From xen-devel-bounces@lists.xensource.com Sun Jan 01 05:01:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 05: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 1RhDXV-0001Kj-UO; Sun, 01 Jan 2012 05:00: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 1RhDXU-0001Ke-0r
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 05:00:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325394049!8661263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30107 invoked from network); 1 Jan 2012 05:00:50 -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;
	1 Jan 2012 05:00:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,439,1320624000"; 
   d="scan'208";a="9765488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 05:00: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; Sun, 1 Jan 2012 05:00: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 1RhDXN-0004Nj-2x;
	Sun, 01 Jan 2012 05:00:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhDXM-0003wg-Sf;
	Sun, 01 Jan 2012 05:00:48 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10620-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Jan 2012 05:00:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10620: 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 10620 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10620/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10619
 test-amd64-amd64-pv          16 guest-start.2      fail in 10619 pass in 10620
 test-i386-i386-xl            16 guest-start.2      fail in 10619 pass in 10620
 test-amd64-i386-xend-winxpsp3  7 windows-install   fail in 10619 pass in 10620
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10619 pass in 10620

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 10614
 test-i386-i386-pv            16 guest-start.2         fail in 10619 like 10618
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10619 like 10618
 test-amd64-i386-xl-credit2   16 guest-start.2         fail in 10619 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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

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                                   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 Sun Jan 01 05:01:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 05: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 1RhDXV-0001Kj-UO; Sun, 01 Jan 2012 05:00: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 1RhDXU-0001Ke-0r
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 05:00:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325394049!8661263!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30107 invoked from network); 1 Jan 2012 05:00:50 -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;
	1 Jan 2012 05:00:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,439,1320624000"; 
   d="scan'208";a="9765488"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 05:00: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; Sun, 1 Jan 2012 05:00: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 1RhDXN-0004Nj-2x;
	Sun, 01 Jan 2012 05:00:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhDXM-0003wg-Sf;
	Sun, 01 Jan 2012 05:00:48 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10620-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 1 Jan 2012 05:00:48 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10620: 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 10620 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10620/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf      7 debian-install              fail pass in 10619
 test-amd64-amd64-pv          16 guest-start.2      fail in 10619 pass in 10620
 test-i386-i386-xl            16 guest-start.2      fail in 10619 pass in 10620
 test-amd64-i386-xend-winxpsp3  7 windows-install   fail in 10619 pass in 10620
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10619 pass in 10620

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10       fail   like 10614
 test-i386-i386-pv            16 guest-start.2         fail in 10619 like 10618
 test-amd64-amd64-xl-sedf    14 guest-localmigrate/x10 fail in 10619 like 10618
 test-amd64-i386-xl-credit2   16 guest-start.2         fail in 10619 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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

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                                   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 Sun Jan 01 11:53:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 11: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 1RhJxd-0003IH-8k; Sun, 01 Jan 2012 11:52:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RhJxb-0003IC-TS
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 11:52:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325418706!46735574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23251 invoked from network); 1 Jan 2012 11:51:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jan 2012 11:51:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,440,1320624000"; 
   d="scan'208";a="9766542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 11:52:18 +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; Sun, 1 Jan 2012
	11:52:18 +0000
Message-ID: <1325418687.24422.36.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: lmingcsce <Ming.Aaron.Liu@gmail.com>
Date: Sun, 1 Jan 2012 11:51:27 +0000
In-Reply-To: <1325368336020-5112670.post@n5.nabble.com>
References: <1325368336020-5112670.post@n5.nabble.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] 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

On Sat, 2011-12-31 at 21:52 +0000, lmingcsce wrote:
> 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. 
> 

Establishing a new array in the tools *directory*? I presume the
"directory" is superfluous.

You can take a look at some hypercall implementations, e.g. multicall.
Example code can be found at xc_minios.c:minios_privcmd_hypercall and
multicall.c:do_multicall .

One thing I want to remind you is that you don't have to translate
virtual address to machine address before passing it to hypervisor.
copy_from_guest can handle that for you. But you do need to define
GUEST_HANDLE for your hypercall. (Again, check multicall implementation
for details.)


Wei.


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

From xen-devel-bounces@lists.xensource.com Sun Jan 01 11:53:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 11: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 1RhJxd-0003IH-8k; Sun, 01 Jan 2012 11:52:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RhJxb-0003IC-TS
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 11:52:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325418706!46735574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23251 invoked from network); 1 Jan 2012 11:51:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jan 2012 11:51:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,440,1320624000"; 
   d="scan'208";a="9766542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 11:52:18 +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; Sun, 1 Jan 2012
	11:52:18 +0000
Message-ID: <1325418687.24422.36.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: lmingcsce <Ming.Aaron.Liu@gmail.com>
Date: Sun, 1 Jan 2012 11:51:27 +0000
In-Reply-To: <1325368336020-5112670.post@n5.nabble.com>
References: <1325368336020-5112670.post@n5.nabble.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] 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

On Sat, 2011-12-31 at 21:52 +0000, lmingcsce wrote:
> 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. 
> 

Establishing a new array in the tools *directory*? I presume the
"directory" is superfluous.

You can take a look at some hypercall implementations, e.g. multicall.
Example code can be found at xc_minios.c:minios_privcmd_hypercall and
multicall.c:do_multicall .

One thing I want to remind you is that you don't have to translate
virtual address to machine address before passing it to hypervisor.
copy_from_guest can handle that for you. But you do need to define
GUEST_HANDLE for your hypercall. (Again, check multicall implementation
for details.)


Wei.


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

From xen-devel-bounces@lists.xensource.com Sun Jan 01 11:58:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 11: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 1RhK35-0003PK-1e; Sun, 01 Jan 2012 11:57:59 +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 1RhK33-0003PD-O8
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 11:57:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325419071!7435099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9268 invoked from network); 1 Jan 2012 11:57:51 -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;
	1 Jan 2012 11:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,440,1320624000"; 
   d="scan'208";a="9766560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 11:57:51 +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; Sun, 1 Jan 2012
	11:57:50 +0000
Message-ID: <1325419019.24422.39.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Florian Heigl <florian.heigl@gmail.com>
Date: Sun, 1 Jan 2012 11:56:59 +0000
In-Reply-To: <CAFivhPmSQLEFaG5XBZg6TWrPDd5U82keMfgbEo8OR8ErG516vw@mail.gmail.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<CAFivhPmSQLEFaG5XBZg6TWrPDd5U82keMfgbEo8OR8ErG516vw@mail.gmail.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.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

On Sat, 2011-12-31 at 15:01 +0000, Florian Heigl wrote:
> 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! :))
> 

Hi Florian

Have you tested these patches (patch 2 is essential)? Do they work for
you? I only took a glimpse of the code, I thought they should work. If
you encounter any further issue, please let me know.


Wei.


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

From xen-devel-bounces@lists.xensource.com Sun Jan 01 11:58:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 11: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 1RhK35-0003PK-1e; Sun, 01 Jan 2012 11:57:59 +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 1RhK33-0003PD-O8
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 11:57:57 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325419071!7435099!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9268 invoked from network); 1 Jan 2012 11:57:51 -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;
	1 Jan 2012 11:57:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,440,1320624000"; 
   d="scan'208";a="9766560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 11:57:51 +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; Sun, 1 Jan 2012
	11:57:50 +0000
Message-ID: <1325419019.24422.39.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Florian Heigl <florian.heigl@gmail.com>
Date: Sun, 1 Jan 2012 11:56:59 +0000
In-Reply-To: <CAFivhPmSQLEFaG5XBZg6TWrPDd5U82keMfgbEo8OR8ErG516vw@mail.gmail.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<CAFivhPmSQLEFaG5XBZg6TWrPDd5U82keMfgbEo8OR8ErG516vw@mail.gmail.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.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

On Sat, 2011-12-31 at 15:01 +0000, Florian Heigl wrote:
> 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! :))
> 

Hi Florian

Have you tested these patches (patch 2 is essential)? Do they work for
you? I only took a glimpse of the code, I thought they should work. If
you encounter any further issue, please let me know.


Wei.


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

From xen-devel-bounces@lists.xensource.com Sun Jan 01 12:06:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 12:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhKAf-0003mG-SK; Sun, 01 Jan 2012 12:05:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RhKAe-0003m6-48
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 12:05:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325419509!46736093!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3287 invoked from network); 1 Jan 2012 12:05:09 -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 Jan 2012 12:05:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,440,1320624000"; 
   d="scan'208";a="9766589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 12:05:14 +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; Sun, 1 Jan 2012
	12:05:14 +0000
Message-ID: <1325419462.24422.45.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: =?UTF-8?Q?=C2=A4=3FK=E6=96=BCaware?= <250716708@qq.com>
Date: Sun, 1 Jan 2012 12:04:22 +0000
In-Reply-To: <tencent_139A0A6F06168A7D7DAAA6A0@qq.com>
References: <tencent_139A0A6F06168A7D7DAAA6A0@qq.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com
Subject: Re: [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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU2F0LCAyMDExLTEyLTMxIGF0IDEyOjA2ICswMDAwLCDCpD9L5pa8YXdhcmUgd3JvdGU6Cj4g
SGkgZXZlcnlvbmUsCj4gICAgIEkgYWRkZWQgZGVidWcgaW5mbyBpbiB0aGUgZnVuY3Rpb24KPiBk
b19zYXZldm0gb2YgL3Rvb2xzL2lvZW11LXFlbXUteGVuL3hlbi12bC1leHRyYS5jIGFzIGZvbGxv
dzoKPiAgCj4gIAo+IERCRygiZ29pbmcgdG8KPiBzYXZlLi4uIik7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAo+IHJldCA9Cj4gcWVtdV9zYXZldm1fc3RhdGUoZik7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAo+IERCRygic2F2ZSBmaW5pc2guLi4iKTsgIAo+ICAKPiBvbmx5IHRvIHNlZSAi
Z29pbmcgdG8gc2F2ZS4uLiIgYW5kICJzYXZlIGZpbmlzaC4uLiIgaW4gdGhlIGxvZwo+IGZpbGUs
YnV0IEkgY291bGRuJ3QgZ2V0IHRoZSBkZWJ1ZyBvdXRwdXQgaW4gcWVtdV9zYXZldm1fc3RhdGUo
ZikKPiBjYWxsZWQgYnkgImRvX3NhdmV2bSIuIFdoeSBub3Q/Cj4gIAoKV2hhdCBhcmUgeW91IGV4
cGVjdGluZyB0byBzZWU/IElmIHlvdSB3YW50IHRvIHNlZSBkZWJ1ZyBvdXRwdXQgZm9yCnFlbXVf
c2F2ZXZtX3N0YXRlKCksIHlvdSBzaG91bGQgYWRkIHNvbWUgY29kZSB0byBkbyB0aGF0LgoKSSBk
b24ndCBmaW5kIGFueSBEQkcoKSBkZWZpbml0aW9uIGluIGlvZW11IGRpcmVjdG9yeS4gSSBndWVz
cyBEQkcoKSBpcwp5b3VyIGN1c3RvbWl6ZWQgd3JhcHBlciBhcm91bmQgcHJpbnRmKCksIHNvIGl0
IHByaW50cyB3aGF0ZXZlciB5b3UgdGVsbAppdCB0byBwcmludCwgcmlnaHQ/CgpBbm90aGVyIHN1
Z2dlc3Rpb24gZm9yIHlvdXIgZGVidWdnaW5nIGlzIHRoYXQgeW91IGNhbiB1c2UgZ2RiIHRvIGNv
bm5lY3QKdG8gcWVtdSAtLSBpdCBpcyBqdXN0IGEgdXNlcnNwYWNlIHByb2dyYW0uCgoKV2VpLgoK
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 01 12:06:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 12:06:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhKAf-0003mG-SK; Sun, 01 Jan 2012 12:05:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RhKAe-0003m6-48
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 12:05:48 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325419509!46736093!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3287 invoked from network); 1 Jan 2012 12:05:09 -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 Jan 2012 12:05:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,440,1320624000"; 
   d="scan'208";a="9766589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 12:05:14 +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; Sun, 1 Jan 2012
	12:05:14 +0000
Message-ID: <1325419462.24422.45.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: =?UTF-8?Q?=C2=A4=3FK=E6=96=BCaware?= <250716708@qq.com>
Date: Sun, 1 Jan 2012 12:04:22 +0000
In-Reply-To: <tencent_139A0A6F06168A7D7DAAA6A0@qq.com>
References: <tencent_139A0A6F06168A7D7DAAA6A0@qq.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com
Subject: Re: [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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU2F0LCAyMDExLTEyLTMxIGF0IDEyOjA2ICswMDAwLCDCpD9L5pa8YXdhcmUgd3JvdGU6Cj4g
SGkgZXZlcnlvbmUsCj4gICAgIEkgYWRkZWQgZGVidWcgaW5mbyBpbiB0aGUgZnVuY3Rpb24KPiBk
b19zYXZldm0gb2YgL3Rvb2xzL2lvZW11LXFlbXUteGVuL3hlbi12bC1leHRyYS5jIGFzIGZvbGxv
dzoKPiAgCj4gIAo+IERCRygiZ29pbmcgdG8KPiBzYXZlLi4uIik7ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAo+IHJldCA9Cj4gcWVtdV9zYXZldm1fc3RhdGUoZik7ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIAo+IERCRygic2F2ZSBmaW5pc2guLi4iKTsgIAo+ICAKPiBvbmx5IHRvIHNlZSAi
Z29pbmcgdG8gc2F2ZS4uLiIgYW5kICJzYXZlIGZpbmlzaC4uLiIgaW4gdGhlIGxvZwo+IGZpbGUs
YnV0IEkgY291bGRuJ3QgZ2V0IHRoZSBkZWJ1ZyBvdXRwdXQgaW4gcWVtdV9zYXZldm1fc3RhdGUo
ZikKPiBjYWxsZWQgYnkgImRvX3NhdmV2bSIuIFdoeSBub3Q/Cj4gIAoKV2hhdCBhcmUgeW91IGV4
cGVjdGluZyB0byBzZWU/IElmIHlvdSB3YW50IHRvIHNlZSBkZWJ1ZyBvdXRwdXQgZm9yCnFlbXVf
c2F2ZXZtX3N0YXRlKCksIHlvdSBzaG91bGQgYWRkIHNvbWUgY29kZSB0byBkbyB0aGF0LgoKSSBk
b24ndCBmaW5kIGFueSBEQkcoKSBkZWZpbml0aW9uIGluIGlvZW11IGRpcmVjdG9yeS4gSSBndWVz
cyBEQkcoKSBpcwp5b3VyIGN1c3RvbWl6ZWQgd3JhcHBlciBhcm91bmQgcHJpbnRmKCksIHNvIGl0
IHByaW50cyB3aGF0ZXZlciB5b3UgdGVsbAppdCB0byBwcmludCwgcmlnaHQ/CgpBbm90aGVyIHN1
Z2dlc3Rpb24gZm9yIHlvdXIgZGVidWdnaW5nIGlzIHRoYXQgeW91IGNhbiB1c2UgZ2RiIHRvIGNv
bm5lY3QKdG8gcWVtdSAtLSBpdCBpcyBqdXN0IGEgdXNlcnNwYWNlIHByb2dyYW0uCgoKV2VpLgoK
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 01 12:11:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 12:11:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhKFP-0003u4-JE; Sun, 01 Jan 2012 12:10:43 +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 1RhKFN-0003tv-AI
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 12:10:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1325419834!9223218!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 479 invoked from network); 1 Jan 2012 12:10:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jan 2012 12:10:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,440,1320624000"; 
   d="scan'208";a="9766610"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 12:10:25 +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; Sun, 1 Jan 2012
	12:10:25 +0000
Message-ID: <1325419773.24422.49.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: =?UTF-8?Q?=C2=A4=3FK=E6=96=BCaware?= <250716708@qq.com>
Date: Sun, 1 Jan 2012 12:09:33 +0000
In-Reply-To: <tencent_47FAD1C91256BB8566380A6B@qq.com>
References: <tencent_47FAD1C91256BB8566380A6B@qq.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com
Subject: Re: [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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU2F0LCAyMDExLTEyLTMxIGF0IDExOjU4ICswMDAwLCDCpD9L5pa8YXdhcmUgd3JvdGU6Cj4g
SGksCj4gICAgIEkgd2FubmEgdHJ5IG15IGJlc3QgdG8gdW5kZXJzdGFuZCB0aGUgbGlieGMgaW4g
eGVudG9vbHMsIGJ1dCBpdCdzCj4gZGlmZmljdWx0IGZvciBtZSwgYSBuZXdlcix0byBjb21wcmVo
ZW5kIGl0J3MgcHJpbmNpcGxlIQo+ICAgICBCZWdnaW5nIGFkdmljZSx0aGFua3MgYSBsb3QgYWhl
YWQhCj4gIAoKbGlieGMgYWN0cyBhcyBpbnRlcm1lZGlhdGUgYmV0d2VlbiB1c2Vyc3BhY2UgYW5k
IGh5cGVydmlzb3IuIEkgdGhpbmsgeW91CmNhbiBmaXJzdCB0YWtlIGEgbG9vayBhdCBpdHMgZXhw
b3J0ZWQgaGVhZGVyIGZpbGUgLS0geGVuY3RybC5oICwgc28gdGhhdAp5b3UgY2FuIGhhdmUgYSBy
b3VnaCBpZGVhIGFib3V0IGl0cyBmdW5jdGlvbmFsaXRpZXMuIFRoZSB5b3UgY2FuIHBpY2sKd2hh
dGV2ZXIgZnVuY3Rpb25hbGl0eSB5b3UgYXJlIGludGVyZXN0ZWQgaW4gYW5kIGRpZyBkZWVwZXIu
CgoKV2VpLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 01 12:11:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 12:11:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhKFP-0003u4-JE; Sun, 01 Jan 2012 12:10:43 +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 1RhKFN-0003tv-AI
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 12:10:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1325419834!9223218!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 479 invoked from network); 1 Jan 2012 12:10:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jan 2012 12:10:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,440,1320624000"; 
   d="scan'208";a="9766610"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 12:10:25 +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; Sun, 1 Jan 2012
	12:10:25 +0000
Message-ID: <1325419773.24422.49.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: =?UTF-8?Q?=C2=A4=3FK=E6=96=BCaware?= <250716708@qq.com>
Date: Sun, 1 Jan 2012 12:09:33 +0000
In-Reply-To: <tencent_47FAD1C91256BB8566380A6B@qq.com>
References: <tencent_47FAD1C91256BB8566380A6B@qq.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, wei.liu2@citrix.com
Subject: Re: [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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU2F0LCAyMDExLTEyLTMxIGF0IDExOjU4ICswMDAwLCDCpD9L5pa8YXdhcmUgd3JvdGU6Cj4g
SGksCj4gICAgIEkgd2FubmEgdHJ5IG15IGJlc3QgdG8gdW5kZXJzdGFuZCB0aGUgbGlieGMgaW4g
eGVudG9vbHMsIGJ1dCBpdCdzCj4gZGlmZmljdWx0IGZvciBtZSwgYSBuZXdlcix0byBjb21wcmVo
ZW5kIGl0J3MgcHJpbmNpcGxlIQo+ICAgICBCZWdnaW5nIGFkdmljZSx0aGFua3MgYSBsb3QgYWhl
YWQhCj4gIAoKbGlieGMgYWN0cyBhcyBpbnRlcm1lZGlhdGUgYmV0d2VlbiB1c2Vyc3BhY2UgYW5k
IGh5cGVydmlzb3IuIEkgdGhpbmsgeW91CmNhbiBmaXJzdCB0YWtlIGEgbG9vayBhdCBpdHMgZXhw
b3J0ZWQgaGVhZGVyIGZpbGUgLS0geGVuY3RybC5oICwgc28gdGhhdAp5b3UgY2FuIGhhdmUgYSBy
b3VnaCBpZGVhIGFib3V0IGl0cyBmdW5jdGlvbmFsaXRpZXMuIFRoZSB5b3UgY2FuIHBpY2sKd2hh
dGV2ZXIgZnVuY3Rpb25hbGl0eSB5b3UgYXJlIGludGVyZXN0ZWQgaW4gYW5kIGRpZyBkZWVwZXIu
CgoKV2VpLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
XwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0
dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 01 12:19:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 12: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 1RhKN9-000463-KO; Sun, 01 Jan 2012 12:18:43 +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 1RhKN8-00045t-2C
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 12:18:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325420316!9326660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28710 invoked from network); 1 Jan 2012 12:18:36 -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;
	1 Jan 2012 12:18:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,441,1320624000"; 
   d="scan'208";a="9766631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 12:18:35 +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; Sun, 1 Jan 2012
	12:18:35 +0000
Message-ID: <1325420264.24422.53.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Stefan Kuhne <stefan.kuhne@gmx.net>
Date: Sun, 1 Jan 2012 12:17:44 +0000
In-Reply-To: <4EFF9AF5.1070404@access.denied>
References: <4EFF9AF5.1070404@access.denied>
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] 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: text/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-31 at 23:29 +0000, Stefan Kuhne wrote:
> 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?

Xen logs are stored in /var/log/xen by default. And judging from you
log, you're probably using xend, right? You can start with xend.log .


Wei.


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

From xen-devel-bounces@lists.xensource.com Sun Jan 01 12:19:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 12: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 1RhKN9-000463-KO; Sun, 01 Jan 2012 12:18:43 +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 1RhKN8-00045t-2C
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 12:18:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325420316!9326660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28710 invoked from network); 1 Jan 2012 12:18:36 -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;
	1 Jan 2012 12:18:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,441,1320624000"; 
   d="scan'208";a="9766631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 12:18:35 +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; Sun, 1 Jan 2012
	12:18:35 +0000
Message-ID: <1325420264.24422.53.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Stefan Kuhne <stefan.kuhne@gmx.net>
Date: Sun, 1 Jan 2012 12:17:44 +0000
In-Reply-To: <4EFF9AF5.1070404@access.denied>
References: <4EFF9AF5.1070404@access.denied>
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] 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: text/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-31 at 23:29 +0000, Stefan Kuhne wrote:
> 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?

Xen logs are stored in /var/log/xen by default. And judging from you
log, you're probably using xend, right? You can start with xend.log .


Wei.


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

From xen-devel-bounces@lists.xensource.com Sun Jan 01 15:00:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 15: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 1RhMsx-000578-Iy; Sun, 01 Jan 2012 14:59:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ming.Aaron.Liu@gmail.com>) id 1RhMsw-000572-Q4
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 14:59:43 +0000
X-Env-Sender: Ming.Aaron.Liu@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325429974!9164154!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10259 invoked from network); 1 Jan 2012 14:59:36 -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;
	1 Jan 2012 14:59:36 -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 1RhMso-0006jL-0b
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 06:59:34 -0800
Date: Sun, 1 Jan 2012 06:59:34 -0800 (PST)
From: lmingcsce <Ming.Aaron.Liu@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <92932E0E-BC3F-44CD-953E-AC3CB7D8F0A1@gmail.com>
In-Reply-To: <1325418687.24422.36.camel@liuw-desktop>
References: <1325368336020-5112670.post@n5.nabble.com>
	<1325418687.24422.36.camel@liuw-desktop>
MIME-Version: 1.0
Subject: Re: [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: multipart/mixed; boundary="===============5777547149358230898=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5777547149358230898==
Content-Type: multipart/alternative; 
	boundary="----=_Part_6963_7648846.1325429974013"

------=_Part_6963_7648846.1325429974013
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for your reply.
"Establishing a new array in the tools directory" means that I declare a new array in /tools/libxc/xc_domain_save.c and want to pass the physical address of this array to the hypervisor.
I have already tried copy_to_user and copy_to_guest and from the experiment, I find that there is size limit for these two functions.
By the way, I also want to ask the code organization of xen. What's the function of stubdom directory? 
When the virtual machines execute, the function in tools will execute in the Dom0 space? Can you illustrate that for me or give me some specific material? I have already seen some explanation, and don't find the answer.
Thanks.

On Jan 1, 2012, at 6:54 AM, Wei Liu-2 [via Xen] wrote:

> On Sat, 2011-12-31 at 21:52 +0000, lmingcsce wrote: 
> > 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. 
> > 
> 
> Establishing a new array in the tools *directory*? I presume the 
> "directory" is superfluous. 
> 
> You can take a look at some hypercall implementations, e.g. multicall. 
> Example code can be found at xc_minios.c:minios_privcmd_hypercall and 
> multicall.c:do_multicall . 
> 
> One thing I want to remind you is that you don't have to translate 
> virtual address to machine address before passing it to hypervisor. 
> copy_from_guest can handle that for you. But you do need to define 
> GUEST_HANDLE for your hypercall. (Again, check multicall implementation 
> for details.) 
> 
> 
> Wei. 
> 
> 
> _______________________________________________ 
> 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/Translate-virtual-address-to-physical-address-tp5112670p5113058.html
> To unsubscribe from Translate virtual address to physical address, click here.
> NAML



--
View this message in context: http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5113190.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_6963_7648846.1325429974013
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for your reply.<div>"Establishing a new array in the tools directory" means that I declare a new array in /tools/libxc/xc_domain_save.c and want to pass the physical address of this array to the hypervisor.</div><div>I have already tried copy_to_user and copy_to_guest and from the experiment, I find that there is size limit for these two functions.</div><div>By the way, I also want to ask the code organization of xen. What's the function of stubdom directory?&nbsp;</div><div>When the virtual machines execute, the function in tools will execute in the Dom0 space? Can you illustrate that for me or give me some specific material? I have already seen some explanation, and don't find the answer.</div><div>Thanks.</div><div><br></div><div><div><div>On Jan 1, 2012, at 6:54 AM, Wei Liu-2 [via Xen] wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">

	On Sat, 2011-12-31 at 21:52 +0000, lmingcsce wrote:
<br>&gt; Hi everyone, I'm working on a research project now and encounter a problem
<br>&gt; like this:
<br>&gt; I establish a new array in the tools directory and pass the address of this
<br>&gt; array to the hypervisor. I want to know how can I translate the virtual
<br>&gt; address of the array to the machine address. In this way, the hypervisor can
<br>&gt; modify the values in this array. 
<br>&gt; Thanks for your help. 
<br>&gt; 
<br><br>Establishing a new array in the tools *directory*? I presume the
<br>"directory" is superfluous.
<br><br>You can take a look at some hypercall implementations, e.g. multicall.
<br>Example code can be found at xc_minios.c:minios_privcmd_hypercall and
<br>multicall.c:do_multicall .
<br><br>One thing I want to remind you is that you don't have to translate
<br>virtual address to machine address before passing it to hypervisor.
<br>copy_from_guest can handle that for you. But you do need to define
<br>GUEST_HANDLE for your hypercall. (Again, check multicall implementation
<br>for details.)
<br><br><br>Wei.
<br><br><br>_______________________________________________
<br>Xen-devel mailing list
<br>&lt;a href=&quot;x-msg://25/user/SendEmail.jtp?type=node&amp;amp;node=5113058&amp;amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot; link=&quot;external&quot;&gt;[hidden email]</a>
<br><a href="http://lists.xensource.com/xen-devel" target="_top" rel="nofollow" link="external">http://lists.xensource.com/xen-devel</a><br>
	
	<br>
	<br>
	<hr noshade="noshade" size="1" color="#cccccc">
	<div style="color:#444; font: 12px tahoma,geneva,helvetica,arial,sans-serif;">
		<div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div>
		<a href="http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5113058.html" target="_top" rel="nofollow" link="external">http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5113058.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 Translate virtual address to physical address, <a href="" target="_top" 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="_top" link="external">NAML</a>
	</div></blockquote></div><br></div>
	
<br/><hr align="left" width="300" />
View this message in context: <a href="http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5113190.html">Re: Translate virtual address to physical address</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_6963_7648846.1325429974013--


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

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

--===============5777547149358230898==--


From xen-devel-bounces@lists.xensource.com Sun Jan 01 15:00:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 15: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 1RhMsx-000578-Iy; Sun, 01 Jan 2012 14:59:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ming.Aaron.Liu@gmail.com>) id 1RhMsw-000572-Q4
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 14:59:43 +0000
X-Env-Sender: Ming.Aaron.Liu@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325429974!9164154!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10259 invoked from network); 1 Jan 2012 14:59:36 -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;
	1 Jan 2012 14:59:36 -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 1RhMso-0006jL-0b
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 06:59:34 -0800
Date: Sun, 1 Jan 2012 06:59:34 -0800 (PST)
From: lmingcsce <Ming.Aaron.Liu@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <92932E0E-BC3F-44CD-953E-AC3CB7D8F0A1@gmail.com>
In-Reply-To: <1325418687.24422.36.camel@liuw-desktop>
References: <1325368336020-5112670.post@n5.nabble.com>
	<1325418687.24422.36.camel@liuw-desktop>
MIME-Version: 1.0
Subject: Re: [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: multipart/mixed; boundary="===============5777547149358230898=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5777547149358230898==
Content-Type: multipart/alternative; 
	boundary="----=_Part_6963_7648846.1325429974013"

------=_Part_6963_7648846.1325429974013
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for your reply.
"Establishing a new array in the tools directory" means that I declare a new array in /tools/libxc/xc_domain_save.c and want to pass the physical address of this array to the hypervisor.
I have already tried copy_to_user and copy_to_guest and from the experiment, I find that there is size limit for these two functions.
By the way, I also want to ask the code organization of xen. What's the function of stubdom directory? 
When the virtual machines execute, the function in tools will execute in the Dom0 space? Can you illustrate that for me or give me some specific material? I have already seen some explanation, and don't find the answer.
Thanks.

On Jan 1, 2012, at 6:54 AM, Wei Liu-2 [via Xen] wrote:

> On Sat, 2011-12-31 at 21:52 +0000, lmingcsce wrote: 
> > 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. 
> > 
> 
> Establishing a new array in the tools *directory*? I presume the 
> "directory" is superfluous. 
> 
> You can take a look at some hypercall implementations, e.g. multicall. 
> Example code can be found at xc_minios.c:minios_privcmd_hypercall and 
> multicall.c:do_multicall . 
> 
> One thing I want to remind you is that you don't have to translate 
> virtual address to machine address before passing it to hypervisor. 
> copy_from_guest can handle that for you. But you do need to define 
> GUEST_HANDLE for your hypercall. (Again, check multicall implementation 
> for details.) 
> 
> 
> Wei. 
> 
> 
> _______________________________________________ 
> 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/Translate-virtual-address-to-physical-address-tp5112670p5113058.html
> To unsubscribe from Translate virtual address to physical address, click here.
> NAML



--
View this message in context: http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5113190.html
Sent from the Xen - Dev mailing list archive at Nabble.com.
------=_Part_6963_7648846.1325429974013
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for your reply.<div>"Establishing a new array in the tools directory" means that I declare a new array in /tools/libxc/xc_domain_save.c and want to pass the physical address of this array to the hypervisor.</div><div>I have already tried copy_to_user and copy_to_guest and from the experiment, I find that there is size limit for these two functions.</div><div>By the way, I also want to ask the code organization of xen. What's the function of stubdom directory?&nbsp;</div><div>When the virtual machines execute, the function in tools will execute in the Dom0 space? Can you illustrate that for me or give me some specific material? I have already seen some explanation, and don't find the answer.</div><div>Thanks.</div><div><br></div><div><div><div>On Jan 1, 2012, at 6:54 AM, Wei Liu-2 [via Xen] wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">

	On Sat, 2011-12-31 at 21:52 +0000, lmingcsce wrote:
<br>&gt; Hi everyone, I'm working on a research project now and encounter a problem
<br>&gt; like this:
<br>&gt; I establish a new array in the tools directory and pass the address of this
<br>&gt; array to the hypervisor. I want to know how can I translate the virtual
<br>&gt; address of the array to the machine address. In this way, the hypervisor can
<br>&gt; modify the values in this array. 
<br>&gt; Thanks for your help. 
<br>&gt; 
<br><br>Establishing a new array in the tools *directory*? I presume the
<br>"directory" is superfluous.
<br><br>You can take a look at some hypercall implementations, e.g. multicall.
<br>Example code can be found at xc_minios.c:minios_privcmd_hypercall and
<br>multicall.c:do_multicall .
<br><br>One thing I want to remind you is that you don't have to translate
<br>virtual address to machine address before passing it to hypervisor.
<br>copy_from_guest can handle that for you. But you do need to define
<br>GUEST_HANDLE for your hypercall. (Again, check multicall implementation
<br>for details.)
<br><br><br>Wei.
<br><br><br>_______________________________________________
<br>Xen-devel mailing list
<br>&lt;a href=&quot;x-msg://25/user/SendEmail.jtp?type=node&amp;amp;node=5113058&amp;amp;i=0&quot; target=&quot;_top&quot; rel=&quot;nofollow&quot; link=&quot;external&quot;&gt;[hidden email]</a>
<br><a href="http://lists.xensource.com/xen-devel" target="_top" rel="nofollow" link="external">http://lists.xensource.com/xen-devel</a><br>
	
	<br>
	<br>
	<hr noshade="noshade" size="1" color="#cccccc">
	<div style="color:#444; font: 12px tahoma,geneva,helvetica,arial,sans-serif;">
		<div style="font-weight:bold">If you reply to this email, your message will be added to the discussion below:</div>
		<a href="http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5113058.html" target="_top" rel="nofollow" link="external">http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5113058.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 Translate virtual address to physical address, <a href="" target="_top" 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="_top" link="external">NAML</a>
	</div></blockquote></div><br></div>
	
<br/><hr align="left" width="300" />
View this message in context: <a href="http://xen.1045712.n5.nabble.com/Translate-virtual-address-to-physical-address-tp5112670p5113190.html">Re: Translate virtual address to physical address</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_6963_7648846.1325429974013--


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

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

--===============5777547149358230898==--


From xen-devel-bounces@lists.xensource.com Sun Jan 01 15:23:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 15:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhNFe-0005MD-LH; Sun, 01 Jan 2012 15:23:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RhNFc-0005M5-Qq
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 15:23:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325431333!59170912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26477 invoked from network); 1 Jan 2012 15:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jan 2012 15:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,441,1320624000"; 
   d="scan'208";a="9767087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 15:23:07 +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; Sun, 1 Jan 2012
	15:23:07 +0000
Message-ID: <1325431335.24422.65.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: lmingcsce <Ming.Aaron.Liu@gmail.com>
Date: Sun, 1 Jan 2012 15:22:15 +0000
In-Reply-To: <92932E0E-BC3F-44CD-953E-AC3CB7D8F0A1@gmail.com>
References: <1325368336020-5112670.post@n5.nabble.com>
	<1325418687.24422.36.camel@liuw-desktop>
	<92932E0E-BC3F-44CD-953E-AC3CB7D8F0A1@gmail.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] 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

Please don't top-posting.

On Sun, 2012-01-01 at 14:59 +0000, lmingcsce wrote:
> Thanks for your reply.
> "Establishing a new array in the tools directory" means that I declare
> a new array in /tools/libxc/xc_domain_save.c and want to pass the
> physical address of this array to the hypervisor.
> I have already tried copy_to_user and copy_to_guest and from the
> experiment, I find that there is size limit for these two functions.

What size limit? I don't quite get it. I've never seen an array large
enough to bloat whole address space.

> By the way, I also want to ask the code organization of xen. What's
> the function of stubdom directory? 

stubdom is used to boost HVM performance. It is based on minios, with
qemu compiled in. It is not mandatory though.

> When the virtual machines execute, the function in tools will execute
> in the Dom0 space? Can you illustrate that for me or give me some
> specific material? I have already seen some explanation, and don't
> find the answer.
> Thanks.

Of course tools run in Dom0, they are just normal user programs.
However, every functionality requires hypervisor to do the actual job. A
normal work flow is like:

toolstack ---(syscall)--> kernel ---(hypercall)--> hypervisor

The kernel entry is /proc/xen/privcmd, whose source code is in Linux
tree drivers/xen/xenfs.



Wei.




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

From xen-devel-bounces@lists.xensource.com Sun Jan 01 15:23:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 01 Jan 2012 15:23:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhNFe-0005MD-LH; Sun, 01 Jan 2012 15:23:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RhNFc-0005M5-Qq
	for xen-devel@lists.xensource.com; Sun, 01 Jan 2012 15:23:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325431333!59170912!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26477 invoked from network); 1 Jan 2012 15:22:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	1 Jan 2012 15:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,441,1320624000"; 
   d="scan'208";a="9767087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	01 Jan 2012 15:23:07 +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; Sun, 1 Jan 2012
	15:23:07 +0000
Message-ID: <1325431335.24422.65.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: lmingcsce <Ming.Aaron.Liu@gmail.com>
Date: Sun, 1 Jan 2012 15:22:15 +0000
In-Reply-To: <92932E0E-BC3F-44CD-953E-AC3CB7D8F0A1@gmail.com>
References: <1325368336020-5112670.post@n5.nabble.com>
	<1325418687.24422.36.camel@liuw-desktop>
	<92932E0E-BC3F-44CD-953E-AC3CB7D8F0A1@gmail.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] 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

Please don't top-posting.

On Sun, 2012-01-01 at 14:59 +0000, lmingcsce wrote:
> Thanks for your reply.
> "Establishing a new array in the tools directory" means that I declare
> a new array in /tools/libxc/xc_domain_save.c and want to pass the
> physical address of this array to the hypervisor.
> I have already tried copy_to_user and copy_to_guest and from the
> experiment, I find that there is size limit for these two functions.

What size limit? I don't quite get it. I've never seen an array large
enough to bloat whole address space.

> By the way, I also want to ask the code organization of xen. What's
> the function of stubdom directory? 

stubdom is used to boost HVM performance. It is based on minios, with
qemu compiled in. It is not mandatory though.

> When the virtual machines execute, the function in tools will execute
> in the Dom0 space? Can you illustrate that for me or give me some
> specific material? I have already seen some explanation, and don't
> find the answer.
> Thanks.

Of course tools run in Dom0, they are just normal user programs.
However, every functionality requires hypervisor to do the actual job. A
normal work flow is like:

toolstack ---(syscall)--> kernel ---(hypercall)--> hypervisor

The kernel entry is /proc/xen/privcmd, whose source code is in Linux
tree drivers/xen/xenfs.



Wei.




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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 05:04:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 05:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rha3P-00071i-Hm; Mon, 02 Jan 2012 05:03: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 1Rha3N-00071d-8A
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 05:03:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325480594!9390185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29865 invoked from network); 2 Jan 2012 05:03:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jan 2012 05:03:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,442,1320624000"; 
   d="scan'208";a="9769835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 05:03:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Jan 2012 05:03: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 1Rha3F-0003xW-J7;
	Mon, 02 Jan 2012 05:03:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rha3F-0002PL-D5;
	Mon, 02 Jan 2012 05:03:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10621-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Jan 2012 05:03:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10621: 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 10621 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10621/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10620
 test-amd64-amd64-xl-sedf      7 debian-install     fail in 10620 pass in 10621

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10619
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10620 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-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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

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


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 Jan 02 05:04:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 05:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rha3P-00071i-Hm; Mon, 02 Jan 2012 05:03: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 1Rha3N-00071d-8A
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 05:03:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325480594!9390185!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTAzOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29865 invoked from network); 2 Jan 2012 05:03:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jan 2012 05:03:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,442,1320624000"; 
   d="scan'208";a="9769835"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 05:03:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Jan 2012 05:03: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 1Rha3F-0003xW-J7;
	Mon, 02 Jan 2012 05:03:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rha3F-0002PL-D5;
	Mon, 02 Jan 2012 05:03:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10621-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Jan 2012 05:03:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10621: 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 10621 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10621/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-pv           16 guest-start.2               fail pass in 10620
 test-amd64-amd64-xl-sedf      7 debian-install     fail in 10620 pass in 10621

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10       fail   like 10619
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10620 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-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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

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


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 Jan 02 08:20:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 08:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhd7A-0008DV-Rw; Mon, 02 Jan 2012 08:19:28 +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 1Rhd79-0008DQ-Hi
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 08:19:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325492360!2669554!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 13409 invoked from network); 2 Jan 2012 08:19:20 -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; 2 Jan 2012 08:19:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 08:19:18 +0000
Message-Id: <4F0176940200007800069FE8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 08:19:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Hui Lv" <hui.lv@intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
In-Reply-To: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com, xen-devel@lists.xensource.com,
	raistlin@linux.it, 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: text/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.12.11 at 09:46, Hui Lv <hui.lv@intel.com> wrote:
> 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.

I do not see why you need a per-scheduler-instance variable for
issuing the warning and correcting the value - one warning (during
the first initialization) is entirely sufficient. (Otoh the already existing
tslice_ms field is pointless currently too, as it never gets changed
after being initialized from sched_credit_tslice_ms - George?)

Jan

> 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 Jan 02 08:20:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 08:20:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhd7A-0008DV-Rw; Mon, 02 Jan 2012 08:19:28 +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 1Rhd79-0008DQ-Hi
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 08:19:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325492360!2669554!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 13409 invoked from network); 2 Jan 2012 08:19:20 -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; 2 Jan 2012 08:19:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 08:19:18 +0000
Message-Id: <4F0176940200007800069FE8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 08:19:16 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Hui Lv" <hui.lv@intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
In-Reply-To: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George.Dunlap@eu.citrix.com, xen-devel@lists.xensource.com,
	raistlin@linux.it, 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: text/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.12.11 at 09:46, Hui Lv <hui.lv@intel.com> wrote:
> 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.

I do not see why you need a per-scheduler-instance variable for
issuing the warning and correcting the value - one warning (during
the first initialization) is entirely sufficient. (Otoh the already existing
tslice_ms field is pointless currently too, as it never gets changed
after being initialized from sched_credit_tslice_ms - George?)

Jan

> 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 Jan 02 08:33:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 08:33:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhdJY-0008QQ-Al; Mon, 02 Jan 2012 08:32: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 1RhdJV-0008QI-S5
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 08:32:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325493127!5658284!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 15692 invoked from network); 2 Jan 2012 08:32:07 -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 Jan 2012 08:32:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 08:32:07 +0000
Message-Id: <4F0179CC0200007800069FF9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 08:33:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chao Zhou" <chao.zhou@intel.com>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

>>> On 29.12.11 at 09:42, "Zhou, Chao" <chao.zhou@intel.com> wrote:
> New issue(1)
> ==============
> 1. VF doesn't work after hot-plug for many times
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1798 

This should be fixed with 24448:3a22ed3ec534.

Jan


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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 08:33:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 08:33:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhdJY-0008QQ-Al; Mon, 02 Jan 2012 08:32: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 1RhdJV-0008QI-S5
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 08:32:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325493127!5658284!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 15692 invoked from network); 2 Jan 2012 08:32:07 -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 Jan 2012 08:32:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 08:32:07 +0000
Message-Id: <4F0179CC0200007800069FF9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 08:33:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Chao Zhou" <chao.zhou@intel.com>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

>>> On 29.12.11 at 09:42, "Zhou, Chao" <chao.zhou@intel.com> wrote:
> New issue(1)
> ==============
> 1. VF doesn't work after hot-plug for many times
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1798 

This should be fixed with 24448:3a22ed3ec534.

Jan


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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 08:45:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 08: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 1RhdVG-0000Az-QD; Mon, 02 Jan 2012 08:44: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 1RhdVF-0000AI-Fq
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 08:44:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325493848!2549312!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 6306 invoked from network); 2 Jan 2012 08:44:09 -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; 2 Jan 2012 08:44:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 08:44:08 +0000
Message-Id: <4F017C9D020000780006A006@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 08:45:01 +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="=__PartD5FB969D.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/blktap: clean up some log 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>
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.

--=__PartD5FB969D.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
@@ -692,7 +692,7 @@ static int blktap_mmap(struct file *filp
 	int ret;
=20
 	if (info =3D=3D NULL) {
-		WPRINTK("blktap: mmap, retrieving idx failed\n");
+		WPRINTK("mmap: no private data?\n");
 		return -ENOMEM;
 	}
=20
@@ -776,8 +776,7 @@ static int blktap_ioctl(struct inode *in
 			if (BLKTAP_MODE_VALID(arg)) {
 				info->mode =3D arg;
 				/* XXX: may need to flush rings here. */
-				DPRINTK("blktap: set mode to %lx\n",=20
-				       arg);
+				DPRINTK("set mode to %lx\n", arg);
 				return 0;
 			}
 		}
@@ -800,8 +799,7 @@ static int blktap_ioctl(struct inode *in
 	{
 		if (info) {
 			info->pid =3D (pid_t)arg;
-			DPRINTK("blktap: pid received %d\n",=20
-			       info->pid);
+			DPRINTK("pid received %d\n", info->pid);
 		}
 		return 0;
 	}
@@ -942,8 +940,7 @@ static int req_increase(void)
 	if (!pending_reqs[mmap_alloc] || !foreign_pages[mmap_alloc])
 		goto out_of_memory;
=20
-	DPRINTK("%s: reqs=3D%lu, pages=3D%d\n",
-		__FUNCTION__, MAX_PENDING_REQS, mmap_pages);
+	DPRINTK("reqs=3D%lu, pages=3D%d\n", MAX_PENDING_REQS, mmap_pages);
=20
 	for (i =3D 0; i < MAX_PENDING_REQS; i++) {
 		list_add_tail(&pending_reqs[mmap_alloc][i].free_list,=20
@@ -1434,13 +1431,13 @@ static void dispatch_rw_block_io(blkif_t
 =09
 	/* Make sure userspace is ready. */
 	if (!info->ring_ok) {
-		WPRINTK("blktap: ring not ready for requests!\n");
+		WPRINTK("ring not ready for requests!\n");
 		goto fail_response;
 	}
 	smp_rmb();
=20
 	if (RING_FULL(&info->ufe_ring)) {
-		WPRINTK("blktap: fe_ring is full, can't add "
+		WPRINTK("fe_ring is full, "
 			"IO Request will be dropped. %d %d\n",
 			RING_SIZE(&info->ufe_ring),
 			RING_SIZE(&blkif->blk_rings.common));
@@ -1515,7 +1512,7 @@ static void dispatch_rw_block_io(blkif_t
 			}
=20
 			if (unlikely(map[i+1].status !=3D GNTST_okay)) {
-				WPRINTK("invalid kernel buffer -- could =
not remap it\n");
+				WPRINTK("invalid user buffer -- could not =
remap it\n");
 				ret =3D 1;
 				map[i+1].handle =3D INVALID_GRANT_HANDLE;
 			}
@@ -1743,7 +1740,7 @@ static int __init blkif_init(void)
 				    "blktap0");
 	} else {
 		/* this is bad, but not fatal */
-		WPRINTK("blktap: sysfs xen_class not created\n");
+		WPRINTK("sysfs xen_class not created\n");
 	}
=20
 	DPRINTK("Blktap device successfully created\n");




--=__PartD5FB969D.0__=
Content-Type: text/plain; name="xen-blktap-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-blktap-cleanup.patch"

blktap: clean up some log messages=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@@ -692,7 +692,7 @@ static int blktap_mmap(struct =
file *filp=0A 	int ret;=0A =0A 	if (info =3D=3D NULL) {=0A-		=
WPRINTK("blktap: mmap, retrieving idx failed\n");=0A+		WPRINTK("mm=
ap: no private data?\n");=0A 		return -ENOMEM;=0A 	}=0A =0A@@ =
-776,8 +776,7 @@ static int blktap_ioctl(struct inode *in=0A 			=
if (BLKTAP_MODE_VALID(arg)) {=0A 				info->mode =
=3D arg;=0A 				/* XXX: may need to flush rings =
here. */=0A-				DPRINTK("blktap: set mode to =
%lx\n", =0A-				       arg);=0A+			=
	DPRINTK("set mode to %lx\n", arg);=0A 				=
return 0;=0A 			}=0A 		}=0A@@ -800,8 +799,7 @@ =
static int blktap_ioctl(struct inode *in=0A 	{=0A 		if (info) =
{=0A 			info->pid =3D (pid_t)arg;=0A-			=
DPRINTK("blktap: pid received %d\n", =0A-			       =
info->pid);=0A+			DPRINTK("pid received %d\n", info->pid);=0A=
 		}=0A 		return 0;=0A 	}=0A@@ -942,8 +940,7 @@ =
static int req_increase(void)=0A 	if (!pending_reqs[mmap_alloc] || =
!foreign_pages[mmap_alloc])=0A 		goto out_of_memory;=0A =0A-	=
DPRINTK("%s: reqs=3D%lu, pages=3D%d\n",=0A-		__FUNCTION__, =
MAX_PENDING_REQS, mmap_pages);=0A+	DPRINTK("reqs=3D%lu, pages=3D%d\n",=
 MAX_PENDING_REQS, mmap_pages);=0A =0A 	for (i =3D 0; i < MAX_PENDING_REQS;=
 i++) {=0A 		list_add_tail(&pending_reqs[mmap_alloc][i].free_lis=
t, =0A@@ -1434,13 +1431,13 @@ static void dispatch_rw_block_io(blkif_t=0A 	=
=0A 	/* Make sure userspace is ready. */=0A 	if (!info->ring_ok) {=0A-	=
	WPRINTK("blktap: ring not ready for requests!\n");=0A+		=
WPRINTK("ring not ready for requests!\n");=0A 		goto fail_response;=
=0A 	}=0A 	smp_rmb();=0A =0A 	if (RING_FULL(&info->ufe_ring)) =
{=0A-		WPRINTK("blktap: fe_ring is full, can't add "=0A+		=
WPRINTK("fe_ring is full, "=0A 			"IO Request will be =
dropped. %d %d\n",=0A 			RING_SIZE(&info->ufe_ring),=0A 		=
	RING_SIZE(&blkif->blk_rings.common));=0A@@ -1515,7 +1512,7 @@ =
static void dispatch_rw_block_io(blkif_t=0A 			}=0A =0A 	=
		if (unlikely(map[i+1].status !=3D GNTST_okay)) {=0A-		=
		WPRINTK("invalid kernel buffer -- could not remap =
it\n");=0A+				WPRINTK("invalid user buffer -- =
could not remap it\n");=0A 				ret =3D 1;=0A 		=
		map[i+1].handle =3D INVALID_GRANT_HANDLE;=0A 			=
}=0A@@ -1743,7 +1740,7 @@ static int __init blkif_init(void)=0A 		=
		    "blktap0");=0A 	} else {=0A 		/* this is =
bad, but not fatal */=0A-		WPRINTK("blktap: sysfs xen_class =
not created\n");=0A+		WPRINTK("sysfs xen_class not created\n");=
=0A 	}=0A =0A 	DPRINTK("Blktap device successfully created\n");=0A
--=__PartD5FB969D.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

--=__PartD5FB969D.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 08:45:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 08: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 1RhdVG-0000Az-QD; Mon, 02 Jan 2012 08:44: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 1RhdVF-0000AI-Fq
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 08:44:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325493848!2549312!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 6306 invoked from network); 2 Jan 2012 08:44:09 -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; 2 Jan 2012 08:44:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 08:44:08 +0000
Message-Id: <4F017C9D020000780006A006@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 08:45:01 +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="=__PartD5FB969D.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/blktap: clean up some log 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>
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.

--=__PartD5FB969D.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
@@ -692,7 +692,7 @@ static int blktap_mmap(struct file *filp
 	int ret;
=20
 	if (info =3D=3D NULL) {
-		WPRINTK("blktap: mmap, retrieving idx failed\n");
+		WPRINTK("mmap: no private data?\n");
 		return -ENOMEM;
 	}
=20
@@ -776,8 +776,7 @@ static int blktap_ioctl(struct inode *in
 			if (BLKTAP_MODE_VALID(arg)) {
 				info->mode =3D arg;
 				/* XXX: may need to flush rings here. */
-				DPRINTK("blktap: set mode to %lx\n",=20
-				       arg);
+				DPRINTK("set mode to %lx\n", arg);
 				return 0;
 			}
 		}
@@ -800,8 +799,7 @@ static int blktap_ioctl(struct inode *in
 	{
 		if (info) {
 			info->pid =3D (pid_t)arg;
-			DPRINTK("blktap: pid received %d\n",=20
-			       info->pid);
+			DPRINTK("pid received %d\n", info->pid);
 		}
 		return 0;
 	}
@@ -942,8 +940,7 @@ static int req_increase(void)
 	if (!pending_reqs[mmap_alloc] || !foreign_pages[mmap_alloc])
 		goto out_of_memory;
=20
-	DPRINTK("%s: reqs=3D%lu, pages=3D%d\n",
-		__FUNCTION__, MAX_PENDING_REQS, mmap_pages);
+	DPRINTK("reqs=3D%lu, pages=3D%d\n", MAX_PENDING_REQS, mmap_pages);
=20
 	for (i =3D 0; i < MAX_PENDING_REQS; i++) {
 		list_add_tail(&pending_reqs[mmap_alloc][i].free_list,=20
@@ -1434,13 +1431,13 @@ static void dispatch_rw_block_io(blkif_t
 =09
 	/* Make sure userspace is ready. */
 	if (!info->ring_ok) {
-		WPRINTK("blktap: ring not ready for requests!\n");
+		WPRINTK("ring not ready for requests!\n");
 		goto fail_response;
 	}
 	smp_rmb();
=20
 	if (RING_FULL(&info->ufe_ring)) {
-		WPRINTK("blktap: fe_ring is full, can't add "
+		WPRINTK("fe_ring is full, "
 			"IO Request will be dropped. %d %d\n",
 			RING_SIZE(&info->ufe_ring),
 			RING_SIZE(&blkif->blk_rings.common));
@@ -1515,7 +1512,7 @@ static void dispatch_rw_block_io(blkif_t
 			}
=20
 			if (unlikely(map[i+1].status !=3D GNTST_okay)) {
-				WPRINTK("invalid kernel buffer -- could =
not remap it\n");
+				WPRINTK("invalid user buffer -- could not =
remap it\n");
 				ret =3D 1;
 				map[i+1].handle =3D INVALID_GRANT_HANDLE;
 			}
@@ -1743,7 +1740,7 @@ static int __init blkif_init(void)
 				    "blktap0");
 	} else {
 		/* this is bad, but not fatal */
-		WPRINTK("blktap: sysfs xen_class not created\n");
+		WPRINTK("sysfs xen_class not created\n");
 	}
=20
 	DPRINTK("Blktap device successfully created\n");




--=__PartD5FB969D.0__=
Content-Type: text/plain; name="xen-blktap-cleanup.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-blktap-cleanup.patch"

blktap: clean up some log messages=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@@ -692,7 +692,7 @@ static int blktap_mmap(struct =
file *filp=0A 	int ret;=0A =0A 	if (info =3D=3D NULL) {=0A-		=
WPRINTK("blktap: mmap, retrieving idx failed\n");=0A+		WPRINTK("mm=
ap: no private data?\n");=0A 		return -ENOMEM;=0A 	}=0A =0A@@ =
-776,8 +776,7 @@ static int blktap_ioctl(struct inode *in=0A 			=
if (BLKTAP_MODE_VALID(arg)) {=0A 				info->mode =
=3D arg;=0A 				/* XXX: may need to flush rings =
here. */=0A-				DPRINTK("blktap: set mode to =
%lx\n", =0A-				       arg);=0A+			=
	DPRINTK("set mode to %lx\n", arg);=0A 				=
return 0;=0A 			}=0A 		}=0A@@ -800,8 +799,7 @@ =
static int blktap_ioctl(struct inode *in=0A 	{=0A 		if (info) =
{=0A 			info->pid =3D (pid_t)arg;=0A-			=
DPRINTK("blktap: pid received %d\n", =0A-			       =
info->pid);=0A+			DPRINTK("pid received %d\n", info->pid);=0A=
 		}=0A 		return 0;=0A 	}=0A@@ -942,8 +940,7 @@ =
static int req_increase(void)=0A 	if (!pending_reqs[mmap_alloc] || =
!foreign_pages[mmap_alloc])=0A 		goto out_of_memory;=0A =0A-	=
DPRINTK("%s: reqs=3D%lu, pages=3D%d\n",=0A-		__FUNCTION__, =
MAX_PENDING_REQS, mmap_pages);=0A+	DPRINTK("reqs=3D%lu, pages=3D%d\n",=
 MAX_PENDING_REQS, mmap_pages);=0A =0A 	for (i =3D 0; i < MAX_PENDING_REQS;=
 i++) {=0A 		list_add_tail(&pending_reqs[mmap_alloc][i].free_lis=
t, =0A@@ -1434,13 +1431,13 @@ static void dispatch_rw_block_io(blkif_t=0A 	=
=0A 	/* Make sure userspace is ready. */=0A 	if (!info->ring_ok) {=0A-	=
	WPRINTK("blktap: ring not ready for requests!\n");=0A+		=
WPRINTK("ring not ready for requests!\n");=0A 		goto fail_response;=
=0A 	}=0A 	smp_rmb();=0A =0A 	if (RING_FULL(&info->ufe_ring)) =
{=0A-		WPRINTK("blktap: fe_ring is full, can't add "=0A+		=
WPRINTK("fe_ring is full, "=0A 			"IO Request will be =
dropped. %d %d\n",=0A 			RING_SIZE(&info->ufe_ring),=0A 		=
	RING_SIZE(&blkif->blk_rings.common));=0A@@ -1515,7 +1512,7 @@ =
static void dispatch_rw_block_io(blkif_t=0A 			}=0A =0A 	=
		if (unlikely(map[i+1].status !=3D GNTST_okay)) {=0A-		=
		WPRINTK("invalid kernel buffer -- could not remap =
it\n");=0A+				WPRINTK("invalid user buffer -- =
could not remap it\n");=0A 				ret =3D 1;=0A 		=
		map[i+1].handle =3D INVALID_GRANT_HANDLE;=0A 			=
}=0A@@ -1743,7 +1740,7 @@ static int __init blkif_init(void)=0A 		=
		    "blktap0");=0A 	} else {=0A 		/* this is =
bad, but not fatal */=0A-		WPRINTK("blktap: sysfs xen_class =
not created\n");=0A+		WPRINTK("sysfs xen_class not created\n");=
=0A 	}=0A =0A 	DPRINTK("Blktap device successfully created\n");=0A
--=__PartD5FB969D.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

--=__PartD5FB969D.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 09:15:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 09:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhdyX-0000kJ-MQ; Mon, 02 Jan 2012 09:14:37 +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 1RhdyV-0000kC-JC
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 09:14:35 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325495668!10223725!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27130 invoked from network); 2 Jan 2012 09:14:28 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-21.messagelabs.com with SMTP;
	2 Jan 2012 09:14:28 -0000
Received: from p5b2e37e1.dip.t-dialin.net ([91.46.55.225] 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 1RhdyJ-0004Ly-9H; Mon, 02 Jan 2012 09:14:23 +0000
Message-ID: <4F01756D.6060909@canonical.com>
Date: Mon, 02 Jan 2012 10:14:21 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
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>
In-Reply-To: <20111220153501.GC13253@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.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 20.12.2011 16:35, 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?

Just returning from being away over the end of year, so not yet followed any
links and such. But yes, ideally there would be a Launchpad bug reported for
this. And the bug number sent to me or here. That report should mention the
release that is used for domU, too.

-Stefan

> 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 Mon Jan 02 09:15:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 09:15:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhdyX-0000kJ-MQ; Mon, 02 Jan 2012 09:14:37 +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 1RhdyV-0000kC-JC
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 09:14:35 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325495668!10223725!1
X-Originating-IP: [91.189.89.112]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27130 invoked from network); 2 Jan 2012 09:14:28 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-21.messagelabs.com with SMTP;
	2 Jan 2012 09:14:28 -0000
Received: from p5b2e37e1.dip.t-dialin.net ([91.46.55.225] 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 1RhdyJ-0004Ly-9H; Mon, 02 Jan 2012 09:14:23 +0000
Message-ID: <4F01756D.6060909@canonical.com>
Date: Mon, 02 Jan 2012 10:14:21 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
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>
In-Reply-To: <20111220153501.GC13253@andromeda.dapyr.net>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.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 20.12.2011 16:35, 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?

Just returning from being away over the end of year, so not yet followed any
links and such. But yes, ideally there would be a Launchpad bug reported for
this. And the bug number sent to me or here. That report should mention the
release that is used for domU, too.

-Stefan

> 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 Mon Jan 02 09:30:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 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 1RheD2-0000z8-4r; Mon, 02 Jan 2012 09:29:36 +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 1RheD1-0000z0-Dj
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 09:29:35 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325496569!7469481!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 1542 invoked from network); 2 Jan 2012 09:29:29 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-12.tower-174.messagelabs.com with SMTP;
	2 Jan 2012 09:29:29 -0000
Received: from p5b2e37e1.dip.t-dialin.net ([91.46.55.225] 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 1RheCu-0004uS-Fq; Mon, 02 Jan 2012 09:29:28 +0000
Message-ID: <4F0178F7.6050905@canonical.com>
Date: Mon, 02 Jan 2012 10:29:27 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
In-Reply-To: <20111216113300.GA4854@aepfle.de>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 16.12.2011 12:33, 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.

That would be the ideal world. Unfortunately, in reality, hosts stick to a
particular version and maybe get updated with what is provided as stable or
security updates.

> In my testing with Xen4 based hosts their xenstored did properly ignore
> the new command.

I can only take what evidence I see publicly on running EC2 instances. The
closest we can get there is something Redhat or CentOS based with a variation of
3.x based hypervisors (my test box is keeping CentOS 5.6 and Xen 3.4.3 to verify
bugs). Checking against our Xen host reintroduced with 11.10, there is no
problem either.

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

As said before, it is hard to say exactly. We can even see variations of Xen 3.x
(I can at least remember having seen three versions ranging from 3.0 to 3.4.3).
So to a certain degree there are updates going on. But it is impossible to say
what and when. But definitely the problem was still there with 3.4.3 (I stopped
updating the test box because I was rather glad to have a state that exhibits
most of the weirdness that happens in the cloud).

-Stefan
> 
> 
> Olaf


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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 09:30:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 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 1RheD2-0000z8-4r; Mon, 02 Jan 2012 09:29:36 +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 1RheD1-0000z0-Dj
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 09:29:35 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325496569!7469481!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 1542 invoked from network); 2 Jan 2012 09:29:29 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-12.tower-174.messagelabs.com with SMTP;
	2 Jan 2012 09:29:29 -0000
Received: from p5b2e37e1.dip.t-dialin.net ([91.46.55.225] 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 1RheCu-0004uS-Fq; Mon, 02 Jan 2012 09:29:28 +0000
Message-ID: <4F0178F7.6050905@canonical.com>
Date: Mon, 02 Jan 2012 10:29:27 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Olaf Hering <olaf@aepfle.de>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
In-Reply-To: <20111216113300.GA4854@aepfle.de>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 16.12.2011 12:33, 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.

That would be the ideal world. Unfortunately, in reality, hosts stick to a
particular version and maybe get updated with what is provided as stable or
security updates.

> In my testing with Xen4 based hosts their xenstored did properly ignore
> the new command.

I can only take what evidence I see publicly on running EC2 instances. The
closest we can get there is something Redhat or CentOS based with a variation of
3.x based hypervisors (my test box is keeping CentOS 5.6 and Xen 3.4.3 to verify
bugs). Checking against our Xen host reintroduced with 11.10, there is no
problem either.

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

As said before, it is hard to say exactly. We can even see variations of Xen 3.x
(I can at least remember having seen three versions ranging from 3.0 to 3.4.3).
So to a certain degree there are updates going on. But it is impossible to say
what and when. But definitely the problem was still there with 3.4.3 (I stopped
updating the test box because I was rather glad to have a state that exhibits
most of the weirdness that happens in the cloud).

-Stefan
> 
> 
> Olaf


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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 09:33:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 09: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 1RheGA-00016H-Ob; Mon, 02 Jan 2012 09:32:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RheG9-000163-NO
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 09:32:49 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325496711!59219742!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 20447 invoked from network); 2 Jan 2012 09:31:51 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-27.messagelabs.com with SMTP;
	2 Jan 2012 09:31:51 -0000
Received: from p5b2e37e1.dip.t-dialin.net ([91.46.55.225] 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 1RheG3-0004zu-Hr; Mon, 02 Jan 2012 09:32:43 +0000
Message-ID: <4F0179BA.7090909@canonical.com>
Date: Mon, 02 Jan 2012 10:32:42 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<20111216152533.GE31755@phenom.dumpdata.com>
In-Reply-To: <20111216152533.GE31755@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, pradeepv@amazon.com,
	Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	scott.moser@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 16.12.2011 16:25, Konrad Rzeszutek Wilk wrote:
> 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?

Sorry have been off over the end of year and I try to be seriously off when I am
off. ;)
Am working my way through email now and maybe this is already obsolete as I see
some submissions which I have not read, yet. But doing that was on my list.

-Stefan

> 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 Mon Jan 02 09:33:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 09: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 1RheGA-00016H-Ob; Mon, 02 Jan 2012 09:32:50 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <stefan.bader@canonical.com>) id 1RheG9-000163-NO
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 09:32:49 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325496711!59219742!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 20447 invoked from network); 2 Jan 2012 09:31:51 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-2.tower-27.messagelabs.com with SMTP;
	2 Jan 2012 09:31:51 -0000
Received: from p5b2e37e1.dip.t-dialin.net ([91.46.55.225] 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 1RheG3-0004zu-Hr; Mon, 02 Jan 2012 09:32:43 +0000
Message-ID: <4F0179BA.7090909@canonical.com>
Date: Mon, 02 Jan 2012 10:32:42 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <4EEA4877.8010307@canonical.com>
	<20111215193942.GA7640@andromeda.dapyr.net>
	<20111216113300.GA4854@aepfle.de>
	<20111216152533.GE31755@phenom.dumpdata.com>
In-Reply-To: <20111216152533.GE31755@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, pradeepv@amazon.com,
	Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	scott.moser@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 16.12.2011 16:25, Konrad Rzeszutek Wilk wrote:
> 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?

Sorry have been off over the end of year and I try to be seriously off when I am
off. ;)
Am working my way through email now and maybe this is already obsolete as I see
some submissions which I have not read, yet. But doing that was on my list.

-Stefan

> 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 Mon Jan 02 10:08:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 10:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhenx-0001Re-Ok; Mon, 02 Jan 2012 10:07:45 +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 1Rhenw-0001RZ-EO
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 10:07:44 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325498858!7493013!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNDcyNTc=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28562 invoked from network); 2 Jan 2012 10:07:38 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-2.tower-174.messagelabs.com with SMTP;
	2 Jan 2012 10:07:38 -0000
Received: (qmail invoked by alias); 02 Jan 2012 10:07:37 -0000
Received: from dslb-084-059-171-050.pools.arcor-ip.net (EHLO [192.168.222.23])
	[84.59.171.50]
	by mail.gmx.net (mp029) with SMTP; 02 Jan 2012 11:07:37 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX19BSfxGnB1BjVb5wNGJ0BtQr4wphenrAtCYk+lTWQ
	nddZgXRPIOxP+h
Message-ID: <4F0181A1.3010509@gmx.de>
Date: Mon, 02 Jan 2012 11:06:25 +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>
X-Enigmail-Version: 1.3.3
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] review of tools/hotplug/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: multipart/mixed; boundary="===============5713828183554984360=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============5713828183554984360==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030304040006040604050407"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms030304040006040604050407
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

I plan to use xen with openvswitch and did already some work, I plan to
prepare some patches when I'm done with it, maybe someone is a bit
further? But I found that the scripts are still hardcoded to use
ifconfig, maybe they should be refactored to use ip (iproute2), as afaik
this is where it goes.

I have to check the use of the vif-name patch, maybe it makes a more
static approach desirable when using ovs.

Regards,
Florian


--------------ms030304040006040604050407
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwMjEwMDYyNVow
IwYJKoZIhvcNAQkEMRYEFKn4S7k2RdB193dTx3z13JNnq14RMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAtxZif1OGtDbs8nnkBpnDK6txPmee12conltpos1TJ+A53jmF
v8btblPsKjjbcWerqs7rJ2mR2l0wS2QcEA6NlSD9Me9xb34cgHcIVGYuybtYmEGYUhKgcXwb
JpcH3HR/SB8nwBwNz/YldwjV31Xk4uPca5zR+OTzUsUkpkGz1/WguEwXtnyg5qYj8rksFQmk
zVETrWTdLq38/KJlrtb6SVFmjS8BDYvaUGRmoAc52MHxb16xgdzQS7dfzylwHDsM/RyoD4Br
encNP056l5bng5gRpsCWQax/dnC2SHF038Y+TRwdjWsGGV/fq1qfuMJupC6rwtdLOLu1feGt
Y+9mpgAAAAAAAA==
--------------ms030304040006040604050407--


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

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

--===============5713828183554984360==--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 10:08:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 10:08:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhenx-0001Re-Ok; Mon, 02 Jan 2012 10:07:45 +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 1Rhenw-0001RZ-EO
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 10:07:44 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325498858!7493013!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNDcyNTc=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28562 invoked from network); 2 Jan 2012 10:07:38 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-2.tower-174.messagelabs.com with SMTP;
	2 Jan 2012 10:07:38 -0000
Received: (qmail invoked by alias); 02 Jan 2012 10:07:37 -0000
Received: from dslb-084-059-171-050.pools.arcor-ip.net (EHLO [192.168.222.23])
	[84.59.171.50]
	by mail.gmx.net (mp029) with SMTP; 02 Jan 2012 11:07:37 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX19BSfxGnB1BjVb5wNGJ0BtQr4wphenrAtCYk+lTWQ
	nddZgXRPIOxP+h
Message-ID: <4F0181A1.3010509@gmx.de>
Date: Mon, 02 Jan 2012 11:06:25 +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>
X-Enigmail-Version: 1.3.3
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] review of tools/hotplug/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: multipart/mixed; boundary="===============5713828183554984360=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============5713828183554984360==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030304040006040604050407"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms030304040006040604050407
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

I plan to use xen with openvswitch and did already some work, I plan to
prepare some patches when I'm done with it, maybe someone is a bit
further? But I found that the scripts are still hardcoded to use
ifconfig, maybe they should be refactored to use ip (iproute2), as afaik
this is where it goes.

I have to check the use of the vif-name patch, maybe it makes a more
static approach desirable when using ovs.

Regards,
Florian


--------------ms030304040006040604050407
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwMjEwMDYyNVow
IwYJKoZIhvcNAQkEMRYEFKn4S7k2RdB193dTx3z13JNnq14RMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAtxZif1OGtDbs8nnkBpnDK6txPmee12conltpos1TJ+A53jmF
v8btblPsKjjbcWerqs7rJ2mR2l0wS2QcEA6NlSD9Me9xb34cgHcIVGYuybtYmEGYUhKgcXwb
JpcH3HR/SB8nwBwNz/YldwjV31Xk4uPca5zR+OTzUsUkpkGz1/WguEwXtnyg5qYj8rksFQmk
zVETrWTdLq38/KJlrtb6SVFmjS8BDYvaUGRmoAc52MHxb16xgdzQS7dfzylwHDsM/RyoD4Br
encNP056l5bng5gRpsCWQax/dnC2SHF038Y+TRwdjWsGGV/fq1qfuMJupC6rwtdLOLu1feGt
Y+9mpgAAAAAAAA==
--------------ms030304040006040604050407--


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

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

--===============5713828183554984360==--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 10:15:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 10:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhevJ-0001cw-Te; Mon, 02 Jan 2012 10:15: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 1RhevH-0001cj-Sp
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 10:15:20 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325499311!7474354!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.2 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjg5MDQ2\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjg5MDQ2\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_60_70,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 23808 invoked from network); 2 Jan 2012 10:15:12 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-12.tower-174.messagelabs.com with SMTP;
	2 Jan 2012 10:15:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1325499307; bh=igMfuqcPFNwDEckYUn7V1pY1ycO7wSxuT2dGp41N14Q=;
	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=YsnBPocCOGB3NfZBaqGGp3ZhP/V802gcpscm7dNStsM9BX+C3q4hWqnkgnljKWVtp
	C4q1iOo1DUPfwNK6XwY8Orn/9dLBdlMYVLLiLbzT7EWfZEXK31jxwK1c6l6qjAZ
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 121.18.202.140
X-QQ-STYLE: 
X-QQ-mid: webmail196t1325499306t1944624
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?V2VpIExpdQ==?=" <wei.liu2@citrix.com>
Mime-Version: 1.0
Date: Mon, 2 Jan 2012 18:15:06 +0800
X-Priority: 3
Message-ID: <tencent_485C08C7518FDF676D33E626@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 3666770161
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>
Subject: Re: [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="===============1693476192436074240=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1693476192436074240==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4F0183AA_087514D8_3825943B"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4F0183AA_087514D8_3825943B
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

VGhlIGZ1bmN0aW9uIGRvX3NhdmV2bSBvZiAvdG9vbHMvaW9lbXUtcWVtdS14ZW4veGVuLXZs
LWV4dHJhLmMgaXMgY2FsbGVkIHdoZW4gdXNpbmcgJ3htIHNhdmUvcmVzdG9yZScgY29tbWFu
ZC4NCiAgICBKdXN0IGFzIHlvdSBzYWlkLCBEQkcgaXMgYSB3cmFwcGVyIGFyb3VuZCBwcmlu
dGYuDQogICAgSSBhbHNvIGFkZGVkIERCRyBpbiBxZW11X3NhdmV2bV9zdGF0ZSgpLCBidXQg
aXQgZGlkbid0IHByb2R1Y2Ugb3V0cHV0IGluZm8uIFBlcmhhcHMsIGl0cyBvdXRwdXQgd2Fz
IHJlZGlyZWN0ZWQgdG8gYW5vdGhlciBwbGFjZSB3aGVyZSBJIGRpZG4ndCByZWxhbGl6ZSBv
ciB0byAvZGV2L251bGwgYmVjYXVzZSBvZiB1bmtub3duIHJlYXNvbi4uLg0KDQogDQotLS0t
LS0tLS0tLS0tLS0tLS0g1K3KvNPKvP4gLS0tLS0tLS0tLS0tLS0tLS0tDQq3orz+yMs6ICJX
ZWkgTGl1Ijx3ZWkubGl1MkBjaXRyaXguY29tPjsNCreiy83KsbzkOiAyMDEyxOox1MIxyNUo
0MfG2szsKSDN7cnPODowNA0KytW8/sjLOiAioeg/S+y2YXdhcmUiPDI1MDcxNjcwOEBxcS5j
b20+OyANCrOty806ICJ3ZWkubGl1MiI8d2VpLmxpdTJAY2l0cml4LmNvbT47ICJ4ZW4tZGV2
ZWwiPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tPjsgDQrW98ziOiBSZTogW1hlbi1k
ZXZlbF0gW2hlbHBdIHByb2JsZW0gd2l0aCBkZWJ1Z2luZy90b29scy9pb2VtdS1xZW11LXhl
bi94ZW4tdmwtZXh0cmEuYw0KDQogDQpPbiBTYXQsIDIwMTEtMTItMzEgYXQgMTI6MDYgKzAw
MDAsIKHoP0vstmF3YXJlIHdyb3RlOg0KPiBIaSBldmVyeW9uZSwNCj4gICAgIEkgYWRkZWQg
ZGVidWcgaW5mbyBpbiB0aGUgZnVuY3Rpb24NCj4gZG9fc2F2ZXZtIG9mIC90b29scy9pb2Vt
dS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYyBhcyBmb2xsb3c6DQo+ICANCj4gIA0KPiBEQkco
ImdvaW5nIHRvDQo+IHNhdmUuLi4iKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgDQo+IHJldCA9DQo+IHFlbXVfc2F2ZXZtX3N0YXRlKGYpOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICANCj4gREJHKCJzYXZlIGZpbmlzaC4uLiIpOyAgDQo+ICANCj4gb25s
eSB0byBzZWUgImdvaW5nIHRvIHNhdmUuLi4iIGFuZCAic2F2ZSBmaW5pc2guLi4iIGluIHRo
ZSBsb2cNCj4gZmlsZSxidXQgSSBjb3VsZG4ndCBnZXQgdGhlIGRlYnVnIG91dHB1dCBpbiBx
ZW11X3NhdmV2bV9zdGF0ZShmKQ0KPiBjYWxsZWQgYnkgImRvX3NhdmV2bSIuIFdoeSBub3Q/
DQo+ICANCg0KV2hhdCBhcmUgeW91IGV4cGVjdGluZyB0byBzZWU/IElmIHlvdSB3YW50IHRv
IHNlZSBkZWJ1ZyBvdXRwdXQgZm9yDQpxZW11X3NhdmV2bV9zdGF0ZSgpLCB5b3Ugc2hvdWxk
IGFkZCBzb21lIGNvZGUgdG8gZG8gdGhhdC4NCg0KSSBkb24ndCBmaW5kIGFueSBEQkcoKSBk
ZWZpbml0aW9uIGluIGlvZW11IGRpcmVjdG9yeS4gSSBndWVzcyBEQkcoKSBpcw0KeW91ciBj
dXN0b21pemVkIHdyYXBwZXIgYXJvdW5kIHByaW50ZigpLCBzbyBpdCBwcmludHMgd2hhdGV2
ZXIgeW91IHRlbGwNCml0IHRvIHByaW50LCByaWdodD8NCg0KQW5vdGhlciBzdWdnZXN0aW9u
IGZvciB5b3VyIGRlYnVnZ2luZyBpcyB0aGF0IHlvdSBjYW4gdXNlIGdkYiB0byBjb25uZWN0
DQp0byBxZW11IC0tIGl0IGlzIGp1c3QgYSB1c2Vyc3BhY2UgcHJvZ3JhbS4NCg0KDQpXZWku


------=_NextPart_4F0183AA_087514D8_3825943B
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PGJyPiZuYnNwOyZuYnNwOyBUaGUgZnVuY3Rpb24gZG9fc2F2ZXZtIG9mIC90b29scy9pb2Vt
dS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYyBpcyBjYWxsZWQgd2hlbiB1c2luZyAneG0gc2F2
ZS9yZXN0b3JlJyBjb21tYW5kLjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgSnVzdCBhcyB5b3Ug
c2FpZCwgREJHIGlzIGEgd3JhcHBlciBhcm91bmQgcHJpbnRmLjxicj48ZGl2PjxpbmNsdWRl
dGFpbD48ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBJIGFsc28gYWRkZWQgREJHIGluIHFlbXVf
c2F2ZXZtX3N0YXRlKCksIGJ1dCBpdCBkaWRuJ3QgcHJvZHVjZSBvdXRwdXQgaW5mby4gUGVy
aGFwcywgaXRzIG91dHB1dCB3YXMgcmVkaXJlY3RlZCB0byBhbm90aGVyIHBsYWNlIHdoZXJl
IEkgZGlkbid0IHJlbGFsaXplIG9yIHRvIC9kZXYvbnVsbCBiZWNhdXNlIG9mIHVua25vd24g
cmVhc29uLi4uPGJyPjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0iZm9udDpW
ZXJkYW5hIG5vcm1hbCAxNHB4O2NvbG9yOiMwMDA7Ij48ZGl2IHN0eWxlPSJGT05ULVNJWkU6
IDEycHg7Rk9OVC1GQU1JTFk6IEFyaWFsIE5hcnJvdztwYWRkaW5nOjJweCAwIDJweCAwOyI+
LS0tLS0tLS0tLS0tLS0tLS0tJm5ic3A71K3KvNPKvP4mbmJzcDstLS0tLS0tLS0tLS0tLS0t
LS08L2Rpdj48ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHg7YmFja2dyb3VuZDojZWZlZmVm
O3BhZGRpbmc6OHB4OyI+PGRpdiBpZD0ibWVudV9zZW5kZXIiPjxiPreivP7Iyzo8L2I+Jm5i
c3A7IldlaSBMaXUiJmx0O3dlaS5saXUyQGNpdHJpeC5jb20mZ3Q7OzwvZGl2PjxkaXY+PGI+
t6LLzcqxvOQ6PC9iPiZuYnNwOzIwMTLE6jHUwjHI1SjQx8bazOwpIM3tyc84OjA0PC9kaXY+
PGRpdj48Yj7K1bz+yMs6PC9iPiZuYnNwOyKh6D9L7LZhd2FyZSImbHQ7MjUwNzE2NzA4QHFx
LmNvbSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj6zrcvNOjwvYj4mbmJzcDsid2VpLmxpdTIi
Jmx0O3dlaS5saXUyQGNpdHJpeC5jb20mZ3Q7OyAieGVuLWRldmVsIiZsdDt4ZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj7W98ziOjwvYj4m
bmJzcDtSZTogW1hlbi1kZXZlbF0gW2hlbHBdIHByb2JsZW0gd2l0aCBkZWJ1Z2luZy90b29s
cy9pb2VtdS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYzwvZGl2PjwvZGl2PjxkaXY+Jm5ic3A7
PC9kaXY+T24gU2F0LCAyMDExLTEyLTMxIGF0IDEyOjA2ICswMDAwLCCh6D9L7LZhd2FyZSB3
cm90ZTo8YnI+Jmd0OyBIaSBldmVyeW9uZSw8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBJIGFkZGVkIGRlYnVnIGluZm8gaW4gdGhlIGZ1bmN0aW9uPGJyPiZndDsgZG9fc2F2
ZXZtIG9mIC90b29scy9pb2VtdS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYyBhcyBmb2xsb3c6
PGJyPiZndDsmbmJzcDsgPGJyPiZndDsmbmJzcDsgPGJyPiZndDsgREJHKCJnb2luZyB0bzxi
cj4mZ3Q7IHNhdmUuLi4iKTsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
PGJyPiZndDsgcmV0ID08YnI+Jmd0OyBxZW11X3NhdmV2bV9zdGF0ZShmKTsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgPGJyPiZndDsgREJHKCJzYXZlIGZpbmlzaC4uLiIpOyZuYnNwOyA8YnI+Jmd0
OyZuYnNwOyA8YnI+Jmd0OyBvbmx5IHRvIHNlZSAiZ29pbmcgdG8gc2F2ZS4uLiIgYW5kICJz
YXZlIGZpbmlzaC4uLiIgaW4gdGhlIGxvZzxicj4mZ3Q7IGZpbGUsYnV0IEkgY291bGRuJ3Qg
Z2V0IHRoZSBkZWJ1ZyBvdXRwdXQgaW4gcWVtdV9zYXZldm1fc3RhdGUoZik8YnI+Jmd0OyBj
YWxsZWQgYnkgImRvX3NhdmV2bSIuIFdoeSBub3Q/PGJyPiZndDsmbmJzcDsgPGJyPjxicj5X
aGF0IGFyZSB5b3UgZXhwZWN0aW5nIHRvIHNlZT8gSWYgeW91IHdhbnQgdG8gc2VlIGRlYnVn
IG91dHB1dCBmb3I8YnI+cWVtdV9zYXZldm1fc3RhdGUoKSwgeW91IHNob3VsZCBhZGQgc29t
ZSBjb2RlIHRvIGRvIHRoYXQuPGJyPjxicj5JIGRvbid0IGZpbmQgYW55IERCRygpIGRlZmlu
aXRpb24gaW4gaW9lbXUgZGlyZWN0b3J5LiBJIGd1ZXNzIERCRygpIGlzPGJyPnlvdXIgY3Vz
dG9taXplZCB3cmFwcGVyIGFyb3VuZCBwcmludGYoKSwgc28gaXQgcHJpbnRzIHdoYXRldmVy
IHlvdSB0ZWxsPGJyPml0IHRvIHByaW50LCByaWdodD88YnI+PGJyPkFub3RoZXIgc3VnZ2Vz
dGlvbiBmb3IgeW91ciBkZWJ1Z2dpbmcgaXMgdGhhdCB5b3UgY2FuIHVzZSBnZGIgdG8gY29u
bmVjdDxicj50byBxZW11IC0tIGl0IGlzIGp1c3QgYSB1c2Vyc3BhY2UgcHJvZ3JhbS48YnI+
PGJyPjxicj5XZWkuPGJyPjxicj48YnI+PGJyPjwvZGl2PjwvaW5jbHVkZXRhaWw+PC9kaXY+


------=_NextPart_4F0183AA_087514D8_3825943B--



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

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

--===============1693476192436074240==--



From xen-devel-bounces@lists.xensource.com Mon Jan 02 10:15:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 10:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhevJ-0001cw-Te; Mon, 02 Jan 2012 10:15: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 1RhevH-0001cj-Sp
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 10:15:20 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325499311!7474354!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.2 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjg5MDQ2\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjg5MDQ2\n,FROM_ALL_NUMS,
	FROM_STARTS_WITH_NUMS,HTML_60_70,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 23808 invoked from network); 2 Jan 2012 10:15:12 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-12.tower-174.messagelabs.com with SMTP;
	2 Jan 2012 10:15:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1325499307; bh=igMfuqcPFNwDEckYUn7V1pY1ycO7wSxuT2dGp41N14Q=;
	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=YsnBPocCOGB3NfZBaqGGp3ZhP/V802gcpscm7dNStsM9BX+C3q4hWqnkgnljKWVtp
	C4q1iOo1DUPfwNK6XwY8Orn/9dLBdlMYVLLiLbzT7EWfZEXK31jxwK1c6l6qjAZ
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 121.18.202.140
X-QQ-STYLE: 
X-QQ-mid: webmail196t1325499306t1944624
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?V2VpIExpdQ==?=" <wei.liu2@citrix.com>
Mime-Version: 1.0
Date: Mon, 2 Jan 2012 18:15:06 +0800
X-Priority: 3
Message-ID: <tencent_485C08C7518FDF676D33E626@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 3666770161
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>
Subject: Re: [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="===============1693476192436074240=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1693476192436074240==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4F0183AA_087514D8_3825943B"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4F0183AA_087514D8_3825943B
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

VGhlIGZ1bmN0aW9uIGRvX3NhdmV2bSBvZiAvdG9vbHMvaW9lbXUtcWVtdS14ZW4veGVuLXZs
LWV4dHJhLmMgaXMgY2FsbGVkIHdoZW4gdXNpbmcgJ3htIHNhdmUvcmVzdG9yZScgY29tbWFu
ZC4NCiAgICBKdXN0IGFzIHlvdSBzYWlkLCBEQkcgaXMgYSB3cmFwcGVyIGFyb3VuZCBwcmlu
dGYuDQogICAgSSBhbHNvIGFkZGVkIERCRyBpbiBxZW11X3NhdmV2bV9zdGF0ZSgpLCBidXQg
aXQgZGlkbid0IHByb2R1Y2Ugb3V0cHV0IGluZm8uIFBlcmhhcHMsIGl0cyBvdXRwdXQgd2Fz
IHJlZGlyZWN0ZWQgdG8gYW5vdGhlciBwbGFjZSB3aGVyZSBJIGRpZG4ndCByZWxhbGl6ZSBv
ciB0byAvZGV2L251bGwgYmVjYXVzZSBvZiB1bmtub3duIHJlYXNvbi4uLg0KDQogDQotLS0t
LS0tLS0tLS0tLS0tLS0g1K3KvNPKvP4gLS0tLS0tLS0tLS0tLS0tLS0tDQq3orz+yMs6ICJX
ZWkgTGl1Ijx3ZWkubGl1MkBjaXRyaXguY29tPjsNCreiy83KsbzkOiAyMDEyxOox1MIxyNUo
0MfG2szsKSDN7cnPODowNA0KytW8/sjLOiAioeg/S+y2YXdhcmUiPDI1MDcxNjcwOEBxcS5j
b20+OyANCrOty806ICJ3ZWkubGl1MiI8d2VpLmxpdTJAY2l0cml4LmNvbT47ICJ4ZW4tZGV2
ZWwiPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tPjsgDQrW98ziOiBSZTogW1hlbi1k
ZXZlbF0gW2hlbHBdIHByb2JsZW0gd2l0aCBkZWJ1Z2luZy90b29scy9pb2VtdS1xZW11LXhl
bi94ZW4tdmwtZXh0cmEuYw0KDQogDQpPbiBTYXQsIDIwMTEtMTItMzEgYXQgMTI6MDYgKzAw
MDAsIKHoP0vstmF3YXJlIHdyb3RlOg0KPiBIaSBldmVyeW9uZSwNCj4gICAgIEkgYWRkZWQg
ZGVidWcgaW5mbyBpbiB0aGUgZnVuY3Rpb24NCj4gZG9fc2F2ZXZtIG9mIC90b29scy9pb2Vt
dS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYyBhcyBmb2xsb3c6DQo+ICANCj4gIA0KPiBEQkco
ImdvaW5nIHRvDQo+IHNhdmUuLi4iKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgDQo+IHJldCA9DQo+IHFlbXVfc2F2ZXZtX3N0YXRlKGYpOyAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICANCj4gREJHKCJzYXZlIGZpbmlzaC4uLiIpOyAgDQo+ICANCj4gb25s
eSB0byBzZWUgImdvaW5nIHRvIHNhdmUuLi4iIGFuZCAic2F2ZSBmaW5pc2guLi4iIGluIHRo
ZSBsb2cNCj4gZmlsZSxidXQgSSBjb3VsZG4ndCBnZXQgdGhlIGRlYnVnIG91dHB1dCBpbiBx
ZW11X3NhdmV2bV9zdGF0ZShmKQ0KPiBjYWxsZWQgYnkgImRvX3NhdmV2bSIuIFdoeSBub3Q/
DQo+ICANCg0KV2hhdCBhcmUgeW91IGV4cGVjdGluZyB0byBzZWU/IElmIHlvdSB3YW50IHRv
IHNlZSBkZWJ1ZyBvdXRwdXQgZm9yDQpxZW11X3NhdmV2bV9zdGF0ZSgpLCB5b3Ugc2hvdWxk
IGFkZCBzb21lIGNvZGUgdG8gZG8gdGhhdC4NCg0KSSBkb24ndCBmaW5kIGFueSBEQkcoKSBk
ZWZpbml0aW9uIGluIGlvZW11IGRpcmVjdG9yeS4gSSBndWVzcyBEQkcoKSBpcw0KeW91ciBj
dXN0b21pemVkIHdyYXBwZXIgYXJvdW5kIHByaW50ZigpLCBzbyBpdCBwcmludHMgd2hhdGV2
ZXIgeW91IHRlbGwNCml0IHRvIHByaW50LCByaWdodD8NCg0KQW5vdGhlciBzdWdnZXN0aW9u
IGZvciB5b3VyIGRlYnVnZ2luZyBpcyB0aGF0IHlvdSBjYW4gdXNlIGdkYiB0byBjb25uZWN0
DQp0byBxZW11IC0tIGl0IGlzIGp1c3QgYSB1c2Vyc3BhY2UgcHJvZ3JhbS4NCg0KDQpXZWku


------=_NextPart_4F0183AA_087514D8_3825943B
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

PGJyPiZuYnNwOyZuYnNwOyBUaGUgZnVuY3Rpb24gZG9fc2F2ZXZtIG9mIC90b29scy9pb2Vt
dS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYyBpcyBjYWxsZWQgd2hlbiB1c2luZyAneG0gc2F2
ZS9yZXN0b3JlJyBjb21tYW5kLjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgSnVzdCBhcyB5b3Ug
c2FpZCwgREJHIGlzIGEgd3JhcHBlciBhcm91bmQgcHJpbnRmLjxicj48ZGl2PjxpbmNsdWRl
dGFpbD48ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyBJIGFsc28gYWRkZWQgREJHIGluIHFlbXVf
c2F2ZXZtX3N0YXRlKCksIGJ1dCBpdCBkaWRuJ3QgcHJvZHVjZSBvdXRwdXQgaW5mby4gUGVy
aGFwcywgaXRzIG91dHB1dCB3YXMgcmVkaXJlY3RlZCB0byBhbm90aGVyIHBsYWNlIHdoZXJl
IEkgZGlkbid0IHJlbGFsaXplIG9yIHRvIC9kZXYvbnVsbCBiZWNhdXNlIG9mIHVua25vd24g
cmVhc29uLi4uPGJyPjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0iZm9udDpW
ZXJkYW5hIG5vcm1hbCAxNHB4O2NvbG9yOiMwMDA7Ij48ZGl2IHN0eWxlPSJGT05ULVNJWkU6
IDEycHg7Rk9OVC1GQU1JTFk6IEFyaWFsIE5hcnJvdztwYWRkaW5nOjJweCAwIDJweCAwOyI+
LS0tLS0tLS0tLS0tLS0tLS0tJm5ic3A71K3KvNPKvP4mbmJzcDstLS0tLS0tLS0tLS0tLS0t
LS08L2Rpdj48ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHg7YmFja2dyb3VuZDojZWZlZmVm
O3BhZGRpbmc6OHB4OyI+PGRpdiBpZD0ibWVudV9zZW5kZXIiPjxiPreivP7Iyzo8L2I+Jm5i
c3A7IldlaSBMaXUiJmx0O3dlaS5saXUyQGNpdHJpeC5jb20mZ3Q7OzwvZGl2PjxkaXY+PGI+
t6LLzcqxvOQ6PC9iPiZuYnNwOzIwMTLE6jHUwjHI1SjQx8bazOwpIM3tyc84OjA0PC9kaXY+
PGRpdj48Yj7K1bz+yMs6PC9iPiZuYnNwOyKh6D9L7LZhd2FyZSImbHQ7MjUwNzE2NzA4QHFx
LmNvbSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj6zrcvNOjwvYj4mbmJzcDsid2VpLmxpdTIi
Jmx0O3dlaS5saXUyQGNpdHJpeC5jb20mZ3Q7OyAieGVuLWRldmVsIiZsdDt4ZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj7W98ziOjwvYj4m
bmJzcDtSZTogW1hlbi1kZXZlbF0gW2hlbHBdIHByb2JsZW0gd2l0aCBkZWJ1Z2luZy90b29s
cy9pb2VtdS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYzwvZGl2PjwvZGl2PjxkaXY+Jm5ic3A7
PC9kaXY+T24gU2F0LCAyMDExLTEyLTMxIGF0IDEyOjA2ICswMDAwLCCh6D9L7LZhd2FyZSB3
cm90ZTo8YnI+Jmd0OyBIaSBldmVyeW9uZSw8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBJIGFkZGVkIGRlYnVnIGluZm8gaW4gdGhlIGZ1bmN0aW9uPGJyPiZndDsgZG9fc2F2
ZXZtIG9mIC90b29scy9pb2VtdS1xZW11LXhlbi94ZW4tdmwtZXh0cmEuYyBhcyBmb2xsb3c6
PGJyPiZndDsmbmJzcDsgPGJyPiZndDsmbmJzcDsgPGJyPiZndDsgREJHKCJnb2luZyB0bzxi
cj4mZ3Q7IHNhdmUuLi4iKTsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
PGJyPiZndDsgcmV0ID08YnI+Jmd0OyBxZW11X3NhdmV2bV9zdGF0ZShmKTsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgPGJyPiZndDsgREJHKCJzYXZlIGZpbmlzaC4uLiIpOyZuYnNwOyA8YnI+Jmd0
OyZuYnNwOyA8YnI+Jmd0OyBvbmx5IHRvIHNlZSAiZ29pbmcgdG8gc2F2ZS4uLiIgYW5kICJz
YXZlIGZpbmlzaC4uLiIgaW4gdGhlIGxvZzxicj4mZ3Q7IGZpbGUsYnV0IEkgY291bGRuJ3Qg
Z2V0IHRoZSBkZWJ1ZyBvdXRwdXQgaW4gcWVtdV9zYXZldm1fc3RhdGUoZik8YnI+Jmd0OyBj
YWxsZWQgYnkgImRvX3NhdmV2bSIuIFdoeSBub3Q/PGJyPiZndDsmbmJzcDsgPGJyPjxicj5X
aGF0IGFyZSB5b3UgZXhwZWN0aW5nIHRvIHNlZT8gSWYgeW91IHdhbnQgdG8gc2VlIGRlYnVn
IG91dHB1dCBmb3I8YnI+cWVtdV9zYXZldm1fc3RhdGUoKSwgeW91IHNob3VsZCBhZGQgc29t
ZSBjb2RlIHRvIGRvIHRoYXQuPGJyPjxicj5JIGRvbid0IGZpbmQgYW55IERCRygpIGRlZmlu
aXRpb24gaW4gaW9lbXUgZGlyZWN0b3J5LiBJIGd1ZXNzIERCRygpIGlzPGJyPnlvdXIgY3Vz
dG9taXplZCB3cmFwcGVyIGFyb3VuZCBwcmludGYoKSwgc28gaXQgcHJpbnRzIHdoYXRldmVy
IHlvdSB0ZWxsPGJyPml0IHRvIHByaW50LCByaWdodD88YnI+PGJyPkFub3RoZXIgc3VnZ2Vz
dGlvbiBmb3IgeW91ciBkZWJ1Z2dpbmcgaXMgdGhhdCB5b3UgY2FuIHVzZSBnZGIgdG8gY29u
bmVjdDxicj50byBxZW11IC0tIGl0IGlzIGp1c3QgYSB1c2Vyc3BhY2UgcHJvZ3JhbS48YnI+
PGJyPjxicj5XZWkuPGJyPjxicj48YnI+PGJyPjwvZGl2PjwvaW5jbHVkZXRhaWw+PC9kaXY+


------=_NextPart_4F0183AA_087514D8_3825943B--



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

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

--===============1693476192436074240==--



From xen-devel-bounces@lists.xensource.com Mon Jan 02 10:24:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 10: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 1Rhf42-0001nt-0V; Mon, 02 Jan 2012 10:24:22 +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 1Rhf40-0001no-DJ
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 10:24:20 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325499852!9275520!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjg5MDQ2\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjg5MDQ2\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 21107 invoked from network); 2 Jan 2012 10:24:13 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-9.tower-182.messagelabs.com with SMTP;
	2 Jan 2012 10:24:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1325499849; bh=NObRUn0fy43kTO6HzyQt4A5oAO2FAAymG8iLABnDq5g=;
	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=dHNEaV7J4P0Jf269ttla0/RZfhP4/MAdYSQE7RNfNWb08KnQzmB3jBiXPRu/wmCTE
	rgA/WLtUMfLLAUnUZPjU4RDM+NuZKlrDieCrvg4CV4WkICuiBTqZyHiCmGvpyhi
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 121.18.202.140
X-QQ-STYLE: 
X-QQ-mid: webmail196t1325499847t135220
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?V2VpIExpdQ==?=" <wei.liu2@citrix.com>
Mime-Version: 1.0
Date: Mon, 2 Jan 2012 18:24:07 +0800
X-Priority: 3
Message-ID: <tencent_7939EB331BCC128C322A8229@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 2858143282
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>
Subject: [Xen-devel] =?gbk?b?u9i4tKO6ICBbaGVscF0gV2hvJ3MgdGhlIGF1dGhvciBv?=
 =?gbk?q?f_libxc=3F_I_don=27t_know_howto_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="===============1568848159106769393=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1568848159106769393==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4F0185C7_08239E10_6930A392"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4F0185C7_08239E10_6930A392
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

VGhhbmtzLg0KICAgIEkgaGF2ZSBhbHJlYWR5IHByZXZpZXdlZCB0aGUgeGVuY3RybC5oLiAN
CiAgICBUaGUgZm9sbG93aW5nIGlzIHdoYXQgSSB1bmRlcnN0YW5kOiBsaWJ4YyBpcyBjb21w
aWxlZCB0byBhIGZpbGUgbmFtZSBhZnRlciAneGMqKicgZW5kZGluZyB3aXRoICcuc28nLCB4
ZW5kIGNvbW11bmljYXRlcyB3aXRoIGRvbWFpbjAgdGhyb3VnaCB4YyBhbmQgZG9tYWluMCBj
b21tdW5pY2F0ZXMgd2l0aCBoeXBlcnZpc29yIHRocm91Z2ggcHJpdmNtZC4NCiAgICBXaGF0
J3MgdGhlIHByaXZjbWQ/DQogDQogDQotLS0tLS0tLS0tLS0tLS0tLS0g1K3KvNPKvP4gLS0t
LS0tLS0tLS0tLS0tLS0tDQq3orz+yMs6ICJXZWkgTGl1Ijx3ZWkubGl1MkBjaXRyaXguY29t
PjsNCreiy83KsbzkOiAyMDEyxOox1MIxyNUo0MfG2szsKSDN7cnPODowOQ0KytW8/sjLOiAi
oeg/S+y2YXdhcmUiPDI1MDcxNjcwOEBxcS5jb20+OyANCrOty806ICJ3ZWkubGl1MiI8d2Vp
LmxpdTJAY2l0cml4LmNvbT47ICJ4ZW4tZGV2ZWwiPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tPjsgDQrW98ziOiBSZTogW1hlbi1kZXZlbF0gW2hlbHBdIFdobydzIHRoZSBhdXRo
b3Igb2YgbGlieGM/IEkgZG9uJ3Qga25vdyBob3d0byBzdGFydCB3aXRoIGl0DQoNCiANCk9u
IFNhdCwgMjAxMS0xMi0zMSBhdCAxMTo1OCArMDAwMCwgoeg/S+y2YXdhcmUgd3JvdGU6DQo+
IEhpLA0KPiAgICAgSSB3YW5uYSB0cnkgbXkgYmVzdCB0byB1bmRlcnN0YW5kIHRoZSBsaWJ4
YyBpbiB4ZW50b29scywgYnV0IGl0J3MNCj4gZGlmZmljdWx0IGZvciBtZSwgYSBuZXdlcix0
byBjb21wcmVoZW5kIGl0J3MgcHJpbmNpcGxlIQ0KPiAgICAgQmVnZ2luZyBhZHZpY2UsdGhh
bmtzIGEgbG90IGFoZWFkIQ0KPiAgDQoNCmxpYnhjIGFjdHMgYXMgaW50ZXJtZWRpYXRlIGJl
dHdlZW4gdXNlcnNwYWNlIGFuZCBoeXBlcnZpc29yLiBJIHRoaW5rIHlvdQ0KY2FuIGZpcnN0
IHRha2UgYSBsb29rIGF0IGl0cyBleHBvcnRlZCBoZWFkZXIgZmlsZSAtLSB4ZW5jdHJsLmgg
LCBzbyB0aGF0DQp5b3UgY2FuIGhhdmUgYSByb3VnaCBpZGVhIGFib3V0IGl0cyBmdW5jdGlv
bmFsaXRpZXMuIFRoZSB5b3UgY2FuIHBpY2sNCndoYXRldmVyIGZ1bmN0aW9uYWxpdHkgeW91
IGFyZSBpbnRlcmVzdGVkIGluIGFuZCBkaWcgZGVlcGVyLg0KDQoNCldlaS4=

------=_NextPart_4F0185C7_08239E10_6930A392
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcy48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgaGF2
ZSBhbHJlYWR5IHByZXZpZXdlZCB0aGUgeGVuY3RybC5oLiA8YnI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IFRoZSBmb2xsb3dpbmcgaXMgd2hhdCBJIHVuZGVyc3RhbmQ6IGxpYnhjIGlzIGNvbXBp
bGVkIHRvIGEgZmlsZSBuYW1lIGFmdGVyICd4YyoqJyBlbmRkaW5nIHdpdGggJy5zbycsIHhl
bmQgY29tbXVuaWNhdGVzIHdpdGggZG9tYWluMCB0aHJvdWdoIHhjIGFuZCBkb21haW4wIGNv
bW11bmljYXRlcyB3aXRoIGh5cGVydmlzb3IgdGhyb3VnaCBwcml2Y21kLjxicj4mbmJzcDsm
bmJzcDsmbmJzcDsgV2hhdCdzIHRoZSBwcml2Y21kPzxicj48ZGl2PjxpbmNsdWRldGFpbD48
ZGl2PiZuYnNwOzwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0iZm9udDpWZXJk
YW5hIG5vcm1hbCAxNHB4O2NvbG9yOiMwMDA7Ij48ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEy
cHg7Rk9OVC1GQU1JTFk6IEFyaWFsIE5hcnJvdztwYWRkaW5nOjJweCAwIDJweCAwOyI+LS0t
LS0tLS0tLS0tLS0tLS0tJm5ic3A71K3KvNPKvP4mbmJzcDstLS0tLS0tLS0tLS0tLS0tLS08
L2Rpdj48ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHg7YmFja2dyb3VuZDojZWZlZmVmO3Bh
ZGRpbmc6OHB4OyI+PGRpdiBpZD0ibWVudV9zZW5kZXIiPjxiPreivP7Iyzo8L2I+Jm5ic3A7
IldlaSBMaXUiJmx0O3dlaS5saXUyQGNpdHJpeC5jb20mZ3Q7OzwvZGl2PjxkaXY+PGI+t6LL
zcqxvOQ6PC9iPiZuYnNwOzIwMTLE6jHUwjHI1SjQx8bazOwpIM3tyc84OjA5PC9kaXY+PGRp
dj48Yj7K1bz+yMs6PC9iPiZuYnNwOyKh6D9L7LZhd2FyZSImbHQ7MjUwNzE2NzA4QHFxLmNv
bSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj6zrcvNOjwvYj4mbmJzcDsid2VpLmxpdTIiJmx0
O3dlaS5saXUyQGNpdHJpeC5jb20mZ3Q7OyAieGVuLWRldmVsIiZsdDt4ZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj7W98ziOjwvYj4mbmJz
cDtSZTogW1hlbi1kZXZlbF0gW2hlbHBdIFdobydzIHRoZSBhdXRob3Igb2YgbGlieGM/IEkg
ZG9uJ3Qga25vdyBob3d0byBzdGFydCB3aXRoIGl0PC9kaXY+PC9kaXY+PGRpdj4mbmJzcDs8
L2Rpdj5PbiBTYXQsIDIwMTEtMTItMzEgYXQgMTE6NTggKzAwMDAsIKHoP0vstmF3YXJlIHdy
b3RlOjxicj4mZ3Q7IEhpLDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2Fu
bmEgdHJ5IG15IGJlc3QgdG8gdW5kZXJzdGFuZCB0aGUgbGlieGMgaW4geGVudG9vbHMsIGJ1
dCBpdCdzPGJyPiZndDsgZGlmZmljdWx0IGZvciBtZSwgYSBuZXdlcix0byBjb21wcmVoZW5k
IGl0J3MgcHJpbmNpcGxlITxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlZ2dp
bmcgYWR2aWNlLHRoYW5rcyBhIGxvdCBhaGVhZCE8YnI+Jmd0OyZuYnNwOyA8YnI+PGJyPmxp
YnhjIGFjdHMgYXMgaW50ZXJtZWRpYXRlIGJldHdlZW4gdXNlcnNwYWNlIGFuZCBoeXBlcnZp
c29yLiBJIHRoaW5rIHlvdTxicj5jYW4gZmlyc3QgdGFrZSBhIGxvb2sgYXQgaXRzIGV4cG9y
dGVkIGhlYWRlciBmaWxlIC0tIHhlbmN0cmwuaCAsIHNvIHRoYXQ8YnI+eW91IGNhbiBoYXZl
IGEgcm91Z2ggaWRlYSBhYm91dCBpdHMgZnVuY3Rpb25hbGl0aWVzLiBUaGUgeW91IGNhbiBw
aWNrPGJyPndoYXRldmVyIGZ1bmN0aW9uYWxpdHkgeW91IGFyZSBpbnRlcmVzdGVkIGluIGFu
ZCBkaWcgZGVlcGVyLjxicj48YnI+PGJyPldlaS48YnI+PGJyPjxicj48YnI+PC9kaXY+PC9p
bmNsdWRldGFpbD48L2Rpdj4=

------=_NextPart_4F0185C7_08239E10_6930A392--



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

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

--===============1568848159106769393==--



From xen-devel-bounces@lists.xensource.com Mon Jan 02 10:24:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 10: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 1Rhf42-0001nt-0V; Mon, 02 Jan 2012 10:24:22 +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 1Rhf40-0001no-DJ
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 10:24:20 +0000
X-Env-Sender: 250716708@qq.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325499852!9275520!1
X-Originating-IP: [64.71.138.43]
X-SpamReason: No, hits=2.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjg5MDQ2\n,sa_preprocessor: 
	QmFkIElQOiA2NC43MS4xMzguNDMgPT4gMjg5MDQ2\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 21107 invoked from network); 2 Jan 2012 10:24:13 -0000
Received: from smtpbg52.qq.com (HELO smtpbg52.qq.com) (64.71.138.43)
	by server-9.tower-182.messagelabs.com with SMTP;
	2 Jan 2012 10:24:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907;
	t=1325499849; bh=NObRUn0fy43kTO6HzyQt4A5oAO2FAAymG8iLABnDq5g=;
	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=dHNEaV7J4P0Jf269ttla0/RZfhP4/MAdYSQE7RNfNWb08KnQzmB3jBiXPRu/wmCTE
	rgA/WLtUMfLLAUnUZPjU4RDM+NuZKlrDieCrvg4CV4WkICuiBTqZyHiCmGvpyhi
X-QQ-SSF: 00000000000000F0000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 121.18.202.140
X-QQ-STYLE: 
X-QQ-mid: webmail196t1325499847t135220
From: "=?gbk?B?oei9S+y2YXdhcmU=?=" <250716708@qq.com>
To: "=?gbk?B?V2VpIExpdQ==?=" <wei.liu2@citrix.com>
Mime-Version: 1.0
Date: Mon, 2 Jan 2012 18:24:07 +0800
X-Priority: 3
Message-ID: <tencent_7939EB331BCC128C322A8229@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 2858143282
Cc: =?gbk?B?eGVuLWRldmVs?= <xen-devel@lists.xensource.com>
Subject: [Xen-devel] =?gbk?b?u9i4tKO6ICBbaGVscF0gV2hvJ3MgdGhlIGF1dGhvciBv?=
 =?gbk?q?f_libxc=3F_I_don=27t_know_howto_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="===============1568848159106769393=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.

--===============1568848159106769393==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_4F0185C7_08239E10_6930A392"
Content-Transfer-Encoding: 8Bit

This is a multi-part message in MIME format.

------=_NextPart_4F0185C7_08239E10_6930A392
Content-Type: text/plain;
	charset="gbk"
Content-Transfer-Encoding: base64

VGhhbmtzLg0KICAgIEkgaGF2ZSBhbHJlYWR5IHByZXZpZXdlZCB0aGUgeGVuY3RybC5oLiAN
CiAgICBUaGUgZm9sbG93aW5nIGlzIHdoYXQgSSB1bmRlcnN0YW5kOiBsaWJ4YyBpcyBjb21w
aWxlZCB0byBhIGZpbGUgbmFtZSBhZnRlciAneGMqKicgZW5kZGluZyB3aXRoICcuc28nLCB4
ZW5kIGNvbW11bmljYXRlcyB3aXRoIGRvbWFpbjAgdGhyb3VnaCB4YyBhbmQgZG9tYWluMCBj
b21tdW5pY2F0ZXMgd2l0aCBoeXBlcnZpc29yIHRocm91Z2ggcHJpdmNtZC4NCiAgICBXaGF0
J3MgdGhlIHByaXZjbWQ/DQogDQogDQotLS0tLS0tLS0tLS0tLS0tLS0g1K3KvNPKvP4gLS0t
LS0tLS0tLS0tLS0tLS0tDQq3orz+yMs6ICJXZWkgTGl1Ijx3ZWkubGl1MkBjaXRyaXguY29t
PjsNCreiy83KsbzkOiAyMDEyxOox1MIxyNUo0MfG2szsKSDN7cnPODowOQ0KytW8/sjLOiAi
oeg/S+y2YXdhcmUiPDI1MDcxNjcwOEBxcS5jb20+OyANCrOty806ICJ3ZWkubGl1MiI8d2Vp
LmxpdTJAY2l0cml4LmNvbT47ICJ4ZW4tZGV2ZWwiPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tPjsgDQrW98ziOiBSZTogW1hlbi1kZXZlbF0gW2hlbHBdIFdobydzIHRoZSBhdXRo
b3Igb2YgbGlieGM/IEkgZG9uJ3Qga25vdyBob3d0byBzdGFydCB3aXRoIGl0DQoNCiANCk9u
IFNhdCwgMjAxMS0xMi0zMSBhdCAxMTo1OCArMDAwMCwgoeg/S+y2YXdhcmUgd3JvdGU6DQo+
IEhpLA0KPiAgICAgSSB3YW5uYSB0cnkgbXkgYmVzdCB0byB1bmRlcnN0YW5kIHRoZSBsaWJ4
YyBpbiB4ZW50b29scywgYnV0IGl0J3MNCj4gZGlmZmljdWx0IGZvciBtZSwgYSBuZXdlcix0
byBjb21wcmVoZW5kIGl0J3MgcHJpbmNpcGxlIQ0KPiAgICAgQmVnZ2luZyBhZHZpY2UsdGhh
bmtzIGEgbG90IGFoZWFkIQ0KPiAgDQoNCmxpYnhjIGFjdHMgYXMgaW50ZXJtZWRpYXRlIGJl
dHdlZW4gdXNlcnNwYWNlIGFuZCBoeXBlcnZpc29yLiBJIHRoaW5rIHlvdQ0KY2FuIGZpcnN0
IHRha2UgYSBsb29rIGF0IGl0cyBleHBvcnRlZCBoZWFkZXIgZmlsZSAtLSB4ZW5jdHJsLmgg
LCBzbyB0aGF0DQp5b3UgY2FuIGhhdmUgYSByb3VnaCBpZGVhIGFib3V0IGl0cyBmdW5jdGlv
bmFsaXRpZXMuIFRoZSB5b3UgY2FuIHBpY2sNCndoYXRldmVyIGZ1bmN0aW9uYWxpdHkgeW91
IGFyZSBpbnRlcmVzdGVkIGluIGFuZCBkaWcgZGVlcGVyLg0KDQoNCldlaS4=

------=_NextPart_4F0185C7_08239E10_6930A392
Content-Type: text/html;
	charset="gbk"
Content-Transfer-Encoding: base64

Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcy48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgaGF2
ZSBhbHJlYWR5IHByZXZpZXdlZCB0aGUgeGVuY3RybC5oLiA8YnI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IFRoZSBmb2xsb3dpbmcgaXMgd2hhdCBJIHVuZGVyc3RhbmQ6IGxpYnhjIGlzIGNvbXBp
bGVkIHRvIGEgZmlsZSBuYW1lIGFmdGVyICd4YyoqJyBlbmRkaW5nIHdpdGggJy5zbycsIHhl
bmQgY29tbXVuaWNhdGVzIHdpdGggZG9tYWluMCB0aHJvdWdoIHhjIGFuZCBkb21haW4wIGNv
bW11bmljYXRlcyB3aXRoIGh5cGVydmlzb3IgdGhyb3VnaCBwcml2Y21kLjxicj4mbmJzcDsm
bmJzcDsmbmJzcDsgV2hhdCdzIHRoZSBwcml2Y21kPzxicj48ZGl2PjxpbmNsdWRldGFpbD48
ZGl2PiZuYnNwOzwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0iZm9udDpWZXJk
YW5hIG5vcm1hbCAxNHB4O2NvbG9yOiMwMDA7Ij48ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEy
cHg7Rk9OVC1GQU1JTFk6IEFyaWFsIE5hcnJvdztwYWRkaW5nOjJweCAwIDJweCAwOyI+LS0t
LS0tLS0tLS0tLS0tLS0tJm5ic3A71K3KvNPKvP4mbmJzcDstLS0tLS0tLS0tLS0tLS0tLS08
L2Rpdj48ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDEycHg7YmFja2dyb3VuZDojZWZlZmVmO3Bh
ZGRpbmc6OHB4OyI+PGRpdiBpZD0ibWVudV9zZW5kZXIiPjxiPreivP7Iyzo8L2I+Jm5ic3A7
IldlaSBMaXUiJmx0O3dlaS5saXUyQGNpdHJpeC5jb20mZ3Q7OzwvZGl2PjxkaXY+PGI+t6LL
zcqxvOQ6PC9iPiZuYnNwOzIwMTLE6jHUwjHI1SjQx8bazOwpIM3tyc84OjA5PC9kaXY+PGRp
dj48Yj7K1bz+yMs6PC9iPiZuYnNwOyKh6D9L7LZhd2FyZSImbHQ7MjUwNzE2NzA4QHFxLmNv
bSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj6zrcvNOjwvYj4mbmJzcDsid2VpLmxpdTIiJmx0
O3dlaS5saXUyQGNpdHJpeC5jb20mZ3Q7OyAieGVuLWRldmVsIiZsdDt4ZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj7W98ziOjwvYj4mbmJz
cDtSZTogW1hlbi1kZXZlbF0gW2hlbHBdIFdobydzIHRoZSBhdXRob3Igb2YgbGlieGM/IEkg
ZG9uJ3Qga25vdyBob3d0byBzdGFydCB3aXRoIGl0PC9kaXY+PC9kaXY+PGRpdj4mbmJzcDs8
L2Rpdj5PbiBTYXQsIDIwMTEtMTItMzEgYXQgMTE6NTggKzAwMDAsIKHoP0vstmF3YXJlIHdy
b3RlOjxicj4mZ3Q7IEhpLDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2Fu
bmEgdHJ5IG15IGJlc3QgdG8gdW5kZXJzdGFuZCB0aGUgbGlieGMgaW4geGVudG9vbHMsIGJ1
dCBpdCdzPGJyPiZndDsgZGlmZmljdWx0IGZvciBtZSwgYSBuZXdlcix0byBjb21wcmVoZW5k
IGl0J3MgcHJpbmNpcGxlITxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlZ2dp
bmcgYWR2aWNlLHRoYW5rcyBhIGxvdCBhaGVhZCE8YnI+Jmd0OyZuYnNwOyA8YnI+PGJyPmxp
YnhjIGFjdHMgYXMgaW50ZXJtZWRpYXRlIGJldHdlZW4gdXNlcnNwYWNlIGFuZCBoeXBlcnZp
c29yLiBJIHRoaW5rIHlvdTxicj5jYW4gZmlyc3QgdGFrZSBhIGxvb2sgYXQgaXRzIGV4cG9y
dGVkIGhlYWRlciBmaWxlIC0tIHhlbmN0cmwuaCAsIHNvIHRoYXQ8YnI+eW91IGNhbiBoYXZl
IGEgcm91Z2ggaWRlYSBhYm91dCBpdHMgZnVuY3Rpb25hbGl0aWVzLiBUaGUgeW91IGNhbiBw
aWNrPGJyPndoYXRldmVyIGZ1bmN0aW9uYWxpdHkgeW91IGFyZSBpbnRlcmVzdGVkIGluIGFu
ZCBkaWcgZGVlcGVyLjxicj48YnI+PGJyPldlaS48YnI+PGJyPjxicj48YnI+PC9kaXY+PC9p
bmNsdWRldGFpbD48L2Rpdj4=

------=_NextPart_4F0185C7_08239E10_6930A392--



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

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

--===============1568848159106769393==--



From xen-devel-bounces@lists.xensource.com Mon Jan 02 10:48:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 10: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 1RhfQf-000225-49; Mon, 02 Jan 2012 10:47: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 1RhfQd-000220-G8
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 10:47:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325501237!60856453!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 4378 invoked from network); 2 Jan 2012 10:47:18 -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;
	2 Jan 2012 10:47:18 -0000
Received: by wgbdt12 with SMTP id dt12so23508323wgb.0
	for <xen-devel@lists.xensource.com>;
	Mon, 02 Jan 2012 02:47: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:user-agent:date:from:to;
	bh=g8QTTnOy27xnhvxkfUsOe/SjFkyG6x0pbT8X2wRXRHI=;
	b=GYt5Ri/BZTg6tYI+04Yvy5kXfxrFibnS/6csvw66oRlRQXwKuNxyB2y+8Z7Ok7w+L0
	1KTIo/GOgiEkzYL2rlBEh0z9B7G6mEgEgt5HOyjrQLqe+AJEPCN39SWoQTB84Lzcwtp0
	7DYUKwYMz+K92cmGKv3qeyGH5M1TqEVKpDDVE=
Received: by 10.216.136.17 with SMTP id v17mr5438379wei.13.1325501257008;
	Mon, 02 Jan 2012 02:47:37 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id o41sm10934928wba.19.2012.01.02.02.47.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 02 Jan 2012 02:47:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bd59a07ed41187bcafc4dd5214f0744c66ef2069
Message-Id: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Mon, 02 Jan 2012 11:49:19 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1325501151 -3600
# Node ID bd59a07ed41187bcafc4dd5214f0744c66ef2069
# Parent  3e02aa9670b3265e36bdddbd4760415cd87d047b
pygrub: fix extlinux parsing

pygrub was unable to parse extlinux config files correctly, exactly
the ones like:

LABEL grsec
  KERNEL vmlinuz-3.0.10-grsec
  APPEND initrd=initramfs-3.0.10-grsec
root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
modules=sd-mod,usb-storage,ext4 xen quiet

This patch fixes it, adding a new case when parsing the "append" line,
that searches for the initrd image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3e02aa9670b3 -r bd59a07ed411 tools/pygrub/src/ExtLinuxConf.py
--- a/tools/pygrub/src/ExtLinuxConf.py	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/pygrub/src/ExtLinuxConf.py	Mon Jan 02 11:45:51 2012 +0100
@@ -60,6 +60,13 @@ class ExtLinuxImage(object):
 
                 # Bypass regular self.commands handling
                 com = None
+            elif arg.find(" "):
+                # find initrd image in append line
+                args = arg.strip().split(" ")
+                for a in args:
+                    if a.lower().startswith("initrd"):
+                        setattr(self, "initrd", a.replace("initrd=", ""))
+                        arg = arg.replace(a, "")
 
         if com is not None and self.commands.has_key(com):
             if self.commands[com] is not None:
@@ -86,10 +93,12 @@ class ExtLinuxImage(object):
         self._args = args
     def get_kernel(self):
         return self._kernel
+    def set_args(self, val):
+        self._args = val
     def get_args(self):
         return self._args
     kernel = property(get_kernel, set_kernel)
-    args = property(get_args)
+    args = property(get_args, set_args)
 
     def set_initrd(self, val):
         self._initrd = (None,val)

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 10:48:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 10: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 1RhfQf-000225-49; Mon, 02 Jan 2012 10:47: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 1RhfQd-000220-G8
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 10:47:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325501237!60856453!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 4378 invoked from network); 2 Jan 2012 10:47:18 -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;
	2 Jan 2012 10:47:18 -0000
Received: by wgbdt12 with SMTP id dt12so23508323wgb.0
	for <xen-devel@lists.xensource.com>;
	Mon, 02 Jan 2012 02:47: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:user-agent:date:from:to;
	bh=g8QTTnOy27xnhvxkfUsOe/SjFkyG6x0pbT8X2wRXRHI=;
	b=GYt5Ri/BZTg6tYI+04Yvy5kXfxrFibnS/6csvw66oRlRQXwKuNxyB2y+8Z7Ok7w+L0
	1KTIo/GOgiEkzYL2rlBEh0z9B7G6mEgEgt5HOyjrQLqe+AJEPCN39SWoQTB84Lzcwtp0
	7DYUKwYMz+K92cmGKv3qeyGH5M1TqEVKpDDVE=
Received: by 10.216.136.17 with SMTP id v17mr5438379wei.13.1325501257008;
	Mon, 02 Jan 2012 02:47:37 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id o41sm10934928wba.19.2012.01.02.02.47.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 02 Jan 2012 02:47:35 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bd59a07ed41187bcafc4dd5214f0744c66ef2069
Message-Id: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Mon, 02 Jan 2012 11:49:19 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1325501151 -3600
# Node ID bd59a07ed41187bcafc4dd5214f0744c66ef2069
# Parent  3e02aa9670b3265e36bdddbd4760415cd87d047b
pygrub: fix extlinux parsing

pygrub was unable to parse extlinux config files correctly, exactly
the ones like:

LABEL grsec
  KERNEL vmlinuz-3.0.10-grsec
  APPEND initrd=initramfs-3.0.10-grsec
root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
modules=sd-mod,usb-storage,ext4 xen quiet

This patch fixes it, adding a new case when parsing the "append" line,
that searches for the initrd image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3e02aa9670b3 -r bd59a07ed411 tools/pygrub/src/ExtLinuxConf.py
--- a/tools/pygrub/src/ExtLinuxConf.py	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/pygrub/src/ExtLinuxConf.py	Mon Jan 02 11:45:51 2012 +0100
@@ -60,6 +60,13 @@ class ExtLinuxImage(object):
 
                 # Bypass regular self.commands handling
                 com = None
+            elif arg.find(" "):
+                # find initrd image in append line
+                args = arg.strip().split(" ")
+                for a in args:
+                    if a.lower().startswith("initrd"):
+                        setattr(self, "initrd", a.replace("initrd=", ""))
+                        arg = arg.replace(a, "")
 
         if com is not None and self.commands.has_key(com):
             if self.commands[com] is not None:
@@ -86,10 +93,12 @@ class ExtLinuxImage(object):
         self._args = args
     def get_kernel(self):
         return self._kernel
+    def set_args(self, val):
+        self._args = val
     def get_args(self):
         return self._args
     kernel = property(get_kernel, set_kernel)
-    args = property(get_args)
+    args = property(get_args, set_args)
 
     def set_initrd(self, val):
         self._initrd = (None,val)

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 11:28:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 11: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 1Rhg42-0002Ie-Ca; Mon, 02 Jan 2012 11:28:26 +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 1Rhg40-0002IZ-7C
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 11:28:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325503697!7539824!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 1166 invoked from network); 2 Jan 2012 11:28:17 -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; 2 Jan 2012 11:28:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 11:28:16 +0000
Message-Id: <4F01A314020000780006A05E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 11:29:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<b70cf1dcb110f79546f3.1324639760@gran.amd.com>
In-Reply-To: <b70cf1dcb110f79546f3.1324639760@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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.

Shouldn't this be done right away when those functions/hypercalls
get introduced?

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

No new extern declarations in .c files, please.

Jan

> +
>  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 Mon Jan 02 11:28:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 11: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 1Rhg42-0002Ie-Ca; Mon, 02 Jan 2012 11:28:26 +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 1Rhg40-0002IZ-7C
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 11:28:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325503697!7539824!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 1166 invoked from network); 2 Jan 2012 11:28:17 -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; 2 Jan 2012 11:28:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 11:28:16 +0000
Message-Id: <4F01A314020000780006A05E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 11:29:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<b70cf1dcb110f79546f3.1324639760@gran.amd.com>
In-Reply-To: <b70cf1dcb110f79546f3.1324639760@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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.

Shouldn't this be done right away when those functions/hypercalls
get introduced?

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

No new extern declarations in .c files, please.

Jan

> +
>  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 Mon Jan 02 11:36:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 11: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 1RhgAm-0002TN-8h; Mon, 02 Jan 2012 11:35: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 1RhgAk-0002TD-TB
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 11:35:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325504116!7502177!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 19132 invoked from network); 2 Jan 2012 11:35: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; 2 Jan 2012 11:35:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 11:35:15 +0000
Message-Id: <4F01A4B8020000780006A07B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 11:36:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<30b1f434160d989be5e0.1324639759@gran.amd.com>
In-Reply-To: <30b1f434160d989be5e0.1324639759@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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  */

This comment suggests that the patches prior to that aren't consistent.
Is this really a proper standalone patch, or is the word "needs" too
strict, or should it really be moved ahead in the series?

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

This is being done no matter whether it actually is a v2 IOMMU that
you deal with here - if that's correct, the comment above should be
adjusted accordingly.

Jan

>      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 Mon Jan 02 11:36:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 11: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 1RhgAm-0002TN-8h; Mon, 02 Jan 2012 11:35: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 1RhgAk-0002TD-TB
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 11:35:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325504116!7502177!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 19132 invoked from network); 2 Jan 2012 11:35: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; 2 Jan 2012 11:35:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 11:35:15 +0000
Message-Id: <4F01A4B8020000780006A07B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 11:36:08 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<30b1f434160d989be5e0.1324639759@gran.amd.com>
In-Reply-To: <30b1f434160d989be5e0.1324639759@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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  */

This comment suggests that the patches prior to that aren't consistent.
Is this really a proper standalone patch, or is the word "needs" too
strict, or should it really be moved ahead in the series?

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

This is being done no matter whether it actually is a v2 IOMMU that
you deal with here - if that's correct, the comment above should be
adjusted accordingly.

Jan

>      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 Mon Jan 02 11:39:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 11:39:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhgDs-0002bv-9M; Mon, 02 Jan 2012 11:38:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RhgDq-0002bj-99
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 11:38:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325504307!7520091!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 30803 invoked from network); 2 Jan 2012 11:38:28 -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; 2 Jan 2012 11:38:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 11:38:27 +0000
Message-Id: <4F01A579020000780006A087@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 11:39:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<dd808bdd61c581b041d5.1324639758@gran.amd.com>
In-Reply-To: <dd808bdd61c581b041d5.1324639758@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1324569398 -3600
> # Node ID dd808bdd61c581b041d5b7e816b18674de51da6f
> # Parent  2329dad2786f6f20ea69c9609ab60208cad6fca9
> amd iommu: add iommu mmio handler.

This could be part of patch 3, or (perhaps better) the respective bits
should get moved here instead of adding them as dead code there.

Jan

> 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 Mon Jan 02 11:39:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 11:39:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhgDs-0002bv-9M; Mon, 02 Jan 2012 11:38:36 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RhgDq-0002bj-99
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 11:38:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325504307!7520091!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 30803 invoked from network); 2 Jan 2012 11:38:28 -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; 2 Jan 2012 11:38:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 11:38:27 +0000
Message-Id: <4F01A579020000780006A087@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 11:39:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<dd808bdd61c581b041d5.1324639758@gran.amd.com>
In-Reply-To: <dd808bdd61c581b041d5.1324639758@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1324569398 -3600
> # Node ID dd808bdd61c581b041d5b7e816b18674de51da6f
> # Parent  2329dad2786f6f20ea69c9609ab60208cad6fca9
> amd iommu: add iommu mmio handler.

This could be part of patch 3, or (perhaps better) the respective bits
should get moved here instead of adding them as dead code there.

Jan

> 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 Mon Jan 02 11:41:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 11:41:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhgGB-0002jz-H7; Mon, 02 Jan 2012 11:40:59 +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 1RhgG9-0002ja-OK
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 11:40:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325504451!7512990!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 26638 invoked from network); 2 Jan 2012 11:40:51 -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 Jan 2012 11:40:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 11:40:51 +0000
Message-Id: <4F01A608020000780006A08A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 11:41:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<2329dad2786f6f20ea69.1324639757@gran.amd.com>
In-Reply-To: <2329dad2786f6f20ea69.1324639757@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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__

As with the domctl definitions, I fail to see why this should be
excluded for IA64 - the general concept, even if not currently
implemented, is valid for any architecture that could potentially
have IOMMUs.

Jan

> +#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 Mon Jan 02 11:41:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 11:41:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhgGB-0002jz-H7; Mon, 02 Jan 2012 11:40:59 +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 1RhgG9-0002ja-OK
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 11:40:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325504451!7512990!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 26638 invoked from network); 2 Jan 2012 11:40:51 -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 Jan 2012 11:40:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 11:40:51 +0000
Message-Id: <4F01A608020000780006A08A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 11:41:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<2329dad2786f6f20ea69.1324639757@gran.amd.com>
In-Reply-To: <2329dad2786f6f20ea69.1324639757@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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__

As with the domctl definitions, I fail to see why this should be
excluded for IA64 - the general concept, even if not currently
implemented, is valid for any architecture that could potentially
have IOMMUs.

Jan

> +#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 Mon Jan 02 12:15:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 12: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 1Rhgn0-0003Ca-UD; Mon, 02 Jan 2012 12:14:54 +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 1Rhgmz-0003CV-8n
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 12:14:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325506486!9296175!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 18547 invoked from network); 2 Jan 2012 12:14:46 -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 Jan 2012 12:14:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 12:14:46 +0000
Message-Id: <4F01ADF8020000780006A0A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 12:15:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<40d61d0390ec930cf53c.1324639756@gran.amd.com>
In-Reply-To: <40d61d0390ec930cf53c.1324639756@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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__ 

While I understand your reasons for putting the #ifdef here, I would
like to see it removed in favor of a proper abstraction through vectors
in struct iommu_ops.

> +    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 */

Even without said abstraction, the conditional is pointless here, and
the comment would seem unnecessary to me.

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

For one, this would better be placed immediately after devfn (on
64-bit there's a 32-bit hole there).

Second, what about the segment number - is that one always
going to be the physical one? Or always zero?

Finally, please correct the typo ("iommu") and remove "amd" as once
again the concept ought to be generic.

Jan

>  };
>  
>  #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 Mon Jan 02 12:15:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 12: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 1Rhgn0-0003Ca-UD; Mon, 02 Jan 2012 12:14:54 +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 1Rhgmz-0003CV-8n
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 12:14:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325506486!9296175!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 18547 invoked from network); 2 Jan 2012 12:14:46 -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 Jan 2012 12:14:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 12:14:46 +0000
Message-Id: <4F01ADF8020000780006A0A1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 12:15:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<40d61d0390ec930cf53c.1324639756@gran.amd.com>
In-Reply-To: <40d61d0390ec930cf53c.1324639756@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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__ 

While I understand your reasons for putting the #ifdef here, I would
like to see it removed in favor of a proper abstraction through vectors
in struct iommu_ops.

> +    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 */

Even without said abstraction, the conditional is pointless here, and
the comment would seem unnecessary to me.

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

For one, this would better be placed immediately after devfn (on
64-bit there's a 32-bit hole there).

Second, what about the segment number - is that one always
going to be the physical one? Or always zero?

Finally, please correct the typo ("iommu") and remove "amd" as once
again the concept ought to be generic.

Jan

>  };
>  
>  #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 Mon Jan 02 12:44:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 12:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhhEw-0003Qq-Cc; Mon, 02 Jan 2012 12: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 1RhhEv-0003Ql-05
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 12:43:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325508218!1532083!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 5887 invoked from network); 2 Jan 2012 12:43:38 -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; 2 Jan 2012 12:43:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 12:43:37 +0000
Message-Id: <4F01B4BF020000780006A0BB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 12:44:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<4c986253976d7efd1964.1324639750@gran.amd.com>
In-Reply-To: <4c986253976d7efd1964.1324639750@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> --- 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
> ...
> +struct ring_buffer {
> +    void *buffer;
> +    unsigned long entries;
> +    unsigned long alloc_size;
> +    unsigned long entry_size;

I haven't been able to spot a real use of this field (throughout the
patch series).

Jan

> +    uint32_t tail;
> +    uint32_t head;
> +};
> +
>  typedef struct iommu_cap {
>      uint32_t header;                    /* offset 00h */
>      uint32_t base_low;                  /* offset 04h */



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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 12:44:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 12:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhhEw-0003Qq-Cc; Mon, 02 Jan 2012 12: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 1RhhEv-0003Ql-05
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 12:43:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325508218!1532083!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 5887 invoked from network); 2 Jan 2012 12:43:38 -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; 2 Jan 2012 12:43:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 12:43:37 +0000
Message-Id: <4F01B4BF020000780006A0BB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 12:44:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<4c986253976d7efd1964.1324639750@gran.amd.com>
In-Reply-To: <4c986253976d7efd1964.1324639750@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> --- 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
> ...
> +struct ring_buffer {
> +    void *buffer;
> +    unsigned long entries;
> +    unsigned long alloc_size;
> +    unsigned long entry_size;

I haven't been able to spot a real use of this field (throughout the
patch series).

Jan

> +    uint32_t tail;
> +    uint32_t head;
> +};
> +
>  typedef struct iommu_cap {
>      uint32_t header;                    /* offset 00h */
>      uint32_t base_low;                  /* offset 04h */



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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 12:52:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 12:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhhMf-0003bF-Cw; Mon, 02 Jan 2012 12:51:45 +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 1RhhMe-0003bA-BA
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 12:51:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1325508697!10771681!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 2822 invoked from network); 2 Jan 2012 12:51:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Jan 2012 12:51:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 12:51:37 +0000
Message-Id: <4F01B69F020000780006A0C8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 12:52:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<e15194f68f99a64b6504.1324639751@gran.amd.com>
In-Reply-To: <e15194f68f99a64b6504.1324639751@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> --- 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);
>  }
>  

Afaict with these two changes IOMMU_CMD_BUFFER_{HEAD,TAIL}_{MASK,SHIFT}
are unused, so please remove them.

> --- 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);

While I didn't check, I suspect the same applies to the old definitions
here and further down in this same file.

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

I suppose these (and the others below) really belong into
amd-iommu-defs.h?

Jan

> +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 Mon Jan 02 12:52:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 12:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhhMf-0003bF-Cw; Mon, 02 Jan 2012 12:51:45 +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 1RhhMe-0003bA-BA
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 12:51:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1325508697!10771681!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 2822 invoked from network); 2 Jan 2012 12:51:37 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 2 Jan 2012 12:51:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 12:51:37 +0000
Message-Id: <4F01B69F020000780006A0C8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 12:52:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<e15194f68f99a64b6504.1324639751@gran.amd.com>
In-Reply-To: <e15194f68f99a64b6504.1324639751@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> --- 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);
>  }
>  

Afaict with these two changes IOMMU_CMD_BUFFER_{HEAD,TAIL}_{MASK,SHIFT}
are unused, so please remove them.

> --- 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);

While I didn't check, I suspect the same applies to the old definitions
here and further down in this same file.

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

I suppose these (and the others below) really belong into
amd-iommu-defs.h?

Jan

> +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 Mon Jan 02 13:10:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 13: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 1RhheI-0003q7-3V; Mon, 02 Jan 2012 13:09:58 +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 1RhheH-0003q2-12
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 13:09:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325509789!7479935!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 29606 invoked from network); 2 Jan 2012 13:09:50 -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 Jan 2012 13:09:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 13:09:48 +0000
Message-Id: <4F01BAE2020000780006A0FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 13:10:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<33f88c76776c318eea74.1324639753@gran.amd.com>
In-Reply-To: <33f88c76776c318eea74.1324639753@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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;

The latter two should be u32.

> +    u32 power_of2_entries;
> +    u32 entry;
> +
> +    ASSERT ( iommu->ppr_log.buffer );
> +
> +    addr_64 = (u64)virt_to_maddr(iommu->ppr_log.buffer);

Pointless cast?

> +    addr_lo = addr_64 & DMA_32BIT_MASK;

DMA_32BIT_MASK is clearly not meant to be used here (and if addr_lo
was of type u32, a plain assignment would be all that's needed here).

Jan

> +    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)
>  {



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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 13:10:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 13: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 1RhheI-0003q7-3V; Mon, 02 Jan 2012 13:09:58 +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 1RhheH-0003q2-12
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 13:09:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325509789!7479935!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 29606 invoked from network); 2 Jan 2012 13:09:50 -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 Jan 2012 13:09:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 13:09:48 +0000
Message-Id: <4F01BAE2020000780006A0FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 13:10:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<33f88c76776c318eea74.1324639753@gran.amd.com>
In-Reply-To: <33f88c76776c318eea74.1324639753@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> # 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;

The latter two should be u32.

> +    u32 power_of2_entries;
> +    u32 entry;
> +
> +    ASSERT ( iommu->ppr_log.buffer );
> +
> +    addr_64 = (u64)virt_to_maddr(iommu->ppr_log.buffer);

Pointless cast?

> +    addr_lo = addr_64 & DMA_32BIT_MASK;

DMA_32BIT_MASK is clearly not meant to be used here (and if addr_lo
was of type u32, a plain assignment would be all that's needed here).

Jan

> +    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)
>  {



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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 13:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 13:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhhgU-0003v3-Sr; Mon, 02 Jan 2012 13:12:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RhhgT-0003us-It
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 13:12:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325509926!7511651!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 10542 invoked from network); 2 Jan 2012 13:12:07 -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; 2 Jan 2012 13:12:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 13:12:06 +0000
Message-Id: <4F01BB6C020000780006A0FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 13:13:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<bf9f21ad9a0ec245b409.1324639755@gran.amd.com>
In-Reply-To: <bf9f21ad9a0ec245b409.1324639755@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> --- 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
>...
>      spin_unlock_irqrestore(&iommu->lock, flags);
>  }
>  
> +void parse_ppr_log_entry(struct amd_iommu *iommu, u32 entry[])

static?

> +{
> +
> +    u16 device_id;
>...

Jan


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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 13:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 13:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhhgU-0003v3-Sr; Mon, 02 Jan 2012 13:12:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RhhgT-0003us-It
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 13:12:13 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325509926!7511651!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 10542 invoked from network); 2 Jan 2012 13:12:07 -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; 2 Jan 2012 13:12:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 13:12:06 +0000
Message-Id: <4F01BB6C020000780006A0FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 13:13:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<bf9f21ad9a0ec245b409.1324639755@gran.amd.com>
In-Reply-To: <bf9f21ad9a0ec245b409.1324639755@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> --- 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
>...
>      spin_unlock_irqrestore(&iommu->lock, flags);
>  }
>  
> +void parse_ppr_log_entry(struct amd_iommu *iommu, u32 entry[])

static?

> +{
> +
> +    u16 device_id;
>...

Jan


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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 14:23:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 14:23:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhin3-0004Ok-Io; Mon, 02 Jan 2012 14:23:05 +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 1Rhin3-0004Of-1o
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 14:23:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325514177!9324181!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 20959 invoked from network); 2 Jan 2012 14:22:58 -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; 2 Jan 2012 14:22:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 14:22:57 +0000
Message-Id: <4F01CC07020000780006A130@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 14:23: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="=__Part7C523FE7.0__="
Subject: [Xen-devel] [PATCH] PCI: shrink pci_dev_info's is_extfn/is_virtfn
	members
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

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

They are used as boolean flags only, so convert them accordingly
(shrinking the structure size by 8 bytes).

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

--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA
         if ( copy_from_guest(&manage_pci_ext, arg, 1) !=3D 0 )
             break;
=20
-        pdev_info.is_extfn =3D manage_pci_ext.is_extfn;
-        pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;
+        pdev_info.is_extfn =3D !!manage_pci_ext.is_extfn;
+        pdev_info.is_virtfn =3D !!manage_pci_ext.is_virtfn;
         pdev_info.physfn.bus =3D manage_pci_ext.physfn.bus;
         pdev_info.physfn.devfn =3D manage_pci_ext.physfn.devfn;
         ret =3D pci_add_device(0, manage_pci_ext.bus,
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -33,8 +33,8 @@
 #define MAX_MSIX_TABLE_ENTRIES  2048
 #define MAX_MSIX_TABLE_PAGES    8
 struct pci_dev_info {
-    unsigned is_extfn;
-    unsigned is_virtfn;
+    bool_t is_extfn;
+    bool_t is_virtfn;
     struct {
         u8 bus;
         u8 devfn;




--=__Part7C523FE7.0__=
Content-Type: text/plain; name="squeeze-pci_dev_info.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="squeeze-pci_dev_info.patch"

PCI: shrink pci_dev_info's is_extfn/is_virtfn members=0A=0AThey are used =
as boolean flags only, so convert them accordingly=0A(shrinking the =
structure size by 8 bytes).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.=
com>=0A=0A--- a/xen/arch/ia64/xen/hypercall.c=0A+++ b/xen/arch/ia64/xen/hyp=
ercall.c=0A@@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA=0A =
        if ( copy_from_guest(&manage_pci_ext, arg, 1) !=3D 0 )=0A          =
   break;=0A =0A-        pdev_info.is_extfn =3D manage_pci_ext.is_extfn;=0A=
-        pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;=0A+        =
pdev_info.is_extfn =3D !!manage_pci_ext.is_extfn;=0A+        pdev_info.is_v=
irtfn =3D !!manage_pci_ext.is_virtfn;=0A         pdev_info.physfn.bus =3D =
manage_pci_ext.physfn.bus;=0A         pdev_info.physfn.devfn =3D manage_pci=
_ext.physfn.devfn;=0A         ret =3D pci_add_device(0, manage_pci_ext.bus,=
=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@@ -33,8 =
+33,8 @@=0A #define MAX_MSIX_TABLE_ENTRIES  2048=0A #define MAX_MSIX_TABLE_=
PAGES    8=0A struct pci_dev_info {=0A-    unsigned is_extfn;=0A-    =
unsigned is_virtfn;=0A+    bool_t is_extfn;=0A+    bool_t is_virtfn;=0A    =
 struct {=0A         u8 bus;=0A         u8 devfn;=0A
--=__Part7C523FE7.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

--=__Part7C523FE7.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 14:23:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 14:23:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhin3-0004Ok-Io; Mon, 02 Jan 2012 14:23:05 +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 1Rhin3-0004Of-1o
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 14:23:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325514177!9324181!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 20959 invoked from network); 2 Jan 2012 14:22:58 -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; 2 Jan 2012 14:22:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 14:22:57 +0000
Message-Id: <4F01CC07020000780006A130@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 14:23: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="=__Part7C523FE7.0__="
Subject: [Xen-devel] [PATCH] PCI: shrink pci_dev_info's is_extfn/is_virtfn
	members
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

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

They are used as boolean flags only, so convert them accordingly
(shrinking the structure size by 8 bytes).

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

--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA
         if ( copy_from_guest(&manage_pci_ext, arg, 1) !=3D 0 )
             break;
=20
-        pdev_info.is_extfn =3D manage_pci_ext.is_extfn;
-        pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;
+        pdev_info.is_extfn =3D !!manage_pci_ext.is_extfn;
+        pdev_info.is_virtfn =3D !!manage_pci_ext.is_virtfn;
         pdev_info.physfn.bus =3D manage_pci_ext.physfn.bus;
         pdev_info.physfn.devfn =3D manage_pci_ext.physfn.devfn;
         ret =3D pci_add_device(0, manage_pci_ext.bus,
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -33,8 +33,8 @@
 #define MAX_MSIX_TABLE_ENTRIES  2048
 #define MAX_MSIX_TABLE_PAGES    8
 struct pci_dev_info {
-    unsigned is_extfn;
-    unsigned is_virtfn;
+    bool_t is_extfn;
+    bool_t is_virtfn;
     struct {
         u8 bus;
         u8 devfn;




--=__Part7C523FE7.0__=
Content-Type: text/plain; name="squeeze-pci_dev_info.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="squeeze-pci_dev_info.patch"

PCI: shrink pci_dev_info's is_extfn/is_virtfn members=0A=0AThey are used =
as boolean flags only, so convert them accordingly=0A(shrinking the =
structure size by 8 bytes).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.=
com>=0A=0A--- a/xen/arch/ia64/xen/hypercall.c=0A+++ b/xen/arch/ia64/xen/hyp=
ercall.c=0A@@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA=0A =
        if ( copy_from_guest(&manage_pci_ext, arg, 1) !=3D 0 )=0A          =
   break;=0A =0A-        pdev_info.is_extfn =3D manage_pci_ext.is_extfn;=0A=
-        pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;=0A+        =
pdev_info.is_extfn =3D !!manage_pci_ext.is_extfn;=0A+        pdev_info.is_v=
irtfn =3D !!manage_pci_ext.is_virtfn;=0A         pdev_info.physfn.bus =3D =
manage_pci_ext.physfn.bus;=0A         pdev_info.physfn.devfn =3D manage_pci=
_ext.physfn.devfn;=0A         ret =3D pci_add_device(0, manage_pci_ext.bus,=
=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@@ -33,8 =
+33,8 @@=0A #define MAX_MSIX_TABLE_ENTRIES  2048=0A #define MAX_MSIX_TABLE_=
PAGES    8=0A struct pci_dev_info {=0A-    unsigned is_extfn;=0A-    =
unsigned is_virtfn;=0A+    bool_t is_extfn;=0A+    bool_t is_virtfn;=0A    =
 struct {=0A         u8 bus;=0A         u8 devfn;=0A
--=__Part7C523FE7.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

--=__Part7C523FE7.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 14:30:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 14:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhitI-0004cC-KP; Mon, 02 Jan 2012 14:29:32 +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 1RhitG-0004by-Hp
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 14:29:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325514563!9300323!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 29288 invoked from network); 2 Jan 2012 14:29:23 -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 Jan 2012 14:29:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 14:29:23 +0000
Message-Id: <4F01CD88020000780006A13C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 14:30:16 +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="=__PartF1DFB268.0__="
Subject: [Xen-devel] [PATCH] PCI: properly abstract out per-architecture
 extensions to struct pci_dev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

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

x86's used_vectors member was both misplaced (in struct pci_dev_info,
which acts as a hypercall input data passing container only) and
improperly abstracted (requiring a CONFIG_X86 conditional in a generic
header).

The adjustment requires hiding several more lines in IA64's pci.h, but
as a benefit this allows removing one of the "null" headers.

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

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1877,7 +1877,7 @@ int map_domain_pirq(
         if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV
              && !desc->arch.used_vectors )
         {
-            desc->arch.used_vectors =3D &pdev->info.used_vectors;
+            desc->arch.used_vectors =3D &pdev->arch.used_vectors;
             if ( desc->arch.vector !=3D IRQ_VECTOR_UNASSIGNED )
             {
                 int vector =3D desc->arch.vector;
--- a/xen/include/asm-ia64/linux-null/asm-generic/pci-dma-compat.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is intentionally left empty. */
--- a/xen/include/asm-ia64/linux-xen/asm/pci.h
+++ b/xen/include/asm-ia64/linux-xen/asm/pci.h
@@ -28,6 +28,10 @@ void pcibios_config_init(void);
=20
 struct pci_dev;
=20
+#ifdef XEN
+struct arch_pci_dev {};
+#endif
+
 /*
  * PCI_DMA_BUS_IS_PHYS should be set to 1 if there is _necessarily_ a =
direct correspondence
  * between device bus addresses and CPU physical addresses.  Platforms =
with a hardware I/O
@@ -43,6 +47,7 @@ struct pci_dev;
 extern unsigned long ia64_max_iommu_merge_mask;
 #define PCI_DMA_BUS_IS_PHYS	(ia64_max_iommu_merge_mask =3D=3D ~0UL)
=20
+#ifndef XEN
 static inline void
 pcibios_set_master (struct pci_dev *dev)
 {
@@ -110,7 +115,6 @@ extern int pci_mmap_page_range (struct p
 #define HAVE_PCI_LEGACY
 extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
 				      struct vm_area_struct *vma);
-#ifndef XEN
 extern ssize_t pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t =
off,
 				  size_t count);
 extern ssize_t pci_write_legacy_io(struct kobject *kobj, char *buf, =
loff_t off,
@@ -144,6 +148,7 @@ struct pci_controller {
 #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)=

 #define pci_domain_nr(busdev)    (PCI_CONTROLLER(busdev)->segment)
=20
+#ifndef XEN
 extern struct pci_ops pci_root_ops;
=20
 static inline int pci_proc_domain(struct pci_bus *bus)
@@ -161,7 +166,6 @@ extern void pcibios_resource_to_bus(stru
 extern void pcibios_bus_to_resource(struct pci_dev *dev,
 		struct resource *res, struct pci_bus_region *region);
=20
-#ifndef XEN
 static inline struct resource *
 pcibios_select_root(struct pci_dev *pdev, struct resource *res)
 {
--- /dev/null
+++ b/xen/include/asm-x86/pci.h
@@ -0,0 +1,8 @@
+#ifndef __X86_PCI_H__
+#define __X86_PCI_H__
+
+struct arch_pci_dev {
+    vmask_t used_vectors;
+};
+
+#endif /* __X86_PCI_H__ */
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -12,6 +12,7 @@
 #include <xen/list.h>
 #include <xen/spinlock.h>
 #include <xen/irq.h>
+#include <asm/pci.h>
=20
 /*
  * The PCI interface treats multi-function devices as independent
@@ -39,9 +40,6 @@ struct pci_dev_info {
         u8 bus;
         u8 devfn;
     } physfn;
-#ifdef CONFIG_X86
-    vmask_t used_vectors;
-#endif
 };
=20
 struct pci_dev {
@@ -62,6 +60,7 @@ struct pci_dev {
     const u8 bus;
     const u8 devfn;
     struct pci_dev_info info;
+    struct arch_pci_dev arch;
     u64 vf_rlen[6];
 };
=20




--=__PartF1DFB268.0__=
Content-Type: text/plain; name="arch-pci_dev.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arch-pci_dev.patch"

PCI: properly abstract out per-architecture extensions to struct pci_dev=0A=
=0Ax86's used_vectors member was both misplaced (in struct pci_dev_info,=0A=
which acts as a hypercall input data passing container only) and=0Aimproper=
ly abstracted (requiring a CONFIG_X86 conditional in a generic=0Aheader).=
=0A=0AThe adjustment requires hiding several more lines in IA64's pci.h, =
but=0Aas a benefit this allows removing one of the "null" headers.=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/irq.c=
=0A+++ b/xen/arch/x86/irq.c=0A@@ -1877,7 +1877,7 @@ int map_domain_pirq(=0A=
         if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV=0A       =
       && !desc->arch.used_vectors )=0A         {=0A-            desc->arch=
.used_vectors =3D &pdev->info.used_vectors;=0A+            desc->arch.used_=
vectors =3D &pdev->arch.used_vectors;=0A             if ( desc->arch.vector=
 !=3D IRQ_VECTOR_UNASSIGNED )=0A             {=0A                 int =
vector =3D desc->arch.vector;=0A--- a/xen/include/asm-ia64/linux-null/asm-g=
eneric/pci-dma-compat.h=0A+++ /dev/null=0A@@ -1 +0,0 @@=0A-/* This file is =
intentionally left empty. */=0A--- a/xen/include/asm-ia64/linux-xen/asm/pci=
.h=0A+++ b/xen/include/asm-ia64/linux-xen/asm/pci.h=0A@@ -28,6 +28,10 @@ =
void pcibios_config_init(void);=0A =0A struct pci_dev;=0A =0A+#ifdef =
XEN=0A+struct arch_pci_dev {};=0A+#endif=0A+=0A /*=0A  * PCI_DMA_BUS_IS_PHY=
S should be set to 1 if there is _necessarily_ a direct correspondence=0A  =
* between device bus addresses and CPU physical addresses.  Platforms with =
a hardware I/O=0A@@ -43,6 +47,7 @@ struct pci_dev;=0A extern unsigned long =
ia64_max_iommu_merge_mask;=0A #define PCI_DMA_BUS_IS_PHYS	(ia64_max_i=
ommu_merge_mask =3D=3D ~0UL)=0A =0A+#ifndef XEN=0A static inline void=0A =
pcibios_set_master (struct pci_dev *dev)=0A {=0A@@ -110,7 +115,6 @@ extern =
int pci_mmap_page_range (struct p=0A #define HAVE_PCI_LEGACY=0A extern int =
pci_mmap_legacy_page_range(struct pci_bus *bus,=0A 				=
      struct vm_area_struct *vma);=0A-#ifndef XEN=0A extern ssize_t =
pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t off,=0A 		=
		  size_t count);=0A extern ssize_t pci_write_legacy_io(stru=
ct kobject *kobj, char *buf, loff_t off,=0A@@ -144,6 +148,7 @@ struct =
pci_controller {=0A #define PCI_CONTROLLER(busdev) ((struct pci_controller =
*) busdev->sysdata)=0A #define pci_domain_nr(busdev)    (PCI_CONTROLLER(bus=
dev)->segment)=0A =0A+#ifndef XEN=0A extern struct pci_ops pci_root_ops;=0A=
 =0A static inline int pci_proc_domain(struct pci_bus *bus)=0A@@ -161,7 =
+166,6 @@ extern void pcibios_resource_to_bus(stru=0A extern void =
pcibios_bus_to_resource(struct pci_dev *dev,=0A 		struct =
resource *res, struct pci_bus_region *region);=0A =0A-#ifndef XEN=0A =
static inline struct resource *=0A pcibios_select_root(struct pci_dev =
*pdev, struct resource *res)=0A {=0A--- /dev/null=0A+++ b/xen/include/asm-x=
86/pci.h=0A@@ -0,0 +1,8 @@=0A+#ifndef __X86_PCI_H__=0A+#define __X86_PCI_H_=
_=0A+=0A+struct arch_pci_dev {=0A+    vmask_t used_vectors;=0A+};=0A+=0A+#e=
ndif /* __X86_PCI_H__ */=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/=
xen/pci.h=0A@@ -12,6 +12,7 @@=0A #include <xen/list.h>=0A #include =
<xen/spinlock.h>=0A #include <xen/irq.h>=0A+#include <asm/pci.h>=0A =0A =
/*=0A  * The PCI interface treats multi-function devices as independent=0A@=
@ -39,9 +40,6 @@ struct pci_dev_info {=0A         u8 bus;=0A         u8 =
devfn;=0A     } physfn;=0A-#ifdef CONFIG_X86=0A-    vmask_t used_vectors;=
=0A-#endif=0A };=0A =0A struct pci_dev {=0A@@ -62,6 +60,7 @@ struct =
pci_dev {=0A     const u8 bus;=0A     const u8 devfn;=0A     struct =
pci_dev_info info;=0A+    struct arch_pci_dev arch;=0A     u64 vf_rlen[6];=
=0A };=0A =0A
--=__PartF1DFB268.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

--=__PartF1DFB268.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 14:30:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 14:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhitI-0004cC-KP; Mon, 02 Jan 2012 14:29:32 +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 1RhitG-0004by-Hp
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 14:29:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325514563!9300323!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 29288 invoked from network); 2 Jan 2012 14:29:23 -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 Jan 2012 14:29:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 14:29:23 +0000
Message-Id: <4F01CD88020000780006A13C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 14:30:16 +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="=__PartF1DFB268.0__="
Subject: [Xen-devel] [PATCH] PCI: properly abstract out per-architecture
 extensions to struct pci_dev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

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

x86's used_vectors member was both misplaced (in struct pci_dev_info,
which acts as a hypercall input data passing container only) and
improperly abstracted (requiring a CONFIG_X86 conditional in a generic
header).

The adjustment requires hiding several more lines in IA64's pci.h, but
as a benefit this allows removing one of the "null" headers.

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

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1877,7 +1877,7 @@ int map_domain_pirq(
         if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV
              && !desc->arch.used_vectors )
         {
-            desc->arch.used_vectors =3D &pdev->info.used_vectors;
+            desc->arch.used_vectors =3D &pdev->arch.used_vectors;
             if ( desc->arch.vector !=3D IRQ_VECTOR_UNASSIGNED )
             {
                 int vector =3D desc->arch.vector;
--- a/xen/include/asm-ia64/linux-null/asm-generic/pci-dma-compat.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is intentionally left empty. */
--- a/xen/include/asm-ia64/linux-xen/asm/pci.h
+++ b/xen/include/asm-ia64/linux-xen/asm/pci.h
@@ -28,6 +28,10 @@ void pcibios_config_init(void);
=20
 struct pci_dev;
=20
+#ifdef XEN
+struct arch_pci_dev {};
+#endif
+
 /*
  * PCI_DMA_BUS_IS_PHYS should be set to 1 if there is _necessarily_ a =
direct correspondence
  * between device bus addresses and CPU physical addresses.  Platforms =
with a hardware I/O
@@ -43,6 +47,7 @@ struct pci_dev;
 extern unsigned long ia64_max_iommu_merge_mask;
 #define PCI_DMA_BUS_IS_PHYS	(ia64_max_iommu_merge_mask =3D=3D ~0UL)
=20
+#ifndef XEN
 static inline void
 pcibios_set_master (struct pci_dev *dev)
 {
@@ -110,7 +115,6 @@ extern int pci_mmap_page_range (struct p
 #define HAVE_PCI_LEGACY
 extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
 				      struct vm_area_struct *vma);
-#ifndef XEN
 extern ssize_t pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t =
off,
 				  size_t count);
 extern ssize_t pci_write_legacy_io(struct kobject *kobj, char *buf, =
loff_t off,
@@ -144,6 +148,7 @@ struct pci_controller {
 #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)=

 #define pci_domain_nr(busdev)    (PCI_CONTROLLER(busdev)->segment)
=20
+#ifndef XEN
 extern struct pci_ops pci_root_ops;
=20
 static inline int pci_proc_domain(struct pci_bus *bus)
@@ -161,7 +166,6 @@ extern void pcibios_resource_to_bus(stru
 extern void pcibios_bus_to_resource(struct pci_dev *dev,
 		struct resource *res, struct pci_bus_region *region);
=20
-#ifndef XEN
 static inline struct resource *
 pcibios_select_root(struct pci_dev *pdev, struct resource *res)
 {
--- /dev/null
+++ b/xen/include/asm-x86/pci.h
@@ -0,0 +1,8 @@
+#ifndef __X86_PCI_H__
+#define __X86_PCI_H__
+
+struct arch_pci_dev {
+    vmask_t used_vectors;
+};
+
+#endif /* __X86_PCI_H__ */
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -12,6 +12,7 @@
 #include <xen/list.h>
 #include <xen/spinlock.h>
 #include <xen/irq.h>
+#include <asm/pci.h>
=20
 /*
  * The PCI interface treats multi-function devices as independent
@@ -39,9 +40,6 @@ struct pci_dev_info {
         u8 bus;
         u8 devfn;
     } physfn;
-#ifdef CONFIG_X86
-    vmask_t used_vectors;
-#endif
 };
=20
 struct pci_dev {
@@ -62,6 +60,7 @@ struct pci_dev {
     const u8 bus;
     const u8 devfn;
     struct pci_dev_info info;
+    struct arch_pci_dev arch;
     u64 vf_rlen[6];
 };
=20




--=__PartF1DFB268.0__=
Content-Type: text/plain; name="arch-pci_dev.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arch-pci_dev.patch"

PCI: properly abstract out per-architecture extensions to struct pci_dev=0A=
=0Ax86's used_vectors member was both misplaced (in struct pci_dev_info,=0A=
which acts as a hypercall input data passing container only) and=0Aimproper=
ly abstracted (requiring a CONFIG_X86 conditional in a generic=0Aheader).=
=0A=0AThe adjustment requires hiding several more lines in IA64's pci.h, =
but=0Aas a benefit this allows removing one of the "null" headers.=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/irq.c=
=0A+++ b/xen/arch/x86/irq.c=0A@@ -1877,7 +1877,7 @@ int map_domain_pirq(=0A=
         if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV=0A       =
       && !desc->arch.used_vectors )=0A         {=0A-            desc->arch=
.used_vectors =3D &pdev->info.used_vectors;=0A+            desc->arch.used_=
vectors =3D &pdev->arch.used_vectors;=0A             if ( desc->arch.vector=
 !=3D IRQ_VECTOR_UNASSIGNED )=0A             {=0A                 int =
vector =3D desc->arch.vector;=0A--- a/xen/include/asm-ia64/linux-null/asm-g=
eneric/pci-dma-compat.h=0A+++ /dev/null=0A@@ -1 +0,0 @@=0A-/* This file is =
intentionally left empty. */=0A--- a/xen/include/asm-ia64/linux-xen/asm/pci=
.h=0A+++ b/xen/include/asm-ia64/linux-xen/asm/pci.h=0A@@ -28,6 +28,10 @@ =
void pcibios_config_init(void);=0A =0A struct pci_dev;=0A =0A+#ifdef =
XEN=0A+struct arch_pci_dev {};=0A+#endif=0A+=0A /*=0A  * PCI_DMA_BUS_IS_PHY=
S should be set to 1 if there is _necessarily_ a direct correspondence=0A  =
* between device bus addresses and CPU physical addresses.  Platforms with =
a hardware I/O=0A@@ -43,6 +47,7 @@ struct pci_dev;=0A extern unsigned long =
ia64_max_iommu_merge_mask;=0A #define PCI_DMA_BUS_IS_PHYS	(ia64_max_i=
ommu_merge_mask =3D=3D ~0UL)=0A =0A+#ifndef XEN=0A static inline void=0A =
pcibios_set_master (struct pci_dev *dev)=0A {=0A@@ -110,7 +115,6 @@ extern =
int pci_mmap_page_range (struct p=0A #define HAVE_PCI_LEGACY=0A extern int =
pci_mmap_legacy_page_range(struct pci_bus *bus,=0A 				=
      struct vm_area_struct *vma);=0A-#ifndef XEN=0A extern ssize_t =
pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t off,=0A 		=
		  size_t count);=0A extern ssize_t pci_write_legacy_io(stru=
ct kobject *kobj, char *buf, loff_t off,=0A@@ -144,6 +148,7 @@ struct =
pci_controller {=0A #define PCI_CONTROLLER(busdev) ((struct pci_controller =
*) busdev->sysdata)=0A #define pci_domain_nr(busdev)    (PCI_CONTROLLER(bus=
dev)->segment)=0A =0A+#ifndef XEN=0A extern struct pci_ops pci_root_ops;=0A=
 =0A static inline int pci_proc_domain(struct pci_bus *bus)=0A@@ -161,7 =
+166,6 @@ extern void pcibios_resource_to_bus(stru=0A extern void =
pcibios_bus_to_resource(struct pci_dev *dev,=0A 		struct =
resource *res, struct pci_bus_region *region);=0A =0A-#ifndef XEN=0A =
static inline struct resource *=0A pcibios_select_root(struct pci_dev =
*pdev, struct resource *res)=0A {=0A--- /dev/null=0A+++ b/xen/include/asm-x=
86/pci.h=0A@@ -0,0 +1,8 @@=0A+#ifndef __X86_PCI_H__=0A+#define __X86_PCI_H_=
_=0A+=0A+struct arch_pci_dev {=0A+    vmask_t used_vectors;=0A+};=0A+=0A+#e=
ndif /* __X86_PCI_H__ */=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/=
xen/pci.h=0A@@ -12,6 +12,7 @@=0A #include <xen/list.h>=0A #include =
<xen/spinlock.h>=0A #include <xen/irq.h>=0A+#include <asm/pci.h>=0A =0A =
/*=0A  * The PCI interface treats multi-function devices as independent=0A@=
@ -39,9 +40,6 @@ struct pci_dev_info {=0A         u8 bus;=0A         u8 =
devfn;=0A     } physfn;=0A-#ifdef CONFIG_X86=0A-    vmask_t used_vectors;=
=0A-#endif=0A };=0A =0A struct pci_dev {=0A@@ -62,6 +60,7 @@ struct =
pci_dev {=0A     const u8 bus;=0A     const u8 devfn;=0A     struct =
pci_dev_info info;=0A+    struct arch_pci_dev arch;=0A     u64 vf_rlen[6];=
=0A };=0A =0A
--=__PartF1DFB268.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

--=__PartF1DFB268.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 14:50:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 14: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 1RhjCb-0004o8-Jg; Mon, 02 Jan 2012 14:49:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RhjCZ-0004o3-NU
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 14:49:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325515760!7340355!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 17252 invoked from network); 2 Jan 2012 14:49:20 -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; 2 Jan 2012 14:49:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 14:49:20 +0000
Message-Id: <4F01D236020000780006A153@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 14:50:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <20111209.192439.275865894437319638.davem@davemloft.net>
	<1323604139-3890-1-git-send-email-lersek@redhat.com>
In-Reply-To: <1323604139-3890-1-git-send-email-lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [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>
Content-Type: text/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.12.11 at 12:48, Laszlo Ersek <lersek@redhat.com> wrote:
> 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/netbac
> k-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>

Wouldn't all of this equally apply to the 2.6.18 kernel and its derivates?

Jan

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




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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 14:50:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 14: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 1RhjCb-0004o8-Jg; Mon, 02 Jan 2012 14:49:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RhjCZ-0004o3-NU
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 14:49:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325515760!7340355!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 17252 invoked from network); 2 Jan 2012 14:49:20 -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; 2 Jan 2012 14:49:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 14:49:20 +0000
Message-Id: <4F01D236020000780006A153@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 14:50:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <20111209.192439.275865894437319638.davem@davemloft.net>
	<1323604139-3890-1-git-send-email-lersek@redhat.com>
In-Reply-To: <1323604139-3890-1-git-send-email-lersek@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [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>
Content-Type: text/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.12.11 at 12:48, Laszlo Ersek <lersek@redhat.com> wrote:
> 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/netbac
> k-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>

Wouldn't all of this equally apply to the 2.6.18 kernel and its derivates?

Jan

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




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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 15:02:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 15: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 1RhjOk-0005Jd-9d; Mon, 02 Jan 2012 15:02:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RhjOh-0005JU-GM
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 15:01:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325516513!9426390!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA0NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2156 invoked from network); 2 Jan 2012 15:01:53 -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;
	2 Jan 2012 15:01:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,444,1320624000"; 
   d="scan'208";a="9777403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 15:01:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Jan 2012 15:01: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 1RhjOa-0007k8-VP;
	Mon, 02 Jan 2012 15:01:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhjOa-0002Ni-PY;
	Mon, 02 Jan 2012 15:01:52 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10622-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Jan 2012 15:01:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10622: 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 10622 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10622/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pv            16 guest-start.2                fail   like 10619
 test-amd64-amd64-pv          16 guest-start.2                fail   like 10619
 test-amd64-i386-pv           16 guest-start.2                fail   like 10621

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

version targeted for testing:
 xen                  3a22ed3ec534
baseline version:
 xen                  a7b2610b8e5c

------------------------------------------------------------
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>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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                                            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:   24448:3a22ed3ec534
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 02 09:26:19 2012 +0100
    
    x86/passthrough: don't leak guest IRQs
    
    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>
    
    
changeset:   24447:a7b2610b8e5c
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>
    
    
========================================
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 Mon Jan 02 15:02:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 15: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 1RhjOk-0005Jd-9d; Mon, 02 Jan 2012 15:02:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RhjOh-0005JU-GM
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 15:01:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325516513!9426390!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA0NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2156 invoked from network); 2 Jan 2012 15:01:53 -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;
	2 Jan 2012 15:01:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,444,1320624000"; 
   d="scan'208";a="9777403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 15:01:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Jan 2012 15:01: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 1RhjOa-0007k8-VP;
	Mon, 02 Jan 2012 15:01:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhjOa-0002Ni-PY;
	Mon, 02 Jan 2012 15:01:52 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10622-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Jan 2012 15:01:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10622: 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 10622 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10622/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-pv            16 guest-start.2                fail   like 10619
 test-amd64-amd64-pv          16 guest-start.2                fail   like 10619
 test-amd64-i386-pv           16 guest-start.2                fail   like 10621

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

version targeted for testing:
 xen                  3a22ed3ec534
baseline version:
 xen                  a7b2610b8e5c

------------------------------------------------------------
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>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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                                            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:   24448:3a22ed3ec534
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 02 09:26:19 2012 +0100
    
    x86/passthrough: don't leak guest IRQs
    
    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>
    
    
changeset:   24447:a7b2610b8e5c
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>
    
    
========================================
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 Mon Jan 02 16:07:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 16:07:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhkPQ-0006gH-Mv; Mon, 02 Jan 2012 16:06:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RhkPO-0006g0-SG
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 16:06:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325520400!1551309!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjAzNzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjAzNzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8306 invoked from network); 2 Jan 2012 16:06:40 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Jan 2012 16:06:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325520399; l=2272;
	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=DJyMf5KWwEMx3SITvRLacWcnhMI=;
	b=ymJ69a8W22+gQWhF1Ac5Y6vOhUP/+AOkv+4UCj9+QrgOEWpffJyUnbh/c6+FdyQgQLl
	LBn3qffW4N7uiuiuz9vKfhQuzut8LfqEgJjdhczI4bPOSpH/0FMKsA4OxUSNlqdv3mKdm
	0fe6ucrPjnfNdB6AXHO4yM9E+IgS7UG6OUc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PEPbU
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-131.pools.arcor-ip.net [88.65.93.131])
	by smtp.strato.de (klopstock mo3) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id g066a9o02EKJG6 ;
	Mon, 2 Jan 2012 17:06:12 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 27ACF18637; Mon,  2 Jan 2012 17:06:12 +0100 (CET)
Date: Mon, 2 Jan 2012 17:06:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120102160611.GB12529@aepfle.de>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111217143015.GD14816@konrad-lan>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, 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 Sat, Dec 17, Konrad Rzeszutek Wilk wrote:

> > +#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?

I dont remember why I turned this into a macro instead of 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.

A multiline macro needs backslashes at the end.

> So why msleep? Why not go for a proper yield? Call the safe_halt()
> function?

It needs some interuptible sleep, whatever is best in this context.

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

Or if something in the paging paths goes wrong.

> I would recommend you use 'WARN' here and include tons of details.
> This is a pretty serious issues, is it not?

Either the host is really busy and cant page-in quick enough even after
so-many seconds. Or something in the pager/hypervisor does not work
right. In either case, a backtrace wont help much as it does only cause
noise. The printk below prints the function name (I think thats the
reason why it is a macro) to give some hint. 

> > +		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" ?

The caller has to deal with the various !GNTST_okay states anyway, this
patch wont change that fact.

Olaf

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 16:07:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 16:07:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhkPQ-0006gH-Mv; Mon, 02 Jan 2012 16:06:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RhkPO-0006g0-SG
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 16:06:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325520400!1551309!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjAzNzc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjAzNzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8306 invoked from network); 2 Jan 2012 16:06:40 -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 EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Jan 2012 16:06:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325520399; l=2272;
	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=DJyMf5KWwEMx3SITvRLacWcnhMI=;
	b=ymJ69a8W22+gQWhF1Ac5Y6vOhUP/+AOkv+4UCj9+QrgOEWpffJyUnbh/c6+FdyQgQLl
	LBn3qffW4N7uiuiuz9vKfhQuzut8LfqEgJjdhczI4bPOSpH/0FMKsA4OxUSNlqdv3mKdm
	0fe6ucrPjnfNdB6AXHO4yM9E+IgS7UG6OUc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PEPbU
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-131.pools.arcor-ip.net [88.65.93.131])
	by smtp.strato.de (klopstock mo3) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id g066a9o02EKJG6 ;
	Mon, 2 Jan 2012 17:06:12 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 27ACF18637; Mon,  2 Jan 2012 17:06:12 +0100 (CET)
Date: Mon, 2 Jan 2012 17:06:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120102160611.GB12529@aepfle.de>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111217143015.GD14816@konrad-lan>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, 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 Sat, Dec 17, Konrad Rzeszutek Wilk wrote:

> > +#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?

I dont remember why I turned this into a macro instead of 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.

A multiline macro needs backslashes at the end.

> So why msleep? Why not go for a proper yield? Call the safe_halt()
> function?

It needs some interuptible sleep, whatever is best in this context.

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

Or if something in the paging paths goes wrong.

> I would recommend you use 'WARN' here and include tons of details.
> This is a pretty serious issues, is it not?

Either the host is really busy and cant page-in quick enough even after
so-many seconds. Or something in the pager/hypervisor does not work
right. In either case, a backtrace wont help much as it does only cause
noise. The printk below prints the function name (I think thats the
reason why it is a macro) to give some hint. 

> > +		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" ?

The caller has to deal with the various !GNTST_okay states anyway, this
patch wont change that fact.

Olaf

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhkPy-0006iY-4n; Mon, 02 Jan 2012 16:07:22 +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 1RhkPw-0006hx-A2
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 16:07:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325520433!9866971!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzMTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzMTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2432 invoked from network); 2 Jan 2012 16:07:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Jan 2012 16:07:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325520433; l=392;
	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=0O83zL0+gepvy0n91xl4YGfrSAo=;
	b=pcRkyDFXAwdwMwatIIun3dvwI7qqFOldjmK985tOujeV4ybLwXqo46ax/YuXjlGdeNf
	1g1sU+EQCXDsqXQUp3vNj6G18h2mAO+UfusGCqt8jpPKwWEqTz8tcNQOTpW0XJd7Dxcz2
	Ihimyb+qHYecEYo06ZVM+Sfj1Pg3ClQWR1k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PEPbU
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-131.pools.arcor-ip.net [88.65.93.131])
	by smtp.strato.de (fruni mo58) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p057f2o02G0ojP ;
	Mon, 2 Jan 2012 17:06:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 586F618637; Mon,  2 Jan 2012 17:06:50 +0100 (CET)
Date: Mon, 2 Jan 2012 17:06:50 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20120102160650.GC12529@aepfle.de>
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.21.rev5535 (2011-07-01)
Cc: konrad@darnok.org, andres@gridcentric.ca, xen-devel@lists.xensource.com,
	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, 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.

Adin,

thanks for doing this work.

Olaf

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 16:07:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 16:07:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhkPy-0006iY-4n; Mon, 02 Jan 2012 16:07:22 +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 1RhkPw-0006hx-A2
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 16:07:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325520433!9866971!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzMTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzMTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2432 invoked from network); 2 Jan 2012 16:07:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 2 Jan 2012 16:07:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325520433; l=392;
	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=0O83zL0+gepvy0n91xl4YGfrSAo=;
	b=pcRkyDFXAwdwMwatIIun3dvwI7qqFOldjmK985tOujeV4ybLwXqo46ax/YuXjlGdeNf
	1g1sU+EQCXDsqXQUp3vNj6G18h2mAO+UfusGCqt8jpPKwWEqTz8tcNQOTpW0XJd7Dxcz2
	Ihimyb+qHYecEYo06ZVM+Sfj1Pg3ClQWR1k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PEPbU
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-131.pools.arcor-ip.net [88.65.93.131])
	by smtp.strato.de (fruni mo58) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p057f2o02G0ojP ;
	Mon, 2 Jan 2012 17:06:51 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 586F618637; Mon,  2 Jan 2012 17:06:50 +0100 (CET)
Date: Mon, 2 Jan 2012 17:06:50 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20120102160650.GC12529@aepfle.de>
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.21.rev5535 (2011-07-01)
Cc: konrad@darnok.org, andres@gridcentric.ca, xen-devel@lists.xensource.com,
	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, 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.

Adin,

thanks for doing this work.

Olaf

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 16:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 16:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhki6-0007Aw-4s; Mon, 02 Jan 2012 16:26:06 +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 1Rhki4-0007Ar-MC
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 16:26:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325521558!10102299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA0NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27853 invoked from network); 2 Jan 2012 16:25:58 -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;
	2 Jan 2012 16:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,445,1320624000"; 
   d="scan'208";a="9778664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 16:25:57 +0000
Received: from liuw-desktop (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Jan 2012
	16:25:56 +0000
Date: Mon, 2 Jan 2012 16:25:03 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: =?utf-8?B?wqTntYLmlrxhd2FyZQ==?= <250716708@qq.com>
Message-ID: <20120102162503.GB31013@liuw-desktop>
References: <tencent_7939EB331BCC128C322A8229@qq.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tencent_7939EB331BCC128C322A8229@qq.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] =?utf-8?b?5Zue5aSN77yaICBbaGVscF0gV2hvJ3MgdGhlIGF1?=
 =?utf-8?q?thor_of_libxc=3F_I_don=27t_know_howto_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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

UGxlYXNlIGRvbid0IHRvcC1wb3N0aW5nLgoKQW5kIEkgc3Ryb25nbHkgcmVjb21tZW5kIHlvdSB1
c2UgR21haWwgKG9yIG90aGVyIHByb3BlciBtYWlsIGNsaWVudHMpLApiZWNhdXNlIFFRbWFpbCBt
ZXNzZXMgdXAgdGhyZWFkcy4KCk9uIE1vbiwgSmFuIDAyLCAyMDEyIGF0IDEwOjI0OjA3QU0gKzAw
MDAsIMKk57WC5pa8YXdhcmUgd3JvdGU6Cj4gICAgIFRoYW5rcy4KPiAgICAgSSBoYXZlIGFscmVh
ZHkgcHJldmlld2VkIHRoZSB4ZW5jdHJsLmguCj4gICAgIFRoZSBmb2xsb3dpbmcgaXMgd2hhdCBJ
IHVuZGVyc3RhbmQ6IGxpYnhjIGlzIGNvbXBpbGVkIHRvIGEgZmlsZSBuYW1lIGFmdGVyICd4Yyoq
JyBlbmRkaW5nIHdpdGggJy5zbycsIHhlbmQgY29tbXVuaWNhdGVzIHdpdGggZG9tYWluMCB0aHJv
dWdoIHhjIGFuZCBkb21haW4wIGNvbW11bmljYXRlcyB3aXRoIGh5cGVydmlzb3IgdGhyb3VnaCBw
cml2Y21kLgoKbGlieGMgaXMgbm90IGEgc3RhbmRhbG9uZSBwcm9ncmFtIHlvdSBjYW4gY2FsbC4g
eGVuZCBoYXMgYSBweXRob24KbW9kdWxlIHRvIGV4cG9zZSBsaWJ4YyBmdW5jdGlvbmFsaXRpZXMg
dG8gcHl0aG9uLgoKSWYgeW91IGFyZSB1c2luZyBuZXdlciB4ZW4sIHlvdSBwcm9iYWJseSB3YW50
IHRvIGNoYW5nZSB0byB4bAp0b29sc3RhY2suCgo+ICAgICBXaGF0J3MgdGhlIHByaXZjbWQ/Cj4g
CgpJdCBpcyBzaG9ydCBmb3IgInByaXZpbGVnZWQgY29tbWFuZCIgSSB0aGluay4gSXQgaXMgdGhl
IGVudHJ5IHBvaW50IHRvCmtlcm5lbCBzcGFjZSB3aGVuIHlvdSB3YW50IHRvIGlzc3VlIGEgaHlw
ZXJjYWxsLgoKCldlaS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 02 16:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 16:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhki6-0007Aw-4s; Mon, 02 Jan 2012 16:26:06 +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 1Rhki4-0007Ar-MC
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 16:26:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325521558!10102299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA0NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27853 invoked from network); 2 Jan 2012 16:25:58 -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;
	2 Jan 2012 16:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,445,1320624000"; 
   d="scan'208";a="9778664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 16:25:57 +0000
Received: from liuw-desktop (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 2 Jan 2012
	16:25:56 +0000
Date: Mon, 2 Jan 2012 16:25:03 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: =?utf-8?B?wqTntYLmlrxhd2FyZQ==?= <250716708@qq.com>
Message-ID: <20120102162503.GB31013@liuw-desktop>
References: <tencent_7939EB331BCC128C322A8229@qq.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tencent_7939EB331BCC128C322A8229@qq.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] =?utf-8?b?5Zue5aSN77yaICBbaGVscF0gV2hvJ3MgdGhlIGF1?=
 =?utf-8?q?thor_of_libxc=3F_I_don=27t_know_howto_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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

UGxlYXNlIGRvbid0IHRvcC1wb3N0aW5nLgoKQW5kIEkgc3Ryb25nbHkgcmVjb21tZW5kIHlvdSB1
c2UgR21haWwgKG9yIG90aGVyIHByb3BlciBtYWlsIGNsaWVudHMpLApiZWNhdXNlIFFRbWFpbCBt
ZXNzZXMgdXAgdGhyZWFkcy4KCk9uIE1vbiwgSmFuIDAyLCAyMDEyIGF0IDEwOjI0OjA3QU0gKzAw
MDAsIMKk57WC5pa8YXdhcmUgd3JvdGU6Cj4gICAgIFRoYW5rcy4KPiAgICAgSSBoYXZlIGFscmVh
ZHkgcHJldmlld2VkIHRoZSB4ZW5jdHJsLmguCj4gICAgIFRoZSBmb2xsb3dpbmcgaXMgd2hhdCBJ
IHVuZGVyc3RhbmQ6IGxpYnhjIGlzIGNvbXBpbGVkIHRvIGEgZmlsZSBuYW1lIGFmdGVyICd4Yyoq
JyBlbmRkaW5nIHdpdGggJy5zbycsIHhlbmQgY29tbXVuaWNhdGVzIHdpdGggZG9tYWluMCB0aHJv
dWdoIHhjIGFuZCBkb21haW4wIGNvbW11bmljYXRlcyB3aXRoIGh5cGVydmlzb3IgdGhyb3VnaCBw
cml2Y21kLgoKbGlieGMgaXMgbm90IGEgc3RhbmRhbG9uZSBwcm9ncmFtIHlvdSBjYW4gY2FsbC4g
eGVuZCBoYXMgYSBweXRob24KbW9kdWxlIHRvIGV4cG9zZSBsaWJ4YyBmdW5jdGlvbmFsaXRpZXMg
dG8gcHl0aG9uLgoKSWYgeW91IGFyZSB1c2luZyBuZXdlciB4ZW4sIHlvdSBwcm9iYWJseSB3YW50
IHRvIGNoYW5nZSB0byB4bAp0b29sc3RhY2suCgo+ICAgICBXaGF0J3MgdGhlIHByaXZjbWQ/Cj4g
CgpJdCBpcyBzaG9ydCBmb3IgInByaXZpbGVnZWQgY29tbWFuZCIgSSB0aGluay4gSXQgaXMgdGhl
IGVudHJ5IHBvaW50IHRvCmtlcm5lbCBzcGFjZSB3aGVuIHlvdSB3YW50IHRvIGlzc3VlIGEgaHlw
ZXJjYWxsLgoKCldlaS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 02 16:53:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 16:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhl84-0007QT-Dt; Mon, 02 Jan 2012 16:52:56 +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 1Rhl82-0007QO-36
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 16:52:54 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325523166!7567704!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 930 invoked from network); 2 Jan 2012 16:52:47 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	2 Jan 2012 16:52:47 -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 q02GqjnU004645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Jan 2012 11:52:45 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q02Gqhf2010090; Mon, 2 Jan 2012 11:52:44 -0500
Message-ID: <4F01E135.9060201@redhat.com>
Date: Mon, 02 Jan 2012 17:54:13 +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: <20111209.192439.275865894437319638.davem@davemloft.net>
	<1323604139-3890-1-git-send-email-lersek@redhat.com>
	<4F01D236020000780006A153@nat28.tlf.novell.com>
In-Reply-To: <4F01D236020000780006A153@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02/12 15:50, Jan Beulich wrote:

> Wouldn't all of this equally apply to the 2.6.18 kernel and its derivates?

I haven't checked the linux-2.6.18-xen.hg source at all before because 
the (first) affected RHEL-5 netfront patch 
("linux-2.6-xen-xennet-coordinate-ARP-with-backend-network-status.patch") states,

     The frontend part of the patch is not applicable in upstream
     Linux as there is no gratuitous ARP packet support there at all.
     While the backend upstream is dead as far as I know.  So this
     is RHEL5-specific.

Regarding the RHEL-5 host side,

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

 >> Sub-condition (1) is already satisfied by commit f942dc2552b8 in
 >> Linus' tree, based on commit 6b0b80ca7165 from [1].

 >> [1] 
git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history

I figured the backend change is "already upstream". (Actually where I 
took it from was 43223efd9bfd in Jeremy's tree.)

So, what do you want me to do? I think I could get the frontend patch 
right without compiling linux-2.6.18-xen.hg. The backend is more messy 
however.

Thanks
Laszlo

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 16:53:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 16:53:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhl84-0007QT-Dt; Mon, 02 Jan 2012 16:52:56 +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 1Rhl82-0007QO-36
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 16:52:54 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325523166!7567704!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 930 invoked from network); 2 Jan 2012 16:52:47 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	2 Jan 2012 16:52:47 -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 q02GqjnU004645
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Jan 2012 11:52:45 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q02Gqhf2010090; Mon, 2 Jan 2012 11:52:44 -0500
Message-ID: <4F01E135.9060201@redhat.com>
Date: Mon, 02 Jan 2012 17:54:13 +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: <20111209.192439.275865894437319638.davem@davemloft.net>
	<1323604139-3890-1-git-send-email-lersek@redhat.com>
	<4F01D236020000780006A153@nat28.tlf.novell.com>
In-Reply-To: <4F01D236020000780006A153@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02/12 15:50, Jan Beulich wrote:

> Wouldn't all of this equally apply to the 2.6.18 kernel and its derivates?

I haven't checked the linux-2.6.18-xen.hg source at all before because 
the (first) affected RHEL-5 netfront patch 
("linux-2.6-xen-xennet-coordinate-ARP-with-backend-network-status.patch") states,

     The frontend part of the patch is not applicable in upstream
     Linux as there is no gratuitous ARP packet support there at all.
     While the backend upstream is dead as far as I know.  So this
     is RHEL5-specific.

Regarding the RHEL-5 host side,

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

 >> Sub-condition (1) is already satisfied by commit f942dc2552b8 in
 >> Linus' tree, based on commit 6b0b80ca7165 from [1].

 >> [1] 
git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-history

I figured the backend change is "already upstream". (Actually where I 
took it from was 43223efd9bfd in Jeremy's tree.)

So, what do you want me to do? I think I could get the frontend patch 
right without compiling linux-2.6.18-xen.hg. The backend is more messy 
however.

Thanks
Laszlo

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 17:04:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 17: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 1RhlIv-0007fP-JF; Mon, 02 Jan 2012 17:04:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RhlIu-0007fK-Sm
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 17:04:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325523842!9871297!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 25852 invoked from network); 2 Jan 2012 17:04:02 -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; 2 Jan 2012 17:04:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 17:04:02 +0000
Message-Id: <4F01F1BC020000780006A1A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 17:04:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <20111209.192439.275865894437319638.davem@davemloft.net>
	<1323604139-3890-1-git-send-email-lersek@redhat.com>
	<4F01D236020000780006A153@nat28.tlf.novell.com>
	<4F01E135.9060201@redhat.com>
In-Reply-To: <4F01E135.9060201@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [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>
Content-Type: text/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.01.12 at 17:54, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/02/12 15:50, Jan Beulich wrote:
> 
>> Wouldn't all of this equally apply to the 2.6.18 kernel and its derivates?
> 
> I haven't checked the linux-2.6.18-xen.hg source at all before because 
> the (first) affected RHEL-5 netfront patch 
> ("linux-2.6-xen-xennet-coordinate-ARP-with-backend-network-status.patch") states,
> 
>      The frontend part of the patch is not applicable in upstream
>      Linux as there is no gratuitous ARP packet support there at all.
>      While the backend upstream is dead as far as I know.  So this
>      is RHEL5-specific.
> 
> Regarding the RHEL-5 host side,
> 
>  >> (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
> 
>  >> Sub-condition (1) is already satisfied by commit f942dc2552b8 in
>  >> Linus' tree, based on commit 6b0b80ca7165 from [1].
> 
>  >> [1] 
> git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-
> history
> 
> I figured the backend change is "already upstream". (Actually where I 
> took it from was 43223efd9bfd in Jeremy's tree.)
> 
> So, what do you want me to do? I think I could get the frontend patch 
> right without compiling linux-2.6.18-xen.hg. The backend is more messy 
> however.

I've got both backend and frontend changes ready for that tree - all I
was really after was some double checking that both changes logically
apply to that tree.

Jan


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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 17:04:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 17: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 1RhlIv-0007fP-JF; Mon, 02 Jan 2012 17:04:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RhlIu-0007fK-Sm
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 17:04:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325523842!9871297!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 25852 invoked from network); 2 Jan 2012 17:04:02 -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; 2 Jan 2012 17:04:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 02 Jan 2012 17:04:02 +0000
Message-Id: <4F01F1BC020000780006A1A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 02 Jan 2012 17:04:44 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <20111209.192439.275865894437319638.davem@davemloft.net>
	<1323604139-3890-1-git-send-email-lersek@redhat.com>
	<4F01D236020000780006A153@nat28.tlf.novell.com>
	<4F01E135.9060201@redhat.com>
In-Reply-To: <4F01E135.9060201@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [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>
Content-Type: text/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.01.12 at 17:54, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/02/12 15:50, Jan Beulich wrote:
> 
>> Wouldn't all of this equally apply to the 2.6.18 kernel and its derivates?
> 
> I haven't checked the linux-2.6.18-xen.hg source at all before because 
> the (first) affected RHEL-5 netfront patch 
> ("linux-2.6-xen-xennet-coordinate-ARP-with-backend-network-status.patch") states,
> 
>      The frontend part of the patch is not applicable in upstream
>      Linux as there is no gratuitous ARP packet support there at all.
>      While the backend upstream is dead as far as I know.  So this
>      is RHEL5-specific.
> 
> Regarding the RHEL-5 host side,
> 
>  >> (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
> 
>  >> Sub-condition (1) is already satisfied by commit f942dc2552b8 in
>  >> Linus' tree, based on commit 6b0b80ca7165 from [1].
> 
>  >> [1] 
> git://xenbits.xen.org/people/ianc/linux-2.6.git#upstream/dom0/backend/netback-
> history
> 
> I figured the backend change is "already upstream". (Actually where I 
> took it from was 43223efd9bfd in Jeremy's tree.)
> 
> So, what do you want me to do? I think I could get the frontend patch 
> right without compiling linux-2.6.18-xen.hg. The backend is more messy 
> however.

I've got both backend and frontend changes ready for that tree - all I
was really after was some double checking that both changes logically
apply to that tree.

Jan


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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 17:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 17: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 1RhlRi-0007pW-KJ; Mon, 02 Jan 2012 17:13:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RhlRh-0007pO-2C
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 17:13:13 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325524386!2009516!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 27797 invoked from network); 2 Jan 2012 17:13:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	2 Jan 2012 17:13: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 q02HD4aJ021997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Jan 2012 12:13:04 -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 q02HD34U017343; Mon, 2 Jan 2012 12:13:03 -0500
Message-ID: <4F01E5F9.8060006@redhat.com>
Date: Mon, 02 Jan 2012 18:14:33 +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: <20111209.192439.275865894437319638.davem@davemloft.net>
	<1323604139-3890-1-git-send-email-lersek@redhat.com>
	<4F01D236020000780006A153@nat28.tlf.novell.com>
	<4F01E135.9060201@redhat.com>
	<4F01F1BC020000780006A1A8@nat28.tlf.novell.com>
In-Reply-To: <4F01F1BC020000780006A1A8@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02/12 18:04, Jan Beulich wrote:

> I've got both backend and frontend changes ready for that tree - all I
> was really after was some double checking that both changes logically
> apply to that tree.

I think (hope :)) so. In the RHEL-5 kernel they seem to work together fine.

Thanks
Laszlo

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 17:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 17: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 1RhlRi-0007pW-KJ; Mon, 02 Jan 2012 17:13:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RhlRh-0007pO-2C
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 17:13:13 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325524386!2009516!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 27797 invoked from network); 2 Jan 2012 17:13:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	2 Jan 2012 17:13: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 q02HD4aJ021997
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 2 Jan 2012 12:13:04 -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 q02HD34U017343; Mon, 2 Jan 2012 12:13:03 -0500
Message-ID: <4F01E5F9.8060006@redhat.com>
Date: Mon, 02 Jan 2012 18:14:33 +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: <20111209.192439.275865894437319638.davem@davemloft.net>
	<1323604139-3890-1-git-send-email-lersek@redhat.com>
	<4F01D236020000780006A153@nat28.tlf.novell.com>
	<4F01E135.9060201@redhat.com>
	<4F01F1BC020000780006A1A8@nat28.tlf.novell.com>
In-Reply-To: <4F01F1BC020000780006A1A8@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/02/12 18:04, Jan Beulich wrote:

> I've got both backend and frontend changes ready for that tree - all I
> was really after was some double checking that both changes logically
> apply to that tree.

I think (hope :)) so. In the RHEL-5 kernel they seem to work together fine.

Thanks
Laszlo

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 17:17:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 17: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 1RhlVN-0007xP-CN; Mon, 02 Jan 2012 17:17:01 +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 1RhlVL-0007x5-QS
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 17:17:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325524613!9309308!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzMTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzMTQ=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5211 invoked from network); 2 Jan 2012 17:16:53 -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; 2 Jan 2012 17:16:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325524612; l=1129;
	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=V+4Im2OYmt87GE04LCKYpvD68as=;
	b=d/uMbceJrREMbrE7Y2uMooDAp9lvtXGen/PEQ0yWFXkt/aqm+hcMQV1IaT0jTtvfQfo
	D9mUDLoaLH8ZC+ZYFFvwrEhfITzn48aLnZGej0MvaHQTfpnsNknrYbchHwqFJPdTKwbH3
	S6vMlPfpv634AiEsKKY3qG3Jpnie/TmuIVw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PEPbU
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-131.pools.arcor-ip.net [88.65.93.131])
	by post.strato.de (mrclete mo36) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x01766o02F4Okp ;
	Mon, 2 Jan 2012 18:16:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BAB7E18637; Mon,  2 Jan 2012 18:16:31 +0100 (CET)
Date: Mon, 2 Jan 2012 18:16:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120102171631.GA13603@aepfle.de>
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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324412394.8252.163.camel@dagon.hellion.org.uk>
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>,
	Ian Jackson <Ian.Jackson@eu.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, Ian Campbell wrote:

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


If you could come up with a patch to present xenstored (or other
dom0/toolstack) features, that would be great.

Olaf

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 17:17:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 17: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 1RhlVN-0007xP-CN; Mon, 02 Jan 2012 17:17:01 +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 1RhlVL-0007x5-QS
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 17:17:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325524613!9309308!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzMTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzMTQ=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5211 invoked from network); 2 Jan 2012 17:16:53 -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; 2 Jan 2012 17:16:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325524612; l=1129;
	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=V+4Im2OYmt87GE04LCKYpvD68as=;
	b=d/uMbceJrREMbrE7Y2uMooDAp9lvtXGen/PEQ0yWFXkt/aqm+hcMQV1IaT0jTtvfQfo
	D9mUDLoaLH8ZC+ZYFFvwrEhfITzn48aLnZGej0MvaHQTfpnsNknrYbchHwqFJPdTKwbH3
	S6vMlPfpv634AiEsKKY3qG3Jpnie/TmuIVw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHjS0PEPbU
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-093-131.pools.arcor-ip.net [88.65.93.131])
	by post.strato.de (mrclete mo36) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x01766o02F4Okp ;
	Mon, 2 Jan 2012 18:16:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id BAB7E18637; Mon,  2 Jan 2012 18:16:31 +0100 (CET)
Date: Mon, 2 Jan 2012 18:16:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120102171631.GA13603@aepfle.de>
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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324412394.8252.163.camel@dagon.hellion.org.uk>
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>,
	Ian Jackson <Ian.Jackson@eu.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, Ian Campbell wrote:

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


If you could come up with a patch to present xenstored (or other
dom0/toolstack) features, that would be great.

Olaf

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

From xen-devel-bounces@lists.xensource.com Mon Jan 02 17:43:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 17:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhluB-0008F3-Rx; Mon, 02 Jan 2012 17:42:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nupurghatnekar@gmail.com>)
	id 1Rhlu9-0008Ev-Vc; Mon, 02 Jan 2012 17:42:38 +0000
X-Env-Sender: nupurghatnekar@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325526131!51266854!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10525 invoked from network); 2 Jan 2012 17:42:11 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jan 2012 17:42:11 -0000
Received: by wico1 with SMTP id o1so24733205wic.30
	for <multiple recipients>; Mon, 02 Jan 2012 09:42:31 -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=uYmGqZMPT38xE3mqLQuxlmmexhxmDlONGpnoX5/V6r4=;
	b=SaBjKtuF7bE/kg6W9whNCnaQ1lNWkLcskfzRFNnCS9i++pMCkpeGsFb43rYc92QSua
	flpIEf0T3LrQ9ngFpXVS1lH776eH643rFHuwcf991CEDrLr8yxXGPhEf15JX8MMuJlTP
	ugcUoDrFPzizfHwywCwEk6iY6545I7FvqU1b0=
MIME-Version: 1.0
Received: by 10.181.13.179 with SMTP id ez19mr107509363wid.11.1325526150887;
	Mon, 02 Jan 2012 09:42:30 -0800 (PST)
Received: by 10.180.106.195 with HTTP; Mon, 2 Jan 2012 09:42:30 -0800 (PST)
Date: Mon, 2 Jan 2012 23:12:30 +0530
Message-ID: <CAO8_4Vo3PwKyc0DPg7djDTN9C5XiSzoQVrFU+X8Sem0_yn=mfQ@mail.gmail.com>
From: Nupur Ghatnekar <nupurghatnekar@gmail.com>
To: xen-users@lists.xensource.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] Installing Xen on 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="===============0765402019293809434=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0765402019293809434==
Content-Type: multipart/alternative; boundary=f46d043d66d95d37a304b58f1bc0

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

Hi all,

I have been trying to install xen on ubuntu 11.10.
I am following the steps given in this blog.
http://www.beyondlinux.com/2011/11/02/install-xen-4-1-and-setup-your-cloud-os-on-ubuntu-11-10/


Though, after the first 1 step, when I reboot. I do not have a Xen entry to
boot into. It still shows the same grub entry.

Any suggestions.

-- 

Nupur Ghatnekar

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

<div>Hi all,</div><div><br></div>I have been trying to install xen on ubunt=
u 11.10.<div>I am following the steps given in this blog.=C2=A0
<a href=3D"http://www.beyondlinux.com/2011/11/02/install-xen-4-1-and-setup-=
your-cloud-os-on-ubuntu-11-10/">http://www.beyondlinux.com/2011/11/02/insta=
ll-xen-4-1-and-setup-your-cloud-os-on-ubuntu-11-10/</a>=C2=A0</div><div><br=
></div>
<div>Though, after the first 1 step, when I reboot. I do not have a Xen ent=
ry to boot into. It still shows the same grub entry.</div><div><br></div><d=
iv>Any suggestions.<br clear=3D"all"><div><br></div>-- <br><br>Nupur Ghatne=
kar<br>

</div>

--f46d043d66d95d37a304b58f1bc0--


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

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

--===============0765402019293809434==--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 17:43:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 17:43:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhluB-0008F3-Rx; Mon, 02 Jan 2012 17:42:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nupurghatnekar@gmail.com>)
	id 1Rhlu9-0008Ev-Vc; Mon, 02 Jan 2012 17:42:38 +0000
X-Env-Sender: nupurghatnekar@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325526131!51266854!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10525 invoked from network); 2 Jan 2012 17:42:11 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	2 Jan 2012 17:42:11 -0000
Received: by wico1 with SMTP id o1so24733205wic.30
	for <multiple recipients>; Mon, 02 Jan 2012 09:42:31 -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=uYmGqZMPT38xE3mqLQuxlmmexhxmDlONGpnoX5/V6r4=;
	b=SaBjKtuF7bE/kg6W9whNCnaQ1lNWkLcskfzRFNnCS9i++pMCkpeGsFb43rYc92QSua
	flpIEf0T3LrQ9ngFpXVS1lH776eH643rFHuwcf991CEDrLr8yxXGPhEf15JX8MMuJlTP
	ugcUoDrFPzizfHwywCwEk6iY6545I7FvqU1b0=
MIME-Version: 1.0
Received: by 10.181.13.179 with SMTP id ez19mr107509363wid.11.1325526150887;
	Mon, 02 Jan 2012 09:42:30 -0800 (PST)
Received: by 10.180.106.195 with HTTP; Mon, 2 Jan 2012 09:42:30 -0800 (PST)
Date: Mon, 2 Jan 2012 23:12:30 +0530
Message-ID: <CAO8_4Vo3PwKyc0DPg7djDTN9C5XiSzoQVrFU+X8Sem0_yn=mfQ@mail.gmail.com>
From: Nupur Ghatnekar <nupurghatnekar@gmail.com>
To: xen-users@lists.xensource.com, xen-devel@lists.xensource.com
Subject: [Xen-devel] Installing Xen on 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="===============0765402019293809434=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0765402019293809434==
Content-Type: multipart/alternative; boundary=f46d043d66d95d37a304b58f1bc0

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

Hi all,

I have been trying to install xen on ubuntu 11.10.
I am following the steps given in this blog.
http://www.beyondlinux.com/2011/11/02/install-xen-4-1-and-setup-your-cloud-os-on-ubuntu-11-10/


Though, after the first 1 step, when I reboot. I do not have a Xen entry to
boot into. It still shows the same grub entry.

Any suggestions.

-- 

Nupur Ghatnekar

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

<div>Hi all,</div><div><br></div>I have been trying to install xen on ubunt=
u 11.10.<div>I am following the steps given in this blog.=C2=A0
<a href=3D"http://www.beyondlinux.com/2011/11/02/install-xen-4-1-and-setup-=
your-cloud-os-on-ubuntu-11-10/">http://www.beyondlinux.com/2011/11/02/insta=
ll-xen-4-1-and-setup-your-cloud-os-on-ubuntu-11-10/</a>=C2=A0</div><div><br=
></div>
<div>Though, after the first 1 step, when I reboot. I do not have a Xen ent=
ry to boot into. It still shows the same grub entry.</div><div><br></div><d=
iv>Any suggestions.<br clear=3D"all"><div><br></div>-- <br><br>Nupur Ghatne=
kar<br>

</div>

--f46d043d66d95d37a304b58f1bc0--


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

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

--===============0765402019293809434==--


From xen-devel-bounces@lists.xensource.com Mon Jan 02 18:10:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 18:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhmKM-0000S7-S2; Mon, 02 Jan 2012 18:09:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RhmKK-0000S2-S9
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 18:09:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325527736!48761443!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA0NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18386 invoked from network); 2 Jan 2012 18:08: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;
	2 Jan 2012 18:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,445,1320624000"; 
   d="scan'208";a="9779443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 18:09: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; Mon, 2 Jan 2012 18:09: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 1RhmKJ-0000MZ-6E;
	Mon, 02 Jan 2012 18:09:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhmKJ-0001de-3F;
	Mon, 02 Jan 2012 18:09:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10623-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Jan 2012 18:09:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10623: 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 10623 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10623/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu 16 guest-start.2             fail REGR. vs. 10621

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv          16 guest-start.2                fail   like 10619
 test-amd64-i386-pv           16 guest-start.2                fail   like 10621
 test-amd64-amd64-xl-sedf      5 xen-boot                     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-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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  a7b2610b8e5c

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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                                          fail    
 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:   24450:50117a4d1a2c
tag:         tip
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:43:07 2012 +0000
    
    x86/tboot: fix some coding style issues in tboot.c
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Acked-by:  Joseph Cihula <joseph.cihula@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24449:fb1bd2a4ccab
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:42:15 2012 +0000
    
    Update the maitainer list for Intel(R) TXT
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    
    
changeset:   24448:3a22ed3ec534
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 02 09:26:19 2012 +0100
    
    x86/passthrough: don't leak guest IRQs
    
    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>
    
    
changeset:   24447:a7b2610b8e5c
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>
    
    
========================================
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 Mon Jan 02 18:10:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 18:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhmKM-0000S7-S2; Mon, 02 Jan 2012 18:09:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RhmKK-0000S2-S9
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 18:09:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325527736!48761443!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA0NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18386 invoked from network); 2 Jan 2012 18:08: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;
	2 Jan 2012 18:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,445,1320624000"; 
   d="scan'208";a="9779443"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 18:09: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; Mon, 2 Jan 2012 18:09: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 1RhmKJ-0000MZ-6E;
	Mon, 02 Jan 2012 18:09:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhmKJ-0001de-3F;
	Mon, 02 Jan 2012 18:09:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10623-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Jan 2012 18:09:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10623: 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 10623 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10623/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu 16 guest-start.2             fail REGR. vs. 10621

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv          16 guest-start.2                fail   like 10619
 test-amd64-i386-pv           16 guest-start.2                fail   like 10621
 test-amd64-amd64-xl-sedf      5 xen-boot                     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-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-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  a7b2610b8e5c

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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                                          fail    
 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:   24450:50117a4d1a2c
tag:         tip
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:43:07 2012 +0000
    
    x86/tboot: fix some coding style issues in tboot.c
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Acked-by:  Joseph Cihula <joseph.cihula@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24449:fb1bd2a4ccab
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:42:15 2012 +0000
    
    Update the maitainer list for Intel(R) TXT
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    
    
changeset:   24448:3a22ed3ec534
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 02 09:26:19 2012 +0100
    
    x86/passthrough: don't leak guest IRQs
    
    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>
    
    
changeset:   24447:a7b2610b8e5c
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>
    
    
========================================
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 Mon Jan 02 18:10:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 18:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhmKV-0000T7-Dl; Mon, 02 Jan 2012 18:09:51 +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 1RhmKU-0000SU-KY; Mon, 02 Jan 2012 18:09:50 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325527784!9270533!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 16897 invoked from network); 2 Jan 2012 18:09:44 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-182.messagelabs.com with SMTP;
	2 Jan 2012 18:09:44 -0000
Received: from p5b2e37e1.dip.t-dialin.net ([91.46.55.225] 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 1RhmKO-0005Oy-Ed; Mon, 02 Jan 2012 18:09:44 +0000
Message-ID: <4F01F2E6.6070803@canonical.com>
Date: Mon, 02 Jan 2012 19:09:42 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
References: <CAO8_4Vo3PwKyc0DPg7djDTN9C5XiSzoQVrFU+X8Sem0_yn=mfQ@mail.gmail.com>
In-Reply-To: <CAO8_4Vo3PwKyc0DPg7djDTN9C5XiSzoQVrFU+X8Sem0_yn=mfQ@mail.gmail.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] Installing Xen on 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 02.01.2012 18:42, Nupur Ghatnekar wrote:
> Hi all,
> 
> I have been trying to install xen on ubuntu 11.10.
> I am following the steps given in this blog.
> http://www.beyondlinux.com/2011/11/02/install-xen-4-1-and-setup-your-cloud-os-on-ubuntu-11-10/
> 
> 
> Though, after the first 1 step, when I reboot. I do not have a Xen entry to
> boot into. It still shows the same grub entry.
> 
> Any suggestions.
> 

I assume you base installation is ubuntu-server (that is the way I had it done).
The grub entry may be a bit hidden. It becomes a kernel under a heading like
"Xen 4.1-amd64". When that is selected, there will be the kernel choices.
Or for some reason update-grub was not run as it should have. Would running
"sudo update-grub" help?

-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 Mon Jan 02 18:10:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 18:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhmKV-0000T7-Dl; Mon, 02 Jan 2012 18:09:51 +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 1RhmKU-0000SU-KY; Mon, 02 Jan 2012 18:09:50 +0000
X-Env-Sender: stefan.bader@canonical.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325527784!9270533!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 16897 invoked from network); 2 Jan 2012 18:09:44 -0000
Received: from youngberry.canonical.com (HELO youngberry.canonical.com)
	(91.189.89.112) by server-15.tower-182.messagelabs.com with SMTP;
	2 Jan 2012 18:09:44 -0000
Received: from p5b2e37e1.dip.t-dialin.net ([91.46.55.225] 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 1RhmKO-0005Oy-Ed; Mon, 02 Jan 2012 18:09:44 +0000
Message-ID: <4F01F2E6.6070803@canonical.com>
Date: Mon, 02 Jan 2012 19:09:42 +0100
From: Stefan Bader <stefan.bader@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111229 Thunderbird/9.0
MIME-Version: 1.0
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
References: <CAO8_4Vo3PwKyc0DPg7djDTN9C5XiSzoQVrFU+X8Sem0_yn=mfQ@mail.gmail.com>
In-Reply-To: <CAO8_4Vo3PwKyc0DPg7djDTN9C5XiSzoQVrFU+X8Sem0_yn=mfQ@mail.gmail.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] Installing Xen on 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 02.01.2012 18:42, Nupur Ghatnekar wrote:
> Hi all,
> 
> I have been trying to install xen on ubuntu 11.10.
> I am following the steps given in this blog.
> http://www.beyondlinux.com/2011/11/02/install-xen-4-1-and-setup-your-cloud-os-on-ubuntu-11-10/
> 
> 
> Though, after the first 1 step, when I reboot. I do not have a Xen entry to
> boot into. It still shows the same grub entry.
> 
> Any suggestions.
> 

I assume you base installation is ubuntu-server (that is the way I had it done).
The grub entry may be a bit hidden. It becomes a kernel under a heading like
"Xen 4.1-amd64". When that is selected, there will be the kernel choices.
Or for some reason update-grub was not run as it should have. Would running
"sudo update-grub" help?

-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 Mon Jan 02 21:27:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 21:27:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhpP2-0001ZB-K4; Mon, 02 Jan 2012 21:26: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 1RhpP0-0001Z6-Mm
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 21:26:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325539595!7586277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA0NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30524 invoked from network); 2 Jan 2012 21:26:35 -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;
	2 Jan 2012 21:26:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,446,1320624000"; 
   d="scan'208";a="9780501"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 21:26:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Jan 2012 21:26:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RhpOr-0001gY-M2;
	Mon, 02 Jan 2012 21:26:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhpOr-0000ok-Ia;
	Mon, 02 Jan 2012 21:26:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10626-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Jan 2012 21:26:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10626: 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 10626 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10626/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu 16 guest-start.2    fail in 10623 REGR. vs. 10621

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  4 xen-install               fail pass in 10623
 test-amd64-i386-pv            4 xen-install                 fail pass in 10623
 test-amd64-i386-xl-multivcpu  4 xen-install                 fail pass in 10623
 test-amd64-i386-xl            4 xen-install                 fail pass in 10623
 test-amd64-i386-pair          6 xen-install/dst_host        fail pass in 10623
 test-amd64-i386-pair          5 xen-install/src_host        fail pass in 10623
 test-amd64-i386-rhel6hvm-amd  4 xen-install                 fail pass in 10623
 build-i386                    2 host-install(2)           broken pass in 10623
 test-amd64-i386-xl-credit2    4 xen-install                 fail pass in 10623
 test-amd64-i386-xl-win-vcpus1  4 xen-install                fail pass in 10623
 test-amd64-i386-win           4 xen-install                 fail pass in 10623
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install           fail pass in 10623
 test-amd64-i386-win-vcpus1    4 xen-install                 fail pass in 10623
 test-amd64-i386-xend-winxpsp3  4 xen-install                fail pass in 10623
 test-amd64-i386-xl-win7-amd64  4 xen-install                fail pass in 10623

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv          16 guest-start.2         fail in 10623 like 10619
 test-amd64-i386-pv           16 guest-start.2         fail in 10623 like 10621
 test-amd64-amd64-xl-sedf      5 xen-boot              fail in 10623 like 10614

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-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-win      13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   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 10623 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10623 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10623 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10623 never pass
 test-i386-i386-win           16 leak-check/check      fail in 10623 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10623 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10623 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10623 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10623 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10623 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10623 never pass

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  a7b2610b8e5c

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

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

------------------------------------------------------------
changeset:   24450:50117a4d1a2c
tag:         tip
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:43:07 2012 +0000
    
    x86/tboot: fix some coding style issues in tboot.c
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Acked-by:  Joseph Cihula <joseph.cihula@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24449:fb1bd2a4ccab
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:42:15 2012 +0000
    
    Update the maitainer list for Intel(R) TXT
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    
    
changeset:   24448:3a22ed3ec534
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 02 09:26:19 2012 +0100
    
    x86/passthrough: don't leak guest IRQs
    
    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>
    
    
changeset:   24447:a7b2610b8e5c
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>
    
    
========================================
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 Mon Jan 02 21:27:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 02 Jan 2012 21:27:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhpP2-0001ZB-K4; Mon, 02 Jan 2012 21:26: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 1RhpP0-0001Z6-Mm
	for xen-devel@lists.xensource.com; Mon, 02 Jan 2012 21:26:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325539595!7586277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA0NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30524 invoked from network); 2 Jan 2012 21:26:35 -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;
	2 Jan 2012 21:26:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,446,1320624000"; 
   d="scan'208";a="9780501"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	02 Jan 2012 21:26:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 2 Jan 2012 21:26:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RhpOr-0001gY-M2;
	Mon, 02 Jan 2012 21:26:33 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhpOr-0000ok-Ia;
	Mon, 02 Jan 2012 21:26:33 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10626-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 2 Jan 2012 21:26:33 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10626: 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 10626 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10626/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-multivcpu 16 guest-start.2    fail in 10623 REGR. vs. 10621

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-intel  4 xen-install               fail pass in 10623
 test-amd64-i386-pv            4 xen-install                 fail pass in 10623
 test-amd64-i386-xl-multivcpu  4 xen-install                 fail pass in 10623
 test-amd64-i386-xl            4 xen-install                 fail pass in 10623
 test-amd64-i386-pair          6 xen-install/dst_host        fail pass in 10623
 test-amd64-i386-pair          5 xen-install/src_host        fail pass in 10623
 test-amd64-i386-rhel6hvm-amd  4 xen-install                 fail pass in 10623
 build-i386                    2 host-install(2)           broken pass in 10623
 test-amd64-i386-xl-credit2    4 xen-install                 fail pass in 10623
 test-amd64-i386-xl-win-vcpus1  4 xen-install                fail pass in 10623
 test-amd64-i386-win           4 xen-install                 fail pass in 10623
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install           fail pass in 10623
 test-amd64-i386-win-vcpus1    4 xen-install                 fail pass in 10623
 test-amd64-i386-xend-winxpsp3  4 xen-install                fail pass in 10623
 test-amd64-i386-xl-win7-amd64  4 xen-install                fail pass in 10623

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv          16 guest-start.2         fail in 10623 like 10619
 test-amd64-i386-pv           16 guest-start.2         fail in 10623 like 10621
 test-amd64-amd64-xl-sedf      5 xen-boot              fail in 10623 like 10614

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-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-win      13 guest-stop                   fail   never pass
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   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 10623 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10623 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10623 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10623 never pass
 test-i386-i386-win           16 leak-check/check      fail in 10623 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 10623 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10623 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10623 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10623 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10623 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10623 never pass

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  a7b2610b8e5c

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

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

------------------------------------------------------------
changeset:   24450:50117a4d1a2c
tag:         tip
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:43:07 2012 +0000
    
    x86/tboot: fix some coding style issues in tboot.c
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Acked-by:  Joseph Cihula <joseph.cihula@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24449:fb1bd2a4ccab
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:42:15 2012 +0000
    
    Update the maitainer list for Intel(R) TXT
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    
    
changeset:   24448:3a22ed3ec534
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 02 09:26:19 2012 +0100
    
    x86/passthrough: don't leak guest IRQs
    
    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>
    
    
changeset:   24447:a7b2610b8e5c
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>
    
    
========================================
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 Tue Jan 03 01:04:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 01:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhsmq-000777-Im; Tue, 03 Jan 2012 01:03: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 1Rhsmp-000772-Pi
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 01:03:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325552604!2745829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11638 invoked from network); 3 Jan 2012 01:03:24 -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;
	3 Jan 2012 01:03:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,446,1320624000"; 
   d="scan'208";a="9781332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 01:03:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Jan 2012 01:03: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 1Rhsmh-0002s1-6u;
	Tue, 03 Jan 2012 01:03:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rhsmh-0008On-1O;
	Tue, 03 Jan 2012 01:03:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10628-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Jan 2012 01:03:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10628: 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 10628 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10628/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10626
 test-amd64-i386-xl-credit2   10 guest-saverestore           fail pass in 10623
 test-i386-i386-xl-win         7 windows-install             fail pass in 10623
 test-amd64-i386-xend-winxpsp3 14 guest-start.2              fail pass in 10623
 test-amd64-i386-rhel6hvm-intel  4 xen-install      fail in 10626 pass in 10628
 test-amd64-i386-pv            4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xl-multivcpu  4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xl            4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-pair        6 xen-install/dst_host fail in 10626 pass in 10628
 test-amd64-i386-pair        5 xen-install/src_host fail in 10626 pass in 10628
 test-amd64-i386-rhel6hvm-amd  4 xen-install        fail in 10626 pass in 10628
 build-i386                    2 host-install(2)  broken in 10626 pass in 10628
 test-amd64-i386-xl-credit2    4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xl-win-vcpus1  4 xen-install       fail in 10626 pass in 10628
 test-amd64-i386-win           4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install  fail in 10626 pass in 10628
 test-amd64-i386-win-vcpus1    4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xend-winxpsp3  4 xen-install       fail in 10626 pass in 10628
 test-amd64-i386-xl-win7-amd64  4 xen-install       fail in 10626 pass in 10628
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10623 pass in 10628

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv          16 guest-start.2         fail in 10623 like 10619
 test-amd64-i386-pv           16 guest-start.2         fail in 10623 like 10621
 test-amd64-amd64-xl-sedf      5 xen-boot              fail in 10623 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-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-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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-pv             1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-xl             1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-pair           1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-win            1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-xl-win         1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-xl-win        13 guest-stop            fail in 10623 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10623 never pass

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  a7b2610b8e5c

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-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


Pushing revision :

+ branch=xen-unstable
+ revision=50117a4d1a2c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 50117a4d1a2c
+ branch=xen-unstable
+ revision=50117a4d1a2c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 50117a4d1a2c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 01:04:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 01:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rhsmq-000777-Im; Tue, 03 Jan 2012 01:03: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 1Rhsmp-000772-Pi
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 01:03:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325552604!2745829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11638 invoked from network); 3 Jan 2012 01:03:24 -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;
	3 Jan 2012 01:03:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,446,1320624000"; 
   d="scan'208";a="9781332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 01:03:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Jan 2012 01:03: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 1Rhsmh-0002s1-6u;
	Tue, 03 Jan 2012 01:03:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rhsmh-0008On-1O;
	Tue, 03 Jan 2012 01:03:23 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10628-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Jan 2012 01:03:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10628: 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 10628 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10628/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     13 guest-localmigrate.2        fail pass in 10626
 test-amd64-i386-xl-credit2   10 guest-saverestore           fail pass in 10623
 test-i386-i386-xl-win         7 windows-install             fail pass in 10623
 test-amd64-i386-xend-winxpsp3 14 guest-start.2              fail pass in 10623
 test-amd64-i386-rhel6hvm-intel  4 xen-install      fail in 10626 pass in 10628
 test-amd64-i386-pv            4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xl-multivcpu  4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xl            4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-pair        6 xen-install/dst_host fail in 10626 pass in 10628
 test-amd64-i386-pair        5 xen-install/src_host fail in 10626 pass in 10628
 test-amd64-i386-rhel6hvm-amd  4 xen-install        fail in 10626 pass in 10628
 build-i386                    2 host-install(2)  broken in 10626 pass in 10628
 test-amd64-i386-xl-credit2    4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xl-win-vcpus1  4 xen-install       fail in 10626 pass in 10628
 test-amd64-i386-win           4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install  fail in 10626 pass in 10628
 test-amd64-i386-win-vcpus1    4 xen-install        fail in 10626 pass in 10628
 test-amd64-i386-xend-winxpsp3  4 xen-install       fail in 10626 pass in 10628
 test-amd64-i386-xl-win7-amd64  4 xen-install       fail in 10626 pass in 10628
 test-amd64-i386-xl-multivcpu 16 guest-start.2      fail in 10623 pass in 10628

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pv          16 guest-start.2         fail in 10623 like 10619
 test-amd64-i386-pv           16 guest-start.2         fail in 10623 like 10621
 test-amd64-amd64-xl-sedf      5 xen-boot              fail in 10623 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-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-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-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-pv             1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-xl             1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-pair           1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-win            1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-xl-win         1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)        blocked in 10626 n/a
 test-i386-i386-xl-win        13 guest-stop            fail in 10623 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10623 never pass

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  a7b2610b8e5c

------------------------------------------------------------
People who touched revisions under test:
  Gang Wei <gang.wei@intel.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Yongjie Ren <yongjie.ren@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-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


Pushing revision :

+ branch=xen-unstable
+ revision=50117a4d1a2c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 50117a4d1a2c
+ branch=xen-unstable
+ revision=50117a4d1a2c
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 50117a4d1a2c ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 05:06:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 05: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 1RhwYu-0000G3-SE; Tue, 03 Jan 2012 05:05:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RhwYt-0000Fy-8r
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 05:05:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325567116!7570377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20300 invoked from network); 3 Jan 2012 05:05:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 05:05:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,447,1320624000"; 
   d="scan'208";a="9782201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 05:04:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Jan 2012 05:04: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 1RhwXk-0004Bk-FT;
	Tue, 03 Jan 2012 05:04:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhwXk-0000WT-7r;
	Tue, 03 Jan 2012 05:04:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10629-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Jan 2012 05:04:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10629: 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 10629 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10629/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl            16 guest-start.2               fail pass in 10628
 test-amd64-amd64-xl-sedf   13 guest-localmigrate.2 fail in 10628 pass in 10629
 test-amd64-i386-xl-credit2   10 guest-saverestore  fail in 10628 pass in 10629
 test-i386-i386-xl-win         7 windows-install    fail in 10628 pass in 10629
 test-amd64-i386-xend-winxpsp3 14 guest-start.2     fail in 10628 pass in 10629

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pv           16 guest-start.2                fail   like 10623

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

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  50117a4d1a2c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-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                                   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                                           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 Jan 03 05:06:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 05: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 1RhwYu-0000G3-SE; Tue, 03 Jan 2012 05:05:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RhwYt-0000Fy-8r
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 05:05:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325567116!7570377!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20300 invoked from network); 3 Jan 2012 05:05:16 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 05:05:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,447,1320624000"; 
   d="scan'208";a="9782201"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 05:04:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Jan 2012 05:04: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 1RhwXk-0004Bk-FT;
	Tue, 03 Jan 2012 05:04:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RhwXk-0000WT-7r;
	Tue, 03 Jan 2012 05:04:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10629-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 3 Jan 2012 05:04:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10629: 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 10629 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10629/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl            16 guest-start.2               fail pass in 10628
 test-amd64-amd64-xl-sedf   13 guest-localmigrate.2 fail in 10628 pass in 10629
 test-amd64-i386-xl-credit2   10 guest-saverestore  fail in 10628 pass in 10629
 test-i386-i386-xl-win         7 windows-install    fail in 10628 pass in 10629
 test-amd64-i386-xend-winxpsp3 14 guest-start.2     fail in 10628 pass in 10629

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pv           16 guest-start.2                fail   like 10623

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

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  50117a4d1a2c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-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                                   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                                           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 Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySX-0001sm-K0; Tue, 03 Jan 2012 07:06:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shuming@linux.vnet.ibm.com>) id 1Rdxm2-0001kv-EX
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 05:34:30 +0000
X-Env-Sender: shuming@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324618459!8087412!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA3MzE0OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3328 invoked from network); 23 Dec 2011 05:34:23 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2011 05:34:23 -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 <shuming@linux.vnet.ibm.com>; 
	Fri, 23 Dec 2011 05:32:26 +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; 
	Fri, 23 Dec 2011 05:31:54 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pBN5X6aM4915338
	for <xen-devel@lists.xensource.com>; Fri, 23 Dec 2011 16:33:09 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pBN5X6AX015704
	for <xen-devel@lists.xensource.com>; Fri, 23 Dec 2011 16:33:06 +1100
Received: from [127.0.0.1] (ibm-e673136c94d.cn.ibm.com [9.115.122.131] (may be
	forged))
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pBN5X2N1015502; Fri, 23 Dec 2011 16:33:04 +1100
Message-ID: <4EF41282.4010603@linux.vnet.ibm.com>
Date: Fri, 23 Dec 2011 13:32:50 +0800
From: Shu Ming <shuming@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?gbk?Q?=A1=E8=BDK=EC=B6aware?= <250716708@qq.com>
References: <tencent_37EF499B2FBF40764715DEA6@qq.com>
In-Reply-To: <tencent_37EF499B2FBF40764715DEA6@qq.com>
x-cbid: 11122219-5140-0000-0000-0000007800EB
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Cc: xen-devel <xen-devel@lists.xensource.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-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-Transfer-Encoding: base64
Content-Type: text/plain; charset="gbk"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

RG8geW91IG1lYW4gdGhlIGZpbGUgZm9ybWF0PyBxY293MiwgcWVkLCByYXc/IE9yIHRoZSBjb250
ZW50IGxheW91dCBpbiAKdGhlIGZpbGUgaW1hZ2U/Ck9uIDIwMTEtMTItMjMgMTM6MTcsIKHovUvs
tmF3YXJlIHdyb3RlOgo+IEhpLAo+IElzIGFueW9uZSBjbGVhciBhYm91dCB0aGUgZm9ybWF0IG9m
IHFlbXUgZmlsZSBmb3Igc2F2ZXZtIG9yIGxvYWR2bT8KPiBicnVjZQoKCi0tIApTaHUgTWluZzxz
aHVtaW5nQGxpbnV4LnZuZXQuaWJtLmNvbT4KSUJNIENoaW5hIFN5c3RlbXMgYW5kIFRlY2hub2xv
Z3kgTGFib3JhdG9yeQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySY-0001tO-Ef; Tue, 03 Jan 2012 07:06:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <DRose@cputech.com>) id 1Rfbds-0000Hh-RI
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 18:20:53 +0000
X-Env-Sender: DRose@cputech.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325010045!8786692!1
X-Originating-IP: [207.115.36.128]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjExNS4zNi4xMjggPT4gNDExMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12617 invoked from network); 27 Dec 2011 18:20:45 -0000
Received: from nlpi114.sbcis.sbc.com (HELO nlpi114.prodigy.net)
	(207.115.36.128) by server-6.tower-182.messagelabs.com with SMTP;
	27 Dec 2011 18:20:45 -0000
Received: from c4exch02.cputech.int (67-114-201-137.cputech.com
	[67.114.201.137] (may be forged))
	by nlpi114.prodigy.net (8.14.4 biz_spool_out_ldap/8.14.4) with ESMTP id
	pBRIKixF003556
	for <xen-devel@lists.xensource.com>; Tue, 27 Dec 2011 12:20:44 -0600
Received: from EXCH2010CAS.cputech.int ([10.2.0.180]) by c4exch02.cputech.int
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 27 Dec 2011 10:20:43 -0800
Received: from EXCH2010MB.cputech.int ([::1]) by EXCH2010CAS.cputech.int
	([::1]) with mapi id 14.01.0218.012; Tue, 27 Dec 2011 10:20:43 -0800
From: Dennis Rose <DRose@cputech.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: Xen developers wanted
Thread-Index: AczExD2IaMLi7sAwSvO7I8aAirT0sg==
Date: Tue, 27 Dec 2011 18:20:42 +0000
Message-ID: <5E62D2F37927F142AC289A694F1B5085011C09@EXCH2010MB.cputech.int>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.2.1.237]
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Dec 2011 18:20:43.0935 (UTC)
	FILETIME=[3F2B7AF0:01CCC4C4]
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Subject: [Xen-devel] Xen developers wanted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9001314871602355893=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9001314871602355893==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0108_01CCC481.2FA48C40"

------=_NextPart_000_0108_01CCC481.2FA48C40
Content-Type: multipart/related;
	boundary="----=_NextPart_001_0109_01CCC481.2FA48C40"


------=_NextPart_001_0109_01CCC481.2FA48C40
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_010A_01CCC481.2FA48C40"


------=_NextPart_002_010A_01CCC481.2FA48C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


Xen Developers Wanted:
CPUTech.com in Colorado is looking for XEN developers to work on our unique
virtualization platform.  Detailed knowledge of Xen (and/or other
hypervisors) is required.  Consulting or full time positions available.
Come to Colorado to do strange and unique things to hypervisors in the
presence of the Rocky Mountains and get paid for it.  While our Principle
Engineer on this project is out skiing in the Rockies this week, I'm taking
initial inputs for him.  
 
Thanks,
 
        Dennis Rose
  Acalis Program Manager
  CPU Technology, LLC.
  drose@cputech.com
  408-202-2385 (mobile for calls, texts, etc.)
 

------=_NextPart_002_010A_01CCC481.2FA48C40
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-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta name=3D"Microsoft =
Theme 2.00" content=3D"Arctic 011"><meta http-equiv=3DContent-Type =
content=3D"text/html; charset=3Dus-ascii"><meta name=3DProgId =
content=3DWord.Document><meta name=3DGenerator content=3D"Microsoft Word =
14"><meta name=3DOriginator content=3D"Microsoft Word 14"><link =
rel=3DFile-List href=3D"cid:filelist.xml@01CCC481.2F684690"><!--[if gte =
mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:SpellingState>Clean</w:SpellingState>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:EnvelopeVis/>
<w:PunctuationKerning/>
<w:DefaultTableStyle Number=3D"155">Table Theme</w:DefaultTableStyle>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-US</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val=3D"Cambria Math"/>
<m:brkBin m:val=3D"before"/>
<m:brkBinSub m:val=3D"&#45;-"/>
<m:smallFrac m:val=3D"off"/>
<m:dispDef/>
<m:lMargin m:val=3D"0"/>
<m:rMargin m:val=3D"0"/>
<m:defJc m:val=3D"centerGroup"/>
<m:wrapIndent m:val=3D"1440"/>
<m:intLim m:val=3D"subSup"/>
<m:naryLim m:val=3D"undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true" =
DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99" =
LatentStyleCount=3D"267">
<w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
<w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 2"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 3"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 4"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 5"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 6"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 7"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 8"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 9"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
<w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =
Name=3D"caption"/>
<w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
<w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =
Paragraph Font"/>
<w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
<w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
<w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
<w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Placeholder Text"/>
<w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
<w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Revision"/>
<w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
<w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
<w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
<w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Reference"/>
<w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
<w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliography"/>
<w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =
Name=3D"TOC Heading"/>
</w:LatentStyles>
</xml><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 0;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1593833729 1073750107 16 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
h1
	{mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-link:"Heading 1 Char";
	mso-style-next:Normal;
	margin-top:24.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	mso-font-kerning:0pt;}
h2
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 2 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:2;
	font-size:14.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
h3
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 3 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:3;
	font-size:13.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
h4
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 4 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:4;
	font-size:14.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
h5
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 5 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:5;
	font-size:13.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
h6
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 6 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:6;
	font-size:11.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:#9D454F;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:#814E95;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:12.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;
	font-style:normal;
	text-underline:black;}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 1";
	mso-ansi-font-size:16.0pt;
	mso-bidi-font-size:16.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:bold;}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 2";
	mso-ansi-font-size:14.0pt;
	mso-bidi-font-size:14.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 3";
	mso-ansi-font-size:13.0pt;
	mso-bidi-font-size:13.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 4";
	mso-ansi-font-size:14.0pt;
	mso-bidi-font-size:14.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.Heading5Char
	{mso-style-name:"Heading 5 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 5";
	mso-ansi-font-size:13.0pt;
	mso-bidi-font-size:13.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.Heading6Char
	{mso-style-name:"Heading 6 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 6";
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-fareast-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 10]><style>/* Style Definitions */
table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
table.MsoTableTheme
	{mso-style-name:"Table Theme";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	border:solid #585858 1.0pt;
	mso-border-alt:solid #585858 .5pt;
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-border-insideh:.5pt solid #585858;
	mso-border-insidev:.5pt solid #585858;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
</style><![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite =
background=3D"cid:image001.gif@01CCC481.2F5BEA80" lang=3DEN-US =
link=3D"#9D454F" vlink=3D"#814E95" style=3D'tab-interval:.5in'><img =
src=3D"cid:image001.gif@01CCC481.2F5BEA80" =
v:src=3D"cid:image001.gif@01CCC481.2F5BEA80" v:shapes=3D"_x0000_Mail" =
width=3D0 height=3D0 class=3Dshape =
style=3D'display:none;width:0;height:0'><!--[if gte mso 9]><xml>
<v:background id=3D"_x0000_s1025" o:bwmode=3D"white" =
o:targetscreensize=3D"1024,768">
<v:fill src=3D"cid:image001.gif@01CCC481.2F5BEA80" =
o:title=3D"background_arctic" type=3D"frame" />
</v:background></xml><![endif]--><div class=3DWordSection1><p =
class=3DMsoNormal><span style=3D'font-family:"Calibri","sans-serif"'>Xen =
Developers Wanted:<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif"'>CPUTech.com in Colorado is =
looking for XEN developers to work on our unique virtualization =
platform.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Detailed =
knowledge of Xen (and/or other hypervisors) is required.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>Consulting or full time =
positions available.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Come =
to Colorado to do strange and unique things to hypervisors in the =
presence of the Rocky Mountains and get paid for it.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>While our Principle Engineer on =
this project is out skiing in the Rockies this week, I&#8217;m taking =
initial inputs for him.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span><o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:black'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New =
Roman";color:black;mso-no-proof:yes'>Thanks,<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New =
Roman";color:black;mso-no-proof:yes'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; </span><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Den=
nis Rose<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; </span>Acalis Program =
Manager<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; </span>CPU Technology, =
LLC.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; =
</span>drose@cputech.com<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; </span>408-202-2385 (mobile for calls, =
texts, etc.)<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_002_010A_01CCC481.2FA48C40--

------=_NextPart_001_0109_01CCC481.2FA48C40
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <image001.gif@01CCC481.2F5BEA80>

R0lGODlhMgAyAIAAAP///wAAACH5BAAAAAAALAAAAAAyADIAAAIzhI+py+0Po5y02ouz3rz7D4bi
SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKicFADs=

------=_NextPart_001_0109_01CCC481.2FA48C40--

------=_NextPart_000_0108_01CCC481.2FA48C40
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCCBBow
ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk
IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd
hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj
DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU
Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF
s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D
J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez
useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg
lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8
T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6
g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE
74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTKMIIDsqADAgECAhBNRripIIab4M8vEZBF1i08MA0G
CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMwHhcNMTExMTA0MDAwMDAwWhcNMTIxMTAzMjM1OTU5WjCCARExFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13
d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj
KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0Rlbm5pcyBSb3NlMSEw
HwYJKoZIhvcNAQkBFhJkLnJvc2VAY3B1dGVjaC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAMMPKN4bqzhyNxncBx9aKFXARyzHIKHIgnCvDlaG74QVtjT/ilrS3oaK7ILfMNRPZLqMLPfp
MYxd7qiP6W2Y4j2KloAMXbVyNQ3gTO1FSisLHXa3PPVSFmXdhAS1RczHRHYZCQQf4gd8rWeiP+T4
bV8kPcWtcSM61DvF0qhLt8z1AgMBAAGjgdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG
SAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD
VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BB
hj9odHRwOi8vaW5kYzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJ
RC1HMy5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF6WDll6F8AoTY2X9qaoWrnaN2hr0pSZyfdT/YMI
fepOh7YxRQrus+u2wOeVyqoJXdxY3HuouwZIl3wx2/4TQPHLjWzbOSfCH1L0is8k+bgZbNdKSn/F
rj9eTEZzVHHL2OsKbl/LCzbw++iFbj6J9MMidHXgNn7CXdH9lKpqAfbLtoQs9vQGEBt3FAGNpr6E
cBWNAGzC6vxEPRPmyJc9WyCdO7r7dOSBGQureiUs5gpoGq6uKLjEQnvXZHWeFL921GFWf/uBSSSR
EF3mIqEJBRjvRXI5JEdaLlxPTK6fcFiXZkXjfE1oqzKoKbD35WUirUT1hINU0vKNaTxweYUTXqkw
ggbuMIIF1qADAgECAhBxFWYFSuSRIU3pvET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg
dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHd
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV
BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpl
iCALERPpm+BJTotv1QHQXw1HkYpaTHQ+P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJU
GXNGahlCEewScyGN9dwwzeXZVgoxxTZtKRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64a
PGtpePbALI7hgz93+Zn//p9SWsK0hwrYbKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7
HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJIGnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMB
AAGjggK5MIICtTA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlz
aWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAo
BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwu
dmVyaXNpZ24uY29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGCh
XqBcMFowWDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAm
FiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAd
BgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJ
KxH4MIHxBgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5
OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVy
aVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcz
ghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzk
NKha59hsCUwkGrpZpIc7cyHxk4HPv2hjWmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qO
GY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVyF+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37Ogr
ZDV2zbra4NHLFNZxWJu+1T59ttnoJMUkZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLt
Sh2/S+P4zHL6SA5ljknI1viZmDu3lD4xcQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8
oNpSWN0KDn/BgjGCBLgwggS0AgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z
IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQ
ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyIENBIC0gRzMCEE1GuKkghpvgzy8RkEXWLTwwCQYFKw4DAhoFAKCCAxswGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMjI3MTgyMDQxWjAjBgkq
hkiG9w0BCQQxFgQUgncZxNxplO2xn6L5LYKF8C60oicwgasGCSqGSIb3DQEJDzGBnTCBmjALBglg
hkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJ
YIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwggEDBgkrBgEEAYI3EAQxgfUwgfIw
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQTUa4
qSCGm+DPLxGQRdYtPDCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5
BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5
MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz
IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE1GuKkghpvgzy8RkEXWLTwwDQYJKoZI
hvcNAQEBBQAEgYCxgxsH/FKcASvYBSWfDqUZkvj2yMHl1ONs5Xb4klymwN8STD+wb9Gbh22blauh
7hGHWLcjJiG8txFWPsGG15mVETVqeLKTfI+C6TH+kNGifHxl+ZSGiNjuws9mRUf3pq3oSOxTrkbO
xfnMPweDhAzjbEB9be6pTOxszHeBxGXwtAAAAAAAAA==

------=_NextPart_000_0108_01CCC481.2FA48C40--


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

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

--===============9001314871602355893==--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySY-0001tO-Ef; Tue, 03 Jan 2012 07:06:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <DRose@cputech.com>) id 1Rfbds-0000Hh-RI
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 18:20:53 +0000
X-Env-Sender: DRose@cputech.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325010045!8786692!1
X-Originating-IP: [207.115.36.128]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA3LjExNS4zNi4xMjggPT4gNDExMzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12617 invoked from network); 27 Dec 2011 18:20:45 -0000
Received: from nlpi114.sbcis.sbc.com (HELO nlpi114.prodigy.net)
	(207.115.36.128) by server-6.tower-182.messagelabs.com with SMTP;
	27 Dec 2011 18:20:45 -0000
Received: from c4exch02.cputech.int (67-114-201-137.cputech.com
	[67.114.201.137] (may be forged))
	by nlpi114.prodigy.net (8.14.4 biz_spool_out_ldap/8.14.4) with ESMTP id
	pBRIKixF003556
	for <xen-devel@lists.xensource.com>; Tue, 27 Dec 2011 12:20:44 -0600
Received: from EXCH2010CAS.cputech.int ([10.2.0.180]) by c4exch02.cputech.int
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 27 Dec 2011 10:20:43 -0800
Received: from EXCH2010MB.cputech.int ([::1]) by EXCH2010CAS.cputech.int
	([::1]) with mapi id 14.01.0218.012; Tue, 27 Dec 2011 10:20:43 -0800
From: Dennis Rose <DRose@cputech.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: Xen developers wanted
Thread-Index: AczExD2IaMLi7sAwSvO7I8aAirT0sg==
Date: Tue, 27 Dec 2011 18:20:42 +0000
Message-ID: <5E62D2F37927F142AC289A694F1B5085011C09@EXCH2010MB.cputech.int>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.2.1.237]
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Dec 2011 18:20:43.0935 (UTC)
	FILETIME=[3F2B7AF0:01CCC4C4]
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Subject: [Xen-devel] Xen developers wanted
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9001314871602355893=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9001314871602355893==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0108_01CCC481.2FA48C40"

------=_NextPart_000_0108_01CCC481.2FA48C40
Content-Type: multipart/related;
	boundary="----=_NextPart_001_0109_01CCC481.2FA48C40"


------=_NextPart_001_0109_01CCC481.2FA48C40
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_010A_01CCC481.2FA48C40"


------=_NextPart_002_010A_01CCC481.2FA48C40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


Xen Developers Wanted:
CPUTech.com in Colorado is looking for XEN developers to work on our unique
virtualization platform.  Detailed knowledge of Xen (and/or other
hypervisors) is required.  Consulting or full time positions available.
Come to Colorado to do strange and unique things to hypervisors in the
presence of the Rocky Mountains and get paid for it.  While our Principle
Engineer on this project is out skiing in the Rockies this week, I'm taking
initial inputs for him.  
 
Thanks,
 
        Dennis Rose
  Acalis Program Manager
  CPU Technology, LLC.
  drose@cputech.com
  408-202-2385 (mobile for calls, texts, etc.)
 

------=_NextPart_002_010A_01CCC481.2FA48C40
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-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta name=3D"Microsoft =
Theme 2.00" content=3D"Arctic 011"><meta http-equiv=3DContent-Type =
content=3D"text/html; charset=3Dus-ascii"><meta name=3DProgId =
content=3DWord.Document><meta name=3DGenerator content=3D"Microsoft Word =
14"><meta name=3DOriginator content=3D"Microsoft Word 14"><link =
rel=3DFile-List href=3D"cid:filelist.xml@01CCC481.2F684690"><!--[if gte =
mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:SpellingState>Clean</w:SpellingState>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:EnvelopeVis/>
<w:PunctuationKerning/>
<w:DefaultTableStyle Number=3D"155">Table Theme</w:DefaultTableStyle>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-US</w:LidThemeOther>
<w:LidThemeAsian>X-NONE</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val=3D"Cambria Math"/>
<m:brkBin m:val=3D"before"/>
<m:brkBinSub m:val=3D"&#45;-"/>
<m:smallFrac m:val=3D"off"/>
<m:dispDef/>
<m:lMargin m:val=3D"0"/>
<m:rMargin m:val=3D"0"/>
<m:defJc m:val=3D"centerGroup"/>
<m:wrapIndent m:val=3D"1440"/>
<m:intLim m:val=3D"subSup"/>
<m:naryLim m:val=3D"undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true" =
DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99" =
LatentStyleCount=3D"267">
<w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
<w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 2"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 3"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 4"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 5"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 6"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 7"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 8"/>
<w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 9"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
<w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
<w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =
Name=3D"caption"/>
<w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
<w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =
Paragraph Font"/>
<w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
<w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
<w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
<w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Placeholder Text"/>
<w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
<w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Revision"/>
<w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
<w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
<w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
<w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
<w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
<w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
<w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Reference"/>
<w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false" =
UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
<w:LsdException Locked=3D"false" Priority=3D"37" Name=3D"Bibliography"/>
<w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =
Name=3D"TOC Heading"/>
</w:LatentStyles>
</xml><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-520092929 1073786111 9 0 415 0;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1593833729 1073750107 16 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
h1
	{mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-link:"Heading 1 Char";
	mso-style-next:Normal;
	margin-top:24.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	mso-font-kerning:0pt;}
h2
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 2 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:2;
	font-size:14.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
h3
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 3 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:3;
	font-size:13.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
h4
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 4 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:4;
	font-size:14.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
h5
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 5 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:5;
	font-size:13.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
h6
	{mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-qformat:yes;
	mso-style-link:"Heading 6 Char";
	mso-style-next:Normal;
	margin-top:10.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	page-break-after:avoid;
	mso-outline-level:6;
	font-size:11.0pt;
	font-family:"Verdana","sans-serif";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:#9D454F;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:#814E95;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:12.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:normal;
	font-style:normal;
	text-underline:black;}
span.Heading1Char
	{mso-style-name:"Heading 1 Char";
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 1";
	mso-ansi-font-size:16.0pt;
	mso-bidi-font-size:16.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;
	font-weight:bold;}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 2";
	mso-ansi-font-size:14.0pt;
	mso-bidi-font-size:14.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.Heading3Char
	{mso-style-name:"Heading 3 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 3";
	mso-ansi-font-size:13.0pt;
	mso-bidi-font-size:13.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.Heading4Char
	{mso-style-name:"Heading 4 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 4";
	mso-ansi-font-size:14.0pt;
	mso-bidi-font-size:14.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.Heading5Char
	{mso-style-name:"Heading 5 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 5";
	mso-ansi-font-size:13.0pt;
	mso-bidi-font-size:13.0pt;
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.Heading6Char
	{mso-style-name:"Heading 6 Char";
	mso-style-noshow:yes;
	mso-style-priority:9;
	mso-style-unhide:no;
	mso-style-locked:yes;
	mso-style-link:"Heading 6";
	font-family:"Verdana","sans-serif";
	mso-ascii-font-family:Verdana;
	mso-fareast-font-family:"Times New Roman";
	mso-hansi-font-family:Verdana;
	mso-bidi-font-family:"Times New Roman";
	color:black;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-fareast-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 10]><style>/* Style Definitions */
table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
table.MsoTableTheme
	{mso-style-name:"Table Theme";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	border:solid #585858 1.0pt;
	mso-border-alt:solid #585858 .5pt;
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-border-insideh:.5pt solid #585858;
	mso-border-insidev:.5pt solid #585858;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-hansi-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
</style><![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=3Dwhite =
background=3D"cid:image001.gif@01CCC481.2F5BEA80" lang=3DEN-US =
link=3D"#9D454F" vlink=3D"#814E95" style=3D'tab-interval:.5in'><img =
src=3D"cid:image001.gif@01CCC481.2F5BEA80" =
v:src=3D"cid:image001.gif@01CCC481.2F5BEA80" v:shapes=3D"_x0000_Mail" =
width=3D0 height=3D0 class=3Dshape =
style=3D'display:none;width:0;height:0'><!--[if gte mso 9]><xml>
<v:background id=3D"_x0000_s1025" o:bwmode=3D"white" =
o:targetscreensize=3D"1024,768">
<v:fill src=3D"cid:image001.gif@01CCC481.2F5BEA80" =
o:title=3D"background_arctic" type=3D"frame" />
</v:background></xml><![endif]--><div class=3DWordSection1><p =
class=3DMsoNormal><span style=3D'font-family:"Calibri","sans-serif"'>Xen =
Developers Wanted:<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif"'>CPUTech.com in Colorado is =
looking for XEN developers to work on our unique virtualization =
platform.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Detailed =
knowledge of Xen (and/or other hypervisors) is required.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>Consulting or full time =
positions available.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Come =
to Colorado to do strange and unique things to hypervisors in the =
presence of the Rocky Mountains and get paid for it.<span =
style=3D'mso-spacerun:yes'>&nbsp; </span>While our Principle Engineer on =
this project is out skiing in the Rockies this week, I&#8217;m taking =
initial inputs for him.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span><o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";color:black'><o:p>&nbsp;</o:p=
></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New =
Roman";color:black;mso-no-proof:yes'>Thanks,<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New =
Roman";color:black;mso-no-proof:yes'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; </span><span =
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>Den=
nis Rose<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; </span>Acalis Program =
Manager<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; </span>CPU Technology, =
LLC.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; =
</span>drose@cputech.com<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-family:"Calibri","sans-serif";mso-fareast-font-family:"Time=
s New Roman";color:black;mso-no-proof:yes'><span =
style=3D'mso-spacerun:yes'>&nbsp; </span>408-202-2385 (mobile for calls, =
texts, etc.)<o:p></o:p></span></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
------=_NextPart_002_010A_01CCC481.2FA48C40--

------=_NextPart_001_0109_01CCC481.2FA48C40
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <image001.gif@01CCC481.2F5BEA80>

R0lGODlhMgAyAIAAAP///wAAACH5BAAAAAAALAAAAAAyADIAAAIzhI+py+0Po5y02ouz3rz7D4bi
SJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKicFADs=

------=_NextPart_001_0109_01CCC481.2FA48C40--

------=_NextPart_000_0108_01CCC481.2FA48C40
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCCBBow
ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk
IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd
hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj
DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU
Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF
s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D
J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez
useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg
lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8
T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6
g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE
74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTKMIIDsqADAgECAhBNRripIIab4M8vEZBF1i08MA0G
CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMwHhcNMTExMTA0MDAwMDAwWhcNMTIxMTAzMjM1OTU5WjCCARExFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13
d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj
KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0Rlbm5pcyBSb3NlMSEw
HwYJKoZIhvcNAQkBFhJkLnJvc2VAY3B1dGVjaC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAMMPKN4bqzhyNxncBx9aKFXARyzHIKHIgnCvDlaG74QVtjT/ilrS3oaK7ILfMNRPZLqMLPfp
MYxd7qiP6W2Y4j2KloAMXbVyNQ3gTO1FSisLHXa3PPVSFmXdhAS1RczHRHYZCQQf4gd8rWeiP+T4
bV8kPcWtcSM61DvF0qhLt8z1AgMBAAGjgdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG
SAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYD
VR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BB
hj9odHRwOi8vaW5kYzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJ
RC1HMy5jcmwwDQYJKoZIhvcNAQEFBQADggEBAF6WDll6F8AoTY2X9qaoWrnaN2hr0pSZyfdT/YMI
fepOh7YxRQrus+u2wOeVyqoJXdxY3HuouwZIl3wx2/4TQPHLjWzbOSfCH1L0is8k+bgZbNdKSn/F
rj9eTEZzVHHL2OsKbl/LCzbw++iFbj6J9MMidHXgNn7CXdH9lKpqAfbLtoQs9vQGEBt3FAGNpr6E
cBWNAGzC6vxEPRPmyJc9WyCdO7r7dOSBGQureiUs5gpoGq6uKLjEQnvXZHWeFL921GFWf/uBSSSR
EF3mIqEJBRjvRXI5JEdaLlxPTK6fcFiXZkXjfE1oqzKoKbD35WUirUT1hINU0vKNaTxweYUTXqkw
ggbuMIIF1qADAgECAhBxFWYFSuSRIU3pvET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQG
EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l
dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg
dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHd
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJp
c2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNV
BAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpl
iCALERPpm+BJTotv1QHQXw1HkYpaTHQ+P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJU
GXNGahlCEewScyGN9dwwzeXZVgoxxTZtKRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64a
PGtpePbALI7hgz93+Zn//p9SWsK0hwrYbKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7
HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJIGnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMB
AAGjggK5MIICtTA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlz
aWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAo
BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwu
dmVyaXNpZ24uY29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGCh
XqBcMFowWDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAm
FiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAd
BgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJ
KxH4MIHxBgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5
OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVy
aVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcz
ghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzk
NKha59hsCUwkGrpZpIc7cyHxk4HPv2hjWmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qO
GY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVyF+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37Ogr
ZDV2zbra4NHLFNZxWJu+1T59ttnoJMUkZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLt
Sh2/S+P4zHL6SA5ljknI1viZmDu3lD4xcQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8
oNpSWN0KDn/BgjGCBLgwggS0AgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNp
Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z
IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQ
ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVh
bCBTdWJzY3JpYmVyIENBIC0gRzMCEE1GuKkghpvgzy8RkEXWLTwwCQYFKw4DAhoFAKCCAxswGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMjI3MTgyMDQxWjAjBgkq
hkiG9w0BCQQxFgQUgncZxNxplO2xn6L5LYKF8C60oicwgasGCSqGSIb3DQEJDzGBnTCBmjALBglg
hkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0D
AgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJ
YIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwggEDBgkrBgEEAYI3EAQxgfUwgfIw
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQTUa4
qSCGm+DPLxGQRdYtPDCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5
BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5
MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz
IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEE1GuKkghpvgzy8RkEXWLTwwDQYJKoZI
hvcNAQEBBQAEgYCxgxsH/FKcASvYBSWfDqUZkvj2yMHl1ONs5Xb4klymwN8STD+wb9Gbh22blauh
7hGHWLcjJiG8txFWPsGG15mVETVqeLKTfI+C6TH+kNGifHxl+ZSGiNjuws9mRUf3pq3oSOxTrkbO
xfnMPweDhAzjbEB9be6pTOxszHeBxGXwtAAAAAAAAA==

------=_NextPart_000_0108_01CCC481.2FA48C40--


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

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

--===============9001314871602355893==--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySX-0001sm-K0; Tue, 03 Jan 2012 07:06:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shuming@linux.vnet.ibm.com>) id 1Rdxm2-0001kv-EX
	for xen-devel@lists.xensource.com; Fri, 23 Dec 2011 05:34:30 +0000
X-Env-Sender: shuming@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1324618459!8087412!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA3MzE0OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3328 invoked from network); 23 Dec 2011 05:34:23 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Dec 2011 05:34:23 -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 <shuming@linux.vnet.ibm.com>; 
	Fri, 23 Dec 2011 05:32:26 +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; 
	Fri, 23 Dec 2011 05:31:54 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	pBN5X6aM4915338
	for <xen-devel@lists.xensource.com>; Fri, 23 Dec 2011 16:33:09 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	pBN5X6AX015704
	for <xen-devel@lists.xensource.com>; Fri, 23 Dec 2011 16:33:06 +1100
Received: from [127.0.0.1] (ibm-e673136c94d.cn.ibm.com [9.115.122.131] (may be
	forged))
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	pBN5X2N1015502; Fri, 23 Dec 2011 16:33:04 +1100
Message-ID: <4EF41282.4010603@linux.vnet.ibm.com>
Date: Fri, 23 Dec 2011 13:32:50 +0800
From: Shu Ming <shuming@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: =?gbk?Q?=A1=E8=BDK=EC=B6aware?= <250716708@qq.com>
References: <tencent_37EF499B2FBF40764715DEA6@qq.com>
In-Reply-To: <tencent_37EF499B2FBF40764715DEA6@qq.com>
x-cbid: 11122219-5140-0000-0000-0000007800EB
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Cc: xen-devel <xen-devel@lists.xensource.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-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-Transfer-Encoding: base64
Content-Type: text/plain; charset="gbk"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

RG8geW91IG1lYW4gdGhlIGZpbGUgZm9ybWF0PyBxY293MiwgcWVkLCByYXc/IE9yIHRoZSBjb250
ZW50IGxheW91dCBpbiAKdGhlIGZpbGUgaW1hZ2U/Ck9uIDIwMTEtMTItMjMgMTM6MTcsIKHovUvs
tmF3YXJlIHdyb3RlOgo+IEhpLAo+IElzIGFueW9uZSBjbGVhciBhYm91dCB0aGUgZm9ybWF0IG9m
IHFlbXUgZmlsZSBmb3Igc2F2ZXZtIG9yIGxvYWR2bT8KPiBicnVjZQoKCi0tIApTaHUgTWluZzxz
aHVtaW5nQGxpbnV4LnZuZXQuaWJtLmNvbT4KSUJNIENoaW5hIFN5c3RlbXMgYW5kIFRlY2hub2xv
Z3kgTGFib3JhdG9yeQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySX-0001sZ-6K; Tue, 03 Jan 2012 07:06:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maydin.work@gmail.com>) id 1RdPE2-0002KR-9O
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:41:06 +0000
X-Env-Sender: maydin.work@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324485659!8349200!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 23344 invoked from network); 21 Dec 2011 16:40:59 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 16:40:59 -0000
Received: by eekd4 with SMTP id d4so37207972eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 08:40:59 -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=6sEgjIutq++t/uWBEeAxQmzDjdP8u2tNGe2Uv3iIy4o=;
	b=GfQ2soDB+g+fwcRK19tIurL0FDEuyCINqVymeDwA3zUtjyqq3pK+XurbnaATUkz1YO
	nfW/ttAkaEMUWTG3R5tXcBZCN0Zebr6auFWT9/PH+V5Yy6gzvoN4gqk+QjzFhFDkgO0T
	M1Rnn9VfI1PJ+1Hhr6njpinxNJ/uhoUmBsH/Y=
MIME-Version: 1.0
Received: by 10.14.3.232 with SMTP id 80mr2863493eeh.2.1324485659663; Wed, 21
	Dec 2011 08:40:59 -0800 (PST)
Received: by 10.213.34.77 with HTTP; Wed, 21 Dec 2011 08:40:59 -0800 (PST)
In-Reply-To: <1324475220.7877.32.camel@zakaz.uk.xensource.com>
References: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
	<1324475220.7877.32.camel@zakaz.uk.xensource.com>
Date: Wed, 21 Dec 2011 16:40:59 +0000
Message-ID: <CALF+9DEP5-Tb9NTzzwFF8WiWMmGQ2mTJ7vdp+adde0tYejRgGQ@mail.gmail.com>
From: Muhammed Aydin <maydin.work@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
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: multipart/mixed; boundary="===============0953533349817179592=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0953533349817179592==
Content-Type: multipart/alternative; boundary=0016364c7adf411c8704b49cd93a

--0016364c7adf411c8704b49cd93a
Content-Type: text/plain; charset=ISO-8859-1

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.

All the best,

Muhammed

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

Hi Ian,<br><br>Thanks for the response.<br><br>&gt; Perhaps if you explain =
your actual end goal you can be better advised.<br><br>What we are planning=
 to do is to insert some code which can automatically utilise some instruct=
ions from forensics investigation tools (such as a command line tools like =
Sleuthkit), and to do this automatically upon starting up and shutdown / su=
spension of a virtual machine running on the Xen hypervisor in order to aid=
 forensic investigations. Nothing complicated being added but we need to kn=
ow exactly where we would need to put these commands.<br>
<br>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 le=
vel 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&#39;t find anything. <br>
<br>All the best,<br><br>Muhammed<br>
<br><br>

--0016364c7adf411c8704b49cd93a--


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

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

--===============0953533349817179592==--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySZ-0001tu-9p; Tue, 03 Jan 2012 07:06:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuyi9352@126.com>) id 1RgAlS-0001ZR-Qd
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 07:51:03 +0000
X-Env-Sender: liuyi9352@126.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1325145055!7923228!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 4284 invoked from network); 29 Dec 2011 07:50:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Dec 2011 07:50:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <liuyi9352@126.com>) id 1RgAlK-0002xd-T7
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 23:50:54 -0800
Date: Wed, 28 Dec 2011 23:50:54 -0800 (PST)
From: "Liu,Yi" <liuyi9352@126.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325145054882-5107044.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
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
I run 8 vms in HP DL380G7 server. These vms run fine if vm's schedule cap
value is 0(default).But most of vms stop running about one minute later if
their schedule cap values is 42 or other value.
After a few weeks tracking, I find that when I modify sched_credit.c as
follows, vms run fine again:
      1. in csched_acct function:
        - svc->flags |= CSCHED_FLAG_VCPU_PARKED; 
        + set_bit(0, &svc->flags);       // set CSCHED_FLAG_VCPU_PARKED
      2. in csched_vcpu_yield function:
        - sv->flags |= CSCHED_FLAG_VCPU_YIELD;
        + set_bit(1, &svc->flags);       // set CSCHED_FLAG_VCPU_YIELD
      3. in csched_vcpu struct:
        - uint16_t flags;
        + uint32_t flags;      // set_bit ask
Vms don't stop running either if sched_credit_default_yield = 1 in grub
menu.lst.
So, what I modified is correct? Is there access race when xen access
svc->flags from csched_acct and csched_vcpu_yield?
Another interesting things is that vms don't stop running in other server
even if vms's schedule cap values is not 0, just on this HP DL380G7 server.
I don't know why.
My xen version is 4.1.0, dom0 kernel version is 2.6.32.41 from jeremy's git
a few months before.

--
View this message in context: http://xen.1045712.n5.nabble.com/credit-scheduler-svc-flags-access-race-tp5107044p5107044.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 Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySZ-0001tu-9p; Tue, 03 Jan 2012 07:06:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liuyi9352@126.com>) id 1RgAlS-0001ZR-Qd
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 07:51:03 +0000
X-Env-Sender: liuyi9352@126.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1325145055!7923228!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 4284 invoked from network); 29 Dec 2011 07:50:56 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-3.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Dec 2011 07:50:56 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <liuyi9352@126.com>) id 1RgAlK-0002xd-T7
	for xen-devel@lists.xensource.com; Wed, 28 Dec 2011 23:50:54 -0800
Date: Wed, 28 Dec 2011 23:50:54 -0800 (PST)
From: "Liu,Yi" <liuyi9352@126.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325145054882-5107044.post@n5.nabble.com>
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
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
I run 8 vms in HP DL380G7 server. These vms run fine if vm's schedule cap
value is 0(default).But most of vms stop running about one minute later if
their schedule cap values is 42 or other value.
After a few weeks tracking, I find that when I modify sched_credit.c as
follows, vms run fine again:
      1. in csched_acct function:
        - svc->flags |= CSCHED_FLAG_VCPU_PARKED; 
        + set_bit(0, &svc->flags);       // set CSCHED_FLAG_VCPU_PARKED
      2. in csched_vcpu_yield function:
        - sv->flags |= CSCHED_FLAG_VCPU_YIELD;
        + set_bit(1, &svc->flags);       // set CSCHED_FLAG_VCPU_YIELD
      3. in csched_vcpu struct:
        - uint16_t flags;
        + uint32_t flags;      // set_bit ask
Vms don't stop running either if sched_credit_default_yield = 1 in grub
menu.lst.
So, what I modified is correct? Is there access race when xen access
svc->flags from csched_acct and csched_vcpu_yield?
Another interesting things is that vms don't stop running in other server
even if vms's schedule cap values is not 0, just on this HP DL380G7 server.
I don't know why.
My xen version is 4.1.0, dom0 kernel version is 2.6.32.41 from jeremy's git
a few months before.

--
View this message in context: http://xen.1045712.n5.nabble.com/credit-scheduler-svc-flags-access-race-tp5107044p5107044.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 Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySX-0001sZ-6K; Tue, 03 Jan 2012 07:06:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <maydin.work@gmail.com>) id 1RdPE2-0002KR-9O
	for xen-devel@lists.xensource.com; Wed, 21 Dec 2011 16:41:06 +0000
X-Env-Sender: maydin.work@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1324485659!8349200!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 23344 invoked from network); 21 Dec 2011 16:40:59 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Dec 2011 16:40:59 -0000
Received: by eekd4 with SMTP id d4so37207972eek.30
	for <xen-devel@lists.xensource.com>;
	Wed, 21 Dec 2011 08:40:59 -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=6sEgjIutq++t/uWBEeAxQmzDjdP8u2tNGe2Uv3iIy4o=;
	b=GfQ2soDB+g+fwcRK19tIurL0FDEuyCINqVymeDwA3zUtjyqq3pK+XurbnaATUkz1YO
	nfW/ttAkaEMUWTG3R5tXcBZCN0Zebr6auFWT9/PH+V5Yy6gzvoN4gqk+QjzFhFDkgO0T
	M1Rnn9VfI1PJ+1Hhr6njpinxNJ/uhoUmBsH/Y=
MIME-Version: 1.0
Received: by 10.14.3.232 with SMTP id 80mr2863493eeh.2.1324485659663; Wed, 21
	Dec 2011 08:40:59 -0800 (PST)
Received: by 10.213.34.77 with HTTP; Wed, 21 Dec 2011 08:40:59 -0800 (PST)
In-Reply-To: <1324475220.7877.32.camel@zakaz.uk.xensource.com>
References: <CALF+9DFCeYu2E1xBuHOW4n_7J9kz0H4Ngv1BY_Rn8d-SwDb3VA@mail.gmail.com>
	<1324475220.7877.32.camel@zakaz.uk.xensource.com>
Date: Wed, 21 Dec 2011 16:40:59 +0000
Message-ID: <CALF+9DEP5-Tb9NTzzwFF8WiWMmGQ2mTJ7vdp+adde0tYejRgGQ@mail.gmail.com>
From: Muhammed Aydin <maydin.work@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
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: multipart/mixed; boundary="===============0953533349817179592=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0953533349817179592==
Content-Type: multipart/alternative; boundary=0016364c7adf411c8704b49cd93a

--0016364c7adf411c8704b49cd93a
Content-Type: text/plain; charset=ISO-8859-1

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.

All the best,

Muhammed

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

Hi Ian,<br><br>Thanks for the response.<br><br>&gt; Perhaps if you explain =
your actual end goal you can be better advised.<br><br>What we are planning=
 to do is to insert some code which can automatically utilise some instruct=
ions from forensics investigation tools (such as a command line tools like =
Sleuthkit), and to do this automatically upon starting up and shutdown / su=
spension of a virtual machine running on the Xen hypervisor in order to aid=
 forensic investigations. Nothing complicated being added but we need to kn=
ow exactly where we would need to put these commands.<br>
<br>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 le=
vel 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&#39;t find anything. <br>
<br>All the best,<br><br>Muhammed<br>
<br><br>

--0016364c7adf411c8704b49cd93a--


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

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

--===============0953533349817179592==--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySa-0001vF-2f; Tue, 03 Jan 2012 07:07:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefanha@gmail.com>) id 1RgaRc-0002u3-AQ
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 11:16:16 +0000
X-Env-Sender: stefanha@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325243770!7309620!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 23238 invoked from network); 30 Dec 2011 11:16:10 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Dec 2011 11:16:10 -0000
Received: by werg1 with SMTP id g1so18833590wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 30 Dec 2011 03:16:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=qp6UCKhvQB1eyBIjQbgsou54ZgSUTtbQJ3xKvSxmuDQ=;
	b=Kn8qxewNIrx0wnc3ZqS5vsQHLKFKePQP0+Fytg6ePFXKIgg9mnArvvrgUsnEG0SZxb
	IYAUE9V5OVWUvj3U2dWQYehNrbUov/am3NDuKvXM+RleumWxojGKrQAlrKFYDZEnBMN6
	eV6aGHaZZ8pEOtjrXxexeVc8vF3SrkVLASKPk=
Received: by 10.216.132.199 with SMTP id o49mr26770810wei.50.1325243770057;
	Fri, 30 Dec 2011 03:16:10 -0800 (PST)
Received: from localhost ([109.224.133.37])
	by mx.google.com with ESMTPS id z5sm91414802wix.5.2011.12.30.03.16.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 30 Dec 2011 03:16:08 -0800 (PST)
Date: Fri, 30 Dec 2011 11:16:09 +0000
From: Stefan Hajnoczi <stefanha@gmail.com>
To: =?utf-8?B?wqTntYLmlrxhd2FyZQ==?= <250716708@qq.com>
Message-ID: <20111230111609.GC1740@stefanha-thinkpad.localdomain>
References: <tencent_37EF499B2FBF40764715DEA6@qq.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tencent_37EF499B2FBF40764715DEA6@qq.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Cc: xen-devel <xen-devel@lists.xensource.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBEZWMgMjMsIDIwMTEgYXQgMDE6MTc6MDBQTSArMDgwMCwgwqTntYLmlrxhd2FyZSB3
cm90ZToKPiAgICAgIElzIGFueW9uZSBjbGVhciBhYm91dCB0aGUgZm9ybWF0IG9mIHFlbXUgZmls
ZSBmb3Igc2F2ZXZtIG9yIGxvYWR2bT8KCklmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiB0aGUgc2Vy
aWFsaXplZCBkZXZpY2Ugc3RhdGUgZm9ybWF0IChlLmcuIHRoZQplMTAwMCBOSUMncyBzZXJpYWxp
emVkIHN0YXRlKSB0aGVuIHRoZSBhbnN3ZXIgaXMgbm8uICBJJ20gbm90IGF3YXJlIG9mCmFueSBz
cGVjaWZpY2F0aW9uIG9yIHNjaGVtYSB0aGF0IGRvY3VtZW50cyB0aGUgZGV2aWNlIHN0YXRlLgoK
SXQgaGFzIGJlZW4ga25vd24gdG8gY2hhbmdlIGluIHRoZSBwYXN0IGFuZCB3cml0aW5nIHRvb2xz
IHRoYXQgZGVwZW5kIG9uCmEgc3BlY2lmaWMgZGV2aWNlIHN0YXRlIGxheW91dCBvdXRzaWRlIG9m
IHFlbXUuZ2l0IGlzIG5vdCB2aWFibGUgdG9kYXkKYmVjYXVzZSB5b3UnbGwgaGF2ZSB0byB3YXRj
aCBxZW11LmdpdCBody8gY29kZSBjaGFuZ2VzIGFuZCB1cGRhdGUgeW91cgpleHRlcm5hbCBjb2Rl
IGV2ZXJ5IHRpbWUgc29tZXRoaW5nIGNoYW5nZXMuICBJdCBzZWVtcyBsaWtlIGEgYmFkIGlkZWEg
dG8KZHVwbGljYXRlIHRoZSBkZXZpY2Ugc3RhdGUgbGF5b3V0IG91dHNpZGUgb2YgcWVtdS5naXQu
CgpGb3IgYSB0ZW1wb3JhcnkgaGFjaywgcmVhZCB0aGUgUUVNVUZpbGUgYW5kIGh3LyBzYXZlL2xv
YWQgY29kZS4gIFlvdSBjYW4KdHJ5IHFlbXUtaW8gLWMgInJlYWQgLWIgMCAkbGVuZ3RoIiB0byBl
eHRyYWN0IHRoZSB2bXN0YXRlIGZyb20gYSBxY293MgppbWFnZSBmaWxlLgoKU3RlZmFuCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySa-0001vF-2f; Tue, 03 Jan 2012 07:07:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stefanha@gmail.com>) id 1RgaRc-0002u3-AQ
	for xen-devel@lists.xensource.com; Fri, 30 Dec 2011 11:16:16 +0000
X-Env-Sender: stefanha@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325243770!7309620!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 23238 invoked from network); 30 Dec 2011 11:16:10 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Dec 2011 11:16:10 -0000
Received: by werg1 with SMTP id g1so18833590wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 30 Dec 2011 03:16:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=qp6UCKhvQB1eyBIjQbgsou54ZgSUTtbQJ3xKvSxmuDQ=;
	b=Kn8qxewNIrx0wnc3ZqS5vsQHLKFKePQP0+Fytg6ePFXKIgg9mnArvvrgUsnEG0SZxb
	IYAUE9V5OVWUvj3U2dWQYehNrbUov/am3NDuKvXM+RleumWxojGKrQAlrKFYDZEnBMN6
	eV6aGHaZZ8pEOtjrXxexeVc8vF3SrkVLASKPk=
Received: by 10.216.132.199 with SMTP id o49mr26770810wei.50.1325243770057;
	Fri, 30 Dec 2011 03:16:10 -0800 (PST)
Received: from localhost ([109.224.133.37])
	by mx.google.com with ESMTPS id z5sm91414802wix.5.2011.12.30.03.16.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 30 Dec 2011 03:16:08 -0800 (PST)
Date: Fri, 30 Dec 2011 11:16:09 +0000
From: Stefan Hajnoczi <stefanha@gmail.com>
To: =?utf-8?B?wqTntYLmlrxhd2FyZQ==?= <250716708@qq.com>
Message-ID: <20111230111609.GC1740@stefanha-thinkpad.localdomain>
References: <tencent_37EF499B2FBF40764715DEA6@qq.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tencent_37EF499B2FBF40764715DEA6@qq.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Cc: xen-devel <xen-devel@lists.xensource.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBEZWMgMjMsIDIwMTEgYXQgMDE6MTc6MDBQTSArMDgwMCwgwqTntYLmlrxhd2FyZSB3
cm90ZToKPiAgICAgIElzIGFueW9uZSBjbGVhciBhYm91dCB0aGUgZm9ybWF0IG9mIHFlbXUgZmls
ZSBmb3Igc2F2ZXZtIG9yIGxvYWR2bT8KCklmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiB0aGUgc2Vy
aWFsaXplZCBkZXZpY2Ugc3RhdGUgZm9ybWF0IChlLmcuIHRoZQplMTAwMCBOSUMncyBzZXJpYWxp
emVkIHN0YXRlKSB0aGVuIHRoZSBhbnN3ZXIgaXMgbm8uICBJJ20gbm90IGF3YXJlIG9mCmFueSBz
cGVjaWZpY2F0aW9uIG9yIHNjaGVtYSB0aGF0IGRvY3VtZW50cyB0aGUgZGV2aWNlIHN0YXRlLgoK
SXQgaGFzIGJlZW4ga25vd24gdG8gY2hhbmdlIGluIHRoZSBwYXN0IGFuZCB3cml0aW5nIHRvb2xz
IHRoYXQgZGVwZW5kIG9uCmEgc3BlY2lmaWMgZGV2aWNlIHN0YXRlIGxheW91dCBvdXRzaWRlIG9m
IHFlbXUuZ2l0IGlzIG5vdCB2aWFibGUgdG9kYXkKYmVjYXVzZSB5b3UnbGwgaGF2ZSB0byB3YXRj
aCBxZW11LmdpdCBody8gY29kZSBjaGFuZ2VzIGFuZCB1cGRhdGUgeW91cgpleHRlcm5hbCBjb2Rl
IGV2ZXJ5IHRpbWUgc29tZXRoaW5nIGNoYW5nZXMuICBJdCBzZWVtcyBsaWtlIGEgYmFkIGlkZWEg
dG8KZHVwbGljYXRlIHRoZSBkZXZpY2Ugc3RhdGUgbGF5b3V0IG91dHNpZGUgb2YgcWVtdS5naXQu
CgpGb3IgYSB0ZW1wb3JhcnkgaGFjaywgcmVhZCB0aGUgUUVNVUZpbGUgYW5kIGh3LyBzYXZlL2xv
YWQgY29kZS4gIFlvdSBjYW4KdHJ5IHFlbXUtaW8gLWMgInJlYWQgLWIgMCAkbGVuZ3RoIiB0byBl
eHRyYWN0IHRoZSB2bXN0YXRlIGZyb20gYSBxY293MgppbWFnZSBmaWxlLgoKU3RlZmFuCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySZ-0001ur-MW; Tue, 03 Jan 2012 07:06:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lero420@gmail.com>) id 1RgDxC-0003Dz-Ue
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:15:23 +0000
X-Env-Sender: lero420@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325157315!8953910!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 23576 invoked from network); 29 Dec 2011 11:15:16 -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;
	29 Dec 2011 11:15:16 -0000
Received: by iagw33 with SMTP id w33so110188144iag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 29 Dec 2011 03:15:14 -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=M1hxZqhf4KAue/SEMFokbSgz/DqOAeLQZ2c2f7FERk8=;
	b=grRYSZWdSYBZLNjyDwpLa20IaoSkR/iGLT6DDuZa+XVSJp8td7RdyGm7+VAozLkmdl
	as/35viz0NByJnfja28KxRiozw9Vaf05bx2X5beajRrxh4BuozygniFhe1AOkU2Ehkxd
	GHURnoA6+ja+M2d0Trvm0o1ovvv7OvbHkg5lI=
MIME-Version: 1.0
Received: by 10.50.181.136 with SMTP id dw8mr39802977igc.6.1325157314296; Thu,
	29 Dec 2011 03:15:14 -0800 (PST)
Received: by 10.50.104.2 with HTTP; Thu, 29 Dec 2011 03:15:14 -0800 (PST)
Date: Thu, 29 Dec 2011 09:15:14 -0200
X-Google-Sender-Auth: FHHvnQdpUFZEmaxcSlCLWZhvChE
Message-ID: <CAPxDueV_2oNTFQocbGY67Y9Cq2=wwX7VGL7+WayeSxu6Y_L1Nw@mail.gmail.com>
From: "guilherme m. schroeder" <guialemas@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Subject: [Xen-devel] dom0 crash on csched_acct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 having some random crashes with XenServer 5.6 SP2 (Xen 3.4.2).
I thought that it was a problem with Xen 3.4 and tried XenServer 6.0
(Xen 4.1.1), but no luck.
I know that this list is about XenSource and (maybe) doesn't cover it,
but i'm trying to understand
what is happening.

All i have is this crash.log: http://cpro3845.publiccloud.com.br/crash.log

Kdump segfaults on XenServer, so no core to help.

I took a look on sched_credit.c +978 and this is what triggering the crash:

        BUG_ON( (sdom->weight * sdom->active_vcpu_count) > weight_left );

We have some VM's that have different vCPU priority values. Could be
this that is triggering the problem?
Also, there is a limit for vcpu_count on a host?

I'm still trying to reproduce the crash, but it's totally random.
Does anyone have an idea or where to start?

If more details are needed, let me know.

Thanks.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhySZ-0001ur-MW; Tue, 03 Jan 2012 07:06:59 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lero420@gmail.com>) id 1RgDxC-0003Dz-Ue
	for xen-devel@lists.xensource.com; Thu, 29 Dec 2011 11:15:23 +0000
X-Env-Sender: lero420@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325157315!8953910!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 23576 invoked from network); 29 Dec 2011 11:15:16 -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;
	29 Dec 2011 11:15:16 -0000
Received: by iagw33 with SMTP id w33so110188144iag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 29 Dec 2011 03:15:14 -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=M1hxZqhf4KAue/SEMFokbSgz/DqOAeLQZ2c2f7FERk8=;
	b=grRYSZWdSYBZLNjyDwpLa20IaoSkR/iGLT6DDuZa+XVSJp8td7RdyGm7+VAozLkmdl
	as/35viz0NByJnfja28KxRiozw9Vaf05bx2X5beajRrxh4BuozygniFhe1AOkU2Ehkxd
	GHURnoA6+ja+M2d0Trvm0o1ovvv7OvbHkg5lI=
MIME-Version: 1.0
Received: by 10.50.181.136 with SMTP id dw8mr39802977igc.6.1325157314296; Thu,
	29 Dec 2011 03:15:14 -0800 (PST)
Received: by 10.50.104.2 with HTTP; Thu, 29 Dec 2011 03:15:14 -0800 (PST)
Date: Thu, 29 Dec 2011 09:15:14 -0200
X-Google-Sender-Auth: FHHvnQdpUFZEmaxcSlCLWZhvChE
Message-ID: <CAPxDueV_2oNTFQocbGY67Y9Cq2=wwX7VGL7+WayeSxu6Y_L1Nw@mail.gmail.com>
From: "guilherme m. schroeder" <guialemas@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Subject: [Xen-devel] dom0 crash on csched_acct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 having some random crashes with XenServer 5.6 SP2 (Xen 3.4.2).
I thought that it was a problem with Xen 3.4 and tried XenServer 6.0
(Xen 4.1.1), but no luck.
I know that this list is about XenSource and (maybe) doesn't cover it,
but i'm trying to understand
what is happening.

All i have is this crash.log: http://cpro3845.publiccloud.com.br/crash.log

Kdump segfaults on XenServer, so no core to help.

I took a look on sched_credit.c +978 and this is what triggering the crash:

        BUG_ON( (sdom->weight * sdom->active_vcpu_count) > weight_left );

We have some VM's that have different vCPU priority values. Could be
this that is triggering the problem?
Also, there is a limit for vcpu_count on a host?

I'm still trying to reproduce the crash, but it's totally random.
Does anyone have an idea or where to start?

If more details are needed, let me know.

Thanks.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07:07:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhySY-0001t1-0M; Tue, 03 Jan 2012 07:06:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xubo.njust@gmail.com>) id 1RfXs5-0007VO-Kf
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 14:19:17 +0000
X-Env-Sender: xubo.njust@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324995551!8933442!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 2348 invoked from network); 27 Dec 2011 14:19:11 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 14:19:11 -0000
Received: by eaad11 with SMTP id d11so42671049eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 27 Dec 2011 06:19:11 -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=STtr0SZ/HX/k6BfXIcTdoKcBM5zxdCrv50boMw1vlQc=;
	b=Z0pbyZGgfNVC4xMsO9EkzjYsYmR8/TFrjsptwpE4Y35z9OkfGnMzPxbWJ9wWOejAXb
	e5TaHRoN5claEcDs70ci0NfEsa9ZzXLB5Rtr2naOauRbtC35xT/+7B7qLcIu1TIn3w7x
	qFOBKDu1T8CTelMkRdEyQDZ9uFmJEGHQh1JgI=
MIME-Version: 1.0
Received: by 10.204.143.155 with SMTP id v27mr2333661bku.50.1324995550689;
	Tue, 27 Dec 2011 06:19:10 -0800 (PST)
Received: by 10.204.24.209 with HTTP; Tue, 27 Dec 2011 06:19:10 -0800 (PST)
Date: Tue, 27 Dec 2011 22:19:10 +0800
Message-ID: <CAFLYXnC94icOGyBZN6SHS5v=+z64zf6L9RWq-2UDy9FP4G5inw@mail.gmail.com>
From: Bo Xu <xubo.njust@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Subject: [Xen-devel] Does Xen Driver Domain support 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

Hello, everyone.
I am new to Xen, I don't know if Xen Driver Domain, network for
example, support the HVM DomU, like a windows DomU?
Can the windows DomU connect to Internet through the network driver
domain without problem.
The system is Debian squeeze 6.0 x86-64 with xen-hypervisor-4.0-amd64,
xen-qemu-dm-4.0, xen-linux-system-2.6-xen-amd64.

Best Regards!

Ben

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:07:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07:07:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RhySY-0001t1-0M; Tue, 03 Jan 2012 07:06:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xubo.njust@gmail.com>) id 1RfXs5-0007VO-Kf
	for xen-devel@lists.xensource.com; Tue, 27 Dec 2011 14:19:17 +0000
X-Env-Sender: xubo.njust@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1324995551!8933442!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 2348 invoked from network); 27 Dec 2011 14:19:11 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Dec 2011 14:19:11 -0000
Received: by eaad11 with SMTP id d11so42671049eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 27 Dec 2011 06:19:11 -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=STtr0SZ/HX/k6BfXIcTdoKcBM5zxdCrv50boMw1vlQc=;
	b=Z0pbyZGgfNVC4xMsO9EkzjYsYmR8/TFrjsptwpE4Y35z9OkfGnMzPxbWJ9wWOejAXb
	e5TaHRoN5claEcDs70ci0NfEsa9ZzXLB5Rtr2naOauRbtC35xT/+7B7qLcIu1TIn3w7x
	qFOBKDu1T8CTelMkRdEyQDZ9uFmJEGHQh1JgI=
MIME-Version: 1.0
Received: by 10.204.143.155 with SMTP id v27mr2333661bku.50.1324995550689;
	Tue, 27 Dec 2011 06:19:10 -0800 (PST)
Received: by 10.204.24.209 with HTTP; Tue, 27 Dec 2011 06:19:10 -0800 (PST)
Date: Tue, 27 Dec 2011 22:19:10 +0800
Message-ID: <CAFLYXnC94icOGyBZN6SHS5v=+z64zf6L9RWq-2UDy9FP4G5inw@mail.gmail.com>
From: Bo Xu <xubo.njust@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 03 Jan 2012 07:06:56 +0000
Subject: [Xen-devel] Does Xen Driver Domain support 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

Hello, everyone.
I am new to Xen, I don't know if Xen Driver Domain, network for
example, support the HVM DomU, like a windows DomU?
Can the windows DomU connect to Internet through the network driver
domain without problem.
The system is Debian squeeze 6.0 x86-64 with xen-hypervisor-4.0-amd64,
xen-qemu-dm-4.0, xen-linux-system-2.6-xen-amd64.

Best Regards!

Ben

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 07:33:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhysR-0006f5-EX; Tue, 03 Jan 2012 07:33:43 +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 1RhysP-0006eb-Jw
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 07:33:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325576015!9456118!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12923 invoked from network); 3 Jan 2012 07:33:35 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 07:33:35 -0000
Received: by werg1 with SMTP id g1so21911428wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 02 Jan 2012 23:33:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0KSPtoY6PAvZWPx1dVMzSVBusGh+AqS560C3En+2vqY=;
	b=seFXbEqOZDeOXUHABipRNv4EshoZ9zAGaQgtCoP9ifr0uU6sqjTkP3ODPWL9WKURMg
	fdY/AUZv06UZwEFu9HHR8LpMuFbypb0gp+p1rM8bBB4FZ1zW9taebKB53HGqTV6UQET+
	S36LuCoI7YevA/8vBtGSMnSUEgDon49oFsEoU=
Received: by 10.216.131.29 with SMTP id l29mr6357234wei.5.1325576015309;
	Mon, 02 Jan 2012 23:33:35 -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 v28sm12128864wbo.18.2012.01.02.23.33.31
	(version=SSLv3 cipher=OTHER); Mon, 02 Jan 2012 23:33:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 03 Jan 2012 07:33:28 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Liu.yi" <liu.yi24@zte.com.cn>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB285FC8.280CB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] credit scheduler svc->flags access race?
Thread-Index: AczJ6fwKFwBD13MQzEO9Mu6sMgle3w==
In-Reply-To: <1325300125668-5111504.post@n5.nabble.com>
Mime-version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: Re: [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

On 31/12/2011 02:55, "Liu.yi" <liu.yi24@zte.com.cn> wrote:

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

Cc'ing George Dunlap. This is probably a good bug fix.

 -- Keir

> --- 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-tp5111
> 504p5111504.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 Jan 03 07:33:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 07: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 1RhysR-0006f5-EX; Tue, 03 Jan 2012 07:33:43 +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 1RhysP-0006eb-Jw
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 07:33:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325576015!9456118!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12923 invoked from network); 3 Jan 2012 07:33:35 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 07:33:35 -0000
Received: by werg1 with SMTP id g1so21911428wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 02 Jan 2012 23:33:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=0KSPtoY6PAvZWPx1dVMzSVBusGh+AqS560C3En+2vqY=;
	b=seFXbEqOZDeOXUHABipRNv4EshoZ9zAGaQgtCoP9ifr0uU6sqjTkP3ODPWL9WKURMg
	fdY/AUZv06UZwEFu9HHR8LpMuFbypb0gp+p1rM8bBB4FZ1zW9taebKB53HGqTV6UQET+
	S36LuCoI7YevA/8vBtGSMnSUEgDon49oFsEoU=
Received: by 10.216.131.29 with SMTP id l29mr6357234wei.5.1325576015309;
	Mon, 02 Jan 2012 23:33:35 -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 v28sm12128864wbo.18.2012.01.02.23.33.31
	(version=SSLv3 cipher=OTHER); Mon, 02 Jan 2012 23:33:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 03 Jan 2012 07:33:28 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: "Liu.yi" <liu.yi24@zte.com.cn>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB285FC8.280CB%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] credit scheduler svc->flags access race?
Thread-Index: AczJ6fwKFwBD13MQzEO9Mu6sMgle3w==
In-Reply-To: <1325300125668-5111504.post@n5.nabble.com>
Mime-version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: Re: [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

On 31/12/2011 02:55, "Liu.yi" <liu.yi24@zte.com.cn> wrote:

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

Cc'ing George Dunlap. This is probably a good bug fix.

 -- Keir

> --- 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-tp5111
> 504p5111504.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 Jan 03 08:57:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 08:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri0Ah-00084k-3a; Tue, 03 Jan 2012 08:56:39 +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 1Ri0Af-00084f-S8
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 08:56:38 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1325580991!9522590!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 15915 invoked from network); 3 Jan 2012 08:56:31 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Jan 2012 08:56:31 -0000
Received: from mail9-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, 3 Jan 2012 08:56:31 +0000
Received: from mail9-db3 (localhost [127.0.0.1])	by mail9-db3-R.bigfish.com
	(Postfix) with ESMTP id 06EB66A00E6;
	Tue,  3 Jan 2012 08:56:31 +0000 (UTC)
X-SpamScore: -14
X-BigFish: VPS-14(zz1447M1432N98dKzz1202hzz8275bhz2dh668h839h)
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 mail9-db3 (localhost.localdomain [127.0.0.1]) by mail9-db3
	(MessageSwitch) id 1325580941734039_31450;
	Tue,  3 Jan 2012 08:55:41 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.243])	by
	mail9-db3.bigfish.com (Postfix) with ESMTP id AFA361A0042;
	Tue,  3 Jan 2012 08:55:41 +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; Tue, 3 Jan 2012 08:55:41 +0000
X-WSS-ID: 0LX7SSM-02-493-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 280B3C8123;	Tue,  3 Jan 2012 02:55:33 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 3 Jan 2012 02:55: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;
	Tue, 3 Jan 2012 02:55:37 -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, 3 Jan 2012
	03:55:36 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6954049C58B; Tue,  3 Jan 2012
	08:55:35 +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 535795940FF; Tue,  3 Jan 2012
	09:55:35 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 3 Jan 2012 09:58:06 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<bf9f21ad9a0ec245b409.1324639755@gran.amd.com>
	<4F01BB6C020000780006A0FE@nat28.tlf.novell.com>
In-Reply-To: <4F01BB6C020000780006A0FE@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201030958.08981.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

Hi Jan,
Thanks for the review. I will fix all of them in the next try.
Wei

On Monday 02 January 2012 14:13:00 Jan Beulich wrote:
> >>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> >
> > --- 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 ...
> >      spin_unlock_irqrestore(&iommu->lock, flags);
> >  }
> >
> > +void parse_ppr_log_entry(struct amd_iommu *iommu, u32 entry[])
>
> static?
>
> > +{
> > +
> > +    u16 device_id;
> >...
>
> Jan




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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 08:57:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 08:57:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri0Ah-00084k-3a; Tue, 03 Jan 2012 08:56:39 +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 1Ri0Af-00084f-S8
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 08:56:38 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1325580991!9522590!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 15915 invoked from network); 3 Jan 2012 08:56:31 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-5.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Jan 2012 08:56:31 -0000
Received: from mail9-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, 3 Jan 2012 08:56:31 +0000
Received: from mail9-db3 (localhost [127.0.0.1])	by mail9-db3-R.bigfish.com
	(Postfix) with ESMTP id 06EB66A00E6;
	Tue,  3 Jan 2012 08:56:31 +0000 (UTC)
X-SpamScore: -14
X-BigFish: VPS-14(zz1447M1432N98dKzz1202hzz8275bhz2dh668h839h)
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 mail9-db3 (localhost.localdomain [127.0.0.1]) by mail9-db3
	(MessageSwitch) id 1325580941734039_31450;
	Tue,  3 Jan 2012 08:55:41 +0000 (UTC)
Received: from DB3EHSMHS011.bigfish.com (unknown [10.3.81.243])	by
	mail9-db3.bigfish.com (Postfix) with ESMTP id AFA361A0042;
	Tue,  3 Jan 2012 08:55:41 +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; Tue, 3 Jan 2012 08:55:41 +0000
X-WSS-ID: 0LX7SSM-02-493-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 280B3C8123;	Tue,  3 Jan 2012 02:55:33 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 3 Jan 2012 02:55: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;
	Tue, 3 Jan 2012 02:55:37 -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, 3 Jan 2012
	03:55:36 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6954049C58B; Tue,  3 Jan 2012
	08:55:35 +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 535795940FF; Tue,  3 Jan 2012
	09:55:35 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 3 Jan 2012 09:58:06 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<bf9f21ad9a0ec245b409.1324639755@gran.amd.com>
	<4F01BB6C020000780006A0FE@nat28.tlf.novell.com>
In-Reply-To: <4F01BB6C020000780006A0FE@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201030958.08981.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

Hi Jan,
Thanks for the review. I will fix all of them in the next try.
Wei

On Monday 02 January 2012 14:13:00 Jan Beulich wrote:
> >>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> >
> > --- 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 ...
> >      spin_unlock_irqrestore(&iommu->lock, flags);
> >  }
> >
> > +void parse_ppr_log_entry(struct amd_iommu *iommu, u32 entry[])
>
> static?
>
> > +{
> > +
> > +    u16 device_id;
> >...
>
> Jan




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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 09:45:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 09: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 1Ri0vG-0008WG-4D; Tue, 03 Jan 2012 09:44:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri0vE-0008WB-VI
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 09:44:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325583878!10169882!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27969 invoked from network); 3 Jan 2012 09:44:38 -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;
	3 Jan 2012 09:44:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9785181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 09:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	09:44:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 3 Jan 2012 09:44:37 +0000
In-Reply-To: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325583878.25206.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] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU2F0LCAyMDExLTEyLTI0IGF0IDExOjA4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IEknbSB0cnlpbmcgdG8gY3JlYXRlIGEgWGVuIERvbTAgTGl2ZUNEL3Vz
YiwgYmFzZWQgb24gQWxwaW5lIExpbnV4LAo+IHdoaWNoIGhhcyBncmVhdCBzdXBwb3J0IGZvciB0
aGlzIGtpbmQgb2Ygc3R1ZmYuCgpDb29sIQoKPiBJJ3ZlIGJlZW4gYWJsZSB0bwo+IHN1Y2Nlc3Nm
dWxseSBpbnN0YWxsIGFuZCBib290IFhlbiBrZXJuZWwgYW5kIHRvb2xzIGZyb20gYW4gSEREIHVz
aW5nCj4gdGhlIHNhbWUgY29uZmlndXJhdGlvbiwgYnV0IHdoZW4gdXNpbmcgYSB0bXBmcyBiYXNl
ZCBib290LCB0aGUgTGludXgKPiBrZXJuZWwgMy4wLjEwIGNyYXNoZXMgd2hpbGUgbG9hZGluZyBz
b21lIG1vZHVsZXMgKFhlbiBrZXJuZWwgc2VlbXMgdG8KPiBib290IGZpbmUpLiBYZW4gdmVyc2lv
biBpcyBzdGFibGUgNC4xLjIgYW5kIExpbnV4IGtlcm5lbCBpcwo+IDMuMC4xMC1ncnNlYy4gSGVy
ZSBpcyB0aGUgZnVsbCBvdXRwdXQgb2YgdGhlIGJvb3QgcHJvY2VzczoKWy4uLl0KPiAgKiBQb3B1
bGF0aW5nIC9kZXYgd2l0aCBleGlzdGluZyBkZXZpY2VzIHRocm91Z2ggdWV2ZW50cyAuLi4gWyBv
ayBdCj4gICogV2FpdGluZyBmb3IgdWV2ZW50cyB0byBiZSBwcm9jZXNzZWQgLi4uIFsgb2sgXQo+
ICAqIE1vdW50aW5nIG1vZGxvb3AgL21lZGlhL3VzYi9ib290L2dyc2VjLm1vZGxvb3Auc3F1YXNo
ZnMgLi4uIFsgb2sgXQo+ICAqIExvYWRpbmcgaGFyZHdhcmUgZHJpdmVycyAuLi5Mb2FkaW5nIGFj
cGk6QUNQSTAwMDM6Cj4gTG9hZGluZyBhY3BpOkxOWENQVToKPiBMb2FkaW5nIGFjcGk6TE5YUFdS
Qk46Cj4gWyAgIDIzLjA4MDgzN10gQlVHOiB1bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcg
cmVxdWVzdCBhdCBmZmZmZThmZmZmZDNiZmM0Cj4gWyAgIDIzLjA4Nzk5MV0gSVA6IFs8ZmZmZmZm
ZmY4MTA2MjAyNj5dIG1vZHVsZV9yZWZjb3VudCsweDJlLzB4OTkKPiBbICAgMjMuMDkxNzQzXSBQ
R0QgMzUxZDYwNjcgUFVEIDM1MWQ3MDY3IFBNRCAzNTI4ODA2NyBQVEUgMAo+IFsgICAyMy4wOTQ1
MzBdIE9vcHM6IDAwMDAgWyMxXSBTTVAKPiBbICAgMjMuMDk1ODUyXSBDUFUgMAo+IFsgICAyMy4w
OTY1NjFdIE1vZHVsZXMgbGlua2VkIGluOiBwcm9jZXNzb3IgYWMgbmxzX2lzbzg4NTlfMSBubHNf
Y3A0MzcKPiB2ZmF0IGZhdCBzcl9tb2QgY2Ryb20gYXRhX2dlbmVyaWMgYXRhX3BpaXggcGF0YV9h
Y3BpIGxpYmF0YSB1aGNpX2hjZAo+IGVoY2lfaGNkIG1wdHNwaSBtcHRzY3NpaCBtcHRiYXNlIHNj
c2lfdHJhbnNwb3J0X3NwaSBmbG9wcHkgdXNiX3N0b3JhZ2UKPiB1c2JfbGlidXN1YWwgdXNiY29y
ZSBzZF9tb2Qgc2NzaV9tb2Qgc3F1YXNoZnMgbG9vcAo+IFsgICAyMy4xMjExNjVdCj4gWyAgIDIz
LjEyMTgwMV0gUGlkOiAxNjI2LCBjb21tOiBtb2Rwcm9iZSBOb3QgdGFpbnRlZCAzLjAuMTAtZ3Jz
ZWMKPiAjMS1BbHBpbmUgVk13YXJlLCBJbmMuIFZNd2FyZSBWaXJ0dWFsIFBsYXRmb3JtLzQ0MEJY
IERlc2t0b3AgUmVmZXJlbmNlCj4gUGxhdGZvcm0KPiBbICAgMjMuMTI4MjQyXSBSSVA6IGUwMzA6
WzxmZmZmZmZmZjgxMDYyMDI2Pl0gIFs8ZmZmZmZmZmY4MTA2MjAyNj5dCj4gbW9kdWxlX3JlZmNv
dW50KzB4MmUvMHg5OQo+IFsgICAyMy4xMzQ5OTRdIFJTUDogZTAyYjpmZmZmODgwMDM1MWRkZDg4
ICBFRkxBR1M6IDAwMDEwMjg3Cj4gWyAgIDIzLjEzNjk5N10gUkFYOiAwMDAwMDAwMDAwMDAwMDAx
IFJCWDogMDAwMDAwMDAwMDAwMDAwMSBSQ1g6IGZmZmY4ODAwM2FlYTgwMDAKPiBbICAgMjMuMTQw
MTEzXSBSRFg6IDAwMDA2MGZmYzRlOTNmYzAgUlNJOiAwMDAwMDAwMDAwMDAwMDIwIFJESTogMDAw
MDAwMDAwMDAwMDAyMAo+IFsgICAyMy4xNDM5MzldIFJCUDogZmZmZjg4MDAzNTFkZGRhOCBSMDg6
IDAwMDAwMDAwMDAwMDAwMDAgUjA5OiBmZmZmZmZmZjgxNGFhNTIwCj4gWyAgIDIzLjE0NjY1Nl0g
UjEwOiBmZmZmODgwMDM0NWQ1MDAwIFIxMTogMDAwMDAwMDAwMDAwMDAwMCBSMTI6IGZmZmZmZmZm
ODE0YWE1MjAKPiBbICAgMjMuMTQ5MzU0XSBSMTM6IGZmZmZmZmZmYTAxNGI3YTAgUjE0OiAwMDAw
MDAwMDAwMDAxMDAwIFIxNTogZmZmZmZmZmZhMDE0Yjk2OAo+IFsgICAyMy4xNTc2NzNdIEZTOiAg
MDAwMDVmYjAxNzU2NDZhMCgwMDAwKSBHUzpmZmZmODgwMDNhZTkxMDAwKDAwMDApCj4ga25sR1M6
MDAwMDAwMDAwMDAwMDAwMAo+IFsgICAyMy4xNjIzNTRdIENTOiAgZTAzMyBEUzogMDAwMCBFUzog
MDAwMCBDUjA6IDAwMDAwMDAwODAwNTAwM2IKPiBbICAgMjMuMTY0NzM2XSBDUjI6IGZmZmZlOGZm
ZmZkM2JmYzQgQ1IzOiAwMDAwMDAwMDMzOWIzMDAwIENSNDogMDAwMDAwMDAwMDAwMDY2MAo+IFsg
ICAyMy4xNjc5NTRdIERSMDogMDAwMDAwMDAwMDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAg
RFIyOiAwMDAwMDAwMDAwMDAwMDAwCj4gWyAgIDIzLjE3MDcxOV0gRFIzOiAwMDAwMDAwMDAwMDAw
MDAwIERSNjogMDAwMDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0MDAKPiBbICAgMjMu
MTc0MTA5XSBQcm9jZXNzIG1vZHByb2JlIChwaWQ6IDE2MjYsIHRocmVhZGluZm8KPiBmZmZmODgw
MDM0NzdhYjU4LCB0YXNrIGZmZmY4ODAwMzQ3N2E3NjApCj4gWyAgIDIzLjE3ODY2MV0gU3RhY2s6
Cj4gWyAgIDIzLjE3OTQ2Nl0gIGZmZmZmZmZmYTAxNGI3YTggZmZmZjg4MDAzNDMzNDMwMCBmZmZm
ZmZmZmEwMTRiN2EwCj4gMDAwMDAwMDAwMDAwMTAwMAo+IFsgICAyMy4xODI3ODddICBmZmZmODgw
MDM1MWRkZGY4IGZmZmZmZmZmODEwNjIxMWMgZmZmZjg4MDAzNTMwMDQyMAo+IDAwMDA1ZmIwMTZj
ZmZkMTAKPiBbICAgMjMuMTg5NDk0XSAgZmZmZjg4MDAzNTFkZGRmOCBmZmZmODgwMDM0MzM0MzAw
IDAwMDAwMDAwMDAwMDAwMDAKPiAwMDAwMGZlY2RhMGJjZDkwCj4gWyAgIDIzLjE5ODYxOF0gQ2Fs
bCBUcmFjZToKPiBbICAgMjMuMjAwNjI0XSAgWzxmZmZmZmZmZjgxMDYyMTFjPl0gbV9zaG93KzB4
NTQvMHgxNmIKPiBbICAgMjMuMjAyNTEyXSAgWzxmZmZmZmZmZjgxMGQxYjVjPl0gc2VxX3JlYWQr
MHgyNDcvMHg1MWYKPiBbICAgMjMuMjA0NDgzXSAgWzxmZmZmZmZmZjgxMGZjY2MyPl0gcHJvY19y
ZWdfcmVhZCsweDZjLzB4ODUKPiBbICAgMjMuMjA2NTQzXSAgWzxmZmZmZmZmZjgxMGI2MTRmPl0g
dmZzX3JlYWQrMHgxMDQvMHgxOTgKPiBbICAgMjMuMjA4OTA5XSAgWzxmZmZmZmZmZjgxMGI2MjI4
Pl0gc3lzX3JlYWQrMHg0NS8weDZjCj4gWyAgIDIzLjIxMTA3NV0gIFs8ZmZmZmZmZmY4MTJhYTE0
Yj5dIHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYgo+IFsgICAyMy4yMTU3OTZdICBbPGZm
ZmZmZmZmODEyYWEwZTk+XSA/IHN5c3RlbV9jYWxsX2FmdGVyX3N3YXBncysweDE5LzB4NjUKPiBb
ICAgMjMuMjE5MTk2XSBDb2RlOiBmZiA0OCA4OSBlNSA0MSA1NiA0MSA1NSA0OSA4OSBmZCA0MSA1
NCA0YyA4YiAyNQo+IDc5IDEyIDI5IDAwIDUzIDMxIGRiIGViIDE2IDQ4IDYzIGM4IDQ5IDhiIDk1
IGY4IDAxIDAwIDAwIDQ4IDhiIDBjIGNkCj4gNTAgNjAgM2EgODEKPiBbICAgMjMuMjI4Nzc0XSAg
NWMgMGEgMDQgZmYgYzAgYmUgMjAgMDAgMDAgMDAgNGMgODkgZTcgNDggNjMgZDAgZTggMzQgMjQg
MGUKPiBbICAgMjMuMjM1MjIzXSBSSVAgIFs8ZmZmZmZmZmY4MTA2MjAyNj5dIG1vZHVsZV9yZWZj
b3VudCsweDJlLzB4OTkKPiBbICAgMjMuMjQwNzE4XSAgUlNQIDxmZmZmODgwMDM1MWRkZDg4Pgo+
IFsgICAyMy4yNDM5MTJdIENSMjogZmZmZmU4ZmZmZmQzYmZjNAo+IFsgICAyMy4yNDUyNTZdIC0t
LVsgZW5kIHRyYWNlIDQ3NjNhZGRkOWZiMjI2ZTUgXS0tLQo+IEtpbGxlZAo+IExvYWRpbmcgYWNw
aTpMTlhTWVNUTToKPiAKPiBJJ3ZlIGNoYW5nZWQgdGhlIGluaXQgc2NyaXB0IHRvIGxvYWQgZWFj
aCBtb2R1bGUgc2VwYXJhdGVkbHksIGluc3RlYWQKPiBvZiBkb2luZyBhIG1vZHByb2JlIC1hIDxh
bGwgbW9kdWxlcz4sIGlmIEkgbG9hZGVkIGFsbCB0aGUgbW9kdWxlcyBhdAo+IG9uY2UgdGhlIHN5
c3RlbSBjcmFzaGVkIGluc3RlYWQgb2YgZnJlZXppbmcuIFRoZSBwcm9ibGVtIHNlZW1zIHRvIGJl
Cj4gcmVsYXRlZCB0byBhY3BpLCBhbmQgdGhlIG1vZHVsZXMgYXJlIGxvYWRlZCBmcm9tIGEgc3F1
YXNoZnMgaW1hZ2UKPiBtb3VudGVkIG9uIGxvb3AwLiBEb2VzIGFueW9uZSBrbm93IHdoYXQgbWln
aHQgYmUgY2F1c2luZyB0aGlzIGlzc3VlIG9yCj4gaWYgdGhlcmUgaXMgYSBwb3NzaWJsZSBmaXg/
CgpOb3RoaW5nIHNwcmluZ3MgdG8gbWluZC4gT24gdGhlIGZhY2Ugb2YgaXQgdGhpcyBkb2Vzbid0
IGxvb2sgYWxsIHRoYXQKWGVuIHNwZWNpZmljIC0tIGlmIHlvdSBib290IHRoZSBzYW1lIExpbnV4
IGtlcm5lbCB3aXRob3V0IFhlbiB1bmRlcm5lYXRoCihidXQgb3RoZXJ3aXNlIGluIHRoZSBzYW1l
IGNvbmZpZ3VyYXRpb24pIGRvZXMgaXQgd29yaz8KCllvdSBhcmUgdXNpbmcgdGhlIC1ncnNlYyBw
YXRjaGVzIHZlcnNpb24gb2YgTGludXgsIGRvZXMgYSB2YW5pbGxhCm1haW5saW5lIGhhdmUgdGhl
IHNhbWUgaXNzdWU/CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 03 09:45:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 09: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 1Ri0vG-0008WG-4D; Tue, 03 Jan 2012 09:44:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri0vE-0008WB-VI
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 09:44:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325583878!10169882!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27969 invoked from network); 3 Jan 2012 09:44:38 -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;
	3 Jan 2012 09:44:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9785181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 09:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	09:44:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 3 Jan 2012 09:44:37 +0000
In-Reply-To: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325583878.25206.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] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gU2F0LCAyMDExLTEyLTI0IGF0IDExOjA4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IEknbSB0cnlpbmcgdG8gY3JlYXRlIGEgWGVuIERvbTAgTGl2ZUNEL3Vz
YiwgYmFzZWQgb24gQWxwaW5lIExpbnV4LAo+IHdoaWNoIGhhcyBncmVhdCBzdXBwb3J0IGZvciB0
aGlzIGtpbmQgb2Ygc3R1ZmYuCgpDb29sIQoKPiBJJ3ZlIGJlZW4gYWJsZSB0bwo+IHN1Y2Nlc3Nm
dWxseSBpbnN0YWxsIGFuZCBib290IFhlbiBrZXJuZWwgYW5kIHRvb2xzIGZyb20gYW4gSEREIHVz
aW5nCj4gdGhlIHNhbWUgY29uZmlndXJhdGlvbiwgYnV0IHdoZW4gdXNpbmcgYSB0bXBmcyBiYXNl
ZCBib290LCB0aGUgTGludXgKPiBrZXJuZWwgMy4wLjEwIGNyYXNoZXMgd2hpbGUgbG9hZGluZyBz
b21lIG1vZHVsZXMgKFhlbiBrZXJuZWwgc2VlbXMgdG8KPiBib290IGZpbmUpLiBYZW4gdmVyc2lv
biBpcyBzdGFibGUgNC4xLjIgYW5kIExpbnV4IGtlcm5lbCBpcwo+IDMuMC4xMC1ncnNlYy4gSGVy
ZSBpcyB0aGUgZnVsbCBvdXRwdXQgb2YgdGhlIGJvb3QgcHJvY2VzczoKWy4uLl0KPiAgKiBQb3B1
bGF0aW5nIC9kZXYgd2l0aCBleGlzdGluZyBkZXZpY2VzIHRocm91Z2ggdWV2ZW50cyAuLi4gWyBv
ayBdCj4gICogV2FpdGluZyBmb3IgdWV2ZW50cyB0byBiZSBwcm9jZXNzZWQgLi4uIFsgb2sgXQo+
ICAqIE1vdW50aW5nIG1vZGxvb3AgL21lZGlhL3VzYi9ib290L2dyc2VjLm1vZGxvb3Auc3F1YXNo
ZnMgLi4uIFsgb2sgXQo+ICAqIExvYWRpbmcgaGFyZHdhcmUgZHJpdmVycyAuLi5Mb2FkaW5nIGFj
cGk6QUNQSTAwMDM6Cj4gTG9hZGluZyBhY3BpOkxOWENQVToKPiBMb2FkaW5nIGFjcGk6TE5YUFdS
Qk46Cj4gWyAgIDIzLjA4MDgzN10gQlVHOiB1bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBwYWdpbmcg
cmVxdWVzdCBhdCBmZmZmZThmZmZmZDNiZmM0Cj4gWyAgIDIzLjA4Nzk5MV0gSVA6IFs8ZmZmZmZm
ZmY4MTA2MjAyNj5dIG1vZHVsZV9yZWZjb3VudCsweDJlLzB4OTkKPiBbICAgMjMuMDkxNzQzXSBQ
R0QgMzUxZDYwNjcgUFVEIDM1MWQ3MDY3IFBNRCAzNTI4ODA2NyBQVEUgMAo+IFsgICAyMy4wOTQ1
MzBdIE9vcHM6IDAwMDAgWyMxXSBTTVAKPiBbICAgMjMuMDk1ODUyXSBDUFUgMAo+IFsgICAyMy4w
OTY1NjFdIE1vZHVsZXMgbGlua2VkIGluOiBwcm9jZXNzb3IgYWMgbmxzX2lzbzg4NTlfMSBubHNf
Y3A0MzcKPiB2ZmF0IGZhdCBzcl9tb2QgY2Ryb20gYXRhX2dlbmVyaWMgYXRhX3BpaXggcGF0YV9h
Y3BpIGxpYmF0YSB1aGNpX2hjZAo+IGVoY2lfaGNkIG1wdHNwaSBtcHRzY3NpaCBtcHRiYXNlIHNj
c2lfdHJhbnNwb3J0X3NwaSBmbG9wcHkgdXNiX3N0b3JhZ2UKPiB1c2JfbGlidXN1YWwgdXNiY29y
ZSBzZF9tb2Qgc2NzaV9tb2Qgc3F1YXNoZnMgbG9vcAo+IFsgICAyMy4xMjExNjVdCj4gWyAgIDIz
LjEyMTgwMV0gUGlkOiAxNjI2LCBjb21tOiBtb2Rwcm9iZSBOb3QgdGFpbnRlZCAzLjAuMTAtZ3Jz
ZWMKPiAjMS1BbHBpbmUgVk13YXJlLCBJbmMuIFZNd2FyZSBWaXJ0dWFsIFBsYXRmb3JtLzQ0MEJY
IERlc2t0b3AgUmVmZXJlbmNlCj4gUGxhdGZvcm0KPiBbICAgMjMuMTI4MjQyXSBSSVA6IGUwMzA6
WzxmZmZmZmZmZjgxMDYyMDI2Pl0gIFs8ZmZmZmZmZmY4MTA2MjAyNj5dCj4gbW9kdWxlX3JlZmNv
dW50KzB4MmUvMHg5OQo+IFsgICAyMy4xMzQ5OTRdIFJTUDogZTAyYjpmZmZmODgwMDM1MWRkZDg4
ICBFRkxBR1M6IDAwMDEwMjg3Cj4gWyAgIDIzLjEzNjk5N10gUkFYOiAwMDAwMDAwMDAwMDAwMDAx
IFJCWDogMDAwMDAwMDAwMDAwMDAwMSBSQ1g6IGZmZmY4ODAwM2FlYTgwMDAKPiBbICAgMjMuMTQw
MTEzXSBSRFg6IDAwMDA2MGZmYzRlOTNmYzAgUlNJOiAwMDAwMDAwMDAwMDAwMDIwIFJESTogMDAw
MDAwMDAwMDAwMDAyMAo+IFsgICAyMy4xNDM5MzldIFJCUDogZmZmZjg4MDAzNTFkZGRhOCBSMDg6
IDAwMDAwMDAwMDAwMDAwMDAgUjA5OiBmZmZmZmZmZjgxNGFhNTIwCj4gWyAgIDIzLjE0NjY1Nl0g
UjEwOiBmZmZmODgwMDM0NWQ1MDAwIFIxMTogMDAwMDAwMDAwMDAwMDAwMCBSMTI6IGZmZmZmZmZm
ODE0YWE1MjAKPiBbICAgMjMuMTQ5MzU0XSBSMTM6IGZmZmZmZmZmYTAxNGI3YTAgUjE0OiAwMDAw
MDAwMDAwMDAxMDAwIFIxNTogZmZmZmZmZmZhMDE0Yjk2OAo+IFsgICAyMy4xNTc2NzNdIEZTOiAg
MDAwMDVmYjAxNzU2NDZhMCgwMDAwKSBHUzpmZmZmODgwMDNhZTkxMDAwKDAwMDApCj4ga25sR1M6
MDAwMDAwMDAwMDAwMDAwMAo+IFsgICAyMy4xNjIzNTRdIENTOiAgZTAzMyBEUzogMDAwMCBFUzog
MDAwMCBDUjA6IDAwMDAwMDAwODAwNTAwM2IKPiBbICAgMjMuMTY0NzM2XSBDUjI6IGZmZmZlOGZm
ZmZkM2JmYzQgQ1IzOiAwMDAwMDAwMDMzOWIzMDAwIENSNDogMDAwMDAwMDAwMDAwMDY2MAo+IFsg
ICAyMy4xNjc5NTRdIERSMDogMDAwMDAwMDAwMDAwMDAwMCBEUjE6IDAwMDAwMDAwMDAwMDAwMDAg
RFIyOiAwMDAwMDAwMDAwMDAwMDAwCj4gWyAgIDIzLjE3MDcxOV0gRFIzOiAwMDAwMDAwMDAwMDAw
MDAwIERSNjogMDAwMDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0MDAKPiBbICAgMjMu
MTc0MTA5XSBQcm9jZXNzIG1vZHByb2JlIChwaWQ6IDE2MjYsIHRocmVhZGluZm8KPiBmZmZmODgw
MDM0NzdhYjU4LCB0YXNrIGZmZmY4ODAwMzQ3N2E3NjApCj4gWyAgIDIzLjE3ODY2MV0gU3RhY2s6
Cj4gWyAgIDIzLjE3OTQ2Nl0gIGZmZmZmZmZmYTAxNGI3YTggZmZmZjg4MDAzNDMzNDMwMCBmZmZm
ZmZmZmEwMTRiN2EwCj4gMDAwMDAwMDAwMDAwMTAwMAo+IFsgICAyMy4xODI3ODddICBmZmZmODgw
MDM1MWRkZGY4IGZmZmZmZmZmODEwNjIxMWMgZmZmZjg4MDAzNTMwMDQyMAo+IDAwMDA1ZmIwMTZj
ZmZkMTAKPiBbICAgMjMuMTg5NDk0XSAgZmZmZjg4MDAzNTFkZGRmOCBmZmZmODgwMDM0MzM0MzAw
IDAwMDAwMDAwMDAwMDAwMDAKPiAwMDAwMGZlY2RhMGJjZDkwCj4gWyAgIDIzLjE5ODYxOF0gQ2Fs
bCBUcmFjZToKPiBbICAgMjMuMjAwNjI0XSAgWzxmZmZmZmZmZjgxMDYyMTFjPl0gbV9zaG93KzB4
NTQvMHgxNmIKPiBbICAgMjMuMjAyNTEyXSAgWzxmZmZmZmZmZjgxMGQxYjVjPl0gc2VxX3JlYWQr
MHgyNDcvMHg1MWYKPiBbICAgMjMuMjA0NDgzXSAgWzxmZmZmZmZmZjgxMGZjY2MyPl0gcHJvY19y
ZWdfcmVhZCsweDZjLzB4ODUKPiBbICAgMjMuMjA2NTQzXSAgWzxmZmZmZmZmZjgxMGI2MTRmPl0g
dmZzX3JlYWQrMHgxMDQvMHgxOTgKPiBbICAgMjMuMjA4OTA5XSAgWzxmZmZmZmZmZjgxMGI2MjI4
Pl0gc3lzX3JlYWQrMHg0NS8weDZjCj4gWyAgIDIzLjIxMTA3NV0gIFs8ZmZmZmZmZmY4MTJhYTE0
Yj5dIHN5c3RlbV9jYWxsX2Zhc3RwYXRoKzB4MTYvMHgxYgo+IFsgICAyMy4yMTU3OTZdICBbPGZm
ZmZmZmZmODEyYWEwZTk+XSA/IHN5c3RlbV9jYWxsX2FmdGVyX3N3YXBncysweDE5LzB4NjUKPiBb
ICAgMjMuMjE5MTk2XSBDb2RlOiBmZiA0OCA4OSBlNSA0MSA1NiA0MSA1NSA0OSA4OSBmZCA0MSA1
NCA0YyA4YiAyNQo+IDc5IDEyIDI5IDAwIDUzIDMxIGRiIGViIDE2IDQ4IDYzIGM4IDQ5IDhiIDk1
IGY4IDAxIDAwIDAwIDQ4IDhiIDBjIGNkCj4gNTAgNjAgM2EgODEKPiBbICAgMjMuMjI4Nzc0XSAg
NWMgMGEgMDQgZmYgYzAgYmUgMjAgMDAgMDAgMDAgNGMgODkgZTcgNDggNjMgZDAgZTggMzQgMjQg
MGUKPiBbICAgMjMuMjM1MjIzXSBSSVAgIFs8ZmZmZmZmZmY4MTA2MjAyNj5dIG1vZHVsZV9yZWZj
b3VudCsweDJlLzB4OTkKPiBbICAgMjMuMjQwNzE4XSAgUlNQIDxmZmZmODgwMDM1MWRkZDg4Pgo+
IFsgICAyMy4yNDM5MTJdIENSMjogZmZmZmU4ZmZmZmQzYmZjNAo+IFsgICAyMy4yNDUyNTZdIC0t
LVsgZW5kIHRyYWNlIDQ3NjNhZGRkOWZiMjI2ZTUgXS0tLQo+IEtpbGxlZAo+IExvYWRpbmcgYWNw
aTpMTlhTWVNUTToKPiAKPiBJJ3ZlIGNoYW5nZWQgdGhlIGluaXQgc2NyaXB0IHRvIGxvYWQgZWFj
aCBtb2R1bGUgc2VwYXJhdGVkbHksIGluc3RlYWQKPiBvZiBkb2luZyBhIG1vZHByb2JlIC1hIDxh
bGwgbW9kdWxlcz4sIGlmIEkgbG9hZGVkIGFsbCB0aGUgbW9kdWxlcyBhdAo+IG9uY2UgdGhlIHN5
c3RlbSBjcmFzaGVkIGluc3RlYWQgb2YgZnJlZXppbmcuIFRoZSBwcm9ibGVtIHNlZW1zIHRvIGJl
Cj4gcmVsYXRlZCB0byBhY3BpLCBhbmQgdGhlIG1vZHVsZXMgYXJlIGxvYWRlZCBmcm9tIGEgc3F1
YXNoZnMgaW1hZ2UKPiBtb3VudGVkIG9uIGxvb3AwLiBEb2VzIGFueW9uZSBrbm93IHdoYXQgbWln
aHQgYmUgY2F1c2luZyB0aGlzIGlzc3VlIG9yCj4gaWYgdGhlcmUgaXMgYSBwb3NzaWJsZSBmaXg/
CgpOb3RoaW5nIHNwcmluZ3MgdG8gbWluZC4gT24gdGhlIGZhY2Ugb2YgaXQgdGhpcyBkb2Vzbid0
IGxvb2sgYWxsIHRoYXQKWGVuIHNwZWNpZmljIC0tIGlmIHlvdSBib290IHRoZSBzYW1lIExpbnV4
IGtlcm5lbCB3aXRob3V0IFhlbiB1bmRlcm5lYXRoCihidXQgb3RoZXJ3aXNlIGluIHRoZSBzYW1l
IGNvbmZpZ3VyYXRpb24pIGRvZXMgaXQgd29yaz8KCllvdSBhcmUgdXNpbmcgdGhlIC1ncnNlYyBw
YXRjaGVzIHZlcnNpb24gb2YgTGludXgsIGRvZXMgYSB2YW5pbGxhCm1haW5saW5lIGhhdmUgdGhl
IHNhbWUgaXNzdWU/CgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 03 09:50:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 09: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 1Ri10M-0000D8-SF; Tue, 03 Jan 2012 09:50:02 +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 1Ri10K-0000Cu-GL
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 09:50:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325584194!9379961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27993 invoked from network); 3 Jan 2012 09:49:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 09:49:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9785303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 09:49: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, 3 Jan 2012
	09:49:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>
Date: Tue, 3 Jan 2012 09:49:54 +0000
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B051250@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B051250@BITCOM1.int.sbss.com.au>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325584194.25206.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux 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

On Mon, 2011-12-26 at 10:43 +0000, James Harper wrote:
> 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?

It's hard to say unless you provide details like which kernel are you
using. Do you know which baseline last worked for you?

Are you talking about the vif device in dom0 or the endpoint inside the
guest or both?

47103041e91794acdbc6165da0ae288d844c820b is the only upstream netback
which springs out as being related. IIRC
d0e5d83284dac15c015bb48115b6780f5a6413cd is a fixup for that commit
relating to migration.

The contents of the front and backend directories in xenstore might be
interesting?

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 09:50:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 09: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 1Ri10M-0000D8-SF; Tue, 03 Jan 2012 09:50:02 +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 1Ri10K-0000Cu-GL
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 09:50:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325584194!9379961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27993 invoked from network); 3 Jan 2012 09:49:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 09:49:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9785303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 09:49: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, 3 Jan 2012
	09:49:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>
Date: Tue, 3 Jan 2012 09:49:54 +0000
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B051250@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B051250@BITCOM1.int.sbss.com.au>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325584194.25206.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux 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

On Mon, 2011-12-26 at 10:43 +0000, James Harper wrote:
> 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?

It's hard to say unless you provide details like which kernel are you
using. Do you know which baseline last worked for you?

Are you talking about the vif device in dom0 or the endpoint inside the
guest or both?

47103041e91794acdbc6165da0ae288d844c820b is the only upstream netback
which springs out as being related. IIRC
d0e5d83284dac15c015bb48115b6780f5a6413cd is a fixup for that commit
relating to migration.

The contents of the front and backend directories in xenstore might be
interesting?

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 09:52:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 09:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri12N-0000Kv-Ih; Tue, 03 Jan 2012 09:52:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri12M-0000Km-Ih
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 09:52:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325584320!4080739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28748 invoked from network); 3 Jan 2012 09:52:00 -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;
	3 Jan 2012 09:52:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9785397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 09:52:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	09:52:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bo Xu <xubo.njust@gmail.com>
Date: Tue, 3 Jan 2012 09:52:00 +0000
In-Reply-To: <CAFLYXnC94icOGyBZN6SHS5v=+z64zf6L9RWq-2UDy9FP4G5inw@mail.gmail.com>
References: <CAFLYXnC94icOGyBZN6SHS5v=+z64zf6L9RWq-2UDy9FP4G5inw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325584320.25206.12.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Does Xen Driver Domain support 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

On Tue, 2011-12-27 at 14:19 +0000, Bo Xu wrote:
> Hello, everyone.
> I am new to Xen, I don't know if Xen Driver Domain, network for
> example, support the HVM DomU, like a windows DomU?
> Can the windows DomU connect to Internet through the network driver
> domain without problem.
> The system is Debian squeeze 6.0 x86-64 with xen-hypervisor-4.0-amd64,
> xen-qemu-dm-4.0, xen-linux-system-2.6-xen-amd64.

It certainly ought to work.

It should be transparent to the frontend which domain the backend
happens to be in (but stray hardcoded 0's do creep in from time to
time).

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 09:52:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 09:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri12N-0000Kv-Ih; Tue, 03 Jan 2012 09:52:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri12M-0000Km-Ih
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 09:52:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325584320!4080739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28748 invoked from network); 3 Jan 2012 09:52:00 -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;
	3 Jan 2012 09:52:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9785397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 09:52:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	09:52:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Bo Xu <xubo.njust@gmail.com>
Date: Tue, 3 Jan 2012 09:52:00 +0000
In-Reply-To: <CAFLYXnC94icOGyBZN6SHS5v=+z64zf6L9RWq-2UDy9FP4G5inw@mail.gmail.com>
References: <CAFLYXnC94icOGyBZN6SHS5v=+z64zf6L9RWq-2UDy9FP4G5inw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325584320.25206.12.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Does Xen Driver Domain support 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

On Tue, 2011-12-27 at 14:19 +0000, Bo Xu wrote:
> Hello, everyone.
> I am new to Xen, I don't know if Xen Driver Domain, network for
> example, support the HVM DomU, like a windows DomU?
> Can the windows DomU connect to Internet through the network driver
> domain without problem.
> The system is Debian squeeze 6.0 x86-64 with xen-hypervisor-4.0-amd64,
> xen-qemu-dm-4.0, xen-linux-system-2.6-xen-amd64.

It certainly ought to work.

It should be transparent to the frontend which domain the backend
happens to be in (but stray hardcoded 0's do creep in from time to
time).

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:04:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Dn-0000oz-EG; Tue, 03 Jan 2012 10:03:55 +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 1Ri1Dm-0000oc-KP
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:03:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325585025!4082732!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5995 invoked from network); 3 Jan 2012 10:03:47 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	VA3EHSOBE008.bigfish.com) (216.32.180.11)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Jan 2012 10:03:47 -0000
Received: from mail181-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; Tue, 3 Jan 2012 10:03:44 +0000
Received: from mail181-va3 (localhost [127.0.0.1])	by
	mail181-va3-R.bigfish.com (Postfix) with ESMTP id DC899401FF;
	Tue,  3 Jan 2012 10:03:44 +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 mail181-va3 (localhost.localdomain [127.0.0.1]) by mail181-va3
	(MessageSwitch) id 1325585024534315_30149;
	Tue,  3 Jan 2012 10:03:44 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.240])	by
	mail181-va3.bigfish.com (Postfix) with ESMTP id 70564520048;
	Tue,  3 Jan 2012 10:03:44 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.22; Tue, 3 Jan 2012 10:03:43 +0000
X-WSS-ID: 0LX7VY3-01-EBF-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 223CA10280EB;	Tue,  3 Jan 2012 04:03:38 -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, 3 Jan 2012 04:03:49 -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, 3 Jan 2012 04:03:42 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	05:03:18 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 09AC249C58B; Tue,  3 Jan 2012
	10:03:18 +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 E0F165940FF; Tue,  3 Jan 2012
	11:03:17 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 3 Jan 2012 11:05:51 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<30b1f434160d989be5e0.1324639759@gran.amd.com>
	<4F01A4B8020000780006A07B@nat28.tlf.novell.com>
In-Reply-To: <4F01A4B8020000780006A07B@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201031105.52925.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

On Monday 02 January 2012 12:36:08 Jan Beulich wrote:
> >>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> >
> > # 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  */
>
> This comment suggests that the patches prior to that aren't consistent.
> Is this really a proper standalone patch, or is the word "needs" too
> strict, or should it really be moved ahead in the series?
>
> > +    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);
>
> This is being done no matter whether it actually is a v2 IOMMU that
> you deal with here - if that's correct, the comment above should be
> adjusted accordingly.

This bit forces pci-defined no snoop bit to be cleared. This helps to solve 
potential issues in ATS devices with early drivers. I did not see any breaks 
on legacy devices and iommuv1 with FC = 1. But if you like I could make this 
only for v2 or change the comment a bit.
Thanks,
Wei
  

> Jan
>
> >      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 Tue Jan 03 10:04:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:04:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Dn-0000oz-EG; Tue, 03 Jan 2012 10:03:55 +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 1Ri1Dm-0000oc-KP
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:03:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325585025!4082732!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5995 invoked from network); 3 Jan 2012 10:03:47 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	VA3EHSOBE008.bigfish.com) (216.32.180.11)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Jan 2012 10:03:47 -0000
Received: from mail181-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; Tue, 3 Jan 2012 10:03:44 +0000
Received: from mail181-va3 (localhost [127.0.0.1])	by
	mail181-va3-R.bigfish.com (Postfix) with ESMTP id DC899401FF;
	Tue,  3 Jan 2012 10:03:44 +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 mail181-va3 (localhost.localdomain [127.0.0.1]) by mail181-va3
	(MessageSwitch) id 1325585024534315_30149;
	Tue,  3 Jan 2012 10:03:44 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.240])	by
	mail181-va3.bigfish.com (Postfix) with ESMTP id 70564520048;
	Tue,  3 Jan 2012 10:03:44 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server id
	14.1.225.22; Tue, 3 Jan 2012 10:03:43 +0000
X-WSS-ID: 0LX7VY3-01-EBF-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 223CA10280EB;	Tue,  3 Jan 2012 04:03:38 -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, 3 Jan 2012 04:03:49 -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, 3 Jan 2012 04:03:42 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	05:03:18 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 09AC249C58B; Tue,  3 Jan 2012
	10:03:18 +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 E0F165940FF; Tue,  3 Jan 2012
	11:03:17 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 3 Jan 2012 11:05:51 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<30b1f434160d989be5e0.1324639759@gran.amd.com>
	<4F01A4B8020000780006A07B@nat28.tlf.novell.com>
In-Reply-To: <4F01A4B8020000780006A07B@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201031105.52925.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

On Monday 02 January 2012 12:36:08 Jan Beulich wrote:
> >>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> >
> > # 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  */
>
> This comment suggests that the patches prior to that aren't consistent.
> Is this really a proper standalone patch, or is the word "needs" too
> strict, or should it really be moved ahead in the series?
>
> > +    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);
>
> This is being done no matter whether it actually is a v2 IOMMU that
> you deal with here - if that's correct, the comment above should be
> adjusted accordingly.

This bit forces pci-defined no snoop bit to be cleared. This helps to solve 
potential issues in ATS devices with early drivers. I did not see any breaks 
on legacy devices and iommuv1 with FC = 1. But if you like I could make this 
only for v2 or change the comment a bit.
Thanks,
Wei
  

> Jan
>
> >      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 Tue Jan 03 10:12:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1LT-0001Ah-E8; Tue, 03 Jan 2012 10:11: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 1Ri1LR-0001AT-MB
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:11:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325585503!7582650!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 30675 invoked from network); 3 Jan 2012 10:11:43 -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; 3 Jan 2012 10:11:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Jan 2012 10:11:42 +0000
Message-Id: <4F02E2A3020000780006A2A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Jan 2012 10:12:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<30b1f434160d989be5e0.1324639759@gran.amd.com>
	<4F01A4B8020000780006A07B@nat28.tlf.novell.com>
	<201201031105.52925.wei.wang2@amd.com>
In-Reply-To: <201201031105.52925.wei.wang2@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 03.01.12 at 11:05, Wei Wang2 <wei.wang2@amd.com> wrote:
> On Monday 02 January 2012 12:36:08 Jan Beulich wrote:
>> >>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
>> >
>> > # 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  */
>>
>> This comment suggests that the patches prior to that aren't consistent.
>> Is this really a proper standalone patch, or is the word "needs" too
>> strict, or should it really be moved ahead in the series?
>>
>> > +    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);
>>
>> This is being done no matter whether it actually is a v2 IOMMU that
>> you deal with here - if that's correct, the comment above should be
>> adjusted accordingly.
> 
> This bit forces pci-defined no snoop bit to be cleared. This helps to solve 
> potential issues in ATS devices with early drivers. I did not see any breaks 
> 
> on legacy devices and iommuv1 with FC = 1. But if you like I could make this 
> 
> only for v2 or change the comment a bit.

Whatever is the most appropriate thing to do here (you definitely
know better than I do).

Jan


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:12:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:12:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1LT-0001Ah-E8; Tue, 03 Jan 2012 10:11: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 1Ri1LR-0001AT-MB
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:11:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325585503!7582650!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 30675 invoked from network); 3 Jan 2012 10:11:43 -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; 3 Jan 2012 10:11:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Jan 2012 10:11:42 +0000
Message-Id: <4F02E2A3020000780006A2A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Jan 2012 10:12:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<30b1f434160d989be5e0.1324639759@gran.amd.com>
	<4F01A4B8020000780006A07B@nat28.tlf.novell.com>
	<201201031105.52925.wei.wang2@amd.com>
In-Reply-To: <201201031105.52925.wei.wang2@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

>>> On 03.01.12 at 11:05, Wei Wang2 <wei.wang2@amd.com> wrote:
> On Monday 02 January 2012 12:36:08 Jan Beulich wrote:
>> >>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
>> >
>> > # 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  */
>>
>> This comment suggests that the patches prior to that aren't consistent.
>> Is this really a proper standalone patch, or is the word "needs" too
>> strict, or should it really be moved ahead in the series?
>>
>> > +    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);
>>
>> This is being done no matter whether it actually is a v2 IOMMU that
>> you deal with here - if that's correct, the comment above should be
>> adjusted accordingly.
> 
> This bit forces pci-defined no snoop bit to be cleared. This helps to solve 
> potential issues in ATS devices with early drivers. I did not see any breaks 
> 
> on legacy devices and iommuv1 with FC = 1. But if you like I could make this 
> 
> only for v2 or change the comment a bit.

Whatever is the most appropriate thing to do here (you definitely
know better than I do).

Jan


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:13:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Mu-0001En-U5; Tue, 03 Jan 2012 10:13:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri1Mt-0001Eg-IT
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:13:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325585555!48821869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27885 invoked from network); 3 Jan 2012 10:12:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 10:12:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:13: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, 3 Jan 2012
	10:13:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Tue, 3 Jan 2012 10:13:17 +0000
In-Reply-To: <4EFAFD8C.2050502@gmail.com>
References: <4EFAFD8C.2050502@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325585598.25206.24.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Wed, 2011-12-28 at 11:29 +0000, Mohamad Rezaei wrote:
> Thanks for previous helps. I am working on them.
> 
> Is there any way to enable vt-x[EPT] for Dom0.

Not currently although you could checkout Mukesh Rathor's work on
supporting "hybrid" guests (PV guests running in a lightweight HVM
container) since this allows VT-x to be enabled even for PV guests. He
has posted several times to this list over the past year.

Ian.


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



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:13:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Mu-0001En-U5; Tue, 03 Jan 2012 10:13:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri1Mt-0001Eg-IT
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:13:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325585555!48821869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27885 invoked from network); 3 Jan 2012 10:12:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 10:12:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786132"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:13: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, 3 Jan 2012
	10:13:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Tue, 3 Jan 2012 10:13:17 +0000
In-Reply-To: <4EFAFD8C.2050502@gmail.com>
References: <4EFAFD8C.2050502@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325585598.25206.24.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Wed, 2011-12-28 at 11:29 +0000, Mohamad Rezaei wrote:
> Thanks for previous helps. I am working on them.
> 
> Is there any way to enable vt-x[EPT] for Dom0.

Not currently although you could checkout Mukesh Rathor's work on
supporting "hybrid" guests (PV guests running in a lightweight HVM
container) since this allows VT-x to be enabled even for PV guests. He
has posted several times to this list over the past year.

Ian.


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



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:15:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Oz-0001PQ-Ej; Tue, 03 Jan 2012 10:15:29 +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 1Ri1Oy-0001Of-2J
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:15:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1325585719!7633930!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 23511 invoked from network); 3 Jan 2012 10:15:21 -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;
	3 Jan 2012 10:15:21 -0000
Received: by daec6 with SMTP id c6so61818638dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 02:15: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=Imci6/HJTE8hkP9kkyeG9FUKrLYWabXp+zF3KiQq0BI=;
	b=E3/NSISmqhXSCiH7sMXUMJAm5MjPlEyu6lh6zrVWn+kKdRMjxC6PkqKKh2l446qhw/
	U7qOwzDFXBMe6RP0FN6VAKsl5BhsnF3fu2+c99RyU070SBDFzzd3IUkffFSn/pc1WC2+
	0Bpovm5NKQXvc8KdKBQkIzznUwzH9zedIiHKc=
MIME-Version: 1.0
Received: by 10.68.74.41 with SMTP id q9mr130824490pbv.129.1325585719155; Tue,
	03 Jan 2012 02:15:19 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 02:15:19 -0800 (PST)
In-Reply-To: <1325583878.25206.6.camel@zakaz.uk.xensource.com>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
	<1325583878.25206.6.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Jan 2012 11:15:19 +0100
X-Google-Sender-Auth: vk2fb6YIGHFf_0pnw1lQcF4Xi2o
Message-ID: <CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@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] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gU2F0
LCAyMDExLTEyLTI0IGF0IDExOjA4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiBI
ZWxsbywKPj4KPj4gSSdtIHRyeWluZyB0byBjcmVhdGUgYSBYZW4gRG9tMCBMaXZlQ0QvdXNiLCBi
YXNlZCBvbiBBbHBpbmUgTGludXgsCj4+IHdoaWNoIGhhcyBncmVhdCBzdXBwb3J0IGZvciB0aGlz
IGtpbmQgb2Ygc3R1ZmYuCj4KPiBDb29sIQoKV2UgYWxyZWFkeSBoYXZlIG1vc3Qgb2YgdGhpcyB3
b3JraW5nLCB0aGUgbmVjZXNzYXJ5IGZlYXR1cmVzIGFuZApzY3JpcHRzIGhhdmUgYmVlbiBhZGRl
ZCB0byB0aGUgYnVpbGQgdG9vbHMsIGFuZCB3aGVuIHRoZSBuZXcgeGVuLTQuMS4yCnBhY2thZ2Ug
cGFzc2VzIHRlc3RpbmcgY3JlYXRpbmcgYSBYZW4gRG9tMCBMaXZlQ0QvVVNCLy4uLiB3aWxsIGJl
CnRyaXZpYWwuIEkgd2lsbCBkcm9wIGEgbGluZSB0byB0aGUgbGlzdCB3aGVuIGl0IGlzIHJlbGVh
c2VkLgoKPiBOb3RoaW5nIHNwcmluZ3MgdG8gbWluZC4gT24gdGhlIGZhY2Ugb2YgaXQgdGhpcyBk
b2Vzbid0IGxvb2sgYWxsIHRoYXQKPiBYZW4gc3BlY2lmaWMgLS0gaWYgeW91IGJvb3QgdGhlIHNh
bWUgTGludXgga2VybmVsIHdpdGhvdXQgWGVuIHVuZGVybmVhdGgKPiAoYnV0IG90aGVyd2lzZSBp
biB0aGUgc2FtZSBjb25maWd1cmF0aW9uKSBkb2VzIGl0IHdvcms/CgpXaXRob3V0IFhlbiB0aGUg
a2VybmVsIHdvcmtlZCBvaywgZG9uJ3QgcmVhbGx5IGtub3cgd2hhdCBmYWlsZWQKKHByb2JhYmx5
IEkgaGFkIHNvbWUgY29ycnVwdGVkIGZpbGVzIG9uIG15IGluc3RhbGwpIGEgbmV3IGZyZXNoCmlu
c3RhbGwgZGlkbid0IHNob3cgYW55IG9mIHRoaXMgcHJvYmxlbXMsIGJ1dCBJIGNvbXBsZXRlbHkg
Zm9yZ290IHRvCnJlcGx5IHRvIHRoZSB0aHJlYWQsIHNvcnJ5IGZvciB3YXN0aW5nIHlvdXIgdGlt
ZS4KClJvZ2VyLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:15:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Oz-0001PQ-Ej; Tue, 03 Jan 2012 10:15:29 +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 1Ri1Oy-0001Of-2J
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:15:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1325585719!7633930!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 23511 invoked from network); 3 Jan 2012 10:15:21 -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;
	3 Jan 2012 10:15:21 -0000
Received: by daec6 with SMTP id c6so61818638dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 02:15: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=Imci6/HJTE8hkP9kkyeG9FUKrLYWabXp+zF3KiQq0BI=;
	b=E3/NSISmqhXSCiH7sMXUMJAm5MjPlEyu6lh6zrVWn+kKdRMjxC6PkqKKh2l446qhw/
	U7qOwzDFXBMe6RP0FN6VAKsl5BhsnF3fu2+c99RyU070SBDFzzd3IUkffFSn/pc1WC2+
	0Bpovm5NKQXvc8KdKBQkIzznUwzH9zedIiHKc=
MIME-Version: 1.0
Received: by 10.68.74.41 with SMTP id q9mr130824490pbv.129.1325585719155; Tue,
	03 Jan 2012 02:15:19 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 02:15:19 -0800 (PST)
In-Reply-To: <1325583878.25206.6.camel@zakaz.uk.xensource.com>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
	<1325583878.25206.6.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Jan 2012 11:15:19 +0100
X-Google-Sender-Auth: vk2fb6YIGHFf_0pnw1lQcF4Xi2o
Message-ID: <CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@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] 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gU2F0
LCAyMDExLTEyLTI0IGF0IDExOjA4ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiBI
ZWxsbywKPj4KPj4gSSdtIHRyeWluZyB0byBjcmVhdGUgYSBYZW4gRG9tMCBMaXZlQ0QvdXNiLCBi
YXNlZCBvbiBBbHBpbmUgTGludXgsCj4+IHdoaWNoIGhhcyBncmVhdCBzdXBwb3J0IGZvciB0aGlz
IGtpbmQgb2Ygc3R1ZmYuCj4KPiBDb29sIQoKV2UgYWxyZWFkeSBoYXZlIG1vc3Qgb2YgdGhpcyB3
b3JraW5nLCB0aGUgbmVjZXNzYXJ5IGZlYXR1cmVzIGFuZApzY3JpcHRzIGhhdmUgYmVlbiBhZGRl
ZCB0byB0aGUgYnVpbGQgdG9vbHMsIGFuZCB3aGVuIHRoZSBuZXcgeGVuLTQuMS4yCnBhY2thZ2Ug
cGFzc2VzIHRlc3RpbmcgY3JlYXRpbmcgYSBYZW4gRG9tMCBMaXZlQ0QvVVNCLy4uLiB3aWxsIGJl
CnRyaXZpYWwuIEkgd2lsbCBkcm9wIGEgbGluZSB0byB0aGUgbGlzdCB3aGVuIGl0IGlzIHJlbGVh
c2VkLgoKPiBOb3RoaW5nIHNwcmluZ3MgdG8gbWluZC4gT24gdGhlIGZhY2Ugb2YgaXQgdGhpcyBk
b2Vzbid0IGxvb2sgYWxsIHRoYXQKPiBYZW4gc3BlY2lmaWMgLS0gaWYgeW91IGJvb3QgdGhlIHNh
bWUgTGludXgga2VybmVsIHdpdGhvdXQgWGVuIHVuZGVybmVhdGgKPiAoYnV0IG90aGVyd2lzZSBp
biB0aGUgc2FtZSBjb25maWd1cmF0aW9uKSBkb2VzIGl0IHdvcms/CgpXaXRob3V0IFhlbiB0aGUg
a2VybmVsIHdvcmtlZCBvaywgZG9uJ3QgcmVhbGx5IGtub3cgd2hhdCBmYWlsZWQKKHByb2JhYmx5
IEkgaGFkIHNvbWUgY29ycnVwdGVkIGZpbGVzIG9uIG15IGluc3RhbGwpIGEgbmV3IGZyZXNoCmlu
c3RhbGwgZGlkbid0IHNob3cgYW55IG9mIHRoaXMgcHJvYmxlbXMsIGJ1dCBJIGNvbXBsZXRlbHkg
Zm9yZ290IHRvCnJlcGx5IHRvIHRoZSB0aHJlYWQsIHNvcnJ5IGZvciB3YXN0aW5nIHlvdXIgdGlt
ZS4KClJvZ2VyLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:16:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Pd-0001Te-T1; Tue, 03 Jan 2012 10:16: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 1Ri1Pc-0001T8-V0
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:16:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325585762!9379683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25910 invoked from network); 3 Jan 2012 10:16:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 10:16:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:16: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, 3 Jan 2012
	10:16:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 3 Jan 2012 10:16:02 +0000
In-Reply-To: <1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325585762.25206.25.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"florian.heigl@gmail.com" <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> Simple fix to enable user to specify vif names.

Thanks. It is worth noting that the naming of the vif is implemented by
the hotplug scripts and not by netback (which always uses vifX.Y).

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@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)));



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:16:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Pd-0001Te-T1; Tue, 03 Jan 2012 10:16: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 1Ri1Pc-0001T8-V0
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:16:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325585762!9379683!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25910 invoked from network); 3 Jan 2012 10:16:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 10:16:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786199"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:16: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, 3 Jan 2012
	10:16:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 3 Jan 2012 10:16:02 +0000
In-Reply-To: <1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325585762.25206.25.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"florian.heigl@gmail.com" <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> Simple fix to enable user to specify vif names.

Thanks. It is worth noting that the naming of the vif is implemented by
the hotplug scripts and not by netback (which always uses vifX.Y).

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@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)));



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:16:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Q0-0001XB-GA; Tue, 03 Jan 2012 10:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri1Py-0001Wn-QQ
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:16:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325585756!46899520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21039 invoked from network); 3 Jan 2012 10:15:57 -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;
	3 Jan 2012 10:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:16:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	10:16:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 3 Jan 2012 10:16:29 +0000
In-Reply-To: <1325157276-4847-2-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-2-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325585789.25206.26.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"florian.heigl@gmail.com" <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@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);



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:16:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:16:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Q0-0001XB-GA; Tue, 03 Jan 2012 10:16:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri1Py-0001Wn-QQ
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:16:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325585756!46899520!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21039 invoked from network); 3 Jan 2012 10:15:57 -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;
	3 Jan 2012 10:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:16:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	10:16:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 3 Jan 2012 10:16:29 +0000
In-Reply-To: <1325157276-4847-2-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-2-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325585789.25206.26.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"florian.heigl@gmail.com" <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@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);



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:18:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Ro-0001ol-1S; Tue, 03 Jan 2012 10:18:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ri1Rl-0001nw-Tj
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:18:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325585856!58725889!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 19672 invoked from network); 3 Jan 2012 10:17:36 -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; 3 Jan 2012 10:17:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Jan 2012 10:18:15 +0000
Message-Id: <4F02E42E020000780006A2B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Jan 2012 10:19: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="=__PartFDD3BD0E.2__="
Cc: anthony.perard@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen: fix sequence of operations in
	pt_msix_init()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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.

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

Checking the return value of mmap() must be done before adjusting the
value, otherwise failure may not be detected.

Closing the file handle, on the other hand, can be done before checking
the return value.

Finally, printing the errno value without knowing whether the previous
function actually failed is bogus (and superfluous since a subsequent
message prints the strerror() representaton anyway).

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

--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -537,7 +537,6 @@ int pt_msix_init(struct pt_dev *dev, int
     int i, total_entries, table_off, bar_index;
     struct pci_dev *pd =3D dev->pci_dev;
     int fd;
-    int err;
=20
     id =3D pci_read_byte(pd, pos + PCI_CAP_LIST_ID);
=20
@@ -585,17 +584,14 @@ int pt_msix_init(struct pt_dev *dev, int
     dev->msix->phys_iomem_base =3D mmap(0, total_entries * 16 + dev->msix-=
>table_offset_adjust,
                           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);
-    err =3D errno;
-    PT_LOG("errno =3D %d\n",err);
+    close(fd);
     if ( dev->msix->phys_iomem_base =3D=3D MAP_FAILED )
     {
         PT_LOG("Error: Can't map physical MSI-X table: %s\n", strerror(err=
no));
-        close(fd);
         goto error_out;
     }
-    close(fd);
+
+    dev->msix->phys_iomem_base +=3D dev->msix->table_offset_adjust;
=20
     PT_LOG("mapping physical MSI-X table to %lx\n",
            (unsigned long)dev->msix->phys_iomem_base);




--=__PartFDD3BD0E.2__=
Content-Type: text/plain; name="qemu-MSI-X-init-ordering.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-MSI-X-init-ordering.patch"

qemu-xen: fix sequence of operations in pt_msix_init()=0A=0AChecking the =
return value of mmap() must be done before adjusting the=0Avalue, =
otherwise failure may not be detected.=0A=0AClosing the file handle, on =
the other hand, can be done before checking=0Athe return value.=0A=0AFinall=
y, printing the errno value without knowing whether the previous=0Afunction=
 actually failed is bogus (and superfluous since a subsequent=0Amessage =
prints the strerror() representaton anyway).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/hw/pt-msi.c=0A+++ b/hw/pt-msi.c=0A@@=
 -537,7 +537,6 @@ int pt_msix_init(struct pt_dev *dev, int=0A     int i, =
total_entries, table_off, bar_index;=0A     struct pci_dev *pd =3D =
dev->pci_dev;=0A     int fd;=0A-    int err;=0A =0A     id =3D pci_read_byt=
e(pd, pos + PCI_CAP_LIST_ID);=0A =0A@@ -585,17 +584,14 @@ int pt_msix_init(=
struct pt_dev *dev, int=0A     dev->msix->phys_iomem_base =3D mmap(0, =
total_entries * 16 + dev->msix->table_offset_adjust,=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-  =
  err =3D errno;=0A-    PT_LOG("errno =3D %d\n",err);=0A+    close(fd);=0A =
    if ( dev->msix->phys_iomem_base =3D=3D MAP_FAILED )=0A     {=0A        =
 PT_LOG("Error: Can't map physical MSI-X table: %s\n", strerror(errno));=0A=
-        close(fd);=0A         goto error_out;=0A     }=0A-    close(fd);=
=0A+=0A+    dev->msix->phys_iomem_base +=3D dev->msix->table_offset_adjust;=
=0A =0A     PT_LOG("mapping physical MSI-X table to %lx\n",=0A            =
(unsigned long)dev->msix->phys_iomem_base);=0A
--=__PartFDD3BD0E.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

--=__PartFDD3BD0E.2__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:18:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:18:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1Ro-0001ol-1S; Tue, 03 Jan 2012 10:18:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Ri1Rl-0001nw-Tj
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:18:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325585856!58725889!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 19672 invoked from network); 3 Jan 2012 10:17:36 -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; 3 Jan 2012 10:17:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Jan 2012 10:18:15 +0000
Message-Id: <4F02E42E020000780006A2B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Jan 2012 10:19: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="=__PartFDD3BD0E.2__="
Cc: anthony.perard@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen: fix sequence of operations in
	pt_msix_init()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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.

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

Checking the return value of mmap() must be done before adjusting the
value, otherwise failure may not be detected.

Closing the file handle, on the other hand, can be done before checking
the return value.

Finally, printing the errno value without knowing whether the previous
function actually failed is bogus (and superfluous since a subsequent
message prints the strerror() representaton anyway).

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

--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -537,7 +537,6 @@ int pt_msix_init(struct pt_dev *dev, int
     int i, total_entries, table_off, bar_index;
     struct pci_dev *pd =3D dev->pci_dev;
     int fd;
-    int err;
=20
     id =3D pci_read_byte(pd, pos + PCI_CAP_LIST_ID);
=20
@@ -585,17 +584,14 @@ int pt_msix_init(struct pt_dev *dev, int
     dev->msix->phys_iomem_base =3D mmap(0, total_entries * 16 + dev->msix-=
>table_offset_adjust,
                           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);
-    err =3D errno;
-    PT_LOG("errno =3D %d\n",err);
+    close(fd);
     if ( dev->msix->phys_iomem_base =3D=3D MAP_FAILED )
     {
         PT_LOG("Error: Can't map physical MSI-X table: %s\n", strerror(err=
no));
-        close(fd);
         goto error_out;
     }
-    close(fd);
+
+    dev->msix->phys_iomem_base +=3D dev->msix->table_offset_adjust;
=20
     PT_LOG("mapping physical MSI-X table to %lx\n",
            (unsigned long)dev->msix->phys_iomem_base);




--=__PartFDD3BD0E.2__=
Content-Type: text/plain; name="qemu-MSI-X-init-ordering.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-MSI-X-init-ordering.patch"

qemu-xen: fix sequence of operations in pt_msix_init()=0A=0AChecking the =
return value of mmap() must be done before adjusting the=0Avalue, =
otherwise failure may not be detected.=0A=0AClosing the file handle, on =
the other hand, can be done before checking=0Athe return value.=0A=0AFinall=
y, printing the errno value without knowing whether the previous=0Afunction=
 actually failed is bogus (and superfluous since a subsequent=0Amessage =
prints the strerror() representaton anyway).=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/hw/pt-msi.c=0A+++ b/hw/pt-msi.c=0A@@=
 -537,7 +537,6 @@ int pt_msix_init(struct pt_dev *dev, int=0A     int i, =
total_entries, table_off, bar_index;=0A     struct pci_dev *pd =3D =
dev->pci_dev;=0A     int fd;=0A-    int err;=0A =0A     id =3D pci_read_byt=
e(pd, pos + PCI_CAP_LIST_ID);=0A =0A@@ -585,17 +584,14 @@ int pt_msix_init(=
struct pt_dev *dev, int=0A     dev->msix->phys_iomem_base =3D mmap(0, =
total_entries * 16 + dev->msix->table_offset_adjust,=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-  =
  err =3D errno;=0A-    PT_LOG("errno =3D %d\n",err);=0A+    close(fd);=0A =
    if ( dev->msix->phys_iomem_base =3D=3D MAP_FAILED )=0A     {=0A        =
 PT_LOG("Error: Can't map physical MSI-X table: %s\n", strerror(errno));=0A=
-        close(fd);=0A         goto error_out;=0A     }=0A-    close(fd);=
=0A+=0A+    dev->msix->phys_iomem_base +=3D dev->msix->table_offset_adjust;=
=0A =0A     PT_LOG("mapping physical MSI-X table to %lx\n",=0A            =
(unsigned long)dev->msix->phys_iomem_base);=0A
--=__PartFDD3BD0E.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

--=__PartFDD3BD0E.2__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:20:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10: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 1Ri1Tu-00026O-TT; Tue, 03 Jan 2012 10:20:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri1Tt-00025t-DX
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:20:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325585986!9370374!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19901 invoked from network); 3 Jan 2012 10:19:46 -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;
	3 Jan 2012 10:19:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10: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; Tue, 3 Jan 2012
	10:19:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "guilherme m. schroeder" <guialemas@gmail.com>
Date: Tue, 3 Jan 2012 10:19:46 +0000
In-Reply-To: <CAPxDueV_2oNTFQocbGY67Y9Cq2=wwX7VGL7+WayeSxu6Y_L1Nw@mail.gmail.com>
References: <CAPxDueV_2oNTFQocbGY67Y9Cq2=wwX7VGL7+WayeSxu6Y_L1Nw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325585986.25206.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] dom0 crash on csched_acct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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-29 at 11:15 +0000, guilherme m. schroeder wrote:
> Hi,
> 
> I'm having some random crashes with XenServer 5.6 SP2 (Xen 3.4.2).
> I thought that it was a problem with Xen 3.4 and tried XenServer 6.0
> (Xen 4.1.1), but no luck.
> I know that this list is about XenSource and (maybe) doesn't cover it,
> but i'm trying to understand
> what is happening.

Your best bet for XenServer support is either to contact your Citrix
support representative or to use the XenServer forums.

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:20:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10: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 1Ri1Tu-00026O-TT; Tue, 03 Jan 2012 10:20:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri1Tt-00025t-DX
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:20:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325585986!9370374!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19901 invoked from network); 3 Jan 2012 10:19:46 -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;
	3 Jan 2012 10:19:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786309"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10: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; Tue, 3 Jan 2012
	10:19:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "guilherme m. schroeder" <guialemas@gmail.com>
Date: Tue, 3 Jan 2012 10:19:46 +0000
In-Reply-To: <CAPxDueV_2oNTFQocbGY67Y9Cq2=wwX7VGL7+WayeSxu6Y_L1Nw@mail.gmail.com>
References: <CAPxDueV_2oNTFQocbGY67Y9Cq2=wwX7VGL7+WayeSxu6Y_L1Nw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325585986.25206.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] dom0 crash on csched_acct
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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-29 at 11:15 +0000, guilherme m. schroeder wrote:
> Hi,
> 
> I'm having some random crashes with XenServer 5.6 SP2 (Xen 3.4.2).
> I thought that it was a problem with Xen 3.4 and tried XenServer 6.0
> (Xen 4.1.1), but no luck.
> I know that this list is about XenSource and (maybe) doesn't cover it,
> but i'm trying to understand
> what is happening.

Your best bet for XenServer support is either to contact your Citrix
support representative or to use the XenServer forums.

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:22:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri1Vh-0002FI-ER; Tue, 03 Jan 2012 10:22:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1Ri1Vf-0002Em-VC
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:22:24 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325586134!9380740!1
X-Originating-IP: [203.16.207.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 16499 invoked from network); 3 Jan 2012 10:22:17 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Jan 2012 10:22:17 -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 1Ri1VS-0007Tj-Od; Tue, 03 Jan 2012 21:22:10 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 3 Jan 2012 21:22:10 +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;
	Tue, 3 Jan 2012 21:22:11 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] linux 3.1.0 - no network offload
Thread-Index: AQHMyf0ivVHlEt1eq0eisAm3Ki0YmZX6bp4g
Date: Tue, 3 Jan 2012 10:22:07 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B090280@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B051250@BITCOM1.int.sbss.com.au>
	<1325584194.25206.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325584194.25206.10.camel@zakaz.uk.xensource.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Jan 2012 10:22:10.0586 (UTC)
	FILETIME=[8D925FA0:01CCCA01]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> 
> On Mon, 2011-12-26 at 10:43 +0000, James Harper wrote:
> > 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?
> 
> It's hard to say unless you provide details like which kernel are you using. Do
> you know which baseline last worked for you?
> 
> Are you talking about the vif device in dom0 or the endpoint inside the guest
> or both?
> 
> 47103041e91794acdbc6165da0ae288d844c820b is the only upstream netback
> which springs out as being related. IIRC
> d0e5d83284dac15c015bb48115b6780f5a6413cd is a fixup for that commit
> relating to migration.
> 
> The contents of the front and backend directories in xenstore might be
> interesting?
> 

I upgraded my Debian kernel and all the problems went away. It was also obscured by a bug in my GPLPV drivers that wasn't reading the 'checksum offload enabled' flag from the registry properly which caused problems of its own, but the linux PV DomU's were also misbehaving.

Thanks

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:22:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri1Vh-0002FI-ER; Tue, 03 Jan 2012 10:22:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1Ri1Vf-0002Em-VC
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:22:24 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325586134!9380740!1
X-Originating-IP: [203.16.207.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 16499 invoked from network); 3 Jan 2012 10:22:17 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-11.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Jan 2012 10:22:17 -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 1Ri1VS-0007Tj-Od; Tue, 03 Jan 2012 21:22:10 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 3 Jan 2012 21:22:10 +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;
	Tue, 3 Jan 2012 21:22:11 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] linux 3.1.0 - no network offload
Thread-Index: AQHMyf0ivVHlEt1eq0eisAm3Ki0YmZX6bp4g
Date: Tue, 3 Jan 2012 10:22:07 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B090280@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B051250@BITCOM1.int.sbss.com.au>
	<1325584194.25206.10.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325584194.25206.10.camel@zakaz.uk.xensource.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Jan 2012 10:22:10.0586 (UTC)
	FILETIME=[8D925FA0:01CCCA01]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> 
> On Mon, 2011-12-26 at 10:43 +0000, James Harper wrote:
> > 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?
> 
> It's hard to say unless you provide details like which kernel are you using. Do
> you know which baseline last worked for you?
> 
> Are you talking about the vif device in dom0 or the endpoint inside the guest
> or both?
> 
> 47103041e91794acdbc6165da0ae288d844c820b is the only upstream netback
> which springs out as being related. IIRC
> d0e5d83284dac15c015bb48115b6780f5a6413cd is a fixup for that commit
> relating to migration.
> 
> The contents of the front and backend directories in xenstore might be
> interesting?
> 

I upgraded my Debian kernel and all the problems went away. It was also obscured by a bug in my GPLPV drivers that wasn't reading the 'checksum offload enabled' flag from the registry properly which caused problems of its own, but the linux PV DomU's were also misbehaving.

Thanks

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:31:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10: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 1Ri1e4-0002cU-OI; Tue, 03 Jan 2012 10:31: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 1Ri1e3-0002cP-BG
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:31:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325586656!4087289!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 1580 invoked from network); 3 Jan 2012 10:30:56 -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; 3 Jan 2012 10:30:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Jan 2012 10:30:56 +0000
Message-Id: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Jan 2012 10:31:50 +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="=__PartFAD4BA06.2__="
Cc: anthony.perard@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen: adjust MSI-X related log 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>
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.

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

Several of these messages we coded using line continuation within a
string literal. This is generally not recommended and also lead to odd
sequences of many blanks in the middle of the messages.

The message indicating a discarded write due to MSI-X already being
enabled doesn't need to be issued when a write doesn't actually modify
the current value. Adjust the surrounding logic accordingly, and
eliminate some redundancy as well as the sometimes unnecessary access
to the physical MSI-X table.

Finally, adjust the wording of a few messages to be more precise and/or
more useful.

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

--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -431,8 +431,8 @@ int pt_msix_update_remap(struct pt_dev *
 static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr,
                                    uint32_t val)
 {
-    PT_LOG("Error: Invalid write to MSI-X table, \
-            only dword access is allowed.\n");
+    PT_LOG("Error: Invalid write to MSI-X table, addr %016"PRIx64";"
+           " only dword access is allowed\n", addr);
 }
=20
 static void pci_msix_writel(void *opaque, target_phys_addr_t addr, =
uint32_t val)
@@ -441,13 +441,11 @@ static void pci_msix_writel(void *opaque
     struct pt_msix_info *msix =3D dev->msix;
     struct msix_entry_info *entry;
     int entry_nr, offset;
-    void *phys_off;
-    uint32_t vec_ctrl;
=20
     if ( addr % 4 )
     {
-        PT_LOG("Error: Unaligned dword access to MSI-X table, \
-                addr %016"PRIx64"\n", addr);
+        PT_LOG("Error: Unaligned dword write to MSI-X table,"
+               " addr %016"PRIx64"\n", addr);
         return;
     }
=20
@@ -455,22 +453,30 @@ static void pci_msix_writel(void *opaque
     entry =3D &msix->msix_entry[entry_nr];
     offset =3D ((addr - msix->mmio_base_addr) % 16) / 4;
=20
-    /*
-     * If Xen intercepts the mask bit access, io_mem[3] may not be
-     * up-to-date. Read from hardware directly.
-     */
-    phys_off =3D dev->msix->phys_iomem_base + 16 * entry_nr + 12;
-    vec_ctrl =3D *(uint32_t *)phys_off;
-
-    if ( offset !=3D 3 && msix->enabled && !(vec_ctrl & 0x1) )
+    if ( offset !=3D 3 )
     {
-        PT_LOG("Error: Can't update msix entry %d since MSI-X is already =
\
-                function.\n", entry_nr);
-        return;
-    }
+        const volatile uint32_t *vec_ctrl;
+
+        if ( entry->io_mem[offset] =3D=3D val )
+            return;
+
+        /*
+         * If Xen intercepts the mask bit access, io_mem[3] may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl =3D msix->phys_iomem_base + 16 * entry_nr + 12;
+
+        if ( msix->enabled && !(*vec_ctrl & 0x1) )
+        {
+            PT_LOG("Can't update entry %d since MSI-X is already enabled"
+                   " (%08"PRIx32" -> %08"PRIx32")\n",
+                   entry_nr, entry->io_mem[offset], val);
+            return;
+        }
=20
-    if ( offset !=3D 3 && entry->io_mem[offset] !=3D val )
         entry->flags =3D 1;
+    }
+
     entry->io_mem[offset] =3D val;
=20
     if ( offset =3D=3D 3 )
@@ -488,8 +494,8 @@ static CPUWriteMemoryFunc *pci_msix_writ
=20
 static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t =
addr)
 {
-    PT_LOG("Error: Invalid read to MSI-X table, \
-            only dword access is allowed.\n");
+    PT_LOG("Error: Invalid read from MSI-X table, addr %016"PRIx64";"
+           " only dword access is allowed\n", addr);
     return 0;
 }
=20
@@ -501,8 +507,8 @@ static uint32_t pci_msix_readl(void *opa
=20
     if ( addr % 4 )
     {
-        PT_LOG("Error: Unaligned dword access to MSI-X table, \
-                addr %016"PRIx64"\n", addr);
+        PT_LOG("Error: Unaligned dword read from MSI-X table,"
+               " addr %016"PRIx64"\n", addr);
         return 0;
     }
=20




--=__PartFAD4BA06.2__=
Content-Type: text/plain; name="qemu-MSI-X-verbosity.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-MSI-X-verbosity.patch"

qemu-xen: adjust MSI-X related log messages=0A=0ASeveral of these messages =
we coded using line continuation within a=0Astring literal. This is =
generally not recommended and also lead to odd=0Asequences of many blanks =
in the middle of the messages.=0A=0AThe message indicating a discarded =
write due to MSI-X already being=0Aenabled doesn't need to be issued when =
a write doesn't actually modify=0Athe current value. Adjust the surrounding=
 logic accordingly, and=0Aeliminate some redundancy as well as the =
sometimes unnecessary access=0Ato the physical MSI-X table.=0A=0AFinally, =
adjust the wording of a few messages to be more precise and/or=0Amore =
useful.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/hw/pt-msi.c=0A+++ b/hw/pt-msi.c=0A@@ -431,8 +431,8 @@ int pt_msix_update_=
remap(struct pt_dev *=0A static void pci_msix_invalid_write(void *opaque, =
target_phys_addr_t addr,=0A                                    uint32_t =
val)=0A {=0A-    PT_LOG("Error: Invalid write to MSI-X table, \=0A-        =
    only dword access is allowed.\n");=0A+    PT_LOG("Error: Invalid write =
to MSI-X table, addr %016"PRIx64";"=0A+           " only dword access is =
allowed\n", addr);=0A }=0A =0A static void pci_msix_writel(void *opaque, =
target_phys_addr_t addr, uint32_t val)=0A@@ -441,13 +441,11 @@ static void =
pci_msix_writel(void *opaque=0A     struct pt_msix_info *msix =3D =
dev->msix;=0A     struct msix_entry_info *entry;=0A     int entry_nr, =
offset;=0A-    void *phys_off;=0A-    uint32_t vec_ctrl;=0A =0A     if ( =
addr % 4 )=0A     {=0A-        PT_LOG("Error: Unaligned dword access to =
MSI-X table, \=0A-                addr %016"PRIx64"\n", addr);=0A+        =
PT_LOG("Error: Unaligned dword write to MSI-X table,"=0A+               " =
addr %016"PRIx64"\n", addr);=0A         return;=0A     }=0A =0A@@ -455,22 =
+453,30 @@ static void pci_msix_writel(void *opaque=0A     entry =3D =
&msix->msix_entry[entry_nr];=0A     offset =3D ((addr - msix->mmio_base_add=
r) % 16) / 4;=0A =0A-    /*=0A-     * If Xen intercepts the mask bit =
access, io_mem[3] may not be=0A-     * up-to-date. Read from hardware =
directly.=0A-     */=0A-    phys_off =3D dev->msix->phys_iomem_base + 16 * =
entry_nr + 12;=0A-    vec_ctrl =3D *(uint32_t *)phys_off;=0A-=0A-    if ( =
offset !=3D 3 && msix->enabled && !(vec_ctrl & 0x1) )=0A+    if ( offset =
!=3D 3 )=0A     {=0A-        PT_LOG("Error: Can't update msix entry %d =
since MSI-X is already \=0A-                function.\n", entry_nr);=0A-   =
     return;=0A-    }=0A+        const volatile uint32_t *vec_ctrl;=0A+=0A+=
        if ( entry->io_mem[offset] =3D=3D val )=0A+            return;=0A+=
=0A+        /*=0A+         * If Xen intercepts the mask bit access, =
io_mem[3] may not be=0A+         * up-to-date. Read from hardware =
directly.=0A+         */=0A+        vec_ctrl =3D msix->phys_iomem_base + =
16 * entry_nr + 12;=0A+=0A+        if ( msix->enabled && !(*vec_ctrl & =
0x1) )=0A+        {=0A+            PT_LOG("Can't update entry %d since =
MSI-X is already enabled"=0A+                   " (%08"PRIx32" -> =
%08"PRIx32")\n",=0A+                   entry_nr, entry->io_mem[offset], =
val);=0A+            return;=0A+        }=0A =0A-    if ( offset !=3D 3 && =
entry->io_mem[offset] !=3D val )=0A         entry->flags =3D 1;=0A+    =
}=0A+=0A     entry->io_mem[offset] =3D val;=0A =0A     if ( offset =3D=3D =
3 )=0A@@ -488,8 +494,8 @@ static CPUWriteMemoryFunc *pci_msix_writ=0A =0A =
static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t =
addr)=0A {=0A-    PT_LOG("Error: Invalid read to MSI-X table, \=0A-        =
    only dword access is allowed.\n");=0A+    PT_LOG("Error: Invalid read =
from MSI-X table, addr %016"PRIx64";"=0A+           " only dword access is =
allowed\n", addr);=0A     return 0;=0A }=0A =0A@@ -501,8 +507,8 @@ static =
uint32_t pci_msix_readl(void *opa=0A =0A     if ( addr % 4 )=0A     {=0A-  =
      PT_LOG("Error: Unaligned dword access to MSI-X table, \=0A-          =
      addr %016"PRIx64"\n", addr);=0A+        PT_LOG("Error: Unaligned =
dword read from MSI-X table,"=0A+               " addr %016"PRIx64"\n", =
addr);=0A         return 0;=0A     }=0A =0A
--=__PartFAD4BA06.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

--=__PartFAD4BA06.2__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:31:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10: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 1Ri1e4-0002cU-OI; Tue, 03 Jan 2012 10:31: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 1Ri1e3-0002cP-BG
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:31:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325586656!4087289!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 1580 invoked from network); 3 Jan 2012 10:30:56 -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; 3 Jan 2012 10:30:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 03 Jan 2012 10:30:56 +0000
Message-Id: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 03 Jan 2012 10:31:50 +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="=__PartFAD4BA06.2__="
Cc: anthony.perard@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] qemu-xen: adjust MSI-X related log 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>
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.

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

Several of these messages we coded using line continuation within a
string literal. This is generally not recommended and also lead to odd
sequences of many blanks in the middle of the messages.

The message indicating a discarded write due to MSI-X already being
enabled doesn't need to be issued when a write doesn't actually modify
the current value. Adjust the surrounding logic accordingly, and
eliminate some redundancy as well as the sometimes unnecessary access
to the physical MSI-X table.

Finally, adjust the wording of a few messages to be more precise and/or
more useful.

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

--- a/hw/pt-msi.c
+++ b/hw/pt-msi.c
@@ -431,8 +431,8 @@ int pt_msix_update_remap(struct pt_dev *
 static void pci_msix_invalid_write(void *opaque, target_phys_addr_t addr,
                                    uint32_t val)
 {
-    PT_LOG("Error: Invalid write to MSI-X table, \
-            only dword access is allowed.\n");
+    PT_LOG("Error: Invalid write to MSI-X table, addr %016"PRIx64";"
+           " only dword access is allowed\n", addr);
 }
=20
 static void pci_msix_writel(void *opaque, target_phys_addr_t addr, =
uint32_t val)
@@ -441,13 +441,11 @@ static void pci_msix_writel(void *opaque
     struct pt_msix_info *msix =3D dev->msix;
     struct msix_entry_info *entry;
     int entry_nr, offset;
-    void *phys_off;
-    uint32_t vec_ctrl;
=20
     if ( addr % 4 )
     {
-        PT_LOG("Error: Unaligned dword access to MSI-X table, \
-                addr %016"PRIx64"\n", addr);
+        PT_LOG("Error: Unaligned dword write to MSI-X table,"
+               " addr %016"PRIx64"\n", addr);
         return;
     }
=20
@@ -455,22 +453,30 @@ static void pci_msix_writel(void *opaque
     entry =3D &msix->msix_entry[entry_nr];
     offset =3D ((addr - msix->mmio_base_addr) % 16) / 4;
=20
-    /*
-     * If Xen intercepts the mask bit access, io_mem[3] may not be
-     * up-to-date. Read from hardware directly.
-     */
-    phys_off =3D dev->msix->phys_iomem_base + 16 * entry_nr + 12;
-    vec_ctrl =3D *(uint32_t *)phys_off;
-
-    if ( offset !=3D 3 && msix->enabled && !(vec_ctrl & 0x1) )
+    if ( offset !=3D 3 )
     {
-        PT_LOG("Error: Can't update msix entry %d since MSI-X is already =
\
-                function.\n", entry_nr);
-        return;
-    }
+        const volatile uint32_t *vec_ctrl;
+
+        if ( entry->io_mem[offset] =3D=3D val )
+            return;
+
+        /*
+         * If Xen intercepts the mask bit access, io_mem[3] may not be
+         * up-to-date. Read from hardware directly.
+         */
+        vec_ctrl =3D msix->phys_iomem_base + 16 * entry_nr + 12;
+
+        if ( msix->enabled && !(*vec_ctrl & 0x1) )
+        {
+            PT_LOG("Can't update entry %d since MSI-X is already enabled"
+                   " (%08"PRIx32" -> %08"PRIx32")\n",
+                   entry_nr, entry->io_mem[offset], val);
+            return;
+        }
=20
-    if ( offset !=3D 3 && entry->io_mem[offset] !=3D val )
         entry->flags =3D 1;
+    }
+
     entry->io_mem[offset] =3D val;
=20
     if ( offset =3D=3D 3 )
@@ -488,8 +494,8 @@ static CPUWriteMemoryFunc *pci_msix_writ
=20
 static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t =
addr)
 {
-    PT_LOG("Error: Invalid read to MSI-X table, \
-            only dword access is allowed.\n");
+    PT_LOG("Error: Invalid read from MSI-X table, addr %016"PRIx64";"
+           " only dword access is allowed\n", addr);
     return 0;
 }
=20
@@ -501,8 +507,8 @@ static uint32_t pci_msix_readl(void *opa
=20
     if ( addr % 4 )
     {
-        PT_LOG("Error: Unaligned dword access to MSI-X table, \
-                addr %016"PRIx64"\n", addr);
+        PT_LOG("Error: Unaligned dword read from MSI-X table,"
+               " addr %016"PRIx64"\n", addr);
         return 0;
     }
=20




--=__PartFAD4BA06.2__=
Content-Type: text/plain; name="qemu-MSI-X-verbosity.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="qemu-MSI-X-verbosity.patch"

qemu-xen: adjust MSI-X related log messages=0A=0ASeveral of these messages =
we coded using line continuation within a=0Astring literal. This is =
generally not recommended and also lead to odd=0Asequences of many blanks =
in the middle of the messages.=0A=0AThe message indicating a discarded =
write due to MSI-X already being=0Aenabled doesn't need to be issued when =
a write doesn't actually modify=0Athe current value. Adjust the surrounding=
 logic accordingly, and=0Aeliminate some redundancy as well as the =
sometimes unnecessary access=0Ato the physical MSI-X table.=0A=0AFinally, =
adjust the wording of a few messages to be more precise and/or=0Amore =
useful.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/hw/pt-msi.c=0A+++ b/hw/pt-msi.c=0A@@ -431,8 +431,8 @@ int pt_msix_update_=
remap(struct pt_dev *=0A static void pci_msix_invalid_write(void *opaque, =
target_phys_addr_t addr,=0A                                    uint32_t =
val)=0A {=0A-    PT_LOG("Error: Invalid write to MSI-X table, \=0A-        =
    only dword access is allowed.\n");=0A+    PT_LOG("Error: Invalid write =
to MSI-X table, addr %016"PRIx64";"=0A+           " only dword access is =
allowed\n", addr);=0A }=0A =0A static void pci_msix_writel(void *opaque, =
target_phys_addr_t addr, uint32_t val)=0A@@ -441,13 +441,11 @@ static void =
pci_msix_writel(void *opaque=0A     struct pt_msix_info *msix =3D =
dev->msix;=0A     struct msix_entry_info *entry;=0A     int entry_nr, =
offset;=0A-    void *phys_off;=0A-    uint32_t vec_ctrl;=0A =0A     if ( =
addr % 4 )=0A     {=0A-        PT_LOG("Error: Unaligned dword access to =
MSI-X table, \=0A-                addr %016"PRIx64"\n", addr);=0A+        =
PT_LOG("Error: Unaligned dword write to MSI-X table,"=0A+               " =
addr %016"PRIx64"\n", addr);=0A         return;=0A     }=0A =0A@@ -455,22 =
+453,30 @@ static void pci_msix_writel(void *opaque=0A     entry =3D =
&msix->msix_entry[entry_nr];=0A     offset =3D ((addr - msix->mmio_base_add=
r) % 16) / 4;=0A =0A-    /*=0A-     * If Xen intercepts the mask bit =
access, io_mem[3] may not be=0A-     * up-to-date. Read from hardware =
directly.=0A-     */=0A-    phys_off =3D dev->msix->phys_iomem_base + 16 * =
entry_nr + 12;=0A-    vec_ctrl =3D *(uint32_t *)phys_off;=0A-=0A-    if ( =
offset !=3D 3 && msix->enabled && !(vec_ctrl & 0x1) )=0A+    if ( offset =
!=3D 3 )=0A     {=0A-        PT_LOG("Error: Can't update msix entry %d =
since MSI-X is already \=0A-                function.\n", entry_nr);=0A-   =
     return;=0A-    }=0A+        const volatile uint32_t *vec_ctrl;=0A+=0A+=
        if ( entry->io_mem[offset] =3D=3D val )=0A+            return;=0A+=
=0A+        /*=0A+         * If Xen intercepts the mask bit access, =
io_mem[3] may not be=0A+         * up-to-date. Read from hardware =
directly.=0A+         */=0A+        vec_ctrl =3D msix->phys_iomem_base + =
16 * entry_nr + 12;=0A+=0A+        if ( msix->enabled && !(*vec_ctrl & =
0x1) )=0A+        {=0A+            PT_LOG("Can't update entry %d since =
MSI-X is already enabled"=0A+                   " (%08"PRIx32" -> =
%08"PRIx32")\n",=0A+                   entry_nr, entry->io_mem[offset], =
val);=0A+            return;=0A+        }=0A =0A-    if ( offset !=3D 3 && =
entry->io_mem[offset] !=3D val )=0A         entry->flags =3D 1;=0A+    =
}=0A+=0A     entry->io_mem[offset] =3D val;=0A =0A     if ( offset =3D=3D =
3 )=0A@@ -488,8 +494,8 @@ static CPUWriteMemoryFunc *pci_msix_writ=0A =0A =
static uint32_t pci_msix_invalid_read(void *opaque, target_phys_addr_t =
addr)=0A {=0A-    PT_LOG("Error: Invalid read to MSI-X table, \=0A-        =
    only dword access is allowed.\n");=0A+    PT_LOG("Error: Invalid read =
from MSI-X table, addr %016"PRIx64";"=0A+           " only dword access is =
allowed\n", addr);=0A     return 0;=0A }=0A =0A@@ -501,8 +507,8 @@ static =
uint32_t pci_msix_readl(void *opa=0A =0A     if ( addr % 4 )=0A     {=0A-  =
      PT_LOG("Error: Unaligned dword access to MSI-X table, \=0A-          =
      addr %016"PRIx64"\n", addr);=0A+        PT_LOG("Error: Unaligned =
dword read from MSI-X table,"=0A+               " addr %016"PRIx64"\n", =
addr);=0A         return 0;=0A     }=0A =0A
--=__PartFAD4BA06.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

--=__PartFAD4BA06.2__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:35:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1ho-0002lv-2c; Tue, 03 Jan 2012 10:34:56 +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 1Ri1hm-0002le-3U
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:34:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1325586887!9532656!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 25377 invoked from network); 3 Jan 2012 10:34:48 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Jan 2012 10:34:48 -0000
Received: from mail98-am1-R.bigfish.com (10.3.201.242) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Jan 2012 10:34:47 +0000
Received: from mail98-am1 (localhost [127.0.0.1])	by mail98-am1-R.bigfish.com
	(Postfix) with ESMTP id 9CF9A240157;
	Tue,  3 Jan 2012 10:34:47 +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
Received: from mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1
	(MessageSwitch) id 1325586887315474_10750;
	Tue,  3 Jan 2012 10:34:47 +0000 (UTC)
Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.250])	by
	mail98-am1.bigfish.com (Postfix) with ESMTP id 372B64003F;
	Tue,  3 Jan 2012 10:34:47 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Jan 2012 10:34:46 +0000
X-WSS-ID: 0LX7XDR-01-FGX-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 21F531028009;	Tue,  3 Jan 2012 04:34:38 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 3 Jan 2012 04:34:49 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 3 Jan 2012 04:34:42 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	05:34:40 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1E59F49C58B; Tue,  3 Jan 2012
	10:34:40 +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 E3CBA5940FF; Tue,  3 Jan 2012
	11:34:39 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 3 Jan 2012 11:37:13 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<201201031105.52925.wei.wang2@amd.com>
	<4F02E2A3020000780006A2A8@nat28.tlf.novell.com>
In-Reply-To: <4F02E2A3020000780006A2A8@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201031137.15210.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

On Tuesday 03 January 2012 11:12:35 Jan Beulich wrote:
> >>> On 03.01.12 at 11:05, Wei Wang2 <wei.wang2@amd.com> wrote:
> >
> > On Monday 02 January 2012 12:36:08 Jan Beulich wrote:
> >> >>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> >> >
> >> > # 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  */
> >>
> >> This comment suggests that the patches prior to that aren't consistent.
> >> Is this really a proper standalone patch, or is the word "needs" too
> >> strict, or should it really be moved ahead in the series?
> >>
> >> > +    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);
> >>
> >> This is being done no matter whether it actually is a v2 IOMMU that
> >> you deal with here - if that's correct, the comment above should be
> >> adjusted accordingly.
> >
> > This bit forces pci-defined no snoop bit to be cleared. This helps to
> > solve potential issues in ATS devices with early drivers. I did not see
> > any breaks
> >
> > on legacy devices and iommuv1 with FC = 1. But if you like I could make
> > this
> >
> > only for v2 or change the comment a bit.
>
> Whatever is the most appropriate thing to do here (you definitely
> know better than I do)

I intend to keep fc =1 for both v1 and v2. This setup also aligns with Linux 
iommu driver. I will change the comment.
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 Tue Jan 03 10:35:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:35:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1ho-0002lv-2c; Tue, 03 Jan 2012 10:34:56 +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 1Ri1hm-0002le-3U
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:34:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1325586887!9532656!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 25377 invoked from network); 3 Jan 2012 10:34:48 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Jan 2012 10:34:48 -0000
Received: from mail98-am1-R.bigfish.com (10.3.201.242) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Jan 2012 10:34:47 +0000
Received: from mail98-am1 (localhost [127.0.0.1])	by mail98-am1-R.bigfish.com
	(Postfix) with ESMTP id 9CF9A240157;
	Tue,  3 Jan 2012 10:34:47 +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
Received: from mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1
	(MessageSwitch) id 1325586887315474_10750;
	Tue,  3 Jan 2012 10:34:47 +0000 (UTC)
Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.250])	by
	mail98-am1.bigfish.com (Postfix) with ESMTP id 372B64003F;
	Tue,  3 Jan 2012 10:34:47 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Jan 2012 10:34:46 +0000
X-WSS-ID: 0LX7XDR-01-FGX-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 21F531028009;	Tue,  3 Jan 2012 04:34:38 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 3 Jan 2012 04:34:49 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 3 Jan 2012 04:34:42 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	05:34:40 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1E59F49C58B; Tue,  3 Jan 2012
	10:34:40 +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 E3CBA5940FF; Tue,  3 Jan 2012
	11:34:39 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Tue, 3 Jan 2012 11:37:13 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1324639749@gran.amd.com>
	<201201031105.52925.wei.wang2@amd.com>
	<4F02E2A3020000780006A2A8@nat28.tlf.novell.com>
In-Reply-To: <4F02E2A3020000780006A2A8@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201031137.15210.wei.wang2@amd.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 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

On Tuesday 03 January 2012 11:12:35 Jan Beulich wrote:
> >>> On 03.01.12 at 11:05, Wei Wang2 <wei.wang2@amd.com> wrote:
> >
> > On Monday 02 January 2012 12:36:08 Jan Beulich wrote:
> >> >>> On 23.12.11 at 12:29, Wei Wang <wei.wang2@amd.com> wrote:
> >> >
> >> > # 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  */
> >>
> >> This comment suggests that the patches prior to that aren't consistent.
> >> Is this really a proper standalone patch, or is the word "needs" too
> >> strict, or should it really be moved ahead in the series?
> >>
> >> > +    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);
> >>
> >> This is being done no matter whether it actually is a v2 IOMMU that
> >> you deal with here - if that's correct, the comment above should be
> >> adjusted accordingly.
> >
> > This bit forces pci-defined no snoop bit to be cleared. This helps to
> > solve potential issues in ATS devices with early drivers. I did not see
> > any breaks
> >
> > on legacy devices and iommuv1 with FC = 1. But if you like I could make
> > this
> >
> > only for v2 or change the comment a bit.
>
> Whatever is the most appropriate thing to do here (you definitely
> know better than I do)

I intend to keep fc =1 for both v1 and v2. This setup also aligns with Linux 
iommu driver. I will change the comment.
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 Tue Jan 03 10:38:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1lE-0002vC-NY; Tue, 03 Jan 2012 10:38: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 1Ri1lC-0002uv-Ld
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:38:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325587100!7571590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6928 invoked from network); 3 Jan 2012 10:38:20 -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;
	3 Jan 2012 10:38:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:38:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	10:38:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 3 Jan 2012 10:38:19 +0000
In-Reply-To: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
References: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325587099.25206.41.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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-02 at 10:49 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1325501151 -3600
> # Node ID bd59a07ed41187bcafc4dd5214f0744c66ef2069
> # Parent  3e02aa9670b3265e36bdddbd4760415cd87d047b
> pygrub: fix extlinux parsing
> 
> pygrub was unable to parse extlinux config files correctly, exactly
> the ones like:
> 
> LABEL grsec
>   KERNEL vmlinuz-3.0.10-grsec
>   APPEND initrd=initramfs-3.0.10-grsec
> root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
> modules=sd-mod,usb-storage,ext4 xen quiet
> 
> This patch fixes it, adding a new case when parsing the "append" line,
> that searches for the initrd image.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Please could you also supply an example file for your platform as a
patch to tools/pygrub/examples.

> diff -r 3e02aa9670b3 -r bd59a07ed411 tools/pygrub/src/ExtLinuxConf.py
> --- a/tools/pygrub/src/ExtLinuxConf.py	Thu Dec 15 18:55:46 2011 +0100
> +++ b/tools/pygrub/src/ExtLinuxConf.py	Mon Jan 02 11:45:51 2012 +0100
> @@ -60,6 +60,13 @@ class ExtLinuxImage(object):
>  
>                  # Bypass regular self.commands handling
>                  com = None
> +            elif arg.find(" "):
> +                # find initrd image in append line
> +                args = arg.strip().split(" ")
> +                for a in args:
> +                    if a.lower().startswith("initrd"):

Should check for "initrd=" here?

Or perhaps:
	* check for "="
	* split into "k = v"
	* check that k is precisely "initrd"
the first two are probably doable in the same str.split invocation if
you handle the exception correctly.

> +                        setattr(self, "initrd", a.replace("initrd=", ""))
> +                        arg = arg.replace(a, "")
>  
>          if com is not None and self.commands.has_key(com):
>              if self.commands[com] is not None:
> @@ -86,10 +93,12 @@ class ExtLinuxImage(object):
>          self._args = args
>      def get_kernel(self):
>          return self._kernel
> +    def set_args(self, val):
> +        self._args = val
>      def get_args(self):
>          return self._args
>      kernel = property(get_kernel, set_kernel)
> -    args = property(get_args)
> +    args = property(get_args, set_args)

Are these something required by arg.replace?

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:38:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1lE-0002vC-NY; Tue, 03 Jan 2012 10:38: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 1Ri1lC-0002uv-Ld
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:38:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325587100!7571590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6928 invoked from network); 3 Jan 2012 10:38:20 -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;
	3 Jan 2012 10:38:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:38:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	10:38:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 3 Jan 2012 10:38:19 +0000
In-Reply-To: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
References: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325587099.25206.41.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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-02 at 10:49 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1325501151 -3600
> # Node ID bd59a07ed41187bcafc4dd5214f0744c66ef2069
> # Parent  3e02aa9670b3265e36bdddbd4760415cd87d047b
> pygrub: fix extlinux parsing
> 
> pygrub was unable to parse extlinux config files correctly, exactly
> the ones like:
> 
> LABEL grsec
>   KERNEL vmlinuz-3.0.10-grsec
>   APPEND initrd=initramfs-3.0.10-grsec
> root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
> modules=sd-mod,usb-storage,ext4 xen quiet
> 
> This patch fixes it, adding a new case when parsing the "append" line,
> that searches for the initrd image.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Please could you also supply an example file for your platform as a
patch to tools/pygrub/examples.

> diff -r 3e02aa9670b3 -r bd59a07ed411 tools/pygrub/src/ExtLinuxConf.py
> --- a/tools/pygrub/src/ExtLinuxConf.py	Thu Dec 15 18:55:46 2011 +0100
> +++ b/tools/pygrub/src/ExtLinuxConf.py	Mon Jan 02 11:45:51 2012 +0100
> @@ -60,6 +60,13 @@ class ExtLinuxImage(object):
>  
>                  # Bypass regular self.commands handling
>                  com = None
> +            elif arg.find(" "):
> +                # find initrd image in append line
> +                args = arg.strip().split(" ")
> +                for a in args:
> +                    if a.lower().startswith("initrd"):

Should check for "initrd=" here?

Or perhaps:
	* check for "="
	* split into "k = v"
	* check that k is precisely "initrd"
the first two are probably doable in the same str.split invocation if
you handle the exception correctly.

> +                        setattr(self, "initrd", a.replace("initrd=", ""))
> +                        arg = arg.replace(a, "")
>  
>          if com is not None and self.commands.has_key(com):
>              if self.commands[com] is not None:
> @@ -86,10 +93,12 @@ class ExtLinuxImage(object):
>          self._args = args
>      def get_kernel(self):
>          return self._kernel
> +    def set_args(self, val):
> +        self._args = val
>      def get_args(self):
>          return self._args
>      kernel = property(get_kernel, set_kernel)
> -    args = property(get_args)
> +    args = property(get_args, set_args)

Are these something required by arg.replace?

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:41:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1nk-00033k-AO; Tue, 03 Jan 2012 10:41:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Ri1ni-00033R-68
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:41:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1325587128!50324084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5086 invoked from network); 3 Jan 2012 10:38:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 10:38:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786996"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:40:24 +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; Tue, 3 Jan 2012
	10:40:23 +0000
Message-ID: <1325587168.24422.68.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 3 Jan 2012 10:39:28 +0000
In-Reply-To: <1325585762.25206.25.camel@zakaz.uk.xensource.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
	<1325585762.25206.25.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"florian.heigl@gmail.com" <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [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

On Tue, 2012-01-03 at 10:16 +0000, Ian Campbell wrote:
> On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> > Simple fix to enable user to specify vif names.
> 
> Thanks. It is worth noting that the naming of the vif is implemented by
> the hotplug scripts and not by netback (which always uses vifX.Y).
> 

Yes, I knew that after digging into hotplug scripts. :)

It seems that we need to backport these patches to earlier versions as
well.


Wei.


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 10:41:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 10:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri1nk-00033k-AO; Tue, 03 Jan 2012 10:41:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Ri1ni-00033R-68
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 10:41:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1325587128!50324084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5086 invoked from network); 3 Jan 2012 10:38:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 10:38:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9786996"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 10:40:24 +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; Tue, 3 Jan 2012
	10:40:23 +0000
Message-ID: <1325587168.24422.68.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue, 3 Jan 2012 10:39:28 +0000
In-Reply-To: <1325585762.25206.25.camel@zakaz.uk.xensource.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
	<1325585762.25206.25.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"florian.heigl@gmail.com" <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [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

On Tue, 2012-01-03 at 10:16 +0000, Ian Campbell wrote:
> On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> > Simple fix to enable user to specify vif names.
> 
> Thanks. It is worth noting that the naming of the vif is implemented by
> the hotplug scripts and not by netback (which always uses vifX.Y).
> 

Yes, I knew that after digging into hotplug scripts. :)

It seems that we need to backport these patches to earlier versions as
well.


Wei.


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 11:02:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri280-0003Om-Ev; Tue, 03 Jan 2012 11:02: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 1Ri27y-0003Oe-Vh
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 11:01:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325588512!10183245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16883 invoked from network); 3 Jan 2012 11:01: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;
	3 Jan 2012 11:01:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9787577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 11:01: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; Tue, 3 Jan 2012
	11:01:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Jan 2012 11:01:52 +0000
In-Reply-To: <20120102171631.GA13603@aepfle.de>
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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325588512.25206.60.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>,
	Ian Jackson <Ian.Jackson@eu.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 Mon, 2012-01-02 at 17:16 +0000, Olaf Hering wrote:
> On Tue, Dec 20, Ian Campbell wrote:
> 
> > 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.
> 
> 
> If you could come up with a patch to present xenstored (or other
> dom0/toolstack) features, that would be great.

As I said in the bit you trimmed the precedent seems to be to
write /local/domain/<N>/control/platform-feature-<X> for each guest that
you want to expose the feature to. I think a per-guest key makes sense
since even if something seems obviously global you never know when you
might need to hide it from a guest (e.g. to workaround an in-guest bug).

I'm afraid I don't have time to work on this myself but it seems pretty
simple?

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 11:02:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri280-0003Om-Ev; Tue, 03 Jan 2012 11:02: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 1Ri27y-0003Oe-Vh
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 11:01:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325588512!10183245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16883 invoked from network); 3 Jan 2012 11:01: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;
	3 Jan 2012 11:01:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9787577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 11:01: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; Tue, 3 Jan 2012
	11:01:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 3 Jan 2012 11:01:52 +0000
In-Reply-To: <20120102171631.GA13603@aepfle.de>
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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325588512.25206.60.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>,
	Ian Jackson <Ian.Jackson@eu.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 Mon, 2012-01-02 at 17:16 +0000, Olaf Hering wrote:
> On Tue, Dec 20, Ian Campbell wrote:
> 
> > 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.
> 
> 
> If you could come up with a patch to present xenstored (or other
> dom0/toolstack) features, that would be great.

As I said in the bit you trimmed the precedent seems to be to
write /local/domain/<N>/control/platform-feature-<X> for each guest that
you want to expose the feature to. I think a per-guest key makes sense
since even if something seems obviously global you never know when you
might need to hide it from a guest (e.g. to workaround an in-guest bug).

I'm afraid I don't have time to work on this myself but it seems pretty
simple?

Ian.



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 11:56:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 11: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 1Ri2yj-0003rp-VY; Tue, 03 Jan 2012 11:56:30 +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 1Ri2yh-0003rk-V7
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 11:56:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325591779!9535377!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 31616 invoked from network); 3 Jan 2012 11:56:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 11:56:21 -0000
Received: by pbbb11 with SMTP id b11so56459523pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 03:56: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=sLJrzE6j5zZ9vxcARJxOVh2bAMN5g+7uVaGcO6kkj/c=;
	b=rzCMqjD3y36/Aew+MvwpgscR/jzrg3Y8nMKiZogpjAjuQasBn/+pjfSnMJbHi2oIOt
	R3Bw7M8jyrBkb+ebADJot7wrKCNN/enHatoPZSAghlaCxXSl07r8fwyl4iMTh6dpAYYV
	beLeFAuOoAUMOMZRuLCwTwDQyyF1Os5fWJ0M8=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr129934497pbc.112.1325591779471;
	Tue, 03 Jan 2012 03:56:19 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 03:56:19 -0800 (PST)
In-Reply-To: <1325587099.25206.41.camel@zakaz.uk.xensource.com>
References: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
	<1325587099.25206.41.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Jan 2012 12:56:19 +0100
X-Google-Sender-Auth: X2e3Q8kc3QMOJZmm853C-lpAhfc
Message-ID: <CAPLaKK4ewUjrr=ZcsgJJ6xr74FG8qHR8+aQ9NM34Z5gYcesktA@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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gTW9u
LCAyMDEyLTAxLTAyIGF0IDEwOjQ5ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNTUwMTE1MSAtMzYwMAo+PiAjIE5vZGUgSUQgYmQ1
OWEwN2VkNDExODdiY2FmYzRkZDUyMTRmMDc0NGM2NmVmMjA2OQo+PiAjIFBhcmVudCDCoDNlMDJh
YTk2NzBiMzI2NWUzNmJkZGRiZDQ3NjA0MTVjZDg3ZDA0N2IKPj4gcHlncnViOiBmaXggZXh0bGlu
dXggcGFyc2luZwo+Pgo+PiBweWdydWIgd2FzIHVuYWJsZSB0byBwYXJzZSBleHRsaW51eCBjb25m
aWcgZmlsZXMgY29ycmVjdGx5LCBleGFjdGx5Cj4+IHRoZSBvbmVzIGxpa2U6Cj4+Cj4+IExBQkVM
IGdyc2VjCj4+IMKgIEtFUk5FTCB2bWxpbnV6LTMuMC4xMC1ncnNlYwo+PiDCoCBBUFBFTkQgaW5p
dHJkPWluaXRyYW1mcy0zLjAuMTAtZ3JzZWMKPj4gcm9vdD1VVUlEPWNmZDRhN2I0LThjNDAtNDAy
NS1iODc3LTgyMDVmMWM2MjJlZQo+PiBtb2R1bGVzPXNkLW1vZCx1c2Itc3RvcmFnZSxleHQ0IHhl
biBxdWlldAo+Pgo+PiBUaGlzIHBhdGNoIGZpeGVzIGl0LCBhZGRpbmcgYSBuZXcgY2FzZSB3aGVu
IHBhcnNpbmcgdGhlICJhcHBlbmQiIGxpbmUsCj4+IHRoYXQgc2VhcmNoZXMgZm9yIHRoZSBpbml0
cmQgaW1hZ2UuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4KPiBQbGVhc2UgY291bGQgeW91IGFsc28gc3VwcGx5IGFuIGV4YW1w
bGUgZmlsZSBmb3IgeW91ciBwbGF0Zm9ybSBhcyBhCj4gcGF0Y2ggdG8gdG9vbHMvcHlncnViL2V4
YW1wbGVzLgoKRG9uZS4KCj4+IGRpZmYgLXIgM2UwMmFhOTY3MGIzIC1yIGJkNTlhMDdlZDQxMSB0
b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weQo+PiAtLS0gYS90b29scy9weWdydWIvc3Jj
L0V4dExpbnV4Q29uZi5weSDCoCDCoCDCoCDCoFRodSBEZWMgMTUgMTg6NTU6NDYgMjAxMSArMDEw
MAo+PiArKysgYi90b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weSDCoCDCoCDCoCDCoE1v
biBKYW4gMDIgMTE6NDU6NTEgMjAxMiArMDEwMAo+PiBAQCAtNjAsNiArNjAsMTMgQEAgY2xhc3Mg
RXh0TGludXhJbWFnZShvYmplY3QpOgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCMg
QnlwYXNzIHJlZ3VsYXIgc2VsZi5jb21tYW5kcyBoYW5kbGluZwo+PiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoGNvbSA9IE5vbmUKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoGVsaWYgYXJnLmZpbmQo
IiAiKToKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCMgZmluZCBpbml0cmQgaW1hZ2UgaW4g
YXBwZW5kIGxpbmUKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFyZ3MgPSBhcmcuc3RyaXAo
KS5zcGxpdCgiICIpCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmb3IgYSBpbiBhcmdzOgo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYgYS5sb3dlcigpLnN0YXJ0c3dpdGgo
ImluaXRyZCIpOgo+Cj4gU2hvdWxkIGNoZWNrIGZvciAiaW5pdHJkPSIgaGVyZT8KClllcwoKPiBP
ciBwZXJoYXBzOgo+IMKgIMKgIMKgIMKgKiBjaGVjayBmb3IgIj0iCj4gwqAgwqAgwqAgwqAqIHNw
bGl0IGludG8gImsgPSB2Igo+IMKgIMKgIMKgIMKgKiBjaGVjayB0aGF0IGsgaXMgcHJlY2lzZWx5
ICJpbml0cmQiCj4gdGhlIGZpcnN0IHR3byBhcmUgcHJvYmFibHkgZG9hYmxlIGluIHRoZSBzYW1l
IHN0ci5zcGxpdCBpbnZvY2F0aW9uIGlmCj4geW91IGhhbmRsZSB0aGUgZXhjZXB0aW9uIGNvcnJl
Y3RseS4KCkknbSBub3QgcmVhbGx5IHN1cmUgYWJvdXQgc3BsaXR0aW5nICc9Jywgc29tZSBhcmdz
LCBsaWtlIHJvb3QsIGFyZQpyb290PVVVSUQ9WFhYWCwgd2hpY2ggbWlnaHQgYmUgZGlmZmljdWx0
IHRvIHBhcnNlIGluIGEgc2luZ2xlIHNwbGl0CihhdCBsZWFzdCBmb3IgbWUpLiBXaWxsIGxvb2sg
YXQgaXQgbGF0ZXIgYW5kIHBvc3QgYW4gdXBkYXRlZCBwYXRjaC4KCj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXRhdHRyKHNlbGYsICJpbml0cmQiLCBhLnJlcGxhY2Uo
ImluaXRyZD0iLCAiIikpCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBh
cmcgPSBhcmcucmVwbGFjZShhLCAiIikKPj4KPj4gwqAgwqAgwqAgwqAgwqBpZiBjb20gaXMgbm90
IE5vbmUgYW5kIHNlbGYuY29tbWFuZHMuaGFzX2tleShjb20pOgo+PiDCoCDCoCDCoCDCoCDCoCDC
oCDCoGlmIHNlbGYuY29tbWFuZHNbY29tXSBpcyBub3QgTm9uZToKPj4gQEAgLTg2LDEwICs5Mywx
MiBAQCBjbGFzcyBFeHRMaW51eEltYWdlKG9iamVjdCk6Cj4+IMKgIMKgIMKgIMKgIMKgc2VsZi5f
YXJncyA9IGFyZ3MKPj4gwqAgwqAgwqBkZWYgZ2V0X2tlcm5lbChzZWxmKToKPj4gwqAgwqAgwqAg
wqAgwqByZXR1cm4gc2VsZi5fa2VybmVsCj4+ICsgwqAgwqBkZWYgc2V0X2FyZ3Moc2VsZiwgdmFs
KToKPj4gKyDCoCDCoCDCoCDCoHNlbGYuX2FyZ3MgPSB2YWwKPj4gwqAgwqAgwqBkZWYgZ2V0X2Fy
Z3Moc2VsZik6Cj4+IMKgIMKgIMKgIMKgIMKgcmV0dXJuIHNlbGYuX2FyZ3MKPj4gwqAgwqAgwqBr
ZXJuZWwgPSBwcm9wZXJ0eShnZXRfa2VybmVsLCBzZXRfa2VybmVsKQo+PiAtIMKgIMKgYXJncyA9
IHByb3BlcnR5KGdldF9hcmdzKQo+PiArIMKgIMKgYXJncyA9IHByb3BlcnR5KGdldF9hcmdzLCBz
ZXRfYXJncykKPgo+IEFyZSB0aGVzZSBzb21ldGhpbmcgcmVxdWlyZWQgYnkgYXJnLnJlcGxhY2U/
CgphcmdzIHdhcyBzZXQgd2hlbiBzZXR0aW5nIGtlcm5lbCBpbiBwcmV2aW91cyB2ZXJzaW9uLCBi
ZWNhdXNlIGl0CmFzc3VtZWQgdGhlIGxpbmUgd2FzOgoKYXBwZW5kIDxrZXJuZWw+IDxhcmdzPiAt
LS0gPGluaXRyZD4KClNvIGFyZ3Mgd2hlcmUgb2J0YWluZWQgd2hlbiB0aGUga2VybmVsIHdhcyBw
YXJzZWQsIGJ1dCB5b3UgY2FuIGFsc28gaGF2ZQoKa2VybmVsIDxrZXJuZWw+CmFwcGVuZCA8YXJn
cz4KCkFuZCA8YXJncz4gY29udGFpbiB0aGUgaW5pdHJkIHBhdGgsIEkgcmVtb3ZlIHRoZSAiaW5p
dHJkPVhYWCIgZnJvbSB0aGUKYXJncyBhbmQgcHJvY2VzcyB0aGVtIG5vcm1hbGx5LgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 03 11:56:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 11: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 1Ri2yj-0003rp-VY; Tue, 03 Jan 2012 11:56:30 +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 1Ri2yh-0003rk-V7
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 11:56:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325591779!9535377!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 31616 invoked from network); 3 Jan 2012 11:56:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 11:56:21 -0000
Received: by pbbb11 with SMTP id b11so56459523pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 03:56: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=sLJrzE6j5zZ9vxcARJxOVh2bAMN5g+7uVaGcO6kkj/c=;
	b=rzCMqjD3y36/Aew+MvwpgscR/jzrg3Y8nMKiZogpjAjuQasBn/+pjfSnMJbHi2oIOt
	R3Bw7M8jyrBkb+ebADJot7wrKCNN/enHatoPZSAghlaCxXSl07r8fwyl4iMTh6dpAYYV
	beLeFAuOoAUMOMZRuLCwTwDQyyF1Os5fWJ0M8=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr129934497pbc.112.1325591779471;
	Tue, 03 Jan 2012 03:56:19 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 03:56:19 -0800 (PST)
In-Reply-To: <1325587099.25206.41.camel@zakaz.uk.xensource.com>
References: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
	<1325587099.25206.41.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Jan 2012 12:56:19 +0100
X-Google-Sender-Auth: X2e3Q8kc3QMOJZmm853C-lpAhfc
Message-ID: <CAPLaKK4ewUjrr=ZcsgJJ6xr74FG8qHR8+aQ9NM34Z5gYcesktA@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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gTW9u
LCAyMDEyLTAxLTAyIGF0IDEwOjQ5ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNTUwMTE1MSAtMzYwMAo+PiAjIE5vZGUgSUQgYmQ1
OWEwN2VkNDExODdiY2FmYzRkZDUyMTRmMDc0NGM2NmVmMjA2OQo+PiAjIFBhcmVudCDCoDNlMDJh
YTk2NzBiMzI2NWUzNmJkZGRiZDQ3NjA0MTVjZDg3ZDA0N2IKPj4gcHlncnViOiBmaXggZXh0bGlu
dXggcGFyc2luZwo+Pgo+PiBweWdydWIgd2FzIHVuYWJsZSB0byBwYXJzZSBleHRsaW51eCBjb25m
aWcgZmlsZXMgY29ycmVjdGx5LCBleGFjdGx5Cj4+IHRoZSBvbmVzIGxpa2U6Cj4+Cj4+IExBQkVM
IGdyc2VjCj4+IMKgIEtFUk5FTCB2bWxpbnV6LTMuMC4xMC1ncnNlYwo+PiDCoCBBUFBFTkQgaW5p
dHJkPWluaXRyYW1mcy0zLjAuMTAtZ3JzZWMKPj4gcm9vdD1VVUlEPWNmZDRhN2I0LThjNDAtNDAy
NS1iODc3LTgyMDVmMWM2MjJlZQo+PiBtb2R1bGVzPXNkLW1vZCx1c2Itc3RvcmFnZSxleHQ0IHhl
biBxdWlldAo+Pgo+PiBUaGlzIHBhdGNoIGZpeGVzIGl0LCBhZGRpbmcgYSBuZXcgY2FzZSB3aGVu
IHBhcnNpbmcgdGhlICJhcHBlbmQiIGxpbmUsCj4+IHRoYXQgc2VhcmNoZXMgZm9yIHRoZSBpbml0
cmQgaW1hZ2UuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4KPiBQbGVhc2UgY291bGQgeW91IGFsc28gc3VwcGx5IGFuIGV4YW1w
bGUgZmlsZSBmb3IgeW91ciBwbGF0Zm9ybSBhcyBhCj4gcGF0Y2ggdG8gdG9vbHMvcHlncnViL2V4
YW1wbGVzLgoKRG9uZS4KCj4+IGRpZmYgLXIgM2UwMmFhOTY3MGIzIC1yIGJkNTlhMDdlZDQxMSB0
b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weQo+PiAtLS0gYS90b29scy9weWdydWIvc3Jj
L0V4dExpbnV4Q29uZi5weSDCoCDCoCDCoCDCoFRodSBEZWMgMTUgMTg6NTU6NDYgMjAxMSArMDEw
MAo+PiArKysgYi90b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weSDCoCDCoCDCoCDCoE1v
biBKYW4gMDIgMTE6NDU6NTEgMjAxMiArMDEwMAo+PiBAQCAtNjAsNiArNjAsMTMgQEAgY2xhc3Mg
RXh0TGludXhJbWFnZShvYmplY3QpOgo+Pgo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCMg
QnlwYXNzIHJlZ3VsYXIgc2VsZi5jb21tYW5kcyBoYW5kbGluZwo+PiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoGNvbSA9IE5vbmUKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoGVsaWYgYXJnLmZpbmQo
IiAiKToKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCMgZmluZCBpbml0cmQgaW1hZ2UgaW4g
YXBwZW5kIGxpbmUKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFyZ3MgPSBhcmcuc3RyaXAo
KS5zcGxpdCgiICIpCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmb3IgYSBpbiBhcmdzOgo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYgYS5sb3dlcigpLnN0YXJ0c3dpdGgo
ImluaXRyZCIpOgo+Cj4gU2hvdWxkIGNoZWNrIGZvciAiaW5pdHJkPSIgaGVyZT8KClllcwoKPiBP
ciBwZXJoYXBzOgo+IMKgIMKgIMKgIMKgKiBjaGVjayBmb3IgIj0iCj4gwqAgwqAgwqAgwqAqIHNw
bGl0IGludG8gImsgPSB2Igo+IMKgIMKgIMKgIMKgKiBjaGVjayB0aGF0IGsgaXMgcHJlY2lzZWx5
ICJpbml0cmQiCj4gdGhlIGZpcnN0IHR3byBhcmUgcHJvYmFibHkgZG9hYmxlIGluIHRoZSBzYW1l
IHN0ci5zcGxpdCBpbnZvY2F0aW9uIGlmCj4geW91IGhhbmRsZSB0aGUgZXhjZXB0aW9uIGNvcnJl
Y3RseS4KCkknbSBub3QgcmVhbGx5IHN1cmUgYWJvdXQgc3BsaXR0aW5nICc9Jywgc29tZSBhcmdz
LCBsaWtlIHJvb3QsIGFyZQpyb290PVVVSUQ9WFhYWCwgd2hpY2ggbWlnaHQgYmUgZGlmZmljdWx0
IHRvIHBhcnNlIGluIGEgc2luZ2xlIHNwbGl0CihhdCBsZWFzdCBmb3IgbWUpLiBXaWxsIGxvb2sg
YXQgaXQgbGF0ZXIgYW5kIHBvc3QgYW4gdXBkYXRlZCBwYXRjaC4KCj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzZXRhdHRyKHNlbGYsICJpbml0cmQiLCBhLnJlcGxhY2Uo
ImluaXRyZD0iLCAiIikpCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBh
cmcgPSBhcmcucmVwbGFjZShhLCAiIikKPj4KPj4gwqAgwqAgwqAgwqAgwqBpZiBjb20gaXMgbm90
IE5vbmUgYW5kIHNlbGYuY29tbWFuZHMuaGFzX2tleShjb20pOgo+PiDCoCDCoCDCoCDCoCDCoCDC
oCDCoGlmIHNlbGYuY29tbWFuZHNbY29tXSBpcyBub3QgTm9uZToKPj4gQEAgLTg2LDEwICs5Mywx
MiBAQCBjbGFzcyBFeHRMaW51eEltYWdlKG9iamVjdCk6Cj4+IMKgIMKgIMKgIMKgIMKgc2VsZi5f
YXJncyA9IGFyZ3MKPj4gwqAgwqAgwqBkZWYgZ2V0X2tlcm5lbChzZWxmKToKPj4gwqAgwqAgwqAg
wqAgwqByZXR1cm4gc2VsZi5fa2VybmVsCj4+ICsgwqAgwqBkZWYgc2V0X2FyZ3Moc2VsZiwgdmFs
KToKPj4gKyDCoCDCoCDCoCDCoHNlbGYuX2FyZ3MgPSB2YWwKPj4gwqAgwqAgwqBkZWYgZ2V0X2Fy
Z3Moc2VsZik6Cj4+IMKgIMKgIMKgIMKgIMKgcmV0dXJuIHNlbGYuX2FyZ3MKPj4gwqAgwqAgwqBr
ZXJuZWwgPSBwcm9wZXJ0eShnZXRfa2VybmVsLCBzZXRfa2VybmVsKQo+PiAtIMKgIMKgYXJncyA9
IHByb3BlcnR5KGdldF9hcmdzKQo+PiArIMKgIMKgYXJncyA9IHByb3BlcnR5KGdldF9hcmdzLCBz
ZXRfYXJncykKPgo+IEFyZSB0aGVzZSBzb21ldGhpbmcgcmVxdWlyZWQgYnkgYXJnLnJlcGxhY2U/
CgphcmdzIHdhcyBzZXQgd2hlbiBzZXR0aW5nIGtlcm5lbCBpbiBwcmV2aW91cyB2ZXJzaW9uLCBi
ZWNhdXNlIGl0CmFzc3VtZWQgdGhlIGxpbmUgd2FzOgoKYXBwZW5kIDxrZXJuZWw+IDxhcmdzPiAt
LS0gPGluaXRyZD4KClNvIGFyZ3Mgd2hlcmUgb2J0YWluZWQgd2hlbiB0aGUga2VybmVsIHdhcyBw
YXJzZWQsIGJ1dCB5b3UgY2FuIGFsc28gaGF2ZQoKa2VybmVsIDxrZXJuZWw+CmFwcGVuZCA8YXJn
cz4KCkFuZCA8YXJncz4gY29udGFpbiB0aGUgaW5pdHJkIHBhdGgsIEkgcmVtb3ZlIHRoZSAiaW5p
dHJkPVhYWCIgZnJvbSB0aGUKYXJncyBhbmQgcHJvY2VzcyB0aGVtIG5vcm1hbGx5LgoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 03 11:59:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri31X-0003xL-Uc; Tue, 03 Jan 2012 11:59:24 +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 1Ri31W-0003x5-8j
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 11:59:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1325591954!8399994!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5OTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4994 invoked from network); 3 Jan 2012 11:59:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 11:59:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320642000"; d="scan'208";a="176073502"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 06:59:14 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	06:59:14 -0500
Message-ID: <4F02ED82.9080907@citrix.com>
Date: Tue, 3 Jan 2012 11:58: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
	<4EFE533D.5020307@citrix.com>
	<4EFEBBDD020000780007C25E@nat28.tlf.novell.com>
In-Reply-To: <4EFEBBDD020000780007C25E@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 31/12/11 07:38, Jan Beulich wrote:
>>>> 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.

Right - that is useful to know.

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

Assuming that all relevant structures do in fact get allocated by
alloc_xenheap_pages() (which is probably a safe assumption looking at
the code, but I am not certain) then yes, it would have much less impact
on the existing code.  However, it would have a much bigger impact on
the other memory restricted items.  It might be possible (and perhaps a
good idea when extreme debugging is needed) to have a 3rd command line
option for low_crashinfo= which does this, but I dont like it as the
general solution to this problem.

-- 
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 Jan 03 11:59:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri31X-0003xL-Uc; Tue, 03 Jan 2012 11:59:24 +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 1Ri31W-0003x5-8j
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 11:59:22 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1325591954!8399994!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc5OTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4994 invoked from network); 3 Jan 2012 11:59:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 11:59:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320642000"; d="scan'208";a="176073502"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 06:59:14 -0500
Received: from [10.80.2.18] (10.80.2.18) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	06:59:14 -0500
Message-ID: <4F02ED82.9080907@citrix.com>
Date: Tue, 3 Jan 2012 11:58: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <jbeulich@suse.com>
References: <4EFC8C73020000780007C160@nat28.tlf.novell.com>
	<4EFE533D.5020307@citrix.com>
	<4EFEBBDD020000780007C25E@nat28.tlf.novell.com>
In-Reply-To: <4EFEBBDD020000780007C25E@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 31/12/11 07:38, Jan Beulich wrote:
>>>> 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.

Right - that is useful to know.

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

Assuming that all relevant structures do in fact get allocated by
alloc_xenheap_pages() (which is probably a safe assumption looking at
the code, but I am not certain) then yes, it would have much less impact
on the existing code.  However, it would have a much bigger impact on
the other memory restricted items.  It might be possible (and perhaps a
good idea when extreme debugging is needed) to have a 3rd command line
option for low_crashinfo= which does this, but I dont like it as the
general solution to this problem.

-- 
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 Jan 03 12:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 12:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri3Ct-0004QX-R8; Tue, 03 Jan 2012 12:11: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 1Ri3Cr-0004QS-Py
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 12:11:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325592659!9416782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29969 invoked from network); 3 Jan 2012 12:10:59 -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;
	3 Jan 2012 12:10:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9789076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 12: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, 3 Jan 2012
	12:10:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 3 Jan 2012 12:10:25 +0000
In-Reply-To: <CAPLaKK4ewUjrr=ZcsgJJ6xr74FG8qHR8+aQ9NM34Z5gYcesktA@mail.gmail.com>
References: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
	<1325587099.25206.41.camel@zakaz.uk.xensource.com>
	<CAPLaKK4ewUjrr=ZcsgJJ6xr74FG8qHR8+aQ9NM34Z5gYcesktA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325592626.25206.94.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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAxLTAzIGF0IDExOjU2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8zIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+ID4g
T24gTW9uLCAyMDEyLTAxLTAyIGF0IDEwOjQ5ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gPj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxy
b2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+PiAjIERhdGUgMTMyNTUwMTE1MSAtMzYwMAo+ID4+
ICMgTm9kZSBJRCBiZDU5YTA3ZWQ0MTE4N2JjYWZjNGRkNTIxNGYwNzQ0YzY2ZWYyMDY5Cj4gPj4g
IyBQYXJlbnQgIDNlMDJhYTk2NzBiMzI2NWUzNmJkZGRiZDQ3NjA0MTVjZDg3ZDA0N2IKPiA+PiBw
eWdydWI6IGZpeCBleHRsaW51eCBwYXJzaW5nCj4gPj4KPiA+PiBweWdydWIgd2FzIHVuYWJsZSB0
byBwYXJzZSBleHRsaW51eCBjb25maWcgZmlsZXMgY29ycmVjdGx5LCBleGFjdGx5Cj4gPj4gdGhl
IG9uZXMgbGlrZToKPiA+Pgo+ID4+IExBQkVMIGdyc2VjCj4gPj4gICBLRVJORUwgdm1saW51ei0z
LjAuMTAtZ3JzZWMKPiA+PiAgIEFQUEVORCBpbml0cmQ9aW5pdHJhbWZzLTMuMC4xMC1ncnNlYwo+
ID4+IHJvb3Q9VVVJRD1jZmQ0YTdiNC04YzQwLTQwMjUtYjg3Ny04MjA1ZjFjNjIyZWUKPiA+PiBt
b2R1bGVzPXNkLW1vZCx1c2Itc3RvcmFnZSxleHQ0IHhlbiBxdWlldAo+ID4+Cj4gPj4gVGhpcyBw
YXRjaCBmaXhlcyBpdCwgYWRkaW5nIGEgbmV3IGNhc2Ugd2hlbiBwYXJzaW5nIHRoZSAiYXBwZW5k
IiBsaW5lLAo+ID4+IHRoYXQgc2VhcmNoZXMgZm9yIHRoZSBpbml0cmQgaW1hZ2UuCj4gPj4KPiA+
PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1
Pgo+ID4KPiA+IFBsZWFzZSBjb3VsZCB5b3UgYWxzbyBzdXBwbHkgYW4gZXhhbXBsZSBmaWxlIGZv
ciB5b3VyIHBsYXRmb3JtIGFzIGEKPiA+IHBhdGNoIHRvIHRvb2xzL3B5Z3J1Yi9leGFtcGxlcy4K
PiAKPiBEb25lLgo+IAo+ID4+IGRpZmYgLXIgM2UwMmFhOTY3MGIzIC1yIGJkNTlhMDdlZDQxMSB0
b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weQo+ID4+IC0tLSBhL3Rvb2xzL3B5Z3J1Yi9z
cmMvRXh0TGludXhDb25mLnB5ICAgICAgICBUaHUgRGVjIDE1IDE4OjU1OjQ2IDIwMTEgKzAxMDAK
PiA+PiArKysgYi90b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weSAgICAgICAgTW9uIEph
biAwMiAxMTo0NTo1MSAyMDEyICswMTAwCj4gPj4gQEAgLTYwLDYgKzYwLDEzIEBAIGNsYXNzIEV4
dExpbnV4SW1hZ2Uob2JqZWN0KToKPiA+Pgo+ID4+ICAgICAgICAgICAgICAgICAgIyBCeXBhc3Mg
cmVndWxhciBzZWxmLmNvbW1hbmRzIGhhbmRsaW5nCj4gPj4gICAgICAgICAgICAgICAgICBjb20g
PSBOb25lCj4gPj4gKyAgICAgICAgICAgIGVsaWYgYXJnLmZpbmQoIiAiKToKPiA+PiArICAgICAg
ICAgICAgICAgICMgZmluZCBpbml0cmQgaW1hZ2UgaW4gYXBwZW5kIGxpbmUKPiA+PiArICAgICAg
ICAgICAgICAgIGFyZ3MgPSBhcmcuc3RyaXAoKS5zcGxpdCgiICIpCj4gPj4gKyAgICAgICAgICAg
ICAgICBmb3IgYSBpbiBhcmdzOgo+ID4+ICsgICAgICAgICAgICAgICAgICAgIGlmIGEubG93ZXIo
KS5zdGFydHN3aXRoKCJpbml0cmQiKToKPiA+Cj4gPiBTaG91bGQgY2hlY2sgZm9yICJpbml0cmQ9
IiBoZXJlPwo+IAo+IFllcwo+IAo+ID4gT3IgcGVyaGFwczoKPiA+ICAgICAgICAqIGNoZWNrIGZv
ciAiPSIKPiA+ICAgICAgICAqIHNwbGl0IGludG8gImsgPSB2Igo+ID4gICAgICAgICogY2hlY2sg
dGhhdCBrIGlzIHByZWNpc2VseSAiaW5pdHJkIgo+ID4gdGhlIGZpcnN0IHR3byBhcmUgcHJvYmFi
bHkgZG9hYmxlIGluIHRoZSBzYW1lIHN0ci5zcGxpdCBpbnZvY2F0aW9uIGlmCj4gPiB5b3UgaGFu
ZGxlIHRoZSBleGNlcHRpb24gY29ycmVjdGx5Lgo+IAo+IEknbSBub3QgcmVhbGx5IHN1cmUgYWJv
dXQgc3BsaXR0aW5nICc9Jywgc29tZSBhcmdzLCBsaWtlIHJvb3QsIGFyZQo+IHJvb3Q9VVVJRD1Y
WFhYLCB3aGljaCBtaWdodCBiZSBkaWZmaWN1bHQgdG8gcGFyc2UgaW4gYSBzaW5nbGUgc3BsaXQK
PiAoYXQgbGVhc3QgZm9yIG1lKS4gV2lsbCBsb29rIGF0IGl0IGxhdGVyIGFuZCBwb3N0IGFuIHVw
ZGF0ZWQgcGF0Y2guCgpJIHRoaW5rIHlvdSBuZWVkIHRvIGFsd2F5cyBzcGxpdCBvbiB0aGUgZmly
c3QgPS4KCj4gCj4gPj4gKyAgICAgICAgICAgICAgICAgICAgICAgIHNldGF0dHIoc2VsZiwgImlu
aXRyZCIsIGEucmVwbGFjZSgiaW5pdHJkPSIsICIiKSkKPiA+PiArICAgICAgICAgICAgICAgICAg
ICAgICAgYXJnID0gYXJnLnJlcGxhY2UoYSwgIiIpCj4gPj4KPiA+PiAgICAgICAgICBpZiBjb20g
aXMgbm90IE5vbmUgYW5kIHNlbGYuY29tbWFuZHMuaGFzX2tleShjb20pOgo+ID4+ICAgICAgICAg
ICAgICBpZiBzZWxmLmNvbW1hbmRzW2NvbV0gaXMgbm90IE5vbmU6Cj4gPj4gQEAgLTg2LDEwICs5
MywxMiBAQCBjbGFzcyBFeHRMaW51eEltYWdlKG9iamVjdCk6Cj4gPj4gICAgICAgICAgc2VsZi5f
YXJncyA9IGFyZ3MKPiA+PiAgICAgIGRlZiBnZXRfa2VybmVsKHNlbGYpOgo+ID4+ICAgICAgICAg
IHJldHVybiBzZWxmLl9rZXJuZWwKPiA+PiArICAgIGRlZiBzZXRfYXJncyhzZWxmLCB2YWwpOgo+
ID4+ICsgICAgICAgIHNlbGYuX2FyZ3MgPSB2YWwKPiA+PiAgICAgIGRlZiBnZXRfYXJncyhzZWxm
KToKPiA+PiAgICAgICAgICByZXR1cm4gc2VsZi5fYXJncwo+ID4+ICAgICAga2VybmVsID0gcHJv
cGVydHkoZ2V0X2tlcm5lbCwgc2V0X2tlcm5lbCkKPiA+PiAtICAgIGFyZ3MgPSBwcm9wZXJ0eShn
ZXRfYXJncykKPiA+PiArICAgIGFyZ3MgPSBwcm9wZXJ0eShnZXRfYXJncywgc2V0X2FyZ3MpCj4g
Pgo+ID4gQXJlIHRoZXNlIHNvbWV0aGluZyByZXF1aXJlZCBieSBhcmcucmVwbGFjZT8KPiAKPiBh
cmdzIHdhcyBzZXQgd2hlbiBzZXR0aW5nIGtlcm5lbCBpbiBwcmV2aW91cyB2ZXJzaW9uLCBiZWNh
dXNlIGl0Cj4gYXNzdW1lZCB0aGUgbGluZSB3YXM6Cj4gCj4gYXBwZW5kIDxrZXJuZWw+IDxhcmdz
PiAtLS0gPGluaXRyZD4KCkFoLCByaWdodC4gVGhpcyBpcyB0aGUgbWJvb3QuYzMyIHN5bnRheCAo
aS5lLiBpdCBpcyBhbHdheXMgYXNzb2NpYXRlZAp3aXRoICJrZXJuZWwgbWJvb3QuYzMyIikuIElJ
UkMgaXQgaXMgYWN0dWFsbHkKCWFwcGVuZCA8aHlwZXJ2aXNvcj4gPGFyZ3M+IC0tLSA8a2VybmVs
PiA8YXJncz4gLS0tIDxpbml0cmQ+Ck9yIG1vcmUgZ2VuZXJhbGx5ICJbPHRoaW5nPiA8YXJncz4g
LS0tXSsiCgpQZXJoYXBzIHRoaXMgb3VnaHQgdG8ga2V5IG9mZiB0aGUgcHJlc2VuY2Ugb2Yga2Vy
bmVsIG1ib290LmMzMgpzcGVjaWZpY2FsbHk/Cgo+IFNvIGFyZ3Mgd2hlcmUgb2J0YWluZWQgd2hl
biB0aGUga2VybmVsIHdhcyBwYXJzZWQsIGJ1dCB5b3UgY2FuIGFsc28gaGF2ZQo+IAo+IGtlcm5l
bCA8a2VybmVsPgo+IGFwcGVuZCA8YXJncz4KClRoaXMgaXMgYWN0dWFsbHkgdGhlICJub3JtYWwi
IGV4dGxpbnV4IHN5bnRheC4KCj4gQW5kIDxhcmdzPiBjb250YWluIHRoZSBpbml0cmQgcGF0aCwg
SSByZW1vdmUgdGhlICJpbml0cmQ9WFhYIiBmcm9tIHRoZQo+IGFyZ3MgYW5kIHByb2Nlc3MgdGhl
bSBub3JtYWxseS4KClJpZ2h0LgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 03 12:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 12:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri3Ct-0004QX-R8; Tue, 03 Jan 2012 12:11: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 1Ri3Cr-0004QS-Py
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 12:11:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325592659!9416782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29969 invoked from network); 3 Jan 2012 12:10:59 -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;
	3 Jan 2012 12:10:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; 
   d="scan'208";a="9789076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 12: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, 3 Jan 2012
	12:10:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 3 Jan 2012 12:10:25 +0000
In-Reply-To: <CAPLaKK4ewUjrr=ZcsgJJ6xr74FG8qHR8+aQ9NM34Z5gYcesktA@mail.gmail.com>
References: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
	<1325587099.25206.41.camel@zakaz.uk.xensource.com>
	<CAPLaKK4ewUjrr=ZcsgJJ6xr74FG8qHR8+aQ9NM34Z5gYcesktA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325592626.25206.94.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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAxLTAzIGF0IDExOjU2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8zIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+ID4g
T24gTW9uLCAyMDEyLTAxLTAyIGF0IDEwOjQ5ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gPj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxy
b2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+PiAjIERhdGUgMTMyNTUwMTE1MSAtMzYwMAo+ID4+
ICMgTm9kZSBJRCBiZDU5YTA3ZWQ0MTE4N2JjYWZjNGRkNTIxNGYwNzQ0YzY2ZWYyMDY5Cj4gPj4g
IyBQYXJlbnQgIDNlMDJhYTk2NzBiMzI2NWUzNmJkZGRiZDQ3NjA0MTVjZDg3ZDA0N2IKPiA+PiBw
eWdydWI6IGZpeCBleHRsaW51eCBwYXJzaW5nCj4gPj4KPiA+PiBweWdydWIgd2FzIHVuYWJsZSB0
byBwYXJzZSBleHRsaW51eCBjb25maWcgZmlsZXMgY29ycmVjdGx5LCBleGFjdGx5Cj4gPj4gdGhl
IG9uZXMgbGlrZToKPiA+Pgo+ID4+IExBQkVMIGdyc2VjCj4gPj4gICBLRVJORUwgdm1saW51ei0z
LjAuMTAtZ3JzZWMKPiA+PiAgIEFQUEVORCBpbml0cmQ9aW5pdHJhbWZzLTMuMC4xMC1ncnNlYwo+
ID4+IHJvb3Q9VVVJRD1jZmQ0YTdiNC04YzQwLTQwMjUtYjg3Ny04MjA1ZjFjNjIyZWUKPiA+PiBt
b2R1bGVzPXNkLW1vZCx1c2Itc3RvcmFnZSxleHQ0IHhlbiBxdWlldAo+ID4+Cj4gPj4gVGhpcyBw
YXRjaCBmaXhlcyBpdCwgYWRkaW5nIGEgbmV3IGNhc2Ugd2hlbiBwYXJzaW5nIHRoZSAiYXBwZW5k
IiBsaW5lLAo+ID4+IHRoYXQgc2VhcmNoZXMgZm9yIHRoZSBpbml0cmQgaW1hZ2UuCj4gPj4KPiA+
PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1
Pgo+ID4KPiA+IFBsZWFzZSBjb3VsZCB5b3UgYWxzbyBzdXBwbHkgYW4gZXhhbXBsZSBmaWxlIGZv
ciB5b3VyIHBsYXRmb3JtIGFzIGEKPiA+IHBhdGNoIHRvIHRvb2xzL3B5Z3J1Yi9leGFtcGxlcy4K
PiAKPiBEb25lLgo+IAo+ID4+IGRpZmYgLXIgM2UwMmFhOTY3MGIzIC1yIGJkNTlhMDdlZDQxMSB0
b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weQo+ID4+IC0tLSBhL3Rvb2xzL3B5Z3J1Yi9z
cmMvRXh0TGludXhDb25mLnB5ICAgICAgICBUaHUgRGVjIDE1IDE4OjU1OjQ2IDIwMTEgKzAxMDAK
PiA+PiArKysgYi90b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weSAgICAgICAgTW9uIEph
biAwMiAxMTo0NTo1MSAyMDEyICswMTAwCj4gPj4gQEAgLTYwLDYgKzYwLDEzIEBAIGNsYXNzIEV4
dExpbnV4SW1hZ2Uob2JqZWN0KToKPiA+Pgo+ID4+ICAgICAgICAgICAgICAgICAgIyBCeXBhc3Mg
cmVndWxhciBzZWxmLmNvbW1hbmRzIGhhbmRsaW5nCj4gPj4gICAgICAgICAgICAgICAgICBjb20g
PSBOb25lCj4gPj4gKyAgICAgICAgICAgIGVsaWYgYXJnLmZpbmQoIiAiKToKPiA+PiArICAgICAg
ICAgICAgICAgICMgZmluZCBpbml0cmQgaW1hZ2UgaW4gYXBwZW5kIGxpbmUKPiA+PiArICAgICAg
ICAgICAgICAgIGFyZ3MgPSBhcmcuc3RyaXAoKS5zcGxpdCgiICIpCj4gPj4gKyAgICAgICAgICAg
ICAgICBmb3IgYSBpbiBhcmdzOgo+ID4+ICsgICAgICAgICAgICAgICAgICAgIGlmIGEubG93ZXIo
KS5zdGFydHN3aXRoKCJpbml0cmQiKToKPiA+Cj4gPiBTaG91bGQgY2hlY2sgZm9yICJpbml0cmQ9
IiBoZXJlPwo+IAo+IFllcwo+IAo+ID4gT3IgcGVyaGFwczoKPiA+ICAgICAgICAqIGNoZWNrIGZv
ciAiPSIKPiA+ICAgICAgICAqIHNwbGl0IGludG8gImsgPSB2Igo+ID4gICAgICAgICogY2hlY2sg
dGhhdCBrIGlzIHByZWNpc2VseSAiaW5pdHJkIgo+ID4gdGhlIGZpcnN0IHR3byBhcmUgcHJvYmFi
bHkgZG9hYmxlIGluIHRoZSBzYW1lIHN0ci5zcGxpdCBpbnZvY2F0aW9uIGlmCj4gPiB5b3UgaGFu
ZGxlIHRoZSBleGNlcHRpb24gY29ycmVjdGx5Lgo+IAo+IEknbSBub3QgcmVhbGx5IHN1cmUgYWJv
dXQgc3BsaXR0aW5nICc9Jywgc29tZSBhcmdzLCBsaWtlIHJvb3QsIGFyZQo+IHJvb3Q9VVVJRD1Y
WFhYLCB3aGljaCBtaWdodCBiZSBkaWZmaWN1bHQgdG8gcGFyc2UgaW4gYSBzaW5nbGUgc3BsaXQK
PiAoYXQgbGVhc3QgZm9yIG1lKS4gV2lsbCBsb29rIGF0IGl0IGxhdGVyIGFuZCBwb3N0IGFuIHVw
ZGF0ZWQgcGF0Y2guCgpJIHRoaW5rIHlvdSBuZWVkIHRvIGFsd2F5cyBzcGxpdCBvbiB0aGUgZmly
c3QgPS4KCj4gCj4gPj4gKyAgICAgICAgICAgICAgICAgICAgICAgIHNldGF0dHIoc2VsZiwgImlu
aXRyZCIsIGEucmVwbGFjZSgiaW5pdHJkPSIsICIiKSkKPiA+PiArICAgICAgICAgICAgICAgICAg
ICAgICAgYXJnID0gYXJnLnJlcGxhY2UoYSwgIiIpCj4gPj4KPiA+PiAgICAgICAgICBpZiBjb20g
aXMgbm90IE5vbmUgYW5kIHNlbGYuY29tbWFuZHMuaGFzX2tleShjb20pOgo+ID4+ICAgICAgICAg
ICAgICBpZiBzZWxmLmNvbW1hbmRzW2NvbV0gaXMgbm90IE5vbmU6Cj4gPj4gQEAgLTg2LDEwICs5
MywxMiBAQCBjbGFzcyBFeHRMaW51eEltYWdlKG9iamVjdCk6Cj4gPj4gICAgICAgICAgc2VsZi5f
YXJncyA9IGFyZ3MKPiA+PiAgICAgIGRlZiBnZXRfa2VybmVsKHNlbGYpOgo+ID4+ICAgICAgICAg
IHJldHVybiBzZWxmLl9rZXJuZWwKPiA+PiArICAgIGRlZiBzZXRfYXJncyhzZWxmLCB2YWwpOgo+
ID4+ICsgICAgICAgIHNlbGYuX2FyZ3MgPSB2YWwKPiA+PiAgICAgIGRlZiBnZXRfYXJncyhzZWxm
KToKPiA+PiAgICAgICAgICByZXR1cm4gc2VsZi5fYXJncwo+ID4+ICAgICAga2VybmVsID0gcHJv
cGVydHkoZ2V0X2tlcm5lbCwgc2V0X2tlcm5lbCkKPiA+PiAtICAgIGFyZ3MgPSBwcm9wZXJ0eShn
ZXRfYXJncykKPiA+PiArICAgIGFyZ3MgPSBwcm9wZXJ0eShnZXRfYXJncywgc2V0X2FyZ3MpCj4g
Pgo+ID4gQXJlIHRoZXNlIHNvbWV0aGluZyByZXF1aXJlZCBieSBhcmcucmVwbGFjZT8KPiAKPiBh
cmdzIHdhcyBzZXQgd2hlbiBzZXR0aW5nIGtlcm5lbCBpbiBwcmV2aW91cyB2ZXJzaW9uLCBiZWNh
dXNlIGl0Cj4gYXNzdW1lZCB0aGUgbGluZSB3YXM6Cj4gCj4gYXBwZW5kIDxrZXJuZWw+IDxhcmdz
PiAtLS0gPGluaXRyZD4KCkFoLCByaWdodC4gVGhpcyBpcyB0aGUgbWJvb3QuYzMyIHN5bnRheCAo
aS5lLiBpdCBpcyBhbHdheXMgYXNzb2NpYXRlZAp3aXRoICJrZXJuZWwgbWJvb3QuYzMyIikuIElJ
UkMgaXQgaXMgYWN0dWFsbHkKCWFwcGVuZCA8aHlwZXJ2aXNvcj4gPGFyZ3M+IC0tLSA8a2VybmVs
PiA8YXJncz4gLS0tIDxpbml0cmQ+Ck9yIG1vcmUgZ2VuZXJhbGx5ICJbPHRoaW5nPiA8YXJncz4g
LS0tXSsiCgpQZXJoYXBzIHRoaXMgb3VnaHQgdG8ga2V5IG9mZiB0aGUgcHJlc2VuY2Ugb2Yga2Vy
bmVsIG1ib290LmMzMgpzcGVjaWZpY2FsbHk/Cgo+IFNvIGFyZ3Mgd2hlcmUgb2J0YWluZWQgd2hl
biB0aGUga2VybmVsIHdhcyBwYXJzZWQsIGJ1dCB5b3UgY2FuIGFsc28gaGF2ZQo+IAo+IGtlcm5l
bCA8a2VybmVsPgo+IGFwcGVuZCA8YXJncz4KClRoaXMgaXMgYWN0dWFsbHkgdGhlICJub3JtYWwi
IGV4dGxpbnV4IHN5bnRheC4KCj4gQW5kIDxhcmdzPiBjb250YWluIHRoZSBpbml0cmQgcGF0aCwg
SSByZW1vdmUgdGhlICJpbml0cmQ9WFhYIiBmcm9tIHRoZQo+IGFyZ3MgYW5kIHByb2Nlc3MgdGhl
bSBub3JtYWxseS4KClJpZ2h0LgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 03 12:13:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 12: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 1Ri3Ef-0004Ui-GE; Tue, 03 Jan 2012 12:12: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 1Ri3Ed-0004UD-Fx
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 12:12:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325592769!10320190!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 26217 invoked from network); 3 Jan 2012 12:12:49 -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;
	3 Jan 2012 12:12:49 -0000
Received: by wico1 with SMTP id o1so25906521wic.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 04:12:48 -0800 (PST)
DKIM-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=ZA8vgEmXKRJptyDljgjrcEBWvYrqWvTDJB1crcjY/8M=;
	b=KX7qZyK+uy8d1wbmh6oW+SFW+7cq46nnndEryEeP2/f9CFGbZLu2Nu0plZwEHdv8rQ
	PQShc8bO6Nit7POIiYZJUlUfpwzyLck1w9sxTQVTY9WC8mZ3N3opIyMf9HD2n5HB8BIz
	zKObhXpoZPYbwE/HuKqZ8pV48gn3JMZjT3QNA=
Received: by 10.216.137.231 with SMTP id y81mr28990326wei.31.1325592768710;
	Tue, 03 Jan 2012 04:12:48 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id fi11sm54420496wbb.9.2012.01.03.04.12.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 03 Jan 2012 04:12:46 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6fcc1c479ee68f27233a55ec45a618e0f7cf5d6f
Message-Id: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 03 Jan 2012 13:14:19 +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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1325592706 -3600
# Node ID 6fcc1c479ee68f27233a55ec45a618e0f7cf5d6f
# Parent  3e02aa9670b3265e36bdddbd4760415cd87d047b
pygrub: fix extlinux parsing

pygrub was unable to parse extlinux config files correctly, exactly
the ones like:

LABEL grsec
  KERNEL vmlinuz-3.0.10-grsec
  APPEND initrd=initramfs-3.0.10-grsec
root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
modules=sd-mod,usb-storage,ext4 xen quiet

This patch fixes it, adding a new case when parsing the "append" line,
that searches for the initrd image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3e02aa9670b3 -r 6fcc1c479ee6 tools/pygrub/examples/alpine-linux-2.3.2.extlinux
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/pygrub/examples/alpine-linux-2.3.2.extlinux	Tue Jan 03 13:11:46 2012 +0100
@@ -0,0 +1,11 @@
+DEFAULT menu.c32
+PROMPT 0
+MENU TITLE Alpine/Linux Boot Menu
+MENU HIDDEN
+MENU AUTOBOOT Alpine will be booted automatically in # seconds.
+TIMEOUT 30
+LABEL grsec
+  MENU DEFAULT
+  MENU LABEL Linux 3.0.10-grsec
+  KERNEL vmlinuz-3.0.10-grsec
+  APPEND initrd=initramfs-3.0.10-grsec root=UUID=a97ffe64-430f-4fd3-830e-4736d9a27af0 modules=sd-mod,usb-storage,ext4 quiet
diff -r 3e02aa9670b3 -r 6fcc1c479ee6 tools/pygrub/src/ExtLinuxConf.py
--- a/tools/pygrub/src/ExtLinuxConf.py	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/pygrub/src/ExtLinuxConf.py	Tue Jan 03 13:11:46 2012 +0100
@@ -60,6 +60,13 @@ class ExtLinuxImage(object):
 
                 # Bypass regular self.commands handling
                 com = None
+            elif arg.find("initrd="):
+                # find initrd image in append line
+                args = arg.strip().split(" ")
+                for a in args:
+                    if a.lower().startswith("initrd="):
+                        setattr(self, "initrd", a.replace("initrd=", ""))
+                        arg = arg.replace(a, "")
 
         if com is not None and self.commands.has_key(com):
             if self.commands[com] is not None:
@@ -86,10 +93,12 @@ class ExtLinuxImage(object):
         self._args = args
     def get_kernel(self):
         return self._kernel
+    def set_args(self, val):
+        self._args = val
     def get_args(self):
         return self._args
     kernel = property(get_kernel, set_kernel)
-    args = property(get_args)
+    args = property(get_args, set_args)
 
     def set_initrd(self, val):
         self._initrd = (None,val)

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 12:13:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 12: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 1Ri3Ef-0004Ui-GE; Tue, 03 Jan 2012 12:12: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 1Ri3Ed-0004UD-Fx
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 12:12:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325592769!10320190!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 26217 invoked from network); 3 Jan 2012 12:12:49 -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;
	3 Jan 2012 12:12:49 -0000
Received: by wico1 with SMTP id o1so25906521wic.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 04:12:48 -0800 (PST)
DKIM-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=ZA8vgEmXKRJptyDljgjrcEBWvYrqWvTDJB1crcjY/8M=;
	b=KX7qZyK+uy8d1wbmh6oW+SFW+7cq46nnndEryEeP2/f9CFGbZLu2Nu0plZwEHdv8rQ
	PQShc8bO6Nit7POIiYZJUlUfpwzyLck1w9sxTQVTY9WC8mZ3N3opIyMf9HD2n5HB8BIz
	zKObhXpoZPYbwE/HuKqZ8pV48gn3JMZjT3QNA=
Received: by 10.216.137.231 with SMTP id y81mr28990326wei.31.1325592768710;
	Tue, 03 Jan 2012 04:12:48 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id fi11sm54420496wbb.9.2012.01.03.04.12.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 03 Jan 2012 04:12:46 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6fcc1c479ee68f27233a55ec45a618e0f7cf5d6f
Message-Id: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Tue, 03 Jan 2012 13:14:19 +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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1325592706 -3600
# Node ID 6fcc1c479ee68f27233a55ec45a618e0f7cf5d6f
# Parent  3e02aa9670b3265e36bdddbd4760415cd87d047b
pygrub: fix extlinux parsing

pygrub was unable to parse extlinux config files correctly, exactly
the ones like:

LABEL grsec
  KERNEL vmlinuz-3.0.10-grsec
  APPEND initrd=initramfs-3.0.10-grsec
root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
modules=sd-mod,usb-storage,ext4 xen quiet

This patch fixes it, adding a new case when parsing the "append" line,
that searches for the initrd image.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 3e02aa9670b3 -r 6fcc1c479ee6 tools/pygrub/examples/alpine-linux-2.3.2.extlinux
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/tools/pygrub/examples/alpine-linux-2.3.2.extlinux	Tue Jan 03 13:11:46 2012 +0100
@@ -0,0 +1,11 @@
+DEFAULT menu.c32
+PROMPT 0
+MENU TITLE Alpine/Linux Boot Menu
+MENU HIDDEN
+MENU AUTOBOOT Alpine will be booted automatically in # seconds.
+TIMEOUT 30
+LABEL grsec
+  MENU DEFAULT
+  MENU LABEL Linux 3.0.10-grsec
+  KERNEL vmlinuz-3.0.10-grsec
+  APPEND initrd=initramfs-3.0.10-grsec root=UUID=a97ffe64-430f-4fd3-830e-4736d9a27af0 modules=sd-mod,usb-storage,ext4 quiet
diff -r 3e02aa9670b3 -r 6fcc1c479ee6 tools/pygrub/src/ExtLinuxConf.py
--- a/tools/pygrub/src/ExtLinuxConf.py	Thu Dec 15 18:55:46 2011 +0100
+++ b/tools/pygrub/src/ExtLinuxConf.py	Tue Jan 03 13:11:46 2012 +0100
@@ -60,6 +60,13 @@ class ExtLinuxImage(object):
 
                 # Bypass regular self.commands handling
                 com = None
+            elif arg.find("initrd="):
+                # find initrd image in append line
+                args = arg.strip().split(" ")
+                for a in args:
+                    if a.lower().startswith("initrd="):
+                        setattr(self, "initrd", a.replace("initrd=", ""))
+                        arg = arg.replace(a, "")
 
         if com is not None and self.commands.has_key(com):
             if self.commands[com] is not None:
@@ -86,10 +93,12 @@ class ExtLinuxImage(object):
         self._args = args
     def get_kernel(self):
         return self._kernel
+    def set_args(self, val):
+        self._args = val
     def get_args(self):
         return self._args
     kernel = property(get_kernel, set_kernel)
-    args = property(get_args)
+    args = property(get_args, set_args)
 
     def set_initrd(self, val):
         self._initrd = (None,val)

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 12:16:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 12:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri3Hw-0004gh-B4; Tue, 03 Jan 2012 12:16:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Ri3Hu-0004gI-3s
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 12:16:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325592969!7621780!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=1.5 required=7.0 tests=HOT_NASTY,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11635 invoked from network); 3 Jan 2012 12:16:11 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 12:16:11 -0000
Received: by daec6 with SMTP id c6so61963451dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 04:16: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
	:content-transfer-encoding;
	bh=XUKyCXZFq/Ta0l5oMIftJYN1GTcNbeLz4QdO9EJ52fk=;
	b=LlZpiei0TAulzljP17cBKQyY/tYylr/QqMv6h/vgwjW73nudCSO3kmHbavlWmWFpSw
	ai8AhNXBjR8CNZfU9F2xbuqbX916FKYn3hUGshBEl+DA1JLuNfhjU4BNmnZKaRUxxnR1
	Nx8eidV4uJS7pU2TJPOtdHW6bTSEZ1EvkFjCY=
MIME-Version: 1.0
Received: by 10.68.75.233 with SMTP id f9mr132058840pbw.10.1325592969532; Tue,
	03 Jan 2012 04:16:09 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 04:16:09 -0800 (PST)
In-Reply-To: <1325592626.25206.94.camel@zakaz.uk.xensource.com>
References: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
	<1325587099.25206.41.camel@zakaz.uk.xensource.com>
	<CAPLaKK4ewUjrr=ZcsgJJ6xr74FG8qHR8+aQ9NM34Z5gYcesktA@mail.gmail.com>
	<1325592626.25206.94.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Jan 2012 13:16:09 +0100
X-Google-Sender-Auth: KcFTuLbC_87uFmPGYjgai-yz1MA
Message-ID: <CAPLaKK4TwVk6H6XjBz0Mb4r82_V0S8JdxJW56JyW6393NuoyDw@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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gVHVl
LCAyMDEyLTAxLTAzIGF0IDExOjU2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiAy
MDEyLzEvMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPj4gPiBPbiBN
b24sIDIwMTItMDEtMDIgYXQgMTA6NDkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
Pj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9n
ZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+ID4+ICMgRGF0ZSAxMzI1NTAxMTUxIC0zNjAwCj4+ID4+
ICMgTm9kZSBJRCBiZDU5YTA3ZWQ0MTE4N2JjYWZjNGRkNTIxNGYwNzQ0YzY2ZWYyMDY5Cj4+ID4+
ICMgUGFyZW50IMKgM2UwMmFhOTY3MGIzMjY1ZTM2YmRkZGJkNDc2MDQxNWNkODdkMDQ3Ygo+PiA+
PiBweWdydWI6IGZpeCBleHRsaW51eCBwYXJzaW5nCj4+ID4+Cj4+ID4+IHB5Z3J1YiB3YXMgdW5h
YmxlIHRvIHBhcnNlIGV4dGxpbnV4IGNvbmZpZyBmaWxlcyBjb3JyZWN0bHksIGV4YWN0bHkKPj4g
Pj4gdGhlIG9uZXMgbGlrZToKPj4gPj4KPj4gPj4gTEFCRUwgZ3JzZWMKPj4gPj4gwqAgS0VSTkVM
IHZtbGludXotMy4wLjEwLWdyc2VjCj4+ID4+IMKgIEFQUEVORCBpbml0cmQ9aW5pdHJhbWZzLTMu
MC4xMC1ncnNlYwo+PiA+PiByb290PVVVSUQ9Y2ZkNGE3YjQtOGM0MC00MDI1LWI4NzctODIwNWYx
YzYyMmVlCj4+ID4+IG1vZHVsZXM9c2QtbW9kLHVzYi1zdG9yYWdlLGV4dDQgeGVuIHF1aWV0Cj4+
ID4+Cj4+ID4+IFRoaXMgcGF0Y2ggZml4ZXMgaXQsIGFkZGluZyBhIG5ldyBjYXNlIHdoZW4gcGFy
c2luZyB0aGUgImFwcGVuZCIgbGluZSwKPj4gPj4gdGhhdCBzZWFyY2hlcyBmb3IgdGhlIGluaXRy
ZCBpbWFnZS4KPj4gPj4KPj4gPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dl
ci5wYXVAZW50ZWwudXBjLmVkdT4KPj4gPgo+PiA+IFBsZWFzZSBjb3VsZCB5b3UgYWxzbyBzdXBw
bHkgYW4gZXhhbXBsZSBmaWxlIGZvciB5b3VyIHBsYXRmb3JtIGFzIGEKPj4gPiBwYXRjaCB0byB0
b29scy9weWdydWIvZXhhbXBsZXMuCj4+Cj4+IERvbmUuCj4+Cj4+ID4+IGRpZmYgLXIgM2UwMmFh
OTY3MGIzIC1yIGJkNTlhMDdlZDQxMSB0b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weQo+
PiA+PiAtLS0gYS90b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weSDCoCDCoCDCoCDCoFRo
dSBEZWMgMTUgMTg6NTU6NDYgMjAxMSArMDEwMAo+PiA+PiArKysgYi90b29scy9weWdydWIvc3Jj
L0V4dExpbnV4Q29uZi5weSDCoCDCoCDCoCDCoE1vbiBKYW4gMDIgMTE6NDU6NTEgMjAxMiArMDEw
MAo+PiA+PiBAQCAtNjAsNiArNjAsMTMgQEAgY2xhc3MgRXh0TGludXhJbWFnZShvYmplY3QpOgo+
PiA+Pgo+PiA+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCMgQnlwYXNzIHJlZ3VsYXIgc2Vs
Zi5jb21tYW5kcyBoYW5kbGluZwo+PiA+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbSA9
IE5vbmUKPj4gPj4gKyDCoCDCoCDCoCDCoCDCoCDCoGVsaWYgYXJnLmZpbmQoIiAiKToKPj4gPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCMgZmluZCBpbml0cmQgaW1hZ2UgaW4gYXBwZW5kIGxp
bmUKPj4gPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFyZ3MgPSBhcmcuc3RyaXAoKS5zcGxp
dCgiICIpCj4+ID4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmb3IgYSBpbiBhcmdzOgo+PiA+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYgYS5sb3dlcigpLnN0YXJ0c3dpdGgo
ImluaXRyZCIpOgo+PiA+Cj4+ID4gU2hvdWxkIGNoZWNrIGZvciAiaW5pdHJkPSIgaGVyZT8KPj4K
Pj4gWWVzCj4+Cj4+ID4gT3IgcGVyaGFwczoKPj4gPiDCoCDCoCDCoCDCoCogY2hlY2sgZm9yICI9
Igo+PiA+IMKgIMKgIMKgIMKgKiBzcGxpdCBpbnRvICJrID0gdiIKPj4gPiDCoCDCoCDCoCDCoCog
Y2hlY2sgdGhhdCBrIGlzIHByZWNpc2VseSAiaW5pdHJkIgo+PiA+IHRoZSBmaXJzdCB0d28gYXJl
IHByb2JhYmx5IGRvYWJsZSBpbiB0aGUgc2FtZSBzdHIuc3BsaXQgaW52b2NhdGlvbiBpZgo+PiA+
IHlvdSBoYW5kbGUgdGhlIGV4Y2VwdGlvbiBjb3JyZWN0bHkuCj4+Cj4+IEknbSBub3QgcmVhbGx5
IHN1cmUgYWJvdXQgc3BsaXR0aW5nICc9Jywgc29tZSBhcmdzLCBsaWtlIHJvb3QsIGFyZQo+PiBy
b290PVVVSUQ9WFhYWCwgd2hpY2ggbWlnaHQgYmUgZGlmZmljdWx0IHRvIHBhcnNlIGluIGEgc2lu
Z2xlIHNwbGl0Cj4+IChhdCBsZWFzdCBmb3IgbWUpLiBXaWxsIGxvb2sgYXQgaXQgbGF0ZXIgYW5k
IHBvc3QgYW4gdXBkYXRlZCBwYXRjaC4KPgo+IEkgdGhpbmsgeW91IG5lZWQgdG8gYWx3YXlzIHNw
bGl0IG9uIHRoZSBmaXJzdCA9LgoKSSB3YXMgbm90IHJlYWxseSBzdXJlIGlmIGFyZ3MgY291bGQg
YmUgbGlrZSAicm9vdD1YWFggaW5pdHJkPVhYWCIgb3IKaWYgaW5pdHJkIHNob3VsZCBiZSB0aGUg
Zmlyc3Qgb25lLiBBbnl3YXksIEkndmUgc2VudCBhbiB1cGRhdGVkCnZlcnNpb24gdGhhdCBJIHRo
aW5rIGlzIHNhZmVyLgoKPj4KPj4gPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoHNldGF0dHIoc2VsZiwgImluaXRyZCIsIGEucmVwbGFjZSgiaW5pdHJkPSIsICIiKSkKPj4g
Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFyZyA9IGFyZy5yZXBsYWNl
KGEsICIiKQo+PiA+Pgo+PiA+PiDCoCDCoCDCoCDCoCDCoGlmIGNvbSBpcyBub3QgTm9uZSBhbmQg
c2VsZi5jb21tYW5kcy5oYXNfa2V5KGNvbSk6Cj4+ID4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYg
c2VsZi5jb21tYW5kc1tjb21dIGlzIG5vdCBOb25lOgo+PiA+PiBAQCAtODYsMTAgKzkzLDEyIEBA
IGNsYXNzIEV4dExpbnV4SW1hZ2Uob2JqZWN0KToKPj4gPj4gwqAgwqAgwqAgwqAgwqBzZWxmLl9h
cmdzID0gYXJncwo+PiA+PiDCoCDCoCDCoGRlZiBnZXRfa2VybmVsKHNlbGYpOgo+PiA+PiDCoCDC
oCDCoCDCoCDCoHJldHVybiBzZWxmLl9rZXJuZWwKPj4gPj4gKyDCoCDCoGRlZiBzZXRfYXJncyhz
ZWxmLCB2YWwpOgo+PiA+PiArIMKgIMKgIMKgIMKgc2VsZi5fYXJncyA9IHZhbAo+PiA+PiDCoCDC
oCDCoGRlZiBnZXRfYXJncyhzZWxmKToKPj4gPj4gwqAgwqAgwqAgwqAgwqByZXR1cm4gc2VsZi5f
YXJncwo+PiA+PiDCoCDCoCDCoGtlcm5lbCA9IHByb3BlcnR5KGdldF9rZXJuZWwsIHNldF9rZXJu
ZWwpCj4+ID4+IC0gwqAgwqBhcmdzID0gcHJvcGVydHkoZ2V0X2FyZ3MpCj4+ID4+ICsgwqAgwqBh
cmdzID0gcHJvcGVydHkoZ2V0X2FyZ3MsIHNldF9hcmdzKQo+PiA+Cj4+ID4gQXJlIHRoZXNlIHNv
bWV0aGluZyByZXF1aXJlZCBieSBhcmcucmVwbGFjZT8KPj4KPj4gYXJncyB3YXMgc2V0IHdoZW4g
c2V0dGluZyBrZXJuZWwgaW4gcHJldmlvdXMgdmVyc2lvbiwgYmVjYXVzZSBpdAo+PiBhc3N1bWVk
IHRoZSBsaW5lIHdhczoKPj4KPj4gYXBwZW5kIDxrZXJuZWw+IDxhcmdzPiAtLS0gPGluaXRyZD4K
Pgo+IEFoLCByaWdodC4gVGhpcyBpcyB0aGUgbWJvb3QuYzMyIHN5bnRheCAoaS5lLiBpdCBpcyBh
bHdheXMgYXNzb2NpYXRlZAo+IHdpdGggImtlcm5lbCBtYm9vdC5jMzIiKS4gSUlSQyBpdCBpcyBh
Y3R1YWxseQo+IMKgIMKgIMKgIMKgYXBwZW5kIDxoeXBlcnZpc29yPiA8YXJncz4gLS0tIDxrZXJu
ZWw+IDxhcmdzPiAtLS0gPGluaXRyZD4KPiBPciBtb3JlIGdlbmVyYWxseSAiWzx0aGluZz4gPGFy
Z3M+IC0tLV0rIgo+Cj4gUGVyaGFwcyB0aGlzIG91Z2h0IHRvIGtleSBvZmYgdGhlIHByZXNlbmNl
IG9mIGtlcm5lbCBtYm9vdC5jMzIKPiBzcGVjaWZpY2FsbHk/CgpJdCBpcyBoYW5kbGVkIGluIGEg
cHJldmlvdXMgImlmIi4KCj4+IFNvIGFyZ3Mgd2hlcmUgb2J0YWluZWQgd2hlbiB0aGUga2VybmVs
IHdhcyBwYXJzZWQsIGJ1dCB5b3UgY2FuIGFsc28gaGF2ZQo+Pgo+PiBrZXJuZWwgPGtlcm5lbD4K
Pj4gYXBwZW5kIDxhcmdzPgo+Cj4gVGhpcyBpcyBhY3R1YWxseSB0aGUgIm5vcm1hbCIgZXh0bGlu
dXggc3ludGF4Lgo+Cj4+IEFuZCA8YXJncz4gY29udGFpbiB0aGUgaW5pdHJkIHBhdGgsIEkgcmVt
b3ZlIHRoZSAiaW5pdHJkPVhYWCIgZnJvbSB0aGUKPj4gYXJncyBhbmQgcHJvY2VzcyB0aGVtIG5v
cm1hbGx5Lgo+Cj4gUmlnaHQuCj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 03 12:16:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 12:16:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri3Hw-0004gh-B4; Tue, 03 Jan 2012 12:16:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Ri3Hu-0004gI-3s
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 12:16:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325592969!7621780!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=1.5 required=7.0 tests=HOT_NASTY,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11635 invoked from network); 3 Jan 2012 12:16:11 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 12:16:11 -0000
Received: by daec6 with SMTP id c6so61963451dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 04:16: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
	:content-transfer-encoding;
	bh=XUKyCXZFq/Ta0l5oMIftJYN1GTcNbeLz4QdO9EJ52fk=;
	b=LlZpiei0TAulzljP17cBKQyY/tYylr/QqMv6h/vgwjW73nudCSO3kmHbavlWmWFpSw
	ai8AhNXBjR8CNZfU9F2xbuqbX916FKYn3hUGshBEl+DA1JLuNfhjU4BNmnZKaRUxxnR1
	Nx8eidV4uJS7pU2TJPOtdHW6bTSEZ1EvkFjCY=
MIME-Version: 1.0
Received: by 10.68.75.233 with SMTP id f9mr132058840pbw.10.1325592969532; Tue,
	03 Jan 2012 04:16:09 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 04:16:09 -0800 (PST)
In-Reply-To: <1325592626.25206.94.camel@zakaz.uk.xensource.com>
References: <bd59a07ed41187bcafc4.1325501359@loki.upc.es>
	<1325587099.25206.41.camel@zakaz.uk.xensource.com>
	<CAPLaKK4ewUjrr=ZcsgJJ6xr74FG8qHR8+aQ9NM34Z5gYcesktA@mail.gmail.com>
	<1325592626.25206.94.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Jan 2012 13:16:09 +0100
X-Google-Sender-Auth: KcFTuLbC_87uFmPGYjgai-yz1MA
Message-ID: <CAPLaKK4TwVk6H6XjBz0Mb4r82_V0S8JdxJW56JyW6393NuoyDw@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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gVHVl
LCAyMDEyLTAxLTAzIGF0IDExOjU2ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiAy
MDEyLzEvMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPj4gPiBPbiBN
b24sIDIwMTItMDEtMDIgYXQgMTA6NDkgKzAwMDAsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
Pj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9n
ZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+ID4+ICMgRGF0ZSAxMzI1NTAxMTUxIC0zNjAwCj4+ID4+
ICMgTm9kZSBJRCBiZDU5YTA3ZWQ0MTE4N2JjYWZjNGRkNTIxNGYwNzQ0YzY2ZWYyMDY5Cj4+ID4+
ICMgUGFyZW50IMKgM2UwMmFhOTY3MGIzMjY1ZTM2YmRkZGJkNDc2MDQxNWNkODdkMDQ3Ygo+PiA+
PiBweWdydWI6IGZpeCBleHRsaW51eCBwYXJzaW5nCj4+ID4+Cj4+ID4+IHB5Z3J1YiB3YXMgdW5h
YmxlIHRvIHBhcnNlIGV4dGxpbnV4IGNvbmZpZyBmaWxlcyBjb3JyZWN0bHksIGV4YWN0bHkKPj4g
Pj4gdGhlIG9uZXMgbGlrZToKPj4gPj4KPj4gPj4gTEFCRUwgZ3JzZWMKPj4gPj4gwqAgS0VSTkVM
IHZtbGludXotMy4wLjEwLWdyc2VjCj4+ID4+IMKgIEFQUEVORCBpbml0cmQ9aW5pdHJhbWZzLTMu
MC4xMC1ncnNlYwo+PiA+PiByb290PVVVSUQ9Y2ZkNGE3YjQtOGM0MC00MDI1LWI4NzctODIwNWYx
YzYyMmVlCj4+ID4+IG1vZHVsZXM9c2QtbW9kLHVzYi1zdG9yYWdlLGV4dDQgeGVuIHF1aWV0Cj4+
ID4+Cj4+ID4+IFRoaXMgcGF0Y2ggZml4ZXMgaXQsIGFkZGluZyBhIG5ldyBjYXNlIHdoZW4gcGFy
c2luZyB0aGUgImFwcGVuZCIgbGluZSwKPj4gPj4gdGhhdCBzZWFyY2hlcyBmb3IgdGhlIGluaXRy
ZCBpbWFnZS4KPj4gPj4KPj4gPj4gU2lnbmVkLW9mZi1ieTogUm9nZXIgUGF1IE1vbm5lIDxyb2dl
ci5wYXVAZW50ZWwudXBjLmVkdT4KPj4gPgo+PiA+IFBsZWFzZSBjb3VsZCB5b3UgYWxzbyBzdXBw
bHkgYW4gZXhhbXBsZSBmaWxlIGZvciB5b3VyIHBsYXRmb3JtIGFzIGEKPj4gPiBwYXRjaCB0byB0
b29scy9weWdydWIvZXhhbXBsZXMuCj4+Cj4+IERvbmUuCj4+Cj4+ID4+IGRpZmYgLXIgM2UwMmFh
OTY3MGIzIC1yIGJkNTlhMDdlZDQxMSB0b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weQo+
PiA+PiAtLS0gYS90b29scy9weWdydWIvc3JjL0V4dExpbnV4Q29uZi5weSDCoCDCoCDCoCDCoFRo
dSBEZWMgMTUgMTg6NTU6NDYgMjAxMSArMDEwMAo+PiA+PiArKysgYi90b29scy9weWdydWIvc3Jj
L0V4dExpbnV4Q29uZi5weSDCoCDCoCDCoCDCoE1vbiBKYW4gMDIgMTE6NDU6NTEgMjAxMiArMDEw
MAo+PiA+PiBAQCAtNjAsNiArNjAsMTMgQEAgY2xhc3MgRXh0TGludXhJbWFnZShvYmplY3QpOgo+
PiA+Pgo+PiA+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCMgQnlwYXNzIHJlZ3VsYXIgc2Vs
Zi5jb21tYW5kcyBoYW5kbGluZwo+PiA+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGNvbSA9
IE5vbmUKPj4gPj4gKyDCoCDCoCDCoCDCoCDCoCDCoGVsaWYgYXJnLmZpbmQoIiAiKToKPj4gPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCMgZmluZCBpbml0cmQgaW1hZ2UgaW4gYXBwZW5kIGxp
bmUKPj4gPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFyZ3MgPSBhcmcuc3RyaXAoKS5zcGxp
dCgiICIpCj4+ID4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBmb3IgYSBpbiBhcmdzOgo+PiA+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYgYS5sb3dlcigpLnN0YXJ0c3dpdGgo
ImluaXRyZCIpOgo+PiA+Cj4+ID4gU2hvdWxkIGNoZWNrIGZvciAiaW5pdHJkPSIgaGVyZT8KPj4K
Pj4gWWVzCj4+Cj4+ID4gT3IgcGVyaGFwczoKPj4gPiDCoCDCoCDCoCDCoCogY2hlY2sgZm9yICI9
Igo+PiA+IMKgIMKgIMKgIMKgKiBzcGxpdCBpbnRvICJrID0gdiIKPj4gPiDCoCDCoCDCoCDCoCog
Y2hlY2sgdGhhdCBrIGlzIHByZWNpc2VseSAiaW5pdHJkIgo+PiA+IHRoZSBmaXJzdCB0d28gYXJl
IHByb2JhYmx5IGRvYWJsZSBpbiB0aGUgc2FtZSBzdHIuc3BsaXQgaW52b2NhdGlvbiBpZgo+PiA+
IHlvdSBoYW5kbGUgdGhlIGV4Y2VwdGlvbiBjb3JyZWN0bHkuCj4+Cj4+IEknbSBub3QgcmVhbGx5
IHN1cmUgYWJvdXQgc3BsaXR0aW5nICc9Jywgc29tZSBhcmdzLCBsaWtlIHJvb3QsIGFyZQo+PiBy
b290PVVVSUQ9WFhYWCwgd2hpY2ggbWlnaHQgYmUgZGlmZmljdWx0IHRvIHBhcnNlIGluIGEgc2lu
Z2xlIHNwbGl0Cj4+IChhdCBsZWFzdCBmb3IgbWUpLiBXaWxsIGxvb2sgYXQgaXQgbGF0ZXIgYW5k
IHBvc3QgYW4gdXBkYXRlZCBwYXRjaC4KPgo+IEkgdGhpbmsgeW91IG5lZWQgdG8gYWx3YXlzIHNw
bGl0IG9uIHRoZSBmaXJzdCA9LgoKSSB3YXMgbm90IHJlYWxseSBzdXJlIGlmIGFyZ3MgY291bGQg
YmUgbGlrZSAicm9vdD1YWFggaW5pdHJkPVhYWCIgb3IKaWYgaW5pdHJkIHNob3VsZCBiZSB0aGUg
Zmlyc3Qgb25lLiBBbnl3YXksIEkndmUgc2VudCBhbiB1cGRhdGVkCnZlcnNpb24gdGhhdCBJIHRo
aW5rIGlzIHNhZmVyLgoKPj4KPj4gPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoHNldGF0dHIoc2VsZiwgImluaXRyZCIsIGEucmVwbGFjZSgiaW5pdHJkPSIsICIiKSkKPj4g
Pj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGFyZyA9IGFyZy5yZXBsYWNl
KGEsICIiKQo+PiA+Pgo+PiA+PiDCoCDCoCDCoCDCoCDCoGlmIGNvbSBpcyBub3QgTm9uZSBhbmQg
c2VsZi5jb21tYW5kcy5oYXNfa2V5KGNvbSk6Cj4+ID4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgaWYg
c2VsZi5jb21tYW5kc1tjb21dIGlzIG5vdCBOb25lOgo+PiA+PiBAQCAtODYsMTAgKzkzLDEyIEBA
IGNsYXNzIEV4dExpbnV4SW1hZ2Uob2JqZWN0KToKPj4gPj4gwqAgwqAgwqAgwqAgwqBzZWxmLl9h
cmdzID0gYXJncwo+PiA+PiDCoCDCoCDCoGRlZiBnZXRfa2VybmVsKHNlbGYpOgo+PiA+PiDCoCDC
oCDCoCDCoCDCoHJldHVybiBzZWxmLl9rZXJuZWwKPj4gPj4gKyDCoCDCoGRlZiBzZXRfYXJncyhz
ZWxmLCB2YWwpOgo+PiA+PiArIMKgIMKgIMKgIMKgc2VsZi5fYXJncyA9IHZhbAo+PiA+PiDCoCDC
oCDCoGRlZiBnZXRfYXJncyhzZWxmKToKPj4gPj4gwqAgwqAgwqAgwqAgwqByZXR1cm4gc2VsZi5f
YXJncwo+PiA+PiDCoCDCoCDCoGtlcm5lbCA9IHByb3BlcnR5KGdldF9rZXJuZWwsIHNldF9rZXJu
ZWwpCj4+ID4+IC0gwqAgwqBhcmdzID0gcHJvcGVydHkoZ2V0X2FyZ3MpCj4+ID4+ICsgwqAgwqBh
cmdzID0gcHJvcGVydHkoZ2V0X2FyZ3MsIHNldF9hcmdzKQo+PiA+Cj4+ID4gQXJlIHRoZXNlIHNv
bWV0aGluZyByZXF1aXJlZCBieSBhcmcucmVwbGFjZT8KPj4KPj4gYXJncyB3YXMgc2V0IHdoZW4g
c2V0dGluZyBrZXJuZWwgaW4gcHJldmlvdXMgdmVyc2lvbiwgYmVjYXVzZSBpdAo+PiBhc3N1bWVk
IHRoZSBsaW5lIHdhczoKPj4KPj4gYXBwZW5kIDxrZXJuZWw+IDxhcmdzPiAtLS0gPGluaXRyZD4K
Pgo+IEFoLCByaWdodC4gVGhpcyBpcyB0aGUgbWJvb3QuYzMyIHN5bnRheCAoaS5lLiBpdCBpcyBh
bHdheXMgYXNzb2NpYXRlZAo+IHdpdGggImtlcm5lbCBtYm9vdC5jMzIiKS4gSUlSQyBpdCBpcyBh
Y3R1YWxseQo+IMKgIMKgIMKgIMKgYXBwZW5kIDxoeXBlcnZpc29yPiA8YXJncz4gLS0tIDxrZXJu
ZWw+IDxhcmdzPiAtLS0gPGluaXRyZD4KPiBPciBtb3JlIGdlbmVyYWxseSAiWzx0aGluZz4gPGFy
Z3M+IC0tLV0rIgo+Cj4gUGVyaGFwcyB0aGlzIG91Z2h0IHRvIGtleSBvZmYgdGhlIHByZXNlbmNl
IG9mIGtlcm5lbCBtYm9vdC5jMzIKPiBzcGVjaWZpY2FsbHk/CgpJdCBpcyBoYW5kbGVkIGluIGEg
cHJldmlvdXMgImlmIi4KCj4+IFNvIGFyZ3Mgd2hlcmUgb2J0YWluZWQgd2hlbiB0aGUga2VybmVs
IHdhcyBwYXJzZWQsIGJ1dCB5b3UgY2FuIGFsc28gaGF2ZQo+Pgo+PiBrZXJuZWwgPGtlcm5lbD4K
Pj4gYXBwZW5kIDxhcmdzPgo+Cj4gVGhpcyBpcyBhY3R1YWxseSB0aGUgIm5vcm1hbCIgZXh0bGlu
dXggc3ludGF4Lgo+Cj4+IEFuZCA8YXJncz4gY29udGFpbiB0aGUgaW5pdHJkIHBhdGgsIEkgcmVt
b3ZlIHRoZSAiaW5pdHJkPVhYWCIgZnJvbSB0aGUKPj4gYXJncyBhbmQgcHJvY2VzcyB0aGVtIG5v
cm1hbGx5Lgo+Cj4gUmlnaHQuCj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 03 14:26:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 14: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 1Ri5J8-0005R7-Cx; Tue, 03 Jan 2012 14:25:42 +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 1Ri5J6-0005R2-41
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 14:25:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325600689!50732422!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=1.8 required=7.0 tests=DATE_IN_PAST_96_XX,
	UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20238 invoked from network); 3 Jan 2012 14:24:50 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 14:24:50 -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
	q03EPVTl016586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Tue, 3 Jan 2012 14:25:32 GMT
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
	q03EPRXt019136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 14:25:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03EPQtE003021
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 14:25:27 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
	q03EPQ4h003018; Tue, 3 Jan 2012 08:25:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 06:25:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9D86B40315; Thu, 29 Dec 2011 12:32:08 -0500 (EST)
Date: Thu, 29 Dec 2011 12:32:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhou, Chao" <chao.zhou@intel.com>
Message-ID: <20111229173208.GA18032@phenom.dumpdata.com>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F030FD8.0063,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Thu, Dec 29, 2011 at 08:42:17AM +0000, Zhou, Chao wrote:
> 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

When are you guys planning to switch to the upstream kernel?
> =================================================================
> 
> 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

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 14:26:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 14: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 1Ri5J8-0005R7-Cx; Tue, 03 Jan 2012 14:25:42 +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 1Ri5J6-0005R2-41
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 14:25:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325600689!50732422!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=1.8 required=7.0 tests=DATE_IN_PAST_96_XX,
	UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20238 invoked from network); 3 Jan 2012 14:24:50 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 14:24:50 -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
	q03EPVTl016586
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Tue, 3 Jan 2012 14:25:32 GMT
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
	q03EPRXt019136
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 14:25:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03EPQtE003021
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 14:25:27 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
	q03EPQ4h003018; Tue, 3 Jan 2012 08:25:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 06:25:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9D86B40315; Thu, 29 Dec 2011 12:32:08 -0500 (EST)
Date: Thu, 29 Dec 2011 12:32:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhou, Chao" <chao.zhou@intel.com>
Message-ID: <20111229173208.GA18032@phenom.dumpdata.com>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F030FD8.0063,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Thu, Dec 29, 2011 at 08:42:17AM +0000, Zhou, Chao wrote:
> 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

When are you guys planning to switch to the upstream kernel?
> =================================================================
> 
> 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

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 15:05:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 15:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri5ur-0005mS-IV; Tue, 03 Jan 2012 15:04:41 +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 1Ri5uq-0005mN-Ey
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 15:04:40 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325603071!8216673!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 9259 invoked from network); 3 Jan 2012 15:04:33 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 15:04:33 -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
	q03F4US9030132
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 10:04:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03F4Utm030130;
	Tue, 3 Jan 2012 10:04:30 -0500
Date: Tue, 3 Jan 2012 11:04:30 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony Wright <anthony@overnetdata.com>
Message-ID: <20120103150430.GA27383@andromeda.dapyr.net>
References: <4EE0A6C7.9080603@overnetdata.com>
	<20111214213819.GD25896@andromeda.dapyr.net>
	<4EEA1818.6060106@overnetdata.com>
	<20111215211218.GA15407@andromeda.dapyr.net>
	<4EEF5923.1050307@overnetdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF5923.1050307@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 Mon, Dec 19, 2011 at 03:32:51PM +0000, Anthony Wright wrote:
> 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.

Are you enabling gfx_passthrough or using the VNC _and_ the PCI
passthrough features (which is what I was using this last week).

Something like this:

builder='hvm'
memory = 2048
name = "Windows7"
vcpus=3
disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
#stdvga=0
serial='pty'
tsc_mode=0
usb=1
usb_add="host:045e:0040"
usbdevice='tablet'
xen_platform_pci=1
# Remember QEMU_AUDIO_DRV=pa
soundhw='es1370'
pci=['01:00.0','01:00.1','02:00.0']


Where the PCI card is:
01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
01:00.1 Audio device: ATI Technologies Inc HD48x0 audio

Or are you passing in an Nvidia card?

(The motherboard I am using is an AMD one).
> 
> 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

If it was I would think you would get tons of warnings from the Xen
hypervisor about failed mappings and such. [edit: and it seems you are
getting faults]

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

You mean these:

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

Hm, and 0000:00:02.0 is your VGA card right?

These ones you can ignore:
> (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

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 15:05:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 15:05:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri5ur-0005mS-IV; Tue, 03 Jan 2012 15:04:41 +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 1Ri5uq-0005mN-Ey
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 15:04:40 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325603071!8216673!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 9259 invoked from network); 3 Jan 2012 15:04:33 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 15:04:33 -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
	q03F4US9030132
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 10:04:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03F4Utm030130;
	Tue, 3 Jan 2012 10:04:30 -0500
Date: Tue, 3 Jan 2012 11:04:30 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Anthony Wright <anthony@overnetdata.com>
Message-ID: <20120103150430.GA27383@andromeda.dapyr.net>
References: <4EE0A6C7.9080603@overnetdata.com>
	<20111214213819.GD25896@andromeda.dapyr.net>
	<4EEA1818.6060106@overnetdata.com>
	<20111215211218.GA15407@andromeda.dapyr.net>
	<4EEF5923.1050307@overnetdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EEF5923.1050307@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 Mon, Dec 19, 2011 at 03:32:51PM +0000, Anthony Wright wrote:
> 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.

Are you enabling gfx_passthrough or using the VNC _and_ the PCI
passthrough features (which is what I was using this last week).

Something like this:

builder='hvm'
memory = 2048
name = "Windows7"
vcpus=3
disk = [ 'phy:/dev/vg_guest/Win7_Home,hda,w']
vnc=1
videoram=8
vnclisten="0.0.0.0"
vncpasswd=''
#stdvga=0
serial='pty'
tsc_mode=0
usb=1
usb_add="host:045e:0040"
usbdevice='tablet'
xen_platform_pci=1
# Remember QEMU_AUDIO_DRV=pa
soundhw='es1370'
pci=['01:00.0','01:00.1','02:00.0']


Where the PCI card is:
01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
01:00.1 Audio device: ATI Technologies Inc HD48x0 audio

Or are you passing in an Nvidia card?

(The motherboard I am using is an AMD one).
> 
> 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

If it was I would think you would get tons of warnings from the Xen
hypervisor about failed mappings and such. [edit: and it seems you are
getting faults]

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

You mean these:

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

Hm, and 0000:00:02.0 is your VGA card right?

These ones you can ignore:
> (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

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 15:10:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 15:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri5zc-0005w6-Em; Tue, 03 Jan 2012 15:09:36 +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 1Ri5za-0005vv-FV
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 15:09:34 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325603367!1669695!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 29721 invoked from network); 3 Jan 2012 15:09:28 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 15:09: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
	q03F9LuE030311
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 10:09:21 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03F9L1A030309;
	Tue, 3 Jan 2012 10:09:21 -0500
Date: Tue, 3 Jan 2012 11:09:21 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roger Pau Monn?? <roger.pau@entel.upc.edu>
Message-ID: <20120103150921.GB27383@andromeda.dapyr.net>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [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

On Sat, Dec 24, 2011 at 12:08:39PM +0100, Roger Pau Monn?? wrote:
> 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

What happens if you do the same thing (so LiveCD, squashfs) but remove
the Xen hypervisor? Do you get a similar bug?

Does this happen on real hardware or just under VMware?
>  * 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

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 15:10:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 15:10:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri5zc-0005w6-Em; Tue, 03 Jan 2012 15:09:36 +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 1Ri5za-0005vv-FV
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 15:09:34 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325603367!1669695!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 29721 invoked from network); 3 Jan 2012 15:09:28 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 15:09: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
	q03F9LuE030311
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 10:09:21 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03F9L1A030309;
	Tue, 3 Jan 2012 10:09:21 -0500
Date: Tue, 3 Jan 2012 11:09:21 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roger Pau Monn?? <roger.pau@entel.upc.edu>
Message-ID: <20120103150921.GB27383@andromeda.dapyr.net>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [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

On Sat, Dec 24, 2011 at 12:08:39PM +0100, Roger Pau Monn?? wrote:
> 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

What happens if you do the same thing (so LiveCD, squashfs) but remove
the Xen hypervisor? Do you get a similar bug?

Does this happen on real hardware or just under VMware?
>  * 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

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 15:11:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 15:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri614-00060f-VD; Tue, 03 Jan 2012 15:11: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 1Ri612-000608-QW
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 15:11:05 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325603457!10220432!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 15816 invoked from network); 3 Jan 2012 15:10:58 -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; 3 Jan 2012 15:10: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
	q03FAnfV030384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 10:10:49 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03FAnrv030382;
	Tue, 3 Jan 2012 10:10:49 -0500
Date: Tue, 3 Jan 2012 11:10:48 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roger Pau Monn?? <roger.pau@entel.upc.edu>
Message-ID: <20120103151047.GC27383@andromeda.dapyr.net>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
	<1325583878.25206.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@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>
Subject: Re: [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

On Tue, Jan 03, 2012 at 11:15:19AM +0100, Roger Pau Monn?? wrote:
> 2012/1/3 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Sat, 2011-12-24 at 11:08 +0000, Roger Pau Monn?? wrote:
> >> Hello,
> >>
> >> I'm trying to create a Xen Dom0 LiveCD/usb, based on Alpine Linux,
> >> which has great support for this kind of stuff.
> >
> > Cool!
> 
> We already have most of this working, the necessary features and
> scripts have been added to the build tools, and when the new xen-4.1.2
> package passes testing creating a Xen Dom0 LiveCD/USB/... will be
> trivial. I will drop a line to the list when it is released.
> 
> > Nothing springs to mind. On the face of it this doesn't look all that
> > Xen specific -- if you boot the same Linux kernel without Xen underneath
> > (but otherwise in the same configuration) does it work?
> 
> Without Xen the kernel worked ok, don't really know what failed
> (probably I had some corrupted files on my install) a new fresh
> install didn't show any of this problems, but I completely forgot to

Ah, happy to see this resolved itself.

Is you LiveCD/usb available somewhere publicly? Thanks!

> reply to the thread, sorry for wasting your time.
> 
> 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 Jan 03 15:11:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 15:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri614-00060f-VD; Tue, 03 Jan 2012 15:11: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 1Ri612-000608-QW
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 15:11:05 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325603457!10220432!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 15816 invoked from network); 3 Jan 2012 15:10:58 -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; 3 Jan 2012 15:10: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
	q03FAnfV030384
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 10:10:49 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03FAnrv030382;
	Tue, 3 Jan 2012 10:10:49 -0500
Date: Tue, 3 Jan 2012 11:10:48 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roger Pau Monn?? <roger.pau@entel.upc.edu>
Message-ID: <20120103151047.GC27383@andromeda.dapyr.net>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
	<1325583878.25206.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@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>
Subject: Re: [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

On Tue, Jan 03, 2012 at 11:15:19AM +0100, Roger Pau Monn?? wrote:
> 2012/1/3 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Sat, 2011-12-24 at 11:08 +0000, Roger Pau Monn?? wrote:
> >> Hello,
> >>
> >> I'm trying to create a Xen Dom0 LiveCD/usb, based on Alpine Linux,
> >> which has great support for this kind of stuff.
> >
> > Cool!
> 
> We already have most of this working, the necessary features and
> scripts have been added to the build tools, and when the new xen-4.1.2
> package passes testing creating a Xen Dom0 LiveCD/USB/... will be
> trivial. I will drop a line to the list when it is released.
> 
> > Nothing springs to mind. On the face of it this doesn't look all that
> > Xen specific -- if you boot the same Linux kernel without Xen underneath
> > (but otherwise in the same configuration) does it work?
> 
> Without Xen the kernel worked ok, don't really know what failed
> (probably I had some corrupted files on my install) a new fresh
> install didn't show any of this problems, but I completely forgot to

Ah, happy to see this resolved itself.

Is you LiveCD/usb available somewhere publicly? Thanks!

> reply to the thread, sorry for wasting your time.
> 
> 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 Jan 03 15:23:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 15:23:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri6CX-0006Hp-84; Tue, 03 Jan 2012 15:22:57 +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 1Ri6CW-0006Hk-Do
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 15:22:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1325604169!9383430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11150 invoked from network); 3 Jan 2012 15:22:49 -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;
	3 Jan 2012 15:22:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9794256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 15: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; Tue, 3 Jan 2012
	15:22:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 3 Jan 2012 15:22:48 +0000
In-Reply-To: <20120103151047.GC27383@andromeda.dapyr.net>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
	<1325583878.25206.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@mail.gmail.com>
	<20120103151047.GC27383@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325604168.25206.160.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] 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

On Tue, 2012-01-03 at 15:10 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 03, 2012 at 11:15:19AM +0100, Roger Pau Monn?? wrote:
> > 2012/1/3 Ian Campbell <Ian.Campbell@citrix.com>:
> > > On Sat, 2011-12-24 at 11:08 +0000, Roger Pau Monn?? wrote:
> > >> Hello,
> > >>
> > >> I'm trying to create a Xen Dom0 LiveCD/usb, based on Alpine Linux,
> > >> which has great support for this kind of stuff.
> > >
> > > Cool!
> > 
> > We already have most of this working, the necessary features and
> > scripts have been added to the build tools, and when the new xen-4.1.2
> > package passes testing creating a Xen Dom0 LiveCD/USB/... will be
> > trivial. I will drop a line to the list when it is released.
> > 
> > > Nothing springs to mind. On the face of it this doesn't look all that
> > > Xen specific -- if you boot the same Linux kernel without Xen underneath
> > > (but otherwise in the same configuration) does it work?
> > 
> > Without Xen the kernel worked ok, don't really know what failed
> > (probably I had some corrupted files on my install) a new fresh
> > install didn't show any of this problems, but I completely forgot to
> 
> Ah, happy to see this resolved itself.

Yes, great.

> Is you LiveCD/usb available somewhere publicly? Thanks!

We could probably arrange to host it (both binaries and development
repositories, scripts etc) on xenbits if that would be useful. Even if
this is for some internal use (so you can't share it) we'd really
appreciate it if you could write a HOWTO on the wiki...

How do you use it? Are there some pre-canned guests on the ISO or does
it require an HDD in the machine for guest storage?

Ian.

> 
> > reply to the thread, sorry for wasting your time.
> > 
> > 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 Jan 03 15:23:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 15:23:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri6CX-0006Hp-84; Tue, 03 Jan 2012 15:22:57 +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 1Ri6CW-0006Hk-Do
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 15:22:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1325604169!9383430!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11150 invoked from network); 3 Jan 2012 15:22:49 -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;
	3 Jan 2012 15:22:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9794256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 15: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; Tue, 3 Jan 2012
	15:22:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Tue, 3 Jan 2012 15:22:48 +0000
In-Reply-To: <20120103151047.GC27383@andromeda.dapyr.net>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
	<1325583878.25206.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@mail.gmail.com>
	<20120103151047.GC27383@andromeda.dapyr.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325604168.25206.160.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] 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

On Tue, 2012-01-03 at 15:10 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 03, 2012 at 11:15:19AM +0100, Roger Pau Monn?? wrote:
> > 2012/1/3 Ian Campbell <Ian.Campbell@citrix.com>:
> > > On Sat, 2011-12-24 at 11:08 +0000, Roger Pau Monn?? wrote:
> > >> Hello,
> > >>
> > >> I'm trying to create a Xen Dom0 LiveCD/usb, based on Alpine Linux,
> > >> which has great support for this kind of stuff.
> > >
> > > Cool!
> > 
> > We already have most of this working, the necessary features and
> > scripts have been added to the build tools, and when the new xen-4.1.2
> > package passes testing creating a Xen Dom0 LiveCD/USB/... will be
> > trivial. I will drop a line to the list when it is released.
> > 
> > > Nothing springs to mind. On the face of it this doesn't look all that
> > > Xen specific -- if you boot the same Linux kernel without Xen underneath
> > > (but otherwise in the same configuration) does it work?
> > 
> > Without Xen the kernel worked ok, don't really know what failed
> > (probably I had some corrupted files on my install) a new fresh
> > install didn't show any of this problems, but I completely forgot to
> 
> Ah, happy to see this resolved itself.

Yes, great.

> Is you LiveCD/usb available somewhere publicly? Thanks!

We could probably arrange to host it (both binaries and development
repositories, scripts etc) on xenbits if that would be useful. Even if
this is for some internal use (so you can't share it) we'd really
appreciate it if you could write a HOWTO on the wiki...

How do you use it? Are there some pre-canned guests on the ISO or does
it require an HDD in the machine for guest storage?

Ian.

> 
> > reply to the thread, sorry for wasting your time.
> > 
> > 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 Jan 03 16:02:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16:02:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri6ob-0006yP-FT; Tue, 03 Jan 2012 16:02:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ri6oZ-0006yK-Rj
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:02:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325606515!61006903!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31849 invoked from network); 3 Jan 2012 16:01:55 -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;
	3 Jan 2012 16:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9795102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 16:02: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, 3 Jan 2012 16:02: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
	1Ri6oY-0000AM-5c; Tue, 03 Jan 2012 16:02:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri6oY-0005Lj-0s;
	Tue, 03 Jan 2012 16:02:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.9862.11432.52937@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 16:02:14 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <8ea73cd1a367b318f720.1324639764@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<8ea73cd1a367b318f720.1324639764@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 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 ("[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.

I'm not sure I like this name.  It's confusing because it's not at
first glance clear whether it refers to the host's putative iommu, or
some kind of provision to the guest.

And it needs documentation, which I hope will answer my other question
which is "what is this good for?" :-).

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:02:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16:02:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri6ob-0006yP-FT; Tue, 03 Jan 2012 16:02:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ri6oZ-0006yK-Rj
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:02:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325606515!61006903!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31849 invoked from network); 3 Jan 2012 16:01:55 -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;
	3 Jan 2012 16:01:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9795102"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 16:02: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, 3 Jan 2012 16:02: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
	1Ri6oY-0000AM-5c; Tue, 03 Jan 2012 16:02:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri6oY-0005Lj-0s;
	Tue, 03 Jan 2012 16:02:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.9862.11432.52937@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 16:02:14 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <8ea73cd1a367b318f720.1324639764@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<8ea73cd1a367b318f720.1324639764@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 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 ("[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.

I'm not sure I like this name.  It's confusing because it's not at
first glance clear whether it refers to the host's putative iommu, or
some kind of provision to the guest.

And it needs documentation, which I hope will answer my other question
which is "what is this good for?" :-).

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:04:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16:04:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri6pw-00072p-VO; Tue, 03 Jan 2012 16:03:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ri6pu-00072U-Sp
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:03:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325606612!8224793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8824 invoked from network); 3 Jan 2012 16:03:32 -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;
	3 Jan 2012 16:03:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9795141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 16:03: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, 3 Jan 2012 16:03: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
	1Ri6pn-0000Ar-Hg; Tue, 03 Jan 2012 16:03:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri6pn-0005Lv-Go;
	Tue, 03 Jan 2012 16:03:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.9939.353252.893610@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 16:03:31 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 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

Wei Wang writes ("[PATCH 14 of 16] libxl: bind virtual bdf to physical bdf after device assignment"):
> +            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));

This and many of your other patches to libxl need rewrapping to fit
within 75-80 columns, correct indentation, and correct the coding
style to fit with the rest of the code.

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:04:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16:04:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri6pw-00072p-VO; Tue, 03 Jan 2012 16:03:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ri6pu-00072U-Sp
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:03:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325606612!8224793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8824 invoked from network); 3 Jan 2012 16:03:32 -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;
	3 Jan 2012 16:03:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9795141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 16:03: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, 3 Jan 2012 16:03: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
	1Ri6pn-0000Ar-Hg; Tue, 03 Jan 2012 16:03:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri6pn-0005Lv-Go;
	Tue, 03 Jan 2012 16:03:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.9939.353252.893610@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 16:03:31 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
References: <patchbomb.1324639749@gran.amd.com>
	<7ac92c11a11a4dbdf85e.1324639763@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 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

Wei Wang writes ("[PATCH 14 of 16] libxl: bind virtual bdf to physical bdf after device assignment"):
> +            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, pcidev->vdevfn, pcidev_encode_bdf(pcidev));

This and many of your other patches to libxl need rewrapping to fit
within 75-80 columns, correct indentation, and correct the coding
style to fit with the rest of the code.

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:22:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri77K-0007Ks-Lh; Tue, 03 Jan 2012 16:21:38 +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 1Ri77J-0007Kn-71
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:21:37 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325607638!59380346!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNTQxNDQ=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26946 invoked from network); 3 Jan 2012 16:20:38 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-2.tower-27.messagelabs.com with SMTP;
	3 Jan 2012 16:20:38 -0000
Received: (qmail invoked by alias); 03 Jan 2012 16:21:32 -0000
Received: from dslb-188-097-194-071.pools.arcor-ip.net (EHLO [192.168.222.23])
	[188.97.194.71]
	by mail.gmx.net (mp065) with SMTP; 03 Jan 2012 17:21:32 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX1+6lPYrW2e63Gqq9nWe7gTaZf7uY06GGqOYK/r8EN
	94vgym6lCh+nRZ
Message-ID: <4F032AC1.5090800@gmx.de>
Date: Tue, 03 Jan 2012 17:20:17 +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: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
	<1325585762.25206.25.camel@zakaz.uk.xensource.com>
	<1325587168.24422.68.camel@liuw-desktop>
In-Reply-To: <1325587168.24422.68.camel@liuw-desktop>
X-Enigmail-Version: 1.3.3
X-Y-GMX-Trusted: 0
Subject: Re: [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: multipart/mixed; boundary="===============6217383698099509510=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============6217383698099509510==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080004060005030708020107"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms080004060005030708020107
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

This applies against 4.1.2, but untested, as I still have my Athlon X2
xen boot trouble.

diff --git tools/libxl/libxl.c tools/libxl/libxl.c
index 2b8f8f4..3c086d5 100644
--- tools/libxl/libxl.c
+++ tools/libxl/libxl.c
@@ -1229,6 +1229,12 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t
domid, libxl_device_nic *nic)
     flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
     flexarray_append(back, "script");
     flexarray_append(back, nic->script);
+
+    if (nic->ifname) {
+        flexarray_append(back, "vifname");
+        flexarray_append(back, nic->ifname);
+    }
+
     flexarray_append(back, "mac");
     flexarray_append(back, libxl__sprintf(&gc,
"%02x:%02x:%02x:%02x:%02x:%02x",
                                                  nic->mac[0],
nic->mac[1], nic->mac[2],
diff --git tools/libxl/xl_cmdimpl.c tools/libxl/xl_cmdimpl.c
index 8270f34..8da8b88 100644
--- tools/libxl/xl_cmdimpl.c
+++ tools/libxl/xl_cmdimpl.c
@@ -393,6 +393,8 @@
     for (i =3D 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);

Am 03.01.2012 11:39, schrieb Wei Liu:
> On Tue, 2012-01-03 at 10:16 +0000, Ian Campbell wrote:
>> On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
>>> Simple fix to enable user to specify vif names.
>>
>> Thanks. It is worth noting that the naming of the vif is implemented b=
y
>> the hotplug scripts and not by netback (which always uses vifX.Y).
>>
>=20
> Yes, I knew that after digging into hotplug scripts. :)
>=20
> It seems that we need to backport these patches to earlier versions as
> well.
>=20
>=20
> Wei.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>=20



--------------ms080004060005030708020107
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwMzE2MjAxN1ow
IwYJKoZIhvcNAQkEMRYEFLFsiLsEsTtfiWGSdShp4O12+rw7MF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAk0OENOhfMVUYuu34CDC2DkgN82PnUSS//nATshHlxIiBjdsV
xudVoWUUDhnq4FU10LFIf+zNdeq74GtJ905gqR6qtjKgEvBxM/UxrsnE1HDJEPWE8QIDEoLg
dmNVeykDBXKR8H844kvk6G+2/A4IBPDhnH7Ip/KUSX1Gxm2a/+kFzGzeDXMBXYZ0EU9vN1k7
aOJ1lVaylSMK/PjGj4KRsb/c7rbinCOBYt6/2Vhz8b4emLzLAn1FEXn+vJ47Vf1gpV1cXAIF
XDh0IIjZp3jwrxHSKe92K2EgmNXb8ejwjjQYH6p8Q8ve81H4sQHKbhYFOzYke1SDMR4b9VC4
Noz0dQAAAAAAAA==
--------------ms080004060005030708020107--


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

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

--===============6217383698099509510==--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:22:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16:22:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri77K-0007Ks-Lh; Tue, 03 Jan 2012 16:21:38 +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 1Ri77J-0007Kn-71
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:21:37 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325607638!59380346!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNTQxNDQ=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26946 invoked from network); 3 Jan 2012 16:20:38 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-2.tower-27.messagelabs.com with SMTP;
	3 Jan 2012 16:20:38 -0000
Received: (qmail invoked by alias); 03 Jan 2012 16:21:32 -0000
Received: from dslb-188-097-194-071.pools.arcor-ip.net (EHLO [192.168.222.23])
	[188.97.194.71]
	by mail.gmx.net (mp065) with SMTP; 03 Jan 2012 17:21:32 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX1+6lPYrW2e63Gqq9nWe7gTaZf7uY06GGqOYK/r8EN
	94vgym6lCh+nRZ
Message-ID: <4F032AC1.5090800@gmx.de>
Date: Tue, 03 Jan 2012 17:20:17 +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: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
	<1325585762.25206.25.camel@zakaz.uk.xensource.com>
	<1325587168.24422.68.camel@liuw-desktop>
In-Reply-To: <1325587168.24422.68.camel@liuw-desktop>
X-Enigmail-Version: 1.3.3
X-Y-GMX-Trusted: 0
Subject: Re: [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: multipart/mixed; boundary="===============6217383698099509510=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============6217383698099509510==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080004060005030708020107"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms080004060005030708020107
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

This applies against 4.1.2, but untested, as I still have my Athlon X2
xen boot trouble.

diff --git tools/libxl/libxl.c tools/libxl/libxl.c
index 2b8f8f4..3c086d5 100644
--- tools/libxl/libxl.c
+++ tools/libxl/libxl.c
@@ -1229,6 +1229,12 @@ int libxl_device_nic_add(libxl_ctx *ctx, uint32_t
domid, libxl_device_nic *nic)
     flexarray_append(back, libxl__sprintf(&gc, "%d", 1));
     flexarray_append(back, "script");
     flexarray_append(back, nic->script);
+
+    if (nic->ifname) {
+        flexarray_append(back, "vifname");
+        flexarray_append(back, nic->ifname);
+    }
+
     flexarray_append(back, "mac");
     flexarray_append(back, libxl__sprintf(&gc,
"%02x:%02x:%02x:%02x:%02x:%02x",
                                                  nic->mac[0],
nic->mac[1], nic->mac[2],
diff --git tools/libxl/xl_cmdimpl.c tools/libxl/xl_cmdimpl.c
index 8270f34..8da8b88 100644
--- tools/libxl/xl_cmdimpl.c
+++ tools/libxl/xl_cmdimpl.c
@@ -393,6 +393,8 @@
     for (i =3D 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);

Am 03.01.2012 11:39, schrieb Wei Liu:
> On Tue, 2012-01-03 at 10:16 +0000, Ian Campbell wrote:
>> On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
>>> Simple fix to enable user to specify vif names.
>>
>> Thanks. It is worth noting that the naming of the vif is implemented b=
y
>> the hotplug scripts and not by netback (which always uses vifX.Y).
>>
>=20
> Yes, I knew that after digging into hotplug scripts. :)
>=20
> It seems that we need to backport these patches to earlier versions as
> well.
>=20
>=20
> Wei.
>=20
>=20
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>=20



--------------ms080004060005030708020107
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwMzE2MjAxN1ow
IwYJKoZIhvcNAQkEMRYEFLFsiLsEsTtfiWGSdShp4O12+rw7MF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAk0OENOhfMVUYuu34CDC2DkgN82PnUSS//nATshHlxIiBjdsV
xudVoWUUDhnq4FU10LFIf+zNdeq74GtJ905gqR6qtjKgEvBxM/UxrsnE1HDJEPWE8QIDEoLg
dmNVeykDBXKR8H844kvk6G+2/A4IBPDhnH7Ip/KUSX1Gxm2a/+kFzGzeDXMBXYZ0EU9vN1k7
aOJ1lVaylSMK/PjGj4KRsb/c7rbinCOBYt6/2Vhz8b4emLzLAn1FEXn+vJ47Vf1gpV1cXAIF
XDh0IIjZp3jwrxHSKe92K2EgmNXb8ejwjjQYH6p8Q8ve81H4sQHKbhYFOzYke1SDMR4b9VC4
Noz0dQAAAAAAAA==
--------------ms080004060005030708020107--


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

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

--===============6217383698099509510==--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:32:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16: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 1Ri7Hg-0007YD-PE; Tue, 03 Jan 2012 16:32:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri7Hf-0007Y8-0e
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:32:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325608321!9423638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4021 invoked from network); 3 Jan 2012 16:32:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 16:32:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9796035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 16:32:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	16:32:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 3 Jan 2012 16:32:00 +0000
In-Reply-To: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
References: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325608320.25206.161.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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-03 at 12:14 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1325592706 -3600
> # Node ID 6fcc1c479ee68f27233a55ec45a618e0f7cf5d6f
> # Parent  3e02aa9670b3265e36bdddbd4760415cd87d047b
> pygrub: fix extlinux parsing
> 
> pygrub was unable to parse extlinux config files correctly, exactly
> the ones like:
> 
> LABEL grsec
>   KERNEL vmlinuz-3.0.10-grsec
>   APPEND initrd=initramfs-3.0.10-grsec
> root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
> modules=sd-mod,usb-storage,ext4 xen quiet
> 
> This patch fixes it, adding a new case when parsing the "append" line,
> that searches for the initrd image.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

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

> 
> diff -r 3e02aa9670b3 -r 6fcc1c479ee6 tools/pygrub/examples/alpine-linux-2.3.2.extlinux
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/pygrub/examples/alpine-linux-2.3.2.extlinux	Tue Jan 03 13:11:46 2012 +0100
> @@ -0,0 +1,11 @@
> +DEFAULT menu.c32
> +PROMPT 0
> +MENU TITLE Alpine/Linux Boot Menu
> +MENU HIDDEN
> +MENU AUTOBOOT Alpine will be booted automatically in # seconds.
> +TIMEOUT 30
> +LABEL grsec
> +  MENU DEFAULT
> +  MENU LABEL Linux 3.0.10-grsec
> +  KERNEL vmlinuz-3.0.10-grsec
> +  APPEND initrd=initramfs-3.0.10-grsec root=UUID=a97ffe64-430f-4fd3-830e-4736d9a27af0 modules=sd-mod,usb-storage,ext4 quiet
> diff -r 3e02aa9670b3 -r 6fcc1c479ee6 tools/pygrub/src/ExtLinuxConf.py
> --- a/tools/pygrub/src/ExtLinuxConf.py	Thu Dec 15 18:55:46 2011 +0100
> +++ b/tools/pygrub/src/ExtLinuxConf.py	Tue Jan 03 13:11:46 2012 +0100
> @@ -60,6 +60,13 @@ class ExtLinuxImage(object):
>  
>                  # Bypass regular self.commands handling
>                  com = None
> +            elif arg.find("initrd="):
> +                # find initrd image in append line
> +                args = arg.strip().split(" ")
> +                for a in args:
> +                    if a.lower().startswith("initrd="):
> +                        setattr(self, "initrd", a.replace("initrd=", ""))
> +                        arg = arg.replace(a, "")
>  
>          if com is not None and self.commands.has_key(com):
>              if self.commands[com] is not None:
> @@ -86,10 +93,12 @@ class ExtLinuxImage(object):
>          self._args = args
>      def get_kernel(self):
>          return self._kernel
> +    def set_args(self, val):
> +        self._args = val
>      def get_args(self):
>          return self._args
>      kernel = property(get_kernel, set_kernel)
> -    args = property(get_args)
> +    args = property(get_args, set_args)
>  
>      def set_initrd(self, val):
>          self._initrd = (None,val)



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:32:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16: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 1Ri7Hg-0007YD-PE; Tue, 03 Jan 2012 16:32:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ri7Hf-0007Y8-0e
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:32:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325608321!9423638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4021 invoked from network); 3 Jan 2012 16:32:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 16:32:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9796035"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 16:32:00 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Tue, 3 Jan 2012
	16:32:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Tue, 3 Jan 2012 16:32:00 +0000
In-Reply-To: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
References: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325608320.25206.161.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] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-03 at 12:14 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1325592706 -3600
> # Node ID 6fcc1c479ee68f27233a55ec45a618e0f7cf5d6f
> # Parent  3e02aa9670b3265e36bdddbd4760415cd87d047b
> pygrub: fix extlinux parsing
> 
> pygrub was unable to parse extlinux config files correctly, exactly
> the ones like:
> 
> LABEL grsec
>   KERNEL vmlinuz-3.0.10-grsec
>   APPEND initrd=initramfs-3.0.10-grsec
> root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
> modules=sd-mod,usb-storage,ext4 xen quiet
> 
> This patch fixes it, adding a new case when parsing the "append" line,
> that searches for the initrd image.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

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

> 
> diff -r 3e02aa9670b3 -r 6fcc1c479ee6 tools/pygrub/examples/alpine-linux-2.3.2.extlinux
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/tools/pygrub/examples/alpine-linux-2.3.2.extlinux	Tue Jan 03 13:11:46 2012 +0100
> @@ -0,0 +1,11 @@
> +DEFAULT menu.c32
> +PROMPT 0
> +MENU TITLE Alpine/Linux Boot Menu
> +MENU HIDDEN
> +MENU AUTOBOOT Alpine will be booted automatically in # seconds.
> +TIMEOUT 30
> +LABEL grsec
> +  MENU DEFAULT
> +  MENU LABEL Linux 3.0.10-grsec
> +  KERNEL vmlinuz-3.0.10-grsec
> +  APPEND initrd=initramfs-3.0.10-grsec root=UUID=a97ffe64-430f-4fd3-830e-4736d9a27af0 modules=sd-mod,usb-storage,ext4 quiet
> diff -r 3e02aa9670b3 -r 6fcc1c479ee6 tools/pygrub/src/ExtLinuxConf.py
> --- a/tools/pygrub/src/ExtLinuxConf.py	Thu Dec 15 18:55:46 2011 +0100
> +++ b/tools/pygrub/src/ExtLinuxConf.py	Tue Jan 03 13:11:46 2012 +0100
> @@ -60,6 +60,13 @@ class ExtLinuxImage(object):
>  
>                  # Bypass regular self.commands handling
>                  com = None
> +            elif arg.find("initrd="):
> +                # find initrd image in append line
> +                args = arg.strip().split(" ")
> +                for a in args:
> +                    if a.lower().startswith("initrd="):
> +                        setattr(self, "initrd", a.replace("initrd=", ""))
> +                        arg = arg.replace(a, "")
>  
>          if com is not None and self.commands.has_key(com):
>              if self.commands[com] is not None:
> @@ -86,10 +93,12 @@ class ExtLinuxImage(object):
>          self._args = args
>      def get_kernel(self):
>          return self._kernel
> +    def set_args(self, val):
> +        self._args = val
>      def get_args(self):
>          return self._args
>      kernel = property(get_kernel, set_kernel)
> -    args = property(get_args)
> +    args = property(get_args, set_args)
>  
>      def set_initrd(self, val):
>          self._initrd = (None,val)



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:55:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri7e3-0007lm-3y; Tue, 03 Jan 2012 16:55:27 +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 1Ri7e1-0007lh-0c
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:55:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325609713!10397325!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 19850 invoked from network); 3 Jan 2012 16:55:15 -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; 3 Jan 2012 16:55:15 -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
	q03Gt4Pc002888
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 11:55:04 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03Gt35n002886;
	Tue, 3 Jan 2012 11:55:03 -0500
Date: Tue, 3 Jan 2012 12:55:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20120103165503.GA749@andromeda.dapyr.net>
References: <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>
	<CAEc3jaCwiKhxdJAGjQ4vL-s3sWVwmFbho7+BDH20OaSNQEPO8Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEc3jaCwiKhxdJAGjQ4vL-s3sWVwmFbho7+BDH20OaSNQEPO8Q@mail.gmail.com>
User-Agent: Mutt/1.5.9i
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 Mon, Dec 26, 2011 at 06:45:32PM +0000, Roderick Colenbrander wrote:
> I have finally got some results (the tests are still running). Let me
> first summarize what tests were running.

Thanks for being so dilligient in providing full details. It helps after
reading this after the holidays.
> 
> 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

Lets ignore that one. It is harmelss and I should probably remove it.

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

It certainly looks that way. Or rather that we hit a race - what
mmu_notifier_unregister tried to call was already de-allocated.
[edit: Perhaps this is related to a TLB flush fix:
 7899891c7d161752f29abcc9bc0a9c6c3a3af26c xen mmu: fix a race window
causing leave_mm BUG()]

That would explain the hang you got. The qemu-dm is stuck waiting for
gntdev to respond (you should be able to verify this by attaching gdb to
qemu-dm and seeing the backtrace - it should be stuck at some ioctl
call). And the kernel sees that this particular process is not doing
anything. Also we have some gntdev in a bad state (but that should be OK
to the other processes) - so I am not sure how that "hangs" your box.

The interrupts being disabled does not seem to occur with this crash?
Does read_interrupts code you are running is still spewing data right? Or
does it stop as well?

But lets fix one thing at a time.

Looking at the code in 2.6.32 it is the version that went upstream
as git commit ab31523c2fcac557226bac72cbdf5fafe01f9a26 and it has
not had any of the features/bug-fixes that went with the upstream
version:

ab31523 xen/gntdev: allow usermode to map granted pages
8d3eaea xen/gntdev: add VM_PFNMAP to vma
9329e76 xen: gntdev: move use of GNTMAP_contains_pte next to the map_op
ba5d101 xen/gntdev: stop using "token" argument
f0a70c8 xen/gntdev: Fix circular locking dependency
a12b4eb xen gntdev: use gnttab_map_refs and gnttab_unmap_refs
ef91082 xen-gntdev: Change page limit to be global instead of per-open
a879211 xen-gntdev: Use find_vma rather than iterating our vma list
manually
68b025c xen-gntdev: Add reference counting to maps
aab8f11 xen-gntdev: Support mapping in HVM domains
bdc612d xen/gntalloc,gntdev: Add unmap notify ioctl
90b6f30 xen-gntdev: Fix memory leak when mmap fails
0ea22f0 xen-gntdev: Fix unmap notify on PV domains
84e4075 xen-gntdev: Use map->vma for checking map validity
b57c186 xen-gntdev: Avoid unmapping ranges twice
12996fc xen-gntdev: Avoid double-mapping memory
9960be9 xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only
mappings
77c35ac xen-gntdev: Fix incorrect use of zero handle
f4ee4af xen-gntdev: Add cast to pointer
38eaeb0 xen: gntdev: fix build warning
d79647a xen/gntdev,gntalloc: Remove unneeded VM flags
ca47cea xen-gntdev: Use ballooned pages for grant mappings
12f0258 xen-gntdev: return -EFAULT on copy_to_user failure
a93e20a xen-gntdev: unlock on error path in gntdev_mmap()

The big question is whether the bug you are hitting is fixed by one of those
git commits or that an unrelated fix (like the vmalloc_sync_all or the
kmap_atomic one) which are:
461ae488ecb125b140d7ea29ceeedbcce9327003 mm: sync vmalloc address space page tables in alloc_vm_area(
2cd1c8d4dc7ecca9e9431e2dabe41ae9c7d89e51 x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode

But the errors that one gets without those two git commits is much
different from what you get. So I doubt it is one of those.

The CPU time going backwards is disturbing. It does imply that the Xen
hypervisor has stopped updating the timer information. Or maybe it has
not, but the gntdev has crashed and left all the interrupts disabled.

So three questions:
 1). Is the read_intr printing any data after the crash?
 2). If you attach gdb to qemu-dm can you see where it is stuck at?
 3). Is the console activate at all? If not, can you SSH in (some
     network cards switch to polling so you can still login in a machine
     even if the interrupts are turned off - the atl1c something can do
     it and I think the r8169 as well, but not sure).
 4). If you had configured your dom0 console to use the serial console
     instead of going through the Xen hypervisor console (so
     console=ttyS0 on Linux, and no com1=XXX and console=com1 on Xen
     hypervisor line), could you get a back-track of where the Linux
     kernel is at using Alt-sysRq?

Thanks and sorry for taking so long. Just coming back from holidays.


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:55:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 16:55:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri7e3-0007lm-3y; Tue, 03 Jan 2012 16:55:27 +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 1Ri7e1-0007lh-0c
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:55:25 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325609713!10397325!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 19850 invoked from network); 3 Jan 2012 16:55:15 -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; 3 Jan 2012 16:55:15 -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
	q03Gt4Pc002888
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 11:55:04 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03Gt35n002886;
	Tue, 3 Jan 2012 11:55:03 -0500
Date: Tue, 3 Jan 2012 12:55:03 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Roderick Colenbrander <thunderbird2k@gmail.com>
Message-ID: <20120103165503.GA749@andromeda.dapyr.net>
References: <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>
	<CAEc3jaCwiKhxdJAGjQ4vL-s3sWVwmFbho7+BDH20OaSNQEPO8Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEc3jaCwiKhxdJAGjQ4vL-s3sWVwmFbho7+BDH20OaSNQEPO8Q@mail.gmail.com>
User-Agent: Mutt/1.5.9i
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 Mon, Dec 26, 2011 at 06:45:32PM +0000, Roderick Colenbrander wrote:
> I have finally got some results (the tests are still running). Let me
> first summarize what tests were running.

Thanks for being so dilligient in providing full details. It helps after
reading this after the holidays.
> 
> 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

Lets ignore that one. It is harmelss and I should probably remove it.

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

It certainly looks that way. Or rather that we hit a race - what
mmu_notifier_unregister tried to call was already de-allocated.
[edit: Perhaps this is related to a TLB flush fix:
 7899891c7d161752f29abcc9bc0a9c6c3a3af26c xen mmu: fix a race window
causing leave_mm BUG()]

That would explain the hang you got. The qemu-dm is stuck waiting for
gntdev to respond (you should be able to verify this by attaching gdb to
qemu-dm and seeing the backtrace - it should be stuck at some ioctl
call). And the kernel sees that this particular process is not doing
anything. Also we have some gntdev in a bad state (but that should be OK
to the other processes) - so I am not sure how that "hangs" your box.

The interrupts being disabled does not seem to occur with this crash?
Does read_interrupts code you are running is still spewing data right? Or
does it stop as well?

But lets fix one thing at a time.

Looking at the code in 2.6.32 it is the version that went upstream
as git commit ab31523c2fcac557226bac72cbdf5fafe01f9a26 and it has
not had any of the features/bug-fixes that went with the upstream
version:

ab31523 xen/gntdev: allow usermode to map granted pages
8d3eaea xen/gntdev: add VM_PFNMAP to vma
9329e76 xen: gntdev: move use of GNTMAP_contains_pte next to the map_op
ba5d101 xen/gntdev: stop using "token" argument
f0a70c8 xen/gntdev: Fix circular locking dependency
a12b4eb xen gntdev: use gnttab_map_refs and gnttab_unmap_refs
ef91082 xen-gntdev: Change page limit to be global instead of per-open
a879211 xen-gntdev: Use find_vma rather than iterating our vma list
manually
68b025c xen-gntdev: Add reference counting to maps
aab8f11 xen-gntdev: Support mapping in HVM domains
bdc612d xen/gntalloc,gntdev: Add unmap notify ioctl
90b6f30 xen-gntdev: Fix memory leak when mmap fails
0ea22f0 xen-gntdev: Fix unmap notify on PV domains
84e4075 xen-gntdev: Use map->vma for checking map validity
b57c186 xen-gntdev: Avoid unmapping ranges twice
12996fc xen-gntdev: Avoid double-mapping memory
9960be9 xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only
mappings
77c35ac xen-gntdev: Fix incorrect use of zero handle
f4ee4af xen-gntdev: Add cast to pointer
38eaeb0 xen: gntdev: fix build warning
d79647a xen/gntdev,gntalloc: Remove unneeded VM flags
ca47cea xen-gntdev: Use ballooned pages for grant mappings
12f0258 xen-gntdev: return -EFAULT on copy_to_user failure
a93e20a xen-gntdev: unlock on error path in gntdev_mmap()

The big question is whether the bug you are hitting is fixed by one of those
git commits or that an unrelated fix (like the vmalloc_sync_all or the
kmap_atomic one) which are:
461ae488ecb125b140d7ea29ceeedbcce9327003 mm: sync vmalloc address space page tables in alloc_vm_area(
2cd1c8d4dc7ecca9e9431e2dabe41ae9c7d89e51 x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode

But the errors that one gets without those two git commits is much
different from what you get. So I doubt it is one of those.

The CPU time going backwards is disturbing. It does imply that the Xen
hypervisor has stopped updating the timer information. Or maybe it has
not, but the gntdev has crashed and left all the interrupts disabled.

So three questions:
 1). Is the read_intr printing any data after the crash?
 2). If you attach gdb to qemu-dm can you see where it is stuck at?
 3). Is the console activate at all? If not, can you SSH in (some
     network cards switch to polling so you can still login in a machine
     even if the interrupts are turned off - the atl1c something can do
     it and I think the r8169 as well, but not sure).
 4). If you had configured your dom0 console to use the serial console
     instead of going through the Xen hypervisor console (so
     console=ttyS0 on Linux, and no com1=XXX and console=com1 on Xen
     hypervisor line), could you get a back-track of where the Linux
     kernel is at using Alt-sysRq?

Thanks and sorry for taking so long. Just coming back from holidays.


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:59:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri7hv-0007rw-Q9; Tue, 03 Jan 2012 16:59:27 +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 1Ri7hv-0007rS-3N
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:59:27 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325609959!10397847!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 2879 invoked from network); 3 Jan 2012 16:59:21 -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; 3 Jan 2012 16:59: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
	q03GxHfS003049
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 11:59:17 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03GxHAP003047;
	Tue, 3 Jan 2012 11:59:17 -0500
Date: Tue, 3 Jan 2012 12:59:17 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120103165917.GB749@andromeda.dapyr.net>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"'Konrad Rzeszutek Wilk \(konrad.wilk@oracle.com\)'"
	<konrad.wilk@oracle.com>
Subject: Re: [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

On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote:
> Hi, Konrad

Hey!

Sorry for taking so long to respond. Holidays.
> 
> 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 hadn't seen it... but then my main desktop box where I run intensive
tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
The box that has i915 just does some simple framebuffer manipulation and
that looks OK.

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

Do you see the same symptoms - checkboard screen?

The LKML had some fixes for this from Keith Packard. Something about
using i915.semaphores=0 I think. And I thought I saw some fixes for
3.2-rc7 for this but not sure..

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 16:59:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri7hv-0007rw-Q9; Tue, 03 Jan 2012 16:59:27 +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 1Ri7hv-0007rS-3N
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 16:59:27 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325609959!10397847!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 2879 invoked from network); 3 Jan 2012 16:59:21 -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; 3 Jan 2012 16:59: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
	q03GxHfS003049
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 11:59:17 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03GxHAP003047;
	Tue, 3 Jan 2012 11:59:17 -0500
Date: Tue, 3 Jan 2012 12:59:17 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120103165917.GB749@andromeda.dapyr.net>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"'Konrad Rzeszutek Wilk \(konrad.wilk@oracle.com\)'"
	<konrad.wilk@oracle.com>
Subject: Re: [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

On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote:
> Hi, Konrad

Hey!

Sorry for taking so long to respond. Holidays.
> 
> 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 hadn't seen it... but then my main desktop box where I run intensive
tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
The box that has i915 just does some simple framebuffer manipulation and
that looks OK.

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

Do you see the same symptoms - checkboard screen?

The LKML had some fixes for this from Keith Packard. Something about
using i915.semaphores=0 I think. And I thought I saw some fixes for
3.2-rc7 for this but not sure..

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:01:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17: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 1Ri7k0-00082P-DC; Tue, 03 Jan 2012 17:01:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ri7jz-000826-2s
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:01:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325610089!10398131!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8204 invoked from network); 3 Jan 2012 17:01:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:01:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9796580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 17:01: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, 3 Jan 2012 17:01: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
	1Ri7js-0000VZ-GB; Tue, 03 Jan 2012 17:01:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri7js-0005Rj-FG;
	Tue, 03 Jan 2012 17:01:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.13416.459908.208375@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 17:01:28 +0000
To: Adin Scannell <adin@scannell.ca>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] 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

Adin Scannell writes ("[Xen-devel] [PATCH] Only retry mapping pages when ENOENT is returned"):
> 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.

I confess I don't understand the intended error handling here.  AFAICT
this ioctl leaves a separate errno value for each request, in the
array.  Presumably, however, it can also fail entirely and not update
the separate in-array errno values.

So how does one tell which of these is the case ?

CCing Jan since it looks like his code originally, in 20791:0b138a019292

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:01:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17: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 1Ri7k0-00082P-DC; Tue, 03 Jan 2012 17:01:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Ri7jz-000826-2s
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:01:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325610089!10398131!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8204 invoked from network); 3 Jan 2012 17:01:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:01:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9796580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 17:01: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, 3 Jan 2012 17:01: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
	1Ri7js-0000VZ-GB; Tue, 03 Jan 2012 17:01:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri7js-0005Rj-FG;
	Tue, 03 Jan 2012 17:01:28 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.13416.459908.208375@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 17:01:28 +0000
To: Adin Scannell <adin@scannell.ca>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] 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

Adin Scannell writes ("[Xen-devel] [PATCH] Only retry mapping pages when ENOENT is returned"):
> 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.

I confess I don't understand the intended error handling here.  AFAICT
this ioctl leaves a separate errno value for each request, in the
array.  Presumably, however, it can also fail entirely and not update
the separate in-array errno values.

So how does one tell which of these is the case ?

CCing Jan since it looks like his code originally, in 20791:0b138a019292

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:15:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri7xQ-0008K5-PW; Tue, 03 Jan 2012 17:15:28 +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 1Ri7xP-0008K0-4l
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:15:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325610918!9481684!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14382 invoked from network); 3 Jan 2012 17:15:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 17:15:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q03HErWY022505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 17:14: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
	q03HEpa4007169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 17:14:52 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q03HEpwb000624; Tue, 3 Jan 2012 11:14:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 09:14:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 69C2640323; Tue,  3 Jan 2012 12:13:18 -0500 (EST)
Date: Tue, 3 Jan 2012 12:13:18 -0500
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
Message-ID: <20120103171318.GA25341@phenom.dumpdata.com>
References: <1324075099-11397-1-git-send-email-konrad.wilk@oracle.com>
	<1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F03378F.0065,ss=1,re=0.000,fgs=0
Cc: Shane Wang <shane.wang@intel.com>, Thomas Gleixner <tglx@linutronix.de>,
	xen-devel@lists.xensource.com, hpa@zytor.com
Subject: Re: [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>
Content-Type: text/plain; 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:13PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Tang Liang <liang.tang@oracle.com>

Hey Joseph,

I remember you acked the initial rfc patches I had posted.
But I was wondering if these ones are to your liking (I think they are -
they aren't that much different, but I didn't want to blindly sticking
'Acked-by' as they did change a bit).

Thanks!
> 
> 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 Tue Jan 03 17:15:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri7xQ-0008K5-PW; Tue, 03 Jan 2012 17:15:28 +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 1Ri7xP-0008K0-4l
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:15:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325610918!9481684!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14382 invoked from network); 3 Jan 2012 17:15:20 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 17:15:20 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q03HErWY022505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 17:14: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
	q03HEpa4007169
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 17:14:52 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q03HEpwb000624; Tue, 3 Jan 2012 11:14:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 09:14:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 69C2640323; Tue,  3 Jan 2012 12:13:18 -0500 (EST)
Date: Tue, 3 Jan 2012 12:13:18 -0500
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
Message-ID: <20120103171318.GA25341@phenom.dumpdata.com>
References: <1324075099-11397-1-git-send-email-konrad.wilk@oracle.com>
	<1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F03378F.0065,ss=1,re=0.000,fgs=0
Cc: Shane Wang <shane.wang@intel.com>, Thomas Gleixner <tglx@linutronix.de>,
	xen-devel@lists.xensource.com, hpa@zytor.com
Subject: Re: [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>
Content-Type: text/plain; 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:13PM -0500, Konrad Rzeszutek Wilk wrote:
> From: Tang Liang <liang.tang@oracle.com>

Hey Joseph,

I remember you acked the initial rfc patches I had posted.
But I was wondering if these ones are to your liking (I think they are -
they aren't that much different, but I didn't want to blindly sticking
'Acked-by' as they did change a bit).

Thanks!
> 
> 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 Tue Jan 03 17:17:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri7z6-0008PC-GB; Tue, 03 Jan 2012 17:17: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 1Ri7z5-0008Oz-8V
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:17:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325611025!10352821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2187 invoked from network); 3 Jan 2012 17:17: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;
	3 Jan 2012 17:17:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9796828"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 17:17:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Jan 2012 17:17: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
	1Ri7yy-0000av-G3; Tue, 03 Jan 2012 17:17:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri7yy-0005TH-FA;
	Tue, 03 Jan 2012 17:17:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.14352.456283.37593@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 17:17:04 +0000
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CACm5R6R4M6oDdgHyKLkUr4jah3Bki-gDCfTUQpDDTQS8X4bBCw@mail.gmail.com>
References: <CACm5R6R4M6oDdgHyKLkUr4jah3Bki-gDCfTUQpDDTQS8X4bBCw@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] 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

xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] The connection to the server was reset while the page was loading."):
> 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."

This link is stale.  We do not run an lxr instance any more I'm
afraid.

I think this is supposed to be a link to the MAINTAINERS file in
xen-unstable, which can be found here:
  http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/MAINTAINERS
or
  http://xenbits.xen.org/hg/xen-unstable.hg/raw-file/tip/MAINTAINERS

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:17:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:17:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri7z6-0008PC-GB; Tue, 03 Jan 2012 17:17: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 1Ri7z5-0008Oz-8V
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:17:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325611025!10352821!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2187 invoked from network); 3 Jan 2012 17:17: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;
	3 Jan 2012 17:17:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9796828"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 17:17:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Jan 2012 17:17: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
	1Ri7yy-0000av-G3; Tue, 03 Jan 2012 17:17:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri7yy-0005TH-FA;
	Tue, 03 Jan 2012 17:17:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.14352.456283.37593@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 17:17:04 +0000
To: xen-devel.GarveyPatrickD@OrdinaryAmerican.net
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CACm5R6R4M6oDdgHyKLkUr4jah3Bki-gDCfTUQpDDTQS8X4bBCw@mail.gmail.com>
References: <CACm5R6R4M6oDdgHyKLkUr4jah3Bki-gDCfTUQpDDTQS8X4bBCw@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] 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

xen-devel.GarveyPatrickD@OrdinaryAmerican.net writes ("[Xen-devel] The connection to the server was reset while the page was loading."):
> 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."

This link is stale.  We do not run an lxr instance any more I'm
afraid.

I think this is supposed to be a link to the MAINTAINERS file in
xen-unstable, which can be found here:
  http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/MAINTAINERS
or
  http://xenbits.xen.org/hg/xen-unstable.hg/raw-file/tip/MAINTAINERS

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:20:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri827-00008L-3c; Tue, 03 Jan 2012 17:20:19 +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 1Ri825-000086-SJ
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:20:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325611210!9580841!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 14375 invoked from network); 3 Jan 2012 17:20:11 -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; 3 Jan 2012 17:20: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
	q03HK7L1004608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 12:20:07 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03HK7dG004606;
	Tue, 3 Jan 2012 12:20:07 -0500
Date: Tue, 3 Jan 2012 13:20:07 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: chao.zhou@intel.com
Message-ID: <20120103172007.GD749@andromeda.dapyr.net>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
	<20111229173208.GA18032@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111229173208.GA18032@phenom.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Zhou,
	Chao" <chao.zhou@intel.com>
Subject: Re: [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

On Thu, Dec 29, 2011 at 12:32:08PM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 29, 2011 at 08:42:17AM +0000, Zhou, Chao wrote:
> > 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
> 
> When are you guys planning to switch to the upstream kernel?

ping? As in the 3.0 or 3.1 or 3.2.x kernel?

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:20:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 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 1Ri827-00008L-3c; Tue, 03 Jan 2012 17:20:19 +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 1Ri825-000086-SJ
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:20:18 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325611210!9580841!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 14375 invoked from network); 3 Jan 2012 17:20:11 -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; 3 Jan 2012 17:20: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
	q03HK7L1004608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 12:20:07 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03HK7dG004606;
	Tue, 3 Jan 2012 12:20:07 -0500
Date: Tue, 3 Jan 2012 13:20:07 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: chao.zhou@intel.com
Message-ID: <20120103172007.GD749@andromeda.dapyr.net>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
	<20111229173208.GA18032@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111229173208.GA18032@phenom.dumpdata.com>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Zhou,
	Chao" <chao.zhou@intel.com>
Subject: Re: [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

On Thu, Dec 29, 2011 at 12:32:08PM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 29, 2011 at 08:42:17AM +0000, Zhou, Chao wrote:
> > 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
> 
> When are you guys planning to switch to the upstream kernel?

ping? As in the 3.0 or 3.1 or 3.2.x kernel?

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:20:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri82K-00009n-GG; Tue, 03 Jan 2012 17:20:32 +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 1Ri82J-000092-3R
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:20:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325611218!9565709!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20414 invoked from network); 3 Jan 2012 17:20:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:20:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9796884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 17:20: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, 3 Jan 2012 17:20:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ri826-0000cA-1Y; Tue, 03 Jan 2012 17:20:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri826-0005Te-0X;
	Tue, 03 Jan 2012 17:20:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.14545.989493.105590@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 17:20:17 +0000
To: Adin Scannell <adin@scannell.ca>
In-Reply-To: <CAPgzrSV3PsyxFXSwsRfK3ordS-DQF35_c3PP0APpYTC9CUUneA@mail.gmail.com>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
	<20227.13416.459908.208375@mariner.uk.xensource.com>
	<CAPgzrSV3PsyxFXSwsRfK3ordS-DQF35_c3PP0APpYTC9CUUneA@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] 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

Adin Scannell writes ("Re: [Xen-devel] [PATCH] Only retry mapping pages when ENOENT is returned"):
> ENOENT is returned in the case where everything is successful, but at
> least one of the entries is ENOENT as the page was not available
> (paged-out).  In other words, when ENOENT is returned you can trust
> the errno entries were filled in.  It's a somewhat special case.

Right, thanks, that makes sense.  I would apply it but you didn't sign
it off.  Also, we should CC Olaf, so doing that now.

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 Jan 03 17:20:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:20:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri82K-00009n-GG; Tue, 03 Jan 2012 17:20:32 +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 1Ri82J-000092-3R
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:20:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325611218!9565709!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20414 invoked from network); 3 Jan 2012 17:20:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:20:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,450,1320624000"; 
   d="scan'208";a="9796884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 17:20: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, 3 Jan 2012 17:20:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Ri826-0000cA-1Y; Tue, 03 Jan 2012 17:20:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri826-0005Te-0X;
	Tue, 03 Jan 2012 17:20:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.14545.989493.105590@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 17:20:17 +0000
To: Adin Scannell <adin@scannell.ca>
In-Reply-To: <CAPgzrSV3PsyxFXSwsRfK3ordS-DQF35_c3PP0APpYTC9CUUneA@mail.gmail.com>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
	<20227.13416.459908.208375@mariner.uk.xensource.com>
	<CAPgzrSV3PsyxFXSwsRfK3ordS-DQF35_c3PP0APpYTC9CUUneA@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] 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

Adin Scannell writes ("Re: [Xen-devel] [PATCH] Only retry mapping pages when ENOENT is returned"):
> ENOENT is returned in the case where everything is successful, but at
> least one of the entries is ENOENT as the page was not available
> (paged-out).  In other words, when ENOENT is returned you can trust
> the errno entries were filled in.  It's a somewhat special case.

Right, thanks, that makes sense.  I would apply it but you didn't sign
it off.  Also, we should CC Olaf, so doing that now.

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 Jan 03 17:37:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17: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 1Ri8IU-0000al-8O; Tue, 03 Jan 2012 17:37:14 +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 1Ri8IS-0000ad-K2
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:37:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1325612224!10129973!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 5940 invoked from network); 3 Jan 2012 17:37:06 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:37:06 -0000
Received: by daec6 with SMTP id c6so62387752dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 09:37: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=AYlmlUbRnQC5f7fXLYuW4AOvRGgq9Aex1F0KUcmb4Y0=;
	b=URVqIELoxgyiJp786ruF1m4mVM7++TqfIhlzuUfGQbDSCCfTl/OTllXV4f7GM1mGlQ
	qPLlYeWsJiYaTp8ZN8BWXmjQrPkBiuEok+beMzV6ikFJ1jyOZa3OXTpVkT4wb6H40KsL
	/XC//6+istICWBMxMnvfCUByj8HxPjgmFYpw0=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr132315352pbc.112.1325611826648;
	Tue, 03 Jan 2012 09:30:26 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 09:30:26 -0800 (PST)
In-Reply-To: <1325604168.25206.160.camel@zakaz.uk.xensource.com>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
	<1325583878.25206.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@mail.gmail.com>
	<20120103151047.GC27383@andromeda.dapyr.net>
	<1325604168.25206.160.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Jan 2012 18:30:26 +0100
X-Google-Sender-Auth: keIVO2PbY3jCVL7WcxGdqdaP_08
Message-ID: <CAPLaKK7V2TNOxwRGqM3i9FnTowMgO=6d72e=1039TcOiy_nDLA@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: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	alpine-devel@lists.alpinelinux.org
Subject: Re: [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've crafted a small proof-of-concept (I've tested it to some degree,
but it's possibly full of bugs, you are advised), that contains a
patched version of Xen 4.1.2 that works with uclibc. The iso is here:

http://sertel.upc.edu/~royger/alpine-xen.iso
md5: 5c78b0895d58a8f17c958b5dff9cf00c

Just burn it (or load it to your VM) and boot from the CD. The image
will hopefully boot, and you will get a login screen, type root (no
password required). Next step is:

# setup-alpine

To have the basic system working, it will ask you if you want to
bridge your interfaces, which you probably want. It will also ask if
you want to perform a HDD install if it detects a hard drive, reply
none to those questions, and you will have your basic Xen system up
and running.

The image doesn't come with any DomUs, it only comes with the minimum
necessary to run a Dom0 (Xen + BusyBox basically), all loaded to
tmpfs. As a note, the memory/vcpus used by the Dom0 is not limited.

If you want to create DomUs, I recommend that you attach a
HDD/USB/NFS/iSCSI... to store the image (creating it on tmpfs is not
really a good idea).

To generate the image I've used a modified version of alpine-iso (the
image generation tool used by Alpine Linux distribution), and the
changes have already been added to the main tools:

http://git.alpinelinux.org/cgit/alpine-conf/
http://git.alpinelinux.org/cgit/alpine-iso/

The only missing part is the Xen 4.1.2 package itself, which will
hopefully be added to the package repository soon, so Xen Dom0 images
can be build easily by any user by just running alpine-iso tools.

Regards, Roger.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:37:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17: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 1Ri8IU-0000al-8O; Tue, 03 Jan 2012 17:37:14 +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 1Ri8IS-0000ad-K2
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:37:12 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1325612224!10129973!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 5940 invoked from network); 3 Jan 2012 17:37:06 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:37:06 -0000
Received: by daec6 with SMTP id c6so62387752dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 09:37: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=AYlmlUbRnQC5f7fXLYuW4AOvRGgq9Aex1F0KUcmb4Y0=;
	b=URVqIELoxgyiJp786ruF1m4mVM7++TqfIhlzuUfGQbDSCCfTl/OTllXV4f7GM1mGlQ
	qPLlYeWsJiYaTp8ZN8BWXmjQrPkBiuEok+beMzV6ikFJ1jyOZa3OXTpVkT4wb6H40KsL
	/XC//6+istICWBMxMnvfCUByj8HxPjgmFYpw0=
MIME-Version: 1.0
Received: by 10.68.190.226 with SMTP id gt2mr132315352pbc.112.1325611826648;
	Tue, 03 Jan 2012 09:30:26 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 09:30:26 -0800 (PST)
In-Reply-To: <1325604168.25206.160.camel@zakaz.uk.xensource.com>
References: <CAPLaKK7Oi2chcq0Ke2nCz6yqae-oL7fDTbBbWeGw4i2rV0g_XA@mail.gmail.com>
	<1325583878.25206.6.camel@zakaz.uk.xensource.com>
	<CAPLaKK7jNrPQ=bKYzvhA++_spFgUjCUJJ8P9zy-B3hq6VeA0FA@mail.gmail.com>
	<20120103151047.GC27383@andromeda.dapyr.net>
	<1325604168.25206.160.camel@zakaz.uk.xensource.com>
Date: Tue, 3 Jan 2012 18:30:26 +0100
X-Google-Sender-Auth: keIVO2PbY3jCVL7WcxGdqdaP_08
Message-ID: <CAPLaKK7V2TNOxwRGqM3i9FnTowMgO=6d72e=1039TcOiy_nDLA@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: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	alpine-devel@lists.alpinelinux.org
Subject: Re: [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've crafted a small proof-of-concept (I've tested it to some degree,
but it's possibly full of bugs, you are advised), that contains a
patched version of Xen 4.1.2 that works with uclibc. The iso is here:

http://sertel.upc.edu/~royger/alpine-xen.iso
md5: 5c78b0895d58a8f17c958b5dff9cf00c

Just burn it (or load it to your VM) and boot from the CD. The image
will hopefully boot, and you will get a login screen, type root (no
password required). Next step is:

# setup-alpine

To have the basic system working, it will ask you if you want to
bridge your interfaces, which you probably want. It will also ask if
you want to perform a HDD install if it detects a hard drive, reply
none to those questions, and you will have your basic Xen system up
and running.

The image doesn't come with any DomUs, it only comes with the minimum
necessary to run a Dom0 (Xen + BusyBox basically), all loaded to
tmpfs. As a note, the memory/vcpus used by the Dom0 is not limited.

If you want to create DomUs, I recommend that you attach a
HDD/USB/NFS/iSCSI... to store the image (creating it on tmpfs is not
really a good idea).

To generate the image I've used a modified version of alpine-iso (the
image generation tool used by Alpine Linux distribution), and the
changes have already been added to the main tools:

http://git.alpinelinux.org/cgit/alpine-conf/
http://git.alpinelinux.org/cgit/alpine-iso/

The only missing part is the Xen 4.1.2 package itself, which will
hopefully be added to the package repository soon, so Xen Dom0 images
can be build easily by any user by just running alpine-iso tools.

Regards, Roger.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 17:53:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17: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 1Ri8Xh-0000lX-Op; Tue, 03 Jan 2012 17:52:57 +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 1Ri8Xg-0000lM-0I; Tue, 03 Jan 2012 17:52:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325613165!10356503!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 6538 invoked from network); 3 Jan 2012 17:52:47 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 17:52:47 -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
	q03HqhYQ005729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 12:52:43 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03Hqh5S005727;
	Tue, 3 Jan 2012 12:52:43 -0500
Date: Tue, 3 Jan 2012 13:52:43 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: R J <torushikeshj@gmail.com>
Message-ID: <20120103175243.GE749@andromeda.dapyr.net>
References: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
	xen-api@lists.xensource.com
Subject: Re: [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>
Content-Type: text/plain; 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 29, 2011 at 11:28:59PM +0530, R J wrote:
> 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.


Node? Meaning dom0? Or the guest? Are you using dom0_mem=max:X argument?

> I have attached the HVM boot log of successful start. Many times the node
> hangs as soon as the BalloonWorkerThread is activated.

Which PV driver is this? Is this with the other ones: GPL one, Citrix, Novell, and
Oracle as well?

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

> Dec 29 23:08:01 n4 xenguest: Determined the following parameters from xenstore:
> Dec 29 23:08:01 n4 xenguest: vcpu/number:16 vcpu/weight:0 vcpu/cap:0 nx: 1 viridian: 1 apic: 1 acpi: 1 pae: 1 acpi_s4: 0 acpi_s3: 0
> Dec 29 23:08:01 n4 xenguest: vcpu/0/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/1/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/2/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/3/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/4/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/5/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/6/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/7/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/8/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/9/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/10/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/11/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/12/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/13/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/14/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/15/affinity:0
> Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-control: init, 10 x 4k buffers 
> Dec 29 23:08:14 n4 tapdisk[18204]: I/O queue driver: lio 
> Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-log: started, level 0 
> Dec 29 23:08:14 n4 tapdisk[18204]: received 'attach' message (uuid = 0) 
> Dec 29 23:08:14 n4 tapdisk[18204]: sending 'attach response' message (uuid = 0) 
> Dec 29 23:08:14 n4 tapdisk[18204]: received 'open' message (uuid = 0) 
> Dec 29 23:08:14 n4 tapdisk[18204]: Loading driver 'vhd' for vbd 0 /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 0x00000000 
> Dec 29 23:08:14 n4 tapdisk[18204]: /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 version: tap 0x00010003, b: 15360, a: 307, f: 26, n: 1268376 
> Dec 29 23:08:14 n4 tapdisk[18204]: opened image /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 (1 users, state: 0x00000001, type: 4) 
> Dec 29 23:08:14 n4 tapdisk[18204]: /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b version: tap 0x00010003, b: 15360, a: 3331, f: 3307, n: 0 
> Dec 29 23:08:14 n4 tapdisk[18204]: opened image /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b (1 users, state: 0x00000003, type: 4) 
> Dec 29 23:08:14 n4 tapdisk[18204]: VBD CHAIN: 
> Dec 29 23:08:14 n4 tapdisk[18204]: /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297: type:vhd(4) storage:lvm(3) 
> Dec 29 23:08:14 n4 tapdisk[18204]: /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b: type:vhd(4) storage:lvm(3) 
> Dec 29 23:08:14 n4 tapdisk[18204]: sending 'open response' message (uuid = 0) 
> Dec 29 23:08:14 n4 vbd.uevent[add](backend/vbd/18/768): wrote /xapi/18/hotplug/vbd/768/hotplug = 'online'
> Dec 29 23:08:15 n4 vbd.uevent[add](backend/vbd/18/5696): wrote /xapi/18/hotplug/vbd/5696/hotplug = 'online'
> Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl list-ports xapi9
> Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port vif18.0 -- add-port xapi9 vif18.0 -- set interface vif18.0 "external-ids:\"xs-vm-uuid\"=\"6591a403-0eba-30b4-96a6-e02a7db0607a\"" -- set interface vif18.0 "external-ids:\"xs-vif-uuid\"=\"3be54e6d-6d13-b04b-6735-24831e5169e5\"" -- set interface vif18.0 "external-ids:\"xs-network-uuid\"=\"7051ef99-4fcb-fa61-a10e-f98456e12e90\"" -- set interface vif18.0 "external-ids:\"attached-mac\"=\"d6:6d:60:7e:45:52\""
> Dec 29 23:08:15 n4 qemu.18: domid: 18 
> Dec 29 23:08:15 n4 qemu.18: qemu: the number of cpus is 16 
> Dec 29 23:08:15 n4 qemu.18: -videoram option does not work with cirrus vga device model. Videoram set to 4M. 
> Dec 29 23:08:15 n4 HVM18[18302]: Guest uuid = 6591a403-0eba-30b4-96a6-e02a7db0607a 
> Dec 29 23:08:15 n4 HVM18[18302]: Watching /local/domain/18/logdirty/next-active 
> Dec 29 23:08:15 n4 HVM18[18302]: Watching /local/domain/0/device-model/18/command 
> Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/2 
> Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/3 
> Dec 29 23:08:15 n4 HVM18[18302]: qemu_map_cache_init nr_buckets = 4000 size 327680 
> Dec 29 23:08:15 n4 HVM18[18302]: shared page at pfn feffd 
> Dec 29 23:08:15 n4 HVM18[18302]: buffered io page at pfn feffb 
> Dec 29 23:08:15 n4 HVM18[18302]: Time offset set 0 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:00:00 (i440FX) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:00 (PIIX3) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:02:00 (Cirrus VGA) 
> Dec 29 23:08:15 n4 HVM18[18302]: populating video RAM at ff000000 
> Dec 29 23:08:15 n4 HVM18[18302]: mapping video RAM from ff000000 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:03:00 (xen-platform) 
> Dec 29 23:08:15 n4 HVM18[18302]: xs_read(/vm/6591a403-0eba-30b4-96a6-e02a7db0607a/log-throttling): read error 
> Dec 29 23:08:15 n4 HVM18[18302]: ROM memory area now RW 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:04:00 (RTL8139) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:01 (PIIX3 IDE) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:02 (USB-UHCI) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:03 (PIIX4 ACPI) 
> Dec 29 23:08:15 n4 HVM18[18302]: xs_read(/local/domain/0/device-model/18/xen_extended_power_mgmt): read error 
> Dec 29 23:08:15 n4 HVM18[18302]: releasing VM 
> Dec 29 23:08:15 n4 HVM18[18302]: xs_read(): vncpasswd get error. /vm/6591a403-0eba-30b4-96a6-e02a7db0607a/vncpasswd. 
> Dec 29 23:08:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 
> Dec 29 17:38:15 n4 last message repeated 2 times
> Dec 29 17:38:15 n4 HVM18[18302]: Triggered log-dirty buffer switch 
> Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 
> Dec 29 17:38:15 n4 HVM18[18302]: medium change watch on `hdd' (index: 1):  
> Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 
> Dec 29 17:38:15 n4 last message repeated 11 times
> Dec 29 17:38:16 n4 HVM18[18302]: cirrus vga map change while on lfb mode 
> Dec 29 23:08:16 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port tap18.0 -- add-port xapi9 tap18.0
> Dec 29 17:38:16 n4 HVM18[18302]: mapping vram to f0000000 - f0400000 
> Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RW 
> Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RO 
> Dec 29 17:38:18 n4 HVM18[18302]: cirrus: blanking the screen line_offset=3072 height=768 
> Dec 29 17:38:34 n4 HVM18[18302]: cirrus: blanking the screen line_offset=1024 height=768 
> Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol version set to 1 (drivers not blacklisted) 
> Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol 1 active 
> Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: product_id: 1 build_number: 30876 
> Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: drivers not blacklisted 
> Dec 29 17:38:37 n4 HVM18[18302]: ide_unplug_harddisk: drive 0 
> Dec 29 17:38:37 n4 HVM18[18302]: pci_dev_unplug: 00:04:00 
> Dec 29 17:38:37 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0 
> Dec 29 23:08:38 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port tap18.0
> Dec 29 17:38:38 n4 HVM18[18302]:  XEVTCHN: InstallDumpDeviceCallback: version mismatch (255 != 1) 
> Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: XenevtchnAddDevice: FDO = 0xFFFFFA8044323970 
> Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: Initialized tracing provider 
> Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: StartDeviceFdo: ====> 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: XEVTCHN: IO hole: [00000000fbfa6000,00000000fc000000) mapped at FFFFF88002965000 
> Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: KERNEL: 6.1 (build 7600) platform WIN32_NT 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: SP: NONE 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: SUITES: 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - TERMINAL 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - DATACENTER 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - SINGLEUSERTS 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: TYPE: SERVER 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: PV DRIVERS: VERSION: 5.6.0 BUILD: 30876 (Apr 30 2010.06:57:01) 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: 64-bit HVM 
> Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: ExpandGrantTable: GRANT TABLE 0: (0 - 511) at FFFFF88002966000 (fbfa7000) 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: XenEnterprise product string is present 
> Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: PHYSICAL MEMORY: TOP = 00000016.8fc00000 
> Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: BalloonTargetChanged: 94371840k -> 43792384k 
> Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: activating 
> Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2230ms 
> Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 7924ms (2064k/s) 
> Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94355480k) 
> Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 1794ms 
> Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 9157ms (1786k/s) 
> Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94339120k) 
> Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5070ms 
> Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 14601ms (1120k/s) 
> Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94322760k) 
> Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 4321ms 
> Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 16052ms (1019k/s) 
> Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94306400k) 
> Dec 29 17:39:40 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4) 
> Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 6099ms 
> Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 15132ms (1081k/s) 
> Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94290040k) 
> Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 4492ms 
> Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 17206ms (950k/s) 
> Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94273680k) 
> Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2043ms 
> Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 11294ms (1448k/s) 
> Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94257320k) 
> Dec 29 17:40:27 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4) 
> Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5179ms 
> Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 15100ms (1083k/s) 
> Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94240960k) 
> Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2230ms 
> Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 12870ms (1271k/s) 
> Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94224600k) 
> Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5350ms 
> Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 13228ms (1236k/s) 
> Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94208240k) 
> Dec 29 17:41:14 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4) 
> Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 3026ms 
> Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 15490ms (1056k/s) 
> Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94191880k) 
> Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 3151ms 
> Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 13291ms (1230k/s) 
> Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94175520k) 
> Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5553ms 
> Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 16832ms (971k/s) 
> Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94159160k) 
> Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 6754ms 
> Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 18111ms (903k/s) 
> Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94142800k) 
> Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 3244ms 
> Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 18392ms (889k/s) 
> Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94126440k) 
> Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5725ms 
> Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 18454ms (886k/s) 
> Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94110080k) 
> Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 4243ms 
> Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 19453ms (841k/s) 
> Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94093720k) 
> Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5241ms 
> Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 17206ms (950k/s) 
> Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94077360k) 
> Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 1996ms 
> Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 17253ms (948k/s) 
> Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94061000k) 
> Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 4773ms 
> Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 16286ms (1004k/s) 
> Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94044640k) 
> Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2152ms 
> Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 21231ms (770k/s) 
> Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94028280k) 
> Dec 29 17:44:40 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4) 
> Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2199ms 
> Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 17331ms (943k/s) 
> Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94011920k) 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 12554884 page(s) in 32604ms (91243k/s) 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: de-activating 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: XenevtchnMapResources setting callback irq to 11 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: PV init. done 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonTargetChanged: 43792384k -> 48911360k 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: activating 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: Detected new device vif/0. 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: closing device/vif/0... 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: device/vif/0 closed 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: StartDeviceFdo: <==== (00000000) 
> Dec 29 17:45:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: deflated balloon by 1279744 page(s) in 998ms (825660k/s) 
> Dec 29 17:45:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: de-activating 
> Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: XENVBD in NORMAL mode. 
> Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: XenvbdAddDevice: FDO = 0xFFFFFA804434B060 
> Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: IO hole already initialized by XEVTCHN 
> Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: Bugcheck callback already installed 
> Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: Bugcheck reason callback already installed 
> Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: RescanThread: starting 
> Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: XenvbdHwInitialize setting callback irq to 30 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: DeviceRelationsFdo: scanning targets... 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: XenbusFindVbds: found new disk (VBD 768) 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: XenbusFindVbds: ignoring cdrom (VBD 5696) 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: claiming frontend... 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: successfuly claimed device/vbd/768 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: synthesising inquiry data: default page 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: unit serial number = '62c5a501-d662-4d  ' 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: device identifier[0]: CodeSet: 'Ascii' Type: 'VendorId' Assocation: 'Device' 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: device identifier[0]: Length = 45 Data = 'XENSRC  62c5a501-d662-4d38-a75c-a280e2929297 ' 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: closing frontend... 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: backend is closed 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: created 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 03 17:53:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17: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 1Ri8Xh-0000lX-Op; Tue, 03 Jan 2012 17:52:57 +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 1Ri8Xg-0000lM-0I; Tue, 03 Jan 2012 17:52:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325613165!10356503!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 6538 invoked from network); 3 Jan 2012 17:52:47 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 17:52:47 -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
	q03HqhYQ005729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 12:52:43 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03Hqh5S005727;
	Tue, 3 Jan 2012 12:52:43 -0500
Date: Tue, 3 Jan 2012 13:52:43 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: R J <torushikeshj@gmail.com>
Message-ID: <20120103175243.GE749@andromeda.dapyr.net>
References: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
	xen-api@lists.xensource.com
Subject: Re: [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>
Content-Type: text/plain; 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 29, 2011 at 11:28:59PM +0530, R J wrote:
> 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.


Node? Meaning dom0? Or the guest? Are you using dom0_mem=max:X argument?

> I have attached the HVM boot log of successful start. Many times the node
> hangs as soon as the BalloonWorkerThread is activated.

Which PV driver is this? Is this with the other ones: GPL one, Citrix, Novell, and
Oracle as well?

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

> Dec 29 23:08:01 n4 xenguest: Determined the following parameters from xenstore:
> Dec 29 23:08:01 n4 xenguest: vcpu/number:16 vcpu/weight:0 vcpu/cap:0 nx: 1 viridian: 1 apic: 1 acpi: 1 pae: 1 acpi_s4: 0 acpi_s3: 0
> Dec 29 23:08:01 n4 xenguest: vcpu/0/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/1/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/2/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/3/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/4/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/5/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/6/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/7/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/8/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/9/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/10/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/11/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/12/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/13/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/14/affinity:0
> Dec 29 23:08:01 n4 xenguest: vcpu/15/affinity:0
> Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-control: init, 10 x 4k buffers 
> Dec 29 23:08:14 n4 tapdisk[18204]: I/O queue driver: lio 
> Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-log: started, level 0 
> Dec 29 23:08:14 n4 tapdisk[18204]: received 'attach' message (uuid = 0) 
> Dec 29 23:08:14 n4 tapdisk[18204]: sending 'attach response' message (uuid = 0) 
> Dec 29 23:08:14 n4 tapdisk[18204]: received 'open' message (uuid = 0) 
> Dec 29 23:08:14 n4 tapdisk[18204]: Loading driver 'vhd' for vbd 0 /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 0x00000000 
> Dec 29 23:08:14 n4 tapdisk[18204]: /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 version: tap 0x00010003, b: 15360, a: 307, f: 26, n: 1268376 
> Dec 29 23:08:14 n4 tapdisk[18204]: opened image /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 (1 users, state: 0x00000001, type: 4) 
> Dec 29 23:08:14 n4 tapdisk[18204]: /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b version: tap 0x00010003, b: 15360, a: 3331, f: 3307, n: 0 
> Dec 29 23:08:14 n4 tapdisk[18204]: opened image /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b (1 users, state: 0x00000003, type: 4) 
> Dec 29 23:08:14 n4 tapdisk[18204]: VBD CHAIN: 
> Dec 29 23:08:14 n4 tapdisk[18204]: /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297: type:vhd(4) storage:lvm(3) 
> Dec 29 23:08:14 n4 tapdisk[18204]: /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b: type:vhd(4) storage:lvm(3) 
> Dec 29 23:08:14 n4 tapdisk[18204]: sending 'open response' message (uuid = 0) 
> Dec 29 23:08:14 n4 vbd.uevent[add](backend/vbd/18/768): wrote /xapi/18/hotplug/vbd/768/hotplug = 'online'
> Dec 29 23:08:15 n4 vbd.uevent[add](backend/vbd/18/5696): wrote /xapi/18/hotplug/vbd/5696/hotplug = 'online'
> Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl list-ports xapi9
> Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port vif18.0 -- add-port xapi9 vif18.0 -- set interface vif18.0 "external-ids:\"xs-vm-uuid\"=\"6591a403-0eba-30b4-96a6-e02a7db0607a\"" -- set interface vif18.0 "external-ids:\"xs-vif-uuid\"=\"3be54e6d-6d13-b04b-6735-24831e5169e5\"" -- set interface vif18.0 "external-ids:\"xs-network-uuid\"=\"7051ef99-4fcb-fa61-a10e-f98456e12e90\"" -- set interface vif18.0 "external-ids:\"attached-mac\"=\"d6:6d:60:7e:45:52\""
> Dec 29 23:08:15 n4 qemu.18: domid: 18 
> Dec 29 23:08:15 n4 qemu.18: qemu: the number of cpus is 16 
> Dec 29 23:08:15 n4 qemu.18: -videoram option does not work with cirrus vga device model. Videoram set to 4M. 
> Dec 29 23:08:15 n4 HVM18[18302]: Guest uuid = 6591a403-0eba-30b4-96a6-e02a7db0607a 
> Dec 29 23:08:15 n4 HVM18[18302]: Watching /local/domain/18/logdirty/next-active 
> Dec 29 23:08:15 n4 HVM18[18302]: Watching /local/domain/0/device-model/18/command 
> Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/2 
> Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/3 
> Dec 29 23:08:15 n4 HVM18[18302]: qemu_map_cache_init nr_buckets = 4000 size 327680 
> Dec 29 23:08:15 n4 HVM18[18302]: shared page at pfn feffd 
> Dec 29 23:08:15 n4 HVM18[18302]: buffered io page at pfn feffb 
> Dec 29 23:08:15 n4 HVM18[18302]: Time offset set 0 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:00:00 (i440FX) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:00 (PIIX3) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:02:00 (Cirrus VGA) 
> Dec 29 23:08:15 n4 HVM18[18302]: populating video RAM at ff000000 
> Dec 29 23:08:15 n4 HVM18[18302]: mapping video RAM from ff000000 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:03:00 (xen-platform) 
> Dec 29 23:08:15 n4 HVM18[18302]: xs_read(/vm/6591a403-0eba-30b4-96a6-e02a7db0607a/log-throttling): read error 
> Dec 29 23:08:15 n4 HVM18[18302]: ROM memory area now RW 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:04:00 (RTL8139) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:01 (PIIX3 IDE) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:02 (USB-UHCI) 
> Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:03 (PIIX4 ACPI) 
> Dec 29 23:08:15 n4 HVM18[18302]: xs_read(/local/domain/0/device-model/18/xen_extended_power_mgmt): read error 
> Dec 29 23:08:15 n4 HVM18[18302]: releasing VM 
> Dec 29 23:08:15 n4 HVM18[18302]: xs_read(): vncpasswd get error. /vm/6591a403-0eba-30b4-96a6-e02a7db0607a/vncpasswd. 
> Dec 29 23:08:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 
> Dec 29 17:38:15 n4 last message repeated 2 times
> Dec 29 17:38:15 n4 HVM18[18302]: Triggered log-dirty buffer switch 
> Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 
> Dec 29 17:38:15 n4 HVM18[18302]: medium change watch on `hdd' (index: 1):  
> Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 
> Dec 29 17:38:15 n4 last message repeated 11 times
> Dec 29 17:38:16 n4 HVM18[18302]: cirrus vga map change while on lfb mode 
> Dec 29 23:08:16 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port tap18.0 -- add-port xapi9 tap18.0
> Dec 29 17:38:16 n4 HVM18[18302]: mapping vram to f0000000 - f0400000 
> Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RW 
> Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RO 
> Dec 29 17:38:18 n4 HVM18[18302]: cirrus: blanking the screen line_offset=3072 height=768 
> Dec 29 17:38:34 n4 HVM18[18302]: cirrus: blanking the screen line_offset=1024 height=768 
> Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol version set to 1 (drivers not blacklisted) 
> Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol 1 active 
> Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: product_id: 1 build_number: 30876 
> Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: drivers not blacklisted 
> Dec 29 17:38:37 n4 HVM18[18302]: ide_unplug_harddisk: drive 0 
> Dec 29 17:38:37 n4 HVM18[18302]: pci_dev_unplug: 00:04:00 
> Dec 29 17:38:37 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0 
> Dec 29 23:08:38 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port tap18.0
> Dec 29 17:38:38 n4 HVM18[18302]:  XEVTCHN: InstallDumpDeviceCallback: version mismatch (255 != 1) 
> Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: XenevtchnAddDevice: FDO = 0xFFFFFA8044323970 
> Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: Initialized tracing provider 
> Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: StartDeviceFdo: ====> 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: XEVTCHN: IO hole: [00000000fbfa6000,00000000fc000000) mapped at FFFFF88002965000 
> Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: KERNEL: 6.1 (build 7600) platform WIN32_NT 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: SP: NONE 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: SUITES: 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - TERMINAL 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - DATACENTER 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - SINGLEUSERTS 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: TYPE: SERVER 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: PV DRIVERS: VERSION: 5.6.0 BUILD: 30876 (Apr 30 2010.06:57:01) 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: 64-bit HVM 
> Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: ExpandGrantTable: GRANT TABLE 0: (0 - 511) at FFFFF88002966000 (fbfa7000) 
> Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: XenEnterprise product string is present 
> Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: PHYSICAL MEMORY: TOP = 00000016.8fc00000 
> Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: BalloonTargetChanged: 94371840k -> 43792384k 
> Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: activating 
> Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2230ms 
> Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 7924ms (2064k/s) 
> Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94355480k) 
> Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 1794ms 
> Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 9157ms (1786k/s) 
> Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94339120k) 
> Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5070ms 
> Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 14601ms (1120k/s) 
> Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94322760k) 
> Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 4321ms 
> Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 16052ms (1019k/s) 
> Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94306400k) 
> Dec 29 17:39:40 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4) 
> Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 6099ms 
> Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 15132ms (1081k/s) 
> Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94290040k) 
> Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 4492ms 
> Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 17206ms (950k/s) 
> Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94273680k) 
> Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2043ms 
> Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 11294ms (1448k/s) 
> Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94257320k) 
> Dec 29 17:40:27 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4) 
> Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5179ms 
> Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 15100ms (1083k/s) 
> Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94240960k) 
> Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2230ms 
> Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 12870ms (1271k/s) 
> Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94224600k) 
> Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5350ms 
> Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 13228ms (1236k/s) 
> Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94208240k) 
> Dec 29 17:41:14 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4) 
> Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 3026ms 
> Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 15490ms (1056k/s) 
> Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94191880k) 
> Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 3151ms 
> Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 13291ms (1230k/s) 
> Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94175520k) 
> Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5553ms 
> Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 16832ms (971k/s) 
> Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94159160k) 
> Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 6754ms 
> Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 18111ms (903k/s) 
> Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94142800k) 
> Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 3244ms 
> Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 18392ms (889k/s) 
> Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94126440k) 
> Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5725ms 
> Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 18454ms (886k/s) 
> Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94110080k) 
> Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 4243ms 
> Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 19453ms (841k/s) 
> Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94093720k) 
> Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 5241ms 
> Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 17206ms (950k/s) 
> Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94077360k) 
> Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 1996ms 
> Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 17253ms (948k/s) 
> Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94061000k) 
> Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 4773ms 
> Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 16286ms (1004k/s) 
> Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94044640k) 
> Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2152ms 
> Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 21231ms (770k/s) 
> Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94028280k) 
> Dec 29 17:44:40 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4) 
> Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonReleasePfnArray: ran for more than 2199ms 
> Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) in 17331ms (943k/s) 
> Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing for 1s (target = 43792384k, current = 94011920k) 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: inflated balloon by 12554884 page(s) in 32604ms (91243k/s) 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: de-activating 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: XenevtchnMapResources setting callback irq to 11 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: PV init. done 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonTargetChanged: 43792384k -> 48911360k 
> Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: activating 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: Detected new device vif/0. 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: closing device/vif/0... 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: device/vif/0 closed 
> Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: StartDeviceFdo: <==== (00000000) 
> Dec 29 17:45:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: deflated balloon by 1279744 page(s) in 998ms (825660k/s) 
> Dec 29 17:45:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: de-activating 
> Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: XENVBD in NORMAL mode. 
> Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: XenvbdAddDevice: FDO = 0xFFFFFA804434B060 
> Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: IO hole already initialized by XEVTCHN 
> Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: Bugcheck callback already installed 
> Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: Bugcheck reason callback already installed 
> Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: RescanThread: starting 
> Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: XenvbdHwInitialize setting callback irq to 30 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: DeviceRelationsFdo: scanning targets... 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: XenbusFindVbds: found new disk (VBD 768) 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: XenbusFindVbds: ignoring cdrom (VBD 5696) 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: claiming frontend... 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: successfuly claimed device/vbd/768 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: synthesising inquiry data: default page 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: unit serial number = '62c5a501-d662-4d  ' 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: device identifier[0]: CodeSet: 'Ascii' Type: 'VendorId' Assocation: 'Device' 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: device identifier[0]: Length = 45 Data = 'XENSRC  62c5a501-d662-4d38-a75c-a280e2929297 ' 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: closing frontend... 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: backend is closed 
> Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: created 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 03 17:56:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8b9-0000tZ-PF; Tue, 03 Jan 2012 17:56:31 +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 1Ri8b7-0000tK-QB
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:56:30 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325613381!9566385!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 4954 invoked from network); 3 Jan 2012 17:56:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 17: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
	q03HteTC005810
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 12:55:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03HtdBr005808;
	Tue, 3 Jan 2012 12:55:39 -0500
Date: Tue, 3 Jan 2012 13:55:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120103175539.GF749@andromeda.dapyr.net>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> 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.

Which tree are you using? The devel/xen-scsi-1.0 ?

Or the #testing one?

What do you mean: "This used to work fine in pvops" ? Can you be more
specific please.
> 
> 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?

That is the only one?
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 03 17:56:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8b9-0000tZ-PF; Tue, 03 Jan 2012 17:56:31 +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 1Ri8b7-0000tK-QB
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:56:30 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325613381!9566385!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 4954 invoked from network); 3 Jan 2012 17:56:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 17: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
	q03HteTC005810
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 12:55:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03HtdBr005808;
	Tue, 3 Jan 2012 12:55:39 -0500
Date: Tue, 3 Jan 2012 13:55:39 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120103175539.GF749@andromeda.dapyr.net>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> 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.

Which tree are you using? The devel/xen-scsi-1.0 ?

Or the #testing one?

What do you mean: "This used to work fine in pvops" ? Can you be more
specific please.
> 
> 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?

That is the only one?
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 03 17:57:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17: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 1Ri8bw-0000wh-7z; Tue, 03 Jan 2012 17:57:20 +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 1Ri8bu-0000wJ-SZ
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:57:19 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325613430!8238458!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 10893 invoked from network); 3 Jan 2012 17:57:11 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 17:57: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
	q03Hv8YA005913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 12:57:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03Hv8Xr005911;
	Tue, 3 Jan 2012 12:57:08 -0500
Date: Tue, 3 Jan 2012 13:57:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefan Kuhne <stefan.kuhne@gmx.net>
Message-ID: <20120103175708.GG749@andromeda.dapyr.net>
References: <4EFF9AF5.1070404@access.denied>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EFF9AF5.1070404@access.denied>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [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: text/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, Jan 01, 2012 at 12:29:57AM +0100, Stefan Kuhne wrote:
> Hello,
> 
> I try to run xen-4.0.3 (and 4.0.2) with linux-3.1.5.

What is the distro?

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



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 03 17:57:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17: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 1Ri8bw-0000wh-7z; Tue, 03 Jan 2012 17:57:20 +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 1Ri8bu-0000wJ-SZ
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:57:19 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325613430!8238458!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 10893 invoked from network); 3 Jan 2012 17:57:11 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 17:57: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
	q03Hv8YA005913
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 12:57:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03Hv8Xr005911;
	Tue, 3 Jan 2012 12:57:08 -0500
Date: Tue, 3 Jan 2012 13:57:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefan Kuhne <stefan.kuhne@gmx.net>
Message-ID: <20120103175708.GG749@andromeda.dapyr.net>
References: <4EFF9AF5.1070404@access.denied>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EFF9AF5.1070404@access.denied>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [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: text/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, Jan 01, 2012 at 12:29:57AM +0100, Stefan Kuhne wrote:
> Hello,
> 
> I try to run xen-4.0.3 (and 4.0.2) with linux-3.1.5.

What is the distro?

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



> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 03 17:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8cF-0000yk-La; Tue, 03 Jan 2012 17:57:39 +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 1Ri8cD-0000yB-VD
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:57:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325613451!10356979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19429 invoked from network); 3 Jan 2012 17:57:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:57:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; 
   d="scan'208";a="9797533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 17:57: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, 3 Jan 2012 17:57: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
	1Ri8c6-0000oV-Lf; Tue, 03 Jan 2012 17:57:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri8c6-0005Vc-Kp;
	Tue, 03 Jan 2012 17:57:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.16778.631463.62844@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 17:57:30 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
References: <f4ff3ce53fd2286def61.1324374813@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] 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

Roger Pau Monne writes ("[Xen-devel] [PATCH] 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.

I have some suggestions.  The basic idea would be to try to put all of
the ifdefs in one place in libxl_json.h.

> +#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

So how about:

  /* libxl_json.h */

  #ifdef HAVE_YAJL_V2
  typedef size_t libxl_yajl_length;
  ...
  #else
  typedef unsigned int libxl_yajl_length;
  ...
  #endif


  /* libxl_json.c */

  static int json_callback_number(void *opaque, const char *s,
                                  libxl_yajl_length len) {
     ...

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

  /* libxl_json.h */

  #ifdef HAVE_YAJL_V2
  ...
  static inline int libxl_yajl_alloc(...) { return yajl_alloc .... }
  ...
  #else
  ...
  static inline int libxl_yajl_alloc(...) { [version with cfg] }
  #define yajl_complete_parse yajl_parse_complete
  ...
  #endif

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 Jan 03 17:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 17:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8cF-0000yk-La; Tue, 03 Jan 2012 17:57:39 +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 1Ri8cD-0000yB-VD
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:57:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325613451!10356979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19429 invoked from network); 3 Jan 2012 17:57:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:57:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; 
   d="scan'208";a="9797533"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 17:57: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, 3 Jan 2012 17:57: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
	1Ri8c6-0000oV-Lf; Tue, 03 Jan 2012 17:57:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri8c6-0005Vc-Kp;
	Tue, 03 Jan 2012 17:57:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.16778.631463.62844@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 17:57:30 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
References: <f4ff3ce53fd2286def61.1324374813@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] 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

Roger Pau Monne writes ("[Xen-devel] [PATCH] 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.

I have some suggestions.  The basic idea would be to try to put all of
the ifdefs in one place in libxl_json.h.

> +#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

So how about:

  /* libxl_json.h */

  #ifdef HAVE_YAJL_V2
  typedef size_t libxl_yajl_length;
  ...
  #else
  typedef unsigned int libxl_yajl_length;
  ...
  #endif


  /* libxl_json.c */

  static int json_callback_number(void *opaque, const char *s,
                                  libxl_yajl_length len) {
     ...

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

  /* libxl_json.h */

  #ifdef HAVE_YAJL_V2
  ...
  static inline int libxl_yajl_alloc(...) { return yajl_alloc .... }
  ...
  #else
  ...
  static inline int libxl_yajl_alloc(...) { [version with cfg] }
  #define yajl_complete_parse yajl_parse_complete
  ...
  #endif

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 Jan 03 18:00:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:00:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8f0-0001Ln-9N; Tue, 03 Jan 2012 18:00: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 1Ri8ey-0001L1-Rg
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325613621!9540689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28006 invoked from network); 3 Jan 2012 18:00:22 -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;
	3 Jan 2012 18:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; 
   d="scan'208";a="9797585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 18:00: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, 3 Jan 2012 18:00: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
	1Ri8ep-0000pX-Pe; Tue, 03 Jan 2012 18:00:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri8ep-0005WH-Of;
	Tue, 03 Jan 2012 18:00:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.16947.747976.735762@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 18:00:19 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
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>
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>, "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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: add support for yaj=
l 2.x"):
> On Thu, 2011-12-22 at 16:41 +0000, Roger Pau Monn=E9 wrote:
> > 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?

For now, I think we should not add more stuff to the critical path for
Xen 4.2.  But after then we should switch to autoconf I think.  (I
don't approve of automake.)

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:00:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:00:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8f0-0001Ln-9N; Tue, 03 Jan 2012 18:00: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 1Ri8ey-0001L1-Rg
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:00:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325613621!9540689!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28006 invoked from network); 3 Jan 2012 18:00:22 -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;
	3 Jan 2012 18:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; 
   d="scan'208";a="9797585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 18:00: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, 3 Jan 2012 18:00: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
	1Ri8ep-0000pX-Pe; Tue, 03 Jan 2012 18:00:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri8ep-0005WH-Of;
	Tue, 03 Jan 2012 18:00:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.16947.747976.735762@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 18:00:19 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
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>
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>, "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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: add support for yaj=
l 2.x"):
> On Thu, 2011-12-22 at 16:41 +0000, Roger Pau Monn=E9 wrote:
> > 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?

For now, I think we should not add more stuff to the critical path for
Xen 4.2.  But after then we should switch to autoconf I think.  (I
don't approve of automake.)

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:01:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8fb-0001Qn-O5; Tue, 03 Jan 2012 18:01: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 1Ri8fa-0001QS-BQ
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:01:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325613632!46969118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7618 invoked from network); 3 Jan 2012 18:00: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;
	3 Jan 2012 18:00:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; 
   d="scan'208";a="9797593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 18:01:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Jan 2012 18:01: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
	1Ri8fY-0000pl-My; Tue, 03 Jan 2012 18:01:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri8fY-0005WY-M8;
	Tue, 03 Jan 2012 18:01:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.16992.669043.281065@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 18:01:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1324637110.7877.139.camel@zakaz.uk.xensource.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>
	<1324637110.7877.139.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>, "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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x"):
> I'm not sure if we have any resident autotools experts but I'm sure we
> can muddle through.

I have written autoconf macros, a long time ago.  Does that count ? :-)

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:01:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:01:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8fb-0001Qn-O5; Tue, 03 Jan 2012 18:01: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 1Ri8fa-0001QS-BQ
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:01:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325613632!46969118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTA5Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7618 invoked from network); 3 Jan 2012 18:00: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;
	3 Jan 2012 18:00:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; 
   d="scan'208";a="9797593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	03 Jan 2012 18:01:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 3 Jan 2012 18:01: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
	1Ri8fY-0000pl-My; Tue, 03 Jan 2012 18:01:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ri8fY-0005WY-M8;
	Tue, 03 Jan 2012 18:01:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20227.16992.669043.281065@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 18:01:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1324637110.7877.139.camel@zakaz.uk.xensource.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>
	<1324637110.7877.139.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>, "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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] libxl: add support for yajl 2.x"):
> I'm not sure if we have any resident autotools experts but I'm sure we
> can muddle through.

I have written autoconf macros, a long time ago.  Does that count ? :-)

Ian.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:09:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18: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 1Ri8nf-0001pV-P4; Tue, 03 Jan 2012 18:09:27 +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 1Ri8ne-0001pQ-B9
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:09:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325614120!50761245!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 20837 invoked from network); 3 Jan 2012 18:08:42 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 18:08:42 -0000
Received: by pbbb11 with SMTP id b11so56952479pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 10:09:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=3kYRx19zz+UfG7dveYPYAQPJ4cVKlBHBDn9w0tWX8tI=;
	b=nDII1LiZcLILVZiK/yYo5fX/K+lV6sQ99niXfFFNQ2Mo/xtl/STZgQ0PzW+l3AhQJe
	jAOGdxTMVvCrxieYYJm5NUWmGjCkxcf0/xfI2TMXXKEWEDNTIZGsonVBAN4oBBRf6+L+
	3UqFNMdNSztd+aY00JTKmdVSlLqRArH7QXyb0=
MIME-Version: 1.0
Received: by 10.68.75.233 with SMTP id f9mr134563222pbw.10.1325614163151; Tue,
	03 Jan 2012 10:09:23 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 10:09:23 -0800 (PST)
In-Reply-To: <20227.16778.631463.62844@mariner.uk.xensource.com>
References: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
	<20227.16778.631463.62844@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 19:09:23 +0100
X-Google-Sender-Auth: YJzOx1mQde2RVJIzz8c7ItDslpQ
Message-ID: <CAPLaKK7H44CpvDfgLOhr+80rbHuGgDHz4z9iZE7OQYhqVBfSfQ@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] 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

MjAxMi8xLzMgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IFJvZ2Vy
IFBhdSBNb25uZSB3cml0ZXMgKCJbWGVuLWRldmVsXSBbUEFUQ0hdIGxpYnhsOiBhZGQgc3VwcG9y
dCBmb3IgeWFqbCAyLngiKToKPj4gVGhpcyBwYXRjaCBhZGRzIHN1cHBvcnQgZm9yIHlhamwgdmVy
c2lvbnMgMi54LCB3aGlsZSByZXRhaW5pbmcgMS54Cj4+IGNvbXBhdGliaWxpdHkuIFRoaXMgcGF0
Y2ggYWRkcyBxdWl0ZSBhIGxvdCBvZiAjaWZkZWZzIGFsbCBvdmVyIHRoZQo+PiBqc29uIGNvZGUs
IHNvIEknbSBvcGVuIHRvIHN1Z2dlc3Rpb25zIGlmIHRoZXJlJ3MgYSBiZXR0ZXIgd2F5IHRvCj4+
IGhhbmRsZSB0aGlzLgo+Cj4gSSBoYXZlIHNvbWUgc3VnZ2VzdGlvbnMuIMKgVGhlIGJhc2ljIGlk
ZWEgd291bGQgYmUgdG8gdHJ5IHRvIHB1dCBhbGwgb2YKPiB0aGUgaWZkZWZzIGluIG9uZSBwbGFj
ZSBpbiBsaWJ4bF9qc29uLmguCj4KPj4gKyNpZmRlZiBIQVZFX1lBSkxfVjIKPj4gK3N0YXRpYyBp
bnQganNvbl9jYWxsYmFja19udW1iZXIodm9pZCAqb3BhcXVlLCBjb25zdCBjaGFyICpzLCBzaXpl
X3QgbGVuKQo+PiArI2Vsc2UKPj4gwqBzdGF0aWMgaW50IGpzb25fY2FsbGJhY2tfbnVtYmVyKHZv
aWQgKm9wYXF1ZSwgY29uc3QgY2hhciAqcywgdW5zaWduZWQgaW50IGxlbikKPj4gKyNlbmRpZgo+
Cj4gU28gaG93IGFib3V0Ogo+Cj4gwqAvKiBsaWJ4bF9qc29uLmggKi8KPgo+IMKgI2lmZGVmIEhB
VkVfWUFKTF9WMgo+IMKgdHlwZWRlZiBzaXplX3QgbGlieGxfeWFqbF9sZW5ndGg7Cj4gwqAuLi4K
PiDCoCNlbHNlCj4gwqB0eXBlZGVmIHVuc2lnbmVkIGludCBsaWJ4bF95YWpsX2xlbmd0aDsKPiDC
oC4uLgo+IMKgI2VuZGlmCj4KPgo+IMKgLyogbGlieGxfanNvbi5jICovCj4KPiDCoHN0YXRpYyBp
bnQganNvbl9jYWxsYmFja19udW1iZXIodm9pZCAqb3BhcXVlLCBjb25zdCBjaGFyICpzLAo+IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGlieGxfeWFq
bF9sZW5ndGggbGVuKSB7Cj4gwqAgwqAgLi4uCj4KPj4gKyNpZmRlZiBIQVZFX1lBSkxfVjIKPj4g
KyDCoCDCoCDCoCDCoHlhamxfY3R4LmhhbmQgPSB5YWpsX2FsbG9jKCZjYWxsYmFja3MsIE5VTEws
ICZ5YWpsX2N0eCk7Cj4+ICsjZWxzZQo+PiDCoCDCoCDCoCDCoCDCoHlhamxfcGFyc2VyX2NvbmZp
ZyBjZmcgPSB7Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgLmFsbG93Q29tbWVudHMgPSAxLAo+PiDC
oCDCoCDCoCDCoCDCoCDCoCDCoC5jaGVja1VURjggPSAxLAo+PiDCoCDCoCDCoCDCoCDCoH07Cj4+
IMKgIMKgIMKgIMKgIMKgeWFqbF9jdHguaGFuZCA9IHlhamxfYWxsb2MoJmNhbGxiYWNrcywgJmNm
ZywgTlVMTCwgJnlhamxfY3R4KTsKPj4gKyNlbmRpZgo+IC4uLgo+PiDCoCDCoCDCoHN0YXR1cyA9
IHlhamxfcGFyc2UoeWFqbF9jdHguaGFuZCwgKGNvbnN0IHVuc2lnbmVkIGNoYXIgKilzLCBzdHJs
ZW4ocykpOwo+PiDCoCDCoCDCoGlmIChzdGF0dXMgIT0geWFqbF9zdGF0dXNfb2spCj4+IMKgIMKg
IMKgIMKgIMKgZ290byBvdXQ7Cj4+ICsKPgo+IMKgLyogbGlieGxfanNvbi5oICovCj4KPiDCoCNp
ZmRlZiBIQVZFX1lBSkxfVjIKPiDCoC4uLgo+IMKgc3RhdGljIGlubGluZSBpbnQgbGlieGxfeWFq
bF9hbGxvYyguLi4pIHsgcmV0dXJuIHlhamxfYWxsb2MgLi4uLiB9Cj4gwqAuLi4KPiDCoCNlbHNl
Cj4gwqAuLi4KPiDCoHN0YXRpYyBpbmxpbmUgaW50IGxpYnhsX3lhamxfYWxsb2MoLi4uKSB7IFt2
ZXJzaW9uIHdpdGggY2ZnXSB9Cj4gwqAjZGVmaW5lIHlhamxfY29tcGxldGVfcGFyc2UgeWFqbF9w
YXJzZV9jb21wbGV0ZQo+IMKgLi4uCj4gwqAjZW5kaWYKPgo+IGV0Yy4KCkkgaGF2ZW4ndCByZWFs
bHkgdGhvdWdoIG9mIHRoaXMgYW55bW9yZSwgYnV0IHRoaXMgc2VlbXMgbXVjaCBtb3JlCmFwcHJv
cHJpYXRlIGFuZCBsZXNzIGludHJ1c2l2ZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:09:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18: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 1Ri8nf-0001pV-P4; Tue, 03 Jan 2012 18:09:27 +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 1Ri8ne-0001pQ-B9
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:09:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325614120!50761245!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 20837 invoked from network); 3 Jan 2012 18:08:42 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 18:08:42 -0000
Received: by pbbb11 with SMTP id b11so56952479pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 10:09:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=3kYRx19zz+UfG7dveYPYAQPJ4cVKlBHBDn9w0tWX8tI=;
	b=nDII1LiZcLILVZiK/yYo5fX/K+lV6sQ99niXfFFNQ2Mo/xtl/STZgQ0PzW+l3AhQJe
	jAOGdxTMVvCrxieYYJm5NUWmGjCkxcf0/xfI2TMXXKEWEDNTIZGsonVBAN4oBBRf6+L+
	3UqFNMdNSztd+aY00JTKmdVSlLqRArH7QXyb0=
MIME-Version: 1.0
Received: by 10.68.75.233 with SMTP id f9mr134563222pbw.10.1325614163151; Tue,
	03 Jan 2012 10:09:23 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 10:09:23 -0800 (PST)
In-Reply-To: <20227.16778.631463.62844@mariner.uk.xensource.com>
References: <f4ff3ce53fd2286def61.1324374813@alpine.localdomain>
	<20227.16778.631463.62844@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 19:09:23 +0100
X-Google-Sender-Auth: YJzOx1mQde2RVJIzz8c7ItDslpQ
Message-ID: <CAPLaKK7H44CpvDfgLOhr+80rbHuGgDHz4z9iZE7OQYhqVBfSfQ@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] 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

MjAxMi8xLzMgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IFJvZ2Vy
IFBhdSBNb25uZSB3cml0ZXMgKCJbWGVuLWRldmVsXSBbUEFUQ0hdIGxpYnhsOiBhZGQgc3VwcG9y
dCBmb3IgeWFqbCAyLngiKToKPj4gVGhpcyBwYXRjaCBhZGRzIHN1cHBvcnQgZm9yIHlhamwgdmVy
c2lvbnMgMi54LCB3aGlsZSByZXRhaW5pbmcgMS54Cj4+IGNvbXBhdGliaWxpdHkuIFRoaXMgcGF0
Y2ggYWRkcyBxdWl0ZSBhIGxvdCBvZiAjaWZkZWZzIGFsbCBvdmVyIHRoZQo+PiBqc29uIGNvZGUs
IHNvIEknbSBvcGVuIHRvIHN1Z2dlc3Rpb25zIGlmIHRoZXJlJ3MgYSBiZXR0ZXIgd2F5IHRvCj4+
IGhhbmRsZSB0aGlzLgo+Cj4gSSBoYXZlIHNvbWUgc3VnZ2VzdGlvbnMuIMKgVGhlIGJhc2ljIGlk
ZWEgd291bGQgYmUgdG8gdHJ5IHRvIHB1dCBhbGwgb2YKPiB0aGUgaWZkZWZzIGluIG9uZSBwbGFj
ZSBpbiBsaWJ4bF9qc29uLmguCj4KPj4gKyNpZmRlZiBIQVZFX1lBSkxfVjIKPj4gK3N0YXRpYyBp
bnQganNvbl9jYWxsYmFja19udW1iZXIodm9pZCAqb3BhcXVlLCBjb25zdCBjaGFyICpzLCBzaXpl
X3QgbGVuKQo+PiArI2Vsc2UKPj4gwqBzdGF0aWMgaW50IGpzb25fY2FsbGJhY2tfbnVtYmVyKHZv
aWQgKm9wYXF1ZSwgY29uc3QgY2hhciAqcywgdW5zaWduZWQgaW50IGxlbikKPj4gKyNlbmRpZgo+
Cj4gU28gaG93IGFib3V0Ogo+Cj4gwqAvKiBsaWJ4bF9qc29uLmggKi8KPgo+IMKgI2lmZGVmIEhB
VkVfWUFKTF9WMgo+IMKgdHlwZWRlZiBzaXplX3QgbGlieGxfeWFqbF9sZW5ndGg7Cj4gwqAuLi4K
PiDCoCNlbHNlCj4gwqB0eXBlZGVmIHVuc2lnbmVkIGludCBsaWJ4bF95YWpsX2xlbmd0aDsKPiDC
oC4uLgo+IMKgI2VuZGlmCj4KPgo+IMKgLyogbGlieGxfanNvbi5jICovCj4KPiDCoHN0YXRpYyBp
bnQganNvbl9jYWxsYmFja19udW1iZXIodm9pZCAqb3BhcXVlLCBjb25zdCBjaGFyICpzLAo+IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbGlieGxfeWFq
bF9sZW5ndGggbGVuKSB7Cj4gwqAgwqAgLi4uCj4KPj4gKyNpZmRlZiBIQVZFX1lBSkxfVjIKPj4g
KyDCoCDCoCDCoCDCoHlhamxfY3R4LmhhbmQgPSB5YWpsX2FsbG9jKCZjYWxsYmFja3MsIE5VTEws
ICZ5YWpsX2N0eCk7Cj4+ICsjZWxzZQo+PiDCoCDCoCDCoCDCoCDCoHlhamxfcGFyc2VyX2NvbmZp
ZyBjZmcgPSB7Cj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgLmFsbG93Q29tbWVudHMgPSAxLAo+PiDC
oCDCoCDCoCDCoCDCoCDCoCDCoC5jaGVja1VURjggPSAxLAo+PiDCoCDCoCDCoCDCoCDCoH07Cj4+
IMKgIMKgIMKgIMKgIMKgeWFqbF9jdHguaGFuZCA9IHlhamxfYWxsb2MoJmNhbGxiYWNrcywgJmNm
ZywgTlVMTCwgJnlhamxfY3R4KTsKPj4gKyNlbmRpZgo+IC4uLgo+PiDCoCDCoCDCoHN0YXR1cyA9
IHlhamxfcGFyc2UoeWFqbF9jdHguaGFuZCwgKGNvbnN0IHVuc2lnbmVkIGNoYXIgKilzLCBzdHJs
ZW4ocykpOwo+PiDCoCDCoCDCoGlmIChzdGF0dXMgIT0geWFqbF9zdGF0dXNfb2spCj4+IMKgIMKg
IMKgIMKgIMKgZ290byBvdXQ7Cj4+ICsKPgo+IMKgLyogbGlieGxfanNvbi5oICovCj4KPiDCoCNp
ZmRlZiBIQVZFX1lBSkxfVjIKPiDCoC4uLgo+IMKgc3RhdGljIGlubGluZSBpbnQgbGlieGxfeWFq
bF9hbGxvYyguLi4pIHsgcmV0dXJuIHlhamxfYWxsb2MgLi4uLiB9Cj4gwqAuLi4KPiDCoCNlbHNl
Cj4gwqAuLi4KPiDCoHN0YXRpYyBpbmxpbmUgaW50IGxpYnhsX3lhamxfYWxsb2MoLi4uKSB7IFt2
ZXJzaW9uIHdpdGggY2ZnXSB9Cj4gwqAjZGVmaW5lIHlhamxfY29tcGxldGVfcGFyc2UgeWFqbF9w
YXJzZV9jb21wbGV0ZQo+IMKgLi4uCj4gwqAjZW5kaWYKPgo+IGV0Yy4KCkkgaGF2ZW4ndCByZWFs
bHkgdGhvdWdoIG9mIHRoaXMgYW55bW9yZSwgYnV0IHRoaXMgc2VlbXMgbXVjaCBtb3JlCmFwcHJv
cHJpYXRlIGFuZCBsZXNzIGludHJ1c2l2ZS4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:14:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18: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 1Ri8sV-0001yP-J5; Tue, 03 Jan 2012 18:14: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 1Ri8sU-0001yF-9U
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:14:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325614458!9461706!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 17602 invoked from network); 3 Jan 2012 18:14:20 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 18:14:20 -0000
Received: by daec6 with SMTP id c6so62440187dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 10:14: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
	:content-transfer-encoding;
	bh=irP70L8KBO16XOQ4GDjDRgSjLk8Z6ZIoC2gEDCb/3CI=;
	b=VL9zH+utS1b+aBM66n685cbciCDOhgvflBsNPnQ8mOqoyRFIhIowaemrhPJ1mMcocb
	w786zZCAdwkMKjYISR4GZ4S6sXtJZCxHvSE1QpHcq5qv+qL3g0sfzyRFc/Y0E4nrhR+c
	ACuP5dYs/L4fFMzYBC2IGhYtQcRWFJxbgAI/w=
MIME-Version: 1.0
Received: by 10.68.72.164 with SMTP id e4mr132544404pbv.95.1325614456223; Tue,
	03 Jan 2012 10:14:16 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 10:14:16 -0800 (PST)
In-Reply-To: <20227.16992.669043.281065@mariner.uk.xensource.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>
	<1324637110.7877.139.camel@zakaz.uk.xensource.com>
	<20227.16992.669043.281065@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 19:14:16 +0100
X-Google-Sender-Auth: ZgmDSPVftOOGcGesoYFBAdHGrRU
Message-ID: <CAPLaKK6RTt=_YuzeeK_oL4A-q=0JDLx70wWZ6RcdeOZ5WNVP6g@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

MjAxMi8xLzMgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IElhbiBD
YW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDogYWRkIHN1
cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+IEknbSBub3Qgc3VyZSBpZiB3ZSBoYXZlIGFueSByZXNp
ZGVudCBhdXRvdG9vbHMgZXhwZXJ0cyBidXQgSSdtIHN1cmUgd2UKPj4gY2FuIG11ZGRsZSB0aHJv
dWdoLgo+Cj4gSSBoYXZlIHdyaXR0ZW4gYXV0b2NvbmYgbWFjcm9zLCBhIGxvbmcgdGltZSBhZ28u
IMKgRG9lcyB0aGF0IGNvdW50ID8gOi0pCgpJJ3ZlIHN0YXJ0ZWQgdG8gY3JlYXRlIGEgYmFzaWMg
Y29uZmlndXJlLmFjLCBidXQgcmVhbGx5IHRoaXMgYXV0b2NvbmYKdGhpbmcgaXMgcGlzc2luZyBt
ZSBvZmYuIE15IGlkZWEgd2FzIHRvIGdlbmVyYXRlIGEgY29uZmlnLmggYW5kCnJlcGxhY2UgQ29u
ZmlnLm1rIChhdCBsZWFzdCBzb21lIHBhcnRzKSB3aXRoIHRoZSBvdXRwdXQgb2YgY29uZmlndXJl
CmFsc28sIGRvZXMgdGhpcyBzb3VuZCByZWFzb25hYmxlPwoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:14:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18: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 1Ri8sV-0001yP-J5; Tue, 03 Jan 2012 18:14: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 1Ri8sU-0001yF-9U
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:14:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325614458!9461706!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 17602 invoked from network); 3 Jan 2012 18:14:20 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 18:14:20 -0000
Received: by daec6 with SMTP id c6so62440187dae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 10:14: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
	:content-transfer-encoding;
	bh=irP70L8KBO16XOQ4GDjDRgSjLk8Z6ZIoC2gEDCb/3CI=;
	b=VL9zH+utS1b+aBM66n685cbciCDOhgvflBsNPnQ8mOqoyRFIhIowaemrhPJ1mMcocb
	w786zZCAdwkMKjYISR4GZ4S6sXtJZCxHvSE1QpHcq5qv+qL3g0sfzyRFc/Y0E4nrhR+c
	ACuP5dYs/L4fFMzYBC2IGhYtQcRWFJxbgAI/w=
MIME-Version: 1.0
Received: by 10.68.72.164 with SMTP id e4mr132544404pbv.95.1325614456223; Tue,
	03 Jan 2012 10:14:16 -0800 (PST)
Received: by 10.142.213.6 with HTTP; Tue, 3 Jan 2012 10:14:16 -0800 (PST)
In-Reply-To: <20227.16992.669043.281065@mariner.uk.xensource.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>
	<1324637110.7877.139.camel@zakaz.uk.xensource.com>
	<20227.16992.669043.281065@mariner.uk.xensource.com>
Date: Tue, 3 Jan 2012 19:14:16 +0100
X-Google-Sender-Auth: ZgmDSPVftOOGcGesoYFBAdHGrRU
Message-ID: <CAPLaKK6RTt=_YuzeeK_oL4A-q=0JDLx70wWZ6RcdeOZ5WNVP6g@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

MjAxMi8xLzMgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IElhbiBD
YW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDogYWRkIHN1
cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+IEknbSBub3Qgc3VyZSBpZiB3ZSBoYXZlIGFueSByZXNp
ZGVudCBhdXRvdG9vbHMgZXhwZXJ0cyBidXQgSSdtIHN1cmUgd2UKPj4gY2FuIG11ZGRsZSB0aHJv
dWdoLgo+Cj4gSSBoYXZlIHdyaXR0ZW4gYXV0b2NvbmYgbWFjcm9zLCBhIGxvbmcgdGltZSBhZ28u
IMKgRG9lcyB0aGF0IGNvdW50ID8gOi0pCgpJJ3ZlIHN0YXJ0ZWQgdG8gY3JlYXRlIGEgYmFzaWMg
Y29uZmlndXJlLmFjLCBidXQgcmVhbGx5IHRoaXMgYXV0b2NvbmYKdGhpbmcgaXMgcGlzc2luZyBt
ZSBvZmYuIE15IGlkZWEgd2FzIHRvIGdlbmVyYXRlIGEgY29uZmlnLmggYW5kCnJlcGxhY2UgQ29u
ZmlnLm1rIChhdCBsZWFzdCBzb21lIHBhcnRzKSB3aXRoIHRoZSBvdXRwdXQgb2YgY29uZmlndXJl
CmFsc28sIGRvZXMgdGhpcyBzb3VuZCByZWFzb25hYmxlPwoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:20:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8xz-00029u-Bs; Tue, 03 Jan 2012 18:20: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 1Ri8xy-00029j-Qu
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:20:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325614798!7715287!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 20780 invoked from network); 3 Jan 2012 18:20:00 -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; 3 Jan 2012 18:20: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
	q03IJra2007621
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 13:19:53 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03IJr8c007619;
	Tue, 3 Jan 2012 13:19:53 -0500
Date: Tue, 3 Jan 2012 14:19:53 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120103181953.GH749@andromeda.dapyr.net>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
	<20120102160611.GB12529@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120102160611.GB12529@aepfle.de>
User-Agent: Mutt/1.5.9i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, 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 Mon, Jan 02, 2012 at 05:06:12PM +0100, Olaf Hering wrote:
> On Sat, Dec 17, Konrad Rzeszutek Wilk wrote:
> 
> > > +#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?
> 
> I dont remember why I turned this into a macro instead of 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.
> 
> A multiline macro needs backslashes at the end.

Yes. I should have been more specific. The '\' are out of aligment.
> 
> > So why msleep? Why not go for a proper yield? Call the safe_halt()
> > function?
> 
> It needs some interuptible sleep, whatever is best in this context.
> 
> > > +		__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..
> 
> Or if something in the paging paths goes wrong.
> 
> > I would recommend you use 'WARN' here and include tons of details.
> > This is a pretty serious issues, is it not?
> 
> Either the host is really busy and cant page-in quick enough even after
> so-many seconds. Or something in the pager/hypervisor does not work
> right. In either case, a backtrace wont help much as it does only cause
> noise. The printk below prints the function name (I think thats the
> reason why it is a macro) to give some hint. 

OK, we can do this differently. Make a function that does the majority
of this, and one of the arguments is a 'const char *name' and use a
macro that does:

#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)
real_function(__func__, __Hcop, __HCarg_p,...)

or such.

If this problem does occur (the swapper died in dom0) should the
printk at least use printk_ratelimited so that we don't cause too much
noise?
> 
> > > +		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" ?
> 
> The caller has to deal with the various !GNTST_okay states anyway, this
> patch wont change that fact.

Ok, so then we don't really need the printk right? As the caller
would presumarily do the right thing and also print the error?

> 
> 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 Jan 03 18:20:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:20:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri8xz-00029u-Bs; Tue, 03 Jan 2012 18:20: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 1Ri8xy-00029j-Qu
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:20:07 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325614798!7715287!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 20780 invoked from network); 3 Jan 2012 18:20:00 -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; 3 Jan 2012 18:20: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
	q03IJra2007621
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 3 Jan 2012 13:19:53 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q03IJr8c007619;
	Tue, 3 Jan 2012 13:19:53 -0500
Date: Tue, 3 Jan 2012 14:19:53 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120103181953.GH749@andromeda.dapyr.net>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
	<20120102160611.GB12529@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120102160611.GB12529@aepfle.de>
User-Agent: Mutt/1.5.9i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, 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 Mon, Jan 02, 2012 at 05:06:12PM +0100, Olaf Hering wrote:
> On Sat, Dec 17, Konrad Rzeszutek Wilk wrote:
> 
> > > +#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?
> 
> I dont remember why I turned this into a macro instead of 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.
> 
> A multiline macro needs backslashes at the end.

Yes. I should have been more specific. The '\' are out of aligment.
> 
> > So why msleep? Why not go for a proper yield? Call the safe_halt()
> > function?
> 
> It needs some interuptible sleep, whatever is best in this context.
> 
> > > +		__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..
> 
> Or if something in the paging paths goes wrong.
> 
> > I would recommend you use 'WARN' here and include tons of details.
> > This is a pretty serious issues, is it not?
> 
> Either the host is really busy and cant page-in quick enough even after
> so-many seconds. Or something in the pager/hypervisor does not work
> right. In either case, a backtrace wont help much as it does only cause
> noise. The printk below prints the function name (I think thats the
> reason why it is a macro) to give some hint. 

OK, we can do this differently. Make a function that does the majority
of this, and one of the arguments is a 'const char *name' and use a
macro that does:

#define gnttab_check_GNTST_eagain_while(__HCop, __HCarg_p)
real_function(__func__, __Hcop, __HCarg_p,...)

or such.

If this problem does occur (the swapper died in dom0) should the
printk at least use printk_ratelimited so that we don't cause too much
noise?
> 
> > > +		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" ?
> 
> The caller has to deal with the various !GNTST_okay states anyway, this
> patch wont change that fact.

Ok, so then we don't really need the printk right? As the caller
would presumarily do the right thing and also print the error?

> 
> 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 Jan 03 18:44:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18: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 1Ri9L9-0002Sz-Rn; Tue, 03 Jan 2012 18:44:03 +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 1Ri9L7-0002Su-A1
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:44:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325616234!9435774!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjE5ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjE5ODc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20669 invoked from network); 3 Jan 2012 18:43:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Jan 2012 18:43:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325616234; l=935;
	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=9TIzohJbGL68nycTaRZJgRlJoSc=;
	b=vsie1LQ6Nsu2V/SSTkj0mE+N/QHGh6sS2JMguBBYrt1Fjt6b63we0Ep7YbEZoJfD/oV
	g5v0zavWOpmIOCEsX/uLex9o6yNhVyH5z3wlaN/sdWMag+wgGgwauZO0MAMvh33a4/rLY
	DbYyzmNWbJPCG2DYqposuJs8Oswkwv78Wy0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0MEvPR
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-216.pools.arcor-ip.net [88.65.73.216])
	by post.strato.de (mrclete mo32) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V0150bo03GUnB9 ;
	Tue, 3 Jan 2012 19:40:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4CBBD18637; Tue,  3 Jan 2012 19:40:45 +0100 (CET)
Date: Tue, 3 Jan 2012 19:40:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120103184045.GA26720@aepfle.de>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
	<20120102160611.GB12529@aepfle.de>
	<20120103181953.GH749@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120103181953.GH749@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, 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 Tue, Jan 03, Konrad Rzeszutek Wilk wrote:

> If this problem does occur (the swapper died in dom0) should the
> printk at least use printk_ratelimited so that we don't cause too much
> noise?

I remember there was no flood because the guest was stuck anyway. But
see below.

> > The caller has to deal with the various !GNTST_okay states anyway, this
> > patch wont change that fact.
> 
> Ok, so then we don't really need the printk right? As the caller
> would presumarily do the right thing and also print the error?

I think its more a debug thing, so that I knew something bad happend.
And at that time it was just helpful to get me some understanding of the
code flow. Since now that part of the paging code is reasonable
debugged, the printk is not really needed anymore.
Instead the code who uses these new functionality should have proper
error handling and print reasonable diagnostic messages.

Olaf

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:44:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18: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 1Ri9L9-0002Sz-Rn; Tue, 03 Jan 2012 18:44:03 +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 1Ri9L7-0002Su-A1
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:44:01 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325616234!9435774!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjE5ODc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjE5ODc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20669 invoked from network); 3 Jan 2012 18:43:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 3 Jan 2012 18:43:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325616234; l=935;
	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=9TIzohJbGL68nycTaRZJgRlJoSc=;
	b=vsie1LQ6Nsu2V/SSTkj0mE+N/QHGh6sS2JMguBBYrt1Fjt6b63we0Ep7YbEZoJfD/oV
	g5v0zavWOpmIOCEsX/uLex9o6yNhVyH5z3wlaN/sdWMag+wgGgwauZO0MAMvh33a4/rLY
	DbYyzmNWbJPCG2DYqposuJs8Oswkwv78Wy0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0MEvPR
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-216.pools.arcor-ip.net [88.65.73.216])
	by post.strato.de (mrclete mo32) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V0150bo03GUnB9 ;
	Tue, 3 Jan 2012 19:40:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 4CBBD18637; Tue,  3 Jan 2012 19:40:45 +0100 (CET)
Date: Tue, 3 Jan 2012 19:40:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120103184045.GA26720@aepfle.de>
References: <1324092141-9730-1-git-send-email-adin@scannell.ca>
	<1324092141-9730-3-git-send-email-adin@scannell.ca>
	<20111217143015.GD14816@konrad-lan>
	<20120102160611.GB12529@aepfle.de>
	<20120103181953.GH749@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120103181953.GH749@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com,
	Adin Scannell <adin@scannell.ca>, 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 Tue, Jan 03, Konrad Rzeszutek Wilk wrote:

> If this problem does occur (the swapper died in dom0) should the
> printk at least use printk_ratelimited so that we don't cause too much
> noise?

I remember there was no flood because the guest was stuck anyway. But
see below.

> > The caller has to deal with the various !GNTST_okay states anyway, this
> > patch wont change that fact.
> 
> Ok, so then we don't really need the printk right? As the caller
> would presumarily do the right thing and also print the error?

I think its more a debug thing, so that I knew something bad happend.
And at that time it was just helpful to get me some understanding of the
code flow. Since now that part of the paging code is reasonable
debugged, the printk is not really needed anymore.
Instead the code who uses these new functionality should have proper
error handling and print reasonable diagnostic messages.

Olaf

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 18:45:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri9Lt-0002Uj-9K; Tue, 03 Jan 2012 18:44: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 1Ri9Ls-0002UO-3O
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:44:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325616280!9450145!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4NTU4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5738 invoked from network); 3 Jan 2012 18:44:41 -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; 3 Jan 2012 18:44: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
	q03Ii3J0017773
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 18:44:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03Ii1a6024193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 18:44:01 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
	q03IhwHO015540; Tue, 3 Jan 2012 12:43:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 10:43:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1D7F940331; Tue,  3 Jan 2012 13:42:26 -0500 (EST)
Date: Tue, 3 Jan 2012 13:42:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julia Lawall <julia@diku.dk>
Message-ID: <20120103184226.GA27508@phenom.dumpdata.com>
References: <1324661974-17281-4-git-send-email-julia@diku.dk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324661974-17281-4-git-send-email-julia@diku.dk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F034C74.0142,ss=1,re=0.000,fgs=0
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: Re: [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>
Content-Type: text/plain; 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 06:39:29PM +0100, Julia Lawall wrote:
> 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.

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 Jan 03 18:45:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri9Lt-0002Uj-9K; Tue, 03 Jan 2012 18:44: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 1Ri9Ls-0002UO-3O
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:44:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325616280!9450145!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4NTU4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5738 invoked from network); 3 Jan 2012 18:44:41 -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; 3 Jan 2012 18:44: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
	q03Ii3J0017773
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 18:44:04 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03Ii1a6024193
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 18:44:01 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
	q03IhwHO015540; Tue, 3 Jan 2012 12:43:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 10:43:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1D7F940331; Tue,  3 Jan 2012 13:42:26 -0500 (EST)
Date: Tue, 3 Jan 2012 13:42:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Julia Lawall <julia@diku.dk>
Message-ID: <20120103184226.GA27508@phenom.dumpdata.com>
References: <1324661974-17281-4-git-send-email-julia@diku.dk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324661974-17281-4-git-send-email-julia@diku.dk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F034C74.0142,ss=1,re=0.000,fgs=0
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: Re: [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>
Content-Type: text/plain; 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 06:39:29PM +0100, Julia Lawall wrote:
> 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.

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 Jan 03 18:50:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:50:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri9Ra-0002lM-2z; Tue, 03 Jan 2012 18:50: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 1Ri9RY-0002l5-3F
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:50:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325616632!5845074!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4NTU4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2737 invoked from network); 3 Jan 2012 18:50:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 18:50:34 -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
	q03Ing7M024011
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 18:49:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03IneTA002528
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 18:49:41 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q03IndYv019410; Tue, 3 Jan 2012 12:49:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 10:49:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A87ED40332; Tue,  3 Jan 2012 13:48:07 -0500 (EST)
Date: Tue, 3 Jan 2012 13:48:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120103184807.GB27537@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>
	<20120102160611.GB12529@aepfle.de>
	<20120103181953.GH749@andromeda.dapyr.net>
	<20120103184045.GA26720@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120103184045.GA26720@aepfle.de>
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.4F034DC7.0054,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Adin Scannell <adin@scannell.ca>,
	andres@gridcentric.ca, JBeulich@suse.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, 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 Tue, Jan 03, 2012 at 07:40:45PM +0100, Olaf Hering wrote:
> On Tue, Jan 03, Konrad Rzeszutek Wilk wrote:
> 
> > If this problem does occur (the swapper died in dom0) should the
> > printk at least use printk_ratelimited so that we don't cause too much
> > noise?
> 
> I remember there was no flood because the guest was stuck anyway. But
> see below.
> 
> > > The caller has to deal with the various !GNTST_okay states anyway, this
> > > patch wont change that fact.
> > 
> > Ok, so then we don't really need the printk right? As the caller
> > would presumarily do the right thing and also print the error?
> 
> I think its more a debug thing, so that I knew something bad happend.
> And at that time it was just helpful to get me some understanding of the
> code flow. Since now that part of the paging code is reasonable
> debugged, the printk is not really needed anymore.

OK.
> Instead the code who uses these new functionality should have proper
> error handling and print reasonable diagnostic messages.

Excellent. So lets remove that printk(KERN_ERR).

Thanks!
> 
> 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 Jan 03 18:50:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 18:50:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ri9Ra-0002lM-2z; Tue, 03 Jan 2012 18:50: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 1Ri9RY-0002l5-3F
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 18:50:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325616632!5845074!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4NTU4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2737 invoked from network); 3 Jan 2012 18:50:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 18:50:34 -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
	q03Ing7M024011
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 18:49:42 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03IneTA002528
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 18:49:41 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q03IndYv019410; Tue, 3 Jan 2012 12:49:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 10:49:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A87ED40332; Tue,  3 Jan 2012 13:48:07 -0500 (EST)
Date: Tue, 3 Jan 2012 13:48:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120103184807.GB27537@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>
	<20120102160611.GB12529@aepfle.de>
	<20120103181953.GH749@andromeda.dapyr.net>
	<20120103184045.GA26720@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120103184045.GA26720@aepfle.de>
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.4F034DC7.0054,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Adin Scannell <adin@scannell.ca>,
	andres@gridcentric.ca, JBeulich@suse.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, 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 Tue, Jan 03, 2012 at 07:40:45PM +0100, Olaf Hering wrote:
> On Tue, Jan 03, Konrad Rzeszutek Wilk wrote:
> 
> > If this problem does occur (the swapper died in dom0) should the
> > printk at least use printk_ratelimited so that we don't cause too much
> > noise?
> 
> I remember there was no flood because the guest was stuck anyway. But
> see below.
> 
> > > The caller has to deal with the various !GNTST_okay states anyway, this
> > > patch wont change that fact.
> > 
> > Ok, so then we don't really need the printk right? As the caller
> > would presumarily do the right thing and also print the error?
> 
> I think its more a debug thing, so that I knew something bad happend.
> And at that time it was just helpful to get me some understanding of the
> code flow. Since now that part of the paging code is reasonable
> debugged, the printk is not really needed anymore.

OK.
> Instead the code who uses these new functionality should have proper
> error handling and print reasonable diagnostic messages.

Excellent. So lets remove that printk(KERN_ERR).

Thanks!
> 
> 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 Jan 03 19:45:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 19:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiAIK-0003BC-AG; Tue, 03 Jan 2012 19:45:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <haogangchen@gmail.com>) id 1RiAIJ-0003B7-6Y
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 19:45:11 +0000
X-Env-Sender: haogangchen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325619904!9468745!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 11886 invoked from network); 3 Jan 2012 19:45:05 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 19:45:05 -0000
Received: by qcsc20 with SMTP id c20so116584615qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 11:45:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=HWsOAb2qnFzrFTmsylm4cGemHlwN61++Cx1r5glZRRY=;
	b=BaAiAfgyf/BsMBj3lTe79U65sB7CtdPjROcf8rJ7XbZJZ1FJyCLhSNyGwRiOd62ErU
	2dYaMYzDLz2DGM2B7KKcWEfrxbznEHOX3iLfJjBzp9phQR/lLTp2wp1dLsOJak6vfkt3
	xacuYfTjJvbX+zHyNblcF3Qhho5tmMfTPY/x0=
Received: by 10.229.78.134 with SMTP id l6mr19587570qck.19.1325619903683;
	Tue, 03 Jan 2012 11:45:03 -0800 (PST)
Received: from localhost.localdomain (hchen.csail.mit.edu. [18.26.5.5])
	by mx.google.com with ESMTPS id
	dj9sm101648697qab.18.2012.01.03.11.45.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 03 Jan 2012 11:45:02 -0800 (PST)
From: Haogang Chen <haogangchen@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue,  3 Jan 2012 14:42:11 -0500
Message-Id: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
X-Mailer: git-send-email 1.7.5.4
Cc: Haogang Chen <haogangchen@gmail.com>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH] XEN: xenbus: integer overflow in process_msg()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 a potential integer overflow in process_msg() that could result
in cross-domain attack.

	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);

When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
call to xb_read() would write to a zero-length buffer. This causes
kernel oops in the receiving guest and hangs its xenbus kernel thread.
The patch returns -EINVAL in that case.

Signed-off-by: Haogang Chen <haogangchen@gmail.com>
---
 drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index ede860f..e32aefb 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -801,6 +801,12 @@ static int process_msg(void)
 		goto out;
 	}
 
+	if (msg->hdr.len == UINT_MAX) {
+		kfree(msg);
+		err = -EINVAL;
+		goto out;
+	}
+
 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
 	if (body == NULL) {
 		kfree(msg);
-- 
1.7.5.4


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 19:45:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 19:45:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiAIK-0003BC-AG; Tue, 03 Jan 2012 19:45:12 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <haogangchen@gmail.com>) id 1RiAIJ-0003B7-6Y
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 19:45:11 +0000
X-Env-Sender: haogangchen@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325619904!9468745!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 11886 invoked from network); 3 Jan 2012 19:45:05 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 19:45:05 -0000
Received: by qcsc20 with SMTP id c20so116584615qcs.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 11:45:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:to:cc:subject:date:message-id:x-mailer;
	bh=HWsOAb2qnFzrFTmsylm4cGemHlwN61++Cx1r5glZRRY=;
	b=BaAiAfgyf/BsMBj3lTe79U65sB7CtdPjROcf8rJ7XbZJZ1FJyCLhSNyGwRiOd62ErU
	2dYaMYzDLz2DGM2B7KKcWEfrxbznEHOX3iLfJjBzp9phQR/lLTp2wp1dLsOJak6vfkt3
	xacuYfTjJvbX+zHyNblcF3Qhho5tmMfTPY/x0=
Received: by 10.229.78.134 with SMTP id l6mr19587570qck.19.1325619903683;
	Tue, 03 Jan 2012 11:45:03 -0800 (PST)
Received: from localhost.localdomain (hchen.csail.mit.edu. [18.26.5.5])
	by mx.google.com with ESMTPS id
	dj9sm101648697qab.18.2012.01.03.11.45.01
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 03 Jan 2012 11:45:02 -0800 (PST)
From: Haogang Chen <haogangchen@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Date: Tue,  3 Jan 2012 14:42:11 -0500
Message-Id: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
X-Mailer: git-send-email 1.7.5.4
Cc: Haogang Chen <haogangchen@gmail.com>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH] XEN: xenbus: integer overflow in process_msg()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 a potential integer overflow in process_msg() that could result
in cross-domain attack.

	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);

When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
call to xb_read() would write to a zero-length buffer. This causes
kernel oops in the receiving guest and hangs its xenbus kernel thread.
The patch returns -EINVAL in that case.

Signed-off-by: Haogang Chen <haogangchen@gmail.com>
---
 drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index ede860f..e32aefb 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -801,6 +801,12 @@ static int process_msg(void)
 		goto out;
 	}
 
+	if (msg->hdr.len == UINT_MAX) {
+		kfree(msg);
+		err = -EINVAL;
+		goto out;
+	}
+
 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
 	if (body == NULL) {
 		kfree(msg);
-- 
1.7.5.4


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:11:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiAhS-0003px-4i; Tue, 03 Jan 2012 20:11:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiAhQ-0003pr-O5
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:11:08 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325621423!54540806!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 19541 invoked from network); 3 Jan 2012 20:10:26 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Jan 2012 20:10:26 -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 1RiAhD-0002IA-0h; Wed, 04 Jan 2012 07:10:55 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 07:10:55 +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;
	Wed, 4 Jan 2012 07:10:54 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q
Date: Tue, 3 Jan 2012 20:10:52 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
In-Reply-To: <20120103175539.GF749@andromeda.dapyr.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Jan 2012 20:10:55.0054 (UTC)
	FILETIME=[CC986EE0:01CCCA53]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> 
> On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> > 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.
> 
> Which tree are you using? The devel/xen-scsi-1.0 ?
> 
> Or the #testing one?
> 
> What do you mean: "This used to work fine in pvops" ? Can you be more
> specific please.

Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it compiled against jeremy's 2.6.32 tree (out-of-tree build though). That worked fine, and I didn't need scsifront as gplpv is the front end.

Now I'm trying to do the same against 3.0.1 (just compiling against the debian kernel-headers) and it builds fine after a bit more patching but set_phys_to_machine isn't exported.

> >
> > Is there another call I can use instead or does that symbol need to be
> exported?
> 
> That is the only one?

Comparing with blkback from 3.0.1, it uses m2p_add_override instead I think... should that work if I make the same changes to scsiback?

Or maybe someone else already has scsiback working against 3.x.x?

Thanks

James

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:11:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20:11:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiAhS-0003px-4i; Tue, 03 Jan 2012 20:11:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiAhQ-0003pr-O5
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:11:08 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325621423!54540806!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 19541 invoked from network); 3 Jan 2012 20:10:26 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-4.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Jan 2012 20:10:26 -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 1RiAhD-0002IA-0h; Wed, 04 Jan 2012 07:10:55 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 07:10:55 +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;
	Wed, 4 Jan 2012 07:10:54 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q
Date: Tue, 3 Jan 2012 20:10:52 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
In-Reply-To: <20120103175539.GF749@andromeda.dapyr.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Jan 2012 20:10:55.0054 (UTC)
	FILETIME=[CC986EE0:01CCCA53]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> 
> On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> > 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.
> 
> Which tree are you using? The devel/xen-scsi-1.0 ?
> 
> Or the #testing one?
> 
> What do you mean: "This used to work fine in pvops" ? Can you be more
> specific please.

Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it compiled against jeremy's 2.6.32 tree (out-of-tree build though). That worked fine, and I didn't need scsifront as gplpv is the front end.

Now I'm trying to do the same against 3.0.1 (just compiling against the debian kernel-headers) and it builds fine after a bit more patching but set_phys_to_machine isn't exported.

> >
> > Is there another call I can use instead or does that symbol need to be
> exported?
> 
> That is the only one?

Comparing with blkback from 3.0.1, it uses m2p_add_override instead I think... should that work if I make the same changes to scsiback?

Or maybe someone else already has scsiback working against 3.x.x?

Thanks

James

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:26:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20: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 1RiAva-00040b-Im; Tue, 03 Jan 2012 20:25: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 1RiAvY-00040W-Dp
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:25:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325622336!2742692!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18874 invoked from network); 3 Jan 2012 20:25:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 20:25:37 -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
	q03KPYqf031626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 20:25:35 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
	q03KPXTv011765
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 20:25:34 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q03KPXTw006603; Tue, 3 Jan 2012 14:25:33 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 12:25:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9B8A240438; Tue,  3 Jan 2012 15:24:01 -0500 (EST)
Date: Tue, 3 Jan 2012 15:24:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: John Sherwood <theubaz@gmail.com>
Message-ID: <20120103202401.GB17472@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F03643F.006C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> Hello,
> 
> I'm working on a project and trying to pass through a PS/2 mouse + keyboard
> to a hardware VM.  I've played with numerous things (including the obvious,
> using USB), but after finding no alternative, it seems like the best way to
> approach this would be to modify qemu-dm to pipe through data from
> /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and then
> using this version of qemu-dm only for this special case).

That is certainly one way. But you would have an interesting problem that whatever
you type on your physical keyboard would appear in the guest _and_ in the 
domain 0.

> 
> I've been looking through the 4.1.0 source, specifically in
> tools/ioemu-qemu-xen, and it appears that I'd want to (for the keyboard)
> pass key codes from /dev/input through the kbd_put_keycode function.  From
> what I can tell, I'd probably want to split off a thread to do this
> somewhere in main() in vl.c.  I was hoping that I could get some
> confirmation about whether I'm looking in the right places and/or
> suggestions about how to cleanly implement this.  Odds are I won't be able
> to go the whole 9 yards and implement configuration options for xm or
> command line switches for qemu-dm, but I would suspect that someone,
> somewhere, someday will also want this kind of ability.  If it's already
> possible to pass through PS/2 devices without getting nuts in QEMU, that's
> cool too :)

Can't do that. The PS/2 is one of those legacy beasts that depends on ioports.
But now that I think of it, maybe you can. In the guest config you can specify
the ioports that you want to pass in. I hadn't tried to do this for the keyboard
ports but maybe that will work for you?

Or could you use synergy?

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:26:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20: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 1RiAva-00040b-Im; Tue, 03 Jan 2012 20:25: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 1RiAvY-00040W-Dp
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:25:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325622336!2742692!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18874 invoked from network); 3 Jan 2012 20:25:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 20:25:37 -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
	q03KPYqf031626
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 20:25:35 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
	q03KPXTv011765
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 20:25:34 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q03KPXTw006603; Tue, 3 Jan 2012 14:25:33 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 12:25:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9B8A240438; Tue,  3 Jan 2012 15:24:01 -0500 (EST)
Date: Tue, 3 Jan 2012 15:24:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: John Sherwood <theubaz@gmail.com>
Message-ID: <20120103202401.GB17472@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F03643F.006C,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> Hello,
> 
> I'm working on a project and trying to pass through a PS/2 mouse + keyboard
> to a hardware VM.  I've played with numerous things (including the obvious,
> using USB), but after finding no alternative, it seems like the best way to
> approach this would be to modify qemu-dm to pipe through data from
> /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and then
> using this version of qemu-dm only for this special case).

That is certainly one way. But you would have an interesting problem that whatever
you type on your physical keyboard would appear in the guest _and_ in the 
domain 0.

> 
> I've been looking through the 4.1.0 source, specifically in
> tools/ioemu-qemu-xen, and it appears that I'd want to (for the keyboard)
> pass key codes from /dev/input through the kbd_put_keycode function.  From
> what I can tell, I'd probably want to split off a thread to do this
> somewhere in main() in vl.c.  I was hoping that I could get some
> confirmation about whether I'm looking in the right places and/or
> suggestions about how to cleanly implement this.  Odds are I won't be able
> to go the whole 9 yards and implement configuration options for xm or
> command line switches for qemu-dm, but I would suspect that someone,
> somewhere, someday will also want this kind of ability.  If it's already
> possible to pass through PS/2 devices without getting nuts in QEMU, that's
> cool too :)

Can't do that. The PS/2 is one of those legacy beasts that depends on ioports.
But now that I think of it, maybe you can. In the guest config you can specify
the ioports that you want to pass in. I hadn't tried to do this for the keyboard
ports but maybe that will work for you?

Or could you use synergy?

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:32:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiB1S-0004Ae-Ce; Tue, 03 Jan 2012 20:31:50 +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 1RiB1R-0004AY-Ak
	for Xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:31:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1325622576!50397453!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13367 invoked from network); 3 Jan 2012 20:29:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 20:29:37 -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
	q03KVgnd006538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 20:31:43 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
	q03KVfGA016183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 20:31:41 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
	q03KVeam011232; Tue, 3 Jan 2012 14:31:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 12:31:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ED6C64043B; Tue,  3 Jan 2012 15:30:08 -0500 (EST)
Date: Tue, 3 Jan 2012 15:30:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: =?utf-8?B?6ams6ICA?= <327801865@qq.com>
Message-ID: <20120103203008.GC17472@phenom.dumpdata.com>
References: <tencent_1975194D595A261C1C28650E@qq.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tencent_1975194D595A261C1C28650E@qq.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.4F0365AF.005F,ss=1,re=0.000,fgs=0
Cc: Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] HVM (hypercall_grant_table_op) Problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBOb3YgMTgsIDIwMTEgYXQgMTI6NTI6MTNBTSArMDgwMCwg6ams6ICAIHdyb3RlOgo+
IEhpOgo+ICAgICAgSSBtb2RpZmllZCB0aGUgbmV0Zm9udC5jIG9mIExpbnV4IEhWTSBkb21VIGlu
c3RhbGxlZCBQVm9uSFZNLkluIGl0LCBJIGNhbGwgaHlwZXJjYWxsX2dyYW50X3RhYmxlX29wCj4g
IChHTlRUQUJPUF9tYXBfZ3JhbnRfcmVmLi4uKSwgdGhlbiBkb20wIHNodXRkb3duIGFuZCByZXN0
YXJ0IGF0IG9uY2UuCj4gICAgICBJJ20gY29uZnVzZWQgYWJvdXQgdGhpcy4KPiAgICAgIEJlZm9y
ZSBYZW4gMy40LjMsIFhlbi9hcmNoL3g4Ni9IVk0vaHZtLmMgbG9vayBsaWtlIHRoaXM6Cj4gIHN0
YXRpYyBsb25nIGh2bV9ncmFudF90YWJsZV9vcCh1bnNpZ25lZCBpbnQgY21kLCBYRU5fR1VFU1Rf
SEFORExFKHZvaWQpIHVvcCwgdW5zaWduZWQgaW50IGNvdW50KQo+IHsKPiAgICAgaWYgKCAoY21k
ICE9IEdOVFRBQk9QX3F1ZXJ5X3NpemUpICYmIChjbWQgIT0gR05UVEFCT1Bfc2V0dXBfdGFibGUp
ICkKPiAgICAgICAgIHJldHVybiAtRU5PU1lTOyAvKiBhbGwgb3RoZXIgY29tbWFuZHMgbmVlZCBh
dWRpdGluZyAqLwo+ICAgICByZXR1cm4gZG9fZ3JhbnRfdGFibGVfb3AoY21kLCB1b3AsIGNvdW50
KTsKPiB9Cj4gICAgICBJIGtub3cgaXQgaGFkbid0IHN1cHBvcnQgYWxsIGdyYW50X3RhYmxlX29w
IGJ1dCBvbmx5IHR3bzpHTlRUQUJPUF9xdWVyeV9zaXplIGFuZCBHTlRUQUJPUF9zZXR1cF90YWJs
ZS4KPiAgIAo+ICAgICAgTm93LCBhZnRlciBYZW40LjAuMCBhbmQgbGF0ZXIsIGl0IGxvb2sgbGlr
ZSBiZWxvdzoKPiAgc3RhdGljIGxvbmcgaHZtX2dyYW50X3RhYmxlX29wKCB1bnNpZ25lZCBpbnQg
Y21kLCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIHVvcCwgdW5zaWduZWQgaW50IGNvdW50KQo+IHsK
PiAgICAgaWYgKCAhZ3JhbnRfdGFibGVfb3BfaXNfYWxsb3dlZChjbWQpICkKPiAgICAgICAgIHJl
dHVybiAtRU5PU1lTOyAvKiBhbGwgb3RoZXIgY29tbWFuZHMgbmVlZCBhdWRpdGluZyAqLwo+ICAg
ICByZXR1cm4gZG9fZ3JhbnRfdGFibGVfb3AoY21kLCB1b3AsIGNvdW50KTsKPiB9Cj4gIHN0YXRp
YyBpbnQgZ3JhbnRfdGFibGVfb3BfaXNfYWxsb3dlZCh1bnNpZ25lZCBpbnQgY21kKQo+IHsKPiAg
ICAgc3dpdGNoIChjbWQpIHsKPiAgICAgY2FzZSBHTlRUQUJPUF9xdWVyeV9zaXplOgo+ICAgICBj
YXNlIEdOVFRBQk9QX3NldHVwX3RhYmxlOgo+ICAgICBjYXNlIEdOVFRBQk9QX3NldF92ZXJzaW9u
Ogo+ICAgICBjYXNlIEdOVFRBQk9QX2NvcHk6Cj4gICAgIGNhc2UgR05UVEFCT1BfbWFwX2dyYW50
X3JlZjoKPiAgICAgY2FzZSBHTlRUQUJPUF91bm1hcF9ncmFudF9yZWY6Cj4gICAgICAgICByZXR1
cm4gMTsKPiAgICAgZGVmYXVsdDoKPiAgICAgICAgIC8qIGFsbCBvdGhlciBjb21tYW5kcyBuZWVk
IGF1ZGl0aW5nICovCj4gICAgICAgICByZXR1cm4gMDsKPiAgICAgfQo+IH0KPiAgICAgIEZyb20g
YWJvdmUsIEkgY29uY2x1ZGUgdGhhdCBJIGNhbiBtYXAgYSBIVk0ncyBwYWdlIHRvIGFub3RoZXIg
SFZNLCBqdXN0IGxpa2UgdHdvIFBWcy4gCj4gIEFtIEkgd3Jvbmc/IFdobyBjYW4gZ2l2ZSBtZSBz
b21lIHN1Z2dlc3Rpb24/CgpJIGFtIG5vdCBzdXJlIGlmIHdlIGV2ZXIgY2FtZSB0byBhIGNvbmNs
dXNpb24gb24gd2hhdCBtaWdodCBiZSB0aGUgdHJvdWJsZS4gQXJlIHlvdSBzdGlsbCBleHBlcmll
bmNpbmcKcHJvYmxlbXM/CgpUaGFua3MKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:32:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiB1S-0004Ae-Ce; Tue, 03 Jan 2012 20:31:50 +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 1RiB1R-0004AY-Ak
	for Xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:31:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1325622576!50397453!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13367 invoked from network); 3 Jan 2012 20:29:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 20:29:37 -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
	q03KVgnd006538
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 20:31:43 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
	q03KVfGA016183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 20:31:41 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
	q03KVeam011232; Tue, 3 Jan 2012 14:31:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 12:31:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id ED6C64043B; Tue,  3 Jan 2012 15:30:08 -0500 (EST)
Date: Tue, 3 Jan 2012 15:30:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: =?utf-8?B?6ams6ICA?= <327801865@qq.com>
Message-ID: <20120103203008.GC17472@phenom.dumpdata.com>
References: <tencent_1975194D595A261C1C28650E@qq.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tencent_1975194D595A261C1C28650E@qq.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.4F0365AF.005F,ss=1,re=0.000,fgs=0
Cc: Xen-devel <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] HVM (hypercall_grant_table_op) Problem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBOb3YgMTgsIDIwMTEgYXQgMTI6NTI6MTNBTSArMDgwMCwg6ams6ICAIHdyb3RlOgo+
IEhpOgo+ICAgICAgSSBtb2RpZmllZCB0aGUgbmV0Zm9udC5jIG9mIExpbnV4IEhWTSBkb21VIGlu
c3RhbGxlZCBQVm9uSFZNLkluIGl0LCBJIGNhbGwgaHlwZXJjYWxsX2dyYW50X3RhYmxlX29wCj4g
IChHTlRUQUJPUF9tYXBfZ3JhbnRfcmVmLi4uKSwgdGhlbiBkb20wIHNodXRkb3duIGFuZCByZXN0
YXJ0IGF0IG9uY2UuCj4gICAgICBJJ20gY29uZnVzZWQgYWJvdXQgdGhpcy4KPiAgICAgIEJlZm9y
ZSBYZW4gMy40LjMsIFhlbi9hcmNoL3g4Ni9IVk0vaHZtLmMgbG9vayBsaWtlIHRoaXM6Cj4gIHN0
YXRpYyBsb25nIGh2bV9ncmFudF90YWJsZV9vcCh1bnNpZ25lZCBpbnQgY21kLCBYRU5fR1VFU1Rf
SEFORExFKHZvaWQpIHVvcCwgdW5zaWduZWQgaW50IGNvdW50KQo+IHsKPiAgICAgaWYgKCAoY21k
ICE9IEdOVFRBQk9QX3F1ZXJ5X3NpemUpICYmIChjbWQgIT0gR05UVEFCT1Bfc2V0dXBfdGFibGUp
ICkKPiAgICAgICAgIHJldHVybiAtRU5PU1lTOyAvKiBhbGwgb3RoZXIgY29tbWFuZHMgbmVlZCBh
dWRpdGluZyAqLwo+ICAgICByZXR1cm4gZG9fZ3JhbnRfdGFibGVfb3AoY21kLCB1b3AsIGNvdW50
KTsKPiB9Cj4gICAgICBJIGtub3cgaXQgaGFkbid0IHN1cHBvcnQgYWxsIGdyYW50X3RhYmxlX29w
IGJ1dCBvbmx5IHR3bzpHTlRUQUJPUF9xdWVyeV9zaXplIGFuZCBHTlRUQUJPUF9zZXR1cF90YWJs
ZS4KPiAgIAo+ICAgICAgTm93LCBhZnRlciBYZW40LjAuMCBhbmQgbGF0ZXIsIGl0IGxvb2sgbGlr
ZSBiZWxvdzoKPiAgc3RhdGljIGxvbmcgaHZtX2dyYW50X3RhYmxlX29wKCB1bnNpZ25lZCBpbnQg
Y21kLCBYRU5fR1VFU1RfSEFORExFKHZvaWQpIHVvcCwgdW5zaWduZWQgaW50IGNvdW50KQo+IHsK
PiAgICAgaWYgKCAhZ3JhbnRfdGFibGVfb3BfaXNfYWxsb3dlZChjbWQpICkKPiAgICAgICAgIHJl
dHVybiAtRU5PU1lTOyAvKiBhbGwgb3RoZXIgY29tbWFuZHMgbmVlZCBhdWRpdGluZyAqLwo+ICAg
ICByZXR1cm4gZG9fZ3JhbnRfdGFibGVfb3AoY21kLCB1b3AsIGNvdW50KTsKPiB9Cj4gIHN0YXRp
YyBpbnQgZ3JhbnRfdGFibGVfb3BfaXNfYWxsb3dlZCh1bnNpZ25lZCBpbnQgY21kKQo+IHsKPiAg
ICAgc3dpdGNoIChjbWQpIHsKPiAgICAgY2FzZSBHTlRUQUJPUF9xdWVyeV9zaXplOgo+ICAgICBj
YXNlIEdOVFRBQk9QX3NldHVwX3RhYmxlOgo+ICAgICBjYXNlIEdOVFRBQk9QX3NldF92ZXJzaW9u
Ogo+ICAgICBjYXNlIEdOVFRBQk9QX2NvcHk6Cj4gICAgIGNhc2UgR05UVEFCT1BfbWFwX2dyYW50
X3JlZjoKPiAgICAgY2FzZSBHTlRUQUJPUF91bm1hcF9ncmFudF9yZWY6Cj4gICAgICAgICByZXR1
cm4gMTsKPiAgICAgZGVmYXVsdDoKPiAgICAgICAgIC8qIGFsbCBvdGhlciBjb21tYW5kcyBuZWVk
IGF1ZGl0aW5nICovCj4gICAgICAgICByZXR1cm4gMDsKPiAgICAgfQo+IH0KPiAgICAgIEZyb20g
YWJvdmUsIEkgY29uY2x1ZGUgdGhhdCBJIGNhbiBtYXAgYSBIVk0ncyBwYWdlIHRvIGFub3RoZXIg
SFZNLCBqdXN0IGxpa2UgdHdvIFBWcy4gCj4gIEFtIEkgd3Jvbmc/IFdobyBjYW4gZ2l2ZSBtZSBz
b21lIHN1Z2dlc3Rpb24/CgpJIGFtIG5vdCBzdXJlIGlmIHdlIGV2ZXIgY2FtZSB0byBhIGNvbmNs
dXNpb24gb24gd2hhdCBtaWdodCBiZSB0aGUgdHJvdWJsZS4gQXJlIHlvdSBzdGlsbCBleHBlcmll
bmNpbmcKcHJvYmxlbXM/CgpUaGFua3MKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:39:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiB8e-0004O2-AQ; Tue, 03 Jan 2012 20:39:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RiB8c-0004Nx-W2
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:39:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1325623126!54278854!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9797 invoked from network); 3 Jan 2012 20:38:47 -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; 3 Jan 2012 20:38:47 -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
	q03KcGh0014335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 20:38:17 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
	q03KcD6C006361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 20:38:14 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q03KcAvr023368; Tue, 3 Jan 2012 14:38:11 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 12:38:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0B90E4043B; Tue,  3 Jan 2012 15:36:38 -0500 (EST)
Date: Tue, 3 Jan 2012 15:36:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120103203637.GF17472@phenom.dumpdata.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>
	<1324565067.2897.2.camel@bwh-desktop>
	<1324586301.13113.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324586301.13113.3.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F03673B.006D,ss=1,re=0.000,fgs=0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.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>, Ben Hutchings <bhutchings@solarflare.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, Dec 22, 2011 at 08:38:21PM +0000, Ian Campbell wrote:
> 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.

Ian, are you OK with this patch? I think Jan needs to repost once more with the
"pciback" -> DRV_NAME change and then it is OK?

I've tested it with all backends, except the pciback one, and I see no regressions
with 'xl' or 'xm' toolstack.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:39:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20:39:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiB8e-0004O2-AQ; Tue, 03 Jan 2012 20:39:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RiB8c-0004Nx-W2
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:39:15 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1325623126!54278854!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9797 invoked from network); 3 Jan 2012 20:38:47 -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; 3 Jan 2012 20:38:47 -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
	q03KcGh0014335
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 20:38:17 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
	q03KcD6C006361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 20:38:14 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q03KcAvr023368; Tue, 3 Jan 2012 14:38:11 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 12:38:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0B90E4043B; Tue,  3 Jan 2012 15:36:38 -0500 (EST)
Date: Tue, 3 Jan 2012 15:36:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120103203637.GF17472@phenom.dumpdata.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>
	<1324565067.2897.2.camel@bwh-desktop>
	<1324586301.13113.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1324586301.13113.3.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F03673B.006D,ss=1,re=0.000,fgs=0
Cc: Jens Axboe <axboe@kernel.dk>, Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.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>, Ben Hutchings <bhutchings@solarflare.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, Dec 22, 2011 at 08:38:21PM +0000, Ian Campbell wrote:
> 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.

Ian, are you OK with this patch? I think Jan needs to repost once more with the
"pciback" -> DRV_NAME change and then it is OK?

I've tested it with all backends, except the pciback one, and I see no regressions
with 'xl' or 'xm' toolstack.

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:42:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiBB1-0004V7-2c; Tue, 03 Jan 2012 20:41:43 +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 1RiBB0-0004Ur-17
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:41:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325623276!51409338!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY5ODQ4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3969 invoked from network); 3 Jan 2012 20:41:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 20:41:17 -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
	q03Kekhf029507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 20:40:47 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03Kejjf013574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 20:40:46 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
	q03KejCw000711; Tue, 3 Jan 2012 14:40:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 12:40:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A59C640439; Tue,  3 Jan 2012 15:39:12 -0500 (EST)
Date: Tue, 3 Jan 2012 15:39:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120103203912.GG17472@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923359699@SHSMSX101.ccr.corp.intel.com>
	<20111223124208.GA25286@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111223124208.GA25286@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F0367D0.000A,ss=1,re=0.000,fgs=0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, "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: 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 08:42:08AM -0400, Konrad Rzeszutek Wilk wrote:
> 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.

Actually on a second thought we don't need it. This patch (and all the others)
have never been posted upstream. So the back-history is not really that interesting
unless there has been a lot of churn (say the authorship changed or you had to
redo some serious surgery on it).

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 20:42:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 20:42:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiBB1-0004V7-2c; Tue, 03 Jan 2012 20:41:43 +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 1RiBB0-0004Ur-17
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:41:42 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325623276!51409338!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY5ODQ4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3969 invoked from network); 3 Jan 2012 20:41:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 3 Jan 2012 20:41:17 -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
	q03Kekhf029507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 20:40:47 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03Kejjf013574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 20:40:46 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
	q03KejCw000711; Tue, 3 Jan 2012 14:40:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 12:40:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A59C640439; Tue,  3 Jan 2012 15:39:12 -0500 (EST)
Date: Tue, 3 Jan 2012 15:39:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120103203912.GG17472@phenom.dumpdata.com>
References: <DE8DF0795D48FD4CA783C40EC82923359699@SHSMSX101.ccr.corp.intel.com>
	<20111223124208.GA25286@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111223124208.GA25286@andromeda.dapyr.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F0367D0.000A,ss=1,re=0.000,fgs=0
Cc: "Liu, Jinsong" <jinsong.liu@intel.com>, "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: 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 08:42:08AM -0400, Konrad Rzeszutek Wilk wrote:
> 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.

Actually on a second thought we don't need it. This patch (and all the others)
have never been posted upstream. So the back-history is not really that interesting
unless there has been a lot of churn (say the authorship changed or you had to
redo some serious surgery on it).

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 21:02:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 21:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiBUj-0004oX-0r; Tue, 03 Jan 2012 21:02: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 1RiBUh-0004oL-Hi
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 21:02:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325624515!7534321!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY5ODQ4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29794 invoked from network); 3 Jan 2012 21:01:57 -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; 3 Jan 2012 21:01:57 -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
	q03L13iH022505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 21:01: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
	q03L10f4004110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 21:01:02 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
	q03L0wsm031848; Tue, 3 Jan 2012 15:00:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 13:00:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 96F6840438; Tue,  3 Jan 2012 15:59:25 -0500 (EST)
Date: Tue, 3 Jan 2012 15:59:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120103205925.GI17472@phenom.dumpdata.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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F036C91.005E,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@citrix.com" <Ian.Campbell@citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"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 Rzeszutek Wilk <konrad@darnok.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 26, 2011 at 01:31:45AM +0000, Tian, Kevin wrote:
> > 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.

Excellent. So now the big question  - is this something you would have the
time to do?

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 21:02:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 21:02:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiBUj-0004oX-0r; Tue, 03 Jan 2012 21:02: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 1RiBUh-0004oL-Hi
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 21:02:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325624515!7534321!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY5ODQ4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29794 invoked from network); 3 Jan 2012 21:01:57 -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; 3 Jan 2012 21:01:57 -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
	q03L13iH022505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 21:01: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
	q03L10f4004110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 21:01:02 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
	q03L0wsm031848; Tue, 3 Jan 2012 15:00:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 13:00:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 96F6840438; Tue,  3 Jan 2012 15:59:25 -0500 (EST)
Date: Tue, 3 Jan 2012 15:59:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120103205925.GI17472@phenom.dumpdata.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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F036C91.005E,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@citrix.com" <Ian.Campbell@citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"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 Rzeszutek Wilk <konrad@darnok.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 26, 2011 at 01:31:45AM +0000, Tian, Kevin wrote:
> > 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.

Excellent. So now the big question  - is this something you would have the
time to do?

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 22:40:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 22: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 1RiD10-0005Nq-UQ; Tue, 03 Jan 2012 22:39: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 1RiD0y-0005Nl-OL
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 22:39:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325630351!9481672!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4NTU4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24187 invoked from network); 3 Jan 2012 22:39:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 22:39:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q03Mbi7I009961
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 22:37: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
	q03MbhvW013243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 22:37:43 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
	q03MbgmN007365; Tue, 3 Jan 2012 16:37:42 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 14:37:42 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E3B274043E; Tue,  3 Jan 2012 17:36:10 -0500 (EST)
Date: Tue, 3 Jan 2012 17:36:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120103223610.GB12939@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
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.4F038339.00F1,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Tue, Jan 03, 2012 at 08:10:52PM +0000, James Harper wrote:
> > 
> > On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> > > 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.
> > 
> > Which tree are you using? The devel/xen-scsi-1.0 ?
> > 
> > Or the #testing one?
> > 
> > What do you mean: "This used to work fine in pvops" ? Can you be more
> > specific please.
> 
> Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it compiled against jeremy's 2.6.32 tree (out-of-tree build though). That worked fine, and I didn't need scsifront as gplpv is the front end.

Ah, you are using the Windows Xen SCSI driver. Cool. Excited to know it works
that well.

> 
> Now I'm trying to do the same against 3.0.1 (just compiling against the debian kernel-headers) and it builds fine after a bit more patching but set_phys_to_machine isn't exported.
> 
> > >
> > > Is there another call I can use instead or does that symbol need to be
> > exported?
> > 
> > That is the only one?
> 
> Comparing with blkback from 3.0.1, it uses m2p_add_override instead I think... should that work if I make the same changes to scsiback?
> 
> Or maybe someone else already has scsiback working against 3.x.x?

I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should merge it against the 3.1 kernel
otherwise it won't compile b/c one argument changed - but you could alter it yourself if you are
using the 3.0 tree).

Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

They also moved - to drivers/scsi.
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 03 22:40:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 22: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 1RiD10-0005Nq-UQ; Tue, 03 Jan 2012 22:39: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 1RiD0y-0005Nl-OL
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 22:39:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325630351!9481672!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDY4NTU4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24187 invoked from network); 3 Jan 2012 22:39:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 3 Jan 2012 22:39:22 -0000
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238])
	by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q03Mbi7I009961
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 22:37: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
	q03MbhvW013243
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 22:37:43 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
	q03MbgmN007365; Tue, 3 Jan 2012 16:37:42 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 14:37:42 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E3B274043E; Tue,  3 Jan 2012 17:36:10 -0500 (EST)
Date: Tue, 3 Jan 2012 17:36:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120103223610.GB12939@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
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.4F038339.00F1,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Tue, Jan 03, 2012 at 08:10:52PM +0000, James Harper wrote:
> > 
> > On Fri, Dec 30, 2011 at 12:06:58PM +0000, James Harper wrote:
> > > 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.
> > 
> > Which tree are you using? The devel/xen-scsi-1.0 ?
> > 
> > Or the #testing one?
> > 
> > What do you mean: "This used to work fine in pvops" ? Can you be more
> > specific please.
> 
> Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it compiled against jeremy's 2.6.32 tree (out-of-tree build though). That worked fine, and I didn't need scsifront as gplpv is the front end.

Ah, you are using the Windows Xen SCSI driver. Cool. Excited to know it works
that well.

> 
> Now I'm trying to do the same against 3.0.1 (just compiling against the debian kernel-headers) and it builds fine after a bit more patching but set_phys_to_machine isn't exported.
> 
> > >
> > > Is there another call I can use instead or does that symbol need to be
> > exported?
> > 
> > That is the only one?
> 
> Comparing with blkback from 3.0.1, it uses m2p_add_override instead I think... should that work if I make the same changes to scsiback?
> 
> Or maybe someone else already has scsiback working against 3.x.x?

I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should merge it against the 3.1 kernel
otherwise it won't compile b/c one argument changed - but you could alter it yourself if you are
using the 3.0 tree).

Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

They also moved - to drivers/scsi.
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 03 22:42:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 22: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 1RiD3o-0005TQ-H9; Tue, 03 Jan 2012 22:42:24 +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 1RiD3n-0005TE-Ni
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 22:42:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325630535!10261299!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2OTY3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4368 invoked from network); 3 Jan 2012 22:42:17 -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; 3 Jan 2012 22:42:17 -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
	q03MgDg5002914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 22:42:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03MgCKa021189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 22:42:13 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
	q03MgCCY002091; Tue, 3 Jan 2012 16:42:12 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 14:42:12 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E984B4043E; Tue,  3 Jan 2012 17:40:40 -0500 (EST)
Date: Tue, 3 Jan 2012 17:40:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: John Sherwood <jrs@vt.edu>
Message-ID: <20120103224040.GC12939@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F038446.0120,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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 Tue, Jan 03, 2012 at 03:45:17PM -0500, John Sherwood wrote:
> On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
> 
> > On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> > > Hello,
> > >
> > > I'm working on a project and trying to pass through a PS/2 mouse +
> > keyboard
> > > to a hardware VM.  I've played with numerous things (including the
> > obvious,
> > > using USB), but after finding no alternative, it seems like the best way
> > to
> > > approach this would be to modify qemu-dm to pipe through data from
> > > /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and
> > then
> > > using this version of qemu-dm only for this special case).
> >
> > That is certainly one way. But you would have an interesting problem that
> > whatever
> > you type on your physical keyboard would appear in the guest _and_ in the
> > domain 0.
> >
> 
> yeah, I actually tested it and it was quite amusing to watch the keyboard
> and mouse move on the monitor and in VNC.
> 
> 
> >
> > >
> > > I've been looking through the 4.1.0 source, specifically in
> > > tools/ioemu-qemu-xen, and it appears that I'd want to (for the keyboard)
> > > pass key codes from /dev/input through the kbd_put_keycode function.
> >  From
> > > what I can tell, I'd probably want to split off a thread to do this
> > > somewhere in main() in vl.c.  I was hoping that I could get some
> > > confirmation about whether I'm looking in the right places and/or
> > > suggestions about how to cleanly implement this.  Odds are I won't be
> > able
> > > to go the whole 9 yards and implement configuration options for xm or
> > > command line switches for qemu-dm, but I would suspect that someone,
> > > somewhere, someday will also want this kind of ability.  If it's already
> > > possible to pass through PS/2 devices without getting nuts in QEMU,
> > that's
> > > cool too :)
> >
> > Can't do that. The PS/2 is one of those legacy beasts that depends on
> > ioports.
> > But now that I think of it, maybe you can. In the guest config you can
> > specify
> > the ioports that you want to pass in. I hadn't tried to do this for the
> > keyboard
> > ports but maybe that will work for you?
> >
> >
> I tried forwarding the ioports (off the top of my head, I remember trying
> 60 and 64) but didn't have any luck - the kb/mouse weren't forwarded
> despite adding the requisite ioports config as per the docs.  I theorized I
> was leaving off some config for the kernel, but didn't find anything.  I
> agree that it certainly seems like this should work, and if you could
> elaborate on anything I could have goofed on, that would certainly be great
> (and hopefully, useful for anyone else who might try this in the future)

I think you might be missing the ioperm patches. The are in devel/ioperm
on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

> 
> 
> > Or could you use synergy?
> >
> 
> I actually did try synergy, but I couldn't get it to work due to
> requirements for the OSes that were being run.

Huh? What OS is that? Anyhow another thought that occured to me is
what Virtual Computer or Xen Client Project do.. which is something
I don't really know what they do but their demo showed the user hitting
'Alt-Tab' on switching between domains on the laptop screen. The keyboard
is certainly PS/2 so I wonder how they "injected" the keyboard in the guest.
It might be curious to look at their patches: http://xen.org/products/xci_source.html



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 22:42:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 22: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 1RiD3o-0005TQ-H9; Tue, 03 Jan 2012 22:42:24 +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 1RiD3n-0005TE-Ni
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 22:42:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325630535!10261299!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2OTY3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4368 invoked from network); 3 Jan 2012 22:42:17 -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; 3 Jan 2012 22:42:17 -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
	q03MgDg5002914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 22:42:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q03MgCKa021189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 22:42:13 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
	q03MgCCY002091; Tue, 3 Jan 2012 16:42:12 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 14:42:12 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E984B4043E; Tue,  3 Jan 2012 17:40:40 -0500 (EST)
Date: Tue, 3 Jan 2012 17:40:40 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: John Sherwood <jrs@vt.edu>
Message-ID: <20120103224040.GC12939@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F038446.0120,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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 Tue, Jan 03, 2012 at 03:45:17PM -0500, John Sherwood wrote:
> On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
> 
> > On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> > > Hello,
> > >
> > > I'm working on a project and trying to pass through a PS/2 mouse +
> > keyboard
> > > to a hardware VM.  I've played with numerous things (including the
> > obvious,
> > > using USB), but after finding no alternative, it seems like the best way
> > to
> > > approach this would be to modify qemu-dm to pipe through data from
> > > /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and
> > then
> > > using this version of qemu-dm only for this special case).
> >
> > That is certainly one way. But you would have an interesting problem that
> > whatever
> > you type on your physical keyboard would appear in the guest _and_ in the
> > domain 0.
> >
> 
> yeah, I actually tested it and it was quite amusing to watch the keyboard
> and mouse move on the monitor and in VNC.
> 
> 
> >
> > >
> > > I've been looking through the 4.1.0 source, specifically in
> > > tools/ioemu-qemu-xen, and it appears that I'd want to (for the keyboard)
> > > pass key codes from /dev/input through the kbd_put_keycode function.
> >  From
> > > what I can tell, I'd probably want to split off a thread to do this
> > > somewhere in main() in vl.c.  I was hoping that I could get some
> > > confirmation about whether I'm looking in the right places and/or
> > > suggestions about how to cleanly implement this.  Odds are I won't be
> > able
> > > to go the whole 9 yards and implement configuration options for xm or
> > > command line switches for qemu-dm, but I would suspect that someone,
> > > somewhere, someday will also want this kind of ability.  If it's already
> > > possible to pass through PS/2 devices without getting nuts in QEMU,
> > that's
> > > cool too :)
> >
> > Can't do that. The PS/2 is one of those legacy beasts that depends on
> > ioports.
> > But now that I think of it, maybe you can. In the guest config you can
> > specify
> > the ioports that you want to pass in. I hadn't tried to do this for the
> > keyboard
> > ports but maybe that will work for you?
> >
> >
> I tried forwarding the ioports (off the top of my head, I remember trying
> 60 and 64) but didn't have any luck - the kb/mouse weren't forwarded
> despite adding the requisite ioports config as per the docs.  I theorized I
> was leaving off some config for the kernel, but didn't find anything.  I
> agree that it certainly seems like this should work, and if you could
> elaborate on anything I could have goofed on, that would certainly be great
> (and hopefully, useful for anyone else who might try this in the future)

I think you might be missing the ioperm patches. The are in devel/ioperm
on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git

> 
> 
> > Or could you use synergy?
> >
> 
> I actually did try synergy, but I couldn't get it to work due to
> requirements for the OSes that were being run.

Huh? What OS is that? Anyhow another thought that occured to me is
what Virtual Computer or Xen Client Project do.. which is something
I don't really know what they do but their demo showed the user hitting
'Alt-Tab' on switching between domains on the laptop screen. The keyboard
is certainly PS/2 so I wonder how they "injected" the keyboard in the guest.
It might be curious to look at their patches: http://xen.org/products/xci_source.html



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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 22:43:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 22:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiD3t-0005Tn-Tz; Tue, 03 Jan 2012 22:42:29 +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 1RiD3s-0005TH-56
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 22:42:28 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325630541!2751693!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNTQxNDQ=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18879 invoked from network); 3 Jan 2012 22:42:21 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-2.tower-21.messagelabs.com with SMTP;
	3 Jan 2012 22:42:21 -0000
Received: (qmail invoked by alias); 03 Jan 2012 22:42:20 -0000
Received: from xdsl-78-34-180-227.netcologne.de (EHLO Earth.access.denied)
	[78.34.180.227]
	by mail.gmx.net (mp011) with SMTP; 03 Jan 2012 23:42:20 +0100
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX1/E7mdZm4HEsg9rgCD/WBWzyyMaNw+v7RxUOcL42c
	EQi32C50PJdLm4
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>)
	id 1RiD72-00016i-ML; Tue, 03 Jan 2012 23:45:44 +0100
Message-ID: <4F038425.70905@access.denied>
Date: Tue, 03 Jan 2012 23:41:41 +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: "Wei Liu" <wei.liu2@citrix.com>
References: <4EFF9AF5.1070404@access.denied>
	<1325420264.24422.53.camel@liuw-desktop>
In-Reply-To: <1325420264.24422.53.camel@liuw-desktop>
X-Enigmail-Version: 1.3.4
X-Y-GMX-Trusted: 0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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="===============9040944529642364867=="
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)
--===============9040944529642364867==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig28B2211EF5FA819CE5273BE4"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig28B2211EF5FA819CE5273BE4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am 01.01.2012 13:17, schrieb Wei Liu:
> On Sat, 2011-12-31 at 23:29 +0000, Stefan Kuhne wrote:

Hello,

>> Error message:
>>
>> Internal error: Device 769 (vbd) could not be connected. Hotplug scrip=
ts
>> not working..
>>
>> Where can i look for a failure?
>=20
> Xen logs are stored in /var/log/xen by default. And judging from you
> log, you're probably using xend, right? You can start with xend.log .
>=20
I found in xend.log:

[2012-01-04 00:29:58 2055] DEBUG (XendDomain:464) Adding Domain: 0
[2012-01-04 00:29:58 2055] DEBUG (XendDomain:398) number of vcpus to use
is 0
[2012-01-04 00:29:58 2055] DEBUG (XendDomainInfo:1891)
XendDomainInfo.handleShutdownWatch
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call:
VBD.set_device not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: VBD.set_type
not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call:
session.get_all_records not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call:
event.get_record not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: event.get_all
not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call:
VIF.set_device not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: VIF.set_MAC
not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: VIF.set_MTU
not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: debug.get_all
not found


And:
root@eisxen:~# cat /var/log/xen/xend-debug.log
Xend started at Wed Jan  4 00:29:57 2012.
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host3/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host3/model: No such file or directory
cat: /sys/bus/scsi/devices/host3/type: No such file or directory
cat: /sys/bus/scsi/devices/host3/rev: No such file or directory
cat: /sys/bus/scsi/devices/host3/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host4/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host4/model: No such file or directory
cat: /sys/bus/scsi/devices/host4/type: No such file or directory
cat: /sys/bus/scsi/devices/host4/rev: No such file or directory
cat: /sys/bus/scsi/devices/host4/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/scsi_level: No such file or direct=
ory
cat: /sys/bus/scsi/devices/target2:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/scsi_level: No such file or direct=
ory
root@eisxen:~#

I think that doesn't look good.

Thanks. a happy new year and Regards,
Stefan Kuhne


--------------enig28B2211EF5FA819CE5273BE4
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/

iQEcBAEBAgAGBQJPA4QqAAoJEFLNPgL3IBVXMvcH/RH4Q5IjZScyKu+UkxKMSL+/
vDSo++sZfZpQK5E8yoT93lc/vm6TDvmU9nJb84Guw8JpvuuLj+0dgvA5beuVh4xg
cqhRILKanfyCYQyFxRQgzHp+8B3xgBfuemDUaVoRlAJM+NiKV8/6f40GQgtFMoiY
eWVVp76XTQwsVeR4VxH7BBwYI309+H7JUKKS2cd7dTGnSwzjV0VL6/btfeYSNENU
cg5bRd/r0BfvStJvcz6bf5CxI8856YHtA1YIApnBIuQhcgklKsmFUGJ5G+SmBTnB
qtHICh2UV3XQ0zreCOviNlxMkvxPgaxW1BNTT2QP6w21sQxcOzI16VFfuC58ieM=
=2fty
-----END PGP SIGNATURE-----

--------------enig28B2211EF5FA819CE5273BE4--


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

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

--===============9040944529642364867==--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 22:43:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 22:43:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiD3t-0005Tn-Tz; Tue, 03 Jan 2012 22:42:29 +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 1RiD3s-0005TH-56
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 22:42:28 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325630541!2751693!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNTQxNDQ=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18879 invoked from network); 3 Jan 2012 22:42:21 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-2.tower-21.messagelabs.com with SMTP;
	3 Jan 2012 22:42:21 -0000
Received: (qmail invoked by alias); 03 Jan 2012 22:42:20 -0000
Received: from xdsl-78-34-180-227.netcologne.de (EHLO Earth.access.denied)
	[78.34.180.227]
	by mail.gmx.net (mp011) with SMTP; 03 Jan 2012 23:42:20 +0100
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX1/E7mdZm4HEsg9rgCD/WBWzyyMaNw+v7RxUOcL42c
	EQi32C50PJdLm4
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>)
	id 1RiD72-00016i-ML; Tue, 03 Jan 2012 23:45:44 +0100
Message-ID: <4F038425.70905@access.denied>
Date: Tue, 03 Jan 2012 23:41:41 +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: "Wei Liu" <wei.liu2@citrix.com>
References: <4EFF9AF5.1070404@access.denied>
	<1325420264.24422.53.camel@liuw-desktop>
In-Reply-To: <1325420264.24422.53.camel@liuw-desktop>
X-Enigmail-Version: 1.3.4
X-Y-GMX-Trusted: 0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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="===============9040944529642364867=="
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)
--===============9040944529642364867==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig28B2211EF5FA819CE5273BE4"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig28B2211EF5FA819CE5273BE4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am 01.01.2012 13:17, schrieb Wei Liu:
> On Sat, 2011-12-31 at 23:29 +0000, Stefan Kuhne wrote:

Hello,

>> Error message:
>>
>> Internal error: Device 769 (vbd) could not be connected. Hotplug scrip=
ts
>> not working..
>>
>> Where can i look for a failure?
>=20
> Xen logs are stored in /var/log/xen by default. And judging from you
> log, you're probably using xend, right? You can start with xend.log .
>=20
I found in xend.log:

[2012-01-04 00:29:58 2055] DEBUG (XendDomain:464) Adding Domain: 0
[2012-01-04 00:29:58 2055] DEBUG (XendDomain:398) number of vcpus to use
is 0
[2012-01-04 00:29:58 2055] DEBUG (XendDomainInfo:1891)
XendDomainInfo.handleShutdownWatch
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call:
VBD.set_device not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: VBD.set_type
not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call:
session.get_all_records not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call:
event.get_record not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: event.get_all
not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call:
VIF.set_device not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: VIF.set_MAC
not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: VIF.set_MTU
not found
[2012-01-04 00:29:58 2055] WARNING (XendAPI:705) API call: debug.get_all
not found


And:
root@eisxen:~# cat /var/log/xen/xend-debug.log
Xend started at Wed Jan  4 00:29:57 2012.
cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host0/model: No such file or directory
cat: /sys/bus/scsi/devices/host0/type: No such file or directory
cat: /sys/bus/scsi/devices/host0/rev: No such file or directory
cat: /sys/bus/scsi/devices/host0/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host1/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host1/model: No such file or directory
cat: /sys/bus/scsi/devices/host1/type: No such file or directory
cat: /sys/bus/scsi/devices/host1/rev: No such file or directory
cat: /sys/bus/scsi/devices/host1/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host2/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host2/model: No such file or directory
cat: /sys/bus/scsi/devices/host2/type: No such file or directory
cat: /sys/bus/scsi/devices/host2/rev: No such file or directory
cat: /sys/bus/scsi/devices/host2/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host3/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host3/model: No such file or directory
cat: /sys/bus/scsi/devices/host3/type: No such file or directory
cat: /sys/bus/scsi/devices/host3/rev: No such file or directory
cat: /sys/bus/scsi/devices/host3/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/host4/vendor: No such file or directory
cat: /sys/bus/scsi/devices/host4/model: No such file or directory
cat: /sys/bus/scsi/devices/host4/type: No such file or directory
cat: /sys/bus/scsi/devices/host4/rev: No such file or directory
cat: /sys/bus/scsi/devices/host4/scsi_level: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target0:0:0/scsi_level: No such file or direct=
ory
cat: /sys/bus/scsi/devices/target2:0:0/vendor: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/model: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/type: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/rev: No such file or directory
cat: /sys/bus/scsi/devices/target2:0:0/scsi_level: No such file or direct=
ory
root@eisxen:~#

I think that doesn't look good.

Thanks. a happy new year and Regards,
Stefan Kuhne


--------------enig28B2211EF5FA819CE5273BE4
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/

iQEcBAEBAgAGBQJPA4QqAAoJEFLNPgL3IBVXMvcH/RH4Q5IjZScyKu+UkxKMSL+/
vDSo++sZfZpQK5E8yoT93lc/vm6TDvmU9nJb84Guw8JpvuuLj+0dgvA5beuVh4xg
cqhRILKanfyCYQyFxRQgzHp+8B3xgBfuemDUaVoRlAJM+NiKV8/6f40GQgtFMoiY
eWVVp76XTQwsVeR4VxH7BBwYI309+H7JUKKS2cd7dTGnSwzjV0VL6/btfeYSNENU
cg5bRd/r0BfvStJvcz6bf5CxI8856YHtA1YIApnBIuQhcgklKsmFUGJ5G+SmBTnB
qtHICh2UV3XQ0zreCOviNlxMkvxPgaxW1BNTT2QP6w21sQxcOzI16VFfuC58ieM=
=2fty
-----END PGP SIGNATURE-----

--------------enig28B2211EF5FA819CE5273BE4--


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

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

--===============9040944529642364867==--


From xen-devel-bounces@lists.xensource.com Tue Jan 03 22:49:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 22: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 1RiDAP-0005pk-QJ; Tue, 03 Jan 2012 22:49:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RiDAO-0005pc-4C
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 22:49:12 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325630944!9001847!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 1167 invoked from network); 3 Jan 2012 22:49:05 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-13.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Jan 2012 22:49:05 -0000
Received: from mail110-tx2-R.bigfish.com (10.9.14.240) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Jan 2012 22:49:04 +0000
Received: from mail110-tx2 (localhost [127.0.0.1])	by
	mail110-tx2-R.bigfish.com (Postfix) with ESMTP id 061344C02F6;
	Tue,  3 Jan 2012 22:49:04 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h63h)
X-Spam-TCS-SCL: 2: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 mail110-tx2 (localhost.localdomain [127.0.0.1]) by mail110-tx2
	(MessageSwitch) id 1325630943241288_24803;
	Tue,  3 Jan 2012 22:49:03 +0000 (UTC)
Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.245])	by
	mail110-tx2.bigfish.com (Postfix) with ESMTP id 295DC440058;
	Tue,  3 Jan 2012 22:49:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Jan 2012 22:49:00 +0000
X-WSS-ID: 0LX8VDK-01-430-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 20A64102800C;	Tue,  3 Jan 2012 16:48: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, 3 Jan 2012 16:49:08 -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, 3 Jan 2012 16:48: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; Tue, 3 Jan 2012
	17:48:57 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8410E49C58B; Tue,  3 Jan 2012
	22:48:56 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 7CC772D202B; Tue,
	3 Jan 2012 23:48:56 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: a063cab704c21c7adc2d69c47b50433294f9cd02
Message-ID: <a063cab704c21c7adc2d.1325630926@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Tue, 3 Jan 2012 23:48:46 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <keith.coleman@n2servers.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, wei.huang2@amd.com, keir@xen.org,
	xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Xen 3.4: x86/ucode: fix for AMD Fam15 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

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1324656297 18000
# Node ID a063cab704c21c7adc2d69c47b50433294f9cd02
# Parent  548923a4fcf66b51d6d5332f5de575116e2ce67a
Xen 3.4: 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: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
xen-unstable changeset: 24412:ca5f588bd203
xen-unstable date: Thu Dec 15 11:00:09 2011 +0100

diff -r 548923a4fcf6 -r a063cab704c2 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Tue Dec 20 20:50:49 2011 -0500
+++ b/xen/arch/x86/microcode_amd.c	Fri Dec 23 11:04:57 2011 -0500
@@ -33,11 +33,11 @@
 #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))
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
+};
 
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
@@ -66,10 +66,10 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
 
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-    struct microcode_header_amd *mc_header = mc;
+    struct microcode_header_amd *mc_header = mc_amd->mpb;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
     unsigned int i;
@@ -98,9 +98,9 @@ static int microcode_fits(void *mc, int 
 
     if ( !equiv_cpu_id )
     {
-        printk(KERN_ERR "microcode: CPU%d cpu_id "
+        printk(KERN_INFO "microcode: CPU%d cpu_id "
                "not found in equivalent cpu table\n", cpu);
-        return -EINVAL;
+        return 0;
     }
 
     if ( (mc_header->processor_rev_id) != equiv_cpu_id )
@@ -112,14 +112,14 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+	return 0;
 
     printk(KERN_INFO "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
 
 out:
-    return 0;
+    return 1;
 }
 
 static int apply_microcode(int cpu)
@@ -128,16 +128,21 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
     uint32_t rev, dummy;
     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);
 
     if ( mc_amd == NULL )
-        return -EINVAL;
+	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 */
     rdmsr(MSR_AMD_PATCHLEVEL, rev, dummy);
@@ -145,61 +150,67 @@ 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("microcode: CPU%d updated from revision "
            "0x%x to 0x%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)
 {
-    struct microcode_header_amd *mc_header;
-    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;
     }
 
-    mc_header = (struct microcode_header_amd *)(&bufp[off+8]);
+    printk(KERN_INFO "microcode: size %lu, total_size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
-
-    printk(KERN_INFO "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;
 }
@@ -254,7 +265,7 @@ static int cpu_request_microcode(int cpu
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-    void *mc;
+    struct microcode_amd *mc_amd, *mc_old;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -275,8 +286,8 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc == NULL )
+    mc_amd = xmalloc(struct microcode_amd);
+    if ( mc_amd == NULL )
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
@@ -284,32 +295,37 @@ static int cpu_request_microcode(int cpu
         goto out;
     }
 
+    mc_old = uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd = mc;
+    uci->mc.mc_amd = mc_amd;
 
     /*
      * 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)
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, size,
+						  &offset)) == 0 )
     {
-        error = microcode_fits(mc, cpu);
-        if (error != 0)
+        error = microcode_fits(mc_amd, cpu);
+        if (error <= 0)
             continue;
 
         error = apply_microcode(cpu);
-        if (error == 0)
+        if (error == 0) {
+	    error = 1;
             break;
+	}
     }
 
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc = NULL;
+    if (error == 1) {
+	xfree(mc_old);
+	return 0;
     }
-    uci->mc.mc_amd = mc;
 
 out:
     xfree(equiv_cpu_table);
diff -r 548923a4fcf6 -r a063cab704c2 xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Tue Dec 20 20:50:49 2011 -0500
+++ b/xen/include/asm-x86/microcode.h	Fri Dec 23 11:04:57 2011 -0500
@@ -69,8 +69,8 @@ struct microcode_header_amd {
 } __attribute__((packed));
 
 struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
+    void *mpb;
+    size_t mpb_size;
 };
 
 struct cpu_signature {


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 22:49:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 22: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 1RiDAP-0005pk-QJ; Tue, 03 Jan 2012 22:49:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RiDAO-0005pc-4C
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 22:49:12 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325630944!9001847!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 1167 invoked from network); 3 Jan 2012 22:49:05 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-13.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	3 Jan 2012 22:49:05 -0000
Received: from mail110-tx2-R.bigfish.com (10.9.14.240) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Jan 2012 22:49:04 +0000
Received: from mail110-tx2 (localhost [127.0.0.1])	by
	mail110-tx2-R.bigfish.com (Postfix) with ESMTP id 061344C02F6;
	Tue,  3 Jan 2012 22:49:04 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dh668h839h944h63h)
X-Spam-TCS-SCL: 2: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 mail110-tx2 (localhost.localdomain [127.0.0.1]) by mail110-tx2
	(MessageSwitch) id 1325630943241288_24803;
	Tue,  3 Jan 2012 22:49:03 +0000 (UTC)
Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.245])	by
	mail110-tx2.bigfish.com (Postfix) with ESMTP id 295DC440058;
	Tue,  3 Jan 2012 22:49:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server id
	14.1.225.23; Tue, 3 Jan 2012 22:49:00 +0000
X-WSS-ID: 0LX8VDK-01-430-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 20A64102800C;	Tue,  3 Jan 2012 16:48: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, 3 Jan 2012 16:49:08 -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, 3 Jan 2012 16:48: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; Tue, 3 Jan 2012
	17:48:57 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8410E49C58B; Tue,  3 Jan 2012
	22:48:56 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 7CC772D202B; Tue,
	3 Jan 2012 23:48:56 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: a063cab704c21c7adc2d69c47b50433294f9cd02
Message-ID: <a063cab704c21c7adc2d.1325630926@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Tue, 3 Jan 2012 23:48:46 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <keith.coleman@n2servers.com>
X-OriginatorOrg: amd.com
Cc: Christoph.Egger@amd.com, wei.huang2@amd.com, keir@xen.org,
	xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Xen 3.4: x86/ucode: fix for AMD Fam15 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

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1324656297 18000
# Node ID a063cab704c21c7adc2d69c47b50433294f9cd02
# Parent  548923a4fcf66b51d6d5332f5de575116e2ce67a
Xen 3.4: 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: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>
xen-unstable changeset: 24412:ca5f588bd203
xen-unstable date: Thu Dec 15 11:00:09 2011 +0100

diff -r 548923a4fcf6 -r a063cab704c2 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Tue Dec 20 20:50:49 2011 -0500
+++ b/xen/arch/x86/microcode_amd.c	Fri Dec 23 11:04:57 2011 -0500
@@ -33,11 +33,11 @@
 #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))
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
+};
 
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
@@ -66,10 +66,10 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
 
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-    struct microcode_header_amd *mc_header = mc;
+    struct microcode_header_amd *mc_header = mc_amd->mpb;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
     unsigned int i;
@@ -98,9 +98,9 @@ static int microcode_fits(void *mc, int 
 
     if ( !equiv_cpu_id )
     {
-        printk(KERN_ERR "microcode: CPU%d cpu_id "
+        printk(KERN_INFO "microcode: CPU%d cpu_id "
                "not found in equivalent cpu table\n", cpu);
-        return -EINVAL;
+        return 0;
     }
 
     if ( (mc_header->processor_rev_id) != equiv_cpu_id )
@@ -112,14 +112,14 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+	return 0;
 
     printk(KERN_INFO "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
 
 out:
-    return 0;
+    return 1;
 }
 
 static int apply_microcode(int cpu)
@@ -128,16 +128,21 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
     uint32_t rev, dummy;
     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);
 
     if ( mc_amd == NULL )
-        return -EINVAL;
+	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 */
     rdmsr(MSR_AMD_PATCHLEVEL, rev, dummy);
@@ -145,61 +150,67 @@ 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("microcode: CPU%d updated from revision "
            "0x%x to 0x%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)
 {
-    struct microcode_header_amd *mc_header;
-    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;
     }
 
-    mc_header = (struct microcode_header_amd *)(&bufp[off+8]);
+    printk(KERN_INFO "microcode: size %lu, total_size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
-
-    printk(KERN_INFO "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;
 }
@@ -254,7 +265,7 @@ static int cpu_request_microcode(int cpu
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-    void *mc;
+    struct microcode_amd *mc_amd, *mc_old;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -275,8 +286,8 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc == NULL )
+    mc_amd = xmalloc(struct microcode_amd);
+    if ( mc_amd == NULL )
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
@@ -284,32 +295,37 @@ static int cpu_request_microcode(int cpu
         goto out;
     }
 
+    mc_old = uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd = mc;
+    uci->mc.mc_amd = mc_amd;
 
     /*
      * 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)
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, size,
+						  &offset)) == 0 )
     {
-        error = microcode_fits(mc, cpu);
-        if (error != 0)
+        error = microcode_fits(mc_amd, cpu);
+        if (error <= 0)
             continue;
 
         error = apply_microcode(cpu);
-        if (error == 0)
+        if (error == 0) {
+	    error = 1;
             break;
+	}
     }
 
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc = NULL;
+    if (error == 1) {
+	xfree(mc_old);
+	return 0;
     }
-    uci->mc.mc_amd = mc;
 
 out:
     xfree(equiv_cpu_table);
diff -r 548923a4fcf6 -r a063cab704c2 xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Tue Dec 20 20:50:49 2011 -0500
+++ b/xen/include/asm-x86/microcode.h	Fri Dec 23 11:04:57 2011 -0500
@@ -69,8 +69,8 @@ struct microcode_header_amd {
 } __attribute__((packed));
 
 struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
+    void *mpb;
+    size_t mpb_size;
 };
 
 struct cpu_signature {


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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 23:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 23:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiDdv-00069b-P9; Tue, 03 Jan 2012 23:19:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1RiDdt-00069W-LC
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 23:19:41 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1325632775!9492500!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 24972 invoked from network); 3 Jan 2012 23:19:35 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 23:19:35 -0000
Received: by eaad11 with SMTP id d11so55879087eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 15:19:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.156.210 with SMTP id y18mr12866883bkw.118.1325632775001;
	Tue, 03 Jan 2012 15:19:35 -0800 (PST)
Received: by 10.204.70.18 with HTTP; Tue, 3 Jan 2012 15:19:34 -0800 (PST)
X-Originating-IP: [71.56.71.211]
In-Reply-To: <a063cab704c21c7adc2d.1325630926@wotan.osrc.amd.com>
References: <a063cab704c21c7adc2d.1325630926@wotan.osrc.amd.com>
Date: Tue, 3 Jan 2012 18:19:34 -0500
Message-ID: <CAH4C7zGkM8-Zi7j2wz0_KbG3TjGQkUxQS+nf0xKAzhzmV7=n3A@mail.gmail.com>
From: Keith Coleman <keith.coleman@n2servers.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
Cc: Christoph.Egger@amd.com, wei.huang2@amd.com, keir@xen.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Xen 3.4: x86/ucode: fix for AMD Fam15 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 3, 2012 at 5:48 PM, Boris Ostrovsky <boris.ostrovsky@amd.com> w=
rote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1324656297 18000
> # Node ID a063cab704c21c7adc2d69c47b50433294f9cd02
> # Parent =A0548923a4fcf66b51d6d5332f5de575116e2ce67a
> Xen 3.4: 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: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> xen-unstable changeset: 24412:ca5f588bd203
> xen-unstable date: Thu Dec 15 11:00:09 2011 +0100

Thanks! This patch will make the upcoming xen-3.4.4 release.

Keith Coleman

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 23:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 23:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiDdv-00069b-P9; Tue, 03 Jan 2012 23:19:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1RiDdt-00069W-LC
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 23:19:41 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1325632775!9492500!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 24972 invoked from network); 3 Jan 2012 23:19:35 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 23:19:35 -0000
Received: by eaad11 with SMTP id d11so55879087eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 15:19:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.156.210 with SMTP id y18mr12866883bkw.118.1325632775001;
	Tue, 03 Jan 2012 15:19:35 -0800 (PST)
Received: by 10.204.70.18 with HTTP; Tue, 3 Jan 2012 15:19:34 -0800 (PST)
X-Originating-IP: [71.56.71.211]
In-Reply-To: <a063cab704c21c7adc2d.1325630926@wotan.osrc.amd.com>
References: <a063cab704c21c7adc2d.1325630926@wotan.osrc.amd.com>
Date: Tue, 3 Jan 2012 18:19:34 -0500
Message-ID: <CAH4C7zGkM8-Zi7j2wz0_KbG3TjGQkUxQS+nf0xKAzhzmV7=n3A@mail.gmail.com>
From: Keith Coleman <keith.coleman@n2servers.com>
To: Boris Ostrovsky <boris.ostrovsky@amd.com>
Cc: Christoph.Egger@amd.com, wei.huang2@amd.com, keir@xen.org,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Xen 3.4: x86/ucode: fix for AMD Fam15 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 3, 2012 at 5:48 PM, Boris Ostrovsky <boris.ostrovsky@amd.com> w=
rote:
> # HG changeset patch
> # User Boris Ostrovsky <boris.ostrovsky@amd.com>
> # Date 1324656297 18000
> # Node ID a063cab704c21c7adc2d69c47b50433294f9cd02
> # Parent =A0548923a4fcf66b51d6d5332f5de575116e2ce67a
> Xen 3.4: 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: Boris Ostrovsky <boris.ostrovsky@amd.com>
> Acked-by: Christoph Egger <Christoph.Egger@amd.com>
> xen-unstable changeset: 24412:ca5f588bd203
> xen-unstable date: Thu Dec 15 11:00:09 2011 +0100

Thanks! This patch will make the upcoming xen-3.4.4 release.

Keith Coleman

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 23:45:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 23: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 1RiE2U-0006OJ-05; Tue, 03 Jan 2012 23:45:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiE2T-0006OE-0f
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 23:45:05 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325634187!58288667!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 30982 invoked from network); 3 Jan 2012 23:43:10 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Jan 2012 23:43:10 -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 1RiE2J-0001LW-FB; Wed, 04 Jan 2012 10:44:55 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 10:44:55 +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;
	Wed, 4 Jan 2012 10:44:54 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAAMtxEA==
Date: Tue, 3 Jan 2012 23:44:53 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B093177@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
In-Reply-To: <20120103223610.GB12939@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Jan 2012 23:44:55.0234 (UTC)
	FILETIME=[B1F06A20:01CCCA71]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 
> Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> 
> They also moved - to drivers/scsi.

My git-foo is a bit rusty. Having cloned the tree, how do I check out the remote branch?

James

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 23:45:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 23: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 1RiE2U-0006OJ-05; Tue, 03 Jan 2012 23:45:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiE2T-0006OE-0f
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 23:45:05 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325634187!58288667!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 30982 invoked from network); 3 Jan 2012 23:43:10 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-8.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	3 Jan 2012 23:43:10 -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 1RiE2J-0001LW-FB; Wed, 04 Jan 2012 10:44:55 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 10:44:55 +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;
	Wed, 4 Jan 2012 10:44:54 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAAMtxEA==
Date: Tue, 3 Jan 2012 23:44:53 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B093177@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
In-Reply-To: <20120103223610.GB12939@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Jan 2012 23:44:55.0234 (UTC)
	FILETIME=[B1F06A20:01CCCA71]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 
> Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> 
> They also moved - to drivers/scsi.

My git-foo is a bit rusty. Having cloned the tree, how do I check out the remote branch?

James

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 23:52:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 23:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiE8k-0006XO-RB; Tue, 03 Jan 2012 23:51:34 +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 1RiE8j-0006XE-L8
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 23:51:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325634686!9488503!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24778 invoked from network); 3 Jan 2012 23:51:27 -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; 3 Jan 2012 23:51: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
	q03No6m2008146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 23:50:07 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
	q03No5Kb029844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 23:50:06 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
	q03No5Rg005793; Tue, 3 Jan 2012 17:50:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 15:50:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E991740452; Tue,  3 Jan 2012 18:48:33 -0500 (EST)
Date: Tue, 3 Jan 2012 18:48:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120103234833.GB19899@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B093177@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B093177@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F039430.001A,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Tue, Jan 03, 2012 at 11:44:53PM +0000, James Harper wrote:
> > > Or maybe someone else already has scsiback working against 3.x.x?
> > 
> > I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> > merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> > changed - but you could alter it yourself if you are using the 3.0 tree).
> > 
> > Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > 
> > They also moved - to drivers/scsi.
> 
> My git-foo is a bit rusty. Having cloned the tree, how do I check out the remote branch?

git checkout origin/testing

> 
> James

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

From xen-devel-bounces@lists.xensource.com Tue Jan 03 23:52:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 03 Jan 2012 23:52:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiE8k-0006XO-RB; Tue, 03 Jan 2012 23:51:34 +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 1RiE8j-0006XE-L8
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 23:51:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325634686!9488503!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ2ODQ1Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24778 invoked from network); 3 Jan 2012 23:51:27 -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; 3 Jan 2012 23:51: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
	q03No6m2008146
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 23:50:07 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
	q03No5Kb029844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 3 Jan 2012 23:50:06 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
	q03No5Rg005793; Tue, 3 Jan 2012 17:50:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 03 Jan 2012 15:50:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E991740452; Tue,  3 Jan 2012 18:48:33 -0500 (EST)
Date: Tue, 3 Jan 2012 18:48:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120103234833.GB19899@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B093177@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B093177@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F039430.001A,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Tue, Jan 03, 2012 at 11:44:53PM +0000, James Harper wrote:
> > > Or maybe someone else already has scsiback working against 3.x.x?
> > 
> > I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> > merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> > changed - but you could alter it yourself if you are using the 3.0 tree).
> > 
> > Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > 
> > They also moved - to drivers/scsi.
> 
> My git-foo is a bit rusty. Having cloned the tree, how do I check out the remote branch?

git checkout origin/testing

> 
> James

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 00:21:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 00: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 1RiEbZ-0007Ru-71; Wed, 04 Jan 2012 00:21:21 +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 1RiEbX-0007Rp-DF
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 00:21:19 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325636469!7510262!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 14016 invoked from network); 4 Jan 2012 00:21:12 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-14.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 00:21:12 -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 1RiEbE-0003q3-3b; Wed, 04 Jan 2012 11:21:00 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 11:21:00 +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;
	Wed, 4 Jan 2012 11:20:58 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAANTh8A==
Date: Wed, 4 Jan 2012 00:20:57 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0931EF@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
In-Reply-To: <20120103223610.GB12939@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2012 00:21:00.0274 (UTC)
	FILETIME=[BC674D20:01CCCA76]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> >
> > Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it
> > compiled against jeremy's 2.6.32 tree (out-of-tree build though). That
> > worked fine, and I didn't need scsifront as gplpv is the front end.
> 
> Ah, you are using the Windows Xen SCSI driver. Cool. Excited to know it
> works that well.

Yes I do restores from tape to Windows VM's using Symantec Backup Exec IDR.

> >
> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 

What is the changed argument? I see a couple of #defines that aren't present in 3.1.0 (GNTST_eagain and DEFINE_XENBUS_DRIVER), but having built it I'm now getting a crash when I try and load the module.

Also, there are some includes in vscsiif.h that are unnecessary as they are included by common.h... do you think they could be removed?

James


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 00:21:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 00: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 1RiEbZ-0007Ru-71; Wed, 04 Jan 2012 00:21:21 +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 1RiEbX-0007Rp-DF
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 00:21:19 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325636469!7510262!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 14016 invoked from network); 4 Jan 2012 00:21:12 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-14.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 00:21:12 -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 1RiEbE-0003q3-3b; Wed, 04 Jan 2012 11:21:00 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 11:21:00 +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;
	Wed, 4 Jan 2012 11:20:58 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAANTh8A==
Date: Wed, 4 Jan 2012 00:20:57 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0931EF@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
In-Reply-To: <20120103223610.GB12939@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2012 00:21:00.0274 (UTC)
	FILETIME=[BC674D20:01CCCA76]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> >
> > Quite a while ago I grabbed scsiback out of 2.6.18 and patched it up so it
> > compiled against jeremy's 2.6.32 tree (out-of-tree build though). That
> > worked fine, and I didn't need scsifront as gplpv is the front end.
> 
> Ah, you are using the Windows Xen SCSI driver. Cool. Excited to know it
> works that well.

Yes I do restores from tape to Windows VM's using Symantec Backup Exec IDR.

> >
> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 

What is the changed argument? I see a couple of #defines that aren't present in 3.1.0 (GNTST_eagain and DEFINE_XENBUS_DRIVER), but having built it I'm now getting a crash when I try and load the module.

Also, there are some includes in vscsiif.h that are unnecessary as they are included by common.h... do you think they could be removed?

James


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 01:05:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 01:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiFHR-00036u-Nx; Wed, 04 Jan 2012 01:04:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1RiFHN-00036p-0D
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 01:04:33 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1325639065!9558943!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjk2Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31698 invoked from network); 4 Jan 2012 01:04:26 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-21.messagelabs.com with SMTP;
	4 Jan 2012 01:04:26 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Jan 2012 17:04:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="102900112"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 03 Jan 2012 17:04:23 -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; Wed, 4 Jan 2012 09:04: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; Wed, 4 Jan 2012 09:04:22 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>, "Zhou, Chao"
	<chao.zhou@intel.com>
Thread-Topic: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
Thread-Index: AQHMyjxrdypQP5pCF06vy0BLmB+SI5X7Ysnw
Date: Wed, 4 Jan 2012 01:04:21 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100101FF@SHSMSX101.ccr.corp.intel.com>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
	<20111229173208.GA18032@phenom.dumpdata.com>
	<20120103172007.GD749@andromeda.dapyr.net>
In-Reply-To: <20120103172007.GD749@andromeda.dapyr.net>
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>, "Zhou,
	Chao" <chao.zhou@intel.com>
Subject: Re: [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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Konrad
> Rzeszutek Wilk
> Sent: Wednesday, January 04, 2012 1:20 AM
> To: Zhou, Chao
> Cc: xen-devel@lists.xensource.com; Zhou, Chao
> Subject: Re: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
> 
> On Thu, Dec 29, 2011 at 12:32:08PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Dec 29, 2011 at 08:42:17AM +0000, Zhou, Chao wrote:
> > > 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
> >
> > When are you guys planning to switch to the upstream kernel?
> 
> ping? As in the 3.0 or 3.1 or 3.2.x kernel?
> 
We still wait for some PM and RAS patches to be merged into upstream. As you may know, Jinsong is dong RAS rebase to your 3.1 dom0 tree.
Switching to upstream kernel is in our plan. If these patches is in upstream, we'll switch to upstream kernel or 3.1 kernel.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 04 01:05:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 01:05:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiFHR-00036u-Nx; Wed, 04 Jan 2012 01:04:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1RiFHN-00036p-0D
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 01:04:33 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1325639065!9558943!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMjk2Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31698 invoked from network); 4 Jan 2012 01:04:26 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-14.tower-21.messagelabs.com with SMTP;
	4 Jan 2012 01:04:26 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga102.fm.intel.com with ESMTP; 03 Jan 2012 17:04:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="102900112"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 03 Jan 2012 17:04:23 -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; Wed, 4 Jan 2012 09:04: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; Wed, 4 Jan 2012 09:04:22 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>, "Zhou, Chao"
	<chao.zhou@intel.com>
Thread-Topic: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
Thread-Index: AQHMyjxrdypQP5pCF06vy0BLmB+SI5X7Ysnw
Date: Wed, 4 Jan 2012 01:04:21 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100101FF@SHSMSX101.ccr.corp.intel.com>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
	<20111229173208.GA18032@phenom.dumpdata.com>
	<20120103172007.GD749@andromeda.dapyr.net>
In-Reply-To: <20120103172007.GD749@andromeda.dapyr.net>
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>, "Zhou,
	Chao" <chao.zhou@intel.com>
Subject: Re: [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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Konrad
> Rzeszutek Wilk
> Sent: Wednesday, January 04, 2012 1:20 AM
> To: Zhou, Chao
> Cc: xen-devel@lists.xensource.com; Zhou, Chao
> Subject: Re: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
> 
> On Thu, Dec 29, 2011 at 12:32:08PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Thu, Dec 29, 2011 at 08:42:17AM +0000, Zhou, Chao wrote:
> > > 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
> >
> > When are you guys planning to switch to the upstream kernel?
> 
> ping? As in the 3.0 or 3.1 or 3.2.x kernel?
> 
We still wait for some PM and RAS patches to be merged into upstream. As you may know, Jinsong is dong RAS rebase to your 3.1 dom0 tree.
Switching to upstream kernel is in our plan. If these patches is in upstream, we'll switch to upstream kernel or 3.1 kernel.

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 04 01:56:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 01: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 1RiG4d-0003Qq-Cc; Wed, 04 Jan 2012 01:55:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiG4b-0003Ql-RV
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 01:55:26 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325642072!48837520!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 19483 invoked from network); 4 Jan 2012 01:54:35 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 01:54:35 -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 1RiFzS-0001fj-Tb; Wed, 04 Jan 2012 12:50:06 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 12:50:05 +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;
	Wed, 4 Jan 2012 12:50:03 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAAO3gMA==
Date: Wed, 4 Jan 2012 01:50:03 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
In-Reply-To: <20120103223610.GB12939@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2012 01:50:05.0595 (UTC)
	FILETIME=[2E768EB0:01CCCA83]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 
> Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> 

Okay I have it compiling and loading now (that xenbus init macro obviously isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device - it just hangs for a while then says hotplug didn't work.

Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre I'm running now?

Thanks

James

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 01:56:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 01: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 1RiG4d-0003Qq-Cc; Wed, 04 Jan 2012 01:55:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiG4b-0003Ql-RV
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 01:55:26 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325642072!48837520!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 19483 invoked from network); 4 Jan 2012 01:54:35 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-5.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 01:54:35 -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 1RiFzS-0001fj-Tb; Wed, 04 Jan 2012 12:50:06 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 12:50:05 +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;
	Wed, 4 Jan 2012 12:50:03 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAAO3gMA==
Date: Wed, 4 Jan 2012 01:50:03 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
In-Reply-To: <20120103223610.GB12939@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2012 01:50:05.0595 (UTC)
	FILETIME=[2E768EB0:01CCCA83]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> > Or maybe someone else already has scsiback working against 3.x.x?
> 
> I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> changed - but you could alter it yourself if you are using the 3.0 tree).
> 
> Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> 

Okay I have it compiling and loading now (that xenbus init macro obviously isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device - it just hangs for a while then says hotplug didn't work.

Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre I'm running now?

Thanks

James

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 02:21:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 02: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 1RiGSw-0003yl-Jl; Wed, 04 Jan 2012 02:20:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiGSv-0003yg-2X
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 02:20:33 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325643623!9634376!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 22347 invoked from network); 4 Jan 2012 02:20:26 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 02:20:26 -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 1RiGSi-0001k1-FL
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 13:20:20 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 13:20:20 +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;
	Wed, 4 Jan 2012 13:20:18 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: /bin/sh vs trap in vscsi hotplug script
Thread-Index: AczKh2a3bxZ4l513TRelRWbobE/Fiw==
Date: Wed, 4 Jan 2012 02:20:18 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B094067@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: 04 Jan 2012 02:20:20.0322 (UTC)
	FILETIME=[681FEC20:01CCCA87]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] /bin/sh vs trap in vscsi 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

The other hotplug scripts have #!/bin/bash but vscsi has #!/bin/sh, and I think that trap in xen-hotplug-common.sh is a bashism, or at least isn't liked by the Debian default shell dash.

What is the bug here? The incompatible shell specified in vscsi hotplug script, or "trap sigerr ERR" in xen-hotplug-common.sh?

Thanks

James

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 02:21:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 02: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 1RiGSw-0003yl-Jl; Wed, 04 Jan 2012 02:20:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiGSv-0003yg-2X
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 02:20:33 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325643623!9634376!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 22347 invoked from network); 4 Jan 2012 02:20:26 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 02:20:26 -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 1RiGSi-0001k1-FL
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 13:20:20 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 13:20:20 +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;
	Wed, 4 Jan 2012 13:20:18 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: /bin/sh vs trap in vscsi hotplug script
Thread-Index: AczKh2a3bxZ4l513TRelRWbobE/Fiw==
Date: Wed, 4 Jan 2012 02:20:18 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B094067@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: 04 Jan 2012 02:20:20.0322 (UTC)
	FILETIME=[681FEC20:01CCCA87]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] /bin/sh vs trap in vscsi 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

The other hotplug scripts have #!/bin/bash but vscsi has #!/bin/sh, and I think that trap in xen-hotplug-common.sh is a bashism, or at least isn't liked by the Debian default shell dash.

What is the bug here? The incompatible shell specified in vscsi hotplug script, or "trap sigerr ERR" in xen-hotplug-common.sh?

Thanks

James

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 03:45:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 03:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiHmW-0004Qw-Cn; Wed, 04 Jan 2012 03:44:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiHmU-0004Qo-W9
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 03:44:51 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325648681!9487014!1
X-Originating-IP: [203.16.207.99]
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 24131 invoked from network); 4 Jan 2012 03:44:44 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 03:44:44 -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 1RiHmF-0001wf-MK; Wed, 04 Jan 2012 14:44:35 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 14:44:34 +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;
	Wed, 4 Jan 2012 14:44:32 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: James Harper <james.harper@bendigoit.com.au>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAAO3gMIAACpyA
Date: Wed, 4 Jan 2012 03:44:32 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094042@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: 04 Jan 2012 03:44:34.0883 (UTC)
	FILETIME=[2CE0B930:01CCCA93]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> Okay I have it compiling and loading now (that xenbus init macro obviously
> isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device -
> it just hangs for a while then says hotplug didn't work.
> 
> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
> I'm running now?
> 

Loading and detecting properly now (see email about the choice of shell in the vscsi script), and appears to be restoring with the following patch:

--- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 10:51:36.090985303 +1100
+++ emulate.c   2012-01-04 13:28:23.288336520 +1100
@@ -401,8 +401,8 @@
        NO_EMULATE(INQUIRY);               /*0x12*/
        /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
        NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
-       /*NO_EMULATE(RESERVE);               *//*0x16*/
-       /*NO_EMULATE(RELEASE);               *//*0x17*/
+       NO_EMULATE(RESERVE);               /*0x16*/
+       NO_EMULATE(RELEASE);               /*0x17*/
        /*NO_EMULATE(COPY);                  *//*0x18*/
        NO_EMULATE(ERASE);                 /*0x19*/ /* st */
        NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */

James


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 03:45:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 03:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiHmW-0004Qw-Cn; Wed, 04 Jan 2012 03:44:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiHmU-0004Qo-W9
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 03:44:51 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325648681!9487014!1
X-Originating-IP: [203.16.207.99]
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 24131 invoked from network); 4 Jan 2012 03:44:44 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-9.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 03:44:44 -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 1RiHmF-0001wf-MK; Wed, 04 Jan 2012 14:44:35 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 14:44:34 +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;
	Wed, 4 Jan 2012 14:44:32 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: James Harper <james.harper@bendigoit.com.au>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAAO3gMIAACpyA
Date: Wed, 4 Jan 2012 03:44:32 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094042@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: 04 Jan 2012 03:44:34.0883 (UTC)
	FILETIME=[2CE0B930:01CCCA93]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> Okay I have it compiling and loading now (that xenbus init macro obviously
> isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device -
> it just hangs for a while then says hotplug didn't work.
> 
> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
> I'm running now?
> 

Loading and detecting properly now (see email about the choice of shell in the vscsi script), and appears to be restoring with the following patch:

--- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 10:51:36.090985303 +1100
+++ emulate.c   2012-01-04 13:28:23.288336520 +1100
@@ -401,8 +401,8 @@
        NO_EMULATE(INQUIRY);               /*0x12*/
        /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
        NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
-       /*NO_EMULATE(RESERVE);               *//*0x16*/
-       /*NO_EMULATE(RELEASE);               *//*0x17*/
+       NO_EMULATE(RESERVE);               /*0x16*/
+       NO_EMULATE(RELEASE);               /*0x17*/
        /*NO_EMULATE(COPY);                  *//*0x18*/
        NO_EMULATE(ERASE);                 /*0x19*/ /* st */
        NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */

James


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 04:39:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 04:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiIcz-0004rD-1P; Wed, 04 Jan 2012 04:39:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RiIcx-0004r8-Mp
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 04:39:03 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325651936!5879635!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNDEyMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15171 invoked from network); 4 Jan 2012 04:38:57 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-15.tower-174.messagelabs.com with SMTP;
	4 Jan 2012 04:38:57 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LX900GSGBIJUF@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 04 Jan 2012 12:37:32 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LX9007KSBIJUV@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 04 Jan 2012 12:37:31 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGB95546; Wed,
	04 Jan 2012 12:37:31 +0800
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159)
	by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 04 Jan 2012 12:37:27 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml420-hub.china.huawei.com ([10.82.67.159])
	with mapi id 14.01.0323.003; Wed, 04 Jan 2012 12:37:13 +0800
Date: Wed, 04 Jan 2012 04:37:12 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2DF1A@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AczKmoTwILX6pqEgSeyUOnJ07+x4Tw==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Cc: Qianhuibin <qianhuibin@huawei.com>
Subject: [Xen-devel] [xen-devel] create irq failed due to move_cleanup_count
 always being 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

Hi, all
   
    I'm using xen-4.0 to do a test. And when I create a domain, it failed due to create_irq() failure. As only 33 domains were successfully created and destroyed before I got the continuous failures, and the domain just before the failure was properly destroyed(at least destroy_irq() was properly called, which will clear move_in_progress, according to the prink-message). So I can conclude for certain that __assign_irq_vector failed due to move_cleanup_count always being set. 

//this is the normal case when create and destroy domain whose id is 31;
(XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
(XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
(XEN) irq.c:1593: dom31: forcing unbind of pirq 79
(XEN) irq.c:223, destroy irq 77

//domain id 32 is created and destroyed correctly also.
(XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
(XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
(XEN) irq.c:1593: dom32: forcing unbind of pirq 79
(XEN) irq.c:223, destroy irq 77

//all the subsequent domain creation failed, below lists only 3 times:
(XEN) physdev.c:88: dom33: can't create irq for msi!
(XEN) physdev.c:88: dom34: can't create irq for msi!
(XEN) physdev.c:88: dom35: can't create irq for msi!

     I think this might be a bug and might have fixed, so I compare my code with 4.1.2 and search the mail list for potential patches. (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanup_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which add locks in __assign_irq_vector. Can anybody explain why this lock is needed? Or is there a patch that might fix my bug? Thx.

    Addition message: my board is arch-x86, no domains left when failed to create new ones, create_irq failure lasted one day until I reboot the board, and the irq number allocated is used certainly for a msi dev.

Yong an Liu
2012.1.4

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 04:39:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 04:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiIcz-0004rD-1P; Wed, 04 Jan 2012 04:39:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RiIcx-0004r8-Mp
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 04:39:03 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325651936!5879635!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNDEyMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15171 invoked from network); 4 Jan 2012 04:38:57 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-15.tower-174.messagelabs.com with SMTP;
	4 Jan 2012 04:38:57 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LX900GSGBIJUF@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 04 Jan 2012 12:37:32 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LX9007KSBIJUV@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 04 Jan 2012 12:37:31 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGB95546; Wed,
	04 Jan 2012 12:37:31 +0800
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159)
	by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 04 Jan 2012 12:37:27 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml420-hub.china.huawei.com ([10.82.67.159])
	with mapi id 14.01.0323.003; Wed, 04 Jan 2012 12:37:13 +0800
Date: Wed, 04 Jan 2012 04:37:12 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2DF1A@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AczKmoTwILX6pqEgSeyUOnJ07+x4Tw==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Cc: Qianhuibin <qianhuibin@huawei.com>
Subject: [Xen-devel] [xen-devel] create irq failed due to move_cleanup_count
 always being 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

Hi, all
   
    I'm using xen-4.0 to do a test. And when I create a domain, it failed due to create_irq() failure. As only 33 domains were successfully created and destroyed before I got the continuous failures, and the domain just before the failure was properly destroyed(at least destroy_irq() was properly called, which will clear move_in_progress, according to the prink-message). So I can conclude for certain that __assign_irq_vector failed due to move_cleanup_count always being set. 

//this is the normal case when create and destroy domain whose id is 31;
(XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
(XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
(XEN) irq.c:1593: dom31: forcing unbind of pirq 79
(XEN) irq.c:223, destroy irq 77

//domain id 32 is created and destroyed correctly also.
(XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
(XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
(XEN) irq.c:1593: dom32: forcing unbind of pirq 79
(XEN) irq.c:223, destroy irq 77

//all the subsequent domain creation failed, below lists only 3 times:
(XEN) physdev.c:88: dom33: can't create irq for msi!
(XEN) physdev.c:88: dom34: can't create irq for msi!
(XEN) physdev.c:88: dom35: can't create irq for msi!

     I think this might be a bug and might have fixed, so I compare my code with 4.1.2 and search the mail list for potential patches. (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanup_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which add locks in __assign_irq_vector. Can anybody explain why this lock is needed? Or is there a patch that might fix my bug? Thx.

    Addition message: my board is arch-x86, no domains left when failed to create new ones, create_irq failure lasted one day until I reboot the board, and the irq number allocated is used certainly for a msi dev.

Yong an Liu
2012.1.4

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 05:09:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 05:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiJ5U-0005H9-KL; Wed, 04 Jan 2012 05:08: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 1RiJ5T-0005H4-MN
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 05:08:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325653667!48923941!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26347 invoked from network); 4 Jan 2012 05:07:47 -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;
	4 Jan 2012 05:07:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,454,1320624000"; 
   d="scan'208";a="9802559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 05:08: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, 4 Jan 2012 05:08: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 1RiJ5S-0004hR-6w;
	Wed, 04 Jan 2012 05:08:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RiJ5R-0007BX-UO;
	Wed, 04 Jan 2012 05:08:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10630-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Jan 2012 05:08:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10630: 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 10630 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10630/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10629
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10629
 test-i386-i386-xl            16 guest-start.2      fail in 10629 pass in 10630

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pv           16 guest-start.2         fail in 10629 like 10623

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-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-xl-win7-amd64 13 guest-stop           fail in 10629 never pass

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  50117a4d1a2c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Jan 04 05:09:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 05:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiJ5U-0005H9-KL; Wed, 04 Jan 2012 05:08: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 1RiJ5T-0005H4-MN
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 05:08:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325653667!48923941!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26347 invoked from network); 4 Jan 2012 05:07:47 -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;
	4 Jan 2012 05:07:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,454,1320624000"; 
   d="scan'208";a="9802559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 05:08: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, 4 Jan 2012 05:08: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 1RiJ5S-0004hR-6w;
	Wed, 04 Jan 2012 05:08:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RiJ5R-0007BX-UO;
	Wed, 04 Jan 2012 05:08:30 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10630-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Jan 2012 05:08:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10630: 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 10630 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10630/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10      fail pass in 10629
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10629
 test-i386-i386-xl            16 guest-start.2      fail in 10629 pass in 10630

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-pv           16 guest-start.2         fail in 10629 like 10623

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-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-xl-win7-amd64 13 guest-stop           fail in 10629 never pass

version targeted for testing:
 xen                  50117a4d1a2c
baseline version:
 xen                  50117a4d1a2c

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Jan 04 06:01:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 06:01:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiJtx-0005dZ-Sf; Wed, 04 Jan 2012 06:00:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1RiJtw-0005dU-Ne
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 06:00:40 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1325656778!62883991!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE4NDEy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 4 Jan 2012 05:59:39 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-27.messagelabs.com with SMTP;
	4 Jan 2012 05:59:39 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 03 Jan 2012 22:00:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="53051637"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 03 Jan 2012 22:00:36 -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, 4 Jan 2012 14:00:04 +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, 4 Jan 2012 14:00:04 +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, 4 Jan 2012 14:00:03 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Zhou, Chao" <chao.zhou@intel.com>
Thread-Topic: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
Thread-Index: AQHMySljdypQP5pCF06vy0BLmB+SI5X7uN0A
Date: Wed, 4 Jan 2012 06:00:02 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100103FC@SHSMSX101.ccr.corp.intel.com>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
	<4F0179CC0200007800069FF9@nat28.tlf.novell.com>
In-Reply-To: <4F0179CC0200007800069FF9@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>
Subject: Re: [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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Jan Beulich
> Sent: Monday, January 02, 2012 4:33 PM
> To: Zhou, Chao
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
> 
> >>> On 29.12.11 at 09:42, "Zhou, Chao" <chao.zhou@intel.com> wrote:
> > New issue(1)
> > ==============
> > 1. VF doesn't work after hot-plug for many times
> > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1798
> 
> This should be fixed with 24448:3a22ed3ec534.
> 
Yeah. I verified it with xen CS# 24450. The bug is fixed by CS#24448.
Also updated in the bugzilla.

> 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 Wed Jan 04 06:01:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 06:01:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiJtx-0005dZ-Sf; Wed, 04 Jan 2012 06:00:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1RiJtw-0005dU-Ne
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 06:00:40 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1325656778!62883991!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE4NDEy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7357 invoked from network); 4 Jan 2012 05:59:39 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-7.tower-27.messagelabs.com with SMTP;
	4 Jan 2012 05:59:39 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga101.ch.intel.com with ESMTP; 03 Jan 2012 22:00:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="53051637"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by AZSMGA002.ch.intel.com with ESMTP; 03 Jan 2012 22:00:36 -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, 4 Jan 2012 14:00:04 +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, 4 Jan 2012 14:00:04 +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, 4 Jan 2012 14:00:03 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "Zhou, Chao" <chao.zhou@intel.com>
Thread-Topic: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
Thread-Index: AQHMySljdypQP5pCF06vy0BLmB+SI5X7uN0A
Date: Wed, 4 Jan 2012 06:00:02 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A100103FC@SHSMSX101.ccr.corp.intel.com>
References: <40352EBA8B4DF841A9907B883F22B59BDD99@SHSMSX102.ccr.corp.intel.com>
	<4F0179CC0200007800069FF9@nat28.tlf.novell.com>
In-Reply-To: <4F0179CC0200007800069FF9@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>
Subject: Re: [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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Jan Beulich
> Sent: Monday, January 02, 2012 4:33 PM
> To: Zhou, Chao
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] VMX status report. Xen:24446 & Dom0: 20a27c1e...
> 
> >>> On 29.12.11 at 09:42, "Zhou, Chao" <chao.zhou@intel.com> wrote:
> > New issue(1)
> > ==============
> > 1. VF doesn't work after hot-plug for many times
> > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1798
> 
> This should be fixed with 24448:3a22ed3ec534.
> 
Yeah. I verified it with xen CS# 24450. The bug is fixed by CS#24448.
Also updated in the bugzilla.

> 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 Wed Jan 04 06:30:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 06:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiKMQ-000631-V1; Wed, 04 Jan 2012 06:30:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1RiKMO-00062w-Uo
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 06:30:05 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325658557!50803830!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 32722 invoked from network); 4 Jan 2012 06:29:17 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 06:29:17 -0000
Received: by eaad11 with SMTP id d11so56359536eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 22:30:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.148.205 with SMTP id q13mr4397159bkv.46.1325658599227;
	Tue, 03 Jan 2012 22:29:59 -0800 (PST)
Received: by 10.204.70.18 with HTTP; Tue, 3 Jan 2012 22:29:59 -0800 (PST)
X-Originating-IP: [71.56.71.211]
Date: Wed, 4 Jan 2012 01:29:59 -0500
Message-ID: <CAH4C7zG1O6n2SwKOsh+qurux-rjHpXVV6t+FX45MNmp3p-g1zg@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 third 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 third release candidate for Xen 3.4.4 is tagged at:
http://xenbits.xensource.com/xen-3.4-testing.hg (tag '3.4.4-rc3')

Please test and give feedback! This will likely be the last release candidate.

--

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 Jan 04 06:30:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 06:30:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiKMQ-000631-V1; Wed, 04 Jan 2012 06:30:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1RiKMO-00062w-Uo
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 06:30:05 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325658557!50803830!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 32722 invoked from network); 4 Jan 2012 06:29:17 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 06:29:17 -0000
Received: by eaad11 with SMTP id d11so56359536eaa.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 22:30:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.148.205 with SMTP id q13mr4397159bkv.46.1325658599227;
	Tue, 03 Jan 2012 22:29:59 -0800 (PST)
Received: by 10.204.70.18 with HTTP; Tue, 3 Jan 2012 22:29:59 -0800 (PST)
X-Originating-IP: [71.56.71.211]
Date: Wed, 4 Jan 2012 01:29:59 -0500
Message-ID: <CAH4C7zG1O6n2SwKOsh+qurux-rjHpXVV6t+FX45MNmp3p-g1zg@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 third 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 third release candidate for Xen 3.4.4 is tagged at:
http://xenbits.xensource.com/xen-3.4-testing.hg (tag '3.4.4-rc3')

Please test and give feedback! This will likely be the last release candidate.

--

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 Jan 04 07:46:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 07: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 1RiLY5-0006d9-QJ; Wed, 04 Jan 2012 07:46:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1RiLY4-0006d0-7Z
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 07:46:12 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325663057!58318840!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 24930 invoked from network); 4 Jan 2012 07:44:17 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 07:44:17 -0000
Received: by bkbzs2 with SMTP id zs2so45987bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 23:46:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.133.129 with SMTP id hy1mr13277967bkc.28.1325663170461;
	Tue, 03 Jan 2012 23:46:10 -0800 (PST)
Received: by 10.204.70.18 with HTTP; Tue, 3 Jan 2012 23:46:10 -0800 (PST)
X-Originating-IP: [71.56.71.211]
Date: Wed, 4 Jan 2012 02:46:10 -0500
Message-ID: <CAH4C7zEzYrWCobkjzbncV8saxm5dUvu0ca9_KEcAcBzLNZ6Wzw@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 fourth 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 fourth release candidate for Xen 3.4.4 is tagged at:
http://xenbits.xensource.com/xen-3.4-testing.hg (tag '3.4.4-rc4')

Please test and give feedback! This will likely be the last release candidate.

--

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 Jan 04 07:46:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 07: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 1RiLY5-0006d9-QJ; Wed, 04 Jan 2012 07:46:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>) id 1RiLY4-0006d0-7Z
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 07:46:12 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325663057!58318840!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 24930 invoked from network); 4 Jan 2012 07:44:17 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 07:44:17 -0000
Received: by bkbzs2 with SMTP id zs2so45987bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 23:46:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.205.133.129 with SMTP id hy1mr13277967bkc.28.1325663170461;
	Tue, 03 Jan 2012 23:46:10 -0800 (PST)
Received: by 10.204.70.18 with HTTP; Tue, 3 Jan 2012 23:46:10 -0800 (PST)
X-Originating-IP: [71.56.71.211]
Date: Wed, 4 Jan 2012 02:46:10 -0500
Message-ID: <CAH4C7zEzYrWCobkjzbncV8saxm5dUvu0ca9_KEcAcBzLNZ6Wzw@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 fourth 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 fourth release candidate for Xen 3.4.4 is tagged at:
http://xenbits.xensource.com/xen-3.4-testing.hg (tag '3.4.4-rc4')

Please test and give feedback! This will likely be the last release candidate.

--

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 Jan 04 09:17:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiMxe-0007fR-HR; Wed, 04 Jan 2012 09:16:42 +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 1RiMxd-0007fM-VR
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:16:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325668557!50822205!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 30545 invoked from network); 4 Jan 2012 09:15:57 -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; 4 Jan 2012 09:15:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Jan 2012 09:16:38 +0000
Message-Id: <4F04273E020000780006A502@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Jan 2012 09:17:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.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>
	<1324565067.2897.2.camel@bwh-desktop>
	<1324586301.13113.3.camel@dagon.hellion.org.uk>
	<20120103203637.GF17472@phenom.dumpdata.com>
In-Reply-To: <20120103203637.GF17472@phenom.dumpdata.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>,
	"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>,
	Ben Hutchings <bhutchings@solarflare.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 03.01.12 at 21:36, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Dec 22, 2011 at 08:38:21PM +0000, Ian Campbell wrote:
>> 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.
> 
> Ian, are you OK with this patch? I think Jan needs to repost once more with 
> the
> "pciback" -> DRV_NAME change and then it is OK?

But that is what v2 was about (which is this thread).

Jan

> I've tested it with all backends, except the pciback one, and I see no 
> regressions
> with 'xl' or 'xm' toolstack.




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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 09:17:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09:17:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiMxe-0007fR-HR; Wed, 04 Jan 2012 09:16:42 +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 1RiMxd-0007fM-VR
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:16:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325668557!50822205!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 30545 invoked from network); 4 Jan 2012 09:15:57 -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; 4 Jan 2012 09:15:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Jan 2012 09:16:38 +0000
Message-Id: <4F04273E020000780006A502@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Jan 2012 09:17:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.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>
	<1324565067.2897.2.camel@bwh-desktop>
	<1324586301.13113.3.camel@dagon.hellion.org.uk>
	<20120103203637.GF17472@phenom.dumpdata.com>
In-Reply-To: <20120103203637.GF17472@phenom.dumpdata.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>,
	"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>,
	Ben Hutchings <bhutchings@solarflare.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 03.01.12 at 21:36, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Dec 22, 2011 at 08:38:21PM +0000, Ian Campbell wrote:
>> 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.
> 
> Ian, are you OK with this patch? I think Jan needs to repost once more with 
> the
> "pciback" -> DRV_NAME change and then it is OK?

But that is what v2 was about (which is this thread).

Jan

> I've tested it with all backends, except the pciback one, and I see no 
> regressions
> with 'xl' or 'xm' toolstack.




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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 09:21:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09: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 1RiN1y-0007mW-75; Wed, 04 Jan 2012 09:21: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 1RiN1x-0007mG-24
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:21:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325668862!7062719!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30694 invoked from network); 4 Jan 2012 09:21:02 -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;
	4 Jan 2012 09:21:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9805130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 09:20:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Jan 2012
	09:20:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 09:20:45 +0000
In-Reply-To: <20120103203637.GF17472@phenom.dumpdata.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>
	<1324565067.2897.2.camel@bwh-desktop>
	<1324586301.13113.3.camel@dagon.hellion.org.uk>
	<20120103203637.GF17472@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325668846.25206.172.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>,
	"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>, Ben Hutchings <bhutchings@solarflare.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 Tue, 2012-01-03 at 20:36 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 22, 2011 at 08:38:21PM +0000, Ian Campbell wrote:
> > 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.
> 
> Ian, are you OK with this patch? I think Jan needs to repost once more with the
> "pciback" -> DRV_NAME change and then it is OK?

I don't much like the style of leaving macro parameters blank -- I'd
much rather have things be explicitly specified and live with the slight
duplication in cases where the device name happens to match an entry in
the id list. But it's not a show stopper for me.

> I've tested it with all backends, except the pciback one, and I see no regressions
> with 'xl' or 'xm' toolstack.

Great!

Presumably there is no actual change to sysfs arising from 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 Wed Jan 04 09:21:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09: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 1RiN1y-0007mW-75; Wed, 04 Jan 2012 09:21: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 1RiN1x-0007mG-24
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:21:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325668862!7062719!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30694 invoked from network); 4 Jan 2012 09:21:02 -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;
	4 Jan 2012 09:21:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9805130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 09:20:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Jan 2012
	09:20:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 09:20:45 +0000
In-Reply-To: <20120103203637.GF17472@phenom.dumpdata.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>
	<1324565067.2897.2.camel@bwh-desktop>
	<1324586301.13113.3.camel@dagon.hellion.org.uk>
	<20120103203637.GF17472@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325668846.25206.172.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>,
	"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>, Ben Hutchings <bhutchings@solarflare.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 Tue, 2012-01-03 at 20:36 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Dec 22, 2011 at 08:38:21PM +0000, Ian Campbell wrote:
> > 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.
> 
> Ian, are you OK with this patch? I think Jan needs to repost once more with the
> "pciback" -> DRV_NAME change and then it is OK?

I don't much like the style of leaving macro parameters blank -- I'd
much rather have things be explicitly specified and live with the slight
duplication in cases where the device name happens to match an entry in
the id list. But it's not a show stopper for me.

> I've tested it with all backends, except the pciback one, and I see no regressions
> with 'xl' or 'xm' toolstack.

Great!

Presumably there is no actual change to sysfs arising from 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 Wed Jan 04 09:25:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiN5k-0007xe-2H; Wed, 04 Jan 2012 09:25:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiN5i-0007xN-Is
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:25:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325669095!7767612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8494 invoked from network); 4 Jan 2012 09:24:56 -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 Jan 2012 09:24:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9805231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 09:24: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, 4 Jan 2012
	09:24:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Haogang Chen <haogangchen@gmail.com>
Date: Wed, 4 Jan 2012 09:24:54 +0000
In-Reply-To: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
References: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325669095.25206.176.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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] XEN: xenbus: integer overflow in
	process_msg()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-03 at 19:42 +0000, Haogang Chen wrote:
> There is a potential integer overflow in process_msg() that could result
> in cross-domain attack.
> 
> 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
> 
> When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
> call to xb_read() would write to a zero-length buffer.

The other end of this connection is always the xenstore backend daemon
so there is no guest (malicious or otherwise) which can do this. The
xenstore daemon is a trusted component in the system.

However this seem like a reasonable robustness improvement so we should
have it.

> This causes
> kernel oops in the receiving guest and hangs its xenbus kernel thread.
> The patch returns -EINVAL in that case.
> 
> Signed-off-by: Haogang Chen <haogangchen@gmail.com>

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

> ---
>  drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index ede860f..e32aefb 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -801,6 +801,12 @@ static int process_msg(void)
>  		goto out;
>  	}
>  
> +	if (msg->hdr.len == UINT_MAX) {
> +		kfree(msg);
> +		err = -EINVAL;
> +		goto out;
> +	}
> +
>  	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
>  	if (body == NULL) {
>  		kfree(msg);



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 09:25:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09:25:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiN5k-0007xe-2H; Wed, 04 Jan 2012 09:25:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiN5i-0007xN-Is
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:25:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325669095!7767612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8494 invoked from network); 4 Jan 2012 09:24:56 -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 Jan 2012 09:24:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9805231"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 09:24: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, 4 Jan 2012
	09:24:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Haogang Chen <haogangchen@gmail.com>
Date: Wed, 4 Jan 2012 09:24:54 +0000
In-Reply-To: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
References: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325669095.25206.176.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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] XEN: xenbus: integer overflow in
	process_msg()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-03 at 19:42 +0000, Haogang Chen wrote:
> There is a potential integer overflow in process_msg() that could result
> in cross-domain attack.
> 
> 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
> 
> When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
> call to xb_read() would write to a zero-length buffer.

The other end of this connection is always the xenstore backend daemon
so there is no guest (malicious or otherwise) which can do this. The
xenstore daemon is a trusted component in the system.

However this seem like a reasonable robustness improvement so we should
have it.

> This causes
> kernel oops in the receiving guest and hangs its xenbus kernel thread.
> The patch returns -EINVAL in that case.
> 
> Signed-off-by: Haogang Chen <haogangchen@gmail.com>

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

> ---
>  drivers/xen/xenbus/xenbus_xs.c |    6 ++++++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index ede860f..e32aefb 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -801,6 +801,12 @@ static int process_msg(void)
>  		goto out;
>  	}
>  
> +	if (msg->hdr.len == UINT_MAX) {
> +		kfree(msg);
> +		err = -EINVAL;
> +		goto out;
> +	}
> +
>  	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
>  	if (body == NULL) {
>  		kfree(msg);



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 09:31:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09: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 1RiNBv-0008Ah-T9; Wed, 04 Jan 2012 09:31:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1RiNBu-0008Ac-H9
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:31:26 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325669478!7715662!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6521 invoked from network); 4 Jan 2012 09:31:20 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 09:31:20 -0000
Received: by obbwd20 with SMTP id wd20so51334654obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 01:31:18 -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=zxswdWWarT7P4JsKH7haVDxnH3Mt5PWelZuSh1YVmLQ=;
	b=ZLLi1eF3y5XicERC5OL8++ZR7RAIERGz8YlojXexzYsuHmWAXoIlhkbQ8kqTAmOQBq
	WJtTo/qPuisCLh3NscU2b1nHCHTVuNmrGHgcqTr5p1/qXtvyawVlpZqhMqoLs73N6CMv
	s5SLcUksy2sdzriMTS9sNeDUxvWSfZNW3CqbU=
MIME-Version: 1.0
Received: by 10.182.231.7 with SMTP id tc7mr21744345obc.29.1325669478188; Wed,
	04 Jan 2012 01:31:18 -0800 (PST)
Received: by 10.182.109.68 with HTTP; Wed, 4 Jan 2012 01:31:18 -0800 (PST)
Date: Wed, 4 Jan 2012 17:31:18 +0800
Message-ID: <CAAh7U5PhR60SBitVyzgbP8f=9mpc58R5MmADyNYxjNx4zD0+SA@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: "Xen-Devel (E-mail)" <xen-devel@lists.xensource.com>, Jun.Zhu@citrix.com, 
	dgdegra@tycho.nsa.gov, pjcolp@cs.ubc.ca
Subject: [Xen-devel] About Xoar
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 read the paper "Breaking Up is Hard to Do: Security and
Functionality in a Commodity Hypervisor",
which introduces the Xoar.

Thanks for the great work.

I googled but failed to find any more info about Xoar except this paper.

Is Xoar src/binary publicly available/accesible now pls?

Any help will be appreciated.
-- 
Zhou Peng

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 09:31:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09: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 1RiNBv-0008Ah-T9; Wed, 04 Jan 2012 09:31:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zpengxen@gmail.com>) id 1RiNBu-0008Ac-H9
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:31:26 +0000
X-Env-Sender: zpengxen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325669478!7715662!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6521 invoked from network); 4 Jan 2012 09:31:20 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 09:31:20 -0000
Received: by obbwd20 with SMTP id wd20so51334654obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 01:31:18 -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=zxswdWWarT7P4JsKH7haVDxnH3Mt5PWelZuSh1YVmLQ=;
	b=ZLLi1eF3y5XicERC5OL8++ZR7RAIERGz8YlojXexzYsuHmWAXoIlhkbQ8kqTAmOQBq
	WJtTo/qPuisCLh3NscU2b1nHCHTVuNmrGHgcqTr5p1/qXtvyawVlpZqhMqoLs73N6CMv
	s5SLcUksy2sdzriMTS9sNeDUxvWSfZNW3CqbU=
MIME-Version: 1.0
Received: by 10.182.231.7 with SMTP id tc7mr21744345obc.29.1325669478188; Wed,
	04 Jan 2012 01:31:18 -0800 (PST)
Received: by 10.182.109.68 with HTTP; Wed, 4 Jan 2012 01:31:18 -0800 (PST)
Date: Wed, 4 Jan 2012 17:31:18 +0800
Message-ID: <CAAh7U5PhR60SBitVyzgbP8f=9mpc58R5MmADyNYxjNx4zD0+SA@mail.gmail.com>
From: ZhouPeng <zpengxen@gmail.com>
To: "Xen-Devel (E-mail)" <xen-devel@lists.xensource.com>, Jun.Zhu@citrix.com, 
	dgdegra@tycho.nsa.gov, pjcolp@cs.ubc.ca
Subject: [Xen-devel] About Xoar
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 read the paper "Breaking Up is Hard to Do: Security and
Functionality in a Commodity Hypervisor",
which introduces the Xoar.

Thanks for the great work.

I googled but failed to find any more info about Xoar except this paper.

Is Xoar src/binary publicly available/accesible now pls?

Any help will be appreciated.
-- 
Zhou Peng

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 09:35:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09: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 1RiNFL-0008HQ-HV; Wed, 04 Jan 2012 09:34: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 1RiNFK-0008HB-K2
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:34:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325669654!54596878!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15131 invoked from network); 4 Jan 2012 09:34:14 -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;
	4 Jan 2012 09:34:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9805438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 09:34: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, 4 Jan 2012
	09:34:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Haogang Chen <haogangchen@gmail.com>
Date: Wed, 4 Jan 2012 09:34:49 +0000
In-Reply-To: <1325669095.25206.176.camel@zakaz.uk.xensource.com>
References: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
	<1325669095.25206.176.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325669689.25206.181.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] XEN: xenbus: integer overflow in
	process_msg()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 09:24 +0000, Ian Campbell wrote:
> On Tue, 2012-01-03 at 19:42 +0000, Haogang Chen wrote:
> > There is a potential integer overflow in process_msg() that could result
> > in cross-domain attack.
> > 
> > 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
> > 
> > When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
> > call to xb_read() would write to a zero-length buffer.
> 
> The other end of this connection is always the xenstore backend daemon
> so there is no guest (malicious or otherwise) which can do this. The
> xenstore daemon is a trusted component in the system.
> 
> However this seem like a reasonable robustness improvement so we should
> have it.

Actually, rereading docs/misc/xenstore.txt I see:
        The payload length (len field of the header) is limited to 4096
        (XENSTORE_PAYLOAD_MAX) in both directions.  If a client exceeds the
        limit, its xenstored connection will be immediately killed by
        xenstored, which is usually catastrophic from the client's point of
        view.  Clients (particularly domains, which cannot just reconnect)
        should avoid this.

So probably we actually want (untested, but seems obvious enough):

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

>From a010c48fe67ef15495884c265ec6af8a688795f8 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 4 Jan 2012 09:29:41 +0000
Subject: [PATCH] xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.

This also avoids a potential integer overflow pointed out by Haogang Chen.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/xen/xenbus/xenbus_xs.c     |    6 ++++++
 include/xen/interface/io/xs_wire.h |    3 +++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index b3b8f2f..6f0121e 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -810,6 +810,12 @@ static int process_msg(void)
 		goto out;
 	}
 
+	if (msg->hdr.len > XENSTORE_PAYLOAD_MAX) {
+		kfree(msg);
+		err = -EINVAL;
+		goto out;
+	}
+
 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
 	if (body == NULL) {
 		kfree(msg);
diff --git a/include/xen/interface/io/xs_wire.h b/include/xen/interface/io/xs_wire.h
index f0b6890..3c1877c 100644
--- a/include/xen/interface/io/xs_wire.h
+++ b/include/xen/interface/io/xs_wire.h
@@ -88,4 +88,7 @@ struct xenstore_domain_interface {
     XENSTORE_RING_IDX rsp_cons, rsp_prod;
 };
 
+/* Violating this is very bad.  See docs/misc/xenstore.txt. */
+#define XENSTORE_PAYLOAD_MAX 4096
+
 #endif /* _XS_WIRE_H */
-- 
1.7.2.5




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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 09:35:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 09: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 1RiNFL-0008HQ-HV; Wed, 04 Jan 2012 09:34: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 1RiNFK-0008HB-K2
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 09:34:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325669654!54596878!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15131 invoked from network); 4 Jan 2012 09:34:14 -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;
	4 Jan 2012 09:34:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9805438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 09:34: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, 4 Jan 2012
	09:34:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Haogang Chen <haogangchen@gmail.com>
Date: Wed, 4 Jan 2012 09:34:49 +0000
In-Reply-To: <1325669095.25206.176.camel@zakaz.uk.xensource.com>
References: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
	<1325669095.25206.176.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325669689.25206.181.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] XEN: xenbus: integer overflow in
	process_msg()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 09:24 +0000, Ian Campbell wrote:
> On Tue, 2012-01-03 at 19:42 +0000, Haogang Chen wrote:
> > There is a potential integer overflow in process_msg() that could result
> > in cross-domain attack.
> > 
> > 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
> > 
> > When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
> > call to xb_read() would write to a zero-length buffer.
> 
> The other end of this connection is always the xenstore backend daemon
> so there is no guest (malicious or otherwise) which can do this. The
> xenstore daemon is a trusted component in the system.
> 
> However this seem like a reasonable robustness improvement so we should
> have it.

Actually, rereading docs/misc/xenstore.txt I see:
        The payload length (len field of the header) is limited to 4096
        (XENSTORE_PAYLOAD_MAX) in both directions.  If a client exceeds the
        limit, its xenstored connection will be immediately killed by
        xenstored, which is usually catastrophic from the client's point of
        view.  Clients (particularly domains, which cannot just reconnect)
        should avoid this.

So probably we actually want (untested, but seems obvious enough):

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

>From a010c48fe67ef15495884c265ec6af8a688795f8 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Wed, 4 Jan 2012 09:29:41 +0000
Subject: [PATCH] xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.

This also avoids a potential integer overflow pointed out by Haogang Chen.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/xen/xenbus/xenbus_xs.c     |    6 ++++++
 include/xen/interface/io/xs_wire.h |    3 +++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index b3b8f2f..6f0121e 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -810,6 +810,12 @@ static int process_msg(void)
 		goto out;
 	}
 
+	if (msg->hdr.len > XENSTORE_PAYLOAD_MAX) {
+		kfree(msg);
+		err = -EINVAL;
+		goto out;
+	}
+
 	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
 	if (body == NULL) {
 		kfree(msg);
diff --git a/include/xen/interface/io/xs_wire.h b/include/xen/interface/io/xs_wire.h
index f0b6890..3c1877c 100644
--- a/include/xen/interface/io/xs_wire.h
+++ b/include/xen/interface/io/xs_wire.h
@@ -88,4 +88,7 @@ struct xenstore_domain_interface {
     XENSTORE_RING_IDX rsp_cons, rsp_prod;
 };
 
+/* Violating this is very bad.  See docs/misc/xenstore.txt. */
+#define XENSTORE_PAYLOAD_MAX 4096
+
 #endif /* _XS_WIRE_H */
-- 
1.7.2.5




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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 10:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 10:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiO0j-0000Cj-GC; Wed, 04 Jan 2012 10:23:57 +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 1RiO0h-0000Ce-C4
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 10:23:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325672454!9505776!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 15384 invoked from network); 4 Jan 2012 10:20:54 -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; 4 Jan 2012 10:20:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Jan 2012 10:20:54 +0000
Message-Id: <4F04364D020000780006A543@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Jan 2012 10:21:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "James Harper" <james.harper@bendigoit.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
	<6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [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

>>> On 04.01.12 at 04:44, James Harper <james.harper@bendigoit.com.au> wrote:
>>  Okay I have it compiling and loading now (that xenbus init macro obviously
>> isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi 
> device -
>> it just hangs for a while then says hotplug didn't work.
>> 
>> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
>> I'm running now?
>> 
> 
> Loading and detecting properly now (see email about the choice of shell in 
> the vscsi script), and appears to be restoring with the following patch:
> 
> --- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 
> 10:51:36.090985303 +1100
> +++ emulate.c   2012-01-04 13:28:23.288336520 +1100
> @@ -401,8 +401,8 @@
>         NO_EMULATE(INQUIRY);               /*0x12*/
>         /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
>         NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
> -       /*NO_EMULATE(RESERVE);               *//*0x16*/
> -       /*NO_EMULATE(RELEASE);               *//*0x17*/
> +       NO_EMULATE(RESERVE);               /*0x16*/
> +       NO_EMULATE(RELEASE);               /*0x17*/

These don't appear to be generated anywhere in the Linux tree,
even though several drivers implement their handing. Am I then to
understand that it's Windows which is actually making use of them?
If so, is there a way to know what other commands Linux doesn't
use may still need enabling in the emulation table for Windows' sake?

Jan

>         /*NO_EMULATE(COPY);                  *//*0x18*/
>         NO_EMULATE(ERASE);                 /*0x19*/ /* st */
>         NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
> 
> James
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/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 Jan 04 10:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 10:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiO0j-0000Cj-GC; Wed, 04 Jan 2012 10:23:57 +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 1RiO0h-0000Ce-C4
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 10:23:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325672454!9505776!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 15384 invoked from network); 4 Jan 2012 10:20:54 -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; 4 Jan 2012 10:20:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Jan 2012 10:20:54 +0000
Message-Id: <4F04364D020000780006A543@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Jan 2012 10:21:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "James Harper" <james.harper@bendigoit.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
	<6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [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

>>> On 04.01.12 at 04:44, James Harper <james.harper@bendigoit.com.au> wrote:
>>  Okay I have it compiling and loading now (that xenbus init macro obviously
>> isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi 
> device -
>> it just hangs for a while then says hotplug didn't work.
>> 
>> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
>> I'm running now?
>> 
> 
> Loading and detecting properly now (see email about the choice of shell in 
> the vscsi script), and appears to be restoring with the following patch:
> 
> --- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 
> 10:51:36.090985303 +1100
> +++ emulate.c   2012-01-04 13:28:23.288336520 +1100
> @@ -401,8 +401,8 @@
>         NO_EMULATE(INQUIRY);               /*0x12*/
>         /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
>         NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
> -       /*NO_EMULATE(RESERVE);               *//*0x16*/
> -       /*NO_EMULATE(RELEASE);               *//*0x17*/
> +       NO_EMULATE(RESERVE);               /*0x16*/
> +       NO_EMULATE(RELEASE);               /*0x17*/

These don't appear to be generated anywhere in the Linux tree,
even though several drivers implement their handing. Am I then to
understand that it's Windows which is actually making use of them?
If so, is there a way to know what other commands Linux doesn't
use may still need enabling in the emulation table for Windows' sake?

Jan

>         /*NO_EMULATE(COPY);                  *//*0x18*/
>         NO_EMULATE(ERASE);                 /*0x19*/ /* st */
>         NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
> 
> James
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/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 Jan 04 10:36:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 10:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiOBr-0000OI-ML; Wed, 04 Jan 2012 10:35:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiOBp-0000OB-EY
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 10:35:25 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325673316!9537720!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 1321 invoked from network); 4 Jan 2012 10:35:19 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 10:35:19 -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 1RiOBP-00074D-3P; Wed, 04 Jan 2012 21:34:59 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 21:34:58 +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;
	Wed, 4 Jan 2012 21:34:59 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAAO3gMIAACpyA///MrICAALidgA==
Date: Wed, 4 Jan 2012 10:34:55 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B094B26@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
	<6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
	<4F04364D020000780006A543@nat28.tlf.novell.com>
In-Reply-To: <4F04364D020000780006A543@nat28.tlf.novell.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2012 10:34:58.0920 (UTC)
	FILETIME=[81F29680:01CCCACC]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [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

> > +       NO_EMULATE(RESERVE);               /*0x16*/
> > +       NO_EMULATE(RELEASE);               /*0x17*/
> 
> These don't appear to be generated anywhere in the Linux tree, even
> though several drivers implement their handing. Am I then to understand
> that it's Windows which is actually making use of them?

Backup Exec under Windows tries to RESERVE my LTO3 drive and refuses to touch it if it can't. I guess if the device reports or is known to support RESERVE/RELEASE then it would be expected to be implemented.

> If so, is there a way to know what other commands Linux doesn't use may
> still need enabling in the emulation table for Windows' sake?
> 

This is stretching my memory a bit, but the very first incantation of pvscsi was at the per-device level. Then someone mentioned that it would be great to be able to map individual LUN's instead of entire devices. This obviously requires all sorts of emulation and remapping of commands which I think is where the EMULATE stuff came from. I can't quite remember but I suspect there might have been some confusion as to what a LUN actually was.

IMHO the per-LUN idea sounds good in theory but would be really hard to implement as you'd potentially need to decode and re-encode every single reported page of data to adjust the LUN numbers, and probably breaks various aspects of the scsi spec (doesn't the spec require that LUN 0 exist?).

So if you are mapping through entire devices I don't know that much really needs emulating and we could just uncomment the lot so they just pass straight through... I wonder if anyone actually needs the per-lun passthrough and even if they think they need it, if it would actually work?

James


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 10:36:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 10:36:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiOBr-0000OI-ML; Wed, 04 Jan 2012 10:35:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiOBp-0000OB-EY
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 10:35:25 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325673316!9537720!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 1321 invoked from network); 4 Jan 2012 10:35:19 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-4.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 10:35:19 -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 1RiOBP-00074D-3P; Wed, 04 Jan 2012 21:34:59 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 4 Jan 2012 21:34:58 +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;
	Wed, 4 Jan 2012 21:34:59 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [Xen-devel] set_phys_to_machine not exported?
Thread-Index: AQHMykEAE+Ub4ou11UOwOvn8iOI2JZX7Ea7Q//9xlwCAAO3gMIAACpyA///MrICAALidgA==
Date: Wed, 4 Jan 2012 10:34:55 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B094B26@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
	<6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
	<4F04364D020000780006A543@nat28.tlf.novell.com>
In-Reply-To: <4F04364D020000780006A543@nat28.tlf.novell.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2012 10:34:58.0920 (UTC)
	FILETIME=[81F29680:01CCCACC]
X-Really-From-Bendigo-IT: magichashvalue
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [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

> > +       NO_EMULATE(RESERVE);               /*0x16*/
> > +       NO_EMULATE(RELEASE);               /*0x17*/
> 
> These don't appear to be generated anywhere in the Linux tree, even
> though several drivers implement their handing. Am I then to understand
> that it's Windows which is actually making use of them?

Backup Exec under Windows tries to RESERVE my LTO3 drive and refuses to touch it if it can't. I guess if the device reports or is known to support RESERVE/RELEASE then it would be expected to be implemented.

> If so, is there a way to know what other commands Linux doesn't use may
> still need enabling in the emulation table for Windows' sake?
> 

This is stretching my memory a bit, but the very first incantation of pvscsi was at the per-device level. Then someone mentioned that it would be great to be able to map individual LUN's instead of entire devices. This obviously requires all sorts of emulation and remapping of commands which I think is where the EMULATE stuff came from. I can't quite remember but I suspect there might have been some confusion as to what a LUN actually was.

IMHO the per-LUN idea sounds good in theory but would be really hard to implement as you'd potentially need to decode and re-encode every single reported page of data to adjust the LUN numbers, and probably breaks various aspects of the scsi spec (doesn't the spec require that LUN 0 exist?).

So if you are mapping through entire devices I don't know that much really needs emulating and we could just uncomment the lot so they just pass straight through... I wonder if anyone actually needs the per-lun passthrough and even if they think they need it, if it would actually work?

James


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 10:48:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 10:48:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiONM-0000Yl-U6; Wed, 04 Jan 2012 10:47:20 +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 1RiONL-0000Yg-QJ
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 10:47:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325673991!48887798!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyODU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20944 invoked from network); 4 Jan 2012 10:46:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 10:46:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325674035; l=1472;
	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=plQo4WBnmnKDL6cKQmIjMdx0/6E=;
	b=MBEsPQnxAij8icH/rO5u2WXjrmzBudGlzA2Zzb7nb0IcHAv5wUIEzNH4ZCCG5PbsRDv
	T0H7MEew0kMPRgPxS0gM6pjcdSJSTf+IvcHb/v851dB9TeApV9UGB2Yl0e5RVdQ4aErxV
	rZwu1AgcJ0qGHtKJLpqAdOAab5Ik055lMK0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjy0PFmWD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-071-152.pools.arcor-ip.net [88.65.71.152])
	by smtp.strato.de (jimi mo23) (RZmta 27.2 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I03bc8o04ADdpb ;
	Wed, 4 Jan 2012 11:46:55 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2516418637; Wed,  4 Jan 2012 11:46:54 +0100 (CET)
Date: Wed, 4 Jan 2012 11:46:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20120104104654.GA5554@aepfle.de>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [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

On Fri, Dec 16, Adin Scannell wrote:

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

In linux-2.6.18-xen.hg the ioctl could in theory return -ENOMEM in a
later iteration and maybe even other values if the guest was destroyed
meanwhile. So checking also errno for ENOENT is good, because thats the
return code if any of the requested gfns is still in paged-out state.

Acked-by: Olaf Hering <olaf@aepfle.de>

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

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 10:48:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 10:48:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiONM-0000Yl-U6; Wed, 04 Jan 2012 10:47:20 +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 1RiONL-0000Yg-QJ
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 10:47:20 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325673991!48887798!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyODU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20944 invoked from network); 4 Jan 2012 10:46:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 10:46:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325674035; l=1472;
	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=plQo4WBnmnKDL6cKQmIjMdx0/6E=;
	b=MBEsPQnxAij8icH/rO5u2WXjrmzBudGlzA2Zzb7nb0IcHAv5wUIEzNH4ZCCG5PbsRDv
	T0H7MEew0kMPRgPxS0gM6pjcdSJSTf+IvcHb/v851dB9TeApV9UGB2Yl0e5RVdQ4aErxV
	rZwu1AgcJ0qGHtKJLpqAdOAab5Ik055lMK0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjy0PFmWD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-071-152.pools.arcor-ip.net [88.65.71.152])
	by smtp.strato.de (jimi mo23) (RZmta 27.2 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id I03bc8o04ADdpb ;
	Wed, 4 Jan 2012 11:46:55 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 2516418637; Wed,  4 Jan 2012 11:46:54 +0100 (CET)
Date: Wed, 4 Jan 2012 11:46:54 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Adin Scannell <adin@scannell.ca>
Message-ID: <20120104104654.GA5554@aepfle.de>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [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

On Fri, Dec 16, Adin Scannell wrote:

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

In linux-2.6.18-xen.hg the ioctl could in theory return -ENOMEM in a
later iteration and maybe even other values if the guest was destroyed
meanwhile. So checking also errno for ENOENT is good, because thats the
return code if any of the requested gfns is still in paged-out state.

Acked-by: Olaf Hering <olaf@aepfle.de>

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

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 10:50:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 10:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiOQI-0000eZ-Gp; Wed, 04 Jan 2012 10:50: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 1RiOQH-0000eQ-5X
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 10:50:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325674213!9483911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30455 invoked from network); 4 Jan 2012 10:50:14 -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;
	4 Jan 2012 10:50:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9807601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 10:50:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 10:50:13 +0000
Date: Wed, 4 Jan 2012 10:47:27 +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: <4EEA6D50.80902@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
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>
	<4EEA6D50.80902@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 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 Thu, 15 Dec 2011, Daniel De Graaf wrote:
> 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.

It would be great to have a short introduction to flask in the xl man
page. What do you think about the following?


diff -r 50117a4d1a2c docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Jan 02 12:43:07 2012 +0000
+++ b/docs/man/xl.pod.1	Wed Jan 04 10:46:47 2012 +0000
@@ -997,6 +997,20 @@ Get information about how much freeable 
 
 =head2 FLASK
 
+B<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.
+
+See the following document for more details:
+
+L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
+
 =over 4
 
 =item B<getenforce>



As you can see, I linked docs/misc/xsm-flask.txt from the xl man page,
however xsm-flask.txt still references xend so it needs to be updated.

Also it would be great to link the example policy too, but that one is
not online because it is not under docs and it is not installed by
default either. Maybe we need to move the example policy to docs? Or
maybe it is best to install a copy of it to /etc/xen by default?

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 10:50:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 10:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiOQI-0000eZ-Gp; Wed, 04 Jan 2012 10:50: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 1RiOQH-0000eQ-5X
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 10:50:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325674213!9483911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30455 invoked from network); 4 Jan 2012 10:50:14 -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;
	4 Jan 2012 10:50:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9807601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 10:50:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 10:50:13 +0000
Date: Wed, 4 Jan 2012 10:47:27 +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: <4EEA6D50.80902@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
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>
	<4EEA6D50.80902@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 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 Thu, 15 Dec 2011, Daniel De Graaf wrote:
> 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.

It would be great to have a short introduction to flask in the xl man
page. What do you think about the following?


diff -r 50117a4d1a2c docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Mon Jan 02 12:43:07 2012 +0000
+++ b/docs/man/xl.pod.1	Wed Jan 04 10:46:47 2012 +0000
@@ -997,6 +997,20 @@ Get information about how much freeable 
 
 =head2 FLASK
 
+B<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.
+
+See the following document for more details:
+
+L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
+
 =over 4
 
 =item B<getenforce>



As you can see, I linked docs/misc/xsm-flask.txt from the xl man page,
however xsm-flask.txt still references xend so it needs to be updated.

Also it would be great to link the example policy too, but that one is
not online because it is not under docs and it is not installed by
default either. Maybe we need to move the example policy to docs? Or
maybe it is best to install a copy of it to /etc/xen by default?

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:23:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiOvi-0001LQ-5a; Wed, 04 Jan 2012 11:22:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RiOvg-0001LE-SU
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:22:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325676162!10441575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24955 invoked from network); 4 Jan 2012 11:22:42 -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;
	4 Jan 2012 11:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9808588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 11:22:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 11:22: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
	1RiOva-00072U-9A; Wed, 04 Jan 2012 11:22:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RiOva-0006B2-6O;
	Wed, 04 Jan 2012 11:22:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20228.13954.66045.791489@mariner.uk.xensource.com>
Date: Wed, 4 Jan 2012 11:22:42 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6RTt=_YuzeeK_oL4A-q=0JDLx70wWZ6RcdeOZ5WNVP6g@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>
	<1324637110.7877.139.camel@zakaz.uk.xensource.com>
	<20227.16992.669043.281065@mariner.uk.xensource.com>
	<CAPLaKK6RTt=_YuzeeK_oL4A-q=0JDLx70wWZ6RcdeOZ5WNVP6g@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: add support fo=
r yajl 2.x"):
> I've started to create a basic configure.ac, but really this autoconf
> thing is pissing me off. My idea was to generate a config.h and
> replace Config.mk (at least some parts) with the output of configure
> also, does this sound reasonable?

Config.mk should probably include your new autoconf-generated
makefile.

Ian.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:23:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:23:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiOvi-0001LQ-5a; Wed, 04 Jan 2012 11:22:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RiOvg-0001LE-SU
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:22:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325676162!10441575!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24955 invoked from network); 4 Jan 2012 11:22:42 -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;
	4 Jan 2012 11:22:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9808588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 11:22:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 11:22: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
	1RiOva-00072U-9A; Wed, 04 Jan 2012 11:22:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RiOva-0006B2-6O;
	Wed, 04 Jan 2012 11:22:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20228.13954.66045.791489@mariner.uk.xensource.com>
Date: Wed, 4 Jan 2012 11:22:42 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6RTt=_YuzeeK_oL4A-q=0JDLx70wWZ6RcdeOZ5WNVP6g@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>
	<1324637110.7877.139.camel@zakaz.uk.xensource.com>
	<20227.16992.669043.281065@mariner.uk.xensource.com>
	<CAPLaKK6RTt=_YuzeeK_oL4A-q=0JDLx70wWZ6RcdeOZ5WNVP6g@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: add support fo=
r yajl 2.x"):
> I've started to create a basic configure.ac, but really this autoconf
> thing is pissing me off. My idea was to generate a config.h and
> replace Config.mk (at least some parts) with the output of configure
> also, does this sound reasonable?

Config.mk should probably include your new autoconf-generated
makefile.

Ian.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:39:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiPBM-0001Y4-NU; Wed, 04 Jan 2012 11:39:00 +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 1RiPBL-0001Xz-9S
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:38:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325677131!9534563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg0Mzg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16169 invoked from network); 4 Jan 2012 11:38:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 11:38:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320642000"; d="scan'208";a="176211354"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 06:38: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; Wed, 4 Jan 2012
	06:38:51 -0500
Message-ID: <4F043A4A.6060702@citrix.com>
Date: Wed, 4 Jan 2012 11:38: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2DF1A@szxeml522-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2DF1A@szxeml522-mbx.china.huawei.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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 04/01/12 04:37, Liuyongan wrote:
> Hi, all
>    
>     I'm using xen-4.0 to do a test. And when I create a domain, it failed due to create_irq() failure. As only 33 domains were successfully created and destroyed before I got the continuous failures, and the domain just before the failure was properly destroyed(at least destroy_irq() was properly called, which will clear move_in_progress, according to the prink-message). So I can conclude for certain that __assign_irq_vector failed due to move_cleanup_count always being set.

Is it always 33 domains it takes to cause the problem, or does it vary? 
If it varies, then I think you want this patch
http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01 which
corrects the logic which works out which moved vectors it should clean
up.  Without it, stale irq numbers build up in the per-cpu irq_vector
tables leading to __assign_irq_vector failing with -ENOSPC as it find
find a vector to allocate.

> //this is the normal case when create and destroy domain whose id is 31;
> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> (XEN) irq.c:223, destroy irq 77
>
> //domain id 32 is created and destroyed correctly also.
> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> (XEN) irq.c:223, destroy irq 77
>
> //all the subsequent domain creation failed, below lists only 3 times:
> (XEN) physdev.c:88: dom33: can't create irq for msi!
> (XEN) physdev.c:88: dom34: can't create irq for msi!
> (XEN) physdev.c:88: dom35: can't create irq for msi!
>
>      I think this might be a bug and might have fixed, so I compare my code with 4.1.2 and search the mail list for potential patches. (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanup_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which add locks in __assign_irq_vector. Can anybody explain why this lock is needed? Or is there a patch that might fix my bug? Thx.

This patch fixes a problem where IOAPIC line level interrupts cease for
a while.  It has nothing to do with MSI interrupts.  (Also, there are no
locks altered, and xen-4.0-testing seems to have gained an additional
hunk in hvm/vmx code unrelated to the original patch.)

>     Addition message: my board is arch-x86, no domains left when failed to create new ones, create_irq failure lasted one day until I reboot the board, and the irq number allocated is used certainly for a msi dev.
>
> Yong an Liu
> 2012.1.4
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:39:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:39:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiPBM-0001Y4-NU; Wed, 04 Jan 2012 11:39:00 +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 1RiPBL-0001Xz-9S
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:38:59 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325677131!9534563!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg0Mzg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16169 invoked from network); 4 Jan 2012 11:38:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 11:38:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320642000"; d="scan'208";a="176211354"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 06:38: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; Wed, 4 Jan 2012
	06:38:51 -0500
Message-ID: <4F043A4A.6060702@citrix.com>
Date: Wed, 4 Jan 2012 11:38: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2DF1A@szxeml522-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2DF1A@szxeml522-mbx.china.huawei.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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 04/01/12 04:37, Liuyongan wrote:
> Hi, all
>    
>     I'm using xen-4.0 to do a test. And when I create a domain, it failed due to create_irq() failure. As only 33 domains were successfully created and destroyed before I got the continuous failures, and the domain just before the failure was properly destroyed(at least destroy_irq() was properly called, which will clear move_in_progress, according to the prink-message). So I can conclude for certain that __assign_irq_vector failed due to move_cleanup_count always being set.

Is it always 33 domains it takes to cause the problem, or does it vary? 
If it varies, then I think you want this patch
http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01 which
corrects the logic which works out which moved vectors it should clean
up.  Without it, stale irq numbers build up in the per-cpu irq_vector
tables leading to __assign_irq_vector failing with -ENOSPC as it find
find a vector to allocate.

> //this is the normal case when create and destroy domain whose id is 31;
> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> (XEN) irq.c:223, destroy irq 77
>
> //domain id 32 is created and destroyed correctly also.
> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> (XEN) irq.c:223, destroy irq 77
>
> //all the subsequent domain creation failed, below lists only 3 times:
> (XEN) physdev.c:88: dom33: can't create irq for msi!
> (XEN) physdev.c:88: dom34: can't create irq for msi!
> (XEN) physdev.c:88: dom35: can't create irq for msi!
>
>      I think this might be a bug and might have fixed, so I compare my code with 4.1.2 and search the mail list for potential patches. (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanup_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which add locks in __assign_irq_vector. Can anybody explain why this lock is needed? Or is there a patch that might fix my bug? Thx.

This patch fixes a problem where IOAPIC line level interrupts cease for
a while.  It has nothing to do with MSI interrupts.  (Also, there are no
locks altered, and xen-4.0-testing seems to have gained an additional
hunk in hvm/vmx code unrelated to the original patch.)

>     Addition message: my board is arch-x86, no domains left when failed to create new ones, create_irq failure lasted one day until I reboot the board, and the irq number allocated is used certainly for a msi dev.
>
> Yong an Liu
> 2012.1.4
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:40:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11: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 1RiPBm-0001Z8-57; Wed, 04 Jan 2012 11:39: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 1RiPBl-0001Yt-7p
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:39:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325677158!7800519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23458 invoked from network); 4 Jan 2012 11:39:19 -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;
	4 Jan 2012 11:39:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9808949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 11:39: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, 4 Jan 2012
	11:39:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 11:39:17 +0000
In-Reply-To: <1325669689.25206.181.camel@zakaz.uk.xensource.com>
References: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
	<1325669095.25206.176.camel@zakaz.uk.xensource.com>
	<1325669689.25206.181.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Haogang Chen <haogangchen@gmail.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH 0/2] xen: Miscelaneous xenbus cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Just a couple of things I noticed while reviewing Haogang's patch.
Applies on top of my suggested replacement for that patch (in
<1325669689.25206.181.camel@zakaz.uk.xensource.com>).

Not extensively tested but I did run it in dom0 and start both and HVM
and PV guest.

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:40:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11: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 1RiPBm-0001Z8-57; Wed, 04 Jan 2012 11:39: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 1RiPBl-0001Yt-7p
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:39:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325677158!7800519!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23458 invoked from network); 4 Jan 2012 11:39:19 -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;
	4 Jan 2012 11:39:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; 
   d="scan'208";a="9808949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 11:39: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, 4 Jan 2012
	11:39:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 11:39:17 +0000
In-Reply-To: <1325669689.25206.181.camel@zakaz.uk.xensource.com>
References: <1325619731-13936-1-git-send-email-haogangchen@gmail.com>
	<1325669095.25206.176.camel@zakaz.uk.xensource.com>
	<1325669689.25206.181.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Haogang Chen <haogangchen@gmail.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [Xen-devel] [PATCH 0/2] xen: Miscelaneous xenbus cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Just a couple of things I noticed while reviewing Haogang's patch.
Applies on top of my suggested replacement for that patch (in
<1325669689.25206.181.camel@zakaz.uk.xensource.com>).

Not extensively tested but I did run it in dom0 and start both and HVM
and PV guest.

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:40:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiPCR-0001ck-Vb; Wed, 04 Jan 2012 11:40: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 1RiPCQ-0001bc-GY
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:40:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325677199!9561375!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg0Mzg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11319 invoked from network); 4 Jan 2012 11:40:00 -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;
	4 Jan 2012 11:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320642000"; d="scan'208";a="176211441"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 06:39:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 06:39:58 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q04BdrWl010832;	Wed, 4 Jan 2012 03:39:56 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 11:39:52 +0000
Message-ID: <1325677192-10459-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
References: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Haogang Chen <haogangchen@gmail.com>
Subject: [Xen-devel] [PATCH 2/2] xen/xenbus: don't reimplement kvasprintf
	via a fixed size buffer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/xen/xenbus/xenbus_xs.c |   17 +++++++----------
 1 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 6f0121e..226d1ac 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -532,21 +532,18 @@ int xenbus_printf(struct xenbus_transaction t,
 {
 	va_list ap;
 	int ret;
-#define PRINTF_BUFFER_SIZE 4096
-	char *printf_buffer;
-
-	printf_buffer = kmalloc(PRINTF_BUFFER_SIZE, GFP_NOIO | __GFP_HIGH);
-	if (printf_buffer == NULL)
-		return -ENOMEM;
+	char *buf;
 
 	va_start(ap, fmt);
-	ret = vsnprintf(printf_buffer, PRINTF_BUFFER_SIZE, fmt, ap);
+	buf = kvasprintf(GFP_NOIO | __GFP_HIGH, fmt, ap);
 	va_end(ap);
 
-	BUG_ON(ret > PRINTF_BUFFER_SIZE-1);
-	ret = xenbus_write(t, dir, node, printf_buffer);
+	if (!buf)
+		return -ENOMEM;
+
+	ret = xenbus_write(t, dir, node, buf);
 
-	kfree(printf_buffer);
+	kfree(buf);
 
 	return ret;
 }
-- 
1.7.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 Jan 04 11:40:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:40:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiPCR-0001ck-Vb; Wed, 04 Jan 2012 11:40: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 1RiPCQ-0001bc-GY
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:40:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325677199!9561375!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg0Mzg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11319 invoked from network); 4 Jan 2012 11:40:00 -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;
	4 Jan 2012 11:40:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320642000"; d="scan'208";a="176211441"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 06:39:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 06:39:58 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q04BdrWl010832;	Wed, 4 Jan 2012 03:39:56 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 11:39:52 +0000
Message-ID: <1325677192-10459-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
References: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Haogang Chen <haogangchen@gmail.com>
Subject: [Xen-devel] [PATCH 2/2] xen/xenbus: don't reimplement kvasprintf
	via a fixed size buffer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/xen/xenbus/xenbus_xs.c |   17 +++++++----------
 1 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 6f0121e..226d1ac 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -532,21 +532,18 @@ int xenbus_printf(struct xenbus_transaction t,
 {
 	va_list ap;
 	int ret;
-#define PRINTF_BUFFER_SIZE 4096
-	char *printf_buffer;
-
-	printf_buffer = kmalloc(PRINTF_BUFFER_SIZE, GFP_NOIO | __GFP_HIGH);
-	if (printf_buffer == NULL)
-		return -ENOMEM;
+	char *buf;
 
 	va_start(ap, fmt);
-	ret = vsnprintf(printf_buffer, PRINTF_BUFFER_SIZE, fmt, ap);
+	buf = kvasprintf(GFP_NOIO | __GFP_HIGH, fmt, ap);
 	va_end(ap);
 
-	BUG_ON(ret > PRINTF_BUFFER_SIZE-1);
-	ret = xenbus_write(t, dir, node, printf_buffer);
+	if (!buf)
+		return -ENOMEM;
+
+	ret = xenbus_write(t, dir, node, buf);
 
-	kfree(printf_buffer);
+	kfree(buf);
 
 	return ret;
 }
-- 
1.7.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 Jan 04 11:40:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiPCQ-0001cQ-Iv; Wed, 04 Jan 2012 11:40:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiPCO-0001bU-QC
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:40:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325677197!9652513!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQxNDA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29554 invoked from network); 4 Jan 2012 11:39:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 11:39:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320642000"; d="scan'208";a="20534540"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 06:39:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 06:39:56 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q04BdrWk010832;	Wed, 4 Jan 2012 03:39:53 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 11:39:51 +0000
Message-ID: <1325677192-10459-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
References: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Haogang Chen <haogangchen@gmail.com>
Subject: [Xen-devel] [PATCH 1/2] xenbus: maximum buffer size is
	XENSTORE_PAYLOAD_MAX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use this now that it is defined even though it happens to be == PAGE_SIZE.

The code which takes requests from userspace already validates against the size
of this buffer so no further checks are required to ensure that userspace
requests comply with the protocol in this respect.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.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..1fe4324 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -104,7 +104,7 @@ struct xenbus_file_priv {
 	unsigned int len;
 	union {
 		struct xsd_sockmsg msg;
-		char buffer[PAGE_SIZE];
+		char buffer[XENSTORE_PAYLOAD_MAX];
 	} u;
 
 	/* Response queue. */
-- 
1.7.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 Jan 04 11:40:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:40:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiPCQ-0001cQ-Iv; Wed, 04 Jan 2012 11:40:06 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiPCO-0001bU-QC
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:40:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325677197!9652513!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQxNDA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29554 invoked from network); 4 Jan 2012 11:39:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 11:39:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320642000"; d="scan'208";a="20534540"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 06:39:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 06:39:56 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q04BdrWk010832;	Wed, 4 Jan 2012 03:39:53 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 11:39:51 +0000
Message-ID: <1325677192-10459-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
References: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Haogang Chen <haogangchen@gmail.com>
Subject: [Xen-devel] [PATCH 1/2] xenbus: maximum buffer size is
	XENSTORE_PAYLOAD_MAX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use this now that it is defined even though it happens to be == PAGE_SIZE.

The code which takes requests from userspace already validates against the size
of this buffer so no further checks are required to ensure that userspace
requests comply with the protocol in this respect.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Haogang Chen <haogangchen@gmail.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.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..1fe4324 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -104,7 +104,7 @@ struct xenbus_file_priv {
 	unsigned int len;
 	union {
 		struct xsd_sockmsg msg;
-		char buffer[PAGE_SIZE];
+		char buffer[XENSTORE_PAYLOAD_MAX];
 	} u;
 
 	/* Response queue. */
-- 
1.7.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 Jan 04 11:42:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11: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 1RiPEs-0001wa-I6; Wed, 04 Jan 2012 11:42: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 1RiPEr-0001wF-VG
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:42:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325677349!9725684!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQxNDA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14088 invoked from network); 4 Jan 2012 11:42:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 11:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320642000"; d="scan'208";a="20534614"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 06:42: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; Wed, 4 Jan 2012
	06:42:29 -0500
Message-ID: <4F043B24.1090402@citrix.com>
Date: Wed, 4 Jan 2012 11:42: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2DF1A@szxeml522-mbx.china.huawei.com>
	<4F043A4A.6060702@citrix.com>
In-Reply-To: <4F043A4A.6060702@citrix.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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 04/01/12 11:38, Andrew Cooper wrote:
> On 04/01/12 04:37, Liuyongan wrote:
>> Hi, all
>>    
>>     I'm using xen-4.0 to do a test. And when I create a domain, it failed due to create_irq() failure. As only 33 domains were successfully created and destroyed before I got the continuous failures, and the domain just before the failure was properly destroyed(at least destroy_irq() was properly called, which will clear move_in_progress, according to the prink-message). So I can conclude for certain that __assign_irq_vector failed due to move_cleanup_count always being set.
> Is it always 33 domains it takes to cause the problem, or does it vary? 
> If it varies, then I think you want this patch
> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01 which
> corrects the logic which works out which moved vectors it should clean
> up.  Without it, stale irq numbers build up in the per-cpu irq_vector
> tables leading to __assign_irq_vector failing with -ENOSPC as it find
> find a vector to allocate.

P.S. Sorry - I mean the per-cpu vector_irq tables.  The irq_vector table
is something different.

~Andrew

>> //this is the normal case when create and destroy domain whose id is 31;
>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
>> (XEN) irq.c:223, destroy irq 77
>>
>> //domain id 32 is created and destroyed correctly also.
>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
>> (XEN) irq.c:223, destroy irq 77
>>
>> //all the subsequent domain creation failed, below lists only 3 times:
>> (XEN) physdev.c:88: dom33: can't create irq for msi!
>> (XEN) physdev.c:88: dom34: can't create irq for msi!
>> (XEN) physdev.c:88: dom35: can't create irq for msi!
>>
>>      I think this might be a bug and might have fixed, so I compare my code with 4.1.2 and search the mail list for potential patches. (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanup_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which add locks in __assign_irq_vector. Can anybody explain why this lock is needed? Or is there a patch that might fix my bug? Thx.
> This patch fixes a problem where IOAPIC line level interrupts cease for
> a while.  It has nothing to do with MSI interrupts.  (Also, there are no
> locks altered, and xen-4.0-testing seems to have gained an additional
> hunk in hvm/vmx code unrelated to the original patch.)
>
>>     Addition message: my board is arch-x86, no domains left when failed to create new ones, create_irq failure lasted one day until I reboot the board, and the irq number allocated is used certainly for a msi dev.
>>
>> Yong an Liu
>> 2012.1.4
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

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


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:42:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11: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 1RiPEs-0001wa-I6; Wed, 04 Jan 2012 11:42: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 1RiPEr-0001wF-VG
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:42:38 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325677349!9725684!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQxNDA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14088 invoked from network); 4 Jan 2012 11:42:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 11:42:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,455,1320642000"; d="scan'208";a="20534614"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 06:42: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; Wed, 4 Jan 2012
	06:42:29 -0500
Message-ID: <4F043B24.1090402@citrix.com>
Date: Wed, 4 Jan 2012 11:42: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2DF1A@szxeml522-mbx.china.huawei.com>
	<4F043A4A.6060702@citrix.com>
In-Reply-To: <4F043A4A.6060702@citrix.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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 04/01/12 11:38, Andrew Cooper wrote:
> On 04/01/12 04:37, Liuyongan wrote:
>> Hi, all
>>    
>>     I'm using xen-4.0 to do a test. And when I create a domain, it failed due to create_irq() failure. As only 33 domains were successfully created and destroyed before I got the continuous failures, and the domain just before the failure was properly destroyed(at least destroy_irq() was properly called, which will clear move_in_progress, according to the prink-message). So I can conclude for certain that __assign_irq_vector failed due to move_cleanup_count always being set.
> Is it always 33 domains it takes to cause the problem, or does it vary? 
> If it varies, then I think you want this patch
> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01 which
> corrects the logic which works out which moved vectors it should clean
> up.  Without it, stale irq numbers build up in the per-cpu irq_vector
> tables leading to __assign_irq_vector failing with -ENOSPC as it find
> find a vector to allocate.

P.S. Sorry - I mean the per-cpu vector_irq tables.  The irq_vector table
is something different.

~Andrew

>> //this is the normal case when create and destroy domain whose id is 31;
>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
>> (XEN) irq.c:223, destroy irq 77
>>
>> //domain id 32 is created and destroyed correctly also.
>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
>> (XEN) irq.c:223, destroy irq 77
>>
>> //all the subsequent domain creation failed, below lists only 3 times:
>> (XEN) physdev.c:88: dom33: can't create irq for msi!
>> (XEN) physdev.c:88: dom34: can't create irq for msi!
>> (XEN) physdev.c:88: dom35: can't create irq for msi!
>>
>>      I think this might be a bug and might have fixed, so I compare my code with 4.1.2 and search the mail list for potential patches. (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanup_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which add locks in __assign_irq_vector. Can anybody explain why this lock is needed? Or is there a patch that might fix my bug? Thx.
> This patch fixes a problem where IOAPIC line level interrupts cease for
> a while.  It has nothing to do with MSI interrupts.  (Also, there are no
> locks altered, and xen-4.0-testing seems to have gained an additional
> hunk in hvm/vmx code unrelated to the original patch.)
>
>>     Addition message: my board is arch-x86, no domains left when failed to create new ones, create_irq failure lasted one day until I reboot the board, and the irq number allocated is used certainly for a msi dev.
>>
>> Yong an Liu
>> 2012.1.4
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel

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


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 11:58:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiPTu-0002Ji-2A; Wed, 04 Jan 2012 11:58:10 +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 1RiPTs-0002Jd-Fa
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:58:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325678282!9537730!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 25550 invoked from network); 4 Jan 2012 11:58:02 -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; 4 Jan 2012 11:58:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Jan 2012 11:58:03 +0000
Message-Id: <4F044D10020000780006A5B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Jan 2012 11:58:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
	<1325677192-10459-2-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1325677192-10459-2-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Haogang Chen <haogangchen@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/xenbus: don't reimplement
 kvasprintf via a fixed size buffer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 04.01.12 at 12:39, Ian Campbell <ian.campbell@citrix.com> wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

> Cc: Haogang Chen <haogangchen@gmail.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel@lists.xensource.com 
> Cc: virtualization@lists.linux-foundation.org 
> Cc: linux-kernel@vger.kernel.org 
> ---
>  drivers/xen/xenbus/xenbus_xs.c |   17 +++++++----------
>  1 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index 6f0121e..226d1ac 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -532,21 +532,18 @@ int xenbus_printf(struct xenbus_transaction t,
>  {
>  	va_list ap;
>  	int ret;
> -#define PRINTF_BUFFER_SIZE 4096
> -	char *printf_buffer;
> -
> -	printf_buffer = kmalloc(PRINTF_BUFFER_SIZE, GFP_NOIO | __GFP_HIGH);
> -	if (printf_buffer == NULL)
> -		return -ENOMEM;
> +	char *buf;
>  
>  	va_start(ap, fmt);
> -	ret = vsnprintf(printf_buffer, PRINTF_BUFFER_SIZE, fmt, ap);
> +	buf = kvasprintf(GFP_NOIO | __GFP_HIGH, fmt, ap);
>  	va_end(ap);
>  
> -	BUG_ON(ret > PRINTF_BUFFER_SIZE-1);
> -	ret = xenbus_write(t, dir, node, printf_buffer);
> +	if (!buf)
> +		return -ENOMEM;
> +
> +	ret = xenbus_write(t, dir, node, buf);
>  
> -	kfree(printf_buffer);
> +	kfree(buf);
>  
>  	return ret;
>  }
> -- 
> 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 Jan 04 11:58:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 11:58:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiPTu-0002Ji-2A; Wed, 04 Jan 2012 11:58:10 +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 1RiPTs-0002Jd-Fa
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 11:58:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325678282!9537730!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 25550 invoked from network); 4 Jan 2012 11:58:02 -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; 4 Jan 2012 11:58:02 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Jan 2012 11:58:03 +0000
Message-Id: <4F044D10020000780006A5B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Jan 2012 11:58:56 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
	<1325677192-10459-2-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1325677192-10459-2-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Haogang Chen <haogangchen@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/xenbus: don't reimplement
 kvasprintf via a fixed size buffer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 04.01.12 at 12:39, Ian Campbell <ian.campbell@citrix.com> wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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

> Cc: Haogang Chen <haogangchen@gmail.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Cc: xen-devel@lists.xensource.com 
> Cc: virtualization@lists.linux-foundation.org 
> Cc: linux-kernel@vger.kernel.org 
> ---
>  drivers/xen/xenbus/xenbus_xs.c |   17 +++++++----------
>  1 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index 6f0121e..226d1ac 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -532,21 +532,18 @@ int xenbus_printf(struct xenbus_transaction t,
>  {
>  	va_list ap;
>  	int ret;
> -#define PRINTF_BUFFER_SIZE 4096
> -	char *printf_buffer;
> -
> -	printf_buffer = kmalloc(PRINTF_BUFFER_SIZE, GFP_NOIO | __GFP_HIGH);
> -	if (printf_buffer == NULL)
> -		return -ENOMEM;
> +	char *buf;
>  
>  	va_start(ap, fmt);
> -	ret = vsnprintf(printf_buffer, PRINTF_BUFFER_SIZE, fmt, ap);
> +	buf = kvasprintf(GFP_NOIO | __GFP_HIGH, fmt, ap);
>  	va_end(ap);
>  
> -	BUG_ON(ret > PRINTF_BUFFER_SIZE-1);
> -	ret = xenbus_write(t, dir, node, printf_buffer);
> +	if (!buf)
> +		return -ENOMEM;
> +
> +	ret = xenbus_write(t, dir, node, buf);
>  
> -	kfree(printf_buffer);
> +	kfree(buf);
>  
>  	return ret;
>  }
> -- 
> 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 Jan 04 12:43:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiQBW-0002o0-FE; Wed, 04 Jan 2012 12:43:14 +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 1RiQBV-0002ns-Fn
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 12:43:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1325680987!9692833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3793 invoked from network); 4 Jan 2012 12:43:07 -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;
	4 Jan 2012 12:43:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9810749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 12:43:07 +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, 4 Jan 2012
	12:43:07 +0000
Message-ID: <1325680929.24422.125.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 4 Jan 2012 12:42:09 +0000
In-Reply-To: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.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] 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

On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> This feature is required by some of our users.
> 
> Reported-by: Andy Smith <andy@strugglers.net>
> Reported-by: Florian Heigl <florian.heigl@gmail.com>
> 

Ian, ping?


Wei.


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 12:43:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiQBW-0002o0-FE; Wed, 04 Jan 2012 12:43:14 +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 1RiQBV-0002ns-Fn
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 12:43:13 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1325680987!9692833!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3793 invoked from network); 4 Jan 2012 12:43:07 -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;
	4 Jan 2012 12:43:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9810749"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 12:43:07 +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, 4 Jan 2012
	12:43:07 +0000
Message-ID: <1325680929.24422.125.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 4 Jan 2012 12:42:09 +0000
In-Reply-To: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.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] 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

On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> This feature is required by some of our users.
> 
> Reported-by: Andy Smith <andy@strugglers.net>
> Reported-by: Florian Heigl <florian.heigl@gmail.com>
> 

Ian, ping?


Wei.


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 14:28:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiRoI-0003K8-PZ; Wed, 04 Jan 2012 14:27:22 +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 1RiRoH-0003K3-6r
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:27:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325687233!4264458!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5524 invoked from network); 4 Jan 2012 14:27:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 14:27:14 -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
	q04ERBKD027003
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 14:27:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q04ERAhe022717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 14:27:11 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
	q04ERABW011435; Wed, 4 Jan 2012 08:27:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 06:27:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 31AE340469; Wed,  4 Jan 2012 09:25:39 -0500 (EST)
Date: Wed, 4 Jan 2012 09:25:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: John Sherwood <jrs@vt.edu>
Message-ID: <20120104142539.GA3322@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
	<20120103224040.GC12939@phenom.dumpdata.com>
	<CAH5ygH26OBci9U0ogRaH0n_xzEo38csr9H5dUWyvUdH=1hSGGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH5ygH26OBci9U0ogRaH0n_xzEo38csr9H5dUWyvUdH=1hSGGQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F0461C0.0113,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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 Tue, Jan 03, 2012 at 08:16:13PM -0500, John Sherwood wrote:
> the synergy incompatibilities were largely package related, due to
> requirements for a different application that we were supposed to deploy.
>  I'll try the ioperm patches next chance I have.

Please don't top post.

> > http://xen.org/products/xci_source.html

(the ioemu-pq git tree, look for 'ps2-passthrough')

.. has a driver in userspace that actually takes PS/2 input and shovels
them using QEMU to the guest. That might be interesting for you to look at
as well.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 14:28:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiRoI-0003K8-PZ; Wed, 04 Jan 2012 14:27:22 +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 1RiRoH-0003K3-6r
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:27:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325687233!4264458!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5524 invoked from network); 4 Jan 2012 14:27:14 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 14:27:14 -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
	q04ERBKD027003
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 14:27:12 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q04ERAhe022717
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 14:27:11 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
	q04ERABW011435; Wed, 4 Jan 2012 08:27:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 06:27:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 31AE340469; Wed,  4 Jan 2012 09:25:39 -0500 (EST)
Date: Wed, 4 Jan 2012 09:25:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: John Sherwood <jrs@vt.edu>
Message-ID: <20120104142539.GA3322@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
	<20120103224040.GC12939@phenom.dumpdata.com>
	<CAH5ygH26OBci9U0ogRaH0n_xzEo38csr9H5dUWyvUdH=1hSGGQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH5ygH26OBci9U0ogRaH0n_xzEo38csr9H5dUWyvUdH=1hSGGQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F0461C0.0113,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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 Tue, Jan 03, 2012 at 08:16:13PM -0500, John Sherwood wrote:
> the synergy incompatibilities were largely package related, due to
> requirements for a different application that we were supposed to deploy.
>  I'll try the ioperm patches next chance I have.

Please don't top post.

> > http://xen.org/products/xci_source.html

(the ioemu-pq git tree, look for 'ps2-passthrough')

.. has a driver in userspace that actually takes PS/2 input and shovels
them using QEMU to the guest. That might be interesting for you to look at
as well.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 14:43:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiS2t-0003om-0i; Wed, 04 Jan 2012 14:42: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 1RiS2r-0003og-8x
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:42:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325688138!7822531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29980 invoked from network); 4 Jan 2012 14:42:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 14:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9814378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 14:42: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; Wed, 4 Jan 2012 14:42:17 +0000
Date: Wed, 4 Jan 2012 14: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: <4F02E42E020000780006A2B6@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201041439150.2970@kaball-desktop>
References: <4F02E42E020000780006A2B6@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: fix sequence of operations in
	pt_msix_init()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 3 Jan 2012, Jan Beulich wrote:
> Checking the return value of mmap() must be done before adjusting the
> value, otherwise failure may not be detected.
> 
> Closing the file handle, on the other hand, can be done before checking
> the return value.
> 
> Finally, printing the errno value without knowing whether the previous
> function actually failed is bogus (and superfluous since a subsequent
> message prints the strerror() representaton anyway).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

acked

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 14:43:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14:43:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiS2t-0003om-0i; Wed, 04 Jan 2012 14:42: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 1RiS2r-0003og-8x
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:42:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325688138!7822531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29980 invoked from network); 4 Jan 2012 14:42:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 14:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9814378"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 14:42: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; Wed, 4 Jan 2012 14:42:17 +0000
Date: Wed, 4 Jan 2012 14: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: <4F02E42E020000780006A2B6@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201041439150.2970@kaball-desktop>
References: <4F02E42E020000780006A2B6@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: fix sequence of operations in
	pt_msix_init()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 3 Jan 2012, Jan Beulich wrote:
> Checking the return value of mmap() must be done before adjusting the
> value, otherwise failure may not be detected.
> 
> Closing the file handle, on the other hand, can be done before checking
> the return value.
> 
> Finally, printing the errno value without knowing whether the previous
> function actually failed is bogus (and superfluous since a subsequent
> message prints the strerror() representaton anyway).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

acked

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 14:43:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14: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 1RiS3R-0003q6-ER; Wed, 04 Jan 2012 14:43: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 1RiS3P-0003pt-V1
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:43:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325688173!9679910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5541 invoked from network); 4 Jan 2012 14:42:53 -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;
	4 Jan 2012 14:42:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9814400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 14:42:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 14:42:53 +0000
Date: Wed, 4 Jan 2012 14:40:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201041439480.2970@kaball-desktop>
References: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: adjust MSI-X related log 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

On Tue, 3 Jan 2012, Jan Beulich wrote:
> Several of these messages we coded using line continuation within a
> string literal. This is generally not recommended and also lead to odd
> sequences of many blanks in the middle of the messages.
> 
> The message indicating a discarded write due to MSI-X already being
> enabled doesn't need to be issued when a write doesn't actually modify
> the current value. Adjust the surrounding logic accordingly, and
> eliminate some redundancy as well as the sometimes unnecessary access
> to the physical MSI-X table.
> 
> Finally, adjust the wording of a few messages to be more precise and/or
> more useful.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

acked


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 14:43:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14: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 1RiS3R-0003q6-ER; Wed, 04 Jan 2012 14:43: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 1RiS3P-0003pt-V1
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:43:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325688173!9679910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5541 invoked from network); 4 Jan 2012 14:42:53 -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;
	4 Jan 2012 14:42:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9814400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 14:42:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 14:42:53 +0000
Date: Wed, 4 Jan 2012 14:40:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201041439480.2970@kaball-desktop>
References: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: adjust MSI-X related log 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

On Tue, 3 Jan 2012, Jan Beulich wrote:
> Several of these messages we coded using line continuation within a
> string literal. This is generally not recommended and also lead to odd
> sequences of many blanks in the middle of the messages.
> 
> The message indicating a discarded write due to MSI-X already being
> enabled doesn't need to be issued when a write doesn't actually modify
> the current value. Adjust the surrounding logic accordingly, and
> eliminate some redundancy as well as the sometimes unnecessary access
> to the physical MSI-X table.
> 
> Finally, adjust the wording of a few messages to be more precise and/or
> more useful.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

acked


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 14:51:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14: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 1RiSAw-0004AY-Ch; Wed, 04 Jan 2012 14:50:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RiSAu-0004AT-Fk
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:50:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325688636!7796337!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MTUyOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8184 invoked from network); 4 Jan 2012 14:50:38 -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; 4 Jan 2012 14:50:38 -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
	q04EnSM4021891
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 14:49:29 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
	q04EnQ4V013854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 14:49:27 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
	q04EnODw019522; Wed, 4 Jan 2012 08:49:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 06:49:24 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 711D140468; Wed,  4 Jan 2012 09:47:53 -0500 (EST)
Date: Wed, 4 Jan 2012 09:47:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120104144753.GC3322@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F0466FA.00D6,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Wed, Jan 04, 2012 at 01:50:03AM +0000, James Harper wrote:
> > > Or maybe someone else already has scsiback working against 3.x.x?
> > 
> > I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> > merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> > changed - but you could alter it yourself if you are using the 3.0 tree).
> > 
> > Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > 
> 
> Okay I have it compiling and loading now (that xenbus init macro obviously isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device - it just hangs for a while then says hotplug didn't work.

Oh, that is Jan's one. Yeah that wouldn't work very well.
> 
> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre I'm running now?

I've been using 4.1. But 4.0.x ought to work..
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 04 14:51:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14: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 1RiSAw-0004AY-Ch; Wed, 04 Jan 2012 14:50:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RiSAu-0004AT-Fk
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:50:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325688636!7796337!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MTUyOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8184 invoked from network); 4 Jan 2012 14:50:38 -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; 4 Jan 2012 14:50:38 -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
	q04EnSM4021891
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 14:49:29 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
	q04EnQ4V013854
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 14:49:27 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
	q04EnODw019522; Wed, 4 Jan 2012 08:49:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 06:49:24 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 711D140468; Wed,  4 Jan 2012 09:47:53 -0500 (EST)
Date: Wed, 4 Jan 2012 09:47:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120104144753.GC3322@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F0466FA.00D6,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Wed, Jan 04, 2012 at 01:50:03AM +0000, James Harper wrote:
> > > Or maybe someone else already has scsiback working against 3.x.x?
> > 
> > I do. Try the #testing branch or the #devel/xen-scsi-1.0 (but you should
> > merge it against the 3.1 kernel otherwise it won't compile b/c one argument
> > changed - but you could alter it yourself if you are using the 3.0 tree).
> > 
> > Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > 
> 
> Okay I have it compiling and loading now (that xenbus init macro obviously isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device - it just hangs for a while then says hotplug didn't work.

Oh, that is Jan's one. Yeah that wouldn't work very well.
> 
> Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre I'm running now?

I've been using 4.1. But 4.0.x ought to work..
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 04 14:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14: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 1RiSB3-0004B5-PV; Wed, 04 Jan 2012 14:50:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RiSB2-0004At-MG
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:50:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325688630!61139774!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MTUyOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16838 invoked from network); 4 Jan 2012 14:50:32 -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; 4 Jan 2012 14:50:32 -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
	q04EnoLu022390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 14:49:51 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q04Ennr6000040
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 14:49:50 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
	q04EnoGO028203; Wed, 4 Jan 2012 08:49:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 06:49:49 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 969654046A; Wed,  4 Jan 2012 09:48:18 -0500 (EST)
Date: Wed, 4 Jan 2012 09:48:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120104144818.GD3322@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
	<6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
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.4F04670F.005F,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Wed, Jan 04, 2012 at 03:44:32AM +0000, James Harper wrote:
> > Okay I have it compiling and loading now (that xenbus init macro obviously
> > isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device -
> > it just hangs for a while then says hotplug didn't work.
> > 
> > Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
> > I'm running now?
> > 
> 
> Loading and detecting properly now (see email about the choice of shell in the vscsi script), and appears to be restoring with the following patch:

OK. Can you post this along with a SOB and an explanation of what this patch
does please?

> 
> --- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 10:51:36.090985303 +1100
> +++ emulate.c   2012-01-04 13:28:23.288336520 +1100
> @@ -401,8 +401,8 @@
>         NO_EMULATE(INQUIRY);               /*0x12*/
>         /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
>         NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
> -       /*NO_EMULATE(RESERVE);               *//*0x16*/
> -       /*NO_EMULATE(RELEASE);               *//*0x17*/
> +       NO_EMULATE(RESERVE);               /*0x16*/
> +       NO_EMULATE(RELEASE);               /*0x17*/
>         /*NO_EMULATE(COPY);                  *//*0x18*/
>         NO_EMULATE(ERASE);                 /*0x19*/ /* st */
>         NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
> 
> James

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 14:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 14: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 1RiSB3-0004B5-PV; Wed, 04 Jan 2012 14:50:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RiSB2-0004At-MG
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 14:50:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325688630!61139774!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MTUyOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16838 invoked from network); 4 Jan 2012 14:50:32 -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; 4 Jan 2012 14:50:32 -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
	q04EnoLu022390
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 14:49:51 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q04Ennr6000040
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 14:49:50 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
	q04EnoGO028203; Wed, 4 Jan 2012 08:49:50 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 06:49:49 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 969654046A; Wed,  4 Jan 2012 09:48:18 -0500 (EST)
Date: Wed, 4 Jan 2012 09:48:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120104144818.GD3322@phenom.dumpdata.com>
References: <6035A0D088A63A46850C3988ED045A4B0594FA@BITCOM1.int.sbss.com.au>
	<20120103175539.GF749@andromeda.dapyr.net>
	<6035A0D088A63A46850C3988ED045A4B091826@BITCOM1.int.sbss.com.au>
	<20120103223610.GB12939@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B094042@BITCOM1.int.sbss.com.au>
	<6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094109@BITCOM1.int.sbss.com.au>
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.4F04670F.005F,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Wed, Jan 04, 2012 at 03:44:32AM +0000, James Harper wrote:
> > Okay I have it compiling and loading now (that xenbus init macro obviously
> > isn't for the Debian 3.1.0 kernel I'm running...) but I can't attach a scsi device -
> > it just hangs for a while then says hotplug didn't work.
> > 
> > Any suggestions? Would it be expected to work against the Xen 4.0.4-rc1-pre
> > I'm running now?
> > 
> 
> Loading and detecting properly now (see email about the choice of shell in the vscsi script), and appears to be restoring with the following patch:

OK. Can you post this along with a SOB and an explanation of what this patch
does please?

> 
> --- ../konrad/xen/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 10:51:36.090985303 +1100
> +++ emulate.c   2012-01-04 13:28:23.288336520 +1100
> @@ -401,8 +401,8 @@
>         NO_EMULATE(INQUIRY);               /*0x12*/
>         /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
>         NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
> -       /*NO_EMULATE(RESERVE);               *//*0x16*/
> -       /*NO_EMULATE(RELEASE);               *//*0x17*/
> +       NO_EMULATE(RESERVE);               /*0x16*/
> +       NO_EMULATE(RELEASE);               /*0x17*/
>         /*NO_EMULATE(COPY);                  *//*0x18*/
>         NO_EMULATE(ERASE);                 /*0x19*/ /* st */
>         NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */
> 
> James

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:04:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSNx-0004W0-3z; Wed, 04 Jan 2012 15:04:13 +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 1RiSNv-0004Vs-Ez
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:04:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325689444!9756932!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 24480 invoked from network); 4 Jan 2012 15:04:04 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-21.messagelabs.com with SMTP;
	4 Jan 2012 15:04: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
	q04F35Y2006670; Wed, 4 Jan 2012 15:03: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 q04F34lb001108; 
	Wed, 4 Jan 2012 10:03:04 -0500
Message-ID: <4F046A30.6000009@tycho.nsa.gov>
Date: Wed, 04 Jan 2012 10:03:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: 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>
	<4EEA4624.3080308@tycho.nsa.gov>
	<20111215205654.GA11829@andromeda.dapyr.net>
	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 01/04/2012 05:47 AM, Stefano Stabellini wrote:
> On Thu, 15 Dec 2011, Daniel De Graaf wrote:
>> 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.
> 
> It would be great to have a short introduction to flask in the xl man
> page. What do you think about the following?
> 
> 
> diff -r 50117a4d1a2c docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Mon Jan 02 12:43:07 2012 +0000
> +++ b/docs/man/xl.pod.1	Wed Jan 04 10:46:47 2012 +0000
> @@ -997,6 +997,20 @@ Get information about how much freeable 
>  
>  =head2 FLASK
>  
> +B<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.
> +
> +See the following document for more details:
> +
> +L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
> +
>  =over 4
>  
>  =item B<getenforce>
> 
> 
> 
> As you can see, I linked docs/misc/xsm-flask.txt from the xl man page,
> however xsm-flask.txt still references xend so it needs to be updated.

This is a good introduction; I have an update to docs/misc/xsm-flask.txt
that references xl and incorporates some of the changes in the example
policy (will post momentarily).

> Also it would be great to link the example policy too, but that one is
> not online because it is not under docs and it is not installed by
> default either. Maybe we need to move the example policy to docs? Or
> maybe it is best to install a copy of it to /etc/xen by default?
 
The example policy doesn't really belong in docs because it needs to be
compiled to be usable, and this depends on a number of other files (all
files under tools/flask/policy/policy, to be exact). Compiling and
installing FLASK policy during the normal build process (conditional on
FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
would be the best solution. The policy must be installed to /boot, not
/etc/xen, because the initial policy load happens prior to starting dom0.

-- 
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 Wed Jan 04 15:04:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSNx-0004W0-3z; Wed, 04 Jan 2012 15:04:13 +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 1RiSNv-0004Vs-Ez
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:04:11 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325689444!9756932!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 24480 invoked from network); 4 Jan 2012 15:04:04 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-21.messagelabs.com with SMTP;
	4 Jan 2012 15:04: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
	q04F35Y2006670; Wed, 4 Jan 2012 15:03: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 q04F34lb001108; 
	Wed, 4 Jan 2012 10:03:04 -0500
Message-ID: <4F046A30.6000009@tycho.nsa.gov>
Date: Wed, 04 Jan 2012 10:03:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: 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>
	<4EEA4624.3080308@tycho.nsa.gov>
	<20111215205654.GA11829@andromeda.dapyr.net>
	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 01/04/2012 05:47 AM, Stefano Stabellini wrote:
> On Thu, 15 Dec 2011, Daniel De Graaf wrote:
>> 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.
> 
> It would be great to have a short introduction to flask in the xl man
> page. What do you think about the following?
> 
> 
> diff -r 50117a4d1a2c docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1	Mon Jan 02 12:43:07 2012 +0000
> +++ b/docs/man/xl.pod.1	Wed Jan 04 10:46:47 2012 +0000
> @@ -997,6 +997,20 @@ Get information about how much freeable 
>  
>  =head2 FLASK
>  
> +B<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.
> +
> +See the following document for more details:
> +
> +L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
> +
>  =over 4
>  
>  =item B<getenforce>
> 
> 
> 
> As you can see, I linked docs/misc/xsm-flask.txt from the xl man page,
> however xsm-flask.txt still references xend so it needs to be updated.

This is a good introduction; I have an update to docs/misc/xsm-flask.txt
that references xl and incorporates some of the changes in the example
policy (will post momentarily).

> Also it would be great to link the example policy too, but that one is
> not online because it is not under docs and it is not installed by
> default either. Maybe we need to move the example policy to docs? Or
> maybe it is best to install a copy of it to /etc/xen by default?
 
The example policy doesn't really belong in docs because it needs to be
compiled to be usable, and this depends on a number of other files (all
files under tools/flask/policy/policy, to be exact). Compiling and
installing FLASK policy during the normal build process (conditional on
FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
would be the best solution. The policy must be installed to /boot, not
/etc/xen, because the initial policy load happens prior to starting dom0.

-- 
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 Wed Jan 04 15:06:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSQ0-0004aW-L0; Wed, 04 Jan 2012 15:06:20 +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 1RiSPy-0004aA-Ey
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:06:18 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325689571!7767380!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 15815 invoked from network); 4 Jan 2012 15:06:12 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-174.messagelabs.com with SMTP;
	4 Jan 2012 15:06:12 -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
	q04F5OLi004495; Wed, 4 Jan 2012 15:05: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 q04F5NO1001242; 
	Wed, 4 Jan 2012 10:05:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  4 Jan 2012 10:05:29 -0500
Message-Id: <1325689529-16546-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1325689529-16546-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <4F046A30.6000009@tycho.nsa.gov>
	<1325689529-16546-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: konrad@darnok.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2/2] flask/policy: add missing manage_domain
	rules
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 updated example policy did not include rules to allow managing the
created domains (pause, unpause, destroy); allow these actions.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.if |    7 +++++++
 tools/flask/policy/policy/modules/xen/xen.te |    2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index cd240d8..3065718 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -29,6 +29,13 @@ define(`create_domain', `
 	allow $1 $2_$1_channel:event create;
 ')
 
+# manage_domain(priv, target)
+#   Allow managing a running domain
+define(`manage_domain', `
+	allow $1 $2:domain { getdomaininfo getvcpuinfo getvcpuaffinity
+			getaddrsize pause unpause trigger shutdown destroy
+			setvcpuaffinity setdomainmaxmem };
+')
 ################################################################################
 #
 # Inter-domain communication
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 0fc31b5..c5e0883 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -86,10 +86,12 @@ auditallow dom0_t security_t:security { load_policy setenforce };
 declare_domain(domU_t)
 domain_self_comms(domU_t)
 create_domain(dom0_t, domU_t)
+manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
+manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
 ###############################################################################
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:06:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:06:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSQ0-0004aW-L0; Wed, 04 Jan 2012 15:06:20 +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 1RiSPy-0004aA-Ey
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:06:18 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325689571!7767380!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 15815 invoked from network); 4 Jan 2012 15:06:12 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-174.messagelabs.com with SMTP;
	4 Jan 2012 15:06:12 -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
	q04F5OLi004495; Wed, 4 Jan 2012 15:05: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 q04F5NO1001242; 
	Wed, 4 Jan 2012 10:05:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  4 Jan 2012 10:05:29 -0500
Message-Id: <1325689529-16546-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1325689529-16546-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <4F046A30.6000009@tycho.nsa.gov>
	<1325689529-16546-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: konrad@darnok.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2/2] flask/policy: add missing manage_domain
	rules
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 updated example policy did not include rules to allow managing the
created domains (pause, unpause, destroy); allow these actions.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.if |    7 +++++++
 tools/flask/policy/policy/modules/xen/xen.te |    2 ++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index cd240d8..3065718 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -29,6 +29,13 @@ define(`create_domain', `
 	allow $1 $2_$1_channel:event create;
 ')
 
+# manage_domain(priv, target)
+#   Allow managing a running domain
+define(`manage_domain', `
+	allow $1 $2:domain { getdomaininfo getvcpuinfo getvcpuaffinity
+			getaddrsize pause unpause trigger shutdown destroy
+			setvcpuaffinity setdomainmaxmem };
+')
 ################################################################################
 #
 # Inter-domain communication
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 0fc31b5..c5e0883 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -86,10 +86,12 @@ auditallow dom0_t security_t:security { load_policy setenforce };
 declare_domain(domU_t)
 domain_self_comms(domU_t)
 create_domain(dom0_t, domU_t)
+manage_domain(dom0_t, domU_t)
 domain_comms(dom0_t, domU_t)
 
 declare_domain(isolated_domU_t)
 create_domain(dom0_t, isolated_domU_t)
+manage_domain(dom0_t, isolated_domU_t)
 domain_comms(dom0_t, isolated_domU_t)
 
 ###############################################################################
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:06:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSQE-0004cB-7D; Wed, 04 Jan 2012 15:06:34 +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 1RiSQC-0004bS-9C
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:06:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325689584!9592833!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 18370 invoked from network); 4 Jan 2012 15:06:25 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-216.messagelabs.com with SMTP;
	4 Jan 2012 15:06:25 -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
	q04F5OLi004494; Wed, 4 Jan 2012 15:05: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 q04F5NO0001242; 
	Wed, 4 Jan 2012 10:05:23 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  4 Jan 2012 10:05:28 -0500
Message-Id: <1325689529-16546-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <4F046A30.6000009@tycho.nsa.gov>
References: <4F046A30.6000009@tycho.nsa.gov>
Cc: konrad@darnok.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1/2] docs: Update xsm-flask documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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/misc/xsm-flask.txt     |  240 +++++++++++++++++--------------------------
 tools/flask/policy/Makefile |    2 +-
 2 files changed, 97 insertions(+), 145 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 750bb28..2eb75d6 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -1,156 +1,97 @@
-These notes are compiled from xen-devel questions and postings that have occurred
-since the inclusion of XSM.  These notes are not intended to be definitive
-documentation but should address many common problems that arise when
-experimenting with XSM:FLASK.
+                     -----------------------
+                     XSM/FLASK Configuration
+                     -----------------------
 
-Xen XSM:FLASK configuration
----------------------------
+Xen provides a security framework called XSM, and FLASK is an implementation of
+a security model using this framework (at the time of writing, it is the only
+one). FLASK 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.
 
-1) cd xen-unstable.hg
-2) edit Config.mk in the toplevel xen directory as follows:
+Some examples of what FLASK can do:
+ - 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
 
-	XSM_ENABLE ?= y
-	FLASK_ENABLE ?= y
-	
-NB: Only one security module can be selected at a time.  If no module is
-selected, then the default DUMMY module will be enforced.  The DUMMY module
-only exercises the security framework and does not enforce any security
-policies.  Changing the security module selection will require recompiling xen.
-These settings will also configure the corresponding toolchain support.  
-
-3) make xen
-4) make tools
-
-
-Xen XSM:FLASK policy
---------------------
-
-These instructions will enable the configuration and build of the sample policy.
-The sample policy provides the MINIMUM policy necessary to boot a
-paravirtualized dom0 and create a pv or hvm domU.  Many of the 
-default capabilities and usages supported by dom0/domU are disallowed by the
-sample policy.  Further, the policy is comprised of a limited number of types and 
-must be adjusted to meet the specific security goals of the installation. 
-Modification of the policy is straightforward and is covered in a later section.
-
-NB: The policy is not automatically built as part of the tool support because 
-of an external dependancy on the checkpolicy compiler.  The FLASK policy uses 
-the same syntax and structure as SELinux and compiling the policy relies on 
-the SELinux policy toolchain.  This toolchain is available under many 
-distributions as well as the following URL,
-
-	http://userspace.selinuxproject.org/trac/wiki/Releases
-
-You will need at least libsepol and checkpolicy in order to compile a policy.
+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.
 
-1) cd xen-unstable.hg/tools/flask/policy
-2) make policy
-3) make install
-4) edit /etc/grub.conf, add a module line to the xen entry,
 
-	module /xenpolicy.24
+Setting up FLASK
+----------------
 
-NB: The .24 suffix reflects the policy format version and may differ for your
-system depending on the version of checkpolicy you used to build the policy.
-At the time of this writing, policy version 24 is the highest version 
-supported by the latest checkpolicy release and by the Xen Flask module.
-You can force the policy build to a specific policy version by uncommenting 
-the OUTPUT_POLICY= line in the policy Makefile and setting the value as
-desired (to any version supported by the Xen Flask module, presently in the
-range 15-24).  Make sure that your module line above matches the actual
-/xenpolicy.NN file that was created in /boot by the make install.
-
-5) reboot, and select the updated xen entry
-
-NB: The module entry can be inserted on any line after the xen kernel line.  Typical
-configurations use the last module entry or the module entry that immediately 
-follows the xen kernel entry.
-
-If you want to use the MLS policy, then set TYPE=xen-mls in the policy Makefile
-before building the policy.  Note that the MLS constraints in policy/mls
-are incomplete and are only a sample.
-
-Xen configuration of xend
--------------------------
+Xen must be compiled with XSM and FLASK enabled; by default, the security
+framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE and
+FLASK_ENABLE to "y"; this change requires a make clean and rebuild.
 
-1) cd /etc/xen
-2) edit xend-config.sxp
-3) uncomment the line containing the key:value pair entry, 
+FLASK uses only one domain configuration parameter (seclabel) defining the
+full security label of the newly created domain. If using the example policy,
+"seclabel='system_u:system_r:domU_t'" would be used for normal domains. For
+simple policies including the example policy, the user and role portions of the
+label are unused and will always be "system_u:system_r".  Most of FLASK policy
+consists of defining the interactions allowed between different types (domU_t
+would be the type in this example); FLASK policy does not distinguish between
+domains with the same type. This is the same format as used for SELinux
+labeling; see http://selinuxproject.org for more details on the use of the user,
+role, and optional MLS/MCS labels.
 
-	#(xsm_module_name dummy)
+The FLASK security framework is mostly configured using a security policy file.
+This policy file is not normally generated during the Xen build process because
+it relies on the SELinux compiler "checkpolicy"; run
 
-4) change the value entry to 'flask'
+	make -C tools/flask/policy
 
-	(xsm_module_name flask)
+to compile the example policy included with Xen. The policy is generated from
+definition files under this directory. When creating or modifying security
+policy, most modifications will be made to the xen type enforcement (.te) file
+tools/flask/policy/policy/modules/xen/xen.te or the macro definitions in xen.if.
+The XSM policy file needs to be copied to /boot and loaded as a module by grub.
+The exact position of the module does not matter as long as it is after the Xen
+kernel; it is normally placed either just above the dom0 kernel or at the end.
+Once dom0 is running, the policy can be reloaded using "xl loadpolicy".
 
-5) restart xend
+The example policy included with Xen demonstrates most of the features of FLASK
+that can be used without dom0 disaggregation. It has two main types for domUs:
 
-Creating policy controlled domains
-----------------------------------
+ - domU_t is a domain that can communicate with any other domU_t
+ - isolated_domU_t can only communicate with dom0
 
-2) Edit the domain config file and add the following entry for a pv guest,
+More types can be added to allow groups of domains to communicate without
+allowing communication between groups, or only between certain groups.
 
-	access_control = ["policy=,label=system_u:system_r:domU_t"]
+The example policy also includes a resource type (nic_dev_t) for device
+passthrough, configured to allow use by domU_t. To label the PCI device 3:2.0
+for passthrough, run:
 
-or add the following entry for a hvm guest:
+	tools/flask/utils/flask-label-pci 0000:03:02.0 system_u:object_r:nic_dev_t
 
-	access_control = ["policy=,label=system_u:system_r:domHU_t"]
+This command must be rerun on each boot or after any policy reload.
 
-NB: The 'policy' field is not used by XSM:FLASK.  The 'label' must exist in the 
-loaded policy. 'system_u:system_r:domU_t' is one of the existing labels from 
-the sample policy and shown for example purposes.
+The example policy was only tested with simple domain creation and may be
+missing rules allowing accesses by dom0 or domU when a number of hypervisor
+features are used. When first loading or writing a policy, you should run FLASK
+in permissive mode (the default) and check the Xen logs (xl dmesg) for AVC
+denials before using it in enforcing mode (flask_enforcing=1 on the command
+line, or xl setenforce).
 
-If you enabled the MLS policy, then append a MLS level (e.g. s0:c0) to the
-labels, e.g.:
 
-	access_control = ["policy=,label=system_u:system_r:domU_t:s0:c0"]
+MLS/MCS policy
+--------------
 
-2) Create the domain using the 'xm create' command.
-3) Use the 'xm list --label' command to list the running 
-domains and their labels.
-
-Updating the XSM:FLASK policy
------------------------------
-
-It is recommended that the XSM:FLASK policy be tailored to meet the specific
-security goals of the platform.  The policy is tailored by editing the xen.if and xen.te files in the 'policy' subdirectory.
-
-1) cd xen-unstable.hg/tools/flask/policy
-2) edit policy/modules/xen/xen.* - make changes to support platform security goals.
-3) make policy
-4) make install
-5) reboot
-
-Alternatively, one may reload the policy using the 'flask_loadpolicy' tool
-installed by the xen tools.
-
-1) flask_loadpolicy policy.24
-
-NB: The sample policy permits policy reloads as well as general manipulation of
-the Flask security server only from dom0.  The policy can be tailored further to
-restrict policy reloads and other manipulations to boot-time only, by removing 
-the corresponding statements from the policy.
-
-Enforcing the XSM:FLASK policy
-------------------------------
-
-By default, XSM:FLASK is compiled and installed in permissive mode.  This
-configuration will allow an XSM:FLASK system to start in enforcing mode.
+If you want to use the MLS policy, then set TYPE=xen-mls in the policy Makefile
+before building the policy.  Note that the MLS constraints in policy/mls
+are incomplete and are only a sample.
 
-1) edit /etc/grub.conf
-2) append the parameter 'flask_enforcing=1' to the xen kernel line.
-3) reboot, and select the updated xen entry
 
 AVC denials
 -----------
 
-XSM:Flask will emit avc: denied messages when a permission is denied
-by the policy, just like SELinux.  For example, if you were to use
-system_u:system_r:domU_t label for a hvm guest (rather than
-system_u:system_r:domHU_t), you would get a set of denials upon xm
-create:
+XSM:Flask will emit avc: denied messages when a permission is denied by the
+policy, just like SELinux. For example, if the HVM rules are removed from the
+declare_domain and create_domain interfaces:
 
-# xm dmesg | grep avc
+# xl dmesg | grep avc
 (XEN) avc:  denied  { setparam } for domid=0 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=hvm
 (XEN) avc:  denied  { getparam } for domid=0 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=hvm
 (XEN) avc:  denied  { irqlevel } for domid=0 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=hvm
@@ -160,21 +101,29 @@ create:
 (XEN) avc:  denied  { pcilevel } for domid=0 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=hvm
 
 Existing SELinux tools such as audit2allow can be applied to these denials, e.g.
-xm dmesg | audit2allow 
+xl dmesg | audit2allow
 
 The generated allow rules can then be fed back into the policy by
 adding them to xen.te, although manual review is advised and will
-often lead to adding parameterized rules to the interfaces in xen.if 
+often lead to adding parameterized rules to the interfaces in xen.if
 to address the general case.
 
-Device Policy
--------------
 
-Flask is capable of labeling devices and enforcing policies associated with
-them.  To enable this functionality the latest version of checkpolicy
-(>= 2.0.20) and libsepol (>=2.0.39) will be needed in order to compile it.  To
-enable the building of the new policies the following changes will need to be
-done to tools/flask/policy/Makefile.
+Device Labeling in Policy
+-------------------------
+
+FLASK is capable of labeling devices and enforcing policies associated with
+them. There are two methods to label devices: dynamic labeling using
+flask-label-pci or similar tools run in dom0, or static labeling defined in
+policy. Static labeling will make security policy machine-specific and may
+prevent the system from booting after any hardware changes (adding PCI cards,
+memory, or even changing certain BIOS settings). Dynamic labeling requires that
+the domain performing the labeling be trusted to label all the devices in the
+system properly.
+
+To enable static device labeling, a checkpolicy >= 2.0.20 and libsepol >=2.0.39
+are required. The policy Makefile (tools/flask/policy/Makefile) must also be
+changed as follows:
 
 ########################################
 #
@@ -197,7 +146,7 @@ $(LOADPATH): policy.conf
 #        $(QUIET) $(CHECKPOLICY) -t Xen $^ -o $@   (Uncomment this line)
 
 
-Pirqs, PCI devices, I/O memory and ports can all be labeled.  There are
+IRQs, PCI devices, I/O memory and ports can all be labeled.  There are
 commented out lines in xen.te policy for examples on how to label devices.
 
 Device Labeling
@@ -223,13 +172,16 @@ 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
 
-Labeling of the PCI device is tricky since there is no output in lspci that
-makes the information easily available.  The easiest way to obtain the
-information is to look at the avc denial line for the correct hex value.
+The PCI device label must be computed as the 32-bit SBDF number for the PCI
+device. It the PCI device is aaaa:bb:cc.d or bb:cc.d, then the SBDF can be
+calculated using:
+	SBDF = (a << 16) | (b << 8) | (c << 3) | d
 
-(XEN) avc:  denied  { add_device } for domid=0 device=0xc800 <---
-scontext=system_u:system_r:dom0_t tcontext=system_u:object_r:device_t
-tclass=resource
+The AVC denials for IRQs, memory, ports, and PCI devices will normally contain
+the ranges being denied to more easily determine what resources are required.
+When running in permissive mode, only the first denial of a given
+source/destination is printed to the log, so labeling devices using this method
+may require multiple passes to find all required ranges.
 
 Additional notes on XSM:FLASK
 -----------------------------
@@ -242,7 +194,7 @@ Additional notes on XSM:FLASK
 	platform to boot in permissive mode which means that the policy is loaded 
 	but not enforced.  This mode is often helpful for developing new systems 
 	and policies as the policy violations are reported on the xen console and 
-	may be viewed in dom0 through 'xm dmesg'.
+	may be viewed in dom0 through 'xl dmesg'.
 	
 	To boot the platform into enforcing mode, which means that the policy is
 	loaded and enforced, append 'flask_enforcing=1' on the grub line.
diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index e39f076..a27c813 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -20,7 +20,7 @@
 # By default, checkpolicy will create the highest
 # version policy it supports.  Setting this will
 # override the version.
-# OUTPUT_POLICY = 24
+OUTPUT_POLICY = 24
 
 # Policy Type
 # xen
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:06:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:06:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSQE-0004cB-7D; Wed, 04 Jan 2012 15:06:34 +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 1RiSQC-0004bS-9C
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:06:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325689584!9592833!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 18370 invoked from network); 4 Jan 2012 15:06:25 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-216.messagelabs.com with SMTP;
	4 Jan 2012 15:06:25 -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
	q04F5OLi004494; Wed, 4 Jan 2012 15:05: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 q04F5NO0001242; 
	Wed, 4 Jan 2012 10:05:23 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed,  4 Jan 2012 10:05:28 -0500
Message-Id: <1325689529-16546-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <4F046A30.6000009@tycho.nsa.gov>
References: <4F046A30.6000009@tycho.nsa.gov>
Cc: konrad@darnok.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>, keir@xen.org,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1/2] docs: Update xsm-flask documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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/misc/xsm-flask.txt     |  240 +++++++++++++++++--------------------------
 tools/flask/policy/Makefile |    2 +-
 2 files changed, 97 insertions(+), 145 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 750bb28..2eb75d6 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -1,156 +1,97 @@
-These notes are compiled from xen-devel questions and postings that have occurred
-since the inclusion of XSM.  These notes are not intended to be definitive
-documentation but should address many common problems that arise when
-experimenting with XSM:FLASK.
+                     -----------------------
+                     XSM/FLASK Configuration
+                     -----------------------
 
-Xen XSM:FLASK configuration
----------------------------
+Xen provides a security framework called XSM, and FLASK is an implementation of
+a security model using this framework (at the time of writing, it is the only
+one). FLASK 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.
 
-1) cd xen-unstable.hg
-2) edit Config.mk in the toplevel xen directory as follows:
+Some examples of what FLASK can do:
+ - 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
 
-	XSM_ENABLE ?= y
-	FLASK_ENABLE ?= y
-	
-NB: Only one security module can be selected at a time.  If no module is
-selected, then the default DUMMY module will be enforced.  The DUMMY module
-only exercises the security framework and does not enforce any security
-policies.  Changing the security module selection will require recompiling xen.
-These settings will also configure the corresponding toolchain support.  
-
-3) make xen
-4) make tools
-
-
-Xen XSM:FLASK policy
---------------------
-
-These instructions will enable the configuration and build of the sample policy.
-The sample policy provides the MINIMUM policy necessary to boot a
-paravirtualized dom0 and create a pv or hvm domU.  Many of the 
-default capabilities and usages supported by dom0/domU are disallowed by the
-sample policy.  Further, the policy is comprised of a limited number of types and 
-must be adjusted to meet the specific security goals of the installation. 
-Modification of the policy is straightforward and is covered in a later section.
-
-NB: The policy is not automatically built as part of the tool support because 
-of an external dependancy on the checkpolicy compiler.  The FLASK policy uses 
-the same syntax and structure as SELinux and compiling the policy relies on 
-the SELinux policy toolchain.  This toolchain is available under many 
-distributions as well as the following URL,
-
-	http://userspace.selinuxproject.org/trac/wiki/Releases
-
-You will need at least libsepol and checkpolicy in order to compile a policy.
+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.
 
-1) cd xen-unstable.hg/tools/flask/policy
-2) make policy
-3) make install
-4) edit /etc/grub.conf, add a module line to the xen entry,
 
-	module /xenpolicy.24
+Setting up FLASK
+----------------
 
-NB: The .24 suffix reflects the policy format version and may differ for your
-system depending on the version of checkpolicy you used to build the policy.
-At the time of this writing, policy version 24 is the highest version 
-supported by the latest checkpolicy release and by the Xen Flask module.
-You can force the policy build to a specific policy version by uncommenting 
-the OUTPUT_POLICY= line in the policy Makefile and setting the value as
-desired (to any version supported by the Xen Flask module, presently in the
-range 15-24).  Make sure that your module line above matches the actual
-/xenpolicy.NN file that was created in /boot by the make install.
-
-5) reboot, and select the updated xen entry
-
-NB: The module entry can be inserted on any line after the xen kernel line.  Typical
-configurations use the last module entry or the module entry that immediately 
-follows the xen kernel entry.
-
-If you want to use the MLS policy, then set TYPE=xen-mls in the policy Makefile
-before building the policy.  Note that the MLS constraints in policy/mls
-are incomplete and are only a sample.
-
-Xen configuration of xend
--------------------------
+Xen must be compiled with XSM and FLASK enabled; by default, the security
+framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE and
+FLASK_ENABLE to "y"; this change requires a make clean and rebuild.
 
-1) cd /etc/xen
-2) edit xend-config.sxp
-3) uncomment the line containing the key:value pair entry, 
+FLASK uses only one domain configuration parameter (seclabel) defining the
+full security label of the newly created domain. If using the example policy,
+"seclabel='system_u:system_r:domU_t'" would be used for normal domains. For
+simple policies including the example policy, the user and role portions of the
+label are unused and will always be "system_u:system_r".  Most of FLASK policy
+consists of defining the interactions allowed between different types (domU_t
+would be the type in this example); FLASK policy does not distinguish between
+domains with the same type. This is the same format as used for SELinux
+labeling; see http://selinuxproject.org for more details on the use of the user,
+role, and optional MLS/MCS labels.
 
-	#(xsm_module_name dummy)
+The FLASK security framework is mostly configured using a security policy file.
+This policy file is not normally generated during the Xen build process because
+it relies on the SELinux compiler "checkpolicy"; run
 
-4) change the value entry to 'flask'
+	make -C tools/flask/policy
 
-	(xsm_module_name flask)
+to compile the example policy included with Xen. The policy is generated from
+definition files under this directory. When creating or modifying security
+policy, most modifications will be made to the xen type enforcement (.te) file
+tools/flask/policy/policy/modules/xen/xen.te or the macro definitions in xen.if.
+The XSM policy file needs to be copied to /boot and loaded as a module by grub.
+The exact position of the module does not matter as long as it is after the Xen
+kernel; it is normally placed either just above the dom0 kernel or at the end.
+Once dom0 is running, the policy can be reloaded using "xl loadpolicy".
 
-5) restart xend
+The example policy included with Xen demonstrates most of the features of FLASK
+that can be used without dom0 disaggregation. It has two main types for domUs:
 
-Creating policy controlled domains
-----------------------------------
+ - domU_t is a domain that can communicate with any other domU_t
+ - isolated_domU_t can only communicate with dom0
 
-2) Edit the domain config file and add the following entry for a pv guest,
+More types can be added to allow groups of domains to communicate without
+allowing communication between groups, or only between certain groups.
 
-	access_control = ["policy=,label=system_u:system_r:domU_t"]
+The example policy also includes a resource type (nic_dev_t) for device
+passthrough, configured to allow use by domU_t. To label the PCI device 3:2.0
+for passthrough, run:
 
-or add the following entry for a hvm guest:
+	tools/flask/utils/flask-label-pci 0000:03:02.0 system_u:object_r:nic_dev_t
 
-	access_control = ["policy=,label=system_u:system_r:domHU_t"]
+This command must be rerun on each boot or after any policy reload.
 
-NB: The 'policy' field is not used by XSM:FLASK.  The 'label' must exist in the 
-loaded policy. 'system_u:system_r:domU_t' is one of the existing labels from 
-the sample policy and shown for example purposes.
+The example policy was only tested with simple domain creation and may be
+missing rules allowing accesses by dom0 or domU when a number of hypervisor
+features are used. When first loading or writing a policy, you should run FLASK
+in permissive mode (the default) and check the Xen logs (xl dmesg) for AVC
+denials before using it in enforcing mode (flask_enforcing=1 on the command
+line, or xl setenforce).
 
-If you enabled the MLS policy, then append a MLS level (e.g. s0:c0) to the
-labels, e.g.:
 
-	access_control = ["policy=,label=system_u:system_r:domU_t:s0:c0"]
+MLS/MCS policy
+--------------
 
-2) Create the domain using the 'xm create' command.
-3) Use the 'xm list --label' command to list the running 
-domains and their labels.
-
-Updating the XSM:FLASK policy
------------------------------
-
-It is recommended that the XSM:FLASK policy be tailored to meet the specific
-security goals of the platform.  The policy is tailored by editing the xen.if and xen.te files in the 'policy' subdirectory.
-
-1) cd xen-unstable.hg/tools/flask/policy
-2) edit policy/modules/xen/xen.* - make changes to support platform security goals.
-3) make policy
-4) make install
-5) reboot
-
-Alternatively, one may reload the policy using the 'flask_loadpolicy' tool
-installed by the xen tools.
-
-1) flask_loadpolicy policy.24
-
-NB: The sample policy permits policy reloads as well as general manipulation of
-the Flask security server only from dom0.  The policy can be tailored further to
-restrict policy reloads and other manipulations to boot-time only, by removing 
-the corresponding statements from the policy.
-
-Enforcing the XSM:FLASK policy
-------------------------------
-
-By default, XSM:FLASK is compiled and installed in permissive mode.  This
-configuration will allow an XSM:FLASK system to start in enforcing mode.
+If you want to use the MLS policy, then set TYPE=xen-mls in the policy Makefile
+before building the policy.  Note that the MLS constraints in policy/mls
+are incomplete and are only a sample.
 
-1) edit /etc/grub.conf
-2) append the parameter 'flask_enforcing=1' to the xen kernel line.
-3) reboot, and select the updated xen entry
 
 AVC denials
 -----------
 
-XSM:Flask will emit avc: denied messages when a permission is denied
-by the policy, just like SELinux.  For example, if you were to use
-system_u:system_r:domU_t label for a hvm guest (rather than
-system_u:system_r:domHU_t), you would get a set of denials upon xm
-create:
+XSM:Flask will emit avc: denied messages when a permission is denied by the
+policy, just like SELinux. For example, if the HVM rules are removed from the
+declare_domain and create_domain interfaces:
 
-# xm dmesg | grep avc
+# xl dmesg | grep avc
 (XEN) avc:  denied  { setparam } for domid=0 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=hvm
 (XEN) avc:  denied  { getparam } for domid=0 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=hvm
 (XEN) avc:  denied  { irqlevel } for domid=0 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=hvm
@@ -160,21 +101,29 @@ create:
 (XEN) avc:  denied  { pcilevel } for domid=0 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=hvm
 
 Existing SELinux tools such as audit2allow can be applied to these denials, e.g.
-xm dmesg | audit2allow 
+xl dmesg | audit2allow
 
 The generated allow rules can then be fed back into the policy by
 adding them to xen.te, although manual review is advised and will
-often lead to adding parameterized rules to the interfaces in xen.if 
+often lead to adding parameterized rules to the interfaces in xen.if
 to address the general case.
 
-Device Policy
--------------
 
-Flask is capable of labeling devices and enforcing policies associated with
-them.  To enable this functionality the latest version of checkpolicy
-(>= 2.0.20) and libsepol (>=2.0.39) will be needed in order to compile it.  To
-enable the building of the new policies the following changes will need to be
-done to tools/flask/policy/Makefile.
+Device Labeling in Policy
+-------------------------
+
+FLASK is capable of labeling devices and enforcing policies associated with
+them. There are two methods to label devices: dynamic labeling using
+flask-label-pci or similar tools run in dom0, or static labeling defined in
+policy. Static labeling will make security policy machine-specific and may
+prevent the system from booting after any hardware changes (adding PCI cards,
+memory, or even changing certain BIOS settings). Dynamic labeling requires that
+the domain performing the labeling be trusted to label all the devices in the
+system properly.
+
+To enable static device labeling, a checkpolicy >= 2.0.20 and libsepol >=2.0.39
+are required. The policy Makefile (tools/flask/policy/Makefile) must also be
+changed as follows:
 
 ########################################
 #
@@ -197,7 +146,7 @@ $(LOADPATH): policy.conf
 #        $(QUIET) $(CHECKPOLICY) -t Xen $^ -o $@   (Uncomment this line)
 
 
-Pirqs, PCI devices, I/O memory and ports can all be labeled.  There are
+IRQs, PCI devices, I/O memory and ports can all be labeled.  There are
 commented out lines in xen.te policy for examples on how to label devices.
 
 Device Labeling
@@ -223,13 +172,16 @@ 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
 
-Labeling of the PCI device is tricky since there is no output in lspci that
-makes the information easily available.  The easiest way to obtain the
-information is to look at the avc denial line for the correct hex value.
+The PCI device label must be computed as the 32-bit SBDF number for the PCI
+device. It the PCI device is aaaa:bb:cc.d or bb:cc.d, then the SBDF can be
+calculated using:
+	SBDF = (a << 16) | (b << 8) | (c << 3) | d
 
-(XEN) avc:  denied  { add_device } for domid=0 device=0xc800 <---
-scontext=system_u:system_r:dom0_t tcontext=system_u:object_r:device_t
-tclass=resource
+The AVC denials for IRQs, memory, ports, and PCI devices will normally contain
+the ranges being denied to more easily determine what resources are required.
+When running in permissive mode, only the first denial of a given
+source/destination is printed to the log, so labeling devices using this method
+may require multiple passes to find all required ranges.
 
 Additional notes on XSM:FLASK
 -----------------------------
@@ -242,7 +194,7 @@ Additional notes on XSM:FLASK
 	platform to boot in permissive mode which means that the policy is loaded 
 	but not enforced.  This mode is often helpful for developing new systems 
 	and policies as the policy violations are reported on the xen console and 
-	may be viewed in dom0 through 'xm dmesg'.
+	may be viewed in dom0 through 'xl dmesg'.
 	
 	To boot the platform into enforcing mode, which means that the policy is
 	loaded and enforced, append 'flask_enforcing=1' on the grub line.
diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index e39f076..a27c813 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -20,7 +20,7 @@
 # By default, checkpolicy will create the highest
 # version policy it supports.  Setting this will
 # override the version.
-# OUTPUT_POLICY = 24
+OUTPUT_POLICY = 24
 
 # Policy Type
 # xen
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:15:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:15:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSY8-000521-6P; Wed, 04 Jan 2012 15:14:44 +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 1RiSY6-00051s-TX
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:14:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325690075!9702715!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21027 invoked from network); 4 Jan 2012 15:14:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 15:14:36 -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
	q04FERSc029248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 15:14:28 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q04FENGp014661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 15:14:24 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
	q04FELbw015029; Wed, 4 Jan 2012 09:14:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 07:14:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C07B34046A; Wed,  4 Jan 2012 10:12:49 -0500 (EST)
Date: Wed, 4 Jan 2012 10:12:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120104151249.GF3322@phenom.dumpdata.com>
References: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
	<1325677192-10459-2-git-send-email-ian.campbell@citrix.com>
	<4F044D10020000780006A5B4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F044D10020000780006A5B4@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.0A090208.4F046CD5.0053,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Haogang Chen <haogangchen@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/xenbus: don't reimplement
 kvasprintf via a fixed size buffer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 11:58:56AM +0000, Jan Beulich wrote:
> >>> On 04.01.12 at 12:39, Ian Campbell <ian.campbell@citrix.com> wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

OK, took:

Ian Campbell (3):
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      xenbus: maximum buffer size is XENSTORE_PAYLOAD_MAX
      xen/xenbus: don't reimplement kvasprintf via a fixed size buffer

And put the ' xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX'
on the stable@kernel.org as well.

Thanks!

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:15:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:15:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSY8-000521-6P; Wed, 04 Jan 2012 15:14:44 +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 1RiSY6-00051s-TX
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:14:43 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325690075!9702715!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21027 invoked from network); 4 Jan 2012 15:14:36 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 15:14:36 -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
	q04FERSc029248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 15:14:28 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q04FENGp014661
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 15:14:24 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
	q04FELbw015029; Wed, 4 Jan 2012 09:14:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 07:14:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C07B34046A; Wed,  4 Jan 2012 10:12:49 -0500 (EST)
Date: Wed, 4 Jan 2012 10:12:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120104151249.GF3322@phenom.dumpdata.com>
References: <1325677158.25206.244.camel@zakaz.uk.xensource.com>
	<1325677192-10459-2-git-send-email-ian.campbell@citrix.com>
	<4F044D10020000780006A5B4@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F044D10020000780006A5B4@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.0A090208.4F046CD5.0053,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Haogang Chen <haogangchen@gmail.com>
Subject: Re: [Xen-devel] [PATCH 2/2] xen/xenbus: don't reimplement
 kvasprintf via a fixed size buffer
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 11:58:56AM +0000, Jan Beulich wrote:
> >>> On 04.01.12 at 12:39, Ian Campbell <ian.campbell@citrix.com> wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>

OK, took:

Ian Campbell (3):
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      xenbus: maximum buffer size is XENSTORE_PAYLOAD_MAX
      xen/xenbus: don't reimplement kvasprintf via a fixed size buffer

And put the ' xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX'
on the stable@kernel.org as well.

Thanks!

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:29:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:29:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSmG-0005DJ-MR; Wed, 04 Jan 2012 15:29:20 +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 1RiSmE-0005DE-RX
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:29:19 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325690950!7756334!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13358 invoked from network); 4 Jan 2012 15:29:11 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.13)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 15:29:11 -0000
Received: from mail61-tx2-R.bigfish.com (10.9.14.253) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:29:10 +0000
Received: from mail61-tx2 (localhost [127.0.0.1])	by mail61-tx2-R.bigfish.com
	(Postfix) with ESMTP id 0C1465802A7	for
	<xen-devel@lists.xensource.com>; Wed, 4 Jan 2012 15:29:10 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h62h)
X-Spam-TCS-SCL: 1: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 mail61-tx2 (localhost.localdomain [127.0.0.1]) by mail61-tx2
	(MessageSwitch) id 1325690949793550_29938;
	Wed,  4 Jan 2012 15:29:09 +0000 (UTC)
Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.251])	by
	mail61-tx2.bigfish.com (Postfix) with ESMTP id BB784640086	for
	<xen-devel@lists.xensource.com>; Wed,  4 Jan 2012 15:29:09 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:29:08 +0000
X-WSS-ID: 0LXA5OJ-02-0HW-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 23187C8004	for <xen-devel@lists.xensource.com>;
	Wed,  4 Jan 2012 09:29:07 -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, 4 Jan 2012 09:29:20 -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, 4 Jan 2012 09:29:04 -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, 4 Jan 2012
	10:28:55 -0500
Message-ID: <4F047035.1060304@amd.com>
Date: Wed, 4 Jan 2012 16:28:53 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------000704030209060104090003"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Xen 4.1: x86/ucode: fix for AMD Fam15 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000704030209060104090003
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


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>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1


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

--------------000704030209060104090003
Content-Type: text/plain; name="xen41_ucode.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen41_ucode.diff"
Content-Description: xen41_ucode.diff

diff -r 14dbd6be46c8 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Sun Dec 18 14:52:52 2011 +0000
+++ b/xen/arch/x86/microcode_amd.c	Wed Jan 04 15:42:55 2012 +0100
@@ -33,11 +33,11 @@
 #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))
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
+};
 
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
@@ -65,10 +65,10 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
 
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    struct microcode_header_amd *mc_header = mc;
+    struct microcode_header_amd *mc_header = mc_amd->mpb;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
     unsigned int i;
@@ -97,9 +97,9 @@ static int microcode_fits(void *mc, int 
 
     if ( !equiv_cpu_id )
     {
-        printk(KERN_ERR "microcode: CPU%d cpu_id "
+        printk(KERN_INFO "microcode: CPU%d cpu_id "
                "not found in equivalent cpu table\n", cpu);
-        return -EINVAL;
+        return 0;
     }
 
     if ( (mc_header->processor_rev_id) != equiv_cpu_id )
@@ -111,14 +111,14 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+        return 0;
 
     printk(KERN_INFO "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
 
 out:
-    return 0;
+    return 1;
 }
 
 static int apply_microcode(int cpu)
@@ -127,16 +127,21 @@ 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);
 
     if ( mc_amd == NULL )
-        return -EINVAL;
+       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);
@@ -144,61 +149,67 @@ 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("microcode: CPU%d updated from revision "
            "0x%x to 0x%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)
 {
-    struct microcode_header_amd *mc_header;
-    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;
     }
 
-    mc_header = (struct microcode_header_amd *)(&bufp[off+8]);
+    printk(KERN_INFO "microcode: size %lu, total_size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
-
-    printk(KERN_INFO "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;
 }
@@ -253,7 +264,7 @@ static int cpu_request_microcode(int cpu
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    void *mc;
+    struct microcode_amd *mc_amd, *mc_old;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -274,8 +285,8 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc == NULL )
+    mc_amd = xmalloc(struct microcode_amd);
+    if ( mc_amd == NULL )
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
@@ -283,32 +294,37 @@ static int cpu_request_microcode(int cpu
         goto out;
     }
 
+    mc_old = uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd = mc;
+    uci->mc.mc_amd = mc_amd;
 
     /*
      * 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)
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, size,
+                                                  &offset)) == 0)
     {
-        error = microcode_fits(mc, cpu);
-        if (error != 0)
+        error = microcode_fits(mc_amd, cpu);
+        if (error <= 0)
             continue;
 
         error = apply_microcode(cpu);
-        if (error == 0)
+        if (error == 0) {
+            error = 1;
             break;
+        }
     }
 
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc = NULL;
+    if (error == 0) {
+        xfree(mc_old);
+        return 0;
     }
-    uci->mc.mc_amd = mc;
 
 out:
     xfree(equiv_cpu_table);
diff -r 14dbd6be46c8 xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Sun Dec 18 14:52:52 2011 +0000
+++ b/xen/include/asm-x86/microcode.h	Wed Jan 04 15:42:55 2012 +0100
@@ -71,8 +71,8 @@ struct microcode_header_amd {
 } __attribute__((packed));
 
 struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
+    void *mpb;
+    size_t mpb_size;
 };
 
 struct cpu_signature {

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

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

--------------000704030209060104090003--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:29:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:29:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSmG-0005DJ-MR; Wed, 04 Jan 2012 15:29:20 +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 1RiSmE-0005DE-RX
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:29:19 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325690950!7756334!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13358 invoked from network); 4 Jan 2012 15:29:11 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.13)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 15:29:11 -0000
Received: from mail61-tx2-R.bigfish.com (10.9.14.253) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:29:10 +0000
Received: from mail61-tx2 (localhost [127.0.0.1])	by mail61-tx2-R.bigfish.com
	(Postfix) with ESMTP id 0C1465802A7	for
	<xen-devel@lists.xensource.com>; Wed, 4 Jan 2012 15:29:10 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h62h)
X-Spam-TCS-SCL: 1: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 mail61-tx2 (localhost.localdomain [127.0.0.1]) by mail61-tx2
	(MessageSwitch) id 1325690949793550_29938;
	Wed,  4 Jan 2012 15:29:09 +0000 (UTC)
Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.251])	by
	mail61-tx2.bigfish.com (Postfix) with ESMTP id BB784640086	for
	<xen-devel@lists.xensource.com>; Wed,  4 Jan 2012 15:29:09 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:29:08 +0000
X-WSS-ID: 0LXA5OJ-02-0HW-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 23187C8004	for <xen-devel@lists.xensource.com>;
	Wed,  4 Jan 2012 09:29:07 -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, 4 Jan 2012 09:29:20 -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, 4 Jan 2012 09:29:04 -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, 4 Jan 2012
	10:28:55 -0500
Message-ID: <4F047035.1060304@amd.com>
Date: Wed, 4 Jan 2012 16:28:53 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------000704030209060104090003"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Xen 4.1: x86/ucode: fix for AMD Fam15 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------000704030209060104090003
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


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>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1


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

--------------000704030209060104090003
Content-Type: text/plain; name="xen41_ucode.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen41_ucode.diff"
Content-Description: xen41_ucode.diff

diff -r 14dbd6be46c8 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Sun Dec 18 14:52:52 2011 +0000
+++ b/xen/arch/x86/microcode_amd.c	Wed Jan 04 15:42:55 2012 +0100
@@ -33,11 +33,11 @@
 #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))
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
+};
 
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
@@ -65,10 +65,10 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
 
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    struct microcode_header_amd *mc_header = mc;
+    struct microcode_header_amd *mc_header = mc_amd->mpb;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
     unsigned int i;
@@ -97,9 +97,9 @@ static int microcode_fits(void *mc, int 
 
     if ( !equiv_cpu_id )
     {
-        printk(KERN_ERR "microcode: CPU%d cpu_id "
+        printk(KERN_INFO "microcode: CPU%d cpu_id "
                "not found in equivalent cpu table\n", cpu);
-        return -EINVAL;
+        return 0;
     }
 
     if ( (mc_header->processor_rev_id) != equiv_cpu_id )
@@ -111,14 +111,14 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+        return 0;
 
     printk(KERN_INFO "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
 
 out:
-    return 0;
+    return 1;
 }
 
 static int apply_microcode(int cpu)
@@ -127,16 +127,21 @@ 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);
 
     if ( mc_amd == NULL )
-        return -EINVAL;
+       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);
@@ -144,61 +149,67 @@ 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("microcode: CPU%d updated from revision "
            "0x%x to 0x%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)
 {
-    struct microcode_header_amd *mc_header;
-    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;
     }
 
-    mc_header = (struct microcode_header_amd *)(&bufp[off+8]);
+    printk(KERN_INFO "microcode: size %lu, total_size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
-
-    printk(KERN_INFO "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;
 }
@@ -253,7 +264,7 @@ static int cpu_request_microcode(int cpu
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    void *mc;
+    struct microcode_amd *mc_amd, *mc_old;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -274,8 +285,8 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc == NULL )
+    mc_amd = xmalloc(struct microcode_amd);
+    if ( mc_amd == NULL )
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
@@ -283,32 +294,37 @@ static int cpu_request_microcode(int cpu
         goto out;
     }
 
+    mc_old = uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd = mc;
+    uci->mc.mc_amd = mc_amd;
 
     /*
      * 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)
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, size,
+                                                  &offset)) == 0)
     {
-        error = microcode_fits(mc, cpu);
-        if (error != 0)
+        error = microcode_fits(mc_amd, cpu);
+        if (error <= 0)
             continue;
 
         error = apply_microcode(cpu);
-        if (error == 0)
+        if (error == 0) {
+            error = 1;
             break;
+        }
     }
 
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc = NULL;
+    if (error == 0) {
+        xfree(mc_old);
+        return 0;
     }
-    uci->mc.mc_amd = mc;
 
 out:
     xfree(equiv_cpu_table);
diff -r 14dbd6be46c8 xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Sun Dec 18 14:52:52 2011 +0000
+++ b/xen/include/asm-x86/microcode.h	Wed Jan 04 15:42:55 2012 +0100
@@ -71,8 +71,8 @@ struct microcode_header_amd {
 } __attribute__((packed));
 
 struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
+    void *mpb;
+    size_t mpb_size;
 };
 
 struct cpu_signature {

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

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

--------------000704030209060104090003--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:31:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiSny-0005It-Ce; Wed, 04 Jan 2012 15:31:06 +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 1RiSnw-0005IV-NJ
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:31:05 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325691019!54656900!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 8052 invoked from network); 4 Jan 2012 15:30:20 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 15:30:20 -0000
Received: from mail84-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:30:56 +0000
Received: from mail84-ch1 (localhost [127.0.0.1])	by mail84-ch1-R.bigfish.com
	(Postfix) with ESMTP id 942B24801EE	for
	<xen-devel@lists.xensource.com>; Wed, 4 Jan 2012 15:30:56 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,0,13,
Received: from mail84-ch1 (localhost.localdomain [127.0.0.1]) by mail84-ch1
	(MessageSwitch) id 1325691056435912_15246;
	Wed,  4 Jan 2012 15:30:56 +0000 (UTC)
Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail84-ch1.bigfish.com (Postfix) with ESMTP id
	65C4E420141 for <xen-devel@lists.xensource.com>;
	Wed,  4 Jan 2012 15:30:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:30:54 +0000
X-WSS-ID: 0LXA5RG-02-0MP-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 23727C8003	for <xen-devel@lists.xensource.com>;
	Wed,  4 Jan 2012 09:30:51 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 4 Jan 2012 09:31:03 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 4 Jan 2012 09:30:51 -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, 4 Jan 2012
	10:30:47 -0500
Message-ID: <4F0470A7.8010005@amd.com>
Date: Wed, 4 Jan 2012 16:30:47 +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="------------030607000306010401020702"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Xen 4.0: x86/ucode: fix for AMD Fam15 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------030607000306010401020702
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


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>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0



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

--------------030607000306010401020702
Content-Type: text/plain; name="xen40_ucode.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen40_ucode.diff"
Content-Description: xen40_ucode.diff

diff -r 5d372b8bccef xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Sun Dec 18 14:51:04 2011 +0000
+++ b/xen/arch/x86/microcode_amd.c	Wed Jan 04 14:46:05 2012 +0100
@@ -33,11 +33,11 @@
 #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))
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
+};
 
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
@@ -66,10 +66,10 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
 
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    struct microcode_header_amd *mc_header = mc;
+    struct microcode_header_amd *mc_header = mc_amd->mpb;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
     unsigned int i;
@@ -98,9 +98,9 @@ static int microcode_fits(void *mc, int 
 
     if ( !equiv_cpu_id )
     {
-        printk(KERN_ERR "microcode: CPU%d cpu_id "
+        printk(KERN_INFO "microcode: CPU%d cpu_id "
                "not found in equivalent cpu table\n", cpu);
-        return -EINVAL;
+        return 0;
     }
 
     if ( (mc_header->processor_rev_id) != equiv_cpu_id )
@@ -112,14 +112,14 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+        return 0;
 
     printk(KERN_INFO "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
 
 out:
-    return 0;
+    return 1;
 }
 
 static int apply_microcode(int cpu)
@@ -128,16 +128,21 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     uint32_t rev, dummy;
     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);
 
     if ( mc_amd == NULL )
-        return -EINVAL;
+       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 */
     rdmsr(MSR_AMD_PATCHLEVEL, rev, dummy);
@@ -145,61 +150,67 @@ 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("microcode: CPU%d updated from revision "
            "0x%x to 0x%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)
 {
-    struct microcode_header_amd *mc_header;
-    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;
     }
 
-    mc_header = (struct microcode_header_amd *)(&bufp[off+8]);
+    printk(KERN_INFO "microcode: size %lu, total_size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
-
-    printk(KERN_INFO "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;
 }
@@ -254,7 +265,7 @@ static int cpu_request_microcode(int cpu
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    void *mc;
+    struct microcode_amd *mc_amd, *mc_old;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -275,8 +286,8 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc == NULL )
+    mc_amd = xmalloc(struct microcode_amd);
+    if ( mc_amd == NULL )
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
@@ -284,32 +295,37 @@ static int cpu_request_microcode(int cpu
         goto out;
     }
 
+    mc_old = uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd = mc;
+    uci->mc.mc_amd = mc_amd;
 
     /*
      * 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)
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, size,
+                                                  &offset)) == 0)
     {
-        error = microcode_fits(mc, cpu);
-        if (error != 0)
+        error = microcode_fits(mc_amd, cpu);
+        if (error <= 0)
             continue;
 
         error = apply_microcode(cpu);
-        if (error == 0)
+        if (error == 0) {
+            error = 1;
             break;
+        }
     }
 
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc = NULL;
+    if (error == 0) {
+        xfree(mc_old);
+        return 0;
     }
-    uci->mc.mc_amd = mc;
 
 out:
     xfree(equiv_cpu_table);
diff -r 5d372b8bccef xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Sun Dec 18 14:51:04 2011 +0000
+++ b/xen/include/asm-x86/microcode.h	Wed Jan 04 14:46:05 2012 +0100
@@ -71,8 +71,8 @@ struct microcode_header_amd {
 } __attribute__((packed));
 
 struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
+    void *mpb;
+    size_t mpb_size;
 };
 
 struct cpu_signature {

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

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

--------------030607000306010401020702--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:31:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiSny-0005It-Ce; Wed, 04 Jan 2012 15:31:06 +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 1RiSnw-0005IV-NJ
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:31:05 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325691019!54656900!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 8052 invoked from network); 4 Jan 2012 15:30:20 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 15:30:20 -0000
Received: from mail84-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:30:56 +0000
Received: from mail84-ch1 (localhost [127.0.0.1])	by mail84-ch1-R.bigfish.com
	(Postfix) with ESMTP id 942B24801EE	for
	<xen-devel@lists.xensource.com>; Wed, 4 Jan 2012 15:30:56 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,0,13,
Received: from mail84-ch1 (localhost.localdomain [127.0.0.1]) by mail84-ch1
	(MessageSwitch) id 1325691056435912_15246;
	Wed,  4 Jan 2012 15:30:56 +0000 (UTC)
Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail84-ch1.bigfish.com (Postfix) with ESMTP id
	65C4E420141 for <xen-devel@lists.xensource.com>;
	Wed,  4 Jan 2012 15:30:56 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:30:54 +0000
X-WSS-ID: 0LXA5RG-02-0MP-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 23727C8003	for <xen-devel@lists.xensource.com>;
	Wed,  4 Jan 2012 09:30:51 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 4 Jan 2012 09:31:03 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 4 Jan 2012 09:30:51 -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, 4 Jan 2012
	10:30:47 -0500
Message-ID: <4F0470A7.8010005@amd.com>
Date: Wed, 4 Jan 2012 16:30:47 +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="------------030607000306010401020702"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Xen 4.0: x86/ucode: fix for AMD Fam15 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------030607000306010401020702
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


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>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0



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

--------------030607000306010401020702
Content-Type: text/plain; name="xen40_ucode.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen40_ucode.diff"
Content-Description: xen40_ucode.diff

diff -r 5d372b8bccef xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Sun Dec 18 14:51:04 2011 +0000
+++ b/xen/arch/x86/microcode_amd.c	Wed Jan 04 14:46:05 2012 +0100
@@ -33,11 +33,11 @@
 #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))
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
+};
 
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
@@ -66,10 +66,10 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
 
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    struct microcode_header_amd *mc_header = mc;
+    struct microcode_header_amd *mc_header = mc_amd->mpb;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
     unsigned int i;
@@ -98,9 +98,9 @@ static int microcode_fits(void *mc, int 
 
     if ( !equiv_cpu_id )
     {
-        printk(KERN_ERR "microcode: CPU%d cpu_id "
+        printk(KERN_INFO "microcode: CPU%d cpu_id "
                "not found in equivalent cpu table\n", cpu);
-        return -EINVAL;
+        return 0;
     }
 
     if ( (mc_header->processor_rev_id) != equiv_cpu_id )
@@ -112,14 +112,14 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+        return 0;
 
     printk(KERN_INFO "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
 
 out:
-    return 0;
+    return 1;
 }
 
 static int apply_microcode(int cpu)
@@ -128,16 +128,21 @@ static int apply_microcode(int cpu)
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
     uint32_t rev, dummy;
     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);
 
     if ( mc_amd == NULL )
-        return -EINVAL;
+       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 */
     rdmsr(MSR_AMD_PATCHLEVEL, rev, dummy);
@@ -145,61 +150,67 @@ 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("microcode: CPU%d updated from revision "
            "0x%x to 0x%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)
 {
-    struct microcode_header_amd *mc_header;
-    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;
     }
 
-    mc_header = (struct microcode_header_amd *)(&bufp[off+8]);
+    printk(KERN_INFO "microcode: size %lu, total_size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
-
-    printk(KERN_INFO "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;
 }
@@ -254,7 +265,7 @@ static int cpu_request_microcode(int cpu
     int error = 0;
     int ret;
     struct ucode_cpu_info *uci = &per_cpu(ucode_cpu_info, cpu);
-    void *mc;
+    struct microcode_amd *mc_amd, *mc_old;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -275,8 +286,8 @@ static int cpu_request_microcode(int cpu
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc == NULL )
+    mc_amd = xmalloc(struct microcode_amd);
+    if ( mc_amd == NULL )
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
@@ -284,32 +295,37 @@ static int cpu_request_microcode(int cpu
         goto out;
     }
 
+    mc_old = uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd = mc;
+    uci->mc.mc_amd = mc_amd;
 
     /*
      * 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)
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, size,
+                                                  &offset)) == 0)
     {
-        error = microcode_fits(mc, cpu);
-        if (error != 0)
+        error = microcode_fits(mc_amd, cpu);
+        if (error <= 0)
             continue;
 
         error = apply_microcode(cpu);
-        if (error == 0)
+        if (error == 0) {
+            error = 1;
             break;
+        }
     }
 
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc = NULL;
+    if (error == 0) {
+        xfree(mc_old);
+        return 0;
     }
-    uci->mc.mc_amd = mc;
 
 out:
     xfree(equiv_cpu_table);
diff -r 5d372b8bccef xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Sun Dec 18 14:51:04 2011 +0000
+++ b/xen/include/asm-x86/microcode.h	Wed Jan 04 14:46:05 2012 +0100
@@ -71,8 +71,8 @@ struct microcode_header_amd {
 } __attribute__((packed));
 
 struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
+    void *mpb;
+    size_t mpb_size;
 };
 
 struct cpu_signature {

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

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

--------------030607000306010401020702--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:33:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSq7-0005TO-1E; Wed, 04 Jan 2012 15:33:19 +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 1RiSq5-0005Sw-KL
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:33:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325691189!9610239!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1258 invoked from network); 4 Jan 2012 15:33:10 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	VA3EHSOBE008.bigfish.com) (216.32.180.11)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 15:33:10 -0000
Received: from mail84-va3-R.bigfish.com (10.7.14.251) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:33:09 +0000
Received: from mail84-va3 (localhost [127.0.0.1])	by mail84-va3-R.bigfish.com
	(Postfix) with ESMTP id 64F1618019A	for
	<xen-devel@lists.xensource.com>; Wed, 4 Jan 2012 15:33:09 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3
	(MessageSwitch) id 132569118873994_678;
	Wed,  4 Jan 2012 15:33:08 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.247])	by
	mail84-va3.bigfish.com (Postfix) with ESMTP id 01F2528004E	for
	<xen-devel@lists.xensource.com>; Wed,  4 Jan 2012 15:33:08 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server id
	14.1.225.22; Wed, 4 Jan 2012 15:33:07 +0000
X-WSS-ID: 0LXA5V4-01-BKF-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 2C1F71028020	for <xen-devel@lists.xensource.com>;
	Wed,  4 Jan 2012 09:33:03 -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, 4 Jan 2012 09:33:15 -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, 4 Jan 2012 09:32:48 -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, 4 Jan 2012
	10:32:47 -0500
Message-ID: <4F04711E.2010807@amd.com>
Date: Wed, 4 Jan 2012 16:32:46 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------090403060106070807060106"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Xen 3.3: x86/ucode: fix for AMD Fam15 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------090403060106070807060106
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


86/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>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 3.3


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

--------------090403060106070807060106
Content-Type: text/plain; name="xen33_ucode.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen33_ucode.diff"
Content-Description: xen33_ucode.diff

diff -r 98fe9e75d24b xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Oct 26 13:36:51 2009 +0000
+++ b/xen/arch/x86/microcode_amd.c	Wed Jan 04 14:13:58 2012 +0100
@@ -33,11 +33,11 @@
 #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))
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
+};
 
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
@@ -66,10 +66,10 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
 
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-    struct microcode_header_amd *mc_header = mc;
+    struct microcode_header_amd *mc_header = mc_amd->mpb;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
     unsigned int i;
@@ -98,9 +98,9 @@ static int microcode_fits(void *mc, int 
 
     if ( !equiv_cpu_id )
     {
-        printk(KERN_ERR "microcode: CPU%d cpu_id "
+        printk(KERN_INFO "microcode: CPU%d cpu_id "
                "not found in equivalent cpu table\n", cpu);
-        return -EINVAL;
+        return 0;
     }
 
     if ( (mc_header->processor_rev_id) != equiv_cpu_id )
@@ -112,14 +112,14 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+        return 0;
 
     printk(KERN_INFO "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
 
 out:
-    return 0;
+    return 1;
 }
 
 static int apply_microcode(struct ucode_cpu_info *uci, int cpu)
@@ -127,16 +127,21 @@ static int apply_microcode(struct ucode_
     unsigned long flags;
     uint32_t rev, dummy;
     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);
 
     if ( mc_amd == NULL )
-        return -EINVAL;
+       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 */
     rdmsr(MSR_AMD_PATCHLEVEL, rev, dummy);
@@ -144,61 +149,67 @@ static int apply_microcode(struct ucode_
     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("microcode: CPU%d updated from revision "
            "0x%x to 0x%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)
 {
-    struct microcode_header_amd *mc_header;
-    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;
     }
 
-    mc_header = (struct microcode_header_amd *)(&bufp[off+8]);
+    printk(KERN_INFO "microcode: size %lu, total_size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
-
-    printk(KERN_INFO "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;
 }
@@ -253,7 +264,7 @@ static int cpu_request_microcode(struct 
     unsigned long offset = 0;
     int error = 0;
     int ret;
-    void *mc;
+    struct microcode_amd *mc_amd, *mc_old;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -275,8 +286,8 @@ static int cpu_request_microcode(struct 
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc == NULL )
+    mc_amd = xmalloc(struct microcode_amd);
+    if ( mc_amd == NULL )
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
@@ -284,32 +295,37 @@ static int cpu_request_microcode(struct 
         goto out;
     }
 
+    mc_old = uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd = mc;
+    uci->mc.mc_amd = mc_amd;
 
     /*
      * 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)
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, size,
+                                                  &offset)) == 0)
     {
-        error = microcode_fits(mc, cpu);
-        if (error != 0)
+        error = microcode_fits(mc_amd, cpu);
+        if (error <= 0)
             continue;
 
         error = apply_microcode(uci, cpu);
-        if (error == 0)
+        if (error == 0) {
+            error = 1;
             break;
+        }
     }
 
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc = NULL;
+    if (error == 1) {
+        xfree(mc_old);
+        return 0;
     }
-    uci->mc.mc_amd = mc;
 
 out:
     xfree(equiv_cpu_table);
diff -r 98fe9e75d24b xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Mon Oct 26 13:36:51 2009 +0000
+++ b/xen/include/asm-x86/microcode.h	Wed Jan 04 14:13:58 2012 +0100
@@ -69,8 +69,8 @@ struct microcode_header_amd {
 } __attribute__((packed));
 
 struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
+    void *mpb;
+    size_t mpb_size;
 };
 
 struct cpu_signature {

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

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

--------------090403060106070807060106--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:33:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSq7-0005TO-1E; Wed, 04 Jan 2012 15:33:19 +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 1RiSq5-0005Sw-KL
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:33:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325691189!9610239!1
X-Originating-IP: [216.32.180.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1258 invoked from network); 4 Jan 2012 15:33:10 -0000
Received: from va3ehsobe001.messaging.microsoft.com (HELO
	VA3EHSOBE008.bigfish.com) (216.32.180.11)
	by server-5.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 15:33:10 -0000
Received: from mail84-va3-R.bigfish.com (10.7.14.251) by
	VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 15:33:09 +0000
Received: from mail84-va3 (localhost [127.0.0.1])	by mail84-va3-R.bigfish.com
	(Postfix) with ESMTP id 64F1618019A	for
	<xen-devel@lists.xensource.com>; Wed, 4 Jan 2012 15:33:09 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3
	(MessageSwitch) id 132569118873994_678;
	Wed,  4 Jan 2012 15:33:08 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.247])	by
	mail84-va3.bigfish.com (Postfix) with ESMTP id 01F2528004E	for
	<xen-devel@lists.xensource.com>; Wed,  4 Jan 2012 15:33:08 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server id
	14.1.225.22; Wed, 4 Jan 2012 15:33:07 +0000
X-WSS-ID: 0LXA5V4-01-BKF-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 2C1F71028020	for <xen-devel@lists.xensource.com>;
	Wed,  4 Jan 2012 09:33:03 -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, 4 Jan 2012 09:33:15 -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, 4 Jan 2012 09:32:48 -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, 4 Jan 2012
	10:32:47 -0500
Message-ID: <4F04711E.2010807@amd.com>
Date: Wed, 4 Jan 2012 16:32:46 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------090403060106070807060106"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Xen 3.3: x86/ucode: fix for AMD Fam15 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------090403060106070807060106
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


86/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>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 3.3


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

--------------090403060106070807060106
Content-Type: text/plain; name="xen33_ucode.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen33_ucode.diff"
Content-Description: xen33_ucode.diff

diff -r 98fe9e75d24b xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Mon Oct 26 13:36:51 2009 +0000
+++ b/xen/arch/x86/microcode_amd.c	Wed Jan 04 14:13:58 2012 +0100
@@ -33,11 +33,11 @@
 #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))
+struct mpbhdr {
+    uint32_t type;
+    uint32_t len;
+    uint8_t data[];
+};
 
 /* serialize access to the physical write */
 static DEFINE_SPINLOCK(microcode_update_lock);
@@ -66,10 +66,10 @@ static int collect_cpu_info(int cpu, str
     return 0;
 }
 
-static int microcode_fits(void *mc, int cpu)
+static int microcode_fits(const struct microcode_amd *mc_amd, int cpu)
 {
     struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
-    struct microcode_header_amd *mc_header = mc;
+    struct microcode_header_amd *mc_header = mc_amd->mpb;
     unsigned int current_cpu_id;
     unsigned int equiv_cpu_id = 0x0;
     unsigned int i;
@@ -98,9 +98,9 @@ static int microcode_fits(void *mc, int 
 
     if ( !equiv_cpu_id )
     {
-        printk(KERN_ERR "microcode: CPU%d cpu_id "
+        printk(KERN_INFO "microcode: CPU%d cpu_id "
                "not found in equivalent cpu table\n", cpu);
-        return -EINVAL;
+        return 0;
     }
 
     if ( (mc_header->processor_rev_id) != equiv_cpu_id )
@@ -112,14 +112,14 @@ static int microcode_fits(void *mc, int 
     }
 
     if ( mc_header->patch_id <= uci->cpu_sig.rev )
-        return -EINVAL;
+        return 0;
 
     printk(KERN_INFO "microcode: CPU%d found a matching microcode "
            "update with version 0x%x (current=0x%x)\n",
            cpu, mc_header->patch_id, uci->cpu_sig.rev);
 
 out:
-    return 0;
+    return 1;
 }
 
 static int apply_microcode(struct ucode_cpu_info *uci, int cpu)
@@ -127,16 +127,21 @@ static int apply_microcode(struct ucode_
     unsigned long flags;
     uint32_t rev, dummy;
     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);
 
     if ( mc_amd == NULL )
-        return -EINVAL;
+       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 */
     rdmsr(MSR_AMD_PATCHLEVEL, rev, dummy);
@@ -144,61 +149,67 @@ static int apply_microcode(struct ucode_
     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("microcode: CPU%d updated from revision "
            "0x%x to 0x%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)
 {
-    struct microcode_header_amd *mc_header;
-    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;
     }
 
-    mc_header = (struct microcode_header_amd *)(&bufp[off+8]);
+    printk(KERN_INFO "microcode: size %lu, total_size %u, offset %ld\n",
+           bufsize, mpbuf->len, off);
 
-    total_size = (unsigned long) (bufp[off+4] + (bufp[off+5] << 8));
-
-    printk(KERN_INFO "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;
 }
@@ -253,7 +264,7 @@ static int cpu_request_microcode(struct 
     unsigned long offset = 0;
     int error = 0;
     int ret;
-    void *mc;
+    struct microcode_amd *mc_amd, *mc_old;
 
     /* We should bind the task to the CPU */
     BUG_ON(cpu != raw_smp_processor_id());
@@ -275,8 +286,8 @@ static int cpu_request_microcode(struct 
         return -EINVAL;
     }
 
-    mc = xmalloc_bytes(UCODE_MAX_SIZE);
-    if ( mc == NULL )
+    mc_amd = xmalloc(struct microcode_amd);
+    if ( mc_amd == NULL )
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
@@ -284,32 +295,37 @@ static int cpu_request_microcode(struct 
         goto out;
     }
 
+    mc_old = uci->mc.mc_amd;
     /* implicitely validates uci->mc.mc_valid */
-    uci->mc.mc_amd = mc;
+    uci->mc.mc_amd = mc_amd;
 
     /*
      * 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)
+    mc_amd->mpb = NULL;
+    mc_amd->mpb_size = 0;
+    while ( (ret = get_next_ucode_from_buffer_amd(mc_amd, buf, size,
+                                                  &offset)) == 0)
     {
-        error = microcode_fits(mc, cpu);
-        if (error != 0)
+        error = microcode_fits(mc_amd, cpu);
+        if (error <= 0)
             continue;
 
         error = apply_microcode(uci, cpu);
-        if (error == 0)
+        if (error == 0) {
+            error = 1;
             break;
+        }
     }
 
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error) {
-        xfree(mc);
-        mc = NULL;
+    if (error == 1) {
+        xfree(mc_old);
+        return 0;
     }
-    uci->mc.mc_amd = mc;
 
 out:
     xfree(equiv_cpu_table);
diff -r 98fe9e75d24b xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Mon Oct 26 13:36:51 2009 +0000
+++ b/xen/include/asm-x86/microcode.h	Wed Jan 04 14:13:58 2012 +0100
@@ -69,8 +69,8 @@ struct microcode_header_amd {
 } __attribute__((packed));
 
 struct microcode_amd {
-    struct microcode_header_amd hdr;
-    unsigned int mpb[0];
+    void *mpb;
+    size_t mpb_size;
 };
 
 struct cpu_signature {

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

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

--------------090403060106070807060106--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:43:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSzO-0005lE-A5; Wed, 04 Jan 2012 15:42:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <torushikeshj@gmail.com>)
	id 1RiSzL-0005kY-He; Wed, 04 Jan 2012 15:42:52 +0000
X-Env-Sender: torushikeshj@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325691762!2857806!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 16275 invoked from network); 4 Jan 2012 15:42:43 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 15:42:43 -0000
Received: by eekd4 with SMTP id d4so102576163eek.30
	for <multiple recipients>; Wed, 04 Jan 2012 07:42:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ihzQdCAF9dD3Ct+ltTHByCmPKDkIjjicgxNRsU0ALU8=;
	b=n0BbpI4eIumSMrXBkAJBbWIzdE0vPKU75+6l3TR4XZ4Tx6z1mI4lF3ex728eEPIZ88
	AsbwePW7iOjMuj/xkB+FBSWWjJO5a/u4gNbUS+P2pdbYCWRQYnDBjzCmpoenx4qH1aVv
	RFq9WSfrBJ/tKAlKuwFCrg2ktmRXC5M26lZSs=
MIME-Version: 1.0
Received: by 10.14.37.79 with SMTP id x55mr23502393eea.34.1325691762728; Wed,
	04 Jan 2012 07:42:42 -0800 (PST)
Received: by 10.14.130.145 with HTTP; Wed, 4 Jan 2012 07:42:42 -0800 (PST)
In-Reply-To: <20120103175243.GE749@andromeda.dapyr.net>
References: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
	<20120103175243.GE749@andromeda.dapyr.net>
Date: Wed, 4 Jan 2012 21:12:42 +0530
Message-ID: <CAO14VsPre0ScNOfDNSxMKCPvVKRWCOkTVHL_SbF8KZkacSDDAQ@mail.gmail.com>
From: R J <torushikeshj@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
	xen-api@lists.xensource.com
Subject: Re: [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>
Content-Type: multipart/mixed; boundary="===============7184661725521072918=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7184661725521072918==
Content-Type: multipart/alternative; boundary=90e6ba5bb8db995ea304b5b5aa9d

--90e6ba5bb8db995ea304b5b5aa9d
Content-Type: text/plain; charset=ISO-8859-1

Hello Konrad.

Thanks for your email. I have added my responses below.



On Tue, Jan 3, 2012 at 11:22 PM, Konrad Rzeszutek Wilk <konrad@darnok.org>wrote:

> On Thu, Dec 29, 2011 at 11:28:59PM +0530, R J wrote:
> > 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.
>
>
> Node? Meaning dom0? Or the guest? Are you using dom0_mem=max:X argument?
>

Node means the physical machine. I was not sure to call it as dom0.
dom0 in this case has default 750 MB RAM.


> > I have attached the HVM boot log of successful start. Many times the node
> > hangs as soon as the BalloonWorkerThread is activated.
>
> Which PV driver is this? Is this with the other ones: GPL one, Citrix,
> Novell, and
> Oracle as well?
>

This is Citrix PV driver. XCP 1.1 and PV drivers are 1.1 version.


> >
> > 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
>
> > Dec 29 23:08:01 n4 xenguest: Determined the following parameters from
> xenstore:
> > Dec 29 23:08:01 n4 xenguest: vcpu/number:16 vcpu/weight:0 vcpu/cap:0 nx:
> 1 viridian: 1 apic: 1 acpi: 1 pae: 1 acpi_s4: 0 acpi_s3: 0
> > Dec 29 23:08:01 n4 xenguest: vcpu/0/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/1/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/2/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/3/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/4/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/5/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/6/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/7/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/8/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/9/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/10/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/11/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/12/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/13/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/14/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/15/affinity:0
> > Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-control: init, 10 x 4k buffers
> > Dec 29 23:08:14 n4 tapdisk[18204]: I/O queue driver: lio
> > Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-log: started, level 0
> > Dec 29 23:08:14 n4 tapdisk[18204]: received 'attach' message (uuid = 0)
> > Dec 29 23:08:14 n4 tapdisk[18204]: sending 'attach response' message
> (uuid = 0)
> > Dec 29 23:08:14 n4 tapdisk[18204]: received 'open' message (uuid = 0)
> > Dec 29 23:08:14 n4 tapdisk[18204]: Loading driver 'vhd' for vbd 0
> /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297
> 0x00000000
> > Dec 29 23:08:14 n4 tapdisk[18204]:
> /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297
> version: tap 0x00010003, b: 15360, a: 307, f: 26, n: 1268376
> > Dec 29 23:08:14 n4 tapdisk[18204]: opened image
> /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297
> (1 users, state: 0x00000001, type: 4)
> > Dec 29 23:08:14 n4 tapdisk[18204]:
> /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b
> version: tap 0x00010003, b: 15360, a: 3331, f: 3307, n: 0
> > Dec 29 23:08:14 n4 tapdisk[18204]: opened image
> /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b
> (1 users, state: 0x00000003, type: 4)
> > Dec 29 23:08:14 n4 tapdisk[18204]: VBD CHAIN:
> > Dec 29 23:08:14 n4 tapdisk[18204]:
> /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297:
> type:vhd(4) storage:lvm(3)
> > Dec 29 23:08:14 n4 tapdisk[18204]:
> /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b:
> type:vhd(4) storage:lvm(3)
> > Dec 29 23:08:14 n4 tapdisk[18204]: sending 'open response' message (uuid
> = 0)
> > Dec 29 23:08:14 n4 vbd.uevent[add](backend/vbd/18/768): wrote
> /xapi/18/hotplug/vbd/768/hotplug = 'online'
> > Dec 29 23:08:15 n4 vbd.uevent[add](backend/vbd/18/5696): wrote
> /xapi/18/hotplug/vbd/5696/hotplug = 'online'
> > Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as
> /usr/bin/ovs-vsctl list-ports xapi9
> > Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as
> /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port vif18.0 -- add-port
> xapi9 vif18.0 -- set interface vif18.0
> "external-ids:\"xs-vm-uuid\"=\"6591a403-0eba-30b4-96a6-e02a7db0607a\"" --
> set interface vif18.0
> "external-ids:\"xs-vif-uuid\"=\"3be54e6d-6d13-b04b-6735-24831e5169e5\"" --
> set interface vif18.0
> "external-ids:\"xs-network-uuid\"=\"7051ef99-4fcb-fa61-a10e-f98456e12e90\""
> -- set interface vif18.0
> "external-ids:\"attached-mac\"=\"d6:6d:60:7e:45:52\""
> > Dec 29 23:08:15 n4 qemu.18: domid: 18
> > Dec 29 23:08:15 n4 qemu.18: qemu: the number of cpus is 16
> > Dec 29 23:08:15 n4 qemu.18: -videoram option does not work with cirrus
> vga device model. Videoram set to 4M.
> > Dec 29 23:08:15 n4 HVM18[18302]: Guest uuid =
> 6591a403-0eba-30b4-96a6-e02a7db0607a
> > Dec 29 23:08:15 n4 HVM18[18302]: Watching
> /local/domain/18/logdirty/next-active
> > Dec 29 23:08:15 n4 HVM18[18302]: Watching
> /local/domain/0/device-model/18/command
> > Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/2
> > Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/3
> > Dec 29 23:08:15 n4 HVM18[18302]: qemu_map_cache_init nr_buckets = 4000
> size 327680
> > Dec 29 23:08:15 n4 HVM18[18302]: shared page at pfn feffd
> > Dec 29 23:08:15 n4 HVM18[18302]: buffered io page at pfn feffb
> > Dec 29 23:08:15 n4 HVM18[18302]: Time offset set 0
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:00:00 (i440FX)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:00 (PIIX3)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:02:00 (Cirrus
> VGA)
> > Dec 29 23:08:15 n4 HVM18[18302]: populating video RAM at ff000000
> > Dec 29 23:08:15 n4 HVM18[18302]: mapping video RAM from ff000000
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:03:00
> (xen-platform)
> > Dec 29 23:08:15 n4 HVM18[18302]:
> xs_read(/vm/6591a403-0eba-30b4-96a6-e02a7db0607a/log-throttling): read error
> > Dec 29 23:08:15 n4 HVM18[18302]: ROM memory area now RW
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:04:00 (RTL8139)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:01 (PIIX3
> IDE)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:02 (USB-UHCI)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:03 (PIIX4
> ACPI)
> > Dec 29 23:08:15 n4 HVM18[18302]:
> xs_read(/local/domain/0/device-model/18/xen_extended_power_mgmt): read error
> > Dec 29 23:08:15 n4 HVM18[18302]: releasing VM
> > Dec 29 23:08:15 n4 HVM18[18302]: xs_read(): vncpasswd get error.
> /vm/6591a403-0eba-30b4-96a6-e02a7db0607a/vncpasswd.
> > Dec 29 23:08:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port:
> 0, data: 0, count: 0, size: 0
> > Dec 29 17:38:15 n4 last message repeated 2 times
> > Dec 29 17:38:15 n4 HVM18[18302]: Triggered log-dirty buffer switch
> > Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port:
> 0, data: 0, count: 0, size: 0
> > Dec 29 17:38:15 n4 HVM18[18302]: medium change watch on `hdd' (index: 1):
> > Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port:
> 0, data: 0, count: 0, size: 0
> > Dec 29 17:38:15 n4 last message repeated 11 times
> > Dec 29 17:38:16 n4 HVM18[18302]: cirrus vga map change while on lfb mode
> > Dec 29 23:08:16 n4 ovs-vsctl: 00001|vsctl|INFO|Called as
> /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port tap18.0 -- add-port
> xapi9 tap18.0
> > Dec 29 17:38:16 n4 HVM18[18302]: mapping vram to f0000000 - f0400000
> > Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RW
> > Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RO
> > Dec 29 17:38:18 n4 HVM18[18302]: cirrus: blanking the screen
> line_offset=3072 height=768
> > Dec 29 17:38:34 n4 HVM18[18302]: cirrus: blanking the screen
> line_offset=1024 height=768
> > Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol version set to 1
> (drivers not blacklisted)
> > Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol 1 active
> > Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: product_id: 1 build_number:
> 30876
> > Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: drivers not blacklisted
> > Dec 29 17:38:37 n4 HVM18[18302]: ide_unplug_harddisk: drive 0
> > Dec 29 17:38:37 n4 HVM18[18302]: pci_dev_unplug: 00:04:00
> > Dec 29 17:38:37 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0
> > Dec 29 23:08:38 n4 ovs-vsctl: 00001|vsctl|INFO|Called as
> /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port tap18.0
> > Dec 29 17:38:38 n4 HVM18[18302]:  XEVTCHN: InstallDumpDeviceCallback:
> version mismatch (255 != 1)
> > Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: XenevtchnAddDevice: FDO =
> 0xFFFFFA8044323970
> > Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: Initialized tracing provider
> > Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: StartDeviceFdo: ====>
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: XEVTCHN: IO hole:
> [00000000fbfa6000,00000000fc000000) mapped at FFFFF88002965000
> > Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: KERNEL: 6.1 (build 7600)
> platform WIN32_NT
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: SP: NONE
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: SUITES:
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - TERMINAL
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - DATACENTER
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - SINGLEUSERTS
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: TYPE: SERVER
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: PV DRIVERS: VERSION: 5.6.0
> BUILD: 30876 (Apr 30 2010.06:57:01)
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: 64-bit HVM
> > Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: ExpandGrantTable: GRANT
> TABLE 0: (0 - 511) at FFFFF88002966000 (fbfa7000)
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: XenEnterprise product string
> is present
> > Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: PHYSICAL MEMORY: TOP =
> 00000016.8fc00000
> > Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: BalloonTargetChanged:
> 94371840k -> 43792384k
> > Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> activating
> > Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2230ms
> > Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 7924ms (2064k/s)
> > Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94355480k)
> > Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 1794ms
> > Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 9157ms (1786k/s)
> > Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94339120k)
> > Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5070ms
> > Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 14601ms (1120k/s)
> > Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94322760k)
> > Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 4321ms
> > Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 16052ms (1019k/s)
> > Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94306400k)
> > Dec 29 17:39:40 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep:
> HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)
> > Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 6099ms
> > Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 15132ms (1081k/s)
> > Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94290040k)
> > Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 4492ms
> > Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 17206ms (950k/s)
> > Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94273680k)
> > Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2043ms
> > Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 11294ms (1448k/s)
> > Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94257320k)
> > Dec 29 17:40:27 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep:
> HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)
> > Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5179ms
> > Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 15100ms (1083k/s)
> > Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94240960k)
> > Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2230ms
> > Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 12870ms (1271k/s)
> > Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94224600k)
> > Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5350ms
> > Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 13228ms (1236k/s)
> > Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94208240k)
> > Dec 29 17:41:14 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep:
> HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)
> > Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 3026ms
> > Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 15490ms (1056k/s)
> > Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94191880k)
> > Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 3151ms
> > Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 13291ms (1230k/s)
> > Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94175520k)
> > Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5553ms
> > Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 16832ms (971k/s)
> > Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94159160k)
> > Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 6754ms
> > Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 18111ms (903k/s)
> > Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94142800k)
> > Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 3244ms
> > Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 18392ms (889k/s)
> > Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94126440k)
> > Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5725ms
> > Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 18454ms (886k/s)
> > Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94110080k)
> > Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 4243ms
> > Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 19453ms (841k/s)
> > Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94093720k)
> > Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5241ms
> > Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 17206ms (950k/s)
> > Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94077360k)
> > Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 1996ms
> > Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 17253ms (948k/s)
> > Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94061000k)
> > Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 4773ms
> > Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 16286ms (1004k/s)
> > Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94044640k)
> > Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2152ms
> > Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 21231ms (770k/s)
> > Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94028280k)
> > Dec 29 17:44:40 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep:
> HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)
> > Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2199ms
> > Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 17331ms (943k/s)
> > Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94011920k)
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 12554884 page(s) in 32604ms (91243k/s)
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> de-activating
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: XenevtchnMapResources
> setting callback irq to 11
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: PV init. done
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonTargetChanged:
> 43792384k -> 48911360k
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> activating
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: Detected new device vif/0.
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: closing device/vif/0...
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: device/vif/0 closed
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: StartDeviceFdo: <====
> (00000000)
> > Dec 29 17:45:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> deflated balloon by 1279744 page(s) in 998ms (825660k/s)
> > Dec 29 17:45:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> de-activating
> > Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: XENVBD in NORMAL mode.
> > Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: XenvbdAddDevice: FDO =
> 0xFFFFFA804434B060
> > Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: IO hole already
> initialized by XEVTCHN
> > Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: Bugcheck callback
> already installed
> > Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: Bugcheck reason
> callback already installed
> > Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: RescanThread: starting
> > Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: XenvbdHwInitialize setting
> callback irq to 30
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: DeviceRelationsFdo: scanning
> targets...
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: XenbusFindVbds: found new
> disk (VBD 768)
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: XenbusFindVbds: ignoring
> cdrom (VBD 5696)
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: claiming
> frontend...
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: successfuly
> claimed device/vbd/768
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: synthesising
> inquiry data: default page
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: unit serial number
> = '62c5a501-d662-4d  '
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: device
> identifier[0]: CodeSet: 'Ascii' Type: 'VendorId' Assocation: 'Device'
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: device
> identifier[0]: Length = 45 Data = 'XENSRC
>  62c5a501-d662-4d38-a75c-a280e2929297 '
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: closing frontend...
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: backend is closed
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: created
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>

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

Hello Konrad.<br><br>Thanks for your email. I have added my responses below=
.<br><br><br><br><div class=3D"gmail_quote">On Tue, Jan 3, 2012 at 11:22 PM=
, Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@darn=
ok.org">konrad@darnok.org</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 Thu,=
 Dec 29, 2011 at 11:28:59PM +0530, R J wrote:<br>
&gt; Hello List,<br>
&gt;<br>
&gt; Merry Christmas to all !!<br>
&gt;<br>
&gt; Basically I&#39;m trying to boot a Windows 2008R2 DC HVM with 90GB sta=
tic max<br>
&gt; memory and 32GB static min.<br>
&gt;<br>
&gt; The node config is Dell M610 with X5660 and 96GB RAM and its running X=
CP 1.1<br>
&gt;<br>
&gt; Many times the node crashes while booting HVM. Sometimes I get success=
.<br>
<br>
<br>
</div>Node? Meaning dom0? Or the guest? Are you using dom0_mem=3Dmax:X argu=
ment?<br></blockquote><div><br>Node means the physical machine. I was not s=
ure to call it as dom0.<br>dom0 in this case has default 750 MB RAM.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
&gt; I have attached the HVM boot log of successful start. Many times the n=
ode<br>
&gt; hangs as soon as the BalloonWorkerThread is activated.<br>
<br>
</div>Which PV driver is this? Is this with the other ones: GPL one, Citrix=
, Novell, and<br>
Oracle as well?<br></blockquote><div>=A0</div><div>This is Citrix PV driver=
. XCP 1.1 and PV drivers are 1.1 version.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">

<div class=3D"im"><br>
&gt;<br>
&gt; In attached txt the ballon inflation rate is constant 4090<br>
</div>&gt; *XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) =
in 7924ms<br>
&gt; (2064k/s) =A0*<br>
<div class=3D"im">&gt;<br>
&gt; till the time it starts, the inflation rate shoots to 12554884 and the=
 VM<br>
&gt; is live.<br>
</div>&gt; *XENUTIL: BalloonWorkerThread: inflated balloon by 12554884 page=
(s) in<br>
&gt; 32604ms (91243k/s) *<br>
&gt; *XENUTIL: BalloonWorkerThread: de-activating *<br>
&gt; *XENUTIL: XenevtchnMapResources setting callback irq to 11 *<br>
&gt;<br>
&gt;<br>
&gt; Can some one help me understand the *BalloonWorkerThread *behavior ?*<=
br>
&gt;<br>
&gt;<br>
&gt; *Many thanks,<br>
&gt; Rushi<br>
<br>
&gt; Dec 29 23:08:01 n4 xenguest: Determined the following parameters from =
xenstore:<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/number:16 vcpu/weight:0 vcpu/cap:0 n=
x: 1 viridian: 1 apic: 1 acpi: 1 pae: 1 acpi_s4: 0 acpi_s3: 0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/0/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/1/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/2/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/3/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/4/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/5/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/6/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/7/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/8/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/9/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/10/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/11/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/12/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/13/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/14/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/15/affinity:0<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-control: init, 10 x 4k buff=
ers<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: I/O queue driver: lio<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-log: started, level 0<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: received &#39;attach&#39; message (=
uuid =3D 0)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: sending &#39;attach response&#39; m=
essage (uuid =3D 0)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: received &#39;open&#39; message (uu=
id =3D 0)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: Loading driver &#39;vhd&#39; for vb=
d 0 /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d6=
62-4d38-a75c-a280e2929297 0x00000000<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: /dev/VG_XenStorage-49740841-8056-06=
e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 version: tap =
0x00010003, b: 15360, a: 307, f: 26, n: 1268376<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: opened image /dev/VG_XenStorage-497=
40841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 =
(1 users, state: 0x00000001, type: 4)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: /dev/mapper/VG_XenStorage--49740841=
--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa52934=
08b version: tap 0x00010003, b: 15360, a: 3331, f: 3307, n: 0<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: opened image /dev/mapper/VG_XenStor=
age--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a8=
50--3aaa5293408b (1 users, state: 0x00000003, type: 4)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: VBD CHAIN:<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: /dev/VG_XenStorage-49740841-8056-06=
e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297: type:vhd(4) =
storage:lvm(3)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: /dev/mapper/VG_XenStorage--49740841=
--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa52934=
08b: type:vhd(4) storage:lvm(3)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: sending &#39;open response&#39; mes=
sage (uuid =3D 0)<br>
&gt; Dec 29 23:08:14 n4 vbd.uevent[add](backend/vbd/18/768): wrote /xapi/18=
/hotplug/vbd/768/hotplug =3D &#39;online&#39;<br>
&gt; Dec 29 23:08:15 n4 vbd.uevent[add](backend/vbd/18/5696): wrote /xapi/1=
8/hotplug/vbd/5696/hotplug =3D &#39;online&#39;<br>
&gt; Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-=
vsctl list-ports xapi9<br>
&gt; Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-=
vsctl --timeout=3D30 -- --if-exists del-port vif18.0 -- add-port xapi9 vif1=
8.0 -- set interface vif18.0 &quot;external-ids:\&quot;xs-vm-uuid\&quot;=3D=
\&quot;6591a403-0eba-30b4-96a6-e02a7db0607a\&quot;&quot; -- set interface v=
if18.0 &quot;external-ids:\&quot;xs-vif-uuid\&quot;=3D\&quot;3be54e6d-6d13-=
b04b-6735-24831e5169e5\&quot;&quot; -- set interface vif18.0 &quot;external=
-ids:\&quot;xs-network-uuid\&quot;=3D\&quot;7051ef99-4fcb-fa61-a10e-f98456e=
12e90\&quot;&quot; -- set interface vif18.0 &quot;external-ids:\&quot;attac=
hed-mac\&quot;=3D\&quot;d6:6d:60:7e:45:52\&quot;&quot;<br>

&gt; Dec 29 23:08:15 n4 qemu.18: domid: 18<br>
&gt; Dec 29 23:08:15 n4 qemu.18: qemu: the number of cpus is 16<br>
&gt; Dec 29 23:08:15 n4 qemu.18: -videoram option does not work with cirrus=
 vga device model. Videoram set to 4M.<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: Guest uuid =3D 6591a403-0eba-30b4-96a=
6-e02a7db0607a<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: Watching /local/domain/18/logdirty/ne=
xt-active<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: Watching /local/domain/0/device-model=
/18/command<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/2<=
br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/3<=
br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: qemu_map_cache_init nr_buckets =3D 40=
00 size 327680<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: shared page at pfn feffd<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: buffered io page at pfn feffb<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: Time offset set 0<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:00:00 (i440FX=
)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:00 (PIIX3)=
<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:02:00 (Cirrus=
 VGA)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: populating video RAM at ff000000<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: mapping video RAM from ff000000<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:03:00 (xen-pl=
atform)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: xs_read(/vm/6591a403-0eba-30b4-96a6-e=
02a7db0607a/log-throttling): read error<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: ROM memory area now RW<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:04:00 (RTL813=
9)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:01 (PIIX3 =
IDE)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:02 (USB-UH=
CI)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:03 (PIIX4 =
ACPI)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: xs_read(/local/domain/0/device-model/=
18/xen_extended_power_mgmt): read error<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: releasing VM<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: xs_read(): vncpasswd get error. /vm/6=
591a403-0eba-30b4-96a6-e02a7db0607a/vncpasswd.<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, por=
t: 0, data: 0, count: 0, size: 0<br>
&gt; Dec 29 17:38:15 n4 last message repeated 2 times<br>
&gt; Dec 29 17:38:15 n4 HVM18[18302]: Triggered log-dirty buffer switch<br>
&gt; Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, por=
t: 0, data: 0, count: 0, size: 0<br>
&gt; Dec 29 17:38:15 n4 HVM18[18302]: medium change watch on `hdd&#39; (ind=
ex: 1):<br>
&gt; Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, por=
t: 0, data: 0, count: 0, size: 0<br>
&gt; Dec 29 17:38:15 n4 last message repeated 11 times<br>
&gt; Dec 29 17:38:16 n4 HVM18[18302]: cirrus vga map change while on lfb mo=
de<br>
&gt; Dec 29 23:08:16 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-=
vsctl --timeout=3D30 -- --if-exists del-port tap18.0 -- add-port xapi9 tap1=
8.0<br>
&gt; Dec 29 17:38:16 n4 HVM18[18302]: mapping vram to f0000000 - f0400000<b=
r>
&gt; Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RW<br>
&gt; Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RO<br>
&gt; Dec 29 17:38:18 n4 HVM18[18302]: cirrus: blanking the screen line_offs=
et=3D3072 height=3D768<br>
&gt; Dec 29 17:38:34 n4 HVM18[18302]: cirrus: blanking the screen line_offs=
et=3D1024 height=3D768<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol version set to 1 (dr=
ivers not blacklisted)<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol 1 active<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: product_id: 1 build_number: 3=
0876<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: drivers not blacklisted<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: ide_unplug_harddisk: drive 0<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: pci_dev_unplug: 00:04:00<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: net_tap_shutdown: model=3Dtap,name=3D=
tap.0<br>
&gt; Dec 29 23:08:38 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-=
vsctl --timeout=3D30 -- --if-exists del-port tap18.0<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0XEVTCHN: InstallDumpDeviceCallback=
: version mismatch (255 !=3D 1)<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XEVTCHN: XenevtchnAddDevice: FDO =
=3D 0xFFFFFA8044323970<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XEVTCHN: Initialized tracing prov=
ider<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XEVTCHN: StartDeviceFdo: =3D=3D=
=3D=3D&gt;<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: XEVTCHN: IO hole: [00000=
000fbfa6000,00000000fc000000) mapped at FFFFF88002965000<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=3Dtap,name=3D=
tap.0<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: KERNEL: 6.1 (build 7600)=
 platform WIN32_NT<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: SP: NONE<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: SUITES:<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: - TERMINAL<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: - DATACENTER<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: - SINGLEUSERTS<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: TYPE: SERVER<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: PV DRIVERS: VERSION: 5.6=
.0 BUILD: 30876 (Apr 30 2010.06:57:01)<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: 64-bit HVM<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=3Dtap,name=3D=
tap.0<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: ExpandGrantTable: GRANT =
TABLE 0: (0 - 511) at FFFFF88002966000 (fbfa7000)<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: XenEnterprise product st=
ring is present<br>
&gt; Dec 29 17:38:39 n4 HVM18[18302]: =A0 XENUTIL: PHYSICAL MEMORY: TOP =3D=
 00000016.8fc00000<br>
&gt; Dec 29 17:38:39 n4 HVM18[18302]: =A0 XENUTIL: BalloonTargetChanged: 94=
371840k -&gt; 43792384k<br>
&gt; Dec 29 17:38:39 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: act=
ivating<br>
&gt; Dec 29 17:38:47 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2230ms<br>
&gt; Dec 29 17:38:47 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 7924ms (2064k/s)<br>
&gt; Dec 29 17:38:47 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94355480k)<br>
&gt; Dec 29 17:38:57 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 1794ms<br>
&gt; Dec 29 17:38:57 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 9157ms (1786k/s)<br>
&gt; Dec 29 17:38:57 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94339120k)<br>
&gt; Dec 29 17:39:13 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5070ms<br>
&gt; Dec 29 17:39:13 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 14601ms (1120k/s)<br>
&gt; Dec 29 17:39:13 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94322760k)<br>
&gt; Dec 29 17:39:30 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 4321ms<br>
&gt; Dec 29 17:39:30 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 16052ms (1019k/s)<br>
&gt; Dec 29 17:39:30 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94306400k)<br>
&gt; Dec 29 17:39:40 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonPodSweep=
: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)<br>
&gt; Dec 29 17:39:46 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 6099ms<br>
&gt; Dec 29 17:39:46 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 15132ms (1081k/s)<br>
&gt; Dec 29 17:39:46 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94290040k)<br>
&gt; Dec 29 17:40:04 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 4492ms<br>
&gt; Dec 29 17:40:04 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 17206ms (950k/s)<br>
&gt; Dec 29 17:40:04 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94273680k)<br>
&gt; Dec 29 17:40:16 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2043ms<br>
&gt; Dec 29 17:40:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 11294ms (1448k/s)<br>
&gt; Dec 29 17:40:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94257320k)<br>
&gt; Dec 29 17:40:27 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonPodSweep=
: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)<br>
&gt; Dec 29 17:40:32 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5179ms<br>
&gt; Dec 29 17:40:32 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 15100ms (1083k/s)<br>
&gt; Dec 29 17:40:32 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94240960k)<br>
&gt; Dec 29 17:40:46 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2230ms<br>
&gt; Dec 29 17:40:46 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 12870ms (1271k/s)<br>
&gt; Dec 29 17:40:46 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94224600k)<br>
&gt; Dec 29 17:41:01 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5350ms<br>
&gt; Dec 29 17:41:01 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 13228ms (1236k/s)<br>
&gt; Dec 29 17:41:01 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94208240k)<br>
&gt; Dec 29 17:41:14 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonPodSweep=
: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)<br>
&gt; Dec 29 17:41:17 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 3026ms<br>
&gt; Dec 29 17:41:17 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 15490ms (1056k/s)<br>
&gt; Dec 29 17:41:17 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94191880k)<br>
&gt; Dec 29 17:41:31 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 3151ms<br>
&gt; Dec 29 17:41:31 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 13291ms (1230k/s)<br>
&gt; Dec 29 17:41:31 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94175520k)<br>
&gt; Dec 29 17:41:49 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5553ms<br>
&gt; Dec 29 17:41:49 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 16832ms (971k/s)<br>
&gt; Dec 29 17:41:49 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94159160k)<br>
&gt; Dec 29 17:42:08 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 6754ms<br>
&gt; Dec 29 17:42:08 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 18111ms (903k/s)<br>
&gt; Dec 29 17:42:08 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94142800k)<br>
&gt; Dec 29 17:42:28 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 3244ms<br>
&gt; Dec 29 17:42:28 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 18392ms (889k/s)<br>
&gt; Dec 29 17:42:28 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94126440k)<br>
&gt; Dec 29 17:42:47 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5725ms<br>
&gt; Dec 29 17:42:47 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 18454ms (886k/s)<br>
&gt; Dec 29 17:42:47 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94110080k)<br>
&gt; Dec 29 17:43:08 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 4243ms<br>
&gt; Dec 29 17:43:08 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 19453ms (841k/s)<br>
&gt; Dec 29 17:43:08 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94093720k)<br>
&gt; Dec 29 17:43:26 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5241ms<br>
&gt; Dec 29 17:43:26 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 17206ms (950k/s)<br>
&gt; Dec 29 17:43:26 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94077360k)<br>
&gt; Dec 29 17:43:44 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 1996ms<br>
&gt; Dec 29 17:43:44 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 17253ms (948k/s)<br>
&gt; Dec 29 17:43:44 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94061000k)<br>
&gt; Dec 29 17:44:02 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 4773ms<br>
&gt; Dec 29 17:44:02 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 16286ms (1004k/s)<br>
&gt; Dec 29 17:44:02 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94044640k)<br>
&gt; Dec 29 17:44:24 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2152ms<br>
&gt; Dec 29 17:44:24 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 21231ms (770k/s)<br>
&gt; Dec 29 17:44:24 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94028280k)<br>
&gt; Dec 29 17:44:40 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonPodSweep=
: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)<br>
&gt; Dec 29 17:44:42 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2199ms<br>
&gt; Dec 29 17:44:42 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 17331ms (943k/s)<br>
&gt; Dec 29 17:44:42 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94011920k)<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 12554884 page(s) in 32604ms (91243k/s)<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: de-=
activating<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: XenevtchnMapResources se=
tting callback irq to 11<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: PV init. done<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonTargetChanged: 43=
792384k -&gt; 48911360k<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: act=
ivating<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: Detected new device vif/=
0.<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: closing device/vif/0...<=
br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: device/vif/0 closed<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: StartDeviceFdo: &lt;=3D=
=3D=3D=3D (00000000)<br>
&gt; Dec 29 17:45:17 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: def=
lated balloon by 1279744 page(s) in 998ms (825660k/s)<br>
&gt; Dec 29 17:45:17 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: de-=
activating<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 =A0XENVBD: XENVBD in NORMAL mode.=
<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 =A0XENVBD: XenvbdAddDevice: FDO =
=3D 0xFFFFFA804434B060<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 XENUTIL: WARNING: IO hole already=
 initialized by XEVTCHN<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 XENUTIL: WARNING: Bugcheck callba=
ck already installed<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 XENUTIL: WARNING: Bugcheck reason=
 callback already installed<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 =A0XENVBD: RescanThread: starting=
<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 XENUTIL: XenvbdHwInitialize setti=
ng callback irq to 30<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: DeviceRelationsFdo: sc=
anning targets...<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: XenbusFindVbds: found =
new disk (VBD 768)<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: XenbusFindVbds: ignori=
ng cdrom (VBD 5696)<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: claiming fro=
ntend...<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: successfuly =
claimed device/vbd/768<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: synthesising=
 inquiry data: default page<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: unit serial =
number =3D &#39;62c5a501-d662-4d =A0&#39;<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: device ident=
ifier[0]: CodeSet: &#39;Ascii&#39; Type: &#39;VendorId&#39; Assocation: &#3=
9;Device&#39;<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: device ident=
ifier[0]: Length =3D 45 Data =3D &#39;XENSRC =A062c5a501-d662-4d38-a75c-a28=
0e2929297 &#39;<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: closing fron=
tend...<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: backend is c=
losed<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: created<br>
<br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xenso=
urce.com</a><br>
&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">htt=
p://lists.xensource.com/xen-devel</a><br>
<br>
</blockquote></div><br>

--90e6ba5bb8db995ea304b5b5aa9d--


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

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

--===============7184661725521072918==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:43:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:43:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiSzO-0005lE-A5; Wed, 04 Jan 2012 15:42:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <torushikeshj@gmail.com>)
	id 1RiSzL-0005kY-He; Wed, 04 Jan 2012 15:42:52 +0000
X-Env-Sender: torushikeshj@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325691762!2857806!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 16275 invoked from network); 4 Jan 2012 15:42:43 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 15:42:43 -0000
Received: by eekd4 with SMTP id d4so102576163eek.30
	for <multiple recipients>; Wed, 04 Jan 2012 07:42:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ihzQdCAF9dD3Ct+ltTHByCmPKDkIjjicgxNRsU0ALU8=;
	b=n0BbpI4eIumSMrXBkAJBbWIzdE0vPKU75+6l3TR4XZ4Tx6z1mI4lF3ex728eEPIZ88
	AsbwePW7iOjMuj/xkB+FBSWWjJO5a/u4gNbUS+P2pdbYCWRQYnDBjzCmpoenx4qH1aVv
	RFq9WSfrBJ/tKAlKuwFCrg2ktmRXC5M26lZSs=
MIME-Version: 1.0
Received: by 10.14.37.79 with SMTP id x55mr23502393eea.34.1325691762728; Wed,
	04 Jan 2012 07:42:42 -0800 (PST)
Received: by 10.14.130.145 with HTTP; Wed, 4 Jan 2012 07:42:42 -0800 (PST)
In-Reply-To: <20120103175243.GE749@andromeda.dapyr.net>
References: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
	<20120103175243.GE749@andromeda.dapyr.net>
Date: Wed, 4 Jan 2012 21:12:42 +0530
Message-ID: <CAO14VsPre0ScNOfDNSxMKCPvVKRWCOkTVHL_SbF8KZkacSDDAQ@mail.gmail.com>
From: R J <torushikeshj@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
	xen-api@lists.xensource.com
Subject: Re: [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>
Content-Type: multipart/mixed; boundary="===============7184661725521072918=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7184661725521072918==
Content-Type: multipart/alternative; boundary=90e6ba5bb8db995ea304b5b5aa9d

--90e6ba5bb8db995ea304b5b5aa9d
Content-Type: text/plain; charset=ISO-8859-1

Hello Konrad.

Thanks for your email. I have added my responses below.



On Tue, Jan 3, 2012 at 11:22 PM, Konrad Rzeszutek Wilk <konrad@darnok.org>wrote:

> On Thu, Dec 29, 2011 at 11:28:59PM +0530, R J wrote:
> > 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.
>
>
> Node? Meaning dom0? Or the guest? Are you using dom0_mem=max:X argument?
>

Node means the physical machine. I was not sure to call it as dom0.
dom0 in this case has default 750 MB RAM.


> > I have attached the HVM boot log of successful start. Many times the node
> > hangs as soon as the BalloonWorkerThread is activated.
>
> Which PV driver is this? Is this with the other ones: GPL one, Citrix,
> Novell, and
> Oracle as well?
>

This is Citrix PV driver. XCP 1.1 and PV drivers are 1.1 version.


> >
> > 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
>
> > Dec 29 23:08:01 n4 xenguest: Determined the following parameters from
> xenstore:
> > Dec 29 23:08:01 n4 xenguest: vcpu/number:16 vcpu/weight:0 vcpu/cap:0 nx:
> 1 viridian: 1 apic: 1 acpi: 1 pae: 1 acpi_s4: 0 acpi_s3: 0
> > Dec 29 23:08:01 n4 xenguest: vcpu/0/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/1/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/2/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/3/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/4/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/5/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/6/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/7/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/8/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/9/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/10/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/11/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/12/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/13/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/14/affinity:0
> > Dec 29 23:08:01 n4 xenguest: vcpu/15/affinity:0
> > Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-control: init, 10 x 4k buffers
> > Dec 29 23:08:14 n4 tapdisk[18204]: I/O queue driver: lio
> > Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-log: started, level 0
> > Dec 29 23:08:14 n4 tapdisk[18204]: received 'attach' message (uuid = 0)
> > Dec 29 23:08:14 n4 tapdisk[18204]: sending 'attach response' message
> (uuid = 0)
> > Dec 29 23:08:14 n4 tapdisk[18204]: received 'open' message (uuid = 0)
> > Dec 29 23:08:14 n4 tapdisk[18204]: Loading driver 'vhd' for vbd 0
> /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297
> 0x00000000
> > Dec 29 23:08:14 n4 tapdisk[18204]:
> /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297
> version: tap 0x00010003, b: 15360, a: 307, f: 26, n: 1268376
> > Dec 29 23:08:14 n4 tapdisk[18204]: opened image
> /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297
> (1 users, state: 0x00000001, type: 4)
> > Dec 29 23:08:14 n4 tapdisk[18204]:
> /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b
> version: tap 0x00010003, b: 15360, a: 3331, f: 3307, n: 0
> > Dec 29 23:08:14 n4 tapdisk[18204]: opened image
> /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b
> (1 users, state: 0x00000003, type: 4)
> > Dec 29 23:08:14 n4 tapdisk[18204]: VBD CHAIN:
> > Dec 29 23:08:14 n4 tapdisk[18204]:
> /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297:
> type:vhd(4) storage:lvm(3)
> > Dec 29 23:08:14 n4 tapdisk[18204]:
> /dev/mapper/VG_XenStorage--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa5293408b:
> type:vhd(4) storage:lvm(3)
> > Dec 29 23:08:14 n4 tapdisk[18204]: sending 'open response' message (uuid
> = 0)
> > Dec 29 23:08:14 n4 vbd.uevent[add](backend/vbd/18/768): wrote
> /xapi/18/hotplug/vbd/768/hotplug = 'online'
> > Dec 29 23:08:15 n4 vbd.uevent[add](backend/vbd/18/5696): wrote
> /xapi/18/hotplug/vbd/5696/hotplug = 'online'
> > Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as
> /usr/bin/ovs-vsctl list-ports xapi9
> > Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as
> /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port vif18.0 -- add-port
> xapi9 vif18.0 -- set interface vif18.0
> "external-ids:\"xs-vm-uuid\"=\"6591a403-0eba-30b4-96a6-e02a7db0607a\"" --
> set interface vif18.0
> "external-ids:\"xs-vif-uuid\"=\"3be54e6d-6d13-b04b-6735-24831e5169e5\"" --
> set interface vif18.0
> "external-ids:\"xs-network-uuid\"=\"7051ef99-4fcb-fa61-a10e-f98456e12e90\""
> -- set interface vif18.0
> "external-ids:\"attached-mac\"=\"d6:6d:60:7e:45:52\""
> > Dec 29 23:08:15 n4 qemu.18: domid: 18
> > Dec 29 23:08:15 n4 qemu.18: qemu: the number of cpus is 16
> > Dec 29 23:08:15 n4 qemu.18: -videoram option does not work with cirrus
> vga device model. Videoram set to 4M.
> > Dec 29 23:08:15 n4 HVM18[18302]: Guest uuid =
> 6591a403-0eba-30b4-96a6-e02a7db0607a
> > Dec 29 23:08:15 n4 HVM18[18302]: Watching
> /local/domain/18/logdirty/next-active
> > Dec 29 23:08:15 n4 HVM18[18302]: Watching
> /local/domain/0/device-model/18/command
> > Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/2
> > Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/3
> > Dec 29 23:08:15 n4 HVM18[18302]: qemu_map_cache_init nr_buckets = 4000
> size 327680
> > Dec 29 23:08:15 n4 HVM18[18302]: shared page at pfn feffd
> > Dec 29 23:08:15 n4 HVM18[18302]: buffered io page at pfn feffb
> > Dec 29 23:08:15 n4 HVM18[18302]: Time offset set 0
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:00:00 (i440FX)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:00 (PIIX3)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:02:00 (Cirrus
> VGA)
> > Dec 29 23:08:15 n4 HVM18[18302]: populating video RAM at ff000000
> > Dec 29 23:08:15 n4 HVM18[18302]: mapping video RAM from ff000000
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:03:00
> (xen-platform)
> > Dec 29 23:08:15 n4 HVM18[18302]:
> xs_read(/vm/6591a403-0eba-30b4-96a6-e02a7db0607a/log-throttling): read error
> > Dec 29 23:08:15 n4 HVM18[18302]: ROM memory area now RW
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:04:00 (RTL8139)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:01 (PIIX3
> IDE)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:02 (USB-UHCI)
> > Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:03 (PIIX4
> ACPI)
> > Dec 29 23:08:15 n4 HVM18[18302]:
> xs_read(/local/domain/0/device-model/18/xen_extended_power_mgmt): read error
> > Dec 29 23:08:15 n4 HVM18[18302]: releasing VM
> > Dec 29 23:08:15 n4 HVM18[18302]: xs_read(): vncpasswd get error.
> /vm/6591a403-0eba-30b4-96a6-e02a7db0607a/vncpasswd.
> > Dec 29 23:08:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port:
> 0, data: 0, count: 0, size: 0
> > Dec 29 17:38:15 n4 last message repeated 2 times
> > Dec 29 17:38:15 n4 HVM18[18302]: Triggered log-dirty buffer switch
> > Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port:
> 0, data: 0, count: 0, size: 0
> > Dec 29 17:38:15 n4 HVM18[18302]: medium change watch on `hdd' (index: 1):
> > Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, port:
> 0, data: 0, count: 0, size: 0
> > Dec 29 17:38:15 n4 last message repeated 11 times
> > Dec 29 17:38:16 n4 HVM18[18302]: cirrus vga map change while on lfb mode
> > Dec 29 23:08:16 n4 ovs-vsctl: 00001|vsctl|INFO|Called as
> /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port tap18.0 -- add-port
> xapi9 tap18.0
> > Dec 29 17:38:16 n4 HVM18[18302]: mapping vram to f0000000 - f0400000
> > Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RW
> > Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RO
> > Dec 29 17:38:18 n4 HVM18[18302]: cirrus: blanking the screen
> line_offset=3072 height=768
> > Dec 29 17:38:34 n4 HVM18[18302]: cirrus: blanking the screen
> line_offset=1024 height=768
> > Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol version set to 1
> (drivers not blacklisted)
> > Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol 1 active
> > Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: product_id: 1 build_number:
> 30876
> > Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: drivers not blacklisted
> > Dec 29 17:38:37 n4 HVM18[18302]: ide_unplug_harddisk: drive 0
> > Dec 29 17:38:37 n4 HVM18[18302]: pci_dev_unplug: 00:04:00
> > Dec 29 17:38:37 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0
> > Dec 29 23:08:38 n4 ovs-vsctl: 00001|vsctl|INFO|Called as
> /usr/bin/ovs-vsctl --timeout=30 -- --if-exists del-port tap18.0
> > Dec 29 17:38:38 n4 HVM18[18302]:  XEVTCHN: InstallDumpDeviceCallback:
> version mismatch (255 != 1)
> > Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: XenevtchnAddDevice: FDO =
> 0xFFFFFA8044323970
> > Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: Initialized tracing provider
> > Dec 29 17:38:38 n4 HVM18[18302]:   XEVTCHN: StartDeviceFdo: ====>
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: XEVTCHN: IO hole:
> [00000000fbfa6000,00000000fc000000) mapped at FFFFF88002965000
> > Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: KERNEL: 6.1 (build 7600)
> platform WIN32_NT
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: SP: NONE
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: SUITES:
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - TERMINAL
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - DATACENTER
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: - SINGLEUSERTS
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: TYPE: SERVER
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: PV DRIVERS: VERSION: 5.6.0
> BUILD: 30876 (Apr 30 2010.06:57:01)
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: 64-bit HVM
> > Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=tap,name=tap.0
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: ExpandGrantTable: GRANT
> TABLE 0: (0 - 511) at FFFFF88002966000 (fbfa7000)
> > Dec 29 17:38:38 n4 HVM18[18302]:   XENUTIL: XenEnterprise product string
> is present
> > Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: PHYSICAL MEMORY: TOP =
> 00000016.8fc00000
> > Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: BalloonTargetChanged:
> 94371840k -> 43792384k
> > Dec 29 17:38:39 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> activating
> > Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2230ms
> > Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 7924ms (2064k/s)
> > Dec 29 17:38:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94355480k)
> > Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 1794ms
> > Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 9157ms (1786k/s)
> > Dec 29 17:38:57 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94339120k)
> > Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5070ms
> > Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 14601ms (1120k/s)
> > Dec 29 17:39:13 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94322760k)
> > Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 4321ms
> > Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 16052ms (1019k/s)
> > Dec 29 17:39:30 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94306400k)
> > Dec 29 17:39:40 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep:
> HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)
> > Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 6099ms
> > Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 15132ms (1081k/s)
> > Dec 29 17:39:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94290040k)
> > Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 4492ms
> > Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 17206ms (950k/s)
> > Dec 29 17:40:04 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94273680k)
> > Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2043ms
> > Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 11294ms (1448k/s)
> > Dec 29 17:40:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94257320k)
> > Dec 29 17:40:27 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep:
> HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)
> > Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5179ms
> > Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 15100ms (1083k/s)
> > Dec 29 17:40:32 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94240960k)
> > Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2230ms
> > Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 12870ms (1271k/s)
> > Dec 29 17:40:46 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94224600k)
> > Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5350ms
> > Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 13228ms (1236k/s)
> > Dec 29 17:41:01 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94208240k)
> > Dec 29 17:41:14 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep:
> HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)
> > Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 3026ms
> > Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 15490ms (1056k/s)
> > Dec 29 17:41:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94191880k)
> > Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 3151ms
> > Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 13291ms (1230k/s)
> > Dec 29 17:41:31 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94175520k)
> > Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5553ms
> > Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 16832ms (971k/s)
> > Dec 29 17:41:49 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94159160k)
> > Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 6754ms
> > Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 18111ms (903k/s)
> > Dec 29 17:42:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94142800k)
> > Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 3244ms
> > Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 18392ms (889k/s)
> > Dec 29 17:42:28 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94126440k)
> > Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5725ms
> > Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 18454ms (886k/s)
> > Dec 29 17:42:47 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94110080k)
> > Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 4243ms
> > Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 19453ms (841k/s)
> > Dec 29 17:43:08 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94093720k)
> > Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 5241ms
> > Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 17206ms (950k/s)
> > Dec 29 17:43:26 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94077360k)
> > Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 1996ms
> > Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 17253ms (948k/s)
> > Dec 29 17:43:44 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94061000k)
> > Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 4773ms
> > Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 16286ms (1004k/s)
> > Dec 29 17:44:02 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94044640k)
> > Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2152ms
> > Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 21231ms (770k/s)
> > Dec 29 17:44:24 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94028280k)
> > Dec 29 17:44:40 n4 HVM18[18302]:   XENUTIL: WARNING: BalloonPodSweep:
> HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)
> > Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: WARNING:
> BalloonReleasePfnArray: ran for more than 2199ms
> > Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 4090 page(s) in 17331ms (943k/s)
> > Dec 29 17:44:42 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread: pausing
> for 1s (target = 43792384k, current = 94011920k)
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> inflated balloon by 12554884 page(s) in 32604ms (91243k/s)
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> de-activating
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: XenevtchnMapResources
> setting callback irq to 11
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: PV init. done
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonTargetChanged:
> 43792384k -> 48911360k
> > Dec 29 17:45:16 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> activating
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: Detected new device vif/0.
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: closing device/vif/0...
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: device/vif/0 closed
> > Dec 29 17:45:16 n4 HVM18[18302]:   XEVTCHN: StartDeviceFdo: <====
> (00000000)
> > Dec 29 17:45:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> deflated balloon by 1279744 page(s) in 998ms (825660k/s)
> > Dec 29 17:45:17 n4 HVM18[18302]:   XENUTIL: BalloonWorkerThread:
> de-activating
> > Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: XENVBD in NORMAL mode.
> > Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: XenvbdAddDevice: FDO =
> 0xFFFFFA804434B060
> > Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: IO hole already
> initialized by XEVTCHN
> > Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: Bugcheck callback
> already installed
> > Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: WARNING: Bugcheck reason
> callback already installed
> > Dec 29 17:45:18 n4 HVM18[18302]:    XENVBD: RescanThread: starting
> > Dec 29 17:45:18 n4 HVM18[18302]:   XENUTIL: XenvbdHwInitialize setting
> callback irq to 30
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: DeviceRelationsFdo: scanning
> targets...
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: XenbusFindVbds: found new
> disk (VBD 768)
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: XenbusFindVbds: ignoring
> cdrom (VBD 5696)
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: claiming
> frontend...
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: successfuly
> claimed device/vbd/768
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: synthesising
> inquiry data: default page
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: unit serial number
> = '62c5a501-d662-4d  '
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: device
> identifier[0]: CodeSet: 'Ascii' Type: 'VendorId' Assocation: 'Device'
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: device
> identifier[0]: Length = 45 Data = 'XENSRC
>  62c5a501-d662-4d38-a75c-a280e2929297 '
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: closing frontend...
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: backend is closed
> > Dec 29 17:45:19 n4 HVM18[18302]:    XENVBD: target 0: created
>
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
>
>

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

Hello Konrad.<br><br>Thanks for your email. I have added my responses below=
.<br><br><br><br><div class=3D"gmail_quote">On Tue, Jan 3, 2012 at 11:22 PM=
, Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@darn=
ok.org">konrad@darnok.org</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 Thu,=
 Dec 29, 2011 at 11:28:59PM +0530, R J wrote:<br>
&gt; Hello List,<br>
&gt;<br>
&gt; Merry Christmas to all !!<br>
&gt;<br>
&gt; Basically I&#39;m trying to boot a Windows 2008R2 DC HVM with 90GB sta=
tic max<br>
&gt; memory and 32GB static min.<br>
&gt;<br>
&gt; The node config is Dell M610 with X5660 and 96GB RAM and its running X=
CP 1.1<br>
&gt;<br>
&gt; Many times the node crashes while booting HVM. Sometimes I get success=
.<br>
<br>
<br>
</div>Node? Meaning dom0? Or the guest? Are you using dom0_mem=3Dmax:X argu=
ment?<br></blockquote><div><br>Node means the physical machine. I was not s=
ure to call it as dom0.<br>dom0 in this case has default 750 MB RAM.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
&gt; I have attached the HVM boot log of successful start. Many times the n=
ode<br>
&gt; hangs as soon as the BalloonWorkerThread is activated.<br>
<br>
</div>Which PV driver is this? Is this with the other ones: GPL one, Citrix=
, Novell, and<br>
Oracle as well?<br></blockquote><div>=A0</div><div>This is Citrix PV driver=
. XCP 1.1 and PV drivers are 1.1 version.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">

<div class=3D"im"><br>
&gt;<br>
&gt; In attached txt the ballon inflation rate is constant 4090<br>
</div>&gt; *XENUTIL: BalloonWorkerThread: inflated balloon by 4090 page(s) =
in 7924ms<br>
&gt; (2064k/s) =A0*<br>
<div class=3D"im">&gt;<br>
&gt; till the time it starts, the inflation rate shoots to 12554884 and the=
 VM<br>
&gt; is live.<br>
</div>&gt; *XENUTIL: BalloonWorkerThread: inflated balloon by 12554884 page=
(s) in<br>
&gt; 32604ms (91243k/s) *<br>
&gt; *XENUTIL: BalloonWorkerThread: de-activating *<br>
&gt; *XENUTIL: XenevtchnMapResources setting callback irq to 11 *<br>
&gt;<br>
&gt;<br>
&gt; Can some one help me understand the *BalloonWorkerThread *behavior ?*<=
br>
&gt;<br>
&gt;<br>
&gt; *Many thanks,<br>
&gt; Rushi<br>
<br>
&gt; Dec 29 23:08:01 n4 xenguest: Determined the following parameters from =
xenstore:<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/number:16 vcpu/weight:0 vcpu/cap:0 n=
x: 1 viridian: 1 apic: 1 acpi: 1 pae: 1 acpi_s4: 0 acpi_s3: 0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/0/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/1/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/2/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/3/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/4/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/5/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/6/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/7/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/8/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/9/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/10/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/11/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/12/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/13/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/14/affinity:0<br>
&gt; Dec 29 23:08:01 n4 xenguest: vcpu/15/affinity:0<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-control: init, 10 x 4k buff=
ers<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: I/O queue driver: lio<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: tapdisk-log: started, level 0<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: received &#39;attach&#39; message (=
uuid =3D 0)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: sending &#39;attach response&#39; m=
essage (uuid =3D 0)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: received &#39;open&#39; message (uu=
id =3D 0)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: Loading driver &#39;vhd&#39; for vb=
d 0 /dev/VG_XenStorage-49740841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d6=
62-4d38-a75c-a280e2929297 0x00000000<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: /dev/VG_XenStorage-49740841-8056-06=
e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 version: tap =
0x00010003, b: 15360, a: 307, f: 26, n: 1268376<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: opened image /dev/VG_XenStorage-497=
40841-8056-06e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297 =
(1 users, state: 0x00000001, type: 4)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: /dev/mapper/VG_XenStorage--49740841=
--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa52934=
08b version: tap 0x00010003, b: 15360, a: 3331, f: 3307, n: 0<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: opened image /dev/mapper/VG_XenStor=
age--49740841--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a8=
50--3aaa5293408b (1 users, state: 0x00000003, type: 4)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: VBD CHAIN:<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: /dev/VG_XenStorage-49740841-8056-06=
e2-373b-ec72084f6fb0/VHD-62c5a501-d662-4d38-a75c-a280e2929297: type:vhd(4) =
storage:lvm(3)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: /dev/mapper/VG_XenStorage--49740841=
--8056--06e2--373b--ec72084f6fb0-VHD--8eae906c--8f44--4618--a850--3aaa52934=
08b: type:vhd(4) storage:lvm(3)<br>
&gt; Dec 29 23:08:14 n4 tapdisk[18204]: sending &#39;open response&#39; mes=
sage (uuid =3D 0)<br>
&gt; Dec 29 23:08:14 n4 vbd.uevent[add](backend/vbd/18/768): wrote /xapi/18=
/hotplug/vbd/768/hotplug =3D &#39;online&#39;<br>
&gt; Dec 29 23:08:15 n4 vbd.uevent[add](backend/vbd/18/5696): wrote /xapi/1=
8/hotplug/vbd/5696/hotplug =3D &#39;online&#39;<br>
&gt; Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-=
vsctl list-ports xapi9<br>
&gt; Dec 29 23:08:15 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-=
vsctl --timeout=3D30 -- --if-exists del-port vif18.0 -- add-port xapi9 vif1=
8.0 -- set interface vif18.0 &quot;external-ids:\&quot;xs-vm-uuid\&quot;=3D=
\&quot;6591a403-0eba-30b4-96a6-e02a7db0607a\&quot;&quot; -- set interface v=
if18.0 &quot;external-ids:\&quot;xs-vif-uuid\&quot;=3D\&quot;3be54e6d-6d13-=
b04b-6735-24831e5169e5\&quot;&quot; -- set interface vif18.0 &quot;external=
-ids:\&quot;xs-network-uuid\&quot;=3D\&quot;7051ef99-4fcb-fa61-a10e-f98456e=
12e90\&quot;&quot; -- set interface vif18.0 &quot;external-ids:\&quot;attac=
hed-mac\&quot;=3D\&quot;d6:6d:60:7e:45:52\&quot;&quot;<br>

&gt; Dec 29 23:08:15 n4 qemu.18: domid: 18<br>
&gt; Dec 29 23:08:15 n4 qemu.18: qemu: the number of cpus is 16<br>
&gt; Dec 29 23:08:15 n4 qemu.18: -videoram option does not work with cirrus=
 vga device model. Videoram set to 4M.<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: Guest uuid =3D 6591a403-0eba-30b4-96a=
6-e02a7db0607a<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: Watching /local/domain/18/logdirty/ne=
xt-active<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: Watching /local/domain/0/device-model=
/18/command<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/2<=
br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: char device redirected to /dev/pts/3<=
br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: qemu_map_cache_init nr_buckets =3D 40=
00 size 327680<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: shared page at pfn feffd<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: buffered io page at pfn feffb<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: Time offset set 0<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:00:00 (i440FX=
)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:00 (PIIX3)=
<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:02:00 (Cirrus=
 VGA)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: populating video RAM at ff000000<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: mapping video RAM from ff000000<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:03:00 (xen-pl=
atform)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: xs_read(/vm/6591a403-0eba-30b4-96a6-e=
02a7db0607a/log-throttling): read error<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: ROM memory area now RW<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:04:00 (RTL813=
9)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:01 (PIIX3 =
IDE)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:02 (USB-UH=
CI)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: pci_register_device: 00:01:03 (PIIX4 =
ACPI)<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: xs_read(/local/domain/0/device-model/=
18/xen_extended_power_mgmt): read error<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: releasing VM<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: xs_read(): vncpasswd get error. /vm/6=
591a403-0eba-30b4-96a6-e02a7db0607a/vncpasswd.<br>
&gt; Dec 29 23:08:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, por=
t: 0, data: 0, count: 0, size: 0<br>
&gt; Dec 29 17:38:15 n4 last message repeated 2 times<br>
&gt; Dec 29 17:38:15 n4 HVM18[18302]: Triggered log-dirty buffer switch<br>
&gt; Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, por=
t: 0, data: 0, count: 0, size: 0<br>
&gt; Dec 29 17:38:15 n4 HVM18[18302]: medium change watch on `hdd&#39; (ind=
ex: 1):<br>
&gt; Dec 29 17:38:15 n4 HVM18[18302]: I/O request not ready: 0, ptr: 0, por=
t: 0, data: 0, count: 0, size: 0<br>
&gt; Dec 29 17:38:15 n4 last message repeated 11 times<br>
&gt; Dec 29 17:38:16 n4 HVM18[18302]: cirrus vga map change while on lfb mo=
de<br>
&gt; Dec 29 23:08:16 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-=
vsctl --timeout=3D30 -- --if-exists del-port tap18.0 -- add-port xapi9 tap1=
8.0<br>
&gt; Dec 29 17:38:16 n4 HVM18[18302]: mapping vram to f0000000 - f0400000<b=
r>
&gt; Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RW<br>
&gt; Dec 29 17:38:17 n4 HVM18[18302]: ROM memory area now RO<br>
&gt; Dec 29 17:38:18 n4 HVM18[18302]: cirrus: blanking the screen line_offs=
et=3D3072 height=3D768<br>
&gt; Dec 29 17:38:34 n4 HVM18[18302]: cirrus: blanking the screen line_offs=
et=3D1024 height=3D768<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol version set to 1 (dr=
ivers not blacklisted)<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: protocol 1 active<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: product_id: 1 build_number: 3=
0876<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: UNPLUG: drivers not blacklisted<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: ide_unplug_harddisk: drive 0<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: pci_dev_unplug: 00:04:00<br>
&gt; Dec 29 17:38:37 n4 HVM18[18302]: net_tap_shutdown: model=3Dtap,name=3D=
tap.0<br>
&gt; Dec 29 23:08:38 n4 ovs-vsctl: 00001|vsctl|INFO|Called as /usr/bin/ovs-=
vsctl --timeout=3D30 -- --if-exists del-port tap18.0<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0XEVTCHN: InstallDumpDeviceCallback=
: version mismatch (255 !=3D 1)<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XEVTCHN: XenevtchnAddDevice: FDO =
=3D 0xFFFFFA8044323970<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XEVTCHN: Initialized tracing prov=
ider<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XEVTCHN: StartDeviceFdo: =3D=3D=
=3D=3D&gt;<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: XEVTCHN: IO hole: [00000=
000fbfa6000,00000000fc000000) mapped at FFFFF88002965000<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=3Dtap,name=3D=
tap.0<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: KERNEL: 6.1 (build 7600)=
 platform WIN32_NT<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: SP: NONE<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: SUITES:<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: - TERMINAL<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: - DATACENTER<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: - SINGLEUSERTS<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: TYPE: SERVER<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: PV DRIVERS: VERSION: 5.6=
.0 BUILD: 30876 (Apr 30 2010.06:57:01)<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: 64-bit HVM<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: net_tap_shutdown: model=3Dtap,name=3D=
tap.0<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: ExpandGrantTable: GRANT =
TABLE 0: (0 - 511) at FFFFF88002966000 (fbfa7000)<br>
&gt; Dec 29 17:38:38 n4 HVM18[18302]: =A0 XENUTIL: XenEnterprise product st=
ring is present<br>
&gt; Dec 29 17:38:39 n4 HVM18[18302]: =A0 XENUTIL: PHYSICAL MEMORY: TOP =3D=
 00000016.8fc00000<br>
&gt; Dec 29 17:38:39 n4 HVM18[18302]: =A0 XENUTIL: BalloonTargetChanged: 94=
371840k -&gt; 43792384k<br>
&gt; Dec 29 17:38:39 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: act=
ivating<br>
&gt; Dec 29 17:38:47 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2230ms<br>
&gt; Dec 29 17:38:47 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 7924ms (2064k/s)<br>
&gt; Dec 29 17:38:47 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94355480k)<br>
&gt; Dec 29 17:38:57 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 1794ms<br>
&gt; Dec 29 17:38:57 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 9157ms (1786k/s)<br>
&gt; Dec 29 17:38:57 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94339120k)<br>
&gt; Dec 29 17:39:13 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5070ms<br>
&gt; Dec 29 17:39:13 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 14601ms (1120k/s)<br>
&gt; Dec 29 17:39:13 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94322760k)<br>
&gt; Dec 29 17:39:30 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 4321ms<br>
&gt; Dec 29 17:39:30 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 16052ms (1019k/s)<br>
&gt; Dec 29 17:39:30 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94306400k)<br>
&gt; Dec 29 17:39:40 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonPodSweep=
: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)<br>
&gt; Dec 29 17:39:46 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 6099ms<br>
&gt; Dec 29 17:39:46 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 15132ms (1081k/s)<br>
&gt; Dec 29 17:39:46 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94290040k)<br>
&gt; Dec 29 17:40:04 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 4492ms<br>
&gt; Dec 29 17:40:04 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 17206ms (950k/s)<br>
&gt; Dec 29 17:40:04 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94273680k)<br>
&gt; Dec 29 17:40:16 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2043ms<br>
&gt; Dec 29 17:40:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 11294ms (1448k/s)<br>
&gt; Dec 29 17:40:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94257320k)<br>
&gt; Dec 29 17:40:27 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonPodSweep=
: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)<br>
&gt; Dec 29 17:40:32 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5179ms<br>
&gt; Dec 29 17:40:32 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 15100ms (1083k/s)<br>
&gt; Dec 29 17:40:32 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94240960k)<br>
&gt; Dec 29 17:40:46 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2230ms<br>
&gt; Dec 29 17:40:46 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 12870ms (1271k/s)<br>
&gt; Dec 29 17:40:46 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94224600k)<br>
&gt; Dec 29 17:41:01 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5350ms<br>
&gt; Dec 29 17:41:01 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 13228ms (1236k/s)<br>
&gt; Dec 29 17:41:01 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94208240k)<br>
&gt; Dec 29 17:41:14 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonPodSweep=
: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)<br>
&gt; Dec 29 17:41:17 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 3026ms<br>
&gt; Dec 29 17:41:17 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 15490ms (1056k/s)<br>
&gt; Dec 29 17:41:17 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94191880k)<br>
&gt; Dec 29 17:41:31 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 3151ms<br>
&gt; Dec 29 17:41:31 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 13291ms (1230k/s)<br>
&gt; Dec 29 17:41:31 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94175520k)<br>
&gt; Dec 29 17:41:49 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5553ms<br>
&gt; Dec 29 17:41:49 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 16832ms (971k/s)<br>
&gt; Dec 29 17:41:49 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94159160k)<br>
&gt; Dec 29 17:42:08 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 6754ms<br>
&gt; Dec 29 17:42:08 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 18111ms (903k/s)<br>
&gt; Dec 29 17:42:08 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94142800k)<br>
&gt; Dec 29 17:42:28 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 3244ms<br>
&gt; Dec 29 17:42:28 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 18392ms (889k/s)<br>
&gt; Dec 29 17:42:28 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94126440k)<br>
&gt; Dec 29 17:42:47 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5725ms<br>
&gt; Dec 29 17:42:47 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 18454ms (886k/s)<br>
&gt; Dec 29 17:42:47 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94110080k)<br>
&gt; Dec 29 17:43:08 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 4243ms<br>
&gt; Dec 29 17:43:08 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 19453ms (841k/s)<br>
&gt; Dec 29 17:43:08 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94093720k)<br>
&gt; Dec 29 17:43:26 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 5241ms<br>
&gt; Dec 29 17:43:26 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 17206ms (950k/s)<br>
&gt; Dec 29 17:43:26 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94077360k)<br>
&gt; Dec 29 17:43:44 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 1996ms<br>
&gt; Dec 29 17:43:44 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 17253ms (948k/s)<br>
&gt; Dec 29 17:43:44 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94061000k)<br>
&gt; Dec 29 17:44:02 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 4773ms<br>
&gt; Dec 29 17:44:02 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 16286ms (1004k/s)<br>
&gt; Dec 29 17:44:02 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94044640k)<br>
&gt; Dec 29 17:44:24 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2152ms<br>
&gt; Dec 29 17:44:24 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 21231ms (770k/s)<br>
&gt; Dec 29 17:44:24 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94028280k)<br>
&gt; Dec 29 17:44:40 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonPodSweep=
: HYPERVISOR_memory_op(XENMEM_pod_sweep, ...) failed (fffffff4)<br>
&gt; Dec 29 17:44:42 n4 HVM18[18302]: =A0 XENUTIL: WARNING: BalloonReleaseP=
fnArray: ran for more than 2199ms<br>
&gt; Dec 29 17:44:42 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 4090 page(s) in 17331ms (943k/s)<br>
&gt; Dec 29 17:44:42 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: pau=
sing for 1s (target =3D 43792384k, current =3D 94011920k)<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: inf=
lated balloon by 12554884 page(s) in 32604ms (91243k/s)<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: de-=
activating<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: XenevtchnMapResources se=
tting callback irq to 11<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: PV init. done<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonTargetChanged: 43=
792384k -&gt; 48911360k<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: act=
ivating<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: Detected new device vif/=
0.<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: closing device/vif/0...<=
br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: device/vif/0 closed<br>
&gt; Dec 29 17:45:16 n4 HVM18[18302]: =A0 XEVTCHN: StartDeviceFdo: &lt;=3D=
=3D=3D=3D (00000000)<br>
&gt; Dec 29 17:45:17 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: def=
lated balloon by 1279744 page(s) in 998ms (825660k/s)<br>
&gt; Dec 29 17:45:17 n4 HVM18[18302]: =A0 XENUTIL: BalloonWorkerThread: de-=
activating<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 =A0XENVBD: XENVBD in NORMAL mode.=
<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 =A0XENVBD: XenvbdAddDevice: FDO =
=3D 0xFFFFFA804434B060<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 XENUTIL: WARNING: IO hole already=
 initialized by XEVTCHN<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 XENUTIL: WARNING: Bugcheck callba=
ck already installed<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 XENUTIL: WARNING: Bugcheck reason=
 callback already installed<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 =A0XENVBD: RescanThread: starting=
<br>
&gt; Dec 29 17:45:18 n4 HVM18[18302]: =A0 XENUTIL: XenvbdHwInitialize setti=
ng callback irq to 30<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: DeviceRelationsFdo: sc=
anning targets...<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: XenbusFindVbds: found =
new disk (VBD 768)<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: XenbusFindVbds: ignori=
ng cdrom (VBD 5696)<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: claiming fro=
ntend...<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: successfuly =
claimed device/vbd/768<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: synthesising=
 inquiry data: default page<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: unit serial =
number =3D &#39;62c5a501-d662-4d =A0&#39;<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: device ident=
ifier[0]: CodeSet: &#39;Ascii&#39; Type: &#39;VendorId&#39; Assocation: &#3=
9;Device&#39;<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: device ident=
ifier[0]: Length =3D 45 Data =3D &#39;XENSRC =A062c5a501-d662-4d38-a75c-a28=
0e2929297 &#39;<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: closing fron=
tend...<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: backend is c=
losed<br>
&gt; Dec 29 17:45:19 n4 HVM18[18302]: =A0 =A0XENVBD: target 0: created<br>
<br>
&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xenso=
urce.com</a><br>
&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">htt=
p://lists.xensource.com/xen-devel</a><br>
<br>
</blockquote></div><br>

--90e6ba5bb8db995ea304b5b5aa9d--


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

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

--===============7184661725521072918==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:58:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:58:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTDq-0006KF-2w; Wed, 04 Jan 2012 15:57:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RiTDp-0006K7-8L
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:57:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325692662!2981920!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjk4NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjk4NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18245 invoked from network); 4 Jan 2012 15:57:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 4 Jan 2012 15:57:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325692662; l=1737;
	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=pfdFWRyYYmJvispeFaQF/PBtJ1M=;
	b=xm28+OFDpg2yX9h/9wv3Pbvrq44TiDJnv4HoHBuuGGmgIzoikbvVb07OF4L0t4n7l3w
	8WwH/DWlQBbwoir5+1Ni71FR8NlXDfdH3Ogu9vk0O/D5hYNdI29QWX4bP8IGJaztU+mUQ
	kRcBkC4kJZMYvOFl32TWsQZEKI1jYY4G78o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjy0PFmWD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-071-152.pools.arcor-ip.net [88.65.71.152])
	by post.strato.de (mrclete mo21) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 600e9do04Dxn6P ;
	Wed, 4 Jan 2012 16:57:35 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id F02B518637; Wed,  4 Jan 2012 16:57:34 +0100 (CET)
Date: Wed, 4 Jan 2012 16:57:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120104155734.GA9271@aepfle.de>
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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325588512.25206.60.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>,
	Ian Jackson <Ian.Jackson@eu.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, Jan 03, Ian Campbell wrote:

> As I said in the bit you trimmed the precedent seems to be to
> write /local/domain/<N>/control/platform-feature-<X> for each guest that
> you want to expose the feature to. I think a per-guest key makes sense
> since even if something seems obviously global you never know when you
> might need to hide it from a guest (e.g. to workaround an in-guest bug).
> 
> I'm afraid I don't have time to work on this myself but it seems pretty
> simple?

After looking at this, the (compile tested) patch below should be enough:


diff -r 3a22ed3ec534 tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -884,6 +884,10 @@ bool xs_introduce_domain(struct xs_handl
 	char mfn_str[MAX_STRLEN(mfn)];
 	char eventchn_str[MAX_STRLEN(eventchn)];
 	struct iovec iov[3];
+	static const char feat[] = "control/platform-feature-xs_reset_watches";
+	int len;
+	char *dom_path, *feat_path;
+	bool ret;
 
 	snprintf(domid_str, sizeof(domid_str), "%u", domid);
 	snprintf(mfn_str, sizeof(mfn_str), "%lu", mfn);
@@ -896,8 +900,21 @@ bool xs_introduce_domain(struct xs_handl
 	iov[2].iov_base = eventchn_str;
 	iov[2].iov_len = strlen(eventchn_str) + 1;
 
-	return xs_bool(xs_talkv(h, XBT_NULL, XS_INTRODUCE, iov,
+	ret = xs_bool(xs_talkv(h, XBT_NULL, XS_INTRODUCE, iov,
 				ARRAY_SIZE(iov), NULL));
+
+	dom_path = xs_get_domain_path(h, domid);
+	if (dom_path) {
+		len = strlen(dom_path) + 1 + strlen(feat);
+		feat_path = malloc(len + 1);
+		if (feat_path) {
+			snprintf(feat_path, len + 1, "%s/%s", dom_path, feat);
+			xs_write(h, XBT_NULL, feat_path, "1", 1);
+			free(feat_path);
+		}
+		free(dom_path);
+	}
+	return ret;
 }
 
 bool xs_set_target(struct xs_handle *h,

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 15:58:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 15:58:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTDq-0006KF-2w; Wed, 04 Jan 2012 15:57:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RiTDp-0006K7-8L
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 15:57:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325692662!2981920!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjk4NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjk4NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18245 invoked from network); 4 Jan 2012 15:57:43 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 4 Jan 2012 15:57:43 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325692662; l=1737;
	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=pfdFWRyYYmJvispeFaQF/PBtJ1M=;
	b=xm28+OFDpg2yX9h/9wv3Pbvrq44TiDJnv4HoHBuuGGmgIzoikbvVb07OF4L0t4n7l3w
	8WwH/DWlQBbwoir5+1Ni71FR8NlXDfdH3Ogu9vk0O/D5hYNdI29QWX4bP8IGJaztU+mUQ
	kRcBkC4kJZMYvOFl32TWsQZEKI1jYY4G78o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjy0PFmWD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-071-152.pools.arcor-ip.net [88.65.71.152])
	by post.strato.de (mrclete mo21) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 600e9do04Dxn6P ;
	Wed, 4 Jan 2012 16:57:35 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id F02B518637; Wed,  4 Jan 2012 16:57:34 +0100 (CET)
Date: Wed, 4 Jan 2012 16:57:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120104155734.GA9271@aepfle.de>
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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325588512.25206.60.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>,
	Ian Jackson <Ian.Jackson@eu.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, Jan 03, Ian Campbell wrote:

> As I said in the bit you trimmed the precedent seems to be to
> write /local/domain/<N>/control/platform-feature-<X> for each guest that
> you want to expose the feature to. I think a per-guest key makes sense
> since even if something seems obviously global you never know when you
> might need to hide it from a guest (e.g. to workaround an in-guest bug).
> 
> I'm afraid I don't have time to work on this myself but it seems pretty
> simple?

After looking at this, the (compile tested) patch below should be enough:


diff -r 3a22ed3ec534 tools/xenstore/xs.c
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -884,6 +884,10 @@ bool xs_introduce_domain(struct xs_handl
 	char mfn_str[MAX_STRLEN(mfn)];
 	char eventchn_str[MAX_STRLEN(eventchn)];
 	struct iovec iov[3];
+	static const char feat[] = "control/platform-feature-xs_reset_watches";
+	int len;
+	char *dom_path, *feat_path;
+	bool ret;
 
 	snprintf(domid_str, sizeof(domid_str), "%u", domid);
 	snprintf(mfn_str, sizeof(mfn_str), "%lu", mfn);
@@ -896,8 +900,21 @@ bool xs_introduce_domain(struct xs_handl
 	iov[2].iov_base = eventchn_str;
 	iov[2].iov_len = strlen(eventchn_str) + 1;
 
-	return xs_bool(xs_talkv(h, XBT_NULL, XS_INTRODUCE, iov,
+	ret = xs_bool(xs_talkv(h, XBT_NULL, XS_INTRODUCE, iov,
 				ARRAY_SIZE(iov), NULL));
+
+	dom_path = xs_get_domain_path(h, domid);
+	if (dom_path) {
+		len = strlen(dom_path) + 1 + strlen(feat);
+		feat_path = malloc(len + 1);
+		if (feat_path) {
+			snprintf(feat_path, len + 1, "%s/%s", dom_path, feat);
+			xs_write(h, XBT_NULL, feat_path, "1", 1);
+			free(feat_path);
+		}
+		free(dom_path);
+	}
+	return ret;
 }
 
 bool xs_set_target(struct xs_handle *h,

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:03:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTIc-0006uQ-U3; Wed, 04 Jan 2012 16:02:46 +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 1RiTIb-0006uB-2a
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:02:45 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325692957!7806901!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 22991 invoked from network); 4 Jan 2012 16:02:37 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-174.messagelabs.com with SMTP;
	4 Jan 2012 16:02:37 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74286793; Wed, 04 Jan 2012 17:02:36 +0100
Message-ID: <1325692924.2633.2.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 04 Jan 2012 17:02:04 +0100
In-Reply-To: <CAFLBxZbaGiOV-2rBiKZxe6vfLYeG9F1Qer4SoZ945uMzrn6NOQ@mail.gmail.com>
References: <1324054424.2599.13.camel@Solace>
	<CAFLBxZbaGiOV-2rBiKZxe6vfLYeG9F1Qer4SoZ945uMzrn6NOQ@mail.gmail.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
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: multipart/mixed; boundary="===============1048687874952464952=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1048687874952464952==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-lglwhW5zc6sqzgUIDS8U"


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

On Fri, 2011-12-16 at 18:02 +0000, George Dunlap wrote:
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>=20
So... Should I do something else or can this be checked-in? :-)

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)


--=-lglwhW5zc6sqzgUIDS8U
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)

iEYEABECAAYFAk8Ed/wACgkQk4XaBE3IOsTmgwCeLWGvhO8Er/LR8Gn9HwWn5QRV
8p4AoKawsJnx9StTRCbExfAd/ylSE7p/
=jO61
-----END PGP SIGNATURE-----

--=-lglwhW5zc6sqzgUIDS8U--



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

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

--===============1048687874952464952==--



From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:03:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTIc-0006uQ-U3; Wed, 04 Jan 2012 16:02:46 +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 1RiTIb-0006uB-2a
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:02:45 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325692957!7806901!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 22991 invoked from network); 4 Jan 2012 16:02:37 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-174.messagelabs.com with SMTP;
	4 Jan 2012 16:02:37 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74286793; Wed, 04 Jan 2012 17:02:36 +0100
Message-ID: <1325692924.2633.2.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 04 Jan 2012 17:02:04 +0100
In-Reply-To: <CAFLBxZbaGiOV-2rBiKZxe6vfLYeG9F1Qer4SoZ945uMzrn6NOQ@mail.gmail.com>
References: <1324054424.2599.13.camel@Solace>
	<CAFLBxZbaGiOV-2rBiKZxe6vfLYeG9F1Qer4SoZ945uMzrn6NOQ@mail.gmail.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
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: multipart/mixed; boundary="===============1048687874952464952=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1048687874952464952==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-lglwhW5zc6sqzgUIDS8U"


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

On Fri, 2011-12-16 at 18:02 +0000, George Dunlap wrote:
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>=20
So... Should I do something else or can this be checked-in? :-)

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)


--=-lglwhW5zc6sqzgUIDS8U
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)

iEYEABECAAYFAk8Ed/wACgkQk4XaBE3IOsTmgwCeLWGvhO8Er/LR8Gn9HwWn5QRV
8p4AoKawsJnx9StTRCbExfAd/ylSE7p/
=jO61
-----END PGP SIGNATURE-----

--=-lglwhW5zc6sqzgUIDS8U--



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

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

--===============1048687874952464952==--



From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:04:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTJl-0006yu-Cq; Wed, 04 Jan 2012 16:03:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1RiTJj-0006yj-R5
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:03:56 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325692991!50888956!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20043 invoked from network); 4 Jan 2012 16:03:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 16:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; d="asc'?scan'208";a="9817567"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:03:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Jan 2012
	16:03:54 +0000
Message-ID: <1325693012.2633.4.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 4 Jan 2012 17:03:32 +0100
In-Reply-To: <CAFLBxZa586C7D=2zW-NTsA5jxroRcWEoCk7YNg9KBdJwMoGZwQ@mail.gmail.com>
References: <1324052965.2599.8.camel@Solace>
	<CAFLBxZa586C7D=2zW-NTsA5jxroRcWEoCk7YNg9KBdJwMoGZwQ@mail.gmail.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, 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: multipart/mixed; boundary="===============4510558539902146104=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4510558539902146104==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-NlT+FjBRBYXRahYsI8aE"

--=-NlT+FjBRBYXRahYsI8aE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2011-12-16 at 18:06 +0000, George Dunlap wrote:
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> Looks reasonable to me.
>=20
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>=20
>=20
Again... Should I do something else or can this be checked-in? :-)

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)


--=-NlT+FjBRBYXRahYsI8aE
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)

iEYEABECAAYFAk8EeFQACgkQk4XaBE3IOsQH1wCfWQ8BwubCpPT1ij2+VMofUE0K
aCoAoKE8fem2b1jVibrvo9FYO+aCXSuP
=snGd
-----END PGP SIGNATURE-----

--=-NlT+FjBRBYXRahYsI8aE--


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

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

--===============4510558539902146104==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:04:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:04:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTJl-0006yu-Cq; Wed, 04 Jan 2012 16:03:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dario.faggioli@citrix.com>) id 1RiTJj-0006yj-R5
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:03:56 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325692991!50888956!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20043 invoked from network); 4 Jan 2012 16:03:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 16:03:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; d="asc'?scan'208";a="9817567"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:03:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Jan 2012
	16:03:54 +0000
Message-ID: <1325693012.2633.4.camel@Solace>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 4 Jan 2012 17:03:32 +0100
In-Reply-To: <CAFLBxZa586C7D=2zW-NTsA5jxroRcWEoCk7YNg9KBdJwMoGZwQ@mail.gmail.com>
References: <1324052965.2599.8.camel@Solace>
	<CAFLBxZa586C7D=2zW-NTsA5jxroRcWEoCk7YNg9KBdJwMoGZwQ@mail.gmail.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>, 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: multipart/mixed; boundary="===============4510558539902146104=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4510558539902146104==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-NlT+FjBRBYXRahYsI8aE"

--=-NlT+FjBRBYXRahYsI8aE
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2011-12-16 at 18:06 +0000, George Dunlap wrote:
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> Looks reasonable to me.
>=20
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>=20
>=20
Again... Should I do something else or can this be checked-in? :-)

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)


--=-NlT+FjBRBYXRahYsI8aE
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)

iEYEABECAAYFAk8EeFQACgkQk4XaBE3IOsQH1wCfWQ8BwubCpPT1ij2+VMofUE0K
aCoAoKE8fem2b1jVibrvo9FYO+aCXSuP
=snGd
-----END PGP SIGNATURE-----

--=-NlT+FjBRBYXRahYsI8aE--


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

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

--===============4510558539902146104==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:10:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTPS-0007Ir-BM; Wed, 04 Jan 2012 16:09:50 +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 1RiTPR-0007IZ-It; Wed, 04 Jan 2012 16:09:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325693349!54662689!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MTUyOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18870 invoked from network); 4 Jan 2012 16:09:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 16:09:10 -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
	q04G8wOv007171
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 16:08:59 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
	q04G8vg2024147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 16:08:57 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q04G8uT0003292; Wed, 4 Jan 2012 10:08:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 08:08:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5E4DD4047A; Wed,  4 Jan 2012 11:07:25 -0500 (EST)
Date: Wed, 4 Jan 2012 11:07:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: R J <torushikeshj@gmail.com>
Message-ID: <20120104160725.GM3322@phenom.dumpdata.com>
References: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
	<20120103175243.GE749@andromeda.dapyr.net>
	<CAO14VsPre0ScNOfDNSxMKCPvVKRWCOkTVHL_SbF8KZkacSDDAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO14VsPre0ScNOfDNSxMKCPvVKRWCOkTVHL_SbF8KZkacSDDAQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F04799B.0146,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, xen-api@lists.xensource.com
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 09:12:42PM +0530, R J wrote:
> Hello Konrad.
> 
> Thanks for your email. I have added my responses below.

Please don't top post.
> 
> 
> 
> On Tue, Jan 3, 2012 at 11:22 PM, Konrad Rzeszutek Wilk <konrad@darnok.org>wrote:
> 
> > On Thu, Dec 29, 2011 at 11:28:59PM +0530, R J wrote:
> > > 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.
> >
> >
> > Node? Meaning dom0? Or the guest? Are you using dom0_mem=max:X argument?
> >
> 
> Node means the physical machine. I was not sure to call it as dom0.
> dom0 in this case has default 750 MB RAM.

Ok, so did you look in the serial log to see why the node crashed?

> 
> 
> > > I have attached the HVM boot log of successful start. Many times the node
> > > hangs as soon as the BalloonWorkerThread is activated.
> >
> > Which PV driver is this? Is this with the other ones: GPL one, Citrix,
> > Novell, and
> > Oracle as well?
> >
> 
> This is Citrix PV driver. XCP 1.1 and PV drivers are 1.1 version.

OK, can you try other ones?

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:10:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTPS-0007Ir-BM; Wed, 04 Jan 2012 16:09:50 +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 1RiTPR-0007IZ-It; Wed, 04 Jan 2012 16:09:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325693349!54662689!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MTUyOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18870 invoked from network); 4 Jan 2012 16:09:10 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 16:09:10 -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
	q04G8wOv007171
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 16:08:59 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
	q04G8vg2024147
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 16:08:57 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q04G8uT0003292; Wed, 4 Jan 2012 10:08:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 08:08:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5E4DD4047A; Wed,  4 Jan 2012 11:07:25 -0500 (EST)
Date: Wed, 4 Jan 2012 11:07:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: R J <torushikeshj@gmail.com>
Message-ID: <20120104160725.GM3322@phenom.dumpdata.com>
References: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
	<20120103175243.GE749@andromeda.dapyr.net>
	<CAO14VsPre0ScNOfDNSxMKCPvVKRWCOkTVHL_SbF8KZkacSDDAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAO14VsPre0ScNOfDNSxMKCPvVKRWCOkTVHL_SbF8KZkacSDDAQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F04799B.0146,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com, xen-api@lists.xensource.com
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 09:12:42PM +0530, R J wrote:
> Hello Konrad.
> 
> Thanks for your email. I have added my responses below.

Please don't top post.
> 
> 
> 
> On Tue, Jan 3, 2012 at 11:22 PM, Konrad Rzeszutek Wilk <konrad@darnok.org>wrote:
> 
> > On Thu, Dec 29, 2011 at 11:28:59PM +0530, R J wrote:
> > > 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.
> >
> >
> > Node? Meaning dom0? Or the guest? Are you using dom0_mem=max:X argument?
> >
> 
> Node means the physical machine. I was not sure to call it as dom0.
> dom0 in this case has default 750 MB RAM.

Ok, so did you look in the serial log to see why the node crashed?

> 
> 
> > > I have attached the HVM boot log of successful start. Many times the node
> > > hangs as soon as the BalloonWorkerThread is activated.
> >
> > Which PV driver is this? Is this with the other ones: GPL one, Citrix,
> > Novell, and
> > Oracle as well?
> >
> 
> This is Citrix PV driver. XCP 1.1 and PV drivers are 1.1 version.

OK, can you try other ones?

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:14:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiTTF-0007g8-Rp; Wed, 04 Jan 2012 16:13:45 +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 1RiTTE-0007fi-UV
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:13:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325693580!58924172!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 16211 invoked from network); 4 Jan 2012 16:13:01 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 16:13:01 -0000
Received: by iagw33 with SMTP id w33so153023793iag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 08:13:39 -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=8WQn3TUSv8O9Jmpa5BYGi/zanBaFN9GGbvq3GPxoIv8=;
	b=eHbBJeyV1YTK5d7NSdl7jTIogrfLrVis8VZZODXRmT1NFdOBL88+uqqFxXV0uyCNCA
	7Zs6qam22yvYf0f8ff2dJSacJkjC+JJ6IpqEUSqY0qizq8oweopX9uy2ZC9qGfWT5I2c
	E+gUxjoIZCalcq0P3ceqQiI09+kvPi4oZTPd4=
Received: by 10.42.73.138 with SMTP id s10mr58483847icj.38.1325693619208;
	Wed, 04 Jan 2012 08:13:39 -0800 (PST)
Received: from [192.168.1.152] ([198.162.52.244])
	by mx.google.com with ESMTPS id lu10sm96440342igc.0.2012.01.04.08.13.34
	(version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 08:13:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 04 Jan 2012 16:13:23 +0000
From: Keir Fraser <keir@xen.org>
To: Dario Faggioli <raistlin@linux.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CB2A2B23.36D68%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCHv2] Rework locking for sched_adjust.
Thread-Index: AczK+8gftlNBoCmmik620SsBI3M0RA==
In-Reply-To: <1325692924.2633.2.camel@Solace>
Mime-version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 04/01/2012 16:02, "Dario Faggioli" <raistlin@linux.it> wrote:

> On Fri, 2011-12-16 at 18:02 +0000, George Dunlap wrote:
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> 
> So... Should I do something else or can this be checked-in? :-)

Done. And your other one too.

 -- Keir

> Thanks and Regards,
> Dario



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:14:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiTTF-0007g8-Rp; Wed, 04 Jan 2012 16:13:45 +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 1RiTTE-0007fi-UV
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:13:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325693580!58924172!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 16211 invoked from network); 4 Jan 2012 16:13:01 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 16:13:01 -0000
Received: by iagw33 with SMTP id w33so153023793iag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 08:13:39 -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=8WQn3TUSv8O9Jmpa5BYGi/zanBaFN9GGbvq3GPxoIv8=;
	b=eHbBJeyV1YTK5d7NSdl7jTIogrfLrVis8VZZODXRmT1NFdOBL88+uqqFxXV0uyCNCA
	7Zs6qam22yvYf0f8ff2dJSacJkjC+JJ6IpqEUSqY0qizq8oweopX9uy2ZC9qGfWT5I2c
	E+gUxjoIZCalcq0P3ceqQiI09+kvPi4oZTPd4=
Received: by 10.42.73.138 with SMTP id s10mr58483847icj.38.1325693619208;
	Wed, 04 Jan 2012 08:13:39 -0800 (PST)
Received: from [192.168.1.152] ([198.162.52.244])
	by mx.google.com with ESMTPS id lu10sm96440342igc.0.2012.01.04.08.13.34
	(version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 08:13:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 04 Jan 2012 16:13:23 +0000
From: Keir Fraser <keir@xen.org>
To: Dario Faggioli <raistlin@linux.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CB2A2B23.36D68%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCHv2] Rework locking for sched_adjust.
Thread-Index: AczK+8gftlNBoCmmik620SsBI3M0RA==
In-Reply-To: <1325692924.2633.2.camel@Solace>
Mime-version: 1.0
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 04/01/2012 16:02, "Dario Faggioli" <raistlin@linux.it> wrote:

> On Fri, 2011-12-16 at 18:02 +0000, George Dunlap wrote:
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> 
> So... Should I do something else or can this be checked-in? :-)

Done. And your other one too.

 -- Keir

> Thanks and Regards,
> Dario



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:22:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTba-000817-06; Wed, 04 Jan 2012 16:22:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiTbY-00080X-B8
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:22:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325694125!9729728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20904 invoked from network); 4 Jan 2012 16:22: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;
	4 Jan 2012 16:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9818162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:22: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, 4 Jan 2012
	16:22:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 4 Jan 2012 16:22:04 +0000
In-Reply-To: <20120104155734.GA9271@aepfle.de>
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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
	<20120104155734.GA9271@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325694125.25206.299.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>,
	Ian Jackson <Ian.Jackson@eu.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 Wed, 2012-01-04 at 15:57 +0000, Olaf Hering wrote:
> On Tue, Jan 03, Ian Campbell wrote:
> 
> > As I said in the bit you trimmed the precedent seems to be to
> > write /local/domain/<N>/control/platform-feature-<X> for each guest that
> > you want to expose the feature to. I think a per-guest key makes sense
> > since even if something seems obviously global you never know when you
> > might need to hide it from a guest (e.g. to workaround an in-guest bug).
> > 
> > I'm afraid I don't have time to work on this myself but it seems pretty
> > simple?
> 
> After looking at this, the (compile tested) patch below should be enough:
> 
> 
> diff -r 3a22ed3ec534 tools/xenstore/xs.c
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c

I think the toolstack needs to be involved with this. IOW this should be
done in libxl__domain_make() around the same place as
control/platform-feature-multiprocessor-suspend is written.

Ian.

> @@ -884,6 +884,10 @@ bool xs_introduce_domain(struct xs_handl
>  	char mfn_str[MAX_STRLEN(mfn)];
>  	char eventchn_str[MAX_STRLEN(eventchn)];
>  	struct iovec iov[3];
> +	static const char feat[] = "control/platform-feature-xs_reset_watches";
> +	int len;
> +	char *dom_path, *feat_path;
> +	bool ret;
>  
>  	snprintf(domid_str, sizeof(domid_str), "%u", domid);
>  	snprintf(mfn_str, sizeof(mfn_str), "%lu", mfn);
> @@ -896,8 +900,21 @@ bool xs_introduce_domain(struct xs_handl
>  	iov[2].iov_base = eventchn_str;
>  	iov[2].iov_len = strlen(eventchn_str) + 1;
>  
> -	return xs_bool(xs_talkv(h, XBT_NULL, XS_INTRODUCE, iov,
> +	ret = xs_bool(xs_talkv(h, XBT_NULL, XS_INTRODUCE, iov,
>  				ARRAY_SIZE(iov), NULL));
> +
> +	dom_path = xs_get_domain_path(h, domid);
> +	if (dom_path) {
> +		len = strlen(dom_path) + 1 + strlen(feat);
> +		feat_path = malloc(len + 1);
> +		if (feat_path) {
> +			snprintf(feat_path, len + 1, "%s/%s", dom_path, feat);
> +			xs_write(h, XBT_NULL, feat_path, "1", 1);
> +			free(feat_path);
> +		}
> +		free(dom_path);
> +	}
> +	return ret;
>  }
>  
>  bool xs_set_target(struct xs_handle *h,



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:22:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:22:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTba-000817-06; Wed, 04 Jan 2012 16:22:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiTbY-00080X-B8
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:22:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325694125!9729728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20904 invoked from network); 4 Jan 2012 16:22: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;
	4 Jan 2012 16:22:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9818162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:22: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, 4 Jan 2012
	16:22:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Wed, 4 Jan 2012 16:22:04 +0000
In-Reply-To: <20120104155734.GA9271@aepfle.de>
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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
	<20120104155734.GA9271@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325694125.25206.299.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>,
	Ian Jackson <Ian.Jackson@eu.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 Wed, 2012-01-04 at 15:57 +0000, Olaf Hering wrote:
> On Tue, Jan 03, Ian Campbell wrote:
> 
> > As I said in the bit you trimmed the precedent seems to be to
> > write /local/domain/<N>/control/platform-feature-<X> for each guest that
> > you want to expose the feature to. I think a per-guest key makes sense
> > since even if something seems obviously global you never know when you
> > might need to hide it from a guest (e.g. to workaround an in-guest bug).
> > 
> > I'm afraid I don't have time to work on this myself but it seems pretty
> > simple?
> 
> After looking at this, the (compile tested) patch below should be enough:
> 
> 
> diff -r 3a22ed3ec534 tools/xenstore/xs.c
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c

I think the toolstack needs to be involved with this. IOW this should be
done in libxl__domain_make() around the same place as
control/platform-feature-multiprocessor-suspend is written.

Ian.

> @@ -884,6 +884,10 @@ bool xs_introduce_domain(struct xs_handl
>  	char mfn_str[MAX_STRLEN(mfn)];
>  	char eventchn_str[MAX_STRLEN(eventchn)];
>  	struct iovec iov[3];
> +	static const char feat[] = "control/platform-feature-xs_reset_watches";
> +	int len;
> +	char *dom_path, *feat_path;
> +	bool ret;
>  
>  	snprintf(domid_str, sizeof(domid_str), "%u", domid);
>  	snprintf(mfn_str, sizeof(mfn_str), "%lu", mfn);
> @@ -896,8 +900,21 @@ bool xs_introduce_domain(struct xs_handl
>  	iov[2].iov_base = eventchn_str;
>  	iov[2].iov_len = strlen(eventchn_str) + 1;
>  
> -	return xs_bool(xs_talkv(h, XBT_NULL, XS_INTRODUCE, iov,
> +	ret = xs_bool(xs_talkv(h, XBT_NULL, XS_INTRODUCE, iov,
>  				ARRAY_SIZE(iov), NULL));
> +
> +	dom_path = xs_get_domain_path(h, domid);
> +	if (dom_path) {
> +		len = strlen(dom_path) + 1 + strlen(feat);
> +		feat_path = malloc(len + 1);
> +		if (feat_path) {
> +			snprintf(feat_path, len + 1, "%s/%s", dom_path, feat);
> +			xs_write(h, XBT_NULL, feat_path, "1", 1);
> +			free(feat_path);
> +		}
> +		free(dom_path);
> +	}
> +	return ret;
>  }
>  
>  bool xs_set_target(struct xs_handle *h,



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:26:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:26:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTfQ-0008BD-MC; Wed, 04 Jan 2012 16:26:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiTfO-0008Aw-OS
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:26:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325694371!8369995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9951 invoked from network); 4 Jan 2012 16:26:11 -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;
	4 Jan 2012 16:26:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9818290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:26: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, 4 Jan 2012
	16:26:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 4 Jan 2012 16:26:03 +0000
In-Reply-To: <4F046A30.6000009@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>
	<20111215205654.GA11829@andromeda.dapyr.net>	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325694363.25206.302.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>,
	"Keir \(Xen.org\)" <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 Wed, 2012-01-04 at 15:03 +0000, Daniel De Graaf wrote:
> On 01/04/2012 05:47 AM, Stefano Stabellini wrote:
> > On Thu, 15 Dec 2011, Daniel De Graaf wrote:
> >> 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.
> > 
> > It would be great to have a short introduction to flask in the xl man
> > page. What do you think about the following?
> > 
> > 
> > diff -r 50117a4d1a2c docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1	Mon Jan 02 12:43:07 2012 +0000
> > +++ b/docs/man/xl.pod.1	Wed Jan 04 10:46:47 2012 +0000
> > @@ -997,6 +997,20 @@ Get information about how much freeable 
> >  
> >  =head2 FLASK
> >  
> > +B<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.
> > +
> > +See the following document for more details:
> > +
> > +L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
> > +
> >  =over 4
> >  
> >  =item B<getenforce>
> > 
> > 
> > 
> > As you can see, I linked docs/misc/xsm-flask.txt from the xl man page,
> > however xsm-flask.txt still references xend so it needs to be updated.
> 
> This is a good introduction; I have an update to docs/misc/xsm-flask.txt
> that references xl and incorporates some of the changes in the example
> policy (will post momentarily).
> 
> > Also it would be great to link the example policy too, but that one is
> > not online because it is not under docs and it is not installed by
> > default either. Maybe we need to move the example policy to docs? Or
> > maybe it is best to install a copy of it to /etc/xen by default?
>  
> The example policy doesn't really belong in docs because it needs to be
> compiled to be usable,

I think Stefano was referring to having an online copy for reference. I
think it should be ok to have "make -C docs html" (& txt etc) pickup the
source files from tools/flash/policy and export them, this would mean
they would show up on xenbits[0] automatically. Unless the policy files
aren't really suitable for that?

> and this depends on a number of other files (all
> files under tools/flask/policy/policy, to be exact). Compiling and
> installing FLASK policy during the normal build process (conditional on
> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)

I think that makes sense right now. When we switch to autoconf this is
the sort of thing we can/should autodetect.

Ian.

[0] at http://xenbits.xen.org/docs/unstable/

> would be the best solution. The policy must be installed to /boot, not
> /etc/xen, because the initial policy load happens prior to starting dom0.
> 



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:26:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:26:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTfQ-0008BD-MC; Wed, 04 Jan 2012 16:26:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiTfO-0008Aw-OS
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:26:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325694371!8369995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9951 invoked from network); 4 Jan 2012 16:26:11 -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;
	4 Jan 2012 16:26:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9818290"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:26: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, 4 Jan 2012
	16:26:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 4 Jan 2012 16:26:03 +0000
In-Reply-To: <4F046A30.6000009@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>
	<20111215205654.GA11829@andromeda.dapyr.net>	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325694363.25206.302.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>,
	"Keir \(Xen.org\)" <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 Wed, 2012-01-04 at 15:03 +0000, Daniel De Graaf wrote:
> On 01/04/2012 05:47 AM, Stefano Stabellini wrote:
> > On Thu, 15 Dec 2011, Daniel De Graaf wrote:
> >> 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.
> > 
> > It would be great to have a short introduction to flask in the xl man
> > page. What do you think about the following?
> > 
> > 
> > diff -r 50117a4d1a2c docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1	Mon Jan 02 12:43:07 2012 +0000
> > +++ b/docs/man/xl.pod.1	Wed Jan 04 10:46:47 2012 +0000
> > @@ -997,6 +997,20 @@ Get information about how much freeable 
> >  
> >  =head2 FLASK
> >  
> > +B<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.
> > +
> > +See the following document for more details:
> > +
> > +L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
> > +
> >  =over 4
> >  
> >  =item B<getenforce>
> > 
> > 
> > 
> > As you can see, I linked docs/misc/xsm-flask.txt from the xl man page,
> > however xsm-flask.txt still references xend so it needs to be updated.
> 
> This is a good introduction; I have an update to docs/misc/xsm-flask.txt
> that references xl and incorporates some of the changes in the example
> policy (will post momentarily).
> 
> > Also it would be great to link the example policy too, but that one is
> > not online because it is not under docs and it is not installed by
> > default either. Maybe we need to move the example policy to docs? Or
> > maybe it is best to install a copy of it to /etc/xen by default?
>  
> The example policy doesn't really belong in docs because it needs to be
> compiled to be usable,

I think Stefano was referring to having an online copy for reference. I
think it should be ok to have "make -C docs html" (& txt etc) pickup the
source files from tools/flash/policy and export them, this would mean
they would show up on xenbits[0] automatically. Unless the policy files
aren't really suitable for that?

> and this depends on a number of other files (all
> files under tools/flask/policy/policy, to be exact). Compiling and
> installing FLASK policy during the normal build process (conditional on
> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)

I think that makes sense right now. When we switch to autoconf this is
the sort of thing we can/should autodetect.

Ian.

[0] at http://xenbits.xen.org/docs/unstable/

> would be the best solution. The policy must be installed to /boot, not
> /etc/xen, because the initial policy load happens prior to starting dom0.
> 



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:28:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTgn-0008HN-C5; Wed, 04 Jan 2012 16:27:45 +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 1RiTgm-0008Gw-4i
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:27:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325694456!7834931!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyODU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32322 invoked from network); 4 Jan 2012 16:27:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Jan 2012 16:27:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325694455; l=331;
	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=nPDKAJlZA52/018MMmH5Qa20otQ=;
	b=UTyEBhEdS/mcbO8NjsSCZbWxAXT4YIicAy9IlBDidSDw/3pkwrpdprVXYuoS5y4q2ku
	je6MeFZU4j8VcRAJtU4V3B9H6y8PaKfgjAOrz1mKgJV2a55MXB/8OhR7NvwM2V6jy/95M
	5+35XQbL+PJQVkXeVIb+ly8YBZj5Tjtrtds=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjy0PFmWD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-071-152.pools.arcor-ip.net [88.65.71.152])
	by smtp.strato.de (cohen mo26) (RZmta 27.2 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id t02bf8o04Fd3eY ;
	Wed, 4 Jan 2012 17:27:09 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 75A7F18637; Wed,  4 Jan 2012 17:27:08 +0100 (CET)
Date: Wed, 4 Jan 2012 17:27:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120104162708.GA26431@aepfle.de>
References: <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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
	<20120104155734.GA9271@aepfle.de>
	<1325694125.25206.299.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325694125.25206.299.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>,
	Ian Jackson <Ian.Jackson@eu.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 Wed, Jan 04, Ian Campbell wrote:

> I think the toolstack needs to be involved with this. IOW this should be
> done in libxl__domain_make() around the same place as
> control/platform-feature-multiprocessor-suspend is written.

Isnt XS_RESET_WATCHES a feature of xenstored, so it should add its own stuff itself?

Olaf

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:28:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:28:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTgn-0008HN-C5; Wed, 04 Jan 2012 16:27:45 +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 1RiTgm-0008Gw-4i
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:27:44 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325694456!7834931!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyODU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQyODU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32322 invoked from network); 4 Jan 2012 16:27:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Jan 2012 16:27:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325694455; l=331;
	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=nPDKAJlZA52/018MMmH5Qa20otQ=;
	b=UTyEBhEdS/mcbO8NjsSCZbWxAXT4YIicAy9IlBDidSDw/3pkwrpdprVXYuoS5y4q2ku
	je6MeFZU4j8VcRAJtU4V3B9H6y8PaKfgjAOrz1mKgJV2a55MXB/8OhR7NvwM2V6jy/95M
	5+35XQbL+PJQVkXeVIb+ly8YBZj5Tjtrtds=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjy0PFmWD
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-071-152.pools.arcor-ip.net [88.65.71.152])
	by smtp.strato.de (cohen mo26) (RZmta 27.2 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id t02bf8o04Fd3eY ;
	Wed, 4 Jan 2012 17:27:09 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 75A7F18637; Wed,  4 Jan 2012 17:27:08 +0100 (CET)
Date: Wed, 4 Jan 2012 17:27:08 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120104162708.GA26431@aepfle.de>
References: <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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
	<20120104155734.GA9271@aepfle.de>
	<1325694125.25206.299.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325694125.25206.299.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>,
	Ian Jackson <Ian.Jackson@eu.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 Wed, Jan 04, Ian Campbell wrote:

> I think the toolstack needs to be involved with this. IOW this should be
> done in libxl__domain_make() around the same place as
> control/platform-feature-multiprocessor-suspend is written.

Isnt XS_RESET_WATCHES a feature of xenstored, so it should add its own stuff itself?

Olaf

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:29:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16: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 1RiTiU-0008Pm-T8; Wed, 04 Jan 2012 16:29: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 1RiTiT-0008PC-IR
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:29:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325694563!10535660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19196 invoked from network); 4 Jan 2012 16:29:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 16:29:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9818362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:29:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Jan 2012
	16:29:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 4 Jan 2012 16:29:22 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Tim Deegan <tim@xen.org>
Subject: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

What are the outstanding things to do before we think we can start on
the 4.2 -rc's? Does anyone have a timetable in mind?

hypervisor:

      * ??? - Keir, Tim, Jan?

tools:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (IanJ working on this)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate) (IanC working on this, patches
                shortly)
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (IanC working on
                this, patches shortly)
              * The topologyinfo datastructure should be a list of
                tuples, not a tuple of lists. (nobody currently looking
                at this, not 100% sure this makes sense, could possibly
                defer and change after 4.2 in a compatible way)
              * Block script support -- can be done post 4.2?
      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms...
      * Integrate qemu+seabios upstream into the build (Stefano has
        posted patches, I guess they need refreshing and reposting). No
        change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

Has anybody got anything else? I'm sure I've missed stuff. Are there any
must haves e.g. in the paging/sharing spaces?

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:29:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16: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 1RiTiU-0008Pm-T8; Wed, 04 Jan 2012 16:29: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 1RiTiT-0008PC-IR
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:29:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325694563!10535660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19196 invoked from network); 4 Jan 2012 16:29:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 16:29:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9818362"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:29:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Jan 2012
	16:29:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 4 Jan 2012 16:29:22 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Tim Deegan <tim@xen.org>
Subject: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

What are the outstanding things to do before we think we can start on
the 4.2 -rc's? Does anyone have a timetable in mind?

hypervisor:

      * ??? - Keir, Tim, Jan?

tools:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (IanJ working on this)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate) (IanC working on this, patches
                shortly)
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (IanC working on
                this, patches shortly)
              * The topologyinfo datastructure should be a list of
                tuples, not a tuple of lists. (nobody currently looking
                at this, not 100% sure this makes sense, could possibly
                defer and change after 4.2 in a compatible way)
              * Block script support -- can be done post 4.2?
      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms...
      * Integrate qemu+seabios upstream into the build (Stefano has
        posted patches, I guess they need refreshing and reposting). No
        change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

Has anybody got anything else? I'm sure I've missed stuff. Are there any
must haves e.g. in the paging/sharing spaces?

Ian.


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:39:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTrE-0000Za-KM; Wed, 04 Jan 2012 16:38:32 +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 1RiTrD-0000ZT-6O
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:38:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325695105!9695814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17411 invoked from network); 4 Jan 2012 16:38:25 -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;
	4 Jan 2012 16:38:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9818723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:38: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, 4 Jan 2012 16:38:25 +0000
Date: Wed, 4 Jan 2012 16:38:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4EEE25DA.2080400@redhat.com>
Message-ID: <alpine.DEB.2.00.1201041618390.3150@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>
	<4EEE25DA.2080400@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Sun, 18 Dec 2011, Avi Kivity wrote:
> 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.

That is not an issue, the current code supports this case.


> 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()

I cannot see how this is going to fix the save/restore issue we are
trying to solve.
The problem, unfortunately very complex, is that at restore time the
videoram is already allocated at the physical address it was mapped
before the save operation. If it was not mapped, it is at the end of the
physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
allocate it).

So the issue is that the videoram appears to qemu as part of the
physical memory of the guest at an unknown address.

The proposal of introducing early_savevm would easily solve this last
problem: letting us know where the videoram is. The other problem, the
fact that under Xen the videoram would be already allocated while under
native it would not, remains unsolved. 
We cannot simply allocate the videoram twice because the operation
would fail (Xen would realize that we are trying to allocate more memory
than it we are supposed to, returning an error).
However, once we know where the videoram is, we could probably figure out
a smart (see hacky) way to avoid allocating it twice without changes to
the cirrus code.



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

Nope, a guest moving the cirrus BAR should work correctly even now.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:39:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:39:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiTrE-0000Za-KM; Wed, 04 Jan 2012 16:38:32 +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 1RiTrD-0000ZT-6O
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:38:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325695105!9695814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17411 invoked from network); 4 Jan 2012 16:38:25 -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;
	4 Jan 2012 16:38:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9818723"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:38: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, 4 Jan 2012 16:38:25 +0000
Date: Wed, 4 Jan 2012 16:38:09 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4EEE25DA.2080400@redhat.com>
Message-ID: <alpine.DEB.2.00.1201041618390.3150@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>
	<4EEE25DA.2080400@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Sun, 18 Dec 2011, Avi Kivity wrote:
> 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.

That is not an issue, the current code supports this case.


> 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()

I cannot see how this is going to fix the save/restore issue we are
trying to solve.
The problem, unfortunately very complex, is that at restore time the
videoram is already allocated at the physical address it was mapped
before the save operation. If it was not mapped, it is at the end of the
physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
allocate it).

So the issue is that the videoram appears to qemu as part of the
physical memory of the guest at an unknown address.

The proposal of introducing early_savevm would easily solve this last
problem: letting us know where the videoram is. The other problem, the
fact that under Xen the videoram would be already allocated while under
native it would not, remains unsolved. 
We cannot simply allocate the videoram twice because the operation
would fail (Xen would realize that we are trying to allocate more memory
than it we are supposed to, returning an error).
However, once we know where the videoram is, we could probably figure out
a smart (see hacky) way to avoid allocating it twice without changes to
the cirrus code.



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

Nope, a guest moving the cirrus BAR should work correctly even now.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:49:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16: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 1RiU1O-0000tN-TP; Wed, 04 Jan 2012 16:49:02 +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 1RiU1N-0000tI-08
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:49:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325695733!7812626!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MTUyOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14747 invoked from network); 4 Jan 2012 16:48:54 -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; 4 Jan 2012 16:48: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
	q04Gmm0i031623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 16:48:48 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
	q04Gmkmf013089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 16:48:47 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q04Gmjs7003082; Wed, 4 Jan 2012 10:48:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 08:48:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA48B40480; Wed,  4 Jan 2012 11:47:13 -0500 (EST)
Date: Wed, 4 Jan 2012 11:47:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120104164713.GA6294@phenom.dumpdata.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F0482F1.00B1,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
> 
> hypervisor:
> 
>       * ??? - Keir, Tim, Jan?

Mark ARM as experimental? Docs on how to compile it, use it?

> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * event handling (IanJ working on this)
>               * drop libxl_device_model_info (move bits to build_info or
>                 elsewhere as appropriate) (IanC working on this, patches
>                 shortly)
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (IanC working on
>                 this, patches shortly)
>               * The topologyinfo datastructure should be a list of
>                 tuples, not a tuple of lists. (nobody currently looking
>                 at this, not 100% sure this makes sense, could possibly
>                 defer and change after 4.2 in a compatible way)
>               * Block script support -- can be done post 4.2?
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? Roger Pau Monet was looking at this but its looking
>         like a big can-o-worms...
>       * Integrate qemu+seabios upstream into the build (Stefano has
>         posted patches, I guess they need refreshing and reposting). No
>         change in default qemu for 4.2.

Anthony's PCI passthrough patches?

>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.

> 
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?
> 
> 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 Jan 04 16:49:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16: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 1RiU1O-0000tN-TP; Wed, 04 Jan 2012 16:49:02 +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 1RiU1N-0000tI-08
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:49:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325695733!7812626!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MTUyOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14747 invoked from network); 4 Jan 2012 16:48:54 -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; 4 Jan 2012 16:48: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
	q04Gmm0i031623
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 16:48:48 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
	q04Gmkmf013089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 16:48:47 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q04Gmjs7003082; Wed, 4 Jan 2012 10:48:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 08:48:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA48B40480; Wed,  4 Jan 2012 11:47:13 -0500 (EST)
Date: Wed, 4 Jan 2012 11:47:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120104164713.GA6294@phenom.dumpdata.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F0482F1.00B1,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
> 
> hypervisor:
> 
>       * ??? - Keir, Tim, Jan?

Mark ARM as experimental? Docs on how to compile it, use it?

> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * event handling (IanJ working on this)
>               * drop libxl_device_model_info (move bits to build_info or
>                 elsewhere as appropriate) (IanC working on this, patches
>                 shortly)
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (IanC working on
>                 this, patches shortly)
>               * The topologyinfo datastructure should be a list of
>                 tuples, not a tuple of lists. (nobody currently looking
>                 at this, not 100% sure this makes sense, could possibly
>                 defer and change after 4.2 in a compatible way)
>               * Block script support -- can be done post 4.2?
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? Roger Pau Monet was looking at this but its looking
>         like a big can-o-worms...
>       * Integrate qemu+seabios upstream into the build (Stefano has
>         posted patches, I guess they need refreshing and reposting). No
>         change in default qemu for 4.2.

Anthony's PCI passthrough patches?

>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.

> 
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?
> 
> 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 Jan 04 16:50:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiU2c-0000xh-D5; Wed, 04 Jan 2012 16:50:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RiU2a-0000wq-3t
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:50:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1325695809!9728570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30820 invoked from network); 4 Jan 2012 16:50:10 -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;
	4 Jan 2012 16:50:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9819077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:50: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, 4 Jan 2012 16:50:08 +0000
Date: Wed, 4 Jan 2012 16:49:52 +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: <4F046A30.6000009@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
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>
	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 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 Wed, 4 Jan 2012, Daniel De Graaf wrote:
> On 01/04/2012 05:47 AM, Stefano Stabellini wrote:
> > On Thu, 15 Dec 2011, Daniel De Graaf wrote:
> >> 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.
> > 
> > It would be great to have a short introduction to flask in the xl man
> > page. What do you think about the following?
> > 
> > 
> > diff -r 50117a4d1a2c docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1	Mon Jan 02 12:43:07 2012 +0000
> > +++ b/docs/man/xl.pod.1	Wed Jan 04 10:46:47 2012 +0000
> > @@ -997,6 +997,20 @@ Get information about how much freeable 
> >  
> >  =head2 FLASK
> >  
> > +B<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.
> > +
> > +See the following document for more details:
> > +
> > +L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
> > +
> >  =over 4
> >  
> >  =item B<getenforce>
> > 
> > 
> > 
> > As you can see, I linked docs/misc/xsm-flask.txt from the xl man page,
> > however xsm-flask.txt still references xend so it needs to be updated.
> 
> This is a good introduction; I have an update to docs/misc/xsm-flask.txt
> that references xl and incorporates some of the changes in the example
> policy (will post momentarily).

Great, I'll send it as a separate patch.


> > Also it would be great to link the example policy too, but that one is
> > not online because it is not under docs and it is not installed by
> > default either. Maybe we need to move the example policy to docs? Or
> > maybe it is best to install a copy of it to /etc/xen by default?
>  
> The example policy doesn't really belong in docs because it needs to be
> compiled to be usable, and this depends on a number of other files (all
> files under tools/flask/policy/policy, to be exact). Compiling and
> installing FLASK policy during the normal build process (conditional on
> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
> would be the best solution. The policy must be installed to /boot, not
> /etc/xen, because the initial policy load happens prior to starting dom0.

Like Ian said, I meant having the policy somewhere online where can be
linked. However we only publish on xenbits what we have under docs ATM.
It is unfortunate that the policy needs FLASK_ENABLE to be compiled
because I am pretty sure that the automated build system that produces
the docs that end up online does not support that option right now.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:50:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:50:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiU2c-0000xh-D5; Wed, 04 Jan 2012 16:50:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RiU2a-0000wq-3t
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:50:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1325695809!9728570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30820 invoked from network); 4 Jan 2012 16:50:10 -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;
	4 Jan 2012 16:50:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9819077"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:50: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, 4 Jan 2012 16:50:08 +0000
Date: Wed, 4 Jan 2012 16:49:52 +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: <4F046A30.6000009@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
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>
	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 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 Wed, 4 Jan 2012, Daniel De Graaf wrote:
> On 01/04/2012 05:47 AM, Stefano Stabellini wrote:
> > On Thu, 15 Dec 2011, Daniel De Graaf wrote:
> >> 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.
> > 
> > It would be great to have a short introduction to flask in the xl man
> > page. What do you think about the following?
> > 
> > 
> > diff -r 50117a4d1a2c docs/man/xl.pod.1
> > --- a/docs/man/xl.pod.1	Mon Jan 02 12:43:07 2012 +0000
> > +++ b/docs/man/xl.pod.1	Wed Jan 04 10:46:47 2012 +0000
> > @@ -997,6 +997,20 @@ Get information about how much freeable 
> >  
> >  =head2 FLASK
> >  
> > +B<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.
> > +
> > +See the following document for more details:
> > +
> > +L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
> > +
> >  =over 4
> >  
> >  =item B<getenforce>
> > 
> > 
> > 
> > As you can see, I linked docs/misc/xsm-flask.txt from the xl man page,
> > however xsm-flask.txt still references xend so it needs to be updated.
> 
> This is a good introduction; I have an update to docs/misc/xsm-flask.txt
> that references xl and incorporates some of the changes in the example
> policy (will post momentarily).

Great, I'll send it as a separate patch.


> > Also it would be great to link the example policy too, but that one is
> > not online because it is not under docs and it is not installed by
> > default either. Maybe we need to move the example policy to docs? Or
> > maybe it is best to install a copy of it to /etc/xen by default?
>  
> The example policy doesn't really belong in docs because it needs to be
> compiled to be usable, and this depends on a number of other files (all
> files under tools/flask/policy/policy, to be exact). Compiling and
> installing FLASK policy during the normal build process (conditional on
> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
> would be the best solution. The policy must be installed to /boot, not
> /etc/xen, because the initial policy load happens prior to starting dom0.

Like Ian said, I meant having the policy somewhere online where can be
linked. However we only publish on xenbits what we have under docs ATM.
It is unfortunate that the policy needs FLASK_ENABLE to be compiled
because I am pretty sure that the automated build system that produces
the docs that end up online does not support that option right now.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:51:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:51:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiU3i-00013K-TK; Wed, 04 Jan 2012 16:51: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 1RiU3h-00012b-CO
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:51:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325695879!9717936!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3844 invoked from network); 4 Jan 2012 16:51: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;
	4 Jan 2012 16:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9819107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:51: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, 4 Jan 2012 16:51:19 +0000
Date: Wed, 4 Jan 2012 16:51:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120104164713.GA6294@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201041650300.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104164713.GA6294@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > What are the outstanding things to do before we think we can start on
> > the 4.2 -rc's? Does anyone have a timetable in mind?
> > 
> > hypervisor:
> > 
> >       * ??? - Keir, Tim, Jan?
> 
> Mark ARM as experimental? Docs on how to compile it, use it?
> 
> > 
> > tools:
> > 
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> >               * event handling (IanJ working on this)
> >               * drop libxl_device_model_info (move bits to build_info or
> >                 elsewhere as appropriate) (IanC working on this, patches
> >                 shortly)
> >               * add libxl_defbool and generally try and arrange that
> >                 memset(foo,0,...) requests the defaults (IanC working on
> >                 this, patches shortly)
> >               * The topologyinfo datastructure should be a list of
> >                 tuples, not a tuple of lists. (nobody currently looking
> >                 at this, not 100% sure this makes sense, could possibly
> >                 defer and change after 4.2 in a compatible way)
> >               * Block script support -- can be done post 4.2?
> >       * Hotplug script stuff -- internal to libxl (I think, therefore I
> >         didn't put this under stable API above) but still good to have
> >         for 4.2? Roger Pau Monet was looking at this but its looking
> >         like a big can-o-worms...
> >       * Integrate qemu+seabios upstream into the build (Stefano has
> >         posted patches, I guess they need refreshing and reposting). No
> >         change in default qemu for 4.2.
> 
> Anthony's PCI passthrough patches?

Right. And Anthony's save/restore patches as well.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:51:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:51:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiU3i-00013K-TK; Wed, 04 Jan 2012 16:51: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 1RiU3h-00012b-CO
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:51:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325695879!9717936!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3844 invoked from network); 4 Jan 2012 16:51: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;
	4 Jan 2012 16:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9819107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:51: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, 4 Jan 2012 16:51:19 +0000
Date: Wed, 4 Jan 2012 16:51:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120104164713.GA6294@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201041650300.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104164713.GA6294@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > What are the outstanding things to do before we think we can start on
> > the 4.2 -rc's? Does anyone have a timetable in mind?
> > 
> > hypervisor:
> > 
> >       * ??? - Keir, Tim, Jan?
> 
> Mark ARM as experimental? Docs on how to compile it, use it?
> 
> > 
> > tools:
> > 
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> >               * event handling (IanJ working on this)
> >               * drop libxl_device_model_info (move bits to build_info or
> >                 elsewhere as appropriate) (IanC working on this, patches
> >                 shortly)
> >               * add libxl_defbool and generally try and arrange that
> >                 memset(foo,0,...) requests the defaults (IanC working on
> >                 this, patches shortly)
> >               * The topologyinfo datastructure should be a list of
> >                 tuples, not a tuple of lists. (nobody currently looking
> >                 at this, not 100% sure this makes sense, could possibly
> >                 defer and change after 4.2 in a compatible way)
> >               * Block script support -- can be done post 4.2?
> >       * Hotplug script stuff -- internal to libxl (I think, therefore I
> >         didn't put this under stable API above) but still good to have
> >         for 4.2? Roger Pau Monet was looking at this but its looking
> >         like a big can-o-worms...
> >       * Integrate qemu+seabios upstream into the build (Stefano has
> >         posted patches, I guess they need refreshing and reposting). No
> >         change in default qemu for 4.2.
> 
> Anthony's PCI passthrough patches?

Right. And Anthony's save/restore patches as well.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:52:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiU4O-00019B-W0; Wed, 04 Jan 2012 16:52:08 +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 1RiU4N-00018o-N3
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:52:07 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325695877!51244749!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNTkzNTI=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21661 invoked from network); 4 Jan 2012 16:51:18 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-3.tower-27.messagelabs.com with SMTP;
	4 Jan 2012 16:51:18 -0000
Received: (qmail invoked by alias); 04 Jan 2012 16:52:05 -0000
Received: from dslb-088-069-058-150.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.58.150]
	by mail.gmx.net (mp027) with SMTP; 04 Jan 2012 17:52:05 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX19P6bkA2DJPpYRQvy5zx/OtyU67yDVzDovDc/ATu4
	cPjLEnEJ8TNf7c
Message-ID: <4F048368.2000204@gmx.de>
Date: Wed, 04 Jan 2012 17:50:48 +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: <4F047035.1060304@amd.com>
In-Reply-To: <4F047035.1060304@amd.com>
X-Enigmail-Version: 1.3.3
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] Xen 4.1: x86/ucode: fix for AMD Fam15 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: multipart/mixed; boundary="===============4707532076323879453=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============4707532076323879453==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070701060800020305000202"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms070701060800020305000202
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Am 04.01.2012 16:28, schrieb Christoph Egger:
>=20
> x86/ucode: fix for AMD Fam15 CPUs
>=20
> Remove hardcoded maximum size a microcode patch can have. This is
> dynamic now.
>=20
> The microcode patch for family15h can be larger than 2048 bytes and
> gets silently truncated.
>=20
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1
>=20
Could this fix my xen boot problem on athlon x2 (fam 15 according to
cpuinfo)

See xen-devel post:
[Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64 X2
from 22.12.2011 ff

Regards,
Florian

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



--------------ms070701060800020305000202
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwNDE2NTA0OVow
IwYJKoZIhvcNAQkEMRYEFCSMqUr+WXrWh5brR+e5BC4nc+BUMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAFYjnrzLpHtWsNA7vTUuWKyoyoVEPam0Adn/9sKTwewgMx9AC
IfrFpJz/SzDD0r0qRtvHrpD+5lWHPhMyxprC/3iRLP8BidKaUpgjQ3LICwajMeunSp4rv+Bo
dsPjUC3zgI/p8F4egFwD5zdm+bP3bRF32DYF/NCjTBSnpts/QenhHhk26Y3X2lawJIGVEI9T
IJkqvvLpqGPDb36hqKXimxyR++4JhzhtX/4M4snEO/r0GsjDsUTB8tsgZ2cKtngcwiUo6iGK
kpLPBM4LNfQBUxHfUIgcOGRWo/QvHJIjW5m6IeQ9K3jFEdfpWxwsZ8TBQp6W0tk90nSUrg3M
KSqz4wAAAAAAAA==
--------------ms070701060800020305000202--


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

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

--===============4707532076323879453==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:52:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiU4O-00019B-W0; Wed, 04 Jan 2012 16:52:08 +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 1RiU4N-00018o-N3
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:52:07 +0000
X-Env-Sender: florianmanschwetus@gmx.de
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325695877!51244749!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNTkzNTI=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21661 invoked from network); 4 Jan 2012 16:51:18 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-3.tower-27.messagelabs.com with SMTP;
	4 Jan 2012 16:51:18 -0000
Received: (qmail invoked by alias); 04 Jan 2012 16:52:05 -0000
Received: from dslb-088-069-058-150.pools.arcor-ip.net (EHLO [192.168.222.23])
	[88.69.58.150]
	by mail.gmx.net (mp027) with SMTP; 04 Jan 2012 17:52:05 +0100
X-Authenticated: #7518697
X-Provags-ID: V01U2FsdGVkX19P6bkA2DJPpYRQvy5zx/OtyU67yDVzDovDc/ATu4
	cPjLEnEJ8TNf7c
Message-ID: <4F048368.2000204@gmx.de>
Date: Wed, 04 Jan 2012 17:50:48 +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: <4F047035.1060304@amd.com>
In-Reply-To: <4F047035.1060304@amd.com>
X-Enigmail-Version: 1.3.3
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] Xen 4.1: x86/ucode: fix for AMD Fam15 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: multipart/mixed; boundary="===============4707532076323879453=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--===============4707532076323879453==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070701060800020305000202"

Dies ist eine kryptografisch unterzeichnete Nachricht im MIME-Format.

--------------ms070701060800020305000202
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Am 04.01.2012 16:28, schrieb Christoph Egger:
>=20
> x86/ucode: fix for AMD Fam15 CPUs
>=20
> Remove hardcoded maximum size a microcode patch can have. This is
> dynamic now.
>=20
> The microcode patch for family15h can be larger than 2048 bytes and
> gets silently truncated.
>=20
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1
>=20
Could this fix my xen boot problem on athlon x2 (fam 15 according to
cpuinfo)

See xen-devel post:
[Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64 X2
from 22.12.2011 ff

Regards,
Florian

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



--------------ms070701060800020305000202
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDEwNDE2NTA0OVow
IwYJKoZIhvcNAQkEMRYEFCSMqUr+WXrWh5brR+e5BC4nc+BUMF8GCSqGSIb3DQEJDzFSMFAw
CwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMIcxMwgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0Ex
HjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWdu
aW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMIcxMw
DQYJKoZIhvcNAQEBBQAEggEAFYjnrzLpHtWsNA7vTUuWKyoyoVEPam0Adn/9sKTwewgMx9AC
IfrFpJz/SzDD0r0qRtvHrpD+5lWHPhMyxprC/3iRLP8BidKaUpgjQ3LICwajMeunSp4rv+Bo
dsPjUC3zgI/p8F4egFwD5zdm+bP3bRF32DYF/NCjTBSnpts/QenhHhk26Y3X2lawJIGVEI9T
IJkqvvLpqGPDb36hqKXimxyR++4JhzhtX/4M4snEO/r0GsjDsUTB8tsgZ2cKtngcwiUo6iGK
kpLPBM4LNfQBUxHfUIgcOGRWo/QvHJIjW5m6IeQ9K3jFEdfpWxwsZ8TBQp6W0tk90nSUrg3M
KSqz4wAAAAAAAA==
--------------ms070701060800020305000202--


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

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

--===============4707532076323879453==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:52:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiU4E-00017I-I1; Wed, 04 Jan 2012 16:51:58 +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 1RiU4C-00016a-Bb
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:51:56 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325695877!47104686!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 28228 invoked from network); 4 Jan 2012 16:51:17 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-27.messagelabs.com with SMTP;
	4 Jan 2012 16:51:17 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74287756; Wed, 04 Jan 2012 17:51:49 +0100
Message-ID: <1325695886.2633.5.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Keir Fraser <keir@xen.org>
Date: Wed, 04 Jan 2012 17:51:26 +0100
In-Reply-To: <CB2A2B23.36D68%keir@xen.org>
References: <CB2A2B23.36D68%keir@xen.org>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
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>,
	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: multipart/mixed; boundary="===============6864252991091932441=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6864252991091932441==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-yDRxbvS5GTrwd1WeVSg9"


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

On Wed, 2012-01-04 at 16:13 +0000, Keir Fraser wrote:
> > So... Should I do something else or can this be checked-in? :-)
>=20
> Done. And your other one too.
>=20
Ok then.

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)


--=-yDRxbvS5GTrwd1WeVSg9
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)

iEUEABECAAYFAk8Eg44ACgkQk4XaBE3IOsTP4gCfX1PX+96m2pJSBacYSRDQ/G4m
OpUAmLvyLBD3ta06e63PNJA3ngBPgGk=
=8XrU
-----END PGP SIGNATURE-----

--=-yDRxbvS5GTrwd1WeVSg9--



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

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

--===============6864252991091932441==--



From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:52:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16:52:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiU4E-00017I-I1; Wed, 04 Jan 2012 16:51:58 +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 1RiU4C-00016a-Bb
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:51:56 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325695877!47104686!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 28228 invoked from network); 4 Jan 2012 16:51:17 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-27.messagelabs.com with SMTP;
	4 Jan 2012 16:51:17 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74287756; Wed, 04 Jan 2012 17:51:49 +0100
Message-ID: <1325695886.2633.5.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Keir Fraser <keir@xen.org>
Date: Wed, 04 Jan 2012 17:51:26 +0100
In-Reply-To: <CB2A2B23.36D68%keir@xen.org>
References: <CB2A2B23.36D68%keir@xen.org>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
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>,
	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: multipart/mixed; boundary="===============6864252991091932441=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6864252991091932441==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-yDRxbvS5GTrwd1WeVSg9"


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

On Wed, 2012-01-04 at 16:13 +0000, Keir Fraser wrote:
> > So... Should I do something else or can this be checked-in? :-)
>=20
> Done. And your other one too.
>=20
Ok then.

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)


--=-yDRxbvS5GTrwd1WeVSg9
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)

iEUEABECAAYFAk8Eg44ACgkQk4XaBE3IOsTP4gCfX1PX+96m2pJSBacYSRDQ/G4m
OpUAmLvyLBD3ta06e63PNJA3ngBPgGk=
=8XrU
-----END PGP SIGNATURE-----

--=-yDRxbvS5GTrwd1WeVSg9--



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

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

--===============6864252991091932441==--



From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:54:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiU6r-0001Vw-LJ; Wed, 04 Jan 2012 16:54: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 1RiU6q-0001VZ-5h
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:54:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325696031!48942713!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 28412 invoked from network); 4 Jan 2012 16:53:51 -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; 4 Jan 2012 16:53:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Jan 2012 16:54:35 +0000
Message-Id: <4F049293020000780006A6FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Jan 2012 16:55:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
> 
> hypervisor:
> 
>       * ??? - Keir, Tim, Jan?

Apart from a few small things that I have on my todo list, the only
bigger one (at least from an possible impact perspective) is the
round-up of the closing of the security hole in MSI-X passthrough
(uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
table pages), which I intended to do only once the upstream qemu
patch series also incorporates the respective recent qemu-xen
change.

Jan


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:54:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiU6r-0001Vw-LJ; Wed, 04 Jan 2012 16:54: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 1RiU6q-0001VZ-5h
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:54:40 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325696031!48942713!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 28412 invoked from network); 4 Jan 2012 16:53:51 -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; 4 Jan 2012 16:53:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 04 Jan 2012 16:54:35 +0000
Message-Id: <4F049293020000780006A6FE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 04 Jan 2012 16:55:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
> 
> hypervisor:
> 
>       * ??? - Keir, Tim, Jan?

Apart from a few small things that I have on my todo list, the only
bigger one (at least from an possible impact perspective) is the
round-up of the closing of the security hole in MSI-X passthrough
(uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
table pages), which I intended to do only once the upstream qemu
patch series also incorporates the respective recent qemu-xen
change.

Jan


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 16:55:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16: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 1RiU77-0001YQ-2a; Wed, 04 Jan 2012 16:54: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 1RiU75-0001Y2-G6
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:54:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325696051!50896184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22106 invoked from network); 4 Jan 2012 16:54:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 16:54:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9819174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:54: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, 4 Jan 2012
	16:54:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 4 Jan 2012 16:54:54 +0000
In-Reply-To: <alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
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>	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325696094.25206.321.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"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 Wed, 2012-01-04 at 16:49 +0000, Stefano Stabellini wrote:
> On Wed, 4 Jan 2012, Daniel De Graaf wrote:
> > The example policy doesn't really belong in docs because it needs to be
> > compiled to be usable, and this depends on a number of other files (all
> > files under tools/flask/policy/policy, to be exact). Compiling and
> > installing FLASK policy during the normal build process (conditional on
> > FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
> > would be the best solution. The policy must be installed to /boot, not
> > /etc/xen, because the initial policy load happens prior to starting dom0.
> 
> Like Ian said, I meant having the policy somewhere online where can be
> linked. However we only publish on xenbits what we have under docs ATM.
> It is unfortunate that the policy needs FLASK_ENABLE to be compiled
> because I am pretty sure that the automated build system that produces
> the docs that end up online does not support that option right now.

Publishing the docs in this manner wouldn't require FLASK_ENABLE since
it doesn't need any tools, just "cp". Unless I've totally got the wrong
end of the stick and the policy needs processing before you can even
usefully read 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 Jan 04 16:55:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 16: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 1RiU77-0001YQ-2a; Wed, 04 Jan 2012 16:54: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 1RiU75-0001Y2-G6
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 16:54:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325696051!50896184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22106 invoked from network); 4 Jan 2012 16:54:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 16:54:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9819174"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 16:54: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, 4 Jan 2012
	16:54:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed, 4 Jan 2012 16:54:54 +0000
In-Reply-To: <alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
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>	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325696094.25206.321.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"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 Wed, 2012-01-04 at 16:49 +0000, Stefano Stabellini wrote:
> On Wed, 4 Jan 2012, Daniel De Graaf wrote:
> > The example policy doesn't really belong in docs because it needs to be
> > compiled to be usable, and this depends on a number of other files (all
> > files under tools/flask/policy/policy, to be exact). Compiling and
> > installing FLASK policy during the normal build process (conditional on
> > FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
> > would be the best solution. The policy must be installed to /boot, not
> > /etc/xen, because the initial policy load happens prior to starting dom0.
> 
> Like Ian said, I meant having the policy somewhere online where can be
> linked. However we only publish on xenbits what we have under docs ATM.
> It is unfortunate that the policy needs FLASK_ENABLE to be compiled
> because I am pretty sure that the automated build system that produces
> the docs that end up online does not support that option right now.

Publishing the docs in this manner wouldn't require FLASK_ENABLE since
it doesn't need any tools, just "cp". Unless I've totally got the wrong
end of the stick and the policy needs processing before you can even
usefully read 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 Jan 04 17:24:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUYy-0002B9-MY; Wed, 04 Jan 2012 17:23:44 +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 1RiUYx-0002B4-RH
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:23:44 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325697816!9115455!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22187 invoked from network); 4 Jan 2012 17:23:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	4 Jan 2012 17:23:37 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q04HNVhQ027520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 12:23:31 -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 q04HNS1E027753; Wed, 4 Jan 2012 12:23:29 -0500
Message-ID: <4F048B10.1060505@redhat.com>
Date: Wed, 04 Jan 2012 19:23:28 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
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 01/04/2012 06:38 PM, Stefano Stabellini wrote:
>
> > 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()
>
> I cannot see how this is going to fix the save/restore issue we are
> trying to solve.
> The problem, unfortunately very complex, is that at restore time the
> videoram is already allocated at the physical address it was mapped
> before the save operation. If it was not mapped, it is at the end of the
> physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
> allocate it).

Sorry, I don't follow, please be specific as to which type of address
you're referring to:

ram_addr?
physical address (as seen by guest - but if it is not mapped, what does
your last sentence mean?)
something else?

> So the issue is that the videoram appears to qemu as part of the
> physical memory of the guest at an unknown address.
>
> The proposal of introducing early_savevm would easily solve this last
> problem: letting us know where the videoram is. The other problem, the
> fact that under Xen the videoram would be already allocated while under
> native it would not, remains unsolved. 
> We cannot simply allocate the videoram twice because the operation
> would fail (Xen would realize that we are trying to allocate more memory
> than it we are supposed to, returning an error).
> However, once we know where the videoram is, we could probably figure out
> a smart (see hacky) way to avoid allocating it twice without changes to
> the cirrus code.

I'm missing some context.  Can you please explain in more detail?

Note that with the memory API changes, ram addresses are going away. 
There will not be a linear space for guest RAM.  We'll have
(MemoryRegion *, offset) pairs that will be mapped into discontiguous
guest physical address ranges (perhaps with overlaps).

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


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:24:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUYy-0002B9-MY; Wed, 04 Jan 2012 17:23:44 +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 1RiUYx-0002B4-RH
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:23:44 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325697816!9115455!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22187 invoked from network); 4 Jan 2012 17:23:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	4 Jan 2012 17:23:37 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q04HNVhQ027520
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 12:23:31 -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 q04HNS1E027753; Wed, 4 Jan 2012 12:23:29 -0500
Message-ID: <4F048B10.1060505@redhat.com>
Date: Wed, 04 Jan 2012 19:23:28 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
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 01/04/2012 06:38 PM, Stefano Stabellini wrote:
>
> > 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()
>
> I cannot see how this is going to fix the save/restore issue we are
> trying to solve.
> The problem, unfortunately very complex, is that at restore time the
> videoram is already allocated at the physical address it was mapped
> before the save operation. If it was not mapped, it is at the end of the
> physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
> allocate it).

Sorry, I don't follow, please be specific as to which type of address
you're referring to:

ram_addr?
physical address (as seen by guest - but if it is not mapped, what does
your last sentence mean?)
something else?

> So the issue is that the videoram appears to qemu as part of the
> physical memory of the guest at an unknown address.
>
> The proposal of introducing early_savevm would easily solve this last
> problem: letting us know where the videoram is. The other problem, the
> fact that under Xen the videoram would be already allocated while under
> native it would not, remains unsolved. 
> We cannot simply allocate the videoram twice because the operation
> would fail (Xen would realize that we are trying to allocate more memory
> than it we are supposed to, returning an error).
> However, once we know where the videoram is, we could probably figure out
> a smart (see hacky) way to avoid allocating it twice without changes to
> the cirrus code.

I'm missing some context.  Can you please explain in more detail?

Note that with the memory API changes, ram addresses are going away. 
There will not be a linear space for guest RAM.  We'll have
(MemoryRegion *, offset) pairs that will be mapped into discontiguous
guest physical address ranges (perhaps with overlaps).

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


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUZ7-0002BP-3d; Wed, 04 Jan 2012 17:23:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joy@entuzijast.net>) id 1RiUZ5-0002BG-GF
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:23:51 +0000
X-Env-Sender: joy@entuzijast.net
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325697824!9720205!1
X-Originating-IP: [161.53.160.90]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22122 invoked from network); 4 Jan 2012 17:23:45 -0000
Received: from orion.carnet.hr (HELO orion.carnet.hr) (161.53.160.90)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 17:23:45 -0000
Received: from joy by orion.carnet.hr with local (Exim 4.72)
	(envelope-from <joy@entuzijast.net>) id 1RiUYx-0008Ka-6Q
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:23:43 +0100
Date: Wed, 4 Jan 2012 18:23:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <20120104172343.GA30630@entuzijast.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
From: Josip Rodin <joy@entuzijast.net>
X-SA-Exim-Connect-IP: <locally generated>
Subject: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

Sometimes, seemingly randomly, long-running Xen domains, using clocksource
xen, have their clock shift by ~3000 or ~36000 seconds, often with the dom0
complaining about clocksource tsc. The number changes if the hypervisor is
explicitly told to use clocksource=pit, but it still happens. It doesn't
seem to be particularly hardware-specific.

See also http://bugs.debian.org/599161

I see from the archives that others have reported this problem here in
February last year, but I couldn't find a resolution. Can anyone help?

(Please Cc: responses, I'm not subscribed.)

-- 
     2. That which causes joy or happiness.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUZ7-0002BP-3d; Wed, 04 Jan 2012 17:23:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joy@entuzijast.net>) id 1RiUZ5-0002BG-GF
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:23:51 +0000
X-Env-Sender: joy@entuzijast.net
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325697824!9720205!1
X-Originating-IP: [161.53.160.90]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22122 invoked from network); 4 Jan 2012 17:23:45 -0000
Received: from orion.carnet.hr (HELO orion.carnet.hr) (161.53.160.90)
	by server-7.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 17:23:45 -0000
Received: from joy by orion.carnet.hr with local (Exim 4.72)
	(envelope-from <joy@entuzijast.net>) id 1RiUYx-0008Ka-6Q
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:23:43 +0100
Date: Wed, 4 Jan 2012 18:23:43 +0100
To: xen-devel@lists.xensource.com
Message-ID: <20120104172343.GA30630@entuzijast.net>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
From: Josip Rodin <joy@entuzijast.net>
X-SA-Exim-Connect-IP: <locally generated>
Subject: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

Sometimes, seemingly randomly, long-running Xen domains, using clocksource
xen, have their clock shift by ~3000 or ~36000 seconds, often with the dom0
complaining about clocksource tsc. The number changes if the hypervisor is
explicitly told to use clocksource=pit, but it still happens. It doesn't
seem to be particularly hardware-specific.

See also http://bugs.debian.org/599161

I see from the archives that others have reported this problem here in
February last year, but I couldn't find a resolution. Can anyone help?

(Please Cc: responses, I'm not subscribed.)

-- 
     2. That which causes joy or happiness.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUag-0002Ii-K3; Wed, 04 Jan 2012 17:25:30 +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 1RiUaf-0002ID-EP
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:25:29 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325697921!10381022!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTUwNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 910 invoked from network); 4 Jan 2012 17:25:22 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 17:25:22 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 3FE431CEA;
	Wed,  4 Jan 2012 19:25:20 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 14D9E20056; Wed,  4 Jan 2012 19:25:20 +0200 (EET)
Date: Wed, 4 Jan 2012 19:25:19 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120104172519.GS12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
> 
> hypervisor:
> 
>       * ??? - Keir, Tim, Jan?
> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * event handling (IanJ working on this)
>               * drop libxl_device_model_info (move bits to build_info or
>                 elsewhere as appropriate) (IanC working on this, patches
>                 shortly)
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (IanC working on
>                 this, patches shortly)
>               * The topologyinfo datastructure should be a list of
>                 tuples, not a tuple of lists. (nobody currently looking
>                 at this, not 100% sure this makes sense, could possibly
>                 defer and change after 4.2 in a compatible way)
>               * Block script support -- can be done post 4.2?
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? Roger Pau Monet was looking at this but its looking
>         like a big can-o-worms...
>       * Integrate qemu+seabios upstream into the build (Stefano has
>         posted patches, I guess they need refreshing and reposting). No
>         change in default qemu for 4.2.
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
> 
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?
> 

- What's the status of Nested Hardware Virtualization? 
I remember some email saying Intel vmx-on-vmx has some performance issues,
and amd svm-on-svm works better..


- Also there's a bunch of VGA passthru related patches,
that I once volunteered to collect/rebase/cleanup/repost myself,
but I still haven't had time for that :(


-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUag-0002Ii-K3; Wed, 04 Jan 2012 17:25:30 +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 1RiUaf-0002ID-EP
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:25:29 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325697921!10381022!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTUwNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 910 invoked from network); 4 Jan 2012 17:25:22 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 17:25:22 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 3FE431CEA;
	Wed,  4 Jan 2012 19:25:20 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 14D9E20056; Wed,  4 Jan 2012 19:25:20 +0200 (EET)
Date: Wed, 4 Jan 2012 19:25:19 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120104172519.GS12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
> 
> hypervisor:
> 
>       * ??? - Keir, Tim, Jan?
> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * event handling (IanJ working on this)
>               * drop libxl_device_model_info (move bits to build_info or
>                 elsewhere as appropriate) (IanC working on this, patches
>                 shortly)
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (IanC working on
>                 this, patches shortly)
>               * The topologyinfo datastructure should be a list of
>                 tuples, not a tuple of lists. (nobody currently looking
>                 at this, not 100% sure this makes sense, could possibly
>                 defer and change after 4.2 in a compatible way)
>               * Block script support -- can be done post 4.2?
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? Roger Pau Monet was looking at this but its looking
>         like a big can-o-worms...
>       * Integrate qemu+seabios upstream into the build (Stefano has
>         posted patches, I guess they need refreshing and reposting). No
>         change in default qemu for 4.2.
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
> 
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?
> 

- What's the status of Nested Hardware Virtualization? 
I remember some email saying Intel vmx-on-vmx has some performance issues,
and amd svm-on-svm works better..


- Also there's a bunch of VGA passthru related patches,
that I once volunteered to collect/rebase/cleanup/repost myself,
but I still haven't had time for that :(


-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:37:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUlX-0002hM-QS; Wed, 04 Jan 2012 17:36:43 +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 1RiUlW-0002hH-5z
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:36:42 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325698566!47109386!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 8702 invoked from network); 4 Jan 2012 17:36:07 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 17:36:07 -0000
Received: by iagw33 with SMTP id w33so153331975iag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 09:36:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=UeBwGQY4iwyhcG1LjLJiCk+nVLbhzILnQTR/f4jLjRM=;
	b=U82hoZErPmA7kMtdYKyuk9fuGdcLz7PDzwCRygUpuFyTBsUx2w+XHtt4H2nfiBYpmg
	al1dH7C4ZmrNQVl2SaXpOS/wlOGNxRTZO7yVB6joqEo+dUUXZ9ulYZnMXJCc1k283jr7
	eIKXUMD+d8fDr0LoInbURDH5y+eFBTLo4HLkU=
MIME-Version: 1.0
Received: by 10.50.6.233 with SMTP id e9mr68150546iga.17.1325698599402; Wed,
	04 Jan 2012 09:36:39 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 4 Jan 2012 09:36:39 -0800 (PST)
In-Reply-To: <20120104172519.GS12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
Date: Wed, 4 Jan 2012 12:36:39 -0500
X-Google-Sender-Auth: QucWYkAI7YBdzGqz-5FtqM55nvg
Message-ID: <CAFLBxZZv3bLmJjozv2zhYjf8g1Nj6-uFh62p8MYGvkSme+qCxQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 4, 2012 at 12:25 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
>> What are the outstanding things to do before we think we can start on
>> the 4.2 -rc's? Does anyone have a timetable in mind?
>>
>> hypervisor:
>>
>> =A0 =A0 =A0 * ??? - Keir, Tim, Jan?

It would be good to have domctls / sysctls set up to modify scheduler
parameters, like the credit1 timeslice (and schedule rate, if that
ever makes it in).

 -George

>>
>> tools:
>>
>> =A0 =A0 =A0 * libxl stable API -- we would like 4.2 to define a stable A=
PI
>> =A0 =A0 =A0 =A0 which downstream's can start to rely on not changing. As=
pects of
>> =A0 =A0 =A0 =A0 this are:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * event handling (IanJ working on this)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * drop libxl_device_model_info (move bits to=
 build_info or
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elsewhere as appropriate) (IanC working =
on this, patches
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 shortly)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * add libxl_defbool and generally try and ar=
range that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 memset(foo,0,...) requests the defaults =
(IanC working on
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this, patches shortly)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * The topologyinfo datastructure should be a=
 list of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tuples, not a tuple of lists. (nobody cu=
rrently looking
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at this, not 100% sure this makes sense,=
 could possibly
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 defer and change after 4.2 in a compatib=
le way)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Block script support -- can be done post 4=
.2?
>> =A0 =A0 =A0 * Hotplug script stuff -- internal to libxl (I think, theref=
ore I
>> =A0 =A0 =A0 =A0 didn't put this under stable API above) but still good t=
o have
>> =A0 =A0 =A0 =A0 for 4.2? Roger Pau Monet was looking at this but its loo=
king
>> =A0 =A0 =A0 =A0 like a big can-o-worms...
>> =A0 =A0 =A0 * Integrate qemu+seabios upstream into the build (Stefano has
>> =A0 =A0 =A0 =A0 posted patches, I guess they need refreshing and reposti=
ng). No
>> =A0 =A0 =A0 =A0 change in default qemu for 4.2.
>> =A0 =A0 =A0 * More formally deprecate xm/xend. Manpage patches already in
>> =A0 =A0 =A0 =A0 tree. Needs release noting and communication around -rc1=
 to
>> =A0 =A0 =A0 =A0 remind people to test xl.
>>
>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>> must haves e.g. in the paging/sharing spaces?
>>
>
> - What's the status of Nested Hardware Virtualization?
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..
>
>
> - Also there's a bunch of VGA passthru related patches,
> that I once volunteered to collect/rebase/cleanup/repost myself,
> but I still haven't had time for that :(
>
>
> -- 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 Jan 04 17:37:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUlX-0002hM-QS; Wed, 04 Jan 2012 17:36:43 +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 1RiUlW-0002hH-5z
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:36:42 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325698566!47109386!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 8702 invoked from network); 4 Jan 2012 17:36:07 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 17:36:07 -0000
Received: by iagw33 with SMTP id w33so153331975iag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 09:36:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=UeBwGQY4iwyhcG1LjLJiCk+nVLbhzILnQTR/f4jLjRM=;
	b=U82hoZErPmA7kMtdYKyuk9fuGdcLz7PDzwCRygUpuFyTBsUx2w+XHtt4H2nfiBYpmg
	al1dH7C4ZmrNQVl2SaXpOS/wlOGNxRTZO7yVB6joqEo+dUUXZ9ulYZnMXJCc1k283jr7
	eIKXUMD+d8fDr0LoInbURDH5y+eFBTLo4HLkU=
MIME-Version: 1.0
Received: by 10.50.6.233 with SMTP id e9mr68150546iga.17.1325698599402; Wed,
	04 Jan 2012 09:36:39 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 4 Jan 2012 09:36:39 -0800 (PST)
In-Reply-To: <20120104172519.GS12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
Date: Wed, 4 Jan 2012 12:36:39 -0500
X-Google-Sender-Auth: QucWYkAI7YBdzGqz-5FtqM55nvg
Message-ID: <CAFLBxZZv3bLmJjozv2zhYjf8g1Nj6-uFh62p8MYGvkSme+qCxQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 4, 2012 at 12:25 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
>> What are the outstanding things to do before we think we can start on
>> the 4.2 -rc's? Does anyone have a timetable in mind?
>>
>> hypervisor:
>>
>> =A0 =A0 =A0 * ??? - Keir, Tim, Jan?

It would be good to have domctls / sysctls set up to modify scheduler
parameters, like the credit1 timeslice (and schedule rate, if that
ever makes it in).

 -George

>>
>> tools:
>>
>> =A0 =A0 =A0 * libxl stable API -- we would like 4.2 to define a stable A=
PI
>> =A0 =A0 =A0 =A0 which downstream's can start to rely on not changing. As=
pects of
>> =A0 =A0 =A0 =A0 this are:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * event handling (IanJ working on this)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * drop libxl_device_model_info (move bits to=
 build_info or
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elsewhere as appropriate) (IanC working =
on this, patches
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 shortly)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * add libxl_defbool and generally try and ar=
range that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 memset(foo,0,...) requests the defaults =
(IanC working on
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this, patches shortly)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * The topologyinfo datastructure should be a=
 list of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tuples, not a tuple of lists. (nobody cu=
rrently looking
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 at this, not 100% sure this makes sense,=
 could possibly
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 defer and change after 4.2 in a compatib=
le way)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Block script support -- can be done post 4=
.2?
>> =A0 =A0 =A0 * Hotplug script stuff -- internal to libxl (I think, theref=
ore I
>> =A0 =A0 =A0 =A0 didn't put this under stable API above) but still good t=
o have
>> =A0 =A0 =A0 =A0 for 4.2? Roger Pau Monet was looking at this but its loo=
king
>> =A0 =A0 =A0 =A0 like a big can-o-worms...
>> =A0 =A0 =A0 * Integrate qemu+seabios upstream into the build (Stefano has
>> =A0 =A0 =A0 =A0 posted patches, I guess they need refreshing and reposti=
ng). No
>> =A0 =A0 =A0 =A0 change in default qemu for 4.2.
>> =A0 =A0 =A0 * More formally deprecate xm/xend. Manpage patches already in
>> =A0 =A0 =A0 =A0 tree. Needs release noting and communication around -rc1=
 to
>> =A0 =A0 =A0 =A0 remind people to test xl.
>>
>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>> must haves e.g. in the paging/sharing spaces?
>>
>
> - What's the status of Nested Hardware Virtualization?
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..
>
>
> - Also there's a bunch of VGA passthru related patches,
> that I once volunteered to collect/rebase/cleanup/repost myself,
> but I still haven't had time for that :(
>
>
> -- 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 Jan 04 17:40:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUoT-0002pF-Jl; Wed, 04 Jan 2012 17:39:45 +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 1RiUoR-0002p8-Rw
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:39:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325698775!9702143!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 26017 invoked from network); 4 Jan 2012 17:39:37 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 17:39:37 -0000
Received: by daec6 with SMTP id c6so64751048dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 09:39: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=W4aenCEt3nGn0TmcHuGQ1z8ebOltwJnQHm2xvgGTkw0=;
	b=Ke2aNVfKqAdgXpxwNA4vIefBY7d7pFw1Rwmr1GfozrDSBwVot89KqJVYYnASsId4eu
	6QAu8KWnSAYCNG2SB6d5fqdLma0HuFeIHWkksZQwGnr8YpXGKRT4GBv90svZTaNhAgFK
	acKx3RozpoJ5i6uIBpWCQul5SzicwfrY9KV2M=
MIME-Version: 1.0
Received: by 10.68.213.6 with SMTP id no6mr2139013pbc.94.1325698775277; Wed,
	04 Jan 2012 09:39:35 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 4 Jan 2012 09:39:35 -0800 (PST)
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
Date: Wed, 4 Jan 2012 18:39:35 +0100
X-Google-Sender-Auth: ZsHA0zC-VkZI65-oOiUn7YjJxbM
Message-ID: <CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzQgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gV2hhdCBh
cmUgdGhlIG91dHN0YW5kaW5nIHRoaW5ncyB0byBkbyBiZWZvcmUgd2UgdGhpbmsgd2UgY2FuIHN0
YXJ0IG9uCj4gdGhlIDQuMiAtcmMncz8gRG9lcyBhbnlvbmUgaGF2ZSBhIHRpbWV0YWJsZSBpbiBt
aW5kPwo+Cj4gaHlwZXJ2aXNvcjoKPgo+IMKgIMKgIMKgKiA/Pz8gLSBLZWlyLCBUaW0sIEphbj8K
Pgo+IHRvb2xzOgo+Cj4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlr
ZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+IMKgIMKgIMKgIMKgd2hpY2ggZG93bnN0cmVh
bSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgo+IMKgIMKg
IMKgIMKgdGhpcyBhcmU6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGV2ZW50IGhhbmRsaW5nIChJ
YW5KIHdvcmtpbmcgb24gdGhpcykKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogZHJvcCBsaWJ4bF9k
ZXZpY2VfbW9kZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2luZm8gb3IKPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkgKElhbkMgd29ya2luZyBvbiB0
aGlzLCBwYXRjaGVzCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzaG9ydGx5KQo+IMKgIMKgIMKg
IMKgIMKgIMKgIMKgKiBhZGQgbGlieGxfZGVmYm9vbCBhbmQgZ2VuZXJhbGx5IHRyeSBhbmQgYXJy
YW5nZSB0aGF0Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtZW1zZXQoZm9vLDAsLi4uKSByZXF1
ZXN0cyB0aGUgZGVmYXVsdHMgKElhbkMgd29ya2luZyBvbgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgdGhpcywgcGF0Y2hlcyBzaG9ydGx5KQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBUaGUgdG9w
b2xvZ3lpbmZvIGRhdGFzdHJ1Y3R1cmUgc2hvdWxkIGJlIGEgbGlzdCBvZgo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgdHVwbGVzLCBub3QgYSB0dXBsZSBvZiBsaXN0cy4gKG5vYm9keSBjdXJyZW50
bHkgbG9va2luZwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXQgdGhpcywgbm90IDEwMCUgc3Vy
ZSB0aGlzIG1ha2VzIHNlbnNlLCBjb3VsZCBwb3NzaWJseQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgZGVmZXIgYW5kIGNoYW5nZSBhZnRlciA0LjIgaW4gYSBjb21wYXRpYmxlIHdheSkKPiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCogQmxvY2sgc2NyaXB0IHN1cHBvcnQgLS0gY2FuIGJlIGRvbmUgcG9z
dCA0LjI/Cj4gwqAgwqAgwqAqIEhvdHBsdWcgc2NyaXB0IHN0dWZmIC0tIGludGVybmFsIHRvIGxp
YnhsIChJIHRoaW5rLCB0aGVyZWZvcmUgSQo+IMKgIMKgIMKgIMKgZGlkbid0IHB1dCB0aGlzIHVu
ZGVyIHN0YWJsZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhhdmUKPiDCoCDCoCDCoCDC
oGZvciA0LjI/IFJvZ2VyIFBhdSBNb25ldCB3YXMgbG9va2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9v
a2luZwo+IMKgIMKgIMKgIMKgbGlrZSBhIGJpZyBjYW4tby13b3Jtcy4uLgoKVGhlIGhvdHBsdWcg
aW1wbGVtZW50YXRpb24gSSd2ZSBzZW50IGNhbiBiZSBpbXByb3ZlZCB3aXRoIGFzeW5jaHJvbm91
cwpldmVudHMgb25jZSBJYW5KIHBhdGNoZXMgYXJlIGluLiBBbHNvIGl0IG1pZ2h0IGJlIGdvb2Qg
dG8gZG8gc29tZQpjbGVhbmluZyBvZiB0aGUgTGludXggaG90cGx1ZyBzY3JpcHRzLCByaWdodCBu
b3cgdGhleSBhcmUgYSBzdHlsZQptZXNzLCBhcGFydCBmcm9tIHRoZSBmYWN0IHRoYXQgdGhleSB0
YWtlIGRpZmZlcmVudCBwYXJhbWV0ZXJzCmRlcGVuZGluZyBvbiB0aGUgc2NyaXB0IGJlaW5nIGNh
bGxlZCwgd2hpY2ggSSB0aGluayBjb3VsZCBiZSBhdm9pZGVkLgoKSSBkb24ndCBrbm93IG11Y2gg
YWJvdXQgZHJpdmVyIGRvbWFpbnMsIGJ1dCBmcm9tIHdoYXQgSSd2ZSByZWFkIHRoZXkKc2hvdWxk
IGJlIHJ1bm5pbmcgc29tZXRoaW5nIGxpa2UgTmV0QlNEIHhlbmJhY2tlbmQgYW5kIGxpc3RlbiBm
b3IKeGVuc3RvcmUgZXZlbnRzLiBNb3N0IG9mIHRoZSBmdW5jdGlvbnMgdGhhdCBJJ3ZlIHdyaXR0
ZW4gb24gbXkgaG90cGx1ZwpzZXJpZXMgY2FuIGJlIHVzZWQgdG8gY3JlYXRlIGEgbGl0dGxlIGRh
ZW1vbiwgdGhhdCdzIG5vdCB0aGUgcHJvYmxlbSwKdGhlIHByb2JsZW0gaXMgd2hhdCBjYW4gd2Ug
dXNlIHRvIHN5bmNocm9uaXplIGhvdHBsdWcgc2NyaXB0IGNhbGxpbmcKYW5kIGxpYnhsICh3aGF0
IGNvbWVzIHRvIG1pbmQgaXMgdXNpbmcgYSBkZWRpY2F0ZWQgeGVuc3RvcmUgdmFyaWFibGUKZm9y
IGVhY2ggZGV2aWNlLCBidXQgc29tZW9uZSBtaWdodCBoYXZlIGEgYmV0dGVyIGlkZWEpLgoKPiDC
oCDCoCDCoCogSW50ZWdyYXRlIHFlbXUrc2VhYmlvcyB1cHN0cmVhbSBpbnRvIHRoZSBidWlsZCAo
U3RlZmFubyBoYXMKPiDCoCDCoCDCoCDCoHBvc3RlZCBwYXRjaGVzLCBJIGd1ZXNzIHRoZXkgbmVl
ZCByZWZyZXNoaW5nIGFuZCByZXBvc3RpbmcpLiBObwo+IMKgIMKgIMKgIMKgY2hhbmdlIGluIGRl
ZmF1bHQgcWVtdSBmb3IgNC4yLgo+IMKgIMKgIMKgKiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4
bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgo+IMKgIMKgIMKgIMKgdHJlZS4gTmVl
ZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPiDCoCDC
oCDCoCDCoHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPgo+IEhhcyBhbnlib2R5IGdvdCBhbnl0
aGluZyBlbHNlPyBJJ20gc3VyZSBJJ3ZlIG1pc3NlZCBzdHVmZi4gQXJlIHRoZXJlIGFueQo+IG11
c3QgaGF2ZXMgZS5nLiBpbiB0aGUgcGFnaW5nL3NoYXJpbmcgc3BhY2VzPwoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:40:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUoT-0002pF-Jl; Wed, 04 Jan 2012 17:39:45 +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 1RiUoR-0002p8-Rw
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:39:44 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325698775!9702143!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 26017 invoked from network); 4 Jan 2012 17:39:37 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 17:39:37 -0000
Received: by daec6 with SMTP id c6so64751048dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 09:39: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=W4aenCEt3nGn0TmcHuGQ1z8ebOltwJnQHm2xvgGTkw0=;
	b=Ke2aNVfKqAdgXpxwNA4vIefBY7d7pFw1Rwmr1GfozrDSBwVot89KqJVYYnASsId4eu
	6QAu8KWnSAYCNG2SB6d5fqdLma0HuFeIHWkksZQwGnr8YpXGKRT4GBv90svZTaNhAgFK
	acKx3RozpoJ5i6uIBpWCQul5SzicwfrY9KV2M=
MIME-Version: 1.0
Received: by 10.68.213.6 with SMTP id no6mr2139013pbc.94.1325698775277; Wed,
	04 Jan 2012 09:39:35 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 4 Jan 2012 09:39:35 -0800 (PST)
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
Date: Wed, 4 Jan 2012 18:39:35 +0100
X-Google-Sender-Auth: ZsHA0zC-VkZI65-oOiUn7YjJxbM
Message-ID: <CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzQgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gV2hhdCBh
cmUgdGhlIG91dHN0YW5kaW5nIHRoaW5ncyB0byBkbyBiZWZvcmUgd2UgdGhpbmsgd2UgY2FuIHN0
YXJ0IG9uCj4gdGhlIDQuMiAtcmMncz8gRG9lcyBhbnlvbmUgaGF2ZSBhIHRpbWV0YWJsZSBpbiBt
aW5kPwo+Cj4gaHlwZXJ2aXNvcjoKPgo+IMKgIMKgIMKgKiA/Pz8gLSBLZWlyLCBUaW0sIEphbj8K
Pgo+IHRvb2xzOgo+Cj4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlr
ZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+IMKgIMKgIMKgIMKgd2hpY2ggZG93bnN0cmVh
bSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgo+IMKgIMKg
IMKgIMKgdGhpcyBhcmU6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGV2ZW50IGhhbmRsaW5nIChJ
YW5KIHdvcmtpbmcgb24gdGhpcykKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogZHJvcCBsaWJ4bF9k
ZXZpY2VfbW9kZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2luZm8gb3IKPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkgKElhbkMgd29ya2luZyBvbiB0
aGlzLCBwYXRjaGVzCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzaG9ydGx5KQo+IMKgIMKgIMKg
IMKgIMKgIMKgIMKgKiBhZGQgbGlieGxfZGVmYm9vbCBhbmQgZ2VuZXJhbGx5IHRyeSBhbmQgYXJy
YW5nZSB0aGF0Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBtZW1zZXQoZm9vLDAsLi4uKSByZXF1
ZXN0cyB0aGUgZGVmYXVsdHMgKElhbkMgd29ya2luZyBvbgo+IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgdGhpcywgcGF0Y2hlcyBzaG9ydGx5KQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBUaGUgdG9w
b2xvZ3lpbmZvIGRhdGFzdHJ1Y3R1cmUgc2hvdWxkIGJlIGEgbGlzdCBvZgo+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgdHVwbGVzLCBub3QgYSB0dXBsZSBvZiBsaXN0cy4gKG5vYm9keSBjdXJyZW50
bHkgbG9va2luZwo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgYXQgdGhpcywgbm90IDEwMCUgc3Vy
ZSB0aGlzIG1ha2VzIHNlbnNlLCBjb3VsZCBwb3NzaWJseQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgZGVmZXIgYW5kIGNoYW5nZSBhZnRlciA0LjIgaW4gYSBjb21wYXRpYmxlIHdheSkKPiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCogQmxvY2sgc2NyaXB0IHN1cHBvcnQgLS0gY2FuIGJlIGRvbmUgcG9z
dCA0LjI/Cj4gwqAgwqAgwqAqIEhvdHBsdWcgc2NyaXB0IHN0dWZmIC0tIGludGVybmFsIHRvIGxp
YnhsIChJIHRoaW5rLCB0aGVyZWZvcmUgSQo+IMKgIMKgIMKgIMKgZGlkbid0IHB1dCB0aGlzIHVu
ZGVyIHN0YWJsZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhhdmUKPiDCoCDCoCDCoCDC
oGZvciA0LjI/IFJvZ2VyIFBhdSBNb25ldCB3YXMgbG9va2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9v
a2luZwo+IMKgIMKgIMKgIMKgbGlrZSBhIGJpZyBjYW4tby13b3Jtcy4uLgoKVGhlIGhvdHBsdWcg
aW1wbGVtZW50YXRpb24gSSd2ZSBzZW50IGNhbiBiZSBpbXByb3ZlZCB3aXRoIGFzeW5jaHJvbm91
cwpldmVudHMgb25jZSBJYW5KIHBhdGNoZXMgYXJlIGluLiBBbHNvIGl0IG1pZ2h0IGJlIGdvb2Qg
dG8gZG8gc29tZQpjbGVhbmluZyBvZiB0aGUgTGludXggaG90cGx1ZyBzY3JpcHRzLCByaWdodCBu
b3cgdGhleSBhcmUgYSBzdHlsZQptZXNzLCBhcGFydCBmcm9tIHRoZSBmYWN0IHRoYXQgdGhleSB0
YWtlIGRpZmZlcmVudCBwYXJhbWV0ZXJzCmRlcGVuZGluZyBvbiB0aGUgc2NyaXB0IGJlaW5nIGNh
bGxlZCwgd2hpY2ggSSB0aGluayBjb3VsZCBiZSBhdm9pZGVkLgoKSSBkb24ndCBrbm93IG11Y2gg
YWJvdXQgZHJpdmVyIGRvbWFpbnMsIGJ1dCBmcm9tIHdoYXQgSSd2ZSByZWFkIHRoZXkKc2hvdWxk
IGJlIHJ1bm5pbmcgc29tZXRoaW5nIGxpa2UgTmV0QlNEIHhlbmJhY2tlbmQgYW5kIGxpc3RlbiBm
b3IKeGVuc3RvcmUgZXZlbnRzLiBNb3N0IG9mIHRoZSBmdW5jdGlvbnMgdGhhdCBJJ3ZlIHdyaXR0
ZW4gb24gbXkgaG90cGx1ZwpzZXJpZXMgY2FuIGJlIHVzZWQgdG8gY3JlYXRlIGEgbGl0dGxlIGRh
ZW1vbiwgdGhhdCdzIG5vdCB0aGUgcHJvYmxlbSwKdGhlIHByb2JsZW0gaXMgd2hhdCBjYW4gd2Ug
dXNlIHRvIHN5bmNocm9uaXplIGhvdHBsdWcgc2NyaXB0IGNhbGxpbmcKYW5kIGxpYnhsICh3aGF0
IGNvbWVzIHRvIG1pbmQgaXMgdXNpbmcgYSBkZWRpY2F0ZWQgeGVuc3RvcmUgdmFyaWFibGUKZm9y
IGVhY2ggZGV2aWNlLCBidXQgc29tZW9uZSBtaWdodCBoYXZlIGEgYmV0dGVyIGlkZWEpLgoKPiDC
oCDCoCDCoCogSW50ZWdyYXRlIHFlbXUrc2VhYmlvcyB1cHN0cmVhbSBpbnRvIHRoZSBidWlsZCAo
U3RlZmFubyBoYXMKPiDCoCDCoCDCoCDCoHBvc3RlZCBwYXRjaGVzLCBJIGd1ZXNzIHRoZXkgbmVl
ZCByZWZyZXNoaW5nIGFuZCByZXBvc3RpbmcpLiBObwo+IMKgIMKgIMKgIMKgY2hhbmdlIGluIGRl
ZmF1bHQgcWVtdSBmb3IgNC4yLgo+IMKgIMKgIMKgKiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4
bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgo+IMKgIMKgIMKgIMKgdHJlZS4gTmVl
ZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPiDCoCDC
oCDCoCDCoHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPgo+IEhhcyBhbnlib2R5IGdvdCBhbnl0
aGluZyBlbHNlPyBJJ20gc3VyZSBJJ3ZlIG1pc3NlZCBzdHVmZi4gQXJlIHRoZXJlIGFueQo+IG11
c3QgaGF2ZXMgZS5nLiBpbiB0aGUgcGFnaW5nL3NoYXJpbmcgc3BhY2VzPwoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:41:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:41:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUq2-0002uS-3e; Wed, 04 Jan 2012 17:41: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 1RiUq0-0002u7-Lz
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:41:20 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325698872!7807129!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 24202 invoked from network); 4 Jan 2012 17:41:14 -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;
	4 Jan 2012 17:41:14 -0000
Received: by pbbb11 with SMTP id b11so59269053pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 09:41:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=CpP+IYv31AWiYLU8/nf+jnsTWFQ0Fuxi8muitM5U3jE=;
	b=h/mtumYaUf73z4HBRyYeAWnjmSy+DFrQWx/BHqOmc79lxPyZAXSZ616hZGFwd9FOuo
	21o2GEHu3W7kVXN7OICv9ejLLxoT63scqovMn1GVjPcM4NhPt6BJ2ffISdRy0x0i3ZMi
	5u8SYvugfShvWxYbTpKe/ZfEJq7E/FCyy1cLc=
MIME-Version: 1.0
Received: by 10.68.75.199 with SMTP id e7mr144482871pbw.128.1325698871881;
	Wed, 04 Jan 2012 09:41:11 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 4 Jan 2012 09:41:11 -0800 (PST)
In-Reply-To: <1325608320.25206.161.camel@zakaz.uk.xensource.com>
References: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
	<1325608320.25206.161.camel@zakaz.uk.xensource.com>
Date: Wed, 4 Jan 2012 18:41:11 +0100
X-Google-Sender-Auth: XW5OmHtrGVFtLAZ_9FR-i44i5Oo
Message-ID: <CAPLaKK7HauKbX5yXA4VahVYmhUZ8udiG4mRCE1b+MpS9jF5N2w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gVHVl
LCAyMDEyLTAxLTAzIGF0IDEyOjE0ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNTU5MjcwNiAtMzYwMAo+PiAjIE5vZGUgSUQgNmZj
YzFjNDc5ZWU2OGYyNzIzM2E1NWVjNDVhNjE4ZTBmN2NmNWQ2Zgo+PiAjIFBhcmVudCDCoDNlMDJh
YTk2NzBiMzI2NWUzNmJkZGRiZDQ3NjA0MTVjZDg3ZDA0N2IKPj4gcHlncnViOiBmaXggZXh0bGlu
dXggcGFyc2luZwo+Pgo+PiBweWdydWIgd2FzIHVuYWJsZSB0byBwYXJzZSBleHRsaW51eCBjb25m
aWcgZmlsZXMgY29ycmVjdGx5LCBleGFjdGx5Cj4+IHRoZSBvbmVzIGxpa2U6Cj4+Cj4+IExBQkVM
IGdyc2VjCj4+IMKgIEtFUk5FTCB2bWxpbnV6LTMuMC4xMC1ncnNlYwo+PiDCoCBBUFBFTkQgaW5p
dHJkPWluaXRyYW1mcy0zLjAuMTAtZ3JzZWMKPj4gcm9vdD1VVUlEPWNmZDRhN2I0LThjNDAtNDAy
NS1iODc3LTgyMDVmMWM2MjJlZQo+PiBtb2R1bGVzPXNkLW1vZCx1c2Itc3RvcmFnZSxleHQ0IHhl
biBxdWlldAo+Pgo+PiBUaGlzIHBhdGNoIGZpeGVzIGl0LCBhZGRpbmcgYSBuZXcgY2FzZSB3aGVu
IHBhcnNpbmcgdGhlICJhcHBlbmQiIGxpbmUsCj4+IHRoYXQgc2VhcmNoZXMgZm9yIHRoZSBpbml0
cmQgaW1hZ2UuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4KPiBBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxA
Y2l0cml4LmNvbT4KCkNhbiB0aGlzIHBhdGNoIGJlIGJhY2twb3J0ZWQgdG8gNC4xIGF0IGxlYXN0
IChJIGRvbid0IHRoaW5rIDQuMCBpcyBuZWNlc3NhcnkpCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:41:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 17:41:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiUq2-0002uS-3e; Wed, 04 Jan 2012 17:41: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 1RiUq0-0002u7-Lz
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:41:20 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325698872!7807129!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 24202 invoked from network); 4 Jan 2012 17:41:14 -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;
	4 Jan 2012 17:41:14 -0000
Received: by pbbb11 with SMTP id b11so59269053pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 09:41:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=CpP+IYv31AWiYLU8/nf+jnsTWFQ0Fuxi8muitM5U3jE=;
	b=h/mtumYaUf73z4HBRyYeAWnjmSy+DFrQWx/BHqOmc79lxPyZAXSZ616hZGFwd9FOuo
	21o2GEHu3W7kVXN7OICv9ejLLxoT63scqovMn1GVjPcM4NhPt6BJ2ffISdRy0x0i3ZMi
	5u8SYvugfShvWxYbTpKe/ZfEJq7E/FCyy1cLc=
MIME-Version: 1.0
Received: by 10.68.75.199 with SMTP id e7mr144482871pbw.128.1325698871881;
	Wed, 04 Jan 2012 09:41:11 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 4 Jan 2012 09:41:11 -0800 (PST)
In-Reply-To: <1325608320.25206.161.camel@zakaz.uk.xensource.com>
References: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
	<1325608320.25206.161.camel@zakaz.uk.xensource.com>
Date: Wed, 4 Jan 2012 18:41:11 +0100
X-Google-Sender-Auth: XW5OmHtrGVFtLAZ_9FR-i44i5Oo
Message-ID: <CAPLaKK7HauKbX5yXA4VahVYmhUZ8udiG4mRCE1b+MpS9jF5N2w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gVHVl
LCAyMDEyLTAxLTAzIGF0IDEyOjE0ICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNTU5MjcwNiAtMzYwMAo+PiAjIE5vZGUgSUQgNmZj
YzFjNDc5ZWU2OGYyNzIzM2E1NWVjNDVhNjE4ZTBmN2NmNWQ2Zgo+PiAjIFBhcmVudCDCoDNlMDJh
YTk2NzBiMzI2NWUzNmJkZGRiZDQ3NjA0MTVjZDg3ZDA0N2IKPj4gcHlncnViOiBmaXggZXh0bGlu
dXggcGFyc2luZwo+Pgo+PiBweWdydWIgd2FzIHVuYWJsZSB0byBwYXJzZSBleHRsaW51eCBjb25m
aWcgZmlsZXMgY29ycmVjdGx5LCBleGFjdGx5Cj4+IHRoZSBvbmVzIGxpa2U6Cj4+Cj4+IExBQkVM
IGdyc2VjCj4+IMKgIEtFUk5FTCB2bWxpbnV6LTMuMC4xMC1ncnNlYwo+PiDCoCBBUFBFTkQgaW5p
dHJkPWluaXRyYW1mcy0zLjAuMTAtZ3JzZWMKPj4gcm9vdD1VVUlEPWNmZDRhN2I0LThjNDAtNDAy
NS1iODc3LTgyMDVmMWM2MjJlZQo+PiBtb2R1bGVzPXNkLW1vZCx1c2Itc3RvcmFnZSxleHQ0IHhl
biBxdWlldAo+Pgo+PiBUaGlzIHBhdGNoIGZpeGVzIGl0LCBhZGRpbmcgYSBuZXcgY2FzZSB3aGVu
IHBhcnNpbmcgdGhlICJhcHBlbmQiIGxpbmUsCj4+IHRoYXQgc2VhcmNoZXMgZm9yIHRoZSBpbml0
cmQgaW1hZ2UuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4KPiBBY2tlZC1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxA
Y2l0cml4LmNvbT4KCkNhbiB0aGlzIHBhdGNoIGJlIGJhY2twb3J0ZWQgdG8gNC4xIGF0IGxlYXN0
IChJIGRvbid0IHRoaW5rIDQuMCBpcyBuZWNlc3NhcnkpCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:47:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiUvX-0003Br-2x; Wed, 04 Jan 2012 17:47:03 +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 1RiUvU-0003Bm-KQ
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:47:00 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325699175!50902192!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=2.1 required=7.0 tests=UNIQUE_WORDS
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29373 invoked from network); 4 Jan 2012 17:46:16 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	4 Jan 2012 17:46:16 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74288469; Wed, 04 Jan 2012 18:46:58 +0100
Message-ID: <1325699196.2633.9.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 04 Jan 2012 18:46:36 +0100
In-Reply-To: <1324483425.4366.43.camel@Abyss>
References: <1324483425.4366.43.camel@Abyss>
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: Re: [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="===============6045855394741784004=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6045855394741784004==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Dkb3cGpWblrV6K+N2ESn"


--=-Dkb3cGpWblrV6K+N2ESn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-21 at 17:03 +0100, Dario Faggioli wrote:
> sched_sedf.c used o have its own mechanism for producing tracing-alike
> kind of information (domain block, wakeup, etc.).=20
>
> [..]

Ok, given my previous patches has been checked-in, this one does not
apply any longer. v3 that applies cleanly to latest hg, coming.

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)


--=-Dkb3cGpWblrV6K+N2ESn
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)

iEYEABECAAYFAk8EkHwACgkQk4XaBE3IOsRltQCdElgOe4DgNjgXG1puvCr90X2u
9tkAnAxatAcpnMDfdJaHtFIrhmVYRgGF
=nwst
-----END PGP SIGNATURE-----

--=-Dkb3cGpWblrV6K+N2ESn--



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

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

--===============6045855394741784004==--



From xen-devel-bounces@lists.xensource.com Wed Jan 04 17:47:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 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 1RiUvX-0003Br-2x; Wed, 04 Jan 2012 17:47:03 +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 1RiUvU-0003Bm-KQ
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 17:47:00 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1325699175!50902192!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=2.1 required=7.0 tests=UNIQUE_WORDS
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29373 invoked from network); 4 Jan 2012 17:46:16 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	4 Jan 2012 17:46:16 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74288469; Wed, 04 Jan 2012 18:46:58 +0100
Message-ID: <1325699196.2633.9.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 04 Jan 2012 18:46:36 +0100
In-Reply-To: <1324483425.4366.43.camel@Abyss>
References: <1324483425.4366.43.camel@Abyss>
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: Re: [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="===============6045855394741784004=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6045855394741784004==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Dkb3cGpWblrV6K+N2ESn"


--=-Dkb3cGpWblrV6K+N2ESn
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2011-12-21 at 17:03 +0100, Dario Faggioli wrote:
> sched_sedf.c used o have its own mechanism for producing tracing-alike
> kind of information (domain block, wakeup, etc.).=20
>
> [..]

Ok, given my previous patches has been checked-in, this one does not
apply any longer. v3 that applies cleanly to latest hg, coming.

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)


--=-Dkb3cGpWblrV6K+N2ESn
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)

iEYEABECAAYFAk8EkHwACgkQk4XaBE3IOsRltQCdElgOe4DgNjgXG1puvCr90X2u
9tkAnAxatAcpnMDfdJaHtFIrhmVYRgGF
=nwst
-----END PGP SIGNATURE-----

--=-Dkb3cGpWblrV6K+N2ESn--



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

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

--===============6045855394741784004==--



From xen-devel-bounces@lists.xensource.com Wed Jan 04 18:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 18:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiV89-0003RX-Dl; Wed, 04 Jan 2012 18:00:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike.mcclurg@citrix.com>)
	id 1RiV87-0003NR-Fo; Wed, 04 Jan 2012 18:00:03 +0000
X-Env-Sender: mike.mcclurg@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325699996!9705543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg0Mzg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12731 invoked from network); 4 Jan 2012 17:59:57 -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;
	4 Jan 2012 17:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320642000"; d="scan'208";a="176270197"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 12:59:55 -0500
Received: from [10.80.2.141] (10.80.2.141) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Jan 2012
	12:59:55 -0500
Message-ID: <4F04939A.9030506@citrix.com>
Date: Wed, 4 Jan 2012 17:59:54 +0000
From: Mike McClurg <mike.mcclurg@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@OrdinaryAmerican.net>
References: <CACm5R6RY6oxN5KT_VjjvPwsbczBMhficjG0WQBrxffcU0jOuQA@mail.gmail.com>
	<20111217103444.GB12984@reaktio.net>
In-Reply-To: <20111217103444.GB12984@reaktio.net>
X-Enigmail-Version: 1.3.3
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] [Xen-API]  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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/12/11 10:34, Pasi K=E4rkk=E4inen wrote:
> On Fri, Dec 16, 2011 at 03:38:32PM -0800, xen-devel.GarveyPatrickD@Ordina=
ryAmerican.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?
>>
> =


The mirror you found looks to be identical to the original site, though
I'm not sure when the mirror was taken. Another good reference is part 1
of the OCaml manual (http://caml.inria.fr/pub/docs/manual-ocaml/), which
gives a good, but brief, introduction to the language.

Another good place to go for OCaml questions is the #ocaml channel on
IRC. Good luck,

Mike

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 18:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 18:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiV89-0003RX-Dl; Wed, 04 Jan 2012 18:00:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mike.mcclurg@citrix.com>)
	id 1RiV87-0003NR-Fo; Wed, 04 Jan 2012 18:00:03 +0000
X-Env-Sender: mike.mcclurg@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325699996!9705543!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg0Mzg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12731 invoked from network); 4 Jan 2012 17:59:57 -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;
	4 Jan 2012 17:59:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320642000"; d="scan'208";a="176270197"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 12:59:55 -0500
Received: from [10.80.2.141] (10.80.2.141) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Wed, 4 Jan 2012
	12:59:55 -0500
Message-ID: <4F04939A.9030506@citrix.com>
Date: Wed, 4 Jan 2012 17:59:54 +0000
From: Mike McClurg <mike.mcclurg@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel.GarveyPatrickD@OrdinaryAmerican.net"
	<xen-devel.GarveyPatrickD@OrdinaryAmerican.net>
References: <CACm5R6RY6oxN5KT_VjjvPwsbczBMhficjG0WQBrxffcU0jOuQA@mail.gmail.com>
	<20111217103444.GB12984@reaktio.net>
In-Reply-To: <20111217103444.GB12984@reaktio.net>
X-Enigmail-Version: 1.3.3
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] [Xen-API]  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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/12/11 10:34, Pasi K=E4rkk=E4inen wrote:
> On Fri, Dec 16, 2011 at 03:38:32PM -0800, xen-devel.GarveyPatrickD@Ordina=
ryAmerican.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?
>>
> =


The mirror you found looks to be identical to the original site, though
I'm not sure when the mirror was taken. Another good reference is part 1
of the OCaml manual (http://caml.inria.fr/pub/docs/manual-ocaml/), which
gives a good, but brief, introduction to the language.

Another good place to go for OCaml questions is the #ocaml channel on
IRC. Good luck,

Mike

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 18:06:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 18: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 1RiVEI-0003iz-7n; Wed, 04 Jan 2012 18:06: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 1RiVEH-0003ip-GR
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:06:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325700379!9704832!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32172 invoked from network); 4 Jan 2012 18:06:19 -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;
	4 Jan 2012 18:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9820600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 18:06:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 18:06:17 +0000
Date: Wed, 4 Jan 2012 18:06:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <1324304024-11220-18-git-send-email-avi@redhat.com>
Message-ID: <alpine.DEB.2.00.1201041758570.3150@kaball-desktop>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-18-git-send-email-avi@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [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>
Content-Type: text/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, 19 Dec 2011, Avi Kivity wrote:
> -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);
>  }

I really feel I should thank you for your work because you did a very
good job porting xen to the new api. In fact apart from the dirty bitmap
(Anthony is about to send a patch to fix the issue:
xen_sync_dirty_bitmap can actually fail sometimes), everything else
is done right and works correctly.

However I would have appreciated if you could have given us more time to
review the four patches you wrote: considering the time of the year both
Anthony and I were on vacation and didn't have a chance to read them
until today.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 18:06:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 18: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 1RiVEI-0003iz-7n; Wed, 04 Jan 2012 18:06: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 1RiVEH-0003ip-GR
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:06:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325700379!9704832!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32172 invoked from network); 4 Jan 2012 18:06:19 -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;
	4 Jan 2012 18:06:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; 
   d="scan'208";a="9820600"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 18:06:17 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 18:06:17 +0000
Date: Wed, 4 Jan 2012 18:06:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <1324304024-11220-18-git-send-email-avi@redhat.com>
Message-ID: <alpine.DEB.2.00.1201041758570.3150@kaball-desktop>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-18-git-send-email-avi@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [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>
Content-Type: text/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, 19 Dec 2011, Avi Kivity wrote:
> -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);
>  }

I really feel I should thank you for your work because you did a very
good job porting xen to the new api. In fact apart from the dirty bitmap
(Anthony is about to send a patch to fix the issue:
xen_sync_dirty_bitmap can actually fail sometimes), everything else
is done right and works correctly.

However I would have appreciated if you could have given us more time to
review the four patches you wrote: considering the time of the year both
Anthony and I were on vacation and didn't have a chance to read them
until today.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 18:21:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 18: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 1RiVSA-0004BB-8o; Wed, 04 Jan 2012 18:20:46 +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 1RiVS8-0004B6-1v
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:20:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325701199!49030632!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 24569 invoked from network); 4 Jan 2012 18:19:59 -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; 4 Jan 2012 18:19:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RiVS1-000HO1-8S; Wed, 04 Jan 2012 18:20:37 +0000
Date: Wed, 4 Jan 2012 18:20:37 +0000
From: Tim Deegan <tim@xen.org>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120104182037.GC15595@ocelot.phlegethon.org>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120104172519.GS12984@reaktio.net>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 19:25 +0200 on 04 Jan (1325705119), Pasi K?rkk?inen wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > What are the outstanding things to do before we think we can start on
> > the 4.2 -rc's? Does anyone have a timetable in mind?
> > 
> > hypervisor:
> > 
> >       * ??? - Keir, Tim, Jan?

I would like to get the interface changes for sharing/paging/mem-events
done and dusted so that 4.2 is a stable API that we hold to.

It would be nice to get the implementation solid too (i.e., using wait
queues) but that can happen later if it's the only thing holding up a
release.

> - What's the status of Nested Hardware Virtualization? 
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..

The basic feature is in for AMD and Intel, but AIUI it's not getting a
lot of use and it's not in the xen.org automated testing.  The AMD code
has nested-paging support too, which is a requirement for decent
performance. 

We could call it 'experimental' for 4.2?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 18:21:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 18: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 1RiVSA-0004BB-8o; Wed, 04 Jan 2012 18:20:46 +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 1RiVS8-0004B6-1v
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:20:44 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325701199!49030632!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 24569 invoked from network); 4 Jan 2012 18:19:59 -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; 4 Jan 2012 18:19:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RiVS1-000HO1-8S; Wed, 04 Jan 2012 18:20:37 +0000
Date: Wed, 4 Jan 2012 18:20:37 +0000
From: Tim Deegan <tim@xen.org>
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Message-ID: <20120104182037.GC15595@ocelot.phlegethon.org>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120104172519.GS12984@reaktio.net>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 19:25 +0200 on 04 Jan (1325705119), Pasi K?rkk?inen wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > What are the outstanding things to do before we think we can start on
> > the 4.2 -rc's? Does anyone have a timetable in mind?
> > 
> > hypervisor:
> > 
> >       * ??? - Keir, Tim, Jan?

I would like to get the interface changes for sharing/paging/mem-events
done and dusted so that 4.2 is a stable API that we hold to.

It would be nice to get the implementation solid too (i.e., using wait
queues) but that can happen later if it's the only thing holding up a
release.

> - What's the status of Nested Hardware Virtualization? 
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..

The basic feature is in for AMD and Intel, but AIUI it's not getting a
lot of use and it's not in the xen.org automated testing.  The AMD code
has nested-paging support too, which is a requirement for decent
performance. 

We could call it 'experimental' for 4.2?

Cheers,

Tim.

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 18:29:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 18: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 1RiVaP-0004OJ-8Q; Wed, 04 Jan 2012 18:29:17 +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 1RiVaN-0004OB-SM
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:29:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325701748!10500383!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 27349 invoked from network); 4 Jan 2012 18:29:09 -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;
	4 Jan 2012 18:29:09 -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
	q04ISFgK005475; Wed, 4 Jan 2012 18:28: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 q04ISFDF004468; 
	Wed, 4 Jan 2012 13:28:15 -0500
Message-ID: <4F049A46.5080104@tycho.nsa.gov>
Date: Wed, 04 Jan 2012 13:28:22 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <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>	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
	<1325696094.25206.321.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325696094.25206.321.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 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 01/04/2012 11:54 AM, Ian Campbell wrote:
> On Wed, 2012-01-04 at 16:49 +0000, Stefano Stabellini wrote:
>> On Wed, 4 Jan 2012, Daniel De Graaf wrote:
>>> The example policy doesn't really belong in docs because it needs to be
>>> compiled to be usable, and this depends on a number of other files (all
>>> files under tools/flask/policy/policy, to be exact). Compiling and
>>> installing FLASK policy during the normal build process (conditional on
>>> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
>>> would be the best solution. The policy must be installed to /boot, not
>>> /etc/xen, because the initial policy load happens prior to starting dom0.
>>
>> Like Ian said, I meant having the policy somewhere online where can be
>> linked. However we only publish on xenbits what we have under docs ATM.
>> It is unfortunate that the policy needs FLASK_ENABLE to be compiled
>> because I am pretty sure that the automated build system that produces
>> the docs that end up online does not support that option right now.
> 
> Publishing the docs in this manner wouldn't require FLASK_ENABLE since
> it doesn't need any tools, just "cp". Unless I've totally got the wrong
> end of the stick and the policy needs processing before you can even
> usefully read it?
> 
> Ian.
> 

You can read the policy files as-is; the xen.te and xen.if files contain
most of what you would want to inspect. However, this is similar to reading
shell scripts or other source files, which is not what I would expect from
files copied into a docs folder.

There are some tools for searching and understanding SELinux policy such as
sesearch that work either on the binary policy file or on the macro-expanded
policy.conf. Building policy.conf only requires m4, which is already required
for bison as part of Xen's build process. This file is much less readable by
humans, however, since it is the output of macro expansion.

Also: the policy currently isn't built automatically even if FLASK_ENABLE=y;
this is something that I think should be changed although I will wait to post
a patch until we've decided what parts of the output should be used.

-- 
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 Wed Jan 04 18:29:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 18: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 1RiVaP-0004OJ-8Q; Wed, 04 Jan 2012 18:29:17 +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 1RiVaN-0004OB-SM
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:29:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325701748!10500383!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 27349 invoked from network); 4 Jan 2012 18:29:09 -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;
	4 Jan 2012 18:29:09 -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
	q04ISFgK005475; Wed, 4 Jan 2012 18:28: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 q04ISFDF004468; 
	Wed, 4 Jan 2012 13:28:15 -0500
Message-ID: <4F049A46.5080104@tycho.nsa.gov>
Date: Wed, 04 Jan 2012 13:28:22 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <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>	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
	<1325696094.25206.321.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325696094.25206.321.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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 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 01/04/2012 11:54 AM, Ian Campbell wrote:
> On Wed, 2012-01-04 at 16:49 +0000, Stefano Stabellini wrote:
>> On Wed, 4 Jan 2012, Daniel De Graaf wrote:
>>> The example policy doesn't really belong in docs because it needs to be
>>> compiled to be usable, and this depends on a number of other files (all
>>> files under tools/flask/policy/policy, to be exact). Compiling and
>>> installing FLASK policy during the normal build process (conditional on
>>> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
>>> would be the best solution. The policy must be installed to /boot, not
>>> /etc/xen, because the initial policy load happens prior to starting dom0.
>>
>> Like Ian said, I meant having the policy somewhere online where can be
>> linked. However we only publish on xenbits what we have under docs ATM.
>> It is unfortunate that the policy needs FLASK_ENABLE to be compiled
>> because I am pretty sure that the automated build system that produces
>> the docs that end up online does not support that option right now.
> 
> Publishing the docs in this manner wouldn't require FLASK_ENABLE since
> it doesn't need any tools, just "cp". Unless I've totally got the wrong
> end of the stick and the policy needs processing before you can even
> usefully read it?
> 
> Ian.
> 

You can read the policy files as-is; the xen.te and xen.if files contain
most of what you would want to inspect. However, this is similar to reading
shell scripts or other source files, which is not what I would expect from
files copied into a docs folder.

There are some tools for searching and understanding SELinux policy such as
sesearch that work either on the binary policy file or on the macro-expanded
policy.conf. Building policy.conf only requires m4, which is already required
for bison as part of Xen's build process. This file is much less readable by
humans, however, since it is the output of macro expansion.

Also: the policy currently isn't built automatically even if FLASK_ENABLE=y;
this is something that I think should be changed although I will wait to post
a patch until we've decided what parts of the output should be used.

-- 
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 Wed Jan 04 19:23:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWPQ-0004mb-H7; Wed, 04 Jan 2012 19:22:00 +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 1RiWPP-0004mW-3X
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:21:59 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325704912!9079618!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 26675 invoked from network); 4 Jan 2012 19:21:52 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 19:21:52 -0000
Received: from mail50-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; Wed, 4 Jan 2012 19:21:52 +0000
Received: from mail50-db3 (localhost [127.0.0.1])	by mail50-db3-R.bigfish.com
	(Postfix) with ESMTP id 1FC3860180;
	Wed,  4 Jan 2012 19:21:52 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371Ic89bh1432N98dKzz1202hzz8275bhz2dh668h839h)
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 mail50-db3 (localhost.localdomain [127.0.0.1]) by mail50-db3
	(MessageSwitch) id 1325704911925384_8999;
	Wed,  4 Jan 2012 19:21:51 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.248])	by
	mail50-db3.bigfish.com (Postfix) with ESMTP id D1E39640043;
	Wed,  4 Jan 2012 19:21:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:21:49 +0000
X-WSS-ID: 0LXAGG9-02-5M9-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 23C67C8013;	Wed,  4 Jan 2012 13:21:45 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 4 Jan 2012 13:21:58 -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; Wed, 4 Jan 2012
	13:21:46 -0600
Message-ID: <4F04A6CA.3010907@amd.com>
Date: Wed, 4 Jan 2012 13:21:46 -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: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
In-Reply-To: <20120104172519.GS12984@reaktio.net>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/04/2012 11:25 AM, Pasi K=E4rkk=E4inen wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
>> What are the outstanding things to do before we think we can start on
>> the 4.2 -rc's? Does anyone have a timetable in mind?
>>
>> hypervisor:
>>
>>        * ??? - Keir, Tim, Jan?
>>
>> tools:
>>
>>        * libxl stable API -- we would like 4.2 to define a stable API
>>          which downstream's can start to rely on not changing. Aspects of
>>          this are:
>>                * event handling (IanJ working on this)
>>                * drop libxl_device_model_info (move bits to build_info or
>>                  elsewhere as appropriate) (IanC working on this, patches
>>                  shortly)
>>                * add libxl_defbool and generally try and arrange that
>>                  memset(foo,0,...) requests the defaults (IanC working on
>>                  this, patches shortly)
>>                * The topologyinfo datastructure should be a list of
>>                  tuples, not a tuple of lists. (nobody currently looking
>>                  at this, not 100% sure this makes sense, could possibly
>>                  defer and change after 4.2 in a compatible way)
>>                * Block script support -- can be done post 4.2?
>>        * Hotplug script stuff -- internal to libxl (I think, therefore I
>>          didn't put this under stable API above) but still good to have
>>          for 4.2? Roger Pau Monet was looking at this but its looking
>>          like a big can-o-worms...
>>        * Integrate qemu+seabios upstream into the build (Stefano has
>>          posted patches, I guess they need refreshing and reposting). No
>>          change in default qemu for 4.2.
>>        * More formally deprecate xm/xend. Manpage patches already in
>>          tree. Needs release noting and communication around -rc1 to
>>          remind people to test xl.
>>
>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>> must haves e.g. in the paging/sharing spaces?
>>
> - What's the status of Nested Hardware Virtualization?
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..
>
>
> - Also there's a bunch of VGA passthru related patches,
> that I once volunteered to collect/rebase/cleanup/repost myself,
> but I still haven't had time for that :(
Since there were quite a lot of interest on this subject, should we =

document it in a separate wiki for working combinations (like =

hypervisor, dom0, gfx card, driver version, tricks, etc)?
>
> -- 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 Jan 04 19:23:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWPQ-0004mb-H7; Wed, 04 Jan 2012 19:22:00 +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 1RiWPP-0004mW-3X
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:21:59 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325704912!9079618!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 26675 invoked from network); 4 Jan 2012 19:21:52 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 19:21:52 -0000
Received: from mail50-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; Wed, 4 Jan 2012 19:21:52 +0000
Received: from mail50-db3 (localhost [127.0.0.1])	by mail50-db3-R.bigfish.com
	(Postfix) with ESMTP id 1FC3860180;
	Wed,  4 Jan 2012 19:21:52 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371Ic89bh1432N98dKzz1202hzz8275bhz2dh668h839h)
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 mail50-db3 (localhost.localdomain [127.0.0.1]) by mail50-db3
	(MessageSwitch) id 1325704911925384_8999;
	Wed,  4 Jan 2012 19:21:51 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.248])	by
	mail50-db3.bigfish.com (Postfix) with ESMTP id D1E39640043;
	Wed,  4 Jan 2012 19:21:51 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:21:49 +0000
X-WSS-ID: 0LXAGG9-02-5M9-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 23C67C8013;	Wed,  4 Jan 2012 13:21:45 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 4 Jan 2012 13:21:58 -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; Wed, 4 Jan 2012
	13:21:46 -0600
Message-ID: <4F04A6CA.3010907@amd.com>
Date: Wed, 4 Jan 2012 13:21:46 -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: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
In-Reply-To: <20120104172519.GS12984@reaktio.net>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/04/2012 11:25 AM, Pasi K=E4rkk=E4inen wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
>> What are the outstanding things to do before we think we can start on
>> the 4.2 -rc's? Does anyone have a timetable in mind?
>>
>> hypervisor:
>>
>>        * ??? - Keir, Tim, Jan?
>>
>> tools:
>>
>>        * libxl stable API -- we would like 4.2 to define a stable API
>>          which downstream's can start to rely on not changing. Aspects of
>>          this are:
>>                * event handling (IanJ working on this)
>>                * drop libxl_device_model_info (move bits to build_info or
>>                  elsewhere as appropriate) (IanC working on this, patches
>>                  shortly)
>>                * add libxl_defbool and generally try and arrange that
>>                  memset(foo,0,...) requests the defaults (IanC working on
>>                  this, patches shortly)
>>                * The topologyinfo datastructure should be a list of
>>                  tuples, not a tuple of lists. (nobody currently looking
>>                  at this, not 100% sure this makes sense, could possibly
>>                  defer and change after 4.2 in a compatible way)
>>                * Block script support -- can be done post 4.2?
>>        * Hotplug script stuff -- internal to libxl (I think, therefore I
>>          didn't put this under stable API above) but still good to have
>>          for 4.2? Roger Pau Monet was looking at this but its looking
>>          like a big can-o-worms...
>>        * Integrate qemu+seabios upstream into the build (Stefano has
>>          posted patches, I guess they need refreshing and reposting). No
>>          change in default qemu for 4.2.
>>        * More formally deprecate xm/xend. Manpage patches already in
>>          tree. Needs release noting and communication around -rc1 to
>>          remind people to test xl.
>>
>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>> must haves e.g. in the paging/sharing spaces?
>>
> - What's the status of Nested Hardware Virtualization?
> I remember some email saying Intel vmx-on-vmx has some performance issues,
> and amd svm-on-svm works better..
>
>
> - Also there's a bunch of VGA passthru related patches,
> that I once volunteered to collect/rebase/cleanup/repost myself,
> but I still haven't had time for that :(
Since there were quite a lot of interest on this subject, should we =

document it in a separate wiki for working combinations (like =

hypervisor, dom0, gfx card, driver version, tricks, etc)?
>
> -- 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 Jan 04 19:33:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWZH-0004zW-6s; Wed, 04 Jan 2012 19:32:11 +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 1RiWZF-0004zM-By
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:32:09 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325705521!2295963!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11115 invoked from network); 4 Jan 2012 19:32:02 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	VA3EHSOBE004.bigfish.com) (216.32.180.14)
	by server-16.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 19:32:02 -0000
Received: from mail32-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:32:01 +0000
Received: from mail32-va3 (localhost [127.0.0.1])	by mail32-va3-R.bigfish.com
	(Postfix) with ESMTP id 3FB256C0243;
	Wed,  4 Jan 2012 19:32:01 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371Ic85dh1432N98dKzz1202hzz8275bhz2dh668h839h)
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 mail32-va3 (localhost.localdomain [127.0.0.1]) by mail32-va3
	(MessageSwitch) id 1325705519875696_3733;
	Wed,  4 Jan 2012 19:31:59 +0000 (UTC)
Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.244])	by
	mail32-va3.bigfish.com (Postfix) with ESMTP id C68D610004B;
	Wed,  4 Jan 2012 19:31:59 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:31:59 +0000
X-WSS-ID: 0LXAGX8-02-6KM-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 206C1C8009;	Wed,  4 Jan 2012 13:31:56 -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, 4 Jan 2012 13:32:09 -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; Wed, 4 Jan 2012
	13:31:57 -0600
Message-ID: <4F04A92D.7000301@amd.com>
Date: Wed, 4 Jan 2012 13:31:57 -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: Florian Manschwetus <florianmanschwetus@gmx.de>
References: <4F047035.1060304@amd.com> <4F048368.2000204@gmx.de>
In-Reply-To: <4F048368.2000204@gmx.de>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen 4.1: x86/ucode: fix for AMD Fam15 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: multipart/mixed; boundary="===============5864270976095197324=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5864270976095197324==
Content-Type: multipart/alternative;
	boundary="------------070306080704030304010207"

--------------070306080704030304010207
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 01/04/2012 10:50 AM, Florian Manschwetus wrote:
> Am 04.01.2012 16:28, schrieb Christoph Egger:
>> 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>
>> Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1
>>
> Could this fix my xen boot problem on athlon x2 (fam 15 according to
> cpuinfo)
>
> See xen-devel post:
> [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64 X2
> from 22.12.2011 ff
Probably not. cpuinfo reports family in decimal. So your Athlon is 
Family 0xF; but Christoph's patch is for Family 0x15. For a quick 
verification, you can rename your AMD ucode (in /lib/firmware/amd-ucode) 
to prevent it from being loaded. /
/
>
> Regards,
> Florian
>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>


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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 01/04/2012 10:50 AM, Florian Manschwetus wrote:
    <blockquote cite="mid:4F048368.2000204@gmx.de" type="cite">
      <pre wrap="">Am 04.01.2012 16:28, schrieb Christoph Egger:
</pre>
      <blockquote type="cite">
        <pre wrap="">
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 <a class="moz-txt-link-rfc2396E" href="mailto:Christoph.Egger@amd.com">&lt;Christoph.Egger@amd.com&gt;</a>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1

</pre>
      </blockquote>
      <pre wrap="">Could this fix my xen boot problem on athlon x2 (fam 15 according to
cpuinfo)

See xen-devel post:
[Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64 X2
from 22.12.2011 ff</pre>
    </blockquote>
    Probably not. cpuinfo reports family in decimal. So your Athlon is
    Family 0xF; but Christoph's patch is for Family 0x15. For a quick
    verification, you can rename your AMD ucode (in
    /lib/firmware/amd-ucode) to prevent it from being loaded. <em><br>
    </em>
    <blockquote cite="mid:4F048368.2000204@gmx.de" type="cite">
      <pre wrap="">

Regards,
Florian

</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>
    <br>
  </body>
</html>

--------------070306080704030304010207--


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

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

--===============5864270976095197324==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 19:33:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:33:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWZH-0004zW-6s; Wed, 04 Jan 2012 19:32:11 +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 1RiWZF-0004zM-By
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:32:09 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325705521!2295963!1
X-Originating-IP: [216.32.180.14]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11115 invoked from network); 4 Jan 2012 19:32:02 -0000
Received: from va3ehsobe004.messaging.microsoft.com (HELO
	VA3EHSOBE004.bigfish.com) (216.32.180.14)
	by server-16.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 19:32:02 -0000
Received: from mail32-va3-R.bigfish.com (10.7.14.243) by
	VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:32:01 +0000
Received: from mail32-va3 (localhost [127.0.0.1])	by mail32-va3-R.bigfish.com
	(Postfix) with ESMTP id 3FB256C0243;
	Wed,  4 Jan 2012 19:32:01 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zzbb2dI9371Ic85dh1432N98dKzz1202hzz8275bhz2dh668h839h)
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 mail32-va3 (localhost.localdomain [127.0.0.1]) by mail32-va3
	(MessageSwitch) id 1325705519875696_3733;
	Wed,  4 Jan 2012 19:31:59 +0000 (UTC)
Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.244])	by
	mail32-va3.bigfish.com (Postfix) with ESMTP id C68D610004B;
	Wed,  4 Jan 2012 19:31:59 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:31:59 +0000
X-WSS-ID: 0LXAGX8-02-6KM-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 206C1C8009;	Wed,  4 Jan 2012 13:31:56 -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, 4 Jan 2012 13:32:09 -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; Wed, 4 Jan 2012
	13:31:57 -0600
Message-ID: <4F04A92D.7000301@amd.com>
Date: Wed, 4 Jan 2012 13:31:57 -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: Florian Manschwetus <florianmanschwetus@gmx.de>
References: <4F047035.1060304@amd.com> <4F048368.2000204@gmx.de>
In-Reply-To: <4F048368.2000204@gmx.de>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen 4.1: x86/ucode: fix for AMD Fam15 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: multipart/mixed; boundary="===============5864270976095197324=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5864270976095197324==
Content-Type: multipart/alternative;
	boundary="------------070306080704030304010207"

--------------070306080704030304010207
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 01/04/2012 10:50 AM, Florian Manschwetus wrote:
> Am 04.01.2012 16:28, schrieb Christoph Egger:
>> 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>
>> Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1
>>
> Could this fix my xen boot problem on athlon x2 (fam 15 according to
> cpuinfo)
>
> See xen-devel post:
> [Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64 X2
> from 22.12.2011 ff
Probably not. cpuinfo reports family in decimal. So your Athlon is 
Family 0xF; but Christoph's patch is for Family 0x15. For a quick 
verification, you can rename your AMD ucode (in /lib/firmware/amd-ucode) 
to prevent it from being loaded. /
/
>
> Regards,
> Florian
>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>


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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 01/04/2012 10:50 AM, Florian Manschwetus wrote:
    <blockquote cite="mid:4F048368.2000204@gmx.de" type="cite">
      <pre wrap="">Am 04.01.2012 16:28, schrieb Christoph Egger:
</pre>
      <blockquote type="cite">
        <pre wrap="">
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 <a class="moz-txt-link-rfc2396E" href="mailto:Christoph.Egger@amd.com">&lt;Christoph.Egger@amd.com&gt;</a>
Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1

</pre>
      </blockquote>
      <pre wrap="">Could this fix my xen boot problem on athlon x2 (fam 15 according to
cpuinfo)

See xen-devel post:
[Xen-devel] [Xen-users] Problem booting xen 4.1.2 on Athlon 64 X2
from 22.12.2011 ff</pre>
    </blockquote>
    Probably not. cpuinfo reports family in decimal. So your Athlon is
    Family 0xF; but Christoph's patch is for Family 0x15. For a quick
    verification, you can rename your AMD ucode (in
    /lib/firmware/amd-ucode) to prevent it from being loaded. <em><br>
    </em>
    <blockquote cite="mid:4F048368.2000204@gmx.de" type="cite">
      <pre wrap="">

Regards,
Florian

</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>
    <br>
  </body>
</html>

--------------070306080704030304010207--


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

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

--===============5864270976095197324==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 19:42:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWjA-0005AP-92; Wed, 04 Jan 2012 19:42:24 +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 1RiWj8-0005AK-Jc
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:42:22 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325706135!9613179!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13058 invoked from network); 4 Jan 2012 19:42:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	4 Jan 2012 19:42:16 -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 q04JgBvG027290
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 14:42:11 -0500
Received: from dragon.usersys.redhat.com (vpn-202-226.tlv.redhat.com
	[10.35.202.226])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q04Jg8Jp002311; Wed, 4 Jan 2012 14:42:09 -0500
Message-ID: <4F04AB90.2090504@redhat.com>
Date: Wed, 04 Jan 2012 21:42:08 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-18-git-send-email-avi@redhat.com>
	<alpine.DEB.2.00.1201041758570.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201041758570.3150@kaball-desktop>
X-Enigmail-Version: 1.3.4
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [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>
Content-Type: text/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/04/2012 08:06 PM, Stefano Stabellini wrote:
> On Mon, 19 Dec 2011, Avi Kivity wrote:
> > -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);
> >  }
>
> I really feel I should thank you for your work because you did a very
> good job porting xen to the new api. In fact apart from the dirty bitmap
> (Anthony is about to send a patch to fix the issue:
> xen_sync_dirty_bitmap can actually fail sometimes), everything else
> is done right and works correctly.

Thanks.

> However I would have appreciated if you could have given us more time to
> review the four patches you wrote: considering the time of the year both
> Anthony and I were on vacation and didn't have a chance to read them
> until today.

I realize that I bypassed the normal protocol here, but I had to choose
one of several bad choices:

- continue developing without merging, and risk large rebases in case
the patches (or something else in qemu) had to be changed
- stop developing until you returned from your (undoubtedly well
deserved) vacations
- merge and look away while whistling innocently

I chose the third, since I still have quite a lot of work with the
memory API.  Of course I will help with fixing the fallout if needed,
and since you're back online, we can go back to the normal way of
reviewing and testing patches before merging.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 19:42:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:42:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWjA-0005AP-92; Wed, 04 Jan 2012 19:42:24 +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 1RiWj8-0005AK-Jc
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:42:22 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325706135!9613179!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13058 invoked from network); 4 Jan 2012 19:42:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	4 Jan 2012 19:42:16 -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 q04JgBvG027290
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 14:42:11 -0500
Received: from dragon.usersys.redhat.com (vpn-202-226.tlv.redhat.com
	[10.35.202.226])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q04Jg8Jp002311; Wed, 4 Jan 2012 14:42:09 -0500
Message-ID: <4F04AB90.2090504@redhat.com>
Date: Wed, 04 Jan 2012 21:42:08 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-18-git-send-email-avi@redhat.com>
	<alpine.DEB.2.00.1201041758570.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201041758570.3150@kaball-desktop>
X-Enigmail-Version: 1.3.4
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [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>
Content-Type: text/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/04/2012 08:06 PM, Stefano Stabellini wrote:
> On Mon, 19 Dec 2011, Avi Kivity wrote:
> > -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);
> >  }
>
> I really feel I should thank you for your work because you did a very
> good job porting xen to the new api. In fact apart from the dirty bitmap
> (Anthony is about to send a patch to fix the issue:
> xen_sync_dirty_bitmap can actually fail sometimes), everything else
> is done right and works correctly.

Thanks.

> However I would have appreciated if you could have given us more time to
> review the four patches you wrote: considering the time of the year both
> Anthony and I were on vacation and didn't have a chance to read them
> until today.

I realize that I bypassed the normal protocol here, but I had to choose
one of several bad choices:

- continue developing without merging, and risk large rebases in case
the patches (or something else in qemu) had to be changed
- stop developing until you returned from your (undoubtedly well
deserved) vacations
- merge and look away while whistling innocently

I chose the third, since I still have quite a lot of work with the
memory API.  Of course I will help with fixing the fallout if needed,
and since you're back online, we can go back to the normal way of
reviewing and testing patches before merging.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 19:44:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWkb-0005EB-TP; Wed, 04 Jan 2012 19:43:53 +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 1RiWka-0005Do-4Z
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:43:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325706225!7853431!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTUwNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27874 invoked from network); 4 Jan 2012 19:43:46 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Jan 2012 19:43:46 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id C973B1DEB;
	Wed,  4 Jan 2012 21:43:43 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7DFD320056; Wed,  4 Jan 2012 21:43:43 +0200 (EET)
Date: Wed, 4 Jan 2012 21:43:43 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120104194343.GT12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F04A6CA.3010907@amd.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>
>>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>>> must haves e.g. in the paging/sharing spaces?
>>>
>> - What's the status of Nested Hardware Virtualization?
>> I remember some email saying Intel vmx-on-vmx has some performance issues,
>> and amd svm-on-svm works better..
>>
>>
>> - Also there's a bunch of VGA passthru related patches,
>> that I once volunteered to collect/rebase/cleanup/repost myself,
>> but I still haven't had time for that :(
> Since there were quite a lot of interest on this subject, should we  
> document it in a separate wiki for working combinations (like  
> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>

I actually once started writing down that kind of stuff:
http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html

Feel free to contribute :)

There's also:
http://wiki.xen.org/xenwiki/XenVGAPassthrough


-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 19:44:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:44:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWkb-0005EB-TP; Wed, 04 Jan 2012 19:43:53 +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 1RiWka-0005Do-4Z
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:43:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325706225!7853431!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTUwNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27874 invoked from network); 4 Jan 2012 19:43:46 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 4 Jan 2012 19:43:46 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id C973B1DEB;
	Wed,  4 Jan 2012 21:43:43 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 7DFD320056; Wed,  4 Jan 2012 21:43:43 +0200 (EET)
Date: Wed, 4 Jan 2012 21:43:43 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120104194343.GT12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F04A6CA.3010907@amd.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>
>>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>>> must haves e.g. in the paging/sharing spaces?
>>>
>> - What's the status of Nested Hardware Virtualization?
>> I remember some email saying Intel vmx-on-vmx has some performance issues,
>> and amd svm-on-svm works better..
>>
>>
>> - Also there's a bunch of VGA passthru related patches,
>> that I once volunteered to collect/rebase/cleanup/repost myself,
>> but I still haven't had time for that :(
> Since there were quite a lot of interest on this subject, should we  
> document it in a separate wiki for working combinations (like  
> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>

I actually once started writing down that kind of stuff:
http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html

Feel free to contribute :)

There's also:
http://wiki.xen.org/xenwiki/XenVGAPassthrough


-- Pasi


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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 19:59:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWyY-0005U6-Gr; Wed, 04 Jan 2012 19:58:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1RiWyX-0005U1-CS
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:58:17 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325707050!48958377!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 13921 invoked from network); 4 Jan 2012 19:57:31 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 19:57:31 -0000
Received: from mail92-tx2-R.bigfish.com (10.9.14.251) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:58:14 +0000
Received: from mail92-tx2 (localhost [127.0.0.1])	by mail92-tx2-R.bigfish.com
	(Postfix) with ESMTP id 941DF6040E;
	Wed,  4 Jan 2012 19:58:14 +0000 (UTC)
X-SpamScore: -17
X-BigFish: VPS-17(zzbb2dI9371Ic89bh1454I148cM1432N98dKzz1202hzz8275dhz2dh668h839h62h)
X-Spam-TCS-SCL: 1: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 mail92-tx2 (localhost.localdomain [127.0.0.1]) by mail92-tx2
	(MessageSwitch) id 132570705316672_22643;
	Wed,  4 Jan 2012 19:57:33 +0000 (UTC)
Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.252])	by
	mail92-tx2.bigfish.com (Postfix) with ESMTP id EDB3E5C004D;
	Wed,  4 Jan 2012 19:57:32 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:57:30 +0000
X-WSS-ID: 0LXAI3R-02-89H-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 2CF7FC8009;	Wed,  4 Jan 2012 13:57:26 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 4 Jan 2012 13:57:39 -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; Wed, 4 Jan 2012
	13:57:27 -0600
Message-ID: <4F04AF28.8040102@amd.com>
Date: Wed, 4 Jan 2012 13:57:28 -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: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
In-Reply-To: <20120104194343.GT12984@reaktio.net>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/04/2012 01:43 PM, Pasi K=E4rkk=E4inen wrote:
> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there a=
ny
>>>> must haves e.g. in the paging/sharing spaces?
>>>>
>>> - What's the status of Nested Hardware Virtualization?
>>> I remember some email saying Intel vmx-on-vmx has some performance issu=
es,
>>> and amd svm-on-svm works better..
>>>
>>>
>>> - Also there's a bunch of VGA passthru related patches,
>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>> but I still haven't had time for that :(
>> Since there were quite a lot of interest on this subject, should we
>> document it in a separate wiki for working combinations (like
>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>
> I actually once started writing down that kind of stuff:
> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>
> Feel free to contribute :)
>
> There's also:
> http://wiki.xen.org/xenwiki/XenVGAPassthrough
Thanks for sharing. I will contribute my findings as needed. BTW, do you =

need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a =

dilemma for several reasons:  it doesn't always work; sometimes it can =

screw up main display while passthru 2nd GPUs. Plus the recent Catalyst =

driver seems very stable even without these patches. But Wei Wang told =

me that he needs them for some of his cards.
>
> -- Pasi
>
>



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 19:59:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 19:59:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiWyY-0005U6-Gr; Wed, 04 Jan 2012 19:58:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1RiWyX-0005U1-CS
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 19:58:17 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325707050!48958377!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 13921 invoked from network); 4 Jan 2012 19:57:31 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	4 Jan 2012 19:57:31 -0000
Received: from mail92-tx2-R.bigfish.com (10.9.14.251) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:58:14 +0000
Received: from mail92-tx2 (localhost [127.0.0.1])	by mail92-tx2-R.bigfish.com
	(Postfix) with ESMTP id 941DF6040E;
	Wed,  4 Jan 2012 19:58:14 +0000 (UTC)
X-SpamScore: -17
X-BigFish: VPS-17(zzbb2dI9371Ic89bh1454I148cM1432N98dKzz1202hzz8275dhz2dh668h839h62h)
X-Spam-TCS-SCL: 1: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 mail92-tx2 (localhost.localdomain [127.0.0.1]) by mail92-tx2
	(MessageSwitch) id 132570705316672_22643;
	Wed,  4 Jan 2012 19:57:33 +0000 (UTC)
Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.252])	by
	mail92-tx2.bigfish.com (Postfix) with ESMTP id EDB3E5C004D;
	Wed,  4 Jan 2012 19:57:32 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server id
	14.1.225.23; Wed, 4 Jan 2012 19:57:30 +0000
X-WSS-ID: 0LXAI3R-02-89H-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 2CF7FC8009;	Wed,  4 Jan 2012 13:57:26 -0600 (CST)
Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 4 Jan 2012 13:57:39 -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; Wed, 4 Jan 2012
	13:57:27 -0600
Message-ID: <4F04AF28.8040102@amd.com>
Date: Wed, 4 Jan 2012 13:57:28 -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: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
In-Reply-To: <20120104194343.GT12984@reaktio.net>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/04/2012 01:43 PM, Pasi K=E4rkk=E4inen wrote:
> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there a=
ny
>>>> must haves e.g. in the paging/sharing spaces?
>>>>
>>> - What's the status of Nested Hardware Virtualization?
>>> I remember some email saying Intel vmx-on-vmx has some performance issu=
es,
>>> and amd svm-on-svm works better..
>>>
>>>
>>> - Also there's a bunch of VGA passthru related patches,
>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>> but I still haven't had time for that :(
>> Since there were quite a lot of interest on this subject, should we
>> document it in a separate wiki for working combinations (like
>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>
> I actually once started writing down that kind of stuff:
> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>
> Feel free to contribute :)
>
> There's also:
> http://wiki.xen.org/xenwiki/XenVGAPassthrough
Thanks for sharing. I will contribute my findings as needed. BTW, do you =

need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a =

dilemma for several reasons:  it doesn't always work; sometimes it can =

screw up main display while passthru 2nd GPUs. Plus the recent Catalyst =

driver seems very stable even without these patches. But Wei Wang told =

me that he needs them for some of his cards.
>
> -- Pasi
>
>



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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 21:02:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:02:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiXxc-0006HL-40; Wed, 04 Jan 2012 21:01:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <diegop@cs.princeton.edu>) id 1RiXxa-0006HG-Kq
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:01:22 +0000
X-Env-Sender: diegop@cs.princeton.edu
X-Msg-Ref: server-13.tower-27.messagelabs.com!1325710851!54419182!1
X-Originating-IP: [128.112.136.38]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25136 invoked from network); 4 Jan 2012 21:00:52 -0000
Received: from bluebox.cs.princeton.edu (HELO bluebox.CS.Princeton.EDU)
	(128.112.136.38)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 21:00:52 -0000
Received: from suckerpunch-mbx-0.cs.princeton.edu
	(suckerpunch-mbx-0.CS.Princeton.EDU [128.112.136.41])
	by bluebox.CS.Princeton.EDU (8.13.8/8.13.8) with ESMTP id
	q04L1GWM004217
	for <xen-devel@lists.xensource.com>; Wed, 4 Jan 2012 16:01:16 -0500
Date: Wed, 04 Jan 2012 16:01:15 -0500 (EST)
From: Diego Perez Botero <diegop@CS.Princeton.EDU>
To: xen-devel@lists.xensource.com
Message-ID: <7d62feea-9ca1-41e7-b321-c424b78941b8@suckerpunch-mbx-0.CS.Princeton.EDU>
In-Reply-To: <189d906c-385f-4a54-bdcd-af463e6fbd4a@suckerpunch-mbx-0.CS.Princeton.EDU>
MIME-Version: 1.0
X-Originating-IP: [68.46.180.12]
X-Mailer: Zimbra 7.1.3_GA_3374 (ZimbraWebClient - FF3.0 (Win)/7.1.3_GA_3346)
Subject: [Xen-devel] Xentrace isn't reporting any VMEXITs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dear xen-devel members,

My name is Diego Perez-Botero and I'm a Computer Science Master's Degree student from Princeton University. I'm trying to analyze VM exits in the Xen Hypervisor, but I haven't been able to find evidence of any VM exits up until now. I followed the "Fedora13Xen4Tutorial" tutorial from the Xen Wiki (http://wiki.xen.org/xenwiki/Fedora13Xen4Tutorial.html) and have the whole setup running smoothly on my laptop. Here's what I have:

- Fedora Xen 4.0 with Linux 2.6.32.50 pvops dom0
- A CentOS 5.5 DomU guest host running on that Xen installation

I'm using the command "xentrace -e 0x81000 trace.out" on my Fedora Xen to capture TRC_HVM_ENTRYEXIT events. While the xentrace is listening, I'm restarting the CentOS DomU host. When CentOS boots up again, I'm running Apache HTTP Server on it as well as some assembly code that I wrote which includes a call to CPUID. The CPUID call returns without any problems and the HTTP Server works as it's supposed to, so I then stop the xentrace command that has been running on my Fedora Xen only to find an empty trace file (0 bytes).

If I do "xentrace -e all trace.out", a lot of hypercalls and other events are logged (I use "cat trace.out| xentrace_format formats | more" to read the output file), so my xentrace is indeed working. From what I've read, the CPUID call and the Apache server should generate at least 1 VMEXIT, so I don't understand why no VMEXIT events are being logged.

I have googled a lot on the topic and haven't found any information regarding this sort of behavior. Any help is greatly appreciated.

Am I missing something? Do I have to recompile the Xen source with some specific flags? Do you know any VMEXIT-intensive programs that I can use to generate VM exits?

Thanks for your time. I apologize if this is a "newbie" question...I'm a Networking guy and this topic is completely new to me.

Happy New Year!

-Diego

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 21:02:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:02:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiXxc-0006HL-40; Wed, 04 Jan 2012 21:01:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <diegop@cs.princeton.edu>) id 1RiXxa-0006HG-Kq
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:01:22 +0000
X-Env-Sender: diegop@cs.princeton.edu
X-Msg-Ref: server-13.tower-27.messagelabs.com!1325710851!54419182!1
X-Originating-IP: [128.112.136.38]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25136 invoked from network); 4 Jan 2012 21:00:52 -0000
Received: from bluebox.cs.princeton.edu (HELO bluebox.CS.Princeton.EDU)
	(128.112.136.38)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 21:00:52 -0000
Received: from suckerpunch-mbx-0.cs.princeton.edu
	(suckerpunch-mbx-0.CS.Princeton.EDU [128.112.136.41])
	by bluebox.CS.Princeton.EDU (8.13.8/8.13.8) with ESMTP id
	q04L1GWM004217
	for <xen-devel@lists.xensource.com>; Wed, 4 Jan 2012 16:01:16 -0500
Date: Wed, 04 Jan 2012 16:01:15 -0500 (EST)
From: Diego Perez Botero <diegop@CS.Princeton.EDU>
To: xen-devel@lists.xensource.com
Message-ID: <7d62feea-9ca1-41e7-b321-c424b78941b8@suckerpunch-mbx-0.CS.Princeton.EDU>
In-Reply-To: <189d906c-385f-4a54-bdcd-af463e6fbd4a@suckerpunch-mbx-0.CS.Princeton.EDU>
MIME-Version: 1.0
X-Originating-IP: [68.46.180.12]
X-Mailer: Zimbra 7.1.3_GA_3374 (ZimbraWebClient - FF3.0 (Win)/7.1.3_GA_3346)
Subject: [Xen-devel] Xentrace isn't reporting any VMEXITs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dear xen-devel members,

My name is Diego Perez-Botero and I'm a Computer Science Master's Degree student from Princeton University. I'm trying to analyze VM exits in the Xen Hypervisor, but I haven't been able to find evidence of any VM exits up until now. I followed the "Fedora13Xen4Tutorial" tutorial from the Xen Wiki (http://wiki.xen.org/xenwiki/Fedora13Xen4Tutorial.html) and have the whole setup running smoothly on my laptop. Here's what I have:

- Fedora Xen 4.0 with Linux 2.6.32.50 pvops dom0
- A CentOS 5.5 DomU guest host running on that Xen installation

I'm using the command "xentrace -e 0x81000 trace.out" on my Fedora Xen to capture TRC_HVM_ENTRYEXIT events. While the xentrace is listening, I'm restarting the CentOS DomU host. When CentOS boots up again, I'm running Apache HTTP Server on it as well as some assembly code that I wrote which includes a call to CPUID. The CPUID call returns without any problems and the HTTP Server works as it's supposed to, so I then stop the xentrace command that has been running on my Fedora Xen only to find an empty trace file (0 bytes).

If I do "xentrace -e all trace.out", a lot of hypercalls and other events are logged (I use "cat trace.out| xentrace_format formats | more" to read the output file), so my xentrace is indeed working. From what I've read, the CPUID call and the Apache server should generate at least 1 VMEXIT, so I don't understand why no VMEXIT events are being logged.

I have googled a lot on the topic and haven't found any information regarding this sort of behavior. Any help is greatly appreciated.

Am I missing something? Do I have to recompile the Xen source with some specific flags? Do you know any VMEXIT-intensive programs that I can use to generate VM exits?

Thanks for your time. I apologize if this is a "newbie" question...I'm a Networking guy and this topic is completely new to me.

Happy New Year!

-Diego

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 21:09:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiY4b-0006PN-0U; Wed, 04 Jan 2012 21:08: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 1RiY4Z-0006PH-39
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:08:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325711308!9561379!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24762 invoked from network); 4 Jan 2012 21:08:28 -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;
	4 Jan 2012 21:08:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,458,1320624000"; 
   d="scan'208";a="9822974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 21:08:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 21:08: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 1RiY4S-0002Kp-6Y;
	Wed, 04 Jan 2012 21:08:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RiY4S-000416-0B;
	Wed, 04 Jan 2012 21:08:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10631-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Jan 2012 21:08:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10631: 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 10631 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10631/

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

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-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-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  efaa28639a71
baseline version:
 xen                  50117a4d1a2c

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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:   24452:efaa28639a71
tag:         tip
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Wed Jan 04 16:12:44 2012 +0000
    
    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>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24451:d82be53b3ea1
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Wed Jan 04 16:11:46 2012 +0000
    
    All domains (including dom0) should be best effort on 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>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24450:50117a4d1a2c
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:43:07 2012 +0000
    
    x86/tboot: fix some coding style issues in tboot.c
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Acked-by:  Joseph Cihula <joseph.cihula@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
========================================
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 Wed Jan 04 21:09:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiY4b-0006PN-0U; Wed, 04 Jan 2012 21:08: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 1RiY4Z-0006PH-39
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:08:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325711308!9561379!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTM3Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24762 invoked from network); 4 Jan 2012 21:08:28 -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;
	4 Jan 2012 21:08:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,458,1320624000"; 
   d="scan'208";a="9822974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	04 Jan 2012 21:08:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 4 Jan 2012 21:08: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 1RiY4S-0002Kp-6Y;
	Wed, 04 Jan 2012 21:08:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RiY4S-000416-0B;
	Wed, 04 Jan 2012 21:08:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10631-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 4 Jan 2012 21:08:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10631: 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 10631 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10631/

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

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-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-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  efaa28639a71
baseline version:
 xen                  50117a4d1a2c

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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:   24452:efaa28639a71
tag:         tip
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Wed Jan 04 16:12:44 2012 +0000
    
    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>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24451:d82be53b3ea1
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Wed Jan 04 16:11:46 2012 +0000
    
    All domains (including dom0) should be best effort on 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>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24450:50117a4d1a2c
user:        Gang Wei <gang.wei@intel.com>
date:        Mon Jan 02 12:43:07 2012 +0000
    
    x86/tboot: fix some coding style issues in tboot.c
    
    Signed-off-by: Gang Wei <gang.wei@intel.com>
    Acked-by:  Joseph Cihula <joseph.cihula@intel.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
========================================
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 Wed Jan 04 21:50:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiYin-0006ir-KR; Wed, 04 Jan 2012 21:50:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiYil-0006im-KD
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:50:07 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325713764!58953300!1
X-Originating-IP: [203.16.224.4]
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 21513 invoked from network); 4 Jan 2012 21:49:27 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 21:49:27 -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 1RiYib-0000n5-2k; Thu, 05 Jan 2012 08:49:57 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 5 Jan 2012 08:49:57 +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;
	Thu, 5 Jan 2012 08:49:57 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen-scsiback allow RESERVE/RELEASE commands
Thread-Index: AczLKkvV2QKwDC92TbiQ3O1j1iJioQ==
Date: Wed, 4 Jan 2012 21:49:55 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0955C7@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: 04 Jan 2012 21:49:57.0232 (UTC)
	FILETIME=[CCD29700:01CCCB2A]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] xen-scsiback allow RESERVE/RELEASE 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

Some Windows software makes use of RESERVE/RELEASE SCSI commands. Allow them through scsiback, without any emulation.

Signed-off-by: James Harper <james.harper@bendigoit.com.au>

--- a/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 10:51:36.090985303 +1100
+++ b/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 13:28:23.288336520 +1100
@@ -401,8 +401,8 @@
        NO_EMULATE(INQUIRY);               /*0x12*/
        /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
        NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
-       /*NO_EMULATE(RESERVE);               *//*0x16*/
-       /*NO_EMULATE(RELEASE);               *//*0x17*/
+       NO_EMULATE(RESERVE);               /*0x16*/
+       NO_EMULATE(RELEASE);               /*0x17*/
        /*NO_EMULATE(COPY);                  *//*0x18*/
        NO_EMULATE(ERASE);                 /*0x19*/ /* st */
        NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 21:50:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:50:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiYin-0006ir-KR; Wed, 04 Jan 2012 21:50:09 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RiYil-0006im-KD
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:50:07 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325713764!58953300!1
X-Originating-IP: [203.16.224.4]
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 21513 invoked from network); 4 Jan 2012 21:49:27 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	4 Jan 2012 21:49:27 -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 1RiYib-0000n5-2k; Thu, 05 Jan 2012 08:49:57 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 5 Jan 2012 08:49:57 +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;
	Thu, 5 Jan 2012 08:49:57 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [PATCH] xen-scsiback allow RESERVE/RELEASE commands
Thread-Index: AczLKkvV2QKwDC92TbiQ3O1j1iJioQ==
Date: Wed, 4 Jan 2012 21:49:55 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0955C7@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: 04 Jan 2012 21:49:57.0232 (UTC)
	FILETIME=[CCD29700:01CCCB2A]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [PATCH] xen-scsiback allow RESERVE/RELEASE 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

Some Windows software makes use of RESERVE/RELEASE SCSI commands. Allow them through scsiback, without any emulation.

Signed-off-by: James Harper <james.harper@bendigoit.com.au>

--- a/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 10:51:36.090985303 +1100
+++ b/drivers/scsi/xen-scsiback/emulate.c   2012-01-04 13:28:23.288336520 +1100
@@ -401,8 +401,8 @@
        NO_EMULATE(INQUIRY);               /*0x12*/
        /*NO_EMULATE(RECOVER_BUFFERED_DATA); *//*0x14*/
        NO_EMULATE(MODE_SELECT);           /*0x15*/ /* st */
-       /*NO_EMULATE(RESERVE);               *//*0x16*/
-       /*NO_EMULATE(RELEASE);               *//*0x17*/
+       NO_EMULATE(RESERVE);               /*0x16*/
+       NO_EMULATE(RELEASE);               /*0x17*/
        /*NO_EMULATE(COPY);                  *//*0x18*/
        NO_EMULATE(ERASE);                 /*0x19*/ /* st */
        NO_EMULATE(MODE_SENSE);            /*0x1a*/ /* st */

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 21:57:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiYpY-0006sK-GT; Wed, 04 Jan 2012 21:57:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <shemminger@vyatta.com>) id 1RiYpX-0006s9-Hk
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:57:07 +0000
X-Env-Sender: shemminger@vyatta.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1325714221!9688045!1
X-Originating-IP: [76.74.103.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1841 invoked from network); 4 Jan 2012 21:57:01 -0000
Received: from mail.vyatta.com (HELO mail.vyatta.com) (76.74.103.46)
	by server-14.tower-21.messagelabs.com with SMTP;
	4 Jan 2012 21:57:01 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.vyatta.com (Postfix) with ESMTP id 9B973141001A;
	Wed,  4 Jan 2012 13:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at tahiti.vyatta.com
Received: from mail.vyatta.com ([127.0.0.1])
	by localhost (mail.vyatta.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id qZEehh44A9S4; Wed,  4 Jan 2012 13:57:00 -0800 (PST)
Received: from nehalam.linuxnetplumber.net
	(static-50-53-80-93.bvtn.or.frontiernet.net [50.53.80.93])
	by mail.vyatta.com (Postfix) with ESMTPSA id CE8851410015;
	Wed,  4 Jan 2012 13:56:59 -0800 (PST)
Date: Wed, 4 Jan 2012 13:56:58 -0800
From: Stephen Hemminger <shemminger@vyatta.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
Organization: Vyatta
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xen-netback: make ops structs const
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 tables of function pointers should be const to make hacks
more difficult. Compile tested only.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
Patch against net-next

--- a/drivers/net/xen-netback/interface.c	2011-12-07 10:54:19.232282492 -0800
+++ b/drivers/net/xen-netback/interface.c	2012-01-04 13:16:04.414052721 -0800
@@ -223,7 +223,7 @@ static void xenvif_get_strings(struct ne
 	}
 }
 
-static struct ethtool_ops xenvif_ethtool_ops = {
+static const struct ethtool_ops xenvif_ethtool_ops = {
 	.get_link	= ethtool_op_get_link,
 
 	.get_sset_count = xenvif_get_sset_count,
@@ -231,7 +231,7 @@ static struct ethtool_ops xenvif_ethtool
 	.get_strings = xenvif_get_strings,
 };
 
-static struct net_device_ops xenvif_netdev_ops = {
+static const struct net_device_ops xenvif_netdev_ops = {
 	.ndo_start_xmit	= xenvif_start_xmit,
 	.ndo_get_stats	= xenvif_get_stats,
 	.ndo_open	= xenvif_open,

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 21:57:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiYpY-0006sK-GT; Wed, 04 Jan 2012 21:57:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <shemminger@vyatta.com>) id 1RiYpX-0006s9-Hk
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:57:07 +0000
X-Env-Sender: shemminger@vyatta.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1325714221!9688045!1
X-Originating-IP: [76.74.103.46]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1841 invoked from network); 4 Jan 2012 21:57:01 -0000
Received: from mail.vyatta.com (HELO mail.vyatta.com) (76.74.103.46)
	by server-14.tower-21.messagelabs.com with SMTP;
	4 Jan 2012 21:57:01 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.vyatta.com (Postfix) with ESMTP id 9B973141001A;
	Wed,  4 Jan 2012 13:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at tahiti.vyatta.com
Received: from mail.vyatta.com ([127.0.0.1])
	by localhost (mail.vyatta.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id qZEehh44A9S4; Wed,  4 Jan 2012 13:57:00 -0800 (PST)
Received: from nehalam.linuxnetplumber.net
	(static-50-53-80-93.bvtn.or.frontiernet.net [50.53.80.93])
	by mail.vyatta.com (Postfix) with ESMTPSA id CE8851410015;
	Wed,  4 Jan 2012 13:56:59 -0800 (PST)
Date: Wed, 4 Jan 2012 13:56:58 -0800
From: Stephen Hemminger <shemminger@vyatta.com>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
Organization: Vyatta
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xen-netback: make ops structs const
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 tables of function pointers should be const to make hacks
more difficult. Compile tested only.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
Patch against net-next

--- a/drivers/net/xen-netback/interface.c	2011-12-07 10:54:19.232282492 -0800
+++ b/drivers/net/xen-netback/interface.c	2012-01-04 13:16:04.414052721 -0800
@@ -223,7 +223,7 @@ static void xenvif_get_strings(struct ne
 	}
 }
 
-static struct ethtool_ops xenvif_ethtool_ops = {
+static const struct ethtool_ops xenvif_ethtool_ops = {
 	.get_link	= ethtool_op_get_link,
 
 	.get_sset_count = xenvif_get_sset_count,
@@ -231,7 +231,7 @@ static struct ethtool_ops xenvif_ethtool
 	.get_strings = xenvif_get_strings,
 };
 
-static struct net_device_ops xenvif_netdev_ops = {
+static const struct net_device_ops xenvif_netdev_ops = {
 	.ndo_start_xmit	= xenvif_start_xmit,
 	.ndo_get_stats	= xenvif_get_stats,
 	.ndo_open	= xenvif_open,

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 21:58:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiYpz-0006tc-Tf; Wed, 04 Jan 2012 21:57:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <allen.m.kay@intel.com>) id 1RiYpy-0006tT-Th
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:57:35 +0000
X-Env-Sender: allen.m.kay@intel.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325714247!7858532!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE4OTEz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16082 invoked from network); 4 Jan 2012 21:57:28 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-174.messagelabs.com with SMTP;
	4 Jan 2012 21:57:28 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 04 Jan 2012 13:57:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="92443500"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by azsmga001.ch.intel.com with ESMTP; 04 Jan 2012 13:57:25 -0800
Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 4 Jan 2012 13:57:10 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.103]) by
	ORSMSX151.amr.corp.intel.com ([169.254.7.136]) with mapi id
	14.01.0355.002; Wed, 4 Jan 2012 13:57:10 -0800
From: "Kay, Allen M" <allen.m.kay@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] fix build error
Thread-Index: AczLK8zK7RjF54cjTYKnT04N5kw6aw==
Date: Wed, 4 Jan 2012 21:57:09 +0000
Message-ID: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
Content-Type: multipart/mixed;
	boundary="_004_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_"
MIME-Version: 1.0
Cc: "anthony.perard@citrix.com" <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH] fix build 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_004_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_
Content-Type: multipart/alternative;
	boundary="_000_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_"

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

Attached patch fix build error in latest xen-unstable.hg.

Signed-off-by: Allen Kay <allen.m.kay@intel.com<mailto:allen.m.kay@intel.co=
m>>


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Attached patch fix build error in latest xen-unstabl=
e.hg.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Signed-off-by: Allen Kay &lt;<a href=3D"mailto:allen=
.m.kay@intel.com">allen.m.kay@intel.com</a>&gt;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_--

--_004_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_
Content-Type: application/octet-stream; name="build-error.patch"
Content-Description: build-error.patch
Content-Disposition: attachment; filename="build-error.patch"; size=664;
	creation-date="Wed, 04 Jan 2012 21:55:04 GMT";
	modification-date="Wed, 04 Jan 2012 21:51:44 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciA1MDExN2E0ZDFhMmMgdG9vbHMvbGlieGwvbGlieGxfanNvbi5jCi0tLSBhL3Rvb2xz
L2xpYnhsL2xpYnhsX2pzb24uYwlNb24gSmFuIDAyIDEyOjQzOjA3IDIwMTIgKzAwMDAKKysrIGIv
dG9vbHMvbGlieGwvbGlieGxfanNvbi5jCVdlZCBKYW4gMDQgMTM6NTE6MDAgMjAxMiAtMDgwMApA
QCAtODIwLDkgKzgyMCw5IEBAIHN0YXRpYyBjb25zdCBjaGFyICp5YWpsX2dlbl9zdGF0dXNfdG9f
c3QKICAgICAgICAgICAgIHJldHVybiAiZ2VuZXJhdGlvbiBjb21wbGV0ZSI7CiAgICAgICAgIGNh
c2UgeWFqbF9nZW5faW52YWxpZF9udW1iZXI6CiAgICAgICAgICAgICByZXR1cm4gImludmFsaWQg
bnVtYmVyIjsKKyNpZiAwIC8qIFRoaXMgaXMgaW4gdGhlIGRvY3MgYnV0IG5vdCBpbXBsZW1lbnRl
ZCBpbiB0aGUgdmVyc2lvbiBJIGFtIHJ1bm5pbmcuICovCiAgICAgICAgIGNhc2UgeWFqbF9nZW5f
bm9fYnVmOgogICAgICAgICAgICAgcmV0dXJuICJubyBidWZmZXIiOwotI2lmIDAgLyogVGhpcyBp
cyBpbiB0aGUgZG9jcyBidXQgbm90IGltcGxlbWVudGVkIGluIHRoZSB2ZXJzaW9uIEkgYW0gcnVu
bmluZy4gKi8KICAgICAgICAgY2FzZSB5YWpsX2dlbl9pbnZhbGlkX3N0cmluZzoKICAgICAgICAg
ICAgIHJldHVybiAiaW52YWxpZCBzdHJpbmciOwogI2VuZGlmCg==

--_004_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 21:58:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 21:58:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiYpz-0006tc-Tf; Wed, 04 Jan 2012 21:57:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <allen.m.kay@intel.com>) id 1RiYpy-0006tT-Th
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 21:57:35 +0000
X-Env-Sender: allen.m.kay@intel.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325714247!7858532!1
X-Originating-IP: [143.182.124.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMjEgPT4gMjE4OTEz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16082 invoked from network); 4 Jan 2012 21:57:28 -0000
Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21)
	by server-6.tower-174.messagelabs.com with SMTP;
	4 Jan 2012 21:57:28 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 04 Jan 2012 13:57:27 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="92443500"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by azsmga001.ch.intel.com with ESMTP; 04 Jan 2012 13:57:25 -0800
Received: from orsmsx151.amr.corp.intel.com (10.22.226.38) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 4 Jan 2012 13:57:10 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.103]) by
	ORSMSX151.amr.corp.intel.com ([169.254.7.136]) with mapi id
	14.01.0355.002; Wed, 4 Jan 2012 13:57:10 -0800
From: "Kay, Allen M" <allen.m.kay@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] fix build error
Thread-Index: AczLK8zK7RjF54cjTYKnT04N5kw6aw==
Date: Wed, 4 Jan 2012 21:57:09 +0000
Message-ID: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
Content-Type: multipart/mixed;
	boundary="_004_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_"
MIME-Version: 1.0
Cc: "anthony.perard@citrix.com" <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH] fix build 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--_004_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_
Content-Type: multipart/alternative;
	boundary="_000_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_"

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

Attached patch fix build error in latest xen-unstable.hg.

Signed-off-by: Allen Kay <allen.m.kay@intel.com<mailto:allen.m.kay@intel.co=
m>>


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Attached patch fix build error in latest xen-unstabl=
e.hg.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Signed-off-by: Allen Kay &lt;<a href=3D"mailto:allen=
.m.kay@intel.com">allen.m.kay@intel.com</a>&gt;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_--

--_004_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_
Content-Type: application/octet-stream; name="build-error.patch"
Content-Description: build-error.patch
Content-Disposition: attachment; filename="build-error.patch"; size=664;
	creation-date="Wed, 04 Jan 2012 21:55:04 GMT";
	modification-date="Wed, 04 Jan 2012 21:51:44 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciA1MDExN2E0ZDFhMmMgdG9vbHMvbGlieGwvbGlieGxfanNvbi5jCi0tLSBhL3Rvb2xz
L2xpYnhsL2xpYnhsX2pzb24uYwlNb24gSmFuIDAyIDEyOjQzOjA3IDIwMTIgKzAwMDAKKysrIGIv
dG9vbHMvbGlieGwvbGlieGxfanNvbi5jCVdlZCBKYW4gMDQgMTM6NTE6MDAgMjAxMiAtMDgwMApA
QCAtODIwLDkgKzgyMCw5IEBAIHN0YXRpYyBjb25zdCBjaGFyICp5YWpsX2dlbl9zdGF0dXNfdG9f
c3QKICAgICAgICAgICAgIHJldHVybiAiZ2VuZXJhdGlvbiBjb21wbGV0ZSI7CiAgICAgICAgIGNh
c2UgeWFqbF9nZW5faW52YWxpZF9udW1iZXI6CiAgICAgICAgICAgICByZXR1cm4gImludmFsaWQg
bnVtYmVyIjsKKyNpZiAwIC8qIFRoaXMgaXMgaW4gdGhlIGRvY3MgYnV0IG5vdCBpbXBsZW1lbnRl
ZCBpbiB0aGUgdmVyc2lvbiBJIGFtIHJ1bm5pbmcuICovCiAgICAgICAgIGNhc2UgeWFqbF9nZW5f
bm9fYnVmOgogICAgICAgICAgICAgcmV0dXJuICJubyBidWZmZXIiOwotI2lmIDAgLyogVGhpcyBp
cyBpbiB0aGUgZG9jcyBidXQgbm90IGltcGxlbWVudGVkIGluIHRoZSB2ZXJzaW9uIEkgYW0gcnVu
bmluZy4gKi8KICAgICAgICAgY2FzZSB5YWpsX2dlbl9pbnZhbGlkX3N0cmluZzoKICAgICAgICAg
ICAgIHJldHVybiAiaW52YWxpZCBzdHJpbmciOwogI2VuZGlmCg==

--_004_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_003AAFE53969E14CB1F09B6FD68C3CD4019C28ORSMSX105amrcorpi_--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 22:08:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 22: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 1RiYzk-0007FR-1S; Wed, 04 Jan 2012 22:07:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <allen.m.kay@intel.com>) id 1RiYzi-0007FM-PT
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 22:07:39 +0000
X-Env-Sender: allen.m.kay@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1325714851!10293767!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NzQ4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13103 invoked from network); 4 Jan 2012 22:07:32 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-21.messagelabs.com with SMTP;
	4 Jan 2012 22:07:32 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 04 Jan 2012 14:07:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="92447495"
Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87])
	by azsmga001.ch.intel.com with ESMTP; 04 Jan 2012 14:07:30 -0800
Received: from orsmsx106.amr.corp.intel.com (10.22.225.133) by
	orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 4 Jan 2012 14:07:30 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.103]) by
	ORSMSX106.amr.corp.intel.com ([169.254.5.229]) with mapi id
	14.01.0355.002; Wed, 4 Jan 2012 14:07:30 -0800
From: "Kay, Allen M" <allen.m.kay@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: problems I encountered using xen-4.1-testing and xen-unstable
Thread-Index: AczLLT9tAGqCvTvcRECKFQVKnVpssw==
Date: Wed, 4 Jan 2012 22:07:29 +0000
Message-ID: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.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.139]
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"'keir@xen.org'" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] problems I encountered using xen-4.1-testing and
	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: multipart/mixed; boundary="===============1202393681981804278=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1202393681981804278==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_003AAFE53969E14CB1F09B6FD68C3CD4019CB9ORSMSX105amrcorpi_"

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

I'm encountering following problems while using the latest xen-4.1-testing =
and xen-unstable with the latest Linux 3.2 kernel:


1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat =
/proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen=
 and dom0 Linux.  Native Linux reports correct memory size.



2)      Xen-unstable:  I get ext4 file system corruption when booting xen w=
ith the latest upstream Linux kernel.

Has anyone seen these two problems?

Allen

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	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;}
.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;}
/* List Definitions */
@list l0
	{mso-list-id:871771448;
	mso-list-type:hybrid;
	mso-list-template-ids:1236142738 67698705 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></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">I&#8217;m encountering following problems while usin=
g the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 ker=
nel:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">1)<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB sys=
tem, using &#8220;cat /proc/meminfo&#8221;.&nbsp; This is without dom_mem b=
oot parameter and with 64-bit Xen and dom0 Linux.&nbsp; Native Linux report=
s correct memory size.<o:p></o:p></p>
<p class=3D"MsoListParagraph"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">2)<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Xen-unstable: &nbsp;I get ext4 file system corrupti=
on when booting xen with the latest upstream Linux kernel.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Has anyone seen these two problems?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Allen<o:p></o:p></p>
</div>
</body>
</html>

--_000_003AAFE53969E14CB1F09B6FD68C3CD4019CB9ORSMSX105amrcorpi_--


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

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

--===============1202393681981804278==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 22:08:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 22: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 1RiYzk-0007FR-1S; Wed, 04 Jan 2012 22:07:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <allen.m.kay@intel.com>) id 1RiYzi-0007FM-PT
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 22:07:39 +0000
X-Env-Sender: allen.m.kay@intel.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1325714851!10293767!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjE5NzQ4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13103 invoked from network); 4 Jan 2012 22:07:32 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-10.tower-21.messagelabs.com with SMTP;
	4 Jan 2012 22:07:32 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 04 Jan 2012 14:07:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="92447495"
Received: from orsmsx604.amr.corp.intel.com ([10.22.226.87])
	by azsmga001.ch.intel.com with ESMTP; 04 Jan 2012 14:07:30 -0800
Received: from orsmsx106.amr.corp.intel.com (10.22.225.133) by
	orsmsx604.amr.corp.intel.com (10.22.226.87) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Wed, 4 Jan 2012 14:07:30 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.103]) by
	ORSMSX106.amr.corp.intel.com ([169.254.5.229]) with mapi id
	14.01.0355.002; Wed, 4 Jan 2012 14:07:30 -0800
From: "Kay, Allen M" <allen.m.kay@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: problems I encountered using xen-4.1-testing and xen-unstable
Thread-Index: AczLLT9tAGqCvTvcRECKFQVKnVpssw==
Date: Wed, 4 Jan 2012 22:07:29 +0000
Message-ID: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.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.139]
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"'keir@xen.org'" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] problems I encountered using xen-4.1-testing and
	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: multipart/mixed; boundary="===============1202393681981804278=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1202393681981804278==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_003AAFE53969E14CB1F09B6FD68C3CD4019CB9ORSMSX105amrcorpi_"

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

I'm encountering following problems while using the latest xen-4.1-testing =
and xen-unstable with the latest Linux 3.2 kernel:


1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat =
/proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen=
 and dom0 Linux.  Native Linux reports correct memory size.



2)      Xen-unstable:  I get ext4 file system corruption when booting xen w=
ith the latest upstream Linux kernel.

Has anyone seen these two problems?

Allen

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	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;}
.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;}
/* List Definitions */
@list l0
	{mso-list-id:871771448;
	mso-list-type:hybrid;
	mso-list-template-ids:1236142738 67698705 67698713 67698715 67698703 67698=
713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></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">I&#8217;m encountering following problems while usin=
g the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 ker=
nel:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">1)<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB sys=
tem, using &#8220;cat /proc/meminfo&#8221;.&nbsp; This is without dom_mem b=
oot parameter and with 64-bit Xen and dom0 Linux.&nbsp; Native Linux report=
s correct memory size.<o:p></o:p></p>
<p class=3D"MsoListParagraph"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">2)<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Xen-unstable: &nbsp;I get ext4 file system corrupti=
on when booting xen with the latest upstream Linux kernel.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Has anyone seen these two problems?<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Allen<o:p></o:p></p>
</div>
</body>
</html>

--_000_003AAFE53969E14CB1F09B6FD68C3CD4019CB9ORSMSX105amrcorpi_--


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

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

--===============1202393681981804278==--


From xen-devel-bounces@lists.xensource.com Wed Jan 04 23:03:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 23:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiZqp-0007a8-Dm; Wed, 04 Jan 2012 23:02:31 +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 1RiZqo-0007a3-6f
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 23:02:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325718109!54695450!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 22637 invoked from network); 4 Jan 2012 23:01:51 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 23:01:50 -0000
Received: by iagw33 with SMTP id w33so154842908iag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 15:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=PqZKee1cCRXVeiYmLE6qT9kWcaHiM7r3edCXE7l4F78=;
	b=acrErysUdxFokSC/C5uSDxfdZWHAmCwKe3ybTBjv9LZtvx5alJ2VWWQC5AoAQn5fLZ
	WcjYSixriHdkIJEzEUjeJrP796QiUCcg894Anjse1FIOuqWYgsrp1DMx9xCFJj2MPgTs
	humdtoUd7E9xacEUwNdKf5BqbkGU3frrvz7yo=
MIME-Version: 1.0
Received: by 10.42.168.197 with SMTP id x5mr19218757icy.6.1325718147357; Wed,
	04 Jan 2012 15:02:27 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 4 Jan 2012 15:02:27 -0800 (PST)
In-Reply-To: <1325300125668-5111504.post@n5.nabble.com>
References: <1325300125668-5111504.post@n5.nabble.com>
Date: Wed, 4 Jan 2012 18:02:27 -0500
X-Google-Sender-Auth: 4PvFN9WXSwvwwbEUfAo0-gpaf4c
Message-ID: <CAFLBxZat3L6YnyY35WswhQR1Mzy9u1TZb1ri0GOfRmE7i-DFKQ@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: "Liu.yi" <liu.yi24@zte.com.cn>
Cc: xen-devel@lists.xensource.com
Subject: Re: [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="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 30, 2011 at 9:55 PM, Liu.yi <liu.yi24@zte.com.cn> wrote:
> 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 =A0 2010-12-10 10:19:45.000000000 +0800
> +++ ../../xen-4.1.0/xen/common/sched_credit.c =A0 2010-12-31

Liu,

Thanks for the patch.  Unfortunately it doesn't apply for me.  It
needs to be able to apply using either "patch -p1 < patch_file" or "hg
qimport patch_file".  There are instructions on how to make such a
patch here:

http://wiki.xen.org/wiki/SubmittingXenPatches

Just from looking at it: You're right, the svc->flags variable is
modified while holding the vcpu scheduling lock in the case of
vcpu_yield, but the scheduler private lock in the case of
csched_acct().  It looks like your solution makes the update atomic --
let me see if that's the best thing.  I think the updates shouldn't be
too frequent, so it might be easier than trying to sort out locking.

I'll take a look at changing the locking and get back with you.

 -George

> 10:47:39.000000000 +0800
> @@ -135,7 +135,7 @@ struct csched_vcpu {
> =A0 =A0 struct vcpu *vcpu;
> =A0 =A0 atomic_t credit;
> =A0 =A0 s_time_t start_time; =A0 /* When we were scheduled (used for cred=
it) */
> - =A0 =A0uint16_t flags;
> + =A0 =A0uint32_t flags;
> =A0 =A0 int16_t pri;
> =A0#ifdef CSCHED_STATS
> =A0 =A0 struct {
> @@ -787,7 +787,7 @@ csched_vcpu_yield(const struct scheduler
> =A0 =A0 if ( !sched_credit_default_yield )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 /* Let the scheduler know that this vcpu is trying to yie=
ld */
> - =A0 =A0 =A0 =A0sv->flags |=3D CSCHED_FLAG_VCPU_YIELD;
> + =A0 =A0 =A0 =A0set_bit(1, &sv->flags);
> =A0 =A0 }
> =A0}
>
> @@ -1086,7 +1086,7 @@ csched_acct(void* dummy)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CSCHED_STAT_CRANK(vcpu_park);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vcpu_pause_nosync(svc->vcpu);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0svc->flags |=3D CSCHED_FLAG_VCPU=
_PARKED;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set_bit(0, &svc->flags);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Lower bound on credits */
> @@ -1111,7 +1111,7 @@ csched_acct(void* dummy)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CSCHED_STAT_CRANK(vcpu_unpark);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vcpu_unpause(svc->vcpu);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0svc->flags &=3D ~CSCHED_FLAG_VCP=
U_PARKED;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clear_bit(0, &svc->flags);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Upper bound on credits means VCPU stop=
s earning */
> @@ -1337,7 +1337,7 @@ csched_schedule(
> =A0 =A0 =A0* Clear YIELD flag before scheduling out
> =A0 =A0 =A0*/
> =A0 =A0 if ( scurr->flags & CSCHED_FLAG_VCPU_YIELD )
> - =A0 =A0 =A0 =A0scurr->flags &=3D ~(CSCHED_FLAG_VCPU_YIELD);
> + =A0 =A0 =A0 =A0clear_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 gi=
t a
> few months before.
>
> Thanks
>
> liuyi
>
>
> --
> View this message in context: http://xen.1045712.n5.nabble.com/credit-sch=
eduler-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

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 23:03:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 23:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiZqp-0007a8-Dm; Wed, 04 Jan 2012 23:02:31 +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 1RiZqo-0007a3-6f
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 23:02:30 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325718109!54695450!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 22637 invoked from network); 4 Jan 2012 23:01:51 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 23:01:50 -0000
Received: by iagw33 with SMTP id w33so154842908iag.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 15:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=PqZKee1cCRXVeiYmLE6qT9kWcaHiM7r3edCXE7l4F78=;
	b=acrErysUdxFokSC/C5uSDxfdZWHAmCwKe3ybTBjv9LZtvx5alJ2VWWQC5AoAQn5fLZ
	WcjYSixriHdkIJEzEUjeJrP796QiUCcg894Anjse1FIOuqWYgsrp1DMx9xCFJj2MPgTs
	humdtoUd7E9xacEUwNdKf5BqbkGU3frrvz7yo=
MIME-Version: 1.0
Received: by 10.42.168.197 with SMTP id x5mr19218757icy.6.1325718147357; Wed,
	04 Jan 2012 15:02:27 -0800 (PST)
Received: by 10.231.146.21 with HTTP; Wed, 4 Jan 2012 15:02:27 -0800 (PST)
In-Reply-To: <1325300125668-5111504.post@n5.nabble.com>
References: <1325300125668-5111504.post@n5.nabble.com>
Date: Wed, 4 Jan 2012 18:02:27 -0500
X-Google-Sender-Auth: 4PvFN9WXSwvwwbEUfAo0-gpaf4c
Message-ID: <CAFLBxZat3L6YnyY35WswhQR1Mzy9u1TZb1ri0GOfRmE7i-DFKQ@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: "Liu.yi" <liu.yi24@zte.com.cn>
Cc: xen-devel@lists.xensource.com
Subject: Re: [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="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 30, 2011 at 9:55 PM, Liu.yi <liu.yi24@zte.com.cn> wrote:
> 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 =A0 2010-12-10 10:19:45.000000000 +0800
> +++ ../../xen-4.1.0/xen/common/sched_credit.c =A0 2010-12-31

Liu,

Thanks for the patch.  Unfortunately it doesn't apply for me.  It
needs to be able to apply using either "patch -p1 < patch_file" or "hg
qimport patch_file".  There are instructions on how to make such a
patch here:

http://wiki.xen.org/wiki/SubmittingXenPatches

Just from looking at it: You're right, the svc->flags variable is
modified while holding the vcpu scheduling lock in the case of
vcpu_yield, but the scheduler private lock in the case of
csched_acct().  It looks like your solution makes the update atomic --
let me see if that's the best thing.  I think the updates shouldn't be
too frequent, so it might be easier than trying to sort out locking.

I'll take a look at changing the locking and get back with you.

 -George

> 10:47:39.000000000 +0800
> @@ -135,7 +135,7 @@ struct csched_vcpu {
> =A0 =A0 struct vcpu *vcpu;
> =A0 =A0 atomic_t credit;
> =A0 =A0 s_time_t start_time; =A0 /* When we were scheduled (used for cred=
it) */
> - =A0 =A0uint16_t flags;
> + =A0 =A0uint32_t flags;
> =A0 =A0 int16_t pri;
> =A0#ifdef CSCHED_STATS
> =A0 =A0 struct {
> @@ -787,7 +787,7 @@ csched_vcpu_yield(const struct scheduler
> =A0 =A0 if ( !sched_credit_default_yield )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 /* Let the scheduler know that this vcpu is trying to yie=
ld */
> - =A0 =A0 =A0 =A0sv->flags |=3D CSCHED_FLAG_VCPU_YIELD;
> + =A0 =A0 =A0 =A0set_bit(1, &sv->flags);
> =A0 =A0 }
> =A0}
>
> @@ -1086,7 +1086,7 @@ csched_acct(void* dummy)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CSCHED_STAT_CRANK(vcpu_park);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vcpu_pause_nosync(svc->vcpu);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0svc->flags |=3D CSCHED_FLAG_VCPU=
_PARKED;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0set_bit(0, &svc->flags);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Lower bound on credits */
> @@ -1111,7 +1111,7 @@ csched_acct(void* dummy)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CSCHED_STAT_CRANK(vcpu_unpark);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vcpu_unpause(svc->vcpu);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0svc->flags &=3D ~CSCHED_FLAG_VCP=
U_PARKED;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clear_bit(0, &svc->flags);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Upper bound on credits means VCPU stop=
s earning */
> @@ -1337,7 +1337,7 @@ csched_schedule(
> =A0 =A0 =A0* Clear YIELD flag before scheduling out
> =A0 =A0 =A0*/
> =A0 =A0 if ( scurr->flags & CSCHED_FLAG_VCPU_YIELD )
> - =A0 =A0 =A0 =A0scurr->flags &=3D ~(CSCHED_FLAG_VCPU_YIELD);
> + =A0 =A0 =A0 =A0clear_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 gi=
t a
> few months before.
>
> Thanks
>
> liuyi
>
>
> --
> View this message in context: http://xen.1045712.n5.nabble.com/credit-sch=
eduler-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

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 23:37:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 23:37:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiaOP-0007ne-9B; Wed, 04 Jan 2012 23:37:13 +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 1RiaON-0007nW-LX
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 23:37:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325720223!7832586!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2837 invoked from network); 4 Jan 2012 23:37:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 23:37:04 -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
	q04NavEE004143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 23:36:57 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q04NauSP012870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 23:36:56 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q04Nat5Z015523; Wed, 4 Jan 2012 17:36:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 15:36:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 47A9940321; Wed,  4 Jan 2012 18:35:24 -0500 (EST)
Date: Wed, 4 Jan 2012 18:35:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Kay, Allen M" <allen.m.kay@intel.com>, Ian.Campbell@citrix.com,
	david.vrabel@citrix.com
Message-ID: <20120104233524.GA31620@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F04E29A.0067,ss=1,re=0.000,fgs=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] problems I encountered using xen-4.1-testing and
	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 Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> 
> 
> 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.

Huh. You are right. Hadn't noticed that before since I was using dom0_mem.

Ian, David: any ideas? I get the same problem and it looks as
if the area above 4GB ends up being reserved.

> 
> 
> 
> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen with the latest upstream Linux kernel.


That I hadn't seen. Is this with dom0 or domU? There is one bug in the 2.6.18 kernel
in blkback if you are using that version.

> 
> Has anyone seen these two problems?
> 
> Allen

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 23:37:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 23:37:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiaOP-0007ne-9B; Wed, 04 Jan 2012 23:37:13 +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 1RiaON-0007nW-LX
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 23:37:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325720223!7832586!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2837 invoked from network); 4 Jan 2012 23:37:04 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 4 Jan 2012 23:37:04 -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
	q04NavEE004143
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 4 Jan 2012 23:36:57 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q04NauSP012870
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 4 Jan 2012 23:36:56 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q04Nat5Z015523; Wed, 4 Jan 2012 17:36:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 15:36:54 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 47A9940321; Wed,  4 Jan 2012 18:35:24 -0500 (EST)
Date: Wed, 4 Jan 2012 18:35:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Kay, Allen M" <allen.m.kay@intel.com>, Ian.Campbell@citrix.com,
	david.vrabel@citrix.com
Message-ID: <20120104233524.GA31620@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F04E29A.0067,ss=1,re=0.000,fgs=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] problems I encountered using xen-4.1-testing and
	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 Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> 
> 
> 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.

Huh. You are right. Hadn't noticed that before since I was using dom0_mem.

Ian, David: any ideas? I get the same problem and it looks as
if the area above 4GB ends up being reserved.

> 
> 
> 
> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen with the latest upstream Linux kernel.


That I hadn't seen. Is this with dom0 or domU? There is one bug in the 2.6.18 kernel
in blkback if you are using that version.

> 
> Has anyone seen these two problems?
> 
> Allen

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 23:37:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 23:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiaOf-0007oo-Sj; Wed, 04 Jan 2012 23:37:29 +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 1RiaOe-0007og-Ma
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 23:37:29 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325720200!48971365!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 6519 invoked from network); 4 Jan 2012 23:36:41 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 23:36:41 -0000
Received: by ghy10 with SMTP id 10so193706646ghy.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 15:37: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=46BkJnru+xbrIjam3UWCokt68Q6j3me2JCAtzo5t8Xk=;
	b=LKpPNoml41gtp8tbIdB1pjWbJ9wn57FnLJMh3Kxy9ReV424vK+U8oziPxh28WTuECa
	plobBvuidMj3E/lQg7c0Wdi8I8jKGtAKXzS+SSxY6J+c8xuMQdeUH2R2ELrwEwRLvFHG
	MOvPMwdqiwjDH3E7nFYD/QLq6UR27lDwwWnGY=
MIME-Version: 1.0
Received: by 10.101.46.8 with SMTP id y8mr18039681anj.79.1325720244323; Wed,
	04 Jan 2012 15:37:24 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Wed, 4 Jan 2012 15:37:24 -0800 (PST)
In-Reply-To: <20120103165503.GA749@andromeda.dapyr.net>
References: <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>
	<CAEc3jaCwiKhxdJAGjQ4vL-s3sWVwmFbho7+BDH20OaSNQEPO8Q@mail.gmail.com>
	<20120103165503.GA749@andromeda.dapyr.net>
Date: Wed, 4 Jan 2012 23:37:24 +0000
Message-ID: <CAEc3jaB3G06-gt-7bjXtmxo=Mfwvs1S6NEE2iwuXS-WCW0hwaQ@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

Oops initially only replied to Konrad. This is a resend to xen-devel.

On Tue, Jan 3, 2012 at 4:55 PM, Konrad Rzeszutek Wilk <konrad@darnok.org> w=
rote:
> On Mon, Dec 26, 2011 at 06:45:32PM +0000, Roderick Colenbrander wrote:
>> I have finally got some results (the tests are still running). Let me
>> first summarize what tests were running.
>
> Thanks for being so dilligient in providing full details. It helps after
> reading this after the holidays.
>>
>> 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
>
> Lets ignore that one. It is harmelss and I should probably remove it.

Okay good to know that it should probably removed.

>> 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 =A0 0: 87 =A0 =A0113 =A0 365 =A0 blkif-b=
ackend
>> =A0 =A0 =A0525325sec
>>
>> Thu Dec 22 23:30:07 2011 - 1259 =A0 0: 12 =A0 =A06 =A0 =A0 222 =A0 xenbu=
s
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1250 =A0 0: 62 =A0 =A042 =A0 =A01461 =A0ahci
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1249 =A0 0: 37 =A0 =A028 =A0 =A075 =A0 =A0eth=
0-rx-0
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1248 =A0 0: 71 =A0 =A0305 =A0 933 =A0 eth0-tx=
-0
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1243 =A0 0: 6 =A0 =A0 3 =A0 =A0 134
>> evtchn:xenstored =A0 =A0 526065sec
>> Thu Dec 22 23:30:07 2011 - 1241 =A0 0: 6 =A0 =A0 3 =A0 =A0 87582
>> evtchn:xenstored =A0 =A0 526065sec
>> Thu Dec 22 23:30:07 2011 - 1240 =A0 0: 256 =A0 261 =A0 54162 evtchn:qemu=
-dm
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1239 =A0 0: 244 =A0 251 =A0 7219 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1238 =A0 0: 289 =A0 273 =A0 5931 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1237 =A0 0: 248 =A0 245 =A0 4279 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1236 =A0 0: 12 =A0 =A07 =A0 =A0 315 =A0 blkif=
-backend
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1234 =A0 0: 7 =A0 =A0 4 =A0 =A0 43 =A0 =A0vet=
h1
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1232 CPU0 going backwards (-3304)!
>> Thu Dec 22 23:30:07 2011 - =A0 19 CPU0 going backwards (-212)!
>> Thu Dec 22 23:30:07 2011 - =A0 18 =A0 0: 35 =A0 =A017 =A0 =A035 =A0 =A0e=
hci_hcd:usb1,
>> uhci_hcd:usb8 526065sec
>> Thu Dec 22 23:30:07 2011 - =A0 16 CPU0 going backwards (-176)!
>> Thu Dec 22 23:30:07 2011 - =A0 12 CPU0 going backwards (-4)!
>> Thu Dec 22 23:30:07 2011 - =A0 =A04 CPU0 going backwards (-1)!
>> Thu Dec 22 23:30:12 2011 - 1250 =A0 0: 384 =A0 213 =A0 1461 =A0ahci
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:12 2011 - 1249 =A0 0: 14 =A0 =A021 =A0 =A075 =A0 =A0eth=
0-rx-0
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:12 2011 - 1240 =A0 0: 260 =A0 260 =A0 54162 evtchn:qemu=
-dm
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:12 2011 - 1239 =A0 0: 279 =A0 265 =A0 7219 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:13 2011 - 1238 =A0 0: 271 =A0 272 =A0 5931 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:13 2011 - 1237 =A0 0: 261 =A0 253 =A0 4279 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:13 2011 - 1236 =A0 0: 145 =A0 76 =A0 =A0315 =A0 blkif-b=
ackend
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:18 2011 - 1250 =A0 0: 372 =A0 293 =A0 1461 =A0ahci
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1249 =A0 0: 26 =A0 =A024 =A0 =A075 =A0 =A0eth=
0-rx-0
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1248 =A0 0: 16 =A0 =A086 =A0 =A0933 =A0 eth0-=
tx-0
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1240 =A0 0: 234 =A0 247 =A0 54162 evtchn:qemu=
-dm
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1239 =A0 0: 234 =A0 249 =A0 7219 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1238 =A0 0: 241 =A0 256 =A0 5931 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1237 =A0 0: 224 =A0 239 =A0 4279 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1236 =A0 0: 100 =A0 88 =A0 =A0315 =A0 blkif-b=
ackend
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:23 2011 - 1249 =A0 0: 16 =A0 =A020 =A0 =A075 =A0 =A0eth=
0-rx-0
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1248 =A0 0: 7 =A0 =A0 46 =A0 =A0933 =A0 eth0-=
tx-0
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1240 =A0 0: 8 =A0 =A0 128 =A0 54162 evtchn:qe=
mu-dm
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1239 =A0 0: 16 =A0 =A0133 =A0 7219 =A0evtchn:=
qemu-dm
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1238 =A0 0: 28 =A0 =A0142 =A0 5931 =A0evtchn:=
qemu-dm
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1233 CPU0 going backwards (-12648)!
>> Thu Dec 22 23:30:23 2011 - =A0 19 CPU0 going backwards (-212)!
>> Thu Dec 22 23:30:23 2011 - =A0 18 =A0 0: 35 =A0 =A017 =A0 =A042 =A0 =A0e=
hci_hcd:usb1,
>> uhci_hcd:usb8 526080sec
>> Thu Dec 22 23:30:23 2011 - =A0 16 CPU0 going backwards (-176)!
>> Thu Dec 22 23:30:23 2011 - =A0 12 CPU0 going backwards (-4)!
>> Thu Dec 22 23:30:23 2011 - =A0 =A04 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_devin=
tf
>> [533804.822914] Pid: 21632, comm: qemu-dm Not tainted 2.6.32.48 #1 X8STi
>> [533804.829595] RIP: e030:[<ffffffff814bdba9>] =A0[<ffffffff814bdba9>]
>> _spin_lock+0x5/0x15
>> [533804.837873] RSP: e02b:ffff88005f187c50 =A0EFLAGS: 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: =A000007f5cdcefe6f0(0000) GS:ffff880028038000(0000)
>> knlGS:0000000000000000
>> [533804.890874] CS: =A0e033 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] =A0ffffffff810a9ad0 ffff88007deb3180 ffff88007e260100
>> ffff88007e260100
>> [533804.938762] <0> ffffffff8124222d 0000000000000008 0000000000000008
>> ffff88007deb3180
>> [533804.946900] <0> ffffffff810b245e ffff88007fac1e40 ffff88007deb3180
>> 0000000000000000
>> [533804.955465] Call Trace:
>> [533804.958244] =A0[<ffffffff810a9ad0>] ? mmu_notifier_unregister+0x27/0=
xa5
>> [533804.965019] =A0[<ffffffff8124222d>] ? gntdev_release+0xc3/0xd1
>> [533804.971007] =A0[<ffffffff810b245e>] ? __fput+0x100/0x1af
>> [533804.976477] =A0[<ffffffff810af998>] ? filp_close+0x5b/0x62
>> [533804.982119] =A0[<ffffffff81042989>] ? put_files_struct+0x64/0xc1
>> [533804.988280] =A0[<ffffffff810441f0>] ? do_exit+0x209/0x68d
>> [533804.993836] =A0[<ffffffff810441f8>] ? do_exit+0x211/0x68d
>> [533804.999390] =A0[<ffffffff810446e9>] ? do_group_exit+0x75/0x9c
>> [533805.005294] =A0[<ffffffff8104cf1d>] ? get_signal_to_deliver+0x30d/0x=
338
>> [533805.012063] =A0[<ffffffff81010f7a>] ? do_notify_resume+0x8a/0x6b1
>> [533805.018310] =A0[<ffffffff810bdb3a>] ? poll_select_copy_remaining+0xd=
0/0xf3
>> [533805.025339] =A0[<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 =A0[<ffffffff814bdba9>] _spin_lock+0x5/0x15
>> [533805.056182] =A0RSP <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.
>
> It certainly looks that way. Or rather that we hit a race - what
> mmu_notifier_unregister tried to call was already de-allocated.
> [edit: Perhaps this is related to a TLB flush fix:
> =A07899891c7d161752f29abcc9bc0a9c6c3a3af26c xen mmu: fix a race window
> causing leave_mm BUG()]
>
> That would explain the hang you got. The qemu-dm is stuck waiting for
> gntdev to respond (you should be able to verify this by attaching gdb to
> qemu-dm and seeing the backtrace - it should be stuck at some ioctl
> call). And the kernel sees that this particular process is not doing
> anything. Also we have some gntdev in a bad state (but that should be OK
> to the other processes) - so I am not sure how that "hangs" your box.
>
> The interrupts being disabled does not seem to occur with this crash?
> Does read_interrupts code you are running is still spewing data right? Or
> does it stop as well?
>
> But lets fix one thing at a time.
>
> Looking at the code in 2.6.32 it is the version that went upstream
> as git commit ab31523c2fcac557226bac72cbdf5fafe01f9a26 and it has
> not had any of the features/bug-fixes that went with the upstream
> version:
>
> ab31523 xen/gntdev: allow usermode to map granted pages
> 8d3eaea xen/gntdev: add VM_PFNMAP to vma
> 9329e76 xen: gntdev: move use of GNTMAP_contains_pte next to the map_op
> ba5d101 xen/gntdev: stop using "token" argument
> f0a70c8 xen/gntdev: Fix circular locking dependency
> a12b4eb xen gntdev: use gnttab_map_refs and gnttab_unmap_refs
> ef91082 xen-gntdev: Change page limit to be global instead of per-open
> a879211 xen-gntdev: Use find_vma rather than iterating our vma list
> manually
> 68b025c xen-gntdev: Add reference counting to maps
> aab8f11 xen-gntdev: Support mapping in HVM domains
> bdc612d xen/gntalloc,gntdev: Add unmap notify ioctl
> 90b6f30 xen-gntdev: Fix memory leak when mmap fails
> 0ea22f0 xen-gntdev: Fix unmap notify on PV domains
> 84e4075 xen-gntdev: Use map->vma for checking map validity
> b57c186 xen-gntdev: Avoid unmapping ranges twice
> 12996fc xen-gntdev: Avoid double-mapping memory
> 9960be9 xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only
> mappings
> 77c35ac xen-gntdev: Fix incorrect use of zero handle
> f4ee4af xen-gntdev: Add cast to pointer
> 38eaeb0 xen: gntdev: fix build warning
> d79647a xen/gntdev,gntalloc: Remove unneeded VM flags
> ca47cea xen-gntdev: Use ballooned pages for grant mappings
> 12f0258 xen-gntdev: return -EFAULT on copy_to_user failure
> a93e20a xen-gntdev: unlock on error path in gntdev_mmap()
>
> The big question is whether the bug you are hitting is fixed by one of th=
ose
> git commits or that an unrelated fix (like the vmalloc_sync_all or the
> kmap_atomic one) which are:
> 461ae488ecb125b140d7ea29ceeedbcce9327003 mm: sync vmalloc address space p=
age tables in alloc_vm_area(
> 2cd1c8d4dc7ecca9e9431e2dabe41ae9c7d89e51 x86/paravirt: PTE updates in k(u=
n)map_atomic need to be synchronous, regardless of lazy_mmu mode
>
> But the errors that one gets without those two git commits is much
> different from what you get. So I doubt it is one of those.

I kept a close look at most of the gntdev related patches since they
are important to us. As you said, most of the changes look related to
this bug.

>
> The CPU time going backwards is disturbing. It does imply that the Xen
> hypervisor has stopped updating the timer information. Or maybe it has
> not, but the gntdev has crashed and left all the interrupts disabled.
>


Just for the record, aside from the 'Oops' the machine is working
fine. It's responsive, networking works, you can login etcetera.

> So three questions:
> =A01). Is the read_intr printing any data after the crash?
The tool was still running afterwards. Let me show a couple of lines
before (was in previous email) and after the Oops.

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
...
...
[533805.068584] Fixing recursive fault but reboot is needed!
Thu Dec 22 23:30:28 2011 - 1249   0: 15    18    75    eth0-rx-0
     526085sec
Thu Dec 22 23:30:28 2011 - 1241   0: 1361  682   87582
evtchn:xenstored     526085sec
Thu Dec 22 23:30:28 2011 - 1240 CPU0 going backwards (-391001)!
Thu Dec 22 23:30:28 2011 - 1239 CPU0 going backwards (-45746)!
Thu Dec 22 23:30:28 2011 - 1238 CPU0 going backwards (-73084)!
Thu Dec 22 23:30:28 2011 - 1237 CPU0 going backwards (-82968)!
Thu Dec 22 23:30:28 2011 - 1236 CPU0 going backwards (-6887)!
Thu Dec 22 23:30:28 2011 - 1235 CPU0 going backwards (-440)!
Thu Dec 22 23:30:28 2011 - 1234 CPU0 going backwards (-243)!
Thu Dec 22 23:30:28 2011 -   19 CPU0 going backwards (-215)!
Thu Dec 22 23:30:28 2011 -   18 CPU0 going backwards (-2)!
Thu Dec 22 23:30:28 2011 -   16 CPU0 going backwards (-179)!
Thu Dec 22 23:30:28 2011 -   12 CPU0 going backwards (-2)!
Thu Dec 22 23:30:33 2011 - 1249   0: 32    25    75    eth0-rx-0
     526090sec
Thu Dec 22 23:30:33 2011 - 1248   0: 18    21    933   eth0-tx-0
     526090sec
Thu Dec 22 23:30:38 2011 - 1250   0: 6     23    1461  ahci
     526095sec
Thu Dec 22 23:30:38 2011 - 1249   0: 18    22    75    eth0-rx-0
     526095sec
Thu Dec 22 23:30:43 2011 - 1249   0: 10    16    75    eth0-rx-0
     526100sec
Thu Dec 22 23:30:48 2011 - 1249   0: 14    15    75    eth0-rx-0
     526105sec
Thu Dec 22 23:30:53 2011 - 1249   0: 10    12    75    eth0-rx-0
     526110sec
Thu Dec 22 23:30:58 2011 - 1249   0: 12    12    75    eth0-rx-0
     526115sec


> =A02). If you attach gdb to qemu-dm can you see where it is stuck at?
I don't seem to be able to attach to the qemu-dm process. When I try
to attach, gdb never completes attaching to the process. Not sure why
it doesn't work, it works fine on other processes.

> =A03). Is the console activate at all? If not, can you SSH in (some
> =A0 =A0 network cards switch to polling so you can still login in a machi=
ne
> =A0 =A0 even if the interrupts are turned off - the atl1c something can d=
o
> =A0 =A0 it and I think the r8169 as well, but not sure).
The system is still responsive. Both network and the VGA console work fine.

> =A04). If you had configured your dom0 console to use the serial console
> =A0 =A0 instead of going through the Xen hypervisor console (so
> =A0 =A0 console=3DttyS0 on Linux, and no com1=3DXXX and console=3Dcom1 on=
 Xen
> =A0 =A0 hypervisor line), could you get a back-track of where the Linux
> =A0 =A0 kernel is at using Alt-sysRq?

I tried to get some Alt-sysRq output just now. After two tries, the
kernel wasn't too happy with me and died for good. I hope the limited
information is of some use.

[1654538.605575] SysRq : Show Blocked State
[1654538.609723]   task                        PC stack   pid father
[1654538.616093] qemu-dm       D 0000000000000000     0 21632  21633 0x0000=
0004
[1654538.623354]  ffffffff8169e3b0 0000000000000246 0000000000000000
ffff88005f187a28
[1654538.631319]  ffff88005f187968 0000000000000000 000000000000f4f8
ffff88005f187fd8
[1654538.639284]  0000000000013c80 0000000000013c80 ffff880074f4e270
ffff880074f4e518
[1654538.647249] Call Trace:
[1654538.650114]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654538.656100]  [<ffffffff810440b8>] ? do_exit+0xd1/0x68d
[1654538.661655]  [<ffffffff8100eeef>] ? xen_restore_fl_direct_end+0x0/0x1
[1654538.668511]  [<ffffffff814bdbd4>] ? _spin_unlock_irqrestore+0xc/0xd
[1654538.675192]  [<ffffffff81041573>] ? release_console_sem+0x17d/0x1ae
[1654538.681873]  [<ffffffff814bea6c>] ? oops_end+0xae/0xb3
[1654538.687429]  [<ffffffff8102d636>] ? no_context+0x1ff/0x20e
[1654538.693332]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654538.700186]  [<ffffffff8102d7eb>] ? __bad_area_nosemaphore+0x1a6/0x1ca
[1654538.707129]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654538.713985]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654538.719887]  [<ffffffff81035e28>] ? check_preempt_wakeup+0x0/0x15f
[1654538.726482]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654538.733346]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654538.739247]  [<ffffffff81035e28>] ? check_preempt_wakeup+0x0/0x15f
[1654538.745842]  [<ffffffff814bfeba>] ? do_page_fault+0x116/0x2fc
[1654538.752004]  [<ffffffff814bdf45>] ? page_fault+0x25/0x30
[1654538.757738]  [<ffffffff811b862b>] ? cap_file_free_security+0x0/0x1
[1654538.764338]  [<ffffffff814bdba9>] ? _spin_lock+0x5/0x15
[1654538.769980]  [<ffffffff810a9ad0>] ? mmu_notifier_unregister+0x27/0xa5
[1654538.776836]  [<ffffffff8124222d>] ? gntdev_release+0xc3/0xd1
[1654538.782911]  [<ffffffff810b245e>] ? __fput+0x100/0x1af
[1654538.788467]  [<ffffffff810af998>] ? filp_close+0x5b/0x62
[1654538.794195]  [<ffffffff81042989>] ? put_files_struct+0x64/0xc1
[1654538.800444]  [<ffffffff810441f0>] ? do_exit+0x209/0x68d
[1654538.806087]  [<ffffffff810441f8>] ? do_exit+0x211/0x68d
[1654538.811727]  [<ffffffff810446e9>] ? do_group_exit+0x75/0x9c
[1654538.817717]  [<ffffffff8104cf1d>] ? get_signal_to_deliver+0x30d/0x338
[1654538.824572]  [<ffffffff81010f7a>] ? do_notify_resume+0x8a/0x6b1
[1654538.830907]  [<ffffffff810bdb3a>] ? poll_select_copy_remaining+0xd0/0x=
f3
[1654538.838022]  [<ffffffff81011c8e>] ? int_signal+0x12/0x17

It looks like the gntdev file got closed by qemu-dm which triggers the
gntdev cleanup code.

What I was wondering about is 'gntdev_release'.
static int gntdev_release(struct inode *inode, struct file *flip)
{
     struct gntdev_priv *priv =3D flip->private_data;

     ..
     spin_lock(&priv->lock);
     <do cleanup>
     spin_unlock(&priv->lock);

     mmu_notifier_unregister(..);
     kfree(priv);
     return 0;
}

I don't know enough about the file descriptor code in Linux. What
happens if multiple applications (or threads) open gntdev, do they get
the same "flip"? If they do then it looks like there can be a race if
two threads call this code close to each other. I remember there being
some ref counting mechanism on file descriptors, so I guess this is
not the problem.

Wed Jan  4 22:48:45 2012 - 1250   0: 6     4     1461  ahci
     1644285sec
Wed Jan  4 22:48:45 2012 - 1249   0: 19    19    122   eth0-rx-0
     1644285sec
Wed Jan  4 22:48:50 2012 - 1249   0: 19    19    122   eth0-rx-0
     1644290sec
Wed Jan  4 22:48:55 2012 - 1249   0: 14    16    122   eth0-rx-0
     1644295sec
Wed Jan  4 22:49:00 2012 - 1249   0: 25    21    122   eth0-rx-0
     1644300sec
Wed Jan  4 22:49:00 2012 - 1248   0: 13    7     933   eth0-tx-0
     1644300sec
Wed Jan  4 22:49:05 2012 - 1249   0: 21    21    122   eth0-rx-0
     1644305sec
Wed Jan  4 22:49:05 2012 - 1248   0: 7     7     933   eth0-tx-0
     1644305sec
Wed Jan  4 22:49:10 2012 - 1249   0: 21    21    122   eth0-rx-0
     1644310sec
Wed Jan  4 22:49:10 2012 - 1248   0: 15    11    933   eth0-tx-0
     1644310sec
Wed Jan  4 22:49:15 2012 - 1249   0: 15    18    122   eth0-rx-0
     1644315sec
Wed Jan  4 22:49:21 2012 - 1250   0: 9     5     1461  ahci
     1644320sec
Wed Jan  4 22:49:21 2012 - 1249   0: 28    23    122   eth0-rx-0
     1644320sec
Wed Jan  4 22:49:21 2012 - 1248   0: 20    13    933   eth0-tx-0
     1644320sec
Wed Jan  4 22:49:26 2012 - 1249   0: 14    18    122   eth0-rx-0
     1644325sec
Wed Jan  4 22:49:31 2012 - 1249   0: 23    21    122   eth0-rx-0
     1644330sec
Wed Jan  4 22:49:31 2012 - 1248   0: 21    14    933   eth0-tx-0
     1644330sec
Wed Jan  4 22:49:36 2012 - 1249   0: 18    19    122   eth0-rx-0
     1644335sec
Wed Jan  4 22:49:41 2012 - 1249   0: 14    17    122   eth0-rx-0
     1644340sec
Wed Jan  4 22:49:46 2012 - 1249   0: 18    17    122   eth0-rx-0
     1644345sec
Wed Jan  4 22:49:51 2012 - 1249   0: 21    19    122   eth0-rx-0
     1644350sec
Wed Jan  4 22:49:56 2012 - 1250   0: 6     4     1461  ahci
     1644355sec
Wed Jan  4 22:49:56 2012 - 1249   0: 11    15    122   eth0-rx-0
     1644355sec
Wed Jan  4 22:50:01 2012 - 1249   0: 31    23    122   eth0-rx-0
     1644360sec
Wed Jan  4 22:50:01 2012 - 1248   0: 15    8     933   eth0-tx-0
     1644360sec
Wed Jan  4 22:50:06 2012 - 1249   0: 20    22    122   eth0-rx-0
     1644365sec
Wed Jan  4 22:50:06 2012 - 1248   0: 9     8     933   eth0-tx-0
     1644365sec
Wed Jan  4 22:50:11 2012 - 1249   0: 28    25    122   eth0-rx-0
     1644370sec
Wed Jan  4 22:50:11 2012 - 1248   0: 14    11    933   eth0-tx-0
     1644370sec

[1654627.877585] SysRq : Show backtrace of all active CPUs
[1654627.883041] sending NMI to all CPUs:
[1654627.887060] BUG: unable to handle kernel paging request at ffffffffff5=
fc310
[1654627.894437] IP: [<ffffffff81026743>] _flat_send_IPI_mask+0x4b/0x78
[1654627.901049] PGD 1003067 PUD 1004067 PMD 17a5067 PTE 0
[1654627.906500] Thread overran stack, or stack corrupted
[1654627.911883] Oops: 0002 [#2] SMP
[1654627.915515] last sysfs file:
/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0/uevent
[1654627.924320] CPU 0
[1654627.926746] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
[1654627.933681] Pid: 0, comm: swapper Tainted: G      D    2.6.32.48 #1 X8=
STi
[1654627.940883] RIP: e030:[<ffffffff81026743>]  [<ffffffff81026743>]
_flat_send_IPI_mask+0x4b/0x78
[1654627.950121] RSP: e02b:ffff88002803b988  EFLAGS: 00010006
[1654627.955872] RAX: 000000000f000000 RBX: 0000000000000800 RCX:
00000000ffff0095
[1654627.963644] RDX: ffff880028038000 RSI: 0000000000000002 RDI:
000000000000000f
[1654627.971410] RBP: 0000000000000002 R08: 0000000000153363 R09:
ffffffff812608df
[1654627.979176] R10: ffff8800000ba6c0 R11: ffffffff811fd43c R12:
ffffffff817000b0
[1654627.986949] R13: 000000000000000f R14: 000000000000000f R15:
0000000000000026
[1654627.994715] FS:  00007f4c15299910(0000) GS:ffff880028038000(0000)
knlGS:0000000000000000
[1654628.003434] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[1654628.009595] CR2: ffffffffff5fc310 CR3: 000000007b581000 CR4:
0000000000002660
[1654628.017362] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[1654628.025127] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[1654628.032891] Process swapper (pid: 0, threadinfo ffffffff8169a000,
task ffffffff8169e3b0)
[1654628.041609] Stack:
[1654628.044036]  ffffffff8100e871 0000000000000000 000000000000006c
0000000000000001
[1654628.051576] <0> ffff88007e613800 ffffffff810240ef
ffffffff816cce90 ffffffff81265fb5
[1654628.059807] <0> 00000000f28a6723 0000000000000000
0000000000000001 ffff88007e613800
[1654628.068469] Call Trace:
[1654628.071330]  <IRQ>
[1654628.073835]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.080691]  [<ffffffff810240ef>] ?
arch_trigger_all_cpu_backtrace+0x3d/0x5d
[1654628.088370]  [<ffffffff81265fb5>] ? __handle_sysrq+0xaf/0x14b
[1654628.094531]  [<ffffffff8125f057>] ? kbd_event+0x35e/0x616
[1654628.100347]  [<ffffffff814bdbd4>] ? _spin_unlock_irqrestore+0xc/0xd
[1654628.107029]  [<ffffffff8136ec5f>] ? input_pass_event+0x5a/0x7b
[1654628.113276]  [<ffffffff81370b8e>] ? input_event+0x5c/0x82
[1654628.119094]  [<ffffffff8139fb34>] ? hidinput_hid_event+0x291/0x2c1
[1654628.125853]  [<ffffffff8139c992>] ? hid_process_event+0xdd/0x121
[1654628.132274]  [<ffffffff8139cd83>] ? hid_report_raw_event+0x3ad/0x42f
[1654628.139042]  [<ffffffff8139cdf1>] ? hid_report_raw_event+0x41b/0x42f
[1654628.145812]  [<ffffffff8139d040>] ? hid_input_report+0x23b/0x260
[1654628.152235]  [<ffffffff813a5042>] ? hid_irq_in+0xad/0x212
[1654628.158050]  [<ffffffff81344b34>] ? usb_hcd_giveback_urb+0x76/0xa9
[1654628.164646]  [<ffffffff813632d6>] ? uhci_giveback_urb+0x10c/0x226
[1654628.171153]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.178010]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.183912]  [<ffffffff81363b71>] ? uhci_scan_schedule+0x677/0x937
[1654628.190505]  [<ffffffff81366284>] ? uhci_irq+0x8c0/0x8dd
[1654628.196236]  [<ffffffff810550bf>] ? hrtimer_interrupt+0xe3/0x18c
[1654628.202658]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.209598]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.216541]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.223397]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.229299]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.236240]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.243097]  [<ffffffff81344605>] ? usb_hcd_irq+0x39/0x7e
[1654628.248913]  [<ffffffff81077993>] ? handle_IRQ_event+0x2b/0xbd
[1654628.255160]  [<ffffffff810791cf>] ? handle_fasteoi_irq+0x78/0xaf
[1654628.261584]  [<ffffffff8123b382>] ? __xen_evtchn_do_upcall+0x1d0/0x28d
[1654628.268526]  [<ffffffff8123bc9c>] ? xen_evtchn_do_upcall+0x2e/0x42
[1654628.275120]  [<ffffffff81012b7e>] ? xen_do_hypervisor_callback+0x1e/0x=
30
[1654628.282235]  <EOI>
[1654628.284748]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[1654628.291084]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[1654628.297419]  [<ffffffff8100e8ef>] ? xen_safe_halt+0xc/0x15
[1654628.303322]  [<ffffffff81017ec7>] ? default_idle+0x21/0x3d
[1654628.309223]  [<ffffffff81010dd7>] ? cpu_idle+0x59/0x91
[1654628.314780]  [<ffffffff81728c8c>] ? start_kernel+0x381/0x38d
[1654628.320855]  [<ffffffff8172bde1>] ? xen_start_kernel+0x5aa/0x5b0
[1654628.327274] Code: 48 8b 05 f1 00 6e 00 83 fe 02 8b 58 34 75 0a ff
90 58 01 00 00 eb 0e f3 90 8b 04 25 00 c3 5f ff f6 c4 10 75 f2 44 89
e8 c1 e0 18 <89> 04 25 10 c3 5f ff 89 e8 09 d8 80 cf 04 83 fd 02 0f 44
c3 89
[1654628.346854] RIP  [<ffffffff81026743>] _flat_send_IPI_mask+0x4b/0x78
[1654628.353535]  RSP <ffff88002803b988>
[1654628.357436] CR2: ffffffffff5fc310
[1654628.361164] ---[ end trace 85ee7cbec9ce72ad ]---

Then it died:
[1654628.366199] Kernel panic - not syncing: Fatal exception in interrupt
[1654628.372968] Pid: 0, comm: swapper Tainted: G      D    2.6.32.48 #1
[1654628.379649] Call Trace:
[1654628.382509]  <IRQ>  [<ffffffff814bbd88>] ? panic+0x86/0x13e
[1654628.388490]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.394219]  [<ffffffff8100eeef>] ? xen_restore_fl_direct_end+0x0/0x1
[1654628.401074]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.406802]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.412533]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.418520]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.425376]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.431277]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.437266]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.442995]  [<ffffffff814bea64>] ? oops_end+0xa6/0xb3
[1654628.448553]  [<ffffffff8102d636>] ? no_context+0x1ff/0x20e
[1654628.454452]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.460356]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.466343]  [<ffffffff8102d7eb>] ? __bad_area_nosemaphore+0x1a6/0x1ca
[1654628.473286]  [<ffffffff8100eeef>] ? xen_restore_fl_direct_end+0x0/0x1
[1654628.480143]  [<ffffffff81041ad5>] ? vprintk+0x310/0x33c
[1654628.485783]  [<ffffffff8100eeef>] ? xen_restore_fl_direct_end+0x0/0x1
[1654628.492639]  [<ffffffff8100c269>] ? __raw_callee_save_xen_pte_val+0x11=
/0x1e
[1654628.500013]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.506003]  [<ffffffff8102cf52>] ? spurious_fault+0x147/0x1db
[1654628.512251]  [<ffffffff814bfe0d>] ? do_page_fault+0x69/0x2fc
[1654628.518327]  [<ffffffff814bdf45>] ? page_fault+0x25/0x30
[1654628.524056]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.535471]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.541200]  [<ffffffff81026743>] ? _flat_send_IPI_mask+0x4b/0x78
[1654628.547715]  [<ffffffff8102672d>] ? _flat_send_IPI_mask+0x35/0x78
[1654628.554225]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.561080]  [<ffffffff810240ef>] ?
arch_trigger_all_cpu_backtrace+0x3d/0x5d
[1654628.568759]  [<ffffffff81265fb5>] ? __handle_sysrq+0xaf/0x14b
[1654628.574921]  [<ffffffff8125f057>] ? kbd_event+0x35e/0x616
[1654628.580736]  [<ffffffff814bdbd4>] ? _spin_unlock_irqrestore+0xc/0xd
[1654628.587418]  [<ffffffff8136ec5f>] ? input_pass_event+0x5a/0x7b
[1654628.593666]  [<ffffffff81370b8e>] ? input_event+0x5c/0x82
[1654628.599482]  [<ffffffff8139fb34>] ? hidinput_hid_event+0x291/0x2c1
[1654628.606077]  [<ffffffff8139c992>] ? hid_process_event+0xdd/0x121
[1654628.612500]  [<ffffffff8139cd83>] ? hid_report_raw_event+0x3ad/0x42f
[1654628.619268]  [<ffffffff8139cdf1>] ? hid_report_raw_event+0x41b/0x42f
[1654628.626045]  [<ffffffff8139d040>] ? hid_input_report+0x23b/0x260
[1654628.632469]  [<ffffffff813a5042>] ? hid_irq_in+0xad/0x212
[1654628.638284]  [<ffffffff81344b34>] ? usb_hcd_giveback_urb+0x76/0xa9
[1654628.644879]  [<ffffffff813632d6>] ? uhci_giveback_urb+0x10c/0x226
[1654628.651387]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.658243]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.664145]  [<ffffffff81363b71>] ? uhci_scan_schedule+0x677/0x937
[1654628.670740]  [<ffffffff81366284>] ? uhci_irq+0x8c0/0x8dd
[1654628.676468]  [<ffffffff810550bf>] ? hrtimer_interrupt+0xe3/0x18c
[1654628.682891]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.689834]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.696774]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.703629]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.709532]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.716487]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.723348]  [<ffffffff81344605>] ? usb_hcd_irq+0x39/0x7e
[1654628.729163]  [<ffffffff81077993>] ? handle_IRQ_event+0x2b/0xbd
[1654628.735412]  [<ffffffff810791cf>] ? handle_fasteoi_irq+0x78/0xaf
[1654628.741834]  [<ffffffff8123b382>] ? __xen_evtchn_do_upcall+0x1d0/0x28d
[1654628.748776]  [<ffffffff8123bc9c>] ? xen_evtchn_do_upcall+0x2e/0x42
[1654628.755371]  [<ffffffff81012b7e>] ? xen_do_hypervisor_callback+0x1e/0x=
30
[1654628.762485]  <EOI>  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[1654628.769428]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[1654628.775764]  [<ffffffff8100e8ef>] ? xen_safe_halt+0xc/0x15
[1654628.781667]  [<ffffffff81017ec7>] ? default_idle+0x21/0x3d
[1654628.787568]  [<ffffffff81010dd7>] ? cpu_idle+0x59/0x91
[1654628.793124]  [<ffffffff81728c8c>] ? start_kernel+0x381/0x38d
[1654628.799199]  [<ffffffff8172bde1>] ? xen_start_kernel+0x5aa/0x5b0
(XEN) [2012-01-04 22:50:14] Domain 0 crashed: rebooting machine in 5 second=
s.

>
> Thanks and sorry for taking so long. Just coming back from holidays.
>

One of the 'blktap' machines is still running tests. It is running
Linux 2.6.32.48 and Xen 4.1.3-rc1. By now it has probably ran a 5000
VMs and it has been up for about 20 days. Before it wouldn't survive
~1000 VMs and 5 days. It would then get into that very, very slow
state. My feeling is that Linux 2.6.32.48 had some fixes which the
problems I was having. Before I ran Xen 4.1.3-rc1 in combination with
Linux 2.6.32.37 on it and it had the slowness problem.

It would be nice if we can get that other bug fixed as well. It could
be around in 3.x kernels as well. I would love to move to Linux 3.2,
but it requires a lot of testing which will take 1-2 months. At least
2.6.32.48 feels more stable and we may be able to fix a few more bugs
in it.

Thanks for your help!
Roderick

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

From xen-devel-bounces@lists.xensource.com Wed Jan 04 23:37:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 04 Jan 2012 23:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiaOf-0007oo-Sj; Wed, 04 Jan 2012 23:37:29 +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 1RiaOe-0007og-Ma
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 23:37:29 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325720200!48971365!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 6519 invoked from network); 4 Jan 2012 23:36:41 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 23:36:41 -0000
Received: by ghy10 with SMTP id 10so193706646ghy.30
	for <xen-devel@lists.xensource.com>;
	Wed, 04 Jan 2012 15:37: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=46BkJnru+xbrIjam3UWCokt68Q6j3me2JCAtzo5t8Xk=;
	b=LKpPNoml41gtp8tbIdB1pjWbJ9wn57FnLJMh3Kxy9ReV424vK+U8oziPxh28WTuECa
	plobBvuidMj3E/lQg7c0Wdi8I8jKGtAKXzS+SSxY6J+c8xuMQdeUH2R2ELrwEwRLvFHG
	MOvPMwdqiwjDH3E7nFYD/QLq6UR27lDwwWnGY=
MIME-Version: 1.0
Received: by 10.101.46.8 with SMTP id y8mr18039681anj.79.1325720244323; Wed,
	04 Jan 2012 15:37:24 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Wed, 4 Jan 2012 15:37:24 -0800 (PST)
In-Reply-To: <20120103165503.GA749@andromeda.dapyr.net>
References: <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>
	<CAEc3jaCwiKhxdJAGjQ4vL-s3sWVwmFbho7+BDH20OaSNQEPO8Q@mail.gmail.com>
	<20120103165503.GA749@andromeda.dapyr.net>
Date: Wed, 4 Jan 2012 23:37:24 +0000
Message-ID: <CAEc3jaB3G06-gt-7bjXtmxo=Mfwvs1S6NEE2iwuXS-WCW0hwaQ@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

Oops initially only replied to Konrad. This is a resend to xen-devel.

On Tue, Jan 3, 2012 at 4:55 PM, Konrad Rzeszutek Wilk <konrad@darnok.org> w=
rote:
> On Mon, Dec 26, 2011 at 06:45:32PM +0000, Roderick Colenbrander wrote:
>> I have finally got some results (the tests are still running). Let me
>> first summarize what tests were running.
>
> Thanks for being so dilligient in providing full details. It helps after
> reading this after the holidays.
>>
>> 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
>
> Lets ignore that one. It is harmelss and I should probably remove it.

Okay good to know that it should probably removed.

>> 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 =A0 0: 87 =A0 =A0113 =A0 365 =A0 blkif-b=
ackend
>> =A0 =A0 =A0525325sec
>>
>> Thu Dec 22 23:30:07 2011 - 1259 =A0 0: 12 =A0 =A06 =A0 =A0 222 =A0 xenbu=
s
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1250 =A0 0: 62 =A0 =A042 =A0 =A01461 =A0ahci
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1249 =A0 0: 37 =A0 =A028 =A0 =A075 =A0 =A0eth=
0-rx-0
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1248 =A0 0: 71 =A0 =A0305 =A0 933 =A0 eth0-tx=
-0
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1243 =A0 0: 6 =A0 =A0 3 =A0 =A0 134
>> evtchn:xenstored =A0 =A0 526065sec
>> Thu Dec 22 23:30:07 2011 - 1241 =A0 0: 6 =A0 =A0 3 =A0 =A0 87582
>> evtchn:xenstored =A0 =A0 526065sec
>> Thu Dec 22 23:30:07 2011 - 1240 =A0 0: 256 =A0 261 =A0 54162 evtchn:qemu=
-dm
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1239 =A0 0: 244 =A0 251 =A0 7219 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1238 =A0 0: 289 =A0 273 =A0 5931 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1237 =A0 0: 248 =A0 245 =A0 4279 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1236 =A0 0: 12 =A0 =A07 =A0 =A0 315 =A0 blkif=
-backend
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1234 =A0 0: 7 =A0 =A0 4 =A0 =A0 43 =A0 =A0vet=
h1
>> =A0 =A0 =A0526065sec
>> Thu Dec 22 23:30:07 2011 - 1232 CPU0 going backwards (-3304)!
>> Thu Dec 22 23:30:07 2011 - =A0 19 CPU0 going backwards (-212)!
>> Thu Dec 22 23:30:07 2011 - =A0 18 =A0 0: 35 =A0 =A017 =A0 =A035 =A0 =A0e=
hci_hcd:usb1,
>> uhci_hcd:usb8 526065sec
>> Thu Dec 22 23:30:07 2011 - =A0 16 CPU0 going backwards (-176)!
>> Thu Dec 22 23:30:07 2011 - =A0 12 CPU0 going backwards (-4)!
>> Thu Dec 22 23:30:07 2011 - =A0 =A04 CPU0 going backwards (-1)!
>> Thu Dec 22 23:30:12 2011 - 1250 =A0 0: 384 =A0 213 =A0 1461 =A0ahci
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:12 2011 - 1249 =A0 0: 14 =A0 =A021 =A0 =A075 =A0 =A0eth=
0-rx-0
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:12 2011 - 1240 =A0 0: 260 =A0 260 =A0 54162 evtchn:qemu=
-dm
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:12 2011 - 1239 =A0 0: 279 =A0 265 =A0 7219 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:13 2011 - 1238 =A0 0: 271 =A0 272 =A0 5931 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:13 2011 - 1237 =A0 0: 261 =A0 253 =A0 4279 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:13 2011 - 1236 =A0 0: 145 =A0 76 =A0 =A0315 =A0 blkif-b=
ackend
>> =A0 =A0 =A0526070sec
>> Thu Dec 22 23:30:18 2011 - 1250 =A0 0: 372 =A0 293 =A0 1461 =A0ahci
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1249 =A0 0: 26 =A0 =A024 =A0 =A075 =A0 =A0eth=
0-rx-0
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1248 =A0 0: 16 =A0 =A086 =A0 =A0933 =A0 eth0-=
tx-0
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1240 =A0 0: 234 =A0 247 =A0 54162 evtchn:qemu=
-dm
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1239 =A0 0: 234 =A0 249 =A0 7219 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1238 =A0 0: 241 =A0 256 =A0 5931 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1237 =A0 0: 224 =A0 239 =A0 4279 =A0evtchn:qe=
mu-dm
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:18 2011 - 1236 =A0 0: 100 =A0 88 =A0 =A0315 =A0 blkif-b=
ackend
>> =A0 =A0 =A0526075sec
>> Thu Dec 22 23:30:23 2011 - 1249 =A0 0: 16 =A0 =A020 =A0 =A075 =A0 =A0eth=
0-rx-0
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1248 =A0 0: 7 =A0 =A0 46 =A0 =A0933 =A0 eth0-=
tx-0
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1240 =A0 0: 8 =A0 =A0 128 =A0 54162 evtchn:qe=
mu-dm
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1239 =A0 0: 16 =A0 =A0133 =A0 7219 =A0evtchn:=
qemu-dm
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1238 =A0 0: 28 =A0 =A0142 =A0 5931 =A0evtchn:=
qemu-dm
>> =A0 =A0 =A0526080sec
>> Thu Dec 22 23:30:23 2011 - 1233 CPU0 going backwards (-12648)!
>> Thu Dec 22 23:30:23 2011 - =A0 19 CPU0 going backwards (-212)!
>> Thu Dec 22 23:30:23 2011 - =A0 18 =A0 0: 35 =A0 =A017 =A0 =A042 =A0 =A0e=
hci_hcd:usb1,
>> uhci_hcd:usb8 526080sec
>> Thu Dec 22 23:30:23 2011 - =A0 16 CPU0 going backwards (-176)!
>> Thu Dec 22 23:30:23 2011 - =A0 12 CPU0 going backwards (-4)!
>> Thu Dec 22 23:30:23 2011 - =A0 =A04 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_devin=
tf
>> [533804.822914] Pid: 21632, comm: qemu-dm Not tainted 2.6.32.48 #1 X8STi
>> [533804.829595] RIP: e030:[<ffffffff814bdba9>] =A0[<ffffffff814bdba9>]
>> _spin_lock+0x5/0x15
>> [533804.837873] RSP: e02b:ffff88005f187c50 =A0EFLAGS: 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: =A000007f5cdcefe6f0(0000) GS:ffff880028038000(0000)
>> knlGS:0000000000000000
>> [533804.890874] CS: =A0e033 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] =A0ffffffff810a9ad0 ffff88007deb3180 ffff88007e260100
>> ffff88007e260100
>> [533804.938762] <0> ffffffff8124222d 0000000000000008 0000000000000008
>> ffff88007deb3180
>> [533804.946900] <0> ffffffff810b245e ffff88007fac1e40 ffff88007deb3180
>> 0000000000000000
>> [533804.955465] Call Trace:
>> [533804.958244] =A0[<ffffffff810a9ad0>] ? mmu_notifier_unregister+0x27/0=
xa5
>> [533804.965019] =A0[<ffffffff8124222d>] ? gntdev_release+0xc3/0xd1
>> [533804.971007] =A0[<ffffffff810b245e>] ? __fput+0x100/0x1af
>> [533804.976477] =A0[<ffffffff810af998>] ? filp_close+0x5b/0x62
>> [533804.982119] =A0[<ffffffff81042989>] ? put_files_struct+0x64/0xc1
>> [533804.988280] =A0[<ffffffff810441f0>] ? do_exit+0x209/0x68d
>> [533804.993836] =A0[<ffffffff810441f8>] ? do_exit+0x211/0x68d
>> [533804.999390] =A0[<ffffffff810446e9>] ? do_group_exit+0x75/0x9c
>> [533805.005294] =A0[<ffffffff8104cf1d>] ? get_signal_to_deliver+0x30d/0x=
338
>> [533805.012063] =A0[<ffffffff81010f7a>] ? do_notify_resume+0x8a/0x6b1
>> [533805.018310] =A0[<ffffffff810bdb3a>] ? poll_select_copy_remaining+0xd=
0/0xf3
>> [533805.025339] =A0[<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 =A0[<ffffffff814bdba9>] _spin_lock+0x5/0x15
>> [533805.056182] =A0RSP <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.
>
> It certainly looks that way. Or rather that we hit a race - what
> mmu_notifier_unregister tried to call was already de-allocated.
> [edit: Perhaps this is related to a TLB flush fix:
> =A07899891c7d161752f29abcc9bc0a9c6c3a3af26c xen mmu: fix a race window
> causing leave_mm BUG()]
>
> That would explain the hang you got. The qemu-dm is stuck waiting for
> gntdev to respond (you should be able to verify this by attaching gdb to
> qemu-dm and seeing the backtrace - it should be stuck at some ioctl
> call). And the kernel sees that this particular process is not doing
> anything. Also we have some gntdev in a bad state (but that should be OK
> to the other processes) - so I am not sure how that "hangs" your box.
>
> The interrupts being disabled does not seem to occur with this crash?
> Does read_interrupts code you are running is still spewing data right? Or
> does it stop as well?
>
> But lets fix one thing at a time.
>
> Looking at the code in 2.6.32 it is the version that went upstream
> as git commit ab31523c2fcac557226bac72cbdf5fafe01f9a26 and it has
> not had any of the features/bug-fixes that went with the upstream
> version:
>
> ab31523 xen/gntdev: allow usermode to map granted pages
> 8d3eaea xen/gntdev: add VM_PFNMAP to vma
> 9329e76 xen: gntdev: move use of GNTMAP_contains_pte next to the map_op
> ba5d101 xen/gntdev: stop using "token" argument
> f0a70c8 xen/gntdev: Fix circular locking dependency
> a12b4eb xen gntdev: use gnttab_map_refs and gnttab_unmap_refs
> ef91082 xen-gntdev: Change page limit to be global instead of per-open
> a879211 xen-gntdev: Use find_vma rather than iterating our vma list
> manually
> 68b025c xen-gntdev: Add reference counting to maps
> aab8f11 xen-gntdev: Support mapping in HVM domains
> bdc612d xen/gntalloc,gntdev: Add unmap notify ioctl
> 90b6f30 xen-gntdev: Fix memory leak when mmap fails
> 0ea22f0 xen-gntdev: Fix unmap notify on PV domains
> 84e4075 xen-gntdev: Use map->vma for checking map validity
> b57c186 xen-gntdev: Avoid unmapping ranges twice
> 12996fc xen-gntdev: Avoid double-mapping memory
> 9960be9 xen-gntdev: prevent using UNMAP_NOTIFY_CLEAR_BYTE on read-only
> mappings
> 77c35ac xen-gntdev: Fix incorrect use of zero handle
> f4ee4af xen-gntdev: Add cast to pointer
> 38eaeb0 xen: gntdev: fix build warning
> d79647a xen/gntdev,gntalloc: Remove unneeded VM flags
> ca47cea xen-gntdev: Use ballooned pages for grant mappings
> 12f0258 xen-gntdev: return -EFAULT on copy_to_user failure
> a93e20a xen-gntdev: unlock on error path in gntdev_mmap()
>
> The big question is whether the bug you are hitting is fixed by one of th=
ose
> git commits or that an unrelated fix (like the vmalloc_sync_all or the
> kmap_atomic one) which are:
> 461ae488ecb125b140d7ea29ceeedbcce9327003 mm: sync vmalloc address space p=
age tables in alloc_vm_area(
> 2cd1c8d4dc7ecca9e9431e2dabe41ae9c7d89e51 x86/paravirt: PTE updates in k(u=
n)map_atomic need to be synchronous, regardless of lazy_mmu mode
>
> But the errors that one gets without those two git commits is much
> different from what you get. So I doubt it is one of those.

I kept a close look at most of the gntdev related patches since they
are important to us. As you said, most of the changes look related to
this bug.

>
> The CPU time going backwards is disturbing. It does imply that the Xen
> hypervisor has stopped updating the timer information. Or maybe it has
> not, but the gntdev has crashed and left all the interrupts disabled.
>


Just for the record, aside from the 'Oops' the machine is working
fine. It's responsive, networking works, you can login etcetera.

> So three questions:
> =A01). Is the read_intr printing any data after the crash?
The tool was still running afterwards. Let me show a couple of lines
before (was in previous email) and after the Oops.

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
...
...
[533805.068584] Fixing recursive fault but reboot is needed!
Thu Dec 22 23:30:28 2011 - 1249   0: 15    18    75    eth0-rx-0
     526085sec
Thu Dec 22 23:30:28 2011 - 1241   0: 1361  682   87582
evtchn:xenstored     526085sec
Thu Dec 22 23:30:28 2011 - 1240 CPU0 going backwards (-391001)!
Thu Dec 22 23:30:28 2011 - 1239 CPU0 going backwards (-45746)!
Thu Dec 22 23:30:28 2011 - 1238 CPU0 going backwards (-73084)!
Thu Dec 22 23:30:28 2011 - 1237 CPU0 going backwards (-82968)!
Thu Dec 22 23:30:28 2011 - 1236 CPU0 going backwards (-6887)!
Thu Dec 22 23:30:28 2011 - 1235 CPU0 going backwards (-440)!
Thu Dec 22 23:30:28 2011 - 1234 CPU0 going backwards (-243)!
Thu Dec 22 23:30:28 2011 -   19 CPU0 going backwards (-215)!
Thu Dec 22 23:30:28 2011 -   18 CPU0 going backwards (-2)!
Thu Dec 22 23:30:28 2011 -   16 CPU0 going backwards (-179)!
Thu Dec 22 23:30:28 2011 -   12 CPU0 going backwards (-2)!
Thu Dec 22 23:30:33 2011 - 1249   0: 32    25    75    eth0-rx-0
     526090sec
Thu Dec 22 23:30:33 2011 - 1248   0: 18    21    933   eth0-tx-0
     526090sec
Thu Dec 22 23:30:38 2011 - 1250   0: 6     23    1461  ahci
     526095sec
Thu Dec 22 23:30:38 2011 - 1249   0: 18    22    75    eth0-rx-0
     526095sec
Thu Dec 22 23:30:43 2011 - 1249   0: 10    16    75    eth0-rx-0
     526100sec
Thu Dec 22 23:30:48 2011 - 1249   0: 14    15    75    eth0-rx-0
     526105sec
Thu Dec 22 23:30:53 2011 - 1249   0: 10    12    75    eth0-rx-0
     526110sec
Thu Dec 22 23:30:58 2011 - 1249   0: 12    12    75    eth0-rx-0
     526115sec


> =A02). If you attach gdb to qemu-dm can you see where it is stuck at?
I don't seem to be able to attach to the qemu-dm process. When I try
to attach, gdb never completes attaching to the process. Not sure why
it doesn't work, it works fine on other processes.

> =A03). Is the console activate at all? If not, can you SSH in (some
> =A0 =A0 network cards switch to polling so you can still login in a machi=
ne
> =A0 =A0 even if the interrupts are turned off - the atl1c something can d=
o
> =A0 =A0 it and I think the r8169 as well, but not sure).
The system is still responsive. Both network and the VGA console work fine.

> =A04). If you had configured your dom0 console to use the serial console
> =A0 =A0 instead of going through the Xen hypervisor console (so
> =A0 =A0 console=3DttyS0 on Linux, and no com1=3DXXX and console=3Dcom1 on=
 Xen
> =A0 =A0 hypervisor line), could you get a back-track of where the Linux
> =A0 =A0 kernel is at using Alt-sysRq?

I tried to get some Alt-sysRq output just now. After two tries, the
kernel wasn't too happy with me and died for good. I hope the limited
information is of some use.

[1654538.605575] SysRq : Show Blocked State
[1654538.609723]   task                        PC stack   pid father
[1654538.616093] qemu-dm       D 0000000000000000     0 21632  21633 0x0000=
0004
[1654538.623354]  ffffffff8169e3b0 0000000000000246 0000000000000000
ffff88005f187a28
[1654538.631319]  ffff88005f187968 0000000000000000 000000000000f4f8
ffff88005f187fd8
[1654538.639284]  0000000000013c80 0000000000013c80 ffff880074f4e270
ffff880074f4e518
[1654538.647249] Call Trace:
[1654538.650114]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654538.656100]  [<ffffffff810440b8>] ? do_exit+0xd1/0x68d
[1654538.661655]  [<ffffffff8100eeef>] ? xen_restore_fl_direct_end+0x0/0x1
[1654538.668511]  [<ffffffff814bdbd4>] ? _spin_unlock_irqrestore+0xc/0xd
[1654538.675192]  [<ffffffff81041573>] ? release_console_sem+0x17d/0x1ae
[1654538.681873]  [<ffffffff814bea6c>] ? oops_end+0xae/0xb3
[1654538.687429]  [<ffffffff8102d636>] ? no_context+0x1ff/0x20e
[1654538.693332]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654538.700186]  [<ffffffff8102d7eb>] ? __bad_area_nosemaphore+0x1a6/0x1ca
[1654538.707129]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654538.713985]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654538.719887]  [<ffffffff81035e28>] ? check_preempt_wakeup+0x0/0x15f
[1654538.726482]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654538.733346]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654538.739247]  [<ffffffff81035e28>] ? check_preempt_wakeup+0x0/0x15f
[1654538.745842]  [<ffffffff814bfeba>] ? do_page_fault+0x116/0x2fc
[1654538.752004]  [<ffffffff814bdf45>] ? page_fault+0x25/0x30
[1654538.757738]  [<ffffffff811b862b>] ? cap_file_free_security+0x0/0x1
[1654538.764338]  [<ffffffff814bdba9>] ? _spin_lock+0x5/0x15
[1654538.769980]  [<ffffffff810a9ad0>] ? mmu_notifier_unregister+0x27/0xa5
[1654538.776836]  [<ffffffff8124222d>] ? gntdev_release+0xc3/0xd1
[1654538.782911]  [<ffffffff810b245e>] ? __fput+0x100/0x1af
[1654538.788467]  [<ffffffff810af998>] ? filp_close+0x5b/0x62
[1654538.794195]  [<ffffffff81042989>] ? put_files_struct+0x64/0xc1
[1654538.800444]  [<ffffffff810441f0>] ? do_exit+0x209/0x68d
[1654538.806087]  [<ffffffff810441f8>] ? do_exit+0x211/0x68d
[1654538.811727]  [<ffffffff810446e9>] ? do_group_exit+0x75/0x9c
[1654538.817717]  [<ffffffff8104cf1d>] ? get_signal_to_deliver+0x30d/0x338
[1654538.824572]  [<ffffffff81010f7a>] ? do_notify_resume+0x8a/0x6b1
[1654538.830907]  [<ffffffff810bdb3a>] ? poll_select_copy_remaining+0xd0/0x=
f3
[1654538.838022]  [<ffffffff81011c8e>] ? int_signal+0x12/0x17

It looks like the gntdev file got closed by qemu-dm which triggers the
gntdev cleanup code.

What I was wondering about is 'gntdev_release'.
static int gntdev_release(struct inode *inode, struct file *flip)
{
     struct gntdev_priv *priv =3D flip->private_data;

     ..
     spin_lock(&priv->lock);
     <do cleanup>
     spin_unlock(&priv->lock);

     mmu_notifier_unregister(..);
     kfree(priv);
     return 0;
}

I don't know enough about the file descriptor code in Linux. What
happens if multiple applications (or threads) open gntdev, do they get
the same "flip"? If they do then it looks like there can be a race if
two threads call this code close to each other. I remember there being
some ref counting mechanism on file descriptors, so I guess this is
not the problem.

Wed Jan  4 22:48:45 2012 - 1250   0: 6     4     1461  ahci
     1644285sec
Wed Jan  4 22:48:45 2012 - 1249   0: 19    19    122   eth0-rx-0
     1644285sec
Wed Jan  4 22:48:50 2012 - 1249   0: 19    19    122   eth0-rx-0
     1644290sec
Wed Jan  4 22:48:55 2012 - 1249   0: 14    16    122   eth0-rx-0
     1644295sec
Wed Jan  4 22:49:00 2012 - 1249   0: 25    21    122   eth0-rx-0
     1644300sec
Wed Jan  4 22:49:00 2012 - 1248   0: 13    7     933   eth0-tx-0
     1644300sec
Wed Jan  4 22:49:05 2012 - 1249   0: 21    21    122   eth0-rx-0
     1644305sec
Wed Jan  4 22:49:05 2012 - 1248   0: 7     7     933   eth0-tx-0
     1644305sec
Wed Jan  4 22:49:10 2012 - 1249   0: 21    21    122   eth0-rx-0
     1644310sec
Wed Jan  4 22:49:10 2012 - 1248   0: 15    11    933   eth0-tx-0
     1644310sec
Wed Jan  4 22:49:15 2012 - 1249   0: 15    18    122   eth0-rx-0
     1644315sec
Wed Jan  4 22:49:21 2012 - 1250   0: 9     5     1461  ahci
     1644320sec
Wed Jan  4 22:49:21 2012 - 1249   0: 28    23    122   eth0-rx-0
     1644320sec
Wed Jan  4 22:49:21 2012 - 1248   0: 20    13    933   eth0-tx-0
     1644320sec
Wed Jan  4 22:49:26 2012 - 1249   0: 14    18    122   eth0-rx-0
     1644325sec
Wed Jan  4 22:49:31 2012 - 1249   0: 23    21    122   eth0-rx-0
     1644330sec
Wed Jan  4 22:49:31 2012 - 1248   0: 21    14    933   eth0-tx-0
     1644330sec
Wed Jan  4 22:49:36 2012 - 1249   0: 18    19    122   eth0-rx-0
     1644335sec
Wed Jan  4 22:49:41 2012 - 1249   0: 14    17    122   eth0-rx-0
     1644340sec
Wed Jan  4 22:49:46 2012 - 1249   0: 18    17    122   eth0-rx-0
     1644345sec
Wed Jan  4 22:49:51 2012 - 1249   0: 21    19    122   eth0-rx-0
     1644350sec
Wed Jan  4 22:49:56 2012 - 1250   0: 6     4     1461  ahci
     1644355sec
Wed Jan  4 22:49:56 2012 - 1249   0: 11    15    122   eth0-rx-0
     1644355sec
Wed Jan  4 22:50:01 2012 - 1249   0: 31    23    122   eth0-rx-0
     1644360sec
Wed Jan  4 22:50:01 2012 - 1248   0: 15    8     933   eth0-tx-0
     1644360sec
Wed Jan  4 22:50:06 2012 - 1249   0: 20    22    122   eth0-rx-0
     1644365sec
Wed Jan  4 22:50:06 2012 - 1248   0: 9     8     933   eth0-tx-0
     1644365sec
Wed Jan  4 22:50:11 2012 - 1249   0: 28    25    122   eth0-rx-0
     1644370sec
Wed Jan  4 22:50:11 2012 - 1248   0: 14    11    933   eth0-tx-0
     1644370sec

[1654627.877585] SysRq : Show backtrace of all active CPUs
[1654627.883041] sending NMI to all CPUs:
[1654627.887060] BUG: unable to handle kernel paging request at ffffffffff5=
fc310
[1654627.894437] IP: [<ffffffff81026743>] _flat_send_IPI_mask+0x4b/0x78
[1654627.901049] PGD 1003067 PUD 1004067 PMD 17a5067 PTE 0
[1654627.906500] Thread overran stack, or stack corrupted
[1654627.911883] Oops: 0002 [#2] SMP
[1654627.915515] last sysfs file:
/sys/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1:1.0/uevent
[1654627.924320] CPU 0
[1654627.926746] Modules linked in: dm_snapshot dm_mod ipmi_si ipmi_devintf
[1654627.933681] Pid: 0, comm: swapper Tainted: G      D    2.6.32.48 #1 X8=
STi
[1654627.940883] RIP: e030:[<ffffffff81026743>]  [<ffffffff81026743>]
_flat_send_IPI_mask+0x4b/0x78
[1654627.950121] RSP: e02b:ffff88002803b988  EFLAGS: 00010006
[1654627.955872] RAX: 000000000f000000 RBX: 0000000000000800 RCX:
00000000ffff0095
[1654627.963644] RDX: ffff880028038000 RSI: 0000000000000002 RDI:
000000000000000f
[1654627.971410] RBP: 0000000000000002 R08: 0000000000153363 R09:
ffffffff812608df
[1654627.979176] R10: ffff8800000ba6c0 R11: ffffffff811fd43c R12:
ffffffff817000b0
[1654627.986949] R13: 000000000000000f R14: 000000000000000f R15:
0000000000000026
[1654627.994715] FS:  00007f4c15299910(0000) GS:ffff880028038000(0000)
knlGS:0000000000000000
[1654628.003434] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[1654628.009595] CR2: ffffffffff5fc310 CR3: 000000007b581000 CR4:
0000000000002660
[1654628.017362] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[1654628.025127] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[1654628.032891] Process swapper (pid: 0, threadinfo ffffffff8169a000,
task ffffffff8169e3b0)
[1654628.041609] Stack:
[1654628.044036]  ffffffff8100e871 0000000000000000 000000000000006c
0000000000000001
[1654628.051576] <0> ffff88007e613800 ffffffff810240ef
ffffffff816cce90 ffffffff81265fb5
[1654628.059807] <0> 00000000f28a6723 0000000000000000
0000000000000001 ffff88007e613800
[1654628.068469] Call Trace:
[1654628.071330]  <IRQ>
[1654628.073835]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.080691]  [<ffffffff810240ef>] ?
arch_trigger_all_cpu_backtrace+0x3d/0x5d
[1654628.088370]  [<ffffffff81265fb5>] ? __handle_sysrq+0xaf/0x14b
[1654628.094531]  [<ffffffff8125f057>] ? kbd_event+0x35e/0x616
[1654628.100347]  [<ffffffff814bdbd4>] ? _spin_unlock_irqrestore+0xc/0xd
[1654628.107029]  [<ffffffff8136ec5f>] ? input_pass_event+0x5a/0x7b
[1654628.113276]  [<ffffffff81370b8e>] ? input_event+0x5c/0x82
[1654628.119094]  [<ffffffff8139fb34>] ? hidinput_hid_event+0x291/0x2c1
[1654628.125853]  [<ffffffff8139c992>] ? hid_process_event+0xdd/0x121
[1654628.132274]  [<ffffffff8139cd83>] ? hid_report_raw_event+0x3ad/0x42f
[1654628.139042]  [<ffffffff8139cdf1>] ? hid_report_raw_event+0x41b/0x42f
[1654628.145812]  [<ffffffff8139d040>] ? hid_input_report+0x23b/0x260
[1654628.152235]  [<ffffffff813a5042>] ? hid_irq_in+0xad/0x212
[1654628.158050]  [<ffffffff81344b34>] ? usb_hcd_giveback_urb+0x76/0xa9
[1654628.164646]  [<ffffffff813632d6>] ? uhci_giveback_urb+0x10c/0x226
[1654628.171153]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.178010]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.183912]  [<ffffffff81363b71>] ? uhci_scan_schedule+0x677/0x937
[1654628.190505]  [<ffffffff81366284>] ? uhci_irq+0x8c0/0x8dd
[1654628.196236]  [<ffffffff810550bf>] ? hrtimer_interrupt+0xe3/0x18c
[1654628.202658]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.209598]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.216541]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.223397]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.229299]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.236240]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.243097]  [<ffffffff81344605>] ? usb_hcd_irq+0x39/0x7e
[1654628.248913]  [<ffffffff81077993>] ? handle_IRQ_event+0x2b/0xbd
[1654628.255160]  [<ffffffff810791cf>] ? handle_fasteoi_irq+0x78/0xaf
[1654628.261584]  [<ffffffff8123b382>] ? __xen_evtchn_do_upcall+0x1d0/0x28d
[1654628.268526]  [<ffffffff8123bc9c>] ? xen_evtchn_do_upcall+0x2e/0x42
[1654628.275120]  [<ffffffff81012b7e>] ? xen_do_hypervisor_callback+0x1e/0x=
30
[1654628.282235]  <EOI>
[1654628.284748]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[1654628.291084]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[1654628.297419]  [<ffffffff8100e8ef>] ? xen_safe_halt+0xc/0x15
[1654628.303322]  [<ffffffff81017ec7>] ? default_idle+0x21/0x3d
[1654628.309223]  [<ffffffff81010dd7>] ? cpu_idle+0x59/0x91
[1654628.314780]  [<ffffffff81728c8c>] ? start_kernel+0x381/0x38d
[1654628.320855]  [<ffffffff8172bde1>] ? xen_start_kernel+0x5aa/0x5b0
[1654628.327274] Code: 48 8b 05 f1 00 6e 00 83 fe 02 8b 58 34 75 0a ff
90 58 01 00 00 eb 0e f3 90 8b 04 25 00 c3 5f ff f6 c4 10 75 f2 44 89
e8 c1 e0 18 <89> 04 25 10 c3 5f ff 89 e8 09 d8 80 cf 04 83 fd 02 0f 44
c3 89
[1654628.346854] RIP  [<ffffffff81026743>] _flat_send_IPI_mask+0x4b/0x78
[1654628.353535]  RSP <ffff88002803b988>
[1654628.357436] CR2: ffffffffff5fc310
[1654628.361164] ---[ end trace 85ee7cbec9ce72ad ]---

Then it died:
[1654628.366199] Kernel panic - not syncing: Fatal exception in interrupt
[1654628.372968] Pid: 0, comm: swapper Tainted: G      D    2.6.32.48 #1
[1654628.379649] Call Trace:
[1654628.382509]  <IRQ>  [<ffffffff814bbd88>] ? panic+0x86/0x13e
[1654628.388490]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.394219]  [<ffffffff8100eeef>] ? xen_restore_fl_direct_end+0x0/0x1
[1654628.401074]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.406802]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.412533]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.418520]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.425376]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.431277]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.437266]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.442995]  [<ffffffff814bea64>] ? oops_end+0xa6/0xb3
[1654628.448553]  [<ffffffff8102d636>] ? no_context+0x1ff/0x20e
[1654628.454452]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.460356]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.466343]  [<ffffffff8102d7eb>] ? __bad_area_nosemaphore+0x1a6/0x1ca
[1654628.473286]  [<ffffffff8100eeef>] ? xen_restore_fl_direct_end+0x0/0x1
[1654628.480143]  [<ffffffff81041ad5>] ? vprintk+0x310/0x33c
[1654628.485783]  [<ffffffff8100eeef>] ? xen_restore_fl_direct_end+0x0/0x1
[1654628.492639]  [<ffffffff8100c269>] ? __raw_callee_save_xen_pte_val+0x11=
/0x1e
[1654628.500013]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.506003]  [<ffffffff8102cf52>] ? spurious_fault+0x147/0x1db
[1654628.512251]  [<ffffffff814bfe0d>] ? do_page_fault+0x69/0x2fc
[1654628.518327]  [<ffffffff814bdf45>] ? page_fault+0x25/0x30
[1654628.524056]  [<ffffffff811fd43c>] ? vgacon_cursor+0x0/0x17e
[1654628.535471]  [<ffffffff812608df>] ? set_cursor+0x3d/0x63
[1654628.541200]  [<ffffffff81026743>] ? _flat_send_IPI_mask+0x4b/0x78
[1654628.547715]  [<ffffffff8102672d>] ? _flat_send_IPI_mask+0x35/0x78
[1654628.554225]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.561080]  [<ffffffff810240ef>] ?
arch_trigger_all_cpu_backtrace+0x3d/0x5d
[1654628.568759]  [<ffffffff81265fb5>] ? __handle_sysrq+0xaf/0x14b
[1654628.574921]  [<ffffffff8125f057>] ? kbd_event+0x35e/0x616
[1654628.580736]  [<ffffffff814bdbd4>] ? _spin_unlock_irqrestore+0xc/0xd
[1654628.587418]  [<ffffffff8136ec5f>] ? input_pass_event+0x5a/0x7b
[1654628.593666]  [<ffffffff81370b8e>] ? input_event+0x5c/0x82
[1654628.599482]  [<ffffffff8139fb34>] ? hidinput_hid_event+0x291/0x2c1
[1654628.606077]  [<ffffffff8139c992>] ? hid_process_event+0xdd/0x121
[1654628.612500]  [<ffffffff8139cd83>] ? hid_report_raw_event+0x3ad/0x42f
[1654628.619268]  [<ffffffff8139cdf1>] ? hid_report_raw_event+0x41b/0x42f
[1654628.626045]  [<ffffffff8139d040>] ? hid_input_report+0x23b/0x260
[1654628.632469]  [<ffffffff813a5042>] ? hid_irq_in+0xad/0x212
[1654628.638284]  [<ffffffff81344b34>] ? usb_hcd_giveback_urb+0x76/0xa9
[1654628.644879]  [<ffffffff813632d6>] ? uhci_giveback_urb+0x10c/0x226
[1654628.651387]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.658243]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.664145]  [<ffffffff81363b71>] ? uhci_scan_schedule+0x677/0x937
[1654628.670740]  [<ffffffff81366284>] ? uhci_irq+0x8c0/0x8dd
[1654628.676468]  [<ffffffff810550bf>] ? hrtimer_interrupt+0xe3/0x18c
[1654628.682891]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.689834]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.696774]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.703629]  [<ffffffff8100ef02>] ? check_events+0x12/0x20
[1654628.709532]  [<ffffffff8100ee1e>] ? xen_vcpuop_set_next_event+0x0/0x60
[1654628.716487]  [<ffffffff8100e871>] ? xen_force_evtchn_callback+0x9/0xa
[1654628.723348]  [<ffffffff81344605>] ? usb_hcd_irq+0x39/0x7e
[1654628.729163]  [<ffffffff81077993>] ? handle_IRQ_event+0x2b/0xbd
[1654628.735412]  [<ffffffff810791cf>] ? handle_fasteoi_irq+0x78/0xaf
[1654628.741834]  [<ffffffff8123b382>] ? __xen_evtchn_do_upcall+0x1d0/0x28d
[1654628.748776]  [<ffffffff8123bc9c>] ? xen_evtchn_do_upcall+0x2e/0x42
[1654628.755371]  [<ffffffff81012b7e>] ? xen_do_hypervisor_callback+0x1e/0x=
30
[1654628.762485]  <EOI>  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[1654628.769428]  [<ffffffff810093aa>] ? hypercall_page+0x3aa/0x1001
[1654628.775764]  [<ffffffff8100e8ef>] ? xen_safe_halt+0xc/0x15
[1654628.781667]  [<ffffffff81017ec7>] ? default_idle+0x21/0x3d
[1654628.787568]  [<ffffffff81010dd7>] ? cpu_idle+0x59/0x91
[1654628.793124]  [<ffffffff81728c8c>] ? start_kernel+0x381/0x38d
[1654628.799199]  [<ffffffff8172bde1>] ? xen_start_kernel+0x5aa/0x5b0
(XEN) [2012-01-04 22:50:14] Domain 0 crashed: rebooting machine in 5 second=
s.

>
> Thanks and sorry for taking so long. Just coming back from holidays.
>

One of the 'blktap' machines is still running tests. It is running
Linux 2.6.32.48 and Xen 4.1.3-rc1. By now it has probably ran a 5000
VMs and it has been up for about 20 days. Before it wouldn't survive
~1000 VMs and 5 days. It would then get into that very, very slow
state. My feeling is that Linux 2.6.32.48 had some fixes which the
problems I was having. Before I ran Xen 4.1.3-rc1 in combination with
Linux 2.6.32.37 on it and it had the slowness problem.

It would be nice if we can get that other bug fixed as well. It could
be around in 3.x kernels as well. I would love to move to Linux 3.2,
but it requires a lot of testing which will take 1-2 months. At least
2.6.32.48 feels more stable and we may be able to fix a few more bugs
in it.

Thanks for your help!
Roderick

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 00:48:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVP-0000MH-3F; Thu, 05 Jan 2012 00:48:31 +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 1RibVM-0000LX-K2
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325724500!7874843!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17171 invoked from network); 5 Jan 2012 00:48:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 00:48:22 -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
	q050mIsG012881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48:18 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
	q050mHsv008410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 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
	q050mGrU010071; Wed, 4 Jan 2012 18:48:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6139840321; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:42 -0500
Message-Id: <1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F04F353.001A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message to
	include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When a PCI device is transferred to another domain and it is still
in usage (from the internal perspective), mention which other
domain is using it to aid in debugging.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/xenbus.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 474d52e..fa130bd 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
 	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
 	if (xen_register_device_domain_owner(dev,
 					     pdev->xdev->otherend_id) != 0) {
-		dev_err(&dev->dev, "device has been assigned to another " \
-			"domain! Over-writting the ownership, but beware.\n");
+		int other_domain = xen_find_device_domain_owner(dev);
+		dev_err(&dev->dev, "device has been assigned to %d " \
+			"domain! Over-writting the ownership, but beware.\n",
+			other_domain);
 		xen_unregister_device_domain_owner(dev);
 		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
 	}
-- 
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 Jan 05 00:48:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVP-0000MH-3F; Thu, 05 Jan 2012 00:48:31 +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 1RibVM-0000LX-K2
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325724500!7874843!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17171 invoked from network); 5 Jan 2012 00:48:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 00:48:22 -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
	q050mIsG012881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48:18 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
	q050mHsv008410
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 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
	q050mGrU010071; Wed, 4 Jan 2012 18:48:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6139840321; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:42 -0500
Message-Id: <1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F04F353.001A,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message to
	include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When a PCI device is transferred to another domain and it is still
in usage (from the internal perspective), mention which other
domain is using it to aid in debugging.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/xenbus.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 474d52e..fa130bd 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
 	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
 	if (xen_register_device_domain_owner(dev,
 					     pdev->xdev->otherend_id) != 0) {
-		dev_err(&dev->dev, "device has been assigned to another " \
-			"domain! Over-writting the ownership, but beware.\n");
+		int other_domain = xen_find_device_domain_owner(dev);
+		dev_err(&dev->dev, "device has been assigned to %d " \
+			"domain! Over-writting the ownership, but beware.\n",
+			other_domain);
 		xen_unregister_device_domain_owner(dev);
 		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
 	}
-- 
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 Jan 05 00:48:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVP-0000MO-Ez; Thu, 05 Jan 2012 00:48:31 +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 1RibVM-0000LV-Kx
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325724500!7836139!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21171 invoked from network); 5 Jan 2012 00:48:22 -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; 5 Jan 2012 00:48:22 -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
	q050mHuk012879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48: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
	q050mHEA027111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q050mGux001732; Wed, 4 Jan 2012 18:48:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2ED314031C; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:38 -0500
Message-Id: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F04F353.0022,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Support Function Level Reset (FLR) in the
	xen-pciback module (v1) and some 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

The attached patches allow the pciback module to perform a reset whenever
a PCI device is:
 - attached to the pciback module, as so:
  echo "0000:01.07.0" > /sys/bus/pci/devices/pciback/bind
 - detached from the pciback module, as so:
  echo "0000:01.07.0" > /sys/bus/pci/devices/pciback/unbind
 - and when the guest is done with (internally when the guest is not using
   the PCI device anymore).

I ran in one issue which is that I could not do pci_reset_function call when "bind"
or "unbind" were done as the device_lock was held (and pci_reset_function tried to
acquire the mutex). The solution was to introduce a new "pci_reset_function":

[PATCH 1/5] pci: Introduce __pci_reset_function_locked to be used
and then piggyback on that in
[PATCH 2/5] xen/pciback: Support pci_reset_function, aka FLR or D3

Also there are two fixes included in this - one where the PCI_DEV_FLAG_ASSIGNED
was in the wrong location and the "device has been assigned to other domain"
warning that always appeared. More details are in the patches themselves.


 drivers/pci/pci.c                  |   25 ++++++++++++++++++++
 drivers/xen/xen-pciback/pci_stub.c |   45 +++++++++++++++++++++++++++++++++--
 drivers/xen/xen-pciback/pciback.h  |    1 +
 drivers/xen/xen-pciback/xenbus.c   |    8 +++---
 include/linux/pci.h                |    1 +
 5 files changed, 73 insertions(+), 7 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 00:48:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVO-0000MA-NH; Thu, 05 Jan 2012 00:48: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 1RibVM-0000LS-1n
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325724500!9632424!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2184 invoked from network); 5 Jan 2012 00:48:21 -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; 5 Jan 2012 00:48:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q050mI71008821
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48: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
	q050mHRi008409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 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
	q050mGUD001733; Wed, 4 Jan 2012 18:48:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 379424031E; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:39 -0500
Message-Id: <1325724403-29642-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4F04F353.003F,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/5] pci: Introduce __pci_reset_function_locked
	to be used when holding device_lock.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 use case of this is when a driver wants to call FLR when a device
is attached to it using the SysFS "bind" or "unbind" functionality.

The call chain when a user does "bind" looks as so:

 echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind

and ends up calling:
  driver_bind:
    device_lock(dev);  <=== TAKES LOCK
    XXXX_probe:
         .. pci_enable_device()
         ...__pci_reset_function(), which calls
                 pci_dev_reset(dev, 0):
                        if (!0) {
                                device_lock(dev) <==== DEADLOCK

The __pci_reset_function_locked function allows the the drivers
'probe' function to call the "pci_reset_function" while still holding
the driver mutex lock.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/pci.c   |   25 +++++++++++++++++++++++++
 include/linux/pci.h |    1 +
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6d4a531..f9a2a0d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3020,6 +3020,31 @@ int __pci_reset_function(struct pci_dev *dev)
 EXPORT_SYMBOL_GPL(__pci_reset_function);
 
 /**
+ * __pci_reset_function_locked - reset a PCI device function while holding
+ * the @dev mutex lock.
+ * @dev: PCI device to reset
+ *
+ * Some devices allow an individual function to be reset without affecting
+ * other functions in the same device.  The PCI device must be responsive
+ * to PCI config space in order to use this function.
+ *
+ * The device function is presumed to be unused and the caller is holding
+ * the device mutex lock when this function is called.
+ * Resetting the device will make the contents of PCI configuration space
+ * random, so any caller of this must be prepared to reinitialise the
+ * device including MSI, bus mastering, BARs, decoding IO and memory spaces,
+ * etc.
+ *
+ * Returns 0 if the device function was successfully reset or negative if the
+ * device doesn't support resetting a single function.
+ */
+int __pci_reset_function_locked(struct pci_dev *dev)
+{
+	return pci_dev_reset(dev, 1);
+}
+EXPORT_SYMBOL_GPL(__pci_reset_function_locked);
+
+/**
  * pci_probe_reset_function - check whether the device can be safely reset
  * @dev: PCI device to reset
  *
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 7cda65b..af5ee43 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -814,6 +814,7 @@ int pcie_set_readrq(struct pci_dev *dev, int rq);
 int pcie_get_mps(struct pci_dev *dev);
 int pcie_set_mps(struct pci_dev *dev, int mps);
 int __pci_reset_function(struct pci_dev *dev);
+int __pci_reset_function_locked(struct pci_dev *dev);
 int pci_reset_function(struct pci_dev *dev);
 void pci_update_resource(struct pci_dev *dev, int resno);
 int __must_check pci_assign_resource(struct pci_dev *dev, int i);
-- 
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 Jan 05 00:48:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVP-0000MO-Ez; Thu, 05 Jan 2012 00:48:31 +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 1RibVM-0000LV-Kx
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325724500!7836139!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21171 invoked from network); 5 Jan 2012 00:48:22 -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; 5 Jan 2012 00:48:22 -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
	q050mHuk012879
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48: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
	q050mHEA027111
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q050mGux001732; Wed, 4 Jan 2012 18:48:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2ED314031C; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:38 -0500
Message-Id: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F04F353.0022,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Support Function Level Reset (FLR) in the
	xen-pciback module (v1) and some 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

The attached patches allow the pciback module to perform a reset whenever
a PCI device is:
 - attached to the pciback module, as so:
  echo "0000:01.07.0" > /sys/bus/pci/devices/pciback/bind
 - detached from the pciback module, as so:
  echo "0000:01.07.0" > /sys/bus/pci/devices/pciback/unbind
 - and when the guest is done with (internally when the guest is not using
   the PCI device anymore).

I ran in one issue which is that I could not do pci_reset_function call when "bind"
or "unbind" were done as the device_lock was held (and pci_reset_function tried to
acquire the mutex). The solution was to introduce a new "pci_reset_function":

[PATCH 1/5] pci: Introduce __pci_reset_function_locked to be used
and then piggyback on that in
[PATCH 2/5] xen/pciback: Support pci_reset_function, aka FLR or D3

Also there are two fixes included in this - one where the PCI_DEV_FLAG_ASSIGNED
was in the wrong location and the "device has been assigned to other domain"
warning that always appeared. More details are in the patches themselves.


 drivers/pci/pci.c                  |   25 ++++++++++++++++++++
 drivers/xen/xen-pciback/pci_stub.c |   45 +++++++++++++++++++++++++++++++++--
 drivers/xen/xen-pciback/pciback.h  |    1 +
 drivers/xen/xen-pciback/xenbus.c   |    8 +++---
 include/linux/pci.h                |    1 +
 5 files changed, 73 insertions(+), 7 deletions(-)

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 00:48:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVO-0000MA-NH; Thu, 05 Jan 2012 00:48: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 1RibVM-0000LS-1n
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325724500!9632424!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2184 invoked from network); 5 Jan 2012 00:48:21 -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; 5 Jan 2012 00:48:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q050mI71008821
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48: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
	q050mHRi008409
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 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
	q050mGUD001733; Wed, 4 Jan 2012 18:48:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 379424031E; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:39 -0500
Message-Id: <1325724403-29642-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090209.4F04F353.003F,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/5] pci: Introduce __pci_reset_function_locked
	to be used when holding device_lock.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 use case of this is when a driver wants to call FLR when a device
is attached to it using the SysFS "bind" or "unbind" functionality.

The call chain when a user does "bind" looks as so:

 echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind

and ends up calling:
  driver_bind:
    device_lock(dev);  <=== TAKES LOCK
    XXXX_probe:
         .. pci_enable_device()
         ...__pci_reset_function(), which calls
                 pci_dev_reset(dev, 0):
                        if (!0) {
                                device_lock(dev) <==== DEADLOCK

The __pci_reset_function_locked function allows the the drivers
'probe' function to call the "pci_reset_function" while still holding
the driver mutex lock.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/pci.c   |   25 +++++++++++++++++++++++++
 include/linux/pci.h |    1 +
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6d4a531..f9a2a0d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3020,6 +3020,31 @@ int __pci_reset_function(struct pci_dev *dev)
 EXPORT_SYMBOL_GPL(__pci_reset_function);
 
 /**
+ * __pci_reset_function_locked - reset a PCI device function while holding
+ * the @dev mutex lock.
+ * @dev: PCI device to reset
+ *
+ * Some devices allow an individual function to be reset without affecting
+ * other functions in the same device.  The PCI device must be responsive
+ * to PCI config space in order to use this function.
+ *
+ * The device function is presumed to be unused and the caller is holding
+ * the device mutex lock when this function is called.
+ * Resetting the device will make the contents of PCI configuration space
+ * random, so any caller of this must be prepared to reinitialise the
+ * device including MSI, bus mastering, BARs, decoding IO and memory spaces,
+ * etc.
+ *
+ * Returns 0 if the device function was successfully reset or negative if the
+ * device doesn't support resetting a single function.
+ */
+int __pci_reset_function_locked(struct pci_dev *dev)
+{
+	return pci_dev_reset(dev, 1);
+}
+EXPORT_SYMBOL_GPL(__pci_reset_function_locked);
+
+/**
  * pci_probe_reset_function - check whether the device can be safely reset
  * @dev: PCI device to reset
  *
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 7cda65b..af5ee43 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -814,6 +814,7 @@ int pcie_set_readrq(struct pci_dev *dev, int rq);
 int pcie_get_mps(struct pci_dev *dev);
 int pcie_set_mps(struct pci_dev *dev, int mps);
 int __pci_reset_function(struct pci_dev *dev);
+int __pci_reset_function_locked(struct pci_dev *dev);
 int pci_reset_function(struct pci_dev *dev);
 void pci_update_resource(struct pci_dev *dev, int resno);
 int __must_check pci_assign_resource(struct pci_dev *dev, int i);
-- 
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 Jan 05 00:48:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVO-0000M3-B2; Thu, 05 Jan 2012 00:48: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 1RibVL-0000LT-VZ
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325724500!9645339!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23916 invoked from network); 5 Jan 2012 00:48:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 00:48:21 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q050mIPh008824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48:19 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q050mHbc027128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:18 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
	q050mHRQ010079; Wed, 4 Jan 2012 18:48:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6C97340322; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:43 -0500
Message-Id: <1325724403-29642-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-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.0A090209.4F04F353.0053,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 5/5] xen/pciback: Fix "device has been assigned
	to X domain!" warning
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 full warning is:
"pciback 0000:05:00.0: device has been assigned to 2 domain! Over-writting the ownership, but beware."

which is correct - the previous domain that was using the device
forgot to unregister the ownership. This patch fixes this by
calling the unregister ownership function when the PCI device is
relinquished from the guest domain.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index d66328e..6f63b9d 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -260,6 +260,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
 	xen_pcibk_config_reset_dev(found_psdev->dev);
 
+	xen_unregister_device_domain_owner(found_psdev->dev);
+
 	spin_lock_irqsave(&found_psdev->lock, flags);
 	found_psdev->pdev = NULL;
 	spin_unlock_irqrestore(&found_psdev->lock, flags);
-- 
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 Jan 05 00:48:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVO-0000M3-B2; Thu, 05 Jan 2012 00:48: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 1RibVL-0000LT-VZ
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325724500!9645339!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23916 invoked from network); 5 Jan 2012 00:48:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 00:48:21 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q050mIPh008824
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48:19 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q050mHbc027128
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:18 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
	q050mHRQ010079; Wed, 4 Jan 2012 18:48:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:17 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6C97340322; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:43 -0500
Message-Id: <1325724403-29642-6-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-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.0A090209.4F04F353.0053,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 5/5] xen/pciback: Fix "device has been assigned
	to X domain!" warning
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 full warning is:
"pciback 0000:05:00.0: device has been assigned to 2 domain! Over-writting the ownership, but beware."

which is correct - the previous domain that was using the device
forgot to unregister the ownership. This patch fixes this by
calling the unregister ownership function when the PCI device is
relinquished from the guest domain.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index d66328e..6f63b9d 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -260,6 +260,8 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
 	xen_pcibk_config_reset_dev(found_psdev->dev);
 
+	xen_unregister_device_domain_owner(found_psdev->dev);
+
 	spin_lock_irqsave(&found_psdev->lock, flags);
 	found_psdev->pdev = NULL;
 	spin_unlock_irqrestore(&found_psdev->lock, flags);
-- 
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 Jan 05 00:48:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVP-0000MV-RS; Thu, 05 Jan 2012 00:48:31 +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 1RibVM-0000LW-L8
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325724500!7880423!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31009 invoked from network); 5 Jan 2012 00:48:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 00:48:22 -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
	q050mIbe012884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48:19 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
	q050mHo1027120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 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
	q050mGaQ018337; Wed, 4 Jan 2012 18:48:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4FDCE40320; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:41 -0500
Message-Id: <1325724403-29642-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-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.0A090208.4F04F353.0045,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/5] xen/pciback: Move the
	PCI_DEV_FLAGS_ASSIGNED ops to the "[un|]bind"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

operation instead of doing it per guest creation/disconnection. Without
this we could have potentially unloaded the vf driver from the
xen pciback control even if the driver was binded to the xen-pciback.
This will hold on to it until the user "unbind"s the PCI device using
SysFS.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |    2 ++
 drivers/xen/xen-pciback/xenbus.c   |    2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 0ce0dc6..d66328e 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -114,6 +114,7 @@ static void pcistub_device_release(struct kref *kref)
 	xen_pcibk_config_free_dyn_fields(psdev->dev);
 	xen_pcibk_config_free_dev(psdev->dev);
 
+	psdev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
 	pci_dev_put(psdev->dev);
 
 	kfree(psdev);
@@ -366,6 +367,7 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	dev_dbg(&dev->dev, "reset device\n");
 	xen_pcibk_reset_device(dev);
 
+	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
 	return 0;
 
 config_release:
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 0755259..474d52e 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -241,7 +241,6 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
 		goto out;
 
 	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
-	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
 	if (xen_register_device_domain_owner(dev,
 					     pdev->xdev->otherend_id) != 0) {
 		dev_err(&dev->dev, "device has been assigned to another " \
@@ -281,7 +280,6 @@ static int xen_pcibk_remove_device(struct xen_pcibk_device *pdev,
 	}
 
 	dev_dbg(&dev->dev, "unregistering for %d\n", pdev->xdev->otherend_id);
-	dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
 	xen_unregister_device_domain_owner(dev);
 
 	xen_pcibk_release_pci_dev(pdev, dev);
-- 
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 Jan 05 00:48:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVP-0000MV-RS; Thu, 05 Jan 2012 00:48:31 +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 1RibVM-0000LW-L8
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325724500!7880423!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcxNjY5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31009 invoked from network); 5 Jan 2012 00:48:22 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 00:48:22 -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
	q050mIbe012884
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48:19 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
	q050mHo1027120
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 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
	q050mGaQ018337; Wed, 4 Jan 2012 18:48:17 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4FDCE40320; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:41 -0500
Message-Id: <1325724403-29642-4-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-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.0A090208.4F04F353.0045,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3/5] xen/pciback: Move the
	PCI_DEV_FLAGS_ASSIGNED ops to the "[un|]bind"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

operation instead of doing it per guest creation/disconnection. Without
this we could have potentially unloaded the vf driver from the
xen pciback control even if the driver was binded to the xen-pciback.
This will hold on to it until the user "unbind"s the PCI device using
SysFS.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |    2 ++
 drivers/xen/xen-pciback/xenbus.c   |    2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 0ce0dc6..d66328e 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -114,6 +114,7 @@ static void pcistub_device_release(struct kref *kref)
 	xen_pcibk_config_free_dyn_fields(psdev->dev);
 	xen_pcibk_config_free_dev(psdev->dev);
 
+	psdev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
 	pci_dev_put(psdev->dev);
 
 	kfree(psdev);
@@ -366,6 +367,7 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	dev_dbg(&dev->dev, "reset device\n");
 	xen_pcibk_reset_device(dev);
 
+	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
 	return 0;
 
 config_release:
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 0755259..474d52e 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -241,7 +241,6 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
 		goto out;
 
 	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
-	dev->dev_flags |= PCI_DEV_FLAGS_ASSIGNED;
 	if (xen_register_device_domain_owner(dev,
 					     pdev->xdev->otherend_id) != 0) {
 		dev_err(&dev->dev, "device has been assigned to another " \
@@ -281,7 +280,6 @@ static int xen_pcibk_remove_device(struct xen_pcibk_device *pdev,
 	}
 
 	dev_dbg(&dev->dev, "unregistering for %d\n", pdev->xdev->otherend_id);
-	dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
 	xen_unregister_device_domain_owner(dev);
 
 	xen_pcibk_release_pci_dev(pdev, dev);
-- 
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 Jan 05 00:48:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVN-0000Lw-VR; Thu, 05 Jan 2012 00:48: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 1RibVL-0000LU-VY
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325724500!9654544!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27708 invoked from network); 5 Jan 2012 00:48:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 00:48:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q050mIpm008822
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48: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
	q050mH1s008411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 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
	q050mGxa001734; Wed, 4 Jan 2012 18:48:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 441394031F; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:40 -0500
Message-Id: <1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F04F353.004F,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
	aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We use the __pci_reset_function_locked to perform the action.
Also on attaching ("bind") and detaching ("unbind") we save and
restore the configuration states. When the device is disconnected
from a guest we use the "pci_reset_function" to also reset the
device before being passed to another guest.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
 drivers/xen/xen-pciback/pciback.h  |    1 +
 2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 8f06e1e..0ce0dc6 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
 static void pcistub_device_release(struct kref *kref)
 {
 	struct pcistub_device *psdev;
+	struct xen_pcibk_dev_data *dev_data;
 
 	psdev = container_of(kref, struct pcistub_device, kref);
+	dev_data = pci_get_drvdata(psdev->dev);
 
 	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
 
 	xen_unregister_device_domain_owner(psdev->dev);
 
-	/* Clean-up the device */
+	/* Call the reset function which does not take lock as this
+	 * is called from "unbind" which takes a device_lock mutex.
+	 */
+	__pci_reset_function_locked(psdev->dev);
+	if (pci_load_and_free_saved_state(psdev->dev,
+					  &dev_data->pci_saved_state)) {
+		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
+	} else
+		pci_restore_state(psdev->dev);
+
+	/* Disable the device */
 	xen_pcibk_reset_device(psdev->dev);
+
+	kfree(dev_data);
+	pci_set_drvdata(psdev->dev, NULL);
+
+	/* Clean-up the device */
 	xen_pcibk_config_free_dyn_fields(psdev->dev);
 	xen_pcibk_config_free_dev(psdev->dev);
-	kfree(pci_get_drvdata(psdev->dev));
-	pci_set_drvdata(psdev->dev, NULL);
 
 	pci_dev_put(psdev->dev);
 
@@ -230,7 +245,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
+
+	/* This is OK - we are running from workqueue context
+	 * and want to inhibit the user from fiddling with 'reset'
+	 */
+	pci_reset_function(dev);
+	pci_restore_state(psdev->dev);
+
+	/* This disables the device. */
 	xen_pcibk_reset_device(found_psdev->dev);
+
+	/* And cleanup up our emulated fields. */
 	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
 	xen_pcibk_config_reset_dev(found_psdev->dev);
 
@@ -325,6 +350,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	if (err)
 		goto config_release;
 
+	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
+	__pci_reset_function_locked(dev);
+
+	/* We need the device active to save the state. */
+	dev_dbg(&dev->dev, "save state of device\n");
+	pci_save_state(dev);
+	dev_data->pci_saved_state = pci_store_saved_state(dev);
+	if (!dev_data->pci_saved_state)
+		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
+
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
 	 */
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index e9b4011..a7def01 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -41,6 +41,7 @@ struct xen_pcibk_device {
 
 struct xen_pcibk_dev_data {
 	struct list_head config_fields;
+	struct pci_saved_state *pci_saved_state;
 	unsigned int permissive:1;
 	unsigned int warned_on_write:1;
 	unsigned int enable_intx:1;
-- 
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 Jan 05 00:48:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:48:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RibVN-0000Lw-VR; Thu, 05 Jan 2012 00:48: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 1RibVL-0000LU-VY
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:48:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325724500!9654544!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3MjkyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27708 invoked from network); 5 Jan 2012 00:48:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 00:48:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q050mIpm008822
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 00:48: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
	q050mH1s008411
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 00:48:17 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
	q050mGxa001734; Wed, 4 Jan 2012 18:48:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 04 Jan 2012 16:48:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 441394031F; Wed,  4 Jan 2012 19:46:46 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org,
	linux-pci@vger.kernel.org
Date: Wed,  4 Jan 2012 19:46:40 -0500
Message-Id: <1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F04F353.004F,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
	aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We use the __pci_reset_function_locked to perform the action.
Also on attaching ("bind") and detaching ("unbind") we save and
restore the configuration states. When the device is disconnected
from a guest we use the "pci_reset_function" to also reset the
device before being passed to another guest.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
 drivers/xen/xen-pciback/pciback.h  |    1 +
 2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 8f06e1e..0ce0dc6 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
 static void pcistub_device_release(struct kref *kref)
 {
 	struct pcistub_device *psdev;
+	struct xen_pcibk_dev_data *dev_data;
 
 	psdev = container_of(kref, struct pcistub_device, kref);
+	dev_data = pci_get_drvdata(psdev->dev);
 
 	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
 
 	xen_unregister_device_domain_owner(psdev->dev);
 
-	/* Clean-up the device */
+	/* Call the reset function which does not take lock as this
+	 * is called from "unbind" which takes a device_lock mutex.
+	 */
+	__pci_reset_function_locked(psdev->dev);
+	if (pci_load_and_free_saved_state(psdev->dev,
+					  &dev_data->pci_saved_state)) {
+		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
+	} else
+		pci_restore_state(psdev->dev);
+
+	/* Disable the device */
 	xen_pcibk_reset_device(psdev->dev);
+
+	kfree(dev_data);
+	pci_set_drvdata(psdev->dev, NULL);
+
+	/* Clean-up the device */
 	xen_pcibk_config_free_dyn_fields(psdev->dev);
 	xen_pcibk_config_free_dev(psdev->dev);
-	kfree(pci_get_drvdata(psdev->dev));
-	pci_set_drvdata(psdev->dev, NULL);
 
 	pci_dev_put(psdev->dev);
 
@@ -230,7 +245,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
+
+	/* This is OK - we are running from workqueue context
+	 * and want to inhibit the user from fiddling with 'reset'
+	 */
+	pci_reset_function(dev);
+	pci_restore_state(psdev->dev);
+
+	/* This disables the device. */
 	xen_pcibk_reset_device(found_psdev->dev);
+
+	/* And cleanup up our emulated fields. */
 	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
 	xen_pcibk_config_reset_dev(found_psdev->dev);
 
@@ -325,6 +350,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	if (err)
 		goto config_release;
 
+	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
+	__pci_reset_function_locked(dev);
+
+	/* We need the device active to save the state. */
+	dev_dbg(&dev->dev, "save state of device\n");
+	pci_save_state(dev);
+	dev_data->pci_saved_state = pci_store_saved_state(dev);
+	if (!dev_data->pci_saved_state)
+		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
+
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
 	 */
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index e9b4011..a7def01 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -41,6 +41,7 @@ struct xen_pcibk_device {
 
 struct xen_pcibk_dev_data {
 	struct list_head config_fields;
+	struct pci_saved_state *pci_saved_state;
 	unsigned int permissive:1;
 	unsigned int warned_on_write:1;
 	unsigned int enable_intx:1;
-- 
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 Jan 05 00:54:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ribb3-00014W-MJ; Thu, 05 Jan 2012 00:54: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 1Ribb1-000143-Qp
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:54:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325724805!51277956!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26653 invoked from network); 5 Jan 2012 00:53:25 -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 Jan 2012 00:53:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,459,1320624000"; 
   d="scan'208";a="9824453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 00:54: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, 5 Jan 2012 00:54: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 1Ribav-0003gH-8q;
	Thu, 05 Jan 2012 00:54:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ribav-0006Xa-8N;
	Thu, 05 Jan 2012 00:54:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10632-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 00:54:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10632: 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 10632 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10632/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  efaa28639a71
baseline version:
 xen                  50117a4d1a2c

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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=efaa28639a71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 efaa28639a71
+ branch=xen-unstable
+ revision=efaa28639a71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 efaa28639a71 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 5 changes to 4 files

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 00:54:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 00:54:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ribb3-00014W-MJ; Thu, 05 Jan 2012 00:54: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 1Ribb1-000143-Qp
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:54:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325724805!51277956!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26653 invoked from network); 5 Jan 2012 00:53:25 -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 Jan 2012 00:53:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,459,1320624000"; 
   d="scan'208";a="9824453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 00:54: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, 5 Jan 2012 00:54: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 1Ribav-0003gH-8q;
	Thu, 05 Jan 2012 00:54:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ribav-0006Xa-8N;
	Thu, 05 Jan 2012 00:54:13 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10632-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 00:54:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10632: 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 10632 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10632/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  efaa28639a71
baseline version:
 xen                  50117a4d1a2c

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <haitao.shan@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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=efaa28639a71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 efaa28639a71
+ branch=xen-unstable
+ revision=efaa28639a71
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 efaa28639a71 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 5 changes to 4 files

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 02:37:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 02:37:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RidBy-0005s1-VF; Thu, 05 Jan 2012 02:36:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1RidBy-0005rw-2F
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 02:36:34 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325730986!7170450!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 14504 invoked from network); 5 Jan 2012 02:36: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;
	5 Jan 2012 02:36: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 1RidBp-0007HJ-Ow
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:36:25 -0800
Date: Wed, 4 Jan 2012 18:36:25 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1325730985766-5121613.post@n5.nabble.com>
In-Reply-To: <1325300125668-5111504.post@n5.nabble.com>
References: <1325300125668-5111504.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [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, Keir and George, thanks for your concerns.

Access race to svc->flags seems inevitably when csched_acct calls
vcpu_pause_nosync:
    vm excutes PAUSE instruction.
    hypercalls call csched_vcpu_yield.

I had think about taking csched_private->lock in csched_vcpu_yield, but
csched_acct takes this lock for a long time so that csched_vcpu_yield may
been blocked for long time too, so I chooes set_bit and clear_bit.

Atomic operations using LOCK prefix (like set_bit and clear_bit) will block
all the physical cpus which excute memory access. Does this fact implies
that spin locks are more efficient when their's granularity is small?

Sorry for my poor english.

Liuyi

--
View this message in context: http://xen.1045712.n5.nabble.com/credit-scheduler-svc-flags-access-race-tp5111504p5121613.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 Jan 05 02:37:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 02:37:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RidBy-0005s1-VF; Thu, 05 Jan 2012 02:36:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <liu.yi24@zte.com.cn>) id 1RidBy-0005rw-2F
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 02:36:34 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325730986!7170450!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 14504 invoked from network); 5 Jan 2012 02:36: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;
	5 Jan 2012 02:36: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 1RidBp-0007HJ-Ow
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 18:36:25 -0800
Date: Wed, 4 Jan 2012 18:36:25 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1325730985766-5121613.post@n5.nabble.com>
In-Reply-To: <1325300125668-5111504.post@n5.nabble.com>
References: <1325300125668-5111504.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [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, Keir and George, thanks for your concerns.

Access race to svc->flags seems inevitably when csched_acct calls
vcpu_pause_nosync:
    vm excutes PAUSE instruction.
    hypercalls call csched_vcpu_yield.

I had think about taking csched_private->lock in csched_vcpu_yield, but
csched_acct takes this lock for a long time so that csched_vcpu_yield may
been blocked for long time too, so I chooes set_bit and clear_bit.

Atomic operations using LOCK prefix (like set_bit and clear_bit) will block
all the physical cpus which excute memory access. Does this fact implies
that spin locks are more efficient when their's granularity is small?

Sorry for my poor english.

Liuyi

--
View this message in context: http://xen.1045712.n5.nabble.com/credit-scheduler-svc-flags-access-race-tp5111504p5121613.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 Jan 05 03:11:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 03: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 1Ridim-00067h-O3; Thu, 05 Jan 2012 03:10:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Ridil-00067c-Ma
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 03:10:27 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325733020!9152967!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTExNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28852 invoked from network); 5 Jan 2012 03:10:20 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-13.tower-216.messagelabs.com with SMTP;
	5 Jan 2012 03:10:20 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00LWN22Q4M@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:08:50 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00JYP22JCW@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:08:50 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGE76741; Thu,
	05 Jan 2012 11:08:48 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:08:47 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:08:41 +0800
Date: Thu, 05 Jan 2012 03:08:37 +0000
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.3.1+1444a42f6052
X-Mercurial-Node: 052727b8165ce6e05002184ae894096214c8b537
X-CFilter-Loop: Reflected
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in
	in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5578638836688911092=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5578638836688911092==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User hongkaixing<hongkaixing@huawei.com>
# Date 1325149704 -28800
# Node ID 052727b8165ce6e05002184ae894096214c8b537
# Parent  54a5e994a241a506900ee0e197bb42e5f1d8e759
xenpaging:add a new array to speed up page-in in xenpaging

This patch adds a new array named page_out_index to reserve the victim's index.
When page in a page,it has to go through a for loop from 0 to num_pages to find
the right page to read,and it costs much time in this loop.After adding the
page_out_index array,it just reads the arrry to get the right page,and saves much time.

The following is a xenpaging test on suse11-64 with 4G memories.

Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
512M(131072)		    2.6s		           540s			             530s
2G(524288)		    15.5s		           2088s			     2055s

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 54a5e994a241 -r 052727b8165c tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Wed Nov 02 17:09:09 2011 +0000
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
@@ -599,6 +599,7 @@
     struct sigaction act;
     xenpaging_t *paging;
     xenpaging_victim_t *victims;
+    victim_to_i_t *page_out_index = NULL;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int i;
@@ -637,6 +638,17 @@
     }
 
     victims = calloc(paging->num_pages, sizeof(xenpaging_victim_t));
+    if (NULL == victims)
+    {
+        ERROR("Failed to alloc memory\n");
+        goto out;
+    }
+    page_out_index = (victim_to_i_t *)calloc(paging->domain_info->max_pages, sizeof(victim_to_i_t));
+    if ( NULL == page_out_index )
+    {
+        ERROR("Failed to alloc memory\n");
+        goto out;
+    }
 
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
@@ -660,6 +672,7 @@
             break;
         if ( i % 100 == 0 )
             DPRINTF("%d pages evicted\n", i);
+        page_out_index[victims[i].gfn].index=i;
     }
 
     DPRINTF("%d pages evicted. Done.\n", i);
@@ -687,17 +700,7 @@
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->num_pages; i++ )
-                {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->num_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
-                    goto out;
-                }
+                i = page_out_index[req.gfn].index ;
                 
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
@@ -733,7 +736,11 @@
                 if ( interrupted )
                     victims[i].gfn = INVALID_MFN;
                 else
+                {
                     evict_victim(paging, &victims[i], fd, i);
+                    if( victims[i].gfn !=INVALID_MFN )
+                        page_out_index[victims[i].gfn].index = i;
+                }
             }
             else
             {
@@ -798,7 +805,15 @@
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
+    if ( NULL != victims )
+    {
+        free(victims);
+    }
+
+    if ( NULL != page_out_index )
+    {
+        free(page_out_index);
+    }
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 54a5e994a241 -r 052727b8165c tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h	Wed Nov 02 17:09:09 2011 +0000
+++ b/tools/xenpaging/xenpaging.h	Thu Dec 29 17:08:24 2011 +0800
@@ -54,6 +54,10 @@
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;
 
+typedef struct victim_to_i {
+    /* the index of victim array to read from */
+    int index;
+} victim_to_i_t;
 
 typedef struct xenpaging_victim {
     /* the gfn of the page to evict */


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

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

--===============5578638836688911092==--

From xen-devel-bounces@lists.xensource.com Thu Jan 05 03:11:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 03: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 1Ridim-00067h-O3; Thu, 05 Jan 2012 03:10:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Ridil-00067c-Ma
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 03:10:27 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325733020!9152967!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTExNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28852 invoked from network); 5 Jan 2012 03:10:20 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-13.tower-216.messagelabs.com with SMTP;
	5 Jan 2012 03:10:20 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00LWN22Q4M@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:08:50 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00JYP22JCW@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:08:50 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGE76741; Thu,
	05 Jan 2012 11:08:48 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:08:47 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:08:41 +0800
Date: Thu, 05 Jan 2012 03:08:37 +0000
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.3.1+1444a42f6052
X-Mercurial-Node: 052727b8165ce6e05002184ae894096214c8b537
X-CFilter-Loop: Reflected
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in
	in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5578638836688911092=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5578638836688911092==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User hongkaixing<hongkaixing@huawei.com>
# Date 1325149704 -28800
# Node ID 052727b8165ce6e05002184ae894096214c8b537
# Parent  54a5e994a241a506900ee0e197bb42e5f1d8e759
xenpaging:add a new array to speed up page-in in xenpaging

This patch adds a new array named page_out_index to reserve the victim's index.
When page in a page,it has to go through a for loop from 0 to num_pages to find
the right page to read,and it costs much time in this loop.After adding the
page_out_index array,it just reads the arrry to get the right page,and saves much time.

The following is a xenpaging test on suse11-64 with 4G memories.

Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
512M(131072)		    2.6s		           540s			             530s
2G(524288)		    15.5s		           2088s			     2055s

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 54a5e994a241 -r 052727b8165c tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Wed Nov 02 17:09:09 2011 +0000
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
@@ -599,6 +599,7 @@
     struct sigaction act;
     xenpaging_t *paging;
     xenpaging_victim_t *victims;
+    victim_to_i_t *page_out_index = NULL;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int i;
@@ -637,6 +638,17 @@
     }
 
     victims = calloc(paging->num_pages, sizeof(xenpaging_victim_t));
+    if (NULL == victims)
+    {
+        ERROR("Failed to alloc memory\n");
+        goto out;
+    }
+    page_out_index = (victim_to_i_t *)calloc(paging->domain_info->max_pages, sizeof(victim_to_i_t));
+    if ( NULL == page_out_index )
+    {
+        ERROR("Failed to alloc memory\n");
+        goto out;
+    }
 
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
@@ -660,6 +672,7 @@
             break;
         if ( i % 100 == 0 )
             DPRINTF("%d pages evicted\n", i);
+        page_out_index[victims[i].gfn].index=i;
     }
 
     DPRINTF("%d pages evicted. Done.\n", i);
@@ -687,17 +700,7 @@
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->num_pages; i++ )
-                {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->num_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
-                    goto out;
-                }
+                i = page_out_index[req.gfn].index ;
                 
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
@@ -733,7 +736,11 @@
                 if ( interrupted )
                     victims[i].gfn = INVALID_MFN;
                 else
+                {
                     evict_victim(paging, &victims[i], fd, i);
+                    if( victims[i].gfn !=INVALID_MFN )
+                        page_out_index[victims[i].gfn].index = i;
+                }
             }
             else
             {
@@ -798,7 +805,15 @@
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
+    if ( NULL != victims )
+    {
+        free(victims);
+    }
+
+    if ( NULL != page_out_index )
+    {
+        free(page_out_index);
+    }
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 54a5e994a241 -r 052727b8165c tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h	Wed Nov 02 17:09:09 2011 +0000
+++ b/tools/xenpaging/xenpaging.h	Thu Dec 29 17:08:24 2011 +0800
@@ -54,6 +54,10 @@
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;
 
+typedef struct victim_to_i {
+    /* the index of victim array to read from */
+    int index;
+} victim_to_i_t;
 
 typedef struct xenpaging_victim {
     /* the gfn of the page to evict */


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

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

--===============5578638836688911092==--

From xen-devel-bounces@lists.xensource.com Thu Jan 05 03:51:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 03:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RieME-0006MZ-0s; Thu, 05 Jan 2012 03:51:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RieMC-0006MR-1F
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 03:51:12 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325735464!9655522!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTExNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15322 invoked from network); 5 Jan 2012 03:51:05 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-3.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 03:51:05 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00I1M410PA@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:51:01 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00CXK410WI@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:51:00 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGC69000; Thu,
	05 Jan 2012 11:51:00 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153)
	by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:59 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:50 +0800
Date: Thu, 05 Jan 2012 03:50:30 +0000
From: hongkaixing@huawei.com
In-reply-to: <patchbomb.1325735428@h00166998.china.huawei.com>
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <978daceef147273920f2.1325735430@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.3.1+1444a42f6052
X-Mercurial-Node: 978daceef147273920f298556489b60dc32ce458
X-CFilter-Loop: Reflected
References: <patchbomb.1325735428@h00166998.china.huawei.com>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in process to
	speed up page-in in	xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3033599984051250899=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3033599984051250899==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User hongkaixing<hongkaixing@huawei.com>
# Date 1325158899 -28800
# Node ID 978daceef147273920f298556489b60dc32ce458
# Parent  052727b8165ce6e05002184ae894096214c8b537
xenpaging:change page-in process to speed up page-in in xenpaging
In this patch,we change the page-in process.Firstly,we add a new function paging_in_trigger_sync
to handle page-in requests directly.and when the requests' count is up to 32,then handle them
batchly;Most importantly,we use an increasing gfn to test_bit,which saves much time.
In p2m.c,we changes p2m_mem_paging_populate() to return a value;
The following is a xenpaging test on suse11-64 with 4G memory.

Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
512M(131072)		    2.6s		        540s		              4.7s
2G(524288)		    15.5s		        2088s		      	      17.7s

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
+++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
@@ -73,6 +73,13 @@
                                 NULL, NULL, gfn);
 }
 
+int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned long gfn)
+{
+    return xc_mem_event_control(xch, domain_id,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING, 
+                                NULL, NULL, gfn);
+}
 
 /*
  * Local variables:
diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
+++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
@@ -1841,6 +1841,7 @@
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
+int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned long gfn); 
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
@@ -594,6 +594,13 @@
     return ret;
 }
 
+static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long gfn)
+{
+    int rc = 0;
+    rc = xc_mem_paging_in(paging->xc_handle, paging->mem_event.domain_id,gfn);
+    return rc;
+}
+
 int main(int argc, char *argv[])
 {
     struct sigaction act;
@@ -605,6 +612,9 @@
     int i;
     int rc = -1;
     int rc1;
+    int request_count = 0;
+    unsigned long page_in_start_gfn = 0;
+    unsigned long real_page = 0;
     xc_interface *xch;
 
     int open_flags = O_CREAT | O_TRUNC | O_RDWR;
@@ -773,24 +783,51 @@
         /* Write all pages back into the guest */
         if ( interrupted == SIGTERM || interrupted == SIGINT )
         {
-            int num = 0;
+            request_count = 0;
             for ( i = 0; i < paging->domain_info->max_pages; i++ )
             {
-                if ( test_bit(i, paging->bitmap) )
+                real_page = i + page_in_start_gfn;
+                real_page %= paging->domain_info->max_pages;
+                if ( test_bit(real_page, paging->bitmap) )
                 {
-                    paging->pagein_queue[num] = i;
-                    num++;
-                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
-                        break;
+                    rc = paging_in_trigger_sync(paging,real_page);
+                    if ( 0 == rc )
+                    {
+                        request_count++;
+                        /* If page_in requests up to 32 then handle them */
+                        if( request_count >= 32 )
+                        {
+                            page_in_start_gfn=real_page + 1;
+                            break;
+                        }
+                    }
+                    else
+                    {
+                        /* If IO ring is full then handle requests to free space */
+                        if( ENOSPC == errno )
+                        {
+                            page_in_start_gfn = real_page;
+                            break;
+                        }
+                        /* If p2mt is not p2m_is_paging,then clear bitmap;
+                        * e.g. a page is paged then it is dropped by balloon.
+                        */
+                        else if ( EINVAL == errno )
+                        {
+                            clear_bit(i,paging->bitmap);
+                            policy_notify_paged_in(i);
+                        }
+                        /* If hypercall fails then go to teardown xenpaging */
+                        else 
+                        {
+                            ERROR("Error paging in page");
+                            goto out;
+                        }
+                    }
                 }
             }
-            /*
-             * One more round if there are still pages to process.
-             * If no more pages to process, exit loop.
-             */
-            if ( num )
-                page_in_trigger();
-            else if ( i == paging->domain_info->max_pages )
+            if( (i==paging->domain_info->max_pages) && 
+                !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
                 break;
         }
         else
diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
+++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
@@ -57,7 +57,14 @@
         return 0;
     }
     break;
-
+    
+    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
+    {
+        unsigned long gfn = mec->gfn;
+        return p2m_mem_paging_populate(d, gfn);
+    }
+    break;
+    
     default:
         return -ENOSYS;
         break;
diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
+++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
@@ -874,7 +874,7 @@
  * already sent to the pager. In this case the caller has to try again until the
  * gfn is fully paged in again.
  */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
@@ -882,10 +882,12 @@
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int ret;
 
     /* Check that there's space on the ring for this request */
+    ret = -ENOSPC;
     if ( mem_event_check_ring(d, &d->mem_paging) )
-        return;
+        goto out;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -905,19 +907,27 @@
     }
     p2m_unlock(p2m);
 
+    ret = -EINVAL;
     /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
+    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
     {
         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 )
+    else if ( p2mt == p2m_ram_paging_in_start || p2mt == p2m_ram_paging_in )
     {
         /* gfn is already on its way back and vcpu is not paused */
         mem_event_put_req_producers(&d->mem_paging);
-        return;
+        return 0;
     }
+    else if ( !p2m_is_paging(p2mt) )
+    {
+        /* please clear the bit in paging->bitmap; */
+        mem_event_put_req_producers(&d->mem_paging);
+        goto out;
+    }
+
 
     /* Send request to pager */
     req.gfn = gfn;
@@ -925,8 +935,13 @@
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_paging, &req);
+    
+    ret = 0;
+ out:
+    return ret;   
 }
 
+
 /**
  * p2m_mem_paging_prep - Allocate a new page for the guest
  * @d: guest domain
diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
+++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
@@ -485,7 +485,7 @@
 /* Tell xenpaging to drop a paged out frame */
 void 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);
+int 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);
 /* Resume normal operation (in case a domain was paused) */
diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
+++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
@@ -721,6 +721,7 @@
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
+#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
 
 /*
  * Access permissions.


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

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

--===============3033599984051250899==--

From xen-devel-bounces@lists.xensource.com Thu Jan 05 03:51:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 03:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RieME-0006MZ-0s; Thu, 05 Jan 2012 03:51:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RieMC-0006MR-1F
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 03:51:12 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325735464!9655522!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTExNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15322 invoked from network); 5 Jan 2012 03:51:05 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-3.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 03:51:05 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00I1M410PA@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:51:01 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00CXK410WI@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:51:00 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGC69000; Thu,
	05 Jan 2012 11:51:00 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153)
	by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:59 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:50 +0800
Date: Thu, 05 Jan 2012 03:50:30 +0000
From: hongkaixing@huawei.com
In-reply-to: <patchbomb.1325735428@h00166998.china.huawei.com>
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <978daceef147273920f2.1325735430@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.3.1+1444a42f6052
X-Mercurial-Node: 978daceef147273920f298556489b60dc32ce458
X-CFilter-Loop: Reflected
References: <patchbomb.1325735428@h00166998.china.huawei.com>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in process to
	speed up page-in in	xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3033599984051250899=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3033599984051250899==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User hongkaixing<hongkaixing@huawei.com>
# Date 1325158899 -28800
# Node ID 978daceef147273920f298556489b60dc32ce458
# Parent  052727b8165ce6e05002184ae894096214c8b537
xenpaging:change page-in process to speed up page-in in xenpaging
In this patch,we change the page-in process.Firstly,we add a new function paging_in_trigger_sync
to handle page-in requests directly.and when the requests' count is up to 32,then handle them
batchly;Most importantly,we use an increasing gfn to test_bit,which saves much time.
In p2m.c,we changes p2m_mem_paging_populate() to return a value;
The following is a xenpaging test on suse11-64 with 4G memory.

Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
512M(131072)		    2.6s		        540s		              4.7s
2G(524288)		    15.5s		        2088s		      	      17.7s

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
+++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
@@ -73,6 +73,13 @@
                                 NULL, NULL, gfn);
 }
 
+int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned long gfn)
+{
+    return xc_mem_event_control(xch, domain_id,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
+                                XEN_DOMCTL_MEM_EVENT_OP_PAGING, 
+                                NULL, NULL, gfn);
+}
 
 /*
  * Local variables:
diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
+++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
@@ -1841,6 +1841,7 @@
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
                          unsigned long gfn);
+int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned long gfn); 
 
 int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
@@ -594,6 +594,13 @@
     return ret;
 }
 
+static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long gfn)
+{
+    int rc = 0;
+    rc = xc_mem_paging_in(paging->xc_handle, paging->mem_event.domain_id,gfn);
+    return rc;
+}
+
 int main(int argc, char *argv[])
 {
     struct sigaction act;
@@ -605,6 +612,9 @@
     int i;
     int rc = -1;
     int rc1;
+    int request_count = 0;
+    unsigned long page_in_start_gfn = 0;
+    unsigned long real_page = 0;
     xc_interface *xch;
 
     int open_flags = O_CREAT | O_TRUNC | O_RDWR;
@@ -773,24 +783,51 @@
         /* Write all pages back into the guest */
         if ( interrupted == SIGTERM || interrupted == SIGINT )
         {
-            int num = 0;
+            request_count = 0;
             for ( i = 0; i < paging->domain_info->max_pages; i++ )
             {
-                if ( test_bit(i, paging->bitmap) )
+                real_page = i + page_in_start_gfn;
+                real_page %= paging->domain_info->max_pages;
+                if ( test_bit(real_page, paging->bitmap) )
                 {
-                    paging->pagein_queue[num] = i;
-                    num++;
-                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
-                        break;
+                    rc = paging_in_trigger_sync(paging,real_page);
+                    if ( 0 == rc )
+                    {
+                        request_count++;
+                        /* If page_in requests up to 32 then handle them */
+                        if( request_count >= 32 )
+                        {
+                            page_in_start_gfn=real_page + 1;
+                            break;
+                        }
+                    }
+                    else
+                    {
+                        /* If IO ring is full then handle requests to free space */
+                        if( ENOSPC == errno )
+                        {
+                            page_in_start_gfn = real_page;
+                            break;
+                        }
+                        /* If p2mt is not p2m_is_paging,then clear bitmap;
+                        * e.g. a page is paged then it is dropped by balloon.
+                        */
+                        else if ( EINVAL == errno )
+                        {
+                            clear_bit(i,paging->bitmap);
+                            policy_notify_paged_in(i);
+                        }
+                        /* If hypercall fails then go to teardown xenpaging */
+                        else 
+                        {
+                            ERROR("Error paging in page");
+                            goto out;
+                        }
+                    }
                 }
             }
-            /*
-             * One more round if there are still pages to process.
-             * If no more pages to process, exit loop.
-             */
-            if ( num )
-                page_in_trigger();
-            else if ( i == paging->domain_info->max_pages )
+            if( (i==paging->domain_info->max_pages) && 
+                !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
                 break;
         }
         else
diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
+++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
@@ -57,7 +57,14 @@
         return 0;
     }
     break;
-
+    
+    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
+    {
+        unsigned long gfn = mec->gfn;
+        return p2m_mem_paging_populate(d, gfn);
+    }
+    break;
+    
     default:
         return -ENOSYS;
         break;
diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
+++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
@@ -874,7 +874,7 @@
  * already sent to the pager. In this case the caller has to try again until the
  * gfn is fully paged in again.
  */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
@@ -882,10 +882,12 @@
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
+    int ret;
 
     /* Check that there's space on the ring for this request */
+    ret = -ENOSPC;
     if ( mem_event_check_ring(d, &d->mem_paging) )
-        return;
+        goto out;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -905,19 +907,27 @@
     }
     p2m_unlock(p2m);
 
+    ret = -EINVAL;
     /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
+    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
     {
         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 )
+    else if ( p2mt == p2m_ram_paging_in_start || p2mt == p2m_ram_paging_in )
     {
         /* gfn is already on its way back and vcpu is not paused */
         mem_event_put_req_producers(&d->mem_paging);
-        return;
+        return 0;
     }
+    else if ( !p2m_is_paging(p2mt) )
+    {
+        /* please clear the bit in paging->bitmap; */
+        mem_event_put_req_producers(&d->mem_paging);
+        goto out;
+    }
+
 
     /* Send request to pager */
     req.gfn = gfn;
@@ -925,8 +935,13 @@
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_paging, &req);
+    
+    ret = 0;
+ out:
+    return ret;   
 }
 
+
 /**
  * p2m_mem_paging_prep - Allocate a new page for the guest
  * @d: guest domain
diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
+++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
@@ -485,7 +485,7 @@
 /* Tell xenpaging to drop a paged out frame */
 void 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);
+int 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);
 /* Resume normal operation (in case a domain was paused) */
diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
+++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
@@ -721,6 +721,7 @@
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
+#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
 
 /*
  * Access permissions.


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

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

--===============3033599984051250899==--

From xen-devel-bounces@lists.xensource.com Thu Jan 05 03:53:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 03: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 1RieNb-0006PR-Hj; Thu, 05 Jan 2012 03:52:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RieNa-0006PD-4t
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 03:52:38 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325735550!9760387!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNDQxMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28795 invoked from network); 5 Jan 2012 03:52:31 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-12.tower-216.messagelabs.com with SMTP;
	5 Jan 2012 03:52:31 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB0032740QLF@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:50:50 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00LFI40QPY@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:50:50 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGC68979; Thu,
	05 Jan 2012 11:50:49 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153)
	by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:48 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:39 +0800
Date: Thu, 05 Jan 2012 03:50:29 +0000
From: hongkaixing@huawei.com
In-reply-to: <patchbomb.1325735428@h00166998.china.huawei.com>
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <052727b8165ce6e05002.1325735429@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.3.1+1444a42f6052
X-Mercurial-Node: 052727b8165ce6e05002184ae894096214c8b537
X-CFilter-Loop: Reflected
References: <patchbomb.1325735428@h00166998.china.huawei.com>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] xenpaging:add a new array to speed up
	page-in in	xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1947831671940206666=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1947831671940206666==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User hongkaixing<hongkaixing@huawei.com>
# Date 1325149704 -28800
# Node ID 052727b8165ce6e05002184ae894096214c8b537
# Parent  54a5e994a241a506900ee0e197bb42e5f1d8e759
xenpaging:add a new array to speed up page-in in xenpaging

This patch adds a new array named page_out_index to reserve the victim's index.
When page in a page,it has to go through a for loop from 0 to num_pages to find
the right page to read,and it costs much time in this loop.After adding the
page_out_index array,it just reads the arrry to get the right page,and saves much time.

The following is a xenpaging test on suse11-64 with 4G memories.

Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
512M(131072)		    2.6s		           540s			             530s
2G(524288)		    15.5s		           2088s			     2055s

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 54a5e994a241 -r 052727b8165c tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Wed Nov 02 17:09:09 2011 +0000
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
@@ -599,6 +599,7 @@
     struct sigaction act;
     xenpaging_t *paging;
     xenpaging_victim_t *victims;
+    victim_to_i_t *page_out_index = NULL;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int i;
@@ -637,6 +638,17 @@
     }
 
     victims = calloc(paging->num_pages, sizeof(xenpaging_victim_t));
+    if (NULL == victims)
+    {
+        ERROR("Failed to alloc memory\n");
+        goto out;
+    }
+    page_out_index = (victim_to_i_t *)calloc(paging->domain_info->max_pages, sizeof(victim_to_i_t));
+    if ( NULL == page_out_index )
+    {
+        ERROR("Failed to alloc memory\n");
+        goto out;
+    }
 
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
@@ -660,6 +672,7 @@
             break;
         if ( i % 100 == 0 )
             DPRINTF("%d pages evicted\n", i);
+        page_out_index[victims[i].gfn].index=i;
     }
 
     DPRINTF("%d pages evicted. Done.\n", i);
@@ -687,17 +700,7 @@
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->num_pages; i++ )
-                {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->num_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
-                    goto out;
-                }
+                i = page_out_index[req.gfn].index ;
                 
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
@@ -733,7 +736,11 @@
                 if ( interrupted )
                     victims[i].gfn = INVALID_MFN;
                 else
+                {
                     evict_victim(paging, &victims[i], fd, i);
+                    if( victims[i].gfn !=INVALID_MFN )
+                        page_out_index[victims[i].gfn].index = i;
+                }
             }
             else
             {
@@ -798,7 +805,15 @@
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
+    if ( NULL != victims )
+    {
+        free(victims);
+    }
+
+    if ( NULL != page_out_index )
+    {
+        free(page_out_index);
+    }
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 54a5e994a241 -r 052727b8165c tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h	Wed Nov 02 17:09:09 2011 +0000
+++ b/tools/xenpaging/xenpaging.h	Thu Dec 29 17:08:24 2011 +0800
@@ -54,6 +54,10 @@
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;
 
+typedef struct victim_to_i {
+    /* the index of victim array to read from */
+    int index;
+} victim_to_i_t;
 
 typedef struct xenpaging_victim {
     /* the gfn of the page to evict */


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

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

--===============1947831671940206666==--

From xen-devel-bounces@lists.xensource.com Thu Jan 05 03:53:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 03: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 1RieNb-0006PR-Hj; Thu, 05 Jan 2012 03:52:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RieNa-0006PD-4t
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 03:52:38 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325735550!9760387!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNDQxMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28795 invoked from network); 5 Jan 2012 03:52:31 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-12.tower-216.messagelabs.com with SMTP;
	5 Jan 2012 03:52:31 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB0032740QLF@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:50:50 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00LFI40QPY@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:50:50 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGC68979; Thu,
	05 Jan 2012 11:50:49 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153)
	by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:48 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:39 +0800
Date: Thu, 05 Jan 2012 03:50:29 +0000
From: hongkaixing@huawei.com
In-reply-to: <patchbomb.1325735428@h00166998.china.huawei.com>
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <052727b8165ce6e05002.1325735429@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.3.1+1444a42f6052
X-Mercurial-Node: 052727b8165ce6e05002184ae894096214c8b537
X-CFilter-Loop: Reflected
References: <patchbomb.1325735428@h00166998.china.huawei.com>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] xenpaging:add a new array to speed up
	page-in in	xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1947831671940206666=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1947831671940206666==
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT

# HG changeset patch
# User hongkaixing<hongkaixing@huawei.com>
# Date 1325149704 -28800
# Node ID 052727b8165ce6e05002184ae894096214c8b537
# Parent  54a5e994a241a506900ee0e197bb42e5f1d8e759
xenpaging:add a new array to speed up page-in in xenpaging

This patch adds a new array named page_out_index to reserve the victim's index.
When page in a page,it has to go through a for loop from 0 to num_pages to find
the right page to read,and it costs much time in this loop.After adding the
page_out_index array,it just reads the arrry to get the right page,and saves much time.

The following is a xenpaging test on suse11-64 with 4G memories.

Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
512M(131072)		    2.6s		           540s			             530s
2G(524288)		    15.5s		           2088s			     2055s

Signed-off-by£ºhongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>

diff -r 54a5e994a241 -r 052727b8165c tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c	Wed Nov 02 17:09:09 2011 +0000
+++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
@@ -599,6 +599,7 @@
     struct sigaction act;
     xenpaging_t *paging;
     xenpaging_victim_t *victims;
+    victim_to_i_t *page_out_index = NULL;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int i;
@@ -637,6 +638,17 @@
     }
 
     victims = calloc(paging->num_pages, sizeof(xenpaging_victim_t));
+    if (NULL == victims)
+    {
+        ERROR("Failed to alloc memory\n");
+        goto out;
+    }
+    page_out_index = (victim_to_i_t *)calloc(paging->domain_info->max_pages, sizeof(victim_to_i_t));
+    if ( NULL == page_out_index )
+    {
+        ERROR("Failed to alloc memory\n");
+        goto out;
+    }
 
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
@@ -660,6 +672,7 @@
             break;
         if ( i % 100 == 0 )
             DPRINTF("%d pages evicted\n", i);
+        page_out_index[victims[i].gfn].index=i;
     }
 
     DPRINTF("%d pages evicted. Done.\n", i);
@@ -687,17 +700,7 @@
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->num_pages; i++ )
-                {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->num_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
-                    goto out;
-                }
+                i = page_out_index[req.gfn].index ;
                 
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
@@ -733,7 +736,11 @@
                 if ( interrupted )
                     victims[i].gfn = INVALID_MFN;
                 else
+                {
                     evict_victim(paging, &victims[i], fd, i);
+                    if( victims[i].gfn !=INVALID_MFN )
+                        page_out_index[victims[i].gfn].index = i;
+                }
             }
             else
             {
@@ -798,7 +805,15 @@
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
+    if ( NULL != victims )
+    {
+        free(victims);
+    }
+
+    if ( NULL != page_out_index )
+    {
+        free(page_out_index);
+    }
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 54a5e994a241 -r 052727b8165c tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h	Wed Nov 02 17:09:09 2011 +0000
+++ b/tools/xenpaging/xenpaging.h	Thu Dec 29 17:08:24 2011 +0800
@@ -54,6 +54,10 @@
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;
 
+typedef struct victim_to_i {
+    /* the index of victim array to read from */
+    int index;
+} victim_to_i_t;
 
 typedef struct xenpaging_victim {
     /* the gfn of the page to evict */


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

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

--===============1947831671940206666==--

From xen-devel-bounces@lists.xensource.com Thu Jan 05 03:53:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 03:53:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RieNw-0006Qy-VQ; Thu, 05 Jan 2012 03:53:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RieNv-0006QV-NR
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 03:52:59 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325735572!9642064!1
X-Originating-IP: [58.251.152.66]
X-SpamReason: No, hits=0.3 required=7.0 tests=MIME_BASE64_TEXT
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27396 invoked from network); 5 Jan 2012 03:52:53 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(58.251.152.66) by server-10.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 03:52:53 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB0044D40F0T@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:50:39 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00AD640DE1@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:50:39 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGE79203; Thu,
	05 Jan 2012 11:50:38 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153)
	by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:32 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:31 +0800
Date: Thu, 05 Jan 2012 03:50:28 +0000
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <patchbomb.1325735428@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.3.1+1444a42f6052
X-CFilter-Loop: Reflected
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] xenpaging:speed up page-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="cp936"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhlIGZvbGxvd2luZyB0d28gcGF0Y2hlcyBhcmUgYWJvdXQgaG93IHRvIHNwZWVkIHVwIGluIHhl
bnBhZ2luZyB3aGVuIHBhZ2UgaW4gcGFnZXMuCk9uIHN1c2UxMS02NCB3aXRoIDRHIG1lbW9yeSxp
ZiB3ZSBwYWdlIG91dCAyRyBwYWdlcyxpdCB3aWxsIGNvc3QgYWJvdXQgMTUuNSBzZWNvbmRzLApi
dXQgdGFrZSAyMDg4IHNlY29uZHMgdG8gZmluaXNoIHBhZ2luZyBpbi5JZiBwYWdlLWluIGNvc3Rz
IHRvbyBtdWNoIHRpbWUsaXQgd2lsbCBjYXVzZQp1bm1lc3VyYWJsZSBwcm9ibGVtcyB3aGVuIHZt
IG9yIGRvbTAgYWNjZXNzIHRoZSBwYWdlZF9vdXQgcGFnZSxzdWNoIGFzIEJTT0QsY3Jhc2guCldo
YXTigJlzIG1vcmUsdGhlIGRvbTAgaXMgYWx3YXlzIGluIGhpZ2ggSS9PIHByZXNzdXJlLgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Jan 05 03:53:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 03:53:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RieNw-0006Qy-VQ; Thu, 05 Jan 2012 03:53:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RieNv-0006QV-NR
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 03:52:59 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325735572!9642064!1
X-Originating-IP: [58.251.152.66]
X-SpamReason: No, hits=0.3 required=7.0 tests=MIME_BASE64_TEXT
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27396 invoked from network); 5 Jan 2012 03:52:53 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(58.251.152.66) by server-10.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 03:52:53 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB0044D40F0T@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:50:39 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00AD640DE1@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:50:39 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGE79203; Thu,
	05 Jan 2012 11:50:38 +0800
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153)
	by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:32 +0800
Received: from h00166998.china.huawei.com (10.166.80.196)
	by SZXEML414-HUB.china.huawei.com (10.82.67.153) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 11:50:31 +0800
Date: Thu, 05 Jan 2012 03:50:28 +0000
From: hongkaixing@huawei.com
X-Originating-IP: [10.166.80.196]
To: Olaf Hering <olaf@aepfle.de>
Message-id: <patchbomb.1325735428@h00166998.china.huawei.com>
MIME-version: 1.0
User-Agent: Mercurial-patchbomb/1.3.1+1444a42f6052
X-CFilter-Loop: Reflected
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] xenpaging:speed up page-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="cp936"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VGhlIGZvbGxvd2luZyB0d28gcGF0Y2hlcyBhcmUgYWJvdXQgaG93IHRvIHNwZWVkIHVwIGluIHhl
bnBhZ2luZyB3aGVuIHBhZ2UgaW4gcGFnZXMuCk9uIHN1c2UxMS02NCB3aXRoIDRHIG1lbW9yeSxp
ZiB3ZSBwYWdlIG91dCAyRyBwYWdlcyxpdCB3aWxsIGNvc3QgYWJvdXQgMTUuNSBzZWNvbmRzLApi
dXQgdGFrZSAyMDg4IHNlY29uZHMgdG8gZmluaXNoIHBhZ2luZyBpbi5JZiBwYWdlLWluIGNvc3Rz
IHRvbyBtdWNoIHRpbWUsaXQgd2lsbCBjYXVzZQp1bm1lc3VyYWJsZSBwcm9ibGVtcyB3aGVuIHZt
IG9yIGRvbTAgYWNjZXNzIHRoZSBwYWdlZF9vdXQgcGFnZSxzdWNoIGFzIEJTT0QsY3Jhc2guCldo
YXTigJlzIG1vcmUsdGhlIGRvbTAgaXMgYWx3YXlzIGluIGhpZ2ggSS9PIHByZXNzdXJlLgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Jan 05 04:09:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 04:09:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiedL-0006wW-Nu; Thu, 05 Jan 2012 04:08:55 +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 1RiedK-0006wO-8b
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 04:08:54 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325736526!9606478!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzMzAz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4308 invoked from network); 5 Jan 2012 04:08:46 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-216.messagelabs.com with SMTP;
	5 Jan 2012 04:08:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 04 Jan 2012 20:08:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="94629370"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 04 Jan 2012 20:08:43 -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; Thu, 5 Jan 2012 12:08:42 +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; Thu, 5 Jan 2012 12:08:42 +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, 5 Jan 2012 12:08:41 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "George.Dunlap@eu.citrix.com"
	<George.Dunlap@eu.citrix.com>
Thread-Topic: [PATCH] xen/sched_credit: Use delay to control scheduling
	frequency
Thread-Index: AQHMw+UZfvXlFfj3x0u7hY1iQlJRmJX4QIgAgAT1tqA=
Date: Thu, 5 Jan 2012 04:08:40 +0000
Message-ID: <E3E4738020A00E46AC373AD41F7FEAD50118FA@SHSMSX101.ccr.corp.intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
	<4F0176940200007800069FE8@nat28.tlf.novell.com>
In-Reply-To: <4F0176940200007800069FE8@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"raistlin@linux.it" <raistlin@linux.it>,
	"Ian.Campbell@citrix.com" <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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

George, 

Any comments for this? 

Is it the right "warning" way?


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, January 02, 2012 4:19 PM
> To: Lv, Hui
> Cc: Ian.Campbell@citrix.com; George.Dunlap@eu.citrix.com;
> raistlin@linux.it; xen-devel@lists.xensource.com
> Subject: Re: [PATCH] xen/sched_credit: Use delay to control scheduling
> frequency
> 
> >>> On 26.12.11 at 09:46, Hui Lv <hui.lv@intel.com> wrote:
> > 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.
> 
> I do not see why you need a per-scheduler-instance variable for
> issuing the warning and correcting the value - one warning (during
> the first initialization) is entirely sufficient. (Otoh the already
> existing
> tslice_ms field is pointless currently too, as it never gets changed
> after being initialized from sched_credit_tslice_ms - George?)
> 
> Jan
> 
> > 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 Thu Jan 05 04:09:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 04:09:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiedL-0006wW-Nu; Thu, 05 Jan 2012 04:08:55 +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 1RiedK-0006wO-8b
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 04:08:54 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1325736526!9606478!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzMzAz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4308 invoked from network); 5 Jan 2012 04:08:46 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-16.tower-216.messagelabs.com with SMTP;
	5 Jan 2012 04:08:46 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 04 Jan 2012 20:08:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="94629370"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by orsmga002.jf.intel.com with ESMTP; 04 Jan 2012 20:08:43 -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; Thu, 5 Jan 2012 12:08:42 +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; Thu, 5 Jan 2012 12:08:42 +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, 5 Jan 2012 12:08:41 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: Jan Beulich <JBeulich@suse.com>, "George.Dunlap@eu.citrix.com"
	<George.Dunlap@eu.citrix.com>
Thread-Topic: [PATCH] xen/sched_credit: Use delay to control scheduling
	frequency
Thread-Index: AQHMw+UZfvXlFfj3x0u7hY1iQlJRmJX4QIgAgAT1tqA=
Date: Thu, 5 Jan 2012 04:08:40 +0000
Message-ID: <E3E4738020A00E46AC373AD41F7FEAD50118FA@SHSMSX101.ccr.corp.intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
	<4F0176940200007800069FE8@nat28.tlf.novell.com>
In-Reply-To: <4F0176940200007800069FE8@nat28.tlf.novell.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"raistlin@linux.it" <raistlin@linux.it>,
	"Ian.Campbell@citrix.com" <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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

George, 

Any comments for this? 

Is it the right "warning" way?


> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Monday, January 02, 2012 4:19 PM
> To: Lv, Hui
> Cc: Ian.Campbell@citrix.com; George.Dunlap@eu.citrix.com;
> raistlin@linux.it; xen-devel@lists.xensource.com
> Subject: Re: [PATCH] xen/sched_credit: Use delay to control scheduling
> frequency
> 
> >>> On 26.12.11 at 09:46, Hui Lv <hui.lv@intel.com> wrote:
> > 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.
> 
> I do not see why you need a per-scheduler-instance variable for
> issuing the warning and correcting the value - one warning (during
> the first initialization) is entirely sufficient. (Otoh the already
> existing
> tslice_ms field is pointless currently too, as it never gets changed
> after being initialized from sched_credit_tslice_ms - George?)
> 
> Jan
> 
> > 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 Thu Jan 05 05:09:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 05:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RifYz-0007Qr-Eo; Thu, 05 Jan 2012 05:08:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RifYy-0007Qm-7w
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 05:08:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325740101!7861583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18616 invoked from network); 5 Jan 2012 05:08:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 05:08:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,460,1320624000"; 
   d="scan'208";a="9825330"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 05:08: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, 5 Jan 2012 05:08: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 1RifYq-0005Ne-D6;
	Thu, 05 Jan 2012 05:08:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RifYq-0001Xz-0z;
	Thu, 05 Jan 2012 05:08:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10635-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 05:08:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10635: 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 10635 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10635/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-win            7 windows-install             fail pass in 10632
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 10632
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10632

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-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
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check      fail in 10632 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10632 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10632 never pass

version targeted for testing:
 xen                  efaa28639a71
baseline version:
 xen                  efaa28639a71

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Thu Jan 05 05:09:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 05:09:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RifYz-0007Qr-Eo; Thu, 05 Jan 2012 05:08:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RifYy-0007Qm-7w
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 05:08:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325740101!7861583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18616 invoked from network); 5 Jan 2012 05:08:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 05:08:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,460,1320624000"; 
   d="scan'208";a="9825330"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 05:08: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, 5 Jan 2012 05:08: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 1RifYq-0005Ne-D6;
	Thu, 05 Jan 2012 05:08:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RifYq-0001Xz-0z;
	Thu, 05 Jan 2012 05:08:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10635-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 05:08:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10635: 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 10635 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10635/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-i386-i386-win            7 windows-install             fail pass in 10632
 test-i386-i386-xl-winxpsp3    7 windows-install             fail pass in 10632
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10632

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-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
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-win           16 leak-check/check      fail in 10632 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 10632 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10632 never pass

version targeted for testing:
 xen                  efaa28639a71
baseline version:
 xen                  efaa28639a71

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Thu Jan 05 06:14:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 06:14:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RigaY-0007pN-Kq; Thu, 05 Jan 2012 06:14:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RigaX-0007pI-13
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 06:14:09 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325744041!2334208!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNDQxMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23402 invoked from network); 5 Jan 2012 06:14:01 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-16.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 06:14:01 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB005Q2ANB6P@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:14:00 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00CS8AN51R@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:13:59 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGC78950; Thu,
	05 Jan 2012 14:13:58 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 14:13:57 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Thu, 05 Jan 2012 14:13:41 +0800
Date: Thu, 05 Jan 2012 06:13:40 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
X-Originating-IP: [10.166.82.189]
To: Liuyongan <liuyongan@huawei.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"keir@xen.org" <keir@xen.org>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: BO3K BwhS C7Sz HPuc JZkg O2Y1 QLvw QkNL RZKu SEvQ SOuR TfBT
	c5LL dOqS fH77 g6wG; 3;
	YQBuAGQAcgBlAHcALgBjAG8AbwBwAGUAcgAzAEAAYwBpAHQAcgBpAHgALgBjAG8AbQA7AGsAZQBpAHIAQAB4AGUAbgAuAG8AcgBnADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {4923AF6C-C9DA-4EFA-AE58-DDE1D42689AD};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu,
	05 Jan 2012 06:13:35 GMT;
	UgBFADoAIABbAHgAZQBuAC0AZABlAHYAZQBsAF0AIABjAHIAZQBhAHQAZQAgAGkAcgBxACAAZgBhAGkAbABlAGQAIABkAHUAZQAgAHQAbwAgAG0AbwB2AGUAXwBjAGwAZQBhAG4AdQBwAF8AYwBvAHUAbgB0ACAAYQBsAHcAYQB5AHMAIABiAGUAaQBuAGcAIABzAGUAdAA=
x-cr-puzzleid: {4923AF6C-C9DA-4EFA-AE58-DDE1D42689AD}
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
Cc: Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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 04/01/12 11:38, Andrew Cooper wrote:
>> On 04/01/12 04:37, Liuyongan wrote:
>> Hi, all
>>    
>>     I'm using xen-4.0 to do a test. And when I create a domain, it failed due to create_irq() failure. As only 33 domains were successfully created and destroyed before I got the continuous failures, and the domain just before the failure was properly destroyed(at least destroy_irq() was properly called, which will clear move_in_progress, according to the prink-message). So I can conclude for certain that __assign_irq_vector failed due to move_cleanup_count always being set.
> Is it always 33 domains it takes to cause the problem, or does it vary? 
> If it varies, then I think you want this patch
> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01 which
> corrects the logic which works out which moved vectors it should clean
> up.  Without it, stale irq numbers build up in the per-cpu irq_vector
> tables leading to __assign_irq_vector failing with -ENOSPC as it find
> find a vector to allocate.

  Yes, I've noticed this patch, as only 33 domains were created before the failures, so vectors of a given cpu should not have been used up. Besides, I got this problem after 143 domains were created another time. But I could not repeat this problem manually as 4000+ domains created successfully without this problem.

>
>> //this is the normal case when create and destroy domain whose id is 31;
>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
>> (XEN) irq.c:223, destroy irq 77
>>
>> //domain id 32 is created and destroyed correctly also.
>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
>> (XEN) irq.c:223, destroy irq 77
>>
>> //all the subsequent domain creation failed, below lists only 3 times:
>> (XEN) physdev.c:88: dom33: can't create irq for msi!
>> (XEN) physdev.c:88: dom34: can't create irq for msi!
>> (XEN) physdev.c:88: dom35: can't create irq for msi!
>>
>>      I think this might be a bug and might have fixed, so I compare my code with 4.1.2 and search the mail list for potential patches. (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanup_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which add locks in __assign_irq_vector. Can anybody explain why this lock is needed? Or is there a patch that might fix my bug? Thx.
> This patch fixes a problem where IOAPIC line level interrupts cease for
> a while.  It has nothing to do with MSI interrupts.  (Also, there are no
> locks altered, and xen-4.0-testing seems to have gained an additional
> hunk in hvm/vmx code unrelated to the original patch.)
>
>>     Addition message: my board is arch-x86, no domains left when failed to create new ones, create_irq failure lasted one day until I reboot the board, and the irq number allocated is used certainly for a msi dev.
>>
>> Yong an Liu
>> 2012.1.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 Thu Jan 05 06:14:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 06:14:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RigaY-0007pN-Kq; Thu, 05 Jan 2012 06:14:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RigaX-0007pI-13
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 06:14:09 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325744041!2334208!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNDQxMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23402 invoked from network); 5 Jan 2012 06:14:01 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-16.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 06:14:01 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB005Q2ANB6P@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:14:00 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00CS8AN51R@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:13:59 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGC78950; Thu,
	05 Jan 2012 14:13:58 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 14:13:57 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Thu, 05 Jan 2012 14:13:41 +0800
Date: Thu, 05 Jan 2012 06:13:40 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
X-Originating-IP: [10.166.82.189]
To: Liuyongan <liuyongan@huawei.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"keir@xen.org" <keir@xen.org>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: BO3K BwhS C7Sz HPuc JZkg O2Y1 QLvw QkNL RZKu SEvQ SOuR TfBT
	c5LL dOqS fH77 g6wG; 3;
	YQBuAGQAcgBlAHcALgBjAG8AbwBwAGUAcgAzAEAAYwBpAHQAcgBpAHgALgBjAG8AbQA7AGsAZQBpAHIAQAB4AGUAbgAuAG8AcgBnADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {4923AF6C-C9DA-4EFA-AE58-DDE1D42689AD};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu,
	05 Jan 2012 06:13:35 GMT;
	UgBFADoAIABbAHgAZQBuAC0AZABlAHYAZQBsAF0AIABjAHIAZQBhAHQAZQAgAGkAcgBxACAAZgBhAGkAbABlAGQAIABkAHUAZQAgAHQAbwAgAG0AbwB2AGUAXwBjAGwAZQBhAG4AdQBwAF8AYwBvAHUAbgB0ACAAYQBsAHcAYQB5AHMAIABiAGUAaQBuAGcAIABzAGUAdAA=
x-cr-puzzleid: {4923AF6C-C9DA-4EFA-AE58-DDE1D42689AD}
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
Cc: Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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 04/01/12 11:38, Andrew Cooper wrote:
>> On 04/01/12 04:37, Liuyongan wrote:
>> Hi, all
>>    
>>     I'm using xen-4.0 to do a test. And when I create a domain, it failed due to create_irq() failure. As only 33 domains were successfully created and destroyed before I got the continuous failures, and the domain just before the failure was properly destroyed(at least destroy_irq() was properly called, which will clear move_in_progress, according to the prink-message). So I can conclude for certain that __assign_irq_vector failed due to move_cleanup_count always being set.
> Is it always 33 domains it takes to cause the problem, or does it vary? 
> If it varies, then I think you want this patch
> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01 which
> corrects the logic which works out which moved vectors it should clean
> up.  Without it, stale irq numbers build up in the per-cpu irq_vector
> tables leading to __assign_irq_vector failing with -ENOSPC as it find
> find a vector to allocate.

  Yes, I've noticed this patch, as only 33 domains were created before the failures, so vectors of a given cpu should not have been used up. Besides, I got this problem after 143 domains were created another time. But I could not repeat this problem manually as 4000+ domains created successfully without this problem.

>
>> //this is the normal case when create and destroy domain whose id is 31;
>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
>> (XEN) irq.c:223, destroy irq 77
>>
>> //domain id 32 is created and destroyed correctly also.
>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
>> (XEN) irq.c:223, destroy irq 77
>>
>> //all the subsequent domain creation failed, below lists only 3 times:
>> (XEN) physdev.c:88: dom33: can't create irq for msi!
>> (XEN) physdev.c:88: dom34: can't create irq for msi!
>> (XEN) physdev.c:88: dom35: can't create irq for msi!
>>
>>      I think this might be a bug and might have fixed, so I compare my code with 4.1.2 and search the mail list for potential patches. (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanup_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which add locks in __assign_irq_vector. Can anybody explain why this lock is needed? Or is there a patch that might fix my bug? Thx.
> This patch fixes a problem where IOAPIC line level interrupts cease for
> a while.  It has nothing to do with MSI interrupts.  (Also, there are no
> locks altered, and xen-4.0-testing seems to have gained an additional
> hunk in hvm/vmx code unrelated to the original patch.)
>
>>     Addition message: my board is arch-x86, no domains left when failed to create new ones, create_irq failure lasted one day until I reboot the board, and the irq number allocated is used certainly for a msi dev.
>>
>> Yong an Liu
>> 2012.1.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 Thu Jan 05 06:23:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 06:23:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RigjR-0007zK-MM; Thu, 05 Jan 2012 06:23:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RigjQ-0007zF-JQ
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 06:23:20 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325744592!9634503!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTExNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23244 invoked from network); 5 Jan 2012 06:23:13 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-11.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 06:23:13 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00GLSB08TG@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:21:44 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB003LGAZUW5@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:21:44 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGC79826; Thu,
	05 Jan 2012 14:21:44 +0800
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159)
	by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 14:21:43 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml420-hub.china.huawei.com ([10.82.67.159])
	with mapi id 14.01.0323.003; Thu, 05 Jan 2012 14:21:23 +0800
Date: Thu, 05 Jan 2012 06:21:23 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"keir@xen.org" <keir@xen.org>, Liuyongan <liuyongan@huawei.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E414@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_LFvGxF9VChClVuj8JJlpyA)"
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel][PATCH]  x86/IRQ: IRR and TMR race condition bug fix
Thread-index: AczLcj6f7qsLv0ewTO+Kx6/jVG4/kA==
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Cc: Qianhuibin <qianhuibin@huawei.com>
Subject: [Xen-devel] [PATCH]  x86/IRQ: IRR and TMR race condition bug 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


--Boundary_(ID_LFvGxF9VChClVuj8JJlpyA)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT

In vlapic_set_irq, we set the IRR register before the TMR. And the IRR might be serviced before setting TMR, and even worse EOI might occur before TMR setting, in which case the vioapic_update_EOI won't be called, and further prevent all the subsequent interrupt injecting. Reorder setting the TMR and IRR will solve the problem. Besides, KVM has fixed a similar bug in: http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results


Signed-off-by: Yongan Liu<Liuyongan@huawei.com>

diff -r cfe28865e513 xen-4.1.2/xen/arch/x86/hvm/vlapic.c
--- a/xen-4.1.2/xen/arch/x86/hvm/vlapic.c       Wed Jan 04 18:50:58 2012 +0800
+++ b/xen-4.1.2/xen/arch/x86/hvm/vlapic.c       Wed Jan 04 18:53:50 2012 +0800
@@ -144,10 +144,11 @@
 {
     int ret;
 
-    ret = !vlapic_test_and_set_irr(vec, vlapic);
     if ( trig )
         vlapic_set_vector(vec, &vlapic->regs->data[APIC_TMR]);
 
+    ret = !vlapic_test_and_set_irr(vec, vlapic);
+
     /* We may need to wake up target vcpu, besides set pending bit here */
     return ret;
 }

--Boundary_(ID_LFvGxF9VChClVuj8JJlpyA)
Content-type: application/octet-stream; name=irr.patch
Content-transfer-encoding: base64
Content-disposition: attachment; filename=irr.patch; size=525;
 creation-date="Wed, 04 Jan 2012 10:56:08 GMT";
 modification-date="Wed, 04 Jan 2012 10:54:08 GMT"
Content-description: irr.patch

ZGlmZiAtciBjZmUyODg2NWU1MTMgeGVuLTQuMS4yL3hlbi9hcmNoL3g4Ni9odm0vdmxhcGljLmMK
LS0tIGEveGVuLTQuMS4yL3hlbi9hcmNoL3g4Ni9odm0vdmxhcGljLmMJV2VkIEphbiAwNCAxODo1
MDo1OCAyMDEyICswODAwCisrKyBiL3hlbi00LjEuMi94ZW4vYXJjaC94ODYvaHZtL3ZsYXBpYy5j
CVdlZCBKYW4gMDQgMTg6NTQ6MDggMjAxMiArMDgwMApAQCAtMTQ0LDEwICsxNDQsMTEgQEAKIHsK
ICAgICBpbnQgcmV0OwogCi0gICAgcmV0ID0gIXZsYXBpY190ZXN0X2FuZF9zZXRfaXJyKHZlYywg
dmxhcGljKTsKICAgICBpZiAoIHRyaWcgKQogICAgICAgICB2bGFwaWNfc2V0X3ZlY3Rvcih2ZWMs
ICZ2bGFwaWMtPnJlZ3MtPmRhdGFbQVBJQ19UTVJdKTsKIAorICAgIHJldCA9ICF2bGFwaWNfdGVz
dF9hbmRfc2V0X2lycih2ZWMsIHZsYXBpYyk7CisKICAgICAvKiBXZSBtYXkgbmVlZCB0byB3YWtl
IHVwIHRhcmdldCB2Y3B1LCBiZXNpZGVzIHNldCBwZW5kaW5nIGJpdCBoZXJlICovCiAgICAgcmV0
dXJuIHJldDsKIH0K

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

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

--Boundary_(ID_LFvGxF9VChClVuj8JJlpyA)--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 06:23:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 06:23:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RigjR-0007zK-MM; Thu, 05 Jan 2012 06:23:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RigjQ-0007zF-JQ
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 06:23:20 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325744592!9634503!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTExNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23244 invoked from network); 5 Jan 2012 06:23:13 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-11.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 06:23:13 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB00GLSB08TG@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:21:44 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXB003LGAZUW5@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:21:44 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGC79826; Thu,
	05 Jan 2012 14:21:44 +0800
Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159)
	by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 05 Jan 2012 14:21:43 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml420-hub.china.huawei.com ([10.82.67.159])
	with mapi id 14.01.0323.003; Thu, 05 Jan 2012 14:21:23 +0800
Date: Thu, 05 Jan 2012 06:21:23 +0000
From: Liuyongan <liuyongan@huawei.com>
X-Originating-IP: [10.166.82.189]
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"keir@xen.org" <keir@xen.org>, Liuyongan <liuyongan@huawei.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E414@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_LFvGxF9VChClVuj8JJlpyA)"
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel][PATCH]  x86/IRQ: IRR and TMR race condition bug fix
Thread-index: AczLcj6f7qsLv0ewTO+Kx6/jVG4/kA==
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
Cc: Qianhuibin <qianhuibin@huawei.com>
Subject: [Xen-devel] [PATCH]  x86/IRQ: IRR and TMR race condition bug 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


--Boundary_(ID_LFvGxF9VChClVuj8JJlpyA)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT

In vlapic_set_irq, we set the IRR register before the TMR. And the IRR might be serviced before setting TMR, and even worse EOI might occur before TMR setting, in which case the vioapic_update_EOI won't be called, and further prevent all the subsequent interrupt injecting. Reorder setting the TMR and IRR will solve the problem. Besides, KVM has fixed a similar bug in: http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results


Signed-off-by: Yongan Liu<Liuyongan@huawei.com>

diff -r cfe28865e513 xen-4.1.2/xen/arch/x86/hvm/vlapic.c
--- a/xen-4.1.2/xen/arch/x86/hvm/vlapic.c       Wed Jan 04 18:50:58 2012 +0800
+++ b/xen-4.1.2/xen/arch/x86/hvm/vlapic.c       Wed Jan 04 18:53:50 2012 +0800
@@ -144,10 +144,11 @@
 {
     int ret;
 
-    ret = !vlapic_test_and_set_irr(vec, vlapic);
     if ( trig )
         vlapic_set_vector(vec, &vlapic->regs->data[APIC_TMR]);
 
+    ret = !vlapic_test_and_set_irr(vec, vlapic);
+
     /* We may need to wake up target vcpu, besides set pending bit here */
     return ret;
 }

--Boundary_(ID_LFvGxF9VChClVuj8JJlpyA)
Content-type: application/octet-stream; name=irr.patch
Content-transfer-encoding: base64
Content-disposition: attachment; filename=irr.patch; size=525;
 creation-date="Wed, 04 Jan 2012 10:56:08 GMT";
 modification-date="Wed, 04 Jan 2012 10:54:08 GMT"
Content-description: irr.patch

ZGlmZiAtciBjZmUyODg2NWU1MTMgeGVuLTQuMS4yL3hlbi9hcmNoL3g4Ni9odm0vdmxhcGljLmMK
LS0tIGEveGVuLTQuMS4yL3hlbi9hcmNoL3g4Ni9odm0vdmxhcGljLmMJV2VkIEphbiAwNCAxODo1
MDo1OCAyMDEyICswODAwCisrKyBiL3hlbi00LjEuMi94ZW4vYXJjaC94ODYvaHZtL3ZsYXBpYy5j
CVdlZCBKYW4gMDQgMTg6NTQ6MDggMjAxMiArMDgwMApAQCAtMTQ0LDEwICsxNDQsMTEgQEAKIHsK
ICAgICBpbnQgcmV0OwogCi0gICAgcmV0ID0gIXZsYXBpY190ZXN0X2FuZF9zZXRfaXJyKHZlYywg
dmxhcGljKTsKICAgICBpZiAoIHRyaWcgKQogICAgICAgICB2bGFwaWNfc2V0X3ZlY3Rvcih2ZWMs
ICZ2bGFwaWMtPnJlZ3MtPmRhdGFbQVBJQ19UTVJdKTsKIAorICAgIHJldCA9ICF2bGFwaWNfdGVz
dF9hbmRfc2V0X2lycih2ZWMsIHZsYXBpYyk7CisKICAgICAvKiBXZSBtYXkgbmVlZCB0byB3YWtl
IHVwIHRhcmdldCB2Y3B1LCBiZXNpZGVzIHNldCBwZW5kaW5nIGJpdCBoZXJlICovCiAgICAgcmV0
dXJuIHJldDsKIH0K

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

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

--Boundary_(ID_LFvGxF9VChClVuj8JJlpyA)--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 07:28:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 07:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RihjU-0008SS-0u; Thu, 05 Jan 2012 07:27:28 +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 1RihjR-0008SN-Rc
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 07:27:26 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325748438!9831556!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTYyNzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15245 invoked from network); 5 Jan 2012 07:27:19 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 07:27:19 -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 CDE0C22F1;
	Thu,  5 Jan 2012 09:27:16 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 89BCA20056; Thu,  5 Jan 2012 09:27:16 +0200 (EET)
Date: Thu, 5 Jan 2012 09:27:16 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120105072716.GU12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F04AF28.8040102@amd.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> On 01/04/2012 01:43 PM, Pasi K=E4rkk=E4inen wrote:
>> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there =
any
>>>>> must haves e.g. in the paging/sharing spaces?
>>>>>
>>>> - What's the status of Nested Hardware Virtualization?
>>>> I remember some email saying Intel vmx-on-vmx has some performance iss=
ues,
>>>> and amd svm-on-svm works better..
>>>>
>>>>
>>>> - Also there's a bunch of VGA passthru related patches,
>>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>>> but I still haven't had time for that :(
>>> Since there were quite a lot of interest on this subject, should we
>>> document it in a separate wiki for working combinations (like
>>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>>
>> I actually once started writing down that kind of stuff:
>> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>>
>> Feel free to contribute :)
>>
>> There's also:
>> http://wiki.xen.org/xenwiki/XenVGAPassthrough
> Thanks for sharing. I will contribute my findings as needed. BTW, do you  =

> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a  =

> dilemma for several reasons:  it doesn't always work; sometimes it can  =

> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst  =

> driver seems very stable even without these patches. But Wei Wang told  =

> me that he needs them for some of his cards.
>

Yes, please send the patch!

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 07:28:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 07:28:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RihjU-0008SS-0u; Thu, 05 Jan 2012 07:27:28 +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 1RihjR-0008SN-Rc
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 07:27:26 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325748438!9831556!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTYyNzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15245 invoked from network); 5 Jan 2012 07:27:19 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 07:27:19 -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 CDE0C22F1;
	Thu,  5 Jan 2012 09:27:16 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 89BCA20056; Thu,  5 Jan 2012 09:27:16 +0200 (EET)
Date: Thu, 5 Jan 2012 09:27:16 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120105072716.GU12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F04AF28.8040102@amd.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> On 01/04/2012 01:43 PM, Pasi K=E4rkk=E4inen wrote:
>> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there =
any
>>>>> must haves e.g. in the paging/sharing spaces?
>>>>>
>>>> - What's the status of Nested Hardware Virtualization?
>>>> I remember some email saying Intel vmx-on-vmx has some performance iss=
ues,
>>>> and amd svm-on-svm works better..
>>>>
>>>>
>>>> - Also there's a bunch of VGA passthru related patches,
>>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>>> but I still haven't had time for that :(
>>> Since there were quite a lot of interest on this subject, should we
>>> document it in a separate wiki for working combinations (like
>>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>>
>> I actually once started writing down that kind of stuff:
>> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>>
>> Feel free to contribute :)
>>
>> There's also:
>> http://wiki.xen.org/xenwiki/XenVGAPassthrough
> Thanks for sharing. I will contribute my findings as needed. BTW, do you  =

> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a  =

> dilemma for several reasons:  it doesn't always work; sometimes it can  =

> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst  =

> driver seems very stable even without these patches. But Wei Wang told  =

> me that he needs them for some of his cards.
>

Yes, please send the patch!

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 07:58:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 07:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiCr-0000EM-Jc; Thu, 05 Jan 2012 07:57:49 +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 1RiiCq-0000EE-O7
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 07:57:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325750262!9732767!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 28483 invoked from network); 5 Jan 2012 07:57:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jan 2012 07:57:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Jan 2012 07:57:42 +0000
Message-Id: <4F05663C020000780006A899@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Jan 2012 07:58:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liu.yi" <liu.yi24@zte.com.cn>
References: <1325300125668-5111504.post@n5.nabble.com>
	<1325730985766-5121613.post@n5.nabble.com>
In-Reply-To: <1325730985766-5121613.post@n5.nabble.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [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

>>> On 05.01.12 at 03:36, "Liu.yi" <liu.yi24@zte.com.cn> wrote:
> Atomic operations using LOCK prefix (like set_bit and clear_bit) will block
> all the physical cpus which excute memory access.

... to that same cache line.

> Does this fact implies
> that spin locks are more efficient when their's granularity is small?

No - after all, acquiring a spin lock unavoidably implies using a LOCKed
instruction.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 07:58:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 07:58:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiCr-0000EM-Jc; Thu, 05 Jan 2012 07:57:49 +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 1RiiCq-0000EE-O7
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 07:57:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325750262!9732767!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 28483 invoked from network); 5 Jan 2012 07:57:42 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jan 2012 07:57:42 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Jan 2012 07:57:42 +0000
Message-Id: <4F05663C020000780006A899@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Jan 2012 07:58:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Liu.yi" <liu.yi24@zte.com.cn>
References: <1325300125668-5111504.post@n5.nabble.com>
	<1325730985766-5121613.post@n5.nabble.com>
In-Reply-To: <1325730985766-5121613.post@n5.nabble.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [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

>>> On 05.01.12 at 03:36, "Liu.yi" <liu.yi24@zte.com.cn> wrote:
> Atomic operations using LOCK prefix (like set_bit and clear_bit) will block
> all the physical cpus which excute memory access.

... to that same cache line.

> Does this fact implies
> that spin locks are more efficient when their's granularity is small?

No - after all, acquiring a spin lock unavoidably implies using a LOCKed
instruction.

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:01:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiFX-0000mV-0i; Thu, 05 Jan 2012 08:00:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RiiFV-0000m1-K4
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:00:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1325750427!9785779!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 10666 invoked from network); 5 Jan 2012 08:00:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jan 2012 08:00:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Jan 2012 08:00:26 +0000
Message-Id: <4F0566E2020000780006A89C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Jan 2012 08:01:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
In-Reply-To: <20120104233524.GA31620@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Allen M Kay <allen.m.kay@intel.com>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
 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 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
>> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> with the latest upstream Linux kernel.
> 
> 
> That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> 2.6.18 kernel in blkback if you are using that version.

Which one are you referring to?

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:01:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiFX-0000mV-0i; Thu, 05 Jan 2012 08:00:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RiiFV-0000m1-K4
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:00:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1325750427!9785779!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 10666 invoked from network); 5 Jan 2012 08:00:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jan 2012 08:00:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Jan 2012 08:00:26 +0000
Message-Id: <4F0566E2020000780006A89C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Jan 2012 08:01:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
In-Reply-To: <20120104233524.GA31620@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Allen M Kay <allen.m.kay@intel.com>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
 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 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
>> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> with the latest upstream Linux kernel.
> 
> 
> That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> 2.6.18 kernel in blkback if you are using that version.

Which one are you referring to?

Jan


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:02:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiHI-0000s9-HQ; Thu, 05 Jan 2012 08:02:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiiHH-0000rm-KJ
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:02:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325750537!7191563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19769 invoked from network); 5 Jan 2012 08:02:17 -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;
	5 Jan 2012 08:02:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,460,1320624000"; 
   d="scan'208";a="9826774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 08:02: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; Thu, 5 Jan 2012
	08:02:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Kay, Allen M" <allen.m.kay@intel.com>
In-Reply-To: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
Organization: Citrix Systems, Inc.
Date: Thu, 5 Jan 2012 08:02:15 +0000
Message-ID: <1325750535.29084.1.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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 Wed, 2012-01-04 at 21:57 +0000, Kay, Allen M wrote:
> Attached patch fix build error in latest xen-unstable.hg.

What is the specific build error?

What version of yajl do you have and on which distro?

Ian.

> 
>  
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> 
>  
> 
> 



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:02:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiHI-0000s9-HQ; Thu, 05 Jan 2012 08:02:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiiHH-0000rm-KJ
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:02:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325750537!7191563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19769 invoked from network); 5 Jan 2012 08:02:17 -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;
	5 Jan 2012 08:02:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,460,1320624000"; 
   d="scan'208";a="9826774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 08:02: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; Thu, 5 Jan 2012
	08:02:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Kay, Allen M" <allen.m.kay@intel.com>
In-Reply-To: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
Organization: Citrix Systems, Inc.
Date: Thu, 5 Jan 2012 08:02:15 +0000
Message-ID: <1325750535.29084.1.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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 Wed, 2012-01-04 at 21:57 +0000, Kay, Allen M wrote:
> Attached patch fix build error in latest xen-unstable.hg.

What is the specific build error?

What version of yajl do you have and on which distro?

Ian.

> 
>  
> 
> Signed-off-by: Allen Kay <allen.m.kay@intel.com>
> 
>  
> 
> 



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:06:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiKN-00013u-4r; Thu, 05 Jan 2012 08:05: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 1RiiKL-00013W-HP
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:05:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325750727!9720309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8205 invoked from network); 5 Jan 2012 08:05: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;
	5 Jan 2012 08:05:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,460,1320624000"; 
   d="scan'208";a="9826824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 08:05:27 +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, 5 Jan 2012
	08:05:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120104233524.GA31620@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
Date: Thu, 5 Jan 2012 08:05:26 +0000
Message-ID: <1325750726.29084.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	David Vrabel <david.vrabel@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
	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 Wed, 2012-01-04 at 23:35 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> > I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> > 
> > 
> > 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.
> 
> Huh. You are right. Hadn't noticed that before since I was using dom0_mem.
> 
> Ian, David: any ideas?

Nope. It would be nice to see some logs (xen+dom0 and native) though.

Ian.

>  I get the same problem and it looks as
> if the area above 4GB ends up being reserved.
> 
> > 
> > 
> > 
> > 2)      Xen-unstable:  I get ext4 file system corruption when booting xen with the latest upstream Linux kernel.
> 
> 
> That I hadn't seen. Is this with dom0 or domU? There is one bug in the 2.6.18 kernel
> in blkback if you are using that version.
> 
> > 
> > Has anyone seen these two problems?
> > 
> > Allen



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:06:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:06:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiKN-00013u-4r; Thu, 05 Jan 2012 08:05: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 1RiiKL-00013W-HP
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:05:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325750727!9720309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8205 invoked from network); 5 Jan 2012 08:05: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;
	5 Jan 2012 08:05:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,460,1320624000"; 
   d="scan'208";a="9826824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 08:05:27 +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, 5 Jan 2012
	08:05:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120104233524.GA31620@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
Date: Thu, 5 Jan 2012 08:05:26 +0000
Message-ID: <1325750726.29084.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	David Vrabel <david.vrabel@citrix.com>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
	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 Wed, 2012-01-04 at 23:35 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> > I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> > 
> > 
> > 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.
> 
> Huh. You are right. Hadn't noticed that before since I was using dom0_mem.
> 
> Ian, David: any ideas?

Nope. It would be nice to see some logs (xen+dom0 and native) though.

Ian.

>  I get the same problem and it looks as
> if the area above 4GB ends up being reserved.
> 
> > 
> > 
> > 
> > 2)      Xen-unstable:  I get ext4 file system corruption when booting xen with the latest upstream Linux kernel.
> 
> 
> That I hadn't seen. Is this with dom0 or domU? There is one bug in the 2.6.18 kernel
> in blkback if you are using that version.
> 
> > 
> > Has anyone seen these two problems?
> > 
> > Allen



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:44:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:44:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiivX-0001Qq-Be; Thu, 05 Jan 2012 08:43:59 +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 1RiivV-0001Qk-Tf
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:43:58 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-12.tower-182.messagelabs.com!1325753030!9673566!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 6708 invoked from network); 5 Jan 2012 08:43:52 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Jan 2012 08:43:52 -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 1RiivO-0006tG-2r
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:43:50 -0800
Date: Thu, 5 Jan 2012 00:43:50 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1325753030081-5122127.post@n5.nabble.com>
In-Reply-To: <4F05663C020000780006A899@nat28.tlf.novell.com>
References: <1325300125668-5111504.post@n5.nabble.com>
	<1325730985766-5121613.post@n5.nabble.com>
	<4F05663C020000780006A899@nat28.tlf.novell.com>
MIME-Version: 1.0
Subject: Re: [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

Understood, thanks.

--
View this message in context: http://xen.1045712.n5.nabble.com/credit-scheduler-svc-flags-access-race-tp5111504p5122127.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 Jan 05 08:44:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:44:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiivX-0001Qq-Be; Thu, 05 Jan 2012 08:43:59 +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 1RiivV-0001Qk-Tf
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:43:58 +0000
X-Env-Sender: liu.yi24@zte.com.cn
X-Msg-Ref: server-12.tower-182.messagelabs.com!1325753030!9673566!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 6708 invoked from network); 5 Jan 2012 08:43:52 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Jan 2012 08:43:52 -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 1RiivO-0006tG-2r
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 00:43:50 -0800
Date: Thu, 5 Jan 2012 00:43:50 -0800 (PST)
From: "Liu.yi" <liu.yi24@zte.com.cn>
To: xen-devel@lists.xensource.com
Message-ID: <1325753030081-5122127.post@n5.nabble.com>
In-Reply-To: <4F05663C020000780006A899@nat28.tlf.novell.com>
References: <1325300125668-5111504.post@n5.nabble.com>
	<1325730985766-5121613.post@n5.nabble.com>
	<4F05663C020000780006A899@nat28.tlf.novell.com>
MIME-Version: 1.0
Subject: Re: [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

Understood, thanks.

--
View this message in context: http://xen.1045712.n5.nabble.com/credit-scheduler-svc-flags-access-race-tp5111504p5122127.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 Jan 05 08:45:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiwR-0001Ua-Sb; Thu, 05 Jan 2012 08:44: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 1RiiwQ-0001UB-Cr
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:44:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325753088!10213579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8732 invoked from network); 5 Jan 2012 08:44:48 -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;
	5 Jan 2012 08:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9827324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 08:44: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, 5 Jan 2012
	08:44:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 5 Jan 2012 08:44:46 +0000
In-Reply-To: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
References: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325753087.25206.336.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] xen-netback: make ops structs const
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 21:56 +0000, Stephen Hemminger wrote:
> All tables of function pointers should be const to make hacks
> more difficult. Compile tested only.

I also eyeballed for any writes to these structs and couldn't find one.

> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

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

> 
> ---
> Patch against net-next
> 
> --- a/drivers/net/xen-netback/interface.c	2011-12-07 10:54:19.232282492 -0800
> +++ b/drivers/net/xen-netback/interface.c	2012-01-04 13:16:04.414052721 -0800
> @@ -223,7 +223,7 @@ static void xenvif_get_strings(struct ne
>  	}
>  }
>  
> -static struct ethtool_ops xenvif_ethtool_ops = {
> +static const struct ethtool_ops xenvif_ethtool_ops = {
>  	.get_link	= ethtool_op_get_link,
>  
>  	.get_sset_count = xenvif_get_sset_count,
> @@ -231,7 +231,7 @@ static struct ethtool_ops xenvif_ethtool
>  	.get_strings = xenvif_get_strings,
>  };
>  
> -static struct net_device_ops xenvif_netdev_ops = {
> +static const struct net_device_ops xenvif_netdev_ops = {
>  	.ndo_start_xmit	= xenvif_start_xmit,
>  	.ndo_get_stats	= xenvif_get_stats,
>  	.ndo_open	= xenvif_open,



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:45:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:45:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiiwR-0001Ua-Sb; Thu, 05 Jan 2012 08:44: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 1RiiwQ-0001UB-Cr
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:44:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325753088!10213579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8732 invoked from network); 5 Jan 2012 08:44:48 -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;
	5 Jan 2012 08:44:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9827324"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 08:44: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, 5 Jan 2012
	08:44:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 5 Jan 2012 08:44:46 +0000
In-Reply-To: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
References: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325753087.25206.336.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] xen-netback: make ops structs const
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 21:56 +0000, Stephen Hemminger wrote:
> All tables of function pointers should be const to make hacks
> more difficult. Compile tested only.

I also eyeballed for any writes to these structs and couldn't find one.

> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

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

> 
> ---
> Patch against net-next
> 
> --- a/drivers/net/xen-netback/interface.c	2011-12-07 10:54:19.232282492 -0800
> +++ b/drivers/net/xen-netback/interface.c	2012-01-04 13:16:04.414052721 -0800
> @@ -223,7 +223,7 @@ static void xenvif_get_strings(struct ne
>  	}
>  }
>  
> -static struct ethtool_ops xenvif_ethtool_ops = {
> +static const struct ethtool_ops xenvif_ethtool_ops = {
>  	.get_link	= ethtool_op_get_link,
>  
>  	.get_sset_count = xenvif_get_sset_count,
> @@ -231,7 +231,7 @@ static struct ethtool_ops xenvif_ethtool
>  	.get_strings = xenvif_get_strings,
>  };
>  
> -static struct net_device_ops xenvif_netdev_ops = {
> +static const struct net_device_ops xenvif_netdev_ops = {
>  	.ndo_start_xmit	= xenvif_start_xmit,
>  	.ndo_get_stats	= xenvif_get_stats,
>  	.ndo_open	= xenvif_open,



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:48:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riizf-0001g7-GB; Thu, 05 Jan 2012 08:48:15 +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 1Riize-0001fm-B1
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:48:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325753288!9655722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3537 invoked from network); 5 Jan 2012 08:48:08 -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 Jan 2012 08:48:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9827384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 08:48: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, 5 Jan 2012
	08:48:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 5 Jan 2012 08:48:07 +0000
In-Reply-To: <4F049A46.5080104@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>
	<20111215205654.GA11829@andromeda.dapyr.net>	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
	<1325696094.25206.321.camel@zakaz.uk.xensource.com>
	<4F049A46.5080104@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325753287.25206.339.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>,
	"Keir \(Xen.org\)" <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 Wed, 2012-01-04 at 18:28 +0000, Daniel De Graaf wrote:
> On 01/04/2012 11:54 AM, Ian Campbell wrote:
> > On Wed, 2012-01-04 at 16:49 +0000, Stefano Stabellini wrote:
> >> On Wed, 4 Jan 2012, Daniel De Graaf wrote:
> >>> The example policy doesn't really belong in docs because it needs to be
> >>> compiled to be usable, and this depends on a number of other files (all
> >>> files under tools/flask/policy/policy, to be exact). Compiling and
> >>> installing FLASK policy during the normal build process (conditional on
> >>> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
> >>> would be the best solution. The policy must be installed to /boot, not
> >>> /etc/xen, because the initial policy load happens prior to starting dom0.
> >>
> >> Like Ian said, I meant having the policy somewhere online where can be
> >> linked. However we only publish on xenbits what we have under docs ATM.
> >> It is unfortunate that the policy needs FLASK_ENABLE to be compiled
> >> because I am pretty sure that the automated build system that produces
> >> the docs that end up online does not support that option right now.
> > 
> > Publishing the docs in this manner wouldn't require FLASK_ENABLE since
> > it doesn't need any tools, just "cp". Unless I've totally got the wrong
> > end of the stick and the policy needs processing before you can even
> > usefully read it?
> > 
> > Ian.
> > 
> 
> You can read the policy files as-is; the xen.te and xen.if files contain
> most of what you would want to inspect. However, this is similar to reading
> shell scripts or other source files, which is not what I would expect from
> files copied into a docs folder.

In that case I think the best approach would be to reference the file
via the mercurial webterface e.g.
http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/tools/flask/policy/policy/modules/xen/xen.te

> There are some tools for searching and understanding SELinux policy such as
> sesearch that work either on the binary policy file or on the macro-expanded
> policy.conf. Building policy.conf only requires m4, which is already required
> for bison as part of Xen's build process. This file is much less readable by
> humans, however, since it is the output of macro expansion.

Doesn't sound like something that it would be useful to publish, but
does sound very useful if you've actually got the flask tools installed
etc.

> Also: the policy currently isn't built automatically even if FLASK_ENABLE=y;
> this is something that I think should be changed although I will wait to post
> a patch until we've decided what parts of the output should be used.

It sounds like we don't need to use any parts but in any case we may as
well arrange for it to be built and worry about any docs usage of it
later.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 08:48:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 08:48:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riizf-0001g7-GB; Thu, 05 Jan 2012 08:48:15 +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 1Riize-0001fm-B1
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 08:48:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325753288!9655722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3537 invoked from network); 5 Jan 2012 08:48:08 -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 Jan 2012 08:48:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9827384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 08:48: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, 5 Jan 2012
	08:48:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 5 Jan 2012 08:48:07 +0000
In-Reply-To: <4F049A46.5080104@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>
	<20111215205654.GA11829@andromeda.dapyr.net>	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
	<1325696094.25206.321.camel@zakaz.uk.xensource.com>
	<4F049A46.5080104@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325753287.25206.339.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>,
	"Keir \(Xen.org\)" <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 Wed, 2012-01-04 at 18:28 +0000, Daniel De Graaf wrote:
> On 01/04/2012 11:54 AM, Ian Campbell wrote:
> > On Wed, 2012-01-04 at 16:49 +0000, Stefano Stabellini wrote:
> >> On Wed, 4 Jan 2012, Daniel De Graaf wrote:
> >>> The example policy doesn't really belong in docs because it needs to be
> >>> compiled to be usable, and this depends on a number of other files (all
> >>> files under tools/flask/policy/policy, to be exact). Compiling and
> >>> installing FLASK policy during the normal build process (conditional on
> >>> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
> >>> would be the best solution. The policy must be installed to /boot, not
> >>> /etc/xen, because the initial policy load happens prior to starting dom0.
> >>
> >> Like Ian said, I meant having the policy somewhere online where can be
> >> linked. However we only publish on xenbits what we have under docs ATM.
> >> It is unfortunate that the policy needs FLASK_ENABLE to be compiled
> >> because I am pretty sure that the automated build system that produces
> >> the docs that end up online does not support that option right now.
> > 
> > Publishing the docs in this manner wouldn't require FLASK_ENABLE since
> > it doesn't need any tools, just "cp". Unless I've totally got the wrong
> > end of the stick and the policy needs processing before you can even
> > usefully read it?
> > 
> > Ian.
> > 
> 
> You can read the policy files as-is; the xen.te and xen.if files contain
> most of what you would want to inspect. However, this is similar to reading
> shell scripts or other source files, which is not what I would expect from
> files copied into a docs folder.

In that case I think the best approach would be to reference the file
via the mercurial webterface e.g.
http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/tools/flask/policy/policy/modules/xen/xen.te

> There are some tools for searching and understanding SELinux policy such as
> sesearch that work either on the binary policy file or on the macro-expanded
> policy.conf. Building policy.conf only requires m4, which is already required
> for bison as part of Xen's build process. This file is much less readable by
> humans, however, since it is the output of macro expansion.

Doesn't sound like something that it would be useful to publish, but
does sound very useful if you've actually got the flask tools installed
etc.

> Also: the policy currently isn't built automatically even if FLASK_ENABLE=y;
> this is something that I think should be changed although I will wait to post
> a patch until we've decided what parts of the output should be used.

It sounds like we don't need to use any parts but in any case we may as
well arrange for it to be built and worry about any docs usage of it
later.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 09:05:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 09:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RijGN-00021G-7j; Thu, 05 Jan 2012 09:05: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 1RijGL-00021B-Q4
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 09:05:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325754322!7837589!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 21145 invoked from network); 5 Jan 2012 09:05:22 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jan 2012 09:05:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RijG8-000MU4-PI; Thu, 05 Jan 2012 09:05:16 +0000
Date: Thu, 5 Jan 2012 09:05:16 +0000
From: Tim Deegan <tim@xen.org>
To: hongkaixing@huawei.com
Message-ID: <20120105090516.GE15595@ocelot.phlegethon.org>
References: <patchbomb.1325735428@h00166998.china.huawei.com>
	<978daceef147273920f2.1325735430@h00166998.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <978daceef147273920f2.1325735430@h00166998.china.huawei.com>
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 2] xenpaging:change page-in process to
	speed up page-in in	xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello, 

At 03:50 +0000 on 05 Jan (1325735430), hongkaixing@huawei.com wrote:
> xenpaging:change page-in process to speed up page-in in xenpaging
> In this patch,we change the page-in process.Firstly,we add a new function paging_in_trigger_sync
> to handle page-in requests directly.and when the requests' count is up to 32,then handle them
> batchly;Most importantly,we use an increasing gfn to test_bit,which saves much time.
> In p2m.c,we changes p2m_mem_paging_populate() to return a value;
> The following is a xenpaging test on suse11-64 with 4G memory.
> 
> Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
> 512M(131072)		    2.6s		        540s		              4.7s
> 2G(524288)		    15.5s		        2088s		      	      17.7s
> 

Thanks for the patch!  That's an impressive difference.  You're changing
quite a few things in this patch, though.  Can you send them as separate
patches so they can be reviewed one at a time?  Is one of them in
particular making the difference?  I suspect it's mostly the change to
test_bit(), and the rest is not necessary. 

Cheers,

Tim.

> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
> 
> diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
> +++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
> @@ -73,6 +73,13 @@
>                                  NULL, NULL, gfn);
>  }
>  
> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned long gfn)
> +{
> +    return xc_mem_event_control(xch, domain_id,
> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING, 
> +                                NULL, NULL, gfn);
> +}
>  
>  /*
>   * Local variables:
> diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
> +++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
> @@ -1841,6 +1841,7 @@
>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
>  int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
>                           unsigned long gfn);
> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned long gfn); 
>  
>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>                          void *shared_page, void *ring_page);
> diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
> +++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
> @@ -594,6 +594,13 @@
>      return ret;
>  }
>  
> +static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long gfn)
> +{
> +    int rc = 0;
> +    rc = xc_mem_paging_in(paging->xc_handle, paging->mem_event.domain_id,gfn);
> +    return rc;
> +}

This function is 

> +
>  int main(int argc, char *argv[])
>  {
>      struct sigaction act;
> @@ -605,6 +612,9 @@
>      int i;
>      int rc = -1;
>      int rc1;
> +    int request_count = 0;
> +    unsigned long page_in_start_gfn = 0;
> +    unsigned long real_page = 0;
>      xc_interface *xch;
>  
>      int open_flags = O_CREAT | O_TRUNC | O_RDWR;
> @@ -773,24 +783,51 @@
>          /* Write all pages back into the guest */
>          if ( interrupted == SIGTERM || interrupted == SIGINT )
>          {
> -            int num = 0;
> +            request_count = 0;
>              for ( i = 0; i < paging->domain_info->max_pages; i++ )
>              {
> -                if ( test_bit(i, paging->bitmap) )
> +                real_page = i + page_in_start_gfn;
> +                real_page %= paging->domain_info->max_pages;
> +                if ( test_bit(real_page, paging->bitmap) )
>                  {
> -                    paging->pagein_queue[num] = i;
> -                    num++;
> -                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
> -                        break;
> +                    rc = paging_in_trigger_sync(paging,real_page);
> +                    if ( 0 == rc )
> +                    {
> +                        request_count++;
> +                        /* If page_in requests up to 32 then handle them */
> +                        if( request_count >= 32 )
> +                        {
> +                            page_in_start_gfn=real_page + 1;
> +                            break;
> +                        }
> +                    }
> +                    else
> +                    {
> +                        /* If IO ring is full then handle requests to free space */
> +                        if( ENOSPC == errno )
> +                        {
> +                            page_in_start_gfn = real_page;
> +                            break;
> +                        }
> +                        /* If p2mt is not p2m_is_paging,then clear bitmap;
> +                        * e.g. a page is paged then it is dropped by balloon.
> +                        */
> +                        else if ( EINVAL == errno )
> +                        {
> +                            clear_bit(i,paging->bitmap);
> +                            policy_notify_paged_in(i);
> +                        }
> +                        /* If hypercall fails then go to teardown xenpaging */
> +                        else 
> +                        {
> +                            ERROR("Error paging in page");
> +                            goto out;
> +                        }
> +                    }
>                  }
>              }
> -            /*
> -             * One more round if there are still pages to process.
> -             * If no more pages to process, exit loop.
> -             */
> -            if ( num )
> -                page_in_trigger();
> -            else if ( i == paging->domain_info->max_pages )
> +            if( (i==paging->domain_info->max_pages) && 
> +                !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
>                  break;
>          }
>          else
> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
> --- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
> +++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
> @@ -57,7 +57,14 @@
>          return 0;
>      }
>      break;
> -
> +    
> +    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
> +    {
> +        unsigned long gfn = mec->gfn;
> +        return p2m_mem_paging_populate(d, gfn);
> +    }
> +    break;
> +    
>      default:
>          return -ENOSYS;
>          break;
> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
> @@ -874,7 +874,7 @@
>   * already sent to the pager. In this case the caller has to try again until the
>   * gfn is fully paged in again.
>   */
> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>  {
>      struct vcpu *v = current;
>      mem_event_request_t req;
> @@ -882,10 +882,12 @@
>      p2m_access_t a;
>      mfn_t mfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int ret;
>  
>      /* Check that there's space on the ring for this request */
> +    ret = -ENOSPC;
>      if ( mem_event_check_ring(d, &d->mem_paging) )
> -        return;
> +        goto out;
>  
>      memset(&req, 0, sizeof(req));
>      req.type = MEM_EVENT_TYPE_PAGING;
> @@ -905,19 +907,27 @@
>      }
>      p2m_unlock(p2m);
>  
> +    ret = -EINVAL;
>      /* Pause domain if request came from guest and gfn has paging type */
> -    if (  p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
> +    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
>      {
>          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 )
> +    else if ( p2mt == p2m_ram_paging_in_start || p2mt == p2m_ram_paging_in )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
>          mem_event_put_req_producers(&d->mem_paging);
> -        return;
> +        return 0;
>      }
> +    else if ( !p2m_is_paging(p2mt) )
> +    {
> +        /* please clear the bit in paging->bitmap; */
> +        mem_event_put_req_producers(&d->mem_paging);
> +        goto out;
> +    }
> +
>  
>      /* Send request to pager */
>      req.gfn = gfn;
> @@ -925,8 +935,13 @@
>      req.vcpu_id = v->vcpu_id;
>  
>      mem_event_put_request(d, &d->mem_paging, &req);
> +    
> +    ret = 0;
> + out:
> +    return ret;   
>  }
>  
> +
>  /**
>   * p2m_mem_paging_prep - Allocate a new page for the guest
>   * @d: guest domain
> diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
> +++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
> @@ -485,7 +485,7 @@
>  /* Tell xenpaging to drop a paged out frame */
>  void 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);
> +int 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);
>  /* Resume normal operation (in case a domain was paused) */
> diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
> +++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
> @@ -721,6 +721,7 @@
>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
> +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
>  
>  /*
>   * Access permissions.
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 05 09:05:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 09:05:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RijGN-00021G-7j; Thu, 05 Jan 2012 09:05: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 1RijGL-00021B-Q4
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 09:05:30 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325754322!7837589!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 21145 invoked from network); 5 Jan 2012 09:05:22 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jan 2012 09:05:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RijG8-000MU4-PI; Thu, 05 Jan 2012 09:05:16 +0000
Date: Thu, 5 Jan 2012 09:05:16 +0000
From: Tim Deegan <tim@xen.org>
To: hongkaixing@huawei.com
Message-ID: <20120105090516.GE15595@ocelot.phlegethon.org>
References: <patchbomb.1325735428@h00166998.china.huawei.com>
	<978daceef147273920f2.1325735430@h00166998.china.huawei.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <978daceef147273920f2.1325735430@h00166998.china.huawei.com>
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 2] xenpaging:change page-in process to
	speed up page-in in	xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello, 

At 03:50 +0000 on 05 Jan (1325735430), hongkaixing@huawei.com wrote:
> xenpaging:change page-in process to speed up page-in in xenpaging
> In this patch,we change the page-in process.Firstly,we add a new function paging_in_trigger_sync
> to handle page-in requests directly.and when the requests' count is up to 32,then handle them
> batchly;Most importantly,we use an increasing gfn to test_bit,which saves much time.
> In p2m.c,we changes p2m_mem_paging_populate() to return a value;
> The following is a xenpaging test on suse11-64 with 4G memory.
> 
> Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
> 512M(131072)		    2.6s		        540s		              4.7s
> 2G(524288)		    15.5s		        2088s		      	      17.7s
> 

Thanks for the patch!  That's an impressive difference.  You're changing
quite a few things in this patch, though.  Can you send them as separate
patches so they can be reviewed one at a time?  Is one of them in
particular making the difference?  I suspect it's mostly the change to
test_bit(), and the rest is not necessary. 

Cheers,

Tim.

> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
> 
> diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
> +++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
> @@ -73,6 +73,13 @@
>                                  NULL, NULL, gfn);
>  }
>  
> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned long gfn)
> +{
> +    return xc_mem_event_control(xch, domain_id,
> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING, 
> +                                NULL, NULL, gfn);
> +}
>  
>  /*
>   * Local variables:
> diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
> --- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
> +++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
> @@ -1841,6 +1841,7 @@
>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn);
>  int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
>                           unsigned long gfn);
> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned long gfn); 
>  
>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>                          void *shared_page, void *ring_page);
> diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
> --- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
> +++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
> @@ -594,6 +594,13 @@
>      return ret;
>  }
>  
> +static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long gfn)
> +{
> +    int rc = 0;
> +    rc = xc_mem_paging_in(paging->xc_handle, paging->mem_event.domain_id,gfn);
> +    return rc;
> +}

This function is 

> +
>  int main(int argc, char *argv[])
>  {
>      struct sigaction act;
> @@ -605,6 +612,9 @@
>      int i;
>      int rc = -1;
>      int rc1;
> +    int request_count = 0;
> +    unsigned long page_in_start_gfn = 0;
> +    unsigned long real_page = 0;
>      xc_interface *xch;
>  
>      int open_flags = O_CREAT | O_TRUNC | O_RDWR;
> @@ -773,24 +783,51 @@
>          /* Write all pages back into the guest */
>          if ( interrupted == SIGTERM || interrupted == SIGINT )
>          {
> -            int num = 0;
> +            request_count = 0;
>              for ( i = 0; i < paging->domain_info->max_pages; i++ )
>              {
> -                if ( test_bit(i, paging->bitmap) )
> +                real_page = i + page_in_start_gfn;
> +                real_page %= paging->domain_info->max_pages;
> +                if ( test_bit(real_page, paging->bitmap) )
>                  {
> -                    paging->pagein_queue[num] = i;
> -                    num++;
> -                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
> -                        break;
> +                    rc = paging_in_trigger_sync(paging,real_page);
> +                    if ( 0 == rc )
> +                    {
> +                        request_count++;
> +                        /* If page_in requests up to 32 then handle them */
> +                        if( request_count >= 32 )
> +                        {
> +                            page_in_start_gfn=real_page + 1;
> +                            break;
> +                        }
> +                    }
> +                    else
> +                    {
> +                        /* If IO ring is full then handle requests to free space */
> +                        if( ENOSPC == errno )
> +                        {
> +                            page_in_start_gfn = real_page;
> +                            break;
> +                        }
> +                        /* If p2mt is not p2m_is_paging,then clear bitmap;
> +                        * e.g. a page is paged then it is dropped by balloon.
> +                        */
> +                        else if ( EINVAL == errno )
> +                        {
> +                            clear_bit(i,paging->bitmap);
> +                            policy_notify_paged_in(i);
> +                        }
> +                        /* If hypercall fails then go to teardown xenpaging */
> +                        else 
> +                        {
> +                            ERROR("Error paging in page");
> +                            goto out;
> +                        }
> +                    }
>                  }
>              }
> -            /*
> -             * One more round if there are still pages to process.
> -             * If no more pages to process, exit loop.
> -             */
> -            if ( num )
> -                page_in_trigger();
> -            else if ( i == paging->domain_info->max_pages )
> +            if( (i==paging->domain_info->max_pages) && 
> +                !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
>                  break;
>          }
>          else
> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
> --- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
> +++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
> @@ -57,7 +57,14 @@
>          return 0;
>      }
>      break;
> -
> +    
> +    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
> +    {
> +        unsigned long gfn = mec->gfn;
> +        return p2m_mem_paging_populate(d, gfn);
> +    }
> +    break;
> +    
>      default:
>          return -ENOSYS;
>          break;
> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
> @@ -874,7 +874,7 @@
>   * already sent to the pager. In this case the caller has to try again until the
>   * gfn is fully paged in again.
>   */
> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>  {
>      struct vcpu *v = current;
>      mem_event_request_t req;
> @@ -882,10 +882,12 @@
>      p2m_access_t a;
>      mfn_t mfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +    int ret;
>  
>      /* Check that there's space on the ring for this request */
> +    ret = -ENOSPC;
>      if ( mem_event_check_ring(d, &d->mem_paging) )
> -        return;
> +        goto out;
>  
>      memset(&req, 0, sizeof(req));
>      req.type = MEM_EVENT_TYPE_PAGING;
> @@ -905,19 +907,27 @@
>      }
>      p2m_unlock(p2m);
>  
> +    ret = -EINVAL;
>      /* Pause domain if request came from guest and gfn has paging type */
> -    if (  p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
> +    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
>      {
>          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 )
> +    else if ( p2mt == p2m_ram_paging_in_start || p2mt == p2m_ram_paging_in )
>      {
>          /* gfn is already on its way back and vcpu is not paused */
>          mem_event_put_req_producers(&d->mem_paging);
> -        return;
> +        return 0;
>      }
> +    else if ( !p2m_is_paging(p2mt) )
> +    {
> +        /* please clear the bit in paging->bitmap; */
> +        mem_event_put_req_producers(&d->mem_paging);
> +        goto out;
> +    }
> +
>  
>      /* Send request to pager */
>      req.gfn = gfn;
> @@ -925,8 +935,13 @@
>      req.vcpu_id = v->vcpu_id;
>  
>      mem_event_put_request(d, &d->mem_paging, &req);
> +    
> +    ret = 0;
> + out:
> +    return ret;   
>  }
>  
> +
>  /**
>   * p2m_mem_paging_prep - Allocate a new page for the guest
>   * @d: guest domain
> diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
> --- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
> +++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
> @@ -485,7 +485,7 @@
>  /* Tell xenpaging to drop a paged out frame */
>  void 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);
> +int 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);
>  /* Resume normal operation (in case a domain was paused) */
> diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
> --- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
> +++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
> @@ -721,6 +721,7 @@
>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
> +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
>  
>  /*
>   * Access permissions.
> 

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 05 09:26:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 09:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RijaX-0002fL-PM; Thu, 05 Jan 2012 09:26: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 1RijaW-0002fB-C0
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 09:26:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325755574!9806731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30221 invoked from network); 5 Jan 2012 09:26:14 -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;
	5 Jan 2012 09:26:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9828360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 09:26: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, 5 Jan 2012
	09:26:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 5 Jan 2012 09:26:00 +0000
In-Reply-To: <20120104162708.GA26431@aepfle.de>
References: <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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
	<20120104155734.GA9271@aepfle.de>
	<1325694125.25206.299.camel@zakaz.uk.xensource.com>
	<20120104162708.GA26431@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325755560.25206.345.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>,
	Ian Jackson <Ian.Jackson@eu.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 Wed, 2012-01-04 at 16:27 +0000, Olaf Hering wrote:
> On Wed, Jan 04, Ian Campbell wrote:
> 
> > I think the toolstack needs to be involved with this. IOW this should be
> > done in libxl__domain_make() around the same place as
> > control/platform-feature-multiprocessor-suspend is written.
> 
> Isnt XS_RESET_WATCHES a feature of xenstored, so it should add its own stuff itself?

Ultimately I think it needs to be the toolstack so that it can control
if this gets written or not based on configuration should that become
necessary.

This is similar to how control/platform-feature-multiprocessor-suspend
is a feature of libxc but libxl still writes the node.

In general we tend to consider the toolstack as a matched set so in a
given release the toolstack is allowed to rely on features (and in
particular bugfixes) of xenstored in that release.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 09:26:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 09:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RijaX-0002fL-PM; Thu, 05 Jan 2012 09:26: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 1RijaW-0002fB-C0
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 09:26:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325755574!9806731!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTUyOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30221 invoked from network); 5 Jan 2012 09:26:14 -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;
	5 Jan 2012 09:26:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9828360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 09:26: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, 5 Jan 2012
	09:26:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Thu, 5 Jan 2012 09:26:00 +0000
In-Reply-To: <20120104162708.GA26431@aepfle.de>
References: <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>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
	<20120104155734.GA9271@aepfle.de>
	<1325694125.25206.299.camel@zakaz.uk.xensource.com>
	<20120104162708.GA26431@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325755560.25206.345.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>,
	Ian Jackson <Ian.Jackson@eu.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 Wed, 2012-01-04 at 16:27 +0000, Olaf Hering wrote:
> On Wed, Jan 04, Ian Campbell wrote:
> 
> > I think the toolstack needs to be involved with this. IOW this should be
> > done in libxl__domain_make() around the same place as
> > control/platform-feature-multiprocessor-suspend is written.
> 
> Isnt XS_RESET_WATCHES a feature of xenstored, so it should add its own stuff itself?

Ultimately I think it needs to be the toolstack so that it can control
if this gets written or not based on configuration should that become
necessary.

This is similar to how control/platform-feature-multiprocessor-suspend
is a feature of libxc but libxl still writes the node.

In general we tend to consider the toolstack as a matched set so in a
given release the toolstack is allowed to rely on features (and in
particular bugfixes) of xenstored in that release.

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 09:40:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 09:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rijo5-0002tz-6T; Thu, 05 Jan 2012 09:40:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Philippe.Simonet@swisscom.com>) id 1Rijo3-0002ts-W0
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 09:40:20 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325756413!9671284!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gODg0NDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29436 invoked from network); 5 Jan 2012 09:40:13 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 09:40:13 -0000
Received: by mail.swisscom.com; Thu, 5 Jan 2012 10:39:38 +0100
From: <Philippe.Simonet@swisscom.com>
To: <joy@entuzijast.net>, <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
	wrapped 10 or more times.
Thread-Index: AQHMywXO5+ao08/jK0mCGjzA8OSDsJX9g0nQ
Date: Thu, 5 Jan 2012 09:39:37 +0000
Message-ID: <FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
References: <20120104172343.GA30630@entuzijast.net>
In-Reply-To: <20120104172343.GA30630@entuzijast.net>
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
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

I have the same problem with 4 machines (hp dl385, AMD), the problem appears one time per machine and per month ...
No chance to re-produce it faster. On some other machine with another AMD processor, I never had this problem. Olivier Hanesse
reported the problem on some Intel CPU and not on other processor.

I'm using debian squeeze, with 

xen-hypervisor-4.0-amd64                4.0.1-4
linux-image-2.6.32-5-xen-amd64          2.6.32-38 (dom0)

that last changes that I have done is to add cpuidle=0 to hypervisor command line. stable since 3-4 weeks (...)

I have e test system that runs 20 paravirt. domus, with wheezy, with same problematic HW, with
xen-hypervisor-4.1-amd64                4.1.2-2
linux-image-3.1.0-1-amd64               3.1.6-1 (dom0)
and this system never had the TSC jump problem. but test system are test system ....

I would be happy if you could reproduce the problem faster a me, so testing new xen / dom0 version could be
easier ...

thanks and regards

Philippe




> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Josip Rodin
> Sent: Wednesday, January 04, 2012 6:24 PM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
> wrapped 10 or more times.
> 
> Hi,
> 
> Sometimes, seemingly randomly, long-running Xen domains, using
> clocksource xen, have their clock shift by ~3000 or ~36000 seconds, often
> with the dom0 complaining about clocksource tsc. The number changes if the
> hypervisor is explicitly told to use clocksource=pit, but it still happens. It
> doesn't seem to be particularly hardware-specific.
> 
> See also http://bugs.debian.org/599161
> 
> I see from the archives that others have reported this problem here in
> February last year, but I couldn't find a resolution. Can anyone help?
> 
> (Please Cc: responses, I'm not subscribed.)
> 
> --
>      2. That which causes joy or happiness.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 05 09:40:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 09:40:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rijo5-0002tz-6T; Thu, 05 Jan 2012 09:40:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Philippe.Simonet@swisscom.com>) id 1Rijo3-0002ts-W0
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 09:40:20 +0000
X-Env-Sender: Philippe.Simonet@swisscom.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325756413!9671284!1
X-Originating-IP: [193.222.81.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkzLjIyMi44MS4xMDAgPT4gODg0NDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29436 invoked from network); 5 Jan 2012 09:40:13 -0000
Received: from outmail100.swisscom.com (HELO mail.swisscom.com)
	(193.222.81.100)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 09:40:13 -0000
Received: by mail.swisscom.com; Thu, 5 Jan 2012 10:39:38 +0100
From: <Philippe.Simonet@swisscom.com>
To: <joy@entuzijast.net>, <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
	wrapped 10 or more times.
Thread-Index: AQHMywXO5+ao08/jK0mCGjzA8OSDsJX9g0nQ
Date: Thu, 5 Jan 2012 09:39:37 +0000
Message-ID: <FF93AF260AC2BB499A119CC65B092CF73123E467@sg000713.corproot.net>
References: <20120104172343.GA30630@entuzijast.net>
In-Reply-To: <20120104172343.GA30630@entuzijast.net>
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
Subject: Re: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
 wrapped 10 or more times.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi

I have the same problem with 4 machines (hp dl385, AMD), the problem appears one time per machine and per month ...
No chance to re-produce it faster. On some other machine with another AMD processor, I never had this problem. Olivier Hanesse
reported the problem on some Intel CPU and not on other processor.

I'm using debian squeeze, with 

xen-hypervisor-4.0-amd64                4.0.1-4
linux-image-2.6.32-5-xen-amd64          2.6.32-38 (dom0)

that last changes that I have done is to add cpuidle=0 to hypervisor command line. stable since 3-4 weeks (...)

I have e test system that runs 20 paravirt. domus, with wheezy, with same problematic HW, with
xen-hypervisor-4.1-amd64                4.1.2-2
linux-image-3.1.0-1-amd64               3.1.6-1 (dom0)
and this system never had the TSC jump problem. but test system are test system ....

I would be happy if you could reproduce the problem faster a me, so testing new xen / dom0 version could be
easier ...

thanks and regards

Philippe




> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Josip Rodin
> Sent: Wednesday, January 04, 2012 6:24 PM
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] (XEN) Platform timer appears to have unexpectedly
> wrapped 10 or more times.
> 
> Hi,
> 
> Sometimes, seemingly randomly, long-running Xen domains, using
> clocksource xen, have their clock shift by ~3000 or ~36000 seconds, often
> with the dom0 complaining about clocksource tsc. The number changes if the
> hypervisor is explicitly told to use clocksource=pit, but it still happens. It
> doesn't seem to be particularly hardware-specific.
> 
> See also http://bugs.debian.org/599161
> 
> I see from the archives that others have reported this problem here in
> February last year, but I couldn't find a resolution. Can anyone help?
> 
> (Please Cc: responses, I'm not subscribed.)
> 
> --
>      2. That which causes joy or happiness.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 05 10:24:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 10:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RikUe-0003Eh-Vx; Thu, 05 Jan 2012 10:24: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 1RikUd-0003Ec-C9
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 10:24:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325759052!7922765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5467 invoked from network); 5 Jan 2012 10:24:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 10:24:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9830200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 10:24:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	10:24:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 5 Jan 2012 10:24:11 +0000
In-Reply-To: <1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325759051.25206.361.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
> We use the __pci_reset_function_locked to perform the action.
> Also on attaching ("bind") and detaching ("unbind") we save and
> restore the configuration states. When the device is disconnected
> from a guest we use the "pci_reset_function" to also reset the
> device before being passed to another guest.

Currently I thought the toolstack was supposed to do the reset (by
writing to the reset node in sysfs) as it was (de)assigning devices
to/from guests. That's not to say that there isn't an argument for
preferring to do it kernels side but it would be interesting to make
that argument explicitly.

I guess the toolstack doesn't currently save/restore the configuration
state, could it though? I guess the state is all available in sysfs. On
the other hand the kernel provides us with a very handy function which
Just Does It...

Ian.

> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
>  drivers/xen/xen-pciback/pciback.h  |    1 +
>  2 files changed, 39 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
> index 8f06e1e..0ce0dc6 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
>  static void pcistub_device_release(struct kref *kref)
>  {
>  	struct pcistub_device *psdev;
> +	struct xen_pcibk_dev_data *dev_data;
>  
>  	psdev = container_of(kref, struct pcistub_device, kref);
> +	dev_data = pci_get_drvdata(psdev->dev);
>  
>  	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
>  
>  	xen_unregister_device_domain_owner(psdev->dev);
>  
> -	/* Clean-up the device */
> +	/* Call the reset function which does not take lock as this
> +	 * is called from "unbind" which takes a device_lock mutex.
> +	 */
> +	__pci_reset_function_locked(psdev->dev);
> +	if (pci_load_and_free_saved_state(psdev->dev,
> +					  &dev_data->pci_saved_state)) {
> +		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> +	} else
> +		pci_restore_state(psdev->dev);
> +
> +	/* Disable the device */
>  	xen_pcibk_reset_device(psdev->dev);
> +
> +	kfree(dev_data);
> +	pci_set_drvdata(psdev->dev, NULL);
> +
> +	/* Clean-up the device */
>  	xen_pcibk_config_free_dyn_fields(psdev->dev);
>  	xen_pcibk_config_free_dev(psdev->dev);
> -	kfree(pci_get_drvdata(psdev->dev));
> -	pci_set_drvdata(psdev->dev, NULL);
>  
>  	pci_dev_put(psdev->dev);
>  
> @@ -230,7 +245,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
>  	/* Cleanup our device
>  	 * (so it's ready for the next domain)
>  	 */
> +
> +	/* This is OK - we are running from workqueue context
> +	 * and want to inhibit the user from fiddling with 'reset'
> +	 */
> +	pci_reset_function(dev);
> +	pci_restore_state(psdev->dev);
> +
> +	/* This disables the device. */
>  	xen_pcibk_reset_device(found_psdev->dev);
> +
> +	/* And cleanup up our emulated fields. */
>  	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
>  	xen_pcibk_config_reset_dev(found_psdev->dev);
>  
> @@ -325,6 +350,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
>  	if (err)
>  		goto config_release;
>  
> +	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +	__pci_reset_function_locked(dev);
> +
> +	/* We need the device active to save the state. */
> +	dev_dbg(&dev->dev, "save state of device\n");
> +	pci_save_state(dev);
> +	dev_data->pci_saved_state = pci_store_saved_state(dev);
> +	if (!dev_data->pci_saved_state)
> +		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> +
>  	/* Now disable the device (this also ensures some private device
>  	 * data is setup before we export)
>  	 */
> diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
> index e9b4011..a7def01 100644
> --- a/drivers/xen/xen-pciback/pciback.h
> +++ b/drivers/xen/xen-pciback/pciback.h
> @@ -41,6 +41,7 @@ struct xen_pcibk_device {
>  
>  struct xen_pcibk_dev_data {
>  	struct list_head config_fields;
> +	struct pci_saved_state *pci_saved_state;
>  	unsigned int permissive:1;
>  	unsigned int warned_on_write:1;
>  	unsigned int enable_intx:1;



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 10:24:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 10:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RikUe-0003Eh-Vx; Thu, 05 Jan 2012 10:24: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 1RikUd-0003Ec-C9
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 10:24:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325759052!7922765!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5467 invoked from network); 5 Jan 2012 10:24:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 10:24:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9830200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 10:24:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	10:24:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Thu, 5 Jan 2012 10:24:11 +0000
In-Reply-To: <1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325759051.25206.361.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
> We use the __pci_reset_function_locked to perform the action.
> Also on attaching ("bind") and detaching ("unbind") we save and
> restore the configuration states. When the device is disconnected
> from a guest we use the "pci_reset_function" to also reset the
> device before being passed to another guest.

Currently I thought the toolstack was supposed to do the reset (by
writing to the reset node in sysfs) as it was (de)assigning devices
to/from guests. That's not to say that there isn't an argument for
preferring to do it kernels side but it would be interesting to make
that argument explicitly.

I guess the toolstack doesn't currently save/restore the configuration
state, could it though? I guess the state is all available in sysfs. On
the other hand the kernel provides us with a very handy function which
Just Does It...

Ian.

> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
>  drivers/xen/xen-pciback/pciback.h  |    1 +
>  2 files changed, 39 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
> index 8f06e1e..0ce0dc6 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
>  static void pcistub_device_release(struct kref *kref)
>  {
>  	struct pcistub_device *psdev;
> +	struct xen_pcibk_dev_data *dev_data;
>  
>  	psdev = container_of(kref, struct pcistub_device, kref);
> +	dev_data = pci_get_drvdata(psdev->dev);
>  
>  	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
>  
>  	xen_unregister_device_domain_owner(psdev->dev);
>  
> -	/* Clean-up the device */
> +	/* Call the reset function which does not take lock as this
> +	 * is called from "unbind" which takes a device_lock mutex.
> +	 */
> +	__pci_reset_function_locked(psdev->dev);
> +	if (pci_load_and_free_saved_state(psdev->dev,
> +					  &dev_data->pci_saved_state)) {
> +		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
> +	} else
> +		pci_restore_state(psdev->dev);
> +
> +	/* Disable the device */
>  	xen_pcibk_reset_device(psdev->dev);
> +
> +	kfree(dev_data);
> +	pci_set_drvdata(psdev->dev, NULL);
> +
> +	/* Clean-up the device */
>  	xen_pcibk_config_free_dyn_fields(psdev->dev);
>  	xen_pcibk_config_free_dev(psdev->dev);
> -	kfree(pci_get_drvdata(psdev->dev));
> -	pci_set_drvdata(psdev->dev, NULL);
>  
>  	pci_dev_put(psdev->dev);
>  
> @@ -230,7 +245,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
>  	/* Cleanup our device
>  	 * (so it's ready for the next domain)
>  	 */
> +
> +	/* This is OK - we are running from workqueue context
> +	 * and want to inhibit the user from fiddling with 'reset'
> +	 */
> +	pci_reset_function(dev);
> +	pci_restore_state(psdev->dev);
> +
> +	/* This disables the device. */
>  	xen_pcibk_reset_device(found_psdev->dev);
> +
> +	/* And cleanup up our emulated fields. */
>  	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
>  	xen_pcibk_config_reset_dev(found_psdev->dev);
>  
> @@ -325,6 +350,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
>  	if (err)
>  		goto config_release;
>  
> +	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
> +	__pci_reset_function_locked(dev);
> +
> +	/* We need the device active to save the state. */
> +	dev_dbg(&dev->dev, "save state of device\n");
> +	pci_save_state(dev);
> +	dev_data->pci_saved_state = pci_store_saved_state(dev);
> +	if (!dev_data->pci_saved_state)
> +		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
> +
>  	/* Now disable the device (this also ensures some private device
>  	 * data is setup before we export)
>  	 */
> diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
> index e9b4011..a7def01 100644
> --- a/drivers/xen/xen-pciback/pciback.h
> +++ b/drivers/xen/xen-pciback/pciback.h
> @@ -41,6 +41,7 @@ struct xen_pcibk_device {
>  
>  struct xen_pcibk_dev_data {
>  	struct list_head config_fields;
> +	struct pci_saved_state *pci_saved_state;
>  	unsigned int permissive:1;
>  	unsigned int warned_on_write:1;
>  	unsigned int enable_intx:1;



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 10:40:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 10:40:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RikjK-0003UQ-J3; Thu, 05 Jan 2012 10:39:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RikjJ-0003UL-5x
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 10:39:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325759962!9800622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17215 invoked from network); 5 Jan 2012 10:39:23 -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 Jan 2012 10:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9830689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 10:39: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; Thu, 5 Jan 2012
	10:39:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 5 Jan 2012 10:39:20 +0000
In-Reply-To: <20120104182037.GC15595@ocelot.phlegethon.org>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
	<20120104182037.GC15595@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325759960.25206.363.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 18:20 +0000, Tim Deegan wrote:
> At 19:25 +0200 on 04 Jan (1325705119), Pasi K?rkk?inen wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > What are the outstanding things to do before we think we can start on
> > > the 4.2 -rc's? Does anyone have a timetable in mind?
> > > 
> > > hypervisor:
> > > 
> > >       * ??? - Keir, Tim, Jan?
> 
> I would like to get the interface changes for sharing/paging/mem-events
> done and dusted so that 4.2 is a stable API that we hold to.
> 
> It would be nice to get the implementation solid too (i.e., using wait
> queues) but that can happen later if it's the only thing holding up a
> release.
> 
> > - What's the status of Nested Hardware Virtualization? 
> > I remember some email saying Intel vmx-on-vmx has some performance issues,
> > and amd svm-on-svm works better..

That's the impression that I've gotten too.

> The basic feature is in for AMD and Intel, but AIUI it's not getting a
> lot of use and it's not in the xen.org automated testing.  The AMD code
> has nested-paging support too, which is a requirement for decent
> performance. 
> 
> We could call it 'experimental' for 4.2?

IMHO we shouldn't hold up the release for it so either it is working by
the time the release happens or it is experimental. (I guess we should
consider svm-on-svm and vmx-on-vmx separately for these purposes).

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 10:40:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 10:40:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RikjK-0003UQ-J3; Thu, 05 Jan 2012 10:39:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RikjJ-0003UL-5x
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 10:39:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325759962!9800622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17215 invoked from network); 5 Jan 2012 10:39:23 -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 Jan 2012 10:39:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9830689"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 10:39: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; Thu, 5 Jan 2012
	10:39:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 5 Jan 2012 10:39:20 +0000
In-Reply-To: <20120104182037.GC15595@ocelot.phlegethon.org>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
	<20120104182037.GC15595@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325759960.25206.363.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 18:20 +0000, Tim Deegan wrote:
> At 19:25 +0200 on 04 Jan (1325705119), Pasi K?rkk?inen wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > What are the outstanding things to do before we think we can start on
> > > the 4.2 -rc's? Does anyone have a timetable in mind?
> > > 
> > > hypervisor:
> > > 
> > >       * ??? - Keir, Tim, Jan?
> 
> I would like to get the interface changes for sharing/paging/mem-events
> done and dusted so that 4.2 is a stable API that we hold to.
> 
> It would be nice to get the implementation solid too (i.e., using wait
> queues) but that can happen later if it's the only thing holding up a
> release.
> 
> > - What's the status of Nested Hardware Virtualization? 
> > I remember some email saying Intel vmx-on-vmx has some performance issues,
> > and amd svm-on-svm works better..

That's the impression that I've gotten too.

> The basic feature is in for AMD and Intel, but AIUI it's not getting a
> lot of use and it's not in the xen.org automated testing.  The AMD code
> has nested-paging support too, which is a requirement for decent
> performance. 
> 
> We could call it 'experimental' for 4.2?

IMHO we shouldn't hold up the release for it so either it is working by
the time the release happens or it is experimental. (I guess we should
consider svm-on-svm and vmx-on-vmx separately for these purposes).

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 11:20:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 11:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RilMY-0003os-4s; Thu, 05 Jan 2012 11:20:02 +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 1RilMW-0003on-Ag
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:20:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1325762394!9756781!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21475 invoked from network); 5 Jan 2012 11:19:54 -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;
	5 Jan 2012 11:19:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9831800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 11:19: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; Thu, 5 Jan 2012 11:19:54 +0000
Date: Thu, 5 Jan 2012 11:19:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1325753287.25206.339.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201051114290.3150@kaball-desktop>
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>
	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
	<1325696094.25206.321.camel@zakaz.uk.xensource.com>
	<4F049A46.5080104@tycho.nsa.gov>
	<1325753287.25206.339.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"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 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 Thu, 5 Jan 2012, Ian Campbell wrote:
> On Wed, 2012-01-04 at 18:28 +0000, Daniel De Graaf wrote:
> > On 01/04/2012 11:54 AM, Ian Campbell wrote:
> > > On Wed, 2012-01-04 at 16:49 +0000, Stefano Stabellini wrote:
> > >> On Wed, 4 Jan 2012, Daniel De Graaf wrote:
> > >>> The example policy doesn't really belong in docs because it needs to be
> > >>> compiled to be usable, and this depends on a number of other files (all
> > >>> files under tools/flask/policy/policy, to be exact). Compiling and
> > >>> installing FLASK policy during the normal build process (conditional on
> > >>> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
> > >>> would be the best solution. The policy must be installed to /boot, not
> > >>> /etc/xen, because the initial policy load happens prior to starting dom0.
> > >>
> > >> Like Ian said, I meant having the policy somewhere online where can be
> > >> linked. However we only publish on xenbits what we have under docs ATM.
> > >> It is unfortunate that the policy needs FLASK_ENABLE to be compiled
> > >> because I am pretty sure that the automated build system that produces
> > >> the docs that end up online does not support that option right now.
> > > 
> > > Publishing the docs in this manner wouldn't require FLASK_ENABLE since
> > > it doesn't need any tools, just "cp". Unless I've totally got the wrong
> > > end of the stick and the policy needs processing before you can even
> > > usefully read it?
> > > 
> > > Ian.
> > > 
> > 
> > You can read the policy files as-is; the xen.te and xen.if files contain
> > most of what you would want to inspect. However, this is similar to reading
> > shell scripts or other source files, which is not what I would expect from
> > files copied into a docs folder.
> 
> In that case I think the best approach would be to reference the file
> via the mercurial webterface e.g.
> http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/tools/flask/policy/policy/modules/xen/xen.te
> 
> > There are some tools for searching and understanding SELinux policy such as
> > sesearch that work either on the binary policy file or on the macro-expanded
> > policy.conf. Building policy.conf only requires m4, which is already required
> > for bison as part of Xen's build process. This file is much less readable by
> > humans, however, since it is the output of macro expansion.
> 
> Doesn't sound like something that it would be useful to publish, but
> does sound very useful if you've actually got the flask tools installed
> etc.
> 
> > Also: the policy currently isn't built automatically even if FLASK_ENABLE=y;
> > this is something that I think should be changed although I will wait to post
> > a patch until we've decided what parts of the output should be used.
> 
> It sounds like we don't need to use any parts but in any case we may as
> well arrange for it to be built and worry about any docs usage of it
> later.

Yeah, if we build it when FLASK_ENABLE=y at least we could simplify the
"Xen XSM:FLASK policy" subchapter and we could say in the xl manpage
that the user should be able to find a ready to use policy named
"xenpolicy" under the /boot directory.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 11:20:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 11:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RilMY-0003os-4s; Thu, 05 Jan 2012 11:20:02 +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 1RilMW-0003on-Ag
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 11:20:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1325762394!9756781!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21475 invoked from network); 5 Jan 2012 11:19:54 -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;
	5 Jan 2012 11:19:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9831800"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 11:19: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; Thu, 5 Jan 2012 11:19:54 +0000
Date: Thu, 5 Jan 2012 11:19:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1325753287.25206.339.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201051114290.3150@kaball-desktop>
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>
	<4EEA6D50.80902@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041036390.2970@kaball-desktop>
	<4F046A30.6000009@tycho.nsa.gov>
	<alpine.DEB.2.00.1201041644450.3150@kaball-desktop>
	<1325696094.25206.321.camel@zakaz.uk.xensource.com>
	<4F049A46.5080104@tycho.nsa.gov>
	<1325753287.25206.339.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"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 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 Thu, 5 Jan 2012, Ian Campbell wrote:
> On Wed, 2012-01-04 at 18:28 +0000, Daniel De Graaf wrote:
> > On 01/04/2012 11:54 AM, Ian Campbell wrote:
> > > On Wed, 2012-01-04 at 16:49 +0000, Stefano Stabellini wrote:
> > >> On Wed, 4 Jan 2012, Daniel De Graaf wrote:
> > >>> The example policy doesn't really belong in docs because it needs to be
> > >>> compiled to be usable, and this depends on a number of other files (all
> > >>> files under tools/flask/policy/policy, to be exact). Compiling and
> > >>> installing FLASK policy during the normal build process (conditional on
> > >>> FLASK_ENABLE to avoid adding SELinux build tools to build dependencies?)
> > >>> would be the best solution. The policy must be installed to /boot, not
> > >>> /etc/xen, because the initial policy load happens prior to starting dom0.
> > >>
> > >> Like Ian said, I meant having the policy somewhere online where can be
> > >> linked. However we only publish on xenbits what we have under docs ATM.
> > >> It is unfortunate that the policy needs FLASK_ENABLE to be compiled
> > >> because I am pretty sure that the automated build system that produces
> > >> the docs that end up online does not support that option right now.
> > > 
> > > Publishing the docs in this manner wouldn't require FLASK_ENABLE since
> > > it doesn't need any tools, just "cp". Unless I've totally got the wrong
> > > end of the stick and the policy needs processing before you can even
> > > usefully read it?
> > > 
> > > Ian.
> > > 
> > 
> > You can read the policy files as-is; the xen.te and xen.if files contain
> > most of what you would want to inspect. However, this is similar to reading
> > shell scripts or other source files, which is not what I would expect from
> > files copied into a docs folder.
> 
> In that case I think the best approach would be to reference the file
> via the mercurial webterface e.g.
> http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/tools/flask/policy/policy/modules/xen/xen.te
> 
> > There are some tools for searching and understanding SELinux policy such as
> > sesearch that work either on the binary policy file or on the macro-expanded
> > policy.conf. Building policy.conf only requires m4, which is already required
> > for bison as part of Xen's build process. This file is much less readable by
> > humans, however, since it is the output of macro expansion.
> 
> Doesn't sound like something that it would be useful to publish, but
> does sound very useful if you've actually got the flask tools installed
> etc.
> 
> > Also: the policy currently isn't built automatically even if FLASK_ENABLE=y;
> > this is something that I think should be changed although I will wait to post
> > a patch until we've decided what parts of the output should be used.
> 
> It sounds like we don't need to use any parts but in any case we may as
> well arrange for it to be built and worry about any docs usage of it
> later.

Yeah, if we build it when FLASK_ENABLE=y at least we could simplify the
"Xen XSM:FLASK policy" subchapter and we could say in the xl manpage
that the user should be able to find a ready to use policy named
"xenpolicy" under the /boot directory.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 12:27:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 12:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RimPY-0004FU-U6; Thu, 05 Jan 2012 12:27:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RimPW-0004FM-Q8
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 12:27:10 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325766422!9817312!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12590 invoked from network); 5 Jan 2012 12:27:04 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 12:27:04 -0000
Received: by obbwd20 with SMTP id wd20so1370564obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 04:27:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=+0/7RogMsuvKClds9kt3T+1EyeRoYBKNY8LJu0xg5EM=;
	b=lTkhcVJ++gkF1nV3RdQsf/O4Pdhli80hLvq2x0fl75BZfkBWaF2wwt1i0UCURptJ62
	7efu0bgtp1d/fLT49HSZJsoD56zjjE/N/2pFisVTVeOz/vHUOEmIrDqCRCuaIbpnnKBv
	tDxBFrV7u10R9GobF8sEqd9ktPXuTR46xklso=
Received: by 10.182.43.10 with SMTP id s10mr1280978obl.43.1325766422461; Thu,
	05 Jan 2012 04:27:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.36.230 with HTTP; Thu, 5 Jan 2012 04:26:31 -0800 (PST)
In-Reply-To: <20120103170555.3a32ac1b@doriath>
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>
	<alpine.DEB.2.00.1112191637230.11530@perard.uk.xensource.com>
	<20120103170555.3a32ac1b@doriath>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 5 Jan 2012 12:26:31 +0000
X-Google-Sender-Auth: eBR4KKy97KREDigJ5rqiinhOyxA
Message-ID: <CAJJyHj+07H2tUOpWdWT+07sW7_CCsRB0-Z9segPVYV=dgovhkg@mail.gmail.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 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 Tue, Jan 3, 2012 at 19:05, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Mon, 19 Dec 2011 17:27:55 +0000
> Anthony PERARD <anthony.perard@citrix.com> wrote:
>
>> 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.
>
> Do you need both? What about setting inmigrate when initializing the
> machine and using it instead?

I suppose I can use it, by setting INMIGRATE earlier. I was afraid to
change the meaning of inmigrate, but this seems fine in the QEMU point
of view.

> PS: sorry for the delay, I was on vacation.

This is fine, me too :).

-- 
Anthony PERARD

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 12:27:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 12:27:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RimPY-0004FU-U6; Thu, 05 Jan 2012 12:27:12 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@gmail.com>) id 1RimPW-0004FM-Q8
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 12:27:10 +0000
X-Env-Sender: anthony.perard@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325766422!9817312!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12590 invoked from network); 5 Jan 2012 12:27:04 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 12:27:04 -0000
Received: by obbwd20 with SMTP id wd20so1370564obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 04:27:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=+0/7RogMsuvKClds9kt3T+1EyeRoYBKNY8LJu0xg5EM=;
	b=lTkhcVJ++gkF1nV3RdQsf/O4Pdhli80hLvq2x0fl75BZfkBWaF2wwt1i0UCURptJ62
	7efu0bgtp1d/fLT49HSZJsoD56zjjE/N/2pFisVTVeOz/vHUOEmIrDqCRCuaIbpnnKBv
	tDxBFrV7u10R9GobF8sEqd9ktPXuTR46xklso=
Received: by 10.182.43.10 with SMTP id s10mr1280978obl.43.1325766422461; Thu,
	05 Jan 2012 04:27:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.36.230 with HTTP; Thu, 5 Jan 2012 04:26:31 -0800 (PST)
In-Reply-To: <20120103170555.3a32ac1b@doriath>
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>
	<alpine.DEB.2.00.1112191637230.11530@perard.uk.xensource.com>
	<20120103170555.3a32ac1b@doriath>
From: Anthony PERARD <anthony.perard@citrix.com>
Date: Thu, 5 Jan 2012 12:26:31 +0000
X-Google-Sender-Auth: eBR4KKy97KREDigJ5rqiinhOyxA
Message-ID: <CAJJyHj+07H2tUOpWdWT+07sW7_CCsRB0-Z9segPVYV=dgovhkg@mail.gmail.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 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 Tue, Jan 3, 2012 at 19:05, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Mon, 19 Dec 2011 17:27:55 +0000
> Anthony PERARD <anthony.perard@citrix.com> wrote:
>
>> 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.
>
> Do you need both? What about setting inmigrate when initializing the
> machine and using it instead?

I suppose I can use it, by setting INMIGRATE earlier. I was afraid to
change the meaning of inmigrate, but this seems fine in the QEMU point
of view.

> PS: sorry for the delay, I was on vacation.

This is fine, me too :).

-- 
Anthony PERARD

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 12:31:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 12:31:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RimTX-0004NO-JS; Thu, 05 Jan 2012 12:31:19 +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 1RimTW-0004NB-Ed
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 12:31:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325766671!9704168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9691 invoked from network); 5 Jan 2012 12:31:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 12:31:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9833954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 12:30:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 12:30:51 +0000
Date: Thu, 5 Jan 2012 12:30:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F048B10.1060505@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051134150.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Wed, 4 Jan 2012, Avi Kivity wrote:
> On 01/04/2012 06:38 PM, Stefano Stabellini wrote:
> >
> > > 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()
> >
> > I cannot see how this is going to fix the save/restore issue we are
> > trying to solve.
> > The problem, unfortunately very complex, is that at restore time the
> > videoram is already allocated at the physical address it was mapped
> > before the save operation. If it was not mapped, it is at the end of the
> > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
> > allocate it).
> 
> Sorry, I don't follow, please be specific as to which type of address
> you're referring to:
> 
> ram_addr?
> physical address (as seen by guest - but if it is not mapped, what does
> your last sentence mean?)
> something else?

ram_addr_t as returned by qemu_ram_alloc_from_ptr.

In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add
the specified amount of memory to the guest physmap at
new_block->offset. So in a way the videoram is always visible by the
guest, initially at new_block->offset, chosen by find_ram_offset, then
at cirrus_bank_base, when map_linear_vram_bank is called.


> > So the issue is that the videoram appears to qemu as part of the
> > physical memory of the guest at an unknown address.
> >
> > The proposal of introducing early_savevm would easily solve this last
> > problem: letting us know where the videoram is. The other problem, the
> > fact that under Xen the videoram would be already allocated while under
> > native it would not, remains unsolved. 
> > We cannot simply allocate the videoram twice because the operation
> > would fail (Xen would realize that we are trying to allocate more memory
> > than it we are supposed to, returning an error).
> > However, once we know where the videoram is, we could probably figure out
> > a smart (see hacky) way to avoid allocating it twice without changes to
> > the cirrus code.
> 
> I'm missing some context.  Can you please explain in more detail?
> Note that with the memory API changes, ram addresses are going away. 
> There will not be a linear space for guest RAM.  We'll have
> (MemoryRegion *, offset) pairs that will be mapped into discontiguous
> guest physical address ranges (perhaps with overlaps).


This is how memory is currently allocated and mapped in qemu on xen:

- qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for
the guest, the memory is added to the guest p2m (physical to machine
translation table) at the given guest physical address
(new_block->offset, as chosen by find_ram_offset);

- qemu_get_ram_ptr uses the xen mapcache to map guest physical address
ranges into qemu's address space, so that qemu can read/write guest
memory;

- xen_set_memory, called by the memory_listener interface, effectively
moves a guest physical memory address range from one address to another.
So the memory that was initially allocated at new_block->offset, as
chosen by find_ram_offset, is going to be moved to a new destination,
section->offset_within_address_space.


So the videoram lifecycle is the following:

- qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end
  of the physmap;

- qemu_get_ram_ptr maps the videoram into qemu's address space;

- xen_set_memory moves the videoram to cirrus_bank_base;



Now let's introduce save/restore into the picture: the videoram is part
of the guest's memory from the hypervisor POV, so xen will take care of
saving and restoring it as part of the normal guest memory, out of
qemu's control.
At restore time, we know that the videoram is already allocated and
mapped somewhere in the guest physical address space: it could be
cirrus_bank_base, which we don't know yet, or the initial
new_block->offset.
A second videoram allocation by qemu_ram_alloc_from_ptr will fail
because of memory constraints enforced by the hypervisor. Trying to map
the already allocated videoram into qemu's address space is not easy
because we don't know where it is yet (keep in mind that machine->init
is called before the machine restore functions).

The "solution" I am proposing is introducing an early_savevm set of
save/restore functions so that at restore time we can get to know at
what address the videoram is mapped into the guest address space. Once we
know the address we can remap it into qemu's address space and/or move it
to another guest physical address.

The problem of avoiding a second allocation remains, but could be
solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
called "vga.vram" at restore time, and use the reference to the already
allocated videoram instead.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 12:31:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 12:31:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RimTX-0004NO-JS; Thu, 05 Jan 2012 12:31:19 +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 1RimTW-0004NB-Ed
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 12:31:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325766671!9704168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9691 invoked from network); 5 Jan 2012 12:31:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 12:31:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9833954"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 12:30:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 12:30:51 +0000
Date: Thu, 5 Jan 2012 12:30:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F048B10.1060505@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051134150.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Wed, 4 Jan 2012, Avi Kivity wrote:
> On 01/04/2012 06:38 PM, Stefano Stabellini wrote:
> >
> > > 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()
> >
> > I cannot see how this is going to fix the save/restore issue we are
> > trying to solve.
> > The problem, unfortunately very complex, is that at restore time the
> > videoram is already allocated at the physical address it was mapped
> > before the save operation. If it was not mapped, it is at the end of the
> > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
> > allocate it).
> 
> Sorry, I don't follow, please be specific as to which type of address
> you're referring to:
> 
> ram_addr?
> physical address (as seen by guest - but if it is not mapped, what does
> your last sentence mean?)
> something else?

ram_addr_t as returned by qemu_ram_alloc_from_ptr.

In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add
the specified amount of memory to the guest physmap at
new_block->offset. So in a way the videoram is always visible by the
guest, initially at new_block->offset, chosen by find_ram_offset, then
at cirrus_bank_base, when map_linear_vram_bank is called.


> > So the issue is that the videoram appears to qemu as part of the
> > physical memory of the guest at an unknown address.
> >
> > The proposal of introducing early_savevm would easily solve this last
> > problem: letting us know where the videoram is. The other problem, the
> > fact that under Xen the videoram would be already allocated while under
> > native it would not, remains unsolved. 
> > We cannot simply allocate the videoram twice because the operation
> > would fail (Xen would realize that we are trying to allocate more memory
> > than it we are supposed to, returning an error).
> > However, once we know where the videoram is, we could probably figure out
> > a smart (see hacky) way to avoid allocating it twice without changes to
> > the cirrus code.
> 
> I'm missing some context.  Can you please explain in more detail?
> Note that with the memory API changes, ram addresses are going away. 
> There will not be a linear space for guest RAM.  We'll have
> (MemoryRegion *, offset) pairs that will be mapped into discontiguous
> guest physical address ranges (perhaps with overlaps).


This is how memory is currently allocated and mapped in qemu on xen:

- qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for
the guest, the memory is added to the guest p2m (physical to machine
translation table) at the given guest physical address
(new_block->offset, as chosen by find_ram_offset);

- qemu_get_ram_ptr uses the xen mapcache to map guest physical address
ranges into qemu's address space, so that qemu can read/write guest
memory;

- xen_set_memory, called by the memory_listener interface, effectively
moves a guest physical memory address range from one address to another.
So the memory that was initially allocated at new_block->offset, as
chosen by find_ram_offset, is going to be moved to a new destination,
section->offset_within_address_space.


So the videoram lifecycle is the following:

- qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end
  of the physmap;

- qemu_get_ram_ptr maps the videoram into qemu's address space;

- xen_set_memory moves the videoram to cirrus_bank_base;



Now let's introduce save/restore into the picture: the videoram is part
of the guest's memory from the hypervisor POV, so xen will take care of
saving and restoring it as part of the normal guest memory, out of
qemu's control.
At restore time, we know that the videoram is already allocated and
mapped somewhere in the guest physical address space: it could be
cirrus_bank_base, which we don't know yet, or the initial
new_block->offset.
A second videoram allocation by qemu_ram_alloc_from_ptr will fail
because of memory constraints enforced by the hypervisor. Trying to map
the already allocated videoram into qemu's address space is not easy
because we don't know where it is yet (keep in mind that machine->init
is called before the machine restore functions).

The "solution" I am proposing is introducing an early_savevm set of
save/restore functions so that at restore time we can get to know at
what address the videoram is mapped into the guest address space. Once we
know the address we can remap it into qemu's address space and/or move it
to another guest physical address.

The problem of avoiding a second allocation remains, but could be
solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
called "vga.vram" at restore time, and use the reference to the already
allocated videoram instead.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 12:47:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 12:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RimiN-0004bG-3b; Thu, 05 Jan 2012 12:46:39 +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 1RimiL-0004bB-Hs
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 12:46:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325767590!8482922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24579 invoked from network); 5 Jan 2012 12:46:30 -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;
	5 Jan 2012 12:46:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9834348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 12:46: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, 5 Jan 2012 12:46: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 1RimiD-0008VS-UV;
	Thu, 05 Jan 2012 12:46:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RimiD-0006Xh-U6;
	Thu, 05 Jan 2012 12:46:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10636-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 12:46:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10636: 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 10636 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10636/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 10635
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 10635

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      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-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-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  02b92d035f64
baseline version:
 xen                  efaa28639a71

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.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>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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:   24453:02b92d035f64
tag:         tip
user:        Yongan Liu<Liuyongan@huawei.com>
date:        Thu Jan 05 09:29:59 2012 +0100
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24452:efaa28639a71
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Wed Jan 04 16:12:44 2012 +0000
    
    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>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
========================================
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 Jan 05 12:47:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 12:47:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RimiN-0004bG-3b; Thu, 05 Jan 2012 12:46:39 +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 1RimiL-0004bB-Hs
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 12:46:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325767590!8482922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24579 invoked from network); 5 Jan 2012 12:46:30 -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;
	5 Jan 2012 12:46:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9834348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 12:46: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, 5 Jan 2012 12:46: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 1RimiD-0008VS-UV;
	Thu, 05 Jan 2012 12:46:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RimiD-0006Xh-U6;
	Thu, 05 Jan 2012 12:46:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10636-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 12:46:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10636: 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 10636 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10636/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 10635
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 10635

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      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-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-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  02b92d035f64
baseline version:
 xen                  efaa28639a71

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.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>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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:   24453:02b92d035f64
tag:         tip
user:        Yongan Liu<Liuyongan@huawei.com>
date:        Thu Jan 05 09:29:59 2012 +0100
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24452:efaa28639a71
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Wed Jan 04 16:12:44 2012 +0000
    
    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>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
========================================
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 Jan 05 12:51:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 12:51:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RimmB-0004hh-S8; Thu, 05 Jan 2012 12:50: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 1RimmA-0004hZ-5n
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 12:50:34 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325767827!7942241!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15598 invoked from network); 5 Jan 2012 12:50:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 12:50:27 -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 q05CoNZM013535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 07:50:23 -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 q05CoKj6000678; Thu, 5 Jan 2012 07:50:21 -0500
Message-ID: <4F059C8C.2030303@redhat.com>
Date: Thu, 05 Jan 2012 14:50:20 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
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 01/05/2012 02:30 PM, Stefano Stabellini wrote:
> > >
> > > I cannot see how this is going to fix the save/restore issue we are
> > > trying to solve.
> > > The problem, unfortunately very complex, is that at restore time the
> > > videoram is already allocated at the physical address it was mapped
> > > before the save operation. If it was not mapped, it is at the end of the
> > > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
> > > allocate it).
> > 
> > Sorry, I don't follow, please be specific as to which type of address
> > you're referring to:
> > 
> > ram_addr?
> > physical address (as seen by guest - but if it is not mapped, what does
> > your last sentence mean?)
> > something else?
>
> ram_addr_t as returned by qemu_ram_alloc_from_ptr.
>
> In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add
> the specified amount of memory to the guest physmap at
> new_block->offset. So in a way the videoram is always visible by the
> guest, initially at new_block->offset, chosen by find_ram_offset, then
> at cirrus_bank_base, when map_linear_vram_bank is called.

Okay.  So we will need to hook this differently from the memory API.

There are two places we can hook:
- memory_region_init_ram() - similar to qemu_ram_alloc() - at region
construction time
- MemoryListener::region_add() - called the first time the region is
made visible, probably not what we want

> > > So the issue is that the videoram appears to qemu as part of the
> > > physical memory of the guest at an unknown address.
> > >
> > > The proposal of introducing early_savevm would easily solve this last
> > > problem: letting us know where the videoram is. The other problem, the
> > > fact that under Xen the videoram would be already allocated while under
> > > native it would not, remains unsolved. 
> > > We cannot simply allocate the videoram twice because the operation
> > > would fail (Xen would realize that we are trying to allocate more memory
> > > than it we are supposed to, returning an error).
> > > However, once we know where the videoram is, we could probably figure out
> > > a smart (see hacky) way to avoid allocating it twice without changes to
> > > the cirrus code.
> > 
> > I'm missing some context.  Can you please explain in more detail?
> > Note that with the memory API changes, ram addresses are going away. 
> > There will not be a linear space for guest RAM.  We'll have
> > (MemoryRegion *, offset) pairs that will be mapped into discontiguous
> > guest physical address ranges (perhaps with overlaps).
>
>
> This is how memory is currently allocated and mapped in qemu on xen:
>
> - qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for
> the guest, the memory is added to the guest p2m (physical to machine
> translation table) at the given guest physical address
> (new_block->offset, as chosen by find_ram_offset);
>
> - qemu_get_ram_ptr uses the xen mapcache to map guest physical address
> ranges into qemu's address space, so that qemu can read/write guest
> memory;
>
> - xen_set_memory, called by the memory_listener interface, effectively
> moves a guest physical memory address range from one address to another.
> So the memory that was initially allocated at new_block->offset, as
> chosen by find_ram_offset, is going to be moved to a new destination,
> section->offset_within_address_space.

So, where qemu has two different address spaces (ram_addr_t and guest
physical addresses), Xen has just one, and any time the translation
between the two changes, you have to move memory around.


> So the videoram lifecycle is the following:
>
> - qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end
>   of the physmap;
>
> - qemu_get_ram_ptr maps the videoram into qemu's address space;
>
> - xen_set_memory moves the videoram to cirrus_bank_base;
>
>
>
> Now let's introduce save/restore into the picture: the videoram is part
> of the guest's memory from the hypervisor POV, so xen will take care of
> saving and restoring it as part of the normal guest memory, out of
> qemu's control.
> At restore time, we know that the videoram is already allocated and
> mapped somewhere in the guest physical address space: it could be
> cirrus_bank_base, which we don't know yet, or the initial
> new_block->offset.
> A second videoram allocation by qemu_ram_alloc_from_ptr will fail
> because of memory constraints enforced by the hypervisor. Trying to map
> the already allocated videoram into qemu's address space is not easy
> because we don't know where it is yet (keep in mind that machine->init
> is called before the machine restore functions).
>
> The "solution" I am proposing is introducing an early_savevm set of
> save/restore functions so that at restore time we can get to know at
> what address the videoram is mapped into the guest address space. Once we
> know the address we can remap it into qemu's address space and/or move it
> to another guest physical address.

Why can we not simply track it?  For every MemoryRegion, have a field
called xen_address which tracks its location in the Xen address space
(as determined by the last call to xen_set_memory or qemu_ram_alloc). 
xen_address would be maintained by callbacks called from the memory API
into xen-all.c.

> The problem of avoiding a second allocation remains, but could be
> solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> called "vga.vram" at restore time, and use the reference to the already
> allocated videoram instead.

Hacky.  The allocation is not driven by qemu then?

For the long term I suggest making qemu control the allocations (perhaps
by rpcing dom0); otherwise how can you do memory hotplug or PCI cards
with RAM (like ivshmem)?

-- 
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 Jan 05 12:51:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 12:51:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RimmB-0004hh-S8; Thu, 05 Jan 2012 12:50: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 1RimmA-0004hZ-5n
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 12:50:34 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325767827!7942241!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15598 invoked from network); 5 Jan 2012 12:50:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 12:50:27 -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 q05CoNZM013535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 07:50:23 -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 q05CoKj6000678; Thu, 5 Jan 2012 07:50:21 -0500
Message-ID: <4F059C8C.2030303@redhat.com>
Date: Thu, 05 Jan 2012 14:50:20 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
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 01/05/2012 02:30 PM, Stefano Stabellini wrote:
> > >
> > > I cannot see how this is going to fix the save/restore issue we are
> > > trying to solve.
> > > The problem, unfortunately very complex, is that at restore time the
> > > videoram is already allocated at the physical address it was mapped
> > > before the save operation. If it was not mapped, it is at the end of the
> > > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
> > > allocate it).
> > 
> > Sorry, I don't follow, please be specific as to which type of address
> > you're referring to:
> > 
> > ram_addr?
> > physical address (as seen by guest - but if it is not mapped, what does
> > your last sentence mean?)
> > something else?
>
> ram_addr_t as returned by qemu_ram_alloc_from_ptr.
>
> In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add
> the specified amount of memory to the guest physmap at
> new_block->offset. So in a way the videoram is always visible by the
> guest, initially at new_block->offset, chosen by find_ram_offset, then
> at cirrus_bank_base, when map_linear_vram_bank is called.

Okay.  So we will need to hook this differently from the memory API.

There are two places we can hook:
- memory_region_init_ram() - similar to qemu_ram_alloc() - at region
construction time
- MemoryListener::region_add() - called the first time the region is
made visible, probably not what we want

> > > So the issue is that the videoram appears to qemu as part of the
> > > physical memory of the guest at an unknown address.
> > >
> > > The proposal of introducing early_savevm would easily solve this last
> > > problem: letting us know where the videoram is. The other problem, the
> > > fact that under Xen the videoram would be already allocated while under
> > > native it would not, remains unsolved. 
> > > We cannot simply allocate the videoram twice because the operation
> > > would fail (Xen would realize that we are trying to allocate more memory
> > > than it we are supposed to, returning an error).
> > > However, once we know where the videoram is, we could probably figure out
> > > a smart (see hacky) way to avoid allocating it twice without changes to
> > > the cirrus code.
> > 
> > I'm missing some context.  Can you please explain in more detail?
> > Note that with the memory API changes, ram addresses are going away. 
> > There will not be a linear space for guest RAM.  We'll have
> > (MemoryRegion *, offset) pairs that will be mapped into discontiguous
> > guest physical address ranges (perhaps with overlaps).
>
>
> This is how memory is currently allocated and mapped in qemu on xen:
>
> - qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for
> the guest, the memory is added to the guest p2m (physical to machine
> translation table) at the given guest physical address
> (new_block->offset, as chosen by find_ram_offset);
>
> - qemu_get_ram_ptr uses the xen mapcache to map guest physical address
> ranges into qemu's address space, so that qemu can read/write guest
> memory;
>
> - xen_set_memory, called by the memory_listener interface, effectively
> moves a guest physical memory address range from one address to another.
> So the memory that was initially allocated at new_block->offset, as
> chosen by find_ram_offset, is going to be moved to a new destination,
> section->offset_within_address_space.

So, where qemu has two different address spaces (ram_addr_t and guest
physical addresses), Xen has just one, and any time the translation
between the two changes, you have to move memory around.


> So the videoram lifecycle is the following:
>
> - qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end
>   of the physmap;
>
> - qemu_get_ram_ptr maps the videoram into qemu's address space;
>
> - xen_set_memory moves the videoram to cirrus_bank_base;
>
>
>
> Now let's introduce save/restore into the picture: the videoram is part
> of the guest's memory from the hypervisor POV, so xen will take care of
> saving and restoring it as part of the normal guest memory, out of
> qemu's control.
> At restore time, we know that the videoram is already allocated and
> mapped somewhere in the guest physical address space: it could be
> cirrus_bank_base, which we don't know yet, or the initial
> new_block->offset.
> A second videoram allocation by qemu_ram_alloc_from_ptr will fail
> because of memory constraints enforced by the hypervisor. Trying to map
> the already allocated videoram into qemu's address space is not easy
> because we don't know where it is yet (keep in mind that machine->init
> is called before the machine restore functions).
>
> The "solution" I am proposing is introducing an early_savevm set of
> save/restore functions so that at restore time we can get to know at
> what address the videoram is mapped into the guest address space. Once we
> know the address we can remap it into qemu's address space and/or move it
> to another guest physical address.

Why can we not simply track it?  For every MemoryRegion, have a field
called xen_address which tracks its location in the Xen address space
(as determined by the last call to xen_set_memory or qemu_ram_alloc). 
xen_address would be maintained by callbacks called from the memory API
into xen-all.c.

> The problem of avoiding a second allocation remains, but could be
> solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> called "vga.vram" at restore time, and use the reference to the already
> allocated videoram instead.

Hacky.  The allocation is not driven by qemu then?

For the long term I suggest making qemu control the allocations (perhaps
by rpcing dom0); otherwise how can you do memory hotplug or PCI cards
with RAM (like ivshmem)?

-- 
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 Jan 05 13:18:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 13:18:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RinCi-0005Bm-8P; Thu, 05 Jan 2012 13:18:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RinCg-0005BM-Jc
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:17:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325769472!9871108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24454 invoked from network); 5 Jan 2012 13:17:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 13:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9835106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 13:17:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 13:17:51 +0000
Date: Thu, 5 Jan 2012 13:17:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F059C8C.2030303@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051303350.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 02:30 PM, Stefano Stabellini wrote:
> > > >
> > > > I cannot see how this is going to fix the save/restore issue we are
> > > > trying to solve.
> > > > The problem, unfortunately very complex, is that at restore time the
> > > > videoram is already allocated at the physical address it was mapped
> > > > before the save operation. If it was not mapped, it is at the end of the
> > > > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
> > > > allocate it).
> > > 
> > > Sorry, I don't follow, please be specific as to which type of address
> > > you're referring to:
> > > 
> > > ram_addr?
> > > physical address (as seen by guest - but if it is not mapped, what does
> > > your last sentence mean?)
> > > something else?
> >
> > ram_addr_t as returned by qemu_ram_alloc_from_ptr.
> >
> > In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add
> > the specified amount of memory to the guest physmap at
> > new_block->offset. So in a way the videoram is always visible by the
> > guest, initially at new_block->offset, chosen by find_ram_offset, then
> > at cirrus_bank_base, when map_linear_vram_bank is called.
> 
> Okay.  So we will need to hook this differently from the memory API.
> 
> There are two places we can hook:
> - memory_region_init_ram() - similar to qemu_ram_alloc() - at region
> construction time
> - MemoryListener::region_add() - called the first time the region is
> made visible, probably not what we want

memory_region_init_ram seems to be the right place to me


> > > > So the issue is that the videoram appears to qemu as part of the
> > > > physical memory of the guest at an unknown address.
> > > >
> > > > The proposal of introducing early_savevm would easily solve this last
> > > > problem: letting us know where the videoram is. The other problem, the
> > > > fact that under Xen the videoram would be already allocated while under
> > > > native it would not, remains unsolved. 
> > > > We cannot simply allocate the videoram twice because the operation
> > > > would fail (Xen would realize that we are trying to allocate more memory
> > > > than it we are supposed to, returning an error).
> > > > However, once we know where the videoram is, we could probably figure out
> > > > a smart (see hacky) way to avoid allocating it twice without changes to
> > > > the cirrus code.
> > > 
> > > I'm missing some context.  Can you please explain in more detail?
> > > Note that with the memory API changes, ram addresses are going away. 
> > > There will not be a linear space for guest RAM.  We'll have
> > > (MemoryRegion *, offset) pairs that will be mapped into discontiguous
> > > guest physical address ranges (perhaps with overlaps).
> >
> >
> > This is how memory is currently allocated and mapped in qemu on xen:
> >
> > - qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for
> > the guest, the memory is added to the guest p2m (physical to machine
> > translation table) at the given guest physical address
> > (new_block->offset, as chosen by find_ram_offset);
> >
> > - qemu_get_ram_ptr uses the xen mapcache to map guest physical address
> > ranges into qemu's address space, so that qemu can read/write guest
> > memory;
> >
> > - xen_set_memory, called by the memory_listener interface, effectively
> > moves a guest physical memory address range from one address to another.
> > So the memory that was initially allocated at new_block->offset, as
> > chosen by find_ram_offset, is going to be moved to a new destination,
> > section->offset_within_address_space.
> 
> So, where qemu has two different address spaces (ram_addr_t and guest
> physical addresses), Xen has just one, and any time the translation
> between the two changes, you have to move memory around.

Yes


> > So the videoram lifecycle is the following:
> >
> > - qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end
> >   of the physmap;
> >
> > - qemu_get_ram_ptr maps the videoram into qemu's address space;
> >
> > - xen_set_memory moves the videoram to cirrus_bank_base;
> >
> >
> >
> > Now let's introduce save/restore into the picture: the videoram is part
> > of the guest's memory from the hypervisor POV, so xen will take care of
> > saving and restoring it as part of the normal guest memory, out of
> > qemu's control.
> > At restore time, we know that the videoram is already allocated and
> > mapped somewhere in the guest physical address space: it could be
> > cirrus_bank_base, which we don't know yet, or the initial
> > new_block->offset.
> > A second videoram allocation by qemu_ram_alloc_from_ptr will fail
> > because of memory constraints enforced by the hypervisor. Trying to map
> > the already allocated videoram into qemu's address space is not easy
> > because we don't know where it is yet (keep in mind that machine->init
> > is called before the machine restore functions).
> >
> > The "solution" I am proposing is introducing an early_savevm set of
> > save/restore functions so that at restore time we can get to know at
> > what address the videoram is mapped into the guest address space. Once we
> > know the address we can remap it into qemu's address space and/or move it
> > to another guest physical address.
> 
> Why can we not simply track it?  For every MemoryRegion, have a field
> called xen_address which tracks its location in the Xen address space
> (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> xen_address would be maintained by callbacks called from the memory API
> into xen-all.c.

Nice and simple, I like it.
However we would still need an early_savevm mechanism to save and restore the
MemoryRegions, unless they already gets saved and restored somehow?
Maybe saving and restoring the list of MemoryRegions could be useful for
the generic case too?


> > The problem of avoiding a second allocation remains, but could be
> > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> > called "vga.vram" at restore time, and use the reference to the already
> > allocated videoram instead.
> 
> Hacky

Yes :/


> The allocation is not driven by qemu then?

At restore time, it is not.


> For the long term I suggest making qemu control the allocations (perhaps
> by rpcing dom0); otherwise how can you do memory hotplug or PCI cards
> with RAM (like ivshmem)?

It is only the videoram (well, everything allocated with
qemu_ram_alloc_from_ptr actually) and only at restore time, because
the memory in question is being considered normal guest memory and
therefore it is saved and restored by the hypervisor.
Otherwise Qemu is the one that triggers these allocations, so there are
no issues with memory hotplug and pci passthrough.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 13:18:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 13:18:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RinCi-0005Bm-8P; Thu, 05 Jan 2012 13:18:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RinCg-0005BM-Jc
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:17:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325769472!9871108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24454 invoked from network); 5 Jan 2012 13:17:52 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 13:17:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9835106"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 13:17:51 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 13:17:51 +0000
Date: Thu, 5 Jan 2012 13:17:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F059C8C.2030303@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051303350.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 02:30 PM, Stefano Stabellini wrote:
> > > >
> > > > I cannot see how this is going to fix the save/restore issue we are
> > > > trying to solve.
> > > > The problem, unfortunately very complex, is that at restore time the
> > > > videoram is already allocated at the physical address it was mapped
> > > > before the save operation. If it was not mapped, it is at the end of the
> > > > physical memory of the guest (where qemu_ram_alloc_from_ptr decides to
> > > > allocate it).
> > > 
> > > Sorry, I don't follow, please be specific as to which type of address
> > > you're referring to:
> > > 
> > > ram_addr?
> > > physical address (as seen by guest - but if it is not mapped, what does
> > > your last sentence mean?)
> > > something else?
> >
> > ram_addr_t as returned by qemu_ram_alloc_from_ptr.
> >
> > In fact on xen qemu_ram_alloc_from_ptr asks the hypervisor to add
> > the specified amount of memory to the guest physmap at
> > new_block->offset. So in a way the videoram is always visible by the
> > guest, initially at new_block->offset, chosen by find_ram_offset, then
> > at cirrus_bank_base, when map_linear_vram_bank is called.
> 
> Okay.  So we will need to hook this differently from the memory API.
> 
> There are two places we can hook:
> - memory_region_init_ram() - similar to qemu_ram_alloc() - at region
> construction time
> - MemoryListener::region_add() - called the first time the region is
> made visible, probably not what we want

memory_region_init_ram seems to be the right place to me


> > > > So the issue is that the videoram appears to qemu as part of the
> > > > physical memory of the guest at an unknown address.
> > > >
> > > > The proposal of introducing early_savevm would easily solve this last
> > > > problem: letting us know where the videoram is. The other problem, the
> > > > fact that under Xen the videoram would be already allocated while under
> > > > native it would not, remains unsolved. 
> > > > We cannot simply allocate the videoram twice because the operation
> > > > would fail (Xen would realize that we are trying to allocate more memory
> > > > than it we are supposed to, returning an error).
> > > > However, once we know where the videoram is, we could probably figure out
> > > > a smart (see hacky) way to avoid allocating it twice without changes to
> > > > the cirrus code.
> > > 
> > > I'm missing some context.  Can you please explain in more detail?
> > > Note that with the memory API changes, ram addresses are going away. 
> > > There will not be a linear space for guest RAM.  We'll have
> > > (MemoryRegion *, offset) pairs that will be mapped into discontiguous
> > > guest physical address ranges (perhaps with overlaps).
> >
> >
> > This is how memory is currently allocated and mapped in qemu on xen:
> >
> > - qemu_ram_alloc_from_ptr asks the hypervisor to allocate memory for
> > the guest, the memory is added to the guest p2m (physical to machine
> > translation table) at the given guest physical address
> > (new_block->offset, as chosen by find_ram_offset);
> >
> > - qemu_get_ram_ptr uses the xen mapcache to map guest physical address
> > ranges into qemu's address space, so that qemu can read/write guest
> > memory;
> >
> > - xen_set_memory, called by the memory_listener interface, effectively
> > moves a guest physical memory address range from one address to another.
> > So the memory that was initially allocated at new_block->offset, as
> > chosen by find_ram_offset, is going to be moved to a new destination,
> > section->offset_within_address_space.
> 
> So, where qemu has two different address spaces (ram_addr_t and guest
> physical addresses), Xen has just one, and any time the translation
> between the two changes, you have to move memory around.

Yes


> > So the videoram lifecycle is the following:
> >
> > - qemu_ram_alloc_from_ptr allocates the videoram and adds it to the end
> >   of the physmap;
> >
> > - qemu_get_ram_ptr maps the videoram into qemu's address space;
> >
> > - xen_set_memory moves the videoram to cirrus_bank_base;
> >
> >
> >
> > Now let's introduce save/restore into the picture: the videoram is part
> > of the guest's memory from the hypervisor POV, so xen will take care of
> > saving and restoring it as part of the normal guest memory, out of
> > qemu's control.
> > At restore time, we know that the videoram is already allocated and
> > mapped somewhere in the guest physical address space: it could be
> > cirrus_bank_base, which we don't know yet, or the initial
> > new_block->offset.
> > A second videoram allocation by qemu_ram_alloc_from_ptr will fail
> > because of memory constraints enforced by the hypervisor. Trying to map
> > the already allocated videoram into qemu's address space is not easy
> > because we don't know where it is yet (keep in mind that machine->init
> > is called before the machine restore functions).
> >
> > The "solution" I am proposing is introducing an early_savevm set of
> > save/restore functions so that at restore time we can get to know at
> > what address the videoram is mapped into the guest address space. Once we
> > know the address we can remap it into qemu's address space and/or move it
> > to another guest physical address.
> 
> Why can we not simply track it?  For every MemoryRegion, have a field
> called xen_address which tracks its location in the Xen address space
> (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> xen_address would be maintained by callbacks called from the memory API
> into xen-all.c.

Nice and simple, I like it.
However we would still need an early_savevm mechanism to save and restore the
MemoryRegions, unless they already gets saved and restored somehow?
Maybe saving and restoring the list of MemoryRegions could be useful for
the generic case too?


> > The problem of avoiding a second allocation remains, but could be
> > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> > called "vga.vram" at restore time, and use the reference to the already
> > allocated videoram instead.
> 
> Hacky

Yes :/


> The allocation is not driven by qemu then?

At restore time, it is not.


> For the long term I suggest making qemu control the allocations (perhaps
> by rpcing dom0); otherwise how can you do memory hotplug or PCI cards
> with RAM (like ivshmem)?

It is only the videoram (well, everything allocated with
qemu_ram_alloc_from_ptr actually) and only at restore time, because
the memory in question is being considered normal guest memory and
therefore it is saved and restored by the hypervisor.
Otherwise Qemu is the one that triggers these allocations, so there are
no issues with memory hotplug and pci passthrough.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 13:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 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 1RinEA-0005JU-Ne; Thu, 05 Jan 2012 13:19:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RinE9-0005Ix-9q
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:19:29 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325769562!9711454!1
X-Originating-IP: [77.238.189.207]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1262 invoked from network); 5 Jan 2012 13:19:22 -0000
Received: from nm5-vm0.bullet.mail.ird.yahoo.com (HELO
	nm5-vm0.bullet.mail.ird.yahoo.com) (77.238.189.207)
	by server-6.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 13:19:22 -0000
Received: from [77.238.189.49] by nm5.bullet.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:19:22 -0000
Received: from [212.82.108.254] by tm2.bullet.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:19:22 -0000
Received: from [127.0.0.1] by omp1019.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:19:22 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 525635.67605.bm@omp1019.mail.ird.yahoo.com
Received: (qmail 89800 invoked by uid 60001); 5 Jan 2012 13:19:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325769562; bh=ExW2NtgnTZcAy0MypmYK3L1m/UJEKcVRR/yqFcb599A=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=Cul8dCW4U+8i+mFuKEXBddKb0eFju6Nybe6vLI7xOMetX7yHou4OqZn0oRCMSzeB9qEAkkO85VpSGd3y4ylqkP5vBLqVGM+LGRRUPUjPIP0gSJFWIRfKkrb6njLlK7u0mm73gtqKhk8I3rOw8GSX5Li0T7U3SukywpSwunMbVyM=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=Bz/qAP/WeLlQfcde6rmEE5LwzxlLD8/7fYVZJce0qrJZ1zhTYrOI0O2NbduLDG6zM/pR9AaMplLDAtGwSUBLJ0eLV2EaDQyjDaR67ZcIjOkI09oUCgw0fuEVfiG3/vbKQhAQfCzSPDJAza1ySpvVW31aeRTquzD8DmY5kLgp2+Y=;
X-YMail-OSG: BtGDdJMVM1kVH2h1D1Rg85v2Yc5BtmJFIA3KBkLK9MzZ70l
	T79xHgW5WP8YcsBcJ6HBSs2sNCpm51f48gOi3r_L9ua8yVep5XNEVS9o5oUm
	dW8kZxKGrLdpCPiEj_DiK.8T9mdbzUsunbeIy3eIbVDNIxloSE6nYEdLGcQ3
	2vV1fCYMcYu0VW7TcmWbbh48GDVuuUMWssQeJCcppt7.Q2bdriwHnMusSc7a
	ARBuAVo9hzhTi5CKEe9WOR1I_fXIh.Oj2rub2VFLs9PXz4Gzh3YPKA.5UfR5
	PDV8LfhlFmpae6u2KBGdmsiIECGtV_1KQDin9iAwxFkTLLWrjxtTtpHN6jOA
	a8HfZFgjp05MZQjr5TWAc2HhECBYdMZIAv0WCEPk23bWuutfdPOdk6SgBf3i
	dYhbS67KuVZMStIljTbrZBxDehkoP1.6I3hgHfn2MT..qtJAkAPaV7IRJOx0
	xdHaAS.i0QxAKZjnu_YoHLUHv2YwhvqEPKA5xwMnB.x.j.hY7nOq3mDoh8V9
	g9zmsAYsLjC8BpCpBqQGbuaFuk9ECMAoJw4rAsNvr7Gh53vh2O0d._xMqLRe
	c0HAHjkcKsW956mGEe4rC1w--
Received: from [195.167.237.98] by web29802.mail.ird.yahoo.com via HTTP;
	Thu, 05 Jan 2012 13:19:22 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
Message-ID: <1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Thu, 5 Jan 2012 13:19:22 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>,
	Wei Huang <wei.huang2@amd.com>
In-Reply-To: <20120104194343.GT12984@reaktio.net>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
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="===============0818080663760834201=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0818080663760834201==
Content-Type: multipart/alternative; boundary="478945831-1668570713-1325769562=:89445"

--478945831-1668570713-1325769562=:89445
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi=0A=0AI tryied to maintain the patches for Xen 4.2=A0 since a few month=
.=0A=0APlease have a look http://www.davidgis.fr/blog/index.php?2011/12/07/=
860-xen-42unstable-patches-for-vga-pass-through=0A=0AOnce a week, I try to =
test the patches.=0A=0ALet me know if I can contribute.=0A=0ADavid=0A=0A=0A=
________________________________=0A De=A0: Pasi K=E4rkk=E4inen <pasik@iki.f=
i>=0A=C0=A0: Wei Huang <wei.huang2@amd.com> =0ACc=A0: xen-devel <xen-devel@=
lists.xensource.com>; Keir Fraser <keir@xen.org>; Ian Campbell <Ian.Campbel=
l@citrix.com>; Tim Deegan <tim@xen.org>; Ian Jackson <Ian.Jackson@eu.citrix=
.com>; Stefano Stabellini <stefano.stabellini@citrix.com>; Jan Beulich <JBe=
ulich@suse.com> =0AEnvoy=E9 le : Mercredi 4 Janvier 2012 20h43=0AObjet=A0: =
Re: [Xen-devel] RFC: Still TODO for 4.2?=0A =0AOn Wed, Jan 04, 2012 at 01:2=
1:46PM -0600, Wei Huang wrote:=0A>>>=0A>>> Has anybody got anything else? I=
'm sure I've missed stuff. Are there any=0A>>> must haves e.g. in the pagin=
g/sharing spaces?=0A>>>=0A>> - What's the status of Nested Hardware Virtual=
ization?=0A>> I remember some email saying Intel vmx-on-vmx has some perfor=
mance issues,=0A>> and amd svm-on-svm works better..=0A>>=0A>>=0A>> - Also =
there's a bunch of VGA passthru related patches,=0A>> that I once volunteer=
ed to collect/rebase/cleanup/repost myself,=0A>> but I still haven't had ti=
me for that :(=0A> Since there were quite a lot of interest on this subject=
, should we=A0 =0A> document it in a separate wiki for working combinations=
 (like=A0 =0A> hypervisor, dom0, gfx card, driver version, tricks, etc)?=0A=
>=0A=0AI actually once started writing down that kind of stuff:=0Ahttp://wi=
ki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html=0A=0AFeel free to c=
ontribute :)=0A=0AThere's also:=0Ahttp://wiki.xen.org/xenwiki/XenVGAPassthr=
ough=0A=0A=0A-- Pasi=0A=0A=0A______________________________________________=
_=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.x=
ensource.com/xen-devel
--478945831-1668570713-1325769562=:89445
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>Pasi</span=
></div><div><br><span></span></div><div><span>I tryied to maintain the patc=
hes for Xen 4.2&nbsp; since a few month.</span></div><div><br><span></span>=
</div><div><span>Please have a look http://www.davidgis.fr/blog/index.php?2=
011/12/07/860-xen-42unstable-patches-for-vga-pass-through</span></div><div>=
<br><span></span></div><div><span>Once a week, I try to test the patches.</=
span></div><div><br></div><div>Let me know if I can contribute.</div><div><=
br></div><div>David<br><span></span></div><div style=3D"font-family: times =
new roman, new york, times, serif; font-size: 12pt;"> <div style=3D"font-fa=
mily: times new roman, new york, times, serif; font-size: 12pt;"> <font siz=
e=3D"2" face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-weight:bold=
;">De&nbsp;:</span></b> Pasi K=E4rkk=E4inen &lt;pasik@iki.fi&gt;<br> <b><sp=
an
 style=3D"font-weight: bold;">=C0&nbsp;:</span></b> Wei Huang &lt;wei.huang=
2@amd.com&gt; <br><b><span style=3D"font-weight: bold;">Cc&nbsp;:</span></b=
> xen-devel &lt;xen-devel@lists.xensource.com&gt;; Keir Fraser &lt;keir@xen=
.org&gt;; Ian Campbell &lt;Ian.Campbell@citrix.com&gt;; Tim Deegan &lt;tim@=
xen.org&gt;; Ian Jackson &lt;Ian.Jackson@eu.citrix.com&gt;; Stefano Stabell=
ini &lt;stefano.stabellini@citrix.com&gt;; Jan Beulich &lt;JBeulich@suse.co=
m&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span></b> M=
ercredi 4 Janvier 2012 20h43<br> <b><span style=3D"font-weight: bold;">Obje=
t&nbsp;:</span></b> Re: [Xen-devel] RFC: Still TODO for 4.2?<br> </font> <b=
r>On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:<br>&gt;&gt;&gt=
;<br>&gt;&gt;&gt; Has anybody got anything else? I'm sure I've missed stuff=
. Are there any<br>&gt;&gt;&gt; must haves e.g. in the paging/sharing space=
s?<br>&gt;&gt;&gt;<br>&gt;&gt; - What's the status of Nested Hardware
 Virtualization?<br>&gt;&gt; I remember some email saying Intel vmx-on-vmx =
has some performance issues,<br>&gt;&gt; and amd svm-on-svm works better..<=
br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; - Also there's a bunch of VGA passthru =
related patches,<br>&gt;&gt; that I once volunteered to collect/rebase/clea=
nup/repost myself,<br>&gt;&gt; but I still haven't had time for that :(<br>=
&gt; Since there were quite a lot of interest on this subject, should we&nb=
sp; <br>&gt; document it in a separate wiki for working combinations (like&=
nbsp; <br>&gt; hypervisor, dom0, gfx card, driver version, tricks, etc)?<br=
>&gt;<br><br>I actually once started writing down that kind of stuff:<br><a=
 href=3D"http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html" =
target=3D"_blank">http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapte=
rs.html</a><br><br>Feel free to contribute :)<br><br>There's also:<br><a hr=
ef=3D"http://wiki.xen.org/xenwiki/XenVGAPassthrough"
 target=3D"_blank">http://wiki.xen.org/xenwiki/XenVGAPassthrough</a><br><br=
><br>-- Pasi<br><br><br>_______________________________________________<br>=
Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-devel@lists.xensource.co=
m" 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"_blan=
k">http://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  </di=
v></body></html>
--478945831-1668570713-1325769562=:89445--


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

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

--===============0818080663760834201==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 13:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 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 1RinEA-0005JU-Ne; Thu, 05 Jan 2012 13:19:30 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RinE9-0005Ix-9q
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:19:29 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325769562!9711454!1
X-Originating-IP: [77.238.189.207]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1262 invoked from network); 5 Jan 2012 13:19:22 -0000
Received: from nm5-vm0.bullet.mail.ird.yahoo.com (HELO
	nm5-vm0.bullet.mail.ird.yahoo.com) (77.238.189.207)
	by server-6.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 13:19:22 -0000
Received: from [77.238.189.49] by nm5.bullet.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:19:22 -0000
Received: from [212.82.108.254] by tm2.bullet.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:19:22 -0000
Received: from [127.0.0.1] by omp1019.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:19:22 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 525635.67605.bm@omp1019.mail.ird.yahoo.com
Received: (qmail 89800 invoked by uid 60001); 5 Jan 2012 13:19:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325769562; bh=ExW2NtgnTZcAy0MypmYK3L1m/UJEKcVRR/yqFcb599A=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=Cul8dCW4U+8i+mFuKEXBddKb0eFju6Nybe6vLI7xOMetX7yHou4OqZn0oRCMSzeB9qEAkkO85VpSGd3y4ylqkP5vBLqVGM+LGRRUPUjPIP0gSJFWIRfKkrb6njLlK7u0mm73gtqKhk8I3rOw8GSX5Li0T7U3SukywpSwunMbVyM=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=Bz/qAP/WeLlQfcde6rmEE5LwzxlLD8/7fYVZJce0qrJZ1zhTYrOI0O2NbduLDG6zM/pR9AaMplLDAtGwSUBLJ0eLV2EaDQyjDaR67ZcIjOkI09oUCgw0fuEVfiG3/vbKQhAQfCzSPDJAza1ySpvVW31aeRTquzD8DmY5kLgp2+Y=;
X-YMail-OSG: BtGDdJMVM1kVH2h1D1Rg85v2Yc5BtmJFIA3KBkLK9MzZ70l
	T79xHgW5WP8YcsBcJ6HBSs2sNCpm51f48gOi3r_L9ua8yVep5XNEVS9o5oUm
	dW8kZxKGrLdpCPiEj_DiK.8T9mdbzUsunbeIy3eIbVDNIxloSE6nYEdLGcQ3
	2vV1fCYMcYu0VW7TcmWbbh48GDVuuUMWssQeJCcppt7.Q2bdriwHnMusSc7a
	ARBuAVo9hzhTi5CKEe9WOR1I_fXIh.Oj2rub2VFLs9PXz4Gzh3YPKA.5UfR5
	PDV8LfhlFmpae6u2KBGdmsiIECGtV_1KQDin9iAwxFkTLLWrjxtTtpHN6jOA
	a8HfZFgjp05MZQjr5TWAc2HhECBYdMZIAv0WCEPk23bWuutfdPOdk6SgBf3i
	dYhbS67KuVZMStIljTbrZBxDehkoP1.6I3hgHfn2MT..qtJAkAPaV7IRJOx0
	xdHaAS.i0QxAKZjnu_YoHLUHv2YwhvqEPKA5xwMnB.x.j.hY7nOq3mDoh8V9
	g9zmsAYsLjC8BpCpBqQGbuaFuk9ECMAoJw4rAsNvr7Gh53vh2O0d._xMqLRe
	c0HAHjkcKsW956mGEe4rC1w--
Received: from [195.167.237.98] by web29802.mail.ird.yahoo.com via HTTP;
	Thu, 05 Jan 2012 13:19:22 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
Message-ID: <1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Thu, 5 Jan 2012 13:19:22 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>,
	Wei Huang <wei.huang2@amd.com>
In-Reply-To: <20120104194343.GT12984@reaktio.net>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
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="===============0818080663760834201=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0818080663760834201==
Content-Type: multipart/alternative; boundary="478945831-1668570713-1325769562=:89445"

--478945831-1668570713-1325769562=:89445
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi=0A=0AI tryied to maintain the patches for Xen 4.2=A0 since a few month=
.=0A=0APlease have a look http://www.davidgis.fr/blog/index.php?2011/12/07/=
860-xen-42unstable-patches-for-vga-pass-through=0A=0AOnce a week, I try to =
test the patches.=0A=0ALet me know if I can contribute.=0A=0ADavid=0A=0A=0A=
________________________________=0A De=A0: Pasi K=E4rkk=E4inen <pasik@iki.f=
i>=0A=C0=A0: Wei Huang <wei.huang2@amd.com> =0ACc=A0: xen-devel <xen-devel@=
lists.xensource.com>; Keir Fraser <keir@xen.org>; Ian Campbell <Ian.Campbel=
l@citrix.com>; Tim Deegan <tim@xen.org>; Ian Jackson <Ian.Jackson@eu.citrix=
.com>; Stefano Stabellini <stefano.stabellini@citrix.com>; Jan Beulich <JBe=
ulich@suse.com> =0AEnvoy=E9 le : Mercredi 4 Janvier 2012 20h43=0AObjet=A0: =
Re: [Xen-devel] RFC: Still TODO for 4.2?=0A =0AOn Wed, Jan 04, 2012 at 01:2=
1:46PM -0600, Wei Huang wrote:=0A>>>=0A>>> Has anybody got anything else? I=
'm sure I've missed stuff. Are there any=0A>>> must haves e.g. in the pagin=
g/sharing spaces?=0A>>>=0A>> - What's the status of Nested Hardware Virtual=
ization?=0A>> I remember some email saying Intel vmx-on-vmx has some perfor=
mance issues,=0A>> and amd svm-on-svm works better..=0A>>=0A>>=0A>> - Also =
there's a bunch of VGA passthru related patches,=0A>> that I once volunteer=
ed to collect/rebase/cleanup/repost myself,=0A>> but I still haven't had ti=
me for that :(=0A> Since there were quite a lot of interest on this subject=
, should we=A0 =0A> document it in a separate wiki for working combinations=
 (like=A0 =0A> hypervisor, dom0, gfx card, driver version, tricks, etc)?=0A=
>=0A=0AI actually once started writing down that kind of stuff:=0Ahttp://wi=
ki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html=0A=0AFeel free to c=
ontribute :)=0A=0AThere's also:=0Ahttp://wiki.xen.org/xenwiki/XenVGAPassthr=
ough=0A=0A=0A-- Pasi=0A=0A=0A______________________________________________=
_=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.x=
ensource.com/xen-devel
--478945831-1668570713-1325769562=:89445
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>Pasi</span=
></div><div><br><span></span></div><div><span>I tryied to maintain the patc=
hes for Xen 4.2&nbsp; since a few month.</span></div><div><br><span></span>=
</div><div><span>Please have a look http://www.davidgis.fr/blog/index.php?2=
011/12/07/860-xen-42unstable-patches-for-vga-pass-through</span></div><div>=
<br><span></span></div><div><span>Once a week, I try to test the patches.</=
span></div><div><br></div><div>Let me know if I can contribute.</div><div><=
br></div><div>David<br><span></span></div><div style=3D"font-family: times =
new roman, new york, times, serif; font-size: 12pt;"> <div style=3D"font-fa=
mily: times new roman, new york, times, serif; font-size: 12pt;"> <font siz=
e=3D"2" face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-weight:bold=
;">De&nbsp;:</span></b> Pasi K=E4rkk=E4inen &lt;pasik@iki.fi&gt;<br> <b><sp=
an
 style=3D"font-weight: bold;">=C0&nbsp;:</span></b> Wei Huang &lt;wei.huang=
2@amd.com&gt; <br><b><span style=3D"font-weight: bold;">Cc&nbsp;:</span></b=
> xen-devel &lt;xen-devel@lists.xensource.com&gt;; Keir Fraser &lt;keir@xen=
.org&gt;; Ian Campbell &lt;Ian.Campbell@citrix.com&gt;; Tim Deegan &lt;tim@=
xen.org&gt;; Ian Jackson &lt;Ian.Jackson@eu.citrix.com&gt;; Stefano Stabell=
ini &lt;stefano.stabellini@citrix.com&gt;; Jan Beulich &lt;JBeulich@suse.co=
m&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span></b> M=
ercredi 4 Janvier 2012 20h43<br> <b><span style=3D"font-weight: bold;">Obje=
t&nbsp;:</span></b> Re: [Xen-devel] RFC: Still TODO for 4.2?<br> </font> <b=
r>On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:<br>&gt;&gt;&gt=
;<br>&gt;&gt;&gt; Has anybody got anything else? I'm sure I've missed stuff=
. Are there any<br>&gt;&gt;&gt; must haves e.g. in the paging/sharing space=
s?<br>&gt;&gt;&gt;<br>&gt;&gt; - What's the status of Nested Hardware
 Virtualization?<br>&gt;&gt; I remember some email saying Intel vmx-on-vmx =
has some performance issues,<br>&gt;&gt; and amd svm-on-svm works better..<=
br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; - Also there's a bunch of VGA passthru =
related patches,<br>&gt;&gt; that I once volunteered to collect/rebase/clea=
nup/repost myself,<br>&gt;&gt; but I still haven't had time for that :(<br>=
&gt; Since there were quite a lot of interest on this subject, should we&nb=
sp; <br>&gt; document it in a separate wiki for working combinations (like&=
nbsp; <br>&gt; hypervisor, dom0, gfx card, driver version, tricks, etc)?<br=
>&gt;<br><br>I actually once started writing down that kind of stuff:<br><a=
 href=3D"http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html" =
target=3D"_blank">http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapte=
rs.html</a><br><br>Feel free to contribute :)<br><br>There's also:<br><a hr=
ef=3D"http://wiki.xen.org/xenwiki/XenVGAPassthrough"
 target=3D"_blank">http://wiki.xen.org/xenwiki/XenVGAPassthrough</a><br><br=
><br>-- Pasi<br><br><br>_______________________________________________<br>=
Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-devel@lists.xensource.co=
m" 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"_blan=
k">http://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  </di=
v></body></html>
--478945831-1668570713-1325769562=:89445--


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

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

--===============0818080663760834201==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 13:25:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 13: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 1RinJl-0005bi-IU; Thu, 05 Jan 2012 13:25:17 +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 1RinJk-0005bQ-Nj
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:25:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325769910!9710041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20436 invoked from network); 5 Jan 2012 13:25:10 -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;
	5 Jan 2012 13:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9835384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 13:25: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, 5 Jan 2012
	13:25:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David TECHER <davidtecher@yahoo.fr>
Date: Thu, 5 Jan 2012 13:25:09 +0000
In-Reply-To: <1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
	<1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325769910.25206.373.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Wei Huang <wei.huang2@amd.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDEyLTAxLTA1IGF0IDEzOjE5ICswMDAwLCBEYXZpZCBURUNIRVIgd3JvdGU6Cj4g
UGFzaQo+IAo+IAo+IEkgdHJ5aWVkIHRvIG1haW50YWluIHRoZSBwYXRjaGVzIGZvciBYZW4gNC4y
ICBzaW5jZSBhIGZldyBtb250aC4KPiAKPiAKPiBQbGVhc2UgaGF2ZSBhIGxvb2sKPiBodHRwOi8v
d3d3LmRhdmlkZ2lzLmZyL2Jsb2cvaW5kZXgucGhwPzIwMTEvMTIvMDcvODYwLXhlbi00MnVuc3Rh
YmxlLXBhdGNoZXMtZm9yLXZnYS1wYXNzLXRocm91Z2gKClBsZWFzZSBjYW4geW91IHBvc3QgdGhl
c2UgcGF0Y2hlcywgYWdhaW5zdCB0aGUgdGlwIG9mIHhlbi11bnN0YWJsZSwgd2l0aAphIGNoYW5n
ZWxvZyBldGMgYXMgZGVzY3JpYmVkIGluCmh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9TdWJtaXR0
aW5nWGVuUGF0Y2hlcyB0byB4ZW4tZGV2ZWwuCgpUaGVuIHdlIGNhbiBsb29rIGF0IGFjY2VwdGlu
ZyB0aGVtIGluIHRvIHRoZSB0cmVlIGFuZCB5b3UgY2FuIHN0b3AKbmVlZGluZyB0byBtYWludGFp
biB0aGVtIGxpa2UgdGhpcy4gT3IgaXMgdGhlcmUgc29tZSByZWFzb24gdGhlc2UgY2FuJ3QKYmUg
c3VibWl0dGVkPwoKSWFuLgoKPiAKPiAKPiBPbmNlIGEgd2VlaywgSSB0cnkgdG8gdGVzdCB0aGUg
cGF0Y2hlcy4KPiAKPiAKPiBMZXQgbWUga25vdyBpZiBJIGNhbiBjb250cmlidXRlLgo+IAo+IAo+
IERhdmlkCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IERlIDogUGFzaSBLw6Rya2vDpGluZW4gPHBh
c2lrQGlraS5maT4KPiDDgCA6IFdlaSBIdWFuZyA8d2VpLmh1YW5nMkBhbWQuY29tPiAKPiBDYyA6
IHhlbi1kZXZlbCA8eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20+OyBLZWlyIEZyYXNlcgo+
IDxrZWlyQHhlbi5vcmc+OyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjsg
VGltIERlZWdhbgo+IDx0aW1AeGVuLm9yZz47IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5j
aXRyaXguY29tPjsgU3RlZmFubwo+IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBjaXRy
aXguY29tPjsgSmFuIEJldWxpY2gKPiA8SkJldWxpY2hAc3VzZS5jb20+IAo+IEVudm95w6kgbGUg
OiBNZXJjcmVkaSA0IEphbnZpZXIgMjAxMiAyMGg0Mwo+IE9iamV0IDogUmU6IFtYZW4tZGV2ZWxd
IFJGQzogU3RpbGwgVE9ETyBmb3IgNC4yPwo+IAo+IE9uIFdlZCwgSmFuIDA0LCAyMDEyIGF0IDAx
OjIxOjQ2UE0gLTA2MDAsIFdlaSBIdWFuZyB3cm90ZToKPiA+Pj4KPiA+Pj4gSGFzIGFueWJvZHkg
Z290IGFueXRoaW5nIGVsc2U/IEknbSBzdXJlIEkndmUgbWlzc2VkIHN0dWZmLiBBcmUKPiB0aGVy
ZSBhbnkKPiA+Pj4gbXVzdCBoYXZlcyBlLmcuIGluIHRoZSBwYWdpbmcvc2hhcmluZyBzcGFjZXM/
Cj4gPj4+Cj4gPj4gLSBXaGF0J3MgdGhlIHN0YXR1cyBvZiBOZXN0ZWQgSGFyZHdhcmUgVmlydHVh
bGl6YXRpb24/Cj4gPj4gSSByZW1lbWJlciBzb21lIGVtYWlsIHNheWluZyBJbnRlbCB2bXgtb24t
dm14IGhhcyBzb21lIHBlcmZvcm1hbmNlCj4gaXNzdWVzLAo+ID4+IGFuZCBhbWQgc3ZtLW9uLXN2
bSB3b3JrcyBiZXR0ZXIuLgo+ID4+Cj4gPj4KPiA+PiAtIEFsc28gdGhlcmUncyBhIGJ1bmNoIG9m
IFZHQSBwYXNzdGhydSByZWxhdGVkIHBhdGNoZXMsCj4gPj4gdGhhdCBJIG9uY2Ugdm9sdW50ZWVy
ZWQgdG8gY29sbGVjdC9yZWJhc2UvY2xlYW51cC9yZXBvc3QgbXlzZWxmLAo+ID4+IGJ1dCBJIHN0
aWxsIGhhdmVuJ3QgaGFkIHRpbWUgZm9yIHRoYXQgOigKPiA+IFNpbmNlIHRoZXJlIHdlcmUgcXVp
dGUgYSBsb3Qgb2YgaW50ZXJlc3Qgb24gdGhpcyBzdWJqZWN0LCBzaG91bGQKPiB3ZSAgCj4gPiBk
b2N1bWVudCBpdCBpbiBhIHNlcGFyYXRlIHdpa2kgZm9yIHdvcmtpbmcgY29tYmluYXRpb25zIChs
aWtlICAKPiA+IGh5cGVydmlzb3IsIGRvbTAsIGdmeCBjYXJkLCBkcml2ZXIgdmVyc2lvbiwgdHJp
Y2tzLCBldGMpPwo+ID4KPiAKPiBJIGFjdHVhbGx5IG9uY2Ugc3RhcnRlZCB3cml0aW5nIGRvd24g
dGhhdCBraW5kIG9mIHN0dWZmOgo+IGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9YZW5WR0FQ
YXNzdGhyb3VnaFRlc3RlZEFkYXB0ZXJzLmh0bWwKPiAKPiBGZWVsIGZyZWUgdG8gY29udHJpYnV0
ZSA6KQo+IAo+IFRoZXJlJ3MgYWxzbzoKPiBodHRwOi8vd2lraS54ZW4ub3JnL3hlbndpa2kvWGVu
VkdBUGFzc3Rocm91Z2gKPiAKPiAKPiAtLSBQYXNpCj4gCj4gCj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4g
WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwKPiAKPiAKPiAKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Jan 05 13:25:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 13: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 1RinJl-0005bi-IU; Thu, 05 Jan 2012 13:25:17 +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 1RinJk-0005bQ-Nj
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:25:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325769910!9710041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20436 invoked from network); 5 Jan 2012 13:25:10 -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;
	5 Jan 2012 13:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9835384"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 13:25: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, 5 Jan 2012
	13:25:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David TECHER <davidtecher@yahoo.fr>
Date: Thu, 5 Jan 2012 13:25:09 +0000
In-Reply-To: <1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
	<1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325769910.25206.373.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Wei Huang <wei.huang2@amd.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDEyLTAxLTA1IGF0IDEzOjE5ICswMDAwLCBEYXZpZCBURUNIRVIgd3JvdGU6Cj4g
UGFzaQo+IAo+IAo+IEkgdHJ5aWVkIHRvIG1haW50YWluIHRoZSBwYXRjaGVzIGZvciBYZW4gNC4y
ICBzaW5jZSBhIGZldyBtb250aC4KPiAKPiAKPiBQbGVhc2UgaGF2ZSBhIGxvb2sKPiBodHRwOi8v
d3d3LmRhdmlkZ2lzLmZyL2Jsb2cvaW5kZXgucGhwPzIwMTEvMTIvMDcvODYwLXhlbi00MnVuc3Rh
YmxlLXBhdGNoZXMtZm9yLXZnYS1wYXNzLXRocm91Z2gKClBsZWFzZSBjYW4geW91IHBvc3QgdGhl
c2UgcGF0Y2hlcywgYWdhaW5zdCB0aGUgdGlwIG9mIHhlbi11bnN0YWJsZSwgd2l0aAphIGNoYW5n
ZWxvZyBldGMgYXMgZGVzY3JpYmVkIGluCmh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9TdWJtaXR0
aW5nWGVuUGF0Y2hlcyB0byB4ZW4tZGV2ZWwuCgpUaGVuIHdlIGNhbiBsb29rIGF0IGFjY2VwdGlu
ZyB0aGVtIGluIHRvIHRoZSB0cmVlIGFuZCB5b3UgY2FuIHN0b3AKbmVlZGluZyB0byBtYWludGFp
biB0aGVtIGxpa2UgdGhpcy4gT3IgaXMgdGhlcmUgc29tZSByZWFzb24gdGhlc2UgY2FuJ3QKYmUg
c3VibWl0dGVkPwoKSWFuLgoKPiAKPiAKPiBPbmNlIGEgd2VlaywgSSB0cnkgdG8gdGVzdCB0aGUg
cGF0Y2hlcy4KPiAKPiAKPiBMZXQgbWUga25vdyBpZiBJIGNhbiBjb250cmlidXRlLgo+IAo+IAo+
IERhdmlkCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IERlIDogUGFzaSBLw6Rya2vDpGluZW4gPHBh
c2lrQGlraS5maT4KPiDDgCA6IFdlaSBIdWFuZyA8d2VpLmh1YW5nMkBhbWQuY29tPiAKPiBDYyA6
IHhlbi1kZXZlbCA8eGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20+OyBLZWlyIEZyYXNlcgo+
IDxrZWlyQHhlbi5vcmc+OyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjsg
VGltIERlZWdhbgo+IDx0aW1AeGVuLm9yZz47IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5j
aXRyaXguY29tPjsgU3RlZmFubwo+IFN0YWJlbGxpbmkgPHN0ZWZhbm8uc3RhYmVsbGluaUBjaXRy
aXguY29tPjsgSmFuIEJldWxpY2gKPiA8SkJldWxpY2hAc3VzZS5jb20+IAo+IEVudm95w6kgbGUg
OiBNZXJjcmVkaSA0IEphbnZpZXIgMjAxMiAyMGg0Mwo+IE9iamV0IDogUmU6IFtYZW4tZGV2ZWxd
IFJGQzogU3RpbGwgVE9ETyBmb3IgNC4yPwo+IAo+IE9uIFdlZCwgSmFuIDA0LCAyMDEyIGF0IDAx
OjIxOjQ2UE0gLTA2MDAsIFdlaSBIdWFuZyB3cm90ZToKPiA+Pj4KPiA+Pj4gSGFzIGFueWJvZHkg
Z290IGFueXRoaW5nIGVsc2U/IEknbSBzdXJlIEkndmUgbWlzc2VkIHN0dWZmLiBBcmUKPiB0aGVy
ZSBhbnkKPiA+Pj4gbXVzdCBoYXZlcyBlLmcuIGluIHRoZSBwYWdpbmcvc2hhcmluZyBzcGFjZXM/
Cj4gPj4+Cj4gPj4gLSBXaGF0J3MgdGhlIHN0YXR1cyBvZiBOZXN0ZWQgSGFyZHdhcmUgVmlydHVh
bGl6YXRpb24/Cj4gPj4gSSByZW1lbWJlciBzb21lIGVtYWlsIHNheWluZyBJbnRlbCB2bXgtb24t
dm14IGhhcyBzb21lIHBlcmZvcm1hbmNlCj4gaXNzdWVzLAo+ID4+IGFuZCBhbWQgc3ZtLW9uLXN2
bSB3b3JrcyBiZXR0ZXIuLgo+ID4+Cj4gPj4KPiA+PiAtIEFsc28gdGhlcmUncyBhIGJ1bmNoIG9m
IFZHQSBwYXNzdGhydSByZWxhdGVkIHBhdGNoZXMsCj4gPj4gdGhhdCBJIG9uY2Ugdm9sdW50ZWVy
ZWQgdG8gY29sbGVjdC9yZWJhc2UvY2xlYW51cC9yZXBvc3QgbXlzZWxmLAo+ID4+IGJ1dCBJIHN0
aWxsIGhhdmVuJ3QgaGFkIHRpbWUgZm9yIHRoYXQgOigKPiA+IFNpbmNlIHRoZXJlIHdlcmUgcXVp
dGUgYSBsb3Qgb2YgaW50ZXJlc3Qgb24gdGhpcyBzdWJqZWN0LCBzaG91bGQKPiB3ZSAgCj4gPiBk
b2N1bWVudCBpdCBpbiBhIHNlcGFyYXRlIHdpa2kgZm9yIHdvcmtpbmcgY29tYmluYXRpb25zIChs
aWtlICAKPiA+IGh5cGVydmlzb3IsIGRvbTAsIGdmeCBjYXJkLCBkcml2ZXIgdmVyc2lvbiwgdHJp
Y2tzLCBldGMpPwo+ID4KPiAKPiBJIGFjdHVhbGx5IG9uY2Ugc3RhcnRlZCB3cml0aW5nIGRvd24g
dGhhdCBraW5kIG9mIHN0dWZmOgo+IGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9YZW5WR0FQ
YXNzdGhyb3VnaFRlc3RlZEFkYXB0ZXJzLmh0bWwKPiAKPiBGZWVsIGZyZWUgdG8gY29udHJpYnV0
ZSA6KQo+IAo+IFRoZXJlJ3MgYWxzbzoKPiBodHRwOi8vd2lraS54ZW4ub3JnL3hlbndpa2kvWGVu
VkdBUGFzc3Rocm91Z2gKPiAKPiAKPiAtLSBQYXNpCj4gCj4gCj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4g
WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwKPiAKPiAKPiAKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Jan 05 13:33:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 13:33:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RinRM-0005s7-Gw; Thu, 05 Jan 2012 13:33:08 +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 1RinRK-0005rw-MO
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:33:06 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325770379!3103434!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2900 invoked from network); 5 Jan 2012 13:33:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	5 Jan 2012 13:33:00 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q05DWtNi004201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 08:32:55 -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 q05DWqKr013334; Thu, 5 Jan 2012 08:32:53 -0500
Message-ID: <4F05A684.7000509@redhat.com>
Date: Thu, 05 Jan 2012 15:32:52 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
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 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > The "solution" I am proposing is introducing an early_savevm set of
> > > save/restore functions so that at restore time we can get to know at
> > > what address the videoram is mapped into the guest address space. Once we
> > > know the address we can remap it into qemu's address space and/or move it
> > > to another guest physical address.
> > 
> > Why can we not simply track it?  For every MemoryRegion, have a field
> > called xen_address which tracks its location in the Xen address space
> > (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> > xen_address would be maintained by callbacks called from the memory API
> > into xen-all.c.
>
> Nice and simple, I like it.
> However we would still need an early_savevm mechanism to save and restore the
> MemoryRegions, unless they already gets saved and restored somehow?

MemoryRegions are instantiated by the devices, so they should be there
(creating a MemoryRegion == calling qemu_ram_alloc() in the old days)

> Maybe saving and restoring the list of MemoryRegions could be useful for
> the generic case too?

Unneeded, since they're an integral part of the devices.  However, it
would be good to have a list of the devices so we could send that over
instead of relying on invoking qemu with the same command-line arguments
on both sides - but that's something that qom is already tackling.

> > > The problem of avoiding a second allocation remains, but could be
> > > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> > > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> > > called "vga.vram" at restore time, and use the reference to the already
> > > allocated videoram instead.
> > 
> > Hacky
>
> Yes :/

xen_register_framebuffer() is slightly less hacky.

> > The allocation is not driven by qemu then?
>
> At restore time, it is not.
>
>
> > For the long term I suggest making qemu control the allocations (perhaps
> > by rpcing dom0); otherwise how can you do memory hotplug or PCI cards
> > with RAM (like ivshmem)?
>
> It is only the videoram (well, everything allocated with
> qemu_ram_alloc_from_ptr actually) and only at restore time, because
> the memory in question is being considered normal guest memory and
> therefore it is saved and restored by the hypervisor.
> Otherwise Qemu is the one that triggers these allocations, so there are
> no issues with memory hotplug and pci passthrough.

Okay.

-- 
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 Jan 05 13:33:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 13:33:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RinRM-0005s7-Gw; Thu, 05 Jan 2012 13:33:08 +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 1RinRK-0005rw-MO
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:33:06 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325770379!3103434!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2900 invoked from network); 5 Jan 2012 13:33:00 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	5 Jan 2012 13:33:00 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q05DWtNi004201
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 08:32:55 -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 q05DWqKr013334; Thu, 5 Jan 2012 08:32:53 -0500
Message-ID: <4F05A684.7000509@redhat.com>
Date: Thu, 05 Jan 2012 15:32:52 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
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 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > The "solution" I am proposing is introducing an early_savevm set of
> > > save/restore functions so that at restore time we can get to know at
> > > what address the videoram is mapped into the guest address space. Once we
> > > know the address we can remap it into qemu's address space and/or move it
> > > to another guest physical address.
> > 
> > Why can we not simply track it?  For every MemoryRegion, have a field
> > called xen_address which tracks its location in the Xen address space
> > (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> > xen_address would be maintained by callbacks called from the memory API
> > into xen-all.c.
>
> Nice and simple, I like it.
> However we would still need an early_savevm mechanism to save and restore the
> MemoryRegions, unless they already gets saved and restored somehow?

MemoryRegions are instantiated by the devices, so they should be there
(creating a MemoryRegion == calling qemu_ram_alloc() in the old days)

> Maybe saving and restoring the list of MemoryRegions could be useful for
> the generic case too?

Unneeded, since they're an integral part of the devices.  However, it
would be good to have a list of the devices so we could send that over
instead of relying on invoking qemu with the same command-line arguments
on both sides - but that's something that qom is already tackling.

> > > The problem of avoiding a second allocation remains, but could be
> > > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> > > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> > > called "vga.vram" at restore time, and use the reference to the already
> > > allocated videoram instead.
> > 
> > Hacky
>
> Yes :/

xen_register_framebuffer() is slightly less hacky.

> > The allocation is not driven by qemu then?
>
> At restore time, it is not.
>
>
> > For the long term I suggest making qemu control the allocations (perhaps
> > by rpcing dom0); otherwise how can you do memory hotplug or PCI cards
> > with RAM (like ivshmem)?
>
> It is only the videoram (well, everything allocated with
> qemu_ram_alloc_from_ptr actually) and only at restore time, because
> the memory in question is being considered normal guest memory and
> therefore it is saved and restored by the hypervisor.
> Otherwise Qemu is the one that triggers these allocations, so there are
> no issues with memory hotplug and pci passthrough.

Okay.

-- 
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 Jan 05 13:42:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 13: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 1RinZa-00063m-N4; Thu, 05 Jan 2012 13:41:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RinZZ-00063h-Gi
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:41:37 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325770889!7894374!1
X-Originating-IP: [77.238.189.92]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31269 invoked from network); 5 Jan 2012 13:41:29 -0000
Received: from nm19-vm0.bullet.mail.ird.yahoo.com (HELO
	nm19-vm0.bullet.mail.ird.yahoo.com) (77.238.189.92)
	by server-12.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 13:41:29 -0000
Received: from [77.238.189.232] by nm19.bullet.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:41:29 -0000
Received: from [212.82.108.254] by tm13.bullet.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:41:29 -0000
Received: from [127.0.0.1] by omp1019.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:41:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 249578.87048.bm@omp1019.mail.ird.yahoo.com
Received: (qmail 57843 invoked by uid 60001); 5 Jan 2012 13:41:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325770889; bh=WePnB7gsNI3SZVQk56wFKZgP4zdvanJjFHZ2PNS6ux0=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=qQlv5C/xCwdYXt6OcJyTAzEwUFdgGBmuaZpTeIEna8/cXpxofyhh+HLGhBnSnPd3VIIMzS2u/vKHJSTICdGqH9lC7LKgFzIVppRXdf+P50QElKq0LU5Riw3AIsX5BrwUOA2S/2pnP02TjBX0MKueiLj/nijnOFL0tZA6Ws+4iTk=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=YBKHaK1J1wV2fb2iCmU0xYRt31coUAHR3ZZ9JoGY6zO0sPwrMK854ES6wehXmfCtugzXLDSqN4E7B6Vp07qMvWL4ZNCG25/ygnGgdK02ojsZov6MEg3CYIEHASBS1wA2lsGAEsFoSS0o7eOImw3Go+qXjV7e4mJpBh+9eVNHD7I=;
X-YMail-OSG: HvfTS7kVM1mGhp1jjxcyvaIVWkQo3dBwe2A.R9uLVQBT8ui
	HZyagVjh2U.yuLacqmdGrCpduXENcBV7Uc8S6C7HXMwioVWPeFZ7_B7Wqq34
	OJd5o75Q2MpUCd3AHHOe.f2s5PCK3iov3D7B9TJPPJ51SedQ22QyTpB3CIyZ
	GPwF6sKOytAILWtePMn_7pOet1nR4FEQGj0rVF6.FZI8v4782pjQFpy8G16k
	0JWbCOmfhpfkv8DbKaiIezB6fR0FDaHuePMEjlmPvivFXU_K3.hS9maM5AvA
	HUs8HIWg.t2NFVuOrs6cF8sPXycDmT97JwfOTpWVe68_svduGFU_schByJRK
	gb4Hv9h9rCljlaXL8jRv.ralLwkBgQPU3pXS8ypx_pmChECdi6Mwfz1jmcvj
	D5p0bK8MKfD28FwAQfRKk5sOl4TXi9X8CyZsw9lbHfEefN_66Ey6nmsLGAPb
	F_7_JtG606slfZ9jNByysyzMj6oKmrUA.Eql1Cqv_Wokem1FBAdwICTzNT9F
	OALcDEgNzWARDWS4mkbml1qA7cer1.Lyff1enXudIOcR5cgtknFk60WTcXuz
	Cu0KQzU01uPiqd5cOby06pLD.uDKd3g--
Received: from [195.167.237.98] by web29803.mail.ird.yahoo.com via HTTP;
	Thu, 05 Jan 2012 13:41:28 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
	<1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<1325769910.25206.373.camel@zakaz.uk.xensource.com>
Message-ID: <1325770888.57253.YahooMailNeo@web29803.mail.ird.yahoo.com>
Date: Thu, 5 Jan 2012 13:41:28 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1325769910.25206.373.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Huang <wei.huang2@amd.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
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="===============1616093974050320331=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1616093974050320331==
Content-Type: multipart/alternative; boundary="-829503087-1082661605-1325770888=:57253"

---829503087-1082661605-1325770888=:57253
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Ian=0A=0AI will try to submit the patch tonight when I am at home (I am in =
France - C.E.T) else you can download patches at http://www.davidgis.fr/dow=
nload/xen-4.2_rev24232_gfx-passthrough-patchs.tar.bz2=0A=0A=0AFor your info=
rmation and as it is writtten in my article, I am not the author of the pat=
ches, just a simple maintainer.=0A=0AHowever tt is worth having a try for s=
ubmitting tonight=0A=0A=0AThanks.=0A=0ADavid.=0A=0A=0A=0A__________________=
______________=0A De=A0: Ian Campbell <Ian.Campbell@citrix.com>=0A=C0=A0: D=
avid TECHER <davidtecher@yahoo.fr> =0ACc=A0: xen-devel <xen-devel@lists.xen=
source.com>; Keir (Xen.org) <keir@xen.org>; Stefano Stabellini <Stefano.Sta=
bellini@eu.citrix.com>; Tim (Xen.org) <tim@xen.org>; Wei Huang <wei.huang2@=
amd.com>; Ian Jackson <Ian.Jackson@eu.citrix.com>; Jan Beulich <JBeulich@su=
se.com> =0AEnvoy=E9 le : Jeudi 5 Janvier 2012 14h25=0AObjet=A0: Re: [Xen-de=
vel] RFC: Still TODO for 4.2?=0A =0AOn Thu, 2012-01-05 at 13:19 +0000, Davi=
d TECHER wrote:=0A> Pasi=0A> =0A> =0A> I tryied to maintain the patches for=
 Xen 4.2=A0 since a few month.=0A> =0A> =0A> Please have a look=0A> http://=
www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vg=
a-pass-through=0A=0APlease can you post these patches, against the tip of x=
en-unstable, with=0Aa changelog etc as described in=0Ahttp://wiki.xen.org/w=
iki/SubmittingXenPatches to xen-devel.=0A=0AThen we can look at accepting t=
hem in to the tree and you can stop=0Aneeding to maintain them like this. O=
r is there some reason these can't=0Abe submitted?=0A=0AIan.=0A=0A> =0A> =
=0A> Once a week, I try to test the patches.=0A> =0A> =0A> Let me know if I=
 can contribute.=0A> =0A> =0A> David=0A> =0A> =0A> ________________________=
______________________________________________=0A> De : Pasi K=E4rkk=E4inen=
 <pasik@iki.fi>=0A> =C0 : Wei Huang <wei.huang2@amd.com> =0A> Cc : xen-deve=
l <xen-devel@lists.xensource.com>; Keir Fraser=0A> <keir@xen.org>; Ian Camp=
bell <Ian.Campbell@citrix.com>; Tim Deegan=0A> <tim@xen.org>; Ian Jackson <=
Ian.Jackson@eu.citrix.com>; Stefano=0A> Stabellini <stefano.stabellini@citr=
ix.com>; Jan Beulich=0A> <JBeulich@suse.com> =0A> Envoy=E9 le : Mercredi 4 =
Janvier 2012 20h43=0A> Objet : Re: [Xen-devel] RFC: Still TODO for 4.2?=0A>=
 =0A> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:=0A> >>>=0A=
> >>> Has anybody got anything else? I'm sure I've missed stuff. Are=0A> th=
ere any=0A> >>> must haves e.g. in the paging/sharing spaces?=0A> >>>=0A> >=
> - What's the status of Nested Hardware Virtualization?=0A> >> I remember =
some email saying Intel vmx-on-vmx has some performance=0A> issues,=0A> >> =
and amd svm-on-svm works better..=0A> >>=0A> >>=0A> >> - Also there's a bun=
ch of VGA passthru related patches,=0A> >> that I once volunteered to colle=
ct/rebase/cleanup/repost myself,=0A> >> but I still haven't had time for th=
at :(=0A> > Since there were quite a lot of interest on this subject, shoul=
d=0A> we=A0 =0A> > document it in a separate wiki for working combinations =
(like=A0 =0A> > hypervisor, dom0, gfx card, driver version, tricks, etc)?=
=0A> >=0A> =0A> I actually once started writing down that kind of stuff:=0A=
> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html=0A> =0A>=
 Feel free to contribute :)=0A> =0A> There's also:=0A> http://wiki.xen.org/=
xenwiki/XenVGAPassthrough=0A> =0A> =0A> -- Pasi=0A> =0A> =0A> _____________=
__________________________________=0A> Xen-devel mailing list=0A> Xen-devel=
@lists.xensource.com=0A> http://lists.xensource.com/xen-devel=0A> =0A> =0A>=
 =0A=0A=0A=0A_______________________________________________=0AXen-devel ma=
iling list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensource.com/xen=
-devel
---829503087-1082661605-1325770888=:57253
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>Ian</span>=
</div><div><br><span></span></div><div><span>I will try to submit the patch=
 tonight when I am at home (I am in France - C.E.T) else you can download p=
atches at http://www.davidgis.fr/download/xen-4.2_rev24232_gfx-passthrough-=
patchs.tar.bz2<br></span></div><div><br><span></span></div><div><span>For y=
our information and as it is writtten in my article, I am not the author of=
 the patches, just a simple maintainer.</span></div><div><br><span></span><=
/div><div><span></span><span>However tt is worth having a try for submittin=
g tonight<br></span></div><div><br><span></span></div><div><span>Thanks.</s=
pan></div><div><br><span></span></div><div><span>David.</span></div><div><b=
r></div>  <div style=3D"font-family: times new roman, new york, times, seri=
f; font-size: 12pt;"> <div style=3D"font-family: times new roman, new
 york, times, serif; font-size: 12pt;"> <font size=3D"2" face=3D"Arial"> <h=
r size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> Ia=
n Campbell &lt;Ian.Campbell@citrix.com&gt;<br> <b><span style=3D"font-weigh=
t: bold;">=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <=
br><b><span style=3D"font-weight: bold;">Cc&nbsp;:</span></b> xen-devel &lt=
;xen-devel@lists.xensource.com&gt;; Keir (Xen.org) &lt;keir@xen.org&gt;; St=
efano Stabellini &lt;Stefano.Stabellini@eu.citrix.com&gt;; Tim (Xen.org) &l=
t;tim@xen.org&gt;; Wei Huang &lt;wei.huang2@amd.com&gt;; Ian Jackson &lt;Ia=
n.Jackson@eu.citrix.com&gt;; Jan Beulich &lt;JBeulich@suse.com&gt; <br> <b>=
<span style=3D"font-weight: bold;">Envoy=E9 le :</span></b> Jeudi 5 Janvier=
 2012 14h25<br> <b><span style=3D"font-weight: bold;">Objet&nbsp;:</span></=
b> Re: [Xen-devel] RFC: Still TODO for 4.2?<br> </font> <br>On Thu, 2012-01=
-05 at 13:19 +0000, David TECHER wrote:<br>&gt; Pasi<br>&gt; <br>&gt; <br>&=
gt; I
 tryied to maintain the patches for Xen 4.2&nbsp; since a few month.<br>&gt=
; <br>&gt; <br>&gt; Please have a look<br>&gt; <a href=3D"http://www.davidg=
is.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-thr=
ough" target=3D"_blank">http://www.davidgis.fr/blog/index.php?2011/12/07/86=
0-xen-42unstable-patches-for-vga-pass-through</a><br><br>Please can you pos=
t these patches, against the tip of xen-unstable, with<br>a changelog etc a=
s described in<br><a href=3D"http://wiki.xen.org/wiki/SubmittingXenPatches"=
 target=3D"_blank">http://wiki.xen.org/wiki/SubmittingXenPatches</a> to xen=
-devel.<br><br>Then we can look at accepting them in to the tree and you ca=
n stop<br>needing to maintain them like this. Or is there some reason these=
 can't<br>be submitted?<br><br>Ian.<br><br>&gt; <br>&gt; <br>&gt; Once a we=
ek, I try to test the patches.<br>&gt; <br>&gt; <br>&gt; Let me know if I c=
an contribute.<br>&gt; <br>&gt; <br>&gt; David<br>&gt; <br>&gt; <br>&gt;
 ______________________________________________________________________<br>=
&gt; De : Pasi K=E4rkk=E4inen &lt;<a ymailto=3D"mailto:pasik@iki.fi" href=
=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt;<br>&gt; =C0 : Wei Huang &lt;<=
a ymailto=3D"mailto:wei.huang2@amd.com" href=3D"mailto:wei.huang2@amd.com">=
wei.huang2@amd.com</a>&gt; <br>&gt; Cc : xen-devel &lt;<a ymailto=3D"mailto=
:xen-devel@lists.xensource.com" href=3D"mailto:xen-devel@lists.xensource.co=
m">xen-devel@lists.xensource.com</a>&gt;; Keir Fraser<br>&gt; &lt;<a ymailt=
o=3D"mailto:keir@xen.org" href=3D"mailto:keir@xen.org">keir@xen.org</a>&gt;=
; Ian Campbell &lt;<a ymailto=3D"mailto:Ian.Campbell@citrix.com" href=3D"ma=
ilto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt;; Tim Deegan<b=
r>&gt; &lt;<a ymailto=3D"mailto:tim@xen.org" href=3D"mailto:tim@xen.org">ti=
m@xen.org</a>&gt;; Ian Jackson &lt;<a ymailto=3D"mailto:Ian.Jackson@eu.citr=
ix.com" href=3D"mailto:Ian.Jackson@eu.citrix.com">Ian.Jackson@eu.citrix.com=
</a>&gt;; Stefano<br>&gt;
 Stabellini &lt;<a ymailto=3D"mailto:stefano.stabellini@citrix.com" href=3D=
"mailto:stefano.stabellini@citrix.com">stefano.stabellini@citrix.com</a>&gt=
;; Jan Beulich<br>&gt; &lt;<a ymailto=3D"mailto:JBeulich@suse.com" href=3D"=
mailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; <br>&gt; Envoy=E9 le : =
Mercredi 4 Janvier 2012 20h43<br>&gt; Objet : Re: [Xen-devel] RFC: Still TO=
DO for 4.2?<br>&gt; <br>&gt; On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei =
Huang wrote:<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; Has anybody got anyt=
hing else? I'm sure I've missed stuff. Are<br>&gt; there any<br>&gt; &gt;&g=
t;&gt; must haves e.g. in the paging/sharing spaces?<br>&gt; &gt;&gt;&gt;<b=
r>&gt; &gt;&gt; - What's the status of Nested Hardware Virtualization?<br>&=
gt; &gt;&gt; I remember some email saying Intel vmx-on-vmx has some perform=
ance<br>&gt; issues,<br>&gt; &gt;&gt; and amd svm-on-svm works better..<br>=
&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; - Also there's a bunch of V=
GA
 passthru related patches,<br>&gt; &gt;&gt; that I once volunteered to coll=
ect/rebase/cleanup/repost myself,<br>&gt; &gt;&gt; but I still haven't had =
time for that :(<br>&gt; &gt; Since there were quite a lot of interest on t=
his subject, should<br>&gt; we&nbsp; <br>&gt; &gt; document it in a separat=
e wiki for working combinations (like&nbsp; <br>&gt; &gt; hypervisor, dom0,=
 gfx card, driver version, tricks, etc)?<br>&gt; &gt;<br>&gt; <br>&gt; I ac=
tually once started writing down that kind of stuff:<br>&gt; <a href=3D"htt=
p://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html" target=3D"_b=
lank">http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html</a><=
br>&gt; <br>&gt; Feel free to contribute :)<br>&gt; <br>&gt; There's also:<=
br>&gt; <a href=3D"http://wiki.xen.org/xenwiki/XenVGAPassthrough" target=3D=
"_blank">http://wiki.xen.org/xenwiki/XenVGAPassthrough</a><br>&gt; <br>&gt;=
 <br>&gt; -- Pasi<br>&gt; <br>&gt; <br>&gt;
 _______________________________________________<br>&gt; Xen-devel mailing =
list<br>&gt; <a ymailto=3D"mailto:Xen-devel@lists.xensource.com" href=3D"ma=
ilto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br>&g=
t; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http:=
//lists.xensource.com/xen-devel</a><br>&gt; <br>&gt; <br>&gt; <br><br><br><=
br>_______________________________________________<br>Xen-devel mailing lis=
t<br><a ymailto=3D"mailto:Xen-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.xenso=
urce.com/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
---829503087-1082661605-1325770888=:57253--


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

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

--===============1616093974050320331==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 13:42:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 13: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 1RinZa-00063m-N4; Thu, 05 Jan 2012 13:41:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RinZZ-00063h-Gi
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 13:41:37 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-12.tower-174.messagelabs.com!1325770889!7894374!1
X-Originating-IP: [77.238.189.92]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31269 invoked from network); 5 Jan 2012 13:41:29 -0000
Received: from nm19-vm0.bullet.mail.ird.yahoo.com (HELO
	nm19-vm0.bullet.mail.ird.yahoo.com) (77.238.189.92)
	by server-12.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 13:41:29 -0000
Received: from [77.238.189.232] by nm19.bullet.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:41:29 -0000
Received: from [212.82.108.254] by tm13.bullet.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:41:29 -0000
Received: from [127.0.0.1] by omp1019.mail.ird.yahoo.com with NNFMP;
	05 Jan 2012 13:41:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 249578.87048.bm@omp1019.mail.ird.yahoo.com
Received: (qmail 57843 invoked by uid 60001); 5 Jan 2012 13:41:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325770889; bh=WePnB7gsNI3SZVQk56wFKZgP4zdvanJjFHZ2PNS6ux0=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=qQlv5C/xCwdYXt6OcJyTAzEwUFdgGBmuaZpTeIEna8/cXpxofyhh+HLGhBnSnPd3VIIMzS2u/vKHJSTICdGqH9lC7LKgFzIVppRXdf+P50QElKq0LU5Riw3AIsX5BrwUOA2S/2pnP02TjBX0MKueiLj/nijnOFL0tZA6Ws+4iTk=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=YBKHaK1J1wV2fb2iCmU0xYRt31coUAHR3ZZ9JoGY6zO0sPwrMK854ES6wehXmfCtugzXLDSqN4E7B6Vp07qMvWL4ZNCG25/ygnGgdK02ojsZov6MEg3CYIEHASBS1wA2lsGAEsFoSS0o7eOImw3Go+qXjV7e4mJpBh+9eVNHD7I=;
X-YMail-OSG: HvfTS7kVM1mGhp1jjxcyvaIVWkQo3dBwe2A.R9uLVQBT8ui
	HZyagVjh2U.yuLacqmdGrCpduXENcBV7Uc8S6C7HXMwioVWPeFZ7_B7Wqq34
	OJd5o75Q2MpUCd3AHHOe.f2s5PCK3iov3D7B9TJPPJ51SedQ22QyTpB3CIyZ
	GPwF6sKOytAILWtePMn_7pOet1nR4FEQGj0rVF6.FZI8v4782pjQFpy8G16k
	0JWbCOmfhpfkv8DbKaiIezB6fR0FDaHuePMEjlmPvivFXU_K3.hS9maM5AvA
	HUs8HIWg.t2NFVuOrs6cF8sPXycDmT97JwfOTpWVe68_svduGFU_schByJRK
	gb4Hv9h9rCljlaXL8jRv.ralLwkBgQPU3pXS8ypx_pmChECdi6Mwfz1jmcvj
	D5p0bK8MKfD28FwAQfRKk5sOl4TXi9X8CyZsw9lbHfEefN_66Ey6nmsLGAPb
	F_7_JtG606slfZ9jNByysyzMj6oKmrUA.Eql1Cqv_Wokem1FBAdwICTzNT9F
	OALcDEgNzWARDWS4mkbml1qA7cer1.Lyff1enXudIOcR5cgtknFk60WTcXuz
	Cu0KQzU01uPiqd5cOby06pLD.uDKd3g--
Received: from [195.167.237.98] by web29803.mail.ird.yahoo.com via HTTP;
	Thu, 05 Jan 2012 13:41:28 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
	<1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<1325769910.25206.373.camel@zakaz.uk.xensource.com>
Message-ID: <1325770888.57253.YahooMailNeo@web29803.mail.ird.yahoo.com>
Date: Thu, 5 Jan 2012 13:41:28 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1325769910.25206.373.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Huang <wei.huang2@amd.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
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="===============1616093974050320331=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1616093974050320331==
Content-Type: multipart/alternative; boundary="-829503087-1082661605-1325770888=:57253"

---829503087-1082661605-1325770888=:57253
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Ian=0A=0AI will try to submit the patch tonight when I am at home (I am in =
France - C.E.T) else you can download patches at http://www.davidgis.fr/dow=
nload/xen-4.2_rev24232_gfx-passthrough-patchs.tar.bz2=0A=0A=0AFor your info=
rmation and as it is writtten in my article, I am not the author of the pat=
ches, just a simple maintainer.=0A=0AHowever tt is worth having a try for s=
ubmitting tonight=0A=0A=0AThanks.=0A=0ADavid.=0A=0A=0A=0A__________________=
______________=0A De=A0: Ian Campbell <Ian.Campbell@citrix.com>=0A=C0=A0: D=
avid TECHER <davidtecher@yahoo.fr> =0ACc=A0: xen-devel <xen-devel@lists.xen=
source.com>; Keir (Xen.org) <keir@xen.org>; Stefano Stabellini <Stefano.Sta=
bellini@eu.citrix.com>; Tim (Xen.org) <tim@xen.org>; Wei Huang <wei.huang2@=
amd.com>; Ian Jackson <Ian.Jackson@eu.citrix.com>; Jan Beulich <JBeulich@su=
se.com> =0AEnvoy=E9 le : Jeudi 5 Janvier 2012 14h25=0AObjet=A0: Re: [Xen-de=
vel] RFC: Still TODO for 4.2?=0A =0AOn Thu, 2012-01-05 at 13:19 +0000, Davi=
d TECHER wrote:=0A> Pasi=0A> =0A> =0A> I tryied to maintain the patches for=
 Xen 4.2=A0 since a few month.=0A> =0A> =0A> Please have a look=0A> http://=
www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vg=
a-pass-through=0A=0APlease can you post these patches, against the tip of x=
en-unstable, with=0Aa changelog etc as described in=0Ahttp://wiki.xen.org/w=
iki/SubmittingXenPatches to xen-devel.=0A=0AThen we can look at accepting t=
hem in to the tree and you can stop=0Aneeding to maintain them like this. O=
r is there some reason these can't=0Abe submitted?=0A=0AIan.=0A=0A> =0A> =
=0A> Once a week, I try to test the patches.=0A> =0A> =0A> Let me know if I=
 can contribute.=0A> =0A> =0A> David=0A> =0A> =0A> ________________________=
______________________________________________=0A> De : Pasi K=E4rkk=E4inen=
 <pasik@iki.fi>=0A> =C0 : Wei Huang <wei.huang2@amd.com> =0A> Cc : xen-deve=
l <xen-devel@lists.xensource.com>; Keir Fraser=0A> <keir@xen.org>; Ian Camp=
bell <Ian.Campbell@citrix.com>; Tim Deegan=0A> <tim@xen.org>; Ian Jackson <=
Ian.Jackson@eu.citrix.com>; Stefano=0A> Stabellini <stefano.stabellini@citr=
ix.com>; Jan Beulich=0A> <JBeulich@suse.com> =0A> Envoy=E9 le : Mercredi 4 =
Janvier 2012 20h43=0A> Objet : Re: [Xen-devel] RFC: Still TODO for 4.2?=0A>=
 =0A> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:=0A> >>>=0A=
> >>> Has anybody got anything else? I'm sure I've missed stuff. Are=0A> th=
ere any=0A> >>> must haves e.g. in the paging/sharing spaces?=0A> >>>=0A> >=
> - What's the status of Nested Hardware Virtualization?=0A> >> I remember =
some email saying Intel vmx-on-vmx has some performance=0A> issues,=0A> >> =
and amd svm-on-svm works better..=0A> >>=0A> >>=0A> >> - Also there's a bun=
ch of VGA passthru related patches,=0A> >> that I once volunteered to colle=
ct/rebase/cleanup/repost myself,=0A> >> but I still haven't had time for th=
at :(=0A> > Since there were quite a lot of interest on this subject, shoul=
d=0A> we=A0 =0A> > document it in a separate wiki for working combinations =
(like=A0 =0A> > hypervisor, dom0, gfx card, driver version, tricks, etc)?=
=0A> >=0A> =0A> I actually once started writing down that kind of stuff:=0A=
> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html=0A> =0A>=
 Feel free to contribute :)=0A> =0A> There's also:=0A> http://wiki.xen.org/=
xenwiki/XenVGAPassthrough=0A> =0A> =0A> -- Pasi=0A> =0A> =0A> _____________=
__________________________________=0A> Xen-devel mailing list=0A> Xen-devel=
@lists.xensource.com=0A> http://lists.xensource.com/xen-devel=0A> =0A> =0A>=
 =0A=0A=0A=0A_______________________________________________=0AXen-devel ma=
iling list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensource.com/xen=
-devel
---829503087-1082661605-1325770888=:57253
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>Ian</span>=
</div><div><br><span></span></div><div><span>I will try to submit the patch=
 tonight when I am at home (I am in France - C.E.T) else you can download p=
atches at http://www.davidgis.fr/download/xen-4.2_rev24232_gfx-passthrough-=
patchs.tar.bz2<br></span></div><div><br><span></span></div><div><span>For y=
our information and as it is writtten in my article, I am not the author of=
 the patches, just a simple maintainer.</span></div><div><br><span></span><=
/div><div><span></span><span>However tt is worth having a try for submittin=
g tonight<br></span></div><div><br><span></span></div><div><span>Thanks.</s=
pan></div><div><br><span></span></div><div><span>David.</span></div><div><b=
r></div>  <div style=3D"font-family: times new roman, new york, times, seri=
f; font-size: 12pt;"> <div style=3D"font-family: times new roman, new
 york, times, serif; font-size: 12pt;"> <font size=3D"2" face=3D"Arial"> <h=
r size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> Ia=
n Campbell &lt;Ian.Campbell@citrix.com&gt;<br> <b><span style=3D"font-weigh=
t: bold;">=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <=
br><b><span style=3D"font-weight: bold;">Cc&nbsp;:</span></b> xen-devel &lt=
;xen-devel@lists.xensource.com&gt;; Keir (Xen.org) &lt;keir@xen.org&gt;; St=
efano Stabellini &lt;Stefano.Stabellini@eu.citrix.com&gt;; Tim (Xen.org) &l=
t;tim@xen.org&gt;; Wei Huang &lt;wei.huang2@amd.com&gt;; Ian Jackson &lt;Ia=
n.Jackson@eu.citrix.com&gt;; Jan Beulich &lt;JBeulich@suse.com&gt; <br> <b>=
<span style=3D"font-weight: bold;">Envoy=E9 le :</span></b> Jeudi 5 Janvier=
 2012 14h25<br> <b><span style=3D"font-weight: bold;">Objet&nbsp;:</span></=
b> Re: [Xen-devel] RFC: Still TODO for 4.2?<br> </font> <br>On Thu, 2012-01=
-05 at 13:19 +0000, David TECHER wrote:<br>&gt; Pasi<br>&gt; <br>&gt; <br>&=
gt; I
 tryied to maintain the patches for Xen 4.2&nbsp; since a few month.<br>&gt=
; <br>&gt; <br>&gt; Please have a look<br>&gt; <a href=3D"http://www.davidg=
is.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-thr=
ough" target=3D"_blank">http://www.davidgis.fr/blog/index.php?2011/12/07/86=
0-xen-42unstable-patches-for-vga-pass-through</a><br><br>Please can you pos=
t these patches, against the tip of xen-unstable, with<br>a changelog etc a=
s described in<br><a href=3D"http://wiki.xen.org/wiki/SubmittingXenPatches"=
 target=3D"_blank">http://wiki.xen.org/wiki/SubmittingXenPatches</a> to xen=
-devel.<br><br>Then we can look at accepting them in to the tree and you ca=
n stop<br>needing to maintain them like this. Or is there some reason these=
 can't<br>be submitted?<br><br>Ian.<br><br>&gt; <br>&gt; <br>&gt; Once a we=
ek, I try to test the patches.<br>&gt; <br>&gt; <br>&gt; Let me know if I c=
an contribute.<br>&gt; <br>&gt; <br>&gt; David<br>&gt; <br>&gt; <br>&gt;
 ______________________________________________________________________<br>=
&gt; De : Pasi K=E4rkk=E4inen &lt;<a ymailto=3D"mailto:pasik@iki.fi" href=
=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt;<br>&gt; =C0 : Wei Huang &lt;<=
a ymailto=3D"mailto:wei.huang2@amd.com" href=3D"mailto:wei.huang2@amd.com">=
wei.huang2@amd.com</a>&gt; <br>&gt; Cc : xen-devel &lt;<a ymailto=3D"mailto=
:xen-devel@lists.xensource.com" href=3D"mailto:xen-devel@lists.xensource.co=
m">xen-devel@lists.xensource.com</a>&gt;; Keir Fraser<br>&gt; &lt;<a ymailt=
o=3D"mailto:keir@xen.org" href=3D"mailto:keir@xen.org">keir@xen.org</a>&gt;=
; Ian Campbell &lt;<a ymailto=3D"mailto:Ian.Campbell@citrix.com" href=3D"ma=
ilto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt;; Tim Deegan<b=
r>&gt; &lt;<a ymailto=3D"mailto:tim@xen.org" href=3D"mailto:tim@xen.org">ti=
m@xen.org</a>&gt;; Ian Jackson &lt;<a ymailto=3D"mailto:Ian.Jackson@eu.citr=
ix.com" href=3D"mailto:Ian.Jackson@eu.citrix.com">Ian.Jackson@eu.citrix.com=
</a>&gt;; Stefano<br>&gt;
 Stabellini &lt;<a ymailto=3D"mailto:stefano.stabellini@citrix.com" href=3D=
"mailto:stefano.stabellini@citrix.com">stefano.stabellini@citrix.com</a>&gt=
;; Jan Beulich<br>&gt; &lt;<a ymailto=3D"mailto:JBeulich@suse.com" href=3D"=
mailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; <br>&gt; Envoy=E9 le : =
Mercredi 4 Janvier 2012 20h43<br>&gt; Objet : Re: [Xen-devel] RFC: Still TO=
DO for 4.2?<br>&gt; <br>&gt; On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei =
Huang wrote:<br>&gt; &gt;&gt;&gt;<br>&gt; &gt;&gt;&gt; Has anybody got anyt=
hing else? I'm sure I've missed stuff. Are<br>&gt; there any<br>&gt; &gt;&g=
t;&gt; must haves e.g. in the paging/sharing spaces?<br>&gt; &gt;&gt;&gt;<b=
r>&gt; &gt;&gt; - What's the status of Nested Hardware Virtualization?<br>&=
gt; &gt;&gt; I remember some email saying Intel vmx-on-vmx has some perform=
ance<br>&gt; issues,<br>&gt; &gt;&gt; and amd svm-on-svm works better..<br>=
&gt; &gt;&gt;<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; - Also there's a bunch of V=
GA
 passthru related patches,<br>&gt; &gt;&gt; that I once volunteered to coll=
ect/rebase/cleanup/repost myself,<br>&gt; &gt;&gt; but I still haven't had =
time for that :(<br>&gt; &gt; Since there were quite a lot of interest on t=
his subject, should<br>&gt; we&nbsp; <br>&gt; &gt; document it in a separat=
e wiki for working combinations (like&nbsp; <br>&gt; &gt; hypervisor, dom0,=
 gfx card, driver version, tricks, etc)?<br>&gt; &gt;<br>&gt; <br>&gt; I ac=
tually once started writing down that kind of stuff:<br>&gt; <a href=3D"htt=
p://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html" target=3D"_b=
lank">http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html</a><=
br>&gt; <br>&gt; Feel free to contribute :)<br>&gt; <br>&gt; There's also:<=
br>&gt; <a href=3D"http://wiki.xen.org/xenwiki/XenVGAPassthrough" target=3D=
"_blank">http://wiki.xen.org/xenwiki/XenVGAPassthrough</a><br>&gt; <br>&gt;=
 <br>&gt; -- Pasi<br>&gt; <br>&gt; <br>&gt;
 _______________________________________________<br>&gt; Xen-devel mailing =
list<br>&gt; <a ymailto=3D"mailto:Xen-devel@lists.xensource.com" href=3D"ma=
ilto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br>&g=
t; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http:=
//lists.xensource.com/xen-devel</a><br>&gt; <br>&gt; <br>&gt; <br><br><br><=
br>_______________________________________________<br>Xen-devel mailing lis=
t<br><a ymailto=3D"mailto:Xen-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.xenso=
urce.com/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
---829503087-1082661605-1325770888=:57253--


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

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

--===============1616093974050320331==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:31:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14:31:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RioLh-0006QZ-Az; Thu, 05 Jan 2012 14:31: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 1RioLf-0006QH-Ru
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:31:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325773873!7739324!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8666 invoked from network); 5 Jan 2012 14:31:14 -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;
	5 Jan 2012 14:31:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9838715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:30: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, 5 Jan 2012 14:30: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
	1RioLE-0000fL-Qe; Thu, 05 Jan 2012 14:30:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RioLE-0007Ez-OI;
	Thu, 05 Jan 2012 14:30:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.46108.738709.553368@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 14:30:52 +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"):
> 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?

I think this will do, modulo the comments in the thread and your
intent to add some docs.  Is a fresh patch going to be forthcoming ?

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:31:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14:31:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RioLh-0006QZ-Az; Thu, 05 Jan 2012 14:31: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 1RioLf-0006QH-Ru
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:31:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325773873!7739324!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8666 invoked from network); 5 Jan 2012 14:31:14 -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;
	5 Jan 2012 14:31:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9838715"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:30: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, 5 Jan 2012 14:30: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
	1RioLE-0000fL-Qe; Thu, 05 Jan 2012 14:30:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RioLE-0007Ez-OI;
	Thu, 05 Jan 2012 14:30:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.46108.738709.553368@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 14:30:52 +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"):
> 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?

I think this will do, modulo the comments in the thread and your
intent to add some docs.  Is a fresh patch going to be forthcoming ?

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:35:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RioPE-0006Ww-EE; Thu, 05 Jan 2012 14:35:00 +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 1RioPC-0006Wq-RH
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:34:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325774092!9818337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19171 invoked from network); 5 Jan 2012 14:34:52 -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;
	5 Jan 2012 14:34:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9838933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:34: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; Thu, 5 Jan 2012 14:34:52 +0000
Date: Thu, 5 Jan 2012 14:34:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F05A684.7000509@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051427340.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > > The "solution" I am proposing is introducing an early_savevm set of
> > > > save/restore functions so that at restore time we can get to know at
> > > > what address the videoram is mapped into the guest address space. Once we
> > > > know the address we can remap it into qemu's address space and/or move it
> > > > to another guest physical address.
> > > 
> > > Why can we not simply track it?  For every MemoryRegion, have a field
> > > called xen_address which tracks its location in the Xen address space
> > > (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> > > xen_address would be maintained by callbacks called from the memory API
> > > into xen-all.c.
> >
> > Nice and simple, I like it.
> > However we would still need an early_savevm mechanism to save and restore the
> > MemoryRegions, unless they already gets saved and restored somehow?
> 
> MemoryRegions are instantiated by the devices, so they should be there
> (creating a MemoryRegion == calling qemu_ram_alloc() in the old days)

If the MemoryRegions are re-created by the devices, then we need another
mechanism to find out where the videoram is.
What I am saying is that the suggestion of having a xen_address field
for every MemoryRegion would make the code cleaner but it would not
solve the save/restore issue described in the previous email.


> > Maybe saving and restoring the list of MemoryRegions could be useful for
> > the generic case too?
> 
> Unneeded, since they're an integral part of the devices.  However, it
> would be good to have a list of the devices so we could send that over
> instead of relying on invoking qemu with the same command-line arguments
> on both sides - but that's something that qom is already tackling.
> 
> > > > The problem of avoiding a second allocation remains, but could be
> > > > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> > > > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> > > > called "vga.vram" at restore time, and use the reference to the already
> > > > allocated videoram instead.
> > > 
> > > Hacky
> >
> > Yes :/
> 
> xen_register_framebuffer() is slightly less hacky.

I agree, however xen_register_framebuffer is called after
memory_region_init_ram, so the allocation would have been made already.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:35:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RioPE-0006Ww-EE; Thu, 05 Jan 2012 14:35:00 +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 1RioPC-0006Wq-RH
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:34:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325774092!9818337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19171 invoked from network); 5 Jan 2012 14:34:52 -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;
	5 Jan 2012 14:34:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9838933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:34: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; Thu, 5 Jan 2012 14:34:52 +0000
Date: Thu, 5 Jan 2012 14:34:40 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F05A684.7000509@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051427340.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > > The "solution" I am proposing is introducing an early_savevm set of
> > > > save/restore functions so that at restore time we can get to know at
> > > > what address the videoram is mapped into the guest address space. Once we
> > > > know the address we can remap it into qemu's address space and/or move it
> > > > to another guest physical address.
> > > 
> > > Why can we not simply track it?  For every MemoryRegion, have a field
> > > called xen_address which tracks its location in the Xen address space
> > > (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> > > xen_address would be maintained by callbacks called from the memory API
> > > into xen-all.c.
> >
> > Nice and simple, I like it.
> > However we would still need an early_savevm mechanism to save and restore the
> > MemoryRegions, unless they already gets saved and restored somehow?
> 
> MemoryRegions are instantiated by the devices, so they should be there
> (creating a MemoryRegion == calling qemu_ram_alloc() in the old days)

If the MemoryRegions are re-created by the devices, then we need another
mechanism to find out where the videoram is.
What I am saying is that the suggestion of having a xen_address field
for every MemoryRegion would make the code cleaner but it would not
solve the save/restore issue described in the previous email.


> > Maybe saving and restoring the list of MemoryRegions could be useful for
> > the generic case too?
> 
> Unneeded, since they're an integral part of the devices.  However, it
> would be good to have a list of the devices so we could send that over
> instead of relying on invoking qemu with the same command-line arguments
> on both sides - but that's something that qom is already tackling.
> 
> > > > The problem of avoiding a second allocation remains, but could be
> > > > solved by passing the "name" parameter from qemu_ram_alloc_from_ptr to
> > > > xen_ram_alloc: xen_ram_alloc could avoid doing any work for anything
> > > > called "vga.vram" at restore time, and use the reference to the already
> > > > allocated videoram instead.
> > > 
> > > Hacky
> >
> > Yes :/
> 
> xen_register_framebuffer() is slightly less hacky.

I agree, however xen_register_framebuffer is called after
memory_region_init_ram, so the allocation would have been made already.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:36:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14: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 1RioQb-0006bX-AO; Thu, 05 Jan 2012 14:36: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 1RioQZ-0006b5-AU
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:36:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325774175!9723744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30159 invoked from network); 5 Jan 2012 14:36:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 14:36:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9838961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14: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; Thu, 5 Jan 2012 14:36: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
	1RioQI-0000h6-CR; Thu, 05 Jan 2012 14:36:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RioQI-0007GN-Au;
	Thu, 05 Jan 2012 14:36:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.46422.324630.116322@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 14:36:06 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0051e09f73efea06f2f2.1323970917@loki.upc.es>
References: <0051e09f73efea06f2f2.1323970917@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 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

Roger Pau Monne writes ("[Xen-devel] [PATCH v3] xenpaging: remove _XOPEN_SOURCE"):
> xenpaging: remove _XOPEN_SOURCE

I decided that it would be best to fix this by removing _XOPEN_SOURCE,
so I have applied this patch.

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 Jan 05 14:36:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14: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 1RioQb-0006bX-AO; Thu, 05 Jan 2012 14:36: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 1RioQZ-0006b5-AU
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:36:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325774175!9723744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30159 invoked from network); 5 Jan 2012 14:36:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 14:36:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9838961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14: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; Thu, 5 Jan 2012 14:36: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
	1RioQI-0000h6-CR; Thu, 05 Jan 2012 14:36:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RioQI-0007GN-Au;
	Thu, 05 Jan 2012 14:36:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.46422.324630.116322@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 14:36:06 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0051e09f73efea06f2f2.1323970917@loki.upc.es>
References: <0051e09f73efea06f2f2.1323970917@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 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

Roger Pau Monne writes ("[Xen-devel] [PATCH v3] xenpaging: remove _XOPEN_SOURCE"):
> xenpaging: remove _XOPEN_SOURCE

I decided that it would be best to fix this by removing _XOPEN_SOURCE,
so I have applied this patch.

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 Jan 05 14:39:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14: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 1RioTJ-0006lw-Ff; Thu, 05 Jan 2012 14:39: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 1RioTH-0006lk-Oz
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:39:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325774303!49065267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9291 invoked from network); 5 Jan 2012 14:38:23 -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 Jan 2012 14:38:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9839034"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:39: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, 5 Jan 2012 14:39: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
	1RioTD-0000i8-9v; Thu, 05 Jan 2012 14:39:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RioTD-0007HB-90;
	Thu, 05 Jan 2012 14:39:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.46603.265055.83034@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 14:39:07 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
References: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [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

> ipxe: update to upstream version

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 Jan 05 14:39:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14: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 1RioTJ-0006lw-Ff; Thu, 05 Jan 2012 14:39: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 1RioTH-0006lk-Oz
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:39:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325774303!49065267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9291 invoked from network); 5 Jan 2012 14:38:23 -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 Jan 2012 14:38:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9839034"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:39: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, 5 Jan 2012 14:39: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
	1RioTD-0000i8-9v; Thu, 05 Jan 2012 14:39:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RioTD-0007HB-90;
	Thu, 05 Jan 2012 14:39:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.46603.265055.83034@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 14:39:07 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
References: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, JBeulich@suse.com
Subject: Re: [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

> ipxe: update to upstream version

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 Jan 05 14:53:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14: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 1Riogk-00073H-6N; Thu, 05 Jan 2012 14:53:06 +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 1Riogi-00073C-LY
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:53:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325775178!7969724!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19253 invoked from network); 5 Jan 2012 14:52:58 -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 Jan 2012 14:52:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9839561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:52:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 14:52:57 +0000
Date: Thu, 5 Jan 2012 14:52:45 +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.1201051448320.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xl.pod.1: introduction to FLASK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 simple introduction to FLASK to the xl man page, at the beginning
of the FLASK chapter. Link to the xsm-flask.txt document.
Currently FLASK, TMEM and PCI PASS-THROUGH are defined as =head2 so they
look like sub-chapters of VIRTUAL DEVICE COMMANDS. Make them =head1.

Based on a text written by Daniel De Graaf.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 17789b4..18fd411 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -906,7 +906,7 @@ List virtual network interfaces for a domain.
 
 =back
 
-=head2 PCI PASS-THROUGH
+=head1 PCI PASS-THROUGH
 
 =over 4
 
@@ -929,7 +929,7 @@ List pass-through pci devices for a domain.
 
 =back
 
-=head2 TMEM
+=head1 TMEM
 
 =over 4
 
@@ -995,7 +995,20 @@ Get information about how much freeable memory (MB) is in-use by tmem.
 
 =back
 
-=head2 FLASK
+=head1 FLASK
+
+B<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.
+
+You can find more details on how to use FLASK and an example security
+policy here: L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
 
 =over 4
 
@@ -1039,6 +1052,7 @@ And the following documents on the xen.org website:
 
 L<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
 L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
+L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
 
 =head1 BUGS
 

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:53:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14: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 1Riogk-00073H-6N; Thu, 05 Jan 2012 14:53:06 +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 1Riogi-00073C-LY
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:53:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325775178!7969724!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19253 invoked from network); 5 Jan 2012 14:52:58 -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 Jan 2012 14:52:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9839561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:52:57 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 14:52:57 +0000
Date: Thu, 5 Jan 2012 14:52:45 +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.1201051448320.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xl.pod.1: introduction to FLASK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 simple introduction to FLASK to the xl man page, at the beginning
of the FLASK chapter. Link to the xsm-flask.txt document.
Currently FLASK, TMEM and PCI PASS-THROUGH are defined as =head2 so they
look like sub-chapters of VIRTUAL DEVICE COMMANDS. Make them =head1.

Based on a text written by Daniel De Graaf.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 17789b4..18fd411 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -906,7 +906,7 @@ List virtual network interfaces for a domain.
 
 =back
 
-=head2 PCI PASS-THROUGH
+=head1 PCI PASS-THROUGH
 
 =over 4
 
@@ -929,7 +929,7 @@ List pass-through pci devices for a domain.
 
 =back
 
-=head2 TMEM
+=head1 TMEM
 
 =over 4
 
@@ -995,7 +995,20 @@ Get information about how much freeable memory (MB) is in-use by tmem.
 
 =back
 
-=head2 FLASK
+=head1 FLASK
+
+B<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.
+
+You can find more details on how to use FLASK and an example security
+policy here: L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
 
 =over 4
 
@@ -1039,6 +1052,7 @@ And the following documents on the xen.org website:
 
 L<http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html>
 L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
+L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
 
 =head1 BUGS
 

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:54:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14: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 1RiohV-000766-Qp; Thu, 05 Jan 2012 14:53: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 1RiohU-00075g-Fi
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:53:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1325775226!9846465!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28503 invoked from network); 5 Jan 2012 14:53:46 -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;
	5 Jan 2012 14:53:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9839588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:53: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, 5 Jan 2012
	14:53:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 14:53:45 +0000
In-Reply-To: <20229.46108.738709.553368@mariner.uk.xensource.com>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
	<20229.46108.738709.553368@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325775226.25206.391.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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 14:30 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of encrypted VNC"):
> > 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?
> 
> I think this will do, modulo the comments in the thread and your
> intent to add some docs.  Is a fresh patch going to be forthcoming ?

That's my intention, although it is behind a pretty big series in my
queue which I'd like to flush first.

Ian.




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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:54:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14: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 1RiohV-000766-Qp; Thu, 05 Jan 2012 14:53: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 1RiohU-00075g-Fi
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:53:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1325775226!9846465!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28503 invoked from network); 5 Jan 2012 14:53:46 -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;
	5 Jan 2012 14:53:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9839588"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 14:53: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, 5 Jan 2012
	14:53:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 14:53:45 +0000
In-Reply-To: <20229.46108.738709.553368@mariner.uk.xensource.com>
References: <1323951936.20077.471.camel@zakaz.uk.xensource.com>
	<20229.46108.738709.553368@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325775226.25206.391.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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 14:30 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [RFC] xl: support configuration of encrypted VNC"):
> > 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?
> 
> I think this will do, modulo the comments in the thread and your
> intent to add some docs.  Is a fresh patch going to be forthcoming ?

That's my intention, although it is behind a pretty big series in my
queue which I'd like to flush first.

Ian.




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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:54:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riohc-000775-89; Thu, 05 Jan 2012 14:54:00 +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 1Riohb-00076O-9Q
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:53:59 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325775213!51659211!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIyNTQ5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5952 invoked from network); 5 Jan 2012 14:53:33 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-27.messagelabs.com with SMTP;
	5 Jan 2012 14:53:33 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 05 Jan 2012 06:53:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="94803711"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 05 Jan 2012 06:53:51 -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; Thu, 5 Jan 2012 22:53:51 +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, 5 Jan 2012 22:53:49 +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 new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0A==
Date: Thu, 5 Jan 2012 14:53:48 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEFE8C@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_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "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 new SMP bring up way for tboot 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_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

tboot may be trying to put APs waiting in MWAIT loops before launching Xen.=
 Xen could check the new flag field in v6 tboot shared page for the hint. I=
f TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write t=
he monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MW=
AIT loops. The sipi vector should be written in g_tboot_shared->ap_wake_add=
r before waking up APs.

Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r cbf1ce3afd74 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Sat Dec 31 16:18:55 2011 +0800
+++ b/xen/arch/x86/smpboot.c	Sat Dec 31 18:50:14 2011 +0800
@@ -586,7 +586,9 @@
     smpboot_setup_warm_reset_vector(start_eip);
=20
     /* Starting actual IPI sequence... */
-    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
+    boot_error =3D tboot_wake_ap(apicid, start_eip);
+    if ( boot_error )
+        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
=20
     if ( !boot_error )
     {
diff -r cbf1ce3afd74 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c	Sat Dec 31 16:18:55 2011 +0800
+++ b/xen/arch/x86/tboot.c	Sat Dec 31 18:50:14 2011 +0800
@@ -123,6 +123,10 @@
     printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
     printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
     printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
+    if ( tboot_shared->version >=3D 5 )
+        printk("  num_in_wfs: %u\n", tboot_shared->num_in_wfs);
+    if ( tboot_shared->version >=3D 6 )
+        printk("  flags: 0x%08x\n", tboot_shared->flags);
=20
     /* these will be needed by tboot_protect_mem_regions() and/or
        tboot_parse_dmar_table(), so get them now */
@@ -529,6 +533,19 @@
     panic("Memory integrity was lost on resume (%d)\n", error);
 }
=20
+int tboot_wake_ap(int apicid, unsigned long sipi_vec)
+{
+    if ( tboot_in_measured_env() && g_tboot_shared->version >=3D 6 &&
+         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
+    {
+        printk("waking AP %d w/ monitor write\n", apicid);
+        g_tboot_shared->ap_wake_addr =3D sipi_vec;
+        g_tboot_shared->ap_wake_trigger =3D apicid;
+        return 0;
+    }
+    return -1;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r cbf1ce3afd74 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h	Sat Dec 31 16:18:55 2011 +0800
+++ b/xen/include/asm-x86/tboot.h	Sat Dec 31 18:50:14 2011 +0800
@@ -85,7 +85,7 @@
 typedef struct __packed {
     /* version 3+ fields: */
     uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08}=
 */
-    uint32_t  version;           /* Version number; currently supports 0.4=
 */
+    uint32_t  version;           /* Version number; currently supports 0.6=
 */
     uint32_t  log_addr;          /* physical addr of tb_log_t log */
     uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
     uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
@@ -99,6 +99,13 @@
     /* version 4+ fields: */
                                  /* populated by tboot; will be encrypted =
*/
     uint8_t   s3_key[TB_KEY_SIZE];
+    /* version 5+ fields: */
+    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
+    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI =
*/
+    /* version 6+ fields: */
+    uint32_t  flags;
+    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
+    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP *=
/
 } tboot_shared_t;
=20
 #define TB_SHUTDOWN_REBOOT      0
@@ -107,6 +114,9 @@
 #define TB_SHUTDOWN_S3          3
 #define TB_SHUTDOWN_HALT        4
=20
+#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use INIT-SIPI-=
SIPI
+                                                 if clear, ap_wake_* if se=
t */
+
 /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
 #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
                                { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
@@ -120,6 +130,7 @@
 int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
 int tboot_s3_resume(void);
 void tboot_s3_error(int error);
+int tboot_wake_ap(int apicid, unsigned long sipi_vec);
=20
 #endif /* __TBOOT_H__ */


--_002_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_
Content-Type: application/octet-stream; name="mwait-smp-up-for-tboot.patch"
Content-Description: mwait-smp-up-for-tboot.patch
Content-Disposition: attachment; filename="mwait-smp-up-for-tboot.patch";
	size=4321; creation-date="Thu, 05 Jan 2012 14:48:54 GMT";
	modification-date="Thu, 05 Jan 2012 14:45:40 GMT"
Content-Transfer-Encoding: base64

eDg2OiBhZGQgYSBuZXcgU01QIGJyaW5nIHVwIHdheSBmb3IgdGJvb3QgY2FzZQoKdGJvb3QgbWF5
IGJlIHRyeWluZyB0byBwdXQgQVBzIHdhaXRpbmcgaW4gTVdBSVQgbG9vcHMgYmVmb3JlIGxhdW5j
aGluZyBYZW4uIFhlbiBjb3VsZCBjaGVjayB0aGUgbmV3IGZsYWcgZmllbGQgaW4gdjYgdGJvb3Qg
c2hhcmVkIHBhZ2UgZm9yIHRoZSBoaW50LiBJZiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCBiaXQg
aW4gZmxhZyBmaWVsZCBpcyBzZXQsIFhlbiBCU1AgaGF2ZSB0byB3cml0ZSB0aGUgbW9uaXRvcmVk
IG1lbW9yeShnX3Rib290X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyKSB0byBicmluZyBBUHMgb3V0
IG9mIE1XQUlUIGxvb3BzLiBUaGUgc2lwaSB2ZWN0b3Igc2hvdWxkIGJlIHdyaXR0ZW4gaW4gZ190
Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciBiZWZvcmUgd2FraW5nIHVwIEFQcy4KClNpZ25lZC1v
ZmYtYnk6IEpvc2VwaCBDaWh1bGEgPGpvc2VwaC5jaWh1bGFAaW50ZWwuY29tPgpTaWduZWQtb2Zm
LWJ5OiBTaGFuZSBXYW5nIDxzaGFuZS53YW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogR2Fu
ZyBXZWkgPGdhbmcud2VpQGludGVsLmNvbT4KCmRpZmYgLXIgY2JmMWNlM2FmZDc0IHhlbi9hcmNo
L3g4Ni9zbXBib290LmMKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlTYXQgRGVjIDMxIDE2
OjE4OjU1IDIwMTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlTYXQgRGVjIDMx
IDE4OjUwOjE0IDIwMTEgKzA4MDAKQEAgLTU4Niw3ICs1ODYsOSBAQAogICAgIHNtcGJvb3Rfc2V0
dXBfd2FybV9yZXNldF92ZWN0b3Ioc3RhcnRfZWlwKTsKIAogICAgIC8qIFN0YXJ0aW5nIGFjdHVh
bCBJUEkgc2VxdWVuY2UuLi4gKi8KLSAgICBib290X2Vycm9yID0gd2FrZXVwX3NlY29uZGFyeV9j
cHUoYXBpY2lkLCBzdGFydF9laXApOworICAgIGJvb3RfZXJyb3IgPSB0Ym9vdF93YWtlX2FwKGFw
aWNpZCwgc3RhcnRfZWlwKTsKKyAgICBpZiAoIGJvb3RfZXJyb3IgKQorICAgICAgICBib290X2Vy
cm9yID0gd2FrZXVwX3NlY29uZGFyeV9jcHUoYXBpY2lkLCBzdGFydF9laXApOwogCiAgICAgaWYg
KCAhYm9vdF9lcnJvciApCiAgICAgewpkaWZmIC1yIGNiZjFjZTNhZmQ3NCB4ZW4vYXJjaC94ODYv
dGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvdGJvb3QuYwlTYXQgRGVjIDMxIDE2OjE4OjU1IDIw
MTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3Rib290LmMJU2F0IERlYyAzMSAxODo1MDoxNCAy
MDExICswODAwCkBAIC0xMjMsNiArMTIzLDEwIEBACiAgICAgcHJpbnRrKCIgIHNodXRkb3duX2Vu
dHJ5OiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+c2h1dGRvd25fZW50cnkpOwogICAgIHByaW50
aygiICB0Ym9vdF9iYXNlOiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+dGJvb3RfYmFzZSk7CiAg
ICAgcHJpbnRrKCIgIHRib290X3NpemU6IDB4JXhcbiIsIHRib290X3NoYXJlZC0+dGJvb3Rfc2l6
ZSk7CisgICAgaWYgKCB0Ym9vdF9zaGFyZWQtPnZlcnNpb24gPj0gNSApCisgICAgICAgIHByaW50
aygiICBudW1faW5fd2ZzOiAldVxuIiwgdGJvb3Rfc2hhcmVkLT5udW1faW5fd2ZzKTsKKyAgICBp
ZiAoIHRib290X3NoYXJlZC0+dmVyc2lvbiA+PSA2ICkKKyAgICAgICAgcHJpbnRrKCIgIGZsYWdz
OiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+ZmxhZ3MpOwogCiAgICAgLyogdGhlc2Ugd2lsbCBi
ZSBuZWVkZWQgYnkgdGJvb3RfcHJvdGVjdF9tZW1fcmVnaW9ucygpIGFuZC9vcgogICAgICAgIHRi
b290X3BhcnNlX2RtYXJfdGFibGUoKSwgc28gZ2V0IHRoZW0gbm93ICovCkBAIC01MjksNiArNTMz
LDE5IEBACiAgICAgcGFuaWMoIk1lbW9yeSBpbnRlZ3JpdHkgd2FzIGxvc3Qgb24gcmVzdW1lICgl
ZClcbiIsIGVycm9yKTsKIH0KIAoraW50IHRib290X3dha2VfYXAoaW50IGFwaWNpZCwgdW5zaWdu
ZWQgbG9uZyBzaXBpX3ZlYykKK3sKKyAgICBpZiAoIHRib290X2luX21lYXN1cmVkX2VudigpICYm
IGdfdGJvb3Rfc2hhcmVkLT52ZXJzaW9uID49IDYgJiYKKyAgICAgICAgIChnX3Rib290X3NoYXJl
ZC0+ZmxhZ3MgJiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCkgKQorICAgIHsKKyAgICAgICAgcHJp
bnRrKCJ3YWtpbmcgQVAgJWQgdy8gbW9uaXRvciB3cml0ZVxuIiwgYXBpY2lkKTsKKyAgICAgICAg
Z190Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciA9IHNpcGlfdmVjOworICAgICAgICBnX3Rib290
X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyID0gYXBpY2lkOworICAgICAgICByZXR1cm4gMDsKKyAg
ICB9CisgICAgcmV0dXJuIC0xOworfQorCiAvKgogICogTG9jYWwgdmFyaWFibGVzOgogICogbW9k
ZTogQwpkaWZmIC1yIGNiZjFjZTNhZmQ3NCB4ZW4vaW5jbHVkZS9hc20teDg2L3Rib290LmgKLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni90Ym9vdC5oCVNhdCBEZWMgMzEgMTY6MTg6NTUgMjAxMSAr
MDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L3Rib290LmgJU2F0IERlYyAzMSAxODo1MDox
NCAyMDExICswODAwCkBAIC04NSw3ICs4NSw3IEBACiB0eXBlZGVmIHN0cnVjdCBfX3BhY2tlZCB7
CiAgICAgLyogdmVyc2lvbiAzKyBmaWVsZHM6ICovCiAgICAgdXVpZF90ICAgIHV1aWQ7ICAgICAg
ICAgICAgICAvKiB7NjYzQzhERkYtRThCMy00YjgyLUFBQkYtMTlFQTREMDU3QTA4fSAqLwotICAg
IHVpbnQzMl90ICB2ZXJzaW9uOyAgICAgICAgICAgLyogVmVyc2lvbiBudW1iZXI7IGN1cnJlbnRs
eSBzdXBwb3J0cyAwLjQgKi8KKyAgICB1aW50MzJfdCAgdmVyc2lvbjsgICAgICAgICAgIC8qIFZl
cnNpb24gbnVtYmVyOyBjdXJyZW50bHkgc3VwcG9ydHMgMC42ICovCiAgICAgdWludDMyX3QgIGxv
Z19hZGRyOyAgICAgICAgICAvKiBwaHlzaWNhbCBhZGRyIG9mIHRiX2xvZ190IGxvZyAqLwogICAg
IHVpbnQzMl90ICBzaHV0ZG93bl9lbnRyeTsgICAgLyogZW50cnkgcG9pbnQgZm9yIHRib290IHNo
dXRkb3duICovCiAgICAgdWludDMyX3QgIHNodXRkb3duX3R5cGU7ICAgICAvKiB0eXBlIG9mIHNo
dXRkb3duIChUQl9TSFVURE9XTl8qKSAqLwpAQCAtOTksNiArOTksMTMgQEAKICAgICAvKiB2ZXJz
aW9uIDQrIGZpZWxkczogKi8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIHBv
cHVsYXRlZCBieSB0Ym9vdDsgd2lsbCBiZSBlbmNyeXB0ZWQgKi8KICAgICB1aW50OF90ICAgczNf
a2V5W1RCX0tFWV9TSVpFXTsKKyAgICAvKiB2ZXJzaW9uIDUrIGZpZWxkczogKi8KKyAgICB1aW50
OF90ICAgcmVzZXJ2ZWRfYWxpZ25bM107IC8qIHVzZWQgdG8gNGJ5dGUtYWxpZ24gbnVtX2luX3dm
cyAqLworICAgIHVpbnQzMl90ICBudW1faW5fd2ZzOyAgICAgICAgLyogbnVtYmVyIG9mIHByb2Nl
c3NvcnMgaW4gd2FpdC1mb3ItU0lQSSAqLworICAgIC8qIHZlcnNpb24gNisgZmllbGRzOiAqLwor
ICAgIHVpbnQzMl90ICBmbGFnczsKKyAgICB1aW50NjRfdCAgYXBfd2FrZV9hZGRyOyAgICAgIC8q
IHBoeXMgYWRkciBvZiBrZXJuZWwvVk1NIFNJUEkgdmVjdG9yICovCisgICAgdWludDMyX3QgIGFw
X3dha2VfdHJpZ2dlcjsgICAvKiBrZXJuZWwvVk1NIHdyaXRlcyBBUElDIElEIHRvIHdha2UgQVAg
Ki8KIH0gdGJvb3Rfc2hhcmVkX3Q7CiAKICNkZWZpbmUgVEJfU0hVVERPV05fUkVCT09UICAgICAg
MApAQCAtMTA3LDYgKzExNCw5IEBACiAjZGVmaW5lIFRCX1NIVVRET1dOX1MzICAgICAgICAgIDMK
ICNkZWZpbmUgVEJfU0hVVERPV05fSEFMVCAgICAgICAgNAogCisjZGVmaW5lIFRCX0ZMQUdfQVBf
V0FLRV9TVVBQT1JUICAgMHgwMDAwMDAwMSAgLyoga2VybmVsL1ZNTSB1c2UgSU5JVC1TSVBJLVNJ
UEkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiBj
bGVhciwgYXBfd2FrZV8qIGlmIHNldCAqLworCiAvKiB7NjYzQzhERkYtRThCMy00YjgyLUFBQkYt
MTlFQTREMDU3QTA4fSAqLwogI2RlZmluZSBUQk9PVF9TSEFSRURfVVVJRCAgICB7IDB4NjYzYzhk
ZmYsIDB4ZThiMywgMHg0YjgyLCAweGFhYmYsIFwKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB7IDB4MTksIDB4ZWEsIDB4NGQsIDB4NSwgMHg3YSwgMHg4IH0gfTsKQEAgLTEyMCw2ICsx
MzAsNyBAQAogaW50IHRib290X3BhcnNlX2RtYXJfdGFibGUoYWNwaV90YWJsZV9oYW5kbGVyIGRt
YXJfaGFuZGxlcik7CiBpbnQgdGJvb3RfczNfcmVzdW1lKHZvaWQpOwogdm9pZCB0Ym9vdF9zM19l
cnJvcihpbnQgZXJyb3IpOworaW50IHRib290X3dha2VfYXAoaW50IGFwaWNpZCwgdW5zaWduZWQg
bG9uZyBzaXBpX3ZlYyk7CiAKICNlbmRpZiAvKiBfX1RCT09UX0hfXyAqLwogCg==

--_002_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 14:54:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 14:54:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riohc-000775-89; Thu, 05 Jan 2012 14:54:00 +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 1Riohb-00076O-9Q
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:53:59 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325775213!51659211!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIyNTQ5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5952 invoked from network); 5 Jan 2012 14:53:33 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-11.tower-27.messagelabs.com with SMTP;
	5 Jan 2012 14:53:33 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 05 Jan 2012 06:53:53 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="94803711"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 05 Jan 2012 06:53:51 -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; Thu, 5 Jan 2012 22:53:51 +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, 5 Jan 2012 22:53:49 +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 new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0A==
Date: Thu, 5 Jan 2012 14:53:48 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEFE8C@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_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_"
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "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 new SMP bring up way for tboot 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_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

tboot may be trying to put APs waiting in MWAIT loops before launching Xen.=
 Xen could check the new flag field in v6 tboot shared page for the hint. I=
f TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write t=
he monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MW=
AIT loops. The sipi vector should be written in g_tboot_shared->ap_wake_add=
r before waking up APs.

Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r cbf1ce3afd74 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Sat Dec 31 16:18:55 2011 +0800
+++ b/xen/arch/x86/smpboot.c	Sat Dec 31 18:50:14 2011 +0800
@@ -586,7 +586,9 @@
     smpboot_setup_warm_reset_vector(start_eip);
=20
     /* Starting actual IPI sequence... */
-    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
+    boot_error =3D tboot_wake_ap(apicid, start_eip);
+    if ( boot_error )
+        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
=20
     if ( !boot_error )
     {
diff -r cbf1ce3afd74 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c	Sat Dec 31 16:18:55 2011 +0800
+++ b/xen/arch/x86/tboot.c	Sat Dec 31 18:50:14 2011 +0800
@@ -123,6 +123,10 @@
     printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
     printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
     printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
+    if ( tboot_shared->version >=3D 5 )
+        printk("  num_in_wfs: %u\n", tboot_shared->num_in_wfs);
+    if ( tboot_shared->version >=3D 6 )
+        printk("  flags: 0x%08x\n", tboot_shared->flags);
=20
     /* these will be needed by tboot_protect_mem_regions() and/or
        tboot_parse_dmar_table(), so get them now */
@@ -529,6 +533,19 @@
     panic("Memory integrity was lost on resume (%d)\n", error);
 }
=20
+int tboot_wake_ap(int apicid, unsigned long sipi_vec)
+{
+    if ( tboot_in_measured_env() && g_tboot_shared->version >=3D 6 &&
+         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
+    {
+        printk("waking AP %d w/ monitor write\n", apicid);
+        g_tboot_shared->ap_wake_addr =3D sipi_vec;
+        g_tboot_shared->ap_wake_trigger =3D apicid;
+        return 0;
+    }
+    return -1;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r cbf1ce3afd74 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h	Sat Dec 31 16:18:55 2011 +0800
+++ b/xen/include/asm-x86/tboot.h	Sat Dec 31 18:50:14 2011 +0800
@@ -85,7 +85,7 @@
 typedef struct __packed {
     /* version 3+ fields: */
     uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08}=
 */
-    uint32_t  version;           /* Version number; currently supports 0.4=
 */
+    uint32_t  version;           /* Version number; currently supports 0.6=
 */
     uint32_t  log_addr;          /* physical addr of tb_log_t log */
     uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
     uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
@@ -99,6 +99,13 @@
     /* version 4+ fields: */
                                  /* populated by tboot; will be encrypted =
*/
     uint8_t   s3_key[TB_KEY_SIZE];
+    /* version 5+ fields: */
+    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
+    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI =
*/
+    /* version 6+ fields: */
+    uint32_t  flags;
+    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
+    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP *=
/
 } tboot_shared_t;
=20
 #define TB_SHUTDOWN_REBOOT      0
@@ -107,6 +114,9 @@
 #define TB_SHUTDOWN_S3          3
 #define TB_SHUTDOWN_HALT        4
=20
+#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use INIT-SIPI-=
SIPI
+                                                 if clear, ap_wake_* if se=
t */
+
 /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
 #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
                                { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
@@ -120,6 +130,7 @@
 int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
 int tboot_s3_resume(void);
 void tboot_s3_error(int error);
+int tboot_wake_ap(int apicid, unsigned long sipi_vec);
=20
 #endif /* __TBOOT_H__ */


--_002_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_
Content-Type: application/octet-stream; name="mwait-smp-up-for-tboot.patch"
Content-Description: mwait-smp-up-for-tboot.patch
Content-Disposition: attachment; filename="mwait-smp-up-for-tboot.patch";
	size=4321; creation-date="Thu, 05 Jan 2012 14:48:54 GMT";
	modification-date="Thu, 05 Jan 2012 14:45:40 GMT"
Content-Transfer-Encoding: base64

eDg2OiBhZGQgYSBuZXcgU01QIGJyaW5nIHVwIHdheSBmb3IgdGJvb3QgY2FzZQoKdGJvb3QgbWF5
IGJlIHRyeWluZyB0byBwdXQgQVBzIHdhaXRpbmcgaW4gTVdBSVQgbG9vcHMgYmVmb3JlIGxhdW5j
aGluZyBYZW4uIFhlbiBjb3VsZCBjaGVjayB0aGUgbmV3IGZsYWcgZmllbGQgaW4gdjYgdGJvb3Qg
c2hhcmVkIHBhZ2UgZm9yIHRoZSBoaW50LiBJZiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCBiaXQg
aW4gZmxhZyBmaWVsZCBpcyBzZXQsIFhlbiBCU1AgaGF2ZSB0byB3cml0ZSB0aGUgbW9uaXRvcmVk
IG1lbW9yeShnX3Rib290X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyKSB0byBicmluZyBBUHMgb3V0
IG9mIE1XQUlUIGxvb3BzLiBUaGUgc2lwaSB2ZWN0b3Igc2hvdWxkIGJlIHdyaXR0ZW4gaW4gZ190
Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciBiZWZvcmUgd2FraW5nIHVwIEFQcy4KClNpZ25lZC1v
ZmYtYnk6IEpvc2VwaCBDaWh1bGEgPGpvc2VwaC5jaWh1bGFAaW50ZWwuY29tPgpTaWduZWQtb2Zm
LWJ5OiBTaGFuZSBXYW5nIDxzaGFuZS53YW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogR2Fu
ZyBXZWkgPGdhbmcud2VpQGludGVsLmNvbT4KCmRpZmYgLXIgY2JmMWNlM2FmZDc0IHhlbi9hcmNo
L3g4Ni9zbXBib290LmMKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlTYXQgRGVjIDMxIDE2
OjE4OjU1IDIwMTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlTYXQgRGVjIDMx
IDE4OjUwOjE0IDIwMTEgKzA4MDAKQEAgLTU4Niw3ICs1ODYsOSBAQAogICAgIHNtcGJvb3Rfc2V0
dXBfd2FybV9yZXNldF92ZWN0b3Ioc3RhcnRfZWlwKTsKIAogICAgIC8qIFN0YXJ0aW5nIGFjdHVh
bCBJUEkgc2VxdWVuY2UuLi4gKi8KLSAgICBib290X2Vycm9yID0gd2FrZXVwX3NlY29uZGFyeV9j
cHUoYXBpY2lkLCBzdGFydF9laXApOworICAgIGJvb3RfZXJyb3IgPSB0Ym9vdF93YWtlX2FwKGFw
aWNpZCwgc3RhcnRfZWlwKTsKKyAgICBpZiAoIGJvb3RfZXJyb3IgKQorICAgICAgICBib290X2Vy
cm9yID0gd2FrZXVwX3NlY29uZGFyeV9jcHUoYXBpY2lkLCBzdGFydF9laXApOwogCiAgICAgaWYg
KCAhYm9vdF9lcnJvciApCiAgICAgewpkaWZmIC1yIGNiZjFjZTNhZmQ3NCB4ZW4vYXJjaC94ODYv
dGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvdGJvb3QuYwlTYXQgRGVjIDMxIDE2OjE4OjU1IDIw
MTEgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3Rib290LmMJU2F0IERlYyAzMSAxODo1MDoxNCAy
MDExICswODAwCkBAIC0xMjMsNiArMTIzLDEwIEBACiAgICAgcHJpbnRrKCIgIHNodXRkb3duX2Vu
dHJ5OiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+c2h1dGRvd25fZW50cnkpOwogICAgIHByaW50
aygiICB0Ym9vdF9iYXNlOiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+dGJvb3RfYmFzZSk7CiAg
ICAgcHJpbnRrKCIgIHRib290X3NpemU6IDB4JXhcbiIsIHRib290X3NoYXJlZC0+dGJvb3Rfc2l6
ZSk7CisgICAgaWYgKCB0Ym9vdF9zaGFyZWQtPnZlcnNpb24gPj0gNSApCisgICAgICAgIHByaW50
aygiICBudW1faW5fd2ZzOiAldVxuIiwgdGJvb3Rfc2hhcmVkLT5udW1faW5fd2ZzKTsKKyAgICBp
ZiAoIHRib290X3NoYXJlZC0+dmVyc2lvbiA+PSA2ICkKKyAgICAgICAgcHJpbnRrKCIgIGZsYWdz
OiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+ZmxhZ3MpOwogCiAgICAgLyogdGhlc2Ugd2lsbCBi
ZSBuZWVkZWQgYnkgdGJvb3RfcHJvdGVjdF9tZW1fcmVnaW9ucygpIGFuZC9vcgogICAgICAgIHRi
b290X3BhcnNlX2RtYXJfdGFibGUoKSwgc28gZ2V0IHRoZW0gbm93ICovCkBAIC01MjksNiArNTMz
LDE5IEBACiAgICAgcGFuaWMoIk1lbW9yeSBpbnRlZ3JpdHkgd2FzIGxvc3Qgb24gcmVzdW1lICgl
ZClcbiIsIGVycm9yKTsKIH0KIAoraW50IHRib290X3dha2VfYXAoaW50IGFwaWNpZCwgdW5zaWdu
ZWQgbG9uZyBzaXBpX3ZlYykKK3sKKyAgICBpZiAoIHRib290X2luX21lYXN1cmVkX2VudigpICYm
IGdfdGJvb3Rfc2hhcmVkLT52ZXJzaW9uID49IDYgJiYKKyAgICAgICAgIChnX3Rib290X3NoYXJl
ZC0+ZmxhZ3MgJiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCkgKQorICAgIHsKKyAgICAgICAgcHJp
bnRrKCJ3YWtpbmcgQVAgJWQgdy8gbW9uaXRvciB3cml0ZVxuIiwgYXBpY2lkKTsKKyAgICAgICAg
Z190Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciA9IHNpcGlfdmVjOworICAgICAgICBnX3Rib290
X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyID0gYXBpY2lkOworICAgICAgICByZXR1cm4gMDsKKyAg
ICB9CisgICAgcmV0dXJuIC0xOworfQorCiAvKgogICogTG9jYWwgdmFyaWFibGVzOgogICogbW9k
ZTogQwpkaWZmIC1yIGNiZjFjZTNhZmQ3NCB4ZW4vaW5jbHVkZS9hc20teDg2L3Rib290LmgKLS0t
IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni90Ym9vdC5oCVNhdCBEZWMgMzEgMTY6MTg6NTUgMjAxMSAr
MDgwMAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L3Rib290LmgJU2F0IERlYyAzMSAxODo1MDox
NCAyMDExICswODAwCkBAIC04NSw3ICs4NSw3IEBACiB0eXBlZGVmIHN0cnVjdCBfX3BhY2tlZCB7
CiAgICAgLyogdmVyc2lvbiAzKyBmaWVsZHM6ICovCiAgICAgdXVpZF90ICAgIHV1aWQ7ICAgICAg
ICAgICAgICAvKiB7NjYzQzhERkYtRThCMy00YjgyLUFBQkYtMTlFQTREMDU3QTA4fSAqLwotICAg
IHVpbnQzMl90ICB2ZXJzaW9uOyAgICAgICAgICAgLyogVmVyc2lvbiBudW1iZXI7IGN1cnJlbnRs
eSBzdXBwb3J0cyAwLjQgKi8KKyAgICB1aW50MzJfdCAgdmVyc2lvbjsgICAgICAgICAgIC8qIFZl
cnNpb24gbnVtYmVyOyBjdXJyZW50bHkgc3VwcG9ydHMgMC42ICovCiAgICAgdWludDMyX3QgIGxv
Z19hZGRyOyAgICAgICAgICAvKiBwaHlzaWNhbCBhZGRyIG9mIHRiX2xvZ190IGxvZyAqLwogICAg
IHVpbnQzMl90ICBzaHV0ZG93bl9lbnRyeTsgICAgLyogZW50cnkgcG9pbnQgZm9yIHRib290IHNo
dXRkb3duICovCiAgICAgdWludDMyX3QgIHNodXRkb3duX3R5cGU7ICAgICAvKiB0eXBlIG9mIHNo
dXRkb3duIChUQl9TSFVURE9XTl8qKSAqLwpAQCAtOTksNiArOTksMTMgQEAKICAgICAvKiB2ZXJz
aW9uIDQrIGZpZWxkczogKi8KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIHBv
cHVsYXRlZCBieSB0Ym9vdDsgd2lsbCBiZSBlbmNyeXB0ZWQgKi8KICAgICB1aW50OF90ICAgczNf
a2V5W1RCX0tFWV9TSVpFXTsKKyAgICAvKiB2ZXJzaW9uIDUrIGZpZWxkczogKi8KKyAgICB1aW50
OF90ICAgcmVzZXJ2ZWRfYWxpZ25bM107IC8qIHVzZWQgdG8gNGJ5dGUtYWxpZ24gbnVtX2luX3dm
cyAqLworICAgIHVpbnQzMl90ICBudW1faW5fd2ZzOyAgICAgICAgLyogbnVtYmVyIG9mIHByb2Nl
c3NvcnMgaW4gd2FpdC1mb3ItU0lQSSAqLworICAgIC8qIHZlcnNpb24gNisgZmllbGRzOiAqLwor
ICAgIHVpbnQzMl90ICBmbGFnczsKKyAgICB1aW50NjRfdCAgYXBfd2FrZV9hZGRyOyAgICAgIC8q
IHBoeXMgYWRkciBvZiBrZXJuZWwvVk1NIFNJUEkgdmVjdG9yICovCisgICAgdWludDMyX3QgIGFw
X3dha2VfdHJpZ2dlcjsgICAvKiBrZXJuZWwvVk1NIHdyaXRlcyBBUElDIElEIHRvIHdha2UgQVAg
Ki8KIH0gdGJvb3Rfc2hhcmVkX3Q7CiAKICNkZWZpbmUgVEJfU0hVVERPV05fUkVCT09UICAgICAg
MApAQCAtMTA3LDYgKzExNCw5IEBACiAjZGVmaW5lIFRCX1NIVVRET1dOX1MzICAgICAgICAgIDMK
ICNkZWZpbmUgVEJfU0hVVERPV05fSEFMVCAgICAgICAgNAogCisjZGVmaW5lIFRCX0ZMQUdfQVBf
V0FLRV9TVVBQT1JUICAgMHgwMDAwMDAwMSAgLyoga2VybmVsL1ZNTSB1c2UgSU5JVC1TSVBJLVNJ
UEkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiBj
bGVhciwgYXBfd2FrZV8qIGlmIHNldCAqLworCiAvKiB7NjYzQzhERkYtRThCMy00YjgyLUFBQkYt
MTlFQTREMDU3QTA4fSAqLwogI2RlZmluZSBUQk9PVF9TSEFSRURfVVVJRCAgICB7IDB4NjYzYzhk
ZmYsIDB4ZThiMywgMHg0YjgyLCAweGFhYmYsIFwKICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB7IDB4MTksIDB4ZWEsIDB4NGQsIDB4NSwgMHg3YSwgMHg4IH0gfTsKQEAgLTEyMCw2ICsx
MzAsNyBAQAogaW50IHRib290X3BhcnNlX2RtYXJfdGFibGUoYWNwaV90YWJsZV9oYW5kbGVyIGRt
YXJfaGFuZGxlcik7CiBpbnQgdGJvb3RfczNfcmVzdW1lKHZvaWQpOwogdm9pZCB0Ym9vdF9zM19l
cnJvcihpbnQgZXJyb3IpOworaW50IHRib290X3dha2VfYXAoaW50IGFwaWNpZCwgdW5zaWduZWQg
bG9uZyBzaXBpX3ZlYyk7CiAKICNlbmRpZiAvKiBfX1RCT09UX0hfXyAqLwogCg==

--_002_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_D0B11485C64D4B47B66902F8A4E901BEFE8CSHSMSX101ccrcorpint_--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:01:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:01:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiooO-0007fr-To; Thu, 05 Jan 2012 15:01:00 +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 1RiooM-0007fJ-K2
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:00:58 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325775651!6100634!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNjM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3788 invoked from network); 5 Jan 2012 15:00:52 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 15:00:52 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 05 Jan 2012 07:00:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="93271543"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 05 Jan 2012 07:00:50 -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, 5 Jan 2012 23:00:44 +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, 5 Jan 2012 23:00:43 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "Kay, Allen M"
	<allen.m.kay@intel.com>
Thread-Topic: [Xen-devel] [PATCH] fix build error
Thread-Index: AQHMy4Caa1EXLbLdTUuB76yhlKqEsZX93Wfg
Date: Thu, 5 Jan 2012 15:00:43 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
	<1325750535.29084.1.camel@dagon.hellion.org.uk>
In-Reply-To: <1325750535.29084.1.camel@dagon.hellion.org.uk>
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: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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="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 wrote on=A02012-01-05:
> On Wed, 2012-01-04 at 21:57 +0000, Kay, Allen M wrote:
>> Attached patch fix build error in latest xen-unstable.hg.
> =

> What is the specific build error?
> =

> What version of yajl do you have and on which distro?
> =


I am not try to answer this for Allen, but I also met similar build error(i=
t says yajl_gen_no_buf was not defined) in RHEL6.2 64bit with yajl 1.0.7-3.

Jimmy



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:01:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:01:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiooO-0007fr-To; Thu, 05 Jan 2012 15:01:00 +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 1RiooM-0007fJ-K2
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:00:58 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325775651!6100634!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNjM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3788 invoked from network); 5 Jan 2012 15:00:52 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-15.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 15:00:52 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 05 Jan 2012 07:00:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="93271543"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 05 Jan 2012 07:00:50 -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, 5 Jan 2012 23:00:44 +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, 5 Jan 2012 23:00:43 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "Kay, Allen M"
	<allen.m.kay@intel.com>
Thread-Topic: [Xen-devel] [PATCH] fix build error
Thread-Index: AQHMy4Caa1EXLbLdTUuB76yhlKqEsZX93Wfg
Date: Thu, 5 Jan 2012 15:00:43 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
	<1325750535.29084.1.camel@dagon.hellion.org.uk>
In-Reply-To: <1325750535.29084.1.camel@dagon.hellion.org.uk>
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: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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="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 wrote on=A02012-01-05:
> On Wed, 2012-01-04 at 21:57 +0000, Kay, Allen M wrote:
>> Attached patch fix build error in latest xen-unstable.hg.
> =

> What is the specific build error?
> =

> What version of yajl do you have and on which distro?
> =


I am not try to answer this for Allen, but I also met similar build error(i=
t says yajl_gen_no_buf was not defined) in RHEL6.2 64bit with yajl 1.0.7-3.

Jimmy



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:03:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15: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 1RioqR-0007ss-FD; Thu, 05 Jan 2012 15:03:07 +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 1RioqP-0007sd-Qk
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:03:06 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1325775723!63106304!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQ1Mzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18716 invoked from network); 5 Jan 2012 15:02:04 -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;
	5 Jan 2012 15:02:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320642000"; d="scan'208";a="20580750"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 10:03:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 10:03:03 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q05F319N014942;
	Thu, 5 Jan 2012 07:03:01 -0800
MIME-Version: 1.0
X-Mercurial-Node: e25b7798f13ba47f5325f95afed0ec7d2a27cc44
Message-ID: <e25b7798f13ba47f5325.1325775781@qabil.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Jan 2012 15:03:01 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH] x86: emulate lea with two register operands
	correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

An lea instruction with two register operands should raise an
undefined instruction exception.

Skype does such a instruction and will crash when starting if it does
not get the exception.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>

diff -r efaa28639a71 -r e25b7798f13b xen/arch/x86/x86_emulate/x86_emulate.c
--- a/xen/arch/x86/x86_emulate/x86_emulate.c	Wed Jan 04 16:12:44 2012 +0000
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c	Thu Jan 05 14:58:56 2012 +0000
@@ -2240,6 +2240,7 @@ x86_emulate(
     }
 
     case 0x8d: /* lea */
+        generate_exception_if(modrm_mod == 3, EXC_UD, -1);
         dst.val = ea.mem.off;
         break;
 

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:03:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15: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 1RioqR-0007ss-FD; Thu, 05 Jan 2012 15:03:07 +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 1RioqP-0007sd-Qk
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:03:06 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1325775723!63106304!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQ1Mzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18716 invoked from network); 5 Jan 2012 15:02:04 -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;
	5 Jan 2012 15:02:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320642000"; d="scan'208";a="20580750"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 10:03:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 10:03:03 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q05F319N014942;
	Thu, 5 Jan 2012 07:03:01 -0800
MIME-Version: 1.0
X-Mercurial-Node: e25b7798f13ba47f5325f95afed0ec7d2a27cc44
Message-ID: <e25b7798f13ba47f5325.1325775781@qabil.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Thu, 5 Jan 2012 15:03:01 +0000
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH] x86: emulate lea with two register operands
	correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

An lea instruction with two register operands should raise an
undefined instruction exception.

Skype does such a instruction and will crash when starting if it does
not get the exception.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>

diff -r efaa28639a71 -r e25b7798f13b xen/arch/x86/x86_emulate/x86_emulate.c
--- a/xen/arch/x86/x86_emulate/x86_emulate.c	Wed Jan 04 16:12:44 2012 +0000
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c	Thu Jan 05 14:58:56 2012 +0000
@@ -2240,6 +2240,7 @@ x86_emulate(
     }
 
     case 0x8d: /* lea */
+        generate_exception_if(modrm_mod == 3, EXC_UD, -1);
         dst.val = ea.mem.off;
         break;
 

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:05:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riosl-00083D-1J; Thu, 05 Jan 2012 15:05: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 1Riosj-00082w-5S
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:05:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325775922!7964843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14679 invoked from network); 5 Jan 2012 15:05:23 -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;
	5 Jan 2012 15:05:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9839921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 15:05: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, 5 Jan 2012
	15:05:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Wei, Gang" <gang.wei@intel.com>
Date: Thu, 5 Jan 2012 15:05:21 +0000
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
	<1325750535.29084.1.camel@dagon.hellion.org.uk>
	<D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325775922.25206.395.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>,
	"Kay, Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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 Thu, 2012-01-05 at 15:00 +0000, Wei, Gang wrote:
> Ian Campbell wrote on 2012-01-05:
> > On Wed, 2012-01-04 at 21:57 +0000, Kay, Allen M wrote:
> >> Attached patch fix build error in latest xen-unstable.hg.
> > 
> > What is the specific build error?
> > 
> > What version of yajl do you have and on which distro?
> > 
> 
> I am not try to answer this for Allen, but I also met similar build error(it says yajl_gen_no_buf was not defined) in RHEL6.2 64bit with yajl 1.0.7-3.

I use 1.0.8 so I guess this must be new there.

Any patch which says "fix build error/warning/message" should, IMHO,
always include a verbatim copy of the error message being fixed.

Please can one of you resubmit with the changelog corrected in that
manner?

Eventually we could use autoconf to detect this stuff, although that
does sound rather like overkill...

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:05:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riosl-00083D-1J; Thu, 05 Jan 2012 15:05: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 1Riosj-00082w-5S
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:05:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325775922!7964843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14679 invoked from network); 5 Jan 2012 15:05:23 -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;
	5 Jan 2012 15:05:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,461,1320624000"; 
   d="scan'208";a="9839921"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 15:05: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, 5 Jan 2012
	15:05:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Wei, Gang" <gang.wei@intel.com>
Date: Thu, 5 Jan 2012 15:05:21 +0000
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
	<1325750535.29084.1.camel@dagon.hellion.org.uk>
	<D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325775922.25206.395.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>,
	"Kay, Allen M" <allen.m.kay@intel.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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 Thu, 2012-01-05 at 15:00 +0000, Wei, Gang wrote:
> Ian Campbell wrote on 2012-01-05:
> > On Wed, 2012-01-04 at 21:57 +0000, Kay, Allen M wrote:
> >> Attached patch fix build error in latest xen-unstable.hg.
> > 
> > What is the specific build error?
> > 
> > What version of yajl do you have and on which distro?
> > 
> 
> I am not try to answer this for Allen, but I also met similar build error(it says yajl_gen_no_buf was not defined) in RHEL6.2 64bit with yajl 1.0.7-3.

I use 1.0.8 so I guess this must be new there.

Any patch which says "fix build error/warning/message" should, IMHO,
always include a verbatim copy of the error message being fixed.

Please can one of you resubmit with the changelog corrected in that
manner?

Eventually we could use autoconf to detect this stuff, although that
does sound rather like overkill...

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:11:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RioyR-0000LF-8o; Thu, 05 Jan 2012 15:11:23 +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 1RioyP-0000Kt-Co
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:11:21 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325776274!10669905!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 7045 invoked from network); 5 Jan 2012 15:11:14 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-15.tower-21.messagelabs.com with SMTP;
	5 Jan 2012 15:11:14 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74305064; Thu, 05 Jan 2012 16:11:13 +0100
Message-ID: <1325776241.2728.5.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Thu, 05 Jan 2012 16:10:41 +0100
X-Mailer: Evolution 3.2.2-1 
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] [PATCHv2 0 of 2] 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="===============3106767073735837224=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3106767073735837224==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-7YuUHGMafC2GrzkNY5Jr"


--=-7YuUHGMafC2GrzkNY5Jr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello everyone,

Reposting with after having applied the (minor) fixes suggested by Wei
and Jan.

Allen, if you can tell us what you think about this, or suggest someone
else to ask some feedback to, if you're no longer involved with VT-d,
that would be great! :-)

--

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

--
 iommu-fault-tasklet_vtd.patch
 iommu-fault-tasklet_amd.patch

 xen/drivers/passthrough/amd/iommu_init.c |  47 +++++++++++++++++++++++++++=
+++++++++++++++++---
 xen/drivers/passthrough/vtd/iommu.c      |  39 +++++++++++++++++++++++++++=
+++++++++---
 2 files changed, 80 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)


--=-7YuUHGMafC2GrzkNY5Jr
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)

iEYEABECAAYFAk8FvXEACgkQk4XaBE3IOsQqIQCeMXIeT+kVhoGZppOMVRUSIW8j
9XkAn2N0GtOpinp58IopkOiyMGBrWlJh
=Psx/
-----END PGP SIGNATURE-----

--=-7YuUHGMafC2GrzkNY5Jr--



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

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

--===============3106767073735837224==--



From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:11:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:11:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RioyR-0000LF-8o; Thu, 05 Jan 2012 15:11:23 +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 1RioyP-0000Kt-Co
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:11:21 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-15.tower-21.messagelabs.com!1325776274!10669905!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 7045 invoked from network); 5 Jan 2012 15:11:14 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-15.tower-21.messagelabs.com with SMTP;
	5 Jan 2012 15:11:14 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74305064; Thu, 05 Jan 2012 16:11:13 +0100
Message-ID: <1325776241.2728.5.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Thu, 05 Jan 2012 16:10:41 +0100
X-Mailer: Evolution 3.2.2-1 
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] [PATCHv2 0 of 2] 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="===============3106767073735837224=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3106767073735837224==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-7YuUHGMafC2GrzkNY5Jr"


--=-7YuUHGMafC2GrzkNY5Jr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello everyone,

Reposting with after having applied the (minor) fixes suggested by Wei
and Jan.

Allen, if you can tell us what you think about this, or suggest someone
else to ask some feedback to, if you're no longer involved with VT-d,
that would be great! :-)

--

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

--
 iommu-fault-tasklet_vtd.patch
 iommu-fault-tasklet_amd.patch

 xen/drivers/passthrough/amd/iommu_init.c |  47 +++++++++++++++++++++++++++=
+++++++++++++++++---
 xen/drivers/passthrough/vtd/iommu.c      |  39 +++++++++++++++++++++++++++=
+++++++++---
 2 files changed, 80 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)


--=-7YuUHGMafC2GrzkNY5Jr
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)

iEYEABECAAYFAk8FvXEACgkQk4XaBE3IOsQqIQCeMXIeT+kVhoGZppOMVRUSIW8j
9XkAn2N0GtOpinp58IopkOiyMGBrWlJh
=Psx/
-----END PGP SIGNATURE-----

--=-7YuUHGMafC2GrzkNY5Jr--



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

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

--===============3106767073735837224==--



From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:13:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rip0E-0000Vm-03; Thu, 05 Jan 2012 15:13: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 1Rip0C-0000V5-PH
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:13:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325776386!4418605!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 12995 invoked from network); 5 Jan 2012 15:13: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; 5 Jan 2012 15:13:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Jan 2012 15:14:20 +0000
Message-Id: <4F05CC48020000780006A9C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Jan 2012 15:14:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Gang Wei" <gang.wei@intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Joseph Cihula <joseph.cihula@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: add a new SMP bring up way for tboot
	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.01.12 at 15:53, "Wei, Gang" <gang.wei@intel.com> wrote:
> tboot may be trying to put APs waiting in MWAIT loops before launching Xen. 
> Xen could check the new flag field in v6 tboot shared page for the hint. If 
> TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write the 
> monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MWAIT 
> loops. The sipi vector should be written in g_tboot_shared->ap_wake_addr before 
> waking up APs.
> 
> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
> Signed-off-by: Shane Wang <shane.wang@intel.com>
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r cbf1ce3afd74 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c	Sat Dec 31 16:18:55 2011 +0800
> +++ b/xen/arch/x86/smpboot.c	Sat Dec 31 18:50:14 2011 +0800
> @@ -586,7 +586,9 @@
>      smpboot_setup_warm_reset_vector(start_eip);
>  
>      /* Starting actual IPI sequence... */
> -    boot_error = wakeup_secondary_cpu(apicid, start_eip);
> +    boot_error = tboot_wake_ap(apicid, start_eip);

As tboot.h is being included here anyway, it would seem more clean
to me to guard the call with tboot_in_measured_env() here rather
than in the called function.

> +    if ( boot_error )
> +        boot_error = wakeup_secondary_cpu(apicid, start_eip);
>  
>      if ( !boot_error )
>      {
> diff -r cbf1ce3afd74 xen/arch/x86/tboot.c
> --- a/xen/arch/x86/tboot.c	Sat Dec 31 16:18:55 2011 +0800
> +++ b/xen/arch/x86/tboot.c	Sat Dec 31 18:50:14 2011 +0800
> @@ -123,6 +123,10 @@
>      printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
>      printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
>      printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
> +    if ( tboot_shared->version >= 5 )
> +        printk("  num_in_wfs: %u\n", tboot_shared->num_in_wfs);

You're printing this field, but aren't making any other use of it?

> +    if ( tboot_shared->version >= 6 )
> +        printk("  flags: 0x%08x\n", tboot_shared->flags);
>  
>      /* these will be needed by tboot_protect_mem_regions() and/or
>         tboot_parse_dmar_table(), so get them now */
> @@ -529,6 +533,19 @@
>      panic("Memory integrity was lost on resume (%d)\n", error);
>  }
>  
> +int tboot_wake_ap(int apicid, unsigned long sipi_vec)
> +{
> +    if ( tboot_in_measured_env() && g_tboot_shared->version >= 6 &&
> +         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
> +    {
> +        printk("waking AP %d w/ monitor write\n", apicid);

Please, no once-per-CPU printk()-s, especially if they don't depend on
per-CPU properties.

> +        g_tboot_shared->ap_wake_addr = sipi_vec;
> +        g_tboot_shared->ap_wake_trigger = apicid;
> +        return 0;
> +    }
> +    return -1;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff -r cbf1ce3afd74 xen/include/asm-x86/tboot.h
> --- a/xen/include/asm-x86/tboot.h	Sat Dec 31 16:18:55 2011 +0800
> +++ b/xen/include/asm-x86/tboot.h	Sat Dec 31 18:50:14 2011 +0800
> @@ -85,7 +85,7 @@
>  typedef struct __packed {
>      /* version 3+ fields: */
>      uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
> -    uint32_t  version;           /* Version number; currently supports 0.4 
> */
> +    uint32_t  version;           /* Version number; currently supports 0.6 
> */
>      uint32_t  log_addr;          /* physical addr of tb_log_t log */
>      uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
>      uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
> @@ -99,6 +99,13 @@
>      /* version 4+ fields: */
>                                   /* populated by tboot; will be encrypted 
> */
>      uint8_t   s3_key[TB_KEY_SIZE];
> +    /* version 5+ fields: */
> +    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
> +    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI */
> +    /* version 6+ fields: */
> +    uint32_t  flags;
> +    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
> +    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP */
>  } tboot_shared_t;
>  
>  #define TB_SHUTDOWN_REBOOT      0
> @@ -107,6 +114,9 @@
>  #define TB_SHUTDOWN_S3          3
>  #define TB_SHUTDOWN_HALT        4
>  
> +#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use 
> INIT-SIPI-SIPI
> +                                                 if clear, ap_wake_* if set 
> */
> +
>  /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
>  #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
>                                 { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
> @@ -120,6 +130,7 @@
>  int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
>  int tboot_s3_resume(void);
>  void tboot_s3_error(int error);
> +int tboot_wake_ap(int apicid, unsigned long sipi_vec);
>  
>  #endif /* __TBOOT_H__ */



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:13:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:13:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rip0E-0000Vm-03; Thu, 05 Jan 2012 15:13: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 1Rip0C-0000V5-PH
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:13:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325776386!4418605!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 12995 invoked from network); 5 Jan 2012 15:13: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; 5 Jan 2012 15:13:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 05 Jan 2012 15:14:20 +0000
Message-Id: <4F05CC48020000780006A9C7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 05 Jan 2012 15:14:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Gang Wei" <gang.wei@intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Joseph Cihula <joseph.cihula@intel.com>, "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: add a new SMP bring up way for tboot
	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.01.12 at 15:53, "Wei, Gang" <gang.wei@intel.com> wrote:
> tboot may be trying to put APs waiting in MWAIT loops before launching Xen. 
> Xen could check the new flag field in v6 tboot shared page for the hint. If 
> TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write the 
> monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MWAIT 
> loops. The sipi vector should be written in g_tboot_shared->ap_wake_addr before 
> waking up APs.
> 
> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
> Signed-off-by: Shane Wang <shane.wang@intel.com>
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r cbf1ce3afd74 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c	Sat Dec 31 16:18:55 2011 +0800
> +++ b/xen/arch/x86/smpboot.c	Sat Dec 31 18:50:14 2011 +0800
> @@ -586,7 +586,9 @@
>      smpboot_setup_warm_reset_vector(start_eip);
>  
>      /* Starting actual IPI sequence... */
> -    boot_error = wakeup_secondary_cpu(apicid, start_eip);
> +    boot_error = tboot_wake_ap(apicid, start_eip);

As tboot.h is being included here anyway, it would seem more clean
to me to guard the call with tboot_in_measured_env() here rather
than in the called function.

> +    if ( boot_error )
> +        boot_error = wakeup_secondary_cpu(apicid, start_eip);
>  
>      if ( !boot_error )
>      {
> diff -r cbf1ce3afd74 xen/arch/x86/tboot.c
> --- a/xen/arch/x86/tboot.c	Sat Dec 31 16:18:55 2011 +0800
> +++ b/xen/arch/x86/tboot.c	Sat Dec 31 18:50:14 2011 +0800
> @@ -123,6 +123,10 @@
>      printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
>      printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
>      printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
> +    if ( tboot_shared->version >= 5 )
> +        printk("  num_in_wfs: %u\n", tboot_shared->num_in_wfs);

You're printing this field, but aren't making any other use of it?

> +    if ( tboot_shared->version >= 6 )
> +        printk("  flags: 0x%08x\n", tboot_shared->flags);
>  
>      /* these will be needed by tboot_protect_mem_regions() and/or
>         tboot_parse_dmar_table(), so get them now */
> @@ -529,6 +533,19 @@
>      panic("Memory integrity was lost on resume (%d)\n", error);
>  }
>  
> +int tboot_wake_ap(int apicid, unsigned long sipi_vec)
> +{
> +    if ( tboot_in_measured_env() && g_tboot_shared->version >= 6 &&
> +         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
> +    {
> +        printk("waking AP %d w/ monitor write\n", apicid);

Please, no once-per-CPU printk()-s, especially if they don't depend on
per-CPU properties.

> +        g_tboot_shared->ap_wake_addr = sipi_vec;
> +        g_tboot_shared->ap_wake_trigger = apicid;
> +        return 0;
> +    }
> +    return -1;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff -r cbf1ce3afd74 xen/include/asm-x86/tboot.h
> --- a/xen/include/asm-x86/tboot.h	Sat Dec 31 16:18:55 2011 +0800
> +++ b/xen/include/asm-x86/tboot.h	Sat Dec 31 18:50:14 2011 +0800
> @@ -85,7 +85,7 @@
>  typedef struct __packed {
>      /* version 3+ fields: */
>      uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
> -    uint32_t  version;           /* Version number; currently supports 0.4 
> */
> +    uint32_t  version;           /* Version number; currently supports 0.6 
> */
>      uint32_t  log_addr;          /* physical addr of tb_log_t log */
>      uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
>      uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
> @@ -99,6 +99,13 @@
>      /* version 4+ fields: */
>                                   /* populated by tboot; will be encrypted 
> */
>      uint8_t   s3_key[TB_KEY_SIZE];
> +    /* version 5+ fields: */
> +    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
> +    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI */
> +    /* version 6+ fields: */
> +    uint32_t  flags;
> +    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
> +    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP */
>  } tboot_shared_t;
>  
>  #define TB_SHUTDOWN_REBOOT      0
> @@ -107,6 +114,9 @@
>  #define TB_SHUTDOWN_S3          3
>  #define TB_SHUTDOWN_HALT        4
>  
> +#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use 
> INIT-SIPI-SIPI
> +                                                 if clear, ap_wake_* if set 
> */
> +
>  /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
>  #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
>                                 { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
> @@ -120,6 +130,7 @@
>  int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
>  int tboot_s3_resume(void);
>  void tboot_s3_error(int error);
> +int tboot_wake_ap(int apicid, unsigned long sipi_vec);
>  
>  #endif /* __TBOOT_H__ */



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:17:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rip4U-0000sn-OJ; Thu, 05 Jan 2012 15:17:38 +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 1Rip4S-0000sI-4z
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:17:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-182.messagelabs.com!1325776646!2325995!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 1305 invoked from network); 5 Jan 2012 15:17:26 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 15:17:26 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74305199; Thu, 05 Jan 2012 16:17:24 +0100
Message-ID: <1325776621.2728.7.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 05 Jan 2012 16:17:01 +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] [PATCHv3] 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="===============0162675564886136273=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0162675564886136273==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-BVBDbEUzgZPrsy4cOGLY"


--=-BVBDbEUzgZPrsy4cOGLY
Content-Type: multipart/mixed; boundary="=-Q+nO0nZUPH9ih0IDSLo0"


--=-Q+nO0nZUPH9ih0IDSLo0
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 efaa28639a71 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Jan 04 16:12:44 2012 +0000
+++ b/xen/common/sched_sedf.c	Thu Jan 05 15:02:30 2012 +0100
@@ -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
@@ -71,34 +63,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;   /* =3D worst 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
@@ -165,18 +158,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)
 {
@@ -185,11 +177,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.
@@ -200,25 +187,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
@@ -228,29 +208,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
@@ -259,7 +224,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
@@ -272,8 +237,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));
@@ -286,13 +249,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
@@ -310,30 +272,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
@@ -361,12 +321,12 @@ static void *sedf_alloc_vdata(const stru
=20
     inf->vcpu =3D v;
=20
-    /* Every VCPU gets an equal share of extratime by default. */
+    /* Every VCPU gets an equal share of extratime by default */
     inf->deadl_abs   =3D 0;
     inf->latency     =3D 0;
     inf->status      =3D EXTRA_AWARE | SEDF_ASLEEP;
     inf->extraweight =3D 1;
-    /* Upon creation all domain are best-effort. */
+    /* Upon creation all domain are best-effort */
     inf->period      =3D WEIGHT_PERIOD;
     inf->slice       =3D 0;
=20
@@ -450,21 +410,19 @@ 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
-    /*
-     * Scheduling decisions which don't remove the running domain from the
-     * runq.=20
-     */
+    /* Scheduling decisions which don't remove the running domain from
+     * the runq */
     if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
         return;
  =20
     __del_from_queue(d);
- =20
+
     /*
      * Manage bookkeeping (i.e. calculate next deadline, memorise
      * overrun-time of slice) of finished domains.
@@ -475,30 +433,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) )
@@ -518,8 +476,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.
@@ -527,41 +483,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) ||
@@ -571,18 +518,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.
@@ -593,7 +540,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);
@@ -603,17 +550,17 @@ static void update_queues(
         else
             break;
     }
-
-    PRINT(3,"done updating the queues\n");
 }
=20
=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);
@@ -622,29 +569,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
@@ -653,51 +596,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) )
@@ -729,8 +680,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;
@@ -744,7 +697,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]);
@@ -794,11 +747,13 @@ static void sedf_deinit(const struct sch
 }
=20
=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)
 {
@@ -811,13 +766,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
@@ -826,7 +783,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
@@ -836,10 +793,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)))) )
@@ -855,9 +814,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;
         }
@@ -869,14 +830,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",
@@ -896,9 +861,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
@@ -920,7 +882,8 @@ static void sedf_sleep(const struct sche
 }
=20
=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
@@ -994,27 +957,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 )
         {
@@ -1024,28 +991,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
=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;
 }
@@ -1068,15 +1038,17 @@ static inline int get_run_type(struct vc
 }
=20
=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)
@@ -1085,26 +1057,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;
@@ -1118,18 +1089,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;
@@ -1138,28 +1102,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);
@@ -1168,8 +1129,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
@@ -1179,8 +1139,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
@@ -1190,24 +1149,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;
@@ -1216,12 +1164,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);
@@ -1266,7 +1216,7 @@ static void sedf_dump_domain(struct vcpu
 }
=20
=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;
@@ -1341,16 +1291,18 @@ static void sedf_dump_cpu_state(const st
 }
=20
=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, int nr_cpus, int *sumw, =
s_time_t *sumt)
 {
     struct vcpu *p;
     struct domain      *d;
     unsigned int        cpu;
=20
-    /* Sum across all weights. Notice that no runq locking is needed
+    /*
+     * 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. */
+     * anything that is accessed during scheduling.
+     */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1365,11 +1317,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
@@ -1380,9 +1335,11 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. Unlike above, we
+    /*
+     * 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. */
+     * slice and period which are referenced during scheduling.
+     */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1410,7 +1367,7 @@ static int sedf_adjust_weights(struct cp
 }
=20
=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 sedf_priv_info *prv =3D SEDF_PRIV(ops);
@@ -1421,23 +1378,22 @@ static int sedf_adjust(const struct sche
     struct vcpu *v;
     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");
-
-    /* Serialize against the pluggable scheduler lock to protect from
+    /*
+     * 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. */
+     * pluggable scheduler lock.
+     */
     spin_lock_irqsave(&prv->lock, flags);
=20
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
-        /* These are used in sedf_adjust_weights() but have to be allocate=
d in
+        /*
+         * 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. */
+         * within our prv->lock.
+         */
         if ( !sumw || !sumt )
         {
             /* Check for errors here, the _getinfo branch doesn't care */
@@ -1445,7 +1401,7 @@ static int sedf_adjust(const struct sche
             goto out;
         }
=20
-        /* Check for sane parameters. */
+        /* Check for sane parameters */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
         {
             rc =3D -EINVAL;
@@ -1457,7 +1413,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 )
                 {
                     /* (Here and everywhere in the following) IRQs are alr=
eady off,
@@ -1472,7 +1428,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 ) {
                     vcpu_schedule_lock(v);
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
@@ -1495,7 +1451,7 @@ static int sedf_adjust(const struct sche
                 goto out;
             }
=20
-            /* Time-driven domains. */
+            /* Time-driven domains */
             for_each_vcpu ( p, v )
             {
                 vcpu_schedule_lock(v);
@@ -1545,7 +1501,6 @@ out:
     xfree(sumt);
     xfree(sumw);
=20
-    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
     return rc;
 }
=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)


--=-Q+nO0nZUPH9ih0IDSLo0
Content-Disposition: attachment; filename="sedf-debug-cleanup.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="sedf-debug-cleanup.patch"; charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGVmYWEyODYzOWE3MTUyNGE2OTNiYTUwMDYy
NGY4NTEyZTU3OTVlMTgNCnNlZGY6IHJlbW92ZSB1c2VsZXNzIHRyYWNpbmcgcHJpbnRrIGFuZCBo
YXJtb25pemUgY29tbWVudHMgc3R5bGUuDQoNCnNjaGVkX3NlZGYuYyB1c2VkIG8gaGF2ZSBpdHMg
b3duIG1lY2hhbmlzbSBmb3IgcHJvZHVjaW5nIHRyYWNpbmctYWxpa2UNCmtpbmQgb2YgaW5mb3Jt
YXRpb24gKGRvbWFpbiBibG9jaywgd2FrZXVwLCBldGMuKS4gTm93YWRheXMsIHdpdGggYW4gZXZl
bg0Kbm90IHNvIGhpZ2ggbnVtYmVyIG9mIHBDUFVzL3ZDUFVzLCBqdXN0IHRyeWluZyB0byBlbmFi
bGUgdGhpcyBtYWtlcw0KdGhlIHNlcmlhbCBjb25zb2xlIGNvbXBsZXRlbHkgdW51c2FibGUsIHBy
b2R1Y2VzIHRvbnMgb2YgdmVyeSBoYXJkIHRvDQpwYXJzZSBhbmQgaW50ZXJwcmVldCBsb2dnaW5n
IGFuZCBjYW4gZWFzaWx5IGxpdmVsb2NrIERvbTAuIE1vcmVvdmVyLA0KcHJldHR5IG11Y2ggdGhl
IHNhbWUgcmVzdWx0IHRoaXMgaXMgc3RydWdnbGluZyB0byBnZXQgdG8sIGlzIGJldHRlcg0KYWNo
aWV2ZWQgYnkgZW5hYmxpbmcgdGhlIHNjaGVkdWxlci1yZWxhdGVkIHRyYWNpbmcgZXZlbnRzLCBh
cw0KaXQgaXMgZm9yIHRoZSBvdGhlciBzY2hlZHVsZXJzIChzYXksIGNyZWRpdCBvciBjcmVkaXQy
KS4NCg0KRm9yIGFsbCB0aGVzZSByZWFzb25zLCB0aGlzIHJlbW92ZXMgdGhhdCBtYWNoaW5lcnkg
Y29tcGxldGVseS4gV2hpbGUgYXQNCml0LCBjaGVjayBpbiBzb21lIGNvc21ldGljcyB0aGF0IGhh
cm1vbml6ZSB0aGUgY29tbWVudHMgd2l0aGltIHRoZW1zZWxmDQphbmQgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY29kZSBiYXNlLg0KDQpTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8u
ZmFnZ2lvbGlAY2l0cml4LmNvbT4NCg0KZGlmZiAtciBlZmFhMjg2MzlhNzEgeGVuL2NvbW1vbi9z
Y2hlZF9zZWRmLmMNCi0tLSBhL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCVdlZCBKYW4gMDQgMTY6
MTI6NDQgMjAxMiArMDAwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJVGh1IEphbiAw
NSAxNTowMjozMCAyMDEyICswMTAwDQpAQCAtMTMsMTQgKzEzLDYgQEANCiAjaW5jbHVkZSA8eGVu
L3RpbWUuaD4NCiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQogDQotLyp2ZXJib3NpdHkgc2V0dGlu
Z3MqLw0KLSNkZWZpbmUgU0VERkxFVkVMIDANCi0jZGVmaW5lIFBSSU5UKF9mLCBfYS4uLikgICAg
ICAgICAgICAgICAgICAgICAgICBcDQotICAgIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KLSAgICAgICAgaWYgKCAoX2YpIDw9IFNFREZMRVZFTCApICAgICAg
ICAgICAgICAgIFwNCi0gICAgICAgICAgICBwcmludGsoX2EgKTsgICAgICAgICAgICAgICAgICAg
ICAgICBcDQotICAgIH0gd2hpbGUgKCAwICkNCi0NCiAjZGVmaW5lIFNFREZfQ1BVT05MSU5FKF9w
b29sKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAg
KCgoX3Bvb2wpID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9jcHVzIDogKF9wb29sKS0+Y3B1X3Zh
bGlkKQ0KIA0KQEAgLTcxLDM0ICs2MywzNSBAQCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gew0KICAg
ICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgZXh0cmFsaXN0
WzJdOw0KICANCi0gICAgLypQYXJhbWV0ZXJzIGZvciBFREYqLw0KLSAgICBzX3RpbWVfdCAgcGVy
aW9kOyAgLyo9KHJlbGF0aXZlIGRlYWRsaW5lKSovDQotICAgIHNfdGltZV90ICBzbGljZTsgIC8q
PXdvcnN0IGNhc2UgZXhlY3V0aW9uIHRpbWUqLw0KKyAgICAvKiBQYXJhbWV0ZXJzIGZvciBFREYg
Ki8NCisgICAgc190aW1lX3QgIHBlcmlvZDsgIC8qID0gcmVsYXRpdmUgZGVhZGxpbmUgKi8NCisg
ICAgc190aW1lX3QgIHNsaWNlOyAgIC8qID0gd29yc3QgY2FzZSBleGVjdXRpb24gdGltZSAqLw0K
ICANCi0gICAgLypBZHZhY2VkIFBhcmFtZXRlcnMqLw0KLSAgICAvKkxhdGVuY3kgU2NhbGluZyov
DQorICAgIC8qIEFkdmFjZWQgUGFyYW1ldGVycyAqLw0KKw0KKyAgICAvKiBMYXRlbmN5IFNjYWxp
bmcgKi8NCiAgICAgc190aW1lX3QgIHBlcmlvZF9vcmlnOw0KICAgICBzX3RpbWVfdCAgc2xpY2Vf
b3JpZzsNCiAgICAgc190aW1lX3QgIGxhdGVuY3k7DQogIA0KLSAgICAvKnN0YXR1cyBvZiBkb21h
aW4qLw0KKyAgICAvKiBTdGF0dXMgb2YgZG9tYWluICovDQogICAgIGludCAgICAgICBzdGF0dXM7
DQotICAgIC8qd2VpZ2h0cyBmb3IgIlNjaGVkdWxpbmcgZm9yIGJlZ2lubmVycy8gbGF6eS8gZXRj
LiIgOykqLw0KKyAgICAvKiBXZWlnaHRzIGZvciAiU2NoZWR1bGluZyBmb3IgYmVnaW5uZXJzLyBs
YXp5LyBldGMuIiA7KSAqLw0KICAgICBzaG9ydCAgICAgd2VpZ2h0Ow0KICAgICBzaG9ydCAgICAg
ZXh0cmF3ZWlnaHQ7DQotICAgIC8qQm9va2tlZXBpbmcqLw0KKyAgICAvKiBCb29ra2VlcGluZyAq
Lw0KICAgICBzX3RpbWVfdCAgZGVhZGxfYWJzOw0KICAgICBzX3RpbWVfdCAgc2NoZWRfc3RhcnRf
YWJzOw0KICAgICBzX3RpbWVfdCAgY3B1dGltZTsNCi0gICAgLyogdGltZXMgdGhlIGRvbWFpbiB1
bi0vYmxvY2tlZCAqLw0KKyAgICAvKiBUaW1lcyB0aGUgZG9tYWluIHVuLS9ibG9ja2VkICovDQog
ICAgIHNfdGltZV90ICBibG9ja19hYnM7DQogICAgIHNfdGltZV90ICB1bmJsb2NrX2FiczsNCiAg
DQotICAgIC8qc2NvcmVzIGZvciB7dXRpbCwgYmxvY2sgcGVuYWx0eX0td2VpZ2h0ZWQgZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiovDQorICAgIC8qIFNjb3JlcyBmb3Ige3V0aWwsIGJsb2NrIHBlbmFs
dHl9LXdlaWdodGVkIGV4dHJhdGltZSBkaXN0cmlidXRpb24gKi8NCiAgICAgaW50ICAgc2NvcmVb
Ml07DQogICAgIHNfdGltZV90ICBzaG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgDQotICAgIC8qU3Rh
dGlzdGljcyovDQorICAgIC8qIFN0YXRpc3RpY3MgKi8NCiAgICAgc190aW1lX3QgIGV4dHJhX3Rp
bWVfdG90Ow0KIA0KICNpZmRlZiBTRURGX1NUQVRTDQpAQCAtMTY1LDE4ICsxNTgsMTcgQEAgc3Rh
dGljIGlubGluZSB2b2lkIGV4dHJhcV9kZWwoc3RydWN0IHZjcA0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IEVYVFJBTElTVChkLGkpOw0KICAgICBBU1NFUlQoZXh0cmFxX29uKGQs
aSkpOw0KLSAgICBQUklOVCgzLCAiUmVtb3ZpbmcgZG9tYWluICVpLiVpIGZyb20gTCVpIGV4dHJh
cVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGkpOw0K
ICAgICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VS
VCghZXh0cmFxX29uKGQsIGkpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUgcXVl
dWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQotICAg
aXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBwcmlv
cml0eSBmb3IgYW4gZXh0cmENCi0gICBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29yZSwg
Ynkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KLSAgIGVhY2ggZW50cnks
IGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNpbXBs
eQ0KLSAgIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdpdGgg
YW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KKy8qDQorICogQWRkcyBhIGRvbWFpbiB0byB0aGUg
cXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQor
ICogaXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBw
cmlvcml0eSBmb3IgYW4gZXh0cmENCisgKiBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29y
ZSwgYnkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KKyAqIGVhY2ggZW50
cnksIGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNp
bXBseQ0KKyAqIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdp
dGggYW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KICAqLyANCiBzdGF0aWMgaW5saW5lIHZvaWQg
ZXh0cmFxX2FkZF9zb3J0X3VwZGF0ZShzdHJ1Y3QgdmNwdSAqZCwgaW50IGksIGludCBzdWIpDQog
ew0KQEAgLTE4NSwxMSArMTc3LDYgQEAgc3RhdGljIGlubGluZSB2b2lkIGV4dHJhcV9hZGRfc29y
dF91cGRhdA0KICANCiAgICAgQVNTRVJUKCFleHRyYXFfb24oZCxpKSk7DQogDQotICAgIFBSSU5U
KDMsICJBZGRpbmcgZG9tYWluICVpLiVpIChzY29yZT0gJWksIHNob3J0X3Blbj0gJSJQUklpNjQi
KSINCi0gICAgICAgICAgIiB0byBMJWkgZXh0cmFxXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4t
PmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgRURPTV9JTkZPKGQpLT5zY29yZVtpXSwNCi0gICAgICAg
ICAgRURPTV9JTkZPKGQpLT5zaG9ydF9ibG9ja19sb3N0X3RvdCwgaSk7DQotDQogICAgIC8qDQog
ICAgICAqIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIgImhvbGUiIGFu
ZCBvbiBvdXIgd2F5DQogICAgICAqIHVwZGF0ZSBhbGwgdGhlIG90aGVyIHNjb3Jlcy4NCkBAIC0y
MDAsMjUgKzE4NywxOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgZXh0cmFxX2FkZF9zb3J0X3VwZGF0
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
IC0yMjgsMjkgKzIwOCwxNCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgZXh0cmFxX2NoZWNrKHN0cnVj
dCB2DQogew0KICAgICBpZiAoIGV4dHJhcV9vbihkLCBFWFRSQV9VVElMX1EpICkNCiAgICAgew0K
LSAgICAgICAgUFJJTlQoMiwiRG9tICVpLiVpIGlzIG9uIEwxIGV4dHJhUVxuIiwNCi0gICAgICAg
ICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0NCiAgICAgICAgIGlm
ICggIShFRE9NX0lORk8oZCktPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJg0KICAgICAgICAgICAg
ICAhZXh0cmFfcnVucyhFRE9NX0lORk8oZCkpICkNCi0gICAgICAgIHsNCiAgICAgICAgICAgICBl
eHRyYXFfZGVsKGQsIEVYVFJBX1VUSUxfUSk7DQotICAgICAgICAgICAgUFJJTlQoMiwiUmVtb3Zl
ZCBkb20gJWkuJWkgZnJvbSBMMSBleHRyYVFcbiIsDQotICAgICAgICAgICAgICAgICAgZC0+ZG9t
YWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQpOw0KLSAgICAgICAgfQ0KICAgICB9DQogICAgIGVs
c2UNCiAgICAgew0KLSAgICAgICAgUFJJTlQoMiwgIkRvbSAlaS4laSBpcyBOT1Qgb24gTDEgZXh0
cmFRXG4iLA0KLSAgICAgICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAgICAg
ICAgICBkLT52Y3B1X2lkKTsNCi0NCiAgICAgICAgIGlmICggKEVET01fSU5GTyhkKS0+c3RhdHVz
ICYgRVhUUkFfQVdBUkUpICYmIHNlZGZfcnVubmFibGUoZCkgKQ0KLSAgICAgICAgew0KICAgICAg
ICAgICAgIGV4dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfVVRJTF9RLCAwKTsNCi0gICAg
ICAgICAgICBQUklOVCgyLCJBZGRlZCBkb20gJWkuJWkgdG8gTDEgZXh0cmFRXG4iLA0KLSAgICAg
ICAgICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gICAgICAg
IH0NCiAgICAgfQ0KIH0NCiANCkBAIC0yNTksNyArMjI0LDcgQEAgc3RhdGljIGlubGluZSB2b2lk
IGV4dHJhcV9jaGVja19hZGRfdW5ibA0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gKmluZiA9
IEVET01fSU5GTyhkKTsNCiANCiAgICAgaWYgKCBpbmYtPnN0YXR1cyAmIEVYVFJBX0FXQVJFICkN
Ci0gICAgICAgIC8qIFB1dCBvbiB0aGUgd2VpZ2h0ZWQgZXh0cmFxIHdpdGhvdXQgdXBkYXRpbmcg
YW55IHNjb3Jlcy4gKi8NCisgICAgICAgIC8qIFB1dCBvbiB0aGUgd2VpZ2h0ZWQgZXh0cmFxIHdp
dGhvdXQgdXBkYXRpbmcgYW55IHNjb3JlcyAqLw0KICAgICAgICAgZXh0cmFxX2FkZF9zb3J0X3Vw
ZGF0ZShkLCBFWFRSQV9VVElMX1EsIDApOw0KIH0NCiANCkBAIC0yNzIsOCArMjM3LDYgQEAgc3Rh
dGljIGlubGluZSB2b2lkIF9fZGVsX2Zyb21fcXVldWUoc3RydQ0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IExJU1QoZCk7DQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkp
Ow0KLSAgICBQUklOVCgzLCJSZW1vdmluZyBkb21haW4gJWkuJWkgKGJvcD0gJSJQUkl1NjQiKSBm
cm9tIHJ1bnEvd2FpdHFcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52
Y3B1X2lkLCBQRVJJT0RfQkVHSU4oRURPTV9JTkZPKGQpKSk7DQogICAgIGxpc3RfZGVsKGxpc3Qp
Ow0KICAgICBsaXN0LT5uZXh0ID0gTlVMTDsNCiAgICAgQVNTRVJUKCFfX3Rhc2tfb25fcXVldWUo
ZCkpOw0KQEAgLTI4NiwxMyArMjQ5LDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBsaXN0X2luc2Vy
dF9zb3J0KA0KIHsNCiAgICAgc3RydWN0IGxpc3RfaGVhZCAgICAgKmN1cjsNCiANCi0gICAgLyog
SXRlcmF0ZSB0aHJvdWdoIGFsbCBlbGVtZW50cyB0byBmaW5kIG91ciAiaG9sZSIuICovDQorICAg
IC8qIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIgImhvbGUiICovDQog
ICAgIGxpc3RfZm9yX2VhY2goIGN1ciwgbGlzdCApDQogICAgICAgICBpZiAoIGNvbXAoZWxlbWVu
dCwgY3VyKSA8IDAgKQ0KICAgICAgICAgICAgIGJyZWFrOw0KIA0KLSAgICAvKiBjdXIgbm93IGNv
bnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUgd2hpY2ggd2UnbGwgZW5xdWV1ZS4gKi8NCi0gICAg
UFJJTlQoMywiXHRsaXN0X2FkZCB0byAlcFxuIixjdXItPnByZXYpOw0KKyAgICAvKiBjdXIgbm93
IGNvbnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUgd2hpY2ggd2UnbGwgZW5xdWV1ZSAqLw0KICAg
ICBsaXN0X2FkZChlbGVtZW50LCBjdXItPnByZXYpOw0KIH0NCiANCkBAIC0zMTAsMzAgKzI3Miwy
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
ciksIExJU1QodiksIHJ1bnFfY29tcCk7DQogfQ0KIA0KQEAgLTM2MSwxMiArMzIxLDEyIEBAIHN0
YXRpYyB2b2lkICpzZWRmX2FsbG9jX3ZkYXRhKGNvbnN0IHN0cnUNCiANCiAgICAgaW5mLT52Y3B1
ID0gdjsNCiANCi0gICAgLyogRXZlcnkgVkNQVSBnZXRzIGFuIGVxdWFsIHNoYXJlIG9mIGV4dHJh
dGltZSBieSBkZWZhdWx0LiAqLw0KKyAgICAvKiBFdmVyeSBWQ1BVIGdldHMgYW4gZXF1YWwgc2hh
cmUgb2YgZXh0cmF0aW1lIGJ5IGRlZmF1bHQgKi8NCiAgICAgaW5mLT5kZWFkbF9hYnMgICA9IDA7
DQogICAgIGluZi0+bGF0ZW5jeSAgICAgPSAwOw0KICAgICBpbmYtPnN0YXR1cyAgICAgID0gRVhU
UkFfQVdBUkUgfCBTRURGX0FTTEVFUDsNCiAgICAgaW5mLT5leHRyYXdlaWdodCA9IDE7DQotICAg
IC8qIFVwb24gY3JlYXRpb24gYWxsIGRvbWFpbiBhcmUgYmVzdC1lZmZvcnQuICovDQorICAgIC8q
IFVwb24gY3JlYXRpb24gYWxsIGRvbWFpbiBhcmUgYmVzdC1lZmZvcnQgKi8NCiAgICAgaW5mLT5w
ZXJpb2QgICAgICA9IFdFSUdIVF9QRVJJT0Q7DQogICAgIGluZi0+c2xpY2UgICAgICAgPSAwOw0K
IA0KQEAgLTQ1MCwyMSArNDEwLDE5IEBAIHN0YXRpYyB2b2lkIGRlc2NoZWRfZWRmX2RvbShzX3Rp
bWVfdCBub3cNCiB7DQogICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyogaW5mID0gRURPTV9JTkZP
KGQpOw0KIA0KLSAgICAvKiBDdXJyZW50IGRvbWFpbiBpcyBydW5uaW5nIGluIHJlYWwgdGltZSBt
b2RlLiAqLw0KKyAgICAvKiBDdXJyZW50IGRvbWFpbiBpcyBydW5uaW5nIGluIHJlYWwgdGltZSBt
b2RlICovDQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkpOw0KIA0KLSAgICAvKiBVcGRh
dGUgdGhlIGRvbWFpbidzIGNwdXRpbWUuICovDQorICAgIC8qIFVwZGF0ZSB0aGUgZG9tYWluJ3Mg
Y3B1dGltZSAqLw0KICAgICBpbmYtPmNwdXRpbWUgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9h
YnM7DQogDQotICAgIC8qDQotICAgICAqIFNjaGVkdWxpbmcgZGVjaXNpb25zIHdoaWNoIGRvbid0
IHJlbW92ZSB0aGUgcnVubmluZyBkb21haW4gZnJvbSB0aGUNCi0gICAgICogcnVucS4gDQotICAg
ICAqLw0KKyAgICAvKiBTY2hlZHVsaW5nIGRlY2lzaW9ucyB3aGljaCBkb24ndCByZW1vdmUgdGhl
IHJ1bm5pbmcgZG9tYWluIGZyb20NCisgICAgICogdGhlIHJ1bnEgKi8NCiAgICAgaWYgKCAoaW5m
LT5jcHV0aW1lIDwgaW5mLT5zbGljZSkgJiYgc2VkZl9ydW5uYWJsZShkKSApDQogICAgICAgICBy
ZXR1cm47DQogICANCiAgICAgX19kZWxfZnJvbV9xdWV1ZShkKTsNCi0gIA0KKw0KICAgICAvKg0K
ICAgICAgKiBNYW5hZ2UgYm9va2tlZXBpbmcgKGkuZS4gY2FsY3VsYXRlIG5leHQgZGVhZGxpbmUs
IG1lbW9yaXNlDQogICAgICAqIG92ZXJydW4tdGltZSBvZiBzbGljZSkgb2YgZmluaXNoZWQgZG9t
YWlucy4NCkBAIC00NzUsMzAgKzQzMywzMCBAQCBzdGF0aWMgdm9pZCBkZXNjaGVkX2VkZl9kb20o
c190aW1lX3Qgbm93DQogICANCiAgICAgICAgIGlmICggaW5mLT5wZXJpb2QgPCBpbmYtPnBlcmlv
ZF9vcmlnICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKiBUaGlzIGRvbWFpbiBydW5zIGlu
IGxhdGVuY3kgc2NhbGluZyBvciBidXJzdCBtb2RlLiAqLw0KKyAgICAgICAgICAgIC8qIFRoaXMg
ZG9tYWluIHJ1bnMgaW4gbGF0ZW5jeSBzY2FsaW5nIG9yIGJ1cnN0IG1vZGUgKi8NCiAgICAgICAg
ICAgICBpbmYtPnBlcmlvZCAqPSAyOw0KICAgICAgICAgICAgIGluZi0+c2xpY2UgICo9IDI7DQog
ICAgICAgICAgICAgaWYgKCAoaW5mLT5wZXJpb2QgPiBpbmYtPnBlcmlvZF9vcmlnKSB8fA0KICAg
ICAgICAgICAgICAgICAgKGluZi0+c2xpY2UgPiBpbmYtPnNsaWNlX29yaWcpICkNCiAgICAgICAg
ICAgICB7DQotICAgICAgICAgICAgICAgIC8qIFJlc2V0IHNsaWNlIGFuZCBwZXJpb2QuICovDQor
ICAgICAgICAgICAgICAgIC8qIFJlc2V0IHNsaWNlIGFuZCBwZXJpb2QgKi8NCiAgICAgICAgICAg
ICAgICAgaW5mLT5wZXJpb2QgPSBpbmYtPnBlcmlvZF9vcmlnOw0KICAgICAgICAgICAgICAgICBp
bmYtPnNsaWNlID0gaW5mLT5zbGljZV9vcmlnOw0KICAgICAgICAgICAgIH0NCiAgICAgICAgIH0N
CiANCi0gICAgICAgIC8qIFNldCBuZXh0IGRlYWRsaW5lLiAqLw0KKyAgICAgICAgLyogU2V0IG5l
eHQgZGVhZGxpbmUgKi8NCiAgICAgICAgIGluZi0+ZGVhZGxfYWJzICs9IGluZi0+cGVyaW9kOw0K
ICAgICB9DQogIA0KLSAgICAvKiBBZGQgYSBydW5uYWJsZSBkb21haW4gdG8gdGhlIHdhaXRxdWV1
ZS4gKi8NCisgICAgLyogQWRkIGEgcnVubmFibGUgZG9tYWluIHRvIHRoZSB3YWl0cXVldWUgKi8N
CiAgICAgaWYgKCBzZWRmX3J1bm5hYmxlKGQpICkNCiAgICAgew0KICAgICAgICAgX19hZGRfdG9f
d2FpdHF1ZXVlX3NvcnQoZCk7DQogICAgIH0NCiAgICAgZWxzZQ0KICAgICB7DQotICAgICAgICAv
KiBXZSBoYXZlIGEgYmxvY2tlZCByZWFsdGltZSB0YXNrIC0+IHJlbW92ZSBpdCBmcm9tIGV4cXMg
dG9vLiAqLw0KKyAgICAgICAgLyogV2UgaGF2ZSBhIGJsb2NrZWQgcmVhbHRpbWUgdGFzayAtPiBy
ZW1vdmUgaXQgZnJvbSBleHFzIHRvbyAqLw0KICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhU
UkFfUEVOX1EpICkNCiAgICAgICAgICAgICBleHRyYXFfZGVsKGQsIEVYVFJBX1BFTl9RKTsNCiAg
ICAgICAgIGlmICggZXh0cmFxX29uKGQsIEVYVFJBX1VUSUxfUSkgKQ0KQEAgLTUxOCw4ICs0NzYs
NiBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfcXVldWVzKA0KICAgICBzdHJ1Y3QgbGlzdF9oZWFkICAg
ICAqY3VyLCAqdG1wOw0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gKmN1cmluZjsNCiAgDQot
ICAgIFBSSU5UKDMsIlVwZGF0aW5nIHdhaXRxLi5cbiIpOw0KLQ0KICAgICAvKg0KICAgICAgKiBD
aGVjayBmb3IgdGhlIGZpcnN0IGVsZW1lbnRzIG9mIHRoZSB3YWl0cXVldWUsIHdoZXRoZXIgdGhl
aXINCiAgICAgICogbmV4dCBwZXJpb2QgaGFzIGFscmVhZHkgc3RhcnRlZC4NCkBAIC01MjcsNDEg
KzQ4MywzMiBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfcXVldWVzKA0KICAgICBsaXN0X2Zvcl9lYWNo
X3NhZmUgKCBjdXIsIHRtcCwgd2FpdHEgKQ0KICAgICB7DQogICAgICAgICBjdXJpbmYgPSBsaXN0
X2VudHJ5KGN1ciwgc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBsaXN0KTsNCi0gICAgICAgIFBSSU5U
KDQsIlx0TG9va2luZyBAIGRvbSAlaS4laVxuIiwNCi0gICAgICAgICAgICAgIGN1cmluZi0+dmNw
dS0+ZG9tYWluLT5kb21haW5faWQsIGN1cmluZi0+dmNwdS0+dmNwdV9pZCk7DQogICAgICAgICBp
ZiAoIFBFUklPRF9CRUdJTihjdXJpbmYpID4gbm93ICkNCiAgICAgICAgICAgICBicmVhazsNCiAg
ICAgICAgIF9fZGVsX2Zyb21fcXVldWUoY3VyaW5mLT52Y3B1KTsNCiAgICAgICAgIF9fYWRkX3Rv
X3J1bnF1ZXVlX3NvcnQoY3VyaW5mLT52Y3B1KTsNCiAgICAgfQ0KICANCi0gICAgUFJJTlQoMywi
VXBkYXRpbmcgcnVucS4uXG4iKTsNCi0NCi0gICAgLyogUHJvY2VzcyB0aGUgcnVucSwgZmluZCBk
b21haW5zIHRoYXQgYXJlIG9uIHRoZSBydW5xIHRoYXQgc2hvdWxkbid0LiAqLw0KKyAgICAvKiBQ
cm9jZXNzIHRoZSBydW5xLCBmaW5kIGRvbWFpbnMgdGhhdCBhcmUgb24gdGhlIHJ1bnEgdGhhdCBz
aG91bGRuJ3QgKi8NCiAgICAgbGlzdF9mb3JfZWFjaF9zYWZlICggY3VyLCB0bXAsIHJ1bnEgKQ0K
ICAgICB7DQogICAgICAgICBjdXJpbmYgPSBsaXN0X2VudHJ5KGN1cixzdHJ1Y3Qgc2VkZl92Y3B1
X2luZm8sbGlzdCk7DQotICAgICAgICBQUklOVCg0LCJcdExvb2tpbmcgQCBkb20gJWkuJWlcbiIs
DQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCBjdXJpbmYt
PnZjcHUtPnZjcHVfaWQpOw0KIA0KICAgICAgICAgaWYgKCB1bmxpa2VseShjdXJpbmYtPnNsaWNl
ID09IDApICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKiBJZ25vcmUgZG9tYWlucyB3aXRo
IGVtcHR5IHNsaWNlLiAqLw0KLSAgICAgICAgICAgIFBSSU5UKDQsIlx0VXBkYXRpbmcgemVyby1z
bGljZSBkb21haW4gJWkuJWlcbiIsDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5k
b21haW4tPmRvbWFpbl9pZCwNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPnZjcHVf
aWQpOw0KKyAgICAgICAgICAgIC8qIElnbm9yZSBkb21haW5zIHdpdGggZW1wdHkgc2xpY2UgKi8N
CiAgICAgICAgICAgICBfX2RlbF9mcm9tX3F1ZXVlKGN1cmluZi0+dmNwdSk7DQogDQotICAgICAg
ICAgICAgLyogTW92ZSB0aGVtIHRvIHRoZWlyIG5leHQgcGVyaW9kLiAqLw0KKyAgICAgICAgICAg
IC8qIE1vdmUgdGhlbSB0byB0aGVpciBuZXh0IHBlcmlvZCAqLw0KICAgICAgICAgICAgIGN1cmlu
Zi0+ZGVhZGxfYWJzICs9IGN1cmluZi0+cGVyaW9kOw0KIA0KLSAgICAgICAgICAgIC8qIEVuc3Vy
ZSB0aGF0IHRoZSBzdGFydCBvZiB0aGUgbmV4dCBwZXJpb2QgaXMgaW4gdGhlIGZ1dHVyZS4gKi8N
CisgICAgICAgICAgICAvKiBFbnN1cmUgdGhhdCB0aGUgc3RhcnQgb2YgdGhlIG5leHQgcGVyaW9k
IGlzIGluIHRoZSBmdXR1cmUgKi8NCiAgICAgICAgICAgICBpZiAoIHVubGlrZWx5KFBFUklPRF9C
RUdJTihjdXJpbmYpIDwgbm93KSApDQogICAgICAgICAgICAgICAgIGN1cmluZi0+ZGVhZGxfYWJz
ICs9IA0KICAgICAgICAgICAgICAgICAgICAgKERJVl9VUChub3cgLSBQRVJJT0RfQkVHSU4oY3Vy
aW5mKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VyaW5mLT5wZXJpb2QpKSAqIGN1
cmluZi0+cGVyaW9kOw0KIA0KLSAgICAgICAgICAgIC8qIFB1dCB0aGVtIGJhY2sgaW50byB0aGUg
cXVldWUuICovDQorICAgICAgICAgICAgLyogUHV0IHRoZW0gYmFjayBpbnRvIHRoZSBxdWV1ZSAq
Lw0KICAgICAgICAgICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGN1cmluZi0+dmNwdSk7DQog
ICAgICAgICB9DQogICAgICAgICBlbHNlIGlmICggdW5saWtlbHkoKGN1cmluZi0+ZGVhZGxfYWJz
IDwgbm93KSB8fA0KQEAgLTU3MSwxOCArNTE4LDE4IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1
ZXMoDQogICAgICAgICAgICAgICogV2UgbWlzc2VkIHRoZSBkZWFkbGluZSBvciB0aGUgc2xpY2Ug
d2FzIGFscmVhZHkgZmluaXNoZWQuDQogICAgICAgICAgICAgICogTWlnaHQgaGFwZW4gYmVjYXVz
ZSBvZiBkb21fYWRqLg0KICAgICAgICAgICAgICAqLw0KLSAgICAgICAgICAgIFBSSU5UKDQsIlx0
RG9tYWluICVpLiVpIGV4Y2VlZGVkIGl0J3MgZGVhZGxpbmUvIg0KLSAgICAgICAgICAgICAgICAg
ICJzbGljZSAoJSJQUkl1NjQiIC8gJSJQUkl1NjQiKSBub3c6ICUiUFJJdTY0DQotICAgICAgICAg
ICAgICAgICAgIiBjcHV0aW1lOiAlIlBSSXU2NCJcbiIsDQotICAgICAgICAgICAgICAgICAgY3Vy
aW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYt
PnZjcHUtPnZjcHVfaWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT5kZWFkbF9hYnMsIGN1
cmluZi0+c2xpY2UsIG5vdywNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYtPmNwdXRpbWUpOw0K
KyAgICAgICAgICAgIHByaW50aygiXHREb21haW4gJWkuJWkgZXhjZWVkZWQgaXQncyBkZWFkbGlu
ZS8iDQorICAgICAgICAgICAgICAgICAgICJzbGljZSAoJSJQUkl1NjQiIC8gJSJQUkl1NjQiKSBu
b3c6ICUiUFJJdTY0DQorICAgICAgICAgICAgICAgICAgICIgY3B1dGltZTogJSJQUkl1NjQiXG4i
LA0KKyAgICAgICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLA0K
KyAgICAgICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsDQorICAgICAgICAgICAg
ICAgICAgIGN1cmluZi0+ZGVhZGxfYWJzLCBjdXJpbmYtPnNsaWNlLCBub3csDQorICAgICAgICAg
ICAgICAgICAgIGN1cmluZi0+Y3B1dGltZSk7DQogICAgICAgICAgICAgX19kZWxfZnJvbV9xdWV1
ZShjdXJpbmYtPnZjcHUpOw0KIA0KLSAgICAgICAgICAgIC8qIENvbW1vbiBjYXNlOiB3ZSBtaXNz
IG9uZSBwZXJpb2QuICovDQorICAgICAgICAgICAgLyogQ29tbW9uIGNhc2U6IHdlIG1pc3Mgb25l
IHBlcmlvZCAqLw0KICAgICAgICAgICAgIGN1cmluZi0+ZGVhZGxfYWJzICs9IGN1cmluZi0+cGVy
aW9kOw0KLSAgIA0KKw0KICAgICAgICAgICAgIC8qDQogICAgICAgICAgICAgICogSWYgd2UgYXJl
IHN0aWxsIGJlaGluZDogbW9kdWxvIGFyaXRobWV0aWMsIGZvcmNlIGRlYWRsaW5lDQogICAgICAg
ICAgICAgICogdG8gYmUgaW4gZnV0dXJlIGFuZCBhbGlnbmVkIHRvIHBlcmlvZCBib3JkZXJzLg0K
QEAgLTU5Myw3ICs1NDAsNyBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfcXVldWVzKA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGN1cmluZi0+cGVyaW9kKSAqIGN1cmluZi0+cGVyaW9kOw0KICAg
ICAgICAgICAgIEFTU0VSVChjdXJpbmYtPmRlYWRsX2FicyA+PSBub3cpOw0KIA0KLSAgICAgICAg
ICAgIC8qIEdpdmUgYSBmcmVzaCBzbGljZS4gKi8NCisgICAgICAgICAgICAvKiBHaXZlIGEgZnJl
c2ggc2xpY2UgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmNwdXRpbWUgPSAwOw0KICAgICAgICAg
ICAgIGlmICggUEVSSU9EX0JFR0lOKGN1cmluZikgPiBub3cgKQ0KICAgICAgICAgICAgICAgICBf
X2FkZF90b193YWl0cXVldWVfc29ydChjdXJpbmYtPnZjcHUpOw0KQEAgLTYwMywxNyArNTUwLDE3
IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgICAgICBlbHNlDQogICAgICAgICAg
ICAgYnJlYWs7DQogICAgIH0NCi0NCi0gICAgUFJJTlQoMywiZG9uZSB1cGRhdGluZyB0aGUgcXVl
dWVzXG4iKTsNCiB9DQogDQogDQotLyogcmVtb3ZlcyBhIGRvbWFpbiBmcm9tIHRoZSBoZWFkIG9m
IHRoZSBhY2NvcmRpbmcgZXh0cmFRIGFuZA0KLSAgIHJlcXVldWVzIGl0IGF0IGEgc3BlY2lmaWVk
IHBvc2l0aW9uOg0KLSAgICAgcm91bmQtcm9iaW4gZXh0cmF0aW1lOiBlbmQgb2YgZXh0cmFRDQot
ICAgICB3ZWlnaHRlZCBleHQuOiBpbnNlcnQgaW4gc29ydGVkIGxpc3QgYnkgc2NvcmUNCi0gICBp
ZiB0aGUgZG9tYWluIGlzIGJsb2NrZWQgLyBoYXMgcmVnYWluZWQgaXRzIHNob3J0LWJsb2NrLWxv
c3MNCi0gICB0aW1lIGl0IGlzIG5vdCBwdXQgb24gYW55IHF1ZXVlICovDQorLyoNCisgKiByZW1v
dmVzIGEgZG9tYWluIGZyb20gdGhlIGhlYWQgb2YgdGhlIGFjY29yZGluZyBleHRyYVEgYW5kDQor
ICogcmVxdWV1ZXMgaXQgYXQgYSBzcGVjaWZpZWQgcG9zaXRpb246DQorICogICByb3VuZC1yb2Jp
biBleHRyYXRpbWU6IGVuZCBvZiBleHRyYVENCisgKiAgIHdlaWdodGVkIGV4dC46IGluc2VydCBp
biBzb3J0ZWQgbGlzdCBieSBzY29yZQ0KKyAqIGlmIHRoZSBkb21haW4gaXMgYmxvY2tlZCAvIGhh
cyByZWdhaW5lZCBpdHMgc2hvcnQtYmxvY2stbG9zcw0KKyAqIHRpbWUgaXQgaXMgbm90IHB1dCBv
biBhbnkgcXVldWUuDQorICovDQogc3RhdGljIHZvaWQgZGVzY2hlZF9leHRyYV9kb20oc190aW1l
X3Qgbm93LCBzdHJ1Y3QgdmNwdSAqZCkNCiB7DQogICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyAq
aW5mID0gRURPTV9JTkZPKGQpOw0KQEAgLTYyMiwyOSArNTY5LDI1IEBAIHN0YXRpYyB2b2lkIGRl
c2NoZWRfZXh0cmFfZG9tKHNfdGltZV90IG4NCiANCiAgICAgQVNTRVJUKGV4dHJhcV9vbihkLCBp
KSk7DQogDQotICAgIC8qIFVuc2V0IGFsbCBydW5uaW5nIGZsYWdzLiAqLw0KKyAgICAvKiBVbnNl
dCBhbGwgcnVubmluZyBmbGFncyAqLw0KICAgICBpbmYtPnN0YXR1cyAgJj0gfihFWFRSQV9SVU5f
UEVOIHwgRVhUUkFfUlVOX1VUSUwpOw0KLSAgICAvKiBGcmVzaCBzbGljZSBmb3IgdGhlIG5leHQg
cnVuLiAqLw0KKyAgICAvKiBGcmVzaCBzbGljZSBmb3IgdGhlIG5leHQgcnVuICovDQogICAgIGlu
Zi0+Y3B1dGltZSA9IDA7DQotICAgIC8qIEFjY3VtdWxhdGUgdG90YWwgZXh0cmF0aW1lLiAqLw0K
KyAgICAvKiBBY2N1bXVsYXRlIHRvdGFsIGV4dHJhdGltZSAqLw0KICAgICBpbmYtPmV4dHJhX3Rp
bWVfdG90ICs9IG5vdyAtIGluZi0+c2NoZWRfc3RhcnRfYWJzOw0KICAgICAvKiBSZW1vdmUgZXh0
cmFkb21haW4gZnJvbSBoZWFkIG9mIHRoZSBxdWV1ZS4gKi8NCiAgICAgZXh0cmFxX2RlbChkLCBp
KTsNCiANCi0gICAgLyogVXBkYXRlIHRoZSBzY29yZS4gKi8NCisgICAgLyogVXBkYXRlIHRoZSBz
Y29yZSAqLw0KICAgICBvbGRzY29yZSA9IGluZi0+c2NvcmVbaV07DQogICAgIGlmICggaSA9PSBF
WFRSQV9QRU5fUSApDQogICAgIHsNCi0gICAgICAgIC8qZG9tYWluIHdhcyBydW5uaW5nIGluIEww
IGV4dHJhcSovDQotICAgICAgICAvKnJlZHVjZSBibG9jayBsb3N0LCBwcm9iYWJseSBtb3JlIHNv
cGhpc3RpY2F0aW9uIGhlcmUhKi8NCisgICAgICAgIC8qIERvbWFpbiB3YXMgcnVubmluZyBpbiBM
MCBleHRyYXEgKi8NCisgICAgICAgIC8qIHJlZHVjZSBibG9jayBsb3N0LCBwcm9iYWJseSBtb3Jl
IHNvcGhpc3RpY2F0aW9uIGhlcmUhKi8NCiAgICAgICAgIC8qaW5mLT5zaG9ydF9ibG9ja19sb3N0
X3RvdCAtPSBFWFRSQV9RVUFOVFVNOyovDQogICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3Rf
dG90IC09IG5vdyAtIGluZi0+c2NoZWRfc3RhcnRfYWJzOw0KLSAgICAgICAgUFJJTlQoMywiRG9t
YWluICVpLiVpOiBTaG9ydF9ibG9ja19sb3NzOiAlIlBSSWk2NCJcbiIsIA0KLSAgICAgICAgICAg
ICAgaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgaW5mLT52Y3B1LT52Y3B1X2lkLA0KLSAg
ICAgICAgICAgICAgaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCk7DQogI2lmIDANCi0gICAgICAg
IC8qDQotICAgICAgICAgKiBLQUY6IElmIHdlIGRvbid0IGV4aXQgc2hvcnQtYmxvY2tpbmcgc3Rh
dGUgYXQgdGhpcyBwb2ludA0KKyAgICAgICAgLyogS0FGOiBJZiB3ZSBkb24ndCBleGl0IHNob3J0
LWJsb2NraW5nIHN0YXRlIGF0IHRoaXMgcG9pbnQNCiAgICAgICAgICAqIGRvbWFpbjAgY2FuIHN0
ZWFsIGFsbCBDUFUgZm9yIHVwIHRvIDEwIHNlY29uZHMgYmVmb3JlDQogICAgICAgICAgKiBzY2hl
ZHVsaW5nIHNldHRsZXMgZG93biAod2hlbiBjb21wZXRpbmcgYWdhaW5zdCBhbm90aGVyDQogICAg
ICAgICAgKiBDUFUtYm91bmQgZG9tYWluKS4gRG9pbmcgdGhpcyBzZWVtcyB0byBtYWtlIHRoaW5n
cyBiZWhhdmUNCkBAIC02NTMsNTEgKzU5Niw1OSBAQCBzdGF0aWMgdm9pZCBkZXNjaGVkX2V4dHJh
X2RvbShzX3RpbWVfdCBuDQogICAgICAgICBpZiAoIGluZi0+c2hvcnRfYmxvY2tfbG9zdF90b3Qg
PD0gMCApDQogI2VuZGlmDQogICAgICAgICB7DQotICAgICAgICAgICAgUFJJTlQoNCwiRG9tYWlu
ICVpLiVpIGNvbXBlbnNhdGVkIHNob3J0IGJsb2NrIGxvc3MhXG4iLA0KLSAgICAgICAgICAgICAg
ICAgIGluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5faWQsIGluZi0+dmNwdS0+dmNwdV9pZCk7DQot
ICAgICAgICAgICAgLyp3ZSBoYXZlIChvdmVyLSljb21wZW5zYXRlZCBvdXIgYmxvY2sgcGVuYWx0
eSovDQorICAgICAgICAgICAgLyogV2UgaGF2ZSAob3Zlci0pY29tcGVuc2F0ZWQgb3VyIGJsb2Nr
IHBlbmFsdHkgKi8NCiAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90ID0gMDsN
Ci0gICAgICAgICAgICAvKndlIGRvbid0IHdhbnQgYSBwbGFjZSBvbiB0aGUgcGVuYWx0eSBxdWV1
ZSBhbnltb3JlISovDQorICAgICAgICAgICAgLyogV2UgZG9uJ3Qgd2FudCBhIHBsYWNlIG9uIHRo
ZSBwZW5hbHR5IHF1ZXVlIGFueW1vcmUhICovDQogICAgICAgICAgICAgaW5mLT5zdGF0dXMgJj0g
fkVYVFJBX1dBTlRfUEVOX1E7DQogICAgICAgICAgICAgZ290byBjaGVja19leHRyYV9xdWV1ZXM7
DQogICAgICAgICB9DQogDQotICAgICAgICAvKndlIGhhdmUgdG8gZ28gYWdhaW4gZm9yIGFub3Ro
ZXIgdHJ5IGluIHRoZSBibG9jay1leHRyYXEsDQotICAgICAgICAgIHRoZSBzY29yZSBpcyBub3Qg
dXNlZCBpbmNyZW1hbnRhbGx5IGhlcmUsIGFzIHRoaXMgaXMNCi0gICAgICAgICAgYWxyZWFkeSBk
b25lIGJ5IHJlY2FsY3VsYXRpbmcgdGhlIGJsb2NrX2xvc3QqLw0KKyAgICAgICAgLyoNCisgICAg
ICAgICAqIFdlIGhhdmUgdG8gZ28gYWdhaW4gZm9yIGFub3RoZXIgdHJ5IGluIHRoZSBibG9jay1l
eHRyYXEsDQorICAgICAgICAgKiB0aGUgc2NvcmUgaXMgbm90IHVzZWQgaW5jcmVtYW50YWxseSBo
ZXJlLCBhcyB0aGlzIGlzDQorICAgICAgICAgKiBhbHJlYWR5IGRvbmUgYnkgcmVjYWxjdWxhdGlu
ZyB0aGUgYmxvY2tfbG9zdA0KKyAgICAgICAgICovDQogICAgICAgICBpbmYtPnNjb3JlW0VYVFJB
X1BFTl9RXSA9IChpbmYtPnBlcmlvZCA8PCAxMCkgLw0KICAgICAgICAgICAgIGluZi0+c2hvcnRf
YmxvY2tfbG9zdF90b3Q7DQogICAgICAgICBvbGRzY29yZSA9IDA7DQogICAgIH0NCiAgICAgZWxz
ZQ0KICAgICB7DQotICAgICAgICAvKmRvbWFpbiB3YXMgcnVubmluZyBpbiBMMSBleHRyYXEgPT4g
c2NvcmUgaXMgaW52ZXJzZSBvZg0KLSAgICAgICAgICB1dGlsaXphdGlvbiBhbmQgaXMgdXNlZCBz
b21ld2hhdCBpbmNyZW1lbnRhbCEqLw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIERvbWFpbiB3
YXMgcnVubmluZyBpbiBMMSBleHRyYXEgPT4gc2NvcmUgaXMgaW52ZXJzZSBvZg0KKyAgICAgICAg
ICogdXRpbGl6YXRpb24gYW5kIGlzIHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhDQorICAgICAg
ICAgKi8NCiAgICAgICAgIGlmICggIWluZi0+ZXh0cmF3ZWlnaHQgKQ0KLSAgICAgICAgICAgIC8q
TkI6IHVzZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyovDQorICAgICAgICB7
DQorICAgICAgICAgICAgLyogTkI6IHVzZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAg
Yml0cyAqLw0KICAgICAgICAgICAgIGluZi0+c2NvcmVbRVhUUkFfVVRJTF9RXSA9IChpbmYtPnBl
cmlvZCA8PCAxMCkgLw0KICAgICAgICAgICAgICAgICBpbmYtPnNsaWNlOw0KKyAgICAgICAgfQ0K
ICAgICAgICAgZWxzZQ0KLSAgICAgICAgICAgIC8qY29udmVyc2lvbiBiZXR3ZWVuIHJlYWx0aW1l
IHV0aWxpc2F0aW9uIGFuZCBleHRyYXdpZWdodDoNCi0gICAgICAgICAgICAgIGZ1bGwgKGllIDEw
MCUpIHV0aWxpemF0aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0Ki8NCisgICAg
ICAgIHsNCisgICAgICAgICAgICAvKg0KKyAgICAgICAgICAgICAqIENvbnZlcnNpb24gYmV0d2Vl
biByZWFsdGltZSB1dGlsaXNhdGlvbiBhbmQgZXh0cmF3aWVnaHQ6DQorICAgICAgICAgICAgICog
ZnVsbCAoaWUgMTAwJSkgdXRpbGl6YXRpb24gaXMgZXF1aXZhbGVudCB0byAxMjggZXh0cmF3ZWln
aHQNCisgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICBpbmYtPnNjb3JlW0VYVFJBX1VUSUxf
UV0gPSAoMTw8MTcpIC8gaW5mLT5leHRyYXdlaWdodDsNCisgICAgICAgIH0NCiAgICAgfQ0KIA0K
ICBjaGVja19leHRyYV9xdWV1ZXM6DQotICAgIC8qIEFkZGluZyBhIHJ1bm5hYmxlIGRvbWFpbiB0
byB0aGUgcmlnaHQgcXVldWUgYW5kIHJlbW92aW5nIGJsb2NrZWQgb25lcyovDQorICAgIC8qIEFk
ZGluZyBhIHJ1bm5hYmxlIGRvbWFpbiB0byB0aGUgcmlnaHQgcXVldWUgYW5kIHJlbW92aW5nIGJs
b2NrZWQgb25lcyAqLw0KICAgICBpZiAoIHNlZGZfcnVubmFibGUoZCkgKQ0KICAgICB7DQotICAg
ICAgICAvKmFkZCBhY2NvcmRpbmcgdG8gc2NvcmU6IHdlaWdodGVkIHJvdW5kIHJvYmluKi8NCisg
ICAgICAgIC8qIEFkZCBhY2NvcmRpbmcgdG8gc2NvcmU6IHdlaWdodGVkIHJvdW5kIHJvYmluICov
DQogICAgICAgICBpZiAoKChpbmYtPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJiAoaSA9PSBFWFRS
QV9VVElMX1EpKSB8fA0KICAgICAgICAgICAgICgoaW5mLT5zdGF0dXMgJiBFWFRSQV9XQU5UX1BF
Tl9RKSAmJiAoaSA9PSBFWFRSQV9QRU5fUSkpKQ0KICAgICAgICAgICAgIGV4dHJhcV9hZGRfc29y
dF91cGRhdGUoZCwgaSwgb2xkc2NvcmUpOw0KICAgICB9DQogICAgIGVsc2UNCiAgICAgew0KLSAg
ICAgICAgLypyZW1vdmUgdGhpcyBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSB3YWl0cSEqLw0KKyAg
ICAgICAgLyogUmVtb3ZlIHRoaXMgYmxvY2tlZCBkb21haW4gZnJvbSB0aGUgd2FpdHEhICovDQog
ICAgICAgICBfX2RlbF9mcm9tX3F1ZXVlKGQpOw0KLSAgICAgICAgLyptYWtlIHN1cmUgdGhhdCB3
ZSByZW1vdmUgYSBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSBvdGhlcg0KLSAgICAgICAgICBleHRy
YXEgdG9vKi8NCisgICAgICAgIC8qIE1ha2Ugc3VyZSB0aGF0IHdlIHJlbW92ZSBhIGJsb2NrZWQg
ZG9tYWluIGZyb20gdGhlIG90aGVyDQorICAgICAgICAgKiBleHRyYXEgdG9vLiAqLw0KICAgICAg
ICAgaWYgKCBpID09IEVYVFJBX1BFTl9RICkNCiAgICAgICAgIHsNCiAgICAgICAgICAgICBpZiAo
IGV4dHJhcV9vbihkLCBFWFRSQV9VVElMX1EpICkNCkBAIC03MjksOCArNjgwLDEwIEBAIHN0YXRp
YyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiANCiAgICAgaWYgKCAhbGlzdF9l
bXB0eShleHRyYXFbRVhUUkFfUEVOX1FdKSApDQogICAgIHsNCi0gICAgICAgIC8qd2Ugc3RpbGwg
aGF2ZSBlbGVtZW50cyBvbiB0aGUgbGV2ZWwgMCBleHRyYXEgDQotICAgICAgICAgID0+IGxldCB0
aG9zZSBydW4gZmlyc3QhKi8NCisgICAgICAgIC8qDQorICAgICAgICAgKiBXZSBzdGlsbCBoYXZl
IGVsZW1lbnRzIG9uIHRoZSBsZXZlbCAwIGV4dHJhcQ0KKyAgICAgICAgICogPT4gbGV0IHRob3Nl
IHJ1biBmaXJzdCENCisgICAgICAgICAqLw0KICAgICAgICAgcnVuaW5mICAgPSBsaXN0X2VudHJ5
KGV4dHJhcVtFWFRSQV9QRU5fUV0tPm5leHQsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywgZXh0cmFsaXN0W0VYVFJBX1BFTl9RXSk7DQogICAg
ICAgICBydW5pbmYtPnN0YXR1cyB8PSBFWFRSQV9SVU5fUEVOOw0KQEAgLTc0NCw3ICs2OTcsNyBA
QCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2VkZl9kb19leHRyYV9zDQogICAgIHsNCiAgICAg
ICAgIGlmICggIWxpc3RfZW1wdHkoZXh0cmFxW0VYVFJBX1VUSUxfUV0pICkNCiAgICAgICAgIHsN
Ci0gICAgICAgICAgICAvKnVzZSBlbGVtZW50cyBmcm9tIHRoZSBub3JtYWwgZXh0cmFxdWV1ZSov
DQorICAgICAgICAgICAgLyogVXNlIGVsZW1lbnRzIGZyb20gdGhlIG5vcm1hbCBleHRyYXF1ZXVl
ICovDQogICAgICAgICAgICAgcnVuaW5mICAgPSBsaXN0X2VudHJ5KGV4dHJhcVtFWFRSQV9VVElM
X1FdLT5uZXh0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qgc2Vk
Zl92Y3B1X2luZm8sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4dHJhbGlz
dFtFWFRSQV9VVElMX1FdKTsNCkBAIC03OTQsMTEgKzc0NywxMyBAQCBzdGF0aWMgdm9pZCBzZWRm
X2RlaW5pdChjb25zdCBzdHJ1Y3Qgc2NoDQogfQ0KIA0KIA0KLS8qIE1haW4gc2NoZWR1bGluZyBm
dW5jdGlvbg0KLSAgIFJlYXNvbnMgZm9yIGNhbGxpbmcgdGhpcyBmdW5jdGlvbiBhcmU6DQotICAg
LXRpbWVzbGljZSBmb3IgdGhlIGN1cnJlbnQgcGVyaW9kIHVzZWQgdXANCi0gICAtZG9tYWluIG9u
IHdhaXRxdWV1ZSBoYXMgc3RhcnRlZCBpdCdzIHBlcmlvZA0KLSAgIC1hbmQgdmFyaW91cyBvdGhl
cnMgOykgaW4gZ2VuZXJhbDogZGV0ZXJtaW5lIHdoaWNoIGRvbWFpbiB0byBydW4gbmV4dCovDQor
LyoNCisgKiBNYWluIHNjaGVkdWxpbmcgZnVuY3Rpb24NCisgKiBSZWFzb25zIGZvciBjYWxsaW5n
IHRoaXMgZnVuY3Rpb24gYXJlOg0KKyAqIC10aW1lc2xpY2UgZm9yIHRoZSBjdXJyZW50IHBlcmlv
ZCB1c2VkIHVwDQorICogLWRvbWFpbiBvbiB3YWl0cXVldWUgaGFzIHN0YXJ0ZWQgaXQncyBwZXJp
b2QNCisgKiAtYW5kIHZhcmlvdXMgb3RoZXJzIDspIGluIGdlbmVyYWw6IGRldGVybWluZSB3aGlj
aCBkb21haW4gdG8gcnVuIG5leHQNCisgKi8NCiBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2Vk
Zl9kb19zY2hlZHVsZSgNCiAgICAgY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBzX3RpbWVf
dCBub3csIGJvb2xfdCB0YXNrbGV0X3dvcmtfc2NoZWR1bGVkKQ0KIHsNCkBAIC04MTEsMTMgKzc2
NiwxNSBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2VkZl9kb19zY2hlZHVsDQogICAgIHN0
cnVjdCBzZWRmX3ZjcHVfaW5mbyAqcnVuaW5mLCAqd2FpdGluZjsNCiAgICAgc3RydWN0IHRhc2tf
c2xpY2UgICAgICByZXQ7DQogDQotICAgIC8qaWRsZSB0YXNrcyBkb24ndCBuZWVkIGFueSBvZiB0
aGUgZm9sbG93aW5nIHN0dWYqLw0KKyAgICAvKiBJZGxlIHRhc2tzIGRvbid0IG5lZWQgYW55IG9m
IHRoZSBmb2xsb3dpbmcgc3R1ZiAqLw0KICAgICBpZiAoIGlzX2lkbGVfdmNwdShjdXJyZW50KSAp
DQogICAgICAgICBnb3RvIGNoZWNrX3dhaXRxOw0KLSANCi0gICAgLyogY3JlYXRlIGxvY2FsIHN0
YXRlIG9mIHRoZSBzdGF0dXMgb2YgdGhlIGRvbWFpbiwgaW4gb3JkZXIgdG8gYXZvaWQNCi0gICAg
ICAgaW5jb25zaXN0ZW50IHN0YXRlIGR1cmluZyBzY2hlZHVsaW5nIGRlY2lzaW9ucywgYmVjYXVz
ZSBkYXRhIGZvcg0KLSAgICAgICB2Y3B1X3J1bm5hYmxlIGlzIG5vdCBwcm90ZWN0ZWQgYnkgdGhl
IHNjaGVkdWxpbmcgbG9jayEqLw0KKw0KKyAgICAvKg0KKyAgICAgKiBDcmVhdGUgbG9jYWwgc3Rh
dGUgb2YgdGhlIHN0YXR1cyBvZiB0aGUgZG9tYWluLCBpbiBvcmRlciB0byBhdm9pZA0KKyAgICAg
KiBpbmNvbnNpc3RlbnQgc3RhdGUgZHVyaW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLCBiZWNhdXNl
IGRhdGEgZm9yDQorICAgICAqIHZjcHVfcnVubmFibGUgaXMgbm90IHByb3RlY3RlZCBieSB0aGUg
c2NoZWR1bGluZyBsb2NrIQ0KKyAgICAgKi8NCiAgICAgaWYgKCAhdmNwdV9ydW5uYWJsZShjdXJy
ZW50KSApDQogICAgICAgICBpbmYtPnN0YXR1cyB8PSBTRURGX0FTTEVFUDsNCiAgDQpAQCAtODI2
LDcgKzc4Myw3IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAN
CiAgICAgaWYgKCB1bmxpa2VseShleHRyYV9ydW5zKGluZikpICkNCiAgICAgew0KLSAgICAgICAg
LypzcGVjaWFsIHRyZWF0bWVudCBvZiBkb21haW5zIHJ1bm5pbmcgaW4gZXh0cmEgdGltZSovDQor
ICAgICAgICAvKiBTcGVjaWFsIHRyZWF0bWVudCBvZiBkb21haW5zIHJ1bm5pbmcgaW4gZXh0cmEg
dGltZSAqLw0KICAgICAgICAgZGVzY2hlZF9leHRyYV9kb20obm93LCBjdXJyZW50KTsNCiAgICAg
fQ0KICAgICBlbHNlIA0KQEAgLTgzNiwxMCArNzkzLDEyIEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19z
bGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgY2hlY2tfd2FpdHE6DQogICAgIHVwZGF0ZV9xdWV1ZXMo
bm93LCBydW5xLCB3YWl0cSk7DQogDQotICAgIC8qbm93IHNpbXBseSBwaWNrIHRoZSBmaXJzdCBk
b21haW4gZnJvbSB0aGUgcnVucXVldWUsIHdoaWNoIGhhcyB0aGUNCi0gICAgICBlYXJsaWVzdCBk
ZWFkbGluZSwgYmVjYXVzZSB0aGUgbGlzdCBpcyBzb3J0ZWQqLw0KLSANCi0gICAgLyogVGFza2xl
dCB3b3JrICh3aGljaCBydW5zIGluIGlkbGUgVkNQVSBjb250ZXh0KSBvdmVycmlkZXMgYWxsIGVs
c2UuICovDQorICAgIC8qDQorICAgICAqIE5vdyBzaW1wbHkgcGljayB0aGUgZmlyc3QgZG9tYWlu
IGZyb20gdGhlIHJ1bnF1ZXVlLCB3aGljaCBoYXMgdGhlDQorICAgICAqIGVhcmxpZXN0IGRlYWRs
aW5lLCBiZWNhdXNlIHRoZSBsaXN0IGlzIHNvcnRlZA0KKyAgICAgKg0KKyAgICAgKiBUYXNrbGV0
IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BVIGNvbnRleHQpIG92ZXJyaWRlcyBhbGwgZWxz
ZS4NCisgICAgICovDQogICAgIGlmICggdGFza2xldF93b3JrX3NjaGVkdWxlZCB8fA0KICAgICAg
ICAgIChsaXN0X2VtcHR5KHJ1bnEpICYmIGxpc3RfZW1wdHkod2FpdHEpKSB8fA0KICAgICAgICAg
IHVubGlrZWx5KCFjcHVtYXNrX3Rlc3RfY3B1KGNwdSwgU0VERl9DUFVPTkxJTkUocGVyX2NwdShj
cHVwb29sLCBjcHUpKSkpICkNCkBAIC04NTUsOSArODE0LDExIEBAIHN0YXRpYyBzdHJ1Y3QgdGFz
a19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgICAgIHsNCiAgICAgICAgICAgICB3YWl0aW5m
ICA9IGxpc3RfZW50cnkod2FpdHEtPm5leHQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyxsaXN0KTsNCi0gICAgICAgICAgICAvKnJlcnVu
IHNjaGVkdWxlciwgd2hlbiBzY2hlZHVsZWQgZG9tYWluIHJlYWNoZXMgaXQncw0KLSAgICAgICAg
ICAgICAgZW5kIG9mIHNsaWNlIG9yIHRoZSBmaXJzdCBkb21haW4gZnJvbSB0aGUgd2FpdHF1ZXVl
DQotICAgICAgICAgICAgICBnZXRzIHJlYWR5Ki8NCisgICAgICAgICAgICAvKg0KKyAgICAgICAg
ICAgICAqIFJlcnVuIHNjaGVkdWxlciwgd2hlbiBzY2hlZHVsZWQgZG9tYWluIHJlYWNoZXMgaXQn
cw0KKyAgICAgICAgICAgICAqIGVuZCBvZiBzbGljZSBvciB0aGUgZmlyc3QgZG9tYWluIGZyb20g
dGhlIHdhaXRxdWV1ZQ0KKyAgICAgICAgICAgICAqIGdldHMgcmVhZHkuDQorICAgICAgICAgICAg
ICovDQogICAgICAgICAgICAgcmV0LnRpbWUgPSBNSU4obm93ICsgcnVuaW5mLT5zbGljZSAtIHJ1
bmluZi0+Y3B1dGltZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQRVJJT0RfQkVHSU4o
d2FpdGluZikpIC0gbm93Ow0KICAgICAgICAgfQ0KQEAgLTg2OSwxNCArODMwLDE4IEBAIHN0YXRp
YyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgZWxzZQ0KICAgICB7DQog
ICAgICAgICB3YWl0aW5mICA9IGxpc3RfZW50cnkod2FpdHEtPm5leHQsc3RydWN0IHNlZGZfdmNw
dV9pbmZvLCBsaXN0KTsNCi0gICAgICAgIC8qd2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCi0gICAgICAgICAgPT4gbG9vayBmb3IgZG9tYWlucyB0aGF0IGFyZSBhd2FyZSBv
ZiBleHRyYXRpbWUqLw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFdlIGNvdWxkIG5vdCBmaW5k
IGFueSBzdWl0YWJsZSBkb21haW4gDQorICAgICAgICAgKiA9PiBsb29rIGZvciBkb21haW5zIHRo
YXQgYXJlIGF3YXJlIG9mIGV4dHJhdGltZQ0KKyAgICAgICAgICovDQogICAgICAgICByZXQgPSBz
ZWRmX2RvX2V4dHJhX3NjaGVkdWxlKG5vdywgUEVSSU9EX0JFR0lOKHdhaXRpbmYpLA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHRyYXEsIGNwdSk7DQogICAgIH0NCiAN
Ci0gICAgLypUT0RPOiBEbyBzb21ldGhpbmcgVVNFRlVMIHdoZW4gdGhpcyBoYXBwZW5zIGFuZCBm
aW5kIG91dCwgd2h5IGl0DQotICAgICAgc3RpbGwgY2FuIGhhcHBlbiEhISovDQorICAgIC8qDQor
ICAgICAqIFRPRE86IERvIHNvbWV0aGluZyBVU0VGVUwgd2hlbiB0aGlzIGhhcHBlbnMgYW5kIGZp
bmQgb3V0LCB3aHkgaXQNCisgICAgICogc3RpbGwgY2FuIGhhcHBlbiEhIQ0KKyAgICAgKi8NCiAg
ICAgaWYgKCByZXQudGltZSA8IDApDQogICAgIHsNCiAgICAgICAgIHByaW50aygiT3VjaCEgV2Ug
YXJlIHNlcmlvdXNseSBCRUhJTkQgc2NoZWR1bGUhICUiUFJJaTY0IlxuIiwNCkBAIC04OTYsOSAr
ODYxLDYgQEAgc3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KIA0KIHN0
YXRpYyB2b2lkIHNlZGZfc2xlZXAoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBzdHJ1Y3Qg
dmNwdSAqZCkNCiB7DQotICAgIFBSSU5UKDIsInNlZGZfc2xlZXAgd2FzIGNhbGxlZCwgZG9tYWlu
LWlkICVpLiVpXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9p
ZCk7DQotIA0KICAgICBpZiAoIGlzX2lkbGVfdmNwdShkKSApDQogICAgICAgICByZXR1cm47DQog
DQpAQCAtOTIwLDcgKzg4Miw4IEBAIHN0YXRpYyB2b2lkIHNlZGZfc2xlZXAoY29uc3Qgc3RydWN0
IHNjaGUNCiB9DQogDQogDQotLyogVGhpcyBmdW5jdGlvbiB3YWtlcyB1cCBhIGRvbWFpbiwgaS5l
LiBtb3ZlcyB0aGVtIGludG8gdGhlIHdhaXRxdWV1ZQ0KKy8qDQorICogVGhpcyBmdW5jdGlvbiB3
YWtlcyB1cCBhIGRvbWFpbiwgaS5lLiBtb3ZlcyB0aGVtIGludG8gdGhlIHdhaXRxdWV1ZQ0KICAq
IHRoaW5ncyB0byBtZW50aW9uIGFyZTogYWRtaXNzaW9uIGNvbnRyb2wgaXMgdGFraW5nIHBsYWNl
IG5vd2hlcmUgYXQNCiAgKiB0aGUgbW9tZW50LCBzbyB3ZSBjYW4ndCBiZSBzdXJlLCB3aGV0aGVy
IGl0IGlzIHNhZmUgdG8gd2FrZSB0aGUgZG9tYWluDQogICogdXAgYXQgYWxsLiBBbnl3YXksIGV2
ZW4gaWYgaXQgaXMgc2FmZSAodG90YWwgY3B1IHVzYWdlIDw9MTAwJSkgdGhlcmUgYXJlDQpAQCAt
OTk0LDI3ICs5NTcsMzEgQEAgc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBzdHJ1Y3Qgc2No
ZQ0KIHN0YXRpYyB2b2lkIHVuYmxvY2tfc2hvcnRfZXh0cmFfc3VwcG9ydCgNCiAgICAgc3RydWN0
IHNlZGZfdmNwdV9pbmZvKiBpbmYsIHNfdGltZV90IG5vdykNCiB7DQotICAgIC8qdGhpcyB1bmJs
b2NraW5nIHNjaGVtZSB0cmllcyB0byBzdXBwb3J0IHRoZSBkb21haW4sIGJ5IGFzc2lnbmluZyBp
dA0KLSAgICBhIHByaW9yaXR5IGluIGV4dHJhdGltZSBkaXN0cmlidXRpb24gYWNjb3JkaW5nIHRv
IHRoZSBsb3NzIG9mIHRpbWUNCi0gICAgaW4gdGhpcyBzbGljZSBkdWUgdG8gYmxvY2tpbmcqLw0K
KyAgICAvKg0KKyAgICAgKiBUaGlzIHVuYmxvY2tpbmcgc2NoZW1lIHRyaWVzIHRvIHN1cHBvcnQg
dGhlIGRvbWFpbiwgYnkgYXNzaWduaW5nIGl0DQorICAgICAqIGEgcHJpb3JpdHkgaW4gZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiBhY2NvcmRpbmcgdG8gdGhlIGxvc3Mgb2YgdGltZQ0KKyAgICAgKiBp
biB0aGlzIHNsaWNlIGR1ZSB0byBibG9ja2luZw0KKyAgICAgKi8NCiAgICAgc190aW1lX3QgcGVu
Ow0KICANCi0gICAgLypubyBtb3JlIHJlYWx0aW1lIGV4ZWN1dGlvbiBpbiB0aGlzIHBlcmlvZCEq
Lw0KKyAgICAvKiBObyBtb3JlIHJlYWx0aW1lIGV4ZWN1dGlvbiBpbiB0aGlzIHBlcmlvZCEgKi8N
CiAgICAgaW5mLT5kZWFkbF9hYnMgKz0gaW5mLT5wZXJpb2Q7DQogICAgIGlmICggbGlrZWx5KGlu
Zi0+YmxvY2tfYWJzKSApDQogICAgIHsNCi0gICAgICAgIC8vdHJlYXQgYmxvY2tlZCB0aW1lIGFz
IGNvbnN1bWVkIGJ5IHRoZSBkb21haW4qLw0KKyAgICAgICAgLyogVHJlYXQgYmxvY2tlZCB0aW1l
IGFzIGNvbnN1bWVkIGJ5IHRoZSBkb21haW4gKi8NCiAgICAgICAgIC8qaW5mLT5jcHV0aW1lICs9
IG5vdyAtIGluZi0+YmxvY2tfYWJzOyovDQotICAgICAgICAvKnBlbmFsdHkgaXMgdGltZSB0aGUg
ZG9tYWluIHdvdWxkIGhhdmUNCi0gICAgICAgICAgaGFkIGlmIGl0IGNvbnRpbnVlZCB0byBydW4g
Ki8NCisgICAgICAgIC8qDQorICAgICAgICAgKiBQZW5hbHR5IGlzIHRpbWUgdGhlIGRvbWFpbiB3
b3VsZCBoYXZlDQorICAgICAgICAgKiBoYWQgaWYgaXQgY29udGludWVkIHRvIHJ1bi4NCisgICAg
ICAgICAqLw0KICAgICAgICAgcGVuID0gKGluZi0+c2xpY2UgLSBpbmYtPmNwdXRpbWUpOw0KICAg
ICAgICAgaWYgKCBwZW4gPCAwICkNCiAgICAgICAgICAgICBwZW4gPSAwOw0KLSAgICAgICAgLyph
Y2N1bXVsYXRlIGFsbCBwZW5hbHRpZXMgb3ZlciB0aGUgcGVyaW9kcyovDQorICAgICAgICAvKiBB
Y2N1bXVsYXRlIGFsbCBwZW5hbHRpZXMgb3ZlciB0aGUgcGVyaW9kcyAqLw0KICAgICAgICAgLypp
bmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90ICs9IHBlbjsqLw0KLSAgICAgICAgLypzZXQgcGVuYWx0
eSB0byB0aGUgY3VycmVudCB2YWx1ZSovDQorICAgICAgICAvKiBTZXQgcGVuYWx0eSB0byB0aGUg
Y3VycmVudCB2YWx1ZSAqLw0KICAgICAgICAgaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCA9IHBl
bjsNCi0gICAgICAgIC8qbm90IHN1cmUgd2hpY2ggb25lIGlzIGJldHRlci4uIGJ1dCBzZWVtcyB0
byB3b3JrIHdlbGwuLi4qLw0KKyAgICAgICAgLyogTm90IHN1cmUgd2hpY2ggb25lIGlzIGJldHRl
ci4uIGJ1dCBzZWVtcyB0byB3b3JrIHdlbGwuLi4gKi8NCiAgIA0KICAgICAgICAgaWYgKCBpbmYt
PnNob3J0X2Jsb2NrX2xvc3RfdG90ICkNCiAgICAgICAgIHsNCkBAIC0xMDI0LDI4ICs5OTEsMzEg
QEAgc3RhdGljIHZvaWQgdW5ibG9ja19zaG9ydF9leHRyYV9zdXBwb3J0KA0KICAgICAgICAgICAg
IGluZi0+cGVuX2V4dHJhX2Jsb2NrcysrOw0KICNlbmRpZg0KICAgICAgICAgICAgIGlmICggZXh0
cmFxX29uKGluZi0+dmNwdSwgRVhUUkFfUEVOX1EpICkNCi0gICAgICAgICAgICAgICAgLypyZW1v
dmUgZG9tYWluIGZvciBwb3NzaWJsZSByZXNvcnRpbmchKi8NCisgICAgICAgICAgICAgICAgLyog
UmVtb3ZlIGRvbWFpbiBmb3IgcG9zc2libGUgcmVzb3J0aW5nISAqLw0KICAgICAgICAgICAgICAg
ICBleHRyYXFfZGVsKGluZi0+dmNwdSwgRVhUUkFfUEVOX1EpOw0KICAgICAgICAgICAgIGVsc2UN
Ci0gICAgICAgICAgICAgICAgLypyZW1lbWJlciB0aGF0IHdlIHdhbnQgdG8gYmUgb24gdGhlIHBl
bmFsdHkgcQ0KLSAgICAgICAgICAgICAgICAgIHNvIHRoYXQgd2UgY2FuIGNvbnRpbnVlIHdoZW4g
d2UgKHVuLSlibG9jaw0KLSAgICAgICAgICAgICAgICAgIGluIHBlbmFsdHktZXh0cmF0aW1lKi8N
CisgICAgICAgICAgICAgICAgLyoNCisgICAgICAgICAgICAgICAgICogUmVtZW1iZXIgdGhhdCB3
ZSB3YW50IHRvIGJlIG9uIHRoZSBwZW5hbHR5IHENCisgICAgICAgICAgICAgICAgICogc28gdGhh
dCB3ZSBjYW4gY29udGludWUgd2hlbiB3ZSAodW4tKWJsb2NrDQorICAgICAgICAgICAgICAgICAq
IGluIHBlbmFsdHktZXh0cmF0aW1lDQorICAgICAgICAgICAgICAgICAqLw0KICAgICAgICAgICAg
ICAgICBpbmYtPnN0YXR1cyB8PSBFWFRSQV9XQU5UX1BFTl9ROw0KICAgIA0KLSAgICAgICAgICAg
IC8qKHJlLSlhZGQgZG9tYWluIHRvIHRoZSBwZW5hbHR5IGV4dHJhcSovDQorICAgICAgICAgICAg
LyogKHJlLSlhZGQgZG9tYWluIHRvIHRoZSBwZW5hbHR5IGV4dHJhcSAqLw0KICAgICAgICAgICAg
IGV4dHJhcV9hZGRfc29ydF91cGRhdGUoaW5mLT52Y3B1LCBFWFRSQV9QRU5fUSwgMCk7DQogICAg
ICAgICB9DQogICAgIH0NCiANCi0gICAgLypnaXZlIGl0IGEgZnJlc2ggc2xpY2UgaW4gdGhlIG5l
eHQgcGVyaW9kISovDQorICAgIC8qIEdpdmUgaXQgYSBmcmVzaCBzbGljZSBpbiB0aGUgbmV4dCBw
ZXJpb2QhICovDQogICAgIGluZi0+Y3B1dGltZSA9IDA7DQogfQ0KIA0KIA0KIHN0YXRpYyB2b2lk
IHVuYmxvY2tfbG9uZ19jb25zX2Ioc3RydWN0IHNlZGZfdmNwdV9pbmZvKiBpbmYsc190aW1lX3Qg
bm93KQ0KIHsNCi0gICAgLypDb25zZXJ2YXRpdmUgMmIqLw0KLSAgICAvKlRyZWF0IHRoZSB1bmJs
b2NraW5nIHRpbWUgYXMgYSBzdGFydCBvZiBhIG5ldyBwZXJpb2QgKi8NCisgICAgLyogQ29uc2Vy
dmF0aXZlIDJiICovDQorDQorICAgIC8qIFRyZWF0IHRoZSB1bmJsb2NraW5nIHRpbWUgYXMgYSBz
dGFydCBvZiBhIG5ldyBwZXJpb2QgKi8NCiAgICAgaW5mLT5kZWFkbF9hYnMgPSBub3cgKyBpbmYt
PnBlcmlvZDsNCiAgICAgaW5mLT5jcHV0aW1lID0gMDsNCiB9DQpAQCAtMTA2OCwxNSArMTAzOCwx
NyBAQCBzdGF0aWMgaW5saW5lIGludCBnZXRfcnVuX3R5cGUoc3RydWN0IHZjDQogfQ0KIA0KIA0K
LS8qQ29tcGFyZXMgdHdvIGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9u
ZSBpcyBhbGxvd2VkIHRvDQotICBpbnRlcnJ1cHQgdGhlIG90aGVycyBleGVjdXRpb24uDQotICBJ
dCByZXR1cm5zIHRydWUgKCE9MCkgaWYgYSBzd2l0Y2ggdG8gdGhlIG90aGVyIGRvbWFpbiBpcyBn
b29kLg0KLSAgQ3VycmVudCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCi0gICBFREYg
PiBMMCAocGVuYWx0eSBiYXNlZCkgZXh0cmEtdGltZSA+IA0KLSAgIEwxICh1dGlsaXphdGlvbikg
ZXh0cmEtdGltZSA+IGlkbGUtZG9tYWluDQotICBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVz
IGFyZSBhc3NpZ25lZCBhcyBmb2xsb3dpbmc6DQotICAgRURGOiBlYXJseSBkZWFkbGluZSA+IGxh
dGUgZGVhZGxpbmUNCi0gICBMMCBleHRyYS10aW1lOiBsb3dlciBzY29yZSA+IGhpZ2hlciBzY29y
ZSovDQorLyoNCisgKiBDb21wYXJlcyB0d28gZG9tYWlucyBpbiB0aGUgcmVsYXRpb24gb2Ygd2hl
dGhlciB0aGUgb25lIGlzIGFsbG93ZWQgdG8NCisgKiBpbnRlcnJ1cHQgdGhlIG90aGVycyBleGVj
dXRpb24uDQorICogSXQgcmV0dXJucyB0cnVlICghPTApIGlmIGEgc3dpdGNoIHRvIHRoZSBvdGhl
ciBkb21haW4gaXMgZ29vZC4NCisgKiBDdXJyZW50IFByaW9yaXR5IHNjaGVtZSBpcyBhcyBmb2xs
b3dzOg0KKyAqICBFREYgPiBMMCAocGVuYWx0eSBiYXNlZCkgZXh0cmEtdGltZSA+IA0KKyAqICBM
MSAodXRpbGl6YXRpb24pIGV4dHJhLXRpbWUgPiBpZGxlLWRvbWFpbg0KKyAqIEluIHRoZSBzYW1l
IGNsYXNzIHByaW9yaXRpZXMgYXJlIGFzc2lnbmVkIGFzIGZvbGxvd2luZzoNCisgKiAgRURGOiBl
YXJseSBkZWFkbGluZSA+IGxhdGUgZGVhZGxpbmUNCisgKiAgTDAgZXh0cmEtdGltZTogbG93ZXIg
c2NvcmUgPiBoaWdoZXIgc2NvcmUNCisgKi8NCiBzdGF0aWMgaW5saW5lIGludCBzaG91bGRfc3dp
dGNoKHN0cnVjdCB2Y3B1ICpjdXIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dHJ1Y3QgdmNwdSAqb3RoZXIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzX3Rp
bWVfdCBub3cpDQpAQCAtMTA4NSwyNiArMTA1NywyNSBAQCBzdGF0aWMgaW5saW5lIGludCBzaG91
bGRfc3dpdGNoKHN0cnVjdCB2DQogICAgIGN1cl9pbmYgICA9IEVET01fSU5GTyhjdXIpOw0KICAg
ICBvdGhlcl9pbmYgPSBFRE9NX0lORk8ob3RoZXIpOw0KICANCi0gICAgLyogQ2hlY2sgd2hldGhl
ciB3ZSBuZWVkIHRvIG1ha2UgYW4gZWFybGllciBzY2hlZHVsaW5nIGRlY2lzaW9uLiAqLw0KKyAg
ICAvKiBDaGVjayB3aGV0aGVyIHdlIG5lZWQgdG8gbWFrZSBhbiBlYXJsaWVyIHNjaGVkdWxpbmcg
ZGVjaXNpb24gKi8NCiAgICAgaWYgKCBQRVJJT0RfQkVHSU4ob3RoZXJfaW5mKSA8IA0KICAgICAg
ICAgIENQVV9JTkZPKG90aGVyLT5wcm9jZXNzb3IpLT5jdXJyZW50X3NsaWNlX2V4cGlyZXMgKQ0K
ICAgICAgICAgcmV0dXJuIDE7DQogDQotICAgIC8qIE5vIHRpbWluZy1iYXNlZCBzd2l0Y2hlcyBu
ZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBoZXJlLiAqLw0KKyAgICAvKiBObyB0aW1pbmct
YmFzZWQgc3dpdGNoZXMgbmVlZCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgaGVyZSAqLw0KICAg
ICBzd2l0Y2ggKCBnZXRfcnVuX3R5cGUoY3VyKSApDQogICAgIHsNCiAgICAgY2FzZSBET01BSU5f
RURGOg0KLSAgICAgICAgLyogRG8gbm90IGludGVycnVwdCBhIHJ1bm5pbmcgRURGIGRvbWFpbi4g
Ki8NCisgICAgICAgIC8qIERvIG5vdCBpbnRlcnJ1cHQgYSBydW5uaW5nIEVERiBkb21haW4gKi8N
CiAgICAgICAgIHJldHVybiAwOw0KICAgICBjYXNlIERPTUFJTl9FWFRSQV9QRU46DQotICAgICAg
ICAvKiBDaGVjayB3aGV0aGVyIHdlIGFsc28gd2FudCB0aGUgTDAgZXgtcSB3aXRoIGxvd2VyIHNj
b3JlLiAqLw0KKyAgICAgICAgLyogQ2hlY2sgd2hldGhlciB3ZSBhbHNvIHdhbnQgdGhlIEwwIGV4
LXEgd2l0aCBsb3dlciBzY29yZSAqLw0KICAgICAgICAgcmV0dXJuICgob3RoZXJfaW5mLT5zdGF0
dXMgJiBFWFRSQV9XQU5UX1BFTl9RKSAmJg0KICAgICAgICAgICAgICAgICAob3RoZXJfaW5mLT5z
Y29yZVtFWFRSQV9QRU5fUV0gPCANCiAgICAgICAgICAgICAgICAgIGN1cl9pbmYtPnNjb3JlW0VY
VFJBX1BFTl9RXSkpOw0KICAgICBjYXNlIERPTUFJTl9FWFRSQV9VVElMOg0KICAgICAgICAgLyog
Q2hlY2sgd2hldGhlciB3ZSB3YW50IHRoZSBMMCBleHRyYXEuIERvbid0DQotICAgICAgICAgKiBz
d2l0Y2ggaWYgYm90aCBkb21haW5zIHdhbnQgTDEgZXh0cmFxLg0KLSAgICAgICAgICovDQorICAg
ICAgICAgKiBzd2l0Y2ggaWYgYm90aCBkb21haW5zIHdhbnQgTDEgZXh0cmFxLiAqLw0KICAgICAg
ICAgcmV0dXJuICEhKG90aGVyX2luZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5fUSk7DQogICAg
IGNhc2UgRE9NQUlOX0lETEU6DQogICAgICAgICByZXR1cm4gMTsNCkBAIC0xMTE4LDE4ICsxMDg5
LDExIEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgc190
aW1lX3QgICAgICAgICAgICAgIG5vdyA9IE5PVygpOw0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2lu
Zm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiANCi0gICAgUFJJTlQoMywgInNlZGZfd2FrZSB3YXMg
Y2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsZC0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAg
ICAgIGQtPnZjcHVfaWQpOw0KLQ0KICAgICBpZiAoIHVubGlrZWx5KGlzX2lkbGVfdmNwdShkKSkg
KQ0KICAgICAgICAgcmV0dXJuOw0KICAgIA0KICAgICBpZiAoIHVubGlrZWx5KF9fdGFza19vbl9x
dWV1ZShkKSkgKQ0KLSAgICB7DQotICAgICAgICBQUklOVCgzLCJcdGRvbWFpbiAlaS4laSBpcyBh
bHJlYWR5IGluIHNvbWUgcXVldWVcbiIsDQotICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFp
bl9pZCwgZC0+dmNwdV9pZCk7DQogICAgICAgICByZXR1cm47DQotICAgIH0NCiANCiAgICAgQVNT
RVJUKCFzZWRmX3J1bm5hYmxlKGQpKTsNCiAgICAgaW5mLT5zdGF0dXMgJj0gflNFREZfQVNMRUVQ
Ow0KQEAgLTExMzgsMjggKzExMDIsMjUgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0
cnVjdCBzY2hlZA0KICANCiAgICAgaWYgKCB1bmxpa2VseShpbmYtPmRlYWRsX2FicyA9PSAwKSAp
DQogICAgIHsNCi0gICAgICAgIC8qaW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVhZGxpbmUqLw0KKyAg
ICAgICAgLyogSW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVhZGxpbmUgKi8NCiAgICAgICAgIGluZi0+
ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5zbGljZTsNCiAgICAgfQ0KICAgDQotICAgIFBSSU5UKDMs
ICJ3YWtpbmcgdXAgZG9tYWluICVpLiVpIChkZWFkbD0gJSJQUkl1NjQiIHBlcmlvZD0gJSJQUkl1
NjQNCi0gICAgICAgICAgIm5vdz0gJSJQUkl1NjQiKVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWlu
LT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGluZi0+ZGVhZGxfYWJzLCBpbmYtPnBlcmlvZCwgbm93
KTsNCi0NCiAjaWZkZWYgU0VERl9TVEFUUyANCiAgICAgaW5mLT5ibG9ja190b3QrKzsNCiAjZW5k
aWYNCiANCiAgICAgaWYgKCB1bmxpa2VseShub3cgPCBQRVJJT0RfQkVHSU4oaW5mKSkgKQ0KICAg
ICB7DQotICAgICAgICBQUklOVCg0LCJleHRyYXRpbWUgdW5ibG9ja1xuIik7DQotICAgICAgICAv
KiB1bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQorICAgICAgICAvKiBVbmJsb2NraW5nIGlu
IGV4dHJhLXRpbWUhICovDQogICAgICAgICBpZiAoIGluZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9Q
RU5fUSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyp3ZSBoYXZlIGEgZG9tYWluIHRoYXQg
d2FudHMgY29tcGVuc2F0aW9uDQotICAgICAgICAgICAgICBmb3IgYmxvY2sgcGVuYWx0eSBhbmQg
ZGlkIGp1c3QgYmxvY2sgaW4NCi0gICAgICAgICAgICAgIGl0cyBjb21wZW5zYXRpb24gdGltZS4g
R2l2ZSBpdCBhbm90aGVyDQotICAgICAgICAgICAgICBjaGFuY2UhKi8NCisgICAgICAgICAgICAv
Kg0KKyAgICAgICAgICAgICAqIFdlIGhhdmUgYSBkb21haW4gdGhhdCB3YW50cyBjb21wZW5zYXRp
b24NCisgICAgICAgICAgICAgKiBmb3IgYmxvY2sgcGVuYWx0eSBhbmQgZGlkIGp1c3QgYmxvY2sg
aW4NCisgICAgICAgICAgICAgKiBpdHMgY29tcGVuc2F0aW9uIHRpbWUuIEdpdmUgaXQgYW5vdGhl
cg0KKyAgICAgICAgICAgICAqIGNoYW5jZSENCisgICAgICAgICAgICAgKi8NCiAgICAgICAgICAg
ICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIEVYVFJBX1BFTl9RLCAwKTsNCiAgICAgICAgIH0N
CiAgICAgICAgIGV4dHJhcV9jaGVja19hZGRfdW5ibG9ja2VkKGQsIDApOw0KQEAgLTExNjgsOCAr
MTEyOSw3IEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAg
eyAgDQogICAgICAgICBpZiAoIG5vdyA8IGluZi0+ZGVhZGxfYWJzICkNCiAgICAgICAgIHsNCi0g
ICAgICAgICAgICBQUklOVCg0LCJzaG9ydCB1bmJsb2NraW5nXG4iKTsNCi0gICAgICAgICAgICAv
KnNob3J0IGJsb2NraW5nKi8NCisgICAgICAgICAgICAvKiBTaG9ydCBibG9ja2luZyAqLw0KICNp
ZmRlZiBTRURGX1NUQVRTDQogICAgICAgICAgICAgaW5mLT5zaG9ydF9ibG9ja190b3QrKzsNCiAj
ZW5kaWYNCkBAIC0xMTc5LDggKzExMzksNyBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qg
c3RydWN0IHNjaGVkDQogICAgICAgICB9DQogICAgICAgICBlbHNlDQogICAgICAgICB7DQotICAg
ICAgICAgICAgUFJJTlQoNCwibG9uZyB1bmJsb2NraW5nXG4iKTsNCi0gICAgICAgICAgICAvKmxv
bmcgdW5ibG9ja2luZyovDQorICAgICAgICAgICAgLyogTG9uZyB1bmJsb2NraW5nICovDQogI2lm
ZGVmIFNFREZfU1RBVFMNCiAgICAgICAgICAgICBpbmYtPmxvbmdfYmxvY2tfdG90Kys7DQogI2Vu
ZGlmDQpAQCAtMTE5MCwyNCArMTE0OSwxMyBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qg
c3RydWN0IHNjaGVkDQogICAgICAgICB9DQogICAgIH0NCiANCi0gICAgUFJJTlQoMywgIndva2Ug
dXAgZG9tYWluICVpLiVpIChkZWFkbD0gJSJQUkl1NjQiIHBlcmlvZD0gJSJQUkl1NjQNCi0gICAg
ICAgICAgIm5vdz0gJSJQUkl1NjQiKVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5f
aWQsIGQtPnZjcHVfaWQsIGluZi0+ZGVhZGxfYWJzLA0KLSAgICAgICAgICBpbmYtPnBlcmlvZCwg
bm93KTsNCi0NCiAgICAgaWYgKCBQRVJJT0RfQkVHSU4oaW5mKSA+IG5vdyApDQotICAgIHsNCiAg
ICAgICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGQpOw0KLSAgICAgICAgUFJJTlQoMywiYWRk
ZWQgdG8gd2FpdHFcbiIpOw0KLSAgICB9DQogICAgIGVsc2UNCi0gICAgew0KICAgICAgICAgX19h
ZGRfdG9fcnVucXVldWVfc29ydChkKTsNCi0gICAgICAgIFBSSU5UKDMsImFkZGVkIHRvIHJ1bnFc
biIpOw0KLSAgICB9DQogIA0KICNpZmRlZiBTRURGX1NUQVRTDQotICAgIC8qZG8gc29tZSBzdGF0
aXN0aWNzIGhlcmUuLi4qLw0KKyAgICAvKiBEbyBzb21lIHN0YXRpc3RpY3MgaGVyZS4uLiAqLw0K
ICAgICBpZiAoIGluZi0+YmxvY2tfYWJzICE9IDAgKQ0KICAgICB7DQogICAgICAgICBpbmYtPmJs
b2NrX3RpbWVfdG90ICs9IG5vdyAtIGluZi0+YmxvY2tfYWJzOw0KQEAgLTEyMTYsMTIgKzExNjQs
MTQgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0KICAgICB9DQog
I2VuZGlmDQogDQotICAgIC8qc2FuaXR5IGNoZWNrOiBtYWtlIHN1cmUgZWFjaCBleHRyYS1hd2Fy
ZSBkb21haW4gSVMgb24gdGhlIHV0aWwtcSEqLw0KKyAgICAvKiBTYW5pdHkgY2hlY2s6IG1ha2Ug
c3VyZSBlYWNoIGV4dHJhLWF3YXJlIGRvbWFpbiBJUyBvbiB0aGUgdXRpbC1xISAqLw0KICAgICBB
U1NFUlQoSU1QTFkoaW5mLT5zdGF0dXMgJiBFWFRSQV9BV0FSRSwgZXh0cmFxX29uKGQsIEVYVFJB
X1VUSUxfUSkpKTsNCiAgICAgQVNTRVJUKF9fdGFza19vbl9xdWV1ZShkKSk7DQotICAgIC8qY2hl
Y2sgd2hldGhlciB0aGUgYXdha2VuZWQgdGFzayBuZWVkcyB0byBpbnZva2UgdGhlIGRvX3NjaGVk
dWxlDQotICAgICAgcm91dGluZS4gVHJ5IHRvIGF2b2lkIHVubmVjZXNzYXJ5IHJ1bnMgYnV0Og0K
LSAgICAgIFNhdmUgYXBwcm94aW1hdGlvbjogQWx3YXlzIHN3aXRjaCB0byBzY2hlZHVsZXIhKi8N
CisgICAgLyoNCisgICAgICogQ2hlY2sgd2hldGhlciB0aGUgYXdha2VuZWQgdGFzayBuZWVkcyB0
byBpbnZva2UgdGhlIGRvX3NjaGVkdWxlDQorICAgICAqIHJvdXRpbmUuIFRyeSB0byBhdm9pZCB1
bm5lY2Vzc2FyeSBydW5zIGJ1dDoNCisgICAgICogU2F2ZSBhcHByb3hpbWF0aW9uOiBBbHdheXMg
c3dpdGNoIHRvIHNjaGVkdWxlciENCisgICAgICovDQogICAgIEFTU0VSVChkLT5wcm9jZXNzb3Ig
Pj0gMCk7DQogICAgIEFTU0VSVChkLT5wcm9jZXNzb3IgPCBucl9jcHVfaWRzKTsNCiAgICAgQVNT
RVJUKHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwgZC0+cHJvY2Vzc29yKS5jdXJyKTsNCkBAIC0xMjY2
LDcgKzEyMTYsNyBAQCBzdGF0aWMgdm9pZCBzZWRmX2R1bXBfZG9tYWluKHN0cnVjdCB2Y3B1DQog
fQ0KIA0KIA0KLS8qIGR1bXBzIGFsbCBkb21haW5zIG9uIHRoZSBzcGVjaWZpZWQgY3B1ICovDQor
LyogRHVtcHMgYWxsIGRvbWFpbnMgb24gdGhlIHNwZWNpZmllZCBjcHUgKi8NCiBzdGF0aWMgdm9p
ZCBzZWRmX2R1bXBfY3B1X3N0YXRlKGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywgaW50IGkp
DQogew0KICAgICBzdHJ1Y3QgbGlzdF9oZWFkICAgICAgKmxpc3QsICpxdWV1ZSwgKnRtcDsNCkBA
IC0xMzQxLDE2ICsxMjkxLDE4IEBAIHN0YXRpYyB2b2lkIHNlZGZfZHVtcF9jcHVfc3RhdGUoY29u
c3Qgc3QNCiB9DQogDQogDQotLyogQWRqdXN0cyBwZXJpb2RzIGFuZCBzbGljZXMgb2YgdGhlIGRv
bWFpbnMgYWNjb3JkaW5nbHkgdG8gdGhlaXIgd2VpZ2h0cy4gKi8NCisvKiBBZGp1c3RzIHBlcmlv
ZHMgYW5kIHNsaWNlcyBvZiB0aGUgZG9tYWlucyBhY2NvcmRpbmdseSB0byB0aGVpciB3ZWlnaHRz
ICovDQogc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcHVwb29sICpjLCBp
bnQgbnJfY3B1cywgaW50ICpzdW13LCBzX3RpbWVfdCAqc3VtdCkNCiB7DQogICAgIHN0cnVjdCB2
Y3B1ICpwOw0KICAgICBzdHJ1Y3QgZG9tYWluICAgICAgKmQ7DQogICAgIHVuc2lnbmVkIGludCAg
ICAgICAgY3B1Ow0KIA0KLSAgICAvKiBTdW0gYWNyb3NzIGFsbCB3ZWlnaHRzLiBOb3RpY2UgdGhh
dCBubyBydW5xIGxvY2tpbmcgaXMgbmVlZGVkDQorICAgIC8qDQorICAgICAqIFN1bSBhY3Jvc3Mg
YWxsIHdlaWdodHMuIE5vdGljZSB0aGF0IG5vIHJ1bnEgbG9ja2luZyBpcyBuZWVkZWQNCiAgICAg
ICogaGVyZTogdGhlIGNhbGxlciBob2xkcyBzZWRmX3ByaXZfaW5mby5sb2NrIGFuZCB3ZSdyZSBu
b3QgY2hhbmdpbmcNCi0gICAgICogYW55dGhpbmcgdGhhdCBpcyBhY2Nlc3NlZCBkdXJpbmcgc2No
ZWR1bGluZy4gKi8NCisgICAgICogYW55dGhpbmcgdGhhdCBpcyBhY2Nlc3NlZCBkdXJpbmcgc2No
ZWR1bGluZy4NCisgICAgICovDQogICAgIHJjdV9yZWFkX2xvY2soJmRvbWxpc3RfcmVhZF9sb2Nr
KTsNCiAgICAgZm9yX2VhY2hfZG9tYWluX2luX2NwdXBvb2woIGQsIGMgKQ0KICAgICB7DQpAQCAt
MTM2NSwxMSArMTMxNywxNCBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0
IGNwDQogICAgICAgICAgICAgfQ0KICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICB7DQot
ICAgICAgICAgICAgICAgIC8qZG9uJ3QgbW9kaWZ5IGRvbWFpbnMgd2hvIGRvbid0IGhhdmUgYSB3
ZWlnaHQsIGJ1dCBzdW0NCi0gICAgICAgICAgICAgICAgICB1cCB0aGUgdGltZSB0aGV5IG5lZWQs
IHByb2plY3RlZCB0byBhIFdFSUdIVF9QRVJJT0QsDQotICAgICAgICAgICAgICAgICAgc28gdGhh
dCB0aGlzIHRpbWUgaXMgbm90IGdpdmVuIHRvIHRoZSB3ZWlnaHQtZHJpdmVuDQotICAgICAgICAg
ICAgICAgICAgZG9tYWlucyovDQotICAgICAgICAgICAgICAgIC8qY2hlY2sgZm9yIG92ZXJmbG93
cyovDQorICAgICAgICAgICAgICAgIC8qDQorICAgICAgICAgICAgICAgICAqIERvbid0IG1vZGlm
eSBkb21haW5zIHdobyBkb24ndCBoYXZlIGEgd2VpZ2h0LCBidXQgc3VtDQorICAgICAgICAgICAg
ICAgICAqIHVwIHRoZSB0aW1lIHRoZXkgbmVlZCwgcHJvamVjdGVkIHRvIGEgV0VJR0hUX1BFUklP
RCwNCisgICAgICAgICAgICAgICAgICogc28gdGhhdCB0aGlzIHRpbWUgaXMgbm90IGdpdmVuIHRv
IHRoZSB3ZWlnaHQtZHJpdmVuDQorICAgICAgICAgICAgICAgICAqICBkb21haW5zDQorICAgICAg
ICAgICAgICAgICAqLw0KKw0KKyAgICAgICAgICAgICAgICAvKiBDaGVjayBmb3Igb3ZlcmZsb3dz
ICovDQogICAgICAgICAgICAgICAgIEFTU0VSVCgoV0VJR0hUX1BFUklPRCA8IFVMT05HX01BWCkg
DQogICAgICAgICAgICAgICAgICAgICAgICAmJiAoRURPTV9JTkZPKHApLT5zbGljZV9vcmlnIDwg
VUxPTkdfTUFYKSk7DQogICAgICAgICAgICAgICAgIHN1bXRbY3B1XSArPSANCkBAIC0xMzgwLDkg
KzEzMzUsMTEgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAg
ICB9DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KIA0KLSAgICAv
KiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcgd2VpZ2h0LiBVbmxp
a2UgYWJvdmUsIHdlDQorICAgIC8qDQorICAgICAqIEFkanVzdCBhbGwgc2xpY2VzIChhbmQgcGVy
aW9kcykgdG8gdGhlIG5ldyB3ZWlnaHQuIFVubGlrZSBhYm92ZSwgd2UNCiAgICAgICogbmVlZCB0
byB0YWtlIHRociBydW5xIGxvY2sgZm9yIHRoZSB2YXJpb3VzIFZDUFVzOiB3ZSdyZSBtb2R5Zmlu
Zw0KLSAgICAgKiBzbGljZSBhbmQgcGVyaW9kIHdoaWNoIGFyZSByZWZlcmVuY2VkIGR1cmluZyBz
Y2hlZHVsaW5nLiAqLw0KKyAgICAgKiBzbGljZSBhbmQgcGVyaW9kIHdoaWNoIGFyZSByZWZlcmVu
Y2VkIGR1cmluZyBzY2hlZHVsaW5nLg0KKyAgICAgKi8NCiAgICAgcmN1X3JlYWRfbG9jaygmZG9t
bGlzdF9yZWFkX2xvY2spOw0KICAgICBmb3JfZWFjaF9kb21haW5faW5fY3B1cG9vbCggZCwgYyAp
DQogICAgIHsNCkBAIC0xNDEwLDcgKzEzNjcsNyBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dl
aWdodHMoc3RydWN0IGNwDQogfQ0KIA0KIA0KLS8qIHNldCBvciBmZXRjaCBkb21haW4gc2NoZWR1
bGluZyBwYXJhbWV0ZXJzICovDQorLyogU2V0IG9yIGZldGNoIGRvbWFpbiBzY2hlZHVsaW5nIHBh
cmFtZXRlcnMgKi8NCiBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlZHVs
ZXIgKm9wcywgc3RydWN0IGRvbWFpbiAqcCwgc3RydWN0IHhlbl9kb21jdGxfc2NoZWR1bGVyX29w
ICpvcCkNCiB7DQogICAgIHN0cnVjdCBzZWRmX3ByaXZfaW5mbyAqcHJ2ID0gU0VERl9QUklWKG9w
cyk7DQpAQCAtMTQyMSwyMyArMTM3OCwyMiBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0
IHN0cnVjdCBzY2hlDQogICAgIHN0cnVjdCB2Y3B1ICp2Ow0KICAgICBpbnQgcmMgPSAwOw0KIA0K
LSAgICBQUklOVCgyLCJzZWRmX2FkanVzdCB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkgbmV3IHBl
cmlvZCAlIlBSSXU2NCIgIg0KLSAgICAgICAgICAibmV3IHNsaWNlICUiUFJJdTY0IlxubGF0ZW5j
eSAlIlBSSXU2NCIgZXh0cmE6JXNcbiIsDQotICAgICAgICAgIHAtPmRvbWFpbl9pZCwgb3AtPnUu
c2VkZi5wZXJpb2QsIG9wLT51LnNlZGYuc2xpY2UsDQotICAgICAgICAgIG9wLT51LnNlZGYubGF0
ZW5jeSwgKG9wLT51LnNlZGYuZXh0cmF0aW1lKT8ieWVzIjoibm8iKTsNCi0NCi0gICAgLyogU2Vy
aWFsaXplIGFnYWluc3QgdGhlIHBsdWdnYWJsZSBzY2hlZHVsZXIgbG9jayB0byBwcm90ZWN0IGZy
b20NCisgICAgLyoNCisgICAgICogU2VyaWFsaXplIGFnYWluc3QgdGhlIHBsdWdnYWJsZSBzY2hl
ZHVsZXIgbG9jayB0byBwcm90ZWN0IGZyb20NCiAgICAgICogY29uY3VycmVudCB1cGRhdGVzLiBX
ZSBuZWVkIHRvIHRha2UgdGhlIHJ1bnEgbG9jayBmb3IgdGhlIFZDUFVzDQogICAgICAqIGFzIHdl
bGwsIHNpbmNlIHdlIGFyZSB0b3VjaGluZyBleHRyYXdlaWdodCwgd2VpZ2h0LCBzbGljZSBhbmQN
CiAgICAgICogcGVyaW9kLiBBcyBpbiBzY2hlZF9jcmVkaXQyLmMsIHJ1bnEgbG9ja3MgbmVzdCBp
bnNpZGUgdGhlDQotICAgICAqIHBsdWdnYWJsZSBzY2hlZHVsZXIgbG9jay4gKi8NCisgICAgICog
cGx1Z2dhYmxlIHNjaGVkdWxlciBsb2NrLg0KKyAgICAgKi8NCiAgICAgc3Bpbl9sb2NrX2lycXNh
dmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KIA0KICAgICBpZiAoIG9wLT5jbWQgPT0gWEVOX0RPTUNU
TF9TQ0hFRE9QX3B1dGluZm8gKQ0KICAgICB7DQotICAgICAgICAvKiBUaGVzZSBhcmUgdXNlZCBp
biBzZWRmX2FkanVzdF93ZWlnaHRzKCkgYnV0IGhhdmUgdG8gYmUgYWxsb2NhdGVkIGluDQorICAg
ICAgICAvKg0KKyAgICAgICAgICogVGhlc2UgYXJlIHVzZWQgaW4gc2VkZl9hZGp1c3Rfd2VpZ2h0
cygpIGJ1dCBoYXZlIHRvIGJlIGFsbG9jYXRlZCBpbg0KICAgICAgICAgICogdGhpcyBmdW5jdGlv
biwgYXMgd2UgbmVlZCB0byBhdm9pZCBuZXN0aW5nIHhtZW1fcG9vbF9hbGxvYydzIGxvY2sNCi0g
ICAgICAgICAqIHdpdGhpbiBvdXIgcHJ2LT5sb2NrLiAqLw0KKyAgICAgICAgICogd2l0aGluIG91
ciBwcnYtPmxvY2suDQorICAgICAgICAgKi8NCiAgICAgICAgIGlmICggIXN1bXcgfHwgIXN1bXQg
KQ0KICAgICAgICAgew0KICAgICAgICAgICAgIC8qIENoZWNrIGZvciBlcnJvcnMgaGVyZSwgdGhl
IF9nZXRpbmZvIGJyYW5jaCBkb2Vzbid0IGNhcmUgKi8NCkBAIC0xNDQ1LDcgKzE0MDEsNyBAQCBz
dGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAgICAgZ290
byBvdXQ7DQogICAgICAgICB9DQogDQotICAgICAgICAvKiBDaGVjayBmb3Igc2FuZSBwYXJhbWV0
ZXJzLiAqLw0KKyAgICAgICAgLyogQ2hlY2sgZm9yIHNhbmUgcGFyYW1ldGVycyAqLw0KICAgICAg
ICAgaWYgKCAhb3AtPnUuc2VkZi5wZXJpb2QgJiYgIW9wLT51LnNlZGYud2VpZ2h0ICkNCiAgICAg
ICAgIHsNCiAgICAgICAgICAgICByYyA9IC1FSU5WQUw7DQpAQCAtMTQ1Nyw3ICsxNDEzLDcgQEAg
c3RhdGljIGludCBzZWRmX2FkanVzdChjb25zdCBzdHJ1Y3Qgc2NoZQ0KICAgICAgICAgICAgIGlm
ICggKG9wLT51LnNlZGYuZXh0cmF0aW1lICYgRVhUUkFfQVdBUkUpICYmDQogICAgICAgICAgICAg
ICAgICAoIW9wLT51LnNlZGYucGVyaW9kKSApDQogICAgICAgICAgICAgew0KLSAgICAgICAgICAg
ICAgICAvKiBXZWlnaHQtZHJpdmVuIGRvbWFpbnMgd2l0aCBleHRyYXRpbWUgb25seS4gKi8NCisg
ICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggZXh0cmF0aW1lIG9u
bHkgKi8NCiAgICAgICAgICAgICAgICAgZm9yX2VhY2hfdmNwdSAoIHAsIHYgKQ0KICAgICAgICAg
ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAvKiAoSGVyZSBhbmQgZXZlcnl3aGVyZSBp
biB0aGUgZm9sbG93aW5nKSBJUlFzIGFyZSBhbHJlYWR5IG9mZiwNCkBAIC0xNDcyLDcgKzE0Mjgs
NyBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAg
ICAgfQ0KICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICB7DQotICAgICAgICAgICAgICAg
IC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIHJlYWwtdGltZSBleGVjdXRpb24uICovDQor
ICAgICAgICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIHJlYWwtdGltZSBl
eGVjdXRpb24gKi8NCiAgICAgICAgICAgICAgICAgZm9yX2VhY2hfdmNwdSAoIHAsIHYgKSB7DQog
ICAgICAgICAgICAgICAgICAgICB2Y3B1X3NjaGVkdWxlX2xvY2sodik7DQogICAgICAgICAgICAg
ICAgICAgICBFRE9NX0lORk8odiktPndlaWdodCA9IG9wLT51LnNlZGYud2VpZ2h0Ow0KQEAgLTE0
OTUsNyArMTQ1MSw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0IHNjaGUN
CiAgICAgICAgICAgICAgICAgZ290byBvdXQ7DQogICAgICAgICAgICAgfQ0KIA0KLSAgICAgICAg
ICAgIC8qIFRpbWUtZHJpdmVuIGRvbWFpbnMuICovDQorICAgICAgICAgICAgLyogVGltZS1kcml2
ZW4gZG9tYWlucyAqLw0KICAgICAgICAgICAgIGZvcl9lYWNoX3ZjcHUgKCBwLCB2ICkNCiAgICAg
ICAgICAgICB7DQogICAgICAgICAgICAgICAgIHZjcHVfc2NoZWR1bGVfbG9jayh2KTsNCkBAIC0x
NTQ1LDcgKzE1MDEsNiBAQCBvdXQ6DQogICAgIHhmcmVlKHN1bXQpOw0KICAgICB4ZnJlZShzdW13
KTsNCiANCi0gICAgUFJJTlQoMiwic2VkZl9hZGp1c3RfZmluaXNoZWQgd2l0aCByZXR1cm4gY29k
ZSAlZFxuIiwgcmMpOw0KICAgICByZXR1cm4gcmM7DQogfQ0KIA0K


--=-Q+nO0nZUPH9ih0IDSLo0--

--=-BVBDbEUzgZPrsy4cOGLY
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)

iEYEABECAAYFAk8Fvu0ACgkQk4XaBE3IOsR1VwCfcsuEozHwG9FojBY+UvcmkcD1
v9IAnA3Ue47AV827f9NpybP7AUye4eh1
=QtEa
-----END PGP SIGNATURE-----

--=-BVBDbEUzgZPrsy4cOGLY--



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

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

--===============0162675564886136273==--



From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:17:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rip4U-0000sn-OJ; Thu, 05 Jan 2012 15:17:38 +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 1Rip4S-0000sI-4z
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:17:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-182.messagelabs.com!1325776646!2325995!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 1305 invoked from network); 5 Jan 2012 15:17:26 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 15:17:26 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74305199; Thu, 05 Jan 2012 16:17:24 +0100
Message-ID: <1325776621.2728.7.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 05 Jan 2012 16:17:01 +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] [PATCHv3] 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="===============0162675564886136273=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0162675564886136273==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-BVBDbEUzgZPrsy4cOGLY"


--=-BVBDbEUzgZPrsy4cOGLY
Content-Type: multipart/mixed; boundary="=-Q+nO0nZUPH9ih0IDSLo0"


--=-Q+nO0nZUPH9ih0IDSLo0
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 efaa28639a71 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Wed Jan 04 16:12:44 2012 +0000
+++ b/xen/common/sched_sedf.c	Thu Jan 05 15:02:30 2012 +0100
@@ -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
@@ -71,34 +63,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;   /* =3D worst 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
@@ -165,18 +158,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)
 {
@@ -185,11 +177,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.
@@ -200,25 +187,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
@@ -228,29 +208,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
@@ -259,7 +224,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
@@ -272,8 +237,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));
@@ -286,13 +249,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
@@ -310,30 +272,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
@@ -361,12 +321,12 @@ static void *sedf_alloc_vdata(const stru
=20
     inf->vcpu =3D v;
=20
-    /* Every VCPU gets an equal share of extratime by default. */
+    /* Every VCPU gets an equal share of extratime by default */
     inf->deadl_abs   =3D 0;
     inf->latency     =3D 0;
     inf->status      =3D EXTRA_AWARE | SEDF_ASLEEP;
     inf->extraweight =3D 1;
-    /* Upon creation all domain are best-effort. */
+    /* Upon creation all domain are best-effort */
     inf->period      =3D WEIGHT_PERIOD;
     inf->slice       =3D 0;
=20
@@ -450,21 +410,19 @@ 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
-    /*
-     * Scheduling decisions which don't remove the running domain from the
-     * runq.=20
-     */
+    /* Scheduling decisions which don't remove the running domain from
+     * the runq */
     if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
         return;
  =20
     __del_from_queue(d);
- =20
+
     /*
      * Manage bookkeeping (i.e. calculate next deadline, memorise
      * overrun-time of slice) of finished domains.
@@ -475,30 +433,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) )
@@ -518,8 +476,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.
@@ -527,41 +483,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) ||
@@ -571,18 +518,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.
@@ -593,7 +540,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);
@@ -603,17 +550,17 @@ static void update_queues(
         else
             break;
     }
-
-    PRINT(3,"done updating the queues\n");
 }
=20
=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);
@@ -622,29 +569,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
@@ -653,51 +596,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) )
@@ -729,8 +680,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;
@@ -744,7 +697,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]);
@@ -794,11 +747,13 @@ static void sedf_deinit(const struct sch
 }
=20
=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)
 {
@@ -811,13 +766,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
@@ -826,7 +783,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
@@ -836,10 +793,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)))) )
@@ -855,9 +814,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;
         }
@@ -869,14 +830,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",
@@ -896,9 +861,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
@@ -920,7 +882,8 @@ static void sedf_sleep(const struct sche
 }
=20
=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
@@ -994,27 +957,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 )
         {
@@ -1024,28 +991,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
=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;
 }
@@ -1068,15 +1038,17 @@ static inline int get_run_type(struct vc
 }
=20
=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)
@@ -1085,26 +1057,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;
@@ -1118,18 +1089,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;
@@ -1138,28 +1102,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);
@@ -1168,8 +1129,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
@@ -1179,8 +1139,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
@@ -1190,24 +1149,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;
@@ -1216,12 +1164,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);
@@ -1266,7 +1216,7 @@ static void sedf_dump_domain(struct vcpu
 }
=20
=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;
@@ -1341,16 +1291,18 @@ static void sedf_dump_cpu_state(const st
 }
=20
=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, int nr_cpus, int *sumw, =
s_time_t *sumt)
 {
     struct vcpu *p;
     struct domain      *d;
     unsigned int        cpu;
=20
-    /* Sum across all weights. Notice that no runq locking is needed
+    /*
+     * 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. */
+     * anything that is accessed during scheduling.
+     */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1365,11 +1317,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
@@ -1380,9 +1335,11 @@ static int sedf_adjust_weights(struct cp
     }
     rcu_read_unlock(&domlist_read_lock);
=20
-    /* Adjust all slices (and periods) to the new weight. Unlike above, we
+    /*
+     * 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. */
+     * slice and period which are referenced during scheduling.
+     */
     rcu_read_lock(&domlist_read_lock);
     for_each_domain_in_cpupool( d, c )
     {
@@ -1410,7 +1367,7 @@ static int sedf_adjust_weights(struct cp
 }
=20
=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 sedf_priv_info *prv =3D SEDF_PRIV(ops);
@@ -1421,23 +1378,22 @@ static int sedf_adjust(const struct sche
     struct vcpu *v;
     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");
-
-    /* Serialize against the pluggable scheduler lock to protect from
+    /*
+     * 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. */
+     * pluggable scheduler lock.
+     */
     spin_lock_irqsave(&prv->lock, flags);
=20
     if ( op->cmd =3D=3D XEN_DOMCTL_SCHEDOP_putinfo )
     {
-        /* These are used in sedf_adjust_weights() but have to be allocate=
d in
+        /*
+         * 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. */
+         * within our prv->lock.
+         */
         if ( !sumw || !sumt )
         {
             /* Check for errors here, the _getinfo branch doesn't care */
@@ -1445,7 +1401,7 @@ static int sedf_adjust(const struct sche
             goto out;
         }
=20
-        /* Check for sane parameters. */
+        /* Check for sane parameters */
         if ( !op->u.sedf.period && !op->u.sedf.weight )
         {
             rc =3D -EINVAL;
@@ -1457,7 +1413,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 )
                 {
                     /* (Here and everywhere in the following) IRQs are alr=
eady off,
@@ -1472,7 +1428,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 ) {
                     vcpu_schedule_lock(v);
                     EDOM_INFO(v)->weight =3D op->u.sedf.weight;
@@ -1495,7 +1451,7 @@ static int sedf_adjust(const struct sche
                 goto out;
             }
=20
-            /* Time-driven domains. */
+            /* Time-driven domains */
             for_each_vcpu ( p, v )
             {
                 vcpu_schedule_lock(v);
@@ -1545,7 +1501,6 @@ out:
     xfree(sumt);
     xfree(sumw);
=20
-    PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
     return rc;
 }
=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)


--=-Q+nO0nZUPH9ih0IDSLo0
Content-Disposition: attachment; filename="sedf-debug-cleanup.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="sedf-debug-cleanup.patch"; charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGVmYWEyODYzOWE3MTUyNGE2OTNiYTUwMDYy
NGY4NTEyZTU3OTVlMTgNCnNlZGY6IHJlbW92ZSB1c2VsZXNzIHRyYWNpbmcgcHJpbnRrIGFuZCBo
YXJtb25pemUgY29tbWVudHMgc3R5bGUuDQoNCnNjaGVkX3NlZGYuYyB1c2VkIG8gaGF2ZSBpdHMg
b3duIG1lY2hhbmlzbSBmb3IgcHJvZHVjaW5nIHRyYWNpbmctYWxpa2UNCmtpbmQgb2YgaW5mb3Jt
YXRpb24gKGRvbWFpbiBibG9jaywgd2FrZXVwLCBldGMuKS4gTm93YWRheXMsIHdpdGggYW4gZXZl
bg0Kbm90IHNvIGhpZ2ggbnVtYmVyIG9mIHBDUFVzL3ZDUFVzLCBqdXN0IHRyeWluZyB0byBlbmFi
bGUgdGhpcyBtYWtlcw0KdGhlIHNlcmlhbCBjb25zb2xlIGNvbXBsZXRlbHkgdW51c2FibGUsIHBy
b2R1Y2VzIHRvbnMgb2YgdmVyeSBoYXJkIHRvDQpwYXJzZSBhbmQgaW50ZXJwcmVldCBsb2dnaW5n
IGFuZCBjYW4gZWFzaWx5IGxpdmVsb2NrIERvbTAuIE1vcmVvdmVyLA0KcHJldHR5IG11Y2ggdGhl
IHNhbWUgcmVzdWx0IHRoaXMgaXMgc3RydWdnbGluZyB0byBnZXQgdG8sIGlzIGJldHRlcg0KYWNo
aWV2ZWQgYnkgZW5hYmxpbmcgdGhlIHNjaGVkdWxlci1yZWxhdGVkIHRyYWNpbmcgZXZlbnRzLCBh
cw0KaXQgaXMgZm9yIHRoZSBvdGhlciBzY2hlZHVsZXJzIChzYXksIGNyZWRpdCBvciBjcmVkaXQy
KS4NCg0KRm9yIGFsbCB0aGVzZSByZWFzb25zLCB0aGlzIHJlbW92ZXMgdGhhdCBtYWNoaW5lcnkg
Y29tcGxldGVseS4gV2hpbGUgYXQNCml0LCBjaGVjayBpbiBzb21lIGNvc21ldGljcyB0aGF0IGhh
cm1vbml6ZSB0aGUgY29tbWVudHMgd2l0aGltIHRoZW1zZWxmDQphbmQgd2l0aCB0aGUgcmVzdCBv
ZiB0aGUgY29kZSBiYXNlLg0KDQpTaWduZWQtb2ZmLWJ5OiBEYXJpbyBGYWdnaW9saSA8ZGFyaW8u
ZmFnZ2lvbGlAY2l0cml4LmNvbT4NCg0KZGlmZiAtciBlZmFhMjg2MzlhNzEgeGVuL2NvbW1vbi9z
Y2hlZF9zZWRmLmMNCi0tLSBhL3hlbi9jb21tb24vc2NoZWRfc2VkZi5jCVdlZCBKYW4gMDQgMTY6
MTI6NDQgMjAxMiArMDAwMA0KKysrIGIveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJVGh1IEphbiAw
NSAxNTowMjozMCAyMDEyICswMTAwDQpAQCAtMTMsMTQgKzEzLDYgQEANCiAjaW5jbHVkZSA8eGVu
L3RpbWUuaD4NCiAjaW5jbHVkZSA8eGVuL2Vycm5vLmg+DQogDQotLyp2ZXJib3NpdHkgc2V0dGlu
Z3MqLw0KLSNkZWZpbmUgU0VERkxFVkVMIDANCi0jZGVmaW5lIFBSSU5UKF9mLCBfYS4uLikgICAg
ICAgICAgICAgICAgICAgICAgICBcDQotICAgIGRvIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KLSAgICAgICAgaWYgKCAoX2YpIDw9IFNFREZMRVZFTCApICAgICAg
ICAgICAgICAgIFwNCi0gICAgICAgICAgICBwcmludGsoX2EgKTsgICAgICAgICAgICAgICAgICAg
ICAgICBcDQotICAgIH0gd2hpbGUgKCAwICkNCi0NCiAjZGVmaW5lIFNFREZfQ1BVT05MSU5FKF9w
b29sKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwNCiAgICAg
KCgoX3Bvb2wpID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9jcHVzIDogKF9wb29sKS0+Y3B1X3Zh
bGlkKQ0KIA0KQEAgLTcxLDM0ICs2MywzNSBAQCBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gew0KICAg
ICBzdHJ1Y3QgbGlzdF9oZWFkIGxpc3Q7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgZXh0cmFsaXN0
WzJdOw0KICANCi0gICAgLypQYXJhbWV0ZXJzIGZvciBFREYqLw0KLSAgICBzX3RpbWVfdCAgcGVy
aW9kOyAgLyo9KHJlbGF0aXZlIGRlYWRsaW5lKSovDQotICAgIHNfdGltZV90ICBzbGljZTsgIC8q
PXdvcnN0IGNhc2UgZXhlY3V0aW9uIHRpbWUqLw0KKyAgICAvKiBQYXJhbWV0ZXJzIGZvciBFREYg
Ki8NCisgICAgc190aW1lX3QgIHBlcmlvZDsgIC8qID0gcmVsYXRpdmUgZGVhZGxpbmUgKi8NCisg
ICAgc190aW1lX3QgIHNsaWNlOyAgIC8qID0gd29yc3QgY2FzZSBleGVjdXRpb24gdGltZSAqLw0K
ICANCi0gICAgLypBZHZhY2VkIFBhcmFtZXRlcnMqLw0KLSAgICAvKkxhdGVuY3kgU2NhbGluZyov
DQorICAgIC8qIEFkdmFjZWQgUGFyYW1ldGVycyAqLw0KKw0KKyAgICAvKiBMYXRlbmN5IFNjYWxp
bmcgKi8NCiAgICAgc190aW1lX3QgIHBlcmlvZF9vcmlnOw0KICAgICBzX3RpbWVfdCAgc2xpY2Vf
b3JpZzsNCiAgICAgc190aW1lX3QgIGxhdGVuY3k7DQogIA0KLSAgICAvKnN0YXR1cyBvZiBkb21h
aW4qLw0KKyAgICAvKiBTdGF0dXMgb2YgZG9tYWluICovDQogICAgIGludCAgICAgICBzdGF0dXM7
DQotICAgIC8qd2VpZ2h0cyBmb3IgIlNjaGVkdWxpbmcgZm9yIGJlZ2lubmVycy8gbGF6eS8gZXRj
LiIgOykqLw0KKyAgICAvKiBXZWlnaHRzIGZvciAiU2NoZWR1bGluZyBmb3IgYmVnaW5uZXJzLyBs
YXp5LyBldGMuIiA7KSAqLw0KICAgICBzaG9ydCAgICAgd2VpZ2h0Ow0KICAgICBzaG9ydCAgICAg
ZXh0cmF3ZWlnaHQ7DQotICAgIC8qQm9va2tlZXBpbmcqLw0KKyAgICAvKiBCb29ra2VlcGluZyAq
Lw0KICAgICBzX3RpbWVfdCAgZGVhZGxfYWJzOw0KICAgICBzX3RpbWVfdCAgc2NoZWRfc3RhcnRf
YWJzOw0KICAgICBzX3RpbWVfdCAgY3B1dGltZTsNCi0gICAgLyogdGltZXMgdGhlIGRvbWFpbiB1
bi0vYmxvY2tlZCAqLw0KKyAgICAvKiBUaW1lcyB0aGUgZG9tYWluIHVuLS9ibG9ja2VkICovDQog
ICAgIHNfdGltZV90ICBibG9ja19hYnM7DQogICAgIHNfdGltZV90ICB1bmJsb2NrX2FiczsNCiAg
DQotICAgIC8qc2NvcmVzIGZvciB7dXRpbCwgYmxvY2sgcGVuYWx0eX0td2VpZ2h0ZWQgZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiovDQorICAgIC8qIFNjb3JlcyBmb3Ige3V0aWwsIGJsb2NrIHBlbmFs
dHl9LXdlaWdodGVkIGV4dHJhdGltZSBkaXN0cmlidXRpb24gKi8NCiAgICAgaW50ICAgc2NvcmVb
Ml07DQogICAgIHNfdGltZV90ICBzaG9ydF9ibG9ja19sb3N0X3RvdDsNCiAgDQotICAgIC8qU3Rh
dGlzdGljcyovDQorICAgIC8qIFN0YXRpc3RpY3MgKi8NCiAgICAgc190aW1lX3QgIGV4dHJhX3Rp
bWVfdG90Ow0KIA0KICNpZmRlZiBTRURGX1NUQVRTDQpAQCAtMTY1LDE4ICsxNTgsMTcgQEAgc3Rh
dGljIGlubGluZSB2b2lkIGV4dHJhcV9kZWwoc3RydWN0IHZjcA0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IEVYVFJBTElTVChkLGkpOw0KICAgICBBU1NFUlQoZXh0cmFxX29uKGQs
aSkpOw0KLSAgICBQUklOVCgzLCAiUmVtb3ZpbmcgZG9tYWluICVpLiVpIGZyb20gTCVpIGV4dHJh
cVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGkpOw0K
ICAgICBsaXN0X2RlbChsaXN0KTsNCiAgICAgbGlzdC0+bmV4dCA9IE5VTEw7DQogICAgIEFTU0VS
VCghZXh0cmFxX29uKGQsIGkpKTsNCiB9DQogDQotLyogYWRkcyBhIGRvbWFpbiB0byB0aGUgcXVl
dWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQotICAg
aXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBwcmlv
cml0eSBmb3IgYW4gZXh0cmENCi0gICBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29yZSwg
Ynkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KLSAgIGVhY2ggZW50cnks
IGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNpbXBs
eQ0KLSAgIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdpdGgg
YW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KKy8qDQorICogQWRkcyBhIGRvbWFpbiB0byB0aGUg
cXVldWUgb2YgcHJvY2Vzc2VzIHdoaWNoIGFyZSBhd2FyZSBvZiBleHRyYSB0aW1lLiBMaXN0DQor
ICogaXMgc29ydGVkIGJ5IHNjb3JlLCB3aGVyZSBhIGxvd2VyIHNjb3JlIG1lYW5zIGhpZ2hlciBw
cmlvcml0eSBmb3IgYW4gZXh0cmENCisgKiBzbGljZS4gSXQgYWxzbyB1cGRhdGVzIHRoZSBzY29y
ZSwgYnkgc2ltcGx5IHN1YnRyYWN0aW5nIGEgZml4ZWQgdmFsdWUgZnJvbQ0KKyAqIGVhY2ggZW50
cnksIGluIG9yZGVyIHRvIGF2b2lkIG92ZXJmbG93LiBUaGUgYWxnb3JpdGhtIHdvcmtzIGJ5IHNp
bXBseQ0KKyAqIGNoYXJnaW5nIGVhY2ggZG9tYWluIHRoYXQgcmVjaWV2ZWQgZXh0cmF0aW1lIHdp
dGggYW4gaW52ZXJzZSBvZiBpdHMgd2VpZ2h0Lg0KICAqLyANCiBzdGF0aWMgaW5saW5lIHZvaWQg
ZXh0cmFxX2FkZF9zb3J0X3VwZGF0ZShzdHJ1Y3QgdmNwdSAqZCwgaW50IGksIGludCBzdWIpDQog
ew0KQEAgLTE4NSwxMSArMTc3LDYgQEAgc3RhdGljIGlubGluZSB2b2lkIGV4dHJhcV9hZGRfc29y
dF91cGRhdA0KICANCiAgICAgQVNTRVJUKCFleHRyYXFfb24oZCxpKSk7DQogDQotICAgIFBSSU5U
KDMsICJBZGRpbmcgZG9tYWluICVpLiVpIChzY29yZT0gJWksIHNob3J0X3Blbj0gJSJQUklpNjQi
KSINCi0gICAgICAgICAgIiB0byBMJWkgZXh0cmFxXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4t
PmRvbWFpbl9pZCwgZC0+dmNwdV9pZCwgRURPTV9JTkZPKGQpLT5zY29yZVtpXSwNCi0gICAgICAg
ICAgRURPTV9JTkZPKGQpLT5zaG9ydF9ibG9ja19sb3N0X3RvdCwgaSk7DQotDQogICAgIC8qDQog
ICAgICAqIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIgImhvbGUiIGFu
ZCBvbiBvdXIgd2F5DQogICAgICAqIHVwZGF0ZSBhbGwgdGhlIG90aGVyIHNjb3Jlcy4NCkBAIC0y
MDAsMjUgKzE4NywxOCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgZXh0cmFxX2FkZF9zb3J0X3VwZGF0
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
IC0yMjgsMjkgKzIwOCwxNCBAQCBzdGF0aWMgaW5saW5lIHZvaWQgZXh0cmFxX2NoZWNrKHN0cnVj
dCB2DQogew0KICAgICBpZiAoIGV4dHJhcV9vbihkLCBFWFRSQV9VVElMX1EpICkNCiAgICAgew0K
LSAgICAgICAgUFJJTlQoMiwiRG9tICVpLiVpIGlzIG9uIEwxIGV4dHJhUVxuIiwNCi0gICAgICAg
ICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0NCiAgICAgICAgIGlm
ICggIShFRE9NX0lORk8oZCktPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJg0KICAgICAgICAgICAg
ICAhZXh0cmFfcnVucyhFRE9NX0lORk8oZCkpICkNCi0gICAgICAgIHsNCiAgICAgICAgICAgICBl
eHRyYXFfZGVsKGQsIEVYVFJBX1VUSUxfUSk7DQotICAgICAgICAgICAgUFJJTlQoMiwiUmVtb3Zl
ZCBkb20gJWkuJWkgZnJvbSBMMSBleHRyYVFcbiIsDQotICAgICAgICAgICAgICAgICAgZC0+ZG9t
YWluLT5kb21haW5faWQsIGQtPnZjcHVfaWQpOw0KLSAgICAgICAgfQ0KICAgICB9DQogICAgIGVs
c2UNCiAgICAgew0KLSAgICAgICAgUFJJTlQoMiwgIkRvbSAlaS4laSBpcyBOT1Qgb24gTDEgZXh0
cmFRXG4iLA0KLSAgICAgICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAgICAg
ICAgICBkLT52Y3B1X2lkKTsNCi0NCiAgICAgICAgIGlmICggKEVET01fSU5GTyhkKS0+c3RhdHVz
ICYgRVhUUkFfQVdBUkUpICYmIHNlZGZfcnVubmFibGUoZCkgKQ0KLSAgICAgICAgew0KICAgICAg
ICAgICAgIGV4dHJhcV9hZGRfc29ydF91cGRhdGUoZCwgRVhUUkFfVVRJTF9RLCAwKTsNCi0gICAg
ICAgICAgICBQUklOVCgyLCJBZGRlZCBkb20gJWkuJWkgdG8gTDEgZXh0cmFRXG4iLA0KLSAgICAg
ICAgICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52Y3B1X2lkKTsNCi0gICAgICAg
IH0NCiAgICAgfQ0KIH0NCiANCkBAIC0yNTksNyArMjI0LDcgQEAgc3RhdGljIGlubGluZSB2b2lk
IGV4dHJhcV9jaGVja19hZGRfdW5ibA0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gKmluZiA9
IEVET01fSU5GTyhkKTsNCiANCiAgICAgaWYgKCBpbmYtPnN0YXR1cyAmIEVYVFJBX0FXQVJFICkN
Ci0gICAgICAgIC8qIFB1dCBvbiB0aGUgd2VpZ2h0ZWQgZXh0cmFxIHdpdGhvdXQgdXBkYXRpbmcg
YW55IHNjb3Jlcy4gKi8NCisgICAgICAgIC8qIFB1dCBvbiB0aGUgd2VpZ2h0ZWQgZXh0cmFxIHdp
dGhvdXQgdXBkYXRpbmcgYW55IHNjb3JlcyAqLw0KICAgICAgICAgZXh0cmFxX2FkZF9zb3J0X3Vw
ZGF0ZShkLCBFWFRSQV9VVElMX1EsIDApOw0KIH0NCiANCkBAIC0yNzIsOCArMjM3LDYgQEAgc3Rh
dGljIGlubGluZSB2b2lkIF9fZGVsX2Zyb21fcXVldWUoc3RydQ0KIHsNCiAgICAgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCA9IExJU1QoZCk7DQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkp
Ow0KLSAgICBQUklOVCgzLCJSZW1vdmluZyBkb21haW4gJWkuJWkgKGJvcD0gJSJQUkl1NjQiKSBm
cm9tIHJ1bnEvd2FpdHFcbiIsDQotICAgICAgICAgIGQtPmRvbWFpbi0+ZG9tYWluX2lkLCBkLT52
Y3B1X2lkLCBQRVJJT0RfQkVHSU4oRURPTV9JTkZPKGQpKSk7DQogICAgIGxpc3RfZGVsKGxpc3Qp
Ow0KICAgICBsaXN0LT5uZXh0ID0gTlVMTDsNCiAgICAgQVNTRVJUKCFfX3Rhc2tfb25fcXVldWUo
ZCkpOw0KQEAgLTI4NiwxMyArMjQ5LDEyIEBAIHN0YXRpYyBpbmxpbmUgdm9pZCBsaXN0X2luc2Vy
dF9zb3J0KA0KIHsNCiAgICAgc3RydWN0IGxpc3RfaGVhZCAgICAgKmN1cjsNCiANCi0gICAgLyog
SXRlcmF0ZSB0aHJvdWdoIGFsbCBlbGVtZW50cyB0byBmaW5kIG91ciAiaG9sZSIuICovDQorICAg
IC8qIEl0ZXJhdGUgdGhyb3VnaCBhbGwgZWxlbWVudHMgdG8gZmluZCBvdXIgImhvbGUiICovDQog
ICAgIGxpc3RfZm9yX2VhY2goIGN1ciwgbGlzdCApDQogICAgICAgICBpZiAoIGNvbXAoZWxlbWVu
dCwgY3VyKSA8IDAgKQ0KICAgICAgICAgICAgIGJyZWFrOw0KIA0KLSAgICAvKiBjdXIgbm93IGNv
bnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUgd2hpY2ggd2UnbGwgZW5xdWV1ZS4gKi8NCi0gICAg
UFJJTlQoMywiXHRsaXN0X2FkZCB0byAlcFxuIixjdXItPnByZXYpOw0KKyAgICAvKiBjdXIgbm93
IGNvbnRhaW5zIHRoZSBlbGVtZW50LCBiZWZvcmUgd2hpY2ggd2UnbGwgZW5xdWV1ZSAqLw0KICAg
ICBsaXN0X2FkZChlbGVtZW50LCBjdXItPnByZXYpOw0KIH0NCiANCkBAIC0zMTAsMzAgKzI3Miwy
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
ciksIExJU1QodiksIHJ1bnFfY29tcCk7DQogfQ0KIA0KQEAgLTM2MSwxMiArMzIxLDEyIEBAIHN0
YXRpYyB2b2lkICpzZWRmX2FsbG9jX3ZkYXRhKGNvbnN0IHN0cnUNCiANCiAgICAgaW5mLT52Y3B1
ID0gdjsNCiANCi0gICAgLyogRXZlcnkgVkNQVSBnZXRzIGFuIGVxdWFsIHNoYXJlIG9mIGV4dHJh
dGltZSBieSBkZWZhdWx0LiAqLw0KKyAgICAvKiBFdmVyeSBWQ1BVIGdldHMgYW4gZXF1YWwgc2hh
cmUgb2YgZXh0cmF0aW1lIGJ5IGRlZmF1bHQgKi8NCiAgICAgaW5mLT5kZWFkbF9hYnMgICA9IDA7
DQogICAgIGluZi0+bGF0ZW5jeSAgICAgPSAwOw0KICAgICBpbmYtPnN0YXR1cyAgICAgID0gRVhU
UkFfQVdBUkUgfCBTRURGX0FTTEVFUDsNCiAgICAgaW5mLT5leHRyYXdlaWdodCA9IDE7DQotICAg
IC8qIFVwb24gY3JlYXRpb24gYWxsIGRvbWFpbiBhcmUgYmVzdC1lZmZvcnQuICovDQorICAgIC8q
IFVwb24gY3JlYXRpb24gYWxsIGRvbWFpbiBhcmUgYmVzdC1lZmZvcnQgKi8NCiAgICAgaW5mLT5w
ZXJpb2QgICAgICA9IFdFSUdIVF9QRVJJT0Q7DQogICAgIGluZi0+c2xpY2UgICAgICAgPSAwOw0K
IA0KQEAgLTQ1MCwyMSArNDEwLDE5IEBAIHN0YXRpYyB2b2lkIGRlc2NoZWRfZWRmX2RvbShzX3Rp
bWVfdCBub3cNCiB7DQogICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyogaW5mID0gRURPTV9JTkZP
KGQpOw0KIA0KLSAgICAvKiBDdXJyZW50IGRvbWFpbiBpcyBydW5uaW5nIGluIHJlYWwgdGltZSBt
b2RlLiAqLw0KKyAgICAvKiBDdXJyZW50IGRvbWFpbiBpcyBydW5uaW5nIGluIHJlYWwgdGltZSBt
b2RlICovDQogICAgIEFTU0VSVChfX3Rhc2tfb25fcXVldWUoZCkpOw0KIA0KLSAgICAvKiBVcGRh
dGUgdGhlIGRvbWFpbidzIGNwdXRpbWUuICovDQorICAgIC8qIFVwZGF0ZSB0aGUgZG9tYWluJ3Mg
Y3B1dGltZSAqLw0KICAgICBpbmYtPmNwdXRpbWUgKz0gbm93IC0gaW5mLT5zY2hlZF9zdGFydF9h
YnM7DQogDQotICAgIC8qDQotICAgICAqIFNjaGVkdWxpbmcgZGVjaXNpb25zIHdoaWNoIGRvbid0
IHJlbW92ZSB0aGUgcnVubmluZyBkb21haW4gZnJvbSB0aGUNCi0gICAgICogcnVucS4gDQotICAg
ICAqLw0KKyAgICAvKiBTY2hlZHVsaW5nIGRlY2lzaW9ucyB3aGljaCBkb24ndCByZW1vdmUgdGhl
IHJ1bm5pbmcgZG9tYWluIGZyb20NCisgICAgICogdGhlIHJ1bnEgKi8NCiAgICAgaWYgKCAoaW5m
LT5jcHV0aW1lIDwgaW5mLT5zbGljZSkgJiYgc2VkZl9ydW5uYWJsZShkKSApDQogICAgICAgICBy
ZXR1cm47DQogICANCiAgICAgX19kZWxfZnJvbV9xdWV1ZShkKTsNCi0gIA0KKw0KICAgICAvKg0K
ICAgICAgKiBNYW5hZ2UgYm9va2tlZXBpbmcgKGkuZS4gY2FsY3VsYXRlIG5leHQgZGVhZGxpbmUs
IG1lbW9yaXNlDQogICAgICAqIG92ZXJydW4tdGltZSBvZiBzbGljZSkgb2YgZmluaXNoZWQgZG9t
YWlucy4NCkBAIC00NzUsMzAgKzQzMywzMCBAQCBzdGF0aWMgdm9pZCBkZXNjaGVkX2VkZl9kb20o
c190aW1lX3Qgbm93DQogICANCiAgICAgICAgIGlmICggaW5mLT5wZXJpb2QgPCBpbmYtPnBlcmlv
ZF9vcmlnICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKiBUaGlzIGRvbWFpbiBydW5zIGlu
IGxhdGVuY3kgc2NhbGluZyBvciBidXJzdCBtb2RlLiAqLw0KKyAgICAgICAgICAgIC8qIFRoaXMg
ZG9tYWluIHJ1bnMgaW4gbGF0ZW5jeSBzY2FsaW5nIG9yIGJ1cnN0IG1vZGUgKi8NCiAgICAgICAg
ICAgICBpbmYtPnBlcmlvZCAqPSAyOw0KICAgICAgICAgICAgIGluZi0+c2xpY2UgICo9IDI7DQog
ICAgICAgICAgICAgaWYgKCAoaW5mLT5wZXJpb2QgPiBpbmYtPnBlcmlvZF9vcmlnKSB8fA0KICAg
ICAgICAgICAgICAgICAgKGluZi0+c2xpY2UgPiBpbmYtPnNsaWNlX29yaWcpICkNCiAgICAgICAg
ICAgICB7DQotICAgICAgICAgICAgICAgIC8qIFJlc2V0IHNsaWNlIGFuZCBwZXJpb2QuICovDQor
ICAgICAgICAgICAgICAgIC8qIFJlc2V0IHNsaWNlIGFuZCBwZXJpb2QgKi8NCiAgICAgICAgICAg
ICAgICAgaW5mLT5wZXJpb2QgPSBpbmYtPnBlcmlvZF9vcmlnOw0KICAgICAgICAgICAgICAgICBp
bmYtPnNsaWNlID0gaW5mLT5zbGljZV9vcmlnOw0KICAgICAgICAgICAgIH0NCiAgICAgICAgIH0N
CiANCi0gICAgICAgIC8qIFNldCBuZXh0IGRlYWRsaW5lLiAqLw0KKyAgICAgICAgLyogU2V0IG5l
eHQgZGVhZGxpbmUgKi8NCiAgICAgICAgIGluZi0+ZGVhZGxfYWJzICs9IGluZi0+cGVyaW9kOw0K
ICAgICB9DQogIA0KLSAgICAvKiBBZGQgYSBydW5uYWJsZSBkb21haW4gdG8gdGhlIHdhaXRxdWV1
ZS4gKi8NCisgICAgLyogQWRkIGEgcnVubmFibGUgZG9tYWluIHRvIHRoZSB3YWl0cXVldWUgKi8N
CiAgICAgaWYgKCBzZWRmX3J1bm5hYmxlKGQpICkNCiAgICAgew0KICAgICAgICAgX19hZGRfdG9f
d2FpdHF1ZXVlX3NvcnQoZCk7DQogICAgIH0NCiAgICAgZWxzZQ0KICAgICB7DQotICAgICAgICAv
KiBXZSBoYXZlIGEgYmxvY2tlZCByZWFsdGltZSB0YXNrIC0+IHJlbW92ZSBpdCBmcm9tIGV4cXMg
dG9vLiAqLw0KKyAgICAgICAgLyogV2UgaGF2ZSBhIGJsb2NrZWQgcmVhbHRpbWUgdGFzayAtPiBy
ZW1vdmUgaXQgZnJvbSBleHFzIHRvbyAqLw0KICAgICAgICAgaWYgKCBleHRyYXFfb24oZCwgRVhU
UkFfUEVOX1EpICkNCiAgICAgICAgICAgICBleHRyYXFfZGVsKGQsIEVYVFJBX1BFTl9RKTsNCiAg
ICAgICAgIGlmICggZXh0cmFxX29uKGQsIEVYVFJBX1VUSUxfUSkgKQ0KQEAgLTUxOCw4ICs0NzYs
NiBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfcXVldWVzKA0KICAgICBzdHJ1Y3QgbGlzdF9oZWFkICAg
ICAqY3VyLCAqdG1wOw0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gKmN1cmluZjsNCiAgDQot
ICAgIFBSSU5UKDMsIlVwZGF0aW5nIHdhaXRxLi5cbiIpOw0KLQ0KICAgICAvKg0KICAgICAgKiBD
aGVjayBmb3IgdGhlIGZpcnN0IGVsZW1lbnRzIG9mIHRoZSB3YWl0cXVldWUsIHdoZXRoZXIgdGhl
aXINCiAgICAgICogbmV4dCBwZXJpb2QgaGFzIGFscmVhZHkgc3RhcnRlZC4NCkBAIC01MjcsNDEg
KzQ4MywzMiBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfcXVldWVzKA0KICAgICBsaXN0X2Zvcl9lYWNo
X3NhZmUgKCBjdXIsIHRtcCwgd2FpdHEgKQ0KICAgICB7DQogICAgICAgICBjdXJpbmYgPSBsaXN0
X2VudHJ5KGN1ciwgc3RydWN0IHNlZGZfdmNwdV9pbmZvLCBsaXN0KTsNCi0gICAgICAgIFBSSU5U
KDQsIlx0TG9va2luZyBAIGRvbSAlaS4laVxuIiwNCi0gICAgICAgICAgICAgIGN1cmluZi0+dmNw
dS0+ZG9tYWluLT5kb21haW5faWQsIGN1cmluZi0+dmNwdS0+dmNwdV9pZCk7DQogICAgICAgICBp
ZiAoIFBFUklPRF9CRUdJTihjdXJpbmYpID4gbm93ICkNCiAgICAgICAgICAgICBicmVhazsNCiAg
ICAgICAgIF9fZGVsX2Zyb21fcXVldWUoY3VyaW5mLT52Y3B1KTsNCiAgICAgICAgIF9fYWRkX3Rv
X3J1bnF1ZXVlX3NvcnQoY3VyaW5mLT52Y3B1KTsNCiAgICAgfQ0KICANCi0gICAgUFJJTlQoMywi
VXBkYXRpbmcgcnVucS4uXG4iKTsNCi0NCi0gICAgLyogUHJvY2VzcyB0aGUgcnVucSwgZmluZCBk
b21haW5zIHRoYXQgYXJlIG9uIHRoZSBydW5xIHRoYXQgc2hvdWxkbid0LiAqLw0KKyAgICAvKiBQ
cm9jZXNzIHRoZSBydW5xLCBmaW5kIGRvbWFpbnMgdGhhdCBhcmUgb24gdGhlIHJ1bnEgdGhhdCBz
aG91bGRuJ3QgKi8NCiAgICAgbGlzdF9mb3JfZWFjaF9zYWZlICggY3VyLCB0bXAsIHJ1bnEgKQ0K
ICAgICB7DQogICAgICAgICBjdXJpbmYgPSBsaXN0X2VudHJ5KGN1cixzdHJ1Y3Qgc2VkZl92Y3B1
X2luZm8sbGlzdCk7DQotICAgICAgICBQUklOVCg0LCJcdExvb2tpbmcgQCBkb20gJWkuJWlcbiIs
DQotICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLCBjdXJpbmYt
PnZjcHUtPnZjcHVfaWQpOw0KIA0KICAgICAgICAgaWYgKCB1bmxpa2VseShjdXJpbmYtPnNsaWNl
ID09IDApICkNCiAgICAgICAgIHsNCi0gICAgICAgICAgICAvKiBJZ25vcmUgZG9tYWlucyB3aXRo
IGVtcHR5IHNsaWNlLiAqLw0KLSAgICAgICAgICAgIFBSSU5UKDQsIlx0VXBkYXRpbmcgemVyby1z
bGljZSBkb21haW4gJWkuJWlcbiIsDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT52Y3B1LT5k
b21haW4tPmRvbWFpbl9pZCwNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPnZjcHVf
aWQpOw0KKyAgICAgICAgICAgIC8qIElnbm9yZSBkb21haW5zIHdpdGggZW1wdHkgc2xpY2UgKi8N
CiAgICAgICAgICAgICBfX2RlbF9mcm9tX3F1ZXVlKGN1cmluZi0+dmNwdSk7DQogDQotICAgICAg
ICAgICAgLyogTW92ZSB0aGVtIHRvIHRoZWlyIG5leHQgcGVyaW9kLiAqLw0KKyAgICAgICAgICAg
IC8qIE1vdmUgdGhlbSB0byB0aGVpciBuZXh0IHBlcmlvZCAqLw0KICAgICAgICAgICAgIGN1cmlu
Zi0+ZGVhZGxfYWJzICs9IGN1cmluZi0+cGVyaW9kOw0KIA0KLSAgICAgICAgICAgIC8qIEVuc3Vy
ZSB0aGF0IHRoZSBzdGFydCBvZiB0aGUgbmV4dCBwZXJpb2QgaXMgaW4gdGhlIGZ1dHVyZS4gKi8N
CisgICAgICAgICAgICAvKiBFbnN1cmUgdGhhdCB0aGUgc3RhcnQgb2YgdGhlIG5leHQgcGVyaW9k
IGlzIGluIHRoZSBmdXR1cmUgKi8NCiAgICAgICAgICAgICBpZiAoIHVubGlrZWx5KFBFUklPRF9C
RUdJTihjdXJpbmYpIDwgbm93KSApDQogICAgICAgICAgICAgICAgIGN1cmluZi0+ZGVhZGxfYWJz
ICs9IA0KICAgICAgICAgICAgICAgICAgICAgKERJVl9VUChub3cgLSBQRVJJT0RfQkVHSU4oY3Vy
aW5mKSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3VyaW5mLT5wZXJpb2QpKSAqIGN1
cmluZi0+cGVyaW9kOw0KIA0KLSAgICAgICAgICAgIC8qIFB1dCB0aGVtIGJhY2sgaW50byB0aGUg
cXVldWUuICovDQorICAgICAgICAgICAgLyogUHV0IHRoZW0gYmFjayBpbnRvIHRoZSBxdWV1ZSAq
Lw0KICAgICAgICAgICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGN1cmluZi0+dmNwdSk7DQog
ICAgICAgICB9DQogICAgICAgICBlbHNlIGlmICggdW5saWtlbHkoKGN1cmluZi0+ZGVhZGxfYWJz
IDwgbm93KSB8fA0KQEAgLTU3MSwxOCArNTE4LDE4IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1
ZXMoDQogICAgICAgICAgICAgICogV2UgbWlzc2VkIHRoZSBkZWFkbGluZSBvciB0aGUgc2xpY2Ug
d2FzIGFscmVhZHkgZmluaXNoZWQuDQogICAgICAgICAgICAgICogTWlnaHQgaGFwZW4gYmVjYXVz
ZSBvZiBkb21fYWRqLg0KICAgICAgICAgICAgICAqLw0KLSAgICAgICAgICAgIFBSSU5UKDQsIlx0
RG9tYWluICVpLiVpIGV4Y2VlZGVkIGl0J3MgZGVhZGxpbmUvIg0KLSAgICAgICAgICAgICAgICAg
ICJzbGljZSAoJSJQUkl1NjQiIC8gJSJQUkl1NjQiKSBub3c6ICUiUFJJdTY0DQotICAgICAgICAg
ICAgICAgICAgIiBjcHV0aW1lOiAlIlBSSXU2NCJcbiIsDQotICAgICAgICAgICAgICAgICAgY3Vy
aW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYt
PnZjcHUtPnZjcHVfaWQsDQotICAgICAgICAgICAgICAgICAgY3VyaW5mLT5kZWFkbF9hYnMsIGN1
cmluZi0+c2xpY2UsIG5vdywNCi0gICAgICAgICAgICAgICAgICBjdXJpbmYtPmNwdXRpbWUpOw0K
KyAgICAgICAgICAgIHByaW50aygiXHREb21haW4gJWkuJWkgZXhjZWVkZWQgaXQncyBkZWFkbGlu
ZS8iDQorICAgICAgICAgICAgICAgICAgICJzbGljZSAoJSJQUkl1NjQiIC8gJSJQUkl1NjQiKSBu
b3c6ICUiUFJJdTY0DQorICAgICAgICAgICAgICAgICAgICIgY3B1dGltZTogJSJQUkl1NjQiXG4i
LA0KKyAgICAgICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPmRvbWFpbi0+ZG9tYWluX2lkLA0K
KyAgICAgICAgICAgICAgICAgICBjdXJpbmYtPnZjcHUtPnZjcHVfaWQsDQorICAgICAgICAgICAg
ICAgICAgIGN1cmluZi0+ZGVhZGxfYWJzLCBjdXJpbmYtPnNsaWNlLCBub3csDQorICAgICAgICAg
ICAgICAgICAgIGN1cmluZi0+Y3B1dGltZSk7DQogICAgICAgICAgICAgX19kZWxfZnJvbV9xdWV1
ZShjdXJpbmYtPnZjcHUpOw0KIA0KLSAgICAgICAgICAgIC8qIENvbW1vbiBjYXNlOiB3ZSBtaXNz
IG9uZSBwZXJpb2QuICovDQorICAgICAgICAgICAgLyogQ29tbW9uIGNhc2U6IHdlIG1pc3Mgb25l
IHBlcmlvZCAqLw0KICAgICAgICAgICAgIGN1cmluZi0+ZGVhZGxfYWJzICs9IGN1cmluZi0+cGVy
aW9kOw0KLSAgIA0KKw0KICAgICAgICAgICAgIC8qDQogICAgICAgICAgICAgICogSWYgd2UgYXJl
IHN0aWxsIGJlaGluZDogbW9kdWxvIGFyaXRobWV0aWMsIGZvcmNlIGRlYWRsaW5lDQogICAgICAg
ICAgICAgICogdG8gYmUgaW4gZnV0dXJlIGFuZCBhbGlnbmVkIHRvIHBlcmlvZCBib3JkZXJzLg0K
QEAgLTU5Myw3ICs1NDAsNyBAQCBzdGF0aWMgdm9pZCB1cGRhdGVfcXVldWVzKA0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGN1cmluZi0+cGVyaW9kKSAqIGN1cmluZi0+cGVyaW9kOw0KICAg
ICAgICAgICAgIEFTU0VSVChjdXJpbmYtPmRlYWRsX2FicyA+PSBub3cpOw0KIA0KLSAgICAgICAg
ICAgIC8qIEdpdmUgYSBmcmVzaCBzbGljZS4gKi8NCisgICAgICAgICAgICAvKiBHaXZlIGEgZnJl
c2ggc2xpY2UgKi8NCiAgICAgICAgICAgICBjdXJpbmYtPmNwdXRpbWUgPSAwOw0KICAgICAgICAg
ICAgIGlmICggUEVSSU9EX0JFR0lOKGN1cmluZikgPiBub3cgKQ0KICAgICAgICAgICAgICAgICBf
X2FkZF90b193YWl0cXVldWVfc29ydChjdXJpbmYtPnZjcHUpOw0KQEAgLTYwMywxNyArNTUwLDE3
IEBAIHN0YXRpYyB2b2lkIHVwZGF0ZV9xdWV1ZXMoDQogICAgICAgICBlbHNlDQogICAgICAgICAg
ICAgYnJlYWs7DQogICAgIH0NCi0NCi0gICAgUFJJTlQoMywiZG9uZSB1cGRhdGluZyB0aGUgcXVl
dWVzXG4iKTsNCiB9DQogDQogDQotLyogcmVtb3ZlcyBhIGRvbWFpbiBmcm9tIHRoZSBoZWFkIG9m
IHRoZSBhY2NvcmRpbmcgZXh0cmFRIGFuZA0KLSAgIHJlcXVldWVzIGl0IGF0IGEgc3BlY2lmaWVk
IHBvc2l0aW9uOg0KLSAgICAgcm91bmQtcm9iaW4gZXh0cmF0aW1lOiBlbmQgb2YgZXh0cmFRDQot
ICAgICB3ZWlnaHRlZCBleHQuOiBpbnNlcnQgaW4gc29ydGVkIGxpc3QgYnkgc2NvcmUNCi0gICBp
ZiB0aGUgZG9tYWluIGlzIGJsb2NrZWQgLyBoYXMgcmVnYWluZWQgaXRzIHNob3J0LWJsb2NrLWxv
c3MNCi0gICB0aW1lIGl0IGlzIG5vdCBwdXQgb24gYW55IHF1ZXVlICovDQorLyoNCisgKiByZW1v
dmVzIGEgZG9tYWluIGZyb20gdGhlIGhlYWQgb2YgdGhlIGFjY29yZGluZyBleHRyYVEgYW5kDQor
ICogcmVxdWV1ZXMgaXQgYXQgYSBzcGVjaWZpZWQgcG9zaXRpb246DQorICogICByb3VuZC1yb2Jp
biBleHRyYXRpbWU6IGVuZCBvZiBleHRyYVENCisgKiAgIHdlaWdodGVkIGV4dC46IGluc2VydCBp
biBzb3J0ZWQgbGlzdCBieSBzY29yZQ0KKyAqIGlmIHRoZSBkb21haW4gaXMgYmxvY2tlZCAvIGhh
cyByZWdhaW5lZCBpdHMgc2hvcnQtYmxvY2stbG9zcw0KKyAqIHRpbWUgaXQgaXMgbm90IHB1dCBv
biBhbnkgcXVldWUuDQorICovDQogc3RhdGljIHZvaWQgZGVzY2hlZF9leHRyYV9kb20oc190aW1l
X3Qgbm93LCBzdHJ1Y3QgdmNwdSAqZCkNCiB7DQogICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyAq
aW5mID0gRURPTV9JTkZPKGQpOw0KQEAgLTYyMiwyOSArNTY5LDI1IEBAIHN0YXRpYyB2b2lkIGRl
c2NoZWRfZXh0cmFfZG9tKHNfdGltZV90IG4NCiANCiAgICAgQVNTRVJUKGV4dHJhcV9vbihkLCBp
KSk7DQogDQotICAgIC8qIFVuc2V0IGFsbCBydW5uaW5nIGZsYWdzLiAqLw0KKyAgICAvKiBVbnNl
dCBhbGwgcnVubmluZyBmbGFncyAqLw0KICAgICBpbmYtPnN0YXR1cyAgJj0gfihFWFRSQV9SVU5f
UEVOIHwgRVhUUkFfUlVOX1VUSUwpOw0KLSAgICAvKiBGcmVzaCBzbGljZSBmb3IgdGhlIG5leHQg
cnVuLiAqLw0KKyAgICAvKiBGcmVzaCBzbGljZSBmb3IgdGhlIG5leHQgcnVuICovDQogICAgIGlu
Zi0+Y3B1dGltZSA9IDA7DQotICAgIC8qIEFjY3VtdWxhdGUgdG90YWwgZXh0cmF0aW1lLiAqLw0K
KyAgICAvKiBBY2N1bXVsYXRlIHRvdGFsIGV4dHJhdGltZSAqLw0KICAgICBpbmYtPmV4dHJhX3Rp
bWVfdG90ICs9IG5vdyAtIGluZi0+c2NoZWRfc3RhcnRfYWJzOw0KICAgICAvKiBSZW1vdmUgZXh0
cmFkb21haW4gZnJvbSBoZWFkIG9mIHRoZSBxdWV1ZS4gKi8NCiAgICAgZXh0cmFxX2RlbChkLCBp
KTsNCiANCi0gICAgLyogVXBkYXRlIHRoZSBzY29yZS4gKi8NCisgICAgLyogVXBkYXRlIHRoZSBz
Y29yZSAqLw0KICAgICBvbGRzY29yZSA9IGluZi0+c2NvcmVbaV07DQogICAgIGlmICggaSA9PSBF
WFRSQV9QRU5fUSApDQogICAgIHsNCi0gICAgICAgIC8qZG9tYWluIHdhcyBydW5uaW5nIGluIEww
IGV4dHJhcSovDQotICAgICAgICAvKnJlZHVjZSBibG9jayBsb3N0LCBwcm9iYWJseSBtb3JlIHNv
cGhpc3RpY2F0aW9uIGhlcmUhKi8NCisgICAgICAgIC8qIERvbWFpbiB3YXMgcnVubmluZyBpbiBM
MCBleHRyYXEgKi8NCisgICAgICAgIC8qIHJlZHVjZSBibG9jayBsb3N0LCBwcm9iYWJseSBtb3Jl
IHNvcGhpc3RpY2F0aW9uIGhlcmUhKi8NCiAgICAgICAgIC8qaW5mLT5zaG9ydF9ibG9ja19sb3N0
X3RvdCAtPSBFWFRSQV9RVUFOVFVNOyovDQogICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3Rf
dG90IC09IG5vdyAtIGluZi0+c2NoZWRfc3RhcnRfYWJzOw0KLSAgICAgICAgUFJJTlQoMywiRG9t
YWluICVpLiVpOiBTaG9ydF9ibG9ja19sb3NzOiAlIlBSSWk2NCJcbiIsIA0KLSAgICAgICAgICAg
ICAgaW5mLT52Y3B1LT5kb21haW4tPmRvbWFpbl9pZCwgaW5mLT52Y3B1LT52Y3B1X2lkLA0KLSAg
ICAgICAgICAgICAgaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCk7DQogI2lmIDANCi0gICAgICAg
IC8qDQotICAgICAgICAgKiBLQUY6IElmIHdlIGRvbid0IGV4aXQgc2hvcnQtYmxvY2tpbmcgc3Rh
dGUgYXQgdGhpcyBwb2ludA0KKyAgICAgICAgLyogS0FGOiBJZiB3ZSBkb24ndCBleGl0IHNob3J0
LWJsb2NraW5nIHN0YXRlIGF0IHRoaXMgcG9pbnQNCiAgICAgICAgICAqIGRvbWFpbjAgY2FuIHN0
ZWFsIGFsbCBDUFUgZm9yIHVwIHRvIDEwIHNlY29uZHMgYmVmb3JlDQogICAgICAgICAgKiBzY2hl
ZHVsaW5nIHNldHRsZXMgZG93biAod2hlbiBjb21wZXRpbmcgYWdhaW5zdCBhbm90aGVyDQogICAg
ICAgICAgKiBDUFUtYm91bmQgZG9tYWluKS4gRG9pbmcgdGhpcyBzZWVtcyB0byBtYWtlIHRoaW5n
cyBiZWhhdmUNCkBAIC02NTMsNTEgKzU5Niw1OSBAQCBzdGF0aWMgdm9pZCBkZXNjaGVkX2V4dHJh
X2RvbShzX3RpbWVfdCBuDQogICAgICAgICBpZiAoIGluZi0+c2hvcnRfYmxvY2tfbG9zdF90b3Qg
PD0gMCApDQogI2VuZGlmDQogICAgICAgICB7DQotICAgICAgICAgICAgUFJJTlQoNCwiRG9tYWlu
ICVpLiVpIGNvbXBlbnNhdGVkIHNob3J0IGJsb2NrIGxvc3MhXG4iLA0KLSAgICAgICAgICAgICAg
ICAgIGluZi0+dmNwdS0+ZG9tYWluLT5kb21haW5faWQsIGluZi0+dmNwdS0+dmNwdV9pZCk7DQot
ICAgICAgICAgICAgLyp3ZSBoYXZlIChvdmVyLSljb21wZW5zYXRlZCBvdXIgYmxvY2sgcGVuYWx0
eSovDQorICAgICAgICAgICAgLyogV2UgaGF2ZSAob3Zlci0pY29tcGVuc2F0ZWQgb3VyIGJsb2Nr
IHBlbmFsdHkgKi8NCiAgICAgICAgICAgICBpbmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90ID0gMDsN
Ci0gICAgICAgICAgICAvKndlIGRvbid0IHdhbnQgYSBwbGFjZSBvbiB0aGUgcGVuYWx0eSBxdWV1
ZSBhbnltb3JlISovDQorICAgICAgICAgICAgLyogV2UgZG9uJ3Qgd2FudCBhIHBsYWNlIG9uIHRo
ZSBwZW5hbHR5IHF1ZXVlIGFueW1vcmUhICovDQogICAgICAgICAgICAgaW5mLT5zdGF0dXMgJj0g
fkVYVFJBX1dBTlRfUEVOX1E7DQogICAgICAgICAgICAgZ290byBjaGVja19leHRyYV9xdWV1ZXM7
DQogICAgICAgICB9DQogDQotICAgICAgICAvKndlIGhhdmUgdG8gZ28gYWdhaW4gZm9yIGFub3Ro
ZXIgdHJ5IGluIHRoZSBibG9jay1leHRyYXEsDQotICAgICAgICAgIHRoZSBzY29yZSBpcyBub3Qg
dXNlZCBpbmNyZW1hbnRhbGx5IGhlcmUsIGFzIHRoaXMgaXMNCi0gICAgICAgICAgYWxyZWFkeSBk
b25lIGJ5IHJlY2FsY3VsYXRpbmcgdGhlIGJsb2NrX2xvc3QqLw0KKyAgICAgICAgLyoNCisgICAg
ICAgICAqIFdlIGhhdmUgdG8gZ28gYWdhaW4gZm9yIGFub3RoZXIgdHJ5IGluIHRoZSBibG9jay1l
eHRyYXEsDQorICAgICAgICAgKiB0aGUgc2NvcmUgaXMgbm90IHVzZWQgaW5jcmVtYW50YWxseSBo
ZXJlLCBhcyB0aGlzIGlzDQorICAgICAgICAgKiBhbHJlYWR5IGRvbmUgYnkgcmVjYWxjdWxhdGlu
ZyB0aGUgYmxvY2tfbG9zdA0KKyAgICAgICAgICovDQogICAgICAgICBpbmYtPnNjb3JlW0VYVFJB
X1BFTl9RXSA9IChpbmYtPnBlcmlvZCA8PCAxMCkgLw0KICAgICAgICAgICAgIGluZi0+c2hvcnRf
YmxvY2tfbG9zdF90b3Q7DQogICAgICAgICBvbGRzY29yZSA9IDA7DQogICAgIH0NCiAgICAgZWxz
ZQ0KICAgICB7DQotICAgICAgICAvKmRvbWFpbiB3YXMgcnVubmluZyBpbiBMMSBleHRyYXEgPT4g
c2NvcmUgaXMgaW52ZXJzZSBvZg0KLSAgICAgICAgICB1dGlsaXphdGlvbiBhbmQgaXMgdXNlZCBz
b21ld2hhdCBpbmNyZW1lbnRhbCEqLw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIERvbWFpbiB3
YXMgcnVubmluZyBpbiBMMSBleHRyYXEgPT4gc2NvcmUgaXMgaW52ZXJzZSBvZg0KKyAgICAgICAg
ICogdXRpbGl6YXRpb24gYW5kIGlzIHVzZWQgc29tZXdoYXQgaW5jcmVtZW50YWwhDQorICAgICAg
ICAgKi8NCiAgICAgICAgIGlmICggIWluZi0+ZXh0cmF3ZWlnaHQgKQ0KLSAgICAgICAgICAgIC8q
TkI6IHVzZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAgYml0cyovDQorICAgICAgICB7
DQorICAgICAgICAgICAgLyogTkI6IHVzZSBmaXhlZCBwb2ludCBhcml0aG1ldGljIHdpdGggMTAg
Yml0cyAqLw0KICAgICAgICAgICAgIGluZi0+c2NvcmVbRVhUUkFfVVRJTF9RXSA9IChpbmYtPnBl
cmlvZCA8PCAxMCkgLw0KICAgICAgICAgICAgICAgICBpbmYtPnNsaWNlOw0KKyAgICAgICAgfQ0K
ICAgICAgICAgZWxzZQ0KLSAgICAgICAgICAgIC8qY29udmVyc2lvbiBiZXR3ZWVuIHJlYWx0aW1l
IHV0aWxpc2F0aW9uIGFuZCBleHRyYXdpZWdodDoNCi0gICAgICAgICAgICAgIGZ1bGwgKGllIDEw
MCUpIHV0aWxpemF0aW9uIGlzIGVxdWl2YWxlbnQgdG8gMTI4IGV4dHJhd2VpZ2h0Ki8NCisgICAg
ICAgIHsNCisgICAgICAgICAgICAvKg0KKyAgICAgICAgICAgICAqIENvbnZlcnNpb24gYmV0d2Vl
biByZWFsdGltZSB1dGlsaXNhdGlvbiBhbmQgZXh0cmF3aWVnaHQ6DQorICAgICAgICAgICAgICog
ZnVsbCAoaWUgMTAwJSkgdXRpbGl6YXRpb24gaXMgZXF1aXZhbGVudCB0byAxMjggZXh0cmF3ZWln
aHQNCisgICAgICAgICAgICAgKi8NCiAgICAgICAgICAgICBpbmYtPnNjb3JlW0VYVFJBX1VUSUxf
UV0gPSAoMTw8MTcpIC8gaW5mLT5leHRyYXdlaWdodDsNCisgICAgICAgIH0NCiAgICAgfQ0KIA0K
ICBjaGVja19leHRyYV9xdWV1ZXM6DQotICAgIC8qIEFkZGluZyBhIHJ1bm5hYmxlIGRvbWFpbiB0
byB0aGUgcmlnaHQgcXVldWUgYW5kIHJlbW92aW5nIGJsb2NrZWQgb25lcyovDQorICAgIC8qIEFk
ZGluZyBhIHJ1bm5hYmxlIGRvbWFpbiB0byB0aGUgcmlnaHQgcXVldWUgYW5kIHJlbW92aW5nIGJs
b2NrZWQgb25lcyAqLw0KICAgICBpZiAoIHNlZGZfcnVubmFibGUoZCkgKQ0KICAgICB7DQotICAg
ICAgICAvKmFkZCBhY2NvcmRpbmcgdG8gc2NvcmU6IHdlaWdodGVkIHJvdW5kIHJvYmluKi8NCisg
ICAgICAgIC8qIEFkZCBhY2NvcmRpbmcgdG8gc2NvcmU6IHdlaWdodGVkIHJvdW5kIHJvYmluICov
DQogICAgICAgICBpZiAoKChpbmYtPnN0YXR1cyAmIEVYVFJBX0FXQVJFKSAmJiAoaSA9PSBFWFRS
QV9VVElMX1EpKSB8fA0KICAgICAgICAgICAgICgoaW5mLT5zdGF0dXMgJiBFWFRSQV9XQU5UX1BF
Tl9RKSAmJiAoaSA9PSBFWFRSQV9QRU5fUSkpKQ0KICAgICAgICAgICAgIGV4dHJhcV9hZGRfc29y
dF91cGRhdGUoZCwgaSwgb2xkc2NvcmUpOw0KICAgICB9DQogICAgIGVsc2UNCiAgICAgew0KLSAg
ICAgICAgLypyZW1vdmUgdGhpcyBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSB3YWl0cSEqLw0KKyAg
ICAgICAgLyogUmVtb3ZlIHRoaXMgYmxvY2tlZCBkb21haW4gZnJvbSB0aGUgd2FpdHEhICovDQog
ICAgICAgICBfX2RlbF9mcm9tX3F1ZXVlKGQpOw0KLSAgICAgICAgLyptYWtlIHN1cmUgdGhhdCB3
ZSByZW1vdmUgYSBibG9ja2VkIGRvbWFpbiBmcm9tIHRoZSBvdGhlcg0KLSAgICAgICAgICBleHRy
YXEgdG9vKi8NCisgICAgICAgIC8qIE1ha2Ugc3VyZSB0aGF0IHdlIHJlbW92ZSBhIGJsb2NrZWQg
ZG9tYWluIGZyb20gdGhlIG90aGVyDQorICAgICAgICAgKiBleHRyYXEgdG9vLiAqLw0KICAgICAg
ICAgaWYgKCBpID09IEVYVFJBX1BFTl9RICkNCiAgICAgICAgIHsNCiAgICAgICAgICAgICBpZiAo
IGV4dHJhcV9vbihkLCBFWFRSQV9VVElMX1EpICkNCkBAIC03MjksOCArNjgwLDEwIEBAIHN0YXRp
YyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX2V4dHJhX3MNCiANCiAgICAgaWYgKCAhbGlzdF9l
bXB0eShleHRyYXFbRVhUUkFfUEVOX1FdKSApDQogICAgIHsNCi0gICAgICAgIC8qd2Ugc3RpbGwg
aGF2ZSBlbGVtZW50cyBvbiB0aGUgbGV2ZWwgMCBleHRyYXEgDQotICAgICAgICAgID0+IGxldCB0
aG9zZSBydW4gZmlyc3QhKi8NCisgICAgICAgIC8qDQorICAgICAgICAgKiBXZSBzdGlsbCBoYXZl
IGVsZW1lbnRzIG9uIHRoZSBsZXZlbCAwIGV4dHJhcQ0KKyAgICAgICAgICogPT4gbGV0IHRob3Nl
IHJ1biBmaXJzdCENCisgICAgICAgICAqLw0KICAgICAgICAgcnVuaW5mICAgPSBsaXN0X2VudHJ5
KGV4dHJhcVtFWFRSQV9QRU5fUV0tPm5leHQsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbywgZXh0cmFsaXN0W0VYVFJBX1BFTl9RXSk7DQogICAg
ICAgICBydW5pbmYtPnN0YXR1cyB8PSBFWFRSQV9SVU5fUEVOOw0KQEAgLTc0NCw3ICs2OTcsNyBA
QCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2VkZl9kb19leHRyYV9zDQogICAgIHsNCiAgICAg
ICAgIGlmICggIWxpc3RfZW1wdHkoZXh0cmFxW0VYVFJBX1VUSUxfUV0pICkNCiAgICAgICAgIHsN
Ci0gICAgICAgICAgICAvKnVzZSBlbGVtZW50cyBmcm9tIHRoZSBub3JtYWwgZXh0cmFxdWV1ZSov
DQorICAgICAgICAgICAgLyogVXNlIGVsZW1lbnRzIGZyb20gdGhlIG5vcm1hbCBleHRyYXF1ZXVl
ICovDQogICAgICAgICAgICAgcnVuaW5mICAgPSBsaXN0X2VudHJ5KGV4dHJhcVtFWFRSQV9VVElM
X1FdLT5uZXh0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3Qgc2Vk
Zl92Y3B1X2luZm8sDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4dHJhbGlz
dFtFWFRSQV9VVElMX1FdKTsNCkBAIC03OTQsMTEgKzc0NywxMyBAQCBzdGF0aWMgdm9pZCBzZWRm
X2RlaW5pdChjb25zdCBzdHJ1Y3Qgc2NoDQogfQ0KIA0KIA0KLS8qIE1haW4gc2NoZWR1bGluZyBm
dW5jdGlvbg0KLSAgIFJlYXNvbnMgZm9yIGNhbGxpbmcgdGhpcyBmdW5jdGlvbiBhcmU6DQotICAg
LXRpbWVzbGljZSBmb3IgdGhlIGN1cnJlbnQgcGVyaW9kIHVzZWQgdXANCi0gICAtZG9tYWluIG9u
IHdhaXRxdWV1ZSBoYXMgc3RhcnRlZCBpdCdzIHBlcmlvZA0KLSAgIC1hbmQgdmFyaW91cyBvdGhl
cnMgOykgaW4gZ2VuZXJhbDogZGV0ZXJtaW5lIHdoaWNoIGRvbWFpbiB0byBydW4gbmV4dCovDQor
LyoNCisgKiBNYWluIHNjaGVkdWxpbmcgZnVuY3Rpb24NCisgKiBSZWFzb25zIGZvciBjYWxsaW5n
IHRoaXMgZnVuY3Rpb24gYXJlOg0KKyAqIC10aW1lc2xpY2UgZm9yIHRoZSBjdXJyZW50IHBlcmlv
ZCB1c2VkIHVwDQorICogLWRvbWFpbiBvbiB3YWl0cXVldWUgaGFzIHN0YXJ0ZWQgaXQncyBwZXJp
b2QNCisgKiAtYW5kIHZhcmlvdXMgb3RoZXJzIDspIGluIGdlbmVyYWw6IGRldGVybWluZSB3aGlj
aCBkb21haW4gdG8gcnVuIG5leHQNCisgKi8NCiBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2Vk
Zl9kb19zY2hlZHVsZSgNCiAgICAgY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBzX3RpbWVf
dCBub3csIGJvb2xfdCB0YXNrbGV0X3dvcmtfc2NoZWR1bGVkKQ0KIHsNCkBAIC04MTEsMTMgKzc2
NiwxNSBAQCBzdGF0aWMgc3RydWN0IHRhc2tfc2xpY2Ugc2VkZl9kb19zY2hlZHVsDQogICAgIHN0
cnVjdCBzZWRmX3ZjcHVfaW5mbyAqcnVuaW5mLCAqd2FpdGluZjsNCiAgICAgc3RydWN0IHRhc2tf
c2xpY2UgICAgICByZXQ7DQogDQotICAgIC8qaWRsZSB0YXNrcyBkb24ndCBuZWVkIGFueSBvZiB0
aGUgZm9sbG93aW5nIHN0dWYqLw0KKyAgICAvKiBJZGxlIHRhc2tzIGRvbid0IG5lZWQgYW55IG9m
IHRoZSBmb2xsb3dpbmcgc3R1ZiAqLw0KICAgICBpZiAoIGlzX2lkbGVfdmNwdShjdXJyZW50KSAp
DQogICAgICAgICBnb3RvIGNoZWNrX3dhaXRxOw0KLSANCi0gICAgLyogY3JlYXRlIGxvY2FsIHN0
YXRlIG9mIHRoZSBzdGF0dXMgb2YgdGhlIGRvbWFpbiwgaW4gb3JkZXIgdG8gYXZvaWQNCi0gICAg
ICAgaW5jb25zaXN0ZW50IHN0YXRlIGR1cmluZyBzY2hlZHVsaW5nIGRlY2lzaW9ucywgYmVjYXVz
ZSBkYXRhIGZvcg0KLSAgICAgICB2Y3B1X3J1bm5hYmxlIGlzIG5vdCBwcm90ZWN0ZWQgYnkgdGhl
IHNjaGVkdWxpbmcgbG9jayEqLw0KKw0KKyAgICAvKg0KKyAgICAgKiBDcmVhdGUgbG9jYWwgc3Rh
dGUgb2YgdGhlIHN0YXR1cyBvZiB0aGUgZG9tYWluLCBpbiBvcmRlciB0byBhdm9pZA0KKyAgICAg
KiBpbmNvbnNpc3RlbnQgc3RhdGUgZHVyaW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLCBiZWNhdXNl
IGRhdGEgZm9yDQorICAgICAqIHZjcHVfcnVubmFibGUgaXMgbm90IHByb3RlY3RlZCBieSB0aGUg
c2NoZWR1bGluZyBsb2NrIQ0KKyAgICAgKi8NCiAgICAgaWYgKCAhdmNwdV9ydW5uYWJsZShjdXJy
ZW50KSApDQogICAgICAgICBpbmYtPnN0YXR1cyB8PSBTRURGX0FTTEVFUDsNCiAgDQpAQCAtODI2
LDcgKzc4Myw3IEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAN
CiAgICAgaWYgKCB1bmxpa2VseShleHRyYV9ydW5zKGluZikpICkNCiAgICAgew0KLSAgICAgICAg
LypzcGVjaWFsIHRyZWF0bWVudCBvZiBkb21haW5zIHJ1bm5pbmcgaW4gZXh0cmEgdGltZSovDQor
ICAgICAgICAvKiBTcGVjaWFsIHRyZWF0bWVudCBvZiBkb21haW5zIHJ1bm5pbmcgaW4gZXh0cmEg
dGltZSAqLw0KICAgICAgICAgZGVzY2hlZF9leHRyYV9kb20obm93LCBjdXJyZW50KTsNCiAgICAg
fQ0KICAgICBlbHNlIA0KQEAgLTgzNiwxMCArNzkzLDEyIEBAIHN0YXRpYyBzdHJ1Y3QgdGFza19z
bGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgY2hlY2tfd2FpdHE6DQogICAgIHVwZGF0ZV9xdWV1ZXMo
bm93LCBydW5xLCB3YWl0cSk7DQogDQotICAgIC8qbm93IHNpbXBseSBwaWNrIHRoZSBmaXJzdCBk
b21haW4gZnJvbSB0aGUgcnVucXVldWUsIHdoaWNoIGhhcyB0aGUNCi0gICAgICBlYXJsaWVzdCBk
ZWFkbGluZSwgYmVjYXVzZSB0aGUgbGlzdCBpcyBzb3J0ZWQqLw0KLSANCi0gICAgLyogVGFza2xl
dCB3b3JrICh3aGljaCBydW5zIGluIGlkbGUgVkNQVSBjb250ZXh0KSBvdmVycmlkZXMgYWxsIGVs
c2UuICovDQorICAgIC8qDQorICAgICAqIE5vdyBzaW1wbHkgcGljayB0aGUgZmlyc3QgZG9tYWlu
IGZyb20gdGhlIHJ1bnF1ZXVlLCB3aGljaCBoYXMgdGhlDQorICAgICAqIGVhcmxpZXN0IGRlYWRs
aW5lLCBiZWNhdXNlIHRoZSBsaXN0IGlzIHNvcnRlZA0KKyAgICAgKg0KKyAgICAgKiBUYXNrbGV0
IHdvcmsgKHdoaWNoIHJ1bnMgaW4gaWRsZSBWQ1BVIGNvbnRleHQpIG92ZXJyaWRlcyBhbGwgZWxz
ZS4NCisgICAgICovDQogICAgIGlmICggdGFza2xldF93b3JrX3NjaGVkdWxlZCB8fA0KICAgICAg
ICAgIChsaXN0X2VtcHR5KHJ1bnEpICYmIGxpc3RfZW1wdHkod2FpdHEpKSB8fA0KICAgICAgICAg
IHVubGlrZWx5KCFjcHVtYXNrX3Rlc3RfY3B1KGNwdSwgU0VERl9DUFVPTkxJTkUocGVyX2NwdShj
cHVwb29sLCBjcHUpKSkpICkNCkBAIC04NTUsOSArODE0LDExIEBAIHN0YXRpYyBzdHJ1Y3QgdGFz
a19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgICAgIHsNCiAgICAgICAgICAgICB3YWl0aW5m
ICA9IGxpc3RfZW50cnkod2FpdHEtPm5leHQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHN0cnVjdCBzZWRmX3ZjcHVfaW5mbyxsaXN0KTsNCi0gICAgICAgICAgICAvKnJlcnVu
IHNjaGVkdWxlciwgd2hlbiBzY2hlZHVsZWQgZG9tYWluIHJlYWNoZXMgaXQncw0KLSAgICAgICAg
ICAgICAgZW5kIG9mIHNsaWNlIG9yIHRoZSBmaXJzdCBkb21haW4gZnJvbSB0aGUgd2FpdHF1ZXVl
DQotICAgICAgICAgICAgICBnZXRzIHJlYWR5Ki8NCisgICAgICAgICAgICAvKg0KKyAgICAgICAg
ICAgICAqIFJlcnVuIHNjaGVkdWxlciwgd2hlbiBzY2hlZHVsZWQgZG9tYWluIHJlYWNoZXMgaXQn
cw0KKyAgICAgICAgICAgICAqIGVuZCBvZiBzbGljZSBvciB0aGUgZmlyc3QgZG9tYWluIGZyb20g
dGhlIHdhaXRxdWV1ZQ0KKyAgICAgICAgICAgICAqIGdldHMgcmVhZHkuDQorICAgICAgICAgICAg
ICovDQogICAgICAgICAgICAgcmV0LnRpbWUgPSBNSU4obm93ICsgcnVuaW5mLT5zbGljZSAtIHJ1
bmluZi0+Y3B1dGltZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQRVJJT0RfQkVHSU4o
d2FpdGluZikpIC0gbm93Ow0KICAgICAgICAgfQ0KQEAgLTg2OSwxNCArODMwLDE4IEBAIHN0YXRp
YyBzdHJ1Y3QgdGFza19zbGljZSBzZWRmX2RvX3NjaGVkdWwNCiAgICAgZWxzZQ0KICAgICB7DQog
ICAgICAgICB3YWl0aW5mICA9IGxpc3RfZW50cnkod2FpdHEtPm5leHQsc3RydWN0IHNlZGZfdmNw
dV9pbmZvLCBsaXN0KTsNCi0gICAgICAgIC8qd2UgY291bGQgbm90IGZpbmQgYW55IHN1aXRhYmxl
IGRvbWFpbiANCi0gICAgICAgICAgPT4gbG9vayBmb3IgZG9tYWlucyB0aGF0IGFyZSBhd2FyZSBv
ZiBleHRyYXRpbWUqLw0KKyAgICAgICAgLyoNCisgICAgICAgICAqIFdlIGNvdWxkIG5vdCBmaW5k
IGFueSBzdWl0YWJsZSBkb21haW4gDQorICAgICAgICAgKiA9PiBsb29rIGZvciBkb21haW5zIHRo
YXQgYXJlIGF3YXJlIG9mIGV4dHJhdGltZQ0KKyAgICAgICAgICovDQogICAgICAgICByZXQgPSBz
ZWRmX2RvX2V4dHJhX3NjaGVkdWxlKG5vdywgUEVSSU9EX0JFR0lOKHdhaXRpbmYpLA0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHRyYXEsIGNwdSk7DQogICAgIH0NCiAN
Ci0gICAgLypUT0RPOiBEbyBzb21ldGhpbmcgVVNFRlVMIHdoZW4gdGhpcyBoYXBwZW5zIGFuZCBm
aW5kIG91dCwgd2h5IGl0DQotICAgICAgc3RpbGwgY2FuIGhhcHBlbiEhISovDQorICAgIC8qDQor
ICAgICAqIFRPRE86IERvIHNvbWV0aGluZyBVU0VGVUwgd2hlbiB0aGlzIGhhcHBlbnMgYW5kIGZp
bmQgb3V0LCB3aHkgaXQNCisgICAgICogc3RpbGwgY2FuIGhhcHBlbiEhIQ0KKyAgICAgKi8NCiAg
ICAgaWYgKCByZXQudGltZSA8IDApDQogICAgIHsNCiAgICAgICAgIHByaW50aygiT3VjaCEgV2Ug
YXJlIHNlcmlvdXNseSBCRUhJTkQgc2NoZWR1bGUhICUiUFJJaTY0IlxuIiwNCkBAIC04OTYsOSAr
ODYxLDYgQEAgc3RhdGljIHN0cnVjdCB0YXNrX3NsaWNlIHNlZGZfZG9fc2NoZWR1bA0KIA0KIHN0
YXRpYyB2b2lkIHNlZGZfc2xlZXAoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzLCBzdHJ1Y3Qg
dmNwdSAqZCkNCiB7DQotICAgIFBSSU5UKDIsInNlZGZfc2xlZXAgd2FzIGNhbGxlZCwgZG9tYWlu
LWlkICVpLiVpXG4iLA0KLSAgICAgICAgICBkLT5kb21haW4tPmRvbWFpbl9pZCwgZC0+dmNwdV9p
ZCk7DQotIA0KICAgICBpZiAoIGlzX2lkbGVfdmNwdShkKSApDQogICAgICAgICByZXR1cm47DQog
DQpAQCAtOTIwLDcgKzg4Miw4IEBAIHN0YXRpYyB2b2lkIHNlZGZfc2xlZXAoY29uc3Qgc3RydWN0
IHNjaGUNCiB9DQogDQogDQotLyogVGhpcyBmdW5jdGlvbiB3YWtlcyB1cCBhIGRvbWFpbiwgaS5l
LiBtb3ZlcyB0aGVtIGludG8gdGhlIHdhaXRxdWV1ZQ0KKy8qDQorICogVGhpcyBmdW5jdGlvbiB3
YWtlcyB1cCBhIGRvbWFpbiwgaS5lLiBtb3ZlcyB0aGVtIGludG8gdGhlIHdhaXRxdWV1ZQ0KICAq
IHRoaW5ncyB0byBtZW50aW9uIGFyZTogYWRtaXNzaW9uIGNvbnRyb2wgaXMgdGFraW5nIHBsYWNl
IG5vd2hlcmUgYXQNCiAgKiB0aGUgbW9tZW50LCBzbyB3ZSBjYW4ndCBiZSBzdXJlLCB3aGV0aGVy
IGl0IGlzIHNhZmUgdG8gd2FrZSB0aGUgZG9tYWluDQogICogdXAgYXQgYWxsLiBBbnl3YXksIGV2
ZW4gaWYgaXQgaXMgc2FmZSAodG90YWwgY3B1IHVzYWdlIDw9MTAwJSkgdGhlcmUgYXJlDQpAQCAt
OTk0LDI3ICs5NTcsMzEgQEAgc3RhdGljIHZvaWQgc2VkZl9zbGVlcChjb25zdCBzdHJ1Y3Qgc2No
ZQ0KIHN0YXRpYyB2b2lkIHVuYmxvY2tfc2hvcnRfZXh0cmFfc3VwcG9ydCgNCiAgICAgc3RydWN0
IHNlZGZfdmNwdV9pbmZvKiBpbmYsIHNfdGltZV90IG5vdykNCiB7DQotICAgIC8qdGhpcyB1bmJs
b2NraW5nIHNjaGVtZSB0cmllcyB0byBzdXBwb3J0IHRoZSBkb21haW4sIGJ5IGFzc2lnbmluZyBp
dA0KLSAgICBhIHByaW9yaXR5IGluIGV4dHJhdGltZSBkaXN0cmlidXRpb24gYWNjb3JkaW5nIHRv
IHRoZSBsb3NzIG9mIHRpbWUNCi0gICAgaW4gdGhpcyBzbGljZSBkdWUgdG8gYmxvY2tpbmcqLw0K
KyAgICAvKg0KKyAgICAgKiBUaGlzIHVuYmxvY2tpbmcgc2NoZW1lIHRyaWVzIHRvIHN1cHBvcnQg
dGhlIGRvbWFpbiwgYnkgYXNzaWduaW5nIGl0DQorICAgICAqIGEgcHJpb3JpdHkgaW4gZXh0cmF0
aW1lIGRpc3RyaWJ1dGlvbiBhY2NvcmRpbmcgdG8gdGhlIGxvc3Mgb2YgdGltZQ0KKyAgICAgKiBp
biB0aGlzIHNsaWNlIGR1ZSB0byBibG9ja2luZw0KKyAgICAgKi8NCiAgICAgc190aW1lX3QgcGVu
Ow0KICANCi0gICAgLypubyBtb3JlIHJlYWx0aW1lIGV4ZWN1dGlvbiBpbiB0aGlzIHBlcmlvZCEq
Lw0KKyAgICAvKiBObyBtb3JlIHJlYWx0aW1lIGV4ZWN1dGlvbiBpbiB0aGlzIHBlcmlvZCEgKi8N
CiAgICAgaW5mLT5kZWFkbF9hYnMgKz0gaW5mLT5wZXJpb2Q7DQogICAgIGlmICggbGlrZWx5KGlu
Zi0+YmxvY2tfYWJzKSApDQogICAgIHsNCi0gICAgICAgIC8vdHJlYXQgYmxvY2tlZCB0aW1lIGFz
IGNvbnN1bWVkIGJ5IHRoZSBkb21haW4qLw0KKyAgICAgICAgLyogVHJlYXQgYmxvY2tlZCB0aW1l
IGFzIGNvbnN1bWVkIGJ5IHRoZSBkb21haW4gKi8NCiAgICAgICAgIC8qaW5mLT5jcHV0aW1lICs9
IG5vdyAtIGluZi0+YmxvY2tfYWJzOyovDQotICAgICAgICAvKnBlbmFsdHkgaXMgdGltZSB0aGUg
ZG9tYWluIHdvdWxkIGhhdmUNCi0gICAgICAgICAgaGFkIGlmIGl0IGNvbnRpbnVlZCB0byBydW4g
Ki8NCisgICAgICAgIC8qDQorICAgICAgICAgKiBQZW5hbHR5IGlzIHRpbWUgdGhlIGRvbWFpbiB3
b3VsZCBoYXZlDQorICAgICAgICAgKiBoYWQgaWYgaXQgY29udGludWVkIHRvIHJ1bi4NCisgICAg
ICAgICAqLw0KICAgICAgICAgcGVuID0gKGluZi0+c2xpY2UgLSBpbmYtPmNwdXRpbWUpOw0KICAg
ICAgICAgaWYgKCBwZW4gPCAwICkNCiAgICAgICAgICAgICBwZW4gPSAwOw0KLSAgICAgICAgLyph
Y2N1bXVsYXRlIGFsbCBwZW5hbHRpZXMgb3ZlciB0aGUgcGVyaW9kcyovDQorICAgICAgICAvKiBB
Y2N1bXVsYXRlIGFsbCBwZW5hbHRpZXMgb3ZlciB0aGUgcGVyaW9kcyAqLw0KICAgICAgICAgLypp
bmYtPnNob3J0X2Jsb2NrX2xvc3RfdG90ICs9IHBlbjsqLw0KLSAgICAgICAgLypzZXQgcGVuYWx0
eSB0byB0aGUgY3VycmVudCB2YWx1ZSovDQorICAgICAgICAvKiBTZXQgcGVuYWx0eSB0byB0aGUg
Y3VycmVudCB2YWx1ZSAqLw0KICAgICAgICAgaW5mLT5zaG9ydF9ibG9ja19sb3N0X3RvdCA9IHBl
bjsNCi0gICAgICAgIC8qbm90IHN1cmUgd2hpY2ggb25lIGlzIGJldHRlci4uIGJ1dCBzZWVtcyB0
byB3b3JrIHdlbGwuLi4qLw0KKyAgICAgICAgLyogTm90IHN1cmUgd2hpY2ggb25lIGlzIGJldHRl
ci4uIGJ1dCBzZWVtcyB0byB3b3JrIHdlbGwuLi4gKi8NCiAgIA0KICAgICAgICAgaWYgKCBpbmYt
PnNob3J0X2Jsb2NrX2xvc3RfdG90ICkNCiAgICAgICAgIHsNCkBAIC0xMDI0LDI4ICs5OTEsMzEg
QEAgc3RhdGljIHZvaWQgdW5ibG9ja19zaG9ydF9leHRyYV9zdXBwb3J0KA0KICAgICAgICAgICAg
IGluZi0+cGVuX2V4dHJhX2Jsb2NrcysrOw0KICNlbmRpZg0KICAgICAgICAgICAgIGlmICggZXh0
cmFxX29uKGluZi0+dmNwdSwgRVhUUkFfUEVOX1EpICkNCi0gICAgICAgICAgICAgICAgLypyZW1v
dmUgZG9tYWluIGZvciBwb3NzaWJsZSByZXNvcnRpbmchKi8NCisgICAgICAgICAgICAgICAgLyog
UmVtb3ZlIGRvbWFpbiBmb3IgcG9zc2libGUgcmVzb3J0aW5nISAqLw0KICAgICAgICAgICAgICAg
ICBleHRyYXFfZGVsKGluZi0+dmNwdSwgRVhUUkFfUEVOX1EpOw0KICAgICAgICAgICAgIGVsc2UN
Ci0gICAgICAgICAgICAgICAgLypyZW1lbWJlciB0aGF0IHdlIHdhbnQgdG8gYmUgb24gdGhlIHBl
bmFsdHkgcQ0KLSAgICAgICAgICAgICAgICAgIHNvIHRoYXQgd2UgY2FuIGNvbnRpbnVlIHdoZW4g
d2UgKHVuLSlibG9jaw0KLSAgICAgICAgICAgICAgICAgIGluIHBlbmFsdHktZXh0cmF0aW1lKi8N
CisgICAgICAgICAgICAgICAgLyoNCisgICAgICAgICAgICAgICAgICogUmVtZW1iZXIgdGhhdCB3
ZSB3YW50IHRvIGJlIG9uIHRoZSBwZW5hbHR5IHENCisgICAgICAgICAgICAgICAgICogc28gdGhh
dCB3ZSBjYW4gY29udGludWUgd2hlbiB3ZSAodW4tKWJsb2NrDQorICAgICAgICAgICAgICAgICAq
IGluIHBlbmFsdHktZXh0cmF0aW1lDQorICAgICAgICAgICAgICAgICAqLw0KICAgICAgICAgICAg
ICAgICBpbmYtPnN0YXR1cyB8PSBFWFRSQV9XQU5UX1BFTl9ROw0KICAgIA0KLSAgICAgICAgICAg
IC8qKHJlLSlhZGQgZG9tYWluIHRvIHRoZSBwZW5hbHR5IGV4dHJhcSovDQorICAgICAgICAgICAg
LyogKHJlLSlhZGQgZG9tYWluIHRvIHRoZSBwZW5hbHR5IGV4dHJhcSAqLw0KICAgICAgICAgICAg
IGV4dHJhcV9hZGRfc29ydF91cGRhdGUoaW5mLT52Y3B1LCBFWFRSQV9QRU5fUSwgMCk7DQogICAg
ICAgICB9DQogICAgIH0NCiANCi0gICAgLypnaXZlIGl0IGEgZnJlc2ggc2xpY2UgaW4gdGhlIG5l
eHQgcGVyaW9kISovDQorICAgIC8qIEdpdmUgaXQgYSBmcmVzaCBzbGljZSBpbiB0aGUgbmV4dCBw
ZXJpb2QhICovDQogICAgIGluZi0+Y3B1dGltZSA9IDA7DQogfQ0KIA0KIA0KIHN0YXRpYyB2b2lk
IHVuYmxvY2tfbG9uZ19jb25zX2Ioc3RydWN0IHNlZGZfdmNwdV9pbmZvKiBpbmYsc190aW1lX3Qg
bm93KQ0KIHsNCi0gICAgLypDb25zZXJ2YXRpdmUgMmIqLw0KLSAgICAvKlRyZWF0IHRoZSB1bmJs
b2NraW5nIHRpbWUgYXMgYSBzdGFydCBvZiBhIG5ldyBwZXJpb2QgKi8NCisgICAgLyogQ29uc2Vy
dmF0aXZlIDJiICovDQorDQorICAgIC8qIFRyZWF0IHRoZSB1bmJsb2NraW5nIHRpbWUgYXMgYSBz
dGFydCBvZiBhIG5ldyBwZXJpb2QgKi8NCiAgICAgaW5mLT5kZWFkbF9hYnMgPSBub3cgKyBpbmYt
PnBlcmlvZDsNCiAgICAgaW5mLT5jcHV0aW1lID0gMDsNCiB9DQpAQCAtMTA2OCwxNSArMTAzOCwx
NyBAQCBzdGF0aWMgaW5saW5lIGludCBnZXRfcnVuX3R5cGUoc3RydWN0IHZjDQogfQ0KIA0KIA0K
LS8qQ29tcGFyZXMgdHdvIGRvbWFpbnMgaW4gdGhlIHJlbGF0aW9uIG9mIHdoZXRoZXIgdGhlIG9u
ZSBpcyBhbGxvd2VkIHRvDQotICBpbnRlcnJ1cHQgdGhlIG90aGVycyBleGVjdXRpb24uDQotICBJ
dCByZXR1cm5zIHRydWUgKCE9MCkgaWYgYSBzd2l0Y2ggdG8gdGhlIG90aGVyIGRvbWFpbiBpcyBn
b29kLg0KLSAgQ3VycmVudCBQcmlvcml0eSBzY2hlbWUgaXMgYXMgZm9sbG93czoNCi0gICBFREYg
PiBMMCAocGVuYWx0eSBiYXNlZCkgZXh0cmEtdGltZSA+IA0KLSAgIEwxICh1dGlsaXphdGlvbikg
ZXh0cmEtdGltZSA+IGlkbGUtZG9tYWluDQotICBJbiB0aGUgc2FtZSBjbGFzcyBwcmlvcml0aWVz
IGFyZSBhc3NpZ25lZCBhcyBmb2xsb3dpbmc6DQotICAgRURGOiBlYXJseSBkZWFkbGluZSA+IGxh
dGUgZGVhZGxpbmUNCi0gICBMMCBleHRyYS10aW1lOiBsb3dlciBzY29yZSA+IGhpZ2hlciBzY29y
ZSovDQorLyoNCisgKiBDb21wYXJlcyB0d28gZG9tYWlucyBpbiB0aGUgcmVsYXRpb24gb2Ygd2hl
dGhlciB0aGUgb25lIGlzIGFsbG93ZWQgdG8NCisgKiBpbnRlcnJ1cHQgdGhlIG90aGVycyBleGVj
dXRpb24uDQorICogSXQgcmV0dXJucyB0cnVlICghPTApIGlmIGEgc3dpdGNoIHRvIHRoZSBvdGhl
ciBkb21haW4gaXMgZ29vZC4NCisgKiBDdXJyZW50IFByaW9yaXR5IHNjaGVtZSBpcyBhcyBmb2xs
b3dzOg0KKyAqICBFREYgPiBMMCAocGVuYWx0eSBiYXNlZCkgZXh0cmEtdGltZSA+IA0KKyAqICBM
MSAodXRpbGl6YXRpb24pIGV4dHJhLXRpbWUgPiBpZGxlLWRvbWFpbg0KKyAqIEluIHRoZSBzYW1l
IGNsYXNzIHByaW9yaXRpZXMgYXJlIGFzc2lnbmVkIGFzIGZvbGxvd2luZzoNCisgKiAgRURGOiBl
YXJseSBkZWFkbGluZSA+IGxhdGUgZGVhZGxpbmUNCisgKiAgTDAgZXh0cmEtdGltZTogbG93ZXIg
c2NvcmUgPiBoaWdoZXIgc2NvcmUNCisgKi8NCiBzdGF0aWMgaW5saW5lIGludCBzaG91bGRfc3dp
dGNoKHN0cnVjdCB2Y3B1ICpjdXIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBz
dHJ1Y3QgdmNwdSAqb3RoZXIsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzX3Rp
bWVfdCBub3cpDQpAQCAtMTA4NSwyNiArMTA1NywyNSBAQCBzdGF0aWMgaW5saW5lIGludCBzaG91
bGRfc3dpdGNoKHN0cnVjdCB2DQogICAgIGN1cl9pbmYgICA9IEVET01fSU5GTyhjdXIpOw0KICAg
ICBvdGhlcl9pbmYgPSBFRE9NX0lORk8ob3RoZXIpOw0KICANCi0gICAgLyogQ2hlY2sgd2hldGhl
ciB3ZSBuZWVkIHRvIG1ha2UgYW4gZWFybGllciBzY2hlZHVsaW5nIGRlY2lzaW9uLiAqLw0KKyAg
ICAvKiBDaGVjayB3aGV0aGVyIHdlIG5lZWQgdG8gbWFrZSBhbiBlYXJsaWVyIHNjaGVkdWxpbmcg
ZGVjaXNpb24gKi8NCiAgICAgaWYgKCBQRVJJT0RfQkVHSU4ob3RoZXJfaW5mKSA8IA0KICAgICAg
ICAgIENQVV9JTkZPKG90aGVyLT5wcm9jZXNzb3IpLT5jdXJyZW50X3NsaWNlX2V4cGlyZXMgKQ0K
ICAgICAgICAgcmV0dXJuIDE7DQogDQotICAgIC8qIE5vIHRpbWluZy1iYXNlZCBzd2l0Y2hlcyBu
ZWVkIHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBoZXJlLiAqLw0KKyAgICAvKiBObyB0aW1pbmct
YmFzZWQgc3dpdGNoZXMgbmVlZCB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgaGVyZSAqLw0KICAg
ICBzd2l0Y2ggKCBnZXRfcnVuX3R5cGUoY3VyKSApDQogICAgIHsNCiAgICAgY2FzZSBET01BSU5f
RURGOg0KLSAgICAgICAgLyogRG8gbm90IGludGVycnVwdCBhIHJ1bm5pbmcgRURGIGRvbWFpbi4g
Ki8NCisgICAgICAgIC8qIERvIG5vdCBpbnRlcnJ1cHQgYSBydW5uaW5nIEVERiBkb21haW4gKi8N
CiAgICAgICAgIHJldHVybiAwOw0KICAgICBjYXNlIERPTUFJTl9FWFRSQV9QRU46DQotICAgICAg
ICAvKiBDaGVjayB3aGV0aGVyIHdlIGFsc28gd2FudCB0aGUgTDAgZXgtcSB3aXRoIGxvd2VyIHNj
b3JlLiAqLw0KKyAgICAgICAgLyogQ2hlY2sgd2hldGhlciB3ZSBhbHNvIHdhbnQgdGhlIEwwIGV4
LXEgd2l0aCBsb3dlciBzY29yZSAqLw0KICAgICAgICAgcmV0dXJuICgob3RoZXJfaW5mLT5zdGF0
dXMgJiBFWFRSQV9XQU5UX1BFTl9RKSAmJg0KICAgICAgICAgICAgICAgICAob3RoZXJfaW5mLT5z
Y29yZVtFWFRSQV9QRU5fUV0gPCANCiAgICAgICAgICAgICAgICAgIGN1cl9pbmYtPnNjb3JlW0VY
VFJBX1BFTl9RXSkpOw0KICAgICBjYXNlIERPTUFJTl9FWFRSQV9VVElMOg0KICAgICAgICAgLyog
Q2hlY2sgd2hldGhlciB3ZSB3YW50IHRoZSBMMCBleHRyYXEuIERvbid0DQotICAgICAgICAgKiBz
d2l0Y2ggaWYgYm90aCBkb21haW5zIHdhbnQgTDEgZXh0cmFxLg0KLSAgICAgICAgICovDQorICAg
ICAgICAgKiBzd2l0Y2ggaWYgYm90aCBkb21haW5zIHdhbnQgTDEgZXh0cmFxLiAqLw0KICAgICAg
ICAgcmV0dXJuICEhKG90aGVyX2luZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9QRU5fUSk7DQogICAg
IGNhc2UgRE9NQUlOX0lETEU6DQogICAgICAgICByZXR1cm4gMTsNCkBAIC0xMTE4LDE4ICsxMDg5
LDExIEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAgc190
aW1lX3QgICAgICAgICAgICAgIG5vdyA9IE5PVygpOw0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2lu
Zm8qIGluZiA9IEVET01fSU5GTyhkKTsNCiANCi0gICAgUFJJTlQoMywgInNlZGZfd2FrZSB3YXMg
Y2FsbGVkLCBkb21haW4taWQgJWkuJWlcbiIsZC0+ZG9tYWluLT5kb21haW5faWQsDQotICAgICAg
ICAgIGQtPnZjcHVfaWQpOw0KLQ0KICAgICBpZiAoIHVubGlrZWx5KGlzX2lkbGVfdmNwdShkKSkg
KQ0KICAgICAgICAgcmV0dXJuOw0KICAgIA0KICAgICBpZiAoIHVubGlrZWx5KF9fdGFza19vbl9x
dWV1ZShkKSkgKQ0KLSAgICB7DQotICAgICAgICBQUklOVCgzLCJcdGRvbWFpbiAlaS4laSBpcyBh
bHJlYWR5IGluIHNvbWUgcXVldWVcbiIsDQotICAgICAgICAgICAgICBkLT5kb21haW4tPmRvbWFp
bl9pZCwgZC0+dmNwdV9pZCk7DQogICAgICAgICByZXR1cm47DQotICAgIH0NCiANCiAgICAgQVNT
RVJUKCFzZWRmX3J1bm5hYmxlKGQpKTsNCiAgICAgaW5mLT5zdGF0dXMgJj0gflNFREZfQVNMRUVQ
Ow0KQEAgLTExMzgsMjggKzExMDIsMjUgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0
cnVjdCBzY2hlZA0KICANCiAgICAgaWYgKCB1bmxpa2VseShpbmYtPmRlYWRsX2FicyA9PSAwKSAp
DQogICAgIHsNCi0gICAgICAgIC8qaW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVhZGxpbmUqLw0KKyAg
ICAgICAgLyogSW5pdGlhbCBzZXR1cCBvZiB0aGUgZGVhZGxpbmUgKi8NCiAgICAgICAgIGluZi0+
ZGVhZGxfYWJzID0gbm93ICsgaW5mLT5zbGljZTsNCiAgICAgfQ0KICAgDQotICAgIFBSSU5UKDMs
ICJ3YWtpbmcgdXAgZG9tYWluICVpLiVpIChkZWFkbD0gJSJQUkl1NjQiIHBlcmlvZD0gJSJQUkl1
NjQNCi0gICAgICAgICAgIm5vdz0gJSJQUkl1NjQiKVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWlu
LT5kb21haW5faWQsIGQtPnZjcHVfaWQsIGluZi0+ZGVhZGxfYWJzLCBpbmYtPnBlcmlvZCwgbm93
KTsNCi0NCiAjaWZkZWYgU0VERl9TVEFUUyANCiAgICAgaW5mLT5ibG9ja190b3QrKzsNCiAjZW5k
aWYNCiANCiAgICAgaWYgKCB1bmxpa2VseShub3cgPCBQRVJJT0RfQkVHSU4oaW5mKSkgKQ0KICAg
ICB7DQotICAgICAgICBQUklOVCg0LCJleHRyYXRpbWUgdW5ibG9ja1xuIik7DQotICAgICAgICAv
KiB1bmJsb2NraW5nIGluIGV4dHJhLXRpbWUhICovDQorICAgICAgICAvKiBVbmJsb2NraW5nIGlu
IGV4dHJhLXRpbWUhICovDQogICAgICAgICBpZiAoIGluZi0+c3RhdHVzICYgRVhUUkFfV0FOVF9Q
RU5fUSApDQogICAgICAgICB7DQotICAgICAgICAgICAgLyp3ZSBoYXZlIGEgZG9tYWluIHRoYXQg
d2FudHMgY29tcGVuc2F0aW9uDQotICAgICAgICAgICAgICBmb3IgYmxvY2sgcGVuYWx0eSBhbmQg
ZGlkIGp1c3QgYmxvY2sgaW4NCi0gICAgICAgICAgICAgIGl0cyBjb21wZW5zYXRpb24gdGltZS4g
R2l2ZSBpdCBhbm90aGVyDQotICAgICAgICAgICAgICBjaGFuY2UhKi8NCisgICAgICAgICAgICAv
Kg0KKyAgICAgICAgICAgICAqIFdlIGhhdmUgYSBkb21haW4gdGhhdCB3YW50cyBjb21wZW5zYXRp
b24NCisgICAgICAgICAgICAgKiBmb3IgYmxvY2sgcGVuYWx0eSBhbmQgZGlkIGp1c3QgYmxvY2sg
aW4NCisgICAgICAgICAgICAgKiBpdHMgY29tcGVuc2F0aW9uIHRpbWUuIEdpdmUgaXQgYW5vdGhl
cg0KKyAgICAgICAgICAgICAqIGNoYW5jZSENCisgICAgICAgICAgICAgKi8NCiAgICAgICAgICAg
ICBleHRyYXFfYWRkX3NvcnRfdXBkYXRlKGQsIEVYVFJBX1BFTl9RLCAwKTsNCiAgICAgICAgIH0N
CiAgICAgICAgIGV4dHJhcV9jaGVja19hZGRfdW5ibG9ja2VkKGQsIDApOw0KQEAgLTExNjgsOCAr
MTEyOSw3IEBAIHN0YXRpYyB2b2lkIHNlZGZfd2FrZShjb25zdCBzdHJ1Y3Qgc2NoZWQNCiAgICAg
eyAgDQogICAgICAgICBpZiAoIG5vdyA8IGluZi0+ZGVhZGxfYWJzICkNCiAgICAgICAgIHsNCi0g
ICAgICAgICAgICBQUklOVCg0LCJzaG9ydCB1bmJsb2NraW5nXG4iKTsNCi0gICAgICAgICAgICAv
KnNob3J0IGJsb2NraW5nKi8NCisgICAgICAgICAgICAvKiBTaG9ydCBibG9ja2luZyAqLw0KICNp
ZmRlZiBTRURGX1NUQVRTDQogICAgICAgICAgICAgaW5mLT5zaG9ydF9ibG9ja190b3QrKzsNCiAj
ZW5kaWYNCkBAIC0xMTc5LDggKzExMzksNyBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qg
c3RydWN0IHNjaGVkDQogICAgICAgICB9DQogICAgICAgICBlbHNlDQogICAgICAgICB7DQotICAg
ICAgICAgICAgUFJJTlQoNCwibG9uZyB1bmJsb2NraW5nXG4iKTsNCi0gICAgICAgICAgICAvKmxv
bmcgdW5ibG9ja2luZyovDQorICAgICAgICAgICAgLyogTG9uZyB1bmJsb2NraW5nICovDQogI2lm
ZGVmIFNFREZfU1RBVFMNCiAgICAgICAgICAgICBpbmYtPmxvbmdfYmxvY2tfdG90Kys7DQogI2Vu
ZGlmDQpAQCAtMTE5MCwyNCArMTE0OSwxMyBAQCBzdGF0aWMgdm9pZCBzZWRmX3dha2UoY29uc3Qg
c3RydWN0IHNjaGVkDQogICAgICAgICB9DQogICAgIH0NCiANCi0gICAgUFJJTlQoMywgIndva2Ug
dXAgZG9tYWluICVpLiVpIChkZWFkbD0gJSJQUkl1NjQiIHBlcmlvZD0gJSJQUkl1NjQNCi0gICAg
ICAgICAgIm5vdz0gJSJQUkl1NjQiKVxuIiwNCi0gICAgICAgICAgZC0+ZG9tYWluLT5kb21haW5f
aWQsIGQtPnZjcHVfaWQsIGluZi0+ZGVhZGxfYWJzLA0KLSAgICAgICAgICBpbmYtPnBlcmlvZCwg
bm93KTsNCi0NCiAgICAgaWYgKCBQRVJJT0RfQkVHSU4oaW5mKSA+IG5vdyApDQotICAgIHsNCiAg
ICAgICAgIF9fYWRkX3RvX3dhaXRxdWV1ZV9zb3J0KGQpOw0KLSAgICAgICAgUFJJTlQoMywiYWRk
ZWQgdG8gd2FpdHFcbiIpOw0KLSAgICB9DQogICAgIGVsc2UNCi0gICAgew0KICAgICAgICAgX19h
ZGRfdG9fcnVucXVldWVfc29ydChkKTsNCi0gICAgICAgIFBSSU5UKDMsImFkZGVkIHRvIHJ1bnFc
biIpOw0KLSAgICB9DQogIA0KICNpZmRlZiBTRURGX1NUQVRTDQotICAgIC8qZG8gc29tZSBzdGF0
aXN0aWNzIGhlcmUuLi4qLw0KKyAgICAvKiBEbyBzb21lIHN0YXRpc3RpY3MgaGVyZS4uLiAqLw0K
ICAgICBpZiAoIGluZi0+YmxvY2tfYWJzICE9IDAgKQ0KICAgICB7DQogICAgICAgICBpbmYtPmJs
b2NrX3RpbWVfdG90ICs9IG5vdyAtIGluZi0+YmxvY2tfYWJzOw0KQEAgLTEyMTYsMTIgKzExNjQs
MTQgQEAgc3RhdGljIHZvaWQgc2VkZl93YWtlKGNvbnN0IHN0cnVjdCBzY2hlZA0KICAgICB9DQog
I2VuZGlmDQogDQotICAgIC8qc2FuaXR5IGNoZWNrOiBtYWtlIHN1cmUgZWFjaCBleHRyYS1hd2Fy
ZSBkb21haW4gSVMgb24gdGhlIHV0aWwtcSEqLw0KKyAgICAvKiBTYW5pdHkgY2hlY2s6IG1ha2Ug
c3VyZSBlYWNoIGV4dHJhLWF3YXJlIGRvbWFpbiBJUyBvbiB0aGUgdXRpbC1xISAqLw0KICAgICBB
U1NFUlQoSU1QTFkoaW5mLT5zdGF0dXMgJiBFWFRSQV9BV0FSRSwgZXh0cmFxX29uKGQsIEVYVFJB
X1VUSUxfUSkpKTsNCiAgICAgQVNTRVJUKF9fdGFza19vbl9xdWV1ZShkKSk7DQotICAgIC8qY2hl
Y2sgd2hldGhlciB0aGUgYXdha2VuZWQgdGFzayBuZWVkcyB0byBpbnZva2UgdGhlIGRvX3NjaGVk
dWxlDQotICAgICAgcm91dGluZS4gVHJ5IHRvIGF2b2lkIHVubmVjZXNzYXJ5IHJ1bnMgYnV0Og0K
LSAgICAgIFNhdmUgYXBwcm94aW1hdGlvbjogQWx3YXlzIHN3aXRjaCB0byBzY2hlZHVsZXIhKi8N
CisgICAgLyoNCisgICAgICogQ2hlY2sgd2hldGhlciB0aGUgYXdha2VuZWQgdGFzayBuZWVkcyB0
byBpbnZva2UgdGhlIGRvX3NjaGVkdWxlDQorICAgICAqIHJvdXRpbmUuIFRyeSB0byBhdm9pZCB1
bm5lY2Vzc2FyeSBydW5zIGJ1dDoNCisgICAgICogU2F2ZSBhcHByb3hpbWF0aW9uOiBBbHdheXMg
c3dpdGNoIHRvIHNjaGVkdWxlciENCisgICAgICovDQogICAgIEFTU0VSVChkLT5wcm9jZXNzb3Ig
Pj0gMCk7DQogICAgIEFTU0VSVChkLT5wcm9jZXNzb3IgPCBucl9jcHVfaWRzKTsNCiAgICAgQVNT
RVJUKHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwgZC0+cHJvY2Vzc29yKS5jdXJyKTsNCkBAIC0xMjY2
LDcgKzEyMTYsNyBAQCBzdGF0aWMgdm9pZCBzZWRmX2R1bXBfZG9tYWluKHN0cnVjdCB2Y3B1DQog
fQ0KIA0KIA0KLS8qIGR1bXBzIGFsbCBkb21haW5zIG9uIHRoZSBzcGVjaWZpZWQgY3B1ICovDQor
LyogRHVtcHMgYWxsIGRvbWFpbnMgb24gdGhlIHNwZWNpZmllZCBjcHUgKi8NCiBzdGF0aWMgdm9p
ZCBzZWRmX2R1bXBfY3B1X3N0YXRlKGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcywgaW50IGkp
DQogew0KICAgICBzdHJ1Y3QgbGlzdF9oZWFkICAgICAgKmxpc3QsICpxdWV1ZSwgKnRtcDsNCkBA
IC0xMzQxLDE2ICsxMjkxLDE4IEBAIHN0YXRpYyB2b2lkIHNlZGZfZHVtcF9jcHVfc3RhdGUoY29u
c3Qgc3QNCiB9DQogDQogDQotLyogQWRqdXN0cyBwZXJpb2RzIGFuZCBzbGljZXMgb2YgdGhlIGRv
bWFpbnMgYWNjb3JkaW5nbHkgdG8gdGhlaXIgd2VpZ2h0cy4gKi8NCisvKiBBZGp1c3RzIHBlcmlv
ZHMgYW5kIHNsaWNlcyBvZiB0aGUgZG9tYWlucyBhY2NvcmRpbmdseSB0byB0aGVpciB3ZWlnaHRz
ICovDQogc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcHVwb29sICpjLCBp
bnQgbnJfY3B1cywgaW50ICpzdW13LCBzX3RpbWVfdCAqc3VtdCkNCiB7DQogICAgIHN0cnVjdCB2
Y3B1ICpwOw0KICAgICBzdHJ1Y3QgZG9tYWluICAgICAgKmQ7DQogICAgIHVuc2lnbmVkIGludCAg
ICAgICAgY3B1Ow0KIA0KLSAgICAvKiBTdW0gYWNyb3NzIGFsbCB3ZWlnaHRzLiBOb3RpY2UgdGhh
dCBubyBydW5xIGxvY2tpbmcgaXMgbmVlZGVkDQorICAgIC8qDQorICAgICAqIFN1bSBhY3Jvc3Mg
YWxsIHdlaWdodHMuIE5vdGljZSB0aGF0IG5vIHJ1bnEgbG9ja2luZyBpcyBuZWVkZWQNCiAgICAg
ICogaGVyZTogdGhlIGNhbGxlciBob2xkcyBzZWRmX3ByaXZfaW5mby5sb2NrIGFuZCB3ZSdyZSBu
b3QgY2hhbmdpbmcNCi0gICAgICogYW55dGhpbmcgdGhhdCBpcyBhY2Nlc3NlZCBkdXJpbmcgc2No
ZWR1bGluZy4gKi8NCisgICAgICogYW55dGhpbmcgdGhhdCBpcyBhY2Nlc3NlZCBkdXJpbmcgc2No
ZWR1bGluZy4NCisgICAgICovDQogICAgIHJjdV9yZWFkX2xvY2soJmRvbWxpc3RfcmVhZF9sb2Nr
KTsNCiAgICAgZm9yX2VhY2hfZG9tYWluX2luX2NwdXBvb2woIGQsIGMgKQ0KICAgICB7DQpAQCAt
MTM2NSwxMSArMTMxNywxNCBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dlaWdodHMoc3RydWN0
IGNwDQogICAgICAgICAgICAgfQ0KICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICB7DQot
ICAgICAgICAgICAgICAgIC8qZG9uJ3QgbW9kaWZ5IGRvbWFpbnMgd2hvIGRvbid0IGhhdmUgYSB3
ZWlnaHQsIGJ1dCBzdW0NCi0gICAgICAgICAgICAgICAgICB1cCB0aGUgdGltZSB0aGV5IG5lZWQs
IHByb2plY3RlZCB0byBhIFdFSUdIVF9QRVJJT0QsDQotICAgICAgICAgICAgICAgICAgc28gdGhh
dCB0aGlzIHRpbWUgaXMgbm90IGdpdmVuIHRvIHRoZSB3ZWlnaHQtZHJpdmVuDQotICAgICAgICAg
ICAgICAgICAgZG9tYWlucyovDQotICAgICAgICAgICAgICAgIC8qY2hlY2sgZm9yIG92ZXJmbG93
cyovDQorICAgICAgICAgICAgICAgIC8qDQorICAgICAgICAgICAgICAgICAqIERvbid0IG1vZGlm
eSBkb21haW5zIHdobyBkb24ndCBoYXZlIGEgd2VpZ2h0LCBidXQgc3VtDQorICAgICAgICAgICAg
ICAgICAqIHVwIHRoZSB0aW1lIHRoZXkgbmVlZCwgcHJvamVjdGVkIHRvIGEgV0VJR0hUX1BFUklP
RCwNCisgICAgICAgICAgICAgICAgICogc28gdGhhdCB0aGlzIHRpbWUgaXMgbm90IGdpdmVuIHRv
IHRoZSB3ZWlnaHQtZHJpdmVuDQorICAgICAgICAgICAgICAgICAqICBkb21haW5zDQorICAgICAg
ICAgICAgICAgICAqLw0KKw0KKyAgICAgICAgICAgICAgICAvKiBDaGVjayBmb3Igb3ZlcmZsb3dz
ICovDQogICAgICAgICAgICAgICAgIEFTU0VSVCgoV0VJR0hUX1BFUklPRCA8IFVMT05HX01BWCkg
DQogICAgICAgICAgICAgICAgICAgICAgICAmJiAoRURPTV9JTkZPKHApLT5zbGljZV9vcmlnIDwg
VUxPTkdfTUFYKSk7DQogICAgICAgICAgICAgICAgIHN1bXRbY3B1XSArPSANCkBAIC0xMzgwLDkg
KzEzMzUsMTEgQEAgc3RhdGljIGludCBzZWRmX2FkanVzdF93ZWlnaHRzKHN0cnVjdCBjcA0KICAg
ICB9DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KIA0KLSAgICAv
KiBBZGp1c3QgYWxsIHNsaWNlcyAoYW5kIHBlcmlvZHMpIHRvIHRoZSBuZXcgd2VpZ2h0LiBVbmxp
a2UgYWJvdmUsIHdlDQorICAgIC8qDQorICAgICAqIEFkanVzdCBhbGwgc2xpY2VzIChhbmQgcGVy
aW9kcykgdG8gdGhlIG5ldyB3ZWlnaHQuIFVubGlrZSBhYm92ZSwgd2UNCiAgICAgICogbmVlZCB0
byB0YWtlIHRociBydW5xIGxvY2sgZm9yIHRoZSB2YXJpb3VzIFZDUFVzOiB3ZSdyZSBtb2R5Zmlu
Zw0KLSAgICAgKiBzbGljZSBhbmQgcGVyaW9kIHdoaWNoIGFyZSByZWZlcmVuY2VkIGR1cmluZyBz
Y2hlZHVsaW5nLiAqLw0KKyAgICAgKiBzbGljZSBhbmQgcGVyaW9kIHdoaWNoIGFyZSByZWZlcmVu
Y2VkIGR1cmluZyBzY2hlZHVsaW5nLg0KKyAgICAgKi8NCiAgICAgcmN1X3JlYWRfbG9jaygmZG9t
bGlzdF9yZWFkX2xvY2spOw0KICAgICBmb3JfZWFjaF9kb21haW5faW5fY3B1cG9vbCggZCwgYyAp
DQogICAgIHsNCkBAIC0xNDEwLDcgKzEzNjcsNyBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0X3dl
aWdodHMoc3RydWN0IGNwDQogfQ0KIA0KIA0KLS8qIHNldCBvciBmZXRjaCBkb21haW4gc2NoZWR1
bGluZyBwYXJhbWV0ZXJzICovDQorLyogU2V0IG9yIGZldGNoIGRvbWFpbiBzY2hlZHVsaW5nIHBh
cmFtZXRlcnMgKi8NCiBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlZHVs
ZXIgKm9wcywgc3RydWN0IGRvbWFpbiAqcCwgc3RydWN0IHhlbl9kb21jdGxfc2NoZWR1bGVyX29w
ICpvcCkNCiB7DQogICAgIHN0cnVjdCBzZWRmX3ByaXZfaW5mbyAqcHJ2ID0gU0VERl9QUklWKG9w
cyk7DQpAQCAtMTQyMSwyMyArMTM3OCwyMiBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0
IHN0cnVjdCBzY2hlDQogICAgIHN0cnVjdCB2Y3B1ICp2Ow0KICAgICBpbnQgcmMgPSAwOw0KIA0K
LSAgICBQUklOVCgyLCJzZWRmX2FkanVzdCB3YXMgY2FsbGVkLCBkb21haW4taWQgJWkgbmV3IHBl
cmlvZCAlIlBSSXU2NCIgIg0KLSAgICAgICAgICAibmV3IHNsaWNlICUiUFJJdTY0IlxubGF0ZW5j
eSAlIlBSSXU2NCIgZXh0cmE6JXNcbiIsDQotICAgICAgICAgIHAtPmRvbWFpbl9pZCwgb3AtPnUu
c2VkZi5wZXJpb2QsIG9wLT51LnNlZGYuc2xpY2UsDQotICAgICAgICAgIG9wLT51LnNlZGYubGF0
ZW5jeSwgKG9wLT51LnNlZGYuZXh0cmF0aW1lKT8ieWVzIjoibm8iKTsNCi0NCi0gICAgLyogU2Vy
aWFsaXplIGFnYWluc3QgdGhlIHBsdWdnYWJsZSBzY2hlZHVsZXIgbG9jayB0byBwcm90ZWN0IGZy
b20NCisgICAgLyoNCisgICAgICogU2VyaWFsaXplIGFnYWluc3QgdGhlIHBsdWdnYWJsZSBzY2hl
ZHVsZXIgbG9jayB0byBwcm90ZWN0IGZyb20NCiAgICAgICogY29uY3VycmVudCB1cGRhdGVzLiBX
ZSBuZWVkIHRvIHRha2UgdGhlIHJ1bnEgbG9jayBmb3IgdGhlIFZDUFVzDQogICAgICAqIGFzIHdl
bGwsIHNpbmNlIHdlIGFyZSB0b3VjaGluZyBleHRyYXdlaWdodCwgd2VpZ2h0LCBzbGljZSBhbmQN
CiAgICAgICogcGVyaW9kLiBBcyBpbiBzY2hlZF9jcmVkaXQyLmMsIHJ1bnEgbG9ja3MgbmVzdCBp
bnNpZGUgdGhlDQotICAgICAqIHBsdWdnYWJsZSBzY2hlZHVsZXIgbG9jay4gKi8NCisgICAgICog
cGx1Z2dhYmxlIHNjaGVkdWxlciBsb2NrLg0KKyAgICAgKi8NCiAgICAgc3Bpbl9sb2NrX2lycXNh
dmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KIA0KICAgICBpZiAoIG9wLT5jbWQgPT0gWEVOX0RPTUNU
TF9TQ0hFRE9QX3B1dGluZm8gKQ0KICAgICB7DQotICAgICAgICAvKiBUaGVzZSBhcmUgdXNlZCBp
biBzZWRmX2FkanVzdF93ZWlnaHRzKCkgYnV0IGhhdmUgdG8gYmUgYWxsb2NhdGVkIGluDQorICAg
ICAgICAvKg0KKyAgICAgICAgICogVGhlc2UgYXJlIHVzZWQgaW4gc2VkZl9hZGp1c3Rfd2VpZ2h0
cygpIGJ1dCBoYXZlIHRvIGJlIGFsbG9jYXRlZCBpbg0KICAgICAgICAgICogdGhpcyBmdW5jdGlv
biwgYXMgd2UgbmVlZCB0byBhdm9pZCBuZXN0aW5nIHhtZW1fcG9vbF9hbGxvYydzIGxvY2sNCi0g
ICAgICAgICAqIHdpdGhpbiBvdXIgcHJ2LT5sb2NrLiAqLw0KKyAgICAgICAgICogd2l0aGluIG91
ciBwcnYtPmxvY2suDQorICAgICAgICAgKi8NCiAgICAgICAgIGlmICggIXN1bXcgfHwgIXN1bXQg
KQ0KICAgICAgICAgew0KICAgICAgICAgICAgIC8qIENoZWNrIGZvciBlcnJvcnMgaGVyZSwgdGhl
IF9nZXRpbmZvIGJyYW5jaCBkb2Vzbid0IGNhcmUgKi8NCkBAIC0xNDQ1LDcgKzE0MDEsNyBAQCBz
dGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAgICAgZ290
byBvdXQ7DQogICAgICAgICB9DQogDQotICAgICAgICAvKiBDaGVjayBmb3Igc2FuZSBwYXJhbWV0
ZXJzLiAqLw0KKyAgICAgICAgLyogQ2hlY2sgZm9yIHNhbmUgcGFyYW1ldGVycyAqLw0KICAgICAg
ICAgaWYgKCAhb3AtPnUuc2VkZi5wZXJpb2QgJiYgIW9wLT51LnNlZGYud2VpZ2h0ICkNCiAgICAg
ICAgIHsNCiAgICAgICAgICAgICByYyA9IC1FSU5WQUw7DQpAQCAtMTQ1Nyw3ICsxNDEzLDcgQEAg
c3RhdGljIGludCBzZWRmX2FkanVzdChjb25zdCBzdHJ1Y3Qgc2NoZQ0KICAgICAgICAgICAgIGlm
ICggKG9wLT51LnNlZGYuZXh0cmF0aW1lICYgRVhUUkFfQVdBUkUpICYmDQogICAgICAgICAgICAg
ICAgICAoIW9wLT51LnNlZGYucGVyaW9kKSApDQogICAgICAgICAgICAgew0KLSAgICAgICAgICAg
ICAgICAvKiBXZWlnaHQtZHJpdmVuIGRvbWFpbnMgd2l0aCBleHRyYXRpbWUgb25seS4gKi8NCisg
ICAgICAgICAgICAgICAgLyogV2VpZ2h0LWRyaXZlbiBkb21haW5zIHdpdGggZXh0cmF0aW1lIG9u
bHkgKi8NCiAgICAgICAgICAgICAgICAgZm9yX2VhY2hfdmNwdSAoIHAsIHYgKQ0KICAgICAgICAg
ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAvKiAoSGVyZSBhbmQgZXZlcnl3aGVyZSBp
biB0aGUgZm9sbG93aW5nKSBJUlFzIGFyZSBhbHJlYWR5IG9mZiwNCkBAIC0xNDcyLDcgKzE0Mjgs
NyBAQCBzdGF0aWMgaW50IHNlZGZfYWRqdXN0KGNvbnN0IHN0cnVjdCBzY2hlDQogICAgICAgICAg
ICAgfQ0KICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICB7DQotICAgICAgICAgICAgICAg
IC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIHJlYWwtdGltZSBleGVjdXRpb24uICovDQor
ICAgICAgICAgICAgICAgIC8qIFdlaWdodC1kcml2ZW4gZG9tYWlucyB3aXRoIHJlYWwtdGltZSBl
eGVjdXRpb24gKi8NCiAgICAgICAgICAgICAgICAgZm9yX2VhY2hfdmNwdSAoIHAsIHYgKSB7DQog
ICAgICAgICAgICAgICAgICAgICB2Y3B1X3NjaGVkdWxlX2xvY2sodik7DQogICAgICAgICAgICAg
ICAgICAgICBFRE9NX0lORk8odiktPndlaWdodCA9IG9wLT51LnNlZGYud2VpZ2h0Ow0KQEAgLTE0
OTUsNyArMTQ1MSw3IEBAIHN0YXRpYyBpbnQgc2VkZl9hZGp1c3QoY29uc3Qgc3RydWN0IHNjaGUN
CiAgICAgICAgICAgICAgICAgZ290byBvdXQ7DQogICAgICAgICAgICAgfQ0KIA0KLSAgICAgICAg
ICAgIC8qIFRpbWUtZHJpdmVuIGRvbWFpbnMuICovDQorICAgICAgICAgICAgLyogVGltZS1kcml2
ZW4gZG9tYWlucyAqLw0KICAgICAgICAgICAgIGZvcl9lYWNoX3ZjcHUgKCBwLCB2ICkNCiAgICAg
ICAgICAgICB7DQogICAgICAgICAgICAgICAgIHZjcHVfc2NoZWR1bGVfbG9jayh2KTsNCkBAIC0x
NTQ1LDcgKzE1MDEsNiBAQCBvdXQ6DQogICAgIHhmcmVlKHN1bXQpOw0KICAgICB4ZnJlZShzdW13
KTsNCiANCi0gICAgUFJJTlQoMiwic2VkZl9hZGp1c3RfZmluaXNoZWQgd2l0aCByZXR1cm4gY29k
ZSAlZFxuIiwgcmMpOw0KICAgICByZXR1cm4gcmM7DQogfQ0KIA0K


--=-Q+nO0nZUPH9ih0IDSLo0--

--=-BVBDbEUzgZPrsy4cOGLY
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)

iEYEABECAAYFAk8Fvu0ACgkQk4XaBE3IOsR1VwCfcsuEozHwG9FojBY+UvcmkcD1
v9IAnA3Ue47AV827f9NpybP7AUye4eh1
=QtEa
-----END PGP SIGNATURE-----

--=-BVBDbEUzgZPrsy4cOGLY--



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

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

--===============0162675564886136273==--



From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:20:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rip7N-00015S-Ne; Thu, 05 Jan 2012 15:20:37 +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 1Rip7M-00015F-Ou
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:20:36 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325776830!9194715!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16072 invoked from network); 5 Jan 2012 15:20:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 15:20:30 -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 q05FK1V7029470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 10:20:01 -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 q05FJwLH004615; Thu, 5 Jan 2012 10:19:59 -0500
Message-ID: <4F05BF9E.7000203@redhat.com>
Date: Thu, 05 Jan 2012 17:19:58 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
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 01/05/2012 04:34 PM, Stefano Stabellini wrote:
> On Thu, 5 Jan 2012, Avi Kivity wrote:
> > On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > > > The "solution" I am proposing is introducing an early_savevm set of
> > > > > save/restore functions so that at restore time we can get to know at
> > > > > what address the videoram is mapped into the guest address space. Once we
> > > > > know the address we can remap it into qemu's address space and/or move it
> > > > > to another guest physical address.
> > > > 
> > > > Why can we not simply track it?  For every MemoryRegion, have a field
> > > > called xen_address which tracks its location in the Xen address space
> > > > (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> > > > xen_address would be maintained by callbacks called from the memory API
> > > > into xen-all.c.
> > >
> > > Nice and simple, I like it.
> > > However we would still need an early_savevm mechanism to save and restore the
> > > MemoryRegions, unless they already gets saved and restored somehow?
> > 
> > MemoryRegions are instantiated by the devices, so they should be there
> > (creating a MemoryRegion == calling qemu_ram_alloc() in the old days)
>
> If the MemoryRegions are re-created by the devices, then we need another
> mechanism to find out where the videoram is.
> What I am saying is that the suggestion of having a xen_address field
> for every MemoryRegion would make the code cleaner but it would not
> solve the save/restore issue described in the previous email.

Okay, I think I understand now.

You're not really allocating memory on restore, you're attaching to
already allocated memory, and you need a handle to it, passed from the
save side.

One way is to add early-save/restore like you suggest.  Another is to
make the attach late.  Can we defer it until after restore is complete
and we know everything?

This involves:
- adding vmstate to xen-all.c so it can migrate the xen vram address
- making sure the memory core doesn't do mappings during restore (can be
done by wrapping restore with
memory_region_transaction_begin()/memory_region_transaction_commit();
beneficial to normal qemu migrations as well)
- updating the mapped address during restore

I think this is cleaner than introducing a new migration stage, but the
implementation may prove otherwise.

> > 
> > xen_register_framebuffer() is slightly less hacky.
>
> I agree, however xen_register_framebuffer is called after
> memory_region_init_ram, so the allocation would have been made already.

xen_ram_alloc(MemoryRegion *mr)
{
    if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
        return;
    }
}

xen_framebuffer_address_post_load()
{
    framebuffer_addr_known = true;
    if (framebuffer) {
        framebuffer->xen_address = framebuffer_addr;
    }
}

(ugly way of avoiding a dependency, but should work)

-- 
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 Jan 05 15:20:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rip7N-00015S-Ne; Thu, 05 Jan 2012 15:20:37 +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 1Rip7M-00015F-Ou
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:20:36 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325776830!9194715!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16072 invoked from network); 5 Jan 2012 15:20:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 15:20:30 -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 q05FK1V7029470
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 10:20:01 -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 q05FJwLH004615; Thu, 5 Jan 2012 10:19:59 -0500
Message-ID: <4F05BF9E.7000203@redhat.com>
Date: Thu, 05 Jan 2012 17:19:58 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
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 01/05/2012 04:34 PM, Stefano Stabellini wrote:
> On Thu, 5 Jan 2012, Avi Kivity wrote:
> > On 01/05/2012 03:17 PM, Stefano Stabellini wrote:
> > > > > The "solution" I am proposing is introducing an early_savevm set of
> > > > > save/restore functions so that at restore time we can get to know at
> > > > > what address the videoram is mapped into the guest address space. Once we
> > > > > know the address we can remap it into qemu's address space and/or move it
> > > > > to another guest physical address.
> > > > 
> > > > Why can we not simply track it?  For every MemoryRegion, have a field
> > > > called xen_address which tracks its location in the Xen address space
> > > > (as determined by the last call to xen_set_memory or qemu_ram_alloc). 
> > > > xen_address would be maintained by callbacks called from the memory API
> > > > into xen-all.c.
> > >
> > > Nice and simple, I like it.
> > > However we would still need an early_savevm mechanism to save and restore the
> > > MemoryRegions, unless they already gets saved and restored somehow?
> > 
> > MemoryRegions are instantiated by the devices, so they should be there
> > (creating a MemoryRegion == calling qemu_ram_alloc() in the old days)
>
> If the MemoryRegions are re-created by the devices, then we need another
> mechanism to find out where the videoram is.
> What I am saying is that the suggestion of having a xen_address field
> for every MemoryRegion would make the code cleaner but it would not
> solve the save/restore issue described in the previous email.

Okay, I think I understand now.

You're not really allocating memory on restore, you're attaching to
already allocated memory, and you need a handle to it, passed from the
save side.

One way is to add early-save/restore like you suggest.  Another is to
make the attach late.  Can we defer it until after restore is complete
and we know everything?

This involves:
- adding vmstate to xen-all.c so it can migrate the xen vram address
- making sure the memory core doesn't do mappings during restore (can be
done by wrapping restore with
memory_region_transaction_begin()/memory_region_transaction_commit();
beneficial to normal qemu migrations as well)
- updating the mapped address during restore

I think this is cleaner than introducing a new migration stage, but the
implementation may prove otherwise.

> > 
> > xen_register_framebuffer() is slightly less hacky.
>
> I agree, however xen_register_framebuffer is called after
> memory_region_init_ram, so the allocation would have been made already.

xen_ram_alloc(MemoryRegion *mr)
{
    if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
        return;
    }
}

xen_framebuffer_address_post_load()
{
    framebuffer_addr_known = true;
    if (framebuffer) {
        framebuffer->xen_address = framebuffer_addr;
    }
}

(ugly way of avoiding a dependency, but should work)

-- 
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 Jan 05 15:26:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipCp-0001J5-Hu; Thu, 05 Jan 2012 15:26:15 +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 1RipCo-0001J0-9n
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:26:14 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325777139!47232111!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 4239 invoked from network); 5 Jan 2012 15:25:39 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-27.messagelabs.com with SMTP;
	5 Jan 2012 15:25:39 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74305336; Thu, 05 Jan 2012 16:26:11 +0100
Message-ID: <1325777149.2728.9.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Thu, 05 Jan 2012 16:25:49 +0100
In-Reply-To: <1325776241.2728.5.camel@Solace>
References: <1325776241.2728.5.camel@Solace>
X-Mailer: Evolution 3.2.2-1 
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] [PATCHv2 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="===============9181086115744466247=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============9181086115744466247==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-gcfNY/9wlfpQGHGqP8uB"


--=-gcfNY/9wlfpQGHGqP8uB
Content-Type: multipart/mixed; boundary="=-xL9D24flhr5EjzYrrouw"


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

Dealing with interrupts from VT-d IOMMU(s) 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 of 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 efaa28639a71 xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c	Wed Jan 04 16:12:44 2012 +0000
+++ b/xen/drivers/passthrough/vtd/iommu.c	Thu Jan 05 15:17:47 2012 +0100
@@ -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,37 @@ 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 IOMMUs) 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 +2175,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)


--=-xL9D24flhr5EjzYrrouw
Content-Disposition: attachment; filename="iommu-fault-tasklet_vtd.patch"
Content-Type: text/x-patch; name="iommu-fault-tasklet_vtd.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGVmYWEyODYzOWE3MTUyNGE2OTNiYTUwMDYy
NGY4NTEyZTU3OTVlMTgNCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgVlQtZC4NCg0KRGVhbGluZyB3aXRoIGludGVycnVwdHMgZnJvbSBWVC1kIElPTU1VKHMpIGlz
IGRlZmVycmVkIHRvIGEgc29mdGlycS10YXNrbGV0LA0KcmFpc2VkIGJ5IHRoZSBhY3R1YWwgSVJR
IGhhbmRsZXIuIFNpbmNlIGEgbmV3IGludGVycnVwdCBpcyBub3QgZ2VuZXJhdGVkLA0KZXZlbiBp
ZiBmdXJ0aGVyIGZhdWx0cyBvY2N1ciwgdW50aWwgd2UgY2xlYXJlZCBhbGwgdGhlIHBlbmRpbmcg
b25lcywNCnRoZXJlJ3Mgbm8gbmVlZCBvZiBkaXNhYmxpbmcgSVJRcywgYXMgdGhlIGhhcmR3YXJl
IGRvZXMgaXQgYnkgaXRzIG93bi4NCk5vdGljZSB0aGF0IHRoaXMgbWF5IGNhdXNlIHRoZSBsb2cg
dG8gb3ZlcmZsb3csIGJ1dCBub25lIG9mIHRoZSBleGlzdGluZw0KZW50cnkgd2lsbCBiZSBvdmVy
d3JpdHRlbi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xp
QGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgZWZhYTI4NjM5YTcxIHhlbi9kcml2ZXJzL3Bhc3N0aHJv
dWdoL3Z0ZC9pb21tdS5jDQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC92dGQvaW9tbXUu
YwlXZWQgSmFuIDA0IDE2OjEyOjQ0IDIwMTIgKzAwMDANCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0
aHJvdWdoL3Z0ZC9pb21tdS5jCVRodSBKYW4gMDUgMTU6MTc6NDcgMjAxMiArMDEwMA0KQEAgLTUz
LDYgKzUzLDggQEAgYm9vbF90IF9fcmVhZF9tb3N0bHkgdW50cnVzdGVkX21zaTsNCiANCiBpbnQg
bnJfaW9tbXVzOw0KIA0KK3N0YXRpYyBzdHJ1Y3QgdGFza2xldCB2dGRfZmF1bHRfdGFza2xldDsN
CisNCiBzdGF0aWMgdm9pZCBzZXR1cF9kb20wX2RldmljZShzdHJ1Y3QgcGNpX2RldiAqKTsNCiBz
dGF0aWMgdm9pZCBzZXR1cF9kb20wX3JtcnIoc3RydWN0IGRvbWFpbiAqZCk7DQogDQpAQCAtOTE4
LDEwICs5MjAsOCBAQCBzdGF0aWMgdm9pZCBpb21tdV9mYXVsdF9zdGF0dXModTMyIGZhdWx0DQog
fQ0KIA0KICNkZWZpbmUgUFJJTUFSWV9GQVVMVF9SRUdfTEVOICgxNikNCi1zdGF0aWMgdm9pZCBp
b21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCi0gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3N0YXRpYyB2b2lkIF9f
ZG9faW9tbXVfcGFnZV9mYXVsdChzdHJ1Y3QgaW9tbXUgKmlvbW11KQ0KIHsNCi0gICAgc3RydWN0
IGlvbW11ICppb21tdSA9IGRldl9pZDsNCiAgICAgaW50IHJlZywgZmF1bHRfaW5kZXg7DQogICAg
IHUzMiBmYXVsdF9zdGF0dXM7DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQpAQCAtOTk2LDYg
Kzk5NiwzNyBAQCBjbGVhcl9vdmVyZmxvdzoNCiAgICAgfQ0KIH0NCiANCitzdGF0aWMgdm9pZCBk
b19pb21tdV9wYWdlX2ZhdWx0KHVuc2lnbmVkIGxvbmcgZGF0YSkNCit7DQorICAgIHN0cnVjdCBh
Y3BpX2RyaGRfdW5pdCAqZHJoZDsNCisNCisgICAgaWYgKCBsaXN0X2VtcHR5KCZhY3BpX2RyaGRf
dW5pdHMpICkNCisgICAgew0KKyAgICAgICBJTlRFTF9JT01NVV9ERUJVRygibm8gZGV2aWNlIGZv
dW5kLCBzb21ldGhpbmcgbXVzdCBiZSB2ZXJ5IHdyb25nIVxuIik7DQorICAgICAgIHJldHVybjsN
CisgICAgfQ0KKw0KKyAgICAvKg0KKyAgICAgKiBObyBtYXR0ZXIgZnJvbSB3aG9tIHRoZSBpbnRl
cnJ1cHQgY2FtZSBmcm9tLCBjaGVjayBhbGwgdGhlDQorICAgICAqIElPTU1VcyBwcmVzZW50IGlu
IHRoZSBzeXN0ZW0uIFRoaXMgYWxsb3dzIGZvciBoYXZpbmcganVzdCBvbmUNCisgICAgICogdGFz
a2xldCAoaW5zdGVhZCBvZiBvbmUgcGVyIGVhY2ggSU9NTVVzKSBhbmQgc2hvdWxkIGJlIG1vcmUg
dGhhbg0KKyAgICAgKiBmaW5lLCBjb25zaWRlcmluZyBob3cgcmFyZSB0aGUgZXZlbnQgb2YgYSBm
YXVsdCBzaG91bGQgYmUuDQorICAgICAqLw0KKyAgICBmb3JfZWFjaF9kcmhkX3VuaXQgKCBkcmhk
ICkNCisgICAgICAgIF9fZG9faW9tbXVfcGFnZV9mYXVsdChkcmhkLT5pb21tdSk7DQorfQ0KKw0K
K3N0YXRpYyB2b2lkIGlvbW11X3BhZ2VfZmF1bHQoaW50IGlycSwgdm9pZCAqZGV2X2lkLA0KKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQor
ew0KKyAgICAvKg0KKyAgICAgKiBKdXN0IGZsYWcgdGhlIHRhc2tsZXQgYXMgcnVubmFibGUuIFRo
aXMgaXMgZmluZSwgYWNjb3JkaW5nIHRvIFZULWQNCisgICAgICogc3BlY3Mgc2luY2UgYSBuZXcg
aW50ZXJydXB0IHdvbid0IGJlIGdlbmVyYXRlZCB1bnRpbCB3ZSBjbGVhciBhbGwNCisgICAgICog
dGhlIGZhdWx0cyB0aGF0IGNhdXNlZCB0aGlzIG9uZSB0byBoYXBwZW4uDQorICAgICAqLw0KKyAg
ICB0YXNrbGV0X3NjaGVkdWxlKCZ2dGRfZmF1bHRfdGFza2xldCk7DQorfQ0KKw0KIHN0YXRpYyB2
b2lkIGRtYV9tc2lfdW5tYXNrKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykNCiB7DQogICAgIHN0cnVj
dCBpb21tdSAqaW9tbXUgPSBkZXNjLT5hY3Rpb24tPmRldl9pZDsNCkBAIC0yMTQ0LDYgKzIxNzUs
OCBAQCBpbnQgX19pbml0IGludGVsX3Z0ZF9zZXR1cCh2b2lkKQ0KICAgICAgICAgaW9tbXUtPmly
cSA9IHJldDsNCiAgICAgfQ0KIA0KKyAgICBzb2Z0aXJxX3Rhc2tsZXRfaW5pdCgmdnRkX2ZhdWx0
X3Rhc2tsZXQsIGRvX2lvbW11X3BhZ2VfZmF1bHQsIDApOw0KKw0KICAgICBpZiAoICFpb21tdV9x
aW52YWwgJiYgaW9tbXVfaW50cmVtYXAgKQ0KICAgICB7DQogICAgICAgICBpb21tdV9pbnRyZW1h
cCA9IDA7DQo=


--=-xL9D24flhr5EjzYrrouw--

--=-gcfNY/9wlfpQGHGqP8uB
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)

iEYEABECAAYFAk8FwP0ACgkQk4XaBE3IOsTRVQCghCdZs4JXMr/QestWJluTBOZh
ZwIAnjHKDto1HNMtVzLbQL5KHFfwHZPt
=Qa6U
-----END PGP SIGNATURE-----

--=-gcfNY/9wlfpQGHGqP8uB--



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

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

--===============9181086115744466247==--



From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:26:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipCp-0001J5-Hu; Thu, 05 Jan 2012 15:26:15 +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 1RipCo-0001J0-9n
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:26:14 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325777139!47232111!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 4239 invoked from network); 5 Jan 2012 15:25:39 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-27.messagelabs.com with SMTP;
	5 Jan 2012 15:25:39 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74305336; Thu, 05 Jan 2012 16:26:11 +0100
Message-ID: <1325777149.2728.9.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Thu, 05 Jan 2012 16:25:49 +0100
In-Reply-To: <1325776241.2728.5.camel@Solace>
References: <1325776241.2728.5.camel@Solace>
X-Mailer: Evolution 3.2.2-1 
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] [PATCHv2 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="===============9181086115744466247=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============9181086115744466247==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-gcfNY/9wlfpQGHGqP8uB"


--=-gcfNY/9wlfpQGHGqP8uB
Content-Type: multipart/mixed; boundary="=-xL9D24flhr5EjzYrrouw"


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

Dealing with interrupts from VT-d IOMMU(s) 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 of 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 efaa28639a71 xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c	Wed Jan 04 16:12:44 2012 +0000
+++ b/xen/drivers/passthrough/vtd/iommu.c	Thu Jan 05 15:17:47 2012 +0100
@@ -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,37 @@ 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 IOMMUs) 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 +2175,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)


--=-xL9D24flhr5EjzYrrouw
Content-Disposition: attachment; filename="iommu-fault-tasklet_vtd.patch"
Content-Type: text/x-patch; name="iommu-fault-tasklet_vtd.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGVmYWEyODYzOWE3MTUyNGE2OTNiYTUwMDYy
NGY4NTEyZTU3OTVlMTgNCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgVlQtZC4NCg0KRGVhbGluZyB3aXRoIGludGVycnVwdHMgZnJvbSBWVC1kIElPTU1VKHMpIGlz
IGRlZmVycmVkIHRvIGEgc29mdGlycS10YXNrbGV0LA0KcmFpc2VkIGJ5IHRoZSBhY3R1YWwgSVJR
IGhhbmRsZXIuIFNpbmNlIGEgbmV3IGludGVycnVwdCBpcyBub3QgZ2VuZXJhdGVkLA0KZXZlbiBp
ZiBmdXJ0aGVyIGZhdWx0cyBvY2N1ciwgdW50aWwgd2UgY2xlYXJlZCBhbGwgdGhlIHBlbmRpbmcg
b25lcywNCnRoZXJlJ3Mgbm8gbmVlZCBvZiBkaXNhYmxpbmcgSVJRcywgYXMgdGhlIGhhcmR3YXJl
IGRvZXMgaXQgYnkgaXRzIG93bi4NCk5vdGljZSB0aGF0IHRoaXMgbWF5IGNhdXNlIHRoZSBsb2cg
dG8gb3ZlcmZsb3csIGJ1dCBub25lIG9mIHRoZSBleGlzdGluZw0KZW50cnkgd2lsbCBiZSBvdmVy
d3JpdHRlbi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xp
QGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgZWZhYTI4NjM5YTcxIHhlbi9kcml2ZXJzL3Bhc3N0aHJv
dWdoL3Z0ZC9pb21tdS5jDQotLS0gYS94ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC92dGQvaW9tbXUu
YwlXZWQgSmFuIDA0IDE2OjEyOjQ0IDIwMTIgKzAwMDANCisrKyBiL3hlbi9kcml2ZXJzL3Bhc3N0
aHJvdWdoL3Z0ZC9pb21tdS5jCVRodSBKYW4gMDUgMTU6MTc6NDcgMjAxMiArMDEwMA0KQEAgLTUz
LDYgKzUzLDggQEAgYm9vbF90IF9fcmVhZF9tb3N0bHkgdW50cnVzdGVkX21zaTsNCiANCiBpbnQg
bnJfaW9tbXVzOw0KIA0KK3N0YXRpYyBzdHJ1Y3QgdGFza2xldCB2dGRfZmF1bHRfdGFza2xldDsN
CisNCiBzdGF0aWMgdm9pZCBzZXR1cF9kb20wX2RldmljZShzdHJ1Y3QgcGNpX2RldiAqKTsNCiBz
dGF0aWMgdm9pZCBzZXR1cF9kb20wX3JtcnIoc3RydWN0IGRvbWFpbiAqZCk7DQogDQpAQCAtOTE4
LDEwICs5MjAsOCBAQCBzdGF0aWMgdm9pZCBpb21tdV9mYXVsdF9zdGF0dXModTMyIGZhdWx0DQog
fQ0KIA0KICNkZWZpbmUgUFJJTUFSWV9GQVVMVF9SRUdfTEVOICgxNikNCi1zdGF0aWMgdm9pZCBp
b21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCi0gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3N0YXRpYyB2b2lkIF9f
ZG9faW9tbXVfcGFnZV9mYXVsdChzdHJ1Y3QgaW9tbXUgKmlvbW11KQ0KIHsNCi0gICAgc3RydWN0
IGlvbW11ICppb21tdSA9IGRldl9pZDsNCiAgICAgaW50IHJlZywgZmF1bHRfaW5kZXg7DQogICAg
IHUzMiBmYXVsdF9zdGF0dXM7DQogICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQpAQCAtOTk2LDYg
Kzk5NiwzNyBAQCBjbGVhcl9vdmVyZmxvdzoNCiAgICAgfQ0KIH0NCiANCitzdGF0aWMgdm9pZCBk
b19pb21tdV9wYWdlX2ZhdWx0KHVuc2lnbmVkIGxvbmcgZGF0YSkNCit7DQorICAgIHN0cnVjdCBh
Y3BpX2RyaGRfdW5pdCAqZHJoZDsNCisNCisgICAgaWYgKCBsaXN0X2VtcHR5KCZhY3BpX2RyaGRf
dW5pdHMpICkNCisgICAgew0KKyAgICAgICBJTlRFTF9JT01NVV9ERUJVRygibm8gZGV2aWNlIGZv
dW5kLCBzb21ldGhpbmcgbXVzdCBiZSB2ZXJ5IHdyb25nIVxuIik7DQorICAgICAgIHJldHVybjsN
CisgICAgfQ0KKw0KKyAgICAvKg0KKyAgICAgKiBObyBtYXR0ZXIgZnJvbSB3aG9tIHRoZSBpbnRl
cnJ1cHQgY2FtZSBmcm9tLCBjaGVjayBhbGwgdGhlDQorICAgICAqIElPTU1VcyBwcmVzZW50IGlu
IHRoZSBzeXN0ZW0uIFRoaXMgYWxsb3dzIGZvciBoYXZpbmcganVzdCBvbmUNCisgICAgICogdGFz
a2xldCAoaW5zdGVhZCBvZiBvbmUgcGVyIGVhY2ggSU9NTVVzKSBhbmQgc2hvdWxkIGJlIG1vcmUg
dGhhbg0KKyAgICAgKiBmaW5lLCBjb25zaWRlcmluZyBob3cgcmFyZSB0aGUgZXZlbnQgb2YgYSBm
YXVsdCBzaG91bGQgYmUuDQorICAgICAqLw0KKyAgICBmb3JfZWFjaF9kcmhkX3VuaXQgKCBkcmhk
ICkNCisgICAgICAgIF9fZG9faW9tbXVfcGFnZV9mYXVsdChkcmhkLT5pb21tdSk7DQorfQ0KKw0K
K3N0YXRpYyB2b2lkIGlvbW11X3BhZ2VfZmF1bHQoaW50IGlycSwgdm9pZCAqZGV2X2lkLA0KKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQor
ew0KKyAgICAvKg0KKyAgICAgKiBKdXN0IGZsYWcgdGhlIHRhc2tsZXQgYXMgcnVubmFibGUuIFRo
aXMgaXMgZmluZSwgYWNjb3JkaW5nIHRvIFZULWQNCisgICAgICogc3BlY3Mgc2luY2UgYSBuZXcg
aW50ZXJydXB0IHdvbid0IGJlIGdlbmVyYXRlZCB1bnRpbCB3ZSBjbGVhciBhbGwNCisgICAgICog
dGhlIGZhdWx0cyB0aGF0IGNhdXNlZCB0aGlzIG9uZSB0byBoYXBwZW4uDQorICAgICAqLw0KKyAg
ICB0YXNrbGV0X3NjaGVkdWxlKCZ2dGRfZmF1bHRfdGFza2xldCk7DQorfQ0KKw0KIHN0YXRpYyB2
b2lkIGRtYV9tc2lfdW5tYXNrKHN0cnVjdCBpcnFfZGVzYyAqZGVzYykNCiB7DQogICAgIHN0cnVj
dCBpb21tdSAqaW9tbXUgPSBkZXNjLT5hY3Rpb24tPmRldl9pZDsNCkBAIC0yMTQ0LDYgKzIxNzUs
OCBAQCBpbnQgX19pbml0IGludGVsX3Z0ZF9zZXR1cCh2b2lkKQ0KICAgICAgICAgaW9tbXUtPmly
cSA9IHJldDsNCiAgICAgfQ0KIA0KKyAgICBzb2Z0aXJxX3Rhc2tsZXRfaW5pdCgmdnRkX2ZhdWx0
X3Rhc2tsZXQsIGRvX2lvbW11X3BhZ2VfZmF1bHQsIDApOw0KKw0KICAgICBpZiAoICFpb21tdV9x
aW52YWwgJiYgaW9tbXVfaW50cmVtYXAgKQ0KICAgICB7DQogICAgICAgICBpb21tdV9pbnRyZW1h
cCA9IDA7DQo=


--=-xL9D24flhr5EjzYrrouw--

--=-gcfNY/9wlfpQGHGqP8uB
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)

iEYEABECAAYFAk8FwP0ACgkQk4XaBE3IOsTRVQCghCdZs4JXMr/QestWJluTBOZh
ZwIAnjHKDto1HNMtVzLbQL5KHFfwHZPt
=Qa6U
-----END PGP SIGNATURE-----

--=-gcfNY/9wlfpQGHGqP8uB--



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

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

--===============9181086115744466247==--



From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:27:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:27:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipE4-0001MU-1M; Thu, 05 Jan 2012 15:27:32 +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 1RipE2-0001MA-57
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:27:30 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325777243!9731430!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 27693 invoked from network); 5 Jan 2012 15:27:23 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 15:27:23 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74305351; Thu, 05 Jan 2012 16:27:22 +0100
Message-ID: <1325777220.2728.11.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Thu, 05 Jan 2012 16:27:00 +0100
In-Reply-To: <1325776241.2728.5.camel@Solace>
References: <1325776241.2728.5.camel@Solace>
X-Mailer: Evolution 3.2.2-1 
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] [PATCHv2 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="===============2544051390667607061=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2544051390667607061==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-LgfSLpqc91p9nBEa/n3k"


--=-LgfSLpqc91p9nBEa/n3k
Content-Type: multipart/mixed; boundary="=-UGaeOSSswF4hJv9RKu01"


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

Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-taskl=
et,
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 lo=
w
level IRQ handler and enabled back in the tasklet body. Notice that this ma=
y
cause the log to overflow, but none of the existing entry will be overwritt=
en.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 3cb587bb34d0 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Jan 05 15:12:35 2012 +01=
00
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Jan 05 15:14:03 2012 +01=
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,45 @@ 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 ( !iommu_found() )
+    {
+        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 IOMMUs) 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 +923,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)


--=-UGaeOSSswF4hJv9RKu01
Content-Disposition: attachment; filename="iommu-fault-tasklet_amd.patch"
Content-Type: text/x-patch; name="iommu-fault-tasklet_amd.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDNjYjU4N2JiMzRkMGIxYTU4NmIwZjc4OWQ3
MGU0MjM2NTVmYThjMjcNCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgQU1ELVZpLg0KDQpEZWFsaW5nIHdpdGggaW50ZXJydXB0cyBmcm9tIEFNRC1WaSBJT01NVShz
KSBpcyBkZWZlcnJlZCB0byBhIHNvZnRpcnEtdGFza2xldCwNCnJhaXNlZCBieSB0aGUgYWN0dWFs
IElSUSBoYW5kbGVyLiBUbyBhdm9pZCBtb3JlIGludGVycnVwdHMgYmVpbmcgZ2VuZXJhdGVkDQoo
YmVjYXVzZSBvZiBmdXJ0aGVyIGZhdWx0cyksIHRoZXkgbXVzdCBiZSBtYXNrZWQgaW4gdGhlIElP
TU1VIHdpdGhpbiB0aGUgbG93DQpsZXZlbCBJUlEgaGFuZGxlciBhbmQgZW5hYmxlZCBiYWNrIGlu
IHRoZSB0YXNrbGV0IGJvZHkuIE5vdGljZSB0aGF0IHRoaXMgbWF5DQpjYXVzZSB0aGUgbG9nIHRv
IG92ZXJmbG93LCBidXQgbm9uZSBvZiB0aGUgZXhpc3RpbmcgZW50cnkgd2lsbCBiZSBvdmVyd3Jp
dHRlbi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xpQGNp
dHJpeC5jb20+DQoNCmRpZmYgLXIgM2NiNTg3YmIzNGQwIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo
L2FtZC9pb21tdV9pbml0LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21t
dV9pbml0LmMJVGh1IEphbiAwNSAxNToxMjozNSAyMDEyICswMTAwDQorKysgYi94ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW5pdC5jCVRodSBKYW4gMDUgMTU6MTQ6MDMgMjAxMiAr
MDEwMA0KQEAgLTMyLDYgKzMyLDggQEANCiANCiBzdGF0aWMgaW50IF9faW5pdGRhdGEgbnJfYW1k
X2lvbW11czsNCiANCitzdGF0aWMgc3RydWN0IHRhc2tsZXQgYW1kX2lvbW11X2ZhdWx0X3Rhc2ts
ZXQ7DQorDQogdW5zaWduZWQgc2hvcnQgaXZyc19iZGZfZW50cmllczsNCiBzdGF0aWMgc3RydWN0
IHJhZGl4X3RyZWVfcm9vdCBpdnJzX21hcHM7DQogc3RydWN0IGxpc3RfaGVhZCBhbWRfaW9tbXVf
aGVhZDsNCkBAIC01MjIsMTIgKzUyNCwxMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9ldmVudF9sb2df
ZW50cnkoc3RydWN0DQogICAgIH0NCiB9DQogDQotc3RhdGljIHZvaWQgYW1kX2lvbW11X3BhZ2Vf
ZmF1bHQoaW50IGlycSwgdm9pZCAqZGV2X2lkLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQorc3RhdGljIHZvaWQgX19kb19hbWRfaW9t
bXVfcGFnZV9mYXVsdChzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSkNCiB7DQogICAgIHUzMiBlbnRy
eTsNCiAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsNCi0gICAgc3RydWN0IGFtZF9pb21tdSAqaW9t
bXUgPSBkZXZfaWQ7DQogDQogICAgIHNwaW5fbG9ja19pcnFzYXZlKCZpb21tdS0+bG9jaywgZmxh
Z3MpOw0KICAgICBhbWRfaW9tbXVfcmVhZF9ldmVudF9sb2coaW9tbXUpOw0KQEAgLTU0Niw2ICs1
NDYsNDUgQEAgc3RhdGljIHZvaWQgYW1kX2lvbW11X3BhZ2VfZmF1bHQoaW50IGlycQ0KICAgICBz
cGluX3VubG9ja19pcnFyZXN0b3JlKCZpb21tdS0+bG9jaywgZmxhZ3MpOw0KIH0NCiANCitzdGF0
aWMgdm9pZCBkb19hbWRfaW9tbXVfcGFnZV9mYXVsdCh1bnNpZ25lZCBsb25nIGRhdGEpDQorew0K
KyAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsNCisNCisgICAgaWYgKCAhaW9tbXVfZm91bmQo
KSApDQorICAgIHsNCisgICAgICAgIEFNRF9JT01NVV9ERUJVRygibm8gZGV2aWNlIGZvdW5kLCBz
b21ldGhpbmcgbXVzdCBiZSB2ZXJ5IHdyb25nIVxuIik7DQorICAgICAgICByZXR1cm47DQorICAg
IH0NCisNCisgICAgLyoNCisgICAgICogTm8gbWF0dGVyIGZyb20gd2hvbSB0aGUgaW50ZXJydXB0
IGNhbWUgZnJvbSwgY2hlY2sgYWxsIHRoZQ0KKyAgICAgKiBJT01NVXMgcHJlc2VudCBpbiB0aGUg
c3lzdGVtLiBUaGlzIGFsbG93cyBmb3IgaGF2aW5nIGp1c3Qgb25lDQorICAgICAqIHRhc2tsZXQg
KGluc3RlYWQgb2Ygb25lIHBlciBlYWNoIElPTU1VcykgYW5kIHNob3VsZCBiZSBtb3JlIHRoYW4N
CisgICAgICogZmluZSwgY29uc2lkZXJpbmcgaG93IHJhcmUgdGhlIGV2ZW50IG9mIGEgZmF1bHQg
c2hvdWxkIGJlLg0KKyAgICAgKi8NCisgICAgZm9yX2VhY2hfYW1kX2lvbW11ICggaW9tbXUgKQ0K
KyAgICAgICAgX19kb19hbWRfaW9tbXVfcGFnZV9mYXVsdChpb21tdSk7DQorfQ0KKw0KK3N0YXRp
YyB2b2lkIGFtZF9pb21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3sN
CisgICAgdTMyIGVudHJ5Ow0KKyAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KKyAgICBzdHJ1Y3Qg
YW1kX2lvbW11ICppb21tdSA9IGRldl9pZDsNCisNCisgICAgLyogc2lsZW5jZSBpbnRlcnJ1cHRz
LiBUaGUgdGFza2xldCB3aWxsIGVuYWJsZSB0aGVtIGJhY2sgKi8NCisgICAgc3Bpbl9sb2NrX2ly
cXNhdmUoJmlvbW11LT5sb2NrLCBmbGFncyk7DQorICAgIGVudHJ5ID0gcmVhZGwoaW9tbXUtPm1t
aW9fYmFzZSArIElPTU1VX1NUQVRVU19NTUlPX09GRlNFVCk7DQorICAgIGlvbW11X2NsZWFyX2Jp
dCgmZW50cnksIElPTU1VX1NUQVRVU19FVkVOVF9MT0dfSU5UX1NISUZUKTsNCisgICAgd3JpdGVs
KGVudHJ5LCBpb21tdS0+bW1pb19iYXNlK0lPTU1VX1NUQVRVU19NTUlPX09GRlNFVCk7DQorICAg
IHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmlvbW11LT5sb2NrLCBmbGFncyk7DQorDQorICAgIC8q
IEZsYWcgdGhlIHRhc2tsZXQgYXMgcnVubmFibGUgc28gdGhhdCBpdCBjYW4gZXhlY3V0ZSwgY2xl
YXINCisgICAgICogdGhlIGxvZyBhbmQgcmUtZW5hYmxlIGludGVycnVwdHMuICovDQorICAgIHRh
c2tsZXRfc2NoZWR1bGUoJmFtZF9pb21tdV9mYXVsdF90YXNrbGV0KTsNCit9DQorDQogc3RhdGlj
IGludCBfX2luaXQgc2V0X2lvbW11X2ludGVycnVwdF9oYW5kbGVyKHN0cnVjdCBhbWRfaW9tbXUg
KmlvbW11KQ0KIHsNCiAgICAgaW50IGlycSwgcmV0Ow0KQEAgLTg4NCw2ICs5MjMsOCBAQCBpbnQg
X19pbml0IGFtZF9pb21tdV9pbml0KHZvaWQpDQogICAgICAgICBpZiAoIGFtZF9pb21tdV9pbml0
X29uZShpb21tdSkgIT0gMCApDQogICAgICAgICAgICAgZ290byBlcnJvcl9vdXQ7DQogDQorICAg
IHNvZnRpcnFfdGFza2xldF9pbml0KCZhbWRfaW9tbXVfZmF1bHRfdGFza2xldCwgZG9fYW1kX2lv
bW11X3BhZ2VfZmF1bHQsIDApOw0KKw0KICAgICByZXR1cm4gMDsNCiANCiBlcnJvcl9vdXQ6DQo=


--=-UGaeOSSswF4hJv9RKu01--

--=-LgfSLpqc91p9nBEa/n3k
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)

iEYEABECAAYFAk8FwUQACgkQk4XaBE3IOsR1EACbBN3JL7n1IfV8wJc6VBRsXMv4
J7IAn1qLVQ68CTeXGQIgwWMp93UMVDYi
=y6xN
-----END PGP SIGNATURE-----

--=-LgfSLpqc91p9nBEa/n3k--



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

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

--===============2544051390667607061==--



From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:27:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:27:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipE4-0001MU-1M; Thu, 05 Jan 2012 15:27:32 +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 1RipE2-0001MA-57
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:27:30 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325777243!9731430!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 27693 invoked from network); 5 Jan 2012 15:27:23 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 15:27:23 -0000
Received: from [62.94.182.88] (account d.faggioli@sssup.it HELO [192.168.0.40])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74305351; Thu, 05 Jan 2012 16:27:22 +0100
Message-ID: <1325777220.2728.11.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel@lists.xensource.com
Date: Thu, 05 Jan 2012 16:27:00 +0100
In-Reply-To: <1325776241.2728.5.camel@Solace>
References: <1325776241.2728.5.camel@Solace>
X-Mailer: Evolution 3.2.2-1 
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] [PATCHv2 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="===============2544051390667607061=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2544051390667607061==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-LgfSLpqc91p9nBEa/n3k"


--=-LgfSLpqc91p9nBEa/n3k
Content-Type: multipart/mixed; boundary="=-UGaeOSSswF4hJv9RKu01"


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

Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-taskl=
et,
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 lo=
w
level IRQ handler and enabled back in the tasklet body. Notice that this ma=
y
cause the log to overflow, but none of the existing entry will be overwritt=
en.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 3cb587bb34d0 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Thu Jan 05 15:12:35 2012 +01=
00
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Jan 05 15:14:03 2012 +01=
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,45 @@ 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 ( !iommu_found() )
+    {
+        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 IOMMUs) 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 +923,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)


--=-UGaeOSSswF4hJv9RKu01
Content-Disposition: attachment; filename="iommu-fault-tasklet_amd.patch"
Content-Type: text/x-patch; name="iommu-fault-tasklet_amd.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDNjYjU4N2JiMzRkMGIxYTU4NmIwZjc4OWQ3
MGU0MjM2NTVmYThjMjcNCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgQU1ELVZpLg0KDQpEZWFsaW5nIHdpdGggaW50ZXJydXB0cyBmcm9tIEFNRC1WaSBJT01NVShz
KSBpcyBkZWZlcnJlZCB0byBhIHNvZnRpcnEtdGFza2xldCwNCnJhaXNlZCBieSB0aGUgYWN0dWFs
IElSUSBoYW5kbGVyLiBUbyBhdm9pZCBtb3JlIGludGVycnVwdHMgYmVpbmcgZ2VuZXJhdGVkDQoo
YmVjYXVzZSBvZiBmdXJ0aGVyIGZhdWx0cyksIHRoZXkgbXVzdCBiZSBtYXNrZWQgaW4gdGhlIElP
TU1VIHdpdGhpbiB0aGUgbG93DQpsZXZlbCBJUlEgaGFuZGxlciBhbmQgZW5hYmxlZCBiYWNrIGlu
IHRoZSB0YXNrbGV0IGJvZHkuIE5vdGljZSB0aGF0IHRoaXMgbWF5DQpjYXVzZSB0aGUgbG9nIHRv
IG92ZXJmbG93LCBidXQgbm9uZSBvZiB0aGUgZXhpc3RpbmcgZW50cnkgd2lsbCBiZSBvdmVyd3Jp
dHRlbi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xpQGNp
dHJpeC5jb20+DQoNCmRpZmYgLXIgM2NiNTg3YmIzNGQwIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdo
L2FtZC9pb21tdV9pbml0LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21t
dV9pbml0LmMJVGh1IEphbiAwNSAxNToxMjozNSAyMDEyICswMTAwDQorKysgYi94ZW4vZHJpdmVy
cy9wYXNzdGhyb3VnaC9hbWQvaW9tbXVfaW5pdC5jCVRodSBKYW4gMDUgMTU6MTQ6MDMgMjAxMiAr
MDEwMA0KQEAgLTMyLDYgKzMyLDggQEANCiANCiBzdGF0aWMgaW50IF9faW5pdGRhdGEgbnJfYW1k
X2lvbW11czsNCiANCitzdGF0aWMgc3RydWN0IHRhc2tsZXQgYW1kX2lvbW11X2ZhdWx0X3Rhc2ts
ZXQ7DQorDQogdW5zaWduZWQgc2hvcnQgaXZyc19iZGZfZW50cmllczsNCiBzdGF0aWMgc3RydWN0
IHJhZGl4X3RyZWVfcm9vdCBpdnJzX21hcHM7DQogc3RydWN0IGxpc3RfaGVhZCBhbWRfaW9tbXVf
aGVhZDsNCkBAIC01MjIsMTIgKzUyNCwxMCBAQCBzdGF0aWMgdm9pZCBwYXJzZV9ldmVudF9sb2df
ZW50cnkoc3RydWN0DQogICAgIH0NCiB9DQogDQotc3RhdGljIHZvaWQgYW1kX2lvbW11X3BhZ2Vf
ZmF1bHQoaW50IGlycSwgdm9pZCAqZGV2X2lkLA0KLSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgc3RydWN0IGNwdV91c2VyX3JlZ3MgKnJlZ3MpDQorc3RhdGljIHZvaWQgX19kb19hbWRfaW9t
bXVfcGFnZV9mYXVsdChzdHJ1Y3QgYW1kX2lvbW11ICppb21tdSkNCiB7DQogICAgIHUzMiBlbnRy
eTsNCiAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsNCi0gICAgc3RydWN0IGFtZF9pb21tdSAqaW9t
bXUgPSBkZXZfaWQ7DQogDQogICAgIHNwaW5fbG9ja19pcnFzYXZlKCZpb21tdS0+bG9jaywgZmxh
Z3MpOw0KICAgICBhbWRfaW9tbXVfcmVhZF9ldmVudF9sb2coaW9tbXUpOw0KQEAgLTU0Niw2ICs1
NDYsNDUgQEAgc3RhdGljIHZvaWQgYW1kX2lvbW11X3BhZ2VfZmF1bHQoaW50IGlycQ0KICAgICBz
cGluX3VubG9ja19pcnFyZXN0b3JlKCZpb21tdS0+bG9jaywgZmxhZ3MpOw0KIH0NCiANCitzdGF0
aWMgdm9pZCBkb19hbWRfaW9tbXVfcGFnZV9mYXVsdCh1bnNpZ25lZCBsb25nIGRhdGEpDQorew0K
KyAgICBzdHJ1Y3QgYW1kX2lvbW11ICppb21tdTsNCisNCisgICAgaWYgKCAhaW9tbXVfZm91bmQo
KSApDQorICAgIHsNCisgICAgICAgIEFNRF9JT01NVV9ERUJVRygibm8gZGV2aWNlIGZvdW5kLCBz
b21ldGhpbmcgbXVzdCBiZSB2ZXJ5IHdyb25nIVxuIik7DQorICAgICAgICByZXR1cm47DQorICAg
IH0NCisNCisgICAgLyoNCisgICAgICogTm8gbWF0dGVyIGZyb20gd2hvbSB0aGUgaW50ZXJydXB0
IGNhbWUgZnJvbSwgY2hlY2sgYWxsIHRoZQ0KKyAgICAgKiBJT01NVXMgcHJlc2VudCBpbiB0aGUg
c3lzdGVtLiBUaGlzIGFsbG93cyBmb3IgaGF2aW5nIGp1c3Qgb25lDQorICAgICAqIHRhc2tsZXQg
KGluc3RlYWQgb2Ygb25lIHBlciBlYWNoIElPTU1VcykgYW5kIHNob3VsZCBiZSBtb3JlIHRoYW4N
CisgICAgICogZmluZSwgY29uc2lkZXJpbmcgaG93IHJhcmUgdGhlIGV2ZW50IG9mIGEgZmF1bHQg
c2hvdWxkIGJlLg0KKyAgICAgKi8NCisgICAgZm9yX2VhY2hfYW1kX2lvbW11ICggaW9tbXUgKQ0K
KyAgICAgICAgX19kb19hbWRfaW9tbXVfcGFnZV9mYXVsdChpb21tdSk7DQorfQ0KKw0KK3N0YXRp
YyB2b2lkIGFtZF9pb21tdV9wYWdlX2ZhdWx0KGludCBpcnEsIHZvaWQgKmRldl9pZCwNCisgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzKQ0KK3sN
CisgICAgdTMyIGVudHJ5Ow0KKyAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KKyAgICBzdHJ1Y3Qg
YW1kX2lvbW11ICppb21tdSA9IGRldl9pZDsNCisNCisgICAgLyogc2lsZW5jZSBpbnRlcnJ1cHRz
LiBUaGUgdGFza2xldCB3aWxsIGVuYWJsZSB0aGVtIGJhY2sgKi8NCisgICAgc3Bpbl9sb2NrX2ly
cXNhdmUoJmlvbW11LT5sb2NrLCBmbGFncyk7DQorICAgIGVudHJ5ID0gcmVhZGwoaW9tbXUtPm1t
aW9fYmFzZSArIElPTU1VX1NUQVRVU19NTUlPX09GRlNFVCk7DQorICAgIGlvbW11X2NsZWFyX2Jp
dCgmZW50cnksIElPTU1VX1NUQVRVU19FVkVOVF9MT0dfSU5UX1NISUZUKTsNCisgICAgd3JpdGVs
KGVudHJ5LCBpb21tdS0+bW1pb19iYXNlK0lPTU1VX1NUQVRVU19NTUlPX09GRlNFVCk7DQorICAg
IHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmlvbW11LT5sb2NrLCBmbGFncyk7DQorDQorICAgIC8q
IEZsYWcgdGhlIHRhc2tsZXQgYXMgcnVubmFibGUgc28gdGhhdCBpdCBjYW4gZXhlY3V0ZSwgY2xl
YXINCisgICAgICogdGhlIGxvZyBhbmQgcmUtZW5hYmxlIGludGVycnVwdHMuICovDQorICAgIHRh
c2tsZXRfc2NoZWR1bGUoJmFtZF9pb21tdV9mYXVsdF90YXNrbGV0KTsNCit9DQorDQogc3RhdGlj
IGludCBfX2luaXQgc2V0X2lvbW11X2ludGVycnVwdF9oYW5kbGVyKHN0cnVjdCBhbWRfaW9tbXUg
KmlvbW11KQ0KIHsNCiAgICAgaW50IGlycSwgcmV0Ow0KQEAgLTg4NCw2ICs5MjMsOCBAQCBpbnQg
X19pbml0IGFtZF9pb21tdV9pbml0KHZvaWQpDQogICAgICAgICBpZiAoIGFtZF9pb21tdV9pbml0
X29uZShpb21tdSkgIT0gMCApDQogICAgICAgICAgICAgZ290byBlcnJvcl9vdXQ7DQogDQorICAg
IHNvZnRpcnFfdGFza2xldF9pbml0KCZhbWRfaW9tbXVfZmF1bHRfdGFza2xldCwgZG9fYW1kX2lv
bW11X3BhZ2VfZmF1bHQsIDApOw0KKw0KICAgICByZXR1cm4gMDsNCiANCiBlcnJvcl9vdXQ6DQo=


--=-UGaeOSSswF4hJv9RKu01--

--=-LgfSLpqc91p9nBEa/n3k
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)

iEYEABECAAYFAk8FwUQACgkQk4XaBE3IOsR1EACbBN3JL7n1IfV8wJc6VBRsXMv4
J7IAn1qLVQ68CTeXGQIgwWMp93UMVDYi
=y6xN
-----END PGP SIGNATURE-----

--=-LgfSLpqc91p9nBEa/n3k--



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

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

--===============2544051390667607061==--



From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:28:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:28:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipEx-0001QV-H4; Thu, 05 Jan 2012 15: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 1RipEv-0001Pu-R3
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:28:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325777279!61289244!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4047 invoked from network); 5 Jan 2012 15:28:00 -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;
	5 Jan 2012 15:28:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9840665"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 15:28:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 15:28: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 1RipEo-0000yp-VQ;
	Thu, 05 Jan 2012 15:28:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RipEo-0000qo-Ut;
	Thu, 05 Jan 2012 15:28:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10639-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 15:28:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10639: 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 10639 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10639/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 10635
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 10635

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    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-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  94180a5a0c7c
baseline version:
 xen                  efaa28639a71

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <haitao.shan@intel.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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:   24455:94180a5a0c7c
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Tue Dec 20 08:21:11 2011 +0100
    
    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>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24454:f2a781ab96ba
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Thu Jan 05 14:35:38 2012 +0000
    
    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>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24453:02b92d035f64
user:        Yongan Liu<Liuyongan@huawei.com>
date:        Thu Jan 05 09:29:59 2012 +0100
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24452:efaa28639a71
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Wed Jan 04 16:12:44 2012 +0000
    
    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>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
========================================
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 Jan 05 15:28:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:28:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipEx-0001QV-H4; Thu, 05 Jan 2012 15: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 1RipEv-0001Pu-R3
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:28:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1325777279!61289244!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4047 invoked from network); 5 Jan 2012 15:28:00 -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;
	5 Jan 2012 15:28:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9840665"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 15:28:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 15:28: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 1RipEo-0000yp-VQ;
	Thu, 05 Jan 2012 15:28:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RipEo-0000qo-Ut;
	Thu, 05 Jan 2012 15:28:18 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10639-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 15:28:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10639: 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 10639 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10639/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops              4 kernel-build              fail REGR. vs. 10635
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 10635

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  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-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-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-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    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-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-win          1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  94180a5a0c7c
baseline version:
 xen                  efaa28639a71

------------------------------------------------------------
People who touched revisions under test:
  Dario Faggioli <dario.faggioli@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Haitao Shan <haitao.shan@intel.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shan Haitao <maillists.shan@gmail.com>
  Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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:   24455:94180a5a0c7c
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Tue Dec 20 08:21:11 2011 +0100
    
    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>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24454:f2a781ab96ba
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Thu Jan 05 14:35:38 2012 +0000
    
    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>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24453:02b92d035f64
user:        Yongan Liu<Liuyongan@huawei.com>
date:        Thu Jan 05 09:29:59 2012 +0100
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    
    
changeset:   24452:efaa28639a71
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Wed Jan 04 16:12:44 2012 +0000
    
    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>
    Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
========================================
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 Jan 05 15:30:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipH2-0001eh-8I; Thu, 05 Jan 2012 15:30:36 +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 1RipH0-0001dv-9o
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:30:34 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1325777426!9851860!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 23357 invoked from network); 5 Jan 2012 15:30:27 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.12)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Jan 2012 15:30:27 -0000
Received: from mail177-tx2-R.bigfish.com (10.9.14.252) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:30:25 +0000
Received: from mail177-tx2 (localhost [127.0.0.1])	by
	mail177-tx2-R.bigfish.com (Postfix) with ESMTP id B81743A0252	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:30:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bh8275dhz2dh668h839h34h61h)
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,0,
Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2
	(MessageSwitch) id 1325777411530922_10820;
	Thu,  5 Jan 2012 15:30:11 +0000 (UTC)
Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.244])	by
	mail177-tx2.bigfish.com (Postfix) with ESMTP id 7199C2005D	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:30:11 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:30:10 +0000
X-WSS-ID: 0LXC0E6-01-GXP-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 235421028028	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 09:30:05 -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, 5 Jan 2012 09:30:21 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 5 Jan 2012 09:30:05 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	10:30:05 -0500
Message-ID: <4F05C1FC.2090803@amd.com>
Date: Thu, 5 Jan 2012 16:30:04 +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="------------010801080300090401060904"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: build fix with gcc 4.5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010801080300090401060904
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Fix build failure with gcc 4.5:
implicit declaration of __builtin_stdarg_start

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
From: David Brownlee <abs@netbsd.org>

Please also apply this to xen-4.1-testing.

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

--------------010801080300090401060904
Content-Type: text/plain; name="xen_stdarg.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_stdarg.diff"
Content-Description: xen_stdarg.diff

diff -r 9a84303b600c xen/include/xen/stdarg.h
--- a/xen/include/xen/stdarg.h	Thu Jan 05 14:46:28 2012 +0100
+++ b/xen/include/xen/stdarg.h	Thu Jan 05 16:15:47 2012 +0100
@@ -5,7 +5,17 @@
 #  include "/usr/include/stdarg.h"
 #elif defined (__NetBSD__)
    typedef __builtin_va_list va_list;
-#  define va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#  ifdef __GNUC__
+#    define __GNUC_PREREQ__(x, y)                                       \
+        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
+         (__GNUC__ > (x)))
+#  else
+#    define __GNUC_PREREQ__(x, y)   0
+#  endif
+#  if !__GNUC_PREREQ__(4, 5)
+#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#  endif
+#  define va_start(ap, last)    __builtin_va_start((ap), (last))
 #  define va_end(ap)            __builtin_va_end(ap)
 #  define va_arg                __builtin_va_arg
 #else

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

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

--------------010801080300090401060904--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:30:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:30:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipH2-0001eh-8I; Thu, 05 Jan 2012 15:30:36 +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 1RipH0-0001dv-9o
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:30:34 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1325777426!9851860!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 23357 invoked from network); 5 Jan 2012 15:30:27 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.12)
	by server-8.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Jan 2012 15:30:27 -0000
Received: from mail177-tx2-R.bigfish.com (10.9.14.252) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:30:25 +0000
Received: from mail177-tx2 (localhost [127.0.0.1])	by
	mail177-tx2-R.bigfish.com (Postfix) with ESMTP id B81743A0252	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:30:25 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bh8275dhz2dh668h839h34h61h)
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,0,
Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2
	(MessageSwitch) id 1325777411530922_10820;
	Thu,  5 Jan 2012 15:30:11 +0000 (UTC)
Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.244])	by
	mail177-tx2.bigfish.com (Postfix) with ESMTP id 7199C2005D	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:30:11 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:30:10 +0000
X-WSS-ID: 0LXC0E6-01-GXP-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 235421028028	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 09:30:05 -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, 5 Jan 2012 09:30:21 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Thu, 5 Jan 2012 09:30:05 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	10:30:05 -0500
Message-ID: <4F05C1FC.2090803@amd.com>
Date: Thu, 5 Jan 2012 16:30:04 +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="------------010801080300090401060904"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: build fix with gcc 4.5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010801080300090401060904
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Fix build failure with gcc 4.5:
implicit declaration of __builtin_stdarg_start

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
From: David Brownlee <abs@netbsd.org>

Please also apply this to xen-4.1-testing.

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

--------------010801080300090401060904
Content-Type: text/plain; name="xen_stdarg.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_stdarg.diff"
Content-Description: xen_stdarg.diff

diff -r 9a84303b600c xen/include/xen/stdarg.h
--- a/xen/include/xen/stdarg.h	Thu Jan 05 14:46:28 2012 +0100
+++ b/xen/include/xen/stdarg.h	Thu Jan 05 16:15:47 2012 +0100
@@ -5,7 +5,17 @@
 #  include "/usr/include/stdarg.h"
 #elif defined (__NetBSD__)
    typedef __builtin_va_list va_list;
-#  define va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#  ifdef __GNUC__
+#    define __GNUC_PREREQ__(x, y)                                       \
+        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
+         (__GNUC__ > (x)))
+#  else
+#    define __GNUC_PREREQ__(x, y)   0
+#  endif
+#  if !__GNUC_PREREQ__(4, 5)
+#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#  endif
+#  define va_start(ap, last)    __builtin_va_start((ap), (last))
 #  define va_end(ap)            __builtin_va_end(ap)
 #  define va_arg                __builtin_va_arg
 #else

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

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

--------------010801080300090401060904--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:40:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15: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 1RipPs-00023H-CD; Thu, 05 Jan 2012 15:39:44 +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 1RipPq-00023C-83
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:39:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325777975!10628325!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 7827 invoked from network); 5 Jan 2012 15:39:35 -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;
	5 Jan 2012 15:39:35 -0000
Received: by wico1 with SMTP id o1so1267851wic.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 07:39:35 -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=A5FOTRKzKEHjgFeyP5oj+sfo5Yj12MY8w2JRgkqynhc=;
	b=SJLEid7Xc21rWeJ0usfFGSFwtSeIboMy+Af650hgRqIjLKezVeY+7UC1UFquDaw/bZ
	pfmBH+RyF7gEqHX0c4UNxItGm8xi6Y9zYRaRR3FYlTCcivwKEqbDCsbFInucVdY/PaYw
	wf5N/0M5dM4TKNox2LXsNjtDzlUavRPv7f8sQ=
Received: by 10.181.13.162 with SMTP id ez2mr4855617wid.17.1325777975227;
	Thu, 05 Jan 2012 07:39:35 -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 n3sm18268737wiz.9.2012.01.05.07.39.33
	(version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 07:39:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 05 Jan 2012 15:39:27 +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: <CB2B74AF.36EA9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xen: build fix with gcc 4.5
Thread-Index: AczLwDT8jLh+OYfewkmrVL/5P32dfA==
In-Reply-To: <4F05C1FC.2090803@amd.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] xen: build fix with gcc 4.5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 15:30, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> 
> Fix build failure with gcc 4.5:
> implicit declaration of __builtin_stdarg_start
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> From: David Brownlee <abs@netbsd.org>

Can you please put netbsd in the comment header for netbsd-specific changes?

 -- Keir

> Please also apply this to xen-4.1-testing.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:40:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15: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 1RipPs-00023H-CD; Thu, 05 Jan 2012 15:39:44 +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 1RipPq-00023C-83
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:39:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325777975!10628325!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 7827 invoked from network); 5 Jan 2012 15:39:35 -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;
	5 Jan 2012 15:39:35 -0000
Received: by wico1 with SMTP id o1so1267851wic.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 07:39:35 -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=A5FOTRKzKEHjgFeyP5oj+sfo5Yj12MY8w2JRgkqynhc=;
	b=SJLEid7Xc21rWeJ0usfFGSFwtSeIboMy+Af650hgRqIjLKezVeY+7UC1UFquDaw/bZ
	pfmBH+RyF7gEqHX0c4UNxItGm8xi6Y9zYRaRR3FYlTCcivwKEqbDCsbFInucVdY/PaYw
	wf5N/0M5dM4TKNox2LXsNjtDzlUavRPv7f8sQ=
Received: by 10.181.13.162 with SMTP id ez2mr4855617wid.17.1325777975227;
	Thu, 05 Jan 2012 07:39:35 -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 n3sm18268737wiz.9.2012.01.05.07.39.33
	(version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 07:39:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 05 Jan 2012 15:39:27 +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: <CB2B74AF.36EA9%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xen: build fix with gcc 4.5
Thread-Index: AczLwDT8jLh+OYfewkmrVL/5P32dfA==
In-Reply-To: <4F05C1FC.2090803@amd.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] xen: build fix with gcc 4.5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 15:30, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> 
> Fix build failure with gcc 4.5:
> implicit declaration of __builtin_stdarg_start
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
> From: David Brownlee <abs@netbsd.org>

Can you please put netbsd in the comment header for netbsd-specific changes?

 -- Keir

> Please also apply this to xen-4.1-testing.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:48:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:48:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipYJ-0002QL-3r; Thu, 05 Jan 2012 15:48:27 +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 1RipYH-0002Q8-96
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:48:25 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325778497!7971222!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 13103 invoked from network); 5 Jan 2012 15:48:18 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-10.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Jan 2012 15:48:18 -0000
Received: from mail139-tx2-R.bigfish.com (10.9.14.250) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:48:16 +0000
Received: from mail139-tx2 (localhost [127.0.0.1])	by
	mail139-tx2-R.bigfish.com (Postfix) with ESMTP id A565618050D	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:48:16 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bh8275dhz2dh668h839h34h61h)
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 mail139-tx2 (localhost.localdomain [127.0.0.1]) by mail139-tx2
	(MessageSwitch) id 1325778496411100_12457;
	Thu,  5 Jan 2012 15:48:16 +0000 (UTC)
Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.244])	by
	mail139-tx2.bigfish.com (Postfix) with ESMTP id 55E92340043	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:48:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:48:14 +0000
X-WSS-ID: 0LXC18C-02-I81-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 216E1C801A	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 09:48:12 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 5 Jan 2012 09:48:28 -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;
	Thu, 5 Jan 2012 09:48:13 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	10:48:12 -0500
Message-ID: <4F05C63B.8030409@amd.com>
Date: Thu, 5 Jan 2012 16:48:11 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F05C1FC.2090803@amd.com>
In-Reply-To: <4F05C1FC.2090803@amd.com>
Content-Type: multipart/mixed; boundary="------------070405020704090205060306"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: build fix with gcc 4.5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------070405020704090205060306
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit

Fix build failure with gcc 4.5 on NetBSD:
implicit declaration of __builtin_stdarg_start

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
From: David Brownlee <abs@netbsd.org>

Please also apply this to xen-4.1-testing.

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

--------------070405020704090205060306
Content-Type: text/plain; name="xen_stdarg.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_stdarg.diff"
Content-Description: xen_stdarg.diff

diff -r 9a84303b600c xen/include/xen/stdarg.h
--- a/xen/include/xen/stdarg.h	Thu Jan 05 14:46:28 2012 +0100
+++ b/xen/include/xen/stdarg.h	Thu Jan 05 16:15:47 2012 +0100
@@ -5,7 +5,17 @@
 #  include "/usr/include/stdarg.h"
 #elif defined (__NetBSD__)
    typedef __builtin_va_list va_list;
-#  define va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#  ifdef __GNUC__
+#    define __GNUC_PREREQ__(x, y)                                       \
+        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
+         (__GNUC__ > (x)))
+#  else
+#    define __GNUC_PREREQ__(x, y)   0
+#  endif
+#  if !__GNUC_PREREQ__(4, 5)
+#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#  endif
+#  define va_start(ap, last)    __builtin_va_start((ap), (last))
 #  define va_end(ap)            __builtin_va_end(ap)
 #  define va_arg                __builtin_va_arg
 #else

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

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

--------------070405020704090205060306--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:48:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:48:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipYJ-0002QL-3r; Thu, 05 Jan 2012 15:48:27 +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 1RipYH-0002Q8-96
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:48:25 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325778497!7971222!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 13103 invoked from network); 5 Jan 2012 15:48:18 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-10.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Jan 2012 15:48:18 -0000
Received: from mail139-tx2-R.bigfish.com (10.9.14.250) by
	TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:48:16 +0000
Received: from mail139-tx2 (localhost [127.0.0.1])	by
	mail139-tx2-R.bigfish.com (Postfix) with ESMTP id A565618050D	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:48:16 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bh8275dhz2dh668h839h34h61h)
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 mail139-tx2 (localhost.localdomain [127.0.0.1]) by mail139-tx2
	(MessageSwitch) id 1325778496411100_12457;
	Thu,  5 Jan 2012 15:48:16 +0000 (UTC)
Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.244])	by
	mail139-tx2.bigfish.com (Postfix) with ESMTP id 55E92340043	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:48:16 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:48:14 +0000
X-WSS-ID: 0LXC18C-02-I81-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 216E1C801A	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 09:48:12 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 5 Jan 2012 09:48:28 -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;
	Thu, 5 Jan 2012 09:48:13 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	10:48:12 -0500
Message-ID: <4F05C63B.8030409@amd.com>
Date: Thu, 5 Jan 2012 16:48:11 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F05C1FC.2090803@amd.com>
In-Reply-To: <4F05C1FC.2090803@amd.com>
Content-Type: multipart/mixed; boundary="------------070405020704090205060306"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: build fix with gcc 4.5
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------070405020704090205060306
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit

Fix build failure with gcc 4.5 on NetBSD:
implicit declaration of __builtin_stdarg_start

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
From: David Brownlee <abs@netbsd.org>

Please also apply this to xen-4.1-testing.

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

--------------070405020704090205060306
Content-Type: text/plain; name="xen_stdarg.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_stdarg.diff"
Content-Description: xen_stdarg.diff

diff -r 9a84303b600c xen/include/xen/stdarg.h
--- a/xen/include/xen/stdarg.h	Thu Jan 05 14:46:28 2012 +0100
+++ b/xen/include/xen/stdarg.h	Thu Jan 05 16:15:47 2012 +0100
@@ -5,7 +5,17 @@
 #  include "/usr/include/stdarg.h"
 #elif defined (__NetBSD__)
    typedef __builtin_va_list va_list;
-#  define va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#  ifdef __GNUC__
+#    define __GNUC_PREREQ__(x, y)                                       \
+        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
+         (__GNUC__ > (x)))
+#  else
+#    define __GNUC_PREREQ__(x, y)   0
+#  endif
+#  if !__GNUC_PREREQ__(4, 5)
+#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#  endif
+#  define va_start(ap, last)    __builtin_va_start((ap), (last))
 #  define va_end(ap)            __builtin_va_end(ap)
 #  define va_arg                __builtin_va_arg
 #else

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

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

--------------070405020704090205060306--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:50:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipZu-0002We-Jr; Thu, 05 Jan 2012 15:50:06 +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 1RipZs-0002WB-Ty
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:50:05 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325778598!9896119!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 24954 invoked from network); 5 Jan 2012 15:49:59 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 15:49:59 -0000
Received: by wico1 with SMTP id o1so1286630wic.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 07:49:58 -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=SoWBgkb6ZVl6xTIdtmnBffEWTu0AAUWoo3mP5DJHu5o=;
	b=ZY6mrmg6ddTkzdYSPj2rD86PFWQ8BGZpQXdiCQPuOEBykmDJpQWj+r9o5irHL4GvU5
	jKMUsyqeBG9WRhWrAIQBIMvFglIVX6X8ty2c2fsNS25Raol/1m8ilw05a+WVIK4Mm4ev
	Iv/0KXtXcmqvRSYTYLeAz8IYQE9v8V+RLqjwM=
Received: by 10.180.94.97 with SMTP id db1mr4924584wib.16.1325778598876;
	Thu, 05 Jan 2012 07:49:58 -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 f36sm21512655wbo.10.2012.01.05.07.49.57
	(version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 07:49:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 05 Jan 2012 15:49:55 +0000
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB2B7723.36EB2%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: emulate lea with two register operands
	correctly
Thread-Index: AczLwatN15hVb5RJKEarRSsF+GJ6RQ==
In-Reply-To: <e25b7798f13ba47f5325.1325775781@qabil.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: emulate lea with two register operands
 correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 15:03, "David Vrabel" <david.vrabel@citrix.com> wrote:

> An lea instruction with two register operands should raise an
> undefined instruction exception.
> 
> Skype does such a instruction and will crash when starting if it does
> not get the exception.

Thanks. I think it is a little nicer to check ea.type != OP_MEM, so I made
that change before committing this patch. It's now in xen-unstable staging.

It's a bit concerning that we're emulating LEA at all, perhaps. I wonder if
a pagetable page has been reused as a code page and we didn't notice yet? Or
is there some other reason that skype is getting emulated? :-)

 -- Keir

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> diff -r efaa28639a71 -r e25b7798f13b xen/arch/x86/x86_emulate/x86_emulate.c
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Thu Jan 05 14:58:56 2012 +0000
> @@ -2240,6 +2240,7 @@ x86_emulate(
>      }
>  
>      case 0x8d: /* lea */
> +        generate_exception_if(modrm_mod == 3, EXC_UD, -1);
>          dst.val = ea.mem.off;
>          break;
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 05 15:50:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RipZu-0002We-Jr; Thu, 05 Jan 2012 15:50:06 +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 1RipZs-0002WB-Ty
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:50:05 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325778598!9896119!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 24954 invoked from network); 5 Jan 2012 15:49:59 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 15:49:59 -0000
Received: by wico1 with SMTP id o1so1286630wic.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 07:49:58 -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=SoWBgkb6ZVl6xTIdtmnBffEWTu0AAUWoo3mP5DJHu5o=;
	b=ZY6mrmg6ddTkzdYSPj2rD86PFWQ8BGZpQXdiCQPuOEBykmDJpQWj+r9o5irHL4GvU5
	jKMUsyqeBG9WRhWrAIQBIMvFglIVX6X8ty2c2fsNS25Raol/1m8ilw05a+WVIK4Mm4ev
	Iv/0KXtXcmqvRSYTYLeAz8IYQE9v8V+RLqjwM=
Received: by 10.180.94.97 with SMTP id db1mr4924584wib.16.1325778598876;
	Thu, 05 Jan 2012 07:49:58 -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 f36sm21512655wbo.10.2012.01.05.07.49.57
	(version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 07:49:58 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 05 Jan 2012 15:49:55 +0000
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB2B7723.36EB2%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: emulate lea with two register operands
	correctly
Thread-Index: AczLwatN15hVb5RJKEarRSsF+GJ6RQ==
In-Reply-To: <e25b7798f13ba47f5325.1325775781@qabil.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: emulate lea with two register operands
 correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 15:03, "David Vrabel" <david.vrabel@citrix.com> wrote:

> An lea instruction with two register operands should raise an
> undefined instruction exception.
> 
> Skype does such a instruction and will crash when starting if it does
> not get the exception.

Thanks. I think it is a little nicer to check ea.type != OP_MEM, so I made
that change before committing this patch. It's now in xen-unstable staging.

It's a bit concerning that we're emulating LEA at all, perhaps. I wonder if
a pagetable page has been reused as a code page and we didn't notice yet? Or
is there some other reason that skype is getting emulated? :-)

 -- Keir

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> 
> diff -r efaa28639a71 -r e25b7798f13b xen/arch/x86/x86_emulate/x86_emulate.c
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Thu Jan 05 14:58:56 2012 +0000
> @@ -2240,6 +2240,7 @@ x86_emulate(
>      }
>  
>      case 0x8d: /* lea */
> +        generate_exception_if(modrm_mod == 3, EXC_UD, -1);
>          dst.val = ea.mem.off;
>          break;
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 05 15:51:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:51:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ripas-0002br-2t; Thu, 05 Jan 2012 15:51:06 +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 1Ripaq-0002bX-OH
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:51:04 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325778657!7946080!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27838 invoked from network); 5 Jan 2012 15:50:58 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.13)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Jan 2012 15:50:58 -0000
Received: from mail176-tx2-R.bigfish.com (10.9.14.237) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:50:56 +0000
Received: from mail176-tx2 (localhost [127.0.0.1])	by
	mail176-tx2-R.bigfish.com (Postfix) with ESMTP id AB9BF2C0400	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:50:56 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzzz2dh668h839h66h)
X-Spam-TCS-SCL: 5: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 mail176-tx2 (localhost.localdomain [127.0.0.1]) by mail176-tx2
	(MessageSwitch) id 1325778656519234_31596;
	Thu,  5 Jan 2012 15:50:56 +0000 (UTC)
Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.247])	by
	mail176-tx2.bigfish.com (Postfix) with ESMTP id 7038322004A	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:50:56 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:50:54 +0000
X-WSS-ID: 0LXC1CT-01-IKW-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 219C5102802B	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 09:50:52 -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, 5 Jan 2012 09:51:09 -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, 5 Jan 2012 09:50:53 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	10:50:52 -0500
Message-ID: <4F05C6DB.2090207@amd.com>
Date: Thu, 5 Jan 2012 16:50:51 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] x11 header check still needed?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

is the x11 header check in tools/check/ still needed?

On NetBSD it is superflous and can be removed.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:51:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:51:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ripas-0002br-2t; Thu, 05 Jan 2012 15:51:06 +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 1Ripaq-0002bX-OH
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:51:04 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325778657!7946080!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27838 invoked from network); 5 Jan 2012 15:50:58 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.13)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	5 Jan 2012 15:50:58 -0000
Received: from mail176-tx2-R.bigfish.com (10.9.14.237) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:50:56 +0000
Received: from mail176-tx2 (localhost [127.0.0.1])	by
	mail176-tx2-R.bigfish.com (Postfix) with ESMTP id AB9BF2C0400	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:50:56 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzzz2dh668h839h66h)
X-Spam-TCS-SCL: 5: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 mail176-tx2 (localhost.localdomain [127.0.0.1]) by mail176-tx2
	(MessageSwitch) id 1325778656519234_31596;
	Thu,  5 Jan 2012 15:50:56 +0000 (UTC)
Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.247])	by
	mail176-tx2.bigfish.com (Postfix) with ESMTP id 7038322004A	for
	<xen-devel@lists.xensource.com>; Thu,  5 Jan 2012 15:50:56 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server id
	14.1.225.23; Thu, 5 Jan 2012 15:50:54 +0000
X-WSS-ID: 0LXC1CT-01-IKW-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 219C5102802B	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 09:50:52 -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, 5 Jan 2012 09:51:09 -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, 5 Jan 2012 09:50:53 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	10:50:52 -0500
Message-ID: <4F05C6DB.2090207@amd.com>
Date: Thu, 5 Jan 2012 16:50:51 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] x11 header check still needed?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

is the x11 header check in tools/check/ still needed?

On NetBSD it is superflous and can be removed.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:54:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ripdy-0002sI-Ms; Thu, 05 Jan 2012 15:54:18 +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 1Ripdx-0002rZ-2D
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:54:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325778850!7267306!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18015 invoked from network); 5 Jan 2012 15:54:10 -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;
	5 Jan 2012 15:54:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9841337"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 15:54: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, 5 Jan 2012 15:54:09 +0000
Date: Thu, 5 Jan 2012 15:53:57 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F05BF9E.7000203@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051536290.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Thu, 5 Jan 2012, Avi Kivity wrote:
> > If the MemoryRegions are re-created by the devices, then we need another
> > mechanism to find out where the videoram is.
> > What I am saying is that the suggestion of having a xen_address field
> > for every MemoryRegion would make the code cleaner but it would not
> > solve the save/restore issue described in the previous email.
> 
> Okay, I think I understand now.
> 
> You're not really allocating memory on restore, you're attaching to
> already allocated memory, and you need a handle to it, passed from the
> save side.

Right


> One way is to add early-save/restore like you suggest.  Another is to
> make the attach late.  Can we defer it until after restore is complete
> and we know everything?

If it could be done, it would probably be a better solution, but I am
not so sure about the actual feasibility.


> This involves:
> - adding vmstate to xen-all.c so it can migrate the xen vram address

Easy so far.


> - making sure the memory core doesn't do mappings during restore (can be
> done by wrapping restore with
> memory_region_transaction_begin()/memory_region_transaction_commit();
> beneficial to normal qemu migrations as well)

Besides restore we would also need to wrap machine->init() with
memory_region_transaction_begin()/memory_region_transaction_commit(),
so that all the mappings are only done at the end of restore, when we do
know the videoram address.

This seems unfeasable to me: what about all the addresses set in the
meantime using memory_region_get_ram_ptr()?
For example s->vram_ptr set by vga_common_init during machine->init()?
If the actual memory is only allocated at the end of restore, vram_ptr
would be bogus at least until then and we would still need a way to
update it afterwards.

BTW what you are suggesting is not so different from what was done by
Anthony in the last patch series he sent. See the following (ugly) patch
to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
completed and then update the pointer:

http://marc.info/?l=qemu-devel&m=132346828427314&w=2


> - updating the mapped address during restore
> 
> I think this is cleaner than introducing a new migration stage, but the
> implementation may prove otherwise.

see patch above, a good summary of the difficulties of this approach


> > > xen_register_framebuffer() is slightly less hacky.
> >
> > I agree, however xen_register_framebuffer is called after
> > memory_region_init_ram, so the allocation would have been made already.
> 
> xen_ram_alloc(MemoryRegion *mr)
> {
>     if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
>         return;
>     }
> }
> 
> xen_framebuffer_address_post_load()
> {
>     framebuffer_addr_known = true;
>     if (framebuffer) {
>         framebuffer->xen_address = framebuffer_addr;
>     }
> }
> 
> (ugly way of avoiding a dependency, but should work)
 
The issue is that xen_ram_alloc is called by memory_region_init_ram
before xen_register_framebuffer is called (see the order of calls in
vga_common_init).
So when xen_ram_alloc is called framebuffer is still NULL: mr !=
framebuffer.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 15:54:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 15:54:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ripdy-0002sI-Ms; Thu, 05 Jan 2012 15:54:18 +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 1Ripdx-0002rZ-2D
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:54:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325778850!7267306!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18015 invoked from network); 5 Jan 2012 15:54:10 -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;
	5 Jan 2012 15:54:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9841337"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 15:54: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, 5 Jan 2012 15:54:09 +0000
Date: Thu, 5 Jan 2012 15:53:57 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F05BF9E.7000203@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051536290.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Thu, 5 Jan 2012, Avi Kivity wrote:
> > If the MemoryRegions are re-created by the devices, then we need another
> > mechanism to find out where the videoram is.
> > What I am saying is that the suggestion of having a xen_address field
> > for every MemoryRegion would make the code cleaner but it would not
> > solve the save/restore issue described in the previous email.
> 
> Okay, I think I understand now.
> 
> You're not really allocating memory on restore, you're attaching to
> already allocated memory, and you need a handle to it, passed from the
> save side.

Right


> One way is to add early-save/restore like you suggest.  Another is to
> make the attach late.  Can we defer it until after restore is complete
> and we know everything?

If it could be done, it would probably be a better solution, but I am
not so sure about the actual feasibility.


> This involves:
> - adding vmstate to xen-all.c so it can migrate the xen vram address

Easy so far.


> - making sure the memory core doesn't do mappings during restore (can be
> done by wrapping restore with
> memory_region_transaction_begin()/memory_region_transaction_commit();
> beneficial to normal qemu migrations as well)

Besides restore we would also need to wrap machine->init() with
memory_region_transaction_begin()/memory_region_transaction_commit(),
so that all the mappings are only done at the end of restore, when we do
know the videoram address.

This seems unfeasable to me: what about all the addresses set in the
meantime using memory_region_get_ram_ptr()?
For example s->vram_ptr set by vga_common_init during machine->init()?
If the actual memory is only allocated at the end of restore, vram_ptr
would be bogus at least until then and we would still need a way to
update it afterwards.

BTW what you are suggesting is not so different from what was done by
Anthony in the last patch series he sent. See the following (ugly) patch
to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
completed and then update the pointer:

http://marc.info/?l=qemu-devel&m=132346828427314&w=2


> - updating the mapped address during restore
> 
> I think this is cleaner than introducing a new migration stage, but the
> implementation may prove otherwise.

see patch above, a good summary of the difficulties of this approach


> > > xen_register_framebuffer() is slightly less hacky.
> >
> > I agree, however xen_register_framebuffer is called after
> > memory_region_init_ram, so the allocation would have been made already.
> 
> xen_ram_alloc(MemoryRegion *mr)
> {
>     if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
>         return;
>     }
> }
> 
> xen_framebuffer_address_post_load()
> {
>     framebuffer_addr_known = true;
>     if (framebuffer) {
>         framebuffer->xen_address = framebuffer_addr;
>     }
> }
> 
> (ugly way of avoiding a dependency, but should work)
 
The issue is that xen_ram_alloc is called by memory_region_init_ram
before xen_register_framebuffer is called (see the order of calls in
vga_common_init).
So when xen_ram_alloc is called framebuffer is still NULL: mr !=
framebuffer.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:07:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16:07:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ripq7-0003vB-Lz; Thu, 05 Jan 2012 16:06:51 +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 1Ripq6-0003uv-Nr
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:06:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325779603!7936151!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 4141 invoked from network); 5 Jan 2012 16:06:44 -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; 5 Jan 2012 16:06:44 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rippx-000OHQ-JV; Thu, 05 Jan 2012 16:06:41 +0000
Date: Thu, 5 Jan 2012 16:06:41 +0000
From: Tim Deegan <tim@xen.org>
To: Keir Fraser <keir@xen.org>
Message-ID: <20120105160641.GB87519@ocelot.phlegethon.org>
References: <e25b7798f13ba47f5325.1325775781@qabil.uk.xensource.com>
	<CB2B7723.36EB2%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CB2B7723.36EB2%keir@xen.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86: emulate lea with two register operands
	correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:49 +0000 on 05 Jan (1325778595), Keir Fraser wrote:
> On 05/01/2012 15:03, "David Vrabel" <david.vrabel@citrix.com> wrote:
> 
> > An lea instruction with two register operands should raise an
> > undefined instruction exception.
> > 
> > Skype does such a instruction and will crash when starting if it does
> > not get the exception.
> 
> Thanks. I think it is a little nicer to check ea.type != OP_MEM, so I made
> that change before committing this patch. It's now in xen-unstable staging.
> 
> It's a bit concerning that we're emulating LEA at all, perhaps. I wonder if
> a pagetable page has been reused as a code page and we didn't notice yet? Or
> is there some other reason that skype is getting emulated? :-)

#UD exceptions in HVM are passed to the emulator (IIRC as part of the
cross-vendor migration patches, so SYSENTER & friends could be managed).

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:07:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16:07:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ripq7-0003vB-Lz; Thu, 05 Jan 2012 16:06:51 +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 1Ripq6-0003uv-Nr
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:06:50 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325779603!7936151!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 4141 invoked from network); 5 Jan 2012 16:06:44 -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; 5 Jan 2012 16:06:44 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rippx-000OHQ-JV; Thu, 05 Jan 2012 16:06:41 +0000
Date: Thu, 5 Jan 2012 16:06:41 +0000
From: Tim Deegan <tim@xen.org>
To: Keir Fraser <keir@xen.org>
Message-ID: <20120105160641.GB87519@ocelot.phlegethon.org>
References: <e25b7798f13ba47f5325.1325775781@qabil.uk.xensource.com>
	<CB2B7723.36EB2%keir@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CB2B7723.36EB2%keir@xen.org>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86: emulate lea with two register operands
	correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:49 +0000 on 05 Jan (1325778595), Keir Fraser wrote:
> On 05/01/2012 15:03, "David Vrabel" <david.vrabel@citrix.com> wrote:
> 
> > An lea instruction with two register operands should raise an
> > undefined instruction exception.
> > 
> > Skype does such a instruction and will crash when starting if it does
> > not get the exception.
> 
> Thanks. I think it is a little nicer to check ea.type != OP_MEM, so I made
> that change before committing this patch. It's now in xen-unstable staging.
> 
> It's a bit concerning that we're emulating LEA at all, perhaps. I wonder if
> a pagetable page has been reused as a code page and we didn't notice yet? Or
> is there some other reason that skype is getting emulated? :-)

#UD exceptions in HVM are passed to the emulator (IIRC as part of the
cross-vendor migration patches, so SYSENTER & friends could be managed).

Tim.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:17:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16: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 1Riq0J-0004ZK-Nb; Thu, 05 Jan 2012 16:17:23 +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 1Riq0I-0004Z9-Fi
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:17:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325780235!7982181!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg4MjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7080 invoked from network); 5 Jan 2012 16:17:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 16:17:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320642000"; d="scan'208";a="176413782"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 11:17:14 -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, 5 Jan 2012
	11:17:14 -0500
Message-ID: <4F05CD09.4020503@citrix.com>
Date: Thu, 5 Jan 2012 16:17:13 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CB2B7723.36EB2%keir@xen.org>
In-Reply-To: <CB2B7723.36EB2%keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: emulate lea with two register operands
 correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/12 15:49, Keir Fraser wrote:
> On 05/01/2012 15:03, "David Vrabel" <david.vrabel@citrix.com> wrote:
> 
>> An lea instruction with two register operands should raise an
>> undefined instruction exception.
>>
>> Skype does such a instruction and will crash when starting if it does
>> not get the exception.
> 
> Thanks. I think it is a little nicer to check ea.type != OP_MEM, so I made
> that change before committing this patch. It's now in xen-unstable staging.

That works for me, thanks.

I also think this patch should be a 4.1 candidate.

David

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:17:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16: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 1Riq0J-0004ZK-Nb; Thu, 05 Jan 2012 16:17:23 +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 1Riq0I-0004Z9-Fi
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:17:22 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325780235!7982181!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjg4MjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7080 invoked from network); 5 Jan 2012 16:17:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 16:17:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320642000"; d="scan'208";a="176413782"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 11:17:14 -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, 5 Jan 2012
	11:17:14 -0500
Message-ID: <4F05CD09.4020503@citrix.com>
Date: Thu, 5 Jan 2012 16:17:13 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CB2B7723.36EB2%keir@xen.org>
In-Reply-To: <CB2B7723.36EB2%keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: emulate lea with two register operands
 correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/12 15:49, Keir Fraser wrote:
> On 05/01/2012 15:03, "David Vrabel" <david.vrabel@citrix.com> wrote:
> 
>> An lea instruction with two register operands should raise an
>> undefined instruction exception.
>>
>> Skype does such a instruction and will crash when starting if it does
>> not get the exception.
> 
> Thanks. I think it is a little nicer to check ea.type != OP_MEM, so I made
> that change before committing this patch. It's now in xen-unstable staging.

That works for me, thanks.

I also think this patch should be a 4.1 candidate.

David

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:19:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riq1l-0004dw-79; Thu, 05 Jan 2012 16:18:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Riq1j-0004dY-Om
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325780325!7792921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13690 invoked from network); 5 Jan 2012 16:18:45 -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;
	5 Jan 2012 16:18:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9841938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 16:18: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, 5 Jan 2012
	16:18:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David TECHER <davidtecher@yahoo.fr>
Date: Thu, 5 Jan 2012 16:18:44 +0000
In-Reply-To: <1325770888.57253.YahooMailNeo@web29803.mail.ird.yahoo.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
	<1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<1325769910.25206.373.camel@zakaz.uk.xensource.com>
	<1325770888.57253.YahooMailNeo@web29803.mail.ird.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325780324.25206.401.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Huang <wei.huang2@amd.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDEyLTAxLTA1IGF0IDEzOjQxICswMDAwLCBEYXZpZCBURUNIRVIgd3JvdGU6Cj4g
SWFuCj4gCj4gCj4gSSB3aWxsIHRyeSB0byBzdWJtaXQgdGhlIHBhdGNoIHRvbmlnaHQgd2hlbiBJ
IGFtIGF0IGhvbWUgKEkgYW0gaW4KPiBGcmFuY2UgLSBDLkUuVCkgZWxzZSB5b3UgY2FuIGRvd25s
b2FkIHBhdGNoZXMgYXQKPiBodHRwOi8vd3d3LmRhdmlkZ2lzLmZyL2Rvd25sb2FkL3hlbi00LjJf
cmV2MjQyMzJfZ2Z4LXBhc3N0aHJvdWdoLXBhdGNocy50YXIuYnoyCgpUaGFua3MsIEknbSBub3Qg
YWN0dWFsbHkgaW50ZXJlc3RlZCBpbiB0aGlzIGZ1bmN0aW9uYWxpdHkgbXlzZWxmIC0tIEkKanVz
dCB3YW50ZWQgdG8gZW5jb3VyYWdlIHRoZWlyIHN1Ym1pc3Npb24gdXBzdHJlYW0gc2luY2Ugb3Ro
ZXJzIHNlZW0gdG8Kd2FudCB0aGVtLgoKPiBGb3IgeW91ciBpbmZvcm1hdGlvbiBhbmQgYXMgaXQg
aXMgd3JpdHR0ZW4gaW4gbXkgYXJ0aWNsZSwgSSBhbSBub3QgdGhlCj4gYXV0aG9yIG9mIHRoZSBw
YXRjaGVzLCBqdXN0IGEgc2ltcGxlIG1haW50YWluZXIuCgpUaGVuIHRoZXJlIGlzIG9uZSBhZGRp
dGlvbmFsIHdyaW5rbGUgb3ZlciBhbmQgYWJvdmUgd2hhdCBpcyBkZXNjcmliZWQgaW4KdGhlIFN1
Ym1pdHRpbmdYZW5QYXRjaGVzIHdpa2kgcGFnZSwgeW91IHNob3VsZCBpbmNsdWRlIGEgIlNpZ25l
ZC1vZmYtYnkiCmZyb20gdGhlIG9yaWdpbmFsIGF1dGhvciBhYm92ZSB5b3VyIG93bi4KCkhvcGVm
dWxseSB0aGV5IGluY2x1ZGVkIG9uZSB3aGVuIHRoZXkgb3JpZ2luYWxseSBwb3N0ZWQgdGhlIHBh
dGNoLCBpbgp3aGljaCBjYXNlIHlvdSBjYW4ganVzdCBwYXNzIGl0IG9uLiBJZiB0aGV5IGRpZCBu
b3QgdGhlbiBwbGVhc2UgQ0MgdGhlbQpvbiB0aGUgcG9zdGluZyBhbmQgYXNrIHRoZW0gdG8gc3Vw
cGx5IGl0IChkb24ndCBqdXN0IG1ha2UgaXQgdXAKeW91cnNlbGYpLgoKSG9wZWZ1bGx5IHRoZSBv
cmlnaW5hbCBhdXRob3JzaGlwIG9mIGFsbCB0aGUgcGF0Y2hlcyBpcyBjbGVhciwgaWYgbm90CnBs
ZWFzZSBub3RlIHRoaXMgaW4geW91ciBjaGFuZ2Vsb2cgYW5kIHdlJ2xsIHNlZSBpZiB3ZSBjYW4g
dHJhY2sgdGhlbQpkb3duIGV0Yy4KCj4gSG93ZXZlciB0dCBpcyB3b3J0aCBoYXZpbmcgYSB0cnkg
Zm9yIHN1Ym1pdHRpbmcgdG9uaWdodAoKUGxlYXNlLgoKVGhhbmtzLApJYW4uCgo+IAo+IAo+IAo+
IFRoYW5rcy4KPiAKPiAKPiBEYXZpZC4KPiAKPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRGUgOiBJ
YW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPgo+IMOAIDogRGF2aWQgVEVDSEVS
IDxkYXZpZHRlY2hlckB5YWhvby5mcj4gCj4gQ2MgOiB4ZW4tZGV2ZWwgPHhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tPjsgS2VpciAoWGVuLm9yZykKPiA8a2VpckB4ZW4ub3JnPjsgU3RlZmFu
byBTdGFiZWxsaW5pIDxTdGVmYW5vLlN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT47Cj4gVGltIChY
ZW4ub3JnKSA8dGltQHhlbi5vcmc+OyBXZWkgSHVhbmcgPHdlaS5odWFuZzJAYW1kLmNvbT47IElh
bgo+IEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+OyBKYW4gQmV1bGljaCA8SkJl
dWxpY2hAc3VzZS5jb20+IAo+IEVudm95w6kgbGUgOiBKZXVkaSA1IEphbnZpZXIgMjAxMiAxNGgy
NQo+IE9iamV0IDogUmU6IFtYZW4tZGV2ZWxdIFJGQzogU3RpbGwgVE9ETyBmb3IgNC4yPwo+IAo+
IE9uIFRodSwgMjAxMi0wMS0wNSBhdCAxMzoxOSArMDAwMCwgRGF2aWQgVEVDSEVSIHdyb3RlOgo+
ID4gUGFzaQo+ID4gCj4gPiAKPiA+IEkgdHJ5aWVkIHRvIG1haW50YWluIHRoZSBwYXRjaGVzIGZv
ciBYZW4gNC4yICBzaW5jZSBhIGZldyBtb250aC4KPiA+IAo+ID4gCj4gPiBQbGVhc2UgaGF2ZSBh
IGxvb2sKPiA+Cj4gaHR0cDovL3d3dy5kYXZpZGdpcy5mci9ibG9nL2luZGV4LnBocD8yMDExLzEy
LzA3Lzg2MC14ZW4tNDJ1bnN0YWJsZS1wYXRjaGVzLWZvci12Z2EtcGFzcy10aHJvdWdoCj4gCj4g
UGxlYXNlIGNhbiB5b3UgcG9zdCB0aGVzZSBwYXRjaGVzLCBhZ2FpbnN0IHRoZSB0aXAgb2YgeGVu
LXVuc3RhYmxlLAo+IHdpdGgKPiBhIGNoYW5nZWxvZyBldGMgYXMgZGVzY3JpYmVkIGluCj4gaHR0
cDovL3dpa2kueGVuLm9yZy93aWtpL1N1Ym1pdHRpbmdYZW5QYXRjaGVzIHRvIHhlbi1kZXZlbC4K
PiAKPiBUaGVuIHdlIGNhbiBsb29rIGF0IGFjY2VwdGluZyB0aGVtIGluIHRvIHRoZSB0cmVlIGFu
ZCB5b3UgY2FuIHN0b3AKPiBuZWVkaW5nIHRvIG1haW50YWluIHRoZW0gbGlrZSB0aGlzLiBPciBp
cyB0aGVyZSBzb21lIHJlYXNvbiB0aGVzZQo+IGNhbid0Cj4gYmUgc3VibWl0dGVkPwo+IAo+IElh
bi4KPiAKPiA+IAo+ID4gCj4gPiBPbmNlIGEgd2VlaywgSSB0cnkgdG8gdGVzdCB0aGUgcGF0Y2hl
cy4KPiA+IAo+ID4gCj4gPiBMZXQgbWUga25vdyBpZiBJIGNhbiBjb250cmlidXRlLgo+ID4gCj4g
PiAKPiA+IERhdmlkCj4gPiAKPiA+IAo+ID4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBEZSA6IFBhc2kg
S8Okcmtrw6RpbmVuIDxwYXNpa0Bpa2kuZmk+Cj4gPiDDgCA6IFdlaSBIdWFuZyA8d2VpLmh1YW5n
MkBhbWQuY29tPiAKPiA+IENjIDogeGVuLWRldmVsIDx4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbT47IEtlaXIgRnJhc2VyCj4gPiA8a2VpckB4ZW4ub3JnPjsgSWFuIENhbXBiZWxsIDxJYW4u
Q2FtcGJlbGxAY2l0cml4LmNvbT47IFRpbSBEZWVnYW4KPiA+IDx0aW1AeGVuLm9yZz47IElhbiBK
YWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjsgU3RlZmFubwo+ID4gU3RhYmVsbGlu
aSA8c3RlZmFuby5zdGFiZWxsaW5pQGNpdHJpeC5jb20+OyBKYW4gQmV1bGljaAo+ID4gPEpCZXVs
aWNoQHN1c2UuY29tPiAKPiA+IEVudm95w6kgbGUgOiBNZXJjcmVkaSA0IEphbnZpZXIgMjAxMiAy
MGg0Mwo+ID4gT2JqZXQgOiBSZTogW1hlbi1kZXZlbF0gUkZDOiBTdGlsbCBUT0RPIGZvciA0LjI/
Cj4gPiAKPiA+IE9uIFdlZCwgSmFuIDA0LCAyMDEyIGF0IDAxOjIxOjQ2UE0gLTA2MDAsIFdlaSBI
dWFuZyB3cm90ZToKPiA+ID4+Pgo+ID4gPj4+IEhhcyBhbnlib2R5IGdvdCBhbnl0aGluZyBlbHNl
PyBJJ20gc3VyZSBJJ3ZlIG1pc3NlZCBzdHVmZi4gQXJlCj4gPiB0aGVyZSBhbnkKPiA+ID4+PiBt
dXN0IGhhdmVzIGUuZy4gaW4gdGhlIHBhZ2luZy9zaGFyaW5nIHNwYWNlcz8KPiA+ID4+Pgo+ID4g
Pj4gLSBXaGF0J3MgdGhlIHN0YXR1cyBvZiBOZXN0ZWQgSGFyZHdhcmUgVmlydHVhbGl6YXRpb24/
Cj4gPiA+PiBJIHJlbWVtYmVyIHNvbWUgZW1haWwgc2F5aW5nIEludGVsIHZteC1vbi12bXggaGFz
IHNvbWUKPiBwZXJmb3JtYW5jZQo+ID4gaXNzdWVzLAo+ID4gPj4gYW5kIGFtZCBzdm0tb24tc3Zt
IHdvcmtzIGJldHRlci4uCj4gPiA+Pgo+ID4gPj4KPiA+ID4+IC0gQWxzbyB0aGVyZSdzIGEgYnVu
Y2ggb2YgVkdBIHBhc3N0aHJ1IHJlbGF0ZWQgcGF0Y2hlcywKPiA+ID4+IHRoYXQgSSBvbmNlIHZv
bHVudGVlcmVkIHRvIGNvbGxlY3QvcmViYXNlL2NsZWFudXAvcmVwb3N0IG15c2VsZiwKPiA+ID4+
IGJ1dCBJIHN0aWxsIGhhdmVuJ3QgaGFkIHRpbWUgZm9yIHRoYXQgOigKPiA+ID4gU2luY2UgdGhl
cmUgd2VyZSBxdWl0ZSBhIGxvdCBvZiBpbnRlcmVzdCBvbiB0aGlzIHN1YmplY3QsIHNob3VsZAo+
ID4gd2UgIAo+ID4gPiBkb2N1bWVudCBpdCBpbiBhIHNlcGFyYXRlIHdpa2kgZm9yIHdvcmtpbmcg
Y29tYmluYXRpb25zIChsaWtlICAKPiA+ID4gaHlwZXJ2aXNvciwgZG9tMCwgZ2Z4IGNhcmQsIGRy
aXZlciB2ZXJzaW9uLCB0cmlja3MsIGV0Yyk/Cj4gPiA+Cj4gPiAKPiA+IEkgYWN0dWFsbHkgb25j
ZSBzdGFydGVkIHdyaXRpbmcgZG93biB0aGF0IGtpbmQgb2Ygc3R1ZmY6Cj4gPiBodHRwOi8vd2lr
aS54ZW4ub3JnL3hlbndpa2kvWGVuVkdBUGFzc3Rocm91Z2hUZXN0ZWRBZGFwdGVycy5odG1sCj4g
PiAKPiA+IEZlZWwgZnJlZSB0byBjb250cmlidXRlIDopCj4gPiAKPiA+IFRoZXJlJ3MgYWxzbzoK
PiA+IGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9YZW5WR0FQYXNzdGhyb3VnaAo+ID4gCj4g
PiAKPiA+IC0tIFBhc2kKPiA+IAo+ID4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwo+ID4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+ID4gWGVuLWRl
dmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiA+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hl
bi1kZXZlbAo+ID4gCj4gPiAKPiA+IAo+IAo+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCj4gCj4gCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:19:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16:19:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riq1l-0004dw-79; Thu, 05 Jan 2012 16:18:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Riq1j-0004dY-Om
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325780325!7792921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13690 invoked from network); 5 Jan 2012 16:18:45 -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;
	5 Jan 2012 16:18:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9841938"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 16:18: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, 5 Jan 2012
	16:18:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David TECHER <davidtecher@yahoo.fr>
Date: Thu, 5 Jan 2012 16:18:44 +0000
In-Reply-To: <1325770888.57253.YahooMailNeo@web29803.mail.ird.yahoo.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net>
	<1325769562.89445.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<1325769910.25206.373.camel@zakaz.uk.xensource.com>
	<1325770888.57253.YahooMailNeo@web29803.mail.ird.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325780324.25206.401.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Huang <wei.huang2@amd.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCAyMDEyLTAxLTA1IGF0IDEzOjQxICswMDAwLCBEYXZpZCBURUNIRVIgd3JvdGU6Cj4g
SWFuCj4gCj4gCj4gSSB3aWxsIHRyeSB0byBzdWJtaXQgdGhlIHBhdGNoIHRvbmlnaHQgd2hlbiBJ
IGFtIGF0IGhvbWUgKEkgYW0gaW4KPiBGcmFuY2UgLSBDLkUuVCkgZWxzZSB5b3UgY2FuIGRvd25s
b2FkIHBhdGNoZXMgYXQKPiBodHRwOi8vd3d3LmRhdmlkZ2lzLmZyL2Rvd25sb2FkL3hlbi00LjJf
cmV2MjQyMzJfZ2Z4LXBhc3N0aHJvdWdoLXBhdGNocy50YXIuYnoyCgpUaGFua3MsIEknbSBub3Qg
YWN0dWFsbHkgaW50ZXJlc3RlZCBpbiB0aGlzIGZ1bmN0aW9uYWxpdHkgbXlzZWxmIC0tIEkKanVz
dCB3YW50ZWQgdG8gZW5jb3VyYWdlIHRoZWlyIHN1Ym1pc3Npb24gdXBzdHJlYW0gc2luY2Ugb3Ro
ZXJzIHNlZW0gdG8Kd2FudCB0aGVtLgoKPiBGb3IgeW91ciBpbmZvcm1hdGlvbiBhbmQgYXMgaXQg
aXMgd3JpdHR0ZW4gaW4gbXkgYXJ0aWNsZSwgSSBhbSBub3QgdGhlCj4gYXV0aG9yIG9mIHRoZSBw
YXRjaGVzLCBqdXN0IGEgc2ltcGxlIG1haW50YWluZXIuCgpUaGVuIHRoZXJlIGlzIG9uZSBhZGRp
dGlvbmFsIHdyaW5rbGUgb3ZlciBhbmQgYWJvdmUgd2hhdCBpcyBkZXNjcmliZWQgaW4KdGhlIFN1
Ym1pdHRpbmdYZW5QYXRjaGVzIHdpa2kgcGFnZSwgeW91IHNob3VsZCBpbmNsdWRlIGEgIlNpZ25l
ZC1vZmYtYnkiCmZyb20gdGhlIG9yaWdpbmFsIGF1dGhvciBhYm92ZSB5b3VyIG93bi4KCkhvcGVm
dWxseSB0aGV5IGluY2x1ZGVkIG9uZSB3aGVuIHRoZXkgb3JpZ2luYWxseSBwb3N0ZWQgdGhlIHBh
dGNoLCBpbgp3aGljaCBjYXNlIHlvdSBjYW4ganVzdCBwYXNzIGl0IG9uLiBJZiB0aGV5IGRpZCBu
b3QgdGhlbiBwbGVhc2UgQ0MgdGhlbQpvbiB0aGUgcG9zdGluZyBhbmQgYXNrIHRoZW0gdG8gc3Vw
cGx5IGl0IChkb24ndCBqdXN0IG1ha2UgaXQgdXAKeW91cnNlbGYpLgoKSG9wZWZ1bGx5IHRoZSBv
cmlnaW5hbCBhdXRob3JzaGlwIG9mIGFsbCB0aGUgcGF0Y2hlcyBpcyBjbGVhciwgaWYgbm90CnBs
ZWFzZSBub3RlIHRoaXMgaW4geW91ciBjaGFuZ2Vsb2cgYW5kIHdlJ2xsIHNlZSBpZiB3ZSBjYW4g
dHJhY2sgdGhlbQpkb3duIGV0Yy4KCj4gSG93ZXZlciB0dCBpcyB3b3J0aCBoYXZpbmcgYSB0cnkg
Zm9yIHN1Ym1pdHRpbmcgdG9uaWdodAoKUGxlYXNlLgoKVGhhbmtzLApJYW4uCgo+IAo+IAo+IAo+
IFRoYW5rcy4KPiAKPiAKPiBEYXZpZC4KPiAKPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gRGUgOiBJ
YW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPgo+IMOAIDogRGF2aWQgVEVDSEVS
IDxkYXZpZHRlY2hlckB5YWhvby5mcj4gCj4gQ2MgOiB4ZW4tZGV2ZWwgPHhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tPjsgS2VpciAoWGVuLm9yZykKPiA8a2VpckB4ZW4ub3JnPjsgU3RlZmFu
byBTdGFiZWxsaW5pIDxTdGVmYW5vLlN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT47Cj4gVGltIChY
ZW4ub3JnKSA8dGltQHhlbi5vcmc+OyBXZWkgSHVhbmcgPHdlaS5odWFuZzJAYW1kLmNvbT47IElh
bgo+IEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+OyBKYW4gQmV1bGljaCA8SkJl
dWxpY2hAc3VzZS5jb20+IAo+IEVudm95w6kgbGUgOiBKZXVkaSA1IEphbnZpZXIgMjAxMiAxNGgy
NQo+IE9iamV0IDogUmU6IFtYZW4tZGV2ZWxdIFJGQzogU3RpbGwgVE9ETyBmb3IgNC4yPwo+IAo+
IE9uIFRodSwgMjAxMi0wMS0wNSBhdCAxMzoxOSArMDAwMCwgRGF2aWQgVEVDSEVSIHdyb3RlOgo+
ID4gUGFzaQo+ID4gCj4gPiAKPiA+IEkgdHJ5aWVkIHRvIG1haW50YWluIHRoZSBwYXRjaGVzIGZv
ciBYZW4gNC4yICBzaW5jZSBhIGZldyBtb250aC4KPiA+IAo+ID4gCj4gPiBQbGVhc2UgaGF2ZSBh
IGxvb2sKPiA+Cj4gaHR0cDovL3d3dy5kYXZpZGdpcy5mci9ibG9nL2luZGV4LnBocD8yMDExLzEy
LzA3Lzg2MC14ZW4tNDJ1bnN0YWJsZS1wYXRjaGVzLWZvci12Z2EtcGFzcy10aHJvdWdoCj4gCj4g
UGxlYXNlIGNhbiB5b3UgcG9zdCB0aGVzZSBwYXRjaGVzLCBhZ2FpbnN0IHRoZSB0aXAgb2YgeGVu
LXVuc3RhYmxlLAo+IHdpdGgKPiBhIGNoYW5nZWxvZyBldGMgYXMgZGVzY3JpYmVkIGluCj4gaHR0
cDovL3dpa2kueGVuLm9yZy93aWtpL1N1Ym1pdHRpbmdYZW5QYXRjaGVzIHRvIHhlbi1kZXZlbC4K
PiAKPiBUaGVuIHdlIGNhbiBsb29rIGF0IGFjY2VwdGluZyB0aGVtIGluIHRvIHRoZSB0cmVlIGFu
ZCB5b3UgY2FuIHN0b3AKPiBuZWVkaW5nIHRvIG1haW50YWluIHRoZW0gbGlrZSB0aGlzLiBPciBp
cyB0aGVyZSBzb21lIHJlYXNvbiB0aGVzZQo+IGNhbid0Cj4gYmUgc3VibWl0dGVkPwo+IAo+IElh
bi4KPiAKPiA+IAo+ID4gCj4gPiBPbmNlIGEgd2VlaywgSSB0cnkgdG8gdGVzdCB0aGUgcGF0Y2hl
cy4KPiA+IAo+ID4gCj4gPiBMZXQgbWUga25vdyBpZiBJIGNhbiBjb250cmlidXRlLgo+ID4gCj4g
PiAKPiA+IERhdmlkCj4gPiAKPiA+IAo+ID4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBEZSA6IFBhc2kg
S8Okcmtrw6RpbmVuIDxwYXNpa0Bpa2kuZmk+Cj4gPiDDgCA6IFdlaSBIdWFuZyA8d2VpLmh1YW5n
MkBhbWQuY29tPiAKPiA+IENjIDogeGVuLWRldmVsIDx4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbT47IEtlaXIgRnJhc2VyCj4gPiA8a2VpckB4ZW4ub3JnPjsgSWFuIENhbXBiZWxsIDxJYW4u
Q2FtcGJlbGxAY2l0cml4LmNvbT47IFRpbSBEZWVnYW4KPiA+IDx0aW1AeGVuLm9yZz47IElhbiBK
YWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjsgU3RlZmFubwo+ID4gU3RhYmVsbGlu
aSA8c3RlZmFuby5zdGFiZWxsaW5pQGNpdHJpeC5jb20+OyBKYW4gQmV1bGljaAo+ID4gPEpCZXVs
aWNoQHN1c2UuY29tPiAKPiA+IEVudm95w6kgbGUgOiBNZXJjcmVkaSA0IEphbnZpZXIgMjAxMiAy
MGg0Mwo+ID4gT2JqZXQgOiBSZTogW1hlbi1kZXZlbF0gUkZDOiBTdGlsbCBUT0RPIGZvciA0LjI/
Cj4gPiAKPiA+IE9uIFdlZCwgSmFuIDA0LCAyMDEyIGF0IDAxOjIxOjQ2UE0gLTA2MDAsIFdlaSBI
dWFuZyB3cm90ZToKPiA+ID4+Pgo+ID4gPj4+IEhhcyBhbnlib2R5IGdvdCBhbnl0aGluZyBlbHNl
PyBJJ20gc3VyZSBJJ3ZlIG1pc3NlZCBzdHVmZi4gQXJlCj4gPiB0aGVyZSBhbnkKPiA+ID4+PiBt
dXN0IGhhdmVzIGUuZy4gaW4gdGhlIHBhZ2luZy9zaGFyaW5nIHNwYWNlcz8KPiA+ID4+Pgo+ID4g
Pj4gLSBXaGF0J3MgdGhlIHN0YXR1cyBvZiBOZXN0ZWQgSGFyZHdhcmUgVmlydHVhbGl6YXRpb24/
Cj4gPiA+PiBJIHJlbWVtYmVyIHNvbWUgZW1haWwgc2F5aW5nIEludGVsIHZteC1vbi12bXggaGFz
IHNvbWUKPiBwZXJmb3JtYW5jZQo+ID4gaXNzdWVzLAo+ID4gPj4gYW5kIGFtZCBzdm0tb24tc3Zt
IHdvcmtzIGJldHRlci4uCj4gPiA+Pgo+ID4gPj4KPiA+ID4+IC0gQWxzbyB0aGVyZSdzIGEgYnVu
Y2ggb2YgVkdBIHBhc3N0aHJ1IHJlbGF0ZWQgcGF0Y2hlcywKPiA+ID4+IHRoYXQgSSBvbmNlIHZv
bHVudGVlcmVkIHRvIGNvbGxlY3QvcmViYXNlL2NsZWFudXAvcmVwb3N0IG15c2VsZiwKPiA+ID4+
IGJ1dCBJIHN0aWxsIGhhdmVuJ3QgaGFkIHRpbWUgZm9yIHRoYXQgOigKPiA+ID4gU2luY2UgdGhl
cmUgd2VyZSBxdWl0ZSBhIGxvdCBvZiBpbnRlcmVzdCBvbiB0aGlzIHN1YmplY3QsIHNob3VsZAo+
ID4gd2UgIAo+ID4gPiBkb2N1bWVudCBpdCBpbiBhIHNlcGFyYXRlIHdpa2kgZm9yIHdvcmtpbmcg
Y29tYmluYXRpb25zIChsaWtlICAKPiA+ID4gaHlwZXJ2aXNvciwgZG9tMCwgZ2Z4IGNhcmQsIGRy
aXZlciB2ZXJzaW9uLCB0cmlja3MsIGV0Yyk/Cj4gPiA+Cj4gPiAKPiA+IEkgYWN0dWFsbHkgb25j
ZSBzdGFydGVkIHdyaXRpbmcgZG93biB0aGF0IGtpbmQgb2Ygc3R1ZmY6Cj4gPiBodHRwOi8vd2lr
aS54ZW4ub3JnL3hlbndpa2kvWGVuVkdBUGFzc3Rocm91Z2hUZXN0ZWRBZGFwdGVycy5odG1sCj4g
PiAKPiA+IEZlZWwgZnJlZSB0byBjb250cmlidXRlIDopCj4gPiAKPiA+IFRoZXJlJ3MgYWxzbzoK
PiA+IGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9YZW5WR0FQYXNzdGhyb3VnaAo+ID4gCj4g
PiAKPiA+IC0tIFBhc2kKPiA+IAo+ID4gCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwo+ID4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+ID4gWGVuLWRl
dmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPiA+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hl
bi1kZXZlbAo+ID4gCj4gPiAKPiA+IAo+IAo+IAo+IAo+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCj4gCj4gCj4gCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:27:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16:27:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiqA6-0004vd-8m; Thu, 05 Jan 2012 16:27:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiqA4-0004vY-2T
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:27:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1325780842!11195755!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20701 invoked from network); 5 Jan 2012 16:27:22 -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;
	5 Jan 2012 16:27:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9842204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 16:27:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	16:27:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Thu, 5 Jan 2012 16:27:21 +0000
In-Reply-To: <4F05C6DB.2090207@amd.com>
References: <4F05C6DB.2090207@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325780841.25206.403.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] x11 header check still needed?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 15:50 +0000, Christoph Egger wrote:
> Hi,
> 
> is the x11 header check in tools/check/ still needed?
> 
> On NetBSD it is superflous and can be removed.

I can't see any mention of "keysymdef.h" under tools so I expect it is
superfluous everywhere?

Unless keysymdef.h is just the canary header we use to check for xll
generally but we don't actually use it? Perhaps this is needed to build
qemu with SDL support (but then we'd be better checking for sdl
explicitly, which I expect the qemu config script does...)?

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:27:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16:27:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiqA6-0004vd-8m; Thu, 05 Jan 2012 16:27:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RiqA4-0004vY-2T
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:27:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1325780842!11195755!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20701 invoked from network); 5 Jan 2012 16:27:22 -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;
	5 Jan 2012 16:27:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9842204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 16:27:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	16:27:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Thu, 5 Jan 2012 16:27:21 +0000
In-Reply-To: <4F05C6DB.2090207@amd.com>
References: <4F05C6DB.2090207@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325780841.25206.403.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] x11 header check still needed?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 15:50 +0000, Christoph Egger wrote:
> Hi,
> 
> is the x11 header check in tools/check/ still needed?
> 
> On NetBSD it is superflous and can be removed.

I can't see any mention of "keysymdef.h" under tools so I expect it is
superfluous everywhere?

Unless keysymdef.h is just the canary header we use to check for xll
generally but we don't actually use it? Perhaps this is needed to build
qemu with SDL support (but then we'd be better checking for sdl
explicitly, which I expect the qemu config script does...)?

Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:33:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16: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 1RiqFg-00056I-21; Thu, 05 Jan 2012 16:33: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 1RiqFf-000569-5u
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:33:15 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325781188!9727617!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26961 invoked from network); 5 Jan 2012 16:33:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 16:33:08 -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 q05GX3St003013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 11:33:04 -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 q05GX0E9032577; Thu, 5 Jan 2012 11:33:01 -0500
Message-ID: <4F05D0BC.70707@redhat.com>
Date: Thu, 05 Jan 2012 18:33:00 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051536290.3150@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 01/05/2012 05:53 PM, Stefano Stabellini wrote:
>
> > This involves:
> > - adding vmstate to xen-all.c so it can migrate the xen vram address
>
> Easy so far.
>
>
> > - making sure the memory core doesn't do mappings during restore (can be
> > done by wrapping restore with
> > memory_region_transaction_begin()/memory_region_transaction_commit();
> > beneficial to normal qemu migrations as well)
>
> Besides restore we would also need to wrap machine->init() with
> memory_region_transaction_begin()/memory_region_transaction_commit(),
> so that all the mappings are only done at the end of restore, when we do
> know the videoram address.
>
> This seems unfeasable to me: what about all the addresses set in the
> meantime using memory_region_get_ram_ptr()?
> For example s->vram_ptr set by vga_common_init during machine->init()?
> If the actual memory is only allocated at the end of restore, vram_ptr
> would be bogus at least until then and we would still need a way to
> update it afterwards.

One way is to only call it on demand when we actually need to draw or
read the framebuffer.  Currently this will be slow since we'll search
the RAMBlock list, but soon it will be dereference of MemoryRegion.

> BTW what you are suggesting is not so different from what was done by
> Anthony in the last patch series he sent. See the following (ugly) patch
> to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
> completed and then update the pointer:
>
> http://marc.info/?l=qemu-devel&m=132346828427314&w=2

I see.

Maybe we can put the xen_address in the cirrus vmstate?  That way there
is no ordering issue at all.  Of course we have to make sure it isn't
saved/restored for non-xen, but that's doable with a predicate attached
to the field.

>
> > - updating the mapped address during restore
> > 
> > I think this is cleaner than introducing a new migration stage, but the
> > implementation may prove otherwise.
>
> see patch above, a good summary of the difficulties of this approach
>
>
> > > > xen_register_framebuffer() is slightly less hacky.
> > >
> > > I agree, however xen_register_framebuffer is called after
> > > memory_region_init_ram, so the allocation would have been made already.
> > 
> > xen_ram_alloc(MemoryRegion *mr)
> > {
> >     if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
> >         return;
> >     }
> > }
> > 
> > xen_framebuffer_address_post_load()
> > {
> >     framebuffer_addr_known = true;
> >     if (framebuffer) {
> >         framebuffer->xen_address = framebuffer_addr;
> >     }
> > }
> > 
> > (ugly way of avoiding a dependency, but should work)
>  
> The issue is that xen_ram_alloc is called by memory_region_init_ram
> before xen_register_framebuffer is called (see the order of calls in
> vga_common_init).
> So when xen_ram_alloc is called framebuffer is still NULL: mr !=
> framebuffer.

Yup.  We could invert the order.  It's really ugly though to pass the
address of an uninitialized structure.


-- 
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 Jan 05 16:33:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16: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 1RiqFg-00056I-21; Thu, 05 Jan 2012 16:33: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 1RiqFf-000569-5u
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 16:33:15 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325781188!9727617!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26961 invoked from network); 5 Jan 2012 16:33:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 16:33:08 -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 q05GX3St003013
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 11:33:04 -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 q05GX0E9032577; Thu, 5 Jan 2012 11:33:01 -0500
Message-ID: <4F05D0BC.70707@redhat.com>
Date: Thu, 05 Jan 2012 18:33:00 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051536290.3150@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 01/05/2012 05:53 PM, Stefano Stabellini wrote:
>
> > This involves:
> > - adding vmstate to xen-all.c so it can migrate the xen vram address
>
> Easy so far.
>
>
> > - making sure the memory core doesn't do mappings during restore (can be
> > done by wrapping restore with
> > memory_region_transaction_begin()/memory_region_transaction_commit();
> > beneficial to normal qemu migrations as well)
>
> Besides restore we would also need to wrap machine->init() with
> memory_region_transaction_begin()/memory_region_transaction_commit(),
> so that all the mappings are only done at the end of restore, when we do
> know the videoram address.
>
> This seems unfeasable to me: what about all the addresses set in the
> meantime using memory_region_get_ram_ptr()?
> For example s->vram_ptr set by vga_common_init during machine->init()?
> If the actual memory is only allocated at the end of restore, vram_ptr
> would be bogus at least until then and we would still need a way to
> update it afterwards.

One way is to only call it on demand when we actually need to draw or
read the framebuffer.  Currently this will be slow since we'll search
the RAMBlock list, but soon it will be dereference of MemoryRegion.

> BTW what you are suggesting is not so different from what was done by
> Anthony in the last patch series he sent. See the following (ugly) patch
> to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
> completed and then update the pointer:
>
> http://marc.info/?l=qemu-devel&m=132346828427314&w=2

I see.

Maybe we can put the xen_address in the cirrus vmstate?  That way there
is no ordering issue at all.  Of course we have to make sure it isn't
saved/restored for non-xen, but that's doable with a predicate attached
to the field.

>
> > - updating the mapped address during restore
> > 
> > I think this is cleaner than introducing a new migration stage, but the
> > implementation may prove otherwise.
>
> see patch above, a good summary of the difficulties of this approach
>
>
> > > > xen_register_framebuffer() is slightly less hacky.
> > >
> > > I agree, however xen_register_framebuffer is called after
> > > memory_region_init_ram, so the allocation would have been made already.
> > 
> > xen_ram_alloc(MemoryRegion *mr)
> > {
> >     if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
> >         return;
> >     }
> > }
> > 
> > xen_framebuffer_address_post_load()
> > {
> >     framebuffer_addr_known = true;
> >     if (framebuffer) {
> >         framebuffer->xen_address = framebuffer_addr;
> >     }
> > }
> > 
> > (ugly way of avoiding a dependency, but should work)
>  
> The issue is that xen_ram_alloc is called by memory_region_init_ram
> before xen_register_framebuffer is called (see the order of calls in
> vga_common_init).
> So when xen_ram_alloc is called framebuffer is still NULL: mr !=
> framebuffer.

Yup.  We could invert the order.  It's really ugly though to pass the
address of an uninitialized structure.


-- 
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 Jan 05 16:47:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16: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 1RiqT6-0005MC-Nc; Thu, 05 Jan 2012 16:47:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RiqT5-0005Lo-C4; Thu, 05 Jan 2012 16:47:07 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325782020!9834999!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28182 invoked from network); 5 Jan 2012 16:47:00 -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;
	5 Jan 2012 16:47:00 -0000
Received: by wgbds11 with SMTP id ds11so701960wgb.24
	for <multiple recipients>; Thu, 05 Jan 2012 08:47:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=GhIH/dQR8v+D6eOVZOf1y1dkQPdrCX4sS8adRDsgLIE=;
	b=Lig7Dydz0JCsEJwgSV9pYSSlnMxfjt0JFSVp9Jthzk5oG9AAgGhifgIch6QYPYQ0RR
	OCt5jVPnjMz5VDuHKOSIvoWvOG1H/t26HsEVg0pnrABFcaxBuQb9Ef4im4vl3LWafJiE
	I6ReFDS4Jw7SpnhzP4RJzCF6i/RsR5dkiEh78=
Received: by 10.227.203.10 with SMTP id fg10mr2630032wbb.1.1325782020477;
	Thu, 05 Jan 2012 08:47:00 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id k33sm22910686wbo.5.2012.01.05.08.46.58
	(version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 08:46:58 -0800 (PST)
Message-ID: <4F05D400.6020306@xen.org>
Date: Thu, 05 Jan 2012 16:46:56 +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-arm@lists.xensource.com, 
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] Oracle hosted Xen Hackathon, March 6-8, 2012,
	Santa Clara, CA
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2649549528197661132=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

I am pleased to announce the Next Xen Hackathon. The Hackathon will be 
hosted by Oracle and takes place March 6-8, 2012 at the Oracle Campus in 
Santa Clara, CA, USA. If you want to attend, save the date and add 
yourself to the wiki <http://wiki.xen.org/wiki/Hackathon/March2012>. I 
wanted to thank Oracle and in particular Konrad Rzeszutek Wilk for 
making the Hackathon happen.

The aim of the Hackathon is to give developers the opportunity to meet 
face to face to discuss development, coordinate, write code and 
collaborate with other developers as well as allowing everyone to put 
names with faces. There is no registration fee. However as an attendee 
you will need to cover your own travel, accommodation and other costs 
such as evening meals etc. More details will follow and will be 
communicated in due course on the blog, mailing lists and via the wiki 
<http://wiki.xen.org/wiki/Hackathon/March2012> page.

See you there!

Regards
Lars


--------------050104040002050204010508
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">
    <p>I am pleased to announce the Next Xen Hackathon. The Hackathon
      will be hosted by Oracle and takes place March 6-8, 2012 at the
      Oracle Campus in Santa Clara, CA, USA. If you want to attend, save
      the date and add yourself to the <a
        href="http://wiki.xen.org/wiki/Hackathon/March2012">wiki</a>. I
      wanted to thank Oracle and in particular Konrad Rzeszutek Wilk for
      making the Hackathon happen.</p>
    <p>The aim of the Hackathon is to give developers the opportunity to
      meet face to face to discuss development, coordinate, write code
      and collaborate with other developers as well as allowing everyone
      to put names with faces. There is no registration fee. However as
      an attendee you will need to cover your own travel, accommodation
      and other costs such as evening meals etc. More details will
      follow and will be communicated in due course on the blog, mailing
      lists and via the <a
        href="http://wiki.xen.org/wiki/Hackathon/March2012">wiki</a>
      page. </p>
    <p>See you there!<br>
    </p>
    <p>Regards<br>
      Lars<br>
    </p>
  </body>
</html>

--------------050104040002050204010508--


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

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

--===============2649549528197661132==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 16:47:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 16: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 1RiqT6-0005MC-Nc; Thu, 05 Jan 2012 16:47:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RiqT5-0005Lo-C4; Thu, 05 Jan 2012 16:47:07 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1325782020!9834999!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28182 invoked from network); 5 Jan 2012 16:47:00 -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;
	5 Jan 2012 16:47:00 -0000
Received: by wgbds11 with SMTP id ds11so701960wgb.24
	for <multiple recipients>; Thu, 05 Jan 2012 08:47:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type; bh=GhIH/dQR8v+D6eOVZOf1y1dkQPdrCX4sS8adRDsgLIE=;
	b=Lig7Dydz0JCsEJwgSV9pYSSlnMxfjt0JFSVp9Jthzk5oG9AAgGhifgIch6QYPYQ0RR
	OCt5jVPnjMz5VDuHKOSIvoWvOG1H/t26HsEVg0pnrABFcaxBuQb9Ef4im4vl3LWafJiE
	I6ReFDS4Jw7SpnhzP4RJzCF6i/RsR5dkiEh78=
Received: by 10.227.203.10 with SMTP id fg10mr2630032wbb.1.1325782020477;
	Thu, 05 Jan 2012 08:47:00 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id k33sm22910686wbo.5.2012.01.05.08.46.58
	(version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 08:46:58 -0800 (PST)
Message-ID: <4F05D400.6020306@xen.org>
Date: Thu, 05 Jan 2012 16:46:56 +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-arm@lists.xensource.com, 
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] Oracle hosted Xen Hackathon, March 6-8, 2012,
	Santa Clara, CA
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2649549528197661132=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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

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

I am pleased to announce the Next Xen Hackathon. The Hackathon will be 
hosted by Oracle and takes place March 6-8, 2012 at the Oracle Campus in 
Santa Clara, CA, USA. If you want to attend, save the date and add 
yourself to the wiki <http://wiki.xen.org/wiki/Hackathon/March2012>. I 
wanted to thank Oracle and in particular Konrad Rzeszutek Wilk for 
making the Hackathon happen.

The aim of the Hackathon is to give developers the opportunity to meet 
face to face to discuss development, coordinate, write code and 
collaborate with other developers as well as allowing everyone to put 
names with faces. There is no registration fee. However as an attendee 
you will need to cover your own travel, accommodation and other costs 
such as evening meals etc. More details will follow and will be 
communicated in due course on the blog, mailing lists and via the wiki 
<http://wiki.xen.org/wiki/Hackathon/March2012> page.

See you there!

Regards
Lars


--------------050104040002050204010508
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">
    <p>I am pleased to announce the Next Xen Hackathon. The Hackathon
      will be hosted by Oracle and takes place March 6-8, 2012 at the
      Oracle Campus in Santa Clara, CA, USA. If you want to attend, save
      the date and add yourself to the <a
        href="http://wiki.xen.org/wiki/Hackathon/March2012">wiki</a>. I
      wanted to thank Oracle and in particular Konrad Rzeszutek Wilk for
      making the Hackathon happen.</p>
    <p>The aim of the Hackathon is to give developers the opportunity to
      meet face to face to discuss development, coordinate, write code
      and collaborate with other developers as well as allowing everyone
      to put names with faces. There is no registration fee. However as
      an attendee you will need to cover your own travel, accommodation
      and other costs such as evening meals etc. More details will
      follow and will be communicated in due course on the blog, mailing
      lists and via the <a
        href="http://wiki.xen.org/wiki/Hackathon/March2012">wiki</a>
      page. </p>
    <p>See you there!<br>
    </p>
    <p>Regards<br>
      Lars<br>
    </p>
  </body>
</html>

--------------050104040002050204010508--


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

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

--===============2649549528197661132==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:19:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riqxw-00068U-4J; Thu, 05 Jan 2012 17:19:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Riqxu-00068P-Jg
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:18:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325783931!2426869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8381 invoked from network); 5 Jan 2012 17:18:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 17:18:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:18:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	17:18:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 17:18:51 +0000
In-Reply-To: <20229.46603.265055.83034@mariner.uk.xensource.com>
References: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
	<20229.46603.265055.83034@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325783931.25206.417.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>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

On Thu, 2012-01-05 at 14:39 +0000, Ian Jackson wrote:
> > ipxe: update to upstream version
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I'm guessing this is the cause of:

make[6]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/firmware/etherboot'
rm -rf ipxe
gzip -dc ipxe.tar.gz | tar xf -
for i in $(cat patches/series) ; do                 \
	    patch -d ipxe -p1 --quiet <patches/$i || exit 1 ; \
	done
1 out of 4 hunks FAILED -- saving rejects to file src/arch/i386/prefix/romprefix.S.rej
make[6]: *** [ipxe/src/arch/i386/Makefile] Error 1
make[6]: Leaving directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/firmware/etherboot'

This seems to be fixed (or at least mitigated) by properly removing the
tarball on clean:

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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1325783856 0
# Node ID 0fcfd62166de11687ac2db799b71906e7ce41300
# Parent  f2682e2ec7e53683a31e940ada37726aa8da7fcc
ipxe: remove tarball on clean

This prevents us picking up a stale tarball when the tag changes.

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

diff -r f2682e2ec7e5 -r 0fcfd62166de tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile	Thu Jan 05 16:33:25 2012 +0000
+++ b/tools/firmware/etherboot/Makefile	Thu Jan 05 17:17:36 2012 +0000
@@ -56,7 +56,7 @@ eb-roms.h: Config
 
 .PHONY: clean
 clean:
-	rm -rf $D $D.git *~ eb-roms.h _$T
+	rm -rf $D $D.git *~ eb-roms.h _$T $T
 
 .PHONY: distclean
 distclean: clean


Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:19:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:19:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riqxw-00068U-4J; Thu, 05 Jan 2012 17:19:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Riqxu-00068P-Jg
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:18:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325783931!2426869!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8381 invoked from network); 5 Jan 2012 17:18:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 17:18:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843491"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:18:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Thu, 5 Jan 2012
	17:18:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 17:18:51 +0000
In-Reply-To: <20229.46603.265055.83034@mariner.uk.xensource.com>
References: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
	<20229.46603.265055.83034@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325783931.25206.417.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>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

On Thu, 2012-01-05 at 14:39 +0000, Ian Jackson wrote:
> > ipxe: update to upstream version
> 
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

I'm guessing this is the cause of:

make[6]: Entering directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/firmware/etherboot'
rm -rf ipxe
gzip -dc ipxe.tar.gz | tar xf -
for i in $(cat patches/series) ; do                 \
	    patch -d ipxe -p1 --quiet <patches/$i || exit 1 ; \
	done
1 out of 4 hunks FAILED -- saving rejects to file src/arch/i386/prefix/romprefix.S.rej
make[6]: *** [ipxe/src/arch/i386/Makefile] Error 1
make[6]: Leaving directory `/local/scratch/ianc/devel/xen-unstable.hg/tools/firmware/etherboot'

This seems to be fixed (or at least mitigated) by properly removing the
tarball on clean:

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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1325783856 0
# Node ID 0fcfd62166de11687ac2db799b71906e7ce41300
# Parent  f2682e2ec7e53683a31e940ada37726aa8da7fcc
ipxe: remove tarball on clean

This prevents us picking up a stale tarball when the tag changes.

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

diff -r f2682e2ec7e5 -r 0fcfd62166de tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile	Thu Jan 05 16:33:25 2012 +0000
+++ b/tools/firmware/etherboot/Makefile	Thu Jan 05 17:17:36 2012 +0000
@@ -56,7 +56,7 @@ eb-roms.h: Config
 
 .PHONY: clean
 clean:
-	rm -rf $D $D.git *~ eb-roms.h _$T
+	rm -rf $D $D.git *~ eb-roms.h _$T $T
 
 .PHONY: distclean
 distclean: clean


Ian.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:22:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir0b-0006DV-Mw; Thu, 05 Jan 2012 17:21:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rir0a-0006DB-8V
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:21:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325784097!7913592!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22651 invoked from network); 5 Jan 2012 17:21:38 -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;
	5 Jan 2012 17:21:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:21: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; Thu, 5 Jan 2012 17:21:37 +0000
Date: Thu, 5 Jan 2012 17:21:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F05D0BC.70707@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051646580.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 05:53 PM, Stefano Stabellini wrote:
> >
> > > This involves:
> > > - adding vmstate to xen-all.c so it can migrate the xen vram address
> >
> > Easy so far.
> >
> >
> > > - making sure the memory core doesn't do mappings during restore (can be
> > > done by wrapping restore with
> > > memory_region_transaction_begin()/memory_region_transaction_commit();
> > > beneficial to normal qemu migrations as well)
> >
> > Besides restore we would also need to wrap machine->init() with
> > memory_region_transaction_begin()/memory_region_transaction_commit(),
> > so that all the mappings are only done at the end of restore, when we do
> > know the videoram address.
> >
> > This seems unfeasable to me: what about all the addresses set in the
> > meantime using memory_region_get_ram_ptr()?
> > For example s->vram_ptr set by vga_common_init during machine->init()?
> > If the actual memory is only allocated at the end of restore, vram_ptr
> > would be bogus at least until then and we would still need a way to
> > update it afterwards.
> 
> One way is to only call it on demand when we actually need to draw or
> read the framebuffer.  Currently this will be slow since we'll search
> the RAMBlock list, but soon it will be dereference of MemoryRegion.

given that there is only one access to the framebuffer after
vga_common_init and before cirrus_post_load, that is the framebuffer
memset to 0xff, and given that it is actually useless to memset the
framebuffer on restore because it is going to be overwritten anyway
afterwards, I suggest keeping the second hunk of
http://marc.info/?l=qemu-devel&m=132346828427314&w=2 instead


> > BTW what you are suggesting is not so different from what was done by
> > Anthony in the last patch series he sent. See the following (ugly) patch
> > to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
> > completed and then update the pointer:
> >
> > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> 
> I see.
> 
> Maybe we can put the xen_address in the cirrus vmstate?  That way there
> is no ordering issue at all.  Of course we have to make sure it isn't
> saved/restored for non-xen, but that's doable with a predicate attached
> to the field.

Introducing a xen_address field to the cirrus vmstate is good: it would
let us avoid playing tricks with the mapcache to understand where to map
what. It would also avoid nasty ordering issues, like you say.
However we would still need a xen specific "if" in cirrus_post_load, to
update vram_ptr correctly, similarly to the first hunk of the patch
linked above.


> > > - updating the mapped address during restore
> > > 
> > > I think this is cleaner than introducing a new migration stage, but the
> > > implementation may prove otherwise.
> >
> > see patch above, a good summary of the difficulties of this approach
> >
> >
> > > > > xen_register_framebuffer() is slightly less hacky.
> > > >
> > > > I agree, however xen_register_framebuffer is called after
> > > > memory_region_init_ram, so the allocation would have been made already.
> > > 
> > > xen_ram_alloc(MemoryRegion *mr)
> > > {
> > >     if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
> > >         return;
> > >     }
> > > }
> > > 
> > > xen_framebuffer_address_post_load()
> > > {
> > >     framebuffer_addr_known = true;
> > >     if (framebuffer) {
> > >         framebuffer->xen_address = framebuffer_addr;
> > >     }
> > > }
> > > 
> > > (ugly way of avoiding a dependency, but should work)
> >  
> > The issue is that xen_ram_alloc is called by memory_region_init_ram
> > before xen_register_framebuffer is called (see the order of calls in
> > vga_common_init).
> > So when xen_ram_alloc is called framebuffer is still NULL: mr !=
> > framebuffer.
> 
> Yup.  We could invert the order.  It's really ugly though to pass the
> address of an uninitialized structure.

OK. Maybe we have a plan :-)


Let me summarize what we have come up with so far:

- we move the call to xen_register_framebuffer before
memory_region_init_ram in vga_common_init;

- we prevent xen_ram_alloc from allocating a second framebuffer on
restore, checking for mr == framebuffer;

- we avoid memsetting the framebuffer on restore (useless anyway, the
videoram is going to be loaded from the savefile in the general case);

- we introduce a xen_address field to cirrus_vmstate and we use it
to map the videoram into qemu's address space and update vram_ptr in
cirrus_post_load.


Does it make sense? Do you agree with the approach?

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:22:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir0b-0006DV-Mw; Thu, 05 Jan 2012 17:21:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rir0a-0006DB-8V
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:21:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325784097!7913592!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22651 invoked from network); 5 Jan 2012 17:21:38 -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;
	5 Jan 2012 17:21:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:21: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; Thu, 5 Jan 2012 17:21:37 +0000
Date: Thu, 5 Jan 2012 17:21:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F05D0BC.70707@redhat.com>
Message-ID: <alpine.DEB.2.00.1201051646580.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
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 Thu, 5 Jan 2012, Avi Kivity wrote:
> On 01/05/2012 05:53 PM, Stefano Stabellini wrote:
> >
> > > This involves:
> > > - adding vmstate to xen-all.c so it can migrate the xen vram address
> >
> > Easy so far.
> >
> >
> > > - making sure the memory core doesn't do mappings during restore (can be
> > > done by wrapping restore with
> > > memory_region_transaction_begin()/memory_region_transaction_commit();
> > > beneficial to normal qemu migrations as well)
> >
> > Besides restore we would also need to wrap machine->init() with
> > memory_region_transaction_begin()/memory_region_transaction_commit(),
> > so that all the mappings are only done at the end of restore, when we do
> > know the videoram address.
> >
> > This seems unfeasable to me: what about all the addresses set in the
> > meantime using memory_region_get_ram_ptr()?
> > For example s->vram_ptr set by vga_common_init during machine->init()?
> > If the actual memory is only allocated at the end of restore, vram_ptr
> > would be bogus at least until then and we would still need a way to
> > update it afterwards.
> 
> One way is to only call it on demand when we actually need to draw or
> read the framebuffer.  Currently this will be slow since we'll search
> the RAMBlock list, but soon it will be dereference of MemoryRegion.

given that there is only one access to the framebuffer after
vga_common_init and before cirrus_post_load, that is the framebuffer
memset to 0xff, and given that it is actually useless to memset the
framebuffer on restore because it is going to be overwritten anyway
afterwards, I suggest keeping the second hunk of
http://marc.info/?l=qemu-devel&m=132346828427314&w=2 instead


> > BTW what you are suggesting is not so different from what was done by
> > Anthony in the last patch series he sent. See the following (ugly) patch
> > to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
> > completed and then update the pointer:
> >
> > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> 
> I see.
> 
> Maybe we can put the xen_address in the cirrus vmstate?  That way there
> is no ordering issue at all.  Of course we have to make sure it isn't
> saved/restored for non-xen, but that's doable with a predicate attached
> to the field.

Introducing a xen_address field to the cirrus vmstate is good: it would
let us avoid playing tricks with the mapcache to understand where to map
what. It would also avoid nasty ordering issues, like you say.
However we would still need a xen specific "if" in cirrus_post_load, to
update vram_ptr correctly, similarly to the first hunk of the patch
linked above.


> > > - updating the mapped address during restore
> > > 
> > > I think this is cleaner than introducing a new migration stage, but the
> > > implementation may prove otherwise.
> >
> > see patch above, a good summary of the difficulties of this approach
> >
> >
> > > > > xen_register_framebuffer() is slightly less hacky.
> > > >
> > > > I agree, however xen_register_framebuffer is called after
> > > > memory_region_init_ram, so the allocation would have been made already.
> > > 
> > > xen_ram_alloc(MemoryRegion *mr)
> > > {
> > >     if (in_restore && mr == framebuffer && !framebuffer_addr_known) {
> > >         return;
> > >     }
> > > }
> > > 
> > > xen_framebuffer_address_post_load()
> > > {
> > >     framebuffer_addr_known = true;
> > >     if (framebuffer) {
> > >         framebuffer->xen_address = framebuffer_addr;
> > >     }
> > > }
> > > 
> > > (ugly way of avoiding a dependency, but should work)
> >  
> > The issue is that xen_ram_alloc is called by memory_region_init_ram
> > before xen_register_framebuffer is called (see the order of calls in
> > vga_common_init).
> > So when xen_ram_alloc is called framebuffer is still NULL: mr !=
> > framebuffer.
> 
> Yup.  We could invert the order.  It's really ugly though to pass the
> address of an uninitialized structure.

OK. Maybe we have a plan :-)


Let me summarize what we have come up with so far:

- we move the call to xen_register_framebuffer before
memory_region_init_ram in vga_common_init;

- we prevent xen_ram_alloc from allocating a second framebuffer on
restore, checking for mr == framebuffer;

- we avoid memsetting the framebuffer on restore (useless anyway, the
videoram is going to be loaded from the savefile in the general case);

- we introduce a xen_address field to cirrus_vmstate and we use it
to map the videoram into qemu's address space and update vram_ptr in
cirrus_post_load.


Does it make sense? Do you agree with the approach?

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:24:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rir2c-0006NX-JC; Thu, 05 Jan 2012 17:23:50 +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 1Rir2b-0006N8-GE
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:23:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325784221!9733316!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 31811 invoked from network); 5 Jan 2012 17:23:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 17:23:43 -0000
Received: by daec6 with SMTP id c6so2024558dae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 09:23: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=1x12Gt6yJzLV7ML4qDwUAbgYt1cmXtHDBbwISIbaPp8=;
	b=HwMKRXZcr954nOpVFnjUi9OeLzrDComve8TOqeIQyDLJITYw+DwUhsj1o6el6mZE1K
	LlyYzedpuiZFDXjemdhT7bJa1CF2DTzOjEtImcEZLdaT3sPC9lNTxg+9WwsJYFZyIrHH
	KQ+Dt+DSrisLP73WIMcjAEZ3szB1xAtDrwNu8=
MIME-Version: 1.0
Received: by 10.68.72.8 with SMTP id z8mr7002539pbu.111.1325784221052; Thu, 05
	Jan 2012 09:23:41 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Thu, 5 Jan 2012 09:23:40 -0800 (PST)
In-Reply-To: <1325783931.25206.417.camel@zakaz.uk.xensource.com>
References: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
	<20229.46603.265055.83034@mariner.uk.xensource.com>
	<1325783931.25206.417.camel@zakaz.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:23:40 +0100
X-Google-Sender-Auth: Ag2L7wi9Yu7elrZhxJhR9evujtI
Message-ID: <CAPLaKK56eC0VD+NNMdmjAnTnFPv118ZWL9dgVWfrt51UYUpV8A@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>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzUgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gVGh1
LCAyMDEyLTAxLTA1IGF0IDE0OjM5ICswMDAwLCBJYW4gSmFja3NvbiB3cm90ZToKPj4gPiBpcHhl
OiB1cGRhdGUgdG8gdXBzdHJlYW0gdmVyc2lvbgo+Pgo+PiBDb21taXR0ZWQtYnk6IElhbiBKYWNr
c29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgo+Cj4gSSdtIGd1ZXNzaW5nIHRoaXMgaXMg
dGhlIGNhdXNlIG9mOgo+Cj4gbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbG9jYWwvc2Ny
YXRjaC9pYW5jL2RldmVsL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3Qn
Cj4gcm0gLXJmIGlweGUKPiBnemlwIC1kYyBpcHhlLnRhci5neiB8IHRhciB4ZiAtCj4gZm9yIGkg
aW4gJChjYXQgcGF0Y2hlcy9zZXJpZXMpIDsgZG8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgXAo+
IMKgIMKgIMKgIMKgIMKgIMKgcGF0Y2ggLWQgaXB4ZSAtcDEgLS1xdWlldCA8cGF0Y2hlcy8kaSB8
fCBleGl0IDEgOyBcCj4gwqAgwqAgwqAgwqBkb25lCj4gMSBvdXQgb2YgNCBodW5rcyBGQUlMRUQg
LS0gc2F2aW5nIHJlamVjdHMgdG8gZmlsZSBzcmMvYXJjaC9pMzg2L3ByZWZpeC9yb21wcmVmaXgu
Uy5yZWoKPiBtYWtlWzZdOiAqKiogW2lweGUvc3JjL2FyY2gvaTM4Ni9NYWtlZmlsZV0gRXJyb3Ig
MQo+IG1ha2VbNl06IExlYXZpbmcgZGlyZWN0b3J5IGAvbG9jYWwvc2NyYXRjaC9pYW5jL2RldmVs
L3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QnCj4KPiBUaGlzIHNlZW1z
IHRvIGJlIGZpeGVkIChvciBhdCBsZWFzdCBtaXRpZ2F0ZWQpIGJ5IHByb3Blcmx5IHJlbW92aW5n
IHRoZQo+IHRhcmJhbGwgb24gY2xlYW46CgpTb3JyeSwgSSBkaWQgdGhpcyBwYXRjaCBvbiBhIGZy
ZXNoIGNoZWNrb3V0LCBzbyBJIGRpZG4ndCByZWFsaXplIG9mCnRoaXMgcHJvYmxlbSwgdGhlIE1h
a2VmaWxlIHdpbGwgYWx3YXlzIHRyeSB0byB1c2UgaXB4ZS50YXIuZ3ogaWYKdGhlcmUncyBvbmUg
b24gdGhlIGZvbGRlci4gVGhhbmtzIGZvciB0aGUgcGF0Y2ghCgo+IDg8LS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ICMgVXNl
ciBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+ICMgRGF0ZSAxMzI1Nzgz
ODU2IDAKPiAjIE5vZGUgSUQgMGZjZmQ2MjE2NmRlMTE2ODdhYzJkYjc5OWI3MTkwNmU3Y2U0MTMw
MAo+ICMgUGFyZW50IMKgZjI2ODJlMmVjN2U1MzY4M2EzMWU5NDBhZGEzNzcyNmFhOGRhN2ZjYwo+
IGlweGU6IHJlbW92ZSB0YXJiYWxsIG9uIGNsZWFuCj4KPiBUaGlzIHByZXZlbnRzIHVzIHBpY2tp
bmcgdXAgYSBzdGFsZSB0YXJiYWxsIHdoZW4gdGhlIHRhZyBjaGFuZ2VzLgo+Cj4gU2lnbmVkLW9m
Zi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPgo+IGRpZmYgLXIg
ZjI2ODJlMmVjN2U1IC1yIDBmY2ZkNjIxNjZkZSB0b29scy9maXJtd2FyZS9ldGhlcmJvb3QvTWFr
ZWZpbGUKPiAtLS0gYS90b29scy9maXJtd2FyZS9ldGhlcmJvb3QvTWFrZWZpbGUgVGh1IEphbiAw
NSAxNjozMzoyNSAyMDEyICswMDAwCj4gKysrIGIvdG9vbHMvZmlybXdhcmUvZXRoZXJib290L01h
a2VmaWxlIFRodSBKYW4gMDUgMTc6MTc6MzYgMjAxMiArMDAwMAo+IEBAIC01Niw3ICs1Niw3IEBA
IGViLXJvbXMuaDogQ29uZmlnCj4KPiDCoC5QSE9OWTogY2xlYW4KPiDCoGNsZWFuOgo+IC0gwqAg
wqAgwqAgcm0gLXJmICREICRELmdpdCAqfiBlYi1yb21zLmggXyRUCj4gKyDCoCDCoCDCoCBybSAt
cmYgJEQgJEQuZ2l0ICp+IGViLXJvbXMuaCBfJFQgJFQKPgo+IMKgLlBIT05ZOiBkaXN0Y2xlYW4K
PiDCoGRpc3RjbGVhbjogY2xlYW4KPgo+Cj4gSWFuLgo+Cj4KCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:24:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:24:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rir2c-0006NX-JC; Thu, 05 Jan 2012 17:23:50 +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 1Rir2b-0006N8-GE
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:23:49 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325784221!9733316!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 31811 invoked from network); 5 Jan 2012 17:23:43 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 17:23:43 -0000
Received: by daec6 with SMTP id c6so2024558dae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 09:23: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=1x12Gt6yJzLV7ML4qDwUAbgYt1cmXtHDBbwISIbaPp8=;
	b=HwMKRXZcr954nOpVFnjUi9OeLzrDComve8TOqeIQyDLJITYw+DwUhsj1o6el6mZE1K
	LlyYzedpuiZFDXjemdhT7bJa1CF2DTzOjEtImcEZLdaT3sPC9lNTxg+9WwsJYFZyIrHH
	KQ+Dt+DSrisLP73WIMcjAEZ3szB1xAtDrwNu8=
MIME-Version: 1.0
Received: by 10.68.72.8 with SMTP id z8mr7002539pbu.111.1325784221052; Thu, 05
	Jan 2012 09:23:41 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Thu, 5 Jan 2012 09:23:40 -0800 (PST)
In-Reply-To: <1325783931.25206.417.camel@zakaz.uk.xensource.com>
References: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
	<20229.46603.265055.83034@mariner.uk.xensource.com>
	<1325783931.25206.417.camel@zakaz.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:23:40 +0100
X-Google-Sender-Auth: Ag2L7wi9Yu7elrZhxJhR9evujtI
Message-ID: <CAPLaKK56eC0VD+NNMdmjAnTnFPv118ZWL9dgVWfrt51UYUpV8A@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>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzUgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gVGh1
LCAyMDEyLTAxLTA1IGF0IDE0OjM5ICswMDAwLCBJYW4gSmFja3NvbiB3cm90ZToKPj4gPiBpcHhl
OiB1cGRhdGUgdG8gdXBzdHJlYW0gdmVyc2lvbgo+Pgo+PiBDb21taXR0ZWQtYnk6IElhbiBKYWNr
c29uIDxpYW4uamFja3NvbkBldS5jaXRyaXguY29tPgo+Cj4gSSdtIGd1ZXNzaW5nIHRoaXMgaXMg
dGhlIGNhdXNlIG9mOgo+Cj4gbWFrZVs2XTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvbG9jYWwvc2Ny
YXRjaC9pYW5jL2RldmVsL3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3Qn
Cj4gcm0gLXJmIGlweGUKPiBnemlwIC1kYyBpcHhlLnRhci5neiB8IHRhciB4ZiAtCj4gZm9yIGkg
aW4gJChjYXQgcGF0Y2hlcy9zZXJpZXMpIDsgZG8gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgXAo+
IMKgIMKgIMKgIMKgIMKgIMKgcGF0Y2ggLWQgaXB4ZSAtcDEgLS1xdWlldCA8cGF0Y2hlcy8kaSB8
fCBleGl0IDEgOyBcCj4gwqAgwqAgwqAgwqBkb25lCj4gMSBvdXQgb2YgNCBodW5rcyBGQUlMRUQg
LS0gc2F2aW5nIHJlamVjdHMgdG8gZmlsZSBzcmMvYXJjaC9pMzg2L3ByZWZpeC9yb21wcmVmaXgu
Uy5yZWoKPiBtYWtlWzZdOiAqKiogW2lweGUvc3JjL2FyY2gvaTM4Ni9NYWtlZmlsZV0gRXJyb3Ig
MQo+IG1ha2VbNl06IExlYXZpbmcgZGlyZWN0b3J5IGAvbG9jYWwvc2NyYXRjaC9pYW5jL2RldmVs
L3hlbi11bnN0YWJsZS5oZy90b29scy9maXJtd2FyZS9ldGhlcmJvb3QnCj4KPiBUaGlzIHNlZW1z
IHRvIGJlIGZpeGVkIChvciBhdCBsZWFzdCBtaXRpZ2F0ZWQpIGJ5IHByb3Blcmx5IHJlbW92aW5n
IHRoZQo+IHRhcmJhbGwgb24gY2xlYW46CgpTb3JyeSwgSSBkaWQgdGhpcyBwYXRjaCBvbiBhIGZy
ZXNoIGNoZWNrb3V0LCBzbyBJIGRpZG4ndCByZWFsaXplIG9mCnRoaXMgcHJvYmxlbSwgdGhlIE1h
a2VmaWxlIHdpbGwgYWx3YXlzIHRyeSB0byB1c2UgaXB4ZS50YXIuZ3ogaWYKdGhlcmUncyBvbmUg
b24gdGhlIGZvbGRlci4gVGhhbmtzIGZvciB0aGUgcGF0Y2ghCgo+IDg8LS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ICMgVXNl
ciBJYW4gQ2FtcGJlbGwgPGlhbi5jYW1wYmVsbEBjaXRyaXguY29tPgo+ICMgRGF0ZSAxMzI1Nzgz
ODU2IDAKPiAjIE5vZGUgSUQgMGZjZmQ2MjE2NmRlMTE2ODdhYzJkYjc5OWI3MTkwNmU3Y2U0MTMw
MAo+ICMgUGFyZW50IMKgZjI2ODJlMmVjN2U1MzY4M2EzMWU5NDBhZGEzNzcyNmFhOGRhN2ZjYwo+
IGlweGU6IHJlbW92ZSB0YXJiYWxsIG9uIGNsZWFuCj4KPiBUaGlzIHByZXZlbnRzIHVzIHBpY2tp
bmcgdXAgYSBzdGFsZSB0YXJiYWxsIHdoZW4gdGhlIHRhZyBjaGFuZ2VzLgo+Cj4gU2lnbmVkLW9m
Zi1ieTogSWFuIENhbXBiZWxsIDxpYW4uY2FtcGJlbGxAY2l0cml4LmNvbT4KPgo+IGRpZmYgLXIg
ZjI2ODJlMmVjN2U1IC1yIDBmY2ZkNjIxNjZkZSB0b29scy9maXJtd2FyZS9ldGhlcmJvb3QvTWFr
ZWZpbGUKPiAtLS0gYS90b29scy9maXJtd2FyZS9ldGhlcmJvb3QvTWFrZWZpbGUgVGh1IEphbiAw
NSAxNjozMzoyNSAyMDEyICswMDAwCj4gKysrIGIvdG9vbHMvZmlybXdhcmUvZXRoZXJib290L01h
a2VmaWxlIFRodSBKYW4gMDUgMTc6MTc6MzYgMjAxMiArMDAwMAo+IEBAIC01Niw3ICs1Niw3IEBA
IGViLXJvbXMuaDogQ29uZmlnCj4KPiDCoC5QSE9OWTogY2xlYW4KPiDCoGNsZWFuOgo+IC0gwqAg
wqAgwqAgcm0gLXJmICREICRELmdpdCAqfiBlYi1yb21zLmggXyRUCj4gKyDCoCDCoCDCoCBybSAt
cmYgJEQgJEQuZ2l0ICp+IGViLXJvbXMuaCBfJFQgJFQKPgo+IMKgLlBIT05ZOiBkaXN0Y2xlYW4K
PiDCoGRpc3RjbGVhbjogY2xlYW4KPgo+Cj4gSWFuLgo+Cj4KCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRl
dmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRl
dmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:25:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rir3u-0006UQ-Tl; Thu, 05 Jan 2012 17:25:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rir3s-0006T8-Pw
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29499 invoked from network); 5 Jan 2012 17:25:03 -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;
	5 Jan 2012 17:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:25: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, 5 Jan 2012 17:25: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
	1Riqxa-0001eZ-V0; Thu, 05 Jan 2012 17:18:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Riqxa-0000W4-UD;
	Thu, 05 Jan 2012 17:18:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56174.919167.483587@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:18:38 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
References: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] pygrub: fix extlinux parsing"):
> pygrub: fix extlinux parsing
> 
> pygrub was unable to parse extlinux config files correctly, exactly
> the ones like:

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 Jan 05 17:25:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:25:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rir3u-0006UQ-Tl; Thu, 05 Jan 2012 17:25:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rir3s-0006T8-Pw
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29499 invoked from network); 5 Jan 2012 17:25:03 -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;
	5 Jan 2012 17:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843593"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:25: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, 5 Jan 2012 17:25: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
	1Riqxa-0001eZ-V0; Thu, 05 Jan 2012 17:18:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Riqxa-0000W4-UD;
	Thu, 05 Jan 2012 17:18:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56174.919167.483587@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:18:38 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
References: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] pygrub: fix extlinux parsing"):
> pygrub: fix extlinux parsing
> 
> pygrub was unable to parse extlinux config files correctly, exactly
> the ones like:

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 Jan 05 17:25:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir3v-0006UZ-A4; Thu, 05 Jan 2012 17:25: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 1Rir3t-0006T9-1j
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29516 invoked from network); 5 Jan 2012 17:25:03 -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;
	5 Jan 2012 17:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843594"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:25: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, 5 Jan 2012 17:25: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
	1Riqw9-0001e0-Tm; Thu, 05 Jan 2012 17:17:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Riqw9-0000Vk-T5;
	Thu, 05 Jan 2012 17:17:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56085.887104.932449@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:17:09 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
References: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: anthony.perard@citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: adjust MSI-X related log 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

Jan Beulich writes ("[Xen-devel] [PATCH] qemu-xen: adjust MSI-X related log messages"):
> Several of these messages we coded using line continuation within a
> string literal. This is generally not recommended and also lead to odd
> sequences of many blanks in the middle of the messages.
> 
> The message indicating a discarded write due to MSI-X already being
> enabled doesn't need to be issued when a write doesn't actually modify
> the current value. Adjust the surrounding logic accordingly, and
> eliminate some redundancy as well as the sometimes unnecessary access
> to the physical MSI-X table.
> 
> Finally, adjust the wording of a few messages to be more precise and/or
> more useful.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.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 Jan 05 17:25:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir3v-0006UZ-A4; Thu, 05 Jan 2012 17:25: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 1Rir3t-0006T9-1j
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29516 invoked from network); 5 Jan 2012 17:25:03 -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;
	5 Jan 2012 17:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843594"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:25: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, 5 Jan 2012 17:25: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
	1Riqw9-0001e0-Tm; Thu, 05 Jan 2012 17:17:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Riqw9-0000Vk-T5;
	Thu, 05 Jan 2012 17:17:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56085.887104.932449@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:17:09 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
References: <4F02E726020000780006A2C9@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: anthony.perard@citrix.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: adjust MSI-X related log 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

Jan Beulich writes ("[Xen-devel] [PATCH] qemu-xen: adjust MSI-X related log messages"):
> Several of these messages we coded using line continuation within a
> string literal. This is generally not recommended and also lead to odd
> sequences of many blanks in the middle of the messages.
> 
> The message indicating a discarded write due to MSI-X already being
> enabled doesn't need to be issued when a write doesn't actually modify
> the current value. Adjust the surrounding logic accordingly, and
> eliminate some redundancy as well as the sometimes unnecessary access
> to the physical MSI-X table.
> 
> Finally, adjust the wording of a few messages to be more precise and/or
> more useful.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.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 Jan 05 17:25:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir3t-0006Tj-2D; Thu, 05 Jan 2012 17:25:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rir3r-0006T3-U2
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29411 invoked from network); 5 Jan 2012 17:25:02 -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;
	5 Jan 2012 17:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:25: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, 5 Jan 2012 17:25: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
	1RiqtE-0001cp-2A; Thu, 05 Jan 2012 17:14:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RiqtE-0000Sa-1K;
	Thu, 05 Jan 2012 17:14:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.55903.874059.318852@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:14:07 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1325585762.25206.25.camel@zakaz.uk.xensource.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
	<1325585762.25206.25.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"florian.heigl@gmail.com" <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/2] libxl: write vifname in xenstore if set."):
> On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> > Simple fix to enable user to specify vif names.
...
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

both

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 Jan 05 17:25:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir3u-0006UE-Ff; Thu, 05 Jan 2012 17:25:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rir3s-0006T4-64
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29455 invoked from network); 5 Jan 2012 17:25:02 -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;
	5 Jan 2012 17:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843591"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17: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; Thu, 5 Jan 2012 17:25: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
	1Rir0H-0001fa-PV; Thu, 05 Jan 2012 17:21:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rir0H-0000XI-Og;
	Thu, 05 Jan 2012 17:21:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56341.752814.143434@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:21:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1325783931.25206.417.camel@zakaz.uk.xensource.com>
References: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
	<20229.46603.265055.83034@mariner.uk.xensource.com>
	<1325783931.25206.417.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>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] ipxe: update to upstream version"):
> ipxe: remove tarball on clean
> 
> This prevents us picking up a stale tarball when the tag changes.
> 
> Signed-off-by: Ian Campbell <ian.campbell@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 Thu Jan 05 17:25:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir3t-0006Tj-2D; Thu, 05 Jan 2012 17:25:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rir3r-0006T3-U2
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29411 invoked from network); 5 Jan 2012 17:25:02 -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;
	5 Jan 2012 17:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:25: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, 5 Jan 2012 17:25: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
	1RiqtE-0001cp-2A; Thu, 05 Jan 2012 17:14:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RiqtE-0000Sa-1K;
	Thu, 05 Jan 2012 17:14:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.55903.874059.318852@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:14:07 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1325585762.25206.25.camel@zakaz.uk.xensource.com>
References: <1325157276-4847-1-git-send-email-wei.liu2@citrix.com>
	<1325157276-4847-3-git-send-email-wei.liu2@citrix.com>
	<1325585762.25206.25.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "andy@strugglers.net" <andy@strugglers.net>,
	"florian.heigl@gmail.com" <florian.heigl@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/2] libxl: write vifname in xenstore if set."):
> On Thu, 2011-12-29 at 11:14 +0000, Wei Liu wrote:
> > Simple fix to enable user to specify vif names.
...
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>

both

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 Jan 05 17:25:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir3u-0006UE-Ff; Thu, 05 Jan 2012 17:25:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rir3s-0006T4-64
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29455 invoked from network); 5 Jan 2012 17:25:02 -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;
	5 Jan 2012 17:25:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843591"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17: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; Thu, 5 Jan 2012 17:25: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
	1Rir0H-0001fa-PV; Thu, 05 Jan 2012 17:21:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rir0H-0000XI-Og;
	Thu, 05 Jan 2012 17:21:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56341.752814.143434@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:21:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1325783931.25206.417.camel@zakaz.uk.xensource.com>
References: <cf68eb390e1bf2fa4bb0.1324365732@alpine.localdomain>
	<20229.46603.265055.83034@mariner.uk.xensource.com>
	<1325783931.25206.417.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>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [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

Ian Campbell writes ("Re: [Xen-devel] [PATCH v2] ipxe: update to upstream version"):
> ipxe: remove tarball on clean
> 
> This prevents us picking up a stale tarball when the tag changes.
> 
> Signed-off-by: Ian Campbell <ian.campbell@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 Thu Jan 05 17:25:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rir3v-0006Um-Nx; Thu, 05 Jan 2012 17:25: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 1Rir3t-0006TB-DL
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29524 invoked from network); 5 Jan 2012 17:25:03 -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;
	5 Jan 2012 17:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:25: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, 5 Jan 2012 17:25: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
	1RiqvK-0001dX-Ru; Thu, 05 Jan 2012 17:16:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RiqvK-0000VI-R4;
	Thu, 05 Jan 2012 17:16:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56034.824282.816127@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:16:18 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201041439150.2970@kaball-desktop>
References: <4F02E42E020000780006A2B6@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201041439150.2970@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: fix sequence of operations
	in	pt_msix_init()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu-xen: fix sequence of operations in pt_msix_init()"):
> On Tue, 3 Jan 2012, Jan Beulich wrote:
> > Checking the return value of mmap() must be done before adjusting the
> > value, otherwise failure may not be detected.
> > 
> > Closing the file handle, on the other hand, can be done before checking
> > the return value.
> > 
> > Finally, printing the errno value without knowing whether the previous
> > function actually failed is bogus (and superfluous since a subsequent
> > message prints the strerror() representaton anyway).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> acked

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 Jan 05 17:25:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rir3v-0006Um-Nx; Thu, 05 Jan 2012 17:25: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 1Rir3t-0006TB-DL
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:25:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325784301!10642722!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29524 invoked from network); 5 Jan 2012 17:25:03 -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;
	5 Jan 2012 17:25:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:25: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, 5 Jan 2012 17:25: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
	1RiqvK-0001dX-Ru; Thu, 05 Jan 2012 17:16:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RiqvK-0000VI-R4;
	Thu, 05 Jan 2012 17:16:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56034.824282.816127@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:16:18 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201041439150.2970@kaball-desktop>
References: <4F02E42E020000780006A2B6@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201041439150.2970@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: fix sequence of operations
	in	pt_msix_init()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] qemu-xen: fix sequence of operations in pt_msix_init()"):
> On Tue, 3 Jan 2012, Jan Beulich wrote:
> > Checking the return value of mmap() must be done before adjusting the
> > value, otherwise failure may not be detected.
> > 
> > Closing the file handle, on the other hand, can be done before checking
> > the return value.
> > 
> > Finally, printing the errno value without knowing whether the previous
> > function actually failed is bogus (and superfluous since a subsequent
> > message prints the strerror() representaton anyway).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> acked

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 Jan 05 17:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir5Z-0006vn-8L; Thu, 05 Jan 2012 17:26:53 +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 1Rir5Y-0006uc-Gl
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:26:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325784406!7279421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25725 invoked from network); 5 Jan 2012 17:26:46 -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;
	5 Jan 2012 17:26:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:26: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, 5 Jan 2012 17:26: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
	1Rir5R-0001iE-HD; Thu, 05 Jan 2012 17:26:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rir5R-0000YN-GR;
	Thu, 05 Jan 2012 17:26:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56661.417963.236595@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:26:45 +0000
To: James Harper <james.harper@bendigoit.com.au>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094067@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B094067@BITCOM1.int.sbss.com.au>
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] /bin/sh vs trap in vscsi 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

James Harper writes ("[Xen-devel] /bin/sh vs trap in vscsi hotplug script"):
> The other hotplug scripts have #!/bin/bash but vscsi has #!/bin/sh, and I think that trap in xen-hotplug-common.sh is a bashism, or at least isn't liked by the Debian default shell dash.
> 
> What is the bug here? The incompatible shell specified in vscsi hotplug script, or "trap sigerr ERR" in xen-hotplug-common.sh?

I think "trap ... ERR" is a very useful feature which it would be
irritating to do without.  So I should change the #!

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1Rir5Z-0006vn-8L; Thu, 05 Jan 2012 17:26:53 +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 1Rir5Y-0006uc-Gl
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:26:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325784406!7279421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25725 invoked from network); 5 Jan 2012 17:26:46 -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;
	5 Jan 2012 17:26:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:26: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, 5 Jan 2012 17:26: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
	1Rir5R-0001iE-HD; Thu, 05 Jan 2012 17:26:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rir5R-0000YN-GR;
	Thu, 05 Jan 2012 17:26:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.56661.417963.236595@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:26:45 +0000
To: James Harper <james.harper@bendigoit.com.au>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B094067@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B094067@BITCOM1.int.sbss.com.au>
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] /bin/sh vs trap in vscsi 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

James Harper writes ("[Xen-devel] /bin/sh vs trap in vscsi hotplug script"):
> The other hotplug scripts have #!/bin/bash but vscsi has #!/bin/sh, and I think that trap in xen-hotplug-common.sh is a bashism, or at least isn't liked by the Debian default shell dash.
> 
> What is the bug here? The incompatible shell specified in vscsi hotplug script, or "trap sigerr ERR" in xen-hotplug-common.sh?

I think "trap ... ERR" is a very useful feature which it would be
irritating to do without.  So I should change the #!

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:41:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1RirJT-0007ja-6T; Thu, 05 Jan 2012 17: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 1RirJR-0007jS-Nr
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:41:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325785267!9754330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26403 invoked from network); 5 Jan 2012 17:41:07 -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;
	5 Jan 2012 17:41:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:40: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; Thu, 5 Jan 2012 17:40: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
	1RirJ1-0001n0-4S; Thu, 05 Jan 2012 17:40:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RirJ1-0000Zc-3b;
	Thu, 05 Jan 2012 17:40:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.57503.64455.14463@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:40:47 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120104104654.GA5554@aepfle.de>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
	<20120104104654.GA5554@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Adin Scannell <adin@scannell.ca>
Subject: Re: [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

Olaf Hering writes ("Re: [Xen-devel] [PATCH] Only retry mapping pages when ENOENT is returned"):
> In linux-2.6.18-xen.hg the ioctl could in theory return -ENOMEM in a
> later iteration and maybe even other values if the guest was destroyed
> meanwhile. So checking also errno for ENOENT is good, because thats the
> return code if any of the requested gfns is still in paged-out state.
> 
> Acked-by: Olaf Hering <olaf@aepfle.de>

Thanks.  Adin, would you care to sign it off, indicating your
confirmation that the Developer's Certificate of Origin applies  ?
See  http://wiki.xen.org/wiki/SubmittingXenPatches

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 Jan 05 17:41:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1RirJT-0007ja-6T; Thu, 05 Jan 2012 17: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 1RirJR-0007jS-Nr
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:41:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325785267!9754330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26403 invoked from network); 5 Jan 2012 17:41:07 -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;
	5 Jan 2012 17:41:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:40: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; Thu, 5 Jan 2012 17:40: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
	1RirJ1-0001n0-4S; Thu, 05 Jan 2012 17:40:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RirJ1-0000Zc-3b;
	Thu, 05 Jan 2012 17:40:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.57503.64455.14463@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:40:47 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120104104654.GA5554@aepfle.de>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
	<20120104104654.GA5554@aepfle.de>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Adin Scannell <adin@scannell.ca>
Subject: Re: [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

Olaf Hering writes ("Re: [Xen-devel] [PATCH] Only retry mapping pages when ENOENT is returned"):
> In linux-2.6.18-xen.hg the ioctl could in theory return -ENOMEM in a
> later iteration and maybe even other values if the guest was destroyed
> meanwhile. So checking also errno for ENOENT is good, because thats the
> return code if any of the requested gfns is still in paged-out state.
> 
> Acked-by: Olaf Hering <olaf@aepfle.de>

Thanks.  Adin, would you care to sign it off, indicating your
confirmation that the Developer's Certificate of Origin applies  ?
See  http://wiki.xen.org/wiki/SubmittingXenPatches

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 Jan 05 17:49:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1RirRV-0007tg-4v; Thu, 05 Jan 2012 17:49: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 1RirRU-0007tb-3X
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:49:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325785766!9690810!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14673 invoked from network); 5 Jan 2012 17:49:26 -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;
	5 Jan 2012 17:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:49: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, 5 Jan 2012 17:49: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
	1RirRN-0001ps-DC; Thu, 05 Jan 2012 17:49:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RirRN-0000aO-CH;
	Thu, 05 Jan 2012 17:49:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.58021.365808.925949@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:49:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] RFC: Still TODO for 4.2?"):
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
> 
> hypervisor:
> 
>       * ??? - Keir, Tim, Jan?
> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:

Relatedly, xl should have a json-based querier intended for users to
not have to use the weird handwritten sexp printfs.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:49:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17: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 1RirRV-0007tg-4v; Thu, 05 Jan 2012 17:49: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 1RirRU-0007tb-3X
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:49:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325785766!9690810!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14673 invoked from network); 5 Jan 2012 17:49:26 -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;
	5 Jan 2012 17:49:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,462,1320624000"; 
   d="scan'208";a="9843949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 17:49: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, 5 Jan 2012 17:49: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
	1RirRN-0001ps-DC; Thu, 05 Jan 2012 17:49:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RirRN-0000aO-CH;
	Thu, 05 Jan 2012 17:49:25 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.58021.365808.925949@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 17:49:25 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] RFC: Still TODO for 4.2?"):
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
> 
> hypervisor:
> 
>       * ??? - Keir, Tim, Jan?
> 
> tools:
> 
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:

Relatedly, xl should have a json-based querier intended for users to
not have to use the weird handwritten sexp printfs.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 17:51:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:51:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RirT0-0007zB-Qx; Thu, 05 Jan 2012 17:51:06 +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 1RirSz-0007z0-BB
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:51:05 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325785808!59672991!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5085 invoked from network); 5 Jan 2012 17:50:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	5 Jan 2012 17:50:09 -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 q05HoxdF013889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 12:51:00 -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 q05Hovid021914; Thu, 5 Jan 2012 12:50:58 -0500
Message-ID: <4F05E301.2020808@redhat.com>
Date: Thu, 05 Jan 2012 19:50:57 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
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 01/05/2012 07:21 PM, Stefano Stabellini wrote:
> > > BTW what you are suggesting is not so different from what was done by
> > > Anthony in the last patch series he sent. See the following (ugly) patch
> > > to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
> > > completed and then update the pointer:
> > >
> > > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> > 
> > I see.
> > 
> > Maybe we can put the xen_address in the cirrus vmstate?  That way there
> > is no ordering issue at all.  Of course we have to make sure it isn't
> > saved/restored for non-xen, but that's doable with a predicate attached
> > to the field.
>
> Introducing a xen_address field to the cirrus vmstate is good: it would
> let us avoid playing tricks with the mapcache to understand where to map
> what. It would also avoid nasty ordering issues, like you say.
> However we would still need a xen specific "if" in cirrus_post_load, to
> update vram_ptr correctly, similarly to the first hunk of the patch
> linked above.

While the fear of accelerator-specific hooks in device code is healthy,
at some point we have to let go.  Designing elaborate abstraction layers
around a specific problem with a not-so-good interface just makes the
problem worse.  If we have to have an if there, so be it.

> > 
> > Yup.  We could invert the order.  It's really ugly though to pass the
> > address of an uninitialized structure.
>
> OK. Maybe we have a plan :-)
>
>
> Let me summarize what we have come up with so far:
>
> - we move the call to xen_register_framebuffer before
> memory_region_init_ram in vga_common_init;
>
> - we prevent xen_ram_alloc from allocating a second framebuffer on
> restore, checking for mr == framebuffer;
>
> - we avoid memsetting the framebuffer on restore (useless anyway, the
> videoram is going to be loaded from the savefile in the general case);
>
> - we introduce a xen_address field to cirrus_vmstate and we use it
> to map the videoram into qemu's address space and update vram_ptr in
> cirrus_post_load.
>
>
> Does it make sense? Do you agree with the approach?

Yes and yes.

-- 
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 Jan 05 17:51:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 17:51:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RirT0-0007zB-Qx; Thu, 05 Jan 2012 17:51:06 +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 1RirSz-0007z0-BB
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:51:05 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325785808!59672991!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5085 invoked from network); 5 Jan 2012 17:50:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	5 Jan 2012 17:50:09 -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 q05HoxdF013889
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 12:51:00 -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 q05Hovid021914; Thu, 5 Jan 2012 12:50:58 -0500
Message-ID: <4F05E301.2020808@redhat.com>
Date: Thu, 05 Jan 2012 19:50:57 +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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
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 01/05/2012 07:21 PM, Stefano Stabellini wrote:
> > > BTW what you are suggesting is not so different from what was done by
> > > Anthony in the last patch series he sent. See the following (ugly) patch
> > > to cirrus-vga.c to avoid accessing s->vga.vram_ptr before restore is
> > > completed and then update the pointer:
> > >
> > > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> > 
> > I see.
> > 
> > Maybe we can put the xen_address in the cirrus vmstate?  That way there
> > is no ordering issue at all.  Of course we have to make sure it isn't
> > saved/restored for non-xen, but that's doable with a predicate attached
> > to the field.
>
> Introducing a xen_address field to the cirrus vmstate is good: it would
> let us avoid playing tricks with the mapcache to understand where to map
> what. It would also avoid nasty ordering issues, like you say.
> However we would still need a xen specific "if" in cirrus_post_load, to
> update vram_ptr correctly, similarly to the first hunk of the patch
> linked above.

While the fear of accelerator-specific hooks in device code is healthy,
at some point we have to let go.  Designing elaborate abstraction layers
around a specific problem with a not-so-good interface just makes the
problem worse.  If we have to have an if there, so be it.

> > 
> > Yup.  We could invert the order.  It's really ugly though to pass the
> > address of an uninitialized structure.
>
> OK. Maybe we have a plan :-)
>
>
> Let me summarize what we have come up with so far:
>
> - we move the call to xen_register_framebuffer before
> memory_region_init_ram in vga_common_init;
>
> - we prevent xen_ram_alloc from allocating a second framebuffer on
> restore, checking for mr == framebuffer;
>
> - we avoid memsetting the framebuffer on restore (useless anyway, the
> videoram is going to be loaded from the savefile in the general case);
>
> - we introduce a xen_address field to cirrus_vmstate and we use it
> to map the videoram into qemu's address space and update vram_ptr in
> cirrus_post_load.
>
>
> Does it make sense? Do you agree with the approach?

Yes and yes.

-- 
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 Jan 05 18:20:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 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 1RirvB-0008SW-Ax; Thu, 05 Jan 2012 18:20:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rirv9-0008SR-QD
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:20:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325787566!49095170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22883 invoked from network); 5 Jan 2012 18:19:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 18:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:20:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 18:20: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
	1RiriR-00021D-NW; Thu, 05 Jan 2012 18:07:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RiriR-0000bW-Md;
	Thu, 05 Jan 2012 18:07:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.59079.535980.830271@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:07:03 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.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@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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] RFC: Still TODO for 4.2?"):
> I don't know much about driver domains, but from what I've read they
> should be running something like NetBSD xenbackend and listen for
> xenstore events. Most of the functions that I've written on my hotplug
> series can be used to create a little daemon, that's not the problem,
> the problem is what can we use to synchronize hotplug script calling
> and libxl (what comes to mind is using a dedicated xenstore variable
> for each device, but someone might have a better idea).

This envisages devicer setup/teardown scripts in driver domains
running in a different way to those in the same domain as the
toolstack.  Are we sure this is a good idea ?

I think it would be preferable to have only one interface to device
scripts, which is used everywhere.  That interface would have to
involve initiation by the toolstack, and collection of resulting
success/failure/etc., via xenstore.

The sequence of events for vifs with a kernel-level backend needs
to go like this:
  * toolstack tells backend domain to create vif, via xenstore
  * backend kernel creates a virtual network interface vifNN
  * something in backend domain notices that this vifNN
    has appeared and consequently
  * device setup script runs, enslaves vifNN to bridge, adds
    it to routing tables, gives it an address, etc.
  * something in backend domain domain tells toolstack vif is ready
  [ device is used ]
  * toolstack tells backend domain to destroy vif; perhaps entire
    xenstore directory is forcibly removed??
  * backend kernel removes virtual network interface immediately
    and all routes, bridge enslavements, etc., are undone
  * something in backend notices the removal
  * device teardown script may need to remove eg firewall rules
  * when this is complete, the backend domain notifies the
    toolstack (how??)

For block devices with a kernel-level backend:
  * toolstack tells backend domain to create vbd
    parameters include: vbd number, target??, script??
  * something in backend domain notices this and consequently
  * device setup script runs, creates a suitable actual
    block device in backend domain
  * backend kernel picks up actual block device details and
    becomes available to guest
  * something in backend domain tells the toolstack all is well
  [ device is used ]
  * toolstack tells backend domain to destroy vbd; perhaps entire
    xenstore directory is forcibly removed??
  * backend kernel removes its actual backend and closes the
    block device, and somehow notifies userspace when this
    is done so that
  * device teardown script cleans up, including making actual
    block device go away (if it was one which the setup script
    created)
  * when this is complete, the backend domain notifies the
    toolstack (how??)

For block devices with a user-level backend:
  * toolstack tells backend domain to create vbd
    parameters include: vbd number, target??, script??
  * userland backend notices this, does its housekeeping
    and setup, and tells the toolstack all is well
  [ device is used ]
  * toolstack tells backend domain to destroy vbd; perhaps entire
    xenstore directory is forcibly removed??
  * userland backend removes its actual backend and closes the
    resources it was using, and
  * notifies the toolstack (how??)

Much of this seems to be covered by, or coverable by, the existing
xenstore protocol.  I think we just need to define in more detail
exactly how it should all work, and on each platform how the
"something"s work.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:20:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 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 1RirvB-0008SW-Ax; Thu, 05 Jan 2012 18:20:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rirv9-0008SR-QD
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:20:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325787566!49095170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22883 invoked from network); 5 Jan 2012 18:19:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 18:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844455"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:20:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 18:20: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
	1RiriR-00021D-NW; Thu, 05 Jan 2012 18:07:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RiriR-0000bW-Md;
	Thu, 05 Jan 2012 18:07:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.59079.535980.830271@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:07:03 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.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@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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] RFC: Still TODO for 4.2?"):
> I don't know much about driver domains, but from what I've read they
> should be running something like NetBSD xenbackend and listen for
> xenstore events. Most of the functions that I've written on my hotplug
> series can be used to create a little daemon, that's not the problem,
> the problem is what can we use to synchronize hotplug script calling
> and libxl (what comes to mind is using a dedicated xenstore variable
> for each device, but someone might have a better idea).

This envisages devicer setup/teardown scripts in driver domains
running in a different way to those in the same domain as the
toolstack.  Are we sure this is a good idea ?

I think it would be preferable to have only one interface to device
scripts, which is used everywhere.  That interface would have to
involve initiation by the toolstack, and collection of resulting
success/failure/etc., via xenstore.

The sequence of events for vifs with a kernel-level backend needs
to go like this:
  * toolstack tells backend domain to create vif, via xenstore
  * backend kernel creates a virtual network interface vifNN
  * something in backend domain notices that this vifNN
    has appeared and consequently
  * device setup script runs, enslaves vifNN to bridge, adds
    it to routing tables, gives it an address, etc.
  * something in backend domain domain tells toolstack vif is ready
  [ device is used ]
  * toolstack tells backend domain to destroy vif; perhaps entire
    xenstore directory is forcibly removed??
  * backend kernel removes virtual network interface immediately
    and all routes, bridge enslavements, etc., are undone
  * something in backend notices the removal
  * device teardown script may need to remove eg firewall rules
  * when this is complete, the backend domain notifies the
    toolstack (how??)

For block devices with a kernel-level backend:
  * toolstack tells backend domain to create vbd
    parameters include: vbd number, target??, script??
  * something in backend domain notices this and consequently
  * device setup script runs, creates a suitable actual
    block device in backend domain
  * backend kernel picks up actual block device details and
    becomes available to guest
  * something in backend domain tells the toolstack all is well
  [ device is used ]
  * toolstack tells backend domain to destroy vbd; perhaps entire
    xenstore directory is forcibly removed??
  * backend kernel removes its actual backend and closes the
    block device, and somehow notifies userspace when this
    is done so that
  * device teardown script cleans up, including making actual
    block device go away (if it was one which the setup script
    created)
  * when this is complete, the backend domain notifies the
    toolstack (how??)

For block devices with a user-level backend:
  * toolstack tells backend domain to create vbd
    parameters include: vbd number, target??, script??
  * userland backend notices this, does its housekeeping
    and setup, and tells the toolstack all is well
  [ device is used ]
  * toolstack tells backend domain to destroy vbd; perhaps entire
    xenstore directory is forcibly removed??
  * userland backend removes its actual backend and closes the
    resources it was using, and
  * notifies the toolstack (how??)

Much of this seems to be covered by, or coverable by, the existing
xenstore protocol.  I think we just need to define in more detail
exactly how it should all work, and on each platform how the
"something"s work.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:23:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiryH-00008m-U7; Thu, 05 Jan 2012 18:23:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RiryG-00008a-HQ
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:23:24 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-182.messagelabs.com!1325787796!9689846!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13127 invoked from network); 5 Jan 2012 18:23:18 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 18:23:18 -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 q05INCC1020897
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 5 Jan 2012 10:23:13 -0800
Date: Thu, 05 Jan 2012 13:23:12 -0500 (EST)
Message-Id: <20120105.132312.2097184941479195775.davem@davemloft.net>
To: shemminger@vyatta.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
References: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
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]);
	Thu, 05 Jan 2012 10:23:14 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen-netback: make ops structs const
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 4 Jan 2012 13:56:58 -0800

> All tables of function pointers should be const to make hacks
> more difficult. Compile tested only.
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Applied.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:23:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:23:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiryH-00008m-U7; Thu, 05 Jan 2012 18:23:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <davem@davemloft.net>) id 1RiryG-00008a-HQ
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:23:24 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-7.tower-182.messagelabs.com!1325787796!9689846!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13127 invoked from network); 5 Jan 2012 18:23:18 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 18:23:18 -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 q05INCC1020897
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 5 Jan 2012 10:23:13 -0800
Date: Thu, 05 Jan 2012 13:23:12 -0500 (EST)
Message-Id: <20120105.132312.2097184941479195775.davem@davemloft.net>
To: shemminger@vyatta.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
References: <20120104135658.0347211f@nehalam.linuxnetplumber.net>
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]);
	Thu, 05 Jan 2012 10:23:14 -0800 (PST)
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen-netback: make ops structs const
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 4 Jan 2012 13:56:58 -0800

> All tables of function pointers should be const to make hacks
> more difficult. Compile tested only.
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Applied.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:27:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18: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 1Ris1w-0000JW-J8; Thu, 05 Jan 2012 18: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 1Ris1u-0000JF-Vw
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:27:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325788022!9864409!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12918 invoked from network); 5 Jan 2012 18:27:02 -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;
	5 Jan 2012 18:27:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:27:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 18:27: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
	1Ris1l-00029Q-El; Thu, 05 Jan 2012 18:27:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ris1l-0000dO-Dr;
	Thu, 05 Jan 2012 18:27:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.60277.415298.787859@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:27:01 +0000
To: hongkaixing@huawei.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in	in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hongkaixing@huawei.com writes ("[Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in in xenpaging"):
> xenpaging:add a new array to speed up page-in in xenpaging
> 
> This patch adds a new array named page_out_index to reserve the
> victim's index.  When page in a page,it has to go through a for loop
> from 0 to num_pages to find the right page to read,and it costs much
> time in this loop.After adding the page_out_index array,it just
> reads the arrry to get the right page,and saves much time.

Thanks for this submission.  Olaf may well have some comments, but I
have some too:

> @@ -660,6 +672,7 @@
>              break;
>          if ( i % 100 == 0 )
>              DPRINTF("%d pages evicted\n", i);
> +        page_out_index[victims[i].gfn].index=i;

Surely this should be better done much closer to the actual point
where we page out ?

And you should reset the index entry when the page is read back in, 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 Thu Jan 05 18:27:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18: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 1Ris1w-0000JW-J8; Thu, 05 Jan 2012 18: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 1Ris1u-0000JF-Vw
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:27:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325788022!9864409!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12918 invoked from network); 5 Jan 2012 18:27:02 -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;
	5 Jan 2012 18:27:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844520"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:27:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 5 Jan 2012 18:27: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
	1Ris1l-00029Q-El; Thu, 05 Jan 2012 18:27:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ris1l-0000dO-Dr;
	Thu, 05 Jan 2012 18:27:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.60277.415298.787859@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:27:01 +0000
To: hongkaixing@huawei.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in	in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hongkaixing@huawei.com writes ("[Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in in xenpaging"):
> xenpaging:add a new array to speed up page-in in xenpaging
> 
> This patch adds a new array named page_out_index to reserve the
> victim's index.  When page in a page,it has to go through a for loop
> from 0 to num_pages to find the right page to read,and it costs much
> time in this loop.After adding the page_out_index array,it just
> reads the arrry to get the right page,and saves much time.

Thanks for this submission.  Olaf may well have some comments, but I
have some too:

> @@ -660,6 +672,7 @@
>              break;
>          if ( i % 100 == 0 )
>              DPRINTF("%d pages evicted\n", i);
> +        page_out_index[victims[i].gfn].index=i;

Surely this should be better done much closer to the actual point
where we page out ?

And you should reset the index entry when the page is read back in, 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 Thu Jan 05 18:29:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18: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 1Ris3J-0000OR-2F; Thu, 05 Jan 2012 18:28:37 +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 1Ris3H-0000Nz-F8
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:28:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325788108!7989944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31247 invoked from network); 5 Jan 2012 18:28:29 -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;
	5 Jan 2012 18:28:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:28: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; Thu, 5 Jan 2012 18:28:28 +0000
Date: Thu, 5 Jan 2012 18:28:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <1325087775.24422.25.camel@liuw-desktop>
Message-ID: <alpine.DEB.2.00.1201051825370.3150@kaball-desktop>
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>
	<1325087775.24422.25.camel@liuw-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.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, 28 Dec 2011, Wei Liu wrote:
> 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.

My guess is that xend used to write a "vifname" node on xenstore in the
network backend path with the name of the vif, and the 2.8.16 netback
would set the vif name based on that.
However you are right saying that modern pvops kernels are unable to do
it.
I think there is no harm in writing the vifname node to xenstore in
libxl, that should solve the problem.

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


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:29:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18: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 1Ris3J-0000OR-2F; Thu, 05 Jan 2012 18:28:37 +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 1Ris3H-0000Nz-F8
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:28:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1325788108!7989944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31247 invoked from network); 5 Jan 2012 18:28:29 -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;
	5 Jan 2012 18:28:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844536"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:28: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; Thu, 5 Jan 2012 18:28:28 +0000
Date: Thu, 5 Jan 2012 18:28:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Wei Liu <wei.liu2@citrix.com>
In-Reply-To: <1325087775.24422.25.camel@liuw-desktop>
Message-ID: <alpine.DEB.2.00.1201051825370.3150@kaball-desktop>
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>
	<1325087775.24422.25.camel@liuw-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.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, 28 Dec 2011, Wei Liu wrote:
> 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.

My guess is that xend used to write a "vifname" node on xenstore in the
network backend path with the name of the vif, and the 2.8.16 netback
would set the vif name based on that.
However you are right saying that modern pvops kernels are unable to do
it.
I think there is no harm in writing the vifname node to xenstore in
libxl, that should solve the problem.

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


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:31:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ris5t-0000Zl-KP; Thu, 05 Jan 2012 18:31:17 +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 1Ris5r-0000ZO-SX
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:31:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325788269!9846858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14273 invoked from network); 5 Jan 2012 18:31:09 -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;
	5 Jan 2012 18:31:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:31: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, 5 Jan 2012 18:31: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
	1Ris5d-0002Al-5V; Thu, 05 Jan 2012 18:31:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ris5d-0000dx-4T;
	Thu, 05 Jan 2012 18:31:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.60517.106414.825193@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:31:01 +0000
To: hongkaixing@huawei.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in	in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hongkaixing@huawei.com writes ("[Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in in xenpaging"):
> xenpaging:add a new array to speed up page-in in xenpaging

Oh, and a couple of style points.  You should keep to the style of the
code you're editing.  So:

> +    if (NULL == victims)

In the xenpaging code this is written like this:

       if (victims == NULL)

You should do the same, throughout.

> +    page_out_index = (victim_to_i_t *)calloc(paging->domain_info->max_pages, sizeof(victim_to_i_t));

Do not cast the return value from malloc et al.

> +                i = page_out_index[req.gfn].index ;

The space before the semicolon is not the conventional style.

> +                    if( victims[i].gfn !=INVALID_MFN )

> -    free(victims);
> +    if ( NULL != victims )
> +    {
> +        free(victims);
> +    }

This is simply pointless.  free(NULL) is legal.

> +typedef struct victim_to_i {
> +    /* the index of victim array to read from */
> +    int index;
> +} victim_to_i_t;

Why wrap this up in a struct ?

Use of types with names ending in _t is reserved to the C
implementation (compiler and runtime).  I know xenpaging is full of
these but we shouldn't introduce any more.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:31:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ris5t-0000Zl-KP; Thu, 05 Jan 2012 18:31:17 +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 1Ris5r-0000ZO-SX
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:31:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325788269!9846858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14273 invoked from network); 5 Jan 2012 18:31:09 -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;
	5 Jan 2012 18:31:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:31: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, 5 Jan 2012 18:31: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
	1Ris5d-0002Al-5V; Thu, 05 Jan 2012 18:31:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Ris5d-0000dx-4T;
	Thu, 05 Jan 2012 18:31:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.60517.106414.825193@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:31:01 +0000
To: hongkaixing@huawei.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in	in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

hongkaixing@huawei.com writes ("[Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in in xenpaging"):
> xenpaging:add a new array to speed up page-in in xenpaging

Oh, and a couple of style points.  You should keep to the style of the
code you're editing.  So:

> +    if (NULL == victims)

In the xenpaging code this is written like this:

       if (victims == NULL)

You should do the same, throughout.

> +    page_out_index = (victim_to_i_t *)calloc(paging->domain_info->max_pages, sizeof(victim_to_i_t));

Do not cast the return value from malloc et al.

> +                i = page_out_index[req.gfn].index ;

The space before the semicolon is not the conventional style.

> +                    if( victims[i].gfn !=INVALID_MFN )

> -    free(victims);
> +    if ( NULL != victims )
> +    {
> +        free(victims);
> +    }

This is simply pointless.  free(NULL) is legal.

> +typedef struct victim_to_i {
> +    /* the index of victim array to read from */
> +    int index;
> +} victim_to_i_t;

Why wrap this up in a struct ?

Use of types with names ending in _t is reserved to the C
implementation (compiler and runtime).  I know xenpaging is full of
these but we shouldn't introduce any more.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:41:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:41:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RisFt-0000tk-Rm; Thu, 05 Jan 2012 18:41:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RisFs-0000tf-Cq
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:41:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325788889!1983193!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21696 invoked from network); 5 Jan 2012 18:41:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Jan 2012 18:41:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325788889; l=1506;
	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=f1V2qU9gucEg7rTK31ENnK8rKow=;
	b=NMVNxmJUKRFjSCt5qoTLwZsOmwW9310cGN1bytH7bsElR/Rl6n2UMrF0c/3AM1/Lsml
	O2iTCHcCzh+hFfQnsSyAezuF2GQKgiCnGLGMhBhZDvR8m+9OqIp+4k+/WeMZScRDre/qt
	SRowyqSHKAN6QPc+vldMRpKN9kyBZKiTiHM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by smtp.strato.de (klopstock mo11) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 005c0bo05IA6zH
	for <xen-devel@lists.xensource.com>;
	Thu, 5 Jan 2012 19:41:23 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2BF7918634
	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 19:41:23 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2f5a98692acde9e74d4009f50f83a8aa08296310
Message-Id: <2f5a98692acde9e74d40.1325788881@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 05 Jan 2012 19:41:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] add feature flag to xenstore for
	XS_RESET_WATCHES
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1325788840 -3600
# Node ID 2f5a98692acde9e74d4009f50f83a8aa08296310
# Parent  3a22ed3ec534799b3cab55b0dc0a7380e701ecbe
add feature flag to xenstore for XS_RESET_WATCHES

Tell guest about availibilty of xenstoreds XS_RESET_WATCHES function.
Guests can not issue this command unconditionally because some buggy
toolstacks (such as EC2) do not ignore unknown commands properly.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3a22ed3ec534 -r 2f5a98692acd tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -434,6 +434,7 @@ retry_transaction:
     libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/control/platform-feature-multiprocessor-suspend", dom_path), "1", 1);
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/control/platform-feature-xs_reset_watches", dom_path), "1", 1);
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN) {
             t = 0;
diff -r 3a22ed3ec534 -r 2f5a98692acd tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -1770,6 +1770,7 @@ class XendDomainInfo:
         f('store/port',       self.store_port)
         f('store/ring-ref',   self.store_mfn)
 
+        f('control/platform-feature-xs_reset_watches', True)
         if arch.type == "x86":
             f('control/platform-feature-multiprocessor-suspend', True)
 

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:41:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:41:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RisFt-0000tk-Rm; Thu, 05 Jan 2012 18:41:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RisFs-0000tf-Cq
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:41:36 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325788889!1983193!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21696 invoked from network); 5 Jan 2012 18:41:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Jan 2012 18:41:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325788889; l=1506;
	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=f1V2qU9gucEg7rTK31ENnK8rKow=;
	b=NMVNxmJUKRFjSCt5qoTLwZsOmwW9310cGN1bytH7bsElR/Rl6n2UMrF0c/3AM1/Lsml
	O2iTCHcCzh+hFfQnsSyAezuF2GQKgiCnGLGMhBhZDvR8m+9OqIp+4k+/WeMZScRDre/qt
	SRowyqSHKAN6QPc+vldMRpKN9kyBZKiTiHM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by smtp.strato.de (klopstock mo11) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 005c0bo05IA6zH
	for <xen-devel@lists.xensource.com>;
	Thu, 5 Jan 2012 19:41:23 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2BF7918634
	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 19:41:23 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2f5a98692acde9e74d4009f50f83a8aa08296310
Message-Id: <2f5a98692acde9e74d40.1325788881@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 05 Jan 2012 19:41:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] add feature flag to xenstore for
	XS_RESET_WATCHES
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1325788840 -3600
# Node ID 2f5a98692acde9e74d4009f50f83a8aa08296310
# Parent  3a22ed3ec534799b3cab55b0dc0a7380e701ecbe
add feature flag to xenstore for XS_RESET_WATCHES

Tell guest about availibilty of xenstoreds XS_RESET_WATCHES function.
Guests can not issue this command unconditionally because some buggy
toolstacks (such as EC2) do not ignore unknown commands properly.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3a22ed3ec534 -r 2f5a98692acd tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -434,6 +434,7 @@ retry_transaction:
     libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
 
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/control/platform-feature-multiprocessor-suspend", dom_path), "1", 1);
+    xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/control/platform-feature-xs_reset_watches", dom_path), "1", 1);
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN) {
             t = 0;
diff -r 3a22ed3ec534 -r 2f5a98692acd tools/python/xen/xend/XendDomainInfo.py
--- a/tools/python/xen/xend/XendDomainInfo.py
+++ b/tools/python/xen/xend/XendDomainInfo.py
@@ -1770,6 +1770,7 @@ class XendDomainInfo:
         f('store/port',       self.store_port)
         f('store/ring-ref',   self.store_mfn)
 
+        f('control/platform-feature-xs_reset_watches', True)
         if arch.type == "x86":
             f('control/platform-feature-multiprocessor-suspend', True)
 

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:44:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RisId-00011c-Jh; Thu, 05 Jan 2012 18:44:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RisIc-00011Q-2n
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:44:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1325789059!10426866!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDY0OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDY0OTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20455 invoked from network); 5 Jan 2012 18:44:19 -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; 5 Jan 2012 18:44:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325789059; l=797;
	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=DXS6n1PJH0HWUqotnSuBw1xydtM=;
	b=oX9zDDn0zO51pJs9e8Mho+HR8rFD07JZcIfEUISsKC1lj+IktWcJVLy0MOfJQS7P45K
	r0jW+rAlNAeA2X58RM8xl8b7NM+E/7/y6Rz+/YEiYdAFm88pzZjSey+AScNYS6YPs5hz1
	d1EPJ2ryu8t89uR0aqNfucIijKtPBA6dj7g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by smtp.strato.de (fruni mo57) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w05744o05IaQzf ;
	Thu, 5 Jan 2012 19:43:54 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7282318637; Thu,  5 Jan 2012 19:43:53 +0100 (CET)
Date: Thu, 5 Jan 2012 19:43:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120105184353.GA13213@aepfle.de>
References: <20111220131533.GA7800@aepfle.de>
	<20111220141612.GA25139@konrad-lan>
	<20208.50657.799146.57017@mariner.uk.xensource.com>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
	<20120104155734.GA9271@aepfle.de>
	<1325694125.25206.299.camel@zakaz.uk.xensource.com>
	<20120104162708.GA26431@aepfle.de>
	<1325755560.25206.345.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325755560.25206.345.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>,
	Ian Jackson <Ian.Jackson@eu.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 Thu, Jan 05, Ian Campbell wrote:

> On Wed, 2012-01-04 at 16:27 +0000, Olaf Hering wrote:
> > On Wed, Jan 04, Ian Campbell wrote:
> > 
> > > I think the toolstack needs to be involved with this. IOW this should be
> > > done in libxl__domain_make() around the same place as
> > > control/platform-feature-multiprocessor-suspend is written.
> > 
> > Isnt XS_RESET_WATCHES a feature of xenstored, so it should add its own stuff itself?
> 
> Ultimately I think it needs to be the toolstack so that it can control
> if this gets written or not based on configuration should that become
> necessary.

I have sent a patch to add control/platform-feature-xs_reset_watches
from libxl/xend. With this patch a guest can now decide wether it can
issue the XS_RESET_WATCHES command.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:44:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:44:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RisId-00011c-Jh; Thu, 05 Jan 2012 18:44:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RisIc-00011Q-2n
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:44:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-21.messagelabs.com!1325789059!10426866!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDY0OTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDY0OTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20455 invoked from network); 5 Jan 2012 18:44:19 -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; 5 Jan 2012 18:44:19 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325789059; l=797;
	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=DXS6n1PJH0HWUqotnSuBw1xydtM=;
	b=oX9zDDn0zO51pJs9e8Mho+HR8rFD07JZcIfEUISsKC1lj+IktWcJVLy0MOfJQS7P45K
	r0jW+rAlNAeA2X58RM8xl8b7NM+E/7/y6Rz+/YEiYdAFm88pzZjSey+AScNYS6YPs5hz1
	d1EPJ2ryu8t89uR0aqNfucIijKtPBA6dj7g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by smtp.strato.de (fruni mo57) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w05744o05IaQzf ;
	Thu, 5 Jan 2012 19:43:54 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7282318637; Thu,  5 Jan 2012 19:43:53 +0100 (CET)
Date: Thu, 5 Jan 2012 19:43:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120105184353.GA13213@aepfle.de>
References: <20111220131533.GA7800@aepfle.de>
	<20111220141612.GA25139@konrad-lan>
	<20208.50657.799146.57017@mariner.uk.xensource.com>
	<1324412394.8252.163.camel@dagon.hellion.org.uk>
	<20120102171631.GA13603@aepfle.de>
	<1325588512.25206.60.camel@zakaz.uk.xensource.com>
	<20120104155734.GA9271@aepfle.de>
	<1325694125.25206.299.camel@zakaz.uk.xensource.com>
	<20120104162708.GA26431@aepfle.de>
	<1325755560.25206.345.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325755560.25206.345.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>,
	Ian Jackson <Ian.Jackson@eu.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 Thu, Jan 05, Ian Campbell wrote:

> On Wed, 2012-01-04 at 16:27 +0000, Olaf Hering wrote:
> > On Wed, Jan 04, Ian Campbell wrote:
> > 
> > > I think the toolstack needs to be involved with this. IOW this should be
> > > done in libxl__domain_make() around the same place as
> > > control/platform-feature-multiprocessor-suspend is written.
> > 
> > Isnt XS_RESET_WATCHES a feature of xenstored, so it should add its own stuff itself?
> 
> Ultimately I think it needs to be the toolstack so that it can control
> if this gets written or not based on configuration should that become
> necessary.

I have sent a patch to add control/platform-feature-xs_reset_watches
from libxl/xend. With this patch a guest can now decide wether it can
issue the XS_RESET_WATCHES command.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:48:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:48:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RisLn-0001Bi-Ax; Thu, 05 Jan 2012 18:47: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 1RisLl-0001BJ-FU
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:47:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325789255!8534610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31610 invoked from network); 5 Jan 2012 18:47:35 -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;
	5 Jan 2012 18:47:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:47: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; Thu, 5 Jan 2012 18:47:34 +0000
Date: Thu, 5 Jan 2012 18:47:23 +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.1201051825370.3150@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201051846560.3150@kaball-desktop>
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>
	<1325087775.24422.25.camel@liuw-desktop>
	<alpine.DEB.2.00.1201051825370.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <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 Thu, 5 Jan 2012, Stefano Stabellini wrote:
> My guess is that xend used to write a "vifname" node on xenstore in the
> network backend path with the name of the vif, and the 2.8.16 netback
> would set the vif name based on that.
> However you are right saying that modern pvops kernels are unable to do
> it.
> I think there is no harm in writing the vifname node to xenstore in
> libxl, that should solve the problem.

Oops, I have just seen that you have fixed this already!

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:48:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:48:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RisLn-0001Bi-Ax; Thu, 05 Jan 2012 18:47: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 1RisLl-0001BJ-FU
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:47:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325789255!8534610!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31610 invoked from network); 5 Jan 2012 18:47:35 -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;
	5 Jan 2012 18:47:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:47: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; Thu, 5 Jan 2012 18:47:34 +0000
Date: Thu, 5 Jan 2012 18:47:23 +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.1201051825370.3150@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201051846560.3150@kaball-desktop>
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>
	<1325087775.24422.25.camel@liuw-desktop>
	<alpine.DEB.2.00.1201051825370.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andy Smith <andy@strugglers.net>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <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 Thu, 5 Jan 2012, Stefano Stabellini wrote:
> My guess is that xend used to write a "vifname" node on xenstore in the
> network backend path with the name of the vif, and the 2.8.16 netback
> would set the vif name based on that.
> However you are right saying that modern pvops kernels are unable to do
> it.
> I think there is no harm in writing the vifname node to xenstore in
> libxl, that should solve the problem.

Oops, I have just seen that you have fixed this already!

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:48:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RisMk-0001GV-QA; Thu, 05 Jan 2012 18:48: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 1RisMj-0001G5-KE
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:48:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325789309!9298075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21929 invoked from network); 5 Jan 2012 18:48:35 -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;
	5 Jan 2012 18:48:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:48: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; Thu, 5 Jan 2012 18:48: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
	1RisMX-0002Ib-5K; Thu, 05 Jan 2012 18:48:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RisMX-0000gh-4R;
	Thu, 05 Jan 2012 18:48:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.61565.124935.656551@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:48:29 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201051448320.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201051448320.3150@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl.pod.1: introduction to FLASK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] xl.pod.1: introduction to FLASK"):
> Based on a text written by Daniel De Graaf.

We therefore need a signoff from Daniel too.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

And that is therefore a lie.

Can I remind everyone that writing "Signed-off-by" is not a mere
formality, where you just rubber-stamp your own name.  If you wrote
the whole thing and you (your company) wants to submit it, fine.

But if any of it was written by anyone else then you need their
signoff too.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:48:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18:48:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RisMk-0001GV-QA; Thu, 05 Jan 2012 18:48: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 1RisMj-0001G5-KE
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:48:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325789309!9298075!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTcyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21929 invoked from network); 5 Jan 2012 18:48:35 -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;
	5 Jan 2012 18:48:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; 
   d="scan'208";a="9844726"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 18:48: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; Thu, 5 Jan 2012 18:48: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
	1RisMX-0002Ib-5K; Thu, 05 Jan 2012 18:48:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RisMX-0000gh-4R;
	Thu, 05 Jan 2012 18:48:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20229.61565.124935.656551@mariner.uk.xensource.com>
Date: Thu, 5 Jan 2012 18:48:29 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201051448320.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201051448320.3150@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xl.pod.1: introduction to FLASK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] xl.pod.1: introduction to FLASK"):
> Based on a text written by Daniel De Graaf.

We therefore need a signoff from Daniel too.

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

And that is therefore a lie.

Can I remind everyone that writing "Signed-off-by" is not a mere
formality, where you just rubber-stamp your own name.  If you wrote
the whole thing and you (your company) wants to submit it, fine.

But if any of it was written by anyone else then you need their
signoff too.

Ian.

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:49:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18: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 1RisNQ-0001L2-7W; Thu, 05 Jan 2012 18:49:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RisNP-0001KC-4t
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:49:23 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325789356!7953718!1
X-Originating-IP: [217.72.192.234]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14649 invoked from network); 5 Jan 2012 18:49:16 -0000
Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234)
	by server-2.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 18:49:16 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate03.web.de (Postfix) with ESMTP id 587FC1AF40828
	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 19:49:16 +0100 (CET)
Received: from netbook.home ([187.105.25.94]) by smtp.web.de (mrweb001) with
	ESMTPA (Nemesis) id 0LtoGb-1SgrTZ2mg9-011DrF;
	Thu, 05 Jan 2012 19:49:15 +0100
Message-ID: <4F05F09E.8030800@web.de>
Date: Thu, 05 Jan 2012 16:49:02 -0200
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: Avi Kivity <avi@redhat.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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com>
In-Reply-To: <4F05E301.2020808@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:HPFe7Z6H8yNHTPcwmvig/+X3O0rD0xhvJJ9Q9bt8Pvi
	n8dU5+fYOswSCD9WfWXtPSMYk7c4pJ4gZT8P+tsFpOJmLiDTF9
	Qed9tUoKm8n28PEX1+8hVydz1sNKKMisY551BVOrANOJxy3sGq
	8eNeG3pruU68ekasbgYAlHyrsk2c6t4RdguNUjH18O2HEhI2MN
	+7UCy9JWsOwpSZGirhR8Q==
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: multipart/mixed; boundary="===============8998378152586059994=="
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)
--===============8998378152586059994==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigBFEEEA9BB7F5AAC4180D2E0B"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBFEEEA9BB7F5AAC4180D2E0B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2012-01-05 15:50, Avi Kivity wrote:
>> Let me summarize what we have come up with so far:
>>
>> - we move the call to xen_register_framebuffer before
>> memory_region_init_ram in vga_common_init;
>>
>> - we prevent xen_ram_alloc from allocating a second framebuffer on
>> restore, checking for mr =3D=3D framebuffer;
>>
>> - we avoid memsetting the framebuffer on restore (useless anyway, the
>> videoram is going to be loaded from the savefile in the general case);=

>>
>> - we introduce a xen_address field to cirrus_vmstate and we use it
>> to map the videoram into qemu's address space and update vram_ptr in
>> cirrus_post_load.
>>
>>
>> Does it make sense? Do you agree with the approach?
>=20
> Yes and yes.

To me this still sounds like a cirrus-only xen workaround that
nevertheless spreads widely.

Again, what speaks against migrating the information Xen needs before
creating the machine or a single device? That would only introduce a
generic concept of an (optional) "early", let's call it
"accelerator-related" vmstate and would allow Xen to deal with all the
specifics behind the curtain.

Jan


--------------enigBFEEEA9BB7F5AAC4180D2E0B
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.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8F8J8ACgkQitSsb3rl5xRekACdG5G/4+F5S9YF2J5imlmju8kV
ZIEAoLhwol0x6yH/o1PsPBPkuDHu2CGf
=U7wT
-----END PGP SIGNATURE-----

--------------enigBFEEEA9BB7F5AAC4180D2E0B--


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

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

--===============8998378152586059994==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 18:49:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 18: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 1RisNQ-0001L2-7W; Thu, 05 Jan 2012 18:49:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RisNP-0001KC-4t
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:49:23 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325789356!7953718!1
X-Originating-IP: [217.72.192.234]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14649 invoked from network); 5 Jan 2012 18:49:16 -0000
Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234)
	by server-2.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 18:49:16 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate03.web.de (Postfix) with ESMTP id 587FC1AF40828
	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 19:49:16 +0100 (CET)
Received: from netbook.home ([187.105.25.94]) by smtp.web.de (mrweb001) with
	ESMTPA (Nemesis) id 0LtoGb-1SgrTZ2mg9-011DrF;
	Thu, 05 Jan 2012 19:49:15 +0100
Message-ID: <4F05F09E.8030800@web.de>
Date: Thu, 05 Jan 2012 16:49:02 -0200
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: Avi Kivity <avi@redhat.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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com>
In-Reply-To: <4F05E301.2020808@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:HPFe7Z6H8yNHTPcwmvig/+X3O0rD0xhvJJ9Q9bt8Pvi
	n8dU5+fYOswSCD9WfWXtPSMYk7c4pJ4gZT8P+tsFpOJmLiDTF9
	Qed9tUoKm8n28PEX1+8hVydz1sNKKMisY551BVOrANOJxy3sGq
	8eNeG3pruU68ekasbgYAlHyrsk2c6t4RdguNUjH18O2HEhI2MN
	+7UCy9JWsOwpSZGirhR8Q==
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: multipart/mixed; boundary="===============8998378152586059994=="
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)
--===============8998378152586059994==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigBFEEEA9BB7F5AAC4180D2E0B"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigBFEEEA9BB7F5AAC4180D2E0B
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2012-01-05 15:50, Avi Kivity wrote:
>> Let me summarize what we have come up with so far:
>>
>> - we move the call to xen_register_framebuffer before
>> memory_region_init_ram in vga_common_init;
>>
>> - we prevent xen_ram_alloc from allocating a second framebuffer on
>> restore, checking for mr =3D=3D framebuffer;
>>
>> - we avoid memsetting the framebuffer on restore (useless anyway, the
>> videoram is going to be loaded from the savefile in the general case);=

>>
>> - we introduce a xen_address field to cirrus_vmstate and we use it
>> to map the videoram into qemu's address space and update vram_ptr in
>> cirrus_post_load.
>>
>>
>> Does it make sense? Do you agree with the approach?
>=20
> Yes and yes.

To me this still sounds like a cirrus-only xen workaround that
nevertheless spreads widely.

Again, what speaks against migrating the information Xen needs before
creating the machine or a single device? That would only introduce a
generic concept of an (optional) "early", let's call it
"accelerator-related" vmstate and would allow Xen to deal with all the
specifics behind the curtain.

Jan


--------------enigBFEEEA9BB7F5AAC4180D2E0B
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.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8F8J8ACgkQitSsb3rl5xRekACdG5G/4+F5S9YF2J5imlmju8kV
ZIEAoLhwol0x6yH/o1PsPBPkuDHu2CGf
=U7wT
-----END PGP SIGNATURE-----

--------------enigBFEEEA9BB7F5AAC4180D2E0B--


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

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

--===============8998378152586059994==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 19:03:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 19:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Risb8-0001o4-Qd; Thu, 05 Jan 2012 19:03: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 1Risb7-0001nz-0A
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 19:03:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325790204!7808796!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2996 invoked from network); 5 Jan 2012 19:03:26 -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;
	5 Jan 2012 19:03:26 -0000
Received: by ggnh4 with SMTP id h4so3696668ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 11:03: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=H/BeQg6C3StfL3N8nT2to/d98ko0OAfRUleNAm8Tyss=;
	b=b38p7A8LlrM4hsnScQmt1Q9T+gaQUnuPEKlS+EtkfU5OX/VL0pJzw13eLdl691ju2J
	DGSx52WixdWDDRqoxwroTIfFzQYzk5dbySkRlrfg7mxR5unaTlaytLd+avUzaY98NFBn
	Mizor2dT1aGFVSYnBjQkKlvMr8vxwFAMx/iC4=
Received: by 10.100.86.8 with SMTP id j8mr1499021anb.66.1325790204494;
	Thu, 05 Jan 2012 11:03:24 -0800 (PST)
Received: from [192.168.1.152] ([198.162.52.244])
	by mx.google.com with ESMTPS id b6sm15348275ani.16.2012.01.05.11.03.20
	(version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 11:03:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 05 Jan 2012 19:03:09 +0000
From: Keir Fraser <keir@xen.org>
To: Tim Deegan <tim@xen.org>
Message-ID: <CB2BA46D.36EF5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: emulate lea with two register operands
	correctly
Thread-Index: AczL3KndLXDU6P7SUE+ABNSrlChYtA==
In-Reply-To: <20120105160641.GB87519@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86: emulate lea with two register operands
 correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 16:06, "Tim Deegan" <tim@xen.org> wrote:

> At 15:49 +0000 on 05 Jan (1325778595), Keir Fraser wrote:
>> On 05/01/2012 15:03, "David Vrabel" <david.vrabel@citrix.com> wrote:
>> 
>>> An lea instruction with two register operands should raise an
>>> undefined instruction exception.
>>> 
>>> Skype does such a instruction and will crash when starting if it does
>>> not get the exception.
>> 
>> Thanks. I think it is a little nicer to check ea.type != OP_MEM, so I made
>> that change before committing this patch. It's now in xen-unstable staging.
>> 
>> It's a bit concerning that we're emulating LEA at all, perhaps. I wonder if
>> a pagetable page has been reused as a code page and we didn't notice yet? Or
>> is there some other reason that skype is getting emulated? :-)
> 
> #UD exceptions in HVM are passed to the emulator (IIRC as part of the
> cross-vendor migration patches, so SYSENTER & friends could be managed).

Duh, good point.

 -- Keir

> Tim.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 19:03:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 19:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Risb8-0001o4-Qd; Thu, 05 Jan 2012 19:03: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 1Risb7-0001nz-0A
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 19:03:33 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325790204!7808796!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2996 invoked from network); 5 Jan 2012 19:03:26 -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;
	5 Jan 2012 19:03:26 -0000
Received: by ggnh4 with SMTP id h4so3696668ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 11:03: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=H/BeQg6C3StfL3N8nT2to/d98ko0OAfRUleNAm8Tyss=;
	b=b38p7A8LlrM4hsnScQmt1Q9T+gaQUnuPEKlS+EtkfU5OX/VL0pJzw13eLdl691ju2J
	DGSx52WixdWDDRqoxwroTIfFzQYzk5dbySkRlrfg7mxR5unaTlaytLd+avUzaY98NFBn
	Mizor2dT1aGFVSYnBjQkKlvMr8vxwFAMx/iC4=
Received: by 10.100.86.8 with SMTP id j8mr1499021anb.66.1325790204494;
	Thu, 05 Jan 2012 11:03:24 -0800 (PST)
Received: from [192.168.1.152] ([198.162.52.244])
	by mx.google.com with ESMTPS id b6sm15348275ani.16.2012.01.05.11.03.20
	(version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 11:03:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 05 Jan 2012 19:03:09 +0000
From: Keir Fraser <keir@xen.org>
To: Tim Deegan <tim@xen.org>
Message-ID: <CB2BA46D.36EF5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] x86: emulate lea with two register operands
	correctly
Thread-Index: AczL3KndLXDU6P7SUE+ABNSrlChYtA==
In-Reply-To: <20120105160641.GB87519@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86: emulate lea with two register operands
 correctly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 16:06, "Tim Deegan" <tim@xen.org> wrote:

> At 15:49 +0000 on 05 Jan (1325778595), Keir Fraser wrote:
>> On 05/01/2012 15:03, "David Vrabel" <david.vrabel@citrix.com> wrote:
>> 
>>> An lea instruction with two register operands should raise an
>>> undefined instruction exception.
>>> 
>>> Skype does such a instruction and will crash when starting if it does
>>> not get the exception.
>> 
>> Thanks. I think it is a little nicer to check ea.type != OP_MEM, so I made
>> that change before committing this patch. It's now in xen-unstable staging.
>> 
>> It's a bit concerning that we're emulating LEA at all, perhaps. I wonder if
>> a pagetable page has been reused as a code page and we didn't notice yet? Or
>> is there some other reason that skype is getting emulated? :-)
> 
> #UD exceptions in HVM are passed to the emulator (IIRC as part of the
> cross-vendor migration patches, so SYSENTER & friends could be managed).

Duh, good point.

 -- Keir

> Tim.



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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 19:32:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 19:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rit3B-00023q-BX; Thu, 05 Jan 2012 19:32:33 +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 1Rit3A-00023d-Ia
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 19:32:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1325791945!7974990!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 6430 invoked from network); 5 Jan 2012 19:32:26 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 19:32: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
	q05JWMWK013759; Thu, 5 Jan 2012 19:32:23 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 q05JWMdF015377; 
	Thu, 5 Jan 2012 14:32:22 -0500
Message-ID: <4F05FACD.6050000@tycho.nsa.gov>
Date: Thu, 05 Jan 2012 14:32:29 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <alpine.DEB.2.00.1201051448320.3150@kaball-desktop>
	<20229.61565.124935.656551@mariner.uk.xensource.com>
In-Reply-To: <20229.61565.124935.656551@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xl.pod.1: introduction to FLASK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/05/2012 01:48 PM, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH] xl.pod.1: introduction to FLASK"):
>> Based on a text written by Daniel De Graaf.
> 
> We therefore need a signoff from Daniel too.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> And that is therefore a lie.
> 
> Can I remind everyone that writing "Signed-off-by" is not a mere
> formality, where you just rubber-stamp your own name.  If you wrote
> the whole thing and you (your company) wants to submit it, fine.
> 
> But if any of it was written by anyone else then you need their
> signoff too.
> 
> Ian.
> 

-- 
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 Jan 05 19:32:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 19:32:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rit3B-00023q-BX; Thu, 05 Jan 2012 19:32:33 +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 1Rit3A-00023d-Ia
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 19:32:32 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1325791945!7974990!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 6430 invoked from network); 5 Jan 2012 19:32:26 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-174.messagelabs.com with SMTP;
	5 Jan 2012 19:32: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
	q05JWMWK013759; Thu, 5 Jan 2012 19:32:23 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 q05JWMdF015377; 
	Thu, 5 Jan 2012 14:32:22 -0500
Message-ID: <4F05FACD.6050000@tycho.nsa.gov>
Date: Thu, 05 Jan 2012 14:32:29 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <alpine.DEB.2.00.1201051448320.3150@kaball-desktop>
	<20229.61565.124935.656551@mariner.uk.xensource.com>
In-Reply-To: <20229.61565.124935.656551@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xl.pod.1: introduction to FLASK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/05/2012 01:48 PM, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH] xl.pod.1: introduction to FLASK"):
>> Based on a text written by Daniel De Graaf.
> 
> We therefore need a signoff from Daniel too.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> And that is therefore a lie.
> 
> Can I remind everyone that writing "Signed-off-by" is not a mere
> formality, where you just rubber-stamp your own name.  If you wrote
> the whole thing and you (your company) wants to submit it, fine.
> 
> But if any of it was written by anyone else then you need their
> signoff too.
> 
> Ian.
> 

-- 
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 Jan 05 20:28:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 20: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 1RituM-0002W1-OA; Thu, 05 Jan 2012 20:27:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RituL-0002Vw-3U
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 20:27:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325795242!4450740!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2099 invoked from network); 5 Jan 2012 20:27:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Jan 2012 20:27:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325795242; l=1044;
	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=41OnWt/eg/u4sVvj7HG1UbniDO4=;
	b=YKsI5rH0SghnlGR5EcjHIGWq1jTXG4D0UhA4DCt4cwfBRNrciaz3uykahObEjBW59hU
	s+LHNEYv7ZgNWQpim2UqDwcEWHRsXtLwBLP20Qozf+TlYDqACQISHglCxb9QyqPmA6j+W
	8EgWV8OWRASDWrQyQy4X2Sk5bAujxJz/vsw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by post.strato.de (mrclete mo60) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x025ado05K0WA8
	for <xen-devel@lists.xensource.com>;
	Thu, 5 Jan 2012 21:27:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 65A5B18634
	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 21:27:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 8d1991a7f8a37ec1fc9a660cb48cb40ef42e9ff3
Message-Id: <8d1991a7f8a37ec1fc9a.1325795227@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 05 Jan 2012 21:27:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] linux-2.6.18: check availibility of
	XS_RESET_WATCHES command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1325795190 -3600
# Node ID 8d1991a7f8a37ec1fc9a660cb48cb40ef42e9ff3
# Parent  821a5b2a10c86f18fbce0907af0db6905b9d540a
linux-2.6.18: check availibility of XS_RESET_WATCHES command

Check platform-feature-xs_reset_watches before sending XS_RESET_WATCHES
command. Buggy xenstored implementations such as EC2 do not ignore unknown
commands properly and cause a guest hang.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 821a5b2a10c8 -r 8d1991a7f8a3 drivers/xen/xenbus/xenbus_xs.c
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -630,7 +630,12 @@ static struct xenbus_watch *find_watch(c
 static void xs_reset_watches(void)
 {
 #ifndef CONFIG_XEN
-	int err;
+	int err, supported = 0;
+
+	err = xenbus_scanf(XBT_NIL, "control",
+			"platform-feature-xs_reset_watches", "%d", &supported);
+	if (err != 1 || !supported)
+		return;
 
 	err = xs_error(xs_single(XBT_NIL, XS_RESET_WATCHES, "", NULL));
 	if (err && err != -EEXIST)

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 20:28:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 20: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 1RituM-0002W1-OA; Thu, 05 Jan 2012 20:27:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RituL-0002Vw-3U
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 20:27:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325795242!4450740!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2099 invoked from network); 5 Jan 2012 20:27:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Jan 2012 20:27:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325795242; l=1044;
	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=41OnWt/eg/u4sVvj7HG1UbniDO4=;
	b=YKsI5rH0SghnlGR5EcjHIGWq1jTXG4D0UhA4DCt4cwfBRNrciaz3uykahObEjBW59hU
	s+LHNEYv7ZgNWQpim2UqDwcEWHRsXtLwBLP20Qozf+TlYDqACQISHglCxb9QyqPmA6j+W
	8EgWV8OWRASDWrQyQy4X2Sk5bAujxJz/vsw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by post.strato.de (mrclete mo60) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x025ado05K0WA8
	for <xen-devel@lists.xensource.com>;
	Thu, 5 Jan 2012 21:27:08 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 65A5B18634
	for <xen-devel@lists.xensource.com>;
	Thu,  5 Jan 2012 21:27:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 8d1991a7f8a37ec1fc9a660cb48cb40ef42e9ff3
Message-Id: <8d1991a7f8a37ec1fc9a.1325795227@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 05 Jan 2012 21:27:07 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] linux-2.6.18: check availibility of
	XS_RESET_WATCHES command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1325795190 -3600
# Node ID 8d1991a7f8a37ec1fc9a660cb48cb40ef42e9ff3
# Parent  821a5b2a10c86f18fbce0907af0db6905b9d540a
linux-2.6.18: check availibility of XS_RESET_WATCHES command

Check platform-feature-xs_reset_watches before sending XS_RESET_WATCHES
command. Buggy xenstored implementations such as EC2 do not ignore unknown
commands properly and cause a guest hang.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 821a5b2a10c8 -r 8d1991a7f8a3 drivers/xen/xenbus/xenbus_xs.c
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -630,7 +630,12 @@ static struct xenbus_watch *find_watch(c
 static void xs_reset_watches(void)
 {
 #ifndef CONFIG_XEN
-	int err;
+	int err, supported = 0;
+
+	err = xenbus_scanf(XBT_NIL, "control",
+			"platform-feature-xs_reset_watches", "%d", &supported);
+	if (err != 1 || !supported)
+		return;
 
 	err = xs_error(xs_single(XBT_NIL, XS_RESET_WATCHES, "", NULL));
 	if (err && err != -EEXIST)

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 20:42:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 20: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 1Riu87-0002ly-5a; Thu, 05 Jan 2012 20:41:43 +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 1Riu85-0002lt-1h
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 20:41:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325796093!7999709!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6517 invoked from network); 5 Jan 2012 20:41:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 20:41:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325796093; l=2700;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=uoL59CHit6lk1QExmmhX90sEqZY=;
	b=s4nWyfwgKNqdS3FOhigGPDcUfF2TYf7iUK8t6WKjfz1I6XnytO6gTlfkfsLytaKtggy
	SKHmgPcmOKQ6sBkBJyRGOggkmMiCiMsFkF0BYzPojECLp2jUwj6CKpxCLyLh+nmDDrsBD
	aqyHAtdjFAleS5JOw/7gMeuIZ2gV3KpBlpo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by smtp.strato.de (jimi mo40) (RZmta 27.2 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L04880o05J3LPD
	for <xen-devel@lists.xensource.com>;
	Thu, 5 Jan 2012 21:41:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 17A8B18637; Thu,  5 Jan 2012 21:41:26 +0100 (CET)
Date: Thu, 5 Jan 2012 21:41:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120105204126.GA29219@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] [PATCH] 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

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

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---

Note: the patch will be available via git://... once it was reviewed

 drivers/xen/xenbus/xenbus_xs.c     |   21 +++++++++++++++++++++
 include/xen/interface/io/xs_wire.h |    3 ++-
 2 files changed, 23 insertions(+), 1 deletion(-)

Index: linux-3.2/drivers/xen/xenbus/xenbus_xs.c
===================================================================
--- linux-3.2.orig/drivers/xen/xenbus/xenbus_xs.c
+++ linux-3.2/drivers/xen/xenbus/xenbus_xs.c
@@ -621,6 +621,23 @@ static struct xenbus_watch *find_watch(c
 	return NULL;
 }
 
+static void xs_reset_watches(void)
+{
+	int err, supported = 0;
+
+	if (!xen_hvm_domain())
+		return;
+
+	err = xenbus_scanf(XBT_NIL, "control",
+			"platform-feature-xs_reset_watches", "%d", &supported);
+	if (err != 1 || !supported)
+		return;
+
+	err = xs_error(xs_single(XBT_NIL, XS_RESET_WATCHES, "", NULL));
+	if (err && err != -EEXIST)
+		printk(KERN_WARNING "xs_reset_watches failed: %d\n", err);
+}
+
 /* Register callback to watch this node. */
 int register_xenbus_watch(struct xenbus_watch *watch)
 {
@@ -897,5 +915,8 @@ int xs_init(void)
 	if (IS_ERR(task))
 		return PTR_ERR(task);
 
+	/* shutdown watches for kexec boot */
+	xs_reset_watches();
+
 	return 0;
 }
Index: linux-3.2/include/xen/interface/io/xs_wire.h
===================================================================
--- linux-3.2.orig/include/xen/interface/io/xs_wire.h
+++ linux-3.2/include/xen/interface/io/xs_wire.h
@@ -29,7 +29,8 @@ enum xsd_sockmsg_type
     XS_IS_DOMAIN_INTRODUCED,
     XS_RESUME,
     XS_SET_TARGET,
-    XS_RESTRICT
+    XS_RESTRICT,
+    XS_RESET_WATCHES
 };
 
 #define XS_WRITE_NONE "NONE"

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 20:42:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 20: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 1Riu87-0002ly-5a; Thu, 05 Jan 2012 20:41:43 +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 1Riu85-0002lt-1h
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 20:41:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325796093!7999709!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzE1Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6517 invoked from network); 5 Jan 2012 20:41:34 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 5 Jan 2012 20:41:34 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325796093; l=2700;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=uoL59CHit6lk1QExmmhX90sEqZY=;
	b=s4nWyfwgKNqdS3FOhigGPDcUfF2TYf7iUK8t6WKjfz1I6XnytO6gTlfkfsLytaKtggy
	SKHmgPcmOKQ6sBkBJyRGOggkmMiCiMsFkF0BYzPojECLp2jUwj6CKpxCLyLh+nmDDrsBD
	aqyHAtdjFAleS5JOw/7gMeuIZ2gV3KpBlpo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by smtp.strato.de (jimi mo40) (RZmta 27.2 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L04880o05J3LPD
	for <xen-devel@lists.xensource.com>;
	Thu, 5 Jan 2012 21:41:32 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 17A8B18637; Thu,  5 Jan 2012 21:41:26 +0100 (CET)
Date: Thu, 5 Jan 2012 21:41:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120105204126.GA29219@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] [PATCH] 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

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

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---

Note: the patch will be available via git://... once it was reviewed

 drivers/xen/xenbus/xenbus_xs.c     |   21 +++++++++++++++++++++
 include/xen/interface/io/xs_wire.h |    3 ++-
 2 files changed, 23 insertions(+), 1 deletion(-)

Index: linux-3.2/drivers/xen/xenbus/xenbus_xs.c
===================================================================
--- linux-3.2.orig/drivers/xen/xenbus/xenbus_xs.c
+++ linux-3.2/drivers/xen/xenbus/xenbus_xs.c
@@ -621,6 +621,23 @@ static struct xenbus_watch *find_watch(c
 	return NULL;
 }
 
+static void xs_reset_watches(void)
+{
+	int err, supported = 0;
+
+	if (!xen_hvm_domain())
+		return;
+
+	err = xenbus_scanf(XBT_NIL, "control",
+			"platform-feature-xs_reset_watches", "%d", &supported);
+	if (err != 1 || !supported)
+		return;
+
+	err = xs_error(xs_single(XBT_NIL, XS_RESET_WATCHES, "", NULL));
+	if (err && err != -EEXIST)
+		printk(KERN_WARNING "xs_reset_watches failed: %d\n", err);
+}
+
 /* Register callback to watch this node. */
 int register_xenbus_watch(struct xenbus_watch *watch)
 {
@@ -897,5 +915,8 @@ int xs_init(void)
 	if (IS_ERR(task))
 		return PTR_ERR(task);
 
+	/* shutdown watches for kexec boot */
+	xs_reset_watches();
+
 	return 0;
 }
Index: linux-3.2/include/xen/interface/io/xs_wire.h
===================================================================
--- linux-3.2.orig/include/xen/interface/io/xs_wire.h
+++ linux-3.2/include/xen/interface/io/xs_wire.h
@@ -29,7 +29,8 @@ enum xsd_sockmsg_type
     XS_IS_DOMAIN_INTRODUCED,
     XS_RESUME,
     XS_SET_TARGET,
-    XS_RESTRICT
+    XS_RESTRICT,
+    XS_RESET_WATCHES
 };
 
 #define XS_WRITE_NONE "NONE"

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:00:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21: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 1RiuPP-0002z0-3U; Thu, 05 Jan 2012 20:59:35 +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 1RiuPN-0002yq-P2
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 20:59:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325797167!9892688!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzI1MTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzI1MTQ=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20315 invoked from network); 5 Jan 2012 20:59:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Jan 2012 20:59:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325797166; l=1617;
	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=yFsr9al+lwxShyCpCl5tiEaPnIc=;
	b=n7QzdJNX+U3QS2cd4e7cPVdfLIwaChcQPcRDXrr+mY7LaPoKz6CmUZbyDlCMKAUJ9BV
	hCS3HcU5CZJEPxtgDBCPAPXHWtuAjfu/bzrj8XVpw+ERIkDUH/GxiXjDVpwFW0NeN8kf5
	c1QlIPrsM2r8NEjk6Y6xV3W30hBHoCoz2S8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by post.strato.de (mrclete mo52) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B020a5o05JvXG6 ;
	Thu, 5 Jan 2012 21:59:11 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id DEC4B18637; Thu,  5 Jan 2012 21:59:10 +0100 (CET)
Date: Thu, 5 Jan 2012 21:59:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120105205910.GA29311@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, hongkaixing@huawei.com wrote:

> # HG changeset patch
> # User hongkaixing<hongkaixing@huawei.com>
> # Date 1325149704 -28800
> # Node ID 052727b8165ce6e05002184ae894096214c8b537
> # Parent  54a5e994a241a506900ee0e197bb42e5f1d8e759
> xenpaging:add a new array to speed up page-in in xenpaging
> 
> This patch adds a new array named page_out_index to reserve the victim's index.
> When page in a page,it has to go through a for loop from 0 to num_pages to find
> the right page to read,and it costs much time in this loop.After adding the
> page_out_index array,it just reads the arrry to get the right page,and saves much time.
> 
> The following is a xenpaging test on suse11-64 with 4G memories.
> 
> Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
> 512M(131072)		    2.6s		           540s			             530s
> 2G(524288)		    15.5s		           2088s			     2055s

Thanks for your work on this.

Is the page-out time for 512M really that fast? For me page-out is still
really slow even when the pagefile is in tmpfs. It takes several
minutes, I get around 4MB/s. page-in is around 20MB/s.

Wether an extra array is needed, we have to decide as it costs some
runtime memory. I was thinking already about better bitop functions,
like xc_find_next_bit_set and similar, just what xenpaging needs, to
remove the test bits one-by-one.

As for the new page-in op, there was some offline discussion about doing
page-in/page-out differently. If these ideas make into xen-unstable most
of domctls will disappear, and also the mmap to trigger page-in is not
needed anymore.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:00:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21: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 1RiuPP-0002z0-3U; Thu, 05 Jan 2012 20:59:35 +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 1RiuPN-0002yq-P2
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 20:59:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325797167!9892688!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzI1MTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzI1MTQ=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20315 invoked from network); 5 Jan 2012 20:59:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-9.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 5 Jan 2012 20:59:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325797166; l=1617;
	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=yFsr9al+lwxShyCpCl5tiEaPnIc=;
	b=n7QzdJNX+U3QS2cd4e7cPVdfLIwaChcQPcRDXrr+mY7LaPoKz6CmUZbyDlCMKAUJ9BV
	hCS3HcU5CZJEPxtgDBCPAPXHWtuAjfu/bzrj8XVpw+ERIkDUH/GxiXjDVpwFW0NeN8kf5
	c1QlIPrsM2r8NEjk6Y6xV3W30hBHoCoz2S8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjjQQFYbe
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-107-063.pools.arcor-ip.net [88.65.107.63])
	by post.strato.de (mrclete mo52) (RZmta 27.2 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B020a5o05JvXG6 ;
	Thu, 5 Jan 2012 21:59:11 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id DEC4B18637; Thu,  5 Jan 2012 21:59:10 +0100 (CET)
Date: Thu, 5 Jan 2012 21:59:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120105205910.GA29311@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, hongkaixing@huawei.com wrote:

> # HG changeset patch
> # User hongkaixing<hongkaixing@huawei.com>
> # Date 1325149704 -28800
> # Node ID 052727b8165ce6e05002184ae894096214c8b537
> # Parent  54a5e994a241a506900ee0e197bb42e5f1d8e759
> xenpaging:add a new array to speed up page-in in xenpaging
> 
> This patch adds a new array named page_out_index to reserve the victim's index.
> When page in a page,it has to go through a for loop from 0 to num_pages to find
> the right page to read,and it costs much time in this loop.After adding the
> page_out_index array,it just reads the arrry to get the right page,and saves much time.
> 
> The following is a xenpaging test on suse11-64 with 4G memories.
> 
> Nums of page_out pages	Page out time	Page in time(in unstable code) Page in time(apply this patch)
> 512M(131072)		    2.6s		           540s			             530s
> 2G(524288)		    15.5s		           2088s			     2055s

Thanks for your work on this.

Is the page-out time for 512M really that fast? For me page-out is still
really slow even when the pagefile is in tmpfs. It takes several
minutes, I get around 4MB/s. page-in is around 20MB/s.

Wether an extra array is needed, we have to decide as it costs some
runtime memory. I was thinking already about better bitop functions,
like xc_find_next_bit_set and similar, just what xenpaging needs, to
remove the test bits one-by-one.

As for the new page-in op, there was some offline discussion about doing
page-in/page-out differently. If these ideas make into xen-unstable most
of domctls will disappear, and also the mmap to trigger page-in is not
needed anymore.

Olaf

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:25:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riunc-0003Hh-9g; Thu, 05 Jan 2012 21:24: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 1Riunb-0003Hc-0P
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 21:24:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1325798608!63143467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3989 invoked from network); 5 Jan 2012 21:23:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 21:23:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,464,1320624000"; 
   d="scan'208";a="9848788"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 21:24: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, 5 Jan 2012 21:24: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 1RiunU-00039p-2o;
	Thu, 05 Jan 2012 21:24:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RiunT-00082a-TE;
	Thu, 05 Jan 2012 21:24:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10640-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 21:24:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10640: 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 10640 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10640/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10635
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10635
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10635

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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-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-i386-i386-xl-winxpsp3   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-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  efaa28639a71

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Brownlee <abs@netbsd.org>
  David Vrabel <david.vrabel@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=4086e4811547
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 4086e4811547
+ branch=xen-unstable
+ revision=4086e4811547
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 4086e4811547 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 13 changes to 12 files

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:25:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21:25:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riunc-0003Hh-9g; Thu, 05 Jan 2012 21:24: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 1Riunb-0003Hc-0P
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 21:24:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1325798608!63143467!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3989 invoked from network); 5 Jan 2012 21:23:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 21:23:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,464,1320624000"; 
   d="scan'208";a="9848788"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	05 Jan 2012 21:24: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, 5 Jan 2012 21:24: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 1RiunU-00039p-2o;
	Thu, 05 Jan 2012 21:24:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RiunT-00082a-TE;
	Thu, 05 Jan 2012 21:24:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10640-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 5 Jan 2012 21:24:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10640: 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 10640 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10640/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10635
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10635
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10635

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-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-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-i386-i386-xl-winxpsp3   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-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  efaa28639a71

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  Dario Faggioli <dario.faggioli@citrix.com>
  David Brownlee <abs@netbsd.org>
  David Vrabel <david.vrabel@citrix.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@citrix.com>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=4086e4811547
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 4086e4811547
+ branch=xen-unstable
+ revision=4086e4811547
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 4086e4811547 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 13 changes to 12 files

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:26:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21:26:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiupJ-0003LK-Pt; Thu, 05 Jan 2012 21:26:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RiupI-0003L8-Cg
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 21:26:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325798772!9770952!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0ODM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14696 invoked from network); 5 Jan 2012 21:26:13 -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; 5 Jan 2012 21:26:13 -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
	q05LQ5Vv023994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 21:26:05 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
	q05LQ3kt000280
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 21:26:04 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q05LQ2D0002186; Thu, 5 Jan 2012 15:26:03 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Jan 2012 13:26:02 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5DD7140467; Thu,  5 Jan 2012 16:24:25 -0500 (EST)
Date: Thu, 5 Jan 2012 16:24:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120105212425.GA5180@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
	<4F0566E2020000780006A89C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0566E2020000780006A89C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F06156E.002D,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Allen M Kay <allen.m.kay@intel.com>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
 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, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> > with the latest upstream Linux kernel.
> > 
> > 
> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> > 2.6.18 kernel in blkback if you are using that version.
> 
> Which one are you referring to?

The fix you posted some time ago. Not all distros have picked it up.

# 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;

> 
> Jan

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:26:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21:26:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiupJ-0003LK-Pt; Thu, 05 Jan 2012 21:26:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RiupI-0003L8-Cg
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 21:26:20 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325798772!9770952!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0ODM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14696 invoked from network); 5 Jan 2012 21:26:13 -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; 5 Jan 2012 21:26:13 -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
	q05LQ5Vv023994
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 21:26:05 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
	q05LQ3kt000280
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 21:26:04 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q05LQ2D0002186; Thu, 5 Jan 2012 15:26:03 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Jan 2012 13:26:02 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5DD7140467; Thu,  5 Jan 2012 16:24:25 -0500 (EST)
Date: Thu, 5 Jan 2012 16:24:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120105212425.GA5180@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
	<4F0566E2020000780006A89C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0566E2020000780006A89C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F06156E.002D,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Allen M Kay <allen.m.kay@intel.com>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
 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, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> > with the latest upstream Linux kernel.
> > 
> > 
> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> > 2.6.18 kernel in blkback if you are using that version.
> 
> Which one are you referring to?

The fix you posted some time ago. Not all distros have picked it up.

# 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;

> 
> Jan

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiuqX-0003QX-8s; Thu, 05 Jan 2012 21:27:37 +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 1RiuqV-0003QO-OX
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 21:27:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325798815!54826035!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0ODM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9758 invoked from network); 5 Jan 2012 21:26:56 -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; 5 Jan 2012 21:26:56 -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
	q05LRSEK025535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 21:27:29 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
	q05LRRCj002692
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 21:27:28 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
	q05LRRKI018033; Thu, 5 Jan 2012 15:27:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Jan 2012 13:27:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5D25040467; Thu,  5 Jan 2012 16:25:50 -0500 (EST)
Date: Thu, 5 Jan 2012 16:25:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120105212550.GB5180@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
	<1325750726.29084.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325750726.29084.3.camel@dagon.hellion.org.uk>
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.4F0615C1.00B3,ss=1,re=0.000,fgs=0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
	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, Jan 05, 2012 at 08:05:26AM +0000, Ian Campbell wrote:
> On Wed, 2012-01-04 at 23:35 +0000, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> > > I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> > > 
> > > 
> > > 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.
> > 
> > Huh. You are right. Hadn't noticed that before since I was using dom0_mem.
> > 
> > Ian, David: any ideas?
> 
> Nope. It would be nice to see some logs (xen+dom0 and native) though.

I tried this last night and it seems that this problem has existed in 3.0 and in 3.1 as well.
So not a regression but rather something we had never fixed. Interstingly enough you can experience
the same problem with 8GB - you end up having 6GB in dom0. Naturally you can balloon up (hadn't tried
to do it under 4GB with 2.68GB but it looks like you can certainly do it).

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiuqX-0003QX-8s; Thu, 05 Jan 2012 21:27:37 +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 1RiuqV-0003QO-OX
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 21:27:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1325798815!54826035!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0ODM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9758 invoked from network); 5 Jan 2012 21:26:56 -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; 5 Jan 2012 21:26:56 -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
	q05LRSEK025535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 21:27:29 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
	q05LRRCj002692
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 21:27:28 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
	q05LRRKI018033; Thu, 5 Jan 2012 15:27:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Jan 2012 13:27:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5D25040467; Thu,  5 Jan 2012 16:25:50 -0500 (EST)
Date: Thu, 5 Jan 2012 16:25:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120105212550.GB5180@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
	<1325750726.29084.3.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325750726.29084.3.camel@dagon.hellion.org.uk>
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.4F0615C1.00B3,ss=1,re=0.000,fgs=0
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
	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, Jan 05, 2012 at 08:05:26AM +0000, Ian Campbell wrote:
> On Wed, 2012-01-04 at 23:35 +0000, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> > > I'm encountering following problems while using the latest xen-4.1-testing and xen-unstable with the latest Linux 3.2 kernel:
> > > 
> > > 
> > > 1)      Xen-4.1-testing: dom0 only sees ~2.6GB on a 4GB system, using "cat /proc/meminfo".  This is without dom_mem boot parameter and with 64-bit Xen and dom0 Linux.  Native Linux reports correct memory size.
> > 
> > Huh. You are right. Hadn't noticed that before since I was using dom0_mem.
> > 
> > Ian, David: any ideas?
> 
> Nope. It would be nice to see some logs (xen+dom0 and native) though.

I tried this last night and it seems that this problem has existed in 3.0 and in 3.1 as well.
So not a regression but rather something we had never fixed. Interstingly enough you can experience
the same problem with 8GB - you end up having 6GB in dom0. Naturally you can balloon up (hadn't tried
to do it under 4GB with 2.68GB but it looks like you can certainly do it).

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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21: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 1Riuys-00048R-4o; Thu, 05 Jan 2012 21:36:14 +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 1Riuyr-00048D-1w
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 21:36:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325799365!7782178!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0ODM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23868 invoked from network); 5 Jan 2012 21:36:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jan 2012 21:36:06 -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
	q05La2Hr002992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 21:36:03 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
	q05La0OX006810
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 21:36:01 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
	q05La0DC032283; Thu, 5 Jan 2012 15:36:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Jan 2012 13:36:00 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5223040466; Thu,  5 Jan 2012 16:34:23 -0500 (EST)
Date: Thu, 5 Jan 2012 16:34:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Don Dutile <ddutile@redhat.com>
Message-ID: <20120105213423.GC5180@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
	<1325759051.25206.361.camel@zakaz.uk.xensource.com>
	<4F05F2EA.5030502@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F05F2EA.5030502@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F0617C3.00D4,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, 2012 at 01:58:50PM -0500, Don Dutile wrote:
> On 01/05/2012 05:24 AM, Ian Campbell wrote:
> >On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
> >>We use the __pci_reset_function_locked to perform the action.
> >>Also on attaching ("bind") and detaching ("unbind") we save and
> >>restore the configuration states. When the device is disconnected
> >>from a guest we use the "pci_reset_function" to also reset the
> >>device before being passed to another guest.
> >
> >Currently I thought the toolstack was supposed to do the reset (by
> >writing to the reset node in sysfs) as it was (de)assigning devices
> >to/from guests. That's not to say that there isn't an argument for
> >preferring to do it kernels side but it would be interesting to make
> >that argument explicitly.
> >
> >I guess the toolstack doesn't currently save/restore the configuration
> >state, could it though? I guess the state is all available in sysfs. On
> pci_reset_function() saves the config state before doing a fcn-level reset.
> 
> the libvirt toolstack handles the unbind/reset/bind functionality
> and is used by kvm for it's device assignment.

The KVM assigned PCI module does the call as well via the ioctls when
assigning/de-assigning the PCI device. Look in 'kvm_free_assigned_device'
and in 'kvm_vm_ioctl_assign_device'.

Is that what you mean by the unbind/reset/bind functionality - the ioctl
call?


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 21:36:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 21: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 1Riuys-00048R-4o; Thu, 05 Jan 2012 21:36:14 +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 1Riuyr-00048D-1w
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 21:36:13 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325799365!7782178!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc0ODM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23868 invoked from network); 5 Jan 2012 21:36:06 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 5 Jan 2012 21:36:06 -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
	q05La2Hr002992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 21:36:03 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
	q05La0OX006810
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 5 Jan 2012 21:36:01 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
	q05La0DC032283; Thu, 5 Jan 2012 15:36:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 05 Jan 2012 13:36:00 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5223040466; Thu,  5 Jan 2012 16:34:23 -0500 (EST)
Date: Thu, 5 Jan 2012 16:34:23 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Don Dutile <ddutile@redhat.com>
Message-ID: <20120105213423.GC5180@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
	<1325759051.25206.361.camel@zakaz.uk.xensource.com>
	<4F05F2EA.5030502@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F05F2EA.5030502@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F0617C3.00D4,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, 2012 at 01:58:50PM -0500, Don Dutile wrote:
> On 01/05/2012 05:24 AM, Ian Campbell wrote:
> >On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
> >>We use the __pci_reset_function_locked to perform the action.
> >>Also on attaching ("bind") and detaching ("unbind") we save and
> >>restore the configuration states. When the device is disconnected
> >>from a guest we use the "pci_reset_function" to also reset the
> >>device before being passed to another guest.
> >
> >Currently I thought the toolstack was supposed to do the reset (by
> >writing to the reset node in sysfs) as it was (de)assigning devices
> >to/from guests. That's not to say that there isn't an argument for
> >preferring to do it kernels side but it would be interesting to make
> >that argument explicitly.
> >
> >I guess the toolstack doesn't currently save/restore the configuration
> >state, could it though? I guess the state is all available in sysfs. On
> pci_reset_function() saves the config state before doing a fcn-level reset.
> 
> the libvirt toolstack handles the unbind/reset/bind functionality
> and is used by kvm for it's device assignment.

The KVM assigned PCI module does the call as well via the ioctls when
assigning/de-assigning the PCI device. Look in 'kvm_free_assigned_device'
and in 'kvm_vm_ioctl_assign_device'.

Is that what you mean by the unbind/reset/bind functionality - the ioctl
call?


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

From xen-devel-bounces@lists.xensource.com Thu Jan 05 23:16:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 23:16:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiwX5-00059B-Jj; Thu, 05 Jan 2012 23:15:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1RiwX4-000596-8I
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 23:15:38 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325805330!7825358!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 9905 invoked from network); 5 Jan 2012 23:15:31 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-16.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Jan 2012 23:15:31 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1RiwWv-000181-34
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:15:29 -0800
Date: Thu, 5 Jan 2012 15:15:29 -0800 (PST)
From: romihs <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325805329088-5124160.post@n5.nabble.com>
In-Reply-To: <CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 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

Hello,

I am not a developer, but am using this discussion as a guideline to getting
PCI passthrough working on my system.

I am trying to get a EVGA GTX480 SE passed through to the VM (Windows 7).

Also I am considering arranging my system so that the NVIDIA card will be
the secondary VGA interface, passed through to my DomU. The primary
interface (on-board VGA) will be used for Dom0.

I would like to ask if the current xen-unstable (24462) has the patches
discussed here incorporated into it or will I still have to patch this
version to get my NVDIA card passed through?


Also, has anyone successfully passed the GTX480 through to a Windows or
Linux DomU?

Thanks and best regards

Sandi

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5124160.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 Jan 05 23:16:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 23:16:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiwX5-00059B-Jj; Thu, 05 Jan 2012 23:15:39 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1RiwX4-000596-8I
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 23:15:38 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1325805330!7825358!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 9905 invoked from network); 5 Jan 2012 23:15:31 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-16.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	5 Jan 2012 23:15:31 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1RiwWv-000181-34
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 15:15:29 -0800
Date: Thu, 5 Jan 2012 15:15:29 -0800 (PST)
From: romihs <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325805329088-5124160.post@n5.nabble.com>
In-Reply-To: <CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 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

Hello,

I am not a developer, but am using this discussion as a guideline to getting
PCI passthrough working on my system.

I am trying to get a EVGA GTX480 SE passed through to the VM (Windows 7).

Also I am considering arranging my system so that the NVIDIA card will be
the secondary VGA interface, passed through to my DomU. The primary
interface (on-board VGA) will be used for Dom0.

I would like to ask if the current xen-unstable (24462) has the patches
discussed here incorporated into it or will I still have to patch this
version to get my NVDIA card passed through?


Also, has anyone successfully passed the GTX480 through to a Windows or
Linux DomU?

Thanks and best regards

Sandi

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5124160.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 Jan 05 23:39:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 23:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiwtJ-0005ip-JJ; Thu, 05 Jan 2012 23:38:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netlogic.xen@gmail.com>) id 1RiwtH-0005ii-Kq
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 23:38:35 +0000
X-Env-Sender: netlogic.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325806704!9713851!1
X-Originating-IP: [209.85.160.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 19825 invoked from network); 5 Jan 2012 23:38:29 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 23:38:29 -0000
Received: by pbbb11 with SMTP id b11so2946685pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 15:38: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=QeQibiQjNzKL0Yva8nmKqE0CgdeEQVFN1A5D8+VvsB0=;
	b=idLPLvFMtnnk9H7EZRn5ze8RU4KLcndaTI/UTL7FAnDypy4eiuZme+l/p8PY6PjUqz
	C/2QBxMfCfs1/BeH/HyWeJkGFmgBW64lCeO7SD7czrY1AOCtscH1/OT8PZ9LcdGeI0fo
	zm+Ckxw72jIPda5IWeAMINuwZ1qYHHbDcZuCw=
MIME-Version: 1.0
Received: by 10.68.72.136 with SMTP id d8mr9769273pbv.75.1325806703611; Thu,
	05 Jan 2012 15:38:23 -0800 (PST)
Received: by 10.142.154.6 with HTTP; Thu, 5 Jan 2012 15:38:23 -0800 (PST)
Date: Thu, 5 Jan 2012 15:38:23 -0800
Message-ID: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
From: Prasad Boddupalli <netlogic.xen@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] MIPS port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7853918936682398348=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7853918936682398348==
Content-Type: multipart/alternative; boundary=f46d040f9daa9c0fea04b5d06d6d

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

Hello All,

About 3 weeks back, after resolving some console related issues, SMP
versions of PV dom0 and domU could be booted on our MIPS boards. Our
current version of MIPS Xen is based on an old version (3.4.0) and are
currently in the process of moving the changes to the unstable branch. The
Linux changes are not part of pv-ops infrastructure.

Although we have our simulator, the plan is to get the above running on
Qemu to enable others try out the MIPS version of Xen. Linux could be
released as a tarball for the present.

The performance of applications such as hackbench is a little
unsatisfactory when run on PV Linux (due to frequent traps in the syscall
path). So, we are also working on performance improvements, which probably
could go on in parallel with the submission to open source.

Any suggestions with regard to submitting our changes are welcome.

Prasad.

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

Hello All,<br><br>About 3 weeks back, after resolving some console related =
issues, SMP versions of PV dom0 and domU could be booted on our MIPS boards=
. Our current version of MIPS Xen is based on an old version (3.4.0) and ar=
e currently in the process of moving the changes to the unstable branch. Th=
e Linux changes are not part of pv-ops infrastructure.<br>

<br>Although we have our simulator, the plan is to get the above running on=
 Qemu to enable others try out the MIPS version of Xen. Linux could be rele=
ased as a tarball for the present.<br><br>The performance of applications s=
uch as hackbench is a little unsatisfactory when run on PV Linux (due to fr=
equent traps in the syscall path). So, we are also working on performance i=
mprovements, which probably could go on in parallel with the submission to =
open source.<br>

<br>Any suggestions with regard to submitting our changes are welcome.<br><=
br>Prasad.<br>

--f46d040f9daa9c0fea04b5d06d6d--


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

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

--===============7853918936682398348==--


From xen-devel-bounces@lists.xensource.com Thu Jan 05 23:39:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 05 Jan 2012 23:39:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiwtJ-0005ip-JJ; Thu, 05 Jan 2012 23:38:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <netlogic.xen@gmail.com>) id 1RiwtH-0005ii-Kq
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 23:38:35 +0000
X-Env-Sender: netlogic.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325806704!9713851!1
X-Originating-IP: [209.85.160.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 19825 invoked from network); 5 Jan 2012 23:38:29 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	5 Jan 2012 23:38:29 -0000
Received: by pbbb11 with SMTP id b11so2946685pbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 15:38: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=QeQibiQjNzKL0Yva8nmKqE0CgdeEQVFN1A5D8+VvsB0=;
	b=idLPLvFMtnnk9H7EZRn5ze8RU4KLcndaTI/UTL7FAnDypy4eiuZme+l/p8PY6PjUqz
	C/2QBxMfCfs1/BeH/HyWeJkGFmgBW64lCeO7SD7czrY1AOCtscH1/OT8PZ9LcdGeI0fo
	zm+Ckxw72jIPda5IWeAMINuwZ1qYHHbDcZuCw=
MIME-Version: 1.0
Received: by 10.68.72.136 with SMTP id d8mr9769273pbv.75.1325806703611; Thu,
	05 Jan 2012 15:38:23 -0800 (PST)
Received: by 10.142.154.6 with HTTP; Thu, 5 Jan 2012 15:38:23 -0800 (PST)
Date: Thu, 5 Jan 2012 15:38:23 -0800
Message-ID: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
From: Prasad Boddupalli <netlogic.xen@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] MIPS port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7853918936682398348=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7853918936682398348==
Content-Type: multipart/alternative; boundary=f46d040f9daa9c0fea04b5d06d6d

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

Hello All,

About 3 weeks back, after resolving some console related issues, SMP
versions of PV dom0 and domU could be booted on our MIPS boards. Our
current version of MIPS Xen is based on an old version (3.4.0) and are
currently in the process of moving the changes to the unstable branch. The
Linux changes are not part of pv-ops infrastructure.

Although we have our simulator, the plan is to get the above running on
Qemu to enable others try out the MIPS version of Xen. Linux could be
released as a tarball for the present.

The performance of applications such as hackbench is a little
unsatisfactory when run on PV Linux (due to frequent traps in the syscall
path). So, we are also working on performance improvements, which probably
could go on in parallel with the submission to open source.

Any suggestions with regard to submitting our changes are welcome.

Prasad.

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

Hello All,<br><br>About 3 weeks back, after resolving some console related =
issues, SMP versions of PV dom0 and domU could be booted on our MIPS boards=
. Our current version of MIPS Xen is based on an old version (3.4.0) and ar=
e currently in the process of moving the changes to the unstable branch. Th=
e Linux changes are not part of pv-ops infrastructure.<br>

<br>Although we have our simulator, the plan is to get the above running on=
 Qemu to enable others try out the MIPS version of Xen. Linux could be rele=
ased as a tarball for the present.<br><br>The performance of applications s=
uch as hackbench is a little unsatisfactory when run on PV Linux (due to fr=
equent traps in the syscall path). So, we are also working on performance i=
mprovements, which probably could go on in parallel with the submission to =
open source.<br>

<br>Any suggestions with regard to submitting our changes are welcome.<br><=
br>Prasad.<br>

--f46d040f9daa9c0fea04b5d06d6d--


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

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

--===============7853918936682398348==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 00:58:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 00:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riy8E-0006gI-NA; Fri, 06 Jan 2012 00:58:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Riy8C-0006gD-IQ
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 00:58:04 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325811477!9764433!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNjM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29567 invoked from network); 6 Jan 2012 00:57:58 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 00:57:58 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 05 Jan 2012 16:57:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="95005758"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 05 Jan 2012 16:57:56 -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, 6 Jan 2012 08:57:55 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 6 Jan 2012 08:57:55 +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; Fri, 6 Jan 2012 08:57:53 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4A=
Date: Fri, 6 Jan 2012 00:57:53 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
In-Reply-To: <20120103165917.GB749@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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"'Konrad Rzeszutek Wilk \(konrad.wilk@oracle.com\)'"
	<konrad.wilk@oracle.com>
Subject: Re: [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

> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Wednesday, January 04, 2012 12:59 AM
> 
> On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote:
> > Hi, Konrad
> 
> Hey!
> 
> Sorry for taking so long to respond. Holidays.

good season for relax. :-)

> >
> > wiki page
> (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a9004971
> 6207b9c672fd78187b0c77767be0)
> > 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 hadn't seen it... but then my main desktop box where I run intensive
> tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
> The box that has i915 just does some simple framebuffer manipulation and
> that looks OK.

yes, framebuffer console works well in my side too.

> 
> >
> > 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... :-)
> 
> Do you see the same symptoms - checkboard screen?

Not exactly. The screen becomes white, and then the system becomes
unstable and hang several minutes later. It's possible that mine is a 
different issue than listed on the wiki page, since many reasons may 
finally reach the same symptom - GPU hang... :/

> 
> The LKML had some fixes for this from Keith Packard. Something about
> using i915.semaphores=0 I think. And I thought I saw some fixes for
> 3.2-rc7 for this but not sure..

I'll have a try on latest Linux on this. But I suspect that this may be a
virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case),
because same dom0 image could run glxgear smoothly on bare metal.

Thanks
Kevin

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 00:58:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 00:58:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Riy8E-0006gI-NA; Fri, 06 Jan 2012 00:58:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Riy8C-0006gD-IQ
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 00:58:04 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325811477!9764433!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjkzNjM3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29567 invoked from network); 6 Jan 2012 00:57:58 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-14.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 00:57:58 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga101.jf.intel.com with ESMTP; 05 Jan 2012 16:57:57 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="95005758"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 05 Jan 2012 16:57:56 -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, 6 Jan 2012 08:57:55 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 6 Jan 2012 08:57:55 +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; Fri, 6 Jan 2012 08:57:53 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4A=
Date: Fri, 6 Jan 2012 00:57:53 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
In-Reply-To: <20120103165917.GB749@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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"'Konrad Rzeszutek Wilk \(konrad.wilk@oracle.com\)'"
	<konrad.wilk@oracle.com>
Subject: Re: [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

> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Wednesday, January 04, 2012 12:59 AM
> 
> On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote:
> > Hi, Konrad
> 
> Hey!
> 
> Sorry for taking so long to respond. Holidays.

good season for relax. :-)

> >
> > wiki page
> (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a9004971
> 6207b9c672fd78187b0c77767be0)
> > 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 hadn't seen it... but then my main desktop box where I run intensive
> tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
> The box that has i915 just does some simple framebuffer manipulation and
> that looks OK.

yes, framebuffer console works well in my side too.

> 
> >
> > 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... :-)
> 
> Do you see the same symptoms - checkboard screen?

Not exactly. The screen becomes white, and then the system becomes
unstable and hang several minutes later. It's possible that mine is a 
different issue than listed on the wiki page, since many reasons may 
finally reach the same symptom - GPU hang... :/

> 
> The LKML had some fixes for this from Keith Packard. Something about
> using i915.semaphores=0 I think. And I thought I saw some fixes for
> 3.2-rc7 for this but not sure..

I'll have a try on latest Linux on this. But I suspect that this may be a
virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case),
because same dom0 image could run glxgear smoothly on bare metal.

Thanks
Kevin

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 01:09:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 01: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 1RiyID-0002GM-Pq; Fri, 06 Jan 2012 01:08:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RiyIC-0002GH-6v
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 01:08:24 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325812096!9796551!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMzk0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13321 invoked from network); 6 Jan 2012 01:08:17 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 01:08:17 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 05 Jan 2012 17:08:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="109273518"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga002.fm.intel.com with ESMTP; 05 Jan 2012 17:08:13 -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, 6 Jan 2012 09:08:00 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 6 Jan 2012 09:08:00 +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; Fri, 6 Jan 2012 09:07:59 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: AQHMwR8jSQj+OztfxUuz+mAW9L1uCZXtWRMwgA1TuICAA+19QA==
Date: Fri, 6 Jan 2012 01:07:58 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D102D62B@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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
In-Reply-To: <20120103205925.GI17472@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "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@kernel.org" <konrad@kernel.org>,
	"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 Rzeszutek Wilk <konrad@darnok.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.wilk@oracle.com]
> Sent: Wednesday, January 04, 2012 4:59 AM
> 
> On Mon, Dec 26, 2011 at 01:31:45AM +0000, Tian, Kevin wrote:
> > > 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.
> 
> Excellent. So now the big question  - is this something you would have the
> time to do?

yes, this is a big question. First, I'd like to give my sincere thanks to you and
Liang for help push this part to Linux upstream. You've done a great job. :-)
Unfortunately I can't afford the time in the short term, due to extremely busy
tasks in other projects, at least in the whole Q1. Really sorry about that. :/

I would very appreciate your help if you could continue lending some time here,
since you've done plenty of works on the cleanup. The majority of the tricky 
part is related to VCPU/PCPU handling. If putting that part aside, the remaining 
logic should be much simpler.

Thanks
Kevin

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 01:09:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 01: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 1RiyID-0002GM-Pq; Fri, 06 Jan 2012 01:08:25 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RiyIC-0002GH-6v
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 01:08:24 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325812096!9796551!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwMzk0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13321 invoked from network); 6 Jan 2012 01:08:17 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-5.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 01:08:17 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 05 Jan 2012 17:08:16 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="109273518"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga002.fm.intel.com with ESMTP; 05 Jan 2012 17:08:13 -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, 6 Jan 2012 09:08:00 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX151.gar.corp.intel.com (172.30.236.41) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 6 Jan 2012 09:08:00 +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; Fri, 6 Jan 2012 09:07:59 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: AQHMwR8jSQj+OztfxUuz+mAW9L1uCZXtWRMwgA1TuICAA+19QA==
Date: Fri, 6 Jan 2012 01:07:58 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D102D62B@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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
In-Reply-To: <20120103205925.GI17472@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "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@kernel.org" <konrad@kernel.org>,
	"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 Rzeszutek Wilk <konrad@darnok.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.wilk@oracle.com]
> Sent: Wednesday, January 04, 2012 4:59 AM
> 
> On Mon, Dec 26, 2011 at 01:31:45AM +0000, Tian, Kevin wrote:
> > > 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.
> 
> Excellent. So now the big question  - is this something you would have the
> time to do?

yes, this is a big question. First, I'd like to give my sincere thanks to you and
Liang for help push this part to Linux upstream. You've done a great job. :-)
Unfortunately I can't afford the time in the short term, due to extremely busy
tasks in other projects, at least in the whole Q1. Really sorry about that. :/

I would very appreciate your help if you could continue lending some time here,
since you've done plenty of works on the cleanup. The majority of the tricky 
part is related to VCPU/PCPU handling. If putting that part aside, the remaining 
logic should be much simpler.

Thanks
Kevin

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 01:13:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 01:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiyN2-0002O3-HJ; Fri, 06 Jan 2012 01:13:24 +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 1RiyN1-0002Nx-2c
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 01:13:23 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325812395!2008199!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 30262 invoked from network); 6 Jan 2012 01:13:16 -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 Jan 2012 01:13:16 -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 1RiyMs-0002Fs-C6
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:13:14 -0800
Date: Thu, 5 Jan 2012 17:13:14 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325812394368-5124377.post@n5.nabble.com>
In-Reply-To: <1325805329088-5124160.post@n5.nabble.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 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

Forget about Windows 7. I didn't see a single working solution to passthrough
an nVidia card (at least not Quadro) to a win7 domu. 

However WindowsXP works almost painless. Just follow instructions and apply
patches from D. Teacher on his website and everything should work just fine. 
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5124377.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 Jan 06 01:13:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 01:13:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RiyN2-0002O3-HJ; Fri, 06 Jan 2012 01:13:24 +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 1RiyN1-0002Nx-2c
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 01:13:23 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325812395!2008199!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 30262 invoked from network); 6 Jan 2012 01:13:16 -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 Jan 2012 01:13:16 -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 1RiyMs-0002Fs-C6
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 17:13:14 -0800
Date: Thu, 5 Jan 2012 17:13:14 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325812394368-5124377.post@n5.nabble.com>
In-Reply-To: <1325805329088-5124160.post@n5.nabble.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 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

Forget about Windows 7. I didn't see a single working solution to passthrough
an nVidia card (at least not Quadro) to a win7 domu. 

However WindowsXP works almost painless. Just follow instructions and apply
patches from D. Teacher on his website and everything should work just fine. 
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5124377.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 Jan 06 02:36:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 02: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 1Rized-0003Ma-Mj; Fri, 06 Jan 2012 02:35:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Rizeb-0003MI-WB
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 02:35:38 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325817221!58583486!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTQ3Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8146 invoked from network); 6 Jan 2012 02:33:42 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-8.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 02:33:42 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC003EHV7ATZ@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:34 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC006UUV7AJB@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:34 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG10579; Fri,
	06 Jan 2012 10:35:34 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 10:35:26 +0800
Received: from h00166998 (10.166.80.196) by szxeml404-hub.china.huawei.com
	(10.82.67.59) with Microsoft SMTP Server id 14.1.323.3; Fri,
	06 Jan 2012 10:35:24 +0800
Date: Fri, 06 Jan 2012 10:35:57 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20229.60277.415298.787859@mariner.uk.xensource.com>
X-Originating-IP: [10.166.80.196]
To: 'Ian Jackson' <Ian.Jackson@eu.citrix.com>
Message-id: <001501cccc1b$eb6aa580$c23ff080$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczL16Jn0/+jdMRkSh2ETXIJwIdxswAP127w
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60277.415298.787859@mariner.uk.xensource.com>
Cc: 'Olaf Hering' <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Cgo+IC0tLS0t08q8/tStvP4tLS0tLQo+ILeivP7IyzogSWFuIEphY2tzb24gW21haWx0bzpJYW4u
SmFja3NvbkBldS5jaXRyaXguY29tXQo+ILeiy83KsbzkOiAyMDEyxOox1MI2yNUgMjoyNwo+IMrV
vP7IyzogaG9uZ2thaXhpbmdAaHVhd2VpLmNvbQo+ILOty806IE9sYWYgSGVyaW5nOyB4ZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+INb3zOI6IFJlOiBbWGVuLWRldmVsXSBbUEFUQ0hdIHhl
bnBhZ2luZzphZGQgYSBuZXcgYXJyYXkgdG8gc3BlZWQgdXAKcGFnZS1pbgo+IGluIHhlbnBhZ2lu
Zwo+IAo+IGhvbmdrYWl4aW5nQGh1YXdlaS5jb20gd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENI
XSB4ZW5wYWdpbmc6YWRkIGEgbmV3Cj4gYXJyYXkgdG8gc3BlZWQgdXAgcGFnZS1pbiBpbiB4ZW5w
YWdpbmciKToKPiA+IHhlbnBhZ2luZzphZGQgYSBuZXcgYXJyYXkgdG8gc3BlZWQgdXAgcGFnZS1p
biBpbiB4ZW5wYWdpbmcKPiA+Cj4gPiBUaGlzIHBhdGNoIGFkZHMgYSBuZXcgYXJyYXkgbmFtZWQg
cGFnZV9vdXRfaW5kZXggdG8gcmVzZXJ2ZSB0aGUKPiA+IHZpY3RpbSdzIGluZGV4LiAgV2hlbiBw
YWdlIGluIGEgcGFnZSxpdCBoYXMgdG8gZ28gdGhyb3VnaCBhIGZvciBsb29wCj4gPiBmcm9tIDAg
dG8gbnVtX3BhZ2VzIHRvIGZpbmQgdGhlIHJpZ2h0IHBhZ2UgdG8gcmVhZCxhbmQgaXQgY29zdHMg
bXVjaAo+ID4gdGltZSBpbiB0aGlzIGxvb3AuQWZ0ZXIgYWRkaW5nIHRoZSBwYWdlX291dF9pbmRl
eCBhcnJheSxpdCBqdXN0Cj4gPiByZWFkcyB0aGUgYXJycnkgdG8gZ2V0IHRoZSByaWdodCBwYWdl
LGFuZCBzYXZlcyBtdWNoIHRpbWUuCj4gCj4gVGhhbmtzIGZvciB0aGlzIHN1Ym1pc3Npb24uICBP
bGFmIG1heSB3ZWxsIGhhdmUgc29tZSBjb21tZW50cywgYnV0IEkKPiBoYXZlIHNvbWUgdG9vOgo+
IAo+ID4gQEAgLTY2MCw2ICs2NzIsNyBAQAo+ID4gICAgICAgICAgICAgIGJyZWFrOwo+ID4gICAg
ICAgICAgaWYgKCBpICUgMTAwID09IDAgKQo+ID4gICAgICAgICAgICAgIERQUklOVEYoIiVkIHBh
Z2VzIGV2aWN0ZWRcbiIsIGkpOwo+ID4gKyAgICAgICAgcGFnZV9vdXRfaW5kZXhbdmljdGltc1tp
XS5nZm5dLmluZGV4PWk7Cj4gCj4gU3VyZWx5IHRoaXMgc2hvdWxkIGJlIGJldHRlciBkb25lIG11
Y2ggY2xvc2VyIHRvIHRoZSBhY3R1YWwgcG9pbnQKPiB3aGVyZSB3ZSBwYWdlIG91dCA/CgpBZnRl
ciB3ZSBpbXByb3ZlIHRoZSBwYWdlLWluIHNwZWVkLCBzZWFyY2ggaW5kZXggaW4gdGhlIGZvciBs
b29wIGJlY29tZXMgdGhlCmJvdHRsZW5lY2ssIGV4dHJlbWVseSB3aGVuIHRoZSBwYWdlIG51bWJl
ciBpcyBiaWcuCgo+IAo+IEFuZCB5b3Ugc2hvdWxkIHJlc2V0IHRoZSBpbmRleCBlbnRyeSB3aGVu
IHRoZSBwYWdlIGlzIHJlYWQgYmFjayBpbiwgSQo+IHRoaW5rID8KCkVuLCBvdXIgaWRlYSBpcyBs
ZXQgaXQgZ28gbGF6eSB3YXkuIEkgd2lsbCB0cnkgbXkgYmVzdCB0byBtYWtlIGl0IHBlcmZlY3Qu
Cgo+IAo+IElhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Jan 06 02:36:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 02: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 1Rized-0003Ma-Mj; Fri, 06 Jan 2012 02:35:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Rizeb-0003MI-WB
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 02:35:38 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325817221!58583486!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTQ3Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8146 invoked from network); 6 Jan 2012 02:33:42 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-8.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 02:33:42 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC003EHV7ATZ@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:34 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC006UUV7AJB@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:34 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG10579; Fri,
	06 Jan 2012 10:35:34 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 10:35:26 +0800
Received: from h00166998 (10.166.80.196) by szxeml404-hub.china.huawei.com
	(10.82.67.59) with Microsoft SMTP Server id 14.1.323.3; Fri,
	06 Jan 2012 10:35:24 +0800
Date: Fri, 06 Jan 2012 10:35:57 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20229.60277.415298.787859@mariner.uk.xensource.com>
X-Originating-IP: [10.166.80.196]
To: 'Ian Jackson' <Ian.Jackson@eu.citrix.com>
Message-id: <001501cccc1b$eb6aa580$c23ff080$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczL16Jn0/+jdMRkSh2ETXIJwIdxswAP127w
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60277.415298.787859@mariner.uk.xensource.com>
Cc: 'Olaf Hering' <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Cgo+IC0tLS0t08q8/tStvP4tLS0tLQo+ILeivP7IyzogSWFuIEphY2tzb24gW21haWx0bzpJYW4u
SmFja3NvbkBldS5jaXRyaXguY29tXQo+ILeiy83KsbzkOiAyMDEyxOox1MI2yNUgMjoyNwo+IMrV
vP7IyzogaG9uZ2thaXhpbmdAaHVhd2VpLmNvbQo+ILOty806IE9sYWYgSGVyaW5nOyB4ZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+INb3zOI6IFJlOiBbWGVuLWRldmVsXSBbUEFUQ0hdIHhl
bnBhZ2luZzphZGQgYSBuZXcgYXJyYXkgdG8gc3BlZWQgdXAKcGFnZS1pbgo+IGluIHhlbnBhZ2lu
Zwo+IAo+IGhvbmdrYWl4aW5nQGh1YXdlaS5jb20gd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENI
XSB4ZW5wYWdpbmc6YWRkIGEgbmV3Cj4gYXJyYXkgdG8gc3BlZWQgdXAgcGFnZS1pbiBpbiB4ZW5w
YWdpbmciKToKPiA+IHhlbnBhZ2luZzphZGQgYSBuZXcgYXJyYXkgdG8gc3BlZWQgdXAgcGFnZS1p
biBpbiB4ZW5wYWdpbmcKPiA+Cj4gPiBUaGlzIHBhdGNoIGFkZHMgYSBuZXcgYXJyYXkgbmFtZWQg
cGFnZV9vdXRfaW5kZXggdG8gcmVzZXJ2ZSB0aGUKPiA+IHZpY3RpbSdzIGluZGV4LiAgV2hlbiBw
YWdlIGluIGEgcGFnZSxpdCBoYXMgdG8gZ28gdGhyb3VnaCBhIGZvciBsb29wCj4gPiBmcm9tIDAg
dG8gbnVtX3BhZ2VzIHRvIGZpbmQgdGhlIHJpZ2h0IHBhZ2UgdG8gcmVhZCxhbmQgaXQgY29zdHMg
bXVjaAo+ID4gdGltZSBpbiB0aGlzIGxvb3AuQWZ0ZXIgYWRkaW5nIHRoZSBwYWdlX291dF9pbmRl
eCBhcnJheSxpdCBqdXN0Cj4gPiByZWFkcyB0aGUgYXJycnkgdG8gZ2V0IHRoZSByaWdodCBwYWdl
LGFuZCBzYXZlcyBtdWNoIHRpbWUuCj4gCj4gVGhhbmtzIGZvciB0aGlzIHN1Ym1pc3Npb24uICBP
bGFmIG1heSB3ZWxsIGhhdmUgc29tZSBjb21tZW50cywgYnV0IEkKPiBoYXZlIHNvbWUgdG9vOgo+
IAo+ID4gQEAgLTY2MCw2ICs2NzIsNyBAQAo+ID4gICAgICAgICAgICAgIGJyZWFrOwo+ID4gICAg
ICAgICAgaWYgKCBpICUgMTAwID09IDAgKQo+ID4gICAgICAgICAgICAgIERQUklOVEYoIiVkIHBh
Z2VzIGV2aWN0ZWRcbiIsIGkpOwo+ID4gKyAgICAgICAgcGFnZV9vdXRfaW5kZXhbdmljdGltc1tp
XS5nZm5dLmluZGV4PWk7Cj4gCj4gU3VyZWx5IHRoaXMgc2hvdWxkIGJlIGJldHRlciBkb25lIG11
Y2ggY2xvc2VyIHRvIHRoZSBhY3R1YWwgcG9pbnQKPiB3aGVyZSB3ZSBwYWdlIG91dCA/CgpBZnRl
ciB3ZSBpbXByb3ZlIHRoZSBwYWdlLWluIHNwZWVkLCBzZWFyY2ggaW5kZXggaW4gdGhlIGZvciBs
b29wIGJlY29tZXMgdGhlCmJvdHRsZW5lY2ssIGV4dHJlbWVseSB3aGVuIHRoZSBwYWdlIG51bWJl
ciBpcyBiaWcuCgo+IAo+IEFuZCB5b3Ugc2hvdWxkIHJlc2V0IHRoZSBpbmRleCBlbnRyeSB3aGVu
IHRoZSBwYWdlIGlzIHJlYWQgYmFjayBpbiwgSQo+IHRoaW5rID8KCkVuLCBvdXIgaWRlYSBpcyBs
ZXQgaXQgZ28gbGF6eSB3YXkuIEkgd2lsbCB0cnkgbXkgYmVzdCB0byBtYWtlIGl0IHBlcmZlY3Qu
Cgo+IAo+IElhbi4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
Cmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Jan 06 02:36:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 02: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 1RizeS-0003Lj-TN; Fri, 06 Jan 2012 02:35:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RizeR-0003Ld-8Z
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 02:35:27 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325817319!8011181!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiAxMzQ4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32400 invoked from network); 6 Jan 2012 02:35:20 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66) by server-6.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 02:35:20 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC00MV3V6UTM@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:18 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC00C4GV4Y1C@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:18 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG10540; Fri,
	06 Jan 2012 10:35:12 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 10:35:09 +0800
Received: from h00166998 (10.166.80.196) by szxeml404-hub.china.huawei.com
	(10.82.67.59) with Microsoft SMTP Server id 14.1.323.3; Fri,
	06 Jan 2012 10:34:51 +0800
Date: Fri, 06 Jan 2012 10:35:12 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20229.60517.106414.825193@mariner.uk.xensource.com>
X-Originating-IP: [10.166.80.196]
To: 'Ian Jackson' <Ian.Jackson@eu.citrix.com>
Message-id: <001301cccc1b$d7ca1470$875e3d50$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczL2EzfA/F+k/lUSlKwTtS/ufoHAgAOY6Ew
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
Cc: "'bicky.'" <bicky.shi@huawei.com>, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in	in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Cgo+IC0tLS0t08q8/tStvP4tLS0tLQo+ILeivP7IyzogSWFuIEphY2tzb24gW21haWx0bzpJYW4u
SmFja3NvbkBldS5jaXRyaXguY29tXQo+ILeiy83KsbzkOiAyMDEyxOox1MI2yNUgMjozMQo+IMrV
vP7IyzogaG9uZ2thaXhpbmdAaHVhd2VpLmNvbQo+ILOty806IE9sYWYgSGVyaW5nOyB4ZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+INb3zOI6IFJlOiBbWGVuLWRldmVsXSBbUEFUQ0hdIHhl
bnBhZ2luZzphZGQgYSBuZXcgYXJyYXkgdG8gc3BlZWQgdXAKcGFnZS1pbgo+IGluIHhlbnBhZ2lu
Zwo+IAo+IGhvbmdrYWl4aW5nQGh1YXdlaS5jb20gd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENI
XSB4ZW5wYWdpbmc6YWRkIGEgbmV3Cj4gYXJyYXkgdG8gc3BlZWQgdXAgcGFnZS1pbiBpbiB4ZW5w
YWdpbmciKToKPiA+IHhlbnBhZ2luZzphZGQgYSBuZXcgYXJyYXkgdG8gc3BlZWQgdXAgcGFnZS1p
biBpbiB4ZW5wYWdpbmcKPiAKPiBPaCwgYW5kIGEgY291cGxlIG9mIHN0eWxlIHBvaW50cy4gIFlv
dSBzaG91bGQga2VlcCB0byB0aGUgc3R5bGUgb2YgdGhlCj4gY29kZSB5b3UncmUgZWRpdGluZy4g
IFNvOgo+IAo+ID4gKyAgICBpZiAoTlVMTCA9PSB2aWN0aW1zKQo+IAo+IEluIHRoZSB4ZW5wYWdp
bmcgY29kZSB0aGlzIGlzIHdyaXR0ZW4gbGlrZSB0aGlzOgo+IAo+ICAgICAgICBpZiAodmljdGlt
cyA9PSBOVUxMKQo+IAoKT2gsIFRoaXMgaXMgb3VyIGNvZGluZyBzdHlsZSwgSSB3aWxsIG1vZGlm
eSBpdCBhY2NvcmRpbmcgeW91ciBvcGluaW9uLgoKPiBZb3Ugc2hvdWxkIGRvIHRoZSBzYW1lLCB0
aHJvdWdob3V0Lgo+IAo+ID4gKyAgICBwYWdlX291dF9pbmRleCA9ICh2aWN0aW1fdG9faV90Cj4g
KiljYWxsb2MocGFnaW5nLT5kb21haW5faW5mby0+bWF4X3BhZ2VzLCBzaXplb2YodmljdGltX3Rv
X2lfdCkpOwo+IAo+IERvIG5vdCBjYXN0IHRoZSByZXR1cm4gdmFsdWUgZnJvbSBtYWxsb2MgZXQg
YWwuCj4gCj4gPiArICAgICAgICAgICAgICAgIGkgPSBwYWdlX291dF9pbmRleFtyZXEuZ2ZuXS5p
bmRleCA7Cj4gCj4gVGhlIHNwYWNlIGJlZm9yZSB0aGUgc2VtaWNvbG9uIGlzIG5vdCB0aGUgY29u
dmVudGlvbmFsIHN0eWxlLgo+IAo+ID4gKyAgICAgICAgICAgICAgICAgICAgaWYoIHZpY3RpbXNb
aV0uZ2ZuICE9SU5WQUxJRF9NRk4gKQo+IAo+ID4gLSAgICBmcmVlKHZpY3RpbXMpOwo+ID4gKyAg
ICBpZiAoIE5VTEwgIT0gdmljdGltcyApCj4gPiArICAgIHsKPiA+ICsgICAgICAgIGZyZWUodmlj
dGltcyk7Cj4gPiArICAgIH0KPiAKPiBUaGlzIGlzIHNpbXBseSBwb2ludGxlc3MuICBmcmVlKE5V
TEwpIGlzIGxlZ2FsLgoKSSBzZWUuLi4KCj4gCj4gPiArdHlwZWRlZiBzdHJ1Y3QgdmljdGltX3Rv
X2kgewo+ID4gKyAgICAvKiB0aGUgaW5kZXggb2YgdmljdGltIGFycmF5IHRvIHJlYWQgZnJvbSAq
Lwo+ID4gKyAgICBpbnQgaW5kZXg7Cj4gPiArfSB2aWN0aW1fdG9faV90Owo+IAo+IFdoeSB3cmFw
IHRoaXMgdXAgaW4gYSBzdHJ1Y3QgPwoKV2Ugd2FudCB0byBrZWVwIHRoZSBzYW1lIHN0eWxlIHdp
dGgKCnR5cGVkZWYgc3RydWN0IHhlbnBhZ2luZ192aWN0aW0gewogICAgLyogdGhlIGdmbiBvZiB0
aGUgcGFnZSB0byBldmljdCAqLwogICAgdW5zaWduZWQgbG9uZyBnZm47Cn0geGVucGFnaW5nX3Zp
Y3RpbV90OwoKPiAKPiBVc2Ugb2YgdHlwZXMgd2l0aCBuYW1lcyBlbmRpbmcgaW4gX3QgaXMgcmVz
ZXJ2ZWQgdG8gdGhlIEMKPiBpbXBsZW1lbnRhdGlvbiAoY29tcGlsZXIgYW5kIHJ1bnRpbWUpLiAg
SSBrbm93IHhlbnBhZ2luZyBpcyBmdWxsIG9mCj4gdGhlc2UgYnV0IHdlIHNob3VsZG4ndCBpbnRy
b2R1Y2UgYW55IG1vcmUuCj4gCj4gSWFuLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Jan 06 02:36:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 02: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 1RizeY-0003Ly-9P; Fri, 06 Jan 2012 02:35:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RizeW-0003Li-U6
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 02:35:33 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325817325!9770252!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTQ3Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6018 invoked from network); 6 Jan 2012 02:35:26 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-9.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 02:35:26 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC00NYOV7033@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:24 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC00DCYV70V5@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:24 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGE06677; Fri,
	06 Jan 2012 10:35:24 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 10:35:12 +0800
Received: from h00166998 (10.166.80.196) by szxeml404-hub.china.huawei.com
	(10.82.67.59) with Microsoft SMTP Server id 14.1.323.3; Fri,
	06 Jan 2012 10:35:12 +0800
Date: Fri, 06 Jan 2012 10:35:12 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120105205910.GA29311@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <001401cccc1b$e43b5a20$acb20e60$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczL7O0/5v3KSdeXSv+jr/yAoj2aswAIOePQ
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20120105205910.GA29311@aepfle.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T2gsIHNvcnJ5LCB0aGlzIHBhdGNoIGlzIHNlbnQgaW4gaHVycnksIHRoZSB3aG9sZSB2ZXJzaW9u
IGlzIHNlbnQgb3V0IGZvbGxvdyB0aGlzIG9uZS4gCgpBY2NvcmRpbmcgdG8gb3VyIGFuYWx5c2lz
LCB0aGUgb2xkIHBhZ2UgaW4gbWV0aG9kIHNwZW5kcyBtdWNoIHRpbWUgaW4geGNfbWFwX2ZvcmVp
Z25fcGFnZXMsIHNvIHdlIGludHJvZHVjZSBhIGRpcmVjdCB3YXkgdG8gdHJpZ2dlciBwYWdlIGlu
LiAgVGhpcyBpcyB0aGUgcG9pbnQuCkFmdGVyIG91ciBuZXcgcGFnZS1pbiBtZXRob2QgaXMgYXBw
bGllZCwgYSBuZXcgYXJyYXkgY2FuIHNwZWVkIHVwIHBhZ2UgaW4gc2lnbmlmaWNhbnRseS4KClJl
c3VsdCBzaG93cyB0aGUgcGFnZS1pbiBzcGVlZCBjYW4gcmVhY2ggdGhlIGhhcmQgZGlzaydzIGxp
bWl0LCBhYm92ZSAxMjBNL3MKCgoKPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tCj4g5Y+R5Lu25Lq6
OiBPbGFmIEhlcmluZyBbbWFpbHRvOm9sYWZAYWVwZmxlLmRlXQo+IOWPkemAgeaXtumXtDogMjAx
MuW5tDHmnIg25pelIDQ6NTkKPiDmlLbku7bkuro6IGhvbmdrYWl4aW5nQGh1YXdlaS5jb20KPiDm
ioTpgIE6IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4g5Li76aKYOiBSZTogW1BBVENI
XSB4ZW5wYWdpbmc6YWRkIGEgbmV3IGFycmF5IHRvIHNwZWVkIHVwIHBhZ2UtaW4gaW4geGVucGFn
aW5nCj4gCj4gT24gVGh1LCBKYW4gMDUsIGhvbmdrYWl4aW5nQGh1YXdlaS5jb20gd3JvdGU6Cj4g
Cj4gPiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4gIyBVc2VyIGhvbmdrYWl4aW5nPGhvbmdrYWl4
aW5nQGh1YXdlaS5jb20+Cj4gPiAjIERhdGUgMTMyNTE0OTcwNCAtMjg4MDAKPiA+ICMgTm9kZSBJ
RCAwNTI3MjdiODE2NWNlNmUwNTAwMjE4NGFlODk0MDk2MjE0YzhiNTM3Cj4gPiAjIFBhcmVudCAg
NTRhNWU5OTRhMjQxYTUwNjkwMGVlMGUxOTdiYjQyZTVmMWQ4ZTc1OQo+ID4geGVucGFnaW5nOmFk
ZCBhIG5ldyBhcnJheSB0byBzcGVlZCB1cCBwYWdlLWluIGluIHhlbnBhZ2luZwo+ID4KPiA+IFRo
aXMgcGF0Y2ggYWRkcyBhIG5ldyBhcnJheSBuYW1lZCBwYWdlX291dF9pbmRleCB0byByZXNlcnZl
IHRoZSB2aWN0aW0ncwo+IGluZGV4Lgo+ID4gV2hlbiBwYWdlIGluIGEgcGFnZSxpdCBoYXMgdG8g
Z28gdGhyb3VnaCBhIGZvciBsb29wIGZyb20gMCB0byBudW1fcGFnZXMgdG8KPiBmaW5kCj4gPiB0
aGUgcmlnaHQgcGFnZSB0byByZWFkLGFuZCBpdCBjb3N0cyBtdWNoIHRpbWUgaW4gdGhpcyBsb29w
LkFmdGVyIGFkZGluZyB0aGUKPiA+IHBhZ2Vfb3V0X2luZGV4IGFycmF5LGl0IGp1c3QgcmVhZHMg
dGhlIGFycnJ5IHRvIGdldCB0aGUgcmlnaHQgcGFnZSxhbmQgc2F2ZXMKPiBtdWNoIHRpbWUuCj4g
Pgo+ID4gVGhlIGZvbGxvd2luZyBpcyBhIHhlbnBhZ2luZyB0ZXN0IG9uIHN1c2UxMS02NCB3aXRo
IDRHIG1lbW9yaWVzLgo+ID4KPiA+IE51bXMgb2YgcGFnZV9vdXQgcGFnZXMJUGFnZSBvdXQgdGlt
ZQlQYWdlIGluIHRpbWUoaW4gdW5zdGFibGUgY29kZSkKPiBQYWdlIGluIHRpbWUoYXBwbHkgdGhp
cyBwYXRjaCkKPiA+IDUxMk0oMTMxMDcyKQkJICAgIDIuNnMJCSAgICAgICAgICAgNTQwcwo+IDUz
MHMKPiA+IDJHKDUyNDI4OCkJCSAgICAxNS41cwkJICAgICAgICAgICAyMDg4cwo+IDIwNTVzCj4g
Cj4gVGhhbmtzIGZvciB5b3VyIHdvcmsgb24gdGhpcy4KPiAKPiBJcyB0aGUgcGFnZS1vdXQgdGlt
ZSBmb3IgNTEyTSByZWFsbHkgdGhhdCBmYXN0PyBGb3IgbWUgcGFnZS1vdXQgaXMgc3RpbGwKPiBy
ZWFsbHkgc2xvdyBldmVuIHdoZW4gdGhlIHBhZ2VmaWxlIGlzIGluIHRtcGZzLiBJdCB0YWtlcyBz
ZXZlcmFsCj4gbWludXRlcywgSSBnZXQgYXJvdW5kIDRNQi9zLiBwYWdlLWluIGlzIGFyb3VuZCAy
ME1CL3MuCj4gCj4gV2V0aGVyIGFuIGV4dHJhIGFycmF5IGlzIG5lZWRlZCwgd2UgaGF2ZSB0byBk
ZWNpZGUgYXMgaXQgY29zdHMgc29tZQo+IHJ1bnRpbWUgbWVtb3J5LiBJIHdhcyB0aGlua2luZyBh
bHJlYWR5IGFib3V0IGJldHRlciBiaXRvcCBmdW5jdGlvbnMsCj4gbGlrZSB4Y19maW5kX25leHRf
Yml0X3NldCBhbmQgc2ltaWxhciwganVzdCB3aGF0IHhlbnBhZ2luZyBuZWVkcywgdG8KPiByZW1v
dmUgdGhlIHRlc3QgYml0cyBvbmUtYnktb25lLgo+IAo+IEFzIGZvciB0aGUgbmV3IHBhZ2UtaW4g
b3AsIHRoZXJlIHdhcyBzb21lIG9mZmxpbmUgZGlzY3Vzc2lvbiBhYm91dCBkb2luZwo+IHBhZ2Ut
aW4vcGFnZS1vdXQgZGlmZmVyZW50bHkuIElmIHRoZXNlIGlkZWFzIG1ha2UgaW50byB4ZW4tdW5z
dGFibGUgbW9zdAo+IG9mIGRvbWN0bHMgd2lsbCBkaXNhcHBlYXIsIGFuZCBhbHNvIHRoZSBtbWFw
IHRvIHRyaWdnZXIgcGFnZS1pbiBpcyBub3QKPiBuZWVkZWQgYW55bW9yZS4KPiAKPiBPbGFmCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 06 02:36:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 02: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 1RizeY-0003Ly-9P; Fri, 06 Jan 2012 02:35:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RizeW-0003Li-U6
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 02:35:33 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325817325!9770252!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTQ3Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6018 invoked from network); 6 Jan 2012 02:35:26 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-9.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 02:35:26 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC00NYOV7033@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:24 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC00DCYV70V5@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:24 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGE06677; Fri,
	06 Jan 2012 10:35:24 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 10:35:12 +0800
Received: from h00166998 (10.166.80.196) by szxeml404-hub.china.huawei.com
	(10.82.67.59) with Microsoft SMTP Server id 14.1.323.3; Fri,
	06 Jan 2012 10:35:12 +0800
Date: Fri, 06 Jan 2012 10:35:12 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120105205910.GA29311@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <001401cccc1b$e43b5a20$acb20e60$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczL7O0/5v3KSdeXSv+jr/yAoj2aswAIOePQ
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20120105205910.GA29311@aepfle.de>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T2gsIHNvcnJ5LCB0aGlzIHBhdGNoIGlzIHNlbnQgaW4gaHVycnksIHRoZSB3aG9sZSB2ZXJzaW9u
IGlzIHNlbnQgb3V0IGZvbGxvdyB0aGlzIG9uZS4gCgpBY2NvcmRpbmcgdG8gb3VyIGFuYWx5c2lz
LCB0aGUgb2xkIHBhZ2UgaW4gbWV0aG9kIHNwZW5kcyBtdWNoIHRpbWUgaW4geGNfbWFwX2ZvcmVp
Z25fcGFnZXMsIHNvIHdlIGludHJvZHVjZSBhIGRpcmVjdCB3YXkgdG8gdHJpZ2dlciBwYWdlIGlu
LiAgVGhpcyBpcyB0aGUgcG9pbnQuCkFmdGVyIG91ciBuZXcgcGFnZS1pbiBtZXRob2QgaXMgYXBw
bGllZCwgYSBuZXcgYXJyYXkgY2FuIHNwZWVkIHVwIHBhZ2UgaW4gc2lnbmlmaWNhbnRseS4KClJl
c3VsdCBzaG93cyB0aGUgcGFnZS1pbiBzcGVlZCBjYW4gcmVhY2ggdGhlIGhhcmQgZGlzaydzIGxp
bWl0LCBhYm92ZSAxMjBNL3MKCgoKPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tCj4g5Y+R5Lu25Lq6
OiBPbGFmIEhlcmluZyBbbWFpbHRvOm9sYWZAYWVwZmxlLmRlXQo+IOWPkemAgeaXtumXtDogMjAx
MuW5tDHmnIg25pelIDQ6NTkKPiDmlLbku7bkuro6IGhvbmdrYWl4aW5nQGh1YXdlaS5jb20KPiDm
ioTpgIE6IHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4g5Li76aKYOiBSZTogW1BBVENI
XSB4ZW5wYWdpbmc6YWRkIGEgbmV3IGFycmF5IHRvIHNwZWVkIHVwIHBhZ2UtaW4gaW4geGVucGFn
aW5nCj4gCj4gT24gVGh1LCBKYW4gMDUsIGhvbmdrYWl4aW5nQGh1YXdlaS5jb20gd3JvdGU6Cj4g
Cj4gPiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+ID4gIyBVc2VyIGhvbmdrYWl4aW5nPGhvbmdrYWl4
aW5nQGh1YXdlaS5jb20+Cj4gPiAjIERhdGUgMTMyNTE0OTcwNCAtMjg4MDAKPiA+ICMgTm9kZSBJ
RCAwNTI3MjdiODE2NWNlNmUwNTAwMjE4NGFlODk0MDk2MjE0YzhiNTM3Cj4gPiAjIFBhcmVudCAg
NTRhNWU5OTRhMjQxYTUwNjkwMGVlMGUxOTdiYjQyZTVmMWQ4ZTc1OQo+ID4geGVucGFnaW5nOmFk
ZCBhIG5ldyBhcnJheSB0byBzcGVlZCB1cCBwYWdlLWluIGluIHhlbnBhZ2luZwo+ID4KPiA+IFRo
aXMgcGF0Y2ggYWRkcyBhIG5ldyBhcnJheSBuYW1lZCBwYWdlX291dF9pbmRleCB0byByZXNlcnZl
IHRoZSB2aWN0aW0ncwo+IGluZGV4Lgo+ID4gV2hlbiBwYWdlIGluIGEgcGFnZSxpdCBoYXMgdG8g
Z28gdGhyb3VnaCBhIGZvciBsb29wIGZyb20gMCB0byBudW1fcGFnZXMgdG8KPiBmaW5kCj4gPiB0
aGUgcmlnaHQgcGFnZSB0byByZWFkLGFuZCBpdCBjb3N0cyBtdWNoIHRpbWUgaW4gdGhpcyBsb29w
LkFmdGVyIGFkZGluZyB0aGUKPiA+IHBhZ2Vfb3V0X2luZGV4IGFycmF5LGl0IGp1c3QgcmVhZHMg
dGhlIGFycnJ5IHRvIGdldCB0aGUgcmlnaHQgcGFnZSxhbmQgc2F2ZXMKPiBtdWNoIHRpbWUuCj4g
Pgo+ID4gVGhlIGZvbGxvd2luZyBpcyBhIHhlbnBhZ2luZyB0ZXN0IG9uIHN1c2UxMS02NCB3aXRo
IDRHIG1lbW9yaWVzLgo+ID4KPiA+IE51bXMgb2YgcGFnZV9vdXQgcGFnZXMJUGFnZSBvdXQgdGlt
ZQlQYWdlIGluIHRpbWUoaW4gdW5zdGFibGUgY29kZSkKPiBQYWdlIGluIHRpbWUoYXBwbHkgdGhp
cyBwYXRjaCkKPiA+IDUxMk0oMTMxMDcyKQkJICAgIDIuNnMJCSAgICAgICAgICAgNTQwcwo+IDUz
MHMKPiA+IDJHKDUyNDI4OCkJCSAgICAxNS41cwkJICAgICAgICAgICAyMDg4cwo+IDIwNTVzCj4g
Cj4gVGhhbmtzIGZvciB5b3VyIHdvcmsgb24gdGhpcy4KPiAKPiBJcyB0aGUgcGFnZS1vdXQgdGlt
ZSBmb3IgNTEyTSByZWFsbHkgdGhhdCBmYXN0PyBGb3IgbWUgcGFnZS1vdXQgaXMgc3RpbGwKPiBy
ZWFsbHkgc2xvdyBldmVuIHdoZW4gdGhlIHBhZ2VmaWxlIGlzIGluIHRtcGZzLiBJdCB0YWtlcyBz
ZXZlcmFsCj4gbWludXRlcywgSSBnZXQgYXJvdW5kIDRNQi9zLiBwYWdlLWluIGlzIGFyb3VuZCAy
ME1CL3MuCj4gCj4gV2V0aGVyIGFuIGV4dHJhIGFycmF5IGlzIG5lZWRlZCwgd2UgaGF2ZSB0byBk
ZWNpZGUgYXMgaXQgY29zdHMgc29tZQo+IHJ1bnRpbWUgbWVtb3J5LiBJIHdhcyB0aGlua2luZyBh
bHJlYWR5IGFib3V0IGJldHRlciBiaXRvcCBmdW5jdGlvbnMsCj4gbGlrZSB4Y19maW5kX25leHRf
Yml0X3NldCBhbmQgc2ltaWxhciwganVzdCB3aGF0IHhlbnBhZ2luZyBuZWVkcywgdG8KPiByZW1v
dmUgdGhlIHRlc3QgYml0cyBvbmUtYnktb25lLgo+IAo+IEFzIGZvciB0aGUgbmV3IHBhZ2UtaW4g
b3AsIHRoZXJlIHdhcyBzb21lIG9mZmxpbmUgZGlzY3Vzc2lvbiBhYm91dCBkb2luZwo+IHBhZ2Ut
aW4vcGFnZS1vdXQgZGlmZmVyZW50bHkuIElmIHRoZXNlIGlkZWFzIG1ha2UgaW50byB4ZW4tdW5z
dGFibGUgbW9zdAo+IG9mIGRvbWN0bHMgd2lsbCBkaXNhcHBlYXIsIGFuZCBhbHNvIHRoZSBtbWFw
IHRvIHRyaWdnZXIgcGFnZS1pbiBpcyBub3QKPiBuZWVkZWQgYW55bW9yZS4KPiAKPiBPbGFmCgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 06 02:36:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 02: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 1RizeS-0003Lj-TN; Fri, 06 Jan 2012 02:35:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RizeR-0003Ld-8Z
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 02:35:27 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325817319!8011181!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiAxMzQ4Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32400 invoked from network); 6 Jan 2012 02:35:20 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66) by server-6.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 02:35:20 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC00MV3V6UTM@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:18 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXC00C4GV4Y1C@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:35:18 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG10540; Fri,
	06 Jan 2012 10:35:12 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 10:35:09 +0800
Received: from h00166998 (10.166.80.196) by szxeml404-hub.china.huawei.com
	(10.82.67.59) with Microsoft SMTP Server id 14.1.323.3; Fri,
	06 Jan 2012 10:34:51 +0800
Date: Fri, 06 Jan 2012 10:35:12 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20229.60517.106414.825193@mariner.uk.xensource.com>
X-Originating-IP: [10.166.80.196]
To: 'Ian Jackson' <Ian.Jackson@eu.citrix.com>
Message-id: <001301cccc1b$d7ca1470$875e3d50$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczL2EzfA/F+k/lUSlKwTtS/ufoHAgAOY6Ew
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
Cc: "'bicky.'" <bicky.shi@huawei.com>, 'Olaf Hering' <olaf@aepfle.de>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in	in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Cgo+IC0tLS0t08q8/tStvP4tLS0tLQo+ILeivP7IyzogSWFuIEphY2tzb24gW21haWx0bzpJYW4u
SmFja3NvbkBldS5jaXRyaXguY29tXQo+ILeiy83KsbzkOiAyMDEyxOox1MI2yNUgMjozMQo+IMrV
vP7IyzogaG9uZ2thaXhpbmdAaHVhd2VpLmNvbQo+ILOty806IE9sYWYgSGVyaW5nOyB4ZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+INb3zOI6IFJlOiBbWGVuLWRldmVsXSBbUEFUQ0hdIHhl
bnBhZ2luZzphZGQgYSBuZXcgYXJyYXkgdG8gc3BlZWQgdXAKcGFnZS1pbgo+IGluIHhlbnBhZ2lu
Zwo+IAo+IGhvbmdrYWl4aW5nQGh1YXdlaS5jb20gd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENI
XSB4ZW5wYWdpbmc6YWRkIGEgbmV3Cj4gYXJyYXkgdG8gc3BlZWQgdXAgcGFnZS1pbiBpbiB4ZW5w
YWdpbmciKToKPiA+IHhlbnBhZ2luZzphZGQgYSBuZXcgYXJyYXkgdG8gc3BlZWQgdXAgcGFnZS1p
biBpbiB4ZW5wYWdpbmcKPiAKPiBPaCwgYW5kIGEgY291cGxlIG9mIHN0eWxlIHBvaW50cy4gIFlv
dSBzaG91bGQga2VlcCB0byB0aGUgc3R5bGUgb2YgdGhlCj4gY29kZSB5b3UncmUgZWRpdGluZy4g
IFNvOgo+IAo+ID4gKyAgICBpZiAoTlVMTCA9PSB2aWN0aW1zKQo+IAo+IEluIHRoZSB4ZW5wYWdp
bmcgY29kZSB0aGlzIGlzIHdyaXR0ZW4gbGlrZSB0aGlzOgo+IAo+ICAgICAgICBpZiAodmljdGlt
cyA9PSBOVUxMKQo+IAoKT2gsIFRoaXMgaXMgb3VyIGNvZGluZyBzdHlsZSwgSSB3aWxsIG1vZGlm
eSBpdCBhY2NvcmRpbmcgeW91ciBvcGluaW9uLgoKPiBZb3Ugc2hvdWxkIGRvIHRoZSBzYW1lLCB0
aHJvdWdob3V0Lgo+IAo+ID4gKyAgICBwYWdlX291dF9pbmRleCA9ICh2aWN0aW1fdG9faV90Cj4g
KiljYWxsb2MocGFnaW5nLT5kb21haW5faW5mby0+bWF4X3BhZ2VzLCBzaXplb2YodmljdGltX3Rv
X2lfdCkpOwo+IAo+IERvIG5vdCBjYXN0IHRoZSByZXR1cm4gdmFsdWUgZnJvbSBtYWxsb2MgZXQg
YWwuCj4gCj4gPiArICAgICAgICAgICAgICAgIGkgPSBwYWdlX291dF9pbmRleFtyZXEuZ2ZuXS5p
bmRleCA7Cj4gCj4gVGhlIHNwYWNlIGJlZm9yZSB0aGUgc2VtaWNvbG9uIGlzIG5vdCB0aGUgY29u
dmVudGlvbmFsIHN0eWxlLgo+IAo+ID4gKyAgICAgICAgICAgICAgICAgICAgaWYoIHZpY3RpbXNb
aV0uZ2ZuICE9SU5WQUxJRF9NRk4gKQo+IAo+ID4gLSAgICBmcmVlKHZpY3RpbXMpOwo+ID4gKyAg
ICBpZiAoIE5VTEwgIT0gdmljdGltcyApCj4gPiArICAgIHsKPiA+ICsgICAgICAgIGZyZWUodmlj
dGltcyk7Cj4gPiArICAgIH0KPiAKPiBUaGlzIGlzIHNpbXBseSBwb2ludGxlc3MuICBmcmVlKE5V
TEwpIGlzIGxlZ2FsLgoKSSBzZWUuLi4KCj4gCj4gPiArdHlwZWRlZiBzdHJ1Y3QgdmljdGltX3Rv
X2kgewo+ID4gKyAgICAvKiB0aGUgaW5kZXggb2YgdmljdGltIGFycmF5IHRvIHJlYWQgZnJvbSAq
Lwo+ID4gKyAgICBpbnQgaW5kZXg7Cj4gPiArfSB2aWN0aW1fdG9faV90Owo+IAo+IFdoeSB3cmFw
IHRoaXMgdXAgaW4gYSBzdHJ1Y3QgPwoKV2Ugd2FudCB0byBrZWVwIHRoZSBzYW1lIHN0eWxlIHdp
dGgKCnR5cGVkZWYgc3RydWN0IHhlbnBhZ2luZ192aWN0aW0gewogICAgLyogdGhlIGdmbiBvZiB0
aGUgcGFnZSB0byBldmljdCAqLwogICAgdW5zaWduZWQgbG9uZyBnZm47Cn0geGVucGFnaW5nX3Zp
Y3RpbV90OwoKPiAKPiBVc2Ugb2YgdHlwZXMgd2l0aCBuYW1lcyBlbmRpbmcgaW4gX3QgaXMgcmVz
ZXJ2ZWQgdG8gdGhlIEMKPiBpbXBsZW1lbnRhdGlvbiAoY29tcGlsZXIgYW5kIHJ1bnRpbWUpLiAg
SSBrbm93IHhlbnBhZ2luZyBpcyBmdWxsIG9mCj4gdGhlc2UgYnV0IHdlIHNob3VsZG4ndCBpbnRy
b2R1Y2UgYW55IG1vcmUuCj4gCj4gSWFuLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Jan 06 05:32:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 05:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj2Oi-0004j5-VN; Fri, 06 Jan 2012 05:31: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 1Rj2Oh-0004j0-Gk
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 05:31:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325827837!49132115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2388 invoked from network); 6 Jan 2012 05:30:38 -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;
	6 Jan 2012 05:30:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,466,1320624000"; 
   d="scan'208";a="9857589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 05:31: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, 6 Jan 2012 05:31: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 1Rj2Of-0005vh-TI;
	Fri, 06 Jan 2012 05:31:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rj2Of-0007yu-Ib;
	Fri, 06 Jan 2012 05:31:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10641-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Jan 2012 05:31:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10641: 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 10641 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10641/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  4086e4811547

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Fri Jan 06 05:32:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 05:32:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj2Oi-0004j5-VN; Fri, 06 Jan 2012 05:31: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 1Rj2Oh-0004j0-Gk
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 05:31:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325827837!49132115!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2388 invoked from network); 6 Jan 2012 05:30:38 -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;
	6 Jan 2012 05:30:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,466,1320624000"; 
   d="scan'208";a="9857589"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 05:31: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, 6 Jan 2012 05:31: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 1Rj2Of-0005vh-TI;
	Fri, 06 Jan 2012 05:31:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rj2Of-0007yu-Ib;
	Fri, 06 Jan 2012 05:31:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10641-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 6 Jan 2012 05:31:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10641: 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 10641 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10641/

Failures :-/ but no regressions.

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

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  4086e4811547

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Fri Jan 06 05:38:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 05: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 1Rj2VR-0004rv-R4; Fri, 06 Jan 2012 05:38:21 +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 1Rj2VR-0004rn-4T
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 05:38:21 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1325828294!9862065!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNTUxOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 6 Jan 2012 05:38:14 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-14.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 05:38:14 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 05 Jan 2012 21:38:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="104090725"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 05 Jan 2012 21:38:12 -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, 6 Jan 2012 13:37:50 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 6 Jan 2012 13:37:49 +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; Fri, 6 Jan 2012 13:37:48 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>, Konrad Rzeszutek Wilk
	<konrad@darnok.org>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4AACb/RMA==
Date: Fri, 6 Jan 2012 05:37:47 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "'Konrad
	Rzeszutek Wilk \(konrad.wilk@oracle.com\)'" <konrad.wilk@oracle.com>
Subject: Re: [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

> From: Tian, Kevin
> Sent: Friday, January 06, 2012 8:58 AM
> 
> > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > Sent: Wednesday, January 04, 2012 12:59 AM
> >
> > On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote:
> > > Hi, Konrad
> >
> > Hey!
> >
> > Sorry for taking so long to respond. Holidays.
> 
> good season for relax. :-)
> 
> > >
> > > wiki page
> >
> (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a9004971
> > 6207b9c672fd78187b0c77767be0)
> > > 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 hadn't seen it... but then my main desktop box where I run intensive
> > tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
> > The box that has i915 just does some simple framebuffer manipulation and
> > that looks OK.
> 
> yes, framebuffer console works well in my side too.
> 
> >
> > >
> > > 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... :-)
> >
> > Do you see the same symptoms - checkboard screen?
> 
> Not exactly. The screen becomes white, and then the system becomes
> unstable and hang several minutes later. It's possible that mine is a
> different issue than listed on the wiki page, since many reasons may
> finally reach the same symptom - GPU hang... :/

well, there happens once with a checkboard screen, with the rest all
white screens.

> 
> >
> > The LKML had some fixes for this from Keith Packard. Something about
> > using i915.semaphores=0 I think. And I thought I saw some fixes for
> > 3.2-rc7 for this but not sure..
> 
> I'll have a try on latest Linux on this. But I suspect that this may be a
> virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case),
> because same dom0 image could run glxgear smoothly on bare metal.
> 

I used latest 3.2 release, no difference.

i915.semaphores=0 has no effect.

But I observed below warnings in the boot process:
[    8.872430] [drm] MTRR allocation failed.  Graphics performance may suffer.
[   18.384552] microcode: CPU0 update to revision 0x1b failed

Not sure whether above two issues may have impact on the said problem. 
I know microcode update is still missing in upstream, but not sure about any
MTRR specific pending patches.

Thanks
Kevin

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 05:38:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 05: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 1Rj2VR-0004rv-R4; Fri, 06 Jan 2012 05:38:21 +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 1Rj2VR-0004rn-4T
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 05:38:21 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1325828294!9862065!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNTUxOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18419 invoked from network); 6 Jan 2012 05:38:14 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-14.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 05:38:14 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 05 Jan 2012 21:38:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="104090725"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by fmsmga001.fm.intel.com with ESMTP; 05 Jan 2012 21:38:12 -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, 6 Jan 2012 13:37:50 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 6 Jan 2012 13:37:49 +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; Fri, 6 Jan 2012 13:37:48 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>, Konrad Rzeszutek Wilk
	<konrad@darnok.org>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4AACb/RMA==
Date: Fri, 6 Jan 2012 05:37:47 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "'Konrad
	Rzeszutek Wilk \(konrad.wilk@oracle.com\)'" <konrad.wilk@oracle.com>
Subject: Re: [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

> From: Tian, Kevin
> Sent: Friday, January 06, 2012 8:58 AM
> 
> > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > Sent: Wednesday, January 04, 2012 12:59 AM
> >
> > On Tue, Dec 27, 2011 at 06:47:44AM +0000, Tian, Kevin wrote:
> > > Hi, Konrad
> >
> > Hey!
> >
> > Sorry for taking so long to respond. Holidays.
> 
> good season for relax. :-)
> 
> > >
> > > wiki page
> >
> (http://wiki.xensource.com/xenwiki/XenPVOPSDRM.html#head-4da1a9004971
> > 6207b9c672fd78187b0c77767be0)
> > > 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 hadn't seen it... but then my main desktop box where I run intensive
> > tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
> > The box that has i915 just does some simple framebuffer manipulation and
> > that looks OK.
> 
> yes, framebuffer console works well in my side too.
> 
> >
> > >
> > > 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... :-)
> >
> > Do you see the same symptoms - checkboard screen?
> 
> Not exactly. The screen becomes white, and then the system becomes
> unstable and hang several minutes later. It's possible that mine is a
> different issue than listed on the wiki page, since many reasons may
> finally reach the same symptom - GPU hang... :/

well, there happens once with a checkboard screen, with the rest all
white screens.

> 
> >
> > The LKML had some fixes for this from Keith Packard. Something about
> > using i915.semaphores=0 I think. And I thought I saw some fixes for
> > 3.2-rc7 for this but not sure..
> 
> I'll have a try on latest Linux on this. But I suspect that this may be a
> virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case),
> because same dom0 image could run glxgear smoothly on bare metal.
> 

I used latest 3.2 release, no difference.

i915.semaphores=0 has no effect.

But I observed below warnings in the boot process:
[    8.872430] [drm] MTRR allocation failed.  Graphics performance may suffer.
[   18.384552] microcode: CPU0 update to revision 0x1b failed

Not sure whether above two issues may have impact on the said problem. 
I know microcode update is still missing in upstream, but not sure about any
MTRR specific pending patches.

Thanks
Kevin

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 06:06:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 06:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj2wb-0005DZ-EU; Fri, 06 Jan 2012 06:06:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1Rj2wa-0005DU-4T
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 06:06:24 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325829976!9338351!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTQ3Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25149 invoked from network); 6 Jan 2012 06:06:16 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-14.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 06:06:16 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXD002V34VYSN@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:04:47 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXD004DP4VUVU@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:04:46 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG26170; Fri,
	06 Jan 2012 14:04:46 +0800
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152)
	by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 14:04:43 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml413-hub.china.huawei.com ([10.82.67.152])
	with mapi id 14.01.0323.003; Fri, 06 Jan 2012 14:04:25 +0800
Date: Fri, 06 Jan 2012 06:04:25 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
X-Originating-IP: [10.166.82.189]
To: Liuyongan <liuyongan@huawei.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"keir@xen.org" <keir@xen.org>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DJX+VQ9Q
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: AUaO A5zL Drqh ESIp Hrjy IdTm ImOW LCWj OLIH RVgo Xiaf YQrf
	cU9f cgUF hTIA hnP8; 3;
	YQBuAGQAcgBlAHcALgBjAG8AbwBwAGUAcgAzAEAAYwBpAHQAcgBpAHgALgBjAG8AbQA7AGsAZQBpAHIAQAB4AGUAbgAuAG8AcgBnADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {0430DB8C-97C2-42A9-B3C5-7E5DE5B43AA2};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Fri,
	06 Jan 2012 06:04:19 GMT;
	UgBFADoAIABbAHgAZQBuAC0AZABlAHYAZQBsAF0AIABjAHIAZQBhAHQAZQAgAGkAcgBxACAAZgBhAGkAbABlAGQAIABkAHUAZQAgAHQAbwAgAG0AbwB2AGUAXwBjAGwAZQBhAG4AdQBwAF8AYwBvAHUAbgB0ACAAYQBsAHcAYQB5AHMAIABiAGUAaQBuAGcAIABzAGUAdAA=
x-cr-puzzleid: {0430DB8C-97C2-42A9-B3C5-7E5DE5B43AA2}
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
Cc: Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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

   As only 33 domains were successfully created(and destroyed) before the problem occurring,  there should be enough free IRQ  number and vector number to allocate(suppose that irqs and vectors failed to deallocate). And destroy_irq() will clear move_in_progress, so move_cleanup_count must be setted?  Is this the case? 

   Yong an
> -----Original Message-----
> From: Liuyongan
> Sent: Thursday, January 05, 2012 2:14 PM
> To: Liuyongan; xen-devel@lists.xensource.com;
> andrew.cooper3@citrix.com; keir@xen.org
> Cc: Qianhuibin
> Subject: RE: [xen-devel] create irq failed due to move_cleanup_count
> always being set
> 
> > On 04/01/12 11:38, Andrew Cooper wrote:
> >> On 04/01/12 04:37, Liuyongan wrote:
> >> Hi, all
> >>
> >>     I'm using xen-4.0 to do a test. And when I create a domain, it
> failed due to create_irq() failure. As only 33 domains were
> successfully created and destroyed before I got the continuous
> failures, and the domain just before the failure was properly
> destroyed(at least destroy_irq() was properly called, which will clear
> move_in_progress, according to the prink-message). So I can conclude
> for certain that __assign_irq_vector failed due to move_cleanup_count
> always being set.
> > Is it always 33 domains it takes to cause the problem, or does it
> vary?
> > If it varies, then I think you want this patch
> > http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
> which
> > corrects the logic which works out which moved vectors it should
> clean
> > up.  Without it, stale irq numbers build up in the per-cpu irq_vector
> > tables leading to __assign_irq_vector failing with -ENOSPC as it find
> > find a vector to allocate.
> 
>   Yes, I've noticed this patch, as only 33 domains were created before
> the failures, so vectors of a given cpu should not have been used up.
> Besides, I got this problem after 143 domains were created another
> time. But I could not repeat this problem manually as 4000+ domains
> created successfully without this problem.
> 
> >
> >> //this is the normal case when create and destroy domain whose id is
> 31;
> >> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> >> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> >> (XEN) irq.c:223, destroy irq 77
> >>
> >> //domain id 32 is created and destroyed correctly also.
> >> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> >> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> >> (XEN) irq.c:223, destroy irq 77
> >>
> >> //all the subsequent domain creation failed, below lists only 3
> times:
> >> (XEN) physdev.c:88: dom33: can't create irq for msi!
> >> (XEN) physdev.c:88: dom34: can't create irq for msi!
> >> (XEN) physdev.c:88: dom35: can't create irq for msi!
> >>
> >>      I think this might be a bug and might have fixed, so I compare
> my code with 4.1.2 and search the mail list for potential patches.
> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which
> add locks in __assign_irq_vector. Can anybody explain why this lock is
> needed? Or is there a patch that might fix my bug? Thx.
> > This patch fixes a problem where IOAPIC line level interrupts cease
> for
> > a while.  It has nothing to do with MSI interrupts.  (Also, there are
> no
> > locks altered, and xen-4.0-testing seems to have gained an additional
> > hunk in hvm/vmx code unrelated to the original patch.)
> >
> >>     Addition message: my board is arch-x86, no domains left when
> failed to create new ones, create_irq failure lasted one day until I
> reboot the board, and the irq number allocated is used certainly for a
> msi dev.
> >>
> >> Yong an Liu
> >> 2012.1.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 Jan 06 06:06:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 06:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj2wb-0005DZ-EU; Fri, 06 Jan 2012 06:06:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1Rj2wa-0005DU-4T
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 06:06:24 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325829976!9338351!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTQ3Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25149 invoked from network); 6 Jan 2012 06:06:16 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-14.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 06:06:16 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXD002V34VYSN@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:04:47 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXD004DP4VUVU@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:04:46 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG26170; Fri,
	06 Jan 2012 14:04:46 +0800
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152)
	by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 14:04:43 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml413-hub.china.huawei.com ([10.82.67.152])
	with mapi id 14.01.0323.003; Fri, 06 Jan 2012 14:04:25 +0800
Date: Fri, 06 Jan 2012 06:04:25 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
X-Originating-IP: [10.166.82.189]
To: Liuyongan <liuyongan@huawei.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
	"keir@xen.org" <keir@xen.org>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DJX+VQ9Q
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: AUaO A5zL Drqh ESIp Hrjy IdTm ImOW LCWj OLIH RVgo Xiaf YQrf
	cU9f cgUF hTIA hnP8; 3;
	YQBuAGQAcgBlAHcALgBjAG8AbwBwAGUAcgAzAEAAYwBpAHQAcgBpAHgALgBjAG8AbQA7AGsAZQBpAHIAQAB4AGUAbgAuAG8AcgBnADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {0430DB8C-97C2-42A9-B3C5-7E5DE5B43AA2};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Fri,
	06 Jan 2012 06:04:19 GMT;
	UgBFADoAIABbAHgAZQBuAC0AZABlAHYAZQBsAF0AIABjAHIAZQBhAHQAZQAgAGkAcgBxACAAZgBhAGkAbABlAGQAIABkAHUAZQAgAHQAbwAgAG0AbwB2AGUAXwBjAGwAZQBhAG4AdQBwAF8AYwBvAHUAbgB0ACAAYQBsAHcAYQB5AHMAIABiAGUAaQBuAGcAIABzAGUAdAA=
x-cr-puzzleid: {0430DB8C-97C2-42A9-B3C5-7E5DE5B43AA2}
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
Cc: Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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

   As only 33 domains were successfully created(and destroyed) before the problem occurring,  there should be enough free IRQ  number and vector number to allocate(suppose that irqs and vectors failed to deallocate). And destroy_irq() will clear move_in_progress, so move_cleanup_count must be setted?  Is this the case? 

   Yong an
> -----Original Message-----
> From: Liuyongan
> Sent: Thursday, January 05, 2012 2:14 PM
> To: Liuyongan; xen-devel@lists.xensource.com;
> andrew.cooper3@citrix.com; keir@xen.org
> Cc: Qianhuibin
> Subject: RE: [xen-devel] create irq failed due to move_cleanup_count
> always being set
> 
> > On 04/01/12 11:38, Andrew Cooper wrote:
> >> On 04/01/12 04:37, Liuyongan wrote:
> >> Hi, all
> >>
> >>     I'm using xen-4.0 to do a test. And when I create a domain, it
> failed due to create_irq() failure. As only 33 domains were
> successfully created and destroyed before I got the continuous
> failures, and the domain just before the failure was properly
> destroyed(at least destroy_irq() was properly called, which will clear
> move_in_progress, according to the prink-message). So I can conclude
> for certain that __assign_irq_vector failed due to move_cleanup_count
> always being set.
> > Is it always 33 domains it takes to cause the problem, or does it
> vary?
> > If it varies, then I think you want this patch
> > http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
> which
> > corrects the logic which works out which moved vectors it should
> clean
> > up.  Without it, stale irq numbers build up in the per-cpu irq_vector
> > tables leading to __assign_irq_vector failing with -ENOSPC as it find
> > find a vector to allocate.
> 
>   Yes, I've noticed this patch, as only 33 domains were created before
> the failures, so vectors of a given cpu should not have been used up.
> Besides, I got this problem after 143 domains were created another
> time. But I could not repeat this problem manually as 4000+ domains
> created successfully without this problem.
> 
> >
> >> //this is the normal case when create and destroy domain whose id is
> 31;
> >> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> >> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> >> (XEN) irq.c:223, destroy irq 77
> >>
> >> //domain id 32 is created and destroyed correctly also.
> >> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> >> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> >> (XEN) irq.c:223, destroy irq 77
> >>
> >> //all the subsequent domain creation failed, below lists only 3
> times:
> >> (XEN) physdev.c:88: dom33: can't create irq for msi!
> >> (XEN) physdev.c:88: dom34: can't create irq for msi!
> >> (XEN) physdev.c:88: dom35: can't create irq for msi!
> >>
> >>      I think this might be a bug and might have fixed, so I compare
> my code with 4.1.2 and search the mail list for potential patches.
> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which
> add locks in __assign_irq_vector. Can anybody explain why this lock is
> needed? Or is there a patch that might fix my bug? Thx.
> > This patch fixes a problem where IOAPIC line level interrupts cease
> for
> > a while.  It has nothing to do with MSI interrupts.  (Also, there are
> no
> > locks altered, and xen-4.0-testing seems to have gained an additional
> > hunk in hvm/vmx code unrelated to the original patch.)
> >
> >>     Addition message: my board is arch-x86, no domains left when
> failed to create new ones, create_irq failure lasted one day until I
> reboot the board, and the irq number allocated is used certainly for a
> msi dev.
> >>
> >> Yong an Liu
> >> 2012.1.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 Jan 06 07:45:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 07:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj4Te-0005jA-2M; Fri, 06 Jan 2012 07:44:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1Rj4Tc-0005j5-Ge
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 07:44:36 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325835853!51731674!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwODk4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1776 invoked from network); 6 Jan 2012 07:44:14 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 07:44:14 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 05 Jan 2012 23:44:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="53837423"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 05 Jan 2012 23:44:32 -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, 6 Jan 2012 15:44:28 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 6 Jan 2012 15:44: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, 6 Jan 2012 15:44:26 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] tools: fix ipxe version issue in Makefile
Thread-Index: AczMRwG0/KHzXywMRnO7sDrHQC4Rrw==
Date: Fri, 6 Jan 2012 07:44:26 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@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="_004_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_
Content-Type: multipart/alternative;
	boundary="_000_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_"

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

Hi All,
The ipxe git commit version changed, but its release version should still s=
tay at v1.0.0

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com<mailto:yongjie.ren@intel.=
com>>
------

diff -r 4086e4811547 tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile Thu Jan 05 17:25:23 2012 +0000
+++ b/tools/firmware/etherboot/Makefile Fri Jan 06 14:30:54 2012 +0800
@@ -12,7 +12,9 @@

IPXE_GIT_TAG :=3D 9a93db3f0947484e30e753bbd61a10b17336e20e

-IPXE_TARBALL_URL :=3D $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
+IPXE_VERSION :=3D v1.0.0
+
+IPXE_TARBALL_URL :=3D $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_VERSION).tar.gz

D=3Dipxe
T=3Dipxe.tar.gz

Best Regards,
     Yongjie Ren  (Jay)


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family: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:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Hi All,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The ipxe git commit version cha=
nged, but its release version should still stay at v1.0.0<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Signed-off-by: Yongjie Ren &lt;=
<a href=3D"mailto:yongjie.ren@intel.com">yongjie.ren@intel.com</a>&gt;<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">------<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">diff -r 4086e4811547 tools/firm=
ware/etherboot/Makefile<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">--- a/tools/firmware/etherboot/=
Makefile Thu Jan 05 17:25:23 2012 &#43;0000<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&#43;&#43;&#43; b/tools/firmwar=
e/etherboot/Makefile Fri Jan 06 14:30:54 2012 &#43;0800<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">@@ -12,7 &#43;12,9 @@<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">IPXE_GIT_TAG :=3D 9a93db3f09474=
84e30e753bbd61a10b17336e20e<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">-IPXE_TARBALL_URL :=3D $(XEN_EX=
TFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&#43;IPXE_VERSION :=3D v1.0.0<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&#43;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&#43;IPXE_TARBALL_URL :=3D $(XE=
N_EXTFILES_URL)/ipxe-git-$(IPXE_VERSION).tar.gz<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">D=3Dipxe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">T=3Dipxe.tar.gz<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Best Regards,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp; Yongji=
e Ren&nbsp; (Jay)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_--

--_004_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="ipxe-version.patch"
Content-Description: ipxe-version.patch
Content-Disposition: attachment; filename="ipxe-version.patch"; size=471;
	creation-date="Fri, 06 Jan 2012 07:38:32 GMT";
	modification-date="Fri, 06 Jan 2012 07:37:35 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciA0MDg2ZTQ4MTE1NDcgdG9vbHMvZmlybXdhcmUvZXRoZXJib290L01ha2VmaWxlCi0t
LSBhL3Rvb2xzL2Zpcm13YXJlL2V0aGVyYm9vdC9NYWtlZmlsZSBUaHUgSmFuIDA1IDE3OjI1OjIz
IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvZmlybXdhcmUvZXRoZXJib290L01ha2VmaWxlIEZyaSBK
YW4gMDYgMTQ6MzA6NTQgMjAxMiArMDgwMApAQCAtMTIsNyArMTIsOSBAQAoKIElQWEVfR0lUX1RB
RyA6PSA5YTkzZGIzZjA5NDc0ODRlMzBlNzUzYmJkNjFhMTBiMTczMzZlMjBlCgotSVBYRV9UQVJC
QUxMX1VSTCA6PSAkKFhFTl9FWFRGSUxFU19VUkwpL2lweGUtZ2l0LSQoSVBYRV9HSVRfVEFHKS50
YXIuZ3oKK0lQWEVfVkVSU0lPTiA6PSB2MS4wLjAKKworSVBYRV9UQVJCQUxMX1VSTCA6PSAkKFhF
Tl9FWFRGSUxFU19VUkwpL2lweGUtZ2l0LSQoSVBYRV9WRVJTSU9OKS50YXIuZ3oKCiBEPWlweGUK
IFQ9aXB4ZS50YXIuZ3oK

--_004_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 07:45:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 07:45:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj4Te-0005jA-2M; Fri, 06 Jan 2012 07:44:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1Rj4Tc-0005j5-Ge
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 07:44:36 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325835853!51731674!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIwODk4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1776 invoked from network); 6 Jan 2012 07:44:14 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-11.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 07:44:14 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 05 Jan 2012 23:44:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="53837423"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 05 Jan 2012 23:44:32 -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, 6 Jan 2012 15:44:28 +0800
Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by
	PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Fri, 6 Jan 2012 15:44: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, 6 Jan 2012 15:44:26 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] tools: fix ipxe version issue in Makefile
Thread-Index: AczMRwG0/KHzXywMRnO7sDrHQC4Rrw==
Date: Fri, 6 Jan 2012 07:44:26 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@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="_004_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_"
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_
Content-Type: multipart/alternative;
	boundary="_000_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_"

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

Hi All,
The ipxe git commit version changed, but its release version should still s=
tay at v1.0.0

Signed-off-by: Yongjie Ren <yongjie.ren@intel.com<mailto:yongjie.ren@intel.=
com>>
------

diff -r 4086e4811547 tools/firmware/etherboot/Makefile
--- a/tools/firmware/etherboot/Makefile Thu Jan 05 17:25:23 2012 +0000
+++ b/tools/firmware/etherboot/Makefile Fri Jan 06 14:30:54 2012 +0800
@@ -12,7 +12,9 @@

IPXE_GIT_TAG :=3D 9a93db3f0947484e30e753bbd61a10b17336e20e

-IPXE_TARBALL_URL :=3D $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
+IPXE_VERSION :=3D v1.0.0
+
+IPXE_TARBALL_URL :=3D $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_VERSION).tar.gz

D=3Dipxe
T=3Dipxe.tar.gz

Best Regards,
     Yongjie Ren  (Jay)


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family: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:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
/* Page Definitions */
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t=
rim:punctuation">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Hi All,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The ipxe git commit version cha=
nged, but its release version should still stay at v1.0.0<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Signed-off-by: Yongjie Ren &lt;=
<a href=3D"mailto:yongjie.ren@intel.com">yongjie.ren@intel.com</a>&gt;<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">------<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">diff -r 4086e4811547 tools/firm=
ware/etherboot/Makefile<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">--- a/tools/firmware/etherboot/=
Makefile Thu Jan 05 17:25:23 2012 &#43;0000<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&#43;&#43;&#43; b/tools/firmwar=
e/etherboot/Makefile Fri Jan 06 14:30:54 2012 &#43;0800<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">@@ -12,7 &#43;12,9 @@<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">IPXE_GIT_TAG :=3D 9a93db3f09474=
84e30e753bbd61a10b17336e20e<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">-IPXE_TARBALL_URL :=3D $(XEN_EX=
TFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&#43;IPXE_VERSION :=3D v1.0.0<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&#43;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&#43;IPXE_TARBALL_URL :=3D $(XE=
N_EXTFILES_URL)/ipxe-git-$(IPXE_VERSION).tar.gz<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">D=3Dipxe<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">T=3Dipxe.tar.gz<o:p></o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Best Regards,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp; Yongji=
e Ren&nbsp; (Jay)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_--

--_004_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_
Content-Type: application/octet-stream; name="ipxe-version.patch"
Content-Description: ipxe-version.patch
Content-Disposition: attachment; filename="ipxe-version.patch"; size=471;
	creation-date="Fri, 06 Jan 2012 07:38:32 GMT";
	modification-date="Fri, 06 Jan 2012 07:37:35 GMT"
Content-Transfer-Encoding: base64

ZGlmZiAtciA0MDg2ZTQ4MTE1NDcgdG9vbHMvZmlybXdhcmUvZXRoZXJib290L01ha2VmaWxlCi0t
LSBhL3Rvb2xzL2Zpcm13YXJlL2V0aGVyYm9vdC9NYWtlZmlsZSBUaHUgSmFuIDA1IDE3OjI1OjIz
IDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvZmlybXdhcmUvZXRoZXJib290L01ha2VmaWxlIEZyaSBK
YW4gMDYgMTQ6MzA6NTQgMjAxMiArMDgwMApAQCAtMTIsNyArMTIsOSBAQAoKIElQWEVfR0lUX1RB
RyA6PSA5YTkzZGIzZjA5NDc0ODRlMzBlNzUzYmJkNjFhMTBiMTczMzZlMjBlCgotSVBYRV9UQVJC
QUxMX1VSTCA6PSAkKFhFTl9FWFRGSUxFU19VUkwpL2lweGUtZ2l0LSQoSVBYRV9HSVRfVEFHKS50
YXIuZ3oKK0lQWEVfVkVSU0lPTiA6PSB2MS4wLjAKKworSVBYRV9UQVJCQUxMX1VSTCA6PSAkKFhF
Tl9FWFRGSUxFU19VUkwpL2lweGUtZ2l0LSQoSVBYRV9WRVJTSU9OKS50YXIuZ3oKCiBEPWlweGUK
IFQ9aXB4ZS50YXIuZ3oK

--_004_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_1B4B44D9196EFF41AE41FDA404FC0A1001197CSHSMSX101ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:46:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5RK-00074h-CE; Fri, 06 Jan 2012 08:46: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 1Rj5RI-00074Z-45
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:46:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325839569!7825110!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26894 invoked from network); 6 Jan 2012 08:46:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 08:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9858868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 08:45: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, 6 Jan 2012
	08:45:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Fri, 6 Jan 2012 08:45:50 +0000
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325839550.25206.420.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] tools: fix ipxe version issue in Makefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 07:44 +0000, Ren, Yongjie wrote:
> Hi All,
> 
> The ipxe git commit version changed, but its release version should
> still stay at v1.0.0

Doesn't this effectively undo the change in 24455:94180a5a0c7c since the
$T rules first tries to wget $(IPXE_TARBALL_URL) before cloning the git
tree? Therefore with this change it is going to find and clone v1.0
instead of using the git tag.

> 
>  
> 
> Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> ------
> 
>  
> 
> diff -r 4086e4811547 tools/firmware/etherboot/Makefile
> 
> --- a/tools/firmware/etherboot/Makefile Thu Jan 05 17:25:23 2012 +0000
> 
> +++ b/tools/firmware/etherboot/Makefile Fri Jan 06 14:30:54 2012 +0800
> 
> @@ -12,7 +12,9 @@
> 
>  
> 
> IPXE_GIT_TAG := 9a93db3f0947484e30e753bbd61a10b17336e20e
> 
>  
> 
> -IPXE_TARBALL_URL :=
> $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
> 
> +IPXE_VERSION := v1.0.0
> 
> +
> 
> +IPXE_TARBALL_URL :=
> $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_VERSION).tar.gz
> 
>  
> 
> D=ipxe
> 
> T=ipxe.tar.gz
> 
>  
> 
> Best Regards,
> 
>      Yongjie Ren  (Jay)
> 
>  
> 
> 



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:46:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5RK-00074h-CE; Fri, 06 Jan 2012 08:46: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 1Rj5RI-00074Z-45
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:46:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1325839569!7825110!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26894 invoked from network); 6 Jan 2012 08:46:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 08:46:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9858868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 08:45: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, 6 Jan 2012
	08:45:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Ren, Yongjie" <yongjie.ren@intel.com>
Date: Fri, 6 Jan 2012 08:45:50 +0000
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@SHSMSX101.ccr.corp.intel.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325839550.25206.420.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] tools: fix ipxe version issue in Makefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 07:44 +0000, Ren, Yongjie wrote:
> Hi All,
> 
> The ipxe git commit version changed, but its release version should
> still stay at v1.0.0

Doesn't this effectively undo the change in 24455:94180a5a0c7c since the
$T rules first tries to wget $(IPXE_TARBALL_URL) before cloning the git
tree? Therefore with this change it is going to find and clone v1.0
instead of using the git tag.

> 
>  
> 
> Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
> 
> ------
> 
>  
> 
> diff -r 4086e4811547 tools/firmware/etherboot/Makefile
> 
> --- a/tools/firmware/etherboot/Makefile Thu Jan 05 17:25:23 2012 +0000
> 
> +++ b/tools/firmware/etherboot/Makefile Fri Jan 06 14:30:54 2012 +0800
> 
> @@ -12,7 +12,9 @@
> 
>  
> 
> IPXE_GIT_TAG := 9a93db3f0947484e30e753bbd61a10b17336e20e
> 
>  
> 
> -IPXE_TARBALL_URL :=
> $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
> 
> +IPXE_VERSION := v1.0.0
> 
> +
> 
> +IPXE_TARBALL_URL :=
> $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_VERSION).tar.gz
> 
>  
> 
> D=ipxe
> 
> T=ipxe.tar.gz
> 
>  
> 
> Best Regards,
> 
>      Yongjie Ren  (Jay)
> 
>  
> 
> 



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5c7-0007HS-VP; Fri, 06 Jan 2012 08:57:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c6-0007Gj-OB
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:26 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325840239!2490499!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17962 invoked from network); 6 Jan 2012 08:57:20 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 08:57:20 -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 q068vIPj020595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:19 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQL022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:18 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:07 +0100
Message-Id: <1325840229-3420-3-git-send-email-drjones@redhat.com>
In-Reply-To: <1325840229-3420-1-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..269b299 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
 	select FB_SYS_IMAGEBLIT
 	select FB_SYS_FOPS
 	select FB_DEFERRED_IO
+	select INPUT_XEN_KBDDEV_FRONTEND
 	select XEN_XENBUS_FRONTEND
 	default y
 	help
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5c7-0007HS-VP; Fri, 06 Jan 2012 08:57:27 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c6-0007Gj-OB
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:26 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325840239!2490499!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17962 invoked from network); 6 Jan 2012 08:57:20 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 08:57:20 -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 q068vIPj020595
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:19 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQL022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:18 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:07 +0100
Message-Id: <1325840229-3420-3-git-send-email-drjones@redhat.com>
In-Reply-To: <1325840229-3420-1-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..269b299 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
 	select FB_SYS_IMAGEBLIT
 	select FB_SYS_FOPS
 	select FB_DEFERRED_IO
+	select INPUT_XEN_KBDDEV_FRONTEND
 	select XEN_XENBUS_FRONTEND
 	default y
 	help
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5c3-0007Gq-Qw; Fri, 06 Jan 2012 08:57:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c2-0007Gk-1j
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:22 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325840195!49149595!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10308 invoked from network); 6 Jan 2012 08:56:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 08:56:36 -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 q068vJVG020603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:19 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQM022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:19 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:08 +0100
Message-Id: <1325840229-3420-4-git-send-email-drjones@redhat.com>
In-Reply-To: <1325840229-3420-1-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Describe dom0 support in the config menu and supply help text for it.
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..88862d5 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support"
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5c3-0007Gq-Qw; Fri, 06 Jan 2012 08:57:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c2-0007Gk-1j
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:22 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325840195!49149595!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10308 invoked from network); 6 Jan 2012 08:56:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 08:56:36 -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 q068vJVG020603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:19 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQM022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:19 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:08 +0100
Message-Id: <1325840229-3420-4-git-send-email-drjones@redhat.com>
In-Reply-To: <1325840229-3420-1-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Describe dom0 support in the config menu and supply help text for it.
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..88862d5 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support"
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5c6-0007H8-7A; Fri, 06 Jan 2012 08:57:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c3-0007Gh-Vf
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:24 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325840237!8038944!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2125 invoked from network); 6 Jan 2012 08:57:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 08:57:17 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q068vGMM007761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:17 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQJ022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:16 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:05 +0100
Message-Id: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 0/4] xen kconfig tweaks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series is a collection of xen kconfig fixes and additions.

Andrew Jones (4):
  xen kconfig: keep XEN_XENBUS_FRONTEND builtin
  xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
  xen kconfig: add dom0 support help text
  xen kconfig: describe xen tmem in the config menu

 arch/x86/xen/Kconfig       |    7 ++++++-
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 drivers/xen/Kconfig        |    4 ++--
 4 files changed, 10 insertions(+), 4 deletions(-)

-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:57:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5c6-0007H8-7A; Fri, 06 Jan 2012 08:57:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c3-0007Gh-Vf
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:24 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1325840237!8038944!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2125 invoked from network); 6 Jan 2012 08:57:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 08:57:17 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q068vGMM007761
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:17 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQJ022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:16 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:05 +0100
Message-Id: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 0/4] xen kconfig tweaks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series is a collection of xen kconfig fixes and additions.

Andrew Jones (4):
  xen kconfig: keep XEN_XENBUS_FRONTEND builtin
  xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
  xen kconfig: add dom0 support help text
  xen kconfig: describe xen tmem in the config menu

 arch/x86/xen/Kconfig       |    7 ++++++-
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 drivers/xen/Kconfig        |    4 ++--
 4 files changed, 10 insertions(+), 4 deletions(-)

-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5c9-0007Hs-CP; Fri, 06 Jan 2012 08:57:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c7-0007Gp-Tq
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:28 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325840241!8591858!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11771 invoked from network); 6 Jan 2012 08:57:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 08:57:21 -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 q068vKk0030587
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:20 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQN022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:20 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:09 +0100
Message-Id: <1325840229-3420-5-git-send-email-drjones@redhat.com>
In-Reply-To: <1325840229-3420-1-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 description to the config menu for xen tmem.
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d24061..7e8d728 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -143,7 +143,7 @@ config SWIOTLB_XEN
 	select SWIOTLB
 
 config XEN_TMEM
-	bool
+	bool "Xen Transcendent Memory (tmem)"
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5c9-0007Hs-CP; Fri, 06 Jan 2012 08:57:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c7-0007Gp-Tq
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:28 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325840241!8591858!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11771 invoked from network); 6 Jan 2012 08:57:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 08:57:21 -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 q068vKk0030587
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:20 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQN022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:20 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:09 +0100
Message-Id: <1325840229-3420-5-git-send-email-drjones@redhat.com>
In-Reply-To: <1325840229-3420-1-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 description to the config menu for xen tmem.
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d24061..7e8d728 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -143,7 +143,7 @@ config SWIOTLB_XEN
 	select SWIOTLB
 
 config XEN_TMEM
-	bool
+	bool "Xen Transcendent Memory (tmem)"
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08: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 1Rj5c6-0007HG-J3; Fri, 06 Jan 2012 08:57:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c4-0007Gi-TE
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:25 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325840238!9862641!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18344 invoked from network); 6 Jan 2012 08:57:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 08:57:18 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q068vHV5030579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:17 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQK022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:17 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:06 +0100
Message-Id: <1325840229-3420-2-git-send-email-drjones@redhat.com>
In-Reply-To: <1325840229-3420-1-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..1d24061 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
 	 but will have no xen contents.
 
 config XEN_XENBUS_FRONTEND
-	tristate
+	bool
 
 config XEN_GNTDEV
 	tristate "userspace grant access device driver"
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 08:57:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 08: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 1Rj5c6-0007HG-J3; Fri, 06 Jan 2012 08:57:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj5c4-0007Gi-TE
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:57:25 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325840238!9862641!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18344 invoked from network); 6 Jan 2012 08:57:18 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 08:57:18 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q068vHV5030579
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:17 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q068vFQK022034
	for <xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 03:57:17 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 09:57:06 +0100
Message-Id: <1325840229-3420-2-git-send-email-drjones@redhat.com>
In-Reply-To: <1325840229-3420-1-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..1d24061 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
 	 but will have no xen contents.
 
 config XEN_XENBUS_FRONTEND
-	tristate
+	bool
 
 config XEN_GNTDEV
 	tristate "userspace grant access device driver"
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:21:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5zJ-00086I-Ls; Fri, 06 Jan 2012 09:21: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 1Rj5zI-00086D-Bj
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:21:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325841676!8056123!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17560 invoked from network); 6 Jan 2012 09:21:18 -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;
	6 Jan 2012 09:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9859413"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 09:20: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, 6 Jan 2012
	09:20:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Jones <drjones@redhat.com>
Date: Fri, 6 Jan 2012 09:20:53 +0000
In-Reply-To: <1325840229-3420-4-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
	<1325840229-3420-4-git-send-email-drjones@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325841653.25206.430.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/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> Describe dom0 support in the config menu and supply help text for it.

This turns a non-user visible symbol into a user visible one. Previously
if Xen was enabled and the other prerequisites were met you would get
dom0 support automatically -- do we really want to change that?
According to 6b0661a5e6fbf it was a deliberate decision to have it this
way.

BTW, you forgot a Signed-off-by and the appropriate CCs (please use
MAINTAINERS or ./scripts/get-maintainer.pl).

Ian.

> ---
>  arch/x86/xen/Kconfig |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..88862d5 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
>  	  Xen hypervisor.
>  
>  config XEN_DOM0
> -	def_bool y
> +	bool "Xen Initial Domain (Dom0) support"
> +	default y
>  	depends on XEN && PCI_XEN && SWIOTLB_XEN
>  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> +	help
> +	  This allows the kernel to be used for the initial Xen domain,
> +	  Domain0. This is a privileged guest that supplies backends
> +	  and is used to manage the other Xen domains.
>  
>  # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
>  # name in tools.



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:21:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj5zJ-00086I-Ls; Fri, 06 Jan 2012 09:21: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 1Rj5zI-00086D-Bj
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:21:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325841676!8056123!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17560 invoked from network); 6 Jan 2012 09:21:18 -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;
	6 Jan 2012 09:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9859413"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 09:20: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, 6 Jan 2012
	09:20:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Jones <drjones@redhat.com>
Date: Fri, 6 Jan 2012 09:20:53 +0000
In-Reply-To: <1325840229-3420-4-git-send-email-drjones@redhat.com>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
	<1325840229-3420-4-git-send-email-drjones@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325841653.25206.430.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/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> Describe dom0 support in the config menu and supply help text for it.

This turns a non-user visible symbol into a user visible one. Previously
if Xen was enabled and the other prerequisites were met you would get
dom0 support automatically -- do we really want to change that?
According to 6b0661a5e6fbf it was a deliberate decision to have it this
way.

BTW, you forgot a Signed-off-by and the appropriate CCs (please use
MAINTAINERS or ./scripts/get-maintainer.pl).

Ian.

> ---
>  arch/x86/xen/Kconfig |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..88862d5 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
>  	  Xen hypervisor.
>  
>  config XEN_DOM0
> -	def_bool y
> +	bool "Xen Initial Domain (Dom0) support"
> +	default y
>  	depends on XEN && PCI_XEN && SWIOTLB_XEN
>  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> +	help
> +	  This allows the kernel to be used for the initial Xen domain,
> +	  Domain0. This is a privileged guest that supplies backends
> +	  and is used to manage the other Xen domains.
>  
>  # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
>  # name in tools.



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:26:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09: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 1Rj63u-0008EO-Cn; Fri, 06 Jan 2012 09:26:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj63t-0008EC-88
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:26:09 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325841962!9754019!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzAyMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15017 invoked from network); 6 Jan 2012 09:26:03 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-15.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 09:26:03 -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 q069Q0ft021212;
	Fri, 6 Jan 2012 04:26:00 -0500
Date: Fri, 06 Jan 2012 04:26:00 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <5a67dfb3-fab0-4792-ba17-95f0934cf7af@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1325841653.25206.430.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > Describe dom0 support in the config menu and supply help text for
> > it.
> 
> This turns a non-user visible symbol into a user visible one.
> Previously
> if Xen was enabled and the other prerequisites were met you would get
> dom0 support automatically -- do we really want to change that?
> According to 6b0661a5e6fbf it was a deliberate decision to have it
> this
> way.

I think it's a necessary evil in order to give users the ability to
compile kernels without the support. I know it doesn't make much sense
for most users, but...

> 
> BTW, you forgot a Signed-off-by and the appropriate CCs (please use
> MAINTAINERS or ./scripts/get-maintainer.pl).
> 

Sorry, I'll resend properly.

Drew

> Ian.
> 
> > ---
> >  arch/x86/xen/Kconfig |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > index 26c731a..88862d5 100644
> > --- a/arch/x86/xen/Kconfig
> > +++ b/arch/x86/xen/Kconfig
> > @@ -14,9 +14,14 @@ config XEN
> >  	  Xen hypervisor.
> >  
> >  config XEN_DOM0
> > -	def_bool y
> > +	bool "Xen Initial Domain (Dom0) support"
> > +	default y
> >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > +	help
> > +	  This allows the kernel to be used for the initial Xen domain,
> > +	  Domain0. This is a privileged guest that supplies backends
> > +	  and is used to manage the other Xen domains.
> >  
> >  # Dummy symbol since people have come to rely on the
> >  PRIVILEGED_GUEST
> >  # name in tools.
> 
> 
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:26:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09: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 1Rj63u-0008EO-Cn; Fri, 06 Jan 2012 09:26:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj63t-0008EC-88
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:26:09 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325841962!9754019!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzAyMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15017 invoked from network); 6 Jan 2012 09:26:03 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-15.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 09:26:03 -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 q069Q0ft021212;
	Fri, 6 Jan 2012 04:26:00 -0500
Date: Fri, 06 Jan 2012 04:26:00 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <5a67dfb3-fab0-4792-ba17-95f0934cf7af@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1325841653.25206.430.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > Describe dom0 support in the config menu and supply help text for
> > it.
> 
> This turns a non-user visible symbol into a user visible one.
> Previously
> if Xen was enabled and the other prerequisites were met you would get
> dom0 support automatically -- do we really want to change that?
> According to 6b0661a5e6fbf it was a deliberate decision to have it
> this
> way.

I think it's a necessary evil in order to give users the ability to
compile kernels without the support. I know it doesn't make much sense
for most users, but...

> 
> BTW, you forgot a Signed-off-by and the appropriate CCs (please use
> MAINTAINERS or ./scripts/get-maintainer.pl).
> 

Sorry, I'll resend properly.

Drew

> Ian.
> 
> > ---
> >  arch/x86/xen/Kconfig |    7 ++++++-
> >  1 files changed, 6 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > index 26c731a..88862d5 100644
> > --- a/arch/x86/xen/Kconfig
> > +++ b/arch/x86/xen/Kconfig
> > @@ -14,9 +14,14 @@ config XEN
> >  	  Xen hypervisor.
> >  
> >  config XEN_DOM0
> > -	def_bool y
> > +	bool "Xen Initial Domain (Dom0) support"
> > +	default y
> >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > +	help
> > +	  This allows the kernel to be used for the initial Xen domain,
> > +	  Domain0. This is a privileged guest that supplies backends
> > +	  and is used to manage the other Xen domains.
> >  
> >  # Dummy symbol since people have come to rely on the
> >  PRIVILEGED_GUEST
> >  # name in tools.
> 
> 
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:35:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09: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 1Rj6Cl-0008Sd-DZ; Fri, 06 Jan 2012 09:35:19 +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 1Rj6Cj-0008SY-Vc
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:35:18 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325842511!8052348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14758 invoked from network); 6 Jan 2012 09:35:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 09:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9859645"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 09:35:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 6 Jan 2012
	09:35:10 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 09:35:13 +0000
Thread-Topic: [PATCH 0 of 4] Support for VM generation ID save/restore and
	migrate
Thread-Index: Acy8At8iUfFGRkKxQcWh8mrXI+GIMgQUyeWQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED1913@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@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 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

Ping? Patch 3 was integrated on Dec 18th but I don't see the rest as yet. Is there something more I need to do?

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 16 December 2011 14:55
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH 0 of 4] Support for VM generation ID save/restore
> and migrate
> 
> 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 Jan 06 09:35:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09: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 1Rj6Cl-0008Sd-DZ; Fri, 06 Jan 2012 09:35:19 +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 1Rj6Cj-0008SY-Vc
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:35:18 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325842511!8052348!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14758 invoked from network); 6 Jan 2012 09:35:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 09:35:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9859645"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 09:35:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Fri, 6 Jan 2012
	09:35:10 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 09:35:13 +0000
Thread-Topic: [PATCH 0 of 4] Support for VM generation ID save/restore and
	migrate
Thread-Index: Acy8At8iUfFGRkKxQcWh8mrXI+GIMgQUyeWQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED1913@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1324047273@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 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

Ping? Patch 3 was integrated on Dec 18th but I don't see the rest as yet. Is there something more I need to do?

  Paul

> -----Original Message-----
> From: Paul Durrant [mailto:paul.durrant@citrix.com]
> Sent: 16 December 2011 14:55
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant
> Subject: [PATCH 0 of 4] Support for VM generation ID save/restore
> and migrate
> 
> 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 Jan 06 09:43:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6Ke-0000B4-Bd; Fri, 06 Jan 2012 09:43:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kd-0000Av-CW
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:27 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1325843000!10491219!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15818 invoked from network); 6 Jan 2012 09:43:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 09:43:21 -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 q069hHG0030981
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:17 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hErX014467; Fri, 6 Jan 2012 04:43:15 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:07 +0100
Message-Id: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0/4] xen kconfig tweaks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series is a collection of xen kconfig fixes and additions.

Andrew Jones (4):
  xen kconfig: keep XEN_XENBUS_FRONTEND builtin
  xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
  xen kconfig: add dom0 support help text
  xen kconfig: describe xen tmem in the config menu

 arch/x86/xen/Kconfig       |    7 ++++++-
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 drivers/xen/Kconfig        |    4 ++--
 4 files changed, 10 insertions(+), 4 deletions(-)

-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6Ke-0000B4-Bd; Fri, 06 Jan 2012 09:43:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kd-0000Av-CW
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:27 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1325843000!10491219!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15818 invoked from network); 6 Jan 2012 09:43:21 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 09:43:21 -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 q069hHG0030981
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:17 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hErX014467; Fri, 6 Jan 2012 04:43:15 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:07 +0100
Message-Id: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 0/4] xen kconfig tweaks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This series is a collection of xen kconfig fixes and additions.

Andrew Jones (4):
  xen kconfig: keep XEN_XENBUS_FRONTEND builtin
  xen kconfig: relax INPUT_XEN_KBDDEV_FRONTEND deps
  xen kconfig: add dom0 support help text
  xen kconfig: describe xen tmem in the config menu

 arch/x86/xen/Kconfig       |    7 ++++++-
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 drivers/xen/Kconfig        |    4 ++--
 4 files changed, 10 insertions(+), 4 deletions(-)

-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6Kh-0000Bn-FY; Fri, 06 Jan 2012 09:43:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kf-0000Az-R0
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:30 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325842891!58614655!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29598 invoked from network); 6 Jan 2012 09:41:31 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 09:41:31 -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 q069hN08018170
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:23 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hErb014467; Fri, 6 Jan 2012 04:43:22 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:11 +0100
Message-Id: <1325842991-4404-5-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-1-git-send-email-drjones@redhat.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 description to the config menu for xen tmem.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d24061..7e8d728 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -143,7 +143,7 @@ config SWIOTLB_XEN
 	select SWIOTLB
 
 config XEN_TMEM
-	bool
+	bool "Xen Transcendent Memory (tmem)"
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6Kh-0000Bn-FY; Fri, 06 Jan 2012 09:43:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kf-0000Az-R0
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:30 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325842891!58614655!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29598 invoked from network); 6 Jan 2012 09:41:31 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 09:41:31 -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 q069hN08018170
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:23 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hErb014467; Fri, 6 Jan 2012 04:43:22 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:11 +0100
Message-Id: <1325842991-4404-5-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-1-git-send-email-drjones@redhat.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 description to the config menu for xen tmem.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d24061..7e8d728 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -143,7 +143,7 @@ config SWIOTLB_XEN
 	select SWIOTLB
 
 config XEN_TMEM
-	bool
+	bool "Xen Transcendent Memory (tmem)"
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6Ki-0000C8-1u; Fri, 06 Jan 2012 09:43:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kg-0000Ay-NM
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:30 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325843003!9798028!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18447 invoked from network); 6 Jan 2012 09:43:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 09:43: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 q069hMTI018164
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:22 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hEra014467; Fri, 6 Jan 2012 04:43:21 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:10 +0100
Message-Id: <1325842991-4404-4-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-1-git-send-email-drjones@redhat.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Describe dom0 support in the config menu and supply help text for it.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..88862d5 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support"
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:43:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6Ki-0000C8-1u; Fri, 06 Jan 2012 09:43:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kg-0000Ay-NM
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:30 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325843003!9798028!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18447 invoked from network); 6 Jan 2012 09:43:24 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 09:43: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 q069hMTI018164
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:22 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hEra014467; Fri, 6 Jan 2012 04:43:21 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:10 +0100
Message-Id: <1325842991-4404-4-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-1-git-send-email-drjones@redhat.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Describe dom0 support in the config menu and supply help text for it.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..88862d5 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support"
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09: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 1Rj6Kh-0000Bf-3s; Fri, 06 Jan 2012 09:43:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kf-0000Aw-A2
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:29 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325843001!8015259!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16540 invoked from network); 6 Jan 2012 09:43:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 09:43:22 -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 q069hJx8007957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:19 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hErY014467; Fri, 6 Jan 2012 04:43:18 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:08 +0100
Message-Id: <1325842991-4404-2-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-1-git-send-email-drjones@redhat.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..1d24061 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
 	 but will have no xen contents.
 
 config XEN_XENBUS_FRONTEND
-	tristate
+	bool
 
 config XEN_GNTDEV
 	tristate "userspace grant access device driver"
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09: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 1Rj6Kh-0000Bf-3s; Fri, 06 Jan 2012 09:43:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kf-0000Aw-A2
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:29 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325843001!8015259!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16540 invoked from network); 6 Jan 2012 09:43:22 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 09:43:22 -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 q069hJx8007957
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:19 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hErY014467; Fri, 6 Jan 2012 04:43:18 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:08 +0100
Message-Id: <1325842991-4404-2-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-1-git-send-email-drjones@redhat.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..1d24061 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
 	 but will have no xen contents.
 
 config XEN_XENBUS_FRONTEND
-	tristate
+	bool
 
 config XEN_GNTDEV
 	tristate "userspace grant access device driver"
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6Kg-0000BU-O0; Fri, 06 Jan 2012 09:43:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kf-0000Ax-B2
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:29 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325843002!9925702!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14883 invoked from network); 6 Jan 2012 09:43:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 09:43:23 -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 q069hKQx019074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:20 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hErZ014467; Fri, 6 Jan 2012 04:43:19 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:09 +0100
Message-Id: <1325842991-4404-3-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-1-git-send-email-drjones@redhat.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..269b299 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
 	select FB_SYS_IMAGEBLIT
 	select FB_SYS_FOPS
 	select FB_DEFERRED_IO
+	select INPUT_XEN_KBDDEV_FRONTEND
 	select XEN_XENBUS_FRONTEND
 	default y
 	help
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:43:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6Kg-0000BU-O0; Fri, 06 Jan 2012 09:43:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj6Kf-0000Ax-B2
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:43:29 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325843002!9925702!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYzMDE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14883 invoked from network); 6 Jan 2012 09:43:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 09:43:23 -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 q069hKQx019074
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 04:43:20 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q069hErZ014467; Fri, 6 Jan 2012 04:43:19 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 10:43:09 +0100
Message-Id: <1325842991-4404-3-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-1-git-send-email-drjones@redhat.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..269b299 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
 	select FB_SYS_IMAGEBLIT
 	select FB_SYS_FOPS
 	select FB_DEFERRED_IO
+	select INPUT_XEN_KBDDEV_FRONTEND
 	select XEN_XENBUS_FRONTEND
 	default y
 	help
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:56:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6X9-0000wz-CJ; Fri, 06 Jan 2012 09:56: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 1Rj6X8-0000wu-3Q
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:56:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325843775!9928615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32268 invoked from network); 6 Jan 2012 09:56: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 Jan 2012 09:56:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9860135"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 09:55: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, 6 Jan 2012
	09:55:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Jones <drjones@redhat.com>
Date: Fri, 6 Jan 2012 09:55:43 +0000
In-Reply-To: <5a67dfb3-fab0-4792-ba17-95f0934cf7af@zmail13.collab.prod.int.phx2.redhat.com>
References: <5a67dfb3-fab0-4792-ba17-95f0934cf7af@zmail13.collab.prod.int.phx2.redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325843743.25206.438.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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> 
> ----- Original Message -----
> > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > Describe dom0 support in the config menu and supply help text for
> > > it.
> > 
> > This turns a non-user visible symbol into a user visible one.
> > Previously
> > if Xen was enabled and the other prerequisites were met you would get
> > dom0 support automatically -- do we really want to change that?
> > According to 6b0661a5e6fbf it was a deliberate decision to have it
> > this
> > way.
> 
> I think it's a necessary evil in order to give users the ability to
> compile kernels without the support. I know it doesn't make much sense
> for most users, but...

Who actually wants to do this though and why? Do you have a bug report
requesting this change?

Almost all of the things which dom0 needs (e.g. PCI device management
etc) is also required by a domU with passthrough enabled so the savings
are really very slight.

We are talking less than 1k of code AFAICT, 319 bytes for
arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
whatever xen_register_gsi (a couple of dozen lines of code) adds to
arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
anywhere else. What savings do you see in practice from disabling just
this symbol?

We need to weigh up the size change against the complexity of asking the
user yet another question, I'm not convinced the question is worth it on
balance.

> > 
> > BTW, you forgot a Signed-off-by and the appropriate CCs (please use
> > MAINTAINERS or ./scripts/get-maintainer.pl).
> > 
> 
> Sorry, I'll resend properly.

I've added those CC's to this reply too.

Ian.

> 
> Drew
> 
> > Ian.
> > 
> > > ---
> > >  arch/x86/xen/Kconfig |    7 ++++++-
> > >  1 files changed, 6 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > index 26c731a..88862d5 100644
> > > --- a/arch/x86/xen/Kconfig
> > > +++ b/arch/x86/xen/Kconfig
> > > @@ -14,9 +14,14 @@ config XEN
> > >  	  Xen hypervisor.
> > >  
> > >  config XEN_DOM0
> > > -	def_bool y
> > > +	bool "Xen Initial Domain (Dom0) support"
> > > +	default y
> > >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > +	help
> > > +	  This allows the kernel to be used for the initial Xen domain,
> > > +	  Domain0. This is a privileged guest that supplies backends
> > > +	  and is used to manage the other Xen domains.
> > >  
> > >  # Dummy symbol since people have come to rely on the
> > >  PRIVILEGED_GUEST
> > >  # name in tools.
> > 
> > 
> > 



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 09:56:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 09:56:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6X9-0000wz-CJ; Fri, 06 Jan 2012 09:56: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 1Rj6X8-0000wu-3Q
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:56:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325843775!9928615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32268 invoked from network); 6 Jan 2012 09:56: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 Jan 2012 09:56:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9860135"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 09:55: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, 6 Jan 2012
	09:55:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Jones <drjones@redhat.com>
Date: Fri, 6 Jan 2012 09:55:43 +0000
In-Reply-To: <5a67dfb3-fab0-4792-ba17-95f0934cf7af@zmail13.collab.prod.int.phx2.redhat.com>
References: <5a67dfb3-fab0-4792-ba17-95f0934cf7af@zmail13.collab.prod.int.phx2.redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325843743.25206.438.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>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> 
> ----- Original Message -----
> > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > Describe dom0 support in the config menu and supply help text for
> > > it.
> > 
> > This turns a non-user visible symbol into a user visible one.
> > Previously
> > if Xen was enabled and the other prerequisites were met you would get
> > dom0 support automatically -- do we really want to change that?
> > According to 6b0661a5e6fbf it was a deliberate decision to have it
> > this
> > way.
> 
> I think it's a necessary evil in order to give users the ability to
> compile kernels without the support. I know it doesn't make much sense
> for most users, but...

Who actually wants to do this though and why? Do you have a bug report
requesting this change?

Almost all of the things which dom0 needs (e.g. PCI device management
etc) is also required by a domU with passthrough enabled so the savings
are really very slight.

We are talking less than 1k of code AFAICT, 319 bytes for
arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
whatever xen_register_gsi (a couple of dozen lines of code) adds to
arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
anywhere else. What savings do you see in practice from disabling just
this symbol?

We need to weigh up the size change against the complexity of asking the
user yet another question, I'm not convinced the question is worth it on
balance.

> > 
> > BTW, you forgot a Signed-off-by and the appropriate CCs (please use
> > MAINTAINERS or ./scripts/get-maintainer.pl).
> > 
> 
> Sorry, I'll resend properly.

I've added those CC's to this reply too.

Ian.

> 
> Drew
> 
> > Ian.
> > 
> > > ---
> > >  arch/x86/xen/Kconfig |    7 ++++++-
> > >  1 files changed, 6 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > index 26c731a..88862d5 100644
> > > --- a/arch/x86/xen/Kconfig
> > > +++ b/arch/x86/xen/Kconfig
> > > @@ -14,9 +14,14 @@ config XEN
> > >  	  Xen hypervisor.
> > >  
> > >  config XEN_DOM0
> > > -	def_bool y
> > > +	bool "Xen Initial Domain (Dom0) support"
> > > +	default y
> > >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > +	help
> > > +	  This allows the kernel to be used for the initial Xen domain,
> > > +	  Domain0. This is a privileged guest that supplies backends
> > > +	  and is used to manage the other Xen domains.
> > >  
> > >  # Dummy symbol since people have come to rely on the
> > >  PRIVILEGED_GUEST
> > >  # name in tools.
> > 
> > 
> > 



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:22:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6w0-0001Gs-MG; Fri, 06 Jan 2012 10:22: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 1Rj6vz-0001Gn-Ah
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:22:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325845316!2054034!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 10588 invoked from network); 6 Jan 2012 10:21:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 10:21:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 10:21:40 +0000
Message-Id: <4F06B671020000780006AC26@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 07:53:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
	<4F0566E2020000780006A89C@nat28.tlf.novell.com>
	<20120105212425.GA5180@phenom.dumpdata.com>
In-Reply-To: <20120105212425.GA5180@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Allen M Kay <allen.m.kay@intel.com>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
 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 05.01.12 at 22:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
>> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
>> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
>> > with the latest upstream Linux kernel.
>> > 
>> > 
>> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
>> > 2.6.18 kernel in blkback if you are using that version.
>> 
>> Which one are you referring to?
> 
> The fix you posted some time ago. Not all distros have picked it up.

Ah, okay, an already fixed one - you could have said "was" instead
of "is" to not make people like me nervous...

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:22:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6w0-0001Gs-MG; Fri, 06 Jan 2012 10:22: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 1Rj6vz-0001Gn-Ah
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:22:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325845316!2054034!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 10588 invoked from network); 6 Jan 2012 10:21:57 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 10:21:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 10:21:40 +0000
Message-Id: <4F06B671020000780006AC26@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 07:53:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
	<4F0566E2020000780006A89C@nat28.tlf.novell.com>
	<20120105212425.GA5180@phenom.dumpdata.com>
In-Reply-To: <20120105212425.GA5180@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Allen M Kay <allen.m.kay@intel.com>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
 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 05.01.12 at 22:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
>> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
>> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
>> > with the latest upstream Linux kernel.
>> > 
>> > 
>> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
>> > 2.6.18 kernel in blkback if you are using that version.
>> 
>> Which one are you referring to?
> 
> The fix you posted some time ago. Not all distros have picked it up.

Ah, okay, an already fixed one - you could have said "was" instead
of "is" to not make people like me nervous...

Jan


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:22:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6w5-0001HA-2L; Fri, 06 Jan 2012 10:22:09 +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 1Rj6w3-0001Gz-NY
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:22:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325845212!58620255!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 15523 invoked from network); 6 Jan 2012 10:20:12 -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; 6 Jan 2012 10:20:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 10:21:42 +0000
Message-Id: <4F06C101020000780006AC32@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 08:38:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> When a PCI device is transferred to another domain and it is still
> in usage (from the internal perspective), mention which other
> domain is using it to aid in debugging.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 474d52e..fa130bd 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
> xen_pcibk_device *pdev,
>  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
>  	if (xen_register_device_domain_owner(dev,
>  					     pdev->xdev->otherend_id) != 0) {
> -		dev_err(&dev->dev, "device has been assigned to another " \
> -			"domain! Over-writting the ownership, but beware.\n");
> +		int other_domain = xen_find_device_domain_owner(dev);
> +		dev_err(&dev->dev, "device has been assigned to %d " \
> +			"domain! Over-writting the ownership, but beware.\n",
> +			other_domain);

As you're touching this anyway, how about fixing the other minor
issues with it too? E.g.

		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
			" Overwriting the ownership, but beware.\n",
			xen_find_device_domain_owner(dev));

(a native English speaker may want to comment the "but beware"
part - it reads odd for me).

Jan

>  		xen_unregister_device_domain_owner(dev);
>  		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
>  	}
> -- 
> 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 Jan 06 10:22:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj6w5-0001HA-2L; Fri, 06 Jan 2012 10:22:09 +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 1Rj6w3-0001Gz-NY
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:22:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1325845212!58620255!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 15523 invoked from network); 6 Jan 2012 10:20:12 -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; 6 Jan 2012 10:20:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 10:21:42 +0000
Message-Id: <4F06C101020000780006AC32@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 08:38:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
In-Reply-To: <1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> When a PCI device is transferred to another domain and it is still
> in usage (from the internal perspective), mention which other
> domain is using it to aid in debugging.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 474d52e..fa130bd 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
> xen_pcibk_device *pdev,
>  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
>  	if (xen_register_device_domain_owner(dev,
>  					     pdev->xdev->otherend_id) != 0) {
> -		dev_err(&dev->dev, "device has been assigned to another " \
> -			"domain! Over-writting the ownership, but beware.\n");
> +		int other_domain = xen_find_device_domain_owner(dev);
> +		dev_err(&dev->dev, "device has been assigned to %d " \
> +			"domain! Over-writting the ownership, but beware.\n",
> +			other_domain);

As you're touching this anyway, how about fixing the other minor
issues with it too? E.g.

		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
			" Overwriting the ownership, but beware.\n",
			xen_find_device_domain_owner(dev));

(a native English speaker may want to comment the "but beware"
part - it reads odd for me).

Jan

>  		xen_unregister_device_domain_owner(dev);
>  		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
>  	}
> -- 
> 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 Jan 06 10:35:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10: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 1Rj78U-0001eN-EE; Fri, 06 Jan 2012 10:34:58 +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 1Rj78S-0001eI-V8
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:34:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325846090!2163411!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20767 invoked from network); 6 Jan 2012 10:34:50 -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;
	6 Jan 2012 10:34:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:34: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; Fri, 6 Jan 2012 10:34:50 +0000
Date: Fri, 6 Jan 2012 10:34:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Prasad Boddupalli <netlogic.xen@gmail.com>
In-Reply-To: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201061032300.3150@kaball-desktop>
References: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] MIPS port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 5 Jan 2012, Prasad Boddupalli wrote:
> Hello All,
> 
> About 3 weeks back, after resolving some console related issues, SMP versions of PV dom0 and domU could be booted on our
> MIPS boards. Our current version of MIPS Xen is based on an old version (3.4.0) and are currently in the process of moving
> the changes to the unstable branch. The Linux changes are not part of pv-ops infrastructure.
> 
> Although we have our simulator, the plan is to get the above running on Qemu to enable others try out the MIPS version of
> Xen. Linux could be released as a tarball for the present.

Great to hear that!


> The performance of applications such as hackbench is a little unsatisfactory when run on PV Linux (due to frequent traps
> in the syscall path). So, we are also working on performance improvements, which probably could go on in parallel with the
> submission to open source.
> 
> Any suggestions with regard to submitting our changes are welcome.
 
release early release often :)
I am looking forward to seeing the patches!

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:35:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10: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 1Rj78U-0001eN-EE; Fri, 06 Jan 2012 10:34:58 +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 1Rj78S-0001eI-V8
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:34:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325846090!2163411!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20767 invoked from network); 6 Jan 2012 10:34:50 -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;
	6 Jan 2012 10:34:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:34: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; Fri, 6 Jan 2012 10:34:50 +0000
Date: Fri, 6 Jan 2012 10:34:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Prasad Boddupalli <netlogic.xen@gmail.com>
In-Reply-To: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201061032300.3150@kaball-desktop>
References: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] MIPS port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 5 Jan 2012, Prasad Boddupalli wrote:
> Hello All,
> 
> About 3 weeks back, after resolving some console related issues, SMP versions of PV dom0 and domU could be booted on our
> MIPS boards. Our current version of MIPS Xen is based on an old version (3.4.0) and are currently in the process of moving
> the changes to the unstable branch. The Linux changes are not part of pv-ops infrastructure.
> 
> Although we have our simulator, the plan is to get the above running on Qemu to enable others try out the MIPS version of
> Xen. Linux could be released as a tarball for the present.

Great to hear that!


> The performance of applications such as hackbench is a little unsatisfactory when run on PV Linux (due to frequent traps
> in the syscall path). So, we are also working on performance improvements, which probably could go on in parallel with the
> submission to open source.
> 
> Any suggestions with regard to submitting our changes are welcome.
 
release early release often :)
I am looking forward to seeing the patches!

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:39:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj7Cf-0001m3-4T; Fri, 06 Jan 2012 10:39:17 +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 1Rj7Cc-0001lg-TO
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:39:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325846348!8066426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5984 invoked from network); 6 Jan 2012 10:39:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 10:39:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:39: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; Fri, 6 Jan 2012 10:39:08 +0000
Date: Fri, 6 Jan 2012 10:38:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <1325840229-3420-3-git-send-email-drjones@redhat.com>
Message-ID: <alpine.DEB.2.00.1201061038330.3150@kaball-desktop>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
	<1325840229-3420-3-git-send-email-drjones@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
 INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

ack

> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..269b299 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> +	select INPUT_XEN_KBDDEV_FRONTEND
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:39:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj7Cf-0001m3-4T; Fri, 06 Jan 2012 10:39:17 +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 1Rj7Cc-0001lg-TO
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:39:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325846348!8066426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5984 invoked from network); 6 Jan 2012 10:39:08 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 10:39:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:39: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; Fri, 6 Jan 2012 10:39:08 +0000
Date: Fri, 6 Jan 2012 10:38:59 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <1325840229-3420-3-git-send-email-drjones@redhat.com>
Message-ID: <alpine.DEB.2.00.1201061038330.3150@kaball-desktop>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
	<1325840229-3420-3-git-send-email-drjones@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
 INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

ack

> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..269b299 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> +	select INPUT_XEN_KBDDEV_FRONTEND
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:42:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10: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 1Rj7Fg-0001uB-OG; Fri, 06 Jan 2012 10:42:24 +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 1Rj7Ff-0001u0-RD
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:42:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325846537!9953997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9363 invoked from network); 6 Jan 2012 10:42:17 -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 Jan 2012 10:42:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:42: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; Fri, 6 Jan 2012 10:42:16 +0000
Date: Fri, 6 Jan 2012 10:42:07 +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: <1325843743.25206.438.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201061039480.3150@kaball-desktop>
References: <5a67dfb3-fab0-4792-ba17-95f0934cf7af@zmail13.collab.prod.int.phx2.redhat.com>
	<1325843743.25206.438.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> > 
> > ----- Original Message -----
> > > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > > Describe dom0 support in the config menu and supply help text for
> > > > it.
> > > 
> > > This turns a non-user visible symbol into a user visible one.
> > > Previously
> > > if Xen was enabled and the other prerequisites were met you would get
> > > dom0 support automatically -- do we really want to change that?
> > > According to 6b0661a5e6fbf it was a deliberate decision to have it
> > > this
> > > way.
> > 
> > I think it's a necessary evil in order to give users the ability to
> > compile kernels without the support. I know it doesn't make much sense
> > for most users, but...
> 
> Who actually wants to do this though and why? Do you have a bug report
> requesting this change?
> 
> Almost all of the things which dom0 needs (e.g. PCI device management
> etc) is also required by a domU with passthrough enabled so the savings
> are really very slight.
> 
> We are talking less than 1k of code AFAICT, 319 bytes for
> arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> whatever xen_register_gsi (a couple of dozen lines of code) adds to
> arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> anywhere else. What savings do you see in practice from disabling just
> this symbol?
> 
> We need to weigh up the size change against the complexity of asking the
> user yet another question, I'm not convinced the question is worth it on
> balance.

I agree, there is nothing to gain disabling dom0 support if the
conditions it depends upon are already met.
XEN_DOM0 was meant to be a silent option since the beginning to avoid
unnecessary complexity.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:42:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10: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 1Rj7Fg-0001uB-OG; Fri, 06 Jan 2012 10:42:24 +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 1Rj7Ff-0001u0-RD
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:42:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325846537!9953997!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9363 invoked from network); 6 Jan 2012 10:42:17 -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 Jan 2012 10:42:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861318"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:42: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; Fri, 6 Jan 2012 10:42:16 +0000
Date: Fri, 6 Jan 2012 10:42:07 +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: <1325843743.25206.438.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201061039480.3150@kaball-desktop>
References: <5a67dfb3-fab0-4792-ba17-95f0934cf7af@zmail13.collab.prod.int.phx2.redhat.com>
	<1325843743.25206.438.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> > 
> > ----- Original Message -----
> > > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > > Describe dom0 support in the config menu and supply help text for
> > > > it.
> > > 
> > > This turns a non-user visible symbol into a user visible one.
> > > Previously
> > > if Xen was enabled and the other prerequisites were met you would get
> > > dom0 support automatically -- do we really want to change that?
> > > According to 6b0661a5e6fbf it was a deliberate decision to have it
> > > this
> > > way.
> > 
> > I think it's a necessary evil in order to give users the ability to
> > compile kernels without the support. I know it doesn't make much sense
> > for most users, but...
> 
> Who actually wants to do this though and why? Do you have a bug report
> requesting this change?
> 
> Almost all of the things which dom0 needs (e.g. PCI device management
> etc) is also required by a domU with passthrough enabled so the savings
> are really very slight.
> 
> We are talking less than 1k of code AFAICT, 319 bytes for
> arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> whatever xen_register_gsi (a couple of dozen lines of code) adds to
> arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> anywhere else. What savings do you see in practice from disabling just
> this symbol?
> 
> We need to weigh up the size change against the complexity of asking the
> user yet another question, I'm not convinced the question is worth it on
> balance.

I agree, there is nothing to gain disabling dom0 support if the
conditions it depends upon are already met.
XEN_DOM0 was meant to be a silent option since the beginning to avoid
unnecessary complexity.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:43:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10: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 1Rj7GS-0001zi-CI; Fri, 06 Jan 2012 10:43:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rj7GQ-0001yB-Uv
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:43:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325846584!9987944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4910 invoked from network); 6 Jan 2012 10:43:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 10:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:43: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; Fri, 6 Jan 2012 10:43:04 +0000
Date: Fri, 6 Jan 2012 10:42:56 +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.1201061038330.3150@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201061042270.3150@kaball-desktop>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
	<1325840229-3420-3-git-send-email-drjones@redhat.com>
	<alpine.DEB.2.00.1201061038330.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
 INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Stefano Stabellini wrote:
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> > they don't use the xen frame buffer frontend. For this case it doesn't
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> > if you're using xenfb, then you'll want xenkbd. Switch the dependencies.
> 
> ack

I meant to ack the version you sent with a signed-off-by line

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:43:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10: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 1Rj7GS-0001zi-CI; Fri, 06 Jan 2012 10:43:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rj7GQ-0001yB-Uv
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:43:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1325846584!9987944!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4910 invoked from network); 6 Jan 2012 10:43:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 10:43:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:43: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; Fri, 6 Jan 2012 10:43:04 +0000
Date: Fri, 6 Jan 2012 10:42:56 +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.1201061038330.3150@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201061042270.3150@kaball-desktop>
References: <1325840229-3420-1-git-send-email-drjones@redhat.com>
	<1325840229-3420-3-git-send-email-drjones@redhat.com>
	<alpine.DEB.2.00.1201061038330.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
 INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Stefano Stabellini wrote:
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> > they don't use the xen frame buffer frontend. For this case it doesn't
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> > if you're using xenfb, then you'll want xenkbd. Switch the dependencies.
> 
> ack

I meant to ack the version you sent with a signed-off-by line

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:46:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj7Ix-0002Cz-0C; Fri, 06 Jan 2012 10:45:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj7Iv-0002CW-20
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:45:45 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325846738!9917386!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjMzOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17500 invoked from network); 6 Jan 2012 10:45:38 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-4.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 10:45:38 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q06AjVh3023083;
	Fri, 6 Jan 2012 05:45:31 -0500
Date: Fri, 06 Jan 2012 05:45:31 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <0872cdd4-a141-4904-8149-ff84cee00514@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1325843743.25206.438.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> > 
> > ----- Original Message -----
> > > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > > Describe dom0 support in the config menu and supply help text
> > > > for
> > > > it.
> > > 
> > > This turns a non-user visible symbol into a user visible one.
> > > Previously
> > > if Xen was enabled and the other prerequisites were met you would
> > > get
> > > dom0 support automatically -- do we really want to change that?
> > > According to 6b0661a5e6fbf it was a deliberate decision to have
> > > it
> > > this
> > > way.
> > 
> > I think it's a necessary evil in order to give users the ability to
> > compile kernels without the support. I know it doesn't make much
> > sense
> > for most users, but...
> 
> Who actually wants to do this though and why? Do you have a bug
> report
> requesting this change?
> 

No bug for it. I'll explain the motivation below.

> Almost all of the things which dom0 needs (e.g. PCI device management
> etc) is also required by a domU with passthrough enabled so the
> savings
> are really very slight.
> 
> We are talking less than 1k of code AFAICT, 319 bytes for
> arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> whatever xen_register_gsi (a couple of dozen lines of code) adds to
> arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> anywhere else. What savings do you see in practice from disabling
> just
> this symbol?

I completely agree that the saving are near none. The savings, however,
aren't the only reason to drive the change. It's actually the symbol
name itself. Unfortunately configs can be perceived as a contract of
support, i.e. if feature xyz is enabled in the distro's config, then
the distributor must have selected, and therefore will support, said
feature.

I didn't make this motivation clear in my initial post, because I was
hoping to spare people some eye rolling.

> 
> We need to weigh up the size change against the complexity of asking
> the
> user yet another question, I'm not convinced the question is worth it
> on
> balance.
> 

Tons of questions aren't much fun to wade through, but I guess I'm
generally for a config menu complexity that is proportional to
(and controls) the kernel complexity.

Drew

> > > 
> > > BTW, you forgot a Signed-off-by and the appropriate CCs (please
> > > use
> > > MAINTAINERS or ./scripts/get-maintainer.pl).
> > > 
> > 
> > Sorry, I'll resend properly.
> 
> I've added those CC's to this reply too.
> 
> Ian.
> 
> > 
> > Drew
> > 
> > > Ian.
> > > 
> > > > ---
> > > >  arch/x86/xen/Kconfig |    7 ++++++-
> > > >  1 files changed, 6 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > > index 26c731a..88862d5 100644
> > > > --- a/arch/x86/xen/Kconfig
> > > > +++ b/arch/x86/xen/Kconfig
> > > > @@ -14,9 +14,14 @@ config XEN
> > > >  	  Xen hypervisor.
> > > >  
> > > >  config XEN_DOM0
> > > > -	def_bool y
> > > > +	bool "Xen Initial Domain (Dom0) support"
> > > > +	default y
> > > >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > > >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > > +	help
> > > > +	  This allows the kernel to be used for the initial Xen
> > > > domain,
> > > > +	  Domain0. This is a privileged guest that supplies backends
> > > > +	  and is used to manage the other Xen domains.
> > > >  
> > > >  # Dummy symbol since people have come to rely on the
> > > >  PRIVILEGED_GUEST
> > > >  # name in tools.
> > > 
> > > 
> > > 
> 
> 
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:46:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj7Ix-0002Cz-0C; Fri, 06 Jan 2012 10:45:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj7Iv-0002CW-20
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:45:45 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325846738!9917386!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjMzOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17500 invoked from network); 6 Jan 2012 10:45:38 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-4.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 10:45:38 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q06AjVh3023083;
	Fri, 6 Jan 2012 05:45:31 -0500
Date: Fri, 06 Jan 2012 05:45:31 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <0872cdd4-a141-4904-8149-ff84cee00514@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1325843743.25206.438.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 2012-01-06 at 09:26 +0000, Andrew Jones wrote:
> > 
> > ----- Original Message -----
> > > On Fri, 2012-01-06 at 08:57 +0000, Andrew Jones wrote:
> > > > Describe dom0 support in the config menu and supply help text
> > > > for
> > > > it.
> > > 
> > > This turns a non-user visible symbol into a user visible one.
> > > Previously
> > > if Xen was enabled and the other prerequisites were met you would
> > > get
> > > dom0 support automatically -- do we really want to change that?
> > > According to 6b0661a5e6fbf it was a deliberate decision to have
> > > it
> > > this
> > > way.
> > 
> > I think it's a necessary evil in order to give users the ability to
> > compile kernels without the support. I know it doesn't make much
> > sense
> > for most users, but...
> 
> Who actually wants to do this though and why? Do you have a bug
> report
> requesting this change?
> 

No bug for it. I'll explain the motivation below.

> Almost all of the things which dom0 needs (e.g. PCI device management
> etc) is also required by a domU with passthrough enabled so the
> savings
> are really very slight.
> 
> We are talking less than 1k of code AFAICT, 319 bytes for
> arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> whatever xen_register_gsi (a couple of dozen lines of code) adds to
> arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> anywhere else. What savings do you see in practice from disabling
> just
> this symbol?

I completely agree that the saving are near none. The savings, however,
aren't the only reason to drive the change. It's actually the symbol
name itself. Unfortunately configs can be perceived as a contract of
support, i.e. if feature xyz is enabled in the distro's config, then
the distributor must have selected, and therefore will support, said
feature.

I didn't make this motivation clear in my initial post, because I was
hoping to spare people some eye rolling.

> 
> We need to weigh up the size change against the complexity of asking
> the
> user yet another question, I'm not convinced the question is worth it
> on
> balance.
> 

Tons of questions aren't much fun to wade through, but I guess I'm
generally for a config menu complexity that is proportional to
(and controls) the kernel complexity.

Drew

> > > 
> > > BTW, you forgot a Signed-off-by and the appropriate CCs (please
> > > use
> > > MAINTAINERS or ./scripts/get-maintainer.pl).
> > > 
> > 
> > Sorry, I'll resend properly.
> 
> I've added those CC's to this reply too.
> 
> Ian.
> 
> > 
> > Drew
> > 
> > > Ian.
> > > 
> > > > ---
> > > >  arch/x86/xen/Kconfig |    7 ++++++-
> > > >  1 files changed, 6 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> > > > index 26c731a..88862d5 100644
> > > > --- a/arch/x86/xen/Kconfig
> > > > +++ b/arch/x86/xen/Kconfig
> > > > @@ -14,9 +14,14 @@ config XEN
> > > >  	  Xen hypervisor.
> > > >  
> > > >  config XEN_DOM0
> > > > -	def_bool y
> > > > +	bool "Xen Initial Domain (Dom0) support"
> > > > +	default y
> > > >  	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > > >  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > > +	help
> > > > +	  This allows the kernel to be used for the initial Xen
> > > > domain,
> > > > +	  Domain0. This is a privileged guest that supplies backends
> > > > +	  and is used to manage the other Xen domains.
> > > >  
> > > >  # Dummy symbol since people have come to rely on the
> > > >  PRIVILEGED_GUEST
> > > >  # name in tools.
> > > 
> > > 
> > > 
> 
> 
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:51:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:51:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj7OG-0002S8-Q6; Fri, 06 Jan 2012 10:51: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 1Rj7OF-0002S2-Ky
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:51:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325847030!47516964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14019 invoked from network); 6 Jan 2012 10:50:30 -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 Jan 2012 10:50:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:50: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; Fri, 6 Jan 2012 10:50:54 +0000
Date: Fri, 6 Jan 2012 10:50:45 +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: <4F05F09E.8030800@web.de>
Message-ID: <alpine.DEB.2.00.1201061045550.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	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 Thu, 5 Jan 2012, Jan Kiszka wrote:
> On 2012-01-05 15:50, Avi Kivity wrote:
> >> Let me summarize what we have come up with so far:
> >>
> >> - we move the call to xen_register_framebuffer before
> >> memory_region_init_ram in vga_common_init;
> >>
> >> - we prevent xen_ram_alloc from allocating a second framebuffer on
> >> restore, checking for mr == framebuffer;
> >>
> >> - we avoid memsetting the framebuffer on restore (useless anyway, the
> >> videoram is going to be loaded from the savefile in the general case);
> >>
> >> - we introduce a xen_address field to cirrus_vmstate and we use it
> >> to map the videoram into qemu's address space and update vram_ptr in
> >> cirrus_post_load.
> >>
> >>
> >> Does it make sense? Do you agree with the approach?
> > 
> > Yes and yes.
> 
> To me this still sounds like a cirrus-only xen workaround that
> nevertheless spreads widely.

The first two points are still necessary even if we go with the
early_savevm option;
the third point is a good change regardless of the qemu accelerator;
the only cirrus-only workaround is the last point, however it certainly
doesn't spread widely. It is true that other framebuffer based devices
would need a similar change.


> Again, what speaks against migrating the information Xen needs before
> creating the machine or a single device? That would only introduce a
> generic concept of an (optional) "early", let's call it
> "accelerator-related" vmstate and would allow Xen to deal with all the
> specifics behind the curtain.

I am OK with both approaches.
The only practical difference between the two is how we pass the xen
framebuffer address across save/restore: either in the device specific
savevm record or in a xen specific early_savevm record.
What is it going to be?

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 10:51:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 10:51:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj7OG-0002S8-Q6; Fri, 06 Jan 2012 10:51: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 1Rj7OF-0002S2-Ky
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 10:51:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325847030!47516964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14019 invoked from network); 6 Jan 2012 10:50:30 -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 Jan 2012 10:50:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9861720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 10:50: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; Fri, 6 Jan 2012 10:50:54 +0000
Date: Fri, 6 Jan 2012 10:50:45 +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: <4F05F09E.8030800@web.de>
Message-ID: <alpine.DEB.2.00.1201061045550.3150@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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	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 Thu, 5 Jan 2012, Jan Kiszka wrote:
> On 2012-01-05 15:50, Avi Kivity wrote:
> >> Let me summarize what we have come up with so far:
> >>
> >> - we move the call to xen_register_framebuffer before
> >> memory_region_init_ram in vga_common_init;
> >>
> >> - we prevent xen_ram_alloc from allocating a second framebuffer on
> >> restore, checking for mr == framebuffer;
> >>
> >> - we avoid memsetting the framebuffer on restore (useless anyway, the
> >> videoram is going to be loaded from the savefile in the general case);
> >>
> >> - we introduce a xen_address field to cirrus_vmstate and we use it
> >> to map the videoram into qemu's address space and update vram_ptr in
> >> cirrus_post_load.
> >>
> >>
> >> Does it make sense? Do you agree with the approach?
> > 
> > Yes and yes.
> 
> To me this still sounds like a cirrus-only xen workaround that
> nevertheless spreads widely.

The first two points are still necessary even if we go with the
early_savevm option;
the third point is a good change regardless of the qemu accelerator;
the only cirrus-only workaround is the last point, however it certainly
doesn't spread widely. It is true that other framebuffer based devices
would need a similar change.


> Again, what speaks against migrating the information Xen needs before
> creating the machine or a single device? That would only introduce a
> generic concept of an (optional) "early", let's call it
> "accelerator-related" vmstate and would allow Xen to deal with all the
> specifics behind the curtain.

I am OK with both approaches.
The only practical difference between the two is how we pass the xen
framebuffer address across save/restore: either in the device specific
savevm record or in a xen specific early_savevm record.
What is it going to be?

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 11:01:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 11: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 1Rj7XR-0002em-SR; Fri, 06 Jan 2012 11:00:45 +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 1Rj7XQ-0002eh-6g
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 11:00:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325847583!59748343!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjkxNzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9006 invoked from network); 6 Jan 2012 10:59:44 -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;
	6 Jan 2012 10:59:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320642000"; d="scan'208";a="176526737"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 06:00: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, 6 Jan 2012
	06:00:37 -0500
Message-ID: <4F06D454.1080608@citrix.com>
Date: Fri, 6 Jan 2012 11:00: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Liuyongan <liuyongan@huawei.com>
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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

Could you please avoid top posing.

On 06/01/12 06:04, Liuyongan wrote:
>    As only 33 domains were successfully created(and destroyed) before the problem occurring,  there should be enough free IRQ  number and vector number to allocate(suppose that irqs and vectors failed to deallocate). And destroy_irq() will clear move_in_progress, so move_cleanup_count must be setted?  Is this the case? 

Is it repeatably 33 domains, or was that a 1 off experiment?  Can you
confirm exactly which version of Xen you are using, including changeset
if you know it?  Without knowing your hardware, it is hard to say if
there are actually enough free IRQs, although I do agree that what you
are currently seeing is buggy behavior.

The per-cpu IDT functionality introduced in Xen-4.0 is fragile at the
best of times, and has had several bugfixes and tweaks to it which I am
not certain have actually found their way back to Xen-4.0.  Could you
try with Xen-4.1 and see if the problem persists?

~Andrew

>    Yong an
>> -----Original Message-----
>> From: Liuyongan
>> Sent: Thursday, January 05, 2012 2:14 PM
>> To: Liuyongan; xen-devel@lists.xensource.com;
>> andrew.cooper3@citrix.com; keir@xen.org
>> Cc: Qianhuibin
>> Subject: RE: [xen-devel] create irq failed due to move_cleanup_count
>> always being set
>>
>>> On 04/01/12 11:38, Andrew Cooper wrote:
>>>> On 04/01/12 04:37, Liuyongan wrote:
>>>> Hi, all
>>>>
>>>>     I'm using xen-4.0 to do a test. And when I create a domain, it
>> failed due to create_irq() failure. As only 33 domains were
>> successfully created and destroyed before I got the continuous
>> failures, and the domain just before the failure was properly
>> destroyed(at least destroy_irq() was properly called, which will clear
>> move_in_progress, according to the prink-message). So I can conclude
>> for certain that __assign_irq_vector failed due to move_cleanup_count
>> always being set.
>>> Is it always 33 domains it takes to cause the problem, or does it
>> vary?
>>> If it varies, then I think you want this patch
>>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
>> which
>>> corrects the logic which works out which moved vectors it should
>> clean
>>> up.  Without it, stale irq numbers build up in the per-cpu irq_vector
>>> tables leading to __assign_irq_vector failing with -ENOSPC as it find
>>> find a vector to allocate.
>>   Yes, I've noticed this patch, as only 33 domains were created before
>> the failures, so vectors of a given cpu should not have been used up.
>> Besides, I got this problem after 143 domains were created another
>> time. But I could not repeat this problem manually as 4000+ domains
>> created successfully without this problem.
>>
>>>> //this is the normal case when create and destroy domain whose id is
>> 31;
>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
>>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
>>>> (XEN) irq.c:223, destroy irq 77
>>>>
>>>> //domain id 32 is created and destroyed correctly also.
>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
>>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
>>>> (XEN) irq.c:223, destroy irq 77
>>>>
>>>> //all the subsequent domain creation failed, below lists only 3
>> times:
>>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
>>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
>>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
>>>>
>>>>      I think this might be a bug and might have fixed, so I compare
>> my code with 4.1.2 and search the mail list for potential patches.
>> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
>> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which
>> add locks in __assign_irq_vector. Can anybody explain why this lock is
>> needed? Or is there a patch that might fix my bug? Thx.
>>> This patch fixes a problem where IOAPIC line level interrupts cease
>> for
>>> a while.  It has nothing to do with MSI interrupts.  (Also, there are
>> no
>>> locks altered, and xen-4.0-testing seems to have gained an additional
>>> hunk in hvm/vmx code unrelated to the original patch.)
>>>
>>>>     Addition message: my board is arch-x86, no domains left when
>> failed to create new ones, create_irq failure lasted one day until I
>> reboot the board, and the irq number allocated is used certainly for a
>> msi dev.
>>>> Yong an Liu
>>>> 2012.1.4
>>>>
>>>> _______________________________________________
>>>> 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 Jan 06 11:01:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 11: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 1Rj7XR-0002em-SR; Fri, 06 Jan 2012 11:00:45 +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 1Rj7XQ-0002eh-6g
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 11:00:44 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1325847583!59748343!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjkxNzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9006 invoked from network); 6 Jan 2012 10:59:44 -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;
	6 Jan 2012 10:59:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320642000"; d="scan'208";a="176526737"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 06:00: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, 6 Jan 2012
	06:00:37 -0500
Message-ID: <4F06D454.1080608@citrix.com>
Date: Fri, 6 Jan 2012 11:00: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Liuyongan <liuyongan@huawei.com>
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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

Could you please avoid top posing.

On 06/01/12 06:04, Liuyongan wrote:
>    As only 33 domains were successfully created(and destroyed) before the problem occurring,  there should be enough free IRQ  number and vector number to allocate(suppose that irqs and vectors failed to deallocate). And destroy_irq() will clear move_in_progress, so move_cleanup_count must be setted?  Is this the case? 

Is it repeatably 33 domains, or was that a 1 off experiment?  Can you
confirm exactly which version of Xen you are using, including changeset
if you know it?  Without knowing your hardware, it is hard to say if
there are actually enough free IRQs, although I do agree that what you
are currently seeing is buggy behavior.

The per-cpu IDT functionality introduced in Xen-4.0 is fragile at the
best of times, and has had several bugfixes and tweaks to it which I am
not certain have actually found their way back to Xen-4.0.  Could you
try with Xen-4.1 and see if the problem persists?

~Andrew

>    Yong an
>> -----Original Message-----
>> From: Liuyongan
>> Sent: Thursday, January 05, 2012 2:14 PM
>> To: Liuyongan; xen-devel@lists.xensource.com;
>> andrew.cooper3@citrix.com; keir@xen.org
>> Cc: Qianhuibin
>> Subject: RE: [xen-devel] create irq failed due to move_cleanup_count
>> always being set
>>
>>> On 04/01/12 11:38, Andrew Cooper wrote:
>>>> On 04/01/12 04:37, Liuyongan wrote:
>>>> Hi, all
>>>>
>>>>     I'm using xen-4.0 to do a test. And when I create a domain, it
>> failed due to create_irq() failure. As only 33 domains were
>> successfully created and destroyed before I got the continuous
>> failures, and the domain just before the failure was properly
>> destroyed(at least destroy_irq() was properly called, which will clear
>> move_in_progress, according to the prink-message). So I can conclude
>> for certain that __assign_irq_vector failed due to move_cleanup_count
>> always being set.
>>> Is it always 33 domains it takes to cause the problem, or does it
>> vary?
>>> If it varies, then I think you want this patch
>>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
>> which
>>> corrects the logic which works out which moved vectors it should
>> clean
>>> up.  Without it, stale irq numbers build up in the per-cpu irq_vector
>>> tables leading to __assign_irq_vector failing with -ENOSPC as it find
>>> find a vector to allocate.
>>   Yes, I've noticed this patch, as only 33 domains were created before
>> the failures, so vectors of a given cpu should not have been used up.
>> Besides, I got this problem after 143 domains were created another
>> time. But I could not repeat this problem manually as 4000+ domains
>> created successfully without this problem.
>>
>>>> //this is the normal case when create and destroy domain whose id is
>> 31;
>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
>>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
>>>> (XEN) irq.c:223, destroy irq 77
>>>>
>>>> //domain id 32 is created and destroyed correctly also.
>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
>>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
>>>> (XEN) irq.c:223, destroy irq 77
>>>>
>>>> //all the subsequent domain creation failed, below lists only 3
>> times:
>>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
>>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
>>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
>>>>
>>>>      I think this might be a bug and might have fixed, so I compare
>> my code with 4.1.2 and search the mail list for potential patches.
>> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
>> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch which
>> add locks in __assign_irq_vector. Can anybody explain why this lock is
>> needed? Or is there a patch that might fix my bug? Thx.
>>> This patch fixes a problem where IOAPIC line level interrupts cease
>> for
>>> a while.  It has nothing to do with MSI interrupts.  (Also, there are
>> no
>>> locks altered, and xen-4.0-testing seems to have gained an additional
>>> hunk in hvm/vmx code unrelated to the original patch.)
>>>
>>>>     Addition message: my board is arch-x86, no domains left when
>> failed to create new ones, create_irq failure lasted one day until I
>> reboot the board, and the irq number allocated is used certainly for a
>> msi dev.
>>>> Yong an Liu
>>>> 2012.1.4
>>>>
>>>> _______________________________________________
>>>> 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 Jan 06 11:03:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 11: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 1Rj7aC-0002kd-Fk; Fri, 06 Jan 2012 11:03:36 +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 1Rj7aA-0002kS-95
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 11:03:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325847805!2167187!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjkxNzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9002 invoked from network); 6 Jan 2012 11:03:27 -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;
	6 Jan 2012 11:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320642000"; d="scan'208";a="176527052"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 06:03:13 -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, 6 Jan 2012
	06:03:12 -0500
Message-ID: <4F06D4EF.2080609@citrix.com>
Date: Fri, 6 Jan 2012 11:03:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
In-Reply-To: <4F06C101020000780006AC32@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 06/01/12 08:38, Jan Beulich wrote:
>>>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> When a PCI device is transferred to another domain and it is still
>> in usage (from the internal perspective), mention which other
>> domain is using it to aid in debugging.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
>> index 474d52e..fa130bd 100644
>> --- a/drivers/xen/xen-pciback/xenbus.c
>> +++ b/drivers/xen/xen-pciback/xenbus.c
>> @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
>> xen_pcibk_device *pdev,
>>  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
>>  	if (xen_register_device_domain_owner(dev,
>>  					     pdev->xdev->otherend_id) != 0) {
>> -		dev_err(&dev->dev, "device has been assigned to another " \
>> -			"domain! Over-writting the ownership, but beware.\n");
>> +		int other_domain = xen_find_device_domain_owner(dev);
>> +		dev_err(&dev->dev, "device has been assigned to %d " \
>> +			"domain! Over-writting the ownership, but beware.\n",
>> +			other_domain);
> As you're touching this anyway, how about fixing the other minor
> issues with it too? E.g.
>
> 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
> 			" Overwriting the ownership, but beware.\n",
> 			xen_find_device_domain_owner(dev));
>
> (a native English speaker may want to comment the "but beware"
> part - it reads odd for me).
>
> Jan

Agreed - the "but beware" is superfluous to the meaning of the error
message.

~Andrew

>>  		xen_unregister_device_domain_owner(dev);
>>  		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
>>  	}
>> -- 
>> 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

-- 
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 Jan 06 11:03:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 11: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 1Rj7aC-0002kd-Fk; Fri, 06 Jan 2012 11:03:36 +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 1Rj7aA-0002kS-95
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 11:03:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325847805!2167187!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjkxNzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9002 invoked from network); 6 Jan 2012 11:03:27 -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;
	6 Jan 2012 11:03:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320642000"; d="scan'208";a="176527052"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 06:03:13 -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, 6 Jan 2012
	06:03:12 -0500
Message-ID: <4F06D4EF.2080609@citrix.com>
Date: Fri, 6 Jan 2012 11:03:11 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
In-Reply-To: <4F06C101020000780006AC32@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 06/01/12 08:38, Jan Beulich wrote:
>>>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> When a PCI device is transferred to another domain and it is still
>> in usage (from the internal perspective), mention which other
>> domain is using it to aid in debugging.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> ---
>>  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
>>  1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
>> index 474d52e..fa130bd 100644
>> --- a/drivers/xen/xen-pciback/xenbus.c
>> +++ b/drivers/xen/xen-pciback/xenbus.c
>> @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
>> xen_pcibk_device *pdev,
>>  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
>>  	if (xen_register_device_domain_owner(dev,
>>  					     pdev->xdev->otherend_id) != 0) {
>> -		dev_err(&dev->dev, "device has been assigned to another " \
>> -			"domain! Over-writting the ownership, but beware.\n");
>> +		int other_domain = xen_find_device_domain_owner(dev);
>> +		dev_err(&dev->dev, "device has been assigned to %d " \
>> +			"domain! Over-writting the ownership, but beware.\n",
>> +			other_domain);
> As you're touching this anyway, how about fixing the other minor
> issues with it too? E.g.
>
> 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
> 			" Overwriting the ownership, but beware.\n",
> 			xen_find_device_domain_owner(dev));
>
> (a native English speaker may want to comment the "but beware"
> part - it reads odd for me).
>
> Jan

Agreed - the "but beware" is superfluous to the meaning of the error
message.

~Andrew

>>  		xen_unregister_device_domain_owner(dev);
>>  		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
>>  	}
>> -- 
>> 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

-- 
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 Jan 06 11:22:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 11:22:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj7s0-00032i-8U; Fri, 06 Jan 2012 11:22:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rj7rz-00032d-AQ
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 11:21:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325848913!9818617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29934 invoked from network); 6 Jan 2012 11:21:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 11:21:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9862475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 11:21:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 11:21:52 +0000
Date: Fri, 6 Jan 2012 11:21:44 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <0872cdd4-a141-4904-8149-ff84cee00514@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.DEB.2.00.1201061051410.3150@kaball-desktop>
References: <0872cdd4-a141-4904-8149-ff84cee00514@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Andrew Jones wrote:
> > Almost all of the things which dom0 needs (e.g. PCI device management
> > etc) is also required by a domU with passthrough enabled so the
> > savings
> > are really very slight.
> > 
> > We are talking less than 1k of code AFAICT, 319 bytes for
> > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > whatever xen_register_gsi (a couple of dozen lines of code) adds to
> > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > anywhere else. What savings do you see in practice from disabling
> > just
> > this symbol?
> 
> I completely agree that the saving are near none. The savings, however,
> aren't the only reason to drive the change. It's actually the symbol
> name itself. Unfortunately configs can be perceived as a contract of
> support, i.e. if feature xyz is enabled in the distro's config, then
> the distributor must have selected, and therefore will support, said
> feature.
> 
> I didn't make this motivation clear in my initial post, because I was
> hoping to spare people some eye rolling.

I thought that in the kernel community we make decisions based on
technical merits rather than "contracts of support". 
Given that disabling the symbol saves near to nothing, the logical thing
to do is removing the symbol altogether.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 11:22:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 11:22:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj7s0-00032i-8U; Fri, 06 Jan 2012 11:22:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rj7rz-00032d-AQ
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 11:21:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1325848913!9818617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29934 invoked from network); 6 Jan 2012 11:21:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 11:21:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9862475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 11:21:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 11:21:52 +0000
Date: Fri, 6 Jan 2012 11:21:44 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <0872cdd4-a141-4904-8149-ff84cee00514@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.DEB.2.00.1201061051410.3150@kaball-desktop>
References: <0872cdd4-a141-4904-8149-ff84cee00514@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Andrew Jones wrote:
> > Almost all of the things which dom0 needs (e.g. PCI device management
> > etc) is also required by a domU with passthrough enabled so the
> > savings
> > are really very slight.
> > 
> > We are talking less than 1k of code AFAICT, 319 bytes for
> > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > whatever xen_register_gsi (a couple of dozen lines of code) adds to
> > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > anywhere else. What savings do you see in practice from disabling
> > just
> > this symbol?
> 
> I completely agree that the saving are near none. The savings, however,
> aren't the only reason to drive the change. It's actually the symbol
> name itself. Unfortunately configs can be perceived as a contract of
> support, i.e. if feature xyz is enabled in the distro's config, then
> the distributor must have selected, and therefore will support, said
> feature.
> 
> I didn't make this motivation clear in my initial post, because I was
> hoping to spare people some eye rolling.

I thought that in the kernel community we make decisions based on
technical merits rather than "contracts of support". 
Given that disabling the symbol saves near to nothing, the logical thing
to do is removing the symbol altogether.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 11:52:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 11:52:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8Kd-0003KB-PS; Fri, 06 Jan 2012 11:51:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1Rj8Kc-0003K4-Gg
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 11:51:34 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325850686!9944499!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTU5OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15680 invoked from network); 6 Jan 2012 11:51:27 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-12.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 11:51:27 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXD00AW1KXEH1@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:51:15 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXD00AL7KXEGV@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:51:14 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGE36438; Fri,
	06 Jan 2012 19:51:14 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35)
	by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 19:51:11 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Fri, 06 Jan 2012 19:50:55 +0800
Date: Fri, 06 Jan 2012 11:50:54 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <4F06D454.1080608@citrix.com>
X-Originating-IP: [10.166.82.189]
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DJX+VQ9QgABSyACAAItH0A==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
	<4F06D454.1080608@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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



> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Friday, January 06, 2012 7:01 PM
> To: Liuyongan
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
> always being set
> 
> Could you please avoid top posing.
> 
> On 06/01/12 06:04, Liuyongan wrote:
> >    As only 33 domains were successfully created(and destroyed) before
> the problem occurring,  there should be enough free IRQ  number and
> vector number to allocate(suppose that irqs and vectors failed to
> deallocate). And destroy_irq() will clear move_in_progress, so
> move_cleanup_count must be setted?  Is this the case?
> 
> Is it repeatably 33 domains, or was that a 1 off experiment?  Can you

  No, it's not repeatable, this occurred 2 times, another one is after 152 domains.

> confirm exactly which version of Xen you are using, including changeset
> if you know it?  Without knowing your hardware, it is hard to say if
> there are actually enough free IRQs, although I do agree that what you
> are currently seeing is buggy behavior.
> 
> The per-cpu IDT functionality introduced in Xen-4.0 is fragile at the
> best of times, and has had several bugfixes and tweaks to it which I am
> not certain have actually found their way back to Xen-4.0.  Could you
> try with Xen-4.1 and see if the problem persists?
> 
> ~Andrew

  As I could not make it re-occure in xen-4.0, trying xen-4.1 seems useless.
I noticed a scenario:

   1) move_in_progress occure;
   2) IPI IRQ_MOVE_CLEANUP_VECTOR interrupt is sent;
   3) the irq is destroyed, so cfg->vector is cleared, and etc.;
   4) IRQ_MOVE_CLEANUP_VECTOR irq is responded.
 
  In xen-4.1 , step 3, vector_irq of old_cpu_mask/old_domain is also reset, so in step 4) move_cleanup_count will failed to sub by one, and finally leading to create_irq failure(right?);

  In xen-4.0, step 3, and in my code vector_irq is not reset(this is a bug as you'v mentioned),  I still could not figure out why 
create_irq should failed.

> 
> >> -----Original Message-----
> >> From: Liuyongan
> >> Sent: Thursday, January 05, 2012 2:14 PM
> >> To: Liuyongan; xen-devel@lists.xensource.com;
> >> andrew.cooper3@citrix.com; keir@xen.org
> >> Cc: Qianhuibin
> >> Subject: RE: [xen-devel] create irq failed due to move_cleanup_count
> >> always being set
> >>
> >>> On 04/01/12 11:38, Andrew Cooper wrote:
> >>>> On 04/01/12 04:37, Liuyongan wrote:
> >>>> Hi, all
> >>>>
> >>>>     I'm using xen-4.0 to do a test. And when I create a domain, it
> >> failed due to create_irq() failure. As only 33 domains were
> >> successfully created and destroyed before I got the continuous
> >> failures, and the domain just before the failure was properly
> >> destroyed(at least destroy_irq() was properly called, which will
> clear
> >> move_in_progress, according to the prink-message). So I can conclude
> >> for certain that __assign_irq_vector failed due to
> move_cleanup_count
> >> always being set.
> >>> Is it always 33 domains it takes to cause the problem, or does it
> >> vary?
> >>> If it varies, then I think you want this patch
> >>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
> >> which
> >>> corrects the logic which works out which moved vectors it should
> >> clean
> >>> up.  Without it, stale irq numbers build up in the per-cpu
> irq_vector
> >>> tables leading to __assign_irq_vector failing with -ENOSPC as it
> find
> >>> find a vector to allocate.
> >>   Yes, I've noticed this patch, as only 33 domains were created
> before
> >> the failures, so vectors of a given cpu should not have been used
> up.
> >> Besides, I got this problem after 143 domains were created another
> >> time. But I could not repeat this problem manually as 4000+ domains
> >> created successfully without this problem.
> >>
> >>>> //this is the normal case when create and destroy domain whose id
> is
> >> 31;
> >>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> >>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> >>>> (XEN) irq.c:223, destroy irq 77
> >>>>
> >>>> //domain id 32 is created and destroyed correctly also.
> >>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> >>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> >>>> (XEN) irq.c:223, destroy irq 77
> >>>>
> >>>> //all the subsequent domain creation failed, below lists only 3
> >> times:
> >>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
> >>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
> >>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
> >>>>
> >>>>      I think this might be a bug and might have fixed, so I
> compare
> >> my code with 4.1.2 and search the mail list for potential patches.
> >>
> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
> >> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch
> which
> >> add locks in __assign_irq_vector. Can anybody explain why this lock
> is
> >> needed? Or is there a patch that might fix my bug? Thx.
> >>> This patch fixes a problem where IOAPIC line level interrupts cease
> >> for
> >>> a while.  It has nothing to do with MSI interrupts.  (Also, there
> are
> >> no
> >>> locks altered, and xen-4.0-testing seems to have gained an
> additional
> >>> hunk in hvm/vmx code unrelated to the original patch.)
> >>>
> >>>>     Addition message: my board is arch-x86, no domains left when
> >> failed to create new ones, create_irq failure lasted one day until I
> >> reboot the board, and the irq number allocated is used certainly for
> a
> >> msi dev.
> >>>> Yong an Liu
> >>>> 2012.1.4
> >>>>
> >>>> _______________________________________________
> >>>> 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 Jan 06 11:52:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 11:52:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8Kd-0003KB-PS; Fri, 06 Jan 2012 11:51:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1Rj8Kc-0003K4-Gg
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 11:51:34 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325850686!9944499!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNTU5OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15680 invoked from network); 6 Jan 2012 11:51:27 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-12.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 11:51:27 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXD00AW1KXEH1@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:51:15 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXD00AL7KXEGV@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:51:14 +0800 (CST)
Received: from szxeml207-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGE36438; Fri,
	06 Jan 2012 19:51:14 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35)
	by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 19:51:11 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003;
	Fri, 06 Jan 2012 19:50:55 +0800
Date: Fri, 06 Jan 2012 11:50:54 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <4F06D454.1080608@citrix.com>
X-Originating-IP: [10.166.82.189]
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DJX+VQ9QgABSyACAAItH0A==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
	<4F06D454.1080608@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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



> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Friday, January 06, 2012 7:01 PM
> To: Liuyongan
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
> always being set
> 
> Could you please avoid top posing.
> 
> On 06/01/12 06:04, Liuyongan wrote:
> >    As only 33 domains were successfully created(and destroyed) before
> the problem occurring,  there should be enough free IRQ  number and
> vector number to allocate(suppose that irqs and vectors failed to
> deallocate). And destroy_irq() will clear move_in_progress, so
> move_cleanup_count must be setted?  Is this the case?
> 
> Is it repeatably 33 domains, or was that a 1 off experiment?  Can you

  No, it's not repeatable, this occurred 2 times, another one is after 152 domains.

> confirm exactly which version of Xen you are using, including changeset
> if you know it?  Without knowing your hardware, it is hard to say if
> there are actually enough free IRQs, although I do agree that what you
> are currently seeing is buggy behavior.
> 
> The per-cpu IDT functionality introduced in Xen-4.0 is fragile at the
> best of times, and has had several bugfixes and tweaks to it which I am
> not certain have actually found their way back to Xen-4.0.  Could you
> try with Xen-4.1 and see if the problem persists?
> 
> ~Andrew

  As I could not make it re-occure in xen-4.0, trying xen-4.1 seems useless.
I noticed a scenario:

   1) move_in_progress occure;
   2) IPI IRQ_MOVE_CLEANUP_VECTOR interrupt is sent;
   3) the irq is destroyed, so cfg->vector is cleared, and etc.;
   4) IRQ_MOVE_CLEANUP_VECTOR irq is responded.
 
  In xen-4.1 , step 3, vector_irq of old_cpu_mask/old_domain is also reset, so in step 4) move_cleanup_count will failed to sub by one, and finally leading to create_irq failure(right?);

  In xen-4.0, step 3, and in my code vector_irq is not reset(this is a bug as you'v mentioned),  I still could not figure out why 
create_irq should failed.

> 
> >> -----Original Message-----
> >> From: Liuyongan
> >> Sent: Thursday, January 05, 2012 2:14 PM
> >> To: Liuyongan; xen-devel@lists.xensource.com;
> >> andrew.cooper3@citrix.com; keir@xen.org
> >> Cc: Qianhuibin
> >> Subject: RE: [xen-devel] create irq failed due to move_cleanup_count
> >> always being set
> >>
> >>> On 04/01/12 11:38, Andrew Cooper wrote:
> >>>> On 04/01/12 04:37, Liuyongan wrote:
> >>>> Hi, all
> >>>>
> >>>>     I'm using xen-4.0 to do a test. And when I create a domain, it
> >> failed due to create_irq() failure. As only 33 domains were
> >> successfully created and destroyed before I got the continuous
> >> failures, and the domain just before the failure was properly
> >> destroyed(at least destroy_irq() was properly called, which will
> clear
> >> move_in_progress, according to the prink-message). So I can conclude
> >> for certain that __assign_irq_vector failed due to
> move_cleanup_count
> >> always being set.
> >>> Is it always 33 domains it takes to cause the problem, or does it
> >> vary?
> >>> If it varies, then I think you want this patch
> >>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
> >> which
> >>> corrects the logic which works out which moved vectors it should
> >> clean
> >>> up.  Without it, stale irq numbers build up in the per-cpu
> irq_vector
> >>> tables leading to __assign_irq_vector failing with -ENOSPC as it
> find
> >>> find a vector to allocate.
> >>   Yes, I've noticed this patch, as only 33 domains were created
> before
> >> the failures, so vectors of a given cpu should not have been used
> up.
> >> Besides, I got this problem after 143 domains were created another
> >> time. But I could not repeat this problem manually as 4000+ domains
> >> created successfully without this problem.
> >>
> >>>> //this is the normal case when create and destroy domain whose id
> is
> >> 31;
> >>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> >>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> >>>> (XEN) irq.c:223, destroy irq 77
> >>>>
> >>>> //domain id 32 is created and destroyed correctly also.
> >>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> >>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> >>>> (XEN) irq.c:223, destroy irq 77
> >>>>
> >>>> //all the subsequent domain creation failed, below lists only 3
> >> times:
> >>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
> >>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
> >>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
> >>>>
> >>>>      I think this might be a bug and might have fixed, so I
> compare
> >> my code with 4.1.2 and search the mail list for potential patches.
> >>
> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
> >> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch
> which
> >> add locks in __assign_irq_vector. Can anybody explain why this lock
> is
> >> needed? Or is there a patch that might fix my bug? Thx.
> >>> This patch fixes a problem where IOAPIC line level interrupts cease
> >> for
> >>> a while.  It has nothing to do with MSI interrupts.  (Also, there
> are
> >> no
> >>> locks altered, and xen-4.0-testing seems to have gained an
> additional
> >>> hunk in hvm/vmx code unrelated to the original patch.)
> >>>
> >>>>     Addition message: my board is arch-x86, no domains left when
> >> failed to create new ones, create_irq failure lasted one day until I
> >> reboot the board, and the irq number allocated is used certainly for
> a
> >> msi dev.
> >>>> Yong an Liu
> >>>> 2012.1.4
> >>>>
> >>>> _______________________________________________
> >>>> 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 Jan 06 12:00:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12: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 1Rj8TC-0003ZV-2i; Fri, 06 Jan 2012 12:00:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rj8TA-0003ZD-Lm
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:00:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325851216!3232374!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9206 invoked from network); 6 Jan 2012 12:00:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 12:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9863157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 12:00: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, 6 Jan 2012
	12:00:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Prasad Boddupalli <netlogic.xen@gmail.com>
Date: Fri, 6 Jan 2012 12:00:15 +0000
In-Reply-To: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
References: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325851216.25206.482.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] MIPS port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 23:38 +0000, Prasad Boddupalli wrote:
> Hello All,
> 
> About 3 weeks back, after resolving some console related issues, SMP
> versions of PV dom0 and domU could be booted on our MIPS boards. Our
> current version of MIPS Xen is based on an old version (3.4.0) and are
> currently in the process of moving the changes to the unstable branch.
> The Linux changes are not part of pv-ops infrastructure.
> 
> Although we have our simulator, the plan is to get the above running
> on Qemu to enable others try out the MIPS version of Xen. Linux could
> be released as a tarball for the present.
> 
> The performance of applications such as hackbench is a little
> unsatisfactory when run on PV Linux (due to frequent traps in the
> syscall path). So, we are also working on performance improvements,
> which probably could go on in parallel with the submission to open
> source.
> 
> Any suggestions with regard to submitting our changes are welcome.

Sounds pretty cool!

The usual guide for posting patches is
http://wiki.xen.org/wiki/SubmittingXenPatches but that's not really
appropriate for a complete new architecture submission. Some stuff, like
signing-off patches, writing commit messages and hints on tooling still
apply so I'd encourage you to read it anyway.

You might like to take a look at Stefano's recent postings of the Xen
ARM port patches. In general the form is general patches first followed
by new arch code in rough functional blocks, with the usual constraint
wrt building at every step relaxed. Putting the Makefile patch last
helps avoid any confusion about when the new port should be buildable.

In general I think it'd be better to just post it and we can worry about
the details later.

Cheers,
Ian.


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:00:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12: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 1Rj8TC-0003ZV-2i; Fri, 06 Jan 2012 12:00:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rj8TA-0003ZD-Lm
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:00:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1325851216!3232374!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9206 invoked from network); 6 Jan 2012 12:00:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 12:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9863157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 12:00: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, 6 Jan 2012
	12:00:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Prasad Boddupalli <netlogic.xen@gmail.com>
Date: Fri, 6 Jan 2012 12:00:15 +0000
In-Reply-To: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
References: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325851216.25206.482.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] MIPS port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 23:38 +0000, Prasad Boddupalli wrote:
> Hello All,
> 
> About 3 weeks back, after resolving some console related issues, SMP
> versions of PV dom0 and domU could be booted on our MIPS boards. Our
> current version of MIPS Xen is based on an old version (3.4.0) and are
> currently in the process of moving the changes to the unstable branch.
> The Linux changes are not part of pv-ops infrastructure.
> 
> Although we have our simulator, the plan is to get the above running
> on Qemu to enable others try out the MIPS version of Xen. Linux could
> be released as a tarball for the present.
> 
> The performance of applications such as hackbench is a little
> unsatisfactory when run on PV Linux (due to frequent traps in the
> syscall path). So, we are also working on performance improvements,
> which probably could go on in parallel with the submission to open
> source.
> 
> Any suggestions with regard to submitting our changes are welcome.

Sounds pretty cool!

The usual guide for posting patches is
http://wiki.xen.org/wiki/SubmittingXenPatches but that's not really
appropriate for a complete new architecture submission. Some stuff, like
signing-off patches, writing commit messages and hints on tooling still
apply so I'd encourage you to read it anyway.

You might like to take a look at Stefano's recent postings of the Xen
ARM port patches. In general the form is general patches first followed
by new arch code in rough functional blocks, with the usual constraint
wrt building at every step relaxed. Putting the Makefile patch last
helps avoid any confusion about when the new port should be buildable.

In general I think it'd be better to just post it and we can worry about
the details later.

Cheers,
Ian.


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:01:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8UE-0003d8-J6; Fri, 06 Jan 2012 12:01:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rj8UD-0003ci-2q
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:01:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325851282!6208806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27319 invoked from network); 6 Jan 2012 12:01:23 -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;
	6 Jan 2012 12:01:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9863176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 12:01: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; Fri, 6 Jan 2012 12:01:09 +0000
Date: Fri, 6 Jan 2012 12:01:00 +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: <20229.59079.535980.830271@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201061127460.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2121740318-1325849355=:3150"
Content-ID: <alpine.DEB.2.00.1201061129360.3150@kaball-desktop>
Cc: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-2121740318-1325849355=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1201061129361.3150@kaball-desktop>

On Thu, 5 Jan 2012, Ian Jackson wrote:
> Roger Pau Monn�© writes ("Re: [Xen-devel] RFC: Still TODO for 4.2?"):
> > I don't know much about driver domains, but from what I've read they
> > should be running something like NetBSD xenbackend and listen for
> > xenstore events. Most of the functions that I've written on my hotplug
> > series can be used to create a little daemon, that's not the problem,
> > the problem is what can we use to synchronize hotplug script calling
> > and libxl (what comes to mind is using a dedicated xenstore variable
> > for each device, but someone might have a better idea).
> 
> This envisages devicer setup/teardown scripts in driver domains
> running in a different way to those in the same domain as the
> toolstack.  Are we sure this is a good idea ?
> 
> I think it would be preferable to have only one interface to device
> scripts, which is used everywhere.  That interface would have to
> involve initiation by the toolstack, and collection of resulting
> success/failure/etc., via xenstore.
> 
> The sequence of events for vifs with a kernel-level backend needs
> to go like this:
>   * toolstack tells backend domain to create vif, via xenstore
>   * backend kernel creates a virtual network interface vifNN
>   * something in backend domain notices that this vifNN
>     has appeared and consequently
>   * device setup script runs, enslaves vifNN to bridge, adds
>     it to routing tables, gives it an address, etc.
>   * something in backend domain domain tells toolstack vif is ready
>   [ device is used ]
>   * toolstack tells backend domain to destroy vif; perhaps entire
>     xenstore directory is forcibly removed??
>   * backend kernel removes virtual network interface immediately
>     and all routes, bridge enslavements, etc., are undone
>   * something in backend notices the removal
>   * device teardown script may need to remove eg firewall rules
>   * when this is complete, the backend domain notifies the
>     toolstack (how??)
> 
> For block devices with a kernel-level backend:
>   * toolstack tells backend domain to create vbd
>     parameters include: vbd number, target??, script??
>   * something in backend domain notices this and consequently
>   * device setup script runs, creates a suitable actual
>     block device in backend domain
>   * backend kernel picks up actual block device details and
>     becomes available to guest
>   * something in backend domain tells the toolstack all is well
>   [ device is used ]
>   * toolstack tells backend domain to destroy vbd; perhaps entire
>     xenstore directory is forcibly removed??
>   * backend kernel removes its actual backend and closes the
>     block device, and somehow notifies userspace when this
>     is done so that
>   * device teardown script cleans up, including making actual
>     block device go away (if it was one which the setup script
>     created)
>   * when this is complete, the backend domain notifies the
>     toolstack (how??)
> 
> For block devices with a user-level backend:
>   * toolstack tells backend domain to create vbd
>     parameters include: vbd number, target??, script??
>   * userland backend notices this, does its housekeeping
>     and setup, and tells the toolstack all is well
>   [ device is used ]
>   * toolstack tells backend domain to destroy vbd; perhaps entire
>     xenstore directory is forcibly removed??
>   * userland backend removes its actual backend and closes the
>     resources it was using, and
>   * notifies the toolstack (how??)
> 
> Much of this seems to be covered by, or coverable by, the existing
> xenstore protocol.  I think we just need to define in more detail
> exactly how it should all work, and on each platform how the
> "something"s work.
 
I have given some thoughts on this issue and these are my observations:

- given that the backend might be in userspace, it is recommendable not
to rely on udev for the execution of the scripts;

- given that some complex network storage solutions might have difficult
timing requirements, it is advisable not to tight the execution of the setup
script to the setup of the block backend node on xenstore (that can
cause the block backend to run before its time). We want to be able to
setup the storage and once that is done write the params node on
xenstore for the block backend.

- same for teardown: it is better not to tight the executing of the
teardown block script to the removal of the block backend node on
xenstore. We could run the script independently and store their
information somewhere else.

As a consequence I suggest that we adopt a solution similar to
xenbackendd, however rather than reacting to the backend creation on
xenstore, it should react on different, more explicit, events on another
xenstore location.
This way the toolstack can decide exactly when the script gets executed
independently from the block/network backend.
Also storing the script info on a different location has the advantage
that we can prevent the script from writing (maybe even reading) to the
backend nodes on xenstore, that frankly is quite scaring.

However to do this we probably need to change some/most of/all the
scripts.
--8323329-2121740318-1325849355=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-2121740318-1325849355=:3150--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:01:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:01:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8UE-0003d8-J6; Fri, 06 Jan 2012 12:01:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rj8UD-0003ci-2q
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:01:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1325851282!6208806!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27319 invoked from network); 6 Jan 2012 12:01:23 -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;
	6 Jan 2012 12:01:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; 
   d="scan'208";a="9863176"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 12:01: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; Fri, 6 Jan 2012 12:01:09 +0000
Date: Fri, 6 Jan 2012 12:01:00 +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: <20229.59079.535980.830271@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201061127460.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2121740318-1325849355=:3150"
Content-ID: <alpine.DEB.2.00.1201061129360.3150@kaball-desktop>
Cc: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-2121740318-1325849355=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1201061129361.3150@kaball-desktop>

On Thu, 5 Jan 2012, Ian Jackson wrote:
> Roger Pau Monn�© writes ("Re: [Xen-devel] RFC: Still TODO for 4.2?"):
> > I don't know much about driver domains, but from what I've read they
> > should be running something like NetBSD xenbackend and listen for
> > xenstore events. Most of the functions that I've written on my hotplug
> > series can be used to create a little daemon, that's not the problem,
> > the problem is what can we use to synchronize hotplug script calling
> > and libxl (what comes to mind is using a dedicated xenstore variable
> > for each device, but someone might have a better idea).
> 
> This envisages devicer setup/teardown scripts in driver domains
> running in a different way to those in the same domain as the
> toolstack.  Are we sure this is a good idea ?
> 
> I think it would be preferable to have only one interface to device
> scripts, which is used everywhere.  That interface would have to
> involve initiation by the toolstack, and collection of resulting
> success/failure/etc., via xenstore.
> 
> The sequence of events for vifs with a kernel-level backend needs
> to go like this:
>   * toolstack tells backend domain to create vif, via xenstore
>   * backend kernel creates a virtual network interface vifNN
>   * something in backend domain notices that this vifNN
>     has appeared and consequently
>   * device setup script runs, enslaves vifNN to bridge, adds
>     it to routing tables, gives it an address, etc.
>   * something in backend domain domain tells toolstack vif is ready
>   [ device is used ]
>   * toolstack tells backend domain to destroy vif; perhaps entire
>     xenstore directory is forcibly removed??
>   * backend kernel removes virtual network interface immediately
>     and all routes, bridge enslavements, etc., are undone
>   * something in backend notices the removal
>   * device teardown script may need to remove eg firewall rules
>   * when this is complete, the backend domain notifies the
>     toolstack (how??)
> 
> For block devices with a kernel-level backend:
>   * toolstack tells backend domain to create vbd
>     parameters include: vbd number, target??, script??
>   * something in backend domain notices this and consequently
>   * device setup script runs, creates a suitable actual
>     block device in backend domain
>   * backend kernel picks up actual block device details and
>     becomes available to guest
>   * something in backend domain tells the toolstack all is well
>   [ device is used ]
>   * toolstack tells backend domain to destroy vbd; perhaps entire
>     xenstore directory is forcibly removed??
>   * backend kernel removes its actual backend and closes the
>     block device, and somehow notifies userspace when this
>     is done so that
>   * device teardown script cleans up, including making actual
>     block device go away (if it was one which the setup script
>     created)
>   * when this is complete, the backend domain notifies the
>     toolstack (how??)
> 
> For block devices with a user-level backend:
>   * toolstack tells backend domain to create vbd
>     parameters include: vbd number, target??, script??
>   * userland backend notices this, does its housekeeping
>     and setup, and tells the toolstack all is well
>   [ device is used ]
>   * toolstack tells backend domain to destroy vbd; perhaps entire
>     xenstore directory is forcibly removed??
>   * userland backend removes its actual backend and closes the
>     resources it was using, and
>   * notifies the toolstack (how??)
> 
> Much of this seems to be covered by, or coverable by, the existing
> xenstore protocol.  I think we just need to define in more detail
> exactly how it should all work, and on each platform how the
> "something"s work.
 
I have given some thoughts on this issue and these are my observations:

- given that the backend might be in userspace, it is recommendable not
to rely on udev for the execution of the scripts;

- given that some complex network storage solutions might have difficult
timing requirements, it is advisable not to tight the execution of the setup
script to the setup of the block backend node on xenstore (that can
cause the block backend to run before its time). We want to be able to
setup the storage and once that is done write the params node on
xenstore for the block backend.

- same for teardown: it is better not to tight the executing of the
teardown block script to the removal of the block backend node on
xenstore. We could run the script independently and store their
information somewhere else.

As a consequence I suggest that we adopt a solution similar to
xenbackendd, however rather than reacting to the backend creation on
xenstore, it should react on different, more explicit, events on another
xenstore location.
This way the toolstack can decide exactly when the script gets executed
independently from the block/network backend.
Also storing the script info on a different location has the advantage
that we can prevent the script from writing (maybe even reading) to the
backend nodes on xenstore, that frankly is quite scaring.

However to do this we probably need to change some/most of/all the
scripts.
--8323329-2121740318-1325849355=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-2121740318-1325849355=:3150--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:18:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8ke-0003xb-9d; Fri, 06 Jan 2012 12:18:28 +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 1Rj8kc-0003xW-VA
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:18:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325852299!9302631!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQ2OTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12278 invoked from network); 6 Jan 2012 12:18:20 -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 Jan 2012 12:18:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320642000"; d="scan'208";a="20624055"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 07:18:18 -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, 6 Jan 2012
	07:18:18 -0500
Message-ID: <4F06E689.9030506@citrix.com>
Date: Fri, 6 Jan 2012 12:18:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Liuyongan <liuyongan@huawei.com>
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
	<4F06D454.1080608@citrix.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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 06/01/12 11:50, Liuyongan wrote:
>
>> -----Original Message-----
>> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
>> Sent: Friday, January 06, 2012 7:01 PM
>> To: Liuyongan
>> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
>> Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
>> always being set
>>
>> Could you please avoid top posing.
>>
>> On 06/01/12 06:04, Liuyongan wrote:
>>>    As only 33 domains were successfully created(and destroyed) before
>> the problem occurring,  there should be enough free IRQ  number and
>> vector number to allocate(suppose that irqs and vectors failed to
>> deallocate). And destroy_irq() will clear move_in_progress, so
>> move_cleanup_count must be setted?  Is this the case?
>>
>> Is it repeatably 33 domains, or was that a 1 off experiment?  Can you
>   No, it's not repeatable, this occurred 2 times, another one is after 152 domains.

Can you list all the failures you have seen with the number of domains? 
So far it seems that it has been 33 twice but many more some of the
time, which doesn't lend itself to saying "33 domains is a systematic
failure" for certain at the moment.

>> confirm exactly which version of Xen you are using, including changeset
>> if you know it?  Without knowing your hardware, it is hard to say if
>> there are actually enough free IRQs, although I do agree that what you
>> are currently seeing is buggy behavior.
>>
>> The per-cpu IDT functionality introduced in Xen-4.0 is fragile at the
>> best of times, and has had several bugfixes and tweaks to it which I am
>> not certain have actually found their way back to Xen-4.0.  Could you
>> try with Xen-4.1 and see if the problem persists?
>>
>> ~Andrew
>   As I could not make it re-occure in xen-4.0, trying xen-4.1 seems useless.
> I noticed a scenario:

I am confused.  Above, you say that the problem is repeatable, but here
you say it is not.

>    1) move_in_progress occure;
>    2) IPI IRQ_MOVE_CLEANUP_VECTOR interrupt is sent;
>    3) the irq is destroyed, so cfg->vector is cleared, and etc.;
>    4) IRQ_MOVE_CLEANUP_VECTOR irq is responded.
>  
>   In xen-4.1 , step 3, vector_irq of old_cpu_mask/old_domain is also reset, so in step 4) move_cleanup_count will failed to sub by one, and finally leading to create_irq failure(right?);
>
>   In xen-4.0, step 3, and in my code vector_irq is not reset(this is a bug as you'v mentioned),  I still could not figure out why 
> create_irq should failed.

The first point of debugging should be to see how create_irq is
failing.  Is it failing because of find_unassigned_irq() or because of
__assign_irq_vector().

Another piece of useful information would be what your guests are and
what they are trying to do with interrupts.  Are you using PCI passthrough?

~Andrew

>>>> -----Original Message-----
>>>> From: Liuyongan
>>>> Sent: Thursday, January 05, 2012 2:14 PM
>>>> To: Liuyongan; xen-devel@lists.xensource.com;
>>>> andrew.cooper3@citrix.com; keir@xen.org
>>>> Cc: Qianhuibin
>>>> Subject: RE: [xen-devel] create irq failed due to move_cleanup_count
>>>> always being set
>>>>
>>>>> On 04/01/12 11:38, Andrew Cooper wrote:
>>>>>> On 04/01/12 04:37, Liuyongan wrote:
>>>>>> Hi, all
>>>>>>
>>>>>>     I'm using xen-4.0 to do a test. And when I create a domain, it
>>>> failed due to create_irq() failure. As only 33 domains were
>>>> successfully created and destroyed before I got the continuous
>>>> failures, and the domain just before the failure was properly
>>>> destroyed(at least destroy_irq() was properly called, which will
>> clear
>>>> move_in_progress, according to the prink-message). So I can conclude
>>>> for certain that __assign_irq_vector failed due to
>> move_cleanup_count
>>>> always being set.
>>>>> Is it always 33 domains it takes to cause the problem, or does it
>>>> vary?
>>>>> If it varies, then I think you want this patch
>>>>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
>>>> which
>>>>> corrects the logic which works out which moved vectors it should
>>>> clean
>>>>> up.  Without it, stale irq numbers build up in the per-cpu
>> irq_vector
>>>>> tables leading to __assign_irq_vector failing with -ENOSPC as it
>> find
>>>>> find a vector to allocate.
>>>>   Yes, I've noticed this patch, as only 33 domains were created
>> before
>>>> the failures, so vectors of a given cpu should not have been used
>> up.
>>>> Besides, I got this problem after 143 domains were created another
>>>> time. But I could not repeat this problem manually as 4000+ domains
>>>> created successfully without this problem.
>>>>
>>>>>> //this is the normal case when create and destroy domain whose id
>> is
>>>> 31;
>>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>>>>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
>>>>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
>>>>>> (XEN) irq.c:223, destroy irq 77
>>>>>>
>>>>>> //domain id 32 is created and destroyed correctly also.
>>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>>>>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
>>>>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
>>>>>> (XEN) irq.c:223, destroy irq 77
>>>>>>
>>>>>> //all the subsequent domain creation failed, below lists only 3
>>>> times:
>>>>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
>>>>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
>>>>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
>>>>>>
>>>>>>      I think this might be a bug and might have fixed, so I
>> compare
>>>> my code with 4.1.2 and search the mail list for potential patches.
>>>>
>> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
>>>> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch
>> which
>>>> add locks in __assign_irq_vector. Can anybody explain why this lock
>> is
>>>> needed? Or is there a patch that might fix my bug? Thx.
>>>>> This patch fixes a problem where IOAPIC line level interrupts cease
>>>> for
>>>>> a while.  It has nothing to do with MSI interrupts.  (Also, there
>> are
>>>> no
>>>>> locks altered, and xen-4.0-testing seems to have gained an
>> additional
>>>>> hunk in hvm/vmx code unrelated to the original patch.)
>>>>>
>>>>>>     Addition message: my board is arch-x86, no domains left when
>>>> failed to create new ones, create_irq failure lasted one day until I
>>>> reboot the board, and the irq number allocated is used certainly for
>> a
>>>> msi dev.
>>>>>> Yong an Liu
>>>>>> 2012.1.4
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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

-- 
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 Jan 06 12:18:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:18:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8ke-0003xb-9d; Fri, 06 Jan 2012 12:18:28 +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 1Rj8kc-0003xW-VA
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:18:27 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1325852299!9302631!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQ2OTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12278 invoked from network); 6 Jan 2012 12:18:20 -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 Jan 2012 12:18:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320642000"; d="scan'208";a="20624055"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 07:18:18 -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, 6 Jan 2012
	07:18:18 -0500
Message-ID: <4F06E689.9030506@citrix.com>
Date: Fri, 6 Jan 2012 12:18:17 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Liuyongan <liuyongan@huawei.com>
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
	<4F06D454.1080608@citrix.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
In-Reply-To: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
X-Enigmail-Version: 1.1.2
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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 06/01/12 11:50, Liuyongan wrote:
>
>> -----Original Message-----
>> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
>> Sent: Friday, January 06, 2012 7:01 PM
>> To: Liuyongan
>> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
>> Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
>> always being set
>>
>> Could you please avoid top posing.
>>
>> On 06/01/12 06:04, Liuyongan wrote:
>>>    As only 33 domains were successfully created(and destroyed) before
>> the problem occurring,  there should be enough free IRQ  number and
>> vector number to allocate(suppose that irqs and vectors failed to
>> deallocate). And destroy_irq() will clear move_in_progress, so
>> move_cleanup_count must be setted?  Is this the case?
>>
>> Is it repeatably 33 domains, or was that a 1 off experiment?  Can you
>   No, it's not repeatable, this occurred 2 times, another one is after 152 domains.

Can you list all the failures you have seen with the number of domains? 
So far it seems that it has been 33 twice but many more some of the
time, which doesn't lend itself to saying "33 domains is a systematic
failure" for certain at the moment.

>> confirm exactly which version of Xen you are using, including changeset
>> if you know it?  Without knowing your hardware, it is hard to say if
>> there are actually enough free IRQs, although I do agree that what you
>> are currently seeing is buggy behavior.
>>
>> The per-cpu IDT functionality introduced in Xen-4.0 is fragile at the
>> best of times, and has had several bugfixes and tweaks to it which I am
>> not certain have actually found their way back to Xen-4.0.  Could you
>> try with Xen-4.1 and see if the problem persists?
>>
>> ~Andrew
>   As I could not make it re-occure in xen-4.0, trying xen-4.1 seems useless.
> I noticed a scenario:

I am confused.  Above, you say that the problem is repeatable, but here
you say it is not.

>    1) move_in_progress occure;
>    2) IPI IRQ_MOVE_CLEANUP_VECTOR interrupt is sent;
>    3) the irq is destroyed, so cfg->vector is cleared, and etc.;
>    4) IRQ_MOVE_CLEANUP_VECTOR irq is responded.
>  
>   In xen-4.1 , step 3, vector_irq of old_cpu_mask/old_domain is also reset, so in step 4) move_cleanup_count will failed to sub by one, and finally leading to create_irq failure(right?);
>
>   In xen-4.0, step 3, and in my code vector_irq is not reset(this is a bug as you'v mentioned),  I still could not figure out why 
> create_irq should failed.

The first point of debugging should be to see how create_irq is
failing.  Is it failing because of find_unassigned_irq() or because of
__assign_irq_vector().

Another piece of useful information would be what your guests are and
what they are trying to do with interrupts.  Are you using PCI passthrough?

~Andrew

>>>> -----Original Message-----
>>>> From: Liuyongan
>>>> Sent: Thursday, January 05, 2012 2:14 PM
>>>> To: Liuyongan; xen-devel@lists.xensource.com;
>>>> andrew.cooper3@citrix.com; keir@xen.org
>>>> Cc: Qianhuibin
>>>> Subject: RE: [xen-devel] create irq failed due to move_cleanup_count
>>>> always being set
>>>>
>>>>> On 04/01/12 11:38, Andrew Cooper wrote:
>>>>>> On 04/01/12 04:37, Liuyongan wrote:
>>>>>> Hi, all
>>>>>>
>>>>>>     I'm using xen-4.0 to do a test. And when I create a domain, it
>>>> failed due to create_irq() failure. As only 33 domains were
>>>> successfully created and destroyed before I got the continuous
>>>> failures, and the domain just before the failure was properly
>>>> destroyed(at least destroy_irq() was properly called, which will
>> clear
>>>> move_in_progress, according to the prink-message). So I can conclude
>>>> for certain that __assign_irq_vector failed due to
>> move_cleanup_count
>>>> always being set.
>>>>> Is it always 33 domains it takes to cause the problem, or does it
>>>> vary?
>>>>> If it varies, then I think you want this patch
>>>>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
>>>> which
>>>>> corrects the logic which works out which moved vectors it should
>>>> clean
>>>>> up.  Without it, stale irq numbers build up in the per-cpu
>> irq_vector
>>>>> tables leading to __assign_irq_vector failing with -ENOSPC as it
>> find
>>>>> find a vector to allocate.
>>>>   Yes, I've noticed this patch, as only 33 domains were created
>> before
>>>> the failures, so vectors of a given cpu should not have been used
>> up.
>>>> Besides, I got this problem after 143 domains were created another
>>>> time. But I could not repeat this problem manually as 4000+ domains
>>>> created successfully without this problem.
>>>>
>>>>>> //this is the normal case when create and destroy domain whose id
>> is
>>>> 31;
>>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>>>>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
>>>>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
>>>>>> (XEN) irq.c:223, destroy irq 77
>>>>>>
>>>>>> //domain id 32 is created and destroyed correctly also.
>>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
>>>>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
>>>>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
>>>>>> (XEN) irq.c:223, destroy irq 77
>>>>>>
>>>>>> //all the subsequent domain creation failed, below lists only 3
>>>> times:
>>>>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
>>>>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
>>>>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
>>>>>>
>>>>>>      I think this might be a bug and might have fixed, so I
>> compare
>>>> my code with 4.1.2 and search the mail list for potential patches.
>>>>
>> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
>>>> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch
>> which
>>>> add locks in __assign_irq_vector. Can anybody explain why this lock
>> is
>>>> needed? Or is there a patch that might fix my bug? Thx.
>>>>> This patch fixes a problem where IOAPIC line level interrupts cease
>>>> for
>>>>> a while.  It has nothing to do with MSI interrupts.  (Also, there
>> are
>>>> no
>>>>> locks altered, and xen-4.0-testing seems to have gained an
>> additional
>>>>> hunk in hvm/vmx code unrelated to the original patch.)
>>>>>
>>>>>>     Addition message: my board is arch-x86, no domains left when
>>>> failed to create new ones, create_irq failure lasted one day until I
>>>> reboot the board, and the irq number allocated is used certainly for
>> a
>>>> msi dev.
>>>>>> Yong an Liu
>>>>>> 2012.1.4
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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

-- 
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 Jan 06 12:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8m4-00040r-Pe; Fri, 06 Jan 2012 12:19:56 +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 1Rj8m2-00040W-Vn
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:19:55 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325852388!8003963!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31706 invoked from network); 6 Jan 2012 12:19:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 12:19:48 -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 q06CJLRb022904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 07:19:22 -0500
Received: from dragon.usersys.redhat.com (vpn-202-209.tlv.redhat.com
	[10.35.202.209])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q06CJIGm008044; Fri, 6 Jan 2012 07:19:19 -0500
Message-ID: <4F06E6C6.5080607@redhat.com>
Date: Fri, 06 Jan 2012 14:19:18 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
In-Reply-To: <4F05F09E.8030800@web.de>
X-Enigmail-Version: 1.3.4
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
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 01/05/2012 08:49 PM, Jan Kiszka wrote:
> To me this still sounds like a cirrus-only xen workaround that
> nevertheless spreads widely.

It is.

> Again, what speaks against migrating the information Xen needs before
> creating the machine or a single device? That would only introduce a
> generic concept of an (optional) "early", let's call it
> "accelerator-related" vmstate and would allow Xen to deal with all the
> specifics behind the curtain.
>

Adding more concepts, just to work around a bug (and this is really a
bug in the qemu/xen interface) makes it harder to refactor things later on.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8m4-00040r-Pe; Fri, 06 Jan 2012 12:19:56 +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 1Rj8m2-00040W-Vn
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:19:55 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1325852388!8003963!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31706 invoked from network); 6 Jan 2012 12:19:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 12:19:48 -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 q06CJLRb022904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 07:19:22 -0500
Received: from dragon.usersys.redhat.com (vpn-202-209.tlv.redhat.com
	[10.35.202.209])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q06CJIGm008044; Fri, 6 Jan 2012 07:19:19 -0500
Message-ID: <4F06E6C6.5080607@redhat.com>
Date: Fri, 06 Jan 2012 14:19:18 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
In-Reply-To: <4F05F09E.8030800@web.de>
X-Enigmail-Version: 1.3.4
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
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 01/05/2012 08:49 PM, Jan Kiszka wrote:
> To me this still sounds like a cirrus-only xen workaround that
> nevertheless spreads widely.

It is.

> Again, what speaks against migrating the information Xen needs before
> creating the machine or a single device? That would only introduce a
> generic concept of an (optional) "early", let's call it
> "accelerator-related" vmstate and would allow Xen to deal with all the
> specifics behind the curtain.
>

Adding more concepts, just to work around a bug (and this is really a
bug in the qemu/xen interface) makes it harder to refactor things later on.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:23:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12: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 1Rj8p7-0004BQ-DK; Fri, 06 Jan 2012 12:23:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1Rj8p5-0004B2-VU
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:23:04 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325852577!9903077!1
X-Originating-IP: [217.72.192.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyNyA9PiA1ODg1\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyNyA9PiA1ODg1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23684 invoked from network); 6 Jan 2012 12:22:57 -0000
Received: from fmmailgate02.web.de (HELO fmmailgate02.web.de) (217.72.192.227)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 12:22:57 -0000
Received: from moweb001.kundenserver.de (moweb001.kundenserver.de
	[172.19.20.114])
	by fmmailgate02.web.de (Postfix) with ESMTP id CE9891BF3DCB7
	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 13:22:56 +0100 (CET)
Received: from netbook.home ([187.105.25.94]) by smtp.web.de (mrweb001) with
	ESMTPA (Nemesis) id 0LcPhu-1SPJGs1Y8s-00jpXK;
	Fri, 06 Jan 2012 13:22:54 +0100
Message-ID: <4F06E789.6050509@web.de>
Date: Fri, 06 Jan 2012 10:22:33 -0200
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: Avi Kivity <avi@redhat.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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<4F06E6C6.5080607@redhat.com>
In-Reply-To: <4F06E6C6.5080607@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:dUJ4dhfbpvn8r+/MHZ1DdlY/BmtB4fiWCiOb041EGpW
	tzcZMUT/w/WLKZN02Wdf4wG2TxlKG0c5z/+ORMbk1317Cxph1Y
	87MQrvjFY9bZviW3MDlozbwjVc0d2tFPpWz1p4xy9GY/wN3j4j
	NotPdED1UILpmCvFjyrxPnJWZtHlhsUjTzbEFOfTepGY8hg8ZA
	T0IbttERRQalRCYIfUZnQ==
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: multipart/mixed; boundary="===============6434559708287490371=="
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)
--===============6434559708287490371==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigA286793C49D7C06177BA9609"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA286793C49D7C06177BA9609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2012-01-06 10:19, Avi Kivity wrote:
> On 01/05/2012 08:49 PM, Jan Kiszka wrote:
>> To me this still sounds like a cirrus-only xen workaround that
>> nevertheless spreads widely.
>=20
> It is.
>=20
>> Again, what speaks against migrating the information Xen needs before
>> creating the machine or a single device? That would only introduce a
>> generic concept of an (optional) "early", let's call it
>> "accelerator-related" vmstate and would allow Xen to deal with all the=

>> specifics behind the curtain.
>>
>=20
> Adding more concepts, just to work around a bug (and this is really a
> bug in the qemu/xen interface) makes it harder to refactor things later=
 on.

Well, it's at least only a single concept, one that could even be used
independently of Xen issues, while it appears to me like the other
proposal comes with multiple ones.

Jan


--------------enigA286793C49D7C06177BA9609
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.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8G54wACgkQitSsb3rl5xQNmgCbBoh2+6C+sQ3RB1ZV4a9TB7bR
SoYAn3t2QPxuja5CqwHVHmrgFW3CBu1w
=wu1y
-----END PGP SIGNATURE-----

--------------enigA286793C49D7C06177BA9609--


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

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

--===============6434559708287490371==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:23:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12: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 1Rj8p7-0004BQ-DK; Fri, 06 Jan 2012 12:23:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1Rj8p5-0004B2-VU
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:23:04 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1325852577!9903077!1
X-Originating-IP: [217.72.192.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyNyA9PiA1ODg1\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyNyA9PiA1ODg1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23684 invoked from network); 6 Jan 2012 12:22:57 -0000
Received: from fmmailgate02.web.de (HELO fmmailgate02.web.de) (217.72.192.227)
	by server-3.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 12:22:57 -0000
Received: from moweb001.kundenserver.de (moweb001.kundenserver.de
	[172.19.20.114])
	by fmmailgate02.web.de (Postfix) with ESMTP id CE9891BF3DCB7
	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 13:22:56 +0100 (CET)
Received: from netbook.home ([187.105.25.94]) by smtp.web.de (mrweb001) with
	ESMTPA (Nemesis) id 0LcPhu-1SPJGs1Y8s-00jpXK;
	Fri, 06 Jan 2012 13:22:54 +0100
Message-ID: <4F06E789.6050509@web.de>
Date: Fri, 06 Jan 2012 10:22:33 -0200
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: Avi Kivity <avi@redhat.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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<4F06E6C6.5080607@redhat.com>
In-Reply-To: <4F06E6C6.5080607@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:dUJ4dhfbpvn8r+/MHZ1DdlY/BmtB4fiWCiOb041EGpW
	tzcZMUT/w/WLKZN02Wdf4wG2TxlKG0c5z/+ORMbk1317Cxph1Y
	87MQrvjFY9bZviW3MDlozbwjVc0d2tFPpWz1p4xy9GY/wN3j4j
	NotPdED1UILpmCvFjyrxPnJWZtHlhsUjTzbEFOfTepGY8hg8ZA
	T0IbttERRQalRCYIfUZnQ==
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: multipart/mixed; boundary="===============6434559708287490371=="
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)
--===============6434559708287490371==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigA286793C49D7C06177BA9609"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA286793C49D7C06177BA9609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2012-01-06 10:19, Avi Kivity wrote:
> On 01/05/2012 08:49 PM, Jan Kiszka wrote:
>> To me this still sounds like a cirrus-only xen workaround that
>> nevertheless spreads widely.
>=20
> It is.
>=20
>> Again, what speaks against migrating the information Xen needs before
>> creating the machine or a single device? That would only introduce a
>> generic concept of an (optional) "early", let's call it
>> "accelerator-related" vmstate and would allow Xen to deal with all the=

>> specifics behind the curtain.
>>
>=20
> Adding more concepts, just to work around a bug (and this is really a
> bug in the qemu/xen interface) makes it harder to refactor things later=
 on.

Well, it's at least only a single concept, one that could even be used
independently of Xen issues, while it appears to me like the other
proposal comes with multiple ones.

Jan


--------------enigA286793C49D7C06177BA9609
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.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8G54wACgkQitSsb3rl5xQNmgCbBoh2+6C+sQ3RB1ZV4a9TB7bR
SoYAn3t2QPxuja5CqwHVHmrgFW3CBu1w
=wu1y
-----END PGP SIGNATURE-----

--------------enigA286793C49D7C06177BA9609--


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

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

--===============6434559708287490371==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:24:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8qR-0004JI-2z; Fri, 06 Jan 2012 12:24:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj8qP-0004IZ-Ow
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:24:25 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325852658!8050443!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzA2MTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1764 invoked from network); 6 Jan 2012 12:24:19 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-8.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 12:24:19 -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 q06COCA5005325;
	Fri, 6 Jan 2012 07:24:12 -0500
Date: Fri, 06 Jan 2012 07:24:12 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <a0f8cfee-aeee-4993-a433-4166d63a34e6@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <alpine.DEB.2.00.1201061051410.3150@kaball-desktop>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > Almost all of the things which dom0 needs (e.g. PCI device
> > > management
> > > etc) is also required by a domU with passthrough enabled so the
> > > savings
> > > are really very slight.
> > > 
> > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > > whatever xen_register_gsi (a couple of dozen lines of code) adds
> > > to
> > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > > anywhere else. What savings do you see in practice from disabling
> > > just
> > > this symbol?
> > 
> > I completely agree that the saving are near none. The savings,
> > however,
> > aren't the only reason to drive the change. It's actually the
> > symbol
> > name itself. Unfortunately configs can be perceived as a contract
> > of
> > support, i.e. if feature xyz is enabled in the distro's config,
> > then
> > the distributor must have selected, and therefore will support,
> > said
> > feature.
> > 
> > I didn't make this motivation clear in my initial post, because I
> > was
> > hoping to spare people some eye rolling.
> 
> I thought that in the kernel community we make decisions based on
> technical merits rather than "contracts of support".

Sorry.

> Given that disabling the symbol saves near to nothing, the logical
> thing
> to do is removing the symbol altogether.
> 

I thought of that too. If the symbol just goes away, then my
non-technical requirement will be met and the functionality will
stay. I consider that a bigger win actually. I didn't suggest it
though, since I've never done any dom0 development, nor had any
consideration for dom0 code needs of the future. With
anti-credentials like that, I'd guess it'd be tougher for me to sell
the need to remove it, than it is for me to just make it
configurable.

Drew

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:24:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:24:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj8qR-0004JI-2z; Fri, 06 Jan 2012 12:24:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj8qP-0004IZ-Ow
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:24:25 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325852658!8050443!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzA2MTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1764 invoked from network); 6 Jan 2012 12:24:19 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-8.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 12:24:19 -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 q06COCA5005325;
	Fri, 6 Jan 2012 07:24:12 -0500
Date: Fri, 06 Jan 2012 07:24:12 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <a0f8cfee-aeee-4993-a433-4166d63a34e6@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <alpine.DEB.2.00.1201061051410.3150@kaball-desktop>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > Almost all of the things which dom0 needs (e.g. PCI device
> > > management
> > > etc) is also required by a domU with passthrough enabled so the
> > > savings
> > > are really very slight.
> > > 
> > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > > whatever xen_register_gsi (a couple of dozen lines of code) adds
> > > to
> > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > > anywhere else. What savings do you see in practice from disabling
> > > just
> > > this symbol?
> > 
> > I completely agree that the saving are near none. The savings,
> > however,
> > aren't the only reason to drive the change. It's actually the
> > symbol
> > name itself. Unfortunately configs can be perceived as a contract
> > of
> > support, i.e. if feature xyz is enabled in the distro's config,
> > then
> > the distributor must have selected, and therefore will support,
> > said
> > feature.
> > 
> > I didn't make this motivation clear in my initial post, because I
> > was
> > hoping to spare people some eye rolling.
> 
> I thought that in the kernel community we make decisions based on
> technical merits rather than "contracts of support".

Sorry.

> Given that disabling the symbol saves near to nothing, the logical
> thing
> to do is removing the symbol altogether.
> 

I thought of that too. If the symbol just goes away, then my
non-technical requirement will be met and the functionality will
stay. I consider that a bigger win actually. I didn't suggest it
though, since I've never done any dom0 development, nor had any
consideration for dom0 code needs of the future. With
anti-credentials like that, I'd guess it'd be tougher for me to sell
the need to remove it, than it is for me to just make it
configurable.

Drew

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:36:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj91w-0004gl-BN; Fri, 06 Jan 2012 12:36:20 +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 1Rj91v-0004ge-Pk
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:36:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325853373!9346537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11867 invoked from network); 6 Jan 2012 12:36:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 12:36:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9863722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 12:35: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, 6 Jan 2012 12:35:48 +0000
Date: Fri, 6 Jan 2012 12:35:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <a0f8cfee-aeee-4993-a433-4166d63a34e6@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.DEB.2.00.1201061231150.3150@kaball-desktop>
References: <a0f8cfee-aeee-4993-a433-4166d63a34e6@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
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 <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Andrew Jones wrote:
> ----- Original Message -----
> > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > > Almost all of the things which dom0 needs (e.g. PCI device
> > > > management
> > > > etc) is also required by a domU with passthrough enabled so the
> > > > savings
> > > > are really very slight.
> > > > 
> > > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > > > whatever xen_register_gsi (a couple of dozen lines of code) adds
> > > > to
> > > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > > > anywhere else. What savings do you see in practice from disabling
> > > > just
> > > > this symbol?
> > > 
> > > I completely agree that the saving are near none. The savings,
> > > however,
> > > aren't the only reason to drive the change. It's actually the
> > > symbol
> > > name itself. Unfortunately configs can be perceived as a contract
> > > of
> > > support, i.e. if feature xyz is enabled in the distro's config,
> > > then
> > > the distributor must have selected, and therefore will support,
> > > said
> > > feature.
> > > 
> > > I didn't make this motivation clear in my initial post, because I
> > > was
> > > hoping to spare people some eye rolling.
> > 
> > I thought that in the kernel community we make decisions based on
> > technical merits rather than "contracts of support".
> 
> Sorry.
> 
> > Given that disabling the symbol saves near to nothing, the logical
> > thing
> > to do is removing the symbol altogether.
> > 
> 
> I thought of that too. If the symbol just goes away, then my
> non-technical requirement will be met and the functionality will
> stay. I consider that a bigger win actually. I didn't suggest it
> though, since I've never done any dom0 development, nor had any
> consideration for dom0 code needs of the future. With
> anti-credentials like that, I'd guess it'd be tougher for me to sell
> the need to remove it, than it is for me to just make it
> configurable.
 
The reason to remove is easy: it is already a silent option and
disabling it saves almost nothing.
I think that removing it should be easy enough but if you don't
feel confident doing it, I can come up with a patch.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:36:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj91w-0004gl-BN; Fri, 06 Jan 2012 12:36:20 +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 1Rj91v-0004ge-Pk
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:36:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325853373!9346537!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11867 invoked from network); 6 Jan 2012 12:36:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 12:36:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9863722"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 12:35: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, 6 Jan 2012 12:35:48 +0000
Date: Fri, 6 Jan 2012 12:35:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <a0f8cfee-aeee-4993-a433-4166d63a34e6@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.DEB.2.00.1201061231150.3150@kaball-desktop>
References: <a0f8cfee-aeee-4993-a433-4166d63a34e6@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
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 <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Andrew Jones wrote:
> ----- Original Message -----
> > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > > Almost all of the things which dom0 needs (e.g. PCI device
> > > > management
> > > > etc) is also required by a domU with passthrough enabled so the
> > > > savings
> > > > are really very slight.
> > > > 
> > > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o plus
> > > > whatever xen_register_gsi (a couple of dozen lines of code) adds
> > > > to
> > > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being used
> > > > anywhere else. What savings do you see in practice from disabling
> > > > just
> > > > this symbol?
> > > 
> > > I completely agree that the saving are near none. The savings,
> > > however,
> > > aren't the only reason to drive the change. It's actually the
> > > symbol
> > > name itself. Unfortunately configs can be perceived as a contract
> > > of
> > > support, i.e. if feature xyz is enabled in the distro's config,
> > > then
> > > the distributor must have selected, and therefore will support,
> > > said
> > > feature.
> > > 
> > > I didn't make this motivation clear in my initial post, because I
> > > was
> > > hoping to spare people some eye rolling.
> > 
> > I thought that in the kernel community we make decisions based on
> > technical merits rather than "contracts of support".
> 
> Sorry.
> 
> > Given that disabling the symbol saves near to nothing, the logical
> > thing
> > to do is removing the symbol altogether.
> > 
> 
> I thought of that too. If the symbol just goes away, then my
> non-technical requirement will be met and the functionality will
> stay. I consider that a bigger win actually. I didn't suggest it
> though, since I've never done any dom0 development, nor had any
> consideration for dom0 code needs of the future. With
> anti-credentials like that, I'd guess it'd be tougher for me to sell
> the need to remove it, than it is for me to just make it
> configurable.
 
The reason to remove is easy: it is already a silent option and
disabling it saves almost nothing.
I think that removing it should be easy enough but if you don't
feel confident doing it, I can come up with a patch.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:44:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj992-0004qQ-9y; Fri, 06 Jan 2012 12:43:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj991-0004qL-3z
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:43:39 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1325853812!9848727!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjMzOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7813 invoked from network); 6 Jan 2012 12:43:32 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-12.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 12:43:32 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q06ChQ7R003088;
	Fri, 6 Jan 2012 07:43:26 -0500
Date: Fri, 06 Jan 2012 07:43:26 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <c802fb58-5067-4075-80b3-ca8004005364@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <alpine.DEB.2.00.1201061231150.3150@kaball-desktop>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > ----- Original Message -----
> > > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > > > Almost all of the things which dom0 needs (e.g. PCI device
> > > > > management
> > > > > etc) is also required by a domU with passthrough enabled so
> > > > > the
> > > > > savings
> > > > > are really very slight.
> > > > > 
> > > > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o
> > > > > plus
> > > > > whatever xen_register_gsi (a couple of dozen lines of code)
> > > > > adds
> > > > > to
> > > > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being
> > > > > used
> > > > > anywhere else. What savings do you see in practice from
> > > > > disabling
> > > > > just
> > > > > this symbol?
> > > > 
> > > > I completely agree that the saving are near none. The savings,
> > > > however,
> > > > aren't the only reason to drive the change. It's actually the
> > > > symbol
> > > > name itself. Unfortunately configs can be perceived as a
> > > > contract
> > > > of
> > > > support, i.e. if feature xyz is enabled in the distro's config,
> > > > then
> > > > the distributor must have selected, and therefore will support,
> > > > said
> > > > feature.
> > > > 
> > > > I didn't make this motivation clear in my initial post, because
> > > > I
> > > > was
> > > > hoping to spare people some eye rolling.
> > > 
> > > I thought that in the kernel community we make decisions based on
> > > technical merits rather than "contracts of support".
> > 
> > Sorry.
> > 
> > > Given that disabling the symbol saves near to nothing, the
> > > logical
> > > thing
> > > to do is removing the symbol altogether.
> > > 
> > 
> > I thought of that too. If the symbol just goes away, then my
> > non-technical requirement will be met and the functionality will
> > stay. I consider that a bigger win actually. I didn't suggest it
> > though, since I've never done any dom0 development, nor had any
> > consideration for dom0 code needs of the future. With
> > anti-credentials like that, I'd guess it'd be tougher for me to
> > sell
> > the need to remove it, than it is for me to just make it
> > configurable.
>  
> The reason to remove is easy: it is already a silent option and
> disabling it saves almost nothing.
> I think that removing it should be easy enough but if you don't
> feel confident doing it, I can come up with a patch.
> 

I'll write the patch. It's not the patch I thought would be hard to
do (although I'll only be posting it compile tested, as I don't
have an environment where I can test it set up). What I thought would
be difficult is the justification. However, considering you're
advocating it, I guess I'm good there too.

Drew

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:44:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj992-0004qQ-9y; Fri, 06 Jan 2012 12:43:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rj991-0004qL-3z
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:43:39 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1325853812!9848727!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjMzOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7813 invoked from network); 6 Jan 2012 12:43:32 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-12.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 12:43:32 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q06ChQ7R003088;
	Fri, 6 Jan 2012 07:43:26 -0500
Date: Fri, 06 Jan 2012 07:43:26 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <c802fb58-5067-4075-80b3-ca8004005364@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <alpine.DEB.2.00.1201061231150.3150@kaball-desktop>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	konrad wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > ----- Original Message -----
> > > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > > > Almost all of the things which dom0 needs (e.g. PCI device
> > > > > management
> > > > > etc) is also required by a domU with passthrough enabled so
> > > > > the
> > > > > savings
> > > > > are really very slight.
> > > > > 
> > > > > We are talking less than 1k of code AFAICT, 319 bytes for
> > > > > arch/x86/xen/vga.o and 573 for drivers/xen/xenfs/xenstored.o
> > > > > plus
> > > > > whatever xen_register_gsi (a couple of dozen lines of code)
> > > > > adds
> > > > > to
> > > > > arch/x86/pci/xen.o. grep doesn't show CONFIG_XEN_DOM0 being
> > > > > used
> > > > > anywhere else. What savings do you see in practice from
> > > > > disabling
> > > > > just
> > > > > this symbol?
> > > > 
> > > > I completely agree that the saving are near none. The savings,
> > > > however,
> > > > aren't the only reason to drive the change. It's actually the
> > > > symbol
> > > > name itself. Unfortunately configs can be perceived as a
> > > > contract
> > > > of
> > > > support, i.e. if feature xyz is enabled in the distro's config,
> > > > then
> > > > the distributor must have selected, and therefore will support,
> > > > said
> > > > feature.
> > > > 
> > > > I didn't make this motivation clear in my initial post, because
> > > > I
> > > > was
> > > > hoping to spare people some eye rolling.
> > > 
> > > I thought that in the kernel community we make decisions based on
> > > technical merits rather than "contracts of support".
> > 
> > Sorry.
> > 
> > > Given that disabling the symbol saves near to nothing, the
> > > logical
> > > thing
> > > to do is removing the symbol altogether.
> > > 
> > 
> > I thought of that too. If the symbol just goes away, then my
> > non-technical requirement will be met and the functionality will
> > stay. I consider that a bigger win actually. I didn't suggest it
> > though, since I've never done any dom0 development, nor had any
> > consideration for dom0 code needs of the future. With
> > anti-credentials like that, I'd guess it'd be tougher for me to
> > sell
> > the need to remove it, than it is for me to just make it
> > configurable.
>  
> The reason to remove is easy: it is already a silent option and
> disabling it saves almost nothing.
> I think that removing it should be easy enough but if you don't
> feel confident doing it, I can come up with a patch.
> 

I'll write the patch. It's not the patch I thought would be hard to
do (although I'll only be posting it compile tested, as I don't
have an environment where I can test it set up). What I thought would
be difficult is the justification. However, considering you're
advocating it, I guess I'm good there too.

Drew

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:44:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 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 1Rj99v-0004sv-OC; Fri, 06 Jan 2012 12:44: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 1Rj99u-0004se-5V
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:44:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325853866!9823451!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 13897 invoked from network); 6 Jan 2012 12:44:27 -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; 6 Jan 2012 12:44:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 12:44:26 +0000
Message-Id: <4F06FAF1020000780006AD0A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 12:45:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <4EF1A0F702000078000694AC@nat28.tlf.novell.com>
In-Reply-To: <4EF1A0F702000078000694AC@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Ping: [PATCH] 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>
Content-Type: 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 - if it's not you to ack this (or otherwise comment on it), who would
be the one?

Thanks, Jan

>>> On 21.12.11 at 09:03, "Jan Beulich" <JBeulich@suse.com> wrote:
> - 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 = 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
>  
>      ret = xc_pm_get_max_cx(xc_handle, cpuid, &max_cx_num);
>      if ( ret )
> -        return errno;
> +        return -errno;
>  
>      if ( !cxstat )
>          return -EINVAL;
> @@ -135,15 +135,14 @@ static int get_cxstat_by_cpuid(xc_interf
>      ret = xc_pm_get_cxstat(xc_handle, cpuid, cxstat);
>      if( ret )
>      {
> -        int temp = errno;
> +        ret = -errno;
>          free(cxstat->triggers);
>          free(cxstat->residencies);
>          cxstat->triggers = NULL;
>          cxstat->residencies = NULL;
> -        return temp;
>      }
>  
> -    return 0;
> +    return ret;
>  }
>  
>  static int show_max_cstate(xc_interface *xc_handle)
> @@ -214,14 +213,13 @@ static void print_pxstat(int cpuid, stru
>      for ( i = 0; i < pxstat->total; i++ )
>      {
>          if ( pxstat->cur == 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
>  
>      ret = xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);
>      if ( ret )
> -        return errno;
> +        return -errno;
>  
>      if ( !pxstat)
>          return -EINVAL;
> @@ -254,15 +252,14 @@ static int get_pxstat_by_cpuid(xc_interf
>      ret = xc_pm_get_pxstat(xc_handle, cpuid, pxstat);
>      if( ret )
>      {
> -        int temp = errno;
> +        ret = -errno;
>          free(pxstat->trans_pt);
>          free(pxstat->pt);
>          pxstat->trans_pt = NULL;
>          pxstat->pt = NULL;
> -        return temp;
>      }
>  
> -    return 0;
> +    return ret;
>  }
>  
>  /* show cpu actual average freq information on CPU cpuid */
> @@ -272,11 +269,9 @@ static int get_avgfreq_by_cpuid(xc_inter
>  
>      ret = xc_get_cpufreq_avgfreq(xc_handle, cpuid, avgfreq);
>      if ( ret )
> -    {
> -        return errno;
> -    }
> +        ret = -errno;
>  
> -    return 0;
> +    return ret;
>  }
>  
>  static int show_pxstat_by_cpuid(xc_interface *xc_handle, int cpuid)
> @@ -325,7 +320,7 @@ static uint64_t *sum, *sum_cx, *sum_px;
>  
>  static void signal_int_handler(int signo)
>  {
> -    int i, j, k, ret;
> +    int i, j, k;
>      struct timeval tv;
>      int cx_cap = 0, px_cap = 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]);
>      }
>  
>      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 = MAX_NR_CPU - 1;
>  
> -    ret = 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] == socket_ids[i] )
>                          break;
>                  }
> -                printf("Socket %d\n", socket_ids[i]);
> +                printf("\nSocket %d\n", socket_ids[i]);
>                  res = 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 = 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]);
>      }
>  
>      /* some clean up and then exits */
> @@ -542,23 +535,23 @@ void start_gather_func(int argc, char *a
>      }
>      usec_start = tv.tv_sec * 1000000UL + tv.tv_usec;
>  
> -    sum = malloc(sizeof(uint64_t) * 2 * max_cpu_nr);
> +    sum = calloc(2 * max_cpu_nr, sizeof(*sum));
>      if ( sum == NULL )
>          return ;
> -    cxstat = malloc(sizeof(struct xc_cx_stat) * 2 * max_cpu_nr);
> +    cxstat = calloc(2 * max_cpu_nr, sizeof(*cxstat));
>      if ( cxstat == NULL )
>      {
>          free(sum);
>          return ;
>      }
> -    pxstat = malloc(sizeof(struct xc_px_stat) * 2 * max_cpu_nr);
> +    pxstat = calloc(2 * max_cpu_nr, sizeof(*pxstat));
>      if ( pxstat == NULL )
>      {
>          free(sum);
>          free(cxstat);
>          return ;
>      }
> -    avgfreq = malloc(sizeof(int) * max_cpu_nr);
> +    avgfreq = calloc(max_cpu_nr, sizeof(*avgfreq));
>      if ( avgfreq == 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 = sum;
>      sum_px = sum + max_cpu_nr;
>      cxstat_start = cxstat;



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:44:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 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 1Rj99v-0004sv-OC; Fri, 06 Jan 2012 12:44: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 1Rj99u-0004se-5V
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:44:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1325853866!9823451!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 13897 invoked from network); 6 Jan 2012 12:44:27 -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; 6 Jan 2012 12:44:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 12:44:26 +0000
Message-Id: <4F06FAF1020000780006AD0A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 12:45:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <4EF1A0F702000078000694AC@nat28.tlf.novell.com>
In-Reply-To: <4EF1A0F702000078000694AC@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Ping: [PATCH] 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>
Content-Type: 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 - if it's not you to ack this (or otherwise comment on it), who would
be the one?

Thanks, Jan

>>> On 21.12.11 at 09:03, "Jan Beulich" <JBeulich@suse.com> wrote:
> - 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 = 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
>  
>      ret = xc_pm_get_max_cx(xc_handle, cpuid, &max_cx_num);
>      if ( ret )
> -        return errno;
> +        return -errno;
>  
>      if ( !cxstat )
>          return -EINVAL;
> @@ -135,15 +135,14 @@ static int get_cxstat_by_cpuid(xc_interf
>      ret = xc_pm_get_cxstat(xc_handle, cpuid, cxstat);
>      if( ret )
>      {
> -        int temp = errno;
> +        ret = -errno;
>          free(cxstat->triggers);
>          free(cxstat->residencies);
>          cxstat->triggers = NULL;
>          cxstat->residencies = NULL;
> -        return temp;
>      }
>  
> -    return 0;
> +    return ret;
>  }
>  
>  static int show_max_cstate(xc_interface *xc_handle)
> @@ -214,14 +213,13 @@ static void print_pxstat(int cpuid, stru
>      for ( i = 0; i < pxstat->total; i++ )
>      {
>          if ( pxstat->cur == 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
>  
>      ret = xc_pm_get_max_px(xc_handle, cpuid, &max_px_num);
>      if ( ret )
> -        return errno;
> +        return -errno;
>  
>      if ( !pxstat)
>          return -EINVAL;
> @@ -254,15 +252,14 @@ static int get_pxstat_by_cpuid(xc_interf
>      ret = xc_pm_get_pxstat(xc_handle, cpuid, pxstat);
>      if( ret )
>      {
> -        int temp = errno;
> +        ret = -errno;
>          free(pxstat->trans_pt);
>          free(pxstat->pt);
>          pxstat->trans_pt = NULL;
>          pxstat->pt = NULL;
> -        return temp;
>      }
>  
> -    return 0;
> +    return ret;
>  }
>  
>  /* show cpu actual average freq information on CPU cpuid */
> @@ -272,11 +269,9 @@ static int get_avgfreq_by_cpuid(xc_inter
>  
>      ret = xc_get_cpufreq_avgfreq(xc_handle, cpuid, avgfreq);
>      if ( ret )
> -    {
> -        return errno;
> -    }
> +        ret = -errno;
>  
> -    return 0;
> +    return ret;
>  }
>  
>  static int show_pxstat_by_cpuid(xc_interface *xc_handle, int cpuid)
> @@ -325,7 +320,7 @@ static uint64_t *sum, *sum_cx, *sum_px;
>  
>  static void signal_int_handler(int signo)
>  {
> -    int i, j, k, ret;
> +    int i, j, k;
>      struct timeval tv;
>      int cx_cap = 0, px_cap = 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]);
>      }
>  
>      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 = MAX_NR_CPU - 1;
>  
> -    ret = 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] == socket_ids[i] )
>                          break;
>                  }
> -                printf("Socket %d\n", socket_ids[i]);
> +                printf("\nSocket %d\n", socket_ids[i]);
>                  res = 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 = 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]);
>      }
>  
>      /* some clean up and then exits */
> @@ -542,23 +535,23 @@ void start_gather_func(int argc, char *a
>      }
>      usec_start = tv.tv_sec * 1000000UL + tv.tv_usec;
>  
> -    sum = malloc(sizeof(uint64_t) * 2 * max_cpu_nr);
> +    sum = calloc(2 * max_cpu_nr, sizeof(*sum));
>      if ( sum == NULL )
>          return ;
> -    cxstat = malloc(sizeof(struct xc_cx_stat) * 2 * max_cpu_nr);
> +    cxstat = calloc(2 * max_cpu_nr, sizeof(*cxstat));
>      if ( cxstat == NULL )
>      {
>          free(sum);
>          return ;
>      }
> -    pxstat = malloc(sizeof(struct xc_px_stat) * 2 * max_cpu_nr);
> +    pxstat = calloc(2 * max_cpu_nr, sizeof(*pxstat));
>      if ( pxstat == NULL )
>      {
>          free(sum);
>          free(cxstat);
>          return ;
>      }
> -    avgfreq = malloc(sizeof(int) * max_cpu_nr);
> +    avgfreq = calloc(max_cpu_nr, sizeof(*avgfreq));
>      if ( avgfreq == 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 = sum;
>      sum_px = sum + max_cpu_nr;
>      cxstat_start = cxstat;



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:47:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12: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 1Rj9Cp-00054F-BR; Fri, 06 Jan 2012 12:47:35 +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 1Rj9Co-00053w-SW
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:47:35 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325854048!9837081!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24430 invoked from network); 6 Jan 2012 12:47:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 12:47:28 -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 q06ClObE012780
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 07:47:24 -0500
Received: from dragon.usersys.redhat.com (vpn-202-209.tlv.redhat.com
	[10.35.202.209])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q06ClLPS028293; Fri, 6 Jan 2012 07:47:22 -0500
Message-ID: <4F06ED57.2000909@redhat.com>
Date: Fri, 06 Jan 2012 14:47:19 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<4F06E6C6.5080607@redhat.com> <4F06E789.6050509@web.de>
In-Reply-To: <4F06E789.6050509@web.de>
X-Enigmail-Version: 1.3.4
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
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 01/06/2012 02:22 PM, Jan Kiszka wrote:
> > 
> > Adding more concepts, just to work around a bug (and this is really a
> > bug in the qemu/xen interface) makes it harder to refactor things later on.
>
> Well, it's at least only a single concept, one that could even be used
> independently of Xen issues,

If it has other uses, sure, I'm all for it.

>  while it appears to me like the other
> proposal comes with multiple ones.
>

The other proposal is a hack, but it's doesn't introduce new concepts.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:47:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12: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 1Rj9Cp-00054F-BR; Fri, 06 Jan 2012 12:47:35 +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 1Rj9Co-00053w-SW
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:47:35 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1325854048!9837081!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24430 invoked from network); 6 Jan 2012 12:47:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 12:47:28 -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 q06ClObE012780
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 07:47:24 -0500
Received: from dragon.usersys.redhat.com (vpn-202-209.tlv.redhat.com
	[10.35.202.209])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q06ClLPS028293; Fri, 6 Jan 2012 07:47:22 -0500
Message-ID: <4F06ED57.2000909@redhat.com>
Date: Fri, 06 Jan 2012 14:47:19 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<4F06E6C6.5080607@redhat.com> <4F06E789.6050509@web.de>
In-Reply-To: <4F06E789.6050509@web.de>
X-Enigmail-Version: 1.3.4
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
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 01/06/2012 02:22 PM, Jan Kiszka wrote:
> > 
> > Adding more concepts, just to work around a bug (and this is really a
> > bug in the qemu/xen interface) makes it harder to refactor things later on.
>
> Well, it's at least only a single concept, one that could even be used
> independently of Xen issues,

If it has other uses, sure, I'm all for it.

>  while it appears to me like the other
> proposal comes with multiple ones.
>

The other proposal is a hack, but it's doesn't introduce new concepts.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:51:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj9Fy-0005FV-Vj; Fri, 06 Jan 2012 12:50: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 1Rj9Fy-0005Ez-4o
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:50:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325854242!9384485!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 2100 invoked from network); 6 Jan 2012 12:50:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 12:50:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 12:50:42 +0000
Message-Id: <4F06FC6A020000780006AD14@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 12:51:38 +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="=__Part85ABC14A.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/scsiback: fix initialization error
	paths
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

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

scsiback_interface_exit() must not be called upon failure of
scsiback_interface_init().

Similarly, scsiback_xenbus_unregister() shouldn't be called when
scsiback_xenbus_init() failed. With this reference to it removed, the
function can be marked __exit (and its initialization counterpart
should have been __init from the beginning).

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

--- a/drivers/xen/scsiback/scsiback.c
+++ b/drivers/xen/scsiback/scsiback.c
@@ -700,7 +700,7 @@ static int __init scsiback_init(void)
 		pending_grant_handles[i] =3D SCSIBACK_INVALID_HANDLE;
=20
 	if (scsiback_interface_init() < 0)
-		goto out_of_kmem;
+		goto out_of_memory;
=20
 	INIT_LIST_HEAD(&pending_free);
=20
@@ -708,15 +708,13 @@ static int __init scsiback_init(void)
 		list_add_tail(&pending_reqs[i].free_list, &pending_free);
=20
 	if (scsiback_xenbus_init())
-		goto out_of_xenbus;
+		goto out_interface;
=20
 	scsiback_emulation_init();
=20
 	return 0;
=20
-out_of_xenbus:
-	scsiback_xenbus_unregister();
-out_of_kmem:
+out_interface:
 	scsiback_interface_exit();
 out_of_memory:
 	kfree(pending_reqs);
--- a/drivers/xen/scsiback/xenbus.c
+++ b/drivers/xen/scsiback/xenbus.c
@@ -363,12 +363,12 @@ static DEFINE_XENBUS_DRIVER(scsiback, ,
 	.otherend_changed	=3D scsiback_frontend_changed
 );
=20
-int scsiback_xenbus_init(void)
+int __init scsiback_xenbus_init(void)
 {
 	return xenbus_register_backend(&scsiback_driver);
 }
=20
-void scsiback_xenbus_unregister(void)
+void __exit scsiback_xenbus_unregister(void)
 {
 	xenbus_unregister_driver(&scsiback_driver);
 }




--=__Part85ABC14A.0__=
Content-Type: text/plain; name="xen-scsiback-init-error-paths.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-scsiback-init-error-paths.patch"

scsiback: fix initialization error paths=0A=0Ascsiback_interface_exit() =
must not be called upon failure of=0Ascsiback_interface_init().=0A=0ASimila=
rly, scsiback_xenbus_unregister() shouldn't be called when=0Ascsiback_xenbu=
s_init() failed. With this reference to it removed, the=0Afunction can be =
marked __exit (and its initialization counterpart=0Ashould have been =
__init from the beginning).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.=
com>=0A=0A--- a/drivers/xen/scsiback/scsiback.c=0A+++ b/drivers/xen/scsibac=
k/scsiback.c=0A@@ -700,7 +700,7 @@ static int __init scsiback_init(void)=0A=
 		pending_grant_handles[i] =3D SCSIBACK_INVALID_HANDLE;=0A =
=0A 	if (scsiback_interface_init() < 0)=0A-		goto out_of_kmem;=
=0A+		goto out_of_memory;=0A =0A 	INIT_LIST_HEAD(&pending_fre=
e);=0A =0A@@ -708,15 +708,13 @@ static int __init scsiback_init(void)=0A 	=
	list_add_tail(&pending_reqs[i].free_list, &pending_free);=0A =0A 	=
if (scsiback_xenbus_init())=0A-		goto out_of_xenbus;=0A+		=
goto out_interface;=0A =0A 	scsiback_emulation_init();=0A =0A 	=
return 0;=0A =0A-out_of_xenbus:=0A-	scsiback_xenbus_unregister();=0A-ou=
t_of_kmem:=0A+out_interface:=0A 	scsiback_interface_exit();=0A =
out_of_memory:=0A 	kfree(pending_reqs);=0A--- a/drivers/xen/scsiback/x=
enbus.c=0A+++ b/drivers/xen/scsiback/xenbus.c=0A@@ -363,12 +363,12 @@ =
static DEFINE_XENBUS_DRIVER(scsiback, ,=0A 	.otherend_changed	=
=3D scsiback_frontend_changed=0A );=0A =0A-int scsiback_xenbus_init(void)=
=0A+int __init scsiback_xenbus_init(void)=0A {=0A 	return xenbus_regis=
ter_backend(&scsiback_driver);=0A }=0A =0A-void scsiback_xenbus_unregister(=
void)=0A+void __exit scsiback_xenbus_unregister(void)=0A {=0A 	xenbus_unre=
gister_driver(&scsiback_driver);=0A }=0A
--=__Part85ABC14A.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

--=__Part85ABC14A.0__=--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 12:51:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 12:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj9Fy-0005FV-Vj; Fri, 06 Jan 2012 12:50: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 1Rj9Fy-0005Ez-4o
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 12:50:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325854242!9384485!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 2100 invoked from network); 6 Jan 2012 12:50:43 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 12:50:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 12:50:42 +0000
Message-Id: <4F06FC6A020000780006AD14@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 12:51:38 +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="=__Part85ABC14A.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/scsiback: fix initialization error
	paths
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

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

scsiback_interface_exit() must not be called upon failure of
scsiback_interface_init().

Similarly, scsiback_xenbus_unregister() shouldn't be called when
scsiback_xenbus_init() failed. With this reference to it removed, the
function can be marked __exit (and its initialization counterpart
should have been __init from the beginning).

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

--- a/drivers/xen/scsiback/scsiback.c
+++ b/drivers/xen/scsiback/scsiback.c
@@ -700,7 +700,7 @@ static int __init scsiback_init(void)
 		pending_grant_handles[i] =3D SCSIBACK_INVALID_HANDLE;
=20
 	if (scsiback_interface_init() < 0)
-		goto out_of_kmem;
+		goto out_of_memory;
=20
 	INIT_LIST_HEAD(&pending_free);
=20
@@ -708,15 +708,13 @@ static int __init scsiback_init(void)
 		list_add_tail(&pending_reqs[i].free_list, &pending_free);
=20
 	if (scsiback_xenbus_init())
-		goto out_of_xenbus;
+		goto out_interface;
=20
 	scsiback_emulation_init();
=20
 	return 0;
=20
-out_of_xenbus:
-	scsiback_xenbus_unregister();
-out_of_kmem:
+out_interface:
 	scsiback_interface_exit();
 out_of_memory:
 	kfree(pending_reqs);
--- a/drivers/xen/scsiback/xenbus.c
+++ b/drivers/xen/scsiback/xenbus.c
@@ -363,12 +363,12 @@ static DEFINE_XENBUS_DRIVER(scsiback, ,
 	.otherend_changed	=3D scsiback_frontend_changed
 );
=20
-int scsiback_xenbus_init(void)
+int __init scsiback_xenbus_init(void)
 {
 	return xenbus_register_backend(&scsiback_driver);
 }
=20
-void scsiback_xenbus_unregister(void)
+void __exit scsiback_xenbus_unregister(void)
 {
 	xenbus_unregister_driver(&scsiback_driver);
 }




--=__Part85ABC14A.0__=
Content-Type: text/plain; name="xen-scsiback-init-error-paths.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-scsiback-init-error-paths.patch"

scsiback: fix initialization error paths=0A=0Ascsiback_interface_exit() =
must not be called upon failure of=0Ascsiback_interface_init().=0A=0ASimila=
rly, scsiback_xenbus_unregister() shouldn't be called when=0Ascsiback_xenbu=
s_init() failed. With this reference to it removed, the=0Afunction can be =
marked __exit (and its initialization counterpart=0Ashould have been =
__init from the beginning).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.=
com>=0A=0A--- a/drivers/xen/scsiback/scsiback.c=0A+++ b/drivers/xen/scsibac=
k/scsiback.c=0A@@ -700,7 +700,7 @@ static int __init scsiback_init(void)=0A=
 		pending_grant_handles[i] =3D SCSIBACK_INVALID_HANDLE;=0A =
=0A 	if (scsiback_interface_init() < 0)=0A-		goto out_of_kmem;=
=0A+		goto out_of_memory;=0A =0A 	INIT_LIST_HEAD(&pending_fre=
e);=0A =0A@@ -708,15 +708,13 @@ static int __init scsiback_init(void)=0A 	=
	list_add_tail(&pending_reqs[i].free_list, &pending_free);=0A =0A 	=
if (scsiback_xenbus_init())=0A-		goto out_of_xenbus;=0A+		=
goto out_interface;=0A =0A 	scsiback_emulation_init();=0A =0A 	=
return 0;=0A =0A-out_of_xenbus:=0A-	scsiback_xenbus_unregister();=0A-ou=
t_of_kmem:=0A+out_interface:=0A 	scsiback_interface_exit();=0A =
out_of_memory:=0A 	kfree(pending_reqs);=0A--- a/drivers/xen/scsiback/x=
enbus.c=0A+++ b/drivers/xen/scsiback/xenbus.c=0A@@ -363,12 +363,12 @@ =
static DEFINE_XENBUS_DRIVER(scsiback, ,=0A 	.otherend_changed	=
=3D scsiback_frontend_changed=0A );=0A =0A-int scsiback_xenbus_init(void)=
=0A+int __init scsiback_xenbus_init(void)=0A {=0A 	return xenbus_regis=
ter_backend(&scsiback_driver);=0A }=0A =0A-void scsiback_xenbus_unregister(=
void)=0A+void __exit scsiback_xenbus_unregister(void)=0A {=0A 	xenbus_unre=
gister_driver(&scsiback_driver);=0A }=0A
--=__Part85ABC14A.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

--=__Part85ABC14A.0__=--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 13:08:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 13: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 1Rj9Wb-0005da-W4; Fri, 06 Jan 2012 13:08:01 +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 1Rj9WZ-0005dI-N1
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 13:08:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1325855273!8075774!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjc5OTY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjc5OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11697 invoked from network); 6 Jan 2012 13:07:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 13:07:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325855272; 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=kDRygcH75W5L7P6t/fnyt7zTOjE=;
	b=EDCtdKeil8zeuazjdjWSgk6150gvBpvZz73vfXfqnwMosRgwp5/TvlsarhzjbO8Xrvq
	PNTM6+SA4Mv8fBt9Zk1i7VmVjcotxe+Ki8vEd1EzmEpwG4n6sxIfEvQFZLrYAtcVU0vfi
	gNocKnFr6nMicY0BTvQ+NkJXPkLWLuU7P+s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3s7tEEw=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-077-062.pools.arcor-ip.net [84.57.77.62])
	by smtp.strato.de (cohen mo9) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id m070b5o06CGsxP ;
	Fri, 6 Jan 2012 14:07:39 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5E93718637; Fri,  6 Jan 2012 14:07:38 +0100 (CET)
Date: Fri, 6 Jan 2012 14:07:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120106130737.GB1694@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20120105205910.GA29311@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120105205910.GA29311@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, Olaf Hering wrote:

> Is the page-out time for 512M really that fast? For me page-out is still
> really slow even when the pagefile is in tmpfs. It takes several
> minutes, I get around 4MB/s. page-in is around 20MB/s.

Wait, the slow page-out is due to the poll() timeout in
xenpaging_wait_for_event_or_timeout(). This can be fixed with some sort
of dynamic timeout while there is still something to page-out.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 13:08:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 13: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 1Rj9Wb-0005da-W4; Fri, 06 Jan 2012 13:08:01 +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 1Rj9WZ-0005dI-N1
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 13:08:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1325855273!8075774!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjc5OTY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjc5OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11697 invoked from network); 6 Jan 2012 13:07:53 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 13:07:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1325855272; 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=kDRygcH75W5L7P6t/fnyt7zTOjE=;
	b=EDCtdKeil8zeuazjdjWSgk6150gvBpvZz73vfXfqnwMosRgwp5/TvlsarhzjbO8Xrvq
	PNTM6+SA4Mv8fBt9Zk1i7VmVjcotxe+Ki8vEd1EzmEpwG4n6sxIfEvQFZLrYAtcVU0vfi
	gNocKnFr6nMicY0BTvQ+NkJXPkLWLuU7P+s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lq3s7tEEw=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-077-062.pools.arcor-ip.net [84.57.77.62])
	by smtp.strato.de (cohen mo9) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id m070b5o06CGsxP ;
	Fri, 6 Jan 2012 14:07:39 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 5E93718637; Fri,  6 Jan 2012 14:07:38 +0100 (CET)
Date: Fri, 6 Jan 2012 14:07:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: hongkaixing@huawei.com
Message-ID: <20120106130737.GB1694@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20120105205910.GA29311@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120105205910.GA29311@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, Olaf Hering wrote:

> Is the page-out time for 512M really that fast? For me page-out is still
> really slow even when the pagefile is in tmpfs. It takes several
> minutes, I get around 4MB/s. page-in is around 20MB/s.

Wait, the slow page-out is due to the poll() timeout in
xenpaging_wait_for_event_or_timeout(). This can be fixed with some sort
of dynamic timeout while there is still something to page-out.

Olaf

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 13:31:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 13:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj9sm-0005qX-0Z; Fri, 06 Jan 2012 13:30:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1Rj9sl-0005qM-0S
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 13:30:55 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325856648!8059375!1
X-Originating-IP: [217.72.192.242]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjI0MiA9PiAxNDIwMQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjI0MiA9PiAxNDIwMQ==\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26187 invoked from network); 6 Jan 2012 13:30:48 -0000
Received: from fmmailgate04.web.de (HELO fmmailgate04.web.de) (217.72.192.242)
	by server-8.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 13:30:48 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate04.web.de (Postfix) with ESMTP id 023747094007
	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 14:30:48 +0100 (CET)
Received: from netbook.home ([187.105.25.94]) by smtp.web.de (mrweb001) with
	ESMTPA (Nemesis) id 0MA5dJ-1RuPEL0zXt-00BJFG;
	Fri, 06 Jan 2012 14:30:46 +0100
Message-ID: <4F06F76F.7090002@web.de>
Date: Fri, 06 Jan 2012 11:30:23 -0200
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: 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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:MOxoCg+5hvufwIFmmkjV2fQAaMQwi0XgvgDm0SVveyl
	7T53Kt8DRDOkDd9FnQlQrbIiIQlPkKqWpfPWqbifKaZtg7BWNX
	k7AV3hpCWMXSxDTLCzlggmZPOAuRZjt2fiHHJ64T5zI7VcFjE9
	nBDIsKMPhbm0KnH9/1xRSZu3ftUeE9QGbG3SWCLSnqRaYEoiNb
	IZ/7II7tPgHL8Fm2sDQLw==
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.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: multipart/mixed; boundary="===============3651095902074495796=="
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)
--===============3651095902074495796==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig2615110D80419480362E1B39"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2615110D80419480362E1B39
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2012-01-06 08:50, Stefano Stabellini wrote:
> On Thu, 5 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-05 15:50, Avi Kivity wrote:
>>>> Let me summarize what we have come up with so far:
>>>>
>>>> - we move the call to xen_register_framebuffer before
>>>> memory_region_init_ram in vga_common_init;
>>>>
>>>> - we prevent xen_ram_alloc from allocating a second framebuffer on
>>>> restore, checking for mr =3D=3D framebuffer;
>>>>
>>>> - we avoid memsetting the framebuffer on restore (useless anyway, th=
e
>>>> videoram is going to be loaded from the savefile in the general case=
);
>>>>
>>>> - we introduce a xen_address field to cirrus_vmstate and we use it
>>>> to map the videoram into qemu's address space and update vram_ptr in=

>>>> cirrus_post_load.
>>>>
>>>>
>>>> Does it make sense? Do you agree with the approach?
>>>
>>> Yes and yes.
>>
>> To me this still sounds like a cirrus-only xen workaround that
>> nevertheless spreads widely.
>=20
> The first two points are still necessary even if we go with the
> early_savevm option;

Can't really asses what the best way for Xen is to associate a memory
region with a particular physical mapping as to be stored in the early
vmstate. Is the memory API lacking some tag here?

> the third point is a good change regardless of the qemu accelerator;
> the only cirrus-only workaround is the last point, however it certainly=

> doesn't spread widely. It is true that other framebuffer based devices
> would need a similar change.

The third point indicates that there is rather more generic room for
improvements: Why should qemu reset device models before restore at all?
If we don't run the reset handlers, we don't suffer from that useless
memset. Testing for "Are we about to restore?" in a cirrus-only way
looks wrong.

>=20
>=20
>> Again, what speaks against migrating the information Xen needs before
>> creating the machine or a single device? That would only introduce a
>> generic concept of an (optional) "early", let's call it
>> "accelerator-related" vmstate and would allow Xen to deal with all the=

>> specifics behind the curtain.
>=20
> I am OK with both approaches.
> The only practical difference between the two is how we pass the xen
> framebuffer address across save/restore: either in the device specific
> savevm record or in a xen specific early_savevm record.
> What is it going to be?

I'm sure you will appreciate a more generic approach than adding this to
the device state once supporting more than cirrus over Xen.

Jan


--------------enig2615110D80419480362E1B39
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.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8G938ACgkQitSsb3rl5xTz5QCeNpAhM9E05GjyNkKJbzFTsUAj
/NsAn1fI6cAhCowrznXOObwrsf2XPNKb
=0iif
-----END PGP SIGNATURE-----

--------------enig2615110D80419480362E1B39--


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

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

--===============3651095902074495796==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 13:31:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 13:31:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj9sm-0005qX-0Z; Fri, 06 Jan 2012 13:30:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1Rj9sl-0005qM-0S
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 13:30:55 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1325856648!8059375!1
X-Originating-IP: [217.72.192.242]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjI0MiA9PiAxNDIwMQ==\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjI0MiA9PiAxNDIwMQ==\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26187 invoked from network); 6 Jan 2012 13:30:48 -0000
Received: from fmmailgate04.web.de (HELO fmmailgate04.web.de) (217.72.192.242)
	by server-8.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 13:30:48 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate04.web.de (Postfix) with ESMTP id 023747094007
	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 14:30:48 +0100 (CET)
Received: from netbook.home ([187.105.25.94]) by smtp.web.de (mrweb001) with
	ESMTPA (Nemesis) id 0MA5dJ-1RuPEL0zXt-00BJFG;
	Fri, 06 Jan 2012 14:30:46 +0100
Message-ID: <4F06F76F.7090002@web.de>
Date: Fri, 06 Jan 2012 11:30:23 -0200
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: 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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:MOxoCg+5hvufwIFmmkjV2fQAaMQwi0XgvgDm0SVveyl
	7T53Kt8DRDOkDd9FnQlQrbIiIQlPkKqWpfPWqbifKaZtg7BWNX
	k7AV3hpCWMXSxDTLCzlggmZPOAuRZjt2fiHHJ64T5zI7VcFjE9
	nBDIsKMPhbm0KnH9/1xRSZu3ftUeE9QGbG3SWCLSnqRaYEoiNb
	IZ/7II7tPgHL8Fm2sDQLw==
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.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: multipart/mixed; boundary="===============3651095902074495796=="
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)
--===============3651095902074495796==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig2615110D80419480362E1B39"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2615110D80419480362E1B39
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 2012-01-06 08:50, Stefano Stabellini wrote:
> On Thu, 5 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-05 15:50, Avi Kivity wrote:
>>>> Let me summarize what we have come up with so far:
>>>>
>>>> - we move the call to xen_register_framebuffer before
>>>> memory_region_init_ram in vga_common_init;
>>>>
>>>> - we prevent xen_ram_alloc from allocating a second framebuffer on
>>>> restore, checking for mr =3D=3D framebuffer;
>>>>
>>>> - we avoid memsetting the framebuffer on restore (useless anyway, th=
e
>>>> videoram is going to be loaded from the savefile in the general case=
);
>>>>
>>>> - we introduce a xen_address field to cirrus_vmstate and we use it
>>>> to map the videoram into qemu's address space and update vram_ptr in=

>>>> cirrus_post_load.
>>>>
>>>>
>>>> Does it make sense? Do you agree with the approach?
>>>
>>> Yes and yes.
>>
>> To me this still sounds like a cirrus-only xen workaround that
>> nevertheless spreads widely.
>=20
> The first two points are still necessary even if we go with the
> early_savevm option;

Can't really asses what the best way for Xen is to associate a memory
region with a particular physical mapping as to be stored in the early
vmstate. Is the memory API lacking some tag here?

> the third point is a good change regardless of the qemu accelerator;
> the only cirrus-only workaround is the last point, however it certainly=

> doesn't spread widely. It is true that other framebuffer based devices
> would need a similar change.

The third point indicates that there is rather more generic room for
improvements: Why should qemu reset device models before restore at all?
If we don't run the reset handlers, we don't suffer from that useless
memset. Testing for "Are we about to restore?" in a cirrus-only way
looks wrong.

>=20
>=20
>> Again, what speaks against migrating the information Xen needs before
>> creating the machine or a single device? That would only introduce a
>> generic concept of an (optional) "early", let's call it
>> "accelerator-related" vmstate and would allow Xen to deal with all the=

>> specifics behind the curtain.
>=20
> I am OK with both approaches.
> The only practical difference between the two is how we pass the xen
> framebuffer address across save/restore: either in the device specific
> savevm record or in a xen specific early_savevm record.
> What is it going to be?

I'm sure you will appreciate a more generic approach than adding this to
the device state once supporting more than cirrus over Xen.

Jan


--------------enig2615110D80419480362E1B39
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.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8G938ACgkQitSsb3rl5xTz5QCeNpAhM9E05GjyNkKJbzFTsUAj
/NsAn1fI6cAhCowrznXOObwrsf2XPNKb
=0iif
-----END PGP SIGNATURE-----

--------------enig2615110D80419480362E1B39--


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

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

--===============3651095902074495796==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 13:38:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 13:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj9zk-00064W-0V; Fri, 06 Jan 2012 13:38: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 1Rj9zi-00064M-MV
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 13:38:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1325857080!1068000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6469 invoked from network); 6 Jan 2012 13:38:00 -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;
	6 Jan 2012 13:38:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9864777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 13:38: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; Fri, 6 Jan 2012
	13:38:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 6 Jan 2012 13:37:59 +0000
In-Reply-To: <20229.58021.365808.925949@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20229.58021.365808.925949@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325857080.25206.499.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 17:49 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] RFC: Still TODO for 4.2?"):
> > What are the outstanding things to do before we think we can start on
> > the 4.2 -rc's? Does anyone have a timetable in mind?
> > 
> > hypervisor:
> > 
> >       * ??? - Keir, Tim, Jan?
> > 
> > tools:
> > 
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> 
> Relatedly, xl should have a json-based querier intended for users to
> not have to use the weird handwritten sexp printfs.

You mean for the "create -d" output? I agree and I've got such a patch
somewhere that I could polish off (and will).

I'd argue that the json output should be the default with sxp requiring
a special option, even though that break backwards compat with xm. I
have a hard time believing that the sexp printed by xl is close enough
to the xm one that people haven't already been hacking around it in
their parsers anyway...

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 13:38:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 13:38:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rj9zk-00064W-0V; Fri, 06 Jan 2012 13:38: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 1Rj9zi-00064M-MV
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 13:38:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1325857080!1068000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6469 invoked from network); 6 Jan 2012 13:38:00 -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;
	6 Jan 2012 13:38:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9864777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 13:38: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; Fri, 6 Jan 2012
	13:38:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 6 Jan 2012 13:37:59 +0000
In-Reply-To: <20229.58021.365808.925949@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20229.58021.365808.925949@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325857080.25206.499.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Tim \(Xen.org\)" <tim@xen.org>, xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-05 at 17:49 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] RFC: Still TODO for 4.2?"):
> > What are the outstanding things to do before we think we can start on
> > the 4.2 -rc's? Does anyone have a timetable in mind?
> > 
> > hypervisor:
> > 
> >       * ??? - Keir, Tim, Jan?
> > 
> > tools:
> > 
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> 
> Relatedly, xl should have a json-based querier intended for users to
> not have to use the weird handwritten sexp printfs.

You mean for the "create -d" output? I agree and I've got such a patch
somewhere that I could polish off (and will).

I'd argue that the json output should be the default with sxp requiring
a special option, even though that break backwards compat with xm. I
have a hard time believing that the sexp printed by xl is close enough
to the xm one that people haven't already been hacking around it in
their parsers anyway...

Ian.



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 14:23:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 14:23:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjAhY-0006Sg-S1; Fri, 06 Jan 2012 14:23:24 +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 1RjAhX-0006Sb-7Q
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:23:23 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325859796!9946694!1
X-Originating-IP: [77.238.189.64]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 18184 invoked from network); 6 Jan 2012 14:23:16 -0000
Received: from nm11.bullet.mail.ird.yahoo.com (HELO
	nm11.bullet.mail.ird.yahoo.com) (77.238.189.64)
	by server-4.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 14:23:16 -0000
Received: from [77.238.189.50] by nm11.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 14:23:16 -0000
Received: from [212.82.108.125] by tm3.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 14:23:16 -0000
Received: from [127.0.0.1] by omp1034.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 14:23:16 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 353220.82727.bm@omp1034.mail.ird.yahoo.com
Received: (qmail 78230 invoked by uid 60001); 6 Jan 2012 14:23:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325859796; bh=gU3PGwA9Vi+raVb0MGENkvoAbknrB9sztnEK2b79qiU=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=sGdCuq++BZJA8mw+Df1XV0I1TazEj/vodBMUFrdDhwG+s3+kAs1KW6T1xn/Z6sk6yYJmOD4VcSCg1rUxx23iX180gAJt30Vm+ciS0Iu+0hAwJXHwZxdONwNibWGOteA0IPS/YpjKcRPHb6dUXuDHIj6/Mjr1kj/MdVB1C+oSRzY=
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=PJJNaIBYaMGh5REFN2GKfscpXQnoXP+ZCED+VMf/oT1kOmHxG6IC2VSs5UO7CB49mq3+paJ3aQa5jhgzzxgSK77MO2x+bkbz2lCTutSYjGMtfMc9Ot6kSo4abwmBekpmL6Dd5DdPTEJZkP/mchPamc6+4vDvwoY12RLJ0A/PrsU=;
X-YMail-OSG: _zzhkxcVM1lrBJ9d8N4aJEzuKHwNPmScAwROpsM67ZwJi7a
	7z8Dsivq1mb1jTW5YvyW35Zqhwm3ptwmmPh2GP4_crHgjTpGHy6mVSGzDxU9
	7dEO9QBP9cZQSh2Ld.NR1vkbAaea1A3fpDp.Gln0Josl0_M9QMpRcowZxs6P
	3c2K6DfGKJazS.tyBqSyTG.k4tjyuAJz5loRd26UF3Sgt9jFiGxbLfGZnxUD
	rW9Wz8dOVXvVqTIXTVIJhfX2Ix6IYynmqfhIHZRgwOKLNRvoWP0ZojeTxDIg
	MJi0gMpxapz_nm0UCGQaq4KSUm6KQhLL50805SL5XDGW8G9iOBDRFM2r38Oh
	M.oqeiP5iwWY70Qj33pSSuEKXKXbUyt8sWSyEqVwHgXBcD4wv.TGYr.G.XOQ
	aXRv4d5x_ZBJJt4TFebqHeFvdHnlEuqXbkYzQISvB0cDfk0wKR4Rw2S4Js7t
	46EidTO9d5QgY38jQGd.b7aDqa1pBZkv8KEtke6YW6FjPwZiESeUUFeOOFHf
	xYodOnORSUO5gIIUs8oooyBP0tHe40kgTw8HkqFvcbWOF5cFX7TebpBs4rKO
	feBnr9Es3GdjX7lZCrfwI63gVoxTrbjC7QGhGmSnM52dC8A9zMd4JjHrUzJU
	rUQibW6UVIQYfgDDpqAEOtlFEaQMN2CqeN019pp7_lBcP1ye.dTyzZuph__v
	bwspCX982hcm26gs9IufPMh40sYrOmi1kAV9WNsFNM4vA6Wvlrg8BWxxjlAM
	.VmsRUZ4nQynUh6n4cBTIQ2Q.I6.3E6GPdSC1cgeQ8fd61rZWnJfiL2_QhOF
	75OWdpcXUyejhr8L4NF4jJ2SwDXrTMGKrffhaF8H0hR__Js6OJTcWdF.4JrA -
Received: from [195.167.237.98] by web29804.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 14:23:15 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
Message-ID: <1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 14:23:15 +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: <1325812394368-5124377.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] 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="===============8781184948006109192=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8781184948006109192==
Content-Type: multipart/alternative; boundary="-481600219-969151267-1325859795=:74578"

---481600219-969151267-1325859795=:74578
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

All informations given - by n4rc0tic - are right.=0A=0AFor XP: nvidia shoul=
d work=0A=0A=0AFor win7, you should be well-advised to use a ATI card.=0A=
=0ADavid.=0A=0A=0A=0A________________________________=0A De=A0: n4rC0t1C <s=
handivo@gmail.com>=0A=C0=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le :=
 Vendredi 6 Janvier 2012 2h13=0AObjet=A0: Re: [Xen-devel] Patches for VGA-P=
assthrough XEN 4.2 unstable=0A =0AForget about Windows 7. I didn't see a si=
ngle working solution to passthrough=0Aan nVidia card (at least not Quadro)=
 to a win7 domu. =0A=0AHowever WindowsXP works almost painless. Just follow=
 instructions and apply=0Apatches from D. Teacher on his website and everyt=
hing should work just fine. =0Ahttp://www.davidgis.fr/blog/index.php?2011/1=
2/07/860-xen-42unstable-patches-for-vga-pass-through=0A=0A--=0AView this me=
ssage in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthro=
ugh-XEN-4-2-unstable-tp4406265p5124377.html=0ASent from the Xen - Dev maili=
ng list archive at Nabble.com.=0A=0A_______________________________________=
________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://=
lists.xensource.com/xen-devel
---481600219-969151267-1325859795=:74578
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>All inform=
ations given - by n4rc0tic - are right.</span></div><div><br></div><div>For=
 XP: nvidia should work<br></div><div><br><span></span></div><div><span>For=
 win7, you should be well-advised to use a ATI card.</span></div><div><br><=
span></span></div><div><span>David.<br></span></div><div><br></div>  <div s=
tyle=3D"font-family: times new roman, new york, times, serif; font-size: 12=
pt;"> <div style=3D"font-family: times new roman, new york, times, serif; f=
ont-size: 12pt;"> <font size=3D"2" face=3D"Arial"> <hr size=3D"1">  <b><spa=
n style=3D"font-weight:bold;">De&nbsp;:</span></b> n4rC0t1C &lt;shandivo@gm=
ail.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;">E=
nvoy=E9 le :</span></b> Vendredi 6 Janvier 2012 2h13<br> <b><span style=3D"=
font-weight:
 bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Patches for VGA-Passthrough=
 XEN 4.2 unstable<br> </font> <br>Forget about Windows 7. I didn't see a si=
ngle working solution to passthrough<br>an nVidia card (at least not Quadro=
) to a win7 domu. <br><br>However WindowsXP works almost painless. Just fol=
low instructions and apply<br>patches from D. Teacher on his website and ev=
erything should work just fine. <br><a href=3D"http://www.davidgis.fr/blog/=
index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through" targe=
t=3D"_blank">http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42uns=
table-patches-for-vga-pass-through</a><br><br>--<br>View this message in co=
ntext: <a href=3D"http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthro=
ugh-XEN-4-2-unstable-tp4406265p5124377.html" target=3D"_blank">http://xen.1=
045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265=
p5124377.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:Xen-devel@lists.xensource.com" h=
ref=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">h=
ttp://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  </div></=
body></html>
---481600219-969151267-1325859795=:74578--


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

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

--===============8781184948006109192==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 14:23:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 14:23:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjAhY-0006Sg-S1; Fri, 06 Jan 2012 14:23:24 +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 1RjAhX-0006Sb-7Q
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:23:23 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325859796!9946694!1
X-Originating-IP: [77.238.189.64]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 18184 invoked from network); 6 Jan 2012 14:23:16 -0000
Received: from nm11.bullet.mail.ird.yahoo.com (HELO
	nm11.bullet.mail.ird.yahoo.com) (77.238.189.64)
	by server-4.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 14:23:16 -0000
Received: from [77.238.189.50] by nm11.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 14:23:16 -0000
Received: from [212.82.108.125] by tm3.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 14:23:16 -0000
Received: from [127.0.0.1] by omp1034.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 14:23:16 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 353220.82727.bm@omp1034.mail.ird.yahoo.com
Received: (qmail 78230 invoked by uid 60001); 6 Jan 2012 14:23:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325859796; bh=gU3PGwA9Vi+raVb0MGENkvoAbknrB9sztnEK2b79qiU=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=sGdCuq++BZJA8mw+Df1XV0I1TazEj/vodBMUFrdDhwG+s3+kAs1KW6T1xn/Z6sk6yYJmOD4VcSCg1rUxx23iX180gAJt30Vm+ciS0Iu+0hAwJXHwZxdONwNibWGOteA0IPS/YpjKcRPHb6dUXuDHIj6/Mjr1kj/MdVB1C+oSRzY=
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=PJJNaIBYaMGh5REFN2GKfscpXQnoXP+ZCED+VMf/oT1kOmHxG6IC2VSs5UO7CB49mq3+paJ3aQa5jhgzzxgSK77MO2x+bkbz2lCTutSYjGMtfMc9Ot6kSo4abwmBekpmL6Dd5DdPTEJZkP/mchPamc6+4vDvwoY12RLJ0A/PrsU=;
X-YMail-OSG: _zzhkxcVM1lrBJ9d8N4aJEzuKHwNPmScAwROpsM67ZwJi7a
	7z8Dsivq1mb1jTW5YvyW35Zqhwm3ptwmmPh2GP4_crHgjTpGHy6mVSGzDxU9
	7dEO9QBP9cZQSh2Ld.NR1vkbAaea1A3fpDp.Gln0Josl0_M9QMpRcowZxs6P
	3c2K6DfGKJazS.tyBqSyTG.k4tjyuAJz5loRd26UF3Sgt9jFiGxbLfGZnxUD
	rW9Wz8dOVXvVqTIXTVIJhfX2Ix6IYynmqfhIHZRgwOKLNRvoWP0ZojeTxDIg
	MJi0gMpxapz_nm0UCGQaq4KSUm6KQhLL50805SL5XDGW8G9iOBDRFM2r38Oh
	M.oqeiP5iwWY70Qj33pSSuEKXKXbUyt8sWSyEqVwHgXBcD4wv.TGYr.G.XOQ
	aXRv4d5x_ZBJJt4TFebqHeFvdHnlEuqXbkYzQISvB0cDfk0wKR4Rw2S4Js7t
	46EidTO9d5QgY38jQGd.b7aDqa1pBZkv8KEtke6YW6FjPwZiESeUUFeOOFHf
	xYodOnORSUO5gIIUs8oooyBP0tHe40kgTw8HkqFvcbWOF5cFX7TebpBs4rKO
	feBnr9Es3GdjX7lZCrfwI63gVoxTrbjC7QGhGmSnM52dC8A9zMd4JjHrUzJU
	rUQibW6UVIQYfgDDpqAEOtlFEaQMN2CqeN019pp7_lBcP1ye.dTyzZuph__v
	bwspCX982hcm26gs9IufPMh40sYrOmi1kAV9WNsFNM4vA6Wvlrg8BWxxjlAM
	.VmsRUZ4nQynUh6n4cBTIQ2Q.I6.3E6GPdSC1cgeQ8fd61rZWnJfiL2_QhOF
	75OWdpcXUyejhr8L4NF4jJ2SwDXrTMGKrffhaF8H0hR__Js6OJTcWdF.4JrA -
Received: from [195.167.237.98] by web29804.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 14:23:15 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
Message-ID: <1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 14:23:15 +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: <1325812394368-5124377.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] 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="===============8781184948006109192=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8781184948006109192==
Content-Type: multipart/alternative; boundary="-481600219-969151267-1325859795=:74578"

---481600219-969151267-1325859795=:74578
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

All informations given - by n4rc0tic - are right.=0A=0AFor XP: nvidia shoul=
d work=0A=0A=0AFor win7, you should be well-advised to use a ATI card.=0A=
=0ADavid.=0A=0A=0A=0A________________________________=0A De=A0: n4rC0t1C <s=
handivo@gmail.com>=0A=C0=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le :=
 Vendredi 6 Janvier 2012 2h13=0AObjet=A0: Re: [Xen-devel] Patches for VGA-P=
assthrough XEN 4.2 unstable=0A =0AForget about Windows 7. I didn't see a si=
ngle working solution to passthrough=0Aan nVidia card (at least not Quadro)=
 to a win7 domu. =0A=0AHowever WindowsXP works almost painless. Just follow=
 instructions and apply=0Apatches from D. Teacher on his website and everyt=
hing should work just fine. =0Ahttp://www.davidgis.fr/blog/index.php?2011/1=
2/07/860-xen-42unstable-patches-for-vga-pass-through=0A=0A--=0AView this me=
ssage in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthro=
ugh-XEN-4-2-unstable-tp4406265p5124377.html=0ASent from the Xen - Dev maili=
ng list archive at Nabble.com.=0A=0A_______________________________________=
________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://=
lists.xensource.com/xen-devel
---481600219-969151267-1325859795=:74578
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>All inform=
ations given - by n4rc0tic - are right.</span></div><div><br></div><div>For=
 XP: nvidia should work<br></div><div><br><span></span></div><div><span>For=
 win7, you should be well-advised to use a ATI card.</span></div><div><br><=
span></span></div><div><span>David.<br></span></div><div><br></div>  <div s=
tyle=3D"font-family: times new roman, new york, times, serif; font-size: 12=
pt;"> <div style=3D"font-family: times new roman, new york, times, serif; f=
ont-size: 12pt;"> <font size=3D"2" face=3D"Arial"> <hr size=3D"1">  <b><spa=
n style=3D"font-weight:bold;">De&nbsp;:</span></b> n4rC0t1C &lt;shandivo@gm=
ail.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;">E=
nvoy=E9 le :</span></b> Vendredi 6 Janvier 2012 2h13<br> <b><span style=3D"=
font-weight:
 bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Patches for VGA-Passthrough=
 XEN 4.2 unstable<br> </font> <br>Forget about Windows 7. I didn't see a si=
ngle working solution to passthrough<br>an nVidia card (at least not Quadro=
) to a win7 domu. <br><br>However WindowsXP works almost painless. Just fol=
low instructions and apply<br>patches from D. Teacher on his website and ev=
erything should work just fine. <br><a href=3D"http://www.davidgis.fr/blog/=
index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through" targe=
t=3D"_blank">http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42uns=
table-patches-for-vga-pass-through</a><br><br>--<br>View this message in co=
ntext: <a href=3D"http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthro=
ugh-XEN-4-2-unstable-tp4406265p5124377.html" target=3D"_blank">http://xen.1=
045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265=
p5124377.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:Xen-devel@lists.xensource.com" h=
ref=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">h=
ttp://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  </div></=
body></html>
---481600219-969151267-1325859795=:74578--


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

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

--===============8781184948006109192==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 14:41:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 14:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjAy0-0006hC-MB; Fri, 06 Jan 2012 14:40:24 +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 1RjAxz-0006h7-7q
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:40:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1325860816!11311614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7897 invoked from network); 6 Jan 2012 14:40:17 -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;
	6 Jan 2012 14:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9866090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 14:40:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 14:40:15 +0000
Date: Fri, 6 Jan 2012 14:40:06 +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: <4F06F76F.7090002@web.de>
Message-ID: <alpine.DEB.2.00.1201061417480.3150@kaball-desktop>
References: <1323467645-24271-1-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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	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, 6 Jan 2012, Jan Kiszka wrote:
> On 2012-01-06 08:50, Stefano Stabellini wrote:
> > On Thu, 5 Jan 2012, Jan Kiszka wrote:
> >> On 2012-01-05 15:50, Avi Kivity wrote:
> >>>> Let me summarize what we have come up with so far:
> >>>>
> >>>> - we move the call to xen_register_framebuffer before
> >>>> memory_region_init_ram in vga_common_init;
> >>>>
> >>>> - we prevent xen_ram_alloc from allocating a second framebuffer on
> >>>> restore, checking for mr == framebuffer;
> >>>>
> >>>> - we avoid memsetting the framebuffer on restore (useless anyway, the
> >>>> videoram is going to be loaded from the savefile in the general case);
> >>>>
> >>>> - we introduce a xen_address field to cirrus_vmstate and we use it
> >>>> to map the videoram into qemu's address space and update vram_ptr in
> >>>> cirrus_post_load.
> >>>>
> >>>>
> >>>> Does it make sense? Do you agree with the approach?
> >>>
> >>> Yes and yes.
> >>
> >> To me this still sounds like a cirrus-only xen workaround that
> >> nevertheless spreads widely.
> > 
> > The first two points are still necessary even if we go with the
> > early_savevm option;
> 
> Can't really asses what the best way for Xen is to associate a memory
> region with a particular physical mapping as to be stored in the early
> vmstate. Is the memory API lacking some tag here?

ATM we have our own list of physmaps (physical mappings) maintained in
xen-all.c, but adding a xen specific field to the MemoryRegion struct
should be enough to allow us to remove the physmap list and just use
MemoryRegions for everything.

Regarding save/restore, we could save in an early_savevm record all the
MemoryRegions or just the ones with a special xen mapping.


> > the third point is a good change regardless of the qemu accelerator;
> > the only cirrus-only workaround is the last point, however it certainly
> > doesn't spread widely. It is true that other framebuffer based devices
> > would need a similar change.
> 
> The third point indicates that there is rather more generic room for
> improvements: Why should qemu reset device models before restore at all?
> If we don't run the reset handlers, we don't suffer from that useless
> memset. Testing for "Are we about to restore?" in a cirrus-only way
> looks wrong.

Fair enough.


> >> Again, what speaks against migrating the information Xen needs before
> >> creating the machine or a single device? That would only introduce a
> >> generic concept of an (optional) "early", let's call it
> >> "accelerator-related" vmstate and would allow Xen to deal with all the
> >> specifics behind the curtain.
> > 
> > I am OK with both approaches.
> > The only practical difference between the two is how we pass the xen
> > framebuffer address across save/restore: either in the device specific
> > savevm record or in a xen specific early_savevm record.
> > What is it going to be?
> 
> I'm sure you will appreciate a more generic approach than adding this to
> the device state once supporting more than cirrus over Xen.
 
Of course I do, in fact that is why I like the early_savevm approach, it
is more flexible.
On the other hand it is more work and realistically 99% of our users just
use Cirrus all the time so that is why I am also OK with the other
solution.

Avi, if you think that early_savevm is a decent solution, we'll start
working on it. Also if you would like to save and restore all the
MemoryRegions because you can see some possible future uses for it, please
let me know. Otherwise we might try to save some space and just store the
ones we need.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 14:41:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 14:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjAy0-0006hC-MB; Fri, 06 Jan 2012 14:40:24 +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 1RjAxz-0006h7-7q
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:40:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1325860816!11311614!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7897 invoked from network); 6 Jan 2012 14:40:17 -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;
	6 Jan 2012 14:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9866090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 14:40:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 14:40:15 +0000
Date: Fri, 6 Jan 2012 14:40:06 +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: <4F06F76F.7090002@web.de>
Message-ID: <alpine.DEB.2.00.1201061417480.3150@kaball-desktop>
References: <1323467645-24271-1-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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	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, 6 Jan 2012, Jan Kiszka wrote:
> On 2012-01-06 08:50, Stefano Stabellini wrote:
> > On Thu, 5 Jan 2012, Jan Kiszka wrote:
> >> On 2012-01-05 15:50, Avi Kivity wrote:
> >>>> Let me summarize what we have come up with so far:
> >>>>
> >>>> - we move the call to xen_register_framebuffer before
> >>>> memory_region_init_ram in vga_common_init;
> >>>>
> >>>> - we prevent xen_ram_alloc from allocating a second framebuffer on
> >>>> restore, checking for mr == framebuffer;
> >>>>
> >>>> - we avoid memsetting the framebuffer on restore (useless anyway, the
> >>>> videoram is going to be loaded from the savefile in the general case);
> >>>>
> >>>> - we introduce a xen_address field to cirrus_vmstate and we use it
> >>>> to map the videoram into qemu's address space and update vram_ptr in
> >>>> cirrus_post_load.
> >>>>
> >>>>
> >>>> Does it make sense? Do you agree with the approach?
> >>>
> >>> Yes and yes.
> >>
> >> To me this still sounds like a cirrus-only xen workaround that
> >> nevertheless spreads widely.
> > 
> > The first two points are still necessary even if we go with the
> > early_savevm option;
> 
> Can't really asses what the best way for Xen is to associate a memory
> region with a particular physical mapping as to be stored in the early
> vmstate. Is the memory API lacking some tag here?

ATM we have our own list of physmaps (physical mappings) maintained in
xen-all.c, but adding a xen specific field to the MemoryRegion struct
should be enough to allow us to remove the physmap list and just use
MemoryRegions for everything.

Regarding save/restore, we could save in an early_savevm record all the
MemoryRegions or just the ones with a special xen mapping.


> > the third point is a good change regardless of the qemu accelerator;
> > the only cirrus-only workaround is the last point, however it certainly
> > doesn't spread widely. It is true that other framebuffer based devices
> > would need a similar change.
> 
> The third point indicates that there is rather more generic room for
> improvements: Why should qemu reset device models before restore at all?
> If we don't run the reset handlers, we don't suffer from that useless
> memset. Testing for "Are we about to restore?" in a cirrus-only way
> looks wrong.

Fair enough.


> >> Again, what speaks against migrating the information Xen needs before
> >> creating the machine or a single device? That would only introduce a
> >> generic concept of an (optional) "early", let's call it
> >> "accelerator-related" vmstate and would allow Xen to deal with all the
> >> specifics behind the curtain.
> > 
> > I am OK with both approaches.
> > The only practical difference between the two is how we pass the xen
> > framebuffer address across save/restore: either in the device specific
> > savevm record or in a xen specific early_savevm record.
> > What is it going to be?
> 
> I'm sure you will appreciate a more generic approach than adding this to
> the device state once supporting more than cirrus over Xen.
 
Of course I do, in fact that is why I like the early_savevm approach, it
is more flexible.
On the other hand it is more work and realistically 99% of our users just
use Cirrus all the time so that is why I am also OK with the other
solution.

Avi, if you think that early_savevm is a decent solution, we'll start
working on it. Also if you would like to save and restore all the
MemoryRegions because you can see some possible future uses for it, please
let me know. Otherwise we might try to save some space and just store the
ones we need.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:21:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBbB-0007ae-9P; Fri, 06 Jan 2012 15:20:53 +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 1RjBb9-0007aR-Pt
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:20:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-174.messagelabs.com!1325863245!8093187!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5ODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11214 invoked from network); 6 Jan 2012 15:20:45 -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; 6 Jan 2012 15:20: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 2C45F1810;
	Fri,  6 Jan 2012 17:20:42 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id F03EF20056; Fri,  6 Jan 2012 17:20:41 +0200 (EET)
Date: Fri, 6 Jan 2012 17:20:41 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20120106152041.GZ12984@reaktio.net>
References: <20110624151324.GB356@spongy.cam.xci-test.com>
	<4E04C8AA.2040506@goop.org>
	<20110624221513.GA8916@spongy.cam.xci-test.com>
	<4E051306.4060109@goop.org>
	<20110627201907.GA8795@taoand.xen.fishsoupisgoodforyou.com>
	<1309691766.6460.19.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1309691766.6460.19.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	James <James.McKenzie@citrix.com>, Jean Guyader <Jean.Guyader@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] Linux: 6 arguments hypercall v3 / V4V
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, Jul 03, 2011 at 12:16:01PM +0100, Ian Campbell wrote:
> On Mon, 2011-06-27 at 21:19 +0100, James wrote:
> > On Fri, Jun 24, 2011 at 03:43:18PM -0700, Jeremy Fitzhardinge wrote:
> > > Does it have to?  Couldn't it take a pointer to a struct or something?
> > 
> > Yes we could change the API, make sure the struct is visible on all
> > CPUs,
> 
> FWIW the struct only needs to be visible on the CPU actually making the
> hypercall. Many (most?) Xen hypercalls take a pointer to an argument
> structure in this way.
> 

.. what was the end result of this? 

I'm wondering if V4V will be upstreamed, or if the new libvchan can replace V4V?
I assume XenClient is still using V4V ..

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:21:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBbB-0007ae-9P; Fri, 06 Jan 2012 15:20:53 +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 1RjBb9-0007aR-Pt
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:20:52 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-174.messagelabs.com!1325863245!8093187!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5ODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11214 invoked from network); 6 Jan 2012 15:20:45 -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; 6 Jan 2012 15:20: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 2C45F1810;
	Fri,  6 Jan 2012 17:20:42 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id F03EF20056; Fri,  6 Jan 2012 17:20:41 +0200 (EET)
Date: Fri, 6 Jan 2012 17:20:41 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20120106152041.GZ12984@reaktio.net>
References: <20110624151324.GB356@spongy.cam.xci-test.com>
	<4E04C8AA.2040506@goop.org>
	<20110624221513.GA8916@spongy.cam.xci-test.com>
	<4E051306.4060109@goop.org>
	<20110627201907.GA8795@taoand.xen.fishsoupisgoodforyou.com>
	<1309691766.6460.19.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1309691766.6460.19.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	James <James.McKenzie@citrix.com>, Jean Guyader <Jean.Guyader@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] Linux: 6 arguments hypercall v3 / V4V
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, Jul 03, 2011 at 12:16:01PM +0100, Ian Campbell wrote:
> On Mon, 2011-06-27 at 21:19 +0100, James wrote:
> > On Fri, Jun 24, 2011 at 03:43:18PM -0700, Jeremy Fitzhardinge wrote:
> > > Does it have to?  Couldn't it take a pointer to a struct or something?
> > 
> > Yes we could change the API, make sure the struct is visible on all
> > CPUs,
> 
> FWIW the struct only needs to be visible on the CPU actually making the
> hypercall. Many (most?) Xen hypercalls take a pointer to an argument
> structure in this way.
> 

.. what was the end result of this? 

I'm wondering if V4V will be upstreamed, or if the new libvchan can replace V4V?
I assume XenClient is still using V4V ..

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:24:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBed-0007lI-9Z; Fri, 06 Jan 2012 15:24:27 +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 1RjBeb-0007lA-Dn
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:24:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325863420!47555058!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5ODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26535 invoked from network); 6 Jan 2012 15:23:40 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 15:23:40 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 342802908;
	Fri,  6 Jan 2012 17:24:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1981320058; Fri,  6 Jan 2012 17:24:22 +0200 (EET)
Date: Fri, 6 Jan 2012 17:24:22 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120106152422.GA12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
	<20120104182037.GC15595@ocelot.phlegethon.org>
	<1325759960.25206.363.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325759960.25206.363.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Shan, Haitao" <haitao.shan@intel.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? Nested Paging for
	Intel	Nested Virt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, 2012 at 10:39:20AM +0000, Ian Campbell wrote:
> On Wed, 2012-01-04 at 18:20 +0000, Tim Deegan wrote:
> > At 19:25 +0200 on 04 Jan (1325705119), Pasi K?rkk?inen wrote:
> > > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > > What are the outstanding things to do before we think we can start on
> > > > the 4.2 -rc's? Does anyone have a timetable in mind?
> > > > 
> > > > hypervisor:
> > > > 
> > > >       * ??? - Keir, Tim, Jan?
> > 
> > I would like to get the interface changes for sharing/paging/mem-events
> > done and dusted so that 4.2 is a stable API that we hold to.
> > 
> > It would be nice to get the implementation solid too (i.e., using wait
> > queues) but that can happen later if it's the only thing holding up a
> > release.
> > 
> > > - What's the status of Nested Hardware Virtualization? 
> > > I remember some email saying Intel vmx-on-vmx has some performance issues,
> > > and amd svm-on-svm works better..
> 
> That's the impression that I've gotten too.
> 

Yep. 

Intel guys: Any plans to implement Nested Paging for Nested Virt ? 


> > The basic feature is in for AMD and Intel, but AIUI it's not getting a
> > lot of use and it's not in the xen.org automated testing.  The AMD code
> > has nested-paging support too, which is a requirement for decent
> > performance. 
> > 
> > We could call it 'experimental' for 4.2?
> 
> IMHO we shouldn't hold up the release for it so either it is working by
> the time the release happens or it is experimental. (I guess we should
> consider svm-on-svm and vmx-on-vmx separately for these purposes).
> 

Makes sense.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:24:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBed-0007lI-9Z; Fri, 06 Jan 2012 15:24:27 +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 1RjBeb-0007lA-Dn
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:24:25 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325863420!47555058!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5ODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26535 invoked from network); 6 Jan 2012 15:23:40 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 15:23:40 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 342802908;
	Fri,  6 Jan 2012 17:24:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1981320058; Fri,  6 Jan 2012 17:24:22 +0200 (EET)
Date: Fri, 6 Jan 2012 17:24:22 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120106152422.GA12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
	<20120104182037.GC15595@ocelot.phlegethon.org>
	<1325759960.25206.363.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325759960.25206.363.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "Shan, Haitao" <haitao.shan@intel.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, "Dong, Eddie" <eddie.dong@intel.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? Nested Paging for
	Intel	Nested Virt
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, 2012 at 10:39:20AM +0000, Ian Campbell wrote:
> On Wed, 2012-01-04 at 18:20 +0000, Tim Deegan wrote:
> > At 19:25 +0200 on 04 Jan (1325705119), Pasi K?rkk?inen wrote:
> > > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > > What are the outstanding things to do before we think we can start on
> > > > the 4.2 -rc's? Does anyone have a timetable in mind?
> > > > 
> > > > hypervisor:
> > > > 
> > > >       * ??? - Keir, Tim, Jan?
> > 
> > I would like to get the interface changes for sharing/paging/mem-events
> > done and dusted so that 4.2 is a stable API that we hold to.
> > 
> > It would be nice to get the implementation solid too (i.e., using wait
> > queues) but that can happen later if it's the only thing holding up a
> > release.
> > 
> > > - What's the status of Nested Hardware Virtualization? 
> > > I remember some email saying Intel vmx-on-vmx has some performance issues,
> > > and amd svm-on-svm works better..
> 
> That's the impression that I've gotten too.
> 

Yep. 

Intel guys: Any plans to implement Nested Paging for Nested Virt ? 


> > The basic feature is in for AMD and Intel, but AIUI it's not getting a
> > lot of use and it's not in the xen.org automated testing.  The AMD code
> > has nested-paging support too, which is a requirement for decent
> > performance. 
> > 
> > We could call it 'experimental' for 4.2?
> 
> IMHO we shouldn't hold up the release for it so either it is working by
> the time the release happens or it is experimental. (I guess we should
> consider svm-on-svm and vmx-on-vmx separately for these purposes).
> 

Makes sense.

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:30:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15: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 1RjBjo-00082p-2D; Fri, 06 Jan 2012 15:29:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1RjBjm-000824-Ri
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:29:47 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325863780!9954785!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk0MTQ3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14471 invoked from network); 6 Jan 2012 15:29:40 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 15:29:40 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 06 Jan 2012 07:29:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="93672974"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 06 Jan 2012 07:29:38 -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; Fri, 6 Jan 2012 23:28:12 +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, 6 Jan 2012 23:28:11 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
Thread-Index: AczMRwG0/KHzXywMRnO7sDrHQC4Rr///iw4A//8RO9A=
Date: Fri, 6 Jan 2012 15:28:10 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10012510@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@SHSMSX101.ccr.corp.intel.com>
	<1325839550.25206.420.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325839550.25206.420.camel@zakaz.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, January 06, 2012 4:46 PM
> To: Ren, Yongjie
> Cc: xen-devel@lists.xensource.com; Ian Jackson
> Subject: Re: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
> 
> On Fri, 2012-01-06 at 07:44 +0000, Ren, Yongjie wrote:
> > Hi All,
> >
> > The ipxe git commit version changed, but its release version should
> > still stay at v1.0.0
> 
> Doesn't this effectively undo the change in 24455:94180a5a0c7c since the
> $T rules first tries to wget $(IPXE_TARBALL_URL) before cloning the git
> tree? Therefore with this change it is going to find and clone v1.0
> instead of using the git tag.
> 
No, I don't want to undo the change in CS #24455.
I just want to fix an obvious issue. Before my patch, we'll get "IPXE_TARBALL_URL= http://xenbits.xensource.com/xen-extfiles/ipxe-git- 9a93db3f0947484e30e753bbd61a10b17336e20e.tar.gz". So the tarball file in this URL cannot be found. To wget the URL should always fail. I just change it use ipxe-git-v1.0.0.tar.gz which is an available file as before.
And I know there is still a problem. If using ipxe tarball, we can't add the patches in 'patches/series' successfully after CS #24455 because that change set made these patches dedicated for ipxe.git upstream.
I'm not familiar with the iPXE, so I have two questions?
1. Should we support both tarball and ipxe.git upstream in xen tools? 
2. Are patches in 'patches/series' important?
If we support both and patches are import, we can prepare two kinds of patch-series. One is born for tarball, the other is for ipxe.git upstream.
If these patches are not important, we can only do patching logic when we using ipxe upstream not tarball.

> >
> >
> >
> > Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
> >
> > ------
> >
> >
> >
> > diff -r 4086e4811547 tools/firmware/etherboot/Makefile
> >
> > --- a/tools/firmware/etherboot/Makefile Thu Jan 05 17:25:23 2012 +0000
> >
> > +++ b/tools/firmware/etherboot/Makefile Fri Jan 06 14:30:54 2012 +0800
> >
> > @@ -12,7 +12,9 @@
> >
> >
> >
> > IPXE_GIT_TAG := 9a93db3f0947484e30e753bbd61a10b17336e20e
> >
> >
> >
> > -IPXE_TARBALL_URL :=
> > $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
> >
> > +IPXE_VERSION := v1.0.0
> >
> > +
> >
> > +IPXE_TARBALL_URL :=
> > $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_VERSION).tar.gz
> >
> >
> >
> > D=ipxe
> >
> > T=ipxe.tar.gz
> >
> >
> >
> > Best Regards,
> >
> >      Yongjie Ren  (Jay)
> >
> >
> >
> >
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:30:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15: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 1RjBjo-00082p-2D; Fri, 06 Jan 2012 15:29:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <yongjie.ren@intel.com>) id 1RjBjm-000824-Ri
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:29:47 +0000
X-Env-Sender: yongjie.ren@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325863780!9954785!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk0MTQ3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14471 invoked from network); 6 Jan 2012 15:29:40 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-4.tower-216.messagelabs.com with SMTP;
	6 Jan 2012 15:29:40 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 06 Jan 2012 07:29:39 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="93672974"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 06 Jan 2012 07:29:38 -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; Fri, 6 Jan 2012 23:28:12 +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, 6 Jan 2012 23:28:11 +0800
From: "Ren, Yongjie" <yongjie.ren@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Thread-Topic: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
Thread-Index: AczMRwG0/KHzXywMRnO7sDrHQC4Rr///iw4A//8RO9A=
Date: Fri, 6 Jan 2012 15:28:10 +0000
Message-ID: <1B4B44D9196EFF41AE41FDA404FC0A10012510@SHSMSX101.ccr.corp.intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@SHSMSX101.ccr.corp.intel.com>
	<1325839550.25206.420.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325839550.25206.420.camel@zakaz.uk.xensource.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, January 06, 2012 4:46 PM
> To: Ren, Yongjie
> Cc: xen-devel@lists.xensource.com; Ian Jackson
> Subject: Re: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
> 
> On Fri, 2012-01-06 at 07:44 +0000, Ren, Yongjie wrote:
> > Hi All,
> >
> > The ipxe git commit version changed, but its release version should
> > still stay at v1.0.0
> 
> Doesn't this effectively undo the change in 24455:94180a5a0c7c since the
> $T rules first tries to wget $(IPXE_TARBALL_URL) before cloning the git
> tree? Therefore with this change it is going to find and clone v1.0
> instead of using the git tag.
> 
No, I don't want to undo the change in CS #24455.
I just want to fix an obvious issue. Before my patch, we'll get "IPXE_TARBALL_URL= http://xenbits.xensource.com/xen-extfiles/ipxe-git- 9a93db3f0947484e30e753bbd61a10b17336e20e.tar.gz". So the tarball file in this URL cannot be found. To wget the URL should always fail. I just change it use ipxe-git-v1.0.0.tar.gz which is an available file as before.
And I know there is still a problem. If using ipxe tarball, we can't add the patches in 'patches/series' successfully after CS #24455 because that change set made these patches dedicated for ipxe.git upstream.
I'm not familiar with the iPXE, so I have two questions?
1. Should we support both tarball and ipxe.git upstream in xen tools? 
2. Are patches in 'patches/series' important?
If we support both and patches are import, we can prepare two kinds of patch-series. One is born for tarball, the other is for ipxe.git upstream.
If these patches are not important, we can only do patching logic when we using ipxe upstream not tarball.

> >
> >
> >
> > Signed-off-by: Yongjie Ren <yongjie.ren@intel.com>
> >
> > ------
> >
> >
> >
> > diff -r 4086e4811547 tools/firmware/etherboot/Makefile
> >
> > --- a/tools/firmware/etherboot/Makefile Thu Jan 05 17:25:23 2012 +0000
> >
> > +++ b/tools/firmware/etherboot/Makefile Fri Jan 06 14:30:54 2012 +0800
> >
> > @@ -12,7 +12,9 @@
> >
> >
> >
> > IPXE_GIT_TAG := 9a93db3f0947484e30e753bbd61a10b17336e20e
> >
> >
> >
> > -IPXE_TARBALL_URL :=
> > $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
> >
> > +IPXE_VERSION := v1.0.0
> >
> > +
> >
> > +IPXE_TARBALL_URL :=
> > $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_VERSION).tar.gz
> >
> >
> >
> > D=ipxe
> >
> > T=ipxe.tar.gz
> >
> >
> >
> > Best Regards,
> >
> >      Yongjie Ren  (Jay)
> >
> >
> >
> >
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:37:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15: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 1RjBrP-0008Fn-4d; Fri, 06 Jan 2012 15:37:39 +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 1RjBrN-0008Fd-Mf
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:37:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1325864249!8095370!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 3851 invoked from network); 6 Jan 2012 15:37:31 -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; 6 Jan 2012 15:37:31 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q06FbEP9021464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 6 Jan 2012 10:37:14 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q06FbELS021462;
	Fri, 6 Jan 2012 10:37:14 -0500
Date: Fri, 6 Jan 2012 11:37:14 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120106153714.GA21220@andromeda.dapyr.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F04AF28.8040102@amd.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
> >On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
> >>>>Has anybody got anything else? I'm sure I've missed stuff. Are there any
> >>>>must haves e.g. in the paging/sharing spaces?
> >>>>
> >>>- What's the status of Nested Hardware Virtualization?
> >>>I remember some email saying Intel vmx-on-vmx has some performance 
> >>>issues,
> >>>and amd svm-on-svm works better..
> >>>
> >>>
> >>>- Also there's a bunch of VGA passthru related patches,
> >>>that I once volunteered to collect/rebase/cleanup/repost myself,
> >>>but I still haven't had time for that :(
> >>Since there were quite a lot of interest on this subject, should we
> >>document it in a separate wiki for working combinations (like
> >>hypervisor, dom0, gfx card, driver version, tricks, etc)?
> >>
> >I actually once started writing down that kind of stuff:
> >http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> >
> >Feel free to contribute :)
> >
> >There's also:
> >http://wiki.xen.org/xenwiki/XenVGAPassthrough
> Thanks for sharing. I will contribute my findings as needed. BTW, do you 
> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a 

Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
guest and it works nicely.. the first time. After I shut down the guest
it just never works again :-(

> dilemma for several reasons:  it doesn't always work; sometimes it can 
> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst 
> driver seems very stable even without these patches. But Wei Wang told 
> me that he needs them for some of his cards.
> >
> >-- 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 Fri Jan 06 15:37:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15: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 1RjBrP-0008Fn-4d; Fri, 06 Jan 2012 15:37:39 +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 1RjBrN-0008Fd-Mf
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:37:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1325864249!8095370!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 3851 invoked from network); 6 Jan 2012 15:37:31 -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; 6 Jan 2012 15:37:31 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q06FbEP9021464
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 6 Jan 2012 10:37:14 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q06FbELS021462;
	Fri, 6 Jan 2012 10:37:14 -0500
Date: Fri, 6 Jan 2012 11:37:14 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Wei Huang <wei.huang2@amd.com>
Message-ID: <20120106153714.GA21220@andromeda.dapyr.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F04AF28.8040102@amd.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
> On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
> >On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
> >>>>Has anybody got anything else? I'm sure I've missed stuff. Are there any
> >>>>must haves e.g. in the paging/sharing spaces?
> >>>>
> >>>- What's the status of Nested Hardware Virtualization?
> >>>I remember some email saying Intel vmx-on-vmx has some performance 
> >>>issues,
> >>>and amd svm-on-svm works better..
> >>>
> >>>
> >>>- Also there's a bunch of VGA passthru related patches,
> >>>that I once volunteered to collect/rebase/cleanup/repost myself,
> >>>but I still haven't had time for that :(
> >>Since there were quite a lot of interest on this subject, should we
> >>document it in a separate wiki for working combinations (like
> >>hypervisor, dom0, gfx card, driver version, tricks, etc)?
> >>
> >I actually once started writing down that kind of stuff:
> >http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
> >
> >Feel free to contribute :)
> >
> >There's also:
> >http://wiki.xen.org/xenwiki/XenVGAPassthrough
> Thanks for sharing. I will contribute my findings as needed. BTW, do you 
> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a 

Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
guest and it works nicely.. the first time. After I shut down the guest
it just never works again :-(

> dilemma for several reasons:  it doesn't always work; sometimes it can 
> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst 
> driver seems very stable even without these patches. But Wei Wang told 
> me that he needs them for some of his cards.
> >
> >-- 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 Fri Jan 06 15:43:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBw9-0008OC-Sh; Fri, 06 Jan 2012 15:42:33 +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 1RjBw7-0008O4-Su
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:42:32 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325864528!51797076!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 19893 invoked from network); 6 Jan 2012 15:42:09 -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; 6 Jan 2012 15:42:09 -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
	q06FgROx021688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 6 Jan 2012 10:42:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q06FgR1c021686;
	Fri, 6 Jan 2012 10:42:27 -0500
Date: Fri, 6 Jan 2012 11:42:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120106154227.GB21220@andromeda.dapyr.net>
References: <20120105204126.GA29219@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120105204126.GA29219@aepfle.de>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] 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, Jan 05, 2012 at 09:41:26PM +0100, Olaf Hering wrote:
> Add 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.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Please resend and CC the maintainer and as well LKML.

> 
> ---
> 
> Note: the patch will be available via git://... once it was reviewed

huh?

> 
>  drivers/xen/xenbus/xenbus_xs.c     |   21 +++++++++++++++++++++
>  include/xen/interface/io/xs_wire.h |    3 ++-
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> Index: linux-3.2/drivers/xen/xenbus/xenbus_xs.c
> ===================================================================
> --- linux-3.2.orig/drivers/xen/xenbus/xenbus_xs.c
> +++ linux-3.2/drivers/xen/xenbus/xenbus_xs.c
> @@ -621,6 +621,23 @@ static struct xenbus_watch *find_watch(c
>  	return NULL;
>  }
>  
> +static void xs_reset_watches(void)
> +{
> +	int err, supported = 0;
> +
> +	if (!xen_hvm_domain())
> +		return;
> +
> +	err = xenbus_scanf(XBT_NIL, "control",
> +			"platform-feature-xs_reset_watches", "%d", &supported);
> +	if (err != 1 || !supported)
> +		return;
> +
> +	err = xs_error(xs_single(XBT_NIL, XS_RESET_WATCHES, "", NULL));
> +	if (err && err != -EEXIST)
> +		printk(KERN_WARNING "xs_reset_watches failed: %d\n", err);
> +}
> +
>  /* Register callback to watch this node. */
>  int register_xenbus_watch(struct xenbus_watch *watch)
>  {
> @@ -897,5 +915,8 @@ int xs_init(void)
>  	if (IS_ERR(task))
>  		return PTR_ERR(task);
>  
> +	/* shutdown watches for kexec boot */
> +	xs_reset_watches();
> +
>  	return 0;
>  }
> Index: linux-3.2/include/xen/interface/io/xs_wire.h
> ===================================================================
> --- linux-3.2.orig/include/xen/interface/io/xs_wire.h
> +++ linux-3.2/include/xen/interface/io/xs_wire.h
> @@ -29,7 +29,8 @@ enum xsd_sockmsg_type
>      XS_IS_DOMAIN_INTRODUCED,
>      XS_RESUME,
>      XS_SET_TARGET,
> -    XS_RESTRICT
> +    XS_RESTRICT,
> +    XS_RESET_WATCHES
>  };
>  
>  #define XS_WRITE_NONE "NONE"
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 06 15:43:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:43:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBw9-0008OC-Sh; Fri, 06 Jan 2012 15:42:33 +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 1RjBw7-0008O4-Su
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:42:32 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1325864528!51797076!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 19893 invoked from network); 6 Jan 2012 15:42:09 -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; 6 Jan 2012 15:42:09 -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
	q06FgROx021688
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 6 Jan 2012 10:42:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q06FgR1c021686;
	Fri, 6 Jan 2012 10:42:27 -0500
Date: Fri, 6 Jan 2012 11:42:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120106154227.GB21220@andromeda.dapyr.net>
References: <20120105204126.GA29219@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120105204126.GA29219@aepfle.de>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] 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, Jan 05, 2012 at 09:41:26PM +0100, Olaf Hering wrote:
> Add 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.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Please resend and CC the maintainer and as well LKML.

> 
> ---
> 
> Note: the patch will be available via git://... once it was reviewed

huh?

> 
>  drivers/xen/xenbus/xenbus_xs.c     |   21 +++++++++++++++++++++
>  include/xen/interface/io/xs_wire.h |    3 ++-
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> Index: linux-3.2/drivers/xen/xenbus/xenbus_xs.c
> ===================================================================
> --- linux-3.2.orig/drivers/xen/xenbus/xenbus_xs.c
> +++ linux-3.2/drivers/xen/xenbus/xenbus_xs.c
> @@ -621,6 +621,23 @@ static struct xenbus_watch *find_watch(c
>  	return NULL;
>  }
>  
> +static void xs_reset_watches(void)
> +{
> +	int err, supported = 0;
> +
> +	if (!xen_hvm_domain())
> +		return;
> +
> +	err = xenbus_scanf(XBT_NIL, "control",
> +			"platform-feature-xs_reset_watches", "%d", &supported);
> +	if (err != 1 || !supported)
> +		return;
> +
> +	err = xs_error(xs_single(XBT_NIL, XS_RESET_WATCHES, "", NULL));
> +	if (err && err != -EEXIST)
> +		printk(KERN_WARNING "xs_reset_watches failed: %d\n", err);
> +}
> +
>  /* Register callback to watch this node. */
>  int register_xenbus_watch(struct xenbus_watch *watch)
>  {
> @@ -897,5 +915,8 @@ int xs_init(void)
>  	if (IS_ERR(task))
>  		return PTR_ERR(task);
>  
> +	/* shutdown watches for kexec boot */
> +	xs_reset_watches();
> +
>  	return 0;
>  }
> Index: linux-3.2/include/xen/interface/io/xs_wire.h
> ===================================================================
> --- linux-3.2.orig/include/xen/interface/io/xs_wire.h
> +++ linux-3.2/include/xen/interface/io/xs_wire.h
> @@ -29,7 +29,8 @@ enum xsd_sockmsg_type
>      XS_IS_DOMAIN_INTRODUCED,
>      XS_RESUME,
>      XS_SET_TARGET,
> -    XS_RESTRICT
> +    XS_RESTRICT,
> +    XS_RESET_WATCHES
>  };
>  
>  #define XS_WRITE_NONE "NONE"
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 06 15:43:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:43:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBwq-0008QO-AW; Fri, 06 Jan 2012 15:43:16 +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 1RjBwp-0008Q2-Ng
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:43:15 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325864587!9867044!1
X-Originating-IP: [216.32.181.182]
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 26578 invoked from network); 6 Jan 2012 15:43:08 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-2.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Jan 2012 15:43:08 -0000
Received: from mail84-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Jan 2012 15:43:06 +0000
Received: from mail84-ch1 (localhost [127.0.0.1])	by mail84-ch1-R.bigfish.com
	(Postfix) with ESMTP id B1B1B48038C	for
	<xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 15:43:05 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,0,
Received: from mail84-ch1 (localhost.localdomain [127.0.0.1]) by mail84-ch1
	(MessageSwitch) id 132586455667915_12245;
	Fri,  6 Jan 2012 15:42:36 +0000 (UTC)
Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.249])	by mail84-ch1.bigfish.com (Postfix) with ESMTP id
	08BC442041E for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 15:42:36 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Jan 2012 15:42:35 +0000
X-WSS-ID: 0LXDVMX-01-JXE-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 2ABBF102802E	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 09:42:33 -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, 6 Jan 2012 09:42:52 -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, 6 Jan 2012 09:42:33 -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; Fri, 6 Jan 2012
	10:42:13 -0500
Message-ID: <4F071654.3000102@amd.com>
Date: Fri, 6 Jan 2012 16:42: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------060704030607060908090807"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] netbsd: disable CONFIG_SYSTEM_LIBAIO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------060704030607060908090807
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Disable CONFIG_SYSTEM_LIBAIO on NetBSD.

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

--------------060704030607060908090807
Content-Type: text/plain; name="xen_libaio.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_libaio.diff"
Content-Description: xen_libaio.diff

diff -r 4086e4811547 config/NetBSD.mk
--- a/config/NetBSD.mk	Thu Jan 05 17:25:23 2012 +0000
+++ b/config/NetBSD.mk	Fri Jan 06 16:39:18 2012 +0100
@@ -16,3 +16,5 @@ XEN_LOCK_DIR = $(PREFIX)/var/lib
 endif
 
 WGET = ftp
+
+CONFIG_SYSTEM_LIBAIO = n

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

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

--------------060704030607060908090807--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:43:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:43:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBwq-0008QO-AW; Fri, 06 Jan 2012 15:43:16 +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 1RjBwp-0008Q2-Ng
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:43:15 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325864587!9867044!1
X-Originating-IP: [216.32.181.182]
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 26578 invoked from network); 6 Jan 2012 15:43:08 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-2.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Jan 2012 15:43:08 -0000
Received: from mail84-ch1-R.bigfish.com (10.43.68.252) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Jan 2012 15:43:06 +0000
Received: from mail84-ch1 (localhost [127.0.0.1])	by mail84-ch1-R.bigfish.com
	(Postfix) with ESMTP id B1B1B48038C	for
	<xen-devel@lists.xensource.com>; Fri, 6 Jan 2012 15:43:05 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dh668h839h34h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
X-FB-SS: 0,0,
Received: from mail84-ch1 (localhost.localdomain [127.0.0.1]) by mail84-ch1
	(MessageSwitch) id 132586455667915_12245;
	Fri,  6 Jan 2012 15:42:36 +0000 (UTC)
Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.249])	by mail84-ch1.bigfish.com (Postfix) with ESMTP id
	08BC442041E for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 15:42:36 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Jan 2012 15:42:35 +0000
X-WSS-ID: 0LXDVMX-01-JXE-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 2ABBF102802E	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 09:42:33 -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, 6 Jan 2012 09:42:52 -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, 6 Jan 2012 09:42:33 -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; Fri, 6 Jan 2012
	10:42:13 -0500
Message-ID: <4F071654.3000102@amd.com>
Date: Fri, 6 Jan 2012 16:42: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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------060704030607060908090807"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] netbsd: disable CONFIG_SYSTEM_LIBAIO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------060704030607060908090807
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Disable CONFIG_SYSTEM_LIBAIO on NetBSD.

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

--------------060704030607060908090807
Content-Type: text/plain; name="xen_libaio.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_libaio.diff"
Content-Description: xen_libaio.diff

diff -r 4086e4811547 config/NetBSD.mk
--- a/config/NetBSD.mk	Thu Jan 05 17:25:23 2012 +0000
+++ b/config/NetBSD.mk	Fri Jan 06 16:39:18 2012 +0100
@@ -16,3 +16,5 @@ XEN_LOCK_DIR = $(PREFIX)/var/lib
 endif
 
 WGET = ftp
+
+CONFIG_SYSTEM_LIBAIO = n

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

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

--------------060704030607060908090807--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:44:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBxb-0008Vl-1z; Fri, 06 Jan 2012 15:44:03 +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 1RjBxZ-0008Um-RR
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:44:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325864633!8102392!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcyOTE0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16730 invoked from network); 6 Jan 2012 15:43:55 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 15:43:55 -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
	q06Fhlpv001371
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 15:43:48 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
	q06Fhk5S004191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 15:43:47 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q06FhkBZ022488; Fri, 6 Jan 2012 09:43:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 07:43:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7EB4540943; Fri,  6 Jan 2012 10:02:44 -0500 (EST)
Date: Fri, 6 Jan 2012 10:02:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120106150244.GA5855@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
	<4F0566E2020000780006A89C@nat28.tlf.novell.com>
	<20120105212425.GA5180@phenom.dumpdata.com>
	<4F06B671020000780006AC26@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F06B671020000780006AC26@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F0716B5.0079,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Allen M Kay <allen.m.kay@intel.com>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
 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, Jan 06, 2012 at 07:53:05AM +0000, Jan Beulich wrote:
> >>> On 05.01.12 at 22:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Thu, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
> >> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> >> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> >> > with the latest upstream Linux kernel.
> >> > 
> >> > 
> >> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> >> > 2.6.18 kernel in blkback if you are using that version.
> >> 
> >> Which one are you referring to?
> > 
> > The fix you posted some time ago. Not all distros have picked it up.
> 
> Ah, okay, an already fixed one - you could have said "was" instead
> of "is" to not make people like me nervous...

Sorry - I saw it a couple of months ago with some of the cloudproviders so
it was still fresh in my mind.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:44:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBxb-0008Vl-1z; Fri, 06 Jan 2012 15:44:03 +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 1RjBxZ-0008Um-RR
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:44:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325864633!8102392!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcyOTE0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16730 invoked from network); 6 Jan 2012 15:43:55 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 15:43:55 -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
	q06Fhlpv001371
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 15:43:48 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
	q06Fhk5S004191
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 15:43:47 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q06FhkBZ022488; Fri, 6 Jan 2012 09:43:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 07:43:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7EB4540943; Fri,  6 Jan 2012 10:02:44 -0500 (EST)
Date: Fri, 6 Jan 2012 10:02:44 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120106150244.GA5855@phenom.dumpdata.com>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019CB9@ORSMSX105.amr.corp.intel.com>
	<20120104233524.GA31620@phenom.dumpdata.com>
	<4F0566E2020000780006A89C@nat28.tlf.novell.com>
	<20120105212425.GA5180@phenom.dumpdata.com>
	<4F06B671020000780006AC26@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F06B671020000780006AC26@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F0716B5.0079,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Allen M Kay <allen.m.kay@intel.com>, david.vrabel@citrix.com
Subject: Re: [Xen-devel] problems I encountered using xen-4.1-testing and
 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, Jan 06, 2012 at 07:53:05AM +0000, Jan Beulich wrote:
> >>> On 05.01.12 at 22:24, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Thu, Jan 05, 2012 at 08:01:22AM +0000, Jan Beulich wrote:
> >> >>> On 05.01.12 at 00:35, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > On Wed, Jan 04, 2012 at 10:07:29PM +0000, Kay, Allen M wrote:
> >> >> 2)      Xen-unstable:  I get ext4 file system corruption when booting xen 
> >> > with the latest upstream Linux kernel.
> >> > 
> >> > 
> >> > That I hadn't seen. Is this with dom0 or domU? There is one bug in the 
> >> > 2.6.18 kernel in blkback if you are using that version.
> >> 
> >> Which one are you referring to?
> > 
> > The fix you posted some time ago. Not all distros have picked it up.
> 
> Ah, okay, an already fixed one - you could have said "was" instead
> of "is" to not make people like me nervous...

Sorry - I saw it a couple of months ago with some of the cloudproviders so
it was still fresh in my mind.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:44:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:44:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBxc-0008W6-Em; Fri, 06 Jan 2012 15:44:04 +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 1RjBxa-0008Ut-9a
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:44:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325864632!9370188!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NzgzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9132 invoked from network); 6 Jan 2012 15:43:53 -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; 6 Jan 2012 15:43:53 -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
	q06FhmVr001573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 15:43:49 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
	q06FhkfS004189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 15:43:47 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
	q06Fhk7v013559; Fri, 6 Jan 2012 09:43:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 07:43:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E523540944; Fri,  6 Jan 2012 10:03:38 -0500 (EST)
Date: Fri, 6 Jan 2012 10:03:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20120106150338.GB5855@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F06C101020000780006AC32@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.0A090208.4F0716B5.00E6,ss=1,re=0.000,fgs=0
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 08:38:09AM +0000, Jan Beulich wrote:
> >>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > When a PCI device is transferred to another domain and it is still
> > in usage (from the internal perspective), mention which other
> > domain is using it to aid in debugging.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
> >  1 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > index 474d52e..fa130bd 100644
> > --- a/drivers/xen/xen-pciback/xenbus.c
> > +++ b/drivers/xen/xen-pciback/xenbus.c
> > @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
> > xen_pcibk_device *pdev,
> >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> >  	if (xen_register_device_domain_owner(dev,
> >  					     pdev->xdev->otherend_id) != 0) {
> > -		dev_err(&dev->dev, "device has been assigned to another " \
> > -			"domain! Over-writting the ownership, but beware.\n");
> > +		int other_domain = xen_find_device_domain_owner(dev);
> > +		dev_err(&dev->dev, "device has been assigned to %d " \
> > +			"domain! Over-writting the ownership, but beware.\n",
> > +			other_domain);
> 
> As you're touching this anyway, how about fixing the other minor
> issues with it too? E.g.
> 
> 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
> 			" Overwriting the ownership, but beware.\n",
> 			xen_find_device_domain_owner(dev));
> 
> (a native English speaker may want to comment the "but beware"
> part - it reads odd for me).

Hm, lets ask the English speakers. Ian?

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:44:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:44:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBxc-0008W6-Em; Fri, 06 Jan 2012 15:44:04 +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 1RjBxa-0008Ut-9a
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:44:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1325864632!9370188!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NzgzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9132 invoked from network); 6 Jan 2012 15:43:53 -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; 6 Jan 2012 15:43:53 -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
	q06FhmVr001573
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 15:43:49 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
	q06FhkfS004189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 15:43:47 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
	q06Fhk7v013559; Fri, 6 Jan 2012 09:43:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 07:43:46 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E523540944; Fri,  6 Jan 2012 10:03:38 -0500 (EST)
Date: Fri, 6 Jan 2012 10:03:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20120106150338.GB5855@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F06C101020000780006AC32@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.0A090208.4F0716B5.00E6,ss=1,re=0.000,fgs=0
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 08:38:09AM +0000, Jan Beulich wrote:
> >>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > When a PCI device is transferred to another domain and it is still
> > in usage (from the internal perspective), mention which other
> > domain is using it to aid in debugging.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
> >  1 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > index 474d52e..fa130bd 100644
> > --- a/drivers/xen/xen-pciback/xenbus.c
> > +++ b/drivers/xen/xen-pciback/xenbus.c
> > @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
> > xen_pcibk_device *pdev,
> >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> >  	if (xen_register_device_domain_owner(dev,
> >  					     pdev->xdev->otherend_id) != 0) {
> > -		dev_err(&dev->dev, "device has been assigned to another " \
> > -			"domain! Over-writting the ownership, but beware.\n");
> > +		int other_domain = xen_find_device_domain_owner(dev);
> > +		dev_err(&dev->dev, "device has been assigned to %d " \
> > +			"domain! Over-writting the ownership, but beware.\n",
> > +			other_domain);
> 
> As you're touching this anyway, how about fixing the other minor
> issues with it too? E.g.
> 
> 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
> 			" Overwriting the ownership, but beware.\n",
> 			xen_find_device_domain_owner(dev));
> 
> (a native English speaker may want to comment the "but beware"
> part - it reads odd for me).

Hm, lets ask the English speakers. Ian?

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:44:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBxc-0008WQ-Ra; Fri, 06 Jan 2012 15:44:04 +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 1RjBxa-0008Ux-Sv
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:44:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325864635!9867975!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcyOTE0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6734 invoked from network); 6 Jan 2012 15:43:56 -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; 6 Jan 2012 15:43:56 -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
	q06Fhl6h001365
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 15:43:48 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
	q06FhjQn004174
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 15:43:46 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
	q06FhjBu022474; Fri, 6 Jan 2012 09:43:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 07:43:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DD17F40945; Fri,  6 Jan 2012 10:07:01 -0500 (EST)
Date: Fri, 6 Jan 2012 10:07:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120106150701.GC5855@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201061231150.3150@kaball-desktop>
	<c802fb58-5067-4075-80b3-ca8004005364@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c802fb58-5067-4075-80b3-ca8004005364@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F0716B4.00C4,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 reason to remove is easy: it is already a silent option and
> > disabling it saves almost nothing.
> > I think that removing it should be easy enough but if you don't
> > feel confident doing it, I can come up with a patch.
> > 
> 
> I'll write the patch. It's not the patch I thought would be hard to
> do (although I'll only be posting it compile tested, as I don't
> have an environment where I can test it set up). What I thought would

Um.. Fedora Core 16?

> be difficult is the justification. However, considering you're
> advocating it, I guess I'm good there too.

We don't bite :-)

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:44:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjBxc-0008WQ-Ra; Fri, 06 Jan 2012 15:44:04 +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 1RjBxa-0008Ux-Sv
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:44:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1325864635!9867975!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDcyOTE0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6734 invoked from network); 6 Jan 2012 15:43:56 -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; 6 Jan 2012 15:43:56 -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
	q06Fhl6h001365
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 15:43:48 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
	q06FhjQn004174
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 15:43:46 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
	q06FhjBu022474; Fri, 6 Jan 2012 09:43:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 07:43:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DD17F40945; Fri,  6 Jan 2012 10:07:01 -0500 (EST)
Date: Fri, 6 Jan 2012 10:07:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120106150701.GC5855@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201061231150.3150@kaball-desktop>
	<c802fb58-5067-4075-80b3-ca8004005364@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c802fb58-5067-4075-80b3-ca8004005364@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F0716B4.00C4,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 reason to remove is easy: it is already a silent option and
> > disabling it saves almost nothing.
> > I think that removing it should be easy enough but if you don't
> > feel confident doing it, I can come up with a patch.
> > 
> 
> I'll write the patch. It's not the patch I thought would be hard to
> do (although I'll only be posting it compile tested, as I don't
> have an environment where I can test it set up). What I thought would

Um.. Fedora Core 16?

> be difficult is the justification. However, considering you're
> advocating it, I guess I'm good there too.

We don't bite :-)

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:44:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjByE-0000Fk-H3; Fri, 06 Jan 2012 15:44:42 +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 1RjByD-0000E2-B8
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:44:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325864674!9862102!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NzgzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15081 invoked from network); 6 Jan 2012 15:44:35 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 15:44:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q06Fhlqu001562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 15:43: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
	q06Fhkv1014138
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 15:43:46 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
	q06FhjjQ031849; Fri, 6 Jan 2012 09:43:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 07:43:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EC6DF40937; Fri,  6 Jan 2012 09:37:19 -0500 (EST)
Date: Fri, 6 Jan 2012 09:37:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120106143719.GA5078@phenom.dumpdata.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F0716B4.0075,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> > > I hadn't seen it... but then my main desktop box where I run intensive
> > > tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
> > > The box that has i915 just does some simple framebuffer manipulation and
> > > that looks OK.
> > 
> > yes, framebuffer console works well in my side too.

Good.
> > > Do you see the same symptoms - checkboard screen?
> > 
> > Not exactly. The screen becomes white, and then the system becomes
> > unstable and hang several minutes later. It's possible that mine is a
> > different issue than listed on the wiki page, since many reasons may
> > finally reach the same symptom - GPU hang... :/
> 
> well, there happens once with a checkboard screen, with the rest all
> white screens.
> 
> > 
> > >
> > > The LKML had some fixes for this from Keith Packard. Something about
> > > using i915.semaphores=0 I think. And I thought I saw some fixes for
> > > 3.2-rc7 for this but not sure..
> > 
> > I'll have a try on latest Linux on this. But I suspect that this may be a
> > virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case),
> > because same dom0 image could run glxgear smoothly on bare metal.
> > 
> 
> I used latest 3.2 release, no difference.

What is the motherboard you have? I just bought an "DQ67SW" which perhaps
has the same video card?


But more interestingly - are you building your kernel from scratch? There
was some requirements in having CONFIG_IOMMU_DMAR in the kernels - otherwise
the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.

And that caused an endless amount of pain.
> 
> i915.semaphores=0 has no effect.
> 
> But I observed below warnings in the boot process:
> [    8.872430] [drm] MTRR allocation failed.  Graphics performance may suffer.
> [   18.384552] microcode: CPU0 update to revision 0x1b failed
> 
> Not sure whether above two issues may have impact on the said problem. 
> I know microcode update is still missing in upstream, but not sure about any

Right, microcode is ... pending hpa's coming back from paternity leave.
> MTRR specific pending patches.

The MTRR are not in, but the graphics code should still work.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:44:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:44:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjByE-0000Fk-H3; Fri, 06 Jan 2012 15:44:42 +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 1RjByD-0000E2-B8
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:44:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325864674!9862102!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NzgzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15081 invoked from network); 6 Jan 2012 15:44:35 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 15:44:35 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q06Fhlqu001562
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 15:43: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
	q06Fhkv1014138
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 15:43:46 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
	q06FhjjQ031849; Fri, 6 Jan 2012 09:43:46 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 07:43:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id EC6DF40937; Fri,  6 Jan 2012 09:37:19 -0500 (EST)
Date: Fri, 6 Jan 2012 09:37:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120106143719.GA5078@phenom.dumpdata.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F0716B4.0075,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> > > I hadn't seen it... but then my main desktop box where I run intensive
> > > tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
> > > The box that has i915 just does some simple framebuffer manipulation and
> > > that looks OK.
> > 
> > yes, framebuffer console works well in my side too.

Good.
> > > Do you see the same symptoms - checkboard screen?
> > 
> > Not exactly. The screen becomes white, and then the system becomes
> > unstable and hang several minutes later. It's possible that mine is a
> > different issue than listed on the wiki page, since many reasons may
> > finally reach the same symptom - GPU hang... :/
> 
> well, there happens once with a checkboard screen, with the rest all
> white screens.
> 
> > 
> > >
> > > The LKML had some fixes for this from Keith Packard. Something about
> > > using i915.semaphores=0 I think. And I thought I saw some fixes for
> > > 3.2-rc7 for this but not sure..
> > 
> > I'll have a try on latest Linux on this. But I suspect that this may be a
> > virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case),
> > because same dom0 image could run glxgear smoothly on bare metal.
> > 
> 
> I used latest 3.2 release, no difference.

What is the motherboard you have? I just bought an "DQ67SW" which perhaps
has the same video card?


But more interestingly - are you building your kernel from scratch? There
was some requirements in having CONFIG_IOMMU_DMAR in the kernels - otherwise
the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.

And that caused an endless amount of pain.
> 
> i915.semaphores=0 has no effect.
> 
> But I observed below warnings in the boot process:
> [    8.872430] [drm] MTRR allocation failed.  Graphics performance may suffer.
> [   18.384552] microcode: CPU0 update to revision 0x1b failed
> 
> Not sure whether above two issues may have impact on the said problem. 
> I know microcode update is still missing in upstream, but not sure about any

Right, microcode is ... pending hpa's coming back from paternity leave.
> MTRR specific pending patches.

The MTRR are not in, but the graphics code should still work.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:47:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjC0O-0000jA-6X; Fri, 06 Jan 2012 15:46:56 +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 1RjC0M-0000iU-Uk
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:46:55 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325864806!9883615!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 9735 invoked from network); 6 Jan 2012 15:46:47 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 15:46:47 -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
	q06Fkegx021930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 6 Jan 2012 10:46:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q06Fke1Q021928;
	Fri, 6 Jan 2012 10:46:40 -0500
Date: Fri, 6 Jan 2012 11:46:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120106154640.GC21220@andromeda.dapyr.net>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-3-git-send-email-drjones@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325842991-4404-3-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

You need to CC as well these people that have 'maintainer' field on them:

konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
drivers/video/Kconfig
Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
(maintainer:FRAMEBUFFER LAYER)
linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
linux-kernel@vger.kernel.org (open list)
konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
drivers/input/misc/Kconfig
Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT
(KEYBOARD,...,commit_signer:9/16=56%)
Samuel Ortiz <sameo@linux.intel.com> (commit_signer:3/16=19%)
Anirudh Ghayal <aghayal@codeaurora.org> (commit_signer:2/16=12%)
Peter Ujfalusi <peter.ujfalusi@ti.com> (commit_signer:2/16=12%)
Alan Cox <alan@linux.intel.com> (commit_signer:2/16=12%)
linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
linux-kernel@vger.kernel.org (open list)

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..269b299 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> +	select INPUT_XEN_KBDDEV_FRONTEND
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:47:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:47:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjC0O-0000jA-6X; Fri, 06 Jan 2012 15:46:56 +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 1RjC0M-0000iU-Uk
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:46:55 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325864806!9883615!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 9735 invoked from network); 6 Jan 2012 15:46:47 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 15:46:47 -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
	q06Fkegx021930
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 6 Jan 2012 10:46:40 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q06Fke1Q021928;
	Fri, 6 Jan 2012 10:46:40 -0500
Date: Fri, 6 Jan 2012 11:46:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120106154640.GC21220@andromeda.dapyr.net>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-3-git-send-email-drjones@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325842991-4404-3-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

You need to CC as well these people that have 'maintainer' field on them:

konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
drivers/video/Kconfig
Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
(maintainer:FRAMEBUFFER LAYER)
linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
linux-kernel@vger.kernel.org (open list)
konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
drivers/input/misc/Kconfig
Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT
(KEYBOARD,...,commit_signer:9/16=56%)
Samuel Ortiz <sameo@linux.intel.com> (commit_signer:3/16=19%)
Anirudh Ghayal <aghayal@codeaurora.org> (commit_signer:2/16=12%)
Peter Ujfalusi <peter.ujfalusi@ti.com> (commit_signer:2/16=12%)
Alan Cox <alan@linux.intel.com> (commit_signer:2/16=12%)
linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
linux-kernel@vger.kernel.org (open list)

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..269b299 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> +	select INPUT_XEN_KBDDEV_FRONTEND
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:50:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjC3g-00016q-Rl; Fri, 06 Jan 2012 15:50: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 1RjC3f-00016Y-S9
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:50:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325865013!8065268!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 7381 invoked from network); 6 Jan 2012 15:50:13 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 15:50:13 -0000
Received: by werg1 with SMTP id g1so3558915wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 07:50:13 -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=mnjyRPs1pPPE5/p1g4i2sQh/W/tuW5haD96OFFYRin0=;
	b=MuzJeWNnqC9HrVoWCHMOTkiqTLFnznAKGHLE5twLTxIAtwiMGGl9pMxiEwtypZPduf
	nZomhb1zbUeRgmNUnHkhd+81NOkh+RBscHuZ9DrOP8awOAIepSlS2DWf0HojozMFjM1y
	0e6rY0mamLk7rnG11nwg4bBIe2JjFaBqAe810=
Received: by 10.216.136.156 with SMTP id w28mr3359822wei.11.1325865013643;
	Fri, 06 Jan 2012 07:50:13 -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 ba4sm49837564wib.5.2012.01.06.07.50.11
	(version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 07:50:12 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 06 Jan 2012 15:50:04 +0000
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <CB2CC8AC.36FD5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
	to include domain id.
Thread-Index: AczMitsU40GbprNDNUy/g9RSFnMGSg==
In-Reply-To: <20120106150338.GB5855@phenom.dumpdata.com>
Mime-version: 1.0
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/01/2012 15:03, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:

>> As you're touching this anyway, how about fixing the other minor
>> issues with it too? E.g.
>> 
>> dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
>> " Overwriting the ownership, but beware.\n",
>> xen_find_device_domain_owner(dev));
>> 
>> (a native English speaker may want to comment the "but beware"
>> part - it reads odd for me).
> 
> Hm, lets ask the English speakers. Ian?

The suggested reworking above is an improvement. The "but beware" bit is
fine.

 -- keir



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:50:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:50:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjC3g-00016q-Rl; Fri, 06 Jan 2012 15:50: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 1RjC3f-00016Y-S9
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:50:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1325865013!8065268!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 7381 invoked from network); 6 Jan 2012 15:50:13 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 15:50:13 -0000
Received: by werg1 with SMTP id g1so3558915wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 07:50:13 -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=mnjyRPs1pPPE5/p1g4i2sQh/W/tuW5haD96OFFYRin0=;
	b=MuzJeWNnqC9HrVoWCHMOTkiqTLFnznAKGHLE5twLTxIAtwiMGGl9pMxiEwtypZPduf
	nZomhb1zbUeRgmNUnHkhd+81NOkh+RBscHuZ9DrOP8awOAIepSlS2DWf0HojozMFjM1y
	0e6rY0mamLk7rnG11nwg4bBIe2JjFaBqAe810=
Received: by 10.216.136.156 with SMTP id w28mr3359822wei.11.1325865013643;
	Fri, 06 Jan 2012 07:50:13 -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 ba4sm49837564wib.5.2012.01.06.07.50.11
	(version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 07:50:12 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 06 Jan 2012 15:50:04 +0000
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jan Beulich <JBeulich@suse.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <CB2CC8AC.36FD5%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
	to include domain id.
Thread-Index: AczMitsU40GbprNDNUy/g9RSFnMGSg==
In-Reply-To: <20120106150338.GB5855@phenom.dumpdata.com>
Mime-version: 1.0
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org, jbarnes@virtuousgeek.org
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 06/01/2012 15:03, "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com> wrote:

>> As you're touching this anyway, how about fixing the other minor
>> issues with it too? E.g.
>> 
>> dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
>> " Overwriting the ownership, but beware.\n",
>> xen_find_device_domain_owner(dev));
>> 
>> (a native English speaker may want to comment the "but beware"
>> part - it reads odd for me).
> 
> Hm, lets ask the English speakers. Ian?

The suggested reworking above is an improvement. The "but beware" bit is
fine.

 -- keir



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:51:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjC4v-0001BK-B3; Fri, 06 Jan 2012 15:51:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RjC4u-0001Aq-44
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:51:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325865086!9958491!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25245 invoked from network); 6 Jan 2012 15:51:29 -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;
	6 Jan 2012 15:51:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9868155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 15: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; Fri, 6 Jan 2012
	15:51:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 6 Jan 2012 15:51:25 +0000
In-Reply-To: <20120106150338.GB5855@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325865086.25206.512.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 15:03 +0000, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 08:38:09AM +0000, Jan Beulich wrote:
> > >>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > When a PCI device is transferred to another domain and it is still
> > > in usage (from the internal perspective), mention which other
> > > domain is using it to aid in debugging.
> > > 
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
> > >  1 files changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > > index 474d52e..fa130bd 100644
> > > --- a/drivers/xen/xen-pciback/xenbus.c
> > > +++ b/drivers/xen/xen-pciback/xenbus.c
> > > @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
> > > xen_pcibk_device *pdev,
> > >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> > >  	if (xen_register_device_domain_owner(dev,
> > >  					     pdev->xdev->otherend_id) != 0) {
> > > -		dev_err(&dev->dev, "device has been assigned to another " \
> > > -			"domain! Over-writting the ownership, but beware.\n");
> > > +		int other_domain = xen_find_device_domain_owner(dev);
> > > +		dev_err(&dev->dev, "device has been assigned to %d " \
> > > +			"domain! Over-writting the ownership, but beware.\n",
> > > +			other_domain);
> > 
> > As you're touching this anyway, how about fixing the other minor
> > issues with it too? E.g.
> > 
> > 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
> > 			" Overwriting the ownership, but beware.\n",
> > 			xen_find_device_domain_owner(dev));
> > 
> > (a native English speaker may want to comment the "but beware"
> > part - it reads odd for me).
> 
> Hm, lets ask the English speakers. Ian?

I think you underestimate a native speakers ability to mangle a
language. Especially this one ;-)

Anyway, I think it's unnecessary, so you may as well drop it and just
have:

 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
 			" Overwriting the ownership.\n",
 			xen_find_device_domain_owner(dev));

I suppose you might want "Overriding ownership to dom%d".

Ian.


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:51:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15:51:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjC4v-0001BK-B3; Fri, 06 Jan 2012 15:51:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RjC4u-0001Aq-44
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:51:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325865086!9958491!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25245 invoked from network); 6 Jan 2012 15:51:29 -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;
	6 Jan 2012 15:51:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9868155"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 15: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; Fri, 6 Jan 2012
	15:51:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 6 Jan 2012 15:51:25 +0000
In-Reply-To: <20120106150338.GB5855@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325865086.25206.512.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 15:03 +0000, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 08:38:09AM +0000, Jan Beulich wrote:
> > >>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > When a PCI device is transferred to another domain and it is still
> > > in usage (from the internal perspective), mention which other
> > > domain is using it to aid in debugging.
> > > 
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
> > >  1 files changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > > index 474d52e..fa130bd 100644
> > > --- a/drivers/xen/xen-pciback/xenbus.c
> > > +++ b/drivers/xen/xen-pciback/xenbus.c
> > > @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
> > > xen_pcibk_device *pdev,
> > >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> > >  	if (xen_register_device_domain_owner(dev,
> > >  					     pdev->xdev->otherend_id) != 0) {
> > > -		dev_err(&dev->dev, "device has been assigned to another " \
> > > -			"domain! Over-writting the ownership, but beware.\n");
> > > +		int other_domain = xen_find_device_domain_owner(dev);
> > > +		dev_err(&dev->dev, "device has been assigned to %d " \
> > > +			"domain! Over-writting the ownership, but beware.\n",
> > > +			other_domain);
> > 
> > As you're touching this anyway, how about fixing the other minor
> > issues with it too? E.g.
> > 
> > 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
> > 			" Overwriting the ownership, but beware.\n",
> > 			xen_find_device_domain_owner(dev));
> > 
> > (a native English speaker may want to comment the "but beware"
> > part - it reads odd for me).
> 
> Hm, lets ask the English speakers. Ian?

I think you underestimate a native speakers ability to mangle a
language. Especially this one ;-)

Anyway, I think it's unnecessary, so you may as well drop it and just
have:

 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
 			" Overwriting the ownership.\n",
 			xen_find_device_domain_owner(dev));

I suppose you might want "Overriding ownership to dom%d".

Ian.


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:58:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15: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 1RjCBR-0001T9-7N; Fri, 06 Jan 2012 15:58:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1RjCBQ-0001T4-5f
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:58:20 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325865493!9855283!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 16755 invoked from network); 6 Jan 2012 15:58:14 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 15:58:14 -0000
Received: by qabg27 with SMTP id g27so6796729qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 07:58:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.179.148 with SMTP id bq20mr6462959qab.78.1325865492586;
	Fri, 06 Jan 2012 07:58:12 -0800 (PST)
Received: by 10.229.39.134 with HTTP; Fri, 6 Jan 2012 07:58:12 -0800 (PST)
In-Reply-To: <4F06F76F.7090002@web.de>
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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
Date: Fri, 6 Jan 2012 15:58:12 +0000
Message-ID: <CAFEAcA-A7YujsGDpGezxeNmB9z5rG=Rtp7UHX1R5wWoL=wukwA@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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 6 January 2012 13:30, Jan Kiszka <jan.kiszka@web.de> wrote:
> The third point indicates that there is rather more generic room for
> improvements: Why should qemu reset device models before restore at all?

Commit 5a8a49d7aa says:
# if we load from a snapshot, the machine can be in any state. That can
# cause troubles if loading an older image which does not carry all state
# information the executing QEMU requires. Hardly any device takes care of
# this scenario.

I think it's also easier to reason about devices if you know that the
device before a load was in a known clean state rather than being
anything at all.

-- PMM

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:58:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15: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 1RjCBR-0001T9-7N; Fri, 06 Jan 2012 15:58:21 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <peter.maydell@linaro.org>) id 1RjCBQ-0001T4-5f
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:58:20 +0000
X-Env-Sender: peter.maydell@linaro.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325865493!9855283!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 16755 invoked from network); 6 Jan 2012 15:58:14 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 15:58:14 -0000
Received: by qabg27 with SMTP id g27so6796729qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 07:58:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.179.148 with SMTP id bq20mr6462959qab.78.1325865492586;
	Fri, 06 Jan 2012 07:58:12 -0800 (PST)
Received: by 10.229.39.134 with HTTP; Fri, 6 Jan 2012 07:58:12 -0800 (PST)
In-Reply-To: <4F06F76F.7090002@web.de>
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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
Date: Fri, 6 Jan 2012 15:58:12 +0000
Message-ID: <CAFEAcA-A7YujsGDpGezxeNmB9z5rG=Rtp7UHX1R5wWoL=wukwA@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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 6 January 2012 13:30, Jan Kiszka <jan.kiszka@web.de> wrote:
> The third point indicates that there is rather more generic room for
> improvements: Why should qemu reset device models before restore at all?

Commit 5a8a49d7aa says:
# if we load from a snapshot, the machine can be in any state. That can
# cause troubles if loading an older image which does not carry all state
# information the executing QEMU requires. Hardly any device takes care of
# this scenario.

I think it's also easier to reason about devices if you know that the
device before a load was in a known clean state rather than being
anything at all.

-- PMM

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:59:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15: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 1RjCC9-0001VZ-LG; Fri, 06 Jan 2012 15:59:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RjCC8-0001VC-7v
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:59:04 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325865537!10420021!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjMzOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29567 invoked from network); 6 Jan 2012 15:58:58 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-11.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 15:58:58 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q06Fw664030467;
	Fri, 6 Jan 2012 10:58:06 -0500
Date: Fri, 06 Jan 2012 10:58:06 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <da05c51a-a541-4edd-8356-f0b5d2af0c03@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120106154640.GC21220@andromeda.dapyr.net>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>, FlorianSchandinat@gmx.de,
	dmitry.torokhov@gmail.com, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
> > but
> > they don't use the xen frame buffer frontend. For this case it
> > doesn't
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
> > i.e.
> > if you're using xenfb, then you'll want xenkbd. Switch the
> > dependencies.
> 
> You need to CC as well these people that have 'maintainer' field on
> them:
> 
> konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> drivers/video/Kconfig
> Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> (maintainer:FRAMEBUFFER LAYER)
> linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
> linux-kernel@vger.kernel.org (open list)
> konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> drivers/input/misc/Kconfig
> Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT
> (KEYBOARD,...,commit_signer:9/16=56%)
> Samuel Ortiz <sameo@linux.intel.com> (commit_signer:3/16=19%)
> Anirudh Ghayal <aghayal@codeaurora.org> (commit_signer:2/16=12%)
> Peter Ujfalusi <peter.ujfalusi@ti.com> (commit_signer:2/16=12%)
> Alan Cox <alan@linux.intel.com> (commit_signer:2/16=12%)
> linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
> linux-kernel@vger.kernel.org (open list)
> 

Thanks. Replied with them in CC.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/input/misc/Kconfig |    2 +-
> >  drivers/video/Kconfig      |    1 +
> >  2 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/input/misc/Kconfig
> > b/drivers/input/misc/Kconfig
> > index 22d875f..36c15bf 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> >  
> >  config INPUT_XEN_KBDDEV_FRONTEND
> >  	tristate "Xen virtual keyboard and mouse support"
> > -	depends on XEN_FBDEV_FRONTEND
> > +	depends on XEN
> >  	default y
> >  	select XEN_XENBUS_FRONTEND
> >  	help
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index d83e967..269b299 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
> >  	select FB_SYS_IMAGEBLIT
> >  	select FB_SYS_FOPS
> >  	select FB_DEFERRED_IO
> > +	select INPUT_XEN_KBDDEV_FRONTEND
> >  	select XEN_XENBUS_FRONTEND
> >  	default y
> >  	help
> > --
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 15:59:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 15: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 1RjCC9-0001VZ-LG; Fri, 06 Jan 2012 15:59:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RjCC8-0001VC-7v
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 15:59:04 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325865537!10420021!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjMzOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29567 invoked from network); 6 Jan 2012 15:58:58 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-11.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 15:58:58 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q06Fw664030467;
	Fri, 6 Jan 2012 10:58:06 -0500
Date: Fri, 06 Jan 2012 10:58:06 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <da05c51a-a541-4edd-8356-f0b5d2af0c03@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120106154640.GC21220@andromeda.dapyr.net>
MIME-Version: 1.0
X-Originating-IP: [10.36.4.188]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>, FlorianSchandinat@gmx.de,
	dmitry.torokhov@gmail.com, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
> > but
> > they don't use the xen frame buffer frontend. For this case it
> > doesn't
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
> > i.e.
> > if you're using xenfb, then you'll want xenkbd. Switch the
> > dependencies.
> 
> You need to CC as well these people that have 'maintainer' field on
> them:
> 
> konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> drivers/video/Kconfig
> Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> (maintainer:FRAMEBUFFER LAYER)
> linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
> linux-kernel@vger.kernel.org (open list)
> konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> drivers/input/misc/Kconfig
> Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT
> (KEYBOARD,...,commit_signer:9/16=56%)
> Samuel Ortiz <sameo@linux.intel.com> (commit_signer:3/16=19%)
> Anirudh Ghayal <aghayal@codeaurora.org> (commit_signer:2/16=12%)
> Peter Ujfalusi <peter.ujfalusi@ti.com> (commit_signer:2/16=12%)
> Alan Cox <alan@linux.intel.com> (commit_signer:2/16=12%)
> linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
> linux-kernel@vger.kernel.org (open list)
> 

Thanks. Replied with them in CC.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/input/misc/Kconfig |    2 +-
> >  drivers/video/Kconfig      |    1 +
> >  2 files changed, 2 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/input/misc/Kconfig
> > b/drivers/input/misc/Kconfig
> > index 22d875f..36c15bf 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> >  
> >  config INPUT_XEN_KBDDEV_FRONTEND
> >  	tristate "Xen virtual keyboard and mouse support"
> > -	depends on XEN_FBDEV_FRONTEND
> > +	depends on XEN
> >  	default y
> >  	select XEN_XENBUS_FRONTEND
> >  	help
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index d83e967..269b299 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
> >  	select FB_SYS_IMAGEBLIT
> >  	select FB_SYS_FOPS
> >  	select FB_DEFERRED_IO
> > +	select INPUT_XEN_KBDDEV_FRONTEND
> >  	select XEN_XENBUS_FRONTEND
> >  	default y
> >  	help
> > --
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:02:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16: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 1RjCF1-0002CK-Fn; Fri, 06 Jan 2012 16:02: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 1RjCEz-0002Bs-Lv
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:02:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325865714!9918588!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NzgzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31235 invoked from network); 6 Jan 2012 16:01:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 16:01: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
	q06G1pgv024795
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 16:01:52 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q06G1op8001495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 16:01:50 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
	q06G1nLD026635; Fri, 6 Jan 2012 10:01:49 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 08:01:49 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2B1C740930; Fri,  6 Jan 2012 11:00:11 -0500 (EST)
Date: Fri, 6 Jan 2012 11:00:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120106160011.GD6125@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325865086.25206.512.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020202.4F071AF0.018B,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 03:51:25PM +0000, Ian Campbell wrote:
> On Fri, 2012-01-06 at 15:03 +0000, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 06, 2012 at 08:38:09AM +0000, Jan Beulich wrote:
> > > >>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > > When a PCI device is transferred to another domain and it is still
> > > > in usage (from the internal perspective), mention which other
> > > > domain is using it to aid in debugging.
> > > > 
> > > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > ---
> > > >  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
> > > >  1 files changed, 4 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > > > index 474d52e..fa130bd 100644
> > > > --- a/drivers/xen/xen-pciback/xenbus.c
> > > > +++ b/drivers/xen/xen-pciback/xenbus.c
> > > > @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
> > > > xen_pcibk_device *pdev,
> > > >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> > > >  	if (xen_register_device_domain_owner(dev,
> > > >  					     pdev->xdev->otherend_id) != 0) {
> > > > -		dev_err(&dev->dev, "device has been assigned to another " \
> > > > -			"domain! Over-writting the ownership, but beware.\n");
> > > > +		int other_domain = xen_find_device_domain_owner(dev);
> > > > +		dev_err(&dev->dev, "device has been assigned to %d " \
> > > > +			"domain! Over-writting the ownership, but beware.\n",
> > > > +			other_domain);
> > > 
> > > As you're touching this anyway, how about fixing the other minor
> > > issues with it too? E.g.
> > > 
> > > 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
> > > 			" Overwriting the ownership, but beware.\n",
> > > 			xen_find_device_domain_owner(dev));
> > > 
> > > (a native English speaker may want to comment the "but beware"
> > > part - it reads odd for me).
> > 
> > Hm, lets ask the English speakers. Ian?
> 
> I think you underestimate a native speakers ability to mangle a
> language. Especially this one ;-)
> 
> Anyway, I think it's unnecessary, so you may as well drop it and just
> have:
> 
>  		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
>  			" Overwriting the ownership.\n",
>  			xen_find_device_domain_owner(dev));
> 
> I suppose you might want "Overriding ownership to dom%d".

OK. To the point and potentially can fit in 80 lines :-).

Will spin out the patch next week-sih.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:02:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16: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 1RjCF1-0002CK-Fn; Fri, 06 Jan 2012 16:02: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 1RjCEz-0002Bs-Lv
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:02:01 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325865714!9918588!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NzgzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31235 invoked from network); 6 Jan 2012 16:01:55 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 16:01: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
	q06G1pgv024795
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 16:01:52 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q06G1op8001495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 16:01:50 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
	q06G1nLD026635; Fri, 6 Jan 2012 10:01:49 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 08:01:49 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2B1C740930; Fri,  6 Jan 2012 11:00:11 -0500 (EST)
Date: Fri, 6 Jan 2012 11:00:11 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120106160011.GD6125@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325865086.25206.512.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A020202.4F071AF0.018B,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 03:51:25PM +0000, Ian Campbell wrote:
> On Fri, 2012-01-06 at 15:03 +0000, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jan 06, 2012 at 08:38:09AM +0000, Jan Beulich wrote:
> > > >>> On 05.01.12 at 01:46, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > > When a PCI device is transferred to another domain and it is still
> > > > in usage (from the internal perspective), mention which other
> > > > domain is using it to aid in debugging.
> > > > 
> > > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > > ---
> > > >  drivers/xen/xen-pciback/xenbus.c |    6 ++++--
> > > >  1 files changed, 4 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > > > index 474d52e..fa130bd 100644
> > > > --- a/drivers/xen/xen-pciback/xenbus.c
> > > > +++ b/drivers/xen/xen-pciback/xenbus.c
> > > > @@ -243,8 +243,10 @@ static int xen_pcibk_export_device(struct 
> > > > xen_pcibk_device *pdev,
> > > >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> > > >  	if (xen_register_device_domain_owner(dev,
> > > >  					     pdev->xdev->otherend_id) != 0) {
> > > > -		dev_err(&dev->dev, "device has been assigned to another " \
> > > > -			"domain! Over-writting the ownership, but beware.\n");
> > > > +		int other_domain = xen_find_device_domain_owner(dev);
> > > > +		dev_err(&dev->dev, "device has been assigned to %d " \
> > > > +			"domain! Over-writting the ownership, but beware.\n",
> > > > +			other_domain);
> > > 
> > > As you're touching this anyway, how about fixing the other minor
> > > issues with it too? E.g.
> > > 
> > > 		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
> > > 			" Overwriting the ownership, but beware.\n",
> > > 			xen_find_device_domain_owner(dev));
> > > 
> > > (a native English speaker may want to comment the "but beware"
> > > part - it reads odd for me).
> > 
> > Hm, lets ask the English speakers. Ian?
> 
> I think you underestimate a native speakers ability to mangle a
> language. Especially this one ;-)
> 
> Anyway, I think it's unnecessary, so you may as well drop it and just
> have:
> 
>  		dev_err(&dev->dev, "Device appears to be assigned to dom%d!"
>  			" Overwriting the ownership.\n",
>  			xen_find_device_domain_owner(dev));
> 
> I suppose you might want "Overriding ownership to dom%d".

OK. To the point and potentially can fit in 80 lines :-).

Will spin out the patch next week-sih.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:03:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCGJ-0002KH-VE; Fri, 06 Jan 2012 16:03:23 +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 1RjCGJ-0002Jr-Cl
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:03:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325865796!2548232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7123 invoked from network); 6 Jan 2012 16:03:17 -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;
	6 Jan 2012 16:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9868417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 16:03:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 16:03:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RjCGB-0001pt-S4; Fri, 06 Jan 2012 16:03:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjCGB-0001Uo-QN;
	Fri, 06 Jan 2012 16:03:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20231.6979.676569.115840@mariner.uk.xensource.com>
Date: Fri, 6 Jan 2012 16:03:15 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4F0703B1.2010207@amd.com>
References: <4F0703B1.2010207@amd.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, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] missing libxl patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("missing libxl patches"):
> any reason to not apply all patches from Roger
> (http://lists.xen.org/archives/html/xen-devel/2011-12/msg01380.html) ?

I think we're still having a conversation about how scripts should be
run, which is tied up with the BSD xenbackendd stuff.

Some of Roger's patches could probably be applied anyway but I haven't
had time yet to decide exactly which.

> libxl fails to build for me because PTHREAD_RECURSIVE_INITIALIZER_NP
> is not available on NetBSD.

Urgh, now you've drawn my attention to this I've just read that patch.
How unpleasant.  I think we should break that into its own function.

Ian.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:03:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:03:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCGJ-0002KH-VE; Fri, 06 Jan 2012 16:03:23 +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 1RjCGJ-0002Jr-Cl
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:03:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1325865796!2548232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7123 invoked from network); 6 Jan 2012 16:03:17 -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;
	6 Jan 2012 16:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,468,1320624000"; 
   d="scan'208";a="9868417"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 16:03:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 16:03:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RjCGB-0001pt-S4; Fri, 06 Jan 2012 16:03:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjCGB-0001Uo-QN;
	Fri, 06 Jan 2012 16:03:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20231.6979.676569.115840@mariner.uk.xensource.com>
Date: Fri, 6 Jan 2012 16:03:15 +0000
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4F0703B1.2010207@amd.com>
References: <4F0703B1.2010207@amd.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, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] missing libxl patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Christoph Egger writes ("missing libxl patches"):
> any reason to not apply all patches from Roger
> (http://lists.xen.org/archives/html/xen-devel/2011-12/msg01380.html) ?

I think we're still having a conversation about how scripts should be
run, which is tied up with the BSD xenbackendd stuff.

Some of Roger's patches could probably be applied anyway but I haven't
had time yet to decide exactly which.

> libxl fails to build for me because PTHREAD_RECURSIVE_INITIALIZER_NP
> is not available on NetBSD.

Urgh, now you've drawn my attention to this I've just read that patch.
How unpleasant.  I think we should break that into its own function.

Ian.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:09:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCLx-0002bG-PH; Fri, 06 Jan 2012 16:09:13 +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 1RjCLw-0002b7-N4
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:09:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325866146!9870498!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 29148 invoked from network); 6 Jan 2012 16:09:06 -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; 6 Jan 2012 16:09:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 16:09:56 +0000
Message-Id: <4F072AE9020000780006AE79@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 16:10:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yongjie Ren" <yongjie.ren@intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@SHSMSX101.ccr.corp.intel.com>
	<1325839550.25206.420.camel@zakaz.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A10012510@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10012510@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 16:28, "Ren, Yongjie" <yongjie.ren@intel.com> wrote:
>>  -----Original Message-----
>> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
>> Sent: Friday, January 06, 2012 4:46 PM
>> To: Ren, Yongjie
>> Cc: xen-devel@lists.xensource.com; Ian Jackson
>> Subject: Re: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
>> 
>> On Fri, 2012-01-06 at 07:44 +0000, Ren, Yongjie wrote:
>> > Hi All,
>> >
>> > The ipxe git commit version changed, but its release version should
>> > still stay at v1.0.0
>> 
>> Doesn't this effectively undo the change in 24455:94180a5a0c7c since the
>> $T rules first tries to wget $(IPXE_TARBALL_URL) before cloning the git
>> tree? Therefore with this change it is going to find and clone v1.0
>> instead of using the git tag.
>> 
> No, I don't want to undo the change in CS #24455.
> I just want to fix an obvious issue. Before my patch, we'll get 
> "IPXE_TARBALL_URL= http://xenbits.xensource.com/xen-extfiles/ipxe-git- 
> 9a93db3f0947484e30e753bbd61a10b17336e20e.tar.gz". So the tarball file in this 
> URL cannot be found. To wget the URL should always fail. I just change it use 
> ipxe-git-v1.0.0.tar.gz which is an available file as before.

But that would get you the unfixed version, and purpose of the
change really was to get a fixed (albeit unreleased) version of ipxe
into Xen.

If anything, a tarball with the new name should be made available
at xenbits.

Jan

> And I know there is still a problem. If using ipxe tarball, we can't add the 
> patches in 'patches/series' successfully after CS #24455 because that change 
> set made these patches dedicated for ipxe.git upstream.
> I'm not familiar with the iPXE, so I have two questions?
> 1. Should we support both tarball and ipxe.git upstream in xen tools? 
> 2. Are patches in 'patches/series' important?
> If we support both and patches are import, we can prepare two kinds of 
> patch-series. One is born for tarball, the other is for ipxe.git upstream.
> If these patches are not important, we can only do patching logic when we 
> using ipxe upstream not tarball.




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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:09:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:09:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCLx-0002bG-PH; Fri, 06 Jan 2012 16:09:13 +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 1RjCLw-0002b7-N4
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:09:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325866146!9870498!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 29148 invoked from network); 6 Jan 2012 16:09:06 -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; 6 Jan 2012 16:09:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 06 Jan 2012 16:09:56 +0000
Message-Id: <4F072AE9020000780006AE79@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 06 Jan 2012 16:10:01 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Yongjie Ren" <yongjie.ren@intel.com>
References: <1B4B44D9196EFF41AE41FDA404FC0A1001197C@SHSMSX101.ccr.corp.intel.com>
	<1325839550.25206.420.camel@zakaz.uk.xensource.com>
	<1B4B44D9196EFF41AE41FDA404FC0A10012510@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A10012510@SHSMSX101.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 16:28, "Ren, Yongjie" <yongjie.ren@intel.com> wrote:
>>  -----Original Message-----
>> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
>> Sent: Friday, January 06, 2012 4:46 PM
>> To: Ren, Yongjie
>> Cc: xen-devel@lists.xensource.com; Ian Jackson
>> Subject: Re: [Xen-devel] [PATCH] tools: fix ipxe version issue in Makefile
>> 
>> On Fri, 2012-01-06 at 07:44 +0000, Ren, Yongjie wrote:
>> > Hi All,
>> >
>> > The ipxe git commit version changed, but its release version should
>> > still stay at v1.0.0
>> 
>> Doesn't this effectively undo the change in 24455:94180a5a0c7c since the
>> $T rules first tries to wget $(IPXE_TARBALL_URL) before cloning the git
>> tree? Therefore with this change it is going to find and clone v1.0
>> instead of using the git tag.
>> 
> No, I don't want to undo the change in CS #24455.
> I just want to fix an obvious issue. Before my patch, we'll get 
> "IPXE_TARBALL_URL= http://xenbits.xensource.com/xen-extfiles/ipxe-git- 
> 9a93db3f0947484e30e753bbd61a10b17336e20e.tar.gz". So the tarball file in this 
> URL cannot be found. To wget the URL should always fail. I just change it use 
> ipxe-git-v1.0.0.tar.gz which is an available file as before.

But that would get you the unfixed version, and purpose of the
change really was to get a fixed (albeit unreleased) version of ipxe
into Xen.

If anything, a tarball with the new name should be made available
at xenbits.

Jan

> And I know there is still a problem. If using ipxe tarball, we can't add the 
> patches in 'patches/series' successfully after CS #24455 because that change 
> set made these patches dedicated for ipxe.git upstream.
> I'm not familiar with the iPXE, so I have two questions?
> 1. Should we support both tarball and ipxe.git upstream in xen tools? 
> 2. Are patches in 'patches/series' important?
> If we support both and patches are import, we can prepare two kinds of 
> patch-series. One is born for tarball, the other is for ipxe.git upstream.
> If these patches are not important, we can only do patching logic when we 
> using ipxe upstream not tarball.




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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:19:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCVh-0002lq-U6; Fri, 06 Jan 2012 16:19:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RjCVg-0002li-FC
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:19:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325866709!59196429!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NzgzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8512 invoked from network); 6 Jan 2012 16:18:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 16:18: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
	q06GJ6nk014189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 16:19:07 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
	q06GJ5dH029349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 16:19:05 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
	q06GJ4hg006397; Fri, 6 Jan 2012 10:19:04 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 08:19:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4D3AC40930; Fri,  6 Jan 2012 11:17:26 -0500 (EST)
Date: Fri, 6 Jan 2012 11:17:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120106161726.GA8657@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
	<1325759051.25206.361.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325759051.25206.361.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F071EFC.000F,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, 2012 at 10:24:11AM +0000, Ian Campbell wrote:
> On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
> > We use the __pci_reset_function_locked to perform the action.
> > Also on attaching ("bind") and detaching ("unbind") we save and
> > restore the configuration states. When the device is disconnected
> > from a guest we use the "pci_reset_function" to also reset the
> > device before being passed to another guest.
> 
> Currently I thought the toolstack was supposed to do the reset (by
> writing to the reset node in sysfs) as it was (de)assigning devices
> to/from guests. That's not to say that there isn't an argument for
> preferring to do it kernels side but it would be interesting to make
> that argument explicitly.

I am kind of on the fence on this one. The one issue I found with
the toolstack is that it sometimes is run too late (now mind you -
I haven't actually found any bugs, so this might be all ballloony).

The xen-pciback can be used to inhibit drivers from grabbing the devices
during bootup. This can be done by 'xen-pciback.hide=(02:00.0)(02:00.1)(..)'

Pretty handy as you don't have to deal with:
 echo "0000:02:00.1" > /sys/bus/pci/devices/0000:02:00.1/drivers/unbind

and then later 'rmmod e1000e' to save some memory space.

The unfortunate side effect is that xen-pciback does this:

 pci_enable_device()
 pci_disable_device(dev)
 pci_write_config_word(dev, PCI_COMMAND, 0)

... and then when the guest finally uses the device it would (this is what
the toolstack does - I think?):

 echo "1" > /sys/bus/pci/devices/0000:02:00.1/reset

which calls
 pci_dev_reset() - do FLR or D3, or whatnot
 pci_save_state()

 pci_write_config_word(dev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);

 pci_dev_reset(dev) [with a lock held so that "reset" on SysFS cannot be done]
 pci_restore_state()

which means that the PCI configuration state before the "pci_save_state"
is already influenced by what the xen-pciback had done during startup:
the pci_enable/pci_disable/pci_write_config_work(dev, PCI_COMMAND, 0).

When the 'pci_restore_state()' is called it would restore it to
what xen-pciback.hide=(xx) did. Not what the device state is before xen-pciback
gets its hand on it.

This is part of this patchset - were we make sure to save it before we do our deed.
(with those pci_save_config/pci_restore_config). 
And to be fair - I hadn't seen any issues with this, so it might not be
neccessary.

The other way of making this work is to remove the 
pci_write_config_work(dev, PCI_COMMAND, 0) but I hadn't seen any bugs with
that ..

> 
> I guess the toolstack doesn't currently save/restore the configuration
> state, could it though? I guess the state is all available in sysfs. On
> the other hand the kernel provides us with a very handy function which
> Just Does It...

Yeah, there is one more use case - 'xm'. The 'xm' does not do 'reset' on the 
SysFS so having it done in the kernel is kind of nice. But then 'xm' is on the
deprecated list so xen-unstable does not care about it. But I do since
Fedora Core 16 is using it ..


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:19:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCVh-0002lq-U6; Fri, 06 Jan 2012 16:19:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RjCVg-0002li-FC
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:19:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325866709!59196429!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3NzgzNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8512 invoked from network); 6 Jan 2012 16:18:31 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 16:18: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
	q06GJ6nk014189
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 16:19:07 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
	q06GJ5dH029349
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 16:19:05 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
	q06GJ4hg006397; Fri, 6 Jan 2012 10:19:04 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 08:19:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4D3AC40930; Fri,  6 Jan 2012 11:17:26 -0500 (EST)
Date: Fri, 6 Jan 2012 11:17:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120106161726.GA8657@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
	<1325759051.25206.361.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325759051.25206.361.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F071EFC.000F,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, 2012 at 10:24:11AM +0000, Ian Campbell wrote:
> On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
> > We use the __pci_reset_function_locked to perform the action.
> > Also on attaching ("bind") and detaching ("unbind") we save and
> > restore the configuration states. When the device is disconnected
> > from a guest we use the "pci_reset_function" to also reset the
> > device before being passed to another guest.
> 
> Currently I thought the toolstack was supposed to do the reset (by
> writing to the reset node in sysfs) as it was (de)assigning devices
> to/from guests. That's not to say that there isn't an argument for
> preferring to do it kernels side but it would be interesting to make
> that argument explicitly.

I am kind of on the fence on this one. The one issue I found with
the toolstack is that it sometimes is run too late (now mind you -
I haven't actually found any bugs, so this might be all ballloony).

The xen-pciback can be used to inhibit drivers from grabbing the devices
during bootup. This can be done by 'xen-pciback.hide=(02:00.0)(02:00.1)(..)'

Pretty handy as you don't have to deal with:
 echo "0000:02:00.1" > /sys/bus/pci/devices/0000:02:00.1/drivers/unbind

and then later 'rmmod e1000e' to save some memory space.

The unfortunate side effect is that xen-pciback does this:

 pci_enable_device()
 pci_disable_device(dev)
 pci_write_config_word(dev, PCI_COMMAND, 0)

... and then when the guest finally uses the device it would (this is what
the toolstack does - I think?):

 echo "1" > /sys/bus/pci/devices/0000:02:00.1/reset

which calls
 pci_dev_reset() - do FLR or D3, or whatnot
 pci_save_state()

 pci_write_config_word(dev, PCI_COMMAND, PCI_COMMAND_INTX_DISABLE);

 pci_dev_reset(dev) [with a lock held so that "reset" on SysFS cannot be done]
 pci_restore_state()

which means that the PCI configuration state before the "pci_save_state"
is already influenced by what the xen-pciback had done during startup:
the pci_enable/pci_disable/pci_write_config_work(dev, PCI_COMMAND, 0).

When the 'pci_restore_state()' is called it would restore it to
what xen-pciback.hide=(xx) did. Not what the device state is before xen-pciback
gets its hand on it.

This is part of this patchset - were we make sure to save it before we do our deed.
(with those pci_save_config/pci_restore_config). 
And to be fair - I hadn't seen any issues with this, so it might not be
neccessary.

The other way of making this work is to remove the 
pci_write_config_work(dev, PCI_COMMAND, 0) but I hadn't seen any bugs with
that ..

> 
> I guess the toolstack doesn't currently save/restore the configuration
> state, could it though? I guess the state is all available in sysfs. On
> the other hand the kernel provides us with a very handy function which
> Just Does It...

Yeah, there is one more use case - 'xm'. The 'xm' does not do 'reset' on the 
SysFS so having it done in the kernel is kind of nice. But then 'xm' is on the
deprecated list so xen-unstable does not care about it. But I do since
Fedora Core 16 is using it ..


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:22:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCYe-0002sC-HR; Fri, 06 Jan 2012 16:22:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elthariel@gmail.com>) id 1RjCYc-0002s3-5u
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:22:18 +0000
X-Env-Sender: elthariel@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325866931!8112545!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32657 invoked from network); 6 Jan 2012 16:22:11 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 16:22:11 -0000
Received: by werg1 with SMTP id g1so3619966wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 08:22:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=Ol60jNKXl2DHwHffE+uTcNzyBf3ygiBawW+gs8wVENo=;
	b=h2TeISaw+snRBzakDVUjcg93+Hu9aS+HEH9G3+q/3iFJFcfJ82tNXyVN1ir2lREMfq
	LuLSXeD7IMUd2YDDNH2XyK7OdWp0v4pqnESQfnS0q5/sC/AB/WoVRF75XBA7S+pbds9N
	V8wcnv6KDpFuEDV6tnpIt7p1OM5AnzKU2BqQE=
MIME-Version: 1.0
Received: by 10.216.133.104 with SMTP id p82mr3235923wei.6.1325866931140; Fri,
	06 Jan 2012 08:22:11 -0800 (PST)
Received: by 10.216.181.202 with HTTP; Fri, 6 Jan 2012 08:22:11 -0800 (PST)
In-Reply-To: <1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 17:22:11 +0100
X-Google-Sender-Auth: DHUbw8f0pbga8IVd-kSrzDcwuks
Message-ID: <CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
From: "-+= Lta =+-" <lta@akr.fm>
To: David TECHER <davidtecher@yahoo.fr>
Cc: n4rC0t1C <shandivo@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 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="===============2782446436081480963=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2782446436081480963==
Content-Type: multipart/alternative; boundary=0016e6de1767733a5a04b5de7368

--0016e6de1767733a5a04b5de7368
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

I've just posted on the list my setup of a working win7 domu with an nvidia
card. You might wanna have a look.

--
Lta

On Fri, Jan 6, 2012 at 3:23 PM, David TECHER <davidtecher@yahoo.fr> wrote:

> All informations given - by n4rc0tic - are right.
>
> For XP: nvidia should work
>
> For win7, you should be well-advised to use a ATI card.
>
> David.
>
>   ------------------------------
> *De :* n4rC0t1C <shandivo@gmail.com>
> *=C0 :* xen-devel@lists.xensource.com
> *Envoy=E9 le :* Vendredi 6 Janvier 2012 2h13
> *Objet :* Re: [Xen-devel] Patches for VGA-Passthrough XEN 4.2 unstable
>
> Forget about Windows 7. I didn't see a single working solution to
> passthrough
> an nVidia card (at least not Quadro) to a win7 domu.
>
> However WindowsXP works almost painless. Just follow instructions and app=
ly
> patches from D. Teacher on his website and everything should work just
> fine.
>
> http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patch=
es-for-vga-pass-through
>
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unst=
able-tp4406265p5124377.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
>
>

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

Hello,<div><br></div><div>I&#39;ve just posted on the list my setup of a wo=
rking win7 domu with an nvidia card. You might wanna have a look.</div><div=
><br></div><div>--</div><div>Lta<br><br><div class=3D"gmail_quote">On Fri, =
Jan 6, 2012 at 3:23 PM, David TECHER <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div style=3D"color:#000;background-col=
or:#fff;font-family:times new roman,new york,times,serif;font-size:12pt"><d=
iv>
<span>All informations given - by n4rc0tic - are right.</span></div><div><b=
r></div><div>For XP: nvidia should work<br></div><div><br><span></span></di=
v><div><span>For win7, you should be well-advised to use a ATI card.</span>=
</div>
<div><br><span></span></div><div><span>David.<br></span></div><div><br></di=
v>  <div style=3D"font-family:times new roman,new york,times,serif;font-siz=
e:12pt"> <div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">
 <font face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-weight:bold"=
>De=A0:</span></b> n4rC0t1C &lt;<a href=3D"mailto:shandivo@gmail.com" targe=
t=3D"_blank">shandivo@gmail.com</a>&gt;<br> <b><span style=3D"font-weight:b=
old">=C0=A0:</span></b> <a href=3D"mailto:xen-devel@lists.xensource.com" ta=
rget=3D"_blank">xen-devel@lists.xensource.com</a> <br>
 <b><span style=3D"font-weight:bold">Envoy=E9 le :</span></b> Vendredi 6 Ja=
nvier 2012 2h13<br> <b><span style=3D"font-weight:bold">Objet=A0:</span></b=
> Re: [Xen-devel] Patches for VGA-Passthrough XEN 4.2 unstable<br> </font> =
<br>
Forget about Windows 7. I didn&#39;t see a single working solution to passt=
hrough<br>an nVidia card (at least not Quadro) to a win7 domu. <br><br>Howe=
ver WindowsXP works almost painless. Just follow instructions and apply<br>
patches from D. Teacher on his website and everything should work just fine=
. <br><a href=3D"http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-4=
2unstable-patches-for-vga-pass-through" target=3D"_blank">http://www.davidg=
is.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-thr=
ough</a><span class=3D"HOEnZb"><font color=3D"#888888"><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-tp4406265p5124377.htm=
l" target=3D"_blank">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passt=
hrough-XEN-4-2-unstable-tp4406265p5124377.html</a><br>
Sent from the Xen - Dev mailing list archive at
 Nabble.com.<br><br>_______________________________________________<br>Xen-=
devel mailing list<br><a href=3D"mailto:Xen-devel@lists.xensource.com" targ=
et=3D"_blank">Xen-devel@lists.xensource.com</a><br><a href=3D"http://lists.=
xensource.com/xen-devel" target=3D"_blank">http://lists.xensource.com/xen-d=
evel</a><br>
<br><br> </font></span></div> </div>  </div></div><br>_____________________=
__________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br></div>

--0016e6de1767733a5a04b5de7368--


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

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

--===============2782446436081480963==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:22:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:22:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCYe-0002sC-HR; Fri, 06 Jan 2012 16:22:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elthariel@gmail.com>) id 1RjCYc-0002s3-5u
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:22:18 +0000
X-Env-Sender: elthariel@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1325866931!8112545!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32657 invoked from network); 6 Jan 2012 16:22:11 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 16:22:11 -0000
Received: by werg1 with SMTP id g1so3619966wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 08:22:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=Ol60jNKXl2DHwHffE+uTcNzyBf3ygiBawW+gs8wVENo=;
	b=h2TeISaw+snRBzakDVUjcg93+Hu9aS+HEH9G3+q/3iFJFcfJ82tNXyVN1ir2lREMfq
	LuLSXeD7IMUd2YDDNH2XyK7OdWp0v4pqnESQfnS0q5/sC/AB/WoVRF75XBA7S+pbds9N
	V8wcnv6KDpFuEDV6tnpIt7p1OM5AnzKU2BqQE=
MIME-Version: 1.0
Received: by 10.216.133.104 with SMTP id p82mr3235923wei.6.1325866931140; Fri,
	06 Jan 2012 08:22:11 -0800 (PST)
Received: by 10.216.181.202 with HTTP; Fri, 6 Jan 2012 08:22:11 -0800 (PST)
In-Reply-To: <1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 17:22:11 +0100
X-Google-Sender-Auth: DHUbw8f0pbga8IVd-kSrzDcwuks
Message-ID: <CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
From: "-+= Lta =+-" <lta@akr.fm>
To: David TECHER <davidtecher@yahoo.fr>
Cc: n4rC0t1C <shandivo@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] 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="===============2782446436081480963=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2782446436081480963==
Content-Type: multipart/alternative; boundary=0016e6de1767733a5a04b5de7368

--0016e6de1767733a5a04b5de7368
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,

I've just posted on the list my setup of a working win7 domu with an nvidia
card. You might wanna have a look.

--
Lta

On Fri, Jan 6, 2012 at 3:23 PM, David TECHER <davidtecher@yahoo.fr> wrote:

> All informations given - by n4rc0tic - are right.
>
> For XP: nvidia should work
>
> For win7, you should be well-advised to use a ATI card.
>
> David.
>
>   ------------------------------
> *De :* n4rC0t1C <shandivo@gmail.com>
> *=C0 :* xen-devel@lists.xensource.com
> *Envoy=E9 le :* Vendredi 6 Janvier 2012 2h13
> *Objet :* Re: [Xen-devel] Patches for VGA-Passthrough XEN 4.2 unstable
>
> Forget about Windows 7. I didn't see a single working solution to
> passthrough
> an nVidia card (at least not Quadro) to a win7 domu.
>
> However WindowsXP works almost painless. Just follow instructions and app=
ly
> patches from D. Teacher on his website and everything should work just
> fine.
>
> http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patch=
es-for-vga-pass-through
>
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unst=
able-tp4406265p5124377.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
>
>

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

Hello,<div><br></div><div>I&#39;ve just posted on the list my setup of a wo=
rking win7 domu with an nvidia card. You might wanna have a look.</div><div=
><br></div><div>--</div><div>Lta<br><br><div class=3D"gmail_quote">On Fri, =
Jan 6, 2012 at 3:23 PM, David TECHER <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div style=3D"color:#000;background-col=
or:#fff;font-family:times new roman,new york,times,serif;font-size:12pt"><d=
iv>
<span>All informations given - by n4rc0tic - are right.</span></div><div><b=
r></div><div>For XP: nvidia should work<br></div><div><br><span></span></di=
v><div><span>For win7, you should be well-advised to use a ATI card.</span>=
</div>
<div><br><span></span></div><div><span>David.<br></span></div><div><br></di=
v>  <div style=3D"font-family:times new roman,new york,times,serif;font-siz=
e:12pt"> <div style=3D"font-family:times new roman,new york,times,serif;fon=
t-size:12pt">
 <font face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-weight:bold"=
>De=A0:</span></b> n4rC0t1C &lt;<a href=3D"mailto:shandivo@gmail.com" targe=
t=3D"_blank">shandivo@gmail.com</a>&gt;<br> <b><span style=3D"font-weight:b=
old">=C0=A0:</span></b> <a href=3D"mailto:xen-devel@lists.xensource.com" ta=
rget=3D"_blank">xen-devel@lists.xensource.com</a> <br>
 <b><span style=3D"font-weight:bold">Envoy=E9 le :</span></b> Vendredi 6 Ja=
nvier 2012 2h13<br> <b><span style=3D"font-weight:bold">Objet=A0:</span></b=
> Re: [Xen-devel] Patches for VGA-Passthrough XEN 4.2 unstable<br> </font> =
<br>
Forget about Windows 7. I didn&#39;t see a single working solution to passt=
hrough<br>an nVidia card (at least not Quadro) to a win7 domu. <br><br>Howe=
ver WindowsXP works almost painless. Just follow instructions and apply<br>
patches from D. Teacher on his website and everything should work just fine=
. <br><a href=3D"http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-4=
2unstable-patches-for-vga-pass-through" target=3D"_blank">http://www.davidg=
is.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-thr=
ough</a><span class=3D"HOEnZb"><font color=3D"#888888"><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-tp4406265p5124377.htm=
l" target=3D"_blank">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passt=
hrough-XEN-4-2-unstable-tp4406265p5124377.html</a><br>
Sent from the Xen - Dev mailing list archive at
 Nabble.com.<br><br>_______________________________________________<br>Xen-=
devel mailing list<br><a href=3D"mailto:Xen-devel@lists.xensource.com" targ=
et=3D"_blank">Xen-devel@lists.xensource.com</a><br><a href=3D"http://lists.=
xensource.com/xen-devel" target=3D"_blank">http://lists.xensource.com/xen-d=
evel</a><br>
<br><br> </font></span></div> </div>  </div></div><br>_____________________=
__________________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.=
com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/xen-devel</a><br>
<br></blockquote></div><br></div>

--0016e6de1767733a5a04b5de7368--


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

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

--===============2782446436081480963==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:35:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 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 1RjCkp-0003Be-1I; Fri, 06 Jan 2012 16:34:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RjCkn-0003BZ-St
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:34:54 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325867655!47370592!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 31576 invoked from network); 6 Jan 2012 16:34:16 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Jan 2012 16:34:16 -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 1RjCki-0003UP-AS
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:34:48 -0800
Date: Fri, 6 Jan 2012 08:34:48 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325867688317-5126020.post@n5.nabble.com>
In-Reply-To: <CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 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


-+= Lta =+- wrote
> 
> Hello,
> 
> I've just posted on the list my setup of a working win7 domu with an
> nvidia
> card. You might wanna have a look.
> 
> --
> Lta
> 
> On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &lt;davidtecher@&gt; wrote:
> 
> 

Sorry, where? Dind't find the post. REALLY interested.

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.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 Jan 06 16:35:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 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 1RjCkp-0003Be-1I; Fri, 06 Jan 2012 16:34:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <shandivo@gmail.com>) id 1RjCkn-0003BZ-St
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:34:54 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1325867655!47370592!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 31576 invoked from network); 6 Jan 2012 16:34:16 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Jan 2012 16:34:16 -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 1RjCki-0003UP-AS
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:34:48 -0800
Date: Fri, 6 Jan 2012 08:34:48 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325867688317-5126020.post@n5.nabble.com>
In-Reply-To: <CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] 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


-+= Lta =+- wrote
> 
> Hello,
> 
> I've just posted on the list my setup of a working win7 domu with an
> nvidia
> card. You might wanna have a look.
> 
> --
> Lta
> 
> On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &lt;davidtecher@&gt; wrote:
> 
> 

Sorry, where? Dind't find the post. REALLY interested.

--
View this message in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.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 Jan 06 16:40:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16: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 1RjCpw-0003Mx-OF; Fri, 06 Jan 2012 16:40:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RjCpv-0003Mm-Dn
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:40:11 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325868002!10654042!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6226 invoked from network); 6 Jan 2012 16:40:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 16:40:03 -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 q06GdsVE020355
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 11:39:54 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q06Gdpcc030410; Fri, 6 Jan 2012 11:39:52 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 17:39:50 +0100
Message-Id: <1325867990-15018-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOM0 is a silent option that has been automatically selected when
CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed
to a menu configurable option then it would only give users the ability
to compile out about 100 kbytes of code. As that option makes little
sense to choose, and the option isn't menu selectable anyway, then we
can clean up some code by simply removing it. Also remove
XEN_PRIVILEGED_GUEST as it's just an alias for XEN_DOM0.

I compile tested this on a latest pull using an F16 config. The compile
succeeded and 'make oldconfig' only removed these two options as
expected.

CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/include/asm/xen/pci.h |   21 +--------------------
 arch/x86/pci/xen.c             |    6 ------
 arch/x86/xen/Kconfig           |   10 ----------
 arch/x86/xen/Makefile          |    3 +--
 arch/x86/xen/xen-ops.h         |    7 -------
 drivers/xen/Kconfig            |    3 ++-
 drivers/xen/Makefile           |    3 +--
 drivers/xen/xenfs/Makefile     |    3 +--
 include/xen/xen.h              |   11 +++--------
 9 files changed, 9 insertions(+), 58 deletions(-)

diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
index 968d57d..b423889 100644
--- a/arch/x86/include/asm/xen/pci.h
+++ b/arch/x86/include/asm/xen/pci.h
@@ -13,30 +13,11 @@ static inline int pci_xen_hvm_init(void)
 	return -1;
 }
 #endif
-#if defined(CONFIG_XEN_DOM0)
+
 int __init pci_xen_initial_domain(void);
 int xen_find_device_domain_owner(struct pci_dev *dev);
 int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
 int xen_unregister_device_domain_owner(struct pci_dev *dev);
-#else
-static inline int __init pci_xen_initial_domain(void)
-{
-	return -1;
-}
-static inline int xen_find_device_domain_owner(struct pci_dev *dev)
-{
-	return -1;
-}
-static inline int xen_register_device_domain_owner(struct pci_dev *dev,
-						   uint16_t domain)
-{
-	return -1;
-}
-static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
-{
-	return -1;
-}
-#endif
 
 #if defined(CONFIG_PCI_MSI)
 #if defined(CONFIG_PCI_XEN)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 492ade8..e298726 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -108,7 +108,6 @@ static int acpi_register_gsi_xen_hvm(struct device *dev, u32 gsi,
 				 false /* no mapping of GSI to PIRQ */);
 }
 
-#ifdef CONFIG_XEN_DOM0
 static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polarity)
 {
 	int rc, irq;
@@ -143,7 +142,6 @@ static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
 	return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, polarity);
 }
 #endif
-#endif
 
 #if defined(CONFIG_PCI_MSI)
 #include <linux/msi.h>
@@ -251,7 +249,6 @@ error:
 	return irq;
 }
 
-#ifdef CONFIG_XEN_DOM0
 static bool __read_mostly pci_seg_supported = true;
 
 static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
@@ -324,7 +321,6 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 out:
 	return ret;
 }
-#endif
 
 static void xen_teardown_msi_irqs(struct pci_dev *dev)
 {
@@ -392,7 +388,6 @@ int __init pci_xen_hvm_init(void)
 	return 0;
 }
 
-#ifdef CONFIG_XEN_DOM0
 static __init void xen_setup_acpi_sci(void)
 {
 	int rc;
@@ -539,4 +534,3 @@ int xen_unregister_device_domain_owner(struct pci_dev *dev)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_unregister_device_domain_owner);
-#endif
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..3c7e89a 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -13,16 +13,6 @@ config XEN
 	  kernel to boot in a paravirtualized environment under the
 	  Xen hypervisor.
 
-config XEN_DOM0
-	def_bool y
-	depends on XEN && PCI_XEN && SWIOTLB_XEN
-	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
-
-# Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
-# name in tools.
-config XEN_PRIVILEGED_GUEST
-	def_bool XEN_DOM0
-
 config XEN_PVHVM
 	def_bool y
 	depends on XEN && PCI && X86_LOCAL_APIC
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index add2c2d..b2d4c4b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -13,12 +13,11 @@ CFLAGS_mmu.o			:= $(nostackp)
 obj-y		:= enlighten.o setup.o multicalls.o mmu.o irq.o \
 			time.o xen-asm.o xen-asm_$(BITS).o \
 			grant-table.o suspend.o platform-pci-unplug.o \
-			p2m.o
+			p2m.o vga.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
 obj-$(CONFIG_SMP)		+= smp.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
-obj-$(CONFIG_XEN_DOM0)		+= vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index b095739..d9dbbca 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -90,14 +90,7 @@ static inline void xen_uninit_lock_cpu(int cpu)
 
 struct dom0_vga_console_info;
 
-#ifdef CONFIG_XEN_DOM0
 void __init xen_init_vga(const struct dom0_vga_console_info *, size_t size);
-#else
-static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
-				       size_t size)
-{
-}
-#endif
 
 /* Declare an asm function, along with symbols needed to make it
    inlineable */
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..0725228 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
 
 config XEN_BACKEND
 	bool "Backend driver support"
-	depends on XEN_DOM0
 	default y
+	depends on XEN && PCI_XEN && SWIOTLB_XEN
+	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
 	help
 	  Support for backend device drivers that provide I/O services
 	  to other virtual machines.
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 974fffd..7e61662 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 pci.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
@@ -17,7 +17,6 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
 obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
-obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 
 xen-evtchn-y				:= evtchn.o
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 4fde944..d20c060 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,3 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o privcmd.o
-xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
+xenfs-y			  = super.o xenbus.o privcmd.o xenstored.o
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a164024..d814ef7 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -1,6 +1,9 @@
 #ifndef _XEN_XEN_H
 #define _XEN_XEN_H
 
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+
 enum xen_domain_type {
 	XEN_NATIVE,		/* running on bare hardware    */
 	XEN_PV_DOMAIN,		/* running in a PV domain      */
@@ -18,15 +21,7 @@ extern enum xen_domain_type xen_domain_type;
 				 xen_domain_type == XEN_PV_DOMAIN)
 #define xen_hvm_domain()	(xen_domain() &&			\
 				 xen_domain_type == XEN_HVM_DOMAIN)
-
-#ifdef CONFIG_XEN_DOM0
-#include <xen/interface/xen.h>
-#include <asm/xen/hypervisor.h>
-
 #define xen_initial_domain()	(xen_pv_domain() && \
 				 xen_start_info->flags & SIF_INITDOMAIN)
-#else  /* !CONFIG_XEN_DOM0 */
-#define xen_initial_domain()	(0)
-#endif	/* CONFIG_XEN_DOM0 */
 
 #endif	/* _XEN_XEN_H */
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:40:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16: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 1RjCpw-0003Mx-OF; Fri, 06 Jan 2012 16:40:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RjCpv-0003Mm-Dn
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:40:11 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325868002!10654042!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6226 invoked from network); 6 Jan 2012 16:40:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 16:40:03 -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 q06GdsVE020355
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 11:39:54 -0500
Received: from turtle.usersys.redhat.com (vpn1-4-188.ams2.redhat.com
	[10.36.4.188])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q06Gdpcc030410; Fri, 6 Jan 2012 11:39:52 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Fri,  6 Jan 2012 17:39:50 +0100
Message-Id: <1325867990-15018-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	stefano.stabellini@eu.citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOM0 is a silent option that has been automatically selected when
CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed
to a menu configurable option then it would only give users the ability
to compile out about 100 kbytes of code. As that option makes little
sense to choose, and the option isn't menu selectable anyway, then we
can clean up some code by simply removing it. Also remove
XEN_PRIVILEGED_GUEST as it's just an alias for XEN_DOM0.

I compile tested this on a latest pull using an F16 config. The compile
succeeded and 'make oldconfig' only removed these two options as
expected.

CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/include/asm/xen/pci.h |   21 +--------------------
 arch/x86/pci/xen.c             |    6 ------
 arch/x86/xen/Kconfig           |   10 ----------
 arch/x86/xen/Makefile          |    3 +--
 arch/x86/xen/xen-ops.h         |    7 -------
 drivers/xen/Kconfig            |    3 ++-
 drivers/xen/Makefile           |    3 +--
 drivers/xen/xenfs/Makefile     |    3 +--
 include/xen/xen.h              |   11 +++--------
 9 files changed, 9 insertions(+), 58 deletions(-)

diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
index 968d57d..b423889 100644
--- a/arch/x86/include/asm/xen/pci.h
+++ b/arch/x86/include/asm/xen/pci.h
@@ -13,30 +13,11 @@ static inline int pci_xen_hvm_init(void)
 	return -1;
 }
 #endif
-#if defined(CONFIG_XEN_DOM0)
+
 int __init pci_xen_initial_domain(void);
 int xen_find_device_domain_owner(struct pci_dev *dev);
 int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
 int xen_unregister_device_domain_owner(struct pci_dev *dev);
-#else
-static inline int __init pci_xen_initial_domain(void)
-{
-	return -1;
-}
-static inline int xen_find_device_domain_owner(struct pci_dev *dev)
-{
-	return -1;
-}
-static inline int xen_register_device_domain_owner(struct pci_dev *dev,
-						   uint16_t domain)
-{
-	return -1;
-}
-static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
-{
-	return -1;
-}
-#endif
 
 #if defined(CONFIG_PCI_MSI)
 #if defined(CONFIG_PCI_XEN)
diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 492ade8..e298726 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -108,7 +108,6 @@ static int acpi_register_gsi_xen_hvm(struct device *dev, u32 gsi,
 				 false /* no mapping of GSI to PIRQ */);
 }
 
-#ifdef CONFIG_XEN_DOM0
 static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polarity)
 {
 	int rc, irq;
@@ -143,7 +142,6 @@ static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
 	return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, polarity);
 }
 #endif
-#endif
 
 #if defined(CONFIG_PCI_MSI)
 #include <linux/msi.h>
@@ -251,7 +249,6 @@ error:
 	return irq;
 }
 
-#ifdef CONFIG_XEN_DOM0
 static bool __read_mostly pci_seg_supported = true;
 
 static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
@@ -324,7 +321,6 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
 out:
 	return ret;
 }
-#endif
 
 static void xen_teardown_msi_irqs(struct pci_dev *dev)
 {
@@ -392,7 +388,6 @@ int __init pci_xen_hvm_init(void)
 	return 0;
 }
 
-#ifdef CONFIG_XEN_DOM0
 static __init void xen_setup_acpi_sci(void)
 {
 	int rc;
@@ -539,4 +534,3 @@ int xen_unregister_device_domain_owner(struct pci_dev *dev)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(xen_unregister_device_domain_owner);
-#endif
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..3c7e89a 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -13,16 +13,6 @@ config XEN
 	  kernel to boot in a paravirtualized environment under the
 	  Xen hypervisor.
 
-config XEN_DOM0
-	def_bool y
-	depends on XEN && PCI_XEN && SWIOTLB_XEN
-	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
-
-# Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
-# name in tools.
-config XEN_PRIVILEGED_GUEST
-	def_bool XEN_DOM0
-
 config XEN_PVHVM
 	def_bool y
 	depends on XEN && PCI && X86_LOCAL_APIC
diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index add2c2d..b2d4c4b 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -13,12 +13,11 @@ CFLAGS_mmu.o			:= $(nostackp)
 obj-y		:= enlighten.o setup.o multicalls.o mmu.o irq.o \
 			time.o xen-asm.o xen-asm_$(BITS).o \
 			grant-table.o suspend.o platform-pci-unplug.o \
-			p2m.o
+			p2m.o vga.o
 
 obj-$(CONFIG_EVENT_TRACING) += trace.o
 
 obj-$(CONFIG_SMP)		+= smp.o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
-obj-$(CONFIG_XEN_DOM0)		+= vga.o
 obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index b095739..d9dbbca 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -90,14 +90,7 @@ static inline void xen_uninit_lock_cpu(int cpu)
 
 struct dom0_vga_console_info;
 
-#ifdef CONFIG_XEN_DOM0
 void __init xen_init_vga(const struct dom0_vga_console_info *, size_t size);
-#else
-static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
-				       size_t size)
-{
-}
-#endif
 
 /* Declare an asm function, along with symbols needed to make it
    inlineable */
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..0725228 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
 
 config XEN_BACKEND
 	bool "Backend driver support"
-	depends on XEN_DOM0
 	default y
+	depends on XEN && PCI_XEN && SWIOTLB_XEN
+	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
 	help
 	  Support for backend device drivers that provide I/O services
 	  to other virtual machines.
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 974fffd..7e61662 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 pci.o
 obj-y	+= xenbus/
 
 nostackp := $(call cc-option, -fno-stack-protector)
@@ -17,7 +17,6 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
 obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
 obj-$(CONFIG_XEN_TMEM)			+= tmem.o
 obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
-obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 
 xen-evtchn-y				:= evtchn.o
diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
index 4fde944..d20c060 100644
--- a/drivers/xen/xenfs/Makefile
+++ b/drivers/xen/xenfs/Makefile
@@ -1,4 +1,3 @@
 obj-$(CONFIG_XENFS) += xenfs.o
 
-xenfs-y			  = super.o xenbus.o privcmd.o
-xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
+xenfs-y			  = super.o xenbus.o privcmd.o xenstored.o
diff --git a/include/xen/xen.h b/include/xen/xen.h
index a164024..d814ef7 100644
--- a/include/xen/xen.h
+++ b/include/xen/xen.h
@@ -1,6 +1,9 @@
 #ifndef _XEN_XEN_H
 #define _XEN_XEN_H
 
+#include <xen/interface/xen.h>
+#include <asm/xen/hypervisor.h>
+
 enum xen_domain_type {
 	XEN_NATIVE,		/* running on bare hardware    */
 	XEN_PV_DOMAIN,		/* running in a PV domain      */
@@ -18,15 +21,7 @@ extern enum xen_domain_type xen_domain_type;
 				 xen_domain_type == XEN_PV_DOMAIN)
 #define xen_hvm_domain()	(xen_domain() &&			\
 				 xen_domain_type == XEN_HVM_DOMAIN)
-
-#ifdef CONFIG_XEN_DOM0
-#include <xen/interface/xen.h>
-#include <asm/xen/hypervisor.h>
-
 #define xen_initial_domain()	(xen_pv_domain() && \
 				 xen_start_info->flags & SIF_INITDOMAIN)
-#else  /* !CONFIG_XEN_DOM0 */
-#define xen_initial_domain()	(0)
-#endif	/* CONFIG_XEN_DOM0 */
 
 #endif	/* _XEN_XEN_H */
-- 
1.7.7.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:42:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCrl-0003af-96; Fri, 06 Jan 2012 16:42:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ming.Aaron.Liu@gmail.com>) id 1RjCrj-0003Zq-My
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:42:03 +0000
X-Env-Sender: Ming.Aaron.Liu@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325868115!9874605!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 20716 invoked from network); 6 Jan 2012 16:41:57 -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;
	6 Jan 2012 16:41:57 -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 1RjCrb-0004Hm-2m
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:41:55 -0800
Date: Fri, 6 Jan 2012 08:41:55 -0800 (PST)
From: lmingcsce <Ming.Aaron.Liu@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325868115079-5126037.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] DomU memory update procedures ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, I have a question about memory update of DomU. 
When DomU writes a new value to a memory address, how does hypervisor change
the value in the particular address and change the dirty page bit? 
In my current understanding, I find that there is a hypercal do_mmu_update
in the hypervisor changing the content in the memory. However, I want to
know the details about the memory update procedures. Or you can simply tell
me how can I find this procedures.
Thanks for your help. 

--
View this message in context: http://xen.1045712.n5.nabble.com/DomU-memory-update-procedures-tp5126037p5126037.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 Jan 06 16:42:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:42:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCrl-0003af-96; Fri, 06 Jan 2012 16:42:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ming.Aaron.Liu@gmail.com>) id 1RjCrj-0003Zq-My
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:42:03 +0000
X-Env-Sender: Ming.Aaron.Liu@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325868115!9874605!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 20716 invoked from network); 6 Jan 2012 16:41:57 -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;
	6 Jan 2012 16:41:57 -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 1RjCrb-0004Hm-2m
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 08:41:55 -0800
Date: Fri, 6 Jan 2012 08:41:55 -0800 (PST)
From: lmingcsce <Ming.Aaron.Liu@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325868115079-5126037.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] DomU memory update procedures ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, I have a question about memory update of DomU. 
When DomU writes a new value to a memory address, how does hypervisor change
the value in the particular address and change the dirty page bit? 
In my current understanding, I find that there is a hypercal do_mmu_update
in the hypervisor changing the content in the memory. However, I want to
know the details about the memory update procedures. Or you can simply tell
me how can I find this procedures.
Thanks for your help. 

--
View this message in context: http://xen.1045712.n5.nabble.com/DomU-memory-update-procedures-tp5126037p5126037.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 Jan 06 16:48:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCxj-0003xf-8Z; Fri, 06 Jan 2012 16:48:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elthariel@gmail.com>) id 1RjCxh-0003xV-Vh
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:48:14 +0000
X-Env-Sender: elthariel@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1325868487!11327031!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11378 invoked from network); 6 Jan 2012 16:48:07 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 16:48:07 -0000
Received: by wico1 with SMTP id o1so3013857wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 08:48: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:content-type;
	bh=4mlDR4K63Zp1eRqlrBn5hpwi/3FE4XbWnxN/5V2UN+k=;
	b=jBEPCI9+5VWamVo4FxCAqlz6179iigd53OhW07Qi+8f7m2K4Q8J9mqXb6VABK90btj
	0WsOBJF5jWZkTsNKc9az89/eqnghmIx6O5KwzeTdlwvLQ6QzzrYTCAithS0MQUrYs5NM
	QPFYJPTSDtwvpCEHIdBru5Q2oQq6f+JCyLi/0=
MIME-Version: 1.0
Received: by 10.180.91.201 with SMTP id cg9mr12654083wib.15.1325868486805;
	Fri, 06 Jan 2012 08:48:06 -0800 (PST)
Received: by 10.216.181.202 with HTTP; Fri, 6 Jan 2012 08:48:06 -0800 (PST)
In-Reply-To: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
Date: Fri, 6 Jan 2012 17:48:06 +0100
X-Google-Sender-Auth: eN0LPaQCd9iZKUgYvVnR-d5oNyQ
Message-ID: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
From: "-+= Lta =+-" <lta@akr.fm>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success report.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2371626196972212935=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2371626196972212935==
Content-Type: multipart/alternative; boundary=f46d043bdf142cc8dd04b5ded0b5

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

Hello xen-devel,


This is my first post on this list and as such i might be breaking some
explicit/implicit rules and i apologize if it's the case. Maybe this list
isn't the exact right kind of place where to post this kind of stuff, but i
know lots of us are browsing this list as the primary source of
documentation for xen.

I've read many times windows 7 isn't the right os to run on top of xen.
Most of the guy's who are running vga passthru are recommanding to use
windows xp, and i've never seen any success report of vga passthru on
windows 7 so i thought it was important to post mine.

Anyway, here's my hardware setup :
- Gigabyte GA-990X-UD3
- AMD Phenom II X6 1075T Processor
- MSI Cyclone NVIDIA Geforce GTX 460

On the software side i'm using :

- Debian testing as Dom0
- Xen-4.1 (debian version 4.1.2-2) with what's now referred to as "Tobias
Geiger patches" (
http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html)
(You have to edit the patches, changing the path to some qemu source files
for them to apply)
- debian's kernel  3.1.5, compiled to include the pciback driver. Here's
the output of `cat /boot/my3.1.5config | grep -i xen`
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_XEN_DEBUG is not set
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=m
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_BACKEND=m
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_XEN_WDT=m
CONFIG_XEN_FBDEV_FRONTEND=y
# Xen driver support
CONFIG_XEN_BALLOON=y
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_XEN_PLATFORM_PCI=m
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PCIDEV_BACKEND=y

The kernel boot options are 'nomodeset xen-pciback.passthrough=1
xen-pciback.hide=(01:00.0)(01:00.1)'

- Here's my win7 domU config file :

kernel = "/usr/lib/xen-4.1/boot/hvmloader"
builder='hvm'
memory = 3072
name = "w7"
vif = [ 'type=netfront,bridge=xenbr0, mac=00:16:3e:35:49:62']
disk = [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']
device_model = '/usr/lib/xen-4.1/bin/qemu-dm'
boot="dc"

pci=['01:00.0','01:00.1']
gfx_passthru=1

vcpus=6
acpi=1
sdl=0
vnc=1
vncconsole=1
vncpasswd=''
serial='pty'
usbdevice='tablet'
pae=1
pci_msitranslate=0
pci_power_mgmt=0
acpi_s3 = 1
acpi_s4 = 1
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
xen_platform_pci=1
hpet = 1
viridian=1
monitor=1
xen_extended_power_mgmt=2
hpet=1

What's important here for the Nvidia drivers to work and not give a nice
nvlddmkm.sys BSOD is:
pci_msitranslate=0
pci_power_mgmt=0

- Windows 7 32bits
- Nvidia drivers 275.33
- You have to manually run aero speed test or force aero to start by using
registry entries for the desktop not to be laggy

The windows 7 domU is running fine with no performance decrease noticeable,
although i've not yet played intensive gpu video game, i'm still pretty
confident they'll run fine.

Anyway. i've still some problems i shall report in separate posts :
- The PCI bus topology isn't preserved, and the gfx card, which is plugged
on 01:00 becomes 05:00 on domU.
- I'm passing through an RME Hdsp / hammerfall pci sound card to the domU
and while it is working fine on his own, there's a strange interaction
between it and the GPLPV network driver. When i start playing sound, the
network instantly cease working. It starts back as soon as i stop playing
audio.

That's all folks,

Cheers,
Lta

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

<div class=3D"gmail_quote">Hello xen-devel,<div><br></div><div><br></div><d=
iv>This is my first post on this list and as such i might be breaking some =
explicit/implicit rules and i apologize if it&#39;s the case. Maybe this li=
st isn&#39;t the exact=A0right=A0kind of place where to post this kind of s=
tuff, but i know lots of us are browsing this list as the primary source of=
 documentation for xen.</div>

<div><br></div><div>I&#39;ve read many times windows 7 isn&#39;t the right =
os to run on top of xen. Most of the guy&#39;s who are running vga passthru=
 are recommanding to use windows xp, and i&#39;ve never seen any success re=
port of vga passthru on windows 7 so i thought it was important to post min=
e.</div>

<div><br></div><div>Anyway, here&#39;s my hardware setup :</div><div>- Giga=
byte GA-990X-UD3</div><div>-=A0AMD Phenom II X6 1075T Processor</div><div>-=
 MSI Cyclone NVIDIA Geforce GTX 460</div><div><br></div><div>On the softwar=
e side i&#39;m using :</div>

<div><br></div><div>- Debian testing as Dom0</div><div>- Xen-4.1 (debian ve=
rsion 4.1.2-2) with what&#39;s now referred to as &quot;Tobias Geiger patch=
es&quot; (<a href=3D"http://old-list-archives.xen.org/archives/html/xen-dev=
el/2010-05/msg00441.html" target=3D"_blank">http://old-list-archives.xen.or=
g/archives/html/xen-devel/2010-05/msg00441.html</a>) (You have to edit the =
patches, changing the path to some qemu source files for them to apply)</di=
v>

<div>- debian&#39;s kernel =A03.1.5, compiled to include the pciback driver=
. Here&#39;s the output of `cat /boot/my3.1.5config | grep -i xen`</div><di=
v><div><font size=3D"1">CONFIG_XEN=3Dy</font></div><div>
<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><div><font size=3D"1">CONF=
IG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_PV=
HVM=3Dy</font></div>
<div><font size=3D"1">CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><=
font size=3D"1">CONFIG_XEN_SAVE_RESTORE=3Dy</font></div><div><font size=3D"=
1"># CONFIG_XEN_DEBUG_FS is not set</font></div>
<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set</font></div><div><font =
size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_=
PCIDEV_FRONTEND=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font=
 size=3D"1">CONFIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D"1"=
>CONFIG_NETXEN_NIC=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm</font></div><div><font=
 size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></div><div><font size=3D"1"=
>CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>
<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"1">=
CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FRONT=
END=3Dy</font></div>
<div><font size=3D"1"># Xen driver support</font></div><div><font size=3D"1=
">CONFIG_XEN_BALLOON=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_BAL=
LOON_MEMORY_HOTPLUG is not set</font></div>
<div><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font siz=
e=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_BACKEND=3Dy</font></div>
<div><font size=3D"1">CONFIG_XENFS=3Dm</font></div><div><font size=3D"1">CO=
NFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_SYS_=
HYPERVISOR=3Dy</font></div>
<div><font size=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_GRANT_DEV_ALLOC=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</font></div><div><font si=
ze=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XE=
N_PCIDEV_BACKEND=3Dy</font></div>
</div><div><font size=3D"1"><br></font></div><div>The kernel boot options a=
re &#39;nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(=
01:00.1)&#39;</div><div><br></div><div>- Here&#39;s my win7 domU config fil=
e :</div>

<div><br></div><div><div><font size=3D"1">kernel =3D &quot;/usr/lib/xen-4.1=
/boot/hvmloader&quot;</font></div><div><font size=3D"1">builder=3D&#39;hvm&=
#39;</font></div><div><font size=3D"1">memory =3D 3072</font></div>
<div><font size=3D"1">name =3D &quot;w7&quot;</font></div><div><font size=
=3D"1">vif =3D [ &#39;type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49=
:62&#39;]</font></div><div><font size=3D"1">disk =3D [ &#39;phy:/dev/w7-xen=
/system,hda,w&#39;, &#39;phy:/dev/w7-xen/appz,hdb,w&#39;]</font></div>

<div><font size=3D"1">device_model =3D &#39;/usr/lib/xen-4.1/bin/qemu-dm&#3=
9;</font></div><div><font size=3D"1">boot=3D&quot;dc&quot;</font></div><div=
><font size=3D"1"><br>
</font></div><div><font size=3D"1">pci=3D[&#39;01:00.0&#39;,&#39;01:00.1&#3=
9;]</font></div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><fo=
nt size=3D"1"><br>
</font></div><div><font size=3D"1">vcpus=3D6</font></div><div><font size=3D=
"1">acpi=3D1</font></div><div><font size=3D"1">sdl=3D0</font></div><div><fo=
nt size=3D"1">vnc=3D1</font></div>
<div><font size=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncp=
asswd=3D&#39;&#39;</font></div><div><font size=3D"1">serial=3D&#39;pty&#39;=
</font></div>
<div><font size=3D"1">usbdevice=3D&#39;tablet&#39;</font></div><div><font s=
ize=3D"1">pae=3D1</font></div><div><font size=3D"1">pci_msitranslate=3D0</f=
ont></div>
<div><font size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">=
acpi_s3 =3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><=
div><font size=3D"1">on_poweroff =3D &#39;destroy&#39;</font></div>
<div><font size=3D"1">on_reboot =A0 =3D &#39;restart&#39;</font></div><div>=
<font size=3D"1">on_crash =A0 =A0=3D &#39;restart&#39;</font></div><div><fo=
nt size=3D"1">xen_platform_pci=3D1</font></div>
<div><font size=3D"1">hpet =3D 1</font></div><div><font size=3D"1">viridian=
=3D1</font></div><div><font size=3D"1">monitor=3D1</font></div><div><font s=
ize=3D"1">xen_extended_power_mgmt=3D2</font></div>
<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><div>What&#=
39;s important here for the Nvidia drivers to work and not give a nice nvld=
dmkm.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0</fon=
t></div>

<div><font size=3D"1">pci_power_mgmt=3D0</font></div></div><div><font size=
=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvidia drivers =
275.33</div><div>- You have to manually run aero speed test or force aero t=
o start by using registry entries for the desktop not to be laggy</div>

<div><br></div><div>The windows 7 domU is running fine with no performance =
decrease noticeable, although i&#39;ve not yet played intensive gpu video g=
ame, i&#39;m still pretty confident they&#39;ll run fine.</div><div><br>

</div><div>Anyway. i&#39;ve still some problems i shall report in separate =
posts :</div><div>- The PCI bus topology isn&#39;t preserved, and the gfx c=
ard, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I&#39;m p=
assing through an RME Hdsp / hammerfall pci sound card to the domU and whil=
e it is working fine on his own, there&#39;s a strange interaction between =
it and the GPLPV network driver. When i start playing sound, the network in=
stantly cease working. It starts back as soon as i stop playing audio.</div=
>

<div><br></div><div>That&#39;s all folks,</div><div><br></div><div>Cheers,<=
/div><div>Lta</div>
</div><br>

--f46d043bdf142cc8dd04b5ded0b5--


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

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

--===============2371626196972212935==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:48:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjCxj-0003xf-8Z; Fri, 06 Jan 2012 16:48:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elthariel@gmail.com>) id 1RjCxh-0003xV-Vh
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:48:14 +0000
X-Env-Sender: elthariel@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1325868487!11327031!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11378 invoked from network); 6 Jan 2012 16:48:07 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 16:48:07 -0000
Received: by wico1 with SMTP id o1so3013857wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 08:48: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:content-type;
	bh=4mlDR4K63Zp1eRqlrBn5hpwi/3FE4XbWnxN/5V2UN+k=;
	b=jBEPCI9+5VWamVo4FxCAqlz6179iigd53OhW07Qi+8f7m2K4Q8J9mqXb6VABK90btj
	0WsOBJF5jWZkTsNKc9az89/eqnghmIx6O5KwzeTdlwvLQ6QzzrYTCAithS0MQUrYs5NM
	QPFYJPTSDtwvpCEHIdBru5Q2oQq6f+JCyLi/0=
MIME-Version: 1.0
Received: by 10.180.91.201 with SMTP id cg9mr12654083wib.15.1325868486805;
	Fri, 06 Jan 2012 08:48:06 -0800 (PST)
Received: by 10.216.181.202 with HTTP; Fri, 6 Jan 2012 08:48:06 -0800 (PST)
In-Reply-To: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
Date: Fri, 6 Jan 2012 17:48:06 +0100
X-Google-Sender-Auth: eN0LPaQCd9iZKUgYvVnR-d5oNyQ
Message-ID: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
From: "-+= Lta =+-" <lta@akr.fm>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success report.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2371626196972212935=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2371626196972212935==
Content-Type: multipart/alternative; boundary=f46d043bdf142cc8dd04b5ded0b5

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

Hello xen-devel,


This is my first post on this list and as such i might be breaking some
explicit/implicit rules and i apologize if it's the case. Maybe this list
isn't the exact right kind of place where to post this kind of stuff, but i
know lots of us are browsing this list as the primary source of
documentation for xen.

I've read many times windows 7 isn't the right os to run on top of xen.
Most of the guy's who are running vga passthru are recommanding to use
windows xp, and i've never seen any success report of vga passthru on
windows 7 so i thought it was important to post mine.

Anyway, here's my hardware setup :
- Gigabyte GA-990X-UD3
- AMD Phenom II X6 1075T Processor
- MSI Cyclone NVIDIA Geforce GTX 460

On the software side i'm using :

- Debian testing as Dom0
- Xen-4.1 (debian version 4.1.2-2) with what's now referred to as "Tobias
Geiger patches" (
http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html)
(You have to edit the patches, changing the path to some qemu source files
for them to apply)
- debian's kernel  3.1.5, compiled to include the pciback driver. Here's
the output of `cat /boot/my3.1.5config | grep -i xen`
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_XEN_DEBUG is not set
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=m
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_BACKEND=m
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_XEN_WDT=m
CONFIG_XEN_FBDEV_FRONTEND=y
# Xen driver support
CONFIG_XEN_BALLOON=y
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_XEN_PLATFORM_PCI=m
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PCIDEV_BACKEND=y

The kernel boot options are 'nomodeset xen-pciback.passthrough=1
xen-pciback.hide=(01:00.0)(01:00.1)'

- Here's my win7 domU config file :

kernel = "/usr/lib/xen-4.1/boot/hvmloader"
builder='hvm'
memory = 3072
name = "w7"
vif = [ 'type=netfront,bridge=xenbr0, mac=00:16:3e:35:49:62']
disk = [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']
device_model = '/usr/lib/xen-4.1/bin/qemu-dm'
boot="dc"

pci=['01:00.0','01:00.1']
gfx_passthru=1

vcpus=6
acpi=1
sdl=0
vnc=1
vncconsole=1
vncpasswd=''
serial='pty'
usbdevice='tablet'
pae=1
pci_msitranslate=0
pci_power_mgmt=0
acpi_s3 = 1
acpi_s4 = 1
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
xen_platform_pci=1
hpet = 1
viridian=1
monitor=1
xen_extended_power_mgmt=2
hpet=1

What's important here for the Nvidia drivers to work and not give a nice
nvlddmkm.sys BSOD is:
pci_msitranslate=0
pci_power_mgmt=0

- Windows 7 32bits
- Nvidia drivers 275.33
- You have to manually run aero speed test or force aero to start by using
registry entries for the desktop not to be laggy

The windows 7 domU is running fine with no performance decrease noticeable,
although i've not yet played intensive gpu video game, i'm still pretty
confident they'll run fine.

Anyway. i've still some problems i shall report in separate posts :
- The PCI bus topology isn't preserved, and the gfx card, which is plugged
on 01:00 becomes 05:00 on domU.
- I'm passing through an RME Hdsp / hammerfall pci sound card to the domU
and while it is working fine on his own, there's a strange interaction
between it and the GPLPV network driver. When i start playing sound, the
network instantly cease working. It starts back as soon as i stop playing
audio.

That's all folks,

Cheers,
Lta

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

<div class=3D"gmail_quote">Hello xen-devel,<div><br></div><div><br></div><d=
iv>This is my first post on this list and as such i might be breaking some =
explicit/implicit rules and i apologize if it&#39;s the case. Maybe this li=
st isn&#39;t the exact=A0right=A0kind of place where to post this kind of s=
tuff, but i know lots of us are browsing this list as the primary source of=
 documentation for xen.</div>

<div><br></div><div>I&#39;ve read many times windows 7 isn&#39;t the right =
os to run on top of xen. Most of the guy&#39;s who are running vga passthru=
 are recommanding to use windows xp, and i&#39;ve never seen any success re=
port of vga passthru on windows 7 so i thought it was important to post min=
e.</div>

<div><br></div><div>Anyway, here&#39;s my hardware setup :</div><div>- Giga=
byte GA-990X-UD3</div><div>-=A0AMD Phenom II X6 1075T Processor</div><div>-=
 MSI Cyclone NVIDIA Geforce GTX 460</div><div><br></div><div>On the softwar=
e side i&#39;m using :</div>

<div><br></div><div>- Debian testing as Dom0</div><div>- Xen-4.1 (debian ve=
rsion 4.1.2-2) with what&#39;s now referred to as &quot;Tobias Geiger patch=
es&quot; (<a href=3D"http://old-list-archives.xen.org/archives/html/xen-dev=
el/2010-05/msg00441.html" target=3D"_blank">http://old-list-archives.xen.or=
g/archives/html/xen-devel/2010-05/msg00441.html</a>) (You have to edit the =
patches, changing the path to some qemu source files for them to apply)</di=
v>

<div>- debian&#39;s kernel =A03.1.5, compiled to include the pciback driver=
. Here&#39;s the output of `cat /boot/my3.1.5config | grep -i xen`</div><di=
v><div><font size=3D"1">CONFIG_XEN=3Dy</font></div><div>
<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><div><font size=3D"1">CONF=
IG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_PV=
HVM=3Dy</font></div>
<div><font size=3D"1">CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><=
font size=3D"1">CONFIG_XEN_SAVE_RESTORE=3Dy</font></div><div><font size=3D"=
1"># CONFIG_XEN_DEBUG_FS is not set</font></div>
<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set</font></div><div><font =
size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_=
PCIDEV_FRONTEND=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font=
 size=3D"1">CONFIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D"1"=
>CONFIG_NETXEN_NIC=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm</font></div><div><font=
 size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></div><div><font size=3D"1"=
>CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>
<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"1">=
CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FRONT=
END=3Dy</font></div>
<div><font size=3D"1"># Xen driver support</font></div><div><font size=3D"1=
">CONFIG_XEN_BALLOON=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_BAL=
LOON_MEMORY_HOTPLUG is not set</font></div>
<div><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font siz=
e=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_BACKEND=3Dy</font></div>
<div><font size=3D"1">CONFIG_XENFS=3Dm</font></div><div><font size=3D"1">CO=
NFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_SYS_=
HYPERVISOR=3Dy</font></div>
<div><font size=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_GRANT_DEV_ALLOC=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</font></div><div><font si=
ze=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XE=
N_PCIDEV_BACKEND=3Dy</font></div>
</div><div><font size=3D"1"><br></font></div><div>The kernel boot options a=
re &#39;nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(=
01:00.1)&#39;</div><div><br></div><div>- Here&#39;s my win7 domU config fil=
e :</div>

<div><br></div><div><div><font size=3D"1">kernel =3D &quot;/usr/lib/xen-4.1=
/boot/hvmloader&quot;</font></div><div><font size=3D"1">builder=3D&#39;hvm&=
#39;</font></div><div><font size=3D"1">memory =3D 3072</font></div>
<div><font size=3D"1">name =3D &quot;w7&quot;</font></div><div><font size=
=3D"1">vif =3D [ &#39;type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49=
:62&#39;]</font></div><div><font size=3D"1">disk =3D [ &#39;phy:/dev/w7-xen=
/system,hda,w&#39;, &#39;phy:/dev/w7-xen/appz,hdb,w&#39;]</font></div>

<div><font size=3D"1">device_model =3D &#39;/usr/lib/xen-4.1/bin/qemu-dm&#3=
9;</font></div><div><font size=3D"1">boot=3D&quot;dc&quot;</font></div><div=
><font size=3D"1"><br>
</font></div><div><font size=3D"1">pci=3D[&#39;01:00.0&#39;,&#39;01:00.1&#3=
9;]</font></div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><fo=
nt size=3D"1"><br>
</font></div><div><font size=3D"1">vcpus=3D6</font></div><div><font size=3D=
"1">acpi=3D1</font></div><div><font size=3D"1">sdl=3D0</font></div><div><fo=
nt size=3D"1">vnc=3D1</font></div>
<div><font size=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncp=
asswd=3D&#39;&#39;</font></div><div><font size=3D"1">serial=3D&#39;pty&#39;=
</font></div>
<div><font size=3D"1">usbdevice=3D&#39;tablet&#39;</font></div><div><font s=
ize=3D"1">pae=3D1</font></div><div><font size=3D"1">pci_msitranslate=3D0</f=
ont></div>
<div><font size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">=
acpi_s3 =3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><=
div><font size=3D"1">on_poweroff =3D &#39;destroy&#39;</font></div>
<div><font size=3D"1">on_reboot =A0 =3D &#39;restart&#39;</font></div><div>=
<font size=3D"1">on_crash =A0 =A0=3D &#39;restart&#39;</font></div><div><fo=
nt size=3D"1">xen_platform_pci=3D1</font></div>
<div><font size=3D"1">hpet =3D 1</font></div><div><font size=3D"1">viridian=
=3D1</font></div><div><font size=3D"1">monitor=3D1</font></div><div><font s=
ize=3D"1">xen_extended_power_mgmt=3D2</font></div>
<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><div>What&#=
39;s important here for the Nvidia drivers to work and not give a nice nvld=
dmkm.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0</fon=
t></div>

<div><font size=3D"1">pci_power_mgmt=3D0</font></div></div><div><font size=
=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvidia drivers =
275.33</div><div>- You have to manually run aero speed test or force aero t=
o start by using registry entries for the desktop not to be laggy</div>

<div><br></div><div>The windows 7 domU is running fine with no performance =
decrease noticeable, although i&#39;ve not yet played intensive gpu video g=
ame, i&#39;m still pretty confident they&#39;ll run fine.</div><div><br>

</div><div>Anyway. i&#39;ve still some problems i shall report in separate =
posts :</div><div>- The PCI bus topology isn&#39;t preserved, and the gfx c=
ard, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I&#39;m p=
assing through an RME Hdsp / hammerfall pci sound card to the domU and whil=
e it is working fine on his own, there&#39;s a strange interaction between =
it and the GPLPV network driver. When i start playing sound, the network in=
stantly cease working. It starts back as soon as i stop playing audio.</div=
>

<div><br></div><div>That&#39;s all folks,</div><div><br></div><div>Cheers,<=
/div><div>Lta</div>
</div><br>

--f46d043bdf142cc8dd04b5ded0b5--


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

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

--===============2371626196972212935==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:51:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 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 1RjD0P-0004DJ-KN; Fri, 06 Jan 2012 16:51:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RjD0N-0004Ci-UV
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:51:00 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1325868653!8089335!1
X-Originating-IP: [217.72.192.234]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiAzNzYy\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiAzNzYy\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21947 invoked from network); 6 Jan 2012 16:50:53 -0000
Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234)
	by server-4.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 16:50:53 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate03.web.de (Postfix) with ESMTP id 1ACDE1AF48C9B
	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 17:50:53 +0100 (CET)
Received: from netbook.home ([187.105.25.94]) by smtp.web.de (mrweb002) with
	ESMTPA (Nemesis) id 0M5woT-1SgYzI2fHd-00xebB;
	Fri, 06 Jan 2012 17:50:52 +0100
Message-ID: <4F072664.3070000@web.de>
Date: Fri, 06 Jan 2012 14:50:44 -0200
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: Peter Maydell <peter.maydell@linaro.org>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<CAFEAcA-A7YujsGDpGezxeNmB9z5rG=Rtp7UHX1R5wWoL=wukwA@mail.gmail.com>
In-Reply-To: <CAFEAcA-A7YujsGDpGezxeNmB9z5rG=Rtp7UHX1R5wWoL=wukwA@mail.gmail.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:+YbwLVpELaJxQh6wNZMr+PfBaHYwfuvVZFWeQV4Bwbi
	6v2JR0svmxvzwx28fRwsJnQKwj6EHlIQ4Yh+J/9MFe7MRt2fHU
	toRoOZI0CxZ2W2DALoQKPUeu6MDWYHrJKzcCoU6FSFbxvNxpZh
	iPqXlt3+wqewDeRlozzVhi+1/yRIlk8aqmAbj8jzLJcwDCaHzq
	teIb8AE6sAaR8g4G76BWg==
Cc: Anthony Perard <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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: multipart/mixed; boundary="===============9074248504482393012=="
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)
--===============9074248504482393012==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig7D8EE30EADF2B9FB4905657F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7D8EE30EADF2B9FB4905657F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2012-01-06 13:58, Peter Maydell wrote:
> On 6 January 2012 13:30, Jan Kiszka <jan.kiszka@web.de> wrote:
>> The third point indicates that there is rather more generic room for
>> improvements: Why should qemu reset device models before restore at al=
l?
>=20
> Commit 5a8a49d7aa says:
> # if we load from a snapshot, the machine can be in any state. That can=

> # cause troubles if loading an older image which does not carry all sta=
te
> # information the executing QEMU requires. Hardly any device takes care=
 of
> # this scenario.
>=20
> I think it's also easier to reason about devices if you know that the
> device before a load was in a known clean state rather than being
> anything at all.

True, that's why we do this ATM. But issuing the reset globally without
giving devices chance to handle this more precisely is just a suboptimal
workaround, one that we may want to overcome at some point.

Jan


--------------enig7D8EE30EADF2B9FB4905657F
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.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8HJmQACgkQitSsb3rl5xQXbgCgln3tGCQ2ZxLyCAxIoM1X5Wfs
vAYAoLCNzt56MjBceak1+pr+8ankm0Rz
=8647
-----END PGP SIGNATURE-----

--------------enig7D8EE30EADF2B9FB4905657F--


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

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

--===============9074248504482393012==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:51:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 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 1RjD0P-0004DJ-KN; Fri, 06 Jan 2012 16:51:01 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RjD0N-0004Ci-UV
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:51:00 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-4.tower-174.messagelabs.com!1325868653!8089335!1
X-Originating-IP: [217.72.192.234]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiAzNzYy\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiAzNzYy\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21947 invoked from network); 6 Jan 2012 16:50:53 -0000
Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234)
	by server-4.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 16:50:53 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate03.web.de (Postfix) with ESMTP id 1ACDE1AF48C9B
	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 17:50:53 +0100 (CET)
Received: from netbook.home ([187.105.25.94]) by smtp.web.de (mrweb002) with
	ESMTPA (Nemesis) id 0M5woT-1SgYzI2fHd-00xebB;
	Fri, 06 Jan 2012 17:50:52 +0100
Message-ID: <4F072664.3070000@web.de>
Date: Fri, 06 Jan 2012 14:50:44 -0200
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: Peter Maydell <peter.maydell@linaro.org>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<CAFEAcA-A7YujsGDpGezxeNmB9z5rG=Rtp7UHX1R5wWoL=wukwA@mail.gmail.com>
In-Reply-To: <CAFEAcA-A7YujsGDpGezxeNmB9z5rG=Rtp7UHX1R5wWoL=wukwA@mail.gmail.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:+YbwLVpELaJxQh6wNZMr+PfBaHYwfuvVZFWeQV4Bwbi
	6v2JR0svmxvzwx28fRwsJnQKwj6EHlIQ4Yh+J/9MFe7MRt2fHU
	toRoOZI0CxZ2W2DALoQKPUeu6MDWYHrJKzcCoU6FSFbxvNxpZh
	iPqXlt3+wqewDeRlozzVhi+1/yRIlk8aqmAbj8jzLJcwDCaHzq
	teIb8AE6sAaR8g4G76BWg==
Cc: Anthony Perard <anthony.perard@citrix.com>,
	QEMU-devel <qemu-devel@nongnu.org>,
	Xen Devel <xen-devel@lists.xensource.com>, Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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: multipart/mixed; boundary="===============9074248504482393012=="
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)
--===============9074248504482393012==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig7D8EE30EADF2B9FB4905657F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7D8EE30EADF2B9FB4905657F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2012-01-06 13:58, Peter Maydell wrote:
> On 6 January 2012 13:30, Jan Kiszka <jan.kiszka@web.de> wrote:
>> The third point indicates that there is rather more generic room for
>> improvements: Why should qemu reset device models before restore at al=
l?
>=20
> Commit 5a8a49d7aa says:
> # if we load from a snapshot, the machine can be in any state. That can=

> # cause troubles if loading an older image which does not carry all sta=
te
> # information the executing QEMU requires. Hardly any device takes care=
 of
> # this scenario.
>=20
> I think it's also easier to reason about devices if you know that the
> device before a load was in a known clean state rather than being
> anything at all.

True, that's why we do this ATM. But issuing the reset globally without
giving devices chance to handle this more precisely is just a suboptimal
workaround, one that we may want to overcome at some point.

Jan


--------------enig7D8EE30EADF2B9FB4905657F
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.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8HJmQACgkQitSsb3rl5xQXbgCgln3tGCQ2ZxLyCAxIoM1X5Wfs
vAYAoLCNzt56MjBceak1+pr+8ankm0Rz
=8647
-----END PGP SIGNATURE-----

--------------enig7D8EE30EADF2B9FB4905657F--


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

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

--===============9074248504482393012==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:51:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16: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 1RjD0c-0004Ft-9w; Fri, 06 Jan 2012 16:51:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elthariel@gmail.com>) id 1RjD0a-0004Em-Br
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:51:12 +0000
X-Env-Sender: elthariel@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325868664!9870432!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20625 invoked from network); 6 Jan 2012 16:51:04 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 16:51:04 -0000
Received: by wico1 with SMTP id o1so3018303wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 08:51: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=+pfFAYI3a4WqYu/aNsj+aKM0sRT5Cir39E6Z5hWxuYA=;
	b=OZFeBplKxVhTfU9K+8gaEJSEWxki0sFVupLL54gl9FEKSKekR9HpdPhlPPJ4Q8DNQM
	zYzL4KCAU5aVrM4/JjXZe8YhhHvu1r40UejDQEb2Z8+0ftR5KPXsBxTUo/+TlVIbISEp
	IUsqHkZu2f1L0bIjePqftwjlBnbuePJxzkPQY=
MIME-Version: 1.0
Received: by 10.180.91.201 with SMTP id cg9mr12672257wib.15.1325868664206;
	Fri, 06 Jan 2012 08:51:04 -0800 (PST)
Received: by 10.216.181.202 with HTTP; Fri, 6 Jan 2012 08:51:04 -0800 (PST)
In-Reply-To: <1325867688317-5126020.post@n5.nabble.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
	<1325867688317-5126020.post@n5.nabble.com>
Date: Fri, 6 Jan 2012 17:51:04 +0100
X-Google-Sender-Auth: xqLp_TGZDsvyX59DagjC1TYe5hg
Message-ID: <CAFV75=yMMuCv7Os1zjBo=p51+SOn0wqOF+0-4T33D-nbfPpAiA@mail.gmail.com>
From: "-+= Lta =+-" <lta@akr.fm>
To: n4rC0t1C <shandivo@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 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="===============1225811875951291944=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1225811875951291944==
Content-Type: multipart/alternative; boundary=f46d043bdf14bfb53904b5deda35

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

On Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C <shandivo@gmail.com> wrote:

>
> -+= Lta =+- wrote
> >
> > Hello,
> >
> > I've just posted on the list my setup of a working win7 domu with an
> > nvidia
> > card. You might wanna have a look.
> >
> > --
> > Lta
> >
> > On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &lt;davidtecher@&gt; wrote:
> >
> >
>
> Sorry, where? Dind't find the post. REALLY interested.
>


Hi,

I must have sent him from the wrong address so the list refused it. I've
resent it with the right one, it should be in your inbox somewhere

Regards,
Lta


>
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.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
>

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

<br><br><div class=3D"gmail_quote">On Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:shandivo@gmail.com">shandivo@gmail=
.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-+=3D Lta =3D+- wrote<br>
<div class=3D"im">&gt;<br>
&gt; Hello,<br>
&gt;<br>
&gt; I&#39;ve just posted on the list my setup of a working win7 domu with =
an<br>
&gt; nvidia<br>
&gt; card. You might wanna have a look.<br>
&gt;<br>
&gt; --<br>
&gt; Lta<br>
&gt;<br>
</div>&gt; On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &amp;lt;davidtecher=
@&amp;gt; wrote:<br>
&gt;<br>
&gt;<br>
<br>
Sorry, where? Dind&#39;t find the post. REALLY interested.<br></blockquote>=
<div><br></div><div><br></div><div>Hi,<br><div><br></div><div>I must have s=
ent him from the wrong address so the list refused it. I&#39;ve resent it w=
ith the right one, it should be in your inbox somewhere</div>
</div><div><br></div><div>Regards,</div><div>Lta</div><div>=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/P=
atches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.html" target=
=3D"_blank">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XE=
N-4-2-unstable-tp4406265p5126020.html</a><br>

</font></span><div class=3D"HOEnZb"><div class=3D"h5">Sent from the Xen - D=
ev mailing list archive at Nabble.com.<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>

--f46d043bdf14bfb53904b5deda35--


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

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

--===============1225811875951291944==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:51:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16: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 1RjD0c-0004Ft-9w; Fri, 06 Jan 2012 16:51:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elthariel@gmail.com>) id 1RjD0a-0004Em-Br
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:51:12 +0000
X-Env-Sender: elthariel@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325868664!9870432!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20625 invoked from network); 6 Jan 2012 16:51:04 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 16:51:04 -0000
Received: by wico1 with SMTP id o1so3018303wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 08:51: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=+pfFAYI3a4WqYu/aNsj+aKM0sRT5Cir39E6Z5hWxuYA=;
	b=OZFeBplKxVhTfU9K+8gaEJSEWxki0sFVupLL54gl9FEKSKekR9HpdPhlPPJ4Q8DNQM
	zYzL4KCAU5aVrM4/JjXZe8YhhHvu1r40UejDQEb2Z8+0ftR5KPXsBxTUo/+TlVIbISEp
	IUsqHkZu2f1L0bIjePqftwjlBnbuePJxzkPQY=
MIME-Version: 1.0
Received: by 10.180.91.201 with SMTP id cg9mr12672257wib.15.1325868664206;
	Fri, 06 Jan 2012 08:51:04 -0800 (PST)
Received: by 10.216.181.202 with HTTP; Fri, 6 Jan 2012 08:51:04 -0800 (PST)
In-Reply-To: <1325867688317-5126020.post@n5.nabble.com>
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
	<1325867688317-5126020.post@n5.nabble.com>
Date: Fri, 6 Jan 2012 17:51:04 +0100
X-Google-Sender-Auth: xqLp_TGZDsvyX59DagjC1TYe5hg
Message-ID: <CAFV75=yMMuCv7Os1zjBo=p51+SOn0wqOF+0-4T33D-nbfPpAiA@mail.gmail.com>
From: "-+= Lta =+-" <lta@akr.fm>
To: n4rC0t1C <shandivo@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] 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="===============1225811875951291944=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1225811875951291944==
Content-Type: multipart/alternative; boundary=f46d043bdf14bfb53904b5deda35

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

On Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C <shandivo@gmail.com> wrote:

>
> -+= Lta =+- wrote
> >
> > Hello,
> >
> > I've just posted on the list my setup of a working win7 domu with an
> > nvidia
> > card. You might wanna have a look.
> >
> > --
> > Lta
> >
> > On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &lt;davidtecher@&gt; wrote:
> >
> >
>
> Sorry, where? Dind't find the post. REALLY interested.
>


Hi,

I must have sent him from the wrong address so the list refused it. I've
resent it with the right one, it should be in your inbox somewhere

Regards,
Lta


>
> --
> View this message in context:
> http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.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
>

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

<br><br><div class=3D"gmail_quote">On Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:shandivo@gmail.com">shandivo@gmail=
.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-+=3D Lta =3D+- wrote<br>
<div class=3D"im">&gt;<br>
&gt; Hello,<br>
&gt;<br>
&gt; I&#39;ve just posted on the list my setup of a working win7 domu with =
an<br>
&gt; nvidia<br>
&gt; card. You might wanna have a look.<br>
&gt;<br>
&gt; --<br>
&gt; Lta<br>
&gt;<br>
</div>&gt; On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &amp;lt;davidtecher=
@&amp;gt; wrote:<br>
&gt;<br>
&gt;<br>
<br>
Sorry, where? Dind&#39;t find the post. REALLY interested.<br></blockquote>=
<div><br></div><div><br></div><div>Hi,<br><div><br></div><div>I must have s=
ent him from the wrong address so the list refused it. I&#39;ve resent it w=
ith the right one, it should be in your inbox somewhere</div>
</div><div><br></div><div>Regards,</div><div>Lta</div><div>=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
View this message in context: <a href=3D"http://xen.1045712.n5.nabble.com/P=
atches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.html" target=
=3D"_blank">http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XE=
N-4-2-unstable-tp4406265p5126020.html</a><br>

</font></span><div class=3D"HOEnZb"><div class=3D"h5">Sent from the Xen - D=
ev mailing list archive at Nabble.com.<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>

--f46d043bdf14bfb53904b5deda35--


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

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

--===============1225811875951291944==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:58:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjD7i-00057F-W4; Fri, 06 Jan 2012 16:58:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjD7h-00056x-QL
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:58:34 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325869106!9815165!1
X-Originating-IP: [212.82.109.231]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,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 16981 invoked from network); 6 Jan 2012 16:58:26 -0000
Received: from nm23-vm2.bullet.mail.ird.yahoo.com (HELO
	nm23-vm2.bullet.mail.ird.yahoo.com) (212.82.109.231)
	by server-15.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 16:58:26 -0000
Received: from [77.238.189.233] by nm23.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 16:58:26 -0000
Received: from [212.82.108.251] by tm14.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 16:58:25 -0000
Received: from [127.0.0.1] by omp1016.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 16:58:25 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 908922.9798.bm@omp1016.mail.ird.yahoo.com
Received: (qmail 32918 invoked by uid 60001); 6 Jan 2012 16:58:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325869105; bh=QxyiqPRpRBRrid29mZ6earqIDe57feK1zARTFB/VN+w=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=5z6guCVYTMov4MEoVE7Je8YdYabz9VJJLBPv75aLlZATjYUUhokq9kYtYaHFF2hQTrpmKlu6qqeEoudI4IeY+xcQvT1I14A7/vQtRGDugWFq7QGVscXBtk+3ntZvn4aj+duTePy79MIQ8EolvycRlWar61dxkvAuF7uBOT64fp0=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=QVLxbHDbeT7ZXwZWXkFltldwc7XHDPpDtDzXmC6tZuCKwGkFrA2MYo+t8MeY2W/pQPfRozfOSu5l0bZ70yV3/qgTazOJZH3ZvQDuHbIBW/pPSGcOpDUIvniyI1qKhBz7+Aas3v6RTeJM1A0Uddy9xjueTip/qENxAuMY9zNEUwg=;
X-YMail-OSG: a74mrOEVM1k25gJRaqJNePdWpdC59SH7kmfDHQ2D_XeimMC
	G6hA75P7mZhIubmF97Wjwot6UEdtRf9TQKzY1Vdh9O6YrKefexanxET7f4qj
	GXkDUxdVonZTNqk0N0uK6odECiuTBzDXRxWegAeDkzMGM7W0jkiQz5Stdgqj
	VMrUJR8L2SQFONpUnbJqy5lQe6.WEn7UYAK6aUTVxmMKsjw12jEWJphdS1QM
	fiT_Q7WjORN00ca9MIjuO5ru_pZNLr__knSbTA4m..Ss6eIYwxNRxCwAh_rH
	fe6fKkoE5mWxq3of2ZzUEaj4noGx5XXMIouLea3Qn6bAw30.J92NtNYGnWqV
	2xWyS8Hc3rxBbxrunkCyA7XpjOUTW7d2HeEIJNp40u.AhGHpNfrOwhzqiZLp
	XRRiIHkAOmDNBQq2P1T.5c4wEte4cgWZkleOYh4ki_zrHMjuvES05_p4MMuU
	ig5VreBSBlD2nQf5ezbw6GF2k0NuiuKS0hMAoUH0dsfLkWBc_wagXtnftjuw
	1IkIcSJwNydfZ80Ad06b0806cvMPT9DN3l99K9DHZtR5IbnxdRHvjODhtQlm
	Lp2A89W8m2PkD_.ZGPvd8Y20ZOEAVUt4PLPc4h1F_CVFLWjreCd6UFAsh4gX
	8Z3MAGCTmWvf..PiY9M9VM5qFs_3h03Sk_pa7nAvb5tJpqMWFpYF7csXo9g_
	K01ufnHc4ApijSLO5lC0RcFiYNhhHavMeRQ--
Received: from [195.167.237.98] by web29806.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 16:58:25 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
	<1325867688317-5126020.post@n5.nabble.com>
	<CAFV75=yMMuCv7Os1zjBo=p51+SOn0wqOF+0-4T33D-nbfPpAiA@mail.gmail.com>
Message-ID: <1325869105.26080.YahooMailNeo@web29806.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 16:58:25 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: -+= Lta =+- <lta@akr.fm>, n4rC0t1C <shandivo@gmail.com>
In-Reply-To: <CAFV75=yMMuCv7Os1zjBo=p51+SOn0wqOF+0-4T33D-nbfPpAiA@mail.gmail.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] 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="===============3726685183355151718=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3726685183355151718==
Content-Type: multipart/alternative; boundary="47836494-918686177-1325869105=:26080"

--47836494-918686177-1325869105=:26080
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Interested too.=0A=0AI did a search on my inbox found nothing even in the i=
ncoming mails you sent=0A=0A=0A=0A________________________________=0A De=A0=
: -+=3D Lta =3D+- <lta@akr.fm>=0A=C0=A0: n4rC0t1C <shandivo@gmail.com> =0AC=
c=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Vendredi 6 Janvier 201=
2 17h51=0AObjet=A0: Re: [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.=
2 unstable=0A =0A=0A=0A=0A=0AOn Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C <shan=
divo@gmail.com> wrote:=0A=0A=0A>-+=3D Lta =3D+- wrote=0A>=0A>>=0A>> Hello,=
=0A>>=0A>> I've just posted on the list my setup of a working win7 domu wit=
h an=0A>> nvidia=0A>> card. You might wanna have a look.=0A>>=0A>> --=0A>> =
Lta=0A>>=0A>> On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &lt;davidtecher@=
&gt; wrote:=0A>>=0A>>=0A>=0A>Sorry, where? Dind't find the post. REALLY int=
erested.=0A>=0A=0A=0AHi,=0A=0A=0AI must have sent him from the wrong addres=
s so the list refused it. I've resent it with the right one, it should be i=
n your inbox somewhere=0A=0ARegards,=0ALta=0A=A0=0A=0A>--=0A>View this mess=
age in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthroug=
h-XEN-4-2-unstable-tp4406265p5126020.html=0A>=0A>Sent from the Xen - Dev ma=
iling list archive at Nabble.com.=0A>=0A>__________________________________=
_____________=0A>Xen-devel mailing list=0A>Xen-devel@lists.xensource.com=0A=
>http://lists.xensource.com/xen-devel=0A>=0A=0A____________________________=
___________________=0AXen-devel mailing list=0AXen-devel@lists.xensource.co=
m=0Ahttp://lists.xensource.com/xen-devel
--47836494-918686177-1325869105=:26080
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>Interested=
 too.</span></div><div><br><span></span></div><div><span>I did a search on =
my inbox found nothing even in the incoming mails you sent<br></span></div>=
<div><br></div>  <div style=3D"font-family: times new roman, new york, time=
s, serif; font-size: 12pt;"> <div style=3D"font-family: times new roman, ne=
w york, times, serif; font-size: 12pt;"> <font size=3D"2" face=3D"Arial"> <=
hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -=
+=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight: bold;"=
>=C0&nbsp;:</span></b> n4rC0t1C &lt;shandivo@gmail.com&gt; <br><b><span sty=
le=3D"font-weight: bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensource.co=
m <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span></b> Vendr=
edi 6 Janvier 2012 17h51<br> <b><span style=3D"font-weight: bold;">Objet&nb=
sp;:</span></b> Re:
 [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.2 unstable<br> </font> =
<br><div id=3D"yiv1978695361"><br><br><div class=3D"yiv1978695361gmail_quot=
e">On Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C <span dir=3D"ltr">&lt;<a rel=3D=
"nofollow" ymailto=3D"mailto:shandivo@gmail.com" target=3D"_blank" href=3D"=
mailto:shandivo@gmail.com">shandivo@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"yiv1978695361gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex;">=0A<br>=0A-+=3D Lta =3D+- wrote<br=
>=0A<div class=3D"yiv1978695361im">&gt;<br>=0A&gt; Hello,<br>=0A&gt;<br>=0A=
&gt; I've just posted on the list my setup of a working win7 domu with an<b=
r>=0A&gt; nvidia<br>=0A&gt; card. You might wanna have a look.<br>=0A&gt;<b=
r>=0A&gt; --<br>=0A&gt; Lta<br>=0A&gt;<br>=0A</div>&gt; On Fri, Jan 6, 2012=
 at 3:23 PM, David TECHER &amp;lt;davidtecher@&amp;gt; wrote:<br>=0A&gt;<br=
>=0A&gt;<br>=0A<br>=0ASorry, where? Dind't find the post. REALLY interested=
.<br></blockquote><div><br></div><div><br></div><div>Hi,<br><div><br></div>=
<div>I must have sent him from the wrong address so the list refused it. I'=
ve resent it with the right one, it should be in your inbox somewhere</div>=
=0A</div><div><br></div><div>Regards,</div><div>Lta</div><div>&nbsp;</div><=
blockquote class=3D"yiv1978695361gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">=0A<span class=3D"yiv1978695361=
HOEnZb"><font color=3D"#888888"><br>=0A--<br>=0AView this message in contex=
t: <a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.nabb=
le.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.html"=
>http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta=
ble-tp4406265p5126020.html</a><br>=0A=0A</font></span><div class=3D"yiv1978=
695361HOEnZb"><div class=3D"yiv1978695361h5">Sent from the Xen - Dev mailin=
g list archive at Nabble.com.<br>=0A<br>=0A________________________________=
_______________<br>=0AXen-devel mailing list<br>=0A<a rel=3D"nofollow" ymai=
lto=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mail=
to:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br>=0A<=
a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensource.com/xen=
-devel">http://lists.xensource.com/xen-devel</a><br>=0A</div></div></blockq=
uote></div><br>=0A</div><br>_______________________________________________=
<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-devel@lists.xensourc=
e.com" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensou=
rce.com</a><br><a href=3D"http://lists.xensource.com/xen-devel" target=3D"_=
blank">http://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  =
</div></body></html>
--47836494-918686177-1325869105=:26080--


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

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

--===============3726685183355151718==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:58:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:58:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjD7i-00057F-W4; Fri, 06 Jan 2012 16:58:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjD7h-00056x-QL
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:58:34 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-15.tower-182.messagelabs.com!1325869106!9815165!1
X-Originating-IP: [212.82.109.231]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,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 16981 invoked from network); 6 Jan 2012 16:58:26 -0000
Received: from nm23-vm2.bullet.mail.ird.yahoo.com (HELO
	nm23-vm2.bullet.mail.ird.yahoo.com) (212.82.109.231)
	by server-15.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 16:58:26 -0000
Received: from [77.238.189.233] by nm23.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 16:58:26 -0000
Received: from [212.82.108.251] by tm14.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 16:58:25 -0000
Received: from [127.0.0.1] by omp1016.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 16:58:25 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 908922.9798.bm@omp1016.mail.ird.yahoo.com
Received: (qmail 32918 invoked by uid 60001); 6 Jan 2012 16:58:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325869105; bh=QxyiqPRpRBRrid29mZ6earqIDe57feK1zARTFB/VN+w=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=5z6guCVYTMov4MEoVE7Je8YdYabz9VJJLBPv75aLlZATjYUUhokq9kYtYaHFF2hQTrpmKlu6qqeEoudI4IeY+xcQvT1I14A7/vQtRGDugWFq7QGVscXBtk+3ntZvn4aj+duTePy79MIQ8EolvycRlWar61dxkvAuF7uBOT64fp0=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=QVLxbHDbeT7ZXwZWXkFltldwc7XHDPpDtDzXmC6tZuCKwGkFrA2MYo+t8MeY2W/pQPfRozfOSu5l0bZ70yV3/qgTazOJZH3ZvQDuHbIBW/pPSGcOpDUIvniyI1qKhBz7+Aas3v6RTeJM1A0Uddy9xjueTip/qENxAuMY9zNEUwg=;
X-YMail-OSG: a74mrOEVM1k25gJRaqJNePdWpdC59SH7kmfDHQ2D_XeimMC
	G6hA75P7mZhIubmF97Wjwot6UEdtRf9TQKzY1Vdh9O6YrKefexanxET7f4qj
	GXkDUxdVonZTNqk0N0uK6odECiuTBzDXRxWegAeDkzMGM7W0jkiQz5Stdgqj
	VMrUJR8L2SQFONpUnbJqy5lQe6.WEn7UYAK6aUTVxmMKsjw12jEWJphdS1QM
	fiT_Q7WjORN00ca9MIjuO5ru_pZNLr__knSbTA4m..Ss6eIYwxNRxCwAh_rH
	fe6fKkoE5mWxq3of2ZzUEaj4noGx5XXMIouLea3Qn6bAw30.J92NtNYGnWqV
	2xWyS8Hc3rxBbxrunkCyA7XpjOUTW7d2HeEIJNp40u.AhGHpNfrOwhzqiZLp
	XRRiIHkAOmDNBQq2P1T.5c4wEte4cgWZkleOYh4ki_zrHMjuvES05_p4MMuU
	ig5VreBSBlD2nQf5ezbw6GF2k0NuiuKS0hMAoUH0dsfLkWBc_wagXtnftjuw
	1IkIcSJwNydfZ80Ad06b0806cvMPT9DN3l99K9DHZtR5IbnxdRHvjODhtQlm
	Lp2A89W8m2PkD_.ZGPvd8Y20ZOEAVUt4PLPc4h1F_CVFLWjreCd6UFAsh4gX
	8Z3MAGCTmWvf..PiY9M9VM5qFs_3h03Sk_pa7nAvb5tJpqMWFpYF7csXo9g_
	K01ufnHc4ApijSLO5lC0RcFiYNhhHavMeRQ--
Received: from [195.167.237.98] by web29806.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 16:58:25 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
	<1325867688317-5126020.post@n5.nabble.com>
	<CAFV75=yMMuCv7Os1zjBo=p51+SOn0wqOF+0-4T33D-nbfPpAiA@mail.gmail.com>
Message-ID: <1325869105.26080.YahooMailNeo@web29806.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 16:58:25 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: -+= Lta =+- <lta@akr.fm>, n4rC0t1C <shandivo@gmail.com>
In-Reply-To: <CAFV75=yMMuCv7Os1zjBo=p51+SOn0wqOF+0-4T33D-nbfPpAiA@mail.gmail.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] 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="===============3726685183355151718=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3726685183355151718==
Content-Type: multipart/alternative; boundary="47836494-918686177-1325869105=:26080"

--47836494-918686177-1325869105=:26080
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Interested too.=0A=0AI did a search on my inbox found nothing even in the i=
ncoming mails you sent=0A=0A=0A=0A________________________________=0A De=A0=
: -+=3D Lta =3D+- <lta@akr.fm>=0A=C0=A0: n4rC0t1C <shandivo@gmail.com> =0AC=
c=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Vendredi 6 Janvier 201=
2 17h51=0AObjet=A0: Re: [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.=
2 unstable=0A =0A=0A=0A=0A=0AOn Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C <shan=
divo@gmail.com> wrote:=0A=0A=0A>-+=3D Lta =3D+- wrote=0A>=0A>>=0A>> Hello,=
=0A>>=0A>> I've just posted on the list my setup of a working win7 domu wit=
h an=0A>> nvidia=0A>> card. You might wanna have a look.=0A>>=0A>> --=0A>> =
Lta=0A>>=0A>> On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &lt;davidtecher@=
&gt; wrote:=0A>>=0A>>=0A>=0A>Sorry, where? Dind't find the post. REALLY int=
erested.=0A>=0A=0A=0AHi,=0A=0A=0AI must have sent him from the wrong addres=
s so the list refused it. I've resent it with the right one, it should be i=
n your inbox somewhere=0A=0ARegards,=0ALta=0A=A0=0A=0A>--=0A>View this mess=
age in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthroug=
h-XEN-4-2-unstable-tp4406265p5126020.html=0A>=0A>Sent from the Xen - Dev ma=
iling list archive at Nabble.com.=0A>=0A>__________________________________=
_____________=0A>Xen-devel mailing list=0A>Xen-devel@lists.xensource.com=0A=
>http://lists.xensource.com/xen-devel=0A>=0A=0A____________________________=
___________________=0AXen-devel mailing list=0AXen-devel@lists.xensource.co=
m=0Ahttp://lists.xensource.com/xen-devel
--47836494-918686177-1325869105=:26080
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>Interested=
 too.</span></div><div><br><span></span></div><div><span>I did a search on =
my inbox found nothing even in the incoming mails you sent<br></span></div>=
<div><br></div>  <div style=3D"font-family: times new roman, new york, time=
s, serif; font-size: 12pt;"> <div style=3D"font-family: times new roman, ne=
w york, times, serif; font-size: 12pt;"> <font size=3D"2" face=3D"Arial"> <=
hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -=
+=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight: bold;"=
>=C0&nbsp;:</span></b> n4rC0t1C &lt;shandivo@gmail.com&gt; <br><b><span sty=
le=3D"font-weight: bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensource.co=
m <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span></b> Vendr=
edi 6 Janvier 2012 17h51<br> <b><span style=3D"font-weight: bold;">Objet&nb=
sp;:</span></b> Re:
 [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.2 unstable<br> </font> =
<br><div id=3D"yiv1978695361"><br><br><div class=3D"yiv1978695361gmail_quot=
e">On Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C <span dir=3D"ltr">&lt;<a rel=3D=
"nofollow" ymailto=3D"mailto:shandivo@gmail.com" target=3D"_blank" href=3D"=
mailto:shandivo@gmail.com">shandivo@gmail.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"yiv1978695361gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex;">=0A<br>=0A-+=3D Lta =3D+- wrote<br=
>=0A<div class=3D"yiv1978695361im">&gt;<br>=0A&gt; Hello,<br>=0A&gt;<br>=0A=
&gt; I've just posted on the list my setup of a working win7 domu with an<b=
r>=0A&gt; nvidia<br>=0A&gt; card. You might wanna have a look.<br>=0A&gt;<b=
r>=0A&gt; --<br>=0A&gt; Lta<br>=0A&gt;<br>=0A</div>&gt; On Fri, Jan 6, 2012=
 at 3:23 PM, David TECHER &amp;lt;davidtecher@&amp;gt; wrote:<br>=0A&gt;<br=
>=0A&gt;<br>=0A<br>=0ASorry, where? Dind't find the post. REALLY interested=
.<br></blockquote><div><br></div><div><br></div><div>Hi,<br><div><br></div>=
<div>I must have sent him from the wrong address so the list refused it. I'=
ve resent it with the right one, it should be in your inbox somewhere</div>=
=0A</div><div><br></div><div>Regards,</div><div>Lta</div><div>&nbsp;</div><=
blockquote class=3D"yiv1978695361gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">=0A<span class=3D"yiv1978695361=
HOEnZb"><font color=3D"#888888"><br>=0A--<br>=0AView this message in contex=
t: <a rel=3D"nofollow" target=3D"_blank" href=3D"http://xen.1045712.n5.nabb=
le.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.html"=
>http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthrough-XEN-4-2-unsta=
ble-tp4406265p5126020.html</a><br>=0A=0A</font></span><div class=3D"yiv1978=
695361HOEnZb"><div class=3D"yiv1978695361h5">Sent from the Xen - Dev mailin=
g list archive at Nabble.com.<br>=0A<br>=0A________________________________=
_______________<br>=0AXen-devel mailing list<br>=0A<a rel=3D"nofollow" ymai=
lto=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mail=
to:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br>=0A<=
a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensource.com/xen=
-devel">http://lists.xensource.com/xen-devel</a><br>=0A</div></div></blockq=
uote></div><br>=0A</div><br>_______________________________________________=
<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-devel@lists.xensourc=
e.com" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensou=
rce.com</a><br><a href=3D"http://lists.xensource.com/xen-devel" target=3D"_=
blank">http://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  =
</div></body></html>
--47836494-918686177-1325869105=:26080--


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

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

--===============3726685183355151718==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:59:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjD8a-0005CJ-Fc; Fri, 06 Jan 2012 16:59:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RjD8Z-0005BB-7y
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:59:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325869161!9966403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17956 invoked from network); 6 Jan 2012 16:59:21 -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;
	6 Jan 2012 16:59:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9869514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 16:59:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 16:59:21 +0000
Date: Fri, 6 Jan 2012 16:59:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <1325867990-15018-1-git-send-email-drjones@redhat.com>
Message-ID: <alpine.DEB.2.00.1201061648440.3150@kaball-desktop>
References: <1325867990-15018-1-git-send-email-drjones@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Andrew Jones wrote:
> XEN_DOM0 is a silent option that has been automatically selected when
> CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed
> to a menu configurable option then it would only give users the ability
> to compile out about 100 kbytes of code.

I think that it is less than that because backends are not tied to dom0
in any way, even though currently they cannot be compiled without
XEN_DOM0.
Running a network or block backend in domU is a well known
configuration.
Therefore the code compiled out only amounts to about 10K.


> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 8795480..0725228 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
>  
>  config XEN_BACKEND
>  	bool "Backend driver support"
> -	depends on XEN_DOM0
>  	default y
> +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
>  	help
>  	  Support for backend device drivers that provide I/O services
>  	  to other virtual machines.

I think we can trimmer the dependency list here: after all backends can
be run in unpriviledged guests as well (see driver domains).
So I think it should depend only on XEN.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 16:59:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 16:59:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjD8a-0005CJ-Fc; Fri, 06 Jan 2012 16:59:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RjD8Z-0005BB-7y
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:59:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1325869161!9966403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17956 invoked from network); 6 Jan 2012 16:59:21 -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;
	6 Jan 2012 16:59:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9869514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 16:59:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 16:59:21 +0000
Date: Fri, 6 Jan 2012 16:59:13 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <1325867990-15018-1-git-send-email-drjones@redhat.com>
Message-ID: <alpine.DEB.2.00.1201061648440.3150@kaball-desktop>
References: <1325867990-15018-1-git-send-email-drjones@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 6 Jan 2012, Andrew Jones wrote:
> XEN_DOM0 is a silent option that has been automatically selected when
> CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was changed
> to a menu configurable option then it would only give users the ability
> to compile out about 100 kbytes of code.

I think that it is less than that because backends are not tied to dom0
in any way, even though currently they cannot be compiled without
XEN_DOM0.
Running a network or block backend in domU is a well known
configuration.
Therefore the code compiled out only amounts to about 10K.


> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 8795480..0725228 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
>  
>  config XEN_BACKEND
>  	bool "Backend driver support"
> -	depends on XEN_DOM0
>  	default y
> +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
>  	help
>  	  Support for backend device drivers that provide I/O services
>  	  to other virtual machines.

I think we can trimmer the dependency list here: after all backends can
be run in unpriviledged guests as well (see driver domains).
So I think it should depend only on XEN.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 17:00:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17: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 1RjD9D-0005Ip-Uc; Fri, 06 Jan 2012 17:00:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjD9B-0005IY-MD
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:00:06 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-7.tower-27.messagelabs.com!1325869142!63249036!1
X-Originating-IP: [77.238.189.196]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,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 14162 invoked from network); 6 Jan 2012 16:59:03 -0000
Received: from nm12-vm0.bullet.mail.ird.yahoo.com (HELO
	nm12-vm0.bullet.mail.ird.yahoo.com) (77.238.189.196)
	by server-7.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 16:59:03 -0000
Received: from [77.238.189.55] by nm12.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:00:02 -0000
Received: from [212.82.108.242] by tm8.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:00:02 -0000
Received: from [127.0.0.1] by omp1007.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:00:02 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 735404.40566.bm@omp1007.mail.ird.yahoo.com
Received: (qmail 62277 invoked by uid 60001); 6 Jan 2012 17:00:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325869202; bh=I5TIsEX9YT+aRNe2N+ty4ILT4jXjoWx2o7iv9bueUH0=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=CAOd3kULwGbZwEmwLs0Vik9fg9lZ7aaf44FsjO85QE0uQVdx7KiLVzIzwVyLrxAeBXrJOIUQYC8MQn425qw12ukBbweqIg0nHEMrPwnlOxcj0AdvMezpUdv0iaVVq3SzeMi7j4Fpl/OgCMrZD5iZEni12Xsh9JReYN3cWOgh1iU=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=Dn5KjNbK4+wq1D44KeYm/m2VqTsTZlxXmWUJGykjFZncwv62SYGndQTUfPOExFFkh88ZOZUyw5kBTH4/V6Fjc8BmhChZkmyiMFI2Dou8GZurlOdjFfKnWUSRRsMHXVDDcuVsqUU6YUMg1QtUjEkBC0XLXSvMYDmTucZnB1x/0kM=;
X-YMail-OSG: G1pYqrEVM1kaTr1uMij2A6UGIHTid6uX_aMXVV98LMJTwZJ
	r2XNidMdQckehOIHpSfSVBp.Am3vHLBniFdmPI3bgUBst.XB_vEApUHStG42
	rB6CLazMwJYSvLZESRvktffTDsmWO7pqilvLYh_5vRYP82QY0C03uRy8udp4
	C3j50WrICtpGlSbCiwtc6hr7_9TlsiQqps1ThYoM92IqLu4Y0HhuEsZ6SmnV
	Dh.z4AVBJQsOHGvQQIxVqSmhWiP0ZWGiiiFo8FHS3h9lmjkz90Ztxoe1Pkum
	lZDi4OGxfbgzudG9NjFTSoF2YekKZ03GteXmTNl3IK6tYgVdKDMn2EHOt3aC
	qb1UmwYknOAN0ZatPZYQ58.2ekcgr1CWpr9.dgp3JZrGFW.QtjhZBaeQG6kb
	IgFi2yYuwVpWC05DRPTGNfOssN9alWDHeZ7KPAbdR1T72j_TyAC3ZzaHd.kO
	9qwXRH7fRl9pZRFKsEctdCNn5_gjNLWxslZGiQ.DnPoXjcALcF.6HQbaMboB
	kEOaQxeJOAC0VEmlGeVmlMOVMJyiivUVy7QmVaPP6IrGUiVIbA3Cre8JQ037
	ZKCIgnJ5RysGqhlocfRU4bblfFJDQ7p909OF_IwbVUXo5LHVDt5AMl10j8QQ
	avym9RlagiTjIrV335TRg4BOjsn0YlnkAJ7npg.fDHitr_ymAm9Dt0qaFgbL
	00.8iHDzYrAX24zFJVi8SqSsXETSDY0KU.g--
Received: from [195.167.237.98] by web29802.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 17:00:02 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
	<1325867688317-5126020.post@n5.nabble.com>
	<CAFV75=yMMuCv7Os1zjBo=p51+SOn0wqOF+0-4T33D-nbfPpAiA@mail.gmail.com>
	<1325869105.26080.YahooMailNeo@web29806.mail.ird.yahoo.com>
Message-ID: <1325869202.35081.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 17:00:02 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: -+= Lta =+- <lta@akr.fm>, n4rC0t1C <shandivo@gmail.com>
In-Reply-To: <1325869105.26080.YahooMailNeo@web29806.mail.ird.yahoo.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] 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="===============2910936294020014349=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2910936294020014349==
Content-Type: multipart/alternative; boundary="478945831-1568258958-1325869202=:35081"

--478945831-1568258958-1325869202=:35081
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry I found it. The title was different.=0A=0AI will have a look=0A=0ATha=
nks=0A=0A=0A=0A________________________________=0A De=A0: David TECHER <dav=
idtecher@yahoo.fr>=0A=C0=A0: -+=3D Lta =3D+- <lta@akr.fm>; n4rC0t1C <shandi=
vo@gmail.com> =0ACc=A0: "xen-devel@lists.xensource.com" <xen-devel@lists.xe=
nsource.com> =0AEnvoy=E9 le : Vendredi 6 Janvier 2012 17h58=0AObjet=A0: Re =
: [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.2 unstable=0A =0A=0AIn=
terested too.=0A=0AI did a search on my inbox found nothing even in the inc=
oming mails you sent=0A=0A=0A=0A________________________________=0A De=A0: =
-+=3D Lta =3D+- <lta@akr.fm>=0A=C0=A0: n4rC0t1C <shandivo@gmail.com> =0ACc=
=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Vendredi 6 Janvier 2012=
 17h51=0AObjet=A0: Re: [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.2=
 unstable=0A =0A=0A=0A=0A=0AOn Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C <shand=
ivo@gmail.com> wrote:=0A=0A=0A>-+=3D Lta =3D+- wrote=0A>=0A>>=0A>> Hello,=
=0A>>=0A>> I've just posted on the list my setup of a working win7 domu wit=
h an=0A>> nvidia=0A>> card. You might wanna have a look.=0A>>=0A>> --=0A>> =
Lta=0A>>=0A>> On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &lt;davidtecher@=
&gt; wrote:=0A>>=0A>>=0A>=0A>Sorry, where? Dind't find the post. REALLY int=
erested.=0A>=0A=0A=0AHi,=0A=0A=0AI must have sent him from the wrong addres=
s so the list refused it. I've resent it with the right one, it should be i=
n your inbox somewhere=0A=0ARegards,=0ALta=0A=A0=0A=0A>--=0A>View this mess=
age in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthroug=
h-XEN-4-2-unstable-tp4406265p5126020.html=0A>=0A>Sent from the Xen - Dev ma=
iling list archive at Nabble.com.=0A>=0A>__________________________________=
_____________=0A>Xen-devel mailing list=0A>Xen-devel@lists.xensource.com=0A=
>http://lists.xensource.com/xen-devel=0A>=0A=0A____________________________=
___________________=0AXen-devel mailing list=0AXen-devel@lists.xensource.co=
m=0Ahttp://lists.xensource.com/xen-devel
--478945831-1568258958-1325869202=:35081
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>Sorry I fo=
und it. The title was different.</span></div><div><br><span></span></div><d=
iv><span>I will have a look</span></div><div><span><br>Thanks<br></span></d=
iv><div><br></div>  <div style=3D"font-family: times new roman, new york, t=
imes, serif; font-size: 12pt;"> <div style=3D"font-family: times new roman,=
 new york, times, serif; font-size: 12pt;"> <font size=3D"2" face=3D"Arial"=
> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b=
> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><span style=3D"font-weig=
ht: bold;">=C0&nbsp;:</span></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt;; n4rC0t=
1C &lt;shandivo@gmail.com&gt; <br><b><span style=3D"font-weight: bold;">Cc&=
nbsp;:</span></b> "xen-devel@lists.xensource.com" &lt;xen-devel@lists.xenso=
urce.com&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span=
></b> Vendredi 6
 Janvier 2012 17h58<br> <b><span style=3D"font-weight: bold;">Objet&nbsp;:<=
/span></b> Re : [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.2 unstab=
le<br> </font> <br><div id=3D"yiv1628736879"><div><div style=3D"color:#000;=
background-color:#fff;font-family:times new roman, new york, times, serif;f=
ont-size:12pt;"><div><span>Interested too.</span></div><div><br><span></spa=
n></div><div><span>I did a search on my inbox found nothing even in the inc=
oming mails you sent<br></span></div><div><br></div>  <div style=3D"font-fa=
mily: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 size=3D"2" face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-wei=
ght:bold;">De&nbsp;:</span></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><=
span style=3D"font-weight:bold;">=C0&nbsp;:</span></b> n4rC0t1C &lt;shandiv=
o@gmail.com&gt; <br><b><span style=3D"font-weight:bold;">Cc&nbsp;:</span></=
b>
 xen-devel@lists.xensource.com <br> <b><span style=3D"font-weight:bold;">En=
voy=E9 le :</span></b> Vendredi 6 Janvier 2012 17h51<br> <b><span style=3D"=
font-weight:bold;">Objet&nbsp;:</span></b> Re:=0A [Xen-devel] Re : Patches =
for VGA-Passthrough XEN 4.2 unstable<br> </font> <br><div id=3D"yiv16287368=
79"><br><br><div class=3D"yiv1628736879gmail_quote">On Fri, Jan 6, 2012 at =
5:34 PM, n4rC0t1C <span dir=3D"ltr">&lt;<a rel=3D"nofollow" ymailto=3D"mail=
to:shandivo@gmail.com" target=3D"_blank" href=3D"mailto:shandivo@gmail.com"=
>shandivo@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"yiv162873=
6879gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">=0A<br>=0A-+=3D Lta =3D+- wrote<br>=0A<div class=3D"yiv16287=
36879im">&gt;<br>=0A&gt; Hello,<br>=0A&gt;<br>=0A&gt; I've just posted on t=
he list my setup of a working win7 domu with an<br>=0A&gt; nvidia<br>=0A&gt=
; card. You might wanna have a look.<br>=0A&gt;<br>=0A&gt; --<br>=0A&gt; Lt=
a<br>=0A&gt;<br>=0A</div>&gt; On Fri, Jan 6, 2012 at 3:23 PM, David TECHER =
&amp;lt;davidtecher@&amp;gt; wrote:<br>=0A&gt;<br>=0A&gt;<br>=0A<br>=0ASorr=
y, where? Dind't find the post. REALLY interested.<br></blockquote><div><br=
></div><div><br></div><div>Hi,<br><div><br></div><div>I must have sent him =
from the wrong address so the list refused it. I've resent it with the righ=
t one, it should be in your inbox somewhere</div>=0A</div><div><br></div><d=
iv>Regards,</div><div>Lta</div><div>&nbsp;</div><blockquote class=3D"yiv162=
8736879gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex;">=0A<span class=3D"yiv1628736879HOEnZb"><font color=3D"#88=
8888"><br>=0A--<br>=0AView this message in context: <a rel=3D"nofollow" tar=
get=3D"_blank" href=3D"http://xen.1045712.n5.nabble.com/Patches-for-VGA-Pas=
sthrough-XEN-4-2-unstable-tp4406265p5126020.html">http://xen.1045712.n5.nab=
ble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.html=
</a><br>=0A=0A</font></span><div class=3D"yiv1628736879HOEnZb"><div class=
=3D"yiv1628736879h5">Sent from the Xen - Dev mailing list archive at Nabble=
.com.<br>=0A<br>=0A_______________________________________________<br>=0AXe=
n-devel mailing list<br>=0A<a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@=
lists.xensource.com" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xenso=
urce.com">Xen-devel@lists.xensource.com</a><br>=0A<a rel=3D"nofollow" targe=
t=3D"_blank" href=3D"http://lists.xensource.com/xen-devel">http://lists.xen=
source.com/xen-devel</a><br>=0A</div></div></blockquote></div><br>=0A</div>=
<br>_______________________________________________<br>Xen-devel mailing li=
st<br><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.xensource.com" =
target=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@l=
ists.xensource.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"htt=
p://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>=
<br><br><br> </div> </div>  </div></div></div><br><br> </div> </div>  </div=
></body></html>
--478945831-1568258958-1325869202=:35081--


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

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

--===============2910936294020014349==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 17:00:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17: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 1RjD9D-0005Ip-Uc; Fri, 06 Jan 2012 17:00:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjD9B-0005IY-MD
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:00:06 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-7.tower-27.messagelabs.com!1325869142!63249036!1
X-Originating-IP: [77.238.189.196]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_60_70,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 14162 invoked from network); 6 Jan 2012 16:59:03 -0000
Received: from nm12-vm0.bullet.mail.ird.yahoo.com (HELO
	nm12-vm0.bullet.mail.ird.yahoo.com) (77.238.189.196)
	by server-7.tower-27.messagelabs.com with SMTP;
	6 Jan 2012 16:59:03 -0000
Received: from [77.238.189.55] by nm12.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:00:02 -0000
Received: from [212.82.108.242] by tm8.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:00:02 -0000
Received: from [127.0.0.1] by omp1007.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:00:02 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 735404.40566.bm@omp1007.mail.ird.yahoo.com
Received: (qmail 62277 invoked by uid 60001); 6 Jan 2012 17:00:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325869202; bh=I5TIsEX9YT+aRNe2N+ty4ILT4jXjoWx2o7iv9bueUH0=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=CAOd3kULwGbZwEmwLs0Vik9fg9lZ7aaf44FsjO85QE0uQVdx7KiLVzIzwVyLrxAeBXrJOIUQYC8MQn425qw12ukBbweqIg0nHEMrPwnlOxcj0AdvMezpUdv0iaVVq3SzeMi7j4Fpl/OgCMrZD5iZEni12Xsh9JReYN3cWOgh1iU=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=Dn5KjNbK4+wq1D44KeYm/m2VqTsTZlxXmWUJGykjFZncwv62SYGndQTUfPOExFFkh88ZOZUyw5kBTH4/V6Fjc8BmhChZkmyiMFI2Dou8GZurlOdjFfKnWUSRRsMHXVDDcuVsqUU6YUMg1QtUjEkBC0XLXSvMYDmTucZnB1x/0kM=;
X-YMail-OSG: G1pYqrEVM1kaTr1uMij2A6UGIHTid6uX_aMXVV98LMJTwZJ
	r2XNidMdQckehOIHpSfSVBp.Am3vHLBniFdmPI3bgUBst.XB_vEApUHStG42
	rB6CLazMwJYSvLZESRvktffTDsmWO7pqilvLYh_5vRYP82QY0C03uRy8udp4
	C3j50WrICtpGlSbCiwtc6hr7_9TlsiQqps1ThYoM92IqLu4Y0HhuEsZ6SmnV
	Dh.z4AVBJQsOHGvQQIxVqSmhWiP0ZWGiiiFo8FHS3h9lmjkz90Ztxoe1Pkum
	lZDi4OGxfbgzudG9NjFTSoF2YekKZ03GteXmTNl3IK6tYgVdKDMn2EHOt3aC
	qb1UmwYknOAN0ZatPZYQ58.2ekcgr1CWpr9.dgp3JZrGFW.QtjhZBaeQG6kb
	IgFi2yYuwVpWC05DRPTGNfOssN9alWDHeZ7KPAbdR1T72j_TyAC3ZzaHd.kO
	9qwXRH7fRl9pZRFKsEctdCNn5_gjNLWxslZGiQ.DnPoXjcALcF.6HQbaMboB
	kEOaQxeJOAC0VEmlGeVmlMOVMJyiivUVy7QmVaPP6IrGUiVIbA3Cre8JQ037
	ZKCIgnJ5RysGqhlocfRU4bblfFJDQ7p909OF_IwbVUXo5LHVDt5AMl10j8QQ
	avym9RlagiTjIrV335TRg4BOjsn0YlnkAJ7npg.fDHitr_ymAm9Dt0qaFgbL
	00.8iHDzYrAX24zFJVi8SqSsXETSDY0KU.g--
Received: from [195.167.237.98] by web29802.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 17:00:02 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <6FD49434405AF34C876B114E4733B967EAE633@AMSPRD0202MB101.eurprd02.prod.outlook.com>
	<CAPE0SYyVpndVoSWoicMJ5VYy1UrFb7-MnTBmPFbuMHeaEdJXNw@mail.gmail.com>
	<1325805329088-5124160.post@n5.nabble.com>
	<1325812394368-5124377.post@n5.nabble.com>
	<1325859795.74578.YahooMailNeo@web29804.mail.ird.yahoo.com>
	<CAFV75=yMpdZsHXtvZGKstKdDa3iUDajk4_=1-LNTE1dZWM47Cg@mail.gmail.com>
	<1325867688317-5126020.post@n5.nabble.com>
	<CAFV75=yMMuCv7Os1zjBo=p51+SOn0wqOF+0-4T33D-nbfPpAiA@mail.gmail.com>
	<1325869105.26080.YahooMailNeo@web29806.mail.ird.yahoo.com>
Message-ID: <1325869202.35081.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 17:00:02 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: -+= Lta =+- <lta@akr.fm>, n4rC0t1C <shandivo@gmail.com>
In-Reply-To: <1325869105.26080.YahooMailNeo@web29806.mail.ird.yahoo.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] 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="===============2910936294020014349=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2910936294020014349==
Content-Type: multipart/alternative; boundary="478945831-1568258958-1325869202=:35081"

--478945831-1568258958-1325869202=:35081
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry I found it. The title was different.=0A=0AI will have a look=0A=0ATha=
nks=0A=0A=0A=0A________________________________=0A De=A0: David TECHER <dav=
idtecher@yahoo.fr>=0A=C0=A0: -+=3D Lta =3D+- <lta@akr.fm>; n4rC0t1C <shandi=
vo@gmail.com> =0ACc=A0: "xen-devel@lists.xensource.com" <xen-devel@lists.xe=
nsource.com> =0AEnvoy=E9 le : Vendredi 6 Janvier 2012 17h58=0AObjet=A0: Re =
: [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.2 unstable=0A =0A=0AIn=
terested too.=0A=0AI did a search on my inbox found nothing even in the inc=
oming mails you sent=0A=0A=0A=0A________________________________=0A De=A0: =
-+=3D Lta =3D+- <lta@akr.fm>=0A=C0=A0: n4rC0t1C <shandivo@gmail.com> =0ACc=
=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Vendredi 6 Janvier 2012=
 17h51=0AObjet=A0: Re: [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.2=
 unstable=0A =0A=0A=0A=0A=0AOn Fri, Jan 6, 2012 at 5:34 PM, n4rC0t1C <shand=
ivo@gmail.com> wrote:=0A=0A=0A>-+=3D Lta =3D+- wrote=0A>=0A>>=0A>> Hello,=
=0A>>=0A>> I've just posted on the list my setup of a working win7 domu wit=
h an=0A>> nvidia=0A>> card. You might wanna have a look.=0A>>=0A>> --=0A>> =
Lta=0A>>=0A>> On Fri, Jan 6, 2012 at 3:23 PM, David TECHER &lt;davidtecher@=
&gt; wrote:=0A>>=0A>>=0A>=0A>Sorry, where? Dind't find the post. REALLY int=
erested.=0A>=0A=0A=0AHi,=0A=0A=0AI must have sent him from the wrong addres=
s so the list refused it. I've resent it with the right one, it should be i=
n your inbox somewhere=0A=0ARegards,=0ALta=0A=A0=0A=0A>--=0A>View this mess=
age in context: http://xen.1045712.n5.nabble.com/Patches-for-VGA-Passthroug=
h-XEN-4-2-unstable-tp4406265p5126020.html=0A>=0A>Sent from the Xen - Dev ma=
iling list archive at Nabble.com.=0A>=0A>__________________________________=
_____________=0A>Xen-devel mailing list=0A>Xen-devel@lists.xensource.com=0A=
>http://lists.xensource.com/xen-devel=0A>=0A=0A____________________________=
___________________=0AXen-devel mailing list=0AXen-devel@lists.xensource.co=
m=0Ahttp://lists.xensource.com/xen-devel
--478945831-1568258958-1325869202=:35081
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>Sorry I fo=
und it. The title was different.</span></div><div><br><span></span></div><d=
iv><span>I will have a look</span></div><div><span><br>Thanks<br></span></d=
iv><div><br></div>  <div style=3D"font-family: times new roman, new york, t=
imes, serif; font-size: 12pt;"> <div style=3D"font-family: times new roman,=
 new york, times, serif; font-size: 12pt;"> <font size=3D"2" face=3D"Arial"=
> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b=
> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><span style=3D"font-weig=
ht: bold;">=C0&nbsp;:</span></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt;; n4rC0t=
1C &lt;shandivo@gmail.com&gt; <br><b><span style=3D"font-weight: bold;">Cc&=
nbsp;:</span></b> "xen-devel@lists.xensource.com" &lt;xen-devel@lists.xenso=
urce.com&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span=
></b> Vendredi 6
 Janvier 2012 17h58<br> <b><span style=3D"font-weight: bold;">Objet&nbsp;:<=
/span></b> Re : [Xen-devel] Re : Patches for VGA-Passthrough XEN 4.2 unstab=
le<br> </font> <br><div id=3D"yiv1628736879"><div><div style=3D"color:#000;=
background-color:#fff;font-family:times new roman, new york, times, serif;f=
ont-size:12pt;"><div><span>Interested too.</span></div><div><br><span></spa=
n></div><div><span>I did a search on my inbox found nothing even in the inc=
oming mails you sent<br></span></div><div><br></div>  <div style=3D"font-fa=
mily: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 size=3D"2" face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-wei=
ght:bold;">De&nbsp;:</span></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><=
span style=3D"font-weight:bold;">=C0&nbsp;:</span></b> n4rC0t1C &lt;shandiv=
o@gmail.com&gt; <br><b><span style=3D"font-weight:bold;">Cc&nbsp;:</span></=
b>
 xen-devel@lists.xensource.com <br> <b><span style=3D"font-weight:bold;">En=
voy=E9 le :</span></b> Vendredi 6 Janvier 2012 17h51<br> <b><span style=3D"=
font-weight:bold;">Objet&nbsp;:</span></b> Re:=0A [Xen-devel] Re : Patches =
for VGA-Passthrough XEN 4.2 unstable<br> </font> <br><div id=3D"yiv16287368=
79"><br><br><div class=3D"yiv1628736879gmail_quote">On Fri, Jan 6, 2012 at =
5:34 PM, n4rC0t1C <span dir=3D"ltr">&lt;<a rel=3D"nofollow" ymailto=3D"mail=
to:shandivo@gmail.com" target=3D"_blank" href=3D"mailto:shandivo@gmail.com"=
>shandivo@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"yiv162873=
6879gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">=0A<br>=0A-+=3D Lta =3D+- wrote<br>=0A<div class=3D"yiv16287=
36879im">&gt;<br>=0A&gt; Hello,<br>=0A&gt;<br>=0A&gt; I've just posted on t=
he list my setup of a working win7 domu with an<br>=0A&gt; nvidia<br>=0A&gt=
; card. You might wanna have a look.<br>=0A&gt;<br>=0A&gt; --<br>=0A&gt; Lt=
a<br>=0A&gt;<br>=0A</div>&gt; On Fri, Jan 6, 2012 at 3:23 PM, David TECHER =
&amp;lt;davidtecher@&amp;gt; wrote:<br>=0A&gt;<br>=0A&gt;<br>=0A<br>=0ASorr=
y, where? Dind't find the post. REALLY interested.<br></blockquote><div><br=
></div><div><br></div><div>Hi,<br><div><br></div><div>I must have sent him =
from the wrong address so the list refused it. I've resent it with the righ=
t one, it should be in your inbox somewhere</div>=0A</div><div><br></div><d=
iv>Regards,</div><div>Lta</div><div>&nbsp;</div><blockquote class=3D"yiv162=
8736879gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex;">=0A<span class=3D"yiv1628736879HOEnZb"><font color=3D"#88=
8888"><br>=0A--<br>=0AView this message in context: <a rel=3D"nofollow" tar=
get=3D"_blank" href=3D"http://xen.1045712.n5.nabble.com/Patches-for-VGA-Pas=
sthrough-XEN-4-2-unstable-tp4406265p5126020.html">http://xen.1045712.n5.nab=
ble.com/Patches-for-VGA-Passthrough-XEN-4-2-unstable-tp4406265p5126020.html=
</a><br>=0A=0A</font></span><div class=3D"yiv1628736879HOEnZb"><div class=
=3D"yiv1628736879h5">Sent from the Xen - Dev mailing list archive at Nabble=
.com.<br>=0A<br>=0A_______________________________________________<br>=0AXe=
n-devel mailing list<br>=0A<a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@=
lists.xensource.com" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xenso=
urce.com">Xen-devel@lists.xensource.com</a><br>=0A<a rel=3D"nofollow" targe=
t=3D"_blank" href=3D"http://lists.xensource.com/xen-devel">http://lists.xen=
source.com/xen-devel</a><br>=0A</div></div></blockquote></div><br>=0A</div>=
<br>_______________________________________________<br>Xen-devel mailing li=
st<br><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.xensource.com" =
target=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@l=
ists.xensource.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"htt=
p://lists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a>=
<br><br><br> </div> </div>  </div></div></div><br><br> </div> </div>  </div=
></body></html>
--478945831-1568258958-1325869202=:35081--


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

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

--===============2910936294020014349==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 17:02:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17: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 1RjDBm-0005lM-Ez; Fri, 06 Jan 2012 17:02:46 +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 1RjDBk-0005kD-Dp
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:02:44 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325869357!10774273!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 6879 invoked from network); 6 Jan 2012 17:02:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Jan 2012 17:02:38 -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 1RjDBc-0007fF-JI
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:02:36 -0800
Date: Fri, 6 Jan 2012 09:02:36 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325869356591-5126105.post@n5.nabble.com>
In-Reply-To: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
References: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Secondary VGA Passthrough, nvidia,
	win7: success report.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


-+= Lta =+- wrote
> 
> Hello xen-devel,
> 
> 
> This is my first post on this list and as such i might be breaking some
> explicit/implicit rules and i apologize if it's the case. Maybe this list
> isn't the exact right kind of place where to post this kind of stuff, but
> i
> know lots of us are browsing this list as the primary source of
> documentation for xen.
> 
> I've read many times windows 7 isn't the right os to run on top of xen.
> Most of the guy's who are running vga passthru are recommanding to use
> windows xp, and i've never seen any success report of vga passthru on
> windows 7 so i thought it was important to post mine.
> 
> Anyway, here's my hardware setup :
> - Gigabyte GA-990X-UD3
> - AMD Phenom II X6 1075T Processor
> - MSI Cyclone NVIDIA Geforce GTX 460
> 
> On the software side i'm using :
> 
> - Debian testing as Dom0
> - Xen-4.1 (debian version 4.1.2-2) with what's now referred to as "Tobias
> Geiger patches" (
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html)
> (You have to edit the patches, changing the path to some qemu source files
> for them to apply)
> - debian's kernel  3.1.5, compiled to include the pciback driver. Here's
> the output of `cat /boot/my3.1.5config | grep -i xen`
> CONFIG_XEN=y
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=128
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> # CONFIG_XEN_DEBUG is not set
> CONFIG_PCI_XEN=y
> CONFIG_XEN_PCIDEV_FRONTEND=m
> CONFIG_XEN_BLKDEV_FRONTEND=m
> CONFIG_XEN_BLKDEV_BACKEND=m
> CONFIG_NETXEN_NIC=m
> CONFIG_XEN_NETDEV_FRONTEND=m
> CONFIG_XEN_NETDEV_BACKEND=m
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> CONFIG_HVC_XEN=y
> CONFIG_XEN_WDT=m
> CONFIG_XEN_FBDEV_FRONTEND=y
> # Xen driver support
> CONFIG_XEN_BALLOON=y
> # CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
> CONFIG_XEN_SCRUB_PAGES=y
> CONFIG_XEN_DEV_EVTCHN=m
> CONFIG_XEN_BACKEND=y
> CONFIG_XENFS=m
> CONFIG_XEN_COMPAT_XENFS=y
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=m
> CONFIG_XEN_GRANT_DEV_ALLOC=m
> CONFIG_XEN_PLATFORM_PCI=m
> CONFIG_SWIOTLB_XEN=y
> CONFIG_XEN_PCIDEV_BACKEND=y
> 
> The kernel boot options are 'nomodeset xen-pciback.passthrough=1
> xen-pciback.hide=(01:00.0)(01:00.1)'
> 
> - Here's my win7 domU config file :
> 
> kernel = "/usr/lib/xen-4.1/boot/hvmloader"
> builder='hvm'
> memory = 3072
> name = "w7"
> vif = [ 'type=netfront,bridge=xenbr0, mac=00:16:3e:35:49:62']
> disk = [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']
> device_model = '/usr/lib/xen-4.1/bin/qemu-dm'
> boot="dc"
> 
> pci=['01:00.0','01:00.1']
> gfx_passthru=1
> 
> vcpus=6
> acpi=1
> sdl=0
> vnc=1
> vncconsole=1
> vncpasswd=''
> serial='pty'
> usbdevice='tablet'
> pae=1
> pci_msitranslate=0
> pci_power_mgmt=0
> acpi_s3 = 1
> acpi_s4 = 1
> on_poweroff = 'destroy'
> on_reboot   = 'restart'
> on_crash    = 'restart'
> xen_platform_pci=1
> hpet = 1
> viridian=1
> monitor=1
> xen_extended_power_mgmt=2
> hpet=1
> 
> What's important here for the Nvidia drivers to work and not give a nice
> nvlddmkm.sys BSOD is:
> pci_msitranslate=0
> pci_power_mgmt=0
> 
> - Windows 7 32bits
> - Nvidia drivers 275.33
> - You have to manually run aero speed test or force aero to start by using
> registry entries for the desktop not to be laggy
> 
> The windows 7 domU is running fine with no performance decrease
> noticeable,
> although i've not yet played intensive gpu video game, i'm still pretty
> confident they'll run fine.
> 
> Anyway. i've still some problems i shall report in separate posts :
> - The PCI bus topology isn't preserved, and the gfx card, which is plugged
> on 01:00 becomes 05:00 on domU.
> - I'm passing through an RME Hdsp / hammerfall pci sound card to the domU
> and while it is working fine on his own, there's a strange interaction
> between it and the GPLPV network driver. When i start playing sound, the
> network instantly cease working. It starts back as soon as i stop playing
> audio.
> 
> That's all folks,
> 
> Cheers,
> Lta
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xensource
> http://lists.xensource.com/xen-devel
> 

You could be my HERO of the day. 
However I have to wait monday to confirm that this works on my setup too,
since I'm not at home.

Maybe you just saved me from buying an ATI card. I'll let you know asap.
THANKS


--
View this message in context: http://xen.1045712.n5.nabble.com/Secondary-VGA-Passthrough-nvidia-win7-success-report-tp5126062p5126105.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 Jan 06 17:02:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17: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 1RjDBm-0005lM-Ez; Fri, 06 Jan 2012 17:02:46 +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 1RjDBk-0005kD-Dp
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:02:44 +0000
X-Env-Sender: shandivo@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1325869357!10774273!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 6879 invoked from network); 6 Jan 2012 17:02:38 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-8.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	6 Jan 2012 17:02:38 -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 1RjDBc-0007fF-JI
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 09:02:36 -0800
Date: Fri, 6 Jan 2012 09:02:36 -0800 (PST)
From: n4rC0t1C <shandivo@gmail.com>
To: xen-devel@lists.xensource.com
Message-ID: <1325869356591-5126105.post@n5.nabble.com>
In-Reply-To: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
References: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Secondary VGA Passthrough, nvidia,
	win7: success report.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


-+= Lta =+- wrote
> 
> Hello xen-devel,
> 
> 
> This is my first post on this list and as such i might be breaking some
> explicit/implicit rules and i apologize if it's the case. Maybe this list
> isn't the exact right kind of place where to post this kind of stuff, but
> i
> know lots of us are browsing this list as the primary source of
> documentation for xen.
> 
> I've read many times windows 7 isn't the right os to run on top of xen.
> Most of the guy's who are running vga passthru are recommanding to use
> windows xp, and i've never seen any success report of vga passthru on
> windows 7 so i thought it was important to post mine.
> 
> Anyway, here's my hardware setup :
> - Gigabyte GA-990X-UD3
> - AMD Phenom II X6 1075T Processor
> - MSI Cyclone NVIDIA Geforce GTX 460
> 
> On the software side i'm using :
> 
> - Debian testing as Dom0
> - Xen-4.1 (debian version 4.1.2-2) with what's now referred to as "Tobias
> Geiger patches" (
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html)
> (You have to edit the patches, changing the path to some qemu source files
> for them to apply)
> - debian's kernel  3.1.5, compiled to include the pciback driver. Here's
> the output of `cat /boot/my3.1.5config | grep -i xen`
> CONFIG_XEN=y
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> CONFIG_XEN_PVHVM=y
> CONFIG_XEN_MAX_DOMAIN_MEMORY=128
> CONFIG_XEN_SAVE_RESTORE=y
> # CONFIG_XEN_DEBUG_FS is not set
> # CONFIG_XEN_DEBUG is not set
> CONFIG_PCI_XEN=y
> CONFIG_XEN_PCIDEV_FRONTEND=m
> CONFIG_XEN_BLKDEV_FRONTEND=m
> CONFIG_XEN_BLKDEV_BACKEND=m
> CONFIG_NETXEN_NIC=m
> CONFIG_XEN_NETDEV_FRONTEND=m
> CONFIG_XEN_NETDEV_BACKEND=m
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
> CONFIG_HVC_XEN=y
> CONFIG_XEN_WDT=m
> CONFIG_XEN_FBDEV_FRONTEND=y
> # Xen driver support
> CONFIG_XEN_BALLOON=y
> # CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
> CONFIG_XEN_SCRUB_PAGES=y
> CONFIG_XEN_DEV_EVTCHN=m
> CONFIG_XEN_BACKEND=y
> CONFIG_XENFS=m
> CONFIG_XEN_COMPAT_XENFS=y
> CONFIG_XEN_SYS_HYPERVISOR=y
> CONFIG_XEN_XENBUS_FRONTEND=y
> CONFIG_XEN_GNTDEV=m
> CONFIG_XEN_GRANT_DEV_ALLOC=m
> CONFIG_XEN_PLATFORM_PCI=m
> CONFIG_SWIOTLB_XEN=y
> CONFIG_XEN_PCIDEV_BACKEND=y
> 
> The kernel boot options are 'nomodeset xen-pciback.passthrough=1
> xen-pciback.hide=(01:00.0)(01:00.1)'
> 
> - Here's my win7 domU config file :
> 
> kernel = "/usr/lib/xen-4.1/boot/hvmloader"
> builder='hvm'
> memory = 3072
> name = "w7"
> vif = [ 'type=netfront,bridge=xenbr0, mac=00:16:3e:35:49:62']
> disk = [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']
> device_model = '/usr/lib/xen-4.1/bin/qemu-dm'
> boot="dc"
> 
> pci=['01:00.0','01:00.1']
> gfx_passthru=1
> 
> vcpus=6
> acpi=1
> sdl=0
> vnc=1
> vncconsole=1
> vncpasswd=''
> serial='pty'
> usbdevice='tablet'
> pae=1
> pci_msitranslate=0
> pci_power_mgmt=0
> acpi_s3 = 1
> acpi_s4 = 1
> on_poweroff = 'destroy'
> on_reboot   = 'restart'
> on_crash    = 'restart'
> xen_platform_pci=1
> hpet = 1
> viridian=1
> monitor=1
> xen_extended_power_mgmt=2
> hpet=1
> 
> What's important here for the Nvidia drivers to work and not give a nice
> nvlddmkm.sys BSOD is:
> pci_msitranslate=0
> pci_power_mgmt=0
> 
> - Windows 7 32bits
> - Nvidia drivers 275.33
> - You have to manually run aero speed test or force aero to start by using
> registry entries for the desktop not to be laggy
> 
> The windows 7 domU is running fine with no performance decrease
> noticeable,
> although i've not yet played intensive gpu video game, i'm still pretty
> confident they'll run fine.
> 
> Anyway. i've still some problems i shall report in separate posts :
> - The PCI bus topology isn't preserved, and the gfx card, which is plugged
> on 01:00 becomes 05:00 on domU.
> - I'm passing through an RME Hdsp / hammerfall pci sound card to the domU
> and while it is working fine on his own, there's a strange interaction
> between it and the GPLPV network driver. When i start playing sound, the
> network instantly cease working. It starts back as soon as i stop playing
> audio.
> 
> That's all folks,
> 
> Cheers,
> Lta
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@.xensource
> http://lists.xensource.com/xen-devel
> 

You could be my HERO of the day. 
However I have to wait monday to confirm that this works on my setup too,
since I'm not at home.

Maybe you just saved me from buying an ATI card. I'll let you know asap.
THANKS


--
View this message in context: http://xen.1045712.n5.nabble.com/Secondary-VGA-Passthrough-nvidia-win7-success-report-tp5126062p5126105.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 Jan 06 17:07:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17: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 1RjDFp-0006Lm-SA; Fri, 06 Jan 2012 17:06:57 +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 1RjDFn-0006KN-Ug
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:06:56 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325869609!9872181!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5ODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29404 invoked from network); 6 Jan 2012 17:06:50 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 17:06:50 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 2D21011FD;
	Fri,  6 Jan 2012 19:06:48 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1240A20058; Fri,  6 Jan 2012 19:06:48 +0200 (EET)
Date: Fri, 6 Jan 2012 19:06:48 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: -+= Lta =+- <lta@akr.fm>
Message-ID: <20120106170648.GB12984@reaktio.net>
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Secondary VGA Passthrough, nvidia,
	win7: success	report.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 05:48:06PM +0100, -+= Lta =+- wrote:
>    Hello xen-devel,

Hello,

>    This is my first post on this list and as such i might be breaking some
>    explicit/implicit rules and i apologize if it's the case. Maybe this list
>    isn't the exact right kind of place where to post this kind of stuff, but
>    i know lots of us are browsing this list as the primary source of
>    documentation for xen.
>    I've read many times windows 7 isn't the right os to run on top of xen.
>    Most of the guy's who are running vga passthru are recommanding to use
>    windows xp, and i've never seen any success report of vga passthru on
>    windows 7 so i thought it was important to post mine.

Thanks for the post! I'm sure it helps many people trying out this stuff.


>    The kernel boot options are 'nomodeset xen-pciback.passthrough=1
>    xen-pciback.hide=(01:00.0)(01:00.1)'
>    - Here's my win7 domU config file :
>    kernel = "/usr/lib/xen-4.1/boot/hvmloader"
>    builder='hvm'
>    memory = 3072
>    name = "w7"
>    vif = [ 'type=netfront,bridge=xenbr0, mac=00:16:3e:35:49:62']
>    disk = [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']
>    device_model = '/usr/lib/xen-4.1/bin/qemu-dm'
>    boot="dc"
>    pci=['01:00.0','01:00.1']
>    gfx_passthru=1


Just a note that "gfx_passthru=1" makes the passthru physical graphics adapter
become *primary* in the guest VM.. the subject of the email says "secondary", 
so I wanted to clarify that :)


>    pci_msitranslate=0
>    pci_power_mgmt=0

So these are the required 'magic' options.. 

>    acpi_s3 = 1
>    acpi_s4 = 1
>    on_poweroff = 'destroy'
>    on_reboot   = 'restart'
>    on_crash    = 'restart'
>    xen_platform_pci=1
>    hpet = 1
>    viridian=1
>    monitor=1
>    xen_extended_power_mgmt=2

I wonder if this is important aswell.. 


>    hpet=1

It seems you have hpet two times :) 


>    What's important here for the Nvidia drivers to work and not give a nice
>    nvlddmkm.sys BSOD is:
>    pci_msitranslate=0
>    pci_power_mgmt=0
>    - Windows 7 32bits
>    - Nvidia drivers 275.33
>    - You have to manually run aero speed test or force aero to start by using
>    registry entries for the desktop not to be laggy
>    The windows 7 domU is running fine with no performance decrease
>    noticeable, although i've not yet played intensive gpu video game, i'm
>    still pretty confident they'll run fine.

>    Anyway. i've still some problems i shall report in separate posts :
>    - The PCI bus topology isn't preserved, and the gfx card, which is plugged
>    on 01:00 becomes 05:00 on domU.


Hmm.. I wonder why "xen-pciback.passthrough=1" doesn't work.. 


>    - I'm passing through an RME Hdsp / hammerfall pci sound card to the domU
>    and while it is working fine on his own, there's a strange interaction
>    between it and the GPLPV network driver. When i start playing sound, the
>    network instantly cease working. It starts back as soon as i stop playing
>    audio.
>    That's all folks,
>    Cheers,
>    Lta
> 

Thanks! 

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 17:07:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17: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 1RjDFp-0006Lm-SA; Fri, 06 Jan 2012 17:06:57 +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 1RjDFn-0006KN-Ug
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:06:56 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325869609!9872181!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTg5ODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29404 invoked from network); 6 Jan 2012 17:06:50 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 6 Jan 2012 17:06:50 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 2D21011FD;
	Fri,  6 Jan 2012 19:06:48 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 1240A20058; Fri,  6 Jan 2012 19:06:48 +0200 (EET)
Date: Fri, 6 Jan 2012 19:06:48 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: -+= Lta =+- <lta@akr.fm>
Message-ID: <20120106170648.GB12984@reaktio.net>
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Secondary VGA Passthrough, nvidia,
	win7: success	report.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 05:48:06PM +0100, -+= Lta =+- wrote:
>    Hello xen-devel,

Hello,

>    This is my first post on this list and as such i might be breaking some
>    explicit/implicit rules and i apologize if it's the case. Maybe this list
>    isn't the exact right kind of place where to post this kind of stuff, but
>    i know lots of us are browsing this list as the primary source of
>    documentation for xen.
>    I've read many times windows 7 isn't the right os to run on top of xen.
>    Most of the guy's who are running vga passthru are recommanding to use
>    windows xp, and i've never seen any success report of vga passthru on
>    windows 7 so i thought it was important to post mine.

Thanks for the post! I'm sure it helps many people trying out this stuff.


>    The kernel boot options are 'nomodeset xen-pciback.passthrough=1
>    xen-pciback.hide=(01:00.0)(01:00.1)'
>    - Here's my win7 domU config file :
>    kernel = "/usr/lib/xen-4.1/boot/hvmloader"
>    builder='hvm'
>    memory = 3072
>    name = "w7"
>    vif = [ 'type=netfront,bridge=xenbr0, mac=00:16:3e:35:49:62']
>    disk = [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']
>    device_model = '/usr/lib/xen-4.1/bin/qemu-dm'
>    boot="dc"
>    pci=['01:00.0','01:00.1']
>    gfx_passthru=1


Just a note that "gfx_passthru=1" makes the passthru physical graphics adapter
become *primary* in the guest VM.. the subject of the email says "secondary", 
so I wanted to clarify that :)


>    pci_msitranslate=0
>    pci_power_mgmt=0

So these are the required 'magic' options.. 

>    acpi_s3 = 1
>    acpi_s4 = 1
>    on_poweroff = 'destroy'
>    on_reboot   = 'restart'
>    on_crash    = 'restart'
>    xen_platform_pci=1
>    hpet = 1
>    viridian=1
>    monitor=1
>    xen_extended_power_mgmt=2

I wonder if this is important aswell.. 


>    hpet=1

It seems you have hpet two times :) 


>    What's important here for the Nvidia drivers to work and not give a nice
>    nvlddmkm.sys BSOD is:
>    pci_msitranslate=0
>    pci_power_mgmt=0
>    - Windows 7 32bits
>    - Nvidia drivers 275.33
>    - You have to manually run aero speed test or force aero to start by using
>    registry entries for the desktop not to be laggy
>    The windows 7 domU is running fine with no performance decrease
>    noticeable, although i've not yet played intensive gpu video game, i'm
>    still pretty confident they'll run fine.

>    Anyway. i've still some problems i shall report in separate posts :
>    - The PCI bus topology isn't preserved, and the gfx card, which is plugged
>    on 01:00 becomes 05:00 on domU.


Hmm.. I wonder why "xen-pciback.passthrough=1" doesn't work.. 


>    - I'm passing through an RME Hdsp / hammerfall pci sound card to the domU
>    and while it is working fine on his own, there's a strange interaction
>    between it and the GPLPV network driver. When i start playing sound, the
>    network instantly cease working. It starts back as soon as i stop playing
>    audio.
>    That's all folks,
>    Cheers,
>    Lta
> 

Thanks! 

-- Pasi


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 17:07:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjDGc-0006Tv-9d; Fri, 06 Jan 2012 17:07:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjDGb-0006T6-IC
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:07:46 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325869658!9863720!1
X-Originating-IP: [77.238.189.214]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,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 28255 invoked from network); 6 Jan 2012 17:07:38 -0000
Received: from nm17-vm0.bullet.mail.ird.yahoo.com (HELO
	nm17-vm0.bullet.mail.ird.yahoo.com) (77.238.189.214)
	by server-14.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 17:07:38 -0000
Received: from [77.238.189.233] by nm17.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:07:38 -0000
Received: from [212.82.108.121] by tm14.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:07:37 -0000
Received: from [127.0.0.1] by omp1030.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:07:37 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 890057.47618.bm@omp1030.mail.ird.yahoo.com
Received: (qmail 29644 invoked by uid 60001); 6 Jan 2012 17:07:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325869657; bh=NPSOUb9z8nYML51IAwr8OUIB3grd4CTaUVAykPutUrc=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=wXDyoVxhIXcx35NWUkjfLClx0kzrAhFuJms7esKedJvnfAe/SqehXpFRrOM2XeyTceHoP+Lqu8goBDVXlG3ax7wPVmBtXBa/bTAyLoUPdmvweKj1oru5z61Ls74f5kkYrAcx/7kOCPqIs0aUBtOoFBA4fIhW3ECJDrG0S9H/jOc=
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=e6lut1fEjQ0Yn5VgJca8RPTg+u7zL75YTu+nfZ+MfhNVBWGsAx+ISoevD3Lc2tX6w6CyFiolaV23LScSStHQABtUarzIR16Izwnai2+HBH47l24Cl3TH0/yXxyZoKLjxJ/S6BDnikLl3bS5HAmQzNwDWoLbnJu8x+WW9tbaqhDM=;
X-YMail-OSG: 93g2WN0VM1leHEYZS.PyFXJrxe5ZDEgHNNvhKT_OFoHz6uw
	.MA0U5NrItl2p1CXkSEE8_K9QtwErNKhdPVj6jk8IwTC_hjxcKnLteQjUU8W
	yUjSsaC.r.J5fXOJNeFDSfpTeCEFuNRGG12EqW0lRvNNuegOkzvBafLCy2T7
	cb7FFFvIwOeKgAF1jUpqvA8VGHDYth8GpACi2s7YALA6GMA0kfdWFKbUWa90
	vs9CrI6qj76WwfHPdixy6d4xslVl.FVWHV_vmjdU6VbBcAVFv7ai6CVPVJ.l
	9Mmn1XMGABqOwsQ5DiYh7q4he96PgikMByDTTOyK1YKW0MbA5EkRKUSaXkz4
	TRX9hwZula6ifoWY5OGA5nHUvcClbl.B_pDL5QNUapz5jQ81kFbojX9AOsiW
	wwxnrjt4m141qcQrHb0pohQf0d7Yfd2vYeTzX4FgYdX1bMNyOc1aSTJISc7f
	ZX2mJjg6tbH_DKbBRvuKo1fC.tYGt_4obvEuiHppivoF8rkWijRxMITrxrC1
	RPgwt.Nx03NOETklruWdDAaQUenAYU5KPuddpRKdjdWp.EP7jEUNtl5NychV
	cLccxkVUmPNO3fZXlkTf2lzkaE7VYlj9WC9R4mnS6gaDU5SQLoo_XmIhZlSk
	z7Wqa8N1wA9U.udaqn.oJTJtobl1RbJ7058G2FviQMDrSJElORBD1qhFWocQ
	MyxXuc.taa41BgtkK01yyJhbQpKChrjuAMWh.UzZF6ybojhQADBE7HOcrjVF
	NrE.B1Ggo_1iDeua0rk08pqwG7mG71b5rOO.wCXufL6w1MXvp3DdBYsgS5SV
	hOnyFxDJtqGfItaTB3OFAchq1urByW6XM_17k__eZkV6Hafh0dBY-
Received: from [195.167.237.98] by web29805.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 17:07:37 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325869356591-5126105.post@n5.nabble.com>
Message-ID: <1325869657.29172.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 17:07:37 +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: <1325869356591-5126105.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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="===============3167108891165893783=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3167108891165893783==
Content-Type: multipart/alternative; boundary="62747910-1077758145-1325869657=:29172"

--62747910-1077758145-1325869657=:29172
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I am going to test it in a couple hours when I am back to home.=0A=0AIf it =
works with xen 4.2, it should be very very interesting :)=0A=0AI will let y=
ou know.=0A=0A=0A=0A________________________________=0A De=A0: n4rC0t1C <sh=
andivo@gmail.com>=0A=C0=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : =
Vendredi 6 Janvier 2012 18h02=0AObjet=A0: Re: [Xen-devel] Secondary VGA Pas=
sthrough, nvidia, win7: success report.=0A =0A=0A-+=3D Lta =3D+- wrote=0A> =
=0A> Hello xen-devel,=0A> =0A> =0A> This is my first post on this list and =
as such i might be breaking some=0A> explicit/implicit rules and i apologiz=
e if it's the case. Maybe this list=0A> isn't the exact right kind of place=
 where to post this kind of stuff, but=0A> i=0A> know lots of us are browsi=
ng this list as the primary source of=0A> documentation for xen.=0A> =0A> I=
've read many times windows 7 isn't the right os to run on top of xen.=0A> =
Most of the guy's who are running vga passthru are recommanding to use=0A> =
windows xp, and i've never seen any success report of vga passthru on=0A> w=
indows 7 so i thought it was important to post mine.=0A> =0A> Anyway, here'=
s my hardware setup :=0A> - Gigabyte GA-990X-UD3=0A> - AMD Phenom II X6 107=
5T Processor=0A> - MSI Cyclone NVIDIA Geforce GTX 460=0A> =0A> On the softw=
are side i'm using :=0A> =0A> - Debian testing as Dom0=0A> - Xen-4.1 (debia=
n version 4.1.2-2) with what's now referred to as "Tobias=0A> Geiger patche=
s" (=0A> http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/m=
sg00441.html)=0A> (You have to edit the patches, changing the path to some =
qemu source files=0A> for them to apply)=0A> - debian's kernel=A0 3.1.5, co=
mpiled to include the pciback driver. Here's=0A> the output of `cat /boot/m=
y3.1.5config | grep -i xen`=0A> CONFIG_XEN=3Dy=0A> CONFIG_XEN_DOM0=3Dy=0A> =
CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A> CONFIG_XEN_PVHVM=3Dy=0A> CONFIG_XEN_MAX=
_DOMAIN_MEMORY=3D128=0A> CONFIG_XEN_SAVE_RESTORE=3Dy=0A> # CONFIG_XEN_DEBUG=
_FS is not set=0A> # CONFIG_XEN_DEBUG is not set=0A> CONFIG_PCI_XEN=3Dy=0A>=
 CONFIG_XEN_PCIDEV_FRONTEND=3Dm=0A> CONFIG_XEN_BLKDEV_FRONTEND=3Dm=0A> CONF=
IG_XEN_BLKDEV_BACKEND=3Dm=0A> CONFIG_NETXEN_NIC=3Dm=0A> CONFIG_XEN_NETDEV_F=
RONTEND=3Dm=0A> CONFIG_XEN_NETDEV_BACKEND=3Dm=0A> CONFIG_INPUT_XEN_KBDDEV_F=
RONTEND=3Dy=0A> CONFIG_HVC_XEN=3Dy=0A> CONFIG_XEN_WDT=3Dm=0A> CONFIG_XEN_FB=
DEV_FRONTEND=3Dy=0A> # Xen driver support=0A> CONFIG_XEN_BALLOON=3Dy=0A> # =
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=0A> CONFIG_XEN_SCRUB_PAGES=3Dy=
=0A> CONFIG_XEN_DEV_EVTCHN=3Dm=0A> CONFIG_XEN_BACKEND=3Dy=0A> CONFIG_XENFS=
=3Dm=0A> CONFIG_XEN_COMPAT_XENFS=3Dy=0A> CONFIG_XEN_SYS_HYPERVISOR=3Dy=0A> =
CONFIG_XEN_XENBUS_FRONTEND=3Dy=0A> CONFIG_XEN_GNTDEV=3Dm=0A> CONFIG_XEN_GRA=
NT_DEV_ALLOC=3Dm=0A> CONFIG_XEN_PLATFORM_PCI=3Dm=0A> CONFIG_SWIOTLB_XEN=3Dy=
=0A> CONFIG_XEN_PCIDEV_BACKEND=3Dy=0A> =0A> The kernel boot options are 'no=
modeset xen-pciback.passthrough=3D1=0A> xen-pciback.hide=3D(01:00.0)(01:00.=
1)'=0A> =0A> - Here's my win7 domU config file :=0A> =0A> kernel =3D "/usr/=
lib/xen-4.1/boot/hvmloader"=0A> builder=3D'hvm'=0A> memory =3D 3072=0A> nam=
e =3D "w7"=0A> vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:3=
5:49:62']=0A> disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/a=
ppz,hdb,w']=0A> device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0A> boot=3D=
"dc"=0A> =0A> pci=3D['01:00.0','01:00.1']=0A> gfx_passthru=3D1=0A> =0A> vcp=
us=3D6=0A> acpi=3D1=0A> sdl=3D0=0A> vnc=3D1=0A> vncconsole=3D1=0A> vncpassw=
d=3D''=0A> serial=3D'pty'=0A> usbdevice=3D'tablet'=0A> pae=3D1=0A> pci_msit=
ranslate=3D0=0A> pci_power_mgmt=3D0=0A> acpi_s3 =3D 1=0A> acpi_s4 =3D 1=0A>=
 on_poweroff =3D 'destroy'=0A> on_reboot=A0  =3D 'restart'=0A> on_crash=A0 =
=A0 =3D 'restart'=0A> xen_platform_pci=3D1=0A> hpet =3D 1=0A> viridian=3D1=
=0A> monitor=3D1=0A> xen_extended_power_mgmt=3D2=0A> hpet=3D1=0A> =0A> What=
's important here for the Nvidia drivers to work and not give a nice=0A> nv=
lddmkm.sys BSOD is:=0A> pci_msitranslate=3D0=0A> pci_power_mgmt=3D0=0A> =0A=
> - Windows 7 32bits=0A> - Nvidia drivers 275.33=0A> - You have to manually=
 run aero speed test or force aero to start by using=0A> registry entries f=
or the desktop not to be laggy=0A> =0A> The windows 7 domU is running fine =
with no performance decrease=0A> noticeable,=0A> although i've not yet play=
ed intensive gpu video game, i'm still pretty=0A> confident they'll run fin=
e.=0A> =0A> Anyway. i've still some problems i shall report in separate pos=
ts :=0A> - The PCI bus topology isn't preserved, and the gfx card, which is=
 plugged=0A> on 01:00 becomes 05:00 on domU.=0A> - I'm passing through an R=
ME Hdsp / hammerfall pci sound card to the domU=0A> and while it is working=
 fine on his own, there's a strange interaction=0A> between it and the GPLP=
V network driver. When i start playing sound, the=0A> network instantly cea=
se working. It starts back as soon as i stop playing=0A> audio.=0A> =0A> Th=
at's all folks,=0A> =0A> Cheers,=0A> Lta=0A> =0A> _________________________=
______________________=0A> Xen-devel mailing list=0A> Xen-devel@.xensource=
=0A> http://lists.xensource.com/xen-devel=0A> =0A=0AYou could be my HERO of=
 the day. =0AHowever I have to wait monday to confirm that this works on my=
 setup too,=0Asince I'm not at home.=0A=0AMaybe you just saved me from buyi=
ng an ATI card. I'll let you know asap.=0ATHANKS=0A=0A=0A--=0AView this mes=
sage in context: http://xen.1045712.n5.nabble.com/Secondary-VGA-Passthrough=
-nvidia-win7-success-report-tp5126062p5126105.html=0ASent from the Xen - De=
v mailing list archive at Nabble.com.=0A=0A________________________________=
_______________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0A=
http://lists.xensource.com/xen-devel
--62747910-1077758145-1325869657=:29172
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>I am going=
 to test it in a couple hours when I am back to home.</span></div><div><br>=
<span></span></div><div><span>If it works with xen 4.2, it should be very v=
ery interesting :)</span></div><div><br><span></span></div><div><span>I wil=
l let you know.<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, times, serif; font-size: 12pt;"> <f=
ont size=3D"2" face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-weig=
ht: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.xen=
source.com <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span><=
/b> Vendredi 6 Janvier 2012 18h02<br> <b><span style=3D"font-weight:
 bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Secondary VGA Passthrough, =
nvidia, win7: success report.<br> </font> <br><br>-+=3D Lta =3D+- wrote<br>=
&gt; <br>&gt; Hello xen-devel,<br>&gt; <br>&gt; <br>&gt; This is my first p=
ost on this list and as such i might be breaking some<br>&gt; explicit/impl=
icit rules and i apologize if it's the case. Maybe this list<br>&gt; isn't =
the exact right kind of place where to post this kind of stuff, but<br>&gt;=
 i<br>&gt; know lots of us are browsing this list as the primary source of<=
br>&gt; documentation for xen.<br>&gt; <br>&gt; I've read many times window=
s 7 isn't the right os to run on top of xen.<br>&gt; Most of the guy's who =
are running vga passthru are recommanding to use<br>&gt; windows xp, and i'=
ve never seen any success report of vga passthru on<br>&gt; windows 7 so i =
thought it was important to post mine.<br>&gt; <br>&gt; Anyway, here's my h=
ardware setup :<br>&gt; - Gigabyte GA-990X-UD3<br>&gt; - AMD Phenom II
 X6 1075T Processor<br>&gt; - MSI Cyclone NVIDIA Geforce GTX 460<br>&gt; <b=
r>&gt; On the software side i'm using :<br>&gt; <br>&gt; - Debian testing a=
s Dom0<br>&gt; - Xen-4.1 (debian version 4.1.2-2) with what's now referred =
to as "Tobias<br>&gt; Geiger patches" (<br>&gt; <a href=3D"http://old-list-=
archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html" target=3D"_=
blank">http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg=
00441.html</a>)<br>&gt; (You have to edit the patches, changing the path to=
 some qemu source files<br>&gt; for them to apply)<br>&gt; - debian's kerne=
l&nbsp; 3.1.5, compiled to include the pciback driver. Here's<br>&gt; the o=
utput of `cat /boot/my3.1.5config | grep -i xen`<br>&gt; CONFIG_XEN=3Dy<br>=
&gt; CONFIG_XEN_DOM0=3Dy<br>&gt; CONFIG_XEN_PRIVILEGED_GUEST=3Dy<br>&gt; CO=
NFIG_XEN_PVHVM=3Dy<br>&gt; CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128<br>&gt; CONFI=
G_XEN_SAVE_RESTORE=3Dy<br>&gt; # CONFIG_XEN_DEBUG_FS is not set<br>&gt; #
 CONFIG_XEN_DEBUG is not set<br>&gt; CONFIG_PCI_XEN=3Dy<br>&gt; CONFIG_XEN_=
PCIDEV_FRONTEND=3Dm<br>&gt; CONFIG_XEN_BLKDEV_FRONTEND=3Dm<br>&gt; CONFIG_X=
EN_BLKDEV_BACKEND=3Dm<br>&gt; CONFIG_NETXEN_NIC=3Dm<br>&gt; CONFIG_XEN_NETD=
EV_FRONTEND=3Dm<br>&gt; CONFIG_XEN_NETDEV_BACKEND=3Dm<br>&gt; CONFIG_INPUT_=
XEN_KBDDEV_FRONTEND=3Dy<br>&gt; CONFIG_HVC_XEN=3Dy<br>&gt; CONFIG_XEN_WDT=
=3Dm<br>&gt; CONFIG_XEN_FBDEV_FRONTEND=3Dy<br>&gt; # Xen driver support<br>=
&gt; CONFIG_XEN_BALLOON=3Dy<br>&gt; # CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is =
not set<br>&gt; CONFIG_XEN_SCRUB_PAGES=3Dy<br>&gt; CONFIG_XEN_DEV_EVTCHN=3D=
m<br>&gt; CONFIG_XEN_BACKEND=3Dy<br>&gt; CONFIG_XENFS=3Dm<br>&gt; CONFIG_XE=
N_COMPAT_XENFS=3Dy<br>&gt; CONFIG_XEN_SYS_HYPERVISOR=3Dy<br>&gt; CONFIG_XEN=
_XENBUS_FRONTEND=3Dy<br>&gt; CONFIG_XEN_GNTDEV=3Dm<br>&gt; CONFIG_XEN_GRANT=
_DEV_ALLOC=3Dm<br>&gt; CONFIG_XEN_PLATFORM_PCI=3Dm<br>&gt; CONFIG_SWIOTLB_X=
EN=3Dy<br>&gt; CONFIG_XEN_PCIDEV_BACKEND=3Dy<br>&gt; <br>&gt; The kernel bo=
ot options are 'nomodeset
 xen-pciback.passthrough=3D1<br>&gt; xen-pciback.hide=3D(01:00.0)(01:00.1)'=
<br>&gt; <br>&gt; - Here's my win7 domU config file :<br>&gt; <br>&gt; kern=
el =3D "/usr/lib/xen-4.1/boot/hvmloader"<br>&gt; builder=3D'hvm'<br>&gt; me=
mory =3D 3072<br>&gt; name =3D "w7"<br>&gt; vif =3D [ 'type=3Dnetfront,brid=
ge=3Dxenbr0, mac=3D00:16:3e:35:49:62']<br>&gt; disk =3D [ 'phy:/dev/w7-xen/=
system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']<br>&gt; device_model =3D '/usr=
/lib/xen-4.1/bin/qemu-dm'<br>&gt; boot=3D"dc"<br>&gt; <br>&gt; pci=3D['01:0=
0.0','01:00.1']<br>&gt; gfx_passthru=3D1<br>&gt; <br>&gt; vcpus=3D6<br>&gt;=
 acpi=3D1<br>&gt; sdl=3D0<br>&gt; vnc=3D1<br>&gt; vncconsole=3D1<br>&gt; vn=
cpasswd=3D''<br>&gt; serial=3D'pty'<br>&gt; usbdevice=3D'tablet'<br>&gt; pa=
e=3D1<br>&gt; pci_msitranslate=3D0<br>&gt; pci_power_mgmt=3D0<br>&gt; acpi_=
s3 =3D 1<br>&gt; acpi_s4 =3D 1<br>&gt; on_poweroff =3D 'destroy'<br>&gt; on=
_reboot&nbsp;  =3D 'restart'<br>&gt; on_crash&nbsp; &nbsp; =3D 'restart'<br=
>&gt; xen_platform_pci=3D1<br>&gt; hpet =3D 1<br>&gt;
 viridian=3D1<br>&gt; monitor=3D1<br>&gt; xen_extended_power_mgmt=3D2<br>&g=
t; hpet=3D1<br>&gt; <br>&gt; What's important here for the Nvidia drivers t=
o work and not give a nice<br>&gt; nvlddmkm.sys BSOD is:<br>&gt; pci_msitra=
nslate=3D0<br>&gt; pci_power_mgmt=3D0<br>&gt; <br>&gt; - Windows 7 32bits<b=
r>&gt; - Nvidia drivers 275.33<br>&gt; - You have to manually run aero spee=
d test or force aero to start by using<br>&gt; registry entries for the des=
ktop not to be laggy<br>&gt; <br>&gt; The windows 7 domU is running fine wi=
th no performance decrease<br>&gt; noticeable,<br>&gt; although i've not ye=
t played intensive gpu video game, i'm still pretty<br>&gt; confident they'=
ll run fine.<br>&gt; <br>&gt; Anyway. i've still some problems i shall repo=
rt in separate posts :<br>&gt; - The PCI bus topology isn't preserved, and =
the gfx card, which is plugged<br>&gt; on 01:00 becomes 05:00 on domU.<br>&=
gt; - I'm passing through an RME Hdsp / hammerfall pci sound card to the
 domU<br>&gt; and while it is working fine on his own, there's a strange in=
teraction<br>&gt; between it and the GPLPV network driver. When i start pla=
ying sound, the<br>&gt; network instantly cease working. It starts back as =
soon as i stop playing<br>&gt; audio.<br>&gt; <br>&gt; That's all folks,<br=
>&gt; <br>&gt; Cheers,<br>&gt; Lta<br>&gt; <br>&gt; _______________________=
________________________<br>&gt; Xen-devel mailing list<br>&gt; Xen-devel@.=
xensource<br>&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=
=3D"_blank">http://lists.xensource.com/xen-devel</a><br>&gt; <br><br>You co=
uld be my HERO of the day. <br>However I have to wait monday to confirm tha=
t this works on my setup too,<br>since I'm not at home.<br><br>Maybe you ju=
st saved me from buying an ATI card. I'll let you know asap.<br>THANKS<br><=
br><br>--<br>View this message in context: <a
 href=3D"http://xen.1045712.n5.nabble.com/Secondary-VGA-Passthrough-nvidia-=
win7-success-report-tp5126062p5126105.html" target=3D"_blank">http://xen.10=
45712.n5.nabble.com/Secondary-VGA-Passthrough-nvidia-win7-success-report-tp=
5126062p5126105.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:Xen-devel@lists.xensource.com" h=
ref=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">h=
ttp://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  </div></=
body></html>
--62747910-1077758145-1325869657=:29172--


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

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

--===============3167108891165893783==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 17:07:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjDGc-0006Tv-9d; Fri, 06 Jan 2012 17:07:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjDGb-0006T6-IC
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:07:46 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-14.tower-182.messagelabs.com!1325869658!9863720!1
X-Originating-IP: [77.238.189.214]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,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 28255 invoked from network); 6 Jan 2012 17:07:38 -0000
Received: from nm17-vm0.bullet.mail.ird.yahoo.com (HELO
	nm17-vm0.bullet.mail.ird.yahoo.com) (77.238.189.214)
	by server-14.tower-182.messagelabs.com with SMTP;
	6 Jan 2012 17:07:38 -0000
Received: from [77.238.189.233] by nm17.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:07:38 -0000
Received: from [212.82.108.121] by tm14.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:07:37 -0000
Received: from [127.0.0.1] by omp1030.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 17:07:37 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 890057.47618.bm@omp1030.mail.ird.yahoo.com
Received: (qmail 29644 invoked by uid 60001); 6 Jan 2012 17:07:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325869657; bh=NPSOUb9z8nYML51IAwr8OUIB3grd4CTaUVAykPutUrc=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=wXDyoVxhIXcx35NWUkjfLClx0kzrAhFuJms7esKedJvnfAe/SqehXpFRrOM2XeyTceHoP+Lqu8goBDVXlG3ax7wPVmBtXBa/bTAyLoUPdmvweKj1oru5z61Ls74f5kkYrAcx/7kOCPqIs0aUBtOoFBA4fIhW3ECJDrG0S9H/jOc=
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=e6lut1fEjQ0Yn5VgJca8RPTg+u7zL75YTu+nfZ+MfhNVBWGsAx+ISoevD3Lc2tX6w6CyFiolaV23LScSStHQABtUarzIR16Izwnai2+HBH47l24Cl3TH0/yXxyZoKLjxJ/S6BDnikLl3bS5HAmQzNwDWoLbnJu8x+WW9tbaqhDM=;
X-YMail-OSG: 93g2WN0VM1leHEYZS.PyFXJrxe5ZDEgHNNvhKT_OFoHz6uw
	.MA0U5NrItl2p1CXkSEE8_K9QtwErNKhdPVj6jk8IwTC_hjxcKnLteQjUU8W
	yUjSsaC.r.J5fXOJNeFDSfpTeCEFuNRGG12EqW0lRvNNuegOkzvBafLCy2T7
	cb7FFFvIwOeKgAF1jUpqvA8VGHDYth8GpACi2s7YALA6GMA0kfdWFKbUWa90
	vs9CrI6qj76WwfHPdixy6d4xslVl.FVWHV_vmjdU6VbBcAVFv7ai6CVPVJ.l
	9Mmn1XMGABqOwsQ5DiYh7q4he96PgikMByDTTOyK1YKW0MbA5EkRKUSaXkz4
	TRX9hwZula6ifoWY5OGA5nHUvcClbl.B_pDL5QNUapz5jQ81kFbojX9AOsiW
	wwxnrjt4m141qcQrHb0pohQf0d7Yfd2vYeTzX4FgYdX1bMNyOc1aSTJISc7f
	ZX2mJjg6tbH_DKbBRvuKo1fC.tYGt_4obvEuiHppivoF8rkWijRxMITrxrC1
	RPgwt.Nx03NOETklruWdDAaQUenAYU5KPuddpRKdjdWp.EP7jEUNtl5NychV
	cLccxkVUmPNO3fZXlkTf2lzkaE7VYlj9WC9R4mnS6gaDU5SQLoo_XmIhZlSk
	z7Wqa8N1wA9U.udaqn.oJTJtobl1RbJ7058G2FviQMDrSJElORBD1qhFWocQ
	MyxXuc.taa41BgtkK01yyJhbQpKChrjuAMWh.UzZF6ybojhQADBE7HOcrjVF
	NrE.B1Ggo_1iDeua0rk08pqwG7mG71b5rOO.wCXufL6w1MXvp3DdBYsgS5SV
	hOnyFxDJtqGfItaTB3OFAchq1urByW6XM_17k__eZkV6Hafh0dBY-
Received: from [195.167.237.98] by web29805.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 17:07:37 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325869356591-5126105.post@n5.nabble.com>
Message-ID: <1325869657.29172.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 17:07:37 +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: <1325869356591-5126105.post@n5.nabble.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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="===============3167108891165893783=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3167108891165893783==
Content-Type: multipart/alternative; boundary="62747910-1077758145-1325869657=:29172"

--62747910-1077758145-1325869657=:29172
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I am going to test it in a couple hours when I am back to home.=0A=0AIf it =
works with xen 4.2, it should be very very interesting :)=0A=0AI will let y=
ou know.=0A=0A=0A=0A________________________________=0A De=A0: n4rC0t1C <sh=
andivo@gmail.com>=0A=C0=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : =
Vendredi 6 Janvier 2012 18h02=0AObjet=A0: Re: [Xen-devel] Secondary VGA Pas=
sthrough, nvidia, win7: success report.=0A =0A=0A-+=3D Lta =3D+- wrote=0A> =
=0A> Hello xen-devel,=0A> =0A> =0A> This is my first post on this list and =
as such i might be breaking some=0A> explicit/implicit rules and i apologiz=
e if it's the case. Maybe this list=0A> isn't the exact right kind of place=
 where to post this kind of stuff, but=0A> i=0A> know lots of us are browsi=
ng this list as the primary source of=0A> documentation for xen.=0A> =0A> I=
've read many times windows 7 isn't the right os to run on top of xen.=0A> =
Most of the guy's who are running vga passthru are recommanding to use=0A> =
windows xp, and i've never seen any success report of vga passthru on=0A> w=
indows 7 so i thought it was important to post mine.=0A> =0A> Anyway, here'=
s my hardware setup :=0A> - Gigabyte GA-990X-UD3=0A> - AMD Phenom II X6 107=
5T Processor=0A> - MSI Cyclone NVIDIA Geforce GTX 460=0A> =0A> On the softw=
are side i'm using :=0A> =0A> - Debian testing as Dom0=0A> - Xen-4.1 (debia=
n version 4.1.2-2) with what's now referred to as "Tobias=0A> Geiger patche=
s" (=0A> http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/m=
sg00441.html)=0A> (You have to edit the patches, changing the path to some =
qemu source files=0A> for them to apply)=0A> - debian's kernel=A0 3.1.5, co=
mpiled to include the pciback driver. Here's=0A> the output of `cat /boot/m=
y3.1.5config | grep -i xen`=0A> CONFIG_XEN=3Dy=0A> CONFIG_XEN_DOM0=3Dy=0A> =
CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A> CONFIG_XEN_PVHVM=3Dy=0A> CONFIG_XEN_MAX=
_DOMAIN_MEMORY=3D128=0A> CONFIG_XEN_SAVE_RESTORE=3Dy=0A> # CONFIG_XEN_DEBUG=
_FS is not set=0A> # CONFIG_XEN_DEBUG is not set=0A> CONFIG_PCI_XEN=3Dy=0A>=
 CONFIG_XEN_PCIDEV_FRONTEND=3Dm=0A> CONFIG_XEN_BLKDEV_FRONTEND=3Dm=0A> CONF=
IG_XEN_BLKDEV_BACKEND=3Dm=0A> CONFIG_NETXEN_NIC=3Dm=0A> CONFIG_XEN_NETDEV_F=
RONTEND=3Dm=0A> CONFIG_XEN_NETDEV_BACKEND=3Dm=0A> CONFIG_INPUT_XEN_KBDDEV_F=
RONTEND=3Dy=0A> CONFIG_HVC_XEN=3Dy=0A> CONFIG_XEN_WDT=3Dm=0A> CONFIG_XEN_FB=
DEV_FRONTEND=3Dy=0A> # Xen driver support=0A> CONFIG_XEN_BALLOON=3Dy=0A> # =
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=0A> CONFIG_XEN_SCRUB_PAGES=3Dy=
=0A> CONFIG_XEN_DEV_EVTCHN=3Dm=0A> CONFIG_XEN_BACKEND=3Dy=0A> CONFIG_XENFS=
=3Dm=0A> CONFIG_XEN_COMPAT_XENFS=3Dy=0A> CONFIG_XEN_SYS_HYPERVISOR=3Dy=0A> =
CONFIG_XEN_XENBUS_FRONTEND=3Dy=0A> CONFIG_XEN_GNTDEV=3Dm=0A> CONFIG_XEN_GRA=
NT_DEV_ALLOC=3Dm=0A> CONFIG_XEN_PLATFORM_PCI=3Dm=0A> CONFIG_SWIOTLB_XEN=3Dy=
=0A> CONFIG_XEN_PCIDEV_BACKEND=3Dy=0A> =0A> The kernel boot options are 'no=
modeset xen-pciback.passthrough=3D1=0A> xen-pciback.hide=3D(01:00.0)(01:00.=
1)'=0A> =0A> - Here's my win7 domU config file :=0A> =0A> kernel =3D "/usr/=
lib/xen-4.1/boot/hvmloader"=0A> builder=3D'hvm'=0A> memory =3D 3072=0A> nam=
e =3D "w7"=0A> vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:3=
5:49:62']=0A> disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/a=
ppz,hdb,w']=0A> device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0A> boot=3D=
"dc"=0A> =0A> pci=3D['01:00.0','01:00.1']=0A> gfx_passthru=3D1=0A> =0A> vcp=
us=3D6=0A> acpi=3D1=0A> sdl=3D0=0A> vnc=3D1=0A> vncconsole=3D1=0A> vncpassw=
d=3D''=0A> serial=3D'pty'=0A> usbdevice=3D'tablet'=0A> pae=3D1=0A> pci_msit=
ranslate=3D0=0A> pci_power_mgmt=3D0=0A> acpi_s3 =3D 1=0A> acpi_s4 =3D 1=0A>=
 on_poweroff =3D 'destroy'=0A> on_reboot=A0  =3D 'restart'=0A> on_crash=A0 =
=A0 =3D 'restart'=0A> xen_platform_pci=3D1=0A> hpet =3D 1=0A> viridian=3D1=
=0A> monitor=3D1=0A> xen_extended_power_mgmt=3D2=0A> hpet=3D1=0A> =0A> What=
's important here for the Nvidia drivers to work and not give a nice=0A> nv=
lddmkm.sys BSOD is:=0A> pci_msitranslate=3D0=0A> pci_power_mgmt=3D0=0A> =0A=
> - Windows 7 32bits=0A> - Nvidia drivers 275.33=0A> - You have to manually=
 run aero speed test or force aero to start by using=0A> registry entries f=
or the desktop not to be laggy=0A> =0A> The windows 7 domU is running fine =
with no performance decrease=0A> noticeable,=0A> although i've not yet play=
ed intensive gpu video game, i'm still pretty=0A> confident they'll run fin=
e.=0A> =0A> Anyway. i've still some problems i shall report in separate pos=
ts :=0A> - The PCI bus topology isn't preserved, and the gfx card, which is=
 plugged=0A> on 01:00 becomes 05:00 on domU.=0A> - I'm passing through an R=
ME Hdsp / hammerfall pci sound card to the domU=0A> and while it is working=
 fine on his own, there's a strange interaction=0A> between it and the GPLP=
V network driver. When i start playing sound, the=0A> network instantly cea=
se working. It starts back as soon as i stop playing=0A> audio.=0A> =0A> Th=
at's all folks,=0A> =0A> Cheers,=0A> Lta=0A> =0A> _________________________=
______________________=0A> Xen-devel mailing list=0A> Xen-devel@.xensource=
=0A> http://lists.xensource.com/xen-devel=0A> =0A=0AYou could be my HERO of=
 the day. =0AHowever I have to wait monday to confirm that this works on my=
 setup too,=0Asince I'm not at home.=0A=0AMaybe you just saved me from buyi=
ng an ATI card. I'll let you know asap.=0ATHANKS=0A=0A=0A--=0AView this mes=
sage in context: http://xen.1045712.n5.nabble.com/Secondary-VGA-Passthrough=
-nvidia-win7-success-report-tp5126062p5126105.html=0ASent from the Xen - De=
v mailing list archive at Nabble.com.=0A=0A________________________________=
_______________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0A=
http://lists.xensource.com/xen-devel
--62747910-1077758145-1325869657=:29172
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>I am going=
 to test it in a couple hours when I am back to home.</span></div><div><br>=
<span></span></div><div><span>If it works with xen 4.2, it should be very v=
ery interesting :)</span></div><div><br><span></span></div><div><span>I wil=
l let you know.<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, times, serif; font-size: 12pt;"> <f=
ont size=3D"2" face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-weig=
ht: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.xen=
source.com <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span><=
/b> Vendredi 6 Janvier 2012 18h02<br> <b><span style=3D"font-weight:
 bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] Secondary VGA Passthrough, =
nvidia, win7: success report.<br> </font> <br><br>-+=3D Lta =3D+- wrote<br>=
&gt; <br>&gt; Hello xen-devel,<br>&gt; <br>&gt; <br>&gt; This is my first p=
ost on this list and as such i might be breaking some<br>&gt; explicit/impl=
icit rules and i apologize if it's the case. Maybe this list<br>&gt; isn't =
the exact right kind of place where to post this kind of stuff, but<br>&gt;=
 i<br>&gt; know lots of us are browsing this list as the primary source of<=
br>&gt; documentation for xen.<br>&gt; <br>&gt; I've read many times window=
s 7 isn't the right os to run on top of xen.<br>&gt; Most of the guy's who =
are running vga passthru are recommanding to use<br>&gt; windows xp, and i'=
ve never seen any success report of vga passthru on<br>&gt; windows 7 so i =
thought it was important to post mine.<br>&gt; <br>&gt; Anyway, here's my h=
ardware setup :<br>&gt; - Gigabyte GA-990X-UD3<br>&gt; - AMD Phenom II
 X6 1075T Processor<br>&gt; - MSI Cyclone NVIDIA Geforce GTX 460<br>&gt; <b=
r>&gt; On the software side i'm using :<br>&gt; <br>&gt; - Debian testing a=
s Dom0<br>&gt; - Xen-4.1 (debian version 4.1.2-2) with what's now referred =
to as "Tobias<br>&gt; Geiger patches" (<br>&gt; <a href=3D"http://old-list-=
archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html" target=3D"_=
blank">http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg=
00441.html</a>)<br>&gt; (You have to edit the patches, changing the path to=
 some qemu source files<br>&gt; for them to apply)<br>&gt; - debian's kerne=
l&nbsp; 3.1.5, compiled to include the pciback driver. Here's<br>&gt; the o=
utput of `cat /boot/my3.1.5config | grep -i xen`<br>&gt; CONFIG_XEN=3Dy<br>=
&gt; CONFIG_XEN_DOM0=3Dy<br>&gt; CONFIG_XEN_PRIVILEGED_GUEST=3Dy<br>&gt; CO=
NFIG_XEN_PVHVM=3Dy<br>&gt; CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128<br>&gt; CONFI=
G_XEN_SAVE_RESTORE=3Dy<br>&gt; # CONFIG_XEN_DEBUG_FS is not set<br>&gt; #
 CONFIG_XEN_DEBUG is not set<br>&gt; CONFIG_PCI_XEN=3Dy<br>&gt; CONFIG_XEN_=
PCIDEV_FRONTEND=3Dm<br>&gt; CONFIG_XEN_BLKDEV_FRONTEND=3Dm<br>&gt; CONFIG_X=
EN_BLKDEV_BACKEND=3Dm<br>&gt; CONFIG_NETXEN_NIC=3Dm<br>&gt; CONFIG_XEN_NETD=
EV_FRONTEND=3Dm<br>&gt; CONFIG_XEN_NETDEV_BACKEND=3Dm<br>&gt; CONFIG_INPUT_=
XEN_KBDDEV_FRONTEND=3Dy<br>&gt; CONFIG_HVC_XEN=3Dy<br>&gt; CONFIG_XEN_WDT=
=3Dm<br>&gt; CONFIG_XEN_FBDEV_FRONTEND=3Dy<br>&gt; # Xen driver support<br>=
&gt; CONFIG_XEN_BALLOON=3Dy<br>&gt; # CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is =
not set<br>&gt; CONFIG_XEN_SCRUB_PAGES=3Dy<br>&gt; CONFIG_XEN_DEV_EVTCHN=3D=
m<br>&gt; CONFIG_XEN_BACKEND=3Dy<br>&gt; CONFIG_XENFS=3Dm<br>&gt; CONFIG_XE=
N_COMPAT_XENFS=3Dy<br>&gt; CONFIG_XEN_SYS_HYPERVISOR=3Dy<br>&gt; CONFIG_XEN=
_XENBUS_FRONTEND=3Dy<br>&gt; CONFIG_XEN_GNTDEV=3Dm<br>&gt; CONFIG_XEN_GRANT=
_DEV_ALLOC=3Dm<br>&gt; CONFIG_XEN_PLATFORM_PCI=3Dm<br>&gt; CONFIG_SWIOTLB_X=
EN=3Dy<br>&gt; CONFIG_XEN_PCIDEV_BACKEND=3Dy<br>&gt; <br>&gt; The kernel bo=
ot options are 'nomodeset
 xen-pciback.passthrough=3D1<br>&gt; xen-pciback.hide=3D(01:00.0)(01:00.1)'=
<br>&gt; <br>&gt; - Here's my win7 domU config file :<br>&gt; <br>&gt; kern=
el =3D "/usr/lib/xen-4.1/boot/hvmloader"<br>&gt; builder=3D'hvm'<br>&gt; me=
mory =3D 3072<br>&gt; name =3D "w7"<br>&gt; vif =3D [ 'type=3Dnetfront,brid=
ge=3Dxenbr0, mac=3D00:16:3e:35:49:62']<br>&gt; disk =3D [ 'phy:/dev/w7-xen/=
system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']<br>&gt; device_model =3D '/usr=
/lib/xen-4.1/bin/qemu-dm'<br>&gt; boot=3D"dc"<br>&gt; <br>&gt; pci=3D['01:0=
0.0','01:00.1']<br>&gt; gfx_passthru=3D1<br>&gt; <br>&gt; vcpus=3D6<br>&gt;=
 acpi=3D1<br>&gt; sdl=3D0<br>&gt; vnc=3D1<br>&gt; vncconsole=3D1<br>&gt; vn=
cpasswd=3D''<br>&gt; serial=3D'pty'<br>&gt; usbdevice=3D'tablet'<br>&gt; pa=
e=3D1<br>&gt; pci_msitranslate=3D0<br>&gt; pci_power_mgmt=3D0<br>&gt; acpi_=
s3 =3D 1<br>&gt; acpi_s4 =3D 1<br>&gt; on_poweroff =3D 'destroy'<br>&gt; on=
_reboot&nbsp;  =3D 'restart'<br>&gt; on_crash&nbsp; &nbsp; =3D 'restart'<br=
>&gt; xen_platform_pci=3D1<br>&gt; hpet =3D 1<br>&gt;
 viridian=3D1<br>&gt; monitor=3D1<br>&gt; xen_extended_power_mgmt=3D2<br>&g=
t; hpet=3D1<br>&gt; <br>&gt; What's important here for the Nvidia drivers t=
o work and not give a nice<br>&gt; nvlddmkm.sys BSOD is:<br>&gt; pci_msitra=
nslate=3D0<br>&gt; pci_power_mgmt=3D0<br>&gt; <br>&gt; - Windows 7 32bits<b=
r>&gt; - Nvidia drivers 275.33<br>&gt; - You have to manually run aero spee=
d test or force aero to start by using<br>&gt; registry entries for the des=
ktop not to be laggy<br>&gt; <br>&gt; The windows 7 domU is running fine wi=
th no performance decrease<br>&gt; noticeable,<br>&gt; although i've not ye=
t played intensive gpu video game, i'm still pretty<br>&gt; confident they'=
ll run fine.<br>&gt; <br>&gt; Anyway. i've still some problems i shall repo=
rt in separate posts :<br>&gt; - The PCI bus topology isn't preserved, and =
the gfx card, which is plugged<br>&gt; on 01:00 becomes 05:00 on domU.<br>&=
gt; - I'm passing through an RME Hdsp / hammerfall pci sound card to the
 domU<br>&gt; and while it is working fine on his own, there's a strange in=
teraction<br>&gt; between it and the GPLPV network driver. When i start pla=
ying sound, the<br>&gt; network instantly cease working. It starts back as =
soon as i stop playing<br>&gt; audio.<br>&gt; <br>&gt; That's all folks,<br=
>&gt; <br>&gt; Cheers,<br>&gt; Lta<br>&gt; <br>&gt; _______________________=
________________________<br>&gt; Xen-devel mailing list<br>&gt; Xen-devel@.=
xensource<br>&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=
=3D"_blank">http://lists.xensource.com/xen-devel</a><br>&gt; <br><br>You co=
uld be my HERO of the day. <br>However I have to wait monday to confirm tha=
t this works on my setup too,<br>since I'm not at home.<br><br>Maybe you ju=
st saved me from buying an ATI card. I'll let you know asap.<br>THANKS<br><=
br><br>--<br>View this message in context: <a
 href=3D"http://xen.1045712.n5.nabble.com/Secondary-VGA-Passthrough-nvidia-=
win7-success-report-tp5126062p5126105.html" target=3D"_blank">http://xen.10=
45712.n5.nabble.com/Secondary-VGA-Passthrough-nvidia-win7-success-report-tp=
5126062p5126105.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:Xen-devel@lists.xensource.com" h=
ref=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">h=
ttp://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  </div></=
body></html>
--62747910-1077758145-1325869657=:29172--


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

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

--===============3167108891165893783==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 17:16:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjDP9-0007Hh-6e; Fri, 06 Jan 2012 17:16: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 1RjDP7-0007HY-Ql
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:16:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325870143!51515694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18865 invoked from network); 6 Jan 2012 17:15:43 -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;
	6 Jan 2012 17:15:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9869818"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 17:16:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Jan 2012
	17:16:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Jones <drjones@redhat.com>
Date: Fri, 6 Jan 2012 17:16:31 +0000
In-Reply-To: <1325867990-15018-1-git-send-email-drjones@redhat.com>
References: <1325867990-15018-1-git-send-email-drjones@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325870192.25206.514.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 16:39 +0000, Andrew Jones wrote:
> remove XEN_PRIVILEGED_GUEST as it's just an alias for XEN_DOM0.

Hmm, this one is used by tools like update-grub to know when it is ok to
create xen+kernel entries so I think it needs to stay, or we at least
need to give lengthly warning to distros etc that it is going away.

Perhaps you can just patch it out locally?

Ian.

> 
> I compile tested this on a latest pull using an F16 config. The compile
> succeeded and 'make oldconfig' only removed these two options as
> expected.
> 
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/x86/include/asm/xen/pci.h |   21 +--------------------
>  arch/x86/pci/xen.c             |    6 ------
>  arch/x86/xen/Kconfig           |   10 ----------
>  arch/x86/xen/Makefile          |    3 +--
>  arch/x86/xen/xen-ops.h         |    7 -------
>  drivers/xen/Kconfig            |    3 ++-
>  drivers/xen/Makefile           |    3 +--
>  drivers/xen/xenfs/Makefile     |    3 +--
>  include/xen/xen.h              |   11 +++--------
>  9 files changed, 9 insertions(+), 58 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
> index 968d57d..b423889 100644
> --- a/arch/x86/include/asm/xen/pci.h
> +++ b/arch/x86/include/asm/xen/pci.h
> @@ -13,30 +13,11 @@ static inline int pci_xen_hvm_init(void)
>  	return -1;
>  }
>  #endif
> -#if defined(CONFIG_XEN_DOM0)
> +
>  int __init pci_xen_initial_domain(void);
>  int xen_find_device_domain_owner(struct pci_dev *dev);
>  int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
>  int xen_unregister_device_domain_owner(struct pci_dev *dev);
> -#else
> -static inline int __init pci_xen_initial_domain(void)
> -{
> -	return -1;
> -}
> -static inline int xen_find_device_domain_owner(struct pci_dev *dev)
> -{
> -	return -1;
> -}
> -static inline int xen_register_device_domain_owner(struct pci_dev *dev,
> -						   uint16_t domain)
> -{
> -	return -1;
> -}
> -static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
> -{
> -	return -1;
> -}
> -#endif
>  
>  #if defined(CONFIG_PCI_MSI)
>  #if defined(CONFIG_PCI_XEN)
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 492ade8..e298726 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -108,7 +108,6 @@ static int acpi_register_gsi_xen_hvm(struct device *dev, u32 gsi,
>  				 false /* no mapping of GSI to PIRQ */);
>  }
>  
> -#ifdef CONFIG_XEN_DOM0
>  static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polarity)
>  {
>  	int rc, irq;
> @@ -143,7 +142,6 @@ static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
>  	return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, polarity);
>  }
>  #endif
> -#endif
>  
>  #if defined(CONFIG_PCI_MSI)
>  #include <linux/msi.h>
> @@ -251,7 +249,6 @@ error:
>  	return irq;
>  }
>  
> -#ifdef CONFIG_XEN_DOM0
>  static bool __read_mostly pci_seg_supported = true;
>  
>  static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> @@ -324,7 +321,6 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  out:
>  	return ret;
>  }
> -#endif
>  
>  static void xen_teardown_msi_irqs(struct pci_dev *dev)
>  {
> @@ -392,7 +388,6 @@ int __init pci_xen_hvm_init(void)
>  	return 0;
>  }
>  
> -#ifdef CONFIG_XEN_DOM0
>  static __init void xen_setup_acpi_sci(void)
>  {
>  	int rc;
> @@ -539,4 +534,3 @@ int xen_unregister_device_domain_owner(struct pci_dev *dev)
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(xen_unregister_device_domain_owner);
> -#endif
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..3c7e89a 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -13,16 +13,6 @@ config XEN
>  	  kernel to boot in a paravirtualized environment under the
>  	  Xen hypervisor.
>  
> -config XEN_DOM0
> -	def_bool y
> -	depends on XEN && PCI_XEN && SWIOTLB_XEN
> -	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> -
> -# Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
> -# name in tools.
> -config XEN_PRIVILEGED_GUEST
> -	def_bool XEN_DOM0
> -
>  config XEN_PVHVM
>  	def_bool y
>  	depends on XEN && PCI && X86_LOCAL_APIC
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index add2c2d..b2d4c4b 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -13,12 +13,11 @@ CFLAGS_mmu.o			:= $(nostackp)
>  obj-y		:= enlighten.o setup.o multicalls.o mmu.o irq.o \
>  			time.o xen-asm.o xen-asm_$(BITS).o \
>  			grant-table.o suspend.o platform-pci-unplug.o \
> -			p2m.o
> +			p2m.o vga.o
>  
>  obj-$(CONFIG_EVENT_TRACING) += trace.o
>  
>  obj-$(CONFIG_SMP)		+= smp.o
>  obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
>  obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
> -obj-$(CONFIG_XEN_DOM0)		+= vga.o
>  obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index b095739..d9dbbca 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -90,14 +90,7 @@ static inline void xen_uninit_lock_cpu(int cpu)
>  
>  struct dom0_vga_console_info;
>  
> -#ifdef CONFIG_XEN_DOM0
>  void __init xen_init_vga(const struct dom0_vga_console_info *, size_t size);
> -#else
> -static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
> -				       size_t size)
> -{
> -}
> -#endif
>  
>  /* Declare an asm function, along with symbols needed to make it
>     inlineable */
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 8795480..0725228 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
>  
>  config XEN_BACKEND
>  	bool "Backend driver support"
> -	depends on XEN_DOM0
>  	default y
> +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
>  	help
>  	  Support for backend device drivers that provide I/O services
>  	  to other virtual machines.
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 974fffd..7e61662 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 pci.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> @@ -17,7 +17,6 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
>  obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> -obj-$(CONFIG_XEN_DOM0)			+= pci.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>  
>  xen-evtchn-y				:= evtchn.o
> diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
> index 4fde944..d20c060 100644
> --- a/drivers/xen/xenfs/Makefile
> +++ b/drivers/xen/xenfs/Makefile
> @@ -1,4 +1,3 @@
>  obj-$(CONFIG_XENFS) += xenfs.o
>  
> -xenfs-y			  = super.o xenbus.o privcmd.o
> -xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
> +xenfs-y			  = super.o xenbus.o privcmd.o xenstored.o
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index a164024..d814ef7 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -1,6 +1,9 @@
>  #ifndef _XEN_XEN_H
>  #define _XEN_XEN_H
>  
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +
>  enum xen_domain_type {
>  	XEN_NATIVE,		/* running on bare hardware    */
>  	XEN_PV_DOMAIN,		/* running in a PV domain      */
> @@ -18,15 +21,7 @@ extern enum xen_domain_type xen_domain_type;
>  				 xen_domain_type == XEN_PV_DOMAIN)
>  #define xen_hvm_domain()	(xen_domain() &&			\
>  				 xen_domain_type == XEN_HVM_DOMAIN)
> -
> -#ifdef CONFIG_XEN_DOM0
> -#include <xen/interface/xen.h>
> -#include <asm/xen/hypervisor.h>
> -
>  #define xen_initial_domain()	(xen_pv_domain() && \
>  				 xen_start_info->flags & SIF_INITDOMAIN)
> -#else  /* !CONFIG_XEN_DOM0 */
> -#define xen_initial_domain()	(0)
> -#endif	/* CONFIG_XEN_DOM0 */
>  
>  #endif	/* _XEN_XEN_H */



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 17:16:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 17:16:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjDP9-0007Hh-6e; Fri, 06 Jan 2012 17:16: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 1RjDP7-0007HY-Ql
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 17:16:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325870143!51515694!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18865 invoked from network); 6 Jan 2012 17:15:43 -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;
	6 Jan 2012 17:15:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9869818"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 17:16:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Jan 2012
	17:16:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andrew Jones <drjones@redhat.com>
Date: Fri, 6 Jan 2012 17:16:31 +0000
In-Reply-To: <1325867990-15018-1-git-send-email-drjones@redhat.com>
References: <1325867990-15018-1-git-send-email-drjones@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1325870192.25206.514.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 16:39 +0000, Andrew Jones wrote:
> remove XEN_PRIVILEGED_GUEST as it's just an alias for XEN_DOM0.

Hmm, this one is used by tools like update-grub to know when it is ok to
create xen+kernel entries so I think it needs to stay, or we at least
need to give lengthly warning to distros etc that it is going away.

Perhaps you can just patch it out locally?

Ian.

> 
> I compile tested this on a latest pull using an F16 config. The compile
> succeeded and 'make oldconfig' only removed these two options as
> expected.
> 
> CONFIG_XEN_DOM0=y
> CONFIG_XEN_PRIVILEGED_GUEST=y
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/x86/include/asm/xen/pci.h |   21 +--------------------
>  arch/x86/pci/xen.c             |    6 ------
>  arch/x86/xen/Kconfig           |   10 ----------
>  arch/x86/xen/Makefile          |    3 +--
>  arch/x86/xen/xen-ops.h         |    7 -------
>  drivers/xen/Kconfig            |    3 ++-
>  drivers/xen/Makefile           |    3 +--
>  drivers/xen/xenfs/Makefile     |    3 +--
>  include/xen/xen.h              |   11 +++--------
>  9 files changed, 9 insertions(+), 58 deletions(-)
> 
> diff --git a/arch/x86/include/asm/xen/pci.h b/arch/x86/include/asm/xen/pci.h
> index 968d57d..b423889 100644
> --- a/arch/x86/include/asm/xen/pci.h
> +++ b/arch/x86/include/asm/xen/pci.h
> @@ -13,30 +13,11 @@ static inline int pci_xen_hvm_init(void)
>  	return -1;
>  }
>  #endif
> -#if defined(CONFIG_XEN_DOM0)
> +
>  int __init pci_xen_initial_domain(void);
>  int xen_find_device_domain_owner(struct pci_dev *dev);
>  int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t domain);
>  int xen_unregister_device_domain_owner(struct pci_dev *dev);
> -#else
> -static inline int __init pci_xen_initial_domain(void)
> -{
> -	return -1;
> -}
> -static inline int xen_find_device_domain_owner(struct pci_dev *dev)
> -{
> -	return -1;
> -}
> -static inline int xen_register_device_domain_owner(struct pci_dev *dev,
> -						   uint16_t domain)
> -{
> -	return -1;
> -}
> -static inline int xen_unregister_device_domain_owner(struct pci_dev *dev)
> -{
> -	return -1;
> -}
> -#endif
>  
>  #if defined(CONFIG_PCI_MSI)
>  #if defined(CONFIG_PCI_XEN)
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 492ade8..e298726 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -108,7 +108,6 @@ static int acpi_register_gsi_xen_hvm(struct device *dev, u32 gsi,
>  				 false /* no mapping of GSI to PIRQ */);
>  }
>  
> -#ifdef CONFIG_XEN_DOM0
>  static int xen_register_gsi(u32 gsi, int gsi_override, int triggering, int polarity)
>  {
>  	int rc, irq;
> @@ -143,7 +142,6 @@ static int acpi_register_gsi_xen(struct device *dev, u32 gsi,
>  	return xen_register_gsi(gsi, -1 /* no GSI override */, trigger, polarity);
>  }
>  #endif
> -#endif
>  
>  #if defined(CONFIG_PCI_MSI)
>  #include <linux/msi.h>
> @@ -251,7 +249,6 @@ error:
>  	return irq;
>  }
>  
> -#ifdef CONFIG_XEN_DOM0
>  static bool __read_mostly pci_seg_supported = true;
>  
>  static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> @@ -324,7 +321,6 @@ static int xen_initdom_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>  out:
>  	return ret;
>  }
> -#endif
>  
>  static void xen_teardown_msi_irqs(struct pci_dev *dev)
>  {
> @@ -392,7 +388,6 @@ int __init pci_xen_hvm_init(void)
>  	return 0;
>  }
>  
> -#ifdef CONFIG_XEN_DOM0
>  static __init void xen_setup_acpi_sci(void)
>  {
>  	int rc;
> @@ -539,4 +534,3 @@ int xen_unregister_device_domain_owner(struct pci_dev *dev)
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(xen_unregister_device_domain_owner);
> -#endif
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..3c7e89a 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -13,16 +13,6 @@ config XEN
>  	  kernel to boot in a paravirtualized environment under the
>  	  Xen hypervisor.
>  
> -config XEN_DOM0
> -	def_bool y
> -	depends on XEN && PCI_XEN && SWIOTLB_XEN
> -	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> -
> -# Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
> -# name in tools.
> -config XEN_PRIVILEGED_GUEST
> -	def_bool XEN_DOM0
> -
>  config XEN_PVHVM
>  	def_bool y
>  	depends on XEN && PCI && X86_LOCAL_APIC
> diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
> index add2c2d..b2d4c4b 100644
> --- a/arch/x86/xen/Makefile
> +++ b/arch/x86/xen/Makefile
> @@ -13,12 +13,11 @@ CFLAGS_mmu.o			:= $(nostackp)
>  obj-y		:= enlighten.o setup.o multicalls.o mmu.o irq.o \
>  			time.o xen-asm.o xen-asm_$(BITS).o \
>  			grant-table.o suspend.o platform-pci-unplug.o \
> -			p2m.o
> +			p2m.o vga.o
>  
>  obj-$(CONFIG_EVENT_TRACING) += trace.o
>  
>  obj-$(CONFIG_SMP)		+= smp.o
>  obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
>  obj-$(CONFIG_XEN_DEBUG_FS)	+= debugfs.o
> -obj-$(CONFIG_XEN_DOM0)		+= vga.o
>  obj-$(CONFIG_SWIOTLB_XEN)	+= pci-swiotlb-xen.o
> diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
> index b095739..d9dbbca 100644
> --- a/arch/x86/xen/xen-ops.h
> +++ b/arch/x86/xen/xen-ops.h
> @@ -90,14 +90,7 @@ static inline void xen_uninit_lock_cpu(int cpu)
>  
>  struct dom0_vga_console_info;
>  
> -#ifdef CONFIG_XEN_DOM0
>  void __init xen_init_vga(const struct dom0_vga_console_info *, size_t size);
> -#else
> -static inline void __init xen_init_vga(const struct dom0_vga_console_info *info,
> -				       size_t size)
> -{
> -}
> -#endif
>  
>  /* Declare an asm function, along with symbols needed to make it
>     inlineable */
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 8795480..0725228 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
>  
>  config XEN_BACKEND
>  	bool "Backend driver support"
> -	depends on XEN_DOM0
>  	default y
> +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
>  	help
>  	  Support for backend device drivers that provide I/O services
>  	  to other virtual machines.
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 974fffd..7e61662 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 pci.o
>  obj-y	+= xenbus/
>  
>  nostackp := $(call cc-option, -fno-stack-protector)
> @@ -17,7 +17,6 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR)	+= sys-hypervisor.o
>  obj-$(CONFIG_XEN_PVHVM)			+= platform-pci.o
>  obj-$(CONFIG_XEN_TMEM)			+= tmem.o
>  obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
> -obj-$(CONFIG_XEN_DOM0)			+= pci.o
>  obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
>  
>  xen-evtchn-y				:= evtchn.o
> diff --git a/drivers/xen/xenfs/Makefile b/drivers/xen/xenfs/Makefile
> index 4fde944..d20c060 100644
> --- a/drivers/xen/xenfs/Makefile
> +++ b/drivers/xen/xenfs/Makefile
> @@ -1,4 +1,3 @@
>  obj-$(CONFIG_XENFS) += xenfs.o
>  
> -xenfs-y			  = super.o xenbus.o privcmd.o
> -xenfs-$(CONFIG_XEN_DOM0) += xenstored.o
> +xenfs-y			  = super.o xenbus.o privcmd.o xenstored.o
> diff --git a/include/xen/xen.h b/include/xen/xen.h
> index a164024..d814ef7 100644
> --- a/include/xen/xen.h
> +++ b/include/xen/xen.h
> @@ -1,6 +1,9 @@
>  #ifndef _XEN_XEN_H
>  #define _XEN_XEN_H
>  
> +#include <xen/interface/xen.h>
> +#include <asm/xen/hypervisor.h>
> +
>  enum xen_domain_type {
>  	XEN_NATIVE,		/* running on bare hardware    */
>  	XEN_PV_DOMAIN,		/* running in a PV domain      */
> @@ -18,15 +21,7 @@ extern enum xen_domain_type xen_domain_type;
>  				 xen_domain_type == XEN_PV_DOMAIN)
>  #define xen_hvm_domain()	(xen_domain() &&			\
>  				 xen_domain_type == XEN_HVM_DOMAIN)
> -
> -#ifdef CONFIG_XEN_DOM0
> -#include <xen/interface/xen.h>
> -#include <asm/xen/hypervisor.h>
> -
>  #define xen_initial_domain()	(xen_pv_domain() && \
>  				 xen_start_info->flags & SIF_INITDOMAIN)
> -#else  /* !CONFIG_XEN_DOM0 */
> -#define xen_initial_domain()	(0)
> -#endif	/* CONFIG_XEN_DOM0 */
>  
>  #endif	/* _XEN_XEN_H */



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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 18:13:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 18:13:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjEHf-0008Q2-LY; Fri, 06 Jan 2012 18:12:55 +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 1RjEHe-0008Px-BJ
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 18:12:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1325873568!2475418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5920 invoked from network); 6 Jan 2012 18:12:48 -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;
	6 Jan 2012 18:12:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9870302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 18:12: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, 6 Jan 2012 18:12:48 +0000
Date: Fri, 6 Jan 2012 18:12:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EEA333802000078000684E5@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201061759070.3150@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
	<1323966657-19790-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EEA333802000078000684E5@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>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.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 Thu, 15 Dec 2011, Jan Beulich wrote:
> >>> 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?

Yep, good idea.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 18:13:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 18:13:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjEHf-0008Q2-LY; Fri, 06 Jan 2012 18:12:55 +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 1RjEHe-0008Px-BJ
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 18:12:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1325873568!2475418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5920 invoked from network); 6 Jan 2012 18:12:48 -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;
	6 Jan 2012 18:12:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9870302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 18:12: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, 6 Jan 2012 18:12:48 +0000
Date: Fri, 6 Jan 2012 18:12:39 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4EEA333802000078000684E5@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201061759070.3150@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
	<1323966657-19790-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EEA333802000078000684E5@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>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.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 Thu, 15 Dec 2011, Jan Beulich wrote:
> >>> 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?

Yep, good idea.

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 18:13:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 18:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjEIA-0008RC-2L; Fri, 06 Jan 2012 18:13: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 1RjEI8-0008R0-0c
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 18:13:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325873597!2222402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27180 invoked from network); 6 Jan 2012 18:13:17 -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;
	6 Jan 2012 18:13:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9870305"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 18:13: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; Fri, 6 Jan 2012 18:13:16 +0000
Date: Fri, 6 Jan 2012 18:13: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: <4EEA343902000078000684FC@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201061805500.3150@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
	<1323966657-19790-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EEA343902000078000684FC@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>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.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 Thu, 15 Dec 2011, Jan Beulich wrote:
> >>> 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.

I am going to add two checks here and print a message in case of errors,
however I am not going to propagate the error up, considering that there
is no error checking in elf_load_binary and it doesn't return an error.
Would that be OK for you?

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 18:13:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 18:13:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjEIA-0008RC-2L; Fri, 06 Jan 2012 18:13: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 1RjEI8-0008R0-0c
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 18:13:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1325873597!2222402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27180 invoked from network); 6 Jan 2012 18:13:17 -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;
	6 Jan 2012 18:13:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9870305"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 18:13: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; Fri, 6 Jan 2012 18:13:16 +0000
Date: Fri, 6 Jan 2012 18:13: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: <4EEA343902000078000684FC@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201061805500.3150@kaball-desktop>
References: <alpine.DEB.2.00.1112131831560.3517@kaball-desktop>
	<1323966657-19790-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4EEA343902000078000684FC@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>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.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 Thu, 15 Dec 2011, Jan Beulich wrote:
> >>> 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.

I am going to add two checks here and print a message in case of errors,
however I am not going to propagate the error up, considering that there
is no error checking in elf_load_binary and it doesn't return an error.
Would that be OK for you?

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 19:16:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 19:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjFGG-0000a8-02; Fri, 06 Jan 2012 19:15:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1RjFGF-0000a3-9T
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:15:31 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325877325!9994702!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 4673 invoked from network); 6 Jan 2012 19:15:25 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Jan 2012 19:15:25 -0000
Received: from mail51-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Jan 2012 19:15:24 +0000
Received: from mail51-db3 (localhost [127.0.0.1])	by mail51-db3-R.bigfish.com
	(Postfix) with ESMTP id 7BD7E180689;
	Fri,  6 Jan 2012 19:15:24 +0000 (UTC)
X-SpamScore: -17
X-BigFish: VPS-17(zzbb2dI9371I1454I148cM1432N98dKzz1202hzz8275bh8275dhz2dh668h839h)
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 mail51-db3 (localhost.localdomain [127.0.0.1]) by mail51-db3
	(MessageSwitch) id 1325877324368025_10864;
	Fri,  6 Jan 2012 19:15:24 +0000 (UTC)
Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.250])	by
	mail51-db3.bigfish.com (Postfix) with ESMTP id 480B63C0045;
	Fri,  6 Jan 2012 19:15:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Jan 2012 19:15:23 +0000
X-WSS-ID: 0LXE5HJ-01-XOS-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 2AFA91028034;	Fri,  6 Jan 2012 13:15:19 -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;
	Fri, 6 Jan 2012 13:15:39 -0600
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Jan 2012
	13:15:19 -0600
Message-ID: <4F0746CB.6060706@amd.com>
Date: Fri, 6 Jan 2012 13:08:59 -0600
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
	<20120106153714.GA21220@andromeda.dapyr.net>
In-Reply-To: <20120106153714.GA21220@andromeda.dapyr.net>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/06/2012 09:37 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
>> On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
>>> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>>>>>> must haves e.g. in the paging/sharing spaces?
>>>>>>
>>>>> - What's the status of Nested Hardware Virtualization?
>>>>> I remember some email saying Intel vmx-on-vmx has some performance
>>>>> issues,
>>>>> and amd svm-on-svm works better..
>>>>>
>>>>>
>>>>> - Also there's a bunch of VGA passthru related patches,
>>>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>>>> but I still haven't had time for that :(
>>>> Since there were quite a lot of interest on this subject, should we
>>>> document it in a separate wiki for working combinations (like
>>>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>>>
>>> I actually once started writing down that kind of stuff:
>>> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>>>
>>> Feel free to contribute :)
>>>
>>> There's also:
>>> http://wiki.xen.org/xenwiki/XenVGAPassthrough
>> Thanks for sharing. I will contribute my findings as needed. BTW, do you
>> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a
> Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
> from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
> guest and it works nicely.. the first time. After I shut down the guest
> it just never works again :-(

This is a known issue which should be addressed for 4.2. I remember 
several persons reported this problem.

>
>> dilemma for several reasons:  it doesn't always work; sometimes it can
>> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst
>> driver seems very stable even without these patches. But Wei Wang told
>> me that he needs them for some of his cards.
>>> -- 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 Fri Jan 06 19:16:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 19:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjFGG-0000a8-02; Fri, 06 Jan 2012 19:15:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Huang2@amd.com>) id 1RjFGF-0000a3-9T
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:15:31 +0000
X-Env-Sender: Wei.Huang2@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1325877325!9994702!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 4673 invoked from network); 6 Jan 2012 19:15:25 -0000
Received: from db3ehsobe003.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.141)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	6 Jan 2012 19:15:25 -0000
Received: from mail51-db3-R.bigfish.com (10.3.81.249) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Jan 2012 19:15:24 +0000
Received: from mail51-db3 (localhost [127.0.0.1])	by mail51-db3-R.bigfish.com
	(Postfix) with ESMTP id 7BD7E180689;
	Fri,  6 Jan 2012 19:15:24 +0000 (UTC)
X-SpamScore: -17
X-BigFish: VPS-17(zzbb2dI9371I1454I148cM1432N98dKzz1202hzz8275bh8275dhz2dh668h839h)
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 mail51-db3 (localhost.localdomain [127.0.0.1]) by mail51-db3
	(MessageSwitch) id 1325877324368025_10864;
	Fri,  6 Jan 2012 19:15:24 +0000 (UTC)
Received: from DB3EHSMHS009.bigfish.com (unknown [10.3.81.250])	by
	mail51-db3.bigfish.com (Postfix) with ESMTP id 480B63C0045;
	Fri,  6 Jan 2012 19:15:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS009.bigfish.com (10.3.87.109) with Microsoft SMTP Server id
	14.1.225.23; Fri, 6 Jan 2012 19:15:23 +0000
X-WSS-ID: 0LXE5HJ-01-XOS-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 2AFA91028034;	Fri,  6 Jan 2012 13:15:19 -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;
	Fri, 6 Jan 2012 13:15:39 -0600
Received: from huangwei.amd.com (10.236.48.87) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0; Fri, 6 Jan 2012
	13:15:19 -0600
Message-ID: <4F0746CB.6060706@amd.com>
Date: Fri, 6 Jan 2012 13:08:59 -0600
From: Wei Huang <wei.huang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net> <4F04A6CA.3010907@amd.com>
	<20120104194343.GT12984@reaktio.net> <4F04AF28.8040102@amd.com>
	<20120106153714.GA21220@andromeda.dapyr.net>
In-Reply-To: <20120106153714.GA21220@andromeda.dapyr.net>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: wei.huang2@amd.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/06/2012 09:37 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 04, 2012 at 01:57:28PM -0600, Wei Huang wrote:
>> On 01/04/2012 01:43 PM, Pasi K?rkk?inen wrote:
>>> On Wed, Jan 04, 2012 at 01:21:46PM -0600, Wei Huang wrote:
>>>>>> Has anybody got anything else? I'm sure I've missed stuff. Are there any
>>>>>> must haves e.g. in the paging/sharing spaces?
>>>>>>
>>>>> - What's the status of Nested Hardware Virtualization?
>>>>> I remember some email saying Intel vmx-on-vmx has some performance
>>>>> issues,
>>>>> and amd svm-on-svm works better..
>>>>>
>>>>>
>>>>> - Also there's a bunch of VGA passthru related patches,
>>>>> that I once volunteered to collect/rebase/cleanup/repost myself,
>>>>> but I still haven't had time for that :(
>>>> Since there were quite a lot of interest on this subject, should we
>>>> document it in a separate wiki for working combinations (like
>>>> hypervisor, dom0, gfx card, driver version, tricks, etc)?
>>>>
>>> I actually once started writing down that kind of stuff:
>>> http://wiki.xen.org/xenwiki/XenVGAPassthroughTestedAdapters.html
>>>
>>> Feel free to contribute :)
>>>
>>> There's also:
>>> http://wiki.xen.org/xenwiki/XenVGAPassthrough
>> Thanks for sharing. I will contribute my findings as needed. BTW, do you
>> need my VBIOS loading patches (sent long time ago) for AMD GPU? It is a
> Yes! Thought I haven't figured out yet how to extract the AMD GPU BIOS
> from the card. I've been able to pass in a Radeon 4870 to an Win 7 HVM
> guest and it works nicely.. the first time. After I shut down the guest
> it just never works again :-(

This is a known issue which should be addressed for 4.2. I remember 
several persons reported this problem.

>
>> dilemma for several reasons:  it doesn't always work; sometimes it can
>> screw up main display while passthru 2nd GPUs. Plus the recent Catalyst
>> driver seems very stable even without these patches. But Wei Wang told
>> me that he needs them for some of his cards.
>>> -- 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 Fri Jan 06 19:50:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 19: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 1RjFns-0000sL-Rj; Fri, 06 Jan 2012 19:50:16 +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 1RjFnr-0000sG-8R
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:50:15 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325879369!47578782!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQ2OTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28550 invoked from network); 6 Jan 2012 19:49:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 19:49:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320642000"; d="scan'208";a="20639262"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 14:50:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 14:50:12 -0500
Received: from [0.0.0.0] (latara.uk.xensource.com [10.80.16.67])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q06Jo6Ir018853;
	Fri, 6 Jan 2012 11:50:08 -0800
Message-ID: <4F07506E.5050500@eu.citrix.com>
Date: Fri, 6 Jan 2012 14:50:06 -0500
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
	<4F0176940200007800069FE8@nat28.tlf.novell.com>
In-Reply-To: <4F0176940200007800069FE8@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"raistlin@linux.it" <raistlin@linux.it>,
	Ian Campbell <Ian.Campbell@citrix.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/01/12 03:19, Jan Beulich wrote:
>>>> On 26.12.11 at 09:46, Hui Lv<hui.lv@intel.com>  wrote:
>> 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.
> I do not see why you need a per-scheduler-instance variable for
> issuing the warning and correcting the value - one warning (during
> the first initialization) is entirely sufficient. (Otoh the already existing
> tslice_ms field is pointless currently too, as it never gets changed
> after being initialized from sched_credit_tslice_ms - George?)
Before the 4.2 release, I plan to add SYSCTL_scheduler_op calls for the 
credit scheduler for both the timeslice and ratelimiting.  But I don't 
think it's necessary for this patch to be admitted.

  -George

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 19:50:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 19: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 1RjFns-0000sL-Rj; Fri, 06 Jan 2012 19:50:16 +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 1RjFnr-0000sG-8R
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:50:15 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325879369!47578782!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQ2OTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28550 invoked from network); 6 Jan 2012 19:49:30 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 19:49:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320642000"; d="scan'208";a="20639262"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 14:50:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 14:50:12 -0500
Received: from [0.0.0.0] (latara.uk.xensource.com [10.80.16.67])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q06Jo6Ir018853;
	Fri, 6 Jan 2012 11:50:08 -0800
Message-ID: <4F07506E.5050500@eu.citrix.com>
Date: Fri, 6 Jan 2012 14:50:06 -0500
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
	<4F0176940200007800069FE8@nat28.tlf.novell.com>
In-Reply-To: <4F0176940200007800069FE8@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"raistlin@linux.it" <raistlin@linux.it>,
	Ian Campbell <Ian.Campbell@citrix.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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 02/01/12 03:19, Jan Beulich wrote:
>>>> On 26.12.11 at 09:46, Hui Lv<hui.lv@intel.com>  wrote:
>> 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.
> I do not see why you need a per-scheduler-instance variable for
> issuing the warning and correcting the value - one warning (during
> the first initialization) is entirely sufficient. (Otoh the already existing
> tslice_ms field is pointless currently too, as it never gets changed
> after being initialized from sched_credit_tslice_ms - George?)
Before the 4.2 release, I plan to add SYSCTL_scheduler_op calls for the 
credit scheduler for both the timeslice and ratelimiting.  But I don't 
think it's necessary for this patch to be admitted.

  -George

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 19:57:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 19: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 1RjFuT-000112-Nm; Fri, 06 Jan 2012 19:57:05 +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 1RjFuS-00010u-AZ
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:57:04 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325879817!9427855!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQ2OTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6473 invoked from network); 6 Jan 2012 19:56:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 19:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320642000"; d="scan'208";a="20639468"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 14:56:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 14:56:56 -0500
Received: from [0.0.0.0] (latara.uk.xensource.com [10.80.16.67])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q06JuqkD018856;
	Fri, 6 Jan 2012 11:56:53 -0800
Message-ID: <4F075204.3040408@eu.citrix.com>
Date: Fri, 6 Jan 2012 14:56:52 -0500
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Hui Lv <hui.lv@intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
In-Reply-To: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"raistlin@linux.it" <raistlin@linux.it>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry for the delay; just catching up after the Christmas holidays.

On 26/12/11 03:46, Hui Lv wrote:
> @@ -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")
The standard idiom for this kind of message would be:
  WARNING [what's wrong]
  [What you're doing about it]

So the last sentence of the warning should be:
   Setting ratelimit_us to 1000 * tslice_ms

(Grammatically, you could say "Forcing ratelimit..." but I think "force" 
is too strong in this case.)

Other than that, I'm happy with it, if everyone else is:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 19:57:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 19: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 1RjFuT-000112-Nm; Fri, 06 Jan 2012 19:57:05 +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 1RjFuS-00010u-AZ
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 19:57:04 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1325879817!9427855!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTQ2OTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6473 invoked from network); 6 Jan 2012 19:56:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 19:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320642000"; d="scan'208";a="20639468"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 14:56:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 14:56:56 -0500
Received: from [0.0.0.0] (latara.uk.xensource.com [10.80.16.67])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q06JuqkD018856;
	Fri, 6 Jan 2012 11:56:53 -0800
Message-ID: <4F075204.3040408@eu.citrix.com>
Date: Fri, 6 Jan 2012 14:56:52 -0500
From: George Dunlap <george.dunlap@eu.citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Hui Lv <hui.lv@intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
In-Reply-To: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"raistlin@linux.it" <raistlin@linux.it>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry for the delay; just catching up after the Christmas holidays.

On 26/12/11 03:46, Hui Lv wrote:
> @@ -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")
The standard idiom for this kind of message would be:
  WARNING [what's wrong]
  [What you're doing about it]

So the last sentence of the warning should be:
   Setting ratelimit_us to 1000 * tslice_ms

(Grammatically, you could say "Forcing ratelimit..." but I think "force" 
is too strong in this case.)

Other than that, I'm happy with it, if everyone else is:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 20:06:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20:06:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjG2n-0001Ku-S7; Fri, 06 Jan 2012 20:05:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RjG2l-0001Kl-Df
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:05:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325880330!9997055!1
X-Originating-IP: [209.85.212.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 25531 invoked from network); 6 Jan 2012 20:05:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 20:05:31 -0000
Received: by wico1 with SMTP id o1so3291604wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 12:05: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=u3Ulu4hwulIAWXE/kxMm5pOOH2KC1ex5wb4/mY2VE/w=;
	b=iS04OXJya23hYi5+POSAYA2s53Tx4bdaP4zKTBiqegkzG6xWAy0mWTbS4WGzrEwSEY
	3oOn4cQMRIqjv0XDrMdAKlShBJ1Bg1V+YU5+nH7rqnl103oUgDU3/G8LnldQJv6khVCc
	wgi6DrPbiXN6sZ2kfbTNAeCLV1ppAo5KjXWu0=
MIME-Version: 1.0
Received: by 10.180.19.138 with SMTP id f10mr15917670wie.3.1325880330497; Fri,
	06 Jan 2012 12:05:30 -0800 (PST)
Received: by 10.216.186.7 with HTTP; Fri, 6 Jan 2012 12:05:30 -0800 (PST)
In-Reply-To: <1325776621.2728.7.camel@Solace>
References: <1325776621.2728.7.camel@Solace>
Date: Fri, 6 Jan 2012 15:05:30 -0500
X-Google-Sender-Auth: 4MFJHuVm_G0NAtPtdZSOSivSkXA
Message-ID: <CAFLBxZahhTNEYthuPDGkkSZtmK3BWaQjZdarXmpjB74FPmjZxQ@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] [PATCHv3] 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

Dario,

This patch has word-wrap damage.  I'm afraid you're going to have to
either send it as an attachment or use hg email.

 -George

On Thu, Jan 5, 2012 at 10:17 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.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> diff -r efaa28639a71 xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/common/sched_sedf.c =A0 Thu Jan 05 15:02:30 2012 +0100
> @@ -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)
>
> @@ -71,34 +63,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 /* =3D worst 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
> @@ -165,18 +158,17 @@ 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{
> @@ -185,11 +177,6 @@ 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 =A0* Iterate through all elements to find our "hole" and on our w=
ay
> =A0 =A0 =A0* update all the other scores.
> @@ -200,25 +187,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 }
>
> @@ -228,29 +208,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}
>
> @@ -259,7 +224,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}
>
> @@ -272,8 +237,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));
> @@ -286,13 +249,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}
>
> @@ -310,30 +272,28 @@ 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}
>
> @@ -361,12 +321,12 @@ static void *sedf_alloc_vdata(const stru
>
> =A0 =A0 inf->vcpu =3D v;
>
> - =A0 =A0/* Every VCPU gets an equal share of extratime by default. */
> + =A0 =A0/* Every VCPU gets an equal share of extratime by default */
> =A0 =A0 inf->deadl_abs =A0 =3D 0;
> =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 =A0/* Upon creation all domain are best-effort. */
> + =A0 =A0/* Upon creation all domain are best-effort */
> =A0 =A0 inf->period =A0 =A0 =A0=3D WEIGHT_PERIOD;
> =A0 =A0 inf->slice =A0 =A0 =A0 =3D 0;
>
> @@ -450,21 +410,19 @@ static void desched_edf_dom(s_time_t now
> =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 * runq.
> - =A0 =A0 */
> + =A0 =A0/* Scheduling decisions which don't remove the running domain fr=
om
> + =A0 =A0 * the runq */
> =A0 =A0 if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
> =A0 =A0 =A0 =A0 return;
>
> =A0 =A0 __del_from_queue(d);
> -
> +
> =A0 =A0 /*
> =A0 =A0 =A0* Manage bookkeeping (i.e. calculate next deadline, memorise
> =A0 =A0 =A0* overrun-time of slice) of finished domains.
> @@ -475,30 +433,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) )
> @@ -518,8 +476,6 @@ 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 =A0* Check for the first elements of the waitqueue, whether their
> =A0 =A0 =A0* next period has already started.
> @@ -527,41 +483,32 @@ static void update_queues(
> =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) ||
> @@ -571,18 +518,18 @@ static void update_queues(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* We missed the deadline or the slice was alre=
ady 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 =A0* If we are still behind: modulo arithmetic, f=
orce deadline
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* to be in future and aligned to period border=
s.
> @@ -593,7 +540,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);
> @@ -603,17 +550,17 @@ 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}
>
>
> -/* 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 */
> +/*
> + * removes a domain from the head of the according extraQ and
> + * 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);
> @@ -622,29 +569,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
> @@ -653,51 +596,59 @@ 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/*
> + =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/*
> + =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/*
> + =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) )
> @@ -729,8 +680,10 @@ 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/*
> + =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;
> @@ -744,7 +697,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]);
> @@ -794,11 +747,13 @@ static void sedf_deinit(const struct sch
> =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*/
> +/*
> + * 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
> + */
> =A0static struct task_slice sedf_do_schedule(
> =A0 =A0 const struct scheduler *ops, s_time_t now, bool_t tasklet_work_sc=
heduled)
> =A0{
> @@ -811,13 +766,15 @@ 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/*
> + =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;
>
> @@ -826,7 +783,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
> @@ -836,10 +793,12 @@ 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/*
> + =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)))) )
> @@ -855,9 +814,11 @@ 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/*
> + =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 }
> @@ -869,14 +830,18 @@ 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/*
> + =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 */
> =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/*
> + =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",
> @@ -896,9 +861,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;
>
> @@ -920,7 +882,8 @@ static void sedf_sleep(const struct sche
> =A0}
>
>
> -/* 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
> =A0* things to mention are: admission control is taking place nowhere at
> =A0* the moment, so we can't be sure, whether it is safe to wake the doma=
in
> =A0* up at all. Anyway, even if it is safe (total cpu usage <=3D100%) the=
re are
> @@ -994,27 +957,31 @@ 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/*
> + =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/*
> + =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 {
> @@ -1024,28 +991,31 @@ 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/*
> + =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}
> @@ -1068,15 +1038,17 @@ 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)
> @@ -1085,26 +1057,25 @@ 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]));
> =A0 =A0 case DOMAIN_EXTRA_UTIL:
> =A0 =A0 =A0 =A0 /* Check whether we want the L0 extraq. Don't
> - =A0 =A0 =A0 =A0 * switch if both domains want L1 extraq.
> - =A0 =A0 =A0 =A0 */
> + =A0 =A0 =A0 =A0 * switch if both domains want L1 extraq. */
> =A0 =A0 =A0 =A0 return !!(other_inf->status & EXTRA_WANT_PEN_Q);
> =A0 =A0 case DOMAIN_IDLE:
> =A0 =A0 =A0 =A0 return 1;
> @@ -1118,18 +1089,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;
> @@ -1138,28 +1102,25 @@ 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/*
> + =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);
> @@ -1168,8 +1129,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
> @@ -1179,8 +1139,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
> @@ -1190,24 +1149,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;
> @@ -1216,12 +1164,14 @@ 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/*
> + =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);
> @@ -1266,7 +1216,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;
> @@ -1341,16 +1291,18 @@ 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, int nr_cpus, int *su=
mw, s_time_t *sumt)
> =A0{
> =A0 =A0 struct vcpu *p;
> =A0 =A0 struct domain =A0 =A0 =A0*d;
> =A0 =A0 unsigned int =A0 =A0 =A0 =A0cpu;
>
> - =A0 =A0/* Sum across all weights. Notice that no runq locking is needed
> + =A0 =A0/*
> + =A0 =A0 * Sum across all weights. Notice that no runq locking is needed
> =A0 =A0 =A0* here: the caller holds sedf_priv_info.lock and we're not cha=
nging
> - =A0 =A0 * anything that is accessed during scheduling. */
> + =A0 =A0 * anything that is accessed during scheduling.
> + =A0 =A0 */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1365,11 +1317,14 @@ 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/*
> + =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
> @@ -1380,9 +1335,11 @@ 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. Unlike abo=
ve, we
> + =A0 =A0/*
> + =A0 =A0 * Adjust all slices (and periods) to the new weight. Unlike abo=
ve, we
> =A0 =A0 =A0* need to take thr runq lock for the various VCPUs: we're mody=
fing
> - =A0 =A0 * slice and period which are referenced during scheduling. */
> + =A0 =A0 * slice and period which are referenced during scheduling.
> + =A0 =A0 */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1410,7 +1367,7 @@ 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 sedf_priv_info *prv =3D SEDF_PRIV(ops);
> @@ -1421,23 +1378,22 @@ static int sedf_adjust(const struct sche
> =A0 =A0 struct vcpu *v;
> =A0 =A0 int rc =3D 0;
>
> - =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/* Serialize against the pluggable scheduler lock to protect from
> + =A0 =A0/*
> + =A0 =A0 * Serialize against the pluggable scheduler lock to protect from
> =A0 =A0 =A0* concurrent updates. We need to take the runq lock for the VC=
PUs
> =A0 =A0 =A0* as well, since we are touching extraweight, weight, slice and
> =A0 =A0 =A0* period. As in sched_credit2.c, runq locks nest inside the
> - =A0 =A0 * pluggable scheduler lock. */
> + =A0 =A0 * pluggable scheduler lock.
> + =A0 =A0 */
> =A0 =A0 spin_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/*
> + =A0 =A0 =A0 =A0 * These are used in sedf_adjust_weights() but have to b=
e allocated in
> =A0 =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 =A0 * within our prv->lock.
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 if ( !sumw || !sumt )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 /* Check for errors here, the _getinfo branch doe=
sn't care */
> @@ -1445,7 +1401,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =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 =A0 =A0 =A0 =A0 rc =3D -EINVAL;
> @@ -1457,7 +1413,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 /* (Here and everywhere in the fo=
llowing) IRQs are already off,
> @@ -1472,7 +1428,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 vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D op->u.se=
df.weight;
> @@ -1495,7 +1451,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Time-driven domains. */
> + =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 vcpu_schedule_lock(v);
> @@ -1545,7 +1501,6 @@ out:
> =A0 =A0 xfree(sumt);
> =A0 =A0 xfree(sumw);
>
> - =A0 =A0PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
> =A0 =A0 return rc;
> =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 Jan 06 20:06:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20:06:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjG2n-0001Ku-S7; Fri, 06 Jan 2012 20:05:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1RjG2l-0001Kl-Df
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:05:40 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1325880330!9997055!1
X-Originating-IP: [209.85.212.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 25531 invoked from network); 6 Jan 2012 20:05:31 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 20:05:31 -0000
Received: by wico1 with SMTP id o1so3291604wic.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 12:05: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=u3Ulu4hwulIAWXE/kxMm5pOOH2KC1ex5wb4/mY2VE/w=;
	b=iS04OXJya23hYi5+POSAYA2s53Tx4bdaP4zKTBiqegkzG6xWAy0mWTbS4WGzrEwSEY
	3oOn4cQMRIqjv0XDrMdAKlShBJ1Bg1V+YU5+nH7rqnl103oUgDU3/G8LnldQJv6khVCc
	wgi6DrPbiXN6sZ2kfbTNAeCLV1ppAo5KjXWu0=
MIME-Version: 1.0
Received: by 10.180.19.138 with SMTP id f10mr15917670wie.3.1325880330497; Fri,
	06 Jan 2012 12:05:30 -0800 (PST)
Received: by 10.216.186.7 with HTTP; Fri, 6 Jan 2012 12:05:30 -0800 (PST)
In-Reply-To: <1325776621.2728.7.camel@Solace>
References: <1325776621.2728.7.camel@Solace>
Date: Fri, 6 Jan 2012 15:05:30 -0500
X-Google-Sender-Auth: 4MFJHuVm_G0NAtPtdZSOSivSkXA
Message-ID: <CAFLBxZahhTNEYthuPDGkkSZtmK3BWaQjZdarXmpjB74FPmjZxQ@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] [PATCHv3] 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

Dario,

This patch has word-wrap damage.  I'm afraid you're going to have to
either send it as an attachment or use hg email.

 -George

On Thu, Jan 5, 2012 at 10:17 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.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>
> diff -r efaa28639a71 xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/common/sched_sedf.c =A0 Thu Jan 05 15:02:30 2012 +0100
> @@ -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)
>
> @@ -71,34 +63,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 /* =3D worst 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
> @@ -165,18 +158,17 @@ 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{
> @@ -185,11 +177,6 @@ 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 =A0* Iterate through all elements to find our "hole" and on our w=
ay
> =A0 =A0 =A0* update all the other scores.
> @@ -200,25 +187,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 }
>
> @@ -228,29 +208,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}
>
> @@ -259,7 +224,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}
>
> @@ -272,8 +237,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));
> @@ -286,13 +249,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}
>
> @@ -310,30 +272,28 @@ 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}
>
> @@ -361,12 +321,12 @@ static void *sedf_alloc_vdata(const stru
>
> =A0 =A0 inf->vcpu =3D v;
>
> - =A0 =A0/* Every VCPU gets an equal share of extratime by default. */
> + =A0 =A0/* Every VCPU gets an equal share of extratime by default */
> =A0 =A0 inf->deadl_abs =A0 =3D 0;
> =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 =A0/* Upon creation all domain are best-effort. */
> + =A0 =A0/* Upon creation all domain are best-effort */
> =A0 =A0 inf->period =A0 =A0 =A0=3D WEIGHT_PERIOD;
> =A0 =A0 inf->slice =A0 =A0 =A0 =3D 0;
>
> @@ -450,21 +410,19 @@ static void desched_edf_dom(s_time_t now
> =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 * runq.
> - =A0 =A0 */
> + =A0 =A0/* Scheduling decisions which don't remove the running domain fr=
om
> + =A0 =A0 * the runq */
> =A0 =A0 if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
> =A0 =A0 =A0 =A0 return;
>
> =A0 =A0 __del_from_queue(d);
> -
> +
> =A0 =A0 /*
> =A0 =A0 =A0* Manage bookkeeping (i.e. calculate next deadline, memorise
> =A0 =A0 =A0* overrun-time of slice) of finished domains.
> @@ -475,30 +433,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) )
> @@ -518,8 +476,6 @@ 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 =A0* Check for the first elements of the waitqueue, whether their
> =A0 =A0 =A0* next period has already started.
> @@ -527,41 +483,32 @@ static void update_queues(
> =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) ||
> @@ -571,18 +518,18 @@ static void update_queues(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* We missed the deadline or the slice was alre=
ady 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 =A0* If we are still behind: modulo arithmetic, f=
orce deadline
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* to be in future and aligned to period border=
s.
> @@ -593,7 +540,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);
> @@ -603,17 +550,17 @@ 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}
>
>
> -/* 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 */
> +/*
> + * removes a domain from the head of the according extraQ and
> + * 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);
> @@ -622,29 +569,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
> @@ -653,51 +596,59 @@ 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/*
> + =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/*
> + =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/*
> + =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) )
> @@ -729,8 +680,10 @@ 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/*
> + =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;
> @@ -744,7 +697,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]);
> @@ -794,11 +747,13 @@ static void sedf_deinit(const struct sch
> =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*/
> +/*
> + * 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
> + */
> =A0static struct task_slice sedf_do_schedule(
> =A0 =A0 const struct scheduler *ops, s_time_t now, bool_t tasklet_work_sc=
heduled)
> =A0{
> @@ -811,13 +766,15 @@ 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/*
> + =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;
>
> @@ -826,7 +783,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
> @@ -836,10 +793,12 @@ 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/*
> + =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)))) )
> @@ -855,9 +814,11 @@ 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/*
> + =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 }
> @@ -869,14 +830,18 @@ 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/*
> + =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 */
> =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/*
> + =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",
> @@ -896,9 +861,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;
>
> @@ -920,7 +882,8 @@ static void sedf_sleep(const struct sche
> =A0}
>
>
> -/* 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
> =A0* things to mention are: admission control is taking place nowhere at
> =A0* the moment, so we can't be sure, whether it is safe to wake the doma=
in
> =A0* up at all. Anyway, even if it is safe (total cpu usage <=3D100%) the=
re are
> @@ -994,27 +957,31 @@ 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/*
> + =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/*
> + =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 {
> @@ -1024,28 +991,31 @@ 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/*
> + =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}
> @@ -1068,15 +1038,17 @@ 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)
> @@ -1085,26 +1057,25 @@ 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]));
> =A0 =A0 case DOMAIN_EXTRA_UTIL:
> =A0 =A0 =A0 =A0 /* Check whether we want the L0 extraq. Don't
> - =A0 =A0 =A0 =A0 * switch if both domains want L1 extraq.
> - =A0 =A0 =A0 =A0 */
> + =A0 =A0 =A0 =A0 * switch if both domains want L1 extraq. */
> =A0 =A0 =A0 =A0 return !!(other_inf->status & EXTRA_WANT_PEN_Q);
> =A0 =A0 case DOMAIN_IDLE:
> =A0 =A0 =A0 =A0 return 1;
> @@ -1118,18 +1089,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;
> @@ -1138,28 +1102,25 @@ 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/*
> + =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);
> @@ -1168,8 +1129,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
> @@ -1179,8 +1139,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
> @@ -1190,24 +1149,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;
> @@ -1216,12 +1164,14 @@ 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/*
> + =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);
> @@ -1266,7 +1216,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;
> @@ -1341,16 +1291,18 @@ 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, int nr_cpus, int *su=
mw, s_time_t *sumt)
> =A0{
> =A0 =A0 struct vcpu *p;
> =A0 =A0 struct domain =A0 =A0 =A0*d;
> =A0 =A0 unsigned int =A0 =A0 =A0 =A0cpu;
>
> - =A0 =A0/* Sum across all weights. Notice that no runq locking is needed
> + =A0 =A0/*
> + =A0 =A0 * Sum across all weights. Notice that no runq locking is needed
> =A0 =A0 =A0* here: the caller holds sedf_priv_info.lock and we're not cha=
nging
> - =A0 =A0 * anything that is accessed during scheduling. */
> + =A0 =A0 * anything that is accessed during scheduling.
> + =A0 =A0 */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1365,11 +1317,14 @@ 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/*
> + =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
> @@ -1380,9 +1335,11 @@ 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. Unlike abo=
ve, we
> + =A0 =A0/*
> + =A0 =A0 * Adjust all slices (and periods) to the new weight. Unlike abo=
ve, we
> =A0 =A0 =A0* need to take thr runq lock for the various VCPUs: we're mody=
fing
> - =A0 =A0 * slice and period which are referenced during scheduling. */
> + =A0 =A0 * slice and period which are referenced during scheduling.
> + =A0 =A0 */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1410,7 +1367,7 @@ 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 sedf_priv_info *prv =3D SEDF_PRIV(ops);
> @@ -1421,23 +1378,22 @@ static int sedf_adjust(const struct sche
> =A0 =A0 struct vcpu *v;
> =A0 =A0 int rc =3D 0;
>
> - =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/* Serialize against the pluggable scheduler lock to protect from
> + =A0 =A0/*
> + =A0 =A0 * Serialize against the pluggable scheduler lock to protect from
> =A0 =A0 =A0* concurrent updates. We need to take the runq lock for the VC=
PUs
> =A0 =A0 =A0* as well, since we are touching extraweight, weight, slice and
> =A0 =A0 =A0* period. As in sched_credit2.c, runq locks nest inside the
> - =A0 =A0 * pluggable scheduler lock. */
> + =A0 =A0 * pluggable scheduler lock.
> + =A0 =A0 */
> =A0 =A0 spin_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/*
> + =A0 =A0 =A0 =A0 * These are used in sedf_adjust_weights() but have to b=
e allocated in
> =A0 =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 =A0 * within our prv->lock.
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 if ( !sumw || !sumt )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 /* Check for errors here, the _getinfo branch doe=
sn't care */
> @@ -1445,7 +1401,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =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 =A0 =A0 =A0 =A0 rc =3D -EINVAL;
> @@ -1457,7 +1413,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 /* (Here and everywhere in the fo=
llowing) IRQs are already off,
> @@ -1472,7 +1428,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 vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D op->u.se=
df.weight;
> @@ -1495,7 +1451,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Time-driven domains. */
> + =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 vcpu_schedule_lock(v);
> @@ -1545,7 +1501,6 @@ out:
> =A0 =A0 xfree(sumt);
> =A0 =A0 xfree(sumw);
>
> - =A0 =A0PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
> =A0 =A0 return rc;
> =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 Jan 06 20:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjGVY-0001el-LZ; Fri, 06 Jan 2012 20:35: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 1RjGVX-0001eB-Ge
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1510 invoked from network); 6 Jan 2012 20:35:17 -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;
	6 Jan 2012 20:35:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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, 6 Jan 2012 20:35: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
	1RjGVQ-0003ar-Ra; Fri, 06 Jan 2012 20:35:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVQ-0001WY-Qk;
	Fri, 06 Jan 2012 20:35:16 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:34:59 +0000
Message-ID: <1325882107-5794-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] 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 Jan 06 20:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjGVb-0001fD-32; Fri, 06 Jan 2012 20:35:27 +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 1RjGVZ-0001eG-5L
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1522 invoked from network); 6 Jan 2012 20:35:18 -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;
	6 Jan 2012 20:35:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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; Fri, 6 Jan 2012 20:35:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RjGVS-0003ax-1m; Fri, 06 Jan 2012 20:35:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVS-0001We-0v;
	Fri, 06 Jan 2012 20:35:18 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:00 +0000
Message-ID: <1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: move a lot more includes into
	libxl_internal.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

Move a lot of
  #include <stdfoo.h>
from individual files into libxl_internal.h.  This helps avoid
portability mistakes where necessary system headers are omitted from
individual files, and is also of course a convenience when developing.

Also add
  #include "libxl_osdeps.h" /* must come before any other headers */
to the top of most libxl*.c files, so that anyone who adds any headers
before libxl_internal.h will put the in the right place.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c            |   15 ---------------
 tools/libxl/libxl_blktap2.c    |    4 +---
 tools/libxl/libxl_bootloader.c |    7 +------
 tools/libxl/libxl_cpuid.c      |    2 ++
 tools/libxl/libxl_create.c     |   13 +++----------
 tools/libxl/libxl_device.c     |   10 +---------
 tools/libxl/libxl_dm.c         |   10 +---------
 tools/libxl/libxl_dom.c        |   11 +----------
 tools/libxl/libxl_exec.c       |   13 +------------
 tools/libxl/libxl_flask.c      |    8 +-------
 tools/libxl/libxl_internal.c   |   10 +---------
 tools/libxl/libxl_internal.h   |   22 +++++++++++++++++++---
 tools/libxl/libxl_json.c       |    4 +---
 tools/libxl/libxl_linux.c      |    2 +-
 tools/libxl/libxl_netbsd.c     |    2 +-
 tools/libxl/libxl_noblktap2.c  |    2 ++
 tools/libxl/libxl_nocpuid.c    |    2 ++
 tools/libxl/libxl_paths.c      |    1 +
 tools/libxl/libxl_pci.c        |   16 +---------------
 tools/libxl/libxl_qmp.c        |    4 +---
 tools/libxl/libxl_utils.c      |   13 +------------
 tools/libxl/libxl_uuid.c       |    2 +-
 tools/libxl/libxl_xshelp.c     |    8 +-------
 tools/libxl/libxlu_cfg.c       |    2 ++
 tools/libxl/libxlu_cfg_i.h     |    1 +
 tools/libxl/libxlu_disk.c      |    1 +
 tools/libxl/libxlu_disk_i.h    |    2 ++
 27 files changed, 51 insertions(+), 136 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2b8f8f4..2d3e8cd 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -16,21 +16,6 @@
 
 #include "libxl_osdeps.h"
 
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <sys/select.h>
-#include <sys/wait.h>
-#include <sys/time.h>
-#include <signal.h>
-#include <unistd.h> /* for write, unlink and close */
-#include <stdint.h>
-#include <inttypes.h>
-#include <assert.h>
-
 #include "libxl_internal.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
index acf4110..2c40182 100644
--- a/tools/libxl/libxl_blktap2.c
+++ b/tools/libxl/libxl_blktap2.c
@@ -12,13 +12,11 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
 
 #include "tap-ctl.h"
 
-#include <string.h>
-
 int libxl__blktap_enabled(libxl__gc *gc)
 {
     const char *msg;
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index ce83b8e..2da1d90 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -12,15 +12,10 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <unistd.h>
-#include <fcntl.h>
 #include <termios.h>
 
-#include <sys/stat.h>
-#include <sys/types.h>
-
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 56a00cd..dcdb9d02 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -10,6 +10,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #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 ebf2ed7..9a6a94a 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -15,20 +15,13 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include <xenctrl.h>
-#include <xc_dom.h>
-#include <xenguest.h>
-#include <assert.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
+#include <xc_dom.h>
+#include <xenguest.h>
+
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
     int i;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 9b1fc57..5d05e90 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -14,15 +14,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <string.h>
-#include <stdio.h>
-#include <sys/time.h> /* for struct timeval */
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <unistd.h>
-#include <fcntl.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..f0bf014 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -15,15 +15,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-#include <signal.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include <assert.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..b2259f8 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -13,22 +13,13 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <stdio.h>
-#include <assert.h>
 #include <glob.h>
-#include <inttypes.h>
-#include <string.h>
-#include <sys/mman.h>
-#include <sys/time.h> /* for struct timeval */
-#include <sys/stat.h> /* for stat */
-#include <unistd.h> /* for sleep(2) */
 
 #include <xenctrl.h>
 #include <xc_dom.h>
 #include <xenguest.h>
-#include <fcntl.h>
 
 #include <xen/hvm/hvm_info_table.h>
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 52d40d1..b10e79f 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -15,18 +15,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <assert.h>
-#include <sys/types.h>
-#include <sys/wait.h>
-#include <signal.h> /* for SIGKILL */
-#include <fcntl.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
index 6b548dd..23f2476 100644
--- a/tools/libxl/libxl_flask.c
+++ b/tools/libxl/libxl_flask.c
@@ -7,13 +7,7 @@
  *  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_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index cfa8c61..49b0dab 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -13,15 +13,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <sys/mman.h>
-#include <unistd.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1bca869..d681d73 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,17 +17,33 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <stdint.h>
+#include <assert.h>
+#include <dirent.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <pthread.h>
+#include <signal.h>
 #include <stdarg.h>
+#include <stddef.h>
+#include <stdint.h>
+#include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
-#include <pthread.h>
+#include <unistd.h>
+
+#include <sys/mman.h>
+#include <sys/select.h>
+#include <sys/stat.h>
 #include <sys/time.h>
+#include <sys/types.h>
+#include <sys/wait.h>
 
 #include <xs.h>
 #include <xenctrl.h>
+
 #include "xentoollog.h"
 
 #include <xen/io/xenbus.h>
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index c0f869e..6ff2910 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -12,10 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <assert.h>
-#include <string.h>
 #include <math.h>
 
 #include <yajl/yajl_parse.h>
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 786c6b5..925248b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -13,7 +13,7 @@
  * GNU Lesser General Public License for more details.
  */
  
-#include <sys/stat.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
  
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 1e8d622..9e0ed6d 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -13,7 +13,7 @@
  * GNU Lesser General Public License for more details.
  */
  
-#include <sys/stat.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
index 3307551..246b0de 100644
--- a/tools/libxl/libxl_noblktap2.c
+++ b/tools/libxl/libxl_noblktap2.c
@@ -12,6 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #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 2e9490c..9e52f8d 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -10,6 +10,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #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 e7bd1a2..a95d29f 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -12,6 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
 #include "_libxl_paths.h"
 
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 8b2a1c5..c3828f6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -14,21 +14,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <sys/types.h>
-#include <fcntl.h>
-#include <sys/select.h>
-#include <sys/mman.h>
-#include <sys/wait.h>
-#include <sys/stat.h>
-#include <signal.h>
-#include <unistd.h> /* for write, unlink and close */
-#include <inttypes.h>
-#include <dirent.h>
-#include <assert.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 3dfa43a..61d9769 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,12 +18,10 @@
  * Specification, see in the QEMU repository.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <unistd.h>
 #include <sys/un.h>
 #include <sys/queue.h>
-#include <fcntl.h>
 
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index d36c737..dbe8891 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -13,20 +13,9 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <stdint.h>
-#include <string.h>
-#include <xs.h>
-#include <xenctrl.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #include <ctype.h>
-#include <errno.h>
-#include <sys/stat.h>
-#include <sys/types.h>
-#include <unistd.h>
-#include <assert.h>
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index 80ab789..7c18d71 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -12,7 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <libxl_uuid.h>
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index ea835e2..6958d21 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -13,13 +13,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <string.h>
-#include <stddef.h>
-#include <stdio.h>
-#include <stdarg.h>
-#include <inttypes.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 0d1c5d3..e3659c7 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -16,6 +16,8 @@
  */
 
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #include <limits.h>
 
 #include "libxlu_internal.h"
diff --git a/tools/libxl/libxlu_cfg_i.h b/tools/libxl/libxlu_cfg_i.h
index ea6a326..54d033c 100644
--- a/tools/libxl/libxlu_cfg_i.h
+++ b/tools/libxl/libxlu_cfg_i.h
@@ -18,6 +18,7 @@
 #ifndef LIBXLU_CFG_I_H
 #define LIBXLU_CFG_I_H
 
+#include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxlu_internal.h"
 #include "libxlu_cfg_y.h"
 
diff --git a/tools/libxl/libxlu_disk.c b/tools/libxl/libxlu_disk.c
index 88b79ac..6cd86e9 100644
--- a/tools/libxl/libxlu_disk.c
+++ b/tools/libxl/libxlu_disk.c
@@ -1,3 +1,4 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxlu_internal.h"
 #include "libxlu_disk_l.h"
 #include "libxlu_disk_i.h"
diff --git a/tools/libxl/libxlu_disk_i.h b/tools/libxl/libxlu_disk_i.h
index 4fccd4a..37246f2 100644
--- a/tools/libxl/libxlu_disk_i.h
+++ b/tools/libxl/libxlu_disk_i.h
@@ -1,6 +1,8 @@
 #ifndef LIBXLU_DISK_I_H
 #define LIBXLU_DISK_I_H
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #include "libxlu_internal.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 Jan 06 20:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjGVY-0001el-LZ; Fri, 06 Jan 2012 20:35: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 1RjGVX-0001eB-Ge
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1510 invoked from network); 6 Jan 2012 20:35:17 -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;
	6 Jan 2012 20:35:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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, 6 Jan 2012 20:35: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
	1RjGVQ-0003ar-Ra; Fri, 06 Jan 2012 20:35:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVQ-0001WY-Qk;
	Fri, 06 Jan 2012 20:35:16 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:34:59 +0000
Message-ID: <1325882107-5794-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] 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 Jan 06 20:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjGVb-0001fD-32; Fri, 06 Jan 2012 20:35:27 +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 1RjGVZ-0001eG-5L
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1522 invoked from network); 6 Jan 2012 20:35:18 -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;
	6 Jan 2012 20:35:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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; Fri, 6 Jan 2012 20:35:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RjGVS-0003ax-1m; Fri, 06 Jan 2012 20:35:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVS-0001We-0v;
	Fri, 06 Jan 2012 20:35:18 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:00 +0000
Message-ID: <1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: move a lot more includes into
	libxl_internal.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

Move a lot of
  #include <stdfoo.h>
from individual files into libxl_internal.h.  This helps avoid
portability mistakes where necessary system headers are omitted from
individual files, and is also of course a convenience when developing.

Also add
  #include "libxl_osdeps.h" /* must come before any other headers */
to the top of most libxl*.c files, so that anyone who adds any headers
before libxl_internal.h will put the in the right place.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c            |   15 ---------------
 tools/libxl/libxl_blktap2.c    |    4 +---
 tools/libxl/libxl_bootloader.c |    7 +------
 tools/libxl/libxl_cpuid.c      |    2 ++
 tools/libxl/libxl_create.c     |   13 +++----------
 tools/libxl/libxl_device.c     |   10 +---------
 tools/libxl/libxl_dm.c         |   10 +---------
 tools/libxl/libxl_dom.c        |   11 +----------
 tools/libxl/libxl_exec.c       |   13 +------------
 tools/libxl/libxl_flask.c      |    8 +-------
 tools/libxl/libxl_internal.c   |   10 +---------
 tools/libxl/libxl_internal.h   |   22 +++++++++++++++++++---
 tools/libxl/libxl_json.c       |    4 +---
 tools/libxl/libxl_linux.c      |    2 +-
 tools/libxl/libxl_netbsd.c     |    2 +-
 tools/libxl/libxl_noblktap2.c  |    2 ++
 tools/libxl/libxl_nocpuid.c    |    2 ++
 tools/libxl/libxl_paths.c      |    1 +
 tools/libxl/libxl_pci.c        |   16 +---------------
 tools/libxl/libxl_qmp.c        |    4 +---
 tools/libxl/libxl_utils.c      |   13 +------------
 tools/libxl/libxl_uuid.c       |    2 +-
 tools/libxl/libxl_xshelp.c     |    8 +-------
 tools/libxl/libxlu_cfg.c       |    2 ++
 tools/libxl/libxlu_cfg_i.h     |    1 +
 tools/libxl/libxlu_disk.c      |    1 +
 tools/libxl/libxlu_disk_i.h    |    2 ++
 27 files changed, 51 insertions(+), 136 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2b8f8f4..2d3e8cd 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -16,21 +16,6 @@
 
 #include "libxl_osdeps.h"
 
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <sys/select.h>
-#include <sys/wait.h>
-#include <sys/time.h>
-#include <signal.h>
-#include <unistd.h> /* for write, unlink and close */
-#include <stdint.h>
-#include <inttypes.h>
-#include <assert.h>
-
 #include "libxl_internal.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
index acf4110..2c40182 100644
--- a/tools/libxl/libxl_blktap2.c
+++ b/tools/libxl/libxl_blktap2.c
@@ -12,13 +12,11 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
 
 #include "tap-ctl.h"
 
-#include <string.h>
-
 int libxl__blktap_enabled(libxl__gc *gc)
 {
     const char *msg;
diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
index ce83b8e..2da1d90 100644
--- a/tools/libxl/libxl_bootloader.c
+++ b/tools/libxl/libxl_bootloader.c
@@ -12,15 +12,10 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <unistd.h>
-#include <fcntl.h>
 #include <termios.h>
 
-#include <sys/stat.h>
-#include <sys/types.h>
-
 #include "libxl_internal.h"
 
 #define XENCONSOLED_BUF_SIZE 16
diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
index 56a00cd..dcdb9d02 100644
--- a/tools/libxl/libxl_cpuid.c
+++ b/tools/libxl/libxl_cpuid.c
@@ -10,6 +10,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #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 ebf2ed7..9a6a94a 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -15,20 +15,13 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include <xenctrl.h>
-#include <xc_dom.h>
-#include <xenguest.h>
-#include <assert.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
+#include <xc_dom.h>
+#include <xenguest.h>
+
 void libxl_domain_config_dispose(libxl_domain_config *d_config)
 {
     int i;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 9b1fc57..5d05e90 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -14,15 +14,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <string.h>
-#include <stdio.h>
-#include <sys/time.h> /* for struct timeval */
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <unistd.h>
-#include <fcntl.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..f0bf014 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -15,15 +15,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-#include <signal.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include <assert.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..b2259f8 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -13,22 +13,13 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <stdio.h>
-#include <assert.h>
 #include <glob.h>
-#include <inttypes.h>
-#include <string.h>
-#include <sys/mman.h>
-#include <sys/time.h> /* for struct timeval */
-#include <sys/stat.h> /* for stat */
-#include <unistd.h> /* for sleep(2) */
 
 #include <xenctrl.h>
 #include <xc_dom.h>
 #include <xenguest.h>
-#include <fcntl.h>
 
 #include <xen/hvm/hvm_info_table.h>
 
diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 52d40d1..b10e79f 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -15,18 +15,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <assert.h>
-#include <sys/types.h>
-#include <sys/wait.h>
-#include <signal.h> /* for SIGKILL */
-#include <fcntl.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
index 6b548dd..23f2476 100644
--- a/tools/libxl/libxl_flask.c
+++ b/tools/libxl/libxl_flask.c
@@ -7,13 +7,7 @@
  *  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_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index cfa8c61..49b0dab 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -13,15 +13,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-
-#include <sys/types.h>
-#include <sys/stat.h>
-#include <fcntl.h>
-#include <sys/mman.h>
-#include <unistd.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1bca869..d681d73 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -17,17 +17,33 @@
 #ifndef LIBXL_INTERNAL_H
 #define LIBXL_INTERNAL_H
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <stdint.h>
+#include <assert.h>
+#include <dirent.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <pthread.h>
+#include <signal.h>
 #include <stdarg.h>
+#include <stddef.h>
+#include <stdint.h>
+#include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
-#include <pthread.h>
+#include <unistd.h>
+
+#include <sys/mman.h>
+#include <sys/select.h>
+#include <sys/stat.h>
 #include <sys/time.h>
+#include <sys/types.h>
+#include <sys/wait.h>
 
 #include <xs.h>
 #include <xenctrl.h>
+
 #include "xentoollog.h"
 
 #include <xen/io/xenbus.h>
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index c0f869e..6ff2910 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -12,10 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <assert.h>
-#include <string.h>
 #include <math.h>
 
 #include <yajl/yajl_parse.h>
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 786c6b5..925248b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -13,7 +13,7 @@
  * GNU Lesser General Public License for more details.
  */
  
-#include <sys/stat.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
  
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 1e8d622..9e0ed6d 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -13,7 +13,7 @@
  * GNU Lesser General Public License for more details.
  */
  
-#include <sys/stat.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
index 3307551..246b0de 100644
--- a/tools/libxl/libxl_noblktap2.c
+++ b/tools/libxl/libxl_noblktap2.c
@@ -12,6 +12,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #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 2e9490c..9e52f8d 100644
--- a/tools/libxl/libxl_nocpuid.c
+++ b/tools/libxl/libxl_nocpuid.c
@@ -10,6 +10,8 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #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 e7bd1a2..a95d29f 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -12,6 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxl_internal.h"
 #include "_libxl_paths.h"
 
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 8b2a1c5..c3828f6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -14,21 +14,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <sys/types.h>
-#include <fcntl.h>
-#include <sys/select.h>
-#include <sys/mman.h>
-#include <sys/wait.h>
-#include <sys/stat.h>
-#include <signal.h>
-#include <unistd.h> /* for write, unlink and close */
-#include <inttypes.h>
-#include <dirent.h>
-#include <assert.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 3dfa43a..61d9769 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,12 +18,10 @@
  * Specification, see in the QEMU repository.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
-#include <unistd.h>
 #include <sys/un.h>
 #include <sys/queue.h>
-#include <fcntl.h>
 
 #include <yajl/yajl_gen.h>
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index d36c737..dbe8891 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -13,20 +13,9 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <stdint.h>
-#include <string.h>
-#include <xs.h>
-#include <xenctrl.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #include <ctype.h>
-#include <errno.h>
-#include <sys/stat.h>
-#include <sys/types.h>
-#include <unistd.h>
-#include <assert.h>
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
index 80ab789..7c18d71 100644
--- a/tools/libxl/libxl_uuid.c
+++ b/tools/libxl/libxl_uuid.c
@@ -12,7 +12,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include <libxl_uuid.h>
 
diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
index ea835e2..6958d21 100644
--- a/tools/libxl/libxl_xshelp.c
+++ b/tools/libxl/libxl_xshelp.c
@@ -13,13 +13,7 @@
  * GNU Lesser General Public License for more details.
  */
 
-#include "libxl_osdeps.h"
-
-#include <string.h>
-#include <stddef.h>
-#include <stdio.h>
-#include <stdarg.h>
-#include <inttypes.h>
+#include "libxl_osdeps.h" /* must come before any other headers */
 
 #include "libxl_internal.h"
 
diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 0d1c5d3..e3659c7 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -16,6 +16,8 @@
  */
 
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #include <limits.h>
 
 #include "libxlu_internal.h"
diff --git a/tools/libxl/libxlu_cfg_i.h b/tools/libxl/libxlu_cfg_i.h
index ea6a326..54d033c 100644
--- a/tools/libxl/libxlu_cfg_i.h
+++ b/tools/libxl/libxlu_cfg_i.h
@@ -18,6 +18,7 @@
 #ifndef LIBXLU_CFG_I_H
 #define LIBXLU_CFG_I_H
 
+#include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxlu_internal.h"
 #include "libxlu_cfg_y.h"
 
diff --git a/tools/libxl/libxlu_disk.c b/tools/libxl/libxlu_disk.c
index 88b79ac..6cd86e9 100644
--- a/tools/libxl/libxlu_disk.c
+++ b/tools/libxl/libxlu_disk.c
@@ -1,3 +1,4 @@
+#include "libxl_osdeps.h" /* must come before any other headers */
 #include "libxlu_internal.h"
 #include "libxlu_disk_l.h"
 #include "libxlu_disk_i.h"
diff --git a/tools/libxl/libxlu_disk_i.h b/tools/libxl/libxlu_disk_i.h
index 4fccd4a..37246f2 100644
--- a/tools/libxl/libxlu_disk_i.h
+++ b/tools/libxl/libxlu_disk_i.h
@@ -1,6 +1,8 @@
 #ifndef LIBXLU_DISK_I_H
 #define LIBXLU_DISK_I_H
 
+#include "libxl_osdeps.h" /* must come before any other headers */
+
 #include "libxlu_internal.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 Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVb-0001fO-HW; Fri, 06 Jan 2012 20:35:27 +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 1RjGVa-0001eO-0b
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1551 invoked from network); 6 Jan 2012 20:35:20 -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;
	6 Jan 2012 20:35:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871215"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 20:35: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
	1RjGVT-0003b1-Gv; Fri, 06 Jan 2012 20:35:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVT-0001Wi-GA;
	Fri, 06 Jan 2012 20:35:19 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:01 +0000
Message-ID: <1325882107-5794-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Provide more formal
	libxl__ctx_lock and _unlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 the only official interface for the ctx lock was the
CTX_LOCK and CTX_UNLOCK convenience macros, which assume and use "ctx"
from the surrounding scope.

Instead, provide libxl__ctx_lock and _unlock functions which can be
used by these convenience macros, and other callers who have
nonstandard requirements.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   23 +++++++++++++----------
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d681d73..1dadf15 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -115,7 +115,8 @@ struct libxl__ctx {
     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.
+      /* Always use libxl__ctx_lock and _unlock (or the convenience
+       * macors 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
@@ -749,16 +750,18 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 /* 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)
+static inline void libxl__ctx_lock(libxl_ctx *ctx) {
+    int r = pthread_mutex_lock(&ctx->lock);
+    assert(!r);
+}
 
-#define CTX_UNLOCK do {                                 \
-        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
-        assert(!mutex_r);                               \
-    } while(0)
-        
+static inline void libxl__ctx_unlock(libxl_ctx *ctx) {
+    int r = pthread_mutex_unlock(&ctx->lock);
+    assert(!r);
+}
+
+#define CTX_LOCK (libxl__ctx_lock(CTX))
+#define CTX_UNLOCK (libxl__ctx_unlock(CTX))
 
 
 /*
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVb-0001fO-HW; Fri, 06 Jan 2012 20:35:27 +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 1RjGVa-0001eO-0b
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1551 invoked from network); 6 Jan 2012 20:35:20 -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;
	6 Jan 2012 20:35:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871215"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 20:35: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
	1RjGVT-0003b1-Gv; Fri, 06 Jan 2012 20:35:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVT-0001Wi-GA;
	Fri, 06 Jan 2012 20:35:19 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:01 +0000
Message-ID: <1325882107-5794-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Provide more formal
	libxl__ctx_lock and _unlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 the only official interface for the ctx lock was the
CTX_LOCK and CTX_UNLOCK convenience macros, which assume and use "ctx"
from the surrounding scope.

Instead, provide libxl__ctx_lock and _unlock functions which can be
used by these convenience macros, and other callers who have
nonstandard requirements.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   23 +++++++++++++----------
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d681d73..1dadf15 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -115,7 +115,8 @@ struct libxl__ctx {
     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.
+      /* Always use libxl__ctx_lock and _unlock (or the convenience
+       * macors 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
@@ -749,16 +750,18 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 /* 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)
+static inline void libxl__ctx_lock(libxl_ctx *ctx) {
+    int r = pthread_mutex_lock(&ctx->lock);
+    assert(!r);
+}
 
-#define CTX_UNLOCK do {                                 \
-        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
-        assert(!mutex_r);                               \
-    } while(0)
-        
+static inline void libxl__ctx_unlock(libxl_ctx *ctx) {
+    int r = pthread_mutex_unlock(&ctx->lock);
+    assert(!r);
+}
+
+#define CTX_LOCK (libxl__ctx_lock(CTX))
+#define CTX_UNLOCK (libxl__ctx_unlock(CTX))
 
 
 /*
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVf-0001h0-Hi; Fri, 06 Jan 2012 20:35: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 1RjGVe-0001en-3y
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1626 invoked from network); 6 Jan 2012 20:35:24 -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;
	6 Jan 2012 20:35:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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; Fri, 6 Jan 2012 20:35: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
	1RjGVX-0003b7-Ii; Fri, 06 Jan 2012 20:35:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVX-0001Wt-Hy;
	Fri, 06 Jan 2012 20:35:23 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 6 Jan 2012 20:35:03 +0000
Message-ID: <1325882107-5794-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] DROP: 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

*** THIS PATCH WILL PROBABLY BE DROPPED as it is no longer needed
    in the current version of later patches. ***

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>
---
 tools/libxl/libxl.h          |    2 +-
 tools/libxl/libxl_internal.c |    2 +-
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_qmp.c      |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 723eac2..9ae7cea 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 49b0dab..cc98d86 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -53,7 +53,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 1dadf15..df1dfde 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -190,7 +190,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.
@@ -744,7 +744,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)
 
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 61d9769..58f5283 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -528,7 +528,7 @@ static int qmp_send(libxl__qmp_handler *qmp,
 
     rc = qmp->last_id_used;
 out:
-    libxl__free_all(&gc);
+    libxl__gc_cleanup(&gc);
     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 Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVf-0001h0-Hi; Fri, 06 Jan 2012 20:35: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 1RjGVe-0001en-3y
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1626 invoked from network); 6 Jan 2012 20:35:24 -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;
	6 Jan 2012 20:35:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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; Fri, 6 Jan 2012 20:35: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
	1RjGVX-0003b7-Ii; Fri, 06 Jan 2012 20:35:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVX-0001Wt-Hy;
	Fri, 06 Jan 2012 20:35:23 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 6 Jan 2012 20:35:03 +0000
Message-ID: <1325882107-5794-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] DROP: 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

*** THIS PATCH WILL PROBABLY BE DROPPED as it is no longer needed
    in the current version of later patches. ***

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>
---
 tools/libxl/libxl.h          |    2 +-
 tools/libxl/libxl_internal.c |    2 +-
 tools/libxl/libxl_internal.h |    4 ++--
 tools/libxl/libxl_qmp.c      |    2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 723eac2..9ae7cea 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 49b0dab..cc98d86 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -53,7 +53,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 1dadf15..df1dfde 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -190,7 +190,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.
@@ -744,7 +744,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)
 
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 61d9769..58f5283 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -528,7 +528,7 @@ static int qmp_send(libxl__qmp_handler *qmp,
 
     rc = qmp->last_id_used;
 out:
-    libxl__free_all(&gc);
+    libxl__gc_cleanup(&gc);
     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 Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVh-0001iD-Vd; Fri, 06 Jan 2012 20:35:33 +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 1RjGVg-0001fL-Mo
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1642 invoked from network); 6 Jan 2012 20:35:26 -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;
	6 Jan 2012 20:35:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 20:35: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
	1RjGVZ-0003bA-RX; Fri, 06 Jan 2012 20:35:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVZ-0001Wx-Qb;
	Fri, 06 Jan 2012 20:35:25 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:04 +0000
Message-ID: <1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] 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    |  748 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  204 ++++++++++++
 tools/libxl/libxl_internal.h |  266 +++++++++++++++-
 6 files changed, 1252 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 78bc589..8bdc308 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -47,7 +47,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 8ecce26..c0024af 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,6 +45,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_rindex = 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);
@@ -79,9 +89,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_rindex);
+    free(ctx->watch_slots);
+
+    GC_FREE;
     free(ctx);
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 9ae7cea..c0a4373 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"
@@ -223,6 +224,9 @@ enum {
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
     ERROR_NOPARAVIRT = -10,
+    ERROR_NOT_READY = -11,
+    ERROR_OSEVENT_REG_FAIL = -12,
+    ERROR_BUFFERFULL = -13,
 };
 
 #define LIBXL_VERSION 0
@@ -648,6 +652,8 @@ const char *libxl_xenpaging_dir_path(void);
 /* misc */
 int libxl_fd_set_cloexec(int fd);
 
+#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..e71ab66
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,748 @@
+/*
+ * 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->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;
+
+ 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__egc *egc, libxl__ev_fd *ev,
+                             int fd, short events, short revents)
+{
+    libxl__gc *gc = &egc->gc;
+
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "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(egc, 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 rc;
+
+    /*
+     * 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_rindex
+         * 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_rindex.
+         */
+
+        int maxfd = 0;
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+            if (!efd->events)
+                continue;
+            if (efd->fd >= maxfd)
+                maxfd = efd->fd + 1;
+        }
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_rindex_allocd < maxfd) {
+            assert(maxfd < INT_MAX / sizeof(int) / 2);
+            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+            memset(newarray + CTX->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
+            CTX->fd_rindex = newarray;
+            CTX->fd_rindex_allocd = maxfd;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            assert(efd->fd < CTX->fd_rindex_allocd);
+            CTX->fd_rindex[efd->fd] = used;
+        }
+        used++;
+    }
+    rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    *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;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static int afterpoll_check_fd(libxl_ctx *ctx,
+                              const struct pollfd *fds, int nfds,
+                              int fd, int events)
+    /* returns mask of events which were requested and occurred */
+{
+    if (fd >= ctx->fd_rindex_allocd)
+        /* added after we went into poll, have to try again */
+        return 0;
+
+    int slot = ctx->fd_rindex[fd];
+
+    if (slot >= nfds)
+        /* stale slot entry; again, added afterwards */
+        return 0;
+
+    if (fds[slot].fd != fd)
+        /* again, stale slot entry */
+        return 0;
+
+    int revents = fds[slot].revents & events;
+    /* we mask in case requested events have changed */
+    
+    return revents;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    libxl__ev_fd *efd;
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+
+        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        if (revents)
+            efd->func(egc, 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(egc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    EGC_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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(egc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+{
+    libxl__ev_time *ev = for_libxl;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(egc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func)
+{
+    libxl__gc *gc = &egc->gc;
+
+    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);
+}
+
+void libxl__egc_cleanup(libxl__egc *egc)
+{
+    libxl__gc_cleanup(&egc->gc);
+}
+
+/*
+ * 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..a7e8240
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,204 @@
+/*
+ * 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.
+ *
+ * (Callers inside libxl may not call libxl_osevent_... functions.)
+ */
+
+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.  (It is therefore not possible
+   * to have multiple threads simultaneously polling using this
+   * interface.)
+   *
+   * 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 df1dfde..fdfcf9d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -35,6 +35,7 @@
 #include <unistd.h>
 
 #include <sys/mman.h>
+#include <sys/poll.h>
 #include <sys/select.h>
 #include <sys/stat.h>
 #include <sys/time.h>
@@ -109,6 +110,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__egc libxl__egc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* all private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    int fd;
+    short events;
+    void *for_app_reg;
+    libxl__ev_fd_callback *func;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__egc *egc, 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__egc *egc, 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;
@@ -127,6 +188,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_rindex_allocd;
+    int *fd_rindex; /* 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 */
@@ -157,12 +235,17 @@ 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;
+};
+
+struct libxl__egc {
+    /* for event-generating functions only */
+    struct libxl__gc gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -228,9 +311,141 @@ _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.
+ *      FUNC will be called with the context locked (with CTX_LOCK).
+ *
+ *  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__egc*, 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(egc, msg, errnoval, type) \
+    libxl__event_disaster(egc, 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);
@@ -596,6 +811,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)
 
@@ -733,6 +950,49 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 
 /*
+ * Calling context and GC for event-generating functions:
+ *
+ * These are for use by parts of libxl which directly or indirectly
+ * call libxl__event_occurred.  These contain a gc but also a list of
+ * deferred events.
+ *
+ * Most code in libxlshould not need to initialise their own egc.
+ * Even functions which generate specific kinds of events don't need
+ * to - rather, they will be passed an egc into their own callback
+ * function and should just use the one they're given.
+ *
+ * A handy idiom for functions taking an egc is:
+ *     libxl__gc *gc = &egc->gc;
+ *
+ * Functions using LIBXL__INIT_EGC may *not* generally be called from
+ * within libxl, because libxl__egc_cleanup may call back into the
+ * application.  This should be documented near the function
+ * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
+ *
+ * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
+ * with the ctx *unlocked*.  So the right pattern has the EGC_...
+ * macro calls on the outside of the CTX_... ones.
+ */
+
+/* egc initialisation and destruction: */
+
+#define LIBXL_INIT_EGC(egc,ctx) do{             \
+        LIBXL_INIT_GC((egc).gc,ctx);            \
+        /* list of occurred events tbd */       \
+    } while(0)
+
+_hidden void libxl__egc_cleanup(libxl__egc *egc);
+
+/* convenience macros: */
+
+#define EGC_INIT(ctx)                       \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
+    libxl__gc *gc = &egc->gc
+
+#define EGC_FREE           libxl__egc_cleanup(egc)
+
+
+/*
  * Convenience macros.
  */
 
-- 
1.7.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 Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVh-0001iD-Vd; Fri, 06 Jan 2012 20:35:33 +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 1RjGVg-0001fL-Mo
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1642 invoked from network); 6 Jan 2012 20:35:26 -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;
	6 Jan 2012 20:35:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871218"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 20:35: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
	1RjGVZ-0003bA-RX; Fri, 06 Jan 2012 20:35:25 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVZ-0001Wx-Qb;
	Fri, 06 Jan 2012 20:35:25 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:04 +0000
Message-ID: <1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] 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    |  748 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  204 ++++++++++++
 tools/libxl/libxl_internal.h |  266 +++++++++++++++-
 6 files changed, 1252 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 78bc589..8bdc308 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -47,7 +47,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 8ecce26..c0024af 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,6 +45,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_rindex = 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);
@@ -79,9 +89,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_rindex);
+    free(ctx->watch_slots);
+
+    GC_FREE;
     free(ctx);
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 9ae7cea..c0a4373 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"
@@ -223,6 +224,9 @@ enum {
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
     ERROR_NOPARAVIRT = -10,
+    ERROR_NOT_READY = -11,
+    ERROR_OSEVENT_REG_FAIL = -12,
+    ERROR_BUFFERFULL = -13,
 };
 
 #define LIBXL_VERSION 0
@@ -648,6 +652,8 @@ const char *libxl_xenpaging_dir_path(void);
 /* misc */
 int libxl_fd_set_cloexec(int fd);
 
+#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..e71ab66
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,748 @@
+/*
+ * 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->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;
+
+ 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__egc *egc, libxl__ev_fd *ev,
+                             int fd, short events, short revents)
+{
+    libxl__gc *gc = &egc->gc;
+
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "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(egc, 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 rc;
+
+    /*
+     * 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_rindex
+         * 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_rindex.
+         */
+
+        int maxfd = 0;
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+            if (!efd->events)
+                continue;
+            if (efd->fd >= maxfd)
+                maxfd = efd->fd + 1;
+        }
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_rindex_allocd < maxfd) {
+            assert(maxfd < INT_MAX / sizeof(int) / 2);
+            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+            memset(newarray + CTX->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
+            CTX->fd_rindex = newarray;
+            CTX->fd_rindex_allocd = maxfd;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            assert(efd->fd < CTX->fd_rindex_allocd);
+            CTX->fd_rindex[efd->fd] = used;
+        }
+        used++;
+    }
+    rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    *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;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static int afterpoll_check_fd(libxl_ctx *ctx,
+                              const struct pollfd *fds, int nfds,
+                              int fd, int events)
+    /* returns mask of events which were requested and occurred */
+{
+    if (fd >= ctx->fd_rindex_allocd)
+        /* added after we went into poll, have to try again */
+        return 0;
+
+    int slot = ctx->fd_rindex[fd];
+
+    if (slot >= nfds)
+        /* stale slot entry; again, added afterwards */
+        return 0;
+
+    if (fds[slot].fd != fd)
+        /* again, stale slot entry */
+        return 0;
+
+    int revents = fds[slot].revents & events;
+    /* we mask in case requested events have changed */
+    
+    return revents;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    libxl__ev_fd *efd;
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+
+        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        if (revents)
+            efd->func(egc, 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(egc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    EGC_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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(egc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+{
+    libxl__ev_time *ev = for_libxl;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(egc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func)
+{
+    libxl__gc *gc = &egc->gc;
+
+    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);
+}
+
+void libxl__egc_cleanup(libxl__egc *egc)
+{
+    libxl__gc_cleanup(&egc->gc);
+}
+
+/*
+ * 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..a7e8240
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,204 @@
+/*
+ * 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.
+ *
+ * (Callers inside libxl may not call libxl_osevent_... functions.)
+ */
+
+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.  (It is therefore not possible
+   * to have multiple threads simultaneously polling using this
+   * interface.)
+   *
+   * 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 df1dfde..fdfcf9d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -35,6 +35,7 @@
 #include <unistd.h>
 
 #include <sys/mman.h>
+#include <sys/poll.h>
 #include <sys/select.h>
 #include <sys/stat.h>
 #include <sys/time.h>
@@ -109,6 +110,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__egc libxl__egc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* all private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    int fd;
+    short events;
+    void *for_app_reg;
+    libxl__ev_fd_callback *func;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__egc *egc, 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__egc *egc, 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;
@@ -127,6 +188,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_rindex_allocd;
+    int *fd_rindex; /* 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 */
@@ -157,12 +235,17 @@ 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;
+};
+
+struct libxl__egc {
+    /* for event-generating functions only */
+    struct libxl__gc gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -228,9 +311,141 @@ _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.
+ *      FUNC will be called with the context locked (with CTX_LOCK).
+ *
+ *  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__egc*, 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(egc, msg, errnoval, type) \
+    libxl__event_disaster(egc, 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);
@@ -596,6 +811,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)
 
@@ -733,6 +950,49 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 
 /*
+ * Calling context and GC for event-generating functions:
+ *
+ * These are for use by parts of libxl which directly or indirectly
+ * call libxl__event_occurred.  These contain a gc but also a list of
+ * deferred events.
+ *
+ * Most code in libxlshould not need to initialise their own egc.
+ * Even functions which generate specific kinds of events don't need
+ * to - rather, they will be passed an egc into their own callback
+ * function and should just use the one they're given.
+ *
+ * A handy idiom for functions taking an egc is:
+ *     libxl__gc *gc = &egc->gc;
+ *
+ * Functions using LIBXL__INIT_EGC may *not* generally be called from
+ * within libxl, because libxl__egc_cleanup may call back into the
+ * application.  This should be documented near the function
+ * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
+ *
+ * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
+ * with the ctx *unlocked*.  So the right pattern has the EGC_...
+ * macro calls on the outside of the CTX_... ones.
+ */
+
+/* egc initialisation and destruction: */
+
+#define LIBXL_INIT_EGC(egc,ctx) do{             \
+        LIBXL_INIT_GC((egc).gc,ctx);            \
+        /* list of occurred events tbd */       \
+    } while(0)
+
+_hidden void libxl__egc_cleanup(libxl__egc *egc);
+
+/* convenience macros: */
+
+#define EGC_INIT(ctx)                       \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
+    libxl__gc *gc = &egc->gc
+
+#define EGC_FREE           libxl__egc_cleanup(egc)
+
+
+/*
  * Convenience macros.
  */
 
-- 
1.7.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 Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVT-0001eH-Sf; Fri, 06 Jan 2012 20:35:19 +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 1RjGVS-0001e6-Ep
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1474 invoked from network); 6 Jan 2012 20:35:12 -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;
	6 Jan 2012 20:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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, 6 Jan 2012 20:35: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
	1RjGVL-0003ak-01; Fri, 06 Jan 2012 20:35:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVK-0001WK-Tc;
	Fri, 06 Jan 2012 20:35:10 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:34:57 +0000
Message-ID: <1325882107-5794-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 v6 00/10] libxl: 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 series is the latest revision of my event handling API.  It
includes changes in response to a number of comments made.  It also
includes a few new consequential patches and unrelated
fixes/improvements, as usual.

The most significant difference is the new "libxl__egc" type which is
used instead of libxl__gc by event-generating functions.  This
prevents accidental violation of the callback reentrancy rules.

I'm still working on this series.  At the moment I'm working on
providing asynchronous calls for long-running operations; this
requires more support machinery which is still not finalised.

Of the resulting patches in this series,

These should perhaps go in soon:
 01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
 03/10 libxl: move a lot more includes into libxl_internal.h
 04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
 05/10 libxl: Fix leaks on context init failure
 09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec

This one has now been tested and can go in IMO:
 02/10 xenstore: New function xs_path_is_subpath

These are the meat:
 07/10 libxl: New API for providing OS events to libxl
 08/10 libxl: New event generation API
 10/10 libxl: Permit multithreaded event waiting

And this one has become rendered obsolete.  If we are to retain the
new libxl__egc structure, I will drop it.  Otherwise it may still be
needed, and it's disruptive, which is why I haven't dropped it from my
series yet:
 06/10 DROP: libxl: rename libxl__free_all

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVd-0001g7-4a; Fri, 06 Jan 2012 20:35:29 +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 1RjGVb-0001ea-V4
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1596 invoked from network); 6 Jan 2012 20:35:21 -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;
	6 Jan 2012 20:35:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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; Fri, 6 Jan 2012 20:35: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
	1RjGVV-0003b4-Eu; Fri, 06 Jan 2012 20:35:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVV-0001Wp-E6;
	Fri, 06 Jan 2012 20:35:21 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:02 +0000
Message-ID: <1325882107-5794-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Fix leaks on context init 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

Several of the error exits from libxl_ctx_alloc leaked the context
struct itself and sometimes other resources too.

Fix this by using the standard "rc = ERROR_FOO; goto out" error
handling style throughout.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2d3e8cd..8ecce26 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -24,17 +24,17 @@
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags, xentoollog_logger * lg)
 {
-    libxl_ctx *ctx;
+    libxl_ctx *ctx = NULL;
     struct stat stat_buf;
     const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
+    int rc;
 
-    if (version != LIBXL_VERSION)
-        return ERROR_VERSION;
+    if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }
 
     ctx = malloc(sizeof(*ctx));
     if (!ctx) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed to allocate context\n");
-        return ERROR_NOMEM;
+        rc = ERROR_NOMEM; goto out;
     }
 
     memset(ctx, 0, sizeof(libxl_ctx));
@@ -48,14 +48,14 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     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);
-        return ERROR_FAIL;
+        rc = ERROR_FAIL; goto out;
     }
 
     ctx->xch = xc_interface_open(lg,lg,0);
     if (!ctx->xch) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
                         "cannot open libxc handle");
-        return ERROR_FAIL;
+        rc = ERROR_FAIL; goto out;
     }
 
     ctx->xsh = xs_daemon_open();
@@ -64,12 +64,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     if (!ctx->xsh) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
                         "cannot connect to xenstore");
-        xc_interface_close(ctx->xch);
-        return ERROR_FAIL;
+        rc = ERROR_FAIL; goto out;
     }
 
     *pctx = ctx;
     return 0;
+
+ out:
+    libxl_ctx_free(ctx);
+    *pctx = NULL;
+    return rc;
 }
 
 int libxl_ctx_free(libxl_ctx *ctx)
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVT-0001eH-Sf; Fri, 06 Jan 2012 20:35:19 +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 1RjGVS-0001e6-Ep
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1474 invoked from network); 6 Jan 2012 20:35:12 -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;
	6 Jan 2012 20:35:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871210"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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, 6 Jan 2012 20:35: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
	1RjGVL-0003ak-01; Fri, 06 Jan 2012 20:35:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVK-0001WK-Tc;
	Fri, 06 Jan 2012 20:35:10 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:34:57 +0000
Message-ID: <1325882107-5794-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 v6 00/10] libxl: 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 series is the latest revision of my event handling API.  It
includes changes in response to a number of comments made.  It also
includes a few new consequential patches and unrelated
fixes/improvements, as usual.

The most significant difference is the new "libxl__egc" type which is
used instead of libxl__gc by event-generating functions.  This
prevents accidental violation of the callback reentrancy rules.

I'm still working on this series.  At the moment I'm working on
providing asynchronous calls for long-running operations; this
requires more support machinery which is still not finalised.

Of the resulting patches in this series,

These should perhaps go in soon:
 01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
 03/10 libxl: move a lot more includes into libxl_internal.h
 04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
 05/10 libxl: Fix leaks on context init failure
 09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec

This one has now been tested and can go in IMO:
 02/10 xenstore: New function xs_path_is_subpath

These are the meat:
 07/10 libxl: New API for providing OS events to libxl
 08/10 libxl: New event generation API
 10/10 libxl: Permit multithreaded event waiting

And this one has become rendered obsolete.  If we are to retain the
new libxl__egc structure, I will drop it.  Otherwise it may still be
needed, and it's disruptive, which is why I haven't dropped it from my
series yet:
 06/10 DROP: libxl: rename libxl__free_all

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVd-0001g7-4a; Fri, 06 Jan 2012 20:35:29 +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 1RjGVb-0001ea-V4
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1596 invoked from network); 6 Jan 2012 20:35:21 -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;
	6 Jan 2012 20:35:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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; Fri, 6 Jan 2012 20:35: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
	1RjGVV-0003b4-Eu; Fri, 06 Jan 2012 20:35:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVV-0001Wp-E6;
	Fri, 06 Jan 2012 20:35:21 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:02 +0000
Message-ID: <1325882107-5794-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Fix leaks on context init 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

Several of the error exits from libxl_ctx_alloc leaked the context
struct itself and sometimes other resources too.

Fix this by using the standard "rc = ERROR_FOO; goto out" error
handling style throughout.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c |   20 ++++++++++++--------
 1 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2d3e8cd..8ecce26 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -24,17 +24,17 @@
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
                     unsigned flags, xentoollog_logger * lg)
 {
-    libxl_ctx *ctx;
+    libxl_ctx *ctx = NULL;
     struct stat stat_buf;
     const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
+    int rc;
 
-    if (version != LIBXL_VERSION)
-        return ERROR_VERSION;
+    if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }
 
     ctx = malloc(sizeof(*ctx));
     if (!ctx) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed to allocate context\n");
-        return ERROR_NOMEM;
+        rc = ERROR_NOMEM; goto out;
     }
 
     memset(ctx, 0, sizeof(libxl_ctx));
@@ -48,14 +48,14 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     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);
-        return ERROR_FAIL;
+        rc = ERROR_FAIL; goto out;
     }
 
     ctx->xch = xc_interface_open(lg,lg,0);
     if (!ctx->xch) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
                         "cannot open libxc handle");
-        return ERROR_FAIL;
+        rc = ERROR_FAIL; goto out;
     }
 
     ctx->xsh = xs_daemon_open();
@@ -64,12 +64,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     if (!ctx->xsh) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
                         "cannot connect to xenstore");
-        xc_interface_close(ctx->xch);
-        return ERROR_FAIL;
+        rc = ERROR_FAIL; goto out;
     }
 
     *pctx = ctx;
     return 0;
+
+ out:
+    libxl_ctx_free(ctx);
+    *pctx = NULL;
+    return rc;
 }
 
 int libxl_ctx_free(libxl_ctx *ctx)
-- 
1.7.2.5


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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVn-0001ks-4F; Fri, 06 Jan 2012 20:35:39 +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 1RjGVk-0001gy-P2
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1732 invoked from network); 6 Jan 2012 20:35:30 -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;
	6 Jan 2012 20:35:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20: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; Fri, 6 Jan 2012 20:35:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RjGVd-0003bG-SF; Fri, 06 Jan 2012 20:35:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVd-0001X5-RO;
	Fri, 06 Jan 2012 20:35:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:06 +0000
Message-ID: <1325882107-5794-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: introduce libxl_fd_set_nonblock,
	rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 want a function for setting fds to nonblocking, so introduce one.

This is a very similar requirement to that for libxl_fd_set_cloexec,
so make it common with that.

While we're at it, fix a few deficiences that make this latter
function less desirable than it could be:
 * Change the return from 0/-1 (like a syscall) to a libxl error code
 * Take a boolean parameter for turning the flag on and off
 * Log on error (and so, take a ctx for this purpose)

Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
such errors are highly unlikely.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c      |   33 ++++++++++++++++++++++++++-------
 tools/libxl/libxl.h      |    6 +++++-
 tools/libxl/libxl_qmp.c  |    3 ++-
 tools/libxl/xl_cmdimpl.c |    3 ++-
 4 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f6370d4..42b64d8 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3647,19 +3647,38 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
-int libxl_fd_set_cloexec(int fd)
+static int fd_set_flags(libxl_ctx *ctx, int fd,
+                        int fcntlgetop, int fcntlsetop, const char *fl,
+                        int flagmask, int set_p)
 {
-    int flags = 0;
+    int flags, r;
 
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
+    flags = fcntl(fd, fcntlgetop);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_GET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
+
+    if (set_p)
+        flags |= flagmask;
+    else
+        flags &= ~flagmask;
+
+    r = fcntl(fd, fcntlsetop, flags);
+    if (r == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_SET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+
+    return 0;
 }
 
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
+  { return fd_set_flags(ctx,fd, F_GETFD,F_SETFD,"FD", FD_CLOEXEC, cloexec); }
+
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
+  { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 97ca25e..5396ba8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -613,7 +613,11 @@ const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
 /* misc */
-int libxl_fd_set_cloexec(int fd);
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
+  /* Each of these sets or clears the flag according to whether the
+   * 2nd parameter is nonzero.  On failure, they log, and
+   * return ERROR_FAIL, but also leave errno valid. */
 
 #include <libxl_event.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 58f5283..05df4d7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -324,7 +324,8 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl_fd_set_cloexec(qmp->qmp_fd);
+    ret = libxl_fd_set_cloexec(qmp->ctx, qmp->qmp_fd, 1);
+    if (ret) return -1;
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index a18c6b2..b88fc8a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1490,7 +1490,8 @@ static int create_domain(struct domain_create *dom_info)
             restore_fd = migrate_fd;
         } else {
             restore_fd = open(restore_file, O_RDONLY);
-            libxl_fd_set_cloexec(restore_fd);
+            rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
+            if (rc) return rc;
         }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
-- 
1.7.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 Jan 06 20:35:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVo-0001lz-OG; Fri, 06 Jan 2012 20:35:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RjGVm-0001i3-Uc
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1756 invoked from network); 6 Jan 2012 20:35:32 -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;
	6 Jan 2012 20:35:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871223"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 20:35: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
	1RjGVf-0003bJ-Vl; Fri, 06 Jan 2012 20:35:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVf-0001XC-Uz;
	Fri, 06 Jan 2012 20:35:31 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:07 +0000
Message-ID: <1325882107-5794-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Permit multithreaded event waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, the context would be locked whenever we were waiting in
libxl's own call to poll (waiting for operating system events).

This would mean that multiple simultaneous calls to libxl_event_wait
in different threads with different parameters would not work
properly.

If we simply unlock the context, it would be possible for another
thread to discover the occurrence of the event we were waiting for,
without us even waking up, and we would remain in poll.  So we need a
way to wake up other threads: a pipe, one for each thread in poll.

We also need to move some variables from globals in the ctx to be
per-polling-thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   18 +++-
 tools/libxl/libxl_event.c    |  196 ++++++++++++++++++++++++++++++++++--------
 tools/libxl/libxl_internal.h |   51 ++++++++++-
 3 files changed, 219 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42b64d8..b8167b3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -49,8 +49,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->osevent_hooks = 0;
 
-    ctx->fd_polls = 0;
-    ctx->fd_rindex = 0;
+    LIBXL_LIST_INIT(&ctx->pollers_event);
+    LIBXL_LIST_INIT(&ctx->pollers_idle);
+
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
 
@@ -61,6 +62,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    rc = libxl__poller_init(ctx, &ctx->poller_app);
+    if (rc) goto out;
+
     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);
@@ -135,8 +139,14 @@ 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_rindex);
+    libxl__poller_dispose(&ctx->poller_app);
+    assert(LIBXL_LIST_EMPTY(&ctx->pollers_event));
+    libxl__poller *poller, *poller_tmp;
+    LIBXL_LIST_FOREACH_SAFE(poller, &ctx->pollers_idle, entry, poller_tmp) {
+        libxl__poller_dispose(poller);
+        free(poller);
+    }
+
     free(ctx->watch_slots);
 
     discard_events(&ctx->occurred);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c42b565..704e734 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -509,9 +509,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
  * osevent poll
  */
 
-static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
-                               struct pollfd *fds, int *timeout_upd,
-                               struct timeval now)
+static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
+                               int *nfds_io, struct pollfd *fds,
+                               int *timeout_upd, struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -533,7 +533,7 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = 0;
+        int maxfd = poller->wakeup_pipe[0] + 1;
         LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
             if (!efd->events)
                 continue;
@@ -541,30 +541,39 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
                 maxfd = efd->fd + 1;
         }
         /* make sure our array is as big as *nfds_io */
-        if (CTX->fd_rindex_allocd < maxfd) {
+        if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
             if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + CTX->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
-            CTX->fd_rindex = newarray;
-            CTX->fd_rindex_allocd = maxfd;
+            memset(newarray + poller->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
+            poller->fd_rindex = newarray;
+            poller->fd_rindex_allocd = maxfd;
         }
     }
 
     int used = 0;
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-        if (!efd->events)
-            continue;
-        if (used < *nfds_io) {
-            fds[used].fd = efd->fd;
-            fds[used].events = efd->events;
-            fds[used].revents = 0;
-            assert(efd->fd < CTX->fd_rindex_allocd);
-            CTX->fd_rindex[efd->fd] = used;
-        }
-        used++;
-    }
+
+#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
+        if ((req_events)) {                                     \
+            if (used < *nfds_io) {                              \
+                fds[used].fd = (req_fd);                        \
+                fds[used].events = (req_events);                \
+                fds[used].revents = 0;                          \
+                assert((req_fd) < poller->fd_rindex_allocd);    \
+                poller->fd_rindex[(req_fd)] = used;             \
+            }                                                   \
+            used++;                                             \
+        }                                                       \
+    }while(0)
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
+        REQUIRE_FD(efd->fd, efd->events, efd);
+
+    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
+
+#undef REQUIRE_FD
+
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
     *nfds_io = used;
@@ -598,22 +607,23 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
+    int rc = beforepoll_internal(gc, &ctx->poller_app,
+                                 nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
 }
 
-static int afterpoll_check_fd(libxl_ctx *ctx,
+static int afterpoll_check_fd(libxl__poller *poller,
                               const struct pollfd *fds, int nfds,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= ctx->fd_rindex_allocd)
+    if (fd >= poller->fd_rindex_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = ctx->fd_rindex[fd];
+    int slot = poller->fd_rindex[fd];
 
     if (slot >= nfds)
         /* stale slot entry; again, added afterwards */
@@ -629,22 +639,31 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-static void afterpoll_internal(libxl__egc *egc,
+static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
     libxl__gc *gc = &egc->gc;
     libxl__ev_fd *efd;
 
+
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
 
-        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        int revents = afterpoll_check_fd(poller,fds,nfds, efd->fd,efd->events);
         if (revents)
             efd->func(egc, efd, efd->fd, efd->events, revents);
     }
 
+    if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
+        char buf[256];
+        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
+        if (r < 0)
+            if (errno != EINTR && errno != EWOULDBLOCK)
+                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+    }
+
     for (;;) {
         libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
         if (!etime)
@@ -666,7 +685,7 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    afterpoll_internal(egc, nfds, fds, now);
+    afterpoll_internal(egc, &ctx->poller_app, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
@@ -789,7 +808,10 @@ void libxl__event_occurred(libxl__egc *egc, libxl_event *event)
         LIBXL_TAILQ_INSERT_TAIL(&egc->occurred_for_callback, event, link);
         return;
     } else {
+        libxl__poller *poller;
         LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+        LIBXL_LIST_FOREACH(poller, &CTX->pollers_event, entry)
+            libxl__poller_wakeup(egc, poller);
     }
 }
 
@@ -857,7 +879,94 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
-static int eventloop_iteration(libxl__egc *egc) {
+/*
+ * Manipulation of pollers
+ */
+
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
+{
+    int r, rc;
+    p->fd_polls = 0;
+    p->fd_rindex = 0;
+
+    r = pipe(p->wakeup_pipe);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
+    if (rc) goto out;
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__poller_dispose(p);
+    return rc;
+}
+
+void libxl__poller_dispose(libxl__poller *p)
+{
+    if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
+    if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
+    free(p->fd_polls);
+    free(p->fd_rindex);
+}
+
+libxl__poller *libxl__poller_get(libxl_ctx *ctx)
+{
+    /* must be called with ctx locked */
+    int rc;
+
+    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
+    if (p)
+        return p;
+
+    p = malloc(sizeof(*p));
+    if (!p) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
+        return 0;
+    }
+    memset(p, 0, sizeof(*p));
+
+    rc = libxl__poller_init(ctx, p);
+    if (rc) return NULL;
+
+    return p;
+}
+
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
+{
+    LIBXL_LIST_INSERT_HEAD(&ctx->pollers_idle, p, entry);
+}
+
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
+{
+    static const char buf[1] = "";
+
+    for (;;) {
+        int r = write(p->wakeup_pipe[1], buf, 1);
+        if (r==1) return;
+        assert(r==-1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return;
+        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
+        return;
+    }
+}
+
+/*
+ * Main event loop iteration
+ */
+
+static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
+    /* The CTX must be locked EXACTLY ONCE so that this function
+     * can unlock it when it polls.
+     */
     libxl__gc *gc = &egc->gc;
     int rc;
     struct timeval now;
@@ -870,23 +979,27 @@ static int eventloop_iteration(libxl__egc *egc) {
     int timeout;
 
     for (;;) {
-        int nfds = CTX->fd_polls_allocd;
+        int nfds = poller->fd_polls_allocd;
         timeout = -1;
-        rc = beforepoll_internal(gc, &nfds, CTX->fd_polls, &timeout, now);
+        rc = beforepoll_internal(gc, poller, &nfds, poller->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);
+            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
 
         if (!newarray) { rc = ERROR_NOMEM; goto out; }
 
-        CTX->fd_polls = newarray;
-        CTX->fd_polls_allocd = nfds;
+        poller->fd_polls = newarray;
+        poller->fd_polls_allocd = nfds;
     }
 
-    rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+    CTX_UNLOCK;
+    rc = poll(poller->fd_polls, poller->fd_polls_allocd, timeout);
+    CTX_LOCK;
+
     if (rc < 0) {
         if (errno == EINTR)
             return 0; /* will go round again if caller requires */
@@ -899,7 +1012,8 @@ static int eventloop_iteration(libxl__egc *egc) {
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
-    afterpoll_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+    afterpoll_internal(egc, poller,
+                       poller->fd_polls_allocd, poller->fd_polls, now);
 
     CTX_UNLOCK;
 
@@ -913,15 +1027,19 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      libxl_event_predicate *pred, void *pred_user)
 {
     int rc;
+    libxl__poller *poller = NULL;
 
     EGC_INIT(ctx);
     CTX_LOCK;
 
+    poller = libxl__poller_get(ctx);
+    if (!poller) { rc = ERROR_FAIL; goto out; }
+
     for (;;) {
         rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
         if (rc != ERROR_NOT_READY) goto out;
 
-        rc = eventloop_iteration(egc);
+        rc = eventloop_iteration(egc, poller);
         if (rc) goto out;
 
         /* we unlock and cleanup the egc each time we go through this loop,
@@ -935,6 +1053,8 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     }
 
  out:
+    libxl__poller_put(ctx, poller);
+
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8cb6cdb..546f300 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -200,6 +200,33 @@ struct libxl__evgen_disk_eject {
 _hidden void
 libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
 
+typedef struct libxl__poller libxl__poller;
+struct libxl__poller {
+    /*
+     * These are used to allow other threads to wake up a thread which
+     * may be stuck in poll, because whatever it was waiting for
+     * hadn't happened yet.  Threads which generate events will write
+     * a byte to each pipe.  A threads which is waiting will empty its
+     * own pipe, and put its poller on the pollers_event list, before
+     * releasing the ctx lock and going into poll; when it comes out
+     * of poll it will take the poller off the pollers_event list.
+     *
+     * When a thread is done with a poller it should put it onto
+     * pollers_idle, where it can be reused later.
+     *
+     * The "poller_app" is never idle, but is sometimes on
+     * pollers_event.
+     */
+    LIBXL_LIST_ENTRY(libxl__poller) entry;
+
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
+    int fd_rindex_allocd;
+    int *fd_rindex; /* see libxl_osevent_beforepoll */
+
+    int wakeup_pipe[2]; /* 0 means no fd allocated */
+};
 
 struct libxl__ctx {
     xentoollog_logger *lg;
@@ -230,10 +257,9 @@ struct libxl__ctx {
       /* 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_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    libxl__poller poller_app; /* libxl_osevent_beforepoll and _afterpoll */
+    LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
+
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
     LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
 
@@ -517,6 +543,23 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
     libxl__event_disaster(egc, msg, errnoval, type, __FILE__,__LINE__,__func__)
 
 
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+void libxl__poller_dispose(libxl__poller *p);
+  /* Fills in, or disposes of the resources held by, a poller whose
+   * space the caller has allocated.  ctx must be locked.
+   */
+
+libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
+  /* Obtain a fresh poller from malloc or the idle list, and put it
+   * away again afterwards.  _get can fail, returning NULL.
+   * ctx must be locked. */
+
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
+  /* Notifies whoever is polling using p that they should wake up.
+   * ctx must be locked. */
+
+
 /* 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);
-- 
1.7.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 Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVm-0001kd-Na; Fri, 06 Jan 2012 20:35:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RjGVk-0001gn-7G
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1680 invoked from network); 6 Jan 2012 20:35:28 -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;
	6 Jan 2012 20:35:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871220"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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; Fri, 6 Jan 2012 20:35: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
	1RjGVb-0003bD-TX; Fri, 06 Jan 2012 20:35:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVb-0001X1-Sg;
	Fri, 06 Jan 2012 20:35:27 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:05 +0000
Message-ID: <1325882107-5794-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] 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          |  327 ++++++++++++++++++++++++++++++-----------
 tools/libxl/libxl.h          |   55 ++------
 tools/libxl/libxl_event.c    |  239 ++++++++++++++++++++++++++++---
 tools/libxl/libxl_event.h    |  184 +++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |   82 ++++++++++-
 tools/libxl/libxl_types.idl  |   34 ++++-
 tools/libxl/xl_cmdimpl.c     |  270 ++++++++++++++++++++---------------
 7 files changed, 912 insertions(+), 279 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c0024af..f6370d4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,8 +45,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_rindex = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -55,6 +58,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);
@@ -86,6 +92,20 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return rc;
 }
 
+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;
@@ -95,6 +115,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);
@@ -108,9 +135,12 @@ 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_rindex);
     free(ctx->watch_slots);
 
+    discard_events(&ctx->occurred);
+
     GC_FREE;
     free(ctx);
     return 0;
@@ -646,117 +676,175 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
     return ret;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl__gc *gc = &egc->gc;
+    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(egc, "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(egc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(egc, 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(egc, 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(egc, 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__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl__gc *gc = &egc->gc;
+    libxl_evgen_disk_eject *evg = (void*)w;
     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(egc, "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(egc, 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")) {
@@ -765,19 +853,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(egc, 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)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c0a4373..97ca25e 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"
@@ -300,51 +308,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 e71ab66..c42b565 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -143,7 +143,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);
@@ -508,9 +509,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_internal(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -522,9 +523,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_rindex
@@ -591,8 +589,18 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
     }
 
  out:
+    return rc;
+}
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
-    GC_FREE;
+    EGC_FREE;
     return rc;
 }
 
@@ -621,11 +629,11 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now)
+static void afterpoll_internal(libxl__egc *egc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now)
 {
-    EGC_INIT(ctx);
-    CTX_LOCK;
+    libxl__gc *gc = &egc->gc;
     libxl__ev_fd *efd;
 
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
@@ -651,12 +659,18 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(egc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_internal(egc, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -721,11 +735,10 @@ void libxl__event_disaster(libxl__egc *egc, 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";
@@ -734,9 +747,197 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
     exit(-1);
 }
 
+static void egc_run_callbacks(libxl__egc *egc)
+{
+    libxl__gc *gc = &egc->gc;
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
+}
+
 void libxl__egc_cleanup(libxl__egc *egc)
 {
-    libxl__gc_cleanup(&egc->gc);
+    libxl__gc *gc = &egc->gc;
+    libxl__gc_cleanup(gc);
+
+    egc_run_callbacks(egc);
+}
+
+/*
+ * 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__egc *egc, libxl_event *event)
+{
+    libxl__gc *gc = &egc->gc;
+
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__egc_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(&egc->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__egc *egc,
+                              libxl_event_type type, uint32_t domid)
+{
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_internal(libxl__egc *egc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user)
+{
+    libxl__gc *gc = &egc->gc;
+    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)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+static int eventloop_iteration(libxl__egc *egc) {
+    libxl__gc *gc = &egc->gc;
+    int rc;
+    struct timeval now;
+    
+    CTX_LOCK;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) goto out;
+
+    int timeout;
+
+    for (;;) {
+        int nfds = CTX->fd_polls_allocd;
+        timeout = -1;
+        rc = beforepoll_internal(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)
+            return 0; /* will go round again if caller requires */
+
+        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_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+    CTX_UNLOCK;
+
+    rc = 0;
+ out:
+    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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = eventloop_iteration(egc);
+        if (rc) goto out;
+
+        /* we unlock and cleanup the egc 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__egc_cleanup(egc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
 }
 
 /*
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index a7e8240..dd6e6ed 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,180 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ *
+ * (Callers inside libxl may not call libxl_event_check or _wait.)
+ */
+
+#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 +210,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;
  *      }
  *   }
  *
@@ -175,6 +349,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.h b/tools/libxl/libxl_internal.h
index fdfcf9d..8cb6cdb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -170,11 +170,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 libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -188,12 +222,16 @@ 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_rindex_allocd;
     int *fd_rindex; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -205,6 +243,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 */
@@ -245,6 +290,7 @@ struct libxl__gc {
 struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
+    struct libxl__event_list occurred_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -383,6 +429,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.
  */
 
 
@@ -426,6 +475,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__egc*, 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__egc*, 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(egc, type, domid)                              \
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
 _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
                                    libxl_event_type type /* may be 0 */,
                                    const char *file, int line,
@@ -438,6 +506,9 @@ _hidden void libxl__event_disaster(libxl__egc*, 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).
@@ -976,12 +1047,15 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 /* egc initialisation and destruction: */
 
-#define LIBXL_INIT_EGC(egc,ctx) do{             \
-        LIBXL_INIT_GC((egc).gc,ctx);            \
-        /* list of occurred events tbd */       \
+#define LIBXL_INIT_EGC(egc,ctx) do{                     \
+        LIBXL_INIT_GC((egc).gc,ctx);                    \
+        LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
+  /* Frees memory allocated within this egc's gc, and and report all
+   * occurred events via callback, if applicable.  May reenter the
+   * application; see restrictions above. */
 
 /* convenience macros: */
 
@@ -1004,7 +1078,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  */
 
 #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 78a1cc6..6728479 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"),
@@ -394,3 +389,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
     ("extratime", integer),
     ("weight", 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 8270f34..a18c6b2 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;
@@ -1651,14 +1678,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;
@@ -1695,92 +1722,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:
@@ -2263,6 +2304,7 @@ 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);
@@ -2277,37 +2319,39 @@ static void shutdown_domain(const char *p, int wait)
     }
 
     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 Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVn-0001ks-4F; Fri, 06 Jan 2012 20:35:39 +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 1RjGVk-0001gy-P2
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1732 invoked from network); 6 Jan 2012 20:35:30 -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;
	6 Jan 2012 20:35:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871221"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20: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; Fri, 6 Jan 2012 20:35:30 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RjGVd-0003bG-SF; Fri, 06 Jan 2012 20:35:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVd-0001X5-RO;
	Fri, 06 Jan 2012 20:35:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:06 +0000
Message-ID: <1325882107-5794-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: introduce libxl_fd_set_nonblock,
	rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 want a function for setting fds to nonblocking, so introduce one.

This is a very similar requirement to that for libxl_fd_set_cloexec,
so make it common with that.

While we're at it, fix a few deficiences that make this latter
function less desirable than it could be:
 * Change the return from 0/-1 (like a syscall) to a libxl error code
 * Take a boolean parameter for turning the flag on and off
 * Log on error (and so, take a ctx for this purpose)

Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
such errors are highly unlikely.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c      |   33 ++++++++++++++++++++++++++-------
 tools/libxl/libxl.h      |    6 +++++-
 tools/libxl/libxl_qmp.c  |    3 ++-
 tools/libxl/xl_cmdimpl.c |    3 ++-
 4 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f6370d4..42b64d8 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3647,19 +3647,38 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
-int libxl_fd_set_cloexec(int fd)
+static int fd_set_flags(libxl_ctx *ctx, int fd,
+                        int fcntlgetop, int fcntlsetop, const char *fl,
+                        int flagmask, int set_p)
 {
-    int flags = 0;
+    int flags, r;
 
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
+    flags = fcntl(fd, fcntlgetop);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_GET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
+
+    if (set_p)
+        flags |= flagmask;
+    else
+        flags &= ~flagmask;
+
+    r = fcntl(fd, fcntlsetop, flags);
+    if (r == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_SET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+
+    return 0;
 }
 
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
+  { return fd_set_flags(ctx,fd, F_GETFD,F_SETFD,"FD", FD_CLOEXEC, cloexec); }
+
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
+  { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 97ca25e..5396ba8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -613,7 +613,11 @@ const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
 /* misc */
-int libxl_fd_set_cloexec(int fd);
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
+  /* Each of these sets or clears the flag according to whether the
+   * 2nd parameter is nonzero.  On failure, they log, and
+   * return ERROR_FAIL, but also leave errno valid. */
 
 #include <libxl_event.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 58f5283..05df4d7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -324,7 +324,8 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl_fd_set_cloexec(qmp->qmp_fd);
+    ret = libxl_fd_set_cloexec(qmp->ctx, qmp->qmp_fd, 1);
+    if (ret) return -1;
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index a18c6b2..b88fc8a 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1490,7 +1490,8 @@ static int create_domain(struct domain_create *dom_info)
             restore_fd = migrate_fd;
         } else {
             restore_fd = open(restore_file, O_RDONLY);
-            libxl_fd_set_cloexec(restore_fd);
+            rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
+            if (rc) return rc;
         }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
-- 
1.7.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 Jan 06 20:35:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVV-0001eT-8O; Fri, 06 Jan 2012 20:35:21 +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 1RjGVU-0001eA-LM
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1493 invoked from network); 6 Jan 2012 20:35:14 -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;
	6 Jan 2012 20:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 20:35: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
	1RjGVN-0003an-R4; Fri, 06 Jan 2012 20:35:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVN-0001WU-QE;
	Fri, 06 Jan 2012 20:35:13 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 6 Jan 2012 20:34:58 +0000
Message-ID: <1325882107-5794-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] 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 are only a couple of callers now,
including 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 +++++++--
 tools/libxl/libxl_qmp.c      |    2 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa7fb16..1bca869 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -147,7 +147,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;
@@ -721,7 +726,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)
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 1777e44..3dfa43a 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -513,7 +513,7 @@ static int qmp_send(libxl__qmp_handler *qmp,
 {
     char *buf = NULL;
     int rc = -1;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    libxl__gc gc; LIBXL_INIT_GC(gc,qmp->ctx);
 
     buf = qmp_send_prepare(&gc, qmp, cmd, args, callback, opaque, context);
 
-- 
1.7.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 Jan 06 20:35:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVV-0001eT-8O; Fri, 06 Jan 2012 20:35:21 +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 1RjGVU-0001eA-LM
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1493 invoked from network); 6 Jan 2012 20:35:14 -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;
	6 Jan 2012 20:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871211"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 20:35: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
	1RjGVN-0003an-R4; Fri, 06 Jan 2012 20:35:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVN-0001WU-QE;
	Fri, 06 Jan 2012 20:35:13 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 6 Jan 2012 20:34:58 +0000
Message-ID: <1325882107-5794-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] 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 are only a couple of callers now,
including 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 +++++++--
 tools/libxl/libxl_qmp.c      |    2 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa7fb16..1bca869 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -147,7 +147,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;
@@ -721,7 +726,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)
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 1777e44..3dfa43a 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -513,7 +513,7 @@ static int qmp_send(libxl__qmp_handler *qmp,
 {
     char *buf = NULL;
     int rc = -1;
-    libxl__gc gc = LIBXL_INIT_GC(qmp->ctx);
+    libxl__gc gc; LIBXL_INIT_GC(gc,qmp->ctx);
 
     buf = qmp_send_prepare(&gc, qmp, cmd, args, callback, opaque, context);
 
-- 
1.7.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 Jan 06 20:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVm-0001kd-Na; Fri, 06 Jan 2012 20:35:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RjGVk-0001gn-7G
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1680 invoked from network); 6 Jan 2012 20:35:28 -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;
	6 Jan 2012 20:35:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871220"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35: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; Fri, 6 Jan 2012 20:35: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
	1RjGVb-0003bD-TX; Fri, 06 Jan 2012 20:35:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVb-0001X1-Sg;
	Fri, 06 Jan 2012 20:35:27 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:05 +0000
Message-ID: <1325882107-5794-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] 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          |  327 ++++++++++++++++++++++++++++++-----------
 tools/libxl/libxl.h          |   55 ++------
 tools/libxl/libxl_event.c    |  239 ++++++++++++++++++++++++++++---
 tools/libxl/libxl_event.h    |  184 +++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |   82 ++++++++++-
 tools/libxl/libxl_types.idl  |   34 ++++-
 tools/libxl/xl_cmdimpl.c     |  270 ++++++++++++++++++++---------------
 7 files changed, 912 insertions(+), 279 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c0024af..f6370d4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,8 +45,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_rindex = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -55,6 +58,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);
@@ -86,6 +92,20 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return rc;
 }
 
+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;
@@ -95,6 +115,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);
@@ -108,9 +135,12 @@ 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_rindex);
     free(ctx->watch_slots);
 
+    discard_events(&ctx->occurred);
+
     GC_FREE;
     free(ctx);
     return 0;
@@ -646,117 +676,175 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
     return ret;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl__gc *gc = &egc->gc;
+    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(egc, "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(egc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(egc, 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(egc, 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(egc, 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__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    libxl__gc *gc = &egc->gc;
+    libxl_evgen_disk_eject *evg = (void*)w;
     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(egc, "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(egc, 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")) {
@@ -765,19 +853,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(egc, 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)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c0a4373..97ca25e 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"
@@ -300,51 +308,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 e71ab66..c42b565 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -143,7 +143,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);
@@ -508,9 +509,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_internal(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -522,9 +523,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_rindex
@@ -591,8 +589,18 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
     }
 
  out:
+    return rc;
+}
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
-    GC_FREE;
+    EGC_FREE;
     return rc;
 }
 
@@ -621,11 +629,11 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now)
+static void afterpoll_internal(libxl__egc *egc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now)
 {
-    EGC_INIT(ctx);
-    CTX_LOCK;
+    libxl__gc *gc = &egc->gc;
     libxl__ev_fd *efd;
 
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
@@ -651,12 +659,18 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(egc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_internal(egc, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -721,11 +735,10 @@ void libxl__event_disaster(libxl__egc *egc, 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";
@@ -734,9 +747,197 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
     exit(-1);
 }
 
+static void egc_run_callbacks(libxl__egc *egc)
+{
+    libxl__gc *gc = &egc->gc;
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
+}
+
 void libxl__egc_cleanup(libxl__egc *egc)
 {
-    libxl__gc_cleanup(&egc->gc);
+    libxl__gc *gc = &egc->gc;
+    libxl__gc_cleanup(gc);
+
+    egc_run_callbacks(egc);
+}
+
+/*
+ * 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__egc *egc, libxl_event *event)
+{
+    libxl__gc *gc = &egc->gc;
+
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__egc_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(&egc->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__egc *egc,
+                              libxl_event_type type, uint32_t domid)
+{
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_internal(libxl__egc *egc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user)
+{
+    libxl__gc *gc = &egc->gc;
+    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)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+static int eventloop_iteration(libxl__egc *egc) {
+    libxl__gc *gc = &egc->gc;
+    int rc;
+    struct timeval now;
+    
+    CTX_LOCK;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) goto out;
+
+    int timeout;
+
+    for (;;) {
+        int nfds = CTX->fd_polls_allocd;
+        timeout = -1;
+        rc = beforepoll_internal(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)
+            return 0; /* will go round again if caller requires */
+
+        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_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+    CTX_UNLOCK;
+
+    rc = 0;
+ out:
+    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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = eventloop_iteration(egc);
+        if (rc) goto out;
+
+        /* we unlock and cleanup the egc 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__egc_cleanup(egc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
 }
 
 /*
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index a7e8240..dd6e6ed 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,180 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ *
+ * (Callers inside libxl may not call libxl_event_check or _wait.)
+ */
+
+#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 +210,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;
  *      }
  *   }
  *
@@ -175,6 +349,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.h b/tools/libxl/libxl_internal.h
index fdfcf9d..8cb6cdb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -170,11 +170,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 libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -188,12 +222,16 @@ 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_rindex_allocd;
     int *fd_rindex; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -205,6 +243,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 */
@@ -245,6 +290,7 @@ struct libxl__gc {
 struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
+    struct libxl__event_list occurred_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -383,6 +429,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.
  */
 
 
@@ -426,6 +475,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__egc*, 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__egc*, 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(egc, type, domid)                              \
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
 _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
                                    libxl_event_type type /* may be 0 */,
                                    const char *file, int line,
@@ -438,6 +506,9 @@ _hidden void libxl__event_disaster(libxl__egc*, 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).
@@ -976,12 +1047,15 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 /* egc initialisation and destruction: */
 
-#define LIBXL_INIT_EGC(egc,ctx) do{             \
-        LIBXL_INIT_GC((egc).gc,ctx);            \
-        /* list of occurred events tbd */       \
+#define LIBXL_INIT_EGC(egc,ctx) do{                     \
+        LIBXL_INIT_GC((egc).gc,ctx);                    \
+        LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
+  /* Frees memory allocated within this egc's gc, and and report all
+   * occurred events via callback, if applicable.  May reenter the
+   * application; see restrictions above. */
 
 /* convenience macros: */
 
@@ -1004,7 +1078,7 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
  */
 
 #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 78a1cc6..6728479 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"),
@@ -394,3 +389,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
     ("extratime", integer),
     ("weight", 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 8270f34..a18c6b2 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;
@@ -1651,14 +1678,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;
@@ -1695,92 +1722,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:
@@ -2263,6 +2304,7 @@ 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);
@@ -2277,37 +2319,39 @@ static void shutdown_domain(const char *p, int wait)
     }
 
     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 Jan 06 20:35:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGVo-0001lz-OG; Fri, 06 Jan 2012 20:35:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RjGVm-0001i3-Uc
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:35:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1325882112!2125953!11
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTg2MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1756 invoked from network); 6 Jan 2012 20:35:32 -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;
	6 Jan 2012 20:35:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; 
   d="scan'208";a="9871223"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	06 Jan 2012 20:35:32 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 6 Jan 2012 20:35: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
	1RjGVf-0003bJ-Vl; Fri, 06 Jan 2012 20:35:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RjGVf-0001XC-Uz;
	Fri, 06 Jan 2012 20:35:31 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:35:07 +0000
Message-ID: <1325882107-5794-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Permit multithreaded event waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, the context would be locked whenever we were waiting in
libxl's own call to poll (waiting for operating system events).

This would mean that multiple simultaneous calls to libxl_event_wait
in different threads with different parameters would not work
properly.

If we simply unlock the context, it would be possible for another
thread to discover the occurrence of the event we were waiting for,
without us even waking up, and we would remain in poll.  So we need a
way to wake up other threads: a pipe, one for each thread in poll.

We also need to move some variables from globals in the ctx to be
per-polling-thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   18 +++-
 tools/libxl/libxl_event.c    |  196 ++++++++++++++++++++++++++++++++++--------
 tools/libxl/libxl_internal.h |   51 ++++++++++-
 3 files changed, 219 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 42b64d8..b8167b3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -49,8 +49,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->osevent_hooks = 0;
 
-    ctx->fd_polls = 0;
-    ctx->fd_rindex = 0;
+    LIBXL_LIST_INIT(&ctx->pollers_event);
+    LIBXL_LIST_INIT(&ctx->pollers_idle);
+
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
 
@@ -61,6 +62,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    rc = libxl__poller_init(ctx, &ctx->poller_app);
+    if (rc) goto out;
+
     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);
@@ -135,8 +139,14 @@ 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_rindex);
+    libxl__poller_dispose(&ctx->poller_app);
+    assert(LIBXL_LIST_EMPTY(&ctx->pollers_event));
+    libxl__poller *poller, *poller_tmp;
+    LIBXL_LIST_FOREACH_SAFE(poller, &ctx->pollers_idle, entry, poller_tmp) {
+        libxl__poller_dispose(poller);
+        free(poller);
+    }
+
     free(ctx->watch_slots);
 
     discard_events(&ctx->occurred);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c42b565..704e734 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -509,9 +509,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
  * osevent poll
  */
 
-static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
-                               struct pollfd *fds, int *timeout_upd,
-                               struct timeval now)
+static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
+                               int *nfds_io, struct pollfd *fds,
+                               int *timeout_upd, struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -533,7 +533,7 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = 0;
+        int maxfd = poller->wakeup_pipe[0] + 1;
         LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
             if (!efd->events)
                 continue;
@@ -541,30 +541,39 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
                 maxfd = efd->fd + 1;
         }
         /* make sure our array is as big as *nfds_io */
-        if (CTX->fd_rindex_allocd < maxfd) {
+        if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
             if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + CTX->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
-            CTX->fd_rindex = newarray;
-            CTX->fd_rindex_allocd = maxfd;
+            memset(newarray + poller->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
+            poller->fd_rindex = newarray;
+            poller->fd_rindex_allocd = maxfd;
         }
     }
 
     int used = 0;
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-        if (!efd->events)
-            continue;
-        if (used < *nfds_io) {
-            fds[used].fd = efd->fd;
-            fds[used].events = efd->events;
-            fds[used].revents = 0;
-            assert(efd->fd < CTX->fd_rindex_allocd);
-            CTX->fd_rindex[efd->fd] = used;
-        }
-        used++;
-    }
+
+#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
+        if ((req_events)) {                                     \
+            if (used < *nfds_io) {                              \
+                fds[used].fd = (req_fd);                        \
+                fds[used].events = (req_events);                \
+                fds[used].revents = 0;                          \
+                assert((req_fd) < poller->fd_rindex_allocd);    \
+                poller->fd_rindex[(req_fd)] = used;             \
+            }                                                   \
+            used++;                                             \
+        }                                                       \
+    }while(0)
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
+        REQUIRE_FD(efd->fd, efd->events, efd);
+
+    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
+
+#undef REQUIRE_FD
+
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
     *nfds_io = used;
@@ -598,22 +607,23 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
+    int rc = beforepoll_internal(gc, &ctx->poller_app,
+                                 nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
 }
 
-static int afterpoll_check_fd(libxl_ctx *ctx,
+static int afterpoll_check_fd(libxl__poller *poller,
                               const struct pollfd *fds, int nfds,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= ctx->fd_rindex_allocd)
+    if (fd >= poller->fd_rindex_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = ctx->fd_rindex[fd];
+    int slot = poller->fd_rindex[fd];
 
     if (slot >= nfds)
         /* stale slot entry; again, added afterwards */
@@ -629,22 +639,31 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-static void afterpoll_internal(libxl__egc *egc,
+static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
     libxl__gc *gc = &egc->gc;
     libxl__ev_fd *efd;
 
+
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
 
-        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        int revents = afterpoll_check_fd(poller,fds,nfds, efd->fd,efd->events);
         if (revents)
             efd->func(egc, efd, efd->fd, efd->events, revents);
     }
 
+    if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
+        char buf[256];
+        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
+        if (r < 0)
+            if (errno != EINTR && errno != EWOULDBLOCK)
+                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+    }
+
     for (;;) {
         libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
         if (!etime)
@@ -666,7 +685,7 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    afterpoll_internal(egc, nfds, fds, now);
+    afterpoll_internal(egc, &ctx->poller_app, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
@@ -789,7 +808,10 @@ void libxl__event_occurred(libxl__egc *egc, libxl_event *event)
         LIBXL_TAILQ_INSERT_TAIL(&egc->occurred_for_callback, event, link);
         return;
     } else {
+        libxl__poller *poller;
         LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+        LIBXL_LIST_FOREACH(poller, &CTX->pollers_event, entry)
+            libxl__poller_wakeup(egc, poller);
     }
 }
 
@@ -857,7 +879,94 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
-static int eventloop_iteration(libxl__egc *egc) {
+/*
+ * Manipulation of pollers
+ */
+
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
+{
+    int r, rc;
+    p->fd_polls = 0;
+    p->fd_rindex = 0;
+
+    r = pipe(p->wakeup_pipe);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
+    if (rc) goto out;
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__poller_dispose(p);
+    return rc;
+}
+
+void libxl__poller_dispose(libxl__poller *p)
+{
+    if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
+    if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
+    free(p->fd_polls);
+    free(p->fd_rindex);
+}
+
+libxl__poller *libxl__poller_get(libxl_ctx *ctx)
+{
+    /* must be called with ctx locked */
+    int rc;
+
+    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
+    if (p)
+        return p;
+
+    p = malloc(sizeof(*p));
+    if (!p) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
+        return 0;
+    }
+    memset(p, 0, sizeof(*p));
+
+    rc = libxl__poller_init(ctx, p);
+    if (rc) return NULL;
+
+    return p;
+}
+
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
+{
+    LIBXL_LIST_INSERT_HEAD(&ctx->pollers_idle, p, entry);
+}
+
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
+{
+    static const char buf[1] = "";
+
+    for (;;) {
+        int r = write(p->wakeup_pipe[1], buf, 1);
+        if (r==1) return;
+        assert(r==-1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return;
+        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
+        return;
+    }
+}
+
+/*
+ * Main event loop iteration
+ */
+
+static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
+    /* The CTX must be locked EXACTLY ONCE so that this function
+     * can unlock it when it polls.
+     */
     libxl__gc *gc = &egc->gc;
     int rc;
     struct timeval now;
@@ -870,23 +979,27 @@ static int eventloop_iteration(libxl__egc *egc) {
     int timeout;
 
     for (;;) {
-        int nfds = CTX->fd_polls_allocd;
+        int nfds = poller->fd_polls_allocd;
         timeout = -1;
-        rc = beforepoll_internal(gc, &nfds, CTX->fd_polls, &timeout, now);
+        rc = beforepoll_internal(gc, poller, &nfds, poller->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);
+            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
 
         if (!newarray) { rc = ERROR_NOMEM; goto out; }
 
-        CTX->fd_polls = newarray;
-        CTX->fd_polls_allocd = nfds;
+        poller->fd_polls = newarray;
+        poller->fd_polls_allocd = nfds;
     }
 
-    rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+    CTX_UNLOCK;
+    rc = poll(poller->fd_polls, poller->fd_polls_allocd, timeout);
+    CTX_LOCK;
+
     if (rc < 0) {
         if (errno == EINTR)
             return 0; /* will go round again if caller requires */
@@ -899,7 +1012,8 @@ static int eventloop_iteration(libxl__egc *egc) {
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
-    afterpoll_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+    afterpoll_internal(egc, poller,
+                       poller->fd_polls_allocd, poller->fd_polls, now);
 
     CTX_UNLOCK;
 
@@ -913,15 +1027,19 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      libxl_event_predicate *pred, void *pred_user)
 {
     int rc;
+    libxl__poller *poller = NULL;
 
     EGC_INIT(ctx);
     CTX_LOCK;
 
+    poller = libxl__poller_get(ctx);
+    if (!poller) { rc = ERROR_FAIL; goto out; }
+
     for (;;) {
         rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
         if (rc != ERROR_NOT_READY) goto out;
 
-        rc = eventloop_iteration(egc);
+        rc = eventloop_iteration(egc, poller);
         if (rc) goto out;
 
         /* we unlock and cleanup the egc each time we go through this loop,
@@ -935,6 +1053,8 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     }
 
  out:
+    libxl__poller_put(ctx, poller);
+
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8cb6cdb..546f300 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -200,6 +200,33 @@ struct libxl__evgen_disk_eject {
 _hidden void
 libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
 
+typedef struct libxl__poller libxl__poller;
+struct libxl__poller {
+    /*
+     * These are used to allow other threads to wake up a thread which
+     * may be stuck in poll, because whatever it was waiting for
+     * hadn't happened yet.  Threads which generate events will write
+     * a byte to each pipe.  A threads which is waiting will empty its
+     * own pipe, and put its poller on the pollers_event list, before
+     * releasing the ctx lock and going into poll; when it comes out
+     * of poll it will take the poller off the pollers_event list.
+     *
+     * When a thread is done with a poller it should put it onto
+     * pollers_idle, where it can be reused later.
+     *
+     * The "poller_app" is never idle, but is sometimes on
+     * pollers_event.
+     */
+    LIBXL_LIST_ENTRY(libxl__poller) entry;
+
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
+    int fd_rindex_allocd;
+    int *fd_rindex; /* see libxl_osevent_beforepoll */
+
+    int wakeup_pipe[2]; /* 0 means no fd allocated */
+};
 
 struct libxl__ctx {
     xentoollog_logger *lg;
@@ -230,10 +257,9 @@ struct libxl__ctx {
       /* 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_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    libxl__poller poller_app; /* libxl_osevent_beforepoll and _afterpoll */
+    LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
+
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
     LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
 
@@ -517,6 +543,23 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
     libxl__event_disaster(egc, msg, errnoval, type, __FILE__,__LINE__,__func__)
 
 
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+void libxl__poller_dispose(libxl__poller *p);
+  /* Fills in, or disposes of the resources held by, a poller whose
+   * space the caller has allocated.  ctx must be locked.
+   */
+
+libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
+  /* Obtain a fresh poller from malloc or the idle list, and put it
+   * away again afterwards.  _get can fail, returning NULL.
+   * ctx must be locked. */
+
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
+  /* Notifies whoever is polling using p that they should wake up.
+   * ctx must be locked. */
+
+
 /* 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);
-- 
1.7.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 Jan 06 20:51:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGke-0003PI-GB; Fri, 06 Jan 2012 20:51:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Bob.Jung@mandiant.com>) id 1RjGkc-0003PC-90
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:50:58 +0000
X-Env-Sender: Bob.Jung@mandiant.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325883016!59217177!1
X-Originating-IP: [165.212.64.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTY1LjIxMi42NC4yMSA9PiA4NjExNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14701 invoked from network); 6 Jan 2012 20:50:18 -0000
Received: from gateout01.mbox.net (HELO gateout01.mbox.net) (165.212.64.21)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 20:50:18 -0000
Received: from gateout01.mbox.net (gateout01-lo [127.0.0.1])
	by gateout01.mbox.net (Postfix) with ESMTP id E38F0CCCFA
	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 20:50:55 +0000 (GMT)
X-USANET-Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net
	via mtad (C8.MAIN.3.72B) 
	with ESMTP id 973qaFuY36864Mo1; Fri, 06 Jan 2012 20:50:54 -0000
Received: from S1HUB8.EXCHPROD.USA.NET [165.212.120.254] by gateout01.mbox.net
	via smtad (C8.MAIN.3.72B) 
	with ESMTPS id XID520qaFuY32561Xo1; Fri, 06 Jan 2012 20:50:54 -0000
X-USANET-Source: 165.212.120.254 IN Bob.Jung@mandiant.com
	S1HUB8.EXCHPROD.USA.NET
X-USANET-MsgId: XID520qaFuY32561Xo1
Received: from MBX3.EXCHPROD.USA.NET ([10.120.221.32]) by
	S1HUB8.EXCHPROD.USA.NET ([10.120.220.38]) with mapi;
	Fri, 6 Jan 2012 20:49:55 +0000
From: Bob Jung <Bob.Jung@mandiant.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:49:53 +0000
Thread-Topic: potential bug where mem_event_request_t gfn value == -1?
Thread-Index: AczMtL50Jdzl6W3yQtCso6ZNlTNuLw==
Message-ID: <CC85277B-4FC1-4296-867C-971234973298@mandiant.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] potential bug where mem_event_request_t gfn value == -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


Hi there,

I am running an adapted version of tools/tests/xen_access/xen_access.c  to get and respond to memory events to do some analysis.  Anyways, after registering for and receiving single stepping events in my ring buffer where the me_event_request_t's  reason field == MEM_EVENT_REASON_SINGLESTEP, I sometimes see that the gfn in the request is -1.

the guest is HVM windows 32 bit.  For 99.99% of the single step traps the req.gfn value is the correct guest frame number value, but every now and again I get a -1

Does anyone know why this could happen?  

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 20:51:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 20: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 1RjGke-0003PI-GB; Fri, 06 Jan 2012 20:51:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Bob.Jung@mandiant.com>) id 1RjGkc-0003PC-90
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 20:50:58 +0000
X-Env-Sender: Bob.Jung@mandiant.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325883016!59217177!1
X-Originating-IP: [165.212.64.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTY1LjIxMi42NC4yMSA9PiA4NjExNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14701 invoked from network); 6 Jan 2012 20:50:18 -0000
Received: from gateout01.mbox.net (HELO gateout01.mbox.net) (165.212.64.21)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 20:50:18 -0000
Received: from gateout01.mbox.net (gateout01-lo [127.0.0.1])
	by gateout01.mbox.net (Postfix) with ESMTP id E38F0CCCFA
	for <xen-devel@lists.xensource.com>;
	Fri,  6 Jan 2012 20:50:55 +0000 (GMT)
X-USANET-Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net
	via mtad (C8.MAIN.3.72B) 
	with ESMTP id 973qaFuY36864Mo1; Fri, 06 Jan 2012 20:50:54 -0000
Received: from S1HUB8.EXCHPROD.USA.NET [165.212.120.254] by gateout01.mbox.net
	via smtad (C8.MAIN.3.72B) 
	with ESMTPS id XID520qaFuY32561Xo1; Fri, 06 Jan 2012 20:50:54 -0000
X-USANET-Source: 165.212.120.254 IN Bob.Jung@mandiant.com
	S1HUB8.EXCHPROD.USA.NET
X-USANET-MsgId: XID520qaFuY32561Xo1
Received: from MBX3.EXCHPROD.USA.NET ([10.120.221.32]) by
	S1HUB8.EXCHPROD.USA.NET ([10.120.220.38]) with mapi;
	Fri, 6 Jan 2012 20:49:55 +0000
From: Bob Jung <Bob.Jung@mandiant.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 20:49:53 +0000
Thread-Topic: potential bug where mem_event_request_t gfn value == -1?
Thread-Index: AczMtL50Jdzl6W3yQtCso6ZNlTNuLw==
Message-ID: <CC85277B-4FC1-4296-867C-971234973298@mandiant.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] potential bug where mem_event_request_t gfn value == -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


Hi there,

I am running an adapted version of tools/tests/xen_access/xen_access.c  to get and respond to memory events to do some analysis.  Anyways, after registering for and receiving single stepping events in my ring buffer where the me_event_request_t's  reason field == MEM_EVENT_REASON_SINGLESTEP, I sometimes see that the gfn in the request is -1.

the guest is HVM windows 32 bit.  For 99.99% of the single step traps the req.gfn value is the correct guest frame number value, but every now and again I get a -1

Does anyone know why this could happen?  

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

From xen-devel-bounces@lists.xensource.com Fri Jan 06 22:21:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 22: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 1RjIA4-00044U-DP; Fri, 06 Jan 2012 22:21:20 +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 1RjIA2-00044P-U5
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 22:21:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325888471!8128314!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3ODAwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8079 invoked from network); 6 Jan 2012 22:21:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 22:21:12 -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
	q06ML7ik025615
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 22:21:08 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
	q06ML6uA017617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 22:21:07 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
	q06ML5Pc019960; Fri, 6 Jan 2012 16:21:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 14:21:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 684364094B; Fri,  6 Jan 2012 17:19:27 -0500 (EST)
Date: Fri, 6 Jan 2012 17:19:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120106221927.GA10248@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120106160011.GD6125@phenom.dumpdata.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.0A090206.4F0773D5.0046,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > I suppose you might want "Overriding ownership to dom%d".
> 
> OK. To the point and potentially can fit in 80 lines :-).

how about this?
> 
>From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 14:16:45 -0500
Subject: [PATCH] xen/pciback: Expand the warning message to include domain
 id.

When a PCI device is transferred to another domain and it is still
in usage (from the internal perspective), mention which other
domain is using it to aid in debugging.

[v2: Truncate the verbose message per Jan Beulich suggestion]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/xenbus.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 474d52e..2405a24 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
 	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
 	if (xen_register_device_domain_owner(dev,
 					     pdev->xdev->otherend_id) != 0) {
-		dev_err(&dev->dev, "device has been assigned to another " \
-			"domain! Over-writting the ownership, but beware.\n");
+		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
+			xen_find_device_domain_owner(dev));
 		xen_unregister_device_domain_owner(dev);
 		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
 	}
-- 
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 Jan 06 22:21:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 22: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 1RjIA4-00044U-DP; Fri, 06 Jan 2012 22:21:20 +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 1RjIA2-00044P-U5
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 22:21:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325888471!8128314!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3ODAwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8079 invoked from network); 6 Jan 2012 22:21:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 6 Jan 2012 22:21:12 -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
	q06ML7ik025615
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 22:21:08 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
	q06ML6uA017617
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 6 Jan 2012 22:21:07 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
	q06ML5Pc019960; Fri, 6 Jan 2012 16:21:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 06 Jan 2012 14:21:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 684364094B; Fri,  6 Jan 2012 17:19:27 -0500 (EST)
Date: Fri, 6 Jan 2012 17:19:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120106221927.GA10248@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120106160011.GD6125@phenom.dumpdata.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.0A090206.4F0773D5.0046,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > I suppose you might want "Overriding ownership to dom%d".
> 
> OK. To the point and potentially can fit in 80 lines :-).

how about this?
> 
>From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 4 Jan 2012 14:16:45 -0500
Subject: [PATCH] xen/pciback: Expand the warning message to include domain
 id.

When a PCI device is transferred to another domain and it is still
in usage (from the internal perspective), mention which other
domain is using it to aid in debugging.

[v2: Truncate the verbose message per Jan Beulich suggestion]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/xenbus.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 474d52e..2405a24 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
 	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
 	if (xen_register_device_domain_owner(dev,
 					     pdev->xdev->otherend_id) != 0) {
-		dev_err(&dev->dev, "device has been assigned to another " \
-			"domain! Over-writting the ownership, but beware.\n");
+		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
+			xen_find_device_domain_owner(dev));
 		xen_unregister_device_domain_owner(dev);
 		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
 	}
-- 
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 Jan 06 22:24:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 22:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjICm-0004Bh-7s; Fri, 06 Jan 2012 22:24:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjICk-0004BV-Dr
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 22:24:06 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325888639!8128466!1
X-Originating-IP: [77.238.189.218]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11734 invoked from network); 6 Jan 2012 22:23:59 -0000
Received: from nm11-vm0.bullet.mail.ird.yahoo.com (HELO
	nm11-vm0.bullet.mail.ird.yahoo.com) (77.238.189.218)
	by server-5.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 22:23:59 -0000
Received: from [77.238.189.233] by nm11.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 22:23:59 -0000
Received: from [212.82.108.120] by tm14.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 22:23:59 -0000
Received: from [127.0.0.1] by omp1029.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 22:23:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 64783.68506.bm@omp1029.mail.ird.yahoo.com
Received: (qmail 86543 invoked by uid 60001); 6 Jan 2012 22:23:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325888638; bh=E3E6ZaeRi4CHlN2xRdwI7b9dJfgsfRPBt85af2ZNVNk=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=sH0wEhGb6RurU1GLIrc66u0d7vRjZ93TyFb10MJ7MIeJpU/KJuiyhIDK6X2rnDMB/XE+Z+87/BT4kDj9U82bPMrGiffRAfR8kRzWwPuf+I7RcXa3B+axrb8qSfstDVVrTWJosujeNPXWnM2o7LzuB6nzL6wE8XHNuIwHW0jzJII=
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=mWdrWLQqOeTWsXmMjFtjUsV1A5cuXlAaohFGsVvnbm6CpPWBL9jbtZIv6W2AXarRq1Pgc8VCZnVr3AHXt2ZbB/leHMgSgUPVcVHMOE7hT2pNusajJhq3iE0RXR5rsctZoDthPak0koUroo6k+WuaN0uj2mj16Yc5L+VlZVuRINQ=;
X-YMail-OSG: LRHmuUkVM1nNefxlRePxiReg61G0DiC4j61k1Iw0pljoa7F
	1tV4kEW9c6i7Jx8wlVppPR1dI47lKVJiFDw_SpINVk_G8ysXlSg5UH7TdmGp
	uyXAi4HVnSY7.gs7CfTzV1gtvaL7e7_DSZGxcHKz45B4xf7TNVaZqj38JtRg
	W4eH9LUC3DDde1ye2vtuq_UQY5oxl6OYDkrKJG.mP3WEuMFmp3QIvTNjZ6Au
	l5GudHCWc.FL2Z0yaJzbuCxvK1aUtFDKjd0fpQeYkNNNznRyz6n61J00Yhri
	.0Cc3PQ_QyYzFuOhgiwBjx2TmDEzmPeybZu_xPKp5e6JfjNU9IjRWyaPQ1Du
	BjN4KcJrx6F4Sw6RMgAfjd8PV5T8OjiOo0rVjbZZFm6yfwVIA.fnm3Q5jUvb
	D1t22awnvM9OHDYSTKEfsFfMm2Fc7XeF2oixtPz9ZlCxHb8jB.rew91T2zeb
	CGNbtWbbvYU9lgl5SGvlbobZcKZCC.Uf7mRc_LY0riNXU.Gz8YLrKK5ircd_
	8kFIbAu0RRibJEUQBUhQon31wL45SQBsYSx7.Q5c5jVMQfrp2Alvwxv9Q
Received: from [83.154.246.188] by web29802.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 22:23:58 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
Message-ID: <1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 22:23:58 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: -+= Lta =+- <lta@akr.fm>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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="===============5153699869455889023=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5153699869455889023==
Content-Type: multipart/alternative; boundary="478945831-155259025-1325888638=:86498"

--478945831-155259025-1325888638=:86498
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Could you tell me what version of Xen? 4.1.0? 4.1.2?=0A=0ABy the way could =
you send your patches attached to a mail so I could try?=0A=0ATest on Xen 4=
.2 failed (desktop stays to lag...)=0A=0AWith installing xen 4.1.0/4.2.0 ov=
er my xen 4.2, domU boot but nothing appears on screen.=0A=0AStrange.=0A=0A=
=0A=0A________________________________=0A De=A0: -+=3D Lta =3D+- <lta@akr.f=
m>=0A=C0=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Vendredi 6 Janv=
ier 2012 17h48=0AObjet=A0: [Xen-devel] Secondary VGA Passthrough, nvidia, w=
in7: success report.=0A =0A=0AHello xen-devel,=0A=0A=0AThis is my first pos=
t on this list and as such i might be breaking some explicit/implicit rules=
 and i apologize if it's the case. Maybe this list isn't the exact=A0right=
=A0kind of place where to post this kind of stuff, but i know lots of us ar=
e browsing this list as the primary source of documentation for xen.=0A=0AI=
've read many times windows 7 isn't the right os to run on top of xen. Most=
 of the guy's who are running vga passthru are recommanding to use windows =
xp, and i've never seen any success report of vga passthru on windows 7 so =
i thought it was important to post mine.=0A=0AAnyway, here's my hardware se=
tup :=0A- Gigabyte GA-990X-UD3=0A-=A0AMD Phenom II X6 1075T Processor=0A- M=
SI Cyclone NVIDIA Geforce GTX 460=0A=0AOn the software side i'm using :=0A=
=0A- Debian testing as Dom0=0A- Xen-4.1 (debian version 4.1.2-2) with what'=
s now referred to as "Tobias Geiger patches" (http://old-list-archives.xen.=
org/archives/html/xen-devel/2010-05/msg00441.html) (You have to edit the pa=
tches, changing the path to some qemu source files for them to apply)=0A- d=
ebian's kernel =A03.1.5, compiled to include the pciback driver. Here's the=
 output of `cat /boot/my3.1.5config | grep -i xen`=0ACONFIG_XEN=3Dy=0ACONFI=
G_XEN_DOM0=3Dy=0ACONFIG_XEN_PRIVILEGED_GUEST=3Dy=0ACONFIG_XEN_PVHVM=3Dy=0AC=
ONFIG_XEN_MAX_DOMAIN_MEMORY=3D128=0ACONFIG_XEN_SAVE_RESTORE=3Dy=0A# CONFIG_=
XEN_DEBUG_FS is not set=0A# CONFIG_XEN_DEBUG is not set=0ACONFIG_PCI_XEN=3D=
y=0ACONFIG_XEN_PCIDEV_FRONTEND=3Dm=0ACONFIG_XEN_BLKDEV_FRONTEND=3Dm=0ACONFI=
G_XEN_BLKDEV_BACKEND=3Dm=0ACONFIG_NETXEN_NIC=3Dm=0ACONFIG_XEN_NETDEV_FRONTE=
ND=3Dm=0ACONFIG_XEN_NETDEV_BACKEND=3Dm=0ACONFIG_INPUT_XEN_KBDDEV_FRONTEND=
=3Dy=0ACONFIG_HVC_XEN=3Dy=0ACONFIG_XEN_WDT=3Dm=0ACONFIG_XEN_FBDEV_FRONTEND=
=3Dy=0A# Xen driver support=0ACONFIG_XEN_BALLOON=3Dy=0A# CONFIG_XEN_BALLOON=
_MEMORY_HOTPLUG is not set=0ACONFIG_XEN_SCRUB_PAGES=3Dy=0ACONFIG_XEN_DEV_EV=
TCHN=3Dm=0ACONFIG_XEN_BACKEND=3Dy=0ACONFIG_XENFS=3Dm=0ACONFIG_XEN_COMPAT_XE=
NFS=3Dy=0ACONFIG_XEN_SYS_HYPERVISOR=3Dy=0ACONFIG_XEN_XENBUS_FRONTEND=3Dy=0A=
CONFIG_XEN_GNTDEV=3Dm=0ACONFIG_XEN_GRANT_DEV_ALLOC=3Dm=0ACONFIG_XEN_PLATFOR=
M_PCI=3Dm=0ACONFIG_SWIOTLB_XEN=3Dy=0ACONFIG_XEN_PCIDEV_BACKEND=3Dy=0A=0AThe=
 kernel boot options are 'nomodeset xen-pciback.passthrough=3D1 xen-pciback=
.hide=3D(01:00.0)(01:00.1)'=0A=0A- Here's my win7 domU config file :=0A=0Ak=
ernel =3D "/usr/lib/xen-4.1/boot/hvmloader"=0Abuilder=3D'hvm'=0Amemory =3D =
3072=0Aname =3D "w7"=0Avif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00=
:16:3e:35:49:62']=0Adisk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7=
-xen/appz,hdb,w']=0Adevice_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0Aboot=
=3D"dc"=0A=0Apci=3D['01:00.0','01:00.1']=0Agfx_passthru=3D1=0A=0Avcpus=3D6=
=0Aacpi=3D1=0Asdl=3D0=0Avnc=3D1=0Avncconsole=3D1=0Avncpasswd=3D''=0Aserial=
=3D'pty'=0Ausbdevice=3D'tablet'=0Apae=3D1=0Apci_msitranslate=3D0=0Apci_powe=
r_mgmt=3D0=0Aacpi_s3 =3D 1=0Aacpi_s4 =3D 1=0Aon_poweroff =3D 'destroy'=0Aon=
_reboot =A0 =3D 'restart'=0Aon_crash =A0 =A0=3D 'restart'=0Axen_platform_pc=
i=3D1=0Ahpet =3D 1=0Aviridian=3D1=0Amonitor=3D1=0Axen_extended_power_mgmt=
=3D2=0Ahpet=3D1=0A=0AWhat's important here for the Nvidia drivers to work a=
nd not give a nice nvlddmkm.sys BSOD is:=0Apci_msitranslate=3D0=0Apci_power=
_mgmt=3D0=0A=0A- Windows 7 32bits=0A- Nvidia drivers 275.33=0A- You have to=
 manually run aero speed test or force aero to start by using registry entr=
ies for the desktop not to be laggy=0A=0AThe windows 7 domU is running fine=
 with no performance decrease noticeable, although i've not yet played inte=
nsive gpu video game, i'm still pretty confident they'll run fine.=0A=0AAny=
way. i've still some problems i shall report in separate posts :=0A- The PC=
I bus topology isn't preserved, and the gfx card, which is plugged on 01:00=
 becomes 05:00 on domU.=0A- I'm passing through an RME Hdsp / hammerfall pc=
i sound card to the domU and while it is working fine on his own, there's a=
 strange interaction between it and the GPLPV network driver. When i start =
playing sound, the network instantly cease working. It starts back as soon =
as i stop playing audio.=0A=0AThat's all folks,=0A=0ACheers,=0ALta=0A=0A___=
____________________________________________=0AXen-devel mailing list=0AXen=
-devel@lists.xensource.com=0Ahttp://lists.xensource.com/xen-devel
--478945831-155259025-1325888638=:86498
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>Could you =
tell me what version of Xen? 4.1.0? 4.1.2?</span></div><div><br><span></spa=
n></div><div><span>By the way could you send your patches attached to a mai=
l so I could try?</span></div><div><br><span></span></div><div><span>Test o=
n Xen 4.2 failed (desktop stays to lag...)</span></div><div><br><span></spa=
n></div><div><span>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU bo=
ot but nothing appears on screen.</span></div><div><br><span></span></div><=
div><span>Strange.<br></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> -+=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <=
b><span
 style=3D"font-weight: bold;">=C0&nbsp;:</span></b> xen-devel@lists.xensour=
ce.com <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span></b> =
Vendredi 6 Janvier 2012 17h48<br> <b><span style=3D"font-weight: bold;">Obj=
et&nbsp;:</span></b> [Xen-devel] Secondary VGA Passthrough, nvidia, win7: s=
uccess report.<br> </font> <br><div id=3D"yiv301820163"><div class=3D"yiv30=
1820163gmail_quote">Hello xen-devel,<div><br></div><div><br></div><div>This=
 is my first post on this list and as such i might be breaking some explici=
t/implicit rules and i apologize if it's the case. Maybe this list isn't th=
e exact&nbsp;right&nbsp;kind of place where to post this kind of stuff, but=
 i know lots of us are browsing this list as the primary source of document=
ation for xen.</div>=0A=0A<div><br></div><div>I've read many times windows =
7 isn't the right os to run on top of xen. Most of the guy's who are runnin=
g vga passthru are recommanding to use windows xp, and i've never seen any =
success report of vga passthru on windows 7 so i thought it was important t=
o post mine.</div>=0A=0A<div><br></div><div>Anyway, here's my hardware setu=
p :</div><div>- Gigabyte GA-990X-UD3</div><div>-&nbsp;AMD Phenom II X6 1075=
T Processor</div><div>- MSI Cyclone NVIDIA Geforce GTX 460</div><div><br></=
div><div>On the software side i'm using :</div>=0A=0A<div><br></div><div>- =
Debian testing as Dom0</div><div>- Xen-4.1 (debian version 4.1.2-2) with wh=
at's now referred to as "Tobias Geiger patches" (<a rel=3D"nofollow" target=
=3D"_blank" href=3D"http://old-list-archives.xen.org/archives/html/xen-deve=
l/2010-05/msg00441.html">http://old-list-archives.xen.org/archives/html/xen=
-devel/2010-05/msg00441.html</a>) (You have to edit the patches, changing t=
he path to some qemu source files for them to apply)</div>=0A=0A<div>- debi=
an's kernel &nbsp;3.1.5, compiled to include the pciback driver. Here's the=
 output of `cat /boot/my3.1.5config | grep -i xen`</div><div><div><font siz=
e=3D"1">CONFIG_XEN=3Dy</font></div><div>=0A<font size=3D"1">CONFIG_XEN_DOM0=
=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</fon=
t></div><div><font size=3D"1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><fon=
t size=3D"1">CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><font size=
=3D"1">CONFIG_XEN_SAVE_RESTORE=3Dy</font></div><div><font size=3D"1"># CONF=
IG_XEN_DEBUG_FS is not set</font></div>=0A<div><font size=3D"1"># CONFIG_XE=
N_DEBUG is not set</font></div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy</fo=
nt></div><div><font size=3D"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></div>=
=0A<div><font size=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><f=
ont size=3D"1">CONFIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D=
"1">CONFIG_NETXEN_NIC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_N=
ETDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_NETDEV_BACK=
END=3Dm</font></div><div><font size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTEND=
=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><d=
iv><font size=3D"1">CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CO=
NFIG_XEN_FBDEV_FRONTEND=3Dy</font></div>=0A<div><font size=3D"1"># Xen driv=
er support</font></div><div><font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font><=
/div><div><font size=3D"1"># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set</=
font></div>=0A<div><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div>=
<div><font size=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=
=3D"1">CONFIG_XEN_BACKEND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_X=
ENFS=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</fon=
t></div><div><font size=3D"1">CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=0A=
<div><font size=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_GRANT_DEV_ALLOC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_PLA=
TFORM_PCI=3Dm</font></div><div><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</fon=
t></div><div><font size=3D"1">CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=0A=
</div><div><font size=3D"1"><br></font></div><div>The kernel boot options a=
re 'nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:0=
0.1)'</div><div><br></div><div>- Here's my win7 domU config file :</div>=0A=
=0A<div><br></div><div><div><font size=3D"1">kernel =3D "/usr/lib/xen-4.1/b=
oot/hvmloader"</font></div><div><font size=3D"1">builder=3D'hvm'</font></di=
v><div><font size=3D"1">memory =3D 3072</font></div>=0A<div><font size=3D"1=
">name =3D "w7"</font></div><div><font size=3D"1">vif =3D [ 'type=3Dnetfron=
t,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62']</font></div><div><font size=3D=
"1">disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w'=
]</font></div>=0A=0A<div><font size=3D"1">device_model =3D '/usr/lib/xen-4.=
1/bin/qemu-dm'</font></div><div><font size=3D"1">boot=3D"dc"</font></div><d=
iv><font size=3D"1"><br>=0A</font></div><div><font size=3D"1">pci=3D['01:00=
.0','01:00.1']</font></div><div><font size=3D"1">gfx_passthru=3D1</font></d=
iv><div><font size=3D"1"><br>=0A</font></div><div><font size=3D"1">vcpus=3D=
6</font></div><div><font size=3D"1">acpi=3D1</font></div><div><font size=3D=
"1">sdl=3D0</font></div><div><font size=3D"1">vnc=3D1</font></div>=0A<div><=
font size=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncpasswd=
=3D''</font></div><div><font size=3D"1">serial=3D'pty'</font></div>=0A<div>=
<font size=3D"1">usbdevice=3D'tablet'</font></div><div><font size=3D"1">pae=
=3D1</font></div><div><font size=3D"1">pci_msitranslate=3D0</font></div>=0A=
<div><font size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">=
acpi_s3 =3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><=
div><font size=3D"1">on_poweroff =3D 'destroy'</font></div>=0A<div><font si=
ze=3D"1">on_reboot &nbsp; =3D 'restart'</font></div><div><font size=3D"1">o=
n_crash &nbsp; &nbsp;=3D 'restart'</font></div><div><font size=3D"1">xen_pl=
atform_pci=3D1</font></div>=0A<div><font size=3D"1">hpet =3D 1</font></div>=
<div><font size=3D"1">viridian=3D1</font></div><div><font size=3D"1">monito=
r=3D1</font></div><div><font size=3D"1">xen_extended_power_mgmt=3D2</font><=
/div>=0A<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><di=
v>What's important here for the Nvidia drivers to work and not give a nice =
nvlddmkm.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0<=
/font></div>=0A=0A<div><font size=3D"1">pci_power_mgmt=3D0</font></div></di=
v><div><font size=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>=
- Nvidia drivers 275.33</div><div>- You have to manually run aero speed tes=
t or force aero to start by using registry entries for the desktop not to b=
e laggy</div>=0A=0A<div><br></div><div>The windows 7 domU is running fine w=
ith no performance decrease noticeable, although i've not yet played intens=
ive gpu video game, i'm still pretty confident they'll run fine.</div><div>=
<br>=0A=0A</div><div>Anyway. i've still some problems i shall report in sep=
arate posts :</div><div>- The PCI bus topology isn't preserved, and the gfx=
 card, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I'm pas=
sing through an RME Hdsp / hammerfall pci sound card to the domU and while =
it is working fine on his own, there's a strange interaction between it and=
 the GPLPV network driver. When i start playing sound, the network instantl=
y cease working. It starts back as soon as i stop playing audio.</div>=0A=
=0A<div><br></div><div>That's all folks,</div><div><br></div><div>Cheers,</=
div><div>Lta</div>=0A</div><br>=0A</div><br>_______________________________=
________________<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-deve=
l@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-de=
vel@lists.xensource.com</a><br><a href=3D"http://lists.xensource.com/xen-de=
vel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br><br><br>=
 </div> </div>  </div></body></html>
--478945831-155259025-1325888638=:86498--


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

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

--===============5153699869455889023==--


From xen-devel-bounces@lists.xensource.com Fri Jan 06 22:24:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 06 Jan 2012 22:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjICm-0004Bh-7s; Fri, 06 Jan 2012 22:24:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjICk-0004BV-Dr
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 22:24:06 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-5.tower-174.messagelabs.com!1325888639!8128466!1
X-Originating-IP: [77.238.189.218]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11734 invoked from network); 6 Jan 2012 22:23:59 -0000
Received: from nm11-vm0.bullet.mail.ird.yahoo.com (HELO
	nm11-vm0.bullet.mail.ird.yahoo.com) (77.238.189.218)
	by server-5.tower-174.messagelabs.com with SMTP;
	6 Jan 2012 22:23:59 -0000
Received: from [77.238.189.233] by nm11.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 22:23:59 -0000
Received: from [212.82.108.120] by tm14.bullet.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 22:23:59 -0000
Received: from [127.0.0.1] by omp1029.mail.ird.yahoo.com with NNFMP;
	06 Jan 2012 22:23:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 64783.68506.bm@omp1029.mail.ird.yahoo.com
Received: (qmail 86543 invoked by uid 60001); 6 Jan 2012 22:23:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325888638; bh=E3E6ZaeRi4CHlN2xRdwI7b9dJfgsfRPBt85af2ZNVNk=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=sH0wEhGb6RurU1GLIrc66u0d7vRjZ93TyFb10MJ7MIeJpU/KJuiyhIDK6X2rnDMB/XE+Z+87/BT4kDj9U82bPMrGiffRAfR8kRzWwPuf+I7RcXa3B+axrb8qSfstDVVrTWJosujeNPXWnM2o7LzuB6nzL6wE8XHNuIwHW0jzJII=
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=mWdrWLQqOeTWsXmMjFtjUsV1A5cuXlAaohFGsVvnbm6CpPWBL9jbtZIv6W2AXarRq1Pgc8VCZnVr3AHXt2ZbB/leHMgSgUPVcVHMOE7hT2pNusajJhq3iE0RXR5rsctZoDthPak0koUroo6k+WuaN0uj2mj16Yc5L+VlZVuRINQ=;
X-YMail-OSG: LRHmuUkVM1nNefxlRePxiReg61G0DiC4j61k1Iw0pljoa7F
	1tV4kEW9c6i7Jx8wlVppPR1dI47lKVJiFDw_SpINVk_G8ysXlSg5UH7TdmGp
	uyXAi4HVnSY7.gs7CfTzV1gtvaL7e7_DSZGxcHKz45B4xf7TNVaZqj38JtRg
	W4eH9LUC3DDde1ye2vtuq_UQY5oxl6OYDkrKJG.mP3WEuMFmp3QIvTNjZ6Au
	l5GudHCWc.FL2Z0yaJzbuCxvK1aUtFDKjd0fpQeYkNNNznRyz6n61J00Yhri
	.0Cc3PQ_QyYzFuOhgiwBjx2TmDEzmPeybZu_xPKp5e6JfjNU9IjRWyaPQ1Du
	BjN4KcJrx6F4Sw6RMgAfjd8PV5T8OjiOo0rVjbZZFm6yfwVIA.fnm3Q5jUvb
	D1t22awnvM9OHDYSTKEfsFfMm2Fc7XeF2oixtPz9ZlCxHb8jB.rew91T2zeb
	CGNbtWbbvYU9lgl5SGvlbobZcKZCC.Uf7mRc_LY0riNXU.Gz8YLrKK5ircd_
	8kFIbAu0RRibJEUQBUhQon31wL45SQBsYSx7.Q5c5jVMQfrp2Alvwxv9Q
Received: from [83.154.246.188] by web29802.mail.ird.yahoo.com via HTTP;
	Fri, 06 Jan 2012 22:23:58 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
Message-ID: <1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Fri, 6 Jan 2012 22:23:58 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: -+= Lta =+- <lta@akr.fm>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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="===============5153699869455889023=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5153699869455889023==
Content-Type: multipart/alternative; boundary="478945831-155259025-1325888638=:86498"

--478945831-155259025-1325888638=:86498
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Could you tell me what version of Xen? 4.1.0? 4.1.2?=0A=0ABy the way could =
you send your patches attached to a mail so I could try?=0A=0ATest on Xen 4=
.2 failed (desktop stays to lag...)=0A=0AWith installing xen 4.1.0/4.2.0 ov=
er my xen 4.2, domU boot but nothing appears on screen.=0A=0AStrange.=0A=0A=
=0A=0A________________________________=0A De=A0: -+=3D Lta =3D+- <lta@akr.f=
m>=0A=C0=A0: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Vendredi 6 Janv=
ier 2012 17h48=0AObjet=A0: [Xen-devel] Secondary VGA Passthrough, nvidia, w=
in7: success report.=0A =0A=0AHello xen-devel,=0A=0A=0AThis is my first pos=
t on this list and as such i might be breaking some explicit/implicit rules=
 and i apologize if it's the case. Maybe this list isn't the exact=A0right=
=A0kind of place where to post this kind of stuff, but i know lots of us ar=
e browsing this list as the primary source of documentation for xen.=0A=0AI=
've read many times windows 7 isn't the right os to run on top of xen. Most=
 of the guy's who are running vga passthru are recommanding to use windows =
xp, and i've never seen any success report of vga passthru on windows 7 so =
i thought it was important to post mine.=0A=0AAnyway, here's my hardware se=
tup :=0A- Gigabyte GA-990X-UD3=0A-=A0AMD Phenom II X6 1075T Processor=0A- M=
SI Cyclone NVIDIA Geforce GTX 460=0A=0AOn the software side i'm using :=0A=
=0A- Debian testing as Dom0=0A- Xen-4.1 (debian version 4.1.2-2) with what'=
s now referred to as "Tobias Geiger patches" (http://old-list-archives.xen.=
org/archives/html/xen-devel/2010-05/msg00441.html) (You have to edit the pa=
tches, changing the path to some qemu source files for them to apply)=0A- d=
ebian's kernel =A03.1.5, compiled to include the pciback driver. Here's the=
 output of `cat /boot/my3.1.5config | grep -i xen`=0ACONFIG_XEN=3Dy=0ACONFI=
G_XEN_DOM0=3Dy=0ACONFIG_XEN_PRIVILEGED_GUEST=3Dy=0ACONFIG_XEN_PVHVM=3Dy=0AC=
ONFIG_XEN_MAX_DOMAIN_MEMORY=3D128=0ACONFIG_XEN_SAVE_RESTORE=3Dy=0A# CONFIG_=
XEN_DEBUG_FS is not set=0A# CONFIG_XEN_DEBUG is not set=0ACONFIG_PCI_XEN=3D=
y=0ACONFIG_XEN_PCIDEV_FRONTEND=3Dm=0ACONFIG_XEN_BLKDEV_FRONTEND=3Dm=0ACONFI=
G_XEN_BLKDEV_BACKEND=3Dm=0ACONFIG_NETXEN_NIC=3Dm=0ACONFIG_XEN_NETDEV_FRONTE=
ND=3Dm=0ACONFIG_XEN_NETDEV_BACKEND=3Dm=0ACONFIG_INPUT_XEN_KBDDEV_FRONTEND=
=3Dy=0ACONFIG_HVC_XEN=3Dy=0ACONFIG_XEN_WDT=3Dm=0ACONFIG_XEN_FBDEV_FRONTEND=
=3Dy=0A# Xen driver support=0ACONFIG_XEN_BALLOON=3Dy=0A# CONFIG_XEN_BALLOON=
_MEMORY_HOTPLUG is not set=0ACONFIG_XEN_SCRUB_PAGES=3Dy=0ACONFIG_XEN_DEV_EV=
TCHN=3Dm=0ACONFIG_XEN_BACKEND=3Dy=0ACONFIG_XENFS=3Dm=0ACONFIG_XEN_COMPAT_XE=
NFS=3Dy=0ACONFIG_XEN_SYS_HYPERVISOR=3Dy=0ACONFIG_XEN_XENBUS_FRONTEND=3Dy=0A=
CONFIG_XEN_GNTDEV=3Dm=0ACONFIG_XEN_GRANT_DEV_ALLOC=3Dm=0ACONFIG_XEN_PLATFOR=
M_PCI=3Dm=0ACONFIG_SWIOTLB_XEN=3Dy=0ACONFIG_XEN_PCIDEV_BACKEND=3Dy=0A=0AThe=
 kernel boot options are 'nomodeset xen-pciback.passthrough=3D1 xen-pciback=
.hide=3D(01:00.0)(01:00.1)'=0A=0A- Here's my win7 domU config file :=0A=0Ak=
ernel =3D "/usr/lib/xen-4.1/boot/hvmloader"=0Abuilder=3D'hvm'=0Amemory =3D =
3072=0Aname =3D "w7"=0Avif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00=
:16:3e:35:49:62']=0Adisk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7=
-xen/appz,hdb,w']=0Adevice_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0Aboot=
=3D"dc"=0A=0Apci=3D['01:00.0','01:00.1']=0Agfx_passthru=3D1=0A=0Avcpus=3D6=
=0Aacpi=3D1=0Asdl=3D0=0Avnc=3D1=0Avncconsole=3D1=0Avncpasswd=3D''=0Aserial=
=3D'pty'=0Ausbdevice=3D'tablet'=0Apae=3D1=0Apci_msitranslate=3D0=0Apci_powe=
r_mgmt=3D0=0Aacpi_s3 =3D 1=0Aacpi_s4 =3D 1=0Aon_poweroff =3D 'destroy'=0Aon=
_reboot =A0 =3D 'restart'=0Aon_crash =A0 =A0=3D 'restart'=0Axen_platform_pc=
i=3D1=0Ahpet =3D 1=0Aviridian=3D1=0Amonitor=3D1=0Axen_extended_power_mgmt=
=3D2=0Ahpet=3D1=0A=0AWhat's important here for the Nvidia drivers to work a=
nd not give a nice nvlddmkm.sys BSOD is:=0Apci_msitranslate=3D0=0Apci_power=
_mgmt=3D0=0A=0A- Windows 7 32bits=0A- Nvidia drivers 275.33=0A- You have to=
 manually run aero speed test or force aero to start by using registry entr=
ies for the desktop not to be laggy=0A=0AThe windows 7 domU is running fine=
 with no performance decrease noticeable, although i've not yet played inte=
nsive gpu video game, i'm still pretty confident they'll run fine.=0A=0AAny=
way. i've still some problems i shall report in separate posts :=0A- The PC=
I bus topology isn't preserved, and the gfx card, which is plugged on 01:00=
 becomes 05:00 on domU.=0A- I'm passing through an RME Hdsp / hammerfall pc=
i sound card to the domU and while it is working fine on his own, there's a=
 strange interaction between it and the GPLPV network driver. When i start =
playing sound, the network instantly cease working. It starts back as soon =
as i stop playing audio.=0A=0AThat's all folks,=0A=0ACheers,=0ALta=0A=0A___=
____________________________________________=0AXen-devel mailing list=0AXen=
-devel@lists.xensource.com=0Ahttp://lists.xensource.com/xen-devel
--478945831-155259025-1325888638=:86498
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>Could you =
tell me what version of Xen? 4.1.0? 4.1.2?</span></div><div><br><span></spa=
n></div><div><span>By the way could you send your patches attached to a mai=
l so I could try?</span></div><div><br><span></span></div><div><span>Test o=
n Xen 4.2 failed (desktop stays to lag...)</span></div><div><br><span></spa=
n></div><div><span>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU bo=
ot but nothing appears on screen.</span></div><div><br><span></span></div><=
div><span>Strange.<br></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> -+=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <=
b><span
 style=3D"font-weight: bold;">=C0&nbsp;:</span></b> xen-devel@lists.xensour=
ce.com <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span></b> =
Vendredi 6 Janvier 2012 17h48<br> <b><span style=3D"font-weight: bold;">Obj=
et&nbsp;:</span></b> [Xen-devel] Secondary VGA Passthrough, nvidia, win7: s=
uccess report.<br> </font> <br><div id=3D"yiv301820163"><div class=3D"yiv30=
1820163gmail_quote">Hello xen-devel,<div><br></div><div><br></div><div>This=
 is my first post on this list and as such i might be breaking some explici=
t/implicit rules and i apologize if it's the case. Maybe this list isn't th=
e exact&nbsp;right&nbsp;kind of place where to post this kind of stuff, but=
 i know lots of us are browsing this list as the primary source of document=
ation for xen.</div>=0A=0A<div><br></div><div>I've read many times windows =
7 isn't the right os to run on top of xen. Most of the guy's who are runnin=
g vga passthru are recommanding to use windows xp, and i've never seen any =
success report of vga passthru on windows 7 so i thought it was important t=
o post mine.</div>=0A=0A<div><br></div><div>Anyway, here's my hardware setu=
p :</div><div>- Gigabyte GA-990X-UD3</div><div>-&nbsp;AMD Phenom II X6 1075=
T Processor</div><div>- MSI Cyclone NVIDIA Geforce GTX 460</div><div><br></=
div><div>On the software side i'm using :</div>=0A=0A<div><br></div><div>- =
Debian testing as Dom0</div><div>- Xen-4.1 (debian version 4.1.2-2) with wh=
at's now referred to as "Tobias Geiger patches" (<a rel=3D"nofollow" target=
=3D"_blank" href=3D"http://old-list-archives.xen.org/archives/html/xen-deve=
l/2010-05/msg00441.html">http://old-list-archives.xen.org/archives/html/xen=
-devel/2010-05/msg00441.html</a>) (You have to edit the patches, changing t=
he path to some qemu source files for them to apply)</div>=0A=0A<div>- debi=
an's kernel &nbsp;3.1.5, compiled to include the pciback driver. Here's the=
 output of `cat /boot/my3.1.5config | grep -i xen`</div><div><div><font siz=
e=3D"1">CONFIG_XEN=3Dy</font></div><div>=0A<font size=3D"1">CONFIG_XEN_DOM0=
=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</fon=
t></div><div><font size=3D"1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><fon=
t size=3D"1">CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><font size=
=3D"1">CONFIG_XEN_SAVE_RESTORE=3Dy</font></div><div><font size=3D"1"># CONF=
IG_XEN_DEBUG_FS is not set</font></div>=0A<div><font size=3D"1"># CONFIG_XE=
N_DEBUG is not set</font></div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy</fo=
nt></div><div><font size=3D"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></div>=
=0A<div><font size=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><f=
ont size=3D"1">CONFIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D=
"1">CONFIG_NETXEN_NIC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_N=
ETDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_NETDEV_BACK=
END=3Dm</font></div><div><font size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTEND=
=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><d=
iv><font size=3D"1">CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CO=
NFIG_XEN_FBDEV_FRONTEND=3Dy</font></div>=0A<div><font size=3D"1"># Xen driv=
er support</font></div><div><font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font><=
/div><div><font size=3D"1"># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set</=
font></div>=0A<div><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div>=
<div><font size=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=
=3D"1">CONFIG_XEN_BACKEND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_X=
ENFS=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</fon=
t></div><div><font size=3D"1">CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=0A=
<div><font size=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_GRANT_DEV_ALLOC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_PLA=
TFORM_PCI=3Dm</font></div><div><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</fon=
t></div><div><font size=3D"1">CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=0A=
</div><div><font size=3D"1"><br></font></div><div>The kernel boot options a=
re 'nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:0=
0.1)'</div><div><br></div><div>- Here's my win7 domU config file :</div>=0A=
=0A<div><br></div><div><div><font size=3D"1">kernel =3D "/usr/lib/xen-4.1/b=
oot/hvmloader"</font></div><div><font size=3D"1">builder=3D'hvm'</font></di=
v><div><font size=3D"1">memory =3D 3072</font></div>=0A<div><font size=3D"1=
">name =3D "w7"</font></div><div><font size=3D"1">vif =3D [ 'type=3Dnetfron=
t,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62']</font></div><div><font size=3D=
"1">disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w'=
]</font></div>=0A=0A<div><font size=3D"1">device_model =3D '/usr/lib/xen-4.=
1/bin/qemu-dm'</font></div><div><font size=3D"1">boot=3D"dc"</font></div><d=
iv><font size=3D"1"><br>=0A</font></div><div><font size=3D"1">pci=3D['01:00=
.0','01:00.1']</font></div><div><font size=3D"1">gfx_passthru=3D1</font></d=
iv><div><font size=3D"1"><br>=0A</font></div><div><font size=3D"1">vcpus=3D=
6</font></div><div><font size=3D"1">acpi=3D1</font></div><div><font size=3D=
"1">sdl=3D0</font></div><div><font size=3D"1">vnc=3D1</font></div>=0A<div><=
font size=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncpasswd=
=3D''</font></div><div><font size=3D"1">serial=3D'pty'</font></div>=0A<div>=
<font size=3D"1">usbdevice=3D'tablet'</font></div><div><font size=3D"1">pae=
=3D1</font></div><div><font size=3D"1">pci_msitranslate=3D0</font></div>=0A=
<div><font size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">=
acpi_s3 =3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><=
div><font size=3D"1">on_poweroff =3D 'destroy'</font></div>=0A<div><font si=
ze=3D"1">on_reboot &nbsp; =3D 'restart'</font></div><div><font size=3D"1">o=
n_crash &nbsp; &nbsp;=3D 'restart'</font></div><div><font size=3D"1">xen_pl=
atform_pci=3D1</font></div>=0A<div><font size=3D"1">hpet =3D 1</font></div>=
<div><font size=3D"1">viridian=3D1</font></div><div><font size=3D"1">monito=
r=3D1</font></div><div><font size=3D"1">xen_extended_power_mgmt=3D2</font><=
/div>=0A<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><di=
v>What's important here for the Nvidia drivers to work and not give a nice =
nvlddmkm.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0<=
/font></div>=0A=0A<div><font size=3D"1">pci_power_mgmt=3D0</font></div></di=
v><div><font size=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>=
- Nvidia drivers 275.33</div><div>- You have to manually run aero speed tes=
t or force aero to start by using registry entries for the desktop not to b=
e laggy</div>=0A=0A<div><br></div><div>The windows 7 domU is running fine w=
ith no performance decrease noticeable, although i've not yet played intens=
ive gpu video game, i'm still pretty confident they'll run fine.</div><div>=
<br>=0A=0A</div><div>Anyway. i've still some problems i shall report in sep=
arate posts :</div><div>- The PCI bus topology isn't preserved, and the gfx=
 card, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I'm pas=
sing through an RME Hdsp / hammerfall pci sound card to the domU and while =
it is working fine on his own, there's a strange interaction between it and=
 the GPLPV network driver. When i start playing sound, the network instantl=
y cease working. It starts back as soon as i stop playing audio.</div>=0A=
=0A<div><br></div><div>That's all folks,</div><div><br></div><div>Cheers,</=
div><div>Lta</div>=0A</div><br>=0A</div><br>_______________________________=
________________<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-deve=
l@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-de=
vel@lists.xensource.com</a><br><a href=3D"http://lists.xensource.com/xen-de=
vel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br><br><br>=
 </div> </div>  </div></body></html>
--478945831-155259025-1325888638=:86498--


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

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

--===============5153699869455889023==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 02:18:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 02:18:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjLqV-0001q8-9u; Sat, 07 Jan 2012 02:17:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elthariel@gmail.com>) id 1RjLqU-0001q3-2c
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 02:17:22 +0000
X-Env-Sender: elthariel@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325902633!9998040!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30788 invoked from network); 7 Jan 2012 02:17:14 -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;
	7 Jan 2012 02:17:14 -0000
Received: by qaea17 with SMTP id a17so8315037qae.9
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 18:17:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XVYy3D9KyCUTqqOK1CDFMQPR0XRxRfXEuLySWmuoHC8=;
	b=A4Td2wdn7W6eBX296ZS5HceGIqjI7+YXPucHfxcivrIcHhMIelL0Ymn0UpTx1uDmRa
	EPIPEc+V460asmJUHTrw2bOjdv1eUHVibHJ9i0USRqYm/YoRFbwf/g9XCpx3fdDgm2GX
	udwKY8e27o8w5fMsF/J8BtcgSZfDJdR73AkCo=
MIME-Version: 1.0
Received: by 10.224.178.207 with SMTP id bn15mr10780503qab.34.1325902633200;
	Fri, 06 Jan 2012 18:17:13 -0800 (PST)
Received: by 10.229.95.3 with HTTP; Fri, 6 Jan 2012 18:17:13 -0800 (PST)
In-Reply-To: <1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 03:17:13 +0100
X-Google-Sender-Auth: 186nFoNe-ALOqL4VOlqKZ8DLVnM
Message-ID: <CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
From: "-+= Lta =+-" <lta@akr.fm>
To: David TECHER <davidtecher@yahoo.fr>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1595756803892991872=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1595756803892991872==
Content-Type: multipart/alternative; boundary=20cf30334b05756bed04b5e6c365

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

Hi,

On Fri, Jan 6, 2012 at 11:23 PM, David TECHER <davidtecher@yahoo.fr> wrote:

> Could you tell me what version of Xen? 4.1.0? 4.1.2?
>

As it is stated before this is a 4.1.2 version with debian patches


>
> By the way could you send your patches attached to a mail so I could try?
>

- There's also a link to tobias patche's on the first post.


>
> Test on Xen 4.2 failed (desktop stays to lag...)
>

Have u tried to force windows to activate the aero desktop ?


>
> With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but nothing
> appears on screen.
>

I also followed tobias (same as yours) instructions to dump and build
vgabios-pt.bin into xen, did u do it also ?


>
> Strange.
>
>   ------------------------------
> *De :* -+=3D Lta =3D+- <lta@akr.fm>
> *=C0 :* xen-devel@lists.xensource.com
> *Envoy=E9 le :* Vendredi 6 Janvier 2012 17h48
> *Objet :* [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success
> report.
>
> Hello xen-devel,
>
>
> This is my first post on this list and as such i might be breaking some
> explicit/implicit rules and i apologize if it's the case. Maybe this list
> isn't the exact right kind of place where to post this kind of stuff, but=
 i
> know lots of us are browsing this list as the primary source of
> documentation for xen.
>
> I've read many times windows 7 isn't the right os to run on top of xen.
> Most of the guy's who are running vga passthru are recommanding to use
> windows xp, and i've never seen any success report of vga passthru on
> windows 7 so i thought it was important to post mine.
>
> Anyway, here's my hardware setup :
> - Gigabyte GA-990X-UD3
> - AMD Phenom II X6 1075T Processor
> - MSI Cyclone NVIDIA Geforce GTX 460
>
> On the software side i'm using :
>
> - Debian testing as Dom0
> - Xen-4.1 (debian version 4.1.2-2) with what's now referred to as "Tobias
> Geiger patches" (
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441=
.html)
> (You have to edit the patches, changing the path to some qemu source file=
s
> for them to apply)
> - debian's kernel  3.1.5, compiled to include the pciback driver. Here's
> the output of `cat /boot/my3.1.5config | grep -i xen`
> CONFIG_XEN=3Dy
> CONFIG_XEN_DOM0=3Dy
> CONFIG_XEN_PRIVILEGED_GUEST=3Dy
> CONFIG_XEN_PVHVM=3Dy
> CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128
> CONFIG_XEN_SAVE_RESTORE=3Dy
> # CONFIG_XEN_DEBUG_FS is not set
> # CONFIG_XEN_DEBUG is not set
> CONFIG_PCI_XEN=3Dy
> CONFIG_XEN_PCIDEV_FRONTEND=3Dm
> CONFIG_XEN_BLKDEV_FRONTEND=3Dm
> CONFIG_XEN_BLKDEV_BACKEND=3Dm
> CONFIG_NETXEN_NIC=3Dm
> CONFIG_XEN_NETDEV_FRONTEND=3Dm
> CONFIG_XEN_NETDEV_BACKEND=3Dm
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy
> CONFIG_HVC_XEN=3Dy
> CONFIG_XEN_WDT=3Dm
> CONFIG_XEN_FBDEV_FRONTEND=3Dy
> # Xen driver support
> CONFIG_XEN_BALLOON=3Dy
> # CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
> CONFIG_XEN_SCRUB_PAGES=3Dy
> CONFIG_XEN_DEV_EVTCHN=3Dm
> CONFIG_XEN_BACKEND=3Dy
> CONFIG_XENFS=3Dm
> CONFIG_XEN_COMPAT_XENFS=3Dy
> CONFIG_XEN_SYS_HYPERVISOR=3Dy
> CONFIG_XEN_XENBUS_FRONTEND=3Dy
> CONFIG_XEN_GNTDEV=3Dm
> CONFIG_XEN_GRANT_DEV_ALLOC=3Dm
> CONFIG_XEN_PLATFORM_PCI=3Dm
> CONFIG_SWIOTLB_XEN=3Dy
> CONFIG_XEN_PCIDEV_BACKEND=3Dy
>
> The kernel boot options are 'nomodeset xen-pciback.passthrough=3D1
> xen-pciback.hide=3D(01:00.0)(01:00.1)'
>
> - Here's my win7 domU config file :
>
> kernel =3D "/usr/lib/xen-4.1/boot/hvmloader"
> builder=3D'hvm'
> memory =3D 3072
> name =3D "w7"
> vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62']
> disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']
> device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'
> boot=3D"dc"
>
> pci=3D['01:00.0','01:00.1']
> gfx_passthru=3D1
>
> vcpus=3D6
> acpi=3D1
> sdl=3D0
> vnc=3D1
> vncconsole=3D1
> vncpasswd=3D''
> serial=3D'pty'
> usbdevice=3D'tablet'
> pae=3D1
> pci_msitranslate=3D0
> pci_power_mgmt=3D0
> acpi_s3 =3D 1
> acpi_s4 =3D 1
> on_poweroff =3D 'destroy'
> on_reboot   =3D 'restart'
> on_crash    =3D 'restart'
> xen_platform_pci=3D1
> hpet =3D 1
> viridian=3D1
> monitor=3D1
> xen_extended_power_mgmt=3D2
> hpet=3D1
>
> What's important here for the Nvidia drivers to work and not give a nice
> nvlddmkm.sys BSOD is:
> pci_msitranslate=3D0
> pci_power_mgmt=3D0
>
> - Windows 7 32bits
> - Nvidia drivers 275.33
> - You have to manually run aero speed test or force aero to start by usin=
g
> registry entries for the desktop not to be laggy
>
> The windows 7 domU is running fine with no performance decrease
> noticeable, although i've not yet played intensive gpu video game, i'm
> still pretty confident they'll run fine.
>
> Anyway. i've still some problems i shall report in separate posts :
> - The PCI bus topology isn't preserved, and the gfx card, which is plugge=
d
> on 01:00 becomes 05:00 on domU.
> - I'm passing through an RME Hdsp / hammerfall pci sound card to the domU
> and while it is working fine on his own, there's a strange interaction
> between it and the GPLPV network driver. When i start playing sound, the
> network instantly cease working. It starts back as soon as i stop playing
> audio.
>
> That's all folks,
>
> Cheers,
> Lta
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>

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

Hi,<br><br><div class=3D"gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, Davi=
d TECHER <span dir=3D"ltr">&lt;<a href=3D"mailto:davidtecher@yahoo.fr">davi=
dtecher@yahoo.fr</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><div style=3D"font-size:12pt;font-family:times new roman,new york,time=
s,serif"><div><span>Could you tell me what version of Xen? 4.1.0? 4.1.2?</s=
pan></div></div></div></blockquote><div><br></div><div>As it is stated befo=
re this is a 4.1.2 version with debian patches</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div><div style=3D"font-size:1=
2pt;font-family:times new roman,new york,times,serif"><div><br><span></span=
></div>
<div><span>By the way could you send your patches attached to a mail so I c=
ould try?</span></div></div></div></blockquote><div><br></div><div>- There&=
#39;s also a link to tobias patche&#39;s on the first post.</div><div>=A0</=
div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div style=3D"font-size:12pt;font-famil=
y:times new roman,new york,times,serif"><div><br><span></span></div><div><s=
pan>Test on Xen 4.2 failed (desktop stays to lag...)</span></div>
</div></div></blockquote><div><br></div><div>Have u tried to force windows =
to activate the aero desktop ?</div><div>=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div><div style=3D"font-size:12pt;font-family:times new roman,new york,time=
s,serif"><div><br><span></span></div><div><span>With installing xen 4.1.0/4=
.2.0 over my xen 4.2, domU boot but nothing appears on screen.</span></div>
</div></div></blockquote><div><br></div><div>I also followed tobias (same a=
s yours) instructions to dump and build vgabios-pt.bin into xen, did u do i=
t also ?</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style=3D"font-size:12pt;font-family:times new roman,new york,time=
s,serif"><div><br><span></span></div><div><span>Strange.<br></span></div><d=
iv><br></div>  <div style=3D"font-family:times new roman,new york,times,ser=
if;font-size:12pt">
 <div style=3D"font-family:times new roman,new york,times,serif;font-size:1=
2pt"> <font face=3D"Arial"><div class=3D"im"> <hr size=3D"1">  <b><span sty=
le=3D"font-weight:bold">De=A0:</span></b> -+=3D Lta =3D+- &lt;<a href=3D"ma=
ilto:lta@akr.fm" target=3D"_blank">lta@akr.fm</a>&gt;<br>
 </div><b><span style=3D"font-weight:bold">=C0=A0:</span></b> <a href=3D"ma=
ilto:xen-devel@lists.xensource.com" target=3D"_blank">xen-devel@lists.xenso=
urce.com</a> <br> <b><span style=3D"font-weight:bold">Envoy=E9 le :</span><=
/b> Vendredi 6 Janvier 2012 17h48<br>
 <b><span style=3D"font-weight:bold">Objet=A0:</span></b> [Xen-devel] Secon=
dary VGA Passthrough, nvidia, win7: success report.<br> </font><div><div cl=
ass=3D"h5"> <br><div><div>Hello xen-devel,<div><br></div><div><br></div><di=
v>
This is my first post on this list and as such i might be breaking some exp=
licit/implicit rules and i apologize if it&#39;s the case. Maybe this list =
isn&#39;t the exact=A0right=A0kind of place where to post this kind of stuf=
f, but i know lots of us are browsing this list as the primary source of do=
cumentation for xen.</div>


<div><br></div><div>I&#39;ve read many times windows 7 isn&#39;t the right =
os to run on top of xen. Most of the guy&#39;s who are running vga passthru=
 are recommanding to use windows xp, and i&#39;ve never seen any success re=
port of vga passthru on windows 7 so i thought it was important to post min=
e.</div>


<div><br></div><div>Anyway, here&#39;s my hardware setup :</div><div>- Giga=
byte GA-990X-UD3</div><div>-=A0AMD Phenom II X6 1075T Processor</div><div>-=
 MSI Cyclone NVIDIA Geforce GTX 460</div><div><br></div><div>On the softwar=
e side i&#39;m using :</div>


<div><br></div><div>- Debian testing as Dom0</div><div>- Xen-4.1 (debian ve=
rsion 4.1.2-2) with what&#39;s now referred to as &quot;Tobias Geiger patch=
es&quot; (<a rel=3D"nofollow" href=3D"http://old-list-archives.xen.org/arch=
ives/html/xen-devel/2010-05/msg00441.html" target=3D"_blank">http://old-lis=
t-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html</a>) (You =
have to edit the patches, changing the path to some qemu source files for t=
hem to apply)</div>


<div>- debian&#39;s kernel =A03.1.5, compiled to include the pciback driver=
. Here&#39;s the output of `cat /boot/my3.1.5config | grep -i xen`</div><di=
v><div><font size=3D"1">CONFIG_XEN=3Dy</font></div><div>
<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><div><font size=3D"1">CONF=
IG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_PV=
HVM=3Dy</font></div>
<div><font size=3D"1">CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><=
font size=3D"1">CONFIG_XEN_SAVE_RESTORE=3Dy</font></div><div><font size=3D"=
1"># CONFIG_XEN_DEBUG_FS is not set</font></div>
<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set</font></div><div><font =
size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_=
PCIDEV_FRONTEND=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font=
 size=3D"1">CONFIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D"1"=
>CONFIG_NETXEN_NIC=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm</font></div><div><font=
 size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></div><div><font size=3D"1"=
>CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>
<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"1">=
CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FRONT=
END=3Dy</font></div>
<div><font size=3D"1"># Xen driver support</font></div><div><font size=3D"1=
">CONFIG_XEN_BALLOON=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_BAL=
LOON_MEMORY_HOTPLUG is not set</font></div>
<div><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font siz=
e=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_BACKEND=3Dy</font></div>
<div><font size=3D"1">CONFIG_XENFS=3Dm</font></div><div><font size=3D"1">CO=
NFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_SYS_=
HYPERVISOR=3Dy</font></div>
<div><font size=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_GRANT_DEV_ALLOC=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</font></div><div><font si=
ze=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XE=
N_PCIDEV_BACKEND=3Dy</font></div>
</div><div><font size=3D"1"><br></font></div><div>The kernel boot options a=
re &#39;nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(=
01:00.1)&#39;</div><div><br></div><div>- Here&#39;s my win7 domU config fil=
e :</div>


<div><br></div><div><div><font size=3D"1">kernel =3D &quot;/usr/lib/xen-4.1=
/boot/hvmloader&quot;</font></div><div><font size=3D"1">builder=3D&#39;hvm&=
#39;</font></div><div><font size=3D"1">memory =3D 3072</font></div>
<div><font size=3D"1">name =3D &quot;w7&quot;</font></div><div><font size=
=3D"1">vif =3D [ &#39;type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49=
:62&#39;]</font></div><div><font size=3D"1">disk =3D [ &#39;phy:/dev/w7-xen=
/system,hda,w&#39;, &#39;phy:/dev/w7-xen/appz,hdb,w&#39;]</font></div>


<div><font size=3D"1">device_model =3D &#39;/usr/lib/xen-4.1/bin/qemu-dm&#3=
9;</font></div><div><font size=3D"1">boot=3D&quot;dc&quot;</font></div><div=
><font size=3D"1"><br>
</font></div><div><font size=3D"1">pci=3D[&#39;01:00.0&#39;,&#39;01:00.1&#3=
9;]</font></div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><fo=
nt size=3D"1"><br>
</font></div><div><font size=3D"1">vcpus=3D6</font></div><div><font size=3D=
"1">acpi=3D1</font></div><div><font size=3D"1">sdl=3D0</font></div><div><fo=
nt size=3D"1">vnc=3D1</font></div>
<div><font size=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncp=
asswd=3D&#39;&#39;</font></div><div><font size=3D"1">serial=3D&#39;pty&#39;=
</font></div>
<div><font size=3D"1">usbdevice=3D&#39;tablet&#39;</font></div><div><font s=
ize=3D"1">pae=3D1</font></div><div><font size=3D"1">pci_msitranslate=3D0</f=
ont></div>
<div><font size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">=
acpi_s3 =3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><=
div><font size=3D"1">on_poweroff =3D &#39;destroy&#39;</font></div>
<div><font size=3D"1">on_reboot =A0 =3D &#39;restart&#39;</font></div><div>=
<font size=3D"1">on_crash =A0 =A0=3D &#39;restart&#39;</font></div><div><fo=
nt size=3D"1">xen_platform_pci=3D1</font></div>
<div><font size=3D"1">hpet =3D 1</font></div><div><font size=3D"1">viridian=
=3D1</font></div><div><font size=3D"1">monitor=3D1</font></div><div><font s=
ize=3D"1">xen_extended_power_mgmt=3D2</font></div>
<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><div>What&#=
39;s important here for the Nvidia drivers to work and not give a nice nvld=
dmkm.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0</fon=
t></div>


<div><font size=3D"1">pci_power_mgmt=3D0</font></div></div><div><font size=
=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvidia drivers =
275.33</div><div>- You have to manually run aero speed test or force aero t=
o start by using registry entries for the desktop not to be laggy</div>


<div><br></div><div>The windows 7 domU is running fine with no performance =
decrease noticeable, although i&#39;ve not yet played intensive gpu video g=
ame, i&#39;m still pretty confident they&#39;ll run fine.</div><div><br>


</div><div>Anyway. i&#39;ve still some problems i shall report in separate =
posts :</div><div>- The PCI bus topology isn&#39;t preserved, and the gfx c=
ard, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I&#39;m p=
assing through an RME Hdsp / hammerfall pci sound card to the domU and whil=
e it is working fine on his own, there&#39;s a strange interaction between =
it and the GPLPV network driver. When i start playing sound, the network in=
stantly cease working. It starts back as soon as i stop playing audio.</div=
>


<div><br></div><div>That&#39;s all folks,</div><div><br></div><div>Cheers,<=
/div><div>Lta</div>
</div><br>
</div><br></div></div><div class=3D"im">___________________________________=
____________<br>Xen-devel mailing list<br><a href=3D"mailto:Xen-devel@lists=
.xensource.com" target=3D"_blank">Xen-devel@lists.xensource.com</a><br><a h=
ref=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://lists=
.xensource.com/xen-devel</a><br>
<br><br> </div></div> </div>  </div></div></blockquote></div><br>

--20cf30334b05756bed04b5e6c365--


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

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

--===============1595756803892991872==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 02:18:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 02:18:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjLqV-0001q8-9u; Sat, 07 Jan 2012 02:17:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <elthariel@gmail.com>) id 1RjLqU-0001q3-2c
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 02:17:22 +0000
X-Env-Sender: elthariel@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1325902633!9998040!1
X-Originating-IP: [209.85.216.50]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30788 invoked from network); 7 Jan 2012 02:17:14 -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;
	7 Jan 2012 02:17:14 -0000
Received: by qaea17 with SMTP id a17so8315037qae.9
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 18:17:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=XVYy3D9KyCUTqqOK1CDFMQPR0XRxRfXEuLySWmuoHC8=;
	b=A4Td2wdn7W6eBX296ZS5HceGIqjI7+YXPucHfxcivrIcHhMIelL0Ymn0UpTx1uDmRa
	EPIPEc+V460asmJUHTrw2bOjdv1eUHVibHJ9i0USRqYm/YoRFbwf/g9XCpx3fdDgm2GX
	udwKY8e27o8w5fMsF/J8BtcgSZfDJdR73AkCo=
MIME-Version: 1.0
Received: by 10.224.178.207 with SMTP id bn15mr10780503qab.34.1325902633200;
	Fri, 06 Jan 2012 18:17:13 -0800 (PST)
Received: by 10.229.95.3 with HTTP; Fri, 6 Jan 2012 18:17:13 -0800 (PST)
In-Reply-To: <1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 03:17:13 +0100
X-Google-Sender-Auth: 186nFoNe-ALOqL4VOlqKZ8DLVnM
Message-ID: <CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
From: "-+= Lta =+-" <lta@akr.fm>
To: David TECHER <davidtecher@yahoo.fr>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1595756803892991872=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1595756803892991872==
Content-Type: multipart/alternative; boundary=20cf30334b05756bed04b5e6c365

--20cf30334b05756bed04b5e6c365
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Jan 6, 2012 at 11:23 PM, David TECHER <davidtecher@yahoo.fr> wrote:

> Could you tell me what version of Xen? 4.1.0? 4.1.2?
>

As it is stated before this is a 4.1.2 version with debian patches


>
> By the way could you send your patches attached to a mail so I could try?
>

- There's also a link to tobias patche's on the first post.


>
> Test on Xen 4.2 failed (desktop stays to lag...)
>

Have u tried to force windows to activate the aero desktop ?


>
> With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but nothing
> appears on screen.
>

I also followed tobias (same as yours) instructions to dump and build
vgabios-pt.bin into xen, did u do it also ?


>
> Strange.
>
>   ------------------------------
> *De :* -+=3D Lta =3D+- <lta@akr.fm>
> *=C0 :* xen-devel@lists.xensource.com
> *Envoy=E9 le :* Vendredi 6 Janvier 2012 17h48
> *Objet :* [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success
> report.
>
> Hello xen-devel,
>
>
> This is my first post on this list and as such i might be breaking some
> explicit/implicit rules and i apologize if it's the case. Maybe this list
> isn't the exact right kind of place where to post this kind of stuff, but=
 i
> know lots of us are browsing this list as the primary source of
> documentation for xen.
>
> I've read many times windows 7 isn't the right os to run on top of xen.
> Most of the guy's who are running vga passthru are recommanding to use
> windows xp, and i've never seen any success report of vga passthru on
> windows 7 so i thought it was important to post mine.
>
> Anyway, here's my hardware setup :
> - Gigabyte GA-990X-UD3
> - AMD Phenom II X6 1075T Processor
> - MSI Cyclone NVIDIA Geforce GTX 460
>
> On the software side i'm using :
>
> - Debian testing as Dom0
> - Xen-4.1 (debian version 4.1.2-2) with what's now referred to as "Tobias
> Geiger patches" (
> http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441=
.html)
> (You have to edit the patches, changing the path to some qemu source file=
s
> for them to apply)
> - debian's kernel  3.1.5, compiled to include the pciback driver. Here's
> the output of `cat /boot/my3.1.5config | grep -i xen`
> CONFIG_XEN=3Dy
> CONFIG_XEN_DOM0=3Dy
> CONFIG_XEN_PRIVILEGED_GUEST=3Dy
> CONFIG_XEN_PVHVM=3Dy
> CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128
> CONFIG_XEN_SAVE_RESTORE=3Dy
> # CONFIG_XEN_DEBUG_FS is not set
> # CONFIG_XEN_DEBUG is not set
> CONFIG_PCI_XEN=3Dy
> CONFIG_XEN_PCIDEV_FRONTEND=3Dm
> CONFIG_XEN_BLKDEV_FRONTEND=3Dm
> CONFIG_XEN_BLKDEV_BACKEND=3Dm
> CONFIG_NETXEN_NIC=3Dm
> CONFIG_XEN_NETDEV_FRONTEND=3Dm
> CONFIG_XEN_NETDEV_BACKEND=3Dm
> CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy
> CONFIG_HVC_XEN=3Dy
> CONFIG_XEN_WDT=3Dm
> CONFIG_XEN_FBDEV_FRONTEND=3Dy
> # Xen driver support
> CONFIG_XEN_BALLOON=3Dy
> # CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
> CONFIG_XEN_SCRUB_PAGES=3Dy
> CONFIG_XEN_DEV_EVTCHN=3Dm
> CONFIG_XEN_BACKEND=3Dy
> CONFIG_XENFS=3Dm
> CONFIG_XEN_COMPAT_XENFS=3Dy
> CONFIG_XEN_SYS_HYPERVISOR=3Dy
> CONFIG_XEN_XENBUS_FRONTEND=3Dy
> CONFIG_XEN_GNTDEV=3Dm
> CONFIG_XEN_GRANT_DEV_ALLOC=3Dm
> CONFIG_XEN_PLATFORM_PCI=3Dm
> CONFIG_SWIOTLB_XEN=3Dy
> CONFIG_XEN_PCIDEV_BACKEND=3Dy
>
> The kernel boot options are 'nomodeset xen-pciback.passthrough=3D1
> xen-pciback.hide=3D(01:00.0)(01:00.1)'
>
> - Here's my win7 domU config file :
>
> kernel =3D "/usr/lib/xen-4.1/boot/hvmloader"
> builder=3D'hvm'
> memory =3D 3072
> name =3D "w7"
> vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62']
> disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']
> device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'
> boot=3D"dc"
>
> pci=3D['01:00.0','01:00.1']
> gfx_passthru=3D1
>
> vcpus=3D6
> acpi=3D1
> sdl=3D0
> vnc=3D1
> vncconsole=3D1
> vncpasswd=3D''
> serial=3D'pty'
> usbdevice=3D'tablet'
> pae=3D1
> pci_msitranslate=3D0
> pci_power_mgmt=3D0
> acpi_s3 =3D 1
> acpi_s4 =3D 1
> on_poweroff =3D 'destroy'
> on_reboot   =3D 'restart'
> on_crash    =3D 'restart'
> xen_platform_pci=3D1
> hpet =3D 1
> viridian=3D1
> monitor=3D1
> xen_extended_power_mgmt=3D2
> hpet=3D1
>
> What's important here for the Nvidia drivers to work and not give a nice
> nvlddmkm.sys BSOD is:
> pci_msitranslate=3D0
> pci_power_mgmt=3D0
>
> - Windows 7 32bits
> - Nvidia drivers 275.33
> - You have to manually run aero speed test or force aero to start by usin=
g
> registry entries for the desktop not to be laggy
>
> The windows 7 domU is running fine with no performance decrease
> noticeable, although i've not yet played intensive gpu video game, i'm
> still pretty confident they'll run fine.
>
> Anyway. i've still some problems i shall report in separate posts :
> - The PCI bus topology isn't preserved, and the gfx card, which is plugge=
d
> on 01:00 becomes 05:00 on domU.
> - I'm passing through an RME Hdsp / hammerfall pci sound card to the domU
> and while it is working fine on his own, there's a strange interaction
> between it and the GPLPV network driver. When i start playing sound, the
> network instantly cease working. It starts back as soon as i stop playing
> audio.
>
> That's all folks,
>
> Cheers,
> Lta
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>

--20cf30334b05756bed04b5e6c365
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br><div class=3D"gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, Davi=
d TECHER <span dir=3D"ltr">&lt;<a href=3D"mailto:davidtecher@yahoo.fr">davi=
dtecher@yahoo.fr</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><div style=3D"font-size:12pt;font-family:times new roman,new york,time=
s,serif"><div><span>Could you tell me what version of Xen? 4.1.0? 4.1.2?</s=
pan></div></div></div></blockquote><div><br></div><div>As it is stated befo=
re this is a 4.1.2 version with debian patches</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div><div style=3D"font-size:1=
2pt;font-family:times new roman,new york,times,serif"><div><br><span></span=
></div>
<div><span>By the way could you send your patches attached to a mail so I c=
ould try?</span></div></div></div></blockquote><div><br></div><div>- There&=
#39;s also a link to tobias patche&#39;s on the first post.</div><div>=A0</=
div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div style=3D"font-size:12pt;font-famil=
y:times new roman,new york,times,serif"><div><br><span></span></div><div><s=
pan>Test on Xen 4.2 failed (desktop stays to lag...)</span></div>
</div></div></blockquote><div><br></div><div>Have u tried to force windows =
to activate the aero desktop ?</div><div>=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div><div style=3D"font-size:12pt;font-family:times new roman,new york,time=
s,serif"><div><br><span></span></div><div><span>With installing xen 4.1.0/4=
.2.0 over my xen 4.2, domU boot but nothing appears on screen.</span></div>
</div></div></blockquote><div><br></div><div>I also followed tobias (same a=
s yours) instructions to dump and build vgabios-pt.bin into xen, did u do i=
t also ?</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style=3D"font-size:12pt;font-family:times new roman,new york,time=
s,serif"><div><br><span></span></div><div><span>Strange.<br></span></div><d=
iv><br></div>  <div style=3D"font-family:times new roman,new york,times,ser=
if;font-size:12pt">
 <div style=3D"font-family:times new roman,new york,times,serif;font-size:1=
2pt"> <font face=3D"Arial"><div class=3D"im"> <hr size=3D"1">  <b><span sty=
le=3D"font-weight:bold">De=A0:</span></b> -+=3D Lta =3D+- &lt;<a href=3D"ma=
ilto:lta@akr.fm" target=3D"_blank">lta@akr.fm</a>&gt;<br>
 </div><b><span style=3D"font-weight:bold">=C0=A0:</span></b> <a href=3D"ma=
ilto:xen-devel@lists.xensource.com" target=3D"_blank">xen-devel@lists.xenso=
urce.com</a> <br> <b><span style=3D"font-weight:bold">Envoy=E9 le :</span><=
/b> Vendredi 6 Janvier 2012 17h48<br>
 <b><span style=3D"font-weight:bold">Objet=A0:</span></b> [Xen-devel] Secon=
dary VGA Passthrough, nvidia, win7: success report.<br> </font><div><div cl=
ass=3D"h5"> <br><div><div>Hello xen-devel,<div><br></div><div><br></div><di=
v>
This is my first post on this list and as such i might be breaking some exp=
licit/implicit rules and i apologize if it&#39;s the case. Maybe this list =
isn&#39;t the exact=A0right=A0kind of place where to post this kind of stuf=
f, but i know lots of us are browsing this list as the primary source of do=
cumentation for xen.</div>


<div><br></div><div>I&#39;ve read many times windows 7 isn&#39;t the right =
os to run on top of xen. Most of the guy&#39;s who are running vga passthru=
 are recommanding to use windows xp, and i&#39;ve never seen any success re=
port of vga passthru on windows 7 so i thought it was important to post min=
e.</div>


<div><br></div><div>Anyway, here&#39;s my hardware setup :</div><div>- Giga=
byte GA-990X-UD3</div><div>-=A0AMD Phenom II X6 1075T Processor</div><div>-=
 MSI Cyclone NVIDIA Geforce GTX 460</div><div><br></div><div>On the softwar=
e side i&#39;m using :</div>


<div><br></div><div>- Debian testing as Dom0</div><div>- Xen-4.1 (debian ve=
rsion 4.1.2-2) with what&#39;s now referred to as &quot;Tobias Geiger patch=
es&quot; (<a rel=3D"nofollow" href=3D"http://old-list-archives.xen.org/arch=
ives/html/xen-devel/2010-05/msg00441.html" target=3D"_blank">http://old-lis=
t-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html</a>) (You =
have to edit the patches, changing the path to some qemu source files for t=
hem to apply)</div>


<div>- debian&#39;s kernel =A03.1.5, compiled to include the pciback driver=
. Here&#39;s the output of `cat /boot/my3.1.5config | grep -i xen`</div><di=
v><div><font size=3D"1">CONFIG_XEN=3Dy</font></div><div>
<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><div><font size=3D"1">CONF=
IG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_PV=
HVM=3Dy</font></div>
<div><font size=3D"1">CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><=
font size=3D"1">CONFIG_XEN_SAVE_RESTORE=3Dy</font></div><div><font size=3D"=
1"># CONFIG_XEN_DEBUG_FS is not set</font></div>
<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set</font></div><div><font =
size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_=
PCIDEV_FRONTEND=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font=
 size=3D"1">CONFIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D"1"=
>CONFIG_NETXEN_NIC=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm</font></div><div><font=
 size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></div><div><font size=3D"1"=
>CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>
<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"1">=
CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FRONT=
END=3Dy</font></div>
<div><font size=3D"1"># Xen driver support</font></div><div><font size=3D"1=
">CONFIG_XEN_BALLOON=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_BAL=
LOON_MEMORY_HOTPLUG is not set</font></div>
<div><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font siz=
e=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_BACKEND=3Dy</font></div>
<div><font size=3D"1">CONFIG_XENFS=3Dm</font></div><div><font size=3D"1">CO=
NFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_SYS_=
HYPERVISOR=3Dy</font></div>
<div><font size=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_=
XEN_GRANT_DEV_ALLOC=3Dm</font></div>
<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</font></div><div><font si=
ze=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XE=
N_PCIDEV_BACKEND=3Dy</font></div>
</div><div><font size=3D"1"><br></font></div><div>The kernel boot options a=
re &#39;nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(=
01:00.1)&#39;</div><div><br></div><div>- Here&#39;s my win7 domU config fil=
e :</div>


<div><br></div><div><div><font size=3D"1">kernel =3D &quot;/usr/lib/xen-4.1=
/boot/hvmloader&quot;</font></div><div><font size=3D"1">builder=3D&#39;hvm&=
#39;</font></div><div><font size=3D"1">memory =3D 3072</font></div>
<div><font size=3D"1">name =3D &quot;w7&quot;</font></div><div><font size=
=3D"1">vif =3D [ &#39;type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49=
:62&#39;]</font></div><div><font size=3D"1">disk =3D [ &#39;phy:/dev/w7-xen=
/system,hda,w&#39;, &#39;phy:/dev/w7-xen/appz,hdb,w&#39;]</font></div>


<div><font size=3D"1">device_model =3D &#39;/usr/lib/xen-4.1/bin/qemu-dm&#3=
9;</font></div><div><font size=3D"1">boot=3D&quot;dc&quot;</font></div><div=
><font size=3D"1"><br>
</font></div><div><font size=3D"1">pci=3D[&#39;01:00.0&#39;,&#39;01:00.1&#3=
9;]</font></div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><fo=
nt size=3D"1"><br>
</font></div><div><font size=3D"1">vcpus=3D6</font></div><div><font size=3D=
"1">acpi=3D1</font></div><div><font size=3D"1">sdl=3D0</font></div><div><fo=
nt size=3D"1">vnc=3D1</font></div>
<div><font size=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncp=
asswd=3D&#39;&#39;</font></div><div><font size=3D"1">serial=3D&#39;pty&#39;=
</font></div>
<div><font size=3D"1">usbdevice=3D&#39;tablet&#39;</font></div><div><font s=
ize=3D"1">pae=3D1</font></div><div><font size=3D"1">pci_msitranslate=3D0</f=
ont></div>
<div><font size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">=
acpi_s3 =3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><=
div><font size=3D"1">on_poweroff =3D &#39;destroy&#39;</font></div>
<div><font size=3D"1">on_reboot =A0 =3D &#39;restart&#39;</font></div><div>=
<font size=3D"1">on_crash =A0 =A0=3D &#39;restart&#39;</font></div><div><fo=
nt size=3D"1">xen_platform_pci=3D1</font></div>
<div><font size=3D"1">hpet =3D 1</font></div><div><font size=3D"1">viridian=
=3D1</font></div><div><font size=3D"1">monitor=3D1</font></div><div><font s=
ize=3D"1">xen_extended_power_mgmt=3D2</font></div>
<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><div>What&#=
39;s important here for the Nvidia drivers to work and not give a nice nvld=
dmkm.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0</fon=
t></div>


<div><font size=3D"1">pci_power_mgmt=3D0</font></div></div><div><font size=
=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvidia drivers =
275.33</div><div>- You have to manually run aero speed test or force aero t=
o start by using registry entries for the desktop not to be laggy</div>


<div><br></div><div>The windows 7 domU is running fine with no performance =
decrease noticeable, although i&#39;ve not yet played intensive gpu video g=
ame, i&#39;m still pretty confident they&#39;ll run fine.</div><div><br>


</div><div>Anyway. i&#39;ve still some problems i shall report in separate =
posts :</div><div>- The PCI bus topology isn&#39;t preserved, and the gfx c=
ard, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I&#39;m p=
assing through an RME Hdsp / hammerfall pci sound card to the domU and whil=
e it is working fine on his own, there&#39;s a strange interaction between =
it and the GPLPV network driver. When i start playing sound, the network in=
stantly cease working. It starts back as soon as i stop playing audio.</div=
>


<div><br></div><div>That&#39;s all folks,</div><div><br></div><div>Cheers,<=
/div><div>Lta</div>
</div><br>
</div><br></div></div><div class=3D"im">___________________________________=
____________<br>Xen-devel mailing list<br><a href=3D"mailto:Xen-devel@lists=
.xensource.com" target=3D"_blank">Xen-devel@lists.xensource.com</a><br><a h=
ref=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://lists=
.xensource.com/xen-devel</a><br>
<br><br> </div></div> </div>  </div></div></blockquote></div><br>

--20cf30334b05756bed04b5e6c365--


--===============1595756803892991872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1595756803892991872==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 02:29:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 02: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 1RjM1R-00023S-PV; Sat, 07 Jan 2012 02:28:41 +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 1RjM1Q-00023N-KO
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 02:28:40 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1325903311!1130579!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 31421 invoked from network); 7 Jan 2012 02:28:34 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Jan 2012 02:28:34 -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 1RjM1E-0006k7-3L
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 13:28:28 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sat, 7 Jan 2012 13:28:27 +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;
	Sat, 7 Jan 2012 13:28:27 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: usbback for linux 3.1?
Thread-Index: AczM4/0cNj6BlRPTSc6NPBw8veRbrw==
Date: Sat, 7 Jan 2012 02:28:24 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0984C5@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: 07 Jan 2012 02:28:27.0463 (UTC)
	FILETIME=[09B8FD70:01CCCCE4]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] usbback for linux 3.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

Is anyone maintaining usbback that compiles against Linux 3.1?

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 Jan 07 02:29:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 02: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 1RjM1R-00023S-PV; Sat, 07 Jan 2012 02:28:41 +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 1RjM1Q-00023N-KO
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 02:28:40 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-16.tower-21.messagelabs.com!1325903311!1130579!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 31421 invoked from network); 7 Jan 2012 02:28:34 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-16.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Jan 2012 02:28:34 -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 1RjM1E-0006k7-3L
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 13:28:28 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sat, 7 Jan 2012 13:28:27 +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;
	Sat, 7 Jan 2012 13:28:27 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: usbback for linux 3.1?
Thread-Index: AczM4/0cNj6BlRPTSc6NPBw8veRbrw==
Date: Sat, 7 Jan 2012 02:28:24 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0984C5@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: 07 Jan 2012 02:28:27.0463 (UTC)
	FILETIME=[09B8FD70:01CCCCE4]
X-Really-From-Bendigo-IT: magichashvalue
Subject: [Xen-devel] usbback for linux 3.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

Is anyone maintaining usbback that compiles against Linux 3.1?

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 Jan 07 03:52:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 03:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjNJn-0002Qz-6h; Sat, 07 Jan 2012 03:51:43 +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 1RjNJk-0002Qu-Jo
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 03:51:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325908293!9931860!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDY2Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18818 invoked from network); 7 Jan 2012 03:51:33 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-182.messagelabs.com with SMTP;
	7 Jan 2012 03:51:33 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 8E95476C06E;
	Fri,  6 Jan 2012 19:51:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=t10NGzLCMHv2SWsiwJ5caixtS+oad1G0KkbDmApGnsr0
	x2NtX8reAN8hIWcw/pmLE8tWB73sELhzIvfkak4qkuMqlTopRBfatGOO2342lIeU
	VDXZBb5sJNT5fZY07LDoYS74WvkwDsBg2f+uot/QhZ0lbf0Tj7exCBrbSBp0xwU=
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=nJHYA5q1NAhOtJT9TbIxE5RY2gg=; b=lL+Kx8PS
	9E5UJ9FWWVLguMu7j3WuLkh5xrvEMWzCCJVyxvhrcmS/CF27fKWac4h6Nt1lT6TR
	OMm3MQi1r7Kou6gDhnoStEqIo0xzRCmWOrWjNRGit2Os6I1oM6b71ybFwcLJgucw
	YfeaS7gnNZ8gV9eBxhg/9qKstUGFzrxVeuI=
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 4E1F976C069; 
	Fri,  6 Jan 2012 19:51:32 -0800 (PST)
Received: from 64.20.10.210 (proxying for 10.1.201.136, 64.20.10.210)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 6 Jan 2012 19:51:32 -0800
Message-ID: <a344dc410cb70b471e31c922ce80d94a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.5929.1325754331.12970.xen-devel@lists.xensource.com>
References: <mailman.5929.1325754331.12970.xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 19:51:32 -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, hongkaixing@huawei.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in process
 to	speed up page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Thu, 5 Jan 2012 09:05:16 +0000
> From: Tim Deegan <tim@xen.org>
> To: hongkaixing@huawei.com
> Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in
> 	process to	speed up page-in in	xenpaging
> Message-ID: <20120105090516.GE15595@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hello,
>
> At 03:50 +0000 on 05 Jan (1325735430), hongkaixing@huawei.com wrote:
>> xenpaging:change page-in process to speed up page-in in xenpaging
>> In this patch,we change the page-in process.Firstly,we add a new
>> function paging_in_trigger_sync
>> to handle page-in requests directly.and when the requests' count is up
>> to 32,then handle them
>> batchly;Most importantly,we use an increasing gfn to test_bit,which
>> saves much time.
>> In p2m.c,we changes p2m_mem_paging_populate() to return a value;
>> The following is a xenpaging test on suse11-64 with 4G memory.
>>
>> Nums of page_out pages	Page out time	Page in time(in unstable code) Page
>> in time(apply this patch)
>> 512M(131072)		    2.6s		        540s		              4.7s
>> 2G(524288)		    15.5s		        2088s		      	      17.7s
>>
>
> Thanks for the patch!  That's an impressive difference.  You're changing
> quite a few things in this patch, though.  Can you send them as separate
> patches so they can be reviewed one at a time?  Is one of them in
> particular making the difference?  I suspect it's mostly the change to
> test_bit(), and the rest is not necessary.

Second that, on all counts. Impressive numbers, and, a bit puzzled as to
what actually made the difference.

I would also like to see changes to xenpaging teased out from changes to
the hypervisor.

I've been sitting on a patch to page-in synchronously, which shortcuts
even more aggressively the page-in path: instead of calling populate, we
go straight into paging_load. This does not necessitate an additional
domctl, and would save even more hypervisor<->pager control round-trips.
Do you foresee any conflicts with your current approach?

Thanks!
Andres

>
> Cheers,
>
> Tim.
>
>> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
>>
>> diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
>> --- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
>> @@ -73,6 +73,13 @@
>>                                  NULL, NULL, gfn);
>>  }
>>
>> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned
>> long gfn)
>> +{
>> +    return xc_mem_event_control(xch, domain_id,
>> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
>> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>> +                                NULL, NULL, gfn);
>> +}
>>
>>  /*
>>   * Local variables:
>> diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
>> @@ -1841,6 +1841,7 @@
>>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned
>> long gfn);
>>  int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
>>                           unsigned long gfn);
>> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned long
>> gfn);
>>
>>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>>                          void *shared_page, void *ring_page);
>> diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
>> --- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
>> @@ -594,6 +594,13 @@
>>      return ret;
>>  }
>>
>> +static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long
>> gfn)
>> +{
>> +    int rc = 0;
>> +    rc = xc_mem_paging_in(paging->xc_handle,
>> paging->mem_event.domain_id,gfn);
>> +    return rc;
>> +}
>
> This function is
>
>> +
>>  int main(int argc, char *argv[])
>>  {
>>      struct sigaction act;
>> @@ -605,6 +612,9 @@
>>      int i;
>>      int rc = -1;
>>      int rc1;
>> +    int request_count = 0;
>> +    unsigned long page_in_start_gfn = 0;
>> +    unsigned long real_page = 0;
>>      xc_interface *xch;
>>
>>      int open_flags = O_CREAT | O_TRUNC | O_RDWR;
>> @@ -773,24 +783,51 @@
>>          /* Write all pages back into the guest */
>>          if ( interrupted == SIGTERM || interrupted == SIGINT )
>>          {
>> -            int num = 0;
>> +            request_count = 0;
>>              for ( i = 0; i < paging->domain_info->max_pages; i++ )
>>              {
>> -                if ( test_bit(i, paging->bitmap) )
>> +                real_page = i + page_in_start_gfn;
>> +                real_page %= paging->domain_info->max_pages;
>> +                if ( test_bit(real_page, paging->bitmap) )
>>                  {
>> -                    paging->pagein_queue[num] = i;
>> -                    num++;
>> -                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
>> -                        break;
>> +                    rc = paging_in_trigger_sync(paging,real_page);
>> +                    if ( 0 == rc )
>> +                    {
>> +                        request_count++;
>> +                        /* If page_in requests up to 32 then handle
>> them */
>> +                        if( request_count >= 32 )
>> +                        {
>> +                            page_in_start_gfn=real_page + 1;
>> +                            break;
>> +                        }
>> +                    }
>> +                    else
>> +                    {
>> +                        /* If IO ring is full then handle requests to
>> free space */
>> +                        if( ENOSPC == errno )
>> +                        {
>> +                            page_in_start_gfn = real_page;
>> +                            break;
>> +                        }
>> +                        /* If p2mt is not p2m_is_paging,then clear
>> bitmap;
>> +                        * e.g. a page is paged then it is dropped by
>> balloon.
>> +                        */
>> +                        else if ( EINVAL == errno )
>> +                        {
>> +                            clear_bit(i,paging->bitmap);
>> +                            policy_notify_paged_in(i);
>> +                        }
>> +                        /* If hypercall fails then go to teardown
>> xenpaging */
>> +                        else
>> +                        {
>> +                            ERROR("Error paging in page");
>> +                            goto out;
>> +                        }
>> +                    }
>>                  }
>>              }
>> -            /*
>> -             * One more round if there are still pages to process.
>> -             * If no more pages to process, exit loop.
>> -             */
>> -            if ( num )
>> -                page_in_trigger();
>> -            else if ( i == paging->domain_info->max_pages )
>> +            if( (i==paging->domain_info->max_pages) &&
>> +
>> !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
>>                  break;
>>          }
>>          else
>> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
>> --- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
>> @@ -57,7 +57,14 @@
>>          return 0;
>>      }
>>      break;
>> -
>> +
>> +    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
>> +    {
>> +        unsigned long gfn = mec->gfn;
>> +        return p2m_mem_paging_populate(d, gfn);
>> +    }
>> +    break;
>> +
>>      default:
>>          return -ENOSYS;
>>          break;
>> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
>> @@ -874,7 +874,7 @@
>>   * already sent to the pager. In this case the caller has to try again
>> until the
>>   * gfn is fully paged in again.
>>   */
>> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>>  {
>>      struct vcpu *v = current;
>>      mem_event_request_t req;
>> @@ -882,10 +882,12 @@
>>      p2m_access_t a;
>>      mfn_t mfn;
>>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +    int ret;
>>
>>      /* Check that there's space on the ring for this request */
>> +    ret = -ENOSPC;
>>      if ( mem_event_check_ring(d, &d->mem_paging) )
>> -        return;
>> +        goto out;
>>
>>      memset(&req, 0, sizeof(req));
>>      req.type = MEM_EVENT_TYPE_PAGING;
>> @@ -905,19 +907,27 @@
>>      }
>>      p2m_unlock(p2m);
>>
>> +    ret = -EINVAL;
>>      /* Pause domain if request came from guest and gfn has paging type
>> */
>> -    if (  p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
>> +    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
>>      {
>>          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 )
>> +    else if ( p2mt == p2m_ram_paging_in_start || p2mt ==
>> p2m_ram_paging_in )
>>      {
>>          /* gfn is already on its way back and vcpu is not paused */
>>          mem_event_put_req_producers(&d->mem_paging);
>> -        return;
>> +        return 0;
>>      }
>> +    else if ( !p2m_is_paging(p2mt) )
>> +    {
>> +        /* please clear the bit in paging->bitmap; */
>> +        mem_event_put_req_producers(&d->mem_paging);
>> +        goto out;
>> +    }
>> +
>>
>>      /* Send request to pager */
>>      req.gfn = gfn;
>> @@ -925,8 +935,13 @@
>>      req.vcpu_id = v->vcpu_id;
>>
>>      mem_event_put_request(d, &d->mem_paging, &req);
>> +
>> +    ret = 0;
>> + out:
>> +    return ret;
>>  }
>>
>> +
>>  /**
>>   * p2m_mem_paging_prep - Allocate a new page for the guest
>>   * @d: guest domain
>> diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
>> --- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
>> @@ -485,7 +485,7 @@
>>  /* Tell xenpaging to drop a paged out frame */
>>  void 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);
>> +int 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);
>>  /* Resume normal operation (in case a domain was paused) */
>> diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
>> @@ -721,6 +721,7 @@
>>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
>>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
>>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
>> +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
>>
>>  /*
>>   * Access permissions.
>>
>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 39
> *****************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 03:52:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 03:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjNJn-0002Qz-6h; Sat, 07 Jan 2012 03:51:43 +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 1RjNJk-0002Qu-Jo
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 03:51:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1325908293!9931860!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNDY2Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18818 invoked from network); 7 Jan 2012 03:51:33 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-182.messagelabs.com with SMTP;
	7 Jan 2012 03:51:33 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 8E95476C06E;
	Fri,  6 Jan 2012 19:51:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=t10NGzLCMHv2SWsiwJ5caixtS+oad1G0KkbDmApGnsr0
	x2NtX8reAN8hIWcw/pmLE8tWB73sELhzIvfkak4qkuMqlTopRBfatGOO2342lIeU
	VDXZBb5sJNT5fZY07LDoYS74WvkwDsBg2f+uot/QhZ0lbf0Tj7exCBrbSBp0xwU=
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=nJHYA5q1NAhOtJT9TbIxE5RY2gg=; b=lL+Kx8PS
	9E5UJ9FWWVLguMu7j3WuLkh5xrvEMWzCCJVyxvhrcmS/CF27fKWac4h6Nt1lT6TR
	OMm3MQi1r7Kou6gDhnoStEqIo0xzRCmWOrWjNRGit2Os6I1oM6b71ybFwcLJgucw
	YfeaS7gnNZ8gV9eBxhg/9qKstUGFzrxVeuI=
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 4E1F976C069; 
	Fri,  6 Jan 2012 19:51:32 -0800 (PST)
Received: from 64.20.10.210 (proxying for 10.1.201.136, 64.20.10.210)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Fri, 6 Jan 2012 19:51:32 -0800
Message-ID: <a344dc410cb70b471e31c922ce80d94a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.5929.1325754331.12970.xen-devel@lists.xensource.com>
References: <mailman.5929.1325754331.12970.xen-devel@lists.xensource.com>
Date: Fri, 6 Jan 2012 19:51:32 -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, hongkaixing@huawei.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in process
 to	speed up page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Thu, 5 Jan 2012 09:05:16 +0000
> From: Tim Deegan <tim@xen.org>
> To: hongkaixing@huawei.com
> Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in
> 	process to	speed up page-in in	xenpaging
> Message-ID: <20120105090516.GE15595@ocelot.phlegethon.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hello,
>
> At 03:50 +0000 on 05 Jan (1325735430), hongkaixing@huawei.com wrote:
>> xenpaging:change page-in process to speed up page-in in xenpaging
>> In this patch,we change the page-in process.Firstly,we add a new
>> function paging_in_trigger_sync
>> to handle page-in requests directly.and when the requests' count is up
>> to 32,then handle them
>> batchly;Most importantly,we use an increasing gfn to test_bit,which
>> saves much time.
>> In p2m.c,we changes p2m_mem_paging_populate() to return a value;
>> The following is a xenpaging test on suse11-64 with 4G memory.
>>
>> Nums of page_out pages	Page out time	Page in time(in unstable code) Page
>> in time(apply this patch)
>> 512M(131072)		    2.6s		        540s		              4.7s
>> 2G(524288)		    15.5s		        2088s		      	      17.7s
>>
>
> Thanks for the patch!  That's an impressive difference.  You're changing
> quite a few things in this patch, though.  Can you send them as separate
> patches so they can be reviewed one at a time?  Is one of them in
> particular making the difference?  I suspect it's mostly the change to
> test_bit(), and the rest is not necessary.

Second that, on all counts. Impressive numbers, and, a bit puzzled as to
what actually made the difference.

I would also like to see changes to xenpaging teased out from changes to
the hypervisor.

I've been sitting on a patch to page-in synchronously, which shortcuts
even more aggressively the page-in path: instead of calling populate, we
go straight into paging_load. This does not necessitate an additional
domctl, and would save even more hypervisor<->pager control round-trips.
Do you foresee any conflicts with your current approach?

Thanks!
Andres

>
> Cheers,
>
> Tim.
>
>> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
>>
>> diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
>> --- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
>> @@ -73,6 +73,13 @@
>>                                  NULL, NULL, gfn);
>>  }
>>
>> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned
>> long gfn)
>> +{
>> +    return xc_mem_event_control(xch, domain_id,
>> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
>> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>> +                                NULL, NULL, gfn);
>> +}
>>
>>  /*
>>   * Local variables:
>> diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
>> --- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
>> @@ -1841,6 +1841,7 @@
>>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned
>> long gfn);
>>  int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
>>                           unsigned long gfn);
>> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned long
>> gfn);
>>
>>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>>                          void *shared_page, void *ring_page);
>> diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
>> --- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
>> @@ -594,6 +594,13 @@
>>      return ret;
>>  }
>>
>> +static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long
>> gfn)
>> +{
>> +    int rc = 0;
>> +    rc = xc_mem_paging_in(paging->xc_handle,
>> paging->mem_event.domain_id,gfn);
>> +    return rc;
>> +}
>
> This function is
>
>> +
>>  int main(int argc, char *argv[])
>>  {
>>      struct sigaction act;
>> @@ -605,6 +612,9 @@
>>      int i;
>>      int rc = -1;
>>      int rc1;
>> +    int request_count = 0;
>> +    unsigned long page_in_start_gfn = 0;
>> +    unsigned long real_page = 0;
>>      xc_interface *xch;
>>
>>      int open_flags = O_CREAT | O_TRUNC | O_RDWR;
>> @@ -773,24 +783,51 @@
>>          /* Write all pages back into the guest */
>>          if ( interrupted == SIGTERM || interrupted == SIGINT )
>>          {
>> -            int num = 0;
>> +            request_count = 0;
>>              for ( i = 0; i < paging->domain_info->max_pages; i++ )
>>              {
>> -                if ( test_bit(i, paging->bitmap) )
>> +                real_page = i + page_in_start_gfn;
>> +                real_page %= paging->domain_info->max_pages;
>> +                if ( test_bit(real_page, paging->bitmap) )
>>                  {
>> -                    paging->pagein_queue[num] = i;
>> -                    num++;
>> -                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
>> -                        break;
>> +                    rc = paging_in_trigger_sync(paging,real_page);
>> +                    if ( 0 == rc )
>> +                    {
>> +                        request_count++;
>> +                        /* If page_in requests up to 32 then handle
>> them */
>> +                        if( request_count >= 32 )
>> +                        {
>> +                            page_in_start_gfn=real_page + 1;
>> +                            break;
>> +                        }
>> +                    }
>> +                    else
>> +                    {
>> +                        /* If IO ring is full then handle requests to
>> free space */
>> +                        if( ENOSPC == errno )
>> +                        {
>> +                            page_in_start_gfn = real_page;
>> +                            break;
>> +                        }
>> +                        /* If p2mt is not p2m_is_paging,then clear
>> bitmap;
>> +                        * e.g. a page is paged then it is dropped by
>> balloon.
>> +                        */
>> +                        else if ( EINVAL == errno )
>> +                        {
>> +                            clear_bit(i,paging->bitmap);
>> +                            policy_notify_paged_in(i);
>> +                        }
>> +                        /* If hypercall fails then go to teardown
>> xenpaging */
>> +                        else
>> +                        {
>> +                            ERROR("Error paging in page");
>> +                            goto out;
>> +                        }
>> +                    }
>>                  }
>>              }
>> -            /*
>> -             * One more round if there are still pages to process.
>> -             * If no more pages to process, exit loop.
>> -             */
>> -            if ( num )
>> -                page_in_trigger();
>> -            else if ( i == paging->domain_info->max_pages )
>> +            if( (i==paging->domain_info->max_pages) &&
>> +
>> !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
>>                  break;
>>          }
>>          else
>> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
>> --- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
>> @@ -57,7 +57,14 @@
>>          return 0;
>>      }
>>      break;
>> -
>> +
>> +    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
>> +    {
>> +        unsigned long gfn = mec->gfn;
>> +        return p2m_mem_paging_populate(d, gfn);
>> +    }
>> +    break;
>> +
>>      default:
>>          return -ENOSYS;
>>          break;
>> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
>> @@ -874,7 +874,7 @@
>>   * already sent to the pager. In this case the caller has to try again
>> until the
>>   * gfn is fully paged in again.
>>   */
>> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>>  {
>>      struct vcpu *v = current;
>>      mem_event_request_t req;
>> @@ -882,10 +882,12 @@
>>      p2m_access_t a;
>>      mfn_t mfn;
>>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +    int ret;
>>
>>      /* Check that there's space on the ring for this request */
>> +    ret = -ENOSPC;
>>      if ( mem_event_check_ring(d, &d->mem_paging) )
>> -        return;
>> +        goto out;
>>
>>      memset(&req, 0, sizeof(req));
>>      req.type = MEM_EVENT_TYPE_PAGING;
>> @@ -905,19 +907,27 @@
>>      }
>>      p2m_unlock(p2m);
>>
>> +    ret = -EINVAL;
>>      /* Pause domain if request came from guest and gfn has paging type
>> */
>> -    if (  p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
>> +    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
>>      {
>>          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 )
>> +    else if ( p2mt == p2m_ram_paging_in_start || p2mt ==
>> p2m_ram_paging_in )
>>      {
>>          /* gfn is already on its way back and vcpu is not paused */
>>          mem_event_put_req_producers(&d->mem_paging);
>> -        return;
>> +        return 0;
>>      }
>> +    else if ( !p2m_is_paging(p2mt) )
>> +    {
>> +        /* please clear the bit in paging->bitmap; */
>> +        mem_event_put_req_producers(&d->mem_paging);
>> +        goto out;
>> +    }
>> +
>>
>>      /* Send request to pager */
>>      req.gfn = gfn;
>> @@ -925,8 +935,13 @@
>>      req.vcpu_id = v->vcpu_id;
>>
>>      mem_event_put_request(d, &d->mem_paging, &req);
>> +
>> +    ret = 0;
>> + out:
>> +    return ret;
>>  }
>>
>> +
>>  /**
>>   * p2m_mem_paging_prep - Allocate a new page for the guest
>>   * @d: guest domain
>> diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
>> --- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
>> @@ -485,7 +485,7 @@
>>  /* Tell xenpaging to drop a paged out frame */
>>  void 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);
>> +int 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);
>>  /* Resume normal operation (in case a domain was paused) */
>> diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
>> --- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
>> +++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
>> @@ -721,6 +721,7 @@
>>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
>>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
>>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
>> +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
>>
>>  /*
>>   * Access permissions.
>>
>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 39
> *****************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 04:18:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 04:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjNim-0002hf-Fl; Sat, 07 Jan 2012 04:17:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tinnycloud@hotmail.com>) id 1RjNil-0002ha-Ne
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 04:17:31 +0000
X-Env-Sender: tinnycloud@hotmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325909844!10696887!1
X-Originating-IP: [65.55.111.100]
X-SpamReason: No, hits=0.7 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9360 invoked from network); 7 Jan 2012 04:17:25 -0000
Received: from blu0-omc2-s25.blu0.hotmail.com (HELO
	blu0-omc2-s25.blu0.hotmail.com) (65.55.111.100)
	by server-6.tower-21.messagelabs.com with SMTP;
	7 Jan 2012 04:17:25 -0000
Received: from BLU157-W65 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 6 Jan 2012 20:17:24 -0800
Message-ID: <BLU157-W65C4641D5245A308C327C2DA9A0@phx.gbl>
X-Originating-IP: [125.118.65.42]
From: MaoXiaoyun <tinnycloud@hotmail.com>
To: xen devel <xen-devel@lists.xensource.com>
Date: Sat, 7 Jan 2012 12:17:23 +0800
Importance: Normal
In-Reply-To: <mailman.6093.1325902643.12970.xen-devel@lists.xensource.com>
References: <mailman.6093.1325902643.12970.xen-devel@lists.xensource.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Jan 2012 04:17:24.0100 (UTC)
	FILETIME=[41DCA440:01CCCCF3]
Subject: [Xen-devel] Linux Container and Tapdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6119489830975497569=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6119489830975497569==
Content-Type: multipart/alternative;
	boundary="_03bf71ed-babc-49bf-a771-6d6657d47ac6_"

--_03bf71ed-babc-49bf-a771-6d6657d47ac6_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit


Hi:
 
      Recently I have some study on linux container(lxc), which is a light weight OS level
virtualization.
 
     With the previous knowledge of tapdisk, I have an assumption that, I may could
use the vhd for each container to seperate the storage of all containers, or even in 
later days, vhd is stored in distributed storage, container could be migrated.
 
      Build filesystem on tapdev and mount it under some directory, put the rootfs of 
container into that dir, and start the lxc, I haven't try this, will try later.
      
     I post my idea here, hope someone has one forsee comments.
 
     Thanks.
       		 	   		  
--_03bf71ed-babc-49bf-a771-6d6657d47ac6_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Hi:<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Recently I have some study on linux container(lxc), which is a light weight OS level<BR>
virtualization.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp; With the previous knowledge of tapdisk, I have an assumption that, I&nbsp;may could<BR>
use the vhd for each container to seperate the storage of all containers, or even in <BR>
later days, vhd is stored in distributed storage, container could be migrated.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Build filesystem on tapdev and mount it under some directory, put the rootfs of <BR>
container into that dir, and start the lxc, I haven't try this, will try later.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp; I post my idea here, hope someone has one forsee comments.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Thanks.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR> 		 	   		  </div></body>
</html>
--_03bf71ed-babc-49bf-a771-6d6657d47ac6_--


--===============6119489830975497569==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6119489830975497569==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 04:18:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 04:18:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjNim-0002hf-Fl; Sat, 07 Jan 2012 04:17:32 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tinnycloud@hotmail.com>) id 1RjNil-0002ha-Ne
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 04:17:31 +0000
X-Env-Sender: tinnycloud@hotmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325909844!10696887!1
X-Originating-IP: [65.55.111.100]
X-SpamReason: No, hits=0.7 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	HTML_40_50, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9360 invoked from network); 7 Jan 2012 04:17:25 -0000
Received: from blu0-omc2-s25.blu0.hotmail.com (HELO
	blu0-omc2-s25.blu0.hotmail.com) (65.55.111.100)
	by server-6.tower-21.messagelabs.com with SMTP;
	7 Jan 2012 04:17:25 -0000
Received: from BLU157-W65 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 6 Jan 2012 20:17:24 -0800
Message-ID: <BLU157-W65C4641D5245A308C327C2DA9A0@phx.gbl>
X-Originating-IP: [125.118.65.42]
From: MaoXiaoyun <tinnycloud@hotmail.com>
To: xen devel <xen-devel@lists.xensource.com>
Date: Sat, 7 Jan 2012 12:17:23 +0800
Importance: Normal
In-Reply-To: <mailman.6093.1325902643.12970.xen-devel@lists.xensource.com>
References: <mailman.6093.1325902643.12970.xen-devel@lists.xensource.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Jan 2012 04:17:24.0100 (UTC)
	FILETIME=[41DCA440:01CCCCF3]
Subject: [Xen-devel] Linux Container and Tapdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6119489830975497569=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6119489830975497569==
Content-Type: multipart/alternative;
	boundary="_03bf71ed-babc-49bf-a771-6d6657d47ac6_"

--_03bf71ed-babc-49bf-a771-6d6657d47ac6_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit


Hi:
 
      Recently I have some study on linux container(lxc), which is a light weight OS level
virtualization.
 
     With the previous knowledge of tapdisk, I have an assumption that, I may could
use the vhd for each container to seperate the storage of all containers, or even in 
later days, vhd is stored in distributed storage, container could be migrated.
 
      Build filesystem on tapdev and mount it under some directory, put the rootfs of 
container into that dir, and start the lxc, I haven't try this, will try later.
      
     I post my idea here, hope someone has one forsee comments.
 
     Thanks.
       		 	   		  
--_03bf71ed-babc-49bf-a771-6d6657d47ac6_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Hi:<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Recently I have some study on linux container(lxc), which is a light weight OS level<BR>
virtualization.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp; With the previous knowledge of tapdisk, I have an assumption that, I&nbsp;may could<BR>
use the vhd for each container to seperate the storage of all containers, or even in <BR>
later days, vhd is stored in distributed storage, container could be migrated.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Build filesystem on tapdev and mount it under some directory, put the rootfs of <BR>
container into that dir, and start the lxc, I haven't try this, will try later.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp; I post my idea here, hope someone has one forsee comments.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Thanks.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR> 		 	   		  </div></body>
</html>
--_03bf71ed-babc-49bf-a771-6d6657d47ac6_--


--===============6119489830975497569==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6119489830975497569==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 05:24:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 05:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjOlR-0003CU-QD; Sat, 07 Jan 2012 05:24: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 1RjOlQ-0003CP-OE
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 05:24:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1325913853!10040706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk0Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4773 invoked from network); 7 Jan 2012 05:24:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jan 2012 05:24:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,472,1320624000"; 
   d="scan'208";a="9873444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jan 2012 05:24:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Jan 2012 05:24: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 1RjOlI-0006VV-3s;
	Sat, 07 Jan 2012 05:24:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RjOlH-0004mH-PD;
	Sat, 07 Jan 2012 05:24:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10642-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Jan 2012 05:24:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10642: 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 10642 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10642/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10641
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10641

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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   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-win-vcpus1   16 leak-check/check             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-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-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10641 never pass

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  4086e4811547

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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


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 Jan 07 05:24:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 05:24:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjOlR-0003CU-QD; Sat, 07 Jan 2012 05:24: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 1RjOlQ-0003CP-OE
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 05:24:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1325913853!10040706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk0Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4773 invoked from network); 7 Jan 2012 05:24:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jan 2012 05:24:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,472,1320624000"; 
   d="scan'208";a="9873444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	07 Jan 2012 05:24:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 7 Jan 2012 05:24: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 1RjOlI-0006VV-3s;
	Sat, 07 Jan 2012 05:24:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RjOlH-0004mH-PD;
	Sat, 07 Jan 2012 05:24:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10642-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 7 Jan 2012 05:24:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10642: 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 10642 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10642/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10641
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10641

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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   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-win-vcpus1   16 leak-check/check             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-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-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10641 never pass

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  4086e4811547

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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


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 Jan 07 08:40:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 08: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 1RjRoI-0004SV-WA; Sat, 07 Jan 2012 08:39:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RjRoG-0004SQ-Na
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 08:39:29 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325925560!8705611!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNjA3Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19915 invoked from network); 7 Jan 2012 08:39:21 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-12.tower-21.messagelabs.com with SMTP;
	7 Jan 2012 08:39:21 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF004T76PIPS@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:39:18 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF00MDX6PIW4@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:39:18 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG91919; Sat,
	07 Jan 2012 16:39:16 +0800
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Sat, 07 Jan 2012 16:39:11 +0800
Received: from h00166998 (10.166.80.196) by szxeml408-hub.china.huawei.com
	(10.82.67.95) with Microsoft SMTP Server id 14.1.323.3; Sat,
	07 Jan 2012 16:38:55 +0800
Date: Sat, 07 Jan 2012 16:38:54 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <a344dc410cb70b471e31c922ce80d94a.squirrel@webmail.lagarcavilla.org>
X-Originating-IP: [10.166.80.196]
To: andres@lagarcavilla.org, xen-devel@lists.xensource.com
Message-id: <002b01cccd17$ca4652d0$5ed2f870$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczM76cfbVfMSKB/SBiYQ2CfX9cOOAAJe+OA
x-cr-hashedpuzzle: CBi8 FhBk LLEM Q/KW VL+p jeHm oYUa qB4p qoJH 0jON 36mr
	AAeG2Q== AA7zjw== AC/k8Q== ADQxjg== AD3bJQ==; 8;
	YQBuAGQAcgBlAHMAQABsAGEAZwBhAHIAYwBhAHYAaQBsAGwAYQAuAG8AcgBnADsAYgBpAGMAawB5AC4AcwBoAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAaABhAG4AdwBlAGkAZABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwBvAGwAYQBmAEAAYQBlAHAAZgBsAGUALgBkAGUAOwB0AGkAbQBAAHgAZQBuAC4AbwByAGcAOwB4AGUAbgAtAGQAZQB2AGUAbABAAGwAaQBzAHQAcwAuAHgAZQBuAHMAbwB1AHIAYwBlAC4AYwBvAG0AOwB4AGkAYQBvAHcAZQBpAC4AeQBhAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwB5AGEAbgBxAGkAYQBuAGcAagB1AG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {D6ECF3DE-BB1A-4C77-9CBA-D5784740C487};
	aABvAG4AZwBrAGEAaQB4AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=;
	Sat, 07 Jan 2012 08:38:40 GMT;
	UgBFADoAIABbAFAAQQBUAEMASAAgADIAIABvAGYAIAAyAF0AIAB4AGUAbgBwAGEAZwBpAG4AZwA6AGMAaABhAG4AZwBlACAAcABhAGcAZQAtAGkAbgAgAHAAcgBvAGMAZQBzAHMAIAB0AG8ACQBzAHAAZQBlAGQAIAB1AHAAIABwAGEAZwBlAC0AaQBuACAAaQBuACAAeABlAG4AcABhAGcAaQBuAGcA
x-cr-puzzleid: {D6ECF3DE-BB1A-4C77-9CBA-D5784740C487}
X-CFilter-Loop: Reflected
References: <mailman.5929.1325754331.12970.xen-devel@lists.xensource.com>
	<a344dc410cb70b471e31c922ce80d94a.squirrel@webmail.lagarcavilla.org>
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, hanweidong@huawei.com,
	yanqiangjun@huawei.com, tim@xen.org, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in process
 to	speed up page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Saturday, January 07, 2012 11:52 AM
> To: xen-devel@lists.xensource.com
> Cc: tim@xen.org; olaf@aepfle.de; hongkaixing@huawei.com
> Subject: Re: [PATCH 2 of 2] xenpaging:change page-in process to speed up page-in in xenpaging
> 
> > Date: Thu, 5 Jan 2012 09:05:16 +0000
> > From: Tim Deegan <tim@xen.org>
> > To: hongkaixing@huawei.com
> > Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in
> > 	process to	speed up page-in in	xenpaging
> > Message-ID: <20120105090516.GE15595@ocelot.phlegethon.org>
> > Content-Type: text/plain; charset=iso-8859-1
> >
> > Hello,
> >
> > At 03:50 +0000 on 05 Jan (1325735430), hongkaixing@huawei.com wrote:
> >> xenpaging:change page-in process to speed up page-in in xenpaging
> >> In this patch,we change the page-in process.Firstly,we add a new
> >> function paging_in_trigger_sync
> >> to handle page-in requests directly.and when the requests' count is up
> >> to 32,then handle them
> >> batchly;Most importantly,we use an increasing gfn to test_bit,which
> >> saves much time.
> >> In p2m.c,we changes p2m_mem_paging_populate() to return a value;
> >> The following is a xenpaging test on suse11-64 with 4G memory.
> >>
> >> Nums of page_out pages	Page out time	Page in time(in unstable code) Page
> >> in time(apply this patch)
> >> 512M(131072)		    2.6s		        540s		              4.7s
> >> 2G(524288)		    15.5s		        2088s		      	      17.7s
> >>
> >
> > Thanks for the patch!  That's an impressive difference.  You're changing
> > quite a few things in this patch, though.  Can you send them as separate
> > patches so they can be reviewed one at a time?  Is one of them in
> > particular making the difference?  I suspect it's mostly the change to
> > test_bit(), and the rest is not necessary.
> 
> Second that, on all counts. Impressive numbers, and, a bit puzzled as to
> what actually made the difference.

Take paging 512M as a example, before using this patch, it spends 540s in page-in process, after using this patch, only 4.7 s

> 
> I would also like to see changes to xenpaging teased out from changes to
> the hypervisor.
> 
> I've been sitting on a patch to page-in synchronously, which shortcuts
> even more aggressively the page-in path: instead of calling populate, we
> go straight into paging_load. This does not necessitate an additional
> domctl, and would save even more hypervisor<->pager control round-trips.

Would you mind showing your details?
I see, I have try this so. My method is :
When test the page is paged out, then populate directly without using event ring.
Problem is : There may be some concurrency problems, and some strange blue screens.


> Do you foresee any conflicts with your current approach?

Our approach is stable till now.
> 
> Thanks!
> Andres
> 
> >
> > Cheers,
> >
> > Tim.
> >
> >> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
> >>
> >> diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
> >> --- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -73,6 +73,13 @@
> >>                                  NULL, NULL, gfn);
> >>  }
> >>
> >> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned
> >> long gfn)
> >> +{
> >> +    return xc_mem_event_control(xch, domain_id,
> >> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
> >> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
> >> +                                NULL, NULL, gfn);
> >> +}
> >>
> >>  /*
> >>   * Local variables:
> >> diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
> >> --- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -1841,6 +1841,7 @@
> >>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned
> >> long gfn);
> >>  int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
> >>                           unsigned long gfn);
> >> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned long
> >> gfn);
> >>
> >>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
> >>                          void *shared_page, void *ring_page);
> >> diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
> >> --- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -594,6 +594,13 @@
> >>      return ret;
> >>  }
> >>
> >> +static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long
> >> gfn)
> >> +{
> >> +    int rc = 0;
> >> +    rc = xc_mem_paging_in(paging->xc_handle,
> >> paging->mem_event.domain_id,gfn);
> >> +    return rc;
> >> +}
> >
> > This function is
> >
> >> +
> >>  int main(int argc, char *argv[])
> >>  {
> >>      struct sigaction act;
> >> @@ -605,6 +612,9 @@
> >>      int i;
> >>      int rc = -1;
> >>      int rc1;
> >> +    int request_count = 0;
> >> +    unsigned long page_in_start_gfn = 0;
> >> +    unsigned long real_page = 0;
> >>      xc_interface *xch;
> >>
> >>      int open_flags = O_CREAT | O_TRUNC | O_RDWR;
> >> @@ -773,24 +783,51 @@
> >>          /* Write all pages back into the guest */
> >>          if ( interrupted == SIGTERM || interrupted == SIGINT )
> >>          {
> >> -            int num = 0;
> >> +            request_count = 0;
> >>              for ( i = 0; i < paging->domain_info->max_pages; i++ )
> >>              {
> >> -                if ( test_bit(i, paging->bitmap) )
> >> +                real_page = i + page_in_start_gfn;
> >> +                real_page %= paging->domain_info->max_pages;
> >> +                if ( test_bit(real_page, paging->bitmap) )
> >>                  {
> >> -                    paging->pagein_queue[num] = i;
> >> -                    num++;
> >> -                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
> >> -                        break;
> >> +                    rc = paging_in_trigger_sync(paging,real_page);
> >> +                    if ( 0 == rc )
> >> +                    {
> >> +                        request_count++;
> >> +                        /* If page_in requests up to 32 then handle
> >> them */
> >> +                        if( request_count >= 32 )
> >> +                        {
> >> +                            page_in_start_gfn=real_page + 1;
> >> +                            break;
> >> +                        }
> >> +                    }
> >> +                    else
> >> +                    {
> >> +                        /* If IO ring is full then handle requests to
> >> free space */
> >> +                        if( ENOSPC == errno )
> >> +                        {
> >> +                            page_in_start_gfn = real_page;
> >> +                            break;
> >> +                        }
> >> +                        /* If p2mt is not p2m_is_paging,then clear
> >> bitmap;
> >> +                        * e.g. a page is paged then it is dropped by
> >> balloon.
> >> +                        */
> >> +                        else if ( EINVAL == errno )
> >> +                        {
> >> +                            clear_bit(i,paging->bitmap);
> >> +                            policy_notify_paged_in(i);
> >> +                        }
> >> +                        /* If hypercall fails then go to teardown
> >> xenpaging */
> >> +                        else
> >> +                        {
> >> +                            ERROR("Error paging in page");
> >> +                            goto out;
> >> +                        }
> >> +                    }
> >>                  }
> >>              }
> >> -            /*
> >> -             * One more round if there are still pages to process.
> >> -             * If no more pages to process, exit loop.
> >> -             */
> >> -            if ( num )
> >> -                page_in_trigger();
> >> -            else if ( i == paging->domain_info->max_pages )
> >> +            if( (i==paging->domain_info->max_pages) &&
> >> +
> >> !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
> >>                  break;
> >>          }
> >>          else
> >> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
> >> --- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -57,7 +57,14 @@
> >>          return 0;
> >>      }
> >>      break;
> >> -
> >> +
> >> +    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
> >> +    {
> >> +        unsigned long gfn = mec->gfn;
> >> +        return p2m_mem_paging_populate(d, gfn);
> >> +    }
> >> +    break;
> >> +
> >>      default:
> >>          return -ENOSYS;
> >>          break;
> >> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
> >> --- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -874,7 +874,7 @@
> >>   * already sent to the pager. In this case the caller has to try again
> >> until the
> >>   * gfn is fully paged in again.
> >>   */
> >> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >>  {
> >>      struct vcpu *v = current;
> >>      mem_event_request_t req;
> >> @@ -882,10 +882,12 @@
> >>      p2m_access_t a;
> >>      mfn_t mfn;
> >>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> +    int ret;
> >>
> >>      /* Check that there's space on the ring for this request */
> >> +    ret = -ENOSPC;
> >>      if ( mem_event_check_ring(d, &d->mem_paging) )
> >> -        return;
> >> +        goto out;
> >>
> >>      memset(&req, 0, sizeof(req));
> >>      req.type = MEM_EVENT_TYPE_PAGING;
> >> @@ -905,19 +907,27 @@
> >>      }
> >>      p2m_unlock(p2m);
> >>
> >> +    ret = -EINVAL;
> >>      /* Pause domain if request came from guest and gfn has paging type
> >> */
> >> -    if (  p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
> >> +    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
> >>      {
> >>          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 )
> >> +    else if ( p2mt == p2m_ram_paging_in_start || p2mt ==
> >> p2m_ram_paging_in )
> >>      {
> >>          /* gfn is already on its way back and vcpu is not paused */
> >>          mem_event_put_req_producers(&d->mem_paging);
> >> -        return;
> >> +        return 0;
> >>      }
> >> +    else if ( !p2m_is_paging(p2mt) )
> >> +    {
> >> +        /* please clear the bit in paging->bitmap; */
> >> +        mem_event_put_req_producers(&d->mem_paging);
> >> +        goto out;
> >> +    }
> >> +
> >>
> >>      /* Send request to pager */
> >>      req.gfn = gfn;
> >> @@ -925,8 +935,13 @@
> >>      req.vcpu_id = v->vcpu_id;
> >>
> >>      mem_event_put_request(d, &d->mem_paging, &req);
> >> +
> >> +    ret = 0;
> >> + out:
> >> +    return ret;
> >>  }
> >>
> >> +
> >>  /**
> >>   * p2m_mem_paging_prep - Allocate a new page for the guest
> >>   * @d: guest domain
> >> diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
> >> --- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -485,7 +485,7 @@
> >>  /* Tell xenpaging to drop a paged out frame */
> >>  void 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);
> >> +int 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);
> >>  /* Resume normal operation (in case a domain was paused) */
> >> diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
> >> --- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -721,6 +721,7 @@
> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
> >> +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
> >>
> >>  /*
> >>   * Access permissions.
> >>
> >
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> >
> > End of Xen-devel Digest, Vol 83, Issue 39
> > *****************************************
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 08:40:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 08: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 1RjRoI-0004SV-WA; Sat, 07 Jan 2012 08:39:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RjRoG-0004SQ-Na
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 08:39:29 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1325925560!8705611!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNjA3Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19915 invoked from network); 7 Jan 2012 08:39:21 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-12.tower-21.messagelabs.com with SMTP;
	7 Jan 2012 08:39:21 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF004T76PIPS@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:39:18 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF00MDX6PIW4@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:39:18 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG91919; Sat,
	07 Jan 2012 16:39:16 +0800
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Sat, 07 Jan 2012 16:39:11 +0800
Received: from h00166998 (10.166.80.196) by szxeml408-hub.china.huawei.com
	(10.82.67.95) with Microsoft SMTP Server id 14.1.323.3; Sat,
	07 Jan 2012 16:38:55 +0800
Date: Sat, 07 Jan 2012 16:38:54 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <a344dc410cb70b471e31c922ce80d94a.squirrel@webmail.lagarcavilla.org>
X-Originating-IP: [10.166.80.196]
To: andres@lagarcavilla.org, xen-devel@lists.xensource.com
Message-id: <002b01cccd17$ca4652d0$5ed2f870$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczM76cfbVfMSKB/SBiYQ2CfX9cOOAAJe+OA
x-cr-hashedpuzzle: CBi8 FhBk LLEM Q/KW VL+p jeHm oYUa qB4p qoJH 0jON 36mr
	AAeG2Q== AA7zjw== AC/k8Q== ADQxjg== AD3bJQ==; 8;
	YQBuAGQAcgBlAHMAQABsAGEAZwBhAHIAYwBhAHYAaQBsAGwAYQAuAG8AcgBnADsAYgBpAGMAawB5AC4AcwBoAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAaABhAG4AdwBlAGkAZABvAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwBvAGwAYQBmAEAAYQBlAHAAZgBsAGUALgBkAGUAOwB0AGkAbQBAAHgAZQBuAC4AbwByAGcAOwB4AGUAbgAtAGQAZQB2AGUAbABAAGwAaQBzAHQAcwAuAHgAZQBuAHMAbwB1AHIAYwBlAC4AYwBvAG0AOwB4AGkAYQBvAHcAZQBpAC4AeQBhAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0AOwB5AGEAbgBxAGkAYQBuAGcAagB1AG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {D6ECF3DE-BB1A-4C77-9CBA-D5784740C487};
	aABvAG4AZwBrAGEAaQB4AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=;
	Sat, 07 Jan 2012 08:38:40 GMT;
	UgBFADoAIABbAFAAQQBUAEMASAAgADIAIABvAGYAIAAyAF0AIAB4AGUAbgBwAGEAZwBpAG4AZwA6AGMAaABhAG4AZwBlACAAcABhAGcAZQAtAGkAbgAgAHAAcgBvAGMAZQBzAHMAIAB0AG8ACQBzAHAAZQBlAGQAIAB1AHAAIABwAGEAZwBlAC0AaQBuACAAaQBuACAAeABlAG4AcABhAGcAaQBuAGcA
x-cr-puzzleid: {D6ECF3DE-BB1A-4C77-9CBA-D5784740C487}
X-CFilter-Loop: Reflected
References: <mailman.5929.1325754331.12970.xen-devel@lists.xensource.com>
	<a344dc410cb70b471e31c922ce80d94a.squirrel@webmail.lagarcavilla.org>
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, hanweidong@huawei.com,
	yanqiangjun@huawei.com, tim@xen.org, bicky.shi@huawei.com
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in process
 to	speed up page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> -----Original Message-----
> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Saturday, January 07, 2012 11:52 AM
> To: xen-devel@lists.xensource.com
> Cc: tim@xen.org; olaf@aepfle.de; hongkaixing@huawei.com
> Subject: Re: [PATCH 2 of 2] xenpaging:change page-in process to speed up page-in in xenpaging
> 
> > Date: Thu, 5 Jan 2012 09:05:16 +0000
> > From: Tim Deegan <tim@xen.org>
> > To: hongkaixing@huawei.com
> > Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in
> > 	process to	speed up page-in in	xenpaging
> > Message-ID: <20120105090516.GE15595@ocelot.phlegethon.org>
> > Content-Type: text/plain; charset=iso-8859-1
> >
> > Hello,
> >
> > At 03:50 +0000 on 05 Jan (1325735430), hongkaixing@huawei.com wrote:
> >> xenpaging:change page-in process to speed up page-in in xenpaging
> >> In this patch,we change the page-in process.Firstly,we add a new
> >> function paging_in_trigger_sync
> >> to handle page-in requests directly.and when the requests' count is up
> >> to 32,then handle them
> >> batchly;Most importantly,we use an increasing gfn to test_bit,which
> >> saves much time.
> >> In p2m.c,we changes p2m_mem_paging_populate() to return a value;
> >> The following is a xenpaging test on suse11-64 with 4G memory.
> >>
> >> Nums of page_out pages	Page out time	Page in time(in unstable code) Page
> >> in time(apply this patch)
> >> 512M(131072)		    2.6s		        540s		              4.7s
> >> 2G(524288)		    15.5s		        2088s		      	      17.7s
> >>
> >
> > Thanks for the patch!  That's an impressive difference.  You're changing
> > quite a few things in this patch, though.  Can you send them as separate
> > patches so they can be reviewed one at a time?  Is one of them in
> > particular making the difference?  I suspect it's mostly the change to
> > test_bit(), and the rest is not necessary.
> 
> Second that, on all counts. Impressive numbers, and, a bit puzzled as to
> what actually made the difference.

Take paging 512M as a example, before using this patch, it spends 540s in page-in process, after using this patch, only 4.7 s

> 
> I would also like to see changes to xenpaging teased out from changes to
> the hypervisor.
> 
> I've been sitting on a patch to page-in synchronously, which shortcuts
> even more aggressively the page-in path: instead of calling populate, we
> go straight into paging_load. This does not necessitate an additional
> domctl, and would save even more hypervisor<->pager control round-trips.

Would you mind showing your details?
I see, I have try this so. My method is :
When test the page is paged out, then populate directly without using event ring.
Problem is : There may be some concurrency problems, and some strange blue screens.


> Do you foresee any conflicts with your current approach?

Our approach is stable till now.
> 
> Thanks!
> Andres
> 
> >
> > Cheers,
> >
> > Tim.
> >
> >> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
> >>
> >> diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
> >> --- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -73,6 +73,13 @@
> >>                                  NULL, NULL, gfn);
> >>  }
> >>
> >> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned
> >> long gfn)
> >> +{
> >> +    return xc_mem_event_control(xch, domain_id,
> >> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
> >> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
> >> +                                NULL, NULL, gfn);
> >> +}
> >>
> >>  /*
> >>   * Local variables:
> >> diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
> >> --- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -1841,6 +1841,7 @@
> >>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned
> >> long gfn);
> >>  int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
> >>                           unsigned long gfn);
> >> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned long
> >> gfn);
> >>
> >>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
> >>                          void *shared_page, void *ring_page);
> >> diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
> >> --- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -594,6 +594,13 @@
> >>      return ret;
> >>  }
> >>
> >> +static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long
> >> gfn)
> >> +{
> >> +    int rc = 0;
> >> +    rc = xc_mem_paging_in(paging->xc_handle,
> >> paging->mem_event.domain_id,gfn);
> >> +    return rc;
> >> +}
> >
> > This function is
> >
> >> +
> >>  int main(int argc, char *argv[])
> >>  {
> >>      struct sigaction act;
> >> @@ -605,6 +612,9 @@
> >>      int i;
> >>      int rc = -1;
> >>      int rc1;
> >> +    int request_count = 0;
> >> +    unsigned long page_in_start_gfn = 0;
> >> +    unsigned long real_page = 0;
> >>      xc_interface *xch;
> >>
> >>      int open_flags = O_CREAT | O_TRUNC | O_RDWR;
> >> @@ -773,24 +783,51 @@
> >>          /* Write all pages back into the guest */
> >>          if ( interrupted == SIGTERM || interrupted == SIGINT )
> >>          {
> >> -            int num = 0;
> >> +            request_count = 0;
> >>              for ( i = 0; i < paging->domain_info->max_pages; i++ )
> >>              {
> >> -                if ( test_bit(i, paging->bitmap) )
> >> +                real_page = i + page_in_start_gfn;
> >> +                real_page %= paging->domain_info->max_pages;
> >> +                if ( test_bit(real_page, paging->bitmap) )
> >>                  {
> >> -                    paging->pagein_queue[num] = i;
> >> -                    num++;
> >> -                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
> >> -                        break;
> >> +                    rc = paging_in_trigger_sync(paging,real_page);
> >> +                    if ( 0 == rc )
> >> +                    {
> >> +                        request_count++;
> >> +                        /* If page_in requests up to 32 then handle
> >> them */
> >> +                        if( request_count >= 32 )
> >> +                        {
> >> +                            page_in_start_gfn=real_page + 1;
> >> +                            break;
> >> +                        }
> >> +                    }
> >> +                    else
> >> +                    {
> >> +                        /* If IO ring is full then handle requests to
> >> free space */
> >> +                        if( ENOSPC == errno )
> >> +                        {
> >> +                            page_in_start_gfn = real_page;
> >> +                            break;
> >> +                        }
> >> +                        /* If p2mt is not p2m_is_paging,then clear
> >> bitmap;
> >> +                        * e.g. a page is paged then it is dropped by
> >> balloon.
> >> +                        */
> >> +                        else if ( EINVAL == errno )
> >> +                        {
> >> +                            clear_bit(i,paging->bitmap);
> >> +                            policy_notify_paged_in(i);
> >> +                        }
> >> +                        /* If hypercall fails then go to teardown
> >> xenpaging */
> >> +                        else
> >> +                        {
> >> +                            ERROR("Error paging in page");
> >> +                            goto out;
> >> +                        }
> >> +                    }
> >>                  }
> >>              }
> >> -            /*
> >> -             * One more round if there are still pages to process.
> >> -             * If no more pages to process, exit loop.
> >> -             */
> >> -            if ( num )
> >> -                page_in_trigger();
> >> -            else if ( i == paging->domain_info->max_pages )
> >> +            if( (i==paging->domain_info->max_pages) &&
> >> +
> >> !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
> >>                  break;
> >>          }
> >>          else
> >> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
> >> --- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -57,7 +57,14 @@
> >>          return 0;
> >>      }
> >>      break;
> >> -
> >> +
> >> +    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
> >> +    {
> >> +        unsigned long gfn = mec->gfn;
> >> +        return p2m_mem_paging_populate(d, gfn);
> >> +    }
> >> +    break;
> >> +
> >>      default:
> >>          return -ENOSYS;
> >>          break;
> >> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
> >> --- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -874,7 +874,7 @@
> >>   * already sent to the pager. In this case the caller has to try again
> >> until the
> >>   * gfn is fully paged in again.
> >>   */
> >> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> >>  {
> >>      struct vcpu *v = current;
> >>      mem_event_request_t req;
> >> @@ -882,10 +882,12 @@
> >>      p2m_access_t a;
> >>      mfn_t mfn;
> >>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> +    int ret;
> >>
> >>      /* Check that there's space on the ring for this request */
> >> +    ret = -ENOSPC;
> >>      if ( mem_event_check_ring(d, &d->mem_paging) )
> >> -        return;
> >> +        goto out;
> >>
> >>      memset(&req, 0, sizeof(req));
> >>      req.type = MEM_EVENT_TYPE_PAGING;
> >> @@ -905,19 +907,27 @@
> >>      }
> >>      p2m_unlock(p2m);
> >>
> >> +    ret = -EINVAL;
> >>      /* Pause domain if request came from guest and gfn has paging type
> >> */
> >> -    if (  p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
> >> +    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id )
> >>      {
> >>          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 )
> >> +    else if ( p2mt == p2m_ram_paging_in_start || p2mt ==
> >> p2m_ram_paging_in )
> >>      {
> >>          /* gfn is already on its way back and vcpu is not paused */
> >>          mem_event_put_req_producers(&d->mem_paging);
> >> -        return;
> >> +        return 0;
> >>      }
> >> +    else if ( !p2m_is_paging(p2mt) )
> >> +    {
> >> +        /* please clear the bit in paging->bitmap; */
> >> +        mem_event_put_req_producers(&d->mem_paging);
> >> +        goto out;
> >> +    }
> >> +
> >>
> >>      /* Send request to pager */
> >>      req.gfn = gfn;
> >> @@ -925,8 +935,13 @@
> >>      req.vcpu_id = v->vcpu_id;
> >>
> >>      mem_event_put_request(d, &d->mem_paging, &req);
> >> +
> >> +    ret = 0;
> >> + out:
> >> +    return ret;
> >>  }
> >>
> >> +
> >>  /**
> >>   * p2m_mem_paging_prep - Allocate a new page for the guest
> >>   * @d: guest domain
> >> diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
> >> --- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -485,7 +485,7 @@
> >>  /* Tell xenpaging to drop a paged out frame */
> >>  void 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);
> >> +int 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);
> >>  /* Resume normal operation (in case a domain was paused) */
> >> diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
> >> --- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
> >> +++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
> >> @@ -721,6 +721,7 @@
> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
> >> +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
> >>
> >>  /*
> >>   * Access permissions.
> >>
> >
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/xen-devel
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
> >
> > End of Xen-devel Digest, Vol 83, Issue 39
> > *****************************************
> >



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 08:57:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 08: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 1RjS4U-0004fA-Pu; Sat, 07 Jan 2012 08:56:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RjS4T-0004f2-Sj
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 08:56:14 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325926522!51562993!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNjA3Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3224 invoked from network); 7 Jan 2012 08:55:23 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-3.tower-27.messagelabs.com with SMTP;
	7 Jan 2012 08:55:23 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF007J77HMF2@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:56:11 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF00CSJ7HMSR@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:56:10 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG92747; Sat,
	07 Jan 2012 16:56:10 +0800
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152)
	by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Sat, 07 Jan 2012 16:56:00 +0800
Received: from h00166998 (10.166.80.196) by szxeml413-hub.china.huawei.com
	(10.82.67.152) with Microsoft SMTP Server id 14.1.323.3; Sat,
	07 Jan 2012 16:55:50 +0800
Date: Sat, 07 Jan 2012 16:55:49 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120106130737.GB1694@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <002c01cccd1a$279c9a00$76d5ce00$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczMdDx9Ip7V7DZvSIG1sd1myW3tbQAo5a7g
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20120105205910.GA29311@aepfle.de> <20120106130737.GB1694@aepfle.de>
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Friday, January 06, 2012 9:08 PM
> To: hongkaixing@huawei.com
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [PATCH] xenpaging:add a new array to speed up page-in in xenpaging
> 
> On Thu, Jan 05, Olaf Hering wrote:
> 
> > Is the page-out time for 512M really that fast? For me page-out is still
> > really slow even when the pagefile is in tmpfs. It takes several
> > minutes, I get around 4MB/s. page-in is around 20MB/s.
> 
> Wait, the slow page-out is due to the poll() timeout in
> xenpaging_wait_for_event_or_timeout(). This can be fixed with some sort
> of dynamic timeout while there is still something to page-out.

   I don't think so. Our approach still use 100ms in poll(), Using 10ms seems no significant change.

   In my opinion, In order to improve speed , 2 points are necessary:
   1. put page-in request fast
   2. request should be in disk order. Especially for a large swap file.


> 
> Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 08:57:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 08: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 1RjS4U-0004fA-Pu; Sat, 07 Jan 2012 08:56:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RjS4T-0004f2-Sj
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 08:56:14 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1325926522!51562993!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNjA3Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3224 invoked from network); 7 Jan 2012 08:55:23 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-3.tower-27.messagelabs.com with SMTP;
	7 Jan 2012 08:55:23 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF007J77HMF2@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:56:11 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF00CSJ7HMSR@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:56:10 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG92747; Sat,
	07 Jan 2012 16:56:10 +0800
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152)
	by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Sat, 07 Jan 2012 16:56:00 +0800
Received: from h00166998 (10.166.80.196) by szxeml413-hub.china.huawei.com
	(10.82.67.152) with Microsoft SMTP Server id 14.1.323.3; Sat,
	07 Jan 2012 16:55:50 +0800
Date: Sat, 07 Jan 2012 16:55:49 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120106130737.GB1694@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <002c01cccd1a$279c9a00$76d5ce00$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczMdDx9Ip7V7DZvSIG1sd1myW3tbQAo5a7g
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20120105205910.GA29311@aepfle.de> <20120106130737.GB1694@aepfle.de>
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
	page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Friday, January 06, 2012 9:08 PM
> To: hongkaixing@huawei.com
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [PATCH] xenpaging:add a new array to speed up page-in in xenpaging
> 
> On Thu, Jan 05, Olaf Hering wrote:
> 
> > Is the page-out time for 512M really that fast? For me page-out is still
> > really slow even when the pagefile is in tmpfs. It takes several
> > minutes, I get around 4MB/s. page-in is around 20MB/s.
> 
> Wait, the slow page-out is due to the poll() timeout in
> xenpaging_wait_for_event_or_timeout(). This can be fixed with some sort
> of dynamic timeout while there is still something to page-out.

   I don't think so. Our approach still use 100ms in poll(), Using 10ms seems no significant change.

   In my opinion, In order to improve speed , 2 points are necessary:
   1. put page-in request fast
   2. request should be in disk order. Especially for a large swap file.


> 
> Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 10:35:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 10:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjTbM-000598-BG; Sat, 07 Jan 2012 10:34:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RjTbK-000590-W1
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 10:34:15 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325932446!9937536!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiAxMzc5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2121 invoked from network); 7 Jan 2012 10:34:07 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66) by server-6.tower-182.messagelabs.com with SMTP;
	7 Jan 2012 10:34:07 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF00BNYC0TOM@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 18:34:05 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF00B88C0T82@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 18:34:05 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG96649; Sat,
	07 Jan 2012 18:34:04 +0800
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Sat, 07 Jan 2012 18:33:58 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml419-hub.china.huawei.com ([10.82.67.158])
	with mapi id 14.01.0323.003; Sat, 07 Jan 2012 18:33:44 +0800
Date: Sat, 07 Jan 2012 10:33:43 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <4F06E689.9030506@citrix.com>
X-Originating-IP: [10.166.82.189]
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E934@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DJX+VQ9QgABSyACAAItH0P//im2AgAHyHnA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: Gecc H139 MCef MR2C MdtB PKi2 PsnW P7Zf SerG U80H XCjB XIqB
	Xypg ap92 dZGz dzYT; 3;
	YQBuAGQAcgBlAHcALgBjAG8AbwBwAGUAcgAzAEAAYwBpAHQAcgBpAHgALgBjAG8AbQA7AGsAZQBpAHIAQAB4AGUAbgAuAG8AcgBnADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {EA62F8FA-C115-4969-99DC-9BCE67DFE95A};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sat,
	07 Jan 2012 10:33:28 GMT;
	UgBFADoAIABbAHgAZQBuAC0AZABlAHYAZQBsAF0AIABjAHIAZQBhAHQAZQAgAGkAcgBxACAAZgBhAGkAbABlAGQAIABkAHUAZQAgAHQAbwAgAG0AbwB2AGUAXwBjAGwAZQBhAG4AdQBwAF8AYwBvAHUAbgB0ACAAYQBsAHcAYQB5AHMAIABiAGUAaQBuAGcAIABzAGUAdAA=
x-cr-puzzleid: {EA62F8FA-C115-4969-99DC-9BCE67DFE95A}
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
	<4F06D454.1080608@citrix.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
	<4F06E689.9030506@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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



> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Friday, January 06, 2012 8:18 PM
> To: Liuyongan
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
> always being set
> 
> On 06/01/12 11:50, Liuyongan wrote:
> >
> >> -----Original Message-----
> >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> >> Sent: Friday, January 06, 2012 7:01 PM
> >> To: Liuyongan
> >> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> >> Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
> >> always being set
> >>
> >> Could you please avoid top posing.
> >>
> >> On 06/01/12 06:04, Liuyongan wrote:
> >>>    As only 33 domains were successfully created(and destroyed)
> before
> >> the problem occurring,  there should be enough free IRQ  number and
> >> vector number to allocate(suppose that irqs and vectors failed to
> >> deallocate). And destroy_irq() will clear move_in_progress, so
> >> move_cleanup_count must be setted?  Is this the case?
> >>
> >> Is it repeatably 33 domains, or was that a 1 off experiment?  Can
> you
> >   No, it's not repeatable, this occurred 2 times, another one is
> after 152 domains.
> 
> Can you list all the failures you have seen with the number of domains?
> So far it seems that it has been 33 twice but many more some of the
> time, which doesn't lend itself to saying "33 domains is a systematic
> failure" for certain at the moment.

  Sorry, to make it clear: this problems occurred 2 times one is after 33 
  domains, the other is after 152 domains. I'm not quite expressive in 
  English.

> 
> >> confirm exactly which version of Xen you are using, including
> changeset
> >> if you know it?  Without knowing your hardware, it is hard to say if
> >> there are actually enough free IRQs, although I do agree that what
> you
> >> are currently seeing is buggy behavior.
> >>
> >> The per-cpu IDT functionality introduced in Xen-4.0 is fragile at
> the
> >> best of times, and has had several bugfixes and tweaks to it which I
> am
> >> not certain have actually found their way back to Xen-4.0.  Could
> you
> >> try with Xen-4.1 and see if the problem persists?
> >>
> >> ~Andrew
> >   As I could not make it re-occure in xen-4.0, trying xen-4.1 seems
> useless.
> > I noticed a scenario:
> 
> I am confused.  Above, you say that the problem is repeatable, but here
> you say it is not.
> 
> >    1) move_in_progress occure;
> >    2) IPI IRQ_MOVE_CLEANUP_VECTOR interrupt is sent;
> >    3) the irq is destroyed, so cfg->vector is cleared, and etc.;
> >    4) IRQ_MOVE_CLEANUP_VECTOR irq is responded.
> >
> >   In xen-4.1 , step 3, vector_irq of old_cpu_mask/old_domain is also
> reset, so in step 4) move_cleanup_count will failed to sub by one, and
> finally leading to create_irq failure(right?);
> >
> >   In xen-4.0, step 3, and in my code vector_irq is not reset(this is
> a bug as you'v mentioned),  I still could not figure out why
> > create_irq should failed.
> 
> The first point of debugging should be to see how create_irq is
> failing.  Is it failing because of find_unassigned_irq() or because of
> __assign_irq_vector().
> 
> Another piece of useful information would be what your guests are and
> what they are trying to do with interrupts.  Are you using PCI
> passthrough?
> 
> ~Andrew

  Thx for your suggestion. I think I'v got the reason. Dig into details:
  1) move_in_progress occurs;
  2) new interrupt occurs on new cpus, so IPI IRQ_MOVE_CLEANUP_VECTOR 
     interrupt is sent;
  3) the irq is destroyed, so __clear_irq_vector is called;
  4) IRQ_MOVE_CLEANUP_VECTOR irq is responded with function 
     smp_irq_move_cleanup_interrupt(); 
  
  In step 3) code with patch "cpus_and(tmp_mask, cfg->old_domain, 
  cpu_online_map);" will clear vector_irq of old_cpu_mask/old_domain,
  so in step 4):
        irq = __get_cpu_var(vector_irq)[vector];

        if (irq == -1)
            continue;
  will missed the irq(cfg) to clear.

  In step 3) code without patch(this is the case of mine),vector_irq
  of old_cpu_mask is not cleared, so in step 4) irq(cfg) is found
  correctly, but at code:
         if (vector == cfg->vector && cpu_isset(me, cfg->domain))
            goto unlock;
  there is a chance that vector should equal cfg->vector and me equal
  cfg->domain, but because irq is destroyed, then not "goto unlock",so
         cfg->move_cleanup_count--;
  execute unexpectedly. And left cfg->move_cleanup_count=255 finally.

  So I think the loop made in smp_irq_move_cleanup_interrupt should 
  based on irq not vectors to find struct cfg. 

  Is that right? Drowsy head on weekend, if my analysis is right, I'll 
  submit the patch on Monday :)
   
> 
> >>>> -----Original Message-----
> >>>> From: Liuyongan
> >>>> Sent: Thursday, January 05, 2012 2:14 PM
> >>>> To: Liuyongan; xen-devel@lists.xensource.com;
> >>>> andrew.cooper3@citrix.com; keir@xen.org
> >>>> Cc: Qianhuibin
> >>>> Subject: RE: [xen-devel] create irq failed due to
> move_cleanup_count
> >>>> always being set
> >>>>
> >>>>> On 04/01/12 11:38, Andrew Cooper wrote:
> >>>>>> On 04/01/12 04:37, Liuyongan wrote:
> >>>>>> Hi, all
> >>>>>>
> >>>>>>     I'm using xen-4.0 to do a test. And when I create a domain,
> it
> >>>> failed due to create_irq() failure. As only 33 domains were
> >>>> successfully created and destroyed before I got the continuous
> >>>> failures, and the domain just before the failure was properly
> >>>> destroyed(at least destroy_irq() was properly called, which will
> >> clear
> >>>> move_in_progress, according to the prink-message). So I can
> conclude
> >>>> for certain that __assign_irq_vector failed due to
> >> move_cleanup_count
> >>>> always being set.
> >>>>> Is it always 33 domains it takes to cause the problem, or does it
> >>>> vary?
> >>>>> If it varies, then I think you want this patch
> >>>>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
> >>>> which
> >>>>> corrects the logic which works out which moved vectors it should
> >>>> clean
> >>>>> up.  Without it, stale irq numbers build up in the per-cpu
> >> irq_vector
> >>>>> tables leading to __assign_irq_vector failing with -ENOSPC as it
> >> find
> >>>>> find a vector to allocate.
> >>>>   Yes, I've noticed this patch, as only 33 domains were created
> >> before
> >>>> the failures, so vectors of a given cpu should not have been used
> >> up.
> >>>> Besides, I got this problem after 143 domains were created another
> >>>> time. But I could not repeat this problem manually as 4000+
> domains
> >>>> created successfully without this problem.
> >>>>
> >>>>>> //this is the normal case when create and destroy domain whose
> id
> >> is
> >>>> 31;
> >>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >>>>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> >>>>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> >>>>>> (XEN) irq.c:223, destroy irq 77
> >>>>>>
> >>>>>> //domain id 32 is created and destroyed correctly also.
> >>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >>>>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> >>>>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> >>>>>> (XEN) irq.c:223, destroy irq 77
> >>>>>>
> >>>>>> //all the subsequent domain creation failed, below lists only 3
> >>>> times:
> >>>>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
> >>>>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
> >>>>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
> >>>>>>
> >>>>>>      I think this might be a bug and might have fixed, so I
> >> compare
> >>>> my code with 4.1.2 and search the mail list for potential patches.
> >>>>
> >>
> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
> >>>> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch
> >> which
> >>>> add locks in __assign_irq_vector. Can anybody explain why this
> lock
> >> is
> >>>> needed? Or is there a patch that might fix my bug? Thx.
> >>>>> This patch fixes a problem where IOAPIC line level interrupts
> cease
> >>>> for
> >>>>> a while.  It has nothing to do with MSI interrupts.  (Also, there
> >> are
> >>>> no
> >>>>> locks altered, and xen-4.0-testing seems to have gained an
> >> additional
> >>>>> hunk in hvm/vmx code unrelated to the original patch.)
> >>>>>
> >>>>>>     Addition message: my board is arch-x86, no domains left when
> >>>> failed to create new ones, create_irq failure lasted one day until
> I
> >>>> reboot the board, and the irq number allocated is used certainly
> for
> >> a
> >>>> msi dev.
> >>>>>> Yong an Liu
> >>>>>> 2012.1.4
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> 
> --
> 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 Sat Jan 07 10:35:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 10:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjTbM-000598-BG; Sat, 07 Jan 2012 10:34:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1RjTbK-000590-W1
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 10:34:15 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1325932446!9937536!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiAxMzc5Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2121 invoked from network); 7 Jan 2012 10:34:07 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66) by server-6.tower-182.messagelabs.com with SMTP;
	7 Jan 2012 10:34:07 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF00BNYC0TOM@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 18:34:05 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXF00B88C0T82@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Sat, 07 Jan 2012 18:34:05 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG96649; Sat,
	07 Jan 2012 18:34:04 +0800
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Sat, 07 Jan 2012 18:33:58 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml419-hub.china.huawei.com ([10.82.67.158])
	with mapi id 14.01.0323.003; Sat, 07 Jan 2012 18:33:44 +0800
Date: Sat, 07 Jan 2012 10:33:43 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <4F06E689.9030506@citrix.com>
X-Originating-IP: [10.166.82.189]
To: Andrew Cooper <andrew.cooper3@citrix.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E934@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [xen-devel] create irq failed due to move_cleanup_count always
	being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DJX+VQ9QgABSyACAAItH0P//im2AgAHyHnA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: Gecc H139 MCef MR2C MdtB PKi2 PsnW P7Zf SerG U80H XCjB XIqB
	Xypg ap92 dZGz dzYT; 3;
	YQBuAGQAcgBlAHcALgBjAG8AbwBwAGUAcgAzAEAAYwBpAHQAcgBpAHgALgBjAG8AbQA7AGsAZQBpAHIAQAB4AGUAbgAuAG8AcgBnADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {EA62F8FA-C115-4969-99DC-9BCE67DFE95A};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sat,
	07 Jan 2012 10:33:28 GMT;
	UgBFADoAIABbAHgAZQBuAC0AZABlAHYAZQBsAF0AIABjAHIAZQBhAHQAZQAgAGkAcgBxACAAZgBhAGkAbABlAGQAIABkAHUAZQAgAHQAbwAgAG0AbwB2AGUAXwBjAGwAZQBhAG4AdQBwAF8AYwBvAHUAbgB0ACAAYQBsAHcAYQB5AHMAIABiAGUAaQBuAGcAIABzAGUAdAA=
x-cr-puzzleid: {EA62F8FA-C115-4969-99DC-9BCE67DFE95A}
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
	<4F06D454.1080608@citrix.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
	<4F06E689.9030506@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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



> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> Sent: Friday, January 06, 2012 8:18 PM
> To: Liuyongan
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
> always being set
> 
> On 06/01/12 11:50, Liuyongan wrote:
> >
> >> -----Original Message-----
> >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> >> Sent: Friday, January 06, 2012 7:01 PM
> >> To: Liuyongan
> >> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> >> Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
> >> always being set
> >>
> >> Could you please avoid top posing.
> >>
> >> On 06/01/12 06:04, Liuyongan wrote:
> >>>    As only 33 domains were successfully created(and destroyed)
> before
> >> the problem occurring,  there should be enough free IRQ  number and
> >> vector number to allocate(suppose that irqs and vectors failed to
> >> deallocate). And destroy_irq() will clear move_in_progress, so
> >> move_cleanup_count must be setted?  Is this the case?
> >>
> >> Is it repeatably 33 domains, or was that a 1 off experiment?  Can
> you
> >   No, it's not repeatable, this occurred 2 times, another one is
> after 152 domains.
> 
> Can you list all the failures you have seen with the number of domains?
> So far it seems that it has been 33 twice but many more some of the
> time, which doesn't lend itself to saying "33 domains is a systematic
> failure" for certain at the moment.

  Sorry, to make it clear: this problems occurred 2 times one is after 33 
  domains, the other is after 152 domains. I'm not quite expressive in 
  English.

> 
> >> confirm exactly which version of Xen you are using, including
> changeset
> >> if you know it?  Without knowing your hardware, it is hard to say if
> >> there are actually enough free IRQs, although I do agree that what
> you
> >> are currently seeing is buggy behavior.
> >>
> >> The per-cpu IDT functionality introduced in Xen-4.0 is fragile at
> the
> >> best of times, and has had several bugfixes and tweaks to it which I
> am
> >> not certain have actually found their way back to Xen-4.0.  Could
> you
> >> try with Xen-4.1 and see if the problem persists?
> >>
> >> ~Andrew
> >   As I could not make it re-occure in xen-4.0, trying xen-4.1 seems
> useless.
> > I noticed a scenario:
> 
> I am confused.  Above, you say that the problem is repeatable, but here
> you say it is not.
> 
> >    1) move_in_progress occure;
> >    2) IPI IRQ_MOVE_CLEANUP_VECTOR interrupt is sent;
> >    3) the irq is destroyed, so cfg->vector is cleared, and etc.;
> >    4) IRQ_MOVE_CLEANUP_VECTOR irq is responded.
> >
> >   In xen-4.1 , step 3, vector_irq of old_cpu_mask/old_domain is also
> reset, so in step 4) move_cleanup_count will failed to sub by one, and
> finally leading to create_irq failure(right?);
> >
> >   In xen-4.0, step 3, and in my code vector_irq is not reset(this is
> a bug as you'v mentioned),  I still could not figure out why
> > create_irq should failed.
> 
> The first point of debugging should be to see how create_irq is
> failing.  Is it failing because of find_unassigned_irq() or because of
> __assign_irq_vector().
> 
> Another piece of useful information would be what your guests are and
> what they are trying to do with interrupts.  Are you using PCI
> passthrough?
> 
> ~Andrew

  Thx for your suggestion. I think I'v got the reason. Dig into details:
  1) move_in_progress occurs;
  2) new interrupt occurs on new cpus, so IPI IRQ_MOVE_CLEANUP_VECTOR 
     interrupt is sent;
  3) the irq is destroyed, so __clear_irq_vector is called;
  4) IRQ_MOVE_CLEANUP_VECTOR irq is responded with function 
     smp_irq_move_cleanup_interrupt(); 
  
  In step 3) code with patch "cpus_and(tmp_mask, cfg->old_domain, 
  cpu_online_map);" will clear vector_irq of old_cpu_mask/old_domain,
  so in step 4):
        irq = __get_cpu_var(vector_irq)[vector];

        if (irq == -1)
            continue;
  will missed the irq(cfg) to clear.

  In step 3) code without patch(this is the case of mine),vector_irq
  of old_cpu_mask is not cleared, so in step 4) irq(cfg) is found
  correctly, but at code:
         if (vector == cfg->vector && cpu_isset(me, cfg->domain))
            goto unlock;
  there is a chance that vector should equal cfg->vector and me equal
  cfg->domain, but because irq is destroyed, then not "goto unlock",so
         cfg->move_cleanup_count--;
  execute unexpectedly. And left cfg->move_cleanup_count=255 finally.

  So I think the loop made in smp_irq_move_cleanup_interrupt should 
  based on irq not vectors to find struct cfg. 

  Is that right? Drowsy head on weekend, if my analysis is right, I'll 
  submit the patch on Monday :)
   
> 
> >>>> -----Original Message-----
> >>>> From: Liuyongan
> >>>> Sent: Thursday, January 05, 2012 2:14 PM
> >>>> To: Liuyongan; xen-devel@lists.xensource.com;
> >>>> andrew.cooper3@citrix.com; keir@xen.org
> >>>> Cc: Qianhuibin
> >>>> Subject: RE: [xen-devel] create irq failed due to
> move_cleanup_count
> >>>> always being set
> >>>>
> >>>>> On 04/01/12 11:38, Andrew Cooper wrote:
> >>>>>> On 04/01/12 04:37, Liuyongan wrote:
> >>>>>> Hi, all
> >>>>>>
> >>>>>>     I'm using xen-4.0 to do a test. And when I create a domain,
> it
> >>>> failed due to create_irq() failure. As only 33 domains were
> >>>> successfully created and destroyed before I got the continuous
> >>>> failures, and the domain just before the failure was properly
> >>>> destroyed(at least destroy_irq() was properly called, which will
> >> clear
> >>>> move_in_progress, according to the prink-message). So I can
> conclude
> >>>> for certain that __assign_irq_vector failed due to
> >> move_cleanup_count
> >>>> always being set.
> >>>>> Is it always 33 domains it takes to cause the problem, or does it
> >>>> vary?
> >>>>> If it varies, then I think you want this patch
> >>>>> http://xenbits.xensource.com/hg/xen-unstable.hg/rev/68b903bb1b01
> >>>> which
> >>>>> corrects the logic which works out which moved vectors it should
> >>>> clean
> >>>>> up.  Without it, stale irq numbers build up in the per-cpu
> >> irq_vector
> >>>>> tables leading to __assign_irq_vector failing with -ENOSPC as it
> >> find
> >>>>> find a vector to allocate.
> >>>>   Yes, I've noticed this patch, as only 33 domains were created
> >> before
> >>>> the failures, so vectors of a given cpu should not have been used
> >> up.
> >>>> Besides, I got this problem after 143 domains were created another
> >>>> time. But I could not repeat this problem manually as 4000+
> domains
> >>>> created successfully without this problem.
> >>>>
> >>>>>> //this is the normal case when create and destroy domain whose
> id
> >> is
> >>>> 31;
> >>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >>>>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> >>>>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> >>>>>> (XEN) irq.c:223, destroy irq 77
> >>>>>>
> >>>>>> //domain id 32 is created and destroyed correctly also.
> >>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> >>>>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> >>>>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> >>>>>> (XEN) irq.c:223, destroy irq 77
> >>>>>>
> >>>>>> //all the subsequent domain creation failed, below lists only 3
> >>>> times:
> >>>>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
> >>>>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
> >>>>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
> >>>>>>
> >>>>>>      I think this might be a bug and might have fixed, so I
> >> compare
> >>>> my code with 4.1.2 and search the mail list for potential patches.
> >>>>
> >>
> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
> >>>> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a patch
> >> which
> >>>> add locks in __assign_irq_vector. Can anybody explain why this
> lock
> >> is
> >>>> needed? Or is there a patch that might fix my bug? Thx.
> >>>>> This patch fixes a problem where IOAPIC line level interrupts
> cease
> >>>> for
> >>>>> a while.  It has nothing to do with MSI interrupts.  (Also, there
> >> are
> >>>> no
> >>>>> locks altered, and xen-4.0-testing seems to have gained an
> >> additional
> >>>>> hunk in hvm/vmx code unrelated to the original patch.)
> >>>>>
> >>>>>>     Addition message: my board is arch-x86, no domains left when
> >>>> failed to create new ones, create_irq failure lasted one day until
> I
> >>>> reboot the board, and the irq number allocated is used certainly
> for
> >> a
> >>>> msi dev.
> >>>>>> Yong an Liu
> >>>>>> 2012.1.4
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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
> 
> --
> 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 Sat Jan 07 12:05:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 12:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjV18-0005gX-RS; Sat, 07 Jan 2012 12:04:58 +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 1RjV17-0005gM-1E
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 12:04:57 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325937888!10068235!1
X-Originating-IP: [77.238.189.70]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 28484 invoked from network); 7 Jan 2012 12:04:48 -0000
Received: from nm17.bullet.mail.ird.yahoo.com (HELO
	nm17.bullet.mail.ird.yahoo.com) (77.238.189.70)
	by server-9.tower-216.messagelabs.com with SMTP;
	7 Jan 2012 12:04:48 -0000
Received: from [77.238.189.52] by nm17.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:04:47 -0000
Received: from [212.82.108.242] by tm5.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:04:47 -0000
Received: from [127.0.0.1] by omp1007.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:04:47 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 806265.97668.bm@omp1007.mail.ird.yahoo.com
Received: (qmail 3401 invoked by uid 60001); 7 Jan 2012 12:04:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325937887; bh=YnCrwsbntQ7ICFbmEns4WXcDM0aCPcxFPEA5yhlYWwI=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=ZypYBbM/lZ3u4XOwjEABlUz0y0ah51FWeHO+qY2VRUJ7k7cC5E/3PN5wUm7BKi707pyXEE9j0EcFVSyj2fKq1oxenSoafPRX/vDWe1mY89v7eV7xM2bPgg7Wqv8Sdif404TNedcuwFE9r9/hbejJOZ9j22I9Q3a6zASeyK61s0M=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=4Tn6LassqJwgR0KDY0rUgiNYKREWIfLMT2n4+7OjCHNY75DWZY2yRu8f0agwLvO7/8eCunXcf1WfdRaIqdWj0u4zf7pLuhuUxqpNkrZJn/+bwiJqQawf09UKkeJJJn42CGDBnPICmJNdiCg01/sVX8XTn6B/DnssQ8bVzTI/c20=;
X-YMail-OSG: lvBzVPsVM1nriB_Iv1_TNLSRCFJ6v.t7NsZWzItWViijAs6
	VLWKBUYLwwyi2lkiT3nhrQsHBCyF4QKrYkEyc.vbom8efG3bUkZvZleVxMDK
	ASGvF0HO0vxSd30gLYKUFbq6L7Az.dEe8Xujccj_dUX4knUgnDno5eRpUucj
	I094VDZnxvg96JOd_OyNxlgLKR8AbXiYXJPI0VC9eXESvao_nSyKxM74V0Bg
	WsAGQ_X6LgOx5V13cNaKt_jTDO4B.X2citRNYol8rizxi1WdNIPAoc2xt99s
	f9WazW.UxtMPn1A0TuapmcfQrCov4lO05AF9BIMw_ILdu8Jwv4hqyo_cbdio
	1sgxwdGVigJu4qlToPFXbpPLj9vVSRroMBLtcCd9p4LZyt11Osn9.FEYKg4g
	IRP5xtVfoyJFYUXnkQHoQ9zhS7hwxe_CCk4f_mNi18J6Zf6epfW8Mck2B3Eb
	yKVURECsMDkHYKtB_sIMhiSTtsP.XQKOLeuDEz81iAcc1LT7YuOz09UA3LqD
	lq0bB5thfvAzTz_J4UHD5p3f0cBJnd1SS85JbmOViEgp4TcBNHvM5ZbPe
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 07 Jan 2012 12:04:47 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
Message-ID: <1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 12:04:47 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: -+= Lta =+- <lta@akr.fm>
In-Reply-To: <CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Re : Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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="===============9215375606536002653=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9215375606536002653==
Content-Type: multipart/alternative; boundary="62747910-497708535-1325937887=:81780"

--62747910-497708535-1325937887=:81780
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I tested xen 4.1.2 too.Tobias patches are the patches I've tested. I am not=
 very lucky.=0A=0A=0ASince you used Tobias patches as me, my question is - =
to be more precise - could you sent Tobias patches that you have modified i=
n order to checking=0AI did not forget something as you. =0A=0A=0AMy idea i=
s that since I already have xen 4.2 installed, installing xen 4.1.2 over th=
is , something wrong happens=0A=0A=0AMy screen stays like a black screen an=
d nothing happens. no "gfx message" in the log.=0A=0AWith Xen 4.2 I tried a=
ero desktop too but my domU crashes when=A0 I tried to activate aero.=0A=0A=
=0A=0A=0A=0A________________________________=0A De=A0: -+=3D Lta =3D+- <lta=
@akr.fm>=0A=C0=A0: David TECHER <davidtecher@yahoo.fr> =0ACc=A0: xen-devel@=
lists.xensource.com =0AEnvoy=E9 le : Samedi 7 Janvier 2012 3h17=0AObjet=A0:=
 Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success repo=
rt.=0A =0A=0AHi,=0A=0A=0AOn Fri, Jan 6, 2012 at 11:23 PM, David TECHER <dav=
idtecher@yahoo.fr> wrote:=0A=0ACould you tell me what version of Xen? 4.1.0=
? 4.1.2?=0A=0AAs it is stated before this is a 4.1.2 version with debian pa=
tches=0A=A0=0A=0A>=0A>By the way could you send your patches attached to a =
mail so I could try?=0A=0A- There's also a link to tobias patche's on the f=
irst post.=0A=A0=0A=0A>=0A>Test on Xen 4.2 failed (desktop stays to lag...)=
=0A=0AHave u tried to force windows to activate the aero desktop ?=0A=A0=0A=
=0A>=0A>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but noth=
ing appears on screen.=0A=0AI also followed tobias (same as yours) instruct=
ions to dump and build vgabios-pt.bin into xen, did u do it also ?=0A=A0=0A=
=0A>=0A>Strange.=0A>=0A>=0A>=0A>=0A>________________________________=0A> De=
=A0: -+=3D Lta =3D+- <lta@akr.fm>=0A>=C0=A0: xen-devel@lists.xensource.com =
=0A>Envoy=E9 le : Vendredi 6 Janvier 2012 17h48=0A>Objet=A0: [Xen-devel] Se=
condary VGA Passthrough, nvidia, win7: success report.=0A>=0A>=0A>=0A>Hello=
 xen-devel,=0A>=0A>=0A>=0A>=0A>This is my first post on this list and as su=
ch i might be breaking some explicit/implicit rules and i apologize if it's=
 the case. Maybe this list isn't the exact=A0right=A0kind of place where to=
 post this kind of stuff, but i know lots of us are browsing this list as t=
he primary source of documentation for xen.=0A>=0A>=0A>I've read many times=
 windows 7 isn't the right os to run on top of xen. Most of the guy's who a=
re running vga passthru are recommanding to use windows xp, and i've never =
seen any success report of vga passthru on windows 7 so i thought it was im=
portant to post mine.=0A>=0A>=0A>Anyway, here's my hardware setup :=0A>- Gi=
gabyte GA-990X-UD3=0A>-=A0AMD Phenom II X6 1075T Processor=0A>- MSI Cyclone=
 NVIDIA Geforce GTX 460=0A>=0A>=0A>On the software side i'm using :=0A>=0A>=
=0A>- Debian testing as Dom0=0A>- Xen-4.1 (debian version 4.1.2-2) with wha=
t's now referred to as "Tobias Geiger patches" (http://old-list-archives.xe=
n.org/archives/html/xen-devel/2010-05/msg00441.html) (You have to edit the =
patches, changing the path to some qemu source files for them to apply)=0A>=
- debian's kernel =A03.1.5, compiled to include the pciback driver. Here's =
the output of `cat /boot/my3.1.5config | grep -i xen`=0A>CONFIG_XEN=3Dy=0A>=
CONFIG_XEN_DOM0=3Dy=0A>CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A>CONFIG_XEN_PVHVM=
=3Dy=0A>CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128=0A>CONFIG_XEN_SAVE_RESTORE=3Dy=
=0A># CONFIG_XEN_DEBUG_FS is not set=0A># CONFIG_XEN_DEBUG is not set=0A>CO=
NFIG_PCI_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKDEV_FRO=
NTEND=3Dm=0A>CONFIG_XEN_BLKDEV_BACKEND=3Dm=0A>CONFIG_NETXEN_NIC=3Dm=0A>CONF=
IG_XEN_NETDEV_FRONTEND=3Dm=0A>CONFIG_XEN_NETDEV_BACKEND=3Dm=0A>CONFIG_INPUT=
_XEN_KBDDEV_FRONTEND=3Dy=0A>CONFIG_HVC_XEN=3Dy=0A>CONFIG_XEN_WDT=3Dm=0A>CON=
FIG_XEN_FBDEV_FRONTEND=3Dy=0A># Xen driver support=0A>CONFIG_XEN_BALLOON=3D=
y=0A># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=0A>CONFIG_XEN_SCRUB_PAG=
ES=3Dy=0A>CONFIG_XEN_DEV_EVTCHN=3Dm=0A>CONFIG_XEN_BACKEND=3Dy=0A>CONFIG_XEN=
FS=3Dm=0A>CONFIG_XEN_COMPAT_XENFS=3Dy=0A>CONFIG_XEN_SYS_HYPERVISOR=3Dy=0A>C=
ONFIG_XEN_XENBUS_FRONTEND=3Dy=0A>CONFIG_XEN_GNTDEV=3Dm=0A>CONFIG_XEN_GRANT_=
DEV_ALLOC=3Dm=0A>CONFIG_XEN_PLATFORM_PCI=3Dm=0A>CONFIG_SWIOTLB_XEN=3Dy=0A>C=
ONFIG_XEN_PCIDEV_BACKEND=3Dy=0A>=0A>=0A>The kernel boot options are 'nomode=
set xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'=0A>=
=0A>=0A>- Here's my win7 domU config file :=0A>=0A>=0A>kernel =3D "/usr/lib=
/xen-4.1/boot/hvmloader"=0A>builder=3D'hvm'=0A>memory =3D 3072=0A>name =3D =
"w7"=0A>vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62=
']=0A>disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,=
w']=0A>device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0A>boot=3D"dc"=0A>=
=0A>=0A>pci=3D['01:00.0','01:00.1']=0A>gfx_passthru=3D1=0A>=0A>=0A>vcpus=3D=
6=0A>acpi=3D1=0A>sdl=3D0=0A>vnc=3D1=0A>vncconsole=3D1=0A>vncpasswd=3D''=0A>=
serial=3D'pty'=0A>usbdevice=3D'tablet'=0A>pae=3D1=0A>pci_msitranslate=3D0=
=0A>pci_power_mgmt=3D0=0A>acpi_s3 =3D 1=0A>acpi_s4 =3D 1=0A>on_poweroff =3D=
 'destroy'=0A>on_reboot =A0 =3D 'restart'=0A>on_crash =A0 =A0=3D 'restart'=
=0A>xen_platform_pci=3D1=0A>hpet =3D 1=0A>viridian=3D1=0A>monitor=3D1=0A>xe=
n_extended_power_mgmt=3D2=0A>hpet=3D1=0A>=0A>=0A>What's important here for =
the Nvidia drivers to work and not give a nice nvlddmkm.sys BSOD is:=0A>pci=
_msitranslate=3D0=0A>pci_power_mgmt=3D0=0A>=0A>=0A>- Windows 7 32bits=0A>- =
Nvidia drivers 275.33=0A>- You have to manually run aero speed test or forc=
e aero to start by using registry entries for the desktop not to be laggy=
=0A>=0A>=0A>The windows 7 domU is running fine with no performance decrease=
 noticeable, although i've not yet played intensive gpu video game, i'm sti=
ll pretty confident they'll run fine.=0A>=0A>=0A>Anyway. i've still some pr=
oblems i shall report in separate posts :=0A>- The PCI bus topology isn't p=
reserved, and the gfx card, which is plugged on 01:00 becomes 05:00 on domU=
.=0A>- I'm passing through an RME Hdsp / hammerfall pci sound card to the d=
omU and while it is working fine on his own, there's a strange interaction =
between it and the GPLPV network driver. When i start playing sound, the ne=
twork instantly cease working. It starts back as soon as i stop playing aud=
io.=0A>=0A>=0A>That's all folks,=0A>=0A>=0A>Cheers,=0A>Lta=0A>=0A>=0A>_____=
__________________________________________=0A>Xen-devel mailing list=0A>Xen=
-devel@lists.xensource.com=0A>http://lists.xensource.com/xen-devel=0A>=0A>=
=0A>
--62747910-497708535-1325937887=:81780
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>I tested x=
en 4.1.2 too.</span><span> Tobias patches are the patches I've tested. I am=
 not very lucky.<br></span></div><div><span><br></span></div><div><span>Sin=
ce you used Tobias patches as me, my question is - to be more precise - cou=
ld you sent Tobias patches that you have modified in order to checking</spa=
n></div><div><span>I did not forget something as you. <br></span></div><div=
><br><span></span></div><div><span>My idea is that since I already have xen=
 4.2 installed, installing xen 4.1.2 over this , something wrong happens<br=
></span></div><div><br><span></span></div><div><span>My screen stays like a=
 black screen and nothing happens. no "gfx message" in the log.</span></div=
><div><br><span></span></div><div><span>With Xen 4.2 I tried aero desktop t=
oo but my domU crashes when&nbsp; I tried to activate
 aero.<br></span></div><div><br><span></span></div><div><span></span></div>=
<div><br></div>  <div style=3D"font-family: times new roman, new york, time=
s, serif; font-size: 12pt;"> <div style=3D"font-family: times new roman, ne=
w 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> -=
+=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight: bold;"=
>=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><sp=
an style=3D"font-weight: bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensou=
rce.com <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span></b>=
 Samedi 7 Janvier 2012 3h17<br> <b><span style=3D"font-weight: bold;">Objet=
&nbsp;:</span></b> Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, =
win7: success report.<br> </font> <br><div id=3D"yiv2088496790">Hi,<br><br>=
<div class=3D"yiv2088496790gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, Da=
vid TECHER <span
 dir=3D"ltr">&lt;<a rel=3D"nofollow" ymailto=3D"mailto:davidtecher@yahoo.fr=
" target=3D"_blank" href=3D"mailto:davidtecher@yahoo.fr">davidtecher@yahoo.=
fr</a>&gt;</span> wrote:<br><blockquote class=3D"yiv2088496790gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=
=0A<div><div style=3D"font-size:12pt;font-family:times new roman, new york,=
 times, serif;"><div><span>Could you tell me what version of Xen? 4.1.0? 4.=
1.2?</span></div></div></div></blockquote><div><br></div><div>As it is stat=
ed before this is a 4.1.2 version with debian patches</div>=0A<div>&nbsp;</=
div><blockquote class=3D"yiv2088496790gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div style=3D"font-si=
ze:12pt;font-family:times new roman, new york, times, serif;"><div><br><spa=
n></span></div>=0A<div><span>By the way could you send your patches attache=
d to a mail so I could try?</span></div></div></div></blockquote><div><br><=
/div><div>- There's also a link to tobias patche's on the first post.</div>=
<div>&nbsp;</div>=0A<blockquote class=3D"yiv2088496790gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div =
style=3D"font-size:12pt;font-family:times new roman, new york, times, serif=
;"><div><br><span></span></div><div><span>Test on Xen 4.2 failed (desktop s=
tays to lag...)</span></div>=0A</div></div></blockquote><div><br></div><div=
>Have u tried to force windows to activate the aero desktop ?</div><div>&nb=
sp;</div><blockquote class=3D"yiv2088496790gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D=
"font-size:12pt;font-family:times new roman, new york, times, serif;"><div>=
<br><span></span></div><div><span>With installing xen 4.1.0/4.2.0 over my x=
en 4.2, domU boot but nothing appears on screen.</span></div>=0A</div></div=
></blockquote><div><br></div><div>I also followed tobias (same as yours) in=
structions to dump and build vgabios-pt.bin into xen, did u do it also ?</d=
iv><div>&nbsp;</div><blockquote class=3D"yiv2088496790gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><d=
iv style=3D"font-size:12pt;font-family:times new roman, new york, times, se=
rif;"><div><br><span></span></div><div><span>Strange.<br></span></div><div>=
<br></div>  <div style=3D"font-family:times new roman, new york, times, ser=
if;font-size:12pt;">=0A <div style=3D"font-family:times new roman, new york=
, times, serif;font-size:12pt;"> <font face=3D"Arial"><div class=3D"yiv2088=
496790im"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:<=
/span></b> -+=3D Lta =3D+- &lt;<a rel=3D"nofollow" ymailto=3D"mailto:lta@ak=
r.fm" target=3D"_blank" href=3D"mailto:lta@akr.fm">lta@akr.fm</a>&gt;<br>=
=0A </div><b><span style=3D"font-weight:bold;">=C0&nbsp;:</span></b> <a rel=
=3D"nofollow" ymailto=3D"mailto:xen-devel@lists.xensource.com" target=3D"_b=
lank" href=3D"mailto:xen-devel@lists.xensource.com">xen-devel@lists.xensour=
ce.com</a> <br> <b><span style=3D"font-weight:bold;">Envoy=E9 le :</span></=
b> Vendredi 6 Janvier 2012 17h48<br>=0A <b><span style=3D"font-weight:bold;=
">Objet&nbsp;:</span></b> [Xen-devel] Secondary VGA Passthrough, nvidia, wi=
n7: success report.<br> </font><div><div class=3D"yiv2088496790h5"> <br><di=
v><div>Hello xen-devel,<div><br></div><div><br></div><div>=0AThis is my fir=
st post on this list and as such i might be breaking some explicit/implicit=
 rules and i apologize if it's the case. Maybe this list isn't the exact&nb=
sp;right&nbsp;kind of place where to post this kind of stuff, but i know lo=
ts of us are browsing this list as the primary source of documentation for =
xen.</div>=0A=0A=0A<div><br></div><div>I've read many times windows 7 isn't=
 the right os to run on top of xen. Most of the guy's who are running vga p=
assthru are recommanding to use windows xp, and i've never seen any success=
 report of vga passthru on windows 7 so i thought it was important to post =
mine.</div>=0A=0A=0A<div><br></div><div>Anyway, here's my hardware setup :<=
/div><div>- Gigabyte GA-990X-UD3</div><div>-&nbsp;AMD Phenom II X6 1075T Pr=
ocessor</div><div>- MSI Cyclone NVIDIA Geforce GTX 460</div><div><br></div>=
<div>On the software side i'm using :</div>=0A=0A=0A<div><br></div><div>- D=
ebian testing as Dom0</div><div>- Xen-4.1 (debian version 4.1.2-2) with wha=
t's now referred to as "Tobias Geiger patches" (<a rel=3D"nofollow" target=
=3D"_blank" href=3D"http://old-list-archives.xen.org/archives/html/xen-deve=
l/2010-05/msg00441.html">http://old-list-archives.xen.org/archives/html/xen=
-devel/2010-05/msg00441.html</a>) (You have to edit the patches, changing t=
he path to some qemu source files for them to apply)</div>=0A=0A=0A<div>- d=
ebian's kernel &nbsp;3.1.5, compiled to include the pciback driver. Here's =
the output of `cat /boot/my3.1.5config | grep -i xen`</div><div><div><font =
size=3D"1">CONFIG_XEN=3Dy</font></div><div>=0A<font size=3D"1">CONFIG_XEN_D=
OM0=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</=
font></div><div><font size=3D"1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><=
font size=3D"1">CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><font s=
ize=3D"1">CONFIG_XEN_SAVE_RESTORE=3Dy</font></div><div><font size=3D"1"># C=
ONFIG_XEN_DEBUG_FS is not set</font></div>=0A<div><font size=3D"1"># CONFIG=
_XEN_DEBUG is not set</font></div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy<=
/font></div><div><font size=3D"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></di=
v>=0A<div><font size=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div>=
<font size=3D"1">CONFIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=
=3D"1">CONFIG_NETXEN_NIC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XE=
N_NETDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_NETDEV_B=
ACKEND=3Dm</font></div><div><font size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTE=
ND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div>=
<div><font size=3D"1">CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">=
CONFIG_XEN_FBDEV_FRONTEND=3Dy</font></div>=0A<div><font size=3D"1"># Xen dr=
iver support</font></div><div><font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font=
></div><div><font size=3D"1"># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=
</font></div>=0A<div><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></di=
v><div><font size=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font si=
ze=3D"1">CONFIG_XEN_BACKEND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG=
_XENFS=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</f=
ont></div><div><font size=3D"1">CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=
=0A<div><font size=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONF=
IG_XEN_GRANT_DEV_ALLOC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_=
PLATFORM_PCI=3Dm</font></div><div><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</=
font></div><div><font size=3D"1">CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=
=0A</div><div><font size=3D"1"><br></font></div><div>The kernel boot option=
s are 'nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(0=
1:00.1)'</div><div><br></div><div>- Here's my win7 domU config file :</div>=
=0A=0A=0A<div><br></div><div><div><font size=3D"1">kernel =3D "/usr/lib/xen=
-4.1/boot/hvmloader"</font></div><div><font size=3D"1">builder=3D'hvm'</fon=
t></div><div><font size=3D"1">memory =3D 3072</font></div>=0A<div><font siz=
e=3D"1">name =3D "w7"</font></div><div><font size=3D"1">vif =3D [ 'type=3Dn=
etfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62']</font></div><div><font s=
ize=3D"1">disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,=
hdb,w']</font></div>=0A=0A=0A<div><font size=3D"1">device_model =3D '/usr/l=
ib/xen-4.1/bin/qemu-dm'</font></div><div><font size=3D"1">boot=3D"dc"</font=
></div><div><font size=3D"1"><br>=0A</font></div><div><font size=3D"1">pci=
=3D['01:00.0','01:00.1']</font></div><div><font size=3D"1">gfx_passthru=3D1=
</font></div><div><font size=3D"1"><br>=0A</font></div><div><font size=3D"1=
">vcpus=3D6</font></div><div><font size=3D"1">acpi=3D1</font></div><div><fo=
nt size=3D"1">sdl=3D0</font></div><div><font size=3D"1">vnc=3D1</font></div=
>=0A<div><font size=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">=
vncpasswd=3D''</font></div><div><font size=3D"1">serial=3D'pty'</font></div=
>=0A<div><font size=3D"1">usbdevice=3D'tablet'</font></div><div><font size=
=3D"1">pae=3D1</font></div><div><font size=3D"1">pci_msitranslate=3D0</font=
></div>=0A<div><font size=3D"1">pci_power_mgmt=3D0</font></div><div><font s=
ize=3D"1">acpi_s3 =3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</fo=
nt></div><div><font size=3D"1">on_poweroff =3D 'destroy'</font></div>=0A<di=
v><font size=3D"1">on_reboot &nbsp; =3D 'restart'</font></div><div><font si=
ze=3D"1">on_crash &nbsp; &nbsp;=3D 'restart'</font></div><div><font size=3D=
"1">xen_platform_pci=3D1</font></div>=0A<div><font size=3D"1">hpet =3D 1</f=
ont></div><div><font size=3D"1">viridian=3D1</font></div><div><font size=3D=
"1">monitor=3D1</font></div><div><font size=3D"1">xen_extended_power_mgmt=
=3D2</font></div>=0A<div><font size=3D"1">hpet=3D1</font></div></div><div><=
br></div><div>What's important here for the Nvidia drivers to work and not =
give a nice nvlddmkm.sys BSOD is:</div><div><div><font size=3D"1">pci_msitr=
anslate=3D0</font></div>=0A=0A=0A<div><font size=3D"1">pci_power_mgmt=3D0</=
font></div></div><div><font size=3D"1"><br></font></div><div>- Windows 7 32=
bits</div><div>- Nvidia drivers 275.33</div><div>- You have to manually run=
 aero speed test or force aero to start by using registry entries for the d=
esktop not to be laggy</div>=0A=0A=0A<div><br></div><div>The windows 7 domU=
 is running fine with no performance decrease noticeable, although i've not=
 yet played intensive gpu video game, i'm still pretty confident they'll ru=
n fine.</div><div><br>=0A=0A=0A</div><div>Anyway. i've still some problems =
i shall report in separate posts :</div><div>- The PCI bus topology isn't p=
reserved, and the gfx card, which is plugged on 01:00 becomes 05:00 on domU=
.</div><div>- I'm passing through an RME Hdsp / hammerfall pci sound card t=
o the domU and while it is working fine on his own, there's a strange inter=
action between it and the GPLPV network driver. When i start playing sound,=
 the network instantly cease working. It starts back as soon as i stop play=
ing audio.</div>=0A=0A=0A<div><br></div><div>That's all folks,</div><div><b=
r></div><div>Cheers,</div><div>Lta</div>=0A</div><br>=0A</div><br></div></d=
iv><div class=3D"yiv2088496790im">_________________________________________=
______<br>Xen-devel mailing list<br><a rel=3D"nofollow" ymailto=3D"mailto:X=
en-devel@lists.xensource.com" target=3D"_blank" href=3D"mailto:Xen-devel@li=
sts.xensource.com">Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow"=
 target=3D"_blank" href=3D"http://lists.xensource.com/xen-devel">http://lis=
ts.xensource.com/xen-devel</a><br>=0A<br><br> </div></div> </div>  </div></=
div></blockquote></div><br>=0A</div><br><br> </div> </div>  </div></body></=
html>
--62747910-497708535-1325937887=:81780--


--===============9215375606536002653==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9215375606536002653==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 12:05:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 12:05:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjV18-0005gX-RS; Sat, 07 Jan 2012 12:04:58 +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 1RjV17-0005gM-1E
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 12:04:57 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-9.tower-216.messagelabs.com!1325937888!10068235!1
X-Originating-IP: [77.238.189.70]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 28484 invoked from network); 7 Jan 2012 12:04:48 -0000
Received: from nm17.bullet.mail.ird.yahoo.com (HELO
	nm17.bullet.mail.ird.yahoo.com) (77.238.189.70)
	by server-9.tower-216.messagelabs.com with SMTP;
	7 Jan 2012 12:04:48 -0000
Received: from [77.238.189.52] by nm17.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:04:47 -0000
Received: from [212.82.108.242] by tm5.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:04:47 -0000
Received: from [127.0.0.1] by omp1007.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:04:47 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 806265.97668.bm@omp1007.mail.ird.yahoo.com
Received: (qmail 3401 invoked by uid 60001); 7 Jan 2012 12:04:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325937887; bh=YnCrwsbntQ7ICFbmEns4WXcDM0aCPcxFPEA5yhlYWwI=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=ZypYBbM/lZ3u4XOwjEABlUz0y0ah51FWeHO+qY2VRUJ7k7cC5E/3PN5wUm7BKi707pyXEE9j0EcFVSyj2fKq1oxenSoafPRX/vDWe1mY89v7eV7xM2bPgg7Wqv8Sdif404TNedcuwFE9r9/hbejJOZ9j22I9Q3a6zASeyK61s0M=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=4Tn6LassqJwgR0KDY0rUgiNYKREWIfLMT2n4+7OjCHNY75DWZY2yRu8f0agwLvO7/8eCunXcf1WfdRaIqdWj0u4zf7pLuhuUxqpNkrZJn/+bwiJqQawf09UKkeJJJn42CGDBnPICmJNdiCg01/sVX8XTn6B/DnssQ8bVzTI/c20=;
X-YMail-OSG: lvBzVPsVM1nriB_Iv1_TNLSRCFJ6v.t7NsZWzItWViijAs6
	VLWKBUYLwwyi2lkiT3nhrQsHBCyF4QKrYkEyc.vbom8efG3bUkZvZleVxMDK
	ASGvF0HO0vxSd30gLYKUFbq6L7Az.dEe8Xujccj_dUX4knUgnDno5eRpUucj
	I094VDZnxvg96JOd_OyNxlgLKR8AbXiYXJPI0VC9eXESvao_nSyKxM74V0Bg
	WsAGQ_X6LgOx5V13cNaKt_jTDO4B.X2citRNYol8rizxi1WdNIPAoc2xt99s
	f9WazW.UxtMPn1A0TuapmcfQrCov4lO05AF9BIMw_ILdu8Jwv4hqyo_cbdio
	1sgxwdGVigJu4qlToPFXbpPLj9vVSRroMBLtcCd9p4LZyt11Osn9.FEYKg4g
	IRP5xtVfoyJFYUXnkQHoQ9zhS7hwxe_CCk4f_mNi18J6Zf6epfW8Mck2B3Eb
	yKVURECsMDkHYKtB_sIMhiSTtsP.XQKOLeuDEz81iAcc1LT7YuOz09UA3LqD
	lq0bB5thfvAzTz_J4UHD5p3f0cBJnd1SS85JbmOViEgp4TcBNHvM5ZbPe
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 07 Jan 2012 12:04:47 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
Message-ID: <1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 12:04:47 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: -+= Lta =+- <lta@akr.fm>
In-Reply-To: <CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Re : Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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="===============9215375606536002653=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9215375606536002653==
Content-Type: multipart/alternative; boundary="62747910-497708535-1325937887=:81780"

--62747910-497708535-1325937887=:81780
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I tested xen 4.1.2 too.Tobias patches are the patches I've tested. I am not=
 very lucky.=0A=0A=0ASince you used Tobias patches as me, my question is - =
to be more precise - could you sent Tobias patches that you have modified i=
n order to checking=0AI did not forget something as you. =0A=0A=0AMy idea i=
s that since I already have xen 4.2 installed, installing xen 4.1.2 over th=
is , something wrong happens=0A=0A=0AMy screen stays like a black screen an=
d nothing happens. no "gfx message" in the log.=0A=0AWith Xen 4.2 I tried a=
ero desktop too but my domU crashes when=A0 I tried to activate aero.=0A=0A=
=0A=0A=0A=0A________________________________=0A De=A0: -+=3D Lta =3D+- <lta=
@akr.fm>=0A=C0=A0: David TECHER <davidtecher@yahoo.fr> =0ACc=A0: xen-devel@=
lists.xensource.com =0AEnvoy=E9 le : Samedi 7 Janvier 2012 3h17=0AObjet=A0:=
 Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success repo=
rt.=0A =0A=0AHi,=0A=0A=0AOn Fri, Jan 6, 2012 at 11:23 PM, David TECHER <dav=
idtecher@yahoo.fr> wrote:=0A=0ACould you tell me what version of Xen? 4.1.0=
? 4.1.2?=0A=0AAs it is stated before this is a 4.1.2 version with debian pa=
tches=0A=A0=0A=0A>=0A>By the way could you send your patches attached to a =
mail so I could try?=0A=0A- There's also a link to tobias patche's on the f=
irst post.=0A=A0=0A=0A>=0A>Test on Xen 4.2 failed (desktop stays to lag...)=
=0A=0AHave u tried to force windows to activate the aero desktop ?=0A=A0=0A=
=0A>=0A>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but noth=
ing appears on screen.=0A=0AI also followed tobias (same as yours) instruct=
ions to dump and build vgabios-pt.bin into xen, did u do it also ?=0A=A0=0A=
=0A>=0A>Strange.=0A>=0A>=0A>=0A>=0A>________________________________=0A> De=
=A0: -+=3D Lta =3D+- <lta@akr.fm>=0A>=C0=A0: xen-devel@lists.xensource.com =
=0A>Envoy=E9 le : Vendredi 6 Janvier 2012 17h48=0A>Objet=A0: [Xen-devel] Se=
condary VGA Passthrough, nvidia, win7: success report.=0A>=0A>=0A>=0A>Hello=
 xen-devel,=0A>=0A>=0A>=0A>=0A>This is my first post on this list and as su=
ch i might be breaking some explicit/implicit rules and i apologize if it's=
 the case. Maybe this list isn't the exact=A0right=A0kind of place where to=
 post this kind of stuff, but i know lots of us are browsing this list as t=
he primary source of documentation for xen.=0A>=0A>=0A>I've read many times=
 windows 7 isn't the right os to run on top of xen. Most of the guy's who a=
re running vga passthru are recommanding to use windows xp, and i've never =
seen any success report of vga passthru on windows 7 so i thought it was im=
portant to post mine.=0A>=0A>=0A>Anyway, here's my hardware setup :=0A>- Gi=
gabyte GA-990X-UD3=0A>-=A0AMD Phenom II X6 1075T Processor=0A>- MSI Cyclone=
 NVIDIA Geforce GTX 460=0A>=0A>=0A>On the software side i'm using :=0A>=0A>=
=0A>- Debian testing as Dom0=0A>- Xen-4.1 (debian version 4.1.2-2) with wha=
t's now referred to as "Tobias Geiger patches" (http://old-list-archives.xe=
n.org/archives/html/xen-devel/2010-05/msg00441.html) (You have to edit the =
patches, changing the path to some qemu source files for them to apply)=0A>=
- debian's kernel =A03.1.5, compiled to include the pciback driver. Here's =
the output of `cat /boot/my3.1.5config | grep -i xen`=0A>CONFIG_XEN=3Dy=0A>=
CONFIG_XEN_DOM0=3Dy=0A>CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A>CONFIG_XEN_PVHVM=
=3Dy=0A>CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128=0A>CONFIG_XEN_SAVE_RESTORE=3Dy=
=0A># CONFIG_XEN_DEBUG_FS is not set=0A># CONFIG_XEN_DEBUG is not set=0A>CO=
NFIG_PCI_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKDEV_FRO=
NTEND=3Dm=0A>CONFIG_XEN_BLKDEV_BACKEND=3Dm=0A>CONFIG_NETXEN_NIC=3Dm=0A>CONF=
IG_XEN_NETDEV_FRONTEND=3Dm=0A>CONFIG_XEN_NETDEV_BACKEND=3Dm=0A>CONFIG_INPUT=
_XEN_KBDDEV_FRONTEND=3Dy=0A>CONFIG_HVC_XEN=3Dy=0A>CONFIG_XEN_WDT=3Dm=0A>CON=
FIG_XEN_FBDEV_FRONTEND=3Dy=0A># Xen driver support=0A>CONFIG_XEN_BALLOON=3D=
y=0A># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=0A>CONFIG_XEN_SCRUB_PAG=
ES=3Dy=0A>CONFIG_XEN_DEV_EVTCHN=3Dm=0A>CONFIG_XEN_BACKEND=3Dy=0A>CONFIG_XEN=
FS=3Dm=0A>CONFIG_XEN_COMPAT_XENFS=3Dy=0A>CONFIG_XEN_SYS_HYPERVISOR=3Dy=0A>C=
ONFIG_XEN_XENBUS_FRONTEND=3Dy=0A>CONFIG_XEN_GNTDEV=3Dm=0A>CONFIG_XEN_GRANT_=
DEV_ALLOC=3Dm=0A>CONFIG_XEN_PLATFORM_PCI=3Dm=0A>CONFIG_SWIOTLB_XEN=3Dy=0A>C=
ONFIG_XEN_PCIDEV_BACKEND=3Dy=0A>=0A>=0A>The kernel boot options are 'nomode=
set xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'=0A>=
=0A>=0A>- Here's my win7 domU config file :=0A>=0A>=0A>kernel =3D "/usr/lib=
/xen-4.1/boot/hvmloader"=0A>builder=3D'hvm'=0A>memory =3D 3072=0A>name =3D =
"w7"=0A>vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62=
']=0A>disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,=
w']=0A>device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0A>boot=3D"dc"=0A>=
=0A>=0A>pci=3D['01:00.0','01:00.1']=0A>gfx_passthru=3D1=0A>=0A>=0A>vcpus=3D=
6=0A>acpi=3D1=0A>sdl=3D0=0A>vnc=3D1=0A>vncconsole=3D1=0A>vncpasswd=3D''=0A>=
serial=3D'pty'=0A>usbdevice=3D'tablet'=0A>pae=3D1=0A>pci_msitranslate=3D0=
=0A>pci_power_mgmt=3D0=0A>acpi_s3 =3D 1=0A>acpi_s4 =3D 1=0A>on_poweroff =3D=
 'destroy'=0A>on_reboot =A0 =3D 'restart'=0A>on_crash =A0 =A0=3D 'restart'=
=0A>xen_platform_pci=3D1=0A>hpet =3D 1=0A>viridian=3D1=0A>monitor=3D1=0A>xe=
n_extended_power_mgmt=3D2=0A>hpet=3D1=0A>=0A>=0A>What's important here for =
the Nvidia drivers to work and not give a nice nvlddmkm.sys BSOD is:=0A>pci=
_msitranslate=3D0=0A>pci_power_mgmt=3D0=0A>=0A>=0A>- Windows 7 32bits=0A>- =
Nvidia drivers 275.33=0A>- You have to manually run aero speed test or forc=
e aero to start by using registry entries for the desktop not to be laggy=
=0A>=0A>=0A>The windows 7 domU is running fine with no performance decrease=
 noticeable, although i've not yet played intensive gpu video game, i'm sti=
ll pretty confident they'll run fine.=0A>=0A>=0A>Anyway. i've still some pr=
oblems i shall report in separate posts :=0A>- The PCI bus topology isn't p=
reserved, and the gfx card, which is plugged on 01:00 becomes 05:00 on domU=
.=0A>- I'm passing through an RME Hdsp / hammerfall pci sound card to the d=
omU and while it is working fine on his own, there's a strange interaction =
between it and the GPLPV network driver. When i start playing sound, the ne=
twork instantly cease working. It starts back as soon as i stop playing aud=
io.=0A>=0A>=0A>That's all folks,=0A>=0A>=0A>Cheers,=0A>Lta=0A>=0A>=0A>_____=
__________________________________________=0A>Xen-devel mailing list=0A>Xen=
-devel@lists.xensource.com=0A>http://lists.xensource.com/xen-devel=0A>=0A>=
=0A>
--62747910-497708535-1325937887=:81780
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>I tested x=
en 4.1.2 too.</span><span> Tobias patches are the patches I've tested. I am=
 not very lucky.<br></span></div><div><span><br></span></div><div><span>Sin=
ce you used Tobias patches as me, my question is - to be more precise - cou=
ld you sent Tobias patches that you have modified in order to checking</spa=
n></div><div><span>I did not forget something as you. <br></span></div><div=
><br><span></span></div><div><span>My idea is that since I already have xen=
 4.2 installed, installing xen 4.1.2 over this , something wrong happens<br=
></span></div><div><br><span></span></div><div><span>My screen stays like a=
 black screen and nothing happens. no "gfx message" in the log.</span></div=
><div><br><span></span></div><div><span>With Xen 4.2 I tried aero desktop t=
oo but my domU crashes when&nbsp; I tried to activate
 aero.<br></span></div><div><br><span></span></div><div><span></span></div>=
<div><br></div>  <div style=3D"font-family: times new roman, new york, time=
s, serif; font-size: 12pt;"> <div style=3D"font-family: times new roman, ne=
w 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> -=
+=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight: bold;"=
>=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><sp=
an style=3D"font-weight: bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensou=
rce.com <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span></b>=
 Samedi 7 Janvier 2012 3h17<br> <b><span style=3D"font-weight: bold;">Objet=
&nbsp;:</span></b> Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, =
win7: success report.<br> </font> <br><div id=3D"yiv2088496790">Hi,<br><br>=
<div class=3D"yiv2088496790gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, Da=
vid TECHER <span
 dir=3D"ltr">&lt;<a rel=3D"nofollow" ymailto=3D"mailto:davidtecher@yahoo.fr=
" target=3D"_blank" href=3D"mailto:davidtecher@yahoo.fr">davidtecher@yahoo.=
fr</a>&gt;</span> wrote:<br><blockquote class=3D"yiv2088496790gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=
=0A<div><div style=3D"font-size:12pt;font-family:times new roman, new york,=
 times, serif;"><div><span>Could you tell me what version of Xen? 4.1.0? 4.=
1.2?</span></div></div></div></blockquote><div><br></div><div>As it is stat=
ed before this is a 4.1.2 version with debian patches</div>=0A<div>&nbsp;</=
div><blockquote class=3D"yiv2088496790gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div style=3D"font-si=
ze:12pt;font-family:times new roman, new york, times, serif;"><div><br><spa=
n></span></div>=0A<div><span>By the way could you send your patches attache=
d to a mail so I could try?</span></div></div></div></blockquote><div><br><=
/div><div>- There's also a link to tobias patche's on the first post.</div>=
<div>&nbsp;</div>=0A<blockquote class=3D"yiv2088496790gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div =
style=3D"font-size:12pt;font-family:times new roman, new york, times, serif=
;"><div><br><span></span></div><div><span>Test on Xen 4.2 failed (desktop s=
tays to lag...)</span></div>=0A</div></div></blockquote><div><br></div><div=
>Have u tried to force windows to activate the aero desktop ?</div><div>&nb=
sp;</div><blockquote class=3D"yiv2088496790gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D=
"font-size:12pt;font-family:times new roman, new york, times, serif;"><div>=
<br><span></span></div><div><span>With installing xen 4.1.0/4.2.0 over my x=
en 4.2, domU boot but nothing appears on screen.</span></div>=0A</div></div=
></blockquote><div><br></div><div>I also followed tobias (same as yours) in=
structions to dump and build vgabios-pt.bin into xen, did u do it also ?</d=
iv><div>&nbsp;</div><blockquote class=3D"yiv2088496790gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><d=
iv style=3D"font-size:12pt;font-family:times new roman, new york, times, se=
rif;"><div><br><span></span></div><div><span>Strange.<br></span></div><div>=
<br></div>  <div style=3D"font-family:times new roman, new york, times, ser=
if;font-size:12pt;">=0A <div style=3D"font-family:times new roman, new york=
, times, serif;font-size:12pt;"> <font face=3D"Arial"><div class=3D"yiv2088=
496790im"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:<=
/span></b> -+=3D Lta =3D+- &lt;<a rel=3D"nofollow" ymailto=3D"mailto:lta@ak=
r.fm" target=3D"_blank" href=3D"mailto:lta@akr.fm">lta@akr.fm</a>&gt;<br>=
=0A </div><b><span style=3D"font-weight:bold;">=C0&nbsp;:</span></b> <a rel=
=3D"nofollow" ymailto=3D"mailto:xen-devel@lists.xensource.com" target=3D"_b=
lank" href=3D"mailto:xen-devel@lists.xensource.com">xen-devel@lists.xensour=
ce.com</a> <br> <b><span style=3D"font-weight:bold;">Envoy=E9 le :</span></=
b> Vendredi 6 Janvier 2012 17h48<br>=0A <b><span style=3D"font-weight:bold;=
">Objet&nbsp;:</span></b> [Xen-devel] Secondary VGA Passthrough, nvidia, wi=
n7: success report.<br> </font><div><div class=3D"yiv2088496790h5"> <br><di=
v><div>Hello xen-devel,<div><br></div><div><br></div><div>=0AThis is my fir=
st post on this list and as such i might be breaking some explicit/implicit=
 rules and i apologize if it's the case. Maybe this list isn't the exact&nb=
sp;right&nbsp;kind of place where to post this kind of stuff, but i know lo=
ts of us are browsing this list as the primary source of documentation for =
xen.</div>=0A=0A=0A<div><br></div><div>I've read many times windows 7 isn't=
 the right os to run on top of xen. Most of the guy's who are running vga p=
assthru are recommanding to use windows xp, and i've never seen any success=
 report of vga passthru on windows 7 so i thought it was important to post =
mine.</div>=0A=0A=0A<div><br></div><div>Anyway, here's my hardware setup :<=
/div><div>- Gigabyte GA-990X-UD3</div><div>-&nbsp;AMD Phenom II X6 1075T Pr=
ocessor</div><div>- MSI Cyclone NVIDIA Geforce GTX 460</div><div><br></div>=
<div>On the software side i'm using :</div>=0A=0A=0A<div><br></div><div>- D=
ebian testing as Dom0</div><div>- Xen-4.1 (debian version 4.1.2-2) with wha=
t's now referred to as "Tobias Geiger patches" (<a rel=3D"nofollow" target=
=3D"_blank" href=3D"http://old-list-archives.xen.org/archives/html/xen-deve=
l/2010-05/msg00441.html">http://old-list-archives.xen.org/archives/html/xen=
-devel/2010-05/msg00441.html</a>) (You have to edit the patches, changing t=
he path to some qemu source files for them to apply)</div>=0A=0A=0A<div>- d=
ebian's kernel &nbsp;3.1.5, compiled to include the pciback driver. Here's =
the output of `cat /boot/my3.1.5config | grep -i xen`</div><div><div><font =
size=3D"1">CONFIG_XEN=3Dy</font></div><div>=0A<font size=3D"1">CONFIG_XEN_D=
OM0=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</=
font></div><div><font size=3D"1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><=
font size=3D"1">CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><font s=
ize=3D"1">CONFIG_XEN_SAVE_RESTORE=3Dy</font></div><div><font size=3D"1"># C=
ONFIG_XEN_DEBUG_FS is not set</font></div>=0A<div><font size=3D"1"># CONFIG=
_XEN_DEBUG is not set</font></div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy<=
/font></div><div><font size=3D"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></di=
v>=0A<div><font size=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div>=
<font size=3D"1">CONFIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=
=3D"1">CONFIG_NETXEN_NIC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XE=
N_NETDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_NETDEV_B=
ACKEND=3Dm</font></div><div><font size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTE=
ND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div>=
<div><font size=3D"1">CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">=
CONFIG_XEN_FBDEV_FRONTEND=3Dy</font></div>=0A<div><font size=3D"1"># Xen dr=
iver support</font></div><div><font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font=
></div><div><font size=3D"1"># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=
</font></div>=0A<div><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></di=
v><div><font size=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font si=
ze=3D"1">CONFIG_XEN_BACKEND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG=
_XENFS=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</f=
ont></div><div><font size=3D"1">CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=
=0A<div><font size=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONF=
IG_XEN_GRANT_DEV_ALLOC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_=
PLATFORM_PCI=3Dm</font></div><div><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</=
font></div><div><font size=3D"1">CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=
=0A</div><div><font size=3D"1"><br></font></div><div>The kernel boot option=
s are 'nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(0=
1:00.1)'</div><div><br></div><div>- Here's my win7 domU config file :</div>=
=0A=0A=0A<div><br></div><div><div><font size=3D"1">kernel =3D "/usr/lib/xen=
-4.1/boot/hvmloader"</font></div><div><font size=3D"1">builder=3D'hvm'</fon=
t></div><div><font size=3D"1">memory =3D 3072</font></div>=0A<div><font siz=
e=3D"1">name =3D "w7"</font></div><div><font size=3D"1">vif =3D [ 'type=3Dn=
etfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62']</font></div><div><font s=
ize=3D"1">disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,=
hdb,w']</font></div>=0A=0A=0A<div><font size=3D"1">device_model =3D '/usr/l=
ib/xen-4.1/bin/qemu-dm'</font></div><div><font size=3D"1">boot=3D"dc"</font=
></div><div><font size=3D"1"><br>=0A</font></div><div><font size=3D"1">pci=
=3D['01:00.0','01:00.1']</font></div><div><font size=3D"1">gfx_passthru=3D1=
</font></div><div><font size=3D"1"><br>=0A</font></div><div><font size=3D"1=
">vcpus=3D6</font></div><div><font size=3D"1">acpi=3D1</font></div><div><fo=
nt size=3D"1">sdl=3D0</font></div><div><font size=3D"1">vnc=3D1</font></div=
>=0A<div><font size=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">=
vncpasswd=3D''</font></div><div><font size=3D"1">serial=3D'pty'</font></div=
>=0A<div><font size=3D"1">usbdevice=3D'tablet'</font></div><div><font size=
=3D"1">pae=3D1</font></div><div><font size=3D"1">pci_msitranslate=3D0</font=
></div>=0A<div><font size=3D"1">pci_power_mgmt=3D0</font></div><div><font s=
ize=3D"1">acpi_s3 =3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</fo=
nt></div><div><font size=3D"1">on_poweroff =3D 'destroy'</font></div>=0A<di=
v><font size=3D"1">on_reboot &nbsp; =3D 'restart'</font></div><div><font si=
ze=3D"1">on_crash &nbsp; &nbsp;=3D 'restart'</font></div><div><font size=3D=
"1">xen_platform_pci=3D1</font></div>=0A<div><font size=3D"1">hpet =3D 1</f=
ont></div><div><font size=3D"1">viridian=3D1</font></div><div><font size=3D=
"1">monitor=3D1</font></div><div><font size=3D"1">xen_extended_power_mgmt=
=3D2</font></div>=0A<div><font size=3D"1">hpet=3D1</font></div></div><div><=
br></div><div>What's important here for the Nvidia drivers to work and not =
give a nice nvlddmkm.sys BSOD is:</div><div><div><font size=3D"1">pci_msitr=
anslate=3D0</font></div>=0A=0A=0A<div><font size=3D"1">pci_power_mgmt=3D0</=
font></div></div><div><font size=3D"1"><br></font></div><div>- Windows 7 32=
bits</div><div>- Nvidia drivers 275.33</div><div>- You have to manually run=
 aero speed test or force aero to start by using registry entries for the d=
esktop not to be laggy</div>=0A=0A=0A<div><br></div><div>The windows 7 domU=
 is running fine with no performance decrease noticeable, although i've not=
 yet played intensive gpu video game, i'm still pretty confident they'll ru=
n fine.</div><div><br>=0A=0A=0A</div><div>Anyway. i've still some problems =
i shall report in separate posts :</div><div>- The PCI bus topology isn't p=
reserved, and the gfx card, which is plugged on 01:00 becomes 05:00 on domU=
.</div><div>- I'm passing through an RME Hdsp / hammerfall pci sound card t=
o the domU and while it is working fine on his own, there's a strange inter=
action between it and the GPLPV network driver. When i start playing sound,=
 the network instantly cease working. It starts back as soon as i stop play=
ing audio.</div>=0A=0A=0A<div><br></div><div>That's all folks,</div><div><b=
r></div><div>Cheers,</div><div>Lta</div>=0A</div><br>=0A</div><br></div></d=
iv><div class=3D"yiv2088496790im">_________________________________________=
______<br>Xen-devel mailing list<br><a rel=3D"nofollow" ymailto=3D"mailto:X=
en-devel@lists.xensource.com" target=3D"_blank" href=3D"mailto:Xen-devel@li=
sts.xensource.com">Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow"=
 target=3D"_blank" href=3D"http://lists.xensource.com/xen-devel">http://lis=
ts.xensource.com/xen-devel</a><br>=0A<br><br> </div></div> </div>  </div></=
div></blockquote></div><br>=0A</div><br><br> </div> </div>  </div></body></=
html>
--62747910-497708535-1325937887=:81780--


--===============9215375606536002653==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9215375606536002653==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 12:23:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 12:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjVIH-0005s7-J4; Sat, 07 Jan 2012 12:22:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjVIG-0005s1-Bv
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 12:22:40 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325938952!8178081!1
X-Originating-IP: [77.238.189.192]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 27995 invoked from network); 7 Jan 2012 12:22:32 -0000
Received: from nm16-vm0.bullet.mail.ird.yahoo.com (HELO
	nm16-vm0.bullet.mail.ird.yahoo.com) (77.238.189.192)
	by server-7.tower-174.messagelabs.com with SMTP;
	7 Jan 2012 12:22:32 -0000
Received: from [77.238.189.57] by nm16.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:22:32 -0000
Received: from [212.82.108.236] by tm10.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:22:32 -0000
Received: from [127.0.0.1] by omp1001.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:22:32 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 435729.99720.bm@omp1001.mail.ird.yahoo.com
Received: (qmail 15525 invoked by uid 60001); 7 Jan 2012 12:22:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325938952; bh=MSPHAzXf+nypmh8UhcagxWaProXZxwwOgIHWz7ls50I=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=ZP6cNVu+mRCdLnJG3ulhWa0sTBKmXYgm7bd9PMQFDJEFgdEREohr4ZxcSzmzIF+82BK89D2k37rvOWPwQeM4d7sI0pyFEnfK2peSnGcIPUq+tdk0KPw+45IrZFijhUM9JZcEcnyNBOV129XoNG9uSq/17uCa79r8PrVh5PfPl4g=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=CTkyo+1o/jp2lwbZaCLUfP3k9sOH2eTNrJAeqhb4VjsBX0P0yP1qAJmYc+1uJmAJYW6TPyVaTeFnya7oWR3RhCdu20twBQ3c5G+ToEAKd+gNKaHEMSe/WceZRj01d6m4bCTHiH9og46odL6dJMWtGY5JL3CfG779TiF7Ab2l928=;
X-YMail-OSG: IVmeknUVM1ncKwhntOh.QeSbznXSJBJu5ZcIBVc50dAuCiH
	VpDJSBVF9pMBZoKw6ozqcBc7dT9HLG8H_KVpR3zkrY.SC9msc8Pjo3.fNavb
	eU6ozEKqUFH.Mii7C66w81SSyMjptihK0XLqElj1irq1e3SCH8RaygFPkfJH
	7OXYU8_SBSkWKTO.PFyDcO9hu7RT8_PeGdWA8MUFoi.Gxg28dzHYTcYJkXyC
	T_3YrYnujNvOB3i14QzVJw9PcA5RRp6wIEStgfu6f6ZRXE4b.mzAyVFuwMq6
	etDFARWOror.db.9D_Ze3L0NpbXEbzhF_A4xq7VfIB69b7uoghcjmLNfQMQc
	ZOG3ElFeNrumuBPsqVbuxncPfAdBKbgmHxCOqAWtVEuqf5nddJMB1j90drHK
	j0K4Gt4r7yYgb9hBdK3HMGJNs.7Q038txcYHVTBc.SgCA1GoSvbttiQHXyR9
	Kv3hT7X4qqDY1z1.fsvrpR8cOYVd2WHHDWwNU8TVtk0BBhHyaQaTAX3fnlqU
	ILP.ltY9Tod1lfN2O9jai7idPzFpDufWL_pB4n5klEEacgCKJVB8z.BcMvQ- -
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 07 Jan 2012 12:22:32 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
	<1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
Message-ID: <1325938952.14430.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 12:22:32 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: David TECHER <davidtecher@yahoo.fr>, -+= Lta =+- <lta@akr.fm>
In-Reply-To: <1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Re :  Re : Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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="===============1586077196087965668=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1586077196087965668==
Content-Type: multipart/alternative; boundary="62747910-419219237-1325938952=:14430"

--62747910-419219237-1325938952=:14430
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Ok=0A=0AI think I understand what's wrong now :)=0A=0AInit build=0A=3D=3D=
=3D=3D=3D=3D=0A=0A=0Awget http://bits.xensource.com/oss-xen/release/4.1.2/x=
en-4.1.2.tar.gz=0Atar xzf xen-4.1.2.tar.gz =0Acd xen-4.1.2/=0Acd tools/=0Am=
ake =0Amake clean =0Acd ..=0A=0ADownload patches=0A=0A=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=0A=0Awget -q http://old-list-archives.xen.org/archives/h=
tml/xen-devel/2010-05/txtIj4stRFbPo.txt -O 01_pass-through.patch=0Awget -q =
http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txt06YdYEs=
i3S.txt -O 02_makefile.patch=0Awget -q http://old-list-archives.xen.org/arc=
hives/html/xen-devel/2010-05/txtS2w8cPgsnS.txt -O 03_dsdt.patch=0Awget -q h=
ttp://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txt2am6wEpo=
R5.txt -O 04_hvmloader.patch=0Awget -q http://old-list-archives.xen.org/arc=
hives/html/xen-devel/2010-05/txtiSIyxOHBZ8.txt -O 05_sound-makefile.patch=
=0A=0A=0AModify the first patch=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=0A=0A=0AReplace the path for the good path in the first patch 01_=
pass-through.patch=0A=0Ased -i "s:tools/ioemu-remote/hw/:tools/ioemu-qemu-x=
en/hw/:g" 01_pass-through.patch=0A=0AApply patches=0A=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=0A=0A=0A=0Aroot@mercury:/opt/tmp/xen-4.1.2# for file in $(ls 0*pa=
tch);do echo "######## PATCH =3D $file ############";patch -p0 < $file;done=
=0A######## PATCH =3D 01_pass-through.patch ############=0Apatching file to=
ols/ioemu-qemu-xen/hw/pass-through.c=0AHunk #1 succeeded at 22 with fuzz 2 =
(offset -1843 lines).=0AHunk #2 succeeded at 3312 (offset -55 lines).=0AHun=
k #3 succeeded at 3336 (offset -55 lines).=0AHunk #4 succeeded at 4335 with=
 fuzz 2 (offset -144 lines).=0A######## PATCH =3D 02_makefile.patch #######=
#####=0Apatching file tools/firmware/hvmloader/Makefile=0A######## PATCH =
=3D 03_dsdt.patch ############=0Apatching file tools/firmware/hvmloader/acp=
i/dsdt.asl=0A######## PATCH =3D 04_hvmloader.patch ############=0Apatching =
file tools/firmware/hvmloader/hvmloader.c=0AHunk #1 succeeded at 116 (offse=
t 1 line).=0AHunk #2 succeeded at 221 (offset 1 line).=0AHunk #3 succeeded =
at 789 (offset 60 lines).=0A######## PATCH =3D 05_sound-makefile.patch ####=
########=0Apatching file tools/ioemu-remote/xen-setup=0AHunk #1 FAILED at 1=
6=0A=0AI will go on my tests and will let you know=0A=0AThanks=0A=0ADavid=
=0A=0A=0A=0A________________________________=0A De=A0: David TECHER <davidt=
echer@yahoo.fr>=0A=C0=A0: -+=3D Lta =3D+- <lta@akr.fm> =0ACc=A0: "xen-devel=
@lists.xensource.com" <xen-devel@lists.xensource.com> =0AEnvoy=E9 le : Same=
di 7 Janvier 2012 13h04=0AObjet=A0: [Xen-devel] Re : Re :  Secondary VGA Pa=
ssthrough, nvidia, win7: success report.=0A =0A=0AI tested xen 4.1.2 too.To=
bias patches are the patches I've tested. I am not very lucky.=0A=0A=0ASinc=
e you used Tobias patches as me, my question is - to be more precise - coul=
d you sent Tobias patches that you have modified in order to checking=0AI d=
id not forget something as you. =0A=0A=0AMy idea is that since I already ha=
ve xen 4.2 installed, installing xen 4.1.2 over this , something wrong happ=
ens=0A=0A=0AMy screen stays like a black screen and nothing happens. no "gf=
x message" in the log.=0A=0AWith Xen 4.2 I tried aero desktop too but my do=
mU crashes when=A0 I tried to activate aero.=0A=0A=0A=0A=0A________________=
________________=0A De=A0: -+=3D Lta =3D+- <lta@akr.fm>=0A=C0=A0: David TEC=
HER <davidtecher@yahoo.fr> =0ACc=A0: xen-devel@lists.xensource.com =0AEnvoy=
=E9 le : Samedi 7 Janvier 2012 3h17=0AObjet=A0: Re: Re : [Xen-devel] Second=
ary VGA Passthrough, nvidia, win7: success report.=0A =0A=0AHi,=0A=0A=0AOn =
Fri, Jan 6, 2012 at 11:23 PM, David TECHER <davidtecher@yahoo.fr> wrote:=0A=
=0ACould you tell me what version of Xen? 4.1.0? 4.1.2?=0A=0AAs it is state=
d before this is a 4.1.2 version with debian patches=0A=A0=0A=0A>=0A>By the=
 way could you send your patches attached to a mail so I could try?=0A=0A- =
There's also a link to tobias patche's on the first post.=0A=A0=0A=0A>=0A>T=
est on Xen 4.2 failed (desktop stays to lag...)=0A=0AHave u tried to force =
windows to activate the aero desktop ?=0A=A0=0A=0A>=0A>With installing xen =
4.1.0/4.2.0 over my xen 4.2, domU boot but nothing appears on screen.=0A=0A=
I also followed tobias (same as yours) instructions to dump and build vgabi=
os-pt.bin into xen, did u do it also ?=0A=A0=0A=0A>=0A>Strange.=0A>=0A>=0A>=
=0A>=0A>________________________________=0A> De=A0: -+=3D Lta =3D+- <lta@ak=
r.fm>=0A>=C0=A0: xen-devel@lists.xensource.com =0A>Envoy=E9 le : Vendredi 6=
 Janvier 2012 17h48=0A>Objet=A0: [Xen-devel] Secondary VGA Passthrough, nvi=
dia, win7: success report.=0A>=0A>=0A>=0A>Hello xen-devel,=0A>=0A>=0A>=0A>=
=0A>This is my first post on this list and as such i might be breaking some=
 explicit/implicit rules and i apologize if it's the case. Maybe this list =
isn't the exact=A0right=A0kind of place where to post this kind of stuff, b=
ut i know lots of us are browsing this list as the primary source of docume=
ntation for xen.=0A>=0A>=0A>I've read many times windows 7 isn't the right =
os to run on top of xen. Most of the guy's who are running vga passthru are=
 recommanding to use windows xp, and i've never seen any success report of =
vga passthru on windows 7 so i thought it was important to post mine.=0A>=
=0A>=0A>Anyway, here's my hardware setup :=0A>- Gigabyte GA-990X-UD3=0A>-=
=A0AMD Phenom II X6 1075T Processor=0A>- MSI Cyclone NVIDIA Geforce GTX 460=
=0A>=0A>=0A>On the software side i'm using :=0A>=0A>=0A>- Debian testing as=
 Dom0=0A>- Xen-4.1 (debian version 4.1.2-2) with what's now referred to as =
"Tobias Geiger patches" (http://old-list-archives.xen.org/archives/html/xen=
-devel/2010-05/msg00441.html) (You have to edit the patches, changing the p=
ath to some qemu source files for them to apply)=0A>- debian's kernel =A03.=
1.5, compiled to include the pciback driver. Here's the output of `cat /boo=
t/my3.1.5config | grep -i xen`=0A>CONFIG_XEN=3Dy=0A>CONFIG_XEN_DOM0=3Dy=0A>=
CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A>CONFIG_XEN_PVHVM=3Dy=0A>CONFIG_XEN_MAX_D=
OMAIN_MEMORY=3D128=0A>CONFIG_XEN_SAVE_RESTORE=3Dy=0A># CONFIG_XEN_DEBUG_FS =
is not set=0A># CONFIG_XEN_DEBUG is not set=0A>CONFIG_PCI_XEN=3Dy=0A>CONFIG=
_XEN_PCIDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BL=
KDEV_BACKEND=3Dm=0A>CONFIG_NETXEN_NIC=3Dm=0A>CONFIG_XEN_NETDEV_FRONTEND=3Dm=
=0A>CONFIG_XEN_NETDEV_BACKEND=3Dm=0A>CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy=
=0A>CONFIG_HVC_XEN=3Dy=0A>CONFIG_XEN_WDT=3Dm=0A>CONFIG_XEN_FBDEV_FRONTEND=
=3Dy=0A># Xen driver support=0A>CONFIG_XEN_BALLOON=3Dy=0A># CONFIG_XEN_BALL=
OON_MEMORY_HOTPLUG is not set=0A>CONFIG_XEN_SCRUB_PAGES=3Dy=0A>CONFIG_XEN_D=
EV_EVTCHN=3Dm=0A>CONFIG_XEN_BACKEND=3Dy=0A>CONFIG_XENFS=3Dm=0A>CONFIG_XEN_C=
OMPAT_XENFS=3Dy=0A>CONFIG_XEN_SYS_HYPERVISOR=3Dy=0A>CONFIG_XEN_XENBUS_FRONT=
END=3Dy=0A>CONFIG_XEN_GNTDEV=3Dm=0A>CONFIG_XEN_GRANT_DEV_ALLOC=3Dm=0A>CONFI=
G_XEN_PLATFORM_PCI=3Dm=0A>CONFIG_SWIOTLB_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_BACKE=
ND=3Dy=0A>=0A>=0A>The kernel boot options are 'nomodeset xen-pciback.passth=
rough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'=0A>=0A>=0A>- Here's my win=
7 domU config file :=0A>=0A>=0A>kernel =3D "/usr/lib/xen-4.1/boot/hvmloader=
"=0A>builder=3D'hvm'=0A>memory =3D 3072=0A>name =3D "w7"=0A>vif =3D [ 'type=
=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62']=0A>disk =3D [ 'phy:/=
dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']=0A>device_model =3D=
 '/usr/lib/xen-4.1/bin/qemu-dm'=0A>boot=3D"dc"=0A>=0A>=0A>pci=3D['01:00.0',=
'01:00.1']=0A>gfx_passthru=3D1=0A>=0A>=0A>vcpus=3D6=0A>acpi=3D1=0A>sdl=3D0=
=0A>vnc=3D1=0A>vncconsole=3D1=0A>vncpasswd=3D''=0A>serial=3D'pty'=0A>usbdev=
ice=3D'tablet'=0A>pae=3D1=0A>pci_msitranslate=3D0=0A>pci_power_mgmt=3D0=0A>=
acpi_s3 =3D 1=0A>acpi_s4 =3D 1=0A>on_poweroff =3D 'destroy'=0A>on_reboot =
=A0 =3D 'restart'=0A>on_crash =A0 =A0=3D 'restart'=0A>xen_platform_pci=3D1=
=0A>hpet =3D 1=0A>viridian=3D1=0A>monitor=3D1=0A>xen_extended_power_mgmt=3D=
2=0A>hpet=3D1=0A>=0A>=0A>What's important here for the Nvidia drivers to wo=
rk and not give a nice nvlddmkm.sys BSOD is:=0A>pci_msitranslate=3D0=0A>pci=
_power_mgmt=3D0=0A>=0A>=0A>- Windows 7 32bits=0A>- Nvidia drivers 275.33=0A=
>- You have to manually run aero speed test or force aero to start by using=
 registry entries for the desktop not to be laggy=0A>=0A>=0A>The windows 7 =
domU is running fine with no performance decrease noticeable, although i've=
 not yet played intensive gpu video game, i'm still pretty confident they'l=
l run fine.=0A>=0A>=0A>Anyway. i've still some problems i shall report in s=
eparate posts :=0A>- The PCI bus topology isn't preserved, and the gfx card=
, which is plugged on 01:00 becomes 05:00 on domU.=0A>- I'm passing through=
 an RME Hdsp / hammerfall pci sound card to the domU and while it is workin=
g fine on his own, there's a strange interaction between it and the GPLPV n=
etwork driver. When i start playing sound, the network instantly cease work=
ing. It starts back as soon as i stop playing audio.=0A>=0A>=0A>That's all =
folks,=0A>=0A>=0A>Cheers,=0A>Lta=0A>=0A>=0A>_______________________________=
________________=0A>Xen-devel mailing list=0A>Xen-devel@lists.xensource.com=
=0A>http://lists.xensource.com/xen-devel=0A>=0A>=0A>=0A=0A=0A=0A___________=
____________________________________=0AXen-devel mailing list=0AXen-devel@l=
ists.xensource.com=0Ahttp://lists.xensource.com/xen-devel
--62747910-419219237-1325938952=:14430
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>Ok</span><=
/div><div><br><span></span></div><div><span>I think I understand what's wro=
ng now :)</span></div><div><br><span></span></div><div>Init build</div><div=
>=3D=3D=3D=3D=3D=3D<br></div><div><br><span></span></div><div><span>wget ht=
tp://bits.xensource.com/oss-xen/release/4.1.2/xen-4.1.2.tar.gz<br>tar xzf x=
en-4.1.2.tar.gz <br>cd xen-4.1.2/<br>cd tools/<br>make <br>make clean <br>c=
d ..</span></div><div><span><br></span></div><div><span>Download patches<br=
></span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span>=
</div><div><span>wget -q http://old-list-archives.xen.org/archives/html/xen=
-devel/2010-05/txtIj4stRFbPo.txt -O 01_pass-through.patch<br>wget -q http:/=
/old-list-archives.xen.org/archives/html/xen-devel/2010-05/txt06YdYEsi3S.tx=
t -O 02_makefile.patch<br>wget -q
 http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtS2w8cP=
gsnS.txt -O 03_dsdt.patch<br>wget -q http://old-list-archives.xen.org/archi=
ves/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader.patch<br>wget =
-q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtiSIy=
xOHBZ8.txt -O 05_sound-makefile.patch<br></span></div><div><br><span></span=
></div><div><span>Modify the first patch</span></div><div><span>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></div><div><span><br></sp=
an></div><div><span>Replace the path for the good path in the first patch <=
/span><span>01_pass-through.patch</span></div><div><span><br></span></div><=
div><span>sed -i "s:tools/ioemu-remote/hw/:tools/ioemu-qemu-xen/hw/:g" 01_p=
ass-through.patch</span></div><div><br><span></span></div><div><span>Apply =
patches</span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></d=
iv><div><span><br></span></div><div><span><br></span></div><div><span>root@=
mercury:/opt/tmp/xen-4.1.2# for file in $(ls
 0*patch);do echo "######## PATCH =3D $file ############";patch -p0 &lt; $f=
ile;done<br>######## PATCH =3D 01_pass-through.patch ############<br>patchi=
ng file tools/ioemu-qemu-xen/hw/pass-through.c<br>Hunk #1 succeeded at 22 w=
ith fuzz 2 (offset -1843 lines).<br>Hunk #2 succeeded at 3312 (offset -55 l=
ines).<br>Hunk #3 succeeded at 3336 (offset -55 lines).<br>Hunk #4 succeede=
d at 4335 with fuzz 2 (offset -144 lines).<br>######## PATCH =3D 02_makefil=
e.patch ############<br>patching file tools/firmware/hvmloader/Makefile<br>=
######## PATCH =3D 03_dsdt.patch ############<br>patching file tools/firmwa=
re/hvmloader/acpi/dsdt.asl<br>######## PATCH =3D 04_hvmloader.patch #######=
#####<br>patching file tools/firmware/hvmloader/hvmloader.c<br>Hunk #1 succ=
eeded at 116 (offset 1 line).<br>Hunk #2 succeeded at 221 (offset 1 line).<=
br>Hunk #3 succeeded at 789 (offset 60 lines).<br>######## PATCH =3D 05_sou=
nd-makefile.patch ############<br>patching file
 tools/ioemu-remote/xen-setup<br>Hunk #1 FAILED at 16</span></div><div><br>=
<span></span></div><div><span>I will go on my tests and will let you know</=
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 st=
yle=3D"font-family: times new roman, new york, times, serif; font-size: 12p=
t;"> <div style=3D"font-family: times new roman, new york, times, serif; fo=
nt-size: 12pt;"> <font face=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span=
 style=3D"font-weight:bold;">De&nbsp;:</span></b> David TECHER &lt;davidtec=
her@yahoo.fr&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nbsp;:</span=
></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span style=3D"font-weight:=
 bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xensource.com" &lt;xen-devel@=
lists.xensource.com&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=E9=
 le :</span></b> Samedi 7 Janvier 2012 13h04<br> <b><span style=3D"font-wei=
ght:
 bold;">Objet&nbsp;:</span></b> [Xen-devel] Re : Re :  Secondary VGA Passth=
rough, nvidia, win7: success report.<br> </font> <br><div id=3D"yiv15021245=
83"><div><div style=3D"color:#000;background-color:#fff;font-family:times n=
ew roman, new york, times, serif;font-size:12pt;"><div><span>I tested xen 4=
.1.2 too.</span><span> Tobias patches are the patches I've tested. I am not=
 very lucky.<br></span></div><div><span><br></span></div><div><span>Since y=
ou used Tobias patches as me, my question is - to be more precise - could y=
ou sent Tobias patches that you have modified in order to checking</span></=
div><div><span>I did not forget something as you. <br></span></div><div><br=
><span></span></div><div><span>My idea is that since I already have xen 4.2=
 installed, installing xen 4.1.2 over this , something wrong happens<br></s=
pan></div><div><br><span></span></div><div><span>My screen stays like a bla=
ck screen and nothing happens. no "gfx message" in the
 log.</span></div><div><br><span></span></div><div><span>With Xen 4.2 I tri=
ed aero desktop too but my domU crashes when&nbsp; I tried to activate=0A a=
ero.<br></span></div><div><br><span></span></div><div><span></span></div><d=
iv><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=
, 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> -+=3D Lt=
a =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight:bold;">=C0&nbs=
p;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><span style=
=3D"font-weight:bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensource.com <=
br> <b><span style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Samedi 7 =
Janvier 2012 3h17<br> <b><span style=3D"font-weight:bold;">Objet&nbsp;:</sp=
an></b> Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7: succe=
ss report.<br> </font> <br><div id=3D"yiv1502124583">Hi,<br><br><div class=
=3D"yiv1502124583gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, David TECHER=
 <span dir=3D"ltr">&lt;<a
 rel=3D"nofollow" ymailto=3D"mailto:davidtecher@yahoo.fr" target=3D"_blank"=
 href=3D"mailto:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>&gt;</span> w=
rote:<br><blockquote class=3D"yiv1502124583gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D=
"font-size:12pt;font-family:times new roman, new york, times, serif;"><div>=
<span>Could you tell me what version of Xen? 4.1.0? 4.1.2?</span></div></di=
v></div></blockquote><div><br></div><div>As it is stated before this is a 4=
.1.2 version with debian patches</div>=0A<div>&nbsp;</div><blockquote class=
=3D"yiv1502124583gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex;"><div><div style=3D"font-size:12pt;font-family:t=
imes new roman, new york, times, serif;"><div><br><span></span></div>=0A<di=
v><span>By the way could you send your patches attached to a mail so I coul=
d try?</span></div></div></div></blockquote><div><br></div><div>- There's a=
lso a link to tobias patche's on the first post.</div><div>&nbsp;</div>=0A<=
blockquote class=3D"yiv1502124583gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;"><div><div style=3D"font-size:12=
pt;font-family:times new roman, new york, times, serif;"><div><br><span></s=
pan></div><div><span>Test on Xen 4.2 failed (desktop stays to lag...)</span=
></div>=0A</div></div></blockquote><div><br></div><div>Have u tried to forc=
e windows to activate the aero desktop ?</div><div>&nbsp;</div><blockquote =
class=3D"yiv1502124583gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size:12pt;font-=
family:times new roman, new york, times, serif;"><div><br><span></span></di=
v><div><span>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but=
 nothing appears on screen.</span></div>=0A</div></div></blockquote><div><b=
r></div><div>I also followed tobias (same as yours) instructions to dump an=
d build vgabios-pt.bin into xen, did u do it also ?</div><div>&nbsp;</div><=
blockquote class=3D"yiv1502124583gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size=
:12pt;font-family:times new roman, new york, times, serif;"><div><br><span>=
</span></div><div><span>Strange.<br></span></div><div><br></div>  <div styl=
e=3D"font-family:times new roman, new york, times, serif;font-size:12pt;">=
=0A <div style=3D"font-family:times new roman, new york, times, serif;font-=
size:12pt;"> <font face=3D"Arial"><div class=3D"yiv1502124583im"> <hr size=
=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -+=3D Lt=
a =3D+- &lt;<a rel=3D"nofollow" ymailto=3D"mailto:lta@akr.fm" target=3D"_bl=
ank" href=3D"mailto:lta@akr.fm">lta@akr.fm</a>&gt;<br>=0A </div><b><span st=
yle=3D"font-weight:bold;">=C0&nbsp;:</span></b> <a rel=3D"nofollow" ymailto=
=3D"mailto:xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mailto:=
xen-devel@lists.xensource.com">xen-devel@lists.xensource.com</a> <br> <b><s=
pan style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Vendredi 6 Janvier=
 2012 17h48<br>=0A <b><span style=3D"font-weight:bold;">Objet&nbsp;:</span>=
</b> [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success report.<b=
r> </font><div><div class=3D"yiv1502124583h5"> <br><div><div>Hello xen-deve=
l,<div><br></div><div><br></div><div>=0AThis is my first post on this list =
and as such i might be breaking some explicit/implicit rules and i apologiz=
e if it's the case. Maybe this list isn't the exact&nbsp;right&nbsp;kind of=
 place where to post this kind of stuff, but i know lots of us are browsing=
 this list as the primary source of documentation for xen.</div>=0A=0A=0A<d=
iv><br></div><div>I've read many times windows 7 isn't the right os to run =
on top of xen. Most of the guy's who are running vga passthru are recommand=
ing to use windows xp, and i've never seen any success report of vga passth=
ru on windows 7 so i thought it was important to post mine.</div>=0A=0A=0A<=
div><br></div><div>Anyway, here's my hardware setup :</div><div>- Gigabyte =
GA-990X-UD3</div><div>-&nbsp;AMD Phenom II X6 1075T Processor</div><div>- M=
SI Cyclone NVIDIA Geforce GTX 460</div><div><br></div><div>On the software =
side i'm using :</div>=0A=0A=0A<div><br></div><div>- Debian testing as Dom0=
</div><div>- Xen-4.1 (debian version 4.1.2-2) with what's now referred to a=
s "Tobias Geiger patches" (<a rel=3D"nofollow" target=3D"_blank" href=3D"ht=
tp://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.htm=
l">http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg0044=
1.html</a>) (You have to edit the patches, changing the path to some qemu s=
ource files for them to apply)</div>=0A=0A=0A<div>- debian's kernel &nbsp;3=
.1.5, compiled to include the pciback driver. Here's the output of `cat /bo=
ot/my3.1.5config | grep -i xen`</div><div><div><font size=3D"1">CONFIG_XEN=
=3Dy</font></div><div>=0A<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><=
div><font size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><font size=3D"1">CONFI=
G_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><font size=3D"1">CONFIG_XEN_=
SAVE_RESTORE=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_DEBUG_FS is=
 not set</font></div>=0A<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set=
</font></div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><fon=
t size=3D"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CON=
FIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D"1">CONFIG_NETXEN_=
NIC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm=
</font></div><div><font size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></di=
v><div><font size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>=
=0A<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"=
1">CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FR=
ONTEND=3Dy</font></div>=0A<div><font size=3D"1"># Xen driver support</font>=
</div><div><font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font></div><div><font s=
ize=3D"1"># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set</font></div>=0A<di=
v><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font size=
=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_X=
EN_BACKEND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_XENFS=3Dm</font>=
</div><div><font size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font size=3D"1">CON=
FIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_GRANT_DEV_A=
LLOC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</=
font></div><div><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=0A</div><div><fon=
t size=3D"1"><br></font></div><div>The kernel boot options are 'nomodeset x=
en-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'</div><div=
><br></div><div>- Here's my win7 domU config file :</div>=0A=0A=0A<div><br>=
</div><div><div><font size=3D"1">kernel =3D "/usr/lib/xen-4.1/boot/hvmloade=
r"</font></div><div><font size=3D"1">builder=3D'hvm'</font></div><div><font=
 size=3D"1">memory =3D 3072</font></div>=0A<div><font size=3D"1">name =3D "=
w7"</font></div><div><font size=3D"1">vif =3D [ 'type=3Dnetfront,bridge=3Dx=
enbr0, mac=3D00:16:3e:35:49:62']</font></div><div><font size=3D"1">disk =3D=
 [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']</font></di=
v>=0A=0A=0A<div><font size=3D"1">device_model =3D '/usr/lib/xen-4.1/bin/qem=
u-dm'</font></div><div><font size=3D"1">boot=3D"dc"</font></div><div><font =
size=3D"1"><br>=0A</font></div><div><font size=3D"1">pci=3D['01:00.0','01:0=
0.1']</font></div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><=
font size=3D"1"><br>=0A</font></div><div><font size=3D"1">vcpus=3D6</font><=
/div><div><font size=3D"1">acpi=3D1</font></div><div><font size=3D"1">sdl=
=3D0</font></div><div><font size=3D"1">vnc=3D1</font></div>=0A<div><font si=
ze=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncpasswd=3D''</f=
ont></div><div><font size=3D"1">serial=3D'pty'</font></div>=0A<div><font si=
ze=3D"1">usbdevice=3D'tablet'</font></div><div><font size=3D"1">pae=3D1</fo=
nt></div><div><font size=3D"1">pci_msitranslate=3D0</font></div>=0A<div><fo=
nt size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">acpi_s3 =
=3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><div><fon=
t size=3D"1">on_poweroff =3D 'destroy'</font></div>=0A<div><font size=3D"1"=
>on_reboot &nbsp; =3D 'restart'</font></div><div><font size=3D"1">on_crash =
&nbsp; &nbsp;=3D 'restart'</font></div><div><font size=3D"1">xen_platform_p=
ci=3D1</font></div>=0A<div><font size=3D"1">hpet =3D 1</font></div><div><fo=
nt size=3D"1">viridian=3D1</font></div><div><font size=3D"1">monitor=3D1</f=
ont></div><div><font size=3D"1">xen_extended_power_mgmt=3D2</font></div>=0A=
<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><div>What's=
 important here for the Nvidia drivers to work and not give a nice nvlddmkm=
.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0</font></=
div>=0A=0A=0A<div><font size=3D"1">pci_power_mgmt=3D0</font></div></div><di=
v><font size=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvi=
dia drivers 275.33</div><div>- You have to manually run aero speed test or =
force aero to start by using registry entries for the desktop not to be lag=
gy</div>=0A=0A=0A<div><br></div><div>The windows 7 domU is running fine wit=
h no performance decrease noticeable, although i've not yet played intensiv=
e gpu video game, i'm still pretty confident they'll run fine.</div><div><b=
r>=0A=0A=0A</div><div>Anyway. i've still some problems i shall report in se=
parate posts :</div><div>- The PCI bus topology isn't preserved, and the gf=
x card, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I'm pa=
ssing through an RME Hdsp / hammerfall pci sound card to the domU and while=
 it is working fine on his own, there's a strange interaction between it an=
d the GPLPV network driver. When i start playing sound, the network instant=
ly cease working. It starts back as soon as i stop playing audio.</div>=0A=
=0A=0A<div><br></div><div>That's all folks,</div><div><br></div><div>Cheers=
,</div><div>Lta</div>=0A</div><br>=0A</div><br></div></div><div class=3D"yi=
v1502124583im">_______________________________________________<br>Xen-devel=
 mailing list<br><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.xens=
ource.com" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.com">=
Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://lists.xensource.com/xen-devel">http://lists.xensource.com/xe=
n-devel</a><br>=0A<br><br> </div></div> </div>  </div></div></blockquote></=
div><br>=0A</div><br><br> </div> </div>  </div></div></div><br>____________=
___________________________________<br>Xen-devel mailing list<br><a ymailto=
=3D"mailto:Xen-devel@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xe=
nsource.com">Xen-devel@lists.xensource.com</a><br><a href=3D"http://lists.x=
ensource.com/xen-devel" target=3D"_blank">http://lists.xensource.com/xen-de=
vel</a><br><br><br> </div> </div>  </div></body></html>
--62747910-419219237-1325938952=:14430--


--===============1586077196087965668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1586077196087965668==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 12:23:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 12:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjVIH-0005s7-J4; Sat, 07 Jan 2012 12:22:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjVIG-0005s1-Bv
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 12:22:40 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-7.tower-174.messagelabs.com!1325938952!8178081!1
X-Originating-IP: [77.238.189.192]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 27995 invoked from network); 7 Jan 2012 12:22:32 -0000
Received: from nm16-vm0.bullet.mail.ird.yahoo.com (HELO
	nm16-vm0.bullet.mail.ird.yahoo.com) (77.238.189.192)
	by server-7.tower-174.messagelabs.com with SMTP;
	7 Jan 2012 12:22:32 -0000
Received: from [77.238.189.57] by nm16.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:22:32 -0000
Received: from [212.82.108.236] by tm10.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:22:32 -0000
Received: from [127.0.0.1] by omp1001.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 12:22:32 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 435729.99720.bm@omp1001.mail.ird.yahoo.com
Received: (qmail 15525 invoked by uid 60001); 7 Jan 2012 12:22:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325938952; bh=MSPHAzXf+nypmh8UhcagxWaProXZxwwOgIHWz7ls50I=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=ZP6cNVu+mRCdLnJG3ulhWa0sTBKmXYgm7bd9PMQFDJEFgdEREohr4ZxcSzmzIF+82BK89D2k37rvOWPwQeM4d7sI0pyFEnfK2peSnGcIPUq+tdk0KPw+45IrZFijhUM9JZcEcnyNBOV129XoNG9uSq/17uCa79r8PrVh5PfPl4g=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=CTkyo+1o/jp2lwbZaCLUfP3k9sOH2eTNrJAeqhb4VjsBX0P0yP1qAJmYc+1uJmAJYW6TPyVaTeFnya7oWR3RhCdu20twBQ3c5G+ToEAKd+gNKaHEMSe/WceZRj01d6m4bCTHiH9og46odL6dJMWtGY5JL3CfG779TiF7Ab2l928=;
X-YMail-OSG: IVmeknUVM1ncKwhntOh.QeSbznXSJBJu5ZcIBVc50dAuCiH
	VpDJSBVF9pMBZoKw6ozqcBc7dT9HLG8H_KVpR3zkrY.SC9msc8Pjo3.fNavb
	eU6ozEKqUFH.Mii7C66w81SSyMjptihK0XLqElj1irq1e3SCH8RaygFPkfJH
	7OXYU8_SBSkWKTO.PFyDcO9hu7RT8_PeGdWA8MUFoi.Gxg28dzHYTcYJkXyC
	T_3YrYnujNvOB3i14QzVJw9PcA5RRp6wIEStgfu6f6ZRXE4b.mzAyVFuwMq6
	etDFARWOror.db.9D_Ze3L0NpbXEbzhF_A4xq7VfIB69b7uoghcjmLNfQMQc
	ZOG3ElFeNrumuBPsqVbuxncPfAdBKbgmHxCOqAWtVEuqf5nddJMB1j90drHK
	j0K4Gt4r7yYgb9hBdK3HMGJNs.7Q038txcYHVTBc.SgCA1GoSvbttiQHXyR9
	Kv3hT7X4qqDY1z1.fsvrpR8cOYVd2WHHDWwNU8TVtk0BBhHyaQaTAX3fnlqU
	ILP.ltY9Tod1lfN2O9jai7idPzFpDufWL_pB4n5klEEacgCKJVB8z.BcMvQ- -
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 07 Jan 2012 12:22:32 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
	<1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
Message-ID: <1325938952.14430.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 12:22:32 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: David TECHER <davidtecher@yahoo.fr>, -+= Lta =+- <lta@akr.fm>
In-Reply-To: <1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Re :  Re : Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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="===============1586077196087965668=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1586077196087965668==
Content-Type: multipart/alternative; boundary="62747910-419219237-1325938952=:14430"

--62747910-419219237-1325938952=:14430
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Ok=0A=0AI think I understand what's wrong now :)=0A=0AInit build=0A=3D=3D=
=3D=3D=3D=3D=0A=0A=0Awget http://bits.xensource.com/oss-xen/release/4.1.2/x=
en-4.1.2.tar.gz=0Atar xzf xen-4.1.2.tar.gz =0Acd xen-4.1.2/=0Acd tools/=0Am=
ake =0Amake clean =0Acd ..=0A=0ADownload patches=0A=0A=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=0A=0Awget -q http://old-list-archives.xen.org/archives/h=
tml/xen-devel/2010-05/txtIj4stRFbPo.txt -O 01_pass-through.patch=0Awget -q =
http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txt06YdYEs=
i3S.txt -O 02_makefile.patch=0Awget -q http://old-list-archives.xen.org/arc=
hives/html/xen-devel/2010-05/txtS2w8cPgsnS.txt -O 03_dsdt.patch=0Awget -q h=
ttp://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txt2am6wEpo=
R5.txt -O 04_hvmloader.patch=0Awget -q http://old-list-archives.xen.org/arc=
hives/html/xen-devel/2010-05/txtiSIyxOHBZ8.txt -O 05_sound-makefile.patch=
=0A=0A=0AModify the first patch=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=0A=0A=0AReplace the path for the good path in the first patch 01_=
pass-through.patch=0A=0Ased -i "s:tools/ioemu-remote/hw/:tools/ioemu-qemu-x=
en/hw/:g" 01_pass-through.patch=0A=0AApply patches=0A=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=0A=0A=0A=0Aroot@mercury:/opt/tmp/xen-4.1.2# for file in $(ls 0*pa=
tch);do echo "######## PATCH =3D $file ############";patch -p0 < $file;done=
=0A######## PATCH =3D 01_pass-through.patch ############=0Apatching file to=
ols/ioemu-qemu-xen/hw/pass-through.c=0AHunk #1 succeeded at 22 with fuzz 2 =
(offset -1843 lines).=0AHunk #2 succeeded at 3312 (offset -55 lines).=0AHun=
k #3 succeeded at 3336 (offset -55 lines).=0AHunk #4 succeeded at 4335 with=
 fuzz 2 (offset -144 lines).=0A######## PATCH =3D 02_makefile.patch #######=
#####=0Apatching file tools/firmware/hvmloader/Makefile=0A######## PATCH =
=3D 03_dsdt.patch ############=0Apatching file tools/firmware/hvmloader/acp=
i/dsdt.asl=0A######## PATCH =3D 04_hvmloader.patch ############=0Apatching =
file tools/firmware/hvmloader/hvmloader.c=0AHunk #1 succeeded at 116 (offse=
t 1 line).=0AHunk #2 succeeded at 221 (offset 1 line).=0AHunk #3 succeeded =
at 789 (offset 60 lines).=0A######## PATCH =3D 05_sound-makefile.patch ####=
########=0Apatching file tools/ioemu-remote/xen-setup=0AHunk #1 FAILED at 1=
6=0A=0AI will go on my tests and will let you know=0A=0AThanks=0A=0ADavid=
=0A=0A=0A=0A________________________________=0A De=A0: David TECHER <davidt=
echer@yahoo.fr>=0A=C0=A0: -+=3D Lta =3D+- <lta@akr.fm> =0ACc=A0: "xen-devel=
@lists.xensource.com" <xen-devel@lists.xensource.com> =0AEnvoy=E9 le : Same=
di 7 Janvier 2012 13h04=0AObjet=A0: [Xen-devel] Re : Re :  Secondary VGA Pa=
ssthrough, nvidia, win7: success report.=0A =0A=0AI tested xen 4.1.2 too.To=
bias patches are the patches I've tested. I am not very lucky.=0A=0A=0ASinc=
e you used Tobias patches as me, my question is - to be more precise - coul=
d you sent Tobias patches that you have modified in order to checking=0AI d=
id not forget something as you. =0A=0A=0AMy idea is that since I already ha=
ve xen 4.2 installed, installing xen 4.1.2 over this , something wrong happ=
ens=0A=0A=0AMy screen stays like a black screen and nothing happens. no "gf=
x message" in the log.=0A=0AWith Xen 4.2 I tried aero desktop too but my do=
mU crashes when=A0 I tried to activate aero.=0A=0A=0A=0A=0A________________=
________________=0A De=A0: -+=3D Lta =3D+- <lta@akr.fm>=0A=C0=A0: David TEC=
HER <davidtecher@yahoo.fr> =0ACc=A0: xen-devel@lists.xensource.com =0AEnvoy=
=E9 le : Samedi 7 Janvier 2012 3h17=0AObjet=A0: Re: Re : [Xen-devel] Second=
ary VGA Passthrough, nvidia, win7: success report.=0A =0A=0AHi,=0A=0A=0AOn =
Fri, Jan 6, 2012 at 11:23 PM, David TECHER <davidtecher@yahoo.fr> wrote:=0A=
=0ACould you tell me what version of Xen? 4.1.0? 4.1.2?=0A=0AAs it is state=
d before this is a 4.1.2 version with debian patches=0A=A0=0A=0A>=0A>By the=
 way could you send your patches attached to a mail so I could try?=0A=0A- =
There's also a link to tobias patche's on the first post.=0A=A0=0A=0A>=0A>T=
est on Xen 4.2 failed (desktop stays to lag...)=0A=0AHave u tried to force =
windows to activate the aero desktop ?=0A=A0=0A=0A>=0A>With installing xen =
4.1.0/4.2.0 over my xen 4.2, domU boot but nothing appears on screen.=0A=0A=
I also followed tobias (same as yours) instructions to dump and build vgabi=
os-pt.bin into xen, did u do it also ?=0A=A0=0A=0A>=0A>Strange.=0A>=0A>=0A>=
=0A>=0A>________________________________=0A> De=A0: -+=3D Lta =3D+- <lta@ak=
r.fm>=0A>=C0=A0: xen-devel@lists.xensource.com =0A>Envoy=E9 le : Vendredi 6=
 Janvier 2012 17h48=0A>Objet=A0: [Xen-devel] Secondary VGA Passthrough, nvi=
dia, win7: success report.=0A>=0A>=0A>=0A>Hello xen-devel,=0A>=0A>=0A>=0A>=
=0A>This is my first post on this list and as such i might be breaking some=
 explicit/implicit rules and i apologize if it's the case. Maybe this list =
isn't the exact=A0right=A0kind of place where to post this kind of stuff, b=
ut i know lots of us are browsing this list as the primary source of docume=
ntation for xen.=0A>=0A>=0A>I've read many times windows 7 isn't the right =
os to run on top of xen. Most of the guy's who are running vga passthru are=
 recommanding to use windows xp, and i've never seen any success report of =
vga passthru on windows 7 so i thought it was important to post mine.=0A>=
=0A>=0A>Anyway, here's my hardware setup :=0A>- Gigabyte GA-990X-UD3=0A>-=
=A0AMD Phenom II X6 1075T Processor=0A>- MSI Cyclone NVIDIA Geforce GTX 460=
=0A>=0A>=0A>On the software side i'm using :=0A>=0A>=0A>- Debian testing as=
 Dom0=0A>- Xen-4.1 (debian version 4.1.2-2) with what's now referred to as =
"Tobias Geiger patches" (http://old-list-archives.xen.org/archives/html/xen=
-devel/2010-05/msg00441.html) (You have to edit the patches, changing the p=
ath to some qemu source files for them to apply)=0A>- debian's kernel =A03.=
1.5, compiled to include the pciback driver. Here's the output of `cat /boo=
t/my3.1.5config | grep -i xen`=0A>CONFIG_XEN=3Dy=0A>CONFIG_XEN_DOM0=3Dy=0A>=
CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A>CONFIG_XEN_PVHVM=3Dy=0A>CONFIG_XEN_MAX_D=
OMAIN_MEMORY=3D128=0A>CONFIG_XEN_SAVE_RESTORE=3Dy=0A># CONFIG_XEN_DEBUG_FS =
is not set=0A># CONFIG_XEN_DEBUG is not set=0A>CONFIG_PCI_XEN=3Dy=0A>CONFIG=
_XEN_PCIDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BL=
KDEV_BACKEND=3Dm=0A>CONFIG_NETXEN_NIC=3Dm=0A>CONFIG_XEN_NETDEV_FRONTEND=3Dm=
=0A>CONFIG_XEN_NETDEV_BACKEND=3Dm=0A>CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy=
=0A>CONFIG_HVC_XEN=3Dy=0A>CONFIG_XEN_WDT=3Dm=0A>CONFIG_XEN_FBDEV_FRONTEND=
=3Dy=0A># Xen driver support=0A>CONFIG_XEN_BALLOON=3Dy=0A># CONFIG_XEN_BALL=
OON_MEMORY_HOTPLUG is not set=0A>CONFIG_XEN_SCRUB_PAGES=3Dy=0A>CONFIG_XEN_D=
EV_EVTCHN=3Dm=0A>CONFIG_XEN_BACKEND=3Dy=0A>CONFIG_XENFS=3Dm=0A>CONFIG_XEN_C=
OMPAT_XENFS=3Dy=0A>CONFIG_XEN_SYS_HYPERVISOR=3Dy=0A>CONFIG_XEN_XENBUS_FRONT=
END=3Dy=0A>CONFIG_XEN_GNTDEV=3Dm=0A>CONFIG_XEN_GRANT_DEV_ALLOC=3Dm=0A>CONFI=
G_XEN_PLATFORM_PCI=3Dm=0A>CONFIG_SWIOTLB_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_BACKE=
ND=3Dy=0A>=0A>=0A>The kernel boot options are 'nomodeset xen-pciback.passth=
rough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'=0A>=0A>=0A>- Here's my win=
7 domU config file :=0A>=0A>=0A>kernel =3D "/usr/lib/xen-4.1/boot/hvmloader=
"=0A>builder=3D'hvm'=0A>memory =3D 3072=0A>name =3D "w7"=0A>vif =3D [ 'type=
=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:35:49:62']=0A>disk =3D [ 'phy:/=
dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']=0A>device_model =3D=
 '/usr/lib/xen-4.1/bin/qemu-dm'=0A>boot=3D"dc"=0A>=0A>=0A>pci=3D['01:00.0',=
'01:00.1']=0A>gfx_passthru=3D1=0A>=0A>=0A>vcpus=3D6=0A>acpi=3D1=0A>sdl=3D0=
=0A>vnc=3D1=0A>vncconsole=3D1=0A>vncpasswd=3D''=0A>serial=3D'pty'=0A>usbdev=
ice=3D'tablet'=0A>pae=3D1=0A>pci_msitranslate=3D0=0A>pci_power_mgmt=3D0=0A>=
acpi_s3 =3D 1=0A>acpi_s4 =3D 1=0A>on_poweroff =3D 'destroy'=0A>on_reboot =
=A0 =3D 'restart'=0A>on_crash =A0 =A0=3D 'restart'=0A>xen_platform_pci=3D1=
=0A>hpet =3D 1=0A>viridian=3D1=0A>monitor=3D1=0A>xen_extended_power_mgmt=3D=
2=0A>hpet=3D1=0A>=0A>=0A>What's important here for the Nvidia drivers to wo=
rk and not give a nice nvlddmkm.sys BSOD is:=0A>pci_msitranslate=3D0=0A>pci=
_power_mgmt=3D0=0A>=0A>=0A>- Windows 7 32bits=0A>- Nvidia drivers 275.33=0A=
>- You have to manually run aero speed test or force aero to start by using=
 registry entries for the desktop not to be laggy=0A>=0A>=0A>The windows 7 =
domU is running fine with no performance decrease noticeable, although i've=
 not yet played intensive gpu video game, i'm still pretty confident they'l=
l run fine.=0A>=0A>=0A>Anyway. i've still some problems i shall report in s=
eparate posts :=0A>- The PCI bus topology isn't preserved, and the gfx card=
, which is plugged on 01:00 becomes 05:00 on domU.=0A>- I'm passing through=
 an RME Hdsp / hammerfall pci sound card to the domU and while it is workin=
g fine on his own, there's a strange interaction between it and the GPLPV n=
etwork driver. When i start playing sound, the network instantly cease work=
ing. It starts back as soon as i stop playing audio.=0A>=0A>=0A>That's all =
folks,=0A>=0A>=0A>Cheers,=0A>Lta=0A>=0A>=0A>_______________________________=
________________=0A>Xen-devel mailing list=0A>Xen-devel@lists.xensource.com=
=0A>http://lists.xensource.com/xen-devel=0A>=0A>=0A>=0A=0A=0A=0A___________=
____________________________________=0AXen-devel mailing list=0AXen-devel@l=
ists.xensource.com=0Ahttp://lists.xensource.com/xen-devel
--62747910-419219237-1325938952=:14430
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>Ok</span><=
/div><div><br><span></span></div><div><span>I think I understand what's wro=
ng now :)</span></div><div><br><span></span></div><div>Init build</div><div=
>=3D=3D=3D=3D=3D=3D<br></div><div><br><span></span></div><div><span>wget ht=
tp://bits.xensource.com/oss-xen/release/4.1.2/xen-4.1.2.tar.gz<br>tar xzf x=
en-4.1.2.tar.gz <br>cd xen-4.1.2/<br>cd tools/<br>make <br>make clean <br>c=
d ..</span></div><div><span><br></span></div><div><span>Download patches<br=
></span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span>=
</div><div><span>wget -q http://old-list-archives.xen.org/archives/html/xen=
-devel/2010-05/txtIj4stRFbPo.txt -O 01_pass-through.patch<br>wget -q http:/=
/old-list-archives.xen.org/archives/html/xen-devel/2010-05/txt06YdYEsi3S.tx=
t -O 02_makefile.patch<br>wget -q
 http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtS2w8cP=
gsnS.txt -O 03_dsdt.patch<br>wget -q http://old-list-archives.xen.org/archi=
ves/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader.patch<br>wget =
-q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtiSIy=
xOHBZ8.txt -O 05_sound-makefile.patch<br></span></div><div><br><span></span=
></div><div><span>Modify the first patch</span></div><div><span>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></div><div><span><br></sp=
an></div><div><span>Replace the path for the good path in the first patch <=
/span><span>01_pass-through.patch</span></div><div><span><br></span></div><=
div><span>sed -i "s:tools/ioemu-remote/hw/:tools/ioemu-qemu-xen/hw/:g" 01_p=
ass-through.patch</span></div><div><br><span></span></div><div><span>Apply =
patches</span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></d=
iv><div><span><br></span></div><div><span><br></span></div><div><span>root@=
mercury:/opt/tmp/xen-4.1.2# for file in $(ls
 0*patch);do echo "######## PATCH =3D $file ############";patch -p0 &lt; $f=
ile;done<br>######## PATCH =3D 01_pass-through.patch ############<br>patchi=
ng file tools/ioemu-qemu-xen/hw/pass-through.c<br>Hunk #1 succeeded at 22 w=
ith fuzz 2 (offset -1843 lines).<br>Hunk #2 succeeded at 3312 (offset -55 l=
ines).<br>Hunk #3 succeeded at 3336 (offset -55 lines).<br>Hunk #4 succeede=
d at 4335 with fuzz 2 (offset -144 lines).<br>######## PATCH =3D 02_makefil=
e.patch ############<br>patching file tools/firmware/hvmloader/Makefile<br>=
######## PATCH =3D 03_dsdt.patch ############<br>patching file tools/firmwa=
re/hvmloader/acpi/dsdt.asl<br>######## PATCH =3D 04_hvmloader.patch #######=
#####<br>patching file tools/firmware/hvmloader/hvmloader.c<br>Hunk #1 succ=
eeded at 116 (offset 1 line).<br>Hunk #2 succeeded at 221 (offset 1 line).<=
br>Hunk #3 succeeded at 789 (offset 60 lines).<br>######## PATCH =3D 05_sou=
nd-makefile.patch ############<br>patching file
 tools/ioemu-remote/xen-setup<br>Hunk #1 FAILED at 16</span></div><div><br>=
<span></span></div><div><span>I will go on my tests and will let you know</=
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 st=
yle=3D"font-family: times new roman, new york, times, serif; font-size: 12p=
t;"> <div style=3D"font-family: times new roman, new york, times, serif; fo=
nt-size: 12pt;"> <font face=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span=
 style=3D"font-weight:bold;">De&nbsp;:</span></b> David TECHER &lt;davidtec=
her@yahoo.fr&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nbsp;:</span=
></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span style=3D"font-weight:=
 bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xensource.com" &lt;xen-devel@=
lists.xensource.com&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=E9=
 le :</span></b> Samedi 7 Janvier 2012 13h04<br> <b><span style=3D"font-wei=
ght:
 bold;">Objet&nbsp;:</span></b> [Xen-devel] Re : Re :  Secondary VGA Passth=
rough, nvidia, win7: success report.<br> </font> <br><div id=3D"yiv15021245=
83"><div><div style=3D"color:#000;background-color:#fff;font-family:times n=
ew roman, new york, times, serif;font-size:12pt;"><div><span>I tested xen 4=
.1.2 too.</span><span> Tobias patches are the patches I've tested. I am not=
 very lucky.<br></span></div><div><span><br></span></div><div><span>Since y=
ou used Tobias patches as me, my question is - to be more precise - could y=
ou sent Tobias patches that you have modified in order to checking</span></=
div><div><span>I did not forget something as you. <br></span></div><div><br=
><span></span></div><div><span>My idea is that since I already have xen 4.2=
 installed, installing xen 4.1.2 over this , something wrong happens<br></s=
pan></div><div><br><span></span></div><div><span>My screen stays like a bla=
ck screen and nothing happens. no "gfx message" in the
 log.</span></div><div><br><span></span></div><div><span>With Xen 4.2 I tri=
ed aero desktop too but my domU crashes when&nbsp; I tried to activate=0A a=
ero.<br></span></div><div><br><span></span></div><div><span></span></div><d=
iv><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=
, 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> -+=3D Lt=
a =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight:bold;">=C0&nbs=
p;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><span style=
=3D"font-weight:bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensource.com <=
br> <b><span style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Samedi 7 =
Janvier 2012 3h17<br> <b><span style=3D"font-weight:bold;">Objet&nbsp;:</sp=
an></b> Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7: succe=
ss report.<br> </font> <br><div id=3D"yiv1502124583">Hi,<br><br><div class=
=3D"yiv1502124583gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, David TECHER=
 <span dir=3D"ltr">&lt;<a
 rel=3D"nofollow" ymailto=3D"mailto:davidtecher@yahoo.fr" target=3D"_blank"=
 href=3D"mailto:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>&gt;</span> w=
rote:<br><blockquote class=3D"yiv1502124583gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D=
"font-size:12pt;font-family:times new roman, new york, times, serif;"><div>=
<span>Could you tell me what version of Xen? 4.1.0? 4.1.2?</span></div></di=
v></div></blockquote><div><br></div><div>As it is stated before this is a 4=
.1.2 version with debian patches</div>=0A<div>&nbsp;</div><blockquote class=
=3D"yiv1502124583gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex;"><div><div style=3D"font-size:12pt;font-family:t=
imes new roman, new york, times, serif;"><div><br><span></span></div>=0A<di=
v><span>By the way could you send your patches attached to a mail so I coul=
d try?</span></div></div></div></blockquote><div><br></div><div>- There's a=
lso a link to tobias patche's on the first post.</div><div>&nbsp;</div>=0A<=
blockquote class=3D"yiv1502124583gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;"><div><div style=3D"font-size:12=
pt;font-family:times new roman, new york, times, serif;"><div><br><span></s=
pan></div><div><span>Test on Xen 4.2 failed (desktop stays to lag...)</span=
></div>=0A</div></div></blockquote><div><br></div><div>Have u tried to forc=
e windows to activate the aero desktop ?</div><div>&nbsp;</div><blockquote =
class=3D"yiv1502124583gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size:12pt;font-=
family:times new roman, new york, times, serif;"><div><br><span></span></di=
v><div><span>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but=
 nothing appears on screen.</span></div>=0A</div></div></blockquote><div><b=
r></div><div>I also followed tobias (same as yours) instructions to dump an=
d build vgabios-pt.bin into xen, did u do it also ?</div><div>&nbsp;</div><=
blockquote class=3D"yiv1502124583gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size=
:12pt;font-family:times new roman, new york, times, serif;"><div><br><span>=
</span></div><div><span>Strange.<br></span></div><div><br></div>  <div styl=
e=3D"font-family:times new roman, new york, times, serif;font-size:12pt;">=
=0A <div style=3D"font-family:times new roman, new york, times, serif;font-=
size:12pt;"> <font face=3D"Arial"><div class=3D"yiv1502124583im"> <hr size=
=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -+=3D Lt=
a =3D+- &lt;<a rel=3D"nofollow" ymailto=3D"mailto:lta@akr.fm" target=3D"_bl=
ank" href=3D"mailto:lta@akr.fm">lta@akr.fm</a>&gt;<br>=0A </div><b><span st=
yle=3D"font-weight:bold;">=C0&nbsp;:</span></b> <a rel=3D"nofollow" ymailto=
=3D"mailto:xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mailto:=
xen-devel@lists.xensource.com">xen-devel@lists.xensource.com</a> <br> <b><s=
pan style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Vendredi 6 Janvier=
 2012 17h48<br>=0A <b><span style=3D"font-weight:bold;">Objet&nbsp;:</span>=
</b> [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success report.<b=
r> </font><div><div class=3D"yiv1502124583h5"> <br><div><div>Hello xen-deve=
l,<div><br></div><div><br></div><div>=0AThis is my first post on this list =
and as such i might be breaking some explicit/implicit rules and i apologiz=
e if it's the case. Maybe this list isn't the exact&nbsp;right&nbsp;kind of=
 place where to post this kind of stuff, but i know lots of us are browsing=
 this list as the primary source of documentation for xen.</div>=0A=0A=0A<d=
iv><br></div><div>I've read many times windows 7 isn't the right os to run =
on top of xen. Most of the guy's who are running vga passthru are recommand=
ing to use windows xp, and i've never seen any success report of vga passth=
ru on windows 7 so i thought it was important to post mine.</div>=0A=0A=0A<=
div><br></div><div>Anyway, here's my hardware setup :</div><div>- Gigabyte =
GA-990X-UD3</div><div>-&nbsp;AMD Phenom II X6 1075T Processor</div><div>- M=
SI Cyclone NVIDIA Geforce GTX 460</div><div><br></div><div>On the software =
side i'm using :</div>=0A=0A=0A<div><br></div><div>- Debian testing as Dom0=
</div><div>- Xen-4.1 (debian version 4.1.2-2) with what's now referred to a=
s "Tobias Geiger patches" (<a rel=3D"nofollow" target=3D"_blank" href=3D"ht=
tp://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.htm=
l">http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg0044=
1.html</a>) (You have to edit the patches, changing the path to some qemu s=
ource files for them to apply)</div>=0A=0A=0A<div>- debian's kernel &nbsp;3=
.1.5, compiled to include the pciback driver. Here's the output of `cat /bo=
ot/my3.1.5config | grep -i xen`</div><div><div><font size=3D"1">CONFIG_XEN=
=3Dy</font></div><div>=0A<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><=
div><font size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><font size=3D"1">CONFI=
G_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><font size=3D"1">CONFIG_XEN_=
SAVE_RESTORE=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_DEBUG_FS is=
 not set</font></div>=0A<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set=
</font></div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><fon=
t size=3D"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CON=
FIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D"1">CONFIG_NETXEN_=
NIC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm=
</font></div><div><font size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></di=
v><div><font size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>=
=0A<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"=
1">CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FR=
ONTEND=3Dy</font></div>=0A<div><font size=3D"1"># Xen driver support</font>=
</div><div><font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font></div><div><font s=
ize=3D"1"># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set</font></div>=0A<di=
v><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font size=
=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_X=
EN_BACKEND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_XENFS=3Dm</font>=
</div><div><font size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font size=3D"1">CON=
FIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_GRANT_DEV_A=
LLOC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</=
font></div><div><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=0A</div><div><fon=
t size=3D"1"><br></font></div><div>The kernel boot options are 'nomodeset x=
en-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'</div><div=
><br></div><div>- Here's my win7 domU config file :</div>=0A=0A=0A<div><br>=
</div><div><div><font size=3D"1">kernel =3D "/usr/lib/xen-4.1/boot/hvmloade=
r"</font></div><div><font size=3D"1">builder=3D'hvm'</font></div><div><font=
 size=3D"1">memory =3D 3072</font></div>=0A<div><font size=3D"1">name =3D "=
w7"</font></div><div><font size=3D"1">vif =3D [ 'type=3Dnetfront,bridge=3Dx=
enbr0, mac=3D00:16:3e:35:49:62']</font></div><div><font size=3D"1">disk =3D=
 [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']</font></di=
v>=0A=0A=0A<div><font size=3D"1">device_model =3D '/usr/lib/xen-4.1/bin/qem=
u-dm'</font></div><div><font size=3D"1">boot=3D"dc"</font></div><div><font =
size=3D"1"><br>=0A</font></div><div><font size=3D"1">pci=3D['01:00.0','01:0=
0.1']</font></div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><=
font size=3D"1"><br>=0A</font></div><div><font size=3D"1">vcpus=3D6</font><=
/div><div><font size=3D"1">acpi=3D1</font></div><div><font size=3D"1">sdl=
=3D0</font></div><div><font size=3D"1">vnc=3D1</font></div>=0A<div><font si=
ze=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncpasswd=3D''</f=
ont></div><div><font size=3D"1">serial=3D'pty'</font></div>=0A<div><font si=
ze=3D"1">usbdevice=3D'tablet'</font></div><div><font size=3D"1">pae=3D1</fo=
nt></div><div><font size=3D"1">pci_msitranslate=3D0</font></div>=0A<div><fo=
nt size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">acpi_s3 =
=3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><div><fon=
t size=3D"1">on_poweroff =3D 'destroy'</font></div>=0A<div><font size=3D"1"=
>on_reboot &nbsp; =3D 'restart'</font></div><div><font size=3D"1">on_crash =
&nbsp; &nbsp;=3D 'restart'</font></div><div><font size=3D"1">xen_platform_p=
ci=3D1</font></div>=0A<div><font size=3D"1">hpet =3D 1</font></div><div><fo=
nt size=3D"1">viridian=3D1</font></div><div><font size=3D"1">monitor=3D1</f=
ont></div><div><font size=3D"1">xen_extended_power_mgmt=3D2</font></div>=0A=
<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><div>What's=
 important here for the Nvidia drivers to work and not give a nice nvlddmkm=
.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0</font></=
div>=0A=0A=0A<div><font size=3D"1">pci_power_mgmt=3D0</font></div></div><di=
v><font size=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvi=
dia drivers 275.33</div><div>- You have to manually run aero speed test or =
force aero to start by using registry entries for the desktop not to be lag=
gy</div>=0A=0A=0A<div><br></div><div>The windows 7 domU is running fine wit=
h no performance decrease noticeable, although i've not yet played intensiv=
e gpu video game, i'm still pretty confident they'll run fine.</div><div><b=
r>=0A=0A=0A</div><div>Anyway. i've still some problems i shall report in se=
parate posts :</div><div>- The PCI bus topology isn't preserved, and the gf=
x card, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I'm pa=
ssing through an RME Hdsp / hammerfall pci sound card to the domU and while=
 it is working fine on his own, there's a strange interaction between it an=
d the GPLPV network driver. When i start playing sound, the network instant=
ly cease working. It starts back as soon as i stop playing audio.</div>=0A=
=0A=0A<div><br></div><div>That's all folks,</div><div><br></div><div>Cheers=
,</div><div>Lta</div>=0A</div><br>=0A</div><br></div></div><div class=3D"yi=
v1502124583im">_______________________________________________<br>Xen-devel=
 mailing list<br><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.xens=
ource.com" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.com">=
Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://lists.xensource.com/xen-devel">http://lists.xensource.com/xe=
n-devel</a><br>=0A<br><br> </div></div> </div>  </div></div></blockquote></=
div><br>=0A</div><br><br> </div> </div>  </div></div></div><br>____________=
___________________________________<br>Xen-devel mailing list<br><a ymailto=
=3D"mailto:Xen-devel@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xe=
nsource.com">Xen-devel@lists.xensource.com</a><br><a href=3D"http://lists.x=
ensource.com/xen-devel" target=3D"_blank">http://lists.xensource.com/xen-de=
vel</a><br><br><br> </div> </div>  </div></body></html>
--62747910-419219237-1325938952=:14430--


--===============1586077196087965668==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1586077196087965668==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 14:06:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 14: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 1RjWth-0006RG-By; Sat, 07 Jan 2012 14:05:25 +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 1RjWtg-0006RB-03
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 14:05:24 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325945117!10503285!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDAwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26664 invoked from network); 7 Jan 2012 14:05:17 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jan 2012 14:05:17 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id D59E825DB;
	Sat,  7 Jan 2012 16:05:15 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3AB5720058; Sat,  7 Jan 2012 16:05:15 +0200 (EET)
Date: Sat, 7 Jan 2012 16:05:15 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120107140514.GC12984@reaktio.net>
References: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] usbback for linux 3.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 Sat, Jan 07, 2012 at 02:28:24AM +0000, James Harper wrote:
> Is anyone maintaining usbback that compiles against Linux 3.1?
> 

I think Konrad tried to forward-port the 2.6.32 pvops pvusb patch to 3.x,
but it didn't work (compile?) out-of-the-box.

pvusb patch for 2.6.32 pvops is here:
http://members.iinet.net.au/~nathanael/pvusb.diff
(http://lists.xensource.com/archives/html/xen-devel/2011-01/msg00354.html)

Maybe try it and see if it's trivial to fix it..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 14:06:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 14: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 1RjWth-0006RG-By; Sat, 07 Jan 2012 14:05:25 +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 1RjWtg-0006RB-03
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 14:05:24 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325945117!10503285!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDAwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26664 invoked from network); 7 Jan 2012 14:05:17 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 7 Jan 2012 14:05:17 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id D59E825DB;
	Sat,  7 Jan 2012 16:05:15 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 3AB5720058; Sat,  7 Jan 2012 16:05:15 +0200 (EET)
Date: Sat, 7 Jan 2012 16:05:15 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120107140514.GC12984@reaktio.net>
References: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] usbback for linux 3.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 Sat, Jan 07, 2012 at 02:28:24AM +0000, James Harper wrote:
> Is anyone maintaining usbback that compiles against Linux 3.1?
> 

I think Konrad tried to forward-port the 2.6.32 pvops pvusb patch to 3.x,
but it didn't work (compile?) out-of-the-box.

pvusb patch for 2.6.32 pvops is here:
http://members.iinet.net.au/~nathanael/pvusb.diff
(http://lists.xensource.com/archives/html/xen-devel/2011-01/msg00354.html)

Maybe try it and see if it's trivial to fix it..

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 14:43:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 14: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 1RjXTk-00071r-IG; Sat, 07 Jan 2012 14:42:40 +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 1RjXTh-00071m-Vc
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 14:42:38 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325947350!10002318!1
X-Originating-IP: [77.238.189.192]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 22769 invoked from network); 7 Jan 2012 14:42:30 -0000
Received: from nm16-vm0.bullet.mail.ird.yahoo.com (HELO
	nm16-vm0.bullet.mail.ird.yahoo.com) (77.238.189.192)
	by server-11.tower-216.messagelabs.com with SMTP;
	7 Jan 2012 14:42:30 -0000
Received: from [77.238.189.50] by nm16.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 14:42:30 -0000
Received: from [212.82.108.112] by tm3.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 14:42:30 -0000
Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 14:42:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 122402.63538.bm@omp1021.mail.ird.yahoo.com
Received: (qmail 7869 invoked by uid 60001); 7 Jan 2012 14:42:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325947349; bh=lBuN00ar1zZvVlHsFm1yPgepE4WM2IYULpi2BOymuDI=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=FY2i4EUEKWV8N9/P7p+JGIj1aYBxITleIV042t9FjS65LZPuvPC0HtZbGOv4tLyb7bUEp1RdQpK9N0viCFKQJXfe6Av2eGOvfkeYOVebEivcASeZufF7Mdhlt6stAHo58nFE1z9haid4ByWYrB9mT65zRETAVIGl1CsaCOPnqGI=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=VMANA5Yr+7BS/Y6blv5nrsuufJ22f19V4epcu61zrHSmEi7dOwZuamIGqXmOXjo3VP4R4WMyxefjFAxLgkZs644YcL7x98jymfZI793c6RcXdVmFiOUeVwf2vigqHpl27kJLgj5Z+ihDUky7yYsxQvBBjTOdsHKFvx/YEQsvE6M=;
X-YMail-OSG: LavNqasVM1mk9XS0ci2lVK8XT87Jak03znXmpTemu850zAN
	nDmp_MoDKaDFPGOYtqxNeSs2Zfe7sRw8HlancDEdOc06YOyDzYXQpA3sumnj
	OyYYgVYpudSHhWp3L2NbRdpHYP_BBMq.HjMeDygxaPlfWJsxaGKmJAwTQaW6
	CfEai9XYueMoerBzshAAb8RW1sihHa0r8_KCraiy6CM5UhyjDfZuQSwMTg2i
	Vzh0Fd0L4AH7h3QsuLgX1KZUn33ZPZRswIvi4KfH1S_7oJx9SIZiAwJ5ekO8
	_5PLI7JbpJh4_Gifj4ZrTP8xb_AxRPn3zc_DbAGg1Bv.x0RUsbZuq9dXJgAn
	nB2wZ6CpFT._aQiHpRdwX7d2D72n9DMFW3h3cHTJvXmRvovY9KB50_veCHju
	.9aeYG0cTNTaZ1XB5TTeJHhmty66FDWPxVJcrhQwlvVB6YeP1hojLy9nFLq.
	b4FrVyZf4kPl1uTkmUMpDeku9vWDTrkRbOmlt2yOFkeiq5R.YxTatLAGbCBd
	7WAswEPFf_0aZeaWUxskTBwMP_OZb6DrIQcTNU1ArYMtcLvW_itk7qMupoA- -
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 07 Jan 2012 14:42:29 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
	<1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
	<1325938952.14430.YahooMailNeo@web29805.mail.ird.yahoo.com>
Message-ID: <1325947349.93467.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 14:42:29 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: David TECHER <davidtecher@yahoo.fr>, -+= Lta =+- <lta@akr.fm>
In-Reply-To: <1325938952.14430.YahooMailNeo@web29805.mail.ird.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="62747910-476652355-1325947349=:93467"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Re :  Re :  Re : Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--62747910-476652355-1325947349=:93467
Content-Type: multipart/alternative; boundary="62747910-870762312-1325947349=:93467"

--62747910-870762312-1325947349=:93467
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Attached=A0 are the=A0 updated Tobias patches for Xen 4.1.2.=0A=0AThe most =
important is 01_pass-through.patch that need to be updated :) else you rece=
ive a stupid error from compilation=0A=0A=0ASince I compiled kernel 3.1.6, =
without modules for Xen (=3DY), I have to remove 'xen-pci.passthough=3D1' f=
rom grub else I can not=A0 have my screen (stays black...)=0A=0A=0AI am doi=
ng my test on a new domU Windows 7.=0A=0AHope it will succeed :)=0A=0AI wil=
l let you know=0A=0A=0A=0A=0A=0A________________________________=0A De=A0: =
David TECHER <davidtecher@yahoo.fr>=0A=C0=A0: David TECHER <davidtecher@yah=
oo.fr>; -+=3D Lta =3D+- <lta@akr.fm> =0ACc=A0: "xen-devel@lists.xensource.c=
om" <xen-devel@lists.xensource.com> =0AEnvoy=E9 le : Samedi 7 Janvier 2012 =
13h22=0AObjet=A0: [Xen-devel] Re :  Re : Re :  Secondary VGA Passthrough, n=
vidia, win7: success report.=0A =0A=0AOk=0A=0AI think I understand what's w=
rong now :)=0A=0AInit build=0A=3D=3D=3D=3D=3D=3D=0A=0A=0Awget http://bits.x=
ensource.com/oss-xen/release/4.1.2/xen-4.1.2.tar.gz=0Atar xzf xen-4.1.2.tar=
.gz =0Acd xen-4.1.2/=0Acd tools/=0Amake =0Amake clean =0Acd ..=0A=0ADownloa=
d patches=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0Awget -q http://=
old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtIj4stRFbPo.txt=
 -O 01_pass-through.patch=0Awget -q http://old-list-archives.xen.org/archiv=
es/html/xen-devel/2010-05/txt06YdYEsi3S.txt -O 02_makefile.patch=0Awget -q=
=0A http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtS2w=
8cPgsnS.txt -O 03_dsdt.patch=0Awget -q http://old-list-archives.xen.org/arc=
hives/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader.patch=0Awget=
 -q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtiSI=
yxOHBZ8.txt -O 05_sound-makefile.patch=0A=0A=0AModify the first patch=0A=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0AReplace the path for =
the good path in the first patch 01_pass-through.patch=0A=0Ased -i "s:tools=
/ioemu-remote/hw/:tools/ioemu-qemu-xen/hw/:g" 01_pass-through.patch=0A=0AAp=
ply patches=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0A=0Aroot@mercury:/opt/t=
mp/xen-4.1.2# for file in $(ls 0*patch);do echo "######## PATCH =3D $file #=
###########";patch -p0 < $file;done=0A######## PATCH =3D 01_pass-through.pa=
tch ############=0Apatching file tools/ioemu-qemu-xen/hw/pass-through.c=0AH=
unk #1 succeeded at 22 with fuzz 2 (offset -1843 lines).=0AHunk #2 succeede=
d at 3312 (offset -55 lines).=0AHunk #3 succeeded at 3336 (offset -55 lines=
).=0AHunk #4 succeeded at 4335 with fuzz 2 (offset -144 lines).=0A######## =
PATCH =3D 02_makefile.patch ############=0Apatching file tools/firmware/hvm=
loader/Makefile=0A######## PATCH =3D 03_dsdt.patch ############=0Apatching =
file tools/firmware/hvmloader/acpi/dsdt.asl=0A######## PATCH =3D 04_hvmload=
er.patch ############=0Apatching file tools/firmware/hvmloader/hvmloader.c=
=0AHunk #1 succeeded at 116 (offset 1 line).=0AHunk #2 succeeded at 221 (of=
fset 1 line).=0AHunk #3 succeeded at 789 (offset 60 lines).=0A######## PATC=
H =3D 05_sound-makefile.patch ############=0Apatching file=0A tools/ioemu-r=
emote/xen-setup=0AHunk #1 FAILED at 16=0A=0AI will go on my tests and will =
let you know=0A=0AThanks=0A=0ADavid=0A=0A=0A_______________________________=
_=0A De=A0: David TECHER <davidtecher@yahoo.fr>=0A=C0=A0: -+=3D Lta =3D+- <=
lta@akr.fm> =0ACc=A0: "xen-devel@lists.xensource.com" <xen-devel@lists.xens=
ource.com> =0AEnvoy=E9 le : Samedi 7 Janvier 2012 13h04=0AObjet=A0: [Xen-de=
vel] Re : Re :  Secondary VGA Passthrough, nvidia, win7: success report.=0A=
 =0A=0AI tested xen 4.1.2 too.Tobias patches are the patches I've tested. I=
 am not very lucky.=0A=0A=0ASince you used Tobias patches as me, my questio=
n is - to be more precise - could you sent Tobias patches that you have mod=
ified in order to checking=0AI did not forget something as you. =0A=0A=0AMy=
 idea is that since I already have xen 4.2 installed, installing xen 4.1.2 =
over this , something wrong happens=0A=0A=0AMy screen stays like a black sc=
reen and nothing happens. no "gfx message" in the log.=0A=0AWith Xen 4.2 I =
tried aero desktop too but my domU crashes when=A0 I tried to activate aero=
.=0A=0A=0A=0A=0A________________________________=0A De=A0: -+=3D Lta =3D+- =
<lta@akr.fm>=0A=C0=A0: David TECHER <davidtecher@yahoo.fr> =0ACc=A0: xen-de=
vel@lists.xensource.com =0AEnvoy=E9 le : Samedi 7 Janvier 2012 3h17=0AObjet=
=A0: Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success =
report.=0A =0A=0AHi,=0A=0A=0AOn Fri, Jan 6, 2012 at 11:23 PM, David TECHER =
<davidtecher@yahoo.fr> wrote:=0A=0ACould you tell me what version of Xen? 4=
.1.0? 4.1.2?=0A=0AAs it is stated before this is a 4.1.2 version with debia=
n patches=0A=A0=0A=0A>=0A>By the way could you send your patches attached t=
o a mail so I could try?=0A=0A- There's also a link to tobias patche's on t=
he first post.=0A=A0=0A=0A>=0A>Test on Xen 4.2 failed (desktop stays to lag=
...)=0A=0AHave u tried to force windows to activate the aero desktop ?=0A=
=A0=0A=0A>=0A>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot bu=
t nothing appears on screen.=0A=0AI also followed tobias (same as yours) in=
structions to dump and build vgabios-pt.bin into xen, did u do it also ?=0A=
=A0=0A=0A>=0A>Strange.=0A>=0A>=0A>=0A>=0A>________________________________=
=0A> De=A0: -+=3D Lta =3D+- <lta@akr.fm>=0A>=C0=A0: xen-devel@lists.xensour=
ce.com =0A>Envoy=E9 le : Vendredi 6 Janvier 2012 17h48=0A>Objet=A0: [Xen-de=
vel] Secondary VGA Passthrough, nvidia, win7: success report.=0A>=0A>=0A>=
=0A>Hello xen-devel,=0A>=0A>=0A>=0A>=0A>This is my first post on this list =
and as such i might be breaking some explicit/implicit rules and i apologiz=
e if it's the case. Maybe this list isn't the exact=A0right=A0kind of place=
 where to post this kind of stuff, but i know lots of us are browsing this =
list as the primary source of documentation for xen.=0A>=0A>=0A>I've read m=
any times windows 7 isn't the right os to run on top of xen. Most of the gu=
y's who are running vga passthru are recommanding to use windows xp, and i'=
ve never seen any success report of vga passthru on windows 7 so i thought =
it was important to post mine.=0A>=0A>=0A>Anyway, here's my hardware setup =
:=0A>- Gigabyte GA-990X-UD3=0A>-=A0AMD Phenom II X6 1075T Processor=0A>- MS=
I Cyclone NVIDIA Geforce GTX 460=0A>=0A>=0A>On the software side i'm using =
:=0A>=0A>=0A>- Debian testing as Dom0=0A>- Xen-4.1 (debian version 4.1.2-2)=
 with what's now referred to as "Tobias Geiger patches" (http://old-list-ar=
chives.xen.org/archives/html/xen-devel/2010-05/msg00441.html) (You have to =
edit the patches, changing the path to some qemu source files for them to a=
pply)=0A>- debian's kernel =A03.1.5, compiled to include the pciback driver=
. Here's the output of `cat /boot/my3.1.5config | grep -i xen`=0A>CONFIG_XE=
N=3Dy=0A>CONFIG_XEN_DOM0=3Dy=0A>CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A>CONFIG_X=
EN_PVHVM=3Dy=0A>CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128=0A>CONFIG_XEN_SAVE_RESTO=
RE=3Dy=0A># CONFIG_XEN_DEBUG_FS is not set=0A># CONFIG_XEN_DEBUG is not set=
=0A>CONFIG_PCI_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKD=
EV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKDEV_BACKEND=3Dm=0A>CONFIG_NETXEN_NIC=3Dm=
=0A>CONFIG_XEN_NETDEV_FRONTEND=3Dm=0A>CONFIG_XEN_NETDEV_BACKEND=3Dm=0A>CONF=
IG_INPUT_XEN_KBDDEV_FRONTEND=3Dy=0A>CONFIG_HVC_XEN=3Dy=0A>CONFIG_XEN_WDT=3D=
m=0A>CONFIG_XEN_FBDEV_FRONTEND=3Dy=0A># Xen driver support=0A>CONFIG_XEN_BA=
LLOON=3Dy=0A># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=0A>CONFIG_XEN_S=
CRUB_PAGES=3Dy=0A>CONFIG_XEN_DEV_EVTCHN=3Dm=0A>CONFIG_XEN_BACKEND=3Dy=0A>CO=
NFIG_XENFS=3Dm=0A>CONFIG_XEN_COMPAT_XENFS=3Dy=0A>CONFIG_XEN_SYS_HYPERVISOR=
=3Dy=0A>CONFIG_XEN_XENBUS_FRONTEND=3Dy=0A>CONFIG_XEN_GNTDEV=3Dm=0A>CONFIG_X=
EN_GRANT_DEV_ALLOC=3Dm=0A>CONFIG_XEN_PLATFORM_PCI=3Dm=0A>CONFIG_SWIOTLB_XEN=
=3Dy=0A>CONFIG_XEN_PCIDEV_BACKEND=3Dy=0A>=0A>=0A>The kernel boot options ar=
e 'nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00=
.1)'=0A>=0A>=0A>- Here's my win7 domU config file :=0A>=0A>=0A>kernel =3D "=
/usr/lib/xen-4.1/boot/hvmloader"=0A>builder=3D'hvm'=0A>memory =3D 3072=0A>n=
ame =3D "w7"=0A>vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:=
35:49:62']=0A>disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/a=
ppz,hdb,w']=0A>device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0A>boot=3D"d=
c"=0A>=0A>=0A>pci=3D['01:00.0','01:00.1']=0A>gfx_passthru=3D1=0A>=0A>=0A>vc=
pus=3D6=0A>acpi=3D1=0A>sdl=3D0=0A>vnc=3D1=0A>vncconsole=3D1=0A>vncpasswd=3D=
''=0A>serial=3D'pty'=0A>usbdevice=3D'tablet'=0A>pae=3D1=0A>pci_msitranslate=
=3D0=0A>pci_power_mgmt=3D0=0A>acpi_s3 =3D 1=0A>acpi_s4 =3D 1=0A>on_poweroff=
 =3D 'destroy'=0A>on_reboot =A0 =3D 'restart'=0A>on_crash =A0 =A0=3D 'resta=
rt'=0A>xen_platform_pci=3D1=0A>hpet =3D 1=0A>viridian=3D1=0A>monitor=3D1=0A=
>xen_extended_power_mgmt=3D2=0A>hpet=3D1=0A>=0A>=0A>What's important here f=
or the Nvidia drivers to work and not give a nice nvlddmkm.sys BSOD is:=0A>=
pci_msitranslate=3D0=0A>pci_power_mgmt=3D0=0A>=0A>=0A>- Windows 7 32bits=0A=
>- Nvidia drivers 275.33=0A>- You have to manually run aero speed test or f=
orce aero to start by using registry entries for the desktop not to be lagg=
y=0A>=0A>=0A>The windows 7 domU is running fine with no performance decreas=
e noticeable, although i've not yet played intensive gpu video game, i'm st=
ill pretty confident they'll run fine.=0A>=0A>=0A>Anyway. i've still some p=
roblems i shall report in separate posts :=0A>- The PCI bus topology isn't =
preserved, and the gfx card, which is plugged on 01:00 becomes 05:00 on dom=
U.=0A>- I'm passing through an RME Hdsp / hammerfall pci sound card to the =
domU and while it is working fine on his own, there's a strange interaction=
 between it and the GPLPV network driver. When i start playing sound, the n=
etwork instantly cease working. It starts back as soon as i stop playing au=
dio.=0A>=0A>=0A>That's all folks,=0A>=0A>=0A>Cheers,=0A>Lta=0A>=0A>=0A>____=
___________________________________________=0A>Xen-devel mailing list=0A>Xe=
n-devel@lists.xensource.com=0A>http://lists.xensource.com/xen-devel=0A>=0A>=
=0A>=0A=0A=0A=0A_______________________________________________=0AXen-devel=
 mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensource.com/=
xen-devel=0A=0A=0A=0A_______________________________________________=0AXen-=
devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensource=
.com/xen-devel
--62747910-870762312-1325947349=:93467
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>Attached&n=
bsp; are the&nbsp; updated Tobias patches for Xen 4.1.2.</span></div><div><=
br><span></span></div><div><span>The most important is 01_pass-through.patc=
h that need to be updated :) else you receive a stupid error from compilati=
on<br></span></div><div><br><span></span></div><div><span>Since I compiled =
kernel 3.1.6, without modules for Xen (=3DY), I have to remove 'xen-pci.pas=
sthough=3D1' from grub else I can not&nbsp; have my screen (stays black...)=
<br></span></div><div><br><span></span></div><div><span>I am doing my test =
on a new domU Windows 7.</span></div><div><br><span></span></div><div><span=
>Hope it will succeed :)</span></div><div><br><span></span></div><div><span=
>I will let you know<br></span></div><div><br><span></span></div><div><span=
><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-famil=
y: 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> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><sp=
an style=3D"font-weight: bold;">=C0&nbsp;:</span></b> David TECHER &lt;davi=
dtecher@yahoo.fr&gt;; -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span style=
=3D"font-weight: bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xensource.com=
" &lt;xen-devel@lists.xensource.com&gt; <br> <b><span style=3D"font-weight:=
 bold;">Envoy=E9 le :</span></b> Samedi 7 Janvier 2012 13h22<br> <b><span s=
tyle=3D"font-weight: bold;">Objet&nbsp;:</span></b> [Xen-devel] Re :  Re : =
Re :  Secondary VGA Passthrough, nvidia, win7: success report.<br> </font> =
<br><div id=3D"yiv1764174381"><div><div style=3D"color:#000;background-colo=
r:#fff;font-family:times new roman, new york, times,
 serif;font-size:12pt;"><div><span>Ok</span></div><div><br><span></span></d=
iv><div><span>I think I understand what's wrong now :)</span></div><div><br=
><span></span></div><div>Init build</div><div>=3D=3D=3D=3D=3D=3D<br></div><=
div><br><span></span></div><div><span>wget http://bits.xensource.com/oss-xe=
n/release/4.1.2/xen-4.1.2.tar.gz<br>tar xzf xen-4.1.2.tar.gz <br>cd xen-4.1=
.2/<br>cd tools/<br>make <br>make clean <br>cd ..</span></div><div><span><b=
r></span></div><div><span>Download patches<br></span></div><div><span>=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></div><div><span>wget -q htt=
p://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtIj4stRFbPo=
.txt -O 01_pass-through.patch<br>wget -q http://old-list-archives.xen.org/a=
rchives/html/xen-devel/2010-05/txt06YdYEsi3S.txt -O 02_makefile.patch<br>wg=
et -q=0A http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/t=
xtS2w8cPgsnS.txt -O 03_dsdt.patch<br>wget -q http://old-list-archives.xen.o=
rg/archives/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader.patch<=
br>wget -q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05=
/txtiSIyxOHBZ8.txt -O 05_sound-makefile.patch<br></span></div><div><br><spa=
n></span></div><div><span>Modify the first patch</span></div><div><span>=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></div><div><span><b=
r></span></div><div><span>Replace the path for the good path in the first p=
atch </span><span>01_pass-through.patch</span></div><div><span><br></span><=
/div><div><span>sed -i "s:tools/ioemu-remote/hw/:tools/ioemu-qemu-xen/hw/:g=
" 01_pass-through.patch</span></div><div><br><span></span></div><div><span>=
Apply patches</span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></sp=
an></div><div><span><br></span></div><div><span><br></span></div><div><span=
>root@mercury:/opt/tmp/xen-4.1.2# for file in $(ls=0A 0*patch);do echo "###=
##### PATCH =3D $file ############";patch -p0 &lt; $file;done<br>######## P=
ATCH =3D 01_pass-through.patch ############<br>patching file tools/ioemu-qe=
mu-xen/hw/pass-through.c<br>Hunk #1 succeeded at 22 with fuzz 2 (offset -18=
43 lines).<br>Hunk #2 succeeded at 3312 (offset -55 lines).<br>Hunk #3 succ=
eeded at 3336 (offset -55 lines).<br>Hunk #4 succeeded at 4335 with fuzz 2 =
(offset -144 lines).<br>######## PATCH =3D 02_makefile.patch ############<b=
r>patching file tools/firmware/hvmloader/Makefile<br>######## PATCH =3D 03_=
dsdt.patch ############<br>patching file tools/firmware/hvmloader/acpi/dsdt=
.asl<br>######## PATCH =3D 04_hvmloader.patch ############<br>patching file=
 tools/firmware/hvmloader/hvmloader.c<br>Hunk #1 succeeded at 116 (offset 1=
 line).<br>Hunk #2 succeeded at 221 (offset 1 line).<br>Hunk #3 succeeded a=
t 789 (offset 60 lines).<br>######## PATCH =3D 05_sound-makefile.patch ####=
########<br>patching file=0A tools/ioemu-remote/xen-setup<br>Hunk #1 FAILED=
 at 16</span></div><div><br><span></span></div><div><span>I will go on my t=
ests and will let you know</span></div><div><br><span></span></div><div><sp=
an>Thanks</span></div><div><br><span></span></div><div><span>David</span></=
div><div><br></div>  <div style=3D"font-family:times new roman, new york, t=
imes, serif;font-size:12pt;"> <div style=3D"font-family:times new roman, ne=
w 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> Dav=
id TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><span style=3D"font-weight:bo=
ld;">=C0&nbsp;:</span></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span =
style=3D"font-weight:bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xensource=
.com" &lt;xen-devel@lists.xensource.com&gt; <br> <b><span style=3D"font-wei=
ght:bold;">Envoy=E9 le :</span></b> Samedi 7 Janvier 2012 13h04<br> <b><spa=
n style=3D"=0Afont-weight:bold;">Objet&nbsp;:</span></b> [Xen-devel] Re : R=
e :  Secondary VGA Passthrough, nvidia, win7: success report.<br> </font> <=
br><div id=3D"yiv1764174381"><div><div style=3D"color:#000;background-color=
:#fff;font-family:times new roman, new york, times, serif;font-size:12pt;">=
<div><span>I tested xen 4.1.2 too.</span><span> Tobias patches are the patc=
hes I've tested. I am not very lucky.<br></span></div><div><span><br></span=
></div><div><span>Since you used Tobias patches as me, my question is - to =
be more precise - could you sent Tobias patches that you have modified in o=
rder to checking</span></div><div><span>I did not forget something as you. =
<br></span></div><div><br><span></span></div><div><span>My idea is that sin=
ce I already have xen 4.2 installed, installing xen 4.1.2 over this , somet=
hing wrong happens<br></span></div><div><br><span></span></div><div><span>M=
y screen stays like a black screen and nothing happens. no "gfx message" in=
 the=0A log.</span></div><div><br><span></span></div><div><span>With Xen 4.=
2 I tried aero desktop too but my domU crashes when&nbsp; I tried to activa=
te=0A aero.<br></span></div><div><br><span></span></div><div><span></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, n=
ew york, times, serif;font-size:12pt;"> <font face=3D"Arial" size=3D"2"> <h=
r size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -+=
=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight:bold;">=
=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><spa=
n style=3D"font-weight:bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensourc=
e.com <br> <b><span style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Sa=
medi 7 Janvier 2012 3h17<br> <b><span style=3D"font-weight:bold;">Objet&nbs=
p;:</span></b> Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7=
: success report.<br> </font> <br><div id=3D"yiv1764174381">Hi,<br><br><div=
 class=3D"yiv1764174381gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, David =
TECHER <span dir=3D"ltr">&lt;<a
 rel=3D"nofollow" ymailto=3D"mailto:davidtecher@yahoo.fr" target=3D"_blank"=
 href=3D"mailto:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>&gt;</span> w=
rote:<br><blockquote class=3D"yiv1764174381gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D=
"font-size:12pt;font-family:times new roman, new york, times, serif;"><div>=
<span>Could you tell me what version of Xen? 4.1.0? 4.1.2?</span></div></di=
v></div></blockquote><div><br></div><div>As it is stated before this is a 4=
.1.2 version with debian patches</div>=0A<div>&nbsp;</div><blockquote class=
=3D"yiv1764174381gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex;"><div><div style=3D"font-size:12pt;font-family:t=
imes new roman, new york, times, serif;"><div><br><span></span></div>=0A<di=
v><span>By the way could you send your patches attached to a mail so I coul=
d try?</span></div></div></div></blockquote><div><br></div><div>- There's a=
lso a link to tobias patche's on the first post.</div><div>&nbsp;</div>=0A<=
blockquote class=3D"yiv1764174381gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;"><div><div style=3D"font-size:12=
pt;font-family:times new roman, new york, times, serif;"><div><br><span></s=
pan></div><div><span>Test on Xen 4.2 failed (desktop stays to lag...)</span=
></div>=0A</div></div></blockquote><div><br></div><div>Have u tried to forc=
e windows to activate the aero desktop ?</div><div>&nbsp;</div><blockquote =
class=3D"yiv1764174381gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size:12pt;font-=
family:times new roman, new york, times, serif;"><div><br><span></span></di=
v><div><span>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but=
 nothing appears on screen.</span></div>=0A</div></div></blockquote><div><b=
r></div><div>I also followed tobias (same as yours) instructions to dump an=
d build vgabios-pt.bin into xen, did u do it also ?</div><div>&nbsp;</div><=
blockquote class=3D"yiv1764174381gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size=
:12pt;font-family:times new roman, new york, times, serif;"><div><br><span>=
</span></div><div><span>Strange.<br></span></div><div><br></div>  <div styl=
e=3D"font-family:times new roman, new york, times, serif;font-size:12pt;">=
=0A <div style=3D"font-family:times new roman, new york, times, serif;font-=
size:12pt;"> <font face=3D"Arial"><div class=3D"yiv1764174381im"> <hr size=
=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -+=3D Lt=
a =3D+- &lt;<a rel=3D"nofollow" ymailto=3D"mailto:lta@akr.fm" target=3D"_bl=
ank" href=3D"mailto:lta@akr.fm">lta@akr.fm</a>&gt;<br>=0A </div><b><span st=
yle=3D"font-weight:bold;">=C0&nbsp;:</span></b> <a rel=3D"nofollow" ymailto=
=3D"mailto:xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mailto:=
xen-devel@lists.xensource.com">xen-devel@lists.xensource.com</a> <br> <b><s=
pan style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Vendredi 6 Janvier=
 2012 17h48<br>=0A <b><span style=3D"font-weight:bold;">Objet&nbsp;:</span>=
</b> [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success report.<b=
r> </font><div><div class=3D"yiv1764174381h5"> <br><div><div>Hello xen-deve=
l,<div><br></div><div><br></div><div>=0AThis is my first post on this list =
and as such i might be breaking some explicit/implicit rules and i apologiz=
e if it's the case. Maybe this list isn't the exact&nbsp;right&nbsp;kind of=
 place where to post this kind of stuff, but i know lots of us are browsing=
 this list as the primary source of documentation for xen.</div>=0A=0A=0A<d=
iv><br></div><div>I've read many times windows 7 isn't the right os to run =
on top of xen. Most of the guy's who are running vga passthru are recommand=
ing to use windows xp, and i've never seen any success report of vga passth=
ru on windows 7 so i thought it was important to post mine.</div>=0A=0A=0A<=
div><br></div><div>Anyway, here's my hardware setup :</div><div>- Gigabyte =
GA-990X-UD3</div><div>-&nbsp;AMD Phenom II X6 1075T Processor</div><div>- M=
SI Cyclone NVIDIA Geforce GTX 460</div><div><br></div><div>On the software =
side i'm using :</div>=0A=0A=0A<div><br></div><div>- Debian testing as Dom0=
</div><div>- Xen-4.1 (debian version 4.1.2-2) with what's now referred to a=
s "Tobias Geiger patches" (<a rel=3D"nofollow" target=3D"_blank" href=3D"ht=
tp://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.htm=
l">http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg0044=
1.html</a>) (You have to edit the patches, changing the path to some qemu s=
ource files for them to apply)</div>=0A=0A=0A<div>- debian's kernel &nbsp;3=
.1.5, compiled to include the pciback driver. Here's the output of `cat /bo=
ot/my3.1.5config | grep -i xen`</div><div><div><font size=3D"1">CONFIG_XEN=
=3Dy</font></div><div>=0A<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><=
div><font size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><font size=3D"1">CONFI=
G_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><font size=3D"1">CONFIG_XEN_=
SAVE_RESTORE=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_DEBUG_FS is=
 not set</font></div>=0A<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set=
</font></div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><fon=
t size=3D"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CON=
FIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D"1">CONFIG_NETXEN_=
NIC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm=
</font></div><div><font size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></di=
v><div><font size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>=
=0A<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"=
1">CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FR=
ONTEND=3Dy</font></div>=0A<div><font size=3D"1"># Xen driver support</font>=
</div><div><font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font></div><div><font s=
ize=3D"1"># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set</font></div>=0A<di=
v><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font size=
=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_X=
EN_BACKEND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_XENFS=3Dm</font>=
</div><div><font size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font size=3D"1">CON=
FIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_GRANT_DEV_A=
LLOC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</=
font></div><div><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=0A</div><div><fon=
t size=3D"1"><br></font></div><div>The kernel boot options are 'nomodeset x=
en-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'</div><div=
><br></div><div>- Here's my win7 domU config file :</div>=0A=0A=0A<div><br>=
</div><div><div><font size=3D"1">kernel =3D "/usr/lib/xen-4.1/boot/hvmloade=
r"</font></div><div><font size=3D"1">builder=3D'hvm'</font></div><div><font=
 size=3D"1">memory =3D 3072</font></div>=0A<div><font size=3D"1">name =3D "=
w7"</font></div><div><font size=3D"1">vif =3D [ 'type=3Dnetfront,bridge=3Dx=
enbr0, mac=3D00:16:3e:35:49:62']</font></div><div><font size=3D"1">disk =3D=
 [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']</font></di=
v>=0A=0A=0A<div><font size=3D"1">device_model =3D '/usr/lib/xen-4.1/bin/qem=
u-dm'</font></div><div><font size=3D"1">boot=3D"dc"</font></div><div><font =
size=3D"1"><br>=0A</font></div><div><font size=3D"1">pci=3D['01:00.0','01:0=
0.1']</font></div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><=
font size=3D"1"><br>=0A</font></div><div><font size=3D"1">vcpus=3D6</font><=
/div><div><font size=3D"1">acpi=3D1</font></div><div><font size=3D"1">sdl=
=3D0</font></div><div><font size=3D"1">vnc=3D1</font></div>=0A<div><font si=
ze=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncpasswd=3D''</f=
ont></div><div><font size=3D"1">serial=3D'pty'</font></div>=0A<div><font si=
ze=3D"1">usbdevice=3D'tablet'</font></div><div><font size=3D"1">pae=3D1</fo=
nt></div><div><font size=3D"1">pci_msitranslate=3D0</font></div>=0A<div><fo=
nt size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">acpi_s3 =
=3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><div><fon=
t size=3D"1">on_poweroff =3D 'destroy'</font></div>=0A<div><font size=3D"1"=
>on_reboot &nbsp; =3D 'restart'</font></div><div><font size=3D"1">on_crash =
&nbsp; &nbsp;=3D 'restart'</font></div><div><font size=3D"1">xen_platform_p=
ci=3D1</font></div>=0A<div><font size=3D"1">hpet =3D 1</font></div><div><fo=
nt size=3D"1">viridian=3D1</font></div><div><font size=3D"1">monitor=3D1</f=
ont></div><div><font size=3D"1">xen_extended_power_mgmt=3D2</font></div>=0A=
<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><div>What's=
 important here for the Nvidia drivers to work and not give a nice nvlddmkm=
.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0</font></=
div>=0A=0A=0A<div><font size=3D"1">pci_power_mgmt=3D0</font></div></div><di=
v><font size=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvi=
dia drivers 275.33</div><div>- You have to manually run aero speed test or =
force aero to start by using registry entries for the desktop not to be lag=
gy</div>=0A=0A=0A<div><br></div><div>The windows 7 domU is running fine wit=
h no performance decrease noticeable, although i've not yet played intensiv=
e gpu video game, i'm still pretty confident they'll run fine.</div><div><b=
r>=0A=0A=0A</div><div>Anyway. i've still some problems i shall report in se=
parate posts :</div><div>- The PCI bus topology isn't preserved, and the gf=
x card, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I'm pa=
ssing through an RME Hdsp / hammerfall pci sound card to the domU and while=
 it is working fine on his own, there's a strange interaction between it an=
d the GPLPV network driver. When i start playing sound, the network instant=
ly cease working. It starts back as soon as i stop playing audio.</div>=0A=
=0A=0A<div><br></div><div>That's all folks,</div><div><br></div><div>Cheers=
,</div><div>Lta</div>=0A</div><br>=0A</div><br></div></div><div class=3D"yi=
v1764174381im">_______________________________________________<br>Xen-devel=
 mailing list<br><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.xens=
ource.com" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.com">=
Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://lists.xensource.com/xen-devel">http://lists.xensource.com/xe=
n-devel</a><br>=0A<br><br> </div></div> </div>  </div></div></blockquote></=
div><br>=0A</div><br><br> </div> </div>  </div></div></div><br>____________=
___________________________________<br>Xen-devel mailing list<br><a rel=3D"=
nofollow" ymailto=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank=
" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.c=
om</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensou=
rce.com/xen-devel">http://lists.xensource.com/xen-devel</a><br><br><br> </d=
iv> </div>  </div></div></div><br>_________________________________________=
______<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-devel@lists.xe=
nsource.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" targe=
t=3D"_blank">http://lists.xensource.com/xen-devel</a><br><br><br> </div> </=
div>  </div></body></html>
--62747910-870762312-1325947349=:93467--
--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="01_pass-through.c.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="01_pass-through.c.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2lvZW11LXFlbXUteGVuL2h3L3Bh
c3MtdGhyb3VnaC5jCTIwMTEtMDItMTEgMTg6NTQ6NTEuMDAwMDAwMDAwICsw
MTAwCisrKyB4ZW4tNC4xLjJfd29yay90b29scy9pb2VtdS1xZW11LXhlbi9o
dy9wYXNzLXRocm91Z2guYwkyMDEyLTAxLTA3IDE0OjM3OjU1LjAwMDAwMDAw
MCArMDEwMApAQCAtMTE1LDYgKzExNSw3OSBAQCBzdHJ1Y3QgZHBjaV9pbmZv
cyB7CiAKIGNoYXIgbWFwcGVkX21hY2hpbmVfaXJxW1BUX05SX0lSUVNdID0g
ezB9OwogCisgI2RlZmluZSBQQ0lfSEVBREVSX1RZUEVfQUREUiAgICAgICAg
MHgwZQorICNkZWZpbmUgUENJX0JSSURHRV9GTEFHICAgICAgICAgICAgIDB4
MDEKKyAKKyAjZGVmaW5lIFBDSV9DTEFTU19DT0RFX0FERFJfMCAgICAgICAw
eDA5CisgI2RlZmluZSBQQ0lfQ0xBU1NfQ09ERV9BRERSXzEgICAgICAgMHgw
YQorICNkZWZpbmUgUENJX0NMQVNTX0NPREVfQUREUl8yICAgICAgIDB4MGIK
KyAjZGVmaW5lIFBDSV9DTEFTU19DT0RFX0RBVEFfMCAgICAgICAweDA2MDAw
MAorICNkZWZpbmUgUENJX0NMQVNTX0NPREVfREFUQV8xICAgICAgIDB4MDYw
MAorICNkZWZpbmUgUENJX0NMQVNTX0NPREVfREFUQV8yICAgICAgIDB4MDYK
KyAKKyAjZGVmaW5lIFBDSV9TRUNPTkRfQlVTX05VTUJFUl9BRERSICAweDE5
CisgCisgI2RlZmluZSBQQ0lfQlJJREdFX0NPTlRST0xfQUREUiAgICAgMHgz
ZQorICNkZWZpbmUgUENJX0JSSURHRV9WR0FfRU5BQkxFICAgICAgIDB4MTgK
KyAKKyAjZGVmaW5lIFBDSV9HUkFQSElDX0NPTlRST0xfQUREUiAgICAweDUy
CisgI2RlZmluZSBQQ0lfSE9TVF9CUklER0VfSUdEX1ZHQV9ESVNBQkxFIDB4
MDIKKyAKKyBzdGF0aWMgdWludDMyX3QgZ2Z4X2NsYWltX3ZnYV9jeWNsZShz
dHJ1Y3QgcGNpX2FjY2VzcyAqcGNpX2FjY2VzcywgIHVpbnQzMl90IGJ1cywg
dWludDMyX3QgZGV2Zm4sIHVpbnQzMl90IGZ1bmMpOworIAorIAorIC8qCisg
ICogQ2xhaW0gdmdhIGN5Y2xlIGZvciB0aGUgZ3JhcGhpY3MgY2FyZCBwYXNz
LXRocm91Z2gKKyAgKi8KKyBzdGF0aWMgdWludDMyX3QgZ2Z4X2NsYWltX3Zn
YV9jeWNsZShzdHJ1Y3QgcGNpX2FjY2VzcyAqcGNpX2FjY2VzcywKKyAgICAg
ICAgdWludDMyX3QgYnVzLCB1aW50MzJfdCBkZXZmbiwgdWludDMyX3QgZnVu
YykKKyB7CisgICAgIHN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2OworIAorICAg
ICBmb3IgKCBwY2lfZGV2ID0gcGNpX2FjY2Vzcy0+ZGV2aWNlczsgcGNpX2Rl
diAhPSBOVUxMOyBwY2lfZGV2ID0gcGNpX2Rldi0+bmV4dCApCisgICAgIHsK
KyAgICAgICAgIC8qIENoZWNrIHdoZXRoZXIgdGhpcyBpcyBhIG9yZGluYXJ5
IGJyaWRnZSAqLworICAgICAgICAgaWYgKCBwY2lfcmVhZF9ieXRlKHBjaV9k
ZXYsIFBDSV9IRUFERVJfVFlQRV9BRERSKSA9PSBQQ0lfQlJJREdFX0ZMQUcg
KQorICAgICAgICAgeworICAgICAgICAgICAgIHVuc2lnbmVkIHNlY19idXNf
bnVtID0gcGNpX3JlYWRfYnl0ZShwY2lfZGV2LCBQQ0lfU0VDT05EX0JVU19O
VU1CRVJfQUREUik7CisgICAgICAgICAgICAgdW5zaWduZWQgdWJyZyA9IHBj
aV9yZWFkX2J5dGUocGNpX2RldiwgUENJX0JSSURHRV9DT05UUk9MX0FERFIp
OworIAorICAgICAgICAgICAgIFBUX0xPRygiYnJpZGdlIGZvciBidXMgJWQs
IHByZXZpb3VzIGJyaWRnZSBjb250cm9sIGlzICV4XG4iLCBzZWNfYnVzX251
bSwgdWJyZyk7CisgICAgICAgICAgICAgUFRfTE9HKCJidXM9MHglZCwgZGV2
PTB4JXgsIGZ1bmM9MHgleFxuIixwY2lfZGV2LT5idXMscGNpX2Rldi0+ZGV2
LHBjaV9kZXYtPmZ1bmMpOworIAorICAgICAgICAgICAgIGlmICggc2VjX2J1
c19udW0gPT0gYnVzICkgLyogVkdBIGRldmljZSdzIGJyaWRnZSAqLworICAg
ICAgICAgICAgICAgICB1YnJnIHw9IFBDSV9CUklER0VfVkdBX0VOQUJMRTsK
KyAgICAgICAgICAgICBlbHNlIC8qIE90aGVyIGRldmljZSdzIGJyaWRnZSAq
LworICAgICAgICAgICAgICAgICB1YnJnICY9IH5QQ0lfQlJJREdFX1ZHQV9F
TkFCTEU7CisgCisgICAgICAgICAgICAgcGNpX3dyaXRlX2J5dGUocGNpX2Rl
diwgUENJX0JSSURHRV9DT05UUk9MX0FERFIsIHVicmcpOworICAgICAgICAg
ICAgIFBUX0xPRygiYnJpZGdlIGZvciBidXMgJWQsIHVwZGF0ZWQgYnJpZGdl
IGNvbnRyb2wgaXMgJXhcbiIsIHNlY19idXNfbnVtLCB1YnJnKTsKKyAgICAg
ICAgIH0KKyAgICAgfQorIAorICAgICBmb3IgKCBwY2lfZGV2ID0gcGNpX2Fj
Y2Vzcy0+ZGV2aWNlczsgcGNpX2RldiAhPSBOVUxMOyBwY2lfZGV2ID0gcGNp
X2Rldi0+bmV4dCApCisgICAgIHsKKyAgICAgICAgIC8qIENoZWNrIGhvc3Qg
YnJpZGdlICovCisgICAgICAgICBpZiAoIHBjaV9yZWFkX3dvcmQocGNpX2Rl
diwgUENJX0NMQVNTX0NPREVfQUREUl8xKSA9PSBQQ0lfQ0xBU1NfQ09ERV9E
QVRBXzEgKQorICAgICAgICAgeworICAgICAgICAgICAgIHVuc2lnbmVkIHVp
Z2QgPSBwY2lfcmVhZF9ieXRlKHBjaV9kZXYsIFBDSV9HUkFQSElDX0NPTlRS
T0xfQUREUik7CisgCisgICAgICAgICAgICAgUFRfTE9HKCJwcmV2aW91cyBp
Z2QgY29udHJvbCBpcyAleFxuIiwgdWlnZCk7CisgCisgICAgICAgICAgICAg
aWYgKCBidXMgPT0gMCApCisgICAgICAgICAgICAgICAgIHVpZ2QgJj0gflBD
SV9IT1NUX0JSSURHRV9JR0RfVkdBX0RJU0FCTEU7CisgICAgICAgICAgICAg
ZWxzZQorICAgICAgICAgICAgICAgICB1aWdkIHw9IFBDSV9IT1NUX0JSSURH
RV9JR0RfVkdBX0RJU0FCTEU7CisgCisgICAgICAgICAgICAgcGNpX3dyaXRl
X2J5dGUocGNpX2RldiwgUENJX0dSQVBISUNfQ09OVFJPTF9BRERSLCB1aWdk
KTsKKyAgICAgICAgICAgICBQVF9MT0coInVwZGF0ZWQgaWdkIGNvbnRyb2wg
aXMgJXhcbiIsIHVpZ2QpOworICAgICAgICAgfQorICAgICB9CisgCisgICAg
IHJldHVybiAwOworIH0KKworCiAvKiBwcm90b3R5cGUgKi8KIHN0YXRpYyB1
aW50MzJfdCBwdF9jb21tb25fcmVnX2luaXQoc3RydWN0IHB0X2RldiAqcHRk
ZXYsCiAgICAgc3RydWN0IHB0X3JlZ19pbmZvX3RibCAqcmVnLCB1aW50MzJf
dCByZWFsX29mZnNldCk7CkBAIC0zMjQzLDYgKzMzMTYsOCBAQCBzdGF0aWMg
aW50IHB0X2NtZF9yZWdfcmVhZChzdHJ1Y3QgcHRfZGV2CiB9CiAKIC8qIHJl
YWQgQkFSICovCitzdGF0aWMgaW50IGdmeF9maXJzdF9yZWFkX0JBUls3XSA9
IHsxLCAxLCAxLCAxLCAxLCAxLCAxfTsKKwogc3RhdGljIGludCBwdF9iYXJf
cmVnX3JlYWQoc3RydWN0IHB0X2RldiAqcHRkZXYsCiAgICAgICAgIHN0cnVj
dCBwdF9yZWdfdGJsICpjZmdfZW50cnksCiAgICAgICAgIHVpbnQzMl90ICp2
YWx1ZSwgdWludDMyX3QgdmFsaWRfbWFzaykKQEAgLTMyNjUsNiArMzM0MCwx
NyBAQCBzdGF0aWMgaW50IHB0X2Jhcl9yZWdfcmVhZChzdHJ1Y3QgcHRfZGV2
CiAgICAgLyogdXNlIGZpeGVkLXVwIHZhbHVlIGZyb20ga2VybmVsIHN5c2Zz
ICovCiAgICAgKnZhbHVlID0gcHRkZXYtPnBjaV9kZXYtPmJhc2VfYWRkcltp
bmRleF07CiAKKyAgICBpZiAoIHB0ZGV2LT5wY2lfZGV2LT5kZXZpY2VfY2xh
c3MgPT0gMHgzMDAgKQorICAgIHsKKyAgICAgICAgaWYgKCBnZnhfZmlyc3Rf
cmVhZF9CQVJbaW5kZXhdID09IDEgKQorICAgICAgICB7CisgICAgICAgICAg
ICBnZnhfZmlyc3RfcmVhZF9CQVJbaW5kZXhdID0gMDsKKyAgICAgICAgICAg
IFBUX0xPRygiZmlyc3QgcmVhZCBCQVJzIG9mIGdmeFxuIik7CisgICAgICAg
ICAgICByZXR1cm4gMDsKKyAgICAgICAgfQorICAgIH0KKworCiAgICAgLyog
c2V0IGVtdWxhdGUgbWFzayBkZXBlbmQgb24gQkFSIGZsYWcgKi8KICAgICBz
d2l0Y2ggKHB0ZGV2LT5iYXNlc1tpbmRleF0uYmFyX2ZsYWcpCiAgICAgewpA
QCAtNDI1Myw2ICs0MzM5LDEzIEBAIHN0YXRpYyBzdHJ1Y3QgcHRfZGV2ICog
cmVnaXN0ZXJfcmVhbF9kZXYKICAgICB9CiAKIAorICAgIGlmICggcGNpX2Rl
di0+ZGV2aWNlX2NsYXNzID09IDB4MDMwMCApCisgICAgeworICAgICAgICBy
YyA9IGdmeF9jbGFpbV92Z2FfY3ljbGUocGNpX2FjY2Vzcywgcl9idXMsIHJf
ZGV2LCByX2Z1bmMpOworICAgICAgICBpZiAoIHJjICE9IDAgKQorICAgICAg
ICAgICAgcmV0dXJuIE5VTEw7CisgICAgfQorCiAgICAgLyogcmVpbml0aWFs
aXplIGVhY2ggY29uZmlnIHJlZ2lzdGVyIHRvIGJlIGVtdWxhdGVkICovCiAg
ICAgcmMgPSBwdF9jb25maWdfaW5pdChhc3NpZ25lZF9kZXZpY2UpOwogICAg
IGlmICggcmMgPCAwICkgewo=

--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="02_Makefile.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="02_Makefile.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9N
YWtlZmlsZQkyMDExLTEwLTIwIDE5OjA1OjQxLjAwMDAwMDAwMCArMDIwMAor
KysgeGVuLTQuMS4yX3dvcmsvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL01h
a2VmaWxlCTIwMTItMDEtMDcgMTQ6MTk6NDguMDAwMDAwMDAwICswMTAwCkBA
IC01MCw2ICs1MCw3IEBAIGh2bWxvYWRlcjogJChPQkpTKSBhY3BpL2FjcGku
YQogcm9tcy5oOiAuLi9yb21iaW9zL0JJT1MtYm9jaHMtbGF0ZXN0IC4uL3Zn
YWJpb3MvVkdBQklPUy1sZ3BsLWxhdGVzdC5iaW4gXAogCS4uL3ZnYWJpb3Mv
VkdBQklPUy1sZ3BsLWxhdGVzdC5jaXJydXMuYmluIC4uL2V0aGVyYm9vdC9l
Yi1yb21zLmgKIAlzaCAuL21raGV4IHJvbWJpb3MgLi4vcm9tYmlvcy9CSU9T
LWJvY2hzLWxhdGVzdCA+IHJvbXMuaAorCXNoIC4vbWtoZXggdmdhYmlvc19w
dCAuLi92Z2FiaW9zL3ZnYWJpb3MtcHQuYmluID4+IHJvbXMuaCAgICAgICAg
IAogCXNoIC4vbWtoZXggdmdhYmlvc19zdGR2Z2EgLi4vdmdhYmlvcy9WR0FC
SU9TLWxncGwtbGF0ZXN0LmJpbiA+PiByb21zLmgKIAlzaCAuL21raGV4IHZn
YWJpb3NfY2lycnVzdmdhIFwKIAkJLi4vdmdhYmlvcy9WR0FCSU9TLWxncGwt
bGF0ZXN0LmNpcnJ1cy5iaW4gPj4gcm9tcy5oCg==

--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="05_xen-setup.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="05_xen-setup.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2lvZW11LXFlbXUteGVuL3hlbi1z
ZXR1cAkyMDExLTAyLTExIDE4OjU0OjUxLjAwMDAwMDAwMCArMDEwMAorKysg
eGVuLTQuMS4yX3dvcmsvdG9vbHMvaW9lbXUtcWVtdS14ZW4veGVuLXNldHVw
CTIwMTItMDEtMDcgMTQ6Mjc6MDQuMDAwMDAwMDAwICswMTAwCkBAIC0xOCw3
ICsxOCw4IEBAIGlmIHRlc3QgLXogIiR7WEVOX1NDUklQVF9ESVJ9IjsgdGhl
bgogCVhFTl9TQ1JJUFRfRElSPSIvZXRjL3hlbi9zY3JpcHRzIgogZmkKIAot
JHtRRU1VX1JPT1Q6LS59L2NvbmZpZ3VyZSAtLWRpc2FibGUtZ2Z4LWNoZWNr
IC0tZGlzYWJsZS1jdXJzZXMgLS1kaXNhYmxlLXNsaXJwICIkQCIgLS1wcmVm
aXg9JHtQUkVGSVh9CisjJHtRRU1VX1JPT1Q6LS59L2NvbmZpZ3VyZSAtLWRp
c2FibGUtZ2Z4LWNoZWNrIC0tZGlzYWJsZS1jdXJzZXMgLS1kaXNhYmxlLXNs
aXJwICIkQCIgLS1wcmVmaXg9JHtQUkVGSVh9Ciske1FFTVVfUk9PVDotLn0v
Y29uZmlndXJlIC0tYXVkaW8tZHJ2LWxpc3Q9YWxzYSAtLWVuYWJsZS1taXhl
bXUgLS1kaXNhYmxlLWdmeC1jaGVjayAtLWRpc2FibGUtY3Vyc2VzIC0tZGlz
YWJsZS1zbGlycCAiJEAiIC0tcHJlZml4PSR7UFJFRklYfQogCiBpZiBbICJ4
JFhFTl9ST09UIiAhPSB4IF07IHRoZW4KIAllY2hvICJYRU5fUk9PVD0kWEVO
X1JPT1QiID4+Y29uZmlnLWhvc3QubWFrCg==

--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="04_hvmloader.c.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="04_hvmloader.c.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9o
dm1sb2FkZXIuYwkyMDExLTEwLTIwIDE5OjA1OjQxLjAwMDAwMDAwMCArMDIw
MAorKysgeGVuLTQuMS4yX3dvcmsvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L2h2bWxvYWRlci5jCTIwMTItMDEtMDcgMTQ6MTk6NDguMDAwMDAwMDAwICsw
MTAwCkBAIC0xMTYsNiArMTE2LDkgQEAgdW5zaWduZWQgbG9uZyBwY2lfbWVt
X2VuZCA9IFBDSV9NRU1fRU5EOwogCiBzdGF0aWMgZW51bSB7IFZHQV9ub25l
LCBWR0Ffc3RkLCBWR0FfY2lycnVzLCBWR0FfcHQgfSB2aXJ0dWFsX3ZnYSA9
IFZHQV9ub25lOwogCisvKiB2aXJ0dWFsIEJERiBvZiBwYXNzLXRocm91Z2hl
ZCBnZnggKi8KK3N0YXRpYyB1aW50OF90IGdmeF9iZGY7CisKIHN0YXRpYyB2
b2lkIGluaXRfaHlwZXJjYWxscyh2b2lkKQogewogICAgIHVpbnQzMl90IGVh
eCwgZWJ4LCBlY3gsIGVkeDsKQEAgLTIxOCw2ICsyMjEsNDIgQEAgc3RhdGlj
IHZvaWQgcGNpX3NldHVwKHZvaWQpCiAgICAgICAgICAgICAgICAgdmlydHVh
bF92Z2EgPSBWR0FfY2lycnVzOwogICAgICAgICAgICAgZWxzZSBpZiAoIHZp
cnR1YWxfdmdhID09IFZHQV9ub25lICkKICAgICAgICAgICAgICAgICB2aXJ0
dWFsX3ZnYSA9IFZHQV9wdDsKKyAgICAgICAgICAgICAgICBnZnhfYmRmID0g
ZGV2Zm47CisKKyAgICAgICAgICAgICAgICAvKiBNYWtlIHZCQVI9cEJBUiAq
LworICAgICAgICAgICAgICAgIHByaW50ZigiTWFrZSB2QkFSID0gcEJBUiBv
ZiBhc3NpZ25lZCBnZnhcbiIpOworICAgICAgICAgICAgICAgIGZvciAoIGJh
ciA9IDA7IGJhciA8IDc7IGJhcisrICkKKyAgICAgICAgICAgICAgICB7Cisg
ICAgICAgICAgICAgICAgICAgIGJhcl9yZWcgPSBQQ0lfQkFTRV9BRERSRVNT
XzAgKyA0KmJhcjsKKyAgICAgICAgICAgICAgICAgICAgaWYgKCBiYXIgPT0g
NiApCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFyX3JlZyA9IFBD
SV9ST01fQUREUkVTUzsKKyAgICAgICAgICAgICAgICAgICAgLyogV2hlbiBm
aXJzdCB0aW1lIHJlYWQsIGl0IHdpbGwgcmV0dXJuIHBoeXNpY2FsIGFkZHJl
c3MgKi8KKyAgICAgICAgICAgICAgICAgICAgYmFyX2RhdGEgPSBwY2lfcmVh
ZGwoZGV2Zm4sIGJhcl9yZWcpOworICAgICAgICAgICAgICAgICAgICBwY2lf
d3JpdGVsKGRldmZuLCBiYXJfcmVnLCBiYXJfZGF0YSk7CisKKyAgICAgICAg
ICAgICAgICAgICAgLyogTm93IGVuYWJsZSB0aGUgbWVtb3J5IG9yIEkvTyBt
YXBwaW5nLiAqLworICAgICAgICAgICAgICAgICAgICBjbWQgPSBwY2lfcmVh
ZHcoZGV2Zm4sIFBDSV9DT01NQU5EKTsKKyAgICAgICAgICAgICAgICAgICAg
aWYgKCAoYmFyX3JlZyA9PSBQQ0lfUk9NX0FERFJFU1MpIHx8CisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgoYmFyX2RhdGEgJiBQQ0lfQkFTRV9B
RERSRVNTX1NQQUNFKSA9PQorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgUENJX0JBU0VfQUREUkVTU19TUEFDRV9NRU1PUlkpICkKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgY21kIHw9IFBDSV9DT01NQU5EX01FTU9SWTsK
KyAgICAgICAgICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgICAg
ICAgICAgICBjbWQgfD0gUENJX0NPTU1BTkRfSU87CisgICAgICAgICAgICAg
ICAgICAgIGNtZCB8PSBQQ0lfQ09NTUFORF9NQVNURVI7CisgICAgICAgICAg
ICAgICAgICAgIHBjaV93cml0ZXcoZGV2Zm4sIFBDSV9DT01NQU5ELCBjbWQp
OworICAgICAgICAgICAgICAgfQorCisgICAgICAgICAgICAgICAgLyogTWFw
IHRoZSBpbnRlcnJ1cHQuICovCisgICAgICAgICAgICAgICAgcGluID0gcGNp
X3JlYWRiKGRldmZuLCBQQ0lfSU5URVJSVVBUX1BJTik7CisgICAgICAgICAg
ICAgICAgaWYgKCBwaW4gIT0gMCApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiBUaGlzIGlzIHRoZSBiYXJiZXIncyBwb2xl
IG1hcHBpbmcgdXNlZCBieSBYZW4uICovCisgICAgICAgICAgICAgICAgICAg
IGxpbmsgPSAoKHBpbiAtIDEpICsgKGRldmZuID4+IDMpKSAmIDM7CisgICAg
ICAgICAgICAgICAgICAgIGlzYV9pcnEgPSBwY2lfcmVhZGIoUENJX0lTQV9E
RVZGTiwgMHg2MCArIGxpbmspOworICAgICAgICAgICAgICAgICAgICBwY2lf
d3JpdGViKGRldmZuLCBQQ0lfSU5URVJSVVBUX0xJTkUsIGlzYV9pcnEpOwor
ICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICBjb250aW51ZTsK
KwogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2UgMHgwNjgwOgog
ICAgICAgICAgICAgLyogUElJWDQgQUNQSSBQTS4gU3BlY2lhbCBkZXZpY2Ug
d2l0aCBzcGVjaWFsIFBDSSBjb25maWcgc3BhY2UuICovCkBAIC03NTAsOCAr
Nzg5LDEwIEBAIGludCBtYWluKHZvaWQpCiAgICAgICAgIGJyZWFrOwogICAg
IGNhc2UgVkdBX3B0OgogICAgICAgICBwcmludGYoIkxvYWRpbmcgVkdBQklP
UyBvZiBwYXNzdGhyb3VnaGVkIGdmeCAuLi5cbiIpOwotICAgICAgICB2Z2Fi
aW9zX3N6ID0KLSAgICAgICAgICAgIHJvdW5kX29wdGlvbl9yb20oKCoodWlu
dDhfdCAqKShWR0FCSU9TX1BIWVNJQ0FMX0FERFJFU1MrMikpICogNTEyKTsK
KyAgICAgICAgbWVtY3B5KCh2b2lkICopVkdBQklPU19QSFlTSUNBTF9BRERS
RVNTLAorICAgICAgICAgICAgICAgdmdhYmlvc19wdCwgc2l6ZW9mKHZnYWJp
b3NfcHQpKTsKKyAgICAgICAgKih1aW50OF90ICopKFZHQUJJT1NfUEhZU0lD
QUxfQUREUkVTUyArIHNpemVvZih2Z2FiaW9zX3B0KSkgPSBnZnhfYmRmOwor
ICAgICAgICB2Z2FiaW9zX3N6ID0gcm91bmRfb3B0aW9uX3JvbShzaXplb2Yo
dmdhYmlvc19wdCkgKyAxKTsKICAgICAgICAgYnJlYWs7CiAgICAgZGVmYXVs
dDoKICAgICAgICAgcHJpbnRmKCJObyBlbXVsYXRlZCBWR0EgYWRhcHRvciAu
Li5cbiIpOwo=

--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="03_dsdt.asl.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="03_dsdt.asl.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9h
Y3BpL2RzZHQuYXNsCTIwMTEtMTAtMjAgMTk6MDU6NDEuMDAwMDAwMDAwICsw
MjAwCisrKyB4ZW4tNC4xLjJfd29yay90b29scy9maXJtd2FyZS9odm1sb2Fk
ZXIvYWNwaS9kc2R0LmFzbAkyMDEyLTAxLTA3IDE0OjQ5OjI2LjAwMDAwMDAw
MCArMDEwMApAQCAtMTczLDE0ICsxNzMsNDIgQEAgRGVmaW5pdGlvbkJsb2Nr
ICgiRFNEVC5hbWwiLCAiRFNEVCIsIDIsCiAgICAgICAgICAgICAgICAgICAg
ICAgICAweDAwMDAwMDAwLAogICAgICAgICAgICAgICAgICAgICAgICAgMHgw
MDAyMDAwMCkKIAorICAgICAgICAgICAgICAgICAgICAvKiByZXNlcnZlIE1N
SU8gQkFScyBvZiBnZnggZm9yIDE6MSBtYXBwaW5nICovCiAgICAgICAgICAg
ICAgICAgICAgIERXb3JkTWVtb3J5KAogICAgICAgICAgICAgICAgICAgICAg
ICAgUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwgTWF4
Rml4ZWQsCiAgICAgICAgICAgICAgICAgICAgICAgICBDYWNoZWFibGUsIFJl
YWRXcml0ZSwKICAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAs
Ci0gICAgICAgICAgICAgICAgICAgICAgICAweEYwMDAwMDAwLAotICAgICAg
ICAgICAgICAgICAgICAgICAgMHhGNEZGRkZGRiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgIDB4RTAwMDAwMDAsCisgICAgICAgICAgICAgICAgICAgICAg
ICAweEVGRkZGRkZGLAogICAgICAgICAgICAgICAgICAgICAgICAgMHgwMDAw
MDAwMCwKLSAgICAgICAgICAgICAgICAgICAgICAgIDB4MDUwMDAwMDAsCisg
ICAgICAgICAgICAgICAgICAgICAgICAweDEwMDAwMDAwKQorCisgICAgICAg
ICAgICAgICAgICAgIERXb3JkTWVtb3J5KAorICAgICAgICAgICAgICAgICAg
ICAgICAgUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwg
TWF4Rml4ZWQsCisgICAgICAgICAgICAgICAgICAgICAgICBOb25DYWNoZWFi
bGUsIFJlYWRXcml0ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAw
MDAwMDAsCisgICAgICAgICAgICAgICAgICAgICAgICAweEMwMDAwMDAwLAor
ICAgICAgICAgICAgICAgICAgICAgICAgMHhDMUZGRkZGRiwKKyAgICAgICAg
ICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsCisgICAgICAgICAgICAgICAg
ICAgICAgICAweDAyMDAwMDAwKQorCisgICAgICAgICAgICAgICAgICAgIERX
b3JkTWVtb3J5KAorICAgICAgICAgICAgICAgICAgICAgICAgUmVzb3VyY2VQ
cm9kdWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwgTWF4Rml4ZWQsCisgICAg
ICAgICAgICAgICAgICAgICAgICBOb25DYWNoZWFibGUsIFJlYWRXcml0ZSwK
KyAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsCisgICAgICAg
ICAgICAgICAgICAgICAgICAweEMyMDAwMDAwLAorICAgICAgICAgICAgICAg
ICAgICAgICAgMHhDMkZGRkZGRiwKKyAgICAgICAgICAgICAgICAgICAgICAg
IDB4MDAwMDAwMDAsCisgICAgICAgICAgICAgICAgICAgICAgICAweDAxMDAw
MDAwKQorCisgICAgICAgICAgICAgICAgICAgIERXb3JkTWVtb3J5KAorICAg
ICAgICAgICAgICAgICAgICAgICAgUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVj
b2RlLCBNaW5GaXhlZCwgTWF4Rml4ZWQsCisgICAgICAgICAgICAgICAgICAg
ICAgICBDYWNoZWFibGUsIFJlYWRXcml0ZSwKKyAgICAgICAgICAgICAgICAg
ICAgICAgIDB4MDAwMDAwMDAsCisgICAgICAgICAgICAgICAgICAgICAgICAw
eEZCMDAwMDAwLAorICAgICAgICAgICAgICAgICAgICAgICAgMHhGQjA3RkZG
RiwKKyAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsCisgICAg
ICAgICAgICAgICAgICAgICAgICAweDAwMDgwMDAwLAogICAgICAgICAgICAg
ICAgICAgICAgICAgLCwgX1kwMSkKICAgICAgICAgICAgICAgICB9KQogCg==


--62747910-476652355-1325947349=:93467
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--62747910-476652355-1325947349=:93467--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 14:43:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 14: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 1RjXTk-00071r-IG; Sat, 07 Jan 2012 14:42:40 +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 1RjXTh-00071m-Vc
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 14:42:38 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-11.tower-216.messagelabs.com!1325947350!10002318!1
X-Originating-IP: [77.238.189.192]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 22769 invoked from network); 7 Jan 2012 14:42:30 -0000
Received: from nm16-vm0.bullet.mail.ird.yahoo.com (HELO
	nm16-vm0.bullet.mail.ird.yahoo.com) (77.238.189.192)
	by server-11.tower-216.messagelabs.com with SMTP;
	7 Jan 2012 14:42:30 -0000
Received: from [77.238.189.50] by nm16.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 14:42:30 -0000
Received: from [212.82.108.112] by tm3.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 14:42:30 -0000
Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 14:42:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 122402.63538.bm@omp1021.mail.ird.yahoo.com
Received: (qmail 7869 invoked by uid 60001); 7 Jan 2012 14:42:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325947349; bh=lBuN00ar1zZvVlHsFm1yPgepE4WM2IYULpi2BOymuDI=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=FY2i4EUEKWV8N9/P7p+JGIj1aYBxITleIV042t9FjS65LZPuvPC0HtZbGOv4tLyb7bUEp1RdQpK9N0viCFKQJXfe6Av2eGOvfkeYOVebEivcASeZufF7Mdhlt6stAHo58nFE1z9haid4ByWYrB9mT65zRETAVIGl1CsaCOPnqGI=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=VMANA5Yr+7BS/Y6blv5nrsuufJ22f19V4epcu61zrHSmEi7dOwZuamIGqXmOXjo3VP4R4WMyxefjFAxLgkZs644YcL7x98jymfZI793c6RcXdVmFiOUeVwf2vigqHpl27kJLgj5Z+ihDUky7yYsxQvBBjTOdsHKFvx/YEQsvE6M=;
X-YMail-OSG: LavNqasVM1mk9XS0ci2lVK8XT87Jak03znXmpTemu850zAN
	nDmp_MoDKaDFPGOYtqxNeSs2Zfe7sRw8HlancDEdOc06YOyDzYXQpA3sumnj
	OyYYgVYpudSHhWp3L2NbRdpHYP_BBMq.HjMeDygxaPlfWJsxaGKmJAwTQaW6
	CfEai9XYueMoerBzshAAb8RW1sihHa0r8_KCraiy6CM5UhyjDfZuQSwMTg2i
	Vzh0Fd0L4AH7h3QsuLgX1KZUn33ZPZRswIvi4KfH1S_7oJx9SIZiAwJ5ekO8
	_5PLI7JbpJh4_Gifj4ZrTP8xb_AxRPn3zc_DbAGg1Bv.x0RUsbZuq9dXJgAn
	nB2wZ6CpFT._aQiHpRdwX7d2D72n9DMFW3h3cHTJvXmRvovY9KB50_veCHju
	.9aeYG0cTNTaZ1XB5TTeJHhmty66FDWPxVJcrhQwlvVB6YeP1hojLy9nFLq.
	b4FrVyZf4kPl1uTkmUMpDeku9vWDTrkRbOmlt2yOFkeiq5R.YxTatLAGbCBd
	7WAswEPFf_0aZeaWUxskTBwMP_OZb6DrIQcTNU1ArYMtcLvW_itk7qMupoA- -
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 07 Jan 2012 14:42:29 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
	<1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
	<1325938952.14430.YahooMailNeo@web29805.mail.ird.yahoo.com>
Message-ID: <1325947349.93467.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 14:42:29 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: David TECHER <davidtecher@yahoo.fr>, -+= Lta =+- <lta@akr.fm>
In-Reply-To: <1325938952.14430.YahooMailNeo@web29805.mail.ird.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="62747910-476652355-1325947349=:93467"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Re :  Re :  Re : Re :  Secondary VGA Passthrough, nvidia,
	win7: success report.
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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--62747910-476652355-1325947349=:93467
Content-Type: multipart/alternative; boundary="62747910-870762312-1325947349=:93467"

--62747910-870762312-1325947349=:93467
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Attached=A0 are the=A0 updated Tobias patches for Xen 4.1.2.=0A=0AThe most =
important is 01_pass-through.patch that need to be updated :) else you rece=
ive a stupid error from compilation=0A=0A=0ASince I compiled kernel 3.1.6, =
without modules for Xen (=3DY), I have to remove 'xen-pci.passthough=3D1' f=
rom grub else I can not=A0 have my screen (stays black...)=0A=0A=0AI am doi=
ng my test on a new domU Windows 7.=0A=0AHope it will succeed :)=0A=0AI wil=
l let you know=0A=0A=0A=0A=0A=0A________________________________=0A De=A0: =
David TECHER <davidtecher@yahoo.fr>=0A=C0=A0: David TECHER <davidtecher@yah=
oo.fr>; -+=3D Lta =3D+- <lta@akr.fm> =0ACc=A0: "xen-devel@lists.xensource.c=
om" <xen-devel@lists.xensource.com> =0AEnvoy=E9 le : Samedi 7 Janvier 2012 =
13h22=0AObjet=A0: [Xen-devel] Re :  Re : Re :  Secondary VGA Passthrough, n=
vidia, win7: success report.=0A =0A=0AOk=0A=0AI think I understand what's w=
rong now :)=0A=0AInit build=0A=3D=3D=3D=3D=3D=3D=0A=0A=0Awget http://bits.x=
ensource.com/oss-xen/release/4.1.2/xen-4.1.2.tar.gz=0Atar xzf xen-4.1.2.tar=
.gz =0Acd xen-4.1.2/=0Acd tools/=0Amake =0Amake clean =0Acd ..=0A=0ADownloa=
d patches=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0Awget -q http://=
old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtIj4stRFbPo.txt=
 -O 01_pass-through.patch=0Awget -q http://old-list-archives.xen.org/archiv=
es/html/xen-devel/2010-05/txt06YdYEsi3S.txt -O 02_makefile.patch=0Awget -q=
=0A http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtS2w=
8cPgsnS.txt -O 03_dsdt.patch=0Awget -q http://old-list-archives.xen.org/arc=
hives/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader.patch=0Awget=
 -q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtiSI=
yxOHBZ8.txt -O 05_sound-makefile.patch=0A=0A=0AModify the first patch=0A=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0AReplace the path for =
the good path in the first patch 01_pass-through.patch=0A=0Ased -i "s:tools=
/ioemu-remote/hw/:tools/ioemu-qemu-xen/hw/:g" 01_pass-through.patch=0A=0AAp=
ply patches=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0A=0Aroot@mercury:/opt/t=
mp/xen-4.1.2# for file in $(ls 0*patch);do echo "######## PATCH =3D $file #=
###########";patch -p0 < $file;done=0A######## PATCH =3D 01_pass-through.pa=
tch ############=0Apatching file tools/ioemu-qemu-xen/hw/pass-through.c=0AH=
unk #1 succeeded at 22 with fuzz 2 (offset -1843 lines).=0AHunk #2 succeede=
d at 3312 (offset -55 lines).=0AHunk #3 succeeded at 3336 (offset -55 lines=
).=0AHunk #4 succeeded at 4335 with fuzz 2 (offset -144 lines).=0A######## =
PATCH =3D 02_makefile.patch ############=0Apatching file tools/firmware/hvm=
loader/Makefile=0A######## PATCH =3D 03_dsdt.patch ############=0Apatching =
file tools/firmware/hvmloader/acpi/dsdt.asl=0A######## PATCH =3D 04_hvmload=
er.patch ############=0Apatching file tools/firmware/hvmloader/hvmloader.c=
=0AHunk #1 succeeded at 116 (offset 1 line).=0AHunk #2 succeeded at 221 (of=
fset 1 line).=0AHunk #3 succeeded at 789 (offset 60 lines).=0A######## PATC=
H =3D 05_sound-makefile.patch ############=0Apatching file=0A tools/ioemu-r=
emote/xen-setup=0AHunk #1 FAILED at 16=0A=0AI will go on my tests and will =
let you know=0A=0AThanks=0A=0ADavid=0A=0A=0A_______________________________=
_=0A De=A0: David TECHER <davidtecher@yahoo.fr>=0A=C0=A0: -+=3D Lta =3D+- <=
lta@akr.fm> =0ACc=A0: "xen-devel@lists.xensource.com" <xen-devel@lists.xens=
ource.com> =0AEnvoy=E9 le : Samedi 7 Janvier 2012 13h04=0AObjet=A0: [Xen-de=
vel] Re : Re :  Secondary VGA Passthrough, nvidia, win7: success report.=0A=
 =0A=0AI tested xen 4.1.2 too.Tobias patches are the patches I've tested. I=
 am not very lucky.=0A=0A=0ASince you used Tobias patches as me, my questio=
n is - to be more precise - could you sent Tobias patches that you have mod=
ified in order to checking=0AI did not forget something as you. =0A=0A=0AMy=
 idea is that since I already have xen 4.2 installed, installing xen 4.1.2 =
over this , something wrong happens=0A=0A=0AMy screen stays like a black sc=
reen and nothing happens. no "gfx message" in the log.=0A=0AWith Xen 4.2 I =
tried aero desktop too but my domU crashes when=A0 I tried to activate aero=
.=0A=0A=0A=0A=0A________________________________=0A De=A0: -+=3D Lta =3D+- =
<lta@akr.fm>=0A=C0=A0: David TECHER <davidtecher@yahoo.fr> =0ACc=A0: xen-de=
vel@lists.xensource.com =0AEnvoy=E9 le : Samedi 7 Janvier 2012 3h17=0AObjet=
=A0: Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success =
report.=0A =0A=0AHi,=0A=0A=0AOn Fri, Jan 6, 2012 at 11:23 PM, David TECHER =
<davidtecher@yahoo.fr> wrote:=0A=0ACould you tell me what version of Xen? 4=
.1.0? 4.1.2?=0A=0AAs it is stated before this is a 4.1.2 version with debia=
n patches=0A=A0=0A=0A>=0A>By the way could you send your patches attached t=
o a mail so I could try?=0A=0A- There's also a link to tobias patche's on t=
he first post.=0A=A0=0A=0A>=0A>Test on Xen 4.2 failed (desktop stays to lag=
...)=0A=0AHave u tried to force windows to activate the aero desktop ?=0A=
=A0=0A=0A>=0A>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot bu=
t nothing appears on screen.=0A=0AI also followed tobias (same as yours) in=
structions to dump and build vgabios-pt.bin into xen, did u do it also ?=0A=
=A0=0A=0A>=0A>Strange.=0A>=0A>=0A>=0A>=0A>________________________________=
=0A> De=A0: -+=3D Lta =3D+- <lta@akr.fm>=0A>=C0=A0: xen-devel@lists.xensour=
ce.com =0A>Envoy=E9 le : Vendredi 6 Janvier 2012 17h48=0A>Objet=A0: [Xen-de=
vel] Secondary VGA Passthrough, nvidia, win7: success report.=0A>=0A>=0A>=
=0A>Hello xen-devel,=0A>=0A>=0A>=0A>=0A>This is my first post on this list =
and as such i might be breaking some explicit/implicit rules and i apologiz=
e if it's the case. Maybe this list isn't the exact=A0right=A0kind of place=
 where to post this kind of stuff, but i know lots of us are browsing this =
list as the primary source of documentation for xen.=0A>=0A>=0A>I've read m=
any times windows 7 isn't the right os to run on top of xen. Most of the gu=
y's who are running vga passthru are recommanding to use windows xp, and i'=
ve never seen any success report of vga passthru on windows 7 so i thought =
it was important to post mine.=0A>=0A>=0A>Anyway, here's my hardware setup =
:=0A>- Gigabyte GA-990X-UD3=0A>-=A0AMD Phenom II X6 1075T Processor=0A>- MS=
I Cyclone NVIDIA Geforce GTX 460=0A>=0A>=0A>On the software side i'm using =
:=0A>=0A>=0A>- Debian testing as Dom0=0A>- Xen-4.1 (debian version 4.1.2-2)=
 with what's now referred to as "Tobias Geiger patches" (http://old-list-ar=
chives.xen.org/archives/html/xen-devel/2010-05/msg00441.html) (You have to =
edit the patches, changing the path to some qemu source files for them to a=
pply)=0A>- debian's kernel =A03.1.5, compiled to include the pciback driver=
. Here's the output of `cat /boot/my3.1.5config | grep -i xen`=0A>CONFIG_XE=
N=3Dy=0A>CONFIG_XEN_DOM0=3Dy=0A>CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A>CONFIG_X=
EN_PVHVM=3Dy=0A>CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128=0A>CONFIG_XEN_SAVE_RESTO=
RE=3Dy=0A># CONFIG_XEN_DEBUG_FS is not set=0A># CONFIG_XEN_DEBUG is not set=
=0A>CONFIG_PCI_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKD=
EV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKDEV_BACKEND=3Dm=0A>CONFIG_NETXEN_NIC=3Dm=
=0A>CONFIG_XEN_NETDEV_FRONTEND=3Dm=0A>CONFIG_XEN_NETDEV_BACKEND=3Dm=0A>CONF=
IG_INPUT_XEN_KBDDEV_FRONTEND=3Dy=0A>CONFIG_HVC_XEN=3Dy=0A>CONFIG_XEN_WDT=3D=
m=0A>CONFIG_XEN_FBDEV_FRONTEND=3Dy=0A># Xen driver support=0A>CONFIG_XEN_BA=
LLOON=3Dy=0A># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=0A>CONFIG_XEN_S=
CRUB_PAGES=3Dy=0A>CONFIG_XEN_DEV_EVTCHN=3Dm=0A>CONFIG_XEN_BACKEND=3Dy=0A>CO=
NFIG_XENFS=3Dm=0A>CONFIG_XEN_COMPAT_XENFS=3Dy=0A>CONFIG_XEN_SYS_HYPERVISOR=
=3Dy=0A>CONFIG_XEN_XENBUS_FRONTEND=3Dy=0A>CONFIG_XEN_GNTDEV=3Dm=0A>CONFIG_X=
EN_GRANT_DEV_ALLOC=3Dm=0A>CONFIG_XEN_PLATFORM_PCI=3Dm=0A>CONFIG_SWIOTLB_XEN=
=3Dy=0A>CONFIG_XEN_PCIDEV_BACKEND=3Dy=0A>=0A>=0A>The kernel boot options ar=
e 'nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00=
.1)'=0A>=0A>=0A>- Here's my win7 domU config file :=0A>=0A>=0A>kernel =3D "=
/usr/lib/xen-4.1/boot/hvmloader"=0A>builder=3D'hvm'=0A>memory =3D 3072=0A>n=
ame =3D "w7"=0A>vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:16:3e:=
35:49:62']=0A>disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/a=
ppz,hdb,w']=0A>device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0A>boot=3D"d=
c"=0A>=0A>=0A>pci=3D['01:00.0','01:00.1']=0A>gfx_passthru=3D1=0A>=0A>=0A>vc=
pus=3D6=0A>acpi=3D1=0A>sdl=3D0=0A>vnc=3D1=0A>vncconsole=3D1=0A>vncpasswd=3D=
''=0A>serial=3D'pty'=0A>usbdevice=3D'tablet'=0A>pae=3D1=0A>pci_msitranslate=
=3D0=0A>pci_power_mgmt=3D0=0A>acpi_s3 =3D 1=0A>acpi_s4 =3D 1=0A>on_poweroff=
 =3D 'destroy'=0A>on_reboot =A0 =3D 'restart'=0A>on_crash =A0 =A0=3D 'resta=
rt'=0A>xen_platform_pci=3D1=0A>hpet =3D 1=0A>viridian=3D1=0A>monitor=3D1=0A=
>xen_extended_power_mgmt=3D2=0A>hpet=3D1=0A>=0A>=0A>What's important here f=
or the Nvidia drivers to work and not give a nice nvlddmkm.sys BSOD is:=0A>=
pci_msitranslate=3D0=0A>pci_power_mgmt=3D0=0A>=0A>=0A>- Windows 7 32bits=0A=
>- Nvidia drivers 275.33=0A>- You have to manually run aero speed test or f=
orce aero to start by using registry entries for the desktop not to be lagg=
y=0A>=0A>=0A>The windows 7 domU is running fine with no performance decreas=
e noticeable, although i've not yet played intensive gpu video game, i'm st=
ill pretty confident they'll run fine.=0A>=0A>=0A>Anyway. i've still some p=
roblems i shall report in separate posts :=0A>- The PCI bus topology isn't =
preserved, and the gfx card, which is plugged on 01:00 becomes 05:00 on dom=
U.=0A>- I'm passing through an RME Hdsp / hammerfall pci sound card to the =
domU and while it is working fine on his own, there's a strange interaction=
 between it and the GPLPV network driver. When i start playing sound, the n=
etwork instantly cease working. It starts back as soon as i stop playing au=
dio.=0A>=0A>=0A>That's all folks,=0A>=0A>=0A>Cheers,=0A>Lta=0A>=0A>=0A>____=
___________________________________________=0A>Xen-devel mailing list=0A>Xe=
n-devel@lists.xensource.com=0A>http://lists.xensource.com/xen-devel=0A>=0A>=
=0A>=0A=0A=0A=0A_______________________________________________=0AXen-devel=
 mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensource.com/=
xen-devel=0A=0A=0A=0A_______________________________________________=0AXen-=
devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensource=
.com/xen-devel
--62747910-870762312-1325947349=:93467
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>Attached&n=
bsp; are the&nbsp; updated Tobias patches for Xen 4.1.2.</span></div><div><=
br><span></span></div><div><span>The most important is 01_pass-through.patc=
h that need to be updated :) else you receive a stupid error from compilati=
on<br></span></div><div><br><span></span></div><div><span>Since I compiled =
kernel 3.1.6, without modules for Xen (=3DY), I have to remove 'xen-pci.pas=
sthough=3D1' from grub else I can not&nbsp; have my screen (stays black...)=
<br></span></div><div><br><span></span></div><div><span>I am doing my test =
on a new domU Windows 7.</span></div><div><br><span></span></div><div><span=
>Hope it will succeed :)</span></div><div><br><span></span></div><div><span=
>I will let you know<br></span></div><div><br><span></span></div><div><span=
><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-famil=
y: 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> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><sp=
an style=3D"font-weight: bold;">=C0&nbsp;:</span></b> David TECHER &lt;davi=
dtecher@yahoo.fr&gt;; -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span style=
=3D"font-weight: bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xensource.com=
" &lt;xen-devel@lists.xensource.com&gt; <br> <b><span style=3D"font-weight:=
 bold;">Envoy=E9 le :</span></b> Samedi 7 Janvier 2012 13h22<br> <b><span s=
tyle=3D"font-weight: bold;">Objet&nbsp;:</span></b> [Xen-devel] Re :  Re : =
Re :  Secondary VGA Passthrough, nvidia, win7: success report.<br> </font> =
<br><div id=3D"yiv1764174381"><div><div style=3D"color:#000;background-colo=
r:#fff;font-family:times new roman, new york, times,
 serif;font-size:12pt;"><div><span>Ok</span></div><div><br><span></span></d=
iv><div><span>I think I understand what's wrong now :)</span></div><div><br=
><span></span></div><div>Init build</div><div>=3D=3D=3D=3D=3D=3D<br></div><=
div><br><span></span></div><div><span>wget http://bits.xensource.com/oss-xe=
n/release/4.1.2/xen-4.1.2.tar.gz<br>tar xzf xen-4.1.2.tar.gz <br>cd xen-4.1=
.2/<br>cd tools/<br>make <br>make clean <br>cd ..</span></div><div><span><b=
r></span></div><div><span>Download patches<br></span></div><div><span>=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></div><div><span>wget -q htt=
p://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtIj4stRFbPo=
.txt -O 01_pass-through.patch<br>wget -q http://old-list-archives.xen.org/a=
rchives/html/xen-devel/2010-05/txt06YdYEsi3S.txt -O 02_makefile.patch<br>wg=
et -q=0A http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/t=
xtS2w8cPgsnS.txt -O 03_dsdt.patch<br>wget -q http://old-list-archives.xen.o=
rg/archives/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader.patch<=
br>wget -q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05=
/txtiSIyxOHBZ8.txt -O 05_sound-makefile.patch<br></span></div><div><br><spa=
n></span></div><div><span>Modify the first patch</span></div><div><span>=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></div><div><span><b=
r></span></div><div><span>Replace the path for the good path in the first p=
atch </span><span>01_pass-through.patch</span></div><div><span><br></span><=
/div><div><span>sed -i "s:tools/ioemu-remote/hw/:tools/ioemu-qemu-xen/hw/:g=
" 01_pass-through.patch</span></div><div><br><span></span></div><div><span>=
Apply patches</span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></sp=
an></div><div><span><br></span></div><div><span><br></span></div><div><span=
>root@mercury:/opt/tmp/xen-4.1.2# for file in $(ls=0A 0*patch);do echo "###=
##### PATCH =3D $file ############";patch -p0 &lt; $file;done<br>######## P=
ATCH =3D 01_pass-through.patch ############<br>patching file tools/ioemu-qe=
mu-xen/hw/pass-through.c<br>Hunk #1 succeeded at 22 with fuzz 2 (offset -18=
43 lines).<br>Hunk #2 succeeded at 3312 (offset -55 lines).<br>Hunk #3 succ=
eeded at 3336 (offset -55 lines).<br>Hunk #4 succeeded at 4335 with fuzz 2 =
(offset -144 lines).<br>######## PATCH =3D 02_makefile.patch ############<b=
r>patching file tools/firmware/hvmloader/Makefile<br>######## PATCH =3D 03_=
dsdt.patch ############<br>patching file tools/firmware/hvmloader/acpi/dsdt=
.asl<br>######## PATCH =3D 04_hvmloader.patch ############<br>patching file=
 tools/firmware/hvmloader/hvmloader.c<br>Hunk #1 succeeded at 116 (offset 1=
 line).<br>Hunk #2 succeeded at 221 (offset 1 line).<br>Hunk #3 succeeded a=
t 789 (offset 60 lines).<br>######## PATCH =3D 05_sound-makefile.patch ####=
########<br>patching file=0A tools/ioemu-remote/xen-setup<br>Hunk #1 FAILED=
 at 16</span></div><div><br><span></span></div><div><span>I will go on my t=
ests and will let you know</span></div><div><br><span></span></div><div><sp=
an>Thanks</span></div><div><br><span></span></div><div><span>David</span></=
div><div><br></div>  <div style=3D"font-family:times new roman, new york, t=
imes, serif;font-size:12pt;"> <div style=3D"font-family:times new roman, ne=
w 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> Dav=
id TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><span style=3D"font-weight:bo=
ld;">=C0&nbsp;:</span></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span =
style=3D"font-weight:bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xensource=
.com" &lt;xen-devel@lists.xensource.com&gt; <br> <b><span style=3D"font-wei=
ght:bold;">Envoy=E9 le :</span></b> Samedi 7 Janvier 2012 13h04<br> <b><spa=
n style=3D"=0Afont-weight:bold;">Objet&nbsp;:</span></b> [Xen-devel] Re : R=
e :  Secondary VGA Passthrough, nvidia, win7: success report.<br> </font> <=
br><div id=3D"yiv1764174381"><div><div style=3D"color:#000;background-color=
:#fff;font-family:times new roman, new york, times, serif;font-size:12pt;">=
<div><span>I tested xen 4.1.2 too.</span><span> Tobias patches are the patc=
hes I've tested. I am not very lucky.<br></span></div><div><span><br></span=
></div><div><span>Since you used Tobias patches as me, my question is - to =
be more precise - could you sent Tobias patches that you have modified in o=
rder to checking</span></div><div><span>I did not forget something as you. =
<br></span></div><div><br><span></span></div><div><span>My idea is that sin=
ce I already have xen 4.2 installed, installing xen 4.1.2 over this , somet=
hing wrong happens<br></span></div><div><br><span></span></div><div><span>M=
y screen stays like a black screen and nothing happens. no "gfx message" in=
 the=0A log.</span></div><div><br><span></span></div><div><span>With Xen 4.=
2 I tried aero desktop too but my domU crashes when&nbsp; I tried to activa=
te=0A aero.<br></span></div><div><br><span></span></div><div><span></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, n=
ew york, times, serif;font-size:12pt;"> <font face=3D"Arial" size=3D"2"> <h=
r size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -+=
=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight:bold;">=
=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><spa=
n style=3D"font-weight:bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensourc=
e.com <br> <b><span style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Sa=
medi 7 Janvier 2012 3h17<br> <b><span style=3D"font-weight:bold;">Objet&nbs=
p;:</span></b> Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7=
: success report.<br> </font> <br><div id=3D"yiv1764174381">Hi,<br><br><div=
 class=3D"yiv1764174381gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, David =
TECHER <span dir=3D"ltr">&lt;<a
 rel=3D"nofollow" ymailto=3D"mailto:davidtecher@yahoo.fr" target=3D"_blank"=
 href=3D"mailto:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>&gt;</span> w=
rote:<br><blockquote class=3D"yiv1764174381gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D=
"font-size:12pt;font-family:times new roman, new york, times, serif;"><div>=
<span>Could you tell me what version of Xen? 4.1.0? 4.1.2?</span></div></di=
v></div></blockquote><div><br></div><div>As it is stated before this is a 4=
.1.2 version with debian patches</div>=0A<div>&nbsp;</div><blockquote class=
=3D"yiv1764174381gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex;"><div><div style=3D"font-size:12pt;font-family:t=
imes new roman, new york, times, serif;"><div><br><span></span></div>=0A<di=
v><span>By the way could you send your patches attached to a mail so I coul=
d try?</span></div></div></div></blockquote><div><br></div><div>- There's a=
lso a link to tobias patche's on the first post.</div><div>&nbsp;</div>=0A<=
blockquote class=3D"yiv1764174381gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;"><div><div style=3D"font-size:12=
pt;font-family:times new roman, new york, times, serif;"><div><br><span></s=
pan></div><div><span>Test on Xen 4.2 failed (desktop stays to lag...)</span=
></div>=0A</div></div></blockquote><div><br></div><div>Have u tried to forc=
e windows to activate the aero desktop ?</div><div>&nbsp;</div><blockquote =
class=3D"yiv1764174381gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size:12pt;font-=
family:times new roman, new york, times, serif;"><div><br><span></span></di=
v><div><span>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but=
 nothing appears on screen.</span></div>=0A</div></div></blockquote><div><b=
r></div><div>I also followed tobias (same as yours) instructions to dump an=
d build vgabios-pt.bin into xen, did u do it also ?</div><div>&nbsp;</div><=
blockquote class=3D"yiv1764174381gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size=
:12pt;font-family:times new roman, new york, times, serif;"><div><br><span>=
</span></div><div><span>Strange.<br></span></div><div><br></div>  <div styl=
e=3D"font-family:times new roman, new york, times, serif;font-size:12pt;">=
=0A <div style=3D"font-family:times new roman, new york, times, serif;font-=
size:12pt;"> <font face=3D"Arial"><div class=3D"yiv1764174381im"> <hr size=
=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -+=3D Lt=
a =3D+- &lt;<a rel=3D"nofollow" ymailto=3D"mailto:lta@akr.fm" target=3D"_bl=
ank" href=3D"mailto:lta@akr.fm">lta@akr.fm</a>&gt;<br>=0A </div><b><span st=
yle=3D"font-weight:bold;">=C0&nbsp;:</span></b> <a rel=3D"nofollow" ymailto=
=3D"mailto:xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mailto:=
xen-devel@lists.xensource.com">xen-devel@lists.xensource.com</a> <br> <b><s=
pan style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Vendredi 6 Janvier=
 2012 17h48<br>=0A <b><span style=3D"font-weight:bold;">Objet&nbsp;:</span>=
</b> [Xen-devel] Secondary VGA Passthrough, nvidia, win7: success report.<b=
r> </font><div><div class=3D"yiv1764174381h5"> <br><div><div>Hello xen-deve=
l,<div><br></div><div><br></div><div>=0AThis is my first post on this list =
and as such i might be breaking some explicit/implicit rules and i apologiz=
e if it's the case. Maybe this list isn't the exact&nbsp;right&nbsp;kind of=
 place where to post this kind of stuff, but i know lots of us are browsing=
 this list as the primary source of documentation for xen.</div>=0A=0A=0A<d=
iv><br></div><div>I've read many times windows 7 isn't the right os to run =
on top of xen. Most of the guy's who are running vga passthru are recommand=
ing to use windows xp, and i've never seen any success report of vga passth=
ru on windows 7 so i thought it was important to post mine.</div>=0A=0A=0A<=
div><br></div><div>Anyway, here's my hardware setup :</div><div>- Gigabyte =
GA-990X-UD3</div><div>-&nbsp;AMD Phenom II X6 1075T Processor</div><div>- M=
SI Cyclone NVIDIA Geforce GTX 460</div><div><br></div><div>On the software =
side i'm using :</div>=0A=0A=0A<div><br></div><div>- Debian testing as Dom0=
</div><div>- Xen-4.1 (debian version 4.1.2-2) with what's now referred to a=
s "Tobias Geiger patches" (<a rel=3D"nofollow" target=3D"_blank" href=3D"ht=
tp://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.htm=
l">http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg0044=
1.html</a>) (You have to edit the patches, changing the path to some qemu s=
ource files for them to apply)</div>=0A=0A=0A<div>- debian's kernel &nbsp;3=
.1.5, compiled to include the pciback driver. Here's the output of `cat /bo=
ot/my3.1.5config | grep -i xen`</div><div><div><font size=3D"1">CONFIG_XEN=
=3Dy</font></div><div>=0A<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><=
div><font size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><font size=3D"1">CONFI=
G_XEN_MAX_DOMAIN_MEMORY=3D128</font></div><div><font size=3D"1">CONFIG_XEN_=
SAVE_RESTORE=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_DEBUG_FS is=
 not set</font></div>=0A<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set=
</font></div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><fon=
t size=3D"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CON=
FIG_XEN_BLKDEV_BACKEND=3Dm</font></div><div><font size=3D"1">CONFIG_NETXEN_=
NIC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm=
</font></div><div><font size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></di=
v><div><font size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>=
=0A<div><font size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"=
1">CONFIG_XEN_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FR=
ONTEND=3Dy</font></div>=0A<div><font size=3D"1"># Xen driver support</font>=
</div><div><font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font></div><div><font s=
ize=3D"1"># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set</font></div>=0A<di=
v><font size=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font size=
=3D"1">CONFIG_XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_X=
EN_BACKEND=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_XENFS=3Dm</font>=
</div><div><font size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_XENBUS_FRONTEND=3Dy</font></div><div><font size=3D"1">CON=
FIG_XEN_GNTDEV=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_GRANT_DEV_A=
LLOC=3Dm</font></div>=0A<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</=
font></div><div><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><f=
ont size=3D"1">CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=0A</div><div><fon=
t size=3D"1"><br></font></div><div>The kernel boot options are 'nomodeset x=
en-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'</div><div=
><br></div><div>- Here's my win7 domU config file :</div>=0A=0A=0A<div><br>=
</div><div><div><font size=3D"1">kernel =3D "/usr/lib/xen-4.1/boot/hvmloade=
r"</font></div><div><font size=3D"1">builder=3D'hvm'</font></div><div><font=
 size=3D"1">memory =3D 3072</font></div>=0A<div><font size=3D"1">name =3D "=
w7"</font></div><div><font size=3D"1">vif =3D [ 'type=3Dnetfront,bridge=3Dx=
enbr0, mac=3D00:16:3e:35:49:62']</font></div><div><font size=3D"1">disk =3D=
 [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']</font></di=
v>=0A=0A=0A<div><font size=3D"1">device_model =3D '/usr/lib/xen-4.1/bin/qem=
u-dm'</font></div><div><font size=3D"1">boot=3D"dc"</font></div><div><font =
size=3D"1"><br>=0A</font></div><div><font size=3D"1">pci=3D['01:00.0','01:0=
0.1']</font></div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><=
font size=3D"1"><br>=0A</font></div><div><font size=3D"1">vcpus=3D6</font><=
/div><div><font size=3D"1">acpi=3D1</font></div><div><font size=3D"1">sdl=
=3D0</font></div><div><font size=3D"1">vnc=3D1</font></div>=0A<div><font si=
ze=3D"1">vncconsole=3D1</font></div><div><font size=3D"1">vncpasswd=3D''</f=
ont></div><div><font size=3D"1">serial=3D'pty'</font></div>=0A<div><font si=
ze=3D"1">usbdevice=3D'tablet'</font></div><div><font size=3D"1">pae=3D1</fo=
nt></div><div><font size=3D"1">pci_msitranslate=3D0</font></div>=0A<div><fo=
nt size=3D"1">pci_power_mgmt=3D0</font></div><div><font size=3D"1">acpi_s3 =
=3D 1</font></div><div><font size=3D"1">acpi_s4 =3D 1</font></div><div><fon=
t size=3D"1">on_poweroff =3D 'destroy'</font></div>=0A<div><font size=3D"1"=
>on_reboot &nbsp; =3D 'restart'</font></div><div><font size=3D"1">on_crash =
&nbsp; &nbsp;=3D 'restart'</font></div><div><font size=3D"1">xen_platform_p=
ci=3D1</font></div>=0A<div><font size=3D"1">hpet =3D 1</font></div><div><fo=
nt size=3D"1">viridian=3D1</font></div><div><font size=3D"1">monitor=3D1</f=
ont></div><div><font size=3D"1">xen_extended_power_mgmt=3D2</font></div>=0A=
<div><font size=3D"1">hpet=3D1</font></div></div><div><br></div><div>What's=
 important here for the Nvidia drivers to work and not give a nice nvlddmkm=
.sys BSOD is:</div><div><div><font size=3D"1">pci_msitranslate=3D0</font></=
div>=0A=0A=0A<div><font size=3D"1">pci_power_mgmt=3D0</font></div></div><di=
v><font size=3D"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvi=
dia drivers 275.33</div><div>- You have to manually run aero speed test or =
force aero to start by using registry entries for the desktop not to be lag=
gy</div>=0A=0A=0A<div><br></div><div>The windows 7 domU is running fine wit=
h no performance decrease noticeable, although i've not yet played intensiv=
e gpu video game, i'm still pretty confident they'll run fine.</div><div><b=
r>=0A=0A=0A</div><div>Anyway. i've still some problems i shall report in se=
parate posts :</div><div>- The PCI bus topology isn't preserved, and the gf=
x card, which is plugged on 01:00 becomes 05:00 on domU.</div><div>- I'm pa=
ssing through an RME Hdsp / hammerfall pci sound card to the domU and while=
 it is working fine on his own, there's a strange interaction between it an=
d the GPLPV network driver. When i start playing sound, the network instant=
ly cease working. It starts back as soon as i stop playing audio.</div>=0A=
=0A=0A<div><br></div><div>That's all folks,</div><div><br></div><div>Cheers=
,</div><div>Lta</div>=0A</div><br>=0A</div><br></div></div><div class=3D"yi=
v1764174381im">_______________________________________________<br>Xen-devel=
 mailing list<br><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.xens=
ource.com" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.com">=
Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow" target=3D"_blank" =
href=3D"http://lists.xensource.com/xen-devel">http://lists.xensource.com/xe=
n-devel</a><br>=0A<br><br> </div></div> </div>  </div></div></blockquote></=
div><br>=0A</div><br><br> </div> </div>  </div></div></div><br>____________=
___________________________________<br>Xen-devel mailing list<br><a rel=3D"=
nofollow" ymailto=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank=
" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.c=
om</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensou=
rce.com/xen-devel">http://lists.xensource.com/xen-devel</a><br><br><br> </d=
iv> </div>  </div></div></div><br>_________________________________________=
______<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-devel@lists.xe=
nsource.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" targe=
t=3D"_blank">http://lists.xensource.com/xen-devel</a><br><br><br> </div> </=
div>  </div></body></html>
--62747910-870762312-1325947349=:93467--
--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="01_pass-through.c.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="01_pass-through.c.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2lvZW11LXFlbXUteGVuL2h3L3Bh
c3MtdGhyb3VnaC5jCTIwMTEtMDItMTEgMTg6NTQ6NTEuMDAwMDAwMDAwICsw
MTAwCisrKyB4ZW4tNC4xLjJfd29yay90b29scy9pb2VtdS1xZW11LXhlbi9o
dy9wYXNzLXRocm91Z2guYwkyMDEyLTAxLTA3IDE0OjM3OjU1LjAwMDAwMDAw
MCArMDEwMApAQCAtMTE1LDYgKzExNSw3OSBAQCBzdHJ1Y3QgZHBjaV9pbmZv
cyB7CiAKIGNoYXIgbWFwcGVkX21hY2hpbmVfaXJxW1BUX05SX0lSUVNdID0g
ezB9OwogCisgI2RlZmluZSBQQ0lfSEVBREVSX1RZUEVfQUREUiAgICAgICAg
MHgwZQorICNkZWZpbmUgUENJX0JSSURHRV9GTEFHICAgICAgICAgICAgIDB4
MDEKKyAKKyAjZGVmaW5lIFBDSV9DTEFTU19DT0RFX0FERFJfMCAgICAgICAw
eDA5CisgI2RlZmluZSBQQ0lfQ0xBU1NfQ09ERV9BRERSXzEgICAgICAgMHgw
YQorICNkZWZpbmUgUENJX0NMQVNTX0NPREVfQUREUl8yICAgICAgIDB4MGIK
KyAjZGVmaW5lIFBDSV9DTEFTU19DT0RFX0RBVEFfMCAgICAgICAweDA2MDAw
MAorICNkZWZpbmUgUENJX0NMQVNTX0NPREVfREFUQV8xICAgICAgIDB4MDYw
MAorICNkZWZpbmUgUENJX0NMQVNTX0NPREVfREFUQV8yICAgICAgIDB4MDYK
KyAKKyAjZGVmaW5lIFBDSV9TRUNPTkRfQlVTX05VTUJFUl9BRERSICAweDE5
CisgCisgI2RlZmluZSBQQ0lfQlJJREdFX0NPTlRST0xfQUREUiAgICAgMHgz
ZQorICNkZWZpbmUgUENJX0JSSURHRV9WR0FfRU5BQkxFICAgICAgIDB4MTgK
KyAKKyAjZGVmaW5lIFBDSV9HUkFQSElDX0NPTlRST0xfQUREUiAgICAweDUy
CisgI2RlZmluZSBQQ0lfSE9TVF9CUklER0VfSUdEX1ZHQV9ESVNBQkxFIDB4
MDIKKyAKKyBzdGF0aWMgdWludDMyX3QgZ2Z4X2NsYWltX3ZnYV9jeWNsZShz
dHJ1Y3QgcGNpX2FjY2VzcyAqcGNpX2FjY2VzcywgIHVpbnQzMl90IGJ1cywg
dWludDMyX3QgZGV2Zm4sIHVpbnQzMl90IGZ1bmMpOworIAorIAorIC8qCisg
ICogQ2xhaW0gdmdhIGN5Y2xlIGZvciB0aGUgZ3JhcGhpY3MgY2FyZCBwYXNz
LXRocm91Z2gKKyAgKi8KKyBzdGF0aWMgdWludDMyX3QgZ2Z4X2NsYWltX3Zn
YV9jeWNsZShzdHJ1Y3QgcGNpX2FjY2VzcyAqcGNpX2FjY2VzcywKKyAgICAg
ICAgdWludDMyX3QgYnVzLCB1aW50MzJfdCBkZXZmbiwgdWludDMyX3QgZnVu
YykKKyB7CisgICAgIHN0cnVjdCBwY2lfZGV2ICpwY2lfZGV2OworIAorICAg
ICBmb3IgKCBwY2lfZGV2ID0gcGNpX2FjY2Vzcy0+ZGV2aWNlczsgcGNpX2Rl
diAhPSBOVUxMOyBwY2lfZGV2ID0gcGNpX2Rldi0+bmV4dCApCisgICAgIHsK
KyAgICAgICAgIC8qIENoZWNrIHdoZXRoZXIgdGhpcyBpcyBhIG9yZGluYXJ5
IGJyaWRnZSAqLworICAgICAgICAgaWYgKCBwY2lfcmVhZF9ieXRlKHBjaV9k
ZXYsIFBDSV9IRUFERVJfVFlQRV9BRERSKSA9PSBQQ0lfQlJJREdFX0ZMQUcg
KQorICAgICAgICAgeworICAgICAgICAgICAgIHVuc2lnbmVkIHNlY19idXNf
bnVtID0gcGNpX3JlYWRfYnl0ZShwY2lfZGV2LCBQQ0lfU0VDT05EX0JVU19O
VU1CRVJfQUREUik7CisgICAgICAgICAgICAgdW5zaWduZWQgdWJyZyA9IHBj
aV9yZWFkX2J5dGUocGNpX2RldiwgUENJX0JSSURHRV9DT05UUk9MX0FERFIp
OworIAorICAgICAgICAgICAgIFBUX0xPRygiYnJpZGdlIGZvciBidXMgJWQs
IHByZXZpb3VzIGJyaWRnZSBjb250cm9sIGlzICV4XG4iLCBzZWNfYnVzX251
bSwgdWJyZyk7CisgICAgICAgICAgICAgUFRfTE9HKCJidXM9MHglZCwgZGV2
PTB4JXgsIGZ1bmM9MHgleFxuIixwY2lfZGV2LT5idXMscGNpX2Rldi0+ZGV2
LHBjaV9kZXYtPmZ1bmMpOworIAorICAgICAgICAgICAgIGlmICggc2VjX2J1
c19udW0gPT0gYnVzICkgLyogVkdBIGRldmljZSdzIGJyaWRnZSAqLworICAg
ICAgICAgICAgICAgICB1YnJnIHw9IFBDSV9CUklER0VfVkdBX0VOQUJMRTsK
KyAgICAgICAgICAgICBlbHNlIC8qIE90aGVyIGRldmljZSdzIGJyaWRnZSAq
LworICAgICAgICAgICAgICAgICB1YnJnICY9IH5QQ0lfQlJJREdFX1ZHQV9F
TkFCTEU7CisgCisgICAgICAgICAgICAgcGNpX3dyaXRlX2J5dGUocGNpX2Rl
diwgUENJX0JSSURHRV9DT05UUk9MX0FERFIsIHVicmcpOworICAgICAgICAg
ICAgIFBUX0xPRygiYnJpZGdlIGZvciBidXMgJWQsIHVwZGF0ZWQgYnJpZGdl
IGNvbnRyb2wgaXMgJXhcbiIsIHNlY19idXNfbnVtLCB1YnJnKTsKKyAgICAg
ICAgIH0KKyAgICAgfQorIAorICAgICBmb3IgKCBwY2lfZGV2ID0gcGNpX2Fj
Y2Vzcy0+ZGV2aWNlczsgcGNpX2RldiAhPSBOVUxMOyBwY2lfZGV2ID0gcGNp
X2Rldi0+bmV4dCApCisgICAgIHsKKyAgICAgICAgIC8qIENoZWNrIGhvc3Qg
YnJpZGdlICovCisgICAgICAgICBpZiAoIHBjaV9yZWFkX3dvcmQocGNpX2Rl
diwgUENJX0NMQVNTX0NPREVfQUREUl8xKSA9PSBQQ0lfQ0xBU1NfQ09ERV9E
QVRBXzEgKQorICAgICAgICAgeworICAgICAgICAgICAgIHVuc2lnbmVkIHVp
Z2QgPSBwY2lfcmVhZF9ieXRlKHBjaV9kZXYsIFBDSV9HUkFQSElDX0NPTlRS
T0xfQUREUik7CisgCisgICAgICAgICAgICAgUFRfTE9HKCJwcmV2aW91cyBp
Z2QgY29udHJvbCBpcyAleFxuIiwgdWlnZCk7CisgCisgICAgICAgICAgICAg
aWYgKCBidXMgPT0gMCApCisgICAgICAgICAgICAgICAgIHVpZ2QgJj0gflBD
SV9IT1NUX0JSSURHRV9JR0RfVkdBX0RJU0FCTEU7CisgICAgICAgICAgICAg
ZWxzZQorICAgICAgICAgICAgICAgICB1aWdkIHw9IFBDSV9IT1NUX0JSSURH
RV9JR0RfVkdBX0RJU0FCTEU7CisgCisgICAgICAgICAgICAgcGNpX3dyaXRl
X2J5dGUocGNpX2RldiwgUENJX0dSQVBISUNfQ09OVFJPTF9BRERSLCB1aWdk
KTsKKyAgICAgICAgICAgICBQVF9MT0coInVwZGF0ZWQgaWdkIGNvbnRyb2wg
aXMgJXhcbiIsIHVpZ2QpOworICAgICAgICAgfQorICAgICB9CisgCisgICAg
IHJldHVybiAwOworIH0KKworCiAvKiBwcm90b3R5cGUgKi8KIHN0YXRpYyB1
aW50MzJfdCBwdF9jb21tb25fcmVnX2luaXQoc3RydWN0IHB0X2RldiAqcHRk
ZXYsCiAgICAgc3RydWN0IHB0X3JlZ19pbmZvX3RibCAqcmVnLCB1aW50MzJf
dCByZWFsX29mZnNldCk7CkBAIC0zMjQzLDYgKzMzMTYsOCBAQCBzdGF0aWMg
aW50IHB0X2NtZF9yZWdfcmVhZChzdHJ1Y3QgcHRfZGV2CiB9CiAKIC8qIHJl
YWQgQkFSICovCitzdGF0aWMgaW50IGdmeF9maXJzdF9yZWFkX0JBUls3XSA9
IHsxLCAxLCAxLCAxLCAxLCAxLCAxfTsKKwogc3RhdGljIGludCBwdF9iYXJf
cmVnX3JlYWQoc3RydWN0IHB0X2RldiAqcHRkZXYsCiAgICAgICAgIHN0cnVj
dCBwdF9yZWdfdGJsICpjZmdfZW50cnksCiAgICAgICAgIHVpbnQzMl90ICp2
YWx1ZSwgdWludDMyX3QgdmFsaWRfbWFzaykKQEAgLTMyNjUsNiArMzM0MCwx
NyBAQCBzdGF0aWMgaW50IHB0X2Jhcl9yZWdfcmVhZChzdHJ1Y3QgcHRfZGV2
CiAgICAgLyogdXNlIGZpeGVkLXVwIHZhbHVlIGZyb20ga2VybmVsIHN5c2Zz
ICovCiAgICAgKnZhbHVlID0gcHRkZXYtPnBjaV9kZXYtPmJhc2VfYWRkcltp
bmRleF07CiAKKyAgICBpZiAoIHB0ZGV2LT5wY2lfZGV2LT5kZXZpY2VfY2xh
c3MgPT0gMHgzMDAgKQorICAgIHsKKyAgICAgICAgaWYgKCBnZnhfZmlyc3Rf
cmVhZF9CQVJbaW5kZXhdID09IDEgKQorICAgICAgICB7CisgICAgICAgICAg
ICBnZnhfZmlyc3RfcmVhZF9CQVJbaW5kZXhdID0gMDsKKyAgICAgICAgICAg
IFBUX0xPRygiZmlyc3QgcmVhZCBCQVJzIG9mIGdmeFxuIik7CisgICAgICAg
ICAgICByZXR1cm4gMDsKKyAgICAgICAgfQorICAgIH0KKworCiAgICAgLyog
c2V0IGVtdWxhdGUgbWFzayBkZXBlbmQgb24gQkFSIGZsYWcgKi8KICAgICBz
d2l0Y2ggKHB0ZGV2LT5iYXNlc1tpbmRleF0uYmFyX2ZsYWcpCiAgICAgewpA
QCAtNDI1Myw2ICs0MzM5LDEzIEBAIHN0YXRpYyBzdHJ1Y3QgcHRfZGV2ICog
cmVnaXN0ZXJfcmVhbF9kZXYKICAgICB9CiAKIAorICAgIGlmICggcGNpX2Rl
di0+ZGV2aWNlX2NsYXNzID09IDB4MDMwMCApCisgICAgeworICAgICAgICBy
YyA9IGdmeF9jbGFpbV92Z2FfY3ljbGUocGNpX2FjY2Vzcywgcl9idXMsIHJf
ZGV2LCByX2Z1bmMpOworICAgICAgICBpZiAoIHJjICE9IDAgKQorICAgICAg
ICAgICAgcmV0dXJuIE5VTEw7CisgICAgfQorCiAgICAgLyogcmVpbml0aWFs
aXplIGVhY2ggY29uZmlnIHJlZ2lzdGVyIHRvIGJlIGVtdWxhdGVkICovCiAg
ICAgcmMgPSBwdF9jb25maWdfaW5pdChhc3NpZ25lZF9kZXZpY2UpOwogICAg
IGlmICggcmMgPCAwICkgewo=

--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="02_Makefile.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="02_Makefile.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9N
YWtlZmlsZQkyMDExLTEwLTIwIDE5OjA1OjQxLjAwMDAwMDAwMCArMDIwMAor
KysgeGVuLTQuMS4yX3dvcmsvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVyL01h
a2VmaWxlCTIwMTItMDEtMDcgMTQ6MTk6NDguMDAwMDAwMDAwICswMTAwCkBA
IC01MCw2ICs1MCw3IEBAIGh2bWxvYWRlcjogJChPQkpTKSBhY3BpL2FjcGku
YQogcm9tcy5oOiAuLi9yb21iaW9zL0JJT1MtYm9jaHMtbGF0ZXN0IC4uL3Zn
YWJpb3MvVkdBQklPUy1sZ3BsLWxhdGVzdC5iaW4gXAogCS4uL3ZnYWJpb3Mv
VkdBQklPUy1sZ3BsLWxhdGVzdC5jaXJydXMuYmluIC4uL2V0aGVyYm9vdC9l
Yi1yb21zLmgKIAlzaCAuL21raGV4IHJvbWJpb3MgLi4vcm9tYmlvcy9CSU9T
LWJvY2hzLWxhdGVzdCA+IHJvbXMuaAorCXNoIC4vbWtoZXggdmdhYmlvc19w
dCAuLi92Z2FiaW9zL3ZnYWJpb3MtcHQuYmluID4+IHJvbXMuaCAgICAgICAg
IAogCXNoIC4vbWtoZXggdmdhYmlvc19zdGR2Z2EgLi4vdmdhYmlvcy9WR0FC
SU9TLWxncGwtbGF0ZXN0LmJpbiA+PiByb21zLmgKIAlzaCAuL21raGV4IHZn
YWJpb3NfY2lycnVzdmdhIFwKIAkJLi4vdmdhYmlvcy9WR0FCSU9TLWxncGwt
bGF0ZXN0LmNpcnJ1cy5iaW4gPj4gcm9tcy5oCg==

--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="05_xen-setup.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="05_xen-setup.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2lvZW11LXFlbXUteGVuL3hlbi1z
ZXR1cAkyMDExLTAyLTExIDE4OjU0OjUxLjAwMDAwMDAwMCArMDEwMAorKysg
eGVuLTQuMS4yX3dvcmsvdG9vbHMvaW9lbXUtcWVtdS14ZW4veGVuLXNldHVw
CTIwMTItMDEtMDcgMTQ6Mjc6MDQuMDAwMDAwMDAwICswMTAwCkBAIC0xOCw3
ICsxOCw4IEBAIGlmIHRlc3QgLXogIiR7WEVOX1NDUklQVF9ESVJ9IjsgdGhl
bgogCVhFTl9TQ1JJUFRfRElSPSIvZXRjL3hlbi9zY3JpcHRzIgogZmkKIAot
JHtRRU1VX1JPT1Q6LS59L2NvbmZpZ3VyZSAtLWRpc2FibGUtZ2Z4LWNoZWNr
IC0tZGlzYWJsZS1jdXJzZXMgLS1kaXNhYmxlLXNsaXJwICIkQCIgLS1wcmVm
aXg9JHtQUkVGSVh9CisjJHtRRU1VX1JPT1Q6LS59L2NvbmZpZ3VyZSAtLWRp
c2FibGUtZ2Z4LWNoZWNrIC0tZGlzYWJsZS1jdXJzZXMgLS1kaXNhYmxlLXNs
aXJwICIkQCIgLS1wcmVmaXg9JHtQUkVGSVh9Ciske1FFTVVfUk9PVDotLn0v
Y29uZmlndXJlIC0tYXVkaW8tZHJ2LWxpc3Q9YWxzYSAtLWVuYWJsZS1taXhl
bXUgLS1kaXNhYmxlLWdmeC1jaGVjayAtLWRpc2FibGUtY3Vyc2VzIC0tZGlz
YWJsZS1zbGlycCAiJEAiIC0tcHJlZml4PSR7UFJFRklYfQogCiBpZiBbICJ4
JFhFTl9ST09UIiAhPSB4IF07IHRoZW4KIAllY2hvICJYRU5fUk9PVD0kWEVO
X1JPT1QiID4+Y29uZmlnLWhvc3QubWFrCg==

--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="04_hvmloader.c.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="04_hvmloader.c.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9o
dm1sb2FkZXIuYwkyMDExLTEwLTIwIDE5OjA1OjQxLjAwMDAwMDAwMCArMDIw
MAorKysgeGVuLTQuMS4yX3dvcmsvdG9vbHMvZmlybXdhcmUvaHZtbG9hZGVy
L2h2bWxvYWRlci5jCTIwMTItMDEtMDcgMTQ6MTk6NDguMDAwMDAwMDAwICsw
MTAwCkBAIC0xMTYsNiArMTE2LDkgQEAgdW5zaWduZWQgbG9uZyBwY2lfbWVt
X2VuZCA9IFBDSV9NRU1fRU5EOwogCiBzdGF0aWMgZW51bSB7IFZHQV9ub25l
LCBWR0Ffc3RkLCBWR0FfY2lycnVzLCBWR0FfcHQgfSB2aXJ0dWFsX3ZnYSA9
IFZHQV9ub25lOwogCisvKiB2aXJ0dWFsIEJERiBvZiBwYXNzLXRocm91Z2hl
ZCBnZnggKi8KK3N0YXRpYyB1aW50OF90IGdmeF9iZGY7CisKIHN0YXRpYyB2
b2lkIGluaXRfaHlwZXJjYWxscyh2b2lkKQogewogICAgIHVpbnQzMl90IGVh
eCwgZWJ4LCBlY3gsIGVkeDsKQEAgLTIxOCw2ICsyMjEsNDIgQEAgc3RhdGlj
IHZvaWQgcGNpX3NldHVwKHZvaWQpCiAgICAgICAgICAgICAgICAgdmlydHVh
bF92Z2EgPSBWR0FfY2lycnVzOwogICAgICAgICAgICAgZWxzZSBpZiAoIHZp
cnR1YWxfdmdhID09IFZHQV9ub25lICkKICAgICAgICAgICAgICAgICB2aXJ0
dWFsX3ZnYSA9IFZHQV9wdDsKKyAgICAgICAgICAgICAgICBnZnhfYmRmID0g
ZGV2Zm47CisKKyAgICAgICAgICAgICAgICAvKiBNYWtlIHZCQVI9cEJBUiAq
LworICAgICAgICAgICAgICAgIHByaW50ZigiTWFrZSB2QkFSID0gcEJBUiBv
ZiBhc3NpZ25lZCBnZnhcbiIpOworICAgICAgICAgICAgICAgIGZvciAoIGJh
ciA9IDA7IGJhciA8IDc7IGJhcisrICkKKyAgICAgICAgICAgICAgICB7Cisg
ICAgICAgICAgICAgICAgICAgIGJhcl9yZWcgPSBQQ0lfQkFTRV9BRERSRVNT
XzAgKyA0KmJhcjsKKyAgICAgICAgICAgICAgICAgICAgaWYgKCBiYXIgPT0g
NiApCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmFyX3JlZyA9IFBD
SV9ST01fQUREUkVTUzsKKyAgICAgICAgICAgICAgICAgICAgLyogV2hlbiBm
aXJzdCB0aW1lIHJlYWQsIGl0IHdpbGwgcmV0dXJuIHBoeXNpY2FsIGFkZHJl
c3MgKi8KKyAgICAgICAgICAgICAgICAgICAgYmFyX2RhdGEgPSBwY2lfcmVh
ZGwoZGV2Zm4sIGJhcl9yZWcpOworICAgICAgICAgICAgICAgICAgICBwY2lf
d3JpdGVsKGRldmZuLCBiYXJfcmVnLCBiYXJfZGF0YSk7CisKKyAgICAgICAg
ICAgICAgICAgICAgLyogTm93IGVuYWJsZSB0aGUgbWVtb3J5IG9yIEkvTyBt
YXBwaW5nLiAqLworICAgICAgICAgICAgICAgICAgICBjbWQgPSBwY2lfcmVh
ZHcoZGV2Zm4sIFBDSV9DT01NQU5EKTsKKyAgICAgICAgICAgICAgICAgICAg
aWYgKCAoYmFyX3JlZyA9PSBQQ0lfUk9NX0FERFJFU1MpIHx8CisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICgoYmFyX2RhdGEgJiBQQ0lfQkFTRV9B
RERSRVNTX1NQQUNFKSA9PQorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgUENJX0JBU0VfQUREUkVTU19TUEFDRV9NRU1PUlkpICkKKyAgICAgICAg
ICAgICAgICAgICAgICAgICAgY21kIHw9IFBDSV9DT01NQU5EX01FTU9SWTsK
KyAgICAgICAgICAgICAgICAgICAgZWxzZQorICAgICAgICAgICAgICAgICAg
ICAgICAgICBjbWQgfD0gUENJX0NPTU1BTkRfSU87CisgICAgICAgICAgICAg
ICAgICAgIGNtZCB8PSBQQ0lfQ09NTUFORF9NQVNURVI7CisgICAgICAgICAg
ICAgICAgICAgIHBjaV93cml0ZXcoZGV2Zm4sIFBDSV9DT01NQU5ELCBjbWQp
OworICAgICAgICAgICAgICAgfQorCisgICAgICAgICAgICAgICAgLyogTWFw
IHRoZSBpbnRlcnJ1cHQuICovCisgICAgICAgICAgICAgICAgcGluID0gcGNp
X3JlYWRiKGRldmZuLCBQQ0lfSU5URVJSVVBUX1BJTik7CisgICAgICAgICAg
ICAgICAgaWYgKCBwaW4gIT0gMCApCisgICAgICAgICAgICAgICAgeworICAg
ICAgICAgICAgICAgICAgICAvKiBUaGlzIGlzIHRoZSBiYXJiZXIncyBwb2xl
IG1hcHBpbmcgdXNlZCBieSBYZW4uICovCisgICAgICAgICAgICAgICAgICAg
IGxpbmsgPSAoKHBpbiAtIDEpICsgKGRldmZuID4+IDMpKSAmIDM7CisgICAg
ICAgICAgICAgICAgICAgIGlzYV9pcnEgPSBwY2lfcmVhZGIoUENJX0lTQV9E
RVZGTiwgMHg2MCArIGxpbmspOworICAgICAgICAgICAgICAgICAgICBwY2lf
d3JpdGViKGRldmZuLCBQQ0lfSU5URVJSVVBUX0xJTkUsIGlzYV9pcnEpOwor
ICAgICAgICAgICAgICAgIH0KKyAgICAgICAgICAgICAgICBjb250aW51ZTsK
KwogICAgICAgICAgICAgYnJlYWs7CiAgICAgICAgIGNhc2UgMHgwNjgwOgog
ICAgICAgICAgICAgLyogUElJWDQgQUNQSSBQTS4gU3BlY2lhbCBkZXZpY2Ug
d2l0aCBzcGVjaWFsIFBDSSBjb25maWcgc3BhY2UuICovCkBAIC03NTAsOCAr
Nzg5LDEwIEBAIGludCBtYWluKHZvaWQpCiAgICAgICAgIGJyZWFrOwogICAg
IGNhc2UgVkdBX3B0OgogICAgICAgICBwcmludGYoIkxvYWRpbmcgVkdBQklP
UyBvZiBwYXNzdGhyb3VnaGVkIGdmeCAuLi5cbiIpOwotICAgICAgICB2Z2Fi
aW9zX3N6ID0KLSAgICAgICAgICAgIHJvdW5kX29wdGlvbl9yb20oKCoodWlu
dDhfdCAqKShWR0FCSU9TX1BIWVNJQ0FMX0FERFJFU1MrMikpICogNTEyKTsK
KyAgICAgICAgbWVtY3B5KCh2b2lkICopVkdBQklPU19QSFlTSUNBTF9BRERS
RVNTLAorICAgICAgICAgICAgICAgdmdhYmlvc19wdCwgc2l6ZW9mKHZnYWJp
b3NfcHQpKTsKKyAgICAgICAgKih1aW50OF90ICopKFZHQUJJT1NfUEhZU0lD
QUxfQUREUkVTUyArIHNpemVvZih2Z2FiaW9zX3B0KSkgPSBnZnhfYmRmOwor
ICAgICAgICB2Z2FiaW9zX3N6ID0gcm91bmRfb3B0aW9uX3JvbShzaXplb2Yo
dmdhYmlvc19wdCkgKyAxKTsKICAgICAgICAgYnJlYWs7CiAgICAgZGVmYXVs
dDoKICAgICAgICAgcHJpbnRmKCJObyBlbXVsYXRlZCBWR0EgYWRhcHRvciAu
Li5cbiIpOwo=

--62747910-476652355-1325947349=:93467
Content-Type: application/octet-stream; name="03_dsdt.asl.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="03_dsdt.asl.patch"

LS0tIHhlbi00LjEuMl9vcmlnL3Rvb2xzL2Zpcm13YXJlL2h2bWxvYWRlci9h
Y3BpL2RzZHQuYXNsCTIwMTEtMTAtMjAgMTk6MDU6NDEuMDAwMDAwMDAwICsw
MjAwCisrKyB4ZW4tNC4xLjJfd29yay90b29scy9maXJtd2FyZS9odm1sb2Fk
ZXIvYWNwaS9kc2R0LmFzbAkyMDEyLTAxLTA3IDE0OjQ5OjI2LjAwMDAwMDAw
MCArMDEwMApAQCAtMTczLDE0ICsxNzMsNDIgQEAgRGVmaW5pdGlvbkJsb2Nr
ICgiRFNEVC5hbWwiLCAiRFNEVCIsIDIsCiAgICAgICAgICAgICAgICAgICAg
ICAgICAweDAwMDAwMDAwLAogICAgICAgICAgICAgICAgICAgICAgICAgMHgw
MDAyMDAwMCkKIAorICAgICAgICAgICAgICAgICAgICAvKiByZXNlcnZlIE1N
SU8gQkFScyBvZiBnZnggZm9yIDE6MSBtYXBwaW5nICovCiAgICAgICAgICAg
ICAgICAgICAgIERXb3JkTWVtb3J5KAogICAgICAgICAgICAgICAgICAgICAg
ICAgUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwgTWF4
Rml4ZWQsCiAgICAgICAgICAgICAgICAgICAgICAgICBDYWNoZWFibGUsIFJl
YWRXcml0ZSwKICAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAs
Ci0gICAgICAgICAgICAgICAgICAgICAgICAweEYwMDAwMDAwLAotICAgICAg
ICAgICAgICAgICAgICAgICAgMHhGNEZGRkZGRiwKKyAgICAgICAgICAgICAg
ICAgICAgICAgIDB4RTAwMDAwMDAsCisgICAgICAgICAgICAgICAgICAgICAg
ICAweEVGRkZGRkZGLAogICAgICAgICAgICAgICAgICAgICAgICAgMHgwMDAw
MDAwMCwKLSAgICAgICAgICAgICAgICAgICAgICAgIDB4MDUwMDAwMDAsCisg
ICAgICAgICAgICAgICAgICAgICAgICAweDEwMDAwMDAwKQorCisgICAgICAg
ICAgICAgICAgICAgIERXb3JkTWVtb3J5KAorICAgICAgICAgICAgICAgICAg
ICAgICAgUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwg
TWF4Rml4ZWQsCisgICAgICAgICAgICAgICAgICAgICAgICBOb25DYWNoZWFi
bGUsIFJlYWRXcml0ZSwKKyAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAw
MDAwMDAsCisgICAgICAgICAgICAgICAgICAgICAgICAweEMwMDAwMDAwLAor
ICAgICAgICAgICAgICAgICAgICAgICAgMHhDMUZGRkZGRiwKKyAgICAgICAg
ICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsCisgICAgICAgICAgICAgICAg
ICAgICAgICAweDAyMDAwMDAwKQorCisgICAgICAgICAgICAgICAgICAgIERX
b3JkTWVtb3J5KAorICAgICAgICAgICAgICAgICAgICAgICAgUmVzb3VyY2VQ
cm9kdWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwgTWF4Rml4ZWQsCisgICAg
ICAgICAgICAgICAgICAgICAgICBOb25DYWNoZWFibGUsIFJlYWRXcml0ZSwK
KyAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsCisgICAgICAg
ICAgICAgICAgICAgICAgICAweEMyMDAwMDAwLAorICAgICAgICAgICAgICAg
ICAgICAgICAgMHhDMkZGRkZGRiwKKyAgICAgICAgICAgICAgICAgICAgICAg
IDB4MDAwMDAwMDAsCisgICAgICAgICAgICAgICAgICAgICAgICAweDAxMDAw
MDAwKQorCisgICAgICAgICAgICAgICAgICAgIERXb3JkTWVtb3J5KAorICAg
ICAgICAgICAgICAgICAgICAgICAgUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVj
b2RlLCBNaW5GaXhlZCwgTWF4Rml4ZWQsCisgICAgICAgICAgICAgICAgICAg
ICAgICBDYWNoZWFibGUsIFJlYWRXcml0ZSwKKyAgICAgICAgICAgICAgICAg
ICAgICAgIDB4MDAwMDAwMDAsCisgICAgICAgICAgICAgICAgICAgICAgICAw
eEZCMDAwMDAwLAorICAgICAgICAgICAgICAgICAgICAgICAgMHhGQjA3RkZG
RiwKKyAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsCisgICAg
ICAgICAgICAgICAgICAgICAgICAweDAwMDgwMDAwLAogICAgICAgICAgICAg
ICAgICAgICAgICAgLCwgX1kwMSkKICAgICAgICAgICAgICAgICB9KQogCg==


--62747910-476652355-1325947349=:93467
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--62747910-476652355-1325947349=:93467--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 16:38:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 16:38:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjZGM-0007vE-CU; Sat, 07 Jan 2012 16:36:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjZGK-0007v9-Np
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:36:57 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325954208!10512632!1
X-Originating-IP: [212.82.109.208]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 17207 invoked from network); 7 Jan 2012 16:36:48 -0000
Received: from nm25-vm7.bullet.mail.ird.yahoo.com (HELO
	nm25-vm7.bullet.mail.ird.yahoo.com) (212.82.109.208)
	by server-11.tower-21.messagelabs.com with SMTP;
	7 Jan 2012 16:36:48 -0000
Received: from [77.238.189.57] by nm25.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 16:36:47 -0000
Received: from [212.82.108.133] by tm10.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 16:36:47 -0000
Received: from [127.0.0.1] by omp1038.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 16:36:47 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 661918.76772.bm@omp1038.mail.ird.yahoo.com
Received: (qmail 89002 invoked by uid 60001); 7 Jan 2012 16:36:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325954207; bh=LxJeQupYjZG8qGIBTClVdSNYEf0bnCMI8xt7J4bJNzE=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=3rta+Lk/ejUWRvxPka82pF1pJezaT9ooeLY8LaUSEABQud1fxGA6iz6aYSQDv24fmsnuZnTduDybMCRMJUxMRUZwIuTkBQBYhiubOozNMMaeF31yTBk9jCb+9KZxey1YR6gZgR1KzbGVX4vrPeaJQ3ctroNqAP/2XT5/b3lj9gk=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=PEU3Nq5CdzZwu6tRRsdlD5EiaB4zeQSHIfS46AQejNbIQwtDg0MA3jVmcF3lAZym9hBKDCq4ha4vWiRWVrDgbYUjoxfurNPvMKaF+E0yXgMyP57q9ldsRUMeKtr2QzDjeUkK4pM3XzHrfXzOPMEp0HaxTj+uKwjqzKUyko4QKUs=;
X-YMail-OSG: xkXa64cVM1lAio5nNqSIV5q3SmuabrgBaYyWnvVIWKDQzsO
	fX.4hPYscuAVRZdDJypgSfpsnPMMs.3dyKiAnjDFzaaJY1X9nSiZi2rNAiDW
	e6YD2ulljdg6m_HBek.ZlI3PllzsTEezWUT9ktOrhhjGzteBNrJGuOMFDbn5
	ts5i3BiWky87sqJuIzYQHGw_SciHESgeCkGsNJ2WVQd9jaKvdaKm4nJ_9I8d
	0nQUevyFYND17flsv8Z3BPedtDdCOdwBcAE6RQdVt2YY9D4pHD2IGdRFFh7H
	33q_OXA_8P7CSbrFmd0kBBo3ATft8ghWLZlBAekj8Cf7cVsDWy50TrAMIDK4
	uzj5OdIV_cnwRzQrX1WiRRpf3_zY1LqKdJJ0825kFDGGcESptDKHm2ikjsXA
	lqoyafY7FUd_4nXOTtyKWnFVQZ0DA0ukea3xUYn_kLVyh2_ouKXkWJRXycU5
	jqyXtLU_9oh9INrMYqmfM9x7BDFJB6fATdTwnG2YMujfZVPG7u13B0WjgGPc
	r9OuefYOaGrpPijlvfo6Nvipl3YQ_dsDBXDr64M_cFgdxWeB71c5MJpDU3g- -
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 07 Jan 2012 16:36:46 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
	<1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
	<1325938952.14430.YahooMailNeo@web29805.mail.ird.yahoo.com>
	<1325947349.93467.YahooMailNeo@web29805.mail.ird.yahoo.com>
Message-ID: <1325954206.88933.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 16:36:46 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: David TECHER <davidtecher@yahoo.fr>, -+= Lta =+- <lta@akr.fm>
In-Reply-To: <1325947349.93467.YahooMailNeo@web29805.mail.ird.yahoo.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Re :  Re :  Re :  Re : Re :  Secondary VGA Passthrough,
	nvidia, win7: success report.
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="===============3220707573426219212=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3220707573426219212==
Content-Type: multipart/alternative; boundary="62747910-923225173-1325954206=:88933"

--62747910-923225173-1325954206=:88933
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I took the decison to stop my tests for xen 4.1.2 and VGA PassThrough.=0A=
=0AToo much problem....with Windows 7. Moreoever I came to the conclusion t=
hat it is too more unstable than VGA PassThrough on Xen 4.2=0A=0A=0ABack=A0=
 to Xen 4.2=A0 :) with XP and Linux :). No windows 7=0A=0A=0A=0A___________=
_____________________=0A De=A0: David TECHER <davidtecher@yahoo.fr>=0A=C0=
=A0: David TECHER <davidtecher@yahoo.fr>; -+=3D Lta =3D+- <lta@akr.fm> =0AC=
c=A0: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> =0AEn=
voy=E9 le : Samedi 7 Janvier 2012 15h42=0AObjet=A0: [Xen-devel] Re :  Re : =
 Re : Re :  Secondary VGA Passthrough, nvidia, win7: success report.=0A =0A=
=0AAttached=A0 are the=A0 updated Tobias patches for Xen 4.1.2.=0A=0AThe mo=
st important is 01_pass-through.patch that need to be updated :) else you r=
eceive a stupid error from compilation=0A=0A=0ASince I compiled kernel 3.1.=
6, without modules for Xen (=3DY), I have to remove 'xen-pci.passthough=3D1=
' from grub else I can not=A0 have my screen (stays black...)=0A=0A=0AI am =
doing my test on a new domU Windows 7.=0A=0AHope it will succeed :)=0A=0AI =
will let you know=0A=0A=0A=0A=0A=0A________________________________=0A De=
=A0: David TECHER <davidtecher@yahoo.fr>=0A=C0=A0: David TECHER <davidteche=
r@yahoo.fr>; -+=3D Lta =3D+- <lta@akr.fm> =0ACc=A0: "xen-devel@lists.xensou=
rce.com" <xen-devel@lists.xensource.com> =0AEnvoy=E9 le : Samedi 7 Janvier =
2012 13h22=0AObjet=A0: [Xen-devel] Re :  Re : Re :  Secondary VGA Passthrou=
gh, nvidia, win7: success report.=0A =0A=0AOk=0A=0AI think I understand wha=
t's wrong now :)=0A=0AInit build=0A=3D=3D=3D=3D=3D=3D=0A=0A=0Awget http://b=
its.xensource.com/oss-xen/release/4.1.2/xen-4.1.2.tar.gz=0Atar xzf xen-4.1.=
2.tar.gz =0Acd xen-4.1.2/=0Acd tools/=0Amake =0Amake clean =0Acd ..=0A=0ADo=
wnload patches=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0Awget -q ht=
tp://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtIj4stRFbP=
o.txt -O 01_pass-through.patch=0Awget -q http://old-list-archives.xen.org/a=
rchives/html/xen-devel/2010-05/txt06YdYEsi3S.txt -O 02_makefile.patch=0Awge=
t -q=0A http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/tx=
tS2w8cPgsnS.txt -O 03_dsdt.patch=0Awget -q http://old-list-archives.xen.org=
/archives/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader.patch=0A=
wget -q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/tx=
tiSIyxOHBZ8.txt -O 05_sound-makefile.patch=0A=0A=0AModify the first patch=
=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0AReplace the pat=
h for the good path in the first patch 01_pass-through.patch=0A=0Ased -i "s=
:tools/ioemu-remote/hw/:tools/ioemu-qemu-xen/hw/:g" 01_pass-through.patch=
=0A=0AApply patches=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0A=0Aroot@mercur=
y:/opt/tmp/xen-4.1.2# for file in $(ls 0*patch);do echo "######## PATCH =3D=
 $file ############";patch -p0 < $file;done=0A######## PATCH =3D 01_pass-th=
rough.patch ############=0Apatching file tools/ioemu-qemu-xen/hw/pass-throu=
gh.c=0AHunk #1 succeeded at 22 with fuzz 2 (offset -1843 lines).=0AHunk #2 =
succeeded at 3312 (offset -55 lines).=0AHunk #3 succeeded at 3336 (offset -=
55 lines).=0AHunk #4 succeeded at 4335 with fuzz 2 (offset -144 lines).=0A#=
####### PATCH =3D 02_makefile.patch ############=0Apatching file tools/firm=
ware/hvmloader/Makefile=0A######## PATCH =3D 03_dsdt.patch ############=0Ap=
atching file tools/firmware/hvmloader/acpi/dsdt.asl=0A######## PATCH =3D 04=
_hvmloader.patch ############=0Apatching file tools/firmware/hvmloader/hvml=
oader.c=0AHunk #1 succeeded at 116 (offset 1 line).=0AHunk #2 succeeded at =
221 (offset 1 line).=0AHunk #3 succeeded at 789 (offset 60 lines).=0A######=
## PATCH =3D 05_sound-makefile.patch ############=0Apatching file=0A tools/=
ioemu-remote/xen-setup=0AHunk #1 FAILED at 16=0A=0AI will go on my tests an=
d will let you know=0A=0AThanks=0A=0ADavid=0A=0A=0A________________________=
________=0A De=A0: David TECHER <davidtecher@yahoo.fr>=0A=C0=A0: -+=3D Lta =
=3D+- <lta@akr.fm> =0ACc=A0: "xen-devel@lists.xensource.com" <xen-devel@lis=
ts.xensource.com> =0AEnvoy=E9 le : Samedi 7 Janvier 2012 13h04=0AObjet=A0: =
[Xen-devel] Re : Re :  Secondary VGA Passthrough, nvidia, win7: success rep=
ort.=0A =0A=0AI tested xen 4.1.2 too.Tobias patches are the patches I've te=
sted. I am not very lucky.=0A=0A=0ASince you used Tobias patches as me, my =
question is - to be more precise - could you sent Tobias patches that you h=
ave modified in order to checking=0AI did not forget something as you. =0A=
=0A=0AMy idea is that since I already have xen 4.2 installed, installing xe=
n 4.1.2 over this , something wrong happens=0A=0A=0AMy screen stays like a =
black screen and nothing happens. no "gfx message" in the log.=0A=0AWith Xe=
n 4.2 I tried aero desktop too but my domU crashes when=A0 I tried to activ=
ate aero.=0A=0A=0A=0A=0A________________________________=0A De=A0: -+=3D Lt=
a =3D+- <lta@akr.fm>=0A=C0=A0: David TECHER <davidtecher@yahoo.fr> =0ACc=A0=
: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Samedi 7 Janvier 2012 3h17=
=0AObjet=A0: Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7: =
success report.=0A =0A=0AHi,=0A=0A=0AOn Fri, Jan 6, 2012 at 11:23 PM, David=
 TECHER <davidtecher@yahoo.fr> wrote:=0A=0ACould you tell me what version o=
f Xen? 4.1.0? 4.1.2?=0A=0AAs it is stated before this is a 4.1.2 version wi=
th debian patches=0A=A0=0A=0A>=0A>By the way could you send your patches at=
tached to a mail so I could try?=0A=0A- There's also a link to tobias patch=
e's on the first post.=0A=A0=0A=0A>=0A>Test on Xen 4.2 failed (desktop stay=
s to lag...)=0A=0AHave u tried to force windows to activate the aero deskto=
p ?=0A=A0=0A=0A>=0A>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU b=
oot but nothing appears on screen.=0A=0AI also followed tobias (same as you=
rs) instructions to dump and build vgabios-pt.bin into xen, did u do it als=
o ?=0A=A0=0A=0A>=0A>Strange.=0A>=0A>=0A>=0A>=0A>___________________________=
_____=0A> De=A0: -+=3D Lta =3D+- <lta@akr.fm>=0A>=C0=A0: xen-devel@lists.xe=
nsource.com =0A>Envoy=E9 le : Vendredi 6 Janvier 2012 17h48=0A>Objet=A0: [X=
en-devel] Secondary VGA Passthrough, nvidia, win7: success report.=0A>=0A>=
=0A>=0A>Hello xen-devel,=0A>=0A>=0A>=0A>=0A>This is my first post on this l=
ist and as such i might be breaking some explicit/implicit rules and i apol=
ogize if it's the case. Maybe this list isn't the exact=A0right=A0kind of p=
lace where to post this kind of stuff, but i know lots of us are browsing t=
his list as the primary source of documentation for xen.=0A>=0A>=0A>I've re=
ad many times windows 7 isn't the right os to run on top of xen. Most of th=
e guy's who are running vga passthru are recommanding to use windows xp, an=
d i've never seen any success report of vga passthru on windows 7 so i thou=
ght it was important to post mine.=0A>=0A>=0A>Anyway, here's my hardware se=
tup :=0A>- Gigabyte GA-990X-UD3=0A>-=A0AMD Phenom II X6 1075T Processor=0A>=
- MSI Cyclone NVIDIA Geforce GTX 460=0A>=0A>=0A>On the software side i'm us=
ing :=0A>=0A>=0A>- Debian testing as Dom0=0A>- Xen-4.1 (debian version 4.1.=
2-2) with what's now referred to as "Tobias Geiger patches" (http://old-lis=
t-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html) (You have=
 to edit the patches, changing the path to some qemu source files for them =
to apply)=0A>- debian's kernel =A03.1.5, compiled to include the pciback dr=
iver. Here's the output of `cat /boot/my3.1.5config | grep -i xen`=0A>CONFI=
G_XEN=3Dy=0A>CONFIG_XEN_DOM0=3Dy=0A>CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A>CONF=
IG_XEN_PVHVM=3Dy=0A>CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128=0A>CONFIG_XEN_SAVE_R=
ESTORE=3Dy=0A># CONFIG_XEN_DEBUG_FS is not set=0A># CONFIG_XEN_DEBUG is not=
 set=0A>CONFIG_PCI_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_FRONTEND=3Dm=0A>CONFIG_XEN_=
BLKDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKDEV_BACKEND=3Dm=0A>CONFIG_NETXEN_NIC=
=3Dm=0A>CONFIG_XEN_NETDEV_FRONTEND=3Dm=0A>CONFIG_XEN_NETDEV_BACKEND=3Dm=0A>=
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy=0A>CONFIG_HVC_XEN=3Dy=0A>CONFIG_XEN_WD=
T=3Dm=0A>CONFIG_XEN_FBDEV_FRONTEND=3Dy=0A># Xen driver support=0A>CONFIG_XE=
N_BALLOON=3Dy=0A># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=0A>CONFIG_X=
EN_SCRUB_PAGES=3Dy=0A>CONFIG_XEN_DEV_EVTCHN=3Dm=0A>CONFIG_XEN_BACKEND=3Dy=
=0A>CONFIG_XENFS=3Dm=0A>CONFIG_XEN_COMPAT_XENFS=3Dy=0A>CONFIG_XEN_SYS_HYPER=
VISOR=3Dy=0A>CONFIG_XEN_XENBUS_FRONTEND=3Dy=0A>CONFIG_XEN_GNTDEV=3Dm=0A>CON=
FIG_XEN_GRANT_DEV_ALLOC=3Dm=0A>CONFIG_XEN_PLATFORM_PCI=3Dm=0A>CONFIG_SWIOTL=
B_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_BACKEND=3Dy=0A>=0A>=0A>The kernel boot optio=
ns are 'nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(=
01:00.1)'=0A>=0A>=0A>- Here's my win7 domU config file :=0A>=0A>=0A>kernel =
=3D "/usr/lib/xen-4.1/boot/hvmloader"=0A>builder=3D'hvm'=0A>memory =3D 3072=
=0A>name =3D "w7"=0A>vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:1=
6:3e:35:49:62']=0A>disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-=
xen/appz,hdb,w']=0A>device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0A>boot=
=3D"dc"=0A>=0A>=0A>pci=3D['01:00.0','01:00.1']=0A>gfx_passthru=3D1=0A>=0A>=
=0A>vcpus=3D6=0A>acpi=3D1=0A>sdl=3D0=0A>vnc=3D1=0A>vncconsole=3D1=0A>vncpas=
swd=3D''=0A>serial=3D'pty'=0A>usbdevice=3D'tablet'=0A>pae=3D1=0A>pci_msitra=
nslate=3D0=0A>pci_power_mgmt=3D0=0A>acpi_s3 =3D 1=0A>acpi_s4 =3D 1=0A>on_po=
weroff =3D 'destroy'=0A>on_reboot =A0 =3D 'restart'=0A>on_crash =A0 =A0=3D =
'restart'=0A>xen_platform_pci=3D1=0A>hpet =3D 1=0A>viridian=3D1=0A>monitor=
=3D1=0A>xen_extended_power_mgmt=3D2=0A>hpet=3D1=0A>=0A>=0A>What's important=
 here for the Nvidia drivers to work and not give a nice nvlddmkm.sys BSOD =
is:=0A>pci_msitranslate=3D0=0A>pci_power_mgmt=3D0=0A>=0A>=0A>- Windows 7 32=
bits=0A>- Nvidia drivers 275.33=0A>- You have to manually run aero speed te=
st or force aero to start by using registry entries for the desktop not to =
be laggy=0A>=0A>=0A>The windows 7 domU is running fine with no performance =
decrease noticeable, although i've not yet played intensive gpu video game,=
 i'm still pretty confident they'll run fine.=0A>=0A>=0A>Anyway. i've still=
 some problems i shall report in separate posts :=0A>- The PCI bus topology=
 isn't preserved, and the gfx card, which is plugged on 01:00 becomes 05:00=
 on domU.=0A>- I'm passing through an RME Hdsp / hammerfall pci sound card =
to the domU and while it is working fine on his own, there's a strange inte=
raction between it and the GPLPV network driver. When i start playing sound=
, the network instantly cease working. It starts back as soon as i stop pla=
ying audio.=0A>=0A>=0A>That's all folks,=0A>=0A>=0A>Cheers,=0A>Lta=0A>=0A>=
=0A>_______________________________________________=0A>Xen-devel mailing li=
st=0A>Xen-devel@lists.xensource.com=0A>http://lists.xensource.com/xen-devel=
=0A>=0A>=0A>=0A=0A=0A=0A_______________________________________________=0AX=
en-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensou=
rce.com/xen-devel=0A=0A=0A=0A______________________________________________=
_=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.x=
ensource.com/xen-devel=0A=0A=0A=0A_________________________________________=
______=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://li=
sts.xensource.com/xen-devel
--62747910-923225173-1325954206=:88933
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>I took the=
 decison to stop my tests for xen 4.1.2 and VGA PassThrough.</span></div><d=
iv><br><span></span></div><div><span>Too much problem....with Windows 7. Mo=
reoever I came to the conclusion that it is too more unstable than VGA Pass=
Through on Xen 4.2<br></span></div><div><br><span></span></div><div><span>B=
ack&nbsp; to Xen 4.2&nbsp; :) with XP and Linux :). No windows 7<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 rom=
an, 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> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><span style=3D"font-w=
eight: bold;">=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&g=
t;; -+=3D
 Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span style=3D"font-weight: bold;">Cc&=
nbsp;:</span></b> "xen-devel@lists.xensource.com" &lt;xen-devel@lists.xenso=
urce.com&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span=
></b> Samedi 7 Janvier 2012 15h42<br> <b><span style=3D"font-weight: bold;"=
>Objet&nbsp;:</span></b> [Xen-devel] Re :  Re :  Re : Re :  Secondary VGA P=
assthrough, nvidia, win7: success report.<br> </font> <br><div id=3D"yiv834=
639090"><div><div style=3D"color:#000;background-color:#fff;font-family:tim=
es new roman, new york, times, serif;font-size:12pt;"><div><span>Attached&n=
bsp; are the&nbsp; updated Tobias patches for Xen 4.1.2.</span></div><div><=
br><span></span></div><div><span>The most important is 01_pass-through.patc=
h that need to be updated :) else you receive a stupid error from compilati=
on<br></span></div><div><br><span></span></div><div><span>Since I compiled =
kernel 3.1.6, without modules for Xen (=3DY), I have to remove
 'xen-pci.passthough=3D1' from grub else I can not&nbsp; have my screen (st=
ays black...)<br></span></div><div><br><span></span></div><div><span>I am d=
oing my test on a new domU Windows 7.</span></div><div><br><span></span></d=
iv><div><span>Hope it will succeed :)</span></div><div><br><span></span></d=
iv><div><span>I will let you know<br></span></div><div><br><span></span></d=
iv><div><span><br></span></div><div><br></div>  <div style=3D"font-family:t=
imes 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 fac=
e=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-weight:bold=
;">De&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><s=
pan style=3D"font-weight:bold;">=C0&nbsp;:</span></b> David TECHER &lt;davi=
dtecher@yahoo.fr&gt;; -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span style=
=3D"font-weight:bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xensource.com"
 &lt;xen-devel@lists.xensource.com&gt; <br> <b><span style=3D"font-weight:b=
old;">Envoy=E9 le :</span></b> Samedi 7 Janvier 2012 13h22<br> <b><span sty=
le=3D"font-weight:bold;">Objet&nbsp;:</span></b> [Xen-devel] Re :  Re : Re =
:  Secondary VGA Passthrough, nvidia, win7: success report.<br> </font> <br=
><div id=3D"yiv834639090"><div><div style=3D"color:#000;background-color:#f=
ff;font-family:times new roman, new york, times, serif;font-size:12pt;"><di=
v><span>Ok</span></div><div><br><span></span></div><div><span>I think I und=
erstand what's wrong now :)</span></div><div><br><span></span></div><div>In=
it build</div><div>=3D=3D=3D=3D=3D=3D<br></div><div><br><span></span></div>=
<div><span>wget http://bits.xensource.com/oss-xen/release/4.1.2/xen-4.1.2.t=
ar.gz<br>tar xzf xen-4.1.2.tar.gz <br>cd xen-4.1.2/<br>cd tools/<br>make <b=
r>make clean <br>cd ..</span></div><div><span><br></span></div><div><span>D=
ownload patches<br></span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br></span></div><div><span>wget
 -q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtIj4=
stRFbPo.txt -O 01_pass-through.patch<br>wget -q http://old-list-archives.xe=
n.org/archives/html/xen-devel/2010-05/txt06YdYEsi3S.txt -O 02_makefile.patc=
h<br>wget -q=0A http://old-list-archives.xen.org/archives/html/xen-devel/20=
10-05/txtS2w8cPgsnS.txt -O 03_dsdt.patch<br>wget -q http://old-list-archive=
s.xen.org/archives/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader=
.patch<br>wget -q http://old-list-archives.xen.org/archives/html/xen-devel/=
2010-05/txtiSIyxOHBZ8.txt -O 05_sound-makefile.patch<br></span></div><div><=
br><span></span></div><div><span>Modify the first patch</span></div><div><s=
pan>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></div><div><=
span><br></span></div><div><span>Replace the path for the good path in the =
first patch </span><span>01_pass-through.patch</span></div><div><span><br><=
/span></div><div><span>sed -i "s:tools/ioemu-remote/hw/:tools/ioemu-qemu-xe=
n/hw/:g" 01_pass-through.patch</span></div><div><br><span></span></div><div=
><span>Apply patches</span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
br></span></div><div><span><br></span></div><div><span><br></span></div><di=
v><span>root@mercury:/opt/tmp/xen-4.1.2# for file in $(ls=0A 0*patch);do ec=
ho "######## PATCH =3D $file ############";patch -p0 &lt; $file;done<br>###=
##### PATCH =3D 01_pass-through.patch ############<br>patching file tools/i=
oemu-qemu-xen/hw/pass-through.c<br>Hunk #1 succeeded at 22 with fuzz 2 (off=
set -1843 lines).<br>Hunk #2 succeeded at 3312 (offset -55 lines).<br>Hunk =
#3 succeeded at 3336 (offset -55 lines).<br>Hunk #4 succeeded at 4335 with =
fuzz 2 (offset -144 lines).<br>######## PATCH =3D 02_makefile.patch #######=
#####<br>patching file tools/firmware/hvmloader/Makefile<br>######## PATCH =
=3D 03_dsdt.patch ############<br>patching file tools/firmware/hvmloader/ac=
pi/dsdt.asl<br>######## PATCH =3D 04_hvmloader.patch ############<br>patchi=
ng file tools/firmware/hvmloader/hvmloader.c<br>Hunk #1 succeeded at 116 (o=
ffset 1 line).<br>Hunk #2 succeeded at 221 (offset 1 line).<br>Hunk #3 succ=
eeded at 789 (offset 60 lines).<br>######## PATCH =3D 05_sound-makefile.pat=
ch ############<br>patching file=0A tools/ioemu-remote/xen-setup<br>Hunk #1=
 FAILED at 16</span></div><div><br><span></span></div><div><span>I will go =
on my tests and will let you know</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-family:times new roman, new =
york, times, serif;font-size:12pt;"> <div style=3D"font-family:times new ro=
man, 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> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><span style=3D"font-we=
ight:bold;">=C0&nbsp;:</span></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b=
><span style=3D"font-weight:bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xe=
nsource.com" &lt;xen-devel@lists.xensource.com&gt; <br> <b><span style=3D"f=
ont-weight:bold;">Envoy=E9 le :</span></b> Samedi 7 Janvier 2012 13h04<br> =
<b><span
 style=3D"font-weight:bold;">Objet&nbsp;:</span></b> [Xen-devel] Re : Re : =
 Secondary VGA Passthrough, nvidia, win7: success report.<br> </font> <br><=
div id=3D"yiv834639090"><div><div style=3D"color:#000;background-color:#fff=
;font-family:times new roman, new york, times, serif;font-size:12pt;"><div>=
<span>I tested xen 4.1.2 too.</span><span> Tobias patches are the patches I=
've tested. I am not very lucky.<br></span></div><div><span><br></span></di=
v><div><span>Since you used Tobias patches as me, my question is - to be mo=
re precise - could you sent Tobias patches that you have modified in order =
to checking</span></div><div><span>I did not forget something as you. <br><=
/span></div><div><br><span></span></div><div><span>My idea is that since I =
already have xen 4.2 installed, installing xen 4.1.2 over this , something =
wrong happens<br></span></div><div><br><span></span></div><div><span>My scr=
een stays like a black screen and nothing happens. no "gfx message" in the=
=0A log.</span></div><div><br><span></span></div><div><span>With Xen 4.2 I =
tried aero desktop too but my domU crashes when&nbsp; I tried to activate=
=0A aero.<br></span></div><div><br><span></span></div><div><span></span></d=
iv><div><br></div>  <div style=3D"font-family:times new roman, new york, ti=
mes, 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> -+=
=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight:bold;">=
=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><spa=
n style=3D"font-weight:bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensourc=
e.com <br> <b><span style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Sa=
medi 7 Janvier 2012 3h17<br> <b><span style=3D"font-weight:bold;">Objet&nbs=
p;:</span></b> Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7=
: success report.<br> </font> <br><div id=3D"yiv834639090">Hi,<br><br><div =
class=3D"yiv834639090gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, David TE=
CHER <span dir=3D"ltr">&lt;<a
 rel=3D"nofollow" ymailto=3D"mailto:davidtecher@yahoo.fr" target=3D"_blank"=
 href=3D"mailto:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>&gt;</span> w=
rote:<br><blockquote class=3D"yiv834639090gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"=
font-size:12pt;font-family:times new roman, new york, times, serif;"><div><=
span>Could you tell me what version of Xen? 4.1.0? 4.1.2?</span></div></div=
></div></blockquote><div><br></div><div>As it is stated before this is a 4.=
1.2 version with debian patches</div>=0A<div>&nbsp;</div><blockquote class=
=3D"yiv834639090gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex;"><div><div style=3D"font-size:12pt;font-family:ti=
mes new roman, new york, times, serif;"><div><br><span></span></div>=0A<div=
><span>By the way could you send your patches attached to a mail so I could=
 try?</span></div></div></div></blockquote><div><br></div><div>- There's al=
so a link to tobias patche's on the first post.</div><div>&nbsp;</div>=0A<b=
lockquote class=3D"yiv834639090gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex;"><div><div style=3D"font-size:12pt=
;font-family:times new roman, new york, times, serif;"><div><br><span></spa=
n></div><div><span>Test on Xen 4.2 failed (desktop stays to lag...)</span><=
/div>=0A</div></div></blockquote><div><br></div><div>Have u tried to force =
windows to activate the aero desktop ?</div><div>&nbsp;</div><blockquote cl=
ass=3D"yiv834639090gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size:12pt;font-fam=
ily:times new roman, new york, times, serif;"><div><br><span></span></div><=
div><span>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but no=
thing appears on screen.</span></div>=0A</div></div></blockquote><div><br><=
/div><div>I also followed tobias (same as yours) instructions to dump and b=
uild vgabios-pt.bin into xen, did u do it also ?</div><div>&nbsp;</div><blo=
ckquote class=3D"yiv834639090gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size:12p=
t;font-family:times new roman, new york, times, serif;"><div><br><span></sp=
an></div><div><span>Strange.<br></span></div><div><br></div>  <div style=3D=
"font-family:times new roman, new york, times, serif;font-size:12pt;">=0A <=
div style=3D"font-family:times new roman, new york, times, serif;font-size:=
12pt;"> <font face=3D"Arial"><div class=3D"yiv834639090im"> <hr size=3D"1">=
  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -+=3D Lta =3D+-=
 &lt;<a rel=3D"nofollow" ymailto=3D"mailto:lta@akr.fm" target=3D"_blank" hr=
ef=3D"mailto:lta@akr.fm">lta@akr.fm</a>&gt;<br>=0A </div><b><span style=3D"=
font-weight:bold;">=C0&nbsp;:</span></b> <a rel=3D"nofollow" ymailto=3D"mai=
lto:xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mailto:xen-dev=
el@lists.xensource.com">xen-devel@lists.xensource.com</a> <br> <b><span sty=
le=3D"font-weight:bold;">Envoy=E9 le :</span></b> Vendredi 6 Janvier 2012 1=
7h48<br>=0A <b><span style=3D"font-weight:bold;">Objet&nbsp;:</span></b> [X=
en-devel] Secondary VGA Passthrough, nvidia, win7: success report.<br> </fo=
nt><div><div class=3D"yiv834639090h5"> <br><div><div>Hello xen-devel,<div><=
br></div><div><br></div><div>=0AThis is my first post on this list and as s=
uch i might be breaking some explicit/implicit rules and i apologize if it'=
s the case. Maybe this list isn't the exact&nbsp;right&nbsp;kind of place w=
here to post this kind of stuff, but i know lots of us are browsing this li=
st as the primary source of documentation for xen.</div>=0A=0A=0A<div><br><=
/div><div>I've read many times windows 7 isn't the right os to run on top o=
f xen. Most of the guy's who are running vga passthru are recommanding to u=
se windows xp, and i've never seen any success report of vga passthru on wi=
ndows 7 so i thought it was important to post mine.</div>=0A=0A=0A<div><br>=
</div><div>Anyway, here's my hardware setup :</div><div>- Gigabyte GA-990X-=
UD3</div><div>-&nbsp;AMD Phenom II X6 1075T Processor</div><div>- MSI Cyclo=
ne NVIDIA Geforce GTX 460</div><div><br></div><div>On the software side i'm=
 using :</div>=0A=0A=0A<div><br></div><div>- Debian testing as Dom0</div><d=
iv>- Xen-4.1 (debian version 4.1.2-2) with what's now referred to as "Tobia=
s Geiger patches" (<a rel=3D"nofollow" target=3D"_blank" href=3D"http://old=
-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html">http:=
//old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html</=
a>) (You have to edit the patches, changing the path to some qemu source fi=
les for them to apply)</div>=0A=0A=0A<div>- debian's kernel &nbsp;3.1.5, co=
mpiled to include the pciback driver. Here's the output of `cat /boot/my3.1=
.5config | grep -i xen`</div><div><div><font size=3D"1">CONFIG_XEN=3Dy</fon=
t></div><div>=0A<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font size=3D"=
1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_XEN_MAX=
_DOMAIN_MEMORY=3D128</font></div><div><font size=3D"1">CONFIG_XEN_SAVE_REST=
ORE=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_DEBUG_FS is not set<=
/font></div>=0A<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set</font></=
div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><font size=3D=
"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></div>=0A<div><font size=3D"1">CON=
FIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_BL=
KDEV_BACKEND=3Dm</font></div><div><font size=3D"1">CONFIG_NETXEN_NIC=3Dm</f=
ont></div>=0A<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm</font></d=
iv><div><font size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></div><div><fo=
nt size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>=0A<div><fon=
t size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XE=
N_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FRONTEND=3Dy</=
font></div>=0A<div><font size=3D"1"># Xen driver support</font></div><div><=
font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font></div><div><font size=3D"1"># =
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font size=3D"1">CONFIG_=
XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_BACKEND=3Dy=
</font></div>=0A<div><font size=3D"1">CONFIG_XENFS=3Dm</font></div><div><fo=
nt size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><font size=3D"1"=
>CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_=
XEN_XENBUS_FRONTEND=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_GNTDEV=
=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_GRANT_DEV_ALLOC=3Dm</font=
></div>=0A<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</font></div><di=
v><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><font size=3D"1"=
>CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=0A</div><div><font size=3D"1"><=
br></font></div><div>The kernel boot options are 'nomodeset xen-pciback.pas=
sthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'</div><div><br></div><di=
v>- Here's my win7 domU config file :</div>=0A=0A=0A<div><br></div><div><di=
v><font size=3D"1">kernel =3D "/usr/lib/xen-4.1/boot/hvmloader"</font></div=
><div><font size=3D"1">builder=3D'hvm'</font></div><div><font size=3D"1">me=
mory =3D 3072</font></div>=0A<div><font size=3D"1">name =3D "w7"</font></di=
v><div><font size=3D"1">vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D0=
0:16:3e:35:49:62']</font></div><div><font size=3D"1">disk =3D [ 'phy:/dev/w=
7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']</font></div>=0A=0A=0A<di=
v><font size=3D"1">device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'</font></=
div><div><font size=3D"1">boot=3D"dc"</font></div><div><font size=3D"1"><br=
>=0A</font></div><div><font size=3D"1">pci=3D['01:00.0','01:00.1']</font></=
div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><font size=3D"1=
"><br>=0A</font></div><div><font size=3D"1">vcpus=3D6</font></div><div><fon=
t size=3D"1">acpi=3D1</font></div><div><font size=3D"1">sdl=3D0</font></div=
><div><font size=3D"1">vnc=3D1</font></div>=0A<div><font size=3D"1">vnccons=
ole=3D1</font></div><div><font size=3D"1">vncpasswd=3D''</font></div><div><=
font size=3D"1">serial=3D'pty'</font></div>=0A<div><font size=3D"1">usbdevi=
ce=3D'tablet'</font></div><div><font size=3D"1">pae=3D1</font></div><div><f=
ont size=3D"1">pci_msitranslate=3D0</font></div>=0A<div><font size=3D"1">pc=
i_power_mgmt=3D0</font></div><div><font size=3D"1">acpi_s3 =3D 1</font></di=
v><div><font size=3D"1">acpi_s4 =3D 1</font></div><div><font size=3D"1">on_=
poweroff =3D 'destroy'</font></div>=0A<div><font size=3D"1">on_reboot &nbsp=
; =3D 'restart'</font></div><div><font size=3D"1">on_crash &nbsp; &nbsp;=3D=
 'restart'</font></div><div><font size=3D"1">xen_platform_pci=3D1</font></d=
iv>=0A<div><font size=3D"1">hpet =3D 1</font></div><div><font size=3D"1">vi=
ridian=3D1</font></div><div><font size=3D"1">monitor=3D1</font></div><div><=
font size=3D"1">xen_extended_power_mgmt=3D2</font></div>=0A<div><font size=
=3D"1">hpet=3D1</font></div></div><div><br></div><div>What's important here=
 for the Nvidia drivers to work and not give a nice nvlddmkm.sys BSOD is:</=
div><div><div><font size=3D"1">pci_msitranslate=3D0</font></div>=0A=0A=0A<d=
iv><font size=3D"1">pci_power_mgmt=3D0</font></div></div><div><font size=3D=
"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvidia drivers 275=
.33</div><div>- You have to manually run aero speed test or force aero to s=
tart by using registry entries for the desktop not to be laggy</div>=0A=0A=
=0A<div><br></div><div>The windows 7 domU is running fine with no performan=
ce decrease noticeable, although i've not yet played intensive gpu video ga=
me, i'm still pretty confident they'll run fine.</div><div><br>=0A=0A=0A</d=
iv><div>Anyway. i've still some problems i shall report in separate posts :=
</div><div>- The PCI bus topology isn't preserved, and the gfx card, which =
is plugged on 01:00 becomes 05:00 on domU.</div><div>- I'm passing through =
an RME Hdsp / hammerfall pci sound card to the domU and while it is working=
 fine on his own, there's a strange interaction between it and the GPLPV ne=
twork driver. When i start playing sound, the network instantly cease worki=
ng. It starts back as soon as i stop playing audio.</div>=0A=0A=0A<div><br>=
</div><div>That's all folks,</div><div><br></div><div>Cheers,</div><div>Lta=
</div>=0A</div><br>=0A</div><br></div></div><div class=3D"yiv834639090im">_=
______________________________________________<br>Xen-devel mailing list<br=
><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.xensource.com" targe=
t=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.=
xensource.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://l=
ists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a><br>=
=0A<br><br> </div></div> </div>  </div></div></blockquote></div><br>=0A</di=
v><br><br> </div> </div>  </div></div></div><br>___________________________=
____________________<br>Xen-devel mailing list<br><a rel=3D"nofollow" ymail=
to=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mailt=
o:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br><a re=
l=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensource.com/xen-dev=
el">http://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  </d=
iv></div></div><br>_______________________________________________<br>Xen-d=
evel mailing list<br><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.=
xensource.com" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.c=
om">Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow" target=3D"_bla=
nk" href=3D"http://lists.xensource.com/xen-devel">http://lists.xensource.co=
m/xen-devel</a><br><br><br> </div> </div>  </div></div></div><br>__________=
_____________________________________<br>Xen-devel mailing list<br><a
 ymailto=3D"mailto:Xen-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.co=
m/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
--62747910-923225173-1325954206=:88933--


--===============3220707573426219212==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3220707573426219212==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 16:38:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 16:38:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjZGM-0007vE-CU; Sat, 07 Jan 2012 16:36:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RjZGK-0007v9-Np
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 16:36:57 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-11.tower-21.messagelabs.com!1325954208!10512632!1
X-Originating-IP: [212.82.109.208]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 17207 invoked from network); 7 Jan 2012 16:36:48 -0000
Received: from nm25-vm7.bullet.mail.ird.yahoo.com (HELO
	nm25-vm7.bullet.mail.ird.yahoo.com) (212.82.109.208)
	by server-11.tower-21.messagelabs.com with SMTP;
	7 Jan 2012 16:36:48 -0000
Received: from [77.238.189.57] by nm25.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 16:36:47 -0000
Received: from [212.82.108.133] by tm10.bullet.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 16:36:47 -0000
Received: from [127.0.0.1] by omp1038.mail.ird.yahoo.com with NNFMP;
	07 Jan 2012 16:36:47 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 661918.76772.bm@omp1038.mail.ird.yahoo.com
Received: (qmail 89002 invoked by uid 60001); 7 Jan 2012 16:36:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1325954207; bh=LxJeQupYjZG8qGIBTClVdSNYEf0bnCMI8xt7J4bJNzE=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=3rta+Lk/ejUWRvxPka82pF1pJezaT9ooeLY8LaUSEABQud1fxGA6iz6aYSQDv24fmsnuZnTduDybMCRMJUxMRUZwIuTkBQBYhiubOozNMMaeF31yTBk9jCb+9KZxey1YR6gZgR1KzbGVX4vrPeaJQ3ctroNqAP/2XT5/b3lj9gk=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=PEU3Nq5CdzZwu6tRRsdlD5EiaB4zeQSHIfS46AQejNbIQwtDg0MA3jVmcF3lAZym9hBKDCq4ha4vWiRWVrDgbYUjoxfurNPvMKaF+E0yXgMyP57q9ldsRUMeKtr2QzDjeUkK4pM3XzHrfXzOPMEp0HaxTj+uKwjqzKUyko4QKUs=;
X-YMail-OSG: xkXa64cVM1lAio5nNqSIV5q3SmuabrgBaYyWnvVIWKDQzsO
	fX.4hPYscuAVRZdDJypgSfpsnPMMs.3dyKiAnjDFzaaJY1X9nSiZi2rNAiDW
	e6YD2ulljdg6m_HBek.ZlI3PllzsTEezWUT9ktOrhhjGzteBNrJGuOMFDbn5
	ts5i3BiWky87sqJuIzYQHGw_SciHESgeCkGsNJ2WVQd9jaKvdaKm4nJ_9I8d
	0nQUevyFYND17flsv8Z3BPedtDdCOdwBcAE6RQdVt2YY9D4pHD2IGdRFFh7H
	33q_OXA_8P7CSbrFmd0kBBo3ATft8ghWLZlBAekj8Cf7cVsDWy50TrAMIDK4
	uzj5OdIV_cnwRzQrX1WiRRpf3_zY1LqKdJJ0825kFDGGcESptDKHm2ikjsXA
	lqoyafY7FUd_4nXOTtyKWnFVQZ0DA0ukea3xUYn_kLVyh2_ouKXkWJRXycU5
	jqyXtLU_9oh9INrMYqmfM9x7BDFJB6fATdTwnG2YMujfZVPG7u13B0WjgGPc
	r9OuefYOaGrpPijlvfo6Nvipl3YQ_dsDBXDr64M_cFgdxWeB71c5MJpDU3g- -
Received: from [83.154.246.188] by web29805.mail.ird.yahoo.com via HTTP;
	Sat, 07 Jan 2012 16:36:46 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFV75=xYkVaxShXQaQ9Lwd9FOzxd5cWz8beHoE+Y9wPH7EeBsw@mail.gmail.com>
	<CAFV75=x2MHAkXutde91_wUtJjwLK_Vp_qDMejWySWpJgBEMmBw@mail.gmail.com>
	<1325888638.86498.YahooMailNeo@web29802.mail.ird.yahoo.com>
	<CAFV75=yCmWF6y84puafwKvPbaF+Wm1hD8wwBLUFXdj0sjzEUpg@mail.gmail.com>
	<1325937887.81780.YahooMailNeo@web29805.mail.ird.yahoo.com>
	<1325938952.14430.YahooMailNeo@web29805.mail.ird.yahoo.com>
	<1325947349.93467.YahooMailNeo@web29805.mail.ird.yahoo.com>
Message-ID: <1325954206.88933.YahooMailNeo@web29805.mail.ird.yahoo.com>
Date: Sat, 7 Jan 2012 16:36:46 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: David TECHER <davidtecher@yahoo.fr>, -+= Lta =+- <lta@akr.fm>
In-Reply-To: <1325947349.93467.YahooMailNeo@web29805.mail.ird.yahoo.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Re :  Re :  Re :  Re : Re :  Secondary VGA Passthrough,
	nvidia, win7: success report.
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="===============3220707573426219212=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3220707573426219212==
Content-Type: multipart/alternative; boundary="62747910-923225173-1325954206=:88933"

--62747910-923225173-1325954206=:88933
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I took the decison to stop my tests for xen 4.1.2 and VGA PassThrough.=0A=
=0AToo much problem....with Windows 7. Moreoever I came to the conclusion t=
hat it is too more unstable than VGA PassThrough on Xen 4.2=0A=0A=0ABack=A0=
 to Xen 4.2=A0 :) with XP and Linux :). No windows 7=0A=0A=0A=0A___________=
_____________________=0A De=A0: David TECHER <davidtecher@yahoo.fr>=0A=C0=
=A0: David TECHER <davidtecher@yahoo.fr>; -+=3D Lta =3D+- <lta@akr.fm> =0AC=
c=A0: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> =0AEn=
voy=E9 le : Samedi 7 Janvier 2012 15h42=0AObjet=A0: [Xen-devel] Re :  Re : =
 Re : Re :  Secondary VGA Passthrough, nvidia, win7: success report.=0A =0A=
=0AAttached=A0 are the=A0 updated Tobias patches for Xen 4.1.2.=0A=0AThe mo=
st important is 01_pass-through.patch that need to be updated :) else you r=
eceive a stupid error from compilation=0A=0A=0ASince I compiled kernel 3.1.=
6, without modules for Xen (=3DY), I have to remove 'xen-pci.passthough=3D1=
' from grub else I can not=A0 have my screen (stays black...)=0A=0A=0AI am =
doing my test on a new domU Windows 7.=0A=0AHope it will succeed :)=0A=0AI =
will let you know=0A=0A=0A=0A=0A=0A________________________________=0A De=
=A0: David TECHER <davidtecher@yahoo.fr>=0A=C0=A0: David TECHER <davidteche=
r@yahoo.fr>; -+=3D Lta =3D+- <lta@akr.fm> =0ACc=A0: "xen-devel@lists.xensou=
rce.com" <xen-devel@lists.xensource.com> =0AEnvoy=E9 le : Samedi 7 Janvier =
2012 13h22=0AObjet=A0: [Xen-devel] Re :  Re : Re :  Secondary VGA Passthrou=
gh, nvidia, win7: success report.=0A =0A=0AOk=0A=0AI think I understand wha=
t's wrong now :)=0A=0AInit build=0A=3D=3D=3D=3D=3D=3D=0A=0A=0Awget http://b=
its.xensource.com/oss-xen/release/4.1.2/xen-4.1.2.tar.gz=0Atar xzf xen-4.1.=
2.tar.gz =0Acd xen-4.1.2/=0Acd tools/=0Amake =0Amake clean =0Acd ..=0A=0ADo=
wnload patches=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0Awget -q ht=
tp://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtIj4stRFbP=
o.txt -O 01_pass-through.patch=0Awget -q http://old-list-archives.xen.org/a=
rchives/html/xen-devel/2010-05/txt06YdYEsi3S.txt -O 02_makefile.patch=0Awge=
t -q=0A http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/tx=
tS2w8cPgsnS.txt -O 03_dsdt.patch=0Awget -q http://old-list-archives.xen.org=
/archives/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader.patch=0A=
wget -q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/tx=
tiSIyxOHBZ8.txt -O 05_sound-makefile.patch=0A=0A=0AModify the first patch=
=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0AReplace the pat=
h for the good path in the first patch 01_pass-through.patch=0A=0Ased -i "s=
:tools/ioemu-remote/hw/:tools/ioemu-qemu-xen/hw/:g" 01_pass-through.patch=
=0A=0AApply patches=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0A=0A=0Aroot@mercur=
y:/opt/tmp/xen-4.1.2# for file in $(ls 0*patch);do echo "######## PATCH =3D=
 $file ############";patch -p0 < $file;done=0A######## PATCH =3D 01_pass-th=
rough.patch ############=0Apatching file tools/ioemu-qemu-xen/hw/pass-throu=
gh.c=0AHunk #1 succeeded at 22 with fuzz 2 (offset -1843 lines).=0AHunk #2 =
succeeded at 3312 (offset -55 lines).=0AHunk #3 succeeded at 3336 (offset -=
55 lines).=0AHunk #4 succeeded at 4335 with fuzz 2 (offset -144 lines).=0A#=
####### PATCH =3D 02_makefile.patch ############=0Apatching file tools/firm=
ware/hvmloader/Makefile=0A######## PATCH =3D 03_dsdt.patch ############=0Ap=
atching file tools/firmware/hvmloader/acpi/dsdt.asl=0A######## PATCH =3D 04=
_hvmloader.patch ############=0Apatching file tools/firmware/hvmloader/hvml=
oader.c=0AHunk #1 succeeded at 116 (offset 1 line).=0AHunk #2 succeeded at =
221 (offset 1 line).=0AHunk #3 succeeded at 789 (offset 60 lines).=0A######=
## PATCH =3D 05_sound-makefile.patch ############=0Apatching file=0A tools/=
ioemu-remote/xen-setup=0AHunk #1 FAILED at 16=0A=0AI will go on my tests an=
d will let you know=0A=0AThanks=0A=0ADavid=0A=0A=0A________________________=
________=0A De=A0: David TECHER <davidtecher@yahoo.fr>=0A=C0=A0: -+=3D Lta =
=3D+- <lta@akr.fm> =0ACc=A0: "xen-devel@lists.xensource.com" <xen-devel@lis=
ts.xensource.com> =0AEnvoy=E9 le : Samedi 7 Janvier 2012 13h04=0AObjet=A0: =
[Xen-devel] Re : Re :  Secondary VGA Passthrough, nvidia, win7: success rep=
ort.=0A =0A=0AI tested xen 4.1.2 too.Tobias patches are the patches I've te=
sted. I am not very lucky.=0A=0A=0ASince you used Tobias patches as me, my =
question is - to be more precise - could you sent Tobias patches that you h=
ave modified in order to checking=0AI did not forget something as you. =0A=
=0A=0AMy idea is that since I already have xen 4.2 installed, installing xe=
n 4.1.2 over this , something wrong happens=0A=0A=0AMy screen stays like a =
black screen and nothing happens. no "gfx message" in the log.=0A=0AWith Xe=
n 4.2 I tried aero desktop too but my domU crashes when=A0 I tried to activ=
ate aero.=0A=0A=0A=0A=0A________________________________=0A De=A0: -+=3D Lt=
a =3D+- <lta@akr.fm>=0A=C0=A0: David TECHER <davidtecher@yahoo.fr> =0ACc=A0=
: xen-devel@lists.xensource.com =0AEnvoy=E9 le : Samedi 7 Janvier 2012 3h17=
=0AObjet=A0: Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7: =
success report.=0A =0A=0AHi,=0A=0A=0AOn Fri, Jan 6, 2012 at 11:23 PM, David=
 TECHER <davidtecher@yahoo.fr> wrote:=0A=0ACould you tell me what version o=
f Xen? 4.1.0? 4.1.2?=0A=0AAs it is stated before this is a 4.1.2 version wi=
th debian patches=0A=A0=0A=0A>=0A>By the way could you send your patches at=
tached to a mail so I could try?=0A=0A- There's also a link to tobias patch=
e's on the first post.=0A=A0=0A=0A>=0A>Test on Xen 4.2 failed (desktop stay=
s to lag...)=0A=0AHave u tried to force windows to activate the aero deskto=
p ?=0A=A0=0A=0A>=0A>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU b=
oot but nothing appears on screen.=0A=0AI also followed tobias (same as you=
rs) instructions to dump and build vgabios-pt.bin into xen, did u do it als=
o ?=0A=A0=0A=0A>=0A>Strange.=0A>=0A>=0A>=0A>=0A>___________________________=
_____=0A> De=A0: -+=3D Lta =3D+- <lta@akr.fm>=0A>=C0=A0: xen-devel@lists.xe=
nsource.com =0A>Envoy=E9 le : Vendredi 6 Janvier 2012 17h48=0A>Objet=A0: [X=
en-devel] Secondary VGA Passthrough, nvidia, win7: success report.=0A>=0A>=
=0A>=0A>Hello xen-devel,=0A>=0A>=0A>=0A>=0A>This is my first post on this l=
ist and as such i might be breaking some explicit/implicit rules and i apol=
ogize if it's the case. Maybe this list isn't the exact=A0right=A0kind of p=
lace where to post this kind of stuff, but i know lots of us are browsing t=
his list as the primary source of documentation for xen.=0A>=0A>=0A>I've re=
ad many times windows 7 isn't the right os to run on top of xen. Most of th=
e guy's who are running vga passthru are recommanding to use windows xp, an=
d i've never seen any success report of vga passthru on windows 7 so i thou=
ght it was important to post mine.=0A>=0A>=0A>Anyway, here's my hardware se=
tup :=0A>- Gigabyte GA-990X-UD3=0A>-=A0AMD Phenom II X6 1075T Processor=0A>=
- MSI Cyclone NVIDIA Geforce GTX 460=0A>=0A>=0A>On the software side i'm us=
ing :=0A>=0A>=0A>- Debian testing as Dom0=0A>- Xen-4.1 (debian version 4.1.=
2-2) with what's now referred to as "Tobias Geiger patches" (http://old-lis=
t-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html) (You have=
 to edit the patches, changing the path to some qemu source files for them =
to apply)=0A>- debian's kernel =A03.1.5, compiled to include the pciback dr=
iver. Here's the output of `cat /boot/my3.1.5config | grep -i xen`=0A>CONFI=
G_XEN=3Dy=0A>CONFIG_XEN_DOM0=3Dy=0A>CONFIG_XEN_PRIVILEGED_GUEST=3Dy=0A>CONF=
IG_XEN_PVHVM=3Dy=0A>CONFIG_XEN_MAX_DOMAIN_MEMORY=3D128=0A>CONFIG_XEN_SAVE_R=
ESTORE=3Dy=0A># CONFIG_XEN_DEBUG_FS is not set=0A># CONFIG_XEN_DEBUG is not=
 set=0A>CONFIG_PCI_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_FRONTEND=3Dm=0A>CONFIG_XEN_=
BLKDEV_FRONTEND=3Dm=0A>CONFIG_XEN_BLKDEV_BACKEND=3Dm=0A>CONFIG_NETXEN_NIC=
=3Dm=0A>CONFIG_XEN_NETDEV_FRONTEND=3Dm=0A>CONFIG_XEN_NETDEV_BACKEND=3Dm=0A>=
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy=0A>CONFIG_HVC_XEN=3Dy=0A>CONFIG_XEN_WD=
T=3Dm=0A>CONFIG_XEN_FBDEV_FRONTEND=3Dy=0A># Xen driver support=0A>CONFIG_XE=
N_BALLOON=3Dy=0A># CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set=0A>CONFIG_X=
EN_SCRUB_PAGES=3Dy=0A>CONFIG_XEN_DEV_EVTCHN=3Dm=0A>CONFIG_XEN_BACKEND=3Dy=
=0A>CONFIG_XENFS=3Dm=0A>CONFIG_XEN_COMPAT_XENFS=3Dy=0A>CONFIG_XEN_SYS_HYPER=
VISOR=3Dy=0A>CONFIG_XEN_XENBUS_FRONTEND=3Dy=0A>CONFIG_XEN_GNTDEV=3Dm=0A>CON=
FIG_XEN_GRANT_DEV_ALLOC=3Dm=0A>CONFIG_XEN_PLATFORM_PCI=3Dm=0A>CONFIG_SWIOTL=
B_XEN=3Dy=0A>CONFIG_XEN_PCIDEV_BACKEND=3Dy=0A>=0A>=0A>The kernel boot optio=
ns are 'nomodeset xen-pciback.passthrough=3D1 xen-pciback.hide=3D(01:00.0)(=
01:00.1)'=0A>=0A>=0A>- Here's my win7 domU config file :=0A>=0A>=0A>kernel =
=3D "/usr/lib/xen-4.1/boot/hvmloader"=0A>builder=3D'hvm'=0A>memory =3D 3072=
=0A>name =3D "w7"=0A>vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D00:1=
6:3e:35:49:62']=0A>disk =3D [ 'phy:/dev/w7-xen/system,hda,w', 'phy:/dev/w7-=
xen/appz,hdb,w']=0A>device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'=0A>boot=
=3D"dc"=0A>=0A>=0A>pci=3D['01:00.0','01:00.1']=0A>gfx_passthru=3D1=0A>=0A>=
=0A>vcpus=3D6=0A>acpi=3D1=0A>sdl=3D0=0A>vnc=3D1=0A>vncconsole=3D1=0A>vncpas=
swd=3D''=0A>serial=3D'pty'=0A>usbdevice=3D'tablet'=0A>pae=3D1=0A>pci_msitra=
nslate=3D0=0A>pci_power_mgmt=3D0=0A>acpi_s3 =3D 1=0A>acpi_s4 =3D 1=0A>on_po=
weroff =3D 'destroy'=0A>on_reboot =A0 =3D 'restart'=0A>on_crash =A0 =A0=3D =
'restart'=0A>xen_platform_pci=3D1=0A>hpet =3D 1=0A>viridian=3D1=0A>monitor=
=3D1=0A>xen_extended_power_mgmt=3D2=0A>hpet=3D1=0A>=0A>=0A>What's important=
 here for the Nvidia drivers to work and not give a nice nvlddmkm.sys BSOD =
is:=0A>pci_msitranslate=3D0=0A>pci_power_mgmt=3D0=0A>=0A>=0A>- Windows 7 32=
bits=0A>- Nvidia drivers 275.33=0A>- You have to manually run aero speed te=
st or force aero to start by using registry entries for the desktop not to =
be laggy=0A>=0A>=0A>The windows 7 domU is running fine with no performance =
decrease noticeable, although i've not yet played intensive gpu video game,=
 i'm still pretty confident they'll run fine.=0A>=0A>=0A>Anyway. i've still=
 some problems i shall report in separate posts :=0A>- The PCI bus topology=
 isn't preserved, and the gfx card, which is plugged on 01:00 becomes 05:00=
 on domU.=0A>- I'm passing through an RME Hdsp / hammerfall pci sound card =
to the domU and while it is working fine on his own, there's a strange inte=
raction between it and the GPLPV network driver. When i start playing sound=
, the network instantly cease working. It starts back as soon as i stop pla=
ying audio.=0A>=0A>=0A>That's all folks,=0A>=0A>=0A>Cheers,=0A>Lta=0A>=0A>=
=0A>_______________________________________________=0A>Xen-devel mailing li=
st=0A>Xen-devel@lists.xensource.com=0A>http://lists.xensource.com/xen-devel=
=0A>=0A>=0A>=0A=0A=0A=0A_______________________________________________=0AX=
en-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensou=
rce.com/xen-devel=0A=0A=0A=0A______________________________________________=
_=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://lists.x=
ensource.com/xen-devel=0A=0A=0A=0A_________________________________________=
______=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp://li=
sts.xensource.com/xen-devel
--62747910-923225173-1325954206=:88933
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>I took the=
 decison to stop my tests for xen 4.1.2 and VGA PassThrough.</span></div><d=
iv><br><span></span></div><div><span>Too much problem....with Windows 7. Mo=
reoever I came to the conclusion that it is too more unstable than VGA Pass=
Through on Xen 4.2<br></span></div><div><br><span></span></div><div><span>B=
ack&nbsp; to Xen 4.2&nbsp; :) with XP and Linux :). No windows 7<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 rom=
an, 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> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><span style=3D"font-w=
eight: bold;">=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&g=
t;; -+=3D
 Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span style=3D"font-weight: bold;">Cc&=
nbsp;:</span></b> "xen-devel@lists.xensource.com" &lt;xen-devel@lists.xenso=
urce.com&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=E9 le :</span=
></b> Samedi 7 Janvier 2012 15h42<br> <b><span style=3D"font-weight: bold;"=
>Objet&nbsp;:</span></b> [Xen-devel] Re :  Re :  Re : Re :  Secondary VGA P=
assthrough, nvidia, win7: success report.<br> </font> <br><div id=3D"yiv834=
639090"><div><div style=3D"color:#000;background-color:#fff;font-family:tim=
es new roman, new york, times, serif;font-size:12pt;"><div><span>Attached&n=
bsp; are the&nbsp; updated Tobias patches for Xen 4.1.2.</span></div><div><=
br><span></span></div><div><span>The most important is 01_pass-through.patc=
h that need to be updated :) else you receive a stupid error from compilati=
on<br></span></div><div><br><span></span></div><div><span>Since I compiled =
kernel 3.1.6, without modules for Xen (=3DY), I have to remove
 'xen-pci.passthough=3D1' from grub else I can not&nbsp; have my screen (st=
ays black...)<br></span></div><div><br><span></span></div><div><span>I am d=
oing my test on a new domU Windows 7.</span></div><div><br><span></span></d=
iv><div><span>Hope it will succeed :)</span></div><div><br><span></span></d=
iv><div><span>I will let you know<br></span></div><div><br><span></span></d=
iv><div><span><br></span></div><div><br></div>  <div style=3D"font-family:t=
imes 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 fac=
e=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-weight:bold=
;">De&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><s=
pan style=3D"font-weight:bold;">=C0&nbsp;:</span></b> David TECHER &lt;davi=
dtecher@yahoo.fr&gt;; -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b><span style=
=3D"font-weight:bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xensource.com"
 &lt;xen-devel@lists.xensource.com&gt; <br> <b><span style=3D"font-weight:b=
old;">Envoy=E9 le :</span></b> Samedi 7 Janvier 2012 13h22<br> <b><span sty=
le=3D"font-weight:bold;">Objet&nbsp;:</span></b> [Xen-devel] Re :  Re : Re =
:  Secondary VGA Passthrough, nvidia, win7: success report.<br> </font> <br=
><div id=3D"yiv834639090"><div><div style=3D"color:#000;background-color:#f=
ff;font-family:times new roman, new york, times, serif;font-size:12pt;"><di=
v><span>Ok</span></div><div><br><span></span></div><div><span>I think I und=
erstand what's wrong now :)</span></div><div><br><span></span></div><div>In=
it build</div><div>=3D=3D=3D=3D=3D=3D<br></div><div><br><span></span></div>=
<div><span>wget http://bits.xensource.com/oss-xen/release/4.1.2/xen-4.1.2.t=
ar.gz<br>tar xzf xen-4.1.2.tar.gz <br>cd xen-4.1.2/<br>cd tools/<br>make <b=
r>make clean <br>cd ..</span></div><div><span><br></span></div><div><span>D=
ownload patches<br></span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br></span></div><div><span>wget
 -q http://old-list-archives.xen.org/archives/html/xen-devel/2010-05/txtIj4=
stRFbPo.txt -O 01_pass-through.patch<br>wget -q http://old-list-archives.xe=
n.org/archives/html/xen-devel/2010-05/txt06YdYEsi3S.txt -O 02_makefile.patc=
h<br>wget -q=0A http://old-list-archives.xen.org/archives/html/xen-devel/20=
10-05/txtS2w8cPgsnS.txt -O 03_dsdt.patch<br>wget -q http://old-list-archive=
s.xen.org/archives/html/xen-devel/2010-05/txt2am6wEpoR5.txt -O 04_hvmloader=
.patch<br>wget -q http://old-list-archives.xen.org/archives/html/xen-devel/=
2010-05/txtiSIyxOHBZ8.txt -O 05_sound-makefile.patch<br></span></div><div><=
br><span></span></div><div><span>Modify the first patch</span></div><div><s=
pan>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br></span></div><div><=
span><br></span></div><div><span>Replace the path for the good path in the =
first patch </span><span>01_pass-through.patch</span></div><div><span><br><=
/span></div><div><span>sed -i "s:tools/ioemu-remote/hw/:tools/ioemu-qemu-xe=
n/hw/:g" 01_pass-through.patch</span></div><div><br><span></span></div><div=
><span>Apply patches</span></div><div><span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
br></span></div><div><span><br></span></div><div><span><br></span></div><di=
v><span>root@mercury:/opt/tmp/xen-4.1.2# for file in $(ls=0A 0*patch);do ec=
ho "######## PATCH =3D $file ############";patch -p0 &lt; $file;done<br>###=
##### PATCH =3D 01_pass-through.patch ############<br>patching file tools/i=
oemu-qemu-xen/hw/pass-through.c<br>Hunk #1 succeeded at 22 with fuzz 2 (off=
set -1843 lines).<br>Hunk #2 succeeded at 3312 (offset -55 lines).<br>Hunk =
#3 succeeded at 3336 (offset -55 lines).<br>Hunk #4 succeeded at 4335 with =
fuzz 2 (offset -144 lines).<br>######## PATCH =3D 02_makefile.patch #######=
#####<br>patching file tools/firmware/hvmloader/Makefile<br>######## PATCH =
=3D 03_dsdt.patch ############<br>patching file tools/firmware/hvmloader/ac=
pi/dsdt.asl<br>######## PATCH =3D 04_hvmloader.patch ############<br>patchi=
ng file tools/firmware/hvmloader/hvmloader.c<br>Hunk #1 succeeded at 116 (o=
ffset 1 line).<br>Hunk #2 succeeded at 221 (offset 1 line).<br>Hunk #3 succ=
eeded at 789 (offset 60 lines).<br>######## PATCH =3D 05_sound-makefile.pat=
ch ############<br>patching file=0A tools/ioemu-remote/xen-setup<br>Hunk #1=
 FAILED at 16</span></div><div><br><span></span></div><div><span>I will go =
on my tests and will let you know</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-family:times new roman, new =
york, times, serif;font-size:12pt;"> <div style=3D"font-family:times new ro=
man, 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> David TECHER &lt;davidtecher@yahoo.fr&gt;<br> <b><span style=3D"font-we=
ight:bold;">=C0&nbsp;:</span></b> -+=3D Lta =3D+- &lt;lta@akr.fm&gt; <br><b=
><span style=3D"font-weight:bold;">Cc&nbsp;:</span></b> "xen-devel@lists.xe=
nsource.com" &lt;xen-devel@lists.xensource.com&gt; <br> <b><span style=3D"f=
ont-weight:bold;">Envoy=E9 le :</span></b> Samedi 7 Janvier 2012 13h04<br> =
<b><span
 style=3D"font-weight:bold;">Objet&nbsp;:</span></b> [Xen-devel] Re : Re : =
 Secondary VGA Passthrough, nvidia, win7: success report.<br> </font> <br><=
div id=3D"yiv834639090"><div><div style=3D"color:#000;background-color:#fff=
;font-family:times new roman, new york, times, serif;font-size:12pt;"><div>=
<span>I tested xen 4.1.2 too.</span><span> Tobias patches are the patches I=
've tested. I am not very lucky.<br></span></div><div><span><br></span></di=
v><div><span>Since you used Tobias patches as me, my question is - to be mo=
re precise - could you sent Tobias patches that you have modified in order =
to checking</span></div><div><span>I did not forget something as you. <br><=
/span></div><div><br><span></span></div><div><span>My idea is that since I =
already have xen 4.2 installed, installing xen 4.1.2 over this , something =
wrong happens<br></span></div><div><br><span></span></div><div><span>My scr=
een stays like a black screen and nothing happens. no "gfx message" in the=
=0A log.</span></div><div><br><span></span></div><div><span>With Xen 4.2 I =
tried aero desktop too but my domU crashes when&nbsp; I tried to activate=
=0A aero.<br></span></div><div><br><span></span></div><div><span></span></d=
iv><div><br></div>  <div style=3D"font-family:times new roman, new york, ti=
mes, 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> -+=
=3D Lta =3D+- &lt;lta@akr.fm&gt;<br> <b><span style=3D"font-weight:bold;">=
=C0&nbsp;:</span></b> David TECHER &lt;davidtecher@yahoo.fr&gt; <br><b><spa=
n style=3D"font-weight:bold;">Cc&nbsp;:</span></b> xen-devel@lists.xensourc=
e.com <br> <b><span style=3D"font-weight:bold;">Envoy=E9 le :</span></b> Sa=
medi 7 Janvier 2012 3h17<br> <b><span style=3D"font-weight:bold;">Objet&nbs=
p;:</span></b> Re: Re : [Xen-devel] Secondary VGA Passthrough, nvidia, win7=
: success report.<br> </font> <br><div id=3D"yiv834639090">Hi,<br><br><div =
class=3D"yiv834639090gmail_quote">On Fri, Jan 6, 2012 at 11:23 PM, David TE=
CHER <span dir=3D"ltr">&lt;<a
 rel=3D"nofollow" ymailto=3D"mailto:davidtecher@yahoo.fr" target=3D"_blank"=
 href=3D"mailto:davidtecher@yahoo.fr">davidtecher@yahoo.fr</a>&gt;</span> w=
rote:<br><blockquote class=3D"yiv834639090gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"=
font-size:12pt;font-family:times new roman, new york, times, serif;"><div><=
span>Could you tell me what version of Xen? 4.1.0? 4.1.2?</span></div></div=
></div></blockquote><div><br></div><div>As it is stated before this is a 4.=
1.2 version with debian patches</div>=0A<div>&nbsp;</div><blockquote class=
=3D"yiv834639090gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex;"><div><div style=3D"font-size:12pt;font-family:ti=
mes new roman, new york, times, serif;"><div><br><span></span></div>=0A<div=
><span>By the way could you send your patches attached to a mail so I could=
 try?</span></div></div></div></blockquote><div><br></div><div>- There's al=
so a link to tobias patche's on the first post.</div><div>&nbsp;</div>=0A<b=
lockquote class=3D"yiv834639090gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex;"><div><div style=3D"font-size:12pt=
;font-family:times new roman, new york, times, serif;"><div><br><span></spa=
n></div><div><span>Test on Xen 4.2 failed (desktop stays to lag...)</span><=
/div>=0A</div></div></blockquote><div><br></div><div>Have u tried to force =
windows to activate the aero desktop ?</div><div>&nbsp;</div><blockquote cl=
ass=3D"yiv834639090gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size:12pt;font-fam=
ily:times new roman, new york, times, serif;"><div><br><span></span></div><=
div><span>With installing xen 4.1.0/4.2.0 over my xen 4.2, domU boot but no=
thing appears on screen.</span></div>=0A</div></div></blockquote><div><br><=
/div><div>I also followed tobias (same as yours) instructions to dump and b=
uild vgabios-pt.bin into xen, did u do it also ?</div><div>&nbsp;</div><blo=
ckquote class=3D"yiv834639090gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex;">=0A<div><div style=3D"font-size:12p=
t;font-family:times new roman, new york, times, serif;"><div><br><span></sp=
an></div><div><span>Strange.<br></span></div><div><br></div>  <div style=3D=
"font-family:times new roman, new york, times, serif;font-size:12pt;">=0A <=
div style=3D"font-family:times new roman, new york, times, serif;font-size:=
12pt;"> <font face=3D"Arial"><div class=3D"yiv834639090im"> <hr size=3D"1">=
  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> -+=3D Lta =3D+-=
 &lt;<a rel=3D"nofollow" ymailto=3D"mailto:lta@akr.fm" target=3D"_blank" hr=
ef=3D"mailto:lta@akr.fm">lta@akr.fm</a>&gt;<br>=0A </div><b><span style=3D"=
font-weight:bold;">=C0&nbsp;:</span></b> <a rel=3D"nofollow" ymailto=3D"mai=
lto:xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mailto:xen-dev=
el@lists.xensource.com">xen-devel@lists.xensource.com</a> <br> <b><span sty=
le=3D"font-weight:bold;">Envoy=E9 le :</span></b> Vendredi 6 Janvier 2012 1=
7h48<br>=0A <b><span style=3D"font-weight:bold;">Objet&nbsp;:</span></b> [X=
en-devel] Secondary VGA Passthrough, nvidia, win7: success report.<br> </fo=
nt><div><div class=3D"yiv834639090h5"> <br><div><div>Hello xen-devel,<div><=
br></div><div><br></div><div>=0AThis is my first post on this list and as s=
uch i might be breaking some explicit/implicit rules and i apologize if it'=
s the case. Maybe this list isn't the exact&nbsp;right&nbsp;kind of place w=
here to post this kind of stuff, but i know lots of us are browsing this li=
st as the primary source of documentation for xen.</div>=0A=0A=0A<div><br><=
/div><div>I've read many times windows 7 isn't the right os to run on top o=
f xen. Most of the guy's who are running vga passthru are recommanding to u=
se windows xp, and i've never seen any success report of vga passthru on wi=
ndows 7 so i thought it was important to post mine.</div>=0A=0A=0A<div><br>=
</div><div>Anyway, here's my hardware setup :</div><div>- Gigabyte GA-990X-=
UD3</div><div>-&nbsp;AMD Phenom II X6 1075T Processor</div><div>- MSI Cyclo=
ne NVIDIA Geforce GTX 460</div><div><br></div><div>On the software side i'm=
 using :</div>=0A=0A=0A<div><br></div><div>- Debian testing as Dom0</div><d=
iv>- Xen-4.1 (debian version 4.1.2-2) with what's now referred to as "Tobia=
s Geiger patches" (<a rel=3D"nofollow" target=3D"_blank" href=3D"http://old=
-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html">http:=
//old-list-archives.xen.org/archives/html/xen-devel/2010-05/msg00441.html</=
a>) (You have to edit the patches, changing the path to some qemu source fi=
les for them to apply)</div>=0A=0A=0A<div>- debian's kernel &nbsp;3.1.5, co=
mpiled to include the pciback driver. Here's the output of `cat /boot/my3.1=
.5config | grep -i xen`</div><div><div><font size=3D"1">CONFIG_XEN=3Dy</fon=
t></div><div>=0A<font size=3D"1">CONFIG_XEN_DOM0=3Dy</font></div><div><font=
 size=3D"1">CONFIG_XEN_PRIVILEGED_GUEST=3Dy</font></div><div><font size=3D"=
1">CONFIG_XEN_PVHVM=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_XEN_MAX=
_DOMAIN_MEMORY=3D128</font></div><div><font size=3D"1">CONFIG_XEN_SAVE_REST=
ORE=3Dy</font></div><div><font size=3D"1"># CONFIG_XEN_DEBUG_FS is not set<=
/font></div>=0A<div><font size=3D"1"># CONFIG_XEN_DEBUG is not set</font></=
div><div><font size=3D"1">CONFIG_PCI_XEN=3Dy</font></div><div><font size=3D=
"1">CONFIG_XEN_PCIDEV_FRONTEND=3Dm</font></div>=0A<div><font size=3D"1">CON=
FIG_XEN_BLKDEV_FRONTEND=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_BL=
KDEV_BACKEND=3Dm</font></div><div><font size=3D"1">CONFIG_NETXEN_NIC=3Dm</f=
ont></div>=0A<div><font size=3D"1">CONFIG_XEN_NETDEV_FRONTEND=3Dm</font></d=
iv><div><font size=3D"1">CONFIG_XEN_NETDEV_BACKEND=3Dm</font></div><div><fo=
nt size=3D"1">CONFIG_INPUT_XEN_KBDDEV_FRONTEND=3Dy</font></div>=0A<div><fon=
t size=3D"1">CONFIG_HVC_XEN=3Dy</font></div><div><font size=3D"1">CONFIG_XE=
N_WDT=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_FBDEV_FRONTEND=3Dy</=
font></div>=0A<div><font size=3D"1"># Xen driver support</font></div><div><=
font size=3D"1">CONFIG_XEN_BALLOON=3Dy</font></div><div><font size=3D"1"># =
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set</font></div>=0A<div><font size=
=3D"1">CONFIG_XEN_SCRUB_PAGES=3Dy</font></div><div><font size=3D"1">CONFIG_=
XEN_DEV_EVTCHN=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_BACKEND=3Dy=
</font></div>=0A<div><font size=3D"1">CONFIG_XENFS=3Dm</font></div><div><fo=
nt size=3D"1">CONFIG_XEN_COMPAT_XENFS=3Dy</font></div><div><font size=3D"1"=
>CONFIG_XEN_SYS_HYPERVISOR=3Dy</font></div>=0A<div><font size=3D"1">CONFIG_=
XEN_XENBUS_FRONTEND=3Dy</font></div><div><font size=3D"1">CONFIG_XEN_GNTDEV=
=3Dm</font></div><div><font size=3D"1">CONFIG_XEN_GRANT_DEV_ALLOC=3Dm</font=
></div>=0A<div><font size=3D"1">CONFIG_XEN_PLATFORM_PCI=3Dm</font></div><di=
v><font size=3D"1">CONFIG_SWIOTLB_XEN=3Dy</font></div><div><font size=3D"1"=
>CONFIG_XEN_PCIDEV_BACKEND=3Dy</font></div>=0A</div><div><font size=3D"1"><=
br></font></div><div>The kernel boot options are 'nomodeset xen-pciback.pas=
sthrough=3D1 xen-pciback.hide=3D(01:00.0)(01:00.1)'</div><div><br></div><di=
v>- Here's my win7 domU config file :</div>=0A=0A=0A<div><br></div><div><di=
v><font size=3D"1">kernel =3D "/usr/lib/xen-4.1/boot/hvmloader"</font></div=
><div><font size=3D"1">builder=3D'hvm'</font></div><div><font size=3D"1">me=
mory =3D 3072</font></div>=0A<div><font size=3D"1">name =3D "w7"</font></di=
v><div><font size=3D"1">vif =3D [ 'type=3Dnetfront,bridge=3Dxenbr0, mac=3D0=
0:16:3e:35:49:62']</font></div><div><font size=3D"1">disk =3D [ 'phy:/dev/w=
7-xen/system,hda,w', 'phy:/dev/w7-xen/appz,hdb,w']</font></div>=0A=0A=0A<di=
v><font size=3D"1">device_model =3D '/usr/lib/xen-4.1/bin/qemu-dm'</font></=
div><div><font size=3D"1">boot=3D"dc"</font></div><div><font size=3D"1"><br=
>=0A</font></div><div><font size=3D"1">pci=3D['01:00.0','01:00.1']</font></=
div><div><font size=3D"1">gfx_passthru=3D1</font></div><div><font size=3D"1=
"><br>=0A</font></div><div><font size=3D"1">vcpus=3D6</font></div><div><fon=
t size=3D"1">acpi=3D1</font></div><div><font size=3D"1">sdl=3D0</font></div=
><div><font size=3D"1">vnc=3D1</font></div>=0A<div><font size=3D"1">vnccons=
ole=3D1</font></div><div><font size=3D"1">vncpasswd=3D''</font></div><div><=
font size=3D"1">serial=3D'pty'</font></div>=0A<div><font size=3D"1">usbdevi=
ce=3D'tablet'</font></div><div><font size=3D"1">pae=3D1</font></div><div><f=
ont size=3D"1">pci_msitranslate=3D0</font></div>=0A<div><font size=3D"1">pc=
i_power_mgmt=3D0</font></div><div><font size=3D"1">acpi_s3 =3D 1</font></di=
v><div><font size=3D"1">acpi_s4 =3D 1</font></div><div><font size=3D"1">on_=
poweroff =3D 'destroy'</font></div>=0A<div><font size=3D"1">on_reboot &nbsp=
; =3D 'restart'</font></div><div><font size=3D"1">on_crash &nbsp; &nbsp;=3D=
 'restart'</font></div><div><font size=3D"1">xen_platform_pci=3D1</font></d=
iv>=0A<div><font size=3D"1">hpet =3D 1</font></div><div><font size=3D"1">vi=
ridian=3D1</font></div><div><font size=3D"1">monitor=3D1</font></div><div><=
font size=3D"1">xen_extended_power_mgmt=3D2</font></div>=0A<div><font size=
=3D"1">hpet=3D1</font></div></div><div><br></div><div>What's important here=
 for the Nvidia drivers to work and not give a nice nvlddmkm.sys BSOD is:</=
div><div><div><font size=3D"1">pci_msitranslate=3D0</font></div>=0A=0A=0A<d=
iv><font size=3D"1">pci_power_mgmt=3D0</font></div></div><div><font size=3D=
"1"><br></font></div><div>- Windows 7 32bits</div><div>- Nvidia drivers 275=
.33</div><div>- You have to manually run aero speed test or force aero to s=
tart by using registry entries for the desktop not to be laggy</div>=0A=0A=
=0A<div><br></div><div>The windows 7 domU is running fine with no performan=
ce decrease noticeable, although i've not yet played intensive gpu video ga=
me, i'm still pretty confident they'll run fine.</div><div><br>=0A=0A=0A</d=
iv><div>Anyway. i've still some problems i shall report in separate posts :=
</div><div>- The PCI bus topology isn't preserved, and the gfx card, which =
is plugged on 01:00 becomes 05:00 on domU.</div><div>- I'm passing through =
an RME Hdsp / hammerfall pci sound card to the domU and while it is working=
 fine on his own, there's a strange interaction between it and the GPLPV ne=
twork driver. When i start playing sound, the network instantly cease worki=
ng. It starts back as soon as i stop playing audio.</div>=0A=0A=0A<div><br>=
</div><div>That's all folks,</div><div><br></div><div>Cheers,</div><div>Lta=
</div>=0A</div><br>=0A</div><br></div></div><div class=3D"yiv834639090im">_=
______________________________________________<br>Xen-devel mailing list<br=
><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.xensource.com" targe=
t=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.com">Xen-devel@lists.=
xensource.com</a><br><a rel=3D"nofollow" target=3D"_blank" href=3D"http://l=
ists.xensource.com/xen-devel">http://lists.xensource.com/xen-devel</a><br>=
=0A<br><br> </div></div> </div>  </div></div></blockquote></div><br>=0A</di=
v><br><br> </div> </div>  </div></div></div><br>___________________________=
____________________<br>Xen-devel mailing list<br><a rel=3D"nofollow" ymail=
to=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank" href=3D"mailt=
o:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br><a re=
l=3D"nofollow" target=3D"_blank" href=3D"http://lists.xensource.com/xen-dev=
el">http://lists.xensource.com/xen-devel</a><br><br><br> </div> </div>  </d=
iv></div></div><br>_______________________________________________<br>Xen-d=
evel mailing list<br><a rel=3D"nofollow" ymailto=3D"mailto:Xen-devel@lists.=
xensource.com" target=3D"_blank" href=3D"mailto:Xen-devel@lists.xensource.c=
om">Xen-devel@lists.xensource.com</a><br><a rel=3D"nofollow" target=3D"_bla=
nk" href=3D"http://lists.xensource.com/xen-devel">http://lists.xensource.co=
m/xen-devel</a><br><br><br> </div> </div>  </div></div></div><br>__________=
_____________________________________<br>Xen-devel mailing list<br><a
 ymailto=3D"mailto:Xen-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.co=
m/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
--62747910-923225173-1325954206=:88933--


--===============3220707573426219212==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3220707573426219212==--


From xen-devel-bounces@lists.xensource.com Sat Jan 07 22:42:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 22:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rjex8-00018z-Cc; Sat, 07 Jan 2012 22:41:30 +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 1Rjex6-00018u-OP
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 22:41:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325976079!9985359!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 32198 invoked from network); 7 Jan 2012 22:41:21 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jan 2012 22:41:21 -0000
Received: by daec6 with SMTP id c6so10019225dae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 07 Jan 2012 14:41: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;
	bh=l/uxNvmKK39vEyRf9IGdQXIs2tsIv/BSGvhfSEpg/aM=;
	b=f848dOXNOn3sKBdoejnmbln8U5mbcIRcQSPqYipBbmAMDoKTRNDu5l4CeEwpwvt3PM
	QGjxaHz9y+UWlNdKf644sY6zMsOiplv8RCpCunlDaZZuW4I9Y+sfS5IbdO/q2vp4/JJS
	enaGxU6TuOTJtSo0Fu7+oEaNkFb+v9I0oZIWE=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr26985221pbc.77.1325976079046; Sat,
	07 Jan 2012 14:41:19 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Sat, 7 Jan 2012 14:41:18 -0800 (PST)
In-Reply-To: <4F071654.3000102@amd.com>
References: <4F071654.3000102@amd.com>
Date: Sat, 7 Jan 2012 23:41:18 +0100
X-Google-Sender-Auth: VEC94RdlAzU_07E-dDra_EUHpyI
Message-ID: <CAPLaKK6fyj_1uH5dS53x6tGi_QwXKD=3fLqQTjtO9dyqj06U6A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] netbsd: disable CONFIG_SYSTEM_LIBAIO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/6 Christoph Egger <Christoph.Egger@amd.com>:
>
> Disable CONFIG_SYSTEM_LIBAIO on NetBSD.
>
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Although this probably won't be necessary once we migrate to autoconf
and are able to detect system configuration properly.

>
> --
> ---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
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 22:42:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 22:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rjex8-00018z-Cc; Sat, 07 Jan 2012 22:41:30 +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 1Rjex6-00018u-OP
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 22:41:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1325976079!9985359!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 32198 invoked from network); 7 Jan 2012 22:41:21 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	7 Jan 2012 22:41:21 -0000
Received: by daec6 with SMTP id c6so10019225dae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 07 Jan 2012 14:41: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;
	bh=l/uxNvmKK39vEyRf9IGdQXIs2tsIv/BSGvhfSEpg/aM=;
	b=f848dOXNOn3sKBdoejnmbln8U5mbcIRcQSPqYipBbmAMDoKTRNDu5l4CeEwpwvt3PM
	QGjxaHz9y+UWlNdKf644sY6zMsOiplv8RCpCunlDaZZuW4I9Y+sfS5IbdO/q2vp4/JJS
	enaGxU6TuOTJtSo0Fu7+oEaNkFb+v9I0oZIWE=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr26985221pbc.77.1325976079046; Sat,
	07 Jan 2012 14:41:19 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Sat, 7 Jan 2012 14:41:18 -0800 (PST)
In-Reply-To: <4F071654.3000102@amd.com>
References: <4F071654.3000102@amd.com>
Date: Sat, 7 Jan 2012 23:41:18 +0100
X-Google-Sender-Auth: VEC94RdlAzU_07E-dDra_EUHpyI
Message-ID: <CAPLaKK6fyj_1uH5dS53x6tGi_QwXKD=3fLqQTjtO9dyqj06U6A@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Christoph Egger <Christoph.Egger@amd.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] netbsd: disable CONFIG_SYSTEM_LIBAIO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/6 Christoph Egger <Christoph.Egger@amd.com>:
>
> Disable CONFIG_SYSTEM_LIBAIO on NetBSD.
>
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

Acked-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Although this probably won't be necessary once we migrate to autoconf
and are able to detect system configuration properly.

>
> --
> ---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
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 23:43:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 23: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 1RjfuQ-0001Th-85; Sat, 07 Jan 2012 23:42:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RjfuP-0001Tc-1I
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 23:42:45 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325979716!59290410!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 30340 invoked from network); 7 Jan 2012 23:41:59 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Jan 2012 23:41:59 -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 1Rjfu9-00026J-RG; Sun, 08 Jan 2012 10:42:29 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 8 Jan 2012 10:42:30 +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;
	Sun, 8 Jan 2012 10:42:30 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Thread-Topic: [Xen-devel] usbback for linux 3.1?
Thread-Index: AQHMzUVqvtJ5K7lCm0e9BbivaXkXr5YBkQcQ
Date: Sat, 7 Jan 2012 23:42:26 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B098C99@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
	<20120107140514.GC12984@reaktio.net>
In-Reply-To: <20120107140514.GC12984@reaktio.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Jan 2012 23:42:30.0025 (UTC)
	FILETIME=[050A4790:01CCCD96]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] usbback for linux 3.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 Sat, Jan 07, 2012 at 02:28:24AM +0000, James Harper wrote:
> > Is anyone maintaining usbback that compiles against Linux 3.1?
> >
> 
> I think Konrad tried to forward-port the 2.6.32 pvops pvusb patch to 3.x, but
> it didn't work (compile?) out-of-the-box.
> 
> pvusb patch for 2.6.32 pvops is here:
> http://members.iinet.net.au/~nathanael/pvusb.diff
> (http://lists.xensource.com/archives/html/xen-devel/2011-
> 01/msg00354.html)
> 
> Maybe try it and see if it's trivial to fix it..
> 

I've got it building and loading against 3.1 now, but I'm not sure its working properly as I don't have any frontend to test it against except gplpv and that's probably a bad measure at this time.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 07 23:43:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 07 Jan 2012 23: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 1RjfuQ-0001Th-85; Sat, 07 Jan 2012 23:42:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RjfuP-0001Tc-1I
	for xen-devel@lists.xensource.com; Sat, 07 Jan 2012 23:42:45 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-27.messagelabs.com!1325979716!59290410!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 30340 invoked from network); 7 Jan 2012 23:41:59 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-9.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	7 Jan 2012 23:41:59 -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 1Rjfu9-00026J-RG; Sun, 08 Jan 2012 10:42:29 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 8 Jan 2012 10:42:30 +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;
	Sun, 8 Jan 2012 10:42:30 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Thread-Topic: [Xen-devel] usbback for linux 3.1?
Thread-Index: AQHMzUVqvtJ5K7lCm0e9BbivaXkXr5YBkQcQ
Date: Sat, 7 Jan 2012 23:42:26 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B098C99@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
	<20120107140514.GC12984@reaktio.net>
In-Reply-To: <20120107140514.GC12984@reaktio.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Jan 2012 23:42:30.0025 (UTC)
	FILETIME=[050A4790:01CCCD96]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] usbback for linux 3.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 Sat, Jan 07, 2012 at 02:28:24AM +0000, James Harper wrote:
> > Is anyone maintaining usbback that compiles against Linux 3.1?
> >
> 
> I think Konrad tried to forward-port the 2.6.32 pvops pvusb patch to 3.x, but
> it didn't work (compile?) out-of-the-box.
> 
> pvusb patch for 2.6.32 pvops is here:
> http://members.iinet.net.au/~nathanael/pvusb.diff
> (http://lists.xensource.com/archives/html/xen-devel/2011-
> 01/msg00354.html)
> 
> Maybe try it and see if it's trivial to fix it..
> 

I've got it building and loading against 3.1 now, but I'm not sure its working properly as I don't have any frontend to test it against except gplpv and that's probably a bad measure at this time.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 08 01:07:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 01:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjhDs-00063a-Mv; Sun, 08 Jan 2012 01:06:56 +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 1RjhDq-00063V-Ha
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 01:06:54 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325984808!8179431!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDAwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15014 invoked from network); 8 Jan 2012 01:06:48 -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; 8 Jan 2012 01:06: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 456CE1048;
	Sun,  8 Jan 2012 03:06:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A7E4D20058; Sun,  8 Jan 2012 03:06:46 +0200 (EET)
Date: Sun, 8 Jan 2012 03:06:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120108010646.GD12984@reaktio.net>
References: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
	<20120107140514.GC12984@reaktio.net>
	<6035A0D088A63A46850C3988ED045A4B098C99@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B098C99@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] usbback for linux 3.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 Sat, Jan 07, 2012 at 11:42:26PM +0000, James Harper wrote:
> > 
> > On Sat, Jan 07, 2012 at 02:28:24AM +0000, James Harper wrote:
> > > Is anyone maintaining usbback that compiles against Linux 3.1?
> > >
> > 
> > I think Konrad tried to forward-port the 2.6.32 pvops pvusb patch to 3.x, but
> > it didn't work (compile?) out-of-the-box.
> > 
> > pvusb patch for 2.6.32 pvops is here:
> > http://members.iinet.net.au/~nathanael/pvusb.diff
> > (http://lists.xensource.com/archives/html/xen-devel/2011-
> > 01/msg00354.html)
> > 
> > Maybe try it and see if it's trivial to fix it..
> > 
> 
> I've got it building and loading against 3.1 now, but I'm not sure its working properly as I don't have any frontend to test it against except gplpv and that's probably a bad measure at this time.
> 

Great! The patch also includes xen-usbfront frontend driver for Linux..
so you can try it on a Linux domU.

btw. Please post the forward-ported patch.. 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 08 01:07:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 01:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjhDs-00063a-Mv; Sun, 08 Jan 2012 01:06:56 +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 1RjhDq-00063V-Ha
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 01:06:54 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-174.messagelabs.com!1325984808!8179431!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDAwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15014 invoked from network); 8 Jan 2012 01:06:48 -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; 8 Jan 2012 01:06: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 456CE1048;
	Sun,  8 Jan 2012 03:06:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id A7E4D20058; Sun,  8 Jan 2012 03:06:46 +0200 (EET)
Date: Sun, 8 Jan 2012 03:06:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: James Harper <james.harper@bendigoit.com.au>
Message-ID: <20120108010646.GD12984@reaktio.net>
References: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
	<20120107140514.GC12984@reaktio.net>
	<6035A0D088A63A46850C3988ED045A4B098C99@BITCOM1.int.sbss.com.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B098C99@BITCOM1.int.sbss.com.au>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] usbback for linux 3.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 Sat, Jan 07, 2012 at 11:42:26PM +0000, James Harper wrote:
> > 
> > On Sat, Jan 07, 2012 at 02:28:24AM +0000, James Harper wrote:
> > > Is anyone maintaining usbback that compiles against Linux 3.1?
> > >
> > 
> > I think Konrad tried to forward-port the 2.6.32 pvops pvusb patch to 3.x, but
> > it didn't work (compile?) out-of-the-box.
> > 
> > pvusb patch for 2.6.32 pvops is here:
> > http://members.iinet.net.au/~nathanael/pvusb.diff
> > (http://lists.xensource.com/archives/html/xen-devel/2011-
> > 01/msg00354.html)
> > 
> > Maybe try it and see if it's trivial to fix it..
> > 
> 
> I've got it building and loading against 3.1 now, but I'm not sure its working properly as I don't have any frontend to test it against except gplpv and that's probably a bad measure at this time.
> 

Great! The patch also includes xen-usbfront frontend driver for Linux..
so you can try it on a Linux domU.

btw. Please post the forward-ported patch.. 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 08 01:11:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 01: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 1RjhHk-00069X-Bu; Sun, 08 Jan 2012 01:10:56 +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 1RjhHi-00069L-Fp
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 01:10:54 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325985045!4676775!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 32268 invoked from network); 8 Jan 2012 01:10:48 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Jan 2012 01:10:48 -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 1RjhHV-0000Ds-U1; Sun, 08 Jan 2012 12:10:41 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 8 Jan 2012 12:10:40 +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;
	Sun, 8 Jan 2012 12:10:39 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Thread-Topic: [Xen-devel] usbback for linux 3.1?
Thread-Index: AQHMzUVqvtJ5K7lCm0e9BbivaXkXr5YBkQcQ//9fnACAALkawA==
Date: Sun, 8 Jan 2012 01:10:36 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B098F06@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
	<20120107140514.GC12984@reaktio.net>
	<6035A0D088A63A46850C3988ED045A4B098C99@BITCOM1.int.sbss.com.au>
	<20120108010646.GD12984@reaktio.net>
In-Reply-To: <20120108010646.GD12984@reaktio.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Jan 2012 01:10:40.0706 (UTC)
	FILETIME=[56882220:01CCCDA2]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] usbback for linux 3.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

> >
> > I've got it building and loading against 3.1 now, but I'm not sure its working
> properly as I don't have any frontend to test it against except gplpv and that's
> probably a bad measure at this time.
> >
> 
> Great! The patch also includes xen-usbfront frontend driver for Linux..
> so you can try it on a Linux domU.
> 
> btw. Please post the forward-ported patch..
> 

I'll see if it works first :)
 
I'm actually building out-of-tree against the Debian kernel I'm using, so the best I can do is just post a tarball of the xen-usbback build directory.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 08 01:11:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 01: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 1RjhHk-00069X-Bu; Sun, 08 Jan 2012 01:10:56 +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 1RjhHi-00069L-Fp
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 01:10:54 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-21.messagelabs.com!1325985045!4676775!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 32268 invoked from network); 8 Jan 2012 01:10:48 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-9.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	8 Jan 2012 01:10:48 -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 1RjhHV-0000Ds-U1; Sun, 08 Jan 2012 12:10:41 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 8 Jan 2012 12:10:40 +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;
	Sun, 8 Jan 2012 12:10:39 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: =?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Thread-Topic: [Xen-devel] usbback for linux 3.1?
Thread-Index: AQHMzUVqvtJ5K7lCm0e9BbivaXkXr5YBkQcQ//9fnACAALkawA==
Date: Sun, 8 Jan 2012 01:10:36 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B098F06@BITCOM1.int.sbss.com.au>
References: <6035A0D088A63A46850C3988ED045A4B0984C5@BITCOM1.int.sbss.com.au>
	<20120107140514.GC12984@reaktio.net>
	<6035A0D088A63A46850C3988ED045A4B098C99@BITCOM1.int.sbss.com.au>
	<20120108010646.GD12984@reaktio.net>
In-Reply-To: <20120108010646.GD12984@reaktio.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Jan 2012 01:10:40.0706 (UTC)
	FILETIME=[56882220:01CCCDA2]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] usbback for linux 3.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

> >
> > I've got it building and loading against 3.1 now, but I'm not sure its working
> properly as I don't have any frontend to test it against except gplpv and that's
> probably a bad measure at this time.
> >
> 
> Great! The patch also includes xen-usbfront frontend driver for Linux..
> so you can try it on a Linux domU.
> 
> btw. Please post the forward-ported patch..
> 

I'll see if it works first :)
 
I'm actually building out-of-tree against the Debian kernel I'm using, so the best I can do is just post a tarball of the xen-usbback build directory.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 08 05:30:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 05:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjlJq-0007e4-2r; Sun, 08 Jan 2012 05:29:22 +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 1RjlJo-0007di-C7
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 05:29:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326000553!8773998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk4Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31313 invoked from network); 8 Jan 2012 05:29:14 -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;
	8 Jan 2012 05:29:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,474,1320624000"; 
   d="scan'208";a="9880640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jan 2012 05:29:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Jan 2012 05:29: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 1RjlJg-00068Q-Qo;
	Sun, 08 Jan 2012 05:29:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RjlJg-0004lF-J4;
	Sun, 08 Jan 2012 05:29:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10643-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Jan 2012 05:29:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10643: 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 10643 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10643/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-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-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-amd64-amd64-xl-winxpsp3 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 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  4086e4811547

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Sun Jan 08 05:30:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 05:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjlJq-0007e4-2r; Sun, 08 Jan 2012 05:29:22 +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 1RjlJo-0007di-C7
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 05:29:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326000553!8773998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk4Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31313 invoked from network); 8 Jan 2012 05:29:14 -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;
	8 Jan 2012 05:29:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,474,1320624000"; 
   d="scan'208";a="9880640"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jan 2012 05:29:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 8 Jan 2012 05:29: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 1RjlJg-00068Q-Qo;
	Sun, 08 Jan 2012 05:29:12 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RjlJg-0004lF-J4;
	Sun, 08 Jan 2012 05:29:12 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10643-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 8 Jan 2012 05:29:12 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10643: 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 10643 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10643/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-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-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-amd64-amd64-xl-winxpsp3 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 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  4086e4811547

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Sun Jan 08 08:49:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 08:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjoQV-0000YH-V0; Sun, 08 Jan 2012 08:48: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 1RjoQU-0000YC-W4
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 08:48:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326012444!63363155!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk4Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10658 invoked from network); 8 Jan 2012 08:47:24 -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 Jan 2012 08:47:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,475,1320624000"; 
   d="scan'208";a="9881293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jan 2012 08:48:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sun, 8 Jan 2012
	08:48:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4F071654.3000102@amd.com>
References: <4F071654.3000102@amd.com>
Organization: Citrix Systems, Inc.
Date: Sun, 8 Jan 2012 08:48:24 +0000
Message-ID: <1326012504.29084.41.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] netbsd: disable CONFIG_SYSTEM_LIBAIO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 15:42 +0000, Christoph Egger wrote:
> Disable CONFIG_SYSTEM_LIBAIO on NetBSD.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

There's no libaio in NetBSD? Could you add it? I hope that one day we
might be able to get rid of these sorts of bundled system libraries.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 08 08:49:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 08:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjoQV-0000YH-V0; Sun, 08 Jan 2012 08:48: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 1RjoQU-0000YC-W4
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 08:48:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326012444!63363155!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk4Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10658 invoked from network); 8 Jan 2012 08:47:24 -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 Jan 2012 08:47:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,475,1320624000"; 
   d="scan'208";a="9881293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	08 Jan 2012 08:48:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Sun, 8 Jan 2012
	08:48:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
In-Reply-To: <4F071654.3000102@amd.com>
References: <4F071654.3000102@amd.com>
Organization: Citrix Systems, Inc.
Date: Sun, 8 Jan 2012 08:48:24 +0000
Message-ID: <1326012504.29084.41.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] netbsd: disable CONFIG_SYSTEM_LIBAIO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 15:42 +0000, Christoph Egger wrote:
> Disable CONFIG_SYSTEM_LIBAIO on NetBSD.
> 
> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

There's no libaio in NetBSD? Could you add it? I hope that one day we
might be able to get rid of these sorts of bundled system libraries.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 08 10:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 10: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 1RjqA4-00015V-NK; Sun, 08 Jan 2012 10:39:36 +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 1RjqA3-00015Q-5k
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 10:39:35 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326019167!8241757!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDg5ODc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5916 invoked from network); 8 Jan 2012 10:39:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	8 Jan 2012 10:39:27 -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 q08AdJOQ008859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 8 Jan 2012 05:39:19 -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 q08AdG2i020192; Sun, 8 Jan 2012 05:39:17 -0500
Message-ID: <4F097253.5080600@redhat.com>
Date: Sun, 08 Jan 2012 12:39:15 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<alpine.DEB.2.00.1201061417480.3150@kaball-deskto! p>
In-Reply-To: <alpine.DEB.2.00.1201061417480.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>, Jan Kiszka <jan.kiszka@web.de>,
	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 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> Avi, if you think that early_savevm is a decent solution, we'll start
> working on it. 

I don't like early_savevm because it complicates life for devices, for
what is a localized problem.  But if everything else is even more
complicated maybe we should do it.

> Also if you would like to save and restore all the
> MemoryRegions because you can see some possible future uses for it, please
> let me know. Otherwise we might try to save some space and just store the
> ones we need.

MemoryRegions don't hold their own state, they just mirror state that
exists elsewhere.  They're 100% implementation artefacts, it's totally
wrong to save/restore them.

-- 
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 Jan 08 10:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 10: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 1RjqA4-00015V-NK; Sun, 08 Jan 2012 10:39:36 +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 1RjqA3-00015Q-5k
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 10:39:35 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326019167!8241757!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDg5ODc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5916 invoked from network); 8 Jan 2012 10:39:27 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	8 Jan 2012 10:39:27 -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 q08AdJOQ008859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 8 Jan 2012 05:39:19 -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 q08AdG2i020192; Sun, 8 Jan 2012 05:39:17 -0500
Message-ID: <4F097253.5080600@redhat.com>
Date: Sun, 08 Jan 2012 12:39:15 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1323467645-24271-1-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>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<alpine.DEB.2.00.1201061417480.3150@kaball-deskto! p>
In-Reply-To: <alpine.DEB.2.00.1201061417480.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>, Jan Kiszka <jan.kiszka@web.de>,
	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 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> Avi, if you think that early_savevm is a decent solution, we'll start
> working on it. 

I don't like early_savevm because it complicates life for devices, for
what is a localized problem.  But if everything else is even more
complicated maybe we should do it.

> Also if you would like to save and restore all the
> MemoryRegions because you can see some possible future uses for it, please
> let me know. Otherwise we might try to save some space and just store the
> ones we need.

MemoryRegions don't hold their own state, they just mirror state that
exists elsewhere.  They're 100% implementation artefacts, it's totally
wrong to save/restore them.

-- 
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 Jan 08 11:45:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 11:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjrAX-0001QJ-SG; Sun, 08 Jan 2012 11:44:09 +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 1RjrAW-0001QE-Au
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 11:44:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326023025!61552578!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_24_48,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18762 invoked from network); 8 Jan 2012 11:43:45 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jan 2012 11:43:45 -0000
Received: by werg1 with SMTP id g1so6635725wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 08 Jan 2012 03:44: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=NlrIcShYGZMGy6RPfgkCz4GcJzHkHIqL5drVzmBGj/U=;
	b=Ht256I5gK6kLmn2UIbMWBsYLhZ20eeYinlhdsFuDgxwRHsLtZkPfP2DHLusVfIcEmw
	jHtAbUE+Yir+/Ik3ayB23iD3lCiOdsUUt/so0IIlVDIPUKXk3gwdIa4pJ2Kvymt+war4
	TwQmQ4LDywVT6OtwoLrpBAD1WBMDMtBcsD8Fg=
Received: by 10.216.136.204 with SMTP id w54mr1842085wei.44.1326023044385;
	Sun, 08 Jan 2012 03:44:04 -0800 (PST)
Received: from build.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234])
	by mx.google.com with ESMTPS id m13sm75144623wbh.0.2012.01.08.03.44.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 08 Jan 2012 03:44:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e12ec1071410c946367cb0508cf218a0c3b596ca
Message-Id: <e12ec1071410c946367c.1325906408@build.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sat, 07 Jan 2012 04:20:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI1OTA2MjMwIC0zNjAwCiMgTm9kZSBJRCBlMTJlYzEwNzE0
MTBjOTQ2MzY3Y2IwNTA4Y2YyMThhMGMzYjU5NmNhCiMgUGFyZW50ICA0MDg2ZTQ4MTE1NDdkZGZm
YjlhNTNmYmYyZWZiNmMyZmE0MzZiNzBhCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwKY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KCkF1dG9jb25mLm1rIGlzIGluY2x1
ZGVkIGJ5IENvbmZpZy5taywgYW5kIGNvbnRhaW5zIG1vc3Qgb2YgdGhlCm9wdGlvbnMgcHJldmlv
dXNseSBkZWZpbmVkIGluIC5jb25maWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwpwYXJh
bWV0ZXJzIG9yIGRlZmluaW5nIGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBj
b25maWd1cmUKc2NyaXB0LgoKY29uZmlnLmggaXMgc3RpbGwgbm90IHVzZWQgYW55d2hlcmUsIGFu
ZCBpcyBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQgYnkKYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1p
Z2ggY2hhbmdlIHdoZW4gd2Ugc3RhcnQgdG8gaW5jbHVkZSB0aGlzCmZpbGUuCgpKdXN0IGEgZmly
c3QgcmVsZWFzZSwgYW5kIHNpbmNlIElpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlwdCBJIGd1
ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNlIHJl
dmlldyBhbmQgY29tbWVudC4KClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIu
cGF1QGVudGVsLnVwYy5lZHU+CgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAg
Q29uZmlnLm1rCi0tLSBhL0NvbmZpZy5tawlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAK
KysrIGIvQ29uZmlnLm1rCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApAQCAtOSw4ICs5
LDYgQEAgcmVhbHBhdGggPSAkKHdpbGRjYXJkICQoZm9yZWFjaCBmaWxlLCQoMQogCiAtaW5jbHVk
ZSAkKFhFTl9ST09UKS8uY29uZmlnCiAKLSMgQSBkZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xz
PwotZGVidWcgPz0geQogCiBYRU5fQ09NUElMRV9BUkNIICAgID89ICQoc2hlbGwgdW5hbWUgLW0g
fCBzZWQgLWUgcy9pLjg2L3g4Nl8zMi8gXAogICAgICAgICAgICAgICAgICAgICAgICAgIC1lIHMv
aTg2cGMveDg2XzMyLyAtZSBzL2FtZDY0L3g4Nl82NC8pCkBAIC00Myw2ICs0MSw3IEBAIGVuZGlm
CiAKIGluY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnLyQoWEVOX09TKS5tawogaW5jbHVkZSAkKFhF
Tl9ST09UKS9jb25maWcvJChYRU5fVEFSR0VUX0FSQ0gpLm1rCitpbmNsdWRlICQoWEVOX1JPT1Qp
L2NvbmZpZy9BdXRvY29uZi5tawogCiBTSEFSRURJUiAgICA/PSAkKFBSRUZJWCkvc2hhcmUKIERP
Q0RJUiAgICAgID89ICQoU0hBUkVESVIpL2RvYy94ZW4KQEAgLTcwLDEwICs2OSw2IEBAIEVYVFJB
X0lOQ0xVREVTICs9ICQoRVhUUkFfUFJFRklYKS9pbmNsdWQKIEVYVFJBX0xJQiArPSAkKEVYVFJB
X1BSRUZJWCkvJChMSUJMRUFGRElSKQogZW5kaWYKIAotQklTT04JPz0gYmlzb24KLUZMRVgJPz0g
ZmxleAotCi1QWVRIT04gICAgICA/PSBweXRob24KIFBZVEhPTl9QUkVGSVhfQVJHID89IC0tcHJl
Zml4PSIkKFBSRUZJWCkiCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJWCBjb250YWlu
cyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCiAjIHRvIHBlcm1pdCB0aGUgdXNl
ciB0byBzZXQgUFlUSE9OX1BSRUZJWF9BUkcgdG8gJycgdG8gd29ya2Fyb3VuZCB0aGlzIGJ1ZzoK
QEAgLTE3NSwyMiArMTcwLDkgQEAgQ0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKFBSRVBFTkRfSU5D
TFVERQogQVBQRU5EX0xERkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0xJQiksIC1MJChp
KSkKIEFQUEVORF9DRkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0lOQ0xVREVTKSwgLUkk
KGkpKQogCi1DSEVDS19MSUIgPSAkKEVYVFJBX0xJQikgJChQUkVQRU5EX0xJQikgJChBUFBFTkRf
TElCKQotQ0hFQ0tfSU5DTFVERVMgPSAkKEVYVFJBX0lOQ0xVREVTKSAkKFBSRVBFTkRfSU5DTFVE
RVMpICQoQVBQRU5EX0lOQ0xVREVTKQotCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgOj0gLW5vcGll
IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tc3RhY2stcHJvdGVjdG9yLWFsbAogRU1CRURERURf
RVhUUkFfQ0ZMQUdTICs9IC1mbm8tZXhjZXB0aW9ucwogCi0jIEVuYWJsZSBYU00gc2VjdXJpdHkg
bW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCi1YU01fRU5BQkxFID89IG4KLUZMQVNLX0VOQUJM
RSA/PSAkKFhTTV9FTkFCTEUpCi0KLSMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRU
UCBvciBHSVQncyBvd24gcHJvdG9jb2w/Ci0jIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQg
bW9yZSByb2J1c3QsIHdoZW4gaXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKLSMgbWF5IGJsb2Nr
IGl0KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkg
ZG93bmxvYWRzCi0jIGZhaWwgb3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5
b3VyIGVudmlyb25tZW50LgotR0lUX0hUVFAgPz0gbgotCiBYRU5fRVhURklMRVNfVVJMPWh0dHA6
Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLWV4dGZpbGVzCiAjIEFsbCB0aGUgZmlsZXMgYXQg
dGhhdCBsb2NhdGlvbiB3ZXJlIGRvd25sb2FkZWQgZnJvbSBlbHNld2hlcmUgb24KICMgdGhlIGlu
dGVybmV0LiAgVGhlIG9yaWdpbmFsIGRvd25sb2FkIFVSTCBpcyBwcmVzZXJ2ZWQgYXMgYSBjb21t
ZW50CkBAIC0yMjIsMTcgKzIwNCwzIEBAIFFFTVVfVEFHID89IGJiMzZkNjMyZTRjYWJmNDc4ODJh
ZGZmMDdhNDUKICMgTm90ZSB0aGF0IHVzaW5nIFNlYUJJT1MgcmVxdWlyZXMgdGhlIHVzZSB0aGUg
dXBzdHJlYW0gcWVtdSBhcyB0aGUKICMgZGV2aWNlIG1vZGVsLgogU0VBQklPU19ESVIgPz0gCi0K
LSMgT3B0aW9uYWwgY29tcG9uZW50cwotWEVOU1RBVF9YRU5UT1AgICAgID89IHkKLVZUUE1fVE9P
TFMgICAgICAgICA/PSBuCi1MSUJYRU5BUElfQklORElOR1MgPz0gbgotUFlUSE9OX1RPT0xTICAg
ICAgID89IHkKLU9DQU1MX1RPT0xTICAgICAgICA/PSB5Ci1DT05GSUdfTUlOSVRFUk0gICAgPz0g
bgotQ09ORklHX0xPTU9VTlQgICAgID89IG4KLUNPTkZJR19TWVNURU1fTElCQUlPID89IHkKLQot
aWZlcSAoJChPQ0FNTF9UT09MUykseSkKLU9DQU1MX1RPT0xTIDo9ICQoc2hlbGwgb2NhbWxvcHQg
LXYgPiAvZGV2L251bGwgMj4mMSAmJiBlY2hvICJ5IiB8fCBlY2hvICJuIikKLWVuZGlmCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBNYWtlZmlsZQotLS0gYS9NYWtlZmlsZQlU
aHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIGIvTWFrZWZpbGUJU2F0IEphbiAwNyAw
NDoxNzoxMCAyMDEyICswMTAwCkBAIC00MCwxMSArNDAsOSBAQCBkaXN0OiBERVNURElSPSQoRElT
VERJUikvaW5zdGFsbAogZGlzdDogZGlzdC14ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlz
dC1zdHViZG9tIGRpc3QtZG9jcyBkaXN0LW1pc2MKIAogZGlzdC1taXNjOgotCSQoSU5TVEFMTF9E
SVIpICQoRElTVERJUikvY2hlY2sKIAkkKElOU1RBTExfREFUQSkgLi9DT1BZSU5HICQoRElTVERJ
UikKIAkkKElOU1RBTExfREFUQSkgLi9SRUFETUUgJChESVNURElSKQogCSQoSU5TVEFMTF9QUk9H
KSAuL2luc3RhbGwuc2ggJChESVNURElSKQotCSQoSU5TVEFMTF9QUk9HKSB0b29scy9jaGVjay9j
aGsgdG9vbHMvY2hlY2svY2hlY2tfKiB0b29scy9jaGVjay9mdW5jcy5zaCAkKERJU1RESVIpL2No
ZWNrCiBkaXN0LSU6IERFU1RESVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0LSU6IGluc3RhbGwt
JQogCUA6ICMgZG8gbm90aGluZwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAg
UkVBRE1FCi0tLSBhL1JFQURNRQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIGIv
UkVBRE1FCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApAQCAtODcsOSArODcsMTUgQEAg
Mi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0ZXZlciB5b3UgcwogMy4gRm9yIHRoZSB2ZXJ5
IGZpcnN0IGJ1aWxkLCBvciBpZiB5b3Ugd2FudCB0byBkZXN0cm95IGJ1aWxkIHRyZWVzLAogICAg
cGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgogCisgICAgIyBhdXRvbWFrZSAtYQorICAgICMg
YXV0b2hlYWRlciAmJiBhdXRvY29uZgorICAgICMgLi9jb25maWd1cmUKICAgICAjIG1ha2Ugd29y
bGQKICAgICAjIG1ha2UgaW5zdGFsbAogCisgICBJZiB5b3Ugd2FudCwgeW91IGNhbiBydW4gLi9j
b25maWd1cmUgLS1oZWxwIHRvIHNlZSB0aGUgbGlzdCBvZgorICAgb3B0aW5zIGF2YWlsYWJsZSBv
cHRpb25zIHdoZW4gYnVpbGRpbmcgYW5kIGluc3RhbGxpbmcgWGVuLgorCiAgICBUaGlzIHdpbGwg
Y3JlYXRlIGFuZCBpbnN0YWxsIG9udG8gdGhlIGxvY2FsIG1hY2hpbmUuIEl0IHdpbGwgYnVpbGQK
ICAgIHRoZSB4ZW4gYmluYXJ5ICh4ZW4uZ3opLCB0aGUgdG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0
aW9uLgogCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBjb25maWcvQXV0b2Nv
bmYubWsuaW4KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIvY29uZmlnL0F1dG9jb25mLm1rLmluCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApA
QCAtMCwwICsxLDQ5IEBACisjIFByZWZpeCBhbmQgaW5zdGFsbCBmb2xkZXIKK1BSRUZJWCAgICAg
ICAgICAgICAgOj0gQHByZWZpeEAKK0xJQkxFQUZESVJfeDg2XzY0ICAgOj0gQExJQl9QQVRIQAor
CisjIEEgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAg
Oj0gQGRlYnVnQAorCisjIFRvb2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09O
QAorRkxFWCAgICAgICAgICAgICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0g
QFBZVEhPTkAKK1BFUkwgICAgICAgICAgICAgICAgOj0gQFBFUkxACitCUkNUTCAgICAgICAgICAg
ICAgIDo9IEBCUkNUTEAKK0lQICAgICAgICAgICAgICAgICAgOj0gQElQQAorQ1VSTC1DT05GSUcg
ICAgICAgICA6PSBAQ1VSTEAKK1hNTDItQ09ORklHICAgICAgICAgOj0gQFhNTEAKK0JBU0ggICAg
ICAgICAgICAgICAgOj0gQEJBU0hACitYR0VUVFRFWFQgICAgICAgICAgIDo9IEBYR0VUVEVYVEAK
KworIyBFeHRyYSBmb2xkZXIgZm9yIGxpYnMvaW5jbHVkZXMKK1BSRVBFTkRfSU5DTFVERVMgICAg
Oj0gQFBSRVBFTkRfSU5DTFVERVNACitQUkVQRU5EX0xJQiAgICAgICAgIDo9IEBQUkVQRU5EX0xJ
QkAKK0FQUEVORF9JTkNMVURFUyAgICAgOj0gQEFQUEVORF9JTkNMVURFU0AKK0FQUEVORF9MSUIg
ICAgICAgICAgOj0gQEFQUEVORF9MSUJACisKKyMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUg
KGJ5IGRlZmF1bHQsIEZsYXNrKS4KK1hTTV9FTkFCTEUgICAgICAgICAgOj0gQHhzbUAKK0ZMQVNL
X0VOQUJMRSAgICAgICAgOj0gQHhzbUAKKworIyBEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZp
YSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8KKyMgR0lUJ3MgcHJvdG9jb2wgaXMgZmFzdGVy
IGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3JrcyBhdCBhbGwgKGZpcmV3YWxscworIyBtYXkg
YmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBkZWZhdWx0LCBidXQgaWYgeW91ciBHSVQgcmVwb3Np
dG9yeSBkb3dubG9hZHMKKyMgZmFpbCBvciBoYW5nLCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15
IGluIHlvdXIgZW52aXJvbm1lbnQuCitHSVRfSFRUUCAgICAgICAgICAgIDo9IEBnaXRodHRwQAor
CisjIE9wdGlvbmFsIGNvbXBvbmVudHMKK1hFTlNUQVRfWEVOVE9QICAgICAgOj0gQG1vbml0b3Jz
QAorVlRQTV9UT09MUyAgICAgICAgICA6PSBAdnRwbUAKK0xJQlhFTkFQSV9CSU5ESU5HUyAgOj0g
QHhhcGlACitQWVRIT05fVE9PTFMgICAgICAgIDo9IEBweXRob250b29sc0AKK09DQU1MX1RPT0xT
ICAgICAgICAgOj0gQG9jYW1sdG9vbHNACitDT05GSUdfTUlOSVRFUk0gICAgIDo9IEBtaW5pdGVy
bUAKK0NPTkZJR19MT01PVU5UICAgICAgOj0gQGxvbW91bnRACisKKyNTeXN0ZW0gb3B0aW9ucwor
Q09ORklHX1NZU1RFTV9MSUJBSU86PSBAc3lzdGVtX2Fpb0AKK0NPTkZJR19MSUJJQ09OViAgICAg
Oj0gQGxpYmljb252QAorQ09ORklHX0dDUllQVCAgICAgICA6PSBAbGliZ2NyeXB0QAorQ09ORklH
X0VYVDJGUyAgICAgICA6PSBAbGliZXh0MmZzQApkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJl
YzEwNzE0MTAgY29uZmlndXJlLmFjCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL2NvbmZpZ3VyZS5hYwlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAx
MDAKQEAgLTAsMCArMSwxNzkgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0aCBh
dXRvY29uZiB0byBwcm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJFUkVRKFsyLjY3
XSkKK0FDX0lOSVQoW1hlbiBIeXBlcnZpc29yXSwgWzQuMl0sIFt4ZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbV0pCitBQ19DT05GSUdfU1JDRElSKFt0b29scy9saWJ4bC9saWJ4bC5jXSkKK0FD
X0NPTkZJR19IRUFERVJTKFtjb25maWcuaF0pCitBQ19DT05GSUdfRklMRVMoW2NvbmZpZy9BdXRv
Y29uZi5ta10pCitBQ19QUkVGSVhfREVGQVVMVChbL3Vzcl0pCisKKyMgQ2hlY2sgaWYgQ0ZMQUdT
LCBMREZMQUdTLCBMSUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdhcm5p
bmcKKworQVNfSUYoW3Rlc3QgLW4gIiRDQyRDRkxBR1MkTERGTEFHUyRMSUJTJENQUEZMQUdTJENQ
UCJdLCBbCisgICAgQUNfTVNHX1dBUk4oCitbU2V0dGluZyBDQywgQ0ZMQUdTLCBMREZMQUdTLCBM
SUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgbm90IFwKK3JlY29tbWVuZGVkLCB1c2UgUFJFUEVORF9J
TkNMVURFUywgUFJFUEVORF9MSUIsIFwKK0FQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBp
bnN0ZWFkIHdoZW4gcG9zc2libGUuXSkKK10pCisKK0FDX1VTRV9TWVNURU1fRVhURU5TSU9OUwor
QUNfQ0FOT05JQ0FMX0hPU1QKKworIyBNNCBNYWNybyBpbmNsdWRlcworbTRfaW5jbHVkZShbbTQv
ZW5hYmxlX2ZlYXR1cmUubTRdKQorbTRfaW5jbHVkZShbbTQvZGlzYWJsZV9mZWF0dXJlLm00XSkK
K200X2luY2x1ZGUoW200L3BhdGhfb3JfZmFpbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25f
eG1sLm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl92ZXJzaW9uLm00XSkKK200X2luY2x1ZGUo
W200L3B5dGhvbl9kZXZlbC5tNF0pCittNF9pbmNsdWRlKFttNC91ZGV2Lm00XSkKK200X2luY2x1
ZGUoW200L29jYW1sLm00XSkKK200X2luY2x1ZGUoW200L2RlZmF1bHRfbGliLm00XSkKK200X2lu
Y2x1ZGUoW200L3NldF9jZmxhZ3NfbGRmbGFncy5tNF0pCisKKyMgRW5hYmxlL2Rpc2FibGUgb3B0
aW9ucworQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt4c21dLAorICAgIFtFbmFibGUgWFNNIHNl
Y3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2spXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VY
UE9SVChbZ2l0aHR0cF0sIFtEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQXSkKK0FY
X0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW21vbml0b3JzXSwKKyAgICBbRGlzYWJsZSB4ZW5zdGF0
IGFuZCB4ZW50b3AgbW9uaXRvcmluZyB0b29sc10pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQo
W3Z0cG1dLCBbRW5hYmxlIFZpcnR1YWwgVHJ1c3RlZCBQbGF0Zm9ybSBNb2R1bGVdKQorQVhfQVJH
X0VOQUJMRV9BTkRfRVhQT1JUKFt4YXBpXSwgW0VuYWJsZSBYZW4gQVBJIEJpbmRpbmdzXSkKK0FY
X0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW3B5dGhvbnRvb2xzXSwgW0Rpc2FibGUgUHl0aG9uIHRv
b2xzXSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW29jYW1sdG9vbHNdLCBbRGlzYWJsZSBP
Y2FtbCB0b29sc10pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW21pbml0ZXJtXSwgW0VuYWJs
ZSBtaW5pdGVybV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW2xvbW91bnRdLCBbRW5hYmxl
IGxvbW91bnRdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbZGVidWddLCBbRGlzYWJsZSBk
ZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xzXSkKKworQUNfQVJHX1ZBUihbUFJFUEVORF9JTkNM
VURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gQ0ZMQUdT
ICh3aXRob3V0IC1JKV0pCitBQ19BUkdfVkFSKFtQUkVQRU5EX0xJQl0sCisgICAgW0xpc3Qgb2Yg
bGlicmFyeSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCldKQorQUNf
QVJHX1ZBUihbQVBQRU5EX0lOQ0xVREVTXSwKKyAgICBbTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMg
dG8gYXBwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSldKQorQUNfQVJHX1ZBUihbQVBQRU5EX0xJ
Ql0sCisgICAgW0xpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIGFwcGVuZCB0byBMREZMQUdTICh3
aXRob3V0IC1MKV0pCisKK0FYX1NFVF9GTEFHUworCitBQ19BUkdfVkFSKFtQWVRIT05dLCBbUGF0
aCB0byBQeXRob24gcGFyc2VyXSkKK0FDX0FSR19WQVIoW1BFUkxdLCBbUGF0aCB0byBQZXJsIHBh
cnNlcl0pCitBQ19BUkdfVkFSKFtCUkNUTF0sIFtQYXRoIHRvIGJyY3RsIHRvb2xdKQorQUNfQVJH
X1ZBUihbSVBdLCBbUGF0aCB0byBpcCB0b29sXSkKK0FDX0FSR19WQVIoW0JJU09OXSwgW1BhdGgg
dG8gQmlzb24gcGFyc2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtGTEVYXSwgW1BhdGggdG8g
RmxleCBsZXhpY2FsIGFuYWx5c2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtDVVJMXSwgW1Bh
dGggdG8gY3VybC1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtYTUxdLCBbUGF0aCB0byB4bWwy
LWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW0JBU0hdLCBbUGF0aCB0byBiYXNoIHNoZWxsXSkK
K0FDX0FSR19WQVIoW1hHRVRURVhUXSwgW1BhdGggdG8geGdldHR0ZXh0IHRvb2xdKQorCisjIENo
ZWNrcyBmb3IgcHJvZ3JhbXMuCitBQ19QUk9HX1NFRAorQUNfUFJPR19DQworQUNfUFJPR19JTlNU
QUxMCitBQ19QUk9HX0xOX1MKK0FDX1BST0dfTUFLRV9TRVQKK0FYX1BBVEhfUFJPR19PUl9GQUlM
KFtQRVJMXSwgW3BlcmxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JSQ1RMXSwgW2JyY3RsXSkK
K0FYX1BBVEhfUFJPR19PUl9GQUlMKFtJUF0sIFtpcF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChb
QklTT05dLCBbYmlzb25dKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0ZMRVhdLCBbZmxleF0pCitB
U19JRihbdGVzdCAieCR4YXBpIiA9ICJ4eSJdLCBbCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwo
W0NVUkxdLCBbY3VybC1jb25maWddKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtYTUxdLCBb
eG1sMi1jb25maWddKQorXSkKK0FTX0lGKFt0ZXN0ICJ4JG9jYW1sdG9vbHMiID0gInh5Il0sIFsK
KyAgICBBQ19QUk9HX09DQU1MCisgICAgQVNfSUYoW3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwg
WworICAgICAgQUNfTVNHX0VSUk9SKFtZb3UgbXVzdCBpbnN0YWxsIHRoZSBPQ2FtbCBjb21waWxl
cl0pCisgICAgXSkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQkFTSF0sIFtiYXNoXSkKK0FT
X0lGKFt0ZXN0ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSJdLCBbCisgICAgQVhfUEFUSF9QUk9HX09S
X0ZBSUwoW1BZVEhPTl0sIFtweXRob25dKQorICAgIEFYX0NIRUNLX1BZVEhPTl9WRVJTSU9OKFsy
XSwgWzNdKQorICAgIEFYX0NIRUNLX1BZVEhPTl9YTUwoKQorICAgIEFYX0NIRUNLX1BZVEhPTl9E
RVZFTCgpCitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hHRVRURVhUXSwgW3hnZXR0ZXh0XSkK
K0FYX0NIRUNLX1VERVYoWzU5XSkKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK0FYX0RFRkFVTFRf
TElCCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCitBQ19DSEVDS19MSUIoW2Fpb10sIFtpb19z
ZXR1cF0sIFtzeXN0ZW1fYWlvPSJ5Il0sIFtzeXN0ZW1fYWlvPSJuIl0pCitBQ19TVUJTVChzeXN0
ZW1fYWlvKQorQUNfQ0hFQ0tfTElCKFtjcnlwdG9dLCBbTUQ1XSwgW10sIFtBQ19NU0dfRVJST1Io
W0NvdWxkIG5vdCBmaW5kIGxpYmNyeXB0b10pXSkKK0FDX0NIRUNLX0xJQihbZXh0MmZzXSwgW2V4
dDJmc19vcGVuMl0sIFtsaWJleHQyZnM9InkiXSwgW2xpYmV4dDJmcz0ibiJdKQorQUNfU1VCU1Qo
bGliZXh0MmZzKQorQUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0s
IFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJdKQorQUNfU1VCU1QobGliZ2NyeXB0KQor
QUNfQ0hFQ0tfTElCKFtwdGhyZWFkXSwgW3B0aHJlYWRfY3JlYXRlXSwgW10gLAorICAgIFtBQ19N
U0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnB0aHJlYWRdKV0pCitBQ19DSEVDS19MSUIoW3J0
XSwgW2Nsb2NrX2dldHRpbWVdKQorQUNfQ0hFQ0tfTElCKFt1dWlkXSwgW3V1aWRfY2xlYXJdLCBb
XSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJ1dWlkXSldKQorQUNfQ0hF
Q0tfTElCKFt5YWpsXSwgW3lhamxfYWxsb2NdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3Vs
ZCBub3QgZmluZCB5YWpsXSldKQorQUNfQ0hFQ0tfTElCKFt6XSwgW2RlZmxhdGVDb3B5XSwgW10s
IFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHpsaWJdKV0pCitBQ19DSEVDS19MSUIoW2lj
b252XSwgW2xpYmljb252X29wZW5dLCBbbGliaWNvbnY9InkiXSwgW2xpYmljb252PSJuIl0pCitB
Q19TVUJTVChsaWJpY29udikKKworIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK0FDX0ZVTkNf
QUxMT0NBCitBQ19DSEVDS19IRUFERVJTKFsgXAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5o
IGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAg
ICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5o
IHN0cmluZy5oIFwKKyAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9j
dGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tl
dC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAg
ICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorICAgICAgICAgICAgICAg
IF0pCisKKyMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNo
YXJhY3RlcmlzdGljcy4KK0FDX0hFQURFUl9TVERCT09MCitBQ19UWVBFX1VJRF9UCitBQ19DX0lO
TElORQorQUNfVFlQRV9JTlQxNl9UCitBQ19UWVBFX0lOVDMyX1QKK0FDX1RZUEVfSU5UNjRfVAor
QUNfVFlQRV9JTlQ4X1QKK0FDX1RZUEVfTU9ERV9UCitBQ19UWVBFX09GRl9UCitBQ19UWVBFX1BJ
RF9UCitBQ19DX1JFU1RSSUNUCitBQ19UWVBFX1NJWkVfVAorQUNfVFlQRV9TU0laRV9UCitBQ19D
SEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9ibGtzaXplXSkKK0FDX1NUUlVDVF9TVF9CTE9D
S1MKK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X3JkZXZdKQorQUNfVFlQRV9VSU5U
MTZfVAorQUNfVFlQRV9VSU5UMzJfVAorQUNfVFlQRV9VSU5UNjRfVAorQUNfVFlQRV9VSU5UOF9U
CitBQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90XSkKKworIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVu
Y3Rpb25zLgorQUNfRlVOQ19FUlJPUl9BVF9MSU5FCitBQ19GVU5DX0ZPUksKK0FDX0ZVTkNfRlNF
RUtPCitBQ19GVU5DX0xTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCitBQ19IRUFERVJfTUFK
T1IKK0FDX0ZVTkNfTUFMTE9DCitBQ19GVU5DX01LVElNRQorQUNfRlVOQ19NTUFQCitBQ19GVU5D
X1JFQUxMT0MKK0FDX0ZVTkNfU1RSTkxFTgorQUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNT
KFsgXAorICAgICAgICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1
cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3Ri
eW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAg
ICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQg
bWtkaXIgXAorICAgICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGgg
cmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3Ry
Y2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAg
ICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3Ry
dG91bGwgdHpzZXQgXAorICAgICAgICAgICAgICAgIHVuYW1lIFwKKyAgICAgICAgICAgICAgICBd
KQorCitBQ19PVVRQVVQoKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgbTQv
ZGVmYXVsdF9saWIubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIvbTQvZGVmYXVsdF9saWIubTQJU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAw
CkBAIC0wLDAgKzEsNyBAQAorQUNfREVGVU4oW0FYX0RFRkFVTFRfTElCXSwKK1tBU19JRihbdGVz
dCAtZCAiJHByZWZpeC9saWI2NCJdLCBbCisgICAgTElCX1BBVEg9ImxpYjY0IgorXSxbCisgICAg
TElCX1BBVEg9ImxpYiIKK10pCitBQ19TVUJTVChMSUJfUEFUSCldKQpcIE5vIG5ld2xpbmUgYXQg
ZW5kIG9mIGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIG00L2Rpc2Fi
bGVfZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MAorKysgYi9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JU
XSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZGlzYWJsZS0k
MV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAg
JDE9Im4iCitdLFsKKyAgICAkMT0ieSIKK10pCitBQ19TVUJTVCgkMSldKQpcIE5vIG5ld2xpbmUg
YXQgZW5kIG9mIGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIG00L2Vu
YWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL200L2VuYWJsZV9mZWF0dXJlLm00CVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiAr
MDEwMApAQCAtMCwwICsxLDEwIEBACitBQ19ERUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JU
XSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQx
XSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAg
JDE9InkiCitdLFsKKyAgICAkMT0ibiIKK10pCitBQ19TVUJTVCgkMSldKQpcIE5vIG5ld2xpbmUg
YXQgZW5kIG9mIGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIG00L29j
YW1sLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L200L29jYW1sLm00CVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApAQCAtMCwwICsxLDI0
MCBAQAorZG5sIGF1dG9jb25mIG1hY3JvcyBmb3IgT0NhbWwKK2RubAorZG5sIENvcHlyaWdodCDC
qSAyMDA5ICAgICAgUmljaGFyZCBXLk0uIEpvbmVzCitkbmwgQ29weXJpZ2h0IMKpIDIwMDkgICAg
ICBTdGVmYW5vIFphY2NoaXJvbGkKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IE9saXZpZXIg
QW5kcmlldQorZG5sIENvcHlyaWdodCDCqSAyMDAwLTIwMDUgSmVhbi1DaHJpc3RvcGhlIEZpbGxp
w6J0cmUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IEdlb3JnZXMgTWFyaWFubworZG5sCitk
bmwgRm9yIGRvY3VtZW50YXRpb24sIHBsZWFzZSByZWFkIHRoZSBvY2FtbC5tNCBtYW4gcGFnZS4K
KworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2Ft
bGMKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxDXSxbb2NhbWxjXSxbbm9dKQorCisgIGlmIHRlc3Qg
IiRPQ0FNTEMiICE9ICJubyI7IHRoZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwg
c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCdgCisgICAgIEFDX01TR19SRVNV
TFQoW09DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTl0pCisgICAgICMgSWYgT0NBTUxMSUIg
aXMgc2V0LCB1c2UgaXQKKyAgICAgaWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0aGVuCisgICAg
ICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRh
aWwgLTF8Y3V0IC1kICcgJyAtZiA0YAorICAgICBlbHNlCisgICAgICAgIEFDX01TR19SRVNVTFQo
W09DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0Ll0pCisgICAgIGZpCisgICAg
IEFDX01TR19SRVNVTFQoW09DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUJdKQorCisgICAg
IEFDX1NVQlNUKFtPQ0FNTFZFUlNJT05dKQorICAgICBBQ19TVUJTVChbT0NBTUxMSUJdKQorCisg
ICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MT1BU
XSxbb2NhbWxvcHRdLFtub10pCisgICAgIE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRP
Q0FNTE9QVCIgPSAibm8iOyB0aGVuCisJQUNfTVNHX1dBUk4oW0Nhbm5vdCBmaW5kIG9jYW1sb3B0
OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5Ll0pCisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAk
T0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJ
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgQUNf
TVNHX1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2Fy
ZGVkLl0pCisJICAgIE9DQU1MT1BUPW5vCisJZWxzZQorCSAgICBPQ0FNTEJFU1Q9b3B0CisJZmkK
KyAgICAgZmkKKworICAgICBBQ19TVUJTVChbT0NBTUxCRVNUXSkKKworICAgICAjIGNoZWNraW5n
IGZvciBvY2FtbGMub3B0CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MQ0RPVE9QVF0sW29jYW1s
Yy5vcHRdLFtub10pCisgICAgIGlmIHRlc3QgIiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4K
KwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiog
KlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lP
TiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2Ft
bGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLl0pCisJZWxzZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RP
VE9QVAorCWZpCisgICAgIGZpCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0Cisg
ICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgIT0gIm5vIiA7IHRoZW4KKwlBQ19DSEVDS19UT09MKFtP
Q0FNTE9QVERPVE9QVF0sW29jYW1sb3B0Lm9wdF0sW25vXSkKKwlpZiB0ZXN0ICIkT0NBTUxPUFRE
T1RPUFQiICE9ICJubyI7IHRoZW4KKwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRET1RPUFQgLXYg
fCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAgaWYgdGVzdCAi
JFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICBBQ19NU0dfUkVT
VUxUKFt2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQu
XSkKKwkgICBlbHNlCisJICAgICAgT0NBTUxPUFQ9JE9DQU1MT1BURE9UT1BUCisJICAgZmkKKyAg
ICAgICAgZmkKKyAgICAgZmkKKworICAgICBBQ19TVUJTVChbT0NBTUxPUFRdKQorICBmaQorCisg
IEFDX1NVQlNUKFtPQ0FNTENdKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sIHRvcGxldmVsCisg
IEFDX0NIRUNLX1RPT0woW09DQU1MXSxbb2NhbWxdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Ig
b2NhbWxkZXAKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxERVBdLFtvY2FtbGRlcF0sW25vXSkKKwor
ICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtUT1Bd
LFtvY2FtbG1rdG9wXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgQUNf
Q0hFQ0tfVE9PTChbT0NBTUxNS0xJQl0sW29jYW1sbWtsaWJdLFtub10pCisKKyAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxkb2MKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxET0NdLFtvY2FtbGRvY10sW25v
XSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIEFDX0NIRUNLX1RPT0woW09DQU1M
QlVJTERdLFtvY2FtbGJ1aWxkXSxbbm9dKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19PQ0FN
TExFWF0sCitbZG5sCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbGV4CisgIEFDX0NIRUNLX1RPT0wo
W09DQU1MTEVYXSxbb2NhbWxsZXhdLFtub10pCisgIGlmIHRlc3QgIiRPQ0FNTExFWCIgIT0gIm5v
IjsgdGhlbgorICAgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVYRE9UT1BUXSxbb2NhbWxsZXgub3B0
XSxbbm9dKQorICAgIGlmIHRlc3QgIiRPQ0FNTExFWERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCU9D
QU1MTEVYPSRPQ0FNTExFWERPVE9QVAorICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtPQ0FNTExF
WF0pCitdKQorCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTFlBQ0NdLAorW2RubAorICBBQ19DSEVD
S19UT09MKFtPQ0FNTFlBQ0NdLFtvY2FtbHlhY2NdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTFlB
Q0NdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19DQU1MUDRdLAorW2RubAorICBBQ19SRVFV
SVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKworICAjIGNoZWNraW5nIGZvciBjYW1scDQKKyAgQUNf
Q0hFQ0tfVE9PTChbQ0FNTFA0XSxbY2FtbHA0XSxbbm9dKQorICBpZiB0ZXN0ICIkQ0FNTFA0IiAh
PSAibm8iOyB0aGVuCisgICAgIFRNUFZFUlNJT049YCRDQU1MUDQgLXYgMj4mMXwgc2VkIC1uIC1l
ICdzfC4qdmVyc2lvbiAqXCguKlwpJHxcMXxwJ2AKKyAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04i
ICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwlBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZm
ZXJzIGZyb20gb2NhbWxjXSkKKyAgICAgICAgQ0FNTFA0PW5vCisgICAgIGZpCisgIGZpCisgIEFD
X1NVQlNUKFtDQU1MUDRdKQorCisgICMgY2hlY2tpbmcgZm9yIGNvbXBhbmlvbiB0b29scworICBB
Q19DSEVDS19UT09MKFtDQU1MUDRCT09UXSxbY2FtbHA0Ym9vdF0sW25vXSkKKyAgQUNfQ0hFQ0tf
VE9PTChbQ0FNTFA0T10sW2NhbWxwNG9dLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9G
XSxbY2FtbHA0b2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9PRl0sW2NhbWxwNG9v
Zl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T1JGXSxbY2FtbHA0b3JmXSxbbm9dKQor
ICBBQ19DSEVDS19UT09MKFtDQU1MUDRQUk9GXSxbY2FtbHA0cHJvZl0sW25vXSkKKyAgQUNfQ0hF
Q0tfVE9PTChbQ0FNTFA0Ul0sW2NhbWxwNHJdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQ
NFJGXSxbY2FtbHA0cmZdLFtub10pCisgIEFDX1NVQlNUKFtDQU1MUDRCT09UXSkKKyAgQUNfU1VC
U1QoW0NBTUxQNE9dKQorICBBQ19TVUJTVChbQ0FNTFA0T0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0
T09GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9SRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRQUk9GXSkK
KyAgQUNfU1VCU1QoW0NBTUxQNFJdKQorICBBQ19TVUJTVChbQ0FNTFA0UkZdKQorXSkKKworCitB
Q19ERUZVTihbQUNfUFJPR19GSU5ETElCXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19P
Q0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxmaW5kCisgIEFDX0NIRUNLX1RPT0wo
W09DQU1MRklORF0sW29jYW1sZmluZF0sW25vXSkKKyAgQUNfU1VCU1QoW09DQU1MRklORF0pCitd
KQorCisKK2RubCBUaGFua3MgdG8gSmltIE1leWVyaW5nIGZvciB3b3JraW5nIHRoaXMgbmV4dCBi
aXQgb3V0IGZvciB1cy4KK2RubCBYWFggV2Ugc2hvdWxkIGRlZmluZSBBU19UUl9TSCBpZiBpdCdz
IG5vdCBkZWZpbmVkIGFscmVhZHkKK2RubCAoZWcuIGZvciBvbGQgYXV0b2NvbmYpLgorQUNfREVG
VU4oW0FDX0NIRUNLX09DQU1MX1BLR10sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfRklO
RExJQl0pZG5sCisKKyAgQUNfTVNHX0NIRUNLSU5HKFtmb3IgT0NhbWwgZmluZGxpYiBwYWNrYWdl
ICQxXSkKKworICB1bnNldCBmb3VuZAorICB1bnNldCBwa2cKKyAgZm91bmQ9bm8KKyAgZm9yIHBr
ZyBpbiAkMSAkMiA7IGRvCisgICAgaWYgJE9DQU1MRklORCBxdWVyeSAkcGtnID4vZGV2L251bGwg
Mj4vZGV2L251bGw7IHRoZW4KKyAgICAgIEFDX01TR19SRVNVTFQoW2ZvdW5kXSkKKyAgICAgIEFT
X1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT0kcGtnCisgICAgICBmb3VuZD15ZXMKKyAgICAgIGJyZWFr
CisgICAgZmkKKyAgZG9uZQorICBpZiB0ZXN0ICIkZm91bmQiID0gIm5vIiA7IHRoZW4KKyAgICBB
Q19NU0dfUkVTVUxUKFtub3QgZm91bmRdKQorICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT1u
bworICBmaQorCisgIEFDX1NVQlNUKEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKSkKK10pCisKKwor
QUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX01PRFVMRV0sCitbZG5sCisgIEFDX01TR19DSEVDS0lO
RyhbZm9yIE9DYW1sIG1vZHVsZSAkMl0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKK29w
ZW4gJDMKK0VPRgorICB1bnNldCBmb3VuZAorICBmb3IgJDEgaW4gJCQxICQ0IDsgZG8KKyAgICBp
ZiAkT0NBTUxDIC1jIC1JICIkJDEiIGNvbmZ0ZXN0Lm1sID4mNSAyPiY1IDsgdGhlbgorICAgICAg
Zm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRvbmUKKworICBpZiB0ZXN0ICIkZm91
bmQiIDsgdGhlbgorICAgIEFDX01TR19SRVNVTFQoWyQkMV0pCisgIGVsc2UKKyAgICBBQ19NU0df
UkVTVUxUKFtub3QgZm91bmRdKQorICAgICQxPW5vCisgIGZpCisgIEFDX1NVQlNUKFskMV0pCitd
KQorCisKK2RubCBYWFggQ3Jvc3MtY29tcGlsaW5nCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxf
V09SRF9TSVpFXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisgIEFD
X01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGNvbXBpbGVyIHdvcmQgc2l6ZV0pCisgIGNhdCA+IGNv
bmZ0ZXN0Lm1sIDw8RU9GCisgIHByaW50X2VuZGxpbmUgKHN0cmluZ19vZl9pbnQgU3lzLndvcmRf
c2l6ZSkKKyAgRU9GCisgIE9DQU1MX1dPUkRfU0laRT1gJE9DQU1MIGNvbmZ0ZXN0Lm1sYAorICBB
Q19NU0dfUkVTVUxUKFskT0NBTUxfV09SRF9TSVpFXSkKKyAgQUNfU1VCU1QoW09DQU1MX1dPUkRf
U0laRV0pCitdKQorCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfT1NfVFlQRV0sCitbZG5sCisg
IEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW09DYW1s
IFN5cy5vc190eXBlXSkKKworICBjYXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9zdHJp
bmcoU3lzLm9zX3R5cGUpOzsKK0VPRgorCisgIE9DQU1MX09TX1RZUEU9YCRPQ0FNTCBjb25mdGVz
dC5tbGAKKyAgQUNfTVNHX1JFU1VMVChbJE9DQU1MX09TX1RZUEVdKQorICBBQ19TVUJTVChbT0NB
TUxfT1NfVFlQRV0pCitdKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgbTQv
cGF0aF9vcl9mYWlsLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL200L3BhdGhfb3JfZmFpbC5tNAlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAx
MDAKQEAgLTAsMCArMSw2IEBACitBQ19ERUZVTihbQVhfUEFUSF9QUk9HX09SX0ZBSUxdLAorW0FD
X1BBVEhfUFJPRyhbJDFdLCBbJDJdLCBbbm9dKQoraWYgdGVzdCB4IiR7JDF9IiA9PSB4Im5vIiAK
K3RoZW4KKyAgICBBQ19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kICQyLCBwbGVhc2UgaW5zdGFs
bCAkMl0pCitmaV0pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBtNC9weXRo
b25fZGV2ZWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
KysrIGIvbTQvcHl0aG9uX2RldmVsLm00CVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApA
QCAtMCwwICsxLDE4IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMXSwKK1tBQ19N
U0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQg
b3MucGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhw
ICsgIi9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEp
CisnID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBB
Q19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2ZWwgcGFja2Fn
ZSBub3QgZm91bmRdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBtNC9weXRob25fdmVyc2lvbi5tNAotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9tNC9weXRob25f
dmVyc2lvbi5tNAlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMiBA
QAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9OXSwKK1tBQ19NU0dfQ0hFQ0tJTkco
W2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7
IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwgJDIpIikpJ2AKK2lmIHRlc3QgIiQ/
IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYxYAorICAg
IEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoCisgICAgICAgIFskcHl0aG9u
X3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzICQxLiQyXSkK
K2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIDQwODZlNDgxMTU0
NyAtciBlMTJlYzEwNzE0MTAgbTQvcHl0aG9uX3htbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9tNC9weXRob25feG1sLm00CVNhdCBKYW4gMDcg
MDQ6MTc6MTAgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tf
UFlUSE9OX1hNTF0sCitbQUNfTVNHX0NIRUNLSU5HKFtmb3IgcHl0aG9uIHhtbC5kb20ubWluaWRv
bV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5kb20ubWluaWRvbSdgCitpZiB0ZXN0ICIkPyIg
IT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUihb
VW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1vZHVsZV0pCitlbHNlCisgICAgQUNfTVNH
X1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEw
IG00L3NldF9jZmxhZ3NfbGRmbGFncy5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi9tNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQJU2F0IEphbiAwNyAw
NDoxNzoxMCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTkgQEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxB
R1NdLAorW2ZvciBjZmxhZyBpbiAkUFJFUEVORF9JTkNMVURFUworZG8KKyAgICBQUkVQRU5EX0NG
TEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCitkbwor
ICAgIFBSRVBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitmb3IgY2ZsYWcgaW4gJEFQ
UEVORF9JTkNMVURFUworZG8KKyAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQor
Zm9yIGxkZmxhZyBpbiAkQVBQRU5EX0xJQgorZG8KKyAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRs
ZGZsYWciCitkb25lCitDRkxBR1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZM
QUdTIgorTERGTEFHUz0iJFBSRVBFTkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1Mi
XSkKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUx
MmVjMTA3MTQxMCBtNC91ZGV2Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL200L3VkZXYubTQJU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAw
CkBAIC0wLDAgKzEsMzIgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19VREVWXSwKK1tpZiB0ZXN0ICIk
aG9zdF9vcyIgPT0gImxpbnV4LWdudSIKK3RoZW4KKyAgICBBQ19QQVRIX1BST0coW1VERVZBRE1d
LCBbdWRldmFkbV0sIFtub10pCisgICAgaWYgdGVzdCB4IiR7VURFVkFETX0iID09IHgibm8iIAor
ICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtVREVWSU5GT10sIFt1ZGV2aW5mb10sIFtu
b10pCisgICAgICAgIGlmIHRlc3QgeCIke1VERVZJTkZPfSIgPT0geCJubyIKKyAgICAgICAgdGhl
bgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKAorICAgICAgICAgICAgICAgIFtVbmFibGUgdG8g
ZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2XSkKKyAgICAgICAg
ZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5GT30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AK
KyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3By
aW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVzdCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRo
ZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtIT1RQTFVHXSwgW2hvdHBsdWddLCBbbm9dKQorICAg
ICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAg
ICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlzIHRvbyBvbGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1
OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisgICAgZmkKK2Vsc2UKKyAgICBBQ19QQVRIX1BST0co
W1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25vXSkKKyAgICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30i
ID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBBQ19NU0dfRVJST1IoW05vdCBhIExpbnV4IHN5
c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kXSkKKyAgICBmaQorZmkKK10pCmRpZmYgLXIgNDA4
NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29scy9NYWtlZmlsZQotLS0gYS90b29scy9NYWtl
ZmlsZQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvTWFrZWZpbGUJ
U2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCkBAIC02LDcgKzYsNiBAQCBTVUJESVJTLWxp
YmFpbyA6PSBsaWJhaW8KIGVuZGlmCiAKIFNVQkRJUlMteSA6PQotU1VCRElSUy15ICs9IGNoZWNr
CiBTVUJESVJTLXkgKz0gaW5jbHVkZQogU1VCRElSUy15ICs9IGxpYnhjCiBTVUJESVJTLXkgKz0g
Zmxhc2sKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL2Jsa3RhcC9k
cml2ZXJzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVRodSBK
YW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi90b29scy9ibGt0YXAvZHJpdmVycy9NYWtl
ZmlsZQlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKQEAgLTEzLDcgKzEzLDcgQEAgQ0ZM
QUdTICAgKz0gJChDRkxBR1NfbGlieGVuc3RvcmUpCiBDRkxBR1MgICArPSAtSSAkKE1FTVNIUl9E
SVIpCiBDRkxBR1MgICArPSAtRF9HTlVfU09VUkNFCiAKLWlmZXEgKCQoc2hlbGwgLiAuL2NoZWNr
X2djcnlwdCAkKENDKSkseWVzKQoraWZlcSAoJENPTkZJR19HQ1JZUFQseSkKIENGTEFHUyArPSAt
RFVTRV9HQ1JZUFQKIENSWVBUX0xJQiA6PSAtbGdjcnlwdAogZWxzZQpkaWZmIC1yIDQwODZlNDgx
MTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvYmxrdGFwL2RyaXZlcnMvY2hlY2tfZ2NyeXB0Ci0t
LSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAlUaHUgSmFuIDA1IDE3OjI1OjIz
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0KLWNhdCA+IC5nY3J5cHQuYyA8PCBFT0YKLSNp
bmNsdWRlIDxnY3J5cHQuaD4KLWludCBtYWluKHZvaWQpIHsgcmV0dXJuIDA7IH0KLUVPRgotCi1p
ZiAkMSAtbyAuZ2NyeXB0IC5nY3J5cHQuYyAtbGdjcnlwdCAyPi9kZXYvbnVsbCA7IHRoZW4KLSAg
ZWNobyAieWVzIgotZWxzZQotICBlY2hvICJubyIKLWZpCi0KLXJtIC1mIC5nY3J5cHQqCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29scy9jaGVjay9NYWtlZmlsZQotLS0g
YS90b29scy9jaGVjay9NYWtlZmlsZQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjYgKzAsMCBA
QAotWEVOX1JPT1QgPSAkKENVUkRJUikvLi4vLi4KLWluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMv
UnVsZXMubWsKLQotIyBFeHBvcnQgdGhlIG5lY2Vzc2FyeSBlbnZpcm9ubWVudCB2YXJpYWJsZXMg
Zm9yIHRoZSB0ZXN0cwotZXhwb3J0IFBZVEhPTgotZXhwb3J0IExJQlhFTkFQSV9CSU5ESU5HUwot
ZXhwb3J0IENIRUNLX0lOQ0xVREVTCi1leHBvcnQgQ0hFQ0tfTElCCi1leHBvcnQgQ09ORklHX1NZ
U1RFTV9MSUJBSU8KLQotLlBIT05ZOiBhbGwgaW5zdGFsbAotYWxsIGluc3RhbGw6IGNoZWNrLWJ1
aWxkCi0KLSMgQ2hlY2sgdGhpcyBtYWNoaW5lIGlzIE9LIGZvciBidWlsZGluZyBvbi4KLS5QSE9O
WTogY2hlY2stYnVpbGQKLWNoZWNrLWJ1aWxkOgotCS4vY2hrIGJ1aWxkCi0KLSMgQ2hlY2sgdGhp
cyBtYWNoaW5lIGlzIE9LIGZvciBpbnN0YWxsaW5nIG9uLgotLlBIT05ZOiBjaGVjay1pbnN0YWxs
Ci1jaGVjay1pbnN0YWxsOgotCS4vY2hrIGluc3RhbGwKLQotLlBIT05ZOiBjbGVhbgotY2xlYW46
Ci0JLi9jaGsgY2xlYW4KZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xz
L2NoZWNrL1JFQURNRQotLS0gYS90b29scy9jaGVjay9SRUFETUUJVGh1IEphbiAwNSAxNzoyNToy
MyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDIwICswLDAgQEAKLUNoZWNrcyBmb3IgdGhlIHN1aXRhYmlsaXR5IG9mIGEgbWFjaGlu
ZSBmb3IgWGVuIGJ1aWxkIG9yIGluc3RhbGwuCi1UbyBjaGVjayBmb3IgYnVpbGQgc3VpdGFiaWxp
dHkgdXNlCi0KLSAgICAgICAgLi9jaGsgYnVpbGQKLQotVG8gY2hlY2sgZm9yIGluc3RhbGwgc3Vp
dGFiaWxpdHkgdXNlCi0KLSAgICAgICAgLi9jaGsgaW5zdGFsbAotCi1UaGUgY2hrIHNjcmlwdCB3
aWxsIHJ1biBjaGVja3MgaW4gdGhpcyBkaXJlY3RvcnkgYW5kIHByaW50Ci10aGUgb25lcyB0aGF0
IGZhaWxlZC4gSXQgcHJpbnRzIG5vdGhpbmcgaWYgY2hlY2tzIHN1Y2NlZWQuCi1UaGUgY2hrIHNj
cmlwdCBleGl0cyB3aXRoIDAgb24gc3VjY2VzcyBhbmQgMSBvbiBmYWlsdXJlLgotCi1UaGUgY2hr
IHNjcmlwdCBydW5zIGV4ZWN1dGFibGUgZmlsZXMgaW4gdGhpcyBkaXJlY3Rvcnkgd2hvc2UKLW5h
bWVzIGJlZ2luIHdpdGggJ2NoZWNrXycuIEZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0stQlVJTEQKLWFy
ZSBydW4gZm9yIHRoZSBidWlsZCBjaGVjaywgYW5kIGZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0stSU5T
VEFMTAotYXJlIHJ1biBmb3IgdGhlIGluc3RhbGwgY2hlY2suCi0KLURldGFpbGVkIG91dHB1dCBm
cm9tIHRoZSBjaGVjayBzY3JpcHRzIGlzIGluIC5jaGtidWlsZCBmb3IgYnVpbGQKLWFuZCAuY2hr
aW5zdGFsbCBmb3IgaW5zdGFsbC4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLXIg
NDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29scy9jaGVjay9jaGVja19icmN0bAotLS0g
YS90b29scy9jaGVjay9jaGVja19icmN0bAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAK
KysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2Ug
JE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhhc19vcl9mYWlsIGJyY29uZmlnIDs7
Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBicmN0bCA7OwotKikKLQlmYWlsICJ1bmtub3duIE9TIiA7
OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2sv
Y2hlY2tfY3J5cHRvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19jcnlwdG9fbGliCVRodSBK
YW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQg
Q0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0
QlNEfE9wZW5CU0QpCi0JZXhpdCAwIDs7Ci1lc2FjCi0KLWhhc19saWIgbGliY3J5cHRvLnNvIHx8
IGZhaWwgIm1pc3NpbmcgbGliY3J5cHRvLnNvIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJl
YzEwNzE0MTAgdG9vbHMvY2hlY2svY2hlY2tfY3VybAotLS0gYS90b29scy9jaGVjay9jaGVja19j
dXJsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyAiJExJQlhFTkFQ
SV9CSU5ESU5HUyIgIT0gInkiIF07IHRoZW4KLQllY2hvIC1uICJ1bnVzZWQsICIKLQlleGl0IDAK
LWZpCi0KLWhhc19vcl9mYWlsIGN1cmwtY29uZmlnCi1jdXJsX2xpYnM9YGN1cmwtY29uZmlnIC0t
bGlic2AgfHwgZmFpbCAiY3VybC1jb25maWcgLS1saWJzIGZhaWxlZCIKLXRlc3RfbGluayAkY3Vy
bF9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZvciBjdXJsIGFyZSBtaXNzaW5n
IgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2svY2hlY2tf
aXByb3V0ZQotLS0gYS90b29scy9jaGVjay9jaGVja19pcHJvdXRlCVRodSBKYW4gMDUgMTc6MjU6
MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSwxNSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVu
Y3Muc2gKLQotUEFUSD0vc2JpbjokUEFUSAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8
RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBpZmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwg
aXAgOzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19kZXZlbAotLS0gYS90
b29scy9jaGVjay9jaGVja19saWJhaW9fZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEx
ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYg
WyBYJHtDT05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQgMAot
ZmkKLWlmICEgaGFzX2hlYWRlciBsaWJhaW8uaCA7IHRoZW4KLSAgICBmYWlsICJjYW4ndCBmaW5k
IGxpYmFpbyBoZWFkZXJzLCBpbnN0YWxsIGxpYmFpbyBkZXZlbCBwYWNrYWdlIG9yIHNldCBDT05G
SUdfU1lTVEVNX0xJQkFJTz1uIgotZmkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcx
NDEwIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tf
bGliYWlvX2xpYglUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0jIS9iaW4vc2gK
LSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyBYJHtD
T05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQgMAotZmkKLWhh
c19saWIgbGliYWlvLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGliYWlvIgpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNzbF9kZXZlbAot
LS0gYS90b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gK
LQotaGFzX2hlYWRlciBvcGVuc3NsL21kNS5oIHx8IGZhaWwgIm1pc3Npbmcgb3BlbnNzbCBoZWFk
ZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2svY2hl
Y2tfcHl0aG9uCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbglUaHUgSmFuIDA1IDE3OjI1
OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RB
TEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhP
Tj1weXRob24KLWZpCi0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgc3lzCi1zeXMuZXhpdChzeXMu
dmVyc2lvbl9pbmZvWzBdIDwgMiBvciBzeXMudmVyc2lvbl9pbmZvWzFdIDwgMykKLScgfHwgZmFp
bCAibmVlZCBweXRob24gdmVyc2lvbiA+PSAyLjMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUx
MmVjMTA3MTQxMCB0b29scy9jaGVjay9jaGVja19weXRob25fZGV2ZWwKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfcHl0aG9uX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNyArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXog
JHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZpCi1oYXNfb3JfZmFpbCAke1BZVEhP
Tn0KLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBvcy5wYXRoLCBzeXMKLWZvciBwIGluIHN5cy5w
YXRoOgotCWlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIpOgotCQlzeXMu
ZXhpdCgwKQotc3lzLmV4aXQoMSkKLScgfHwgZmFpbCAiY2FuJ3QgZmluZCBweXRob24gZGV2ZWwg
ZmlsZXMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29scy9jaGVjay9j
aGVja19weXRob25feG1sCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl94bWwJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxM
Ci0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049
cHl0aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnaW1wb3J0
IHhtbC5kb20ubWluaWRvbScgMj4vZGV2L251bGwgfHwgXAotZmFpbCAiY2FuJ3QgaW1wb3J0IHht
bC5kb20ubWluaWRvbSIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xz
L2NoZWNrL2NoZWNrX3VkZXYKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdWRldglUaHUgSmFuIDA1
IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsMjIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQot
LiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhh
c19vcl9mYWlsIHZuY29uZmlnCi0JOzsKLUxpbnV4KQotCWhhcyAvc2Jpbi91ZGV2YWRtICYmIFwK
LQkJdWRldnZlcj1gL3NiaW4vdWRldmFkbSBpbmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCi0J
WyAteiAiJHVkZXZ2ZXIiIF0gJiYgaGFzX29yX2ZhaWwgdWRldmluZm8gJiYgXAotCQl1ZGV2dmVy
PWB1ZGV2aW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgIiR1ZGV2dmVyIiAtZ2UgNTkg
XSAyPi9kZXYvbnVsbCB8fCBcCi0JCWhhcyBob3RwbHVnIHx8IFwKLQkJZmFpbCAidWRldiBpcyB0
b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3IgbGF0ZXIiCi0JOzsKLSopCi0JZmFpbCAi
dW5rbm93biBPUyIKLQk7OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0
MTAgdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja191
dWlkX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw3ICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB1dWlkLmggfHwgXAot
aGFzX2hlYWRlciB1dWlkL3V1aWQuaCB8fCBmYWlsICJtaXNzaW5nIHV1aWQgaGVhZGVycyAocGFj
a2FnZSB1dWlkLWRldikiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29s
cy9jaGVjay9jaGVja194MTFfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVs
CVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1C
VUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciBYMTEva2V5c3ltZGVmLmggfHwgXAot
aGFzX2hlYWRlciAvdXNyL1gxMVI2L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLWhhc19o
ZWFkZXIgL3Vzci9YMTFSNy9pbmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8fCBcCi13YXJuaW5nICJj
YW4ndCBmaW5kIFgxMSBoZWFkZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0
MTAgdG9vbHMvY2hlY2svY2hlY2tfeGdldHRleHQKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeGdl
dHRleHQJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3NoCi0jIENI
RUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfb3JfZmFpbCB4Z2V0dGV4dApkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2svY2hlY2tfeG1sMgotLS0g
YS90b29scy9jaGVjay9jaGVja194bWwyCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAor
KysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNCArMCww
IEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Mu
c2gKLQotaWYgWyAhICIkTElCWEVOQVBJX0JJTkRJTkdTIiA9ICJ5IiBdCi10aGVuCi0gICAgZWNo
byAtbiAidW51c2VkLCAiCi0gICAgZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCB4bWwyLWNvbmZp
ZwoteG1sMl9saWJzPWB4bWwyLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgInhtbDItY29uZmlnIC0t
bGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJHhtbDJfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxp
YnJhcmllcyBmb3IgeG1sMiBhcmUgbWlzc2luZyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEy
ZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2sv
Y2hlY2tfeWFqbF9kZXZlbAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOCArMCwwIEBACi0jIS9i
aW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgeWFqbC95
YWpsX3BhcnNlLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfcGFyc2UuaCIKLWhhc19o
ZWFkZXIgeWFqbC95YWpsX2dlbi5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95YWpsX2dlbi5o
IgotaGFzX2xpYiBsaWJ5YWpsLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFqbC5zbyIKZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxf
bGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfbGliCVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfbGliIGxpYnlhamwuc28uMSB8fCBmYWlsICJjYW4ndCBmaW5k
IGxpYnlhamwuc28uMSB2ZXJzaW9uIDEiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3
MTQxMCB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3psaWJfZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBm
YWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEy
ZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX3psaWJfbGliCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAk
T1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFz
X2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJ
VGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3Vz
YWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFs
bHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4g
YnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90
LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5l
cmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2Jp
bgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIg
XTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBj
aGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hl
Y2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQg
MAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVz
YWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBj
aGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29u
dGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVz
YWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQot
ICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0g
ICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRo
ZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQot
ZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0
MTAgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGlj
aCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAt
eiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVy
biAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0
byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBp
biAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0J
CQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUK
LQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVs
bCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5
c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBb
IC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAw
Ci0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAi
JENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQot
CQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVj
a19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlv
biBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAj
IGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhp
cyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0
Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3Jr
LgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNv
LmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JP
U1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91
Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9
ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JP
U1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIk
e09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZx
ICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkg
ewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1w
ZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1g
bWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+
JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5
IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiBy
ZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVh
c2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlm
aQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1y
b290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJu
aW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAk
Kn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZB
SUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMx
MDcxNDEwIHRvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2RlYnVn
Z2VyL2dkYnN4L3hnL01ha2VmaWxlCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysg
Yi90b29scy9kZWJ1Z2dlci9nZGJzeC94Zy9NYWtlZmlsZQlTYXQgSmFuIDA3IDA0OjE3OjEwIDIw
MTIgKzAxMDAKQEAgLTIxLDcgKzIxLDYgQEAgeGdfYWxsLmE6ICQoWEdfT0JKUykgTWFrZWZpbGUg
JChYR19IRFJTKQogIwkkKENDKSAtbTMyIC1jIC1vICRAICReCiAKIHhlbi1oZWFkZXJzOgotCSQo
TUFLRSkgLUMgLi4vLi4vLi4vY2hlY2sgCiAJJChNQUtFKSAtQyAuLi8uLi8uLi9pbmNsdWRlCiAK
ICMgeGdfbWFpbi5vOiB4Z19tYWluLmMgTWFrZWZpbGUgJChYR19IRFJTKQpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQotLS0gYS90
b29scy9saWJmc2ltYWdlL01ha2VmaWxlCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAor
KysgYi90b29scy9saWJmc2ltYWdlL01ha2VmaWxlCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiAr
MDEwMApAQCAtMiw3ICsyLDExIEBAIFhFTl9ST09UID0gJChDVVJESVIpLy4uLy4uCiBpbmNsdWRl
ICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCiAKIFNVQkRJUlMteSA9IGNvbW1vbiB1ZnMgcmVp
c2VyZnMgaXNvOTY2MCBmYXQgemZzIHhmcwotU1VCRElSUy15ICs9ICQoc2hlbGwgZW52IENDPSIk
KENDKSIgLi9jaGVjay1saWJleHQyZnMpCitpZmVxICgkKENPTkZJR19FWFQyRlMpLCB5KQorICAg
IFNVQkRJUlMteSArPSBleHQyZnMtbGliCitlbHNlCisgICAgU1VCRElSUy15ICs9IGV4dDJmcwor
ZW5kaWYKIAogLlBIT05ZOiBhbGwgY2xlYW4gaW5zdGFsbAogYWxsIGNsZWFuIGluc3RhbGw6ICU6
IHN1YmRpcnMtJQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvbGli
ZnNpbWFnZS9jaGVjay1saWJleHQyZnMKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9jaGVjay1saWJl
eHQyZnMJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIxICswLDAgQEAKLSMhL2Jpbi9zaAotCi1j
YXQgPmV4dDItdGVzdC5jIDw8RU9GCi0jaW5jbHVkZSA8ZXh0MmZzL2V4dDJmcy5oPgotCi1pbnQg
bWFpbigpCi17Ci0JZXh0MmZzX29wZW4yOwotfQotRU9GCi0KLSR7Q0MtZ2NjfSAtbyBleHQyLXRl
c3QgZXh0Mi10ZXN0LmMgLWxleHQyZnMgPi9kZXYvbnVsbCAyPiYxCi1pZiBbICQ/ID0gMCBdOyB0
aGVuCi0JZWNobyBleHQyZnMtbGliCi1lbHNlCi0JZWNobyBleHQyZnMKLWZpCi0KLXJtIC1mIGV4
dDItdGVzdCBleHQyLXRlc3QuYwotCi1leGl0IDAKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEy
ZWMxMDcxNDEwIHRvb2xzL2xpYnhlbi9NYWtlZmlsZQotLS0gYS90b29scy9saWJ4ZW4vTWFrZWZp
bGUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhlbi9NYWtl
ZmlsZQlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKQEAgLTIyLDEyICsyMiwxMiBAQCBN
QUpPUiA9IDEuMAogTUlOT1IgPSAwCiAKIENGTEFHUyArPSAtSWluY2x1ZGUgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgICAgJChzaGVsbCB4bWwyLWNvbmZpZyAtLWNmbGFncykgXAotICAg
ICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1jZmxhZ3MpIFwKKyAgICAgICAgICAkKHNoZWxs
ICQoWE1MMi1DT05GSUcpIC0tY2ZsYWdzKSBcCisgICAgICAgICAgJChzaGVsbCAkKENVUkwtQ09O
RklHKSAtLWNmbGFncykgXAogICAgICAgICAgIC1mUElDCiAKLUxERkxBR1MgKz0gJChzaGVsbCB4
bWwyLWNvbmZpZyAtLWxpYnMpIFwKLSAgICAgICAgICAgJChzaGVsbCBjdXJsLWNvbmZpZyAtLWxp
YnMpCitMREZMQUdTICs9ICQoc2hlbGwgJChYTUwyLUNPTkZJRykgLS1saWJzKSBcCisgICAgICAg
ICAgICQoc2hlbGwgJChDVVJMLUNPTkZJRykgLS1saWJzKQogCiBMSUJYRU5BUElfSERSUyA9ICQo
d2lsZGNhcmQgaW5jbHVkZS94ZW4vYXBpLyouaCkgaW5jbHVkZS94ZW4vYXBpL3hlbl9hbGwuaAog
TElCWEVOQVBJX09CSlMgPSAkKHBhdHN1YnN0ICUuYywgJS5vLCAkKHdpbGRjYXJkIHNyYy8qLmMp
KQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 08 11:45:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 11:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjrAX-0001QJ-SG; Sun, 08 Jan 2012 11:44:09 +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 1RjrAW-0001QE-Au
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 11:44:08 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326023025!61552578!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.6 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_24_48,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18762 invoked from network); 8 Jan 2012 11:43:45 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	8 Jan 2012 11:43:45 -0000
Received: by werg1 with SMTP id g1so6635725wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 08 Jan 2012 03:44: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=NlrIcShYGZMGy6RPfgkCz4GcJzHkHIqL5drVzmBGj/U=;
	b=Ht256I5gK6kLmn2UIbMWBsYLhZ20eeYinlhdsFuDgxwRHsLtZkPfP2DHLusVfIcEmw
	jHtAbUE+Yir+/Ik3ayB23iD3lCiOdsUUt/so0IIlVDIPUKXk3gwdIa4pJ2Kvymt+war4
	TwQmQ4LDywVT6OtwoLrpBAD1WBMDMtBcsD8Fg=
Received: by 10.216.136.204 with SMTP id w54mr1842085wei.44.1326023044385;
	Sun, 08 Jan 2012 03:44:04 -0800 (PST)
Received: from build.localdomain (234.Red-80-25-94.staticIP.rima-tde.net.
	[80.25.94.234])
	by mx.google.com with ESMTPS id m13sm75144623wbh.0.2012.01.08.03.44.00
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 08 Jan 2012 03:44:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e12ec1071410c946367cb0508cf218a0c3b596ca
Message-Id: <e12ec1071410c946367c.1325906408@build.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sat, 07 Jan 2012 04:20:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI1OTA2MjMwIC0zNjAwCiMgTm9kZSBJRCBlMTJlYzEwNzE0
MTBjOTQ2MzY3Y2IwNTA4Y2YyMThhMGMzYjU5NmNhCiMgUGFyZW50ICA0MDg2ZTQ4MTE1NDdkZGZm
YjlhNTNmYmYyZWZiNmMyZmE0MzZiNzBhCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwKY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KCkF1dG9jb25mLm1rIGlzIGluY2x1
ZGVkIGJ5IENvbmZpZy5taywgYW5kIGNvbnRhaW5zIG1vc3Qgb2YgdGhlCm9wdGlvbnMgcHJldmlv
dXNseSBkZWZpbmVkIGluIC5jb25maWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwpwYXJh
bWV0ZXJzIG9yIGRlZmluaW5nIGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBj
b25maWd1cmUKc2NyaXB0LgoKY29uZmlnLmggaXMgc3RpbGwgbm90IHVzZWQgYW55d2hlcmUsIGFu
ZCBpcyBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQgYnkKYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1p
Z2ggY2hhbmdlIHdoZW4gd2Ugc3RhcnQgdG8gaW5jbHVkZSB0aGlzCmZpbGUuCgpKdXN0IGEgZmly
c3QgcmVsZWFzZSwgYW5kIHNpbmNlIElpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlwdCBJIGd1
ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNlIHJl
dmlldyBhbmQgY29tbWVudC4KClNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIu
cGF1QGVudGVsLnVwYy5lZHU+CgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAg
Q29uZmlnLm1rCi0tLSBhL0NvbmZpZy5tawlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAK
KysrIGIvQ29uZmlnLm1rCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApAQCAtOSw4ICs5
LDYgQEAgcmVhbHBhdGggPSAkKHdpbGRjYXJkICQoZm9yZWFjaCBmaWxlLCQoMQogCiAtaW5jbHVk
ZSAkKFhFTl9ST09UKS8uY29uZmlnCiAKLSMgQSBkZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xz
PwotZGVidWcgPz0geQogCiBYRU5fQ09NUElMRV9BUkNIICAgID89ICQoc2hlbGwgdW5hbWUgLW0g
fCBzZWQgLWUgcy9pLjg2L3g4Nl8zMi8gXAogICAgICAgICAgICAgICAgICAgICAgICAgIC1lIHMv
aTg2cGMveDg2XzMyLyAtZSBzL2FtZDY0L3g4Nl82NC8pCkBAIC00Myw2ICs0MSw3IEBAIGVuZGlm
CiAKIGluY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnLyQoWEVOX09TKS5tawogaW5jbHVkZSAkKFhF
Tl9ST09UKS9jb25maWcvJChYRU5fVEFSR0VUX0FSQ0gpLm1rCitpbmNsdWRlICQoWEVOX1JPT1Qp
L2NvbmZpZy9BdXRvY29uZi5tawogCiBTSEFSRURJUiAgICA/PSAkKFBSRUZJWCkvc2hhcmUKIERP
Q0RJUiAgICAgID89ICQoU0hBUkVESVIpL2RvYy94ZW4KQEAgLTcwLDEwICs2OSw2IEBAIEVYVFJB
X0lOQ0xVREVTICs9ICQoRVhUUkFfUFJFRklYKS9pbmNsdWQKIEVYVFJBX0xJQiArPSAkKEVYVFJB
X1BSRUZJWCkvJChMSUJMRUFGRElSKQogZW5kaWYKIAotQklTT04JPz0gYmlzb24KLUZMRVgJPz0g
ZmxleAotCi1QWVRIT04gICAgICA/PSBweXRob24KIFBZVEhPTl9QUkVGSVhfQVJHID89IC0tcHJl
Zml4PSIkKFBSRUZJWCkiCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJWCBjb250YWlu
cyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCiAjIHRvIHBlcm1pdCB0aGUgdXNl
ciB0byBzZXQgUFlUSE9OX1BSRUZJWF9BUkcgdG8gJycgdG8gd29ya2Fyb3VuZCB0aGlzIGJ1ZzoK
QEAgLTE3NSwyMiArMTcwLDkgQEAgQ0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKFBSRVBFTkRfSU5D
TFVERQogQVBQRU5EX0xERkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0xJQiksIC1MJChp
KSkKIEFQUEVORF9DRkxBR1MgKz0gJChmb3JlYWNoIGksICQoQVBQRU5EX0lOQ0xVREVTKSwgLUkk
KGkpKQogCi1DSEVDS19MSUIgPSAkKEVYVFJBX0xJQikgJChQUkVQRU5EX0xJQikgJChBUFBFTkRf
TElCKQotQ0hFQ0tfSU5DTFVERVMgPSAkKEVYVFJBX0lOQ0xVREVTKSAkKFBSRVBFTkRfSU5DTFVE
RVMpICQoQVBQRU5EX0lOQ0xVREVTKQotCiBFTUJFRERFRF9FWFRSQV9DRkxBR1MgOj0gLW5vcGll
IC1mbm8tc3RhY2stcHJvdGVjdG9yIC1mbm8tc3RhY2stcHJvdGVjdG9yLWFsbAogRU1CRURERURf
RVhUUkFfQ0ZMQUdTICs9IC1mbm8tZXhjZXB0aW9ucwogCi0jIEVuYWJsZSBYU00gc2VjdXJpdHkg
bW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCi1YU01fRU5BQkxFID89IG4KLUZMQVNLX0VOQUJM
RSA/PSAkKFhTTV9FTkFCTEUpCi0KLSMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRU
UCBvciBHSVQncyBvd24gcHJvdG9jb2w/Ci0jIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQg
bW9yZSByb2J1c3QsIHdoZW4gaXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKLSMgbWF5IGJsb2Nr
IGl0KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkg
ZG93bmxvYWRzCi0jIGZhaWwgb3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5
b3VyIGVudmlyb25tZW50LgotR0lUX0hUVFAgPz0gbgotCiBYRU5fRVhURklMRVNfVVJMPWh0dHA6
Ly94ZW5iaXRzLnhlbnNvdXJjZS5jb20veGVuLWV4dGZpbGVzCiAjIEFsbCB0aGUgZmlsZXMgYXQg
dGhhdCBsb2NhdGlvbiB3ZXJlIGRvd25sb2FkZWQgZnJvbSBlbHNld2hlcmUgb24KICMgdGhlIGlu
dGVybmV0LiAgVGhlIG9yaWdpbmFsIGRvd25sb2FkIFVSTCBpcyBwcmVzZXJ2ZWQgYXMgYSBjb21t
ZW50CkBAIC0yMjIsMTcgKzIwNCwzIEBAIFFFTVVfVEFHID89IGJiMzZkNjMyZTRjYWJmNDc4ODJh
ZGZmMDdhNDUKICMgTm90ZSB0aGF0IHVzaW5nIFNlYUJJT1MgcmVxdWlyZXMgdGhlIHVzZSB0aGUg
dXBzdHJlYW0gcWVtdSBhcyB0aGUKICMgZGV2aWNlIG1vZGVsLgogU0VBQklPU19ESVIgPz0gCi0K
LSMgT3B0aW9uYWwgY29tcG9uZW50cwotWEVOU1RBVF9YRU5UT1AgICAgID89IHkKLVZUUE1fVE9P
TFMgICAgICAgICA/PSBuCi1MSUJYRU5BUElfQklORElOR1MgPz0gbgotUFlUSE9OX1RPT0xTICAg
ICAgID89IHkKLU9DQU1MX1RPT0xTICAgICAgICA/PSB5Ci1DT05GSUdfTUlOSVRFUk0gICAgPz0g
bgotQ09ORklHX0xPTU9VTlQgICAgID89IG4KLUNPTkZJR19TWVNURU1fTElCQUlPID89IHkKLQot
aWZlcSAoJChPQ0FNTF9UT09MUykseSkKLU9DQU1MX1RPT0xTIDo9ICQoc2hlbGwgb2NhbWxvcHQg
LXYgPiAvZGV2L251bGwgMj4mMSAmJiBlY2hvICJ5IiB8fCBlY2hvICJuIikKLWVuZGlmCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBNYWtlZmlsZQotLS0gYS9NYWtlZmlsZQlU
aHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIGIvTWFrZWZpbGUJU2F0IEphbiAwNyAw
NDoxNzoxMCAyMDEyICswMTAwCkBAIC00MCwxMSArNDAsOSBAQCBkaXN0OiBERVNURElSPSQoRElT
VERJUikvaW5zdGFsbAogZGlzdDogZGlzdC14ZW4gZGlzdC1rZXJuZWxzIGRpc3QtdG9vbHMgZGlz
dC1zdHViZG9tIGRpc3QtZG9jcyBkaXN0LW1pc2MKIAogZGlzdC1taXNjOgotCSQoSU5TVEFMTF9E
SVIpICQoRElTVERJUikvY2hlY2sKIAkkKElOU1RBTExfREFUQSkgLi9DT1BZSU5HICQoRElTVERJ
UikKIAkkKElOU1RBTExfREFUQSkgLi9SRUFETUUgJChESVNURElSKQogCSQoSU5TVEFMTF9QUk9H
KSAuL2luc3RhbGwuc2ggJChESVNURElSKQotCSQoSU5TVEFMTF9QUk9HKSB0b29scy9jaGVjay9j
aGsgdG9vbHMvY2hlY2svY2hlY2tfKiB0b29scy9jaGVjay9mdW5jcy5zaCAkKERJU1RESVIpL2No
ZWNrCiBkaXN0LSU6IERFU1RESVI9JChESVNURElSKS9pbnN0YWxsCiBkaXN0LSU6IGluc3RhbGwt
JQogCUA6ICMgZG8gbm90aGluZwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAg
UkVBRE1FCi0tLSBhL1JFQURNRQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIGIv
UkVBRE1FCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApAQCAtODcsOSArODcsMTUgQEAg
Mi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0ZXZlciB5b3UgcwogMy4gRm9yIHRoZSB2ZXJ5
IGZpcnN0IGJ1aWxkLCBvciBpZiB5b3Ugd2FudCB0byBkZXN0cm95IGJ1aWxkIHRyZWVzLAogICAg
cGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgogCisgICAgIyBhdXRvbWFrZSAtYQorICAgICMg
YXV0b2hlYWRlciAmJiBhdXRvY29uZgorICAgICMgLi9jb25maWd1cmUKICAgICAjIG1ha2Ugd29y
bGQKICAgICAjIG1ha2UgaW5zdGFsbAogCisgICBJZiB5b3Ugd2FudCwgeW91IGNhbiBydW4gLi9j
b25maWd1cmUgLS1oZWxwIHRvIHNlZSB0aGUgbGlzdCBvZgorICAgb3B0aW5zIGF2YWlsYWJsZSBv
cHRpb25zIHdoZW4gYnVpbGRpbmcgYW5kIGluc3RhbGxpbmcgWGVuLgorCiAgICBUaGlzIHdpbGwg
Y3JlYXRlIGFuZCBpbnN0YWxsIG9udG8gdGhlIGxvY2FsIG1hY2hpbmUuIEl0IHdpbGwgYnVpbGQK
ICAgIHRoZSB4ZW4gYmluYXJ5ICh4ZW4uZ3opLCB0aGUgdG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0
aW9uLgogCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBjb25maWcvQXV0b2Nv
bmYubWsuaW4KLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIvY29uZmlnL0F1dG9jb25mLm1rLmluCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApA
QCAtMCwwICsxLDQ5IEBACisjIFByZWZpeCBhbmQgaW5zdGFsbCBmb2xkZXIKK1BSRUZJWCAgICAg
ICAgICAgICAgOj0gQHByZWZpeEAKK0xJQkxFQUZESVJfeDg2XzY0ICAgOj0gQExJQl9QQVRIQAor
CisjIEEgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAg
Oj0gQGRlYnVnQAorCisjIFRvb2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09O
QAorRkxFWCAgICAgICAgICAgICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0g
QFBZVEhPTkAKK1BFUkwgICAgICAgICAgICAgICAgOj0gQFBFUkxACitCUkNUTCAgICAgICAgICAg
ICAgIDo9IEBCUkNUTEAKK0lQICAgICAgICAgICAgICAgICAgOj0gQElQQAorQ1VSTC1DT05GSUcg
ICAgICAgICA6PSBAQ1VSTEAKK1hNTDItQ09ORklHICAgICAgICAgOj0gQFhNTEAKK0JBU0ggICAg
ICAgICAgICAgICAgOj0gQEJBU0hACitYR0VUVFRFWFQgICAgICAgICAgIDo9IEBYR0VUVEVYVEAK
KworIyBFeHRyYSBmb2xkZXIgZm9yIGxpYnMvaW5jbHVkZXMKK1BSRVBFTkRfSU5DTFVERVMgICAg
Oj0gQFBSRVBFTkRfSU5DTFVERVNACitQUkVQRU5EX0xJQiAgICAgICAgIDo9IEBQUkVQRU5EX0xJ
QkAKK0FQUEVORF9JTkNMVURFUyAgICAgOj0gQEFQUEVORF9JTkNMVURFU0AKK0FQUEVORF9MSUIg
ICAgICAgICAgOj0gQEFQUEVORF9MSUJACisKKyMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUg
KGJ5IGRlZmF1bHQsIEZsYXNrKS4KK1hTTV9FTkFCTEUgICAgICAgICAgOj0gQHhzbUAKK0ZMQVNL
X0VOQUJMRSAgICAgICAgOj0gQHhzbUAKKworIyBEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZp
YSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8KKyMgR0lUJ3MgcHJvdG9jb2wgaXMgZmFzdGVy
IGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3JrcyBhdCBhbGwgKGZpcmV3YWxscworIyBtYXkg
YmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBkZWZhdWx0LCBidXQgaWYgeW91ciBHSVQgcmVwb3Np
dG9yeSBkb3dubG9hZHMKKyMgZmFpbCBvciBoYW5nLCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15
IGluIHlvdXIgZW52aXJvbm1lbnQuCitHSVRfSFRUUCAgICAgICAgICAgIDo9IEBnaXRodHRwQAor
CisjIE9wdGlvbmFsIGNvbXBvbmVudHMKK1hFTlNUQVRfWEVOVE9QICAgICAgOj0gQG1vbml0b3Jz
QAorVlRQTV9UT09MUyAgICAgICAgICA6PSBAdnRwbUAKK0xJQlhFTkFQSV9CSU5ESU5HUyAgOj0g
QHhhcGlACitQWVRIT05fVE9PTFMgICAgICAgIDo9IEBweXRob250b29sc0AKK09DQU1MX1RPT0xT
ICAgICAgICAgOj0gQG9jYW1sdG9vbHNACitDT05GSUdfTUlOSVRFUk0gICAgIDo9IEBtaW5pdGVy
bUAKK0NPTkZJR19MT01PVU5UICAgICAgOj0gQGxvbW91bnRACisKKyNTeXN0ZW0gb3B0aW9ucwor
Q09ORklHX1NZU1RFTV9MSUJBSU86PSBAc3lzdGVtX2Fpb0AKK0NPTkZJR19MSUJJQ09OViAgICAg
Oj0gQGxpYmljb252QAorQ09ORklHX0dDUllQVCAgICAgICA6PSBAbGliZ2NyeXB0QAorQ09ORklH
X0VYVDJGUyAgICAgICA6PSBAbGliZXh0MmZzQApkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJl
YzEwNzE0MTAgY29uZmlndXJlLmFjCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL2NvbmZpZ3VyZS5hYwlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAx
MDAKQEAgLTAsMCArMSwxNzkgQEAKKyMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC0qLSBBdXRvY29uZiAtKi0KKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0aCBh
dXRvY29uZiB0byBwcm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KKworQUNfUFJFUkVRKFsyLjY3
XSkKK0FDX0lOSVQoW1hlbiBIeXBlcnZpc29yXSwgWzQuMl0sIFt4ZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbV0pCitBQ19DT05GSUdfU1JDRElSKFt0b29scy9saWJ4bC9saWJ4bC5jXSkKK0FD
X0NPTkZJR19IRUFERVJTKFtjb25maWcuaF0pCitBQ19DT05GSUdfRklMRVMoW2NvbmZpZy9BdXRv
Y29uZi5ta10pCitBQ19QUkVGSVhfREVGQVVMVChbL3Vzcl0pCisKKyMgQ2hlY2sgaWYgQ0ZMQUdT
LCBMREZMQUdTLCBMSUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdhcm5p
bmcKKworQVNfSUYoW3Rlc3QgLW4gIiRDQyRDRkxBR1MkTERGTEFHUyRMSUJTJENQUEZMQUdTJENQ
UCJdLCBbCisgICAgQUNfTVNHX1dBUk4oCitbU2V0dGluZyBDQywgQ0ZMQUdTLCBMREZMQUdTLCBM
SUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgbm90IFwKK3JlY29tbWVuZGVkLCB1c2UgUFJFUEVORF9J
TkNMVURFUywgUFJFUEVORF9MSUIsIFwKK0FQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBp
bnN0ZWFkIHdoZW4gcG9zc2libGUuXSkKK10pCisKK0FDX1VTRV9TWVNURU1fRVhURU5TSU9OUwor
QUNfQ0FOT05JQ0FMX0hPU1QKKworIyBNNCBNYWNybyBpbmNsdWRlcworbTRfaW5jbHVkZShbbTQv
ZW5hYmxlX2ZlYXR1cmUubTRdKQorbTRfaW5jbHVkZShbbTQvZGlzYWJsZV9mZWF0dXJlLm00XSkK
K200X2luY2x1ZGUoW200L3BhdGhfb3JfZmFpbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25f
eG1sLm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl92ZXJzaW9uLm00XSkKK200X2luY2x1ZGUo
W200L3B5dGhvbl9kZXZlbC5tNF0pCittNF9pbmNsdWRlKFttNC91ZGV2Lm00XSkKK200X2luY2x1
ZGUoW200L29jYW1sLm00XSkKK200X2luY2x1ZGUoW200L2RlZmF1bHRfbGliLm00XSkKK200X2lu
Y2x1ZGUoW200L3NldF9jZmxhZ3NfbGRmbGFncy5tNF0pCisKKyMgRW5hYmxlL2Rpc2FibGUgb3B0
aW9ucworQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt4c21dLAorICAgIFtFbmFibGUgWFNNIHNl
Y3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2spXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VY
UE9SVChbZ2l0aHR0cF0sIFtEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQXSkKK0FY
X0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW21vbml0b3JzXSwKKyAgICBbRGlzYWJsZSB4ZW5zdGF0
IGFuZCB4ZW50b3AgbW9uaXRvcmluZyB0b29sc10pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQo
W3Z0cG1dLCBbRW5hYmxlIFZpcnR1YWwgVHJ1c3RlZCBQbGF0Zm9ybSBNb2R1bGVdKQorQVhfQVJH
X0VOQUJMRV9BTkRfRVhQT1JUKFt4YXBpXSwgW0VuYWJsZSBYZW4gQVBJIEJpbmRpbmdzXSkKK0FY
X0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW3B5dGhvbnRvb2xzXSwgW0Rpc2FibGUgUHl0aG9uIHRv
b2xzXSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBPUlQoW29jYW1sdG9vbHNdLCBbRGlzYWJsZSBP
Y2FtbCB0b29sc10pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW21pbml0ZXJtXSwgW0VuYWJs
ZSBtaW5pdGVybV0pCitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW2xvbW91bnRdLCBbRW5hYmxl
IGxvbW91bnRdKQorQVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbZGVidWddLCBbRGlzYWJsZSBk
ZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xzXSkKKworQUNfQVJHX1ZBUihbUFJFUEVORF9JTkNM
VURFU10sCisgICAgW0xpc3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gQ0ZMQUdT
ICh3aXRob3V0IC1JKV0pCitBQ19BUkdfVkFSKFtQUkVQRU5EX0xJQl0sCisgICAgW0xpc3Qgb2Yg
bGlicmFyeSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCldKQorQUNf
QVJHX1ZBUihbQVBQRU5EX0lOQ0xVREVTXSwKKyAgICBbTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMg
dG8gYXBwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSldKQorQUNfQVJHX1ZBUihbQVBQRU5EX0xJ
Ql0sCisgICAgW0xpc3Qgb2YgbGlicmFyeSBmb2xkZXJzIHRvIGFwcGVuZCB0byBMREZMQUdTICh3
aXRob3V0IC1MKV0pCisKK0FYX1NFVF9GTEFHUworCitBQ19BUkdfVkFSKFtQWVRIT05dLCBbUGF0
aCB0byBQeXRob24gcGFyc2VyXSkKK0FDX0FSR19WQVIoW1BFUkxdLCBbUGF0aCB0byBQZXJsIHBh
cnNlcl0pCitBQ19BUkdfVkFSKFtCUkNUTF0sIFtQYXRoIHRvIGJyY3RsIHRvb2xdKQorQUNfQVJH
X1ZBUihbSVBdLCBbUGF0aCB0byBpcCB0b29sXSkKK0FDX0FSR19WQVIoW0JJU09OXSwgW1BhdGgg
dG8gQmlzb24gcGFyc2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtGTEVYXSwgW1BhdGggdG8g
RmxleCBsZXhpY2FsIGFuYWx5c2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtDVVJMXSwgW1Bh
dGggdG8gY3VybC1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtYTUxdLCBbUGF0aCB0byB4bWwy
LWNvbmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW0JBU0hdLCBbUGF0aCB0byBiYXNoIHNoZWxsXSkK
K0FDX0FSR19WQVIoW1hHRVRURVhUXSwgW1BhdGggdG8geGdldHR0ZXh0IHRvb2xdKQorCisjIENo
ZWNrcyBmb3IgcHJvZ3JhbXMuCitBQ19QUk9HX1NFRAorQUNfUFJPR19DQworQUNfUFJPR19JTlNU
QUxMCitBQ19QUk9HX0xOX1MKK0FDX1BST0dfTUFLRV9TRVQKK0FYX1BBVEhfUFJPR19PUl9GQUlM
KFtQRVJMXSwgW3BlcmxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JSQ1RMXSwgW2JyY3RsXSkK
K0FYX1BBVEhfUFJPR19PUl9GQUlMKFtJUF0sIFtpcF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChb
QklTT05dLCBbYmlzb25dKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0ZMRVhdLCBbZmxleF0pCitB
U19JRihbdGVzdCAieCR4YXBpIiA9ICJ4eSJdLCBbCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwo
W0NVUkxdLCBbY3VybC1jb25maWddKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtYTUxdLCBb
eG1sMi1jb25maWddKQorXSkKK0FTX0lGKFt0ZXN0ICJ4JG9jYW1sdG9vbHMiID0gInh5Il0sIFsK
KyAgICBBQ19QUk9HX09DQU1MCisgICAgQVNfSUYoW3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwg
WworICAgICAgQUNfTVNHX0VSUk9SKFtZb3UgbXVzdCBpbnN0YWxsIHRoZSBPQ2FtbCBjb21waWxl
cl0pCisgICAgXSkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQkFTSF0sIFtiYXNoXSkKK0FT
X0lGKFt0ZXN0ICJ4JHB5dGhvbnRvb2xzIiA9ICJ4eSJdLCBbCisgICAgQVhfUEFUSF9QUk9HX09S
X0ZBSUwoW1BZVEhPTl0sIFtweXRob25dKQorICAgIEFYX0NIRUNLX1BZVEhPTl9WRVJTSU9OKFsy
XSwgWzNdKQorICAgIEFYX0NIRUNLX1BZVEhPTl9YTUwoKQorICAgIEFYX0NIRUNLX1BZVEhPTl9E
RVZFTCgpCitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hHRVRURVhUXSwgW3hnZXR0ZXh0XSkK
K0FYX0NIRUNLX1VERVYoWzU5XSkKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK0FYX0RFRkFVTFRf
TElCCisKKyMgQ2hlY2tzIGZvciBsaWJyYXJpZXMuCitBQ19DSEVDS19MSUIoW2Fpb10sIFtpb19z
ZXR1cF0sIFtzeXN0ZW1fYWlvPSJ5Il0sIFtzeXN0ZW1fYWlvPSJuIl0pCitBQ19TVUJTVChzeXN0
ZW1fYWlvKQorQUNfQ0hFQ0tfTElCKFtjcnlwdG9dLCBbTUQ1XSwgW10sIFtBQ19NU0dfRVJST1Io
W0NvdWxkIG5vdCBmaW5kIGxpYmNyeXB0b10pXSkKK0FDX0NIRUNLX0xJQihbZXh0MmZzXSwgW2V4
dDJmc19vcGVuMl0sIFtsaWJleHQyZnM9InkiXSwgW2xpYmV4dDJmcz0ibiJdKQorQUNfU1VCU1Qo
bGliZXh0MmZzKQorQUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0s
IFtsaWJnY3J5cHQ9InkiXSwgW2xpYmdjcnlwdD0ibiJdKQorQUNfU1VCU1QobGliZ2NyeXB0KQor
QUNfQ0hFQ0tfTElCKFtwdGhyZWFkXSwgW3B0aHJlYWRfY3JlYXRlXSwgW10gLAorICAgIFtBQ19N
U0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnB0aHJlYWRdKV0pCitBQ19DSEVDS19MSUIoW3J0
XSwgW2Nsb2NrX2dldHRpbWVdKQorQUNfQ0hFQ0tfTElCKFt1dWlkXSwgW3V1aWRfY2xlYXJdLCBb
XSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJ1dWlkXSldKQorQUNfQ0hF
Q0tfTElCKFt5YWpsXSwgW3lhamxfYWxsb2NdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3Vs
ZCBub3QgZmluZCB5YWpsXSldKQorQUNfQ0hFQ0tfTElCKFt6XSwgW2RlZmxhdGVDb3B5XSwgW10s
IFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIHpsaWJdKV0pCitBQ19DSEVDS19MSUIoW2lj
b252XSwgW2xpYmljb252X29wZW5dLCBbbGliaWNvbnY9InkiXSwgW2xpYmljb252PSJuIl0pCitB
Q19TVUJTVChsaWJpY29udikKKworIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK0FDX0ZVTkNf
QUxMT0NBCitBQ19DSEVDS19IRUFERVJTKFsgXAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5o
IGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAg
ICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5o
IHN0cmluZy5oIFwKKyAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9j
dGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tl
dC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAg
ICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorICAgICAgICAgICAgICAg
IF0pCisKKyMgQ2hlY2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNo
YXJhY3RlcmlzdGljcy4KK0FDX0hFQURFUl9TVERCT09MCitBQ19UWVBFX1VJRF9UCitBQ19DX0lO
TElORQorQUNfVFlQRV9JTlQxNl9UCitBQ19UWVBFX0lOVDMyX1QKK0FDX1RZUEVfSU5UNjRfVAor
QUNfVFlQRV9JTlQ4X1QKK0FDX1RZUEVfTU9ERV9UCitBQ19UWVBFX09GRl9UCitBQ19UWVBFX1BJ
RF9UCitBQ19DX1JFU1RSSUNUCitBQ19UWVBFX1NJWkVfVAorQUNfVFlQRV9TU0laRV9UCitBQ19D
SEVDS19NRU1CRVJTKFtzdHJ1Y3Qgc3RhdC5zdF9ibGtzaXplXSkKK0FDX1NUUlVDVF9TVF9CTE9D
S1MKK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X3JkZXZdKQorQUNfVFlQRV9VSU5U
MTZfVAorQUNfVFlQRV9VSU5UMzJfVAorQUNfVFlQRV9VSU5UNjRfVAorQUNfVFlQRV9VSU5UOF9U
CitBQ19DSEVDS19UWVBFUyhbcHRyZGlmZl90XSkKKworIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVu
Y3Rpb25zLgorQUNfRlVOQ19FUlJPUl9BVF9MSU5FCitBQ19GVU5DX0ZPUksKK0FDX0ZVTkNfRlNF
RUtPCitBQ19GVU5DX0xTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCitBQ19IRUFERVJfTUFK
T1IKK0FDX0ZVTkNfTUFMTE9DCitBQ19GVU5DX01LVElNRQorQUNfRlVOQ19NTUFQCitBQ19GVU5D
X1JFQUxMT0MKK0FDX0ZVTkNfU1RSTkxFTgorQUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNT
KFsgXAorICAgICAgICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1
cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3Ri
eW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAg
ICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQg
bWtkaXIgXAorICAgICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGgg
cmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3Ry
Y2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAg
ICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3Ry
dG91bGwgdHpzZXQgXAorICAgICAgICAgICAgICAgIHVuYW1lIFwKKyAgICAgICAgICAgICAgICBd
KQorCitBQ19PVVRQVVQoKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgbTQv
ZGVmYXVsdF9saWIubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIvbTQvZGVmYXVsdF9saWIubTQJU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAw
CkBAIC0wLDAgKzEsNyBAQAorQUNfREVGVU4oW0FYX0RFRkFVTFRfTElCXSwKK1tBU19JRihbdGVz
dCAtZCAiJHByZWZpeC9saWI2NCJdLCBbCisgICAgTElCX1BBVEg9ImxpYjY0IgorXSxbCisgICAg
TElCX1BBVEg9ImxpYiIKK10pCitBQ19TVUJTVChMSUJfUEFUSCldKQpcIE5vIG5ld2xpbmUgYXQg
ZW5kIG9mIGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIG00L2Rpc2Fi
bGVfZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MAorKysgYi9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMTAgQEAKK0FDX0RFRlVOKFtBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JU
XSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZGlzYWJsZS0k
MV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAg
JDE9Im4iCitdLFsKKyAgICAkMT0ieSIKK10pCitBQ19TVUJTVCgkMSldKQpcIE5vIG5ld2xpbmUg
YXQgZW5kIG9mIGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIG00L2Vu
YWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL200L2VuYWJsZV9mZWF0dXJlLm00CVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiAr
MDEwMApAQCAtMCwwICsxLDEwIEBACitBQ19ERUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JU
XSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQx
XSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAg
JDE9InkiCitdLFsKKyAgICAkMT0ibiIKK10pCitBQ19TVUJTVCgkMSldKQpcIE5vIG5ld2xpbmUg
YXQgZW5kIG9mIGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIG00L29j
YW1sLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L200L29jYW1sLm00CVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApAQCAtMCwwICsxLDI0
MCBAQAorZG5sIGF1dG9jb25mIG1hY3JvcyBmb3IgT0NhbWwKK2RubAorZG5sIENvcHlyaWdodCDC
qSAyMDA5ICAgICAgUmljaGFyZCBXLk0uIEpvbmVzCitkbmwgQ29weXJpZ2h0IMKpIDIwMDkgICAg
ICBTdGVmYW5vIFphY2NoaXJvbGkKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IE9saXZpZXIg
QW5kcmlldQorZG5sIENvcHlyaWdodCDCqSAyMDAwLTIwMDUgSmVhbi1DaHJpc3RvcGhlIEZpbGxp
w6J0cmUKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IEdlb3JnZXMgTWFyaWFubworZG5sCitk
bmwgRm9yIGRvY3VtZW50YXRpb24sIHBsZWFzZSByZWFkIHRoZSBvY2FtbC5tNCBtYW4gcGFnZS4K
KworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2Ft
bGMKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxDXSxbb2NhbWxjXSxbbm9dKQorCisgIGlmIHRlc3Qg
IiRPQ0FNTEMiICE9ICJubyI7IHRoZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwg
c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCdgCisgICAgIEFDX01TR19SRVNV
TFQoW09DYW1sIHZlcnNpb24gaXMgJE9DQU1MVkVSU0lPTl0pCisgICAgICMgSWYgT0NBTUxMSUIg
aXMgc2V0LCB1c2UgaXQKKyAgICAgaWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0aGVuCisgICAg
ICAgIE9DQU1MTElCPWAkT0NBTUxDIC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRh
aWwgLTF8Y3V0IC1kICcgJyAtZiA0YAorICAgICBlbHNlCisgICAgICAgIEFDX01TR19SRVNVTFQo
W09DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0Ll0pCisgICAgIGZpCisgICAg
IEFDX01TR19SRVNVTFQoW09DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUJdKQorCisgICAg
IEFDX1NVQlNUKFtPQ0FNTFZFUlNJT05dKQorICAgICBBQ19TVUJTVChbT0NBTUxMSUJdKQorCisg
ICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MT1BU
XSxbb2NhbWxvcHRdLFtub10pCisgICAgIE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRP
Q0FNTE9QVCIgPSAibm8iOyB0aGVuCisJQUNfTVNHX1dBUk4oW0Nhbm5vdCBmaW5kIG9jYW1sb3B0
OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5Ll0pCisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAk
T0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJ
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgQUNf
TVNHX1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2Fy
ZGVkLl0pCisJICAgIE9DQU1MT1BUPW5vCisJZWxzZQorCSAgICBPQ0FNTEJFU1Q9b3B0CisJZmkK
KyAgICAgZmkKKworICAgICBBQ19TVUJTVChbT0NBTUxCRVNUXSkKKworICAgICAjIGNoZWNraW5n
IGZvciBvY2FtbGMub3B0CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MQ0RPVE9QVF0sW29jYW1s
Yy5vcHRdLFtub10pCisgICAgIGlmIHRlc3QgIiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4K
KwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiog
KlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lP
TiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2Ft
bGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLl0pCisJZWxzZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RP
VE9QVAorCWZpCisgICAgIGZpCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0Cisg
ICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgIT0gIm5vIiA7IHRoZW4KKwlBQ19DSEVDS19UT09MKFtP
Q0FNTE9QVERPVE9QVF0sW29jYW1sb3B0Lm9wdF0sW25vXSkKKwlpZiB0ZXN0ICIkT0NBTUxPUFRE
T1RPUFQiICE9ICJubyI7IHRoZW4KKwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRET1RPUFQgLXYg
fCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAgaWYgdGVzdCAi
JFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICBBQ19NU0dfUkVT
VUxUKFt2ZXJzaW9uIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQu
XSkKKwkgICBlbHNlCisJICAgICAgT0NBTUxPUFQ9JE9DQU1MT1BURE9UT1BUCisJICAgZmkKKyAg
ICAgICAgZmkKKyAgICAgZmkKKworICAgICBBQ19TVUJTVChbT0NBTUxPUFRdKQorICBmaQorCisg
IEFDX1NVQlNUKFtPQ0FNTENdKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sIHRvcGxldmVsCisg
IEFDX0NIRUNLX1RPT0woW09DQU1MXSxbb2NhbWxdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Ig
b2NhbWxkZXAKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxERVBdLFtvY2FtbGRlcF0sW25vXSkKKwor
ICAjIGNoZWNraW5nIGZvciBvY2FtbG1rdG9wCisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtUT1Bd
LFtvY2FtbG1rdG9wXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgQUNf
Q0hFQ0tfVE9PTChbT0NBTUxNS0xJQl0sW29jYW1sbWtsaWJdLFtub10pCisKKyAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxkb2MKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxET0NdLFtvY2FtbGRvY10sW25v
XSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIEFDX0NIRUNLX1RPT0woW09DQU1M
QlVJTERdLFtvY2FtbGJ1aWxkXSxbbm9dKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19PQ0FN
TExFWF0sCitbZG5sCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbGV4CisgIEFDX0NIRUNLX1RPT0wo
W09DQU1MTEVYXSxbb2NhbWxsZXhdLFtub10pCisgIGlmIHRlc3QgIiRPQ0FNTExFWCIgIT0gIm5v
IjsgdGhlbgorICAgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVYRE9UT1BUXSxbb2NhbWxsZXgub3B0
XSxbbm9dKQorICAgIGlmIHRlc3QgIiRPQ0FNTExFWERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCU9D
QU1MTEVYPSRPQ0FNTExFWERPVE9QVAorICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtPQ0FNTExF
WF0pCitdKQorCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTFlBQ0NdLAorW2RubAorICBBQ19DSEVD
S19UT09MKFtPQ0FNTFlBQ0NdLFtvY2FtbHlhY2NdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTFlB
Q0NdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19DQU1MUDRdLAorW2RubAorICBBQ19SRVFV
SVJFKFtBQ19QUk9HX09DQU1MXSlkbmwKKworICAjIGNoZWNraW5nIGZvciBjYW1scDQKKyAgQUNf
Q0hFQ0tfVE9PTChbQ0FNTFA0XSxbY2FtbHA0XSxbbm9dKQorICBpZiB0ZXN0ICIkQ0FNTFA0IiAh
PSAibm8iOyB0aGVuCisgICAgIFRNUFZFUlNJT049YCRDQU1MUDQgLXYgMj4mMXwgc2VkIC1uIC1l
ICdzfC4qdmVyc2lvbiAqXCguKlwpJHxcMXxwJ2AKKyAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04i
ICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwlBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZm
ZXJzIGZyb20gb2NhbWxjXSkKKyAgICAgICAgQ0FNTFA0PW5vCisgICAgIGZpCisgIGZpCisgIEFD
X1NVQlNUKFtDQU1MUDRdKQorCisgICMgY2hlY2tpbmcgZm9yIGNvbXBhbmlvbiB0b29scworICBB
Q19DSEVDS19UT09MKFtDQU1MUDRCT09UXSxbY2FtbHA0Ym9vdF0sW25vXSkKKyAgQUNfQ0hFQ0tf
VE9PTChbQ0FNTFA0T10sW2NhbWxwNG9dLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9G
XSxbY2FtbHA0b2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9PRl0sW2NhbWxwNG9v
Zl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T1JGXSxbY2FtbHA0b3JmXSxbbm9dKQor
ICBBQ19DSEVDS19UT09MKFtDQU1MUDRQUk9GXSxbY2FtbHA0cHJvZl0sW25vXSkKKyAgQUNfQ0hF
Q0tfVE9PTChbQ0FNTFA0Ul0sW2NhbWxwNHJdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQ
NFJGXSxbY2FtbHA0cmZdLFtub10pCisgIEFDX1NVQlNUKFtDQU1MUDRCT09UXSkKKyAgQUNfU1VC
U1QoW0NBTUxQNE9dKQorICBBQ19TVUJTVChbQ0FNTFA0T0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0
T09GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9SRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRQUk9GXSkK
KyAgQUNfU1VCU1QoW0NBTUxQNFJdKQorICBBQ19TVUJTVChbQ0FNTFA0UkZdKQorXSkKKworCitB
Q19ERUZVTihbQUNfUFJPR19GSU5ETElCXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19P
Q0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxmaW5kCisgIEFDX0NIRUNLX1RPT0wo
W09DQU1MRklORF0sW29jYW1sZmluZF0sW25vXSkKKyAgQUNfU1VCU1QoW09DQU1MRklORF0pCitd
KQorCisKK2RubCBUaGFua3MgdG8gSmltIE1leWVyaW5nIGZvciB3b3JraW5nIHRoaXMgbmV4dCBi
aXQgb3V0IGZvciB1cy4KK2RubCBYWFggV2Ugc2hvdWxkIGRlZmluZSBBU19UUl9TSCBpZiBpdCdz
IG5vdCBkZWZpbmVkIGFscmVhZHkKK2RubCAoZWcuIGZvciBvbGQgYXV0b2NvbmYpLgorQUNfREVG
VU4oW0FDX0NIRUNLX09DQU1MX1BLR10sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfRklO
RExJQl0pZG5sCisKKyAgQUNfTVNHX0NIRUNLSU5HKFtmb3IgT0NhbWwgZmluZGxpYiBwYWNrYWdl
ICQxXSkKKworICB1bnNldCBmb3VuZAorICB1bnNldCBwa2cKKyAgZm91bmQ9bm8KKyAgZm9yIHBr
ZyBpbiAkMSAkMiA7IGRvCisgICAgaWYgJE9DQU1MRklORCBxdWVyeSAkcGtnID4vZGV2L251bGwg
Mj4vZGV2L251bGw7IHRoZW4KKyAgICAgIEFDX01TR19SRVNVTFQoW2ZvdW5kXSkKKyAgICAgIEFT
X1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT0kcGtnCisgICAgICBmb3VuZD15ZXMKKyAgICAgIGJyZWFr
CisgICAgZmkKKyAgZG9uZQorICBpZiB0ZXN0ICIkZm91bmQiID0gIm5vIiA7IHRoZW4KKyAgICBB
Q19NU0dfUkVTVUxUKFtub3QgZm91bmRdKQorICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT1u
bworICBmaQorCisgIEFDX1NVQlNUKEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKSkKK10pCisKKwor
QUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX01PRFVMRV0sCitbZG5sCisgIEFDX01TR19DSEVDS0lO
RyhbZm9yIE9DYW1sIG1vZHVsZSAkMl0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKK29w
ZW4gJDMKK0VPRgorICB1bnNldCBmb3VuZAorICBmb3IgJDEgaW4gJCQxICQ0IDsgZG8KKyAgICBp
ZiAkT0NBTUxDIC1jIC1JICIkJDEiIGNvbmZ0ZXN0Lm1sID4mNSAyPiY1IDsgdGhlbgorICAgICAg
Zm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRvbmUKKworICBpZiB0ZXN0ICIkZm91
bmQiIDsgdGhlbgorICAgIEFDX01TR19SRVNVTFQoWyQkMV0pCisgIGVsc2UKKyAgICBBQ19NU0df
UkVTVUxUKFtub3QgZm91bmRdKQorICAgICQxPW5vCisgIGZpCisgIEFDX1NVQlNUKFskMV0pCitd
KQorCisKK2RubCBYWFggQ3Jvc3MtY29tcGlsaW5nCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxf
V09SRF9TSVpFXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisgIEFD
X01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGNvbXBpbGVyIHdvcmQgc2l6ZV0pCisgIGNhdCA+IGNv
bmZ0ZXN0Lm1sIDw8RU9GCisgIHByaW50X2VuZGxpbmUgKHN0cmluZ19vZl9pbnQgU3lzLndvcmRf
c2l6ZSkKKyAgRU9GCisgIE9DQU1MX1dPUkRfU0laRT1gJE9DQU1MIGNvbmZ0ZXN0Lm1sYAorICBB
Q19NU0dfUkVTVUxUKFskT0NBTUxfV09SRF9TSVpFXSkKKyAgQUNfU1VCU1QoW09DQU1MX1dPUkRf
U0laRV0pCitdKQorCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfT1NfVFlQRV0sCitbZG5sCisg
IEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW09DYW1s
IFN5cy5vc190eXBlXSkKKworICBjYXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9zdHJp
bmcoU3lzLm9zX3R5cGUpOzsKK0VPRgorCisgIE9DQU1MX09TX1RZUEU9YCRPQ0FNTCBjb25mdGVz
dC5tbGAKKyAgQUNfTVNHX1JFU1VMVChbJE9DQU1MX09TX1RZUEVdKQorICBBQ19TVUJTVChbT0NB
TUxfT1NfVFlQRV0pCitdKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgbTQv
cGF0aF9vcl9mYWlsLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL200L3BhdGhfb3JfZmFpbC5tNAlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAx
MDAKQEAgLTAsMCArMSw2IEBACitBQ19ERUZVTihbQVhfUEFUSF9QUk9HX09SX0ZBSUxdLAorW0FD
X1BBVEhfUFJPRyhbJDFdLCBbJDJdLCBbbm9dKQoraWYgdGVzdCB4IiR7JDF9IiA9PSB4Im5vIiAK
K3RoZW4KKyAgICBBQ19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kICQyLCBwbGVhc2UgaW5zdGFs
bCAkMl0pCitmaV0pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBtNC9weXRo
b25fZGV2ZWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
KysrIGIvbTQvcHl0aG9uX2RldmVsLm00CVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMApA
QCAtMCwwICsxLDE4IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVMXSwKK1tBQ19N
U0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQg
b3MucGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhw
ICsgIi9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEp
CisnID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBB
Q19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2ZWwgcGFja2Fn
ZSBub3QgZm91bmRdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBtNC9weXRob25fdmVyc2lvbi5tNAotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9tNC9weXRob25f
dmVyc2lvbi5tNAlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMiBA
QAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9OXSwKK1tBQ19NU0dfQ0hFQ0tJTkco
W2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQWVRIT04gLWMgJ2ltcG9ydCBzeXM7
IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwgJDIpIikpJ2AKK2lmIHRlc3QgIiQ/
IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1gJFBZVEhPTiAtViAyPiYxYAorICAg
IEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoCisgICAgICAgIFskcHl0aG9u
X3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJlZCB2ZXJzaW9uIGlzICQxLiQyXSkK
K2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmldKQpkaWZmIC1yIDQwODZlNDgxMTU0
NyAtciBlMTJlYzEwNzE0MTAgbTQvcHl0aG9uX3htbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9tNC9weXRob25feG1sLm00CVNhdCBKYW4gMDcg
MDQ6MTc6MTAgMjAxMiArMDEwMApAQCAtMCwwICsxLDEwIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tf
UFlUSE9OX1hNTF0sCitbQUNfTVNHX0NIRUNLSU5HKFtmb3IgcHl0aG9uIHhtbC5kb20ubWluaWRv
bV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0IHhtbC5kb20ubWluaWRvbSdgCitpZiB0ZXN0ICIkPyIg
IT0gIjAiCit0aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUihb
VW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1vZHVsZV0pCitlbHNlCisgICAgQUNfTVNH
X1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEw
IG00L3NldF9jZmxhZ3NfbGRmbGFncy5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi9tNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQJU2F0IEphbiAwNyAw
NDoxNzoxMCAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTkgQEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxB
R1NdLAorW2ZvciBjZmxhZyBpbiAkUFJFUEVORF9JTkNMVURFUworZG8KKyAgICBQUkVQRU5EX0NG
TEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCitkbwor
ICAgIFBSRVBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitmb3IgY2ZsYWcgaW4gJEFQ
UEVORF9JTkNMVURFUworZG8KKyAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQor
Zm9yIGxkZmxhZyBpbiAkQVBQRU5EX0xJQgorZG8KKyAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRs
ZGZsYWciCitkb25lCitDRkxBR1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZM
QUdTIgorTERGTEFHUz0iJFBSRVBFTkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1Mi
XSkKXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUx
MmVjMTA3MTQxMCBtNC91ZGV2Lm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL200L3VkZXYubTQJU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAw
CkBAIC0wLDAgKzEsMzIgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19VREVWXSwKK1tpZiB0ZXN0ICIk
aG9zdF9vcyIgPT0gImxpbnV4LWdudSIKK3RoZW4KKyAgICBBQ19QQVRIX1BST0coW1VERVZBRE1d
LCBbdWRldmFkbV0sIFtub10pCisgICAgaWYgdGVzdCB4IiR7VURFVkFETX0iID09IHgibm8iIAor
ICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtVREVWSU5GT10sIFt1ZGV2aW5mb10sIFtu
b10pCisgICAgICAgIGlmIHRlc3QgeCIke1VERVZJTkZPfSIgPT0geCJubyIKKyAgICAgICAgdGhl
bgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKAorICAgICAgICAgICAgICAgIFtVbmFibGUgdG8g
ZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2XSkKKyAgICAgICAg
ZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVWSU5GT30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AK
KyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9YCR7VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3By
aW50ICRORn0nYAorICAgIGZpCisgICAgaWYgdGVzdCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRo
ZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtIT1RQTFVHXSwgW2hvdHBsdWddLCBbbm9dKQorICAg
ICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAg
ICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlzIHRvbyBvbGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1
OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisgICAgZmkKK2Vsc2UKKyAgICBBQ19QQVRIX1BST0co
W1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25vXSkKKyAgICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30i
ID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBBQ19NU0dfRVJST1IoW05vdCBhIExpbnV4IHN5
c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5kXSkKKyAgICBmaQorZmkKK10pCmRpZmYgLXIgNDA4
NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29scy9NYWtlZmlsZQotLS0gYS90b29scy9NYWtl
ZmlsZQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvTWFrZWZpbGUJ
U2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCkBAIC02LDcgKzYsNiBAQCBTVUJESVJTLWxp
YmFpbyA6PSBsaWJhaW8KIGVuZGlmCiAKIFNVQkRJUlMteSA6PQotU1VCRElSUy15ICs9IGNoZWNr
CiBTVUJESVJTLXkgKz0gaW5jbHVkZQogU1VCRElSUy15ICs9IGxpYnhjCiBTVUJESVJTLXkgKz0g
Zmxhc2sKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL2Jsa3RhcC9k
cml2ZXJzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVRodSBK
YW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi90b29scy9ibGt0YXAvZHJpdmVycy9NYWtl
ZmlsZQlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKQEAgLTEzLDcgKzEzLDcgQEAgQ0ZM
QUdTICAgKz0gJChDRkxBR1NfbGlieGVuc3RvcmUpCiBDRkxBR1MgICArPSAtSSAkKE1FTVNIUl9E
SVIpCiBDRkxBR1MgICArPSAtRF9HTlVfU09VUkNFCiAKLWlmZXEgKCQoc2hlbGwgLiAuL2NoZWNr
X2djcnlwdCAkKENDKSkseWVzKQoraWZlcSAoJENPTkZJR19HQ1JZUFQseSkKIENGTEFHUyArPSAt
RFVTRV9HQ1JZUFQKIENSWVBUX0xJQiA6PSAtbGdjcnlwdAogZWxzZQpkaWZmIC1yIDQwODZlNDgx
MTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvYmxrdGFwL2RyaXZlcnMvY2hlY2tfZ2NyeXB0Ci0t
LSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAlUaHUgSmFuIDA1IDE3OjI1OjIz
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0KLWNhdCA+IC5nY3J5cHQuYyA8PCBFT0YKLSNp
bmNsdWRlIDxnY3J5cHQuaD4KLWludCBtYWluKHZvaWQpIHsgcmV0dXJuIDA7IH0KLUVPRgotCi1p
ZiAkMSAtbyAuZ2NyeXB0IC5nY3J5cHQuYyAtbGdjcnlwdCAyPi9kZXYvbnVsbCA7IHRoZW4KLSAg
ZWNobyAieWVzIgotZWxzZQotICBlY2hvICJubyIKLWZpCi0KLXJtIC1mIC5nY3J5cHQqCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29scy9jaGVjay9NYWtlZmlsZQotLS0g
YS90b29scy9jaGVjay9NYWtlZmlsZQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjYgKzAsMCBA
QAotWEVOX1JPT1QgPSAkKENVUkRJUikvLi4vLi4KLWluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMv
UnVsZXMubWsKLQotIyBFeHBvcnQgdGhlIG5lY2Vzc2FyeSBlbnZpcm9ubWVudCB2YXJpYWJsZXMg
Zm9yIHRoZSB0ZXN0cwotZXhwb3J0IFBZVEhPTgotZXhwb3J0IExJQlhFTkFQSV9CSU5ESU5HUwot
ZXhwb3J0IENIRUNLX0lOQ0xVREVTCi1leHBvcnQgQ0hFQ0tfTElCCi1leHBvcnQgQ09ORklHX1NZ
U1RFTV9MSUJBSU8KLQotLlBIT05ZOiBhbGwgaW5zdGFsbAotYWxsIGluc3RhbGw6IGNoZWNrLWJ1
aWxkCi0KLSMgQ2hlY2sgdGhpcyBtYWNoaW5lIGlzIE9LIGZvciBidWlsZGluZyBvbi4KLS5QSE9O
WTogY2hlY2stYnVpbGQKLWNoZWNrLWJ1aWxkOgotCS4vY2hrIGJ1aWxkCi0KLSMgQ2hlY2sgdGhp
cyBtYWNoaW5lIGlzIE9LIGZvciBpbnN0YWxsaW5nIG9uLgotLlBIT05ZOiBjaGVjay1pbnN0YWxs
Ci1jaGVjay1pbnN0YWxsOgotCS4vY2hrIGluc3RhbGwKLQotLlBIT05ZOiBjbGVhbgotY2xlYW46
Ci0JLi9jaGsgY2xlYW4KZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xz
L2NoZWNrL1JFQURNRQotLS0gYS90b29scy9jaGVjay9SRUFETUUJVGh1IEphbiAwNSAxNzoyNToy
MyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDIwICswLDAgQEAKLUNoZWNrcyBmb3IgdGhlIHN1aXRhYmlsaXR5IG9mIGEgbWFjaGlu
ZSBmb3IgWGVuIGJ1aWxkIG9yIGluc3RhbGwuCi1UbyBjaGVjayBmb3IgYnVpbGQgc3VpdGFiaWxp
dHkgdXNlCi0KLSAgICAgICAgLi9jaGsgYnVpbGQKLQotVG8gY2hlY2sgZm9yIGluc3RhbGwgc3Vp
dGFiaWxpdHkgdXNlCi0KLSAgICAgICAgLi9jaGsgaW5zdGFsbAotCi1UaGUgY2hrIHNjcmlwdCB3
aWxsIHJ1biBjaGVja3MgaW4gdGhpcyBkaXJlY3RvcnkgYW5kIHByaW50Ci10aGUgb25lcyB0aGF0
IGZhaWxlZC4gSXQgcHJpbnRzIG5vdGhpbmcgaWYgY2hlY2tzIHN1Y2NlZWQuCi1UaGUgY2hrIHNj
cmlwdCBleGl0cyB3aXRoIDAgb24gc3VjY2VzcyBhbmQgMSBvbiBmYWlsdXJlLgotCi1UaGUgY2hr
IHNjcmlwdCBydW5zIGV4ZWN1dGFibGUgZmlsZXMgaW4gdGhpcyBkaXJlY3Rvcnkgd2hvc2UKLW5h
bWVzIGJlZ2luIHdpdGggJ2NoZWNrXycuIEZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0stQlVJTEQKLWFy
ZSBydW4gZm9yIHRoZSBidWlsZCBjaGVjaywgYW5kIGZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0stSU5T
VEFMTAotYXJlIHJ1biBmb3IgdGhlIGluc3RhbGwgY2hlY2suCi0KLURldGFpbGVkIG91dHB1dCBm
cm9tIHRoZSBjaGVjayBzY3JpcHRzIGlzIGluIC5jaGtidWlsZCBmb3IgYnVpbGQKLWFuZCAuY2hr
aW5zdGFsbCBmb3IgaW5zdGFsbC4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLXIg
NDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29scy9jaGVjay9jaGVja19icmN0bAotLS0g
YS90b29scy9jaGVjay9jaGVja19icmN0bAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAK
KysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2Ug
JE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhhc19vcl9mYWlsIGJyY29uZmlnIDs7
Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBicmN0bCA7OwotKikKLQlmYWlsICJ1bmtub3duIE9TIiA7
OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2sv
Y2hlY2tfY3J5cHRvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19jcnlwdG9fbGliCVRodSBK
YW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQg
Q0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0
QlNEfE9wZW5CU0QpCi0JZXhpdCAwIDs7Ci1lc2FjCi0KLWhhc19saWIgbGliY3J5cHRvLnNvIHx8
IGZhaWwgIm1pc3NpbmcgbGliY3J5cHRvLnNvIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJl
YzEwNzE0MTAgdG9vbHMvY2hlY2svY2hlY2tfY3VybAotLS0gYS90b29scy9jaGVjay9jaGVja19j
dXJsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyAiJExJQlhFTkFQ
SV9CSU5ESU5HUyIgIT0gInkiIF07IHRoZW4KLQllY2hvIC1uICJ1bnVzZWQsICIKLQlleGl0IDAK
LWZpCi0KLWhhc19vcl9mYWlsIGN1cmwtY29uZmlnCi1jdXJsX2xpYnM9YGN1cmwtY29uZmlnIC0t
bGlic2AgfHwgZmFpbCAiY3VybC1jb25maWcgLS1saWJzIGZhaWxlZCIKLXRlc3RfbGluayAkY3Vy
bF9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZvciBjdXJsIGFyZSBtaXNzaW5n
IgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2svY2hlY2tf
aXByb3V0ZQotLS0gYS90b29scy9jaGVjay9jaGVja19pcHJvdXRlCVRodSBKYW4gMDUgMTc6MjU6
MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSwxNSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVu
Y3Muc2gKLQotUEFUSD0vc2JpbjokUEFUSAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8
RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBpZmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwg
aXAgOzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19kZXZlbAotLS0gYS90
b29scy9jaGVjay9jaGVja19saWJhaW9fZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEx
ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYg
WyBYJHtDT05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQgMAot
ZmkKLWlmICEgaGFzX2hlYWRlciBsaWJhaW8uaCA7IHRoZW4KLSAgICBmYWlsICJjYW4ndCBmaW5k
IGxpYmFpbyBoZWFkZXJzLCBpbnN0YWxsIGxpYmFpbyBkZXZlbCBwYWNrYWdlIG9yIHNldCBDT05G
SUdfU1lTVEVNX0xJQkFJTz1uIgotZmkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcx
NDEwIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tf
bGliYWlvX2xpYglUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0jIS9iaW4vc2gK
LSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyBYJHtD
T05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQgMAotZmkKLWhh
c19saWIgbGliYWlvLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGliYWlvIgpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNzbF9kZXZlbAot
LS0gYS90b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gK
LQotaGFzX2hlYWRlciBvcGVuc3NsL21kNS5oIHx8IGZhaWwgIm1pc3Npbmcgb3BlbnNzbCBoZWFk
ZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2svY2hl
Y2tfcHl0aG9uCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbglUaHUgSmFuIDA1IDE3OjI1
OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RB
TEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhP
Tj1weXRob24KLWZpCi0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgc3lzCi1zeXMuZXhpdChzeXMu
dmVyc2lvbl9pbmZvWzBdIDwgMiBvciBzeXMudmVyc2lvbl9pbmZvWzFdIDwgMykKLScgfHwgZmFp
bCAibmVlZCBweXRob24gdmVyc2lvbiA+PSAyLjMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUx
MmVjMTA3MTQxMCB0b29scy9jaGVjay9jaGVja19weXRob25fZGV2ZWwKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfcHl0aG9uX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNyArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXog
JHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZpCi1oYXNfb3JfZmFpbCAke1BZVEhP
Tn0KLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBvcy5wYXRoLCBzeXMKLWZvciBwIGluIHN5cy5w
YXRoOgotCWlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIpOgotCQlzeXMu
ZXhpdCgwKQotc3lzLmV4aXQoMSkKLScgfHwgZmFpbCAiY2FuJ3QgZmluZCBweXRob24gZGV2ZWwg
ZmlsZXMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29scy9jaGVjay9j
aGVja19weXRob25feG1sCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl94bWwJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxM
Ci0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049
cHl0aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnaW1wb3J0
IHhtbC5kb20ubWluaWRvbScgMj4vZGV2L251bGwgfHwgXAotZmFpbCAiY2FuJ3QgaW1wb3J0IHht
bC5kb20ubWluaWRvbSIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xz
L2NoZWNrL2NoZWNrX3VkZXYKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdWRldglUaHUgSmFuIDA1
IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsMjIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQot
LiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhh
c19vcl9mYWlsIHZuY29uZmlnCi0JOzsKLUxpbnV4KQotCWhhcyAvc2Jpbi91ZGV2YWRtICYmIFwK
LQkJdWRldnZlcj1gL3NiaW4vdWRldmFkbSBpbmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCi0J
WyAteiAiJHVkZXZ2ZXIiIF0gJiYgaGFzX29yX2ZhaWwgdWRldmluZm8gJiYgXAotCQl1ZGV2dmVy
PWB1ZGV2aW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgIiR1ZGV2dmVyIiAtZ2UgNTkg
XSAyPi9kZXYvbnVsbCB8fCBcCi0JCWhhcyBob3RwbHVnIHx8IFwKLQkJZmFpbCAidWRldiBpcyB0
b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3IgbGF0ZXIiCi0JOzsKLSopCi0JZmFpbCAi
dW5rbm93biBPUyIKLQk7OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0
MTAgdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja191
dWlkX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw3ICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB1dWlkLmggfHwgXAot
aGFzX2hlYWRlciB1dWlkL3V1aWQuaCB8fCBmYWlsICJtaXNzaW5nIHV1aWQgaGVhZGVycyAocGFj
a2FnZSB1dWlkLWRldikiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCB0b29s
cy9jaGVjay9jaGVja194MTFfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVs
CVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1C
VUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciBYMTEva2V5c3ltZGVmLmggfHwgXAot
aGFzX2hlYWRlciAvdXNyL1gxMVI2L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLWhhc19o
ZWFkZXIgL3Vzci9YMTFSNy9pbmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8fCBcCi13YXJuaW5nICJj
YW4ndCBmaW5kIFgxMSBoZWFkZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0
MTAgdG9vbHMvY2hlY2svY2hlY2tfeGdldHRleHQKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeGdl
dHRleHQJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3NoCi0jIENI
RUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfb3JfZmFpbCB4Z2V0dGV4dApkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvY2hlY2svY2hlY2tfeG1sMgotLS0g
YS90b29scy9jaGVjay9jaGVja194bWwyCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAor
KysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNCArMCww
IEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Mu
c2gKLQotaWYgWyAhICIkTElCWEVOQVBJX0JJTkRJTkdTIiA9ICJ5IiBdCi10aGVuCi0gICAgZWNo
byAtbiAidW51c2VkLCAiCi0gICAgZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCB4bWwyLWNvbmZp
ZwoteG1sMl9saWJzPWB4bWwyLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgInhtbDItY29uZmlnIC0t
bGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJHhtbDJfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxp
YnJhcmllcyBmb3IgeG1sMiBhcmUgbWlzc2luZyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEy
ZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2sv
Y2hlY2tfeWFqbF9kZXZlbAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOCArMCwwIEBACi0jIS9i
aW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgeWFqbC95
YWpsX3BhcnNlLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfcGFyc2UuaCIKLWhhc19o
ZWFkZXIgeWFqbC95YWpsX2dlbi5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95YWpsX2dlbi5o
IgotaGFzX2xpYiBsaWJ5YWpsLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFqbC5zbyIKZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxf
bGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfbGliCVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfbGliIGxpYnlhamwuc28uMSB8fCBmYWlsICJjYW4ndCBmaW5k
IGxpYnlhamwuc28uMSB2ZXJzaW9uIDEiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3
MTQxMCB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3psaWJfZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBm
YWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEy
ZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX3psaWJfbGliCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAk
T1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFz
X2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJ
VGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3Vz
YWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFs
bHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4g
YnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90
LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5l
cmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2Jp
bgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIg
XTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBj
aGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hl
Y2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQg
MAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVz
YWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBj
aGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29u
dGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVz
YWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQot
ICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0g
ICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRo
ZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQot
ZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0
MTAgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGlj
aCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAt
eiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVy
biAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0
byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBp
biAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0J
CQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUK
LQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVs
bCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5
c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBb
IC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAw
Ci0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAi
JENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQot
CQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVj
a19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlv
biBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAj
IGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhp
cyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0
Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3Jr
LgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNv
LmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JP
U1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91
Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9
ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JP
U1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIk
e09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZx
ICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkg
ewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1w
ZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1g
bWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+
JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5
IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiBy
ZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVh
c2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlm
aQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1y
b290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJu
aW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAk
Kn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZB
SUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMx
MDcxNDEwIHRvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2RlYnVn
Z2VyL2dkYnN4L3hnL01ha2VmaWxlCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysg
Yi90b29scy9kZWJ1Z2dlci9nZGJzeC94Zy9NYWtlZmlsZQlTYXQgSmFuIDA3IDA0OjE3OjEwIDIw
MTIgKzAxMDAKQEAgLTIxLDcgKzIxLDYgQEAgeGdfYWxsLmE6ICQoWEdfT0JKUykgTWFrZWZpbGUg
JChYR19IRFJTKQogIwkkKENDKSAtbTMyIC1jIC1vICRAICReCiAKIHhlbi1oZWFkZXJzOgotCSQo
TUFLRSkgLUMgLi4vLi4vLi4vY2hlY2sgCiAJJChNQUtFKSAtQyAuLi8uLi8uLi9pbmNsdWRlCiAK
ICMgeGdfbWFpbi5vOiB4Z19tYWluLmMgTWFrZWZpbGUgJChYR19IRFJTKQpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQotLS0gYS90
b29scy9saWJmc2ltYWdlL01ha2VmaWxlCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAor
KysgYi90b29scy9saWJmc2ltYWdlL01ha2VmaWxlCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiAr
MDEwMApAQCAtMiw3ICsyLDExIEBAIFhFTl9ST09UID0gJChDVVJESVIpLy4uLy4uCiBpbmNsdWRl
ICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCiAKIFNVQkRJUlMteSA9IGNvbW1vbiB1ZnMgcmVp
c2VyZnMgaXNvOTY2MCBmYXQgemZzIHhmcwotU1VCRElSUy15ICs9ICQoc2hlbGwgZW52IENDPSIk
KENDKSIgLi9jaGVjay1saWJleHQyZnMpCitpZmVxICgkKENPTkZJR19FWFQyRlMpLCB5KQorICAg
IFNVQkRJUlMteSArPSBleHQyZnMtbGliCitlbHNlCisgICAgU1VCRElSUy15ICs9IGV4dDJmcwor
ZW5kaWYKIAogLlBIT05ZOiBhbGwgY2xlYW4gaW5zdGFsbAogYWxsIGNsZWFuIGluc3RhbGw6ICU6
IHN1YmRpcnMtJQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgdG9vbHMvbGli
ZnNpbWFnZS9jaGVjay1saWJleHQyZnMKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9jaGVjay1saWJl
eHQyZnMJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDIxICswLDAgQEAKLSMhL2Jpbi9zaAotCi1j
YXQgPmV4dDItdGVzdC5jIDw8RU9GCi0jaW5jbHVkZSA8ZXh0MmZzL2V4dDJmcy5oPgotCi1pbnQg
bWFpbigpCi17Ci0JZXh0MmZzX29wZW4yOwotfQotRU9GCi0KLSR7Q0MtZ2NjfSAtbyBleHQyLXRl
c3QgZXh0Mi10ZXN0LmMgLWxleHQyZnMgPi9kZXYvbnVsbCAyPiYxCi1pZiBbICQ/ID0gMCBdOyB0
aGVuCi0JZWNobyBleHQyZnMtbGliCi1lbHNlCi0JZWNobyBleHQyZnMKLWZpCi0KLXJtIC1mIGV4
dDItdGVzdCBleHQyLXRlc3QuYwotCi1leGl0IDAKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEy
ZWMxMDcxNDEwIHRvb2xzL2xpYnhlbi9NYWtlZmlsZQotLS0gYS90b29scy9saWJ4ZW4vTWFrZWZp
bGUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYnhlbi9NYWtl
ZmlsZQlTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKQEAgLTIyLDEyICsyMiwxMiBAQCBN
QUpPUiA9IDEuMAogTUlOT1IgPSAwCiAKIENGTEFHUyArPSAtSWluY2x1ZGUgICAgICAgICAgICAg
ICAgICAgICBcCi0gICAgICAgICAgJChzaGVsbCB4bWwyLWNvbmZpZyAtLWNmbGFncykgXAotICAg
ICAgICAgICQoc2hlbGwgY3VybC1jb25maWcgLS1jZmxhZ3MpIFwKKyAgICAgICAgICAkKHNoZWxs
ICQoWE1MMi1DT05GSUcpIC0tY2ZsYWdzKSBcCisgICAgICAgICAgJChzaGVsbCAkKENVUkwtQ09O
RklHKSAtLWNmbGFncykgXAogICAgICAgICAgIC1mUElDCiAKLUxERkxBR1MgKz0gJChzaGVsbCB4
bWwyLWNvbmZpZyAtLWxpYnMpIFwKLSAgICAgICAgICAgJChzaGVsbCBjdXJsLWNvbmZpZyAtLWxp
YnMpCitMREZMQUdTICs9ICQoc2hlbGwgJChYTUwyLUNPTkZJRykgLS1saWJzKSBcCisgICAgICAg
ICAgICQoc2hlbGwgJChDVVJMLUNPTkZJRykgLS1saWJzKQogCiBMSUJYRU5BUElfSERSUyA9ICQo
d2lsZGNhcmQgaW5jbHVkZS94ZW4vYXBpLyouaCkgaW5jbHVkZS94ZW4vYXBpL3hlbl9hbGwuaAog
TElCWEVOQVBJX09CSlMgPSAkKHBhdHN1YnN0ICUuYywgJS5vLCAkKHdpbGRjYXJkIHNyYy8qLmMp
KQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 08 12:04:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 12:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjrTN-0001k6-DB; Sun, 08 Jan 2012 12:03:37 +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 1RjrTM-0001jy-GV
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 12:03:36 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326024165!51637536!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIyMTQ0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5671 invoked from network); 8 Jan 2012 12:02:45 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-27.messagelabs.com with SMTP;
	8 Jan 2012 12:02:45 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 08 Jan 2012 04:03:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="93587067"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by azsmga001.ch.intel.com with ESMTP; 08 Jan 2012 04:03:32 -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; Sun, 8 Jan 2012 20:03:31 +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; Sun, 8 Jan 2012 20:03:30 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.16]) with mapi id
	14.01.0355.002; Sun, 8 Jan 2012 20:03:30 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Thread-Topic: [PATCH] xen/sched_credit: Use delay to control scheduling
	frequency
Thread-Index: AQHMw+UZfvXlFfj3x0u7hY1iQlJRmJX/TMQAgAMk4+A=
Date: Sun, 8 Jan 2012 12:03:29 +0000
Message-ID: <E3E4738020A00E46AC373AD41F7FEAD50128C2@SHSMSX101.ccr.corp.intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
	<4F075204.3040408@eu.citrix.com>
In-Reply-To: <4F075204.3040408@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"raistlin@linux.it" <raistlin@linux.it>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <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

Thanks, George.
Should I send a revised version?
Can it be checked in?

-----Original Message-----
From: George Dunlap [mailto:george.dunlap@eu.citrix.com] 
Sent: Saturday, January 07, 2012 3:57 AM
To: Lv, Hui
Cc: xen-devel@lists.xensource.com; raistlin@linux.it; JBeulich@suse.com; Ian Campbell
Subject: Re: [PATCH] xen/sched_credit: Use delay to control scheduling frequency

Sorry for the delay; just catching up after the Christmas holidays.

On 26/12/11 03:46, Hui Lv wrote:
> @@ -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")
The standard idiom for this kind of message would be:
  WARNING [what's wrong]
  [What you're doing about it]

So the last sentence of the warning should be:
   Setting ratelimit_us to 1000 * tslice_ms

(Grammatically, you could say "Forcing ratelimit..." but I think "force" 
is too strong in this case.)

Other than that, I'm happy with it, if everyone else is:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 08 12:04:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 08 Jan 2012 12:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RjrTN-0001k6-DB; Sun, 08 Jan 2012 12:03:37 +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 1RjrTM-0001jy-GV
	for xen-devel@lists.xensource.com; Sun, 08 Jan 2012 12:03:36 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326024165!51637536!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIyMTQ0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5671 invoked from network); 8 Jan 2012 12:02:45 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-3.tower-27.messagelabs.com with SMTP;
	8 Jan 2012 12:02:45 -0000
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga102.ch.intel.com with ESMTP; 08 Jan 2012 04:03:33 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="93587067"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by azsmga001.ch.intel.com with ESMTP; 08 Jan 2012 04:03:32 -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; Sun, 8 Jan 2012 20:03:31 +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; Sun, 8 Jan 2012 20:03:30 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.16]) with mapi id
	14.01.0355.002; Sun, 8 Jan 2012 20:03:30 +0800
From: "Lv, Hui" <hui.lv@intel.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Thread-Topic: [PATCH] xen/sched_credit: Use delay to control scheduling
	frequency
Thread-Index: AQHMw+UZfvXlFfj3x0u7hY1iQlJRmJX/TMQAgAMk4+A=
Date: Sun, 8 Jan 2012 12:03:29 +0000
Message-ID: <E3E4738020A00E46AC373AD41F7FEAD50128C2@SHSMSX101.ccr.corp.intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
	<4F075204.3040408@eu.citrix.com>
In-Reply-To: <4F075204.3040408@eu.citrix.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"raistlin@linux.it" <raistlin@linux.it>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <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

Thanks, George.
Should I send a revised version?
Can it be checked in?

-----Original Message-----
From: George Dunlap [mailto:george.dunlap@eu.citrix.com] 
Sent: Saturday, January 07, 2012 3:57 AM
To: Lv, Hui
Cc: xen-devel@lists.xensource.com; raistlin@linux.it; JBeulich@suse.com; Ian Campbell
Subject: Re: [PATCH] xen/sched_credit: Use delay to control scheduling frequency

Sorry for the delay; just catching up after the Christmas holidays.

On 26/12/11 03:46, Hui Lv wrote:
> @@ -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")
The standard idiom for this kind of message would be:
  WARNING [what's wrong]
  [What you're doing about it]

So the last sentence of the warning should be:
   Setting ratelimit_us to 1000 * tslice_ms

(Grammatically, you could say "Forcing ratelimit..." but I think "force" 
is too strong in this case.)

Other than that, I'm happy with it, if everyone else is:

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 03:20:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 03: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 1Rk5lR-0002Ww-8E; Mon, 09 Jan 2012 03:19:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1Rk5lQ-0002Wo-10
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 03:19:12 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326079145!10083289!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8545 invoked from network); 9 Jan 2012 03:19:05 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 03:19:05 -0000
Received: by bkbzs2 with SMTP id zs2so10464891bkb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 08 Jan 2012 19:19: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=w5Q77BqKiDgPSRlh+FMbNdJvZ9pWIGcnHtwJvc+VOBI=;
	b=ZlplhPmQDkWsLNu8mcwvnSQ7uvBcrJ7kPjrGpRtV75W8jKyGSHTWZiCT1BkfslitZj
	YyyqH1G1ARJtKrhVb5WO+bmSOpSIutOP4Mo/rBN3bUxKir3QrX1fFsuco9N0NE7sQ67h
	BDtzyxyK3LvspiJe0+2vpYD5aUE3kT9ENNPLU=
MIME-Version: 1.0
Received: by 10.204.153.199 with SMTP id l7mr6623605bkw.88.1326079145249; Sun,
	08 Jan 2012 19:19:05 -0800 (PST)
Received: by 10.204.58.78 with HTTP; Sun, 8 Jan 2012 19:19:05 -0800 (PST)
Date: Sun, 8 Jan 2012 21:19:05 -0600
Message-ID: <CAKLFbfwrAUmBdGwFwgov3xxv7wcMeiYcixpEqEAqv9C2S508FA@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Modifying XCP Sources
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7417384436002461753=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7417384436002461753==
Content-Type: multipart/alternative; boundary=0015175d075e658d9f04b60fdc10

--0015175d075e658d9f04b60fdc10
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I am working on a research project using Xen 3.4.3 and CentOS. I have done
some changes to both Xen and CentOS kernel. I want to port my work to XCP.
Fortunately XCP uses CentOS and Xen 3.4.x.

Can I have some pointers how I can apply patches to XCP and rebuild the XCP
executable in ISO format?

Thanks,
~ SDK

--0015175d075e658d9f04b60fdc10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I am working on a research project using Xen 3.4.3 a=
nd CentOS. I have done some changes to both Xen and CentOS kernel. I want t=
o port my work to XCP. Fortunately XCP uses CentOS and Xen 3.4.x.=A0</div>
<div><br></div><div>Can I have some pointers how I can apply patches to XCP=
 and rebuild the XCP executable in ISO format?</div><div><br></div><div>Tha=
nks,<br clear=3D"all">~ SDK<br><br>
</div>

--0015175d075e658d9f04b60fdc10--


--===============7417384436002461753==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7417384436002461753==--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 03:20:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 03: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 1Rk5lR-0002Ww-8E; Mon, 09 Jan 2012 03:19:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ksrujandas@gmail.com>) id 1Rk5lQ-0002Wo-10
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 03:19:12 +0000
X-Env-Sender: ksrujandas@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326079145!10083289!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8545 invoked from network); 9 Jan 2012 03:19:05 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 03:19:05 -0000
Received: by bkbzs2 with SMTP id zs2so10464891bkb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 08 Jan 2012 19:19: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=w5Q77BqKiDgPSRlh+FMbNdJvZ9pWIGcnHtwJvc+VOBI=;
	b=ZlplhPmQDkWsLNu8mcwvnSQ7uvBcrJ7kPjrGpRtV75W8jKyGSHTWZiCT1BkfslitZj
	YyyqH1G1ARJtKrhVb5WO+bmSOpSIutOP4Mo/rBN3bUxKir3QrX1fFsuco9N0NE7sQ67h
	BDtzyxyK3LvspiJe0+2vpYD5aUE3kT9ENNPLU=
MIME-Version: 1.0
Received: by 10.204.153.199 with SMTP id l7mr6623605bkw.88.1326079145249; Sun,
	08 Jan 2012 19:19:05 -0800 (PST)
Received: by 10.204.58.78 with HTTP; Sun, 8 Jan 2012 19:19:05 -0800 (PST)
Date: Sun, 8 Jan 2012 21:19:05 -0600
Message-ID: <CAKLFbfwrAUmBdGwFwgov3xxv7wcMeiYcixpEqEAqv9C2S508FA@mail.gmail.com>
From: Srujan Kotikela <ksrujandas@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Modifying XCP Sources
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7417384436002461753=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7417384436002461753==
Content-Type: multipart/alternative; boundary=0015175d075e658d9f04b60fdc10

--0015175d075e658d9f04b60fdc10
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I am working on a research project using Xen 3.4.3 and CentOS. I have done
some changes to both Xen and CentOS kernel. I want to port my work to XCP.
Fortunately XCP uses CentOS and Xen 3.4.x.

Can I have some pointers how I can apply patches to XCP and rebuild the XCP
executable in ISO format?

Thanks,
~ SDK

--0015175d075e658d9f04b60fdc10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I am working on a research project using Xen 3.4.3 a=
nd CentOS. I have done some changes to both Xen and CentOS kernel. I want t=
o port my work to XCP. Fortunately XCP uses CentOS and Xen 3.4.x.=A0</div>
<div><br></div><div>Can I have some pointers how I can apply patches to XCP=
 and rebuild the XCP executable in ISO format?</div><div><br></div><div>Tha=
nks,<br clear=3D"all">~ SDK<br><br>
</div>

--0015175d075e658d9f04b60fdc10--


--===============7417384436002461753==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7417384436002461753==--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 04:51:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 04: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 1Rk7CJ-0002ub-D3; Mon, 09 Jan 2012 04:51:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1Rk7CG-0002uW-Eq
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 04:51:00 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326084652!8299808!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiAxMzk1MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20244 invoked from network); 9 Jan 2012 04:50:52 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66) by server-5.tower-174.messagelabs.com with SMTP;
	9 Jan 2012 04:50:52 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXI00B4MLGQS3@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:50:51 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXI006BKLG4FA@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:50:50 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGH41185; Mon,
	09 Jan 2012 12:50:50 +0800
Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 09 Jan 2012 12:50:48 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml424-hub.china.huawei.com ([10.82.67.163])
	with mapi id 14.01.0323.003; Mon, 09 Jan 2012 12:50:27 +0800
Date: Mon, 09 Jan 2012 04:50:26 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E934@szxeml522-mbx.china.huawei.com>
X-Originating-IP: [10.166.82.189]
To: Liuyongan <liuyongan@huawei.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E9EF@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel] [xen-devel] create irq failed due to
	move_cleanup_count always being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DJX+VQ9QgABSyACAAItH0P//im2AgAHyHnCAArJZgA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: HnsH KcMp K+IE OpGi PmcY QSY/ QpGj UKh/ UQf8 Uuy+ X/Hn a9rt
	bpQ9 iIPN lMGd lUsV; 3;
	YQBuAGQAcgBlAHcALgBjAG8AbwBwAGUAcgAzAEAAYwBpAHQAcgBpAHgALgBjAG8AbQA7AGsAZQBpAHIAQAB4AGUAbgAuAG8AcgBnADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {50A6B356-64F4-4EF5-A4F3-602AF77C0114};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Mon,
	09 Jan 2012 04:50:17 GMT;
	UgBFADoAIABbAFgAZQBuAC0AZABlAHYAZQBsAF0AIABbAHgAZQBuAC0AZABlAHYAZQBsAF0AIABjAHIAZQBhAHQAZQAgAGkAcgBxACAAZgBhAGkAbABlAGQAIABkAHUAZQAgAHQAbwAgAG0AbwB2AGUAXwBjAGwAZQBhAG4AdQBwAF8AYwBvAHUAbgB0ACAAYQBsAHcAYQB5AHMAIABiAGUAaQBuAGcAIABzAGUAdAA=
x-cr-puzzleid: {50A6B356-64F4-4EF5-A4F3-602AF77C0114}
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
	<4F06D454.1080608@citrix.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
	<4F06E689.9030506@citrix.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E934@szxeml522-mbx.china.huawei.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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



> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Liuyongan
> Sent: Saturday, January 07, 2012 6:34 PM
> To: Andrew Cooper
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
> move_cleanup_count always being set
> 
> 
> 
> > -----Original Message-----
> > From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > Sent: Friday, January 06, 2012 8:18 PM
> > To: Liuyongan
> > Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> > Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
> > always being set
> >
> > On 06/01/12 11:50, Liuyongan wrote:
> > >
> > >> -----Original Message-----
> > >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > >> Sent: Friday, January 06, 2012 7:01 PM
> > >> To: Liuyongan
> > >> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> > >> Subject: Re: [xen-devel] create irq failed due to
> move_cleanup_count
> > >> always being set
> > >>
> > >> Could you please avoid top posing.
> > >>
> > >> On 06/01/12 06:04, Liuyongan wrote:
> > >>>    As only 33 domains were successfully created(and destroyed)
> > before
> > >> the problem occurring,  there should be enough free IRQ  number
> and
> > >> vector number to allocate(suppose that irqs and vectors failed to
> > >> deallocate). And destroy_irq() will clear move_in_progress, so
> > >> move_cleanup_count must be setted?  Is this the case?
> > >>
> > >> Is it repeatably 33 domains, or was that a 1 off experiment?  Can
> > you
> > >   No, it's not repeatable, this occurred 2 times, another one is
> > after 152 domains.
> >
> > Can you list all the failures you have seen with the number of
> domains?
> > So far it seems that it has been 33 twice but many more some of the
> > time, which doesn't lend itself to saying "33 domains is a systematic
> > failure" for certain at the moment.
> 
>   Sorry, to make it clear: this problems occurred 2 times one is after
> 33
>   domains, the other is after 152 domains. I'm not quite expressive in
>   English.
> 
> >
> > >> confirm exactly which version of Xen you are using, including
> > changeset
> > >> if you know it?  Without knowing your hardware, it is hard to say
> if
> > >> there are actually enough free IRQs, although I do agree that what
> > you
> > >> are currently seeing is buggy behavior.
> > >>
> > >> The per-cpu IDT functionality introduced in Xen-4.0 is fragile at
> > the
> > >> best of times, and has had several bugfixes and tweaks to it which
> I
> > am
> > >> not certain have actually found their way back to Xen-4.0.  Could
> > you
> > >> try with Xen-4.1 and see if the problem persists?
> > >>
> > >> ~Andrew
> > >   As I could not make it re-occure in xen-4.0, trying xen-4.1 seems
> > useless.
> > > I noticed a scenario:
> >
> > I am confused.  Above, you say that the problem is repeatable, but
> here
> > you say it is not.
> >
> > >    1) move_in_progress occure;
> > >    2) IPI IRQ_MOVE_CLEANUP_VECTOR interrupt is sent;
> > >    3) the irq is destroyed, so cfg->vector is cleared, and etc.;
> > >    4) IRQ_MOVE_CLEANUP_VECTOR irq is responded.
> > >
> > >   In xen-4.1 , step 3, vector_irq of old_cpu_mask/old_domain is
> also
> > reset, so in step 4) move_cleanup_count will failed to sub by one,
> and
> > finally leading to create_irq failure(right?);
> > >
> > >   In xen-4.0, step 3, and in my code vector_irq is not reset(this
> is
> > a bug as you'v mentioned),  I still could not figure out why
> > > create_irq should failed.
> >
> > The first point of debugging should be to see how create_irq is
> > failing.  Is it failing because of find_unassigned_irq() or because
> of
> > __assign_irq_vector().
> >
> > Another piece of useful information would be what your guests are and
> > what they are trying to do with interrupts.  Are you using PCI
> > passthrough?
> >
> > ~Andrew
> 
>   Thx for your suggestion. I think I'v got the reason. Dig into
> details:
>   1) move_in_progress occurs;
>   2) new interrupt occurs on new cpus, so IPI IRQ_MOVE_CLEANUP_VECTOR
>      interrupt is sent;
>   3) the irq is destroyed, so __clear_irq_vector is called;
>   4) IRQ_MOVE_CLEANUP_VECTOR irq is responded with function
>      smp_irq_move_cleanup_interrupt();
> 
>   In step 3) code with patch "cpus_and(tmp_mask, cfg->old_domain,
>   cpu_online_map);" will clear vector_irq of old_cpu_mask/old_domain,
>   so in step 4):
>         irq = __get_cpu_var(vector_irq)[vector];
> 
>         if (irq == -1)
>             continue;
>   will missed the irq(cfg) to clear.
    Because move_in_progress will be cleared right after IPI irq sending,
    so the chance of old_domain's vector_irq being cleared is little, yet
    chance do exist, so loop based on irq will solve this problem.
> 
>   In step 3) code without patch(this is the case of mine),vector_irq
>   of old_cpu_mask is not cleared, so in step 4) irq(cfg) is found
>   correctly, but at code:
>          if (vector == cfg->vector && cpu_isset(me, cfg->domain))
>             goto unlock;
>   there is a chance that vector should equal cfg->vector and me equal
>   cfg->domain, but because irq is destroyed, then not "goto unlock",so
>          cfg->move_cleanup_count--;
>   execute unexpectedly. And left cfg->move_cleanup_count=255 finally.

    This needs a scenario like this: two irqs move concurrently from/to 
    one cpu: Irq 69 moves from cpu5 to cpu6,and irq 70 moves from cpu6 
    to cpu7, then if cpu6 receives IPI because of irq 70 moving 
    completion, and at the meantime, irq 69 is destroyed, then irq69's
    cfg-> move_cleanup_count may be a invalid value of 255.

    The radical reason of this problem is that cpu who receives IPI irq 
    cannot tell which vector completes move if there are two move 
    concurrently. 
    
> 
>   So I think the loop made in smp_irq_move_cleanup_interrupt should
>   based on irq not vectors to find struct cfg.
> 
>   Is that right? Drowsy head on weekend, if my analysis is right, I'll
>   submit the patch on Monday :)
> 
> >
> > >>>> -----Original Message-----
> > >>>> From: Liuyongan
> > >>>> Sent: Thursday, January 05, 2012 2:14 PM
> > >>>> To: Liuyongan; xen-devel@lists.xensource.com;
> > >>>> andrew.cooper3@citrix.com; keir@xen.org
> > >>>> Cc: Qianhuibin
> > >>>> Subject: RE: [xen-devel] create irq failed due to
> > move_cleanup_count
> > >>>> always being set
> > >>>>
> > >>>>> On 04/01/12 11:38, Andrew Cooper wrote:
> > >>>>>> On 04/01/12 04:37, Liuyongan wrote:
> > >>>>>> Hi, all
> > >>>>>>
> > >>>>>>     I'm using xen-4.0 to do a test. And when I create a
> domain,
> > it
> > >>>> failed due to create_irq() failure. As only 33 domains were
> > >>>> successfully created and destroyed before I got the continuous
> > >>>> failures, and the domain just before the failure was properly
> > >>>> destroyed(at least destroy_irq() was properly called, which will
> > >> clear
> > >>>> move_in_progress, according to the prink-message). So I can
> > conclude
> > >>>> for certain that __assign_irq_vector failed due to
> > >> move_cleanup_count
> > >>>> always being set.
> > >>>>> Is it always 33 domains it takes to cause the problem, or does
> it
> > >>>> vary?
> > >>>>> If it varies, then I think you want this patch
> > >>>>> http://xenbits.xensource.com/hg/xen-
> unstable.hg/rev/68b903bb1b01
> > >>>> which
> > >>>>> corrects the logic which works out which moved vectors it
> should
> > >>>> clean
> > >>>>> up.  Without it, stale irq numbers build up in the per-cpu
> > >> irq_vector
> > >>>>> tables leading to __assign_irq_vector failing with -ENOSPC as
> it
> > >> find
> > >>>>> find a vector to allocate.
> > >>>>   Yes, I've noticed this patch, as only 33 domains were created
> > >> before
> > >>>> the failures, so vectors of a given cpu should not have been
> used
> > >> up.
> > >>>> Besides, I got this problem after 143 domains were created
> another
> > >>>> time. But I could not repeat this problem manually as 4000+
> > domains
> > >>>> created successfully without this problem.
> > >>>>
> > >>>>>> //this is the normal case when create and destroy domain whose
> > id
> > >> is
> > >>>> 31;
> > >>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> > >>>>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> > >>>>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> > >>>>>> (XEN) irq.c:223, destroy irq 77
> > >>>>>>
> > >>>>>> //domain id 32 is created and destroyed correctly also.
> > >>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> > >>>>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> > >>>>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> > >>>>>> (XEN) irq.c:223, destroy irq 77
> > >>>>>>
> > >>>>>> //all the subsequent domain creation failed, below lists only
> 3
> > >>>> times:
> > >>>>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
> > >>>>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
> > >>>>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
> > >>>>>>
> > >>>>>>      I think this might be a bug and might have fixed, so I
> > >> compare
> > >>>> my code with 4.1.2 and search the mail list for potential
> patches.
> > >>>>
> > >>
> >
> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
> > >>>> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a
> patch
> > >> which
> > >>>> add locks in __assign_irq_vector. Can anybody explain why this
> > lock
> > >> is
> > >>>> needed? Or is there a patch that might fix my bug? Thx.
> > >>>>> This patch fixes a problem where IOAPIC line level interrupts
> > cease
> > >>>> for
> > >>>>> a while.  It has nothing to do with MSI interrupts.  (Also,
> there
> > >> are
> > >>>> no
> > >>>>> locks altered, and xen-4.0-testing seems to have gained an
> > >> additional
> > >>>>> hunk in hvm/vmx code unrelated to the original patch.)
> > >>>>>
> > >>>>>>     Addition message: my board is arch-x86, no domains left
> when
> > >>>> failed to create new ones, create_irq failure lasted one day
> until
> > I
> > >>>> reboot the board, and the irq number allocated is used certainly
> > for
> > >> a
> > >>>> msi dev.
> > >>>>>> Yong an Liu
> > >>>>>> 2012.1.4
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> 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
> >
> > --
> > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> > T: +44 (0)1223 225 900, http://www.citrix.com
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 04:51:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 04: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 1Rk7CJ-0002ub-D3; Mon, 09 Jan 2012 04:51:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <liuyongan@huawei.com>) id 1Rk7CG-0002uW-Eq
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 04:51:00 +0000
X-Env-Sender: liuyongan@huawei.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326084652!8299808!1
X-Originating-IP: [119.145.14.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NiA9PiAxMzk1MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20244 invoked from network); 9 Jan 2012 04:50:52 -0000
Received: from szxga03-in.huawei.com (HELO szxga03-in.huawei.com)
	(119.145.14.66) by server-5.tower-174.messagelabs.com with SMTP;
	9 Jan 2012 04:50:52 -0000
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXI00B4MLGQS3@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:50:51 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXI006BKLG4FA@szxga03-in.huawei.com> for
	xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:50:50 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGH41185; Mon,
	09 Jan 2012 12:50:50 +0800
Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Mon, 09 Jan 2012 12:50:48 +0800
Received: from SZXEML522-MBX.china.huawei.com ([169.254.2.185])
	by szxeml424-hub.china.huawei.com ([10.82.67.163])
	with mapi id 14.01.0323.003; Mon, 09 Jan 2012 12:50:27 +0800
Date: Mon, 09 Jan 2012 04:50:26 +0000
From: Liuyongan <liuyongan@huawei.com>
In-reply-to: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E934@szxeml522-mbx.china.huawei.com>
X-Originating-IP: [10.166.82.189]
To: Liuyongan <liuyongan@huawei.com>, Andrew Cooper <andrew.cooper3@citrix.com>
Message-id: <E4ABEE53CC34664FA3F0BD8AEAF50A19A2E9EF@szxeml522-mbx.china.huawei.com>
MIME-version: 1.0
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: [Xen-devel] [xen-devel] create irq failed due to
	move_cleanup_count always being set
Thread-index: AQHMy3ErCljmZmaIjUOAjG8PXXN/DJX+VQ9QgABSyACAAItH0P//im2AgAHyHnCAArJZgA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: HnsH KcMp K+IE OpGi PmcY QSY/ QpGj UKh/ UQf8 Uuy+ X/Hn a9rt
	bpQ9 iIPN lMGd lUsV; 3;
	YQBuAGQAcgBlAHcALgBjAG8AbwBwAGUAcgAzAEAAYwBpAHQAcgBpAHgALgBjAG8AbQA7AGsAZQBpAHIAQAB4AGUAbgAuAG8AcgBnADsAeABlAG4ALQBkAGUAdgBlAGwAQABsAGkAcwB0AHMALgB4AGUAbgBzAG8AdQByAGMAZQAuAGMAbwBtAA==;
	Sosha1_v1; 7; {50A6B356-64F4-4EF5-A4F3-602AF77C0114};
	bABpAHUAeQBvAG4AZwBhAG4AQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Mon,
	09 Jan 2012 04:50:17 GMT;
	UgBFADoAIABbAFgAZQBuAC0AZABlAHYAZQBsAF0AIABbAHgAZQBuAC0AZABlAHYAZQBsAF0AIABjAHIAZQBhAHQAZQAgAGkAcgBxACAAZgBhAGkAbABlAGQAIABkAHUAZQAgAHQAbwAgAG0AbwB2AGUAXwBjAGwAZQBhAG4AdQBwAF8AYwBvAHUAbgB0ACAAYQBsAHcAYQB5AHMAIABiAGUAaQBuAGcAIABzAGUAdAA=
x-cr-puzzleid: {50A6B356-64F4-4EF5-A4F3-602AF77C0114}
X-CFilter-Loop: Reflected
References: <mailman.5905.1325711316.12970.xen-devel@lists.xensource.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E3FC@szxeml522-mbx.china.huawei.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E7C7@szxeml522-mbx.china.huawei.com>
	<4F06D454.1080608@citrix.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E80F@szxeml522-mbx.china.huawei.com>
	<4F06E689.9030506@citrix.com>
	<E4ABEE53CC34664FA3F0BD8AEAF50A19A2E934@szxeml522-mbx.china.huawei.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Qianhuibin <qianhuibin@huawei.com>
Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
 move_cleanup_count always being 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



> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Liuyongan
> Sent: Saturday, January 07, 2012 6:34 PM
> To: Andrew Cooper
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> Subject: Re: [Xen-devel] [xen-devel] create irq failed due to
> move_cleanup_count always being set
> 
> 
> 
> > -----Original Message-----
> > From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > Sent: Friday, January 06, 2012 8:18 PM
> > To: Liuyongan
> > Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> > Subject: Re: [xen-devel] create irq failed due to move_cleanup_count
> > always being set
> >
> > On 06/01/12 11:50, Liuyongan wrote:
> > >
> > >> -----Original Message-----
> > >> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
> > >> Sent: Friday, January 06, 2012 7:01 PM
> > >> To: Liuyongan
> > >> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Qianhuibin
> > >> Subject: Re: [xen-devel] create irq failed due to
> move_cleanup_count
> > >> always being set
> > >>
> > >> Could you please avoid top posing.
> > >>
> > >> On 06/01/12 06:04, Liuyongan wrote:
> > >>>    As only 33 domains were successfully created(and destroyed)
> > before
> > >> the problem occurring,  there should be enough free IRQ  number
> and
> > >> vector number to allocate(suppose that irqs and vectors failed to
> > >> deallocate). And destroy_irq() will clear move_in_progress, so
> > >> move_cleanup_count must be setted?  Is this the case?
> > >>
> > >> Is it repeatably 33 domains, or was that a 1 off experiment?  Can
> > you
> > >   No, it's not repeatable, this occurred 2 times, another one is
> > after 152 domains.
> >
> > Can you list all the failures you have seen with the number of
> domains?
> > So far it seems that it has been 33 twice but many more some of the
> > time, which doesn't lend itself to saying "33 domains is a systematic
> > failure" for certain at the moment.
> 
>   Sorry, to make it clear: this problems occurred 2 times one is after
> 33
>   domains, the other is after 152 domains. I'm not quite expressive in
>   English.
> 
> >
> > >> confirm exactly which version of Xen you are using, including
> > changeset
> > >> if you know it?  Without knowing your hardware, it is hard to say
> if
> > >> there are actually enough free IRQs, although I do agree that what
> > you
> > >> are currently seeing is buggy behavior.
> > >>
> > >> The per-cpu IDT functionality introduced in Xen-4.0 is fragile at
> > the
> > >> best of times, and has had several bugfixes and tweaks to it which
> I
> > am
> > >> not certain have actually found their way back to Xen-4.0.  Could
> > you
> > >> try with Xen-4.1 and see if the problem persists?
> > >>
> > >> ~Andrew
> > >   As I could not make it re-occure in xen-4.0, trying xen-4.1 seems
> > useless.
> > > I noticed a scenario:
> >
> > I am confused.  Above, you say that the problem is repeatable, but
> here
> > you say it is not.
> >
> > >    1) move_in_progress occure;
> > >    2) IPI IRQ_MOVE_CLEANUP_VECTOR interrupt is sent;
> > >    3) the irq is destroyed, so cfg->vector is cleared, and etc.;
> > >    4) IRQ_MOVE_CLEANUP_VECTOR irq is responded.
> > >
> > >   In xen-4.1 , step 3, vector_irq of old_cpu_mask/old_domain is
> also
> > reset, so in step 4) move_cleanup_count will failed to sub by one,
> and
> > finally leading to create_irq failure(right?);
> > >
> > >   In xen-4.0, step 3, and in my code vector_irq is not reset(this
> is
> > a bug as you'v mentioned),  I still could not figure out why
> > > create_irq should failed.
> >
> > The first point of debugging should be to see how create_irq is
> > failing.  Is it failing because of find_unassigned_irq() or because
> of
> > __assign_irq_vector().
> >
> > Another piece of useful information would be what your guests are and
> > what they are trying to do with interrupts.  Are you using PCI
> > passthrough?
> >
> > ~Andrew
> 
>   Thx for your suggestion. I think I'v got the reason. Dig into
> details:
>   1) move_in_progress occurs;
>   2) new interrupt occurs on new cpus, so IPI IRQ_MOVE_CLEANUP_VECTOR
>      interrupt is sent;
>   3) the irq is destroyed, so __clear_irq_vector is called;
>   4) IRQ_MOVE_CLEANUP_VECTOR irq is responded with function
>      smp_irq_move_cleanup_interrupt();
> 
>   In step 3) code with patch "cpus_and(tmp_mask, cfg->old_domain,
>   cpu_online_map);" will clear vector_irq of old_cpu_mask/old_domain,
>   so in step 4):
>         irq = __get_cpu_var(vector_irq)[vector];
> 
>         if (irq == -1)
>             continue;
>   will missed the irq(cfg) to clear.
    Because move_in_progress will be cleared right after IPI irq sending,
    so the chance of old_domain's vector_irq being cleared is little, yet
    chance do exist, so loop based on irq will solve this problem.
> 
>   In step 3) code without patch(this is the case of mine),vector_irq
>   of old_cpu_mask is not cleared, so in step 4) irq(cfg) is found
>   correctly, but at code:
>          if (vector == cfg->vector && cpu_isset(me, cfg->domain))
>             goto unlock;
>   there is a chance that vector should equal cfg->vector and me equal
>   cfg->domain, but because irq is destroyed, then not "goto unlock",so
>          cfg->move_cleanup_count--;
>   execute unexpectedly. And left cfg->move_cleanup_count=255 finally.

    This needs a scenario like this: two irqs move concurrently from/to 
    one cpu: Irq 69 moves from cpu5 to cpu6,and irq 70 moves from cpu6 
    to cpu7, then if cpu6 receives IPI because of irq 70 moving 
    completion, and at the meantime, irq 69 is destroyed, then irq69's
    cfg-> move_cleanup_count may be a invalid value of 255.

    The radical reason of this problem is that cpu who receives IPI irq 
    cannot tell which vector completes move if there are two move 
    concurrently. 
    
> 
>   So I think the loop made in smp_irq_move_cleanup_interrupt should
>   based on irq not vectors to find struct cfg.
> 
>   Is that right? Drowsy head on weekend, if my analysis is right, I'll
>   submit the patch on Monday :)
> 
> >
> > >>>> -----Original Message-----
> > >>>> From: Liuyongan
> > >>>> Sent: Thursday, January 05, 2012 2:14 PM
> > >>>> To: Liuyongan; xen-devel@lists.xensource.com;
> > >>>> andrew.cooper3@citrix.com; keir@xen.org
> > >>>> Cc: Qianhuibin
> > >>>> Subject: RE: [xen-devel] create irq failed due to
> > move_cleanup_count
> > >>>> always being set
> > >>>>
> > >>>>> On 04/01/12 11:38, Andrew Cooper wrote:
> > >>>>>> On 04/01/12 04:37, Liuyongan wrote:
> > >>>>>> Hi, all
> > >>>>>>
> > >>>>>>     I'm using xen-4.0 to do a test. And when I create a
> domain,
> > it
> > >>>> failed due to create_irq() failure. As only 33 domains were
> > >>>> successfully created and destroyed before I got the continuous
> > >>>> failures, and the domain just before the failure was properly
> > >>>> destroyed(at least destroy_irq() was properly called, which will
> > >> clear
> > >>>> move_in_progress, according to the prink-message). So I can
> > conclude
> > >>>> for certain that __assign_irq_vector failed due to
> > >> move_cleanup_count
> > >>>> always being set.
> > >>>>> Is it always 33 domains it takes to cause the problem, or does
> it
> > >>>> vary?
> > >>>>> If it varies, then I think you want this patch
> > >>>>> http://xenbits.xensource.com/hg/xen-
> unstable.hg/rev/68b903bb1b01
> > >>>> which
> > >>>>> corrects the logic which works out which moved vectors it
> should
> > >>>> clean
> > >>>>> up.  Without it, stale irq numbers build up in the per-cpu
> > >> irq_vector
> > >>>>> tables leading to __assign_irq_vector failing with -ENOSPC as
> it
> > >> find
> > >>>>> find a vector to allocate.
> > >>>>   Yes, I've noticed this patch, as only 33 domains were created
> > >> before
> > >>>> the failures, so vectors of a given cpu should not have been
> used
> > >> up.
> > >>>> Besides, I got this problem after 143 domains were created
> another
> > >>>> time. But I could not repeat this problem manually as 4000+
> > domains
> > >>>> created successfully without this problem.
> > >>>>
> > >>>>>> //this is the normal case when create and destroy domain whose
> > id
> > >> is
> > >>>> 31;
> > >>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> > >>>>>> (XEN) irq.c:1377: dom31: pirq 79, irq 77 force unbind
> > >>>>>> (XEN) irq.c:1593: dom31: forcing unbind of pirq 79
> > >>>>>> (XEN) irq.c:223, destroy irq 77
> > >>>>>>
> > >>>>>> //domain id 32 is created and destroyed correctly also.
> > >>>>>> (XEN) irq.c:1232:d0 bind pirq 79, irq 77, share flag:0
> > >>>>>> (XEN) irq.c:1377: dom32: pirq 79, irq 77 force unbind
> > >>>>>> (XEN) irq.c:1593: dom32: forcing unbind of pirq 79
> > >>>>>> (XEN) irq.c:223, destroy irq 77
> > >>>>>>
> > >>>>>> //all the subsequent domain creation failed, below lists only
> 3
> > >>>> times:
> > >>>>>> (XEN) physdev.c:88: dom33: can't create irq for msi!
> > >>>>>> (XEN) physdev.c:88: dom34: can't create irq for msi!
> > >>>>>> (XEN) physdev.c:88: dom35: can't create irq for msi!
> > >>>>>>
> > >>>>>>      I think this might be a bug and might have fixed, so I
> > >> compare
> > >>>> my code with 4.1.2 and search the mail list for potential
> patches.
> > >>>>
> > >>
> >
> (http://xen.markmail.org/search/?q=move_cleanup_count#query:move_cleanu
> > >>>> p_count+page:6+mid:fpkrafqbeyiauvhs+state:results) submit a
> patch
> > >> which
> > >>>> add locks in __assign_irq_vector. Can anybody explain why this
> > lock
> > >> is
> > >>>> needed? Or is there a patch that might fix my bug? Thx.
> > >>>>> This patch fixes a problem where IOAPIC line level interrupts
> > cease
> > >>>> for
> > >>>>> a while.  It has nothing to do with MSI interrupts.  (Also,
> there
> > >> are
> > >>>> no
> > >>>>> locks altered, and xen-4.0-testing seems to have gained an
> > >> additional
> > >>>>> hunk in hvm/vmx code unrelated to the original patch.)
> > >>>>>
> > >>>>>>     Addition message: my board is arch-x86, no domains left
> when
> > >>>> failed to create new ones, create_irq failure lasted one day
> until
> > I
> > >>>> reboot the board, and the irq number allocated is used certainly
> > for
> > >> a
> > >>>> msi dev.
> > >>>>>> Yong an Liu
> > >>>>>> 2012.1.4
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> 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
> >
> > --
> > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> > T: +44 (0)1223 225 900, http://www.citrix.com
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 05:11:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 05:11:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rk7V0-0003Hw-79; Mon, 09 Jan 2012 05:10:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Rk7Ux-0003Hr-Sm
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 05:10:20 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326085812!8285726!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjE5OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17512 invoked from network); 9 Jan 2012 05:10:13 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-174.messagelabs.com with SMTP;
	9 Jan 2012 05:10:13 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 08 Jan 2012 21:10:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110126981"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga002.fm.intel.com with ESMTP; 08 Jan 2012 21:10:11 -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; Mon, 9 Jan 2012 13:09:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.88]) with mapi id
	14.01.0355.002; Mon, 9 Jan 2012 13:09:56 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4AACb/RMAACRHyAAI09hpA=
Date: Mon, 9 Jan 2012 05:09:55 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
In-Reply-To: <20120106143719.GA5078@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, January 06, 2012 10:37 PM
> 
> > > > I hadn't seen it... but then my main desktop box where I run intensive
> > > > tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
> > > > The box that has i915 just does some simple framebuffer manipulation
> and
> > > > that looks OK.
> > >
> > > yes, framebuffer console works well in my side too.
> 
> Good.
> > > > Do you see the same symptoms - checkboard screen?
> > >
> > > Not exactly. The screen becomes white, and then the system becomes
> > > unstable and hang several minutes later. It's possible that mine is a
> > > different issue than listed on the wiki page, since many reasons may
> > > finally reach the same symptom - GPU hang... :/
> >
> > well, there happens once with a checkboard screen, with the rest all
> > white screens.
> >
> > >
> > > >
> > > > The LKML had some fixes for this from Keith Packard. Something about
> > > > using i915.semaphores=0 I think. And I thought I saw some fixes for
> > > > 3.2-rc7 for this but not sure..
> > >
> > > I'll have a try on latest Linux on this. But I suspect that this may be a
> > > virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case),
> > > because same dom0 image could run glxgear smoothly on bare metal.
> > >
> >
> > I used latest 3.2 release, no difference.
> 
> What is the motherboard you have? I just bought an "DQ67SW" which perhaps
> has the same video card?

I'm using a HP elitebook 8460p (Intel @ QM67 express chipset), with a HD 
graphics 3000.

> 
> 
> But more interestingly - are you building your kernel from scratch? There

yes

> was some requirements in having CONFIG_IOMMU_DMAR in the kernels -
> otherwise
> the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.

Suppose you mean CONFIG_DMAR_TABLE? There's no CONFIG_IOMMU_DMAR
in the latest kernel. Yes, I didn't enable that option, and will have a try.

But a side question is, will enabling VT-d in dom0 conflict with Xen's own
VT-d operations?

> 
> And that caused an endless amount of pain.
> >
> > i915.semaphores=0 has no effect.
> >
> > But I observed below warnings in the boot process:
> > [    8.872430] [drm] MTRR allocation failed.  Graphics performance may
> suffer.
> > [   18.384552] microcode: CPU0 update to revision 0x1b failed
> >
> > Not sure whether above two issues may have impact on the said problem.
> > I know microcode update is still missing in upstream, but not sure about any
> 
> Right, microcode is ... pending hpa's coming back from paternity leave.
> > MTRR specific pending patches.
> 
> The MTRR are not in, but the graphics code should still work.

That's my feeling too...

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 Jan 09 05:11:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 05:11:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rk7V0-0003Hw-79; Mon, 09 Jan 2012 05:10:22 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1Rk7Ux-0003Hr-Sm
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 05:10:20 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326085812!8285726!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjE5OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17512 invoked from network); 9 Jan 2012 05:10:13 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-174.messagelabs.com with SMTP;
	9 Jan 2012 05:10:13 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 08 Jan 2012 21:10:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110126981"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga002.fm.intel.com with ESMTP; 08 Jan 2012 21:10:11 -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; Mon, 9 Jan 2012 13:09:57 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.38]) by
	SHSMSX102.ccr.corp.intel.com ([169.254.2.88]) with mapi id
	14.01.0355.002; Mon, 9 Jan 2012 13:09:56 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4AACb/RMAACRHyAAI09hpA=
Date: Mon, 9 Jan 2012 05:09:55 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
In-Reply-To: <20120106143719.GA5078@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Friday, January 06, 2012 10:37 PM
> 
> > > > I hadn't seen it... but then my main desktop box where I run intensive
> > > > tests (ie, games) is radeon and nvidia so hadn't really tried seen this.
> > > > The box that has i915 just does some simple framebuffer manipulation
> and
> > > > that looks OK.
> > >
> > > yes, framebuffer console works well in my side too.
> 
> Good.
> > > > Do you see the same symptoms - checkboard screen?
> > >
> > > Not exactly. The screen becomes white, and then the system becomes
> > > unstable and hang several minutes later. It's possible that mine is a
> > > different issue than listed on the wiki page, since many reasons may
> > > finally reach the same symptom - GPU hang... :/
> >
> > well, there happens once with a checkboard screen, with the rest all
> > white screens.
> >
> > >
> > > >
> > > > The LKML had some fixes for this from Keith Packard. Something about
> > > > using i915.semaphores=0 I think. And I thought I saw some fixes for
> > > > 3.2-rc7 for this but not sure..
> > >
> > > I'll have a try on latest Linux on this. But I suspect that this may be a
> > > virtualization specific bug (e.g. similar gfn/mfn issue as nvidia case),
> > > because same dom0 image could run glxgear smoothly on bare metal.
> > >
> >
> > I used latest 3.2 release, no difference.
> 
> What is the motherboard you have? I just bought an "DQ67SW" which perhaps
> has the same video card?

I'm using a HP elitebook 8460p (Intel @ QM67 express chipset), with a HD 
graphics 3000.

> 
> 
> But more interestingly - are you building your kernel from scratch? There

yes

> was some requirements in having CONFIG_IOMMU_DMAR in the kernels -
> otherwise
> the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.

Suppose you mean CONFIG_DMAR_TABLE? There's no CONFIG_IOMMU_DMAR
in the latest kernel. Yes, I didn't enable that option, and will have a try.

But a side question is, will enabling VT-d in dom0 conflict with Xen's own
VT-d operations?

> 
> And that caused an endless amount of pain.
> >
> > i915.semaphores=0 has no effect.
> >
> > But I observed below warnings in the boot process:
> > [    8.872430] [drm] MTRR allocation failed.  Graphics performance may
> suffer.
> > [   18.384552] microcode: CPU0 update to revision 0x1b failed
> >
> > Not sure whether above two issues may have impact on the said problem.
> > I know microcode update is still missing in upstream, but not sure about any
> 
> Right, microcode is ... pending hpa's coming back from paternity leave.
> > MTRR specific pending patches.
> 
> The MTRR are not in, but the graphics code should still work.

That's my feeling too...

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 Jan 09 06:53:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 06:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rk96V-0003gN-3m; Mon, 09 Jan 2012 06:53:11 +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 1Rk96S-0003gI-Q8
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 06:53:09 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326091966!51983700!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 21960 invoked from network); 9 Jan 2012 06:52:47 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 06:52:47 -0000
Received: by eaad11 with SMTP id d11so9366940eaa.30
	for <xen-devel@lists.xensource.com>;
	Sun, 08 Jan 2012 22:53:07 -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=wtT1Y9kthysh1EiuQtnI08sCmtL0sSCN86RKX77kIT4=;
	b=aHJb1F/qV2J4x91VcGs1O7NViIDdVMQIgIUfznZUnP7uVK94vbggXrRQ76P9iY1gVp
	r3h+ORl1NeNOLyBwSJkEZrlmLWCYgJRnTv1MLdmpm09jBsm5B0vas69q///MPB3H0vc3
	IoAuLzg/kAdtVPGDjWmn0LggbIdAeqM4yQEtU=
Received: by 10.213.33.146 with SMTP id h18mr1390818ebd.103.1326091987217;
	Sun, 08 Jan 2012 22:53:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.8.25 with HTTP; Sun, 8 Jan 2012 22:52:46 -0800 (PST)
From: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Mon, 9 Jan 2012 10:22:46 +0330
Message-ID: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] changing attributes of a 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

Hi,

I am trying to change attributes of a page from Dom0. The reason is
that I want to make a kernel module completely read-only to other
parts of kernel. I will update it from hypervisor itself. I have tried
to do this by this code:

// I have the mfn of the page in Dom0's address space.
void hamed_set_entry(struct p2m_domain *p2m, mfn_t mfn) {
    unsigned long gfn = mfn_to_gfn(p2m->domain,mfn);
    p2m_type_t p2mt;
    p2m_access_t p2ma;
    p2m_lock(p2m);
    p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query);
    p2m->set_entry(p2m, gfn, mfn, 0, p2mt, p2m_access_rwx);
    p2m_unlock(p2m);
}

But whenever it runs Dom0 restarts. I am not even sure this is the
right way to do this. I am grateful for any help!

Best Regards
Mohamad Rezaei
-------------------
ICT Research Center
Amirkabir University of Technology

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 06:53:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 06:53:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rk96V-0003gN-3m; Mon, 09 Jan 2012 06:53:11 +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 1Rk96S-0003gI-Q8
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 06:53:09 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326091966!51983700!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 21960 invoked from network); 9 Jan 2012 06:52:47 -0000
Received: from mail-ey0-f171.google.com (HELO mail-ey0-f171.google.com)
	(209.85.215.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 06:52:47 -0000
Received: by eaad11 with SMTP id d11so9366940eaa.30
	for <xen-devel@lists.xensource.com>;
	Sun, 08 Jan 2012 22:53:07 -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=wtT1Y9kthysh1EiuQtnI08sCmtL0sSCN86RKX77kIT4=;
	b=aHJb1F/qV2J4x91VcGs1O7NViIDdVMQIgIUfznZUnP7uVK94vbggXrRQ76P9iY1gVp
	r3h+ORl1NeNOLyBwSJkEZrlmLWCYgJRnTv1MLdmpm09jBsm5B0vas69q///MPB3H0vc3
	IoAuLzg/kAdtVPGDjWmn0LggbIdAeqM4yQEtU=
Received: by 10.213.33.146 with SMTP id h18mr1390818ebd.103.1326091987217;
	Sun, 08 Jan 2012 22:53:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.8.25 with HTTP; Sun, 8 Jan 2012 22:52:46 -0800 (PST)
From: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Mon, 9 Jan 2012 10:22:46 +0330
Message-ID: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] changing attributes of a 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

Hi,

I am trying to change attributes of a page from Dom0. The reason is
that I want to make a kernel module completely read-only to other
parts of kernel. I will update it from hypervisor itself. I have tried
to do this by this code:

// I have the mfn of the page in Dom0's address space.
void hamed_set_entry(struct p2m_domain *p2m, mfn_t mfn) {
    unsigned long gfn = mfn_to_gfn(p2m->domain,mfn);
    p2m_type_t p2mt;
    p2m_access_t p2ma;
    p2m_lock(p2m);
    p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query);
    p2m->set_entry(p2m, gfn, mfn, 0, p2mt, p2m_access_rwx);
    p2m_unlock(p2m);
}

But whenever it runs Dom0 restarts. I am not even sure this is the
right way to do this. I am grateful for any help!

Best Regards
Mohamad Rezaei
-------------------
ICT Research Center
Amirkabir University of Technology

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 07:03:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 07:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rk9Fv-000404-W5; Mon, 09 Jan 2012 07:02:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rk9Fu-0003zu-3S
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 07:02:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326086264!54839554!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk4OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25401 invoked from network); 9 Jan 2012 05:17:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 05:17:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,478,1320624000"; 
   d="scan'208";a="9887297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 05:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 05:18:11 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rk7cY-0005lb-Pp;
	Mon, 09 Jan 2012 05:18:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rk7cY-000432-H2;
	Mon, 09 Jan 2012 05:18:10 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10644-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Jan 2012 05:18:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10644: 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 10644 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10644/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 10643
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10643

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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   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-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10643 never pass

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  4086e4811547

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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


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 Jan 09 07:03:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 07:03:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rk9Fv-000404-W5; Mon, 09 Jan 2012 07:02:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rk9Fu-0003zu-3S
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 07:02:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326086264!54839554!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk4OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25401 invoked from network); 9 Jan 2012 05:17:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 05:17:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,478,1320624000"; 
   d="scan'208";a="9887297"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 05:18:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 05:18:11 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rk7cY-0005lb-Pp;
	Mon, 09 Jan 2012 05:18:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rk7cY-000432-H2;
	Mon, 09 Jan 2012 05:18:10 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10644-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Jan 2012 05:18:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10644: 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 10644 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10644/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 10 guest-saverestore           fail pass in 10643
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10643

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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   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-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10643 never pass

version targeted for testing:
 xen                  4086e4811547
baseline version:
 xen                  4086e4811547

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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


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 Jan 09 08:00:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 08:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkA8f-0004G4-Kb; Mon, 09 Jan 2012 07:59:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dmitry.torokhov@gmail.com>) id 1RkA8d-0004Fw-VM
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 07:59:28 +0000
X-Env-Sender: dmitry.torokhov@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326095960!8249566!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 27591 invoked from network); 9 Jan 2012 07:59:21 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 07:59:21 -0000
Received: by iagw33 with SMTP id w33so33914221iag.30
	for <xen-devel@lists.xensource.com>;
	Sun, 08 Jan 2012 23:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=/oKMQtN2qq9QQtqrVNEdHLJCsuB/UgVPrMdbtRQEqec=;
	b=q/P1gajjDZYeGFA1ke+gni3D/WkTG4vC6jHzTnBkZLlh4B1xy705iPE3ZIcbra0gev
	T0ZbxZZ6Or4Je/2SZ4Cqe26LlB0EcjSVSZPyNl7gJTvKWFGaw7glSvIzsf3NTd27dXYh
	B6/nbx3yLjAuOrHA0gvyHuFlnLECpX8y8gf8Y=
Received: by 10.42.131.136 with SMTP id z8mr15073250ics.5.1326095958510;
	Sun, 08 Jan 2012 23:59:18 -0800 (PST)
Received: from mailhub.coreip.homeip.net (c-67-188-112-76.hsd1.ca.comcast.net.
	[67.188.112.76])
	by mx.google.com with ESMTPS id z22sm248164592ibg.5.2012.01.08.23.59.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 08 Jan 2012 23:59:15 -0800 (PST)
Date: Sun, 8 Jan 2012 23:59:11 -0800
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120109075911.GA4049@core.coreip.homeip.net>
References: <20120106154640.GC21220@andromeda.dapyr.net>
	<da05c51a-a541-4edd-8356-f0b5d2af0c03@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <da05c51a-a541-4edd-8356-f0b5d2af0c03@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, FlorianSchandinat@gmx.de,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
 INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Andrew,

On Fri, Jan 06, 2012 at 10:58:06AM -0500, Andrew Jones wrote:
> 
> 
> ----- Original Message -----
> > On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> > > PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
> > > but
> > > they don't use the xen frame buffer frontend. For this case it
> > > doesn't
> > > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
> > > i.e.
> > > if you're using xenfb, then you'll want xenkbd. Switch the
> > > dependencies.
> > 
> > You need to CC as well these people that have 'maintainer' field on
> > them:
> > 
> > konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> > drivers/video/Kconfig
> > Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > (maintainer:FRAMEBUFFER LAYER)
> > linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
> > linux-kernel@vger.kernel.org (open list)
> > konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> > drivers/input/misc/Kconfig
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT
> > (KEYBOARD,...,commit_signer:9/16=56%)
> > Samuel Ortiz <sameo@linux.intel.com> (commit_signer:3/16=19%)
> > Anirudh Ghayal <aghayal@codeaurora.org> (commit_signer:2/16=12%)
> > Peter Ujfalusi <peter.ujfalusi@ti.com> (commit_signer:2/16=12%)
> > Alan Cox <alan@linux.intel.com> (commit_signer:2/16=12%)
> > linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
> > linux-kernel@vger.kernel.org (open list)
> > 
> 
> Thanks. Replied with them in CC.
> 
> Drew
> 
> > > 
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > >  drivers/input/misc/Kconfig |    2 +-
> > >  drivers/video/Kconfig      |    1 +
> > >  2 files changed, 2 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/input/misc/Kconfig
> > > b/drivers/input/misc/Kconfig
> > > index 22d875f..36c15bf 100644
> > > --- a/drivers/input/misc/Kconfig
> > > +++ b/drivers/input/misc/Kconfig
> > > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> > >  
> > >  config INPUT_XEN_KBDDEV_FRONTEND
> > >  	tristate "Xen virtual keyboard and mouse support"
> > > -	depends on XEN_FBDEV_FRONTEND
> > > +	depends on XEN

This is OK with me.

> > >  	default y
> > >  	select XEN_XENBUS_FRONTEND
> > >  	help
> > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > index d83e967..269b299 100644
> > > --- a/drivers/video/Kconfig
> > > +++ b/drivers/video/Kconfig
> > > @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
> > >  	select FB_SYS_IMAGEBLIT
> > >  	select FB_SYS_FOPS
> > >  	select FB_DEFERRED_IO
> > > +	select INPUT_XEN_KBDDEV_FRONTEND

But here you need to either depend on or select INPUT as select does not
resolve dependencies for selected symbol.

Thanks.

-- 
Dmitry

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 08:00:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 08:00:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkA8f-0004G4-Kb; Mon, 09 Jan 2012 07:59:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dmitry.torokhov@gmail.com>) id 1RkA8d-0004Fw-VM
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 07:59:28 +0000
X-Env-Sender: dmitry.torokhov@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326095960!8249566!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 27591 invoked from network); 9 Jan 2012 07:59:21 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 07:59:21 -0000
Received: by iagw33 with SMTP id w33so33914221iag.30
	for <xen-devel@lists.xensource.com>;
	Sun, 08 Jan 2012 23:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=date:from:to:cc:subject:message-id:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent;
	bh=/oKMQtN2qq9QQtqrVNEdHLJCsuB/UgVPrMdbtRQEqec=;
	b=q/P1gajjDZYeGFA1ke+gni3D/WkTG4vC6jHzTnBkZLlh4B1xy705iPE3ZIcbra0gev
	T0ZbxZZ6Or4Je/2SZ4Cqe26LlB0EcjSVSZPyNl7gJTvKWFGaw7glSvIzsf3NTd27dXYh
	B6/nbx3yLjAuOrHA0gvyHuFlnLECpX8y8gf8Y=
Received: by 10.42.131.136 with SMTP id z8mr15073250ics.5.1326095958510;
	Sun, 08 Jan 2012 23:59:18 -0800 (PST)
Received: from mailhub.coreip.homeip.net (c-67-188-112-76.hsd1.ca.comcast.net.
	[67.188.112.76])
	by mx.google.com with ESMTPS id z22sm248164592ibg.5.2012.01.08.23.59.14
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sun, 08 Jan 2012 23:59:15 -0800 (PST)
Date: Sun, 8 Jan 2012 23:59:11 -0800
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120109075911.GA4049@core.coreip.homeip.net>
References: <20120106154640.GC21220@andromeda.dapyr.net>
	<da05c51a-a541-4edd-8356-f0b5d2af0c03@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <da05c51a-a541-4edd-8356-f0b5d2af0c03@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, FlorianSchandinat@gmx.de,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
 INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Andrew,

On Fri, Jan 06, 2012 at 10:58:06AM -0500, Andrew Jones wrote:
> 
> 
> ----- Original Message -----
> > On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> > > PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
> > > but
> > > they don't use the xen frame buffer frontend. For this case it
> > > doesn't
> > > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
> > > i.e.
> > > if you're using xenfb, then you'll want xenkbd. Switch the
> > > dependencies.
> > 
> > You need to CC as well these people that have 'maintainer' field on
> > them:
> > 
> > konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> > drivers/video/Kconfig
> > Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > (maintainer:FRAMEBUFFER LAYER)
> > linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
> > linux-kernel@vger.kernel.org (open list)
> > konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> > drivers/input/misc/Kconfig
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT
> > (KEYBOARD,...,commit_signer:9/16=56%)
> > Samuel Ortiz <sameo@linux.intel.com> (commit_signer:3/16=19%)
> > Anirudh Ghayal <aghayal@codeaurora.org> (commit_signer:2/16=12%)
> > Peter Ujfalusi <peter.ujfalusi@ti.com> (commit_signer:2/16=12%)
> > Alan Cox <alan@linux.intel.com> (commit_signer:2/16=12%)
> > linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
> > linux-kernel@vger.kernel.org (open list)
> > 
> 
> Thanks. Replied with them in CC.
> 
> Drew
> 
> > > 
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > >  drivers/input/misc/Kconfig |    2 +-
> > >  drivers/video/Kconfig      |    1 +
> > >  2 files changed, 2 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/input/misc/Kconfig
> > > b/drivers/input/misc/Kconfig
> > > index 22d875f..36c15bf 100644
> > > --- a/drivers/input/misc/Kconfig
> > > +++ b/drivers/input/misc/Kconfig
> > > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> > >  
> > >  config INPUT_XEN_KBDDEV_FRONTEND
> > >  	tristate "Xen virtual keyboard and mouse support"
> > > -	depends on XEN_FBDEV_FRONTEND
> > > +	depends on XEN

This is OK with me.

> > >  	default y
> > >  	select XEN_XENBUS_FRONTEND
> > >  	help
> > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > index d83e967..269b299 100644
> > > --- a/drivers/video/Kconfig
> > > +++ b/drivers/video/Kconfig
> > > @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
> > >  	select FB_SYS_IMAGEBLIT
> > >  	select FB_SYS_FOPS
> > >  	select FB_DEFERRED_IO
> > > +	select INPUT_XEN_KBDDEV_FRONTEND

But here you need to either depend on or select INPUT as select does not
resolve dependencies for selected symbol.

Thanks.

-- 
Dmitry

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 08:22:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 08:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkAU5-0004tl-Rl; Mon, 09 Jan 2012 08:21: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 1RkAU4-0004tg-5D
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 08:21:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326097253!55120036!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 16319 invoked from network); 9 Jan 2012 08:20:53 -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; 9 Jan 2012 08:20:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 08:21:30 +0000
Message-Id: <4F0AB197020000780006B1A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 08:21:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <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>
	<4EEA343902000078000684FC@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201061805500.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201061805500.3150@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <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 06.01.12 at 19:13, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 15 Dec 2011, Jan Beulich wrote:
>> >>> 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.
> 
> I am going to add two checks here and print a message in case of errors,
> however I am not going to propagate the error up, considering that there
> is no error checking in elf_load_binary and it doesn't return an error.
> Would that be OK for you?

Actually, I would prefer making the entire call chain pass up the error,
and handle it at the top-most caller. Unless an error is impossible here
(i.e. the functions are being used solely to get the necessary HVM
semantics taken care of, in which case casting their results to void
and annotating them with a respective comment would seem sufficient
to me).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 08:22:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 08:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkAU5-0004tl-Rl; Mon, 09 Jan 2012 08:21: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 1RkAU4-0004tg-5D
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 08:21:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326097253!55120036!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 16319 invoked from network); 9 Jan 2012 08:20:53 -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; 9 Jan 2012 08:20:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 08:21:30 +0000
Message-Id: <4F0AB197020000780006B1A8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 08:21:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <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>
	<4EEA343902000078000684FC@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201061805500.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201061805500.3150@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"keir.xen@gmail.com" <keir.xen@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <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 06.01.12 at 19:13, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> On Thu, 15 Dec 2011, Jan Beulich wrote:
>> >>> 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.
> 
> I am going to add two checks here and print a message in case of errors,
> however I am not going to propagate the error up, considering that there
> is no error checking in elf_load_binary and it doesn't return an error.
> Would that be OK for you?

Actually, I would prefer making the entire call chain pass up the error,
and handle it at the top-most caller. Unless an error is impossible here
(i.e. the functions are being used solely to get the necessary HVM
semantics taken care of, in which case casting their results to void
and annotating them with a respective comment would seem sufficient
to me).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 09:32:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09: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 1RkBZh-0005cU-HS; Mon, 09 Jan 2012 09:31: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 1RkBZf-0005cM-Lu
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:31:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326101481!10188776!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 29680 invoked from network); 9 Jan 2012 09:31:21 -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; 9 Jan 2012 09:31:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 09:31:21 +0000
Message-Id: <4F0AC189020000780006B1DE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 09:29:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
In-Reply-To: <20120106221927.GA10248@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.01.12 at 23:19, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > I suppose you might want "Overriding ownership to dom%d".
>> 
>> OK. To the point and potentially can fit in 80 lines :-).
> 
> how about this?
>> 
> From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 4 Jan 2012 14:16:45 -0500
> Subject: [PATCH] xen/pciback: Expand the warning message to include domain
>  id.
> 
> When a PCI device is transferred to another domain and it is still
> in usage (from the internal perspective), mention which other
> domain is using it to aid in debugging.
> 
> [v2: Truncate the verbose message per Jan Beulich suggestion]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  drivers/xen/xen-pciback/xenbus.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 474d52e..2405a24 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct 
> xen_pcibk_device *pdev,
>  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
>  	if (xen_register_device_domain_owner(dev,
>  					     pdev->xdev->otherend_id) != 0) {
> -		dev_err(&dev->dev, "device has been assigned to another " \
> -			"domain! Over-writting the ownership, but beware.\n");
> +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> +			xen_find_device_domain_owner(dev));
>  		xen_unregister_device_domain_owner(dev);
>  		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
>  	}
> -- 
> 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 Mon Jan 09 09:32:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09: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 1RkBZh-0005cU-HS; Mon, 09 Jan 2012 09:31: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 1RkBZf-0005cM-Lu
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:31:27 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326101481!10188776!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 29680 invoked from network); 9 Jan 2012 09:31:21 -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; 9 Jan 2012 09:31:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 09:31:21 +0000
Message-Id: <4F0AC189020000780006B1DE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 09:29:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
In-Reply-To: <20120106221927.GA10248@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 06.01.12 at 23:19, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > I suppose you might want "Overriding ownership to dom%d".
>> 
>> OK. To the point and potentially can fit in 80 lines :-).
> 
> how about this?
>> 
> From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 4 Jan 2012 14:16:45 -0500
> Subject: [PATCH] xen/pciback: Expand the warning message to include domain
>  id.
> 
> When a PCI device is transferred to another domain and it is still
> in usage (from the internal perspective), mention which other
> domain is using it to aid in debugging.
> 
> [v2: Truncate the verbose message per Jan Beulich suggestion]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> ---
>  drivers/xen/xen-pciback/xenbus.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 474d52e..2405a24 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct 
> xen_pcibk_device *pdev,
>  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
>  	if (xen_register_device_domain_owner(dev,
>  					     pdev->xdev->otherend_id) != 0) {
> -		dev_err(&dev->dev, "device has been assigned to another " \
> -			"domain! Over-writting the ownership, but beware.\n");
> +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> +			xen_find_device_domain_owner(dev));
>  		xen_unregister_device_domain_owner(dev);
>  		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
>  	}
> -- 
> 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 Mon Jan 09 09:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09: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 1RkBhm-0005wT-Tw; Mon, 09 Jan 2012 09:39:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RkBhk-0005wI-KJ
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:39:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326101981!10099769!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk2ODc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15528 invoked from network); 9 Jan 2012 09:39:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 09:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320642000"; d="scan'208";a="176736421"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 04:38:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 04:38:23 -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 q099cJvi001110;
	Mon, 9 Jan 2012 01:38:20 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: "Lv, Hui" <hui.lv@intel.com>
In-Reply-To: <E3E4738020A00E46AC373AD41F7FEAD50128C2@SHSMSX101.ccr.corp.intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
	<4F075204.3040408@eu.citrix.com>
	<E3E4738020A00E46AC373AD41F7FEAD50128C2@SHSMSX101.ccr.corp.intel.com>
Date: Mon, 9 Jan 2012 09:49:02 +0000
Message-ID: <1326102542.13599.1.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>,
	"raistlin@linux.it" <raistlin@linux.it>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <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

On Sun, 2012-01-08 at 12:03 +0000, Lv, Hui wrote:
> Thanks, George.
> Should I send a revised version?
> Can it be checked in?

Yes, please send a revised version.

It will be checked in if one of the maintainers thinks there's enough
consensus (probably if no one has any more comments in the next day or
two).

Thanks,
 -George

> 
> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@eu.citrix.com] 
> Sent: Saturday, January 07, 2012 3:57 AM
> To: Lv, Hui
> Cc: xen-devel@lists.xensource.com; raistlin@linux.it; JBeulich@suse.com; Ian Campbell
> Subject: Re: [PATCH] xen/sched_credit: Use delay to control scheduling frequency
> 
> Sorry for the delay; just catching up after the Christmas holidays.
> 
> On 26/12/11 03:46, Hui Lv wrote:
> > @@ -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")
> The standard idiom for this kind of message would be:
>   WARNING [what's wrong]
>   [What you're doing about it]
> 
> So the last sentence of the warning should be:
>    Setting ratelimit_us to 1000 * tslice_ms
> 
> (Grammatically, you could say "Forcing ratelimit..." but I think "force" 
> is too strong in this case.)
> 
> Other than that, I'm happy with it, if everyone else is:
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 09:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09: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 1RkBhm-0005wT-Tw; Mon, 09 Jan 2012 09:39:50 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RkBhk-0005wI-KJ
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:39:48 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326101981!10099769!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk2ODc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15528 invoked from network); 9 Jan 2012 09:39:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 09:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320642000"; d="scan'208";a="176736421"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 04:38:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 04:38:23 -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 q099cJvi001110;
	Mon, 9 Jan 2012 01:38:20 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: "Lv, Hui" <hui.lv@intel.com>
In-Reply-To: <E3E4738020A00E46AC373AD41F7FEAD50128C2@SHSMSX101.ccr.corp.intel.com>
References: <18f40e1d027491964a88.1324889181@wsm-ep-n0>
	<4F075204.3040408@eu.citrix.com>
	<E3E4738020A00E46AC373AD41F7FEAD50128C2@SHSMSX101.ccr.corp.intel.com>
Date: Mon, 9 Jan 2012 09:49:02 +0000
Message-ID: <1326102542.13599.1.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>,
	"raistlin@linux.it" <raistlin@linux.it>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <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

On Sun, 2012-01-08 at 12:03 +0000, Lv, Hui wrote:
> Thanks, George.
> Should I send a revised version?
> Can it be checked in?

Yes, please send a revised version.

It will be checked in if one of the maintainers thinks there's enough
consensus (probably if no one has any more comments in the next day or
two).

Thanks,
 -George

> 
> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@eu.citrix.com] 
> Sent: Saturday, January 07, 2012 3:57 AM
> To: Lv, Hui
> Cc: xen-devel@lists.xensource.com; raistlin@linux.it; JBeulich@suse.com; Ian Campbell
> Subject: Re: [PATCH] xen/sched_credit: Use delay to control scheduling frequency
> 
> Sorry for the delay; just catching up after the Christmas holidays.
> 
> On 26/12/11 03:46, Hui Lv wrote:
> > @@ -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")
> The standard idiom for this kind of message would be:
>   WARNING [what's wrong]
>   [What you're doing about it]
> 
> So the last sentence of the warning should be:
>    Setting ratelimit_us to 1000 * tslice_ms
> 
> (Grammatically, you could say "Forcing ratelimit..." but I think "force" 
> is too strong in this case.)
> 
> Other than that, I'm happy with it, if everyone else is:
> 
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 09:46:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09: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 1RkBnV-0006Hb-Qq; Mon, 09 Jan 2012 09:45:45 +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 1RkBnT-0006Gz-OT
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:45:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326102293!47768940!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 22971 invoked from network); 9 Jan 2012 09:44:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 09:44:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 09:45:37 +0000
Message-Id: <4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 09:45:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@entel.upc.edu>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
In-Reply-To: <e12ec1071410c946367c.1325906408@build.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.01.12 at 04:20, Roger Pau Monne <roger.pau@entel.upc.edu> wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1325906230 -3600
> # Node ID e12ec1071410c946367cb0508cf218a0c3b596ca
> # Parent  4086e4811547ddffb9a53fbf2efb6c2fa436b70a
> build: add autoconf to replace custom checks in tools/check
> 
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script,
> config/Autoconf.mk and config.h.
> 
> Autoconf.mk is included by Config.mk, and contains most of the
> options previously defined in .config, that can now be set passing
> parameters or defining environment variables when executing configure
> script.
> 
> config.h is still not used anywhere, and is automatically created by
> autoheader, altough this migh change when we start to include this
> file.
> 
> Just a first release, and since Iit's my first autoconf script I guess
> there will be many things to polish here... Please review and comment.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 4086e4811547 -r e12ec1071410 Config.mk
> --- a/Config.mk	Thu Jan 05 17:25:23 2012 +0000
> +++ b/Config.mk	Sat Jan 07 04:17:10 2012 +0100
> @@ -9,8 +9,6 @@ realpath = $(wildcard $(foreach file,$(1
>  
>  -include $(XEN_ROOT)/.config
>  
> -# A debug build of Xen and tools?
> -debug ?= y

I think this should be kept here (possibly override-able by the autoconf
determined setting, i.e. it may need moving past the inclusion below).

>  
>  XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
>                           -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
> @@ -43,6 +41,7 @@ endif
>  
>  include $(XEN_ROOT)/config/$(XEN_OS).mk
>  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
> +include $(XEN_ROOT)/config/Autoconf.mk

And I would really like to avoid having hypervisor (and perhaps
also stubdom) builds to require running the autoconfig thing
first - this ought to be limited to the tools (as were the check
scripts).

Jan

>  SHAREDIR    ?= $(PREFIX)/share
>  DOCDIR      ?= $(SHAREDIR)/doc/xen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 09:46:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09: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 1RkBnV-0006Hb-Qq; Mon, 09 Jan 2012 09:45:45 +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 1RkBnT-0006Gz-OT
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:45:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326102293!47768940!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 22971 invoked from network); 9 Jan 2012 09:44:53 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 09:44:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 09:45:37 +0000
Message-Id: <4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 09:45:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@entel.upc.edu>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
In-Reply-To: <e12ec1071410c946367c.1325906408@build.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 07.01.12 at 04:20, Roger Pau Monne <roger.pau@entel.upc.edu> wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1325906230 -3600
> # Node ID e12ec1071410c946367cb0508cf218a0c3b596ca
> # Parent  4086e4811547ddffb9a53fbf2efb6c2fa436b70a
> build: add autoconf to replace custom checks in tools/check
> 
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script,
> config/Autoconf.mk and config.h.
> 
> Autoconf.mk is included by Config.mk, and contains most of the
> options previously defined in .config, that can now be set passing
> parameters or defining environment variables when executing configure
> script.
> 
> config.h is still not used anywhere, and is automatically created by
> autoheader, altough this migh change when we start to include this
> file.
> 
> Just a first release, and since Iit's my first autoconf script I guess
> there will be many things to polish here... Please review and comment.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 4086e4811547 -r e12ec1071410 Config.mk
> --- a/Config.mk	Thu Jan 05 17:25:23 2012 +0000
> +++ b/Config.mk	Sat Jan 07 04:17:10 2012 +0100
> @@ -9,8 +9,6 @@ realpath = $(wildcard $(foreach file,$(1
>  
>  -include $(XEN_ROOT)/.config
>  
> -# A debug build of Xen and tools?
> -debug ?= y

I think this should be kept here (possibly override-able by the autoconf
determined setting, i.e. it may need moving past the inclusion below).

>  
>  XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
>                           -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
> @@ -43,6 +41,7 @@ endif
>  
>  include $(XEN_ROOT)/config/$(XEN_OS).mk
>  include $(XEN_ROOT)/config/$(XEN_TARGET_ARCH).mk
> +include $(XEN_ROOT)/config/Autoconf.mk

And I would really like to avoid having hypervisor (and perhaps
also stubdom) builds to require running the autoconfig thing
first - this ought to be limited to the tools (as were the check
scripts).

Jan

>  SHAREDIR    ?= $(PREFIX)/share
>  DOCDIR      ?= $(SHAREDIR)/doc/xen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 09:51:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkBsj-0006XB-0j; Mon, 09 Jan 2012 09:51: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 1RkBsg-0006X1-OU
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:51:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326102659!10230798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4227 invoked from network); 9 Jan 2012 09:50:59 -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 Jan 2012 09:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9890838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 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, 9 Jan 2012
	09:50:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 9 Jan 2012 09:50:57 +0000
In-Reply-To: <20120106221927.GA10248@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326102657.17210.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 22:19 +0000, Konrad Rzeszutek Wilk wrote:
> > > I suppose you might want "Overriding ownership to dom%d".
> > 
> > OK. To the point and potentially can fit in 80 lines :-).
> 
> how about this?
> > 
> From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 4 Jan 2012 14:16:45 -0500
> Subject: [PATCH] xen/pciback: Expand the warning message to include domain
>  id.
> 
> When a PCI device is transferred to another domain and it is still
> in usage (from the internal perspective), mention which other
> domain is using it to aid in debugging.
> 
> [v2: Truncate the verbose message per Jan Beulich suggestion]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/xen-pciback/xenbus.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 474d52e..2405a24 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
>  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
>  	if (xen_register_device_domain_owner(dev,
>  					     pdev->xdev->otherend_id) != 0) {
> -		dev_err(&dev->dev, "device has been assigned to another " \
> -			"domain! Over-writting the ownership, but beware.\n");
> +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> +			xen_find_device_domain_owner(dev));

That sounds like you are going to be assigning the ownership to that
dom, but xen_find_device_domain_owner so aren't you actually steeling
ownership from that domain?

>  		xen_unregister_device_domain_owner(dev);
>  		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
>  	}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 09:51:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkBsj-0006XB-0j; Mon, 09 Jan 2012 09:51: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 1RkBsg-0006X1-OU
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:51:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326102659!10230798!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4227 invoked from network); 9 Jan 2012 09:50:59 -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 Jan 2012 09:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9890838"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 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, 9 Jan 2012
	09:50:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 9 Jan 2012 09:50:57 +0000
In-Reply-To: <20120106221927.GA10248@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326102657.17210.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 22:19 +0000, Konrad Rzeszutek Wilk wrote:
> > > I suppose you might want "Overriding ownership to dom%d".
> > 
> > OK. To the point and potentially can fit in 80 lines :-).
> 
> how about this?
> > 
> From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Wed, 4 Jan 2012 14:16:45 -0500
> Subject: [PATCH] xen/pciback: Expand the warning message to include domain
>  id.
> 
> When a PCI device is transferred to another domain and it is still
> in usage (from the internal perspective), mention which other
> domain is using it to aid in debugging.
> 
> [v2: Truncate the verbose message per Jan Beulich suggestion]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  drivers/xen/xen-pciback/xenbus.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> index 474d52e..2405a24 100644
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
>  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
>  	if (xen_register_device_domain_owner(dev,
>  					     pdev->xdev->otherend_id) != 0) {
> -		dev_err(&dev->dev, "device has been assigned to another " \
> -			"domain! Over-writting the ownership, but beware.\n");
> +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> +			xen_find_device_domain_owner(dev));

That sounds like you are going to be assigning the ownership to that
dom, but xen_find_device_domain_owner so aren't you actually steeling
ownership from that domain?

>  		xen_unregister_device_domain_owner(dev);
>  		xen_register_device_domain_owner(dev, pdev->xdev->otherend_id);
>  	}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 09:58:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkBzF-0006xd-IR; Mon, 09 Jan 2012 09:57:53 +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 1RkBzE-0006x6-3B
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:57:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326103065!2782625!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 17296 invoked from network); 9 Jan 2012 09:57:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 09:57:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkBz6-000EB5-SQ; Mon, 09 Jan 2012 09:57:44 +0000
Date: Mon, 9 Jan 2012 09:57:44 +0000
From: Tim Deegan <tim@xen.org>
To: lmingcsce <Ming.Aaron.Liu@gmail.com>
Message-ID: <20120109095744.GC26595@ocelot.phlegethon.org>
References: <1325868115079-5126037.post@n5.nabble.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325868115079-5126037.post@n5.nabble.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] DomU memory update procedures ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 08:41 -0800 on 06 Jan (1325839315), lmingcsce wrote:
> Hi, I have a question about memory update of DomU. 
> When DomU writes a new value to a memory address, how does hypervisor change
> the value in the particular address and change the dirty page bit? 

The hypervisor is not usually involved in writing the contents of the
memory -- that's just done my the CPU in the normal way.  The same is
true for the dirty bit in the PTE. 

In some cases the hypervisor has to emulate an instruction.  The code
for the emulator is in x86_emulate.c; the pagetable walker is in
arch/x86/mm/guest_walk.c.

> In my current understanding, I find that there is a hypercal do_mmu_update
> in the hypervisor changing the content in the memory.

do_mmu_update() is used by PV domU to change its pagetables; it's not
involved in normal memory writes. 

Cheers,

Tim.

> However, I want to
> know the details about the memory update procedures. Or you can simply tell
> me how can I find this procedures.
> Thanks for your help. 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/DomU-memory-update-procedures-tp5126037p5126037.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 09:58:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 09:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkBzF-0006xd-IR; Mon, 09 Jan 2012 09:57:53 +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 1RkBzE-0006x6-3B
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 09:57:52 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326103065!2782625!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 17296 invoked from network); 9 Jan 2012 09:57:46 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 09:57:46 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkBz6-000EB5-SQ; Mon, 09 Jan 2012 09:57:44 +0000
Date: Mon, 9 Jan 2012 09:57:44 +0000
From: Tim Deegan <tim@xen.org>
To: lmingcsce <Ming.Aaron.Liu@gmail.com>
Message-ID: <20120109095744.GC26595@ocelot.phlegethon.org>
References: <1325868115079-5126037.post@n5.nabble.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325868115079-5126037.post@n5.nabble.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] DomU memory update procedures ?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 08:41 -0800 on 06 Jan (1325839315), lmingcsce wrote:
> Hi, I have a question about memory update of DomU. 
> When DomU writes a new value to a memory address, how does hypervisor change
> the value in the particular address and change the dirty page bit? 

The hypervisor is not usually involved in writing the contents of the
memory -- that's just done my the CPU in the normal way.  The same is
true for the dirty bit in the PTE. 

In some cases the hypervisor has to emulate an instruction.  The code
for the emulator is in x86_emulate.c; the pagetable walker is in
arch/x86/mm/guest_walk.c.

> In my current understanding, I find that there is a hypercal do_mmu_update
> in the hypervisor changing the content in the memory.

do_mmu_update() is used by PV domU to change its pagetables; it's not
involved in normal memory writes. 

Cheers,

Tim.

> However, I want to
> know the details about the memory update procedures. Or you can simply tell
> me how can I find this procedures.
> Thanks for your help. 
> 
> --
> View this message in context: http://xen.1045712.n5.nabble.com/DomU-memory-update-procedures-tp5126037p5126037.html
> Sent from the Xen - Dev mailing list archive at Nabble.com.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:02:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkC3n-0007Mh-KJ; Mon, 09 Jan 2012 10:02:35 +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 1RkC3m-0007Mb-0X
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:02:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326103291!63454784!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 27116 invoked from network); 9 Jan 2012 10:01:31 -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; 9 Jan 2012 10:01:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkC3i-000ED1-68; Mon, 09 Jan 2012 10:02:30 +0000
Date: Mon, 9 Jan 2012 10:02:29 +0000
From: Tim Deegan <tim@xen.org>
To: Bob Jung <Bob.Jung@mandiant.com>
Message-ID: <20120109100229.GD26595@ocelot.phlegethon.org>
References: <CC85277B-4FC1-4296-867C-971234973298@mandiant.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC85277B-4FC1-4296-867C-971234973298@mandiant.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] potential bug where mem_event_request_t gfn value
	== -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

At 20:49 +0000 on 06 Jan (1325882993), Bob Jung wrote:
> 
> Hi there,
> 
> I am running an adapted version of tools/tests/xen_access/xen_access.c  to get and respond to memory events to do some analysis.  Anyways, after registering for and receiving single stepping events in my ring buffer where the me_event_request_t's  reason field == MEM_EVENT_REASON_SINGLESTEP, I sometimes see that the gfn in the request is -1.
> 
> the guest is HVM windows 32 bit.  For 99.99% of the single step traps the req.gfn value is the correct guest frame number value, but every now and again I get a -1
> 
> Does anyone know why this could happen?  

If could happen if the VA in %rip at the time isn't mapped to anything
in the guest's pagetables (for example, if the guest is demand-paging
the program that's running).   You should be able to test this by looking
at the valie if %rip returned in the gla field.   There's some
pagetable-walking code in tools/libxc/xc_pagetab.c

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:02:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkC3n-0007Mh-KJ; Mon, 09 Jan 2012 10:02:35 +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 1RkC3m-0007Mb-0X
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:02:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326103291!63454784!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 27116 invoked from network); 9 Jan 2012 10:01:31 -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; 9 Jan 2012 10:01:31 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkC3i-000ED1-68; Mon, 09 Jan 2012 10:02:30 +0000
Date: Mon, 9 Jan 2012 10:02:29 +0000
From: Tim Deegan <tim@xen.org>
To: Bob Jung <Bob.Jung@mandiant.com>
Message-ID: <20120109100229.GD26595@ocelot.phlegethon.org>
References: <CC85277B-4FC1-4296-867C-971234973298@mandiant.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CC85277B-4FC1-4296-867C-971234973298@mandiant.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] potential bug where mem_event_request_t gfn value
	== -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

At 20:49 +0000 on 06 Jan (1325882993), Bob Jung wrote:
> 
> Hi there,
> 
> I am running an adapted version of tools/tests/xen_access/xen_access.c  to get and respond to memory events to do some analysis.  Anyways, after registering for and receiving single stepping events in my ring buffer where the me_event_request_t's  reason field == MEM_EVENT_REASON_SINGLESTEP, I sometimes see that the gfn in the request is -1.
> 
> the guest is HVM windows 32 bit.  For 99.99% of the single step traps the req.gfn value is the correct guest frame number value, but every now and again I get a -1
> 
> Does anyone know why this could happen?  

If could happen if the VA in %rip at the time isn't mapped to anything
in the guest's pagetables (for example, if the guest is demand-paging
the program that's running).   You should be able to test this by looking
at the valie if %rip returned in the gla field.   There's some
pagetable-walking code in tools/libxc/xc_pagetab.c

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:08:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 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 1RkC9b-0007at-Ed; Mon, 09 Jan 2012 10:08:35 +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 1RkC9a-0007ac-J5
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:08:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326103706!9646596!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 8856 invoked from network); 9 Jan 2012 10:08:27 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 10:08:27 -0000
Received: by pbbb11 with SMTP id b11so14846097pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 02:08: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=nP8nXEifIVQVhEOhBBH0Ni5AhFQemtXmwsgOAK4FtuQ=;
	b=eUqte9aBmIX4Qt3kc510vDGwaQL0xGDcXaPz/S6jBv8f0XpT66+SIhdkETv3/MQRbN
	KxMNv2RtuTt46+n40tUd3DTxHSmG91TxZ6QcGsgYM6Z7yD74a7E2/ooFlw8e0uzFhtXK
	58W5+Ae7tW5q5oWwu6xVvLXYdAEUCBc7uFtGw=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr40275605pbc.77.1326103705947; Mon,
	09 Jan 2012 02:08:25 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 9 Jan 2012 02:08:25 -0800 (PST)
In-Reply-To: <20229.59079.535980.830271@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
Date: Mon, 9 Jan 2012 11:08:25 +0100
X-Google-Sender-Auth: ImayB3DsF2D7Uv9DZqCbYIhJeCo
Message-ID: <CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@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 <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzUgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IFJvZ2Vy
IFBhdSBNb25uw6kgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIFJGQzogU3RpbGwgVE9ETyBmb3Ig
NC4yPyIpOgo+PiBJIGRvbid0IGtub3cgbXVjaCBhYm91dCBkcml2ZXIgZG9tYWlucywgYnV0IGZy
b20gd2hhdCBJJ3ZlIHJlYWQgdGhleQo+PiBzaG91bGQgYmUgcnVubmluZyBzb21ldGhpbmcgbGlr
ZSBOZXRCU0QgeGVuYmFja2VuZCBhbmQgbGlzdGVuIGZvcgo+PiB4ZW5zdG9yZSBldmVudHMuIE1v
c3Qgb2YgdGhlIGZ1bmN0aW9ucyB0aGF0IEkndmUgd3JpdHRlbiBvbiBteSBob3RwbHVnCj4+IHNl
cmllcyBjYW4gYmUgdXNlZCB0byBjcmVhdGUgYSBsaXR0bGUgZGFlbW9uLCB0aGF0J3Mgbm90IHRo
ZSBwcm9ibGVtLAo+PiB0aGUgcHJvYmxlbSBpcyB3aGF0IGNhbiB3ZSB1c2UgdG8gc3luY2hyb25p
emUgaG90cGx1ZyBzY3JpcHQgY2FsbGluZwo+PiBhbmQgbGlieGwgKHdoYXQgY29tZXMgdG8gbWlu
ZCBpcyB1c2luZyBhIGRlZGljYXRlZCB4ZW5zdG9yZSB2YXJpYWJsZQo+PiBmb3IgZWFjaCBkZXZp
Y2UsIGJ1dCBzb21lb25lIG1pZ2h0IGhhdmUgYSBiZXR0ZXIgaWRlYSkuCgpTb3JyeSBJIGRpZG4n
dCByZXBseSBlYXJsaWVyLCBJIHdhcyBzdGlsbCBvbiBob2xpZGF5cyAobW9zdGx5IHdvcmtpbmcK
d2l0aCB0aGUgYXV0b3Rvb2xzIHN0dWZmKS4KCj4gVGhpcyBlbnZpc2FnZXMgZGV2aWNlciBzZXR1
cC90ZWFyZG93biBzY3JpcHRzIGluIGRyaXZlciBkb21haW5zCj4gcnVubmluZyBpbiBhIGRpZmZl
cmVudCB3YXkgdG8gdGhvc2UgaW4gdGhlIHNhbWUgZG9tYWluIGFzIHRoZQo+IHRvb2xzdGFjay4g
wqBBcmUgd2Ugc3VyZSB0aGlzIGlzIGEgZ29vZCBpZGVhID8KCk5vLCBJIHRoaW5rIGl0J3MgYmVz
dCB0aGF0IGV2ZW4gaXMgdGhlIGRyaXZlciBkb21haW4gaXMgRG9tMCB0aGUgc2FtZQpwcm9jZWR1
cmUgc2hvdWxkIGJlIGV4ZWN1dGVkLCBhbmQgeGVuYmFja2VuZGQgc2hvdWxkIGJlIHJ1bm5pbmcg
aW4KZXZlcnkgZHJpdmVyIGRvbWFpbiwgRG9tMCBpbmNsdWRlZCwgdG9vbHN0YWNrIHNob3VsZCBu
ZXZlciBleGVjdXRlCmhvdHBsdWcgc2NyaXB0cyBkaXJlY3RseS4KCj4gSSB0aGluayBpdCB3b3Vs
ZCBiZSBwcmVmZXJhYmxlIHRvIGhhdmUgb25seSBvbmUgaW50ZXJmYWNlIHRvIGRldmljZQo+IHNj
cmlwdHMsIHdoaWNoIGlzIHVzZWQgZXZlcnl3aGVyZS4gwqBUaGF0IGludGVyZmFjZSB3b3VsZCBo
YXZlIHRvCj4gaW52b2x2ZSBpbml0aWF0aW9uIGJ5IHRoZSB0b29sc3RhY2ssIGFuZCBjb2xsZWN0
aW9uIG9mIHJlc3VsdGluZwo+IHN1Y2Nlc3MvZmFpbHVyZS9ldGMuLCB2aWEgeGVuc3RvcmUuCgpB
cmUgd2Ugb25seSBnb2luZyB0byB1c2UgeGVuc3RvcmUgdG8gc2hhcmUgaW5mb3JtYXRpb24gYmV0
d2VlbiBib3RoCmRvbWFpbnMgKERvbTAgPC0tPiBEcml2ZXIgZG9tYWluKT8KCkknbSBnb2luZyB0
byBjb21tZW50IHRoZSB2aWYgY2FzZSwgYnV0IEkgdGhpbmsgYm90aCB2aWYgYW5kIGJsb2NrCmRl
dmljZXMgc2hvdWxkIGZvbGxvdyB0aGUgc2FtZSBhcHByb2FjaCwgYW5kIGhvdHBsdWcgc2NyaXB0
IGV4ZWN1dGlvbgpoYXMgdG8gYmUgc29tZXRoaW5nICJzdGFuZGFyZCIgYW5kIHNob3VsZCBub3Qg
cmVseSBvbiB0aGUgdHlwZSBvZiB0aGUKZGV2aWNlLgoKPiBUaGUgc2VxdWVuY2Ugb2YgZXZlbnRz
IGZvciB2aWZzIHdpdGggYSBrZXJuZWwtbGV2ZWwgYmFja2VuZCBuZWVkcwo+IHRvIGdvIGxpa2Ug
dGhpczoKPiDCoCogdG9vbHN0YWNrIHRlbGxzIGJhY2tlbmQgZG9tYWluIHRvIGNyZWF0ZSB2aWYs
IHZpYSB4ZW5zdG9yZQoKSG93IGRvZXMgdGhlIHRvb2xzdGFjayB0ZWxsIGEgZG9tYWluIHRvIGNy
ZWF0ZSBhIGRldmljZT8gQ3JlYXRpbmcgYQp4ZW5zdG9yZSBlbnRyeSBsaWtlOgoKL2xvY2FsL2Rv
bWFpbi88ZG9taWQ+L2JhY2tlbmQvdmlmLy4uLgoKZG9lcyB0cmlnZ2VyIHRoZSBjcmVhdGlvbiBv
ZiBhIHZpZiBpbnRlcmZhY2UgaW4gdGhlIDxkb21pZD4gZG9tYWluPwoKPiDCoCogYmFja2VuZCBr
ZXJuZWwgY3JlYXRlcyBhIHZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgdmlmTk4KPiDCoCogc29t
ZXRoaW5nIGluIGJhY2tlbmQgZG9tYWluIG5vdGljZXMgdGhhdCB0aGlzIHZpZk5OCj4gwqAgwqBo
YXMgYXBwZWFyZWQgYW5kIGNvbnNlcXVlbnRseQoKVGhpcyBzaG91bGQgYmUgaGFuZGxlZCBieSB4
ZW5iYWNrZW5kZCAoSSBrbm93IGl0IHdpbGwgbm90IGV4YWN0bHkgYmUKeGVuYmFja2VuZGQsIGJ1
dCBsZXQncyBjYWxsIGl0IHRoYXQgd2F5IHRvIHNpbXBsaWZ5IHRoaW5ncyksIHNpbmNlIGl0CnNo
b3VsZCBiZSBsaXN0ZW5pbmcgdG8gL2xvY2FsL2RvbWFpbi88ZG9taWQ+L2JhY2tlbmQvKiBmb3Ig
Y2hhbmdlcyBhbmQKcmVhY3QgdXBvbiB0aGVtLgoKPiDCoCogZGV2aWNlIHNldHVwIHNjcmlwdCBy
dW5zLCBlbnNsYXZlcyB2aWZOTiB0byBicmlkZ2UsIGFkZHMKPiDCoCDCoGl0IHRvIHJvdXRpbmcg
dGFibGVzLCBnaXZlcyBpdCBhbiBhZGRyZXNzLCBldGMuCgpIYW5kbGVkIGJ5IGhvdHBsdWcgc2Ny
aXB0cy4KCj4gwqAqIHNvbWV0aGluZyBpbiBiYWNrZW5kIGRvbWFpbiBkb21haW4gdGVsbHMgdG9v
bHN0YWNrIHZpZiBpcyByZWFkeQoKSG90cGx1ZyBzY3JpcHRzIHNob3VsZCBjaGFuZ2UgYmFja2Vu
ZCBzdGF0ZSAoYW5kIHdyaXRlIHRoZSBhcHByb3ByaWF0ZQp2YWx1ZXMpIHRvIG5vdGlmeSBldmVy
eXRoaW5nIHdoZW4gb2suIFNpbmNlIHhlbmJhY2tlbmRkIGlzIHRoZSBvbmUKdGhhdCBleGVjdXRl
cyB0aGUgc2NyaXB0cywgaXQgc2hvdWxkIGV4YW1pbmUgdGhlIGV4aXQgY29kZSBvZiB0aGUKY2Fs
bGVkIGhvdHBsdWcgc2NyaXB0IGFuZCB3cml0ZSB0aGUgZXhpdCBzdGF0dXMgY29kZSBhbmQgbWVz
c2FnZSBpZgpob3RwbHVnIHNjcmlwdCBleGVjdXRpb24gaXMgbm90IHN1Y2Nlc3NmdWwuIFRoaXMg
dmFsdWVzIGNhbiBiZQpyZXRyaWV2ZWQgZnJvbSB0aGUgdG9vbHN0YWNrIGFuZCBub3RpZnkgdGhl
IHVzZXIgaWYgc29tZXRoaW5nIGZhaWxlZC4KCj4gwqBbIGRldmljZSBpcyB1c2VkIF0KPiDCoCog
dG9vbHN0YWNrIHRlbGxzIGJhY2tlbmQgZG9tYWluIHRvIGRlc3Ryb3kgdmlmOyBwZXJoYXBzIGVu
dGlyZQo+IMKgIMKgeGVuc3RvcmUgZGlyZWN0b3J5IGlzIGZvcmNpYmx5IHJlbW92ZWQ/PwoKSWYg
ZW50aXJlIHhlbnN0b3JlIGRpcmVjdG9yeSBpcyBmb3JjaWJseSByZW1vdmVkLCBob3cgZG9lcyB4
ZW5iYWNrZW5kZAprbm93IHRoZSBwYXJhbWV0ZXJzIHRvIHBhc3MgdG8gdGhlIGhvdHBsdWcgc2Ny
aXB0IHRvIHNodXRkb3duIHRoZQpkZXZpY2U/IERvIHdlIGhhdmUgdG8ga2VlcCBhIGNvcHkgb2Yg
dGhpcyBzb21ld2hlcmUgZWxzZSAoeGVuc3RvcmUgb3IKY3JlYXRlIGEgeGVuYmFja2VuZGQgcHJp
dmF0ZSBkYXRhYmFzZSk/CgpIZXJlIHdlIGhhdmUgdHdvIGNhc2VzLCB3aGV0aGVyIGl0IGlzIGEg
c2h1dGRvd24gb3IgYSBkZXN0cm95OgoKV2hlbiBkb2luZyBhIHNodXRkb3duIHRoZSB0b29sc3Rh
Y2sgc2hvdWxkIHdhaXQgdG8gZ2V0IGEgbm90aWZpY2F0aW9uCmZyb20gdGhlIGRyaXZlciBkb21h
aW4gdGhhdCBob3RwbHVnIGV4ZWN1dGlvbiB3YXMgZG9uZSAoZWl0aGVyCnN1Y2Nlc3NmdWxseSBv
ciBub3QpIGFuZCB0aGVuIHByb2NlZWQgd2l0aCB0aGUgcmVtb3ZhbCBvZiB4ZW5zdG9yZQpkaXJl
Y3RvcnkuCgpEb21VIGNsb3NlcyBkZXZpY2UgLS0+IGRyaXZlciBkb21haW4gbm90aWNlcyAtLT4g
ZXhlY3V0aW9uIG9mIGhvdHBsdWcKc2NyaXB0cyAtLT4gd3JpdGUgcmVzdWx0IHRvIHhlbnN0b3Jl
IC0tPiB0b29sc3RhY2sgcmVhZHMgcmVzdWx0cyBvZgpob3RwbHVnIHRlYXJkb3duLgoKV2hlbiBk
b2luZyBhIGRlc3Ryb3ksIHRoZSB0b29sc3RhY2sgc2hvdWxkIG1hbnVhbGx5IHNldCB0aGUgZnJv
bnRlbmQKc3RhdGUgdG8gY2xvc2VkLCBhbmQgdGh1cyBmb3JjZSB0aGUgZXhlY3V0aW9uIG9mIGhv
dHBsdWcgc2NyaXB0cyBpbgp0aGUgZHJpdmVyIGRvbWFpbj8gSSBrbm93IHRoaXMgaGFzIGJlZW4g
YSBjYXVzZSBvZiBkaXNjdXNzaW9uIGluCnByZXZpb3VzIHBhdGNoZXMsIGJ1dCBJIHJlYWxseSBk
b24ndCBzZWUgdGhlIHByb2JsZW0gd2l0aCBtb2RpZnlpbmcKdGhlIGZyb250ZW5kIHN0YXR1cyBp
ZiB0aGUgZG9tYWluIGlzIGFscmVhZHkgZGVhZCwgaXQncyBqdXN0IGEgd2F5IHRvCmZvcmNlIHRo
ZSB1bnBsdWcgb2YgdGhlIGRldmljZSBhbmQgdGhlIGV4ZWN1dGlvbiBvZiBob3RwbHVnIHNjcmlw
dHMuCk5vcm1hbGx5IHRoZSBEb21VIHNob3VsZCBzZXQgdGhlIGZyb250ZW5kIHN0YXR1cyB0byBj
bG9zZWQsIGJ1dCBzaW5jZQp3ZSBraWxsZWQgaXQgZnJvbSB0aGUgdG9vbHN0YWNrLCBpdCBzaG91
bGQgYmUgdGhlIHRvb2xzdGFjayBpdHNlbGYgdGhlCm9uZSBpbiBjaGFyZ2Ugb2Ygc2V0dGluZyB0
aGUgc3RhdHVzIHRvIGNsb3NlZC4KCnRvb2xzdGFjayBraWxscyBkb21haW4gLS0+IHRvb2xzdGFj
ayBzZXRzIGZyb250ZW5kIHN0YXR1cyB0byBjbG9zZWQKLS0+IGRyaXZlciBkb21haW4ga2VybmVs
IG5vdGljZXMgZnJvbnRlbmQgY2hhbmdlIGFuZCBjbG9zZXMgYmFja2VuZAotLT4geGVuYmFja2Vu
ZGQgbm90aWNpZXMgY2hhbmdlIC0tPiBleGVjdXRpb24gb2YgaG90cGx1ZyBzY3JpcHRzIC0tPgp3
cml0ZSByZXN1bHRzIHRvIHhlbnN0b3JlIC0tPiB0b29sc3RhY2sgcmVhZHMgcmVzdWx0cyBvZiBo
b3RwbHVnCnRlYXJkb3duLgoKPiDCoCogYmFja2VuZCBrZXJuZWwgcmVtb3ZlcyB2aXJ0dWFsIG5l
dHdvcmsgaW50ZXJmYWNlIGltbWVkaWF0ZWx5Cj4gwqAgwqBhbmQgYWxsIHJvdXRlcywgYnJpZGdl
IGVuc2xhdmVtZW50cywgZXRjLiwgYXJlIHVuZG9uZQo+IMKgKiBzb21ldGhpbmcgaW4gYmFja2Vu
ZCBub3RpY2VzIHRoZSByZW1vdmFsCj4gwqAqIGRldmljZSB0ZWFyZG93biBzY3JpcHQgbWF5IG5l
ZWQgdG8gcmVtb3ZlIGVnIGZpcmV3YWxsIHJ1bGVzCj4gwqAqIHdoZW4gdGhpcyBpcyBjb21wbGV0
ZSwgdGhlIGJhY2tlbmQgZG9tYWluIG5vdGlmaWVzIHRoZQo+IMKgIMKgdG9vbHN0YWNrIChob3c/
PykKClNob3VsZCB0aGUgdG9vbHN0YWNrIHdhaXQgZm9yIGEgbm90aWZpY2F0aW9uIGZyb20gdGhl
IGRyaXZlciBkb21haW4/IEkKdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIHRvb2xzdGFj
ayBpcyBhbHdheXMgYXdhcmUgb2Ygd2hhdApoYXBwZW5zIGluIHRoZSBkcml2ZXIgZG9tYWluLCBh
bmQgaXQgc2hvdWxkIHdhaXQgZm9yIHRoZSBleGVjdXRpb24gb2YKdGhlIHRlYXJkb3duIGhvdHBs
dWcgc2NyaXB0cyBhbmQgY2F0Y2ggaXQncyByZXN1bHRzLCB0byBub3RpZnkgdGhlCnVzZXIgaWYg
aXQgaXMgbm90IHN1Y2Nlc3NmdWwuCgo+IEZvciBibG9jayBkZXZpY2VzIHdpdGggYSBrZXJuZWwt
bGV2ZWwgYmFja2VuZDoKPiDCoCogdG9vbHN0YWNrIHRlbGxzIGJhY2tlbmQgZG9tYWluIHRvIGNy
ZWF0ZSB2YmQKPiDCoCDCoHBhcmFtZXRlcnMgaW5jbHVkZTogdmJkIG51bWJlciwgdGFyZ2V0Pz8s
IHNjcmlwdD8/Cj4gwqAqIHNvbWV0aGluZyBpbiBiYWNrZW5kIGRvbWFpbiBub3RpY2VzIHRoaXMg
YW5kIGNvbnNlcXVlbnRseQo+IMKgKiBkZXZpY2Ugc2V0dXAgc2NyaXB0IHJ1bnMsIGNyZWF0ZXMg
YSBzdWl0YWJsZSBhY3R1YWwKPiDCoCDCoGJsb2NrIGRldmljZSBpbiBiYWNrZW5kIGRvbWFpbgo+
IMKgKiBiYWNrZW5kIGtlcm5lbCBwaWNrcyB1cCBhY3R1YWwgYmxvY2sgZGV2aWNlIGRldGFpbHMg
YW5kCj4gwqAgwqBiZWNvbWVzIGF2YWlsYWJsZSB0byBndWVzdAo+IMKgKiBzb21ldGhpbmcgaW4g
YmFja2VuZCBkb21haW4gdGVsbHMgdGhlIHRvb2xzdGFjayBhbGwgaXMgd2VsbAo+IMKgWyBkZXZp
Y2UgaXMgdXNlZCBdCj4gwqAqIHRvb2xzdGFjayB0ZWxscyBiYWNrZW5kIGRvbWFpbiB0byBkZXN0
cm95IHZiZDsgcGVyaGFwcyBlbnRpcmUKPiDCoCDCoHhlbnN0b3JlIGRpcmVjdG9yeSBpcyBmb3Jj
aWJseSByZW1vdmVkPz8KPiDCoCogYmFja2VuZCBrZXJuZWwgcmVtb3ZlcyBpdHMgYWN0dWFsIGJh
Y2tlbmQgYW5kIGNsb3NlcyB0aGUKPiDCoCDCoGJsb2NrIGRldmljZSwgYW5kIHNvbWVob3cgbm90
aWZpZXMgdXNlcnNwYWNlIHdoZW4gdGhpcwo+IMKgIMKgaXMgZG9uZSBzbyB0aGF0Cj4gwqAqIGRl
dmljZSB0ZWFyZG93biBzY3JpcHQgY2xlYW5zIHVwLCBpbmNsdWRpbmcgbWFraW5nIGFjdHVhbAo+
IMKgIMKgYmxvY2sgZGV2aWNlIGdvIGF3YXkgKGlmIGl0IHdhcyBvbmUgd2hpY2ggdGhlIHNldHVw
IHNjcmlwdAo+IMKgIMKgY3JlYXRlZCkKPiDCoCogd2hlbiB0aGlzIGlzIGNvbXBsZXRlLCB0aGUg
YmFja2VuZCBkb21haW4gbm90aWZpZXMgdGhlCj4gwqAgwqB0b29sc3RhY2sgKGhvdz8/KQo+Cj4g
Rm9yIGJsb2NrIGRldmljZXMgd2l0aCBhIHVzZXItbGV2ZWwgYmFja2VuZDoKPiDCoCogdG9vbHN0
YWNrIHRlbGxzIGJhY2tlbmQgZG9tYWluIHRvIGNyZWF0ZSB2YmQKPiDCoCDCoHBhcmFtZXRlcnMg
aW5jbHVkZTogdmJkIG51bWJlciwgdGFyZ2V0Pz8sIHNjcmlwdD8/Cj4gwqAqIHVzZXJsYW5kIGJh
Y2tlbmQgbm90aWNlcyB0aGlzLCBkb2VzIGl0cyBob3VzZWtlZXBpbmcKPiDCoCDCoGFuZCBzZXR1
cCwgYW5kIHRlbGxzIHRoZSB0b29sc3RhY2sgYWxsIGlzIHdlbGwKPiDCoFsgZGV2aWNlIGlzIHVz
ZWQgXQo+IMKgKiB0b29sc3RhY2sgdGVsbHMgYmFja2VuZCBkb21haW4gdG8gZGVzdHJveSB2YmQ7
IHBlcmhhcHMgZW50aXJlCj4gwqAgwqB4ZW5zdG9yZSBkaXJlY3RvcnkgaXMgZm9yY2libHkgcmVt
b3ZlZD8/Cj4gwqAqIHVzZXJsYW5kIGJhY2tlbmQgcmVtb3ZlcyBpdHMgYWN0dWFsIGJhY2tlbmQg
YW5kIGNsb3NlcyB0aGUKPiDCoCDCoHJlc291cmNlcyBpdCB3YXMgdXNpbmcsIGFuZAo+IMKgKiBu
b3RpZmllcyB0aGUgdG9vbHN0YWNrIChob3c/PykKCldoZW4gaXQgY29tZXMgdG8gYmxvY2sgaG90
cGx1ZyBzY3JpcHRzLCB3ZSBoYXZlIHRvIGxldCB4ZW5iYWNrZW5kZApkZWNpZGUgd2hpY2gga2lu
ZCBvZiBiYWNrZW5kIHRvIHVzZSwgc28gd2Ugc2hvdWxkIGFncmVlIG9uIHdoYXQgdG8Kd3JpdGUg
dG8geGVuc3RvcmUgdGhhdCBjYW4gY292ZXIgYWxsIHR5cGVzIG9mIGJsb2NrIGJhY2tlbmRzIChw
aHksCnFkaXNrLCBibGt0YXAuLi4pLCBzaW5jZSB0aGUgdG9vbHN0YWNrIHByb2JhYmx5IGRvZXNu
J3QgaGF2ZSBhY2Nlc3MgdG8KdGhlIHJlcXVlc3RlZCBtZWRpdW0uCgo+IE11Y2ggb2YgdGhpcyBz
ZWVtcyB0byBiZSBjb3ZlcmVkIGJ5LCBvciBjb3ZlcmFibGUgYnksIHRoZSBleGlzdGluZwo+IHhl
bnN0b3JlIHByb3RvY29sLiDCoEkgdGhpbmsgd2UganVzdCBuZWVkIHRvIGRlZmluZSBpbiBtb3Jl
IGRldGFpbAo+IGV4YWN0bHkgaG93IGl0IHNob3VsZCBhbGwgd29yaywgYW5kIG9uIGVhY2ggcGxh
dGZvcm0gaG93IHRoZQo+ICJzb21ldGhpbmcicyB3b3JrLgo+Cj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:08:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 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 1RkC9b-0007at-Ed; Mon, 09 Jan 2012 10:08:35 +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 1RkC9a-0007ac-J5
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:08:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326103706!9646596!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 8856 invoked from network); 9 Jan 2012 10:08:27 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 10:08:27 -0000
Received: by pbbb11 with SMTP id b11so14846097pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 02:08: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=nP8nXEifIVQVhEOhBBH0Ni5AhFQemtXmwsgOAK4FtuQ=;
	b=eUqte9aBmIX4Qt3kc510vDGwaQL0xGDcXaPz/S6jBv8f0XpT66+SIhdkETv3/MQRbN
	KxMNv2RtuTt46+n40tUd3DTxHSmG91TxZ6QcGsgYM6Z7yD74a7E2/ooFlw8e0uzFhtXK
	58W5+Ae7tW5q5oWwu6xVvLXYdAEUCBc7uFtGw=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr40275605pbc.77.1326103705947; Mon,
	09 Jan 2012 02:08:25 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 9 Jan 2012 02:08:25 -0800 (PST)
In-Reply-To: <20229.59079.535980.830271@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
Date: Mon, 9 Jan 2012 11:08:25 +0100
X-Google-Sender-Auth: ImayB3DsF2D7Uv9DZqCbYIhJeCo
Message-ID: <CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@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 <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzUgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IFJvZ2Vy
IFBhdSBNb25uw6kgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIFJGQzogU3RpbGwgVE9ETyBmb3Ig
NC4yPyIpOgo+PiBJIGRvbid0IGtub3cgbXVjaCBhYm91dCBkcml2ZXIgZG9tYWlucywgYnV0IGZy
b20gd2hhdCBJJ3ZlIHJlYWQgdGhleQo+PiBzaG91bGQgYmUgcnVubmluZyBzb21ldGhpbmcgbGlr
ZSBOZXRCU0QgeGVuYmFja2VuZCBhbmQgbGlzdGVuIGZvcgo+PiB4ZW5zdG9yZSBldmVudHMuIE1v
c3Qgb2YgdGhlIGZ1bmN0aW9ucyB0aGF0IEkndmUgd3JpdHRlbiBvbiBteSBob3RwbHVnCj4+IHNl
cmllcyBjYW4gYmUgdXNlZCB0byBjcmVhdGUgYSBsaXR0bGUgZGFlbW9uLCB0aGF0J3Mgbm90IHRo
ZSBwcm9ibGVtLAo+PiB0aGUgcHJvYmxlbSBpcyB3aGF0IGNhbiB3ZSB1c2UgdG8gc3luY2hyb25p
emUgaG90cGx1ZyBzY3JpcHQgY2FsbGluZwo+PiBhbmQgbGlieGwgKHdoYXQgY29tZXMgdG8gbWlu
ZCBpcyB1c2luZyBhIGRlZGljYXRlZCB4ZW5zdG9yZSB2YXJpYWJsZQo+PiBmb3IgZWFjaCBkZXZp
Y2UsIGJ1dCBzb21lb25lIG1pZ2h0IGhhdmUgYSBiZXR0ZXIgaWRlYSkuCgpTb3JyeSBJIGRpZG4n
dCByZXBseSBlYXJsaWVyLCBJIHdhcyBzdGlsbCBvbiBob2xpZGF5cyAobW9zdGx5IHdvcmtpbmcK
d2l0aCB0aGUgYXV0b3Rvb2xzIHN0dWZmKS4KCj4gVGhpcyBlbnZpc2FnZXMgZGV2aWNlciBzZXR1
cC90ZWFyZG93biBzY3JpcHRzIGluIGRyaXZlciBkb21haW5zCj4gcnVubmluZyBpbiBhIGRpZmZl
cmVudCB3YXkgdG8gdGhvc2UgaW4gdGhlIHNhbWUgZG9tYWluIGFzIHRoZQo+IHRvb2xzdGFjay4g
wqBBcmUgd2Ugc3VyZSB0aGlzIGlzIGEgZ29vZCBpZGVhID8KCk5vLCBJIHRoaW5rIGl0J3MgYmVz
dCB0aGF0IGV2ZW4gaXMgdGhlIGRyaXZlciBkb21haW4gaXMgRG9tMCB0aGUgc2FtZQpwcm9jZWR1
cmUgc2hvdWxkIGJlIGV4ZWN1dGVkLCBhbmQgeGVuYmFja2VuZGQgc2hvdWxkIGJlIHJ1bm5pbmcg
aW4KZXZlcnkgZHJpdmVyIGRvbWFpbiwgRG9tMCBpbmNsdWRlZCwgdG9vbHN0YWNrIHNob3VsZCBu
ZXZlciBleGVjdXRlCmhvdHBsdWcgc2NyaXB0cyBkaXJlY3RseS4KCj4gSSB0aGluayBpdCB3b3Vs
ZCBiZSBwcmVmZXJhYmxlIHRvIGhhdmUgb25seSBvbmUgaW50ZXJmYWNlIHRvIGRldmljZQo+IHNj
cmlwdHMsIHdoaWNoIGlzIHVzZWQgZXZlcnl3aGVyZS4gwqBUaGF0IGludGVyZmFjZSB3b3VsZCBo
YXZlIHRvCj4gaW52b2x2ZSBpbml0aWF0aW9uIGJ5IHRoZSB0b29sc3RhY2ssIGFuZCBjb2xsZWN0
aW9uIG9mIHJlc3VsdGluZwo+IHN1Y2Nlc3MvZmFpbHVyZS9ldGMuLCB2aWEgeGVuc3RvcmUuCgpB
cmUgd2Ugb25seSBnb2luZyB0byB1c2UgeGVuc3RvcmUgdG8gc2hhcmUgaW5mb3JtYXRpb24gYmV0
d2VlbiBib3RoCmRvbWFpbnMgKERvbTAgPC0tPiBEcml2ZXIgZG9tYWluKT8KCkknbSBnb2luZyB0
byBjb21tZW50IHRoZSB2aWYgY2FzZSwgYnV0IEkgdGhpbmsgYm90aCB2aWYgYW5kIGJsb2NrCmRl
dmljZXMgc2hvdWxkIGZvbGxvdyB0aGUgc2FtZSBhcHByb2FjaCwgYW5kIGhvdHBsdWcgc2NyaXB0
IGV4ZWN1dGlvbgpoYXMgdG8gYmUgc29tZXRoaW5nICJzdGFuZGFyZCIgYW5kIHNob3VsZCBub3Qg
cmVseSBvbiB0aGUgdHlwZSBvZiB0aGUKZGV2aWNlLgoKPiBUaGUgc2VxdWVuY2Ugb2YgZXZlbnRz
IGZvciB2aWZzIHdpdGggYSBrZXJuZWwtbGV2ZWwgYmFja2VuZCBuZWVkcwo+IHRvIGdvIGxpa2Ug
dGhpczoKPiDCoCogdG9vbHN0YWNrIHRlbGxzIGJhY2tlbmQgZG9tYWluIHRvIGNyZWF0ZSB2aWYs
IHZpYSB4ZW5zdG9yZQoKSG93IGRvZXMgdGhlIHRvb2xzdGFjayB0ZWxsIGEgZG9tYWluIHRvIGNy
ZWF0ZSBhIGRldmljZT8gQ3JlYXRpbmcgYQp4ZW5zdG9yZSBlbnRyeSBsaWtlOgoKL2xvY2FsL2Rv
bWFpbi88ZG9taWQ+L2JhY2tlbmQvdmlmLy4uLgoKZG9lcyB0cmlnZ2VyIHRoZSBjcmVhdGlvbiBv
ZiBhIHZpZiBpbnRlcmZhY2UgaW4gdGhlIDxkb21pZD4gZG9tYWluPwoKPiDCoCogYmFja2VuZCBr
ZXJuZWwgY3JlYXRlcyBhIHZpcnR1YWwgbmV0d29yayBpbnRlcmZhY2UgdmlmTk4KPiDCoCogc29t
ZXRoaW5nIGluIGJhY2tlbmQgZG9tYWluIG5vdGljZXMgdGhhdCB0aGlzIHZpZk5OCj4gwqAgwqBo
YXMgYXBwZWFyZWQgYW5kIGNvbnNlcXVlbnRseQoKVGhpcyBzaG91bGQgYmUgaGFuZGxlZCBieSB4
ZW5iYWNrZW5kZCAoSSBrbm93IGl0IHdpbGwgbm90IGV4YWN0bHkgYmUKeGVuYmFja2VuZGQsIGJ1
dCBsZXQncyBjYWxsIGl0IHRoYXQgd2F5IHRvIHNpbXBsaWZ5IHRoaW5ncyksIHNpbmNlIGl0CnNo
b3VsZCBiZSBsaXN0ZW5pbmcgdG8gL2xvY2FsL2RvbWFpbi88ZG9taWQ+L2JhY2tlbmQvKiBmb3Ig
Y2hhbmdlcyBhbmQKcmVhY3QgdXBvbiB0aGVtLgoKPiDCoCogZGV2aWNlIHNldHVwIHNjcmlwdCBy
dW5zLCBlbnNsYXZlcyB2aWZOTiB0byBicmlkZ2UsIGFkZHMKPiDCoCDCoGl0IHRvIHJvdXRpbmcg
dGFibGVzLCBnaXZlcyBpdCBhbiBhZGRyZXNzLCBldGMuCgpIYW5kbGVkIGJ5IGhvdHBsdWcgc2Ny
aXB0cy4KCj4gwqAqIHNvbWV0aGluZyBpbiBiYWNrZW5kIGRvbWFpbiBkb21haW4gdGVsbHMgdG9v
bHN0YWNrIHZpZiBpcyByZWFkeQoKSG90cGx1ZyBzY3JpcHRzIHNob3VsZCBjaGFuZ2UgYmFja2Vu
ZCBzdGF0ZSAoYW5kIHdyaXRlIHRoZSBhcHByb3ByaWF0ZQp2YWx1ZXMpIHRvIG5vdGlmeSBldmVy
eXRoaW5nIHdoZW4gb2suIFNpbmNlIHhlbmJhY2tlbmRkIGlzIHRoZSBvbmUKdGhhdCBleGVjdXRl
cyB0aGUgc2NyaXB0cywgaXQgc2hvdWxkIGV4YW1pbmUgdGhlIGV4aXQgY29kZSBvZiB0aGUKY2Fs
bGVkIGhvdHBsdWcgc2NyaXB0IGFuZCB3cml0ZSB0aGUgZXhpdCBzdGF0dXMgY29kZSBhbmQgbWVz
c2FnZSBpZgpob3RwbHVnIHNjcmlwdCBleGVjdXRpb24gaXMgbm90IHN1Y2Nlc3NmdWwuIFRoaXMg
dmFsdWVzIGNhbiBiZQpyZXRyaWV2ZWQgZnJvbSB0aGUgdG9vbHN0YWNrIGFuZCBub3RpZnkgdGhl
IHVzZXIgaWYgc29tZXRoaW5nIGZhaWxlZC4KCj4gwqBbIGRldmljZSBpcyB1c2VkIF0KPiDCoCog
dG9vbHN0YWNrIHRlbGxzIGJhY2tlbmQgZG9tYWluIHRvIGRlc3Ryb3kgdmlmOyBwZXJoYXBzIGVu
dGlyZQo+IMKgIMKgeGVuc3RvcmUgZGlyZWN0b3J5IGlzIGZvcmNpYmx5IHJlbW92ZWQ/PwoKSWYg
ZW50aXJlIHhlbnN0b3JlIGRpcmVjdG9yeSBpcyBmb3JjaWJseSByZW1vdmVkLCBob3cgZG9lcyB4
ZW5iYWNrZW5kZAprbm93IHRoZSBwYXJhbWV0ZXJzIHRvIHBhc3MgdG8gdGhlIGhvdHBsdWcgc2Ny
aXB0IHRvIHNodXRkb3duIHRoZQpkZXZpY2U/IERvIHdlIGhhdmUgdG8ga2VlcCBhIGNvcHkgb2Yg
dGhpcyBzb21ld2hlcmUgZWxzZSAoeGVuc3RvcmUgb3IKY3JlYXRlIGEgeGVuYmFja2VuZGQgcHJp
dmF0ZSBkYXRhYmFzZSk/CgpIZXJlIHdlIGhhdmUgdHdvIGNhc2VzLCB3aGV0aGVyIGl0IGlzIGEg
c2h1dGRvd24gb3IgYSBkZXN0cm95OgoKV2hlbiBkb2luZyBhIHNodXRkb3duIHRoZSB0b29sc3Rh
Y2sgc2hvdWxkIHdhaXQgdG8gZ2V0IGEgbm90aWZpY2F0aW9uCmZyb20gdGhlIGRyaXZlciBkb21h
aW4gdGhhdCBob3RwbHVnIGV4ZWN1dGlvbiB3YXMgZG9uZSAoZWl0aGVyCnN1Y2Nlc3NmdWxseSBv
ciBub3QpIGFuZCB0aGVuIHByb2NlZWQgd2l0aCB0aGUgcmVtb3ZhbCBvZiB4ZW5zdG9yZQpkaXJl
Y3RvcnkuCgpEb21VIGNsb3NlcyBkZXZpY2UgLS0+IGRyaXZlciBkb21haW4gbm90aWNlcyAtLT4g
ZXhlY3V0aW9uIG9mIGhvdHBsdWcKc2NyaXB0cyAtLT4gd3JpdGUgcmVzdWx0IHRvIHhlbnN0b3Jl
IC0tPiB0b29sc3RhY2sgcmVhZHMgcmVzdWx0cyBvZgpob3RwbHVnIHRlYXJkb3duLgoKV2hlbiBk
b2luZyBhIGRlc3Ryb3ksIHRoZSB0b29sc3RhY2sgc2hvdWxkIG1hbnVhbGx5IHNldCB0aGUgZnJv
bnRlbmQKc3RhdGUgdG8gY2xvc2VkLCBhbmQgdGh1cyBmb3JjZSB0aGUgZXhlY3V0aW9uIG9mIGhv
dHBsdWcgc2NyaXB0cyBpbgp0aGUgZHJpdmVyIGRvbWFpbj8gSSBrbm93IHRoaXMgaGFzIGJlZW4g
YSBjYXVzZSBvZiBkaXNjdXNzaW9uIGluCnByZXZpb3VzIHBhdGNoZXMsIGJ1dCBJIHJlYWxseSBk
b24ndCBzZWUgdGhlIHByb2JsZW0gd2l0aCBtb2RpZnlpbmcKdGhlIGZyb250ZW5kIHN0YXR1cyBp
ZiB0aGUgZG9tYWluIGlzIGFscmVhZHkgZGVhZCwgaXQncyBqdXN0IGEgd2F5IHRvCmZvcmNlIHRo
ZSB1bnBsdWcgb2YgdGhlIGRldmljZSBhbmQgdGhlIGV4ZWN1dGlvbiBvZiBob3RwbHVnIHNjcmlw
dHMuCk5vcm1hbGx5IHRoZSBEb21VIHNob3VsZCBzZXQgdGhlIGZyb250ZW5kIHN0YXR1cyB0byBj
bG9zZWQsIGJ1dCBzaW5jZQp3ZSBraWxsZWQgaXQgZnJvbSB0aGUgdG9vbHN0YWNrLCBpdCBzaG91
bGQgYmUgdGhlIHRvb2xzdGFjayBpdHNlbGYgdGhlCm9uZSBpbiBjaGFyZ2Ugb2Ygc2V0dGluZyB0
aGUgc3RhdHVzIHRvIGNsb3NlZC4KCnRvb2xzdGFjayBraWxscyBkb21haW4gLS0+IHRvb2xzdGFj
ayBzZXRzIGZyb250ZW5kIHN0YXR1cyB0byBjbG9zZWQKLS0+IGRyaXZlciBkb21haW4ga2VybmVs
IG5vdGljZXMgZnJvbnRlbmQgY2hhbmdlIGFuZCBjbG9zZXMgYmFja2VuZAotLT4geGVuYmFja2Vu
ZGQgbm90aWNpZXMgY2hhbmdlIC0tPiBleGVjdXRpb24gb2YgaG90cGx1ZyBzY3JpcHRzIC0tPgp3
cml0ZSByZXN1bHRzIHRvIHhlbnN0b3JlIC0tPiB0b29sc3RhY2sgcmVhZHMgcmVzdWx0cyBvZiBo
b3RwbHVnCnRlYXJkb3duLgoKPiDCoCogYmFja2VuZCBrZXJuZWwgcmVtb3ZlcyB2aXJ0dWFsIG5l
dHdvcmsgaW50ZXJmYWNlIGltbWVkaWF0ZWx5Cj4gwqAgwqBhbmQgYWxsIHJvdXRlcywgYnJpZGdl
IGVuc2xhdmVtZW50cywgZXRjLiwgYXJlIHVuZG9uZQo+IMKgKiBzb21ldGhpbmcgaW4gYmFja2Vu
ZCBub3RpY2VzIHRoZSByZW1vdmFsCj4gwqAqIGRldmljZSB0ZWFyZG93biBzY3JpcHQgbWF5IG5l
ZWQgdG8gcmVtb3ZlIGVnIGZpcmV3YWxsIHJ1bGVzCj4gwqAqIHdoZW4gdGhpcyBpcyBjb21wbGV0
ZSwgdGhlIGJhY2tlbmQgZG9tYWluIG5vdGlmaWVzIHRoZQo+IMKgIMKgdG9vbHN0YWNrIChob3c/
PykKClNob3VsZCB0aGUgdG9vbHN0YWNrIHdhaXQgZm9yIGEgbm90aWZpY2F0aW9uIGZyb20gdGhl
IGRyaXZlciBkb21haW4/IEkKdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIHRvb2xzdGFj
ayBpcyBhbHdheXMgYXdhcmUgb2Ygd2hhdApoYXBwZW5zIGluIHRoZSBkcml2ZXIgZG9tYWluLCBh
bmQgaXQgc2hvdWxkIHdhaXQgZm9yIHRoZSBleGVjdXRpb24gb2YKdGhlIHRlYXJkb3duIGhvdHBs
dWcgc2NyaXB0cyBhbmQgY2F0Y2ggaXQncyByZXN1bHRzLCB0byBub3RpZnkgdGhlCnVzZXIgaWYg
aXQgaXMgbm90IHN1Y2Nlc3NmdWwuCgo+IEZvciBibG9jayBkZXZpY2VzIHdpdGggYSBrZXJuZWwt
bGV2ZWwgYmFja2VuZDoKPiDCoCogdG9vbHN0YWNrIHRlbGxzIGJhY2tlbmQgZG9tYWluIHRvIGNy
ZWF0ZSB2YmQKPiDCoCDCoHBhcmFtZXRlcnMgaW5jbHVkZTogdmJkIG51bWJlciwgdGFyZ2V0Pz8s
IHNjcmlwdD8/Cj4gwqAqIHNvbWV0aGluZyBpbiBiYWNrZW5kIGRvbWFpbiBub3RpY2VzIHRoaXMg
YW5kIGNvbnNlcXVlbnRseQo+IMKgKiBkZXZpY2Ugc2V0dXAgc2NyaXB0IHJ1bnMsIGNyZWF0ZXMg
YSBzdWl0YWJsZSBhY3R1YWwKPiDCoCDCoGJsb2NrIGRldmljZSBpbiBiYWNrZW5kIGRvbWFpbgo+
IMKgKiBiYWNrZW5kIGtlcm5lbCBwaWNrcyB1cCBhY3R1YWwgYmxvY2sgZGV2aWNlIGRldGFpbHMg
YW5kCj4gwqAgwqBiZWNvbWVzIGF2YWlsYWJsZSB0byBndWVzdAo+IMKgKiBzb21ldGhpbmcgaW4g
YmFja2VuZCBkb21haW4gdGVsbHMgdGhlIHRvb2xzdGFjayBhbGwgaXMgd2VsbAo+IMKgWyBkZXZp
Y2UgaXMgdXNlZCBdCj4gwqAqIHRvb2xzdGFjayB0ZWxscyBiYWNrZW5kIGRvbWFpbiB0byBkZXN0
cm95IHZiZDsgcGVyaGFwcyBlbnRpcmUKPiDCoCDCoHhlbnN0b3JlIGRpcmVjdG9yeSBpcyBmb3Jj
aWJseSByZW1vdmVkPz8KPiDCoCogYmFja2VuZCBrZXJuZWwgcmVtb3ZlcyBpdHMgYWN0dWFsIGJh
Y2tlbmQgYW5kIGNsb3NlcyB0aGUKPiDCoCDCoGJsb2NrIGRldmljZSwgYW5kIHNvbWVob3cgbm90
aWZpZXMgdXNlcnNwYWNlIHdoZW4gdGhpcwo+IMKgIMKgaXMgZG9uZSBzbyB0aGF0Cj4gwqAqIGRl
dmljZSB0ZWFyZG93biBzY3JpcHQgY2xlYW5zIHVwLCBpbmNsdWRpbmcgbWFraW5nIGFjdHVhbAo+
IMKgIMKgYmxvY2sgZGV2aWNlIGdvIGF3YXkgKGlmIGl0IHdhcyBvbmUgd2hpY2ggdGhlIHNldHVw
IHNjcmlwdAo+IMKgIMKgY3JlYXRlZCkKPiDCoCogd2hlbiB0aGlzIGlzIGNvbXBsZXRlLCB0aGUg
YmFja2VuZCBkb21haW4gbm90aWZpZXMgdGhlCj4gwqAgwqB0b29sc3RhY2sgKGhvdz8/KQo+Cj4g
Rm9yIGJsb2NrIGRldmljZXMgd2l0aCBhIHVzZXItbGV2ZWwgYmFja2VuZDoKPiDCoCogdG9vbHN0
YWNrIHRlbGxzIGJhY2tlbmQgZG9tYWluIHRvIGNyZWF0ZSB2YmQKPiDCoCDCoHBhcmFtZXRlcnMg
aW5jbHVkZTogdmJkIG51bWJlciwgdGFyZ2V0Pz8sIHNjcmlwdD8/Cj4gwqAqIHVzZXJsYW5kIGJh
Y2tlbmQgbm90aWNlcyB0aGlzLCBkb2VzIGl0cyBob3VzZWtlZXBpbmcKPiDCoCDCoGFuZCBzZXR1
cCwgYW5kIHRlbGxzIHRoZSB0b29sc3RhY2sgYWxsIGlzIHdlbGwKPiDCoFsgZGV2aWNlIGlzIHVz
ZWQgXQo+IMKgKiB0b29sc3RhY2sgdGVsbHMgYmFja2VuZCBkb21haW4gdG8gZGVzdHJveSB2YmQ7
IHBlcmhhcHMgZW50aXJlCj4gwqAgwqB4ZW5zdG9yZSBkaXJlY3RvcnkgaXMgZm9yY2libHkgcmVt
b3ZlZD8/Cj4gwqAqIHVzZXJsYW5kIGJhY2tlbmQgcmVtb3ZlcyBpdHMgYWN0dWFsIGJhY2tlbmQg
YW5kIGNsb3NlcyB0aGUKPiDCoCDCoHJlc291cmNlcyBpdCB3YXMgdXNpbmcsIGFuZAo+IMKgKiBu
b3RpZmllcyB0aGUgdG9vbHN0YWNrIChob3c/PykKCldoZW4gaXQgY29tZXMgdG8gYmxvY2sgaG90
cGx1ZyBzY3JpcHRzLCB3ZSBoYXZlIHRvIGxldCB4ZW5iYWNrZW5kZApkZWNpZGUgd2hpY2gga2lu
ZCBvZiBiYWNrZW5kIHRvIHVzZSwgc28gd2Ugc2hvdWxkIGFncmVlIG9uIHdoYXQgdG8Kd3JpdGUg
dG8geGVuc3RvcmUgdGhhdCBjYW4gY292ZXIgYWxsIHR5cGVzIG9mIGJsb2NrIGJhY2tlbmRzIChw
aHksCnFkaXNrLCBibGt0YXAuLi4pLCBzaW5jZSB0aGUgdG9vbHN0YWNrIHByb2JhYmx5IGRvZXNu
J3QgaGF2ZSBhY2Nlc3MgdG8KdGhlIHJlcXVlc3RlZCBtZWRpdW0uCgo+IE11Y2ggb2YgdGhpcyBz
ZWVtcyB0byBiZSBjb3ZlcmVkIGJ5LCBvciBjb3ZlcmFibGUgYnksIHRoZSBleGlzdGluZwo+IHhl
bnN0b3JlIHByb3RvY29sLiDCoEkgdGhpbmsgd2UganVzdCBuZWVkIHRvIGRlZmluZSBpbiBtb3Jl
IGRldGFpbAo+IGV4YWN0bHkgaG93IGl0IHNob3VsZCBhbGwgd29yaywgYW5kIG9uIGVhY2ggcGxh
dGZvcm0gaG93IHRoZQo+ICJzb21ldGhpbmcicyB3b3JrLgo+Cj4gSWFuLgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:10:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCB5-0007fQ-Ug; Mon, 09 Jan 2012 10:10:07 +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 1RkCB4-0007f5-F4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:10:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326103672!51000266!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 25957 invoked from network); 9 Jan 2012 10:07:52 -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; 9 Jan 2012 10:07:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkCAv-000EFL-PY; Mon, 09 Jan 2012 10:09:58 +0000
Date: Mon, 9 Jan 2012 10:09:56 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20120109100956.GE26595@ocelot.phlegethon.org>
References: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] changing attributes of a 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

Hi, 

At 10:22 +0330 on 09 Jan (1326104566), Mohamad Rezaei wrote:
> Hi,
> 
> I am trying to change attributes of a page from Dom0.

Do you mean a page of dom0's memory? 

> The reason is
> that I want to make a kernel module completely read-only to other
> parts of kernel. I will update it from hypervisor itself. I have tried
> to do this by this code:
> 
> // I have the mfn of the page in Dom0's address space.
> void hamed_set_entry(struct p2m_domain *p2m, mfn_t mfn) {
>     unsigned long gfn = mfn_to_gfn(p2m->domain,mfn);
>     p2m_type_t p2mt;
>     p2m_access_t p2ma;
>     p2m_lock(p2m);
>     p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query);
>     p2m->set_entry(p2m, gfn, mfn, 0, p2mt, p2m_access_rwx);
>     p2m_unlock(p2m);
> }

That looks plausible for a HVM guest, but dom0 is a PV guest and doesn't
have a p2m table, so you're likely to crash Xen if you try to to this
to dom0.

Do you have a serial console set up on your test machine?  It's _very_
useful for finding out why the system crashed, since Xen will usually
print a backtrace when it crashes. 

> But whenever it runs Dom0 restarts. I am not even sure this is the
> right way to do this. I am grateful for any help!

To do this to dom0 you could
 (a) get dom0 to make the memory read-only in its own pagetables; and
 (b) enforce that read-only property in the PTE validation code in mm.c

Or you could run dom0 under shadow pagetables and enforce the read-only
property in _sh_propagate().  That will have a performace hit, though. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:10:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCB5-0007fQ-Ug; Mon, 09 Jan 2012 10:10:07 +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 1RkCB4-0007f5-F4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:10:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326103672!51000266!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 25957 invoked from network); 9 Jan 2012 10:07:52 -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; 9 Jan 2012 10:07:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkCAv-000EFL-PY; Mon, 09 Jan 2012 10:09:58 +0000
Date: Mon, 9 Jan 2012 10:09:56 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20120109100956.GE26595@ocelot.phlegethon.org>
References: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] changing attributes of a 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

Hi, 

At 10:22 +0330 on 09 Jan (1326104566), Mohamad Rezaei wrote:
> Hi,
> 
> I am trying to change attributes of a page from Dom0.

Do you mean a page of dom0's memory? 

> The reason is
> that I want to make a kernel module completely read-only to other
> parts of kernel. I will update it from hypervisor itself. I have tried
> to do this by this code:
> 
> // I have the mfn of the page in Dom0's address space.
> void hamed_set_entry(struct p2m_domain *p2m, mfn_t mfn) {
>     unsigned long gfn = mfn_to_gfn(p2m->domain,mfn);
>     p2m_type_t p2mt;
>     p2m_access_t p2ma;
>     p2m_lock(p2m);
>     p2m->get_entry(p2m, gfn, &p2mt, &p2ma, p2m_query);
>     p2m->set_entry(p2m, gfn, mfn, 0, p2mt, p2m_access_rwx);
>     p2m_unlock(p2m);
> }

That looks plausible for a HVM guest, but dom0 is a PV guest and doesn't
have a p2m table, so you're likely to crash Xen if you try to to this
to dom0.

Do you have a serial console set up on your test machine?  It's _very_
useful for finding out why the system crashed, since Xen will usually
print a backtrace when it crashes. 

> But whenever it runs Dom0 restarts. I am not even sure this is the
> right way to do this. I am grateful for any help!

To do this to dom0 you could
 (a) get dom0 to make the memory read-only in its own pagetables; and
 (b) enforce that read-only property in the PTE validation code in mm.c

Or you could run dom0 under shadow pagetables and enforce the read-only
property in _sh_propagate().  That will have a performace hit, though. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCES-0007y8-TJ; Mon, 09 Jan 2012 10:13:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <theubaz@gmail.com>) id 1RiBEX-0004fW-Jw
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:45:21 +0000
X-Env-Sender: theubaz@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325623474!48898521!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27284 invoked from network); 3 Jan 2012 20:44:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 20:44:36 -0000
Received: by iagw33 with SMTP id w33so146948060iag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 12:45: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=aYwVGBG/5eLYy4HQvL0gBHQ8QENRYSVPkVFHi23ml24=;
	b=Wvr1nlfHns4u5CqxWUeQvBlk+mu3hpOQ+5nBlPRKX9KStCWCEH3f3efVPF9BLSJ4Bv
	E/rGMPdV9Sd300WBQMjkGAqqS1XkEmR78aRVET9/el11brI8usTma9YgS3Px/4FpGBhh
	4+y7hstZwiTLwgKJ9Icf51/FMM5tjDix7RA+I=
MIME-Version: 1.0
Received: by 10.50.191.200 with SMTP id ha8mr63632382igc.27.1325623517975;
	Tue, 03 Jan 2012 12:45:17 -0800 (PST)
Received: by 10.42.97.73 with HTTP; Tue, 3 Jan 2012 12:45:17 -0800 (PST)
In-Reply-To: <20120103202401.GB17472@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
Date: Tue, 3 Jan 2012 15:45:17 -0500
X-Google-Sender-Auth: QJu39kHpx83sRDwDw0__WMSuoh4
Message-ID: <CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
From: John Sherwood <jrs@vt.edu>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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="===============7647013086107137791=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7647013086107137791==
Content-Type: multipart/alternative; boundary=14dae9340fd9e512e404b5a5c6f3

--14dae9340fd9e512e404b5a5c6f3
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> > Hello,
> >
> > I'm working on a project and trying to pass through a PS/2 mouse +
> keyboard
> > to a hardware VM.  I've played with numerous things (including the
> obvious,
> > using USB), but after finding no alternative, it seems like the best way
> to
> > approach this would be to modify qemu-dm to pipe through data from
> > /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and
> then
> > using this version of qemu-dm only for this special case).
>
> That is certainly one way. But you would have an interesting problem that
> whatever
> you type on your physical keyboard would appear in the guest _and_ in the
> domain 0.
>

yeah, I actually tested it and it was quite amusing to watch the keyboard
and mouse move on the monitor and in VNC.


>
> >
> > I've been looking through the 4.1.0 source, specifically in
> > tools/ioemu-qemu-xen, and it appears that I'd want to (for the keyboard)
> > pass key codes from /dev/input through the kbd_put_keycode function.
>  From
> > what I can tell, I'd probably want to split off a thread to do this
> > somewhere in main() in vl.c.  I was hoping that I could get some
> > confirmation about whether I'm looking in the right places and/or
> > suggestions about how to cleanly implement this.  Odds are I won't be
> able
> > to go the whole 9 yards and implement configuration options for xm or
> > command line switches for qemu-dm, but I would suspect that someone,
> > somewhere, someday will also want this kind of ability.  If it's already
> > possible to pass through PS/2 devices without getting nuts in QEMU,
> that's
> > cool too :)
>
> Can't do that. The PS/2 is one of those legacy beasts that depends on
> ioports.
> But now that I think of it, maybe you can. In the guest config you can
> specify
> the ioports that you want to pass in. I hadn't tried to do this for the
> keyboard
> ports but maybe that will work for you?
>
>
I tried forwarding the ioports (off the top of my head, I remember trying
60 and 64) but didn't have any luck - the kb/mouse weren't forwarded
despite adding the requisite ioports config as per the docs.  I theorized I
was leaving off some config for the kernel, but didn't find anything.  I
agree that it certainly seems like this should work, and if you could
elaborate on anything I could have goofed on, that would certainly be great
(and hopefully, useful for anyone else who might try this in the future)


> Or could you use synergy?
>

I actually did try synergy, but I couldn't get it to work due to
requirements for the OSes that were being run.

--14dae9340fd9e512e404b5a5c6f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzesz=
utek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad.wilk@oracle.com">k=
onrad.wilk@oracle.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div class=3D"im">On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood w=
rote:<br>
&gt; Hello,<br>
&gt;<br>
&gt; I&#39;m working on a project and trying to pass through a PS/2 mouse +=
 keyboard<br>
&gt; to a hardware VM. =A0I&#39;ve played with numerous things (including t=
he obvious,<br>
&gt; using USB), but after finding no alternative, it seems like the best w=
ay to<br>
&gt; approach this would be to modify qemu-dm to pipe through data from<br>
&gt; /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and=
 then<br>
&gt; using this version of qemu-dm only for this special case).<br>
<br>
</div>That is certainly one way. But you would have an interesting problem =
that whatever<br>
you type on your physical keyboard would appear in the guest _and_ in the<b=
r>
domain 0.<br></blockquote><div><br>yeah, I actually tested it and it was qu=
ite amusing to watch the keyboard and mouse move on the monitor and in VNC.=
<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt =
0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class=3D"im"><br>
&gt;<br>
&gt; I&#39;ve been looking through the 4.1.0 source, specifically in<br>
&gt; tools/ioemu-qemu-xen, and it appears that I&#39;d want to (for the key=
board)<br>
&gt; pass key codes from /dev/input through the kbd_put_keycode function. =
=A0From<br>
&gt; what I can tell, I&#39;d probably want to split off a thread to do thi=
s<br>
&gt; somewhere in main() in vl.c. =A0I was hoping that I could get some<br>
&gt; confirmation about whether I&#39;m looking in the right places and/or<=
br>
&gt; suggestions about how to cleanly implement this. =A0Odds are I won&#39=
;t be able<br>
&gt; to go the whole 9 yards and implement configuration options for xm or<=
br>
&gt; command line switches for qemu-dm, but I would suspect that someone,<b=
r>
&gt; somewhere, someday will also want this kind of ability. =A0If it&#39;s=
 already<br>
&gt; possible to pass through PS/2 devices without getting nuts in QEMU, th=
at&#39;s<br>
&gt; cool too :)<br>
<br>
</div>Can&#39;t do that. The PS/2 is one of those legacy beasts that depend=
s on ioports.<br>
But now that I think of it, maybe you can. In the guest config you can spec=
ify<br>
the ioports that you want to pass in. I hadn&#39;t tried to do this for the=
 keyboard<br>
ports but maybe that will work for you?<br>
<br></blockquote><div><br>I tried forwarding the ioports (off the top of my=
 head, I remember trying 60 and 64) but didn&#39;t have any luck - the kb/m=
ouse weren&#39;t forwarded despite adding the requisite ioports config as p=
er the docs.=A0 I theorized I was leaving off some config for the kernel, b=
ut didn&#39;t find anything.=A0 I agree that it certainly seems like this s=
hould work, and if you could elaborate on anything I could have goofed on, =
that would certainly be great (and hopefully, useful for anyone else who mi=
ght try this in the future)<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or could you use synergy?<br>
</blockquote></div><br>I actually did try synergy, but I couldn&#39;t get i=
t to work due to requirements for the OSes that were being run.<br>

--14dae9340fd9e512e404b5a5c6f3--


--===============7647013086107137791==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7647013086107137791==--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCES-0007y8-TJ; Mon, 09 Jan 2012 10:13:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <theubaz@gmail.com>) id 1RiBEX-0004fW-Jw
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 20:45:21 +0000
X-Env-Sender: theubaz@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1325623474!48898521!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27284 invoked from network); 3 Jan 2012 20:44:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 20:44:36 -0000
Received: by iagw33 with SMTP id w33so146948060iag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 12:45: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=aYwVGBG/5eLYy4HQvL0gBHQ8QENRYSVPkVFHi23ml24=;
	b=Wvr1nlfHns4u5CqxWUeQvBlk+mu3hpOQ+5nBlPRKX9KStCWCEH3f3efVPF9BLSJ4Bv
	E/rGMPdV9Sd300WBQMjkGAqqS1XkEmR78aRVET9/el11brI8usTma9YgS3Px/4FpGBhh
	4+y7hstZwiTLwgKJ9Icf51/FMM5tjDix7RA+I=
MIME-Version: 1.0
Received: by 10.50.191.200 with SMTP id ha8mr63632382igc.27.1325623517975;
	Tue, 03 Jan 2012 12:45:17 -0800 (PST)
Received: by 10.42.97.73 with HTTP; Tue, 3 Jan 2012 12:45:17 -0800 (PST)
In-Reply-To: <20120103202401.GB17472@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
Date: Tue, 3 Jan 2012 15:45:17 -0500
X-Google-Sender-Auth: QJu39kHpx83sRDwDw0__WMSuoh4
Message-ID: <CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
From: John Sherwood <jrs@vt.edu>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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="===============7647013086107137791=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7647013086107137791==
Content-Type: multipart/alternative; boundary=14dae9340fd9e512e404b5a5c6f3

--14dae9340fd9e512e404b5a5c6f3
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> > Hello,
> >
> > I'm working on a project and trying to pass through a PS/2 mouse +
> keyboard
> > to a hardware VM.  I've played with numerous things (including the
> obvious,
> > using USB), but after finding no alternative, it seems like the best way
> to
> > approach this would be to modify qemu-dm to pipe through data from
> > /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and
> then
> > using this version of qemu-dm only for this special case).
>
> That is certainly one way. But you would have an interesting problem that
> whatever
> you type on your physical keyboard would appear in the guest _and_ in the
> domain 0.
>

yeah, I actually tested it and it was quite amusing to watch the keyboard
and mouse move on the monitor and in VNC.


>
> >
> > I've been looking through the 4.1.0 source, specifically in
> > tools/ioemu-qemu-xen, and it appears that I'd want to (for the keyboard)
> > pass key codes from /dev/input through the kbd_put_keycode function.
>  From
> > what I can tell, I'd probably want to split off a thread to do this
> > somewhere in main() in vl.c.  I was hoping that I could get some
> > confirmation about whether I'm looking in the right places and/or
> > suggestions about how to cleanly implement this.  Odds are I won't be
> able
> > to go the whole 9 yards and implement configuration options for xm or
> > command line switches for qemu-dm, but I would suspect that someone,
> > somewhere, someday will also want this kind of ability.  If it's already
> > possible to pass through PS/2 devices without getting nuts in QEMU,
> that's
> > cool too :)
>
> Can't do that. The PS/2 is one of those legacy beasts that depends on
> ioports.
> But now that I think of it, maybe you can. In the guest config you can
> specify
> the ioports that you want to pass in. I hadn't tried to do this for the
> keyboard
> ports but maybe that will work for you?
>
>
I tried forwarding the ioports (off the top of my head, I remember trying
60 and 64) but didn't have any luck - the kb/mouse weren't forwarded
despite adding the requisite ioports config as per the docs.  I theorized I
was leaving off some config for the kernel, but didn't find anything.  I
agree that it certainly seems like this should work, and if you could
elaborate on anything I could have goofed on, that would certainly be great
(and hopefully, useful for anyone else who might try this in the future)


> Or could you use synergy?
>

I actually did try synergy, but I couldn't get it to work due to
requirements for the OSes that were being run.

--14dae9340fd9e512e404b5a5c6f3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzesz=
utek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad.wilk@oracle.com">k=
onrad.wilk@oracle.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<div class=3D"im">On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood w=
rote:<br>
&gt; Hello,<br>
&gt;<br>
&gt; I&#39;m working on a project and trying to pass through a PS/2 mouse +=
 keyboard<br>
&gt; to a hardware VM. =A0I&#39;ve played with numerous things (including t=
he obvious,<br>
&gt; using USB), but after finding no alternative, it seems like the best w=
ay to<br>
&gt; approach this would be to modify qemu-dm to pipe through data from<br>
&gt; /dev/input/eventwhatever to the keyboard/mouse that qemu provides (and=
 then<br>
&gt; using this version of qemu-dm only for this special case).<br>
<br>
</div>That is certainly one way. But you would have an interesting problem =
that whatever<br>
you type on your physical keyboard would appear in the guest _and_ in the<b=
r>
domain 0.<br></blockquote><div><br>yeah, I actually tested it and it was qu=
ite amusing to watch the keyboard and mouse move on the monitor and in VNC.=
<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt =
0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div class=3D"im"><br>
&gt;<br>
&gt; I&#39;ve been looking through the 4.1.0 source, specifically in<br>
&gt; tools/ioemu-qemu-xen, and it appears that I&#39;d want to (for the key=
board)<br>
&gt; pass key codes from /dev/input through the kbd_put_keycode function. =
=A0From<br>
&gt; what I can tell, I&#39;d probably want to split off a thread to do thi=
s<br>
&gt; somewhere in main() in vl.c. =A0I was hoping that I could get some<br>
&gt; confirmation about whether I&#39;m looking in the right places and/or<=
br>
&gt; suggestions about how to cleanly implement this. =A0Odds are I won&#39=
;t be able<br>
&gt; to go the whole 9 yards and implement configuration options for xm or<=
br>
&gt; command line switches for qemu-dm, but I would suspect that someone,<b=
r>
&gt; somewhere, someday will also want this kind of ability. =A0If it&#39;s=
 already<br>
&gt; possible to pass through PS/2 devices without getting nuts in QEMU, th=
at&#39;s<br>
&gt; cool too :)<br>
<br>
</div>Can&#39;t do that. The PS/2 is one of those legacy beasts that depend=
s on ioports.<br>
But now that I think of it, maybe you can. In the guest config you can spec=
ify<br>
the ioports that you want to pass in. I hadn&#39;t tried to do this for the=
 keyboard<br>
ports but maybe that will work for you?<br>
<br></blockquote><div><br>I tried forwarding the ioports (off the top of my=
 head, I remember trying 60 and 64) but didn&#39;t have any luck - the kb/m=
ouse weren&#39;t forwarded despite adding the requisite ioports config as p=
er the docs.=A0 I theorized I was leaving off some config for the kernel, b=
ut didn&#39;t find anything.=A0 I agree that it certainly seems like this s=
hould work, and if you could elaborate on anything I could have goofed on, =
that would certainly be great (and hopefully, useful for anyone else who mi=
ght try this in the future)<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or could you use synergy?<br>
</blockquote></div><br>I actually did try synergy, but I couldn&#39;t get i=
t to work due to requirements for the OSes that were being run.<br>

--14dae9340fd9e512e404b5a5c6f3--


--===============7647013086107137791==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7647013086107137791==--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCET-0007yl-Mu; Mon, 09 Jan 2012 10:13:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ming.aaron.liu@gmail.com>) id 1Rioir-0007H6-Lw
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:55:17 +0000
X-Env-Sender: ming.aaron.liu@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325775271!49068003!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 25614 invoked from network); 5 Jan 2012 14:54:32 -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;
	5 Jan 2012 14:54:32 -0000
Received: by yenr9 with SMTP id r9so4998804yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 06:55:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer;
	bh=xEG+XcNnNhkRK9H5O5wFBMNoiMwsVjAVJILYR/CJtw8=;
	b=Kvvr+QO6aZsCxD7MBD+nE3ZSdmfeFX/gw6h0eyIk9QNUCingy9WdT7IaeEL6lRZYu+
	Otfm4cXY0pf4M1dX2BSvJo246P0ol84XdGvqV+hrvWT1LX0fFXXyyyvKQ0bflR0LXGHZ
	BMBCSLg5TlZfkiJ1V2XAgoBuDC2YltKaxKIqM=
Received: by 10.236.148.235 with SMTP id v71mr1964606yhj.6.1325775315160;
	Thu, 05 Jan 2012 06:55:15 -0800 (PST)
Received: from p56-80.dhcp.ece.ufl.edu (n128-227-79-137.xlate.ufl.edu.
	[128.227.79.137])
	by mx.google.com with ESMTPS id z3sm24314537yhd.3.2012.01.05.06.55.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 05 Jan 2012 06:55:14 -0800 (PST)
From: Ming Liu <ming.aaron.liu@gmail.com>
Date: Thu, 5 Jan 2012 09:55:12 -0500
Message-Id: <DE20C7BF-2DC5-4E38-9848-FC91C92C5831@gmail.com>
To: xen-devel@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Subject: [Xen-devel] Question about region_base in xc_domain_restore of live
	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

Hi, 
I'm studying the details about the live migration. I encounter a question when I read the source codes in xc_domain_save.c.
The code is:
region_base = xc_map_foreign_bulk(xc_handle, dom, PORT_READ, pfn_type, pfn_err, batch)
When I see xc_map_foreign_bulk function, I find that it mmap region_base to an address that is :
addr = mmap(NULL, (unsigned long) num << PAGE_SHIFT, port, MAP_SHARED, xc_handle, 0)
>From the above codes, I can know that region_base has been mapped to a block of data which is the same as the size of all pages. 
After that, the there is another line of code:
rc = ioctl(xc_handle, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx)
Is this function used to map all machine page content to region_base?

What is the usage of region_base?
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 Mon Jan 09 10:13:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:13:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCET-0007yl-Mu; Mon, 09 Jan 2012 10:13:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ming.aaron.liu@gmail.com>) id 1Rioir-0007H6-Lw
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 14:55:17 +0000
X-Env-Sender: ming.aaron.liu@gmail.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1325775271!49068003!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 25614 invoked from network); 5 Jan 2012 14:54:32 -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;
	5 Jan 2012 14:54:32 -0000
Received: by yenr9 with SMTP id r9so4998804yen.30
	for <xen-devel@lists.xensource.com>;
	Thu, 05 Jan 2012 06:55:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=from:content-type:content-transfer-encoding:subject:date:message-id
	:to:mime-version:x-mailer;
	bh=xEG+XcNnNhkRK9H5O5wFBMNoiMwsVjAVJILYR/CJtw8=;
	b=Kvvr+QO6aZsCxD7MBD+nE3ZSdmfeFX/gw6h0eyIk9QNUCingy9WdT7IaeEL6lRZYu+
	Otfm4cXY0pf4M1dX2BSvJo246P0ol84XdGvqV+hrvWT1LX0fFXXyyyvKQ0bflR0LXGHZ
	BMBCSLg5TlZfkiJ1V2XAgoBuDC2YltKaxKIqM=
Received: by 10.236.148.235 with SMTP id v71mr1964606yhj.6.1325775315160;
	Thu, 05 Jan 2012 06:55:15 -0800 (PST)
Received: from p56-80.dhcp.ece.ufl.edu (n128-227-79-137.xlate.ufl.edu.
	[128.227.79.137])
	by mx.google.com with ESMTPS id z3sm24314537yhd.3.2012.01.05.06.55.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 05 Jan 2012 06:55:14 -0800 (PST)
From: Ming Liu <ming.aaron.liu@gmail.com>
Date: Thu, 5 Jan 2012 09:55:12 -0500
Message-Id: <DE20C7BF-2DC5-4E38-9848-FC91C92C5831@gmail.com>
To: xen-devel@lists.xensource.com
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Subject: [Xen-devel] Question about region_base in xc_domain_restore of live
	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

Hi, 
I'm studying the details about the live migration. I encounter a question when I read the source codes in xc_domain_save.c.
The code is:
region_base = xc_map_foreign_bulk(xc_handle, dom, PORT_READ, pfn_type, pfn_err, batch)
When I see xc_map_foreign_bulk function, I find that it mmap region_base to an address that is :
addr = mmap(NULL, (unsigned long) num << PAGE_SHIFT, port, MAP_SHARED, xc_handle, 0)
>From the above codes, I can know that region_base has been mapped to a block of data which is the same as the size of all pages. 
After that, the there is another line of code:
rc = ioctl(xc_handle, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx)
Is this function used to map all machine page content to region_base?

What is the usage of region_base?
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 Mon Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCEU-0007zX-EM; Mon, 09 Jan 2012 10:13:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gmail.com>) id 1RjB22-0006oW-1u
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:44:34 +0000
X-Env-Sender: amscanne@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1325860939!50775779!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 3128 invoked from network); 6 Jan 2012 14:42:20 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 14:42:20 -0000
Received: by iagw33 with SMTP id w33so10507460iag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 06:44: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=I1SMSazlVqvPyuhj0hNsSCNzDrR3PYYLyG3nR9ow5lE=;
	b=SQeV/pukzA00lBcrr6Brt2fIRtkGgRqE88Lysq8XclzSqfMY6aPSpGxrlMqFvsGZKO
	ZbLQqAAOQMg0tcYcKCvU3hD8+z1Xl9H1/VXhyPHfBrzf7kntwwmsJhYPxViNaZkkdy+4
	PcBHevqXkdgxEeV1DH5PsAc9+lps0px9z6t/g=
Received: by 10.50.51.199 with SMTP id m7mr8109978igo.23.1325861065197; Fri,
	06 Jan 2012 06:44:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.80.202 with HTTP; Fri, 6 Jan 2012 06:44:05 -0800 (PST)
In-Reply-To: <20229.57503.64455.14463@mariner.uk.xensource.com>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
	<20120104104654.GA5554@aepfle.de>
	<20229.57503.64455.14463@mariner.uk.xensource.com>
From: Adin Scannell <adin@scannell.ca>
Date: Fri, 6 Jan 2012 09:44:05 -0500
X-Google-Sender-Auth: Nof-wcFAAE9S_Lre1ZN2tvCGrSc
Message-ID: <CAPgzrSVKVv1vD-4FDOHCf-X97PSPeSeShgrQj8Ezs0XGMvB8yQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [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="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, Jan 5, 2012 at 12:40, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Thanks. =A0Adin, would you care to sign it off, indicating your
> confirmation that the Developer's Certificate of Origin applies =A0?
> See =A0http://wiki.xen.org/wiki/SubmittingXenPatches

Absolutely, sorry about that.

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 Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCEU-0007zX-EM; Mon, 09 Jan 2012 10:13:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gmail.com>) id 1RjB22-0006oW-1u
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 14:44:34 +0000
X-Env-Sender: amscanne@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1325860939!50775779!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 3128 invoked from network); 6 Jan 2012 14:42:20 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	6 Jan 2012 14:42:20 -0000
Received: by iagw33 with SMTP id w33so10507460iag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 06 Jan 2012 06:44: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:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=I1SMSazlVqvPyuhj0hNsSCNzDrR3PYYLyG3nR9ow5lE=;
	b=SQeV/pukzA00lBcrr6Brt2fIRtkGgRqE88Lysq8XclzSqfMY6aPSpGxrlMqFvsGZKO
	ZbLQqAAOQMg0tcYcKCvU3hD8+z1Xl9H1/VXhyPHfBrzf7kntwwmsJhYPxViNaZkkdy+4
	PcBHevqXkdgxEeV1DH5PsAc9+lps0px9z6t/g=
Received: by 10.50.51.199 with SMTP id m7mr8109978igo.23.1325861065197; Fri,
	06 Jan 2012 06:44:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.80.202 with HTTP; Fri, 6 Jan 2012 06:44:05 -0800 (PST)
In-Reply-To: <20229.57503.64455.14463@mariner.uk.xensource.com>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
	<20120104104654.GA5554@aepfle.de>
	<20229.57503.64455.14463@mariner.uk.xensource.com>
From: Adin Scannell <adin@scannell.ca>
Date: Fri, 6 Jan 2012 09:44:05 -0500
X-Google-Sender-Auth: Nof-wcFAAE9S_Lre1ZN2tvCGrSc
Message-ID: <CAPgzrSVKVv1vD-4FDOHCf-X97PSPeSeShgrQj8Ezs0XGMvB8yQ@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
Subject: Re: [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="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, Jan 5, 2012 at 12:40, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Thanks. =A0Adin, would you care to sign it off, indicating your
> confirmation that the Developer's Certificate of Origin applies =A0?
> See =A0http://wiki.xen.org/wiki/SubmittingXenPatches

Absolutely, sorry about that.

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 Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCES-0007xc-04; Mon, 09 Jan 2012 10:13:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gmail.com>) id 1Ri82Q-0000Ab-9e
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:20:38 +0000
X-Env-Sender: amscanne@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1325611207!54262911!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 10465 invoked from network); 3 Jan 2012 17:20:09 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:20:09 -0000
Received: by iagw33 with SMTP id w33so146154195iag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 09:20:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=g8O5AgxqxBEWl9bVIyXhOKQRr3JV8Pj8/esRmVjfZEo=;
	b=teZwXN/PMV5ucsarU+hKEwaw3BnbIbWF70cpeNqTSLkT2IFfvktDQ8o+vJNQkFAFoK
	8HJtP8YSSBpPJ3rgXcu62yeI78tQ7E8nu52gIDnRN3XlmUMv5/vSVIqyeTj6u1EMwses
	7nK/NdK7HLq0jhIA68ImL4xGSpbkPuVvVEVk0=
Received: by 10.42.168.197 with SMTP id x5mr14458878icy.6.1325610927182; Tue,
	03 Jan 2012 09:15:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.79.85 with HTTP; Tue, 3 Jan 2012 09:15:06 -0800 (PST)
In-Reply-To: <20227.13416.459908.208375@mariner.uk.xensource.com>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
	<20227.13416.459908.208375@mariner.uk.xensource.com>
From: Adin Scannell <adin@scannell.ca>
Date: Tue, 3 Jan 2012 12:15:06 -0500
X-Google-Sender-Auth: 3IapJ_eAZ3VmBrZtDRGkQhXz5gM
Message-ID: <CAPgzrSV3PsyxFXSwsRfK3ordS-DQF35_c3PP0APpYTC9CUUneA@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> I confess I don't understand the intended error handling here. =A0AFAICT
> this ioctl leaves a separate errno value for each request, in the
> array. =A0Presumably, however, it can also fail entirely and not update
> the separate in-array errno values.
>
> So how does one tell which of these is the case ?

ENOENT is returned in the case where everything is successful, but at
least one of the entries is ENOENT as the page was not available
(paged-out).  In other words, when ENOENT is returned you can trust
the errno entries were filled in.  It's a somewhat special case.

As you've pointed out, one cannot trust the errno vals if some
arbitrary error (like EINVAL) is returned.  The current code assumes
that after the first ENOENT, subsequent calls will be the same and the
errno vals can be read and trusted.  My patch was intended to fix this
behavior and only read the errno values when ENOENT is returned and
they are meaningful.  If you get back an EINVAL with my patch, the
loop will break and function call will fail.  Without the patch, it'll
keep looping forever (it's unlikely that this would ever happen, but I
noticed that the logic was a bit broken...).

Cheers,
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCES-0007xc-04; Mon, 09 Jan 2012 10:13:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <amscanne@gmail.com>) id 1Ri82Q-0000Ab-9e
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 17:20:38 +0000
X-Env-Sender: amscanne@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1325611207!54262911!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 10465 invoked from network); 3 Jan 2012 17:20:09 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	3 Jan 2012 17:20:09 -0000
Received: by iagw33 with SMTP id w33so146154195iag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 09:20:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=g8O5AgxqxBEWl9bVIyXhOKQRr3JV8Pj8/esRmVjfZEo=;
	b=teZwXN/PMV5ucsarU+hKEwaw3BnbIbWF70cpeNqTSLkT2IFfvktDQ8o+vJNQkFAFoK
	8HJtP8YSSBpPJ3rgXcu62yeI78tQ7E8nu52gIDnRN3XlmUMv5/vSVIqyeTj6u1EMwses
	7nK/NdK7HLq0jhIA68ImL4xGSpbkPuVvVEVk0=
Received: by 10.42.168.197 with SMTP id x5mr14458878icy.6.1325610927182; Tue,
	03 Jan 2012 09:15:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.79.85 with HTTP; Tue, 3 Jan 2012 09:15:06 -0800 (PST)
In-Reply-To: <20227.13416.459908.208375@mariner.uk.xensource.com>
References: <14d42c7d8e0817040186.1324094120@dev.gridcentric.ca>
	<20227.13416.459908.208375@mariner.uk.xensource.com>
From: Adin Scannell <adin@scannell.ca>
Date: Tue, 3 Jan 2012 12:15:06 -0500
X-Google-Sender-Auth: 3IapJ_eAZ3VmBrZtDRGkQhXz5gM
Message-ID: <CAPgzrSV3PsyxFXSwsRfK3ordS-DQF35_c3PP0APpYTC9CUUneA@mail.gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> I confess I don't understand the intended error handling here. =A0AFAICT
> this ioctl leaves a separate errno value for each request, in the
> array. =A0Presumably, however, it can also fail entirely and not update
> the separate in-array errno values.
>
> So how does one tell which of these is the case ?

ENOENT is returned in the case where everything is successful, but at
least one of the entries is ENOENT as the page was not available
(paged-out).  In other words, when ENOENT is returned you can trust
the errno entries were filled in.  It's a somewhat special case.

As you've pointed out, one cannot trust the errno vals if some
arbitrary error (like EINVAL) is returned.  The current code assumes
that after the first ENOENT, subsequent calls will be the same and the
errno vals can be read and trusted.  My patch was intended to fix this
behavior and only read the errno values when ENOENT is returned and
they are meaningful.  If you get back an EINVAL with my patch, the
loop will break and function call will fail.  Without the patch, it'll
keep looping forever (it's unlikely that this would ever happen, but I
noticed that the logic was a bit broken...).

Cheers,
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCEU-0007zt-Sd; Mon, 09 Jan 2012 10:13:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ddutile@redhat.com>) id 1RjD3C-0004fM-OX
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:53:54 +0000
X-Env-Sender: ddutile@redhat.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325868827!10655479!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2377 invoked from network); 6 Jan 2012 16:53:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 16:53:48 -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 q06Grif1024892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 11:53:44 -0500
Received: from dddsys0.bos.redhat.com (dddsys0.bos.redhat.com [10.16.184.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with
	ESMTP id q06Grh78013894; Fri, 6 Jan 2012 11:53:43 -0500
Message-ID: <4F072717.8090006@redhat.com>
Date: Fri, 06 Jan 2012 11:53:43 -0500
From: Don Dutile <ddutile@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110927 Red Hat/3.1.15-1.el6_1
	Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
	<1325759051.25206.361.camel@zakaz.uk.xensource.com>
	<4F05F2EA.5030502@redhat.com>
	<20120105213423.GC5180@phenom.dumpdata.com>
In-Reply-To: <20120105213423.GC5180@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/05/2012 04:34 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 05, 2012 at 01:58:50PM -0500, Don Dutile wrote:
>> On 01/05/2012 05:24 AM, Ian Campbell wrote:
>>> On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
>>>> We use the __pci_reset_function_locked to perform the action.
>>>> Also on attaching ("bind") and detaching ("unbind") we save and
>>>> restore the configuration states. When the device is disconnected
>>> >from a guest we use the "pci_reset_function" to also reset the
>>>> device before being passed to another guest.
>>>
>>> Currently I thought the toolstack was supposed to do the reset (by
>>> writing to the reset node in sysfs) as it was (de)assigning devices
>>> to/from guests. That's not to say that there isn't an argument for
>>> preferring to do it kernels side but it would be interesting to make
>>> that argument explicitly.
>>>
>>> I guess the toolstack doesn't currently save/restore the configuration
>>> state, could it though? I guess the state is all available in sysfs. On
>> pci_reset_function() saves the config state before doing a fcn-level reset.
>>
>> the libvirt toolstack handles the unbind/reset/bind functionality
>> and is used by kvm for it's device assignment.
>
> The KVM assigned PCI module does the call as well via the ioctls when
> assigning/de-assigning the PCI device. Look in 'kvm_free_assigned_device'
> and in 'kvm_vm_ioctl_assign_device'.
>
> Is that what you mean by the unbind/reset/bind functionality - the ioctl
> call?
>
It's done in both places (libvirt & kvm-ioctl).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCEU-0007zt-Sd; Mon, 09 Jan 2012 10:13:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ddutile@redhat.com>) id 1RjD3C-0004fM-OX
	for xen-devel@lists.xensource.com; Fri, 06 Jan 2012 16:53:54 +0000
X-Env-Sender: ddutile@redhat.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1325868827!10655479!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDgwODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2377 invoked from network); 6 Jan 2012 16:53:48 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-21.messagelabs.com with SMTP;
	6 Jan 2012 16:53:48 -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 q06Grif1024892
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 6 Jan 2012 11:53:44 -0500
Received: from dddsys0.bos.redhat.com (dddsys0.bos.redhat.com [10.16.184.11])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with
	ESMTP id q06Grh78013894; Fri, 6 Jan 2012 11:53:43 -0500
Message-ID: <4F072717.8090006@redhat.com>
Date: Fri, 06 Jan 2012 11:53:43 -0500
From: Don Dutile <ddutile@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110927 Red Hat/3.1.15-1.el6_1
	Thunderbird/3.1.15
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
	<1325759051.25206.361.camel@zakaz.uk.xensource.com>
	<4F05F2EA.5030502@redhat.com>
	<20120105213423.GC5180@phenom.dumpdata.com>
In-Reply-To: <20120105213423.GC5180@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/05/2012 04:34 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 05, 2012 at 01:58:50PM -0500, Don Dutile wrote:
>> On 01/05/2012 05:24 AM, Ian Campbell wrote:
>>> On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
>>>> We use the __pci_reset_function_locked to perform the action.
>>>> Also on attaching ("bind") and detaching ("unbind") we save and
>>>> restore the configuration states. When the device is disconnected
>>> >from a guest we use the "pci_reset_function" to also reset the
>>>> device before being passed to another guest.
>>>
>>> Currently I thought the toolstack was supposed to do the reset (by
>>> writing to the reset node in sysfs) as it was (de)assigning devices
>>> to/from guests. That's not to say that there isn't an argument for
>>> preferring to do it kernels side but it would be interesting to make
>>> that argument explicitly.
>>>
>>> I guess the toolstack doesn't currently save/restore the configuration
>>> state, could it though? I guess the state is all available in sysfs. On
>> pci_reset_function() saves the config state before doing a fcn-level reset.
>>
>> the libvirt toolstack handles the unbind/reset/bind functionality
>> and is used by kvm for it's device assignment.
>
> The KVM assigned PCI module does the call as well via the ioctls when
> assigning/de-assigning the PCI device. Look in 'kvm_free_assigned_device'
> and in 'kvm_vm_ioctl_assign_device'.
>
> Is that what you mean by the unbind/reset/bind functionality - the ioctl
> call?
>
It's done in both places (libvirt & kvm-ioctl).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCEU-0007z8-2T; Mon, 09 Jan 2012 10:13:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ddutile@redhat.com>) id 1RisWj-0001gh-Fv
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:59:01 +0000
X-Env-Sender: ddutile@redhat.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325789934!9753360!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13025 invoked from network); 5 Jan 2012 18:58:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 18:58:54 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q05Iwp1e002441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 13:58:51 -0500
Received: from dddsys0.bos.redhat.com (dddsys0.bos.redhat.com [10.16.184.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with
	ESMTP id q05Iwowt013730; Thu, 5 Jan 2012 13:58:50 -0500
Message-ID: <4F05F2EA.5030502@redhat.com>
Date: Thu, 05 Jan 2012 13:58:50 -0500
From: Don Dutile <ddutile@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110927 Red Hat/3.1.15-1.el6_1
	Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>	
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
	<1325759051.25206.361.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325759051.25206.361.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/05/2012 05:24 AM, Ian Campbell wrote:
> On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
>> We use the __pci_reset_function_locked to perform the action.
>> Also on attaching ("bind") and detaching ("unbind") we save and
>> restore the configuration states. When the device is disconnected
>> from a guest we use the "pci_reset_function" to also reset the
>> device before being passed to another guest.
>
> Currently I thought the toolstack was supposed to do the reset (by
> writing to the reset node in sysfs) as it was (de)assigning devices
> to/from guests. That's not to say that there isn't an argument for
> preferring to do it kernels side but it would be interesting to make
> that argument explicitly.
>
> I guess the toolstack doesn't currently save/restore the configuration
> state, could it though? I guess the state is all available in sysfs. On
pci_reset_function() saves the config state before doing a fcn-level reset.

the libvirt toolstack handles the unbind/reset/bind functionality
and is used by kvm for it's device assignment.

> the other hand the kernel provides us with a very handy function which
> Just Does It...
>
> Ian.
>
>>
>> Signed-off-by: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>> ---
>>   drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
>>   drivers/xen/xen-pciback/pciback.h  |    1 +
>>   2 files changed, 39 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
>> index 8f06e1e..0ce0dc6 100644
>> --- a/drivers/xen/xen-pciback/pci_stub.c
>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>> @@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
>>   static void pcistub_device_release(struct kref *kref)
>>   {
>>   	struct pcistub_device *psdev;
>> +	struct xen_pcibk_dev_data *dev_data;
>>
>>   	psdev = container_of(kref, struct pcistub_device, kref);
>> +	dev_data = pci_get_drvdata(psdev->dev);
>>
>>   	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
>>
>>   	xen_unregister_device_domain_owner(psdev->dev);
>>
>> -	/* Clean-up the device */
>> +	/* Call the reset function which does not take lock as this
>> +	 * is called from "unbind" which takes a device_lock mutex.
>> +	 */
>> +	__pci_reset_function_locked(psdev->dev);
>> +	if (pci_load_and_free_saved_state(psdev->dev,
>> +					&dev_data->pci_saved_state)) {
>> +		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
>> +	} else
>> +		pci_restore_state(psdev->dev);
>> +
>> +	/* Disable the device */
>>   	xen_pcibk_reset_device(psdev->dev);
>> +
>> +	kfree(dev_data);
>> +	pci_set_drvdata(psdev->dev, NULL);
>> +
>> +	/* Clean-up the device */
>>   	xen_pcibk_config_free_dyn_fields(psdev->dev);
>>   	xen_pcibk_config_free_dev(psdev->dev);
>> -	kfree(pci_get_drvdata(psdev->dev));
>> -	pci_set_drvdata(psdev->dev, NULL);
>>
>>   	pci_dev_put(psdev->dev);
>>
>> @@ -230,7 +245,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
>>   	/* Cleanup our device
>>   	 * (so it's ready for the next domain)
>>   	 */
>> +
>> +	/* This is OK - we are running from workqueue context
>> +	 * and want to inhibit the user from fiddling with 'reset'
>> +	 */
>> +	pci_reset_function(dev);
>> +	pci_restore_state(psdev->dev);
>> +
>> +	/* This disables the device. */
>>   	xen_pcibk_reset_device(found_psdev->dev);
>> +
>> +	/* And cleanup up our emulated fields. */
>>   	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
>>   	xen_pcibk_config_reset_dev(found_psdev->dev);
>>
>> @@ -325,6 +350,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
>>   	if (err)
>>   		goto config_release;
>>
>> +	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
>> +	__pci_reset_function_locked(dev);
>> +
>> +	/* We need the device active to save the state. */
>> +	dev_dbg(&dev->dev, "save state of device\n");
>> +	pci_save_state(dev);
>> +	dev_data->pci_saved_state = pci_store_saved_state(dev);
>> +	if (!dev_data->pci_saved_state)
>> +		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
>> +
>>   	/* Now disable the device (this also ensures some private device
>>   	 * data is setup before we export)
>>   	 */
>> diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
>> index e9b4011..a7def01 100644
>> --- a/drivers/xen/xen-pciback/pciback.h
>> +++ b/drivers/xen/xen-pciback/pciback.h
>> @@ -41,6 +41,7 @@ struct xen_pcibk_device {
>>
>>   struct xen_pcibk_dev_data {
>>   	struct list_head config_fields;
>> +	struct pci_saved_state *pci_saved_state;
>>   	unsigned int permissive:1;
>>   	unsigned int warned_on_write:1;
>>   	unsigned int enable_intx:1;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCES-0007xp-EN; Mon, 09 Jan 2012 10:13:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lcapitulino@redhat.com>) id 1Ri9gZ-0002zz-Ty
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 19:06:12 +0000
X-Env-Sender: lcapitulino@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325617564!7001692!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYyNTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2797 invoked from network); 3 Jan 2012 19:06:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	3 Jan 2012 19:06: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 q03J5wYd004906
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 14:05:58 -0500
Received: from doriath (ovpn-113-115.phx2.redhat.com [10.3.113.115])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q03J5u3n027549; Tue, 3 Jan 2012 14:05:56 -0500
Date: Tue, 3 Jan 2012 17:05:55 -0200
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120103170555.3a32ac1b@doriath>
In-Reply-To: <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>
	<alpine.DEB.2.00.1112191637230.11530@perard.uk.xensource.com>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
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 Mon, 19 Dec 2011 17:27:55 +0000
Anthony PERARD <anthony.perard@citrix.com> wrote:

> 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.

Do you need both? What about setting inmigrate when initializing the
machine and using it instead?

PS: sorry for the delay, I was on vacation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCES-0007xp-EN; Mon, 09 Jan 2012 10:13:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lcapitulino@redhat.com>) id 1Ri9gZ-0002zz-Ty
	for xen-devel@lists.xensource.com; Tue, 03 Jan 2012 19:06:12 +0000
X-Env-Sender: lcapitulino@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1325617564!7001692!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDYyNTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2797 invoked from network); 3 Jan 2012 19:06:05 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-21.messagelabs.com with SMTP;
	3 Jan 2012 19:06: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 q03J5wYd004906
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 3 Jan 2012 14:05:58 -0500
Received: from doriath (ovpn-113-115.phx2.redhat.com [10.3.113.115])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q03J5u3n027549; Tue, 3 Jan 2012 14:05:56 -0500
Date: Tue, 3 Jan 2012 17:05:55 -0200
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Anthony PERARD <anthony.perard@citrix.com>
Message-ID: <20120103170555.3a32ac1b@doriath>
In-Reply-To: <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>
	<alpine.DEB.2.00.1112191637230.11530@perard.uk.xensource.com>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
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 Mon, 19 Dec 2011 17:27:55 +0000
Anthony PERARD <anthony.perard@citrix.com> wrote:

> 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.

Do you need both? What about setting inmigrate when initializing the
machine and using it instead?

PS: sorry for the delay, I was on vacation.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCEU-0007z8-2T; Mon, 09 Jan 2012 10:13:38 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <ddutile@redhat.com>) id 1RisWj-0001gh-Fv
	for xen-devel@lists.xensource.com; Thu, 05 Jan 2012 18:59:01 +0000
X-Env-Sender: ddutile@redhat.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1325789934!9753360!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDY0MTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13025 invoked from network); 5 Jan 2012 18:58:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	5 Jan 2012 18:58:54 -0000
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q05Iwp1e002441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 5 Jan 2012 13:58:51 -0500
Received: from dddsys0.bos.redhat.com (dddsys0.bos.redhat.com [10.16.184.11])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with
	ESMTP id q05Iwowt013730; Thu, 5 Jan 2012 13:58:50 -0500
Message-ID: <4F05F2EA.5030502@redhat.com>
Date: Thu, 05 Jan 2012 13:58:50 -0500
From: Don Dutile <ddutile@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110927 Red Hat/3.1.15-1.el6_1
	Thunderbird/3.1.15
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>	
	<1325724403-29642-3-git-send-email-konrad.wilk@oracle.com>
	<1325759051.25206.361.camel@zakaz.uk.xensource.com>
In-Reply-To: <1325759051.25206.361.camel@zakaz.uk.xensource.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/5] xen/pciback: Support pci_reset_function,
 aka FLR or D3 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/05/2012 05:24 AM, Ian Campbell wrote:
> On Thu, 2012-01-05 at 00:46 +0000, Konrad Rzeszutek Wilk wrote:
>> We use the __pci_reset_function_locked to perform the action.
>> Also on attaching ("bind") and detaching ("unbind") we save and
>> restore the configuration states. When the device is disconnected
>> from a guest we use the "pci_reset_function" to also reset the
>> device before being passed to another guest.
>
> Currently I thought the toolstack was supposed to do the reset (by
> writing to the reset node in sysfs) as it was (de)assigning devices
> to/from guests. That's not to say that there isn't an argument for
> preferring to do it kernels side but it would be interesting to make
> that argument explicitly.
>
> I guess the toolstack doesn't currently save/restore the configuration
> state, could it though? I guess the state is all available in sysfs. On
pci_reset_function() saves the config state before doing a fcn-level reset.

the libvirt toolstack handles the unbind/reset/bind functionality
and is used by kvm for it's device assignment.

> the other hand the kernel provides us with a very handy function which
> Just Does It...
>
> Ian.
>
>>
>> Signed-off-by: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>> ---
>>   drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
>>   drivers/xen/xen-pciback/pciback.h  |    1 +
>>   2 files changed, 39 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
>> index 8f06e1e..0ce0dc6 100644
>> --- a/drivers/xen/xen-pciback/pci_stub.c
>> +++ b/drivers/xen/xen-pciback/pci_stub.c
>> @@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
>>   static void pcistub_device_release(struct kref *kref)
>>   {
>>   	struct pcistub_device *psdev;
>> +	struct xen_pcibk_dev_data *dev_data;
>>
>>   	psdev = container_of(kref, struct pcistub_device, kref);
>> +	dev_data = pci_get_drvdata(psdev->dev);
>>
>>   	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
>>
>>   	xen_unregister_device_domain_owner(psdev->dev);
>>
>> -	/* Clean-up the device */
>> +	/* Call the reset function which does not take lock as this
>> +	 * is called from "unbind" which takes a device_lock mutex.
>> +	 */
>> +	__pci_reset_function_locked(psdev->dev);
>> +	if (pci_load_and_free_saved_state(psdev->dev,
>> +					&dev_data->pci_saved_state)) {
>> +		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
>> +	} else
>> +		pci_restore_state(psdev->dev);
>> +
>> +	/* Disable the device */
>>   	xen_pcibk_reset_device(psdev->dev);
>> +
>> +	kfree(dev_data);
>> +	pci_set_drvdata(psdev->dev, NULL);
>> +
>> +	/* Clean-up the device */
>>   	xen_pcibk_config_free_dyn_fields(psdev->dev);
>>   	xen_pcibk_config_free_dev(psdev->dev);
>> -	kfree(pci_get_drvdata(psdev->dev));
>> -	pci_set_drvdata(psdev->dev, NULL);
>>
>>   	pci_dev_put(psdev->dev);
>>
>> @@ -230,7 +245,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
>>   	/* Cleanup our device
>>   	 * (so it's ready for the next domain)
>>   	 */
>> +
>> +	/* This is OK - we are running from workqueue context
>> +	 * and want to inhibit the user from fiddling with 'reset'
>> +	 */
>> +	pci_reset_function(dev);
>> +	pci_restore_state(psdev->dev);
>> +
>> +	/* This disables the device. */
>>   	xen_pcibk_reset_device(found_psdev->dev);
>> +
>> +	/* And cleanup up our emulated fields. */
>>   	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
>>   	xen_pcibk_config_reset_dev(found_psdev->dev);
>>
>> @@ -325,6 +350,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
>>   	if (err)
>>   		goto config_release;
>>
>> +	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
>> +	__pci_reset_function_locked(dev);
>> +
>> +	/* We need the device active to save the state. */
>> +	dev_dbg(&dev->dev, "save state of device\n");
>> +	pci_save_state(dev);
>> +	dev_data->pci_saved_state = pci_store_saved_state(dev);
>> +	if (!dev_data->pci_saved_state)
>> +		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
>> +
>>   	/* Now disable the device (this also ensures some private device
>>   	 * data is setup before we export)
>>   	 */
>> diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
>> index e9b4011..a7def01 100644
>> --- a/drivers/xen/xen-pciback/pciback.h
>> +++ b/drivers/xen/xen-pciback/pciback.h
>> @@ -41,6 +41,7 @@ struct xen_pcibk_device {
>>
>>   struct xen_pcibk_dev_data {
>>   	struct list_head config_fields;
>> +	struct pci_saved_state *pci_saved_state;
>>   	unsigned int permissive:1;
>>   	unsigned int warned_on_write:1;
>>   	unsigned int enable_intx:1;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCET-0007yR-9r; Mon, 09 Jan 2012 10:13:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <theubaz@gmail.com>) id 1RiFSo-0003Gu-DC
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 01:16:22 +0000
X-Env-Sender: theubaz@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325639773!9489435!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30045 invoked from network); 4 Jan 2012 01:16:15 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 01:16:15 -0000
Received: by iagw33 with SMTP id w33so148360800iag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 17:16:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Drmv7WBHivvS1VodLrxiJF2DfjCWfrtDRgxmMFTPUwI=;
	b=t2iXiPG3UOG/DnJSG5a+LrKcZfnsPA7o9bPSCawUkPQPNvz9jgp+cYvqmLF8smC4ez
	EokZQRghE2rNBBiNlwGa7K82k/+1/wSI8VSYnr7yqSjqHPe8onky9jGP8l37kwsS9gYp
	ILxZytudGFyfKjLGVf8P3/z9ymV8k3Tr+9tjg=
MIME-Version: 1.0
Received: by 10.50.159.131 with SMTP id xc3mr64454569igb.27.1325639773442;
	Tue, 03 Jan 2012 17:16:13 -0800 (PST)
Received: by 10.42.97.73 with HTTP; Tue, 3 Jan 2012 17:16:13 -0800 (PST)
In-Reply-To: <20120103224040.GC12939@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
	<20120103224040.GC12939@phenom.dumpdata.com>
Date: Tue, 3 Jan 2012 20:16:13 -0500
X-Google-Sender-Auth: MPRUEly_qSGby6v-71KSGAtyqX8
Message-ID: <CAH5ygH26OBci9U0ogRaH0n_xzEo38csr9H5dUWyvUdH=1hSGGQ@mail.gmail.com>
From: John Sherwood <jrs@vt.edu>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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="===============3152918086423446408=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3152918086423446408==
Content-Type: multipart/alternative; boundary=14dae9399dcdcbd1d604b5a98f11

--14dae9399dcdcbd1d604b5a98f11
Content-Type: text/plain; charset=ISO-8859-1

the synergy incompatibilities were largely package related, due to
requirements for a different application that we were supposed to deploy.
 I'll try the ioperm patches next chance I have.

On Tue, Jan 3, 2012 at 5:40 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Tue, Jan 03, 2012 at 03:45:17PM -0500, John Sherwood wrote:
> > On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
> > konrad.wilk@oracle.com> wrote:
> >
> > > On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> > > > Hello,
> > > >
> > > > I'm working on a project and trying to pass through a PS/2 mouse +
> > > keyboard
> > > > to a hardware VM.  I've played with numerous things (including the
> > > obvious,
> > > > using USB), but after finding no alternative, it seems like the best
> way
> > > to
> > > > approach this would be to modify qemu-dm to pipe through data from
> > > > /dev/input/eventwhatever to the keyboard/mouse that qemu provides
> (and
> > > then
> > > > using this version of qemu-dm only for this special case).
> > >
> > > That is certainly one way. But you would have an interesting problem
> that
> > > whatever
> > > you type on your physical keyboard would appear in the guest _and_ in
> the
> > > domain 0.
> > >
> >
> > yeah, I actually tested it and it was quite amusing to watch the keyboard
> > and mouse move on the monitor and in VNC.
> >
> >
> > >
> > > >
> > > > I've been looking through the 4.1.0 source, specifically in
> > > > tools/ioemu-qemu-xen, and it appears that I'd want to (for the
> keyboard)
> > > > pass key codes from /dev/input through the kbd_put_keycode function.
> > >  From
> > > > what I can tell, I'd probably want to split off a thread to do this
> > > > somewhere in main() in vl.c.  I was hoping that I could get some
> > > > confirmation about whether I'm looking in the right places and/or
> > > > suggestions about how to cleanly implement this.  Odds are I won't be
> > > able
> > > > to go the whole 9 yards and implement configuration options for xm or
> > > > command line switches for qemu-dm, but I would suspect that someone,
> > > > somewhere, someday will also want this kind of ability.  If it's
> already
> > > > possible to pass through PS/2 devices without getting nuts in QEMU,
> > > that's
> > > > cool too :)
> > >
> > > Can't do that. The PS/2 is one of those legacy beasts that depends on
> > > ioports.
> > > But now that I think of it, maybe you can. In the guest config you can
> > > specify
> > > the ioports that you want to pass in. I hadn't tried to do this for the
> > > keyboard
> > > ports but maybe that will work for you?
> > >
> > >
> > I tried forwarding the ioports (off the top of my head, I remember trying
> > 60 and 64) but didn't have any luck - the kb/mouse weren't forwarded
> > despite adding the requisite ioports config as per the docs.  I
> theorized I
> > was leaving off some config for the kernel, but didn't find anything.  I
> > agree that it certainly seems like this should work, and if you could
> > elaborate on anything I could have goofed on, that would certainly be
> great
> > (and hopefully, useful for anyone else who might try this in the future)
>
> I think you might be missing the ioperm patches. The are in devel/ioperm
> on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>
> >
> >
> > > Or could you use synergy?
> > >
> >
> > I actually did try synergy, but I couldn't get it to work due to
> > requirements for the OSes that were being run.
>
> Huh? What OS is that? Anyhow another thought that occured to me is
> what Virtual Computer or Xen Client Project do.. which is something
> I don't really know what they do but their demo showed the user hitting
> 'Alt-Tab' on switching between domains on the laptop screen. The keyboard
> is certainly PS/2 so I wonder how they "injected" the keyboard in the
> guest.
> It might be curious to look at their patches:
> http://xen.org/products/xci_source.html
>
>
>

--14dae9399dcdcbd1d604b5a98f11
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

the synergy incompatibilities were largely package related, due to requirem=
ents for a different application that we were supposed to deploy. =A0I&#39;=
ll try the ioperm patches next chance I have.<br><br><div class=3D"gmail_qu=
ote">
On Tue, Jan 3, 2012 at 5:40 PM, Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt=
;<a href=3D"mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Tue, Jan 03, 2012 at 03:45:17PM =
-0500, John Sherwood wrote:<br>
&gt; On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk &lt;<br>
&gt; <a href=3D"mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&g=
t; wrote:<br>
&gt;<br>
&gt; &gt; On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:<br=
>
&gt; &gt; &gt; Hello,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;m working on a project and trying to pass through a PS=
/2 mouse +<br>
&gt; &gt; keyboard<br>
&gt; &gt; &gt; to a hardware VM. =A0I&#39;ve played with numerous things (i=
ncluding the<br>
&gt; &gt; obvious,<br>
&gt; &gt; &gt; using USB), but after finding no alternative, it seems like =
the best way<br>
&gt; &gt; to<br>
&gt; &gt; &gt; approach this would be to modify qemu-dm to pipe through dat=
a from<br>
&gt; &gt; &gt; /dev/input/eventwhatever to the keyboard/mouse that qemu pro=
vides (and<br>
&gt; &gt; then<br>
&gt; &gt; &gt; using this version of qemu-dm only for this special case).<b=
r>
&gt; &gt;<br>
&gt; &gt; That is certainly one way. But you would have an interesting prob=
lem that<br>
&gt; &gt; whatever<br>
&gt; &gt; you type on your physical keyboard would appear in the guest _and=
_ in the<br>
&gt; &gt; domain 0.<br>
&gt; &gt;<br>
&gt;<br>
&gt; yeah, I actually tested it and it was quite amusing to watch the keybo=
ard<br>
&gt; and mouse move on the monitor and in VNC.<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;ve been looking through the 4.1.0 source, specifically=
 in<br>
&gt; &gt; &gt; tools/ioemu-qemu-xen, and it appears that I&#39;d want to (f=
or the keyboard)<br>
&gt; &gt; &gt; pass key codes from /dev/input through the kbd_put_keycode f=
unction.<br>
&gt; &gt; =A0From<br>
&gt; &gt; &gt; what I can tell, I&#39;d probably want to split off a thread=
 to do this<br>
&gt; &gt; &gt; somewhere in main() in vl.c. =A0I was hoping that I could ge=
t some<br>
&gt; &gt; &gt; confirmation about whether I&#39;m looking in the right plac=
es and/or<br>
&gt; &gt; &gt; suggestions about how to cleanly implement this. =A0Odds are=
 I won&#39;t be<br>
&gt; &gt; able<br>
&gt; &gt; &gt; to go the whole 9 yards and implement configuration options =
for xm or<br>
&gt; &gt; &gt; command line switches for qemu-dm, but I would suspect that =
someone,<br>
&gt; &gt; &gt; somewhere, someday will also want this kind of ability. =A0I=
f it&#39;s already<br>
&gt; &gt; &gt; possible to pass through PS/2 devices without getting nuts i=
n QEMU,<br>
&gt; &gt; that&#39;s<br>
&gt; &gt; &gt; cool too :)<br>
&gt; &gt;<br>
&gt; &gt; Can&#39;t do that. The PS/2 is one of those legacy beasts that de=
pends on<br>
&gt; &gt; ioports.<br>
&gt; &gt; But now that I think of it, maybe you can. In the guest config yo=
u can<br>
&gt; &gt; specify<br>
&gt; &gt; the ioports that you want to pass in. I hadn&#39;t tried to do th=
is for the<br>
&gt; &gt; keyboard<br>
&gt; &gt; ports but maybe that will work for you?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; I tried forwarding the ioports (off the top of my head, I remember try=
ing<br>
&gt; 60 and 64) but didn&#39;t have any luck - the kb/mouse weren&#39;t for=
warded<br>
&gt; despite adding the requisite ioports config as per the docs. =A0I theo=
rized I<br>
&gt; was leaving off some config for the kernel, but didn&#39;t find anythi=
ng. =A0I<br>
&gt; agree that it certainly seems like this should work, and if you could<=
br>
&gt; elaborate on anything I could have goofed on, that would certainly be =
great<br>
&gt; (and hopefully, useful for anyone else who might try this in the futur=
e)<br>
<br>
</div></div>I think you might be missing the ioperm patches. The are in dev=
el/ioperm<br>
on git://<a href=3D"http://git.kernel.org/pub/scm/linux/kernel/git/konrad/x=
en.git" target=3D"_blank">git.kernel.org/pub/scm/linux/kernel/git/konrad/xe=
n.git</a><br>
<div class=3D"im"><br>
&gt;<br>
&gt;<br>
&gt; &gt; Or could you use synergy?<br>
&gt; &gt;<br>
&gt;<br>
&gt; I actually did try synergy, but I couldn&#39;t get it to work due to<b=
r>
&gt; requirements for the OSes that were being run.<br>
<br>
</div>Huh? What OS is that? Anyhow another thought that occured to me is<br=
>
what Virtual Computer or Xen Client Project do.. which is something<br>
I don&#39;t really know what they do but their demo showed the user hitting=
<br>
&#39;Alt-Tab&#39; on switching between domains on the laptop screen. The ke=
yboard<br>
is certainly PS/2 so I wonder how they &quot;injected&quot; the keyboard in=
 the guest.<br>
It might be curious to look at their patches: <a href=3D"http://xen.org/pro=
ducts/xci_source.html" target=3D"_blank">http://xen.org/products/xci_source=
.html</a><br>
<br>
<br>
</blockquote></div><br>

--14dae9399dcdcbd1d604b5a98f11--


--===============3152918086423446408==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3152918086423446408==--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:13:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:13:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCET-0007yR-9r; Mon, 09 Jan 2012 10:13:37 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <theubaz@gmail.com>) id 1RiFSo-0003Gu-DC
	for xen-devel@lists.xensource.com; Wed, 04 Jan 2012 01:16:22 +0000
X-Env-Sender: theubaz@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1325639773!9489435!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30045 invoked from network); 4 Jan 2012 01:16:15 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	4 Jan 2012 01:16:15 -0000
Received: by iagw33 with SMTP id w33so148360800iag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 03 Jan 2012 17:16:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=Drmv7WBHivvS1VodLrxiJF2DfjCWfrtDRgxmMFTPUwI=;
	b=t2iXiPG3UOG/DnJSG5a+LrKcZfnsPA7o9bPSCawUkPQPNvz9jgp+cYvqmLF8smC4ez
	EokZQRghE2rNBBiNlwGa7K82k/+1/wSI8VSYnr7yqSjqHPe8onky9jGP8l37kwsS9gYp
	ILxZytudGFyfKjLGVf8P3/z9ymV8k3Tr+9tjg=
MIME-Version: 1.0
Received: by 10.50.159.131 with SMTP id xc3mr64454569igb.27.1325639773442;
	Tue, 03 Jan 2012 17:16:13 -0800 (PST)
Received: by 10.42.97.73 with HTTP; Tue, 3 Jan 2012 17:16:13 -0800 (PST)
In-Reply-To: <20120103224040.GC12939@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
	<20120103224040.GC12939@phenom.dumpdata.com>
Date: Tue, 3 Jan 2012 20:16:13 -0500
X-Google-Sender-Auth: MPRUEly_qSGby6v-71KSGAtyqX8
Message-ID: <CAH5ygH26OBci9U0ogRaH0n_xzEo38csr9H5dUWyvUdH=1hSGGQ@mail.gmail.com>
From: John Sherwood <jrs@vt.edu>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailman-Approved-At: Mon, 09 Jan 2012 10:13:34 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] extending 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="===============3152918086423446408=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3152918086423446408==
Content-Type: multipart/alternative; boundary=14dae9399dcdcbd1d604b5a98f11

--14dae9399dcdcbd1d604b5a98f11
Content-Type: text/plain; charset=ISO-8859-1

the synergy incompatibilities were largely package related, due to
requirements for a different application that we were supposed to deploy.
 I'll try the ioperm patches next chance I have.

On Tue, Jan 3, 2012 at 5:40 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> On Tue, Jan 03, 2012 at 03:45:17PM -0500, John Sherwood wrote:
> > On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
> > konrad.wilk@oracle.com> wrote:
> >
> > > On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:
> > > > Hello,
> > > >
> > > > I'm working on a project and trying to pass through a PS/2 mouse +
> > > keyboard
> > > > to a hardware VM.  I've played with numerous things (including the
> > > obvious,
> > > > using USB), but after finding no alternative, it seems like the best
> way
> > > to
> > > > approach this would be to modify qemu-dm to pipe through data from
> > > > /dev/input/eventwhatever to the keyboard/mouse that qemu provides
> (and
> > > then
> > > > using this version of qemu-dm only for this special case).
> > >
> > > That is certainly one way. But you would have an interesting problem
> that
> > > whatever
> > > you type on your physical keyboard would appear in the guest _and_ in
> the
> > > domain 0.
> > >
> >
> > yeah, I actually tested it and it was quite amusing to watch the keyboard
> > and mouse move on the monitor and in VNC.
> >
> >
> > >
> > > >
> > > > I've been looking through the 4.1.0 source, specifically in
> > > > tools/ioemu-qemu-xen, and it appears that I'd want to (for the
> keyboard)
> > > > pass key codes from /dev/input through the kbd_put_keycode function.
> > >  From
> > > > what I can tell, I'd probably want to split off a thread to do this
> > > > somewhere in main() in vl.c.  I was hoping that I could get some
> > > > confirmation about whether I'm looking in the right places and/or
> > > > suggestions about how to cleanly implement this.  Odds are I won't be
> > > able
> > > > to go the whole 9 yards and implement configuration options for xm or
> > > > command line switches for qemu-dm, but I would suspect that someone,
> > > > somewhere, someday will also want this kind of ability.  If it's
> already
> > > > possible to pass through PS/2 devices without getting nuts in QEMU,
> > > that's
> > > > cool too :)
> > >
> > > Can't do that. The PS/2 is one of those legacy beasts that depends on
> > > ioports.
> > > But now that I think of it, maybe you can. In the guest config you can
> > > specify
> > > the ioports that you want to pass in. I hadn't tried to do this for the
> > > keyboard
> > > ports but maybe that will work for you?
> > >
> > >
> > I tried forwarding the ioports (off the top of my head, I remember trying
> > 60 and 64) but didn't have any luck - the kb/mouse weren't forwarded
> > despite adding the requisite ioports config as per the docs.  I
> theorized I
> > was leaving off some config for the kernel, but didn't find anything.  I
> > agree that it certainly seems like this should work, and if you could
> > elaborate on anything I could have goofed on, that would certainly be
> great
> > (and hopefully, useful for anyone else who might try this in the future)
>
> I think you might be missing the ioperm patches. The are in devel/ioperm
> on git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
>
> >
> >
> > > Or could you use synergy?
> > >
> >
> > I actually did try synergy, but I couldn't get it to work due to
> > requirements for the OSes that were being run.
>
> Huh? What OS is that? Anyhow another thought that occured to me is
> what Virtual Computer or Xen Client Project do.. which is something
> I don't really know what they do but their demo showed the user hitting
> 'Alt-Tab' on switching between domains on the laptop screen. The keyboard
> is certainly PS/2 so I wonder how they "injected" the keyboard in the
> guest.
> It might be curious to look at their patches:
> http://xen.org/products/xci_source.html
>
>
>

--14dae9399dcdcbd1d604b5a98f11
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

the synergy incompatibilities were largely package related, due to requirem=
ents for a different application that we were supposed to deploy. =A0I&#39;=
ll try the ioperm patches next chance I have.<br><br><div class=3D"gmail_qu=
ote">
On Tue, Jan 3, 2012 at 5:40 PM, Konrad Rzeszutek Wilk <span dir=3D"ltr">&lt=
;<a href=3D"mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Tue, Jan 03, 2012 at 03:45:17PM =
-0500, John Sherwood wrote:<br>
&gt; On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk &lt;<br>
&gt; <a href=3D"mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&g=
t; wrote:<br>
&gt;<br>
&gt; &gt; On Wed, Nov 16, 2011 at 03:26:06PM -0500, John Sherwood wrote:<br=
>
&gt; &gt; &gt; Hello,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;m working on a project and trying to pass through a PS=
/2 mouse +<br>
&gt; &gt; keyboard<br>
&gt; &gt; &gt; to a hardware VM. =A0I&#39;ve played with numerous things (i=
ncluding the<br>
&gt; &gt; obvious,<br>
&gt; &gt; &gt; using USB), but after finding no alternative, it seems like =
the best way<br>
&gt; &gt; to<br>
&gt; &gt; &gt; approach this would be to modify qemu-dm to pipe through dat=
a from<br>
&gt; &gt; &gt; /dev/input/eventwhatever to the keyboard/mouse that qemu pro=
vides (and<br>
&gt; &gt; then<br>
&gt; &gt; &gt; using this version of qemu-dm only for this special case).<b=
r>
&gt; &gt;<br>
&gt; &gt; That is certainly one way. But you would have an interesting prob=
lem that<br>
&gt; &gt; whatever<br>
&gt; &gt; you type on your physical keyboard would appear in the guest _and=
_ in the<br>
&gt; &gt; domain 0.<br>
&gt; &gt;<br>
&gt;<br>
&gt; yeah, I actually tested it and it was quite amusing to watch the keybo=
ard<br>
&gt; and mouse move on the monitor and in VNC.<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;ve been looking through the 4.1.0 source, specifically=
 in<br>
&gt; &gt; &gt; tools/ioemu-qemu-xen, and it appears that I&#39;d want to (f=
or the keyboard)<br>
&gt; &gt; &gt; pass key codes from /dev/input through the kbd_put_keycode f=
unction.<br>
&gt; &gt; =A0From<br>
&gt; &gt; &gt; what I can tell, I&#39;d probably want to split off a thread=
 to do this<br>
&gt; &gt; &gt; somewhere in main() in vl.c. =A0I was hoping that I could ge=
t some<br>
&gt; &gt; &gt; confirmation about whether I&#39;m looking in the right plac=
es and/or<br>
&gt; &gt; &gt; suggestions about how to cleanly implement this. =A0Odds are=
 I won&#39;t be<br>
&gt; &gt; able<br>
&gt; &gt; &gt; to go the whole 9 yards and implement configuration options =
for xm or<br>
&gt; &gt; &gt; command line switches for qemu-dm, but I would suspect that =
someone,<br>
&gt; &gt; &gt; somewhere, someday will also want this kind of ability. =A0I=
f it&#39;s already<br>
&gt; &gt; &gt; possible to pass through PS/2 devices without getting nuts i=
n QEMU,<br>
&gt; &gt; that&#39;s<br>
&gt; &gt; &gt; cool too :)<br>
&gt; &gt;<br>
&gt; &gt; Can&#39;t do that. The PS/2 is one of those legacy beasts that de=
pends on<br>
&gt; &gt; ioports.<br>
&gt; &gt; But now that I think of it, maybe you can. In the guest config yo=
u can<br>
&gt; &gt; specify<br>
&gt; &gt; the ioports that you want to pass in. I hadn&#39;t tried to do th=
is for the<br>
&gt; &gt; keyboard<br>
&gt; &gt; ports but maybe that will work for you?<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; I tried forwarding the ioports (off the top of my head, I remember try=
ing<br>
&gt; 60 and 64) but didn&#39;t have any luck - the kb/mouse weren&#39;t for=
warded<br>
&gt; despite adding the requisite ioports config as per the docs. =A0I theo=
rized I<br>
&gt; was leaving off some config for the kernel, but didn&#39;t find anythi=
ng. =A0I<br>
&gt; agree that it certainly seems like this should work, and if you could<=
br>
&gt; elaborate on anything I could have goofed on, that would certainly be =
great<br>
&gt; (and hopefully, useful for anyone else who might try this in the futur=
e)<br>
<br>
</div></div>I think you might be missing the ioperm patches. The are in dev=
el/ioperm<br>
on git://<a href=3D"http://git.kernel.org/pub/scm/linux/kernel/git/konrad/x=
en.git" target=3D"_blank">git.kernel.org/pub/scm/linux/kernel/git/konrad/xe=
n.git</a><br>
<div class=3D"im"><br>
&gt;<br>
&gt;<br>
&gt; &gt; Or could you use synergy?<br>
&gt; &gt;<br>
&gt;<br>
&gt; I actually did try synergy, but I couldn&#39;t get it to work due to<b=
r>
&gt; requirements for the OSes that were being run.<br>
<br>
</div>Huh? What OS is that? Anyhow another thought that occured to me is<br=
>
what Virtual Computer or Xen Client Project do.. which is something<br>
I don&#39;t really know what they do but their demo showed the user hitting=
<br>
&#39;Alt-Tab&#39; on switching between domains on the laptop screen. The ke=
yboard<br>
is certainly PS/2 so I wonder how they &quot;injected&quot; the keyboard in=
 the guest.<br>
It might be curious to look at their patches: <a href=3D"http://xen.org/pro=
ducts/xci_source.html" target=3D"_blank">http://xen.org/products/xci_source=
.html</a><br>
<br>
<br>
</blockquote></div><br>

--14dae9399dcdcbd1d604b5a98f11--


--===============3152918086423446408==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3152918086423446408==--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:28:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCSE-0002S9-4e; Mon, 09 Jan 2012 10:27:50 +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 1RkCSC-0002RY-JF; Mon, 09 Jan 2012 10:27:48 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326104861!8348983!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7590 invoked from network); 9 Jan 2012 10:27:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 10:27:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9891964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 10:27:40 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 9 Jan 2012
	10:27:40 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: R J <torushikeshj@gmail.com>
Date: Mon, 9 Jan 2012 10:27:47 +0000
Thread-Topic: [Xen-devel] BalloonWorkerThread issue
Thread-Index: AczMt/AVTo7HS+tsRui662n4jw959ACAM22Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED19FB@LONPMAILBOX01.citrite.net>
References: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
	<20120103175243.GE749@andromeda.dapyr.net>
	<CAO14VsPre0ScNOfDNSxMKCPvVKRWCOkTVHL_SbF8KZkacSDDAQ@mail.gmail.com>
	<20120104160725.GM3322@phenom.dumpdata.com>
	<CAO14VsMWuZ7EuxZ0yP132G9LN+XvNyEVa+0zBjTeZAp_QzemDw@mail.gmail.com>
	<20120106150904.GD5855@phenom.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022B598ED1982@LONPMAILBOX01.citrite.net>
	<CAO14VsNB=LgDYe_eYQK6EXyP2KTH3o7EW0rzkHmunnBAroo-xA@mail.gmail.com>
In-Reply-To: <CAO14VsNB=LgDYe_eYQK6EXyP2KTH3o7EW0rzkHmunnBAroo-xA@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--
From: R J [mailto:torushikeshj@gmail.com] =

Sent: 06 January 2012 21:13
To: Paul Durrant
Cc: Konrad Rzeszutek Wilk; annie.li@oracle.com; Konrad Rzeszutek Wilk; xen-=
devel@lists.xensource.com; xen-users@lists.xensource.com; xen-api@lists.xen=
source.com
Subject: Re: [Xen-devel] BalloonWorkerThread issue

Hello Paul,

Thanks for your email and explanation.=A0 =


I'm trying multiple combinations and found that windows will run stable onl=
y if the static max is twice bigger.
I did the test on below static min and max

512MB to 2GB=A0=A0 <- Pass
1GB to 4 GB=A0=A0=A0 <-=A0 Some times pass, some time fails
2GB to 4GB <- Pass
2GB to 8 GB <- Pass
4GB to 32 GB <-- Fail
16GB to 32GB <-- Pass


So it seems that the problem is not due to size of RAM but its due to diffe=
rence between them.
Is there any defined multiplication factor while initial squeeze down ?

Interesting thing is if I start a VM with Static max 32GB and dynamic max, =
dynamic min 32GB and static min 512MB then it starts fine and is able to bo=
ot successfully. The reason here is no ballooning required as target is equ=
al to static max.

Once the VM is up and if I set its memory target to 1 GB ( squeezing from 3=
2G to 1G)=A0 it works fine. No issue of balloon driver or anything.
So I did same for other cases as well where static max and target were same=
. The result was "pass".

Its only the boot process which is hampered.
--

I believe top-posting is against etiquette for this list so I won't continu=
e it...

I don't think anyone has ever determined a multiplication factor that will =
cover *any* windows sku... there's too much variation between them. It's no=
t that surprising that ballooning down after boot gives better results sinc=
e booting will almost certainly require more code and data to be paged in.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:28:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCSE-0002S9-4e; Mon, 09 Jan 2012 10:27:50 +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 1RkCSC-0002RY-JF; Mon, 09 Jan 2012 10:27:48 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326104861!8348983!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7590 invoked from network); 9 Jan 2012 10:27:41 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 10:27:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9891964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 10:27:40 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 9 Jan 2012
	10:27:40 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: R J <torushikeshj@gmail.com>
Date: Mon, 9 Jan 2012 10:27:47 +0000
Thread-Topic: [Xen-devel] BalloonWorkerThread issue
Thread-Index: AczMt/AVTo7HS+tsRui662n4jw959ACAM22Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED19FB@LONPMAILBOX01.citrite.net>
References: <CAO14VsO7N4LAOtnuTokrhZUy8dO4BLOw165V2F9E3LxJ=ojzyA@mail.gmail.com>
	<20120103175243.GE749@andromeda.dapyr.net>
	<CAO14VsPre0ScNOfDNSxMKCPvVKRWCOkTVHL_SbF8KZkacSDDAQ@mail.gmail.com>
	<20120104160725.GM3322@phenom.dumpdata.com>
	<CAO14VsMWuZ7EuxZ0yP132G9LN+XvNyEVa+0zBjTeZAp_QzemDw@mail.gmail.com>
	<20120106150904.GD5855@phenom.dumpdata.com>
	<291EDFCB1E9E224A99088639C4762022B598ED1982@LONPMAILBOX01.citrite.net>
	<CAO14VsNB=LgDYe_eYQK6EXyP2KTH3o7EW0rzkHmunnBAroo-xA@mail.gmail.com>
In-Reply-To: <CAO14VsNB=LgDYe_eYQK6EXyP2KTH3o7EW0rzkHmunnBAroo-xA@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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [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>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--
From: R J [mailto:torushikeshj@gmail.com] =

Sent: 06 January 2012 21:13
To: Paul Durrant
Cc: Konrad Rzeszutek Wilk; annie.li@oracle.com; Konrad Rzeszutek Wilk; xen-=
devel@lists.xensource.com; xen-users@lists.xensource.com; xen-api@lists.xen=
source.com
Subject: Re: [Xen-devel] BalloonWorkerThread issue

Hello Paul,

Thanks for your email and explanation.=A0 =


I'm trying multiple combinations and found that windows will run stable onl=
y if the static max is twice bigger.
I did the test on below static min and max

512MB to 2GB=A0=A0 <- Pass
1GB to 4 GB=A0=A0=A0 <-=A0 Some times pass, some time fails
2GB to 4GB <- Pass
2GB to 8 GB <- Pass
4GB to 32 GB <-- Fail
16GB to 32GB <-- Pass


So it seems that the problem is not due to size of RAM but its due to diffe=
rence between them.
Is there any defined multiplication factor while initial squeeze down ?

Interesting thing is if I start a VM with Static max 32GB and dynamic max, =
dynamic min 32GB and static min 512MB then it starts fine and is able to bo=
ot successfully. The reason here is no ballooning required as target is equ=
al to static max.

Once the VM is up and if I set its memory target to 1 GB ( squeezing from 3=
2G to 1G)=A0 it works fine. No issue of balloon driver or anything.
So I did same for other cases as well where static max and target were same=
. The result was "pass".

Its only the boot process which is hampered.
--

I believe top-posting is against etiquette for this list so I won't continu=
e it...

I don't think anyone has ever determined a multiplication factor that will =
cover *any* windows sku... there's too much variation between them. It's no=
t that surprising that ballooning down after boot gives better results sinc=
e booting will almost certainly require more code and data to be paged in.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:28:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCSj-0002Vv-9h; Mon, 09 Jan 2012 10:28:21 +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 1RkCSh-0002Uz-PW
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:28:20 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326104891!8317929!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 1665 invoked from network); 9 Jan 2012 10:28:12 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 10:28:12 -0000
Received: by vcbfl11 with SMTP id fl11so10042095vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 02:28: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:content-transfer-encoding;
	bh=0BgVaFoRm9y7HgTTM8cdMfJTSm5RXhIuQLbJfPXaf6w=;
	b=qyuG+eCsf6TvRik11LxnEfj+qSCqWoK0qUCQSN/N3kVi5JdpYGnNJOkwdBVq/L3Efe
	cjotvWyRWN7B2vYEGv5FbaJycwAizBkp3rnOooe20W2YRUdjavgNiOb2OXF4GrT+1Tez
	NqQEScxRMlnUAu0erjRmt7dPKo+0b4vFY2DB8=
Received: by 10.220.157.17 with SMTP id z17mr8677639vcw.73.1326104891125; Mon,
	09 Jan 2012 02:28:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.108.207 with HTTP; Mon, 9 Jan 2012 02:27:50 -0800 (PST)
In-Reply-To: <20120104142539.GA3322@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
	<20120103224040.GC12939@phenom.dumpdata.com>
	<CAH5ygH26OBci9U0ogRaH0n_xzEo38csr9H5dUWyvUdH=1hSGGQ@mail.gmail.com>
	<20120104142539.GA3322@phenom.dumpdata.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 9 Jan 2012 10:27:50 +0000
Message-ID: <CAEBdQ90AAUmffY7NaC+SO5UEwwbpN51gnYJJ+5VfNFcU9ZpWLw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, John Sherwood <jrs@vt.edu>
Subject: Re: [Xen-devel] extending 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 4 January 2012 14:25, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wro=
te:
> On Tue, Jan 03, 2012 at 08:16:13PM -0500, John Sherwood wrote:
>> the synergy incompatibilities were largely package related, due to
>> requirements for a different application that we were supposed to deploy.
>> =A0I'll try the ioperm patches next chance I have.
>
> Please don't top post.
>
>> > http://xen.org/products/xci_source.html
>
> (the ioemu-pq git tree, look for 'ps2-passthrough')
>
> .. has a driver in userspace that actually takes PS/2 input and shovels
> them using QEMU to the guest. That might be interesting for you to look at
> as well.
>

Hi,

This patch is at a very rough stage.

The best way to do what you want would be to open the HID device
directly (/dev/event*) from Qemu
and forward the event to do the PS2 device model.
That works fine until you want to share the input between multiple VM,
at this point you probably
what a new daemon to play the gate keeper.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:28:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10: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 1RkCSj-0002Vv-9h; Mon, 09 Jan 2012 10:28:21 +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 1RkCSh-0002Uz-PW
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:28:20 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326104891!8317929!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 1665 invoked from network); 9 Jan 2012 10:28:12 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 10:28:12 -0000
Received: by vcbfl11 with SMTP id fl11so10042095vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 02:28: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:content-transfer-encoding;
	bh=0BgVaFoRm9y7HgTTM8cdMfJTSm5RXhIuQLbJfPXaf6w=;
	b=qyuG+eCsf6TvRik11LxnEfj+qSCqWoK0qUCQSN/N3kVi5JdpYGnNJOkwdBVq/L3Efe
	cjotvWyRWN7B2vYEGv5FbaJycwAizBkp3rnOooe20W2YRUdjavgNiOb2OXF4GrT+1Tez
	NqQEScxRMlnUAu0erjRmt7dPKo+0b4vFY2DB8=
Received: by 10.220.157.17 with SMTP id z17mr8677639vcw.73.1326104891125; Mon,
	09 Jan 2012 02:28:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.108.207 with HTTP; Mon, 9 Jan 2012 02:27:50 -0800 (PST)
In-Reply-To: <20120104142539.GA3322@phenom.dumpdata.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
	<20120103224040.GC12939@phenom.dumpdata.com>
	<CAH5ygH26OBci9U0ogRaH0n_xzEo38csr9H5dUWyvUdH=1hSGGQ@mail.gmail.com>
	<20120104142539.GA3322@phenom.dumpdata.com>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 9 Jan 2012 10:27:50 +0000
Message-ID: <CAEBdQ90AAUmffY7NaC+SO5UEwwbpN51gnYJJ+5VfNFcU9ZpWLw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com, John Sherwood <jrs@vt.edu>
Subject: Re: [Xen-devel] extending 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 4 January 2012 14:25, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wro=
te:
> On Tue, Jan 03, 2012 at 08:16:13PM -0500, John Sherwood wrote:
>> the synergy incompatibilities were largely package related, due to
>> requirements for a different application that we were supposed to deploy.
>> =A0I'll try the ioperm patches next chance I have.
>
> Please don't top post.
>
>> > http://xen.org/products/xci_source.html
>
> (the ioemu-pq git tree, look for 'ps2-passthrough')
>
> .. has a driver in userspace that actually takes PS/2 input and shovels
> them using QEMU to the guest. That might be interesting for you to look at
> as well.
>

Hi,

This patch is at a very rough stage.

The best way to do what you want would be to open the HID device
directly (/dev/event*) from Qemu
and forward the event to do the PS2 device model.
That works fine until you want to share the input between multiple VM,
at this point you probably
what a new daemon to play the gate keeper.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 10:37:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCbr-0003FQ-Ce; Mon, 09 Jan 2012 10:37:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkCbp-0003FA-Vi
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:37:46 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326105459!10111657!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzEwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14123 invoked from network); 9 Jan 2012 10:37:39 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-6.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 10:37:39 -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 q09AbXe1008529;
	Mon, 9 Jan 2012 05:37:33 -0500
Date: Mon, 09 Jan 2012 05:37:33 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <alpine.DEB.2.00.1201061648440.3150@kaball-desktop>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > XEN_DOM0 is a silent option that has been automatically selected
> > when
> > CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was
> > changed
> > to a menu configurable option then it would only give users the
> > ability
> > to compile out about 100 kbytes of code.
> 
> I think that it is less than that because backends are not tied to
> dom0
> in any way, even though currently they cannot be compiled without
> XEN_DOM0.
> Running a network or block backend in domU is a well known
> configuration.
> Therefore the code compiled out only amounts to about 10K.
> 
> 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 8795480..0725228 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
> >  
> >  config XEN_BACKEND
> >  	bool "Backend driver support"
> > -	depends on XEN_DOM0
> >  	default y
> > +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> >  	help
> >  	  Support for backend device drivers that provide I/O services
> >  	  to other virtual machines.
> 
> I think we can trimmer the dependency list here: after all backends
> can
> be run in unpriviledged guests as well (see driver domains).
> So I think it should depend only on XEN.

Hmm.. Actually, with dependency lists in mind, I think a really messed
this patch up. I should have either had CONFIG_XEN inherit these deps,
or I should have spread them around to be required at only the specific
places they're needed, and then left the stub functions in. Neither of
those options seems like a good idea to me. We either force all XEN
guests to always have all the deps needed for an initial domain, which
is exactly the opposite of the suggestion above (trimming XEN_BACKEND
deps for driver domains), or we actually make the code messier and
more complicated with more #ifdefs, which are now neatly packaged with
XEN_DOM0.

The driver domain concept may actually be the technical need for
making XEN_DOM0 optional. If we want the ability to build a minimally
configed XEN kernel to be used as a driver domain, then it doesn't
seem like we'd want it to also be capable of running as an initial
domain, or to be forced to have all the dependencies and code of an
initial domain.

With that in mind, I propose we go back to my initial patch, relax
deps for XEN_BACKEND, and double check that each individual backend
has the appropriate minimal deps. In general, it should be a goal to
make sure most XEN options are menu selectable and that all dep lists
are minimized in order to make sure driver domains can be built with
minimal configs.

Drew

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 10:37:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCbr-0003FQ-Ce; Mon, 09 Jan 2012 10:37:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkCbp-0003FA-Vi
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:37:46 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326105459!10111657!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzEwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14123 invoked from network); 9 Jan 2012 10:37:39 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-6.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 10:37:39 -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 q09AbXe1008529;
	Mon, 9 Jan 2012 05:37:33 -0500
Date: Mon, 09 Jan 2012 05:37:33 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <alpine.DEB.2.00.1201061648440.3150@kaball-desktop>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Fri, 6 Jan 2012, Andrew Jones wrote:
> > XEN_DOM0 is a silent option that has been automatically selected
> > when
> > CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was
> > changed
> > to a menu configurable option then it would only give users the
> > ability
> > to compile out about 100 kbytes of code.
> 
> I think that it is less than that because backends are not tied to
> dom0
> in any way, even though currently they cannot be compiled without
> XEN_DOM0.
> Running a network or block backend in domU is a well known
> configuration.
> Therefore the code compiled out only amounts to about 10K.
> 
> 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 8795480..0725228 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
> >  
> >  config XEN_BACKEND
> >  	bool "Backend driver support"
> > -	depends on XEN_DOM0
> >  	default y
> > +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> >  	help
> >  	  Support for backend device drivers that provide I/O services
> >  	  to other virtual machines.
> 
> I think we can trimmer the dependency list here: after all backends
> can
> be run in unpriviledged guests as well (see driver domains).
> So I think it should depend only on XEN.

Hmm.. Actually, with dependency lists in mind, I think a really messed
this patch up. I should have either had CONFIG_XEN inherit these deps,
or I should have spread them around to be required at only the specific
places they're needed, and then left the stub functions in. Neither of
those options seems like a good idea to me. We either force all XEN
guests to always have all the deps needed for an initial domain, which
is exactly the opposite of the suggestion above (trimming XEN_BACKEND
deps for driver domains), or we actually make the code messier and
more complicated with more #ifdefs, which are now neatly packaged with
XEN_DOM0.

The driver domain concept may actually be the technical need for
making XEN_DOM0 optional. If we want the ability to build a minimally
configed XEN kernel to be used as a driver domain, then it doesn't
seem like we'd want it to also be capable of running as an initial
domain, or to be forced to have all the dependencies and code of an
initial domain.

With that in mind, I propose we go back to my initial patch, relax
deps for XEN_BACKEND, and double check that each individual backend
has the appropriate minimal deps. In general, it should be a goal to
make sure most XEN options are menu selectable and that all dep lists
are minimized in order to make sure driver domains can be built with
minimal configs.

Drew

> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 10:44:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:44:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCiR-0003WL-8j; Mon, 09 Jan 2012 10:44:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkCiQ-0003WG-9O
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:44:34 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326105867!10105155!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjM5MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19315 invoked from network); 9 Jan 2012 10:44:27 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-4.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 10:44:27 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q09AhU9p030084;
	Mon, 9 Jan 2012 05:43:30 -0500
Date: Mon, 09 Jan 2012 05:43:30 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Message-ID: <725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120109075911.GA4049@core.coreip.homeip.net>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>, FlorianSchandinat@gmx.de,
	virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 -----
> Hi Andrew,
> 
> On Fri, Jan 06, 2012 at 10:58:06AM -0500, Andrew Jones wrote:
> > 
> > 
> > ----- Original Message -----
> > > On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> > > > PV-on-HVM guests may want to use the xen keyboard/mouse
> > > > frontend,
> > > > but
> > > > they don't use the xen frame buffer frontend. For this case it
> > > > doesn't
> > > > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > > > XEN_FBDEV_FRONTEND. The opposite direction always makes more
> > > > sense,
> > > > i.e.
> > > > if you're using xenfb, then you'll want xenkbd. Switch the
> > > > dependencies.
> > > 
> > > You need to CC as well these people that have 'maintainer' field
> > > on
> > > them:
> > > 
> > > konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> > > drivers/video/Kconfig
> > > Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > > (maintainer:FRAMEBUFFER LAYER)
> > > linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
> > > linux-kernel@vger.kernel.org (open list)
> > > konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> > > drivers/input/misc/Kconfig
> > > Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT
> > > (KEYBOARD,...,commit_signer:9/16=56%)
> > > Samuel Ortiz <sameo@linux.intel.com> (commit_signer:3/16=19%)
> > > Anirudh Ghayal <aghayal@codeaurora.org> (commit_signer:2/16=12%)
> > > Peter Ujfalusi <peter.ujfalusi@ti.com> (commit_signer:2/16=12%)
> > > Alan Cox <alan@linux.intel.com> (commit_signer:2/16=12%)
> > > linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
> > > linux-kernel@vger.kernel.org (open list)
> > > 
> > 
> > Thanks. Replied with them in CC.
> > 
> > Drew
> > 
> > > > 
> > > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > > ---
> > > >  drivers/input/misc/Kconfig |    2 +-
> > > >  drivers/video/Kconfig      |    1 +
> > > >  2 files changed, 2 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/input/misc/Kconfig
> > > > b/drivers/input/misc/Kconfig
> > > > index 22d875f..36c15bf 100644
> > > > --- a/drivers/input/misc/Kconfig
> > > > +++ b/drivers/input/misc/Kconfig
> > > > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> > > >  
> > > >  config INPUT_XEN_KBDDEV_FRONTEND
> > > >  	tristate "Xen virtual keyboard and mouse support"
> > > > -	depends on XEN_FBDEV_FRONTEND
> > > > +	depends on XEN
> 
> This is OK with me.
> 
> > > >  	default y
> > > >  	select XEN_XENBUS_FRONTEND
> > > >  	help
> > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > index d83e967..269b299 100644
> > > > --- a/drivers/video/Kconfig
> > > > +++ b/drivers/video/Kconfig
> > > > @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
> > > >  	select FB_SYS_IMAGEBLIT
> > > >  	select FB_SYS_FOPS
> > > >  	select FB_DEFERRED_IO
> > > > +	select INPUT_XEN_KBDDEV_FRONTEND
> 
> But here you need to either depend on or select INPUT as select does
> not
> resolve dependencies for selected symbol.
> 

Would I actually need 'select INPUT' and select 'INPUT_MISC'? Maybe
'depends on' would just be cleaner and safer. I'll send a V2.

Thanks,
Drew


> Thanks.
> 
> --
> Dmitry
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 10:44:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:44:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCiR-0003WL-8j; Mon, 09 Jan 2012 10:44:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkCiQ-0003WG-9O
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:44:34 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326105867!10105155!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjM5MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19315 invoked from network); 9 Jan 2012 10:44:27 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-4.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 10:44:27 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q09AhU9p030084;
	Mon, 9 Jan 2012 05:43:30 -0500
Date: Mon, 09 Jan 2012 05:43:30 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Message-ID: <725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120109075911.GA4049@core.coreip.homeip.net>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>, FlorianSchandinat@gmx.de,
	virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 -----
> Hi Andrew,
> 
> On Fri, Jan 06, 2012 at 10:58:06AM -0500, Andrew Jones wrote:
> > 
> > 
> > ----- Original Message -----
> > > On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> > > > PV-on-HVM guests may want to use the xen keyboard/mouse
> > > > frontend,
> > > > but
> > > > they don't use the xen frame buffer frontend. For this case it
> > > > doesn't
> > > > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > > > XEN_FBDEV_FRONTEND. The opposite direction always makes more
> > > > sense,
> > > > i.e.
> > > > if you're using xenfb, then you'll want xenkbd. Switch the
> > > > dependencies.
> > > 
> > > You need to CC as well these people that have 'maintainer' field
> > > on
> > > them:
> > > 
> > > konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> > > drivers/video/Kconfig
> > > Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> > > (maintainer:FRAMEBUFFER LAYER)
> > > linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
> > > linux-kernel@vger.kernel.org (open list)
> > > konrad@phenom:~/work/linux$ scripts/get_maintainer.pl -f
> > > drivers/input/misc/Kconfig
> > > Dmitry Torokhov <dmitry.torokhov@gmail.com> (maintainer:INPUT
> > > (KEYBOARD,...,commit_signer:9/16=56%)
> > > Samuel Ortiz <sameo@linux.intel.com> (commit_signer:3/16=19%)
> > > Anirudh Ghayal <aghayal@codeaurora.org> (commit_signer:2/16=12%)
> > > Peter Ujfalusi <peter.ujfalusi@ti.com> (commit_signer:2/16=12%)
> > > Alan Cox <alan@linux.intel.com> (commit_signer:2/16=12%)
> > > linux-input@vger.kernel.org (open list:INPUT (KEYBOARD,...)
> > > linux-kernel@vger.kernel.org (open list)
> > > 
> > 
> > Thanks. Replied with them in CC.
> > 
> > Drew
> > 
> > > > 
> > > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > > ---
> > > >  drivers/input/misc/Kconfig |    2 +-
> > > >  drivers/video/Kconfig      |    1 +
> > > >  2 files changed, 2 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/input/misc/Kconfig
> > > > b/drivers/input/misc/Kconfig
> > > > index 22d875f..36c15bf 100644
> > > > --- a/drivers/input/misc/Kconfig
> > > > +++ b/drivers/input/misc/Kconfig
> > > > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> > > >  
> > > >  config INPUT_XEN_KBDDEV_FRONTEND
> > > >  	tristate "Xen virtual keyboard and mouse support"
> > > > -	depends on XEN_FBDEV_FRONTEND
> > > > +	depends on XEN
> 
> This is OK with me.
> 
> > > >  	default y
> > > >  	select XEN_XENBUS_FRONTEND
> > > >  	help
> > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > index d83e967..269b299 100644
> > > > --- a/drivers/video/Kconfig
> > > > +++ b/drivers/video/Kconfig
> > > > @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
> > > >  	select FB_SYS_IMAGEBLIT
> > > >  	select FB_SYS_FOPS
> > > >  	select FB_DEFERRED_IO
> > > > +	select INPUT_XEN_KBDDEV_FRONTEND
> 
> But here you need to either depend on or select INPUT as select does
> not
> resolve dependencies for selected symbol.
> 

Would I actually need 'select INPUT' and select 'INPUT_MISC'? Maybe
'depends on' would just be cleaner and safer. I'll send a V2.

Thanks,
Drew


> Thanks.
> 
> --
> Dmitry
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 10:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCko-0003bW-N2; Mon, 09 Jan 2012 10:47:02 +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 1RkCkm-0003b8-E3
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:47:00 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326106010!2361721!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 20629 invoked from network); 9 Jan 2012 10:46:51 -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;
	9 Jan 2012 10:46:51 -0000
Received: by iagw33 with SMTP id w33so34617281iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 02:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=SjPPA4H1PdnpJjykeke3GkkJEdxgw/9sDZFIGjzsZtM=;
	b=iw3PsASbXx7i5y/ULFgLhcZAihhOjOxah0AdG5WOxEmJUJRuy6PH5E2o0KA6BXFu13
	8ODlPhwkOitIfPNlnCfW29Lnryhv7tVRS+pVDpRDv3u2YE6JaiN1rBFlcwS3S+TfXG8p
	xFiU3LhmAHYTosxpLeBdNmnu8HW4tWEDnwnKE=
MIME-Version: 1.0
Received: by 10.43.53.1 with SMTP id vo1mr19286957icb.2.1326106005109; Mon, 09
	Jan 2012 02:46:45 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Mon, 9 Jan 2012 02:46:44 -0800 (PST)
In-Reply-To: <1325776621.2728.7.camel@Solace>
References: <1325776621.2728.7.camel@Solace>
Date: Mon, 9 Jan 2012 10:46:44 +0000
X-Google-Sender-Auth: oYj7f5ntX2ynr7HIiLaMZ73VEcg
Message-ID: <CAFLBxZZz19COBDvdmWmKFsr4MOSxQtxAZRYz6vBYudXFJANxtA@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] [PATCHv3] 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 Thu, Jan 5, 2012 at 3:17 PM, 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.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Looks good -- thanks, Dario.

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

>
> diff -r efaa28639a71 xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/common/sched_sedf.c =A0 Thu Jan 05 15:02:30 2012 +0100
> @@ -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)
>
> @@ -71,34 +63,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 /* =3D worst 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
> @@ -165,18 +158,17 @@ 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{
> @@ -185,11 +177,6 @@ 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 =A0* Iterate through all elements to find our "hole" and on our w=
ay
> =A0 =A0 =A0* update all the other scores.
> @@ -200,25 +187,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 }
>
> @@ -228,29 +208,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}
>
> @@ -259,7 +224,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}
>
> @@ -272,8 +237,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));
> @@ -286,13 +249,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}
>
> @@ -310,30 +272,28 @@ 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}
>
> @@ -361,12 +321,12 @@ static void *sedf_alloc_vdata(const stru
>
> =A0 =A0 inf->vcpu =3D v;
>
> - =A0 =A0/* Every VCPU gets an equal share of extratime by default. */
> + =A0 =A0/* Every VCPU gets an equal share of extratime by default */
> =A0 =A0 inf->deadl_abs =A0 =3D 0;
> =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 =A0/* Upon creation all domain are best-effort. */
> + =A0 =A0/* Upon creation all domain are best-effort */
> =A0 =A0 inf->period =A0 =A0 =A0=3D WEIGHT_PERIOD;
> =A0 =A0 inf->slice =A0 =A0 =A0 =3D 0;
>
> @@ -450,21 +410,19 @@ static void desched_edf_dom(s_time_t now
> =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 * runq.
> - =A0 =A0 */
> + =A0 =A0/* Scheduling decisions which don't remove the running domain fr=
om
> + =A0 =A0 * the runq */
> =A0 =A0 if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
> =A0 =A0 =A0 =A0 return;
>
> =A0 =A0 __del_from_queue(d);
> -
> +
> =A0 =A0 /*
> =A0 =A0 =A0* Manage bookkeeping (i.e. calculate next deadline, memorise
> =A0 =A0 =A0* overrun-time of slice) of finished domains.
> @@ -475,30 +433,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) )
> @@ -518,8 +476,6 @@ 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 =A0* Check for the first elements of the waitqueue, whether their
> =A0 =A0 =A0* next period has already started.
> @@ -527,41 +483,32 @@ static void update_queues(
> =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) ||
> @@ -571,18 +518,18 @@ static void update_queues(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* We missed the deadline or the slice was alre=
ady 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 =A0* If we are still behind: modulo arithmetic, f=
orce deadline
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* to be in future and aligned to period border=
s.
> @@ -593,7 +540,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);
> @@ -603,17 +550,17 @@ 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}
>
>
> -/* 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 */
> +/*
> + * removes a domain from the head of the according extraQ and
> + * 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);
> @@ -622,29 +569,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
> @@ -653,51 +596,59 @@ 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/*
> + =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/*
> + =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/*
> + =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) )
> @@ -729,8 +680,10 @@ 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/*
> + =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;
> @@ -744,7 +697,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]);
> @@ -794,11 +747,13 @@ static void sedf_deinit(const struct sch
> =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*/
> +/*
> + * 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
> + */
> =A0static struct task_slice sedf_do_schedule(
> =A0 =A0 const struct scheduler *ops, s_time_t now, bool_t tasklet_work_sc=
heduled)
> =A0{
> @@ -811,13 +766,15 @@ 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/*
> + =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;
>
> @@ -826,7 +783,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
> @@ -836,10 +793,12 @@ 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/*
> + =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)))) )
> @@ -855,9 +814,11 @@ 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/*
> + =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 }
> @@ -869,14 +830,18 @@ 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/*
> + =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 */
> =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/*
> + =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",
> @@ -896,9 +861,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;
>
> @@ -920,7 +882,8 @@ static void sedf_sleep(const struct sche
> =A0}
>
>
> -/* 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
> =A0* things to mention are: admission control is taking place nowhere at
> =A0* the moment, so we can't be sure, whether it is safe to wake the doma=
in
> =A0* up at all. Anyway, even if it is safe (total cpu usage <=3D100%) the=
re are
> @@ -994,27 +957,31 @@ 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/*
> + =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/*
> + =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 {
> @@ -1024,28 +991,31 @@ 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/*
> + =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}
> @@ -1068,15 +1038,17 @@ 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)
> @@ -1085,26 +1057,25 @@ 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]));
> =A0 =A0 case DOMAIN_EXTRA_UTIL:
> =A0 =A0 =A0 =A0 /* Check whether we want the L0 extraq. Don't
> - =A0 =A0 =A0 =A0 * switch if both domains want L1 extraq.
> - =A0 =A0 =A0 =A0 */
> + =A0 =A0 =A0 =A0 * switch if both domains want L1 extraq. */
> =A0 =A0 =A0 =A0 return !!(other_inf->status & EXTRA_WANT_PEN_Q);
> =A0 =A0 case DOMAIN_IDLE:
> =A0 =A0 =A0 =A0 return 1;
> @@ -1118,18 +1089,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;
> @@ -1138,28 +1102,25 @@ 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/*
> + =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);
> @@ -1168,8 +1129,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
> @@ -1179,8 +1139,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
> @@ -1190,24 +1149,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;
> @@ -1216,12 +1164,14 @@ 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/*
> + =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);
> @@ -1266,7 +1216,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;
> @@ -1341,16 +1291,18 @@ 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, int nr_cpus, int *su=
mw, s_time_t *sumt)
> =A0{
> =A0 =A0 struct vcpu *p;
> =A0 =A0 struct domain =A0 =A0 =A0*d;
> =A0 =A0 unsigned int =A0 =A0 =A0 =A0cpu;
>
> - =A0 =A0/* Sum across all weights. Notice that no runq locking is needed
> + =A0 =A0/*
> + =A0 =A0 * Sum across all weights. Notice that no runq locking is needed
> =A0 =A0 =A0* here: the caller holds sedf_priv_info.lock and we're not cha=
nging
> - =A0 =A0 * anything that is accessed during scheduling. */
> + =A0 =A0 * anything that is accessed during scheduling.
> + =A0 =A0 */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1365,11 +1317,14 @@ 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/*
> + =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
> @@ -1380,9 +1335,11 @@ 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. Unlike abo=
ve, we
> + =A0 =A0/*
> + =A0 =A0 * Adjust all slices (and periods) to the new weight. Unlike abo=
ve, we
> =A0 =A0 =A0* need to take thr runq lock for the various VCPUs: we're mody=
fing
> - =A0 =A0 * slice and period which are referenced during scheduling. */
> + =A0 =A0 * slice and period which are referenced during scheduling.
> + =A0 =A0 */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1410,7 +1367,7 @@ 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 sedf_priv_info *prv =3D SEDF_PRIV(ops);
> @@ -1421,23 +1378,22 @@ static int sedf_adjust(const struct sche
> =A0 =A0 struct vcpu *v;
> =A0 =A0 int rc =3D 0;
>
> - =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/* Serialize against the pluggable scheduler lock to protect from
> + =A0 =A0/*
> + =A0 =A0 * Serialize against the pluggable scheduler lock to protect from
> =A0 =A0 =A0* concurrent updates. We need to take the runq lock for the VC=
PUs
> =A0 =A0 =A0* as well, since we are touching extraweight, weight, slice and
> =A0 =A0 =A0* period. As in sched_credit2.c, runq locks nest inside the
> - =A0 =A0 * pluggable scheduler lock. */
> + =A0 =A0 * pluggable scheduler lock.
> + =A0 =A0 */
> =A0 =A0 spin_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/*
> + =A0 =A0 =A0 =A0 * These are used in sedf_adjust_weights() but have to b=
e allocated in
> =A0 =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 =A0 * within our prv->lock.
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 if ( !sumw || !sumt )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 /* Check for errors here, the _getinfo branch doe=
sn't care */
> @@ -1445,7 +1401,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =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 =A0 =A0 =A0 =A0 rc =3D -EINVAL;
> @@ -1457,7 +1413,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 /* (Here and everywhere in the fo=
llowing) IRQs are already off,
> @@ -1472,7 +1428,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 vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D op->u.se=
df.weight;
> @@ -1495,7 +1451,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Time-driven domains. */
> + =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 vcpu_schedule_lock(v);
> @@ -1545,7 +1501,6 @@ out:
> =A0 =A0 xfree(sumt);
> =A0 =A0 xfree(sumw);
>
> - =A0 =A0PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
> =A0 =A0 return rc;
> =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 Mon Jan 09 10:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 10:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkCko-0003bW-N2; Mon, 09 Jan 2012 10:47:02 +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 1RkCkm-0003b8-E3
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 10:47:00 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326106010!2361721!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 20629 invoked from network); 9 Jan 2012 10:46:51 -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;
	9 Jan 2012 10:46:51 -0000
Received: by iagw33 with SMTP id w33so34617281iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 02:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=SjPPA4H1PdnpJjykeke3GkkJEdxgw/9sDZFIGjzsZtM=;
	b=iw3PsASbXx7i5y/ULFgLhcZAihhOjOxah0AdG5WOxEmJUJRuy6PH5E2o0KA6BXFu13
	8ODlPhwkOitIfPNlnCfW29Lnryhv7tVRS+pVDpRDv3u2YE6JaiN1rBFlcwS3S+TfXG8p
	xFiU3LhmAHYTosxpLeBdNmnu8HW4tWEDnwnKE=
MIME-Version: 1.0
Received: by 10.43.53.1 with SMTP id vo1mr19286957icb.2.1326106005109; Mon, 09
	Jan 2012 02:46:45 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Mon, 9 Jan 2012 02:46:44 -0800 (PST)
In-Reply-To: <1325776621.2728.7.camel@Solace>
References: <1325776621.2728.7.camel@Solace>
Date: Mon, 9 Jan 2012 10:46:44 +0000
X-Google-Sender-Auth: oYj7f5ntX2ynr7HIiLaMZ73VEcg
Message-ID: <CAFLBxZZz19COBDvdmWmKFsr4MOSxQtxAZRYz6vBYudXFJANxtA@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] [PATCHv3] 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 Thu, Jan 5, 2012 at 3:17 PM, 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.
>
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Looks good -- thanks, Dario.

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

>
> diff -r efaa28639a71 xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c =A0 Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/common/sched_sedf.c =A0 Thu Jan 05 15:02:30 2012 +0100
> @@ -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)
>
> @@ -71,34 +63,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 /* =3D worst 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
> @@ -165,18 +158,17 @@ 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{
> @@ -185,11 +177,6 @@ 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 =A0* Iterate through all elements to find our "hole" and on our w=
ay
> =A0 =A0 =A0* update all the other scores.
> @@ -200,25 +187,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 }
>
> @@ -228,29 +208,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}
>
> @@ -259,7 +224,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}
>
> @@ -272,8 +237,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));
> @@ -286,13 +249,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}
>
> @@ -310,30 +272,28 @@ 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}
>
> @@ -361,12 +321,12 @@ static void *sedf_alloc_vdata(const stru
>
> =A0 =A0 inf->vcpu =3D v;
>
> - =A0 =A0/* Every VCPU gets an equal share of extratime by default. */
> + =A0 =A0/* Every VCPU gets an equal share of extratime by default */
> =A0 =A0 inf->deadl_abs =A0 =3D 0;
> =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 =A0/* Upon creation all domain are best-effort. */
> + =A0 =A0/* Upon creation all domain are best-effort */
> =A0 =A0 inf->period =A0 =A0 =A0=3D WEIGHT_PERIOD;
> =A0 =A0 inf->slice =A0 =A0 =A0 =3D 0;
>
> @@ -450,21 +410,19 @@ static void desched_edf_dom(s_time_t now
> =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 * runq.
> - =A0 =A0 */
> + =A0 =A0/* Scheduling decisions which don't remove the running domain fr=
om
> + =A0 =A0 * the runq */
> =A0 =A0 if ( (inf->cputime < inf->slice) && sedf_runnable(d) )
> =A0 =A0 =A0 =A0 return;
>
> =A0 =A0 __del_from_queue(d);
> -
> +
> =A0 =A0 /*
> =A0 =A0 =A0* Manage bookkeeping (i.e. calculate next deadline, memorise
> =A0 =A0 =A0* overrun-time of slice) of finished domains.
> @@ -475,30 +433,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) )
> @@ -518,8 +476,6 @@ 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 =A0* Check for the first elements of the waitqueue, whether their
> =A0 =A0 =A0* next period has already started.
> @@ -527,41 +483,32 @@ static void update_queues(
> =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) ||
> @@ -571,18 +518,18 @@ static void update_queues(
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* We missed the deadline or the slice was alre=
ady 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 =A0* If we are still behind: modulo arithmetic, f=
orce deadline
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* to be in future and aligned to period border=
s.
> @@ -593,7 +540,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);
> @@ -603,17 +550,17 @@ 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}
>
>
> -/* 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 */
> +/*
> + * removes a domain from the head of the according extraQ and
> + * 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);
> @@ -622,29 +569,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
> @@ -653,51 +596,59 @@ 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/*
> + =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/*
> + =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/*
> + =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) )
> @@ -729,8 +680,10 @@ 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/*
> + =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;
> @@ -744,7 +697,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]);
> @@ -794,11 +747,13 @@ static void sedf_deinit(const struct sch
> =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*/
> +/*
> + * 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
> + */
> =A0static struct task_slice sedf_do_schedule(
> =A0 =A0 const struct scheduler *ops, s_time_t now, bool_t tasklet_work_sc=
heduled)
> =A0{
> @@ -811,13 +766,15 @@ 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/*
> + =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;
>
> @@ -826,7 +783,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
> @@ -836,10 +793,12 @@ 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/*
> + =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)))) )
> @@ -855,9 +814,11 @@ 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/*
> + =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 }
> @@ -869,14 +830,18 @@ 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/*
> + =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 */
> =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/*
> + =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",
> @@ -896,9 +861,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;
>
> @@ -920,7 +882,8 @@ static void sedf_sleep(const struct sche
> =A0}
>
>
> -/* 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
> =A0* things to mention are: admission control is taking place nowhere at
> =A0* the moment, so we can't be sure, whether it is safe to wake the doma=
in
> =A0* up at all. Anyway, even if it is safe (total cpu usage <=3D100%) the=
re are
> @@ -994,27 +957,31 @@ 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/*
> + =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/*
> + =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 {
> @@ -1024,28 +991,31 @@ 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/*
> + =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}
> @@ -1068,15 +1038,17 @@ 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)
> @@ -1085,26 +1057,25 @@ 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]));
> =A0 =A0 case DOMAIN_EXTRA_UTIL:
> =A0 =A0 =A0 =A0 /* Check whether we want the L0 extraq. Don't
> - =A0 =A0 =A0 =A0 * switch if both domains want L1 extraq.
> - =A0 =A0 =A0 =A0 */
> + =A0 =A0 =A0 =A0 * switch if both domains want L1 extraq. */
> =A0 =A0 =A0 =A0 return !!(other_inf->status & EXTRA_WANT_PEN_Q);
> =A0 =A0 case DOMAIN_IDLE:
> =A0 =A0 =A0 =A0 return 1;
> @@ -1118,18 +1089,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;
> @@ -1138,28 +1102,25 @@ 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/*
> + =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);
> @@ -1168,8 +1129,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
> @@ -1179,8 +1139,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
> @@ -1190,24 +1149,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;
> @@ -1216,12 +1164,14 @@ 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/*
> + =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);
> @@ -1266,7 +1216,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;
> @@ -1341,16 +1291,18 @@ 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, int nr_cpus, int *su=
mw, s_time_t *sumt)
> =A0{
> =A0 =A0 struct vcpu *p;
> =A0 =A0 struct domain =A0 =A0 =A0*d;
> =A0 =A0 unsigned int =A0 =A0 =A0 =A0cpu;
>
> - =A0 =A0/* Sum across all weights. Notice that no runq locking is needed
> + =A0 =A0/*
> + =A0 =A0 * Sum across all weights. Notice that no runq locking is needed
> =A0 =A0 =A0* here: the caller holds sedf_priv_info.lock and we're not cha=
nging
> - =A0 =A0 * anything that is accessed during scheduling. */
> + =A0 =A0 * anything that is accessed during scheduling.
> + =A0 =A0 */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1365,11 +1317,14 @@ 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/*
> + =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
> @@ -1380,9 +1335,11 @@ 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. Unlike abo=
ve, we
> + =A0 =A0/*
> + =A0 =A0 * Adjust all slices (and periods) to the new weight. Unlike abo=
ve, we
> =A0 =A0 =A0* need to take thr runq lock for the various VCPUs: we're mody=
fing
> - =A0 =A0 * slice and period which are referenced during scheduling. */
> + =A0 =A0 * slice and period which are referenced during scheduling.
> + =A0 =A0 */
> =A0 =A0 rcu_read_lock(&domlist_read_lock);
> =A0 =A0 for_each_domain_in_cpupool( d, c )
> =A0 =A0 {
> @@ -1410,7 +1367,7 @@ 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 sedf_priv_info *prv =3D SEDF_PRIV(ops);
> @@ -1421,23 +1378,22 @@ static int sedf_adjust(const struct sche
> =A0 =A0 struct vcpu *v;
> =A0 =A0 int rc =3D 0;
>
> - =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/* Serialize against the pluggable scheduler lock to protect from
> + =A0 =A0/*
> + =A0 =A0 * Serialize against the pluggable scheduler lock to protect from
> =A0 =A0 =A0* concurrent updates. We need to take the runq lock for the VC=
PUs
> =A0 =A0 =A0* as well, since we are touching extraweight, weight, slice and
> =A0 =A0 =A0* period. As in sched_credit2.c, runq locks nest inside the
> - =A0 =A0 * pluggable scheduler lock. */
> + =A0 =A0 * pluggable scheduler lock.
> + =A0 =A0 */
> =A0 =A0 spin_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/*
> + =A0 =A0 =A0 =A0 * These are used in sedf_adjust_weights() but have to b=
e allocated in
> =A0 =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 =A0 * within our prv->lock.
> + =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 if ( !sumw || !sumt )
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 /* Check for errors here, the _getinfo branch doe=
sn't care */
> @@ -1445,7 +1401,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =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 =A0 =A0 =A0 =A0 rc =3D -EINVAL;
> @@ -1457,7 +1413,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 /* (Here and everywhere in the fo=
llowing) IRQs are already off,
> @@ -1472,7 +1428,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 vcpu_schedule_lock(v);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 EDOM_INFO(v)->weight =3D op->u.se=
df.weight;
> @@ -1495,7 +1451,7 @@ static int sedf_adjust(const struct sche
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0 =A0 =A0 }
>
> - =A0 =A0 =A0 =A0 =A0 =A0/* Time-driven domains. */
> + =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 vcpu_schedule_lock(v);
> @@ -1545,7 +1501,6 @@ out:
> =A0 =A0 xfree(sumt);
> =A0 =A0 xfree(sumw);
>
> - =A0 =A0PRINT(2,"sedf_adjust_finished with return code %d\n", rc);
> =A0 =A0 return rc;
> =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 Mon Jan 09 11:06:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:06:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkD3d-000404-TS; Mon, 09 Jan 2012 11:06:29 +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 1RkD3c-0003zz-KH
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:06:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326107180!2796417!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 10730 invoked from network); 9 Jan 2012 11:06:22 -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;
	9 Jan 2012 11:06:22 -0000
Received: by pbbb11 with SMTP id b11so14975640pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 03:06: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=ZTnhqC80eH0lTvc68O3W4m5E/VBXrubJ1a4iZoVwrzk=;
	b=D6E8/stEPp/KVp/R2jWPIA+1kGcoj0j4acYlMHa+82cN/kKoTF+1FeS09LU+RJKs5r
	xA9wyzdGRYy+sYZbqeaPDII8RXKwoSmcQFCUtT29UJMIN5cd2CkAtBZwhPXE7r2+hSmV
	SQhRknBkXWJbDYviabYKZ+lF2S1EqCXAmV7Mo=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr40687410pbc.77.1326107180185; Mon,
	09 Jan 2012 03:06:20 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 9 Jan 2012 03:06:20 -0800 (PST)
In-Reply-To: <4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
Date: Mon, 9 Jan 2012 12:06:20 +0100
X-Google-Sender-Auth: FAeaO46TIVXc1qvCbQ5HYw9BxVU
Message-ID: <CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzkgSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPjoKPj4+PiBPbiAwNy4wMS4x
MiBhdCAwNDoyMCwgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4gd3Jv
dGU6Cj4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJv
Z2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNTkwNjIzMCAtMzYwMAo+PiAjIE5v
ZGUgSUQgZTEyZWMxMDcxNDEwYzk0NjM2N2NiMDUwOGNmMjE4YTBjM2I1OTZjYQo+PiAjIFBhcmVu
dCDCoDQwODZlNDgxMTU0N2RkZmZiOWE1M2ZiZjJlZmI2YzJmYTQzNmI3MGEKPj4gYnVpbGQ6IGFk
ZCBhdXRvY29uZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3MgaW4gdG9vbHMvY2hlY2sKPj4KPj4g
QWRkZWQgYXV0b3Rvb2xzIG1hZ2ljIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrIHNjcmlwdHMuIFRo
ZSBwcmV2aW91cwo+PiBjaGVja3MgaGF2ZSBiZWVuIHBvcnRlZCB0byBhdXRvY29uZiwgYW5kIHNv
bWUgYWRkaXRpb25hbCBvbmVzIGhhdmUKPj4gYmVlbiBhZGRlZCAocGx1cyB0aGUgc3VnZ2VzdGlv
bnMgZnJvbSBydW5uaW5nIGF1dG9zY2FuKS4gVHdvIGZpbGVzIGFyZQo+PiBjcmVhdGVkIGFzIGEg
cmVzdWx0IGZyb20gZXhlY3V0aW5nIGNvbmZpZ3VyZSBzY3JpcHQsCj4+IGNvbmZpZy9BdXRvY29u
Zi5tayBhbmQgY29uZmlnLmguCj4+Cj4+IEF1dG9jb25mLm1rIGlzIGluY2x1ZGVkIGJ5IENvbmZp
Zy5taywgYW5kIGNvbnRhaW5zIG1vc3Qgb2YgdGhlCj4+IG9wdGlvbnMgcHJldmlvdXNseSBkZWZp
bmVkIGluIC5jb25maWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwo+PiBwYXJhbWV0ZXJz
IG9yIGRlZmluaW5nIGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBjb25maWd1
cmUKPj4gc2NyaXB0Lgo+Pgo+PiBjb25maWcuaCBpcyBzdGlsbCBub3QgdXNlZCBhbnl3aGVyZSwg
YW5kIGlzIGF1dG9tYXRpY2FsbHkgY3JlYXRlZCBieQo+PiBhdXRvaGVhZGVyLCBhbHRvdWdoIHRo
aXMgbWlnaCBjaGFuZ2Ugd2hlbiB3ZSBzdGFydCB0byBpbmNsdWRlIHRoaXMKPj4gZmlsZS4KPj4K
Pj4gSnVzdCBhIGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBJaXQncyBteSBmaXJzdCBhdXRvY29u
ZiBzY3JpcHQgSSBndWVzcwo+PiB0aGVyZSB3aWxsIGJlIG1hbnkgdGhpbmdzIHRvIHBvbGlzaCBo
ZXJlLi4uIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJv
Z2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+Cj4+IGRpZmYgLXIgNDA4
NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBDb25maWcubWsKPj4gLS0tIGEvQ29uZmlnLm1rIMKg
IMKgIMKgIFRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAo+PiArKysgYi9Db25maWcubWsg
wqAgwqAgwqAgU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCj4+IEBAIC05LDggKzksNiBA
QCByZWFscGF0aCA9ICQod2lsZGNhcmQgJChmb3JlYWNoIGZpbGUsJCgxCj4+Cj4+IMKgLWluY2x1
ZGUgJChYRU5fUk9PVCkvLmNvbmZpZwo+Pgo+PiAtIyBBIGRlYnVnIGJ1aWxkIG9mIFhlbiBhbmQg
dG9vbHM/Cj4+IC1kZWJ1ZyA/PSB5Cj4KPiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGtlcHQgaGVy
ZSAocG9zc2libHkgb3ZlcnJpZGUtYWJsZSBieSB0aGUgYXV0b2NvbmYKPiBkZXRlcm1pbmVkIHNl
dHRpbmcsIGkuZS4gaXQgbWF5IG5lZWQgbW92aW5nIHBhc3QgdGhlIGluY2x1c2lvbiBiZWxvdyku
Cj4KPj4KPj4gwqBYRU5fQ09NUElMRV9BUkNIIMKgIMKgPz0gJChzaGVsbCB1bmFtZSAtbSB8IHNl
ZCAtZSBzL2kuODYveDg2XzMyLyBcCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIC1lIHMvaTg2cGMveDg2XzMyLyAtZSBzL2FtZDY0L3g4Nl82NC8pCj4+IEBAIC00Myw2
ICs0MSw3IEBAIGVuZGlmCj4+Cj4+IMKgaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvJChYRU5f
T1MpLm1rCj4+IMKgaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvJChYRU5fVEFSR0VUX0FSQ0gp
Lm1rCj4+ICtpbmNsdWRlICQoWEVOX1JPT1QpL2NvbmZpZy9BdXRvY29uZi5tawo+Cj4gQW5kIEkg
d291bGQgcmVhbGx5IGxpa2UgdG8gYXZvaWQgaGF2aW5nIGh5cGVydmlzb3IgKGFuZCBwZXJoYXBz
Cj4gYWxzbyBzdHViZG9tKSBidWlsZHMgdG8gcmVxdWlyZSBydW5uaW5nIHRoZSBhdXRvY29uZmln
IHRoaW5nCj4gZmlyc3QgLSB0aGlzIG91Z2h0IHRvIGJlIGxpbWl0ZWQgdG8gdGhlIHRvb2xzIChh
cyB3ZXJlIHRoZSBjaGVjawo+IHNjcmlwdHMpLgoKCkRvaW5nIHNvbWV0aGluZyBsaWtlIHRoaXMg
aXMgcHJvYmFibHkgbW9yZSBzdWl0YWJsZToKCmRpZmYgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL01h
a2VmaWxlCi0tLSBhL3Rvb2xzL01ha2VmaWxlCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEw
MAorKysgYi90b29scy9NYWtlZmlsZQlTYXQgSmFuIDA3IDA2OjQ2OjU1IDIwMTIgKzAxMDAKQEAg
LTEsNCArMSw1IEBACiBYRU5fUk9PVCA9ICQoQ1VSRElSKS8uLgoraW5jbHVkZSAkKFhFTl9ST09U
KS9jb25maWcvQXV0b2NvbmYubWsKIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVsZXMubWsK
CiBpZm5lcSAoJChDT05GSUdfU1lTVEVNX0xJQkFJTykseSkKCkFsc28sIEknbSBoYXZpbmcgc29t
ZSB0cm91YmxlIHdpdGggYXV0b21ha2UsIEkganVzdCB3YW50IGl0IHRvCmdlbmVyYXRlIGNvbmZp
Zy5zdWIgYW5kIHJlbGF0ZWQgZmlsZXMsIGJ1dCBpdCBrZWVwcyB0cnlpbmcgdG8gcGFyc2UKTWFr
ZWZpbGUuYW0sIGFuZCBJIGRvbid0IGtub3cgaG93IHRvIGRpc2FibGUgdGhhdC4gU29tZW9uZSB3
aXRoCmV4cGVyaWVuY2Ugb24gYXV0b3Rvb2xzIGNhbiBzaGVkIHNvbWUgbGlnaHQgb24gdGhpcz8K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:06:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:06:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkD3d-000404-TS; Mon, 09 Jan 2012 11:06:29 +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 1RkD3c-0003zz-KH
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:06:28 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326107180!2796417!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 10730 invoked from network); 9 Jan 2012 11:06:22 -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;
	9 Jan 2012 11:06:22 -0000
Received: by pbbb11 with SMTP id b11so14975640pbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 03:06: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=ZTnhqC80eH0lTvc68O3W4m5E/VBXrubJ1a4iZoVwrzk=;
	b=D6E8/stEPp/KVp/R2jWPIA+1kGcoj0j4acYlMHa+82cN/kKoTF+1FeS09LU+RJKs5r
	xA9wyzdGRYy+sYZbqeaPDII8RXKwoSmcQFCUtT29UJMIN5cd2CkAtBZwhPXE7r2+hSmV
	SQhRknBkXWJbDYviabYKZ+lF2S1EqCXAmV7Mo=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr40687410pbc.77.1326107180185; Mon,
	09 Jan 2012 03:06:20 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 9 Jan 2012 03:06:20 -0800 (PST)
In-Reply-To: <4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
Date: Mon, 9 Jan 2012 12:06:20 +0100
X-Google-Sender-Auth: FAeaO46TIVXc1qvCbQ5HYw9BxVU
Message-ID: <CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzkgSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPjoKPj4+PiBPbiAwNy4wMS4x
MiBhdCAwNDoyMCwgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4gd3Jv
dGU6Cj4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJv
Z2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNTkwNjIzMCAtMzYwMAo+PiAjIE5v
ZGUgSUQgZTEyZWMxMDcxNDEwYzk0NjM2N2NiMDUwOGNmMjE4YTBjM2I1OTZjYQo+PiAjIFBhcmVu
dCDCoDQwODZlNDgxMTU0N2RkZmZiOWE1M2ZiZjJlZmI2YzJmYTQzNmI3MGEKPj4gYnVpbGQ6IGFk
ZCBhdXRvY29uZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3MgaW4gdG9vbHMvY2hlY2sKPj4KPj4g
QWRkZWQgYXV0b3Rvb2xzIG1hZ2ljIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrIHNjcmlwdHMuIFRo
ZSBwcmV2aW91cwo+PiBjaGVja3MgaGF2ZSBiZWVuIHBvcnRlZCB0byBhdXRvY29uZiwgYW5kIHNv
bWUgYWRkaXRpb25hbCBvbmVzIGhhdmUKPj4gYmVlbiBhZGRlZCAocGx1cyB0aGUgc3VnZ2VzdGlv
bnMgZnJvbSBydW5uaW5nIGF1dG9zY2FuKS4gVHdvIGZpbGVzIGFyZQo+PiBjcmVhdGVkIGFzIGEg
cmVzdWx0IGZyb20gZXhlY3V0aW5nIGNvbmZpZ3VyZSBzY3JpcHQsCj4+IGNvbmZpZy9BdXRvY29u
Zi5tayBhbmQgY29uZmlnLmguCj4+Cj4+IEF1dG9jb25mLm1rIGlzIGluY2x1ZGVkIGJ5IENvbmZp
Zy5taywgYW5kIGNvbnRhaW5zIG1vc3Qgb2YgdGhlCj4+IG9wdGlvbnMgcHJldmlvdXNseSBkZWZp
bmVkIGluIC5jb25maWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwo+PiBwYXJhbWV0ZXJz
IG9yIGRlZmluaW5nIGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBjb25maWd1
cmUKPj4gc2NyaXB0Lgo+Pgo+PiBjb25maWcuaCBpcyBzdGlsbCBub3QgdXNlZCBhbnl3aGVyZSwg
YW5kIGlzIGF1dG9tYXRpY2FsbHkgY3JlYXRlZCBieQo+PiBhdXRvaGVhZGVyLCBhbHRvdWdoIHRo
aXMgbWlnaCBjaGFuZ2Ugd2hlbiB3ZSBzdGFydCB0byBpbmNsdWRlIHRoaXMKPj4gZmlsZS4KPj4K
Pj4gSnVzdCBhIGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBJaXQncyBteSBmaXJzdCBhdXRvY29u
ZiBzY3JpcHQgSSBndWVzcwo+PiB0aGVyZSB3aWxsIGJlIG1hbnkgdGhpbmdzIHRvIHBvbGlzaCBo
ZXJlLi4uIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJv
Z2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+Cj4+IGRpZmYgLXIgNDA4
NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBDb25maWcubWsKPj4gLS0tIGEvQ29uZmlnLm1rIMKg
IMKgIMKgIFRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAo+PiArKysgYi9Db25maWcubWsg
wqAgwqAgwqAgU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCj4+IEBAIC05LDggKzksNiBA
QCByZWFscGF0aCA9ICQod2lsZGNhcmQgJChmb3JlYWNoIGZpbGUsJCgxCj4+Cj4+IMKgLWluY2x1
ZGUgJChYRU5fUk9PVCkvLmNvbmZpZwo+Pgo+PiAtIyBBIGRlYnVnIGJ1aWxkIG9mIFhlbiBhbmQg
dG9vbHM/Cj4+IC1kZWJ1ZyA/PSB5Cj4KPiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGtlcHQgaGVy
ZSAocG9zc2libHkgb3ZlcnJpZGUtYWJsZSBieSB0aGUgYXV0b2NvbmYKPiBkZXRlcm1pbmVkIHNl
dHRpbmcsIGkuZS4gaXQgbWF5IG5lZWQgbW92aW5nIHBhc3QgdGhlIGluY2x1c2lvbiBiZWxvdyku
Cj4KPj4KPj4gwqBYRU5fQ09NUElMRV9BUkNIIMKgIMKgPz0gJChzaGVsbCB1bmFtZSAtbSB8IHNl
ZCAtZSBzL2kuODYveDg2XzMyLyBcCj4+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIC1lIHMvaTg2cGMveDg2XzMyLyAtZSBzL2FtZDY0L3g4Nl82NC8pCj4+IEBAIC00Myw2
ICs0MSw3IEBAIGVuZGlmCj4+Cj4+IMKgaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvJChYRU5f
T1MpLm1rCj4+IMKgaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvJChYRU5fVEFSR0VUX0FSQ0gp
Lm1rCj4+ICtpbmNsdWRlICQoWEVOX1JPT1QpL2NvbmZpZy9BdXRvY29uZi5tawo+Cj4gQW5kIEkg
d291bGQgcmVhbGx5IGxpa2UgdG8gYXZvaWQgaGF2aW5nIGh5cGVydmlzb3IgKGFuZCBwZXJoYXBz
Cj4gYWxzbyBzdHViZG9tKSBidWlsZHMgdG8gcmVxdWlyZSBydW5uaW5nIHRoZSBhdXRvY29uZmln
IHRoaW5nCj4gZmlyc3QgLSB0aGlzIG91Z2h0IHRvIGJlIGxpbWl0ZWQgdG8gdGhlIHRvb2xzIChh
cyB3ZXJlIHRoZSBjaGVjawo+IHNjcmlwdHMpLgoKCkRvaW5nIHNvbWV0aGluZyBsaWtlIHRoaXMg
aXMgcHJvYmFibHkgbW9yZSBzdWl0YWJsZToKCmRpZmYgLXIgZTEyZWMxMDcxNDEwIHRvb2xzL01h
a2VmaWxlCi0tLSBhL3Rvb2xzL01ha2VmaWxlCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEw
MAorKysgYi90b29scy9NYWtlZmlsZQlTYXQgSmFuIDA3IDA2OjQ2OjU1IDIwMTIgKzAxMDAKQEAg
LTEsNCArMSw1IEBACiBYRU5fUk9PVCA9ICQoQ1VSRElSKS8uLgoraW5jbHVkZSAkKFhFTl9ST09U
KS9jb25maWcvQXV0b2NvbmYubWsKIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVsZXMubWsK
CiBpZm5lcSAoJChDT05GSUdfU1lTVEVNX0xJQkFJTykseSkKCkFsc28sIEknbSBoYXZpbmcgc29t
ZSB0cm91YmxlIHdpdGggYXV0b21ha2UsIEkganVzdCB3YW50IGl0IHRvCmdlbmVyYXRlIGNvbmZp
Zy5zdWIgYW5kIHJlbGF0ZWQgZmlsZXMsIGJ1dCBpdCBrZWVwcyB0cnlpbmcgdG8gcGFyc2UKTWFr
ZWZpbGUuYW0sIGFuZCBJIGRvbid0IGtub3cgaG93IHRvIGRpc2FibGUgdGhhdC4gU29tZW9uZSB3
aXRoCmV4cGVyaWVuY2Ugb24gYXV0b3Rvb2xzIGNhbiBzaGVkIHNvbWUgbGlnaHQgb24gdGhpcz8K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:11:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11: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 1RkD7m-00047h-ID; Mon, 09 Jan 2012 11:10:46 +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 1RkD7l-00047R-RN
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:10:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326107412!54885034!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 17669 invoked from network); 9 Jan 2012 11:10:13 -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 Jan 2012 11:10:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 11:10:39 +0000
Message-Id: <4F0AD93B020000780006B281@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 11:10:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
	<CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@mail.gmail.com>
In-Reply-To: <CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDA5LjAxLjEyIGF0IDEyOjA2LCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiAyMDEyLzEvOSBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5j
b20+Ogo+Pj4+PiBPbiAwNy4wMS4xMiBhdCAwNDoyMCwgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5w
YXVAZW50ZWwudXBjLmVkdT4gd3JvdGU6Cj4+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+Pj4gIyBV
c2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+PiAjIERhdGUg
MTMyNTkwNjIzMCAtMzYwMAo+Pj4gIyBOb2RlIElEIGUxMmVjMTA3MTQxMGM5NDYzNjdjYjA1MDhj
ZjIxOGEwYzNiNTk2Y2EKPj4+ICMgUGFyZW50ICA0MDg2ZTQ4MTE1NDdkZGZmYjlhNTNmYmYyZWZi
NmMyZmE0MzZiNzBhCj4+PiBidWlsZDogYWRkIGF1dG9jb25mIHRvIHJlcGxhY2UgY3VzdG9tIGNo
ZWNrcyBpbiB0b29scy9jaGVjawo+Pj4KPj4+IEFkZGVkIGF1dG90b29scyBtYWdpYyB0byByZXBs
YWNlIGN1c3RvbSBjaGVjayBzY3JpcHRzLiBUaGUgcHJldmlvdXMKPj4+IGNoZWNrcyBoYXZlIGJl
ZW4gcG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQo+Pj4g
YmVlbiBhZGRlZCAocGx1cyB0aGUgc3VnZ2VzdGlvbnMgZnJvbSBydW5uaW5nIGF1dG9zY2FuKS4g
VHdvIGZpbGVzIGFyZQo+Pj4gY3JlYXRlZCBhcyBhIHJlc3VsdCBmcm9tIGV4ZWN1dGluZyBjb25m
aWd1cmUgc2NyaXB0LAo+Pj4gY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KPj4+Cj4+
PiBBdXRvY29uZi5tayBpcyBpbmNsdWRlZCBieSBDb25maWcubWssIGFuZCBjb250YWlucyBtb3N0
IG9mIHRoZQo+Pj4gb3B0aW9ucyBwcmV2aW91c2x5IGRlZmluZWQgaW4gLmNvbmZpZywgdGhhdCBj
YW4gbm93IGJlIHNldCBwYXNzaW5nCj4+PiBwYXJhbWV0ZXJzIG9yIGRlZmluaW5nIGVudmlyb25t
ZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBjb25maWd1cmUKPj4+IHNjcmlwdC4KPj4+Cj4+
PiBjb25maWcuaCBpcyBzdGlsbCBub3QgdXNlZCBhbnl3aGVyZSwgYW5kIGlzIGF1dG9tYXRpY2Fs
bHkgY3JlYXRlZCBieQo+Pj4gYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1pZ2ggY2hhbmdlIHdo
ZW4gd2Ugc3RhcnQgdG8gaW5jbHVkZSB0aGlzCj4+PiBmaWxlLgo+Pj4KPj4+IEp1c3QgYSBmaXJz
dCByZWxlYXNlLCBhbmQgc2luY2UgSWl0J3MgbXkgZmlyc3QgYXV0b2NvbmYgc2NyaXB0IEkgZ3Vl
c3MKPj4+IHRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNl
IHJldmlldyBhbmQgY29tbWVudC4KPj4+Cj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pj4KPj4+IGRpZmYgLXIgNDA4NmU0ODExNTQ3
IC1yIGUxMmVjMTA3MTQxMCBDb25maWcubWsKPj4+IC0tLSBhL0NvbmZpZy5tayAgICAgICBUaHUg
SmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4+ICsrKyBiL0NvbmZpZy5tayAgICAgICBTYXQg
SmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKPj4+IEBAIC05LDggKzksNiBAQCByZWFscGF0aCA9
ICQod2lsZGNhcmQgJChmb3JlYWNoIGZpbGUsJCgxCj4+Pgo+Pj4gIC1pbmNsdWRlICQoWEVOX1JP
T1QpLy5jb25maWcKPj4+Cj4+PiAtIyBBIGRlYnVnIGJ1aWxkIG9mIFhlbiBhbmQgdG9vbHM/Cj4+
PiAtZGVidWcgPz0geQo+Pgo+PiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGtlcHQgaGVyZSAocG9z
c2libHkgb3ZlcnJpZGUtYWJsZSBieSB0aGUgYXV0b2NvbmYKPj4gZGV0ZXJtaW5lZCBzZXR0aW5n
LCBpLmUuIGl0IG1heSBuZWVkIG1vdmluZyBwYXN0IHRoZSBpbmNsdXNpb24gYmVsb3cpLgo+Pgo+
Pj4KPj4+ICBYRU5fQ09NUElMRV9BUkNIICAgID89ICQoc2hlbGwgdW5hbWUgLW0gfCBzZWQgLWUg
cy9pLjg2L3g4Nl8zMi8gXAo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAtZSBzL2k4NnBj
L3g4Nl8zMi8gLWUgcy9hbWQ2NC94ODZfNjQvKQo+Pj4gQEAgLTQzLDYgKzQxLDcgQEAgZW5kaWYK
Pj4+Cj4+PiAgaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvJChYRU5fT1MpLm1rCj4+PiAgaW5j
bHVkZSAkKFhFTl9ST09UKS9jb25maWcvJChYRU5fVEFSR0VUX0FSQ0gpLm1rCj4+PiAraW5jbHVk
ZSAkKFhFTl9ST09UKS9jb25maWcvQXV0b2NvbmYubWsKPj4KPj4gQW5kIEkgd291bGQgcmVhbGx5
IGxpa2UgdG8gYXZvaWQgaGF2aW5nIGh5cGVydmlzb3IgKGFuZCBwZXJoYXBzCj4+IGFsc28gc3R1
YmRvbSkgYnVpbGRzIHRvIHJlcXVpcmUgcnVubmluZyB0aGUgYXV0b2NvbmZpZyB0aGluZwo+PiBm
aXJzdCAtIHRoaXMgb3VnaHQgdG8gYmUgbGltaXRlZCB0byB0aGUgdG9vbHMgKGFzIHdlcmUgdGhl
IGNoZWNrCj4+IHNjcmlwdHMpLgo+IAo+IAo+IERvaW5nIHNvbWV0aGluZyBsaWtlIHRoaXMgaXMg
cHJvYmFibHkgbW9yZSBzdWl0YWJsZToKPiAKPiBkaWZmIC1yIGUxMmVjMTA3MTQxMCB0b29scy9N
YWtlZmlsZQo+IC0tLSBhL3Rvb2xzL01ha2VmaWxlCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiAr
MDEwMAo+ICsrKyBiL3Rvb2xzL01ha2VmaWxlCVNhdCBKYW4gMDcgMDY6NDY6NTUgMjAxMiArMDEw
MAo+IEBAIC0xLDQgKzEsNSBAQAo+ICBYRU5fUk9PVCA9ICQoQ1VSRElSKS8uLgo+ICtpbmNsdWRl
ICQoWEVOX1JPT1QpL2NvbmZpZy9BdXRvY29uZi5tawo+ICBpbmNsdWRlICQoWEVOX1JPT1QpL3Rv
b2xzL1J1bGVzLm1rCj4gCj4gIGlmbmVxICgkKENPTkZJR19TWVNURU1fTElCQUlPKSx5KQoKWWVz
LCBwbGVhc2UuIE9mIGNvdXJzZSwgdGhlIHF1ZXN0aW9uIHRoZW4gaXMgd2hldGhlciBpdCBzaG91
bGRuJ3QKcmVhbGx5IGJlIHRvb2xzL0F1dG9jb25mLm1rIChhbmQgd2hldGhlciBwZXJoYXBzIHRo
ZSB3aG9sZSBzZXQKb2YgbmV3IGZpbGVzIHNob3VsZCBhbHNvIGJlIHJvb3RlZCB1bmRlciB0b29s
cy8gcmF0aGVyIHRoYW4gYXQKJChYRU5fUk9PVCkvKS4KCkphbgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:11:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11: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 1RkD7m-00047h-ID; Mon, 09 Jan 2012 11:10:46 +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 1RkD7l-00047R-RN
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:10:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326107412!54885034!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 17669 invoked from network); 9 Jan 2012 11:10:13 -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 Jan 2012 11:10:13 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 11:10:39 +0000
Message-Id: <4F0AD93B020000780006B281@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 11:10:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
	<CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@mail.gmail.com>
In-Reply-To: <CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDA5LjAxLjEyIGF0IDEyOjA2LCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiAyMDEyLzEvOSBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5j
b20+Ogo+Pj4+PiBPbiAwNy4wMS4xMiBhdCAwNDoyMCwgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5w
YXVAZW50ZWwudXBjLmVkdT4gd3JvdGU6Cj4+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+Pj4gIyBV
c2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4+PiAjIERhdGUg
MTMyNTkwNjIzMCAtMzYwMAo+Pj4gIyBOb2RlIElEIGUxMmVjMTA3MTQxMGM5NDYzNjdjYjA1MDhj
ZjIxOGEwYzNiNTk2Y2EKPj4+ICMgUGFyZW50ICA0MDg2ZTQ4MTE1NDdkZGZmYjlhNTNmYmYyZWZi
NmMyZmE0MzZiNzBhCj4+PiBidWlsZDogYWRkIGF1dG9jb25mIHRvIHJlcGxhY2UgY3VzdG9tIGNo
ZWNrcyBpbiB0b29scy9jaGVjawo+Pj4KPj4+IEFkZGVkIGF1dG90b29scyBtYWdpYyB0byByZXBs
YWNlIGN1c3RvbSBjaGVjayBzY3JpcHRzLiBUaGUgcHJldmlvdXMKPj4+IGNoZWNrcyBoYXZlIGJl
ZW4gcG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQo+Pj4g
YmVlbiBhZGRlZCAocGx1cyB0aGUgc3VnZ2VzdGlvbnMgZnJvbSBydW5uaW5nIGF1dG9zY2FuKS4g
VHdvIGZpbGVzIGFyZQo+Pj4gY3JlYXRlZCBhcyBhIHJlc3VsdCBmcm9tIGV4ZWN1dGluZyBjb25m
aWd1cmUgc2NyaXB0LAo+Pj4gY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KPj4+Cj4+
PiBBdXRvY29uZi5tayBpcyBpbmNsdWRlZCBieSBDb25maWcubWssIGFuZCBjb250YWlucyBtb3N0
IG9mIHRoZQo+Pj4gb3B0aW9ucyBwcmV2aW91c2x5IGRlZmluZWQgaW4gLmNvbmZpZywgdGhhdCBj
YW4gbm93IGJlIHNldCBwYXNzaW5nCj4+PiBwYXJhbWV0ZXJzIG9yIGRlZmluaW5nIGVudmlyb25t
ZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBjb25maWd1cmUKPj4+IHNjcmlwdC4KPj4+Cj4+
PiBjb25maWcuaCBpcyBzdGlsbCBub3QgdXNlZCBhbnl3aGVyZSwgYW5kIGlzIGF1dG9tYXRpY2Fs
bHkgY3JlYXRlZCBieQo+Pj4gYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1pZ2ggY2hhbmdlIHdo
ZW4gd2Ugc3RhcnQgdG8gaW5jbHVkZSB0aGlzCj4+PiBmaWxlLgo+Pj4KPj4+IEp1c3QgYSBmaXJz
dCByZWxlYXNlLCBhbmQgc2luY2UgSWl0J3MgbXkgZmlyc3QgYXV0b2NvbmYgc2NyaXB0IEkgZ3Vl
c3MKPj4+IHRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNl
IHJldmlldyBhbmQgY29tbWVudC4KPj4+Cj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pj4KPj4+IGRpZmYgLXIgNDA4NmU0ODExNTQ3
IC1yIGUxMmVjMTA3MTQxMCBDb25maWcubWsKPj4+IC0tLSBhL0NvbmZpZy5tayAgICAgICBUaHUg
SmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4+ICsrKyBiL0NvbmZpZy5tayAgICAgICBTYXQg
SmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKPj4+IEBAIC05LDggKzksNiBAQCByZWFscGF0aCA9
ICQod2lsZGNhcmQgJChmb3JlYWNoIGZpbGUsJCgxCj4+Pgo+Pj4gIC1pbmNsdWRlICQoWEVOX1JP
T1QpLy5jb25maWcKPj4+Cj4+PiAtIyBBIGRlYnVnIGJ1aWxkIG9mIFhlbiBhbmQgdG9vbHM/Cj4+
PiAtZGVidWcgPz0geQo+Pgo+PiBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIGtlcHQgaGVyZSAocG9z
c2libHkgb3ZlcnJpZGUtYWJsZSBieSB0aGUgYXV0b2NvbmYKPj4gZGV0ZXJtaW5lZCBzZXR0aW5n
LCBpLmUuIGl0IG1heSBuZWVkIG1vdmluZyBwYXN0IHRoZSBpbmNsdXNpb24gYmVsb3cpLgo+Pgo+
Pj4KPj4+ICBYRU5fQ09NUElMRV9BUkNIICAgID89ICQoc2hlbGwgdW5hbWUgLW0gfCBzZWQgLWUg
cy9pLjg2L3g4Nl8zMi8gXAo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAtZSBzL2k4NnBj
L3g4Nl8zMi8gLWUgcy9hbWQ2NC94ODZfNjQvKQo+Pj4gQEAgLTQzLDYgKzQxLDcgQEAgZW5kaWYK
Pj4+Cj4+PiAgaW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvJChYRU5fT1MpLm1rCj4+PiAgaW5j
bHVkZSAkKFhFTl9ST09UKS9jb25maWcvJChYRU5fVEFSR0VUX0FSQ0gpLm1rCj4+PiAraW5jbHVk
ZSAkKFhFTl9ST09UKS9jb25maWcvQXV0b2NvbmYubWsKPj4KPj4gQW5kIEkgd291bGQgcmVhbGx5
IGxpa2UgdG8gYXZvaWQgaGF2aW5nIGh5cGVydmlzb3IgKGFuZCBwZXJoYXBzCj4+IGFsc28gc3R1
YmRvbSkgYnVpbGRzIHRvIHJlcXVpcmUgcnVubmluZyB0aGUgYXV0b2NvbmZpZyB0aGluZwo+PiBm
aXJzdCAtIHRoaXMgb3VnaHQgdG8gYmUgbGltaXRlZCB0byB0aGUgdG9vbHMgKGFzIHdlcmUgdGhl
IGNoZWNrCj4+IHNjcmlwdHMpLgo+IAo+IAo+IERvaW5nIHNvbWV0aGluZyBsaWtlIHRoaXMgaXMg
cHJvYmFibHkgbW9yZSBzdWl0YWJsZToKPiAKPiBkaWZmIC1yIGUxMmVjMTA3MTQxMCB0b29scy9N
YWtlZmlsZQo+IC0tLSBhL3Rvb2xzL01ha2VmaWxlCVNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiAr
MDEwMAo+ICsrKyBiL3Rvb2xzL01ha2VmaWxlCVNhdCBKYW4gMDcgMDY6NDY6NTUgMjAxMiArMDEw
MAo+IEBAIC0xLDQgKzEsNSBAQAo+ICBYRU5fUk9PVCA9ICQoQ1VSRElSKS8uLgo+ICtpbmNsdWRl
ICQoWEVOX1JPT1QpL2NvbmZpZy9BdXRvY29uZi5tawo+ICBpbmNsdWRlICQoWEVOX1JPT1QpL3Rv
b2xzL1J1bGVzLm1rCj4gCj4gIGlmbmVxICgkKENPTkZJR19TWVNURU1fTElCQUlPKSx5KQoKWWVz
LCBwbGVhc2UuIE9mIGNvdXJzZSwgdGhlIHF1ZXN0aW9uIHRoZW4gaXMgd2hldGhlciBpdCBzaG91
bGRuJ3QKcmVhbGx5IGJlIHRvb2xzL0F1dG9jb25mLm1rIChhbmQgd2hldGhlciBwZXJoYXBzIHRo
ZSB3aG9sZSBzZXQKb2YgbmV3IGZpbGVzIHNob3VsZCBhbHNvIGJlIHJvb3RlZCB1bmRlciB0b29s
cy8gcmF0aGVyIHRoYW4gYXQKJChYRU5fUk9PVCkvKS4KCkphbgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:11:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11: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 1RkD8b-0004Ag-0k; Mon, 09 Jan 2012 11:11:37 +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 1RkD8a-0004AK-3Y
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:11:36 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326107489!10110764!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32326 invoked from network); 9 Jan 2012 11:11:29 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 11:11:29 -0000
Received: by eekd4 with SMTP id d4so13322696eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 03:11:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=Dc2MAhkzPqTyIuTmEXbQ2wnJ2+MqfXlQVktPK+T9DbA=;
	b=QbGewbbHz1yDf9Z4urTP+RFvEslpBdrh1h6sS/gQYi01MJH2+1cS68Ijh0o0zoUy+B
	yvuIsiXggsVH/gFuLDPpZeYKFEgPCIaM/7fV0Bw1ZWoKmc5wd0WvVg3ZbI+9eXLAl82t
	NAvuYg+soEcH/WMOtPplvtwrk/RsFJhPbPZaQ=
Received: by 10.14.11.66 with SMTP id 42mr5932195eew.87.1326107489211; Mon, 09
	Jan 2012 03:11:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.8.25 with HTTP; Mon, 9 Jan 2012 03:11:08 -0800 (PST)
In-Reply-To: <20120109100956.GE26595@ocelot.phlegethon.org>
References: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
	<20120109100956.GE26595@ocelot.phlegethon.org>
From: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Mon, 9 Jan 2012 14:41:08 +0330
Message-ID: <CAK6aU6idWKayh6bAEkBo4vSt4HWKQneYEDLVEQfYxusC=HUrRA@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] changing attributes of a 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SSBoYXZlIHN0YXJ0ZWQgRG9tMCB3aXRoIGRvbTBfc2hhZG93PTEuIFNvIGl0IG11c3QgYmUgcnVu
bmluZyB3aXRoIGEKcmVhZC1vbmx5IHBhZ2UgdGFibGUuIEkgdGhvdWdodCBwMm0gaXMgcmVzcG9u
c2libGUgZm9yIHVwZGF0aW5nIHRoZQpkb20wJ3MgcGFnZS10YWJsZS4gSSBoYXZlIGxvb2tlZCBh
dCBfc2hfcHJvcGFnYXRlKCkgYnV0IEkgY291bGRuJ3QKZmluZCBhbnkgb3B0aW9uIHRvIGNoYW5n
ZSBwYWdlIGF0dHJpYnV0ZXMgbGlrZSBSV1guCgpCZXN0IFJlZ2FyZHMKTW9oYW1hZCBSZXphZWkK
LS0tLS0tLS0tLS0tLS0tLS0tLQpJQ1QgUmVzZWFyY2ggQ2VudGVyCkFtaXJrYWJpciBVbml2ZXJz
aXR5IG9mIFRlY2hub2xvZ3kKCgoKT24gTW9uLCBKYW4gOSwgMjAxMiBhdCAxOjM5IFBNLCBUaW0g
RGVlZ2FuIDx0aW1AeGVuLm9yZz4gd3JvdGU6Cj4gSGksCj4KPiBBdCAxMDoyMiArMDMzMCBvbiAw
OSBKYW4gKDEzMjYxMDQ1NjYpLCBNb2hhbWFkIFJlemFlaSB3cm90ZToKPj4gSGksCj4+Cj4+IEkg
YW0gdHJ5aW5nIHRvIGNoYW5nZSBhdHRyaWJ1dGVzIG9mIGEgcGFnZSBmcm9tIERvbTAuCj4KPiBE
byB5b3UgbWVhbiBhIHBhZ2Ugb2YgZG9tMCdzIG1lbW9yeT8KPgo+PiBUaGUgcmVhc29uIGlzCj4+
IHRoYXQgSSB3YW50IHRvIG1ha2UgYSBrZXJuZWwgbW9kdWxlIGNvbXBsZXRlbHkgcmVhZC1vbmx5
IHRvIG90aGVyCj4+IHBhcnRzIG9mIGtlcm5lbC4gSSB3aWxsIHVwZGF0ZSBpdCBmcm9tIGh5cGVy
dmlzb3IgaXRzZWxmLiBJIGhhdmUgdHJpZWQKPj4gdG8gZG8gdGhpcyBieSB0aGlzIGNvZGU6Cj4+
Cj4+IC8vIEkgaGF2ZSB0aGUgbWZuIG9mIHRoZSBwYWdlIGluIERvbTAncyBhZGRyZXNzIHNwYWNl
Lgo+PiB2b2lkIGhhbWVkX3NldF9lbnRyeShzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtLCBtZm5fdCBt
Zm4pIHsKPj4gwqAgwqAgdW5zaWduZWQgbG9uZyBnZm4gPSBtZm5fdG9fZ2ZuKHAybS0+ZG9tYWlu
LG1mbik7Cj4+IMKgIMKgIHAybV90eXBlX3QgcDJtdDsKPj4gwqAgwqAgcDJtX2FjY2Vzc190IHAy
bWE7Cj4+IMKgIMKgIHAybV9sb2NrKHAybSk7Cj4+IMKgIMKgIHAybS0+Z2V0X2VudHJ5KHAybSwg
Z2ZuLCAmcDJtdCwgJnAybWEsIHAybV9xdWVyeSk7Cj4+IMKgIMKgIHAybS0+c2V0X2VudHJ5KHAy
bSwgZ2ZuLCBtZm4sIDAsIHAybXQsIHAybV9hY2Nlc3Nfcnd4KTsKPj4gwqAgwqAgcDJtX3VubG9j
ayhwMm0pOwo+PiB9Cj4KPiBUaGF0IGxvb2tzIHBsYXVzaWJsZSBmb3IgYSBIVk0gZ3Vlc3QsIGJ1
dCBkb20wIGlzIGEgUFYgZ3Vlc3QgYW5kIGRvZXNuJ3QKPiBoYXZlIGEgcDJtIHRhYmxlLCBzbyB5
b3UncmUgbGlrZWx5IHRvIGNyYXNoIFhlbiBpZiB5b3UgdHJ5IHRvIHRvIHRoaXMKPiB0byBkb20w
Lgo+Cj4gRG8geW91IGhhdmUgYSBzZXJpYWwgY29uc29sZSBzZXQgdXAgb24geW91ciB0ZXN0IG1h
Y2hpbmU/IMKgSXQncyBfdmVyeV8KPiB1c2VmdWwgZm9yIGZpbmRpbmcgb3V0IHdoeSB0aGUgc3lz
dGVtIGNyYXNoZWQsIHNpbmNlIFhlbiB3aWxsIHVzdWFsbHkKPiBwcmludCBhIGJhY2t0cmFjZSB3
aGVuIGl0IGNyYXNoZXMuCj4KPj4gQnV0IHdoZW5ldmVyIGl0IHJ1bnMgRG9tMCByZXN0YXJ0cy4g
SSBhbSBub3QgZXZlbiBzdXJlIHRoaXMgaXMgdGhlCj4+IHJpZ2h0IHdheSB0byBkbyB0aGlzLiBJ
IGFtIGdyYXRlZnVsIGZvciBhbnkgaGVscCEKPgo+IFRvIGRvIHRoaXMgdG8gZG9tMCB5b3UgY291
bGQKPiDCoChhKSBnZXQgZG9tMCB0byBtYWtlIHRoZSBtZW1vcnkgcmVhZC1vbmx5IGluIGl0cyBv
d24gcGFnZXRhYmxlczsgYW5kCj4gwqAoYikgZW5mb3JjZSB0aGF0IHJlYWQtb25seSBwcm9wZXJ0
eSBpbiB0aGUgUFRFIHZhbGlkYXRpb24gY29kZSBpbiBtbS5jCj4KPiBPciB5b3UgY291bGQgcnVu
IGRvbTAgdW5kZXIgc2hhZG93IHBhZ2V0YWJsZXMgYW5kIGVuZm9yY2UgdGhlIHJlYWQtb25seQo+
IHByb3BlcnR5IGluIF9zaF9wcm9wYWdhdGUoKS4gwqBUaGF0IHdpbGwgaGF2ZSBhIHBlcmZvcm1h
Y2UgaGl0LCB0aG91Z2guCj4KPiBDaGVlcnMsCj4KPiBUaW0uCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:11:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11: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 1RkD8b-0004Ag-0k; Mon, 09 Jan 2012 11:11:37 +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 1RkD8a-0004AK-3Y
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:11:36 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326107489!10110764!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32326 invoked from network); 9 Jan 2012 11:11:29 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 11:11:29 -0000
Received: by eekd4 with SMTP id d4so13322696eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 03:11:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=Dc2MAhkzPqTyIuTmEXbQ2wnJ2+MqfXlQVktPK+T9DbA=;
	b=QbGewbbHz1yDf9Z4urTP+RFvEslpBdrh1h6sS/gQYi01MJH2+1cS68Ijh0o0zoUy+B
	yvuIsiXggsVH/gFuLDPpZeYKFEgPCIaM/7fV0Bw1ZWoKmc5wd0WvVg3ZbI+9eXLAl82t
	NAvuYg+soEcH/WMOtPplvtwrk/RsFJhPbPZaQ=
Received: by 10.14.11.66 with SMTP id 42mr5932195eew.87.1326107489211; Mon, 09
	Jan 2012 03:11:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.8.25 with HTTP; Mon, 9 Jan 2012 03:11:08 -0800 (PST)
In-Reply-To: <20120109100956.GE26595@ocelot.phlegethon.org>
References: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
	<20120109100956.GE26595@ocelot.phlegethon.org>
From: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Mon, 9 Jan 2012 14:41:08 +0330
Message-ID: <CAK6aU6idWKayh6bAEkBo4vSt4HWKQneYEDLVEQfYxusC=HUrRA@mail.gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] changing attributes of a 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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SSBoYXZlIHN0YXJ0ZWQgRG9tMCB3aXRoIGRvbTBfc2hhZG93PTEuIFNvIGl0IG11c3QgYmUgcnVu
bmluZyB3aXRoIGEKcmVhZC1vbmx5IHBhZ2UgdGFibGUuIEkgdGhvdWdodCBwMm0gaXMgcmVzcG9u
c2libGUgZm9yIHVwZGF0aW5nIHRoZQpkb20wJ3MgcGFnZS10YWJsZS4gSSBoYXZlIGxvb2tlZCBh
dCBfc2hfcHJvcGFnYXRlKCkgYnV0IEkgY291bGRuJ3QKZmluZCBhbnkgb3B0aW9uIHRvIGNoYW5n
ZSBwYWdlIGF0dHJpYnV0ZXMgbGlrZSBSV1guCgpCZXN0IFJlZ2FyZHMKTW9oYW1hZCBSZXphZWkK
LS0tLS0tLS0tLS0tLS0tLS0tLQpJQ1QgUmVzZWFyY2ggQ2VudGVyCkFtaXJrYWJpciBVbml2ZXJz
aXR5IG9mIFRlY2hub2xvZ3kKCgoKT24gTW9uLCBKYW4gOSwgMjAxMiBhdCAxOjM5IFBNLCBUaW0g
RGVlZ2FuIDx0aW1AeGVuLm9yZz4gd3JvdGU6Cj4gSGksCj4KPiBBdCAxMDoyMiArMDMzMCBvbiAw
OSBKYW4gKDEzMjYxMDQ1NjYpLCBNb2hhbWFkIFJlemFlaSB3cm90ZToKPj4gSGksCj4+Cj4+IEkg
YW0gdHJ5aW5nIHRvIGNoYW5nZSBhdHRyaWJ1dGVzIG9mIGEgcGFnZSBmcm9tIERvbTAuCj4KPiBE
byB5b3UgbWVhbiBhIHBhZ2Ugb2YgZG9tMCdzIG1lbW9yeT8KPgo+PiBUaGUgcmVhc29uIGlzCj4+
IHRoYXQgSSB3YW50IHRvIG1ha2UgYSBrZXJuZWwgbW9kdWxlIGNvbXBsZXRlbHkgcmVhZC1vbmx5
IHRvIG90aGVyCj4+IHBhcnRzIG9mIGtlcm5lbC4gSSB3aWxsIHVwZGF0ZSBpdCBmcm9tIGh5cGVy
dmlzb3IgaXRzZWxmLiBJIGhhdmUgdHJpZWQKPj4gdG8gZG8gdGhpcyBieSB0aGlzIGNvZGU6Cj4+
Cj4+IC8vIEkgaGF2ZSB0aGUgbWZuIG9mIHRoZSBwYWdlIGluIERvbTAncyBhZGRyZXNzIHNwYWNl
Lgo+PiB2b2lkIGhhbWVkX3NldF9lbnRyeShzdHJ1Y3QgcDJtX2RvbWFpbiAqcDJtLCBtZm5fdCBt
Zm4pIHsKPj4gwqAgwqAgdW5zaWduZWQgbG9uZyBnZm4gPSBtZm5fdG9fZ2ZuKHAybS0+ZG9tYWlu
LG1mbik7Cj4+IMKgIMKgIHAybV90eXBlX3QgcDJtdDsKPj4gwqAgwqAgcDJtX2FjY2Vzc190IHAy
bWE7Cj4+IMKgIMKgIHAybV9sb2NrKHAybSk7Cj4+IMKgIMKgIHAybS0+Z2V0X2VudHJ5KHAybSwg
Z2ZuLCAmcDJtdCwgJnAybWEsIHAybV9xdWVyeSk7Cj4+IMKgIMKgIHAybS0+c2V0X2VudHJ5KHAy
bSwgZ2ZuLCBtZm4sIDAsIHAybXQsIHAybV9hY2Nlc3Nfcnd4KTsKPj4gwqAgwqAgcDJtX3VubG9j
ayhwMm0pOwo+PiB9Cj4KPiBUaGF0IGxvb2tzIHBsYXVzaWJsZSBmb3IgYSBIVk0gZ3Vlc3QsIGJ1
dCBkb20wIGlzIGEgUFYgZ3Vlc3QgYW5kIGRvZXNuJ3QKPiBoYXZlIGEgcDJtIHRhYmxlLCBzbyB5
b3UncmUgbGlrZWx5IHRvIGNyYXNoIFhlbiBpZiB5b3UgdHJ5IHRvIHRvIHRoaXMKPiB0byBkb20w
Lgo+Cj4gRG8geW91IGhhdmUgYSBzZXJpYWwgY29uc29sZSBzZXQgdXAgb24geW91ciB0ZXN0IG1h
Y2hpbmU/IMKgSXQncyBfdmVyeV8KPiB1c2VmdWwgZm9yIGZpbmRpbmcgb3V0IHdoeSB0aGUgc3lz
dGVtIGNyYXNoZWQsIHNpbmNlIFhlbiB3aWxsIHVzdWFsbHkKPiBwcmludCBhIGJhY2t0cmFjZSB3
aGVuIGl0IGNyYXNoZXMuCj4KPj4gQnV0IHdoZW5ldmVyIGl0IHJ1bnMgRG9tMCByZXN0YXJ0cy4g
SSBhbSBub3QgZXZlbiBzdXJlIHRoaXMgaXMgdGhlCj4+IHJpZ2h0IHdheSB0byBkbyB0aGlzLiBJ
IGFtIGdyYXRlZnVsIGZvciBhbnkgaGVscCEKPgo+IFRvIGRvIHRoaXMgdG8gZG9tMCB5b3UgY291
bGQKPiDCoChhKSBnZXQgZG9tMCB0byBtYWtlIHRoZSBtZW1vcnkgcmVhZC1vbmx5IGluIGl0cyBv
d24gcGFnZXRhYmxlczsgYW5kCj4gwqAoYikgZW5mb3JjZSB0aGF0IHJlYWQtb25seSBwcm9wZXJ0
eSBpbiB0aGUgUFRFIHZhbGlkYXRpb24gY29kZSBpbiBtbS5jCj4KPiBPciB5b3UgY291bGQgcnVu
IGRvbTAgdW5kZXIgc2hhZG93IHBhZ2V0YWJsZXMgYW5kIGVuZm9yY2UgdGhlIHJlYWQtb25seQo+
IHByb3BlcnR5IGluIF9zaF9wcm9wYWdhdGUoKS4gwqBUaGF0IHdpbGwgaGF2ZSBhIHBlcmZvcm1h
Y2UgaGl0LCB0aG91Z2guCj4KPiBDaGVlcnMsCj4KPiBUaW0uCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:21:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDI7-0004So-3x; Mon, 09 Jan 2012 11:21:27 +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 1RkDI5-0004Sj-Lh
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:21:25 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326108079!8352984!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20917 invoked from network); 9 Jan 2012 11:21:19 -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;
	9 Jan 2012 11:21:19 -0000
Received: by eekd4 with SMTP id d4so13345082eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 03:21:19 -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=9ZWdOmtLCFPIp0096+Wy9xiPd+/FsP5zMNrO8QI8hOI=;
	b=pV2RCYDnEDdRNbEAC4tDHX0BWMH+jJnTzfn+VQSK25ktIbObmdkL4Aqxx1857x/UWY
	dBqvlu88+zsj5vA6RzrimhbxovDtpQblND0AK1bFP3n4tv3ESx2T3cvm9VjmrCi7mfjT
	b5Fwi5XZeNh1zAi8ypPbHVM4tYX3ObyYQl+OY=
Received: by 10.14.11.66 with SMTP id 42mr5935156eew.87.1326107630147; Mon, 09
	Jan 2012 03:13:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.8.25 with HTTP; Mon, 9 Jan 2012 03:13:29 -0800 (PST)
From: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Mon, 9 Jan 2012 14:43:29 +0330
Message-ID: <CAK6aU6huANSew5B1mQsKSeqTuEqnSfkuCFbxVCW-q4Qjcw5heg@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] enable NX (execution disabled) bit for Com0?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Is there a way to re-enable NX bit from Xen for a kernel that has disabled it?

Best Regards
Mohamad Rezaei
-------------------
ICT Research Center
Amirkabir University of Technology

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:21:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:21:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDI7-0004So-3x; Mon, 09 Jan 2012 11:21:27 +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 1RkDI5-0004Sj-Lh
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:21:25 +0000
X-Env-Sender: mmrezaie@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326108079!8352984!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20917 invoked from network); 9 Jan 2012 11:21:19 -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;
	9 Jan 2012 11:21:19 -0000
Received: by eekd4 with SMTP id d4so13345082eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 03:21:19 -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=9ZWdOmtLCFPIp0096+Wy9xiPd+/FsP5zMNrO8QI8hOI=;
	b=pV2RCYDnEDdRNbEAC4tDHX0BWMH+jJnTzfn+VQSK25ktIbObmdkL4Aqxx1857x/UWY
	dBqvlu88+zsj5vA6RzrimhbxovDtpQblND0AK1bFP3n4tv3ESx2T3cvm9VjmrCi7mfjT
	b5Fwi5XZeNh1zAi8ypPbHVM4tYX3ObyYQl+OY=
Received: by 10.14.11.66 with SMTP id 42mr5935156eew.87.1326107630147; Mon, 09
	Jan 2012 03:13:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.213.8.25 with HTTP; Mon, 9 Jan 2012 03:13:29 -0800 (PST)
From: Mohamad Rezaei <mmrezaie@gmail.com>
Date: Mon, 9 Jan 2012 14:43:29 +0330
Message-ID: <CAK6aU6huANSew5B1mQsKSeqTuEqnSfkuCFbxVCW-q4Qjcw5heg@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] enable NX (execution disabled) bit for Com0?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Is there a way to re-enable NX bit from Xen for a kernel that has disabled it?

Best Regards
Mohamad Rezaei
-------------------
ICT Research Center
Amirkabir University of Technology

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:40:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11: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 1RkDZu-0004n1-RR; Mon, 09 Jan 2012 11:39:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkDZs-0004mt-Jc
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:39:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326109182!2114458!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3983 invoked from network); 9 Jan 2012 11:39:42 -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;
	9 Jan 2012 11:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9894130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 11:39: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, 9 Jan 2012 11:39:42 +0000
Date: Mon, 9 Jan 2012 11:39:44 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	konrad wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 9 Jan 2012, Andrew Jones wrote:
> ----- Original Message -----
> > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > XEN_DOM0 is a silent option that has been automatically selected
> > > when
> > > CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was
> > > changed
> > > to a menu configurable option then it would only give users the
> > > ability
> > > to compile out about 100 kbytes of code.
> > 
> > I think that it is less than that because backends are not tied to
> > dom0
> > in any way, even though currently they cannot be compiled without
> > XEN_DOM0.
> > Running a network or block backend in domU is a well known
> > configuration.
> > Therefore the code compiled out only amounts to about 10K.
> > 
> > 
> > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > > index 8795480..0725228 100644
> > > --- a/drivers/xen/Kconfig
> > > +++ b/drivers/xen/Kconfig
> > > @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
> > >  
> > >  config XEN_BACKEND
> > >  	bool "Backend driver support"
> > > -	depends on XEN_DOM0
> > >  	default y
> > > +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > > +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > >  	help
> > >  	  Support for backend device drivers that provide I/O services
> > >  	  to other virtual machines.
> > 
> > I think we can trimmer the dependency list here: after all backends
> > can
> > be run in unpriviledged guests as well (see driver domains).
> > So I think it should depend only on XEN.
> 
> Hmm.. Actually, with dependency lists in mind, I think a really messed
> this patch up. I should have either had CONFIG_XEN inherit these deps,
> or I should have spread them around to be required at only the specific
> places they're needed, and then left the stub functions in. Neither of
> those options seems like a good idea to me. We either force all XEN
> guests to always have all the deps needed for an initial domain, which
> is exactly the opposite of the suggestion above (trimming XEN_BACKEND
> deps for driver domains), or we actually make the code messier and
> more complicated with more #ifdefs, which are now neatly packaged with
> XEN_DOM0.

I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
X86_IO_APIC && ACPI && PCI" to XEN either.
However it should be possible to add only the right dependencies to the
right places.
In practice it should be sufficient to:

- make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;

- make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;

- remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.



> The driver domain concept may actually be the technical need for
> making XEN_DOM0 optional. If we want the ability to build a minimally
> configed XEN kernel to be used as a driver domain, then it doesn't
> seem like we'd want it to also be capable of running as an initial
> domain, or to be forced to have all the dependencies and code of an
> initial domain.

In practice any decent driver domain needs PCI and ACPI support, so
basically it has the same config requirement of XEN_DOM0. At that point
we have already discussed that having XEN_DOM0 enabled or disabled
hardly makes any differences, so we can just get rid of it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:40:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11: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 1RkDZu-0004n1-RR; Mon, 09 Jan 2012 11:39:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkDZs-0004mt-Jc
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:39:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326109182!2114458!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3983 invoked from network); 9 Jan 2012 11:39:42 -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;
	9 Jan 2012 11:39:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9894130"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 11:39: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, 9 Jan 2012 11:39:42 +0000
Date: Mon, 9 Jan 2012 11:39:44 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	konrad wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 9 Jan 2012, Andrew Jones wrote:
> ----- Original Message -----
> > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > XEN_DOM0 is a silent option that has been automatically selected
> > > when
> > > CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was
> > > changed
> > > to a menu configurable option then it would only give users the
> > > ability
> > > to compile out about 100 kbytes of code.
> > 
> > I think that it is less than that because backends are not tied to
> > dom0
> > in any way, even though currently they cannot be compiled without
> > XEN_DOM0.
> > Running a network or block backend in domU is a well known
> > configuration.
> > Therefore the code compiled out only amounts to about 10K.
> > 
> > 
> > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > > index 8795480..0725228 100644
> > > --- a/drivers/xen/Kconfig
> > > +++ b/drivers/xen/Kconfig
> > > @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
> > >  
> > >  config XEN_BACKEND
> > >  	bool "Backend driver support"
> > > -	depends on XEN_DOM0
> > >  	default y
> > > +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > > +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > >  	help
> > >  	  Support for backend device drivers that provide I/O services
> > >  	  to other virtual machines.
> > 
> > I think we can trimmer the dependency list here: after all backends
> > can
> > be run in unpriviledged guests as well (see driver domains).
> > So I think it should depend only on XEN.
> 
> Hmm.. Actually, with dependency lists in mind, I think a really messed
> this patch up. I should have either had CONFIG_XEN inherit these deps,
> or I should have spread them around to be required at only the specific
> places they're needed, and then left the stub functions in. Neither of
> those options seems like a good idea to me. We either force all XEN
> guests to always have all the deps needed for an initial domain, which
> is exactly the opposite of the suggestion above (trimming XEN_BACKEND
> deps for driver domains), or we actually make the code messier and
> more complicated with more #ifdefs, which are now neatly packaged with
> XEN_DOM0.

I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
X86_IO_APIC && ACPI && PCI" to XEN either.
However it should be possible to add only the right dependencies to the
right places.
In practice it should be sufficient to:

- make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;

- make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;

- remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.



> The driver domain concept may actually be the technical need for
> making XEN_DOM0 optional. If we want the ability to build a minimally
> configed XEN kernel to be used as a driver domain, then it doesn't
> seem like we'd want it to also be capable of running as an initial
> domain, or to be forced to have all the dependencies and code of an
> initial domain.

In practice any decent driver domain needs PCI and ACPI support, so
basically it has the same config requirement of XEN_DOM0. At that point
we have already discussed that having XEN_DOM0 enabled or disabled
hardly makes any differences, so we can just get rid of it.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:41:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDbA-0004q8-Ah; Mon, 09 Jan 2012 11:41:08 +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 1RkDb8-0004ps-OW
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:41:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326109257!2716255!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 23820 invoked from network); 9 Jan 2012 11:40:59 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 11:40:59 -0000
Received: by daec6 with SMTP id c6so14971830dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 03:40: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=D3dPO+0T5xtnqtoqh7PzmQhWtQfpyrxeGZCSgo27eoI=;
	b=FiOJt4DqErsueg170kEXl9mTYHpDawktNpwG0nnF8NEULOhRXd/TXhX462LC/ghdaY
	8q6mvUrriO9ajP9ask/VgE22mqq8H2JVpXfxmXwOcePL28flhYQzrCNe+XPDCMrP1xW8
	SDmlEMYMeSvrylocHjxuFf34iqX3wmD10AUPM=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr40902102pbc.77.1326109257159; Mon,
	09 Jan 2012 03:40:57 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 9 Jan 2012 03:40:57 -0800 (PST)
In-Reply-To: <4F0AD93B020000780006B281@nat28.tlf.novell.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
	<CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@mail.gmail.com>
	<4F0AD93B020000780006B281@nat28.tlf.novell.com>
Date: Mon, 9 Jan 2012 12:40:57 +0100
X-Google-Sender-Auth: nz_vwc93oJR7zm4-lzCdZ3ETT0U
Message-ID: <CAPLaKK4xWb_isLv01GddWs1mdv7G4PP49b6Pz3jNrFAQo8EDDQ@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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzkgSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPjoKPj4+PiBPbiAwOS4wMS4x
MiBhdCAxMjowNiwgUm9nZXIgUGF1IE1vbm7DqTxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4gd3Jv
dGU6Cj4+IDIwMTIvMS85IEphbiBCZXVsaWNoIDxKQmV1bGljaEBzdXNlLmNvbT46Cj4+Pj4+PiBP
biAwNy4wMS4xMiBhdCAwNDoyMCwgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBj
LmVkdT4gd3JvdGU6Cj4+Pj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4+PiAjIFVzZXIgUm9nZXIg
UGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4+PiAjIERhdGUgMTMyNTkwNjIz
MCAtMzYwMAo+Pj4+ICMgTm9kZSBJRCBlMTJlYzEwNzE0MTBjOTQ2MzY3Y2IwNTA4Y2YyMThhMGMz
YjU5NmNhCj4+Pj4gIyBQYXJlbnQgwqA0MDg2ZTQ4MTE1NDdkZGZmYjlhNTNmYmYyZWZiNmMyZmE0
MzZiNzBhCj4+Pj4gYnVpbGQ6IGFkZCBhdXRvY29uZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3Mg
aW4gdG9vbHMvY2hlY2sKPj4+Pgo+Pj4+IEFkZGVkIGF1dG90b29scyBtYWdpYyB0byByZXBsYWNl
IGN1c3RvbSBjaGVjayBzY3JpcHRzLiBUaGUgcHJldmlvdXMKPj4+PiBjaGVja3MgaGF2ZSBiZWVu
IHBvcnRlZCB0byBhdXRvY29uZiwgYW5kIHNvbWUgYWRkaXRpb25hbCBvbmVzIGhhdmUKPj4+PiBi
ZWVuIGFkZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBU
d28gZmlsZXMgYXJlCj4+Pj4gY3JlYXRlZCBhcyBhIHJlc3VsdCBmcm9tIGV4ZWN1dGluZyBjb25m
aWd1cmUgc2NyaXB0LAo+Pj4+IGNvbmZpZy9BdXRvY29uZi5tayBhbmQgY29uZmlnLmguCj4+Pj4K
Pj4+PiBBdXRvY29uZi5tayBpcyBpbmNsdWRlZCBieSBDb25maWcubWssIGFuZCBjb250YWlucyBt
b3N0IG9mIHRoZQo+Pj4+IG9wdGlvbnMgcHJldmlvdXNseSBkZWZpbmVkIGluIC5jb25maWcsIHRo
YXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwo+Pj4+IHBhcmFtZXRlcnMgb3IgZGVmaW5pbmcgZW52
aXJvbm1lbnQgdmFyaWFibGVzIHdoZW4gZXhlY3V0aW5nIGNvbmZpZ3VyZQo+Pj4+IHNjcmlwdC4K
Pj4+Pgo+Pj4+IGNvbmZpZy5oIGlzIHN0aWxsIG5vdCB1c2VkIGFueXdoZXJlLCBhbmQgaXMgYXV0
b21hdGljYWxseSBjcmVhdGVkIGJ5Cj4+Pj4gYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1pZ2gg
Y2hhbmdlIHdoZW4gd2Ugc3RhcnQgdG8gaW5jbHVkZSB0aGlzCj4+Pj4gZmlsZS4KPj4+Pgo+Pj4+
IEp1c3QgYSBmaXJzdCByZWxlYXNlLCBhbmQgc2luY2UgSWl0J3MgbXkgZmlyc3QgYXV0b2NvbmYg
c2NyaXB0IEkgZ3Vlc3MKPj4+PiB0aGVyZSB3aWxsIGJlIG1hbnkgdGhpbmdzIHRvIHBvbGlzaCBo
ZXJlLi4uIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuCj4+Pj4KPj4+PiBTaWduZWQtb2ZmLWJ5
OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pj4+Cj4+Pj4gZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIENvbmZpZy5tawo+Pj4+IC0tLSBhL0Nv
bmZpZy5tayDCoCDCoCDCoCBUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4+PiArKysg
Yi9Db25maWcubWsgwqAgwqAgwqAgU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCj4+Pj4g
QEAgLTksOCArOSw2IEBAIHJlYWxwYXRoID0gJCh3aWxkY2FyZCAkKGZvcmVhY2ggZmlsZSwkKDEK
Pj4+Pgo+Pj4+IMKgLWluY2x1ZGUgJChYRU5fUk9PVCkvLmNvbmZpZwo+Pj4+Cj4+Pj4gLSMgQSBk
ZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xzPwo+Pj4+IC1kZWJ1ZyA/PSB5Cj4+Pgo+Pj4gSSB0
aGluayB0aGlzIHNob3VsZCBiZSBrZXB0IGhlcmUgKHBvc3NpYmx5IG92ZXJyaWRlLWFibGUgYnkg
dGhlIGF1dG9jb25mCj4+PiBkZXRlcm1pbmVkIHNldHRpbmcsIGkuZS4gaXQgbWF5IG5lZWQgbW92
aW5nIHBhc3QgdGhlIGluY2x1c2lvbiBiZWxvdykuCj4+Pgo+Pj4+Cj4+Pj4gwqBYRU5fQ09NUElM
RV9BUkNIIMKgIMKgPz0gJChzaGVsbCB1bmFtZSAtbSB8IHNlZCAtZSBzL2kuODYveDg2XzMyLyBc
Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLWUgcy9pODZwYy94
ODZfMzIvIC1lIHMvYW1kNjQveDg2XzY0LykKPj4+PiBAQCAtNDMsNiArNDEsNyBAQCBlbmRpZgo+
Pj4+Cj4+Pj4gwqBpbmNsdWRlICQoWEVOX1JPT1QpL2NvbmZpZy8kKFhFTl9PUykubWsKPj4+PiDC
oGluY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnLyQoWEVOX1RBUkdFVF9BUkNIKS5tawo+Pj4+ICtp
bmNsdWRlICQoWEVOX1JPT1QpL2NvbmZpZy9BdXRvY29uZi5tawo+Pj4KPj4+IEFuZCBJIHdvdWxk
IHJlYWxseSBsaWtlIHRvIGF2b2lkIGhhdmluZyBoeXBlcnZpc29yIChhbmQgcGVyaGFwcwo+Pj4g
YWxzbyBzdHViZG9tKSBidWlsZHMgdG8gcmVxdWlyZSBydW5uaW5nIHRoZSBhdXRvY29uZmlnIHRo
aW5nCj4+PiBmaXJzdCAtIHRoaXMgb3VnaHQgdG8gYmUgbGltaXRlZCB0byB0aGUgdG9vbHMgKGFz
IHdlcmUgdGhlIGNoZWNrCj4+PiBzY3JpcHRzKS4KPj4KPj4KPj4gRG9pbmcgc29tZXRoaW5nIGxp
a2UgdGhpcyBpcyBwcm9iYWJseSBtb3JlIHN1aXRhYmxlOgo+Pgo+PiBkaWZmIC1yIGUxMmVjMTA3
MTQxMCB0b29scy9NYWtlZmlsZQo+PiAtLS0gYS90b29scy9NYWtlZmlsZSDCoFNhdCBKYW4gMDcg
MDQ6MTc6MTAgMjAxMiArMDEwMAo+PiArKysgYi90b29scy9NYWtlZmlsZSDCoFNhdCBKYW4gMDcg
MDY6NDY6NTUgMjAxMiArMDEwMAo+PiBAQCAtMSw0ICsxLDUgQEAKPj4gwqBYRU5fUk9PVCA9ICQo
Q1VSRElSKS8uLgo+PiAraW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvQXV0b2NvbmYubWsKPj4g
wqBpbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCj4+Cj4+IMKgaWZuZXEgKCQoQ09O
RklHX1NZU1RFTV9MSUJBSU8pLHkpCj4KPiBZZXMsIHBsZWFzZS4gT2YgY291cnNlLCB0aGUgcXVl
c3Rpb24gdGhlbiBpcyB3aGV0aGVyIGl0IHNob3VsZG4ndAo+IHJlYWxseSBiZSB0b29scy9BdXRv
Y29uZi5tayAoYW5kIHdoZXRoZXIgcGVyaGFwcyB0aGUgd2hvbGUgc2V0Cj4gb2YgbmV3IGZpbGVz
IHNob3VsZCBhbHNvIGJlIHJvb3RlZCB1bmRlciB0b29scy8gcmF0aGVyIHRoYW4gYXQKPiAkKFhF
Tl9ST09UKS8pLgoKSSB0aGluayBpdCdzIG1vcmUgY29tbW9uIHRvIGZpbmQgYSBjb25maWd1cmUg
c2NyaXB0IGluIHRoZSByb290IGZvbGRlcgpvZiB0aGUgcGFja2FnZSByYXRoZXIgdGhhbiBoYXZp
bmcgdG8gc2VhcmNoIGZvciBpdCB1bmRlciBzb21lIGZvbGRlci4KQWxzbyBJIHByZWZlciB0byBy
ZW5hbWUgY29uZmlnL0F1dG9jb25mLm1rIHRvIGNvbmZpZy9Ub29scy5tayB0aGFuIHRvCnBsYWNl
IGl0IGluc2lkZSB0b29scy8uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:41:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:41:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDbA-0004q8-Ah; Mon, 09 Jan 2012 11:41:08 +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 1RkDb8-0004ps-OW
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:41:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326109257!2716255!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 23820 invoked from network); 9 Jan 2012 11:40:59 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 11:40:59 -0000
Received: by daec6 with SMTP id c6so14971830dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 03:40: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=D3dPO+0T5xtnqtoqh7PzmQhWtQfpyrxeGZCSgo27eoI=;
	b=FiOJt4DqErsueg170kEXl9mTYHpDawktNpwG0nnF8NEULOhRXd/TXhX462LC/ghdaY
	8q6mvUrriO9ajP9ask/VgE22mqq8H2JVpXfxmXwOcePL28flhYQzrCNe+XPDCMrP1xW8
	SDmlEMYMeSvrylocHjxuFf34iqX3wmD10AUPM=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr40902102pbc.77.1326109257159; Mon,
	09 Jan 2012 03:40:57 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 9 Jan 2012 03:40:57 -0800 (PST)
In-Reply-To: <4F0AD93B020000780006B281@nat28.tlf.novell.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
	<CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@mail.gmail.com>
	<4F0AD93B020000780006B281@nat28.tlf.novell.com>
Date: Mon, 9 Jan 2012 12:40:57 +0100
X-Google-Sender-Auth: nz_vwc93oJR7zm4-lzCdZ3ETT0U
Message-ID: <CAPLaKK4xWb_isLv01GddWs1mdv7G4PP49b6Pz3jNrFAQo8EDDQ@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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzkgSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2UuY29tPjoKPj4+PiBPbiAwOS4wMS4x
MiBhdCAxMjowNiwgUm9nZXIgUGF1IE1vbm7DqTxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4gd3Jv
dGU6Cj4+IDIwMTIvMS85IEphbiBCZXVsaWNoIDxKQmV1bGljaEBzdXNlLmNvbT46Cj4+Pj4+PiBP
biAwNy4wMS4xMiBhdCAwNDoyMCwgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBj
LmVkdT4gd3JvdGU6Cj4+Pj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4+PiAjIFVzZXIgUm9nZXIg
UGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4+PiAjIERhdGUgMTMyNTkwNjIz
MCAtMzYwMAo+Pj4+ICMgTm9kZSBJRCBlMTJlYzEwNzE0MTBjOTQ2MzY3Y2IwNTA4Y2YyMThhMGMz
YjU5NmNhCj4+Pj4gIyBQYXJlbnQgwqA0MDg2ZTQ4MTE1NDdkZGZmYjlhNTNmYmYyZWZiNmMyZmE0
MzZiNzBhCj4+Pj4gYnVpbGQ6IGFkZCBhdXRvY29uZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3Mg
aW4gdG9vbHMvY2hlY2sKPj4+Pgo+Pj4+IEFkZGVkIGF1dG90b29scyBtYWdpYyB0byByZXBsYWNl
IGN1c3RvbSBjaGVjayBzY3JpcHRzLiBUaGUgcHJldmlvdXMKPj4+PiBjaGVja3MgaGF2ZSBiZWVu
IHBvcnRlZCB0byBhdXRvY29uZiwgYW5kIHNvbWUgYWRkaXRpb25hbCBvbmVzIGhhdmUKPj4+PiBi
ZWVuIGFkZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBU
d28gZmlsZXMgYXJlCj4+Pj4gY3JlYXRlZCBhcyBhIHJlc3VsdCBmcm9tIGV4ZWN1dGluZyBjb25m
aWd1cmUgc2NyaXB0LAo+Pj4+IGNvbmZpZy9BdXRvY29uZi5tayBhbmQgY29uZmlnLmguCj4+Pj4K
Pj4+PiBBdXRvY29uZi5tayBpcyBpbmNsdWRlZCBieSBDb25maWcubWssIGFuZCBjb250YWlucyBt
b3N0IG9mIHRoZQo+Pj4+IG9wdGlvbnMgcHJldmlvdXNseSBkZWZpbmVkIGluIC5jb25maWcsIHRo
YXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwo+Pj4+IHBhcmFtZXRlcnMgb3IgZGVmaW5pbmcgZW52
aXJvbm1lbnQgdmFyaWFibGVzIHdoZW4gZXhlY3V0aW5nIGNvbmZpZ3VyZQo+Pj4+IHNjcmlwdC4K
Pj4+Pgo+Pj4+IGNvbmZpZy5oIGlzIHN0aWxsIG5vdCB1c2VkIGFueXdoZXJlLCBhbmQgaXMgYXV0
b21hdGljYWxseSBjcmVhdGVkIGJ5Cj4+Pj4gYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1pZ2gg
Y2hhbmdlIHdoZW4gd2Ugc3RhcnQgdG8gaW5jbHVkZSB0aGlzCj4+Pj4gZmlsZS4KPj4+Pgo+Pj4+
IEp1c3QgYSBmaXJzdCByZWxlYXNlLCBhbmQgc2luY2UgSWl0J3MgbXkgZmlyc3QgYXV0b2NvbmYg
c2NyaXB0IEkgZ3Vlc3MKPj4+PiB0aGVyZSB3aWxsIGJlIG1hbnkgdGhpbmdzIHRvIHBvbGlzaCBo
ZXJlLi4uIFBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuCj4+Pj4KPj4+PiBTaWduZWQtb2ZmLWJ5
OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pj4+Cj4+Pj4gZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIENvbmZpZy5tawo+Pj4+IC0tLSBhL0Nv
bmZpZy5tayDCoCDCoCDCoCBUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4+PiArKysg
Yi9Db25maWcubWsgwqAgwqAgwqAgU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCj4+Pj4g
QEAgLTksOCArOSw2IEBAIHJlYWxwYXRoID0gJCh3aWxkY2FyZCAkKGZvcmVhY2ggZmlsZSwkKDEK
Pj4+Pgo+Pj4+IMKgLWluY2x1ZGUgJChYRU5fUk9PVCkvLmNvbmZpZwo+Pj4+Cj4+Pj4gLSMgQSBk
ZWJ1ZyBidWlsZCBvZiBYZW4gYW5kIHRvb2xzPwo+Pj4+IC1kZWJ1ZyA/PSB5Cj4+Pgo+Pj4gSSB0
aGluayB0aGlzIHNob3VsZCBiZSBrZXB0IGhlcmUgKHBvc3NpYmx5IG92ZXJyaWRlLWFibGUgYnkg
dGhlIGF1dG9jb25mCj4+PiBkZXRlcm1pbmVkIHNldHRpbmcsIGkuZS4gaXQgbWF5IG5lZWQgbW92
aW5nIHBhc3QgdGhlIGluY2x1c2lvbiBiZWxvdykuCj4+Pgo+Pj4+Cj4+Pj4gwqBYRU5fQ09NUElM
RV9BUkNIIMKgIMKgPz0gJChzaGVsbCB1bmFtZSAtbSB8IHNlZCAtZSBzL2kuODYveDg2XzMyLyBc
Cj4+Pj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgLWUgcy9pODZwYy94
ODZfMzIvIC1lIHMvYW1kNjQveDg2XzY0LykKPj4+PiBAQCAtNDMsNiArNDEsNyBAQCBlbmRpZgo+
Pj4+Cj4+Pj4gwqBpbmNsdWRlICQoWEVOX1JPT1QpL2NvbmZpZy8kKFhFTl9PUykubWsKPj4+PiDC
oGluY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnLyQoWEVOX1RBUkdFVF9BUkNIKS5tawo+Pj4+ICtp
bmNsdWRlICQoWEVOX1JPT1QpL2NvbmZpZy9BdXRvY29uZi5tawo+Pj4KPj4+IEFuZCBJIHdvdWxk
IHJlYWxseSBsaWtlIHRvIGF2b2lkIGhhdmluZyBoeXBlcnZpc29yIChhbmQgcGVyaGFwcwo+Pj4g
YWxzbyBzdHViZG9tKSBidWlsZHMgdG8gcmVxdWlyZSBydW5uaW5nIHRoZSBhdXRvY29uZmlnIHRo
aW5nCj4+PiBmaXJzdCAtIHRoaXMgb3VnaHQgdG8gYmUgbGltaXRlZCB0byB0aGUgdG9vbHMgKGFz
IHdlcmUgdGhlIGNoZWNrCj4+PiBzY3JpcHRzKS4KPj4KPj4KPj4gRG9pbmcgc29tZXRoaW5nIGxp
a2UgdGhpcyBpcyBwcm9iYWJseSBtb3JlIHN1aXRhYmxlOgo+Pgo+PiBkaWZmIC1yIGUxMmVjMTA3
MTQxMCB0b29scy9NYWtlZmlsZQo+PiAtLS0gYS90b29scy9NYWtlZmlsZSDCoFNhdCBKYW4gMDcg
MDQ6MTc6MTAgMjAxMiArMDEwMAo+PiArKysgYi90b29scy9NYWtlZmlsZSDCoFNhdCBKYW4gMDcg
MDY6NDY6NTUgMjAxMiArMDEwMAo+PiBAQCAtMSw0ICsxLDUgQEAKPj4gwqBYRU5fUk9PVCA9ICQo
Q1VSRElSKS8uLgo+PiAraW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvQXV0b2NvbmYubWsKPj4g
wqBpbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCj4+Cj4+IMKgaWZuZXEgKCQoQ09O
RklHX1NZU1RFTV9MSUJBSU8pLHkpCj4KPiBZZXMsIHBsZWFzZS4gT2YgY291cnNlLCB0aGUgcXVl
c3Rpb24gdGhlbiBpcyB3aGV0aGVyIGl0IHNob3VsZG4ndAo+IHJlYWxseSBiZSB0b29scy9BdXRv
Y29uZi5tayAoYW5kIHdoZXRoZXIgcGVyaGFwcyB0aGUgd2hvbGUgc2V0Cj4gb2YgbmV3IGZpbGVz
IHNob3VsZCBhbHNvIGJlIHJvb3RlZCB1bmRlciB0b29scy8gcmF0aGVyIHRoYW4gYXQKPiAkKFhF
Tl9ST09UKS8pLgoKSSB0aGluayBpdCdzIG1vcmUgY29tbW9uIHRvIGZpbmQgYSBjb25maWd1cmUg
c2NyaXB0IGluIHRoZSByb290IGZvbGRlcgpvZiB0aGUgcGFja2FnZSByYXRoZXIgdGhhbiBoYXZp
bmcgdG8gc2VhcmNoIGZvciBpdCB1bmRlciBzb21lIGZvbGRlci4KQWxzbyBJIHByZWZlciB0byBy
ZW5hbWUgY29uZmlnL0F1dG9jb25mLm1rIHRvIGNvbmZpZy9Ub29scy5tayB0aGFuIHRvCnBsYWNl
IGl0IGluc2lkZSB0b29scy8uCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:44:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:44:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDeM-00052i-5H; Mon, 09 Jan 2012 11:44:26 +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 1RkDeK-00052c-Ry
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:44:25 +0000
X-Env-Sender: mrezanin@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326109423!59429524!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzEwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1898 invoked from network); 9 Jan 2012 11:43:43 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-9.tower-27.messagelabs.com with SMTP;
	9 Jan 2012 11:43:43 -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 q09BiMw5014678
	for <xen-devel@lists.xensource.com>; Mon, 9 Jan 2012 06:44:22 -0500
Date: Mon, 09 Jan 2012 06:44:22 -0500 (EST)
From: Miroslav Rezanina <mrezanin@redhat.com>
To: xen-devel <xen-devel@lists.xensource.com>
Message-ID: <8edf9020-ff8c-4e52-90b1-366d5b723164@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <3b140b77-b312-4097-bdae-88935d407cf3@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.112.16]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Linux)/7.1.2_GA_3268)
Subject: [Xen-devel] [PATCH] xenstat: Correct copy of network device name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 xenstat library parse /proc/net/dev, it uses strpbrk function to get pointer
to device name. However, it miss capital letters in the array of valid characters
so it get incorrect name in case device name starts with capital letters or even
segfault if it contains only capital letters.

This patch adds missing characters to strpbrk call.

Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>

diff -r 4086e4811547 tools/xenstat/libxenstat/src/xenstat_linux.c
--- a/tools/xenstat/libxenstat/src/xenstat_linux.c	Thu Jan 05 17:25:23 2012 +0000
+++ b/tools/xenstat/libxenstat/src/xenstat_linux.c	Mon Jan 09 12:40:05 2012 +0100
@@ -222,7 +222,7 @@
 				else
 				/* There were errors when parsing this directly in RE. strpbrk() helps */
 				if (iface != NULL)
-					strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstvuwxyz0123456789"));
+					strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"));
 
 				memset(tmp, 0, matches[i].rm_eo - matches[i].rm_so);
 			}
-- 
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 Jan 09 11:44:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:44:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDeM-00052i-5H; Mon, 09 Jan 2012 11:44:26 +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 1RkDeK-00052c-Ry
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:44:25 +0000
X-Env-Sender: mrezanin@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326109423!59429524!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzEwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1898 invoked from network); 9 Jan 2012 11:43:43 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-9.tower-27.messagelabs.com with SMTP;
	9 Jan 2012 11:43:43 -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 q09BiMw5014678
	for <xen-devel@lists.xensource.com>; Mon, 9 Jan 2012 06:44:22 -0500
Date: Mon, 09 Jan 2012 06:44:22 -0500 (EST)
From: Miroslav Rezanina <mrezanin@redhat.com>
To: xen-devel <xen-devel@lists.xensource.com>
Message-ID: <8edf9020-ff8c-4e52-90b1-366d5b723164@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <3b140b77-b312-4097-bdae-88935d407cf3@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.36.112.16]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - SAF3 (Linux)/7.1.2_GA_3268)
Subject: [Xen-devel] [PATCH] xenstat: Correct copy of network device name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 xenstat library parse /proc/net/dev, it uses strpbrk function to get pointer
to device name. However, it miss capital letters in the array of valid characters
so it get incorrect name in case device name starts with capital letters or even
segfault if it contains only capital letters.

This patch adds missing characters to strpbrk call.

Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>

diff -r 4086e4811547 tools/xenstat/libxenstat/src/xenstat_linux.c
--- a/tools/xenstat/libxenstat/src/xenstat_linux.c	Thu Jan 05 17:25:23 2012 +0000
+++ b/tools/xenstat/libxenstat/src/xenstat_linux.c	Mon Jan 09 12:40:05 2012 +0100
@@ -222,7 +222,7 @@
 				else
 				/* There were errors when parsing this directly in RE. strpbrk() helps */
 				if (iface != NULL)
-					strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstvuwxyz0123456789"));
+					strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"));
 
 				memset(tmp, 0, matches[i].rm_eo - matches[i].rm_so);
 			}
-- 
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 Jan 09 11:51:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDki-0005Gn-Vn; Mon, 09 Jan 2012 11:51:00 +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 1RkDkh-0005Gi-V3
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:51:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326109853!10249067!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17962 invoked from network); 9 Jan 2012 11:50:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 11:50:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326109853; l=288;
	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=oUuWEFrNOWco6HX7MHbSuYRLmCQ=;
	b=FIAe7NSAVjr/AaA6L0U1PaXQs6GWWRmJVHS82ispM2eoR/42BEh2Zeb+BEyVLKz+XwD
	Csc2ISZBY+Eik02yEUPXFSiGRAjStsCy/UDNKioO4dumOrH4DzSR4PoBuQRnEEC7aFDzr
	WE9OBpXKg0U3NT2MNltT30Kv90bHUjyZvIo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (fruni mo50) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z06190o09AntLM ;
	Mon, 9 Jan 2012 12:50:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6276C18637; Mon,  9 Jan 2012 12:50:41 +0100 (CET)
Date: Mon, 9 Jan 2012 12:50:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120109115041.GA20678@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20229.60517.106414.825193@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, hongkaixing@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, Ian Jackson wrote:

> Use of types with names ending in _t is reserved to the C
> implementation (compiler and runtime).  I know xenpaging is full of
> these but we shouldn't introduce any more.

I will prepare patches to remove the typedefs from xenpaging.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 11:51:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 11:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDki-0005Gn-Vn; Mon, 09 Jan 2012 11:51:00 +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 1RkDkh-0005Gi-V3
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 11:51:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326109853!10249067!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17962 invoked from network); 9 Jan 2012 11:50:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 11:50:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326109853; l=288;
	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=oUuWEFrNOWco6HX7MHbSuYRLmCQ=;
	b=FIAe7NSAVjr/AaA6L0U1PaXQs6GWWRmJVHS82ispM2eoR/42BEh2Zeb+BEyVLKz+XwD
	Csc2ISZBY+Eik02yEUPXFSiGRAjStsCy/UDNKioO4dumOrH4DzSR4PoBuQRnEEC7aFDzr
	WE9OBpXKg0U3NT2MNltT30Kv90bHUjyZvIo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (fruni mo50) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z06190o09AntLM ;
	Mon, 9 Jan 2012 12:50:42 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 6276C18637; Mon,  9 Jan 2012 12:50:41 +0100 (CET)
Date: Mon, 9 Jan 2012 12:50:41 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120109115041.GA20678@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20229.60517.106414.825193@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, hongkaixing@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 05, Ian Jackson wrote:

> Use of types with names ending in _t is reserved to the C
> implementation (compiler and runtime).  I know xenpaging is full of
> these but we shouldn't introduce any more.

I will prepare patches to remove the typedefs from xenpaging.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:03:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDwo-0005fB-6A; Mon, 09 Jan 2012 12:03: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 1RkDwm-0005f0-SE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326110602!10122781!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9196 invoked from network); 9 Jan 2012 12:03:22 -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;
	9 Jan 2012 12:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9894946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:03: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; Mon, 9 Jan 2012
	12:03:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 9 Jan 2012 12:03:18 +0000
In-Reply-To: <e12ec1071410c946367c.1325906408@build.localdomain>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326110599.17210.81.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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-01-07 at 03:20 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1325906230 -3600
> # Node ID e12ec1071410c946367cb0508cf218a0c3b596ca
> # Parent  4086e4811547ddffb9a53fbf2efb6c2fa436b70a
> build: add autoconf to replace custom checks in tools/check
> 
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script,
> config/Autoconf.mk and config.h.
> 
> Autoconf.mk is included by Config.mk, and contains most of the
> options previously defined in .config, that can now be set passing
> parameters or defining environment variables when executing configure
> script.
> 
> config.h is still not used anywhere, and is automatically created by
> autoheader, altough this migh change when we start to include this
> file.
> 
> Just a first release, and since Iit's my first autoconf script I guess
> there will be many things to polish here... Please review and comment.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

I would have expected to see an update to the clean/distclean rules
and .hgignore due to all the new generated files.

> diff -r 4086e4811547 -r e12ec1071410 README
> --- a/README    Thu Jan 05 17:25:23 2012 +0000
> +++ b/README    Sat Jan 07 04:17:10 2012 +0100
> @@ -87,9 +87,15 @@ 2. cd to xen-unstable (or whatever you s
>  3. For the very first build, or if you want to destroy build trees,
>     perform the following steps:
> 
> +    # automake -a

We aren't using automake though? Perhaps this explains your problem with
things alwyas trying to use Makefile.am?

> +    # autoheader && autoconf

What does autoheader do? This should be clearly noted as being only
necessary if building from hg and not if you are building from tarball.
I expect we also need some makefile runes or process updates to make
sure the generated stuff gets included in the tarball.

You need to add the relevant packages to the list of build requirements.

> +    # ./configure
>      # make world
>      # make install
> 
> +   If you want, you can run ./configure --help to see the list of
> +   optins available options when building and installing Xen.

      options

> +
>     This will create and install onto the local machine. It will build
>     the xen binary (xen.gz), the tools and the documentation.
> 
> diff -r 4086e4811547 -r e12ec1071410 config/Autoconf.mk.in
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/config/Autoconf.mk.in     Sat Jan 07 04:17:10 2012 +0100
> @@ -0,0 +1,49 @@
> +# Prefix and install folder
> +PREFIX              := @prefix@
> +LIBLEAFDIR_x86_64   := @LIB_PATH@
> +
> +# A debug build of Xen and tools?
> +debug               := @debug@
> +
> +# Tools path
> +BISON               := @BISON@
> +FLEX                := @FLEX@
> +PYTHON              := @PYTHON@
> +PERL                := @PERL@
> +BRCTL               := @BRCTL@
> +IP                  := @IP@
> +CURL-CONFIG         := @CURL@

Are hyphens ok in make variables?

> +XML2-CONFIG         := @XML@
> +BASH                := @BASH@
> +XGETTTEXT           := @XGETTEXT@
> +
> +# Extra folder for libs/includes
> +PREPEND_INCLUDES    := @PREPEND_INCLUDES@
> +PREPEND_LIB         := @PREPEND_LIB@
> +APPEND_INCLUDES     := @APPEND_INCLUDES@
> +APPEND_LIB          := @APPEND_LIB@
> +
> +# Enable XSM security module (by default, Flask).
> +XSM_ENABLE          := @xsm@
> +FLASK_ENABLE        := @xsm@
> +
> +# Download GIT repositories via HTTP or GIT's own protocol?
> +# GIT's protocol is faster and more robust, when it works at all (firewalls
> +# may block it). We make it the default, but if your GIT repository downloads
> +# fail or hang, please specify GIT_HTTP=y in your environment.
> +GIT_HTTP            := @githttp@
> +
> +# Optional components
> +XENSTAT_XENTOP      := @monitors@
> +VTPM_TOOLS          := @vtpm@
> +LIBXENAPI_BINDINGS  := @xapi@
> +PYTHON_TOOLS        := @pythontools@
> +OCAML_TOOLS         := @ocamltools@
> +CONFIG_MINITERM     := @miniterm@
> +CONFIG_LOMOUNT      := @lomount@
> +
> +#System options
> +CONFIG_SYSTEM_LIBAIO:= @system_aio@
> +CONFIG_LIBICONV     := @libiconv@
> +CONFIG_GCRYPT       := @libgcrypt@
> +CONFIG_EXT2FS       := @libext2fs@
> diff -r 4086e4811547 -r e12ec1071410 configure.ac
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/configure.ac      Sat Jan 07 04:17:10 2012 +0100
> @@ -0,0 +1,179 @@
> +#                                               -*- Autoconf -*-
> +# Process this file with autoconf to produce a configure script.
> +
> +AC_PREREQ([2.67])

This is the version in Debian stable which is my rule of thumb for how
far back to support things as a minimum.

However do we rely on features of 2.67 or could we go older if someone
has an older version?

> +AC_INIT([Xen Hypervisor], [4.2], [xen-devel@lists.xensource.com])

Ideally the 4.2 would not be duplicated both here and in xen/Makefile.
I'm not sure how this can be resolved without conflicting with Jan's
(quite reasonable) desire not to need ./configure for the hypervisor.

I suppose it must be possible via the magic of m4 to pull out the
version from the Makefile and include it here.

I didn't review all the tests in detail, I presume we'll end up having
to find a bunch of those errors via testing anywhere.

Does the set of tests here precisely equal those currently done by
tools/check (or elsewhere) or did you add more as you went? It might
have been better for review to present this as a basic infrastructure
patch, the conversion of each test individually as a patch each and
lastly any new tests etc so we could easily review. But I think it's a
bit late now and there's no point splitting this patch up now you've got
it.

> +AC_CONFIG_SRCDIR([tools/libxl/libxl.c])
> +AC_CONFIG_HEADERS([config.h])
> +AC_CONFIG_FILES([config/Autoconf.mk])
> +AC_PREFIX_DEFAULT([/usr])
> +
> +# Check if CFLAGS, LDFLAGS, LIBS, CPPFLAGS or CPP is set and print a warning
> +
> +AS_IF([test -n "$CC$CFLAGS$LDFLAGS$LIBS$CPPFLAGS$CPP"], [
> +    AC_MSG_WARN(
> +[Setting CC, CFLAGS, LDFLAGS, LIBS, CPPFLAGS or CPP is not \
> +recommended, use PREPEND_INCLUDES, PREPEND_LIB, \
> +APPEND_INCLUDES and APPEND_LIB instead when possible.])
> +])
> +
> +AC_USE_SYSTEM_EXTENSIONS
> +AC_CANONICAL_HOST
> +
> +# M4 Macro includes
> +m4_include([m4/enable_feature.m4])
> +m4_include([m4/disable_feature.m4])
> +m4_include([m4/path_or_fail.m4])
> +m4_include([m4/python_xml.m4])
> +m4_include([m4/python_version.m4])
> +m4_include([m4/python_devel.m4])
> +m4_include([m4/udev.m4])
> +m4_include([m4/ocaml.m4])
> +m4_include([m4/default_lib.m4])
> +m4_include([m4/set_cflags_ldflags.m4])
> +
> +# Enable/disable options
> +AX_ARG_ENABLE_AND_EXPORT([xsm],
> +    [Enable XSM security module (by default, Flask)])

Does this macro include support for reading from config.cache as well as
the cmdline option?

[...]
> +AS_IF([test "x$ocamltools" = "xy"], [
> +    AC_PROG_OCAML
> +    AS_IF([test "x$OCAMLC" = "xno"], [
> +      AC_MSG_ERROR([You must install the OCaml compiler])

ocaml was previously optional, I think.

[...]
> +
> +# Checks for header files.
> +AC_FUNC_ALLOCA
> +AC_CHECK_HEADERS([ \
> +                arpa/inet.h fcntl.h inttypes.h libintl.h limits.h malloc.h \
> +                netdb.h netinet/in.h stddef.h stdint.h stdlib.h string.h \
> +                strings.h sys/file.h sys/ioctl.h sys/mount.h sys/param.h \
> +                sys/socket.h sys/statvfs.h sys/time.h syslog.h termios.h \
> +                unistd.h yajl/yajl_version.h \
> +                ])
> +
> +# Checks for typedefs, structures, and compiler characteristics.
> +AC_HEADER_STDBOOL
> +AC_TYPE_UID_T
> +AC_C_INLINE
> +AC_TYPE_INT16_T
> +AC_TYPE_INT32_T
> +AC_TYPE_INT64_T
> +AC_TYPE_INT8_T

There's no AC_TYPE_STDINT or similar?

> +AC_TYPE_MODE_T
> +AC_TYPE_OFF_T
> +AC_TYPE_PID_T
> +AC_C_RESTRICT
> +AC_TYPE_SIZE_T
> +AC_TYPE_SSIZE_T

Is there not some umbrella test for these sorts of very standard things,
e.g. AC_POSIX or something like that?

> +AC_CHECK_MEMBERS([struct stat.st_blksize])
> +AC_STRUCT_ST_BLOCKS
> +AC_CHECK_MEMBERS([struct stat.st_rdev])
> +AC_TYPE_UINT16_T
> +AC_TYPE_UINT32_T
> +AC_TYPE_UINT64_T
> +AC_TYPE_UINT8_T
> +AC_CHECK_TYPES([ptrdiff_t])
> +
> +# Checks for library functions.
> +AC_FUNC_ERROR_AT_LINE
> +AC_FUNC_FORK
> +AC_FUNC_FSEEKO
> +AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
> +AC_HEADER_MAJOR
> +AC_FUNC_MALLOC
> +AC_FUNC_MKTIME
> +AC_FUNC_MMAP
> +AC_FUNC_REALLOC
> +AC_FUNC_STRNLEN
> +AC_FUNC_STRTOD
> +AC_CHECK_FUNCS([ \
> +                alarm atexit bzero clock_gettime dup2 fdatasync ftruncate \
> +                getcwd gethostbyname gethostname getpagesize gettimeofday \
> +                inet_ntoa isascii localtime_r memchr memmove memset mkdir \
> +                mkfifo munmap pathconf realpath regcomp rmdir select setenv \
> +                socket strcasecmp strchr strcspn strdup strerror strndup \
> +                strpbrk strrchr strspn strstr strtol strtoul strtoull tzset \
> +                uname \
> +                ])
> +
> +AC_OUTPUT()
> diff -r 4086e4811547 -r e12ec1071410 m4/default_lib.m4
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/m4/default_lib.m4 Sat Jan 07 04:17:10 2012 +0100
> @@ -0,0 +1,7 @@
> +AC_DEFUN([AX_DEFAULT_LIB],
> +[AS_IF([test -d "$prefix/lib64"], [
> +    LIB_PATH="lib64"
> +],[
> +    LIB_PATH="lib"
> +])
> +AC_SUBST(LIB_PATH)])

Does this get exposed via config.cache and/or the command line? It
should be.

Did you write m4/* from scratch or did they come from some snippet
library?

Isn't the management of these snippets the sort of thing aclocal does
for you?

> \ No newline at end of file

Might this newline be significant in a macro expansion library? I think
it's good practice to include it anyway (here and elsewhere).

[...]
> diff -r 4086e4811547 -r e12ec1071410 m4/ocaml.m4
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/m4/ocaml.m4       Sat Jan 07 04:17:10 2012 +0100
> @@ -0,0 +1,240 @@
> +dnl autoconf macros for OCaml

Please add a comment describing where this came from so we know how to
update in the future. 

Shouldn't/couldn't this be provided by the ocaml packages and just
included by us?

[...]

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:03:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12:03:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkDwo-0005fB-6A; Mon, 09 Jan 2012 12:03: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 1RkDwm-0005f0-SE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:03:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326110602!10122781!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9196 invoked from network); 9 Jan 2012 12:03:22 -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;
	9 Jan 2012 12:03:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9894946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:03: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; Mon, 9 Jan 2012
	12:03:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Mon, 9 Jan 2012 12:03:18 +0000
In-Reply-To: <e12ec1071410c946367c.1325906408@build.localdomain>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326110599.17210.81.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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-01-07 at 03:20 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1325906230 -3600
> # Node ID e12ec1071410c946367cb0508cf218a0c3b596ca
> # Parent  4086e4811547ddffb9a53fbf2efb6c2fa436b70a
> build: add autoconf to replace custom checks in tools/check
> 
> Added autotools magic to replace custom check scripts. The previous
> checks have been ported to autoconf, and some additional ones have
> been added (plus the suggestions from running autoscan). Two files are
> created as a result from executing configure script,
> config/Autoconf.mk and config.h.
> 
> Autoconf.mk is included by Config.mk, and contains most of the
> options previously defined in .config, that can now be set passing
> parameters or defining environment variables when executing configure
> script.
> 
> config.h is still not used anywhere, and is automatically created by
> autoheader, altough this migh change when we start to include this
> file.
> 
> Just a first release, and since Iit's my first autoconf script I guess
> there will be many things to polish here... Please review and comment.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

I would have expected to see an update to the clean/distclean rules
and .hgignore due to all the new generated files.

> diff -r 4086e4811547 -r e12ec1071410 README
> --- a/README    Thu Jan 05 17:25:23 2012 +0000
> +++ b/README    Sat Jan 07 04:17:10 2012 +0100
> @@ -87,9 +87,15 @@ 2. cd to xen-unstable (or whatever you s
>  3. For the very first build, or if you want to destroy build trees,
>     perform the following steps:
> 
> +    # automake -a

We aren't using automake though? Perhaps this explains your problem with
things alwyas trying to use Makefile.am?

> +    # autoheader && autoconf

What does autoheader do? This should be clearly noted as being only
necessary if building from hg and not if you are building from tarball.
I expect we also need some makefile runes or process updates to make
sure the generated stuff gets included in the tarball.

You need to add the relevant packages to the list of build requirements.

> +    # ./configure
>      # make world
>      # make install
> 
> +   If you want, you can run ./configure --help to see the list of
> +   optins available options when building and installing Xen.

      options

> +
>     This will create and install onto the local machine. It will build
>     the xen binary (xen.gz), the tools and the documentation.
> 
> diff -r 4086e4811547 -r e12ec1071410 config/Autoconf.mk.in
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/config/Autoconf.mk.in     Sat Jan 07 04:17:10 2012 +0100
> @@ -0,0 +1,49 @@
> +# Prefix and install folder
> +PREFIX              := @prefix@
> +LIBLEAFDIR_x86_64   := @LIB_PATH@
> +
> +# A debug build of Xen and tools?
> +debug               := @debug@
> +
> +# Tools path
> +BISON               := @BISON@
> +FLEX                := @FLEX@
> +PYTHON              := @PYTHON@
> +PERL                := @PERL@
> +BRCTL               := @BRCTL@
> +IP                  := @IP@
> +CURL-CONFIG         := @CURL@

Are hyphens ok in make variables?

> +XML2-CONFIG         := @XML@
> +BASH                := @BASH@
> +XGETTTEXT           := @XGETTEXT@
> +
> +# Extra folder for libs/includes
> +PREPEND_INCLUDES    := @PREPEND_INCLUDES@
> +PREPEND_LIB         := @PREPEND_LIB@
> +APPEND_INCLUDES     := @APPEND_INCLUDES@
> +APPEND_LIB          := @APPEND_LIB@
> +
> +# Enable XSM security module (by default, Flask).
> +XSM_ENABLE          := @xsm@
> +FLASK_ENABLE        := @xsm@
> +
> +# Download GIT repositories via HTTP or GIT's own protocol?
> +# GIT's protocol is faster and more robust, when it works at all (firewalls
> +# may block it). We make it the default, but if your GIT repository downloads
> +# fail or hang, please specify GIT_HTTP=y in your environment.
> +GIT_HTTP            := @githttp@
> +
> +# Optional components
> +XENSTAT_XENTOP      := @monitors@
> +VTPM_TOOLS          := @vtpm@
> +LIBXENAPI_BINDINGS  := @xapi@
> +PYTHON_TOOLS        := @pythontools@
> +OCAML_TOOLS         := @ocamltools@
> +CONFIG_MINITERM     := @miniterm@
> +CONFIG_LOMOUNT      := @lomount@
> +
> +#System options
> +CONFIG_SYSTEM_LIBAIO:= @system_aio@
> +CONFIG_LIBICONV     := @libiconv@
> +CONFIG_GCRYPT       := @libgcrypt@
> +CONFIG_EXT2FS       := @libext2fs@
> diff -r 4086e4811547 -r e12ec1071410 configure.ac
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/configure.ac      Sat Jan 07 04:17:10 2012 +0100
> @@ -0,0 +1,179 @@
> +#                                               -*- Autoconf -*-
> +# Process this file with autoconf to produce a configure script.
> +
> +AC_PREREQ([2.67])

This is the version in Debian stable which is my rule of thumb for how
far back to support things as a minimum.

However do we rely on features of 2.67 or could we go older if someone
has an older version?

> +AC_INIT([Xen Hypervisor], [4.2], [xen-devel@lists.xensource.com])

Ideally the 4.2 would not be duplicated both here and in xen/Makefile.
I'm not sure how this can be resolved without conflicting with Jan's
(quite reasonable) desire not to need ./configure for the hypervisor.

I suppose it must be possible via the magic of m4 to pull out the
version from the Makefile and include it here.

I didn't review all the tests in detail, I presume we'll end up having
to find a bunch of those errors via testing anywhere.

Does the set of tests here precisely equal those currently done by
tools/check (or elsewhere) or did you add more as you went? It might
have been better for review to present this as a basic infrastructure
patch, the conversion of each test individually as a patch each and
lastly any new tests etc so we could easily review. But I think it's a
bit late now and there's no point splitting this patch up now you've got
it.

> +AC_CONFIG_SRCDIR([tools/libxl/libxl.c])
> +AC_CONFIG_HEADERS([config.h])
> +AC_CONFIG_FILES([config/Autoconf.mk])
> +AC_PREFIX_DEFAULT([/usr])
> +
> +# Check if CFLAGS, LDFLAGS, LIBS, CPPFLAGS or CPP is set and print a warning
> +
> +AS_IF([test -n "$CC$CFLAGS$LDFLAGS$LIBS$CPPFLAGS$CPP"], [
> +    AC_MSG_WARN(
> +[Setting CC, CFLAGS, LDFLAGS, LIBS, CPPFLAGS or CPP is not \
> +recommended, use PREPEND_INCLUDES, PREPEND_LIB, \
> +APPEND_INCLUDES and APPEND_LIB instead when possible.])
> +])
> +
> +AC_USE_SYSTEM_EXTENSIONS
> +AC_CANONICAL_HOST
> +
> +# M4 Macro includes
> +m4_include([m4/enable_feature.m4])
> +m4_include([m4/disable_feature.m4])
> +m4_include([m4/path_or_fail.m4])
> +m4_include([m4/python_xml.m4])
> +m4_include([m4/python_version.m4])
> +m4_include([m4/python_devel.m4])
> +m4_include([m4/udev.m4])
> +m4_include([m4/ocaml.m4])
> +m4_include([m4/default_lib.m4])
> +m4_include([m4/set_cflags_ldflags.m4])
> +
> +# Enable/disable options
> +AX_ARG_ENABLE_AND_EXPORT([xsm],
> +    [Enable XSM security module (by default, Flask)])

Does this macro include support for reading from config.cache as well as
the cmdline option?

[...]
> +AS_IF([test "x$ocamltools" = "xy"], [
> +    AC_PROG_OCAML
> +    AS_IF([test "x$OCAMLC" = "xno"], [
> +      AC_MSG_ERROR([You must install the OCaml compiler])

ocaml was previously optional, I think.

[...]
> +
> +# Checks for header files.
> +AC_FUNC_ALLOCA
> +AC_CHECK_HEADERS([ \
> +                arpa/inet.h fcntl.h inttypes.h libintl.h limits.h malloc.h \
> +                netdb.h netinet/in.h stddef.h stdint.h stdlib.h string.h \
> +                strings.h sys/file.h sys/ioctl.h sys/mount.h sys/param.h \
> +                sys/socket.h sys/statvfs.h sys/time.h syslog.h termios.h \
> +                unistd.h yajl/yajl_version.h \
> +                ])
> +
> +# Checks for typedefs, structures, and compiler characteristics.
> +AC_HEADER_STDBOOL
> +AC_TYPE_UID_T
> +AC_C_INLINE
> +AC_TYPE_INT16_T
> +AC_TYPE_INT32_T
> +AC_TYPE_INT64_T
> +AC_TYPE_INT8_T

There's no AC_TYPE_STDINT or similar?

> +AC_TYPE_MODE_T
> +AC_TYPE_OFF_T
> +AC_TYPE_PID_T
> +AC_C_RESTRICT
> +AC_TYPE_SIZE_T
> +AC_TYPE_SSIZE_T

Is there not some umbrella test for these sorts of very standard things,
e.g. AC_POSIX or something like that?

> +AC_CHECK_MEMBERS([struct stat.st_blksize])
> +AC_STRUCT_ST_BLOCKS
> +AC_CHECK_MEMBERS([struct stat.st_rdev])
> +AC_TYPE_UINT16_T
> +AC_TYPE_UINT32_T
> +AC_TYPE_UINT64_T
> +AC_TYPE_UINT8_T
> +AC_CHECK_TYPES([ptrdiff_t])
> +
> +# Checks for library functions.
> +AC_FUNC_ERROR_AT_LINE
> +AC_FUNC_FORK
> +AC_FUNC_FSEEKO
> +AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
> +AC_HEADER_MAJOR
> +AC_FUNC_MALLOC
> +AC_FUNC_MKTIME
> +AC_FUNC_MMAP
> +AC_FUNC_REALLOC
> +AC_FUNC_STRNLEN
> +AC_FUNC_STRTOD
> +AC_CHECK_FUNCS([ \
> +                alarm atexit bzero clock_gettime dup2 fdatasync ftruncate \
> +                getcwd gethostbyname gethostname getpagesize gettimeofday \
> +                inet_ntoa isascii localtime_r memchr memmove memset mkdir \
> +                mkfifo munmap pathconf realpath regcomp rmdir select setenv \
> +                socket strcasecmp strchr strcspn strdup strerror strndup \
> +                strpbrk strrchr strspn strstr strtol strtoul strtoull tzset \
> +                uname \
> +                ])
> +
> +AC_OUTPUT()
> diff -r 4086e4811547 -r e12ec1071410 m4/default_lib.m4
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/m4/default_lib.m4 Sat Jan 07 04:17:10 2012 +0100
> @@ -0,0 +1,7 @@
> +AC_DEFUN([AX_DEFAULT_LIB],
> +[AS_IF([test -d "$prefix/lib64"], [
> +    LIB_PATH="lib64"
> +],[
> +    LIB_PATH="lib"
> +])
> +AC_SUBST(LIB_PATH)])

Does this get exposed via config.cache and/or the command line? It
should be.

Did you write m4/* from scratch or did they come from some snippet
library?

Isn't the management of these snippets the sort of thing aclocal does
for you?

> \ No newline at end of file

Might this newline be significant in a macro expansion library? I think
it's good practice to include it anyway (here and elsewhere).

[...]
> diff -r 4086e4811547 -r e12ec1071410 m4/ocaml.m4
> --- /dev/null   Thu Jan 01 00:00:00 1970 +0000
> +++ b/m4/ocaml.m4       Sat Jan 07 04:17:10 2012 +0100
> @@ -0,0 +1,240 @@
> +dnl autoconf macros for OCaml

Please add a comment describing where this came from so we know how to
update in the future. 

Shouldn't/couldn't this be provided by the ocaml packages and just
included by us?

[...]

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:27:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12: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 1RkEJG-0005sT-C1; Mon, 09 Jan 2012 12:26:42 +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 1RkEJF-0005sO-7B
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:26:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326111994!10121163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13792 invoked from network); 9 Jan 2012 12:26:35 -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;
	9 Jan 2012 12:26:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9895465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:26: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, 9 Jan 2012 12:26:33 +0000
Date: Mon, 9 Jan 2012 12:26:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1681977532-1326111809=:3150"
Content-ID: <alpine.DEB.2.00.1201091224270.3150@kaball-desktop>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-1681977532-1326111809=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1201091224271.3150@kaball-desktop>

On Mon, 9 Jan 2012, Roger Pau Monné wrote:
> > This envisages devicer setup/teardown scripts in driver domains
> > running in a different way to those in the same domain as the
> > toolstack.  Are we sure this is a good idea ?
> 
> No, I think it's best that even is the driver domain is Dom0 the same
> procedure should be executed, and xenbackendd should be running in
> every driver domain, Dom0 included, toolstack should never execute
> hotplug scripts directly.

I agree.


> > I think it would be preferable to have only one interface to device
> > scripts, which is used everywhere.  That interface would have to
> > involve initiation by the toolstack, and collection of resulting
> > success/failure/etc., via xenstore.
> 
> Are we only going to use xenstore to share information between both
> domains (Dom0 <--> Driver domain)?

That would make things easier, but we have to be careful not turning
xenstore in an RPC style mechanism of communication because it is not
very good a that. In that case we would be better off with libvchan.


> I'm going to comment the vif case, but I think both vif and block
> devices should follow the same approach, and hotplug script execution
> has to be something "standard" and should not rely on the type of the
> device.

Right. However vif and block scripts need to be executed at different
points of the lifecycle of the VM.


> > The sequence of events for vifs with a kernel-level backend needs
> > to go like this:
> >  * toolstack tells backend domain to create vif, via xenstore
> 
> How does the toolstack tell a domain to create a device? Creating a
> xenstore entry like:
> 
> /local/domain/<domid>/backend/vif/...
> 
> does trigger the creation of a vif interface in the <domid> domain?

Yes, I think so.


> >  * backend kernel creates a virtual network interface vifNN
> >  * something in backend domain notices that this vifNN
> >    has appeared and consequently
> 
> This should be handled by xenbackendd (I know it will not exactly be
> xenbackendd, but let's call it that way to simplify things), since it
> should be listening to /local/domain/<domid>/backend/* for changes and
> react upon them.

I think this is wrong because we would be tying together the vif
creation with the script execution, while these two kinds of events
might need to be executed at different point in time (especially in the
block case). We need be flexible.
I would make xenbackendd listen to a different xenstore location,
maybe /hotplug/<domid>/*, so that the toolstack can explicitly ask
xenbackendd for something, making sure that it gets done before taking
other actions.


> >  * device setup script runs, enslaves vifNN to bridge, adds
> >    it to routing tables, gives it an address, etc.
> 
> Handled by hotplug scripts.
> 
> >  * something in backend domain domain tells toolstack vif is ready
> 
> Hotplug scripts should change backend state (and write the appropriate
> values) to notify everything when ok. Since xenbackendd is the one
> that executes the scripts, it should examine the exit code of the
> called hotplug script and write the exit status code and message if
> hotplug script execution is not successful. This values can be
> retrieved from the toolstack and notify the user if something failed.

Or the script could write the return value to /hotplug/<domid>/vif/state
itself. Either way should work.


> >  [ device is used ]
> >  * toolstack tells backend domain to destroy vif; perhaps entire
> >    xenstore directory is forcibly removed??
> 
> If entire xenstore directory is forcibly removed, how does xenbackendd
> know the parameters to pass to the hotplug script to shutdown the
> device? Do we have to keep a copy of this somewhere else (xenstore or
> create a xenbackendd private database)?

This problem would disappear if we use /hotplug/<domid> rather than
/local/domain/<domid>/backend to store the parameters.


> Here we have two cases, whether it is a shutdown or a destroy:
> 
> When doing a shutdown the toolstack should wait to get a notification
> from the driver domain that hotplug execution was done (either
> successfully or not) and then proceed with the removal of xenstore
> directory.
> 
> DomU closes device --> driver domain notices --> execution of hotplug
> scripts --> write result to xenstore --> toolstack reads results of
> hotplug teardown.
> 
> When doing a destroy, the toolstack should manually set the frontend
> state to closed, and thus force the execution of hotplug scripts in
> the driver domain? I know this has been a cause of discussion in
> previous patches, but I really don't see the problem with modifying
> the frontend status if the domain is already dead, it's just a way to
> force the unplug of the device and the execution of hotplug scripts.
> Normally the DomU should set the frontend status to closed, but since
> we killed it from the toolstack, it should be the toolstack itself the
> one in charge of setting the status to closed.

this problem would go away too if we use /hotplug/<domid> rather than
/local/domain/<domid>/backend to trigger xenbackendd events.
--8323329-1681977532-1326111809=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1681977532-1326111809=:3150--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:27:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12: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 1RkEJG-0005sT-C1; Mon, 09 Jan 2012 12:26:42 +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 1RkEJF-0005sO-7B
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:26:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326111994!10121163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13792 invoked from network); 9 Jan 2012 12:26:35 -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;
	9 Jan 2012 12:26:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,479,1320624000"; 
   d="scan'208";a="9895465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:26: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, 9 Jan 2012 12:26:33 +0000
Date: Mon, 9 Jan 2012 12:26:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1681977532-1326111809=:3150"
Content-ID: <alpine.DEB.2.00.1201091224270.3150@kaball-desktop>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-1681977532-1326111809=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1201091224271.3150@kaball-desktop>

On Mon, 9 Jan 2012, Roger Pau Monné wrote:
> > This envisages devicer setup/teardown scripts in driver domains
> > running in a different way to those in the same domain as the
> > toolstack.  Are we sure this is a good idea ?
> 
> No, I think it's best that even is the driver domain is Dom0 the same
> procedure should be executed, and xenbackendd should be running in
> every driver domain, Dom0 included, toolstack should never execute
> hotplug scripts directly.

I agree.


> > I think it would be preferable to have only one interface to device
> > scripts, which is used everywhere.  That interface would have to
> > involve initiation by the toolstack, and collection of resulting
> > success/failure/etc., via xenstore.
> 
> Are we only going to use xenstore to share information between both
> domains (Dom0 <--> Driver domain)?

That would make things easier, but we have to be careful not turning
xenstore in an RPC style mechanism of communication because it is not
very good a that. In that case we would be better off with libvchan.


> I'm going to comment the vif case, but I think both vif and block
> devices should follow the same approach, and hotplug script execution
> has to be something "standard" and should not rely on the type of the
> device.

Right. However vif and block scripts need to be executed at different
points of the lifecycle of the VM.


> > The sequence of events for vifs with a kernel-level backend needs
> > to go like this:
> >  * toolstack tells backend domain to create vif, via xenstore
> 
> How does the toolstack tell a domain to create a device? Creating a
> xenstore entry like:
> 
> /local/domain/<domid>/backend/vif/...
> 
> does trigger the creation of a vif interface in the <domid> domain?

Yes, I think so.


> >  * backend kernel creates a virtual network interface vifNN
> >  * something in backend domain notices that this vifNN
> >    has appeared and consequently
> 
> This should be handled by xenbackendd (I know it will not exactly be
> xenbackendd, but let's call it that way to simplify things), since it
> should be listening to /local/domain/<domid>/backend/* for changes and
> react upon them.

I think this is wrong because we would be tying together the vif
creation with the script execution, while these two kinds of events
might need to be executed at different point in time (especially in the
block case). We need be flexible.
I would make xenbackendd listen to a different xenstore location,
maybe /hotplug/<domid>/*, so that the toolstack can explicitly ask
xenbackendd for something, making sure that it gets done before taking
other actions.


> >  * device setup script runs, enslaves vifNN to bridge, adds
> >    it to routing tables, gives it an address, etc.
> 
> Handled by hotplug scripts.
> 
> >  * something in backend domain domain tells toolstack vif is ready
> 
> Hotplug scripts should change backend state (and write the appropriate
> values) to notify everything when ok. Since xenbackendd is the one
> that executes the scripts, it should examine the exit code of the
> called hotplug script and write the exit status code and message if
> hotplug script execution is not successful. This values can be
> retrieved from the toolstack and notify the user if something failed.

Or the script could write the return value to /hotplug/<domid>/vif/state
itself. Either way should work.


> >  [ device is used ]
> >  * toolstack tells backend domain to destroy vif; perhaps entire
> >    xenstore directory is forcibly removed??
> 
> If entire xenstore directory is forcibly removed, how does xenbackendd
> know the parameters to pass to the hotplug script to shutdown the
> device? Do we have to keep a copy of this somewhere else (xenstore or
> create a xenbackendd private database)?

This problem would disappear if we use /hotplug/<domid> rather than
/local/domain/<domid>/backend to store the parameters.


> Here we have two cases, whether it is a shutdown or a destroy:
> 
> When doing a shutdown the toolstack should wait to get a notification
> from the driver domain that hotplug execution was done (either
> successfully or not) and then proceed with the removal of xenstore
> directory.
> 
> DomU closes device --> driver domain notices --> execution of hotplug
> scripts --> write result to xenstore --> toolstack reads results of
> hotplug teardown.
> 
> When doing a destroy, the toolstack should manually set the frontend
> state to closed, and thus force the execution of hotplug scripts in
> the driver domain? I know this has been a cause of discussion in
> previous patches, but I really don't see the problem with modifying
> the frontend status if the domain is already dead, it's just a way to
> force the unplug of the device and the execution of hotplug scripts.
> Normally the DomU should set the frontend status to closed, but since
> we killed it from the toolstack, it should be the toolstack itself the
> one in charge of setting the status to closed.

this problem would go away too if we use /hotplug/<domid> rather than
/local/domain/<domid>/backend to trigger xenbackendd events.
--8323329-1681977532-1326111809=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1681977532-1326111809=:3150--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:30:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12:30:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkEMU-000617-03; Mon, 09 Jan 2012 12:30:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1RkEMS-00060z-HQ
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:30:00 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326112194!10247703!1
X-Originating-IP: [192.134.164.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28974 invoked from network); 9 Jan 2012 12:29:54 -0000
Received: from mail4-relais-sop.national.inria.fr (HELO
	mail4-relais-sop.national.inria.fr) (192.134.164.105)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 12:29:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320620400"; d="scan'208";a="126090977"
Received: from unknown (HELO type.ipv6) ([193.50.110.73])
	by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES256-SHA;
	09 Jan 2012 13:29:53 +0100
Received: from samy by type.ipv6 with local (Exim 4.77)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1RkEML-0000PP-K0; Mon, 09 Jan 2012 13:29:53 +0100
Date: Mon, 9 Jan 2012 13:29:53 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: John Sherwood <jrs@vt.edu>
Message-ID: <20120109122953.GC4424@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	John Sherwood <jrs@vt.edu>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xensource.com
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] extending 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John Sherwood, le Tue 03 Jan 2012 15:45:17 -0500, a =E9crit :
> On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle=
.com>
> wrote:
>     Can't do that. The PS/2 is one of those legacy beasts that depends on
>     ioports.
>     But now that I think of it, maybe you can. In the guest config you can
>     specify
>     the ioports that you want to pass in. I hadn't tried to do this for t=
he
>     keyboard
>     ports but maybe that will work for you?
> =

> =

> =

> I tried forwarding the ioports (off the top of my head, I remember trying=
 60
> and 64) but didn't have any luck - the kb/mouse weren't forwarded despite
> adding the requisite ioports config as per the docs.

Did you also pass the IRQ?

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:30:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12:30:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkEMU-000617-03; Mon, 09 Jan 2012 12:30:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <samuel.thibault@ens-lyon.org>) id 1RkEMS-00060z-HQ
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:30:00 +0000
X-Env-Sender: samuel.thibault@ens-lyon.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326112194!10247703!1
X-Originating-IP: [192.134.164.105]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28974 invoked from network); 9 Jan 2012 12:29:54 -0000
Received: from mail4-relais-sop.national.inria.fr (HELO
	mail4-relais-sop.national.inria.fr) (192.134.164.105)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 12:29:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320620400"; d="scan'208";a="126090977"
Received: from unknown (HELO type.ipv6) ([193.50.110.73])
	by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES256-SHA;
	09 Jan 2012 13:29:53 +0100
Received: from samy by type.ipv6 with local (Exim 4.77)
	(envelope-from <samuel.thibault@ens-lyon.org>)
	id 1RkEML-0000PP-K0; Mon, 09 Jan 2012 13:29:53 +0100
Date: Mon, 9 Jan 2012 13:29:53 +0100
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: John Sherwood <jrs@vt.edu>
Message-ID: <20120109122953.GC4424@type.bordeaux.inria.fr>
Mail-Followup-To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	John Sherwood <jrs@vt.edu>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xensource.com
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] extending 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John Sherwood, le Tue 03 Jan 2012 15:45:17 -0500, a =E9crit :
> On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle=
.com>
> wrote:
>     Can't do that. The PS/2 is one of those legacy beasts that depends on
>     ioports.
>     But now that I think of it, maybe you can. In the guest config you can
>     specify
>     the ioports that you want to pass in. I hadn't tried to do this for t=
he
>     keyboard
>     ports but maybe that will work for you?
> =

> =

> =

> I tried forwarding the ioports (off the top of my head, I remember trying=
 60
> and 64) but didn't have any luck - the kb/mouse weren't forwarded despite
> adding the requisite ioports config as per the docs.

Did you also pass the IRQ?

Samuel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:49:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkEf3-0006HK-Os; Mon, 09 Jan 2012 12:49:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkEf2-0006HC-G4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:49:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326113345!2127443!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1554 invoked from network); 9 Jan 2012 12:49: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;
	9 Jan 2012 12:49:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9895923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:49: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, 9 Jan 2012
	12:49:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Miroslav Rezanina <mrezanin@redhat.com>
Date: Mon, 9 Jan 2012 12:49:05 +0000
In-Reply-To: <8edf9020-ff8c-4e52-90b1-366d5b723164@zmail13.collab.prod.int.phx2.redhat.com>
References: <8edf9020-ff8c-4e52-90b1-366d5b723164@zmail13.collab.prod.int.phx2.redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326113345.17210.83.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenstat: Correct copy of network device name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 11:44 +0000, Miroslav Rezanina wrote:
> When xenstat library parse /proc/net/dev, it uses strpbrk function to get pointer
> to device name. However, it miss capital letters in the array of valid characters
> so it get incorrect name in case device name starts with capital letters or even
> segfault if it contains only capital letters.
> 
> This patch adds missing characters to strpbrk call.

Presumably if some other characters in the name it will still segfault?
Can we handle that too?


> 
> Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
> 
> diff -r 4086e4811547 tools/xenstat/libxenstat/src/xenstat_linux.c
> --- a/tools/xenstat/libxenstat/src/xenstat_linux.c	Thu Jan 05 17:25:23 2012 +0000
> +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c	Mon Jan 09 12:40:05 2012 +0100
> @@ -222,7 +222,7 @@
>  				else
>  				/* There were errors when parsing this directly in RE. strpbrk() helps */
>  				if (iface != NULL)
> -					strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstvuwxyz0123456789"));
> +					strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"));
>  
>  				memset(tmp, 0, matches[i].rm_eo - matches[i].rm_so);
>  			}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:49:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12:49:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkEf3-0006HK-Os; Mon, 09 Jan 2012 12:49:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkEf2-0006HC-G4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:49:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326113345!2127443!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1554 invoked from network); 9 Jan 2012 12:49: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;
	9 Jan 2012 12:49:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9895923"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:49: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, 9 Jan 2012
	12:49:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Miroslav Rezanina <mrezanin@redhat.com>
Date: Mon, 9 Jan 2012 12:49:05 +0000
In-Reply-To: <8edf9020-ff8c-4e52-90b1-366d5b723164@zmail13.collab.prod.int.phx2.redhat.com>
References: <8edf9020-ff8c-4e52-90b1-366d5b723164@zmail13.collab.prod.int.phx2.redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326113345.17210.83.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenstat: Correct copy of network device name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 11:44 +0000, Miroslav Rezanina wrote:
> When xenstat library parse /proc/net/dev, it uses strpbrk function to get pointer
> to device name. However, it miss capital letters in the array of valid characters
> so it get incorrect name in case device name starts with capital letters or even
> segfault if it contains only capital letters.
> 
> This patch adds missing characters to strpbrk call.

Presumably if some other characters in the name it will still segfault?
Can we handle that too?


> 
> Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
> 
> diff -r 4086e4811547 tools/xenstat/libxenstat/src/xenstat_linux.c
> --- a/tools/xenstat/libxenstat/src/xenstat_linux.c	Thu Jan 05 17:25:23 2012 +0000
> +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c	Mon Jan 09 12:40:05 2012 +0100
> @@ -222,7 +222,7 @@
>  				else
>  				/* There were errors when parsing this directly in RE. strpbrk() helps */
>  				if (iface != NULL)
> -					strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstvuwxyz0123456789"));
> +					strcpy(iface, strpbrk(tmp, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"));
>  
>  				memset(tmp, 0, matches[i].rm_eo - matches[i].rm_so);
>  			}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:57:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12: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 1RkEmg-0006RD-ND; Mon, 09 Jan 2012 12:57: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 1RkEmf-0006R6-95
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:57:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326113817!8332932!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 20013 invoked from network); 9 Jan 2012 12:56:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 12:56:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 12:56:57 +0000
Message-Id: <4F0AF227020000780006B2E2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 12:56:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
	<CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@mail.gmail.com>
	<4F0AD93B020000780006B281@nat28.tlf.novell.com>
	<CAPLaKK4xWb_isLv01GddWs1mdv7G4PP49b6Pz3jNrFAQo8EDDQ@mail.gmail.com>
In-Reply-To: <CAPLaKK4xWb_isLv01GddWs1mdv7G4PP49b6Pz3jNrFAQo8EDDQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDA5LjAxLjEyIGF0IDEyOjQwLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiAyMDEyLzEvOSBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5j
b20+Ogo+Pj4+PiBPbiAwOS4wMS4xMiBhdCAxMjowNiwgUm9nZXIgUGF1IE1vbm7DqTxyb2dlci5w
YXVAZW50ZWwudXBjLmVkdT4gd3JvdGU6Cj4+PiAyMDEyLzEvOSBKYW4gQmV1bGljaCA8SkJldWxp
Y2hAc3VzZS5jb20+Ogo+Pj4+Pj4+IE9uIDA3LjAxLjEyIGF0IDA0OjIwLCBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PiB3cm90ZToKPj4+Pj4gIyBIRyBjaGFuZ2VzZXQg
cGF0Y2gKPj4+Pj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5l
ZHU+Cj4+Pj4+ICMgRGF0ZSAxMzI1OTA2MjMwIC0zNjAwCj4+Pj4+ICMgTm9kZSBJRCBlMTJlYzEw
NzE0MTBjOTQ2MzY3Y2IwNTA4Y2YyMThhMGMzYjU5NmNhCj4+Pj4+ICMgUGFyZW50ICA0MDg2ZTQ4
MTE1NDdkZGZmYjlhNTNmYmYyZWZiNmMyZmE0MzZiNzBhCj4+Pj4+IGJ1aWxkOiBhZGQgYXV0b2Nv
bmYgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCj4+Pj4+Cj4+Pj4+IEFk
ZGVkIGF1dG90b29scyBtYWdpYyB0byByZXBsYWNlIGN1c3RvbSBjaGVjayBzY3JpcHRzLiBUaGUg
cHJldmlvdXMKPj4+Pj4gY2hlY2tzIGhhdmUgYmVlbiBwb3J0ZWQgdG8gYXV0b2NvbmYsIGFuZCBz
b21lIGFkZGl0aW9uYWwgb25lcyBoYXZlCj4+Pj4+IGJlZW4gYWRkZWQgKHBsdXMgdGhlIHN1Z2dl
c3Rpb25zIGZyb20gcnVubmluZyBhdXRvc2NhbikuIFR3byBmaWxlcyBhcmUKPj4+Pj4gY3JlYXRl
ZCBhcyBhIHJlc3VsdCBmcm9tIGV4ZWN1dGluZyBjb25maWd1cmUgc2NyaXB0LAo+Pj4+PiBjb25m
aWcvQXV0b2NvbmYubWsgYW5kIGNvbmZpZy5oLgo+Pj4+Pgo+Pj4+PiBBdXRvY29uZi5tayBpcyBp
bmNsdWRlZCBieSBDb25maWcubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQo+Pj4+PiBvcHRp
b25zIHByZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBh
c3NpbmcKPj4+Pj4gcGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMg
d2hlbiBleGVjdXRpbmcgY29uZmlndXJlCj4+Pj4+IHNjcmlwdC4KPj4+Pj4KPj4+Pj4gY29uZmln
LmggaXMgc3RpbGwgbm90IHVzZWQgYW55d2hlcmUsIGFuZCBpcyBhdXRvbWF0aWNhbGx5IGNyZWF0
ZWQgYnkKPj4+Pj4gYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1pZ2ggY2hhbmdlIHdoZW4gd2Ug
c3RhcnQgdG8gaW5jbHVkZSB0aGlzCj4+Pj4+IGZpbGUuCj4+Pj4+Cj4+Pj4+IEp1c3QgYSBmaXJz
dCByZWxlYXNlLCBhbmQgc2luY2UgSWl0J3MgbXkgZmlyc3QgYXV0b2NvbmYgc2NyaXB0IEkgZ3Vl
c3MKPj4+Pj4gdGhlcmUgd2lsbCBiZSBtYW55IHRoaW5ncyB0byBwb2xpc2ggaGVyZS4uLiBQbGVh
c2UgcmV2aWV3IGFuZCBjb21tZW50Lgo+Pj4+Pgo+Pj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQ
YXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pj4+Pgo+Pj4+PiBkaWZmIC1yIDQw
ODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgQ29uZmlnLm1rCj4+Pj4+IC0tLSBhL0NvbmZpZy5t
ayAgICAgICBUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4+Pj4gKysrIGIvQ29uZmln
Lm1rICAgICAgIFNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+Pj4+PiBAQCAtOSw4ICs5
LDYgQEAgcmVhbHBhdGggPSAkKHdpbGRjYXJkICQoZm9yZWFjaCBmaWxlLCQoMQo+Pj4+Pgo+Pj4+
PiAgLWluY2x1ZGUgJChYRU5fUk9PVCkvLmNvbmZpZwo+Pj4+Pgo+Pj4+PiAtIyBBIGRlYnVnIGJ1
aWxkIG9mIFhlbiBhbmQgdG9vbHM/Cj4+Pj4+IC1kZWJ1ZyA/PSB5Cj4+Pj4KPj4+PiBJIHRoaW5r
IHRoaXMgc2hvdWxkIGJlIGtlcHQgaGVyZSAocG9zc2libHkgb3ZlcnJpZGUtYWJsZSBieSB0aGUg
YXV0b2NvbmYKPj4+PiBkZXRlcm1pbmVkIHNldHRpbmcsIGkuZS4gaXQgbWF5IG5lZWQgbW92aW5n
IHBhc3QgdGhlIGluY2x1c2lvbiBiZWxvdykuCj4+Pj4KPj4+Pj4KPj4+Pj4gIFhFTl9DT01QSUxF
X0FSQ0ggICAgPz0gJChzaGVsbCB1bmFtZSAtbSB8IHNlZCAtZSBzL2kuODYveDg2XzMyLyBcCj4+
Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgLWUgcy9pODZwYy94ODZfMzIvIC1lIHMvYW1k
NjQveDg2XzY0LykKPj4+Pj4gQEAgLTQzLDYgKzQxLDcgQEAgZW5kaWYKPj4+Pj4KPj4+Pj4gIGlu
Y2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnLyQoWEVOX09TKS5tawo+Pj4+PiAgaW5jbHVkZSAkKFhF
Tl9ST09UKS9jb25maWcvJChYRU5fVEFSR0VUX0FSQ0gpLm1rCj4+Pj4+ICtpbmNsdWRlICQoWEVO
X1JPT1QpL2NvbmZpZy9BdXRvY29uZi5tawo+Pj4+Cj4+Pj4gQW5kIEkgd291bGQgcmVhbGx5IGxp
a2UgdG8gYXZvaWQgaGF2aW5nIGh5cGVydmlzb3IgKGFuZCBwZXJoYXBzCj4+Pj4gYWxzbyBzdHVi
ZG9tKSBidWlsZHMgdG8gcmVxdWlyZSBydW5uaW5nIHRoZSBhdXRvY29uZmlnIHRoaW5nCj4+Pj4g
Zmlyc3QgLSB0aGlzIG91Z2h0IHRvIGJlIGxpbWl0ZWQgdG8gdGhlIHRvb2xzIChhcyB3ZXJlIHRo
ZSBjaGVjawo+Pj4+IHNjcmlwdHMpLgo+Pj4KPj4+Cj4+PiBEb2luZyBzb21ldGhpbmcgbGlrZSB0
aGlzIGlzIHByb2JhYmx5IG1vcmUgc3VpdGFibGU6Cj4+Pgo+Pj4gZGlmZiAtciBlMTJlYzEwNzE0
MTAgdG9vbHMvTWFrZWZpbGUKPj4+IC0tLSBhL3Rvb2xzL01ha2VmaWxlICBTYXQgSmFuIDA3IDA0
OjE3OjEwIDIwMTIgKzAxMDAKPj4+ICsrKyBiL3Rvb2xzL01ha2VmaWxlICBTYXQgSmFuIDA3IDA2
OjQ2OjU1IDIwMTIgKzAxMDAKPj4+IEBAIC0xLDQgKzEsNSBAQAo+Pj4gIFhFTl9ST09UID0gJChD
VVJESVIpLy4uCj4+PiAraW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvQXV0b2NvbmYubWsKPj4+
ICBpbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCj4+Pgo+Pj4gIGlmbmVxICgkKENP
TkZJR19TWVNURU1fTElCQUlPKSx5KQo+Pgo+PiBZZXMsIHBsZWFzZS4gT2YgY291cnNlLCB0aGUg
cXVlc3Rpb24gdGhlbiBpcyB3aGV0aGVyIGl0IHNob3VsZG4ndAo+PiByZWFsbHkgYmUgdG9vbHMv
QXV0b2NvbmYubWsgKGFuZCB3aGV0aGVyIHBlcmhhcHMgdGhlIHdob2xlIHNldAo+PiBvZiBuZXcg
ZmlsZXMgc2hvdWxkIGFsc28gYmUgcm9vdGVkIHVuZGVyIHRvb2xzLyByYXRoZXIgdGhhbiBhdAo+
PiAkKFhFTl9ST09UKS8pLgo+IAo+IEkgdGhpbmsgaXQncyBtb3JlIGNvbW1vbiB0byBmaW5kIGEg
Y29uZmlndXJlIHNjcmlwdCBpbiB0aGUgcm9vdCBmb2xkZXIKPiBvZiB0aGUgcGFja2FnZSByYXRo
ZXIgdGhhbiBoYXZpbmcgdG8gc2VhcmNoIGZvciBpdCB1bmRlciBzb21lIGZvbGRlci4KPiBBbHNv
IEkgcHJlZmVyIHRvIHJlbmFtZSBjb25maWcvQXV0b2NvbmYubWsgdG8gY29uZmlnL1Rvb2xzLm1r
IHRoYW4gdG8KPiBwbGFjZSBpdCBpbnNpZGUgdG9vbHMvLgoKSGF2aW5nIGEgLi9jb25maWd1cmUg
YXQgdGhlIHJvb3QgaXMgY2VydGFpbmx5IGZpbmUsIGp1c3QgdGhhdCBpdCBzaG91bGQKdGhlbiBi
ZSBhIHNpbXBsZSB3cmFwcGVyIGFyb3VuZCB0aGUgaW5kaXZpZHVhbCBzdWJ0cmVlIHNjcmlwdHMg
KHdoZXJlCnRoZXkgZXhpc3QpLCBqdXN0IGxpa2UgdGhlIHRvcCBsZXZlbCBNYWtlZmlsZSBqdXN0
IGNvbnRyb2xzIHRoZSBpbnZvY2F0aW9uCm9mIHN1YnRyZWUgbWFrZXMuCgpVbmxlc3MgdGhlcmUg
aXMgcmVhbGx5IG1lYW5pbmdmdWwgc2hhcmluZyBvZiBjb25maWd1cmUgZGV0ZXJtaW5lZApkYXRh
IGJldHdlZW4gc3VidHJlZXMsIGFsbCBvZiB0aGVpciBzdWJ0cmVlIHNwZWNpZmljIGJpdHMgc2hv
dWxkCnJlc2lkZSBpbiB0aGF0IHN1YnRyZWUgaW1vLgoKSmFuCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 09 12:57:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 12: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 1RkEmg-0006RD-ND; Mon, 09 Jan 2012 12:57: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 1RkEmf-0006R6-95
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 12:57:05 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326113817!8332932!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 20013 invoked from network); 9 Jan 2012 12:56:58 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 12:56:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 12:56:57 +0000
Message-Id: <4F0AF227020000780006B2E2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 12:56:55 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<4F0AC54E020000780006B1F3@nat28.tlf.novell.com>
	<CAPLaKK67W99pVfH6k3HFoEBibTy7TM6v9fBhsSge8K2Zb32WOQ@mail.gmail.com>
	<4F0AD93B020000780006B281@nat28.tlf.novell.com>
	<CAPLaKK4xWb_isLv01GddWs1mdv7G4PP49b6Pz3jNrFAQo8EDDQ@mail.gmail.com>
In-Reply-To: <CAPLaKK4xWb_isLv01GddWs1mdv7G4PP49b6Pz3jNrFAQo8EDDQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDA5LjAxLjEyIGF0IDEyOjQwLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiAyMDEyLzEvOSBKYW4gQmV1bGljaCA8SkJldWxpY2hAc3VzZS5j
b20+Ogo+Pj4+PiBPbiAwOS4wMS4xMiBhdCAxMjowNiwgUm9nZXIgUGF1IE1vbm7DqTxyb2dlci5w
YXVAZW50ZWwudXBjLmVkdT4gd3JvdGU6Cj4+PiAyMDEyLzEvOSBKYW4gQmV1bGljaCA8SkJldWxp
Y2hAc3VzZS5jb20+Ogo+Pj4+Pj4+IE9uIDA3LjAxLjEyIGF0IDA0OjIwLCBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PiB3cm90ZToKPj4+Pj4gIyBIRyBjaGFuZ2VzZXQg
cGF0Y2gKPj4+Pj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5l
ZHU+Cj4+Pj4+ICMgRGF0ZSAxMzI1OTA2MjMwIC0zNjAwCj4+Pj4+ICMgTm9kZSBJRCBlMTJlYzEw
NzE0MTBjOTQ2MzY3Y2IwNTA4Y2YyMThhMGMzYjU5NmNhCj4+Pj4+ICMgUGFyZW50ICA0MDg2ZTQ4
MTE1NDdkZGZmYjlhNTNmYmYyZWZiNmMyZmE0MzZiNzBhCj4+Pj4+IGJ1aWxkOiBhZGQgYXV0b2Nv
bmYgdG8gcmVwbGFjZSBjdXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCj4+Pj4+Cj4+Pj4+IEFk
ZGVkIGF1dG90b29scyBtYWdpYyB0byByZXBsYWNlIGN1c3RvbSBjaGVjayBzY3JpcHRzLiBUaGUg
cHJldmlvdXMKPj4+Pj4gY2hlY2tzIGhhdmUgYmVlbiBwb3J0ZWQgdG8gYXV0b2NvbmYsIGFuZCBz
b21lIGFkZGl0aW9uYWwgb25lcyBoYXZlCj4+Pj4+IGJlZW4gYWRkZWQgKHBsdXMgdGhlIHN1Z2dl
c3Rpb25zIGZyb20gcnVubmluZyBhdXRvc2NhbikuIFR3byBmaWxlcyBhcmUKPj4+Pj4gY3JlYXRl
ZCBhcyBhIHJlc3VsdCBmcm9tIGV4ZWN1dGluZyBjb25maWd1cmUgc2NyaXB0LAo+Pj4+PiBjb25m
aWcvQXV0b2NvbmYubWsgYW5kIGNvbmZpZy5oLgo+Pj4+Pgo+Pj4+PiBBdXRvY29uZi5tayBpcyBp
bmNsdWRlZCBieSBDb25maWcubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQo+Pj4+PiBvcHRp
b25zIHByZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBh
c3NpbmcKPj4+Pj4gcGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMg
d2hlbiBleGVjdXRpbmcgY29uZmlndXJlCj4+Pj4+IHNjcmlwdC4KPj4+Pj4KPj4+Pj4gY29uZmln
LmggaXMgc3RpbGwgbm90IHVzZWQgYW55d2hlcmUsIGFuZCBpcyBhdXRvbWF0aWNhbGx5IGNyZWF0
ZWQgYnkKPj4+Pj4gYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1pZ2ggY2hhbmdlIHdoZW4gd2Ug
c3RhcnQgdG8gaW5jbHVkZSB0aGlzCj4+Pj4+IGZpbGUuCj4+Pj4+Cj4+Pj4+IEp1c3QgYSBmaXJz
dCByZWxlYXNlLCBhbmQgc2luY2UgSWl0J3MgbXkgZmlyc3QgYXV0b2NvbmYgc2NyaXB0IEkgZ3Vl
c3MKPj4+Pj4gdGhlcmUgd2lsbCBiZSBtYW55IHRoaW5ncyB0byBwb2xpc2ggaGVyZS4uLiBQbGVh
c2UgcmV2aWV3IGFuZCBjb21tZW50Lgo+Pj4+Pgo+Pj4+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQ
YXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pj4+Pgo+Pj4+PiBkaWZmIC1yIDQw
ODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgQ29uZmlnLm1rCj4+Pj4+IC0tLSBhL0NvbmZpZy5t
ayAgICAgICBUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4+Pj4gKysrIGIvQ29uZmln
Lm1rICAgICAgIFNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+Pj4+PiBAQCAtOSw4ICs5
LDYgQEAgcmVhbHBhdGggPSAkKHdpbGRjYXJkICQoZm9yZWFjaCBmaWxlLCQoMQo+Pj4+Pgo+Pj4+
PiAgLWluY2x1ZGUgJChYRU5fUk9PVCkvLmNvbmZpZwo+Pj4+Pgo+Pj4+PiAtIyBBIGRlYnVnIGJ1
aWxkIG9mIFhlbiBhbmQgdG9vbHM/Cj4+Pj4+IC1kZWJ1ZyA/PSB5Cj4+Pj4KPj4+PiBJIHRoaW5r
IHRoaXMgc2hvdWxkIGJlIGtlcHQgaGVyZSAocG9zc2libHkgb3ZlcnJpZGUtYWJsZSBieSB0aGUg
YXV0b2NvbmYKPj4+PiBkZXRlcm1pbmVkIHNldHRpbmcsIGkuZS4gaXQgbWF5IG5lZWQgbW92aW5n
IHBhc3QgdGhlIGluY2x1c2lvbiBiZWxvdykuCj4+Pj4KPj4+Pj4KPj4+Pj4gIFhFTl9DT01QSUxF
X0FSQ0ggICAgPz0gJChzaGVsbCB1bmFtZSAtbSB8IHNlZCAtZSBzL2kuODYveDg2XzMyLyBcCj4+
Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgLWUgcy9pODZwYy94ODZfMzIvIC1lIHMvYW1k
NjQveDg2XzY0LykKPj4+Pj4gQEAgLTQzLDYgKzQxLDcgQEAgZW5kaWYKPj4+Pj4KPj4+Pj4gIGlu
Y2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnLyQoWEVOX09TKS5tawo+Pj4+PiAgaW5jbHVkZSAkKFhF
Tl9ST09UKS9jb25maWcvJChYRU5fVEFSR0VUX0FSQ0gpLm1rCj4+Pj4+ICtpbmNsdWRlICQoWEVO
X1JPT1QpL2NvbmZpZy9BdXRvY29uZi5tawo+Pj4+Cj4+Pj4gQW5kIEkgd291bGQgcmVhbGx5IGxp
a2UgdG8gYXZvaWQgaGF2aW5nIGh5cGVydmlzb3IgKGFuZCBwZXJoYXBzCj4+Pj4gYWxzbyBzdHVi
ZG9tKSBidWlsZHMgdG8gcmVxdWlyZSBydW5uaW5nIHRoZSBhdXRvY29uZmlnIHRoaW5nCj4+Pj4g
Zmlyc3QgLSB0aGlzIG91Z2h0IHRvIGJlIGxpbWl0ZWQgdG8gdGhlIHRvb2xzIChhcyB3ZXJlIHRo
ZSBjaGVjawo+Pj4+IHNjcmlwdHMpLgo+Pj4KPj4+Cj4+PiBEb2luZyBzb21ldGhpbmcgbGlrZSB0
aGlzIGlzIHByb2JhYmx5IG1vcmUgc3VpdGFibGU6Cj4+Pgo+Pj4gZGlmZiAtciBlMTJlYzEwNzE0
MTAgdG9vbHMvTWFrZWZpbGUKPj4+IC0tLSBhL3Rvb2xzL01ha2VmaWxlICBTYXQgSmFuIDA3IDA0
OjE3OjEwIDIwMTIgKzAxMDAKPj4+ICsrKyBiL3Rvb2xzL01ha2VmaWxlICBTYXQgSmFuIDA3IDA2
OjQ2OjU1IDIwMTIgKzAxMDAKPj4+IEBAIC0xLDQgKzEsNSBAQAo+Pj4gIFhFTl9ST09UID0gJChD
VVJESVIpLy4uCj4+PiAraW5jbHVkZSAkKFhFTl9ST09UKS9jb25maWcvQXV0b2NvbmYubWsKPj4+
ICBpbmNsdWRlICQoWEVOX1JPT1QpL3Rvb2xzL1J1bGVzLm1rCj4+Pgo+Pj4gIGlmbmVxICgkKENP
TkZJR19TWVNURU1fTElCQUlPKSx5KQo+Pgo+PiBZZXMsIHBsZWFzZS4gT2YgY291cnNlLCB0aGUg
cXVlc3Rpb24gdGhlbiBpcyB3aGV0aGVyIGl0IHNob3VsZG4ndAo+PiByZWFsbHkgYmUgdG9vbHMv
QXV0b2NvbmYubWsgKGFuZCB3aGV0aGVyIHBlcmhhcHMgdGhlIHdob2xlIHNldAo+PiBvZiBuZXcg
ZmlsZXMgc2hvdWxkIGFsc28gYmUgcm9vdGVkIHVuZGVyIHRvb2xzLyByYXRoZXIgdGhhbiBhdAo+
PiAkKFhFTl9ST09UKS8pLgo+IAo+IEkgdGhpbmsgaXQncyBtb3JlIGNvbW1vbiB0byBmaW5kIGEg
Y29uZmlndXJlIHNjcmlwdCBpbiB0aGUgcm9vdCBmb2xkZXIKPiBvZiB0aGUgcGFja2FnZSByYXRo
ZXIgdGhhbiBoYXZpbmcgdG8gc2VhcmNoIGZvciBpdCB1bmRlciBzb21lIGZvbGRlci4KPiBBbHNv
IEkgcHJlZmVyIHRvIHJlbmFtZSBjb25maWcvQXV0b2NvbmYubWsgdG8gY29uZmlnL1Rvb2xzLm1r
IHRoYW4gdG8KPiBwbGFjZSBpdCBpbnNpZGUgdG9vbHMvLgoKSGF2aW5nIGEgLi9jb25maWd1cmUg
YXQgdGhlIHJvb3QgaXMgY2VydGFpbmx5IGZpbmUsIGp1c3QgdGhhdCBpdCBzaG91bGQKdGhlbiBi
ZSBhIHNpbXBsZSB3cmFwcGVyIGFyb3VuZCB0aGUgaW5kaXZpZHVhbCBzdWJ0cmVlIHNjcmlwdHMg
KHdoZXJlCnRoZXkgZXhpc3QpLCBqdXN0IGxpa2UgdGhlIHRvcCBsZXZlbCBNYWtlZmlsZSBqdXN0
IGNvbnRyb2xzIHRoZSBpbnZvY2F0aW9uCm9mIHN1YnRyZWUgbWFrZXMuCgpVbmxlc3MgdGhlcmUg
aXMgcmVhbGx5IG1lYW5pbmdmdWwgc2hhcmluZyBvZiBjb25maWd1cmUgZGV0ZXJtaW5lZApkYXRh
IGJldHdlZW4gc3VidHJlZXMsIGFsbCBvZiB0aGVpciBzdWJ0cmVlIHNwZWNpZmljIGJpdHMgc2hv
dWxkCnJlc2lkZSBpbiB0aGF0IHN1YnRyZWUgaW1vLgoKSmFuCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:11:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkF08-0006h4-Bl; Mon, 09 Jan 2012 13:11:00 +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 1RkF06-0006gz-QJ
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:10:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326114650!2390536!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 15391 invoked from network); 9 Jan 2012 13:10:51 -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; 9 Jan 2012 13:10:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 13:10:50 +0000
Message-Id: <4F0AF568020000780006B30C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 13:10:48 +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="=__Part82ACCA48.0__="
Subject: [Xen-devel] Ping: [PATCH] PCI: shrink pci_dev_info's
 is_extfn/is_virtfn members
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part82ACCA48.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

They are used as boolean flags only, so convert them accordingly
(shrinking the structure size by 8 bytes).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA
         if ( copy_from_guest(&manage_pci_ext, arg, 1) !=3D 0 )
             break;
=20
-        pdev_info.is_extfn =3D manage_pci_ext.is_extfn;
-        pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;
+        pdev_info.is_extfn =3D !!manage_pci_ext.is_extfn;
+        pdev_info.is_virtfn =3D !!manage_pci_ext.is_virtfn;
         pdev_info.physfn.bus =3D manage_pci_ext.physfn.bus;
         pdev_info.physfn.devfn =3D manage_pci_ext.physfn.devfn;
         ret =3D pci_add_device(0, manage_pci_ext.bus,
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -33,8 +33,8 @@
 #define MAX_MSIX_TABLE_ENTRIES  2048
 #define MAX_MSIX_TABLE_PAGES    8
 struct pci_dev_info {
-    unsigned is_extfn;
-    unsigned is_virtfn;
+    bool_t is_extfn;
+    bool_t is_virtfn;
     struct {
         u8 bus;
         u8 devfn;




--=__Part82ACCA48.0__=
Content-Type: text/plain; name="squeeze-pci_dev_info.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="squeeze-pci_dev_info.patch"

PCI: shrink pci_dev_info's is_extfn/is_virtfn members=0A=0AThey are used =
as boolean flags only, so convert them accordingly=0A(shrinking the =
structure size by 8 bytes).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.=
com>=0A=0A--- a/xen/arch/ia64/xen/hypercall.c=0A+++ b/xen/arch/ia64/xen/hyp=
ercall.c=0A@@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA=0A =
        if ( copy_from_guest(&manage_pci_ext, arg, 1) !=3D 0 )=0A          =
   break;=0A =0A-        pdev_info.is_extfn =3D manage_pci_ext.is_extfn;=0A=
-        pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;=0A+        =
pdev_info.is_extfn =3D !!manage_pci_ext.is_extfn;=0A+        pdev_info.is_v=
irtfn =3D !!manage_pci_ext.is_virtfn;=0A         pdev_info.physfn.bus =3D =
manage_pci_ext.physfn.bus;=0A         pdev_info.physfn.devfn =3D manage_pci=
_ext.physfn.devfn;=0A         ret =3D pci_add_device(0, manage_pci_ext.bus,=
=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@@ -33,8 =
+33,8 @@=0A #define MAX_MSIX_TABLE_ENTRIES  2048=0A #define MAX_MSIX_TABLE_=
PAGES    8=0A struct pci_dev_info {=0A-    unsigned is_extfn;=0A-    =
unsigned is_virtfn;=0A+    bool_t is_extfn;=0A+    bool_t is_virtfn;=0A    =
 struct {=0A         u8 bus;=0A         u8 devfn;=0A
--=__Part82ACCA48.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

--=__Part82ACCA48.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:11:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:11:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkF08-0006h4-Bl; Mon, 09 Jan 2012 13:11:00 +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 1RkF06-0006gz-QJ
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:10:59 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326114650!2390536!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 15391 invoked from network); 9 Jan 2012 13:10:51 -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; 9 Jan 2012 13:10:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 13:10:50 +0000
Message-Id: <4F0AF568020000780006B30C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 13:10:48 +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="=__Part82ACCA48.0__="
Subject: [Xen-devel] Ping: [PATCH] PCI: shrink pci_dev_info's
 is_extfn/is_virtfn members
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part82ACCA48.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

They are used as boolean flags only, so convert them accordingly
(shrinking the structure size by 8 bytes).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA
         if ( copy_from_guest(&manage_pci_ext, arg, 1) !=3D 0 )
             break;
=20
-        pdev_info.is_extfn =3D manage_pci_ext.is_extfn;
-        pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;
+        pdev_info.is_extfn =3D !!manage_pci_ext.is_extfn;
+        pdev_info.is_virtfn =3D !!manage_pci_ext.is_virtfn;
         pdev_info.physfn.bus =3D manage_pci_ext.physfn.bus;
         pdev_info.physfn.devfn =3D manage_pci_ext.physfn.devfn;
         ret =3D pci_add_device(0, manage_pci_ext.bus,
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -33,8 +33,8 @@
 #define MAX_MSIX_TABLE_ENTRIES  2048
 #define MAX_MSIX_TABLE_PAGES    8
 struct pci_dev_info {
-    unsigned is_extfn;
-    unsigned is_virtfn;
+    bool_t is_extfn;
+    bool_t is_virtfn;
     struct {
         u8 bus;
         u8 devfn;




--=__Part82ACCA48.0__=
Content-Type: text/plain; name="squeeze-pci_dev_info.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="squeeze-pci_dev_info.patch"

PCI: shrink pci_dev_info's is_extfn/is_virtfn members=0A=0AThey are used =
as boolean flags only, so convert them accordingly=0A(shrinking the =
structure size by 8 bytes).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.=
com>=0A=0A--- a/xen/arch/ia64/xen/hypercall.c=0A+++ b/xen/arch/ia64/xen/hyp=
ercall.c=0A@@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA=0A =
        if ( copy_from_guest(&manage_pci_ext, arg, 1) !=3D 0 )=0A          =
   break;=0A =0A-        pdev_info.is_extfn =3D manage_pci_ext.is_extfn;=0A=
-        pdev_info.is_virtfn =3D manage_pci_ext.is_virtfn;=0A+        =
pdev_info.is_extfn =3D !!manage_pci_ext.is_extfn;=0A+        pdev_info.is_v=
irtfn =3D !!manage_pci_ext.is_virtfn;=0A         pdev_info.physfn.bus =3D =
manage_pci_ext.physfn.bus;=0A         pdev_info.physfn.devfn =3D manage_pci=
_ext.physfn.devfn;=0A         ret =3D pci_add_device(0, manage_pci_ext.bus,=
=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@@ -33,8 =
+33,8 @@=0A #define MAX_MSIX_TABLE_ENTRIES  2048=0A #define MAX_MSIX_TABLE_=
PAGES    8=0A struct pci_dev_info {=0A-    unsigned is_extfn;=0A-    =
unsigned is_virtfn;=0A+    bool_t is_extfn;=0A+    bool_t is_virtfn;=0A    =
 struct {=0A         u8 bus;=0A         u8 devfn;=0A
--=__Part82ACCA48.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

--=__Part82ACCA48.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:11:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13: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 1RkF0H-0006hY-PV; Mon, 09 Jan 2012 13:11:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RkF0G-0006hD-RA
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:11:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326114660!1378772!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 3483 invoked from network); 9 Jan 2012 13:11:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 13:11:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 13:11:00 +0000
Message-Id: <4F0AF572020000780006B310@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 13:10: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="=__PartB896F072.0__="
Subject: [Xen-devel] Ping: [PATCH] PCI: properly abstract out
 per-architecture extensions to struct pci_dev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartB896F072.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

x86's used_vectors member was both misplaced (in struct pci_dev_info,
which acts as a hypercall input data passing container only) and
improperly abstracted (requiring a CONFIG_X86 conditional in a generic
header).

The adjustment requires hiding several more lines in IA64's pci.h, but
as a benefit this allows removing one of the "null" headers.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1877,7 +1877,7 @@ int map_domain_pirq(
         if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV
              && !desc->arch.used_vectors )
         {
-            desc->arch.used_vectors =3D &pdev->info.used_vectors;
+            desc->arch.used_vectors =3D &pdev->arch.used_vectors;
             if ( desc->arch.vector !=3D IRQ_VECTOR_UNASSIGNED )
             {
                 int vector =3D desc->arch.vector;
--- a/xen/include/asm-ia64/linux-null/asm-generic/pci-dma-compat.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is intentionally left empty. */
--- a/xen/include/asm-ia64/linux-xen/asm/pci.h
+++ b/xen/include/asm-ia64/linux-xen/asm/pci.h
@@ -28,6 +28,10 @@ void pcibios_config_init(void);
=20
 struct pci_dev;
=20
+#ifdef XEN
+struct arch_pci_dev {};
+#endif
+
 /*
  * PCI_DMA_BUS_IS_PHYS should be set to 1 if there is _necessarily_ a =
direct correspondence
  * between device bus addresses and CPU physical addresses.  Platforms =
with a hardware I/O
@@ -43,6 +47,7 @@ struct pci_dev;
 extern unsigned long ia64_max_iommu_merge_mask;
 #define PCI_DMA_BUS_IS_PHYS	(ia64_max_iommu_merge_mask =3D=3D ~0UL)
=20
+#ifndef XEN
 static inline void
 pcibios_set_master (struct pci_dev *dev)
 {
@@ -110,7 +115,6 @@ extern int pci_mmap_page_range (struct p
 #define HAVE_PCI_LEGACY
 extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
 				      struct vm_area_struct *vma);
-#ifndef XEN
 extern ssize_t pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t =
off,
 				  size_t count);
 extern ssize_t pci_write_legacy_io(struct kobject *kobj, char *buf, =
loff_t off,
@@ -144,6 +148,7 @@ struct pci_controller {
 #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)=

 #define pci_domain_nr(busdev)    (PCI_CONTROLLER(busdev)->segment)
=20
+#ifndef XEN
 extern struct pci_ops pci_root_ops;
=20
 static inline int pci_proc_domain(struct pci_bus *bus)
@@ -161,7 +166,6 @@ extern void pcibios_resource_to_bus(stru
 extern void pcibios_bus_to_resource(struct pci_dev *dev,
 		struct resource *res, struct pci_bus_region *region);
=20
-#ifndef XEN
 static inline struct resource *
 pcibios_select_root(struct pci_dev *pdev, struct resource *res)
 {
--- /dev/null
+++ b/xen/include/asm-x86/pci.h
@@ -0,0 +1,8 @@
+#ifndef __X86_PCI_H__
+#define __X86_PCI_H__
+
+struct arch_pci_dev {
+    vmask_t used_vectors;
+};
+
+#endif /* __X86_PCI_H__ */
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -12,6 +12,7 @@
 #include <xen/list.h>
 #include <xen/spinlock.h>
 #include <xen/irq.h>
+#include <asm/pci.h>
=20
 /*
  * The PCI interface treats multi-function devices as independent
@@ -39,9 +40,6 @@ struct pci_dev_info {
         u8 bus;
         u8 devfn;
     } physfn;
-#ifdef CONFIG_X86
-    vmask_t used_vectors;
-#endif
 };
=20
 struct pci_dev {
@@ -62,6 +60,7 @@ struct pci_dev {
     const u8 bus;
     const u8 devfn;
     struct pci_dev_info info;
+    struct arch_pci_dev arch;
     u64 vf_rlen[6];
 };
=20




--=__PartB896F072.0__=
Content-Type: text/plain; name="arch-pci_dev.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arch-pci_dev.patch"

PCI: properly abstract out per-architecture extensions to struct pci_dev=0A=
=0Ax86's used_vectors member was both misplaced (in struct pci_dev_info,=0A=
which acts as a hypercall input data passing container only) and=0Aimproper=
ly abstracted (requiring a CONFIG_X86 conditional in a generic=0Aheader).=
=0A=0AThe adjustment requires hiding several more lines in IA64's pci.h, =
but=0Aas a benefit this allows removing one of the "null" headers.=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/irq.c=
=0A+++ b/xen/arch/x86/irq.c=0A@@ -1877,7 +1877,7 @@ int map_domain_pirq(=0A=
         if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV=0A       =
       && !desc->arch.used_vectors )=0A         {=0A-            desc->arch=
.used_vectors =3D &pdev->info.used_vectors;=0A+            desc->arch.used_=
vectors =3D &pdev->arch.used_vectors;=0A             if ( desc->arch.vector=
 !=3D IRQ_VECTOR_UNASSIGNED )=0A             {=0A                 int =
vector =3D desc->arch.vector;=0A--- a/xen/include/asm-ia64/linux-null/asm-g=
eneric/pci-dma-compat.h=0A+++ /dev/null=0A@@ -1 +0,0 @@=0A-/* This file is =
intentionally left empty. */=0A--- a/xen/include/asm-ia64/linux-xen/asm/pci=
.h=0A+++ b/xen/include/asm-ia64/linux-xen/asm/pci.h=0A@@ -28,6 +28,10 @@ =
void pcibios_config_init(void);=0A =0A struct pci_dev;=0A =0A+#ifdef =
XEN=0A+struct arch_pci_dev {};=0A+#endif=0A+=0A /*=0A  * PCI_DMA_BUS_IS_PHY=
S should be set to 1 if there is _necessarily_ a direct correspondence=0A  =
* between device bus addresses and CPU physical addresses.  Platforms with =
a hardware I/O=0A@@ -43,6 +47,7 @@ struct pci_dev;=0A extern unsigned long =
ia64_max_iommu_merge_mask;=0A #define PCI_DMA_BUS_IS_PHYS	(ia64_max_i=
ommu_merge_mask =3D=3D ~0UL)=0A =0A+#ifndef XEN=0A static inline void=0A =
pcibios_set_master (struct pci_dev *dev)=0A {=0A@@ -110,7 +115,6 @@ extern =
int pci_mmap_page_range (struct p=0A #define HAVE_PCI_LEGACY=0A extern int =
pci_mmap_legacy_page_range(struct pci_bus *bus,=0A 				=
      struct vm_area_struct *vma);=0A-#ifndef XEN=0A extern ssize_t =
pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t off,=0A 		=
		  size_t count);=0A extern ssize_t pci_write_legacy_io(stru=
ct kobject *kobj, char *buf, loff_t off,=0A@@ -144,6 +148,7 @@ struct =
pci_controller {=0A #define PCI_CONTROLLER(busdev) ((struct pci_controller =
*) busdev->sysdata)=0A #define pci_domain_nr(busdev)    (PCI_CONTROLLER(bus=
dev)->segment)=0A =0A+#ifndef XEN=0A extern struct pci_ops pci_root_ops;=0A=
 =0A static inline int pci_proc_domain(struct pci_bus *bus)=0A@@ -161,7 =
+166,6 @@ extern void pcibios_resource_to_bus(stru=0A extern void =
pcibios_bus_to_resource(struct pci_dev *dev,=0A 		struct =
resource *res, struct pci_bus_region *region);=0A =0A-#ifndef XEN=0A =
static inline struct resource *=0A pcibios_select_root(struct pci_dev =
*pdev, struct resource *res)=0A {=0A--- /dev/null=0A+++ b/xen/include/asm-x=
86/pci.h=0A@@ -0,0 +1,8 @@=0A+#ifndef __X86_PCI_H__=0A+#define __X86_PCI_H_=
_=0A+=0A+struct arch_pci_dev {=0A+    vmask_t used_vectors;=0A+};=0A+=0A+#e=
ndif /* __X86_PCI_H__ */=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/=
xen/pci.h=0A@@ -12,6 +12,7 @@=0A #include <xen/list.h>=0A #include =
<xen/spinlock.h>=0A #include <xen/irq.h>=0A+#include <asm/pci.h>=0A =0A =
/*=0A  * The PCI interface treats multi-function devices as independent=0A@=
@ -39,9 +40,6 @@ struct pci_dev_info {=0A         u8 bus;=0A         u8 =
devfn;=0A     } physfn;=0A-#ifdef CONFIG_X86=0A-    vmask_t used_vectors;=
=0A-#endif=0A };=0A =0A struct pci_dev {=0A@@ -62,6 +60,7 @@ struct =
pci_dev {=0A     const u8 bus;=0A     const u8 devfn;=0A     struct =
pci_dev_info info;=0A+    struct arch_pci_dev arch;=0A     u64 vf_rlen[6];=
=0A };=0A =0A
--=__PartB896F072.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

--=__PartB896F072.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:11:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13: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 1RkF0H-0006hY-PV; Mon, 09 Jan 2012 13:11:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RkF0G-0006hD-RA
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:11:09 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326114660!1378772!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 3483 invoked from network); 9 Jan 2012 13:11:01 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 13:11:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 13:11:00 +0000
Message-Id: <4F0AF572020000780006B310@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 13:10: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="=__PartB896F072.0__="
Subject: [Xen-devel] Ping: [PATCH] PCI: properly abstract out
 per-architecture extensions to struct pci_dev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartB896F072.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

x86's used_vectors member was both misplaced (in struct pci_dev_info,
which acts as a hypercall input data passing container only) and
improperly abstracted (requiring a CONFIG_X86 conditional in a generic
header).

The adjustment requires hiding several more lines in IA64's pci.h, but
as a benefit this allows removing one of the "null" headers.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1877,7 +1877,7 @@ int map_domain_pirq(
         if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV
              && !desc->arch.used_vectors )
         {
-            desc->arch.used_vectors =3D &pdev->info.used_vectors;
+            desc->arch.used_vectors =3D &pdev->arch.used_vectors;
             if ( desc->arch.vector !=3D IRQ_VECTOR_UNASSIGNED )
             {
                 int vector =3D desc->arch.vector;
--- a/xen/include/asm-ia64/linux-null/asm-generic/pci-dma-compat.h
+++ /dev/null
@@ -1 +0,0 @@
-/* This file is intentionally left empty. */
--- a/xen/include/asm-ia64/linux-xen/asm/pci.h
+++ b/xen/include/asm-ia64/linux-xen/asm/pci.h
@@ -28,6 +28,10 @@ void pcibios_config_init(void);
=20
 struct pci_dev;
=20
+#ifdef XEN
+struct arch_pci_dev {};
+#endif
+
 /*
  * PCI_DMA_BUS_IS_PHYS should be set to 1 if there is _necessarily_ a =
direct correspondence
  * between device bus addresses and CPU physical addresses.  Platforms =
with a hardware I/O
@@ -43,6 +47,7 @@ struct pci_dev;
 extern unsigned long ia64_max_iommu_merge_mask;
 #define PCI_DMA_BUS_IS_PHYS	(ia64_max_iommu_merge_mask =3D=3D ~0UL)
=20
+#ifndef XEN
 static inline void
 pcibios_set_master (struct pci_dev *dev)
 {
@@ -110,7 +115,6 @@ extern int pci_mmap_page_range (struct p
 #define HAVE_PCI_LEGACY
 extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
 				      struct vm_area_struct *vma);
-#ifndef XEN
 extern ssize_t pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t =
off,
 				  size_t count);
 extern ssize_t pci_write_legacy_io(struct kobject *kobj, char *buf, =
loff_t off,
@@ -144,6 +148,7 @@ struct pci_controller {
 #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)=

 #define pci_domain_nr(busdev)    (PCI_CONTROLLER(busdev)->segment)
=20
+#ifndef XEN
 extern struct pci_ops pci_root_ops;
=20
 static inline int pci_proc_domain(struct pci_bus *bus)
@@ -161,7 +166,6 @@ extern void pcibios_resource_to_bus(stru
 extern void pcibios_bus_to_resource(struct pci_dev *dev,
 		struct resource *res, struct pci_bus_region *region);
=20
-#ifndef XEN
 static inline struct resource *
 pcibios_select_root(struct pci_dev *pdev, struct resource *res)
 {
--- /dev/null
+++ b/xen/include/asm-x86/pci.h
@@ -0,0 +1,8 @@
+#ifndef __X86_PCI_H__
+#define __X86_PCI_H__
+
+struct arch_pci_dev {
+    vmask_t used_vectors;
+};
+
+#endif /* __X86_PCI_H__ */
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -12,6 +12,7 @@
 #include <xen/list.h>
 #include <xen/spinlock.h>
 #include <xen/irq.h>
+#include <asm/pci.h>
=20
 /*
  * The PCI interface treats multi-function devices as independent
@@ -39,9 +40,6 @@ struct pci_dev_info {
         u8 bus;
         u8 devfn;
     } physfn;
-#ifdef CONFIG_X86
-    vmask_t used_vectors;
-#endif
 };
=20
 struct pci_dev {
@@ -62,6 +60,7 @@ struct pci_dev {
     const u8 bus;
     const u8 devfn;
     struct pci_dev_info info;
+    struct arch_pci_dev arch;
     u64 vf_rlen[6];
 };
=20




--=__PartB896F072.0__=
Content-Type: text/plain; name="arch-pci_dev.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arch-pci_dev.patch"

PCI: properly abstract out per-architecture extensions to struct pci_dev=0A=
=0Ax86's used_vectors member was both misplaced (in struct pci_dev_info,=0A=
which acts as a hypercall input data passing container only) and=0Aimproper=
ly abstracted (requiring a CONFIG_X86 conditional in a generic=0Aheader).=
=0A=0AThe adjustment requires hiding several more lines in IA64's pci.h, =
but=0Aas a benefit this allows removing one of the "null" headers.=0A=0ASig=
ned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/irq.c=
=0A+++ b/xen/arch/x86/irq.c=0A@@ -1877,7 +1877,7 @@ int map_domain_pirq(=0A=
         if ( opt_irq_vector_map =3D=3D OPT_IRQ_VECTOR_MAP_PERDEV=0A       =
       && !desc->arch.used_vectors )=0A         {=0A-            desc->arch=
.used_vectors =3D &pdev->info.used_vectors;=0A+            desc->arch.used_=
vectors =3D &pdev->arch.used_vectors;=0A             if ( desc->arch.vector=
 !=3D IRQ_VECTOR_UNASSIGNED )=0A             {=0A                 int =
vector =3D desc->arch.vector;=0A--- a/xen/include/asm-ia64/linux-null/asm-g=
eneric/pci-dma-compat.h=0A+++ /dev/null=0A@@ -1 +0,0 @@=0A-/* This file is =
intentionally left empty. */=0A--- a/xen/include/asm-ia64/linux-xen/asm/pci=
.h=0A+++ b/xen/include/asm-ia64/linux-xen/asm/pci.h=0A@@ -28,6 +28,10 @@ =
void pcibios_config_init(void);=0A =0A struct pci_dev;=0A =0A+#ifdef =
XEN=0A+struct arch_pci_dev {};=0A+#endif=0A+=0A /*=0A  * PCI_DMA_BUS_IS_PHY=
S should be set to 1 if there is _necessarily_ a direct correspondence=0A  =
* between device bus addresses and CPU physical addresses.  Platforms with =
a hardware I/O=0A@@ -43,6 +47,7 @@ struct pci_dev;=0A extern unsigned long =
ia64_max_iommu_merge_mask;=0A #define PCI_DMA_BUS_IS_PHYS	(ia64_max_i=
ommu_merge_mask =3D=3D ~0UL)=0A =0A+#ifndef XEN=0A static inline void=0A =
pcibios_set_master (struct pci_dev *dev)=0A {=0A@@ -110,7 +115,6 @@ extern =
int pci_mmap_page_range (struct p=0A #define HAVE_PCI_LEGACY=0A extern int =
pci_mmap_legacy_page_range(struct pci_bus *bus,=0A 				=
      struct vm_area_struct *vma);=0A-#ifndef XEN=0A extern ssize_t =
pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t off,=0A 		=
		  size_t count);=0A extern ssize_t pci_write_legacy_io(stru=
ct kobject *kobj, char *buf, loff_t off,=0A@@ -144,6 +148,7 @@ struct =
pci_controller {=0A #define PCI_CONTROLLER(busdev) ((struct pci_controller =
*) busdev->sysdata)=0A #define pci_domain_nr(busdev)    (PCI_CONTROLLER(bus=
dev)->segment)=0A =0A+#ifndef XEN=0A extern struct pci_ops pci_root_ops;=0A=
 =0A static inline int pci_proc_domain(struct pci_bus *bus)=0A@@ -161,7 =
+166,6 @@ extern void pcibios_resource_to_bus(stru=0A extern void =
pcibios_bus_to_resource(struct pci_dev *dev,=0A 		struct =
resource *res, struct pci_bus_region *region);=0A =0A-#ifndef XEN=0A =
static inline struct resource *=0A pcibios_select_root(struct pci_dev =
*pdev, struct resource *res)=0A {=0A--- /dev/null=0A+++ b/xen/include/asm-x=
86/pci.h=0A@@ -0,0 +1,8 @@=0A+#ifndef __X86_PCI_H__=0A+#define __X86_PCI_H_=
_=0A+=0A+struct arch_pci_dev {=0A+    vmask_t used_vectors;=0A+};=0A+=0A+#e=
ndif /* __X86_PCI_H__ */=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/include/=
xen/pci.h=0A@@ -12,6 +12,7 @@=0A #include <xen/list.h>=0A #include =
<xen/spinlock.h>=0A #include <xen/irq.h>=0A+#include <asm/pci.h>=0A =0A =
/*=0A  * The PCI interface treats multi-function devices as independent=0A@=
@ -39,9 +40,6 @@ struct pci_dev_info {=0A         u8 bus;=0A         u8 =
devfn;=0A     } physfn;=0A-#ifdef CONFIG_X86=0A-    vmask_t used_vectors;=
=0A-#endif=0A };=0A =0A struct pci_dev {=0A@@ -62,6 +60,7 @@ struct =
pci_dev {=0A     const u8 bus;=0A     const u8 devfn;=0A     struct =
pci_dev_info info;=0A+    struct arch_pci_dev arch;=0A     u64 vf_rlen[6];=
=0A };=0A =0A
--=__PartB896F072.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

--=__PartB896F072.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:14:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkF2n-0006ru-Bw; Mon, 09 Jan 2012 13:13:45 +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 1RkF2l-0006rT-9H
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:13:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326114816!10158774!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16326 invoked from network); 9 Jan 2012 13:13:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 13:13:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326114816; l=1153;
	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=II70wAU+x/JgZmh0vzY+Y7xjpPw=;
	b=i0hUd43p8GLPQmwLByD9OxaiRNxggm6sJioPlEA7XFyp8UVr7MTaIzrtVV7FLxO8myW
	SZ1JOVLFvLayKm+sRPCMEn7LVh7MX78PMBiu78Rn4Zxk/a0vTwtstjbMKcBgNHOJox24Z
	MzxNQCsjZRiX7omar3kQwkhayusc0ta0hHk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (cohen mo24) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v05135o09Co3BL ;
	Mon, 9 Jan 2012 14:13:23 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 62F8618637; Mon,  9 Jan 2012 14:13:22 +0100 (CET)
Date: Mon, 9 Jan 2012 14:13:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120109131322.GB8514@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20120105205910.GA29311@aepfle.de>
	<20120106130737.GB1694@aepfle.de>
	<002c01cccd1a$279c9a00$76d5ce00$@com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <002c01cccd1a$279c9a00$76d5ce00$@com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 07, Hongkaixing wrote:

> 
> > -----Original Message-----
> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > Sent: Friday, January 06, 2012 9:08 PM
> > To: hongkaixing@huawei.com
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [PATCH] xenpaging:add a new array to speed up page-in in xenpaging
> > 
> > On Thu, Jan 05, Olaf Hering wrote:
> > 
> > > Is the page-out time for 512M really that fast? For me page-out is still
> > > really slow even when the pagefile is in tmpfs. It takes several
> > > minutes, I get around 4MB/s. page-in is around 20MB/s.
> > 
> > Wait, the slow page-out is due to the poll() timeout in
> > xenpaging_wait_for_event_or_timeout(). This can be fixed with some sort
> > of dynamic timeout while there is still something to page-out.
> 
>    I don't think so. Our approach still use 100ms in poll(), Using 10ms seems no significant change.

Sure, I was talking about page-out. With my change to use no timeout for
poll() the guests memory was paged-out in a few seconds.
I will send a patch for that today.

page-in is still slow as you know, we need to improve that in some way.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:14:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:14:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkF2n-0006ru-Bw; Mon, 09 Jan 2012 13:13:45 +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 1RkF2l-0006rT-9H
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:13:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326114816!10158774!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16326 invoked from network); 9 Jan 2012 13:13:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 13:13:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326114816; l=1153;
	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=II70wAU+x/JgZmh0vzY+Y7xjpPw=;
	b=i0hUd43p8GLPQmwLByD9OxaiRNxggm6sJioPlEA7XFyp8UVr7MTaIzrtVV7FLxO8myW
	SZ1JOVLFvLayKm+sRPCMEn7LVh7MX78PMBiu78Rn4Zxk/a0vTwtstjbMKcBgNHOJox24Z
	MzxNQCsjZRiX7omar3kQwkhayusc0ta0hHk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (cohen mo24) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v05135o09Co3BL ;
	Mon, 9 Jan 2012 14:13:23 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 62F8618637; Mon,  9 Jan 2012 14:13:22 +0100 (CET)
Date: Mon, 9 Jan 2012 14:13:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120109131322.GB8514@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20120105205910.GA29311@aepfle.de>
	<20120106130737.GB1694@aepfle.de>
	<002c01cccd1a$279c9a00$76d5ce00$@com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <002c01cccd1a$279c9a00$76d5ce00$@com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: bicky.shi@huawei.com, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, yanqiangjun@huawei.com,
	hanweidong@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 07, Hongkaixing wrote:

> 
> > -----Original Message-----
> > From: Olaf Hering [mailto:olaf@aepfle.de]
> > Sent: Friday, January 06, 2012 9:08 PM
> > To: hongkaixing@huawei.com
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [PATCH] xenpaging:add a new array to speed up page-in in xenpaging
> > 
> > On Thu, Jan 05, Olaf Hering wrote:
> > 
> > > Is the page-out time for 512M really that fast? For me page-out is still
> > > really slow even when the pagefile is in tmpfs. It takes several
> > > minutes, I get around 4MB/s. page-in is around 20MB/s.
> > 
> > Wait, the slow page-out is due to the poll() timeout in
> > xenpaging_wait_for_event_or_timeout(). This can be fixed with some sort
> > of dynamic timeout while there is still something to page-out.
> 
>    I don't think so. Our approach still use 100ms in poll(), Using 10ms seems no significant change.

Sure, I was talking about page-out. With my change to use no timeout for
poll() the guests memory was paged-out in a few seconds.
I will send a patch for that today.

page-in is still slow as you know, we need to improve that in some way.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:15:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13: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 1RkF4M-0006zl-S2; Mon, 09 Jan 2012 13:15: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 1RkF4L-0006zH-2f
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:15:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326114914!7592958!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 18634 invoked from network); 9 Jan 2012 13:15:14 -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; 9 Jan 2012 13:15:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 13:15:13 +0000
Message-Id: <4F0AF66E020000780006B328@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 13:15: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="=__Part8BA5C34E.0__="
Subject: [Xen-devel] [PATCH] VMX: print Pause Loop Exiting disabled message
 just once
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part8BA5C34E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... rather than per booting CPU.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -249,7 +249,8 @@ static int vmx_init_vmcs_config(void)
     if ( (_vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING)=
 &&
           ple_gap =3D=3D 0 )
     {
-        printk("Disable Pause-Loop Exiting.\n");
+        if ( !vmx_pin_based_exec_control )
+            printk(XENLOG_INFO "Disable Pause-Loop Exiting.\n");
         _vmx_secondary_exec_control &=3D ~ SECONDARY_EXEC_PAUSE_LOOP_EXITI=
NG;
     }
=20




--=__Part8BA5C34E.0__=
Content-Type: text/plain; name="vmx-ple-disable-print-once.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vmx-ple-disable-print-once.patch"

VMX: print Pause Loop Exiting disabled message just once=0A=0A... rather =
than per booting CPU.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/hvm/vmx/vmcs.c=0A+++ b/xen/arch/x86/hvm/vmx/vmcs.c=
=0A@@ -249,7 +249,8 @@ static int vmx_init_vmcs_config(void)=0A     if ( =
(_vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING) &&=0A    =
       ple_gap =3D=3D 0 )=0A     {=0A-        printk("Disable Pause-Loop =
Exiting.\n");=0A+        if ( !vmx_pin_based_exec_control )=0A+            =
printk(XENLOG_INFO "Disable Pause-Loop Exiting.\n");=0A         _vmx_second=
ary_exec_control &=3D ~ SECONDARY_EXEC_PAUSE_LOOP_EXITING;=0A     }=0A =0A
--=__Part8BA5C34E.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

--=__Part8BA5C34E.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:15:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13: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 1RkF4M-0006zl-S2; Mon, 09 Jan 2012 13:15: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 1RkF4L-0006zH-2f
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:15:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326114914!7592958!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 18634 invoked from network); 9 Jan 2012 13:15:14 -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; 9 Jan 2012 13:15:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 13:15:13 +0000
Message-Id: <4F0AF66E020000780006B328@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 13:15: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="=__Part8BA5C34E.0__="
Subject: [Xen-devel] [PATCH] VMX: print Pause Loop Exiting disabled message
 just once
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part8BA5C34E.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... rather than per booting CPU.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -249,7 +249,8 @@ static int vmx_init_vmcs_config(void)
     if ( (_vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING)=
 &&
           ple_gap =3D=3D 0 )
     {
-        printk("Disable Pause-Loop Exiting.\n");
+        if ( !vmx_pin_based_exec_control )
+            printk(XENLOG_INFO "Disable Pause-Loop Exiting.\n");
         _vmx_secondary_exec_control &=3D ~ SECONDARY_EXEC_PAUSE_LOOP_EXITI=
NG;
     }
=20




--=__Part8BA5C34E.0__=
Content-Type: text/plain; name="vmx-ple-disable-print-once.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="vmx-ple-disable-print-once.patch"

VMX: print Pause Loop Exiting disabled message just once=0A=0A... rather =
than per booting CPU.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/hvm/vmx/vmcs.c=0A+++ b/xen/arch/x86/hvm/vmx/vmcs.c=
=0A@@ -249,7 +249,8 @@ static int vmx_init_vmcs_config(void)=0A     if ( =
(_vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING) &&=0A    =
       ple_gap =3D=3D 0 )=0A     {=0A-        printk("Disable Pause-Loop =
Exiting.\n");=0A+        if ( !vmx_pin_based_exec_control )=0A+            =
printk(XENLOG_INFO "Disable Pause-Loop Exiting.\n");=0A         _vmx_second=
ary_exec_control &=3D ~ SECONDARY_EXEC_PAUSE_LOOP_EXITING;=0A     }=0A =0A
--=__Part8BA5C34E.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

--=__Part8BA5C34E.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:24:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkFDI-0007I7-Te; Mon, 09 Jan 2012 13:24:36 +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 1RkFDH-0007I2-Sx
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:24:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326115426!47813368!2
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12284 invoked from network); 9 Jan 2012 13:23:47 -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;
	9 Jan 2012 13:23:47 -0000
Received: by mail-wi0-f171.google.com with SMTP id o1so7356585wic.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 05:24:31 -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=5VAHpiG2widNQTPRavDXqxaSaBlX7ec2eHRUYM6Kb4U=;
	b=n2gt0YeHNtx60HME8S5/x2Mtz4ouzj15nl5fY0g9INCIk0RiVigUzhKInT9uYJtnT2
	2QRCxTHrowQT2dUaN3f7i/Rl3o4XKbBM8FAZ/DZocfB/NPjPt3MkBZI9rPzuD/Qnl3Y7
	lDZnFOTmtCz6pYS2mUNy27YgDJj2bCapEbtxU=
Received: by 10.180.20.18 with SMTP id j18mr27401855wie.20.1326115471704;
	Mon, 09 Jan 2012 05:24:31 -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 k33sm36969227wbo.5.2012.01.09.05.24.30
	(version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 05:24:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Jan 2012 13:24: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: <CB309B0B.37083%keir@xen.org>
Thread-Topic: [Xen-devel] Ping: [PATCH] PCI: shrink pci_dev_info's
	is_extfn/is_virtfn members
Thread-Index: AczO0gKpRfHDi0ebsk+zKiHHUkTJTA==
In-Reply-To: <4F0AF568020000780006B30C@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Ping: [PATCH] PCI: shrink pci_dev_info's
 is_extfn/is_virtfn members
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:10, "Jan Beulich" <JBeulich@suse.com> wrote:

> They are used as boolean flags only, so convert them accordingly
> (shrinking the structure size by 8 bytes).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/xen/hypercall.c
> +++ b/xen/arch/ia64/xen/hypercall.c
> @@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA
>          if ( copy_from_guest(&manage_pci_ext, arg, 1) != 0 )
>              break;
>  
> -        pdev_info.is_extfn = manage_pci_ext.is_extfn;
> -        pdev_info.is_virtfn = manage_pci_ext.is_virtfn;
> +        pdev_info.is_extfn = !!manage_pci_ext.is_extfn;
> +        pdev_info.is_virtfn = !!manage_pci_ext.is_virtfn;
>          pdev_info.physfn.bus = manage_pci_ext.physfn.bus;
>          pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
>          ret = pci_add_device(0, manage_pci_ext.bus,
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -33,8 +33,8 @@
>  #define MAX_MSIX_TABLE_ENTRIES  2048
>  #define MAX_MSIX_TABLE_PAGES    8
>  struct pci_dev_info {
> -    unsigned is_extfn;
> -    unsigned is_virtfn;
> +    bool_t is_extfn;
> +    bool_t is_virtfn;
>      struct {
>          u8 bus;
>          u8 devfn;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 13:24:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkFDI-0007I7-Te; Mon, 09 Jan 2012 13:24:36 +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 1RkFDH-0007I2-Sx
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:24:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326115426!47813368!2
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12284 invoked from network); 9 Jan 2012 13:23:47 -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;
	9 Jan 2012 13:23:47 -0000
Received: by mail-wi0-f171.google.com with SMTP id o1so7356585wic.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 05:24:31 -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=5VAHpiG2widNQTPRavDXqxaSaBlX7ec2eHRUYM6Kb4U=;
	b=n2gt0YeHNtx60HME8S5/x2Mtz4ouzj15nl5fY0g9INCIk0RiVigUzhKInT9uYJtnT2
	2QRCxTHrowQT2dUaN3f7i/Rl3o4XKbBM8FAZ/DZocfB/NPjPt3MkBZI9rPzuD/Qnl3Y7
	lDZnFOTmtCz6pYS2mUNy27YgDJj2bCapEbtxU=
Received: by 10.180.20.18 with SMTP id j18mr27401855wie.20.1326115471704;
	Mon, 09 Jan 2012 05:24:31 -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 k33sm36969227wbo.5.2012.01.09.05.24.30
	(version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 05:24:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Jan 2012 13:24: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: <CB309B0B.37083%keir@xen.org>
Thread-Topic: [Xen-devel] Ping: [PATCH] PCI: shrink pci_dev_info's
	is_extfn/is_virtfn members
Thread-Index: AczO0gKpRfHDi0ebsk+zKiHHUkTJTA==
In-Reply-To: <4F0AF568020000780006B30C@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Ping: [PATCH] PCI: shrink pci_dev_info's
 is_extfn/is_virtfn members
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:10, "Jan Beulich" <JBeulich@suse.com> wrote:

> They are used as boolean flags only, so convert them accordingly
> (shrinking the structure size by 8 bytes).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/xen/hypercall.c
> +++ b/xen/arch/ia64/xen/hypercall.c
> @@ -695,8 +695,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HA
>          if ( copy_from_guest(&manage_pci_ext, arg, 1) != 0 )
>              break;
>  
> -        pdev_info.is_extfn = manage_pci_ext.is_extfn;
> -        pdev_info.is_virtfn = manage_pci_ext.is_virtfn;
> +        pdev_info.is_extfn = !!manage_pci_ext.is_extfn;
> +        pdev_info.is_virtfn = !!manage_pci_ext.is_virtfn;
>          pdev_info.physfn.bus = manage_pci_ext.physfn.bus;
>          pdev_info.physfn.devfn = manage_pci_ext.physfn.devfn;
>          ret = pci_add_device(0, manage_pci_ext.bus,
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -33,8 +33,8 @@
>  #define MAX_MSIX_TABLE_ENTRIES  2048
>  #define MAX_MSIX_TABLE_PAGES    8
>  struct pci_dev_info {
> -    unsigned is_extfn;
> -    unsigned is_virtfn;
> +    bool_t is_extfn;
> +    bool_t is_virtfn;
>      struct {
>          u8 bus;
>          u8 devfn;
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 13:24:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkFDK-0007IL-A2; Mon, 09 Jan 2012 13:24:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RkFDJ-0007I1-7p
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:24:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326115426!47813368!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 12259 invoked from network); 9 Jan 2012 13:23:46 -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;
	9 Jan 2012 13:23:46 -0000
Received: by wico1 with SMTP id o1so7356585wic.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 05:24:30 -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=bN8TSft4XfKLPWX/neWj91MTT3GTKCgTt+ncASOfv+8=;
	b=vZgR/bNHNo+GovOpzyCgsAoH2aEZP6SZz8TfVcrKHkVYUWK+hPM0hwjVIIPjOLZjOt
	Gl6XS43n+/2Uh6HbUhY1GYWNCvevPmVAXHbEDIV/4xiM4osIihscPZYRdEVkhDNlPlfd
	TDvzeViqHsxIx4LN9pkGsbxoHNQX0N561v0ns=
Received: by 10.180.20.39 with SMTP id k7mr4679832wie.6.1326115470743;
	Mon, 09 Jan 2012 05:24:30 -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 k33sm36969227wbo.5.2012.01.09.05.24.28
	(version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 05:24:29 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Jan 2012 13:24:13 +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: <CB309AFD.37082%keir@xen.org>
Thread-Topic: [Xen-devel] Ping: [PATCH] PCI: properly abstract out
	per-architecture extensions to struct pci_dev
Thread-Index: AczO0fpQW9SiBK9SBUafSMwH3gizLw==
In-Reply-To: <4F0AF572020000780006B310@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Ping: [PATCH] PCI: properly abstract out
 per-architecture extensions to struct pci_dev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:10, "Jan Beulich" <JBeulich@suse.com> wrote:

> x86's used_vectors member was both misplaced (in struct pci_dev_info,
> which acts as a hypercall input data passing container only) and
> improperly abstracted (requiring a CONFIG_X86 conditional in a generic
> header).
> 
> The adjustment requires hiding several more lines in IA64's pci.h, but
> as a benefit this allows removing one of the "null" headers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1877,7 +1877,7 @@ int map_domain_pirq(
>          if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_PERDEV
>               && !desc->arch.used_vectors )
>          {
> -            desc->arch.used_vectors = &pdev->info.used_vectors;
> +            desc->arch.used_vectors = &pdev->arch.used_vectors;
>              if ( desc->arch.vector != IRQ_VECTOR_UNASSIGNED )
>              {
>                  int vector = desc->arch.vector;
> --- a/xen/include/asm-ia64/linux-null/asm-generic/pci-dma-compat.h
> +++ /dev/null
> @@ -1 +0,0 @@
> -/* This file is intentionally left empty. */
> --- a/xen/include/asm-ia64/linux-xen/asm/pci.h
> +++ b/xen/include/asm-ia64/linux-xen/asm/pci.h
> @@ -28,6 +28,10 @@ void pcibios_config_init(void);
>  
>  struct pci_dev;
>  
> +#ifdef XEN
> +struct arch_pci_dev {};
> +#endif
> +
>  /*
>   * PCI_DMA_BUS_IS_PHYS should be set to 1 if there is _necessarily_ a direct
> correspondence
>   * between device bus addresses and CPU physical addresses.  Platforms with a
> hardware I/O
> @@ -43,6 +47,7 @@ struct pci_dev;
>  extern unsigned long ia64_max_iommu_merge_mask;
>  #define PCI_DMA_BUS_IS_PHYS (ia64_max_iommu_merge_mask == ~0UL)
>  
> +#ifndef XEN
>  static inline void
>  pcibios_set_master (struct pci_dev *dev)
>  {
> @@ -110,7 +115,6 @@ extern int pci_mmap_page_range (struct p
>  #define HAVE_PCI_LEGACY
>  extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
>      struct vm_area_struct *vma);
> -#ifndef XEN
>  extern ssize_t pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t
> off,
>  size_t count);
>  extern ssize_t pci_write_legacy_io(struct kobject *kobj, char *buf, loff_t
> off,
> @@ -144,6 +148,7 @@ struct pci_controller {
>  #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)
>  #define pci_domain_nr(busdev)    (PCI_CONTROLLER(busdev)->segment)
>  
> +#ifndef XEN
>  extern struct pci_ops pci_root_ops;
>  
>  static inline int pci_proc_domain(struct pci_bus *bus)
> @@ -161,7 +166,6 @@ extern void pcibios_resource_to_bus(stru
>  extern void pcibios_bus_to_resource(struct pci_dev *dev,
> struct resource *res, struct pci_bus_region *region);
>  
> -#ifndef XEN
>  static inline struct resource *
>  pcibios_select_root(struct pci_dev *pdev, struct resource *res)
>  {
> --- /dev/null
> +++ b/xen/include/asm-x86/pci.h
> @@ -0,0 +1,8 @@
> +#ifndef __X86_PCI_H__
> +#define __X86_PCI_H__
> +
> +struct arch_pci_dev {
> +    vmask_t used_vectors;
> +};
> +
> +#endif /* __X86_PCI_H__ */
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -12,6 +12,7 @@
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
>  #include <xen/irq.h>
> +#include <asm/pci.h>
>  
>  /*
>   * The PCI interface treats multi-function devices as independent
> @@ -39,9 +40,6 @@ struct pci_dev_info {
>          u8 bus;
>          u8 devfn;
>      } physfn;
> -#ifdef CONFIG_X86
> -    vmask_t used_vectors;
> -#endif
>  };
>  
>  struct pci_dev {
> @@ -62,6 +60,7 @@ struct pci_dev {
>      const u8 bus;
>      const u8 devfn;
>      struct pci_dev_info info;
> +    struct arch_pci_dev arch;
>      u64 vf_rlen[6];
>  };
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:24:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:24:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkFDK-0007IL-A2; Mon, 09 Jan 2012 13:24:38 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RkFDJ-0007I1-7p
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:24:37 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326115426!47813368!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 12259 invoked from network); 9 Jan 2012 13:23:46 -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;
	9 Jan 2012 13:23:46 -0000
Received: by wico1 with SMTP id o1so7356585wic.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 05:24:30 -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=bN8TSft4XfKLPWX/neWj91MTT3GTKCgTt+ncASOfv+8=;
	b=vZgR/bNHNo+GovOpzyCgsAoH2aEZP6SZz8TfVcrKHkVYUWK+hPM0hwjVIIPjOLZjOt
	Gl6XS43n+/2Uh6HbUhY1GYWNCvevPmVAXHbEDIV/4xiM4osIihscPZYRdEVkhDNlPlfd
	TDvzeViqHsxIx4LN9pkGsbxoHNQX0N561v0ns=
Received: by 10.180.20.39 with SMTP id k7mr4679832wie.6.1326115470743;
	Mon, 09 Jan 2012 05:24:30 -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 k33sm36969227wbo.5.2012.01.09.05.24.28
	(version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 05:24:29 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Jan 2012 13:24:13 +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: <CB309AFD.37082%keir@xen.org>
Thread-Topic: [Xen-devel] Ping: [PATCH] PCI: properly abstract out
	per-architecture extensions to struct pci_dev
Thread-Index: AczO0fpQW9SiBK9SBUafSMwH3gizLw==
In-Reply-To: <4F0AF572020000780006B310@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Ping: [PATCH] PCI: properly abstract out
 per-architecture extensions to struct pci_dev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:10, "Jan Beulich" <JBeulich@suse.com> wrote:

> x86's used_vectors member was both misplaced (in struct pci_dev_info,
> which acts as a hypercall input data passing container only) and
> improperly abstracted (requiring a CONFIG_X86 conditional in a generic
> header).
> 
> The adjustment requires hiding several more lines in IA64's pci.h, but
> as a benefit this allows removing one of the "null" headers.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -1877,7 +1877,7 @@ int map_domain_pirq(
>          if ( opt_irq_vector_map == OPT_IRQ_VECTOR_MAP_PERDEV
>               && !desc->arch.used_vectors )
>          {
> -            desc->arch.used_vectors = &pdev->info.used_vectors;
> +            desc->arch.used_vectors = &pdev->arch.used_vectors;
>              if ( desc->arch.vector != IRQ_VECTOR_UNASSIGNED )
>              {
>                  int vector = desc->arch.vector;
> --- a/xen/include/asm-ia64/linux-null/asm-generic/pci-dma-compat.h
> +++ /dev/null
> @@ -1 +0,0 @@
> -/* This file is intentionally left empty. */
> --- a/xen/include/asm-ia64/linux-xen/asm/pci.h
> +++ b/xen/include/asm-ia64/linux-xen/asm/pci.h
> @@ -28,6 +28,10 @@ void pcibios_config_init(void);
>  
>  struct pci_dev;
>  
> +#ifdef XEN
> +struct arch_pci_dev {};
> +#endif
> +
>  /*
>   * PCI_DMA_BUS_IS_PHYS should be set to 1 if there is _necessarily_ a direct
> correspondence
>   * between device bus addresses and CPU physical addresses.  Platforms with a
> hardware I/O
> @@ -43,6 +47,7 @@ struct pci_dev;
>  extern unsigned long ia64_max_iommu_merge_mask;
>  #define PCI_DMA_BUS_IS_PHYS (ia64_max_iommu_merge_mask == ~0UL)
>  
> +#ifndef XEN
>  static inline void
>  pcibios_set_master (struct pci_dev *dev)
>  {
> @@ -110,7 +115,6 @@ extern int pci_mmap_page_range (struct p
>  #define HAVE_PCI_LEGACY
>  extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
>      struct vm_area_struct *vma);
> -#ifndef XEN
>  extern ssize_t pci_read_legacy_io(struct kobject *kobj, char *buf, loff_t
> off,
>  size_t count);
>  extern ssize_t pci_write_legacy_io(struct kobject *kobj, char *buf, loff_t
> off,
> @@ -144,6 +148,7 @@ struct pci_controller {
>  #define PCI_CONTROLLER(busdev) ((struct pci_controller *) busdev->sysdata)
>  #define pci_domain_nr(busdev)    (PCI_CONTROLLER(busdev)->segment)
>  
> +#ifndef XEN
>  extern struct pci_ops pci_root_ops;
>  
>  static inline int pci_proc_domain(struct pci_bus *bus)
> @@ -161,7 +166,6 @@ extern void pcibios_resource_to_bus(stru
>  extern void pcibios_bus_to_resource(struct pci_dev *dev,
> struct resource *res, struct pci_bus_region *region);
>  
> -#ifndef XEN
>  static inline struct resource *
>  pcibios_select_root(struct pci_dev *pdev, struct resource *res)
>  {
> --- /dev/null
> +++ b/xen/include/asm-x86/pci.h
> @@ -0,0 +1,8 @@
> +#ifndef __X86_PCI_H__
> +#define __X86_PCI_H__
> +
> +struct arch_pci_dev {
> +    vmask_t used_vectors;
> +};
> +
> +#endif /* __X86_PCI_H__ */
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -12,6 +12,7 @@
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
>  #include <xen/irq.h>
> +#include <asm/pci.h>
>  
>  /*
>   * The PCI interface treats multi-function devices as independent
> @@ -39,9 +40,6 @@ struct pci_dev_info {
>          u8 bus;
>          u8 devfn;
>      } physfn;
> -#ifdef CONFIG_X86
> -    vmask_t used_vectors;
> -#endif
>  };
>  
>  struct pci_dev {
> @@ -62,6 +60,7 @@ struct pci_dev {
>      const u8 bus;
>      const u8 devfn;
>      struct pci_dev_info info;
> +    struct arch_pci_dev arch;
>      u64 vf_rlen[6];
>  };
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:25:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkFDj-0007La-UI; Mon, 09 Jan 2012 13:25:03 +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 1RkFDh-0007L4-Vq
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:25:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326115495!8373147!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 10970 invoked from network); 9 Jan 2012 13:24:56 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 13:24:56 -0000
Received: by werg1 with SMTP id g1so8145044wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 05:24:55 -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=g+qLdnBnLBhbEhwmJd76wtZL7C5yGy/TPyPGSApGnrM=;
	b=ZrsiHKAexeXIfNB4M2sQk+5FKr7pSE//UYBTy7Gchs5f8qV+IjW5Cxhhp+RFLL6Ofd
	rpNMeadZ8PFnbIAA8/lRksfOnMdKPL37iRVZPLMFtv7f+asI/Hogg0v6KG4l0ucJoo39
	78Hjjv6OJYWcwx/FPrMHE2qSQbQ/3jEEGQsnc=
Received: by 10.216.139.140 with SMTP id c12mr7403415wej.26.1326115495682;
	Mon, 09 Jan 2012 05:24:55 -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 e8sm6135525wiz.10.2012.01.09.05.24.54
	(version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 05:24:55 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Jan 2012 13:24:51 +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: <CB309B23.37084%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] VMX: print Pause Loop Exiting disabled
	message just once
Thread-Index: AczO0hD3/9SK1eT4F0CKITFF2oCing==
In-Reply-To: <4F0AF66E020000780006B328@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] VMX: print Pause Loop Exiting disabled
 message just once
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:15, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... rather than per booting CPU.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -249,7 +249,8 @@ static int vmx_init_vmcs_config(void)
>      if ( (_vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING) &&
>            ple_gap == 0 )
>      {
> -        printk("Disable Pause-Loop Exiting.\n");
> +        if ( !vmx_pin_based_exec_control )
> +            printk(XENLOG_INFO "Disable Pause-Loop Exiting.\n");
>          _vmx_secondary_exec_control &= ~ SECONDARY_EXEC_PAUSE_LOOP_EXITING;
>      }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 13:25:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkFDj-0007La-UI; Mon, 09 Jan 2012 13:25:03 +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 1RkFDh-0007L4-Vq
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:25:02 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326115495!8373147!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 10970 invoked from network); 9 Jan 2012 13:24:56 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 13:24:56 -0000
Received: by werg1 with SMTP id g1so8145044wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 05:24:55 -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=g+qLdnBnLBhbEhwmJd76wtZL7C5yGy/TPyPGSApGnrM=;
	b=ZrsiHKAexeXIfNB4M2sQk+5FKr7pSE//UYBTy7Gchs5f8qV+IjW5Cxhhp+RFLL6Ofd
	rpNMeadZ8PFnbIAA8/lRksfOnMdKPL37iRVZPLMFtv7f+asI/Hogg0v6KG4l0ucJoo39
	78Hjjv6OJYWcwx/FPrMHE2qSQbQ/3jEEGQsnc=
Received: by 10.216.139.140 with SMTP id c12mr7403415wej.26.1326115495682;
	Mon, 09 Jan 2012 05:24:55 -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 e8sm6135525wiz.10.2012.01.09.05.24.54
	(version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 05:24:55 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Jan 2012 13:24:51 +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: <CB309B23.37084%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] VMX: print Pause Loop Exiting disabled
	message just once
Thread-Index: AczO0hD3/9SK1eT4F0CKITFF2oCing==
In-Reply-To: <4F0AF66E020000780006B328@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] VMX: print Pause Loop Exiting disabled
 message just once
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:15, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... rather than per booting CPU.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -249,7 +249,8 @@ static int vmx_init_vmcs_config(void)
>      if ( (_vmx_secondary_exec_control & SECONDARY_EXEC_PAUSE_LOOP_EXITING) &&
>            ple_gap == 0 )
>      {
> -        printk("Disable Pause-Loop Exiting.\n");
> +        if ( !vmx_pin_based_exec_control )
> +            printk(XENLOG_INFO "Disable Pause-Loop Exiting.\n");
>          _vmx_secondary_exec_control &= ~ SECONDARY_EXEC_PAUSE_LOOP_EXITING;
>      }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 13:52:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13: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 1RkFdg-0007qp-CH; Mon, 09 Jan 2012 13:51: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 1RkFdf-0007qh-1H
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:51:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326117083!52056695!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 31775 invoked from network); 9 Jan 2012 13:51:24 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 13:51:24 -0000
Received: by daec6 with SMTP id c6so15248050dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 05:51: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=6qJ0rFWXLzWzEP7u43PPzUKm7Lrubl1jEGF6bi7xgx4=;
	b=WC7eEgVxwrf8012ygFiqI+qmhN/1tc4FAzhMVSQYTn78ZHkO1A0A8msMBDUluqI8JO
	mvOj21a7MWNUal73GzPGbOqnT0FXuPdXvSZ2UxAGTqU6f2OhkFi6o7aY7bWdxVVnKO9N
	N4axgsz0Ea9mp5V8eAeoDLLoHdzQj6rK/YFAg=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr41640060pbc.77.1326117101893; Mon,
	09 Jan 2012 05:51:41 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 9 Jan 2012 05:51:41 -0800 (PST)
In-Reply-To: <1326110599.17210.81.camel@zakaz.uk.xensource.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<1326110599.17210.81.camel@zakaz.uk.xensource.com>
Date: Mon, 9 Jan 2012 14:51:41 +0100
X-Google-Sender-Auth: 8atOWyG8qkPR9VKeI7NCPqBth-Y
Message-ID: <CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gU2F0
LCAyMDEyLTAxLTA3IGF0IDAzOjIwICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNTkwNjIzMCAtMzYwMAo+PiAjIE5vZGUgSUQgZTEy
ZWMxMDcxNDEwYzk0NjM2N2NiMDUwOGNmMjE4YTBjM2I1OTZjYQo+PiAjIFBhcmVudCDCoDQwODZl
NDgxMTU0N2RkZmZiOWE1M2ZiZjJlZmI2YzJmYTQzNmI3MGEKPj4gYnVpbGQ6IGFkZCBhdXRvY29u
ZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3MgaW4gdG9vbHMvY2hlY2sKPj4KPj4gQWRkZWQgYXV0
b3Rvb2xzIG1hZ2ljIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrIHNjcmlwdHMuIFRoZSBwcmV2aW91
cwo+PiBjaGVja3MgaGF2ZSBiZWVuIHBvcnRlZCB0byBhdXRvY29uZiwgYW5kIHNvbWUgYWRkaXRp
b25hbCBvbmVzIGhhdmUKPj4gYmVlbiBhZGRlZCAocGx1cyB0aGUgc3VnZ2VzdGlvbnMgZnJvbSBy
dW5uaW5nIGF1dG9zY2FuKS4gVHdvIGZpbGVzIGFyZQo+PiBjcmVhdGVkIGFzIGEgcmVzdWx0IGZy
b20gZXhlY3V0aW5nIGNvbmZpZ3VyZSBzY3JpcHQsCj4+IGNvbmZpZy9BdXRvY29uZi5tayBhbmQg
Y29uZmlnLmguCj4+Cj4+IEF1dG9jb25mLm1rIGlzIGluY2x1ZGVkIGJ5IENvbmZpZy5taywgYW5k
IGNvbnRhaW5zIG1vc3Qgb2YgdGhlCj4+IG9wdGlvbnMgcHJldmlvdXNseSBkZWZpbmVkIGluIC5j
b25maWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwo+PiBwYXJhbWV0ZXJzIG9yIGRlZmlu
aW5nIGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBjb25maWd1cmUKPj4gc2Ny
aXB0Lgo+Pgo+PiBjb25maWcuaCBpcyBzdGlsbCBub3QgdXNlZCBhbnl3aGVyZSwgYW5kIGlzIGF1
dG9tYXRpY2FsbHkgY3JlYXRlZCBieQo+PiBhdXRvaGVhZGVyLCBhbHRvdWdoIHRoaXMgbWlnaCBj
aGFuZ2Ugd2hlbiB3ZSBzdGFydCB0byBpbmNsdWRlIHRoaXMKPj4gZmlsZS4KPj4KPj4gSnVzdCBh
IGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBJaXQncyBteSBmaXJzdCBhdXRvY29uZiBzY3JpcHQg
SSBndWVzcwo+PiB0aGVyZSB3aWxsIGJlIG1hbnkgdGhpbmdzIHRvIHBvbGlzaCBoZXJlLi4uIFBs
ZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBN
b25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4KPiBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQg
dG8gc2VlIGFuIHVwZGF0ZSB0byB0aGUgY2xlYW4vZGlzdGNsZWFuIHJ1bGVzCj4gYW5kIC5oZ2ln
bm9yZSBkdWUgdG8gYWxsIHRoZSBuZXcgZ2VuZXJhdGVkIGZpbGVzLgoKWWVzLCBJIHdhcyBnb2lu
ZyB0byBkbyB0aGF0IHdoZW4gd2UgYWdyZWUgb24gd2VyZSBzaG91bGQgdGhpbmdzCnJlc2lkZSwg
dGhhdCdzIHdoeSBJIGRpZG4ndCBpbmNsdWRlIGFueSBvZiB0aGlzIG9uIHRoZSBwYXRjaC4KCj4+
IGRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBSRUFETUUKPj4gLS0tIGEvUkVB
RE1FIMKgIMKgVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCj4+ICsrKyBiL1JFQURNRSDC
oCDCoFNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+PiBAQCAtODcsOSArODcsMTUgQEAg
Mi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0ZXZlciB5b3Ugcwo+PiDCoDMuIEZvciB0aGUg
dmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJveSBidWlsZCB0cmVlcywK
Pj4gwqAgwqAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgo+PgoKVGhpcyB3aWxsIGJlIGxp
a2U6CgojIGFjbG9jYWwgJiYgYXV0b21ha2UgLWEKCj4+ICsgwqAgwqAjIGF1dG9tYWtlIC1hCj4K
PiBXZSBhcmVuJ3QgdXNpbmcgYXV0b21ha2UgdGhvdWdoPyBQZXJoYXBzIHRoaXMgZXhwbGFpbnMg
eW91ciBwcm9ibGVtIHdpdGgKPiB0aGluZ3MgYWx3eWFzIHRyeWluZyB0byB1c2UgTWFrZWZpbGUu
YW0/CgpXZSBuZWVkIHRvIHJ1biBhdXRvbWFrZSwgYmVjYXVzZSBpdCBnZW5lcmF0ZXMgY29uZmln
LnN1YiBhbmQKY29uZmlnLmd1ZXNzLCB3aGljaCBpcyBuZWVkZWQgZm9yIGNlcnRhaW4gYXV0b2Nv
bmYgdGVzdHMuIFRoZSBwcm9ibGVtCmlzIHRoYXQgSSBkb24ndCBrbm93IGhvdyB0byBjYWxsIGF1
dG9tYWtlIHRvIG9ubHkgZ2VuZXJhdGUgdGhvc2UgZmlsZXMKYW5kIGRvbid0IHRyeSB0byBwYXJz
ZSBNYWtlZmlsZS5hbSwgYmVjYXVzZSBhdXRvbWFrZSB0cmllcyB0byBwYXJzZQpNYWtlZmlsZS5h
bSBhbmQgZXhpdHMgd2l0aCBhbiBlcnJvciBjb2RlLCB0aGF0J3MgYWxzbyBwcmV2ZW50aW5nIG1l
CmZyb20gdXNpbmcgYXV0b3JlY29uZiBhbmQgZm9yZ2V0IGFib3V0IGNhbGxpbmcgYWNsb2NhbCwg
YXV0b21ha2UsCmF1dG9oZWFkZXIuLi4gc2VwYXJhdGVseS4gSSB3YXMgaG9waW5nIHRoYXQgc29t
ZSBhdXRvdG9vbHMgZXhwZXJ0IGhhcwphIHNvbHV0aW9uIGZvciB0aGlzIChJIHdpbGwga2VlcCBz
ZWFyY2hpbmcgYWxzbykuCgo+PiArIMKgIMKgIyBhdXRvaGVhZGVyICYmIGF1dG9jb25mCj4KPiBX
aGF0IGRvZXMgYXV0b2hlYWRlciBkbz8gVGhpcyBzaG91bGQgYmUgY2xlYXJseSBub3RlZCBhcyBi
ZWluZyBvbmx5Cj4gbmVjZXNzYXJ5IGlmIGJ1aWxkaW5nIGZyb20gaGcgYW5kIG5vdCBpZiB5b3Ug
YXJlIGJ1aWxkaW5nIGZyb20gdGFyYmFsbC4KPiBJIGV4cGVjdCB3ZSBhbHNvIG5lZWQgc29tZSBt
YWtlZmlsZSBydW5lcyBvciBwcm9jZXNzIHVwZGF0ZXMgdG8gbWFrZQo+IHN1cmUgdGhlIGdlbmVy
YXRlZCBzdHVmZiBnZXRzIGluY2x1ZGVkIGluIHRoZSB0YXJiYWxsLgoKYXV0b2hlYWRlciBjcmVh
dGVzIGEgZ2VuZXJpYyBjb25maWcuaC5pbiB3aGljaCBjb250YWlucyBkZWZpbmVzIGZvcgphbGwg
dGhlIGV4cG9ydGVkIHZhcmlhYmxlcy4gV2UgY291bGQgY3JlYXRlIG91ciBvd24gY29uZmlnLmgu
aW4gYW5kCmRvbid0IHJ1biBhdXRvaGVhZGVyLCBidXQgSSB0aGluayB0aGUgZ2VuZXJhdGVkIGZp
bGUgaXMgZmluZS4KCj4KPiBZb3UgbmVlZCB0byBhZGQgdGhlIHJlbGV2YW50IHBhY2thZ2VzIHRv
IHRoZSBsaXN0IG9mIGJ1aWxkIHJlcXVpcmVtZW50cy4KCk9rLCB3aWxsIG1ha2UgYSBsaXN0Cgo+
PiArIMKgIMKgIyAuL2NvbmZpZ3VyZQo+PiDCoCDCoCDCoCMgbWFrZSB3b3JsZAo+PiDCoCDCoCDC
oCMgbWFrZSBpbnN0YWxsCj4+Cj4+ICsgwqAgSWYgeW91IHdhbnQsIHlvdSBjYW4gcnVuIC4vY29u
ZmlndXJlIC0taGVscCB0byBzZWUgdGhlIGxpc3Qgb2YKPj4gKyDCoCBvcHRpbnMgYXZhaWxhYmxl
IG9wdGlvbnMgd2hlbiBidWlsZGluZyBhbmQgaW5zdGFsbGluZyBYZW4uCj4KPiDCoCDCoCDCoG9w
dGlvbnMKCkFsc28gT2sgd2hlbiB3ZSBkZWNpZGUgdGhlIGRlZmluaXRpdmUgb3B0aW9ucy4KCj4+
ICsKPj4gwqAgwqAgVGhpcyB3aWxsIGNyZWF0ZSBhbmQgaW5zdGFsbCBvbnRvIHRoZSBsb2NhbCBt
YWNoaW5lLiBJdCB3aWxsIGJ1aWxkCj4+IMKgIMKgIHRoZSB4ZW4gYmluYXJ5ICh4ZW4uZ3opLCB0
aGUgdG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0aW9uLgo+Pgo+PiBkaWZmIC1yIDQwODZlNDgxMTU0
NyAtciBlMTJlYzEwNzE0MTAgY29uZmlnL0F1dG9jb25mLm1rLmluCj4+IC0tLSAvZGV2L251bGwg
wqAgVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCj4+ICsrKyBiL2NvbmZpZy9BdXRvY29u
Zi5tay5pbiDCoCDCoCBTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKPj4gQEAgLTAsMCAr
MSw0OSBAQAo+PiArIyBQcmVmaXggYW5kIGluc3RhbGwgZm9sZGVyCj4+ICtQUkVGSVggwqAgwqAg
wqAgwqAgwqAgwqAgwqA6PSBAcHJlZml4QAo+PiArTElCTEVBRkRJUl94ODZfNjQgwqAgOj0gQExJ
Ql9QQVRIQAo+PiArCj4+ICsjIEEgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29scz8KPj4gK2Rl
YnVnIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDo9IEBkZWJ1Z0AKPj4gKwo+PiArIyBUb29scyBwYXRo
Cj4+ICtCSVNPTiDCoCDCoCDCoCDCoCDCoCDCoCDCoCA6PSBAQklTT05ACj4+ICtGTEVYIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgOj0gQEZMRVhACj4+ICtQWVRIT04gwqAgwqAgwqAgwqAgwqAgwqAg
wqA6PSBAUFlUSE9OQAo+PiArUEVSTCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDo9IEBQRVJMQAo+
PiArQlJDVEwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOj0gQEJSQ1RMQAo+PiArSVAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqA6PSBASVBACj4+ICtDVVJMLUNPTkZJRyDCoCDCoCDCoCDCoCA6PSBA
Q1VSTEAKPgo+IEFyZSBoeXBoZW5zIG9rIGluIG1ha2UgdmFyaWFibGVzPwoKTG9va3MgbGlrZSwg
YnV0IEkgd2lsbCByZXBsYWNlIHRoZW0gd2l0aCB1bmRlcnNjb3JlcyAoXykgdG8gYmUgb24gdGhl
IHNhZmUgc2lkZS4KCj4KPj4gK1hNTDItQ09ORklHIMKgIMKgIMKgIMKgIDo9IEBYTUxACj4+ICtC
QVNIIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgOj0gQEJBU0hACj4+ICtYR0VUVFRFWFQgwqAgwqAg
wqAgwqAgwqAgOj0gQFhHRVRURVhUQAo+PiArCj4+ICsjIEV4dHJhIGZvbGRlciBmb3IgbGlicy9p
bmNsdWRlcwo+PiArUFJFUEVORF9JTkNMVURFUyDCoCDCoDo9IEBQUkVQRU5EX0lOQ0xVREVTQAo+
PiArUFJFUEVORF9MSUIgwqAgwqAgwqAgwqAgOj0gQFBSRVBFTkRfTElCQAo+PiArQVBQRU5EX0lO
Q0xVREVTIMKgIMKgIDo9IEBBUFBFTkRfSU5DTFVERVNACj4+ICtBUFBFTkRfTElCIMKgIMKgIMKg
IMKgIMKgOj0gQEFQUEVORF9MSUJACj4+ICsKPj4gKyMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1
bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKS4KPj4gK1hTTV9FTkFCTEUgwqAgwqAgwqAgwqAgwqA6PSBA
eHNtQAo+PiArRkxBU0tfRU5BQkxFIMKgIMKgIMKgIMKgOj0gQHhzbUAKPj4gKwo+PiArIyBEb3du
bG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8KPj4g
KyMgR0lUJ3MgcHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3Jr
cyBhdCBhbGwgKGZpcmV3YWxscwo+PiArIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBk
ZWZhdWx0LCBidXQgaWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKPj4gKyMgZmFpbCBv
ciBoYW5nLCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQuCj4+
ICtHSVRfSFRUUCDCoCDCoCDCoCDCoCDCoCDCoDo9IEBnaXRodHRwQAo+PiArCj4+ICsjIE9wdGlv
bmFsIGNvbXBvbmVudHMKPj4gK1hFTlNUQVRfWEVOVE9QIMKgIMKgIMKgOj0gQG1vbml0b3JzQAo+
PiArVlRQTV9UT09MUyDCoCDCoCDCoCDCoCDCoDo9IEB2dHBtQAo+PiArTElCWEVOQVBJX0JJTkRJ
TkdTIMKgOj0gQHhhcGlACj4+ICtQWVRIT05fVE9PTFMgwqAgwqAgwqAgwqA6PSBAcHl0aG9udG9v
bHNACj4+ICtPQ0FNTF9UT09MUyDCoCDCoCDCoCDCoCA6PSBAb2NhbWx0b29sc0AKPj4gK0NPTkZJ
R19NSU5JVEVSTSDCoCDCoCA6PSBAbWluaXRlcm1ACj4+ICtDT05GSUdfTE9NT1VOVCDCoCDCoCDC
oDo9IEBsb21vdW50QAo+PiArCj4+ICsjU3lzdGVtIG9wdGlvbnMKPj4gK0NPTkZJR19TWVNURU1f
TElCQUlPOj0gQHN5c3RlbV9haW9ACj4+ICtDT05GSUdfTElCSUNPTlYgwqAgwqAgOj0gQGxpYmlj
b252QAo+PiArQ09ORklHX0dDUllQVCDCoCDCoCDCoCA6PSBAbGliZ2NyeXB0QAo+PiArQ09ORklH
X0VYVDJGUyDCoCDCoCDCoCA6PSBAbGliZXh0MmZzQAo+PiBkaWZmIC1yIDQwODZlNDgxMTU0NyAt
ciBlMTJlYzEwNzE0MTAgY29uZmlndXJlLmFjCj4+IC0tLSAvZGV2L251bGwgwqAgVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCj4+ICsrKyBiL2NvbmZpZ3VyZS5hYyDCoCDCoCDCoFNhdCBK
YW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+PiBAQCAtMCwwICsxLDE3OSBAQAo+PiArIyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCAtKi0gQXV0b2NvbmYgLSotCj4+ICsjIFByb2Nlc3MgdGhpcyBmaWxlIHdpdGggYXV0
b2NvbmYgdG8gcHJvZHVjZSBhIGNvbmZpZ3VyZSBzY3JpcHQuCj4+ICsKPj4gK0FDX1BSRVJFUShb
Mi42N10pCj4KPiBUaGlzIGlzIHRoZSB2ZXJzaW9uIGluIERlYmlhbiBzdGFibGUgd2hpY2ggaXMg
bXkgcnVsZSBvZiB0aHVtYiBmb3IgaG93Cj4gZmFyIGJhY2sgdG8gc3VwcG9ydCB0aGluZ3MgYXMg
YSBtaW5pbXVtLgo+Cj4gSG93ZXZlciBkbyB3ZSByZWx5IG9uIGZlYXR1cmVzIG9mIDIuNjcgb3Ig
Y291bGQgd2UgZ28gb2xkZXIgaWYgc29tZW9uZQo+IGhhcyBhbiBvbGRlciB2ZXJzaW9uPwoKQUNf
UFJFUkVRIGlzIGF1dG9tYXRpY2FsbHkgc2V0IGJ5IGF1dG9zY2FuIGJhc2VkIG9uIHRoZSB1c2Vk
IHZlcnNpb24uCkkndmUgZ2VuZXJhdGVkIHRoaXMgd2l0aCAyLjY4LCBhbmQgY2hhbmdlZCB0aGUg
QUNfUFJFUkVRIHRvIDIuNjcKYmVjYXVzZSBJIGtuZXcgdGhhdCB5b3Ugd2hlcmUgZ29pbmcgdG8g
Y2hlY2sgZGViaWFuIHN0YWJsZSB2ZXJzaW9uLgpJJ3ZlIHRlc3RlZCB0aGlzIHVuZGVyIDIuNjcg
d2l0aCBEZWJpYW4gYW5kIGl0IHdvcmtzIGZpbmUsIGJ1dCBJIGRvbid0Cmtub3cgYWJvdXQgb2xk
ZXIgdmVyc2lvbnMuCgo+PiArQUNfSU5JVChbWGVuIEh5cGVydmlzb3JdLCBbNC4yXSwgW3hlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tXSkKPgo+IElkZWFsbHkgdGhlIDQuMiB3b3VsZCBub3Qg
YmUgZHVwbGljYXRlZCBib3RoIGhlcmUgYW5kIGluIHhlbi9NYWtlZmlsZS4KPiBJJ20gbm90IHN1
cmUgaG93IHRoaXMgY2FuIGJlIHJlc29sdmVkIHdpdGhvdXQgY29uZmxpY3Rpbmcgd2l0aCBKYW4n
cwo+IChxdWl0ZSByZWFzb25hYmxlKSBkZXNpcmUgbm90IHRvIG5lZWQgLi9jb25maWd1cmUgZm9y
IHRoZSBoeXBlcnZpc29yLgo+Cj4gSSBzdXBwb3NlIGl0IG11c3QgYmUgcG9zc2libGUgdmlhIHRo
ZSBtYWdpYyBvZiBtNCB0byBwdWxsIG91dCB0aGUKPiB2ZXJzaW9uIGZyb20gdGhlIE1ha2VmaWxl
IGFuZCBpbmNsdWRlIGl0IGhlcmUuCgpQcm9iYWJseSB3aXRoIHNvbWUgbTQgYW5kIHNoZWxsIHNj
cmlwdGluZwoKPiBJIGRpZG4ndCByZXZpZXcgYWxsIHRoZSB0ZXN0cyBpbiBkZXRhaWwsIEkgcHJl
c3VtZSB3ZSdsbCBlbmQgdXAgaGF2aW5nCj4gdG8gZmluZCBhIGJ1bmNoIG9mIHRob3NlIGVycm9y
cyB2aWEgdGVzdGluZyBhbnl3aGVyZS4KPgo+IERvZXMgdGhlIHNldCBvZiB0ZXN0cyBoZXJlIHBy
ZWNpc2VseSBlcXVhbCB0aG9zZSBjdXJyZW50bHkgZG9uZSBieQo+IHRvb2xzL2NoZWNrIChvciBl
bHNld2hlcmUpIG9yIGRpZCB5b3UgYWRkIG1vcmUgYXMgeW91IHdlbnQ/CgpJJ3ZlIG1vdmVkIGFs
bCB0b29scy9jaGVjaywgYW5kIGFkZGVkIGEgdGVzdCBmb3IgbGliaWNvbnYgYW5kCnlhamwveWFq
bF92ZXJzaW9uLmguCgo+IEl0IG1pZ2h0Cj4gaGF2ZSBiZWVuIGJldHRlciBmb3IgcmV2aWV3IHRv
IHByZXNlbnQgdGhpcyBhcyBhIGJhc2ljIGluZnJhc3RydWN0dXJlCj4gcGF0Y2gsIHRoZSBjb252
ZXJzaW9uIG9mIGVhY2ggdGVzdCBpbmRpdmlkdWFsbHkgYXMgYSBwYXRjaCBlYWNoIGFuZAo+IGxh
c3RseSBhbnkgbmV3IHRlc3RzIGV0YyBzbyB3ZSBjb3VsZCBlYXNpbHkgcmV2aWV3LiBCdXQgSSB0
aGluayBpdCdzIGEKPiBiaXQgbGF0ZSBub3cgYW5kIHRoZXJlJ3Mgbm8gcG9pbnQgc3BsaXR0aW5n
IHRoaXMgcGF0Y2ggdXAgbm93IHlvdSd2ZSBnb3QKPiBpdC4KCkVhY2ggdGVzdCBoYXMgaXQncyBv
d24gbTQgZmlsZSBpbnNpZGUgbTQvLCBpZiBpdCdzIHJlYWxseSBkaWZmaWN1bHQgdG8KdW5kZXJz
dGFuZCAobTQgaXMgbm90IGVhc3kgZm9yIHRoZSBleWUsIGFsdGhvdWdoIEkgdHJpZWQgdG8gZm9s
bG93CmxpYnhsIENPRElOR19TVFlMRSksIEkgd2lsbCBzcGxpdCBpdCB1cCBpbiBzZXZlcmFsIHBh
dGNoZXMgKG9uZSBmb3IKZWFjaCBtNC8gYW5kIG9uZSBmb3IgdGhlIHJlc3Qgb2YgdGhlIGF1dG90
b29scyBpbmZyYXN0cnVjdHVyZSkuCgo+Cj4+ICtBQ19DT05GSUdfU1JDRElSKFt0b29scy9saWJ4
bC9saWJ4bC5jXSkKPj4gK0FDX0NPTkZJR19IRUFERVJTKFtjb25maWcuaF0pCj4+ICtBQ19DT05G
SUdfRklMRVMoW2NvbmZpZy9BdXRvY29uZi5ta10pCj4+ICtBQ19QUkVGSVhfREVGQVVMVChbL3Vz
cl0pCj4+ICsKPj4gKyMgQ2hlY2sgaWYgQ0ZMQUdTLCBMREZMQUdTLCBMSUJTLCBDUFBGTEFHUyBv
ciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdhcm5pbmcKPj4gKwo+PiArQVNfSUYoW3Rlc3QgLW4g
IiRDQyRDRkxBR1MkTERGTEFHUyRMSUJTJENQUEZMQUdTJENQUCJdLCBbCj4+ICsgwqAgwqBBQ19N
U0dfV0FSTigKPj4gK1tTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdT
IG9yIENQUCBpcyBub3QgXAo+PiArcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQ
UkVQRU5EX0xJQiwgXAo+PiArQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQg
d2hlbiBwb3NzaWJsZS5dKQo+PiArXSkKPj4gKwo+PiArQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05T
Cj4+ICtBQ19DQU5PTklDQUxfSE9TVAo+PiArCj4+ICsjIE00IE1hY3JvIGluY2x1ZGVzCj4+ICtt
NF9pbmNsdWRlKFttNC9lbmFibGVfZmVhdHVyZS5tNF0pCj4+ICttNF9pbmNsdWRlKFttNC9kaXNh
YmxlX2ZlYXR1cmUubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvcGF0aF9vcl9mYWlsLm00XSkKPj4g
K200X2luY2x1ZGUoW200L3B5dGhvbl94bWwubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvcHl0aG9u
X3ZlcnNpb24ubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvcHl0aG9uX2RldmVsLm00XSkKPj4gK200
X2luY2x1ZGUoW200L3VkZXYubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvb2NhbWwubTRdKQo+PiAr
bTRfaW5jbHVkZShbbTQvZGVmYXVsdF9saWIubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvc2V0X2Nm
bGFnc19sZGZsYWdzLm00XSkKPj4gKwo+PiArIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCj4+ICtB
WF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hzbV0sCj4+ICsgwqAgwqBbRW5hYmxlIFhTTSBzZWN1
cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKV0pCj4KPiBEb2VzIHRoaXMgbWFjcm8gaW5j
bHVkZSBzdXBwb3J0IGZvciByZWFkaW5nIGZyb20gY29uZmlnLmNhY2hlIGFzIHdlbGwgYXMKPiB0
aGUgY21kbGluZSBvcHRpb24/CgpUaGV5IHdlcmVuJ3QgYnV0IEkndmUgYWRkZWQgc3VwcG9ydCBh
bmQgdGhleSBhcmUgY2FjaGVkIG5vdyAocHJvdmlkZWQKdGhhdCB5b3UgcnVuIGNvbmZpZ3VyZSB3
aXRoIC0tY29uZmlnLWNhY2hlKS4KCj4KPiBbLi4uXQo+PiArQVNfSUYoW3Rlc3QgIngkb2NhbWx0
b29scyIgPSAieHkiXSwgWwo+PiArIMKgIMKgQUNfUFJPR19PQ0FNTAo+PiArIMKgIMKgQVNfSUYo
W3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwgWwo+PiArIMKgIMKgIMKgQUNfTVNHX0VSUk9SKFtZ
b3UgbXVzdCBpbnN0YWxsIHRoZSBPQ2FtbCBjb21waWxlcl0pCj4KPiBvY2FtbCB3YXMgcHJldmlv
dXNseSBvcHRpb25hbCwgSSB0aGluay4KCk9rLCBJIHdpbGwgc2V0IHRvIGRpc2FibGVkIGJ5IGRl
ZmF1bHQgdGhlbi4KCj4KPiBbLi4uXQo+PiArCj4+ICsjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVz
Lgo+PiArQUNfRlVOQ19BTExPQ0EKPj4gK0FDX0NIRUNLX0hFQURFUlMoWyBcCj4+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqBhcnBhL2luZXQuaCBmY250bC5oIGludHR5cGVzLmggbGliaW50bC5o
IGxpbWl0cy5oIG1hbGxvYy5oIFwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5ldGRiLmgg
bmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKPj4gKyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0bC5oIHN5
cy9tb3VudC5oIHN5cy9wYXJhbS5oIFwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHN5cy9z
b2NrZXQuaCBzeXMvc3RhdHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgXSkKPj4gKwo+PiArIyBDaGVja3MgZm9yIHR5cGVk
ZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgo+PiArQUNfSEVB
REVSX1NUREJPT0wKPj4gK0FDX1RZUEVfVUlEX1QKPj4gK0FDX0NfSU5MSU5FCj4+ICtBQ19UWVBF
X0lOVDE2X1QKPj4gK0FDX1RZUEVfSU5UMzJfVAo+PiArQUNfVFlQRV9JTlQ2NF9UCj4+ICtBQ19U
WVBFX0lOVDhfVAo+Cj4gVGhlcmUncyBubyBBQ19UWVBFX1NURElOVCBvciBzaW1pbGFyPwoKVGhp
cyB3YXMgYXV0b21hdGljYWxseSBkb25lIGJ5IGF1dG9zY2FuLCBhbmQgSSd2ZSB0cmllZCBzZWFy
Y2hpbmcgZm9yCnNvbWV0aGluZyBsaWtlIEFDX1RZUEVfU1RESU5ULCBidXQgSSBoYXZlbid0IGJl
ZW4gYWJsZSB0byBmaW5kCmFueXRoaW5nLiBJZiB5b3Ugd2FudCBJIGNhbiBidW5kbGUgdGhlIElO
VCBjaGVja3MgaW5zaWRlIGEgbWFjcm8KY2FsbGVkIEFYX1RZUEVfU1RESU5ULgoKPgo+PiArQUNf
VFlQRV9NT0RFX1QKPj4gK0FDX1RZUEVfT0ZGX1QKPj4gK0FDX1RZUEVfUElEX1QKPj4gK0FDX0Nf
UkVTVFJJQ1QKPj4gK0FDX1RZUEVfU0laRV9UCj4+ICtBQ19UWVBFX1NTSVpFX1QKPgo+IElzIHRo
ZXJlIG5vdCBzb21lIHVtYnJlbGxhIHRlc3QgZm9yIHRoZXNlIHNvcnRzIG9mIHZlcnkgc3RhbmRh
cmQgdGhpbmdzLAo+IGUuZy4gQUNfUE9TSVggb3Igc29tZXRoaW5nIGxpa2UgdGhhdD8KCkFnYWlu
LCB0aGUgc2FtZSBhcyBhYm92ZS4KCj4KPj4gK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0
LnN0X2Jsa3NpemVdKQo+PiArQUNfU1RSVUNUX1NUX0JMT0NLUwo+PiArQUNfQ0hFQ0tfTUVNQkVS
Uyhbc3RydWN0IHN0YXQuc3RfcmRldl0pCj4+ICtBQ19UWVBFX1VJTlQxNl9UCj4+ICtBQ19UWVBF
X1VJTlQzMl9UCj4+ICtBQ19UWVBFX1VJTlQ2NF9UCj4+ICtBQ19UWVBFX1VJTlQ4X1QKPj4gK0FD
X0NIRUNLX1RZUEVTKFtwdHJkaWZmX3RdKQo+PiArCj4+ICsjIENoZWNrcyBmb3IgbGlicmFyeSBm
dW5jdGlvbnMuCj4+ICtBQ19GVU5DX0VSUk9SX0FUX0xJTkUKPj4gK0FDX0ZVTkNfRk9SSwo+PiAr
QUNfRlVOQ19GU0VFS08KPj4gK0FDX0ZVTkNfTFNUQVRfRk9MTE9XU19TTEFTSEVEX1NZTUxJTksK
Pj4gK0FDX0hFQURFUl9NQUpPUgo+PiArQUNfRlVOQ19NQUxMT0MKPj4gK0FDX0ZVTkNfTUtUSU1F
Cj4+ICtBQ19GVU5DX01NQVAKPj4gK0FDX0ZVTkNfUkVBTExPQwo+PiArQUNfRlVOQ19TVFJOTEVO
Cj4+ICtBQ19GVU5DX1NUUlRPRAo+PiArQUNfQ0hFQ0tfRlVOQ1MoWyBcCj4+ICsgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRh
c3luYyBmdHJ1bmNhdGUgXAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ2V0Y3dkIGdldGhv
c3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKPj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBt
ZW1tb3ZlIG1lbXNldCBta2RpciBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBta2ZpZm8g
bXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1kaXIgc2VsZWN0IHNldGVudiBcCj4+
ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3Nw
biBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBz
dHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0b3VsbCB0enNl
dCBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1bmFtZSBcCj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqBdKQo+PiArCj4+ICtBQ19PVVRQVVQoKQo+PiBkaWZmIC1yIDQwODZlNDgxMTU0
NyAtciBlMTJlYzEwNzE0MTAgbTQvZGVmYXVsdF9saWIubTQKPj4gLS0tIC9kZXYvbnVsbCDCoCBU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKPj4gKysrIGIvbTQvZGVmYXVsdF9saWIubTQg
U2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCj4+IEBAIC0wLDAgKzEsNyBAQAo+PiArQUNf
REVGVU4oW0FYX0RFRkFVTFRfTElCXSwKPj4gK1tBU19JRihbdGVzdCAtZCAiJHByZWZpeC9saWI2
NCJdLCBbCj4+ICsgwqAgwqBMSUJfUEFUSD0ibGliNjQiCj4+ICtdLFsKPj4gKyDCoCDCoExJQl9Q
QVRIPSJsaWIiCj4+ICtdKQo+PiArQUNfU1VCU1QoTElCX1BBVEgpXSkKPgo+IERvZXMgdGhpcyBn
ZXQgZXhwb3NlZCB2aWEgY29uZmlnLmNhY2hlIGFuZC9vciB0aGUgY29tbWFuZCBsaW5lPyBJdAo+
IHNob3VsZCBiZS4KPgo+IERpZCB5b3Ugd3JpdGUgbTQvKiBmcm9tIHNjcmF0Y2ggb3IgZGlkIHRo
ZXkgY29tZSBmcm9tIHNvbWUgc25pcHBldAo+IGxpYnJhcnk/CgpUaGUgb25seSBvbmUgdGhhdCBj
b21lcyBmcm9tIGEgbGlicmFyeSBpcyBvY2FtbC5tNCwgdGhlIG90aGVyIG9uZXMgYXJlCmhhbmQt
d3JpdHRlbi4gTW9zdCBhcmUgdHJhbnNsYXRpb25zIG9mIHRvb2xzL2NoZWNrL2NoZWNrXyosIGFu
ZCB0aGUKcmVzdCBhcmUgYSBjb3VwbGUgb2YgaGFuZGZ1bCBtYWNyb3MgdGhhdCBhdm9pZCByZXBl
YXRpbmcgY29kZSBibG9ja3MKYWxsIG92ZXIuCgo+Cj4gSXNuJ3QgdGhlIG1hbmFnZW1lbnQgb2Yg
dGhlc2Ugc25pcHBldHMgdGhlIHNvcnQgb2YgdGhpbmcgYWNsb2NhbCBkb2VzCj4gZm9yIHlvdT8K
CmFjbG9jYWwganVzdCBzY2FucyBjb25maWd1cmUuYWMgYW5kIGNvbmNhdGVuYXRlcyBhbGwgbmVj
ZXNzYXJ5IG1hY3JvcwppbnRvIGFjbG9jYWwubTQsIEkndmUgdHJpZWQgdG8gdXNlIGFsbCB0aGUg
cHJlZGVmaW5lZCBtYWNyb3MgSSBjb3VsZCwKYW5kIG1vc3Qgb2YgdGhlIGZpbGVzIGluc2lkZSBt
NC8qIGFyZSBqdXN0IHdyYXBwZXJzIHRvIG1ha2UKY29uZmlndXJlLmFjIGNsZWFuZXIgYW5kIGVh
c2llciB0byB1bmRlcnN0YW5kLgoKPgo+PiBcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKPgo+
IE1pZ2h0IHRoaXMgbmV3bGluZSBiZSBzaWduaWZpY2FudCBpbiBhIG1hY3JvIGV4cGFuc2lvbiBs
aWJyYXJ5PyBJIHRoaW5rCj4gaXQncyBnb29kIHByYWN0aWNlIHRvIGluY2x1ZGUgaXQgYW55d2F5
IChoZXJlIGFuZCBlbHNld2hlcmUpLgoKWXVwLCBJJ3ZlIGZvcmdvdC4KCj4KPiBbLi4uXQo+PiBk
aWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgbTQvb2NhbWwubTQKPj4gLS0tIC9k
ZXYvbnVsbCDCoCBUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKPj4gKysrIGIvbTQvb2Nh
bWwubTQgwqAgwqAgwqAgU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCj4+IEBAIC0wLDAg
KzEsMjQwIEBACj4+ICtkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBPQ2FtbAo+Cj4gUGxlYXNlIGFk
ZCBhIGNvbW1lbnQgZGVzY3JpYmluZyB3aGVyZSB0aGlzIGNhbWUgZnJvbSBzbyB3ZSBrbm93IGhv
dyB0bwo+IHVwZGF0ZSBpbiB0aGUgZnV0dXJlLgo+Cj4gU2hvdWxkbid0L2NvdWxkbid0IHRoaXMg
YmUgcHJvdmlkZWQgYnkgdGhlIG9jYW1sIHBhY2thZ2VzIGFuZCBqdXN0Cj4gaW5jbHVkZWQgYnkg
dXM/CgpUaGlzIGNvbWVzIGZyb20gaHR0cDovL2ZvcmdlLm9jYW1sY29yZS5vcmcvLCBhbmQgdGhl
IG1hbnBhZ2Ugc3RhdGVzIHRoYXQ6CgoiVG8gYmVnaW4gdXNpbmcgdGhlc2UgbWFjcm9zLCB5b3Ug
d2lsbCBuZWVkIHRvIGNvcHkgdGhlIG9jYW1sLm00IGZpbGUKKHVzdWFsbHkgbG9jYXRlZCBhdCAv
dXNyL3NoYXJlL2FjbG9jYWwvb2NhbWwubTQpIHRvIHRoZSBhdXRvY29uZgptYWNyb3MgZGlyZWN0
b3J5IGluIHlvdXIgcHJvamVjdC4gTm9ybWFsbHkgdGhpcyBpcyB0aGUgbTQvIGRpcmVjdG9yeQpp
biB5b3VyIHByb2plY3QsIGJ1dCB0aGUgZGlyZWN0b3J5IGNhbiBiZSBjaGFuZ2VkIHVzaW5nIHRo
ZQpBQ19DT05GSUdfTUFDUk9fRElSKERJUikgZGlyZWN0aXZlLiIKClRoYXQncyB3aHkgSSBjb3Bp
ZWQgaXQgdG8gbTQvCgo+Cj4gWy4uLl0KPgo+IElhbi4KPgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 09 13:52:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 13: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 1RkFdg-0007qp-CH; Mon, 09 Jan 2012 13:51: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 1RkFdf-0007qh-1H
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 13:51:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326117083!52056695!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 31775 invoked from network); 9 Jan 2012 13:51:24 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 13:51:24 -0000
Received: by daec6 with SMTP id c6so15248050dae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 05:51: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=6qJ0rFWXLzWzEP7u43PPzUKm7Lrubl1jEGF6bi7xgx4=;
	b=WC7eEgVxwrf8012ygFiqI+qmhN/1tc4FAzhMVSQYTn78ZHkO1A0A8msMBDUluqI8JO
	mvOj21a7MWNUal73GzPGbOqnT0FXuPdXvSZ2UxAGTqU6f2OhkFi6o7aY7bWdxVVnKO9N
	N4axgsz0Ea9mp5V8eAeoDLLoHdzQj6rK/YFAg=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr41640060pbc.77.1326117101893; Mon,
	09 Jan 2012 05:51:41 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 9 Jan 2012 05:51:41 -0800 (PST)
In-Reply-To: <1326110599.17210.81.camel@zakaz.uk.xensource.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<1326110599.17210.81.camel@zakaz.uk.xensource.com>
Date: Mon, 9 Jan 2012 14:51:41 +0100
X-Google-Sender-Auth: 8atOWyG8qkPR9VKeI7NCPqBth-Y
Message-ID: <CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzkgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46Cj4gT24gU2F0
LCAyMDEyLTAxLTA3IGF0IDAzOjIwICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6Cj4+ICMg
SEcgY2hhbmdlc2V0IHBhdGNoCj4+ICMgVXNlciBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBl
bnRlbC51cGMuZWR1Pgo+PiAjIERhdGUgMTMyNTkwNjIzMCAtMzYwMAo+PiAjIE5vZGUgSUQgZTEy
ZWMxMDcxNDEwYzk0NjM2N2NiMDUwOGNmMjE4YTBjM2I1OTZjYQo+PiAjIFBhcmVudCDCoDQwODZl
NDgxMTU0N2RkZmZiOWE1M2ZiZjJlZmI2YzJmYTQzNmI3MGEKPj4gYnVpbGQ6IGFkZCBhdXRvY29u
ZiB0byByZXBsYWNlIGN1c3RvbSBjaGVja3MgaW4gdG9vbHMvY2hlY2sKPj4KPj4gQWRkZWQgYXV0
b3Rvb2xzIG1hZ2ljIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrIHNjcmlwdHMuIFRoZSBwcmV2aW91
cwo+PiBjaGVja3MgaGF2ZSBiZWVuIHBvcnRlZCB0byBhdXRvY29uZiwgYW5kIHNvbWUgYWRkaXRp
b25hbCBvbmVzIGhhdmUKPj4gYmVlbiBhZGRlZCAocGx1cyB0aGUgc3VnZ2VzdGlvbnMgZnJvbSBy
dW5uaW5nIGF1dG9zY2FuKS4gVHdvIGZpbGVzIGFyZQo+PiBjcmVhdGVkIGFzIGEgcmVzdWx0IGZy
b20gZXhlY3V0aW5nIGNvbmZpZ3VyZSBzY3JpcHQsCj4+IGNvbmZpZy9BdXRvY29uZi5tayBhbmQg
Y29uZmlnLmguCj4+Cj4+IEF1dG9jb25mLm1rIGlzIGluY2x1ZGVkIGJ5IENvbmZpZy5taywgYW5k
IGNvbnRhaW5zIG1vc3Qgb2YgdGhlCj4+IG9wdGlvbnMgcHJldmlvdXNseSBkZWZpbmVkIGluIC5j
b25maWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwo+PiBwYXJhbWV0ZXJzIG9yIGRlZmlu
aW5nIGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBjb25maWd1cmUKPj4gc2Ny
aXB0Lgo+Pgo+PiBjb25maWcuaCBpcyBzdGlsbCBub3QgdXNlZCBhbnl3aGVyZSwgYW5kIGlzIGF1
dG9tYXRpY2FsbHkgY3JlYXRlZCBieQo+PiBhdXRvaGVhZGVyLCBhbHRvdWdoIHRoaXMgbWlnaCBj
aGFuZ2Ugd2hlbiB3ZSBzdGFydCB0byBpbmNsdWRlIHRoaXMKPj4gZmlsZS4KPj4KPj4gSnVzdCBh
IGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBJaXQncyBteSBmaXJzdCBhdXRvY29uZiBzY3JpcHQg
SSBndWVzcwo+PiB0aGVyZSB3aWxsIGJlIG1hbnkgdGhpbmdzIHRvIHBvbGlzaCBoZXJlLi4uIFBs
ZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuCj4+Cj4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBN
b25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4KPiBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQg
dG8gc2VlIGFuIHVwZGF0ZSB0byB0aGUgY2xlYW4vZGlzdGNsZWFuIHJ1bGVzCj4gYW5kIC5oZ2ln
bm9yZSBkdWUgdG8gYWxsIHRoZSBuZXcgZ2VuZXJhdGVkIGZpbGVzLgoKWWVzLCBJIHdhcyBnb2lu
ZyB0byBkbyB0aGF0IHdoZW4gd2UgYWdyZWUgb24gd2VyZSBzaG91bGQgdGhpbmdzCnJlc2lkZSwg
dGhhdCdzIHdoeSBJIGRpZG4ndCBpbmNsdWRlIGFueSBvZiB0aGlzIG9uIHRoZSBwYXRjaC4KCj4+
IGRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBSRUFETUUKPj4gLS0tIGEvUkVB
RE1FIMKgIMKgVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCj4+ICsrKyBiL1JFQURNRSDC
oCDCoFNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+PiBAQCAtODcsOSArODcsMTUgQEAg
Mi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0ZXZlciB5b3Ugcwo+PiDCoDMuIEZvciB0aGUg
dmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJveSBidWlsZCB0cmVlcywK
Pj4gwqAgwqAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgo+PgoKVGhpcyB3aWxsIGJlIGxp
a2U6CgojIGFjbG9jYWwgJiYgYXV0b21ha2UgLWEKCj4+ICsgwqAgwqAjIGF1dG9tYWtlIC1hCj4K
PiBXZSBhcmVuJ3QgdXNpbmcgYXV0b21ha2UgdGhvdWdoPyBQZXJoYXBzIHRoaXMgZXhwbGFpbnMg
eW91ciBwcm9ibGVtIHdpdGgKPiB0aGluZ3MgYWx3eWFzIHRyeWluZyB0byB1c2UgTWFrZWZpbGUu
YW0/CgpXZSBuZWVkIHRvIHJ1biBhdXRvbWFrZSwgYmVjYXVzZSBpdCBnZW5lcmF0ZXMgY29uZmln
LnN1YiBhbmQKY29uZmlnLmd1ZXNzLCB3aGljaCBpcyBuZWVkZWQgZm9yIGNlcnRhaW4gYXV0b2Nv
bmYgdGVzdHMuIFRoZSBwcm9ibGVtCmlzIHRoYXQgSSBkb24ndCBrbm93IGhvdyB0byBjYWxsIGF1
dG9tYWtlIHRvIG9ubHkgZ2VuZXJhdGUgdGhvc2UgZmlsZXMKYW5kIGRvbid0IHRyeSB0byBwYXJz
ZSBNYWtlZmlsZS5hbSwgYmVjYXVzZSBhdXRvbWFrZSB0cmllcyB0byBwYXJzZQpNYWtlZmlsZS5h
bSBhbmQgZXhpdHMgd2l0aCBhbiBlcnJvciBjb2RlLCB0aGF0J3MgYWxzbyBwcmV2ZW50aW5nIG1l
CmZyb20gdXNpbmcgYXV0b3JlY29uZiBhbmQgZm9yZ2V0IGFib3V0IGNhbGxpbmcgYWNsb2NhbCwg
YXV0b21ha2UsCmF1dG9oZWFkZXIuLi4gc2VwYXJhdGVseS4gSSB3YXMgaG9waW5nIHRoYXQgc29t
ZSBhdXRvdG9vbHMgZXhwZXJ0IGhhcwphIHNvbHV0aW9uIGZvciB0aGlzIChJIHdpbGwga2VlcCBz
ZWFyY2hpbmcgYWxzbykuCgo+PiArIMKgIMKgIyBhdXRvaGVhZGVyICYmIGF1dG9jb25mCj4KPiBX
aGF0IGRvZXMgYXV0b2hlYWRlciBkbz8gVGhpcyBzaG91bGQgYmUgY2xlYXJseSBub3RlZCBhcyBi
ZWluZyBvbmx5Cj4gbmVjZXNzYXJ5IGlmIGJ1aWxkaW5nIGZyb20gaGcgYW5kIG5vdCBpZiB5b3Ug
YXJlIGJ1aWxkaW5nIGZyb20gdGFyYmFsbC4KPiBJIGV4cGVjdCB3ZSBhbHNvIG5lZWQgc29tZSBt
YWtlZmlsZSBydW5lcyBvciBwcm9jZXNzIHVwZGF0ZXMgdG8gbWFrZQo+IHN1cmUgdGhlIGdlbmVy
YXRlZCBzdHVmZiBnZXRzIGluY2x1ZGVkIGluIHRoZSB0YXJiYWxsLgoKYXV0b2hlYWRlciBjcmVh
dGVzIGEgZ2VuZXJpYyBjb25maWcuaC5pbiB3aGljaCBjb250YWlucyBkZWZpbmVzIGZvcgphbGwg
dGhlIGV4cG9ydGVkIHZhcmlhYmxlcy4gV2UgY291bGQgY3JlYXRlIG91ciBvd24gY29uZmlnLmgu
aW4gYW5kCmRvbid0IHJ1biBhdXRvaGVhZGVyLCBidXQgSSB0aGluayB0aGUgZ2VuZXJhdGVkIGZp
bGUgaXMgZmluZS4KCj4KPiBZb3UgbmVlZCB0byBhZGQgdGhlIHJlbGV2YW50IHBhY2thZ2VzIHRv
IHRoZSBsaXN0IG9mIGJ1aWxkIHJlcXVpcmVtZW50cy4KCk9rLCB3aWxsIG1ha2UgYSBsaXN0Cgo+
PiArIMKgIMKgIyAuL2NvbmZpZ3VyZQo+PiDCoCDCoCDCoCMgbWFrZSB3b3JsZAo+PiDCoCDCoCDC
oCMgbWFrZSBpbnN0YWxsCj4+Cj4+ICsgwqAgSWYgeW91IHdhbnQsIHlvdSBjYW4gcnVuIC4vY29u
ZmlndXJlIC0taGVscCB0byBzZWUgdGhlIGxpc3Qgb2YKPj4gKyDCoCBvcHRpbnMgYXZhaWxhYmxl
IG9wdGlvbnMgd2hlbiBidWlsZGluZyBhbmQgaW5zdGFsbGluZyBYZW4uCj4KPiDCoCDCoCDCoG9w
dGlvbnMKCkFsc28gT2sgd2hlbiB3ZSBkZWNpZGUgdGhlIGRlZmluaXRpdmUgb3B0aW9ucy4KCj4+
ICsKPj4gwqAgwqAgVGhpcyB3aWxsIGNyZWF0ZSBhbmQgaW5zdGFsbCBvbnRvIHRoZSBsb2NhbCBt
YWNoaW5lLiBJdCB3aWxsIGJ1aWxkCj4+IMKgIMKgIHRoZSB4ZW4gYmluYXJ5ICh4ZW4uZ3opLCB0
aGUgdG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0aW9uLgo+Pgo+PiBkaWZmIC1yIDQwODZlNDgxMTU0
NyAtciBlMTJlYzEwNzE0MTAgY29uZmlnL0F1dG9jb25mLm1rLmluCj4+IC0tLSAvZGV2L251bGwg
wqAgVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCj4+ICsrKyBiL2NvbmZpZy9BdXRvY29u
Zi5tay5pbiDCoCDCoCBTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKPj4gQEAgLTAsMCAr
MSw0OSBAQAo+PiArIyBQcmVmaXggYW5kIGluc3RhbGwgZm9sZGVyCj4+ICtQUkVGSVggwqAgwqAg
wqAgwqAgwqAgwqAgwqA6PSBAcHJlZml4QAo+PiArTElCTEVBRkRJUl94ODZfNjQgwqAgOj0gQExJ
Ql9QQVRIQAo+PiArCj4+ICsjIEEgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29scz8KPj4gK2Rl
YnVnIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDo9IEBkZWJ1Z0AKPj4gKwo+PiArIyBUb29scyBwYXRo
Cj4+ICtCSVNPTiDCoCDCoCDCoCDCoCDCoCDCoCDCoCA6PSBAQklTT05ACj4+ICtGTEVYIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgOj0gQEZMRVhACj4+ICtQWVRIT04gwqAgwqAgwqAgwqAgwqAgwqAg
wqA6PSBAUFlUSE9OQAo+PiArUEVSTCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDo9IEBQRVJMQAo+
PiArQlJDVEwgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOj0gQEJSQ1RMQAo+PiArSVAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqA6PSBASVBACj4+ICtDVVJMLUNPTkZJRyDCoCDCoCDCoCDCoCA6PSBA
Q1VSTEAKPgo+IEFyZSBoeXBoZW5zIG9rIGluIG1ha2UgdmFyaWFibGVzPwoKTG9va3MgbGlrZSwg
YnV0IEkgd2lsbCByZXBsYWNlIHRoZW0gd2l0aCB1bmRlcnNjb3JlcyAoXykgdG8gYmUgb24gdGhl
IHNhZmUgc2lkZS4KCj4KPj4gK1hNTDItQ09ORklHIMKgIMKgIMKgIMKgIDo9IEBYTUxACj4+ICtC
QVNIIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgOj0gQEJBU0hACj4+ICtYR0VUVFRFWFQgwqAgwqAg
wqAgwqAgwqAgOj0gQFhHRVRURVhUQAo+PiArCj4+ICsjIEV4dHJhIGZvbGRlciBmb3IgbGlicy9p
bmNsdWRlcwo+PiArUFJFUEVORF9JTkNMVURFUyDCoCDCoDo9IEBQUkVQRU5EX0lOQ0xVREVTQAo+
PiArUFJFUEVORF9MSUIgwqAgwqAgwqAgwqAgOj0gQFBSRVBFTkRfTElCQAo+PiArQVBQRU5EX0lO
Q0xVREVTIMKgIMKgIDo9IEBBUFBFTkRfSU5DTFVERVNACj4+ICtBUFBFTkRfTElCIMKgIMKgIMKg
IMKgIMKgOj0gQEFQUEVORF9MSUJACj4+ICsKPj4gKyMgRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1
bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKS4KPj4gK1hTTV9FTkFCTEUgwqAgwqAgwqAgwqAgwqA6PSBA
eHNtQAo+PiArRkxBU0tfRU5BQkxFIMKgIMKgIMKgIMKgOj0gQHhzbUAKPj4gKwo+PiArIyBEb3du
bG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8KPj4g
KyMgR0lUJ3MgcHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3Jr
cyBhdCBhbGwgKGZpcmV3YWxscwo+PiArIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBk
ZWZhdWx0LCBidXQgaWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKPj4gKyMgZmFpbCBv
ciBoYW5nLCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQuCj4+
ICtHSVRfSFRUUCDCoCDCoCDCoCDCoCDCoCDCoDo9IEBnaXRodHRwQAo+PiArCj4+ICsjIE9wdGlv
bmFsIGNvbXBvbmVudHMKPj4gK1hFTlNUQVRfWEVOVE9QIMKgIMKgIMKgOj0gQG1vbml0b3JzQAo+
PiArVlRQTV9UT09MUyDCoCDCoCDCoCDCoCDCoDo9IEB2dHBtQAo+PiArTElCWEVOQVBJX0JJTkRJ
TkdTIMKgOj0gQHhhcGlACj4+ICtQWVRIT05fVE9PTFMgwqAgwqAgwqAgwqA6PSBAcHl0aG9udG9v
bHNACj4+ICtPQ0FNTF9UT09MUyDCoCDCoCDCoCDCoCA6PSBAb2NhbWx0b29sc0AKPj4gK0NPTkZJ
R19NSU5JVEVSTSDCoCDCoCA6PSBAbWluaXRlcm1ACj4+ICtDT05GSUdfTE9NT1VOVCDCoCDCoCDC
oDo9IEBsb21vdW50QAo+PiArCj4+ICsjU3lzdGVtIG9wdGlvbnMKPj4gK0NPTkZJR19TWVNURU1f
TElCQUlPOj0gQHN5c3RlbV9haW9ACj4+ICtDT05GSUdfTElCSUNPTlYgwqAgwqAgOj0gQGxpYmlj
b252QAo+PiArQ09ORklHX0dDUllQVCDCoCDCoCDCoCA6PSBAbGliZ2NyeXB0QAo+PiArQ09ORklH
X0VYVDJGUyDCoCDCoCDCoCA6PSBAbGliZXh0MmZzQAo+PiBkaWZmIC1yIDQwODZlNDgxMTU0NyAt
ciBlMTJlYzEwNzE0MTAgY29uZmlndXJlLmFjCj4+IC0tLSAvZGV2L251bGwgwqAgVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCj4+ICsrKyBiL2NvbmZpZ3VyZS5hYyDCoCDCoCDCoFNhdCBK
YW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+PiBAQCAtMCwwICsxLDE3OSBAQAo+PiArIyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCAtKi0gQXV0b2NvbmYgLSotCj4+ICsjIFByb2Nlc3MgdGhpcyBmaWxlIHdpdGggYXV0
b2NvbmYgdG8gcHJvZHVjZSBhIGNvbmZpZ3VyZSBzY3JpcHQuCj4+ICsKPj4gK0FDX1BSRVJFUShb
Mi42N10pCj4KPiBUaGlzIGlzIHRoZSB2ZXJzaW9uIGluIERlYmlhbiBzdGFibGUgd2hpY2ggaXMg
bXkgcnVsZSBvZiB0aHVtYiBmb3IgaG93Cj4gZmFyIGJhY2sgdG8gc3VwcG9ydCB0aGluZ3MgYXMg
YSBtaW5pbXVtLgo+Cj4gSG93ZXZlciBkbyB3ZSByZWx5IG9uIGZlYXR1cmVzIG9mIDIuNjcgb3Ig
Y291bGQgd2UgZ28gb2xkZXIgaWYgc29tZW9uZQo+IGhhcyBhbiBvbGRlciB2ZXJzaW9uPwoKQUNf
UFJFUkVRIGlzIGF1dG9tYXRpY2FsbHkgc2V0IGJ5IGF1dG9zY2FuIGJhc2VkIG9uIHRoZSB1c2Vk
IHZlcnNpb24uCkkndmUgZ2VuZXJhdGVkIHRoaXMgd2l0aCAyLjY4LCBhbmQgY2hhbmdlZCB0aGUg
QUNfUFJFUkVRIHRvIDIuNjcKYmVjYXVzZSBJIGtuZXcgdGhhdCB5b3Ugd2hlcmUgZ29pbmcgdG8g
Y2hlY2sgZGViaWFuIHN0YWJsZSB2ZXJzaW9uLgpJJ3ZlIHRlc3RlZCB0aGlzIHVuZGVyIDIuNjcg
d2l0aCBEZWJpYW4gYW5kIGl0IHdvcmtzIGZpbmUsIGJ1dCBJIGRvbid0Cmtub3cgYWJvdXQgb2xk
ZXIgdmVyc2lvbnMuCgo+PiArQUNfSU5JVChbWGVuIEh5cGVydmlzb3JdLCBbNC4yXSwgW3hlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tXSkKPgo+IElkZWFsbHkgdGhlIDQuMiB3b3VsZCBub3Qg
YmUgZHVwbGljYXRlZCBib3RoIGhlcmUgYW5kIGluIHhlbi9NYWtlZmlsZS4KPiBJJ20gbm90IHN1
cmUgaG93IHRoaXMgY2FuIGJlIHJlc29sdmVkIHdpdGhvdXQgY29uZmxpY3Rpbmcgd2l0aCBKYW4n
cwo+IChxdWl0ZSByZWFzb25hYmxlKSBkZXNpcmUgbm90IHRvIG5lZWQgLi9jb25maWd1cmUgZm9y
IHRoZSBoeXBlcnZpc29yLgo+Cj4gSSBzdXBwb3NlIGl0IG11c3QgYmUgcG9zc2libGUgdmlhIHRo
ZSBtYWdpYyBvZiBtNCB0byBwdWxsIG91dCB0aGUKPiB2ZXJzaW9uIGZyb20gdGhlIE1ha2VmaWxl
IGFuZCBpbmNsdWRlIGl0IGhlcmUuCgpQcm9iYWJseSB3aXRoIHNvbWUgbTQgYW5kIHNoZWxsIHNj
cmlwdGluZwoKPiBJIGRpZG4ndCByZXZpZXcgYWxsIHRoZSB0ZXN0cyBpbiBkZXRhaWwsIEkgcHJl
c3VtZSB3ZSdsbCBlbmQgdXAgaGF2aW5nCj4gdG8gZmluZCBhIGJ1bmNoIG9mIHRob3NlIGVycm9y
cyB2aWEgdGVzdGluZyBhbnl3aGVyZS4KPgo+IERvZXMgdGhlIHNldCBvZiB0ZXN0cyBoZXJlIHBy
ZWNpc2VseSBlcXVhbCB0aG9zZSBjdXJyZW50bHkgZG9uZSBieQo+IHRvb2xzL2NoZWNrIChvciBl
bHNld2hlcmUpIG9yIGRpZCB5b3UgYWRkIG1vcmUgYXMgeW91IHdlbnQ/CgpJJ3ZlIG1vdmVkIGFs
bCB0b29scy9jaGVjaywgYW5kIGFkZGVkIGEgdGVzdCBmb3IgbGliaWNvbnYgYW5kCnlhamwveWFq
bF92ZXJzaW9uLmguCgo+IEl0IG1pZ2h0Cj4gaGF2ZSBiZWVuIGJldHRlciBmb3IgcmV2aWV3IHRv
IHByZXNlbnQgdGhpcyBhcyBhIGJhc2ljIGluZnJhc3RydWN0dXJlCj4gcGF0Y2gsIHRoZSBjb252
ZXJzaW9uIG9mIGVhY2ggdGVzdCBpbmRpdmlkdWFsbHkgYXMgYSBwYXRjaCBlYWNoIGFuZAo+IGxh
c3RseSBhbnkgbmV3IHRlc3RzIGV0YyBzbyB3ZSBjb3VsZCBlYXNpbHkgcmV2aWV3LiBCdXQgSSB0
aGluayBpdCdzIGEKPiBiaXQgbGF0ZSBub3cgYW5kIHRoZXJlJ3Mgbm8gcG9pbnQgc3BsaXR0aW5n
IHRoaXMgcGF0Y2ggdXAgbm93IHlvdSd2ZSBnb3QKPiBpdC4KCkVhY2ggdGVzdCBoYXMgaXQncyBv
d24gbTQgZmlsZSBpbnNpZGUgbTQvLCBpZiBpdCdzIHJlYWxseSBkaWZmaWN1bHQgdG8KdW5kZXJz
dGFuZCAobTQgaXMgbm90IGVhc3kgZm9yIHRoZSBleWUsIGFsdGhvdWdoIEkgdHJpZWQgdG8gZm9s
bG93CmxpYnhsIENPRElOR19TVFlMRSksIEkgd2lsbCBzcGxpdCBpdCB1cCBpbiBzZXZlcmFsIHBh
dGNoZXMgKG9uZSBmb3IKZWFjaCBtNC8gYW5kIG9uZSBmb3IgdGhlIHJlc3Qgb2YgdGhlIGF1dG90
b29scyBpbmZyYXN0cnVjdHVyZSkuCgo+Cj4+ICtBQ19DT05GSUdfU1JDRElSKFt0b29scy9saWJ4
bC9saWJ4bC5jXSkKPj4gK0FDX0NPTkZJR19IRUFERVJTKFtjb25maWcuaF0pCj4+ICtBQ19DT05G
SUdfRklMRVMoW2NvbmZpZy9BdXRvY29uZi5ta10pCj4+ICtBQ19QUkVGSVhfREVGQVVMVChbL3Vz
cl0pCj4+ICsKPj4gKyMgQ2hlY2sgaWYgQ0ZMQUdTLCBMREZMQUdTLCBMSUJTLCBDUFBGTEFHUyBv
ciBDUFAgaXMgc2V0IGFuZCBwcmludCBhIHdhcm5pbmcKPj4gKwo+PiArQVNfSUYoW3Rlc3QgLW4g
IiRDQyRDRkxBR1MkTERGTEFHUyRMSUJTJENQUEZMQUdTJENQUCJdLCBbCj4+ICsgwqAgwqBBQ19N
U0dfV0FSTigKPj4gK1tTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdT
IG9yIENQUCBpcyBub3QgXAo+PiArcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQ
UkVQRU5EX0xJQiwgXAo+PiArQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQg
d2hlbiBwb3NzaWJsZS5dKQo+PiArXSkKPj4gKwo+PiArQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05T
Cj4+ICtBQ19DQU5PTklDQUxfSE9TVAo+PiArCj4+ICsjIE00IE1hY3JvIGluY2x1ZGVzCj4+ICtt
NF9pbmNsdWRlKFttNC9lbmFibGVfZmVhdHVyZS5tNF0pCj4+ICttNF9pbmNsdWRlKFttNC9kaXNh
YmxlX2ZlYXR1cmUubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvcGF0aF9vcl9mYWlsLm00XSkKPj4g
K200X2luY2x1ZGUoW200L3B5dGhvbl94bWwubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvcHl0aG9u
X3ZlcnNpb24ubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvcHl0aG9uX2RldmVsLm00XSkKPj4gK200
X2luY2x1ZGUoW200L3VkZXYubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvb2NhbWwubTRdKQo+PiAr
bTRfaW5jbHVkZShbbTQvZGVmYXVsdF9saWIubTRdKQo+PiArbTRfaW5jbHVkZShbbTQvc2V0X2Nm
bGFnc19sZGZsYWdzLm00XSkKPj4gKwo+PiArIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCj4+ICtB
WF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hzbV0sCj4+ICsgwqAgwqBbRW5hYmxlIFhTTSBzZWN1
cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKV0pCj4KPiBEb2VzIHRoaXMgbWFjcm8gaW5j
bHVkZSBzdXBwb3J0IGZvciByZWFkaW5nIGZyb20gY29uZmlnLmNhY2hlIGFzIHdlbGwgYXMKPiB0
aGUgY21kbGluZSBvcHRpb24/CgpUaGV5IHdlcmVuJ3QgYnV0IEkndmUgYWRkZWQgc3VwcG9ydCBh
bmQgdGhleSBhcmUgY2FjaGVkIG5vdyAocHJvdmlkZWQKdGhhdCB5b3UgcnVuIGNvbmZpZ3VyZSB3
aXRoIC0tY29uZmlnLWNhY2hlKS4KCj4KPiBbLi4uXQo+PiArQVNfSUYoW3Rlc3QgIngkb2NhbWx0
b29scyIgPSAieHkiXSwgWwo+PiArIMKgIMKgQUNfUFJPR19PQ0FNTAo+PiArIMKgIMKgQVNfSUYo
W3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwgWwo+PiArIMKgIMKgIMKgQUNfTVNHX0VSUk9SKFtZ
b3UgbXVzdCBpbnN0YWxsIHRoZSBPQ2FtbCBjb21waWxlcl0pCj4KPiBvY2FtbCB3YXMgcHJldmlv
dXNseSBvcHRpb25hbCwgSSB0aGluay4KCk9rLCBJIHdpbGwgc2V0IHRvIGRpc2FibGVkIGJ5IGRl
ZmF1bHQgdGhlbi4KCj4KPiBbLi4uXQo+PiArCj4+ICsjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVz
Lgo+PiArQUNfRlVOQ19BTExPQ0EKPj4gK0FDX0NIRUNLX0hFQURFUlMoWyBcCj4+ICsgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqBhcnBhL2luZXQuaCBmY250bC5oIGludHR5cGVzLmggbGliaW50bC5o
IGxpbWl0cy5oIG1hbGxvYy5oIFwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5ldGRiLmgg
bmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwKPj4gKyDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0bC5oIHN5
cy9tb3VudC5oIHN5cy9wYXJhbS5oIFwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHN5cy9z
b2NrZXQuaCBzeXMvc3RhdHZmcy5oIHN5cy90aW1lLmggc3lzbG9nLmggdGVybWlvcy5oIFwKPj4g
KyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAo+
PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgXSkKPj4gKwo+PiArIyBDaGVja3MgZm9yIHR5cGVk
ZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgo+PiArQUNfSEVB
REVSX1NUREJPT0wKPj4gK0FDX1RZUEVfVUlEX1QKPj4gK0FDX0NfSU5MSU5FCj4+ICtBQ19UWVBF
X0lOVDE2X1QKPj4gK0FDX1RZUEVfSU5UMzJfVAo+PiArQUNfVFlQRV9JTlQ2NF9UCj4+ICtBQ19U
WVBFX0lOVDhfVAo+Cj4gVGhlcmUncyBubyBBQ19UWVBFX1NURElOVCBvciBzaW1pbGFyPwoKVGhp
cyB3YXMgYXV0b21hdGljYWxseSBkb25lIGJ5IGF1dG9zY2FuLCBhbmQgSSd2ZSB0cmllZCBzZWFy
Y2hpbmcgZm9yCnNvbWV0aGluZyBsaWtlIEFDX1RZUEVfU1RESU5ULCBidXQgSSBoYXZlbid0IGJl
ZW4gYWJsZSB0byBmaW5kCmFueXRoaW5nLiBJZiB5b3Ugd2FudCBJIGNhbiBidW5kbGUgdGhlIElO
VCBjaGVja3MgaW5zaWRlIGEgbWFjcm8KY2FsbGVkIEFYX1RZUEVfU1RESU5ULgoKPgo+PiArQUNf
VFlQRV9NT0RFX1QKPj4gK0FDX1RZUEVfT0ZGX1QKPj4gK0FDX1RZUEVfUElEX1QKPj4gK0FDX0Nf
UkVTVFJJQ1QKPj4gK0FDX1RZUEVfU0laRV9UCj4+ICtBQ19UWVBFX1NTSVpFX1QKPgo+IElzIHRo
ZXJlIG5vdCBzb21lIHVtYnJlbGxhIHRlc3QgZm9yIHRoZXNlIHNvcnRzIG9mIHZlcnkgc3RhbmRh
cmQgdGhpbmdzLAo+IGUuZy4gQUNfUE9TSVggb3Igc29tZXRoaW5nIGxpa2UgdGhhdD8KCkFnYWlu
LCB0aGUgc2FtZSBhcyBhYm92ZS4KCj4KPj4gK0FDX0NIRUNLX01FTUJFUlMoW3N0cnVjdCBzdGF0
LnN0X2Jsa3NpemVdKQo+PiArQUNfU1RSVUNUX1NUX0JMT0NLUwo+PiArQUNfQ0hFQ0tfTUVNQkVS
Uyhbc3RydWN0IHN0YXQuc3RfcmRldl0pCj4+ICtBQ19UWVBFX1VJTlQxNl9UCj4+ICtBQ19UWVBF
X1VJTlQzMl9UCj4+ICtBQ19UWVBFX1VJTlQ2NF9UCj4+ICtBQ19UWVBFX1VJTlQ4X1QKPj4gK0FD
X0NIRUNLX1RZUEVTKFtwdHJkaWZmX3RdKQo+PiArCj4+ICsjIENoZWNrcyBmb3IgbGlicmFyeSBm
dW5jdGlvbnMuCj4+ICtBQ19GVU5DX0VSUk9SX0FUX0xJTkUKPj4gK0FDX0ZVTkNfRk9SSwo+PiAr
QUNfRlVOQ19GU0VFS08KPj4gK0FDX0ZVTkNfTFNUQVRfRk9MTE9XU19TTEFTSEVEX1NZTUxJTksK
Pj4gK0FDX0hFQURFUl9NQUpPUgo+PiArQUNfRlVOQ19NQUxMT0MKPj4gK0FDX0ZVTkNfTUtUSU1F
Cj4+ICtBQ19GVU5DX01NQVAKPj4gK0FDX0ZVTkNfUkVBTExPQwo+PiArQUNfRlVOQ19TVFJOTEVO
Cj4+ICtBQ19GVU5DX1NUUlRPRAo+PiArQUNfQ0hFQ0tfRlVOQ1MoWyBcCj4+ICsgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqBhbGFybSBhdGV4aXQgYnplcm8gY2xvY2tfZ2V0dGltZSBkdXAyIGZkYXRh
c3luYyBmdHJ1bmNhdGUgXAo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZ2V0Y3dkIGdldGhv
c3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKPj4gKyDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoGluZXRfbnRvYSBpc2FzY2lpIGxvY2FsdGltZV9yIG1lbWNociBt
ZW1tb3ZlIG1lbXNldCBta2RpciBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBta2ZpZm8g
bXVubWFwIHBhdGhjb25mIHJlYWxwYXRoIHJlZ2NvbXAgcm1kaXIgc2VsZWN0IHNldGVudiBcCj4+
ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3Nw
biBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBz
dHJwYnJrIHN0cnJjaHIgc3Ryc3BuIHN0cnN0ciBzdHJ0b2wgc3RydG91bCBzdHJ0b3VsbCB0enNl
dCBcCj4+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB1bmFtZSBcCj4+ICsgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqBdKQo+PiArCj4+ICtBQ19PVVRQVVQoKQo+PiBkaWZmIC1yIDQwODZlNDgxMTU0
NyAtciBlMTJlYzEwNzE0MTAgbTQvZGVmYXVsdF9saWIubTQKPj4gLS0tIC9kZXYvbnVsbCDCoCBU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKPj4gKysrIGIvbTQvZGVmYXVsdF9saWIubTQg
U2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCj4+IEBAIC0wLDAgKzEsNyBAQAo+PiArQUNf
REVGVU4oW0FYX0RFRkFVTFRfTElCXSwKPj4gK1tBU19JRihbdGVzdCAtZCAiJHByZWZpeC9saWI2
NCJdLCBbCj4+ICsgwqAgwqBMSUJfUEFUSD0ibGliNjQiCj4+ICtdLFsKPj4gKyDCoCDCoExJQl9Q
QVRIPSJsaWIiCj4+ICtdKQo+PiArQUNfU1VCU1QoTElCX1BBVEgpXSkKPgo+IERvZXMgdGhpcyBn
ZXQgZXhwb3NlZCB2aWEgY29uZmlnLmNhY2hlIGFuZC9vciB0aGUgY29tbWFuZCBsaW5lPyBJdAo+
IHNob3VsZCBiZS4KPgo+IERpZCB5b3Ugd3JpdGUgbTQvKiBmcm9tIHNjcmF0Y2ggb3IgZGlkIHRo
ZXkgY29tZSBmcm9tIHNvbWUgc25pcHBldAo+IGxpYnJhcnk/CgpUaGUgb25seSBvbmUgdGhhdCBj
b21lcyBmcm9tIGEgbGlicmFyeSBpcyBvY2FtbC5tNCwgdGhlIG90aGVyIG9uZXMgYXJlCmhhbmQt
d3JpdHRlbi4gTW9zdCBhcmUgdHJhbnNsYXRpb25zIG9mIHRvb2xzL2NoZWNrL2NoZWNrXyosIGFu
ZCB0aGUKcmVzdCBhcmUgYSBjb3VwbGUgb2YgaGFuZGZ1bCBtYWNyb3MgdGhhdCBhdm9pZCByZXBl
YXRpbmcgY29kZSBibG9ja3MKYWxsIG92ZXIuCgo+Cj4gSXNuJ3QgdGhlIG1hbmFnZW1lbnQgb2Yg
dGhlc2Ugc25pcHBldHMgdGhlIHNvcnQgb2YgdGhpbmcgYWNsb2NhbCBkb2VzCj4gZm9yIHlvdT8K
CmFjbG9jYWwganVzdCBzY2FucyBjb25maWd1cmUuYWMgYW5kIGNvbmNhdGVuYXRlcyBhbGwgbmVj
ZXNzYXJ5IG1hY3JvcwppbnRvIGFjbG9jYWwubTQsIEkndmUgdHJpZWQgdG8gdXNlIGFsbCB0aGUg
cHJlZGVmaW5lZCBtYWNyb3MgSSBjb3VsZCwKYW5kIG1vc3Qgb2YgdGhlIGZpbGVzIGluc2lkZSBt
NC8qIGFyZSBqdXN0IHdyYXBwZXJzIHRvIG1ha2UKY29uZmlndXJlLmFjIGNsZWFuZXIgYW5kIGVh
c2llciB0byB1bmRlcnN0YW5kLgoKPgo+PiBcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKPgo+
IE1pZ2h0IHRoaXMgbmV3bGluZSBiZSBzaWduaWZpY2FudCBpbiBhIG1hY3JvIGV4cGFuc2lvbiBs
aWJyYXJ5PyBJIHRoaW5rCj4gaXQncyBnb29kIHByYWN0aWNlIHRvIGluY2x1ZGUgaXQgYW55d2F5
IChoZXJlIGFuZCBlbHNld2hlcmUpLgoKWXVwLCBJJ3ZlIGZvcmdvdC4KCj4KPiBbLi4uXQo+PiBk
aWZmIC1yIDQwODZlNDgxMTU0NyAtciBlMTJlYzEwNzE0MTAgbTQvb2NhbWwubTQKPj4gLS0tIC9k
ZXYvbnVsbCDCoCBUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKPj4gKysrIGIvbTQvb2Nh
bWwubTQgwqAgwqAgwqAgU2F0IEphbiAwNyAwNDoxNzoxMCAyMDEyICswMTAwCj4+IEBAIC0wLDAg
KzEsMjQwIEBACj4+ICtkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBPQ2FtbAo+Cj4gUGxlYXNlIGFk
ZCBhIGNvbW1lbnQgZGVzY3JpYmluZyB3aGVyZSB0aGlzIGNhbWUgZnJvbSBzbyB3ZSBrbm93IGhv
dyB0bwo+IHVwZGF0ZSBpbiB0aGUgZnV0dXJlLgo+Cj4gU2hvdWxkbid0L2NvdWxkbid0IHRoaXMg
YmUgcHJvdmlkZWQgYnkgdGhlIG9jYW1sIHBhY2thZ2VzIGFuZCBqdXN0Cj4gaW5jbHVkZWQgYnkg
dXM/CgpUaGlzIGNvbWVzIGZyb20gaHR0cDovL2ZvcmdlLm9jYW1sY29yZS5vcmcvLCBhbmQgdGhl
IG1hbnBhZ2Ugc3RhdGVzIHRoYXQ6CgoiVG8gYmVnaW4gdXNpbmcgdGhlc2UgbWFjcm9zLCB5b3Ug
d2lsbCBuZWVkIHRvIGNvcHkgdGhlIG9jYW1sLm00IGZpbGUKKHVzdWFsbHkgbG9jYXRlZCBhdCAv
dXNyL3NoYXJlL2FjbG9jYWwvb2NhbWwubTQpIHRvIHRoZSBhdXRvY29uZgptYWNyb3MgZGlyZWN0
b3J5IGluIHlvdXIgcHJvamVjdC4gTm9ybWFsbHkgdGhpcyBpcyB0aGUgbTQvIGRpcmVjdG9yeQpp
biB5b3VyIHByb2plY3QsIGJ1dCB0aGUgZGlyZWN0b3J5IGNhbiBiZSBjaGFuZ2VkIHVzaW5nIHRo
ZQpBQ19DT05GSUdfTUFDUk9fRElSKERJUikgZGlyZWN0aXZlLiIKClRoYXQncyB3aHkgSSBjb3Bp
ZWQgaXQgdG8gbTQvCgo+Cj4gWy4uLl0KPgo+IElhbi4KPgoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2
ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 09 14:00:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 14:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkFlg-00085S-Bt; Mon, 09 Jan 2012 14:00:08 +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 1RkFlf-00085G-9Z
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 14:00:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326117585!61682227!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjAyOTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjAyOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19425 invoked from network); 9 Jan 2012 13:59:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 13:59:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326117604; l=2985;
	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=EqUC5xHo6rkTR4CarA4RWNFUZZU=;
	b=fBoouPX8eRuCslDXEhclksgFWvI15kmZCyRk9Rjdi8DZMcCrzpwzgqaGhdQqqJy1Uwa
	XmX7/h7pDfoMU+I+Tx50zQraR0BB0F3u7u8wFGieROsBlqsRsqnIgb7FKZqzybclnyXHu
	0whuVu1QzkdgYanmnoudsRdsSmHDzZiIHQg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (fruni mo46) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id D05ebdo09Cjobt
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 15:00:02 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id EBB7018634
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 15:00:01 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3394ca5ef6f768aa2fe0988c121b2a86698f1400
Message-Id: <3394ca5ef6f768aa2fe0.1326117597@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 14:59:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: no poll timeout while page-out is in
	progress
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326117284 -3600
# Node ID 3394ca5ef6f768aa2fe0988c121b2a86698f1400
# Parent  3a22ed3ec534799b3cab55b0dc0a7380e701ecbe
xenpaging: no poll timeout while page-out is in progress

The main loop calls xenpaging_wait_for_event_or_timeout() unconditionally
before doing any work. This function calls poll() with a timeout of 100ms. As
a result the page-out process is very slow due to the delay in poll().

Call poll() without timeout so that it returns immediately until the page-out
is done. Page-out is done when either the policy finds no more pages to
nominate or when the requested number of pages is reached.

The condition is cleared when a watch event arrives, so that processing the
new target is not delayed once again by poll().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3a22ed3ec534 -r 3394ca5ef6f7 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -90,6 +90,7 @@ int policy_choose_victim(xenpaging_t *pa
         /* Could not nominate any gfn */
         if ( wrap == current_gfn )
         {
+            paging->use_poll_timeout = 1;
             /* Count wrap arounds */
             unconsumed_cleared++;
             /* Force retry every few seconds (depends on poll() timeout) */
diff -r 3a22ed3ec534 -r 3394ca5ef6f7 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -85,6 +85,7 @@ static int xenpaging_wait_for_event_or_t
     struct pollfd fd[2];
     int port;
     int rc;
+    int timeout;
 
     /* Wait for event channel and xenstore */
     fd[0].fd = xc_evtchn_fd(xce);
@@ -92,7 +93,9 @@ static int xenpaging_wait_for_event_or_t
     fd[1].fd = xs_fileno(paging->xs_handle);
     fd[1].events = POLLIN | POLLERR;
 
-    rc = poll(fd, 2, 100);
+    /* No timeout while page-out is still in progress */
+    timeout = paging->use_poll_timeout ? 100 : 0;
+    rc = poll(fd, 2, timeout);
     if ( rc < 0 )
     {
         if (errno == EINTR)
@@ -134,6 +137,8 @@ static int xenpaging_wait_for_event_or_t
                         if ( target_tot_pages < 0 || target_tot_pages > paging->max_pages )
                             target_tot_pages = paging->max_pages;
                         paging->target_tot_pages = target_tot_pages;
+                        /* Disable poll() delay while new target is not yet reached */
+                        paging->use_poll_timeout = 0;
                         DPRINTF("new target_tot_pages %d\n", target_tot_pages);
                     }
                     free(val);
@@ -985,6 +990,11 @@ int main(int argc, char *argv[])
             }
             resume_pages(paging, num);
         }
+        /* Now target was reached, enable poll() timeout */
+        else
+        {
+            paging->use_poll_timeout = 1;
+        }
 
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
diff -r 3a22ed3ec534 -r 3394ca5ef6f7 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -52,6 +52,7 @@ typedef struct xenpaging {
     int num_paged_out;
     int target_tot_pages;
     int policy_mru_size;
+    int use_poll_timeout;
     int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 14:00:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 14:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkFlg-00085S-Bt; Mon, 09 Jan 2012 14:00:08 +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 1RkFlf-00085G-9Z
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 14:00:07 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326117585!61682227!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjAyOTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjAyOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19425 invoked from network); 9 Jan 2012 13:59:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-15.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 13:59:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326117604; l=2985;
	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=EqUC5xHo6rkTR4CarA4RWNFUZZU=;
	b=fBoouPX8eRuCslDXEhclksgFWvI15kmZCyRk9Rjdi8DZMcCrzpwzgqaGhdQqqJy1Uwa
	XmX7/h7pDfoMU+I+Tx50zQraR0BB0F3u7u8wFGieROsBlqsRsqnIgb7FKZqzybclnyXHu
	0whuVu1QzkdgYanmnoudsRdsSmHDzZiIHQg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (fruni mo46) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id D05ebdo09Cjobt
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 15:00:02 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id EBB7018634
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 15:00:01 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3394ca5ef6f768aa2fe0988c121b2a86698f1400
Message-Id: <3394ca5ef6f768aa2fe0.1326117597@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 14:59:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: no poll timeout while page-out is in
	progress
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326117284 -3600
# Node ID 3394ca5ef6f768aa2fe0988c121b2a86698f1400
# Parent  3a22ed3ec534799b3cab55b0dc0a7380e701ecbe
xenpaging: no poll timeout while page-out is in progress

The main loop calls xenpaging_wait_for_event_or_timeout() unconditionally
before doing any work. This function calls poll() with a timeout of 100ms. As
a result the page-out process is very slow due to the delay in poll().

Call poll() without timeout so that it returns immediately until the page-out
is done. Page-out is done when either the policy finds no more pages to
nominate or when the requested number of pages is reached.

The condition is cleared when a watch event arrives, so that processing the
new target is not delayed once again by poll().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3a22ed3ec534 -r 3394ca5ef6f7 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -90,6 +90,7 @@ int policy_choose_victim(xenpaging_t *pa
         /* Could not nominate any gfn */
         if ( wrap == current_gfn )
         {
+            paging->use_poll_timeout = 1;
             /* Count wrap arounds */
             unconsumed_cleared++;
             /* Force retry every few seconds (depends on poll() timeout) */
diff -r 3a22ed3ec534 -r 3394ca5ef6f7 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -85,6 +85,7 @@ static int xenpaging_wait_for_event_or_t
     struct pollfd fd[2];
     int port;
     int rc;
+    int timeout;
 
     /* Wait for event channel and xenstore */
     fd[0].fd = xc_evtchn_fd(xce);
@@ -92,7 +93,9 @@ static int xenpaging_wait_for_event_or_t
     fd[1].fd = xs_fileno(paging->xs_handle);
     fd[1].events = POLLIN | POLLERR;
 
-    rc = poll(fd, 2, 100);
+    /* No timeout while page-out is still in progress */
+    timeout = paging->use_poll_timeout ? 100 : 0;
+    rc = poll(fd, 2, timeout);
     if ( rc < 0 )
     {
         if (errno == EINTR)
@@ -134,6 +137,8 @@ static int xenpaging_wait_for_event_or_t
                         if ( target_tot_pages < 0 || target_tot_pages > paging->max_pages )
                             target_tot_pages = paging->max_pages;
                         paging->target_tot_pages = target_tot_pages;
+                        /* Disable poll() delay while new target is not yet reached */
+                        paging->use_poll_timeout = 0;
                         DPRINTF("new target_tot_pages %d\n", target_tot_pages);
                     }
                     free(val);
@@ -985,6 +990,11 @@ int main(int argc, char *argv[])
             }
             resume_pages(paging, num);
         }
+        /* Now target was reached, enable poll() timeout */
+        else
+        {
+            paging->use_poll_timeout = 1;
+        }
 
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
diff -r 3a22ed3ec534 -r 3394ca5ef6f7 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -52,6 +52,7 @@ typedef struct xenpaging {
     int num_paged_out;
     int target_tot_pages;
     int policy_mru_size;
+    int use_poll_timeout;
     int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 } xenpaging_t;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 14:56:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 14:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkGdU-0008Nm-Nt; Mon, 09 Jan 2012 14:55: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 1RkGdS-0008Nh-TI
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 14:55:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326120935!8071583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2659 invoked from network); 9 Jan 2012 14:55: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;
	9 Jan 2012 14:55:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9898997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 14:55:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 9 Jan 2012
	14:55: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, 9 Jan 2012 14:55:35 +0000
In-Reply-To: <CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@mail.gmail.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<1326110599.17210.81.camel@zakaz.uk.xensource.com>
	<CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326120935.17210.96.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAxLTA5IGF0IDEzOjUxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS85IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+ID4g
T24gU2F0LCAyMDEyLTAxLTA3IGF0IDAzOjIwICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gPj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxy
b2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+PiAjIERhdGUgMTMyNTkwNjIzMCAtMzYwMAo+ID4+
ICMgTm9kZSBJRCBlMTJlYzEwNzE0MTBjOTQ2MzY3Y2IwNTA4Y2YyMThhMGMzYjU5NmNhCj4gPj4g
IyBQYXJlbnQgIDQwODZlNDgxMTU0N2RkZmZiOWE1M2ZiZjJlZmI2YzJmYTQzNmI3MGEKPiA+PiBi
dWlsZDogYWRkIGF1dG9jb25mIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVj
awo+ID4+Cj4gPj4gQWRkZWQgYXV0b3Rvb2xzIG1hZ2ljIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNr
IHNjcmlwdHMuIFRoZSBwcmV2aW91cwo+ID4+IGNoZWNrcyBoYXZlIGJlZW4gcG9ydGVkIHRvIGF1
dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQo+ID4+IGJlZW4gYWRkZWQgKHBs
dXMgdGhlIHN1Z2dlc3Rpb25zIGZyb20gcnVubmluZyBhdXRvc2NhbikuIFR3byBmaWxlcyBhcmUK
PiA+PiBjcmVhdGVkIGFzIGEgcmVzdWx0IGZyb20gZXhlY3V0aW5nIGNvbmZpZ3VyZSBzY3JpcHQs
Cj4gPj4gY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KPiA+Pgo+ID4+IEF1dG9jb25m
Lm1rIGlzIGluY2x1ZGVkIGJ5IENvbmZpZy5taywgYW5kIGNvbnRhaW5zIG1vc3Qgb2YgdGhlCj4g
Pj4gb3B0aW9ucyBwcmV2aW91c2x5IGRlZmluZWQgaW4gLmNvbmZpZywgdGhhdCBjYW4gbm93IGJl
IHNldCBwYXNzaW5nCj4gPj4gcGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJp
YWJsZXMgd2hlbiBleGVjdXRpbmcgY29uZmlndXJlCj4gPj4gc2NyaXB0Lgo+ID4+Cj4gPj4gY29u
ZmlnLmggaXMgc3RpbGwgbm90IHVzZWQgYW55d2hlcmUsIGFuZCBpcyBhdXRvbWF0aWNhbGx5IGNy
ZWF0ZWQgYnkKPiA+PiBhdXRvaGVhZGVyLCBhbHRvdWdoIHRoaXMgbWlnaCBjaGFuZ2Ugd2hlbiB3
ZSBzdGFydCB0byBpbmNsdWRlIHRoaXMKPiA+PiBmaWxlLgo+ID4+Cj4gPj4gSnVzdCBhIGZpcnN0
IHJlbGVhc2UsIGFuZCBzaW5jZSBJaXQncyBteSBmaXJzdCBhdXRvY29uZiBzY3JpcHQgSSBndWVz
cwo+ID4+IHRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNl
IHJldmlldyBhbmQgY29tbWVudC4KPiA+Pgo+ID4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBN
b25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4gPgo+ID4gSSB3b3VsZCBoYXZlIGV4cGVj
dGVkIHRvIHNlZSBhbiB1cGRhdGUgdG8gdGhlIGNsZWFuL2Rpc3RjbGVhbiBydWxlcwo+ID4gYW5k
IC5oZ2lnbm9yZSBkdWUgdG8gYWxsIHRoZSBuZXcgZ2VuZXJhdGVkIGZpbGVzLgo+IAo+IFllcywg
SSB3YXMgZ29pbmcgdG8gZG8gdGhhdCB3aGVuIHdlIGFncmVlIG9uIHdlcmUgc2hvdWxkIHRoaW5n
cwo+IHJlc2lkZSwgdGhhdCdzIHdoeSBJIGRpZG4ndCBpbmNsdWRlIGFueSBvZiB0aGlzIG9uIHRo
ZSBwYXRjaC4KCk9LCgo+ID4+IGRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBS
RUFETUUKPiA+PiAtLS0gYS9SRUFETUUgICAgVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAw
Cj4gPj4gKysrIGIvUkVBRE1FICAgIFNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+ID4+
IEBAIC04Nyw5ICs4NywxNSBAQCAyLiBjZCB0byB4ZW4tdW5zdGFibGUgKG9yIHdoYXRldmVyIHlv
dSBzCj4gPj4gIDMuIEZvciB0aGUgdmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8g
ZGVzdHJveSBidWlsZCB0cmVlcywKPiA+PiAgICAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBz
Ogo+ID4+Cj4gCj4gVGhpcyB3aWxsIGJlIGxpa2U6Cj4gCj4gIyBhY2xvY2FsICYmIGF1dG9tYWtl
IC1hCj4gCj4gPj4gKyAgICAjIGF1dG9tYWtlIC1hCj4gPgo+ID4gV2UgYXJlbid0IHVzaW5nIGF1
dG9tYWtlIHRob3VnaD8gUGVyaGFwcyB0aGlzIGV4cGxhaW5zIHlvdXIgcHJvYmxlbSB3aXRoCj4g
PiB0aGluZ3MgYWx3eWFzIHRyeWluZyB0byB1c2UgTWFrZWZpbGUuYW0/Cj4gCj4gV2UgbmVlZCB0
byBydW4gYXV0b21ha2UsIGJlY2F1c2UgaXQgZ2VuZXJhdGVzIGNvbmZpZy5zdWIgYW5kCj4gY29u
ZmlnLmd1ZXNzLCB3aGljaCBpcyBuZWVkZWQgZm9yIGNlcnRhaW4gYXV0b2NvbmYgdGVzdHMuIFRo
ZSBwcm9ibGVtCj4gaXMgdGhhdCBJIGRvbid0IGtub3cgaG93IHRvIGNhbGwgYXV0b21ha2UgdG8g
b25seSBnZW5lcmF0ZSB0aG9zZSBmaWxlcwo+IGFuZCBkb24ndCB0cnkgdG8gcGFyc2UgTWFrZWZp
bGUuYW0sIGJlY2F1c2UgYXV0b21ha2UgdHJpZXMgdG8gcGFyc2UKPiBNYWtlZmlsZS5hbSBhbmQg
ZXhpdHMgd2l0aCBhbiBlcnJvciBjb2RlLCB0aGF0J3MgYWxzbyBwcmV2ZW50aW5nIG1lCj4gZnJv
bSB1c2luZyBhdXRvcmVjb25mIGFuZCBmb3JnZXQgYWJvdXQgY2FsbGluZyBhY2xvY2FsLCBhdXRv
bWFrZSwKPiBhdXRvaGVhZGVyLi4uIHNlcGFyYXRlbHkuIEkgd2FzIGhvcGluZyB0aGF0IHNvbWUg
YXV0b3Rvb2xzIGV4cGVydCBoYXMKPiBhIHNvbHV0aW9uIGZvciB0aGlzIChJIHdpbGwga2VlcCBz
ZWFyY2hpbmcgYWxzbykuCgpJJ20gYWZyYWlkIEkgZG9uJ3Qga25vdyB0aGUgYW5zd2VyIHRvIHRo
aXMuICBJdCBzZWVtcyBsaWtlIGl0IHNob3VsZCBiZQpvYnZpb3VzIHRoYXQgd2Ugc2hvdWxkbid0
IGJlIHJ1bm5pbmcgYXV0b21ha2UgdW5sZXNzIHdlIHdhbnQgdG8gdXNlCmF1dG9tYWtlLCBidXQg
d2l0aCBhdXRvKiB3aG8ga25vd3Mgd2hhdCBnb2VzIG9uIDstKS4KClsuLi5dCgo+ID4+ICsgICAg
IyAuL2NvbmZpZ3VyZQo+ID4+ICAgICAgIyBtYWtlIHdvcmxkCj4gPj4gICAgICAjIG1ha2UgaW5z
dGFsbAo+ID4+Cj4gPj4gKyAgIElmIHlvdSB3YW50LCB5b3UgY2FuIHJ1biAuL2NvbmZpZ3VyZSAt
LWhlbHAgdG8gc2VlIHRoZSBsaXN0IG9mCj4gPj4gKyAgIG9wdGlucyBhdmFpbGFibGUgb3B0aW9u
cyB3aGVuIGJ1aWxkaW5nIGFuZCBpbnN0YWxsaW5nIFhlbi4KPiA+Cj4gPiAgICAgIG9wdGlvbnMK
PiAKPiBBbHNvIE9rIHdoZW4gd2UgZGVjaWRlIHRoZSBkZWZpbml0aXZlIG9wdGlvbnMuCgpJIHdh
cyBwb2ludGluZyBvdXQgdGhlIHR5cG8gIm9wdGlucyIuCgo+ID4KPiA+PiArWE1MMi1DT05GSUcg
ICAgICAgICA6PSBAWE1MQAo+ID4+ICtCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAo+ID4+
ICtYR0VUVFRFWFQgICAgICAgICAgIDo9IEBYR0VUVEVYVEAKPiA+PiArCj4gPj4gKyMgRXh0cmEg
Zm9sZGVyIGZvciBsaWJzL2luY2x1ZGVzCj4gPj4gK1BSRVBFTkRfSU5DTFVERVMgICAgOj0gQFBS
RVBFTkRfSU5DTFVERVNACj4gPj4gK1BSRVBFTkRfTElCICAgICAgICAgOj0gQFBSRVBFTkRfTElC
QAo+ID4+ICtBUFBFTkRfSU5DTFVERVMgICAgIDo9IEBBUFBFTkRfSU5DTFVERVNACj4gPj4gK0FQ
UEVORF9MSUIgICAgICAgICAgOj0gQEFQUEVORF9MSUJACj4gPj4gKwo+ID4+ICsjIEVuYWJsZSBY
U00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCj4gPj4gK1hTTV9FTkFCTEUg
ICAgICAgICAgOj0gQHhzbUAKPiA+PiArRkxBU0tfRU5BQkxFICAgICAgICA6PSBAeHNtQAo+ID4+
ICsKPiA+PiArIyBEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93
biBwcm90b2NvbD8KPiA+PiArIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUgcm9i
dXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCj4gPj4gKyMgbWF5IGJsb2NrIGl0
KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93
bmxvYWRzCj4gPj4gKyMgZmFpbCBvciBoYW5nLCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15IGlu
IHlvdXIgZW52aXJvbm1lbnQuCj4gPj4gK0dJVF9IVFRQICAgICAgICAgICAgOj0gQGdpdGh0dHBA
Cj4gPj4gKwo+ID4+ICsjIE9wdGlvbmFsIGNvbXBvbmVudHMKPiA+PiArWEVOU1RBVF9YRU5UT1Ag
ICAgICA6PSBAbW9uaXRvcnNACj4gPj4gK1ZUUE1fVE9PTFMgICAgICAgICAgOj0gQHZ0cG1ACj4g
Pj4gK0xJQlhFTkFQSV9CSU5ESU5HUyAgOj0gQHhhcGlACj4gPj4gK1BZVEhPTl9UT09MUyAgICAg
ICAgOj0gQHB5dGhvbnRvb2xzQAo+ID4+ICtPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRv
b2xzQAo+ID4+ICtDT05GSUdfTUlOSVRFUk0gICAgIDo9IEBtaW5pdGVybUAKPiA+PiArQ09ORklH
X0xPTU9VTlQgICAgICA6PSBAbG9tb3VudEAKPiA+PiArCj4gPj4gKyNTeXN0ZW0gb3B0aW9ucwo+
ID4+ICtDT05GSUdfU1lTVEVNX0xJQkFJTzo9IEBzeXN0ZW1fYWlvQAo+ID4+ICtDT05GSUdfTElC
SUNPTlYgICAgIDo9IEBsaWJpY29udkAKPiA+PiArQ09ORklHX0dDUllQVCAgICAgICA6PSBAbGli
Z2NyeXB0QAo+ID4+ICtDT05GSUdfRVhUMkZTICAgICAgIDo9IEBsaWJleHQyZnNACj4gPj4gZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIGNvbmZpZ3VyZS5hYwo+ID4+IC0tLSAv
ZGV2L251bGwgICBUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKPiA+PiArKysgYi9jb25m
aWd1cmUuYWMgICAgICBTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKPiA+PiBAQCAtMCww
ICsxLDE3OSBAQAo+ID4+ICsjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAtKi0gQXV0b2NvbmYgLSotCj4gPj4gKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0aCBh
dXRvY29uZiB0byBwcm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KPiA+PiArCj4gPj4gK0FDX1BS
RVJFUShbMi42N10pCj4gPgo+ID4gVGhpcyBpcyB0aGUgdmVyc2lvbiBpbiBEZWJpYW4gc3RhYmxl
IHdoaWNoIGlzIG15IHJ1bGUgb2YgdGh1bWIgZm9yIGhvdwo+ID4gZmFyIGJhY2sgdG8gc3VwcG9y
dCB0aGluZ3MgYXMgYSBtaW5pbXVtLgo+ID4KPiA+IEhvd2V2ZXIgZG8gd2UgcmVseSBvbiBmZWF0
dXJlcyBvZiAyLjY3IG9yIGNvdWxkIHdlIGdvIG9sZGVyIGlmIHNvbWVvbmUKPiA+IGhhcyBhbiBv
bGRlciB2ZXJzaW9uPwo+IAo+IEFDX1BSRVJFUSBpcyBhdXRvbWF0aWNhbGx5IHNldCBieSBhdXRv
c2NhbiBiYXNlZCBvbiB0aGUgdXNlZCB2ZXJzaW9uLgo+IEkndmUgZ2VuZXJhdGVkIHRoaXMgd2l0
aCAyLjY4LCBhbmQgY2hhbmdlZCB0aGUgQUNfUFJFUkVRIHRvIDIuNjcKPiBiZWNhdXNlIEkga25l
dyB0aGF0IHlvdSB3aGVyZSBnb2luZyB0byBjaGVjayBkZWJpYW4gc3RhYmxlIHZlcnNpb24uCj4g
SSd2ZSB0ZXN0ZWQgdGhpcyB1bmRlciAyLjY3IHdpdGggRGViaWFuIGFuZCBpdCB3b3JrcyBmaW5l
LCBidXQgSSBkb24ndAo+IGtub3cgYWJvdXQgb2xkZXIgdmVyc2lvbnMuCgpJIHRoaW5rIHdlIGNh
biBmYXVsdCB0aGVtIGluIGFzIHRlc3RlcnMgcmVwb3J0IGlzc3Vlcy4KClsuLi5dCgo+ID4gSSBk
aWRuJ3QgcmV2aWV3IGFsbCB0aGUgdGVzdHMgaW4gZGV0YWlsLCBJIHByZXN1bWUgd2UnbGwgZW5k
IHVwIGhhdmluZwo+ID4gdG8gZmluZCBhIGJ1bmNoIG9mIHRob3NlIGVycm9ycyB2aWEgdGVzdGlu
ZyBhbnl3aGVyZS4KPiA+Cj4gPiBEb2VzIHRoZSBzZXQgb2YgdGVzdHMgaGVyZSBwcmVjaXNlbHkg
ZXF1YWwgdGhvc2UgY3VycmVudGx5IGRvbmUgYnkKPiA+IHRvb2xzL2NoZWNrIChvciBlbHNld2hl
cmUpIG9yIGRpZCB5b3UgYWRkIG1vcmUgYXMgeW91IHdlbnQ/Cj4gCj4gSSd2ZSBtb3ZlZCBhbGwg
dG9vbHMvY2hlY2ssIGFuZCBhZGRlZCBhIHRlc3QgZm9yIGxpYmljb252IGFuZAo+IHlhamwveWFq
bF92ZXJzaW9uLmguCgpUaGVyZSBzZWVtcyB0byBiZSBhIGxvdCBtb3JlIHRlc3RzIGluIHRoZSBj
b25maWd1cmUuYWMgdGhhbiB0aGVyZSBldmVyCndlcmUgdW5kZXIgdG9vbHMvY2hlY2sgdGhvdWdo
PyBBbGwgc29ydHMgb2YgaGVhZGVycyBhbmQgZnVuY3Rpb24gY2hlY2tzCmV0Yy4gRGlkIHRoZXkg
Y29tZSBmcm9tIGF1dG9zY2FuPyAoYXV0b3NjYW4gaXMgbmV3IHRvIG1lLi4uKQoKPiA+IEl0IG1p
Z2h0Cj4gPiBoYXZlIGJlZW4gYmV0dGVyIGZvciByZXZpZXcgdG8gcHJlc2VudCB0aGlzIGFzIGEg
YmFzaWMgaW5mcmFzdHJ1Y3R1cmUKPiA+IHBhdGNoLCB0aGUgY29udmVyc2lvbiBvZiBlYWNoIHRl
c3QgaW5kaXZpZHVhbGx5IGFzIGEgcGF0Y2ggZWFjaCBhbmQKPiA+IGxhc3RseSBhbnkgbmV3IHRl
c3RzIGV0YyBzbyB3ZSBjb3VsZCBlYXNpbHkgcmV2aWV3LiBCdXQgSSB0aGluayBpdCdzIGEKPiA+
IGJpdCBsYXRlIG5vdyBhbmQgdGhlcmUncyBubyBwb2ludCBzcGxpdHRpbmcgdGhpcyBwYXRjaCB1
cCBub3cgeW91J3ZlIGdvdAo+ID4gaXQuCj4gCj4gRWFjaCB0ZXN0IGhhcyBpdCdzIG93biBtNCBm
aWxlIGluc2lkZSBtNC8sIGlmIGl0J3MgcmVhbGx5IGRpZmZpY3VsdCB0bwo+IHVuZGVyc3RhbmQg
KG00IGlzIG5vdCBlYXN5IGZvciB0aGUgZXllLCBhbHRob3VnaCBJIHRyaWVkIHRvIGZvbGxvdwo+
IGxpYnhsIENPRElOR19TVFlMRSksIEkgd2lsbCBzcGxpdCBpdCB1cCBpbiBzZXZlcmFsIHBhdGNo
ZXMgKG9uZSBmb3IKPiBlYWNoIG00LyBhbmQgb25lIGZvciB0aGUgcmVzdCBvZiB0aGUgYXV0b3Rv
b2xzIGluZnJhc3RydWN0dXJlKS4KCkkgZ3Vlc3MgbW9zdCBvZiB0aGUgc3R1ZmYgd2FzIGZyb20g
YXV0b3NjYW4gY2FuJ3QgbG9naWNhbGx5IGJlIHNwbGl0IHVwLApzbyBkb24ndCB3b3JyeS4KCj4g
PiBbLi4uXQo+ID4+ICtBU19JRihbdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSJdLCBbCj4gPj4g
KyAgICBBQ19QUk9HX09DQU1MCj4gPj4gKyAgICBBU19JRihbdGVzdCAieCRPQ0FNTEMiID0gInhu
byJdLCBbCj4gPj4gKyAgICAgIEFDX01TR19FUlJPUihbWW91IG11c3QgaW5zdGFsbCB0aGUgT0Nh
bWwgY29tcGlsZXJdKQo+ID4KPiA+IG9jYW1sIHdhcyBwcmV2aW91c2x5IG9wdGlvbmFsLCBJIHRo
aW5rLgo+IAo+IE9rLCBJIHdpbGwgc2V0IHRvIGRpc2FibGVkIGJ5IGRlZmF1bHQgdGhlbi4KCkJ5
IGRlZmF1bHQgaXQgc2hvdWxkIGJlIGVuYWJsZWQgaWYgdGhlIG5lY2Vzc2FyeSBiaXRzIGFyZSBw
cmVzZW50IGFuZApkaXNhYmxlZCBvdGhlcndpc2UuCgpbLi4uXQo+ID4gVGhlcmUncyBubyBBQ19U
WVBFX1NURElOVCBvciBzaW1pbGFyPwo+IAo+IFRoaXMgd2FzIGF1dG9tYXRpY2FsbHkgZG9uZSBi
eSBhdXRvc2NhbiwgYW5kIEkndmUgdHJpZWQgc2VhcmNoaW5nIGZvcgo+IHNvbWV0aGluZyBsaWtl
IEFDX1RZUEVfU1RESU5ULCBidXQgSSBoYXZlbid0IGJlZW4gYWJsZSB0byBmaW5kCj4gYW55dGhp
bmcuIElmIHlvdSB3YW50IEkgY2FuIGJ1bmRsZSB0aGUgSU5UIGNoZWNrcyBpbnNpZGUgYSBtYWNy
bwo+IGNhbGxlZCBBWF9UWVBFX1NURElOVC4KWy4uLl0KPiA+IElzIHRoZXJlIG5vdCBzb21lIHVt
YnJlbGxhIHRlc3QgZm9yIHRoZXNlIHNvcnRzIG9mIHZlcnkgc3RhbmRhcmQgdGhpbmdzLAo+ID4g
ZS5nLiBBQ19QT1NJWCBvciBzb21ldGhpbmcgbGlrZSB0aGF0Pwo+IAo+IEFnYWluLCB0aGUgc2Ft
ZSBhcyBhYm92ZS4KCkxldHMganVzdCBsZWF2ZSBpdCB0aGVuLgoKPiA+IElzbid0IHRoZSBtYW5h
Z2VtZW50IG9mIHRoZXNlIHNuaXBwZXRzIHRoZSBzb3J0IG9mIHRoaW5nIGFjbG9jYWwgZG9lcwo+
ID4gZm9yIHlvdT8KPiAKPiBhY2xvY2FsIGp1c3Qgc2NhbnMgY29uZmlndXJlLmFjIGFuZCBjb25j
YXRlbmF0ZXMgYWxsIG5lY2Vzc2FyeSBtYWNyb3MKPiBpbnRvIGFjbG9jYWwubTQsIEkndmUgdHJp
ZWQgdG8gdXNlIGFsbCB0aGUgcHJlZGVmaW5lZCBtYWNyb3MgSSBjb3VsZCwKPiBhbmQgbW9zdCBv
ZiB0aGUgZmlsZXMgaW5zaWRlIG00LyogYXJlIGp1c3Qgd3JhcHBlcnMgdG8gbWFrZQo+IGNvbmZp
Z3VyZS5hYyBjbGVhbmVyIGFuZCBlYXNpZXIgdG8gdW5kZXJzdGFuZC4KCk9LLgoKPiA+IFsuLi5d
Cj4gPj4gZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIG00L29jYW1sLm00Cj4g
Pj4gLS0tIC9kZXYvbnVsbCAgIFRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAo+ID4+ICsr
KyBiL200L29jYW1sLm00ICAgICAgIFNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+ID4+
IEBAIC0wLDAgKzEsMjQwIEBACj4gPj4gK2RubCBhdXRvY29uZiBtYWNyb3MgZm9yIE9DYW1sCj4g
Pgo+ID4gUGxlYXNlIGFkZCBhIGNvbW1lbnQgZGVzY3JpYmluZyB3aGVyZSB0aGlzIGNhbWUgZnJv
bSBzbyB3ZSBrbm93IGhvdyB0bwo+ID4gdXBkYXRlIGluIHRoZSBmdXR1cmUuCj4gPgo+ID4gU2hv
dWxkbid0L2NvdWxkbid0IHRoaXMgYmUgcHJvdmlkZWQgYnkgdGhlIG9jYW1sIHBhY2thZ2VzIGFu
ZCBqdXN0Cj4gPiBpbmNsdWRlZCBieSB1cz8KPiAKPiBUaGlzIGNvbWVzIGZyb20gaHR0cDovL2Zv
cmdlLm9jYW1sY29yZS5vcmcvLCBhbmQgdGhlIG1hbnBhZ2Ugc3RhdGVzIHRoYXQ6Cj4gCj4gIlRv
IGJlZ2luIHVzaW5nIHRoZXNlIG1hY3JvcywgeW91IHdpbGwgbmVlZCB0byBjb3B5IHRoZSBvY2Ft
bC5tNCBmaWxlCj4gKHVzdWFsbHkgbG9jYXRlZCBhdCAvdXNyL3NoYXJlL2FjbG9jYWwvb2NhbWwu
bTQpIHRvIHRoZSBhdXRvY29uZgo+IG1hY3JvcyBkaXJlY3RvcnkgaW4geW91ciBwcm9qZWN0LiBO
b3JtYWxseSB0aGlzIGlzIHRoZSBtNC8gZGlyZWN0b3J5Cj4gaW4geW91ciBwcm9qZWN0LCBidXQg
dGhlIGRpcmVjdG9yeSBjYW4gYmUgY2hhbmdlZCB1c2luZyB0aGUKPiBBQ19DT05GSUdfTUFDUk9f
RElSKERJUikgZGlyZWN0aXZlLiIKPiAKPiBUaGF0J3Mgd2h5IEkgY29waWVkIGl0IHRvIG00LwoK
RmFpciBlbm91Z2ghCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 09 14:56:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 14:56:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkGdU-0008Nm-Nt; Mon, 09 Jan 2012 14:55: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 1RkGdS-0008Nh-TI
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 14:55:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326120935!8071583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2659 invoked from network); 9 Jan 2012 14:55: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;
	9 Jan 2012 14:55:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9898997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 14:55:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 9 Jan 2012
	14:55: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, 9 Jan 2012 14:55:35 +0000
In-Reply-To: <CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@mail.gmail.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<1326110599.17210.81.camel@zakaz.uk.xensource.com>
	<CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326120935.17210.96.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAxLTA5IGF0IDEzOjUxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS85IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+ID4g
T24gU2F0LCAyMDEyLTAxLTA3IGF0IDAzOjIwICswMDAwLCBSb2dlciBQYXUgTW9ubmUgd3JvdGU6
Cj4gPj4gIyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPiA+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxy
b2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPiA+PiAjIERhdGUgMTMyNTkwNjIzMCAtMzYwMAo+ID4+
ICMgTm9kZSBJRCBlMTJlYzEwNzE0MTBjOTQ2MzY3Y2IwNTA4Y2YyMThhMGMzYjU5NmNhCj4gPj4g
IyBQYXJlbnQgIDQwODZlNDgxMTU0N2RkZmZiOWE1M2ZiZjJlZmI2YzJmYTQzNmI3MGEKPiA+PiBi
dWlsZDogYWRkIGF1dG9jb25mIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNrcyBpbiB0b29scy9jaGVj
awo+ID4+Cj4gPj4gQWRkZWQgYXV0b3Rvb2xzIG1hZ2ljIHRvIHJlcGxhY2UgY3VzdG9tIGNoZWNr
IHNjcmlwdHMuIFRoZSBwcmV2aW91cwo+ID4+IGNoZWNrcyBoYXZlIGJlZW4gcG9ydGVkIHRvIGF1
dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQo+ID4+IGJlZW4gYWRkZWQgKHBs
dXMgdGhlIHN1Z2dlc3Rpb25zIGZyb20gcnVubmluZyBhdXRvc2NhbikuIFR3byBmaWxlcyBhcmUK
PiA+PiBjcmVhdGVkIGFzIGEgcmVzdWx0IGZyb20gZXhlY3V0aW5nIGNvbmZpZ3VyZSBzY3JpcHQs
Cj4gPj4gY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KPiA+Pgo+ID4+IEF1dG9jb25m
Lm1rIGlzIGluY2x1ZGVkIGJ5IENvbmZpZy5taywgYW5kIGNvbnRhaW5zIG1vc3Qgb2YgdGhlCj4g
Pj4gb3B0aW9ucyBwcmV2aW91c2x5IGRlZmluZWQgaW4gLmNvbmZpZywgdGhhdCBjYW4gbm93IGJl
IHNldCBwYXNzaW5nCj4gPj4gcGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJp
YWJsZXMgd2hlbiBleGVjdXRpbmcgY29uZmlndXJlCj4gPj4gc2NyaXB0Lgo+ID4+Cj4gPj4gY29u
ZmlnLmggaXMgc3RpbGwgbm90IHVzZWQgYW55d2hlcmUsIGFuZCBpcyBhdXRvbWF0aWNhbGx5IGNy
ZWF0ZWQgYnkKPiA+PiBhdXRvaGVhZGVyLCBhbHRvdWdoIHRoaXMgbWlnaCBjaGFuZ2Ugd2hlbiB3
ZSBzdGFydCB0byBpbmNsdWRlIHRoaXMKPiA+PiBmaWxlLgo+ID4+Cj4gPj4gSnVzdCBhIGZpcnN0
IHJlbGVhc2UsIGFuZCBzaW5jZSBJaXQncyBteSBmaXJzdCBhdXRvY29uZiBzY3JpcHQgSSBndWVz
cwo+ID4+IHRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNl
IHJldmlldyBhbmQgY29tbWVudC4KPiA+Pgo+ID4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBN
b25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4gPgo+ID4gSSB3b3VsZCBoYXZlIGV4cGVj
dGVkIHRvIHNlZSBhbiB1cGRhdGUgdG8gdGhlIGNsZWFuL2Rpc3RjbGVhbiBydWxlcwo+ID4gYW5k
IC5oZ2lnbm9yZSBkdWUgdG8gYWxsIHRoZSBuZXcgZ2VuZXJhdGVkIGZpbGVzLgo+IAo+IFllcywg
SSB3YXMgZ29pbmcgdG8gZG8gdGhhdCB3aGVuIHdlIGFncmVlIG9uIHdlcmUgc2hvdWxkIHRoaW5n
cwo+IHJlc2lkZSwgdGhhdCdzIHdoeSBJIGRpZG4ndCBpbmNsdWRlIGFueSBvZiB0aGlzIG9uIHRo
ZSBwYXRjaC4KCk9LCgo+ID4+IGRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGUxMmVjMTA3MTQxMCBS
RUFETUUKPiA+PiAtLS0gYS9SRUFETUUgICAgVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAw
Cj4gPj4gKysrIGIvUkVBRE1FICAgIFNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+ID4+
IEBAIC04Nyw5ICs4NywxNSBAQCAyLiBjZCB0byB4ZW4tdW5zdGFibGUgKG9yIHdoYXRldmVyIHlv
dSBzCj4gPj4gIDMuIEZvciB0aGUgdmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8g
ZGVzdHJveSBidWlsZCB0cmVlcywKPiA+PiAgICAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBz
Ogo+ID4+Cj4gCj4gVGhpcyB3aWxsIGJlIGxpa2U6Cj4gCj4gIyBhY2xvY2FsICYmIGF1dG9tYWtl
IC1hCj4gCj4gPj4gKyAgICAjIGF1dG9tYWtlIC1hCj4gPgo+ID4gV2UgYXJlbid0IHVzaW5nIGF1
dG9tYWtlIHRob3VnaD8gUGVyaGFwcyB0aGlzIGV4cGxhaW5zIHlvdXIgcHJvYmxlbSB3aXRoCj4g
PiB0aGluZ3MgYWx3eWFzIHRyeWluZyB0byB1c2UgTWFrZWZpbGUuYW0/Cj4gCj4gV2UgbmVlZCB0
byBydW4gYXV0b21ha2UsIGJlY2F1c2UgaXQgZ2VuZXJhdGVzIGNvbmZpZy5zdWIgYW5kCj4gY29u
ZmlnLmd1ZXNzLCB3aGljaCBpcyBuZWVkZWQgZm9yIGNlcnRhaW4gYXV0b2NvbmYgdGVzdHMuIFRo
ZSBwcm9ibGVtCj4gaXMgdGhhdCBJIGRvbid0IGtub3cgaG93IHRvIGNhbGwgYXV0b21ha2UgdG8g
b25seSBnZW5lcmF0ZSB0aG9zZSBmaWxlcwo+IGFuZCBkb24ndCB0cnkgdG8gcGFyc2UgTWFrZWZp
bGUuYW0sIGJlY2F1c2UgYXV0b21ha2UgdHJpZXMgdG8gcGFyc2UKPiBNYWtlZmlsZS5hbSBhbmQg
ZXhpdHMgd2l0aCBhbiBlcnJvciBjb2RlLCB0aGF0J3MgYWxzbyBwcmV2ZW50aW5nIG1lCj4gZnJv
bSB1c2luZyBhdXRvcmVjb25mIGFuZCBmb3JnZXQgYWJvdXQgY2FsbGluZyBhY2xvY2FsLCBhdXRv
bWFrZSwKPiBhdXRvaGVhZGVyLi4uIHNlcGFyYXRlbHkuIEkgd2FzIGhvcGluZyB0aGF0IHNvbWUg
YXV0b3Rvb2xzIGV4cGVydCBoYXMKPiBhIHNvbHV0aW9uIGZvciB0aGlzIChJIHdpbGwga2VlcCBz
ZWFyY2hpbmcgYWxzbykuCgpJJ20gYWZyYWlkIEkgZG9uJ3Qga25vdyB0aGUgYW5zd2VyIHRvIHRo
aXMuICBJdCBzZWVtcyBsaWtlIGl0IHNob3VsZCBiZQpvYnZpb3VzIHRoYXQgd2Ugc2hvdWxkbid0
IGJlIHJ1bm5pbmcgYXV0b21ha2UgdW5sZXNzIHdlIHdhbnQgdG8gdXNlCmF1dG9tYWtlLCBidXQg
d2l0aCBhdXRvKiB3aG8ga25vd3Mgd2hhdCBnb2VzIG9uIDstKS4KClsuLi5dCgo+ID4+ICsgICAg
IyAuL2NvbmZpZ3VyZQo+ID4+ICAgICAgIyBtYWtlIHdvcmxkCj4gPj4gICAgICAjIG1ha2UgaW5z
dGFsbAo+ID4+Cj4gPj4gKyAgIElmIHlvdSB3YW50LCB5b3UgY2FuIHJ1biAuL2NvbmZpZ3VyZSAt
LWhlbHAgdG8gc2VlIHRoZSBsaXN0IG9mCj4gPj4gKyAgIG9wdGlucyBhdmFpbGFibGUgb3B0aW9u
cyB3aGVuIGJ1aWxkaW5nIGFuZCBpbnN0YWxsaW5nIFhlbi4KPiA+Cj4gPiAgICAgIG9wdGlvbnMK
PiAKPiBBbHNvIE9rIHdoZW4gd2UgZGVjaWRlIHRoZSBkZWZpbml0aXZlIG9wdGlvbnMuCgpJIHdh
cyBwb2ludGluZyBvdXQgdGhlIHR5cG8gIm9wdGlucyIuCgo+ID4KPiA+PiArWE1MMi1DT05GSUcg
ICAgICAgICA6PSBAWE1MQAo+ID4+ICtCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAo+ID4+
ICtYR0VUVFRFWFQgICAgICAgICAgIDo9IEBYR0VUVEVYVEAKPiA+PiArCj4gPj4gKyMgRXh0cmEg
Zm9sZGVyIGZvciBsaWJzL2luY2x1ZGVzCj4gPj4gK1BSRVBFTkRfSU5DTFVERVMgICAgOj0gQFBS
RVBFTkRfSU5DTFVERVNACj4gPj4gK1BSRVBFTkRfTElCICAgICAgICAgOj0gQFBSRVBFTkRfTElC
QAo+ID4+ICtBUFBFTkRfSU5DTFVERVMgICAgIDo9IEBBUFBFTkRfSU5DTFVERVNACj4gPj4gK0FQ
UEVORF9MSUIgICAgICAgICAgOj0gQEFQUEVORF9MSUJACj4gPj4gKwo+ID4+ICsjIEVuYWJsZSBY
U00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCj4gPj4gK1hTTV9FTkFCTEUg
ICAgICAgICAgOj0gQHhzbUAKPiA+PiArRkxBU0tfRU5BQkxFICAgICAgICA6PSBAeHNtQAo+ID4+
ICsKPiA+PiArIyBEb3dubG9hZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93
biBwcm90b2NvbD8KPiA+PiArIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUgcm9i
dXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCj4gPj4gKyMgbWF5IGJsb2NrIGl0
KS4gV2UgbWFrZSBpdCB0aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93
bmxvYWRzCj4gPj4gKyMgZmFpbCBvciBoYW5nLCBwbGVhc2Ugc3BlY2lmeSBHSVRfSFRUUD15IGlu
IHlvdXIgZW52aXJvbm1lbnQuCj4gPj4gK0dJVF9IVFRQICAgICAgICAgICAgOj0gQGdpdGh0dHBA
Cj4gPj4gKwo+ID4+ICsjIE9wdGlvbmFsIGNvbXBvbmVudHMKPiA+PiArWEVOU1RBVF9YRU5UT1Ag
ICAgICA6PSBAbW9uaXRvcnNACj4gPj4gK1ZUUE1fVE9PTFMgICAgICAgICAgOj0gQHZ0cG1ACj4g
Pj4gK0xJQlhFTkFQSV9CSU5ESU5HUyAgOj0gQHhhcGlACj4gPj4gK1BZVEhPTl9UT09MUyAgICAg
ICAgOj0gQHB5dGhvbnRvb2xzQAo+ID4+ICtPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRv
b2xzQAo+ID4+ICtDT05GSUdfTUlOSVRFUk0gICAgIDo9IEBtaW5pdGVybUAKPiA+PiArQ09ORklH
X0xPTU9VTlQgICAgICA6PSBAbG9tb3VudEAKPiA+PiArCj4gPj4gKyNTeXN0ZW0gb3B0aW9ucwo+
ID4+ICtDT05GSUdfU1lTVEVNX0xJQkFJTzo9IEBzeXN0ZW1fYWlvQAo+ID4+ICtDT05GSUdfTElC
SUNPTlYgICAgIDo9IEBsaWJpY29udkAKPiA+PiArQ09ORklHX0dDUllQVCAgICAgICA6PSBAbGli
Z2NyeXB0QAo+ID4+ICtDT05GSUdfRVhUMkZTICAgICAgIDo9IEBsaWJleHQyZnNACj4gPj4gZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIGNvbmZpZ3VyZS5hYwo+ID4+IC0tLSAv
ZGV2L251bGwgICBUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKPiA+PiArKysgYi9jb25m
aWd1cmUuYWMgICAgICBTYXQgSmFuIDA3IDA0OjE3OjEwIDIwMTIgKzAxMDAKPiA+PiBAQCAtMCww
ICsxLDE3OSBAQAo+ID4+ICsjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAtKi0gQXV0b2NvbmYgLSotCj4gPj4gKyMgUHJvY2VzcyB0aGlzIGZpbGUgd2l0aCBh
dXRvY29uZiB0byBwcm9kdWNlIGEgY29uZmlndXJlIHNjcmlwdC4KPiA+PiArCj4gPj4gK0FDX1BS
RVJFUShbMi42N10pCj4gPgo+ID4gVGhpcyBpcyB0aGUgdmVyc2lvbiBpbiBEZWJpYW4gc3RhYmxl
IHdoaWNoIGlzIG15IHJ1bGUgb2YgdGh1bWIgZm9yIGhvdwo+ID4gZmFyIGJhY2sgdG8gc3VwcG9y
dCB0aGluZ3MgYXMgYSBtaW5pbXVtLgo+ID4KPiA+IEhvd2V2ZXIgZG8gd2UgcmVseSBvbiBmZWF0
dXJlcyBvZiAyLjY3IG9yIGNvdWxkIHdlIGdvIG9sZGVyIGlmIHNvbWVvbmUKPiA+IGhhcyBhbiBv
bGRlciB2ZXJzaW9uPwo+IAo+IEFDX1BSRVJFUSBpcyBhdXRvbWF0aWNhbGx5IHNldCBieSBhdXRv
c2NhbiBiYXNlZCBvbiB0aGUgdXNlZCB2ZXJzaW9uLgo+IEkndmUgZ2VuZXJhdGVkIHRoaXMgd2l0
aCAyLjY4LCBhbmQgY2hhbmdlZCB0aGUgQUNfUFJFUkVRIHRvIDIuNjcKPiBiZWNhdXNlIEkga25l
dyB0aGF0IHlvdSB3aGVyZSBnb2luZyB0byBjaGVjayBkZWJpYW4gc3RhYmxlIHZlcnNpb24uCj4g
SSd2ZSB0ZXN0ZWQgdGhpcyB1bmRlciAyLjY3IHdpdGggRGViaWFuIGFuZCBpdCB3b3JrcyBmaW5l
LCBidXQgSSBkb24ndAo+IGtub3cgYWJvdXQgb2xkZXIgdmVyc2lvbnMuCgpJIHRoaW5rIHdlIGNh
biBmYXVsdCB0aGVtIGluIGFzIHRlc3RlcnMgcmVwb3J0IGlzc3Vlcy4KClsuLi5dCgo+ID4gSSBk
aWRuJ3QgcmV2aWV3IGFsbCB0aGUgdGVzdHMgaW4gZGV0YWlsLCBJIHByZXN1bWUgd2UnbGwgZW5k
IHVwIGhhdmluZwo+ID4gdG8gZmluZCBhIGJ1bmNoIG9mIHRob3NlIGVycm9ycyB2aWEgdGVzdGlu
ZyBhbnl3aGVyZS4KPiA+Cj4gPiBEb2VzIHRoZSBzZXQgb2YgdGVzdHMgaGVyZSBwcmVjaXNlbHkg
ZXF1YWwgdGhvc2UgY3VycmVudGx5IGRvbmUgYnkKPiA+IHRvb2xzL2NoZWNrIChvciBlbHNld2hl
cmUpIG9yIGRpZCB5b3UgYWRkIG1vcmUgYXMgeW91IHdlbnQ/Cj4gCj4gSSd2ZSBtb3ZlZCBhbGwg
dG9vbHMvY2hlY2ssIGFuZCBhZGRlZCBhIHRlc3QgZm9yIGxpYmljb252IGFuZAo+IHlhamwveWFq
bF92ZXJzaW9uLmguCgpUaGVyZSBzZWVtcyB0byBiZSBhIGxvdCBtb3JlIHRlc3RzIGluIHRoZSBj
b25maWd1cmUuYWMgdGhhbiB0aGVyZSBldmVyCndlcmUgdW5kZXIgdG9vbHMvY2hlY2sgdGhvdWdo
PyBBbGwgc29ydHMgb2YgaGVhZGVycyBhbmQgZnVuY3Rpb24gY2hlY2tzCmV0Yy4gRGlkIHRoZXkg
Y29tZSBmcm9tIGF1dG9zY2FuPyAoYXV0b3NjYW4gaXMgbmV3IHRvIG1lLi4uKQoKPiA+IEl0IG1p
Z2h0Cj4gPiBoYXZlIGJlZW4gYmV0dGVyIGZvciByZXZpZXcgdG8gcHJlc2VudCB0aGlzIGFzIGEg
YmFzaWMgaW5mcmFzdHJ1Y3R1cmUKPiA+IHBhdGNoLCB0aGUgY29udmVyc2lvbiBvZiBlYWNoIHRl
c3QgaW5kaXZpZHVhbGx5IGFzIGEgcGF0Y2ggZWFjaCBhbmQKPiA+IGxhc3RseSBhbnkgbmV3IHRl
c3RzIGV0YyBzbyB3ZSBjb3VsZCBlYXNpbHkgcmV2aWV3LiBCdXQgSSB0aGluayBpdCdzIGEKPiA+
IGJpdCBsYXRlIG5vdyBhbmQgdGhlcmUncyBubyBwb2ludCBzcGxpdHRpbmcgdGhpcyBwYXRjaCB1
cCBub3cgeW91J3ZlIGdvdAo+ID4gaXQuCj4gCj4gRWFjaCB0ZXN0IGhhcyBpdCdzIG93biBtNCBm
aWxlIGluc2lkZSBtNC8sIGlmIGl0J3MgcmVhbGx5IGRpZmZpY3VsdCB0bwo+IHVuZGVyc3RhbmQg
KG00IGlzIG5vdCBlYXN5IGZvciB0aGUgZXllLCBhbHRob3VnaCBJIHRyaWVkIHRvIGZvbGxvdwo+
IGxpYnhsIENPRElOR19TVFlMRSksIEkgd2lsbCBzcGxpdCBpdCB1cCBpbiBzZXZlcmFsIHBhdGNo
ZXMgKG9uZSBmb3IKPiBlYWNoIG00LyBhbmQgb25lIGZvciB0aGUgcmVzdCBvZiB0aGUgYXV0b3Rv
b2xzIGluZnJhc3RydWN0dXJlKS4KCkkgZ3Vlc3MgbW9zdCBvZiB0aGUgc3R1ZmYgd2FzIGZyb20g
YXV0b3NjYW4gY2FuJ3QgbG9naWNhbGx5IGJlIHNwbGl0IHVwLApzbyBkb24ndCB3b3JyeS4KCj4g
PiBbLi4uXQo+ID4+ICtBU19JRihbdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSJdLCBbCj4gPj4g
KyAgICBBQ19QUk9HX09DQU1MCj4gPj4gKyAgICBBU19JRihbdGVzdCAieCRPQ0FNTEMiID0gInhu
byJdLCBbCj4gPj4gKyAgICAgIEFDX01TR19FUlJPUihbWW91IG11c3QgaW5zdGFsbCB0aGUgT0Nh
bWwgY29tcGlsZXJdKQo+ID4KPiA+IG9jYW1sIHdhcyBwcmV2aW91c2x5IG9wdGlvbmFsLCBJIHRo
aW5rLgo+IAo+IE9rLCBJIHdpbGwgc2V0IHRvIGRpc2FibGVkIGJ5IGRlZmF1bHQgdGhlbi4KCkJ5
IGRlZmF1bHQgaXQgc2hvdWxkIGJlIGVuYWJsZWQgaWYgdGhlIG5lY2Vzc2FyeSBiaXRzIGFyZSBw
cmVzZW50IGFuZApkaXNhYmxlZCBvdGhlcndpc2UuCgpbLi4uXQo+ID4gVGhlcmUncyBubyBBQ19U
WVBFX1NURElOVCBvciBzaW1pbGFyPwo+IAo+IFRoaXMgd2FzIGF1dG9tYXRpY2FsbHkgZG9uZSBi
eSBhdXRvc2NhbiwgYW5kIEkndmUgdHJpZWQgc2VhcmNoaW5nIGZvcgo+IHNvbWV0aGluZyBsaWtl
IEFDX1RZUEVfU1RESU5ULCBidXQgSSBoYXZlbid0IGJlZW4gYWJsZSB0byBmaW5kCj4gYW55dGhp
bmcuIElmIHlvdSB3YW50IEkgY2FuIGJ1bmRsZSB0aGUgSU5UIGNoZWNrcyBpbnNpZGUgYSBtYWNy
bwo+IGNhbGxlZCBBWF9UWVBFX1NURElOVC4KWy4uLl0KPiA+IElzIHRoZXJlIG5vdCBzb21lIHVt
YnJlbGxhIHRlc3QgZm9yIHRoZXNlIHNvcnRzIG9mIHZlcnkgc3RhbmRhcmQgdGhpbmdzLAo+ID4g
ZS5nLiBBQ19QT1NJWCBvciBzb21ldGhpbmcgbGlrZSB0aGF0Pwo+IAo+IEFnYWluLCB0aGUgc2Ft
ZSBhcyBhYm92ZS4KCkxldHMganVzdCBsZWF2ZSBpdCB0aGVuLgoKPiA+IElzbid0IHRoZSBtYW5h
Z2VtZW50IG9mIHRoZXNlIHNuaXBwZXRzIHRoZSBzb3J0IG9mIHRoaW5nIGFjbG9jYWwgZG9lcwo+
ID4gZm9yIHlvdT8KPiAKPiBhY2xvY2FsIGp1c3Qgc2NhbnMgY29uZmlndXJlLmFjIGFuZCBjb25j
YXRlbmF0ZXMgYWxsIG5lY2Vzc2FyeSBtYWNyb3MKPiBpbnRvIGFjbG9jYWwubTQsIEkndmUgdHJp
ZWQgdG8gdXNlIGFsbCB0aGUgcHJlZGVmaW5lZCBtYWNyb3MgSSBjb3VsZCwKPiBhbmQgbW9zdCBv
ZiB0aGUgZmlsZXMgaW5zaWRlIG00LyogYXJlIGp1c3Qgd3JhcHBlcnMgdG8gbWFrZQo+IGNvbmZp
Z3VyZS5hYyBjbGVhbmVyIGFuZCBlYXNpZXIgdG8gdW5kZXJzdGFuZC4KCk9LLgoKPiA+IFsuLi5d
Cj4gPj4gZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZTEyZWMxMDcxNDEwIG00L29jYW1sLm00Cj4g
Pj4gLS0tIC9kZXYvbnVsbCAgIFRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAo+ID4+ICsr
KyBiL200L29jYW1sLm00ICAgICAgIFNhdCBKYW4gMDcgMDQ6MTc6MTAgMjAxMiArMDEwMAo+ID4+
IEBAIC0wLDAgKzEsMjQwIEBACj4gPj4gK2RubCBhdXRvY29uZiBtYWNyb3MgZm9yIE9DYW1sCj4g
Pgo+ID4gUGxlYXNlIGFkZCBhIGNvbW1lbnQgZGVzY3JpYmluZyB3aGVyZSB0aGlzIGNhbWUgZnJv
bSBzbyB3ZSBrbm93IGhvdyB0bwo+ID4gdXBkYXRlIGluIHRoZSBmdXR1cmUuCj4gPgo+ID4gU2hv
dWxkbid0L2NvdWxkbid0IHRoaXMgYmUgcHJvdmlkZWQgYnkgdGhlIG9jYW1sIHBhY2thZ2VzIGFu
ZCBqdXN0Cj4gPiBpbmNsdWRlZCBieSB1cz8KPiAKPiBUaGlzIGNvbWVzIGZyb20gaHR0cDovL2Zv
cmdlLm9jYW1sY29yZS5vcmcvLCBhbmQgdGhlIG1hbnBhZ2Ugc3RhdGVzIHRoYXQ6Cj4gCj4gIlRv
IGJlZ2luIHVzaW5nIHRoZXNlIG1hY3JvcywgeW91IHdpbGwgbmVlZCB0byBjb3B5IHRoZSBvY2Ft
bC5tNCBmaWxlCj4gKHVzdWFsbHkgbG9jYXRlZCBhdCAvdXNyL3NoYXJlL2FjbG9jYWwvb2NhbWwu
bTQpIHRvIHRoZSBhdXRvY29uZgo+IG1hY3JvcyBkaXJlY3RvcnkgaW4geW91ciBwcm9qZWN0LiBO
b3JtYWxseSB0aGlzIGlzIHRoZSBtNC8gZGlyZWN0b3J5Cj4gaW4geW91ciBwcm9qZWN0LCBidXQg
dGhlIGRpcmVjdG9yeSBjYW4gYmUgY2hhbmdlZCB1c2luZyB0aGUKPiBBQ19DT05GSUdfTUFDUk9f
RElSKERJUikgZGlyZWN0aXZlLiIKPiAKPiBUaGF0J3Mgd2h5IEkgY29waWVkIGl0IHRvIG00LwoK
RmFpciBlbm91Z2ghCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 09 14:59:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 14:59:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkGgV-0008VD-I5; Mon, 09 Jan 2012 14:58:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RkGgU-0008V5-Kb
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 14:58:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326121089!55188242!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc2OTk2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3370 invoked from network); 9 Jan 2012 14:58:11 -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; 9 Jan 2012 14:58:11 -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
	q09Ewc4S014161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 14:58:39 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
	q09EwaVo024084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 14:58:37 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
	q09EwXVT000708; Mon, 9 Jan 2012 08:58:34 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 06:58:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 23AB04094B; Mon,  9 Jan 2012 09:56:48 -0500 (EST)
Date: Mon, 9 Jan 2012 09:56:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120109145648.GA25563@phenom.dumpdata.com>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F0B00A0.00CC,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> On Mon, 9 Jan 2012, Andrew Jones wrote:
> > ----- Original Message -----
> > > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > > XEN_DOM0 is a silent option that has been automatically selected
> > > > when
> > > > CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was
> > > > changed
> > > > to a menu configurable option then it would only give users the
> > > > ability
> > > > to compile out about 100 kbytes of code.
> > > 
> > > I think that it is less than that because backends are not tied to
> > > dom0
> > > in any way, even though currently they cannot be compiled without
> > > XEN_DOM0.
> > > Running a network or block backend in domU is a well known
> > > configuration.
> > > Therefore the code compiled out only amounts to about 10K.
> > > 
> > > 
> > > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > > > index 8795480..0725228 100644
> > > > --- a/drivers/xen/Kconfig
> > > > +++ b/drivers/xen/Kconfig
> > > > @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
> > > >  
> > > >  config XEN_BACKEND
> > > >  	bool "Backend driver support"
> > > > -	depends on XEN_DOM0
> > > >  	default y
> > > > +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > > > +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > >  	help
> > > >  	  Support for backend device drivers that provide I/O services
> > > >  	  to other virtual machines.
> > > 
> > > I think we can trimmer the dependency list here: after all backends
> > > can
> > > be run in unpriviledged guests as well (see driver domains).
> > > So I think it should depend only on XEN.
> > 
> > Hmm.. Actually, with dependency lists in mind, I think a really messed
> > this patch up. I should have either had CONFIG_XEN inherit these deps,
> > or I should have spread them around to be required at only the specific
> > places they're needed, and then left the stub functions in. Neither of
> > those options seems like a good idea to me. We either force all XEN
> > guests to always have all the deps needed for an initial domain, which
> > is exactly the opposite of the suggestion above (trimming XEN_BACKEND
> > deps for driver domains), or we actually make the code messier and
> > more complicated with more #ifdefs, which are now neatly packaged with
> > XEN_DOM0.
> 
> I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
> X86_IO_APIC && ACPI && PCI" to XEN either.
> However it should be possible to add only the right dependencies to the
> right places.
> In practice it should be sufficient to:
> 
> - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;

Not good. You can make non-ACPI builds with PCI.

.. and you are missing CONFIG_PCI in there.
> 
> - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;

OK. That sounds good.
> 
> - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.

No.. same issue - non-ACPI builds can be with PCI.
> 
> 
> 
> > The driver domain concept may actually be the technical need for
> > making XEN_DOM0 optional. If we want the ability to build a minimally
> > configed XEN kernel to be used as a driver domain, then it doesn't
> > seem like we'd want it to also be capable of running as an initial
> > domain, or to be forced to have all the dependencies and code of an
> > initial domain.
> 
> In practice any decent driver domain needs PCI and ACPI support, so
> basically it has the same config requirement of XEN_DOM0. At that point

Sure.. for backends. But for frontends that requirement is not always true.

> we have already discussed that having XEN_DOM0 enabled or disabled
> hardly makes any differences, so we can just get rid of it.

Or in other words, substitute it as CONFIG_PCI_XEN.

But this brings a question about MCE, ACPI cpu freq and ACPI S3.
Those all belong to the dom0 - not to any driver domain. So getting rid
of CONFIG_XEN_DOM0 would present a problem - what would those depend on?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 14:59:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 14:59:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkGgV-0008VD-I5; Mon, 09 Jan 2012 14:58:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RkGgU-0008V5-Kb
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 14:58:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326121089!55188242!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc2OTk2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3370 invoked from network); 9 Jan 2012 14:58:11 -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; 9 Jan 2012 14:58:11 -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
	q09Ewc4S014161
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 14:58:39 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
	q09EwaVo024084
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 14:58:37 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
	q09EwXVT000708; Mon, 9 Jan 2012 08:58:34 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 06:58:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 23AB04094B; Mon,  9 Jan 2012 09:56:48 -0500 (EST)
Date: Mon, 9 Jan 2012 09:56:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120109145648.GA25563@phenom.dumpdata.com>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F0B00A0.00CC,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> On Mon, 9 Jan 2012, Andrew Jones wrote:
> > ----- Original Message -----
> > > On Fri, 6 Jan 2012, Andrew Jones wrote:
> > > > XEN_DOM0 is a silent option that has been automatically selected
> > > > when
> > > > CONFIG_XEN is selected since 6b0661a5e6fbf. If this option was
> > > > changed
> > > > to a menu configurable option then it would only give users the
> > > > ability
> > > > to compile out about 100 kbytes of code.
> > > 
> > > I think that it is less than that because backends are not tied to
> > > dom0
> > > in any way, even though currently they cannot be compiled without
> > > XEN_DOM0.
> > > Running a network or block backend in domU is a well known
> > > configuration.
> > > Therefore the code compiled out only amounts to about 10K.
> > > 
> > > 
> > > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > > > index 8795480..0725228 100644
> > > > --- a/drivers/xen/Kconfig
> > > > +++ b/drivers/xen/Kconfig
> > > > @@ -78,8 +78,9 @@ config XEN_DEV_EVTCHN
> > > >  
> > > >  config XEN_BACKEND
> > > >  	bool "Backend driver support"
> > > > -	depends on XEN_DOM0
> > > >  	default y
> > > > +	depends on XEN && PCI_XEN && SWIOTLB_XEN
> > > > +	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> > > >  	help
> > > >  	  Support for backend device drivers that provide I/O services
> > > >  	  to other virtual machines.
> > > 
> > > I think we can trimmer the dependency list here: after all backends
> > > can
> > > be run in unpriviledged guests as well (see driver domains).
> > > So I think it should depend only on XEN.
> > 
> > Hmm.. Actually, with dependency lists in mind, I think a really messed
> > this patch up. I should have either had CONFIG_XEN inherit these deps,
> > or I should have spread them around to be required at only the specific
> > places they're needed, and then left the stub functions in. Neither of
> > those options seems like a good idea to me. We either force all XEN
> > guests to always have all the deps needed for an initial domain, which
> > is exactly the opposite of the suggestion above (trimming XEN_BACKEND
> > deps for driver domains), or we actually make the code messier and
> > more complicated with more #ifdefs, which are now neatly packaged with
> > XEN_DOM0.
> 
> I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
> X86_IO_APIC && ACPI && PCI" to XEN either.
> However it should be possible to add only the right dependencies to the
> right places.
> In practice it should be sufficient to:
> 
> - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;

Not good. You can make non-ACPI builds with PCI.

.. and you are missing CONFIG_PCI in there.
> 
> - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;

OK. That sounds good.
> 
> - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.

No.. same issue - non-ACPI builds can be with PCI.
> 
> 
> 
> > The driver domain concept may actually be the technical need for
> > making XEN_DOM0 optional. If we want the ability to build a minimally
> > configed XEN kernel to be used as a driver domain, then it doesn't
> > seem like we'd want it to also be capable of running as an initial
> > domain, or to be forced to have all the dependencies and code of an
> > initial domain.
> 
> In practice any decent driver domain needs PCI and ACPI support, so
> basically it has the same config requirement of XEN_DOM0. At that point

Sure.. for backends. But for frontends that requirement is not always true.

> we have already discussed that having XEN_DOM0 enabled or disabled
> hardly makes any differences, so we can just get rid of it.

Or in other words, substitute it as CONFIG_PCI_XEN.

But this brings a question about MCE, ACPI cpu freq and ACPI S3.
Those all belong to the dom0 - not to any driver domain. So getting rid
of CONFIG_XEN_DOM0 would present a problem - what would those depend on?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:07:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15: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 1RkGoo-0000Jf-Kg; Mon, 09 Jan 2012 15:07:26 +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 1RkGom-0000Ja-M4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:07:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326121636!7041155!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8451 invoked from network); 9 Jan 2012 15:07:18 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 15:07:18 -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
	q09F7Gp4016993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 9 Jan 2012 15:07:16 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
	q09F6Oba004486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 15:06:25 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
	q09F6Nvs016262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 15:06:24 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
	q09F6M0x022671; Mon, 9 Jan 2012 09:06:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 07:06:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 14DD44094B; Mon,  9 Jan 2012 10:04:37 -0500 (EST)
Date: Mon, 9 Jan 2012 10:04:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120109150436.GD25563@phenom.dumpdata.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F0B0272.0025,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> > But more interestingly - are you building your kernel from scratch? There
> 
> yes
> 
> > was some requirements in having CONFIG_IOMMU_DMAR in the kernels -
> > otherwise
> > the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.
> 
> Suppose you mean CONFIG_DMAR_TABLE? There's no CONFIG_IOMMU_DMAR
> in the latest kernel. Yes, I didn't enable that option, and will have a try.

Yes, that is the option.

> 
> But a side question is, will enabling VT-d in dom0 conflict with Xen's own
> VT-d operations?

No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux's
parser won't pick it up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:07:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15: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 1RkGoo-0000Jf-Kg; Mon, 09 Jan 2012 15:07:26 +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 1RkGom-0000Ja-M4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:07:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326121636!7041155!1
X-Originating-IP: [141.146.126.236]
X-SpamReason: No, hits=0.0 required=7.0 tests=UNPARSEABLE_RELAY
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8451 invoked from network); 9 Jan 2012 15:07:18 -0000
Received: from acsinet14.oracle.com (HELO acsinet14.oracle.com)
	(141.146.126.236)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 15:07:18 -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
	q09F7Gp4016993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 9 Jan 2012 15:07:16 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
	q09F6Oba004486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 15:06:25 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
	q09F6Nvs016262
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 15:06:24 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
	q09F6M0x022671; Mon, 9 Jan 2012 09:06:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 07:06:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 14DD44094B; Mon,  9 Jan 2012 10:04:37 -0500 (EST)
Date: Mon, 9 Jan 2012 10:04:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120109150436.GD25563@phenom.dumpdata.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F0B0272.0025,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> > But more interestingly - are you building your kernel from scratch? There
> 
> yes
> 
> > was some requirements in having CONFIG_IOMMU_DMAR in the kernels -
> > otherwise
> > the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.
> 
> Suppose you mean CONFIG_DMAR_TABLE? There's no CONFIG_IOMMU_DMAR
> in the latest kernel. Yes, I didn't enable that option, and will have a try.

Yes, that is the option.

> 
> But a side question is, will enabling VT-d in dom0 conflict with Xen's own
> VT-d operations?

No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux's
parser won't pick it up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:14:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:14:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkGua-0000Sr-Hr; Mon, 09 Jan 2012 15:13: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 1RkGuY-0000Sm-HT
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:13:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326121956!55191036!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3OTM1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22952 invoked from network); 9 Jan 2012 15:12:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 15:12:37 -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
	q09FDCSI014261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 15:13:13 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
	q09FDAO8020375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 15:13:11 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q09FDAO2028387; Mon, 9 Jan 2012 09:13:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 07:13:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E1CF04094B; Mon,  9 Jan 2012 10:11:24 -0500 (EST)
Date: Mon, 9 Jan 2012 10:11:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120109151124.GE25563@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
	<1326102657.17210.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326102657.17210.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F0B0409.008B,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 09, 2012 at 09:50:57AM +0000, Ian Campbell wrote:
> On Fri, 2012-01-06 at 22:19 +0000, Konrad Rzeszutek Wilk wrote:
> > > > I suppose you might want "Overriding ownership to dom%d".
> > > 
> > > OK. To the point and potentially can fit in 80 lines :-).
> > 
> > how about this?
> > > 
> > From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Wed, 4 Jan 2012 14:16:45 -0500
> > Subject: [PATCH] xen/pciback: Expand the warning message to include domain
> >  id.
> > 
> > When a PCI device is transferred to another domain and it is still
> > in usage (from the internal perspective), mention which other
> > domain is using it to aid in debugging.
> > 
> > [v2: Truncate the verbose message per Jan Beulich suggestion]
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/xen/xen-pciback/xenbus.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > index 474d52e..2405a24 100644
> > --- a/drivers/xen/xen-pciback/xenbus.c
> > +++ b/drivers/xen/xen-pciback/xenbus.c
> > @@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
> >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> >  	if (xen_register_device_domain_owner(dev,
> >  					     pdev->xdev->otherend_id) != 0) {
> > -		dev_err(&dev->dev, "device has been assigned to another " \
> > -			"domain! Over-writting the ownership, but beware.\n");
> > +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> > +			xen_find_device_domain_owner(dev));
> 
> That sounds like you are going to be assigning the ownership to that
> dom, but xen_find_device_domain_owner so aren't you actually steeling
> ownership from that domain?

Duh! I will do s/to/from/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:14:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:14:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkGua-0000Sr-Hr; Mon, 09 Jan 2012 15:13: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 1RkGuY-0000Sm-HT
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:13:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326121956!55191036!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3OTM1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22952 invoked from network); 9 Jan 2012 15:12:37 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 15:12:37 -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
	q09FDCSI014261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 15:13:13 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
	q09FDAO8020375
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 15:13:11 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q09FDAO2028387; Mon, 9 Jan 2012 09:13:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 07:13:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E1CF04094B; Mon,  9 Jan 2012 10:11:24 -0500 (EST)
Date: Mon, 9 Jan 2012 10:11:24 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120109151124.GE25563@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
	<1326102657.17210.11.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326102657.17210.11.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F0B0409.008B,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 09, 2012 at 09:50:57AM +0000, Ian Campbell wrote:
> On Fri, 2012-01-06 at 22:19 +0000, Konrad Rzeszutek Wilk wrote:
> > > > I suppose you might want "Overriding ownership to dom%d".
> > > 
> > > OK. To the point and potentially can fit in 80 lines :-).
> > 
> > how about this?
> > > 
> > From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Wed, 4 Jan 2012 14:16:45 -0500
> > Subject: [PATCH] xen/pciback: Expand the warning message to include domain
> >  id.
> > 
> > When a PCI device is transferred to another domain and it is still
> > in usage (from the internal perspective), mention which other
> > domain is using it to aid in debugging.
> > 
> > [v2: Truncate the verbose message per Jan Beulich suggestion]
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > ---
> >  drivers/xen/xen-pciback/xenbus.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > index 474d52e..2405a24 100644
> > --- a/drivers/xen/xen-pciback/xenbus.c
> > +++ b/drivers/xen/xen-pciback/xenbus.c
> > @@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
> >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> >  	if (xen_register_device_domain_owner(dev,
> >  					     pdev->xdev->otherend_id) != 0) {
> > -		dev_err(&dev->dev, "device has been assigned to another " \
> > -			"domain! Over-writting the ownership, but beware.\n");
> > +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> > +			xen_find_device_domain_owner(dev));
> 
> That sounds like you are going to be assigning the ownership to that
> dom, but xen_find_device_domain_owner so aren't you actually steeling
> ownership from that domain?

Duh! I will do s/to/from/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:17:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 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 1RkGxu-0000aA-5w; Mon, 09 Jan 2012 15:16:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkGxs-0000Zw-TI
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:16:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326122202!7711088!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29157 invoked from network); 9 Jan 2012 15:16:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 15:16:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9899758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 15:16:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 9 Jan 2012
	15:16:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 9 Jan 2012 15:16:12 +0000
In-Reply-To: <20120109151124.GE25563@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
	<1326102657.17210.11.camel@zakaz.uk.xensource.com>
	<20120109151124.GE25563@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326122172.17210.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 15:11 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 09, 2012 at 09:50:57AM +0000, Ian Campbell wrote:
> > On Fri, 2012-01-06 at 22:19 +0000, Konrad Rzeszutek Wilk wrote:
> > > > > I suppose you might want "Overriding ownership to dom%d".
> > > > 
> > > > OK. To the point and potentially can fit in 80 lines :-).
> > > 
> > > how about this?
> > > > 
> > > From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
> > > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Date: Wed, 4 Jan 2012 14:16:45 -0500
> > > Subject: [PATCH] xen/pciback: Expand the warning message to include domain
> > >  id.
> > > 
> > > When a PCI device is transferred to another domain and it is still
> > > in usage (from the internal perspective), mention which other
> > > domain is using it to aid in debugging.
> > > 
> > > [v2: Truncate the verbose message per Jan Beulich suggestion]
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/xen/xen-pciback/xenbus.c |    4 ++--
> > >  1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > > index 474d52e..2405a24 100644
> > > --- a/drivers/xen/xen-pciback/xenbus.c
> > > +++ b/drivers/xen/xen-pciback/xenbus.c
> > > @@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
> > >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> > >  	if (xen_register_device_domain_owner(dev,
> > >  					     pdev->xdev->otherend_id) != 0) {
> > > -		dev_err(&dev->dev, "device has been assigned to another " \
> > > -			"domain! Over-writting the ownership, but beware.\n");
> > > +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> > > +			xen_find_device_domain_owner(dev));
> > 
> > That sounds like you are going to be assigning the ownership to that
> > dom, but xen_find_device_domain_owner so aren't you actually steeling
> > ownership from that domain?
> 
> Duh! I will do s/to/from/

Maybe s/Overriding/Stealing/ too? "Overriding ownership from xxx" sounds
a bit odd to me.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:17:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 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 1RkGxu-0000aA-5w; Mon, 09 Jan 2012 15:16:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkGxs-0000Zw-TI
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:16:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326122202!7711088!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29157 invoked from network); 9 Jan 2012 15:16:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 15:16:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9899758"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 15:16:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 9 Jan 2012
	15:16:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 9 Jan 2012 15:16:12 +0000
In-Reply-To: <20120109151124.GE25563@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
	<1326102657.17210.11.camel@zakaz.uk.xensource.com>
	<20120109151124.GE25563@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326122172.17210.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 15:11 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 09, 2012 at 09:50:57AM +0000, Ian Campbell wrote:
> > On Fri, 2012-01-06 at 22:19 +0000, Konrad Rzeszutek Wilk wrote:
> > > > > I suppose you might want "Overriding ownership to dom%d".
> > > > 
> > > > OK. To the point and potentially can fit in 80 lines :-).
> > > 
> > > how about this?
> > > > 
> > > From a3d4a80cdfd4274016522572148a89260b3f3de6 Mon Sep 17 00:00:00 2001
> > > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > Date: Wed, 4 Jan 2012 14:16:45 -0500
> > > Subject: [PATCH] xen/pciback: Expand the warning message to include domain
> > >  id.
> > > 
> > > When a PCI device is transferred to another domain and it is still
> > > in usage (from the internal perspective), mention which other
> > > domain is using it to aid in debugging.
> > > 
> > > [v2: Truncate the verbose message per Jan Beulich suggestion]
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > > ---
> > >  drivers/xen/xen-pciback/xenbus.c |    4 ++--
> > >  1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
> > > index 474d52e..2405a24 100644
> > > --- a/drivers/xen/xen-pciback/xenbus.c
> > > +++ b/drivers/xen/xen-pciback/xenbus.c
> > > @@ -243,8 +243,8 @@ static int xen_pcibk_export_device(struct xen_pcibk_device *pdev,
> > >  	dev_dbg(&dev->dev, "registering for %d\n", pdev->xdev->otherend_id);
> > >  	if (xen_register_device_domain_owner(dev,
> > >  					     pdev->xdev->otherend_id) != 0) {
> > > -		dev_err(&dev->dev, "device has been assigned to another " \
> > > -			"domain! Over-writting the ownership, but beware.\n");
> > > +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> > > +			xen_find_device_domain_owner(dev));
> > 
> > That sounds like you are going to be assigning the ownership to that
> > dom, but xen_find_device_domain_owner so aren't you actually steeling
> > ownership from that domain?
> 
> Duh! I will do s/to/from/

Maybe s/Overriding/Stealing/ too? "Overriding ownership from xxx" sounds
a bit odd to me.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:25:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkH5i-0000n5-4y; Mon, 09 Jan 2012 15:24:54 +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 1RkH5g-0000n0-D0
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:24:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326122685!10228226!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3OTM1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15470 invoked from network); 9 Jan 2012 15:24:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 15:24:46 -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
	q09FOgkh029812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 15:24:43 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
	q09FOehk011347
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 15:24:41 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
	q09FOec0022733; Mon, 9 Jan 2012 09:24:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 07:24:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA2F54094B; Mon,  9 Jan 2012 10:22:54 -0500 (EST)
Date: Mon, 9 Jan 2012 10:22:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120109152254.GA26880@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
	<1326102657.17210.11.camel@zakaz.uk.xensource.com>
	<20120109151124.GE25563@phenom.dumpdata.com>
	<1326122172.17210.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326122172.17210.109.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F0B06BB.00C1,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > > > -		dev_err(&dev->dev, "device has been assigned to another " \
> > > > -			"domain! Over-writting the ownership, but beware.\n");
> > > > +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> > > > +			xen_find_device_domain_owner(dev));
> > > 
> > > That sounds like you are going to be assigning the ownership to that
> > > dom, but xen_find_device_domain_owner so aren't you actually steeling
> > > ownership from that domain?
> > 
> > Duh! I will do s/to/from/
> 
> Maybe s/Overriding/Stealing/ too? "Overriding ownership from xxx" sounds
> a bit odd to me.

Bingo! "Stealing ownership from dom%d." it is!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:25:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:25:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkH5i-0000n5-4y; Mon, 09 Jan 2012 15:24:54 +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 1RkH5g-0000n0-D0
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:24:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326122685!10228226!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3OTM1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15470 invoked from network); 9 Jan 2012 15:24:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 15:24:46 -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
	q09FOgkh029812
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 15:24:43 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
	q09FOehk011347
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 15:24:41 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
	q09FOec0022733; Mon, 9 Jan 2012 09:24:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 07:24:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA2F54094B; Mon,  9 Jan 2012 10:22:54 -0500 (EST)
Date: Mon, 9 Jan 2012 10:22:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120109152254.GA26880@phenom.dumpdata.com>
References: <1325724403-29642-1-git-send-email-konrad.wilk@oracle.com>
	<1325724403-29642-5-git-send-email-konrad.wilk@oracle.com>
	<4F06C101020000780006AC32@nat28.tlf.novell.com>
	<20120106150338.GB5855@phenom.dumpdata.com>
	<1325865086.25206.512.camel@zakaz.uk.xensource.com>
	<20120106160011.GD6125@phenom.dumpdata.com>
	<20120106221927.GA10248@phenom.dumpdata.com>
	<1326102657.17210.11.camel@zakaz.uk.xensource.com>
	<20120109151124.GE25563@phenom.dumpdata.com>
	<1326122172.17210.109.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326122172.17210.109.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090206.4F0B06BB.00C1,ss=1,re=0.000,fgs=0
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>
Subject: Re: [Xen-devel] [PATCH 4/5] xen/pciback: Expand the warning message
 to include domain id.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > > > -		dev_err(&dev->dev, "device has been assigned to another " \
> > > > -			"domain! Over-writting the ownership, but beware.\n");
> > > > +		dev_err(&dev->dev, "Overriding ownership to dom%d.\n",
> > > > +			xen_find_device_domain_owner(dev));
> > > 
> > > That sounds like you are going to be assigning the ownership to that
> > > dom, but xen_find_device_domain_owner so aren't you actually steeling
> > > ownership from that domain?
> > 
> > Duh! I will do s/to/from/
> 
> Maybe s/Overriding/Stealing/ too? "Overriding ownership from xxx" sounds
> a bit odd to me.

Bingo! "Stealing ownership from dom%d." it is!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:26:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:26:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkH6p-0000pv-KR; Mon, 09 Jan 2012 15:26: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 1RkH6n-0000pj-W9
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:26:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326122715!49482067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22739 invoked from network); 9 Jan 2012 15:25: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;
	9 Jan 2012 15:25:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9899918"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 15:24:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 15:24:58 +0000
Date: Mon, 9 Jan 2012 15:25:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F097253.5080600@redhat.com>
Message-ID: <alpine.DEB.2.00.1201091509590.3150@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<alpine.DEB.2.00.1201061417480.3150@kaball-deskto! p>
	<4F097253.5080600@redhat.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>, Jan Kiszka <jan.kiszka@web.de>,
	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 Sun, 8 Jan 2012, Avi Kivity wrote:
> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> > Avi, if you think that early_savevm is a decent solution, we'll start
> > working on it. 
> 
> I don't like early_savevm because it complicates life for devices, for
> what is a localized problem.  But if everything else is even more
> complicated maybe we should do it.

I have been thinking more about this issue but unfortunately I cannot
come up with anything better than early_savevm.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:26:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:26:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkH6p-0000pv-KR; Mon, 09 Jan 2012 15:26: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 1RkH6n-0000pj-W9
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:26:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326122715!49482067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22739 invoked from network); 9 Jan 2012 15:25: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;
	9 Jan 2012 15:25:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9899918"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 15:24:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 15:24:58 +0000
Date: Mon, 9 Jan 2012 15:25:01 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F097253.5080600@redhat.com>
Message-ID: <alpine.DEB.2.00.1201091509590.3150@kaball-desktop>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<4EE609BF.1070307@siemens.com>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<alpine.DEB.2.00.1201061417480.3150@kaball-deskto! p>
	<4F097253.5080600@redhat.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>, Jan Kiszka <jan.kiszka@web.de>,
	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 Sun, 8 Jan 2012, Avi Kivity wrote:
> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> > Avi, if you think that early_savevm is a decent solution, we'll start
> > working on it. 
> 
> I don't like early_savevm because it complicates life for devices, for
> what is a localized problem.  But if everything else is even more
> complicated maybe we should do it.

I have been thinking more about this issue but unfortunately I cannot
come up with anything better than early_savevm.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:28:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkH91-00010X-CH; Mon, 09 Jan 2012 15:28:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RkH8z-000103-Ma
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:28:17 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326122891!8336463!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMxNzA4Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16364 invoked from network); 9 Jan 2012 15:28:11 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 15:28:11 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q09FS3JG026489;
	Mon, 9 Jan 2012 16:28:03 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q09FS2wh018376;
	Mon, 9 Jan 2012 16:28:02 +0100
Message-ID: <4F0B0782.4090606@siemens.com>
Date: Mon, 09 Jan 2012 16:28:02 +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>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<alpine.DEB.2.00.1201061417480.3150@kaball-deskto! p>
	<4F097253.5080600@redhat.com>
	<alpine.DEB.2.00.1201091509590.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201091509590.3150@kaball-desktop>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.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 2012-01-09 16:25, Stefano Stabellini wrote:
> On Sun, 8 Jan 2012, Avi Kivity wrote:
>> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
>>> Avi, if you think that early_savevm is a decent solution, we'll start
>>> working on it. 
>>
>> I don't like early_savevm because it complicates life for devices, for
>> what is a localized problem.  But if everything else is even more
>> complicated maybe we should do it.
> 
> I have been thinking more about this issue but unfortunately I cannot
> come up with anything better than early_savevm.

And I do not yet see the impact of the early_savevm concept on devices.
Its point is to have some vmstate that is unrelated, actually predates
any device creation (during restore).

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 Jan 09 15:28:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkH91-00010X-CH; Mon, 09 Jan 2012 15:28:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RkH8z-000103-Ma
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:28:17 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326122891!8336463!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMxNzA4Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16364 invoked from network); 9 Jan 2012 15:28:11 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 15:28:11 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q09FS3JG026489;
	Mon, 9 Jan 2012 16:28:03 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q09FS2wh018376;
	Mon, 9 Jan 2012 16:28:02 +0100
Message-ID: <4F0B0782.4090606@siemens.com>
Date: Mon, 09 Jan 2012 16:28:02 +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>
	<alpine.DEB.2.00.1112121438410.3517@kaball-desktop>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<alpine.DEB.2.00.1201061417480.3150@kaball-deskto! p>
	<4F097253.5080600@redhat.com>
	<alpine.DEB.2.00.1201091509590.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201091509590.3150@kaball-desktop>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.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 2012-01-09 16:25, Stefano Stabellini wrote:
> On Sun, 8 Jan 2012, Avi Kivity wrote:
>> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
>>> Avi, if you think that early_savevm is a decent solution, we'll start
>>> working on it. 
>>
>> I don't like early_savevm because it complicates life for devices, for
>> what is a localized problem.  But if everything else is even more
>> complicated maybe we should do it.
> 
> I have been thinking more about this issue but unfortunately I cannot
> come up with anything better than early_savevm.

And I do not yet see the impact of the early_savevm concept on devices.
Its point is to have some vmstate that is unrelated, actually predates
any device creation (during restore).

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 Jan 09 15:37:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHHI-0001Hf-CJ; Mon, 09 Jan 2012 15:36:52 +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 1RkHHG-0001HX-CL
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:36:50 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326123403!9629660!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDg4MjU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32568 invoked from network); 9 Jan 2012 15:36:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 15:36: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 q09FadSN019729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 10:36:39 -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 q09FaX93007700; Mon, 9 Jan 2012 10:36:34 -0500
Message-ID: <4F0B0980.50306@redhat.com>
Date: Mon, 09 Jan 2012 17:36:32 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<alpine.DEB.2.00.1201061417480.3150@kaball-deskto! p>
	<4F097253.5080600@redhat.com>
	<alpine.DEB.2.00.1201091509590.3150@kaball-desktop>
	<4F0B0782.4090606@siemens.com>
In-Reply-To: <4F0B0782.4090606@siemens.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
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 01/09/2012 05:28 PM, Jan Kiszka wrote:
> On 2012-01-09 16:25, Stefano Stabellini wrote:
> > On Sun, 8 Jan 2012, Avi Kivity wrote:
> >> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> >>> Avi, if you think that early_savevm is a decent solution, we'll start
> >>> working on it. 
> >>
> >> I don't like early_savevm because it complicates life for devices, for
> >> what is a localized problem.  But if everything else is even more
> >> complicated maybe we should do it.
> > 
> > I have been thinking more about this issue but unfortunately I cannot
> > come up with anything better than early_savevm.
>
> And I do not yet see the impact of the early_savevm concept on devices.
> Its point is to have some vmstate that is unrelated, actually predates
> any device creation (during restore).

Okay then, at least we tried.

-- 
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 Jan 09 15:37:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHHI-0001Hf-CJ; Mon, 09 Jan 2012 15:36:52 +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 1RkHHG-0001HX-CL
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:36:50 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326123403!9629660!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDg4MjU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32568 invoked from network); 9 Jan 2012 15:36:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 15:36: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 q09FadSN019729
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 10:36:39 -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 q09FaX93007700; Mon, 9 Jan 2012 10:36:34 -0500
Message-ID: <4F0B0980.50306@redhat.com>
Date: Mon, 09 Jan 2012 17:36:32 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@siemens.com>
References: <1323467645-24271-1-git-send-email-anthony.perard@citrix.com>
	<4EE617BA.4030102@siemens.com>
	<alpine.DEB.2.00.1112121527130.3517@kaball-desktop>
	<4EEE25DA.2080400@redhat.com>
	<alpine.DEB.2.00.1201041618390.3150@kaball-desktop>
	<4F048B10.1060505@redhat.com>
	<alpine.DEB.2.00.1201051134150.3150@kaball-desktop>
	<4F059C8C.2030303@redhat.com>
	<alpine.DEB.2.00.1201051303350.3150@kaball-desktop>
	<4F05A684.7000509@redhat.com>
	<alpine.DEB.2.00.1201051427340.3150@kaball-desktop>
	<4F05BF9E.7000203@redhat.com>
	<alpine.DEB.2.00.1201051536290.3150@kaball-desktop>
	<4F05D0BC.70707@redhat.com>
	<alpine.DEB.2.00.1201051646580.3150@kaball-desktop>
	<4F05E301.2020808@redhat.com> <4F05F09E.8030800@web.de>
	<alpine.DEB.2.00.1201061045550.3150@kaball-desktop>
	<4F06F76F.7090002@web.de>
	<alpine.DEB.2.00.1201061417480.3150@kaball-deskto! p>
	<4F097253.5080600@redhat.com>
	<alpine.DEB.2.00.1201091509590.3150@kaball-desktop>
	<4F0B0782.4090606@siemens.com>
In-Reply-To: <4F0B0782.4090606@siemens.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
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 01/09/2012 05:28 PM, Jan Kiszka wrote:
> On 2012-01-09 16:25, Stefano Stabellini wrote:
> > On Sun, 8 Jan 2012, Avi Kivity wrote:
> >> On 01/06/2012 04:40 PM, Stefano Stabellini wrote:
> >>> Avi, if you think that early_savevm is a decent solution, we'll start
> >>> working on it. 
> >>
> >> I don't like early_savevm because it complicates life for devices, for
> >> what is a localized problem.  But if everything else is even more
> >> complicated maybe we should do it.
> > 
> > I have been thinking more about this issue but unfortunately I cannot
> > come up with anything better than early_savevm.
>
> And I do not yet see the impact of the early_savevm concept on devices.
> Its point is to have some vmstate that is unrelated, actually predates
> any device creation (during restore).

Okay then, at least we tried.

-- 
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 Jan 09 15:44:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15: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 1RkHOZ-0001TV-EU; Mon, 09 Jan 2012 15:44:23 +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 1RkHOX-0001TQ-JU
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:44:21 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326123815!47838836!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjIzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9136 invoked from network); 9 Jan 2012 15:43:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-27.messagelabs.com with SMTP;
	9 Jan 2012 15:43:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 09 Jan 2012 07:44:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="105098916"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 09 Jan 2012 07:44:17 -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; Mon, 9 Jan 2012 23:44:17 +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; Mon, 9 Jan 2012 23:44:16 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Mon, 9 Jan 2012 23:44:15 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] x86: add a new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0P//f4kA//kqZjA=
Date: Mon, 9 Jan 2012 15:44:15 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE016B8D@SHSMSX102.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
In-Reply-To: <4F05CC48020000780006A9C7@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>, "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 new SMP bring up way for tboot
	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=A02012-01-05:
>>>> On 05.01.12 at 15:53, "Wei, Gang" <gang.wei@intel.com> wrote:
>> tboot may be trying to put APs waiting in MWAIT loops before launching X=
en.
>> Xen could check the new flag field in v6 tboot shared page for the
>> hint. If TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP
>> have to write the monitored memory(g_tboot_shared->ap_wake_trigger)
>> to bring APs out of MWAIT loops. The sipi vector should be written
>> in g_tboot_shared->ap_wake_addr before waking up APs.
>> =

>> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
>> Signed-off-by: Shane Wang <shane.wang@intel.com>
>> Signed-off-by: Gang Wei <gang.wei@intel.com>
>> =

>> diff -r cbf1ce3afd74 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c	Sat Dec 31 16:18:55 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c	Sat Dec 31 18:50:14 2011 +0800
>> @@ -586,7 +586,9 @@
>>      smpboot_setup_warm_reset_vector(start_eip);
>>      =

>>      /* Starting actual IPI sequence... */
>> -    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
>> +    boot_error =3D tboot_wake_ap(apicid, start_eip);
> =

> As tboot.h is being included here anyway, it would seem more clean to
> me to guard the call with tboot_in_measured_env() here rather than in
> the called function.

Ok, to be updated in next version.

>> +    if ( boot_error )
>> +        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
>> =

>>      if ( !boot_error )
>>      {
>> diff -r cbf1ce3afd74 xen/arch/x86/tboot.c
>> --- a/xen/arch/x86/tboot.c	Sat Dec 31 16:18:55 2011 +0800
>> +++ b/xen/arch/x86/tboot.c	Sat Dec 31 18:50:14 2011 +0800
>> @@ -123,6 +123,10 @@
>>      printk("  shutdown_entry: 0x%08x\n",
>>      tboot_shared->shutdown_entry); printk("  tboot_base: 0x%08x\n",
>>      tboot_shared->tboot_base); printk("  tboot_size: 0x%x\n",
>>      tboot_shared->tboot_size);
>> +    if ( tboot_shared->version >=3D 5 )
>> +        printk("  num_in_wfs: %u\n", tboot_shared->num_in_wfs);
> =

> You're printing this field, but aren't making any other use of it?

This field is just used by Linux kernel. I will remove this printk.

>> +    if ( tboot_shared->version >=3D 6 )
>> +        printk("  flags: 0x%08x\n", tboot_shared->flags);
>> =

>>      /* these will be needed by tboot_protect_mem_regions() and/or
>>         tboot_parse_dmar_table(), so get them now */ @@ -529,6
> +533,19
>> @@
>>      panic("Memory integrity was lost on resume (%d)\n", error);  }
>> +int tboot_wake_ap(int apicid, unsigned long sipi_vec) {
>> +    if ( tboot_in_measured_env() && g_tboot_shared->version >=3D 6 &&
>> +         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
>> +    {
>> +        printk("waking AP %d w/ monitor write\n", apicid);
> =

> Please, no once-per-CPU printk()-s, especially if they don't depend on
> per-CPU properties.

Ok, remove it in next version.

>> +        g_tboot_shared->ap_wake_addr =3D sipi_vec;
>> +        g_tboot_shared->ap_wake_trigger =3D apicid;
>> +        return 0;
>> +    }
>> +    return -1;
>> +}
>> +
>>  /*
>>   * Local variables:
>>   * mode: C

Thanks for comments.

Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 15:44:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 15: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 1RkHOZ-0001TV-EU; Mon, 09 Jan 2012 15:44:23 +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 1RkHOX-0001TQ-JU
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 15:44:21 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326123815!47838836!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjIzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9136 invoked from network); 9 Jan 2012 15:43:36 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-27.messagelabs.com with SMTP;
	9 Jan 2012 15:43:36 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 09 Jan 2012 07:44:19 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="105098916"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by fmsmga001.fm.intel.com with ESMTP; 09 Jan 2012 07:44:17 -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; Mon, 9 Jan 2012 23:44:17 +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; Mon, 9 Jan 2012 23:44:16 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Mon, 9 Jan 2012 23:44:15 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH] x86: add a new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0P//f4kA//kqZjA=
Date: Mon, 9 Jan 2012 15:44:15 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE016B8D@SHSMSX102.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
In-Reply-To: <4F05CC48020000780006A9C7@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>, "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 new SMP bring up way for tboot
	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=A02012-01-05:
>>>> On 05.01.12 at 15:53, "Wei, Gang" <gang.wei@intel.com> wrote:
>> tboot may be trying to put APs waiting in MWAIT loops before launching X=
en.
>> Xen could check the new flag field in v6 tboot shared page for the
>> hint. If TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP
>> have to write the monitored memory(g_tboot_shared->ap_wake_trigger)
>> to bring APs out of MWAIT loops. The sipi vector should be written
>> in g_tboot_shared->ap_wake_addr before waking up APs.
>> =

>> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
>> Signed-off-by: Shane Wang <shane.wang@intel.com>
>> Signed-off-by: Gang Wei <gang.wei@intel.com>
>> =

>> diff -r cbf1ce3afd74 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c	Sat Dec 31 16:18:55 2011 +0800
>> +++ b/xen/arch/x86/smpboot.c	Sat Dec 31 18:50:14 2011 +0800
>> @@ -586,7 +586,9 @@
>>      smpboot_setup_warm_reset_vector(start_eip);
>>      =

>>      /* Starting actual IPI sequence... */
>> -    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
>> +    boot_error =3D tboot_wake_ap(apicid, start_eip);
> =

> As tboot.h is being included here anyway, it would seem more clean to
> me to guard the call with tboot_in_measured_env() here rather than in
> the called function.

Ok, to be updated in next version.

>> +    if ( boot_error )
>> +        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
>> =

>>      if ( !boot_error )
>>      {
>> diff -r cbf1ce3afd74 xen/arch/x86/tboot.c
>> --- a/xen/arch/x86/tboot.c	Sat Dec 31 16:18:55 2011 +0800
>> +++ b/xen/arch/x86/tboot.c	Sat Dec 31 18:50:14 2011 +0800
>> @@ -123,6 +123,10 @@
>>      printk("  shutdown_entry: 0x%08x\n",
>>      tboot_shared->shutdown_entry); printk("  tboot_base: 0x%08x\n",
>>      tboot_shared->tboot_base); printk("  tboot_size: 0x%x\n",
>>      tboot_shared->tboot_size);
>> +    if ( tboot_shared->version >=3D 5 )
>> +        printk("  num_in_wfs: %u\n", tboot_shared->num_in_wfs);
> =

> You're printing this field, but aren't making any other use of it?

This field is just used by Linux kernel. I will remove this printk.

>> +    if ( tboot_shared->version >=3D 6 )
>> +        printk("  flags: 0x%08x\n", tboot_shared->flags);
>> =

>>      /* these will be needed by tboot_protect_mem_regions() and/or
>>         tboot_parse_dmar_table(), so get them now */ @@ -529,6
> +533,19
>> @@
>>      panic("Memory integrity was lost on resume (%d)\n", error);  }
>> +int tboot_wake_ap(int apicid, unsigned long sipi_vec) {
>> +    if ( tboot_in_measured_env() && g_tboot_shared->version >=3D 6 &&
>> +         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
>> +    {
>> +        printk("waking AP %d w/ monitor write\n", apicid);
> =

> Please, no once-per-CPU printk()-s, especially if they don't depend on
> per-CPU properties.

Ok, remove it in next version.

>> +        g_tboot_shared->ap_wake_addr =3D sipi_vec;
>> +        g_tboot_shared->ap_wake_trigger =3D apicid;
>> +        return 0;
>> +    }
>> +    return -1;
>> +}
>> +
>>  /*
>>   * Local variables:
>>   * mode: C

Thanks for comments.

Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:02:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHfo-00025l-GD; Mon, 09 Jan 2012 16:02:12 +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 1RkHfn-00025g-0n
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:02:11 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326124923!10170681!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIyNjcw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7407 invoked from network); 9 Jan 2012 16:02:04 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 16:02:04 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 09 Jan 2012 08:02:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="94438862"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 09 Jan 2012 08:02:00 -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; Tue, 10 Jan 2012 00:01:59 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.38]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 00:01:58 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH v2] x86: add a new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0P//f4kA//kkYOA=
Date: Mon, 9 Jan 2012 16:01:58 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
In-Reply-To: <4F05CC48020000780006A9C7@nat28.tlf.novell.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_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "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: [Xen-devel] [PATCH v2] x86: add a new SMP bring up way for tboot
	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_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

tboot may be trying to put APs waiting in MWAIT loops before launching Xen.=
 Xen could check the new flag field in v6 tboot shared page for the hint. I=
f TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write t=
he monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MW=
AIT loops. The sipi vector should be written in g_tboot_shared->ap_wake_add=
r before waking up APs.

Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r 8087674cceb9 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/arch/x86/smpboot.c	Mon Jan 09 23:55:41 2012 +0800
@@ -586,7 +586,10 @@
     smpboot_setup_warm_reset_vector(start_eip);
=20
     /* Starting actual IPI sequence... */
-    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
+    if ( tboot_in_measured_env() )
+        boot_error =3D tboot_wake_ap(apicid, start_eip);
+    else
+        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
=20
     if ( !boot_error )
     {
diff -r 8087674cceb9 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/arch/x86/tboot.c	Mon Jan 09 23:55:41 2012 +0800
@@ -123,6 +123,8 @@
     printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
     printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
     printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
+    if ( tboot_shared->version >=3D 6 )
+        printk("  flags: 0x%08x\n", tboot_shared->flags);
=20
     /* these will be needed by tboot_protect_mem_regions() and/or
        tboot_parse_dmar_table(), so get them now */
@@ -529,6 +531,18 @@
     panic("Memory integrity was lost on resume (%d)\n", error);
 }
=20
+int tboot_wake_ap(int apicid, unsigned long sipi_vec)
+{
+    if ( g_tboot_shared->version >=3D 6 &&
+         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
+    {
+        g_tboot_shared->ap_wake_addr =3D sipi_vec;
+        g_tboot_shared->ap_wake_trigger =3D apicid;
+        return 0;
+    }
+    return -1;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 8087674cceb9 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/include/asm-x86/tboot.h	Mon Jan 09 23:55:41 2012 +0800
@@ -85,7 +85,7 @@
 typedef struct __packed {
     /* version 3+ fields: */
     uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08}=
 */
-    uint32_t  version;           /* Version number; currently supports 0.4=
 */
+    uint32_t  version;           /* Version number; currently supports 0.6=
 */
     uint32_t  log_addr;          /* physical addr of tb_log_t log */
     uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
     uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
@@ -99,6 +99,13 @@
     /* version 4+ fields: */
                                  /* populated by tboot; will be encrypted =
*/
     uint8_t   s3_key[TB_KEY_SIZE];
+    /* version 5+ fields: */
+    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
+    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI =
*/
+    /* version 6+ fields: */
+    uint32_t  flags;
+    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
+    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP *=
/
 } tboot_shared_t;
=20
 #define TB_SHUTDOWN_REBOOT      0
@@ -107,6 +114,9 @@
 #define TB_SHUTDOWN_S3          3
 #define TB_SHUTDOWN_HALT        4
=20
+#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use INIT-SIPI-=
SIPI
+                                                 if clear, ap_wake_* if se=
t */
+
 /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
 #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
                                { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
@@ -120,6 +130,7 @@
 int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
 int tboot_s3_resume(void);
 void tboot_s3_error(int error);
+int tboot_wake_ap(int apicid, unsigned long sipi_vec);
=20
 #endif /* __TBOOT_H__ */


--_002_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_
Content-Type: application/octet-stream;
	name="mwait-smp-up-for-tboot-v2.patch"
Content-Description: mwait-smp-up-for-tboot-v2.patch
Content-Disposition: attachment; filename="mwait-smp-up-for-tboot-v2.patch";
	size=4157; creation-date="Mon, 09 Jan 2012 15:58:01 GMT";
	modification-date="Mon, 09 Jan 2012 15:56:46 GMT"
Content-Transfer-Encoding: base64

eDg2OiBhZGQgYSBuZXcgU01QIGJyaW5nIHVwIHdheSBmb3IgdGJvb3QgY2FzZQoKdGJvb3QgbWF5
IGJlIHRyeWluZyB0byBwdXQgQVBzIHdhaXRpbmcgaW4gTVdBSVQgbG9vcHMgYmVmb3JlIGxhdW5j
aGluZyBYZW4uIFhlbiBjb3VsZCBjaGVjayB0aGUgbmV3IGZsYWcgZmllbGQgaW4gdjYgdGJvb3Qg
c2hhcmVkIHBhZ2UgZm9yIHRoZSBoaW50LiBJZiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCBiaXQg
aW4gZmxhZyBmaWVsZCBpcyBzZXQsIFhlbiBCU1AgaGF2ZSB0byB3cml0ZSB0aGUgbW9uaXRvcmVk
IG1lbW9yeShnX3Rib290X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyKSB0byBicmluZyBBUHMgb3V0
IG9mIE1XQUlUIGxvb3BzLiBUaGUgc2lwaSB2ZWN0b3Igc2hvdWxkIGJlIHdyaXR0ZW4gaW4gZ190
Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciBiZWZvcmUgd2FraW5nIHVwIEFQcy4KClNpZ25lZC1v
ZmYtYnk6IEpvc2VwaCBDaWh1bGEgPGpvc2VwaC5jaWh1bGFAaW50ZWwuY29tPgpTaWduZWQtb2Zm
LWJ5OiBTaGFuZSBXYW5nIDxzaGFuZS53YW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogR2Fu
ZyBXZWkgPGdhbmcud2VpQGludGVsLmNvbT4KCmRpZmYgLXIgODA4NzY3NGNjZWI5IHhlbi9hcmNo
L3g4Ni9zbXBib290LmMKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlUaHUgSmFuIDA1IDIy
OjQyOjAyIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlNb24gSmFuIDA5
IDIzOjU1OjQxIDIwMTIgKzA4MDAKQEAgLTU4Niw3ICs1ODYsMTAgQEAKICAgICBzbXBib290X3Nl
dHVwX3dhcm1fcmVzZXRfdmVjdG9yKHN0YXJ0X2VpcCk7CiAKICAgICAvKiBTdGFydGluZyBhY3R1
YWwgSVBJIHNlcXVlbmNlLi4uICovCi0gICAgYm9vdF9lcnJvciA9IHdha2V1cF9zZWNvbmRhcnlf
Y3B1KGFwaWNpZCwgc3RhcnRfZWlwKTsKKyAgICBpZiAoIHRib290X2luX21lYXN1cmVkX2Vudigp
ICkKKyAgICAgICAgYm9vdF9lcnJvciA9IHRib290X3dha2VfYXAoYXBpY2lkLCBzdGFydF9laXAp
OworICAgIGVsc2UKKyAgICAgICAgYm9vdF9lcnJvciA9IHdha2V1cF9zZWNvbmRhcnlfY3B1KGFw
aWNpZCwgc3RhcnRfZWlwKTsKIAogICAgIGlmICggIWJvb3RfZXJyb3IgKQogICAgIHsKZGlmZiAt
ciA4MDg3Njc0Y2NlYjkgeGVuL2FyY2gveDg2L3Rib290LmMKLS0tIGEveGVuL2FyY2gveDg2L3Ri
b290LmMJVGh1IEphbiAwNSAyMjo0MjowMiAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni90
Ym9vdC5jCU1vbiBKYW4gMDkgMjM6NTU6NDEgMjAxMiArMDgwMApAQCAtMTIzLDYgKzEyMyw4IEBA
CiAgICAgcHJpbnRrKCIgIHNodXRkb3duX2VudHJ5OiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+
c2h1dGRvd25fZW50cnkpOwogICAgIHByaW50aygiICB0Ym9vdF9iYXNlOiAweCUwOHhcbiIsIHRi
b290X3NoYXJlZC0+dGJvb3RfYmFzZSk7CiAgICAgcHJpbnRrKCIgIHRib290X3NpemU6IDB4JXhc
biIsIHRib290X3NoYXJlZC0+dGJvb3Rfc2l6ZSk7CisgICAgaWYgKCB0Ym9vdF9zaGFyZWQtPnZl
cnNpb24gPj0gNiApCisgICAgICAgIHByaW50aygiICBmbGFnczogMHglMDh4XG4iLCB0Ym9vdF9z
aGFyZWQtPmZsYWdzKTsKIAogICAgIC8qIHRoZXNlIHdpbGwgYmUgbmVlZGVkIGJ5IHRib290X3By
b3RlY3RfbWVtX3JlZ2lvbnMoKSBhbmQvb3IKICAgICAgICB0Ym9vdF9wYXJzZV9kbWFyX3RhYmxl
KCksIHNvIGdldCB0aGVtIG5vdyAqLwpAQCAtNTI5LDYgKzUzMSwxOCBAQAogICAgIHBhbmljKCJN
ZW1vcnkgaW50ZWdyaXR5IHdhcyBsb3N0IG9uIHJlc3VtZSAoJWQpXG4iLCBlcnJvcik7CiB9CiAK
K2ludCB0Ym9vdF93YWtlX2FwKGludCBhcGljaWQsIHVuc2lnbmVkIGxvbmcgc2lwaV92ZWMpCit7
CisgICAgaWYgKCBnX3Rib290X3NoYXJlZC0+dmVyc2lvbiA+PSA2ICYmCisgICAgICAgICAoZ190
Ym9vdF9zaGFyZWQtPmZsYWdzICYgVEJfRkxBR19BUF9XQUtFX1NVUFBPUlQpICkKKyAgICB7Cisg
ICAgICAgIGdfdGJvb3Rfc2hhcmVkLT5hcF93YWtlX2FkZHIgPSBzaXBpX3ZlYzsKKyAgICAgICAg
Z190Ym9vdF9zaGFyZWQtPmFwX3dha2VfdHJpZ2dlciA9IGFwaWNpZDsKKyAgICAgICAgcmV0dXJu
IDA7CisgICAgfQorICAgIHJldHVybiAtMTsKK30KKwogLyoKICAqIExvY2FsIHZhcmlhYmxlczoK
ICAqIG1vZGU6IEMKZGlmZiAtciA4MDg3Njc0Y2NlYjkgeGVuL2luY2x1ZGUvYXNtLXg4Ni90Ym9v
dC5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvdGJvb3QuaAlUaHUgSmFuIDA1IDIyOjQyOjAy
IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni90Ym9vdC5oCU1vbiBKYW4gMDkg
MjM6NTU6NDEgMjAxMiArMDgwMApAQCAtODUsNyArODUsNyBAQAogdHlwZWRlZiBzdHJ1Y3QgX19w
YWNrZWQgewogICAgIC8qIHZlcnNpb24gMysgZmllbGRzOiAqLwogICAgIHV1aWRfdCAgICB1dWlk
OyAgICAgICAgICAgICAgLyogezY2M0M4REZGLUU4QjMtNGI4Mi1BQUJGLTE5RUE0RDA1N0EwOH0g
Ki8KLSAgICB1aW50MzJfdCAgdmVyc2lvbjsgICAgICAgICAgIC8qIFZlcnNpb24gbnVtYmVyOyBj
dXJyZW50bHkgc3VwcG9ydHMgMC40ICovCisgICAgdWludDMyX3QgIHZlcnNpb247ICAgICAgICAg
ICAvKiBWZXJzaW9uIG51bWJlcjsgY3VycmVudGx5IHN1cHBvcnRzIDAuNiAqLwogICAgIHVpbnQz
Ml90ICBsb2dfYWRkcjsgICAgICAgICAgLyogcGh5c2ljYWwgYWRkciBvZiB0Yl9sb2dfdCBsb2cg
Ki8KICAgICB1aW50MzJfdCAgc2h1dGRvd25fZW50cnk7ICAgIC8qIGVudHJ5IHBvaW50IGZvciB0
Ym9vdCBzaHV0ZG93biAqLwogICAgIHVpbnQzMl90ICBzaHV0ZG93bl90eXBlOyAgICAgLyogdHlw
ZSBvZiBzaHV0ZG93biAoVEJfU0hVVERPV05fKikgKi8KQEAgLTk5LDYgKzk5LDEzIEBACiAgICAg
LyogdmVyc2lvbiA0KyBmaWVsZHM6ICovCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAvKiBwb3B1bGF0ZWQgYnkgdGJvb3Q7IHdpbGwgYmUgZW5jcnlwdGVkICovCiAgICAgdWludDhf
dCAgIHMzX2tleVtUQl9LRVlfU0laRV07CisgICAgLyogdmVyc2lvbiA1KyBmaWVsZHM6ICovCisg
ICAgdWludDhfdCAgIHJlc2VydmVkX2FsaWduWzNdOyAvKiB1c2VkIHRvIDRieXRlLWFsaWduIG51
bV9pbl93ZnMgKi8KKyAgICB1aW50MzJfdCAgbnVtX2luX3dmczsgICAgICAgIC8qIG51bWJlciBv
ZiBwcm9jZXNzb3JzIGluIHdhaXQtZm9yLVNJUEkgKi8KKyAgICAvKiB2ZXJzaW9uIDYrIGZpZWxk
czogKi8KKyAgICB1aW50MzJfdCAgZmxhZ3M7CisgICAgdWludDY0X3QgIGFwX3dha2VfYWRkcjsg
ICAgICAvKiBwaHlzIGFkZHIgb2Yga2VybmVsL1ZNTSBTSVBJIHZlY3RvciAqLworICAgIHVpbnQz
Ml90ICBhcF93YWtlX3RyaWdnZXI7ICAgLyoga2VybmVsL1ZNTSB3cml0ZXMgQVBJQyBJRCB0byB3
YWtlIEFQICovCiB9IHRib290X3NoYXJlZF90OwogCiAjZGVmaW5lIFRCX1NIVVRET1dOX1JFQk9P
VCAgICAgIDAKQEAgLTEwNyw2ICsxMTQsOSBAQAogI2RlZmluZSBUQl9TSFVURE9XTl9TMyAgICAg
ICAgICAzCiAjZGVmaW5lIFRCX1NIVVRET1dOX0hBTFQgICAgICAgIDQKIAorI2RlZmluZSBUQl9G
TEFHX0FQX1dBS0VfU1VQUE9SVCAgIDB4MDAwMDAwMDEgIC8qIGtlcm5lbC9WTU0gdXNlIElOSVQt
U0lQSS1TSVBJCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaWYgY2xlYXIsIGFwX3dha2VfKiBpZiBzZXQgKi8KKwogLyogezY2M0M4REZGLUU4QjMtNGI4
Mi1BQUJGLTE5RUE0RDA1N0EwOH0gKi8KICNkZWZpbmUgVEJPT1RfU0hBUkVEX1VVSUQgICAgeyAw
eDY2M2M4ZGZmLCAweGU4YjMsIDB4NGI4MiwgMHhhYWJmLCBcCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgeyAweDE5LCAweGVhLCAweDRkLCAweDUsIDB4N2EsIDB4OCB9IH07CkBAIC0x
MjAsNiArMTMwLDcgQEAKIGludCB0Ym9vdF9wYXJzZV9kbWFyX3RhYmxlKGFjcGlfdGFibGVfaGFu
ZGxlciBkbWFyX2hhbmRsZXIpOwogaW50IHRib290X3MzX3Jlc3VtZSh2b2lkKTsKIHZvaWQgdGJv
b3RfczNfZXJyb3IoaW50IGVycm9yKTsKK2ludCB0Ym9vdF93YWtlX2FwKGludCBhcGljaWQsIHVu
c2lnbmVkIGxvbmcgc2lwaV92ZWMpOwogCiAjZW5kaWYgLyogX19UQk9PVF9IX18gKi8KIAo=

--_002_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:02:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:02:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHfo-00025l-GD; Mon, 09 Jan 2012 16:02:12 +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 1RkHfn-00025g-0n
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:02:11 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326124923!10170681!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIyNjcw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7407 invoked from network); 9 Jan 2012 16:02:04 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-10.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 16:02:04 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 09 Jan 2012 08:02:02 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="94438862"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 09 Jan 2012 08:02:00 -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; Tue, 10 Jan 2012 00:01:59 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.38]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 00:01:58 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH v2] x86: add a new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0P//f4kA//kkYOA=
Date: Mon, 9 Jan 2012 16:01:58 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
In-Reply-To: <4F05CC48020000780006A9C7@nat28.tlf.novell.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_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_"
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, "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: [Xen-devel] [PATCH v2] x86: add a new SMP bring up way for tboot
	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_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

tboot may be trying to put APs waiting in MWAIT loops before launching Xen.=
 Xen could check the new flag field in v6 tboot shared page for the hint. I=
f TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write t=
he monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MW=
AIT loops. The sipi vector should be written in g_tboot_shared->ap_wake_add=
r before waking up APs.

Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r 8087674cceb9 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/arch/x86/smpboot.c	Mon Jan 09 23:55:41 2012 +0800
@@ -586,7 +586,10 @@
     smpboot_setup_warm_reset_vector(start_eip);
=20
     /* Starting actual IPI sequence... */
-    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
+    if ( tboot_in_measured_env() )
+        boot_error =3D tboot_wake_ap(apicid, start_eip);
+    else
+        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
=20
     if ( !boot_error )
     {
diff -r 8087674cceb9 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/arch/x86/tboot.c	Mon Jan 09 23:55:41 2012 +0800
@@ -123,6 +123,8 @@
     printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
     printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
     printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
+    if ( tboot_shared->version >=3D 6 )
+        printk("  flags: 0x%08x\n", tboot_shared->flags);
=20
     /* these will be needed by tboot_protect_mem_regions() and/or
        tboot_parse_dmar_table(), so get them now */
@@ -529,6 +531,18 @@
     panic("Memory integrity was lost on resume (%d)\n", error);
 }
=20
+int tboot_wake_ap(int apicid, unsigned long sipi_vec)
+{
+    if ( g_tboot_shared->version >=3D 6 &&
+         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
+    {
+        g_tboot_shared->ap_wake_addr =3D sipi_vec;
+        g_tboot_shared->ap_wake_trigger =3D apicid;
+        return 0;
+    }
+    return -1;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 8087674cceb9 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/include/asm-x86/tboot.h	Mon Jan 09 23:55:41 2012 +0800
@@ -85,7 +85,7 @@
 typedef struct __packed {
     /* version 3+ fields: */
     uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08}=
 */
-    uint32_t  version;           /* Version number; currently supports 0.4=
 */
+    uint32_t  version;           /* Version number; currently supports 0.6=
 */
     uint32_t  log_addr;          /* physical addr of tb_log_t log */
     uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
     uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
@@ -99,6 +99,13 @@
     /* version 4+ fields: */
                                  /* populated by tboot; will be encrypted =
*/
     uint8_t   s3_key[TB_KEY_SIZE];
+    /* version 5+ fields: */
+    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
+    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI =
*/
+    /* version 6+ fields: */
+    uint32_t  flags;
+    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
+    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP *=
/
 } tboot_shared_t;
=20
 #define TB_SHUTDOWN_REBOOT      0
@@ -107,6 +114,9 @@
 #define TB_SHUTDOWN_S3          3
 #define TB_SHUTDOWN_HALT        4
=20
+#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use INIT-SIPI-=
SIPI
+                                                 if clear, ap_wake_* if se=
t */
+
 /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
 #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
                                { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
@@ -120,6 +130,7 @@
 int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
 int tboot_s3_resume(void);
 void tboot_s3_error(int error);
+int tboot_wake_ap(int apicid, unsigned long sipi_vec);
=20
 #endif /* __TBOOT_H__ */


--_002_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_
Content-Type: application/octet-stream;
	name="mwait-smp-up-for-tboot-v2.patch"
Content-Description: mwait-smp-up-for-tboot-v2.patch
Content-Disposition: attachment; filename="mwait-smp-up-for-tboot-v2.patch";
	size=4157; creation-date="Mon, 09 Jan 2012 15:58:01 GMT";
	modification-date="Mon, 09 Jan 2012 15:56:46 GMT"
Content-Transfer-Encoding: base64

eDg2OiBhZGQgYSBuZXcgU01QIGJyaW5nIHVwIHdheSBmb3IgdGJvb3QgY2FzZQoKdGJvb3QgbWF5
IGJlIHRyeWluZyB0byBwdXQgQVBzIHdhaXRpbmcgaW4gTVdBSVQgbG9vcHMgYmVmb3JlIGxhdW5j
aGluZyBYZW4uIFhlbiBjb3VsZCBjaGVjayB0aGUgbmV3IGZsYWcgZmllbGQgaW4gdjYgdGJvb3Qg
c2hhcmVkIHBhZ2UgZm9yIHRoZSBoaW50LiBJZiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCBiaXQg
aW4gZmxhZyBmaWVsZCBpcyBzZXQsIFhlbiBCU1AgaGF2ZSB0byB3cml0ZSB0aGUgbW9uaXRvcmVk
IG1lbW9yeShnX3Rib290X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyKSB0byBicmluZyBBUHMgb3V0
IG9mIE1XQUlUIGxvb3BzLiBUaGUgc2lwaSB2ZWN0b3Igc2hvdWxkIGJlIHdyaXR0ZW4gaW4gZ190
Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciBiZWZvcmUgd2FraW5nIHVwIEFQcy4KClNpZ25lZC1v
ZmYtYnk6IEpvc2VwaCBDaWh1bGEgPGpvc2VwaC5jaWh1bGFAaW50ZWwuY29tPgpTaWduZWQtb2Zm
LWJ5OiBTaGFuZSBXYW5nIDxzaGFuZS53YW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogR2Fu
ZyBXZWkgPGdhbmcud2VpQGludGVsLmNvbT4KCmRpZmYgLXIgODA4NzY3NGNjZWI5IHhlbi9hcmNo
L3g4Ni9zbXBib290LmMKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlUaHUgSmFuIDA1IDIy
OjQyOjAyIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlNb24gSmFuIDA5
IDIzOjU1OjQxIDIwMTIgKzA4MDAKQEAgLTU4Niw3ICs1ODYsMTAgQEAKICAgICBzbXBib290X3Nl
dHVwX3dhcm1fcmVzZXRfdmVjdG9yKHN0YXJ0X2VpcCk7CiAKICAgICAvKiBTdGFydGluZyBhY3R1
YWwgSVBJIHNlcXVlbmNlLi4uICovCi0gICAgYm9vdF9lcnJvciA9IHdha2V1cF9zZWNvbmRhcnlf
Y3B1KGFwaWNpZCwgc3RhcnRfZWlwKTsKKyAgICBpZiAoIHRib290X2luX21lYXN1cmVkX2Vudigp
ICkKKyAgICAgICAgYm9vdF9lcnJvciA9IHRib290X3dha2VfYXAoYXBpY2lkLCBzdGFydF9laXAp
OworICAgIGVsc2UKKyAgICAgICAgYm9vdF9lcnJvciA9IHdha2V1cF9zZWNvbmRhcnlfY3B1KGFw
aWNpZCwgc3RhcnRfZWlwKTsKIAogICAgIGlmICggIWJvb3RfZXJyb3IgKQogICAgIHsKZGlmZiAt
ciA4MDg3Njc0Y2NlYjkgeGVuL2FyY2gveDg2L3Rib290LmMKLS0tIGEveGVuL2FyY2gveDg2L3Ri
b290LmMJVGh1IEphbiAwNSAyMjo0MjowMiAyMDEyICswODAwCisrKyBiL3hlbi9hcmNoL3g4Ni90
Ym9vdC5jCU1vbiBKYW4gMDkgMjM6NTU6NDEgMjAxMiArMDgwMApAQCAtMTIzLDYgKzEyMyw4IEBA
CiAgICAgcHJpbnRrKCIgIHNodXRkb3duX2VudHJ5OiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+
c2h1dGRvd25fZW50cnkpOwogICAgIHByaW50aygiICB0Ym9vdF9iYXNlOiAweCUwOHhcbiIsIHRi
b290X3NoYXJlZC0+dGJvb3RfYmFzZSk7CiAgICAgcHJpbnRrKCIgIHRib290X3NpemU6IDB4JXhc
biIsIHRib290X3NoYXJlZC0+dGJvb3Rfc2l6ZSk7CisgICAgaWYgKCB0Ym9vdF9zaGFyZWQtPnZl
cnNpb24gPj0gNiApCisgICAgICAgIHByaW50aygiICBmbGFnczogMHglMDh4XG4iLCB0Ym9vdF9z
aGFyZWQtPmZsYWdzKTsKIAogICAgIC8qIHRoZXNlIHdpbGwgYmUgbmVlZGVkIGJ5IHRib290X3By
b3RlY3RfbWVtX3JlZ2lvbnMoKSBhbmQvb3IKICAgICAgICB0Ym9vdF9wYXJzZV9kbWFyX3RhYmxl
KCksIHNvIGdldCB0aGVtIG5vdyAqLwpAQCAtNTI5LDYgKzUzMSwxOCBAQAogICAgIHBhbmljKCJN
ZW1vcnkgaW50ZWdyaXR5IHdhcyBsb3N0IG9uIHJlc3VtZSAoJWQpXG4iLCBlcnJvcik7CiB9CiAK
K2ludCB0Ym9vdF93YWtlX2FwKGludCBhcGljaWQsIHVuc2lnbmVkIGxvbmcgc2lwaV92ZWMpCit7
CisgICAgaWYgKCBnX3Rib290X3NoYXJlZC0+dmVyc2lvbiA+PSA2ICYmCisgICAgICAgICAoZ190
Ym9vdF9zaGFyZWQtPmZsYWdzICYgVEJfRkxBR19BUF9XQUtFX1NVUFBPUlQpICkKKyAgICB7Cisg
ICAgICAgIGdfdGJvb3Rfc2hhcmVkLT5hcF93YWtlX2FkZHIgPSBzaXBpX3ZlYzsKKyAgICAgICAg
Z190Ym9vdF9zaGFyZWQtPmFwX3dha2VfdHJpZ2dlciA9IGFwaWNpZDsKKyAgICAgICAgcmV0dXJu
IDA7CisgICAgfQorICAgIHJldHVybiAtMTsKK30KKwogLyoKICAqIExvY2FsIHZhcmlhYmxlczoK
ICAqIG1vZGU6IEMKZGlmZiAtciA4MDg3Njc0Y2NlYjkgeGVuL2luY2x1ZGUvYXNtLXg4Ni90Ym9v
dC5oCi0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvdGJvb3QuaAlUaHUgSmFuIDA1IDIyOjQyOjAy
IDIwMTIgKzA4MDAKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni90Ym9vdC5oCU1vbiBKYW4gMDkg
MjM6NTU6NDEgMjAxMiArMDgwMApAQCAtODUsNyArODUsNyBAQAogdHlwZWRlZiBzdHJ1Y3QgX19w
YWNrZWQgewogICAgIC8qIHZlcnNpb24gMysgZmllbGRzOiAqLwogICAgIHV1aWRfdCAgICB1dWlk
OyAgICAgICAgICAgICAgLyogezY2M0M4REZGLUU4QjMtNGI4Mi1BQUJGLTE5RUE0RDA1N0EwOH0g
Ki8KLSAgICB1aW50MzJfdCAgdmVyc2lvbjsgICAgICAgICAgIC8qIFZlcnNpb24gbnVtYmVyOyBj
dXJyZW50bHkgc3VwcG9ydHMgMC40ICovCisgICAgdWludDMyX3QgIHZlcnNpb247ICAgICAgICAg
ICAvKiBWZXJzaW9uIG51bWJlcjsgY3VycmVudGx5IHN1cHBvcnRzIDAuNiAqLwogICAgIHVpbnQz
Ml90ICBsb2dfYWRkcjsgICAgICAgICAgLyogcGh5c2ljYWwgYWRkciBvZiB0Yl9sb2dfdCBsb2cg
Ki8KICAgICB1aW50MzJfdCAgc2h1dGRvd25fZW50cnk7ICAgIC8qIGVudHJ5IHBvaW50IGZvciB0
Ym9vdCBzaHV0ZG93biAqLwogICAgIHVpbnQzMl90ICBzaHV0ZG93bl90eXBlOyAgICAgLyogdHlw
ZSBvZiBzaHV0ZG93biAoVEJfU0hVVERPV05fKikgKi8KQEAgLTk5LDYgKzk5LDEzIEBACiAgICAg
LyogdmVyc2lvbiA0KyBmaWVsZHM6ICovCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAvKiBwb3B1bGF0ZWQgYnkgdGJvb3Q7IHdpbGwgYmUgZW5jcnlwdGVkICovCiAgICAgdWludDhf
dCAgIHMzX2tleVtUQl9LRVlfU0laRV07CisgICAgLyogdmVyc2lvbiA1KyBmaWVsZHM6ICovCisg
ICAgdWludDhfdCAgIHJlc2VydmVkX2FsaWduWzNdOyAvKiB1c2VkIHRvIDRieXRlLWFsaWduIG51
bV9pbl93ZnMgKi8KKyAgICB1aW50MzJfdCAgbnVtX2luX3dmczsgICAgICAgIC8qIG51bWJlciBv
ZiBwcm9jZXNzb3JzIGluIHdhaXQtZm9yLVNJUEkgKi8KKyAgICAvKiB2ZXJzaW9uIDYrIGZpZWxk
czogKi8KKyAgICB1aW50MzJfdCAgZmxhZ3M7CisgICAgdWludDY0X3QgIGFwX3dha2VfYWRkcjsg
ICAgICAvKiBwaHlzIGFkZHIgb2Yga2VybmVsL1ZNTSBTSVBJIHZlY3RvciAqLworICAgIHVpbnQz
Ml90ICBhcF93YWtlX3RyaWdnZXI7ICAgLyoga2VybmVsL1ZNTSB3cml0ZXMgQVBJQyBJRCB0byB3
YWtlIEFQICovCiB9IHRib290X3NoYXJlZF90OwogCiAjZGVmaW5lIFRCX1NIVVRET1dOX1JFQk9P
VCAgICAgIDAKQEAgLTEwNyw2ICsxMTQsOSBAQAogI2RlZmluZSBUQl9TSFVURE9XTl9TMyAgICAg
ICAgICAzCiAjZGVmaW5lIFRCX1NIVVRET1dOX0hBTFQgICAgICAgIDQKIAorI2RlZmluZSBUQl9G
TEFHX0FQX1dBS0VfU1VQUE9SVCAgIDB4MDAwMDAwMDEgIC8qIGtlcm5lbC9WTU0gdXNlIElOSVQt
U0lQSS1TSVBJCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgaWYgY2xlYXIsIGFwX3dha2VfKiBpZiBzZXQgKi8KKwogLyogezY2M0M4REZGLUU4QjMtNGI4
Mi1BQUJGLTE5RUE0RDA1N0EwOH0gKi8KICNkZWZpbmUgVEJPT1RfU0hBUkVEX1VVSUQgICAgeyAw
eDY2M2M4ZGZmLCAweGU4YjMsIDB4NGI4MiwgMHhhYWJmLCBcCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgeyAweDE5LCAweGVhLCAweDRkLCAweDUsIDB4N2EsIDB4OCB9IH07CkBAIC0x
MjAsNiArMTMwLDcgQEAKIGludCB0Ym9vdF9wYXJzZV9kbWFyX3RhYmxlKGFjcGlfdGFibGVfaGFu
ZGxlciBkbWFyX2hhbmRsZXIpOwogaW50IHRib290X3MzX3Jlc3VtZSh2b2lkKTsKIHZvaWQgdGJv
b3RfczNfZXJyb3IoaW50IGVycm9yKTsKK2ludCB0Ym9vdF93YWtlX2FwKGludCBhcGljaWQsIHVu
c2lnbmVkIGxvbmcgc2lwaV92ZWMpOwogCiAjZW5kaWYgLyogX19UQk9PVF9IX18gKi8KIAo=

--_002_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_D0B11485C64D4B47B66902F8A4E901BE016BABSHSMSX102ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16: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 1RkHmz-0002F1-FT; Mon, 09 Jan 2012 16:09: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 1RkHmx-0002Eu-VY
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:09:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326125369!8084354!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 7671 invoked from network); 9 Jan 2012 16:09:29 -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; 9 Jan 2012 16:09:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 16:09:29 +0000
Message-Id: <4F0B1F47020000780006B4D3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 16:09:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Gang Wei" <gang.wei@intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Joseph Cihula <joseph.cihula@intel.com>, "Keir\(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] x86: add a new SMP bring up way for
	tboot 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 09.01.12 at 17:01, "Wei, Gang" <gang.wei@intel.com> wrote:
> tboot may be trying to put APs waiting in MWAIT loops before launching Xen. 
> Xen could check the new flag field in v6 tboot shared page for the hint. If 
> TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write the 
> monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MWAIT 
> loops. The sipi vector should be written in g_tboot_shared->ap_wake_addr before 
> waking up APs.
> 
> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
> Signed-off-by: Shane Wang <shane.wang@intel.com>
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r 8087674cceb9 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c	Thu Jan 05 22:42:02 2012 +0800
> +++ b/xen/arch/x86/smpboot.c	Mon Jan 09 23:55:41 2012 +0800
> @@ -586,7 +586,10 @@
>      smpboot_setup_warm_reset_vector(start_eip);
>  
>      /* Starting actual IPI sequence... */
> -    boot_error = wakeup_secondary_cpu(apicid, start_eip);
> +    if ( tboot_in_measured_env() )
> +        boot_error = tboot_wake_ap(apicid, start_eip);
> +    else
> +        boot_error = wakeup_secondary_cpu(apicid, start_eip);

I'm afraid this is broken now for older tboot - you want to call
wakeup_secondary_cpu() if tboot_wake_ap() failed. All I had
asked in the first review round was that you don't call
tboot_wake_ap() without tboot_in_measured_env() returning
true.

Jan

>      if ( !boot_error )
>      {
> diff -r 8087674cceb9 xen/arch/x86/tboot.c
> --- a/xen/arch/x86/tboot.c	Thu Jan 05 22:42:02 2012 +0800
> +++ b/xen/arch/x86/tboot.c	Mon Jan 09 23:55:41 2012 +0800
> @@ -123,6 +123,8 @@
>      printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
>      printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
>      printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
> +    if ( tboot_shared->version >= 6 )
> +        printk("  flags: 0x%08x\n", tboot_shared->flags);
>  
>      /* these will be needed by tboot_protect_mem_regions() and/or
>         tboot_parse_dmar_table(), so get them now */
> @@ -529,6 +531,18 @@
>      panic("Memory integrity was lost on resume (%d)\n", error);
>  }
>  
> +int tboot_wake_ap(int apicid, unsigned long sipi_vec)
> +{
> +    if ( g_tboot_shared->version >= 6 &&
> +         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
> +    {
> +        g_tboot_shared->ap_wake_addr = sipi_vec;
> +        g_tboot_shared->ap_wake_trigger = apicid;
> +        return 0;
> +    }
> +    return -1;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff -r 8087674cceb9 xen/include/asm-x86/tboot.h
> --- a/xen/include/asm-x86/tboot.h	Thu Jan 05 22:42:02 2012 +0800
> +++ b/xen/include/asm-x86/tboot.h	Mon Jan 09 23:55:41 2012 +0800
> @@ -85,7 +85,7 @@
>  typedef struct __packed {
>      /* version 3+ fields: */
>      uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
> -    uint32_t  version;           /* Version number; currently supports 0.4 
> */
> +    uint32_t  version;           /* Version number; currently supports 0.6 
> */
>      uint32_t  log_addr;          /* physical addr of tb_log_t log */
>      uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
>      uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
> @@ -99,6 +99,13 @@
>      /* version 4+ fields: */
>                                   /* populated by tboot; will be encrypted 
> */
>      uint8_t   s3_key[TB_KEY_SIZE];
> +    /* version 5+ fields: */
> +    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
> +    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI */
> +    /* version 6+ fields: */
> +    uint32_t  flags;
> +    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
> +    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP */
>  } tboot_shared_t;
>  
>  #define TB_SHUTDOWN_REBOOT      0
> @@ -107,6 +114,9 @@
>  #define TB_SHUTDOWN_S3          3
>  #define TB_SHUTDOWN_HALT        4
>  
> +#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use 
> INIT-SIPI-SIPI
> +                                                 if clear, ap_wake_* if set 
> */
> +
>  /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
>  #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
>                                 { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
> @@ -120,6 +130,7 @@
>  int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
>  int tboot_s3_resume(void);
>  void tboot_s3_error(int error);
> +int tboot_wake_ap(int apicid, unsigned long sipi_vec);
>  
>  #endif /* __TBOOT_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:10:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16: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 1RkHmz-0002F1-FT; Mon, 09 Jan 2012 16:09: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 1RkHmx-0002Eu-VY
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:09:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326125369!8084354!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 7671 invoked from network); 9 Jan 2012 16:09:29 -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; 9 Jan 2012 16:09:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 09 Jan 2012 16:09:29 +0000
Message-Id: <4F0B1F47020000780006B4D3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 09 Jan 2012 16:09:27 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Gang Wei" <gang.wei@intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Tim Deegan <tim@xen.org>,
	"tboot-devel@lists.sourceforge.net" <tboot-devel@lists.sourceforge.net>,
	Joseph Cihula <joseph.cihula@intel.com>, "Keir\(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH v2] x86: add a new SMP bring up way for
	tboot 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 09.01.12 at 17:01, "Wei, Gang" <gang.wei@intel.com> wrote:
> tboot may be trying to put APs waiting in MWAIT loops before launching Xen. 
> Xen could check the new flag field in v6 tboot shared page for the hint. If 
> TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write the 
> monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MWAIT 
> loops. The sipi vector should be written in g_tboot_shared->ap_wake_addr before 
> waking up APs.
> 
> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
> Signed-off-by: Shane Wang <shane.wang@intel.com>
> Signed-off-by: Gang Wei <gang.wei@intel.com>
> 
> diff -r 8087674cceb9 xen/arch/x86/smpboot.c
> --- a/xen/arch/x86/smpboot.c	Thu Jan 05 22:42:02 2012 +0800
> +++ b/xen/arch/x86/smpboot.c	Mon Jan 09 23:55:41 2012 +0800
> @@ -586,7 +586,10 @@
>      smpboot_setup_warm_reset_vector(start_eip);
>  
>      /* Starting actual IPI sequence... */
> -    boot_error = wakeup_secondary_cpu(apicid, start_eip);
> +    if ( tboot_in_measured_env() )
> +        boot_error = tboot_wake_ap(apicid, start_eip);
> +    else
> +        boot_error = wakeup_secondary_cpu(apicid, start_eip);

I'm afraid this is broken now for older tboot - you want to call
wakeup_secondary_cpu() if tboot_wake_ap() failed. All I had
asked in the first review round was that you don't call
tboot_wake_ap() without tboot_in_measured_env() returning
true.

Jan

>      if ( !boot_error )
>      {
> diff -r 8087674cceb9 xen/arch/x86/tboot.c
> --- a/xen/arch/x86/tboot.c	Thu Jan 05 22:42:02 2012 +0800
> +++ b/xen/arch/x86/tboot.c	Mon Jan 09 23:55:41 2012 +0800
> @@ -123,6 +123,8 @@
>      printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
>      printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
>      printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
> +    if ( tboot_shared->version >= 6 )
> +        printk("  flags: 0x%08x\n", tboot_shared->flags);
>  
>      /* these will be needed by tboot_protect_mem_regions() and/or
>         tboot_parse_dmar_table(), so get them now */
> @@ -529,6 +531,18 @@
>      panic("Memory integrity was lost on resume (%d)\n", error);
>  }
>  
> +int tboot_wake_ap(int apicid, unsigned long sipi_vec)
> +{
> +    if ( g_tboot_shared->version >= 6 &&
> +         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
> +    {
> +        g_tboot_shared->ap_wake_addr = sipi_vec;
> +        g_tboot_shared->ap_wake_trigger = apicid;
> +        return 0;
> +    }
> +    return -1;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff -r 8087674cceb9 xen/include/asm-x86/tboot.h
> --- a/xen/include/asm-x86/tboot.h	Thu Jan 05 22:42:02 2012 +0800
> +++ b/xen/include/asm-x86/tboot.h	Mon Jan 09 23:55:41 2012 +0800
> @@ -85,7 +85,7 @@
>  typedef struct __packed {
>      /* version 3+ fields: */
>      uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
> -    uint32_t  version;           /* Version number; currently supports 0.4 
> */
> +    uint32_t  version;           /* Version number; currently supports 0.6 
> */
>      uint32_t  log_addr;          /* physical addr of tb_log_t log */
>      uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
>      uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
> @@ -99,6 +99,13 @@
>      /* version 4+ fields: */
>                                   /* populated by tboot; will be encrypted 
> */
>      uint8_t   s3_key[TB_KEY_SIZE];
> +    /* version 5+ fields: */
> +    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
> +    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI */
> +    /* version 6+ fields: */
> +    uint32_t  flags;
> +    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
> +    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP */
>  } tboot_shared_t;
>  
>  #define TB_SHUTDOWN_REBOOT      0
> @@ -107,6 +114,9 @@
>  #define TB_SHUTDOWN_S3          3
>  #define TB_SHUTDOWN_HALT        4
>  
> +#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use 
> INIT-SIPI-SIPI
> +                                                 if clear, ap_wake_* if set 
> */
> +
>  /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
>  #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
>                                 { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
> @@ -120,6 +130,7 @@
>  int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
>  int tboot_s3_resume(void);
>  void tboot_s3_error(int error);
> +int tboot_wake_ap(int apicid, unsigned long sipi_vec);
>  
>  #endif /* __TBOOT_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:10:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:10:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHnG-0002Gp-G9; Mon, 09 Jan 2012 16:09:54 +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 1RkHnE-0002G7-Hj
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:09:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326125385!10167276!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31134 invoked from network); 9 Jan 2012 16:09:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 16:09:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326125385; l=7087;
	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=t7UYBY2ZHmHwLji4TH9dp9haXC0=;
	b=ia8pYjsdA+u+tbgSrcGjRq+qUaVyWlpsJKyr791vh3vWvocbQjLhkG9X/Ybs/HmZjjR
	rSFeAEXZJSVi7lQinpdthOuh0/jIOFMbcdomnqYczTZqudiMBAsGMNILaYfndxFgfwOTF
	BGK+EXv9t7CbbprNoqJNxHg5v6i+Iw5GkbM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by post.strato.de (mrclete mo25) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2012b0o09F9TpZ
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 17:09:40 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0F0C218638
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 17:09:39 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: de41b885dd70757c8a3a283e895d813c2f5e6744
Message-Id: <de41b885dd70757c8a3a.1326125378@probook.site>
In-Reply-To: <patchbomb.1326125376@probook.site>
References: <patchbomb.1326125376@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 17:09:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3] xenpaging: convert xenpaging_t to struct
	xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326125246 -3600
# Node ID de41b885dd70757c8a3a283e895d813c2f5e6744
# Parent  dfcef53aa44f76b0dc13fa2acb012f4158da5c7b
xenpaging: convert xenpaging_t to struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/pagein.c
--- a/tools/xenpaging/pagein.c
+++ b/tools/xenpaging/pagein.c
@@ -61,7 +61,7 @@ void page_in_trigger(void)
     pthread_cond_signal(&page_in_cond);
 }
 
-void create_page_in_thread(xenpaging_t *paging)
+void create_page_in_thread(struct xenpaging *paging)
 {
     page_in_args.dom = paging->mem_event.domain_id;
     page_in_args.pagein_queue = paging->pagein_queue;
diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -28,8 +28,8 @@
 #include "xenpaging.h"
 
 
-int policy_init(xenpaging_t *paging);
-int policy_choose_victim(xenpaging_t *paging, struct victim *victim);
+int policy_init(struct xenpaging *paging);
+int policy_choose_victim(struct xenpaging *paging, struct victim *victim);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -37,7 +37,7 @@ static unsigned long current_gfn;
 static unsigned long max_pages;
 
 
-int policy_init(xenpaging_t *paging)
+int policy_init(struct xenpaging *paging)
 {
     int i;
     int rc = -ENOMEM;
@@ -77,7 +77,7 @@ int policy_init(xenpaging_t *paging)
     return rc;
 }
 
-int policy_choose_victim(xenpaging_t *paging, struct victim *victim)
+int policy_choose_victim(struct xenpaging *paging, struct victim *victim)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -62,7 +62,7 @@ static void close_handler(int sig)
     unlink_pagefile();
 }
 
-static int xenpaging_mem_paging_flush_ioemu_cache(xenpaging_t *paging)
+static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 {
     struct xs_handle *xsh = paging->xs_handle;
     domid_t domain_id = paging->mem_event.domain_id;
@@ -76,7 +76,7 @@ static int xenpaging_mem_paging_flush_io
     return rc == true ? 0 : -1;
 }
 
-static int xenpaging_wait_for_event_or_timeout(xenpaging_t *paging)
+static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     xc_evtchn *xce = paging->mem_event.xce_handle;
@@ -164,7 +164,7 @@ err:
     return rc;
 }
 
-static int xenpaging_get_tot_pages(xenpaging_t *paging)
+static int xenpaging_get_tot_pages(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     xc_domaininfo_t domain_info;
@@ -219,7 +219,7 @@ static void usage(void)
     printf(" -h             --help                   this output.\n");
 }
 
-static int xenpaging_getopts(xenpaging_t *paging, int argc, char *argv[])
+static int xenpaging_getopts(struct xenpaging *paging, int argc, char *argv[])
 {
     int ch;
     static const char sopts[] = "hvd:f:m:r:";
@@ -278,9 +278,9 @@ static int xenpaging_getopts(xenpaging_t
     return 0;
 }
 
-static xenpaging_t *xenpaging_init(int argc, char *argv[])
+static struct xenpaging *xenpaging_init(int argc, char *argv[])
 {
-    xenpaging_t *paging;
+    struct xenpaging *paging;
     xc_domaininfo_t domain_info;
     xc_interface *xch = NULL;
     xentoollog_logger *dbg = NULL;
@@ -288,7 +288,7 @@ static xenpaging_t *xenpaging_init(int a
     int rc;
 
     /* Allocate memory */
-    paging = calloc(1, sizeof(xenpaging_t));
+    paging = calloc(1, sizeof(struct xenpaging));
     if ( !paging )
         goto err;
 
@@ -476,7 +476,7 @@ static xenpaging_t *xenpaging_init(int a
     return NULL;
 }
 
-static int xenpaging_teardown(xenpaging_t *paging)
+static int xenpaging_teardown(struct xenpaging *paging)
 {
     int rc;
     xc_interface *xch;
@@ -562,7 +562,7 @@ static void put_response(mem_event_t *me
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(xenpaging_t *paging, struct victim *victim, int fd, int i)
+static int xenpaging_evict_page(struct xenpaging *paging, struct victim *victim, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
@@ -613,7 +613,7 @@ static int xenpaging_evict_page(xenpagin
     return ret;
 }
 
-static int xenpaging_resume_page(xenpaging_t *paging, mem_event_response_t *rsp, int notify_policy)
+static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t *rsp, int notify_policy)
 {
     int ret;
 
@@ -647,7 +647,7 @@ static int xenpaging_resume_page(xenpagi
     return ret;
 }
 
-static int xenpaging_populate_page(xenpaging_t *paging,
+static int xenpaging_populate_page(struct xenpaging *paging,
     xen_pfn_t gfn, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
@@ -691,7 +691,7 @@ static int xenpaging_populate_page(xenpa
 }
 
 /* Trigger a page-in for a batch of pages */
-static void resume_pages(xenpaging_t *paging, int num_pages)
+static void resume_pages(struct xenpaging *paging, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int i, num = 0;
@@ -711,7 +711,7 @@ static void resume_pages(xenpaging_t *pa
         page_in_trigger();
 }
 
-static int evict_victim(xenpaging_t *paging, struct victim *victim, int fd, int i)
+static int evict_victim(struct xenpaging *paging, struct victim *victim, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
     int j = 0;
@@ -754,7 +754,7 @@ static int evict_victim(xenpaging_t *pag
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(xenpaging_t *paging, int fd, struct victim *victims, int num_pages)
+static int evict_pages(struct xenpaging *paging, int fd, struct victim *victims, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -780,7 +780,7 @@ static int evict_pages(xenpaging_t *pagi
 int main(int argc, char *argv[])
 {
     struct sigaction act;
-    xenpaging_t *paging;
+    struct xenpaging *paging;
     struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -40,7 +40,7 @@ typedef struct mem_event {
     void *ring_page;
 } mem_event_t;
 
-typedef struct xenpaging {
+struct xenpaging {
     xc_interface *xc_handle;
     struct xs_handle *xs_handle;
 
@@ -54,7 +54,7 @@ typedef struct xenpaging {
     int policy_mru_size;
     int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
-} xenpaging_t;
+};
 
 
 struct victim {
@@ -63,7 +63,7 @@ struct victim {
 };
 
 
-extern void create_page_in_thread(xenpaging_t *paging);
+extern void create_page_in_thread(struct xenpaging *paging);
 extern void page_in_trigger(void);
 
 #endif // __XEN_PAGING_H__

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:10:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:10:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHnG-0002Gp-G9; Mon, 09 Jan 2012 16:09:54 +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 1RkHnE-0002G7-Hj
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:09:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326125385!10167276!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31134 invoked from network); 9 Jan 2012 16:09:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 16:09:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326125385; l=7087;
	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=t7UYBY2ZHmHwLji4TH9dp9haXC0=;
	b=ia8pYjsdA+u+tbgSrcGjRq+qUaVyWlpsJKyr791vh3vWvocbQjLhkG9X/Ybs/HmZjjR
	rSFeAEXZJSVi7lQinpdthOuh0/jIOFMbcdomnqYczTZqudiMBAsGMNILaYfndxFgfwOTF
	BGK+EXv9t7CbbprNoqJNxHg5v6i+Iw5GkbM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by post.strato.de (mrclete mo25) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 2012b0o09F9TpZ
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 17:09:40 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0F0C218638
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 17:09:39 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: de41b885dd70757c8a3a283e895d813c2f5e6744
Message-Id: <de41b885dd70757c8a3a.1326125378@probook.site>
In-Reply-To: <patchbomb.1326125376@probook.site>
References: <patchbomb.1326125376@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 17:09:38 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3] xenpaging: convert xenpaging_t to struct
	xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326125246 -3600
# Node ID de41b885dd70757c8a3a283e895d813c2f5e6744
# Parent  dfcef53aa44f76b0dc13fa2acb012f4158da5c7b
xenpaging: convert xenpaging_t to struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/pagein.c
--- a/tools/xenpaging/pagein.c
+++ b/tools/xenpaging/pagein.c
@@ -61,7 +61,7 @@ void page_in_trigger(void)
     pthread_cond_signal(&page_in_cond);
 }
 
-void create_page_in_thread(xenpaging_t *paging)
+void create_page_in_thread(struct xenpaging *paging)
 {
     page_in_args.dom = paging->mem_event.domain_id;
     page_in_args.pagein_queue = paging->pagein_queue;
diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -28,8 +28,8 @@
 #include "xenpaging.h"
 
 
-int policy_init(xenpaging_t *paging);
-int policy_choose_victim(xenpaging_t *paging, struct victim *victim);
+int policy_init(struct xenpaging *paging);
+int policy_choose_victim(struct xenpaging *paging, struct victim *victim);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -37,7 +37,7 @@ static unsigned long current_gfn;
 static unsigned long max_pages;
 
 
-int policy_init(xenpaging_t *paging)
+int policy_init(struct xenpaging *paging)
 {
     int i;
     int rc = -ENOMEM;
@@ -77,7 +77,7 @@ int policy_init(xenpaging_t *paging)
     return rc;
 }
 
-int policy_choose_victim(xenpaging_t *paging, struct victim *victim)
+int policy_choose_victim(struct xenpaging *paging, struct victim *victim)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -62,7 +62,7 @@ static void close_handler(int sig)
     unlink_pagefile();
 }
 
-static int xenpaging_mem_paging_flush_ioemu_cache(xenpaging_t *paging)
+static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 {
     struct xs_handle *xsh = paging->xs_handle;
     domid_t domain_id = paging->mem_event.domain_id;
@@ -76,7 +76,7 @@ static int xenpaging_mem_paging_flush_io
     return rc == true ? 0 : -1;
 }
 
-static int xenpaging_wait_for_event_or_timeout(xenpaging_t *paging)
+static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     xc_evtchn *xce = paging->mem_event.xce_handle;
@@ -164,7 +164,7 @@ err:
     return rc;
 }
 
-static int xenpaging_get_tot_pages(xenpaging_t *paging)
+static int xenpaging_get_tot_pages(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     xc_domaininfo_t domain_info;
@@ -219,7 +219,7 @@ static void usage(void)
     printf(" -h             --help                   this output.\n");
 }
 
-static int xenpaging_getopts(xenpaging_t *paging, int argc, char *argv[])
+static int xenpaging_getopts(struct xenpaging *paging, int argc, char *argv[])
 {
     int ch;
     static const char sopts[] = "hvd:f:m:r:";
@@ -278,9 +278,9 @@ static int xenpaging_getopts(xenpaging_t
     return 0;
 }
 
-static xenpaging_t *xenpaging_init(int argc, char *argv[])
+static struct xenpaging *xenpaging_init(int argc, char *argv[])
 {
-    xenpaging_t *paging;
+    struct xenpaging *paging;
     xc_domaininfo_t domain_info;
     xc_interface *xch = NULL;
     xentoollog_logger *dbg = NULL;
@@ -288,7 +288,7 @@ static xenpaging_t *xenpaging_init(int a
     int rc;
 
     /* Allocate memory */
-    paging = calloc(1, sizeof(xenpaging_t));
+    paging = calloc(1, sizeof(struct xenpaging));
     if ( !paging )
         goto err;
 
@@ -476,7 +476,7 @@ static xenpaging_t *xenpaging_init(int a
     return NULL;
 }
 
-static int xenpaging_teardown(xenpaging_t *paging)
+static int xenpaging_teardown(struct xenpaging *paging)
 {
     int rc;
     xc_interface *xch;
@@ -562,7 +562,7 @@ static void put_response(mem_event_t *me
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(xenpaging_t *paging, struct victim *victim, int fd, int i)
+static int xenpaging_evict_page(struct xenpaging *paging, struct victim *victim, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
@@ -613,7 +613,7 @@ static int xenpaging_evict_page(xenpagin
     return ret;
 }
 
-static int xenpaging_resume_page(xenpaging_t *paging, mem_event_response_t *rsp, int notify_policy)
+static int xenpaging_resume_page(struct xenpaging *paging, mem_event_response_t *rsp, int notify_policy)
 {
     int ret;
 
@@ -647,7 +647,7 @@ static int xenpaging_resume_page(xenpagi
     return ret;
 }
 
-static int xenpaging_populate_page(xenpaging_t *paging,
+static int xenpaging_populate_page(struct xenpaging *paging,
     xen_pfn_t gfn, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
@@ -691,7 +691,7 @@ static int xenpaging_populate_page(xenpa
 }
 
 /* Trigger a page-in for a batch of pages */
-static void resume_pages(xenpaging_t *paging, int num_pages)
+static void resume_pages(struct xenpaging *paging, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int i, num = 0;
@@ -711,7 +711,7 @@ static void resume_pages(xenpaging_t *pa
         page_in_trigger();
 }
 
-static int evict_victim(xenpaging_t *paging, struct victim *victim, int fd, int i)
+static int evict_victim(struct xenpaging *paging, struct victim *victim, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
     int j = 0;
@@ -754,7 +754,7 @@ static int evict_victim(xenpaging_t *pag
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(xenpaging_t *paging, int fd, struct victim *victims, int num_pages)
+static int evict_pages(struct xenpaging *paging, int fd, struct victim *victims, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -780,7 +780,7 @@ static int evict_pages(xenpaging_t *pagi
 int main(int argc, char *argv[])
 {
     struct sigaction act;
-    xenpaging_t *paging;
+    struct xenpaging *paging;
     struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
diff -r dfcef53aa44f -r de41b885dd70 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -40,7 +40,7 @@ typedef struct mem_event {
     void *ring_page;
 } mem_event_t;
 
-typedef struct xenpaging {
+struct xenpaging {
     xc_interface *xc_handle;
     struct xs_handle *xs_handle;
 
@@ -54,7 +54,7 @@ typedef struct xenpaging {
     int policy_mru_size;
     int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
-} xenpaging_t;
+};
 
 
 struct victim {
@@ -63,7 +63,7 @@ struct victim {
 };
 
 
-extern void create_page_in_thread(xenpaging_t *paging);
+extern void create_page_in_thread(struct xenpaging *paging);
 extern void page_in_trigger(void);
 
 #endif // __XEN_PAGING_H__

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:10:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHnF-0002Ge-2X; Mon, 09 Jan 2012 16:09: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 1RkHnE-0002GJ-9Q
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:09:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326125341!49490185!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjAyOTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjAyOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19882 invoked from network); 9 Jan 2012 16:09:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 16:09:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326125386; l=1762;
	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=/vQOzYMexPKff1iOIBVy96EQFiI=;
	b=ip0H0r5LrsGbqg5KR1d3/lheba2Rkpv4ihI70hR2aSp1uWNUW/jKuIvEsyhFJ5lpTVn
	Oa86CGAjFYd/96LLpm2aLBCwJyNPUEfO7MzQQFhL4cFZRmxstE89xDpbqgKE++NWEtFc7
	+ZApAcGxbfs0MSQDe33KbPkeSgT7Iqx5rU4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by post.strato.de (mrclete mo60) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x0289bo09F8KJv
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 17:09:41 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4EF3318639
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 17:09:39 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 283e6ed3e1de572c9f974dd9083dc95e8cf60b15
Message-Id: <283e6ed3e1de572c9f97.1326125379@probook.site>
In-Reply-To: <patchbomb.1326125376@probook.site>
References: <patchbomb.1326125376@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 17:09:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3] xenpaging: convert mem_event_t to struct
	mem_event
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326125252 -3600
# Node ID 283e6ed3e1de572c9f974dd9083dc95e8cf60b15
# Parent  de41b885dd70757c8a3a283e895d813c2f5e6744
xenpaging: convert mem_event_t to struct mem_event

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r de41b885dd70 -r 283e6ed3e1de tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -528,7 +528,7 @@ static int xenpaging_teardown(struct xen
     return -1;
 }
 
-static void get_request(mem_event_t *mem_event, mem_event_request_t *req)
+static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
 {
     mem_event_back_ring_t *back_ring;
     RING_IDX req_cons;
@@ -545,7 +545,7 @@ static void get_request(mem_event_t *mem
     back_ring->sring->req_event = req_cons + 1;
 }
 
-static void put_response(mem_event_t *mem_event, mem_event_response_t *rsp)
+static void put_response(struct mem_event *mem_event, mem_event_response_t *rsp)
 {
     mem_event_back_ring_t *back_ring;
     RING_IDX rsp_prod;
diff -r de41b885dd70 -r 283e6ed3e1de tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -31,14 +31,14 @@
 
 #define XENPAGING_PAGEIN_QUEUE_SIZE 64
 
-typedef struct mem_event {
+struct mem_event {
     domid_t domain_id;
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
     mem_event_shared_page_t *shared_page;
     void *ring_page;
-} mem_event_t;
+};
 
 struct xenpaging {
     xc_interface *xc_handle;
@@ -46,7 +46,7 @@ struct xenpaging {
 
     unsigned long *bitmap;
 
-    mem_event_t mem_event;
+    struct mem_event mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
     int num_paged_out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:10:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:10:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHnF-0002Ge-2X; Mon, 09 Jan 2012 16:09: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 1RkHnE-0002GJ-9Q
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:09:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326125341!49490185!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjAyOTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjAyOTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19882 invoked from network); 9 Jan 2012 16:09:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 16:09:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326125386; l=1762;
	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=/vQOzYMexPKff1iOIBVy96EQFiI=;
	b=ip0H0r5LrsGbqg5KR1d3/lheba2Rkpv4ihI70hR2aSp1uWNUW/jKuIvEsyhFJ5lpTVn
	Oa86CGAjFYd/96LLpm2aLBCwJyNPUEfO7MzQQFhL4cFZRmxstE89xDpbqgKE++NWEtFc7
	+ZApAcGxbfs0MSQDe33KbPkeSgT7Iqx5rU4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by post.strato.de (mrclete mo60) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x0289bo09F8KJv
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 17:09:41 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4EF3318639
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 17:09:39 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 283e6ed3e1de572c9f974dd9083dc95e8cf60b15
Message-Id: <283e6ed3e1de572c9f97.1326125379@probook.site>
In-Reply-To: <patchbomb.1326125376@probook.site>
References: <patchbomb.1326125376@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 17:09:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3] xenpaging: convert mem_event_t to struct
	mem_event
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326125252 -3600
# Node ID 283e6ed3e1de572c9f974dd9083dc95e8cf60b15
# Parent  de41b885dd70757c8a3a283e895d813c2f5e6744
xenpaging: convert mem_event_t to struct mem_event

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r de41b885dd70 -r 283e6ed3e1de tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -528,7 +528,7 @@ static int xenpaging_teardown(struct xen
     return -1;
 }
 
-static void get_request(mem_event_t *mem_event, mem_event_request_t *req)
+static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
 {
     mem_event_back_ring_t *back_ring;
     RING_IDX req_cons;
@@ -545,7 +545,7 @@ static void get_request(mem_event_t *mem
     back_ring->sring->req_event = req_cons + 1;
 }
 
-static void put_response(mem_event_t *mem_event, mem_event_response_t *rsp)
+static void put_response(struct mem_event *mem_event, mem_event_response_t *rsp)
 {
     mem_event_back_ring_t *back_ring;
     RING_IDX rsp_prod;
diff -r de41b885dd70 -r 283e6ed3e1de tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -31,14 +31,14 @@
 
 #define XENPAGING_PAGEIN_QUEUE_SIZE 64
 
-typedef struct mem_event {
+struct mem_event {
     domid_t domain_id;
     xc_evtchn *xce_handle;
     int port;
     mem_event_back_ring_t back_ring;
     mem_event_shared_page_t *shared_page;
     void *ring_page;
-} mem_event_t;
+};
 
 struct xenpaging {
     xc_interface *xc_handle;
@@ -46,7 +46,7 @@ struct xenpaging {
 
     unsigned long *bitmap;
 
-    mem_event_t mem_event;
+    struct mem_event mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
     int num_paged_out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:10:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHnO-0002Hv-2c; Mon, 09 Jan 2012 16:10:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RkHnM-0002He-FE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:10:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326125379!61706470!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29015 invoked from network); 9 Jan 2012 16:09:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 16:09:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326125398; l=645;
	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=wYLp9IqgGTAmyZ+jgNCmpLZzcZU=;
	b=r5yg3U7tmSPFD9b48fs9MyL1hPIAegv+vMyClcvR4g5dktGMWJ1SYDI8xO9jHzbT4Oi
	QENlsxq/tsUZSNoj3Y2Q1v8lwbyTfF4GTRGeW7UdpJhfwxQrq5JhzS8yvIrnE/H8+Ky24
	RsJL9goIehMKWUsuyY17fQEjC5DRVCsnk4k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (fruni mo35) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a055f4o09FDhLn
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 17:09:39 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4F9C618634
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 17:09:38 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1326125376@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 17:09:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3] tools/xenpaging: remove typedefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


As noted by Ian Jackson, use of types with names ending in _t is
reserved to the C implementation (compiler and runtime). This series
removes all typedefs from xenpaging code.

Changes:
xenpaging: convert xenpaging_victim_t to struct victim
xenpaging: convert xenpaging_t to struct xenpaging
xenpaging: convert mem_event_t to struct mem_event

 tools/xenpaging/pagein.c         |    2 -
 tools/xenpaging/policy.h         |    4 +--
 tools/xenpaging/policy_default.c |    4 +--
 tools/xenpaging/xenpaging.c      |   40 ++++++++++++++++++---------------------
 tools/xenpaging/xenpaging.h      |   16 +++++++--------
 5 files changed, 32 insertions(+), 34 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:10:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHnO-0002Hv-2c; Mon, 09 Jan 2012 16:10:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RkHnM-0002He-FE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:10:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326125379!61706470!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29015 invoked from network); 9 Jan 2012 16:09:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 16:09:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326125398; l=645;
	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=wYLp9IqgGTAmyZ+jgNCmpLZzcZU=;
	b=r5yg3U7tmSPFD9b48fs9MyL1hPIAegv+vMyClcvR4g5dktGMWJ1SYDI8xO9jHzbT4Oi
	QENlsxq/tsUZSNoj3Y2Q1v8lwbyTfF4GTRGeW7UdpJhfwxQrq5JhzS8yvIrnE/H8+Ky24
	RsJL9goIehMKWUsuyY17fQEjC5DRVCsnk4k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (fruni mo35) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a055f4o09FDhLn
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 17:09:39 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4F9C618634
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 17:09:38 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1326125376@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 17:09:36 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3] tools/xenpaging: remove typedefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


As noted by Ian Jackson, use of types with names ending in _t is
reserved to the C implementation (compiler and runtime). This series
removes all typedefs from xenpaging code.

Changes:
xenpaging: convert xenpaging_victim_t to struct victim
xenpaging: convert xenpaging_t to struct xenpaging
xenpaging: convert mem_event_t to struct mem_event

 tools/xenpaging/pagein.c         |    2 -
 tools/xenpaging/policy.h         |    4 +--
 tools/xenpaging/policy_default.c |    4 +--
 tools/xenpaging/xenpaging.c      |   40 ++++++++++++++++++---------------------
 tools/xenpaging/xenpaging.h      |   16 +++++++--------
 5 files changed, 32 insertions(+), 34 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:12:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHpW-0002cB-MM; Mon, 09 Jan 2012 16:12:14 +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 1RkHpV-0002at-Kl
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:12:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326125501!54943659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17284 invoked from network); 9 Jan 2012 16:11:41 -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;
	9 Jan 2012 16:11:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9901087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 16:12:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 16:12:07 +0000
Date: Mon, 9 Jan 2012 16:12:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120109145648.GA25563@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
	<20120109145648.GA25563@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> > I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
> > X86_IO_APIC && ACPI && PCI" to XEN either.
> > However it should be possible to add only the right dependencies to the
> > right places.
> > In practice it should be sufficient to:
> > 
> > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> 
> Not good. You can make non-ACPI builds with PCI.
> 
> .. and you are missing CONFIG_PCI in there.
> > 
> > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;
> 
> OK. That sounds good.
> > 
> > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> 
> No.. same issue - non-ACPI builds can be with PCI.
> > 

Right.. in that case we should carefully replace the 'ifdef
CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.
It would effectively keep things as they are now: if ACPI and XEN are
enabled together in the config file, your kernel is able to setup
interrupts when running as DOM0.
Regarding X86_LOCAL_APIC and X86_IO_APIC I cannot recall anymore where
these dependencies come from exactly.


> > > The driver domain concept may actually be the technical need for
> > > making XEN_DOM0 optional. If we want the ability to build a minimally
> > > configed XEN kernel to be used as a driver domain, then it doesn't
> > > seem like we'd want it to also be capable of running as an initial
> > > domain, or to be forced to have all the dependencies and code of an
> > > initial domain.
> > 
> > In practice any decent driver domain needs PCI and ACPI support, so
> > basically it has the same config requirement of XEN_DOM0. At that point
> 
> Sure.. for backends. But for frontends that requirement is not always true.

Right but a driver domain is bound to have at least the pci backend.


> > we have already discussed that having XEN_DOM0 enabled or disabled
> > hardly makes any differences, so we can just get rid of it.
> 
> Or in other words, substitute it as CONFIG_PCI_XEN.

I was just trying to assign the dependencies where they really belong
and I proposed to remove the 'ifdef CONFIG_ACPI' because I didn't
realize that one can build working PCI configurations on XEN without it.

The fact that PCI_XEN would be used then almost as XEN_DOM0 is used now
is just a side effect, due to the fact that PCI and device interrupts
initialization is what mainly differentiates dom0 from other
configurations.


> But this brings a question about MCE, ACPI cpu freq and ACPI S3.
> Those all belong to the dom0 - not to any driver domain. So getting rid
> of CONFIG_XEN_DOM0 would present a problem - what would those depend on?

They would depend on XEN and whatever else they really depend on, for
example ACPI.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:12:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:12:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHpW-0002cB-MM; Mon, 09 Jan 2012 16:12:14 +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 1RkHpV-0002at-Kl
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:12:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326125501!54943659!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17284 invoked from network); 9 Jan 2012 16:11:41 -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;
	9 Jan 2012 16:11:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9901087"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 16:12:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 16:12:07 +0000
Date: Mon, 9 Jan 2012 16:12:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120109145648.GA25563@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
	<20120109145648.GA25563@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> > I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
> > X86_IO_APIC && ACPI && PCI" to XEN either.
> > However it should be possible to add only the right dependencies to the
> > right places.
> > In practice it should be sufficient to:
> > 
> > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> 
> Not good. You can make non-ACPI builds with PCI.
> 
> .. and you are missing CONFIG_PCI in there.
> > 
> > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;
> 
> OK. That sounds good.
> > 
> > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> 
> No.. same issue - non-ACPI builds can be with PCI.
> > 

Right.. in that case we should carefully replace the 'ifdef
CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.
It would effectively keep things as they are now: if ACPI and XEN are
enabled together in the config file, your kernel is able to setup
interrupts when running as DOM0.
Regarding X86_LOCAL_APIC and X86_IO_APIC I cannot recall anymore where
these dependencies come from exactly.


> > > The driver domain concept may actually be the technical need for
> > > making XEN_DOM0 optional. If we want the ability to build a minimally
> > > configed XEN kernel to be used as a driver domain, then it doesn't
> > > seem like we'd want it to also be capable of running as an initial
> > > domain, or to be forced to have all the dependencies and code of an
> > > initial domain.
> > 
> > In practice any decent driver domain needs PCI and ACPI support, so
> > basically it has the same config requirement of XEN_DOM0. At that point
> 
> Sure.. for backends. But for frontends that requirement is not always true.

Right but a driver domain is bound to have at least the pci backend.


> > we have already discussed that having XEN_DOM0 enabled or disabled
> > hardly makes any differences, so we can just get rid of it.
> 
> Or in other words, substitute it as CONFIG_PCI_XEN.

I was just trying to assign the dependencies where they really belong
and I proposed to remove the 'ifdef CONFIG_ACPI' because I didn't
realize that one can build working PCI configurations on XEN without it.

The fact that PCI_XEN would be used then almost as XEN_DOM0 is used now
is just a side effect, due to the fact that PCI and device interrupts
initialization is what mainly differentiates dom0 from other
configurations.


> But this brings a question about MCE, ACPI cpu freq and ACPI S3.
> Those all belong to the dom0 - not to any driver domain. So getting rid
> of CONFIG_XEN_DOM0 would present a problem - what would those depend on?

They would depend on XEN and whatever else they really depend on, for
example ACPI.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:13:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16: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 1RkHqM-0002im-5Z; Mon, 09 Jan 2012 16:13:06 +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 1RkHqK-0002hw-7X
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:13:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326125394!10114657!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13595 invoked from network); 9 Jan 2012 16:09:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 16:09:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326125394; l=3411;
	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=NKHL3l4Z5Jzi+6DmqsCoiKPQgcM=;
	b=AwngSAAUe0r7U4E3XxPsltp8XLbg9D0nyAb2xLVEgD5vkTxwmlW/cteupiJfd3iMp8S
	VTqEajISUMvKOCXN9F4e/M5cpWsS6U/JBhYixElmANgn/ya+5eCQVpk+co/EemeZYKuPt
	JkwHkxKN3zrQcy0pp129EPJjturrcFOV/NM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (fruni mo19) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C049fdo09FcR1C
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 17:09:39 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id A28AF18637
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 17:09:38 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dfcef53aa44f76b0dc13fa2acb012f4158da5c7b
Message-Id: <dfcef53aa44f76b0dc13.1326125377@probook.site>
In-Reply-To: <patchbomb.1326125376@probook.site>
References: <patchbomb.1326125376@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 17:09:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3] xenpaging: convert xenpaging_victim_t to
	struct victim
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326125241 -3600
# Node ID dfcef53aa44f76b0dc13fa2acb012f4158da5c7b
# Parent  3a22ed3ec534799b3cab55b0dc0a7380e701ecbe
xenpaging: convert xenpaging_victim_t to struct victim

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3a22ed3ec534 -r dfcef53aa44f tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -29,7 +29,7 @@
 
 
 int policy_init(xenpaging_t *paging);
-int policy_choose_victim(xenpaging_t *paging, xenpaging_victim_t *victim);
+int policy_choose_victim(xenpaging_t *paging, struct victim *victim);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r 3a22ed3ec534 -r dfcef53aa44f tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -77,7 +77,7 @@ int policy_init(xenpaging_t *paging)
     return rc;
 }
 
-int policy_choose_victim(xenpaging_t *paging, xenpaging_victim_t *victim)
+int policy_choose_victim(xenpaging_t *paging, struct victim *victim)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
diff -r 3a22ed3ec534 -r dfcef53aa44f tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -562,8 +562,7 @@ static void put_response(mem_event_t *me
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(xenpaging_t *paging,
-                         xenpaging_victim_t *victim, int fd, int i)
+static int xenpaging_evict_page(xenpaging_t *paging, struct victim *victim, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
@@ -712,8 +711,7 @@ static void resume_pages(xenpaging_t *pa
         page_in_trigger();
 }
 
-static int evict_victim(xenpaging_t *paging,
-                        xenpaging_victim_t *victim, int fd, int i)
+static int evict_victim(xenpaging_t *paging, struct victim *victim, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
     int j = 0;
@@ -756,7 +754,7 @@ static int evict_victim(xenpaging_t *pag
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(xenpaging_t *paging, int fd, xenpaging_victim_t *victims, int num_pages)
+static int evict_pages(xenpaging_t *paging, int fd, struct victim *victims, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -783,7 +781,7 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     xenpaging_t *paging;
-    xenpaging_victim_t *victims;
+    struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int num, prev_num = 0;
@@ -817,7 +815,7 @@ int main(int argc, char *argv[])
     }
 
     /* Allocate upper limit of pages to allow growing and shrinking */
-    victims = calloc(paging->max_pages, sizeof(xenpaging_victim_t));
+    victims = calloc(paging->max_pages, sizeof(struct victim));
     if ( !victims )
         goto out;
 
diff -r 3a22ed3ec534 -r dfcef53aa44f tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -57,10 +57,10 @@ typedef struct xenpaging {
 } xenpaging_t;
 
 
-typedef struct xenpaging_victim {
+struct victim {
     /* the gfn of the page to evict */
     unsigned long gfn;
-} xenpaging_victim_t;
+};
 
 
 extern void create_page_in_thread(xenpaging_t *paging);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:13:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16: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 1RkHqM-0002im-5Z; Mon, 09 Jan 2012 16:13:06 +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 1RkHqK-0002hw-7X
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:13:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326125394!10114657!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTc3NDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13595 invoked from network); 9 Jan 2012 16:09:54 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-16.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 16:09:54 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326125394; l=3411;
	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=NKHL3l4Z5Jzi+6DmqsCoiKPQgcM=;
	b=AwngSAAUe0r7U4E3XxPsltp8XLbg9D0nyAb2xLVEgD5vkTxwmlW/cteupiJfd3iMp8S
	VTqEajISUMvKOCXN9F4e/M5cpWsS6U/JBhYixElmANgn/ya+5eCQVpk+co/EemeZYKuPt
	JkwHkxKN3zrQcy0pp129EPJjturrcFOV/NM=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by smtp.strato.de (fruni mo19) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id C049fdo09FcR1C
	for <xen-devel@lists.xensource.com>;
	Mon, 9 Jan 2012 17:09:39 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id A28AF18637
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 17:09:38 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dfcef53aa44f76b0dc13fa2acb012f4158da5c7b
Message-Id: <dfcef53aa44f76b0dc13.1326125377@probook.site>
In-Reply-To: <patchbomb.1326125376@probook.site>
References: <patchbomb.1326125376@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 09 Jan 2012 17:09:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3] xenpaging: convert xenpaging_victim_t to
	struct victim
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326125241 -3600
# Node ID dfcef53aa44f76b0dc13fa2acb012f4158da5c7b
# Parent  3a22ed3ec534799b3cab55b0dc0a7380e701ecbe
xenpaging: convert xenpaging_victim_t to struct victim

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3a22ed3ec534 -r dfcef53aa44f tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -29,7 +29,7 @@
 
 
 int policy_init(xenpaging_t *paging);
-int policy_choose_victim(xenpaging_t *paging, xenpaging_victim_t *victim);
+int policy_choose_victim(xenpaging_t *paging, struct victim *victim);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r 3a22ed3ec534 -r dfcef53aa44f tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -77,7 +77,7 @@ int policy_init(xenpaging_t *paging)
     return rc;
 }
 
-int policy_choose_victim(xenpaging_t *paging, xenpaging_victim_t *victim)
+int policy_choose_victim(xenpaging_t *paging, struct victim *victim)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
diff -r 3a22ed3ec534 -r dfcef53aa44f tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -562,8 +562,7 @@ static void put_response(mem_event_t *me
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(xenpaging_t *paging,
-                         xenpaging_victim_t *victim, int fd, int i)
+static int xenpaging_evict_page(xenpaging_t *paging, struct victim *victim, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
@@ -712,8 +711,7 @@ static void resume_pages(xenpaging_t *pa
         page_in_trigger();
 }
 
-static int evict_victim(xenpaging_t *paging,
-                        xenpaging_victim_t *victim, int fd, int i)
+static int evict_victim(xenpaging_t *paging, struct victim *victim, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
     int j = 0;
@@ -756,7 +754,7 @@ static int evict_victim(xenpaging_t *pag
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(xenpaging_t *paging, int fd, xenpaging_victim_t *victims, int num_pages)
+static int evict_pages(xenpaging_t *paging, int fd, struct victim *victims, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -783,7 +781,7 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     xenpaging_t *paging;
-    xenpaging_victim_t *victims;
+    struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int num, prev_num = 0;
@@ -817,7 +815,7 @@ int main(int argc, char *argv[])
     }
 
     /* Allocate upper limit of pages to allow growing and shrinking */
-    victims = calloc(paging->max_pages, sizeof(xenpaging_victim_t));
+    victims = calloc(paging->max_pages, sizeof(struct victim));
     if ( !victims )
         goto out;
 
diff -r 3a22ed3ec534 -r dfcef53aa44f tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -57,10 +57,10 @@ typedef struct xenpaging {
 } xenpaging_t;
 
 
-typedef struct xenpaging_victim {
+struct victim {
     /* the gfn of the page to evict */
     unsigned long gfn;
-} xenpaging_victim_t;
+};
 
 
 extern void create_page_in_thread(xenpaging_t *paging);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:14:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHr6-0002qV-Kw; Mon, 09 Jan 2012 16:13:52 +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 1RkHr5-0002oz-2v
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:13:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326125467!10114853!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3OTM1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18315 invoked from network); 9 Jan 2012 16:11:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 16:11:08 -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
	q09GB5Ba030400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 16:11:06 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
	q09GB5Uw027033
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 16:11:05 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
	q09GB4cr010333; Mon, 9 Jan 2012 10:11:04 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 08:11:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A29D940944; Mon,  9 Jan 2012 11:09:19 -0500 (EST)
Date: Mon, 9 Jan 2012 11:09:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: MaoXiaoyun <tinnycloud@hotmail.com>
Message-ID: <20120109160919.GA28700@phenom.dumpdata.com>
References: <mailman.6093.1325902643.12970.xen-devel@lists.xensource.com>
	<BLU157-W65C4641D5245A308C327C2DA9A0@phx.gbl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BLU157-W65C4641D5245A308C327C2DA9A0@phx.gbl>
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.4F0B119A.01DC,ss=1,re=0.000,fgs=0
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux Container and Tapdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 07, 2012 at 12:17:23PM +0800, MaoXiaoyun wrote:
> 
> Hi:
>  
>       Recently I have some study on linux container(lxc), which is a light weight OS level
> virtualization.
>  
>      With the previous knowledge of tapdisk, I have an assumption that, I may could
> use the vhd for each container to seperate the storage of all containers, or even in 
> later days, vhd is stored in distributed storage, container could be migrated.
>  
>       Build filesystem on tapdev and mount it under some directory, put the rootfs of 

How would you "mount" a tapdev filesystem?

But more interestingly, how would you migrate your tap disk? Is it on NFS or OCFS2
or iSCSI? If so, why not just expand the filesystem on an iSCSI disk and mount it
on other machines and "migrate it".

> container into that dir, and start the lxc, I haven't try this, will try later.

I am not really sure how one would freeze and migrate the processes? Does the
cgroups have that functionality?

>       
>      I post my idea here, hope someone has one forsee comments.
>  
>      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 Mon Jan 09 16:14:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkHr6-0002qV-Kw; Mon, 09 Jan 2012 16:13:52 +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 1RkHr5-0002oz-2v
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:13:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326125467!10114853!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3OTM1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18315 invoked from network); 9 Jan 2012 16:11:08 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-16.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 16:11:08 -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
	q09GB5Ba030400
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 16:11:06 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
	q09GB5Uw027033
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 16:11:05 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
	q09GB4cr010333; Mon, 9 Jan 2012 10:11:04 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 08:11:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A29D940944; Mon,  9 Jan 2012 11:09:19 -0500 (EST)
Date: Mon, 9 Jan 2012 11:09:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: MaoXiaoyun <tinnycloud@hotmail.com>
Message-ID: <20120109160919.GA28700@phenom.dumpdata.com>
References: <mailman.6093.1325902643.12970.xen-devel@lists.xensource.com>
	<BLU157-W65C4641D5245A308C327C2DA9A0@phx.gbl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BLU157-W65C4641D5245A308C327C2DA9A0@phx.gbl>
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.4F0B119A.01DC,ss=1,re=0.000,fgs=0
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux Container and Tapdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 07, 2012 at 12:17:23PM +0800, MaoXiaoyun wrote:
> 
> Hi:
>  
>       Recently I have some study on linux container(lxc), which is a light weight OS level
> virtualization.
>  
>      With the previous knowledge of tapdisk, I have an assumption that, I may could
> use the vhd for each container to seperate the storage of all containers, or even in 
> later days, vhd is stored in distributed storage, container could be migrated.
>  
>       Build filesystem on tapdev and mount it under some directory, put the rootfs of 

How would you "mount" a tapdev filesystem?

But more interestingly, how would you migrate your tap disk? Is it on NFS or OCFS2
or iSCSI? If so, why not just expand the filesystem on an iSCSI disk and mount it
on other machines and "migrate it".

> container into that dir, and start the lxc, I haven't try this, will try later.

I am not really sure how one would freeze and migrate the processes? Does the
cgroups have that functionality?

>       
>      I post my idea here, hope someone has one forsee comments.
>  
>      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 Mon Jan 09 16:36:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:36:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkICc-0003Qu-Vg; Mon, 09 Jan 2012 16:36:06 +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 1RkICb-0003Qp-An
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:36:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326126958!8414421!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDE2Nzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1874 invoked from network); 9 Jan 2012 16:35:59 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 16:35:59 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 809731D6F;
	Mon,  9 Jan 2012 18:35:57 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 54D4A20058; Mon,  9 Jan 2012 18:35:57 +0200 (EET)
Date: Mon, 9 Jan 2012 18:35:57 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120109163557.GH12984@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>
	<20111214090338.GS12984@reaktio.net>
	<alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
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


Hello,

Ian (Jackson): Did you have time to look at these 6 patches for pygrub?
They're already in xen-unstable, and they should be backported to xen-4.1-t=
esting.

http://xenbits.xen.org/hg/xen-unstable.hg/rev/85d7b207fabc
http://xenbits.xen.org/hg/xen-unstable.hg/rev/138f707fa598
http://xenbits.xen.org/hg/xen-unstable.hg/rev/65679fee0177
http://xenbits.xen.org/hg/xen-unstable.hg/rev/152049468175
http://xenbits.xen.org/hg/xen-unstable.hg/rev/979bc34d0ad0
http://xenbits.xen.org/hg/xen-unstable.hg/rev/c681dd5aecf3

In the case they don't apply as-is to xen-4.1-testing =

Fedora 16 xen-4.1.2-2.fc16.src.rpm already contains those patches backporte=
d to 4.1.2.

Thanks,

-- Pasi


On Wed, Dec 14, 2011 at 12:11:33PM +0000, M A Young wrote:
> On Wed, 14 Dec 2011, Pasi K=E4rkk=E4inen wrote:
>
>> 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/update=
s/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.ExtLinuxConfig=
File),
>                             ["/boot/isolinux/isolinux.cfg",
>                              "/boot/extlinux.conf"])


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:36:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16:36:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkICc-0003Qu-Vg; Mon, 09 Jan 2012 16:36:06 +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 1RkICb-0003Qp-An
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:36:05 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326126958!8414421!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDE2Nzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1874 invoked from network); 9 Jan 2012 16:35:59 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 16:35:59 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 809731D6F;
	Mon,  9 Jan 2012 18:35:57 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 54D4A20058; Mon,  9 Jan 2012 18:35:57 +0200 (EET)
Date: Mon, 9 Jan 2012 18:35:57 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120109163557.GH12984@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>
	<20111214090338.GS12984@reaktio.net>
	<alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
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


Hello,

Ian (Jackson): Did you have time to look at these 6 patches for pygrub?
They're already in xen-unstable, and they should be backported to xen-4.1-t=
esting.

http://xenbits.xen.org/hg/xen-unstable.hg/rev/85d7b207fabc
http://xenbits.xen.org/hg/xen-unstable.hg/rev/138f707fa598
http://xenbits.xen.org/hg/xen-unstable.hg/rev/65679fee0177
http://xenbits.xen.org/hg/xen-unstable.hg/rev/152049468175
http://xenbits.xen.org/hg/xen-unstable.hg/rev/979bc34d0ad0
http://xenbits.xen.org/hg/xen-unstable.hg/rev/c681dd5aecf3

In the case they don't apply as-is to xen-4.1-testing =

Fedora 16 xen-4.1.2-2.fc16.src.rpm already contains those patches backporte=
d to 4.1.2.

Thanks,

-- Pasi


On Wed, Dec 14, 2011 at 12:11:33PM +0000, M A Young wrote:
> On Wed, 14 Dec 2011, Pasi K=E4rkk=E4inen wrote:
>
>> 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/update=
s/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.ExtLinuxConfig=
File),
>                             ["/boot/isolinux/isolinux.cfg",
>                              "/boot/extlinux.conf"])


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:45:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16: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 1RkILH-0003ax-3e; Mon, 09 Jan 2012 16:45: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 1RkILE-0003as-HO
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:45:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326127080!10119134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21079 invoked from network); 9 Jan 2012 16:38:00 -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;
	9 Jan 2012 16:38:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9901827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 16:37:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 9 Jan 2012
	16:37:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>, xen-devel
	<xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 16:37:59 +0000
References: <4F071654.3000102@amd.com>
	<1326012504.29084.41.camel@dagon.hellion.org.uk>
	<4F0B1672.5080304@amd.com>
In-Reply-To: <4F0B1672.5080304@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326127079.17210.114.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] netbsd: disable CONFIG_SYSTEM_LIBAIO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 with the list CC that you dropped put back)

On Mon, 2012-01-09 at 16:31 +0000, Christoph Egger wrote:
> On 01/08/12 09:48, Ian Campbell wrote:
> > On Fri, 2012-01-06 at 15:42 +0000, Christoph Egger wrote:
> >> Disable CONFIG_SYSTEM_LIBAIO on NetBSD.
> >>
> >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> >
> > There's no libaio in NetBSD? Could you add it? I hope that one day we
> > might be able to get rid of these sorts of bundled system libraries.
> 
> NetBSD provides the aio interface (IEEE Std 1003.1-2001 (``POSIX.1''))
> via the POSIX real-time library (-lrt).

Any why can't Xen use that then?

Your patch makes netbsd use tools/libaio instead which we would like to
avoid.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 16:45:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 16: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 1RkILH-0003ax-3e; Mon, 09 Jan 2012 16:45: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 1RkILE-0003as-HO
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:45:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326127080!10119134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21079 invoked from network); 9 Jan 2012 16:38:00 -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;
	9 Jan 2012 16:38:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9901827"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 16:37:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0; Mon, 9 Jan 2012
	16:37:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>, xen-devel
	<xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 16:37:59 +0000
References: <4F071654.3000102@amd.com>
	<1326012504.29084.41.camel@dagon.hellion.org.uk>
	<4F0B1672.5080304@amd.com>
In-Reply-To: <4F0B1672.5080304@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326127079.17210.114.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] [PATCH] netbsd: disable CONFIG_SYSTEM_LIBAIO
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 with the list CC that you dropped put back)

On Mon, 2012-01-09 at 16:31 +0000, Christoph Egger wrote:
> On 01/08/12 09:48, Ian Campbell wrote:
> > On Fri, 2012-01-06 at 15:42 +0000, Christoph Egger wrote:
> >> Disable CONFIG_SYSTEM_LIBAIO on NetBSD.
> >>
> >> Signed-off-by: Christoph Egger<Christoph.Egger@amd.com>
> >
> > There's no libaio in NetBSD? Could you add it? I hope that one day we
> > might be able to get rid of these sorts of bundled system libraries.
> 
> NetBSD provides the aio interface (IEEE Std 1003.1-2001 (``POSIX.1''))
> via the POSIX real-time library (-lrt).

Any why can't Xen use that then?

Your patch makes netbsd use tools/libaio instead which we would like to
avoid.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:06:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkIg1-0003pl-4v; Mon, 09 Jan 2012 17:06: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 1RkIfz-0003pg-Ta
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:06:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326128780!10199116!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3OTM1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25893 invoked from network); 9 Jan 2012 17:06:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 17:06:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q09H6DRP011842
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 17:06:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q09H697v027175
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 17:06:10 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
	q09H685B006778; Mon, 9 Jan 2012 11:06:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 09:06:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 634A040944; Mon,  9 Jan 2012 12:04:18 -0500 (EST)
Date: Mon, 9 Jan 2012 12:04:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120109170418.GD28700@phenom.dumpdata.com>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
	<20120109145648.GA25563@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
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.4F0B1E86.00F1,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 09, 2012 at 04:12:10PM +0000, Stefano Stabellini wrote:
> On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> > > I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
> > > X86_IO_APIC && ACPI && PCI" to XEN either.
> > > However it should be possible to add only the right dependencies to the
> > > right places.
> > > In practice it should be sufficient to:
> > > 
> > > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> > 
> > Not good. You can make non-ACPI builds with PCI.
> > 
> > .. and you are missing CONFIG_PCI in there.
> > > 
> > > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;
> > 
> > OK. That sounds good.
> > > 
> > > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> > 
> > No.. same issue - non-ACPI builds can be with PCI.
> > > 
> 
> Right.. in that case we should carefully replace the 'ifdef
> CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.

.. which I think I did at some point as part of cleanup and then
removed them since it peppered the xen.c with tons of #ifdef CONFIG_ACPI.

What about PVonHVM. There is this nagging feeling in the back of my
head that turning CONFIG_XEN_DOM0 disables the CONFIG_PVHVM option?
Or something like that? Maybe it is the other way around?

It would seem we need to seperate the PVHVM  from DOM0. But the extra
complexity comes with Mukesh's PVonHVM Hybrid which can do dom0 stuff
with PVonHVM (should be searchable on xen-devel to find the patches).

Ian also mentioned that we MUST have the XEN_PRIVILIGED option, otherwise
we will cause a regression with the GRUB tools. So that must stay or we need
provide a deprecation schedule for the next 3 years to remove it and
have patches in the GRUB toolchains.

Either way, there is also the question of making sure that no regressions
are introduced - so a lot of the CONFIG_* interdependencies will have
to be checked. I think that means checking CONFIG_XEN, CONFIG_PRIVILIGED,
CONFIG_PVHVM, CONFIG_PCI, CONFIG_ACPI, CONFIG_XEN_BACKEND in various combinations.

Oh, I forgot CONFIG_XEN_FRONTEND.. And I think that one can also become
a module (ditto for XEN_BACKEND)

And everytime we did something to those we managed to mess them up so
we should be dilligient.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:06:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:06:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkIg1-0003pl-4v; Mon, 09 Jan 2012 17:06: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 1RkIfz-0003pg-Ta
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:06:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326128780!10199116!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ3OTM1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25893 invoked from network); 9 Jan 2012 17:06:21 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 17:06:21 -0000
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q09H6DRP011842
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 17:06:14 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q09H697v027175
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 17:06:10 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
	q09H685B006778; Mon, 9 Jan 2012 11:06:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 09:06:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 634A040944; Mon,  9 Jan 2012 12:04:18 -0500 (EST)
Date: Mon, 9 Jan 2012 12:04:18 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120109170418.GD28700@phenom.dumpdata.com>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
	<20120109145648.GA25563@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
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.4F0B1E86.00F1,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 09, 2012 at 04:12:10PM +0000, Stefano Stabellini wrote:
> On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> > > I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
> > > X86_IO_APIC && ACPI && PCI" to XEN either.
> > > However it should be possible to add only the right dependencies to the
> > > right places.
> > > In practice it should be sufficient to:
> > > 
> > > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> > 
> > Not good. You can make non-ACPI builds with PCI.
> > 
> > .. and you are missing CONFIG_PCI in there.
> > > 
> > > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;
> > 
> > OK. That sounds good.
> > > 
> > > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> > 
> > No.. same issue - non-ACPI builds can be with PCI.
> > > 
> 
> Right.. in that case we should carefully replace the 'ifdef
> CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.

.. which I think I did at some point as part of cleanup and then
removed them since it peppered the xen.c with tons of #ifdef CONFIG_ACPI.

What about PVonHVM. There is this nagging feeling in the back of my
head that turning CONFIG_XEN_DOM0 disables the CONFIG_PVHVM option?
Or something like that? Maybe it is the other way around?

It would seem we need to seperate the PVHVM  from DOM0. But the extra
complexity comes with Mukesh's PVonHVM Hybrid which can do dom0 stuff
with PVonHVM (should be searchable on xen-devel to find the patches).

Ian also mentioned that we MUST have the XEN_PRIVILIGED option, otherwise
we will cause a regression with the GRUB tools. So that must stay or we need
provide a deprecation schedule for the next 3 years to remove it and
have patches in the GRUB toolchains.

Either way, there is also the question of making sure that no regressions
are introduced - so a lot of the CONFIG_* interdependencies will have
to be checked. I think that means checking CONFIG_XEN, CONFIG_PRIVILIGED,
CONFIG_PVHVM, CONFIG_PCI, CONFIG_ACPI, CONFIG_XEN_BACKEND in various combinations.

Oh, I forgot CONFIG_XEN_FRONTEND.. And I think that one can also become
a module (ditto for XEN_BACKEND)

And everytime we did something to those we managed to mess them up so
we should be dilligient.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:27:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ02-00040j-0z; Mon, 09 Jan 2012 17:27:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkJ00-00040e-5u
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:27:08 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326130020!8388125!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzEwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15113 invoked from network); 9 Jan 2012 17:27:01 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-8.tower-174.messagelabs.com with SMTP;
	9 Jan 2012 17:27:01 -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 q09HQrMB031183;
	Mon, 9 Jan 2012 12:26:54 -0500
Date: Mon, 09 Jan 2012 12:26:53 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <05d06123-6ec3-4074-96a8-6a0223cd71e2@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> > > I don't think we should add "PCI_XEN && SWIOTLB_XEN &&
> > > X86_LOCAL_APIC &&
> > > X86_IO_APIC && ACPI && PCI" to XEN either.
> > > However it should be possible to add only the right dependencies
> > > to the
> > > right places.
> > > In practice it should be sufficient to:
> > > 
> > > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> > 
> > Not good. You can make non-ACPI builds with PCI.
> > 
> > .. and you are missing CONFIG_PCI in there.
> > > 
> > > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on
> > > PCI_XEN;
> > 
> > OK. That sounds good.
> > > 
> > > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> > 
> > No.. same issue - non-ACPI builds can be with PCI.
> > > 
> 
> Right.. in that case we should carefully replace the 'ifdef
> CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.
> It would effectively keep things as they are now: if ACPI and XEN are
> enabled together in the config file, your kernel is able to setup
> interrupts when running as DOM0.
> Regarding X86_LOCAL_APIC and X86_IO_APIC I cannot recall anymore
> where
> these dependencies come from exactly.
> 

Here's one path

pci_xen_initial_domain [arch/x86/pci/xen.c] (#ifdef XEN_DOM0)
   xen_setup_acpi_sci [arch/x86/pci/xen.c]  (#ifdef XEN_DOM0)
       acpi_get_override_irq [arch/x86/kernel/apic/io_apic.c]
       (#ifdef X86_IO_APIC)

The messiness I stated before comes in when we try to find all these
paths and make sure they're appropriately #ifdef'ed with the minimal
set of symbols from the set that XEN_DOM0 used to cover for us.
However, without alternative implementations in the absence of
particular config options, then we still need to stub the functions out
at the top level. So we could simply s/r XEN_DOM0 with X86_LOCAL_APIC
&& X86_IO_APIC && ACPI in arch/x86/pci/xen.c, but that doesn't make
much sense either, because XEN_DOM0 does a nice job keeping things neat
and well documented, i.e. we can quickly tell what functions are
dom0-only.

> 
> > > > The driver domain concept may actually be the technical need
> > > > for
> > > > making XEN_DOM0 optional. If we want the ability to build a
> > > > minimally
> > > > configed XEN kernel to be used as a driver domain, then it
> > > > doesn't
> > > > seem like we'd want it to also be capable of running as an
> > > > initial
> > > > domain, or to be forced to have all the dependencies and code
> > > > of an
> > > > initial domain.
> > > 
> > > In practice any decent driver domain needs PCI and ACPI support,
> > > so
> > > basically it has the same config requirement of XEN_DOM0. At that
> > > point
> > 
> > Sure.. for backends. But for frontends that requirement is not
> > always true.
> 
> Right but a driver domain is bound to have at least the pci backend.
> 
> 
> > > we have already discussed that having XEN_DOM0 enabled or
> > > disabled
> > > hardly makes any differences, so we can just get rid of it.
> > 
> > Or in other words, substitute it as CONFIG_PCI_XEN.
> 
> I was just trying to assign the dependencies where they really belong
> and I proposed to remove the 'ifdef CONFIG_ACPI' because I didn't
> realize that one can build working PCI configurations on XEN without
> it.
> 
> The fact that PCI_XEN would be used then almost as XEN_DOM0 is used
> now
> is just a side effect, due to the fact that PCI and device interrupts
> initialization is what mainly differentiates dom0 from other
> configurations.
> 
> 
> > But this brings a question about MCE, ACPI cpu freq and ACPI S3.
> > Those all belong to the dom0 - not to any driver domain. So getting
> > rid
> > of CONFIG_XEN_DOM0 would present a problem - what would those
> > depend on?
> 
> They would depend on XEN and whatever else they really depend on, for
> example ACPI.

This brings up my comment before about me not being the best person
to suggest removing XEN_DOM0. It appears this symbol is fairly useful
even now for the reasons I mentioned above, and future work may once
again find it the cleanest way to manage dependencies. Possibly
dependencies will even expand to a point where it sufficiently
diverges from the requirements of driver domains. Then users may like
to be able to configure it out. I don't know.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:27:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ02-00040j-0z; Mon, 09 Jan 2012 17:27:10 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkJ00-00040e-5u
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:27:08 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326130020!8388125!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzEwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15113 invoked from network); 9 Jan 2012 17:27:01 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-8.tower-174.messagelabs.com with SMTP;
	9 Jan 2012 17:27:01 -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 q09HQrMB031183;
	Mon, 9 Jan 2012 12:26:54 -0500
Date: Mon, 09 Jan 2012 12:26:53 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <05d06123-6ec3-4074-96a8-6a0223cd71e2@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> > > I don't think we should add "PCI_XEN && SWIOTLB_XEN &&
> > > X86_LOCAL_APIC &&
> > > X86_IO_APIC && ACPI && PCI" to XEN either.
> > > However it should be possible to add only the right dependencies
> > > to the
> > > right places.
> > > In practice it should be sufficient to:
> > > 
> > > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> > 
> > Not good. You can make non-ACPI builds with PCI.
> > 
> > .. and you are missing CONFIG_PCI in there.
> > > 
> > > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on
> > > PCI_XEN;
> > 
> > OK. That sounds good.
> > > 
> > > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> > 
> > No.. same issue - non-ACPI builds can be with PCI.
> > > 
> 
> Right.. in that case we should carefully replace the 'ifdef
> CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.
> It would effectively keep things as they are now: if ACPI and XEN are
> enabled together in the config file, your kernel is able to setup
> interrupts when running as DOM0.
> Regarding X86_LOCAL_APIC and X86_IO_APIC I cannot recall anymore
> where
> these dependencies come from exactly.
> 

Here's one path

pci_xen_initial_domain [arch/x86/pci/xen.c] (#ifdef XEN_DOM0)
   xen_setup_acpi_sci [arch/x86/pci/xen.c]  (#ifdef XEN_DOM0)
       acpi_get_override_irq [arch/x86/kernel/apic/io_apic.c]
       (#ifdef X86_IO_APIC)

The messiness I stated before comes in when we try to find all these
paths and make sure they're appropriately #ifdef'ed with the minimal
set of symbols from the set that XEN_DOM0 used to cover for us.
However, without alternative implementations in the absence of
particular config options, then we still need to stub the functions out
at the top level. So we could simply s/r XEN_DOM0 with X86_LOCAL_APIC
&& X86_IO_APIC && ACPI in arch/x86/pci/xen.c, but that doesn't make
much sense either, because XEN_DOM0 does a nice job keeping things neat
and well documented, i.e. we can quickly tell what functions are
dom0-only.

> 
> > > > The driver domain concept may actually be the technical need
> > > > for
> > > > making XEN_DOM0 optional. If we want the ability to build a
> > > > minimally
> > > > configed XEN kernel to be used as a driver domain, then it
> > > > doesn't
> > > > seem like we'd want it to also be capable of running as an
> > > > initial
> > > > domain, or to be forced to have all the dependencies and code
> > > > of an
> > > > initial domain.
> > > 
> > > In practice any decent driver domain needs PCI and ACPI support,
> > > so
> > > basically it has the same config requirement of XEN_DOM0. At that
> > > point
> > 
> > Sure.. for backends. But for frontends that requirement is not
> > always true.
> 
> Right but a driver domain is bound to have at least the pci backend.
> 
> 
> > > we have already discussed that having XEN_DOM0 enabled or
> > > disabled
> > > hardly makes any differences, so we can just get rid of it.
> > 
> > Or in other words, substitute it as CONFIG_PCI_XEN.
> 
> I was just trying to assign the dependencies where they really belong
> and I proposed to remove the 'ifdef CONFIG_ACPI' because I didn't
> realize that one can build working PCI configurations on XEN without
> it.
> 
> The fact that PCI_XEN would be used then almost as XEN_DOM0 is used
> now
> is just a side effect, due to the fact that PCI and device interrupts
> initialization is what mainly differentiates dom0 from other
> configurations.
> 
> 
> > But this brings a question about MCE, ACPI cpu freq and ACPI S3.
> > Those all belong to the dom0 - not to any driver domain. So getting
> > rid
> > of CONFIG_XEN_DOM0 would present a problem - what would those
> > depend on?
> 
> They would depend on XEN and whatever else they really depend on, for
> example ACPI.

This brings up my comment before about me not being the best person
to suggest removing XEN_DOM0. It appears this symbol is fairly useful
even now for the reasons I mentioned above, and future work may once
again find it the cleanest way to manage dependencies. Possibly
dependencies will even expand to a point where it sufficiently
diverges from the requirements of driver domains. Then users may like
to be able to configure it out. I don't know.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:35:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17: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 1RkJ7Y-0004Cu-Nr; Mon, 09 Jan 2012 17:34:56 +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 1RkJ7W-0004Bb-GR
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18621 invoked from network); 9 Jan 2012 17:34:48 -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 Jan 2012 17:34:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 17:34: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
	1RkJ7Q-0001xt-1o; Mon, 09 Jan 2012 17:34:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7Q-0004it-0w;
	Mon, 09 Jan 2012 17:34:48 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:37 +0000
Message-ID: <1326130477-18085-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Convert to asynchronous: device
	removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Convert libxl_FOO_device_remove, and the function which does the bulk
of the work, libxl__device_remove, to the new async ops scheme.

Adjust all callers.

Also remove libxl__wait_for_device_state which is now obsolete.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   60 +++++++++++++--------
 tools/libxl/libxl.h          |   16 ++++--
 tools/libxl/libxl_device.c   |  119 +++++++++++++-----------------------------
 tools/libxl/libxl_internal.h |   31 ++---------
 tools/libxl/xl_cmdimpl.c     |    4 +-
 5 files changed, 95 insertions(+), 135 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b8167b3..ce9aef2 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1308,19 +1308,23 @@ out:
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
-                             libxl_device_disk *disk)
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -1534,11 +1538,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 
     ret = 0;
 
-    libxl_device_disk_remove(ctx, domid, disks + i);
+    libxl_device_disk_remove(ctx, domid, disks + i, 0);
     libxl_device_disk_add(ctx, domid, disk);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
-        libxl_device_disk_remove(ctx, stubdomid, disks + i);
+        libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
         libxl_device_disk_add(ctx, stubdomid, disk);
     }
 out:
@@ -1751,19 +1755,23 @@ out:
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_nic *nic)
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2091,19 +2099,23 @@ out:
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vkb *vkb)
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2208,19 +2220,23 @@ out:
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vfb *vfb)
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e8fed73..207288e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -464,7 +464,9 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
 /* Disks */
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
-int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -488,7 +490,9 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 /* Network Interfaces */
 int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
-int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -498,13 +502,17 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 /* Keyboard */
 int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
-int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
-int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5d05e90..fd27ce5 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -357,85 +357,42 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
-/*
- * Returns 0 if a device is removed, ERROR_* if an error
- * or timeout occurred.
- */
-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;
-    unsigned int n;
-    fd_set rfds;
-    char **l1 = NULL;
-
-start:
-    rc = 1;
-    nfds = xs_fileno(ctx->xsh) + 1;
-    FD_ZERO(&rfds);
-    FD_SET(xs_fileno(ctx->xsh), &rfds);
-    switch (select(nfds, &rfds, NULL, NULL, tv)) {
-        case -1:
-            if (errno == EINTR)
-                goto start;
-            rc = ERROR_FAIL;
-            break;
-        case 0:
-            rc = ERROR_TIMEDOUT;
-            break;
-        default:
-            l1 = xs_read_watch(ctx->xsh, &n);
-            if (l1 != NULL) {
-                char *sstate = libxl__xs_read(gc, XBT_NULL,
-                                             l1[XS_WATCH_PATH]);
-                if (!sstate || atoi(sstate) == state) {
-                    /* Call handler function if present */
-                    if (handler)
-                        rc = handler(gc, l1, sstate);
-                } else {
-                    /* State is different than expected, continue waiting... */
-                    goto start;
-                }
-                free(l1);
-            } else {
-                rc = ERROR_FAIL;
-            }
-            break;
-    }
-    return rc;
-}
 
-/*
- * 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]);
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+} libxl__ao_device_remove;
+
+static void device_remove_cleanup(libxl__gc *gc,
+                                  libxl__ao_device_remove *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+    free(aorm);
+}
 
-    return 0;
+static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                   int rc) {
+    libxl__ao_device_remove *aorm;
+    GET_CONTAINING_STRUCT(aorm, ds, ds);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    device_remove_cleanup(&egc->gc, aorm);
 }
 
-/*
- * Returns 0 (device already destroyed) or 1 (caller must
- * wait_for_dev_destroy) on success, ERROR_* on fail.
- */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
 {
+    /* Arranges that dev will be removed from its guest.  When
+     * this is done, the ao will be completed.  An error
+     * return from libxl__device_remove means that the ao
+     * will _not_ be completed and the caller must do so.
+     */
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state = libxl__xs_read(gc, XBT_NULL, state_path);
     int rc = 0;
+    libxl__ao_device_remove *aorm = 0;
 
     if (!state)
         goto out;
@@ -458,23 +415,21 @@ retry_transaction:
         }
     }
 
-    xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    libxl__ev_devstate_init(&aorm->ds);
 
-out:
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
+                                 state_path, XenbusStateClosed,
+                                 LIBXL_DESTROY_TIMEOUT * 1000);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    device_remove_cleanup(gc, aorm);
     return rc;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6c87290..94ab681 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -652,35 +652,16 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
-/* 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);
+_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+    /* Arranges that dev will be removed from its guest.  When
+     * this is done, the ao will be completed.  An error
+     * return from libxl__device_remove means that the ao
+     * will _not_ be completed and the caller must do so.
+     */
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index b88fc8a..dda74b9 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4616,7 +4616,7 @@ int main_networkdetach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_remove(ctx, domid, &nic)) {
+    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_del failed.\n");
         return 1;
     }
@@ -4711,7 +4711,7 @@ int main_blockdetach(int argc, char **argv)
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
     }
-    if (libxl_device_disk_remove(ctx, domid, &disk)) {
+    if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     }
     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 Mon Jan 09 17:35:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17: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 1RkJ7Y-0004Cu-Nr; Mon, 09 Jan 2012 17:34:56 +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 1RkJ7W-0004Bb-GR
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18621 invoked from network); 9 Jan 2012 17:34:48 -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 Jan 2012 17:34:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 17:34: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
	1RkJ7Q-0001xt-1o; Mon, 09 Jan 2012 17:34:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7Q-0004it-0w;
	Mon, 09 Jan 2012 17:34:48 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:37 +0000
Message-ID: <1326130477-18085-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Convert to asynchronous: device
	removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Convert libxl_FOO_device_remove, and the function which does the bulk
of the work, libxl__device_remove, to the new async ops scheme.

Adjust all callers.

Also remove libxl__wait_for_device_state which is now obsolete.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   60 +++++++++++++--------
 tools/libxl/libxl.h          |   16 ++++--
 tools/libxl/libxl_device.c   |  119 +++++++++++++-----------------------------
 tools/libxl/libxl_internal.h |   31 ++---------
 tools/libxl/xl_cmdimpl.c     |    4 +-
 5 files changed, 95 insertions(+), 135 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index b8167b3..ce9aef2 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1308,19 +1308,23 @@ out:
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
-                             libxl_device_disk *disk)
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -1534,11 +1538,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 
     ret = 0;
 
-    libxl_device_disk_remove(ctx, domid, disks + i);
+    libxl_device_disk_remove(ctx, domid, disks + i, 0);
     libxl_device_disk_add(ctx, domid, disk);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
-        libxl_device_disk_remove(ctx, stubdomid, disks + i);
+        libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
         libxl_device_disk_add(ctx, stubdomid, disk);
     }
 out:
@@ -1751,19 +1755,23 @@ out:
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_nic *nic)
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2091,19 +2099,23 @@ out:
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vkb *vkb)
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2208,19 +2220,23 @@ out:
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vfb *vfb)
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e8fed73..207288e 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -464,7 +464,9 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
 /* Disks */
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
-int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -488,7 +490,9 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 /* Network Interfaces */
 int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
-int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -498,13 +502,17 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 /* Keyboard */
 int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
-int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
-int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5d05e90..fd27ce5 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -357,85 +357,42 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
-/*
- * Returns 0 if a device is removed, ERROR_* if an error
- * or timeout occurred.
- */
-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;
-    unsigned int n;
-    fd_set rfds;
-    char **l1 = NULL;
-
-start:
-    rc = 1;
-    nfds = xs_fileno(ctx->xsh) + 1;
-    FD_ZERO(&rfds);
-    FD_SET(xs_fileno(ctx->xsh), &rfds);
-    switch (select(nfds, &rfds, NULL, NULL, tv)) {
-        case -1:
-            if (errno == EINTR)
-                goto start;
-            rc = ERROR_FAIL;
-            break;
-        case 0:
-            rc = ERROR_TIMEDOUT;
-            break;
-        default:
-            l1 = xs_read_watch(ctx->xsh, &n);
-            if (l1 != NULL) {
-                char *sstate = libxl__xs_read(gc, XBT_NULL,
-                                             l1[XS_WATCH_PATH]);
-                if (!sstate || atoi(sstate) == state) {
-                    /* Call handler function if present */
-                    if (handler)
-                        rc = handler(gc, l1, sstate);
-                } else {
-                    /* State is different than expected, continue waiting... */
-                    goto start;
-                }
-                free(l1);
-            } else {
-                rc = ERROR_FAIL;
-            }
-            break;
-    }
-    return rc;
-}
 
-/*
- * 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]);
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+} libxl__ao_device_remove;
+
+static void device_remove_cleanup(libxl__gc *gc,
+                                  libxl__ao_device_remove *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+    free(aorm);
+}
 
-    return 0;
+static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                   int rc) {
+    libxl__ao_device_remove *aorm;
+    GET_CONTAINING_STRUCT(aorm, ds, ds);
+    libxl__ao_complete(egc, aorm->ao, rc);
+    device_remove_cleanup(&egc->gc, aorm);
 }
 
-/*
- * Returns 0 (device already destroyed) or 1 (caller must
- * wait_for_dev_destroy) on success, ERROR_* on fail.
- */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
 {
+    /* Arranges that dev will be removed from its guest.  When
+     * this is done, the ao will be completed.  An error
+     * return from libxl__device_remove means that the ao
+     * will _not_ be completed and the caller must do so.
+     */
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state = libxl__xs_read(gc, XBT_NULL, state_path);
     int rc = 0;
+    libxl__ao_device_remove *aorm = 0;
 
     if (!state)
         goto out;
@@ -458,23 +415,21 @@ retry_transaction:
         }
     }
 
-    xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    libxl__ev_devstate_init(&aorm->ds);
 
-out:
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
+                                 state_path, XenbusStateClosed,
+                                 LIBXL_DESTROY_TIMEOUT * 1000);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    device_remove_cleanup(gc, aorm);
     return rc;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 6c87290..94ab681 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -652,35 +652,16 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
-/* 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);
+_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
+    /* Arranges that dev will be removed from its guest.  When
+     * this is done, the ao will be completed.  An error
+     * return from libxl__device_remove means that the ao
+     * will _not_ be completed and the caller must do so.
+     */
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index b88fc8a..dda74b9 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4616,7 +4616,7 @@ int main_networkdetach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_remove(ctx, domid, &nic)) {
+    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_del failed.\n");
         return 1;
     }
@@ -4711,7 +4711,7 @@ int main_blockdetach(int argc, char **argv)
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
     }
-    if (libxl_device_disk_remove(ctx, domid, &disk)) {
+    if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     }
     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 Mon Jan 09 17:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ7W-0004C4-B5; Mon, 09 Jan 2012 17:34: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 1RkJ7U-0004BX-Vl
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18547 invoked from network); 9 Jan 2012 17:34:46 -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 Jan 2012 17:34:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 17:34: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
	1RkJ7O-0001xi-6W; Mon, 09 Jan 2012 17:34:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7O-0004ih-54;
	Mon, 09 Jan 2012 17:34:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:34 +0000
Message-ID: <1326130477-18085-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Asynchronous/long-running
	operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide a new set of machinery for writing public libxl functions
which may take a long time.  The application gets to decide whether
they want the function to be synchronous, or whether they'd prefer to
get a callback, or an event, when the operation is complete.

User(s) of this machinery will be introduced in later patch(es).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   50 ++++++++++++
 tools/libxl/libxl_event.c    |  183 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |  105 ++++++++++++++++++++++++
 tools/libxl/libxl_types.idl  |    4 +
 4 files changed, 342 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 5396ba8..e8fed73 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -235,8 +235,58 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_ASYNC_INPROGRESS = -14,
 };
 
+
+/*
+ * Some libxl operations can take a long time.  These functions take a
+ * parameter to control their concurrency:
+ *     libxl_asyncop_how *ao_how
+ *
+ * If ao_how==NULL, the function will be synchronous.
+ *
+ * If ao_how!=NULL, the function will set the operation going, and
+ * if this is successful will return ERROR_ASYNCH_INPROGRESS.
+ *
+ * If ao_how->callback!=NULL, the callback will be called when the
+ * operation completes.  The same rules as for libxl_event_hooks
+ * apply, including the reentrancy rules and the possibility of
+ * "disaster", except that libxl calls ao_how->callback instead of
+ * libxl_event_hooks.event_occurs.
+ *
+ * If ao_how->callback==NULL, a libxl_event will be generated which
+ * can be obtained from libxl_event_wait or libxl_event_check.  The
+ * event will have type OPERATION_COMPLETE (which is not used
+ * elsewhere).
+ *
+ * Note that it is possible for an asynchronous operation which is to
+ * result in a callback to complete during its initiating function
+ * call.  In this case the initating function will return
+ * ERROR_ASYNCH_INPROGRESS, even though by the time it returns the
+ * operation is complete and the callback has already happened.
+ *
+ * The application must set and use ao_how->for_event (which will be
+ * copied into libxl_event.for_user) or ao_how->for_callback (passed
+ * to the callback) to determine which operation finished, and it must
+ * of course check the rc value for errors.
+ *
+ * *ao_how does not need to remain valid after the initiating function
+ * returns.
+ *
+ * Callbacks may occur on any thread in which the application calls
+ * libxl.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
+    union {
+        libxl_ev_user for_event; /* used if callback==NULL */
+        void *for_callback; /* passed to callback */
+    } u;
+} libxl_asyncop_how;
+
+
 #define LIBXL_VERSION 0
 
 typedef struct {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 84aa489..c594494 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -770,10 +770,21 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     libxl__gc *gc = &egc->gc;
     libxl_event *ev, *ev_tmp;
+
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
+
+    libxl__ao *ao, *ao_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
+                             entry_for_callback, ao_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
+        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        ao->notified = 1;
+        if (!ao->in_initiator)
+            libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
+    }
 }
 
 void libxl__egc_cleanup(libxl__egc *egc)
@@ -1060,6 +1071,178 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
+
+
+/*
+ * The two possible state flow of an ao:
+ *
+ * Completion before initiator return:
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_complete:               |
+ *     - if synchronous, run event loop           |
+ *       until the ao completes                   |
+ *                              - ao completes on some thread
+ *                              - completing thread releases the lock
+ *                     <--------------'
+ *     - ao_complete takes the lock
+ *     - destroy the ao
+ *
+ *
+ * Completion after initiator return (asynch. only):
+ *
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_complete:               |
+ *     - observes event not net done,             |
+ *     - returns to caller                        |
+ *                                                |
+ *                              - ao completes on some thread
+ *                              - generate the event or call the callback
+ *                              - destroy the ao
+ */
+
+void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao) {
+    if (!ao) return;
+    if (ao->poller) libxl__poller_put(ctx, ao->poller);
+    ao->magic = LIBXL__AO_MAGIC_DESTROYED;
+    libxl__gc_cleanup(&ao->gc);
+    free(ao);
+}
+
+void libxl__ao_abort(libxl__ao *ao) {
+    AO_GC;
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+    assert(!ao->complete);
+    libxl__ao__destroy(CTX, ao);
+}
+
+void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(!ao->complete);
+    ao->complete = 1;
+    ao->rc = rc;
+
+    if (ao->poller) {
+        assert(ao->in_initiator);
+        libxl__poller_wakeup(egc, ao->poller);
+    } else if (ao->how.callback) {
+        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
+    } else {
+        libxl_event *ev;
+        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
+        if (ev) {
+            ev->for_user = ao->how.u.for_event;
+            ev->u.operation_complete.rc = ao->rc;
+            libxl__event_occurred(egc, ev);
+        }
+        ao->notified = 1;
+    }
+    if (!ao->in_initiator && ao->notified)
+        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
+}
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how) {
+    libxl__ao *ao;
+
+    ao = calloc(sizeof(*ao),1);
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+int libxl__ao_inprogress(libxl__ao *ao) {
+    AO_GC;
+    int rc;
+
+    /* We use a fresh gc, so that we can free things
+     * each time round the loop. */
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+
+    if (ao->poller) {
+        /* Caller wants it done synchronously. */
+        libxl__egc egc;
+        LIBXL_INIT_EGC(egc,CTX);
+
+        for (;;) {
+            assert(ao->magic == LIBXL__AO_MAGIC);
+
+            if (ao->complete) {
+                rc = ao->rc;
+                ao->notified = 1;
+                break;
+            }
+
+            rc = eventloop_iteration(&egc,ao->poller);
+            if (rc) {
+                /* Oh dear, this is quite unfortunate. */
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
+                           " event during long-running operation (rc=%d)", rc);
+                sleep(1);
+                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
+                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
+                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
+                 * cancellation ability. */
+            }
+
+            CTX_UNLOCK;
+            libxl__egc_cleanup(&egc);
+            CTX_LOCK;
+        }
+    } else {
+        rc = ERROR_ASYNC_INPROGRESS;
+    }
+
+    ao->in_initiator = 0;
+
+    if (ao->notified) {
+        assert(ao->complete);
+        libxl__ao__destroy(CTX,ao);
+    }
+
+    return rc;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1fc3487..e0ff15c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -112,6 +112,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
+typedef struct libxl__ao libxl__ao;
 
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
@@ -216,6 +217,10 @@ struct libxl__poller {
      * releasing the ctx lock and going into poll; when it comes out
      * of poll it will take the poller off the pollers_event list.
      *
+     * A thread which is waiting for completion of a synchronous ao
+     * will allocate a poller and record it in the ao, so that other
+     * threads can wake it up.
+     *
      * When a thread is done with a poller it should put it onto
      * pollers_idle, where it can be reused later.
      *
@@ -322,6 +327,21 @@ struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+};
+
+#define LIBXL__AO_MAGIC              0xA0FACE00ul
+#define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
+
+struct libxl__ao {
+    uint32_t magic;
+    unsigned in_initiator:1, complete:1, notified:1;
+    int rc;
+    libxl__gc gc;
+    libxl_asyncop_how how;
+    libxl__poller *poller;
+    uint32_t domid;
+    LIBXL_TAILQ_ENTRY(libxl__ao) entry_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -1116,6 +1136,91 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 
 
 /*
+ * Machinery for asynchronous operations ("ao")
+ *
+ * All "slow" functions (includes anything that might block on a
+ * guest or an external script) need to use the asynchronous
+ * operation ("ao") machinery.  The function should take a parameter
+ * const libxl_asyncop_how *ao_how and must start with a call to
+ * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
+ * outside libxl, because they can cause reentrancy callbacks.
+ *
+ * No functions called internally within libxl should ever return
+ * ERROR_ASYNCH_INPROGRESS.
+ *
+ * Lifecycle of an ao:
+ *
+ * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
+ *
+ * - After creation, can be used by code which implements
+ *   the operation as follows:
+ *      - the ao's gc, for allocating memory for the lifetime
+ *        of the operation (possibly with the help of the AO_GC
+ *        macro to introduce the gc into scope)
+ *      - the ao itself may be passed about to sub-functions
+ *        so that they can stash it away etc.
+ *      - in particular, the ao pointer must be stashed in some
+ *        per-operation structure which is also passed as a user
+ *        pointer to the internal event generation request routines
+ *        libxl__evgen_FOO, so that at some point a CALLBACK will be
+ *        made when the operation is complete.
+ *
+ * - If initiation is successful, the initiating function needs
+ *   to run libxl__ao_inprogress right before unlocking and
+ *   returning, and return whatever it returns (AO_INPROGRESS macro).
+ *
+ * - If the initiation is unsuccessful, the initiating function must
+ *   call libxl__ao_abort before unlocking and returning whatever
+ *   error code is appropriate (AO_ABORT macro).
+ *
+ * - Later, some callback function, whose callback has been requested
+ *   directly or indirectly, should call libxl__ao_complete (with the
+ *   ctx locked, as it will generally already be in any event callback
+ *   function).  This must happen exactly once for each ao (and not if
+ *   the ao has been destroyed, obviously), and it may not happen
+ *   until libxl__ao_inprogress has been called on the ao.
+ *
+ * - NOTE RE MULTIPLE GCS
+ */
+
+#define AO_CREATE(ctx, domid, ao_how)                           \
+    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
+    if (!ao) return ERROR_NOMEM;                                \
+    AO_GC;                                                      \
+    CTX_LOCK;
+
+#define AO_INPROGRESS do{                                       \
+        int ao_inprogress_rc = libxl__ao_inprogress(ao);        \
+        CTX_UNLOCK;                                             \
+        return ao_inprogress_rc;                                \
+   }while(0)
+        
+
+#define AO_ABORT(rc) do{                        \
+        assert(rc);                             \
+        assert(rc != ERROR_ASYNC_INPROGRESS);   \
+        libxl__ao_abort(ao);                    \
+        CTX_UNLOCK;                             \
+        return (rc);                            \
+    }while(0)
+
+#define AO_GC                                   \
+    libxl__gc *const gc = &ao->gc
+
+
+_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
+                                    const libxl_asyncop_how*);
+_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden void libxl__ao_abort(libxl__ao *ao);
+_hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
+  /* All of these MUST be called with the ctx locked.
+   * libxl__ao_wait MUST be called with the ctx locked exactly once.
+   */
+
+_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+  /* for use by ao machinery ONLY */
+
+/*
  * Convenience macros.
  */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6728479..eff4d43 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -394,6 +394,7 @@ libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DESTROY"),
     (3, "DISK_EJECT"),
+    (4, "OPERATION_COMPLETE"),
     ])
 
 libxl_ev_user = Number("libxl_ev_user")
@@ -417,4 +418,7 @@ libxl_event = Struct("event",[
                                         ("vdev", string),
                                         ("disk", libxl_device_disk),
                                  ])),
+           ("operation_complete", Struct(None, [
+                                        ("rc", integer),
+                                 ])),
            ]))])
-- 
1.7.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 Jan 09 17:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ7W-0004C4-B5; Mon, 09 Jan 2012 17:34: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 1RkJ7U-0004BX-Vl
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18547 invoked from network); 9 Jan 2012 17:34:46 -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 Jan 2012 17:34:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 17:34: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
	1RkJ7O-0001xi-6W; Mon, 09 Jan 2012 17:34:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7O-0004ih-54;
	Mon, 09 Jan 2012 17:34:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:34 +0000
Message-ID: <1326130477-18085-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Asynchronous/long-running
	operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide a new set of machinery for writing public libxl functions
which may take a long time.  The application gets to decide whether
they want the function to be synchronous, or whether they'd prefer to
get a callback, or an event, when the operation is complete.

User(s) of this machinery will be introduced in later patch(es).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   50 ++++++++++++
 tools/libxl/libxl_event.c    |  183 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |  105 ++++++++++++++++++++++++
 tools/libxl/libxl_types.idl  |    4 +
 4 files changed, 342 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 5396ba8..e8fed73 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -235,8 +235,58 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_ASYNC_INPROGRESS = -14,
 };
 
+
+/*
+ * Some libxl operations can take a long time.  These functions take a
+ * parameter to control their concurrency:
+ *     libxl_asyncop_how *ao_how
+ *
+ * If ao_how==NULL, the function will be synchronous.
+ *
+ * If ao_how!=NULL, the function will set the operation going, and
+ * if this is successful will return ERROR_ASYNCH_INPROGRESS.
+ *
+ * If ao_how->callback!=NULL, the callback will be called when the
+ * operation completes.  The same rules as for libxl_event_hooks
+ * apply, including the reentrancy rules and the possibility of
+ * "disaster", except that libxl calls ao_how->callback instead of
+ * libxl_event_hooks.event_occurs.
+ *
+ * If ao_how->callback==NULL, a libxl_event will be generated which
+ * can be obtained from libxl_event_wait or libxl_event_check.  The
+ * event will have type OPERATION_COMPLETE (which is not used
+ * elsewhere).
+ *
+ * Note that it is possible for an asynchronous operation which is to
+ * result in a callback to complete during its initiating function
+ * call.  In this case the initating function will return
+ * ERROR_ASYNCH_INPROGRESS, even though by the time it returns the
+ * operation is complete and the callback has already happened.
+ *
+ * The application must set and use ao_how->for_event (which will be
+ * copied into libxl_event.for_user) or ao_how->for_callback (passed
+ * to the callback) to determine which operation finished, and it must
+ * of course check the rc value for errors.
+ *
+ * *ao_how does not need to remain valid after the initiating function
+ * returns.
+ *
+ * Callbacks may occur on any thread in which the application calls
+ * libxl.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
+    union {
+        libxl_ev_user for_event; /* used if callback==NULL */
+        void *for_callback; /* passed to callback */
+    } u;
+} libxl_asyncop_how;
+
+
 #define LIBXL_VERSION 0
 
 typedef struct {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 84aa489..c594494 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -770,10 +770,21 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     libxl__gc *gc = &egc->gc;
     libxl_event *ev, *ev_tmp;
+
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
+
+    libxl__ao *ao, *ao_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
+                             entry_for_callback, ao_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
+        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        ao->notified = 1;
+        if (!ao->in_initiator)
+            libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
+    }
 }
 
 void libxl__egc_cleanup(libxl__egc *egc)
@@ -1060,6 +1071,178 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
+
+
+/*
+ * The two possible state flow of an ao:
+ *
+ * Completion before initiator return:
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_complete:               |
+ *     - if synchronous, run event loop           |
+ *       until the ao completes                   |
+ *                              - ao completes on some thread
+ *                              - completing thread releases the lock
+ *                     <--------------'
+ *     - ao_complete takes the lock
+ *     - destroy the ao
+ *
+ *
+ * Completion after initiator return (asynch. only):
+ *
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_complete:               |
+ *     - observes event not net done,             |
+ *     - returns to caller                        |
+ *                                                |
+ *                              - ao completes on some thread
+ *                              - generate the event or call the callback
+ *                              - destroy the ao
+ */
+
+void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao) {
+    if (!ao) return;
+    if (ao->poller) libxl__poller_put(ctx, ao->poller);
+    ao->magic = LIBXL__AO_MAGIC_DESTROYED;
+    libxl__gc_cleanup(&ao->gc);
+    free(ao);
+}
+
+void libxl__ao_abort(libxl__ao *ao) {
+    AO_GC;
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+    assert(!ao->complete);
+    libxl__ao__destroy(CTX, ao);
+}
+
+void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(!ao->complete);
+    ao->complete = 1;
+    ao->rc = rc;
+
+    if (ao->poller) {
+        assert(ao->in_initiator);
+        libxl__poller_wakeup(egc, ao->poller);
+    } else if (ao->how.callback) {
+        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
+    } else {
+        libxl_event *ev;
+        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
+        if (ev) {
+            ev->for_user = ao->how.u.for_event;
+            ev->u.operation_complete.rc = ao->rc;
+            libxl__event_occurred(egc, ev);
+        }
+        ao->notified = 1;
+    }
+    if (!ao->in_initiator && ao->notified)
+        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
+}
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how) {
+    libxl__ao *ao;
+
+    ao = calloc(sizeof(*ao),1);
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+int libxl__ao_inprogress(libxl__ao *ao) {
+    AO_GC;
+    int rc;
+
+    /* We use a fresh gc, so that we can free things
+     * each time round the loop. */
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+
+    if (ao->poller) {
+        /* Caller wants it done synchronously. */
+        libxl__egc egc;
+        LIBXL_INIT_EGC(egc,CTX);
+
+        for (;;) {
+            assert(ao->magic == LIBXL__AO_MAGIC);
+
+            if (ao->complete) {
+                rc = ao->rc;
+                ao->notified = 1;
+                break;
+            }
+
+            rc = eventloop_iteration(&egc,ao->poller);
+            if (rc) {
+                /* Oh dear, this is quite unfortunate. */
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
+                           " event during long-running operation (rc=%d)", rc);
+                sleep(1);
+                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
+                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
+                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
+                 * cancellation ability. */
+            }
+
+            CTX_UNLOCK;
+            libxl__egc_cleanup(&egc);
+            CTX_LOCK;
+        }
+    } else {
+        rc = ERROR_ASYNC_INPROGRESS;
+    }
+
+    ao->in_initiator = 0;
+
+    if (ao->notified) {
+        assert(ao->complete);
+        libxl__ao__destroy(CTX,ao);
+    }
+
+    return rc;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 1fc3487..e0ff15c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -112,6 +112,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
+typedef struct libxl__ao libxl__ao;
 
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
@@ -216,6 +217,10 @@ struct libxl__poller {
      * releasing the ctx lock and going into poll; when it comes out
      * of poll it will take the poller off the pollers_event list.
      *
+     * A thread which is waiting for completion of a synchronous ao
+     * will allocate a poller and record it in the ao, so that other
+     * threads can wake it up.
+     *
      * When a thread is done with a poller it should put it onto
      * pollers_idle, where it can be reused later.
      *
@@ -322,6 +327,21 @@ struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+};
+
+#define LIBXL__AO_MAGIC              0xA0FACE00ul
+#define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
+
+struct libxl__ao {
+    uint32_t magic;
+    unsigned in_initiator:1, complete:1, notified:1;
+    int rc;
+    libxl__gc gc;
+    libxl_asyncop_how how;
+    libxl__poller *poller;
+    uint32_t domid;
+    LIBXL_TAILQ_ENTRY(libxl__ao) entry_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -1116,6 +1136,91 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 
 
 /*
+ * Machinery for asynchronous operations ("ao")
+ *
+ * All "slow" functions (includes anything that might block on a
+ * guest or an external script) need to use the asynchronous
+ * operation ("ao") machinery.  The function should take a parameter
+ * const libxl_asyncop_how *ao_how and must start with a call to
+ * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
+ * outside libxl, because they can cause reentrancy callbacks.
+ *
+ * No functions called internally within libxl should ever return
+ * ERROR_ASYNCH_INPROGRESS.
+ *
+ * Lifecycle of an ao:
+ *
+ * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
+ *
+ * - After creation, can be used by code which implements
+ *   the operation as follows:
+ *      - the ao's gc, for allocating memory for the lifetime
+ *        of the operation (possibly with the help of the AO_GC
+ *        macro to introduce the gc into scope)
+ *      - the ao itself may be passed about to sub-functions
+ *        so that they can stash it away etc.
+ *      - in particular, the ao pointer must be stashed in some
+ *        per-operation structure which is also passed as a user
+ *        pointer to the internal event generation request routines
+ *        libxl__evgen_FOO, so that at some point a CALLBACK will be
+ *        made when the operation is complete.
+ *
+ * - If initiation is successful, the initiating function needs
+ *   to run libxl__ao_inprogress right before unlocking and
+ *   returning, and return whatever it returns (AO_INPROGRESS macro).
+ *
+ * - If the initiation is unsuccessful, the initiating function must
+ *   call libxl__ao_abort before unlocking and returning whatever
+ *   error code is appropriate (AO_ABORT macro).
+ *
+ * - Later, some callback function, whose callback has been requested
+ *   directly or indirectly, should call libxl__ao_complete (with the
+ *   ctx locked, as it will generally already be in any event callback
+ *   function).  This must happen exactly once for each ao (and not if
+ *   the ao has been destroyed, obviously), and it may not happen
+ *   until libxl__ao_inprogress has been called on the ao.
+ *
+ * - NOTE RE MULTIPLE GCS
+ */
+
+#define AO_CREATE(ctx, domid, ao_how)                           \
+    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
+    if (!ao) return ERROR_NOMEM;                                \
+    AO_GC;                                                      \
+    CTX_LOCK;
+
+#define AO_INPROGRESS do{                                       \
+        int ao_inprogress_rc = libxl__ao_inprogress(ao);        \
+        CTX_UNLOCK;                                             \
+        return ao_inprogress_rc;                                \
+   }while(0)
+        
+
+#define AO_ABORT(rc) do{                        \
+        assert(rc);                             \
+        assert(rc != ERROR_ASYNC_INPROGRESS);   \
+        libxl__ao_abort(ao);                    \
+        CTX_UNLOCK;                             \
+        return (rc);                            \
+    }while(0)
+
+#define AO_GC                                   \
+    libxl__gc *const gc = &ao->gc
+
+
+_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
+                                    const libxl_asyncop_how*);
+_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden void libxl__ao_abort(libxl__ao *ao);
+_hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
+  /* All of these MUST be called with the ctx locked.
+   * libxl__ao_wait MUST be called with the ctx locked exactly once.
+   */
+
+_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+  /* for use by ao machinery ONLY */
+
+/*
  * Convenience macros.
  */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 6728479..eff4d43 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -394,6 +394,7 @@ libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DESTROY"),
     (3, "DISK_EJECT"),
+    (4, "OPERATION_COMPLETE"),
     ])
 
 libxl_ev_user = Number("libxl_ev_user")
@@ -417,4 +418,7 @@ libxl_event = Struct("event",[
                                         ("vdev", string),
                                         ("disk", libxl_device_disk),
                                  ])),
+           ("operation_complete", Struct(None, [
+                                        ("rc", integer),
+                                 ])),
            ]))])
-- 
1.7.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 Jan 09 17:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ7Y-0004Ch-9L; Mon, 09 Jan 2012 17:34:56 +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 1RkJ7V-0004BZ-T0
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18601 invoked from network); 9 Jan 2012 17:34:48 -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 Jan 2012 17:34:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34: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, 9 Jan 2012 17:34: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
	1RkJ7P-0001xo-J4; Mon, 09 Jan 2012 17:34:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7P-0004ip-ID;
	Mon, 09 Jan 2012 17:34:47 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:36 +0000
Message-ID: <1326130477-18085-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a new-style asynchronous facility for waiting for device
states on xenbus.  This will replace libxl__wait_for_device_state,
after the callers have been updated in later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   74 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   41 +++++++++++++++++++++++
 2 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c594494..c26210b 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -506,6 +506,80 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
 }
 
 /*
+ * waiting for device state
+ */
+
+static void devstate_watch_callback(libxl__egc *egc, libxl__ev_xswatch *watch,
+                                const char *watch_path, const char *event_path)
+{
+    libxl__ev_devstate *ds;
+    libxl__gc *gc = &egc->gc;
+    GET_CONTAINING_STRUCT(ds, watch, watch);
+    int rc;
+
+    char *sstate = libxl__xs_read(&egc->gc, XBT_NULL, watch_path);
+    if (!sstate) {
+        if (errno == ENOENT) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " but it was removed", watch_path, ds->wanted);
+            rc = ERROR_INVAL;
+        } else {
+            LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "backend %s wanted state"
+                             " %d but read failed", watch_path, ds->wanted);
+            rc = ERROR_FAIL;
+        }
+    } else {
+        int got = atoi(sstate);
+        if (got == ds->wanted) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d ok",
+                       watch_path, ds->wanted);
+            rc = 0;
+        } else {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+                       " still waiting state %d", watch_path, ds->wanted, got);
+            return;
+        }
+    }
+    libxl__ev_devstate_cancel(&egc->gc, ds);
+    ds->callback(egc, ds, rc);
+}
+
+static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    libxl__ev_devstate *ds;
+    libxl__gc *gc = &egc->gc;
+    GET_CONTAINING_STRUCT(ds, ev, timeout);
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+               " timed out", ds->watch.path, ds->wanted);
+    libxl__ev_devstate_cancel(&egc->gc, ds);
+    ds->callback(egc, ds, ERROR_TIMEDOUT);
+}
+
+int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                            libxl__ev_devstate_callback cb,
+                            const char *state_path, int state, int milliseconds)
+{
+    int rc;
+
+    ds->wanted = state;
+
+    rc = libxl__ev_time_register_rel(gc, &ds->timeout, devstate_timeout,
+                                     milliseconds);
+    if (rc) goto out;
+
+    rc = libxl__ev_xswatch_register(gc, &ds->watch, devstate_watch_callback,
+                                    state_path);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__ev_devstate_cancel(gc, ds);
+    return rc;
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0c2ad6..6c87290 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -683,6 +683,47 @@ _hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
                                          libxl__device_state_handler handler);
 
 /*
+ * libxl__ev_devstate - waits a given time for a device to
+ * reach a given state.  Follows the libxl_ev_* conventions.
+ * Will generate only one event, and after that is automatically
+ * cancelled.
+ */
+typedef struct libxl__ev_devstate libxl__ev_devstate;
+typedef void libxl__ev_devstate_callback(libxl__egc *egc, libxl__ev_devstate*,
+                                         int rc);
+  /* rc will be 0, ERROR_TIMEDOUT, ERROR_INVAL (meaning path was removed),
+   * or ERROR_FAIL if other stuff went wrong (in which latter case, logged) */
+
+struct libxl__ev_devstate {
+    /* read-only for caller, who may read only when waiting: */
+    int wanted;
+    libxl__ev_devstate_callback *callback;
+    /* as for the remainder, read-only public parts may also be
+     * read by the caller (notably, watch.path), but only when waiting: */
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+};
+
+static inline void libxl__ev_devstate_init(libxl__ev_devstate *ds)
+{
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+}
+
+static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
+                                             libxl__ev_devstate *ds)
+{
+    libxl__ev_time_deregister(gc,&ds->timeout);
+    libxl__ev_xswatch_deregister(gc,&ds->watch);
+}
+
+_hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                                    libxl__ev_devstate_callback cb,
+                                    const char *state_path,
+                                    int state, int milliseconds);
+
+
+/*
  * 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
-- 
1.7.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 Jan 09 17:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ7Y-0004Ch-9L; Mon, 09 Jan 2012 17:34:56 +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 1RkJ7V-0004BZ-T0
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18601 invoked from network); 9 Jan 2012 17:34:48 -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 Jan 2012 17:34:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34: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, 9 Jan 2012 17:34: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
	1RkJ7P-0001xo-J4; Mon, 09 Jan 2012 17:34:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7P-0004ip-ID;
	Mon, 09 Jan 2012 17:34:47 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:36 +0000
Message-ID: <1326130477-18085-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a new-style asynchronous facility for waiting for device
states on xenbus.  This will replace libxl__wait_for_device_state,
after the callers have been updated in later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   74 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   41 +++++++++++++++++++++++
 2 files changed, 115 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index c594494..c26210b 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -506,6 +506,80 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
 }
 
 /*
+ * waiting for device state
+ */
+
+static void devstate_watch_callback(libxl__egc *egc, libxl__ev_xswatch *watch,
+                                const char *watch_path, const char *event_path)
+{
+    libxl__ev_devstate *ds;
+    libxl__gc *gc = &egc->gc;
+    GET_CONTAINING_STRUCT(ds, watch, watch);
+    int rc;
+
+    char *sstate = libxl__xs_read(&egc->gc, XBT_NULL, watch_path);
+    if (!sstate) {
+        if (errno == ENOENT) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " but it was removed", watch_path, ds->wanted);
+            rc = ERROR_INVAL;
+        } else {
+            LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "backend %s wanted state"
+                             " %d but read failed", watch_path, ds->wanted);
+            rc = ERROR_FAIL;
+        }
+    } else {
+        int got = atoi(sstate);
+        if (got == ds->wanted) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d ok",
+                       watch_path, ds->wanted);
+            rc = 0;
+        } else {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+                       " still waiting state %d", watch_path, ds->wanted, got);
+            return;
+        }
+    }
+    libxl__ev_devstate_cancel(&egc->gc, ds);
+    ds->callback(egc, ds, rc);
+}
+
+static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    libxl__ev_devstate *ds;
+    libxl__gc *gc = &egc->gc;
+    GET_CONTAINING_STRUCT(ds, ev, timeout);
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+               " timed out", ds->watch.path, ds->wanted);
+    libxl__ev_devstate_cancel(&egc->gc, ds);
+    ds->callback(egc, ds, ERROR_TIMEDOUT);
+}
+
+int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                            libxl__ev_devstate_callback cb,
+                            const char *state_path, int state, int milliseconds)
+{
+    int rc;
+
+    ds->wanted = state;
+
+    rc = libxl__ev_time_register_rel(gc, &ds->timeout, devstate_timeout,
+                                     milliseconds);
+    if (rc) goto out;
+
+    rc = libxl__ev_xswatch_register(gc, &ds->watch, devstate_watch_callback,
+                                    state_path);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__ev_devstate_cancel(gc, ds);
+    return rc;
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0c2ad6..6c87290 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -683,6 +683,47 @@ _hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
                                          libxl__device_state_handler handler);
 
 /*
+ * libxl__ev_devstate - waits a given time for a device to
+ * reach a given state.  Follows the libxl_ev_* conventions.
+ * Will generate only one event, and after that is automatically
+ * cancelled.
+ */
+typedef struct libxl__ev_devstate libxl__ev_devstate;
+typedef void libxl__ev_devstate_callback(libxl__egc *egc, libxl__ev_devstate*,
+                                         int rc);
+  /* rc will be 0, ERROR_TIMEDOUT, ERROR_INVAL (meaning path was removed),
+   * or ERROR_FAIL if other stuff went wrong (in which latter case, logged) */
+
+struct libxl__ev_devstate {
+    /* read-only for caller, who may read only when waiting: */
+    int wanted;
+    libxl__ev_devstate_callback *callback;
+    /* as for the remainder, read-only public parts may also be
+     * read by the caller (notably, watch.path), but only when waiting: */
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+};
+
+static inline void libxl__ev_devstate_init(libxl__ev_devstate *ds)
+{
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+}
+
+static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
+                                             libxl__ev_devstate *ds)
+{
+    libxl__ev_time_deregister(gc,&ds->timeout);
+    libxl__ev_xswatch_deregister(gc,&ds->watch);
+}
+
+_hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                                    libxl__ev_devstate_callback cb,
+                                    const char *state_path,
+                                    int state, int milliseconds);
+
+
+/*
  * 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
-- 
1.7.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 Jan 09 17:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ7W-0004CE-ND; Mon, 09 Jan 2012 17:34: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 1RkJ7V-0004BY-8s
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18564 invoked from network); 9 Jan 2012 17:34:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 17:34:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34: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, 9 Jan 2012 17:34: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
	1RkJ7O-0001xl-Te; Mon, 09 Jan 2012 17:34:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7O-0004il-Sn;
	Mon, 09 Jan 2012 17:34:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:35 +0000
Message-ID: <1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: New convenience macro
	CONTAINING_STRUCT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a convenient and type-safe wrapper which does the correct
dance to subtract offsetof.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0ff15c..e0c2ad6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1224,6 +1224,41 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
  * Convenience macros.
  */
 
+/*
+ * [GET_]CONTAINING_STRUCT work like this.  Given:
+ *    typedef struct {
+ *      ...
+ *      member_type member_name;
+ *      ...
+ *    } outer_type;
+ * Then:
+ *    void GET_CONTAINING_STRUCT(outer_type *outer_var [NB:UPDATED],
+ *                               some_type *inner_ptr,
+ *                               member_name);
+ *    outer_type *CONTAINING_STRUCT(outer_type,
+ *                                  some_type *inner_ptr,
+ *                                  member_name);
+ * The semantics are that after:
+ *    outer_type outer, *outer_var;
+ *    member_type *inner_ptr = &outer->member_name;
+ *    GET_CONTAINING_STRUCT(outer_var, &outer_ptr->member_name, member_name)
+ * The following hold:
+ *    CONTAINING_STRUCT(inner_ptr, outer_type, member_name) == outer_ptr
+ *    outer_var == &outer
+ */
+#define GET_CONTAINING_STRUCT(outer_var, inner_ptr, member_name)        \
+    ((outer_var) = (void*)((char*)(inner_ptr) -                         \
+                           offsetof(typeof(*(outer_var)), member_name)), \
+     (void)(&(outer_var)->member_name ==                                \
+           (typeof(inner_ptr))0) /* type check */,                      \
+     (void)0)
+#define CONTAINING_STRUCT(outer_type, inner_ptr, member_name)           \
+    ({                                                                  \
+        typeof(outer_type) *containing_struct;                          \
+        GET_CONTAINING_STRUCT(containing_struct, inner_ptr, member_name); \
+        containing_struct;                                              \
+    })
+
 
 /*
  * All of these assume (or define)
-- 
1.7.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 Jan 09 17:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ7W-0004CE-ND; Mon, 09 Jan 2012 17:34: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 1RkJ7V-0004BY-8s
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18564 invoked from network); 9 Jan 2012 17:34:47 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 17:34:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903304"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34: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, 9 Jan 2012 17:34: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
	1RkJ7O-0001xl-Te; Mon, 09 Jan 2012 17:34:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7O-0004il-Sn;
	Mon, 09 Jan 2012 17:34:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:35 +0000
Message-ID: <1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-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/10] libxl: New convenience macro
	CONTAINING_STRUCT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a convenient and type-safe wrapper which does the correct
dance to subtract offsetof.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e0ff15c..e0c2ad6 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1224,6 +1224,41 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
  * Convenience macros.
  */
 
+/*
+ * [GET_]CONTAINING_STRUCT work like this.  Given:
+ *    typedef struct {
+ *      ...
+ *      member_type member_name;
+ *      ...
+ *    } outer_type;
+ * Then:
+ *    void GET_CONTAINING_STRUCT(outer_type *outer_var [NB:UPDATED],
+ *                               some_type *inner_ptr,
+ *                               member_name);
+ *    outer_type *CONTAINING_STRUCT(outer_type,
+ *                                  some_type *inner_ptr,
+ *                                  member_name);
+ * The semantics are that after:
+ *    outer_type outer, *outer_var;
+ *    member_type *inner_ptr = &outer->member_name;
+ *    GET_CONTAINING_STRUCT(outer_var, &outer_ptr->member_name, member_name)
+ * The following hold:
+ *    CONTAINING_STRUCT(inner_ptr, outer_type, member_name) == outer_ptr
+ *    outer_var == &outer
+ */
+#define GET_CONTAINING_STRUCT(outer_var, inner_ptr, member_name)        \
+    ((outer_var) = (void*)((char*)(inner_ptr) -                         \
+                           offsetof(typeof(*(outer_var)), member_name)), \
+     (void)(&(outer_var)->member_name ==                                \
+           (typeof(inner_ptr))0) /* type check */,                      \
+     (void)0)
+#define CONTAINING_STRUCT(outer_type, inner_ptr, member_name)           \
+    ({                                                                  \
+        typeof(outer_type) *containing_struct;                          \
+        GET_CONTAINING_STRUCT(containing_struct, inner_ptr, member_name); \
+        containing_struct;                                              \
+    })
+
 
 /*
  * All of these assume (or define)
-- 
1.7.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 Jan 09 17:35:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ7T-0004Bi-Uf; Mon, 09 Jan 2012 17:34:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RkJ7S-0004BR-GT
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18485 invoked from network); 9 Jan 2012 17:34:44 -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 Jan 2012 17:34:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903300"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 17:34: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
	1RkJ7M-0001xf-4g; Mon, 09 Jan 2012 17:34:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7M-0004ic-0B;
	Mon, 09 Jan 2012 17:34:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:33 +0000
Message-ID: <1326130477-18085-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH RFC v6.1 11-14/10] libxl: asynchronous 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

Here are four more patches to go onto the end of my previous 10-patch
event series posting:

   11/10 libxl: Asynchronous/long-running operation infrastructure
   12/10 libxl: New convenience macro CONTAINING_STRUCT
   13/10 libxl: Introduce libxl__ev_devstate
   14/10 libxl: Convert to asynchronous: device removal

This introduces a standard way for the same libxl function to be
useable both by simple-minded callers who want to wait synchronously,
and by advanced callers who want to the function to return immediately
and arrange a callback or event later.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:35:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJ7T-0004Bi-Uf; Mon, 09 Jan 2012 17:34:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RkJ7S-0004BR-GT
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:34:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326130484!10272818!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18485 invoked from network); 9 Jan 2012 17:34:44 -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 Jan 2012 17:34:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903300"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:34:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 17:34: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
	1RkJ7M-0001xf-4g; Mon, 09 Jan 2012 17:34:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJ7M-0004ic-0B;
	Mon, 09 Jan 2012 17:34:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 9 Jan 2012 17:34:33 +0000
Message-ID: <1326130477-18085-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH RFC v6.1 11-14/10] libxl: asynchronous 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

Here are four more patches to go onto the end of my previous 10-patch
event series posting:

   11/10 libxl: Asynchronous/long-running operation infrastructure
   12/10 libxl: New convenience macro CONTAINING_STRUCT
   13/10 libxl: Introduce libxl__ev_devstate
   14/10 libxl: Convert to asynchronous: device removal

This introduces a standard way for the same libxl function to be
useable both by simple-minded callers who want to wait synchronously,
and by advanced callers who want to the function to return immediately
and arrange a callback or event later.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:38:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17: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 1RkJAt-0004i4-DU; Mon, 09 Jan 2012 17:38:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkJAs-0004hT-2L
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:38:22 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326130695!10238161!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzEwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7297 invoked from network); 9 Jan 2012 17:38:16 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-11.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 17:38:16 -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 q09Hc8Bj032701;
	Mon, 9 Jan 2012 12:38:08 -0500
Date: Mon, 09 Jan 2012 12:38:08 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <3f35c565-bcaf-49d2-ba46-c61ca95aa51b@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120109170418.GD28700@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Mon, Jan 09, 2012 at 04:12:10PM +0000, Stefano Stabellini wrote:
> > On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini
> > > wrote:
> > > > I don't think we should add "PCI_XEN && SWIOTLB_XEN &&
> > > > X86_LOCAL_APIC &&
> > > > X86_IO_APIC && ACPI && PCI" to XEN either.
> > > > However it should be possible to add only the right
> > > > dependencies to the
> > > > right places.
> > > > In practice it should be sufficient to:
> > > > 
> > > > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> > > 
> > > Not good. You can make non-ACPI builds with PCI.
> > > 
> > > .. and you are missing CONFIG_PCI in there.
> > > > 
> > > > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on
> > > > PCI_XEN;
> > > 
> > > OK. That sounds good.
> > > > 
> > > > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> > > 
> > > No.. same issue - non-ACPI builds can be with PCI.
> > > > 
> > 
> > Right.. in that case we should carefully replace the 'ifdef
> > CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.
> 
> .. which I think I did at some point as part of cleanup and then
> removed them since it peppered the xen.c with tons of #ifdef
> CONFIG_ACPI.
> 
> What about PVonHVM. There is this nagging feeling in the back of my
> head that turning CONFIG_XEN_DOM0 disables the CONFIG_PVHVM option?
> Or something like that? Maybe it is the other way around?
> 
> It would seem we need to seperate the PVHVM  from DOM0. But the extra
> complexity comes with Mukesh's PVonHVM Hybrid which can do dom0 stuff
> with PVonHVM (should be searchable on xen-devel to find the patches).

They're currently separate, i.e. no problem with DOM0 off and PVHVM on,
or vice-versa afaict. I don't know anything about the hybrid though.

> 
> Ian also mentioned that we MUST have the XEN_PRIVILIGED option,
> otherwise
> we will cause a regression with the GRUB tools. So that must stay or
> we need
> provide a deprecation schedule for the next 3 years to remove it and
> have patches in the GRUB toolchains.

Yeah, that's a bummer.

> 
> Either way, there is also the question of making sure that no
> regressions
> are introduced - so a lot of the CONFIG_* interdependencies will have
> to be checked. I think that means checking CONFIG_XEN,
> CONFIG_PRIVILIGED,
> CONFIG_PVHVM, CONFIG_PCI, CONFIG_ACPI, CONFIG_XEN_BACKEND in various
> combinations.
> 

I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in
arch/x86/pci/xen.c it would be pretty easy to review for equivalence.
Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere else and
compile in the 3 files. I don't think it makes much sense to do it
though. XEN_DOM0 keeps things tidier now and might be useful later.

> Oh, I forgot CONFIG_XEN_FRONTEND.. And I think that one can also
> become
> a module (ditto for XEN_BACKEND)
> 
> And everytime we did something to those we managed to mess them up so
> we should be dilligient.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 17:38:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17: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 1RkJAt-0004i4-DU; Mon, 09 Jan 2012 17:38:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkJAs-0004hT-2L
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:38:22 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326130695!10238161!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzEwNDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7297 invoked from network); 9 Jan 2012 17:38:16 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-11.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 17:38:16 -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 q09Hc8Bj032701;
	Mon, 9 Jan 2012 12:38:08 -0500
Date: Mon, 09 Jan 2012 12:38:08 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <3f35c565-bcaf-49d2-ba46-c61ca95aa51b@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120109170418.GD28700@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Mon, Jan 09, 2012 at 04:12:10PM +0000, Stefano Stabellini wrote:
> > On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini
> > > wrote:
> > > > I don't think we should add "PCI_XEN && SWIOTLB_XEN &&
> > > > X86_LOCAL_APIC &&
> > > > X86_IO_APIC && ACPI && PCI" to XEN either.
> > > > However it should be possible to add only the right
> > > > dependencies to the
> > > > right places.
> > > > In practice it should be sufficient to:
> > > > 
> > > > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> > > 
> > > Not good. You can make non-ACPI builds with PCI.
> > > 
> > > .. and you are missing CONFIG_PCI in there.
> > > > 
> > > > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on
> > > > PCI_XEN;
> > > 
> > > OK. That sounds good.
> > > > 
> > > > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> > > 
> > > No.. same issue - non-ACPI builds can be with PCI.
> > > > 
> > 
> > Right.. in that case we should carefully replace the 'ifdef
> > CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.
> 
> .. which I think I did at some point as part of cleanup and then
> removed them since it peppered the xen.c with tons of #ifdef
> CONFIG_ACPI.
> 
> What about PVonHVM. There is this nagging feeling in the back of my
> head that turning CONFIG_XEN_DOM0 disables the CONFIG_PVHVM option?
> Or something like that? Maybe it is the other way around?
> 
> It would seem we need to seperate the PVHVM  from DOM0. But the extra
> complexity comes with Mukesh's PVonHVM Hybrid which can do dom0 stuff
> with PVonHVM (should be searchable on xen-devel to find the patches).

They're currently separate, i.e. no problem with DOM0 off and PVHVM on,
or vice-versa afaict. I don't know anything about the hybrid though.

> 
> Ian also mentioned that we MUST have the XEN_PRIVILIGED option,
> otherwise
> we will cause a regression with the GRUB tools. So that must stay or
> we need
> provide a deprecation schedule for the next 3 years to remove it and
> have patches in the GRUB toolchains.

Yeah, that's a bummer.

> 
> Either way, there is also the question of making sure that no
> regressions
> are introduced - so a lot of the CONFIG_* interdependencies will have
> to be checked. I think that means checking CONFIG_XEN,
> CONFIG_PRIVILIGED,
> CONFIG_PVHVM, CONFIG_PCI, CONFIG_ACPI, CONFIG_XEN_BACKEND in various
> combinations.
> 

I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in
arch/x86/pci/xen.c it would be pretty easy to review for equivalence.
Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere else and
compile in the 3 files. I don't think it makes much sense to do it
though. XEN_DOM0 keeps things tidier now and might be useful later.

> Oh, I forgot CONFIG_XEN_FRONTEND.. And I think that one can also
> become
> a module (ditto for XEN_BACKEND)
> 
> And everytime we did something to those we managed to mess them up so
> we should be dilligient.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 09 17:40:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJCY-0004xy-5b; Mon, 09 Jan 2012 17:40:06 +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 1RkJCW-0004x7-VN
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:40:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326130798!8415251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13869 invoked from network); 9 Jan 2012 17:39:58 -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 Jan 2012 17:39:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903479"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:39:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 17:39: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
	1RkJCQ-0001za-5y; Mon, 09 Jan 2012 17:39:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJCQ-0004jc-3v;
	Mon, 09 Jan 2012 17:39:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20235.9838.103514.619546@mariner.uk.xensource.com>
Date: Mon, 9 Jan 2012 17:39:58 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, xen-devel <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

U3RlZmFubyBTdGFiZWxsaW5pIHdyaXRlcyAoIlJlOiBEcml2ZXIgZG9tYWlucyBhbmQgaG90cGx1
ZyBzY3JpcHRzLCByZWR1eCIpOgo+IE9uIE1vbiwgOSBKYW4gMjAxMiwgUm9nZXIgUGF1IE1vbm7D
g8aSw4LCqSB3cm90ZToKPiA+IFRoaXMgc2hvdWxkIGJlIGhhbmRsZWQgYnkgeGVuYmFja2VuZGQg
KEkga25vdyBpdCB3aWxsIG5vdCBleGFjdGx5IGJlCj4gPiB4ZW5iYWNrZW5kZCwgYnV0IGxldCdz
IGNhbGwgaXQgdGhhdCB3YXkgdG8gc2ltcGxpZnkgdGhpbmdzKSwgc2luY2UgaXQKPiA+IHNob3Vs
ZCBiZSBsaXN0ZW5pbmcgdG8gL2xvY2FsL2RvbWFpbi88ZG9taWQ+L2JhY2tlbmQvKiBmb3IgY2hh
bmdlcyBhbmQKPiA+IHJlYWN0IHVwb24gdGhlbS4KPiAKPiBJIHRoaW5rIHRoaXMgaXMgd3Jvbmcg
YmVjYXVzZSB3ZSB3b3VsZCBiZSB0eWluZyB0b2dldGhlciB0aGUgdmlmCj4gY3JlYXRpb24gd2l0
aCB0aGUgc2NyaXB0IGV4ZWN1dGlvbiwgd2hpbGUgdGhlc2UgdHdvIGtpbmRzIG9mIGV2ZW50cwo+
IG1pZ2h0IG5lZWQgdG8gYmUgZXhlY3V0ZWQgYXQgZGlmZmVyZW50IHBvaW50IGluIHRpbWUgKGVz
cGVjaWFsbHkgaW4gdGhlCj4gYmxvY2sgY2FzZSkuIFdlIG5lZWQgYmUgZmxleGlibGUuCj4gSSB3
b3VsZCBtYWtlIHhlbmJhY2tlbmRkIGxpc3RlbiB0byBhIGRpZmZlcmVudCB4ZW5zdG9yZSBsb2Nh
dGlvbiwKPiBtYXliZSAvaG90cGx1Zy88ZG9taWQ+LyosIHNvIHRoYXQgdGhlIHRvb2xzdGFjayBj
YW4gZXhwbGljaXRseSBhc2sKPiB4ZW5iYWNrZW5kZCBmb3Igc29tZXRoaW5nLCBtYWtpbmcgc3Vy
ZSB0aGF0IGl0IGdldHMgZG9uZSBiZWZvcmUgdGFraW5nCj4gb3RoZXIgYWN0aW9ucy4KClRoZSBm
YWN0IHRoYXQgYW55IHNjcmlwdCBpcyBiZWluZyBydW4sIGFuZCBleGFjdGx5IHdoYXQgdGhhdCBz
Y3JpcHQKaXMsIGFuZCB3aGVuLCBkb2VzIG5vdCBuZWVkIHRvIGJlIHZpc2libGUgdG8gdGhlIG1h
aW4gdG9vbHN0YWNrLiAgSXQncwphIGZ1bmN0aW9uIGVudGlyZWx5IGluc2lkZSB0aGUgZHJpdmVy
IGRvbWFpbi4KClNvIEkgZGlzYWdyZWUuCgpJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:40:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:40:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJCY-0004xy-5b; Mon, 09 Jan 2012 17:40:06 +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 1RkJCW-0004x7-VN
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:40:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326130798!8415251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13869 invoked from network); 9 Jan 2012 17:39:58 -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 Jan 2012 17:39:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903479"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:39:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 17:39: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
	1RkJCQ-0001za-5y; Mon, 09 Jan 2012 17:39:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkJCQ-0004jc-3v;
	Mon, 09 Jan 2012 17:39:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20235.9838.103514.619546@mariner.uk.xensource.com>
Date: Mon, 9 Jan 2012 17:39:58 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, xen-devel <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

U3RlZmFubyBTdGFiZWxsaW5pIHdyaXRlcyAoIlJlOiBEcml2ZXIgZG9tYWlucyBhbmQgaG90cGx1
ZyBzY3JpcHRzLCByZWR1eCIpOgo+IE9uIE1vbiwgOSBKYW4gMjAxMiwgUm9nZXIgUGF1IE1vbm7D
g8aSw4LCqSB3cm90ZToKPiA+IFRoaXMgc2hvdWxkIGJlIGhhbmRsZWQgYnkgeGVuYmFja2VuZGQg
KEkga25vdyBpdCB3aWxsIG5vdCBleGFjdGx5IGJlCj4gPiB4ZW5iYWNrZW5kZCwgYnV0IGxldCdz
IGNhbGwgaXQgdGhhdCB3YXkgdG8gc2ltcGxpZnkgdGhpbmdzKSwgc2luY2UgaXQKPiA+IHNob3Vs
ZCBiZSBsaXN0ZW5pbmcgdG8gL2xvY2FsL2RvbWFpbi88ZG9taWQ+L2JhY2tlbmQvKiBmb3IgY2hh
bmdlcyBhbmQKPiA+IHJlYWN0IHVwb24gdGhlbS4KPiAKPiBJIHRoaW5rIHRoaXMgaXMgd3Jvbmcg
YmVjYXVzZSB3ZSB3b3VsZCBiZSB0eWluZyB0b2dldGhlciB0aGUgdmlmCj4gY3JlYXRpb24gd2l0
aCB0aGUgc2NyaXB0IGV4ZWN1dGlvbiwgd2hpbGUgdGhlc2UgdHdvIGtpbmRzIG9mIGV2ZW50cwo+
IG1pZ2h0IG5lZWQgdG8gYmUgZXhlY3V0ZWQgYXQgZGlmZmVyZW50IHBvaW50IGluIHRpbWUgKGVz
cGVjaWFsbHkgaW4gdGhlCj4gYmxvY2sgY2FzZSkuIFdlIG5lZWQgYmUgZmxleGlibGUuCj4gSSB3
b3VsZCBtYWtlIHhlbmJhY2tlbmRkIGxpc3RlbiB0byBhIGRpZmZlcmVudCB4ZW5zdG9yZSBsb2Nh
dGlvbiwKPiBtYXliZSAvaG90cGx1Zy88ZG9taWQ+LyosIHNvIHRoYXQgdGhlIHRvb2xzdGFjayBj
YW4gZXhwbGljaXRseSBhc2sKPiB4ZW5iYWNrZW5kZCBmb3Igc29tZXRoaW5nLCBtYWtpbmcgc3Vy
ZSB0aGF0IGl0IGdldHMgZG9uZSBiZWZvcmUgdGFraW5nCj4gb3RoZXIgYWN0aW9ucy4KClRoZSBm
YWN0IHRoYXQgYW55IHNjcmlwdCBpcyBiZWluZyBydW4sIGFuZCBleGFjdGx5IHdoYXQgdGhhdCBz
Y3JpcHQKaXMsIGFuZCB3aGVuLCBkb2VzIG5vdCBuZWVkIHRvIGJlIHZpc2libGUgdG8gdGhlIG1h
aW4gdG9vbHN0YWNrLiAgSXQncwphIGZ1bmN0aW9uIGVudGlyZWx5IGluc2lkZSB0aGUgZHJpdmVy
IGRvbWFpbi4KClNvIEkgZGlzYWdyZWUuCgpJYW4uCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:52:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17: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 1RkJO8-0005I1-H6; Mon, 09 Jan 2012 17:52:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkJO7-0005Hw-6t
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:52:03 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326131512!11640266!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDg4MjU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18848 invoked from network); 9 Jan 2012 17:51:56 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 17:51:56 -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 q09HpixH015277
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 12:51:45 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q09Hpgwm024855; Mon, 9 Jan 2012 12:51:43 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Mon,  9 Jan 2012 18:51:41 +0100
Message-Id: <1326131501-9610-1-git-send-email-drjones@redhat.com>
In-Reply-To: <725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com>
References: <725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	dmitry.torokhov@gmail.com, FlorianSchandinat@gmx.de, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..3e38c2f 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2263,7 +2263,7 @@ config FB_VIRTUAL
 
 config XEN_FBDEV_FRONTEND
 	tristate "Xen virtual frame buffer support"
-	depends on FB && XEN
+	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
 	select FB_SYS_FILLRECT
 	select FB_SYS_COPYAREA
 	select FB_SYS_IMAGEBLIT
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:52:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17: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 1RkJO8-0005I1-H6; Mon, 09 Jan 2012 17:52:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkJO7-0005Hw-6t
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:52:03 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326131512!11640266!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDg4MjU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18848 invoked from network); 9 Jan 2012 17:51:56 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 17:51:56 -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 q09HpixH015277
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 12:51:45 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q09Hpgwm024855; Mon, 9 Jan 2012 12:51:43 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Mon,  9 Jan 2012 18:51:41 +0100
Message-Id: <1326131501-9610-1-git-send-email-drjones@redhat.com>
In-Reply-To: <725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com>
References: <725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	dmitry.torokhov@gmail.com, FlorianSchandinat@gmx.de, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..3e38c2f 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2263,7 +2263,7 @@ config FB_VIRTUAL
 
 config XEN_FBDEV_FRONTEND
 	tristate "Xen virtual frame buffer support"
-	depends on FB && XEN
+	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
 	select FB_SYS_FILLRECT
 	select FB_SYS_COPYAREA
 	select FB_SYS_IMAGEBLIT
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:59:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJUo-0005Rr-DF; Mon, 09 Jan 2012 17:58:58 +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 1RkJUm-0005Ri-IL
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:58:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326131930!7066500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11917 invoked from network); 9 Jan 2012 17:58:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 17:58:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:58: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; Mon, 9 Jan 2012 17:58:50 +0000
Date: Mon, 9 Jan 2012 17:58:54 +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.1201091752280.3150@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 v4 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 fourth 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 v4:

- fix arm build after rebasing on xen-unstable
87c607efbfece009360f615b2bf98959f4ea48e8;

- use ABS() in __ldivmod_helper;

- return a negative integer in case of errors in elf_load_image.


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 +
 tools/libxc/xc_dom_elfloader.c         |    8 +-
 tools/libxc/xc_hvm_build.c             |    5 +-
 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/domain_build.c            |    7 +-
 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      |   28 ++-
 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                  |    4 +-
 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           |  236 ++++++++++++
 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               |    4 +-
 xen/include/xen/list.h                 |    1 +
 xen/include/xen/paging.h               |    2 +-
 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 ++
 142 files changed, 10679 insertions(+), 62 deletions(-)


A git branch is available here, based on xen-unstable (git CS
87c607efbfece009360f615b2bf98959f4ea48e8):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v4


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 17:59:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 17:59:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJUo-0005Rr-DF; Mon, 09 Jan 2012 17:58:58 +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 1RkJUm-0005Ri-IL
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 17:58:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326131930!7066500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11917 invoked from network); 9 Jan 2012 17:58:50 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 17:58:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 17:58: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; Mon, 9 Jan 2012 17:58:50 +0000
Date: Mon, 9 Jan 2012 17:58:54 +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.1201091752280.3150@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 v4 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 fourth 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 v4:

- fix arm build after rebasing on xen-unstable
87c607efbfece009360f615b2bf98959f4ea48e8;

- use ABS() in __ldivmod_helper;

- return a negative integer in case of errors in elf_load_image.


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 +
 tools/libxc/xc_dom_elfloader.c         |    8 +-
 tools/libxc/xc_hvm_build.c             |    5 +-
 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/domain_build.c            |    7 +-
 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      |   28 ++-
 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                  |    4 +-
 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           |  236 ++++++++++++
 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               |    4 +-
 xen/include/xen/list.h                 |    1 +
 xen/include/xen/paging.h               |    2 +-
 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 ++
 142 files changed, 10679 insertions(+), 62 deletions(-)


A git branch is available here, based on xen-unstable (git CS
87c607efbfece009360f615b2bf98959f4ea48e8):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v4


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:00:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJVv-0005Zw-KV; Mon, 09 Jan 2012 18:00:07 +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 1RkJVq-0005V8-M4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13668 invoked from network); 9 Jan 2012 17:59:56 -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;
	9 Jan 2012 17:59:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802407"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 12:59: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 q09Hxhu3002699;
	Mon, 9 Jan 2012 09:59:54 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:44 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com, JBeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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; 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 |    4 +++-
 2 files changed, 5 insertions(+), 2 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 15f1806..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)
 {
-- 
1.7.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 Jan 09 18:00:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJVv-0005Zw-KV; Mon, 09 Jan 2012 18:00:07 +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 1RkJVq-0005V8-M4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13668 invoked from network); 9 Jan 2012 17:59:56 -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;
	9 Jan 2012 17:59:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802407"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 12:59: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 q09Hxhu3002699;
	Mon, 9 Jan 2012 09:59:54 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:44 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com, JBeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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; 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 |    4 +++-
 2 files changed, 5 insertions(+), 2 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 15f1806..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)
 {
-- 
1.7.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 Jan 09 18:00:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJVw-0005a5-4L; Mon, 09 Jan 2012 18:00: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 1RkJVs-0005VE-Ng
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14010 invoked from network); 9 Jan 2012 17:59:58 -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;
	9 Jan 2012 17:59:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802415"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 12:59: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 q09Hxhtv002699;
	Mon, 9 Jan 2012 09:59:46 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:38 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 d6ae09b..14ab515 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 014734d..b024016 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 f22fe05..1051a86 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 c796137..8d45439 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 2fb2309..92d1a4f 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 3904afe..6546757 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 76ab440..fdbeed1 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 Mon Jan 09 18:00:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJVw-0005a5-4L; Mon, 09 Jan 2012 18:00: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 1RkJVs-0005VE-Ng
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14010 invoked from network); 9 Jan 2012 17:59:58 -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;
	9 Jan 2012 17:59:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802415"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 12:59: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 q09Hxhtv002699;
	Mon, 9 Jan 2012 09:59:46 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:38 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 d6ae09b..14ab515 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 014734d..b024016 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 f22fe05..1051a86 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 c796137..8d45439 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 2fb2309..92d1a4f 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 3904afe..6546757 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 76ab440..fdbeed1 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 Mon Jan 09 18:00:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJVt-0005XS-Tq; Mon, 09 Jan 2012 18:00:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJVo-0005Uy-5D
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13594 invoked from network); 9 Jan 2012 17:59:53 -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;
	9 Jan 2012 17:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802400"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:52 -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, 9 Jan 2012 12:59:51 -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 q09Hxhu0002699;
	Mon, 9 Jan 2012 09:59:50 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:41 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com, JBeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 160a47f..de1a0ed 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2390,6 +2390,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)
 {
@@ -2476,6 +2566,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 Mon Jan 09 18:00:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJVt-0005XS-Tq; Mon, 09 Jan 2012 18:00:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJVo-0005Uy-5D
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13594 invoked from network); 9 Jan 2012 17:59:53 -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;
	9 Jan 2012 17:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802400"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:52 -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, 9 Jan 2012 12:59:51 -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 q09Hxhu0002699;
	Mon, 9 Jan 2012 09:59:50 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:41 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com, JBeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 160a47f..de1a0ed 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2390,6 +2390,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)
 {
@@ -2476,6 +2566,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 Mon Jan 09 18:00:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJW1-0005be-Ip; Mon, 09 Jan 2012 18:00: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 1RkJVz-0005ZZ-HQ
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14527 invoked from network); 9 Jan 2012 18:00:04 -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;
	9 Jan 2012 18:00:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802429"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu4002699;
	Mon, 9 Jan 2012 09:59:56 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:45 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 v4:

- bring atomic access routines in line with upstream changes;

- fix build for -wunused-values;


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      |  236 ++++++++++++++++++++++++++++++++
 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, 2444 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..c7eadd6
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,236 @@
+/*
+ *  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(read_u8_atomic, "b", uint8_t, "=q")
+build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
+//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
+build_atomic_read(read_int_atomic, "", int, "=r")
+
+build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
+build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
+build_atomic_write(write_u32_atomic, "", uint32_t, "r")
+//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
+build_atomic_write(write_int_atomic, "", int, "r")
+
+void __bad_atomic_size(void);
+
+#define read_atomic(p) ({                                               \
+    typeof(*p) __x;                                                     \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: __x = (typeof(*p))read_u8_atomic((uint8_t *)p); break;      \
+    case 2: __x = (typeof(*p))read_u16_atomic((uint16_t *)p); break;    \
+    case 4: __x = (typeof(*p))read_u32_atomic((uint32_t *)p); break;    \
+    default: __x = 0; __bad_atomic_size(); break;                       \
+    }                                                                   \
+    __x;                                                                \
+})
+
+#define write_atomic(p, x) ({                                           \
+    typeof(*p) __x = (x);                                               \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: write_u8_atomic((uint8_t *)p, (uint8_t)__x); break;         \
+    case 2: write_u16_atomic((uint16_t *)p, (uint16_t)__x); break;      \
+    case 4: write_u32_atomic((uint32_t *)p, (uint32_t)__x); break;      \
+    default: __bad_atomic_size(); break;                                \
+    }                                                                   \
+    __x;                                                                \
+})
+
+/*
+ * 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..452613a
--- /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) ((void) 0)
+#define debugger_trap_immediate() ((void) 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..66fe9bf
--- /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) do {} while (0)
+#define gnttab_create_shared_page(d, t, i) do {} while (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 41b14ea..68bce71 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 Mon Jan 09 18:00:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJW1-0005be-Ip; Mon, 09 Jan 2012 18:00: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 1RkJVz-0005ZZ-HQ
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14527 invoked from network); 9 Jan 2012 18:00:04 -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;
	9 Jan 2012 18:00:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802429"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu4002699;
	Mon, 9 Jan 2012 09:59:56 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:45 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 v4:

- bring atomic access routines in line with upstream changes;

- fix build for -wunused-values;


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      |  236 ++++++++++++++++++++++++++++++++
 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, 2444 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..c7eadd6
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,236 @@
+/*
+ *  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(read_u8_atomic, "b", uint8_t, "=q")
+build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
+//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
+build_atomic_read(read_int_atomic, "", int, "=r")
+
+build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
+build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
+build_atomic_write(write_u32_atomic, "", uint32_t, "r")
+//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
+build_atomic_write(write_int_atomic, "", int, "r")
+
+void __bad_atomic_size(void);
+
+#define read_atomic(p) ({                                               \
+    typeof(*p) __x;                                                     \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: __x = (typeof(*p))read_u8_atomic((uint8_t *)p); break;      \
+    case 2: __x = (typeof(*p))read_u16_atomic((uint16_t *)p); break;    \
+    case 4: __x = (typeof(*p))read_u32_atomic((uint32_t *)p); break;    \
+    default: __x = 0; __bad_atomic_size(); break;                       \
+    }                                                                   \
+    __x;                                                                \
+})
+
+#define write_atomic(p, x) ({                                           \
+    typeof(*p) __x = (x);                                               \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: write_u8_atomic((uint8_t *)p, (uint8_t)__x); break;         \
+    case 2: write_u16_atomic((uint16_t *)p, (uint16_t)__x); break;      \
+    case 4: write_u32_atomic((uint32_t *)p, (uint32_t)__x); break;      \
+    default: __bad_atomic_size(); break;                                \
+    }                                                                   \
+    __x;                                                                \
+})
+
+/*
+ * 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..452613a
--- /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) ((void) 0)
+#define debugger_trap_immediate() ((void) 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..66fe9bf
--- /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) do {} while (0)
+#define gnttab_create_shared_page(d, t, i) do {} while (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 41b14ea..68bce71 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 Mon Jan 09 18:00:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJWD-0005i2-Ro; Mon, 09 Jan 2012 18:00: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 1RkJWB-0005dO-Fa
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17576 invoked from network); 9 Jan 2012 18:00:17 -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;
	9 Jan 2012 18:00:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692283"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:59 -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, 9 Jan 2012 12:59: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 q09Hxhtw002699;
	Mon, 9 Jan 2012 09:59:47 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:39 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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;

- guest_physmap_add_page should be ((void)0).


Changes in v4:

- fix guest_physmap_add_page;


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/paging.h      |    2 +-
 xen/include/xen/time.h        |    1 +
 7 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1100517..3c6c5af 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -635,7 +635,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
 
     xfree(d->mem_event);
 
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 65825b4..ac2be2a 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/paging.h b/xen/include/xen/paging.h
index abe276d..a5d3261 100644
--- a/xen/include/xen/paging.h
+++ b/xen/include/xen/paging.h
@@ -20,7 +20,7 @@
 
 #define paging_mode_translate(d)              (0)
 #define paging_mode_external(d)               (0)
-#define guest_physmap_add_page(d, p, m, o)    (0)
+#define guest_physmap_add_page(d, p, m, o)    ((void)0)
 #define guest_physmap_remove_page(d, p, m, o) ((void)0)
 
 #endif
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 Mon Jan 09 18:00:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJWD-0005i2-Ro; Mon, 09 Jan 2012 18:00: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 1RkJWB-0005dO-Fa
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17576 invoked from network); 9 Jan 2012 18:00:17 -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;
	9 Jan 2012 18:00:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692283"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:59 -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, 9 Jan 2012 12:59: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 q09Hxhtw002699;
	Mon, 9 Jan 2012 09:59:47 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:39 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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;

- guest_physmap_add_page should be ((void)0).


Changes in v4:

- fix guest_physmap_add_page;


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/paging.h      |    2 +-
 xen/include/xen/time.h        |    1 +
 7 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1100517..3c6c5af 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -635,7 +635,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
 
     xfree(d->mem_event);
 
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 65825b4..ac2be2a 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/paging.h b/xen/include/xen/paging.h
index abe276d..a5d3261 100644
--- a/xen/include/xen/paging.h
+++ b/xen/include/xen/paging.h
@@ -20,7 +20,7 @@
 
 #define paging_mode_translate(d)              (0)
 #define paging_mode_external(d)               (0)
-#define guest_physmap_add_page(d, p, m, o)    (0)
+#define guest_physmap_add_page(d, p, m, o)    ((void)0)
 #define guest_physmap_remove_page(d, p, m, o) ((void)0)
 
 #endif
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 Mon Jan 09 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJW7-0005e1-Bt; Mon, 09 Jan 2012 18:00:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJW5-0005b9-K0
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14798 invoked from network); 9 Jan 2012 18:00:10 -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;
	9 Jan 2012 18:00:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802438"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu5002699;
	Mon, 9 Jan 2012 09:59:57 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:46 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWC-0005gv-1X; Mon, 09 Jan 2012 18:00: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 1RkJWA-0005dB-Re
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17491 invoked from network); 9 Jan 2012 18:00:16 -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;
	9 Jan 2012 18:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692281"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:55 -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, 9 Jan 2012 12:59:55 -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 q09Hxhtx002699;
	Mon, 9 Jan 2012 09:59:49 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:40 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com, JBeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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.


Changes in v4:

- use ABS().


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..e9d0637 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 = ABS(a);
+    ub = ABS(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 Mon Jan 09 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJW7-0005e1-Bt; Mon, 09 Jan 2012 18:00:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJW5-0005b9-K0
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14798 invoked from network); 9 Jan 2012 18:00:10 -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;
	9 Jan 2012 18:00:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802438"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu5002699;
	Mon, 9 Jan 2012 09:59:57 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:46 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWC-0005gv-1X; Mon, 09 Jan 2012 18:00: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 1RkJWA-0005dB-Re
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17491 invoked from network); 9 Jan 2012 18:00:16 -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;
	9 Jan 2012 18:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692281"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59:55 -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, 9 Jan 2012 12:59:55 -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 q09Hxhtx002699;
	Mon, 9 Jan 2012 09:59:49 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:40 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com, JBeulich@suse.com,
	stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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.


Changes in v4:

- use ABS().


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..e9d0637 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 = ABS(a);
+    ub = ABS(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 Mon Jan 09 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWD-0005hk-Ec; Mon, 09 Jan 2012 18:00: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 1RkJWB-0005dL-CK
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15013 invoked from network); 9 Jan 2012 18:00:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802452"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuA002699;
	Mon, 9 Jan 2012 10:00:04 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:51 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWD-0005hk-Ec; Mon, 09 Jan 2012 18:00: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 1RkJWB-0005dL-CK
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15013 invoked from network); 9 Jan 2012 18:00:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802452"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuA002699;
	Mon, 9 Jan 2012 10:00:04 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:51 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWE-0005iQ-95; Mon, 09 Jan 2012 18:00:26 +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 1RkJWC-0005dl-4O
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17593 invoked from network); 9 Jan 2012 18:00:17 -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;
	9 Jan 2012 18:00:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu1002699;
	Mon, 9 Jan 2012 09:59:51 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:42 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 v4:

- check for return values in elf_load_image.


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>
---
 tools/libxc/xc_dom_elfloader.c    |    8 +++++++-
 tools/libxc/xc_hvm_build.c        |    5 +++--
 xen/arch/x86/domain_build.c       |    7 ++++++-
 xen/common/libelf/libelf-loader.c |   28 +++++++++++++++++++++++++---
 xen/include/xen/libelf.h          |    2 +-
 5 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 4d7b8e0..2e69559 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -310,9 +310,15 @@ static int xc_dom_parse_elf_kernel(struct xc_dom_image *dom)
 static int xc_dom_load_elf_kernel(struct xc_dom_image *dom)
 {
     struct elf_binary *elf = dom->private_loader;
+    int rc;
 
     elf->dest = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
-    elf_load_binary(elf);
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+    {
+        DOMPRINTF("%s: failed to load elf binary", __FUNCTION__);
+        return rc;
+    }
     if ( dom->parms.bsd_symtab )
         xc_dom_load_elf_symtab(dom, elf, 1);
     return 0;
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 9831bab..1fa5658 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -109,8 +109,9 @@ static int loadelfimage(
     elf->dest += elf->pstart & (PAGE_SIZE - 1);
 
     /* Load the initial elf image. */
-    elf_load_binary(elf);
-    rc = 0;
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
 
     munmap(elf->dest, pages << PAGE_SHIFT);
     elf->dest = NULL;
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 1b3818f..b3c5d4c 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -903,7 +903,12 @@ int __init construct_dom0(
 
     /* Copy the OS image and free temporary buffer. */
     elf.dest = (void*)vkern_start;
-    elf_load_binary(&elf);
+    rc = elf_load_binary(&elf);
+    if ( rc < 0 )
+    {
+        printk("Failed to load the kernel binary\n");
+        return rc;
+    }
     bootstrap_map(NULL);
 
     if ( UNSET_ADDR != parms.virt_hypercall )
diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..4cdb03b 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,32 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+    return 0;
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    int rc;
+    rc = raw_copy_to_guest(dst, src, filesz);
+    if ( rc != 0 )
+        return -rc;
+    rc = raw_clear_guest(dst + filesz, memsz - filesz);
+    if ( rc != 0 )
+        return -rc;
+    return 0;
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -237,7 +258,7 @@ void elf_parse_binary(struct elf_binary *elf)
             __FUNCTION__, elf->pstart, elf->pend);
 }
 
-void elf_load_binary(struct elf_binary *elf)
+int elf_load_binary(struct elf_binary *elf)
 {
     const elf_phdr *phdr;
     uint64_t i, count, paddr, offset, filesz, memsz;
@@ -256,11 +277,12 @@ 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);
+        if ( elf_load_image(dest, elf->image + offset, filesz, memsz) != 0 )
+            return -1;
     }
 
     elf_load_bsdsyms(elf);
+    return 0;
 }
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d77bda6 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -198,7 +198,7 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback*,
 #endif
 
 void elf_parse_binary(struct elf_binary *elf);
-void elf_load_binary(struct elf_binary *elf);
+int elf_load_binary(struct elf_binary *elf);
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr);
 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 Mon Jan 09 18:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWE-0005iQ-95; Mon, 09 Jan 2012 18:00:26 +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 1RkJWC-0005dl-4O
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17593 invoked from network); 9 Jan 2012 18:00:17 -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;
	9 Jan 2012 18:00:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu1002699;
	Mon, 9 Jan 2012 09:59:51 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:42 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 v4:

- check for return values in elf_load_image.


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>
---
 tools/libxc/xc_dom_elfloader.c    |    8 +++++++-
 tools/libxc/xc_hvm_build.c        |    5 +++--
 xen/arch/x86/domain_build.c       |    7 ++++++-
 xen/common/libelf/libelf-loader.c |   28 +++++++++++++++++++++++++---
 xen/include/xen/libelf.h          |    2 +-
 5 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 4d7b8e0..2e69559 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -310,9 +310,15 @@ static int xc_dom_parse_elf_kernel(struct xc_dom_image *dom)
 static int xc_dom_load_elf_kernel(struct xc_dom_image *dom)
 {
     struct elf_binary *elf = dom->private_loader;
+    int rc;
 
     elf->dest = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
-    elf_load_binary(elf);
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+    {
+        DOMPRINTF("%s: failed to load elf binary", __FUNCTION__);
+        return rc;
+    }
     if ( dom->parms.bsd_symtab )
         xc_dom_load_elf_symtab(dom, elf, 1);
     return 0;
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 9831bab..1fa5658 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -109,8 +109,9 @@ static int loadelfimage(
     elf->dest += elf->pstart & (PAGE_SIZE - 1);
 
     /* Load the initial elf image. */
-    elf_load_binary(elf);
-    rc = 0;
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
 
     munmap(elf->dest, pages << PAGE_SHIFT);
     elf->dest = NULL;
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 1b3818f..b3c5d4c 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -903,7 +903,12 @@ int __init construct_dom0(
 
     /* Copy the OS image and free temporary buffer. */
     elf.dest = (void*)vkern_start;
-    elf_load_binary(&elf);
+    rc = elf_load_binary(&elf);
+    if ( rc < 0 )
+    {
+        printk("Failed to load the kernel binary\n");
+        return rc;
+    }
     bootstrap_map(NULL);
 
     if ( UNSET_ADDR != parms.virt_hypercall )
diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..4cdb03b 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,32 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+    return 0;
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    int rc;
+    rc = raw_copy_to_guest(dst, src, filesz);
+    if ( rc != 0 )
+        return -rc;
+    rc = raw_clear_guest(dst + filesz, memsz - filesz);
+    if ( rc != 0 )
+        return -rc;
+    return 0;
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -237,7 +258,7 @@ void elf_parse_binary(struct elf_binary *elf)
             __FUNCTION__, elf->pstart, elf->pend);
 }
 
-void elf_load_binary(struct elf_binary *elf)
+int elf_load_binary(struct elf_binary *elf)
 {
     const elf_phdr *phdr;
     uint64_t i, count, paddr, offset, filesz, memsz;
@@ -256,11 +277,12 @@ 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);
+        if ( elf_load_image(dest, elf->image + offset, filesz, memsz) != 0 )
+            return -1;
     }
 
     elf_load_bsdsyms(elf);
+    return 0;
 }
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d77bda6 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -198,7 +198,7 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback*,
 #endif
 
 void elf_parse_binary(struct elf_binary *elf);
-void elf_load_binary(struct elf_binary *elf);
+int elf_load_binary(struct elf_binary *elf);
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr);
 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 Mon Jan 09 18:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWG-0005kL-9u; Mon, 09 Jan 2012 18:00:28 +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 1RkJWD-0005es-Nx
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17653 invoked from network); 9 Jan 2012 18:00:19 -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;
	9 Jan 2012 18:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692294"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu8002699;
	Mon, 9 Jan 2012 10:00:01 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:49 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 d77bda6..0ff8b5b 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 Mon Jan 09 18:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWG-0005kL-9u; Mon, 09 Jan 2012 18:00:28 +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 1RkJWD-0005es-Nx
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17653 invoked from network); 9 Jan 2012 18:00:19 -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;
	9 Jan 2012 18:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692294"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu8002699;
	Mon, 9 Jan 2012 10:00:01 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:49 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 d77bda6..0ff8b5b 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 Mon Jan 09 18:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWF-0005jE-4O; Mon, 09 Jan 2012 18:00:27 +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 1RkJWD-0005eE-14
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326132017!10182503!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8387 invoked from network); 9 Jan 2012 18:00:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692293"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu2002699;
	Mon, 9 Jan 2012 09:59:53 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:43 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWF-0005jE-4O; Mon, 09 Jan 2012 18:00:27 +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 1RkJWD-0005eE-14
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326132017!10182503!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8387 invoked from network); 9 Jan 2012 18:00:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692293"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu2002699;
	Mon, 9 Jan 2012 09:59:53 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:43 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWH-0005lM-48; Mon, 09 Jan 2012 18:00:29 +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 1RkJWE-0005fm-WE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326132017!10182503!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8493 invoked from network); 9 Jan 2012 18:00:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692303"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuB002699;
	Mon, 9 Jan 2012 10:00:06 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:52 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWH-0005lM-48; Mon, 09 Jan 2012 18:00:29 +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 1RkJWE-0005fm-WE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326132017!10182503!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8493 invoked from network); 9 Jan 2012 18:00:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692303"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuB002699;
	Mon, 9 Jan 2012 10:00:06 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:52 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWH-0005lq-GH; Mon, 09 Jan 2012 18:00:29 +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 1RkJWF-0005fr-4N
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17745 invoked from network); 9 Jan 2012 18:00:20 -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;
	9 Jan 2012 18:00:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692301"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00: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; Mon, 9 Jan 2012 13:00: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 q09Hxhu9002699;
	Mon, 9 Jan 2012 10:00:03 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:50 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWH-0005lq-GH; Mon, 09 Jan 2012 18:00:29 +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 1RkJWF-0005fr-4N
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17745 invoked from network); 9 Jan 2012 18:00:20 -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;
	9 Jan 2012 18:00:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692301"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00: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; Mon, 9 Jan 2012 13:00: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 q09Hxhu9002699;
	Mon, 9 Jan 2012 10:00:03 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:50 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWE-0005ik-M4; Mon, 09 Jan 2012 18:00:26 +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 1RkJWC-0005eD-VG
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17626 invoked from network); 9 Jan 2012 18:00:18 -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;
	9 Jan 2012 18:00:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692280"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59: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; Mon, 9 Jan 2012 12:59:51 -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 q09Hxhtu002699;
	Mon, 9 Jan 2012 09:59:44 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:37 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 52a63ef..1100517 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 Mon Jan 09 18:00:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWE-0005ik-M4; Mon, 09 Jan 2012 18:00:26 +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 1RkJWC-0005eD-VG
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326132015!10179018!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17626 invoked from network); 9 Jan 2012 18:00:18 -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;
	9 Jan 2012 18:00:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692280"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 12:59: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; Mon, 9 Jan 2012 12:59:51 -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 q09Hxhtu002699;
	Mon, 9 Jan 2012 09:59:44 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:37 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 52a63ef..1100517 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 Mon Jan 09 18:00:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWG-0005kq-Nr; Mon, 09 Jan 2012 18:00:28 +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 1RkJWE-0005f9-AF
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26318 invoked from network); 9 Jan 2012 18:00:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692299"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu7002699;
	Mon, 9 Jan 2012 10:00:00 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:48 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWG-0005kq-Nr; Mon, 09 Jan 2012 18:00:28 +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 1RkJWE-0005f9-AF
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26318 invoked from network); 9 Jan 2012 18:00:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692299"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu7002699;
	Mon, 9 Jan 2012 10:00:00 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:48 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWH-0005mR-V9; Mon, 09 Jan 2012 18:00:29 +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 1RkJWF-0005ft-Bq
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326132017!10182503!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8452 invoked from network); 9 Jan 2012 18:00:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692296"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu6002699;
	Mon, 9 Jan 2012 09:59:58 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:47 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWH-0005mR-V9; Mon, 09 Jan 2012 18:00:29 +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 1RkJWF-0005ft-Bq
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326132017!10182503!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8452 invoked from network); 9 Jan 2012 18:00:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692296"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09Hxhu6002699;
	Mon, 9 Jan 2012 09:59:58 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:47 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWK-0005qz-1L; Mon, 09 Jan 2012 18:00:32 +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 1RkJWG-0005gD-9u
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26362 invoked from network); 9 Jan 2012 18:00:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692304"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuC002699;
	Mon, 9 Jan 2012 10:00:07 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:53 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 v4:

- fix build for -wunused-values;


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..f721c54
--- /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), (void)(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 Mon Jan 09 18:00:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWK-0005qz-1L; Mon, 09 Jan 2012 18:00:32 +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 1RkJWG-0005gD-9u
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26362 invoked from network); 9 Jan 2012 18:00:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692304"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuC002699;
	Mon, 9 Jan 2012 10:00:07 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:53 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 v4:

- fix build for -wunused-values;


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..f721c54
--- /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), (void)(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 Mon Jan 09 18:00:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJWK-0005t5-VW; Mon, 09 Jan 2012 18:00:32 +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 1RkJWH-0005h2-KE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26428 invoked from network); 9 Jan 2012 18:00:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692305"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuE002699;
	Mon, 9 Jan 2012 10:00:10 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:55 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJWK-0005t5-VW; Mon, 09 Jan 2012 18:00:32 +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 1RkJWH-0005h2-KE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26428 invoked from network); 9 Jan 2012 18:00:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692305"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuE002699;
	Mon, 9 Jan 2012 10:00:10 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:55 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJWM-0005vy-EG; Mon, 09 Jan 2012 18:00:34 +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 1RkJWK-0005j3-Bc
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26517 invoked from network); 9 Jan 2012 18:00:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692308"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuG002699;
	Mon, 9 Jan 2012 10:00:13 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:57 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJWM-0005vy-EG; Mon, 09 Jan 2012 18:00:34 +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 1RkJWK-0005j3-Bc
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26517 invoked from network); 9 Jan 2012 18:00:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692308"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuG002699;
	Mon, 9 Jan 2012 10:00:13 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:57 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWL-0005uZ-LS; Mon, 09 Jan 2012 18:00: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 1RkJWI-0005hg-M5
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15229 invoked from network); 9 Jan 2012 18:00:24 -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;
	9 Jan 2012 18:00:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802479"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q09HxhuF002699;
	Mon, 9 Jan 2012 10:00:12 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:56 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWL-0005uZ-LS; Mon, 09 Jan 2012 18:00: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 1RkJWI-0005hg-M5
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15229 invoked from network); 9 Jan 2012 18:00:24 -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;
	9 Jan 2012 18:00:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802479"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q09HxhuF002699;
	Mon, 9 Jan 2012 10:00:12 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:56 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWP-00061P-DS; Mon, 09 Jan 2012 18:00:37 +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 1RkJWM-0005lj-Nf
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15358 invoked from network); 9 Jan 2012 18:00:27 -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;
	9 Jan 2012 18:00:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802484"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuH002699;
	Mon, 9 Jan 2012 10:00:14 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:58 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWP-00061P-DS; Mon, 09 Jan 2012 18:00:37 +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 1RkJWM-0005lj-Nf
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15358 invoked from network); 9 Jan 2012 18:00:27 -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;
	9 Jan 2012 18:00:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802484"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuH002699;
	Mon, 9 Jan 2012 10:00:14 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:58 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWR-00065J-HD; Mon, 09 Jan 2012 18:00:39 +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 1RkJWO-0005o5-3R
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26616 invoked from network); 9 Jan 2012 18:00:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692310"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuI002699;
	Mon, 9 Jan 2012 10:00:16 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:59 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWR-00065J-HD; Mon, 09 Jan 2012 18:00:39 +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 1RkJWO-0005o5-3R
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326132018!10195094!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTUyMTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26616 invoked from network); 9 Jan 2012 18:00:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="20692310"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuI002699;
	Mon, 9 Jan 2012 10:00:16 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 17:59:59 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWS-00066B-4X; Mon, 09 Jan 2012 18:00:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJWQ-0005tl-Ib
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!10
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15747 invoked from network); 9 Jan 2012 18:00:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802486"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuJ002699;
	Mon, 9 Jan 2012 10:00:17 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 18:00:00 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWS-00066B-4X; Mon, 09 Jan 2012 18:00:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJWQ-0005tl-Ib
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!10
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15747 invoked from network); 9 Jan 2012 18:00:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:00:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802486"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuJ002699;
	Mon, 9 Jan 2012 10:00:17 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 18:00:00 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWT-00068s-Bm; Mon, 09 Jan 2012 18:00:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJWQ-0005ue-Vm
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!11
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15797 invoked from network); 9 Jan 2012 18:00:31 -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;
	9 Jan 2012 18:00:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802490"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuK002699;
	Mon, 9 Jan 2012 10:00:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 18:00:01 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:00:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJWT-00068s-Bm; Mon, 09 Jan 2012 18:00:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJWQ-0005ue-Vm
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:00:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326131992!2177818!11
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15797 invoked from network); 9 Jan 2012 18:00:31 -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;
	9 Jan 2012 18:00:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176802490"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:00:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 13:00: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 q09HxhuK002699;
	Mon, 9 Jan 2012 10:00:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 9 Jan 2012 18:00:01 +0000
Message-ID: <1326132001-21251-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.1201091752280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	JBeulich@suse.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v4 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 Mon Jan 09 18:08:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJdo-000115-NE; Mon, 09 Jan 2012 18:08:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkJdn-00010x-B1
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:08:15 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326132488!8414587!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDg4MjU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18283 invoked from network); 9 Jan 2012 18:08:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	9 Jan 2012 18:08: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 q09I804K021094
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 13:08:00 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q09I7vZh012019; Mon, 9 Jan 2012 13:07:58 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Mon,  9 Jan 2012 19:07:56 +0100
Message-Id: <1326132476-10047-1-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-4-git-send-email-drjones@redhat.com>
References: <1325842991-4404-4-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3/4 v2] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Describe dom0 support in the config menu and supply help text for it.

v2 adds 'if EXPERT' to keep it out of the "standard" menu.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..31ec975 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support" if EXPERT
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:08:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJdo-000115-NE; Mon, 09 Jan 2012 18:08:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RkJdn-00010x-B1
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:08:15 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326132488!8414587!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDg4MjU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18283 invoked from network); 9 Jan 2012 18:08:09 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	9 Jan 2012 18:08: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 q09I804K021094
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 13:08:00 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q09I7vZh012019; Mon, 9 Jan 2012 13:07:58 -0500
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Date: Mon,  9 Jan 2012 19:07:56 +0100
Message-Id: <1326132476-10047-1-git-send-email-drjones@redhat.com>
In-Reply-To: <1325842991-4404-4-git-send-email-drjones@redhat.com>
References: <1325842991-4404-4-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, virtualization@lists.linux-foundation.org,
	Ian.Campbell@citrix.com, stefano.stabellini@eu.citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 3/4 v2] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Describe dom0 support in the config menu and supply help text for it.

v2 adds 'if EXPERT' to keep it out of the "standard" menu.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..31ec975 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support" if EXPERT
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:12:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 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 1RkJhi-0001Ah-Qz; Mon, 09 Jan 2012 18:12:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJhg-0001AV-RO
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:12:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326132730!10241590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25270 invoked from network); 9 Jan 2012 18:12:11 -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 Jan 2012 18:12:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 18:12:10 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 18:12:10 +0000
Date: Mon, 9 Jan 2012 18:12:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120109170418.GD28700@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201091808460.3150@kaball-desktop>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
	<20120109145648.GA25563@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
	<20120109170418.GD28700@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 09, 2012 at 04:12:10PM +0000, Stefano Stabellini wrote:
> > On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> > > > I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
> > > > X86_IO_APIC && ACPI && PCI" to XEN either.
> > > > However it should be possible to add only the right dependencies to the
> > > > right places.
> > > > In practice it should be sufficient to:
> > > > 
> > > > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> > > 
> > > Not good. You can make non-ACPI builds with PCI.
> > > 
> > > .. and you are missing CONFIG_PCI in there.
> > > > 
> > > > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;
> > > 
> > > OK. That sounds good.
> > > > 
> > > > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> > > 
> > > No.. same issue - non-ACPI builds can be with PCI.
> > > > 
> > 
> > Right.. in that case we should carefully replace the 'ifdef
> > CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.
> 
> .. which I think I did at some point as part of cleanup and then
> removed them since it peppered the xen.c with tons of #ifdef CONFIG_ACPI.

that's unfortunate


> What about PVonHVM. There is this nagging feeling in the back of my
> head that turning CONFIG_XEN_DOM0 disables the CONFIG_PVHVM option?
> Or something like that? Maybe it is the other way around?

nope, nothing I can think of.


> It would seem we need to seperate the PVHVM  from DOM0. But the extra
> complexity comes with Mukesh's PVonHVM Hybrid which can do dom0 stuff
> with PVonHVM (should be searchable on xen-devel to find the patches).

I think that at the moment PVHVM and DOM0 aren't tie to one another in
any way, apart from the fact that they use the same generic
infrastructure to remap interrupts and MSIs into event channels.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:12:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 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 1RkJhi-0001Ah-Qz; Mon, 09 Jan 2012 18:12:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkJhg-0001AV-RO
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:12:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326132730!10241590!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25270 invoked from network); 9 Jan 2012 18:12:11 -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 Jan 2012 18:12:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; 
   d="scan'208";a="9903917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 18:12:10 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 18:12:10 +0000
Date: Mon, 9 Jan 2012 18:12:14 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120109170418.GD28700@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201091808460.3150@kaball-desktop>
References: <d6148ae9-932e-4fba-947e-ee70b2e25fd2@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091054111.3150@kaball-desktop>
	<20120109145648.GA25563@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201091532420.3150@kaball-desktop>
	<20120109170418.GD28700@phenom.dumpdata.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 09, 2012 at 04:12:10PM +0000, Stefano Stabellini wrote:
> > On Mon, 9 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Jan 09, 2012 at 11:39:44AM +0000, Stefano Stabellini wrote:
> > > > I don't think we should add "PCI_XEN && SWIOTLB_XEN && X86_LOCAL_APIC &&
> > > > X86_IO_APIC && ACPI && PCI" to XEN either.
> > > > However it should be possible to add only the right dependencies to the
> > > > right places.
> > > > In practice it should be sufficient to:
> > > > 
> > > > - make PCI_XEN depend on X86_LOCAL_APIC && X86_IO_APIC && ACPI;
> > > 
> > > Not good. You can make non-ACPI builds with PCI.
> > > 
> > > .. and you are missing CONFIG_PCI in there.
> > > > 
> > > > - make XEN_PCIDEV_FRONTEND and XEN_PCIDEV_BACKEND depend on PCI_XEN;
> > > 
> > > OK. That sounds good.
> > > > 
> > > > - remove the 'ifdef CONFIG_ACPI' from arch/x86/pci/xen.c.
> > > 
> > > No.. same issue - non-ACPI builds can be with PCI.
> > > > 
> > 
> > Right.. in that case we should carefully replace the 'ifdef
> > CONFIG_XEN_DOM0' with 'ifdef CONFIG_ACPI' in arch/x86/pci/xen.c.
> 
> .. which I think I did at some point as part of cleanup and then
> removed them since it peppered the xen.c with tons of #ifdef CONFIG_ACPI.

that's unfortunate


> What about PVonHVM. There is this nagging feeling in the back of my
> head that turning CONFIG_XEN_DOM0 disables the CONFIG_PVHVM option?
> Or something like that? Maybe it is the other way around?

nope, nothing I can think of.


> It would seem we need to seperate the PVHVM  from DOM0. But the extra
> complexity comes with Mukesh's PVonHVM Hybrid which can do dom0 stuff
> with PVonHVM (should be searchable on xen-devel to find the patches).

I think that at the moment PVHVM and DOM0 aren't tie to one another in
any way, apart from the fact that they use the same generic
infrastructure to remap interrupts and MSIs into event channels.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:20:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJpS-0001Qq-8k; Mon, 09 Jan 2012 18:20:18 +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 1RkJpQ-0001Ql-5b
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:20:16 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326133208!10188103!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjIzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10754 invoked from network); 9 Jan 2012 18:20:09 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 18:20:09 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 09 Jan 2012 10:20:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110346732"
Received: from unknown (HELO [127.0.0.1]) ([10.239.44.103])
	by fmsmga002.fm.intel.com with ESMTP; 09 Jan 2012 10:20:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: fe8d0ca867aa280cbfb38ab338cc6f9621366f4a
Message-Id: <fe8d0ca867aa280cbfb3.1326104556@wsm-ep-n0>
User-Agent: Mercurial-patchbomb/1.4
Date: Mon, 09 Jan 2012 05:22:36 -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

Updated the warning sentence for ratelimit_us.

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>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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"
+               "Setting ratelimit_us to 1000 * tslice_ms\n");
+        prv->ratelimit_us = 1000 * prv->tslice_ms;
+    }
+    else
+        prv->ratelimit_us = sched_ratelimit_us;
     return 0;
 }
 
diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/schedule.c	Mon Jan 09 05:21:35 2012 -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 fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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 fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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 Jan 09 18:20:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJpS-0001Qq-8k; Mon, 09 Jan 2012 18:20:18 +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 1RkJpQ-0001Ql-5b
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:20:16 +0000
X-Env-Sender: hui.lv@intel.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326133208!10188103!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjIzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10754 invoked from network); 9 Jan 2012 18:20:09 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-10.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 18:20:09 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 09 Jan 2012 10:20:07 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110346732"
Received: from unknown (HELO [127.0.0.1]) ([10.239.44.103])
	by fmsmga002.fm.intel.com with ESMTP; 09 Jan 2012 10:20:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: fe8d0ca867aa280cbfb38ab338cc6f9621366f4a
Message-Id: <fe8d0ca867aa280cbfb3.1326104556@wsm-ep-n0>
User-Agent: Mercurial-patchbomb/1.4
Date: Mon, 09 Jan 2012 05:22:36 -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

Updated the warning sentence for ratelimit_us.

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>

Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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"
+               "Setting ratelimit_us to 1000 * tslice_ms\n");
+        prv->ratelimit_us = 1000 * prv->tslice_ms;
+    }
+    else
+        prv->ratelimit_us = sched_ratelimit_us;
     return 0;
 }
 
diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
--- a/xen/common/schedule.c	Fri Dec 16 18:46:27 2011 +0000
+++ b/xen/common/schedule.c	Mon Jan 09 05:21:35 2012 -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 fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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 fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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 Jan 09 18:26:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJv4-0001cO-2W; Mon, 09 Jan 2012 18:26: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 1RkJv2-0001cC-MM
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:26:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326133556!10299225!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5404 invoked from network); 9 Jan 2012 18:25:58 -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 Jan 2012 18:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176807260"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:25: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; Mon, 9 Jan 2012
	13:25:55 -0500
Message-ID: <4F0B3132.5080601@citrix.com>
Date: Mon, 9 Jan 2012 18:25: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.1201091752280.3150@kaball-desktop>
	<1326132001-21251-23-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326132001-21251-23-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Tim.Deegan@citrix.com, JBeulich@suse.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> 
> +static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> +{
[...]
> +    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;

This needs to return 1 or recent kernels will crash when they try and
read these registers.

David

>From 8c2377a9b4a10cba57fba9f8a19177ac73339d78 Mon Sep 17 00:00:00 2001
From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 9 Jan 2012 15:17:22 +0000
Subject: [PATCH] ARM: allow guest to read GICD_ICFGRn registers

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/vgic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 26eae55..584e682 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -266,7 +266,7 @@ static int vgic_distr_mmio_read(struct vcpu *v,
mmio_info_t *info)
         vgic_lock_rank(v, rank);
         *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
         vgic_unlock_rank(v, rank);
-        return 0;
+        return 1;

     case GICD_NSACR ... GICD_NSACRN:
         /* We do not implement securty extensions for guests, read zero */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:26:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:26:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkJv4-0001cO-2W; Mon, 09 Jan 2012 18:26: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 1RkJv2-0001cC-MM
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:26:04 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326133556!10299225!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5404 invoked from network); 9 Jan 2012 18:25:58 -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 Jan 2012 18:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176807260"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:25: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; Mon, 9 Jan 2012
	13:25:55 -0500
Message-ID: <4F0B3132.5080601@citrix.com>
Date: Mon, 9 Jan 2012 18:25: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.1201091752280.3150@kaball-desktop>
	<1326132001-21251-23-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326132001-21251-23-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Tim.Deegan@citrix.com, JBeulich@suse.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> 
> +static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> +{
[...]
> +    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;

This needs to return 1 or recent kernels will crash when they try and
read these registers.

David

>From 8c2377a9b4a10cba57fba9f8a19177ac73339d78 Mon Sep 17 00:00:00 2001
From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 9 Jan 2012 15:17:22 +0000
Subject: [PATCH] ARM: allow guest to read GICD_ICFGRn registers

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/vgic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 26eae55..584e682 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -266,7 +266,7 @@ static int vgic_distr_mmio_read(struct vcpu *v,
mmio_info_t *info)
         vgic_lock_rank(v, rank);
         *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
         vgic_unlock_rank(v, rank);
-        return 0;
+        return 1;

     case GICD_NSACR ... GICD_NSACRN:
         /* We do not implement securty extensions for guests, read zero */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:30:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJym-0001pl-Qq; Mon, 09 Jan 2012 18:29:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RkJyk-0001pa-Uc
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:29:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326133787!8386604!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21674 invoked from network); 9 Jan 2012 18:29:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:29:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176807982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:29:46 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 9 Jan 2012
	13:29:46 -0500
Message-ID: <4F0B3218.5070101@citrix.com>
Date: Mon, 9 Jan 2012 18:29:44 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-13-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326132001-21251-13-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Tim.Deegan@citrix.com, JBeulich@suse.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> 
> +int construct_dom0(struct domain *d)
> +{
[...]
> +    printk("Routing peripheral interrupts to guest\n");
> +    /* TODO Get from device tree */

Can you route interrupt 34 (timer0) to dom0 as well?  Current mainline
kernels are using this timer.

David

>From 88148e85b2d8d9bf60564d4b5eb2ac73d8389fa5 Mon Sep 17 00:00:00 2001
From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 9 Jan 2012 15:21:37 +0000
Subject: [PATCH] ARM: route timer0 interrupt to dom0

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c36b888..cbbc0b9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -108,6 +108,7 @@ int construct_dom0(struct domain *d)

     printk("Routing peripheral interrupts to guest\n");
     /* TODO Get from device tree */
+    gic_route_irq_to_guest(d, 34, "timer0");
     /*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");
-- 
1.7.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 Jan 09 18:30:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkJym-0001pl-Qq; Mon, 09 Jan 2012 18:29:56 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1RkJyk-0001pa-Uc
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:29:55 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326133787!8386604!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjk3MTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21674 invoked from network); 9 Jan 2012 18:29:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 18:29:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320642000"; d="scan'208";a="176807982"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 13:29:46 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 9 Jan 2012
	13:29:46 -0500
Message-ID: <4F0B3218.5070101@citrix.com>
Date: Mon, 9 Jan 2012 18:29:44 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-13-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326132001-21251-13-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Tim.Deegan@citrix.com, JBeulich@suse.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> 
> +int construct_dom0(struct domain *d)
> +{
[...]
> +    printk("Routing peripheral interrupts to guest\n");
> +    /* TODO Get from device tree */

Can you route interrupt 34 (timer0) to dom0 as well?  Current mainline
kernels are using this timer.

David

>From 88148e85b2d8d9bf60564d4b5eb2ac73d8389fa5 Mon Sep 17 00:00:00 2001
From: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 9 Jan 2012 15:21:37 +0000
Subject: [PATCH] ARM: route timer0 interrupt to dom0

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c36b888..cbbc0b9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -108,6 +108,7 @@ int construct_dom0(struct domain *d)

     printk("Routing peripheral interrupts to guest\n");
     /* TODO Get from device tree */
+    gic_route_irq_to_guest(d, 34, "timer0");
     /*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");
-- 
1.7.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 Jan 09 18:35:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkK3g-00026b-Rx; Mon, 09 Jan 2012 18:35:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>)
	id 1RkK3g-00026F-2u; Mon, 09 Jan 2012 18:35:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326134091!8421195!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc2OTk2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 371 invoked from network); 9 Jan 2012 18:34:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 18:34: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
	q09IYof6014970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 18:34:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q09IYnQn005217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 18:34:49 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
	q09IYndd022710; Mon, 9 Jan 2012 12:34:49 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 10:34:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2F74E40944; Mon,  9 Jan 2012 13:33:04 -0500 (EST)
Date: Mon, 9 Jan 2012 13:33:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Message-ID: <20120109183304.GA1287@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F0B334B.0016,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] Features and bug fixes for Linux kernel 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

Hey,

Linux 3.3 merge window opened last week and today I've asked Linus
to pulled some of the patches. This is what is going in through
the Xen tree:

 - SysFS documentation updates. We are slowly updating them to make sure that the SysFS
   entires are properly documented.
 - Making the grant system able to use more fancier types of grants to speed-up
   guest to guest exchange of data (sub-page and transitive grants).
 - Updates in the backends to be able to export the Xen backends in an
   Hardware Virtualized Management (HVM) guest. We usually export those backends in
   the initial domain (dom0), but are moving slowly to make it possible to do it any guest
   (PV or HVM). NOTE: Only the netback version is in. The blkback needs an
   Ack from Jens Axboe and while I am sure he will provide it it might be past the
   merge window time-frame.
 - Better driver to deal with memory type ioctls calls. In the past we were doing
   ioctls on /proc/xen/priv_cmd (yuck) and with this are moving to doing it in
   /dev/xen/priv_cmd.
 - Fix a security issues were the guest could try to send a nasty (out of band)
   message and potentially cause mishap.
 - Remove duplicate initialization fields in the backend drivers.
 - Jeremy is now working for a fancy new startup so changing the MAINTAINERS file to
   reflect that his contribution are done during his private time.
 - Sensible config options. We had some that weren't all that good so adjusting
   them properly.
 - Bug-fixes, fixing a bug in xen-pciback with the "Ownership but beware" bug.

In the Dave Airlie tree (DRM, graphics) the TTM DMA backend is going in. It allows the TTM
to pre-allocate (and setup DMA for them) the pages for graphics (similar to how network
layers do it) before using them. This means that both radeon and nouveau 32-bit cards
can now work properly with Xen, so that ATI ES1000 found in most server boxes will now
run X. 64-bit cards work just fine.

Full credit is as follow:

Annie Li (7):
      xen/granttable: Introducing grant table V2 stucture
      xen/granttable: Refactor some code
      xen/granttable: Grant tables V2 implementation
      xen/granttable: Keep code format clean
      xen/granttable: Improve comments for function pointers
      xen/granttable: Support sub-page grants
      xen/granttable: Support transitive grants

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

Daniel De Graaf (10):
      xen/gntalloc: Change gref_lock to a mutex
      xen/gnt{dev,alloc}: reserve event channels for notify
      xen/event: Add reference counting to event channels
      xen/events: prevent calling evtchn_get on invalid channels
      xen/gntalloc: release grant references on page free
      xen/gntalloc: fix reference counts on multi-page mappings
      xenbus: Support HVM backends
      xenbus: Use grant-table wrapper functions
      xen/grant-table: Support mappings required by blkback
      xen/netback: Enable netback on HVM guests

David Vrabel (2):
      xen: document balloon driver sysfs files
      xen: document backend sysfs files

Ian Campbell (3):
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      xenbus: maximum buffer size is XENSTORE_PAYLOAD_MAX
      xen/xenbus: don't reimplement kvasprintf via a fixed size buffer

Jan Beulich (1):
      Xen: consolidate and simplify struct xenbus_driver instantiation

Jeremy Fitzhardinge (1):
      Xen: update MAINTAINER info

Julia Lawall (1):
      xen-gntalloc: introduce missing kfree

Konrad Rzeszutek Wilk (7):
      Merge branch 'stable/docs-for-3.3' into stable/for-linus-3.3
      xen/xenbus-frontend: Fix compile error with randconfig
      Merge commit 'v3.2-rc3' into stable/for-linus-3.3
      xen/xenbus: Fix compile error - missing header for xen_initial_domain()
      xen/pciback: Move the PCI_DEV_FLAGS_ASSIGNED ops to the "[un|]bind"
      xen/pciback: Fix "device has been assigned to X domain!" warning
      xen/pciback: Expand the warning message to include domain id.

Maxim Uvarov (1):
      xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible defaults

Tony Luck (1):
      xen/ia64: fix build breakage because of conflicting u64 guest handles


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:35:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18: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 1RkK3g-00026b-Rx; Mon, 09 Jan 2012 18:35:00 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>)
	id 1RkK3g-00026F-2u; Mon, 09 Jan 2012 18:35:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326134091!8421195!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc2OTk2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 371 invoked from network); 9 Jan 2012 18:34:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 18:34: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
	q09IYof6014970
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 18:34:50 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q09IYnQn005217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 18:34:49 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
	q09IYndd022710; Mon, 9 Jan 2012 12:34:49 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 10:34:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 2F74E40944; Mon,  9 Jan 2012 13:33:04 -0500 (EST)
Date: Mon, 9 Jan 2012 13:33:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Message-ID: <20120109183304.GA1287@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F0B334B.0016,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] Features and bug fixes for Linux kernel 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

Hey,

Linux 3.3 merge window opened last week and today I've asked Linus
to pulled some of the patches. This is what is going in through
the Xen tree:

 - SysFS documentation updates. We are slowly updating them to make sure that the SysFS
   entires are properly documented.
 - Making the grant system able to use more fancier types of grants to speed-up
   guest to guest exchange of data (sub-page and transitive grants).
 - Updates in the backends to be able to export the Xen backends in an
   Hardware Virtualized Management (HVM) guest. We usually export those backends in
   the initial domain (dom0), but are moving slowly to make it possible to do it any guest
   (PV or HVM). NOTE: Only the netback version is in. The blkback needs an
   Ack from Jens Axboe and while I am sure he will provide it it might be past the
   merge window time-frame.
 - Better driver to deal with memory type ioctls calls. In the past we were doing
   ioctls on /proc/xen/priv_cmd (yuck) and with this are moving to doing it in
   /dev/xen/priv_cmd.
 - Fix a security issues were the guest could try to send a nasty (out of band)
   message and potentially cause mishap.
 - Remove duplicate initialization fields in the backend drivers.
 - Jeremy is now working for a fancy new startup so changing the MAINTAINERS file to
   reflect that his contribution are done during his private time.
 - Sensible config options. We had some that weren't all that good so adjusting
   them properly.
 - Bug-fixes, fixing a bug in xen-pciback with the "Ownership but beware" bug.

In the Dave Airlie tree (DRM, graphics) the TTM DMA backend is going in. It allows the TTM
to pre-allocate (and setup DMA for them) the pages for graphics (similar to how network
layers do it) before using them. This means that both radeon and nouveau 32-bit cards
can now work properly with Xen, so that ATI ES1000 found in most server boxes will now
run X. 64-bit cards work just fine.

Full credit is as follow:

Annie Li (7):
      xen/granttable: Introducing grant table V2 stucture
      xen/granttable: Refactor some code
      xen/granttable: Grant tables V2 implementation
      xen/granttable: Keep code format clean
      xen/granttable: Improve comments for function pointers
      xen/granttable: Support sub-page grants
      xen/granttable: Support transitive grants

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

Daniel De Graaf (10):
      xen/gntalloc: Change gref_lock to a mutex
      xen/gnt{dev,alloc}: reserve event channels for notify
      xen/event: Add reference counting to event channels
      xen/events: prevent calling evtchn_get on invalid channels
      xen/gntalloc: release grant references on page free
      xen/gntalloc: fix reference counts on multi-page mappings
      xenbus: Support HVM backends
      xenbus: Use grant-table wrapper functions
      xen/grant-table: Support mappings required by blkback
      xen/netback: Enable netback on HVM guests

David Vrabel (2):
      xen: document balloon driver sysfs files
      xen: document backend sysfs files

Ian Campbell (3):
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      xenbus: maximum buffer size is XENSTORE_PAYLOAD_MAX
      xen/xenbus: don't reimplement kvasprintf via a fixed size buffer

Jan Beulich (1):
      Xen: consolidate and simplify struct xenbus_driver instantiation

Jeremy Fitzhardinge (1):
      Xen: update MAINTAINER info

Julia Lawall (1):
      xen-gntalloc: introduce missing kfree

Konrad Rzeszutek Wilk (7):
      Merge branch 'stable/docs-for-3.3' into stable/for-linus-3.3
      xen/xenbus-frontend: Fix compile error with randconfig
      Merge commit 'v3.2-rc3' into stable/for-linus-3.3
      xen/xenbus: Fix compile error - missing header for xen_initial_domain()
      xen/pciback: Move the PCI_DEV_FLAGS_ASSIGNED ops to the "[un|]bind"
      xen/pciback: Fix "device has been assigned to X domain!" warning
      xen/pciback: Expand the warning message to include domain id.

Maxim Uvarov (1):
      xen: Make XEN_MAX_DOMAIN_MEMORY have more sensible defaults

Tony Luck (1):
      xen/ia64: fix build breakage because of conflicting u64 guest handles


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:44:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkKCc-0002aj-ML; Mon, 09 Jan 2012 18:44:14 +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 1RkKCb-0002ae-4M
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:44:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326134602!51810171!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7480 invoked from network); 9 Jan 2012 18:43:22 -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;
	9 Jan 2012 18:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320624000"; 
   d="scan'208";a="9904685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 18:44:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 18:44:12 +0000
Date: Mon, 9 Jan 2012 18:44:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <3f35c565-bcaf-49d2-ba46-c61ca95aa51b@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.DEB.2.00.1201091838490.3150@kaball-desktop>
References: <3f35c565-bcaf-49d2-ba46-c61ca95aa51b@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 9 Jan 2012, Andrew Jones wrote:
> I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in
> arch/x86/pci/xen.c it would be pretty easy to review for equivalence.
> Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere else and
> compile in the 3 files. I don't think it makes much sense to do it
> though. XEN_DOM0 keeps things tidier now and might be useful later.

we can keep things clean with the following:

#ifdef CONFIG_LOCAL_APIC && CONFIG_IO_APIC && CONFIG_ACPI && CONFIG_PCI_XEN

#define XEN_DOM0

#endif

in include/xen/xen.h.

So in the source files we can still '#ifdef XEN_DOM0', but at the same
time we can get rid of the build symbol: everybody wins.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 18:44:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 18:44:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkKCc-0002aj-ML; Mon, 09 Jan 2012 18:44:14 +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 1RkKCb-0002ae-4M
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:44:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326134602!51810171!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7480 invoked from network); 9 Jan 2012 18:43:22 -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;
	9 Jan 2012 18:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,481,1320624000"; 
   d="scan'208";a="9904685"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 18:44:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 18:44:12 +0000
Date: Mon, 9 Jan 2012 18:44:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Andrew Jones <drjones@redhat.com>
In-Reply-To: <3f35c565-bcaf-49d2-ba46-c61ca95aa51b@zmail13.collab.prod.int.phx2.redhat.com>
Message-ID: <alpine.DEB.2.00.1201091838490.3150@kaball-desktop>
References: <3f35c565-bcaf-49d2-ba46-c61ca95aa51b@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 9 Jan 2012, Andrew Jones wrote:
> I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in
> arch/x86/pci/xen.c it would be pretty easy to review for equivalence.
> Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere else and
> compile in the 3 files. I don't think it makes much sense to do it
> though. XEN_DOM0 keeps things tidier now and might be useful later.

we can keep things clean with the following:

#ifdef CONFIG_LOCAL_APIC && CONFIG_IO_APIC && CONFIG_ACPI && CONFIG_PCI_XEN

#define XEN_DOM0

#endif

in include/xen/xen.h.

So in the source files we can still '#ifdef XEN_DOM0', but at the same
time we can get rid of the build symbol: everybody wins.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 19:00:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 19: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 1RkKRg-0002u8-Kf; Mon, 09 Jan 2012 18:59:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <Stefan.Kuhne@gmx.net>) id 1RkKRf-0002tz-1v
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:59:47 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326135580!2869418!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNzQ4NjU=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15278 invoked from network); 9 Jan 2012 18:59:40 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-16.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 18:59:40 -0000
Received: (qmail invoked by alias); 09 Jan 2012 18:59:37 -0000
Received: from xdsl-78-34-137-57.netcologne.de (EHLO Earth.access.denied)
	[78.34.137.57]
	by mail.gmx.net (mp071) with SMTP; 09 Jan 2012 19:59:37 +0100
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX18WhT5YjOIWKfD97f2ObcMI0tzOMSeA662zS0vZv8
	mG18UAbDtC40Cn
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>)
	id 1RkKUh-000105-Q2; Mon, 09 Jan 2012 20:02:55 +0100
Message-ID: <4F0B38F8.6050305@access.denied>
Date: Mon, 09 Jan 2012 19:59:04 +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: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <20120109183304.GA1287@phenom.dumpdata.com>
In-Reply-To: <20120109183304.GA1287@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.4
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] Features and bug fixes for Linux kernel 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: multipart/mixed; boundary="===============2577449229972053826=="
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)
--===============2577449229972053826==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig1030E86724B077D1E5B1E767"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1030E86724B077D1E5B1E767
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am 09.01.2012 19:33, schrieb Konrad Rzeszutek Wilk:

Hello,

> Linux 3.3 merge window opened last week and today I've asked Linus
> to pulled some of the patches. This is what is going in through
> the Xen tree:
>=20
it sounds like no acpi/cpufreq Support in 3.3.
Is it rigth?

Regards,
Stefan Kuhne


--------------enig1030E86724B077D1E5B1E767
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/

iQEcBAEBAgAGBQJPCzj4AAoJEFLNPgL3IBVXmSMH/0dVPjv/nq2MoFCfacVG9tQI
Rb35lp24lX3hRakRbLdrKgyBOlD8qwXlk7ToHnbRdxu4N8aaIvd0QKqvWdIfiwhK
TxQefCYQLdBWe1i82TdUWE2HKVSjKIAt30JE5ypSg6bmYz/a/sEtjTN1OghK6XOm
zVo7AbZkwoLKDeYsFGtkC/Bawe7S0AP0AL04Uex6DO+TGMcj+5WkNT3uVy06T/DK
UNypLfePGANjp8cM5hLAkchIGn6GNjn9dU92Ve3VC6jiZ/2kTRsonM70EvpDIb/Z
lQEskS++U2dfcEuoBCH9c1hMt8XlhgDD8pe8pfpa6SICScFpTx7DrBydod/GNuE=
=qIkW
-----END PGP SIGNATURE-----

--------------enig1030E86724B077D1E5B1E767--


--===============2577449229972053826==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2577449229972053826==--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 19:00:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 19: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 1RkKRg-0002u8-Kf; Mon, 09 Jan 2012 18:59:48 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <Stefan.Kuhne@gmx.net>) id 1RkKRf-0002tz-1v
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:59:47 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326135580!2869418!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAxNzQ4NjU=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15278 invoked from network); 9 Jan 2012 18:59:40 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-16.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 18:59:40 -0000
Received: (qmail invoked by alias); 09 Jan 2012 18:59:37 -0000
Received: from xdsl-78-34-137-57.netcologne.de (EHLO Earth.access.denied)
	[78.34.137.57]
	by mail.gmx.net (mp071) with SMTP; 09 Jan 2012 19:59:37 +0100
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX18WhT5YjOIWKfD97f2ObcMI0tzOMSeA662zS0vZv8
	mG18UAbDtC40Cn
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>)
	id 1RkKUh-000105-Q2; Mon, 09 Jan 2012 20:02:55 +0100
Message-ID: <4F0B38F8.6050305@access.denied>
Date: Mon, 09 Jan 2012 19:59:04 +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: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <20120109183304.GA1287@phenom.dumpdata.com>
In-Reply-To: <20120109183304.GA1287@phenom.dumpdata.com>
X-Enigmail-Version: 1.3.4
X-Y-GMX-Trusted: 0
Subject: Re: [Xen-devel] Features and bug fixes for Linux kernel 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: multipart/mixed; boundary="===============2577449229972053826=="
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)
--===============2577449229972053826==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig1030E86724B077D1E5B1E767"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1030E86724B077D1E5B1E767
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am 09.01.2012 19:33, schrieb Konrad Rzeszutek Wilk:

Hello,

> Linux 3.3 merge window opened last week and today I've asked Linus
> to pulled some of the patches. This is what is going in through
> the Xen tree:
>=20
it sounds like no acpi/cpufreq Support in 3.3.
Is it rigth?

Regards,
Stefan Kuhne


--------------enig1030E86724B077D1E5B1E767
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/

iQEcBAEBAgAGBQJPCzj4AAoJEFLNPgL3IBVXmSMH/0dVPjv/nq2MoFCfacVG9tQI
Rb35lp24lX3hRakRbLdrKgyBOlD8qwXlk7ToHnbRdxu4N8aaIvd0QKqvWdIfiwhK
TxQefCYQLdBWe1i82TdUWE2HKVSjKIAt30JE5ypSg6bmYz/a/sEtjTN1OghK6XOm
zVo7AbZkwoLKDeYsFGtkC/Bawe7S0AP0AL04Uex6DO+TGMcj+5WkNT3uVy06T/DK
UNypLfePGANjp8cM5hLAkchIGn6GNjn9dU92Ve3VC6jiZ/2kTRsonM70EvpDIb/Z
lQEskS++U2dfcEuoBCH9c1hMt8XlhgDD8pe8pfpa6SICScFpTx7DrBydod/GNuE=
=qIkW
-----END PGP SIGNATURE-----

--------------enig1030E86724B077D1E5B1E767--


--===============2577449229972053826==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2577449229972053826==--


From xen-devel-bounces@lists.xensource.com Mon Jan 09 19:00:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 19:00:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkKRq-0002up-1M; Mon, 09 Jan 2012 18:59:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1RkKRo-0002uJ-TE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:59:57 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326135590!8966271!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26836 invoked from network); 9 Jan 2012 18:59:50 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 18:59:50 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 54844FE433
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 18:59:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=postfix; bh=IkCbovlLlM4bJgR/c2CWuw
	RV9rk=; b=qbUzUT36RXBwBX9KXvFSAcpfmoj8nebvJgr6uSAZu4LZkadgp8DOZO
	OYezUHZC15cdahs4QYaGRbLWEY/M2F5AKIot8nkr5WT/0mSKxiQJ0ZYKw2GvC3bJ
	qyfP64MH1tvgJ5cMQ7EL5qCj45Cvb9QClgOnhz8x4Tk3AhYo9AzeI=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; q=dns; s=postfix; b=uwoiBnORbfoJG5di
	SWvffz++10dYi9g+dkgmvqJWaWTcrd1HiscbD8LhvX8I1ulN5ynVg2V+WbmE2rdw
	HkRRTOd3DmNrNNfHfSLJliG8Ym1Kiys+yZbV/xjv9QRwmapOv1qxngzKra+ANuec
	iH/lkbG9VTa+CTt9/vZ9PzBnTHA=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id B9705FE3EC
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 18:59:53 +0000 (UTC)
Message-ID: <4F0B3923.3060505@goirand.fr>
Date: Tue, 10 Jan 2012 02:59:47 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.0.1
Subject: [Xen-devel] Xen anti-spoof firewall issue with routing on a 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: 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,

On one of our server, we have a VM which does BGP routing, and routes a
full class C (let's pretend the network is 12.34.56.0/24). I'm using Xen
4.0 from Debian Squeeze (unmodified package). We use, in
/etc/xen/xend-config.sxp:

(network-script 'network-bridge antispoof=yes')

The issue is that the anti-spoof firewall of Xen prevents the networking
to work for other VMs which will use 12.34.56.1 as gateway. If I do:

iptables -I INPUT -j ACCEPT
iptables -I FORWARD -j ACCEPT

of course, it does work, but that's not what I want. I really want to
have the anti-spoofing feature to be there. Also, if I add let's say
12.34.56.5 to the xen startup file of the VM that does the BGP routing,
it doesn't work (eg: 12.34.56.5, which is used by another VM, is still
not routed).

What's the solution here?

Also, is there a plan for ipv6 support on this anti-spoof firewall?

If there's things to contribute so that the above can be done, I'd be
happy to work on that, so that anti-spoofing can be done.

Last, if I switch to xl instead of xm, is there a way to still have the
anti-spoof feature which is so nice?

Cheers,

Thomas Goirand

P.S: Has anyone tried the new XCP packages available in Debian SID since
Christmas? I've uploaded last week-end v1.3-15 in SID, after a long work
with Mike and Jon on it, and I believe it works quite well now, but
feed-back would be appreciated! Please see the QA page:

http://qa.debian.org/developer.php?login=pkg-xen-devel@lists.alioth.debian.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 19:00:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 19:00:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkKRq-0002up-1M; Mon, 09 Jan 2012 18:59:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thomas@goirand.fr>) id 1RkKRo-0002uJ-TE
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 18:59:57 +0000
X-Env-Sender: thomas@goirand.fr
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326135590!8966271!1
X-Originating-IP: [117.121.247.104]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26836 invoked from network); 9 Jan 2012 18:59:50 -0000
Received: from mx.atlanta.gplhost.com (HELO mx.atlanta.gplhost.com)
	(117.121.247.104)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 18:59:50 -0000
Received: from mx.atlanta.gplhost.com (localhost.localdomain [127.0.0.1])
	by mx.atlanta.gplhost.com (Postfix) with ESMTP id 54844FE433
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 18:59:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; s=postfix; bh=IkCbovlLlM4bJgR/c2CWuw
	RV9rk=; b=qbUzUT36RXBwBX9KXvFSAcpfmoj8nebvJgr6uSAZu4LZkadgp8DOZO
	OYezUHZC15cdahs4QYaGRbLWEY/M2F5AKIot8nkr5WT/0mSKxiQJ0ZYKw2GvC3bJ
	qyfP64MH1tvgJ5cMQ7EL5qCj45Cvb9QClgOnhz8x4Tk3AhYo9AzeI=
DomainKey-Signature: a=rsa-sha1; c=simple; d=goirand.fr; h=message-id
	:date:from:mime-version:to:subject:content-type
	:content-transfer-encoding; q=dns; s=postfix; b=uwoiBnORbfoJG5di
	SWvffz++10dYi9g+dkgmvqJWaWTcrd1HiscbD8LhvX8I1ulN5ynVg2V+WbmE2rdw
	HkRRTOd3DmNrNNfHfSLJliG8Ym1Kiys+yZbV/xjv9QRwmapOv1qxngzKra+ANuec
	iH/lkbG9VTa+CTt9/vZ9PzBnTHA=
Received: from [127.0.0.1] (atl.apt-proxy.gplhost.com [117.121.247.20])
	by mx.atlanta.gplhost.com (Postfix) with ESMTPA id B9705FE3EC
	for <xen-devel@lists.xensource.com>;
	Mon,  9 Jan 2012 18:59:53 +0000 (UTC)
Message-ID: <4F0B3923.3060505@goirand.fr>
Date: Tue, 10 Jan 2012 02:59:47 +0800
From: Thomas Goirand <thomas@goirand.fr>
Organization: GPLHost
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.0.1
Subject: [Xen-devel] Xen anti-spoof firewall issue with routing on a 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: 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,

On one of our server, we have a VM which does BGP routing, and routes a
full class C (let's pretend the network is 12.34.56.0/24). I'm using Xen
4.0 from Debian Squeeze (unmodified package). We use, in
/etc/xen/xend-config.sxp:

(network-script 'network-bridge antispoof=yes')

The issue is that the anti-spoof firewall of Xen prevents the networking
to work for other VMs which will use 12.34.56.1 as gateway. If I do:

iptables -I INPUT -j ACCEPT
iptables -I FORWARD -j ACCEPT

of course, it does work, but that's not what I want. I really want to
have the anti-spoofing feature to be there. Also, if I add let's say
12.34.56.5 to the xen startup file of the VM that does the BGP routing,
it doesn't work (eg: 12.34.56.5, which is used by another VM, is still
not routed).

What's the solution here?

Also, is there a plan for ipv6 support on this anti-spoof firewall?

If there's things to contribute so that the above can be done, I'd be
happy to work on that, so that anti-spoofing can be done.

Last, if I switch to xl instead of xm, is there a way to still have the
anti-spoof feature which is so nice?

Cheers,

Thomas Goirand

P.S: Has anyone tried the new XCP packages available in Debian SID since
Christmas? I've uploaded last week-end v1.3-15 in SID, after a long work
with Mike and Jon on it, and I believe it works quite well now, but
feed-back would be appreciated! Please see the QA page:

http://qa.debian.org/developer.php?login=pkg-xen-devel@lists.alioth.debian.org

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 19:21:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 19:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkKmg-0003RL-01; Mon, 09 Jan 2012 19:21: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 1RkKme-0003RG-CI
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 19:21:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326136881!10299763!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17962 invoked from network); 9 Jan 2012 19:21:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 19:21:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326136881; l=4218;
	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=btqQaHprHrzqIL+vQ9KgAKjQG+E=;
	b=jpmeFiFjQXVYZ/7elZ6uHipMUkRXXd3uVv1hEQe2pSjd0irBczMCi8+sEnqyveF2sfe
	YP0bEi3g0aR/HMcZHtLoHELJ6ddUWj7xsAeaiKxjHfub7kgVyUSa61UNbfgn5pnodTxHY
	XZ7EPpDITUU5P8J861p/nLRhIccC2ip44as=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by post.strato.de (mrclete mo28) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 30147co09I6Q39 ;
	Mon, 9 Jan 2012 20:21:21 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 57A5B18637; Mon,  9 Jan 2012 20:21:20 +0100 (CET)
Date: Mon, 9 Jan 2012 20:21:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120109192119.GB10630@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
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 4 of 4] xenpaging: initial libxl 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

Lets resume this discussion now to get it sorted out for 4.2.

On Tue, Nov 22, George Dunlap wrote:

> On Mon, Nov 21, 2011 at 3:13 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Mon, Nov 21, Stefano Stabellini wrote:
> >
> >> what if tot_memkb is bigger than target_memkb? Or even bigger than
> >> max_memkb?
> >
> > tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> > max_memkb.
> 
> It seems to me the opposite: tot_memkb (as you're describing here) and
> target_memkb both mean, "How much Xen memory the administrator wants
> allocated to the VM."  Before either paging or PoD, the only way to
> modify the amount of memory allocated to a VM was via the balloon
> driver.  PoD introduced a mechanism that allows the domain builder to
> start a VM with less memory than static_max, and allow the VM to run
> until balloon driver can normalize things.    Paging introduces a
> separate mechanism for the administrator to modify the amount of
> memory allocated to the VM.
> 
> It seems to me like paging and ballooning should both use
> target_memkb.  We just need to figure out how to make sure that paging
> only comes on when it's needed.  When it might be needed includes:
> * For guests that don't have a balloon driver
> * For guests whose balloon driver is not meeting target_memkb (either
> because it's unresponsive, rebellious, or because it can't get more
> memory from the guest OS)
> * Potentially, between domain creation and the time the balloon driver
> comes up (i.e., replacing PoD).
> 
> It seems like having some kind of a flag or setting would be better.
> Various factors:
> * Do we start the paging daemon?
> * Do we use paging during boot?  Only matters if max_memkb !=
> target_memkb.  If no, the domain builder uses PoD mode.  If yes, the
> domain builder will fill in target_memkb worth of guest memory, and
> then fill the rest with swapped-out entries.  (If max_memkb ==
> target_memkb, domain builder fills in all entries.)
> * When does the paging daemon respond to changes to target_memkb?
> This could be:
>  - Immediately (assume no balloon driver)
>  - PoD mode: Start immediately, but when you notice the balloon driver
> reaching the initial target_memkb, turn off, or switch into the next
> mode
>  - Fallback mode: Pay attention to changes in target_memkb, but don't
> act immediately.  Wait for paging_delay secs for the balloon driver to
> handle it; if it doesn't respond, then start paging (and perhaps
> switch to "Immediately" mode).
> 
> What do you think?


So there is that maxmem= setting to let the guest OS configure itself
for a given amount of pseudo-physical memory. Then there is a way to cut
down the guest OS memory usage, both with balloon driver in guest and
later with PoD.
Isnt paging a better (or: just different) way to control the memory
usage of a guest OS (It costs diskspace in dom0)?
If a guest OS is configured with maxmem=4096, but then restricted with
memory=3072 in the next line, why is maxmem= there in the first place?
Would it clearer to say: The guest OS has a certain workload which
requires 3072MB. But maybe at some point the guest needs the full
4096MB, then it can access all of it at the cost of some IO due to
swapping in dom0.
I think the balloon driver in the guest is not really needed anymore, it
could just be there and do nothing. IF there is physical memory to
release to the host, the pager can do it on behalf of the balloon
driver.

What if the config format is like this:

Do things as they were done until now (PoD + balloon driver):
  memory=3072
  maxmem=4096
  paging=0 (or not specified at all)

Do things with pager instead of balloon driver and/or PoD:
  memory=3072
  maxmem=4096
  paging=1, or xenpaging=1
  xenpaging_extra=[ '-f', '/path/to/pagefile_guestname' ] (optional)

And have mem-set adjust memory/target-tot_pages to tell pager about the
new target. The builder could create some sort PoD for a paged guest so
that during startup only the amount of memory= needs to be allocated.
This needs to be implemented, right now a starting guest needs the full
amount of memory until the pager starts to page-out pages.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 19:21:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 19:21:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkKmg-0003RL-01; Mon, 09 Jan 2012 19:21: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 1RkKme-0003RG-CI
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 19:21:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326136881!10299763!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDQ1MTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17962 invoked from network); 9 Jan 2012 19:21:22 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 9 Jan 2012 19:21:22 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326136881; l=4218;
	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=btqQaHprHrzqIL+vQ9KgAKjQG+E=;
	b=jpmeFiFjQXVYZ/7elZ6uHipMUkRXXd3uVv1hEQe2pSjd0irBczMCi8+sEnqyveF2sfe
	YP0bEi3g0aR/HMcZHtLoHELJ6ddUWj7xsAeaiKxjHfub7kgVyUSa61UNbfgn5pnodTxHY
	XZ7EPpDITUU5P8J861p/nLRhIccC2ip44as=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qETcM
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-137.pools.arcor-ip.net [84.57.90.137])
	by post.strato.de (mrclete mo28) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 30147co09I6Q39 ;
	Mon, 9 Jan 2012 20:21:21 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 57A5B18637; Mon,  9 Jan 2012 20:21:20 +0100 (CET)
Date: Mon, 9 Jan 2012 20:21:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <20120109192119.GB10630@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
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 4 of 4] xenpaging: initial libxl 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

Lets resume this discussion now to get it sorted out for 4.2.

On Tue, Nov 22, George Dunlap wrote:

> On Mon, Nov 21, 2011 at 3:13 PM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Mon, Nov 21, Stefano Stabellini wrote:
> >
> >> what if tot_memkb is bigger than target_memkb? Or even bigger than
> >> max_memkb?
> >
> > tot_memkb is unrelated to target_memkb, also somewhat unrelated to
> > max_memkb.
> 
> It seems to me the opposite: tot_memkb (as you're describing here) and
> target_memkb both mean, "How much Xen memory the administrator wants
> allocated to the VM."  Before either paging or PoD, the only way to
> modify the amount of memory allocated to a VM was via the balloon
> driver.  PoD introduced a mechanism that allows the domain builder to
> start a VM with less memory than static_max, and allow the VM to run
> until balloon driver can normalize things.    Paging introduces a
> separate mechanism for the administrator to modify the amount of
> memory allocated to the VM.
> 
> It seems to me like paging and ballooning should both use
> target_memkb.  We just need to figure out how to make sure that paging
> only comes on when it's needed.  When it might be needed includes:
> * For guests that don't have a balloon driver
> * For guests whose balloon driver is not meeting target_memkb (either
> because it's unresponsive, rebellious, or because it can't get more
> memory from the guest OS)
> * Potentially, between domain creation and the time the balloon driver
> comes up (i.e., replacing PoD).
> 
> It seems like having some kind of a flag or setting would be better.
> Various factors:
> * Do we start the paging daemon?
> * Do we use paging during boot?  Only matters if max_memkb !=
> target_memkb.  If no, the domain builder uses PoD mode.  If yes, the
> domain builder will fill in target_memkb worth of guest memory, and
> then fill the rest with swapped-out entries.  (If max_memkb ==
> target_memkb, domain builder fills in all entries.)
> * When does the paging daemon respond to changes to target_memkb?
> This could be:
>  - Immediately (assume no balloon driver)
>  - PoD mode: Start immediately, but when you notice the balloon driver
> reaching the initial target_memkb, turn off, or switch into the next
> mode
>  - Fallback mode: Pay attention to changes in target_memkb, but don't
> act immediately.  Wait for paging_delay secs for the balloon driver to
> handle it; if it doesn't respond, then start paging (and perhaps
> switch to "Immediately" mode).
> 
> What do you think?


So there is that maxmem= setting to let the guest OS configure itself
for a given amount of pseudo-physical memory. Then there is a way to cut
down the guest OS memory usage, both with balloon driver in guest and
later with PoD.
Isnt paging a better (or: just different) way to control the memory
usage of a guest OS (It costs diskspace in dom0)?
If a guest OS is configured with maxmem=4096, but then restricted with
memory=3072 in the next line, why is maxmem= there in the first place?
Would it clearer to say: The guest OS has a certain workload which
requires 3072MB. But maybe at some point the guest needs the full
4096MB, then it can access all of it at the cost of some IO due to
swapping in dom0.
I think the balloon driver in the guest is not really needed anymore, it
could just be there and do nothing. IF there is physical memory to
release to the host, the pager can do it on behalf of the balloon
driver.

What if the config format is like this:

Do things as they were done until now (PoD + balloon driver):
  memory=3072
  maxmem=4096
  paging=0 (or not specified at all)

Do things with pager instead of balloon driver and/or PoD:
  memory=3072
  maxmem=4096
  paging=1, or xenpaging=1
  xenpaging_extra=[ '-f', '/path/to/pagefile_guestname' ] (optional)

And have mem-set adjust memory/target-tot_pages to tell pager about the
new target. The builder could create some sort PoD for a paged guest so
that during startup only the amount of memory= needs to be allocated.
This needs to be implemented, right now a starting guest needs the full
amount of memory until the pager starts to page-out pages.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMYh-0004sF-OW; Mon, 09 Jan 2012 21:15:11 +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 1RkMYf-0004sA-W1
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:15:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326143702!10202858!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4MDg0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20018 invoked from network); 9 Jan 2012 21:15:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 21:15:03 -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
	q09LExnK025264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 21:15:00 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
	q09LEvOJ012790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 21:14:59 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
	q09LEvo2019084; Mon, 9 Jan 2012 15:14:57 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 13:14:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CBA1F40944; Mon,  9 Jan 2012 16:13:12 -0500 (EST)
Date: Mon, 9 Jan 2012 16:13:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Kuhne <stefan.kuhne@gmx.net>, liang tang <liang.tang@oracle.com>
Message-ID: <20120109211312.GB4773@phenom.dumpdata.com>
References: <20120109183304.GA1287@phenom.dumpdata.com>
	<4F0B38F8.6050305@access.denied>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0B38F8.6050305@access.denied>
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.4F0B58D4.00A0,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Features and bug fixes for Linux kernel 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 Mon, Jan 09, 2012 at 07:59:04PM +0100, Stefan Kuhne wrote:
> Am 09.01.2012 19:33, schrieb Konrad Rzeszutek Wilk:
> 
> Hello,
> 
> > Linux 3.3 merge window opened last week and today I've asked Linus
> > to pulled some of the patches. This is what is going in through
> > the Xen tree:
> > 
> it sounds like no acpi/cpufreq Support in 3.3.

Not yet. We started the discussion about the patches and we have an thought
of how to rework them. So it will have to wait :-(

> Is it rigth?

<nods> But the moment they are ready to be posted we will make sure you
are CC-ed on them. There will be undoubtly some bugs we haven't found
and you have this sixth sense in finding them :-)

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:15:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:15:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMYh-0004sF-OW; Mon, 09 Jan 2012 21:15:11 +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 1RkMYf-0004sA-W1
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:15:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326143702!10202858!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4MDg0MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20018 invoked from network); 9 Jan 2012 21:15:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 9 Jan 2012 21:15:03 -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
	q09LExnK025264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 21:15:00 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
	q09LEvOJ012790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 21:14:59 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
	q09LEvo2019084; Mon, 9 Jan 2012 15:14:57 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 13:14:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CBA1F40944; Mon,  9 Jan 2012 16:13:12 -0500 (EST)
Date: Mon, 9 Jan 2012 16:13:12 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefan Kuhne <stefan.kuhne@gmx.net>, liang tang <liang.tang@oracle.com>
Message-ID: <20120109211312.GB4773@phenom.dumpdata.com>
References: <20120109183304.GA1287@phenom.dumpdata.com>
	<4F0B38F8.6050305@access.denied>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0B38F8.6050305@access.denied>
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.4F0B58D4.00A0,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Features and bug fixes for Linux kernel 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 Mon, Jan 09, 2012 at 07:59:04PM +0100, Stefan Kuhne wrote:
> Am 09.01.2012 19:33, schrieb Konrad Rzeszutek Wilk:
> 
> Hello,
> 
> > Linux 3.3 merge window opened last week and today I've asked Linus
> > to pulled some of the patches. This is what is going in through
> > the Xen tree:
> > 
> it sounds like no acpi/cpufreq Support in 3.3.

Not yet. We started the discussion about the patches and we have an thought
of how to rework them. So it will have to wait :-(

> Is it rigth?

<nods> But the moment they are ready to be posted we will make sure you
are CC-ed on them. There will be undoubtly some bugs we haven't found
and you have this sixth sense in finding them :-)

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:18:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21: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 1RkMat-0004ww-9l; Mon, 09 Jan 2012 21:17: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 1RkMas-0004wi-8Y
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:17:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326143839!10292477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5359 invoked from network); 9 Jan 2012 21:17:19 -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 Jan 2012 21:17:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,482,1320624000"; 
   d="scan'208";a="9907289"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 21:17:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 21:17: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 1RkMak-0003Fo-M5;
	Mon, 09 Jan 2012 21:17:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RkMak-0007IP-G0;
	Mon, 09 Jan 2012 21:17:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10645-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Jan 2012 21:17:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10645: 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 10645 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10645/

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. 10644

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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   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-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b2676ac1321
baseline version:
 xen                  4086e4811547

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-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.

------------------------------------------------------------
changeset:   24465:5b2676ac1321
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 09 16:01:44 2012 +0100
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24464:a7c763a92ba1
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 09 15:59:59 2012 +0100
    
    PCI: properly abstract out per-architecture extensions to struct pci_dev
    
    x86's used_vectors member was both misplaced (in struct pci_dev_info,
    which acts as a hypercall input data passing container only) and
    improperly abstracted (requiring a CONFIG_X86 conditional in a generic
    header).
    
    The adjustment requires hiding several more lines in IA64's pci.h, but
    as a benefit this allows removing one of the "null" headers.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24463:bfbfd2006ffc
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 09 15:55:00 2012 +0100
    
    PCI: shrink pci_dev_info's is_extfn/is_virtfn members
    
    They are used as boolean flags only, so convert them accordingly
    (shrinking the structure size by 8 bytes).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24462:4086e4811547
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Jan 05 17:25:23 2012 +0000
    
    Update QEMU_TAG
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Mon Jan 09 21:18:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21: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 1RkMat-0004ww-9l; Mon, 09 Jan 2012 21:17: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 1RkMas-0004wi-8Y
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:17:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326143839!10292477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTk5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5359 invoked from network); 9 Jan 2012 21:17:19 -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 Jan 2012 21:17:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,482,1320624000"; 
   d="scan'208";a="9907289"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 21:17:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 9 Jan 2012 21:17: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 1RkMak-0003Fo-M5;
	Mon, 09 Jan 2012 21:17:18 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RkMak-0007IP-G0;
	Mon, 09 Jan 2012 21:17:18 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10645-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 9 Jan 2012 21:17:18 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10645: 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 10645 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10645/

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. 10644

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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   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-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b2676ac1321
baseline version:
 xen                  4086e4811547

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-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.

------------------------------------------------------------
changeset:   24465:5b2676ac1321
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 09 16:01:44 2012 +0100
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24464:a7c763a92ba1
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 09 15:59:59 2012 +0100
    
    PCI: properly abstract out per-architecture extensions to struct pci_dev
    
    x86's used_vectors member was both misplaced (in struct pci_dev_info,
    which acts as a hypercall input data passing container only) and
    improperly abstracted (requiring a CONFIG_X86 conditional in a generic
    header).
    
    The adjustment requires hiding several more lines in IA64's pci.h, but
    as a benefit this allows removing one of the "null" headers.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24463:bfbfd2006ffc
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 09 15:55:00 2012 +0100
    
    PCI: shrink pci_dev_info's is_extfn/is_virtfn members
    
    They are used as boolean flags only, so convert them accordingly
    (shrinking the structure size by 8 bytes).
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24462:4086e4811547
user:        Ian Jackson <Ian.Jackson@eu.citrix.com>
date:        Thu Jan 05 17:25:23 2012 +0000
    
    Update QEMU_TAG
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Mon Jan 09 21:33:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMpY-0005Hr-14; Mon, 09 Jan 2012 21:32:36 +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 1RkMpW-0005Hf-R4; Mon, 09 Jan 2012 21:32:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326144746!10258642!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc2OTk2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28129 invoked from network); 9 Jan 2012 21:32:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 21:32:28 -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
	q09LWPkR002110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 21:32:26 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
	q09LWOd8004018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 21:32:25 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
	q09LWOtn024891; Mon, 9 Jan 2012 15:32:24 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 13:32:24 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7679D40944; Mon,  9 Jan 2012 16:30:39 -0500 (EST)
Date: Mon, 9 Jan 2012 16:30:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Message-ID: <20120109213039.GC4773@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F0B5CEA.0049,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Linux 3.2 was released on Jan 4th and this release saw a lot of 
interesting work. 

For the full credit list, please see the bottom of the email.

We did not have any new drivers in this release, but we did have some
awesome goodness:

 - Remove the XEN_PLATFORM_PCI config option. We need it 99% of time
   and not having it enabled caused tons of headaches. Squashing it in
   fixed a lot of distro bugs were the xen-platform-pci.ko module was not
   present in the installer.
 - Rework the E820 parser. It also for proper accounting of memory in
   the "low" (so below 4GB) and "high" (>4GB) memory that can be used for
   ballooning. In other words, what you see in 'xm list' vs 'xl list' is more
   truthfull.
 - Support "big-iron" machines with PCI segments (another layer in case you
   run out of PCI buses, so more than 256 devices).
 - PVonHVM kexec support. It all worked until we found out that under Amazon
   EC2 (and Xen 3.4.x) it would lock up the guest so had to revert the new
   functionality . Will revisit this for 3.4 with a 'feature-XX' flag.
 - MMU improvements by not using the 'vmalloc_sync_all' slow call but being
   more selective.
 - Initial work to make HVM domains be capable of being device drivers or
   even host the XenBus daemon.
 - Initial work laid out for netback page-flipping (also called zero-copying).
 - Block can pass in discard (TRIM/UNMAP) requests to the backends.
 - Block can support the old-style 'feature-barrier' that was removed in 2.6.36 kernels.
 - Tons of cleanup to make the code easier to read.
 - Security fixes in the gnt/gnt_alloc ioctl calls.
 - Work with more than 32 VCPUs.
 - Tons of bug-fixes in various layers. The most critical were back-ported to
   the stable kernels.


Dan Carpenter (4):
      xen/pciback: double lock typo
      xen-gntdev: integer overflow in gntdev_alloc_map()
      xen-gntalloc: integer overflow in gntalloc_ioctl_alloc()
      xen-gntalloc: signedness bug in add_grefs()

Dan Magenheimer (1):
      xen: Fix selfballooning and ensure it doesn't go too far

Daniel De Graaf (5):
      xenbus: Fix loopback event channel assuming domain 0
      xenbus: don't rely on xen_initial_domain to detect local xenstore
      xen/gntdev: Fix sleep-inside-spinlock
      xen: Remove hanging references to CONFIG_XEN_PLATFORM_PCI
      xen/balloon: Avoid OOM when requesting highmem

David Vrabel (9):
      xen/balloon: account for pages released during memory setup
      xen/balloon: simplify test for the end of usable RAM
      xen: allow balloon driver to use more than one memory region
      xen: allow extra memory to be in multiple regions
      xen: release all pages within 1-1 p2m mappings
      xen: use generic functions instead of xen_{alloc, free}_vm_area()
      block: xen-blkback: use API provided by xenbus module to map rings
      net: xen-netback: use API provided by xenbus module to map rings
      xen: map foreign pages for shared rings by updating the PTEs directly


Ian Campbell (12):
      atm: convert to SKB paged frag API.
      IB: amso1100: convert to SKB paged frag API.
      IB: nes: convert to SKB paged frag API.
      IPoIB: convert to SKB paged frag API.
      tg3: convert to SKB paged frag API.
      bnx2: convert to SKB paged frag API.
      bnx2x: convert to SKB paged frag API.
      bnx2fc: convert to SKB paged frag API.
      fcoe: convert to SKB paged frag API.
      xen: netfront: convert to SKB paged frag API.
      genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier
      xen: only limit memory map to maximum reservation for domain 0.


Jan Beulich (5):
      xen/pci: make bus notifier handler return sane values
      xen/pciback: use mutex rather than spinlock in passthrough backend
      xen/pciback: miscellaneous adjustments
      xen/pci: support multi-segment systems
      xen-blkback: use kzalloc() in favor of kmalloc()+memset()

Jeremy Fitzhardinge (1):
      stop_machine: make stop_machine safe and efficient to call early

Joe Jin (1):
      xen-blkback: fixed indentation and comments

Konrad Rzeszutek Wilk (30):
      Revert "xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set."
      xen-pcifront: Update warning comment to use 'e820_host' option.
      xen-swiotlb: Retry up three times to allocate Xen-SWIOTLB
      xen-swiotlb: Fix wrong panic.
      xen-swiotlb: When doing coherent alloc/dealloc check before swizzling the MFNs.
      xen/pciback: Use mutexes when working with Xenbus state transitions.
      xen/pciback: use mutex rather than spinlock in vpci backend
      xen/p2m: Make debug/xen/mmu/p2m visible again.
      xen/p2m: Use SetPagePrivate and its friends for M2P overrides.
      xen/pv-on-hvm:kexec: Fix implicit declaration of function 'xen_hvm_domain'
      xen/pciback: Add flag indicating device has been assigned by Xen
      xen-blkfront: If no barrier or flush is supported, use invalid operation.
      xen/blkback: Support 'feature-barrier' aka old-style BARRIER requests.
      xen/blkback: Report VBD_WSECT (wr_sect) properly.
      xen/blkback: Fix the inhibition to map pages when discarding sector ranges.
      xen/blkback: Check for proper operation.
      xen/blkback: Fix two races in the handling of barrier requests.
      xen/pciback: Do not dereference psdev during printk when it is NULL.
      xen/pciback: Check if the device is found instead of blindly assuming so.
      xen/events: BUG() when we can't allocate our event->irq array.
      xen/events: Don't check the info for NULL as it is already done.
      xen/irq: If we fail during msi_capability_init return proper error code.
      xen/xenbus: Remove the unnecessary check.
      xen/enlighten: Fix compile warnings and set cx to known value.
      xen/p2m/debugfs: Fix potential pointer exception.
      xen/p2m/debugfs: Make type_name more obvious.
      xen/pm_idle: Make pm_idle be default_idle under Xen.
      x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode
      xen/swiotlb: Use page alignment for early buffer allocation.
      Revert "xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel"

Laszlo Ersek (1):
      xen-blkfront: plug device number leak in xlblk_init() error path

Li Dongyang (4):
      xen-blkfront: add BLKIF_OP_DISCARD and discard request struct
      xen-blkback: Implement discard requests ('feature-discard')
      xen-blkfront: Handle discard requests.
      xen-blkfront: fix a deadlock while handling discard response

Linus Torvalds (2):
      Revert "hvc_console: display printk messages on console."
      Revert "rtc: Expire alarms after the time is set."

Olaf Hering (6):
      xen: use static initializers in xen-balloon.c
      xen/pv-on-hvm kexec: prevent crash in xenwatch_thread() when stale watch events arrive
      xen/pv-on-hvm kexec: rebind virqs to existing eventchannel ports
      xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel
      xen/pv-on-hvm kexec: update xs_wire.h:xsd_sockmsg_type from xen-unstable
      xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel

Randy Dunlap (1):
      xen-swiotlb: fix printk and panic args

Ruslan Pisarev (6):
      Xen: fix whitespaces,tabs coding style issue in drivers/xen/balloon.c
      Xen: fix whitespaces,tabs coding style issue in drivers/xen/events.c
      Xen: fix braces coding style issue in gntdev.c and grant-table.c
      Xen: fix whitespaces,tabs coding style issue in drivers/xen/pci.c
      Xen: fix braces coding style issue in xenbus_probe.h
      Xen: fix braces and tabs coding style issue in xenbus_probe.c

Stefano Stabellini (4):
      xen: add an "highmem" parameter to alloc_xenballooned_pages
      xen: modify kernel mappings corresponding to granted pages
      xen: XEN_PVHVM depends on PCI
      xen: remove XEN_PLATFORM_PCI config option

Thomas Meyer (1):
      xen/pciback: use resource_size()

Yu Ke (1):
      xen/acpi: Domain0 acpi parser related platform hypercall

Zhenzhong Duan (1):
      xen:pvhvm: enable PVHVM VCPU placement when using more than 32 CPUs.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:33:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMpY-0005Hr-14; Mon, 09 Jan 2012 21:32:36 +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 1RkMpW-0005Hf-R4; Mon, 09 Jan 2012 21:32:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326144746!10258642!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc2OTk2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28129 invoked from network); 9 Jan 2012 21:32:28 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 21:32:28 -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
	q09LWPkR002110
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 21:32:26 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
	q09LWOd8004018
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 21:32:25 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
	q09LWOtn024891; Mon, 9 Jan 2012 15:32:24 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 13:32:24 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7679D40944; Mon,  9 Jan 2012 16:30:39 -0500 (EST)
Date: Mon, 9 Jan 2012 16:30:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Message-ID: <20120109213039.GC4773@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F0B5CEA.0049,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Linux 3.2 was released on Jan 4th and this release saw a lot of 
interesting work. 

For the full credit list, please see the bottom of the email.

We did not have any new drivers in this release, but we did have some
awesome goodness:

 - Remove the XEN_PLATFORM_PCI config option. We need it 99% of time
   and not having it enabled caused tons of headaches. Squashing it in
   fixed a lot of distro bugs were the xen-platform-pci.ko module was not
   present in the installer.
 - Rework the E820 parser. It also for proper accounting of memory in
   the "low" (so below 4GB) and "high" (>4GB) memory that can be used for
   ballooning. In other words, what you see in 'xm list' vs 'xl list' is more
   truthfull.
 - Support "big-iron" machines with PCI segments (another layer in case you
   run out of PCI buses, so more than 256 devices).
 - PVonHVM kexec support. It all worked until we found out that under Amazon
   EC2 (and Xen 3.4.x) it would lock up the guest so had to revert the new
   functionality . Will revisit this for 3.4 with a 'feature-XX' flag.
 - MMU improvements by not using the 'vmalloc_sync_all' slow call but being
   more selective.
 - Initial work to make HVM domains be capable of being device drivers or
   even host the XenBus daemon.
 - Initial work laid out for netback page-flipping (also called zero-copying).
 - Block can pass in discard (TRIM/UNMAP) requests to the backends.
 - Block can support the old-style 'feature-barrier' that was removed in 2.6.36 kernels.
 - Tons of cleanup to make the code easier to read.
 - Security fixes in the gnt/gnt_alloc ioctl calls.
 - Work with more than 32 VCPUs.
 - Tons of bug-fixes in various layers. The most critical were back-ported to
   the stable kernels.


Dan Carpenter (4):
      xen/pciback: double lock typo
      xen-gntdev: integer overflow in gntdev_alloc_map()
      xen-gntalloc: integer overflow in gntalloc_ioctl_alloc()
      xen-gntalloc: signedness bug in add_grefs()

Dan Magenheimer (1):
      xen: Fix selfballooning and ensure it doesn't go too far

Daniel De Graaf (5):
      xenbus: Fix loopback event channel assuming domain 0
      xenbus: don't rely on xen_initial_domain to detect local xenstore
      xen/gntdev: Fix sleep-inside-spinlock
      xen: Remove hanging references to CONFIG_XEN_PLATFORM_PCI
      xen/balloon: Avoid OOM when requesting highmem

David Vrabel (9):
      xen/balloon: account for pages released during memory setup
      xen/balloon: simplify test for the end of usable RAM
      xen: allow balloon driver to use more than one memory region
      xen: allow extra memory to be in multiple regions
      xen: release all pages within 1-1 p2m mappings
      xen: use generic functions instead of xen_{alloc, free}_vm_area()
      block: xen-blkback: use API provided by xenbus module to map rings
      net: xen-netback: use API provided by xenbus module to map rings
      xen: map foreign pages for shared rings by updating the PTEs directly


Ian Campbell (12):
      atm: convert to SKB paged frag API.
      IB: amso1100: convert to SKB paged frag API.
      IB: nes: convert to SKB paged frag API.
      IPoIB: convert to SKB paged frag API.
      tg3: convert to SKB paged frag API.
      bnx2: convert to SKB paged frag API.
      bnx2x: convert to SKB paged frag API.
      bnx2fc: convert to SKB paged frag API.
      fcoe: convert to SKB paged frag API.
      xen: netfront: convert to SKB paged frag API.
      genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier
      xen: only limit memory map to maximum reservation for domain 0.


Jan Beulich (5):
      xen/pci: make bus notifier handler return sane values
      xen/pciback: use mutex rather than spinlock in passthrough backend
      xen/pciback: miscellaneous adjustments
      xen/pci: support multi-segment systems
      xen-blkback: use kzalloc() in favor of kmalloc()+memset()

Jeremy Fitzhardinge (1):
      stop_machine: make stop_machine safe and efficient to call early

Joe Jin (1):
      xen-blkback: fixed indentation and comments

Konrad Rzeszutek Wilk (30):
      Revert "xen/debug: WARN_ON when identity PFN has no _PAGE_IOMAP flag set."
      xen-pcifront: Update warning comment to use 'e820_host' option.
      xen-swiotlb: Retry up three times to allocate Xen-SWIOTLB
      xen-swiotlb: Fix wrong panic.
      xen-swiotlb: When doing coherent alloc/dealloc check before swizzling the MFNs.
      xen/pciback: Use mutexes when working with Xenbus state transitions.
      xen/pciback: use mutex rather than spinlock in vpci backend
      xen/p2m: Make debug/xen/mmu/p2m visible again.
      xen/p2m: Use SetPagePrivate and its friends for M2P overrides.
      xen/pv-on-hvm:kexec: Fix implicit declaration of function 'xen_hvm_domain'
      xen/pciback: Add flag indicating device has been assigned by Xen
      xen-blkfront: If no barrier or flush is supported, use invalid operation.
      xen/blkback: Support 'feature-barrier' aka old-style BARRIER requests.
      xen/blkback: Report VBD_WSECT (wr_sect) properly.
      xen/blkback: Fix the inhibition to map pages when discarding sector ranges.
      xen/blkback: Check for proper operation.
      xen/blkback: Fix two races in the handling of barrier requests.
      xen/pciback: Do not dereference psdev during printk when it is NULL.
      xen/pciback: Check if the device is found instead of blindly assuming so.
      xen/events: BUG() when we can't allocate our event->irq array.
      xen/events: Don't check the info for NULL as it is already done.
      xen/irq: If we fail during msi_capability_init return proper error code.
      xen/xenbus: Remove the unnecessary check.
      xen/enlighten: Fix compile warnings and set cx to known value.
      xen/p2m/debugfs: Fix potential pointer exception.
      xen/p2m/debugfs: Make type_name more obvious.
      xen/pm_idle: Make pm_idle be default_idle under Xen.
      x86/paravirt: PTE updates in k(un)map_atomic need to be synchronous, regardless of lazy_mmu mode
      xen/swiotlb: Use page alignment for early buffer allocation.
      Revert "xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel"

Laszlo Ersek (1):
      xen-blkfront: plug device number leak in xlblk_init() error path

Li Dongyang (4):
      xen-blkfront: add BLKIF_OP_DISCARD and discard request struct
      xen-blkback: Implement discard requests ('feature-discard')
      xen-blkfront: Handle discard requests.
      xen-blkfront: fix a deadlock while handling discard response

Linus Torvalds (2):
      Revert "hvc_console: display printk messages on console."
      Revert "rtc: Expire alarms after the time is set."

Olaf Hering (6):
      xen: use static initializers in xen-balloon.c
      xen/pv-on-hvm kexec: prevent crash in xenwatch_thread() when stale watch events arrive
      xen/pv-on-hvm kexec: rebind virqs to existing eventchannel ports
      xen/pv-on-hvm kexec+kdump: reset PV devices in kexec or crash kernel
      xen/pv-on-hvm kexec: update xs_wire.h:xsd_sockmsg_type from xen-unstable
      xen/pv-on-hvm kexec: add xs_reset_watches to shutdown watches from old kernel

Randy Dunlap (1):
      xen-swiotlb: fix printk and panic args

Ruslan Pisarev (6):
      Xen: fix whitespaces,tabs coding style issue in drivers/xen/balloon.c
      Xen: fix whitespaces,tabs coding style issue in drivers/xen/events.c
      Xen: fix braces coding style issue in gntdev.c and grant-table.c
      Xen: fix whitespaces,tabs coding style issue in drivers/xen/pci.c
      Xen: fix braces coding style issue in xenbus_probe.h
      Xen: fix braces and tabs coding style issue in xenbus_probe.c

Stefano Stabellini (4):
      xen: add an "highmem" parameter to alloc_xenballooned_pages
      xen: modify kernel mappings corresponding to granted pages
      xen: XEN_PVHVM depends on PCI
      xen: remove XEN_PLATFORM_PCI config option

Thomas Meyer (1):
      xen/pciback: use resource_size()

Yu Ke (1):
      xen/acpi: Domain0 acpi parser related platform hypercall

Zhenzhong Duan (1):
      xen:pvhvm: enable PVHVM VCPU placement when using more than 32 CPUs.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:34:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:34:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMrK-0005RV-7h; Mon, 09 Jan 2012 21:34:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>)
	id 1RkMrI-0005Qb-VN; Mon, 09 Jan 2012 21:34:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326144857!10211398!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc2OTk2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2468 invoked from network); 9 Jan 2012 21:34:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 21:34:18 -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
	q09LYFNp004359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 21:34: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
	q09LYERq029677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 21:34:15 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
	q09LYFsE031422; Mon, 9 Jan 2012 15:34:15 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 13:34:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C22B40944; Mon,  9 Jan 2012 16:32:30 -0500 (EST)
Date: Mon, 9 Jan 2012 16:32:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Message-ID: <20120109213230.GD4773@phenom.dumpdata.com>
References: <20120109183304.GA1287@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120109183304.GA1287@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F0B5D58.00B5,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] Features and bug fixes for Linux kernel 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 Mon, Jan 09, 2012 at 01:33:04PM -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> Linux 3.3 merge window opened last week and today I've asked Linus
> to pulled some of the patches. This is what is going in through
> the Xen tree:
> 
>  - SysFS documentation updates. We are slowly updating them to make sure that the SysFS
>    entires are properly documented.
>  - Making the grant system able to use more fancier types of grants to speed-up
>    guest to guest exchange of data (sub-page and transitive grants).
>  - Updates in the backends to be able to export the Xen backends in an
>    Hardware Virtualized Management (HVM) guest. We usually export those backends in
>    the initial domain (dom0), but are moving slowly to make it possible to do it any guest
>    (PV or HVM). NOTE: Only the netback version is in. The blkback needs an
>    Ack from Jens Axboe and while I am sure he will provide it it might be past the
>    merge window time-frame.
>  - Better driver to deal with memory type ioctls calls. In the past we were doing
>    ioctls on /proc/xen/priv_cmd (yuck) and with this are moving to doing it in
>    /dev/xen/priv_cmd.
>  - Fix a security issues were the guest could try to send a nasty (out of band)
>    message and potentially cause mishap.
>  - Remove duplicate initialization fields in the backend drivers.
>  - Jeremy is now working for a fancy new startup so changing the MAINTAINERS file to
>    reflect that his contribution are done during his private time.
>  - Sensible config options. We had some that weren't all that good so adjusting
>    them properly.
>  - Bug-fixes, fixing a bug in xen-pciback with the "Ownership but beware" bug.

And in the Jens Axboe (block maintainer) we have patches to support the 'secure' DISCARD
operation for blkfront/blkback. It is TRIM/UNMAP with the option of securely erasing the media.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:34:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:34:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMrK-0005RV-7h; Mon, 09 Jan 2012 21:34:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>)
	id 1RkMrI-0005Qb-VN; Mon, 09 Jan 2012 21:34:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326144857!10211398!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDc2OTk2\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2468 invoked from network); 9 Jan 2012 21:34:18 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 9 Jan 2012 21:34:18 -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
	q09LYFNp004359
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 9 Jan 2012 21:34: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
	q09LYERq029677
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 9 Jan 2012 21:34:15 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
	q09LYFsE031422; Mon, 9 Jan 2012 15:34:15 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 09 Jan 2012 13:34:14 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1C22B40944; Mon,  9 Jan 2012 16:32:30 -0500 (EST)
Date: Mon, 9 Jan 2012 16:32:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Message-ID: <20120109213230.GD4773@phenom.dumpdata.com>
References: <20120109183304.GA1287@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120109183304.GA1287@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F0B5D58.00B5,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] Features and bug fixes for Linux kernel 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 Mon, Jan 09, 2012 at 01:33:04PM -0500, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> Linux 3.3 merge window opened last week and today I've asked Linus
> to pulled some of the patches. This is what is going in through
> the Xen tree:
> 
>  - SysFS documentation updates. We are slowly updating them to make sure that the SysFS
>    entires are properly documented.
>  - Making the grant system able to use more fancier types of grants to speed-up
>    guest to guest exchange of data (sub-page and transitive grants).
>  - Updates in the backends to be able to export the Xen backends in an
>    Hardware Virtualized Management (HVM) guest. We usually export those backends in
>    the initial domain (dom0), but are moving slowly to make it possible to do it any guest
>    (PV or HVM). NOTE: Only the netback version is in. The blkback needs an
>    Ack from Jens Axboe and while I am sure he will provide it it might be past the
>    merge window time-frame.
>  - Better driver to deal with memory type ioctls calls. In the past we were doing
>    ioctls on /proc/xen/priv_cmd (yuck) and with this are moving to doing it in
>    /dev/xen/priv_cmd.
>  - Fix a security issues were the guest could try to send a nasty (out of band)
>    message and potentially cause mishap.
>  - Remove duplicate initialization fields in the backend drivers.
>  - Jeremy is now working for a fancy new startup so changing the MAINTAINERS file to
>    reflect that his contribution are done during his private time.
>  - Sensible config options. We had some that weren't all that good so adjusting
>    them properly.
>  - Bug-fixes, fixing a bug in xen-pciback with the "Ownership but beware" bug.

And in the Jens Axboe (block maintainer) we have patches to support the 'secure' DISCARD
operation for blkfront/blkback. It is TRIM/UNMAP with the option of securely erasing the media.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:36:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21: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 1RkMtS-0005pF-Hp; Mon, 09 Jan 2012 21:36:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RkMtR-0005ng-I2
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:36:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326144990!10269553!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY5MDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9505 invoked from network); 9 Jan 2012 21:36:31 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-3.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 21:36:31 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 8B8B84B0090;
	Mon,  9 Jan 2012 13:36:29 -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=DGDbuf8GWw5zMJCASIBdbW
	tGWcs5G3y0hj8Snk5ke0YbQkvupeAVJgdoPEkmIYW87a3kH0MbhRNgXqu1oTLCYP
	2p7Kv2yYd9gqiGi+ZWxi5TMHzoigUqwEow/IPRXojOxoFSXp/fGxQ3ydH0f+ZHfL
	5DMdMoxTJO977BRq0WMiw=
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=7AT4uxpCoSFj
	/oUcMCWHN1KkMOQ=; b=jrJXMK/IvxZuuVjdTOoZL40IPBcr5PWvLP1vWBn67pPO
	R7rZUM94dW05Mj1t/C5ShW9n7/6cmt7F14z0wDfiINQwNfPmib8yTAL5+mtqoaov
	wYXMr9RVRZYqNC4+yGq3j/+0KV631E+yB7LZAPpcajrli95qEOjnbo/uFNTWlSU=
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 816C54B008F; 
	Mon,  9 Jan 2012 13:36:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 90f764bf02c3c7f781539b61619a53c58dbc152f
Message-Id: <90f764bf02c3c7f78153.1326145234@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:40:34 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
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

 tools/libxc/xc_linux_osdep.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


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.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2a2f3597d156 -r 90f764bf02c3 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 Mon Jan 09 21:36:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21: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 1RkMtS-0005pF-Hp; Mon, 09 Jan 2012 21:36:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RkMtR-0005ng-I2
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:36:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326144990!10269553!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY5MDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9505 invoked from network); 9 Jan 2012 21:36:31 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-3.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 21:36:31 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 8B8B84B0090;
	Mon,  9 Jan 2012 13:36:29 -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=DGDbuf8GWw5zMJCASIBdbW
	tGWcs5G3y0hj8Snk5ke0YbQkvupeAVJgdoPEkmIYW87a3kH0MbhRNgXqu1oTLCYP
	2p7Kv2yYd9gqiGi+ZWxi5TMHzoigUqwEow/IPRXojOxoFSXp/fGxQ3ydH0f+ZHfL
	5DMdMoxTJO977BRq0WMiw=
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=7AT4uxpCoSFj
	/oUcMCWHN1KkMOQ=; b=jrJXMK/IvxZuuVjdTOoZL40IPBcr5PWvLP1vWBn67pPO
	R7rZUM94dW05Mj1t/C5ShW9n7/6cmt7F14z0wDfiINQwNfPmib8yTAL5+mtqoaov
	wYXMr9RVRZYqNC4+yGq3j/+0KV631E+yB7LZAPpcajrli95qEOjnbo/uFNTWlSU=
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 816C54B008F; 
	Mon,  9 Jan 2012 13:36:28 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 90f764bf02c3c7f781539b61619a53c58dbc152f
Message-Id: <90f764bf02c3c7f78153.1326145234@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:40:34 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
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

 tools/libxc/xc_linux_osdep.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


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.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2a2f3597d156 -r 90f764bf02c3 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 Mon Jan 09 21:38:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMuk-00063k-FA; Mon, 09 Jan 2012 21:37:58 +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 1RkMui-00062O-RX
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:37:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326145069!10205274!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NTAw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NTAw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17659 invoked from network); 9 Jan 2012 21:37:50 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 21:37:50 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id D7E037EC069;
	Mon,  9 Jan 2012 13:37: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=ai1gPfxhWPMjiMBqjFXTZNUXkV7KIWNJVmbkGAX81nnr
	rVl7kZLMHQW86gHaFth6QthesM/Q85/1fI/emyk5W2VlWiqLiTJ/tYkcXgWtKHNw
	pnOjNQDTq8V1+CLZlVbb55almmrp9ax7SyNBtGUwHkY5gnCSz0gwUrCvZwCKSbE=
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=q/ED6CIWPJ+qUsIzR9g9HV42nCA=; b=cbzfSOOaOPv
	9pJBSbSUg0YwFlRrDEjL015eJQqskj/avmaYSbhctQwRpc95OOgWMwVN9zSVD15f
	ZvjwHcuFLs/LtgJll1UPON5gYLvgR+jbYrf+OuOftE2oqjfeZ0K5XC1ehK/NCqDi
	RLaFmVPuCgdm+sfs/jnWALSKviXYesvQ=
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 43BA37EC063; 
	Mon,  9 Jan 2012 13:37:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f7c330d5b4b5c78155bde958cbe43ae24b36755f
Message-Id: <f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326145285@xdev.gridcentric.ca>
References: <patchbomb.1326145285@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:41:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
 p2m_ram_paged_out state to be loaded
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)


This removes the need for a page to be accessed in order to be pageable
again. A pager can now page-in pages at will with no need to map them
in a separate thread.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>

diff -r 90f764bf02c3 -r f7c330d5b4b5 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -964,7 +964,7 @@ void p2m_mem_paging_populate(struct doma
 int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 {
     struct page_info *page;
-    p2m_type_t p2mt;
+    p2m_type_t p2mt, target_p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -982,8 +982,8 @@ int p2m_mem_paging_prep(struct domain *d
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
     ret = -ENOENT;
-    /* Allow only missing pages */
-    if ( p2mt != p2m_ram_paging_in_start )
+    /* Allow missing pages */
+    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
         goto out;
 
     /* Allocate a page if the gfn does not have one yet */
@@ -1018,8 +1018,15 @@ int p2m_mem_paging_prep(struct domain *d
         }
     }
 
+    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
+        /* If we kicked the pager with a populate event, the pager will send
+         * a resume event back */
+        p2m_ram_paging_in :
+        /* If this was called asynchronously by the pager, then we can 
+         * transition directly to the final guest-accessible type */
+        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
     /* Fix p2m mapping */
-    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
 
     atomic_dec(&d->paged_pages);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:38:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMuk-00063k-FA; Mon, 09 Jan 2012 21:37:58 +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 1RkMui-00062O-RX
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:37:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326145069!10205274!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NTAw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3NTAw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17659 invoked from network); 9 Jan 2012 21:37:50 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 21:37:50 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id D7E037EC069;
	Mon,  9 Jan 2012 13:37: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=ai1gPfxhWPMjiMBqjFXTZNUXkV7KIWNJVmbkGAX81nnr
	rVl7kZLMHQW86gHaFth6QthesM/Q85/1fI/emyk5W2VlWiqLiTJ/tYkcXgWtKHNw
	pnOjNQDTq8V1+CLZlVbb55almmrp9ax7SyNBtGUwHkY5gnCSz0gwUrCvZwCKSbE=
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=q/ED6CIWPJ+qUsIzR9g9HV42nCA=; b=cbzfSOOaOPv
	9pJBSbSUg0YwFlRrDEjL015eJQqskj/avmaYSbhctQwRpc95OOgWMwVN9zSVD15f
	ZvjwHcuFLs/LtgJll1UPON5gYLvgR+jbYrf+OuOftE2oqjfeZ0K5XC1ehK/NCqDi
	RLaFmVPuCgdm+sfs/jnWALSKviXYesvQ=
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 43BA37EC063; 
	Mon,  9 Jan 2012 13:37:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f7c330d5b4b5c78155bde958cbe43ae24b36755f
Message-Id: <f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326145285@xdev.gridcentric.ca>
References: <patchbomb.1326145285@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:41:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
 p2m_ram_paged_out state to be loaded
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  15 +++++++++++----
 1 files changed, 11 insertions(+), 4 deletions(-)


This removes the need for a page to be accessed in order to be pageable
again. A pager can now page-in pages at will with no need to map them
in a separate thread.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>

diff -r 90f764bf02c3 -r f7c330d5b4b5 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -964,7 +964,7 @@ void p2m_mem_paging_populate(struct doma
 int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 {
     struct page_info *page;
-    p2m_type_t p2mt;
+    p2m_type_t p2mt, target_p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -982,8 +982,8 @@ int p2m_mem_paging_prep(struct domain *d
     mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
 
     ret = -ENOENT;
-    /* Allow only missing pages */
-    if ( p2mt != p2m_ram_paging_in_start )
+    /* Allow missing pages */
+    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
         goto out;
 
     /* Allocate a page if the gfn does not have one yet */
@@ -1018,8 +1018,15 @@ int p2m_mem_paging_prep(struct domain *d
         }
     }
 
+    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
+        /* If we kicked the pager with a populate event, the pager will send
+         * a resume event back */
+        p2m_ram_paging_in :
+        /* If this was called asynchronously by the pager, then we can 
+         * transition directly to the final guest-accessible type */
+        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
     /* Fix p2m mapping */
-    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
+    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
 
     atomic_dec(&d->paged_pages);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:38:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMuk-00063s-Rc; Mon, 09 Jan 2012 21:37:58 +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 1RkMuj-00062U-8Q
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:37:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326145070!10201581!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY5MDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5961 invoked from network); 9 Jan 2012 21:37:50 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 21:37:50 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id AB6167EC072;
	Mon,  9 Jan 2012 13:37: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=c09R37n+OGSVjL9f9ln4RsJpR9I2ugUezKQqpV3/P6Be
	qd6WGq9x7YaIaVXvfHvBOaCqbvTPEPoUx3bAGobV8FFnXM8F+5OGGjZohWtFoJZI
	xyNqZ6HCRXiVFEijf10n37vwgppZC4evkr8ismFQMVuWkAIaaUDMy6+kOUVIzJ4=
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=++QKFQnHEx8NgBRoCOj033kOtuI=; b=eiQ4ZCSZ9xC
	umFK+YFY/gpsH/FqehBzoyza3Bm7tiBmebfrLKNr5hNz7Jgt9oOLYHG0az+UMoGe
	g80GQwexPZQCrCK3j03969xHASLCd0D8T/oRwEkPp8kPUNSKysgaga0TQqZ2qLOj
	3OunmAeDrrBhPR6c68/laZWxj3xORC+Q=
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 10F1B7EC063; 
	Mon,  9 Jan 2012 13:37:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d5e830891ee2ac59881a4d31d122a9b55e5074eb
Message-Id: <d5e830891ee2ac59881a.1326145287@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326145285@xdev.gridcentric.ca>
References: <patchbomb.1326145285@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:41:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: Disable 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

 xen/arch/x86/mm/p2m.c |  4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)


The only way to page-in a page is now the safe paging_load domctl.
(Unless the page was never paged out in the first place)

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>

diff -r f7c330d5b4b5 -r d5e830891ee2 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -989,6 +989,10 @@ int p2m_mem_paging_prep(struct domain *d
     /* Allocate a page if the gfn does not have one yet */
     if ( !mfn_valid(mfn) )
     {
+        /* If the user did not provide a buffer, we disallow */
+        ret = -EINVAL;
+        if ( unlikely(user_ptr == NULL) )
+            goto out;
         /* Get a free page */
         ret = -ENOMEM;
         page = alloc_domheap_page(p2m->domain, 0);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:38:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:38:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMuk-00063s-Rc; Mon, 09 Jan 2012 21:37:58 +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 1RkMuj-00062U-8Q
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:37:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326145070!10201581!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTY5MDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5961 invoked from network); 9 Jan 2012 21:37:50 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.145) by server-10.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 21:37:50 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id AB6167EC072;
	Mon,  9 Jan 2012 13:37: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=c09R37n+OGSVjL9f9ln4RsJpR9I2ugUezKQqpV3/P6Be
	qd6WGq9x7YaIaVXvfHvBOaCqbvTPEPoUx3bAGobV8FFnXM8F+5OGGjZohWtFoJZI
	xyNqZ6HCRXiVFEijf10n37vwgppZC4evkr8ismFQMVuWkAIaaUDMy6+kOUVIzJ4=
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=++QKFQnHEx8NgBRoCOj033kOtuI=; b=eiQ4ZCSZ9xC
	umFK+YFY/gpsH/FqehBzoyza3Bm7tiBmebfrLKNr5hNz7Jgt9oOLYHG0az+UMoGe
	g80GQwexPZQCrCK3j03969xHASLCd0D8T/oRwEkPp8kPUNSKysgaga0TQqZ2qLOj
	3OunmAeDrrBhPR6c68/laZWxj3xORC+Q=
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 10F1B7EC063; 
	Mon,  9 Jan 2012 13:37:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d5e830891ee2ac59881a4d31d122a9b55e5074eb
Message-Id: <d5e830891ee2ac59881a.1326145287@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326145285@xdev.gridcentric.ca>
References: <patchbomb.1326145285@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:41:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: Disable 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

 xen/arch/x86/mm/p2m.c |  4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)


The only way to page-in a page is now the safe paging_load domctl.
(Unless the page was never paged out in the first place)

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>

diff -r f7c330d5b4b5 -r d5e830891ee2 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -989,6 +989,10 @@ int p2m_mem_paging_prep(struct domain *d
     /* Allocate a page if the gfn does not have one yet */
     if ( !mfn_valid(mfn) )
     {
+        /* If the user did not provide a buffer, we disallow */
+        ret = -EINVAL;
+        if ( unlikely(user_ptr == NULL) )
+            goto out;
         /* Get a free page */
         ret = -ENOMEM;
         page = alloc_domheap_page(p2m->domain, 0);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:38:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMuj-00063J-1e; Mon, 09 Jan 2012 21:37:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RkMuh-00062D-J6
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:37:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326145069!10204642!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjUw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjUw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4321 invoked from network); 9 Jan 2012 21:37:49 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-10.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 21:37:49 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 0B55B7EC064;
	Mon,  9 Jan 2012 13:37:48 -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=GdjJgqYxvPe9BHhxEUFYSD
	lNFx0R+UnIGHL5GnQRPDIIaSaGnJbdv5I1zlTcXbjKzAu9vKnyX0S53oEmq+fKWC
	byL4+MbrQV9uv2uz/PXo/UknEQmS135qqbxXg7ZEUK+dwZ99i5z10JAwuqxZFQ6i
	p2HFwIJgRUvIev6EnMizU=
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=ja5RMdRvb9Ma
	WUuf6sdPWBbTpGo=; b=Dhvb6OoNPEdPYNuQApJ71SOFXy8LZXxJk3Jd5c6vVAvB
	UQ6YX5lJUN01/HhbCAmiV9Km8zeBzTl2x66DP7Qp293l3gMpv63DFNsvejvnr4LD
	D11jN3YF4F3loqecziliIx6qisx831t0zDmVwcDbjHN9GQJ+kzlK6NDQM6NgZbQ=
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 4E4027EC063; 
	Mon,  9 Jan 2012 13:37:47 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326145285@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:41:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] x86/mm: Two hypervisor paging 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

- Disallow for good paging_prep: it's unsafe
- Allow paging in of a page in paged-out state. This shortcuts the 
  need to reference the page and trigger a populate event, thus saving
  a complete control stack round-trip.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>

 xen/arch/x86/mm/p2m.c |  15 +++++++++++----
 xen/arch/x86/mm/p2m.c |   4 ++++
 2 files changed, 15 insertions(+), 4 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:38:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:38:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMuj-00063J-1e; Mon, 09 Jan 2012 21:37:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RkMuh-00062D-J6
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:37:55 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326145069!10204642!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjUw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjUw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4321 invoked from network); 9 Jan 2012 21:37:49 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.81) by server-10.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 21:37:49 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 0B55B7EC064;
	Mon,  9 Jan 2012 13:37:48 -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=GdjJgqYxvPe9BHhxEUFYSD
	lNFx0R+UnIGHL5GnQRPDIIaSaGnJbdv5I1zlTcXbjKzAu9vKnyX0S53oEmq+fKWC
	byL4+MbrQV9uv2uz/PXo/UknEQmS135qqbxXg7ZEUK+dwZ99i5z10JAwuqxZFQ6i
	p2HFwIJgRUvIev6EnMizU=
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=ja5RMdRvb9Ma
	WUuf6sdPWBbTpGo=; b=Dhvb6OoNPEdPYNuQApJ71SOFXy8LZXxJk3Jd5c6vVAvB
	UQ6YX5lJUN01/HhbCAmiV9Km8zeBzTl2x66DP7Qp293l3gMpv63DFNsvejvnr4LD
	D11jN3YF4F3loqecziliIx6qisx831t0zDmVwcDbjHN9GQJ+kzlK6NDQM6NgZbQ=
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 4E4027EC063; 
	Mon,  9 Jan 2012 13:37:47 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326145285@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:41:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] x86/mm: Two hypervisor paging 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

- Disallow for good paging_prep: it's unsafe
- Allow paging in of a page in paged-out state. This shortcuts the 
  need to reference the page and trigger a populate event, thus saving
  a complete control stack round-trip.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>

 xen/arch/x86/mm/p2m.c |  15 +++++++++++----
 xen/arch/x86/mm/p2m.c |   4 ++++
 2 files changed, 15 insertions(+), 4 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:39:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMwJ-0006QZ-Hj; Mon, 09 Jan 2012 21:39: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 1RkMwI-0006QG-5h
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:39:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326145128!51478251!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjUw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjUw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11383 invoked from network); 9 Jan 2012 21:38:48 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-27.messagelabs.com with SMTP;
	9 Jan 2012 21:38:48 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 206705EC07E;
	Mon,  9 Jan 2012 13:39:32 -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=K9QV8ucxgISGT4OYiS5lNO
	eTm79O0NQTiGQULkBj0/qGQeMbdtLOMJ2FaFYVh6v6LH3Oc9q1Z59AJvAnFqunei
	gykpSPq0YQJGZbIVWSvC0eW+oo0pFoPlVDI9jwgKvG6wpG+lwlabtbC1S7d3w5Sx
	o3vcy9umBGM7hWSMQBAkA=
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=c17HW62DpJq2
	eMkyHgPdQl0cIwE=; b=t1cXhHkVM08yoMW0WO4clubXQKecmV6L1e5FaGl4Ulg2
	u5wfDyZevgdP3qsARmH0FL5euNvA3Wqgw3lyGHEBBgAW3hpAQzcXBv0qi1R/xYoI
	7BWop+vuXde1KiZc4Wxibkg9wzidoIadu7AUOgr/2BqjktGKSyA5n0UwLRiQxbk=
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 74A9B5EC082; 
	Mon,  9 Jan 2012 13:39:31 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326145399@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:43:19 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Tools: memshr cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Clean up the coding style of memshr in preparation for sharing updates.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar Cavilla <andres@lagarcavilla.org>

 tools/libxc/xc_memshr.c         |  28 ++++++++++++++--------------
 tools/libxc/xenctrl.h           |  14 +++++++-------
 tools/blktap2/drivers/Makefile  |   2 +-
 tools/blktap2/drivers/tapdisk.h |   4 ++++
 tools/memshr/interface.c        |   2 +-
 tools/memshr/memshr.h           |   2 +-
 tools/memshr/shm.c              |   2 +-
 tools/memshr/shm.h              |   2 +-
 8 files changed, 30 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 Mon Jan 09 21:39:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:39:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMwJ-0006QZ-Hj; Mon, 09 Jan 2012 21:39: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 1RkMwI-0006QG-5h
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:39:34 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326145128!51478251!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjUw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE3MjUw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11383 invoked from network); 9 Jan 2012 21:38:48 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.81) by server-6.tower-27.messagelabs.com with SMTP;
	9 Jan 2012 21:38:48 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 206705EC07E;
	Mon,  9 Jan 2012 13:39:32 -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=K9QV8ucxgISGT4OYiS5lNO
	eTm79O0NQTiGQULkBj0/qGQeMbdtLOMJ2FaFYVh6v6LH3Oc9q1Z59AJvAnFqunei
	gykpSPq0YQJGZbIVWSvC0eW+oo0pFoPlVDI9jwgKvG6wpG+lwlabtbC1S7d3w5Sx
	o3vcy9umBGM7hWSMQBAkA=
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=c17HW62DpJq2
	eMkyHgPdQl0cIwE=; b=t1cXhHkVM08yoMW0WO4clubXQKecmV6L1e5FaGl4Ulg2
	u5wfDyZevgdP3qsARmH0FL5euNvA3Wqgw3lyGHEBBgAW3hpAQzcXBv0qi1R/xYoI
	7BWop+vuXde1KiZc4Wxibkg9wzidoIadu7AUOgr/2BqjktGKSyA5n0UwLRiQxbk=
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 74A9B5EC082; 
	Mon,  9 Jan 2012 13:39:31 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326145399@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:43:19 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Tools: memshr cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Clean up the coding style of memshr in preparation for sharing updates.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar Cavilla <andres@lagarcavilla.org>

 tools/libxc/xc_memshr.c         |  28 ++++++++++++++--------------
 tools/libxc/xenctrl.h           |  14 +++++++-------
 tools/blktap2/drivers/Makefile  |   2 +-
 tools/blktap2/drivers/tapdisk.h |   4 ++++
 tools/memshr/interface.c        |   2 +-
 tools/memshr/memshr.h           |   2 +-
 tools/memshr/shm.c              |   2 +-
 tools/memshr/shm.h              |   2 +-
 8 files changed, 30 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 Mon Jan 09 21:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21: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 1RkMwP-0006Rl-UM; Mon, 09 Jan 2012 21:39:41 +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 1RkMwO-0006QR-A1
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:39:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326145173!10195125!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYyMjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19399 invoked from network); 9 Jan 2012 21:39:33 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 21:39:33 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 170545EC07C;
	Mon,  9 Jan 2012 13:39: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=fzBr4UfSlafG6RJuDQZXQVlQO6mshmi9i7hvUJ19w4kv
	Q72ADQ6ukIdFOPmdXSydaSLowshp7iUuTEvJ/tvq04cuf1znRW0QfLwfLS19KDnt
	RGb0q+swspnBZr6rbSzd8fGDRLhqXr1InbBfgxF/9ZtdrJjHXU0j2jlHGhXn750=
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=DXOwj4es8IhPo6ZO7DAsJN9ghLA=; b=ofEZJ14nBUv
	9AkFxZi1LTYLzkCoQx+plA8uxG4w+rpm62VcwhSGi5DMyg71Hhx3SZcVprHPU3NU
	dvOgI2Uaudliw/Nd5b8pYD2BG5C5lB+lDZcKx9dIZQVC4lxroFDoeTOoOm3eEjR5
	4sV3PrZTf5nm7FhpUvlQUzz4O73u3c/M=
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 5243B5EC082; 
	Mon,  9 Jan 2012 13:39:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2d3804d81c3cb04a7e9da4995d9f5eed1919c0ad
Message-Id: <2d3804d81c3cb04a7e9d.1326145400@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326145399@xdev.gridcentric.ca>
References: <patchbomb.1326145399@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:43:20 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Fix types used in xc_memshr_* 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

 tools/libxc/xc_memshr.c |  28 ++++++++++++++--------------
 tools/libxc/xenctrl.h   |  14 +++++++-------
 2 files changed, 21 insertions(+), 21 deletions(-)


Currently the memshr functions use uint32_t for the domid.  This actually leads
to a funny domid_t -> uint32_t -> domid_t sequence of casts.  This patch
updates the API functions to be domid_t in the first place.

No tools need to be modified with this patch, the casts were implicit.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d5e830891ee2 -r 2d3804d81c3c tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -26,7 +26,7 @@
 #include <xen/grant_table.h>
 
 int xc_memshr_control(xc_interface *xch,
-                      uint32_t domid,
+                      domid_t domid,
                       int enable)
 {
     DECLARE_DOMCTL;
@@ -34,7 +34,7 @@ int xc_memshr_control(xc_interface *xch,
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
     op->u.enable = enable;
@@ -43,7 +43,7 @@ int xc_memshr_control(xc_interface *xch,
 }
 
 int xc_memshr_nominate_gfn(xc_interface *xch,
-                           uint32_t domid,
+                           domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
@@ -53,7 +53,7 @@ int xc_memshr_nominate_gfn(xc_interface 
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
     op->u.nominate.u.gfn = gfn;
@@ -65,7 +65,7 @@ int xc_memshr_nominate_gfn(xc_interface 
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
-                            uint32_t domid,
+                            domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle)
 {
@@ -75,7 +75,7 @@ int xc_memshr_nominate_gref(xc_interface
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
     op->u.nominate.u.grant_ref = gref;
@@ -105,14 +105,14 @@ int xc_memshr_share(xc_interface *xch,
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
-                            uint32_t domid)
+                            domid_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;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
 
@@ -120,7 +120,7 @@ int xc_memshr_domain_resume(xc_interface
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
-                        uint32_t domid,
+                        domid_t domid,
                         unsigned long gfn)
 {
     DECLARE_DOMCTL;
@@ -128,7 +128,7 @@ int xc_memshr_debug_gfn(xc_interface *xc
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
     op->u.debug.u.gfn = gfn;
@@ -137,7 +137,7 @@ int xc_memshr_debug_gfn(xc_interface *xc
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
-                        uint32_t domid,
+                        domid_t domid,
                         unsigned long mfn)
 {
     DECLARE_DOMCTL;
@@ -145,7 +145,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
     op->u.debug.u.mfn = mfn;
@@ -154,7 +154,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
-                         uint32_t domid,
+                         domid_t domid,
                          grant_ref_t gref)
 {
     DECLARE_DOMCTL;
@@ -162,7 +162,7 @@ int xc_memshr_debug_gref(xc_interface *x
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
     op->u.debug.u.gref = gref;
diff -r d5e830891ee2 -r 2d3804d81c3c tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1880,29 +1880,29 @@ int xc_mem_access_resume(xc_interface *x
  * memshr operations
  */
 int xc_memshr_control(xc_interface *xch,
-                      uint32_t domid,
+                      domid_t domid,
                       int enable);
 int xc_memshr_nominate_gfn(xc_interface *xch,
-                           uint32_t domid,
+                           domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle);
 int xc_memshr_nominate_gref(xc_interface *xch,
-                            uint32_t domid,
+                            domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
                     uint64_t source_handle,
                     uint64_t client_handle);
 int xc_memshr_domain_resume(xc_interface *xch,
-                            uint32_t domid);
+                            domid_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,
-                        uint32_t domid,
+                        domid_t domid,
                         unsigned long gfn);
 int xc_memshr_debug_mfn(xc_interface *xch,
-                        uint32_t domid,
+                        domid_t domid,
                         unsigned long mfn);
 int xc_memshr_debug_gref(xc_interface *xch,
-                         uint32_t domid,
+                         domid_t domid,
                          grant_ref_t gref);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21: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 1RkMwP-0006Rl-UM; Mon, 09 Jan 2012 21:39:41 +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 1RkMwO-0006QR-A1
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:39:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326145173!10195125!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYyMjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19399 invoked from network); 9 Jan 2012 21:39:33 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-182.messagelabs.com with SMTP;
	9 Jan 2012 21:39:33 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 170545EC07C;
	Mon,  9 Jan 2012 13:39: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=fzBr4UfSlafG6RJuDQZXQVlQO6mshmi9i7hvUJ19w4kv
	Q72ADQ6ukIdFOPmdXSydaSLowshp7iUuTEvJ/tvq04cuf1znRW0QfLwfLS19KDnt
	RGb0q+swspnBZr6rbSzd8fGDRLhqXr1InbBfgxF/9ZtdrJjHXU0j2jlHGhXn750=
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=DXOwj4es8IhPo6ZO7DAsJN9ghLA=; b=ofEZJ14nBUv
	9AkFxZi1LTYLzkCoQx+plA8uxG4w+rpm62VcwhSGi5DMyg71Hhx3SZcVprHPU3NU
	dvOgI2Uaudliw/Nd5b8pYD2BG5C5lB+lDZcKx9dIZQVC4lxroFDoeTOoOm3eEjR5
	4sV3PrZTf5nm7FhpUvlQUzz4O73u3c/M=
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 5243B5EC082; 
	Mon,  9 Jan 2012 13:39:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2d3804d81c3cb04a7e9da4995d9f5eed1919c0ad
Message-Id: <2d3804d81c3cb04a7e9d.1326145400@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326145399@xdev.gridcentric.ca>
References: <patchbomb.1326145399@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:43:20 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Fix types used in xc_memshr_* 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

 tools/libxc/xc_memshr.c |  28 ++++++++++++++--------------
 tools/libxc/xenctrl.h   |  14 +++++++-------
 2 files changed, 21 insertions(+), 21 deletions(-)


Currently the memshr functions use uint32_t for the domid.  This actually leads
to a funny domid_t -> uint32_t -> domid_t sequence of casts.  This patch
updates the API functions to be domid_t in the first place.

No tools need to be modified with this patch, the casts were implicit.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d5e830891ee2 -r 2d3804d81c3c tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -26,7 +26,7 @@
 #include <xen/grant_table.h>
 
 int xc_memshr_control(xc_interface *xch,
-                      uint32_t domid,
+                      domid_t domid,
                       int enable)
 {
     DECLARE_DOMCTL;
@@ -34,7 +34,7 @@ int xc_memshr_control(xc_interface *xch,
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
     op->u.enable = enable;
@@ -43,7 +43,7 @@ int xc_memshr_control(xc_interface *xch,
 }
 
 int xc_memshr_nominate_gfn(xc_interface *xch,
-                           uint32_t domid,
+                           domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
@@ -53,7 +53,7 @@ int xc_memshr_nominate_gfn(xc_interface 
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
     op->u.nominate.u.gfn = gfn;
@@ -65,7 +65,7 @@ int xc_memshr_nominate_gfn(xc_interface 
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
-                            uint32_t domid,
+                            domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle)
 {
@@ -75,7 +75,7 @@ int xc_memshr_nominate_gref(xc_interface
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
     op->u.nominate.u.grant_ref = gref;
@@ -105,14 +105,14 @@ int xc_memshr_share(xc_interface *xch,
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
-                            uint32_t domid)
+                            domid_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;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
 
@@ -120,7 +120,7 @@ int xc_memshr_domain_resume(xc_interface
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
-                        uint32_t domid,
+                        domid_t domid,
                         unsigned long gfn)
 {
     DECLARE_DOMCTL;
@@ -128,7 +128,7 @@ int xc_memshr_debug_gfn(xc_interface *xc
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
     op->u.debug.u.gfn = gfn;
@@ -137,7 +137,7 @@ int xc_memshr_debug_gfn(xc_interface *xc
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
-                        uint32_t domid,
+                        domid_t domid,
                         unsigned long mfn)
 {
     DECLARE_DOMCTL;
@@ -145,7 +145,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
     op->u.debug.u.mfn = mfn;
@@ -154,7 +154,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
-                         uint32_t domid,
+                         domid_t domid,
                          grant_ref_t gref)
 {
     DECLARE_DOMCTL;
@@ -162,7 +162,7 @@ int xc_memshr_debug_gref(xc_interface *x
 
     domctl.cmd = XEN_DOMCTL_mem_sharing_op;
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = (domid_t)domid;
+    domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
     op->u.debug.u.gref = gref;
diff -r d5e830891ee2 -r 2d3804d81c3c tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1880,29 +1880,29 @@ int xc_mem_access_resume(xc_interface *x
  * memshr operations
  */
 int xc_memshr_control(xc_interface *xch,
-                      uint32_t domid,
+                      domid_t domid,
                       int enable);
 int xc_memshr_nominate_gfn(xc_interface *xch,
-                           uint32_t domid,
+                           domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle);
 int xc_memshr_nominate_gref(xc_interface *xch,
-                            uint32_t domid,
+                            domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
 int xc_memshr_share(xc_interface *xch,
                     uint64_t source_handle,
                     uint64_t client_handle);
 int xc_memshr_domain_resume(xc_interface *xch,
-                            uint32_t domid);
+                            domid_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,
-                        uint32_t domid,
+                        domid_t domid,
                         unsigned long gfn);
 int xc_memshr_debug_mfn(xc_interface *xch,
-                        uint32_t domid,
+                        domid_t domid,
                         unsigned long mfn);
 int xc_memshr_debug_gref(xc_interface *xch,
-                         uint32_t domid,
+                         domid_t domid,
                          grant_ref_t gref);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21: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 1RkMwQ-0006Rw-BM; Mon, 09 Jan 2012 21:39:42 +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 1RkMwP-0006Qg-6Y
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:39:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326145174!10259237!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2Njg5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6780 invoked from network); 9 Jan 2012 21:39:34 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-11.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 21:39:34 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id CD8B15EC083;
	Mon,  9 Jan 2012 13:39: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=AiG4qhl0Rdp71JM+Xmrgp0lgS4Gl3HLGc4dkwnpk7u9h
	zoSuL6DpHLr8/7bI6qpuDKzgu03YfjZ1p6gR3jbYIt1KHGF2iZ2nitDNejI4tUf/
	AKRg5NUgKoieeb/Qiwv0OAjdmGhKvALv6wnF0q8Isyf9rfI6bEuvArKtnczll/0=
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=wbHLMlgh03fIpDUBv+BU4XZrrjI=; b=VMAVAbk6ZRL
	Z5KfPOs6cMEzMrpC3gZYcfRDvuBFlO5zAmrHsNmtj75vupJ4uJW3HhfpAlefPPlZ
	NYYrpc2uY3xkpgMv0yCOks2G1vAoKwxPEIPPBPkqpZnr3jhiTJMFMdiqdWBvReWk
	zMYwhh7yQJRBpIMAexXdGfVZ1YLAuya0=
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 498905EC082; 
	Mon,  9 Jan 2012 13:39:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ee6a41ae9dcb0a14c95e2856f9da7c2e9260c7a8
Message-Id: <ee6a41ae9dcb0a14c95e.1326145401@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326145399@xdev.gridcentric.ca>
References: <patchbomb.1326145399@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:43:21 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Add correct const-ness to memshr tool
	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

 tools/blktap2/drivers/Makefile  |  2 +-
 tools/blktap2/drivers/tapdisk.h |  4 ++++
 tools/memshr/interface.c        |  2 +-
 tools/memshr/memshr.h           |  2 +-
 tools/memshr/shm.c              |  2 +-
 tools/memshr/shm.h              |  2 +-
 6 files changed, 9 insertions(+), 5 deletions(-)


This patch addresses some of the compile and link issues with the memshr
module.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2d3804d81c3c -r ee6a41ae9dcb 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 2d3804d81c3c -r ee6a41ae9dcb 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))
diff -r 2d3804d81c3c -r ee6a41ae9dcb tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -123,7 +123,7 @@ void memshr_vbd_initialize(void)
     vbd_info.enabled = 1;
 }
 
-uint16_t memshr_vbd_image_get(char* file)
+uint16_t memshr_vbd_image_get(const char* file)
 {
     uint16_t id;
 
diff -r 2d3804d81c3c -r ee6a41ae9dcb tools/memshr/memshr.h
--- a/tools/memshr/memshr.h
+++ b/tools/memshr/memshr.h
@@ -28,7 +28,7 @@ typedef uint64_t xen_mfn_t;
 extern void memshr_set_domid(int domid);
 extern void memshr_daemon_initialize(void);
 extern void memshr_vbd_initialize(void);
-extern uint16_t memshr_vbd_image_get(char* file);
+extern uint16_t memshr_vbd_image_get(const char* file);
 extern void memshr_vbd_image_put(uint16_t memshr_id);
 extern int memshr_vbd_issue_ro_request(char *buf,
                                        grant_ref_t gref,
diff -r 2d3804d81c3c -r ee6a41ae9dcb tools/memshr/shm.c
--- a/tools/memshr/shm.c
+++ b/tools/memshr/shm.c
@@ -187,7 +187,7 @@ struct blockshr_hash * shm_blockshr_hash
     return h;
 } 
 
-uint16_t shm_vbd_image_get(char* file, vbd_image_info_t *vbd_imgs)
+uint16_t shm_vbd_image_get(const char* file, vbd_image_info_t *vbd_imgs)
 {
     vbd_image_info_t *img, *next_img;
     int i, img_id;
diff -r 2d3804d81c3c -r ee6a41ae9dcb tools/memshr/shm.h
--- a/tools/memshr/shm.h
+++ b/tools/memshr/shm.h
@@ -44,7 +44,7 @@ typedef struct shared_memshr_info {
 shared_memshr_info_t * shm_shared_info_open(int unlink);
 struct fgprtshr_hash * shm_fgprtshr_hash_open(int unlink);
 struct blockshr_hash * shm_blockshr_hash_open(int unlink);
-uint16_t shm_vbd_image_get(char* file, vbd_image_info_t *vbd_imgs);
+uint16_t shm_vbd_image_get(const char* file, vbd_image_info_t *vbd_imgs);
 void     shm_vbd_image_put(uint16_t memshr_id, vbd_image_info_t *vbd_imgs);
 
 #endif /* __SHM_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21: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 1RkMwQ-0006Rw-BM; Mon, 09 Jan 2012 21:39:42 +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 1RkMwP-0006Qg-6Y
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:39:41 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326145174!10259237!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2Njg5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6780 invoked from network); 9 Jan 2012 21:39:34 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-11.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 21:39:34 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id CD8B15EC083;
	Mon,  9 Jan 2012 13:39: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=AiG4qhl0Rdp71JM+Xmrgp0lgS4Gl3HLGc4dkwnpk7u9h
	zoSuL6DpHLr8/7bI6qpuDKzgu03YfjZ1p6gR3jbYIt1KHGF2iZ2nitDNejI4tUf/
	AKRg5NUgKoieeb/Qiwv0OAjdmGhKvALv6wnF0q8Isyf9rfI6bEuvArKtnczll/0=
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=wbHLMlgh03fIpDUBv+BU4XZrrjI=; b=VMAVAbk6ZRL
	Z5KfPOs6cMEzMrpC3gZYcfRDvuBFlO5zAmrHsNmtj75vupJ4uJW3HhfpAlefPPlZ
	NYYrpc2uY3xkpgMv0yCOks2G1vAoKwxPEIPPBPkqpZnr3jhiTJMFMdiqdWBvReWk
	zMYwhh7yQJRBpIMAexXdGfVZ1YLAuya0=
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 498905EC082; 
	Mon,  9 Jan 2012 13:39:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ee6a41ae9dcb0a14c95e2856f9da7c2e9260c7a8
Message-Id: <ee6a41ae9dcb0a14c95e.1326145401@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326145399@xdev.gridcentric.ca>
References: <patchbomb.1326145399@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:43:21 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Add correct const-ness to memshr tool
	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

 tools/blktap2/drivers/Makefile  |  2 +-
 tools/blktap2/drivers/tapdisk.h |  4 ++++
 tools/memshr/interface.c        |  2 +-
 tools/memshr/memshr.h           |  2 +-
 tools/memshr/shm.c              |  2 +-
 tools/memshr/shm.h              |  2 +-
 6 files changed, 9 insertions(+), 5 deletions(-)


This patch addresses some of the compile and link issues with the memshr
module.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2d3804d81c3c -r ee6a41ae9dcb 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 2d3804d81c3c -r ee6a41ae9dcb 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))
diff -r 2d3804d81c3c -r ee6a41ae9dcb tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -123,7 +123,7 @@ void memshr_vbd_initialize(void)
     vbd_info.enabled = 1;
 }
 
-uint16_t memshr_vbd_image_get(char* file)
+uint16_t memshr_vbd_image_get(const char* file)
 {
     uint16_t id;
 
diff -r 2d3804d81c3c -r ee6a41ae9dcb tools/memshr/memshr.h
--- a/tools/memshr/memshr.h
+++ b/tools/memshr/memshr.h
@@ -28,7 +28,7 @@ typedef uint64_t xen_mfn_t;
 extern void memshr_set_domid(int domid);
 extern void memshr_daemon_initialize(void);
 extern void memshr_vbd_initialize(void);
-extern uint16_t memshr_vbd_image_get(char* file);
+extern uint16_t memshr_vbd_image_get(const char* file);
 extern void memshr_vbd_image_put(uint16_t memshr_id);
 extern int memshr_vbd_issue_ro_request(char *buf,
                                        grant_ref_t gref,
diff -r 2d3804d81c3c -r ee6a41ae9dcb tools/memshr/shm.c
--- a/tools/memshr/shm.c
+++ b/tools/memshr/shm.c
@@ -187,7 +187,7 @@ struct blockshr_hash * shm_blockshr_hash
     return h;
 } 
 
-uint16_t shm_vbd_image_get(char* file, vbd_image_info_t *vbd_imgs)
+uint16_t shm_vbd_image_get(const char* file, vbd_image_info_t *vbd_imgs)
 {
     vbd_image_info_t *img, *next_img;
     int i, img_id;
diff -r 2d3804d81c3c -r ee6a41ae9dcb tools/memshr/shm.h
--- a/tools/memshr/shm.h
+++ b/tools/memshr/shm.h
@@ -44,7 +44,7 @@ typedef struct shared_memshr_info {
 shared_memshr_info_t * shm_shared_info_open(int unlink);
 struct fgprtshr_hash * shm_fgprtshr_hash_open(int unlink);
 struct blockshr_hash * shm_blockshr_hash_open(int unlink);
-uint16_t shm_vbd_image_get(char* file, vbd_image_info_t *vbd_imgs);
+uint16_t shm_vbd_image_get(const char* file, vbd_image_info_t *vbd_imgs);
 void     shm_vbd_image_put(uint16_t memshr_id, vbd_image_info_t *vbd_imgs);
 
 #endif /* __SHM_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 21:41:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMxo-0006op-Tp; Mon, 09 Jan 2012 21:41: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 1RkMxn-0006n7-CC
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:41:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326145260!9709704!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDI2Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6761 invoked from network); 9 Jan 2012 21:41:01 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-13.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 21:41:01 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 48BD260408D;
	Mon,  9 Jan 2012 13:41:00 -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=c7VlcnbuVYRAksjuRyeolx
	vJacGYMFXPf1GhV8O1VhK6TLb9DasdBVLoavbvcxbogLutnstdkP5hnXA7nS+eNo
	OYZmSKGwxOshCMxk8oez6vs5anm7LRmctWPbzy5n0iu9HH/K5C5IKM/mC7VNiPeZ
	KmRAKbkkwMYLZVUzWM/I8=
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=8ZNpoYcpT9D1
	mSSNl2jMLlkY+qY=; b=Mr1L8QsrkdTXlZ6XpJTOatp0M/dD8UnFv8UaqqHvurzD
	3L0FOWjyaeI/BA4sUKkeHb9LEgeYPpjjn8M6tUFK1XCDtjWD0BUF3OtMxonIRc1W
	fNbOA3anYCRqjY4QJ8cS00Z0s/XOX0t86ix6/j2tOrjXkyG2uloNH1r4SMQZ3fM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id A8679604089; 
	Mon,  9 Jan 2012 13:40:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2ed49e894084fb18ea58ec68333127ad34cec450
Message-Id: <2ed49e894084fb18ea58.1326145507@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:45:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] 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 |  88 +++++++++++++++++++++---------------------
 2 files changed, 48 insertions(+), 46 deletions(-)


No functional changes, only code style issues.

One small diff in mem_sharing_gref_to_gfn() looks like a logic change,
but it's not.  The flow was confusing, so it's been clarified.

This version does not differ from the last iteration.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r ee6a41ae9dcb -r 2ed49e894084 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4316,9 +4316,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);
@@ -4335,7 +4335,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 ee6a41ae9dcb -r 2ed49e894084 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);
@@ -293,7 +293,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 +317,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 +341,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 +360,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 +371,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 +427,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 +468,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 +502,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 +608,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 +621,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 +635,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 +693,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 +731,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 +744,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 +763,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 Mon Jan 09 21:41:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 21:41:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkMxo-0006op-Tp; Mon, 09 Jan 2012 21:41: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 1RkMxn-0006n7-CC
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 21:41:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326145260!9709704!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNDI2Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6761 invoked from network); 9 Jan 2012 21:41:01 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-13.tower-216.messagelabs.com with SMTP;
	9 Jan 2012 21:41:01 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 48BD260408D;
	Mon,  9 Jan 2012 13:41:00 -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=c7VlcnbuVYRAksjuRyeolx
	vJacGYMFXPf1GhV8O1VhK6TLb9DasdBVLoavbvcxbogLutnstdkP5hnXA7nS+eNo
	OYZmSKGwxOshCMxk8oez6vs5anm7LRmctWPbzy5n0iu9HH/K5C5IKM/mC7VNiPeZ
	KmRAKbkkwMYLZVUzWM/I8=
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=8ZNpoYcpT9D1
	mSSNl2jMLlkY+qY=; b=Mr1L8QsrkdTXlZ6XpJTOatp0M/dD8UnFv8UaqqHvurzD
	3L0FOWjyaeI/BA4sUKkeHb9LEgeYPpjjn8M6tUFK1XCDtjWD0BUF3OtMxonIRc1W
	fNbOA3anYCRqjY4QJ8cS00Z0s/XOX0t86ix6/j2tOrjXkyG2uloNH1r4SMQZ3fM=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id A8679604089; 
	Mon,  9 Jan 2012 13:40:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2ed49e894084fb18ea58ec68333127ad34cec450
Message-Id: <2ed49e894084fb18ea58.1326145507@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 09 Jan 2012 16:45:07 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] 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 |  88 +++++++++++++++++++++---------------------
 2 files changed, 48 insertions(+), 46 deletions(-)


No functional changes, only code style issues.

One small diff in mem_sharing_gref_to_gfn() looks like a logic change,
but it's not.  The flow was confusing, so it's been clarified.

This version does not differ from the last iteration.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r ee6a41ae9dcb -r 2ed49e894084 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4316,9 +4316,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);
@@ -4335,7 +4335,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 ee6a41ae9dcb -r 2ed49e894084 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);
@@ -293,7 +293,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 +317,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 +341,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 +360,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 +371,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 +427,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 +468,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 +502,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 +608,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 +621,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 +635,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 +693,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 +731,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 +744,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 +763,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 Mon Jan 09 22:27:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 22:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkNg5-0007qB-8K; Mon, 09 Jan 2012 22:26:53 +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 1RkNg3-0007q2-D4; Mon, 09 Jan 2012 22:26:51 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326148002!8414787!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 2870 invoked from network); 9 Jan 2012 22:26:45 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Jan 2012 22:26:45 -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 1RkNfn-00066i-Vk; Tue, 10 Jan 2012 09:26: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); 
	Tue, 10 Jan 2012 09:26: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;
	Tue, 10 Jan 2012 09:26:35 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Thread-Topic: [Xen-devel] Features and bug-fixes that went in Linux 3.2
Thread-Index: AQHMzxc0uBc5EJ5yEE2+1LlqwPcRdZYEnTkA
Date: Mon, 9 Jan 2012 22:26:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
References: <20120109213039.GC4773@phenom.dumpdata.com>
In-Reply-To: <20120109213039.GC4773@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Jan 2012 22:26:36.0141 (UTC)
	FILETIME=[BF8A39D0:01CCCF1D]
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>  - Initial work laid out for netback page-flipping (also called zero-copying).

Isn't this how it used to work originally?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 22:27:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 22:27:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkNg5-0007qB-8K; Mon, 09 Jan 2012 22:26:53 +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 1RkNg3-0007q2-D4; Mon, 09 Jan 2012 22:26:51 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326148002!8414787!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 2870 invoked from network); 9 Jan 2012 22:26:45 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-8.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	9 Jan 2012 22:26:45 -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 1RkNfn-00066i-Vk; Tue, 10 Jan 2012 09:26: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); 
	Tue, 10 Jan 2012 09:26: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;
	Tue, 10 Jan 2012 09:26:35 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Thread-Topic: [Xen-devel] Features and bug-fixes that went in Linux 3.2
Thread-Index: AQHMzxc0uBc5EJ5yEE2+1LlqwPcRdZYEnTkA
Date: Mon, 9 Jan 2012 22:26:34 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
References: <20120109213039.GC4773@phenom.dumpdata.com>
In-Reply-To: <20120109213039.GC4773@phenom.dumpdata.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Jan 2012 22:26:36.0141 (UTC)
	FILETIME=[BF8A39D0:01CCCF1D]
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>  - Initial work laid out for netback page-flipping (also called zero-copying).

Isn't this how it used to work originally?

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 22:38:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 22:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkNqh-0008Qc-4T; Mon, 09 Jan 2012 22:37: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 1RkNqf-0008QM-Vs; Mon, 09 Jan 2012 22:37:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326148663!9714342!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDE0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10479 invoked from network); 9 Jan 2012 22:37:43 -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 Jan 2012 22:37:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,482,1320624000"; 
   d="scan'208";a="9908781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 22:37: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; Mon, 9 Jan 2012
	22:37:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
References: <20120109213039.GC4773@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
Organization: Citrix Systems, Inc.
Date: Mon, 9 Jan 2012 22:37:42 +0000
Message-ID: <1326148662.29084.77.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>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 22:26 +0000, James Harper wrote:
> >  - Initial work laid out for netback page-flipping (also called zero-copying).
> 
> Isn't this how it used to work originally?

Some of the original infrastructure for doing this was not upstreamable
(the PageForeign stuff) so while upstream netback I decided to go with a
simpler/less-intrusive copying mode so we could have some sort of
networking support in mainline. 

I've been working on re-laying the necessary infrastructure to allow for
page flipping/mapping mode in upstream (as well as fixing another
generic class of bug) -- you can see the "skb frag destructor" patches
on the netdev list.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 22:38:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 22:38:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkNqh-0008Qc-4T; Mon, 09 Jan 2012 22:37: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 1RkNqf-0008QM-Vs; Mon, 09 Jan 2012 22:37:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326148663!9714342!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDE0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10479 invoked from network); 9 Jan 2012 22:37:43 -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 Jan 2012 22:37:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,482,1320624000"; 
   d="scan'208";a="9908781"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	09 Jan 2012 22:37: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; Mon, 9 Jan 2012
	22:37:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
References: <20120109213039.GC4773@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
Organization: Citrix Systems, Inc.
Date: Mon, 9 Jan 2012 22:37:42 +0000
Message-ID: <1326148662.29084.77.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>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 22:26 +0000, James Harper wrote:
> >  - Initial work laid out for netback page-flipping (also called zero-copying).
> 
> Isn't this how it used to work originally?

Some of the original infrastructure for doing this was not upstreamable
(the PageForeign stuff) so while upstream netback I decided to go with a
simpler/less-intrusive copying mode so we could have some sort of
networking support in mainline. 

I've been working on re-laying the necessary infrastructure to allow for
page flipping/mapping mode in upstream (as well as fixing another
generic class of bug) -- you can see the "skb frag destructor" patches
on the netdev list.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 09 23:07:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 23: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 1RkOJS-0000fR-F8; Mon, 09 Jan 2012 23:07:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tinnycloud@hotmail.com>) id 1RkOJQ-0000fD-V4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 23:07:33 +0000
X-Env-Sender: tinnycloud@hotmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326150446!1521271!1
X-Originating-IP: [65.55.111.101]
X-SpamReason: No, hits=0.3 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_2,MSGID_FROM_MTA_HEADER,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25276 invoked from network); 9 Jan 2012 23:07:26 -0000
Received: from blu0-omc2-s26.blu0.hotmail.com (HELO
	blu0-omc2-s26.blu0.hotmail.com) (65.55.111.101)
	by server-9.tower-21.messagelabs.com with SMTP;
	9 Jan 2012 23:07:26 -0000
Received: from BLU0-SMTP359 ([65.55.111.73]) by blu0-omc2-s26.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 9 Jan 2012 15:07:25 -0800
X-Originating-IP: [115.195.39.185]
X-Originating-Email: [tinnycloud@hotmail.com]
Message-ID: <BLU0-SMTP35900BADBF0963E79F77747DA980@phx.gbl>
Received: from [192.168.1.100] ([115.195.39.185]) by BLU0-SMTP359.phx.gbl over
	TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 9 Jan 2012 15:07:24 -0800
References: <mailman.6093.1325902643.12970.xen-devel@lists.xensource.com>
	<BLU157-W65C4641D5245A308C327C2DA9A0@phx.gbl>
	<20120109160919.GA28700@phenom.dumpdata.com>
In-Reply-To: <20120109160919.GA28700@phenom.dumpdata.com>
MIME-Version: 1.0 (iPad Mail 8G4)
X-Mailer: iPad Mail (8G4)
From: hotmaim <tinnycloud@hotmail.com>
Date: Tue, 10 Jan 2012 07:12:57 +0800
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-OriginalArrivalTime: 09 Jan 2012 23:07:24.0847 (UTC)
	FILETIME=[73151BF0:01CCCF23]
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux Container and Tapdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgoK1NogMjAxMi0xLTEwo6wwOjA5o6xLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxr
QG9yYWNsZS5jb20+IAoKPiBPbiBTYXQsIEphbiAwNywgMjAxMiBhdCAxMjoxNzoyM1BNICswODAw
LCBNYW9YaWFveXVuIHdyb3RlOgo+PiAKPj4gSGk6Cj4+IAo+PiAgICAgIFJlY2VudGx5IEkgaGF2
ZSBzb21lIHN0dWR5IG9uIGxpbnV4IGNvbnRhaW5lcihseGMpLCB3aGljaCBpcyBhIGxpZ2h0IHdl
aWdodCBPUyBsZXZlbAo+PiB2aXJ0dWFsaXphdGlvbi4KPj4gCj4+ICAgICBXaXRoIHRoZSBwcmV2
aW91cyBrbm93bGVkZ2Ugb2YgdGFwZGlzaywgSSBoYXZlIGFuIGFzc3VtcHRpb24gdGhhdCwgSSBt
YXkgY291bGQKPj4gdXNlIHRoZSB2aGQgZm9yIGVhY2ggY29udGFpbmVyIHRvIHNlcGVyYXRlIHRo
ZSBzdG9yYWdlIG9mIGFsbCBjb250YWluZXJzLCBvciBldmVuIGluIAo+PiBsYXRlciBkYXlzLCB2
aGQgaXMgc3RvcmVkIGluIGRpc3RyaWJ1dGVkIHN0b3JhZ2UsIGNvbnRhaW5lciBjb3VsZCBiZSBt
aWdyYXRlZC4KPj4gCj4+ICAgICAgQnVpbGQgZmlsZXN5c3RlbSBvbiB0YXBkZXYgYW5kIG1vdW50
IGl0IHVuZGVyIHNvbWUgZGlyZWN0b3J5LCBwdXQgdGhlIHJvb3RmcyBvZiAKPiAKPiBIb3cgd291
bGQgeW91ICJtb3VudCIgYSB0YXBkZXYgZmlsZXN5c3RlbT8KCldoZW4gYSB0YXBkaXNrIHN0YXJ0
cyx0aGVyZSBpcyBhIHRhcGRldiBkZXZpY2UgdW5kZXIgL2Rldi90YXBkZXZYLCBYIGlzIHN0aCBs
aWtlIGEsYixjLC4uLgouIE1rZnMuZXh0MyBvbiB0aGlzIGRldmljZSBhbmQgbW91bnQgaXQgdG8g
L21udC90YXBkZXZYLCBmaW5hbGx5IGJpbmQgbW91bnQgdG8gTFhDIC4KPiAKPiBCdXQgbW9yZSBp
bnRlcmVzdGluZ2x5LCBob3cgd291bGQgeW91IG1pZ3JhdGUgeW91ciB0YXAgZGlzaz8gSXMgaXQg
b24gTkZTIG9yIE9DRlMyCj4gb3IgaVNDU0k/IElmIHNvLCB3aHkgbm90IGp1c3QgZXhwYW5kIHRo
ZSBmaWxlc3lzdGVtIG9uIGFuIGlTQ1NJIGRpc2sgYW5kIG1vdW50IGl0Cj4gb24gb3RoZXIgbWFj
aGluZXMgYW5kICJtaWdyYXRlIGl0Ii4KCldlIGhhdmUgaGFkb29wIGZvciB0aGUgc3RvcmFnZSwg
VkhEIGluIEhERlMgaXMgbG9naWNhbCwgd2hpY2ggY2FuLHQgZGlyZWN0bHkgbW91bnRlZC4KPiAK
Pj4gY29udGFpbmVyIGludG8gdGhhdCBkaXIsIGFuZCBzdGFydCB0aGUgbHhjLCBJIGhhdmVuJ3Qg
dHJ5IHRoaXMsIHdpbGwgdHJ5IGxhdGVyLgo+IAo+IEkgYW0gbm90IHJlYWxseSBzdXJlIGhvdyBv
bmUgd291bGQgZnJlZXplIGFuZCBtaWdyYXRlIHRoZSBwcm9jZXNzZXM/IERvZXMgdGhlCj4gY2dy
b3VwcyBoYXZlIHRoYXQgZnVuY3Rpb25hbGl0eT8KPiAKCkNsb3NlIGxvY2FsIHRhcGRpc2ssIHN0
YXJ0IGl0IG9uIHJlbW90ZSBob3N0LCByZW9wZW4gdGhlIFZIRCBvbiBIREZTLgpseGMgc3VwcG9y
dHMgc3VwcG9ydHMgZnJlZXplIHRoZSBwcm9jZXNzZXMgaW4gY29udGFpbmVyLCBpLG0gbm90IHN1
cmUsIHdlaHRoZXIgbGl2ZSBtaWdyYXRlIGNvdWxkIGJlIGltcGxlbWVudGVkIGluIGZ1dHVyZS4K
ClRoYW5rcy4KCj4+IAo+PiAgICAgSSBwb3N0IG15IGlkZWEgaGVyZSwgaG9wZSBzb21lb25lIGhh
cyBvbmUgZm9yc2VlIGNvbW1lbnRzLgo+PiAKPj4gICAgIFRoYW5rcy4KPj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAo+IAo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwo+PiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4+IFhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCj4+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZl
bAo+IAo+IAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 09 23:07:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 09 Jan 2012 23: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 1RkOJS-0000fR-F8; Mon, 09 Jan 2012 23:07:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tinnycloud@hotmail.com>) id 1RkOJQ-0000fD-V4
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 23:07:33 +0000
X-Env-Sender: tinnycloud@hotmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326150446!1521271!1
X-Originating-IP: [65.55.111.101]
X-SpamReason: No, hits=0.3 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	MIME_QP_LONG_LINE,ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,
	ML_RADAR_SPEW_LINKS_2,MSGID_FROM_MTA_HEADER,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25276 invoked from network); 9 Jan 2012 23:07:26 -0000
Received: from blu0-omc2-s26.blu0.hotmail.com (HELO
	blu0-omc2-s26.blu0.hotmail.com) (65.55.111.101)
	by server-9.tower-21.messagelabs.com with SMTP;
	9 Jan 2012 23:07:26 -0000
Received: from BLU0-SMTP359 ([65.55.111.73]) by blu0-omc2-s26.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 9 Jan 2012 15:07:25 -0800
X-Originating-IP: [115.195.39.185]
X-Originating-Email: [tinnycloud@hotmail.com]
Message-ID: <BLU0-SMTP35900BADBF0963E79F77747DA980@phx.gbl>
Received: from [192.168.1.100] ([115.195.39.185]) by BLU0-SMTP359.phx.gbl over
	TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); 
	Mon, 9 Jan 2012 15:07:24 -0800
References: <mailman.6093.1325902643.12970.xen-devel@lists.xensource.com>
	<BLU157-W65C4641D5245A308C327C2DA9A0@phx.gbl>
	<20120109160919.GA28700@phenom.dumpdata.com>
In-Reply-To: <20120109160919.GA28700@phenom.dumpdata.com>
MIME-Version: 1.0 (iPad Mail 8G4)
X-Mailer: iPad Mail (8G4)
From: hotmaim <tinnycloud@hotmail.com>
Date: Tue, 10 Jan 2012 07:12:57 +0800
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-OriginalArrivalTime: 09 Jan 2012 23:07:24.0847 (UTC)
	FILETIME=[73151BF0:01CCCF23]
Cc: xen devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Linux Container and Tapdev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

CgoK1NogMjAxMi0xLTEwo6wwOjA5o6xLb25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZC53aWxr
QG9yYWNsZS5jb20+IAoKPiBPbiBTYXQsIEphbiAwNywgMjAxMiBhdCAxMjoxNzoyM1BNICswODAw
LCBNYW9YaWFveXVuIHdyb3RlOgo+PiAKPj4gSGk6Cj4+IAo+PiAgICAgIFJlY2VudGx5IEkgaGF2
ZSBzb21lIHN0dWR5IG9uIGxpbnV4IGNvbnRhaW5lcihseGMpLCB3aGljaCBpcyBhIGxpZ2h0IHdl
aWdodCBPUyBsZXZlbAo+PiB2aXJ0dWFsaXphdGlvbi4KPj4gCj4+ICAgICBXaXRoIHRoZSBwcmV2
aW91cyBrbm93bGVkZ2Ugb2YgdGFwZGlzaywgSSBoYXZlIGFuIGFzc3VtcHRpb24gdGhhdCwgSSBt
YXkgY291bGQKPj4gdXNlIHRoZSB2aGQgZm9yIGVhY2ggY29udGFpbmVyIHRvIHNlcGVyYXRlIHRo
ZSBzdG9yYWdlIG9mIGFsbCBjb250YWluZXJzLCBvciBldmVuIGluIAo+PiBsYXRlciBkYXlzLCB2
aGQgaXMgc3RvcmVkIGluIGRpc3RyaWJ1dGVkIHN0b3JhZ2UsIGNvbnRhaW5lciBjb3VsZCBiZSBt
aWdyYXRlZC4KPj4gCj4+ICAgICAgQnVpbGQgZmlsZXN5c3RlbSBvbiB0YXBkZXYgYW5kIG1vdW50
IGl0IHVuZGVyIHNvbWUgZGlyZWN0b3J5LCBwdXQgdGhlIHJvb3RmcyBvZiAKPiAKPiBIb3cgd291
bGQgeW91ICJtb3VudCIgYSB0YXBkZXYgZmlsZXN5c3RlbT8KCldoZW4gYSB0YXBkaXNrIHN0YXJ0
cyx0aGVyZSBpcyBhIHRhcGRldiBkZXZpY2UgdW5kZXIgL2Rldi90YXBkZXZYLCBYIGlzIHN0aCBs
aWtlIGEsYixjLC4uLgouIE1rZnMuZXh0MyBvbiB0aGlzIGRldmljZSBhbmQgbW91bnQgaXQgdG8g
L21udC90YXBkZXZYLCBmaW5hbGx5IGJpbmQgbW91bnQgdG8gTFhDIC4KPiAKPiBCdXQgbW9yZSBp
bnRlcmVzdGluZ2x5LCBob3cgd291bGQgeW91IG1pZ3JhdGUgeW91ciB0YXAgZGlzaz8gSXMgaXQg
b24gTkZTIG9yIE9DRlMyCj4gb3IgaVNDU0k/IElmIHNvLCB3aHkgbm90IGp1c3QgZXhwYW5kIHRo
ZSBmaWxlc3lzdGVtIG9uIGFuIGlTQ1NJIGRpc2sgYW5kIG1vdW50IGl0Cj4gb24gb3RoZXIgbWFj
aGluZXMgYW5kICJtaWdyYXRlIGl0Ii4KCldlIGhhdmUgaGFkb29wIGZvciB0aGUgc3RvcmFnZSwg
VkhEIGluIEhERlMgaXMgbG9naWNhbCwgd2hpY2ggY2FuLHQgZGlyZWN0bHkgbW91bnRlZC4KPiAK
Pj4gY29udGFpbmVyIGludG8gdGhhdCBkaXIsIGFuZCBzdGFydCB0aGUgbHhjLCBJIGhhdmVuJ3Qg
dHJ5IHRoaXMsIHdpbGwgdHJ5IGxhdGVyLgo+IAo+IEkgYW0gbm90IHJlYWxseSBzdXJlIGhvdyBv
bmUgd291bGQgZnJlZXplIGFuZCBtaWdyYXRlIHRoZSBwcm9jZXNzZXM/IERvZXMgdGhlCj4gY2dy
b3VwcyBoYXZlIHRoYXQgZnVuY3Rpb25hbGl0eT8KPiAKCkNsb3NlIGxvY2FsIHRhcGRpc2ssIHN0
YXJ0IGl0IG9uIHJlbW90ZSBob3N0LCByZW9wZW4gdGhlIFZIRCBvbiBIREZTLgpseGMgc3VwcG9y
dHMgc3VwcG9ydHMgZnJlZXplIHRoZSBwcm9jZXNzZXMgaW4gY29udGFpbmVyLCBpLG0gbm90IHN1
cmUsIHdlaHRoZXIgbGl2ZSBtaWdyYXRlIGNvdWxkIGJlIGltcGxlbWVudGVkIGluIGZ1dHVyZS4K
ClRoYW5rcy4KCj4+IAo+PiAgICAgSSBwb3N0IG15IGlkZWEgaGVyZSwgaG9wZSBzb21lb25lIGhh
cyBvbmUgZm9yc2VlIGNvbW1lbnRzLgo+PiAKPj4gICAgIFRoYW5rcy4KPj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAo+IAo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwo+PiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4+IFhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCj4+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZl
bAo+IAo+IAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 10 00:42:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 00:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkPmj-0001lL-VL; Tue, 10 Jan 2012 00:41:53 +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 1RkPmj-0001lE-2j
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 00:41:53 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326156106!8445786!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIyODUy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29014 invoked from network); 10 Jan 2012 00:41:47 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-174.messagelabs.com with SMTP;
	10 Jan 2012 00:41:47 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 09 Jan 2012 16:41:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="96295718"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 09 Jan 2012 16:41:44 -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; Tue, 10 Jan 2012 08:40:36 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 08:40:35 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH v2] x86: add a new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0P//f4kA//kkYOCADTRygP/+65eQ
Date: Tue, 10 Jan 2012 00:40:34 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE017924@SHSMSX102.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
	<4F0B1F47020000780006B4D3@nat28.tlf.novell.com>
In-Reply-To: <4F0B1F47020000780006B4D3@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>, "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 v2] x86: add a new SMP bring up way for
	tboot 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=A02012-01-10:
>>>> On 09.01.12 at 17:01, "Wei, Gang" <gang.wei@intel.com> wrote:
>> tboot may be trying to put APs waiting in MWAIT loops before launching X=
en.
>> Xen could check the new flag field in v6 tboot shared page for the
>> hint. If TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP
>> have to write the monitored memory(g_tboot_shared->ap_wake_trigger)
>> to bring APs out of MWAIT loops. The sipi vector should be written
>> in g_tboot_shared->ap_wake_addr before waking up APs.
>> =

>> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
>> Signed-off-by: Shane Wang <shane.wang@intel.com>
>> Signed-off-by: Gang Wei <gang.wei@intel.com>
>> =

>> diff -r 8087674cceb9 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c	Thu Jan 05 22:42:02 2012 +0800
>> +++ b/xen/arch/x86/smpboot.c	Mon Jan 09 23:55:41 2012 +0800
>> @@ -586,7 +586,10 @@
>>      smpboot_setup_warm_reset_vector(start_eip);
>>      =

>>      /* Starting actual IPI sequence... */
>> -    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
>> +    if ( tboot_in_measured_env() )
>> +        boot_error =3D tboot_wake_ap(apicid, start_eip);
>> +    else
>> +        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
> =

> I'm afraid this is broken now for older tboot - you want to call
> wakeup_secondary_cpu() if tboot_wake_ap() failed. All I had asked in
> the first review round was that you don't call
> tboot_wake_ap() without tboot_in_measured_env() returning true.

Oh, yes. I should not do this in mid-night. V3 patch will fix it.

Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 00:42:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 00:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkPmj-0001lL-VL; Tue, 10 Jan 2012 00:41:53 +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 1RkPmj-0001lE-2j
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 00:41:53 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326156106!8445786!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIyODUy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29014 invoked from network); 10 Jan 2012 00:41:47 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-5.tower-174.messagelabs.com with SMTP;
	10 Jan 2012 00:41:47 -0000
Received: from orsmga002.jf.intel.com ([10.7.209.21])
	by orsmga102.jf.intel.com with ESMTP; 09 Jan 2012 16:41:45 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="96295718"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga002.jf.intel.com with ESMTP; 09 Jan 2012 16:41:44 -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; Tue, 10 Jan 2012 08:40:36 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 08:40:35 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Thread-Topic: [PATCH v2] x86: add a new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0P//f4kA//kkYOCADTRygP/+65eQ
Date: Tue, 10 Jan 2012 00:40:34 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE017924@SHSMSX102.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
	<4F0B1F47020000780006B4D3@nat28.tlf.novell.com>
In-Reply-To: <4F0B1F47020000780006B4D3@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>, "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 v2] x86: add a new SMP bring up way for
	tboot 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=A02012-01-10:
>>>> On 09.01.12 at 17:01, "Wei, Gang" <gang.wei@intel.com> wrote:
>> tboot may be trying to put APs waiting in MWAIT loops before launching X=
en.
>> Xen could check the new flag field in v6 tboot shared page for the
>> hint. If TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP
>> have to write the monitored memory(g_tboot_shared->ap_wake_trigger)
>> to bring APs out of MWAIT loops. The sipi vector should be written
>> in g_tboot_shared->ap_wake_addr before waking up APs.
>> =

>> Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
>> Signed-off-by: Shane Wang <shane.wang@intel.com>
>> Signed-off-by: Gang Wei <gang.wei@intel.com>
>> =

>> diff -r 8087674cceb9 xen/arch/x86/smpboot.c
>> --- a/xen/arch/x86/smpboot.c	Thu Jan 05 22:42:02 2012 +0800
>> +++ b/xen/arch/x86/smpboot.c	Mon Jan 09 23:55:41 2012 +0800
>> @@ -586,7 +586,10 @@
>>      smpboot_setup_warm_reset_vector(start_eip);
>>      =

>>      /* Starting actual IPI sequence... */
>> -    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
>> +    if ( tboot_in_measured_env() )
>> +        boot_error =3D tboot_wake_ap(apicid, start_eip);
>> +    else
>> +        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
> =

> I'm afraid this is broken now for older tboot - you want to call
> wakeup_secondary_cpu() if tboot_wake_ap() failed. All I had asked in
> the first review round was that you don't call
> tboot_wake_ap() without tboot_in_measured_env() returning true.

Oh, yes. I should not do this in mid-night. V3 patch will fix it.

Jimmy



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 00:43:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 00:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkPnh-0001np-HB; Tue, 10 Jan 2012 00:42: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 1RkPng-0001nh-8o
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 00:42:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326156115!60119546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDE0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6369 invoked from network); 10 Jan 2012 00:41:55 -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;
	10 Jan 2012 00:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,483,1320624000"; 
   d="scan'208";a="9909964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 00:42:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 00:42: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 1RkPne-0004RL-Pt;
	Tue, 10 Jan 2012 00:42:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RkPne-0004uU-PJ;
	Tue, 10 Jan 2012 00:42:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10646-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Jan 2012 00:42:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10646: 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 10646 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10646/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 10645
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10645 pass in 10646

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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   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-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b2676ac1321
baseline version:
 xen                  4086e4811547

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=5b2676ac1321
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 5b2676ac1321
+ branch=xen-unstable
+ revision=5b2676ac1321
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 5b2676ac1321 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 7 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 Tue Jan 10 00:43:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 00:43:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkPnh-0001np-HB; Tue, 10 Jan 2012 00:42: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 1RkPng-0001nh-8o
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 00:42:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326156115!60119546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDE0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6369 invoked from network); 10 Jan 2012 00:41:55 -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;
	10 Jan 2012 00:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,483,1320624000"; 
   d="scan'208";a="9909964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 00:42:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 00:42: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 1RkPne-0004RL-Pt;
	Tue, 10 Jan 2012 00:42:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RkPne-0004uU-PJ;
	Tue, 10 Jan 2012 00:42:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10646-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Jan 2012 00:42:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10646: 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 10646 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10646/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 10645
 test-amd64-i386-xl-credit2    7 debian-install     fail in 10645 pass in 10646

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-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   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-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b2676ac1321
baseline version:
 xen                  4086e4811547

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=5b2676ac1321
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 5b2676ac1321
+ branch=xen-unstable
+ revision=5b2676ac1321
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 5b2676ac1321 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 7 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 Tue Jan 10 01:09:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 01:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkQCz-0005ym-CK; Tue, 10 Jan 2012 01:09:01 +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 1RkQCx-0005yh-PU
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 01:09:00 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326157732!10212574!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjM5MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1574 invoked from network); 10 Jan 2012 01:08:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-182.messagelabs.com with SMTP;
	10 Jan 2012 01:08:53 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 09 Jan 2012 17:08:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110474269"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga002.fm.intel.com with ESMTP; 09 Jan 2012 17:08:50 -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; Tue, 10 Jan 2012 09:07:43 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 10 Jan 2012 09:07:42 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.38]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 09:07:41 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v3] x86: add a new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0P//f4kA//kkYOCADTRygP/+65eQ//3QaSA=
Date: Tue, 10 Jan 2012 01:07:41 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE01797F@SHSMSX102.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
	<4F0B1F47020000780006B4D3@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BE017924@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE017924@SHSMSX102.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_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_"
MIME-Version: 1.0
Cc: "Keir\(Xen.org\)" <keir@xen.org>, "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 v3] x86: add a new SMP bring up way for tboot
	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_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

tboot may be trying to put APs waiting in MWAIT loops before launching Xen.=
 Xen could check the new flag field in v6 tboot shared page for the hint. I=
f TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write t=
he monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MW=
AIT loops. The sipi vector should be written in g_tboot_shared->ap_wake_add=
r before waking up APs.

Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r 8087674cceb9 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/arch/x86/smpboot.c	Tue Jan 10 09:01:25 2012 +0800
@@ -586,7 +586,13 @@
     smpboot_setup_warm_reset_vector(start_eip);
=20
     /* Starting actual IPI sequence... */
-    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
+    if ( tboot_in_measured_env() )
+        boot_error =3D tboot_wake_ap(apicid, start_eip);
+    else
+        boot_error =3D 1;
+
+    if ( boot_error )
+        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
=20
     if ( !boot_error )
     {
diff -r 8087674cceb9 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/arch/x86/tboot.c	Tue Jan 10 09:01:25 2012 +0800
@@ -123,6 +123,8 @@
     printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
     printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
     printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
+    if ( tboot_shared->version >=3D 6 )
+        printk("  flags: 0x%08x\n", tboot_shared->flags);
=20
     /* these will be needed by tboot_protect_mem_regions() and/or
        tboot_parse_dmar_table(), so get them now */
@@ -529,6 +531,18 @@
     panic("Memory integrity was lost on resume (%d)\n", error);
 }
=20
+int tboot_wake_ap(int apicid, unsigned long sipi_vec)
+{
+    if ( g_tboot_shared->version >=3D 6 &&
+         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
+    {
+        g_tboot_shared->ap_wake_addr =3D sipi_vec;
+        g_tboot_shared->ap_wake_trigger =3D apicid;
+        return 0;
+    }
+    return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 8087674cceb9 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/include/asm-x86/tboot.h	Tue Jan 10 09:01:25 2012 +0800
@@ -85,7 +85,7 @@
 typedef struct __packed {
     /* version 3+ fields: */
     uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08}=
 */
-    uint32_t  version;           /* Version number; currently supports 0.4=
 */
+    uint32_t  version;           /* Version number; currently supports 0.6=
 */
     uint32_t  log_addr;          /* physical addr of tb_log_t log */
     uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
     uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
@@ -99,6 +99,13 @@
     /* version 4+ fields: */
                                  /* populated by tboot; will be encrypted =
*/
     uint8_t   s3_key[TB_KEY_SIZE];
+    /* version 5+ fields: */
+    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
+    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI =
*/
+    /* version 6+ fields: */
+    uint32_t  flags;
+    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
+    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP *=
/
 } tboot_shared_t;
=20
 #define TB_SHUTDOWN_REBOOT      0
@@ -107,6 +114,9 @@
 #define TB_SHUTDOWN_S3          3
 #define TB_SHUTDOWN_HALT        4
=20
+#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use INIT-SIPI-=
SIPI
+                                                 if clear, ap_wake_* if se=
t */
+
 /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
 #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
                                { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
@@ -120,6 +130,7 @@
 int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
 int tboot_s3_resume(void);
 void tboot_s3_error(int error);
+int tboot_wake_ap(int apicid, unsigned long sipi_vec);
=20
 #endif /* __TBOOT_H__ */


--_002_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_
Content-Type: application/octet-stream;
	name="mwait-smp-up-for-tboot-v3.patch"
Content-Description: mwait-smp-up-for-tboot-v3.patch
Content-Disposition: attachment; filename="mwait-smp-up-for-tboot-v3.patch";
	size=4206; creation-date="Tue, 10 Jan 2012 01:04:27 GMT";
	modification-date="Tue, 10 Jan 2012 01:02:09 GMT"
Content-Transfer-Encoding: base64

eDg2OiBhZGQgYSBuZXcgU01QIGJyaW5nIHVwIHdheSBmb3IgdGJvb3QgY2FzZQoKdGJvb3QgbWF5
IGJlIHRyeWluZyB0byBwdXQgQVBzIHdhaXRpbmcgaW4gTVdBSVQgbG9vcHMgYmVmb3JlIGxhdW5j
aGluZyBYZW4uIFhlbiBjb3VsZCBjaGVjayB0aGUgbmV3IGZsYWcgZmllbGQgaW4gdjYgdGJvb3Qg
c2hhcmVkIHBhZ2UgZm9yIHRoZSBoaW50LiBJZiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCBiaXQg
aW4gZmxhZyBmaWVsZCBpcyBzZXQsIFhlbiBCU1AgaGF2ZSB0byB3cml0ZSB0aGUgbW9uaXRvcmVk
IG1lbW9yeShnX3Rib290X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyKSB0byBicmluZyBBUHMgb3V0
IG9mIE1XQUlUIGxvb3BzLiBUaGUgc2lwaSB2ZWN0b3Igc2hvdWxkIGJlIHdyaXR0ZW4gaW4gZ190
Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciBiZWZvcmUgd2FraW5nIHVwIEFQcy4KClNpZ25lZC1v
ZmYtYnk6IEpvc2VwaCBDaWh1bGEgPGpvc2VwaC5jaWh1bGFAaW50ZWwuY29tPgpTaWduZWQtb2Zm
LWJ5OiBTaGFuZSBXYW5nIDxzaGFuZS53YW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogR2Fu
ZyBXZWkgPGdhbmcud2VpQGludGVsLmNvbT4KCmRpZmYgLXIgODA4NzY3NGNjZWI5IHhlbi9hcmNo
L3g4Ni9zbXBib290LmMKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlUaHUgSmFuIDA1IDIy
OjQyOjAyIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlUdWUgSmFuIDEw
IDA5OjAxOjI1IDIwMTIgKzA4MDAKQEAgLTU4Niw3ICs1ODYsMTMgQEAKICAgICBzbXBib290X3Nl
dHVwX3dhcm1fcmVzZXRfdmVjdG9yKHN0YXJ0X2VpcCk7CiAKICAgICAvKiBTdGFydGluZyBhY3R1
YWwgSVBJIHNlcXVlbmNlLi4uICovCi0gICAgYm9vdF9lcnJvciA9IHdha2V1cF9zZWNvbmRhcnlf
Y3B1KGFwaWNpZCwgc3RhcnRfZWlwKTsKKyAgICBpZiAoIHRib290X2luX21lYXN1cmVkX2Vudigp
ICkKKyAgICAgICAgYm9vdF9lcnJvciA9IHRib290X3dha2VfYXAoYXBpY2lkLCBzdGFydF9laXAp
OworICAgIGVsc2UKKyAgICAgICAgYm9vdF9lcnJvciA9IDE7CisKKyAgICBpZiAoIGJvb3RfZXJy
b3IgKQorICAgICAgICBib290X2Vycm9yID0gd2FrZXVwX3NlY29uZGFyeV9jcHUoYXBpY2lkLCBz
dGFydF9laXApOwogCiAgICAgaWYgKCAhYm9vdF9lcnJvciApCiAgICAgewpkaWZmIC1yIDgwODc2
NzRjY2ViOSB4ZW4vYXJjaC94ODYvdGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvdGJvb3QuYwlU
aHUgSmFuIDA1IDIyOjQyOjAyIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3Rib290LmMJ
VHVlIEphbiAxMCAwOTowMToyNSAyMDEyICswODAwCkBAIC0xMjMsNiArMTIzLDggQEAKICAgICBw
cmludGsoIiAgc2h1dGRvd25fZW50cnk6IDB4JTA4eFxuIiwgdGJvb3Rfc2hhcmVkLT5zaHV0ZG93
bl9lbnRyeSk7CiAgICAgcHJpbnRrKCIgIHRib290X2Jhc2U6IDB4JTA4eFxuIiwgdGJvb3Rfc2hh
cmVkLT50Ym9vdF9iYXNlKTsKICAgICBwcmludGsoIiAgdGJvb3Rfc2l6ZTogMHgleFxuIiwgdGJv
b3Rfc2hhcmVkLT50Ym9vdF9zaXplKTsKKyAgICBpZiAoIHRib290X3NoYXJlZC0+dmVyc2lvbiA+
PSA2ICkKKyAgICAgICAgcHJpbnRrKCIgIGZsYWdzOiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+
ZmxhZ3MpOwogCiAgICAgLyogdGhlc2Ugd2lsbCBiZSBuZWVkZWQgYnkgdGJvb3RfcHJvdGVjdF9t
ZW1fcmVnaW9ucygpIGFuZC9vcgogICAgICAgIHRib290X3BhcnNlX2RtYXJfdGFibGUoKSwgc28g
Z2V0IHRoZW0gbm93ICovCkBAIC01MjksNiArNTMxLDE4IEBACiAgICAgcGFuaWMoIk1lbW9yeSBp
bnRlZ3JpdHkgd2FzIGxvc3Qgb24gcmVzdW1lICglZClcbiIsIGVycm9yKTsKIH0KIAoraW50IHRi
b290X3dha2VfYXAoaW50IGFwaWNpZCwgdW5zaWduZWQgbG9uZyBzaXBpX3ZlYykKK3sKKyAgICBp
ZiAoIGdfdGJvb3Rfc2hhcmVkLT52ZXJzaW9uID49IDYgJiYKKyAgICAgICAgIChnX3Rib290X3No
YXJlZC0+ZmxhZ3MgJiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCkgKQorICAgIHsKKyAgICAgICAg
Z190Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciA9IHNpcGlfdmVjOworICAgICAgICBnX3Rib290
X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyID0gYXBpY2lkOworICAgICAgICByZXR1cm4gMDsKKyAg
ICB9CisgICAgcmV0dXJuIDE7Cit9CisKIC8qCiAgKiBMb2NhbCB2YXJpYWJsZXM6CiAgKiBtb2Rl
OiBDCmRpZmYgLXIgODA4NzY3NGNjZWI5IHhlbi9pbmNsdWRlL2FzbS14ODYvdGJvb3QuaAotLS0g
YS94ZW4vaW5jbHVkZS9hc20teDg2L3Rib290LmgJVGh1IEphbiAwNSAyMjo0MjowMiAyMDEyICsw
ODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvdGJvb3QuaAlUdWUgSmFuIDEwIDA5OjAxOjI1
IDIwMTIgKzA4MDAKQEAgLTg1LDcgKzg1LDcgQEAKIHR5cGVkZWYgc3RydWN0IF9fcGFja2VkIHsK
ICAgICAvKiB2ZXJzaW9uIDMrIGZpZWxkczogKi8KICAgICB1dWlkX3QgICAgdXVpZDsgICAgICAg
ICAgICAgIC8qIHs2NjNDOERGRi1FOEIzLTRiODItQUFCRi0xOUVBNEQwNTdBMDh9ICovCi0gICAg
dWludDMyX3QgIHZlcnNpb247ICAgICAgICAgICAvKiBWZXJzaW9uIG51bWJlcjsgY3VycmVudGx5
IHN1cHBvcnRzIDAuNCAqLworICAgIHVpbnQzMl90ICB2ZXJzaW9uOyAgICAgICAgICAgLyogVmVy
c2lvbiBudW1iZXI7IGN1cnJlbnRseSBzdXBwb3J0cyAwLjYgKi8KICAgICB1aW50MzJfdCAgbG9n
X2FkZHI7ICAgICAgICAgIC8qIHBoeXNpY2FsIGFkZHIgb2YgdGJfbG9nX3QgbG9nICovCiAgICAg
dWludDMyX3QgIHNodXRkb3duX2VudHJ5OyAgICAvKiBlbnRyeSBwb2ludCBmb3IgdGJvb3Qgc2h1
dGRvd24gKi8KICAgICB1aW50MzJfdCAgc2h1dGRvd25fdHlwZTsgICAgIC8qIHR5cGUgb2Ygc2h1
dGRvd24gKFRCX1NIVVRET1dOXyopICovCkBAIC05OSw2ICs5OSwxMyBAQAogICAgIC8qIHZlcnNp
b24gNCsgZmllbGRzOiAqLwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogcG9w
dWxhdGVkIGJ5IHRib290OyB3aWxsIGJlIGVuY3J5cHRlZCAqLwogICAgIHVpbnQ4X3QgICBzM19r
ZXlbVEJfS0VZX1NJWkVdOworICAgIC8qIHZlcnNpb24gNSsgZmllbGRzOiAqLworICAgIHVpbnQ4
X3QgICByZXNlcnZlZF9hbGlnblszXTsgLyogdXNlZCB0byA0Ynl0ZS1hbGlnbiBudW1faW5fd2Zz
ICovCisgICAgdWludDMyX3QgIG51bV9pbl93ZnM7ICAgICAgICAvKiBudW1iZXIgb2YgcHJvY2Vz
c29ycyBpbiB3YWl0LWZvci1TSVBJICovCisgICAgLyogdmVyc2lvbiA2KyBmaWVsZHM6ICovCisg
ICAgdWludDMyX3QgIGZsYWdzOworICAgIHVpbnQ2NF90ICBhcF93YWtlX2FkZHI7ICAgICAgLyog
cGh5cyBhZGRyIG9mIGtlcm5lbC9WTU0gU0lQSSB2ZWN0b3IgKi8KKyAgICB1aW50MzJfdCAgYXBf
d2FrZV90cmlnZ2VyOyAgIC8qIGtlcm5lbC9WTU0gd3JpdGVzIEFQSUMgSUQgdG8gd2FrZSBBUCAq
LwogfSB0Ym9vdF9zaGFyZWRfdDsKIAogI2RlZmluZSBUQl9TSFVURE9XTl9SRUJPT1QgICAgICAw
CkBAIC0xMDcsNiArMTE0LDkgQEAKICNkZWZpbmUgVEJfU0hVVERPV05fUzMgICAgICAgICAgMwog
I2RlZmluZSBUQl9TSFVURE9XTl9IQUxUICAgICAgICA0CiAKKyNkZWZpbmUgVEJfRkxBR19BUF9X
QUtFX1NVUFBPUlQgICAweDAwMDAwMDAxICAvKiBrZXJuZWwvVk1NIHVzZSBJTklULVNJUEktU0lQ
SQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIGNs
ZWFyLCBhcF93YWtlXyogaWYgc2V0ICovCisKIC8qIHs2NjNDOERGRi1FOEIzLTRiODItQUFCRi0x
OUVBNEQwNTdBMDh9ICovCiAjZGVmaW5lIFRCT09UX1NIQVJFRF9VVUlEICAgIHsgMHg2NjNjOGRm
ZiwgMHhlOGIzLCAweDRiODIsIDB4YWFiZiwgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHsgMHgxOSwgMHhlYSwgMHg0ZCwgMHg1LCAweDdhLCAweDggfSB9OwpAQCAtMTIwLDYgKzEz
MCw3IEBACiBpbnQgdGJvb3RfcGFyc2VfZG1hcl90YWJsZShhY3BpX3RhYmxlX2hhbmRsZXIgZG1h
cl9oYW5kbGVyKTsKIGludCB0Ym9vdF9zM19yZXN1bWUodm9pZCk7CiB2b2lkIHRib290X3MzX2Vy
cm9yKGludCBlcnJvcik7CitpbnQgdGJvb3Rfd2FrZV9hcChpbnQgYXBpY2lkLCB1bnNpZ25lZCBs
b25nIHNpcGlfdmVjKTsKIAogI2VuZGlmIC8qIF9fVEJPT1RfSF9fICovCiAK

--_002_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Tue Jan 10 01:09:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 01:09:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkQCz-0005ym-CK; Tue, 10 Jan 2012 01:09:01 +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 1RkQCx-0005yh-PU
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 01:09:00 +0000
X-Env-Sender: gang.wei@intel.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326157732!10212574!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNjM5MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1574 invoked from network); 10 Jan 2012 01:08:53 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-4.tower-182.messagelabs.com with SMTP;
	10 Jan 2012 01:08:53 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga101.fm.intel.com with ESMTP; 09 Jan 2012 17:08:51 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110474269"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by fmsmga002.fm.intel.com with ESMTP; 09 Jan 2012 17:08:50 -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; Tue, 10 Jan 2012 09:07:43 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 10 Jan 2012 09:07:42 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.38]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 09:07:41 +0800
From: "Wei, Gang" <gang.wei@intel.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [PATCH v3] x86: add a new SMP bring up way for tboot case
Thread-Index: AczLudO1NAQHGJB/S0y4t9wglfAQ0P//f4kA//kkYOCADTRygP/+65eQ//3QaSA=
Date: Tue, 10 Jan 2012 01:07:41 +0000
Message-ID: <D0B11485C64D4B47B66902F8A4E901BE01797F@SHSMSX102.ccr.corp.intel.com>
References: <D0B11485C64D4B47B66902F8A4E901BEFE8C@SHSMSX101.ccr.corp.intel.com>
	<4F05CC48020000780006A9C7@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BE016BAB@SHSMSX102.ccr.corp.intel.com>
	<4F0B1F47020000780006B4D3@nat28.tlf.novell.com>
	<D0B11485C64D4B47B66902F8A4E901BE017924@SHSMSX102.ccr.corp.intel.com>
In-Reply-To: <D0B11485C64D4B47B66902F8A4E901BE017924@SHSMSX102.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_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_"
MIME-Version: 1.0
Cc: "Keir\(Xen.org\)" <keir@xen.org>, "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 v3] x86: add a new SMP bring up way for tboot
	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_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

tboot may be trying to put APs waiting in MWAIT loops before launching Xen.=
 Xen could check the new flag field in v6 tboot shared page for the hint. I=
f TB_FLAG_AP_WAKE_SUPPORT bit in flag field is set, Xen BSP have to write t=
he monitored memory(g_tboot_shared->ap_wake_trigger) to bring APs out of MW=
AIT loops. The sipi vector should be written in g_tboot_shared->ap_wake_add=
r before waking up APs.

Signed-off-by: Joseph Cihula <joseph.cihula@intel.com>
Signed-off-by: Shane Wang <shane.wang@intel.com>
Signed-off-by: Gang Wei <gang.wei@intel.com>

diff -r 8087674cceb9 xen/arch/x86/smpboot.c
--- a/xen/arch/x86/smpboot.c	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/arch/x86/smpboot.c	Tue Jan 10 09:01:25 2012 +0800
@@ -586,7 +586,13 @@
     smpboot_setup_warm_reset_vector(start_eip);
=20
     /* Starting actual IPI sequence... */
-    boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
+    if ( tboot_in_measured_env() )
+        boot_error =3D tboot_wake_ap(apicid, start_eip);
+    else
+        boot_error =3D 1;
+
+    if ( boot_error )
+        boot_error =3D wakeup_secondary_cpu(apicid, start_eip);
=20
     if ( !boot_error )
     {
diff -r 8087674cceb9 xen/arch/x86/tboot.c
--- a/xen/arch/x86/tboot.c	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/arch/x86/tboot.c	Tue Jan 10 09:01:25 2012 +0800
@@ -123,6 +123,8 @@
     printk("  shutdown_entry: 0x%08x\n", tboot_shared->shutdown_entry);
     printk("  tboot_base: 0x%08x\n", tboot_shared->tboot_base);
     printk("  tboot_size: 0x%x\n", tboot_shared->tboot_size);
+    if ( tboot_shared->version >=3D 6 )
+        printk("  flags: 0x%08x\n", tboot_shared->flags);
=20
     /* these will be needed by tboot_protect_mem_regions() and/or
        tboot_parse_dmar_table(), so get them now */
@@ -529,6 +531,18 @@
     panic("Memory integrity was lost on resume (%d)\n", error);
 }
=20
+int tboot_wake_ap(int apicid, unsigned long sipi_vec)
+{
+    if ( g_tboot_shared->version >=3D 6 &&
+         (g_tboot_shared->flags & TB_FLAG_AP_WAKE_SUPPORT) )
+    {
+        g_tboot_shared->ap_wake_addr =3D sipi_vec;
+        g_tboot_shared->ap_wake_trigger =3D apicid;
+        return 0;
+    }
+    return 1;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 8087674cceb9 xen/include/asm-x86/tboot.h
--- a/xen/include/asm-x86/tboot.h	Thu Jan 05 22:42:02 2012 +0800
+++ b/xen/include/asm-x86/tboot.h	Tue Jan 10 09:01:25 2012 +0800
@@ -85,7 +85,7 @@
 typedef struct __packed {
     /* version 3+ fields: */
     uuid_t    uuid;              /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08}=
 */
-    uint32_t  version;           /* Version number; currently supports 0.4=
 */
+    uint32_t  version;           /* Version number; currently supports 0.6=
 */
     uint32_t  log_addr;          /* physical addr of tb_log_t log */
     uint32_t  shutdown_entry;    /* entry point for tboot shutdown */
     uint32_t  shutdown_type;     /* type of shutdown (TB_SHUTDOWN_*) */
@@ -99,6 +99,13 @@
     /* version 4+ fields: */
                                  /* populated by tboot; will be encrypted =
*/
     uint8_t   s3_key[TB_KEY_SIZE];
+    /* version 5+ fields: */
+    uint8_t   reserved_align[3]; /* used to 4byte-align num_in_wfs */
+    uint32_t  num_in_wfs;        /* number of processors in wait-for-SIPI =
*/
+    /* version 6+ fields: */
+    uint32_t  flags;
+    uint64_t  ap_wake_addr;      /* phys addr of kernel/VMM SIPI vector */
+    uint32_t  ap_wake_trigger;   /* kernel/VMM writes APIC ID to wake AP *=
/
 } tboot_shared_t;
=20
 #define TB_SHUTDOWN_REBOOT      0
@@ -107,6 +114,9 @@
 #define TB_SHUTDOWN_S3          3
 #define TB_SHUTDOWN_HALT        4
=20
+#define TB_FLAG_AP_WAKE_SUPPORT   0x00000001  /* kernel/VMM use INIT-SIPI-=
SIPI
+                                                 if clear, ap_wake_* if se=
t */
+
 /* {663C8DFF-E8B3-4b82-AABF-19EA4D057A08} */
 #define TBOOT_SHARED_UUID    { 0x663c8dff, 0xe8b3, 0x4b82, 0xaabf, \
                                { 0x19, 0xea, 0x4d, 0x5, 0x7a, 0x8 } };
@@ -120,6 +130,7 @@
 int tboot_parse_dmar_table(acpi_table_handler dmar_handler);
 int tboot_s3_resume(void);
 void tboot_s3_error(int error);
+int tboot_wake_ap(int apicid, unsigned long sipi_vec);
=20
 #endif /* __TBOOT_H__ */


--_002_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_
Content-Type: application/octet-stream;
	name="mwait-smp-up-for-tboot-v3.patch"
Content-Description: mwait-smp-up-for-tboot-v3.patch
Content-Disposition: attachment; filename="mwait-smp-up-for-tboot-v3.patch";
	size=4206; creation-date="Tue, 10 Jan 2012 01:04:27 GMT";
	modification-date="Tue, 10 Jan 2012 01:02:09 GMT"
Content-Transfer-Encoding: base64

eDg2OiBhZGQgYSBuZXcgU01QIGJyaW5nIHVwIHdheSBmb3IgdGJvb3QgY2FzZQoKdGJvb3QgbWF5
IGJlIHRyeWluZyB0byBwdXQgQVBzIHdhaXRpbmcgaW4gTVdBSVQgbG9vcHMgYmVmb3JlIGxhdW5j
aGluZyBYZW4uIFhlbiBjb3VsZCBjaGVjayB0aGUgbmV3IGZsYWcgZmllbGQgaW4gdjYgdGJvb3Qg
c2hhcmVkIHBhZ2UgZm9yIHRoZSBoaW50LiBJZiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCBiaXQg
aW4gZmxhZyBmaWVsZCBpcyBzZXQsIFhlbiBCU1AgaGF2ZSB0byB3cml0ZSB0aGUgbW9uaXRvcmVk
IG1lbW9yeShnX3Rib290X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyKSB0byBicmluZyBBUHMgb3V0
IG9mIE1XQUlUIGxvb3BzLiBUaGUgc2lwaSB2ZWN0b3Igc2hvdWxkIGJlIHdyaXR0ZW4gaW4gZ190
Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciBiZWZvcmUgd2FraW5nIHVwIEFQcy4KClNpZ25lZC1v
ZmYtYnk6IEpvc2VwaCBDaWh1bGEgPGpvc2VwaC5jaWh1bGFAaW50ZWwuY29tPgpTaWduZWQtb2Zm
LWJ5OiBTaGFuZSBXYW5nIDxzaGFuZS53YW5nQGludGVsLmNvbT4KU2lnbmVkLW9mZi1ieTogR2Fu
ZyBXZWkgPGdhbmcud2VpQGludGVsLmNvbT4KCmRpZmYgLXIgODA4NzY3NGNjZWI5IHhlbi9hcmNo
L3g4Ni9zbXBib290LmMKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlUaHUgSmFuIDA1IDIy
OjQyOjAyIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwlUdWUgSmFuIDEw
IDA5OjAxOjI1IDIwMTIgKzA4MDAKQEAgLTU4Niw3ICs1ODYsMTMgQEAKICAgICBzbXBib290X3Nl
dHVwX3dhcm1fcmVzZXRfdmVjdG9yKHN0YXJ0X2VpcCk7CiAKICAgICAvKiBTdGFydGluZyBhY3R1
YWwgSVBJIHNlcXVlbmNlLi4uICovCi0gICAgYm9vdF9lcnJvciA9IHdha2V1cF9zZWNvbmRhcnlf
Y3B1KGFwaWNpZCwgc3RhcnRfZWlwKTsKKyAgICBpZiAoIHRib290X2luX21lYXN1cmVkX2Vudigp
ICkKKyAgICAgICAgYm9vdF9lcnJvciA9IHRib290X3dha2VfYXAoYXBpY2lkLCBzdGFydF9laXAp
OworICAgIGVsc2UKKyAgICAgICAgYm9vdF9lcnJvciA9IDE7CisKKyAgICBpZiAoIGJvb3RfZXJy
b3IgKQorICAgICAgICBib290X2Vycm9yID0gd2FrZXVwX3NlY29uZGFyeV9jcHUoYXBpY2lkLCBz
dGFydF9laXApOwogCiAgICAgaWYgKCAhYm9vdF9lcnJvciApCiAgICAgewpkaWZmIC1yIDgwODc2
NzRjY2ViOSB4ZW4vYXJjaC94ODYvdGJvb3QuYwotLS0gYS94ZW4vYXJjaC94ODYvdGJvb3QuYwlU
aHUgSmFuIDA1IDIyOjQyOjAyIDIwMTIgKzA4MDAKKysrIGIveGVuL2FyY2gveDg2L3Rib290LmMJ
VHVlIEphbiAxMCAwOTowMToyNSAyMDEyICswODAwCkBAIC0xMjMsNiArMTIzLDggQEAKICAgICBw
cmludGsoIiAgc2h1dGRvd25fZW50cnk6IDB4JTA4eFxuIiwgdGJvb3Rfc2hhcmVkLT5zaHV0ZG93
bl9lbnRyeSk7CiAgICAgcHJpbnRrKCIgIHRib290X2Jhc2U6IDB4JTA4eFxuIiwgdGJvb3Rfc2hh
cmVkLT50Ym9vdF9iYXNlKTsKICAgICBwcmludGsoIiAgdGJvb3Rfc2l6ZTogMHgleFxuIiwgdGJv
b3Rfc2hhcmVkLT50Ym9vdF9zaXplKTsKKyAgICBpZiAoIHRib290X3NoYXJlZC0+dmVyc2lvbiA+
PSA2ICkKKyAgICAgICAgcHJpbnRrKCIgIGZsYWdzOiAweCUwOHhcbiIsIHRib290X3NoYXJlZC0+
ZmxhZ3MpOwogCiAgICAgLyogdGhlc2Ugd2lsbCBiZSBuZWVkZWQgYnkgdGJvb3RfcHJvdGVjdF9t
ZW1fcmVnaW9ucygpIGFuZC9vcgogICAgICAgIHRib290X3BhcnNlX2RtYXJfdGFibGUoKSwgc28g
Z2V0IHRoZW0gbm93ICovCkBAIC01MjksNiArNTMxLDE4IEBACiAgICAgcGFuaWMoIk1lbW9yeSBp
bnRlZ3JpdHkgd2FzIGxvc3Qgb24gcmVzdW1lICglZClcbiIsIGVycm9yKTsKIH0KIAoraW50IHRi
b290X3dha2VfYXAoaW50IGFwaWNpZCwgdW5zaWduZWQgbG9uZyBzaXBpX3ZlYykKK3sKKyAgICBp
ZiAoIGdfdGJvb3Rfc2hhcmVkLT52ZXJzaW9uID49IDYgJiYKKyAgICAgICAgIChnX3Rib290X3No
YXJlZC0+ZmxhZ3MgJiBUQl9GTEFHX0FQX1dBS0VfU1VQUE9SVCkgKQorICAgIHsKKyAgICAgICAg
Z190Ym9vdF9zaGFyZWQtPmFwX3dha2VfYWRkciA9IHNpcGlfdmVjOworICAgICAgICBnX3Rib290
X3NoYXJlZC0+YXBfd2FrZV90cmlnZ2VyID0gYXBpY2lkOworICAgICAgICByZXR1cm4gMDsKKyAg
ICB9CisgICAgcmV0dXJuIDE7Cit9CisKIC8qCiAgKiBMb2NhbCB2YXJpYWJsZXM6CiAgKiBtb2Rl
OiBDCmRpZmYgLXIgODA4NzY3NGNjZWI5IHhlbi9pbmNsdWRlL2FzbS14ODYvdGJvb3QuaAotLS0g
YS94ZW4vaW5jbHVkZS9hc20teDg2L3Rib290LmgJVGh1IEphbiAwNSAyMjo0MjowMiAyMDEyICsw
ODAwCisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvdGJvb3QuaAlUdWUgSmFuIDEwIDA5OjAxOjI1
IDIwMTIgKzA4MDAKQEAgLTg1LDcgKzg1LDcgQEAKIHR5cGVkZWYgc3RydWN0IF9fcGFja2VkIHsK
ICAgICAvKiB2ZXJzaW9uIDMrIGZpZWxkczogKi8KICAgICB1dWlkX3QgICAgdXVpZDsgICAgICAg
ICAgICAgIC8qIHs2NjNDOERGRi1FOEIzLTRiODItQUFCRi0xOUVBNEQwNTdBMDh9ICovCi0gICAg
dWludDMyX3QgIHZlcnNpb247ICAgICAgICAgICAvKiBWZXJzaW9uIG51bWJlcjsgY3VycmVudGx5
IHN1cHBvcnRzIDAuNCAqLworICAgIHVpbnQzMl90ICB2ZXJzaW9uOyAgICAgICAgICAgLyogVmVy
c2lvbiBudW1iZXI7IGN1cnJlbnRseSBzdXBwb3J0cyAwLjYgKi8KICAgICB1aW50MzJfdCAgbG9n
X2FkZHI7ICAgICAgICAgIC8qIHBoeXNpY2FsIGFkZHIgb2YgdGJfbG9nX3QgbG9nICovCiAgICAg
dWludDMyX3QgIHNodXRkb3duX2VudHJ5OyAgICAvKiBlbnRyeSBwb2ludCBmb3IgdGJvb3Qgc2h1
dGRvd24gKi8KICAgICB1aW50MzJfdCAgc2h1dGRvd25fdHlwZTsgICAgIC8qIHR5cGUgb2Ygc2h1
dGRvd24gKFRCX1NIVVRET1dOXyopICovCkBAIC05OSw2ICs5OSwxMyBAQAogICAgIC8qIHZlcnNp
b24gNCsgZmllbGRzOiAqLwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogcG9w
dWxhdGVkIGJ5IHRib290OyB3aWxsIGJlIGVuY3J5cHRlZCAqLwogICAgIHVpbnQ4X3QgICBzM19r
ZXlbVEJfS0VZX1NJWkVdOworICAgIC8qIHZlcnNpb24gNSsgZmllbGRzOiAqLworICAgIHVpbnQ4
X3QgICByZXNlcnZlZF9hbGlnblszXTsgLyogdXNlZCB0byA0Ynl0ZS1hbGlnbiBudW1faW5fd2Zz
ICovCisgICAgdWludDMyX3QgIG51bV9pbl93ZnM7ICAgICAgICAvKiBudW1iZXIgb2YgcHJvY2Vz
c29ycyBpbiB3YWl0LWZvci1TSVBJICovCisgICAgLyogdmVyc2lvbiA2KyBmaWVsZHM6ICovCisg
ICAgdWludDMyX3QgIGZsYWdzOworICAgIHVpbnQ2NF90ICBhcF93YWtlX2FkZHI7ICAgICAgLyog
cGh5cyBhZGRyIG9mIGtlcm5lbC9WTU0gU0lQSSB2ZWN0b3IgKi8KKyAgICB1aW50MzJfdCAgYXBf
d2FrZV90cmlnZ2VyOyAgIC8qIGtlcm5lbC9WTU0gd3JpdGVzIEFQSUMgSUQgdG8gd2FrZSBBUCAq
LwogfSB0Ym9vdF9zaGFyZWRfdDsKIAogI2RlZmluZSBUQl9TSFVURE9XTl9SRUJPT1QgICAgICAw
CkBAIC0xMDcsNiArMTE0LDkgQEAKICNkZWZpbmUgVEJfU0hVVERPV05fUzMgICAgICAgICAgMwog
I2RlZmluZSBUQl9TSFVURE9XTl9IQUxUICAgICAgICA0CiAKKyNkZWZpbmUgVEJfRkxBR19BUF9X
QUtFX1NVUFBPUlQgICAweDAwMDAwMDAxICAvKiBrZXJuZWwvVk1NIHVzZSBJTklULVNJUEktU0lQ
SQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIGNs
ZWFyLCBhcF93YWtlXyogaWYgc2V0ICovCisKIC8qIHs2NjNDOERGRi1FOEIzLTRiODItQUFCRi0x
OUVBNEQwNTdBMDh9ICovCiAjZGVmaW5lIFRCT09UX1NIQVJFRF9VVUlEICAgIHsgMHg2NjNjOGRm
ZiwgMHhlOGIzLCAweDRiODIsIDB4YWFiZiwgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHsgMHgxOSwgMHhlYSwgMHg0ZCwgMHg1LCAweDdhLCAweDggfSB9OwpAQCAtMTIwLDYgKzEz
MCw3IEBACiBpbnQgdGJvb3RfcGFyc2VfZG1hcl90YWJsZShhY3BpX3RhYmxlX2hhbmRsZXIgZG1h
cl9oYW5kbGVyKTsKIGludCB0Ym9vdF9zM19yZXN1bWUodm9pZCk7CiB2b2lkIHRib290X3MzX2Vy
cm9yKGludCBlcnJvcik7CitpbnQgdGJvb3Rfd2FrZV9hcChpbnQgYXBpY2lkLCB1bnNpZ25lZCBs
b25nIHNpcGlfdmVjKTsKIAogI2VuZGlmIC8qIF9fVEJPT1RfSF9fICovCiAK

--_002_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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_D0B11485C64D4B47B66902F8A4E901BE01797FSHSMSX102ccrcorpi_--


From xen-devel-bounces@lists.xensource.com Tue Jan 10 03:34:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 03: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 1RkSSx-0007DK-Tx; Tue, 10 Jan 2012 03:33: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 1RkSSw-0007DF-Gh
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 03:33:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326166410!8455907!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NTUy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8941 invoked from network); 10 Jan 2012 03:33:31 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.5) by server-11.tower-174.messagelabs.com with SMTP;
	10 Jan 2012 03:33:31 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 5325F4B0084;
	Mon,  9 Jan 2012 19:33:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=vd1huQ2fmSshTwyx5b3g4Oe1tgAL+et88n/XrCj6X4i1
	YH7Lpg0qc4zgNhnCTV7qHu5VLymUA0EsM5aB5Qq5zpbIkeRyUa1kk8vSgbN/sziN
	+z9GtkBvpSZD6b/BD0a5B0dk3ldAsxXcyRL9mihFWZ7ej8ZiZ8kiE4h8g6WGaRk=
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=jKwqFutwIifOxxrUAA2TLa6I1jI=; b=f55lYxbA
	MTwOFqaJRuar/sdzrCVqN3qBKgbg7kWxvWUbHNHbMYKxX3ZxQZN7NZGsEXyIB0gw
	sUOpopEyv8XH9R6NVb+7hKBF9uIOLZMTA6IVGjFeAS6a9bJ/5fxy0IUS9AVINCrr
	6Md+UIxq8vxw3+Ib1Uh+R1esyNJD1ryzRR0=
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 ECDE54B007C; 
	Mon,  9 Jan 2012 19:33:28 -0800 (PST)
Received: from 76.10.135.186 (proxying for 76.10.135.186)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 9 Jan 2012 19:33:29 -0800
Message-ID: <6bc50bae068be30df565edd118ee3c78.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <002b01cccd17$ca4652d0$5ed2f870$@com>
References: <mailman.5929.1325754331.12970.xen-devel@lists.xensource.com>
	<a344dc410cb70b471e31c922ce80d94a.squirrel@webmail.lagarcavilla.org>
	<002b01cccd17$ca4652d0$5ed2f870$@com>
Date: Mon, 9 Jan 2012 19:33:29 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Hongkaixing" <hongkaixing@huawei.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, xen-devel@lists.xensource.com,
	hanweidong@huawei.com, yanqiangjun@huawei.com, tim@xen.org,
	bicky.shi@huawei.com, andres@lagarcavilla.org
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in process
 to	speed up page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>
>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Saturday, January 07, 2012 11:52 AM
>> To: xen-devel@lists.xensource.com
>> Cc: tim@xen.org; olaf@aepfle.de; hongkaixing@huawei.com
>> Subject: Re: [PATCH 2 of 2] xenpaging:change page-in process to speed up
>> page-in in xenpaging
>>
>> > Date: Thu, 5 Jan 2012 09:05:16 +0000
>> > From: Tim Deegan <tim@xen.org>
>> > To: hongkaixing@huawei.com
>> > Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
>> > Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in
>> > 	process to	speed up page-in in	xenpaging
>> > Message-ID: <20120105090516.GE15595@ocelot.phlegethon.org>
>> > Content-Type: text/plain; charset=iso-8859-1
>> >
>> > Hello,
>> >
>> > At 03:50 +0000 on 05 Jan (1325735430), hongkaixing@huawei.com wrote:
>> >> xenpaging:change page-in process to speed up page-in in xenpaging
>> >> In this patch,we change the page-in process.Firstly,we add a new
>> >> function paging_in_trigger_sync
>> >> to handle page-in requests directly.and when the requests' count is
>> up
>> >> to 32,then handle them
>> >> batchly;Most importantly,we use an increasing gfn to test_bit,which
>> >> saves much time.
>> >> In p2m.c,we changes p2m_mem_paging_populate() to return a value;
>> >> The following is a xenpaging test on suse11-64 with 4G memory.
>> >>
>> >> Nums of page_out pages	Page out time	Page in time(in unstable code)
>> Page
>> >> in time(apply this patch)
>> >> 512M(131072)		    2.6s		        540s		              4.7s
>> >> 2G(524288)		    15.5s		        2088s		      	      17.7s
>> >>
>> >
>> > Thanks for the patch!  That's an impressive difference.  You're
>> changing
>> > quite a few things in this patch, though.  Can you send them as
>> separate
>> > patches so they can be reviewed one at a time?  Is one of them in
>> > particular making the difference?  I suspect it's mostly the change to
>> > test_bit(), and the rest is not necessary.
>>
>> Second that, on all counts. Impressive numbers, and, a bit puzzled as to
>> what actually made the difference.
>
> Take paging 512M as a example, before using this patch, it spends 540s in
> page-in process, after using this patch, only 4.7 s
>
>>
>> I would also like to see changes to xenpaging teased out from changes to
>> the hypervisor.
>>
>> I've been sitting on a patch to page-in synchronously, which shortcuts
>> even more aggressively the page-in path: instead of calling populate, we
>> go straight into paging_load. This does not necessitate an additional
>> domctl, and would save even more hypervisor<->pager control round-trips.
>
> Would you mind showing your details?
I just sent the patch, look for "[PATCH 1 of 2] x86/mm: Allow a page in
p2m_ram_paged_out state to be loaded"

This should allow xenpaging to populate pages directly in its page-in
thread, without needing a populate domctl (or a mmap).

Andres
> I see, I have try this so. My method is :
> When test the page is paged out, then populate directly without using
> event ring.
> Problem is : There may be some concurrency problems, and some strange blue
> screens.
>
>
>> Do you foresee any conflicts with your current approach?
>
> Our approach is stable till now.
>>
>> Thanks!
>> Andres
>>
>> >
>> > Cheers,
>> >
>> > Tim.
>> >
>> >> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
>> >>
>> >> diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
>> >> --- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -73,6 +73,13 @@
>> >>                                  NULL, NULL, gfn);
>> >>  }
>> >>
>> >> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned
>> >> long gfn)
>> >> +{
>> >> +    return xc_mem_event_control(xch, domain_id,
>> >> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
>> >> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>> >> +                                NULL, NULL, gfn);
>> >> +}
>> >>
>> >>  /*
>> >>   * Local variables:
>> >> diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
>> >> --- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -1841,6 +1841,7 @@
>> >>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id,
>> unsigned
>> >> long gfn);
>> >>  int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
>> >>                           unsigned long gfn);
>> >> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned
>> long
>> >> gfn);
>> >>
>> >>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>> >>                          void *shared_page, void *ring_page);
>> >> diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
>> >> --- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -594,6 +594,13 @@
>> >>      return ret;
>> >>  }
>> >>
>> >> +static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long
>> >> gfn)
>> >> +{
>> >> +    int rc = 0;
>> >> +    rc = xc_mem_paging_in(paging->xc_handle,
>> >> paging->mem_event.domain_id,gfn);
>> >> +    return rc;
>> >> +}
>> >
>> > This function is
>> >
>> >> +
>> >>  int main(int argc, char *argv[])
>> >>  {
>> >>      struct sigaction act;
>> >> @@ -605,6 +612,9 @@
>> >>      int i;
>> >>      int rc = -1;
>> >>      int rc1;
>> >> +    int request_count = 0;
>> >> +    unsigned long page_in_start_gfn = 0;
>> >> +    unsigned long real_page = 0;
>> >>      xc_interface *xch;
>> >>
>> >>      int open_flags = O_CREAT | O_TRUNC | O_RDWR;
>> >> @@ -773,24 +783,51 @@
>> >>          /* Write all pages back into the guest */
>> >>          if ( interrupted == SIGTERM || interrupted == SIGINT )
>> >>          {
>> >> -            int num = 0;
>> >> +            request_count = 0;
>> >>              for ( i = 0; i < paging->domain_info->max_pages; i++ )
>> >>              {
>> >> -                if ( test_bit(i, paging->bitmap) )
>> >> +                real_page = i + page_in_start_gfn;
>> >> +                real_page %= paging->domain_info->max_pages;
>> >> +                if ( test_bit(real_page, paging->bitmap) )
>> >>                  {
>> >> -                    paging->pagein_queue[num] = i;
>> >> -                    num++;
>> >> -                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
>> >> -                        break;
>> >> +                    rc = paging_in_trigger_sync(paging,real_page);
>> >> +                    if ( 0 == rc )
>> >> +                    {
>> >> +                        request_count++;
>> >> +                        /* If page_in requests up to 32 then handle
>> >> them */
>> >> +                        if( request_count >= 32 )
>> >> +                        {
>> >> +                            page_in_start_gfn=real_page + 1;
>> >> +                            break;
>> >> +                        }
>> >> +                    }
>> >> +                    else
>> >> +                    {
>> >> +                        /* If IO ring is full then handle requests
>> to
>> >> free space */
>> >> +                        if( ENOSPC == errno )
>> >> +                        {
>> >> +                            page_in_start_gfn = real_page;
>> >> +                            break;
>> >> +                        }
>> >> +                        /* If p2mt is not p2m_is_paging,then clear
>> >> bitmap;
>> >> +                        * e.g. a page is paged then it is dropped by
>> >> balloon.
>> >> +                        */
>> >> +                        else if ( EINVAL == errno )
>> >> +                        {
>> >> +                            clear_bit(i,paging->bitmap);
>> >> +                            policy_notify_paged_in(i);
>> >> +                        }
>> >> +                        /* If hypercall fails then go to teardown
>> >> xenpaging */
>> >> +                        else
>> >> +                        {
>> >> +                            ERROR("Error paging in page");
>> >> +                            goto out;
>> >> +                        }
>> >> +                    }
>> >>                  }
>> >>              }
>> >> -            /*
>> >> -             * One more round if there are still pages to process.
>> >> -             * If no more pages to process, exit loop.
>> >> -             */
>> >> -            if ( num )
>> >> -                page_in_trigger();
>> >> -            else if ( i == paging->domain_info->max_pages )
>> >> +            if( (i==paging->domain_info->max_pages) &&
>> >> +
>> >> !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
>> >>                  break;
>> >>          }
>> >>          else
>> >> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
>> >> --- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -57,7 +57,14 @@
>> >>          return 0;
>> >>      }
>> >>      break;
>> >> -
>> >> +
>> >> +    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
>> >> +    {
>> >> +        unsigned long gfn = mec->gfn;
>> >> +        return p2m_mem_paging_populate(d, gfn);
>> >> +    }
>> >> +    break;
>> >> +
>> >>      default:
>> >>          return -ENOSYS;
>> >>          break;
>> >> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
>> >> --- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -874,7 +874,7 @@
>> >>   * already sent to the pager. In this case the caller has to try
>> again
>> >> until the
>> >>   * gfn is fully paged in again.
>> >>   */
>> >> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> >> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> >>  {
>> >>      struct vcpu *v = current;
>> >>      mem_event_request_t req;
>> >> @@ -882,10 +882,12 @@
>> >>      p2m_access_t a;
>> >>      mfn_t mfn;
>> >>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> >> +    int ret;
>> >>
>> >>      /* Check that there's space on the ring for this request */
>> >> +    ret = -ENOSPC;
>> >>      if ( mem_event_check_ring(d, &d->mem_paging) )
>> >> -        return;
>> >> +        goto out;
>> >>
>> >>      memset(&req, 0, sizeof(req));
>> >>      req.type = MEM_EVENT_TYPE_PAGING;
>> >> @@ -905,19 +907,27 @@
>> >>      }
>> >>      p2m_unlock(p2m);
>> >>
>> >> +    ret = -EINVAL;
>> >>      /* Pause domain if request came from guest and gfn has paging
>> type
>> >> */
>> >> -    if (  p2m_is_paging(p2mt) && v->domain->domain_id ==
>> d->domain_id )
>> >> +    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id
>> )
>> >>      {
>> >>          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 )
>> >> +    else if ( p2mt == p2m_ram_paging_in_start || p2mt ==
>> >> p2m_ram_paging_in )
>> >>      {
>> >>          /* gfn is already on its way back and vcpu is not paused */
>> >>          mem_event_put_req_producers(&d->mem_paging);
>> >> -        return;
>> >> +        return 0;
>> >>      }
>> >> +    else if ( !p2m_is_paging(p2mt) )
>> >> +    {
>> >> +        /* please clear the bit in paging->bitmap; */
>> >> +        mem_event_put_req_producers(&d->mem_paging);
>> >> +        goto out;
>> >> +    }
>> >> +
>> >>
>> >>      /* Send request to pager */
>> >>      req.gfn = gfn;
>> >> @@ -925,8 +935,13 @@
>> >>      req.vcpu_id = v->vcpu_id;
>> >>
>> >>      mem_event_put_request(d, &d->mem_paging, &req);
>> >> +
>> >> +    ret = 0;
>> >> + out:
>> >> +    return ret;
>> >>  }
>> >>
>> >> +
>> >>  /**
>> >>   * p2m_mem_paging_prep - Allocate a new page for the guest
>> >>   * @d: guest domain
>> >> diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
>> >> --- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -485,7 +485,7 @@
>> >>  /* Tell xenpaging to drop a paged out frame */
>> >>  void 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);
>> >> +int 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);
>> >>  /* Resume normal operation (in case a domain was paused) */
>> >> diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
>> >> --- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -721,6 +721,7 @@
>> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
>> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
>> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
>> >> +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
>> >>
>> >>  /*
>> >>   * Access permissions.
>> >>
>> >
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/xen-devel
>> >
>> >
>> >
>> >
>> > ------------------------------
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
>> >
>> >
>> > End of Xen-devel Digest, Vol 83, Issue 39
>> > *****************************************
>> >
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 03:34:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 03: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 1RkSSx-0007DK-Tx; Tue, 10 Jan 2012 03:33: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 1RkSSw-0007DF-Gh
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 03:33:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326166410!8455907!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE2NTUy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8941 invoked from network); 10 Jan 2012 03:33:31 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.5) by server-11.tower-174.messagelabs.com with SMTP;
	10 Jan 2012 03:33:31 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 5325F4B0084;
	Mon,  9 Jan 2012 19:33:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=vd1huQ2fmSshTwyx5b3g4Oe1tgAL+et88n/XrCj6X4i1
	YH7Lpg0qc4zgNhnCTV7qHu5VLymUA0EsM5aB5Qq5zpbIkeRyUa1kk8vSgbN/sziN
	+z9GtkBvpSZD6b/BD0a5B0dk3ldAsxXcyRL9mihFWZ7ej8ZiZ8kiE4h8g6WGaRk=
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=jKwqFutwIifOxxrUAA2TLa6I1jI=; b=f55lYxbA
	MTwOFqaJRuar/sdzrCVqN3qBKgbg7kWxvWUbHNHbMYKxX3ZxQZN7NZGsEXyIB0gw
	sUOpopEyv8XH9R6NVb+7hKBF9uIOLZMTA6IVGjFeAS6a9bJ/5fxy0IUS9AVINCrr
	6Md+UIxq8vxw3+Ib1Uh+R1esyNJD1ryzRR0=
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 ECDE54B007C; 
	Mon,  9 Jan 2012 19:33:28 -0800 (PST)
Received: from 76.10.135.186 (proxying for 76.10.135.186)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP; Mon, 9 Jan 2012 19:33:29 -0800
Message-ID: <6bc50bae068be30df565edd118ee3c78.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <002b01cccd17$ca4652d0$5ed2f870$@com>
References: <mailman.5929.1325754331.12970.xen-devel@lists.xensource.com>
	<a344dc410cb70b471e31c922ce80d94a.squirrel@webmail.lagarcavilla.org>
	<002b01cccd17$ca4652d0$5ed2f870$@com>
Date: Mon, 9 Jan 2012 19:33:29 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Hongkaixing" <hongkaixing@huawei.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, xen-devel@lists.xensource.com,
	hanweidong@huawei.com, yanqiangjun@huawei.com, tim@xen.org,
	bicky.shi@huawei.com, andres@lagarcavilla.org
Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in process
 to	speed up page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>
>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
>> Sent: Saturday, January 07, 2012 11:52 AM
>> To: xen-devel@lists.xensource.com
>> Cc: tim@xen.org; olaf@aepfle.de; hongkaixing@huawei.com
>> Subject: Re: [PATCH 2 of 2] xenpaging:change page-in process to speed up
>> page-in in xenpaging
>>
>> > Date: Thu, 5 Jan 2012 09:05:16 +0000
>> > From: Tim Deegan <tim@xen.org>
>> > To: hongkaixing@huawei.com
>> > Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com
>> > Subject: Re: [Xen-devel] [PATCH 2 of 2] xenpaging:change page-in
>> > 	process to	speed up page-in in	xenpaging
>> > Message-ID: <20120105090516.GE15595@ocelot.phlegethon.org>
>> > Content-Type: text/plain; charset=iso-8859-1
>> >
>> > Hello,
>> >
>> > At 03:50 +0000 on 05 Jan (1325735430), hongkaixing@huawei.com wrote:
>> >> xenpaging:change page-in process to speed up page-in in xenpaging
>> >> In this patch,we change the page-in process.Firstly,we add a new
>> >> function paging_in_trigger_sync
>> >> to handle page-in requests directly.and when the requests' count is
>> up
>> >> to 32,then handle them
>> >> batchly;Most importantly,we use an increasing gfn to test_bit,which
>> >> saves much time.
>> >> In p2m.c,we changes p2m_mem_paging_populate() to return a value;
>> >> The following is a xenpaging test on suse11-64 with 4G memory.
>> >>
>> >> Nums of page_out pages	Page out time	Page in time(in unstable code)
>> Page
>> >> in time(apply this patch)
>> >> 512M(131072)		    2.6s		        540s		              4.7s
>> >> 2G(524288)		    15.5s		        2088s		      	      17.7s
>> >>
>> >
>> > Thanks for the patch!  That's an impressive difference.  You're
>> changing
>> > quite a few things in this patch, though.  Can you send them as
>> separate
>> > patches so they can be reviewed one at a time?  Is one of them in
>> > particular making the difference?  I suspect it's mostly the change to
>> > test_bit(), and the rest is not necessary.
>>
>> Second that, on all counts. Impressive numbers, and, a bit puzzled as to
>> what actually made the difference.
>
> Take paging 512M as a example, before using this patch, it spends 540s in
> page-in process, after using this patch, only 4.7 s
>
>>
>> I would also like to see changes to xenpaging teased out from changes to
>> the hypervisor.
>>
>> I've been sitting on a patch to page-in synchronously, which shortcuts
>> even more aggressively the page-in path: instead of calling populate, we
>> go straight into paging_load. This does not necessitate an additional
>> domctl, and would save even more hypervisor<->pager control round-trips.
>
> Would you mind showing your details?
I just sent the patch, look for "[PATCH 1 of 2] x86/mm: Allow a page in
p2m_ram_paged_out state to be loaded"

This should allow xenpaging to populate pages directly in its page-in
thread, without needing a populate domctl (or a mmap).

Andres
> I see, I have try this so. My method is :
> When test the page is paged out, then populate directly without using
> event ring.
> Problem is : There may be some concurrency problems, and some strange blue
> screens.
>
>
>> Do you foresee any conflicts with your current approach?
>
> Our approach is stable till now.
>>
>> Thanks!
>> Andres
>>
>> >
>> > Cheers,
>> >
>> > Tim.
>> >
>> >> Signed-off-by??hongkaixing<hongkaixing@huawei.com>,shizhen<bicky.shi@huawei.com>
>> >>
>> >> diff -r 052727b8165c -r 978daceef147 tools/libxc/xc_mem_paging.c
>> >> --- a/tools/libxc/xc_mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/tools/libxc/xc_mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -73,6 +73,13 @@
>> >>                                  NULL, NULL, gfn);
>> >>  }
>> >>
>> >> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id, unsigned
>> >> long gfn)
>> >> +{
>> >> +    return xc_mem_event_control(xch, domain_id,
>> >> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN,
>> >> +                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>> >> +                                NULL, NULL, gfn);
>> >> +}
>> >>
>> >>  /*
>> >>   * Local variables:
>> >> diff -r 052727b8165c -r 978daceef147 tools/libxc/xenctrl.h
>> >> --- a/tools/libxc/xenctrl.h	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/tools/libxc/xenctrl.h	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -1841,6 +1841,7 @@
>> >>  int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id,
>> unsigned
>> >> long gfn);
>> >>  int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id,
>> >>                           unsigned long gfn);
>> >> +int xc_mem_paging_in(xc_interface *xch, domid_t domain_id,unsigned
>> long
>> >> gfn);
>> >>
>> >>  int xc_mem_access_enable(xc_interface *xch, domid_t domain_id,
>> >>                          void *shared_page, void *ring_page);
>> >> diff -r 052727b8165c -r 978daceef147 tools/xenpaging/xenpaging.c
>> >> --- a/tools/xenpaging/xenpaging.c	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/tools/xenpaging/xenpaging.c	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -594,6 +594,13 @@
>> >>      return ret;
>> >>  }
>> >>
>> >> +static int paging_in_trigger_sync(xenpaging_t *paging,unsigned long
>> >> gfn)
>> >> +{
>> >> +    int rc = 0;
>> >> +    rc = xc_mem_paging_in(paging->xc_handle,
>> >> paging->mem_event.domain_id,gfn);
>> >> +    return rc;
>> >> +}
>> >
>> > This function is
>> >
>> >> +
>> >>  int main(int argc, char *argv[])
>> >>  {
>> >>      struct sigaction act;
>> >> @@ -605,6 +612,9 @@
>> >>      int i;
>> >>      int rc = -1;
>> >>      int rc1;
>> >> +    int request_count = 0;
>> >> +    unsigned long page_in_start_gfn = 0;
>> >> +    unsigned long real_page = 0;
>> >>      xc_interface *xch;
>> >>
>> >>      int open_flags = O_CREAT | O_TRUNC | O_RDWR;
>> >> @@ -773,24 +783,51 @@
>> >>          /* Write all pages back into the guest */
>> >>          if ( interrupted == SIGTERM || interrupted == SIGINT )
>> >>          {
>> >> -            int num = 0;
>> >> +            request_count = 0;
>> >>              for ( i = 0; i < paging->domain_info->max_pages; i++ )
>> >>              {
>> >> -                if ( test_bit(i, paging->bitmap) )
>> >> +                real_page = i + page_in_start_gfn;
>> >> +                real_page %= paging->domain_info->max_pages;
>> >> +                if ( test_bit(real_page, paging->bitmap) )
>> >>                  {
>> >> -                    paging->pagein_queue[num] = i;
>> >> -                    num++;
>> >> -                    if ( num == XENPAGING_PAGEIN_QUEUE_SIZE )
>> >> -                        break;
>> >> +                    rc = paging_in_trigger_sync(paging,real_page);
>> >> +                    if ( 0 == rc )
>> >> +                    {
>> >> +                        request_count++;
>> >> +                        /* If page_in requests up to 32 then handle
>> >> them */
>> >> +                        if( request_count >= 32 )
>> >> +                        {
>> >> +                            page_in_start_gfn=real_page + 1;
>> >> +                            break;
>> >> +                        }
>> >> +                    }
>> >> +                    else
>> >> +                    {
>> >> +                        /* If IO ring is full then handle requests
>> to
>> >> free space */
>> >> +                        if( ENOSPC == errno )
>> >> +                        {
>> >> +                            page_in_start_gfn = real_page;
>> >> +                            break;
>> >> +                        }
>> >> +                        /* If p2mt is not p2m_is_paging,then clear
>> >> bitmap;
>> >> +                        * e.g. a page is paged then it is dropped by
>> >> balloon.
>> >> +                        */
>> >> +                        else if ( EINVAL == errno )
>> >> +                        {
>> >> +                            clear_bit(i,paging->bitmap);
>> >> +                            policy_notify_paged_in(i);
>> >> +                        }
>> >> +                        /* If hypercall fails then go to teardown
>> >> xenpaging */
>> >> +                        else
>> >> +                        {
>> >> +                            ERROR("Error paging in page");
>> >> +                            goto out;
>> >> +                        }
>> >> +                    }
>> >>                  }
>> >>              }
>> >> -            /*
>> >> -             * One more round if there are still pages to process.
>> >> -             * If no more pages to process, exit loop.
>> >> -             */
>> >> -            if ( num )
>> >> -                page_in_trigger();
>> >> -            else if ( i == paging->domain_info->max_pages )
>> >> +            if( (i==paging->domain_info->max_pages) &&
>> >> +
>> >> !RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
>> >>                  break;
>> >>          }
>> >>          else
>> >> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/mem_paging.c
>> >> --- a/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/xen/arch/x86/mm/mem_paging.c	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -57,7 +57,14 @@
>> >>          return 0;
>> >>      }
>> >>      break;
>> >> -
>> >> +
>> >> +    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN:
>> >> +    {
>> >> +        unsigned long gfn = mec->gfn;
>> >> +        return p2m_mem_paging_populate(d, gfn);
>> >> +    }
>> >> +    break;
>> >> +
>> >>      default:
>> >>          return -ENOSYS;
>> >>          break;
>> >> diff -r 052727b8165c -r 978daceef147 xen/arch/x86/mm/p2m.c
>> >> --- a/xen/arch/x86/mm/p2m.c	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/xen/arch/x86/mm/p2m.c	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -874,7 +874,7 @@
>> >>   * already sent to the pager. In this case the caller has to try
>> again
>> >> until the
>> >>   * gfn is fully paged in again.
>> >>   */
>> >> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> >> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> >>  {
>> >>      struct vcpu *v = current;
>> >>      mem_event_request_t req;
>> >> @@ -882,10 +882,12 @@
>> >>      p2m_access_t a;
>> >>      mfn_t mfn;
>> >>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> >> +    int ret;
>> >>
>> >>      /* Check that there's space on the ring for this request */
>> >> +    ret = -ENOSPC;
>> >>      if ( mem_event_check_ring(d, &d->mem_paging) )
>> >> -        return;
>> >> +        goto out;
>> >>
>> >>      memset(&req, 0, sizeof(req));
>> >>      req.type = MEM_EVENT_TYPE_PAGING;
>> >> @@ -905,19 +907,27 @@
>> >>      }
>> >>      p2m_unlock(p2m);
>> >>
>> >> +    ret = -EINVAL;
>> >>      /* Pause domain if request came from guest and gfn has paging
>> type
>> >> */
>> >> -    if (  p2m_is_paging(p2mt) && v->domain->domain_id ==
>> d->domain_id )
>> >> +    if ( p2m_is_paging(p2mt) && v->domain->domain_id == d->domain_id
>> )
>> >>      {
>> >>          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 )
>> >> +    else if ( p2mt == p2m_ram_paging_in_start || p2mt ==
>> >> p2m_ram_paging_in )
>> >>      {
>> >>          /* gfn is already on its way back and vcpu is not paused */
>> >>          mem_event_put_req_producers(&d->mem_paging);
>> >> -        return;
>> >> +        return 0;
>> >>      }
>> >> +    else if ( !p2m_is_paging(p2mt) )
>> >> +    {
>> >> +        /* please clear the bit in paging->bitmap; */
>> >> +        mem_event_put_req_producers(&d->mem_paging);
>> >> +        goto out;
>> >> +    }
>> >> +
>> >>
>> >>      /* Send request to pager */
>> >>      req.gfn = gfn;
>> >> @@ -925,8 +935,13 @@
>> >>      req.vcpu_id = v->vcpu_id;
>> >>
>> >>      mem_event_put_request(d, &d->mem_paging, &req);
>> >> +
>> >> +    ret = 0;
>> >> + out:
>> >> +    return ret;
>> >>  }
>> >>
>> >> +
>> >>  /**
>> >>   * p2m_mem_paging_prep - Allocate a new page for the guest
>> >>   * @d: guest domain
>> >> diff -r 052727b8165c -r 978daceef147 xen/include/asm-x86/p2m.h
>> >> --- a/xen/include/asm-x86/p2m.h	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/xen/include/asm-x86/p2m.h	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -485,7 +485,7 @@
>> >>  /* Tell xenpaging to drop a paged out frame */
>> >>  void 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);
>> >> +int 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);
>> >>  /* Resume normal operation (in case a domain was paused) */
>> >> diff -r 052727b8165c -r 978daceef147 xen/include/public/domctl.h
>> >> --- a/xen/include/public/domctl.h	Thu Dec 29 17:08:24 2011 +0800
>> >> +++ b/xen/include/public/domctl.h	Thu Dec 29 19:41:39 2011 +0800
>> >> @@ -721,6 +721,7 @@
>> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
>> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
>> >>  #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
>> >> +#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_IN         6
>> >>
>> >>  /*
>> >>   * Access permissions.
>> >>
>> >
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/xen-devel
>> >
>> >
>> >
>> >
>> > ------------------------------
>> >
>> > _______________________________________________
>> > Xen-devel mailing list
>> > Xen-devel@lists.xensource.com
>> > http://lists.xensource.com/xen-devel
>> >
>> >
>> > End of Xen-devel Digest, Vol 83, Issue 39
>> > *****************************************
>> >
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 04:54:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 04: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 1RkTiN-0007aD-Av; Tue, 10 Jan 2012 04:53: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 1RkTiL-0007a8-Hg
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 04:53:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326171177!55263409!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDE0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30432 invoked from network); 10 Jan 2012 04:52:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 04:52:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,484,1320624000"; 
   d="scan'208";a="9910945"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 04:53: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, 10 Jan 2012 04:53: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 1RkTiJ-0005uL-Tx;
	Tue, 10 Jan 2012 04:53:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RkTiJ-0001I2-Ji;
	Tue, 10 Jan 2012 04:53:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10649-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Jan 2012 04:53:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10649: 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 10649 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10649/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-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-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-amd64-amd64-xl-winxpsp3 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 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b2676ac1321
baseline version:
 xen                  5b2676ac1321

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Tue Jan 10 04:54:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 04: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 1RkTiN-0007aD-Av; Tue, 10 Jan 2012 04:53: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 1RkTiL-0007a8-Hg
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 04:53:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326171177!55263409!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDE0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30432 invoked from network); 10 Jan 2012 04:52:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 04:52:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,484,1320624000"; 
   d="scan'208";a="9910945"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 04:53: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, 10 Jan 2012 04:53: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 1RkTiJ-0005uL-Tx;
	Tue, 10 Jan 2012 04:53:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RkTiJ-0001I2-Ji;
	Tue, 10 Jan 2012 04:53:35 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10649-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 10 Jan 2012 04:53:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10649: 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 10649 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10649/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-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-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-amd64-amd64-xl-winxpsp3 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 13 guest-stop               fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass

version targeted for testing:
 xen                  5b2676ac1321
baseline version:
 xen                  5b2676ac1321

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Tue Jan 10 05:49:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 05:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkUZK-0008Ow-6q; Tue, 10 Jan 2012 05:48:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RkUZI-0008Or-VR
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 05:48:21 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326174492!10180964!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIyNDY3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22430 invoked from network); 10 Jan 2012 05:48:13 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-16.tower-216.messagelabs.com with SMTP;
	10 Jan 2012 05:48:13 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 09 Jan 2012 21:48:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="54945914"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 09 Jan 2012 21:48:11 -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; Tue, 10 Jan 2012 13:47:51 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 10 Jan 2012 13:47:50 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.60]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 13:47:48 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4AACb/RMAACRHyAAI09hpAACpZegAAvdLuw
Date: Tue, 10 Jan 2012 05:47:48 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10FCBE178@SHSMSX102.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
	<20120109150436.GD25563@phenom.dumpdata.com>
In-Reply-To: <20120109150436.GD25563@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Monday, January 09, 2012 11:05 PM
> 
> > > But more interestingly - are you building your kernel from scratch? There
> >
> > yes
> >
> > > was some requirements in having CONFIG_IOMMU_DMAR in the kernels -
> > > otherwise
> > > the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.
> >
> > Suppose you mean CONFIG_DMAR_TABLE? There's no
> CONFIG_IOMMU_DMAR
> > in the latest kernel. Yes, I didn't enable that option, and will have a try.
> 
> Yes, that is the option.
> 
> >
> > But a side question is, will enabling VT-d in dom0 conflict with Xen's own
> > VT-d operations?
> 
> No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux's
> parser won't pick it up.

Hi, Konrad,

this information is really great, and now X can be started smoothly, and also
a simple glxgear runs well! :-) This options deserves an explicit mark in the
wiki page btw.

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 Jan 10 05:49:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 05:49:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkUZK-0008Ow-6q; Tue, 10 Jan 2012 05:48:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RkUZI-0008Or-VR
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 05:48:21 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326174492!10180964!1
X-Originating-IP: [143.182.124.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQzLjE4Mi4xMjQuMzcgPT4gMjIyNDY3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22430 invoked from network); 10 Jan 2012 05:48:13 -0000
Received: from mga14.intel.com (HELO mga14.intel.com) (143.182.124.37)
	by server-16.tower-216.messagelabs.com with SMTP;
	10 Jan 2012 05:48:13 -0000
Received: from azsmga002.ch.intel.com ([10.2.17.35])
	by azsmga102.ch.intel.com with ESMTP; 09 Jan 2012 21:48:12 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="54945914"
Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87])
	by AZSMGA002.ch.intel.com with ESMTP; 09 Jan 2012 21:48:11 -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; Tue, 10 Jan 2012 13:47:51 +0800
Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by
	PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server
	(TLS) id 14.1.355.2; Tue, 10 Jan 2012 13:47:50 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX101.ccr.corp.intel.com ([169.254.1.60]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 13:47:48 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4AACb/RMAACRHyAAI09hpAACpZegAAvdLuw
Date: Tue, 10 Jan 2012 05:47:48 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10FCBE178@SHSMSX102.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
	<20120109150436.GD25563@phenom.dumpdata.com>
In-Reply-To: <20120109150436.GD25563@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Monday, January 09, 2012 11:05 PM
> 
> > > But more interestingly - are you building your kernel from scratch? There
> >
> > yes
> >
> > > was some requirements in having CONFIG_IOMMU_DMAR in the kernels -
> > > otherwise
> > > the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.
> >
> > Suppose you mean CONFIG_DMAR_TABLE? There's no
> CONFIG_IOMMU_DMAR
> > in the latest kernel. Yes, I didn't enable that option, and will have a try.
> 
> Yes, that is the option.
> 
> >
> > But a side question is, will enabling VT-d in dom0 conflict with Xen's own
> > VT-d operations?
> 
> No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux's
> parser won't pick it up.

Hi, Konrad,

this information is really great, and now X can be started smoothly, and also
a simple glxgear runs well! :-) This options deserves an explicit mark in the
wiki page btw.

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 Jan 10 08:33:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 08: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 1RkX7s-0001TM-3t; Tue, 10 Jan 2012 08:32:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkX7q-0001TD-K6
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 08:32:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326184324!8495703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDE0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9704 invoked from network); 10 Jan 2012 08:32:04 -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;
	10 Jan 2012 08:32:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,485,1320624000"; 
   d="scan'208";a="9912919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 08:32:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Jan 2012 08:32:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326132001-21251-10-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-10-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Tue, 10 Jan 2012 08:32:03 +0000
Message-ID: <1326184323.29084.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>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Bit manipulation, division and memcpy & friends implementations for the
> ARM architecture, shamelessly taken from Linux.

When I initially imported these I did so with the minimal changes
possible to integrate the in the Xen tree so as to aid future merges of
this code from Linux.

This meant there was quite a lot of ifdef'd code (in particular for
previous ARM architectures via __LINUX_ARM_ARCH__) but I think that is a
price worth paying to keep these files somewhat in sync. I used a pretty
ugly "#if 1 /* __LINUX_ARM_ARCH__ >= 5 */" construct to minimise changes
but perhaps it would be better to simply define __LINUX_ARM_ARCH__
appropriately within the lib subdirectory?

Ian.

> 
> 
> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 08:33:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 08: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 1RkX7s-0001TM-3t; Tue, 10 Jan 2012 08:32:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkX7q-0001TD-K6
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 08:32:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326184324!8495703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDE0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9704 invoked from network); 10 Jan 2012 08:32:04 -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;
	10 Jan 2012 08:32:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,485,1320624000"; 
   d="scan'208";a="9912919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 08:32:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Jan 2012 08:32:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326132001-21251-10-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-10-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
Date: Tue, 10 Jan 2012 08:32:03 +0000
Message-ID: <1326184323.29084.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>, "Tim
	Deegan \(3P\)" <Tim.Deegan@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Bit manipulation, division and memcpy & friends implementations for the
> ARM architecture, shamelessly taken from Linux.

When I initially imported these I did so with the minimal changes
possible to integrate the in the Xen tree so as to aid future merges of
this code from Linux.

This meant there was quite a lot of ifdef'd code (in particular for
previous ARM architectures via __LINUX_ARM_ARCH__) but I think that is a
price worth paying to keep these files somewhat in sync. I used a pretty
ugly "#if 1 /* __LINUX_ARM_ARCH__ >= 5 */" construct to minimise changes
but perhaps it would be better to simply define __LINUX_ARM_ARCH__
appropriately within the lib subdirectory?

Ian.

> 
> 
> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 08:48:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 08:48:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkXMX-0001fv-QP; Tue, 10 Jan 2012 08:47:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RkXMX-0001fq-7k
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 08:47:21 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326185233!8429273!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 29784 invoked from network); 10 Jan 2012 08:47:14 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Jan 2012 08:47:14 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RkXMO-0002qE-R1
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 00:47:12 -0800
Date: Tue, 10 Jan 2012 00:47:12 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1326185232800-5133661.post@n5.nabble.com>
In-Reply-To: <20120109213039.GC4773@phenom.dumpdata.com>
References: <20120109213039.GC4773@phenom.dumpdata.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks to all for good work, I tried Precise as domU pv (with kernel 3.2) and
I have found critical regression, probably there is a bug or unexpected
cases in some blk commit
I have already report on launchpad, this is the link:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/913760
Dom0 have Squeeze kernel build 2.6.32-35squeeze2, if you need more
information just ask I hope to be helpful.
Thanks and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Features-and-bug-fixes-that-went-in-Linux-3-2-tp5132575p5133661.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 Jan 10 08:48:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 08:48:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkXMX-0001fv-QP; Tue, 10 Jan 2012 08:47:21 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RkXMX-0001fq-7k
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 08:47:21 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326185233!8429273!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 29784 invoked from network); 10 Jan 2012 08:47:14 -0000
Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26)
	by server-12.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	10 Jan 2012 08:47:14 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RkXMO-0002qE-R1
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 00:47:12 -0800
Date: Tue, 10 Jan 2012 00:47:12 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1326185232800-5133661.post@n5.nabble.com>
In-Reply-To: <20120109213039.GC4773@phenom.dumpdata.com>
References: <20120109213039.GC4773@phenom.dumpdata.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks to all for good work, I tried Precise as domU pv (with kernel 3.2) and
I have found critical regression, probably there is a bug or unexpected
cases in some blk commit
I have already report on launchpad, this is the link:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/913760
Dom0 have Squeeze kernel build 2.6.32-35squeeze2, if you need more
information just ask I hope to be helpful.
Thanks and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Features-and-bug-fixes-that-went-in-Linux-3-2-tp5132575p5133661.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 Jan 10 08:57:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 08:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkXVJ-0001pk-R3; Tue, 10 Jan 2012 08:56:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RkXVI-0001pf-Sq
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 08:56:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326185777!8499583!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 916 invoked from network); 10 Jan 2012 08:56:18 -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;
	10 Jan 2012 08:56:18 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RkXVA-0003hM-LK
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 00:56:16 -0800
Date: Tue, 10 Jan 2012 00:56:16 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1326185776653-5133679.post@n5.nabble.com>
In-Reply-To: <1322661592292-5035582.post@n5.nabble.com>
References: <1322219529495-5022556.post@n5.nabble.com>
	<1322658156.31810.86.camel@zakaz.uk.xensource.com>
	<1322661592292-5035582.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Someone can help me to add phy cdrom working and correct see as cdrom on
ubuntu domUs pv or there is some features missing for to this?
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5022556p5133679.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 Jan 10 08:57:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 08:57:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkXVJ-0001pk-R3; Tue, 10 Jan 2012 08:56:25 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RkXVI-0001pf-Sq
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 08:56:25 +0000
X-Env-Sender: fantonifabio@tiscali.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326185777!8499583!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 916 invoked from network); 10 Jan 2012 08:56:18 -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;
	10 Jan 2012 08:56:18 -0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <fantonifabio@tiscali.it>) id 1RkXVA-0003hM-LK
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 00:56:16 -0800
Date: Tue, 10 Jan 2012 00:56:16 -0800 (PST)
From: Fantu <fantonifabio@tiscali.it>
To: xen-devel@lists.xensource.com
Message-ID: <1326185776653-5133679.post@n5.nabble.com>
In-Reply-To: <1322661592292-5035582.post@n5.nabble.com>
References: <1322219529495-5022556.post@n5.nabble.com>
	<1322658156.31810.86.camel@zakaz.uk.xensource.com>
	<1322661592292-5035582.post@n5.nabble.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Cdrom on Linux domU PV
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Someone can help me to add phy cdrom working and correct see as cdrom on
ubuntu domUs pv or there is some features missing for to this?
Thanks for any reply and sorry for bad english.

--
View this message in context: http://xen.1045712.n5.nabble.com/Cdrom-on-Linux-domU-PV-tp5022556p5133679.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 Jan 10 09:01:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 09:01:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkXZn-0001zs-Lf; Tue, 10 Jan 2012 09:01: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 1RkXZl-0001zh-PQ
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 09:01:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326186054!9801356!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22646 invoked from network); 10 Jan 2012 09:00:54 -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;
	10 Jan 2012 09:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9913626"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 09:00:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Jan 2012 09:00:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F0B3132.5080601@citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-23-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0B3132.5080601@citrix.com>
Organization: Citrix Systems, Inc.
Date: Tue, 10 Jan 2012 09:00:52 +0000
Message-ID: <1326186052.29084.86.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 Deegan
	\(3P\)" <Tim.Deegan@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 2012-01-09 at 18:25 +0000, David Vrabel wrote:
> On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> > 
> > +static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> > +{
> [...]
> > +    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;
> 
> This needs to return 1 or recent kernels will crash when they try and
> read these registers.
> 
> David
> 
> From 8c2377a9b4a10cba57fba9f8a19177ac73339d78 Mon Sep 17 00:00:00 2001
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 9 Jan 2012 15:17:22 +0000
> Subject: [PATCH] ARM: allow guest to read GICD_ICFGRn registers
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/vgic.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 26eae55..584e682 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -266,7 +266,7 @@ static int vgic_distr_mmio_read(struct vcpu *v,
> mmio_info_t *info)
>          vgic_lock_rank(v, rank);
>          *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
>          vgic_unlock_rank(v, rank);
> -        return 0;
> +        return 1;
> 
>      case GICD_NSACR ... GICD_NSACRN:
>          /* We do not implement securty extensions for guests, read zero */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 09:01:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 09:01:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkXZn-0001zs-Lf; Tue, 10 Jan 2012 09:01: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 1RkXZl-0001zh-PQ
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 09:01:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326186054!9801356!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22646 invoked from network); 10 Jan 2012 09:00:54 -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;
	10 Jan 2012 09:00:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9913626"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 09:00:54 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Jan 2012 09:00:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F0B3132.5080601@citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-23-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0B3132.5080601@citrix.com>
Organization: Citrix Systems, Inc.
Date: Tue, 10 Jan 2012 09:00:52 +0000
Message-ID: <1326186052.29084.86.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 Deegan
	\(3P\)" <Tim.Deegan@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 2012-01-09 at 18:25 +0000, David Vrabel wrote:
> On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> > 
> > +static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> > +{
> [...]
> > +    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;
> 
> This needs to return 1 or recent kernels will crash when they try and
> read these registers.
> 
> David
> 
> From 8c2377a9b4a10cba57fba9f8a19177ac73339d78 Mon Sep 17 00:00:00 2001
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 9 Jan 2012 15:17:22 +0000
> Subject: [PATCH] ARM: allow guest to read GICD_ICFGRn registers
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/vgic.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 26eae55..584e682 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -266,7 +266,7 @@ static int vgic_distr_mmio_read(struct vcpu *v,
> mmio_info_t *info)
>          vgic_lock_rank(v, rank);
>          *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
>          vgic_unlock_rank(v, rank);
> -        return 0;
> +        return 1;
> 
>      case GICD_NSACR ... GICD_NSACRN:
>          /* We do not implement securty extensions for guests, read zero */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 09:02:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 09:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkXak-00023S-42; Tue, 10 Jan 2012 09:02:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkXaj-00023K-8M
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 09:02:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326186100!61793542!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18717 invoked from network); 10 Jan 2012 09:01:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 09:01:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9913656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 09:01:44 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Jan 2012 09:01:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F0B3218.5070101@citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-13-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0B3218.5070101@citrix.com>
Organization: Citrix Systems, Inc.
Date: Tue, 10 Jan 2012 09:01:42 +0000
Message-ID: <1326186102.29084.87.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 Deegan
	\(3P\)" <Tim.Deegan@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 2012-01-09 at 18:29 +0000, David Vrabel wrote:
> On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> > 
> > +int construct_dom0(struct domain *d)
> > +{
> [...]
> > +    printk("Routing peripheral interrupts to guest\n");
> > +    /* TODO Get from device tree */
> 
> Can you route interrupt 34 (timer0) to dom0 as well?  Current mainline
> kernels are using this timer.
> 
> David
> 
> From 88148e85b2d8d9bf60564d4b5eb2ac73d8389fa5 Mon Sep 17 00:00:00 2001
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 9 Jan 2012 15:21:37 +0000
> Subject: [PATCH] ARM: route timer0 interrupt to dom0

This is the peripheral timer rather than one of the generic timers
provided by the processor. Exposing it to dom0 is correct.

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/domain_build.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c36b888..cbbc0b9 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -108,6 +108,7 @@ int construct_dom0(struct domain *d)
> 
>      printk("Routing peripheral interrupts to guest\n");
>      /* TODO Get from device tree */
> +    gic_route_irq_to_guest(d, 34, "timer0");
>      /*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");



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 09:02:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 09:02:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkXak-00023S-42; Tue, 10 Jan 2012 09:02:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkXaj-00023K-8M
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 09:02:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326186100!61793542!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18717 invoked from network); 10 Jan 2012 09:01:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 09:01:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9913656"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 09:01:44 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 10 Jan 2012 09:01:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
In-Reply-To: <4F0B3218.5070101@citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-13-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0B3218.5070101@citrix.com>
Organization: Citrix Systems, Inc.
Date: Tue, 10 Jan 2012 09:01:42 +0000
Message-ID: <1326186102.29084.87.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 Deegan
	\(3P\)" <Tim.Deegan@citrix.com>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 2012-01-09 at 18:29 +0000, David Vrabel wrote:
> On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> > 
> > +int construct_dom0(struct domain *d)
> > +{
> [...]
> > +    printk("Routing peripheral interrupts to guest\n");
> > +    /* TODO Get from device tree */
> 
> Can you route interrupt 34 (timer0) to dom0 as well?  Current mainline
> kernels are using this timer.
> 
> David
> 
> From 88148e85b2d8d9bf60564d4b5eb2ac73d8389fa5 Mon Sep 17 00:00:00 2001
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 9 Jan 2012 15:21:37 +0000
> Subject: [PATCH] ARM: route timer0 interrupt to dom0

This is the peripheral timer rather than one of the generic timers
provided by the processor. Exposing it to dom0 is correct.

> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  xen/arch/arm/domain_build.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c36b888..cbbc0b9 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -108,6 +108,7 @@ int construct_dom0(struct domain *d)
> 
>      printk("Routing peripheral interrupts to guest\n");
>      /* TODO Get from device tree */
> +    gic_route_irq_to_guest(d, 34, "timer0");
>      /*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");



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 09:37:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 09: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 1RkY8u-0002Qd-T6; Tue, 10 Jan 2012 09:37:20 +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 1RkY8s-0002QY-To
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 09:37:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326188232!10287915!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 12104 invoked from network); 10 Jan 2012 09:37:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Jan 2012 09:37:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkY8k-000LrW-7X; Tue, 10 Jan 2012 09:37:10 +0000
Date: Tue, 10 Jan 2012 09:37:09 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20120110093709.GA81891@ocelot.phlegethon.org>
References: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
	<20120109100956.GE26595@ocelot.phlegethon.org>
	<CAK6aU6idWKayh6bAEkBo4vSt4HWKQneYEDLVEQfYxusC=HUrRA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAK6aU6idWKayh6bAEkBo4vSt4HWKQneYEDLVEQfYxusC=HUrRA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] changing attributes of a 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

Hi, 

Please don't top-post. 

At 14:41 +0330 on 09 Jan (1326120068), Mohamad Rezaei wrote:
> I have started Dom0 with dom0_shadow=1. So it must be running with a
> read-only page table. I thought p2m is responsible for updating the
> dom0's page-table.

PV guests don't have p2m in the hypervisor -- they take care of their
own p2m translations and make pagetables that already point to machihe
addresses.

> I have looked at _sh_propagate() but I couldn't
> find any option to change page attributes like RWX.

Look again. :)  That function makes the PTE that the hardware will
see.  So all you need to do is mask _PAGE_RW out of the sflags when you
see an l1 entry where target_mfn is one of the MFNs you're protecting.
Look at how log-dirty is handled, for example. 

Of course, once you've done that, you also need to handle the pagefaults
that will happen if the guest writes to that memory!

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 09:37:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 09: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 1RkY8u-0002Qd-T6; Tue, 10 Jan 2012 09:37:20 +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 1RkY8s-0002QY-To
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 09:37:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326188232!10287915!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 12104 invoked from network); 10 Jan 2012 09:37:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Jan 2012 09:37:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkY8k-000LrW-7X; Tue, 10 Jan 2012 09:37:10 +0000
Date: Tue, 10 Jan 2012 09:37:09 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20120110093709.GA81891@ocelot.phlegethon.org>
References: <CAK6aU6iNVfAPfoAnhpYGbFQye+XmvhDnU-f-eEM0C5DBAyyY0Q@mail.gmail.com>
	<20120109100956.GE26595@ocelot.phlegethon.org>
	<CAK6aU6idWKayh6bAEkBo4vSt4HWKQneYEDLVEQfYxusC=HUrRA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAK6aU6idWKayh6bAEkBo4vSt4HWKQneYEDLVEQfYxusC=HUrRA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] changing attributes of a 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

Hi, 

Please don't top-post. 

At 14:41 +0330 on 09 Jan (1326120068), Mohamad Rezaei wrote:
> I have started Dom0 with dom0_shadow=1. So it must be running with a
> read-only page table. I thought p2m is responsible for updating the
> dom0's page-table.

PV guests don't have p2m in the hypervisor -- they take care of their
own p2m translations and make pagetables that already point to machihe
addresses.

> I have looked at _sh_propagate() but I couldn't
> find any option to change page attributes like RWX.

Look again. :)  That function makes the PTE that the hardware will
see.  So all you need to do is mask _PAGE_RW out of the sflags when you
see an l1 entry where target_mfn is one of the MFNs you're protecting.
Look at how log-dirty is handled, for example. 

Of course, once you've done that, you also need to handle the pagefaults
that will happen if the guest writes to that memory!

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 09:43:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 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 1RkYEb-0002Z6-Mp; Tue, 10 Jan 2012 09:43:13 +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 1RkYEa-0002Yu-Sv
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 09:43:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326188586!8496604!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 3126 invoked from network); 10 Jan 2012 09:43:06 -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; 10 Jan 2012 09:43:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkYES-000Lth-LN; Tue, 10 Jan 2012 09:43:04 +0000
Date: Tue, 10 Jan 2012 09:43:03 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20120110094303.GB81891@ocelot.phlegethon.org>
References: <CAK6aU6huANSew5B1mQsKSeqTuEqnSfkuCFbxVCW-q4Qjcw5heg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAK6aU6huANSew5B1mQsKSeqTuEqnSfkuCFbxVCW-q4Qjcw5heg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] enable NX (execution disabled) bit for Com0?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:43 +0330 on 09 Jan (1326120209), Mohamad Rezaei wrote:
> Is there a way to re-enable NX bit from Xen for a kernel that has
> disabled it?

Do you mean in the pagetable entries?  Then yes -- you can do it the
same way you're making pages read-only, by fiddling with the PTE flags in
_sh_propagate().

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 09:43:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 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 1RkYEb-0002Z6-Mp; Tue, 10 Jan 2012 09:43:13 +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 1RkYEa-0002Yu-Sv
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 09:43:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326188586!8496604!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 3126 invoked from network); 10 Jan 2012 09:43:06 -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; 10 Jan 2012 09:43:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RkYES-000Lth-LN; Tue, 10 Jan 2012 09:43:04 +0000
Date: Tue, 10 Jan 2012 09:43:03 +0000
From: Tim Deegan <tim@xen.org>
To: Mohamad Rezaei <mmrezaie@gmail.com>
Message-ID: <20120110094303.GB81891@ocelot.phlegethon.org>
References: <CAK6aU6huANSew5B1mQsKSeqTuEqnSfkuCFbxVCW-q4Qjcw5heg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAK6aU6huANSew5B1mQsKSeqTuEqnSfkuCFbxVCW-q4Qjcw5heg@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] enable NX (execution disabled) bit for Com0?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 14:43 +0330 on 09 Jan (1326120209), Mohamad Rezaei wrote:
> Is there a way to re-enable NX bit from Xen for a kernel that has
> disabled it?

Do you mean in the pagetable entries?  Then yes -- you can do it the
same way you're making pages read-only, by fiddling with the PTE flags in
_sh_propagate().

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:03:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkYXU-0002py-K2; Tue, 10 Jan 2012 10:02:44 +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 1RkYXS-0002pt-SN
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:02:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326189755!8501003!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 30430 invoked from network); 10 Jan 2012 10:02:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Jan 2012 10:02:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 10:02:35 +0000
Message-Id: <4F0C1AC9020000780006B860@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 10:02:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>,<xen-devel@lists.xensource.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326132001-21251-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 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.01.12 at 18:59, <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -107,11 +107,32 @@ void elf_set_log(struct elf_binary *elf, 
> elf_log_callback *log_callback,
>      elf->log_caller_data = log_caller_data;
>      elf->verbose = verbose;
>  }
> +
> +static int elf_load_image(void *dst, const void *src, uint64_t filesz, 
> uint64_t memsz)
> +{
> +    memcpy(dst, src, filesz);
> +    memset(dst + filesz, 0, memsz - filesz);
> +    return 0;
> +}
>  #else
> +#include <asm/guest_access.h>
> +
>  void elf_set_verbose(struct elf_binary *elf)
>  {
>      elf->verbose = 1;
>  }
> +
> +static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
> +{
> +    int rc;
> +    rc = raw_copy_to_guest(dst, src, filesz);
> +    if ( rc != 0 )
> +        return -rc;
> +    rc = raw_clear_guest(dst + filesz, memsz - filesz);
> +    if ( rc != 0 )
> +        return -rc;
> +    return 0;
> +}

I'm afraid a little more care is needed here: filesz and memsz being
64-bit values permits them to overflow the "long" of the functions
called. I think simply checking that both values fit in an unsigned long
will do for now.

Also, if you want to return a meaningful error code here, you also
need to consider that fact as well as the counts being unsigned (or
otherwise you could e.g. just return "bool").

Jan

>  #endif
>  
>  /* Calculate the required additional kernel space for the elf image */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:03:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkYXU-0002py-K2; Tue, 10 Jan 2012 10:02:44 +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 1RkYXS-0002pt-SN
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:02:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326189755!8501003!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 30430 invoked from network); 10 Jan 2012 10:02:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Jan 2012 10:02:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 10:02:35 +0000
Message-Id: <4F0C1AC9020000780006B860@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 10:02:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>,<xen-devel@lists.xensource.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-6-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326132001-21251-6-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 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.01.12 at 18:59, <stefano.stabellini@eu.citrix.com> wrote:
> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -107,11 +107,32 @@ void elf_set_log(struct elf_binary *elf, 
> elf_log_callback *log_callback,
>      elf->log_caller_data = log_caller_data;
>      elf->verbose = verbose;
>  }
> +
> +static int elf_load_image(void *dst, const void *src, uint64_t filesz, 
> uint64_t memsz)
> +{
> +    memcpy(dst, src, filesz);
> +    memset(dst + filesz, 0, memsz - filesz);
> +    return 0;
> +}
>  #else
> +#include <asm/guest_access.h>
> +
>  void elf_set_verbose(struct elf_binary *elf)
>  {
>      elf->verbose = 1;
>  }
> +
> +static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
> +{
> +    int rc;
> +    rc = raw_copy_to_guest(dst, src, filesz);
> +    if ( rc != 0 )
> +        return -rc;
> +    rc = raw_clear_guest(dst + filesz, memsz - filesz);
> +    if ( rc != 0 )
> +        return -rc;
> +    return 0;
> +}

I'm afraid a little more care is needed here: filesz and memsz being
64-bit values permits them to overflow the "long" of the functions
called. I think simply checking that both values fit in an unsigned long
will do for now.

Also, if you want to return a meaningful error code here, you also
need to consider that fact as well as the counts being unsigned (or
otherwise you could e.g. just return "bool").

Jan

>  #endif
>  
>  /* Calculate the required additional kernel space for the elf image */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:05:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10: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 1RkYZL-0002uX-3t; Tue, 10 Jan 2012 10:04:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkYZJ-0002uF-NL
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:04:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326189864!11728004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26654 invoked from network); 10 Jan 2012 10:04:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 10:04:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9915376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 10:04: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, 10 Jan 2012 10:04:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Tue, 10 Jan 2012 10:04:23 +0000
In-Reply-To: <1326132001-21251-14-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-14-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326189863.17210.125.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>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
wrote:
> 
> +static unsigned int gic_irq_startup(struct irq_desc *desc)
> +{
> +    uint32_t enabler;
> +       int irq = desc->irq;
> + 

Some hard tabs appear to have snuck in at least a couple of times in
this file and elsewhere:
$ find xen/arch/arm/ xen/include/asm-arm/ -name \*.[ch] | xargs grep '     ' -l
xen/arch/arm/smp.c
xen/arch/arm/lib/bitops.h
xen/arch/arm/irq.c
xen/arch/arm/gic.c
xen/arch/arm/vtimer.c
xen/arch/arm/setup.c
xen/arch/arm/domain.c
xen/include/asm-arm/numa.h
xen/include/asm-arm/grant_table.h
xen/include/asm-arm/div64.h

I think hard tabs are OK in code from Linux (e.g.
xen/arch/arm/lib/bitops.h) and in .S files but not elsewhere.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:05:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10: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 1RkYZL-0002uX-3t; Tue, 10 Jan 2012 10:04:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RkYZJ-0002uF-NL
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:04:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326189864!11728004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26654 invoked from network); 10 Jan 2012 10:04:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 10:04:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9915376"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 10:04: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, 10 Jan 2012 10:04:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Tue, 10 Jan 2012 10:04:23 +0000
In-Reply-To: <1326132001-21251-14-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-14-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326189863.17210.125.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>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
wrote:
> 
> +static unsigned int gic_irq_startup(struct irq_desc *desc)
> +{
> +    uint32_t enabler;
> +       int irq = desc->irq;
> + 

Some hard tabs appear to have snuck in at least a couple of times in
this file and elsewhere:
$ find xen/arch/arm/ xen/include/asm-arm/ -name \*.[ch] | xargs grep '     ' -l
xen/arch/arm/smp.c
xen/arch/arm/lib/bitops.h
xen/arch/arm/irq.c
xen/arch/arm/gic.c
xen/arch/arm/vtimer.c
xen/arch/arm/setup.c
xen/arch/arm/domain.c
xen/include/asm-arm/numa.h
xen/include/asm-arm/grant_table.h
xen/include/asm-arm/div64.h

I think hard tabs are OK in code from Linux (e.g.
xen/arch/arm/lib/bitops.h) and in .S files but not elsewhere.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:05:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkYa4-0002xi-IU; Tue, 10 Jan 2012 10:05:24 +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 1RkYa2-0002x1-3z
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:05:22 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326189914!10281817!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7609 invoked from network); 10 Jan 2012 10:05:15 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 10:05:15 -0000
Received: by ggnh1 with SMTP id h1so2726194ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 02:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=VMt6UCufvYLtFm9G69IqSMhSNpnTwMSWhNnrMU+NI3U=;
	b=p5Drs5Q5xjmB/Y0m+QH2tqZHhE3p96w0b5v6k7doNYgB4C+zjWtVF1K4ZZmLrFXSw1
	E31Obp977Lc47mJkypLWVvX4/opd+iiqs03UYsMkmnJHuZfo6f5yvanIc/Pq1RG7Q5Pf
	GJwgL40m/v0qlt0aGdkBCSLbxyVyU54AVh978=
MIME-Version: 1.0
Received: by 10.50.188.166 with SMTP id gb6mr1814686igc.18.1326189912037; Tue,
	10 Jan 2012 02:05:12 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Tue, 10 Jan 2012 02:05:11 -0800 (PST)
In-Reply-To: <fe8d0ca867aa280cbfb3.1326104556@wsm-ep-n0>
References: <fe8d0ca867aa280cbfb3.1326104556@wsm-ep-n0>
Date: Tue, 10 Jan 2012 10:05:11 +0000
X-Google-Sender-Auth: 5DNPHECMLt5OQfR8BBzvkIZZjiQ
Message-ID: <CAFLBxZYJ3oYaXbPoFMYU5omN6rPQcR9zJm_FRJKxxYCKzg5iDQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Hui Lv <hui.lv@intel.com>
Cc: xen-devel@lists.xensource.com, raistlin@linux.it, Ian.Campbell@citrix.com,
	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="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, Jan 9, 2012 at 10:22 AM, Hui Lv <hui.lv@intel.com> wrote:
> Updated the warning sentence for ratelimit_us.
>
> This patch can improve Xen performance:
> 1. Basically, the "delay method" can achieve 11% overall performance boos=
t for SPECvirt than original credit scheduler.
> 2. We have tried 1ms delay and 10ms delay, there is no big difference bet=
ween 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 pro=
duces the benefits. (int sched_ratelimit_us =3D 1000 is the recommended set=
ting)
>
> Signed-off-by: Hui Lv <hui.lv@intel.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Just confirming this:
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks, Hui.
 -George

>
> diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -0500
> @@ -172,6 +172,7 @@ struct csched_private {
> =A0 =A0 uint32_t credit;
> =A0 =A0 int credit_balance;
> =A0 =A0 uint32_t runq_sort;
> + =A0 =A0unsigned ratelimit_us;
> =A0 =A0 /* Period of master and tick in milliseconds */
> =A0 =A0 unsigned tslice_ms, tick_period_us, ticks_per_tslice;
> =A0 =A0 unsigned credits_per_tslice;
> @@ -1297,10 +1298,15 @@ csched_schedule(
> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
> =A0 =A0 struct csched_vcpu *snext;
> =A0 =A0 struct task_slice ret;
> + =A0 =A0s_time_t runtime, tslice;
>
> =A0 =A0 CSCHED_STAT_CRANK(schedule);
> =A0 =A0 CSCHED_VCPU_CHECK(current);
>
> + =A0 =A0runtime =3D now - current->runstate.state_entry_time;
> + =A0 =A0if ( runtime < 0 ) /* Does this ever happen? */
> + =A0 =A0 =A0 =A0runtime =3D 0;
> +
> =A0 =A0 if ( !is_idle_vcpu(scurr->vcpu) )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 /* Update credits of a non-idle VCPU. */
> @@ -1313,6 +1319,35 @@ csched_schedule(
> =A0 =A0 =A0 =A0 scurr->pri =3D CSCHED_PRI_IDLE;
> =A0 =A0 }
>
> + =A0 =A0/* Choices, choices:
> + =A0 =A0 * - If we have a tasklet, we need to run the idle vcpu no matte=
r what.
> + =A0 =A0 * - If sched rate limiting is in effect, and the current vcpu h=
as
> + =A0 =A0 * =A0 run for less than that amount of time, continue the curre=
nt one,
> + =A0 =A0 * =A0 but with a shorter timeslice and return it immediately
> + =A0 =A0 * - Otherwise, chose the one with the highest priority (which m=
ay
> + =A0 =A0 * =A0 be the one currently running)
> + =A0 =A0 * - If the currently running one is TS_OVER, see if there
> + =A0 =A0 * =A0 is a higher priority one waiting on the runqueue of anoth=
er
> + =A0 =A0 * =A0 cpu and steal it.
> + =A0 =A0 */
> +
> + =A0 =A0/* If we have schedule rate limiting enabled, check to see
> + =A0 =A0 * how long we've run for. */
> + =A0 =A0if ( !tasklet_work_scheduled
> + =A0 =A0 =A0 =A0 && prv->ratelimit_us
> + =A0 =A0 =A0 =A0 && vcpu_runnable(current)
> + =A0 =A0 =A0 =A0 && !is_idle_vcpu(current)
> + =A0 =A0 =A0 =A0 && runtime < MICROSECS(prv->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(prv->ratelimit_us);
> + =A0 =A0 =A0 =A0ret.migrated =3D 0;
> + =A0 =A0 =A0 =A0goto out;
> + =A0 =A0}
> + =A0 =A0tslice =3D MILLISECS(prv->tslice_ms);
> +
> =A0 =A0 /*
> =A0 =A0 =A0* Select next runnable local VCPU (ie top of local runq)
> =A0 =A0 =A0*/
> @@ -1367,11 +1402,12 @@ csched_schedule(
> =A0 =A0 if ( !is_idle_vcpu(snext->vcpu) )
> =A0 =A0 =A0 =A0 snext->start_time +=3D now;
>
> +out:
> =A0 =A0 /*
> =A0 =A0 =A0* Return task to run next...
> =A0 =A0 =A0*/
> =A0 =A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ?
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(prv->tslice_ms));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : tslice);
> =A0 =A0 ret.task =3D snext->vcpu;
>
> =A0 =A0 CSCHED_VCPU_CHECK(ret.task);
> @@ -1533,6 +1569,15 @@ csched_init(struct scheduler *ops)
> =A0 =A0 prv->tick_period_us =3D prv->tslice_ms * 1000 / prv->ticks_per_ts=
lice;
> =A0 =A0 prv->credits_per_tslice =3D CSCHED_CREDITS_PER_MSEC * prv->tslice=
_ms;
>
> + =A0 =A0if ( MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tsli=
ce_ms) )
> + =A0 =A0{
> + =A0 =A0 =A0 =A0printk("WARNING: sched_ratelimit_us >"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "sched_credit_tslice_ms is undefined\n"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Setting ratelimit_us to 1000 * tslice_ms\n=
");
> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D 1000 * prv->tslice_ms;
> + =A0 =A0}
> + =A0 =A0else
> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D sched_ratelimit_us;
> =A0 =A0 return 0;
> =A0}
>
> diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
> --- a/xen/common/schedule.c =A0 =A0 Fri Dec 16 18:46:27 2011 +0000
> +++ b/xen/common/schedule.c =A0 =A0 Mon Jan 09 05:21:35 2012 -0500
> @@ -47,6 +47,11 @@ string_param("sched", opt_sched);
> =A0bool_t sched_smt_power_savings =3D 0;
> =A0boolean_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_tsl=
ice_ms is undefined
> + * */
> +int sched_ratelimit_us =3D 1000;
> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
> =A0/* Various timer handlers. */
> =A0static void s_timer_fn(void *unused);
> =A0static void vcpu_periodic_timer_fn(void *data);
> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h =A0 =A0 =A0Fri Dec 16 18:46:27 2011 +0=
000
> +++ b/xen/include/xen/perfc_defn.h =A0 =A0 =A0Mon Jan 09 05:21:35 2012 -0=
500
> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sch
> =A0PERFCOUNTER(sched_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: runs through=
 scheduler")
> =A0PERFCOUNTER(sched_ctx, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: context swit=
ches")
>
> +PERFCOUNTER(delay_ms, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: delay")
> =A0PERFCOUNTER(vcpu_check, =A0 =A0 =A0 =A0 =A0 =A0 "csched: vcpu_check")
> =A0PERFCOUNTER(schedule, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: schedule")
> =A0PERFCOUNTER(acct_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: acct_run")
> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/sched-if.h
> --- a/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Fri Dec 16 18:46:27 2011 =
+0000
> +++ b/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Mon Jan 09 05:21:35 2012 =
-0500
> @@ -16,6 +16,11 @@ extern struct cpupool *cpupool0;
> =A0/* cpus currently in no cpupool */
> =A0extern cpumask_t cpupool_free_cpus;
>
> +/* Scheduler generic parameters
> + * */
> +extern int sched_ratelimit_us;
> +
> +
> =A0/*
> =A0* In order to allow a scheduler to remap the lock->cpu mapping,
> =A0* 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:05:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkYa4-0002xi-IU; Tue, 10 Jan 2012 10:05:24 +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 1RkYa2-0002x1-3z
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:05:22 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326189914!10281817!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7609 invoked from network); 10 Jan 2012 10:05:15 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 10:05:15 -0000
Received: by ggnh1 with SMTP id h1so2726194ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 02:05:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=VMt6UCufvYLtFm9G69IqSMhSNpnTwMSWhNnrMU+NI3U=;
	b=p5Drs5Q5xjmB/Y0m+QH2tqZHhE3p96w0b5v6k7doNYgB4C+zjWtVF1K4ZZmLrFXSw1
	E31Obp977Lc47mJkypLWVvX4/opd+iiqs03UYsMkmnJHuZfo6f5yvanIc/Pq1RG7Q5Pf
	GJwgL40m/v0qlt0aGdkBCSLbxyVyU54AVh978=
MIME-Version: 1.0
Received: by 10.50.188.166 with SMTP id gb6mr1814686igc.18.1326189912037; Tue,
	10 Jan 2012 02:05:12 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Tue, 10 Jan 2012 02:05:11 -0800 (PST)
In-Reply-To: <fe8d0ca867aa280cbfb3.1326104556@wsm-ep-n0>
References: <fe8d0ca867aa280cbfb3.1326104556@wsm-ep-n0>
Date: Tue, 10 Jan 2012 10:05:11 +0000
X-Google-Sender-Auth: 5DNPHECMLt5OQfR8BBzvkIZZjiQ
Message-ID: <CAFLBxZYJ3oYaXbPoFMYU5omN6rPQcR9zJm_FRJKxxYCKzg5iDQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Hui Lv <hui.lv@intel.com>
Cc: xen-devel@lists.xensource.com, raistlin@linux.it, Ian.Campbell@citrix.com,
	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="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, Jan 9, 2012 at 10:22 AM, Hui Lv <hui.lv@intel.com> wrote:
> Updated the warning sentence for ratelimit_us.
>
> This patch can improve Xen performance:
> 1. Basically, the "delay method" can achieve 11% overall performance boos=
t for SPECvirt than original credit scheduler.
> 2. We have tried 1ms delay and 10ms delay, there is no big difference bet=
ween 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 pro=
duces the benefits. (int sched_ratelimit_us =3D 1000 is the recommended set=
ting)
>
> Signed-off-by: Hui Lv <hui.lv@intel.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Just confirming this:
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Thanks, Hui.
 -George

>
> diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -0500
> @@ -172,6 +172,7 @@ struct csched_private {
> =A0 =A0 uint32_t credit;
> =A0 =A0 int credit_balance;
> =A0 =A0 uint32_t runq_sort;
> + =A0 =A0unsigned ratelimit_us;
> =A0 =A0 /* Period of master and tick in milliseconds */
> =A0 =A0 unsigned tslice_ms, tick_period_us, ticks_per_tslice;
> =A0 =A0 unsigned credits_per_tslice;
> @@ -1297,10 +1298,15 @@ csched_schedule(
> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
> =A0 =A0 struct csched_vcpu *snext;
> =A0 =A0 struct task_slice ret;
> + =A0 =A0s_time_t runtime, tslice;
>
> =A0 =A0 CSCHED_STAT_CRANK(schedule);
> =A0 =A0 CSCHED_VCPU_CHECK(current);
>
> + =A0 =A0runtime =3D now - current->runstate.state_entry_time;
> + =A0 =A0if ( runtime < 0 ) /* Does this ever happen? */
> + =A0 =A0 =A0 =A0runtime =3D 0;
> +
> =A0 =A0 if ( !is_idle_vcpu(scurr->vcpu) )
> =A0 =A0 {
> =A0 =A0 =A0 =A0 /* Update credits of a non-idle VCPU. */
> @@ -1313,6 +1319,35 @@ csched_schedule(
> =A0 =A0 =A0 =A0 scurr->pri =3D CSCHED_PRI_IDLE;
> =A0 =A0 }
>
> + =A0 =A0/* Choices, choices:
> + =A0 =A0 * - If we have a tasklet, we need to run the idle vcpu no matte=
r what.
> + =A0 =A0 * - If sched rate limiting is in effect, and the current vcpu h=
as
> + =A0 =A0 * =A0 run for less than that amount of time, continue the curre=
nt one,
> + =A0 =A0 * =A0 but with a shorter timeslice and return it immediately
> + =A0 =A0 * - Otherwise, chose the one with the highest priority (which m=
ay
> + =A0 =A0 * =A0 be the one currently running)
> + =A0 =A0 * - If the currently running one is TS_OVER, see if there
> + =A0 =A0 * =A0 is a higher priority one waiting on the runqueue of anoth=
er
> + =A0 =A0 * =A0 cpu and steal it.
> + =A0 =A0 */
> +
> + =A0 =A0/* If we have schedule rate limiting enabled, check to see
> + =A0 =A0 * how long we've run for. */
> + =A0 =A0if ( !tasklet_work_scheduled
> + =A0 =A0 =A0 =A0 && prv->ratelimit_us
> + =A0 =A0 =A0 =A0 && vcpu_runnable(current)
> + =A0 =A0 =A0 =A0 && !is_idle_vcpu(current)
> + =A0 =A0 =A0 =A0 && runtime < MICROSECS(prv->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(prv->ratelimit_us);
> + =A0 =A0 =A0 =A0ret.migrated =3D 0;
> + =A0 =A0 =A0 =A0goto out;
> + =A0 =A0}
> + =A0 =A0tslice =3D MILLISECS(prv->tslice_ms);
> +
> =A0 =A0 /*
> =A0 =A0 =A0* Select next runnable local VCPU (ie top of local runq)
> =A0 =A0 =A0*/
> @@ -1367,11 +1402,12 @@ csched_schedule(
> =A0 =A0 if ( !is_idle_vcpu(snext->vcpu) )
> =A0 =A0 =A0 =A0 snext->start_time +=3D now;
>
> +out:
> =A0 =A0 /*
> =A0 =A0 =A0* Return task to run next...
> =A0 =A0 =A0*/
> =A0 =A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ?
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(prv->tslice_ms));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : tslice);
> =A0 =A0 ret.task =3D snext->vcpu;
>
> =A0 =A0 CSCHED_VCPU_CHECK(ret.task);
> @@ -1533,6 +1569,15 @@ csched_init(struct scheduler *ops)
> =A0 =A0 prv->tick_period_us =3D prv->tslice_ms * 1000 / prv->ticks_per_ts=
lice;
> =A0 =A0 prv->credits_per_tslice =3D CSCHED_CREDITS_PER_MSEC * prv->tslice=
_ms;
>
> + =A0 =A0if ( MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tsli=
ce_ms) )
> + =A0 =A0{
> + =A0 =A0 =A0 =A0printk("WARNING: sched_ratelimit_us >"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "sched_credit_tslice_ms is undefined\n"
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Setting ratelimit_us to 1000 * tslice_ms\n=
");
> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D 1000 * prv->tslice_ms;
> + =A0 =A0}
> + =A0 =A0else
> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D sched_ratelimit_us;
> =A0 =A0 return 0;
> =A0}
>
> diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
> --- a/xen/common/schedule.c =A0 =A0 Fri Dec 16 18:46:27 2011 +0000
> +++ b/xen/common/schedule.c =A0 =A0 Mon Jan 09 05:21:35 2012 -0500
> @@ -47,6 +47,11 @@ string_param("sched", opt_sched);
> =A0bool_t sched_smt_power_savings =3D 0;
> =A0boolean_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_tsl=
ice_ms is undefined
> + * */
> +int sched_ratelimit_us =3D 1000;
> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
> =A0/* Various timer handlers. */
> =A0static void s_timer_fn(void *unused);
> =A0static void vcpu_periodic_timer_fn(void *data);
> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/perfc_defn.h
> --- a/xen/include/xen/perfc_defn.h =A0 =A0 =A0Fri Dec 16 18:46:27 2011 +0=
000
> +++ b/xen/include/xen/perfc_defn.h =A0 =A0 =A0Mon Jan 09 05:21:35 2012 -0=
500
> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sch
> =A0PERFCOUNTER(sched_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: runs through=
 scheduler")
> =A0PERFCOUNTER(sched_ctx, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: context swit=
ches")
>
> +PERFCOUNTER(delay_ms, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: delay")
> =A0PERFCOUNTER(vcpu_check, =A0 =A0 =A0 =A0 =A0 =A0 "csched: vcpu_check")
> =A0PERFCOUNTER(schedule, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: schedule")
> =A0PERFCOUNTER(acct_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: acct_run")
> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/sched-if.h
> --- a/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Fri Dec 16 18:46:27 2011 =
+0000
> +++ b/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Mon Jan 09 05:21:35 2012 =
-0500
> @@ -16,6 +16,11 @@ extern struct cpupool *cpupool0;
> =A0/* cpus currently in no cpupool */
> =A0extern cpumask_t cpupool_free_cpus;
>
> +/* Scheduler generic parameters
> + * */
> +extern int sched_ratelimit_us;
> +
> +
> =A0/*
> =A0* In order to allow a scheduler to remap the lock->cpu mapping,
> =A0* 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:07:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkYbj-00039U-8A; Tue, 10 Jan 2012 10:07:07 +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 1RkYbi-00038r-89
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:07:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326190019!8321163!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13475 invoked from network); 10 Jan 2012 10:06:59 -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; 10 Jan 2012 10:06:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 10:06:59 +0000
Message-Id: <4F0C1BCE020000780006B87B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 10:06:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
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 v4 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

>>> On 09.01.12 at 18:58, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> Hello everyone,
> this is the fourth 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.

Out of the first 8 patches, I think all but #6 could go in if you're okay
with them. That would hopefully reduce Stefano's effort a little to
maintain them.

> 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.

All of those that don't touch anything outside xen/*/*arm/ (and don't
depend on #6) could go in imo too. I didn't look too closely to tell
precisely which those are.

What do you think?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:07:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10:07:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkYbj-00039U-8A; Tue, 10 Jan 2012 10:07:07 +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 1RkYbi-00038r-89
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:07:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326190019!8321163!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13475 invoked from network); 10 Jan 2012 10:06:59 -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; 10 Jan 2012 10:06:59 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 10:06:59 +0000
Message-Id: <4F0C1BCE020000780006B87B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 10:06:53 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir@xen.org>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
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 v4 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

>>> On 09.01.12 at 18:58, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
wrote:
> Hello everyone,
> this is the fourth 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.

Out of the first 8 patches, I think all but #6 could go in if you're okay
with them. That would hopefully reduce Stefano's effort a little to
maintain them.

> 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.

All of those that don't touch anything outside xen/*/*arm/ (and don't
depend on #6) could go in imo too. I didn't look too closely to tell
precisely which those are.

What do you think?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 10:59:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10: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 1RkZQG-0004CL-8A; Tue, 10 Jan 2012 10:59:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RkZQF-0004CB-2R
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:59:19 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326193151!10399116!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2NzI2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19861 invoked from network); 10 Jan 2012 10:59:12 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 10:59:12 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:Subject:Content-Type:
	Content-Transfer-Encoding;
	b=F7y+khQBYRNrLW4DeWwdgUqNu/nDmm15C9GWGxx9ED8oOG7vbkW/JOfK
	RR/3XXE7yZgsEFZuQ/f6eVeAOw3sCtZdgxHKCeLMnQx3EaIFYL8vcgTdY
	M7TG0uAQz+8iTn1TeFchO0FPhY/rBKAwojJ1Q2b0Zo2iuRVNS3jBJmuO3
	7QhRUJbB4nvpLJ2FbwQDFOz0XT6IvH07Yd0/KUUiJzNbYO0K2hghi2RFc
	Y5E2Zoyd3dg9SacfL88qwtx1W93NL;
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=1326193152; x=1357729152;
	h=message-id:date:from:mime-version:to:subject:
	content-transfer-encoding;
	bh=z/gNLN1efapGB131iSbjlL2U74fF9etBOsv388RvJOU=;
	b=slzUkvN6wGMNWjin2D6a+eeS73pih4EaOsA0M0sL69xsoEYLqMO0mnuu
	4Oadsv479MqDrnrrHdMGOW+0PeKSBOTCo4BLAsMgwjHyEjIOA3tT4RUO7
	mTBUIuJRAlmAEmVSFEhWohNT6EhjyeO+tB4Kcekjapj/rncGf3oZhB9l7
	rziE7O/UaiTb3zE3Sb7zcsXG9Bpb4VlsuimN9AP6RQgKzxarSrsH3JL9a
	ukm86NOraxqYgdDMCviAYo1C/cK7d;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,485,1320620400"; d="scan'208";a="83030943"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 10 Jan 2012 11:59:12 +0100
X-IronPort-AV: E=Sophos;i="4.71,486,1320620400"; d="scan'208";a="126780660"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 10 Jan 2012 11:59:11 +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 9428975F2FF
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 11:59:11 +0100 (CET)
Message-ID: <4F0C19FF.9030903@ts.fujitsu.com>
Date: Tue, 10 Jan 2012 11:59:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Live Migration of BS2000 DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

we (Fujitsu) are proud to announce the successful live migration of a BS2000
domU (pvHVM). The domU had 32 GB of memory, 8 active vcpus, an active LAN
connection and about 2500 FC-disks online. The domU had an active test load
on 8 disks running and several cpu intensive test jobs.

All BS2000 peripherals are connected via a special pv-driver handling all
devices with just one frontend-backend-pair.

Xen version is 4.0.2, the two machines are both 4-socket Westmere based
servers connected via GB-ethernet.

Live Migration of BS2000 domUs will be officially supported by our next x86
based mainframes.


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 Jan 10 10:59:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 10: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 1RkZQG-0004CL-8A; Tue, 10 Jan 2012 10:59:20 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RkZQF-0004CB-2R
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 10:59:19 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326193151!10399116!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2NzI2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19861 invoked from network); 10 Jan 2012 10:59:12 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 10:59:12 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:Subject:Content-Type:
	Content-Transfer-Encoding;
	b=F7y+khQBYRNrLW4DeWwdgUqNu/nDmm15C9GWGxx9ED8oOG7vbkW/JOfK
	RR/3XXE7yZgsEFZuQ/f6eVeAOw3sCtZdgxHKCeLMnQx3EaIFYL8vcgTdY
	M7TG0uAQz+8iTn1TeFchO0FPhY/rBKAwojJ1Q2b0Zo2iuRVNS3jBJmuO3
	7QhRUJbB4nvpLJ2FbwQDFOz0XT6IvH07Yd0/KUUiJzNbYO0K2hghi2RFc
	Y5E2Zoyd3dg9SacfL88qwtx1W93NL;
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=1326193152; x=1357729152;
	h=message-id:date:from:mime-version:to:subject:
	content-transfer-encoding;
	bh=z/gNLN1efapGB131iSbjlL2U74fF9etBOsv388RvJOU=;
	b=slzUkvN6wGMNWjin2D6a+eeS73pih4EaOsA0M0sL69xsoEYLqMO0mnuu
	4Oadsv479MqDrnrrHdMGOW+0PeKSBOTCo4BLAsMgwjHyEjIOA3tT4RUO7
	mTBUIuJRAlmAEmVSFEhWohNT6EhjyeO+tB4Kcekjapj/rncGf3oZhB9l7
	rziE7O/UaiTb3zE3Sb7zcsXG9Bpb4VlsuimN9AP6RQgKzxarSrsH3JL9a
	ukm86NOraxqYgdDMCviAYo1C/cK7d;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,485,1320620400"; d="scan'208";a="83030943"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 10 Jan 2012 11:59:12 +0100
X-IronPort-AV: E=Sophos;i="4.71,486,1320620400"; d="scan'208";a="126780660"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 10 Jan 2012 11:59:11 +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 9428975F2FF
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 11:59:11 +0100 (CET)
Message-ID: <4F0C19FF.9030903@ts.fujitsu.com>
Date: Tue, 10 Jan 2012 11:59:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Live Migration of BS2000 DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

we (Fujitsu) are proud to announce the successful live migration of a BS2000
domU (pvHVM). The domU had 32 GB of memory, 8 active vcpus, an active LAN
connection and about 2500 FC-disks online. The domU had an active test load
on 8 disks running and several cpu intensive test jobs.

All BS2000 peripherals are connected via a special pv-driver handling all
devices with just one frontend-backend-pair.

Xen version is 4.0.2, the two machines are both 4-socket Westmere based
servers connected via GB-ethernet.

Live Migration of BS2000 domUs will be officially supported by our next x86
based mainframes.


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 Jan 10 11:13:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11: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 1RkZdk-0004Tn-L1; Tue, 10 Jan 2012 11:13: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 1RkZdj-0004Ti-D5
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:13:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326193866!47907475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24364 invoked from network); 10 Jan 2012 11:11:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:11:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:13: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, 10 Jan 2012 11:13:14 +0000
Date: Tue, 10 Jan 2012 11:13:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326189863.17210.125.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201101112330.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326189863.17210.125.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>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Tue, 10 Jan 2012, Ian Campbell wrote:
> On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
> wrote:
> > 
> > +static unsigned int gic_irq_startup(struct irq_desc *desc)
> > +{
> > +    uint32_t enabler;
> > +       int irq = desc->irq;
> > + 
> 
> Some hard tabs appear to have snuck in at least a couple of times in
> this file and elsewhere:
> $ find xen/arch/arm/ xen/include/asm-arm/ -name \*.[ch] | xargs grep '     ' -l
> xen/arch/arm/smp.c
> xen/arch/arm/lib/bitops.h
> xen/arch/arm/irq.c
> xen/arch/arm/gic.c
> xen/arch/arm/vtimer.c
> xen/arch/arm/setup.c
> xen/arch/arm/domain.c
> xen/include/asm-arm/numa.h
> xen/include/asm-arm/grant_table.h
> xen/include/asm-arm/div64.h
> 
> I think hard tabs are OK in code from Linux (e.g.
> xen/arch/arm/lib/bitops.h) and in .S files but not elsewhere.
 
Agreed, evidently my smart vim runes are not smart enough.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:13:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11: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 1RkZdk-0004Tn-L1; Tue, 10 Jan 2012 11:13: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 1RkZdj-0004Ti-D5
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:13:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326193866!47907475!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24364 invoked from network); 10 Jan 2012 11:11:06 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:11:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917465"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:13: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, 10 Jan 2012 11:13:14 +0000
Date: Tue, 10 Jan 2012 11:13:20 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326189863.17210.125.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201101112330.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-14-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326189863.17210.125.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>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Tue, 10 Jan 2012, Ian Campbell wrote:
> On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
> wrote:
> > 
> > +static unsigned int gic_irq_startup(struct irq_desc *desc)
> > +{
> > +    uint32_t enabler;
> > +       int irq = desc->irq;
> > + 
> 
> Some hard tabs appear to have snuck in at least a couple of times in
> this file and elsewhere:
> $ find xen/arch/arm/ xen/include/asm-arm/ -name \*.[ch] | xargs grep '     ' -l
> xen/arch/arm/smp.c
> xen/arch/arm/lib/bitops.h
> xen/arch/arm/irq.c
> xen/arch/arm/gic.c
> xen/arch/arm/vtimer.c
> xen/arch/arm/setup.c
> xen/arch/arm/domain.c
> xen/include/asm-arm/numa.h
> xen/include/asm-arm/grant_table.h
> xen/include/asm-arm/div64.h
> 
> I think hard tabs are OK in code from Linux (e.g.
> xen/arch/arm/lib/bitops.h) and in .S files but not elsewhere.
 
Agreed, evidently my smart vim runes are not smart enough.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:18:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkZi9-0004b5-Be; Tue, 10 Jan 2012 11:17:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkZi7-0004al-6P
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:17:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326194260!8484198!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10132 invoked from network); 10 Jan 2012 11:17:41 -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;
	10 Jan 2012 11:17:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:17:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 11:17:40 +0000
Date: Tue, 10 Jan 2012 11:17:46 +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: <4F0B3132.5080601@citrix.com>
Message-ID: <alpine.DEB.2.00.1201101114300.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-23-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0B3132.5080601@citrix.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>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 9 Jan 2012, David Vrabel wrote:
> On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> > 
> > +static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> > +{
> [...]
> > +    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;
> 
> This needs to return 1 or recent kernels will crash when they try and
> read these registers.

Not just a comment but a patch! Wonderful!
I'll merge it with this patch, thanks!


> >From 8c2377a9b4a10cba57fba9f8a19177ac73339d78 Mon Sep 17 00:00:00 2001
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 9 Jan 2012 15:17:22 +0000
> Subject: [PATCH] ARM: allow guest to read GICD_ICFGRn registers
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/arch/arm/vgic.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 26eae55..584e682 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -266,7 +266,7 @@ static int vgic_distr_mmio_read(struct vcpu *v,
> mmio_info_t *info)
>          vgic_lock_rank(v, rank);
>          *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
>          vgic_unlock_rank(v, rank);
> -        return 0;
> +        return 1;
> 
>      case GICD_NSACR ... GICD_NSACRN:
>          /* We do not implement securty extensions for guests, read zero */
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:18:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11:18:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkZi9-0004b5-Be; Tue, 10 Jan 2012 11:17:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RkZi7-0004al-6P
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:17:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326194260!8484198!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10132 invoked from network); 10 Jan 2012 11:17:41 -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;
	10 Jan 2012 11:17:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:17:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 11:17:40 +0000
Date: Tue, 10 Jan 2012 11:17:46 +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: <4F0B3132.5080601@citrix.com>
Message-ID: <alpine.DEB.2.00.1201101114300.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-23-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0B3132.5080601@citrix.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>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 9 Jan 2012, David Vrabel wrote:
> On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> > 
> > +static int vgic_distr_mmio_read(struct vcpu *v, mmio_info_t *info)
> > +{
> [...]
> > +    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;
> 
> This needs to return 1 or recent kernels will crash when they try and
> read these registers.

Not just a comment but a patch! Wonderful!
I'll merge it with this patch, thanks!


> >From 8c2377a9b4a10cba57fba9f8a19177ac73339d78 Mon Sep 17 00:00:00 2001
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 9 Jan 2012 15:17:22 +0000
> Subject: [PATCH] ARM: allow guest to read GICD_ICFGRn registers
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/arch/arm/vgic.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 26eae55..584e682 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -266,7 +266,7 @@ static int vgic_distr_mmio_read(struct vcpu *v,
> mmio_info_t *info)
>          vgic_lock_rank(v, rank);
>          *r = rank->icfg[REG_RANK_INDEX(2, gicd_reg - GICD_ICFGR)];
>          vgic_unlock_rank(v, rank);
> -        return 0;
> +        return 1;
> 
>      case GICD_NSACR ... GICD_NSACRN:
>          /* We do not implement securty extensions for guests, read zero */
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:19:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11: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 1RkZjp-0004gk-SV; Tue, 10 Jan 2012 11:19: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 1RkZjo-0004gO-PO
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:19:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326194366!10285982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17081 invoked from network); 10 Jan 2012 11:19:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:18: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; Tue, 10 Jan 2012 11:18:24 +0000
Date: Tue, 10 Jan 2012 11:18:30 +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: <4F0B3218.5070101@citrix.com>
Message-ID: <alpine.DEB.2.00.1201101118160.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-13-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0B3218.5070101@citrix.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>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 9 Jan 2012, David Vrabel wrote:
> On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> > 
> > +int construct_dom0(struct domain *d)
> > +{
> [...]
> > +    printk("Routing peripheral interrupts to guest\n");
> > +    /* TODO Get from device tree */
> 
> Can you route interrupt 34 (timer0) to dom0 as well?  Current mainline
> kernels are using this timer.
> 

Good idea, it will be in the next version of the series

> 
> >From 88148e85b2d8d9bf60564d4b5eb2ac73d8389fa5 Mon Sep 17 00:00:00 2001
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 9 Jan 2012 15:21:37 +0000
> Subject: [PATCH] ARM: route timer0 interrupt to dom0
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c36b888..cbbc0b9 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -108,6 +108,7 @@ int construct_dom0(struct domain *d)
> 
>      printk("Routing peripheral interrupts to guest\n");
>      /* TODO Get from device tree */
> +    gic_route_irq_to_guest(d, 34, "timer0");
>      /*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");
> -- 
> 1.7.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 Jan 10 11:19:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11: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 1RkZjp-0004gk-SV; Tue, 10 Jan 2012 11:19: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 1RkZjo-0004gO-PO
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:19:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326194366!10285982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17081 invoked from network); 10 Jan 2012 11:19:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:19:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917643"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:18: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; Tue, 10 Jan 2012 11:18:24 +0000
Date: Tue, 10 Jan 2012 11:18:30 +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: <4F0B3218.5070101@citrix.com>
Message-ID: <alpine.DEB.2.00.1201101118160.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-13-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0B3218.5070101@citrix.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>, "JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 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

On Mon, 9 Jan 2012, David Vrabel wrote:
> On 09/01/12 17:59, stefano.stabellini@eu.citrix.com wrote:
> > 
> > +int construct_dom0(struct domain *d)
> > +{
> [...]
> > +    printk("Routing peripheral interrupts to guest\n");
> > +    /* TODO Get from device tree */
> 
> Can you route interrupt 34 (timer0) to dom0 as well?  Current mainline
> kernels are using this timer.
> 

Good idea, it will be in the next version of the series

> 
> >From 88148e85b2d8d9bf60564d4b5eb2ac73d8389fa5 Mon Sep 17 00:00:00 2001
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 9 Jan 2012 15:21:37 +0000
> Subject: [PATCH] ARM: route timer0 interrupt to dom0
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> ---
>  xen/arch/arm/domain_build.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c36b888..cbbc0b9 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -108,6 +108,7 @@ int construct_dom0(struct domain *d)
> 
>      printk("Routing peripheral interrupts to guest\n");
>      /* TODO Get from device tree */
> +    gic_route_irq_to_guest(d, 34, "timer0");
>      /*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");
> -- 
> 1.7.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 Jan 10 11:23:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11:23:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkZmw-0004r4-Fp; Tue, 10 Jan 2012 11:22: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 1RkZmu-0004qs-IJ
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:22:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326194558!10403814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29925 invoked from network); 10 Jan 2012 11:22:38 -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;
	10 Jan 2012 11:22:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:22:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 11:22:38 +0000
Date: Tue, 10 Jan 2012 11:22:44 +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: <1326184323.29084.80.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1201101118550.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326184323.29084.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>,
	"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 v4 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

On Tue, 10 Jan 2012, Ian Campbell wrote:
> On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
> wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Bit manipulation, division and memcpy & friends implementations for the
> > ARM architecture, shamelessly taken from Linux.
> 
> When I initially imported these I did so with the minimal changes
> possible to integrate the in the Xen tree so as to aid future merges of
> this code from Linux.
> 
> This meant there was quite a lot of ifdef'd code (in particular for
> previous ARM architectures via __LINUX_ARM_ARCH__) but I think that is a
> price worth paying to keep these files somewhat in sync. I used a pretty
> ugly "#if 1 /* __LINUX_ARM_ARCH__ >= 5 */" construct to minimise changes
> but perhaps it would be better to simply define __LINUX_ARM_ARCH__
> appropriately within the lib subdirectory?
> 

I am not a great fan of manually sync'ed source files, however I
understand your concerns. At that point we might have to move
__aeabi_uldivmod and __aeabi_ldivmod to a different location, if we
really want to keep these files identical.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:23:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11:23:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkZmw-0004r4-Fp; Tue, 10 Jan 2012 11:22: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 1RkZmu-0004qs-IJ
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:22:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326194558!10403814!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29925 invoked from network); 10 Jan 2012 11:22:38 -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;
	10 Jan 2012 11:22:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917727"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:22:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 11:22:38 +0000
Date: Tue, 10 Jan 2012 11:22:44 +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: <1326184323.29084.80.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1201101118550.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326184323.29084.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>,
	"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 v4 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

On Tue, 10 Jan 2012, Ian Campbell wrote:
> On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
> wrote:
> > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 
> > Bit manipulation, division and memcpy & friends implementations for the
> > ARM architecture, shamelessly taken from Linux.
> 
> When I initially imported these I did so with the minimal changes
> possible to integrate the in the Xen tree so as to aid future merges of
> this code from Linux.
> 
> This meant there was quite a lot of ifdef'd code (in particular for
> previous ARM architectures via __LINUX_ARM_ARCH__) but I think that is a
> price worth paying to keep these files somewhat in sync. I used a pretty
> ugly "#if 1 /* __LINUX_ARM_ARCH__ >= 5 */" construct to minimise changes
> but perhaps it would be better to simply define __LINUX_ARM_ARCH__
> appropriately within the lib subdirectory?
> 

I am not a great fan of manually sync'ed source files, however I
understand your concerns. At that point we might have to move
__aeabi_uldivmod and __aeabi_ldivmod to a different location, if we
really want to keep these files identical.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:30:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11: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 1RkZtw-00055E-DH; Tue, 10 Jan 2012 11:30: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 1RkZtu-000559-Lb
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:29:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326194958!55320210!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30392 invoked from network); 10 Jan 2012 11:29:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:29:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:29: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, 10 Jan 2012 11:29:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 10 Jan 2012 11:29:56 +0000
In-Reply-To: <alpine.DEB.2.00.1201101118550.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326184323.29084.80.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201101118550.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326194997.17210.128.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>
Subject: Re: [Xen-devel] [PATCH v4 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

On Tue, 2012-01-10 at 11:22 +0000, Stefano Stabellini wrote:
> On Tue, 10 Jan 2012, Ian Campbell wrote:
> > On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
> > wrote:
> > > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > Bit manipulation, division and memcpy & friends implementations for the
> > > ARM architecture, shamelessly taken from Linux.
> > 
> > When I initially imported these I did so with the minimal changes
> > possible to integrate the in the Xen tree so as to aid future merges of
> > this code from Linux.
> > 
> > This meant there was quite a lot of ifdef'd code (in particular for
> > previous ARM architectures via __LINUX_ARM_ARCH__) but I think that is a
> > price worth paying to keep these files somewhat in sync. I used a pretty
> > ugly "#if 1 /* __LINUX_ARM_ARCH__ >= 5 */" construct to minimise changes
> > but perhaps it would be better to simply define __LINUX_ARM_ARCH__
> > appropriately within the lib subdirectory?
> > 
> 
> I am not a great fan of manually sync'ed source files, however I
> understand your concerns. At that point we might have to move
> __aeabi_uldivmod and __aeabi_ldivmod to a different location, if we
> really want to keep these files identical.

Lets just agree that necessary changes are ok. I don't think they need
to be identical, just not unnecessarily changed since that makes
resyncing harder for no gain.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:30:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11: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 1RkZtw-00055E-DH; Tue, 10 Jan 2012 11:30: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 1RkZtu-000559-Lb
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:29:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326194958!55320210!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30392 invoked from network); 10 Jan 2012 11:29:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:29:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320624000"; 
   d="scan'208";a="9917944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:29: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, 10 Jan 2012 11:29:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 10 Jan 2012 11:29:56 +0000
In-Reply-To: <alpine.DEB.2.00.1201101118550.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-10-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326184323.29084.80.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201101118550.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326194997.17210.128.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>
Subject: Re: [Xen-devel] [PATCH v4 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

On Tue, 2012-01-10 at 11:22 +0000, Stefano Stabellini wrote:
> On Tue, 10 Jan 2012, Ian Campbell wrote:
> > On Mon, 2012-01-09 at 17:59 +0000, stefano.stabellini@eu.citrix.com
> > wrote:
> > > From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > 
> > > Bit manipulation, division and memcpy & friends implementations for the
> > > ARM architecture, shamelessly taken from Linux.
> > 
> > When I initially imported these I did so with the minimal changes
> > possible to integrate the in the Xen tree so as to aid future merges of
> > this code from Linux.
> > 
> > This meant there was quite a lot of ifdef'd code (in particular for
> > previous ARM architectures via __LINUX_ARM_ARCH__) but I think that is a
> > price worth paying to keep these files somewhat in sync. I used a pretty
> > ugly "#if 1 /* __LINUX_ARM_ARCH__ >= 5 */" construct to minimise changes
> > but perhaps it would be better to simply define __LINUX_ARM_ARCH__
> > appropriately within the lib subdirectory?
> > 
> 
> I am not a great fan of manually sync'ed source files, however I
> understand your concerns. At that point we might have to move
> __aeabi_uldivmod and __aeabi_ldivmod to a different location, if we
> really want to keep these files identical.

Lets just agree that necessary changes are ok. I don't think they need
to be identical, just not unnecessarily changed since that makes
resyncing harder for no gain.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:51:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkaEu-0005H0-Bc; Tue, 10 Jan 2012 11:51:40 +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 1RkaEs-0005Gv-Oy
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:51:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326196276!61826028!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTU2NzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2632 invoked from network); 10 Jan 2012 11:51:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320642000"; d="scan'208";a="20717009"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 06:51:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 06:51:35 -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 q0ABpXwD004801;
	Tue, 10 Jan 2012 03:51:34 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120109192119.GB10630@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
Date: Tue, 10 Jan 2012 12:02:16 +0000
Message-ID: <1326196936.5154.39.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 19:21 +0000, Olaf Hering wrote:
> So there is that maxmem= setting to let the guest OS configure itself
> for a given amount of pseudo-physical memory. Then there is a way to cut
> down the guest OS memory usage, both with balloon driver in guest and
> later with PoD.
> Isnt paging a better (or: just different) way to control the memory
> usage of a guest OS (It costs diskspace in dom0)?

On the contrary, hypervisor swapping is definitely *much worse* than
using a balloon driver.  The balloon driver was an innovation developed
specifically to avoid hypervisor swapping if at all possible[1].  We
need hypervisor swapping as a back-stop for situations where the balloon
driver is non-existent, or can't function immediately for some reason
(e.g., we've been using page-sharing to do memory overcommit and
suddenly have a bunch of pages un-shared); but it should always be a
last resort, and would ideally be mitigated by the balloon driver as
soon as possible.

[1] http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf

> If a guest OS is configured with maxmem=4096, but then restricted with
> memory=3072 in the next line, why is maxmem= there in the first place?

Because for HVM guests at least, the guest OS will never recognize more
memory than was reported in the e820 map at boot.  So if you boot with
maxmem=3072, the VM will *never* be able to see more then 3072 megabytes
of RAM.  If you want to start a VM with 3072 MiB, but want the
flexibility of allowing the VM to use up to 4096 MiB at some point in
the future, you need to have 4096MiB in the e820 map.

> Would it clearer to say: The guest OS has a certain workload which
> requires 3072MB. But maybe at some point the guest needs the full
> 4096MB, then it can access all of it at the cost of some IO due to
> swapping in dom0.

The very best thing is if the guest does its own swapping.  If its
working set is 4096MiB, but its available memory is only 3072MiB, it's
better to tell the guest it only has 3072MiB to work with, so it can do
the swapping optimally.

> I think the balloon driver in the guest is not really needed anymore, it
> could just be there and do nothing. IF there is physical memory to
> release to the host, the pager can do it on behalf of the balloon
> driver.

Hopefully it's clear that I disagree with this completely.

> What if the config format is like this:
> 
> Do things as they were done until now (PoD + balloon driver):
>   memory=3072
>   maxmem=4096
>   paging=0 (or not specified at all)
> 
> Do things with pager instead of balloon driver and/or PoD:
>   memory=3072
>   maxmem=4096
>   paging=1, or xenpaging=1
>   xenpaging_extra=[ '-f', '/path/to/pagefile_guestname' ] (optional)

Except that this makes paging and ballooning mutually exclusive.  What
we want is to make them work together -- to have paging as a back-up
when ballooning fails (or isn't fast enough).

We'd also like to experiment with having a special-case of paging
replace PoD; in that case, we need to start with this special-case
paging and then transition into ballooning.

It may be that we don't have time to make them work together before the
4.2 release; in that case, we may need to make them mutually exclusive
for that release, to be fixed up in 4.3.  But if we can make them work
together by 4.2, that would be the best; and in any case, we need to
make sure we're planning for them to work together, and minimize the
interface changes when we do.

> The builder could create some sort PoD for a paged guest so
> that during startup only the amount of memory= needs to be allocated.
> This needs to be implemented, right now a starting guest needs the full
> amount of memory until the pager starts to page-out pages.

Yes, the builder needs to be able to start a guest with pages pre-paged
out, for the same reason we introduced PoD: that is, if you page a guest
from 4096MiB down to 3072MiB, and then reboot the guest, you may only
have 3072MiB available.  So if you want maxmem=4096 still, you need to
start with some pages "pre-paged" out.  We need that mechanism for
robustness anyway; we can then experiment with using it to replace PoD.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:51:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkaEu-0005H0-Bc; Tue, 10 Jan 2012 11:51:40 +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 1RkaEs-0005Gv-Oy
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:51:38 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326196276!61826028!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTU2NzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2632 invoked from network); 10 Jan 2012 11:51:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:51:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,486,1320642000"; d="scan'208";a="20717009"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 06:51:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 06:51:35 -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 q0ABpXwD004801;
	Tue, 10 Jan 2012 03:51:34 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120109192119.GB10630@aepfle.de>
References: <patchbomb.1320245136@probook.site>
	<ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
Date: Tue, 10 Jan 2012 12:02:16 +0000
Message-ID: <1326196936.5154.39.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 19:21 +0000, Olaf Hering wrote:
> So there is that maxmem= setting to let the guest OS configure itself
> for a given amount of pseudo-physical memory. Then there is a way to cut
> down the guest OS memory usage, both with balloon driver in guest and
> later with PoD.
> Isnt paging a better (or: just different) way to control the memory
> usage of a guest OS (It costs diskspace in dom0)?

On the contrary, hypervisor swapping is definitely *much worse* than
using a balloon driver.  The balloon driver was an innovation developed
specifically to avoid hypervisor swapping if at all possible[1].  We
need hypervisor swapping as a back-stop for situations where the balloon
driver is non-existent, or can't function immediately for some reason
(e.g., we've been using page-sharing to do memory overcommit and
suddenly have a bunch of pages un-shared); but it should always be a
last resort, and would ideally be mitigated by the balloon driver as
soon as possible.

[1] http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf

> If a guest OS is configured with maxmem=4096, but then restricted with
> memory=3072 in the next line, why is maxmem= there in the first place?

Because for HVM guests at least, the guest OS will never recognize more
memory than was reported in the e820 map at boot.  So if you boot with
maxmem=3072, the VM will *never* be able to see more then 3072 megabytes
of RAM.  If you want to start a VM with 3072 MiB, but want the
flexibility of allowing the VM to use up to 4096 MiB at some point in
the future, you need to have 4096MiB in the e820 map.

> Would it clearer to say: The guest OS has a certain workload which
> requires 3072MB. But maybe at some point the guest needs the full
> 4096MB, then it can access all of it at the cost of some IO due to
> swapping in dom0.

The very best thing is if the guest does its own swapping.  If its
working set is 4096MiB, but its available memory is only 3072MiB, it's
better to tell the guest it only has 3072MiB to work with, so it can do
the swapping optimally.

> I think the balloon driver in the guest is not really needed anymore, it
> could just be there and do nothing. IF there is physical memory to
> release to the host, the pager can do it on behalf of the balloon
> driver.

Hopefully it's clear that I disagree with this completely.

> What if the config format is like this:
> 
> Do things as they were done until now (PoD + balloon driver):
>   memory=3072
>   maxmem=4096
>   paging=0 (or not specified at all)
> 
> Do things with pager instead of balloon driver and/or PoD:
>   memory=3072
>   maxmem=4096
>   paging=1, or xenpaging=1
>   xenpaging_extra=[ '-f', '/path/to/pagefile_guestname' ] (optional)

Except that this makes paging and ballooning mutually exclusive.  What
we want is to make them work together -- to have paging as a back-up
when ballooning fails (or isn't fast enough).

We'd also like to experiment with having a special-case of paging
replace PoD; in that case, we need to start with this special-case
paging and then transition into ballooning.

It may be that we don't have time to make them work together before the
4.2 release; in that case, we may need to make them mutually exclusive
for that release, to be fixed up in 4.3.  But if we can make them work
together by 4.2, that would be the best; and in any case, we need to
make sure we're planning for them to work together, and minimize the
interface changes when we do.

> The builder could create some sort PoD for a paged guest so
> that during startup only the amount of memory= needs to be allocated.
> This needs to be implemented, right now a starting guest needs the full
> amount of memory until the pager starts to page-out pages.

Yes, the builder needs to be able to start a guest with pages pre-paged
out, for the same reason we introduced PoD: that is, if you page a guest
from 4096MiB down to 3072MiB, and then reboot the guest, you may only
have 3072MiB available.  So if you want maxmem=4096 still, you need to
start with some pages "pre-paged" out.  We need that mechanism for
robustness anyway; we can then experiment with using it to replace PoD.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:54:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11: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 1RkaHi-0005Of-3d; Tue, 10 Jan 2012 11:54: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 1RkaHg-0005OS-EA
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:54:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326196464!8521004!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_12_24,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9876 invoked from network); 10 Jan 2012 11:54:24 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:54:24 -0000
Received: by wico1 with SMTP id o1so9196774wic.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 03:54:24 -0800 (PST)
DKIM-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=kW/WcV2BoRJq6RtQ6Jy+YjEqLwllDBGqVod8j+WON7w=;
	b=u+Xbo3yeyUshjvdid3ZSnrVKfzetHWTJXLH6dACjvjwpnBvzbiA3+Q0YjVk5zDdw+z
	y2XtipUnKB+rDxoqM+z6xdoVxp5m1g7pMJjrRhI+V3/9LEyKHfQGcmV/cyA77JVmSvDx
	ft//DVvNG38NpSWc/38Ad9PvD+fpQ2jhaHY0A=
Received: by 10.180.94.102 with SMTP id db6mr3255081wib.0.1326196463874;
	Tue, 10 Jan 2012 03:54:23 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id em13sm1161142wid.7.2012.01.10.03.54.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 10 Jan 2012 03:54:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7d90cbdca2c26ba817f10a404737b25e85d56a7f
Message-Id: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 09 Jan 2012 21:37:07 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI2MTQxMjMyIC0zNjAwCiMgTm9kZSBJRCA3ZDkwY2JkY2Ey
YzI2YmE4MTdmMTBhNDA0NzM3YjI1ZTg1ZDU2YTdmCiMgUGFyZW50ICA0MDg2ZTQ4MTE1NDdkZGZm
YjlhNTNmYmYyZWZiNmMyZmE0MzZiNzBhCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwKY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KCkF1dG9jb25mLm1rIGlzIGluY2x1
ZGVkIGJ5IENvbmZpZy5taywgYW5kIGNvbnRhaW5zIG1vc3Qgb2YgdGhlCm9wdGlvbnMgcHJldmlv
dXNseSBkZWZpbmVkIGluIC5jb25maWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwpwYXJh
bWV0ZXJzIG9yIGRlZmluaW5nIGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBj
b25maWd1cmUKc2NyaXB0LgoKY29uZmlnLmggaXMgc3RpbGwgbm90IHVzZWQgYW55d2hlcmUsIGFu
ZCBpcyBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQgYnkKYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1p
Z2ggY2hhbmdlIHdoZW4gd2Ugc3RhcnQgdG8gaW5jbHVkZSB0aGlzCmZpbGUuCgpKdXN0IGEgZmly
c3QgcmVsZWFzZSwgYW5kIHNpbmNlIElpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlwdCBJIGd1
ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNlIHJl
dmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjE6CgogKiBNb3ZlZCBhdXRvY29uZiBz
dHVmZiBpbnNpZGUgdG9vbHMgZm9sZGVyLgoKICogQWRkIE1ha2VmaWxlIHJ1bGVzIGZvciBjbGVh
bmluZy4KCiAqIFJlbW92ZWQgQXV0b21ha2UgZGVwZW5kZW5jeS4KCiAqIENyZWF0ZSBhdXRvZ2Vu
LnNoIHRvIGF1dG9tYXRpY2FsbHkgY3JlYXRlIGNvbmZpZ3VyZSBzY3JpcHQgd2hlbgogICBidWls
ZGluZyBmcm9tIHNvdXJjZSByZXBvc2l0b3J5LgoKICogQ2FjaGVkIHZhbHVlcyBvZiBvcHRpb25z
IHBhc3NlZCBmcm9tIGNvbW1hbmQgbGluZS4KCiAqIEFkZCBuZWNlc3NhcnkgaWdub3JlcyB0byAu
aGdpZ25vcmUuCgogKiBBZGRlZCBBdXRvY29uZiB0byB0aGUgbGlzdCBvZiBkZXBlbmRlbmNpZXMu
CgogKiBDaGFuZ2VkIGh5cGVuIHRvIHVuZGVyc2NvcmUgaW4gWE1MMiBhbmQgQ1VSTCB2YXJpYWJs
ZSBuYW1lcy4KCiAqIEFkZGVkIHNjcmlwdCB0byBnZXQgdmVyc2lvbiBmcm9tIHhlbi9NYWtlZmls
ZS4KCiAqIFNldCBPY2FtbCB0b29scyB0byBvcHRpb25hbC4KCiAqIEFkZGVkIHByb2NlZGVuY2Ug
b2YgbTQvb2NhbWwubTQuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBh
dUBlbnRlbC51cGMuZWR1PgoKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIC5o
Z2lnbm9yZQotLS0gYS8uaGdpZ25vcmUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisr
KyBiLy5oZ2lnbm9yZQlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTIyLDYgKzIy
LDcgQEAKIF5bXi9dKlwuYnoyJAogXlwuY29uZmlnJAogXlwucGMKK15jb25maWd1cmUkCiAoXnwv
KSh0YWdzfFRBR1MpJAogXmJ1aWxkLS4qJAogXmRpc3QvLiokCkBAIC0zMDgsNiArMzA5LDEwIEBA
CiBedG9vbHMvb2NhbWwvbGlicy94bC94ZW5saWdodFwubWwkCiBedG9vbHMvb2NhbWwvbGlicy94
bC94ZW5saWdodFwubWxpJAogXnRvb2xzL29jYW1sL3hlbnN0b3JlZC9veGVuc3RvcmVkJAorXnRv
b2xzL2F1dG9tNHRlLmNhY2hlJAorXnRvb2xzL2NvbmZpZy4qJAorXnRvb2xzL2NvbmZpZ3VyZSQK
K15jb25maWcvVG9vbHMubWskCiBeeGVuL1wuYmFubmVyLiokCiBeeGVuL0JMT0ckCiBeeGVuL1N5
c3RlbS5tYXAkCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiBDb25maWcubWsK
LS0tIGEvQ29uZmlnLm1rCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi9Db25m
aWcubWsJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAwCkBAIC03MCw5ICs3MCw2IEBAIEVY
VFJBX0lOQ0xVREVTICs9ICQoRVhUUkFfUFJFRklYKS9pbmNsdWQKIEVYVFJBX0xJQiArPSAkKEVY
VFJBX1BSRUZJWCkvJChMSUJMRUFGRElSKQogZW5kaWYKIAotQklTT04JPz0gYmlzb24KLUZMRVgJ
Pz0gZmxleAotCiBQWVRIT04gICAgICA/PSBweXRob24KIFBZVEhPTl9QUkVGSVhfQVJHID89IC0t
cHJlZml4PSIkKFBSRUZJWCkiCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJWCBjb250
YWlucyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCkBAIC0xNzUsMjIgKzE3Miw5
IEBAIENGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChQUkVQRU5EX0lOQ0xVREUKIEFQUEVORF9MREZM
QUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRfQ0ZMQUdT
ICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9JTkNMVURFUyksIC1JJChpKSkKIAotQ0hFQ0tfTElC
ID0gJChFWFRSQV9MSUIpICQoUFJFUEVORF9MSUIpICQoQVBQRU5EX0xJQikKLUNIRUNLX0lOQ0xV
REVTID0gJChFWFRSQV9JTkNMVURFUykgJChQUkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVORF9JTkNM
VURFUykKLQogRU1CRURERURfRVhUUkFfQ0ZMQUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNrLXByb3Rl
Y3RvciAtZm5vLXN0YWNrLXByb3RlY3Rvci1hbGwKIEVNQkVEREVEX0VYVFJBX0NGTEFHUyArPSAt
Zm5vLWV4Y2VwdGlvbnMKIAotIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVs
dCwgRmxhc2spLgotWFNNX0VOQUJMRSA/PSBuCi1GTEFTS19FTkFCTEUgPz0gJChYU01fRU5BQkxF
KQotCi0jIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3duIHBy
b3RvY29sPwotIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3aGVu
IGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCi0jIG1heSBibG9jayBpdCkuIFdlIG1ha2UgaXQg
dGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRvd25sb2FkcwotIyBmYWls
IG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91ciBlbnZpcm9ubWVudC4K
LUdJVF9IVFRQID89IG4KLQogWEVOX0VYVEZJTEVTX1VSTD1odHRwOi8veGVuYml0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1leHRmaWxlcwogIyBBbGwgdGhlIGZpbGVzIGF0IHRoYXQgbG9jYXRpb24gd2Vy
ZSBkb3dubG9hZGVkIGZyb20gZWxzZXdoZXJlIG9uCiAjIHRoZSBpbnRlcm5ldC4gIFRoZSBvcmln
aW5hbCBkb3dubG9hZCBVUkwgaXMgcHJlc2VydmVkIGFzIGEgY29tbWVudApAQCAtMjIyLDE3ICsy
MDYsMyBAQCBRRU1VX1RBRyA/PSBiYjM2ZDYzMmU0Y2FiZjQ3ODgyYWRmZjA3YTQ1CiAjIE5vdGUg
dGhhdCB1c2luZyBTZWFCSU9TIHJlcXVpcmVzIHRoZSB1c2UgdGhlIHVwc3RyZWFtIHFlbXUgYXMg
dGhlCiAjIGRldmljZSBtb2RlbC4KIFNFQUJJT1NfRElSID89IAotCi0jIE9wdGlvbmFsIGNvbXBv
bmVudHMKLVhFTlNUQVRfWEVOVE9QICAgICA/PSB5Ci1WVFBNX1RPT0xTICAgICAgICAgPz0gbgot
TElCWEVOQVBJX0JJTkRJTkdTID89IG4KLVBZVEhPTl9UT09MUyAgICAgICA/PSB5Ci1PQ0FNTF9U
T09MUyAgICAgICAgPz0geQotQ09ORklHX01JTklURVJNICAgID89IG4KLUNPTkZJR19MT01PVU5U
ICAgICA/PSBuCi1DT05GSUdfU1lTVEVNX0xJQkFJTyA/PSB5Ci0KLWlmZXEgKCQoT0NBTUxfVE9P
TFMpLHkpCi1PQ0FNTF9UT09MUyA6PSAkKHNoZWxsIG9jYW1sb3B0IC12ID4gL2Rldi9udWxsIDI+
JjEgJiYgZWNobyAieSIgfHwgZWNobyAibiIpCi1lbmRpZgpkaWZmIC1yIDQwODZlNDgxMTU0NyAt
ciA3ZDkwY2JkY2EyYzIgTWFrZWZpbGUKLS0tIGEvTWFrZWZpbGUJVGh1IEphbiAwNSAxNzoyNToy
MyAyMDEyICswMDAwCisrKyBiL01ha2VmaWxlCU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEw
MApAQCAtNDAsMTEgKzQwLDkgQEAgZGlzdDogREVTVERJUj0kKERJU1RESVIpL2luc3RhbGwKIGRp
c3Q6IGRpc3QteGVuIGRpc3Qta2VybmVscyBkaXN0LXRvb2xzIGRpc3Qtc3R1YmRvbSBkaXN0LWRv
Y3MgZGlzdC1taXNjCiAKIGRpc3QtbWlzYzoKLQkkKElOU1RBTExfRElSKSAkKERJU1RESVIpL2No
ZWNrCiAJJChJTlNUQUxMX0RBVEEpIC4vQ09QWUlORyAkKERJU1RESVIpCiAJJChJTlNUQUxMX0RB
VEEpIC4vUkVBRE1FICQoRElTVERJUikKIAkkKElOU1RBTExfUFJPRykgLi9pbnN0YWxsLnNoICQo
RElTVERJUikKLQkkKElOU1RBTExfUFJPRykgdG9vbHMvY2hlY2svY2hrIHRvb2xzL2NoZWNrL2No
ZWNrXyogdG9vbHMvY2hlY2svZnVuY3Muc2ggJChESVNURElSKS9jaGVjawogZGlzdC0lOiBERVNU
RElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdC0lOiBpbnN0YWxsLSUKIAlAOiAjIGRvIG5vdGhp
bmcKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIFJFQURNRQotLS0gYS9SRUFE
TUUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL1JFQURNRQlNb24gSmFuIDA5
IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTQxLDYgKzQxLDcgQEAgcHJvdmlkZWQgYnkgeW91ciBP
UyBkaXN0cmlidXRvcjoKICAgICAqIEdDQyB2My40IG9yIGxhdGVyCiAgICAgKiBHTlUgTWFrZQog
ICAgICogR05VIEJpbnV0aWxzCisgICAgKiBHTlUgQXV0b2NvbmYgdjIuNjcgb3IgbGF0ZXIKICAg
ICAqIERldmVsb3BtZW50IGluc3RhbGwgb2YgemxpYiAoZS5nLiwgemxpYi1kZXYpCiAgICAgKiBE
ZXZlbG9wbWVudCBpbnN0YWxsIG9mIFB5dGhvbiB2Mi4zIG9yIGxhdGVyIChlLmcuLCBweXRob24t
ZGV2KQogICAgICogRGV2ZWxvcG1lbnQgaW5zdGFsbCBvZiBjdXJzZXMgKGUuZy4sIGxpYm5jdXJz
ZXMtZGV2KQpAQCAtODcsOSArODgsMjEgQEAgMi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0
ZXZlciB5b3UgcwogMy4gRm9yIHRoZSB2ZXJ5IGZpcnN0IGJ1aWxkLCBvciBpZiB5b3Ugd2FudCB0
byBkZXN0cm95IGJ1aWxkIHRyZWVzLAogICAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgog
CisgICBJZiB5b3UgYXJlIGJ1aWxkaW5nIFhlbiBmcm9tIGEgcmVwb3NpdG9yeSAoZ2l0IG9yIG1l
cmN1cmlhbCkgeW91CisgICBtdXN0IHJ1bjoKKworICAgICMgLi9hdXRvZ2VuLnNoCisKKyAgIEJl
Zm9yZSBleGVjdXRpbmcgLi9jb25maWd1cmUgKHRoaXMgc3RlcCBjYW4gYmUgb21taXRlZCB3aGVu
CisgICBidWlsZGluZyBmcm9tIGEgZGlzdHJpYnV0aW9uIHBhY2thZ2UpLgorCisgICAgIyAuL2Nv
bmZpZ3VyZQogICAgICMgbWFrZSB3b3JsZAogICAgICMgbWFrZSBpbnN0YWxsCiAKKyAgIElmIHlv
dSB3YW50LCB5b3UgY2FuIHJ1biAuL2NvbmZpZ3VyZSAtLWhlbHAgdG8gc2VlIHRoZSBsaXN0IG9m
CisgICBvcHRpb25zIGF2YWlsYWJsZSBvcHRpb25zIHdoZW4gYnVpbGRpbmcgYW5kIGluc3RhbGxp
bmcgWGVuLgorCiAgICBUaGlzIHdpbGwgY3JlYXRlIGFuZCBpbnN0YWxsIG9udG8gdGhlIGxvY2Fs
IG1hY2hpbmUuIEl0IHdpbGwgYnVpbGQKICAgIHRoZSB4ZW4gYmluYXJ5ICh4ZW4uZ3opLCB0aGUg
dG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0aW9uLgogCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdk
OTBjYmRjYTJjMiBhdXRvZ2VuLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL2F1dG9nZW4uc2gJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAw
CkBAIC0wLDAgKzEsMTEgQEAKKyMhL2Jpbi9zaAorcm0gLXJmIGNvbmZpZ3VyZQorY2QgdG9vbHMK
K2F1dG9oZWFkZXIgJiYgYXV0b2NvbmYKK2lmIFsgIiQ/IiA9ICIwIiBdCit0aGVuCisgICAgY2Qg
Li4KKyAgICBlY2hvICIjIS9iaW4vc2giID4+IGNvbmZpZ3VyZQorICAgIGVjaG8gImNkIHRvb2xz
ICYmIC4vY29uZmlndXJlIFwkQCIgPj4gY29uZmlndXJlCisgICAgY2htb2QgK3ggY29uZmlndXJl
CitmaQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgY29uZmlnL1Rvb2xzLm1r
LmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL2Nv
bmZpZy9Ub29scy5tay5pbglNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTAsMCAr
MSw1MCBAQAorIyBQcmVmaXggYW5kIGluc3RhbGwgZm9sZGVyCitQUkVGSVggICAgICAgICAgICAg
IDo9IEBwcmVmaXhACitMSUJMRUFGRElSX3g4Nl82NCAgIDo9IEBMSUJfUEFUSEAKKworIyBBIGRl
YnVnIGJ1aWxkIG9mIHRvb2xzPworZGVidWcgICAgICAgICAgICAgICA6PSBAZGVidWdACisKKyMg
VG9vbHMgcGF0aAorQklTT04gICAgICAgICAgICAgICA6PSBAQklTT05ACitGTEVYICAgICAgICAg
ICAgICAgIDo9IEBGTEVYQAorUFlUSE9OICAgICAgICAgICAgICA6PSBAUFlUSE9OQAorUFlUSE9O
X1BBVEggICAgICAgICA6PSBAUFlUSE9OUEFUSEAKK1BFUkwgICAgICAgICAgICAgICAgOj0gQFBF
UkxACitCUkNUTCAgICAgICAgICAgICAgIDo9IEBCUkNUTEAKK0lQICAgICAgICAgICAgICAgICAg
Oj0gQElQQAorQ1VSTF9DT05GSUcgICAgICAgICA6PSBAQ1VSTEAKK1hNTDJfQ09ORklHICAgICAg
ICAgOj0gQFhNTEAKK0JBU0ggICAgICAgICAgICAgICAgOj0gQEJBU0hACitYR0VUVFRFWFQgICAg
ICAgICAgIDo9IEBYR0VUVEVYVEAKKworIyBFeHRyYSBmb2xkZXIgZm9yIGxpYnMvaW5jbHVkZXMK
K1BSRVBFTkRfSU5DTFVERVMgICAgOj0gQFBSRVBFTkRfSU5DTFVERVNACitQUkVQRU5EX0xJQiAg
ICAgICAgIDo9IEBQUkVQRU5EX0xJQkAKK0FQUEVORF9JTkNMVURFUyAgICAgOj0gQEFQUEVORF9J
TkNMVURFU0AKK0FQUEVORF9MSUIgICAgICAgICAgOj0gQEFQUEVORF9MSUJACisKKyMgRW5hYmxl
IFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKS4KK1hTTV9FTkFCTEUgICAg
ICAgICAgOj0gQHhzbUAKK0ZMQVNLX0VOQUJMRSAgICAgICAgOj0gQHhzbUAKKworIyBEb3dubG9h
ZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8KKyMgR0lU
J3MgcHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3JrcyBhdCBh
bGwgKGZpcmV3YWxscworIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBkZWZhdWx0LCBi
dXQgaWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKKyMgZmFpbCBvciBoYW5nLCBwbGVh
c2Ugc3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQuCitHSVRfSFRUUCAgICAg
ICAgICAgIDo9IEBnaXRodHRwQAorCisjIE9wdGlvbmFsIGNvbXBvbmVudHMKK1hFTlNUQVRfWEVO
VE9QICAgICAgOj0gQG1vbml0b3JzQAorVlRQTV9UT09MUyAgICAgICAgICA6PSBAdnRwbUAKK0xJ
QlhFTkFQSV9CSU5ESU5HUyAgOj0gQHhhcGlACitQWVRIT05fVE9PTFMgICAgICAgIDo9IEBweXRo
b250b29sc0AKK09DQU1MX1RPT0xTICAgICAgICAgOj0gQG9jYW1sdG9vbHNACitDT05GSUdfTUlO
SVRFUk0gICAgIDo9IEBtaW5pdGVybUAKK0NPTkZJR19MT01PVU5UICAgICAgOj0gQGxvbW91bnRA
CisKKyNTeXN0ZW0gb3B0aW9ucworQ09ORklHX1NZU1RFTV9MSUJBSU86PSBAc3lzdGVtX2Fpb0AK
K0NPTkZJR19MSUJJQ09OViAgICAgOj0gQGxpYmljb252QAorQ09ORklHX0dDUllQVCAgICAgICA6
PSBAbGliZ2NyeXB0QAorQ09ORklHX0VYVDJGUyAgICAgICA6PSBAbGliZXh0MmZzQApkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMv
TWFrZWZpbGUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL01ha2Vm
aWxlCU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEwMApAQCAtNiw3ICs2LDYgQEAgU1VCRElS
Uy1saWJhaW8gOj0gbGliYWlvCiBlbmRpZgogCiBTVUJESVJTLXkgOj0KLVNVQkRJUlMteSArPSBj
aGVjawogU1VCRElSUy15ICs9IGluY2x1ZGUKIFNVQkRJUlMteSArPSBsaWJ4YwogU1VCRElSUy15
ICs9IGZsYXNrCkBAIC03MiwxMCArNzEsMTQgQEAgaW5zdGFsbDogc3ViZGlycy1pbnN0YWxsCiAK
IC5QSE9OWTogY2xlYW4KIGNsZWFuOiBzdWJkaXJzLWNsZWFuCisJcm0gLXJmIC4uL2NvbmZpZy9U
b29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0dXMgXAorICAgICAgICAgICAg
ICAgY29uZmlnLmNhY2hlCiAKIC5QSE9OWTogZGlzdGNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMt
ZGlzdGNsZWFuCiAJcm0gLXJmIGlvZW11LWRpciBpb2VtdS1yZW1vdGUKKwlybSAtcmYgLi4vY29u
ZmlnL1Rvb2xzLm1rIGNvbmZpZy5oIGNvbmZpZy5sb2cgY29uZmlnLnN0YXR1cyBcCisgICAgICAg
ICAgICAgICBjb25maWcuY2FjaGUgLi4vY29uZmlndXJlIGF1dG9tNHRlLmNhY2hlIGNvbmZpZy5o
LmluIGNvbmZpZ3VyZQogCiBpZm5lcSAoJChYRU5fQ09NUElMRV9BUkNIKSwkKFhFTl9UQVJHRVRf
QVJDSCkpCiBJT0VNVV9DT05GSUdVUkVfQ1JPU1MgPz0gLS1jcHU9JChYRU5fVEFSR0VUX0FSQ0gp
IFwKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL1J1bGVzLm1rCi0t
LSBhL3Rvb2xzL1J1bGVzLm1rCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi90
b29scy9SdWxlcy5tawlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTMsNiArMyw3
IEBACiAjIGBhbGwnIGlzIHRoZSBkZWZhdWx0IHRhcmdldAogYWxsOgogCitpbmNsdWRlICQoWEVO
X1JPT1QpL2NvbmZpZy9Ub29scy5tawogaW5jbHVkZSAkKFhFTl9ST09UKS9Db25maWcubWsKIAog
ZXhwb3J0IF9JTlNUQUxMIDo9ICQoSU5TVEFMTCkKQEAgLTgwLDggKzgxLDYgQEAgY2hlY2stJChD
T05GSUdfWDg2KSA9ICQoY2FsbCBjYy12ZXItY2hlYwogICAgICAgICAgICAgICAgICAgICAgICAg
IlhlbiByZXF1aXJlcyBhdCBsZWFzdCBnY2MtMy40IikKICQoZXZhbCAkKGNoZWNrLXkpKQogCi1f
UFlUSE9OX1BBVEggOj0gJChzaGVsbCB3aGljaCAkKFBZVEhPTikpCi1QWVRIT05fUEFUSCA/PSAk
KF9QWVRIT05fUEFUSCkKIElOU1RBTExfUFlUSE9OX1BST0cgPSBcCiAJJChYRU5fUk9PVCkvdG9v
bHMvcHl0aG9uL2luc3RhbGwtd3JhcCAiJChQWVRIT05fUEFUSCkiICQoSU5TVEFMTF9QUk9HKQog
CkBAIC0xMDksMyArMTA4LDcgQEAgc3ViZGlyLWFsbC0lIHN1YmRpci1jbGVhbi0lIHN1YmRpci1p
bnN0YQogCiBzdWJkaXItZGlzdGNsZWFuLSU6IC5waG9ueQogCSQoTUFLRSkgLUMgJCogY2xlYW4K
KworJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xzLm1rOgorCUBlY2hvICJZb3UgaGF2ZSB0byBydW4g
Li9jb25maWd1cmUgYmVmb3JlIGJ1aWxkaW5nIG9yIGluc3RhbGxpbmcgdGhlIHRvb2xzIgorCUBl
eGl0IDEKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL2Jsa3RhcC9k
cml2ZXJzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVRodSBK
YW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi90b29scy9ibGt0YXAvZHJpdmVycy9NYWtl
ZmlsZQlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTEzLDcgKzEzLDcgQEAgQ0ZM
QUdTICAgKz0gJChDRkxBR1NfbGlieGVuc3RvcmUpCiBDRkxBR1MgICArPSAtSSAkKE1FTVNIUl9E
SVIpCiBDRkxBR1MgICArPSAtRF9HTlVfU09VUkNFCiAKLWlmZXEgKCQoc2hlbGwgLiAuL2NoZWNr
X2djcnlwdCAkKENDKSkseWVzKQoraWZlcSAoJENPTkZJR19HQ1JZUFQseSkKIENGTEFHUyArPSAt
RFVTRV9HQ1JZUFQKIENSWVBUX0xJQiA6PSAtbGdjcnlwdAogZWxzZQpkaWZmIC1yIDQwODZlNDgx
MTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvYmxrdGFwL2RyaXZlcnMvY2hlY2tfZ2NyeXB0Ci0t
LSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAlUaHUgSmFuIDA1IDE3OjI1OjIz
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0KLWNhdCA+IC5nY3J5cHQuYyA8PCBFT0YKLSNp
bmNsdWRlIDxnY3J5cHQuaD4KLWludCBtYWluKHZvaWQpIHsgcmV0dXJuIDA7IH0KLUVPRgotCi1p
ZiAkMSAtbyAuZ2NyeXB0IC5nY3J5cHQuYyAtbGdjcnlwdCAyPi9kZXYvbnVsbCA7IHRoZW4KLSAg
ZWNobyAieWVzIgotZWxzZQotICBlY2hvICJubyIKLWZpCi0KLXJtIC1mIC5nY3J5cHQqCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9jaGVjay9NYWtlZmlsZQotLS0g
YS90b29scy9jaGVjay9NYWtlZmlsZQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjYgKzAsMCBA
QAotWEVOX1JPT1QgPSAkKENVUkRJUikvLi4vLi4KLWluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMv
UnVsZXMubWsKLQotIyBFeHBvcnQgdGhlIG5lY2Vzc2FyeSBlbnZpcm9ubWVudCB2YXJpYWJsZXMg
Zm9yIHRoZSB0ZXN0cwotZXhwb3J0IFBZVEhPTgotZXhwb3J0IExJQlhFTkFQSV9CSU5ESU5HUwot
ZXhwb3J0IENIRUNLX0lOQ0xVREVTCi1leHBvcnQgQ0hFQ0tfTElCCi1leHBvcnQgQ09ORklHX1NZ
U1RFTV9MSUJBSU8KLQotLlBIT05ZOiBhbGwgaW5zdGFsbAotYWxsIGluc3RhbGw6IGNoZWNrLWJ1
aWxkCi0KLSMgQ2hlY2sgdGhpcyBtYWNoaW5lIGlzIE9LIGZvciBidWlsZGluZyBvbi4KLS5QSE9O
WTogY2hlY2stYnVpbGQKLWNoZWNrLWJ1aWxkOgotCS4vY2hrIGJ1aWxkCi0KLSMgQ2hlY2sgdGhp
cyBtYWNoaW5lIGlzIE9LIGZvciBpbnN0YWxsaW5nIG9uLgotLlBIT05ZOiBjaGVjay1pbnN0YWxs
Ci1jaGVjay1pbnN0YWxsOgotCS4vY2hrIGluc3RhbGwKLQotLlBIT05ZOiBjbGVhbgotY2xlYW46
Ci0JLi9jaGsgY2xlYW4KZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xz
L2NoZWNrL1JFQURNRQotLS0gYS90b29scy9jaGVjay9SRUFETUUJVGh1IEphbiAwNSAxNzoyNToy
MyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDIwICswLDAgQEAKLUNoZWNrcyBmb3IgdGhlIHN1aXRhYmlsaXR5IG9mIGEgbWFjaGlu
ZSBmb3IgWGVuIGJ1aWxkIG9yIGluc3RhbGwuCi1UbyBjaGVjayBmb3IgYnVpbGQgc3VpdGFiaWxp
dHkgdXNlCi0KLSAgICAgICAgLi9jaGsgYnVpbGQKLQotVG8gY2hlY2sgZm9yIGluc3RhbGwgc3Vp
dGFiaWxpdHkgdXNlCi0KLSAgICAgICAgLi9jaGsgaW5zdGFsbAotCi1UaGUgY2hrIHNjcmlwdCB3
aWxsIHJ1biBjaGVja3MgaW4gdGhpcyBkaXJlY3RvcnkgYW5kIHByaW50Ci10aGUgb25lcyB0aGF0
IGZhaWxlZC4gSXQgcHJpbnRzIG5vdGhpbmcgaWYgY2hlY2tzIHN1Y2NlZWQuCi1UaGUgY2hrIHNj
cmlwdCBleGl0cyB3aXRoIDAgb24gc3VjY2VzcyBhbmQgMSBvbiBmYWlsdXJlLgotCi1UaGUgY2hr
IHNjcmlwdCBydW5zIGV4ZWN1dGFibGUgZmlsZXMgaW4gdGhpcyBkaXJlY3Rvcnkgd2hvc2UKLW5h
bWVzIGJlZ2luIHdpdGggJ2NoZWNrXycuIEZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0stQlVJTEQKLWFy
ZSBydW4gZm9yIHRoZSBidWlsZCBjaGVjaywgYW5kIGZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0stSU5T
VEFMTAotYXJlIHJ1biBmb3IgdGhlIGluc3RhbGwgY2hlY2suCi0KLURldGFpbGVkIG91dHB1dCBm
cm9tIHRoZSBjaGVjayBzY3JpcHRzIGlzIGluIC5jaGtidWlsZCBmb3IgYnVpbGQKLWFuZCAuY2hr
aW5zdGFsbCBmb3IgaW5zdGFsbC4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLXIg
NDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9jaGVjay9jaGVja19icmN0bAotLS0g
YS90b29scy9jaGVjay9jaGVja19icmN0bAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAK
KysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2Ug
JE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhhc19vcl9mYWlsIGJyY29uZmlnIDs7
Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBicmN0bCA7OwotKikKLQlmYWlsICJ1bmtub3duIE9TIiA7
OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2sv
Y2hlY2tfY3J5cHRvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19jcnlwdG9fbGliCVRodSBK
YW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQg
Q0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0
QlNEfE9wZW5CU0QpCi0JZXhpdCAwIDs7Ci1lc2FjCi0KLWhhc19saWIgbGliY3J5cHRvLnNvIHx8
IGZhaWwgIm1pc3NpbmcgbGliY3J5cHRvLnNvIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkw
Y2JkY2EyYzIgdG9vbHMvY2hlY2svY2hlY2tfY3VybAotLS0gYS90b29scy9jaGVjay9jaGVja19j
dXJsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyAiJExJQlhFTkFQ
SV9CSU5ESU5HUyIgIT0gInkiIF07IHRoZW4KLQllY2hvIC1uICJ1bnVzZWQsICIKLQlleGl0IDAK
LWZpCi0KLWhhc19vcl9mYWlsIGN1cmwtY29uZmlnCi1jdXJsX2xpYnM9YGN1cmwtY29uZmlnIC0t
bGlic2AgfHwgZmFpbCAiY3VybC1jb25maWcgLS1saWJzIGZhaWxlZCIKLXRlc3RfbGluayAkY3Vy
bF9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZvciBjdXJsIGFyZSBtaXNzaW5n
IgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2svY2hlY2tf
aXByb3V0ZQotLS0gYS90b29scy9jaGVjay9jaGVja19pcHJvdXRlCVRodSBKYW4gMDUgMTc6MjU6
MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSwxNSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVu
Y3Muc2gKLQotUEFUSD0vc2JpbjokUEFUSAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8
RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBpZmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwg
aXAgOzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19kZXZlbAotLS0gYS90
b29scy9jaGVjay9jaGVja19saWJhaW9fZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEx
ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYg
WyBYJHtDT05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQgMAot
ZmkKLWlmICEgaGFzX2hlYWRlciBsaWJhaW8uaCA7IHRoZW4KLSAgICBmYWlsICJjYW4ndCBmaW5k
IGxpYmFpbyBoZWFkZXJzLCBpbnN0YWxsIGxpYmFpbyBkZXZlbCBwYWNrYWdlIG9yIHNldCBDT05G
SUdfU1lTVEVNX0xJQkFJTz1uIgotZmkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNh
MmMyIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tf
bGliYWlvX2xpYglUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0jIS9iaW4vc2gK
LSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyBYJHtD
T05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQgMAotZmkKLWhh
c19saWIgbGliYWlvLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGliYWlvIgpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNzbF9kZXZlbAot
LS0gYS90b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gK
LQotaGFzX2hlYWRlciBvcGVuc3NsL21kNS5oIHx8IGZhaWwgIm1pc3Npbmcgb3BlbnNzbCBoZWFk
ZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2svY2hl
Y2tfcHl0aG9uCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbglUaHUgSmFuIDA1IDE3OjI1
OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RB
TEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhP
Tj1weXRob24KLWZpCi0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgc3lzCi1zeXMuZXhpdChzeXMu
dmVyc2lvbl9pbmZvWzBdIDwgMiBvciBzeXMudmVyc2lvbl9pbmZvWzFdIDwgMykKLScgfHwgZmFp
bCAibmVlZCBweXRob24gdmVyc2lvbiA+PSAyLjMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdk
OTBjYmRjYTJjMiB0b29scy9jaGVjay9jaGVja19weXRob25fZGV2ZWwKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfcHl0aG9uX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNyArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXog
JHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZpCi1oYXNfb3JfZmFpbCAke1BZVEhP
Tn0KLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBvcy5wYXRoLCBzeXMKLWZvciBwIGluIHN5cy5w
YXRoOgotCWlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIpOgotCQlzeXMu
ZXhpdCgwKQotc3lzLmV4aXQoMSkKLScgfHwgZmFpbCAiY2FuJ3QgZmluZCBweXRob24gZGV2ZWwg
ZmlsZXMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9jaGVjay9j
aGVja19weXRob25feG1sCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl94bWwJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxM
Ci0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049
cHl0aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnaW1wb3J0
IHhtbC5kb20ubWluaWRvbScgMj4vZGV2L251bGwgfHwgXAotZmFpbCAiY2FuJ3QgaW1wb3J0IHht
bC5kb20ubWluaWRvbSIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xz
L2NoZWNrL2NoZWNrX3VkZXYKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdWRldglUaHUgSmFuIDA1
IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsMjIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQot
LiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhh
c19vcl9mYWlsIHZuY29uZmlnCi0JOzsKLUxpbnV4KQotCWhhcyAvc2Jpbi91ZGV2YWRtICYmIFwK
LQkJdWRldnZlcj1gL3NiaW4vdWRldmFkbSBpbmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCi0J
WyAteiAiJHVkZXZ2ZXIiIF0gJiYgaGFzX29yX2ZhaWwgdWRldmluZm8gJiYgXAotCQl1ZGV2dmVy
PWB1ZGV2aW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgIiR1ZGV2dmVyIiAtZ2UgNTkg
XSAyPi9kZXYvbnVsbCB8fCBcCi0JCWhhcyBob3RwbHVnIHx8IFwKLQkJZmFpbCAidWRldiBpcyB0
b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3IgbGF0ZXIiCi0JOzsKLSopCi0JZmFpbCAi
dW5rbm93biBPUyIKLQk7OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2Ey
YzIgdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja191
dWlkX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw3ICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB1dWlkLmggfHwgXAot
aGFzX2hlYWRlciB1dWlkL3V1aWQuaCB8fCBmYWlsICJtaXNzaW5nIHV1aWQgaGVhZGVycyAocGFj
a2FnZSB1dWlkLWRldikiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29s
cy9jaGVjay9jaGVja194MTFfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVs
CVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1C
VUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciBYMTEva2V5c3ltZGVmLmggfHwgXAot
aGFzX2hlYWRlciAvdXNyL1gxMVI2L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLWhhc19o
ZWFkZXIgL3Vzci9YMTFSNy9pbmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8fCBcCi13YXJuaW5nICJj
YW4ndCBmaW5kIFgxMSBoZWFkZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2Ey
YzIgdG9vbHMvY2hlY2svY2hlY2tfeGdldHRleHQKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeGdl
dHRleHQJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3NoCi0jIENI
RUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfb3JfZmFpbCB4Z2V0dGV4dApkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2svY2hlY2tfeG1sMgotLS0g
YS90b29scy9jaGVjay9jaGVja194bWwyCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAor
KysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNCArMCww
IEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Mu
c2gKLQotaWYgWyAhICIkTElCWEVOQVBJX0JJTkRJTkdTIiA9ICJ5IiBdCi10aGVuCi0gICAgZWNo
byAtbiAidW51c2VkLCAiCi0gICAgZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCB4bWwyLWNvbmZp
ZwoteG1sMl9saWJzPWB4bWwyLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgInhtbDItY29uZmlnIC0t
bGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJHhtbDJfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxp
YnJhcmllcyBmb3IgeG1sMiBhcmUgbWlzc2luZyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5
MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2sv
Y2hlY2tfeWFqbF9kZXZlbAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOCArMCwwIEBACi0jIS9i
aW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgeWFqbC95
YWpsX3BhcnNlLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfcGFyc2UuaCIKLWhhc19o
ZWFkZXIgeWFqbC95YWpsX2dlbi5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95YWpsX2dlbi5o
IgotaGFzX2xpYiBsaWJ5YWpsLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFqbC5zbyIKZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxf
bGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfbGliCVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfbGliIGxpYnlhamwuc28uMSB8fCBmYWlsICJjYW4ndCBmaW5k
IGxpYnlhamwuc28uMSB2ZXJzaW9uIDEiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRj
YTJjMiB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3psaWJfZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBm
YWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5
MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX3psaWJfbGliCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAk
T1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFz
X2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJ
VGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3Vz
YWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFs
bHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4g
YnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90
LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5l
cmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2Jp
bgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIg
XTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBj
aGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hl
Y2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQg
MAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVz
YWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBj
aGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29u
dGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVz
YWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQot
ICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0g
ICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRo
ZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQot
ZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2Ey
YzIgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGlj
aCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAt
eiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVy
biAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0
byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBp
biAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0J
CQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUK
LQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVs
bCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5
c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBb
IC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAw
Ci0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAi
JENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQot
CQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVj
a19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlv
biBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAj
IGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhp
cyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0
Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3Jr
LgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNv
LmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JP
U1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91
Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9
ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JP
U1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIk
e09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZx
ICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkg
ewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1w
ZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1g
bWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+
JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5
IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiBy
ZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVh
c2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlm
aQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1y
b290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJu
aW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAk
Kn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZB
SUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNi
ZGNhMmMyIHRvb2xzL2NvbmZpZ3VyZS5hYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWd1cmUuYWMJTW9uIEphbiAwOSAyMTozMzo1
MiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTc5IEBACisjICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAtKi0gQXV0b2NvbmYgLSotCisjIFByb2Nlc3MgdGhpcyBm
aWxlIHdpdGggYXV0b2NvbmYgdG8gcHJvZHVjZSBhIGNvbmZpZ3VyZSBzY3JpcHQuCisKK0FDX1BS
RVJFUShbMi42N10pCitBQ19JTklUKFtYZW4gSHlwZXJ2aXNvcl0sbTRfZXN5c2NtZChbLi4vdmVy
c2lvbi5zaCAuLi94ZW4vTWFrZWZpbGVdKSwgW3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
XSkKK0FDX0NPTkZJR19TUkNESVIoW2xpYnhsL2xpYnhsLmNdKQorQUNfQ09ORklHX0ZJTEVTKFsu
Li9jb25maWcvVG9vbHMubWtdKQorQUNfQ09ORklHX0hFQURFUlMoW2NvbmZpZy5oXSkKK0FDX1BS
RUZJWF9ERUZBVUxUKFsvdXNyXSkKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxBR1MsIExJQlMs
IENQUEZMQUdTIG9yIENQUCBpcyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitBU19JRihbdGVz
dCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIl0sIFsKKyAgICBBQ19N
U0dfV0FSTigKK1tTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9y
IENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5E
X0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3Nz
aWJsZS5dKQorXSkKKworQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCisKKyMgTTQgTWFjcm8gaW5j
bHVkZXMKK200X2luY2x1ZGUoW200L2VuYWJsZV9mZWF0dXJlLm00XSkKK200X2luY2x1ZGUoW200
L2Rpc2FibGVfZmVhdHVyZS5tNF0pCittNF9pbmNsdWRlKFttNC9wYXRoX29yX2ZhaWwubTRdKQor
bTRfaW5jbHVkZShbbTQvcHl0aG9uX3htbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25fdmVy
c2lvbi5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25fZGV2ZWwubTRdKQorbTRfaW5jbHVkZShb
bTQvdWRldi5tNF0pCittNF9pbmNsdWRlKFttNC9vY2FtbC5tNF0pCittNF9pbmNsdWRlKFttNC9k
ZWZhdWx0X2xpYi5tNF0pCittNF9pbmNsdWRlKFttNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQor
CisjIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeHNt
XSwKKyAgICBbRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKV0p
CitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW2dpdGh0dHBdLCBbRG93bmxvYWQgR0lUIHJlcG9z
aXRvcmllcyB2aWEgSFRUUF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFttb25pdG9yc10s
CisgICAgW0Rpc2FibGUgeGVuc3RhdCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHNdKQorQVhf
QVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt2dHBtXSwgW0VuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxh
dGZvcm0gTW9kdWxlXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeGFwaV0sIFtFbmFibGUg
WGVuIEFQSSBCaW5kaW5nc10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtweXRob250b29s
c10sIFtEaXNhYmxlIFB5dGhvbiB0b29sc10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtv
Y2FtbHRvb2xzXSwgW0Rpc2FibGUgT2NhbWwgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQ
T1JUKFttaW5pdGVybV0sIFtFbmFibGUgbWluaXRlcm1dKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQ
T1JUKFtsb21vdW50XSwgW0VuYWJsZSBsb21vdW50XSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBP
UlQoW2RlYnVnXSwgW0Rpc2FibGUgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29sc10pCisKK0FD
X0FSR19WQVIoW1BSRVBFTkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVy
cyB0byBwcmVwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSldKQorQUNfQVJHX1ZBUihbUFJFUEVO
RF9MSUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxB
R1MgKHdpdGhvdXQgLUwpXSkKK0FDX0FSR19WQVIoW0FQUEVORF9JTkNMVURFU10sCisgICAgW0xp
c3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkK
K0FDX0FSR19WQVIoW0FQUEVORF9MSUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0
byBhcHBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCldKQorCitBWF9TRVRfRkxBR1MKKworQUNf
QVJHX1ZBUihbUFlUSE9OXSwgW1BhdGggdG8gdGhlIFB5dGhvbiBwYXJzZXJdKQorQUNfQVJHX1ZB
UihbUEVSTF0sIFtQYXRoIHRvIFBlcmwgcGFyc2VyXSkKK0FDX0FSR19WQVIoW0JSQ1RMXSwgW1Bh
dGggdG8gYnJjdGwgdG9vbF0pCitBQ19BUkdfVkFSKFtJUF0sIFtQYXRoIHRvIGlwIHRvb2xdKQor
QUNfQVJHX1ZBUihbQklTT05dLCBbUGF0aCB0byBCaXNvbiBwYXJzZXIgZ2VuZXJhdG9yXSkKK0FD
X0FSR19WQVIoW0ZMRVhdLCBbUGF0aCB0byBGbGV4IGxleGljYWwgYW5hbHlzZXIgZ2VuZXJhdG9y
XSkKK0FDX0FSR19WQVIoW0NVUkxdLCBbUGF0aCB0byBjdXJsLWNvbmZpZyB0b29sXSkKK0FDX0FS
R19WQVIoW1hNTF0sIFtQYXRoIHRvIHhtbDItY29uZmlnIHRvb2xdKQorQUNfQVJHX1ZBUihbQkFT
SF0sIFtQYXRoIHRvIGJhc2ggc2hlbGxdKQorQUNfQVJHX1ZBUihbWEdFVFRFWFRdLCBbUGF0aCB0
byB4Z2V0dHRleHQgdG9vbF0pCisKKyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK0FDX1BST0dfU0VE
CitBQ19QUk9HX0NDCitBQ19QUk9HX0lOU1RBTEwKK0FDX1BST0dfTE5fUworQUNfUFJPR19NQUtF
X1NFVAorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BFUkxdLCBbcGVybF0pCitBWF9QQVRIX1BST0df
T1JfRkFJTChbQlJDVExdLCBbYnJjdGxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lQXSwgW2lw
XSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtCSVNPTl0sIFtiaXNvbl0pCitBWF9QQVRIX1BST0df
T1JfRkFJTChbRkxFWF0sIFtmbGV4XSkKK0FTX0lGKFt0ZXN0ICJ4JHhhcGkiID0gInh5Il0sIFsK
KyAgICBBWF9QQVRIX1BST0dfT1JfRkFJTChbQ1VSTF0sIFtjdXJsLWNvbmZpZ10pCisgICAgQVhf
UEFUSF9QUk9HX09SX0ZBSUwoW1hNTF0sIFt4bWwyLWNvbmZpZ10pCitdKQorQVNfSUYoW3Rlc3Qg
Ingkb2NhbWx0b29scyIgPSAieHkiXSwgWworICAgIEFDX1BST0dfT0NBTUwKKyAgICBBU19JRihb
dGVzdCAieCRPQ0FNTEMiID0gInhubyJdLCBbCisgICAgICBvY2FtbHRvb2xzPSJuIgorICAgIF0p
CitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JBU0hdLCBbYmFzaF0pCitBU19JRihbdGVzdCAi
eCRweXRob250b29scyIgPSAieHkiXSwgWworICAgIEFTX0lGKFtlY2hvICIkUFlUSE9OIiB8IGdy
ZXAgLXEgIl4vIl0sIFsKKyAgICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhP
Tj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCisgICAgXSxbdGVzdCAteiAiJFBZVEhPTiJdLCBbUFlU
SE9OPSJweXRob24iXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtQWVRIT04gc3BlY2lmaWVkLCBidXQg
aXMgbm90IGFuIGFic29sdXRlIHBhdGhdKV0pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BZ
VEhPTlBBVEhdLCBbJFBZVEhPTl0pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT04oWzJdLCBb
M10pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1hNTCgpCisgICAgQVhfQ0hFQ0tfUFlUSE9OX0RFVkVM
KCkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbWEdFVFRFWFRdLCBbeGdldHRleHRdKQorQVhf
Q0hFQ0tfVURFVihbNTldKQorCisjIENoZWNrIGxpYnJhcnkgcGF0aAorQVhfREVGQVVMVF9MSUIK
KworIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK0FDX0NIRUNLX0xJQihbYWlvXSwgW2lvX3NldHVw
XSwgW3N5c3RlbV9haW89InkiXSwgW3N5c3RlbV9haW89Im4iXSkKK0FDX1NVQlNUKHN5c3RlbV9h
aW8pCitBQ19DSEVDS19MSUIoW2NyeXB0b10sIFtNRDVdLCBbXSwgW0FDX01TR19FUlJPUihbQ291
bGQgbm90IGZpbmQgbGliY3J5cHRvXSldKQorQUNfQ0hFQ0tfTElCKFtleHQyZnNdLCBbZXh0MmZz
X29wZW4yXSwgW2xpYmV4dDJmcz0ieSJdLCBbbGliZXh0MmZzPSJuIl0pCitBQ19TVUJTVChsaWJl
eHQyZnMpCitBQ19DSEVDS19MSUIoW2djcnlwdF0sIFtnY3J5X21kX2hhc2hfYnVmZmVyXSwgW2xp
YmdjcnlwdD0ieSJdLCBbbGliZ2NyeXB0PSJuIl0pCitBQ19TVUJTVChsaWJnY3J5cHQpCitBQ19D
SEVDS19MSUIoW3B0aHJlYWRdLCBbcHRocmVhZF9jcmVhdGVdLCBbXSAsCisgICAgW0FDX01TR19F
UlJPUihbQ291bGQgbm90IGZpbmQgbGlicHRocmVhZF0pXSkKK0FDX0NIRUNLX0xJQihbcnRdLCBb
Y2xvY2tfZ2V0dGltZV0pCitBQ19DSEVDS19MSUIoW3V1aWRdLCBbdXVpZF9jbGVhcl0sIFtdLAor
ICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnV1aWRdKV0pCitBQ19DSEVDS19M
SUIoW3lhamxdLCBbeWFqbF9hbGxvY10sIFtdLAorICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5v
dCBmaW5kIHlhamxdKV0pCitBQ19DSEVDS19MSUIoW3pdLCBbZGVmbGF0ZUNvcHldLCBbXSwgW0FD
X01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgemxpYl0pXSkKK0FDX0NIRUNLX0xJQihbaWNvbnZd
LCBbbGliaWNvbnZfb3Blbl0sIFtsaWJpY29udj0ieSJdLCBbbGliaWNvbnY9Im4iXSkKK0FDX1NV
QlNUKGxpYmljb252KQorCisjIEF1dG9zY2FuIHN0dWZmIChleGNlcHQgZm9yIHlhamwveWFqbF92
ZXJzaW9uLmggY2hlY2spCisjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgorQUNfRlVOQ19BTExP
Q0EKK0FDX0NIRUNLX0hFQURFUlMoWyBcCisgICAgICAgICAgICAgICAgYXJwYS9pbmV0LmggZmNu
dGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2MuaCBcCisgICAgICAgICAg
ICAgICAgbmV0ZGIuaCBuZXRpbmV0L2luLmggc3RkZGVmLmggc3RkaW50Lmggc3RkbGliLmggc3Ry
aW5nLmggXAorICAgICAgICAgICAgICAgIHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0bC5o
IHN5cy9tb3VudC5oIHN5cy9wYXJhbS5oIFwKKyAgICAgICAgICAgICAgICBzeXMvc29ja2V0Lmgg
c3lzL3N0YXR2ZnMuaCBzeXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3MuaCBcCisgICAgICAgICAg
ICAgICAgdW5pc3RkLmggeWFqbC95YWpsX3ZlcnNpb24uaCBcCisgICAgICAgICAgICAgICAgXSkK
KworIyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFj
dGVyaXN0aWNzLgorQUNfSEVBREVSX1NUREJPT0wKK0FDX1RZUEVfVUlEX1QKK0FDX0NfSU5MSU5F
CitBQ19UWVBFX0lOVDE2X1QKK0FDX1RZUEVfSU5UMzJfVAorQUNfVFlQRV9JTlQ2NF9UCitBQ19U
WVBFX0lOVDhfVAorQUNfVFlQRV9NT0RFX1QKK0FDX1RZUEVfT0ZGX1QKK0FDX1RZUEVfUElEX1QK
K0FDX0NfUkVTVFJJQ1QKK0FDX1RZUEVfU0laRV9UCitBQ19UWVBFX1NTSVpFX1QKK0FDX0NIRUNL
X01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X2Jsa3NpemVdKQorQUNfU1RSVUNUX1NUX0JMT0NLUwor
QUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfcmRldl0pCitBQ19UWVBFX1VJTlQxNl9U
CitBQ19UWVBFX1VJTlQzMl9UCitBQ19UWVBFX1VJTlQ2NF9UCitBQ19UWVBFX1VJTlQ4X1QKK0FD
X0NIRUNLX1RZUEVTKFtwdHJkaWZmX3RdKQorCisjIENoZWNrcyBmb3IgbGlicmFyeSBmdW5jdGlv
bnMuCitBQ19GVU5DX0VSUk9SX0FUX0xJTkUKK0FDX0ZVTkNfRk9SSworQUNfRlVOQ19GU0VFS08K
K0FDX0ZVTkNfTFNUQVRfRk9MTE9XU19TTEFTSEVEX1NZTUxJTksKK0FDX0hFQURFUl9NQUpPUgor
QUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNTKFsgXAorICAgICAgICAgICAgICAgIGFsYXJt
IGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCisg
ICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNp
emUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2Nh
bHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAgICAgICAgICAgICAgIG1r
ZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52
IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJk
dXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0
cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQgXAorICAgICAgICAgICAg
ICAgIHVuYW1lIFwKKyAgICAgICAgICAgICAgICBdKQorCitBQ19PVVRQVVQoKQpkaWZmIC1yIDQw
ODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZp
bGUKLS0tIGEvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJVGh1IEphbiAwNSAxNzoy
NToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCU1v
biBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEwMApAQCAtMjEsNyArMjEsNiBAQCB4Z19hbGwuYTog
JChYR19PQkpTKSBNYWtlZmlsZSAkKFhHX0hEUlMpCiAjCSQoQ0MpIC1tMzIgLWMgLW8gJEAgJF4K
IAogeGVuLWhlYWRlcnM6Ci0JJChNQUtFKSAtQyAuLi8uLi8uLi9jaGVjayAKIAkkKE1BS0UpIC1D
IC4uLy4uLy4uL2luY2x1ZGUKIAogIyB4Z19tYWluLm86IHhnX21haW4uYyBNYWtlZmlsZSAkKFhH
X0hEUlMpCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9saWJmc2lt
YWdlL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJVGh1IEphbiAwNSAx
NzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEph
biAwOSAyMTozMzo1MiAyMDEyICswMTAwCkBAIC0yLDcgKzIsMTEgQEAgWEVOX1JPT1QgPSAkKENV
UkRJUikvLi4vLi4KIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVsZXMubWsKIAogU1VCRElS
Uy15ID0gY29tbW9uIHVmcyByZWlzZXJmcyBpc285NjYwIGZhdCB6ZnMgeGZzCi1TVUJESVJTLXkg
Kz0gJChzaGVsbCBlbnYgQ0M9IiQoQ0MpIiAuL2NoZWNrLWxpYmV4dDJmcykKK2lmZXEgKCQoQ09O
RklHX0VYVDJGUyksIHkpCisgICAgU1VCRElSUy15ICs9IGV4dDJmcy1saWIKK2Vsc2UKKyAgICBT
VUJESVJTLXkgKz0gZXh0MmZzCitlbmRpZgogCiAuUEhPTlk6IGFsbCBjbGVhbiBpbnN0YWxsCiBh
bGwgY2xlYW4gaW5zdGFsbDogJTogc3ViZGlycy0lCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdk
OTBjYmRjYTJjMiB0b29scy9saWJmc2ltYWdlL2NoZWNrLWxpYmV4dDJmcwotLS0gYS90b29scy9s
aWJmc2ltYWdlL2NoZWNrLWxpYmV4dDJmcwlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAK
KysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjEgKzAs
MCBAQAotIyEvYmluL3NoCi0KLWNhdCA+ZXh0Mi10ZXN0LmMgPDxFT0YKLSNpbmNsdWRlIDxleHQy
ZnMvZXh0MmZzLmg+Ci0KLWludCBtYWluKCkKLXsKLQlleHQyZnNfb3BlbjI7Ci19Ci1FT0YKLQot
JHtDQy1nY2N9IC1vIGV4dDItdGVzdCBleHQyLXRlc3QuYyAtbGV4dDJmcyA+L2Rldi9udWxsIDI+
JjEKLWlmIFsgJD8gPSAwIF07IHRoZW4KLQllY2hvIGV4dDJmcy1saWIKLWVsc2UKLQllY2hvIGV4
dDJmcwotZmkKLQotcm0gLWYgZXh0Mi10ZXN0IGV4dDItdGVzdC5jCi0KLWV4aXQgMApkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvbGlieGVuL01ha2VmaWxlCi0tLSBh
L3Rvb2xzL2xpYnhlbi9NYWtlZmlsZQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysr
IGIvdG9vbHMvbGlieGVuL01ha2VmaWxlCU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEwMApA
QCAtMjIsMTIgKzIyLDEyIEBAIE1BSk9SID0gMS4wCiBNSU5PUiA9IDAKIAogQ0ZMQUdTICs9IC1J
aW5jbHVkZSAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAkKHNoZWxsIHhtbDItY29u
ZmlnIC0tY2ZsYWdzKSBcCi0gICAgICAgICAgJChzaGVsbCBjdXJsLWNvbmZpZyAtLWNmbGFncykg
XAorICAgICAgICAgICQoc2hlbGwgJChYTUwyX0NPTkZJRykgLS1jZmxhZ3MpIFwKKyAgICAgICAg
ICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tY2ZsYWdzKSBcCiAgICAgICAgICAgLWZQSUMKIAot
TERGTEFHUyArPSAkKHNoZWxsIHhtbDItY29uZmlnIC0tbGlicykgXAotICAgICAgICAgICAkKHNo
ZWxsIGN1cmwtY29uZmlnIC0tbGlicykKK0xERkxBR1MgKz0gJChzaGVsbCAkKFhNTDJfQ09ORklH
KSAtLWxpYnMpIFwKKyAgICAgICAgICAgJChzaGVsbCAkKENVUkxfQ09ORklHKSAtLWxpYnMpCiAK
IExJQlhFTkFQSV9IRFJTID0gJCh3aWxkY2FyZCBpbmNsdWRlL3hlbi9hcGkvKi5oKSBpbmNsdWRl
L3hlbi9hcGkveGVuX2FsbC5oCiBMSUJYRU5BUElfT0JKUyA9ICQocGF0c3Vic3QgJS5jLCAlLm8s
ICQod2lsZGNhcmQgc3JjLyouYykpCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJj
MiB0b29scy9tNC9kZWZhdWx0X2xpYi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kZWZhdWx0X2xpYi5tNAlNb24gSmFuIDA5IDIx
OjMzOjUyIDIwMTIgKzAxMDAKQEAgLTAsMCArMSw4IEBACitBQ19ERUZVTihbQVhfREVGQVVMVF9M
SUJdLAorW0FTX0lGKFt0ZXN0IC1kICIkcHJlZml4L2xpYjY0Il0sIFsKKyAgICBMSUJfUEFUSD0i
bGliNjQiCitdLFsKKyAgICBMSUJfUEFUSD0ibGliIgorXSkKK0FDX1NVQlNUKExJQl9QQVRIKV0p
CisKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L2Rpc2FibGVf
ZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi90b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtBWF9BUkdfRElTQUJMRV9BTkRfRVhQ
T1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZGlzYWJs
ZS0kMV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisg
ICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInh5ZXMiXSwgWworICAg
IGF4X2N2XyQxPSJ5IgorXSwgW3Rlc3QgLXogJGF4X2N2XyQxXSwgWworICAgIGF4X2N2XyQxPSJ5
IgorXSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcg
LXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L2VuYWJsZV9mZWF0
dXJlLm00CU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEwMApAQCAtMCwwICsxLDEzIEBACitB
Q19ERUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0s
CisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQxXSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0
ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdLCBbdGVzdCAi
eCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAteiAk
YXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdKQorJDE9JGF4X2N2XyQxCitBQ19TVUJT
VCgkMSldKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvbTQvb2Nh
bWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
dG9vbHMvbTQvb2NhbWwubTQJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAwCkBAIC0wLDAg
KzEsMjQxIEBACitkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBPQ2FtbAorZG5sIGZyb20gaHR0cDov
L2ZvcmdlLm9jYW1sY29yZS5vcmcvCitkbmwKK2RubCBDb3B5cmlnaHQgwqkgMjAwOSAgICAgIFJp
Y2hhcmQgVy5NLiBKb25lcworZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgU3RlZmFubyBaYWNj
aGlyb2xpCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBPbGl2aWVyIEFuZHJpZXUKK2RubCBD
b3B5cmlnaHQgwqkgMjAwMC0yMDA1IEplYW4tQ2hyaXN0b3BoZSBGaWxsacOidHJlCitkbmwgQ29w
eXJpZ2h0IMKpIDIwMDAtMjAwNSBHZW9yZ2VzIE1hcmlhbm8KK2RubAorZG5sIEZvciBkb2N1bWVu
dGF0aW9uLCBwbGVhc2UgcmVhZCB0aGUgb2NhbWwubTQgbWFuIHBhZ2UuCisKK0FDX0RFRlVOKFtB
Q19QUk9HX09DQU1MXSwKK1tkbmwKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxjCisgIEFDX0NIRUNL
X1RPT0woW09DQU1MQ10sW29jYW1sY10sW25vXSkKKworICBpZiB0ZXN0ICIkT0NBTUxDIiAhPSAi
bm8iOyB0aGVuCisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wu
KnZlcnNpb24qICpcKC4qXCkkfFwxfHAnYAorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCB2ZXJz
aW9uIGlzICRPQ0FNTFZFUlNJT05dKQorICAgICAjIElmIE9DQU1MTElCIGlzIHNldCwgdXNlIGl0
CisgICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgorICAgICAgICBPQ0FNTExJQj1g
JE9DQU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1MQyAtdnx0YWlsIC0xfGN1dCAtZCAn
ICcgLWYgNGAKKyAgICAgZWxzZQorICAgICAgICBBQ19NU0dfUkVTVUxUKFtPQ0FNTExJQiBwcmV2
aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC5dKQorICAgICBmaQorICAgICBBQ19NU0dfUkVTVUxU
KFtPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCXSkKKworICAgICBBQ19TVUJTVChbT0NB
TUxWRVJTSU9OXSkKKyAgICAgQUNfU1VCU1QoW09DQU1MTElCXSkKKworICAgICAjIGNoZWNraW5n
IGZvciBvY2FtbG9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTE9QVF0sW29jYW1sb3B0XSxb
bm9dKQorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiID0gIm5v
IjsgdGhlbgorCUFDX01TR19XQVJOKFtDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29t
cGlsYXRpb24gb25seS5dKQorICAgICBlbHNlCisJVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwg
c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBW
RVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3Zl
cnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC5dKQorCSAgICBP
Q0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZpCisKKyAg
ICAgQUNfU1VCU1QoW09DQU1MQkVTVF0pCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjLm9w
dAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTENET1RPUFRdLFtvY2FtbGMub3B0XSxbbm9dKQor
ICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1g
JE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAn
IGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAg
ICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0
IGRpc2NhcmRlZC5dKQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAg
ICBmaQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0ZXN0ICIk
T0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJQUNfQ0hFQ0tfVE9PTChbT0NBTUxPUFRET1RPUFRd
LFtvY2FtbG9wdC5vcHRdLFtub10pCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8i
OyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdz
fC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAh
PSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbiBk
aWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLl0pCisJICAgZWxzZQor
CSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZpCisgICAgICAgIGZpCisgICAg
IGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MT1BUXSkKKyAgZmkKKworICBBQ19TVUJTVChbT0NB
TUxDXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbCB0b3BsZXZlbAorICBBQ19DSEVDS19UT09M
KFtPQ0FNTF0sW29jYW1sXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIEFD
X0NIRUNLX1RPT0woW09DQU1MREVQXSxbb2NhbWxkZXBdLFtub10pCisKKyAgIyBjaGVja2luZyBm
b3Igb2NhbWxta3RvcAorICBBQ19DSEVDS19UT09MKFtPQ0FNTE1LVE9QXSxbb2NhbWxta3RvcF0s
W25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGliCisgIEFDX0NIRUNLX1RPT0woW09D
QU1MTUtMSUJdLFtvY2FtbG1rbGliXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9j
CisgIEFDX0NIRUNLX1RPT0woW09DQU1MRE9DXSxbb2NhbWxkb2NdLFtub10pCisKKyAgIyBjaGVj
a2luZyBmb3Igb2NhbWxidWlsZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEJVSUxEXSxbb2NhbWxi
dWlsZF0sW25vXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxMRVhdLAorW2RubAor
ICAjIGNoZWNraW5nIGZvciBvY2FtbGxleAorICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWF0sW29j
YW1sbGV4XSxbbm9dKQorICBpZiB0ZXN0ICIkT0NBTUxMRVgiICE9ICJubyI7IHRoZW4KKyAgICBB
Q19DSEVDS19UT09MKFtPQ0FNTExFWERPVE9QVF0sW29jYW1sbGV4Lm9wdF0sW25vXSkKKyAgICBp
ZiB0ZXN0ICIkT0NBTUxMRVhET1RPUFQiICE9ICJubyI7IHRoZW4KKwlPQ0FNTExFWD0kT0NBTUxM
RVhET1RPUFQKKyAgICBmaQorICBmaQorICBBQ19TVUJTVChbT0NBTUxMRVhdKQorXSkKKworQUNf
REVGVU4oW0FDX1BST0dfT0NBTUxZQUNDXSwKK1tkbmwKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxZ
QUNDXSxbb2NhbWx5YWNjXSxbbm9dKQorICBBQ19TVUJTVChbT0NBTUxZQUNDXSkKK10pCisKKwor
QUNfREVGVU4oW0FDX1BST0dfQ0FNTFA0XSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19P
Q0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3IgY2FtbHA0CisgIEFDX0NIRUNLX1RPT0woW0NB
TUxQNF0sW2NhbWxwNF0sW25vXSkKKyAgaWYgdGVzdCAiJENBTUxQNCIgIT0gIm5vIjsgdGhlbgor
ICAgICBUTVBWRVJTSU9OPWAkQ0FNTFA0IC12IDI+JjF8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24g
KlwoLipcKSR8XDF8cCdgCisgICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVS
U0lPTiIgOyB0aGVuCisJQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1s
Y10pCisgICAgICAgIENBTUxQND1ubworICAgICBmaQorICBmaQorICBBQ19TVUJTVChbQ0FNTFA0
XSkKKworICAjIGNoZWNraW5nIGZvciBjb21wYW5pb24gdG9vbHMKKyAgQUNfQ0hFQ0tfVE9PTChb
Q0FNTFA0Qk9PVF0sW2NhbWxwNGJvb3RdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9d
LFtjYW1scDRvXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPRl0sW2NhbWxwNG9mXSxb
bm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPT0ZdLFtjYW1scDRvb2ZdLFtub10pCisgIEFD
X0NIRUNLX1RPT0woW0NBTUxQNE9SRl0sW2NhbWxwNG9yZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9P
TChbQ0FNTFA0UFJPRl0sW2NhbWxwNHByb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQ
NFJdLFtjYW1scDRyXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRSRl0sW2NhbWxwNHJm
XSxbbm9dKQorICBBQ19TVUJTVChbQ0FNTFA0Qk9PVF0pCisgIEFDX1NVQlNUKFtDQU1MUDRPXSkK
KyAgQUNfU1VCU1QoW0NBTUxQNE9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9PRl0pCisgIEFDX1NV
QlNUKFtDQU1MUDRPUkZdKQorICBBQ19TVUJTVChbQ0FNTFA0UFJPRl0pCisgIEFDX1NVQlNUKFtD
QU1MUDRSXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJGXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BS
T0dfRklORExJQl0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorCisg
ICMgY2hlY2tpbmcgZm9yIG9jYW1sZmluZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEZJTkRdLFtv
Y2FtbGZpbmRdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTEZJTkRdKQorXSkKKworCitkbmwgVGhh
bmtzIHRvIEppbSBNZXllcmluZyBmb3Igd29ya2luZyB0aGlzIG5leHQgYml0IG91dCBmb3IgdXMu
CitkbmwgWFhYIFdlIHNob3VsZCBkZWZpbmUgQVNfVFJfU0ggaWYgaXQncyBub3QgZGVmaW5lZCBh
bHJlYWR5CitkbmwgKGVnLiBmb3Igb2xkIGF1dG9jb25mKS4KK0FDX0RFRlVOKFtBQ19DSEVDS19P
Q0FNTF9QS0ddLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX0ZJTkRMSUJdKWRubAorCisg
IEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGZpbmRsaWIgcGFja2FnZSAkMV0pCisKKyAgdW5z
ZXQgZm91bmQKKyAgdW5zZXQgcGtnCisgIGZvdW5kPW5vCisgIGZvciBwa2cgaW4gJDEgJDIgOyBk
bworICAgIGlmICRPQ0FNTEZJTkQgcXVlcnkgJHBrZyA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0
aGVuCisgICAgICBBQ19NU0dfUkVTVUxUKFtmb3VuZF0pCisgICAgICBBU19UUl9TSChbT0NBTUxf
UEtHXyQxXSk9JHBrZworICAgICAgZm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRv
bmUKKyAgaWYgdGVzdCAiJGZvdW5kIiA9ICJubyIgOyB0aGVuCisgICAgQUNfTVNHX1JFU1VMVChb
bm90IGZvdW5kXSkKKyAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9bm8KKyAgZmkKKworICBB
Q19TVUJTVChBU19UUl9TSChbT0NBTUxfUEtHXyQxXSkpCitdKQorCisKK0FDX0RFRlVOKFtBQ19D
SEVDS19PQ0FNTF9NT0RVTEVdLAorW2RubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBt
b2R1bGUgJDJdKQorCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCitvcGVuICQzCitFT0YKKyAg
dW5zZXQgZm91bmQKKyAgZm9yICQxIGluICQkMSAkNCA7IGRvCisgICAgaWYgJE9DQU1MQyAtYyAt
SSAiJCQxIiBjb25mdGVzdC5tbCA+JjUgMj4mNSA7IHRoZW4KKyAgICAgIGZvdW5kPXllcworICAg
ICAgYnJlYWsKKyAgICBmaQorICBkb25lCisKKyAgaWYgdGVzdCAiJGZvdW5kIiA7IHRoZW4KKyAg
ICBBQ19NU0dfUkVTVUxUKFskJDFdKQorICBlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZv
dW5kXSkKKyAgICAkMT1ubworICBmaQorICBBQ19TVUJTVChbJDFdKQorXSkKKworCitkbmwgWFhY
IENyb3NzLWNvbXBpbGluZworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX1dPUkRfU0laRV0sCitb
ZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkco
W2ZvciBPQ2FtbCBjb21waWxlciB3b3JkIHNpemVdKQorICBjYXQgPiBjb25mdGVzdC5tbCA8PEVP
RgorICBwcmludF9lbmRsaW5lIChzdHJpbmdfb2ZfaW50IFN5cy53b3JkX3NpemUpCisgIEVPRgor
ICBPQ0FNTF9XT1JEX1NJWkU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VMVChb
JE9DQU1MX1dPUkRfU0laRV0pCisgIEFDX1NVQlNUKFtPQ0FNTF9XT1JEX1NJWkVdKQorXSkKKwor
QUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX09TX1RZUEVdLAorW2RubAorICBBQ19SRVFVSVJFKFtB
Q19QUk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtPQ2FtbCBTeXMub3NfdHlwZV0p
CisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJpbnRfc3RyaW5nKFN5cy5vc190eXBl
KTs7CitFT0YKKworICBPQ0FNTF9PU19UWVBFPWAkT0NBTUwgY29uZnRlc3QubWxgCisgIEFDX01T
R19SRVNVTFQoWyRPQ0FNTF9PU19UWVBFXSkKKyAgQUNfU1VCU1QoW09DQU1MX09TX1RZUEVdKQor
XSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L3BhdGhfb3Jf
ZmFpbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysg
Yi90b29scy9tNC9wYXRoX29yX2ZhaWwubTQJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAw
CkBAIC0wLDAgKzEsNiBAQAorQUNfREVGVU4oW0FYX1BBVEhfUFJPR19PUl9GQUlMXSwKK1tBQ19Q
QVRIX1BST0coWyQxXSwgWyQyXSwgW25vXSkKK2lmIHRlc3QgeCIkeyQxfSIgPT0geCJubyIgCit0
aGVuCisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmluZCAkMiwgcGxlYXNlIGluc3RhbGwg
JDJdKQorZmldKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvbTQv
cHl0aG9uX2RldmVsLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl9kZXZlbC5tNAlNb24gSmFuIDA5IDIxOjMzOjUyIDIw
MTIgKzAxMDAKQEAgLTAsMCArMSwxOCBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9ERVZF
TF0sCitbQUNfTVNHX0NIRUNLSU5HKFtmb3IgcHl0aG9uIGRldmVsXSkKKworYCRQWVRIT04gLWMg
JworaW1wb3J0IG9zLnBhdGgsIHN5cworZm9yIHAgaW4gc3lzLnBhdGg6CisgICAgaWYgb3MucGF0
aC5leGlzdHMocCArICIvY29uZmlnL01ha2VmaWxlIik6CisgICAgICAgIHN5cy5leGl0KDApCitz
eXMuZXhpdCgxKQorJyA+IC9kZXYvbnVsbCAyPiYxYAorCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0
aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUihbUHl0aG9uIGRl
dmVsIHBhY2thZ2Ugbm90IGZvdW5kXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQor
ZmldKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvbTQvcHl0aG9u
X3ZlcnNpb24ubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
KysrIGIvdG9vbHMvbTQvcHl0aG9uX3ZlcnNpb24ubTQJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMTIgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19QWVRIT05fVkVSU0lP
Tl0sCitbQUNfTVNHX0NIRUNLSU5HKFtmb3IgcHl0aG9uIHZlcnNpb24gPj0gJDEuJDIgXSkKK2Ak
UFlUSE9OIC1jICdpbXBvcnQgc3lzOyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoJDEs
ICQyKSIpKSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgcHl0aG9uX3ZlcnNpb249
YCRQWVRIT04gLVYgMj4mMWAKKyAgICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VS
Uk9SKAorICAgICAgICBbJHB5dGhvbl92ZXJzaW9uIGlzIHRvbyBvbGQsIG1pbmltdW0gcmVxdWly
ZWQgdmVyc2lvbiBpcyAkMS4kMl0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2Zp
XSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L3B5dGhvbl94
bWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
dG9vbHMvbTQvcHl0aG9uX3htbC5tNAlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAg
LTAsMCArMSwxMCBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9YTUxdLAorW0FDX01TR19D
SEVDS0lORyhbZm9yIHB5dGhvbiB4bWwuZG9tLm1pbmlkb21dKQorYCRQWVRIT04gLWMgJ2ltcG9y
dCB4bWwuZG9tLm1pbmlkb20nYAoraWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIEFDX01T
R19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kIHhtbC5kb20u
bWluaWRvbSBtb2R1bGVdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRp
ZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9tNC9zZXRfY2ZsYWdzX2xk
ZmxhZ3MubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIvdG9vbHMvbTQvc2V0X2NmbGFnc19sZGZsYWdzLm00CU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAx
MiArMDEwMApAQCAtMCwwICsxLDIwIEBACitBQ19ERUZVTihbQVhfU0VUX0ZMQUdTXSwKK1tmb3Ig
Y2ZsYWcgaW4gJFBSRVBFTkRfSU5DTFVERVMKK2RvCisgICAgUFJFUEVORF9DRkxBR1MrPSIgLUkk
Y2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRQUkVQRU5EX0xJQgorZG8KKyAgICBQUkVQRU5E
X0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQorZm9yIGNmbGFnIGluICRBUFBFTkRfSU5DTFVE
RVMKK2RvCisgICAgQVBQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcg
aW4gJEFQUEVORF9MSUIKK2RvCisgICAgQVBQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9u
ZQorQ0ZMQUdTPSIkUFJFUEVORF9DRkxBR1MgJENGTEFHUyAkQVBQRU5EX0NGTEFHUyIKK0xERkxB
R1M9IiRQUkVQRU5EX0xERkxBR1MgJExERkxBR1MgJEFQUEVORF9MREZMQUdTIl0pCisKZGlmZiAt
ciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L3VkZXYubTQKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdWRldi5t
NAlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwzMiBAQAorQUNfREVG
VU4oW0FYX0NIRUNLX1VERVZdLAorW2lmIHRlc3QgImB1bmFtZSAtc2AiID09ICJMaW51eCIKK3Ro
ZW4KKyAgICBBQ19QQVRIX1BST0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAgaWYg
dGVzdCB4IiR7VURFVkFETX0iID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9Q
Uk9HKFtVREVWSU5GT10sIFt1ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIke1VE
RVZJTkZPfSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9S
KAorICAgICAgICAgICAgICAgIFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBw
bGVhc2UgaW5zdGFsbCB1ZGV2XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVW
SU5GT30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9
YCR7VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYg
dGVzdCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtI
T1RQTFVHXSwgW2hvdHBsdWddLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIg
PT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlz
IHRvbyBvbGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisg
ICAgZmkKK2Vsc2UKKyAgICBBQ19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25v
XSkKKyAgICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAg
ICBBQ19NU0dfRVJST1IoW05vdCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5k
XSkKKyAgICBmaQorZmkKK10pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB2
ZXJzaW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisr
KyBiL3ZlcnNpb24uc2gJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAwCkBAIC0wLDAgKzEs
NCBAQAorIyEvYmluL3NoCitNQUpPUj1gZ3JlcCAiZXhwb3J0IFhFTl9WRVJTSU9OIiAkMSB8IHNl
ZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdyZXAgImV4cG9ydCBYRU5fU1VCVkVS
U0lPTiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK3ByaW50ZiAiJWQuJWQiICRN
QUpPUiAkTUlOT1IKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 10 11:54:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 11: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 1RkaHi-0005Of-3d; Tue, 10 Jan 2012 11:54: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 1RkaHg-0005OS-EA
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 11:54:33 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326196464!8521004!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	DATE_IN_PAST_12_24,RCVD_BY_IP,UPPERCASE_25_50
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9876 invoked from network); 10 Jan 2012 11:54:24 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 11:54:24 -0000
Received: by wico1 with SMTP id o1so9196774wic.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 03:54:24 -0800 (PST)
DKIM-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=kW/WcV2BoRJq6RtQ6Jy+YjEqLwllDBGqVod8j+WON7w=;
	b=u+Xbo3yeyUshjvdid3ZSnrVKfzetHWTJXLH6dACjvjwpnBvzbiA3+Q0YjVk5zDdw+z
	y2XtipUnKB+rDxoqM+z6xdoVxp5m1g7pMJjrRhI+V3/9LEyKHfQGcmV/cyA77JVmSvDx
	ft//DVvNG38NpSWc/38Ad9PvD+fpQ2jhaHY0A=
Received: by 10.180.94.102 with SMTP id db6mr3255081wib.0.1326196463874;
	Tue, 10 Jan 2012 03:54:23 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id em13sm1161142wid.7.2012.01.10.03.54.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 10 Jan 2012 03:54:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7d90cbdca2c26ba817f10a404737b25e85d56a7f
Message-Id: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 09 Jan 2012 21:37:07 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: Ian.Campbell@citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI2MTQxMjMyIC0zNjAwCiMgTm9kZSBJRCA3ZDkwY2JkY2Ey
YzI2YmE4MTdmMTBhNDA0NzM3YjI1ZTg1ZDU2YTdmCiMgUGFyZW50ICA0MDg2ZTQ4MTE1NDdkZGZm
YjlhNTNmYmYyZWZiNmMyZmE0MzZiNzBhCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwKY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KCkF1dG9jb25mLm1rIGlzIGluY2x1
ZGVkIGJ5IENvbmZpZy5taywgYW5kIGNvbnRhaW5zIG1vc3Qgb2YgdGhlCm9wdGlvbnMgcHJldmlv
dXNseSBkZWZpbmVkIGluIC5jb25maWcsIHRoYXQgY2FuIG5vdyBiZSBzZXQgcGFzc2luZwpwYXJh
bWV0ZXJzIG9yIGRlZmluaW5nIGVudmlyb25tZW50IHZhcmlhYmxlcyB3aGVuIGV4ZWN1dGluZyBj
b25maWd1cmUKc2NyaXB0LgoKY29uZmlnLmggaXMgc3RpbGwgbm90IHVzZWQgYW55d2hlcmUsIGFu
ZCBpcyBhdXRvbWF0aWNhbGx5IGNyZWF0ZWQgYnkKYXV0b2hlYWRlciwgYWx0b3VnaCB0aGlzIG1p
Z2ggY2hhbmdlIHdoZW4gd2Ugc3RhcnQgdG8gaW5jbHVkZSB0aGlzCmZpbGUuCgpKdXN0IGEgZmly
c3QgcmVsZWFzZSwgYW5kIHNpbmNlIElpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlwdCBJIGd1
ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxlYXNlIHJl
dmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjE6CgogKiBNb3ZlZCBhdXRvY29uZiBz
dHVmZiBpbnNpZGUgdG9vbHMgZm9sZGVyLgoKICogQWRkIE1ha2VmaWxlIHJ1bGVzIGZvciBjbGVh
bmluZy4KCiAqIFJlbW92ZWQgQXV0b21ha2UgZGVwZW5kZW5jeS4KCiAqIENyZWF0ZSBhdXRvZ2Vu
LnNoIHRvIGF1dG9tYXRpY2FsbHkgY3JlYXRlIGNvbmZpZ3VyZSBzY3JpcHQgd2hlbgogICBidWls
ZGluZyBmcm9tIHNvdXJjZSByZXBvc2l0b3J5LgoKICogQ2FjaGVkIHZhbHVlcyBvZiBvcHRpb25z
IHBhc3NlZCBmcm9tIGNvbW1hbmQgbGluZS4KCiAqIEFkZCBuZWNlc3NhcnkgaWdub3JlcyB0byAu
aGdpZ25vcmUuCgogKiBBZGRlZCBBdXRvY29uZiB0byB0aGUgbGlzdCBvZiBkZXBlbmRlbmNpZXMu
CgogKiBDaGFuZ2VkIGh5cGVuIHRvIHVuZGVyc2NvcmUgaW4gWE1MMiBhbmQgQ1VSTCB2YXJpYWJs
ZSBuYW1lcy4KCiAqIEFkZGVkIHNjcmlwdCB0byBnZXQgdmVyc2lvbiBmcm9tIHhlbi9NYWtlZmls
ZS4KCiAqIFNldCBPY2FtbCB0b29scyB0byBvcHRpb25hbC4KCiAqIEFkZGVkIHByb2NlZGVuY2Ug
b2YgbTQvb2NhbWwubTQuCgpTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBh
dUBlbnRlbC51cGMuZWR1PgoKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIC5o
Z2lnbm9yZQotLS0gYS8uaGdpZ25vcmUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisr
KyBiLy5oZ2lnbm9yZQlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTIyLDYgKzIy
LDcgQEAKIF5bXi9dKlwuYnoyJAogXlwuY29uZmlnJAogXlwucGMKK15jb25maWd1cmUkCiAoXnwv
KSh0YWdzfFRBR1MpJAogXmJ1aWxkLS4qJAogXmRpc3QvLiokCkBAIC0zMDgsNiArMzA5LDEwIEBA
CiBedG9vbHMvb2NhbWwvbGlicy94bC94ZW5saWdodFwubWwkCiBedG9vbHMvb2NhbWwvbGlicy94
bC94ZW5saWdodFwubWxpJAogXnRvb2xzL29jYW1sL3hlbnN0b3JlZC9veGVuc3RvcmVkJAorXnRv
b2xzL2F1dG9tNHRlLmNhY2hlJAorXnRvb2xzL2NvbmZpZy4qJAorXnRvb2xzL2NvbmZpZ3VyZSQK
K15jb25maWcvVG9vbHMubWskCiBeeGVuL1wuYmFubmVyLiokCiBeeGVuL0JMT0ckCiBeeGVuL1N5
c3RlbS5tYXAkCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiBDb25maWcubWsK
LS0tIGEvQ29uZmlnLm1rCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi9Db25m
aWcubWsJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAwCkBAIC03MCw5ICs3MCw2IEBAIEVY
VFJBX0lOQ0xVREVTICs9ICQoRVhUUkFfUFJFRklYKS9pbmNsdWQKIEVYVFJBX0xJQiArPSAkKEVY
VFJBX1BSRUZJWCkvJChMSUJMRUFGRElSKQogZW5kaWYKIAotQklTT04JPz0gYmlzb24KLUZMRVgJ
Pz0gZmxleAotCiBQWVRIT04gICAgICA/PSBweXRob24KIFBZVEhPTl9QUkVGSVhfQVJHID89IC0t
cHJlZml4PSIkKFBSRUZJWCkiCiAjIFRoZSBhYm92ZSByZXF1aXJlcyB0aGF0IFBSRUZJWCBjb250
YWlucyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJpYWJsZSBpcyBoZXJlCkBAIC0xNzUsMjIgKzE3Miw5
IEBAIENGTEFHUyArPSAkKGZvcmVhY2ggaSwgJChQUkVQRU5EX0lOQ0xVREUKIEFQUEVORF9MREZM
QUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRfQ0ZMQUdT
ICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9JTkNMVURFUyksIC1JJChpKSkKIAotQ0hFQ0tfTElC
ID0gJChFWFRSQV9MSUIpICQoUFJFUEVORF9MSUIpICQoQVBQRU5EX0xJQikKLUNIRUNLX0lOQ0xV
REVTID0gJChFWFRSQV9JTkNMVURFUykgJChQUkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVORF9JTkNM
VURFUykKLQogRU1CRURERURfRVhUUkFfQ0ZMQUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNrLXByb3Rl
Y3RvciAtZm5vLXN0YWNrLXByb3RlY3Rvci1hbGwKIEVNQkVEREVEX0VYVFJBX0NGTEFHUyArPSAt
Zm5vLWV4Y2VwdGlvbnMKIAotIyBFbmFibGUgWFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVs
dCwgRmxhc2spLgotWFNNX0VOQUJMRSA/PSBuCi1GTEFTS19FTkFCTEUgPz0gJChYU01fRU5BQkxF
KQotCi0jIERvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3duIHBy
b3RvY29sPwotIyBHSVQncyBwcm90b2NvbCBpcyBmYXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3aGVu
IGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxzCi0jIG1heSBibG9jayBpdCkuIFdlIG1ha2UgaXQg
dGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJVCByZXBvc2l0b3J5IGRvd25sb2FkcwotIyBmYWls
IG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJVF9IVFRQPXkgaW4geW91ciBlbnZpcm9ubWVudC4K
LUdJVF9IVFRQID89IG4KLQogWEVOX0VYVEZJTEVTX1VSTD1odHRwOi8veGVuYml0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1leHRmaWxlcwogIyBBbGwgdGhlIGZpbGVzIGF0IHRoYXQgbG9jYXRpb24gd2Vy
ZSBkb3dubG9hZGVkIGZyb20gZWxzZXdoZXJlIG9uCiAjIHRoZSBpbnRlcm5ldC4gIFRoZSBvcmln
aW5hbCBkb3dubG9hZCBVUkwgaXMgcHJlc2VydmVkIGFzIGEgY29tbWVudApAQCAtMjIyLDE3ICsy
MDYsMyBAQCBRRU1VX1RBRyA/PSBiYjM2ZDYzMmU0Y2FiZjQ3ODgyYWRmZjA3YTQ1CiAjIE5vdGUg
dGhhdCB1c2luZyBTZWFCSU9TIHJlcXVpcmVzIHRoZSB1c2UgdGhlIHVwc3RyZWFtIHFlbXUgYXMg
dGhlCiAjIGRldmljZSBtb2RlbC4KIFNFQUJJT1NfRElSID89IAotCi0jIE9wdGlvbmFsIGNvbXBv
bmVudHMKLVhFTlNUQVRfWEVOVE9QICAgICA/PSB5Ci1WVFBNX1RPT0xTICAgICAgICAgPz0gbgot
TElCWEVOQVBJX0JJTkRJTkdTID89IG4KLVBZVEhPTl9UT09MUyAgICAgICA/PSB5Ci1PQ0FNTF9U
T09MUyAgICAgICAgPz0geQotQ09ORklHX01JTklURVJNICAgID89IG4KLUNPTkZJR19MT01PVU5U
ICAgICA/PSBuCi1DT05GSUdfU1lTVEVNX0xJQkFJTyA/PSB5Ci0KLWlmZXEgKCQoT0NBTUxfVE9P
TFMpLHkpCi1PQ0FNTF9UT09MUyA6PSAkKHNoZWxsIG9jYW1sb3B0IC12ID4gL2Rldi9udWxsIDI+
JjEgJiYgZWNobyAieSIgfHwgZWNobyAibiIpCi1lbmRpZgpkaWZmIC1yIDQwODZlNDgxMTU0NyAt
ciA3ZDkwY2JkY2EyYzIgTWFrZWZpbGUKLS0tIGEvTWFrZWZpbGUJVGh1IEphbiAwNSAxNzoyNToy
MyAyMDEyICswMDAwCisrKyBiL01ha2VmaWxlCU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEw
MApAQCAtNDAsMTEgKzQwLDkgQEAgZGlzdDogREVTVERJUj0kKERJU1RESVIpL2luc3RhbGwKIGRp
c3Q6IGRpc3QteGVuIGRpc3Qta2VybmVscyBkaXN0LXRvb2xzIGRpc3Qtc3R1YmRvbSBkaXN0LWRv
Y3MgZGlzdC1taXNjCiAKIGRpc3QtbWlzYzoKLQkkKElOU1RBTExfRElSKSAkKERJU1RESVIpL2No
ZWNrCiAJJChJTlNUQUxMX0RBVEEpIC4vQ09QWUlORyAkKERJU1RESVIpCiAJJChJTlNUQUxMX0RB
VEEpIC4vUkVBRE1FICQoRElTVERJUikKIAkkKElOU1RBTExfUFJPRykgLi9pbnN0YWxsLnNoICQo
RElTVERJUikKLQkkKElOU1RBTExfUFJPRykgdG9vbHMvY2hlY2svY2hrIHRvb2xzL2NoZWNrL2No
ZWNrXyogdG9vbHMvY2hlY2svZnVuY3Muc2ggJChESVNURElSKS9jaGVjawogZGlzdC0lOiBERVNU
RElSPSQoRElTVERJUikvaW5zdGFsbAogZGlzdC0lOiBpbnN0YWxsLSUKIAlAOiAjIGRvIG5vdGhp
bmcKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIFJFQURNRQotLS0gYS9SRUFE
TUUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL1JFQURNRQlNb24gSmFuIDA5
IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTQxLDYgKzQxLDcgQEAgcHJvdmlkZWQgYnkgeW91ciBP
UyBkaXN0cmlidXRvcjoKICAgICAqIEdDQyB2My40IG9yIGxhdGVyCiAgICAgKiBHTlUgTWFrZQog
ICAgICogR05VIEJpbnV0aWxzCisgICAgKiBHTlUgQXV0b2NvbmYgdjIuNjcgb3IgbGF0ZXIKICAg
ICAqIERldmVsb3BtZW50IGluc3RhbGwgb2YgemxpYiAoZS5nLiwgemxpYi1kZXYpCiAgICAgKiBE
ZXZlbG9wbWVudCBpbnN0YWxsIG9mIFB5dGhvbiB2Mi4zIG9yIGxhdGVyIChlLmcuLCBweXRob24t
ZGV2KQogICAgICogRGV2ZWxvcG1lbnQgaW5zdGFsbCBvZiBjdXJzZXMgKGUuZy4sIGxpYm5jdXJz
ZXMtZGV2KQpAQCAtODcsOSArODgsMjEgQEAgMi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0
ZXZlciB5b3UgcwogMy4gRm9yIHRoZSB2ZXJ5IGZpcnN0IGJ1aWxkLCBvciBpZiB5b3Ugd2FudCB0
byBkZXN0cm95IGJ1aWxkIHRyZWVzLAogICAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgog
CisgICBJZiB5b3UgYXJlIGJ1aWxkaW5nIFhlbiBmcm9tIGEgcmVwb3NpdG9yeSAoZ2l0IG9yIG1l
cmN1cmlhbCkgeW91CisgICBtdXN0IHJ1bjoKKworICAgICMgLi9hdXRvZ2VuLnNoCisKKyAgIEJl
Zm9yZSBleGVjdXRpbmcgLi9jb25maWd1cmUgKHRoaXMgc3RlcCBjYW4gYmUgb21taXRlZCB3aGVu
CisgICBidWlsZGluZyBmcm9tIGEgZGlzdHJpYnV0aW9uIHBhY2thZ2UpLgorCisgICAgIyAuL2Nv
bmZpZ3VyZQogICAgICMgbWFrZSB3b3JsZAogICAgICMgbWFrZSBpbnN0YWxsCiAKKyAgIElmIHlv
dSB3YW50LCB5b3UgY2FuIHJ1biAuL2NvbmZpZ3VyZSAtLWhlbHAgdG8gc2VlIHRoZSBsaXN0IG9m
CisgICBvcHRpb25zIGF2YWlsYWJsZSBvcHRpb25zIHdoZW4gYnVpbGRpbmcgYW5kIGluc3RhbGxp
bmcgWGVuLgorCiAgICBUaGlzIHdpbGwgY3JlYXRlIGFuZCBpbnN0YWxsIG9udG8gdGhlIGxvY2Fs
IG1hY2hpbmUuIEl0IHdpbGwgYnVpbGQKICAgIHRoZSB4ZW4gYmluYXJ5ICh4ZW4uZ3opLCB0aGUg
dG9vbHMgYW5kIHRoZSBkb2N1bWVudGF0aW9uLgogCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdk
OTBjYmRjYTJjMiBhdXRvZ2VuLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCisrKyBiL2F1dG9nZW4uc2gJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAw
CkBAIC0wLDAgKzEsMTEgQEAKKyMhL2Jpbi9zaAorcm0gLXJmIGNvbmZpZ3VyZQorY2QgdG9vbHMK
K2F1dG9oZWFkZXIgJiYgYXV0b2NvbmYKK2lmIFsgIiQ/IiA9ICIwIiBdCit0aGVuCisgICAgY2Qg
Li4KKyAgICBlY2hvICIjIS9iaW4vc2giID4+IGNvbmZpZ3VyZQorICAgIGVjaG8gImNkIHRvb2xz
ICYmIC4vY29uZmlndXJlIFwkQCIgPj4gY29uZmlndXJlCisgICAgY2htb2QgK3ggY29uZmlndXJl
CitmaQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgY29uZmlnL1Rvb2xzLm1r
LmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL2Nv
bmZpZy9Ub29scy5tay5pbglNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTAsMCAr
MSw1MCBAQAorIyBQcmVmaXggYW5kIGluc3RhbGwgZm9sZGVyCitQUkVGSVggICAgICAgICAgICAg
IDo9IEBwcmVmaXhACitMSUJMRUFGRElSX3g4Nl82NCAgIDo9IEBMSUJfUEFUSEAKKworIyBBIGRl
YnVnIGJ1aWxkIG9mIHRvb2xzPworZGVidWcgICAgICAgICAgICAgICA6PSBAZGVidWdACisKKyMg
VG9vbHMgcGF0aAorQklTT04gICAgICAgICAgICAgICA6PSBAQklTT05ACitGTEVYICAgICAgICAg
ICAgICAgIDo9IEBGTEVYQAorUFlUSE9OICAgICAgICAgICAgICA6PSBAUFlUSE9OQAorUFlUSE9O
X1BBVEggICAgICAgICA6PSBAUFlUSE9OUEFUSEAKK1BFUkwgICAgICAgICAgICAgICAgOj0gQFBF
UkxACitCUkNUTCAgICAgICAgICAgICAgIDo9IEBCUkNUTEAKK0lQICAgICAgICAgICAgICAgICAg
Oj0gQElQQAorQ1VSTF9DT05GSUcgICAgICAgICA6PSBAQ1VSTEAKK1hNTDJfQ09ORklHICAgICAg
ICAgOj0gQFhNTEAKK0JBU0ggICAgICAgICAgICAgICAgOj0gQEJBU0hACitYR0VUVFRFWFQgICAg
ICAgICAgIDo9IEBYR0VUVEVYVEAKKworIyBFeHRyYSBmb2xkZXIgZm9yIGxpYnMvaW5jbHVkZXMK
K1BSRVBFTkRfSU5DTFVERVMgICAgOj0gQFBSRVBFTkRfSU5DTFVERVNACitQUkVQRU5EX0xJQiAg
ICAgICAgIDo9IEBQUkVQRU5EX0xJQkAKK0FQUEVORF9JTkNMVURFUyAgICAgOj0gQEFQUEVORF9J
TkNMVURFU0AKK0FQUEVORF9MSUIgICAgICAgICAgOj0gQEFQUEVORF9MSUJACisKKyMgRW5hYmxl
IFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKS4KK1hTTV9FTkFCTEUgICAg
ICAgICAgOj0gQHhzbUAKK0ZMQVNLX0VOQUJMRSAgICAgICAgOj0gQHhzbUAKKworIyBEb3dubG9h
ZCBHSVQgcmVwb3NpdG9yaWVzIHZpYSBIVFRQIG9yIEdJVCdzIG93biBwcm90b2NvbD8KKyMgR0lU
J3MgcHJvdG9jb2wgaXMgZmFzdGVyIGFuZCBtb3JlIHJvYnVzdCwgd2hlbiBpdCB3b3JrcyBhdCBh
bGwgKGZpcmV3YWxscworIyBtYXkgYmxvY2sgaXQpLiBXZSBtYWtlIGl0IHRoZSBkZWZhdWx0LCBi
dXQgaWYgeW91ciBHSVQgcmVwb3NpdG9yeSBkb3dubG9hZHMKKyMgZmFpbCBvciBoYW5nLCBwbGVh
c2Ugc3BlY2lmeSBHSVRfSFRUUD15IGluIHlvdXIgZW52aXJvbm1lbnQuCitHSVRfSFRUUCAgICAg
ICAgICAgIDo9IEBnaXRodHRwQAorCisjIE9wdGlvbmFsIGNvbXBvbmVudHMKK1hFTlNUQVRfWEVO
VE9QICAgICAgOj0gQG1vbml0b3JzQAorVlRQTV9UT09MUyAgICAgICAgICA6PSBAdnRwbUAKK0xJ
QlhFTkFQSV9CSU5ESU5HUyAgOj0gQHhhcGlACitQWVRIT05fVE9PTFMgICAgICAgIDo9IEBweXRo
b250b29sc0AKK09DQU1MX1RPT0xTICAgICAgICAgOj0gQG9jYW1sdG9vbHNACitDT05GSUdfTUlO
SVRFUk0gICAgIDo9IEBtaW5pdGVybUAKK0NPTkZJR19MT01PVU5UICAgICAgOj0gQGxvbW91bnRA
CisKKyNTeXN0ZW0gb3B0aW9ucworQ09ORklHX1NZU1RFTV9MSUJBSU86PSBAc3lzdGVtX2Fpb0AK
K0NPTkZJR19MSUJJQ09OViAgICAgOj0gQGxpYmljb252QAorQ09ORklHX0dDUllQVCAgICAgICA6
PSBAbGliZ2NyeXB0QAorQ09ORklHX0VYVDJGUyAgICAgICA6PSBAbGliZXh0MmZzQApkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMv
TWFrZWZpbGUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL01ha2Vm
aWxlCU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEwMApAQCAtNiw3ICs2LDYgQEAgU1VCRElS
Uy1saWJhaW8gOj0gbGliYWlvCiBlbmRpZgogCiBTVUJESVJTLXkgOj0KLVNVQkRJUlMteSArPSBj
aGVjawogU1VCRElSUy15ICs9IGluY2x1ZGUKIFNVQkRJUlMteSArPSBsaWJ4YwogU1VCRElSUy15
ICs9IGZsYXNrCkBAIC03MiwxMCArNzEsMTQgQEAgaW5zdGFsbDogc3ViZGlycy1pbnN0YWxsCiAK
IC5QSE9OWTogY2xlYW4KIGNsZWFuOiBzdWJkaXJzLWNsZWFuCisJcm0gLXJmIC4uL2NvbmZpZy9U
b29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0dXMgXAorICAgICAgICAgICAg
ICAgY29uZmlnLmNhY2hlCiAKIC5QSE9OWTogZGlzdGNsZWFuCiBkaXN0Y2xlYW46IHN1YmRpcnMt
ZGlzdGNsZWFuCiAJcm0gLXJmIGlvZW11LWRpciBpb2VtdS1yZW1vdGUKKwlybSAtcmYgLi4vY29u
ZmlnL1Rvb2xzLm1rIGNvbmZpZy5oIGNvbmZpZy5sb2cgY29uZmlnLnN0YXR1cyBcCisgICAgICAg
ICAgICAgICBjb25maWcuY2FjaGUgLi4vY29uZmlndXJlIGF1dG9tNHRlLmNhY2hlIGNvbmZpZy5o
LmluIGNvbmZpZ3VyZQogCiBpZm5lcSAoJChYRU5fQ09NUElMRV9BUkNIKSwkKFhFTl9UQVJHRVRf
QVJDSCkpCiBJT0VNVV9DT05GSUdVUkVfQ1JPU1MgPz0gLS1jcHU9JChYRU5fVEFSR0VUX0FSQ0gp
IFwKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL1J1bGVzLm1rCi0t
LSBhL3Rvb2xzL1J1bGVzLm1rCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi90
b29scy9SdWxlcy5tawlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTMsNiArMyw3
IEBACiAjIGBhbGwnIGlzIHRoZSBkZWZhdWx0IHRhcmdldAogYWxsOgogCitpbmNsdWRlICQoWEVO
X1JPT1QpL2NvbmZpZy9Ub29scy5tawogaW5jbHVkZSAkKFhFTl9ST09UKS9Db25maWcubWsKIAog
ZXhwb3J0IF9JTlNUQUxMIDo9ICQoSU5TVEFMTCkKQEAgLTgwLDggKzgxLDYgQEAgY2hlY2stJChD
T05GSUdfWDg2KSA9ICQoY2FsbCBjYy12ZXItY2hlYwogICAgICAgICAgICAgICAgICAgICAgICAg
IlhlbiByZXF1aXJlcyBhdCBsZWFzdCBnY2MtMy40IikKICQoZXZhbCAkKGNoZWNrLXkpKQogCi1f
UFlUSE9OX1BBVEggOj0gJChzaGVsbCB3aGljaCAkKFBZVEhPTikpCi1QWVRIT05fUEFUSCA/PSAk
KF9QWVRIT05fUEFUSCkKIElOU1RBTExfUFlUSE9OX1BST0cgPSBcCiAJJChYRU5fUk9PVCkvdG9v
bHMvcHl0aG9uL2luc3RhbGwtd3JhcCAiJChQWVRIT05fUEFUSCkiICQoSU5TVEFMTF9QUk9HKQog
CkBAIC0xMDksMyArMTA4LDcgQEAgc3ViZGlyLWFsbC0lIHN1YmRpci1jbGVhbi0lIHN1YmRpci1p
bnN0YQogCiBzdWJkaXItZGlzdGNsZWFuLSU6IC5waG9ueQogCSQoTUFLRSkgLUMgJCogY2xlYW4K
KworJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xzLm1rOgorCUBlY2hvICJZb3UgaGF2ZSB0byBydW4g
Li9jb25maWd1cmUgYmVmb3JlIGJ1aWxkaW5nIG9yIGluc3RhbGxpbmcgdGhlIHRvb2xzIgorCUBl
eGl0IDEKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL2Jsa3RhcC9k
cml2ZXJzL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVRodSBK
YW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi90b29scy9ibGt0YXAvZHJpdmVycy9NYWtl
ZmlsZQlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTEzLDcgKzEzLDcgQEAgQ0ZM
QUdTICAgKz0gJChDRkxBR1NfbGlieGVuc3RvcmUpCiBDRkxBR1MgICArPSAtSSAkKE1FTVNIUl9E
SVIpCiBDRkxBR1MgICArPSAtRF9HTlVfU09VUkNFCiAKLWlmZXEgKCQoc2hlbGwgLiAuL2NoZWNr
X2djcnlwdCAkKENDKSkseWVzKQoraWZlcSAoJENPTkZJR19HQ1JZUFQseSkKIENGTEFHUyArPSAt
RFVTRV9HQ1JZUFQKIENSWVBUX0xJQiA6PSAtbGdjcnlwdAogZWxzZQpkaWZmIC1yIDQwODZlNDgx
MTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvYmxrdGFwL2RyaXZlcnMvY2hlY2tfZ2NyeXB0Ci0t
LSBhL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL2NoZWNrX2djcnlwdAlUaHUgSmFuIDA1IDE3OjI1OjIz
IDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
QEAgLTEsMTQgKzAsMCBAQAotIyEvYmluL3NoCi0KLWNhdCA+IC5nY3J5cHQuYyA8PCBFT0YKLSNp
bmNsdWRlIDxnY3J5cHQuaD4KLWludCBtYWluKHZvaWQpIHsgcmV0dXJuIDA7IH0KLUVPRgotCi1p
ZiAkMSAtbyAuZ2NyeXB0IC5nY3J5cHQuYyAtbGdjcnlwdCAyPi9kZXYvbnVsbCA7IHRoZW4KLSAg
ZWNobyAieWVzIgotZWxzZQotICBlY2hvICJubyIKLWZpCi0KLXJtIC1mIC5nY3J5cHQqCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9jaGVjay9NYWtlZmlsZQotLS0g
YS90b29scy9jaGVjay9NYWtlZmlsZQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysr
IC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjYgKzAsMCBA
QAotWEVOX1JPT1QgPSAkKENVUkRJUikvLi4vLi4KLWluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMv
UnVsZXMubWsKLQotIyBFeHBvcnQgdGhlIG5lY2Vzc2FyeSBlbnZpcm9ubWVudCB2YXJpYWJsZXMg
Zm9yIHRoZSB0ZXN0cwotZXhwb3J0IFBZVEhPTgotZXhwb3J0IExJQlhFTkFQSV9CSU5ESU5HUwot
ZXhwb3J0IENIRUNLX0lOQ0xVREVTCi1leHBvcnQgQ0hFQ0tfTElCCi1leHBvcnQgQ09ORklHX1NZ
U1RFTV9MSUJBSU8KLQotLlBIT05ZOiBhbGwgaW5zdGFsbAotYWxsIGluc3RhbGw6IGNoZWNrLWJ1
aWxkCi0KLSMgQ2hlY2sgdGhpcyBtYWNoaW5lIGlzIE9LIGZvciBidWlsZGluZyBvbi4KLS5QSE9O
WTogY2hlY2stYnVpbGQKLWNoZWNrLWJ1aWxkOgotCS4vY2hrIGJ1aWxkCi0KLSMgQ2hlY2sgdGhp
cyBtYWNoaW5lIGlzIE9LIGZvciBpbnN0YWxsaW5nIG9uLgotLlBIT05ZOiBjaGVjay1pbnN0YWxs
Ci1jaGVjay1pbnN0YWxsOgotCS4vY2hrIGluc3RhbGwKLQotLlBIT05ZOiBjbGVhbgotY2xlYW46
Ci0JLi9jaGsgY2xlYW4KZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xz
L2NoZWNrL1JFQURNRQotLS0gYS90b29scy9jaGVjay9SRUFETUUJVGh1IEphbiAwNSAxNzoyNToy
MyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CkBAIC0xLDIwICswLDAgQEAKLUNoZWNrcyBmb3IgdGhlIHN1aXRhYmlsaXR5IG9mIGEgbWFjaGlu
ZSBmb3IgWGVuIGJ1aWxkIG9yIGluc3RhbGwuCi1UbyBjaGVjayBmb3IgYnVpbGQgc3VpdGFiaWxp
dHkgdXNlCi0KLSAgICAgICAgLi9jaGsgYnVpbGQKLQotVG8gY2hlY2sgZm9yIGluc3RhbGwgc3Vp
dGFiaWxpdHkgdXNlCi0KLSAgICAgICAgLi9jaGsgaW5zdGFsbAotCi1UaGUgY2hrIHNjcmlwdCB3
aWxsIHJ1biBjaGVja3MgaW4gdGhpcyBkaXJlY3RvcnkgYW5kIHByaW50Ci10aGUgb25lcyB0aGF0
IGZhaWxlZC4gSXQgcHJpbnRzIG5vdGhpbmcgaWYgY2hlY2tzIHN1Y2NlZWQuCi1UaGUgY2hrIHNj
cmlwdCBleGl0cyB3aXRoIDAgb24gc3VjY2VzcyBhbmQgMSBvbiBmYWlsdXJlLgotCi1UaGUgY2hr
IHNjcmlwdCBydW5zIGV4ZWN1dGFibGUgZmlsZXMgaW4gdGhpcyBkaXJlY3Rvcnkgd2hvc2UKLW5h
bWVzIGJlZ2luIHdpdGggJ2NoZWNrXycuIEZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0stQlVJTEQKLWFy
ZSBydW4gZm9yIHRoZSBidWlsZCBjaGVjaywgYW5kIGZpbGVzIGNvbnRhaW5pbmcgQ0hFQ0stSU5T
VEFMTAotYXJlIHJ1biBmb3IgdGhlIGluc3RhbGwgY2hlY2suCi0KLURldGFpbGVkIG91dHB1dCBm
cm9tIHRoZSBjaGVjayBzY3JpcHRzIGlzIGluIC5jaGtidWlsZCBmb3IgYnVpbGQKLWFuZCAuY2hr
aW5zdGFsbCBmb3IgaW5zdGFsbC4KXCBObyBuZXdsaW5lIGF0IGVuZCBvZiBmaWxlCmRpZmYgLXIg
NDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9jaGVjay9jaGVja19icmN0bAotLS0g
YS90b29scy9jaGVjay9jaGVja19icmN0bAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAK
KysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTMgKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNzLnNoCi0KLWNhc2Ug
JE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhhc19vcl9mYWlsIGJyY29uZmlnIDs7
Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBicmN0bCA7OwotKikKLQlmYWlsICJ1bmtub3duIE9TIiA7
OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2sv
Y2hlY2tfY3J5cHRvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19jcnlwdG9fbGliCVRodSBK
YW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMApAQCAtMSwxMSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQg
Q0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLUZyZWVCU0R8TmV0
QlNEfE9wZW5CU0QpCi0JZXhpdCAwIDs7Ci1lc2FjCi0KLWhhc19saWIgbGliY3J5cHRvLnNvIHx8
IGZhaWwgIm1pc3NpbmcgbGliY3J5cHRvLnNvIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkw
Y2JkY2EyYzIgdG9vbHMvY2hlY2svY2hlY2tfY3VybAotLS0gYS90b29scy9jaGVjay9jaGVja19j
dXJsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4g
MDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hF
Q0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyAiJExJQlhFTkFQ
SV9CSU5ESU5HUyIgIT0gInkiIF07IHRoZW4KLQllY2hvIC1uICJ1bnVzZWQsICIKLQlleGl0IDAK
LWZpCi0KLWhhc19vcl9mYWlsIGN1cmwtY29uZmlnCi1jdXJsX2xpYnM9YGN1cmwtY29uZmlnIC0t
bGlic2AgfHwgZmFpbCAiY3VybC1jb25maWcgLS1saWJzIGZhaWxlZCIKLXRlc3RfbGluayAkY3Vy
bF9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZvciBjdXJsIGFyZSBtaXNzaW5n
IgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2svY2hlY2tf
aXByb3V0ZQotLS0gYS90b29scy9jaGVjay9jaGVja19pcHJvdXRlCVRodSBKYW4gMDUgMTc6MjU6
MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAw
MApAQCAtMSwxNSArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVu
Y3Muc2gKLQotUEFUSD0vc2JpbjokUEFUSAotCi1jYXNlICRPUyBpbgotT3BlbkJTRHxOZXRCU0R8
RnJlZUJTRCkKLQloYXNfb3JfZmFpbCBpZmNvbmZpZyA7OwotTGludXgpCi0JaGFzX29yX2ZhaWwg
aXAgOzsKLSopCi0JZmFpbCAidW5rbm93biBPUyIgOzsKLWVzYWMKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19kZXZlbAotLS0gYS90
b29scy9jaGVjay9jaGVja19saWJhaW9fZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEx
ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYg
WyBYJHtDT05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQgMAot
ZmkKLWlmICEgaGFzX2hlYWRlciBsaWJhaW8uaCA7IHRoZW4KLSAgICBmYWlsICJjYW4ndCBmaW5k
IGxpYmFpbyBoZWFkZXJzLCBpbnN0YWxsIGxpYmFpbyBkZXZlbCBwYWNrYWdlIG9yIHNldCBDT05G
SUdfU1lTVEVNX0xJQkFJTz1uIgotZmkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNh
MmMyIHRvb2xzL2NoZWNrL2NoZWNrX2xpYmFpb19saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tf
bGliYWlvX2xpYglUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOSArMCwwIEBACi0jIS9iaW4vc2gK
LSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotaWYgWyBYJHtD
T05GSUdfU1lTVEVNX0xJQkFJT30gIT0gWCJ5IiBdIDsgdGhlbgotICAgIGV4aXQgMAotZmkKLWhh
c19saWIgbGliYWlvLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGliYWlvIgpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2svY2hlY2tfb3BlbnNzbF9kZXZlbAot
LS0gYS90b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gK
LQotaGFzX2hlYWRlciBvcGVuc3NsL21kNS5oIHx8IGZhaWwgIm1pc3Npbmcgb3BlbnNzbCBoZWFk
ZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2svY2hl
Y2tfcHl0aG9uCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbglUaHUgSmFuIDA1IDE3OjI1
OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTMgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RB
TEwKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhP
Tj1weXRob24KLWZpCi0KLSR7UFlUSE9OfSAtYyAnCi1pbXBvcnQgc3lzCi1zeXMuZXhpdChzeXMu
dmVyc2lvbl9pbmZvWzBdIDwgMiBvciBzeXMudmVyc2lvbl9pbmZvWzFdIDwgMykKLScgfHwgZmFp
bCAibmVlZCBweXRob24gdmVyc2lvbiA+PSAyLjMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdk
OTBjYmRjYTJjMiB0b29scy9jaGVjay9jaGVja19weXRob25fZGV2ZWwKLS0tIGEvdG9vbHMvY2hl
Y2svY2hlY2tfcHl0aG9uX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysg
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNyArMCwwIEBA
Ci0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWlmIHRlc3QgLXog
JHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZpCi1oYXNfb3JfZmFpbCAke1BZVEhP
Tn0KLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBvcy5wYXRoLCBzeXMKLWZvciBwIGluIHN5cy5w
YXRoOgotCWlmIG9zLnBhdGguZXhpc3RzKHAgKyAiL2NvbmZpZy9NYWtlZmlsZSIpOgotCQlzeXMu
ZXhpdCgwKQotc3lzLmV4aXQoMSkKLScgfHwgZmFpbCAiY2FuJ3QgZmluZCBweXRob24gZGV2ZWwg
ZmlsZXMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9jaGVjay9j
aGVja19weXRob25feG1sCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl94bWwJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxM
Ci0KLS4gLi9mdW5jcy5zaAotCi1pZiB0ZXN0IC16ICR7UFlUSE9OfTsgdGhlbgotICBQWVRIT049
cHl0aG9uCi1maQotaGFzX29yX2ZhaWwgJHtQWVRIT059Ci0KLSR7UFlUSE9OfSAtYyAnaW1wb3J0
IHhtbC5kb20ubWluaWRvbScgMj4vZGV2L251bGwgfHwgXAotZmFpbCAiY2FuJ3QgaW1wb3J0IHht
bC5kb20ubWluaWRvbSIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xz
L2NoZWNrL2NoZWNrX3VkZXYKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfdWRldglUaHUgSmFuIDA1
IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsMjIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQot
LiAuL2Z1bmNzLnNoCi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQotCWhh
c19vcl9mYWlsIHZuY29uZmlnCi0JOzsKLUxpbnV4KQotCWhhcyAvc2Jpbi91ZGV2YWRtICYmIFwK
LQkJdWRldnZlcj1gL3NiaW4vdWRldmFkbSBpbmZvIC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCi0J
WyAteiAiJHVkZXZ2ZXIiIF0gJiYgaGFzX29yX2ZhaWwgdWRldmluZm8gJiYgXAotCQl1ZGV2dmVy
PWB1ZGV2aW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAotCVsgIiR1ZGV2dmVyIiAtZ2UgNTkg
XSAyPi9kZXYvbnVsbCB8fCBcCi0JCWhhcyBob3RwbHVnIHx8IFwKLQkJZmFpbCAidWRldiBpcyB0
b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3IgbGF0ZXIiCi0JOzsKLSopCi0JZmFpbCAi
dW5rbm93biBPUyIKLQk7OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2Ey
YzIgdG9vbHMvY2hlY2svY2hlY2tfdXVpZF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja191
dWlkX2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRo
dSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw3ICswLDAgQEAKLSMhL2Jpbi9zaAot
IyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB1dWlkLmggfHwgXAot
aGFzX2hlYWRlciB1dWlkL3V1aWQuaCB8fCBmYWlsICJtaXNzaW5nIHV1aWQgaGVhZGVycyAocGFj
a2FnZSB1dWlkLWRldikiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29s
cy9jaGVjay9jaGVja194MTFfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeDExX2RldmVs
CVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1C
VUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciBYMTEva2V5c3ltZGVmLmggfHwgXAot
aGFzX2hlYWRlciAvdXNyL1gxMVI2L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLWhhc19o
ZWFkZXIgL3Vzci9YMTFSNy9pbmNsdWRlL1gxMS9rZXlzeW1kZWYuaCB8fCBcCi13YXJuaW5nICJj
YW4ndCBmaW5kIFgxMSBoZWFkZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2Ey
YzIgdG9vbHMvY2hlY2svY2hlY2tfeGdldHRleHQKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfeGdl
dHRleHQJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEph
biAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3NoCi0jIENI
RUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfb3JfZmFpbCB4Z2V0dGV4dApkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvY2hlY2svY2hlY2tfeG1sMgotLS0g
YS90b29scy9jaGVjay9jaGVja194bWwyCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAor
KysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNCArMCww
IEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Mu
c2gKLQotaWYgWyAhICIkTElCWEVOQVBJX0JJTkRJTkdTIiA9ICJ5IiBdCi10aGVuCi0gICAgZWNo
byAtbiAidW51c2VkLCAiCi0gICAgZXhpdCAwCi1maQotCi1oYXNfb3JfZmFpbCB4bWwyLWNvbmZp
ZwoteG1sMl9saWJzPWB4bWwyLWNvbmZpZyAtLWxpYnNgIHx8IGZhaWwgInhtbDItY29uZmlnIC0t
bGlicyBmYWlsZWQiCi10ZXN0X2xpbmsgJHhtbDJfbGlicyB8fCBmYWlsICJkZXBlbmRlbmN5IGxp
YnJhcmllcyBmb3IgeG1sMiBhcmUgbWlzc2luZyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5
MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2sv
Y2hlY2tfeWFqbF9kZXZlbAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsOCArMCwwIEBACi0jIS9i
aW4vc2gKLSMgQ0hFQ0stQlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgeWFqbC95
YWpsX3BhcnNlLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfcGFyc2UuaCIKLWhhc19o
ZWFkZXIgeWFqbC95YWpsX2dlbi5oIHx8IGZhaWwgImNhbid0IGZpbmQgeWFqbC95YWpsX2dlbi5o
IgotaGFzX2xpYiBsaWJ5YWpsLnNvIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFqbC5zbyIKZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoZWNrX3lhamxf
bGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3lhamxfbGliCVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSw2ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0K
LS4gLi9mdW5jcy5zaAotCi1oYXNfbGliIGxpYnlhamwuc28uMSB8fCBmYWlsICJjYW4ndCBmaW5k
IGxpYnlhamwuc28uMSB2ZXJzaW9uIDEiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRj
YTJjMiB0b29scy9jaGVjay9jaGVja196bGliX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNr
X3psaWJfZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAsMCBAQAotIyEvYmluL3No
Ci0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHpsaWIuaCB8fCBm
YWlsICJjYW4ndCBmaW5kIHpsaWIgaGVhZGVycyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5
MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoZWNrX3psaWJfbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2No
ZWNrX3psaWJfbGliCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMiArMCwwIEBACi0jIS9iaW4v
c2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAk
T1MgaW4KLUZyZWVCU0R8TmV0QlNEfE9wZW5CU0QpCi0JZXhpdCAwCi0JOzsKLWVzYWMKLQotaGFz
X2xpYiBsaWJ6LnNvIHx8IGZhaWwgImNhbid0IGZpbmQgemxpYiIKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL2NoZWNrL2NoawotLS0gYS90b29scy9jaGVjay9jaGsJ
VGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYzICswLDAgQEAKLSMhL2Jpbi9zaAotCi1mdW5jX3Vz
YWdlICgpCi17Ci0gICAgZWNobyAiVXNhZ2U6IgotICAgIGVjaG8gIgkkMCBbYnVpbGR8aW5zdGFs
bHxjbGVhbl0iCi0gICAgZWNobwotICAgIGVjaG8gIkNoZWNrIHN1aXRhYmlsaXR5IGZvciBYZW4g
YnVpbGQgb3IgaW5zdGFsbC4iCi0gICAgZWNobyAiRXhpdCB3aXRoIDAgaWYgT0ssIDEgaWYgbm90
LiIKLSAgICBlY2hvCi0gICAgZWNobyAiQ2FsbGluZyB3aXRoICdjbGVhbicgcmVtb3ZlcyBnZW5l
cmF0ZWQgZmlsZXMuIgotICAgIGV4aXQgMQotfQotCi1QQVRIPSRQQVRIOi9zYmluOi91c3Ivc2Jp
bgotT1M9YHVuYW1lIC1zYAotZXhwb3J0IFBBVEggT1MKLQotaWYgWyAiJE9TIiA9ICJTdW5PUyIg
XTsgdGhlbgotCWV4aXQgMAotZmkKLQotY2FzZSAkMSBpbgotICAgIGJ1aWxkKQotICAgICAgICBj
aGVjaz0iQ0hFQ0stQlVJTEQiCi0gICAgICAgIDs7Ci0gICAgaW5zdGFsbCkKLSAgICAgICAgY2hl
Y2s9IkNIRUNLLUlOU1RBTEwiCi0gICAgICAgIDs7Ci0gICAgY2xlYW4pCi0gICAgICAgIGV4aXQg
MAotICAgICAgICA7OwotICAgICopCi0gICAgICAgIGZ1bmNfdXNhZ2UKLSAgICAgICAgOzsKLWVz
YWMKLQotZmFpbGVkPTAKLQotZWNobyAiWGVuICR7Y2hlY2t9ICIgYGRhdGVgCi1mb3IgZiBpbiBj
aGVja18qIDsgZG8KLSAgICBjYXNlICRmIGluCi0gICAgICAgICp+KQotICAgICAgICAgICAgY29u
dGludWUKLSAgICAgICAgICAgIDs7Ci0gICAgICAgICopCi0gICAgICAgICAgICA7OwotICAgIGVz
YWMKLSAgICBpZiAhIFsgLXggJGYgXSA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQot
ICAgIGlmICEgZ3JlcCAtRnEgIiRjaGVjayIgJGYgOyB0aGVuCi0gICAgICAgIGNvbnRpbnVlCi0g
ICAgZmkKLSAgICBlY2hvIC1uICJDaGVja2luZyAkZjogIgotICAgIGlmIC4vJGYgMj4mMSA7IHRo
ZW4KLSAgICAgICAgZWNobyBPSwotICAgIGVsc2UKLSAgICAgICAgZmFpbGVkPTEKLSAgICBmaQot
ZG9uZQotCi1leGl0ICR7ZmFpbGVkfQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2Ey
YzIgdG9vbHMvY2hlY2svZnVuY3Muc2gKLS0tIGEvdG9vbHMvY2hlY2svZnVuY3Muc2gJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEwNiArMCwwIEBACi0jIGhhcyBpcyB0aGUgc2FtZSBhcyB3aGlj
aCwgZXhjZXB0IGl0IGhhbmRsZXMgY3Jvc3MgZW52aXJvbm1lbnRzCi1oYXMoKSB7Ci0JaWYgWyAt
eiAiJENST1NTX0NPTVBJTEUiIF07IHRoZW4KLQkJY29tbWFuZCB3aGljaCAiJEAiCi0JCXJldHVy
biAkPwotCWZpCi0KLQljaGVja19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0
byBwcmV2ZW50IHBvbGx1dGlvbiBvZiBjYWxsZXIncyBJRlMKLQkoCi0JSUZTPToKLQlmb3IgcCBp
biAkUEFUSDsgZG8KLQkJaWYgWyAteCAiJENST1NTX1NZU19ST09ULyRwLyQxIiBdOyB0aGVuCi0J
CQllY2hvICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiCi0JCQlyZXR1cm4gMAotCQlmaQotCWRvbmUK
LQlyZXR1cm4gMQotCSkKLX0KLQotaGFzX29yX2ZhaWwoKSB7Ci0JaGFzICIkMSIgPi9kZXYvbnVs
bCB8fCBmYWlsICJjYW4ndCBmaW5kICQxIgotfQotCi1oYXNfaGVhZGVyKCkgewotCWNoZWNrX3N5
c19yb290IHx8IHJldHVybiAxCi0KLQljYXNlICQxIGluCi0JCS8qKSA7OwotCQkqKQotCQlpZiBb
IC1yICIkQ1JPU1NfU1lTX1JPT1QvdXNyL2luY2x1ZGUvJDEiIF07IHRoZW4KLQkJCXJldHVybiAw
Ci0JCWZpCi0JCWZvciBwYXRoIGluICR7Q0hFQ0tfSU5DTFVERVN9OyBkbwotCQkJaWYgWyAtciAi
JENST1NTX1NZU19ST09UJHtwYXRofS8kMSIgXTsgdGhlbgotCQkJCXJldHVybiAwCi0JCQlmaQot
CQlkb25lCi0JCTs7Ci0JZXNhYwotCi0JcmV0dXJuIDEKLX0KLQotaGFzX2xpYigpIHsKLQljaGVj
a19zeXNfcm9vdCB8fCByZXR1cm4gMQotCi0JIyBzdWJzaGVsbCB0byBwcmV2ZW50IHBvbGx1dGlv
biBvZiBjYWxsZXIncyBlbnZpcm9ubWVudAotCSgKLQlQQVRIPS9zYmluOiRQQVRIICAgICAgICAj
IGZvciBsZGNvbmZpZwotCUxJQlJBUklFUz0iJENIRUNLX0xJQiAvdXNyL2xpYiIKLQotCSMgVGhp
cyByZWxhdGl2ZWx5IGNvbW1vbiBpbiBhIHN5cy1yb290OyBsaWJzIGFyZSBpbnN0YWxsZWQgYnV0
Ci0JIyBsZGNvbmZpZyBoYXNuJ3QgcnVuIHRoZXJlLCBzbyBsZGNvbmZpZyAtcCB3b24ndCB3b3Jr
LgotCWlmIFsgIiRPUyIgPSBMaW51eCAtYSAhIC1mICIkQ1JPU1NfU1lTX1JPT1QvZXRjL2xkLnNv
LmNhY2hlIiBdOyB0aGVuCi0JICAgIGVjaG8gIlBsZWFzZSBydW4gbGRjb25maWcgLXIgXCIkQ1JP
U1NfU1lTX1JPT1RcIiB0byBnZW5lcmF0ZSBsZC5zby5jYWNoZSIKLQkgICAgIyBmYWxsIHRocm91
Z2g7IGxkY29uZmlnIHRlc3QgYmVsb3cgc2hvdWxkIGZhaWwKLQlmaQotCWlmIFsgIiR7T1N9IiA9
ICJMaW51eCIgXTsgdGhlbgotCQlsZGNvbmZpZyAtcCAke0NST1NTX1NZU19ST09UKy1yICIkQ1JP
U1NfU1lTX1JPT1QifSB8IGdyZXAgLUZxICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlpZiBbICIk
e09TfSIgPSAiTmV0QlNEIiBdOyB0aGVuCi0JCWxzIC0xICR7TElCUkFSSUVTfSB8IGdyZXAgLUZx
ICIkMSIKLQkJcmV0dXJuICQ/Ci0JZmkKLQlyZXR1cm4gMQotCSkKLX0KLQotdGVzdF9saW5rKCkg
ewotCSMgc3Vic2hlbGwgdG8gdHJhcCByZW1vdmFsIG9mIHRtcGZpbGUKLQkoCi0JdW5zZXQgdG1w
ZmlsZQotCXRyYXAgJ3JtIC1mICIkdG1wZmlsZSI7IGV4aXQnIDAgMSAyIDE1Ci0JdG1wZmlsZT1g
bWt0ZW1wYCB8fCByZXR1cm4gMQotCWxkICIkQCIgLW8gIiR0bXBmaWxlIiA+L2Rldi9udWxsIDI+
JjEKLQlyZXR1cm4gJD8KLQkpCi19Ci0KLSMgdGhpcyBmdW5jdGlvbiBpcyB1c2VkIGNvbW1vbmx5
IGFib3ZlCi1jaGVja19zeXNfcm9vdCgpIHsKLQlbIC16ICIkQ1JPU1NfQ09NUElMRSIgXSAmJiBy
ZXR1cm4gMAotCWlmIFsgLXogIiRDUk9TU19TWVNfUk9PVCIgXTsgdGhlbgotCQllY2hvICJwbGVh
c2Ugc2V0IENST1NTX1NZU19ST09UIGluIHRoZSBlbnZpcm9ubWVudCIKLQkJcmV0dXJuIDEKLQlm
aQotCWlmIFsgISAtZCAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gIm5vIHN5cy1y
b290IGZvdW5kIGF0ICRDUk9TU19TWVNfUk9PVCIKLQkJcmV0dXJuIDEKLQlmaQotfQotCi13YXJu
aW5nKCkgewotCWVjaG8KLQllY2hvICIgKioqIGBiYXNlbmFtZSAiJDAiYCBGQUlMRUQkeyorOiAk
Kn0iCi19Ci0KLWZhaWwoKSB7Ci0JZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZB
SUxFRCR7Kis6ICQqfSIKLQlleGl0IDEKLX0KZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNi
ZGNhMmMyIHRvb2xzL2NvbmZpZ3VyZS5hYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWd1cmUuYWMJTW9uIEphbiAwOSAyMTozMzo1
MiAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTc5IEBACisjICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAtKi0gQXV0b2NvbmYgLSotCisjIFByb2Nlc3MgdGhpcyBm
aWxlIHdpdGggYXV0b2NvbmYgdG8gcHJvZHVjZSBhIGNvbmZpZ3VyZSBzY3JpcHQuCisKK0FDX1BS
RVJFUShbMi42N10pCitBQ19JTklUKFtYZW4gSHlwZXJ2aXNvcl0sbTRfZXN5c2NtZChbLi4vdmVy
c2lvbi5zaCAuLi94ZW4vTWFrZWZpbGVdKSwgW3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29t
XSkKK0FDX0NPTkZJR19TUkNESVIoW2xpYnhsL2xpYnhsLmNdKQorQUNfQ09ORklHX0ZJTEVTKFsu
Li9jb25maWcvVG9vbHMubWtdKQorQUNfQ09ORklHX0hFQURFUlMoW2NvbmZpZy5oXSkKK0FDX1BS
RUZJWF9ERUZBVUxUKFsvdXNyXSkKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxBR1MsIExJQlMs
IENQUEZMQUdTIG9yIENQUCBpcyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitBU19JRihbdGVz
dCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIl0sIFsKKyAgICBBQ19N
U0dfV0FSTigKK1tTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9y
IENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5E
X0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3Nz
aWJsZS5dKQorXSkKKworQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCisKKyMgTTQgTWFjcm8gaW5j
bHVkZXMKK200X2luY2x1ZGUoW200L2VuYWJsZV9mZWF0dXJlLm00XSkKK200X2luY2x1ZGUoW200
L2Rpc2FibGVfZmVhdHVyZS5tNF0pCittNF9pbmNsdWRlKFttNC9wYXRoX29yX2ZhaWwubTRdKQor
bTRfaW5jbHVkZShbbTQvcHl0aG9uX3htbC5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25fdmVy
c2lvbi5tNF0pCittNF9pbmNsdWRlKFttNC9weXRob25fZGV2ZWwubTRdKQorbTRfaW5jbHVkZShb
bTQvdWRldi5tNF0pCittNF9pbmNsdWRlKFttNC9vY2FtbC5tNF0pCittNF9pbmNsdWRlKFttNC9k
ZWZhdWx0X2xpYi5tNF0pCittNF9pbmNsdWRlKFttNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTRdKQor
CisjIEVuYWJsZS9kaXNhYmxlIG9wdGlvbnMKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeHNt
XSwKKyAgICBbRW5hYmxlIFhTTSBzZWN1cml0eSBtb2R1bGUgKGJ5IGRlZmF1bHQsIEZsYXNrKV0p
CitBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW2dpdGh0dHBdLCBbRG93bmxvYWQgR0lUIHJlcG9z
aXRvcmllcyB2aWEgSFRUUF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFttb25pdG9yc10s
CisgICAgW0Rpc2FibGUgeGVuc3RhdCBhbmQgeGVudG9wIG1vbml0b3JpbmcgdG9vbHNdKQorQVhf
QVJHX0VOQUJMRV9BTkRfRVhQT1JUKFt2dHBtXSwgW0VuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxh
dGZvcm0gTW9kdWxlXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbeGFwaV0sIFtFbmFibGUg
WGVuIEFQSSBCaW5kaW5nc10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtweXRob250b29s
c10sIFtEaXNhYmxlIFB5dGhvbiB0b29sc10pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtv
Y2FtbHRvb2xzXSwgW0Rpc2FibGUgT2NhbWwgdG9vbHNdKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQ
T1JUKFttaW5pdGVybV0sIFtFbmFibGUgbWluaXRlcm1dKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQ
T1JUKFtsb21vdW50XSwgW0VuYWJsZSBsb21vdW50XSkKK0FYX0FSR19ESVNBQkxFX0FORF9FWFBP
UlQoW2RlYnVnXSwgW0Rpc2FibGUgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29sc10pCisKK0FD
X0FSR19WQVIoW1BSRVBFTkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVy
cyB0byBwcmVwZW5kIHRvIENGTEFHUyAod2l0aG91dCAtSSldKQorQUNfQVJHX1ZBUihbUFJFUEVO
RF9MSUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxB
R1MgKHdpdGhvdXQgLUwpXSkKK0FDX0FSR19WQVIoW0FQUEVORF9JTkNMVURFU10sCisgICAgW0xp
c3Qgb2YgaW5jbHVkZSBmb2xkZXJzIHRvIGFwcGVuZCB0byBDRkxBR1MgKHdpdGhvdXQgLUkpXSkK
K0FDX0FSR19WQVIoW0FQUEVORF9MSUJdLAorICAgIFtMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0
byBhcHBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAtTCldKQorCitBWF9TRVRfRkxBR1MKKworQUNf
QVJHX1ZBUihbUFlUSE9OXSwgW1BhdGggdG8gdGhlIFB5dGhvbiBwYXJzZXJdKQorQUNfQVJHX1ZB
UihbUEVSTF0sIFtQYXRoIHRvIFBlcmwgcGFyc2VyXSkKK0FDX0FSR19WQVIoW0JSQ1RMXSwgW1Bh
dGggdG8gYnJjdGwgdG9vbF0pCitBQ19BUkdfVkFSKFtJUF0sIFtQYXRoIHRvIGlwIHRvb2xdKQor
QUNfQVJHX1ZBUihbQklTT05dLCBbUGF0aCB0byBCaXNvbiBwYXJzZXIgZ2VuZXJhdG9yXSkKK0FD
X0FSR19WQVIoW0ZMRVhdLCBbUGF0aCB0byBGbGV4IGxleGljYWwgYW5hbHlzZXIgZ2VuZXJhdG9y
XSkKK0FDX0FSR19WQVIoW0NVUkxdLCBbUGF0aCB0byBjdXJsLWNvbmZpZyB0b29sXSkKK0FDX0FS
R19WQVIoW1hNTF0sIFtQYXRoIHRvIHhtbDItY29uZmlnIHRvb2xdKQorQUNfQVJHX1ZBUihbQkFT
SF0sIFtQYXRoIHRvIGJhc2ggc2hlbGxdKQorQUNfQVJHX1ZBUihbWEdFVFRFWFRdLCBbUGF0aCB0
byB4Z2V0dHRleHQgdG9vbF0pCisKKyMgQ2hlY2tzIGZvciBwcm9ncmFtcy4KK0FDX1BST0dfU0VE
CitBQ19QUk9HX0NDCitBQ19QUk9HX0lOU1RBTEwKK0FDX1BST0dfTE5fUworQUNfUFJPR19NQUtF
X1NFVAorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BFUkxdLCBbcGVybF0pCitBWF9QQVRIX1BST0df
T1JfRkFJTChbQlJDVExdLCBbYnJjdGxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0lQXSwgW2lw
XSkKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtCSVNPTl0sIFtiaXNvbl0pCitBWF9QQVRIX1BST0df
T1JfRkFJTChbRkxFWF0sIFtmbGV4XSkKK0FTX0lGKFt0ZXN0ICJ4JHhhcGkiID0gInh5Il0sIFsK
KyAgICBBWF9QQVRIX1BST0dfT1JfRkFJTChbQ1VSTF0sIFtjdXJsLWNvbmZpZ10pCisgICAgQVhf
UEFUSF9QUk9HX09SX0ZBSUwoW1hNTF0sIFt4bWwyLWNvbmZpZ10pCitdKQorQVNfSUYoW3Rlc3Qg
Ingkb2NhbWx0b29scyIgPSAieHkiXSwgWworICAgIEFDX1BST0dfT0NBTUwKKyAgICBBU19JRihb
dGVzdCAieCRPQ0FNTEMiID0gInhubyJdLCBbCisgICAgICBvY2FtbHRvb2xzPSJuIgorICAgIF0p
CitdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JBU0hdLCBbYmFzaF0pCitBU19JRihbdGVzdCAi
eCRweXRob250b29scyIgPSAieHkiXSwgWworICAgIEFTX0lGKFtlY2hvICIkUFlUSE9OIiB8IGdy
ZXAgLXEgIl4vIl0sIFsKKyAgICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhP
Tj1gYmFzZW5hbWUgJFBZVEhPTlBBVEhgCisgICAgXSxbdGVzdCAteiAiJFBZVEhPTiJdLCBbUFlU
SE9OPSJweXRob24iXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtQWVRIT04gc3BlY2lmaWVkLCBidXQg
aXMgbm90IGFuIGFic29sdXRlIHBhdGhdKV0pCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW1BZ
VEhPTlBBVEhdLCBbJFBZVEhPTl0pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1ZFUlNJT04oWzJdLCBb
M10pCisgICAgQVhfQ0hFQ0tfUFlUSE9OX1hNTCgpCisgICAgQVhfQ0hFQ0tfUFlUSE9OX0RFVkVM
KCkKK10pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbWEdFVFRFWFRdLCBbeGdldHRleHRdKQorQVhf
Q0hFQ0tfVURFVihbNTldKQorCisjIENoZWNrIGxpYnJhcnkgcGF0aAorQVhfREVGQVVMVF9MSUIK
KworIyBDaGVja3MgZm9yIGxpYnJhcmllcy4KK0FDX0NIRUNLX0xJQihbYWlvXSwgW2lvX3NldHVw
XSwgW3N5c3RlbV9haW89InkiXSwgW3N5c3RlbV9haW89Im4iXSkKK0FDX1NVQlNUKHN5c3RlbV9h
aW8pCitBQ19DSEVDS19MSUIoW2NyeXB0b10sIFtNRDVdLCBbXSwgW0FDX01TR19FUlJPUihbQ291
bGQgbm90IGZpbmQgbGliY3J5cHRvXSldKQorQUNfQ0hFQ0tfTElCKFtleHQyZnNdLCBbZXh0MmZz
X29wZW4yXSwgW2xpYmV4dDJmcz0ieSJdLCBbbGliZXh0MmZzPSJuIl0pCitBQ19TVUJTVChsaWJl
eHQyZnMpCitBQ19DSEVDS19MSUIoW2djcnlwdF0sIFtnY3J5X21kX2hhc2hfYnVmZmVyXSwgW2xp
YmdjcnlwdD0ieSJdLCBbbGliZ2NyeXB0PSJuIl0pCitBQ19TVUJTVChsaWJnY3J5cHQpCitBQ19D
SEVDS19MSUIoW3B0aHJlYWRdLCBbcHRocmVhZF9jcmVhdGVdLCBbXSAsCisgICAgW0FDX01TR19F
UlJPUihbQ291bGQgbm90IGZpbmQgbGlicHRocmVhZF0pXSkKK0FDX0NIRUNLX0xJQihbcnRdLCBb
Y2xvY2tfZ2V0dGltZV0pCitBQ19DSEVDS19MSUIoW3V1aWRdLCBbdXVpZF9jbGVhcl0sIFtdLAor
ICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBmaW5kIGxpYnV1aWRdKV0pCitBQ19DSEVDS19M
SUIoW3lhamxdLCBbeWFqbF9hbGxvY10sIFtdLAorICAgIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5v
dCBmaW5kIHlhamxdKV0pCitBQ19DSEVDS19MSUIoW3pdLCBbZGVmbGF0ZUNvcHldLCBbXSwgW0FD
X01TR19FUlJPUihbQ291bGQgbm90IGZpbmQgemxpYl0pXSkKK0FDX0NIRUNLX0xJQihbaWNvbnZd
LCBbbGliaWNvbnZfb3Blbl0sIFtsaWJpY29udj0ieSJdLCBbbGliaWNvbnY9Im4iXSkKK0FDX1NV
QlNUKGxpYmljb252KQorCisjIEF1dG9zY2FuIHN0dWZmIChleGNlcHQgZm9yIHlhamwveWFqbF92
ZXJzaW9uLmggY2hlY2spCisjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgorQUNfRlVOQ19BTExP
Q0EKK0FDX0NIRUNLX0hFQURFUlMoWyBcCisgICAgICAgICAgICAgICAgYXJwYS9pbmV0LmggZmNu
dGwuaCBpbnR0eXBlcy5oIGxpYmludGwuaCBsaW1pdHMuaCBtYWxsb2MuaCBcCisgICAgICAgICAg
ICAgICAgbmV0ZGIuaCBuZXRpbmV0L2luLmggc3RkZGVmLmggc3RkaW50Lmggc3RkbGliLmggc3Ry
aW5nLmggXAorICAgICAgICAgICAgICAgIHN0cmluZ3MuaCBzeXMvZmlsZS5oIHN5cy9pb2N0bC5o
IHN5cy9tb3VudC5oIHN5cy9wYXJhbS5oIFwKKyAgICAgICAgICAgICAgICBzeXMvc29ja2V0Lmgg
c3lzL3N0YXR2ZnMuaCBzeXMvdGltZS5oIHN5c2xvZy5oIHRlcm1pb3MuaCBcCisgICAgICAgICAg
ICAgICAgdW5pc3RkLmggeWFqbC95YWpsX3ZlcnNpb24uaCBcCisgICAgICAgICAgICAgICAgXSkK
KworIyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFj
dGVyaXN0aWNzLgorQUNfSEVBREVSX1NUREJPT0wKK0FDX1RZUEVfVUlEX1QKK0FDX0NfSU5MSU5F
CitBQ19UWVBFX0lOVDE2X1QKK0FDX1RZUEVfSU5UMzJfVAorQUNfVFlQRV9JTlQ2NF9UCitBQ19U
WVBFX0lOVDhfVAorQUNfVFlQRV9NT0RFX1QKK0FDX1RZUEVfT0ZGX1QKK0FDX1RZUEVfUElEX1QK
K0FDX0NfUkVTVFJJQ1QKK0FDX1RZUEVfU0laRV9UCitBQ19UWVBFX1NTSVpFX1QKK0FDX0NIRUNL
X01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X2Jsa3NpemVdKQorQUNfU1RSVUNUX1NUX0JMT0NLUwor
QUNfQ0hFQ0tfTUVNQkVSUyhbc3RydWN0IHN0YXQuc3RfcmRldl0pCitBQ19UWVBFX1VJTlQxNl9U
CitBQ19UWVBFX1VJTlQzMl9UCitBQ19UWVBFX1VJTlQ2NF9UCitBQ19UWVBFX1VJTlQ4X1QKK0FD
X0NIRUNLX1RZUEVTKFtwdHJkaWZmX3RdKQorCisjIENoZWNrcyBmb3IgbGlicmFyeSBmdW5jdGlv
bnMuCitBQ19GVU5DX0VSUk9SX0FUX0xJTkUKK0FDX0ZVTkNfRk9SSworQUNfRlVOQ19GU0VFS08K
K0FDX0ZVTkNfTFNUQVRfRk9MTE9XU19TTEFTSEVEX1NZTUxJTksKK0FDX0hFQURFUl9NQUpPUgor
QUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNTKFsgXAorICAgICAgICAgICAgICAgIGFsYXJt
IGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5jIGZ0cnVuY2F0ZSBcCisg
ICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9zdG5hbWUgZ2V0cGFnZXNp
emUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250b2EgaXNhc2NpaSBsb2Nh
bHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAgICAgICAgICAgICAgIG1r
ZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRpciBzZWxlY3Qgc2V0ZW52
IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJjaHIgc3RyY3NwbiBzdHJk
dXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3RycGJyayBzdHJyY2hyIHN0
cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQgXAorICAgICAgICAgICAg
ICAgIHVuYW1lIFwKKyAgICAgICAgICAgICAgICBdKQorCitBQ19PVVRQVVQoKQpkaWZmIC1yIDQw
ODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZp
bGUKLS0tIGEvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJVGh1IEphbiAwNSAxNzoy
NToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4L3hnL01ha2VmaWxlCU1v
biBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEwMApAQCAtMjEsNyArMjEsNiBAQCB4Z19hbGwuYTog
JChYR19PQkpTKSBNYWtlZmlsZSAkKFhHX0hEUlMpCiAjCSQoQ0MpIC1tMzIgLWMgLW8gJEAgJF4K
IAogeGVuLWhlYWRlcnM6Ci0JJChNQUtFKSAtQyAuLi8uLi8uLi9jaGVjayAKIAkkKE1BS0UpIC1D
IC4uLy4uLy4uL2luY2x1ZGUKIAogIyB4Z19tYWluLm86IHhnX21haW4uYyBNYWtlZmlsZSAkKFhH
X0hEUlMpCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9saWJmc2lt
YWdlL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJVGh1IEphbiAwNSAx
NzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2xpYmZzaW1hZ2UvTWFrZWZpbGUJTW9uIEph
biAwOSAyMTozMzo1MiAyMDEyICswMTAwCkBAIC0yLDcgKzIsMTEgQEAgWEVOX1JPT1QgPSAkKENV
UkRJUikvLi4vLi4KIGluY2x1ZGUgJChYRU5fUk9PVCkvdG9vbHMvUnVsZXMubWsKIAogU1VCRElS
Uy15ID0gY29tbW9uIHVmcyByZWlzZXJmcyBpc285NjYwIGZhdCB6ZnMgeGZzCi1TVUJESVJTLXkg
Kz0gJChzaGVsbCBlbnYgQ0M9IiQoQ0MpIiAuL2NoZWNrLWxpYmV4dDJmcykKK2lmZXEgKCQoQ09O
RklHX0VYVDJGUyksIHkpCisgICAgU1VCRElSUy15ICs9IGV4dDJmcy1saWIKK2Vsc2UKKyAgICBT
VUJESVJTLXkgKz0gZXh0MmZzCitlbmRpZgogCiAuUEhPTlk6IGFsbCBjbGVhbiBpbnN0YWxsCiBh
bGwgY2xlYW4gaW5zdGFsbDogJTogc3ViZGlycy0lCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdk
OTBjYmRjYTJjMiB0b29scy9saWJmc2ltYWdlL2NoZWNrLWxpYmV4dDJmcwotLS0gYS90b29scy9s
aWJmc2ltYWdlL2NoZWNrLWxpYmV4dDJmcwlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAK
KysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjEgKzAs
MCBAQAotIyEvYmluL3NoCi0KLWNhdCA+ZXh0Mi10ZXN0LmMgPDxFT0YKLSNpbmNsdWRlIDxleHQy
ZnMvZXh0MmZzLmg+Ci0KLWludCBtYWluKCkKLXsKLQlleHQyZnNfb3BlbjI7Ci19Ci1FT0YKLQot
JHtDQy1nY2N9IC1vIGV4dDItdGVzdCBleHQyLXRlc3QuYyAtbGV4dDJmcyA+L2Rldi9udWxsIDI+
JjEKLWlmIFsgJD8gPSAwIF07IHRoZW4KLQllY2hvIGV4dDJmcy1saWIKLWVsc2UKLQllY2hvIGV4
dDJmcwotZmkKLQotcm0gLWYgZXh0Mi10ZXN0IGV4dDItdGVzdC5jCi0KLWV4aXQgMApkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvbGlieGVuL01ha2VmaWxlCi0tLSBh
L3Rvb2xzL2xpYnhlbi9NYWtlZmlsZQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysr
IGIvdG9vbHMvbGlieGVuL01ha2VmaWxlCU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEwMApA
QCAtMjIsMTIgKzIyLDEyIEBAIE1BSk9SID0gMS4wCiBNSU5PUiA9IDAKIAogQ0ZMQUdTICs9IC1J
aW5jbHVkZSAgICAgICAgICAgICAgICAgICAgIFwKLSAgICAgICAgICAkKHNoZWxsIHhtbDItY29u
ZmlnIC0tY2ZsYWdzKSBcCi0gICAgICAgICAgJChzaGVsbCBjdXJsLWNvbmZpZyAtLWNmbGFncykg
XAorICAgICAgICAgICQoc2hlbGwgJChYTUwyX0NPTkZJRykgLS1jZmxhZ3MpIFwKKyAgICAgICAg
ICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tY2ZsYWdzKSBcCiAgICAgICAgICAgLWZQSUMKIAot
TERGTEFHUyArPSAkKHNoZWxsIHhtbDItY29uZmlnIC0tbGlicykgXAotICAgICAgICAgICAkKHNo
ZWxsIGN1cmwtY29uZmlnIC0tbGlicykKK0xERkxBR1MgKz0gJChzaGVsbCAkKFhNTDJfQ09ORklH
KSAtLWxpYnMpIFwKKyAgICAgICAgICAgJChzaGVsbCAkKENVUkxfQ09ORklHKSAtLWxpYnMpCiAK
IExJQlhFTkFQSV9IRFJTID0gJCh3aWxkY2FyZCBpbmNsdWRlL3hlbi9hcGkvKi5oKSBpbmNsdWRl
L3hlbi9hcGkveGVuX2FsbC5oCiBMSUJYRU5BUElfT0JKUyA9ICQocGF0c3Vic3QgJS5jLCAlLm8s
ICQod2lsZGNhcmQgc3JjLyouYykpCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJj
MiB0b29scy9tNC9kZWZhdWx0X2xpYi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6
MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC9kZWZhdWx0X2xpYi5tNAlNb24gSmFuIDA5IDIx
OjMzOjUyIDIwMTIgKzAxMDAKQEAgLTAsMCArMSw4IEBACitBQ19ERUZVTihbQVhfREVGQVVMVF9M
SUJdLAorW0FTX0lGKFt0ZXN0IC1kICIkcHJlZml4L2xpYjY0Il0sIFsKKyAgICBMSUJfUEFUSD0i
bGliNjQiCitdLFsKKyAgICBMSUJfUEFUSD0ibGliIgorXSkKK0FDX1NVQlNUKExJQl9QQVRIKV0p
CisKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L2Rpc2FibGVf
ZmVhdHVyZS5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi90b29scy9tNC9kaXNhYmxlX2ZlYXR1cmUubTQJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FDX0RFRlVOKFtBWF9BUkdfRElTQUJMRV9BTkRfRVhQ
T1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0sCisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZGlzYWJs
ZS0kMV0sIFskMl0pKQorCitBU19JRihbdGVzdCAieCRlbmFibGVfJDEiID0gInhubyJdLCBbCisg
ICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAieCRlbmFibGVfJDEiID0gInh5ZXMiXSwgWworICAg
IGF4X2N2XyQxPSJ5IgorXSwgW3Rlc3QgLXogJGF4X2N2XyQxXSwgWworICAgIGF4X2N2XyQxPSJ5
IgorXSkKKyQxPSRheF9jdl8kMQorQUNfU1VCU1QoJDEpXSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcg
LXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L2VuYWJsZV9mZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L2VuYWJsZV9mZWF0
dXJlLm00CU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAxMiArMDEwMApAQCAtMCwwICsxLDEzIEBACitB
Q19ERUZVTihbQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUXSwKK1tBQ19BUkdfRU5BQkxFKFskMV0s
CisgICAgQVNfSEVMUF9TVFJJTkcoWy0tZW5hYmxlLSQxXSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0
ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAgYXhfY3ZfJDE9InkiCitdLCBbdGVzdCAi
eCRlbmFibGVfJDEiID0gInhubyJdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdLCBbdGVzdCAteiAk
YXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Im4iCitdKQorJDE9JGF4X2N2XyQxCitBQ19TVUJT
VCgkMSldKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvbTQvb2Nh
bWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
dG9vbHMvbTQvb2NhbWwubTQJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAwCkBAIC0wLDAg
KzEsMjQxIEBACitkbmwgYXV0b2NvbmYgbWFjcm9zIGZvciBPQ2FtbAorZG5sIGZyb20gaHR0cDov
L2ZvcmdlLm9jYW1sY29yZS5vcmcvCitkbmwKK2RubCBDb3B5cmlnaHQgwqkgMjAwOSAgICAgIFJp
Y2hhcmQgVy5NLiBKb25lcworZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgU3RlZmFubyBaYWNj
aGlyb2xpCitkbmwgQ29weXJpZ2h0IMKpIDIwMDAtMjAwNSBPbGl2aWVyIEFuZHJpZXUKK2RubCBD
b3B5cmlnaHQgwqkgMjAwMC0yMDA1IEplYW4tQ2hyaXN0b3BoZSBGaWxsacOidHJlCitkbmwgQ29w
eXJpZ2h0IMKpIDIwMDAtMjAwNSBHZW9yZ2VzIE1hcmlhbm8KK2RubAorZG5sIEZvciBkb2N1bWVu
dGF0aW9uLCBwbGVhc2UgcmVhZCB0aGUgb2NhbWwubTQgbWFuIHBhZ2UuCisKK0FDX0RFRlVOKFtB
Q19QUk9HX09DQU1MXSwKK1tkbmwKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxjCisgIEFDX0NIRUNL
X1RPT0woW09DQU1MQ10sW29jYW1sY10sW25vXSkKKworICBpZiB0ZXN0ICIkT0NBTUxDIiAhPSAi
bm8iOyB0aGVuCisgICAgIE9DQU1MVkVSU0lPTj1gJE9DQU1MQyAtdiB8IHNlZCAtbiAtZSAnc3wu
KnZlcnNpb24qICpcKC4qXCkkfFwxfHAnYAorICAgICBBQ19NU0dfUkVTVUxUKFtPQ2FtbCB2ZXJz
aW9uIGlzICRPQ0FNTFZFUlNJT05dKQorICAgICAjIElmIE9DQU1MTElCIGlzIHNldCwgdXNlIGl0
CisgICAgIGlmIHRlc3QgIiRPQ0FNTExJQiIgPSAiIjsgdGhlbgorICAgICAgICBPQ0FNTExJQj1g
JE9DQU1MQyAtd2hlcmUgMj4vZGV2L251bGwgfHwgJE9DQU1MQyAtdnx0YWlsIC0xfGN1dCAtZCAn
ICcgLWYgNGAKKyAgICAgZWxzZQorICAgICAgICBBQ19NU0dfUkVTVUxUKFtPQ0FNTExJQiBwcmV2
aW91c2x5IHNldDsgcHJlc2VydmluZyBpdC5dKQorICAgICBmaQorICAgICBBQ19NU0dfUkVTVUxU
KFtPQ2FtbCBsaWJyYXJ5IHBhdGggaXMgJE9DQU1MTElCXSkKKworICAgICBBQ19TVUJTVChbT0NB
TUxWRVJTSU9OXSkKKyAgICAgQUNfU1VCU1QoW09DQU1MTElCXSkKKworICAgICAjIGNoZWNraW5n
IGZvciBvY2FtbG9wdAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTE9QVF0sW29jYW1sb3B0XSxb
bm9dKQorICAgICBPQ0FNTEJFU1Q9Ynl0ZQorICAgICBpZiB0ZXN0ICIkT0NBTUxPUFQiID0gIm5v
IjsgdGhlbgorCUFDX01TR19XQVJOKFtDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0ZWNvZGUgY29t
cGlsYXRpb24gb25seS5dKQorICAgICBlbHNlCisJVE1QVkVSU0lPTj1gJE9DQU1MT1BUIC12IHwg
c2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRUTVBW
RVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIEFDX01TR19SRVNVTFQoW3Zl
cnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC5dKQorCSAgICBP
Q0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZpCisKKyAg
ICAgQUNfU1VCU1QoW09DQU1MQkVTVF0pCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxjLm9w
dAorICAgICBBQ19DSEVDS19UT09MKFtPQ0FNTENET1RPUFRdLFtvY2FtbGMub3B0XSxbbm9dKQor
ICAgICBpZiB0ZXN0ICIkT0NBTUxDRE9UT1BUIiAhPSAibm8iOyB0aGVuCisJVE1QVkVSU0lPTj1g
JE9DQU1MQ0RPVE9QVCAtdiB8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24qICpcKC4qXCkkfFwxfHAn
IGAKKwlpZiB0ZXN0ICIkVE1QVkVSU0lPTiIgIT0gIiRPQ0FNTFZFUlNJT04iIDsgdGhlbgorCSAg
ICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbGMub3B0
IGRpc2NhcmRlZC5dKQorCWVsc2UKKwkgICAgT0NBTUxDPSRPQ0FNTENET1RPUFQKKwlmaQorICAg
ICBmaQorCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sb3B0Lm9wdAorICAgICBpZiB0ZXN0ICIk
T0NBTUxPUFQiICE9ICJubyIgOyB0aGVuCisJQUNfQ0hFQ0tfVE9PTChbT0NBTUxPUFRET1RPUFRd
LFtvY2FtbG9wdC5vcHRdLFtub10pCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8i
OyB0aGVuCisJICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdz
fC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAh
PSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgICAgQUNfTVNHX1JFU1VMVChbdmVyc2lvbiBk
aWZmZXJzIGZyb20gb2NhbWxjOyBvY2FtbG9wdC5vcHQgZGlzY2FyZGVkLl0pCisJICAgZWxzZQor
CSAgICAgIE9DQU1MT1BUPSRPQ0FNTE9QVERPVE9QVAorCSAgIGZpCisgICAgICAgIGZpCisgICAg
IGZpCisKKyAgICAgQUNfU1VCU1QoW09DQU1MT1BUXSkKKyAgZmkKKworICBBQ19TVUJTVChbT0NB
TUxDXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbCB0b3BsZXZlbAorICBBQ19DSEVDS19UT09M
KFtPQ0FNTF0sW29jYW1sXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZGVwCisgIEFD
X0NIRUNLX1RPT0woW09DQU1MREVQXSxbb2NhbWxkZXBdLFtub10pCisKKyAgIyBjaGVja2luZyBm
b3Igb2NhbWxta3RvcAorICBBQ19DSEVDS19UT09MKFtPQ0FNTE1LVE9QXSxbb2NhbWxta3RvcF0s
W25vXSkKKworICAjIGNoZWNraW5nIGZvciBvY2FtbG1rbGliCisgIEFDX0NIRUNLX1RPT0woW09D
QU1MTUtMSUJdLFtvY2FtbG1rbGliXSxbbm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sZG9j
CisgIEFDX0NIRUNLX1RPT0woW09DQU1MRE9DXSxbb2NhbWxkb2NdLFtub10pCisKKyAgIyBjaGVj
a2luZyBmb3Igb2NhbWxidWlsZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEJVSUxEXSxbb2NhbWxi
dWlsZF0sW25vXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BST0dfT0NBTUxMRVhdLAorW2RubAor
ICAjIGNoZWNraW5nIGZvciBvY2FtbGxleAorICBBQ19DSEVDS19UT09MKFtPQ0FNTExFWF0sW29j
YW1sbGV4XSxbbm9dKQorICBpZiB0ZXN0ICIkT0NBTUxMRVgiICE9ICJubyI7IHRoZW4KKyAgICBB
Q19DSEVDS19UT09MKFtPQ0FNTExFWERPVE9QVF0sW29jYW1sbGV4Lm9wdF0sW25vXSkKKyAgICBp
ZiB0ZXN0ICIkT0NBTUxMRVhET1RPUFQiICE9ICJubyI7IHRoZW4KKwlPQ0FNTExFWD0kT0NBTUxM
RVhET1RPUFQKKyAgICBmaQorICBmaQorICBBQ19TVUJTVChbT0NBTUxMRVhdKQorXSkKKworQUNf
REVGVU4oW0FDX1BST0dfT0NBTUxZQUNDXSwKK1tkbmwKKyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxZ
QUNDXSxbb2NhbWx5YWNjXSxbbm9dKQorICBBQ19TVUJTVChbT0NBTUxZQUNDXSkKK10pCisKKwor
QUNfREVGVU4oW0FDX1BST0dfQ0FNTFA0XSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19P
Q0FNTF0pZG5sCisKKyAgIyBjaGVja2luZyBmb3IgY2FtbHA0CisgIEFDX0NIRUNLX1RPT0woW0NB
TUxQNF0sW2NhbWxwNF0sW25vXSkKKyAgaWYgdGVzdCAiJENBTUxQNCIgIT0gIm5vIjsgdGhlbgor
ICAgICBUTVBWRVJTSU9OPWAkQ0FNTFA0IC12IDI+JjF8IHNlZCAtbiAtZSAnc3wuKnZlcnNpb24g
KlwoLipcKSR8XDF8cCdgCisgICAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVS
U0lPTiIgOyB0aGVuCisJQUNfTVNHX1JFU1VMVChbdmVyc2lvbnMgZGlmZmVycyBmcm9tIG9jYW1s
Y10pCisgICAgICAgIENBTUxQND1ubworICAgICBmaQorICBmaQorICBBQ19TVUJTVChbQ0FNTFA0
XSkKKworICAjIGNoZWNraW5nIGZvciBjb21wYW5pb24gdG9vbHMKKyAgQUNfQ0hFQ0tfVE9PTChb
Q0FNTFA0Qk9PVF0sW2NhbWxwNGJvb3RdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9d
LFtjYW1scDRvXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPRl0sW2NhbWxwNG9mXSxb
bm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRPT0ZdLFtjYW1scDRvb2ZdLFtub10pCisgIEFD
X0NIRUNLX1RPT0woW0NBTUxQNE9SRl0sW2NhbWxwNG9yZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9P
TChbQ0FNTFA0UFJPRl0sW2NhbWxwNHByb2ZdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQ
NFJdLFtjYW1scDRyXSxbbm9dKQorICBBQ19DSEVDS19UT09MKFtDQU1MUDRSRl0sW2NhbWxwNHJm
XSxbbm9dKQorICBBQ19TVUJTVChbQ0FNTFA0Qk9PVF0pCisgIEFDX1NVQlNUKFtDQU1MUDRPXSkK
KyAgQUNfU1VCU1QoW0NBTUxQNE9GXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9PRl0pCisgIEFDX1NV
QlNUKFtDQU1MUDRPUkZdKQorICBBQ19TVUJTVChbQ0FNTFA0UFJPRl0pCisgIEFDX1NVQlNUKFtD
QU1MUDRSXSkKKyAgQUNfU1VCU1QoW0NBTUxQNFJGXSkKK10pCisKKworQUNfREVGVU4oW0FDX1BS
T0dfRklORExJQl0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorCisg
ICMgY2hlY2tpbmcgZm9yIG9jYW1sZmluZAorICBBQ19DSEVDS19UT09MKFtPQ0FNTEZJTkRdLFtv
Y2FtbGZpbmRdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTEZJTkRdKQorXSkKKworCitkbmwgVGhh
bmtzIHRvIEppbSBNZXllcmluZyBmb3Igd29ya2luZyB0aGlzIG5leHQgYml0IG91dCBmb3IgdXMu
CitkbmwgWFhYIFdlIHNob3VsZCBkZWZpbmUgQVNfVFJfU0ggaWYgaXQncyBub3QgZGVmaW5lZCBh
bHJlYWR5CitkbmwgKGVnLiBmb3Igb2xkIGF1dG9jb25mKS4KK0FDX0RFRlVOKFtBQ19DSEVDS19P
Q0FNTF9QS0ddLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX0ZJTkRMSUJdKWRubAorCisg
IEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIGZpbmRsaWIgcGFja2FnZSAkMV0pCisKKyAgdW5z
ZXQgZm91bmQKKyAgdW5zZXQgcGtnCisgIGZvdW5kPW5vCisgIGZvciBwa2cgaW4gJDEgJDIgOyBk
bworICAgIGlmICRPQ0FNTEZJTkQgcXVlcnkgJHBrZyA+L2Rldi9udWxsIDI+L2Rldi9udWxsOyB0
aGVuCisgICAgICBBQ19NU0dfUkVTVUxUKFtmb3VuZF0pCisgICAgICBBU19UUl9TSChbT0NBTUxf
UEtHXyQxXSk9JHBrZworICAgICAgZm91bmQ9eWVzCisgICAgICBicmVhaworICAgIGZpCisgIGRv
bmUKKyAgaWYgdGVzdCAiJGZvdW5kIiA9ICJubyIgOyB0aGVuCisgICAgQUNfTVNHX1JFU1VMVChb
bm90IGZvdW5kXSkKKyAgICBBU19UUl9TSChbT0NBTUxfUEtHXyQxXSk9bm8KKyAgZmkKKworICBB
Q19TVUJTVChBU19UUl9TSChbT0NBTUxfUEtHXyQxXSkpCitdKQorCisKK0FDX0RFRlVOKFtBQ19D
SEVDS19PQ0FNTF9NT0RVTEVdLAorW2RubAorICBBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBPQ2FtbCBt
b2R1bGUgJDJdKQorCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9GCitvcGVuICQzCitFT0YKKyAg
dW5zZXQgZm91bmQKKyAgZm9yICQxIGluICQkMSAkNCA7IGRvCisgICAgaWYgJE9DQU1MQyAtYyAt
SSAiJCQxIiBjb25mdGVzdC5tbCA+JjUgMj4mNSA7IHRoZW4KKyAgICAgIGZvdW5kPXllcworICAg
ICAgYnJlYWsKKyAgICBmaQorICBkb25lCisKKyAgaWYgdGVzdCAiJGZvdW5kIiA7IHRoZW4KKyAg
ICBBQ19NU0dfUkVTVUxUKFskJDFdKQorICBlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbbm90IGZv
dW5kXSkKKyAgICAkMT1ubworICBmaQorICBBQ19TVUJTVChbJDFdKQorXSkKKworCitkbmwgWFhY
IENyb3NzLWNvbXBpbGluZworQUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX1dPUkRfU0laRV0sCitb
ZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkco
W2ZvciBPQ2FtbCBjb21waWxlciB3b3JkIHNpemVdKQorICBjYXQgPiBjb25mdGVzdC5tbCA8PEVP
RgorICBwcmludF9lbmRsaW5lIChzdHJpbmdfb2ZfaW50IFN5cy53b3JkX3NpemUpCisgIEVPRgor
ICBPQ0FNTF9XT1JEX1NJWkU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNHX1JFU1VMVChb
JE9DQU1MX1dPUkRfU0laRV0pCisgIEFDX1NVQlNUKFtPQ0FNTF9XT1JEX1NJWkVdKQorXSkKKwor
QUNfREVGVU4oW0FDX0NIRUNLX09DQU1MX09TX1RZUEVdLAorW2RubAorICBBQ19SRVFVSVJFKFtB
Q19QUk9HX09DQU1MXSlkbmwKKyAgQUNfTVNHX0NIRUNLSU5HKFtPQ2FtbCBTeXMub3NfdHlwZV0p
CisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKKyAgcHJpbnRfc3RyaW5nKFN5cy5vc190eXBl
KTs7CitFT0YKKworICBPQ0FNTF9PU19UWVBFPWAkT0NBTUwgY29uZnRlc3QubWxgCisgIEFDX01T
R19SRVNVTFQoWyRPQ0FNTF9PU19UWVBFXSkKKyAgQUNfU1VCU1QoW09DQU1MX09TX1RZUEVdKQor
XSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L3BhdGhfb3Jf
ZmFpbC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysg
Yi90b29scy9tNC9wYXRoX29yX2ZhaWwubTQJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAw
CkBAIC0wLDAgKzEsNiBAQAorQUNfREVGVU4oW0FYX1BBVEhfUFJPR19PUl9GQUlMXSwKK1tBQ19Q
QVRIX1BST0coWyQxXSwgWyQyXSwgW25vXSkKK2lmIHRlc3QgeCIkeyQxfSIgPT0geCJubyIgCit0
aGVuCisgICAgQUNfTVNHX0VSUk9SKFtVbmFibGUgdG8gZmluZCAkMiwgcGxlYXNlIGluc3RhbGwg
JDJdKQorZmldKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvbTQv
cHl0aG9uX2RldmVsLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3Rvb2xzL200L3B5dGhvbl9kZXZlbC5tNAlNb24gSmFuIDA5IDIxOjMzOjUyIDIw
MTIgKzAxMDAKQEAgLTAsMCArMSwxOCBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9ERVZF
TF0sCitbQUNfTVNHX0NIRUNLSU5HKFtmb3IgcHl0aG9uIGRldmVsXSkKKworYCRQWVRIT04gLWMg
JworaW1wb3J0IG9zLnBhdGgsIHN5cworZm9yIHAgaW4gc3lzLnBhdGg6CisgICAgaWYgb3MucGF0
aC5leGlzdHMocCArICIvY29uZmlnL01ha2VmaWxlIik6CisgICAgICAgIHN5cy5leGl0KDApCitz
eXMuZXhpdCgxKQorJyA+IC9kZXYvbnVsbCAyPiYxYAorCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0
aGVuCisgICAgQUNfTVNHX1JFU1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUihbUHl0aG9uIGRl
dmVsIHBhY2thZ2Ugbm90IGZvdW5kXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQor
ZmldKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciA3ZDkwY2JkY2EyYzIgdG9vbHMvbTQvcHl0aG9u
X3ZlcnNpb24ubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAK
KysrIGIvdG9vbHMvbTQvcHl0aG9uX3ZlcnNpb24ubTQJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMTIgQEAKK0FDX0RFRlVOKFtBWF9DSEVDS19QWVRIT05fVkVSU0lP
Tl0sCitbQUNfTVNHX0NIRUNLSU5HKFtmb3IgcHl0aG9uIHZlcnNpb24gPj0gJDEuJDIgXSkKK2Ak
UFlUSE9OIC1jICdpbXBvcnQgc3lzOyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoJDEs
ICQyKSIpKSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgcHl0aG9uX3ZlcnNpb249
YCRQWVRIT04gLVYgMj4mMWAKKyAgICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VS
Uk9SKAorICAgICAgICBbJHB5dGhvbl92ZXJzaW9uIGlzIHRvbyBvbGQsIG1pbmltdW0gcmVxdWly
ZWQgdmVyc2lvbiBpcyAkMS4kMl0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2Zp
XSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L3B5dGhvbl94
bWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIv
dG9vbHMvbTQvcHl0aG9uX3htbC5tNAlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAg
LTAsMCArMSwxMCBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9YTUxdLAorW0FDX01TR19D
SEVDS0lORyhbZm9yIHB5dGhvbiB4bWwuZG9tLm1pbmlkb21dKQorYCRQWVRIT04gLWMgJ2ltcG9y
dCB4bWwuZG9tLm1pbmlkb20nYAoraWYgdGVzdCAiJD8iICE9ICIwIgordGhlbgorICAgIEFDX01T
R19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kIHhtbC5kb20u
bWluaWRvbSBtb2R1bGVdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitmaV0pCmRp
ZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB0b29scy9tNC9zZXRfY2ZsYWdzX2xk
ZmxhZ3MubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysr
IGIvdG9vbHMvbTQvc2V0X2NmbGFnc19sZGZsYWdzLm00CU1vbiBKYW4gMDkgMjE6MzM6NTIgMjAx
MiArMDEwMApAQCAtMCwwICsxLDIwIEBACitBQ19ERUZVTihbQVhfU0VUX0ZMQUdTXSwKK1tmb3Ig
Y2ZsYWcgaW4gJFBSRVBFTkRfSU5DTFVERVMKK2RvCisgICAgUFJFUEVORF9DRkxBR1MrPSIgLUkk
Y2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRQUkVQRU5EX0xJQgorZG8KKyAgICBQUkVQRU5E
X0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9uZQorZm9yIGNmbGFnIGluICRBUFBFTkRfSU5DTFVE
RVMKK2RvCisgICAgQVBQRU5EX0NGTEFHUys9IiAtSSRjZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcg
aW4gJEFQUEVORF9MSUIKK2RvCisgICAgQVBQRU5EX0xERkxBR1MrPSIgLUwkbGRmbGFnIgorZG9u
ZQorQ0ZMQUdTPSIkUFJFUEVORF9DRkxBR1MgJENGTEFHUyAkQVBQRU5EX0NGTEFHUyIKK0xERkxB
R1M9IiRQUkVQRU5EX0xERkxBR1MgJExERkxBR1MgJEFQUEVORF9MREZMQUdTIl0pCisKZGlmZiAt
ciA0MDg2ZTQ4MTE1NDcgLXIgN2Q5MGNiZGNhMmMyIHRvb2xzL200L3VkZXYubTQKLS0tIC9kZXYv
bnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvdWRldi5t
NAlNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwzMiBAQAorQUNfREVG
VU4oW0FYX0NIRUNLX1VERVZdLAorW2lmIHRlc3QgImB1bmFtZSAtc2AiID09ICJMaW51eCIKK3Ro
ZW4KKyAgICBBQ19QQVRIX1BST0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAgaWYg
dGVzdCB4IiR7VURFVkFETX0iID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9Q
Uk9HKFtVREVWSU5GT10sIFt1ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIke1VE
RVZJTkZPfSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9S
KAorICAgICAgICAgICAgICAgIFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZvLCBw
bGVhc2UgaW5zdGFsbCB1ZGV2XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtVREVW
SU5GT30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2ZXI9
YCR7VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAgaWYg
dGVzdCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9HKFtI
T1RQTFVHXSwgW2hvdHBsdWddLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVHfSIg
PT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2IGlz
IHRvbyBvbGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZpCisg
ICAgZmkKK2Vsc2UKKyAgICBBQ19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwgW25v
XSkKKyAgICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAg
ICBBQ19NU0dfRVJST1IoW05vdCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQgdm5k
XSkKKyAgICBmaQorZmkKK10pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIDdkOTBjYmRjYTJjMiB2
ZXJzaW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisr
KyBiL3ZlcnNpb24uc2gJTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAwCkBAIC0wLDAgKzEs
NCBAQAorIyEvYmluL3NoCitNQUpPUj1gZ3JlcCAiZXhwb3J0IFhFTl9WRVJTSU9OIiAkMSB8IHNl
ZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdyZXAgImV4cG9ydCBYRU5fU1VCVkVS
U0lPTiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK3ByaW50ZiAiJWQuJWQiICRN
QUpPUiAkTUlOT1IKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 10 12:02:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 12: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 1RkaOe-0005j6-Lx; Tue, 10 Jan 2012 12:01:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RkaOd-0005ih-DA
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 12:01:43 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326196897!10232586!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2NzI2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20957 invoked from network); 10 Jan 2012 12:01:37 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 12:01:37 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=dfCSvSYTJBAFle8N0Iv2/TEuuCCk/5Q2aGYBc3XDYrXqqJx5WeUE6B9B
	3YMeKg2KY69T3LuH1iEoRx3FLrdokLDfJxXKkABwDtt8WmkHRpdGRnnd6
	ypG+DKouWsAxPipPXJSsvBH9r3lULqsPoWG9zw5H+B1FpA6Gju6C0kA0u
	cvxo9j2ZI2zpUFsAZ0Oiatvm7w8J7TraKBer2yvlNE2XnuqT6jRv7Miy/
	qKxVX1Kj1/QiU/xS2ql/Mx51IcRGJ;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326196897; x=1357732897;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=gq93GoKR6EXXfJM7i67eqMel+Tlf7zNzdJ46ukiZjKk=;
	b=NhTY5IhOljBs01uXpZS868PwYCT4fz1yxwnoSYgYV2yR6oW0dHjYdMFb
	cpVOjDJAKu/h3tUXqsxm15Pyd9aRqOtN9DbreJP4K1Gsn4jFP59UZL4mP
	nyQ/fgXwjW2o4+3IEQcjOzNqtTugC/zf+HLsL5HXWjYPyl+jzkVRigI33
	qGzC837f+zACc5MYS/UVbsm3N+qOmdT9YTe5RLuNvVqCUppghj5RAKq8k
	tfWyh7ZBzkMnlX4UkA9h22XaBziAr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,486,1320620400"; d="scan'208";a="83039471"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 10 Jan 2012 13:01:37 +0100
X-IronPort-AV: E=Sophos;i="4.71,486,1320620400"; d="scan'208";a="126421839"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 10 Jan 2012 13:01:36 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id B143F95E674;
	Tue, 10 Jan 2012 13:01:36 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 13:01:36 +0100
Message-ID: <1833373.C1p72vWEqk@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CAEBdQ90AAUmffY7NaC+SO5UEwwbpN51gnYJJ+5VfNFcU9ZpWLw@mail.gmail.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120104142539.GA3322@phenom.dumpdata.com>
	<CAEBdQ90AAUmffY7NaC+SO5UEwwbpN51gnYJJ+5VfNFcU9ZpWLw@mail.gmail.com>
MIME-Version: 1.0
Cc: John Sherwood <jrs@vt.edu>, Jean Guyader <jean.guyader@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] extending 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

Am Montag 09 Januar 2012, 10:27:50 schrieb Jean Guyader:
> On 4 January 2012 14:25, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Tue, Jan 03, 2012 at 08:16:13PM -0500, John Sherwood wrote:
> >> the synergy incompatibilities were largely package related, due to
> >> requirements for a different application that we were supposed to deploy.
> >>  I'll try the ioperm patches next chance I have.
> >
> > Please don't top post.
> >
> >> > http://xen.org/products/xci_source.html
> >
> > (the ioemu-pq git tree, look for 'ps2-passthrough')
> >
> > .. has a driver in userspace that actually takes PS/2 input and shovels
> > them using QEMU to the guest. That might be interesting for you to look at
> > as well.
> >
> 
> Hi,
> 
> This patch is at a very rough stage.
> 
> The best way to do what you want would be to open the HID device
> directly (/dev/event*) from Qemu
> and forward the event to do the PS2 device model.
> That works fine until you want to share the input between multiple VM,
> at this point you probably
> what a new daemon to play the gate keeper.
> 
> Jean

I did such hack solution there:
http://lists.xen.org/archives/html/xen-devel/2010-03/msg01292.html

Dietmar.


> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 12:02:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 12: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 1RkaOe-0005j6-Lx; Tue, 10 Jan 2012 12:01:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RkaOd-0005ih-DA
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 12:01:43 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326196897!10232586!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2NzI2OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20957 invoked from network); 10 Jan 2012 12:01:37 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 12:01:37 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=dfCSvSYTJBAFle8N0Iv2/TEuuCCk/5Q2aGYBc3XDYrXqqJx5WeUE6B9B
	3YMeKg2KY69T3LuH1iEoRx3FLrdokLDfJxXKkABwDtt8WmkHRpdGRnnd6
	ypG+DKouWsAxPipPXJSsvBH9r3lULqsPoWG9zw5H+B1FpA6Gju6C0kA0u
	cvxo9j2ZI2zpUFsAZ0Oiatvm7w8J7TraKBer2yvlNE2XnuqT6jRv7Miy/
	qKxVX1Kj1/QiU/xS2ql/Mx51IcRGJ;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326196897; x=1357732897;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=gq93GoKR6EXXfJM7i67eqMel+Tlf7zNzdJ46ukiZjKk=;
	b=NhTY5IhOljBs01uXpZS868PwYCT4fz1yxwnoSYgYV2yR6oW0dHjYdMFb
	cpVOjDJAKu/h3tUXqsxm15Pyd9aRqOtN9DbreJP4K1Gsn4jFP59UZL4mP
	nyQ/fgXwjW2o4+3IEQcjOzNqtTugC/zf+HLsL5HXWjYPyl+jzkVRigI33
	qGzC837f+zACc5MYS/UVbsm3N+qOmdT9YTe5RLuNvVqCUppghj5RAKq8k
	tfWyh7ZBzkMnlX4UkA9h22XaBziAr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,486,1320620400"; d="scan'208";a="83039471"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 10 Jan 2012 13:01:37 +0100
X-IronPort-AV: E=Sophos;i="4.71,486,1320620400"; d="scan'208";a="126421839"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 10 Jan 2012 13:01:36 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id B143F95E674;
	Tue, 10 Jan 2012 13:01:36 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 13:01:36 +0100
Message-ID: <1833373.C1p72vWEqk@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CAEBdQ90AAUmffY7NaC+SO5UEwwbpN51gnYJJ+5VfNFcU9ZpWLw@mail.gmail.com>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120104142539.GA3322@phenom.dumpdata.com>
	<CAEBdQ90AAUmffY7NaC+SO5UEwwbpN51gnYJJ+5VfNFcU9ZpWLw@mail.gmail.com>
MIME-Version: 1.0
Cc: John Sherwood <jrs@vt.edu>, Jean Guyader <jean.guyader@gmail.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] extending 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

Am Montag 09 Januar 2012, 10:27:50 schrieb Jean Guyader:
> On 4 January 2012 14:25, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Tue, Jan 03, 2012 at 08:16:13PM -0500, John Sherwood wrote:
> >> the synergy incompatibilities were largely package related, due to
> >> requirements for a different application that we were supposed to deploy.
> >>  I'll try the ioperm patches next chance I have.
> >
> > Please don't top post.
> >
> >> > http://xen.org/products/xci_source.html
> >
> > (the ioemu-pq git tree, look for 'ps2-passthrough')
> >
> > .. has a driver in userspace that actually takes PS/2 input and shovels
> > them using QEMU to the guest. That might be interesting for you to look at
> > as well.
> >
> 
> Hi,
> 
> This patch is at a very rough stage.
> 
> The best way to do what you want would be to open the HID device
> directly (/dev/event*) from Qemu
> and forward the event to do the PS2 device model.
> That works fine until you want to share the input between multiple VM,
> at this point you probably
> what a new daemon to play the gate keeper.
> 
> Jean

I did such hack solution there:
http://lists.xen.org/archives/html/xen-devel/2010-03/msg01292.html

Dietmar.


> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 13:19:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 13:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkbbp-0006dG-IB; Tue, 10 Jan 2012 13:19: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 1Rkbbn-0006cs-Pt
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 13:19:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326201556!8325094!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 7781 invoked from network); 10 Jan 2012 13:19:17 -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; 10 Jan 2012 13:19:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 13:19:16 +0000
Message-Id: <4F0C48E2020000780006B91F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 13:19:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@entel.upc.edu>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
In-Reply-To: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.01.12 at 21:37, Roger Pau Monne <roger.pau@entel.upc.edu> wrote:
> --- a/README	Thu Jan 05 17:25:23 2012 +0000
> +++ b/README	Mon Jan 09 21:33:52 2012 +0100
> @@ -41,6 +41,7 @@ provided by your OS distributor:
>      * GCC v3.4 or later
>      * GNU Make
>      * GNU Binutils
> +    * GNU Autoconf v2.67 or later

I think Ian had asked this already, but I also think that I didn't see
an answer: Is this relatively new version really a requirement. Not
even SLE11 SP2, which hasn't shipped yet, has this new an
autoconf package. And I would hope to continue to be able to
build on SLE10 SP4, which only has 2.59, without having to
manually build newer packages...

>      * Development install of zlib (e.g., zlib-dev)
>      * Development install of Python v2.3 or later (e.g., python-dev)
>      * Development install of curses (e.g., libncurses-dev)
> @@ -87,9 +88,21 @@ 2. cd to xen-unstable (or whatever you s
>  3. For the very first build, or if you want to destroy build trees,
>     perform the following steps:
>  
> +   If you are building Xen from a repository (git or mercurial) you
> +   must run:
> +
> +    # ./autogen.sh
> +
> +   Before executing ./configure (this step can be ommited when
> +   building from a distribution package).
> +
> +    # ./configure

Can these two steps be automated (i.e. the need to run either
be determined by the absence of some file(s), and them being
invoked from the top level Makefile)?

>      # make world
>      # make install
>  
> +   If you want, you can run ./configure --help to see the list of
> +   options available options when building and installing Xen.
> +
>     This will create and install onto the local machine. It will build
>     the xen binary (xen.gz), the tools and the documentation.
>  
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/autogen.sh	Mon Jan 09 21:33:52 2012 +0100
> @@ -0,0 +1,11 @@
> +#!/bin/sh

Adding -e here ...

> +rm -rf configure
> +cd tools
> +autoheader && autoconf
> +if [ "$?" = "0" ]
> +then

... would eliminate the need for this conditional ...

> +    cd ..
> +    echo "#!/bin/sh" >> configure
> +    echo "cd tools && ./configure \$@" >> configure
> +    chmod +x configure

... and catch failure anywhere here.

> +fi
> --- a/tools/Rules.mk	Thu Jan 05 17:25:23 2012 +0000
> +++ b/tools/Rules.mk	Mon Jan 09 21:33:52 2012 +0100
> @@ -3,6 +3,7 @@
>  # `all' is the default target
>  all:
>  
> +include $(XEN_ROOT)/config/Tools.mk
>  include $(XEN_ROOT)/Config.mk

Wouldn't the order better be the other way around (generic before
subdir specific)?

>  
>  export _INSTALL := $(INSTALL)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 13:19:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 13:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkbbp-0006dG-IB; Tue, 10 Jan 2012 13:19: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 1Rkbbn-0006cs-Pt
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 13:19:24 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326201556!8325094!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 7781 invoked from network); 10 Jan 2012 13:19:17 -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; 10 Jan 2012 13:19:17 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 13:19:16 +0000
Message-Id: <4F0C48E2020000780006B91F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 13:19:14 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Roger Pau Monne" <roger.pau@entel.upc.edu>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
In-Reply-To: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 09.01.12 at 21:37, Roger Pau Monne <roger.pau@entel.upc.edu> wrote:
> --- a/README	Thu Jan 05 17:25:23 2012 +0000
> +++ b/README	Mon Jan 09 21:33:52 2012 +0100
> @@ -41,6 +41,7 @@ provided by your OS distributor:
>      * GCC v3.4 or later
>      * GNU Make
>      * GNU Binutils
> +    * GNU Autoconf v2.67 or later

I think Ian had asked this already, but I also think that I didn't see
an answer: Is this relatively new version really a requirement. Not
even SLE11 SP2, which hasn't shipped yet, has this new an
autoconf package. And I would hope to continue to be able to
build on SLE10 SP4, which only has 2.59, without having to
manually build newer packages...

>      * Development install of zlib (e.g., zlib-dev)
>      * Development install of Python v2.3 or later (e.g., python-dev)
>      * Development install of curses (e.g., libncurses-dev)
> @@ -87,9 +88,21 @@ 2. cd to xen-unstable (or whatever you s
>  3. For the very first build, or if you want to destroy build trees,
>     perform the following steps:
>  
> +   If you are building Xen from a repository (git or mercurial) you
> +   must run:
> +
> +    # ./autogen.sh
> +
> +   Before executing ./configure (this step can be ommited when
> +   building from a distribution package).
> +
> +    # ./configure

Can these two steps be automated (i.e. the need to run either
be determined by the absence of some file(s), and them being
invoked from the top level Makefile)?

>      # make world
>      # make install
>  
> +   If you want, you can run ./configure --help to see the list of
> +   options available options when building and installing Xen.
> +
>     This will create and install onto the local machine. It will build
>     the xen binary (xen.gz), the tools and the documentation.
>  
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/autogen.sh	Mon Jan 09 21:33:52 2012 +0100
> @@ -0,0 +1,11 @@
> +#!/bin/sh

Adding -e here ...

> +rm -rf configure
> +cd tools
> +autoheader && autoconf
> +if [ "$?" = "0" ]
> +then

... would eliminate the need for this conditional ...

> +    cd ..
> +    echo "#!/bin/sh" >> configure
> +    echo "cd tools && ./configure \$@" >> configure
> +    chmod +x configure

... and catch failure anywhere here.

> +fi
> --- a/tools/Rules.mk	Thu Jan 05 17:25:23 2012 +0000
> +++ b/tools/Rules.mk	Mon Jan 09 21:33:52 2012 +0100
> @@ -3,6 +3,7 @@
>  # `all' is the default target
>  all:
>  
> +include $(XEN_ROOT)/config/Tools.mk
>  include $(XEN_ROOT)/Config.mk

Wouldn't the order better be the other way around (generic before
subdir specific)?

>  
>  export _INSTALL := $(INSTALL)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 13:33:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 13:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkboz-0006yp-TV; Tue, 10 Jan 2012 13:33: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 1Rkbox-0006yh-TJ
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 13:33:00 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326202371!10290937!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 29137 invoked from network); 10 Jan 2012 13:32:53 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 13:32:53 -0000
Received: by pbbb11 with SMTP id b11so19214934pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 05:32:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=2qRcXzkBT8yzf3kpJIjGX7x2fsQFbby/gtUzbrtElH0=;
	b=KWHvImwLq/xycmV2a2PnKgwMFTi5Y99ALmoHC84yQXhitGvwZUth3wAoFh0Lwi3yPj
	hDPNmYR6XCqO2zXSNi3NdPkZU0EWEVOWIPqNNP6+jI0Ce/kHKkHZ0btPqiuXbf9r+9c5
	dvX/t7lIW2EivzPo6kH0PUp8LvA5szwsjk56c=
MIME-Version: 1.0
Received: by 10.68.75.199 with SMTP id e7mr50964757pbw.128.1326202370789; Tue,
	10 Jan 2012 05:32:50 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 10 Jan 2012 05:32:50 -0800 (PST)
In-Reply-To: <4F0C48E2020000780006B91F@nat28.tlf.novell.com>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.com>
Date: Tue, 10 Jan 2012 14:32:50 +0100
X-Google-Sender-Auth: srW2HV5B8YPSH75ii4ELYbLdUR4
Message-ID: <CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@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, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
	custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEwIEphbiBCZXVsaWNoIDxKQmV1bGljaEBzdXNlLmNvbT46Cj4+Pj4gT24gMDkuMDEu
MTIgYXQgMjE6MzcsIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+IHdy
b3RlOgo+PiAtLS0gYS9SRUFETUUgwqBUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4g
KysrIGIvUkVBRE1FIMKgTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAwCj4+IEBAIC00MSw2
ICs0MSw3IEBAIHByb3ZpZGVkIGJ5IHlvdXIgT1MgZGlzdHJpYnV0b3I6Cj4+IMKgIMKgIMKgKiBH
Q0MgdjMuNCBvciBsYXRlcgo+PiDCoCDCoCDCoCogR05VIE1ha2UKPj4gwqAgwqAgwqAqIEdOVSBC
aW51dGlscwo+PiArIMKgIMKgKiBHTlUgQXV0b2NvbmYgdjIuNjcgb3IgbGF0ZXIKPgo+IEkgdGhp
bmsgSWFuIGhhZCBhc2tlZCB0aGlzIGFscmVhZHksIGJ1dCBJIGFsc28gdGhpbmsgdGhhdCBJIGRp
ZG4ndCBzZWUKPiBhbiBhbnN3ZXI6IElzIHRoaXMgcmVsYXRpdmVseSBuZXcgdmVyc2lvbiByZWFs
bHkgYSByZXF1aXJlbWVudC4gTm90Cj4gZXZlbiBTTEUxMSBTUDIsIHdoaWNoIGhhc24ndCBzaGlw
cGVkIHlldCwgaGFzIHRoaXMgbmV3IGFuCj4gYXV0b2NvbmYgcGFja2FnZS4gQW5kIEkgd291bGQg
aG9wZSB0byBjb250aW51ZSB0byBiZSBhYmxlIHRvCj4gYnVpbGQgb24gU0xFMTAgU1A0LCB3aGlj
aCBvbmx5IGhhcyAyLjU5LCB3aXRob3V0IGhhdmluZyB0bwo+IG1hbnVhbGx5IGJ1aWxkIG5ld2Vy
IHBhY2thZ2VzLi4uCgpJJ3ZlIG9ubHkgdGVzdGVkIHRoaXMgd2l0aCAyLjY4IGFuZCAyLjY3LCBJ
ICpndWVzcyogaXQgd2lsbCB3b3JrIHdpdGgKMi41OSwgYnV0IGl0IHdpbGwgYmUgZ29vZCBpZiB5
b3UgY291bGQgcnVuIHRoZSBzY3JpcHQgYW5kIHByb3ZlIHRoYXQKaXQgYWN0dWFsbHkgZG9lcy4g
V2UgYWdyZWVkIHdpdGggSWFuIHRoYXQgdmVyc2lvbiB3aWxsIGJlIGRvd25ncmFkZWQKYmFzZWQg
b24gdXNlci1mZWVkYmFjay4KCj4KPj4gwqAgwqAgwqAqIERldmVsb3BtZW50IGluc3RhbGwgb2Yg
emxpYiAoZS5nLiwgemxpYi1kZXYpCj4+IMKgIMKgIMKgKiBEZXZlbG9wbWVudCBpbnN0YWxsIG9m
IFB5dGhvbiB2Mi4zIG9yIGxhdGVyIChlLmcuLCBweXRob24tZGV2KQo+PiDCoCDCoCDCoCogRGV2
ZWxvcG1lbnQgaW5zdGFsbCBvZiBjdXJzZXMgKGUuZy4sIGxpYm5jdXJzZXMtZGV2KQo+PiBAQCAt
ODcsOSArODgsMjEgQEAgMi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0ZXZlciB5b3Ugcwo+
PiDCoDMuIEZvciB0aGUgdmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJv
eSBidWlsZCB0cmVlcywKPj4gwqAgwqAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgo+Pgo+
PiArIMKgIElmIHlvdSBhcmUgYnVpbGRpbmcgWGVuIGZyb20gYSByZXBvc2l0b3J5IChnaXQgb3Ig
bWVyY3VyaWFsKSB5b3UKPj4gKyDCoCBtdXN0IHJ1bjoKPj4gKwo+PiArIMKgIMKgIyAuL2F1dG9n
ZW4uc2gKPj4gKwo+PiArIMKgIEJlZm9yZSBleGVjdXRpbmcgLi9jb25maWd1cmUgKHRoaXMgc3Rl
cCBjYW4gYmUgb21taXRlZCB3aGVuCj4+ICsgwqAgYnVpbGRpbmcgZnJvbSBhIGRpc3RyaWJ1dGlv
biBwYWNrYWdlKS4KPj4gKwo+PiArIMKgIMKgIyAuL2NvbmZpZ3VyZQo+Cj4gQ2FuIHRoZXNlIHR3
byBzdGVwcyBiZSBhdXRvbWF0ZWQgKGkuZS4gdGhlIG5lZWQgdG8gcnVuIGVpdGhlcgo+IGJlIGRl
dGVybWluZWQgYnkgdGhlIGFic2VuY2Ugb2Ygc29tZSBmaWxlKHMpLCBhbmQgdGhlbSBiZWluZwo+
IGludm9rZWQgZnJvbSB0aGUgdG9wIGxldmVsIE1ha2VmaWxlKT8KCkl0IHByb2JhYmx5IGNvdWxk
LCBqdXN0IG1ha2luZyBhIHRhcmdldCBmb3IgY29uZmlnLmggaW4KdG9vbHMvTWFrZWZpbGUuIEFy
ZSB5b3Ugc3VyZSB0aGlzIGlzIHdoYXQgd2Ugd2FudD8gVGhlIGNvbmZpZ3VyZQpzY3JpcHQgaGFz
IHNldmVyYWwgYnVpbGQgb3B0aW9ucyB0aGF0IHNob3VsZCBiZSBzZXQgYnkgdGhlIHVzZXIgKG9y
IGF0CmxlYXN0IHJldmlld2VkLCBzbyB0aGUgdXNlciBrbm93IGl0IGhhcyBidWlsZC9pbnN0YWxs
IG9wdGlvbnMpLgoKPgo+PiDCoCDCoCDCoCMgbWFrZSB3b3JsZAo+PiDCoCDCoCDCoCMgbWFrZSBp
bnN0YWxsCj4+Cj4+ICsgwqAgSWYgeW91IHdhbnQsIHlvdSBjYW4gcnVuIC4vY29uZmlndXJlIC0t
aGVscCB0byBzZWUgdGhlIGxpc3Qgb2YKPj4gKyDCoCBvcHRpb25zIGF2YWlsYWJsZSBvcHRpb25z
IHdoZW4gYnVpbGRpbmcgYW5kIGluc3RhbGxpbmcgWGVuLgo+PiArCj4+IMKgIMKgIFRoaXMgd2ls
bCBjcmVhdGUgYW5kIGluc3RhbGwgb250byB0aGUgbG9jYWwgbWFjaGluZS4gSXQgd2lsbCBidWls
ZAo+PiDCoCDCoCB0aGUgeGVuIGJpbmFyeSAoeGVuLmd6KSwgdGhlIHRvb2xzIGFuZCB0aGUgZG9j
dW1lbnRhdGlvbi4KPj4KPj4gLS0tIC9kZXYvbnVsbCBUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKPj4gKysrIGIvYXV0b2dlbi5zaCDCoCDCoCDCoE1vbiBKYW4gMDkgMjE6MzM6NTIgMjAx
MiArMDEwMAo+PiBAQCAtMCwwICsxLDExIEBACj4+ICsjIS9iaW4vc2gKPgo+IEFkZGluZyAtZSBo
ZXJlIC4uLgo+Cj4+ICtybSAtcmYgY29uZmlndXJlCj4+ICtjZCB0b29scwo+PiArYXV0b2hlYWRl
ciAmJiBhdXRvY29uZgo+PiAraWYgWyAiJD8iID0gIjAiIF0KPj4gK3RoZW4KPgo+IC4uLiB3b3Vs
ZCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIHRoaXMgY29uZGl0aW9uYWwgLi4uCj4KPj4gKyDCoCDC
oGNkIC4uCj4+ICsgwqAgwqBlY2hvICIjIS9iaW4vc2giID4+IGNvbmZpZ3VyZQo+PiArIMKgIMKg
ZWNobyAiY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgXCRAIiA+PiBjb25maWd1cmUKPj4gKyDCoCDC
oGNobW9kICt4IGNvbmZpZ3VyZQo+Cj4gLi4uIGFuZCBjYXRjaCBmYWlsdXJlIGFueXdoZXJlIGhl
cmUuCgpXaWxsIGNoYW5nZSB0aGF0LgoKPgo+PiArZmkKPj4gLS0tIGEvdG9vbHMvUnVsZXMubWsg
wqBUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4gKysrIGIvdG9vbHMvUnVsZXMubWsg
wqBNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKPj4gQEAgLTMsNiArMyw3IEBACj4+IMKg
IyBgYWxsJyBpcyB0aGUgZGVmYXVsdCB0YXJnZXQKPj4gwqBhbGw6Cj4+Cj4+ICtpbmNsdWRlICQo
WEVOX1JPT1QpL2NvbmZpZy9Ub29scy5tawo+PiDCoGluY2x1ZGUgJChYRU5fUk9PVCkvQ29uZmln
Lm1rCj4KPiBXb3VsZG4ndCB0aGUgb3JkZXIgYmV0dGVyIGJlIHRoZSBvdGhlciB3YXkgYXJvdW5k
IChnZW5lcmljIGJlZm9yZQo+IHN1YmRpciBzcGVjaWZpYyk/CgpTaW5jZSBDb25maWcubWsgdXNl
cyA/PSB3aGVuIHNldHRpbmcgdmFyaWFibGVzLCBJIGRvbid0IHRoaW5rIGl0CnJlYWxseSBtYXR0
ZXJzICh0aGUgb25seSB2YXJpYWJsZSB0aGF0IGNvdWxkIGJlIG92ZXJ3cml0dGVuIGJ5CkNvbmZp
Zy5tayBpcyBQWVRIT04sIGFuZCBpdCBpcyBzZXQgd2l0aCA/PSBpbiBDb25maWcubWspLCBhbnl3
YXksIEkKd2lsbCBjaGFuZ2UgaXQuCgo+Cj4+Cj4+IMKgZXhwb3J0IF9JTlNUQUxMIDo9ICQoSU5T
VEFMTCkKPgo+IEphbgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 10 13:33:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 13:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkboz-0006yp-TV; Tue, 10 Jan 2012 13:33: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 1Rkbox-0006yh-TJ
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 13:33:00 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326202371!10290937!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 29137 invoked from network); 10 Jan 2012 13:32:53 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 13:32:53 -0000
Received: by pbbb11 with SMTP id b11so19214934pbb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 05:32:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=2qRcXzkBT8yzf3kpJIjGX7x2fsQFbby/gtUzbrtElH0=;
	b=KWHvImwLq/xycmV2a2PnKgwMFTi5Y99ALmoHC84yQXhitGvwZUth3wAoFh0Lwi3yPj
	hDPNmYR6XCqO2zXSNi3NdPkZU0EWEVOWIPqNNP6+jI0Ce/kHKkHZ0btPqiuXbf9r+9c5
	dvX/t7lIW2EivzPo6kH0PUp8LvA5szwsjk56c=
MIME-Version: 1.0
Received: by 10.68.75.199 with SMTP id e7mr50964757pbw.128.1326202370789; Tue,
	10 Jan 2012 05:32:50 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 10 Jan 2012 05:32:50 -0800 (PST)
In-Reply-To: <4F0C48E2020000780006B91F@nat28.tlf.novell.com>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.com>
Date: Tue, 10 Jan 2012 14:32:50 +0100
X-Google-Sender-Auth: srW2HV5B8YPSH75ii4ELYbLdUR4
Message-ID: <CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@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, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
	custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEwIEphbiBCZXVsaWNoIDxKQmV1bGljaEBzdXNlLmNvbT46Cj4+Pj4gT24gMDkuMDEu
MTIgYXQgMjE6MzcsIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+IHdy
b3RlOgo+PiAtLS0gYS9SRUFETUUgwqBUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4g
KysrIGIvUkVBRE1FIMKgTW9uIEphbiAwOSAyMTozMzo1MiAyMDEyICswMTAwCj4+IEBAIC00MSw2
ICs0MSw3IEBAIHByb3ZpZGVkIGJ5IHlvdXIgT1MgZGlzdHJpYnV0b3I6Cj4+IMKgIMKgIMKgKiBH
Q0MgdjMuNCBvciBsYXRlcgo+PiDCoCDCoCDCoCogR05VIE1ha2UKPj4gwqAgwqAgwqAqIEdOVSBC
aW51dGlscwo+PiArIMKgIMKgKiBHTlUgQXV0b2NvbmYgdjIuNjcgb3IgbGF0ZXIKPgo+IEkgdGhp
bmsgSWFuIGhhZCBhc2tlZCB0aGlzIGFscmVhZHksIGJ1dCBJIGFsc28gdGhpbmsgdGhhdCBJIGRp
ZG4ndCBzZWUKPiBhbiBhbnN3ZXI6IElzIHRoaXMgcmVsYXRpdmVseSBuZXcgdmVyc2lvbiByZWFs
bHkgYSByZXF1aXJlbWVudC4gTm90Cj4gZXZlbiBTTEUxMSBTUDIsIHdoaWNoIGhhc24ndCBzaGlw
cGVkIHlldCwgaGFzIHRoaXMgbmV3IGFuCj4gYXV0b2NvbmYgcGFja2FnZS4gQW5kIEkgd291bGQg
aG9wZSB0byBjb250aW51ZSB0byBiZSBhYmxlIHRvCj4gYnVpbGQgb24gU0xFMTAgU1A0LCB3aGlj
aCBvbmx5IGhhcyAyLjU5LCB3aXRob3V0IGhhdmluZyB0bwo+IG1hbnVhbGx5IGJ1aWxkIG5ld2Vy
IHBhY2thZ2VzLi4uCgpJJ3ZlIG9ubHkgdGVzdGVkIHRoaXMgd2l0aCAyLjY4IGFuZCAyLjY3LCBJ
ICpndWVzcyogaXQgd2lsbCB3b3JrIHdpdGgKMi41OSwgYnV0IGl0IHdpbGwgYmUgZ29vZCBpZiB5
b3UgY291bGQgcnVuIHRoZSBzY3JpcHQgYW5kIHByb3ZlIHRoYXQKaXQgYWN0dWFsbHkgZG9lcy4g
V2UgYWdyZWVkIHdpdGggSWFuIHRoYXQgdmVyc2lvbiB3aWxsIGJlIGRvd25ncmFkZWQKYmFzZWQg
b24gdXNlci1mZWVkYmFjay4KCj4KPj4gwqAgwqAgwqAqIERldmVsb3BtZW50IGluc3RhbGwgb2Yg
emxpYiAoZS5nLiwgemxpYi1kZXYpCj4+IMKgIMKgIMKgKiBEZXZlbG9wbWVudCBpbnN0YWxsIG9m
IFB5dGhvbiB2Mi4zIG9yIGxhdGVyIChlLmcuLCBweXRob24tZGV2KQo+PiDCoCDCoCDCoCogRGV2
ZWxvcG1lbnQgaW5zdGFsbCBvZiBjdXJzZXMgKGUuZy4sIGxpYm5jdXJzZXMtZGV2KQo+PiBAQCAt
ODcsOSArODgsMjEgQEAgMi4gY2QgdG8geGVuLXVuc3RhYmxlIChvciB3aGF0ZXZlciB5b3Ugcwo+
PiDCoDMuIEZvciB0aGUgdmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJv
eSBidWlsZCB0cmVlcywKPj4gwqAgwqAgcGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgo+Pgo+
PiArIMKgIElmIHlvdSBhcmUgYnVpbGRpbmcgWGVuIGZyb20gYSByZXBvc2l0b3J5IChnaXQgb3Ig
bWVyY3VyaWFsKSB5b3UKPj4gKyDCoCBtdXN0IHJ1bjoKPj4gKwo+PiArIMKgIMKgIyAuL2F1dG9n
ZW4uc2gKPj4gKwo+PiArIMKgIEJlZm9yZSBleGVjdXRpbmcgLi9jb25maWd1cmUgKHRoaXMgc3Rl
cCBjYW4gYmUgb21taXRlZCB3aGVuCj4+ICsgwqAgYnVpbGRpbmcgZnJvbSBhIGRpc3RyaWJ1dGlv
biBwYWNrYWdlKS4KPj4gKwo+PiArIMKgIMKgIyAuL2NvbmZpZ3VyZQo+Cj4gQ2FuIHRoZXNlIHR3
byBzdGVwcyBiZSBhdXRvbWF0ZWQgKGkuZS4gdGhlIG5lZWQgdG8gcnVuIGVpdGhlcgo+IGJlIGRl
dGVybWluZWQgYnkgdGhlIGFic2VuY2Ugb2Ygc29tZSBmaWxlKHMpLCBhbmQgdGhlbSBiZWluZwo+
IGludm9rZWQgZnJvbSB0aGUgdG9wIGxldmVsIE1ha2VmaWxlKT8KCkl0IHByb2JhYmx5IGNvdWxk
LCBqdXN0IG1ha2luZyBhIHRhcmdldCBmb3IgY29uZmlnLmggaW4KdG9vbHMvTWFrZWZpbGUuIEFy
ZSB5b3Ugc3VyZSB0aGlzIGlzIHdoYXQgd2Ugd2FudD8gVGhlIGNvbmZpZ3VyZQpzY3JpcHQgaGFz
IHNldmVyYWwgYnVpbGQgb3B0aW9ucyB0aGF0IHNob3VsZCBiZSBzZXQgYnkgdGhlIHVzZXIgKG9y
IGF0CmxlYXN0IHJldmlld2VkLCBzbyB0aGUgdXNlciBrbm93IGl0IGhhcyBidWlsZC9pbnN0YWxs
IG9wdGlvbnMpLgoKPgo+PiDCoCDCoCDCoCMgbWFrZSB3b3JsZAo+PiDCoCDCoCDCoCMgbWFrZSBp
bnN0YWxsCj4+Cj4+ICsgwqAgSWYgeW91IHdhbnQsIHlvdSBjYW4gcnVuIC4vY29uZmlndXJlIC0t
aGVscCB0byBzZWUgdGhlIGxpc3Qgb2YKPj4gKyDCoCBvcHRpb25zIGF2YWlsYWJsZSBvcHRpb25z
IHdoZW4gYnVpbGRpbmcgYW5kIGluc3RhbGxpbmcgWGVuLgo+PiArCj4+IMKgIMKgIFRoaXMgd2ls
bCBjcmVhdGUgYW5kIGluc3RhbGwgb250byB0aGUgbG9jYWwgbWFjaGluZS4gSXQgd2lsbCBidWls
ZAo+PiDCoCDCoCB0aGUgeGVuIGJpbmFyeSAoeGVuLmd6KSwgdGhlIHRvb2xzIGFuZCB0aGUgZG9j
dW1lbnRhdGlvbi4KPj4KPj4gLS0tIC9kZXYvbnVsbCBUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAg
KzAwMDAKPj4gKysrIGIvYXV0b2dlbi5zaCDCoCDCoCDCoE1vbiBKYW4gMDkgMjE6MzM6NTIgMjAx
MiArMDEwMAo+PiBAQCAtMCwwICsxLDExIEBACj4+ICsjIS9iaW4vc2gKPgo+IEFkZGluZyAtZSBo
ZXJlIC4uLgo+Cj4+ICtybSAtcmYgY29uZmlndXJlCj4+ICtjZCB0b29scwo+PiArYXV0b2hlYWRl
ciAmJiBhdXRvY29uZgo+PiAraWYgWyAiJD8iID0gIjAiIF0KPj4gK3RoZW4KPgo+IC4uLiB3b3Vs
ZCBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIHRoaXMgY29uZGl0aW9uYWwgLi4uCj4KPj4gKyDCoCDC
oGNkIC4uCj4+ICsgwqAgwqBlY2hvICIjIS9iaW4vc2giID4+IGNvbmZpZ3VyZQo+PiArIMKgIMKg
ZWNobyAiY2QgdG9vbHMgJiYgLi9jb25maWd1cmUgXCRAIiA+PiBjb25maWd1cmUKPj4gKyDCoCDC
oGNobW9kICt4IGNvbmZpZ3VyZQo+Cj4gLi4uIGFuZCBjYXRjaCBmYWlsdXJlIGFueXdoZXJlIGhl
cmUuCgpXaWxsIGNoYW5nZSB0aGF0LgoKPgo+PiArZmkKPj4gLS0tIGEvdG9vbHMvUnVsZXMubWsg
wqBUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKPj4gKysrIGIvdG9vbHMvUnVsZXMubWsg
wqBNb24gSmFuIDA5IDIxOjMzOjUyIDIwMTIgKzAxMDAKPj4gQEAgLTMsNiArMyw3IEBACj4+IMKg
IyBgYWxsJyBpcyB0aGUgZGVmYXVsdCB0YXJnZXQKPj4gwqBhbGw6Cj4+Cj4+ICtpbmNsdWRlICQo
WEVOX1JPT1QpL2NvbmZpZy9Ub29scy5tawo+PiDCoGluY2x1ZGUgJChYRU5fUk9PVCkvQ29uZmln
Lm1rCj4KPiBXb3VsZG4ndCB0aGUgb3JkZXIgYmV0dGVyIGJlIHRoZSBvdGhlciB3YXkgYXJvdW5k
IChnZW5lcmljIGJlZm9yZQo+IHN1YmRpciBzcGVjaWZpYyk/CgpTaW5jZSBDb25maWcubWsgdXNl
cyA/PSB3aGVuIHNldHRpbmcgdmFyaWFibGVzLCBJIGRvbid0IHRoaW5rIGl0CnJlYWxseSBtYXR0
ZXJzICh0aGUgb25seSB2YXJpYWJsZSB0aGF0IGNvdWxkIGJlIG92ZXJ3cml0dGVuIGJ5CkNvbmZp
Zy5tayBpcyBQWVRIT04sIGFuZCBpdCBpcyBzZXQgd2l0aCA/PSBpbiBDb25maWcubWspLCBhbnl3
YXksIEkKd2lsbCBjaGFuZ2UgaXQuCgo+Cj4+Cj4+IMKgZXhwb3J0IF9JTlNUQUxMIDo9ICQoSU5T
VEFMTCkKPgo+IEphbgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 10 13:50:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 13:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkc5F-0007Ac-E7; Tue, 10 Jan 2012 13:49:49 +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 1Rkc5E-0007AW-6K
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 13:49:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326203382!10404434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19323 invoked from network); 10 Jan 2012 13:49:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 13:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9922618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 13:49: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; Tue, 10 Jan 2012 13:49:41 +0000
Date: Tue, 10 Jan 2012 13:49:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F0C1AC9020000780006B860@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201101348070.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0C1AC9020000780006B860@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 v4 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 Tue, 10 Jan 2012, Jan Beulich wrote:
> >>> On 09.01.12 at 18:59, <stefano.stabellini@eu.citrix.com> wrote:
> > --- a/xen/common/libelf/libelf-loader.c
> > +++ b/xen/common/libelf/libelf-loader.c
> > @@ -107,11 +107,32 @@ void elf_set_log(struct elf_binary *elf, 
> > elf_log_callback *log_callback,
> >      elf->log_caller_data = log_caller_data;
> >      elf->verbose = verbose;
> >  }
> > +
> > +static int elf_load_image(void *dst, const void *src, uint64_t filesz, 
> > uint64_t memsz)
> > +{
> > +    memcpy(dst, src, filesz);
> > +    memset(dst + filesz, 0, memsz - filesz);
> > +    return 0;
> > +}
> >  #else
> > +#include <asm/guest_access.h>
> > +
> >  void elf_set_verbose(struct elf_binary *elf)
> >  {
> >      elf->verbose = 1;
> >  }
> > +
> > +static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
> > +{
> > +    int rc;
> > +    rc = raw_copy_to_guest(dst, src, filesz);
> > +    if ( rc != 0 )
> > +        return -rc;
> > +    rc = raw_clear_guest(dst + filesz, memsz - filesz);
> > +    if ( rc != 0 )
> > +        return -rc;
> > +    return 0;
> > +}
> 
> I'm afraid a little more care is needed here: filesz and memsz being
> 64-bit values permits them to overflow the "long" of the functions
> called. I think simply checking that both values fit in an unsigned long
> will do for now.

OK

> Also, if you want to return a meaningful error code here, you also
> need to consider that fact as well as the counts being unsigned (or
> otherwise you could e.g. just return "bool").

I'll just return -1, to be consistent with elf_init

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 13:50:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 13:50:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkc5F-0007Ac-E7; Tue, 10 Jan 2012 13:49:49 +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 1Rkc5E-0007AW-6K
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 13:49:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326203382!10404434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19323 invoked from network); 10 Jan 2012 13:49:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 13:49:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9922618"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 13:49: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; Tue, 10 Jan 2012 13:49:41 +0000
Date: Tue, 10 Jan 2012 13:49:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F0C1AC9020000780006B860@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201101348070.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F0C1AC9020000780006B860@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 v4 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 Tue, 10 Jan 2012, Jan Beulich wrote:
> >>> On 09.01.12 at 18:59, <stefano.stabellini@eu.citrix.com> wrote:
> > --- a/xen/common/libelf/libelf-loader.c
> > +++ b/xen/common/libelf/libelf-loader.c
> > @@ -107,11 +107,32 @@ void elf_set_log(struct elf_binary *elf, 
> > elf_log_callback *log_callback,
> >      elf->log_caller_data = log_caller_data;
> >      elf->verbose = verbose;
> >  }
> > +
> > +static int elf_load_image(void *dst, const void *src, uint64_t filesz, 
> > uint64_t memsz)
> > +{
> > +    memcpy(dst, src, filesz);
> > +    memset(dst + filesz, 0, memsz - filesz);
> > +    return 0;
> > +}
> >  #else
> > +#include <asm/guest_access.h>
> > +
> >  void elf_set_verbose(struct elf_binary *elf)
> >  {
> >      elf->verbose = 1;
> >  }
> > +
> > +static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
> > +{
> > +    int rc;
> > +    rc = raw_copy_to_guest(dst, src, filesz);
> > +    if ( rc != 0 )
> > +        return -rc;
> > +    rc = raw_clear_guest(dst + filesz, memsz - filesz);
> > +    if ( rc != 0 )
> > +        return -rc;
> > +    return 0;
> > +}
> 
> I'm afraid a little more care is needed here: filesz and memsz being
> 64-bit values permits them to overflow the "long" of the functions
> called. I think simply checking that both values fit in an unsigned long
> will do for now.

OK

> Also, if you want to return a meaningful error code here, you also
> need to consider that fact as well as the counts being unsigned (or
> otherwise you could e.g. just return "bool").

I'll just return -1, to be consistent with elf_init

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 14:13:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 14:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkcRa-0007Qm-IB; Tue, 10 Jan 2012 14:12:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RkcRY-0007Qb-Sa; Tue, 10 Jan 2012 14:12:53 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326204766!10340192!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29113 invoked from network); 10 Jan 2012 14:12:46 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 14:12:46 -0000
Received: by werg1 with SMTP id g1so10205100wer.30
	for <multiple recipients>; Tue, 10 Jan 2012 06:12:45 -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=rUxqRyQ8MyGBV3esrNMKyiPAJK5egwCgdw6pszXIuus=;
	b=DBhR+exSmCTFZV9mkPlfP1FAwNgqgdDlCoSAPKSBdvOmbUsTxtFgcZ8WfW015QkqGS
	n8QiIaQ8EA8FmfZaGlM3sZ+/78w+2JA0OGE0am95a8HhGFE/TnVUez87v8Trs4LiUnGa
	dCUeCAfMIP3qpxxmJNEH2DanbOyvP29VhTpTM=
Received: by 10.216.138.226 with SMTP id a76mr9443208wej.51.1326204765583;
	Tue, 10 Jan 2012 06:12:45 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id dr5sm1779776wib.0.2012.01.10.06.12.42
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 06:12:43 -0800 (PST)
Message-ID: <4F0C4754.1090702@xen.org>
Date: Tue, 10 Jan 2012 14:12:36 +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-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] FOSDEM: Virtualization and Cloud Devroom agenda 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="===============3237873060475172631=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============3237873060475172631==
Content-Type: multipart/alternative;
 boundary="------------060506020202070504040909"

This is a multi-part message in MIME format.
--------------060506020202070504040909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Please see:
http://fosdem.org/2012/schedule/track/virtualization_and_cloud_devroom

There are a few issues with duplicated names but FOSDEM staff is working
on it.

Cheers
Lars


--------------060506020202070504040909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-text-plain" wrap="true" graphical-quote="true"
      style="font-family: -moz-fixed; font-size: 14px;" lang="x-western">
      <pre wrap="">Please see:
<a class="moz-txt-link-freetext" href="http://fosdem.org/2012/schedule/track/virtualization_and_cloud_devroom">http://fosdem.org/2012/schedule/track/virtualization_and_cloud_devroom</a>

There are a few issues with duplicated names but FOSDEM staff is working
on it.

Cheers
Lars
</pre>
    </div>
  </body>
</html>

--------------060506020202070504040909--


--===============3237873060475172631==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3237873060475172631==--


From xen-devel-bounces@lists.xensource.com Tue Jan 10 14:13:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 14:13:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkcRa-0007Qm-IB; Tue, 10 Jan 2012 14:12:54 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RkcRY-0007Qb-Sa; Tue, 10 Jan 2012 14:12:53 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326204766!10340192!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29113 invoked from network); 10 Jan 2012 14:12:46 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 14:12:46 -0000
Received: by werg1 with SMTP id g1so10205100wer.30
	for <multiple recipients>; Tue, 10 Jan 2012 06:12:45 -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=rUxqRyQ8MyGBV3esrNMKyiPAJK5egwCgdw6pszXIuus=;
	b=DBhR+exSmCTFZV9mkPlfP1FAwNgqgdDlCoSAPKSBdvOmbUsTxtFgcZ8WfW015QkqGS
	n8QiIaQ8EA8FmfZaGlM3sZ+/78w+2JA0OGE0am95a8HhGFE/TnVUez87v8Trs4LiUnGa
	dCUeCAfMIP3qpxxmJNEH2DanbOyvP29VhTpTM=
Received: by 10.216.138.226 with SMTP id a76mr9443208wej.51.1326204765583;
	Tue, 10 Jan 2012 06:12:45 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id dr5sm1779776wib.0.2012.01.10.06.12.42
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 06:12:43 -0800 (PST)
Message-ID: <4F0C4754.1090702@xen.org>
Date: Tue, 10 Jan 2012 14:12:36 +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-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] FOSDEM: Virtualization and Cloud Devroom agenda 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="===============3237873060475172631=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============3237873060475172631==
Content-Type: multipart/alternative;
 boundary="------------060506020202070504040909"

This is a multi-part message in MIME format.
--------------060506020202070504040909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Please see:
http://fosdem.org/2012/schedule/track/virtualization_and_cloud_devroom

There are a few issues with duplicated names but FOSDEM staff is working
on it.

Cheers
Lars


--------------060506020202070504040909
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-text-plain" wrap="true" graphical-quote="true"
      style="font-family: -moz-fixed; font-size: 14px;" lang="x-western">
      <pre wrap="">Please see:
<a class="moz-txt-link-freetext" href="http://fosdem.org/2012/schedule/track/virtualization_and_cloud_devroom">http://fosdem.org/2012/schedule/track/virtualization_and_cloud_devroom</a>

There are a few issues with duplicated names but FOSDEM staff is working
on it.

Cheers
Lars
</pre>
    </div>
  </body>
</html>

--------------060506020202070504040909--


--===============3237873060475172631==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3237873060475172631==--


From xen-devel-bounces@lists.xensource.com Tue Jan 10 14:29:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 14:29:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkchB-0007v9-Pf; Tue, 10 Jan 2012 14:29:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <theubaz@gmail.com>) id 1RkICp-0003RE-6l
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:36:19 +0000
X-Env-Sender: theubaz@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326126971!10230244!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15199 invoked from network); 9 Jan 2012 16:36:12 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 16:36:12 -0000
Received: by iagw33 with SMTP id w33so35891597iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 08:36:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=q5wJ7vH+f5AbvxoQBN5cBSm2QNNnUaxL21UrLpSd5po=;
	b=j7uD0yrZLdomLffei03nMKN40h/zurqqCKHK1pgK36TTfTm6i0sh0l8x7kSq5xfDZO
	H+FTDqViYzh6bti7VOL5ojaIElc/ixZbkhy1ozExSkqfMtrqR112hiR/y3DzZkhECvcH
	OBqt8Rl/oscWKnd2PvOLo67e+q0rcHjrRpwEI=
MIME-Version: 1.0
Received: by 10.42.76.66 with SMTP id d2mr18229189ick.7.1326126970828; Mon, 09
	Jan 2012 08:36:10 -0800 (PST)
Received: by 10.42.97.73 with HTTP; Mon, 9 Jan 2012 08:36:10 -0800 (PST)
In-Reply-To: <20120109122953.GC4424@type.bordeaux.inria.fr>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
	<20120109122953.GC4424@type.bordeaux.inria.fr>
Date: Mon, 9 Jan 2012 11:36:10 -0500
X-Google-Sender-Auth: 40AnRlS6RtBXKHQtgOYVcHmb4JE
Message-ID: <CAH5ygH0qMkk6K0Rs5AKu2EndsC8hb32k8QEQ_y9Xj_rOOcEZRw@mail.gmail.com>
From: John Sherwood <jrs@vt.edu>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, John Sherwood <jrs@vt.edu>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 10 Jan 2012 14:29:00 +0000
Subject: Re: [Xen-devel] extending 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="===============0375396426608364131=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0375396426608364131==
Content-Type: multipart/alternative; boundary=90e6ba3fd25d05f64404b61aff99

--90e6ba3fd25d05f64404b61aff99
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 9, 2012 at 7:29 AM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> John Sherwood, le Tue 03 Jan 2012 15:45:17 -0500, a =E9crit :
> > On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com>
> > wrote:
> >     Can't do that. The PS/2 is one of those legacy beasts that depends =
on
> >     ioports.
> >     But now that I think of it, maybe you can. In the guest config you
> can
> >     specify
> >     the ioports that you want to pass in. I hadn't tried to do this for
> the
> >     keyboard
> >     ports but maybe that will work for you?
> >
> >
> >
> > I tried forwarding the ioports (off the top of my head, I remember
> trying 60
> > and 64) but didn't have any luck - the kb/mouse weren't forwarded despi=
te
> > adding the requisite ioports config as per the docs.
>
> Did you also pass the IRQ?
>
> Samuel
>

I believe so, though I haven't had the time pull up the system I was
working on and look at the configuration files I tried with.

--90e6ba3fd25d05f64404b61aff99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Jan 9, 2012 at 7:29 AM, Samuel T=
hibault <span dir=3D"ltr">&lt;<a href=3D"mailto:samuel.thibault@ens-lyon.or=
g">samuel.thibault@ens-lyon.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
John Sherwood, le Tue 03 Jan 2012 15:45:17 -0500, a =E9crit :<br>
<div class=3D"im">&gt; On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wil=
k &lt;<a href=3D"mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&=
gt;<br>
&gt; wrote:<br>
</div><div class=3D"im">&gt; =A0 =A0 Can&#39;t do that. The PS/2 is one of =
those legacy beasts that depends on<br>
&gt; =A0 =A0 ioports.<br>
&gt; =A0 =A0 But now that I think of it, maybe you can. In the guest config=
 you can<br>
&gt; =A0 =A0 specify<br>
&gt; =A0 =A0 the ioports that you want to pass in. I hadn&#39;t tried to do=
 this for the<br>
&gt; =A0 =A0 keyboard<br>
&gt; =A0 =A0 ports but maybe that will work for you?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I tried forwarding the ioports (off the top of my head, I remember try=
ing 60<br>
&gt; and 64) but didn&#39;t have any luck - the kb/mouse weren&#39;t forwar=
ded despite<br>
&gt; adding the requisite ioports config as per the docs.<br>
<br>
</div>Did you also pass the IRQ?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Samuel<br></font></span></blockquote><div><br>I believe so, though I haven&=
#39;t had the time pull up the system I was working on and look at the conf=
iguration files I tried with.<br></div></div><br>

--90e6ba3fd25d05f64404b61aff99--


--===============0375396426608364131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0375396426608364131==--


From xen-devel-bounces@lists.xensource.com Tue Jan 10 14:29:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 14:29:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkchB-0007v9-Pf; Tue, 10 Jan 2012 14:29:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <theubaz@gmail.com>) id 1RkICp-0003RE-6l
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 16:36:19 +0000
X-Env-Sender: theubaz@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326126971!10230244!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15199 invoked from network); 9 Jan 2012 16:36:12 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 16:36:12 -0000
Received: by iagw33 with SMTP id w33so35891597iag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 08:36:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	bh=q5wJ7vH+f5AbvxoQBN5cBSm2QNNnUaxL21UrLpSd5po=;
	b=j7uD0yrZLdomLffei03nMKN40h/zurqqCKHK1pgK36TTfTm6i0sh0l8x7kSq5xfDZO
	H+FTDqViYzh6bti7VOL5ojaIElc/ixZbkhy1ozExSkqfMtrqR112hiR/y3DzZkhECvcH
	OBqt8Rl/oscWKnd2PvOLo67e+q0rcHjrRpwEI=
MIME-Version: 1.0
Received: by 10.42.76.66 with SMTP id d2mr18229189ick.7.1326126970828; Mon, 09
	Jan 2012 08:36:10 -0800 (PST)
Received: by 10.42.97.73 with HTTP; Mon, 9 Jan 2012 08:36:10 -0800 (PST)
In-Reply-To: <20120109122953.GC4424@type.bordeaux.inria.fr>
References: <CAH5ygH1OyxSRZaGC1RVCeg3tmZSERwhqjSA-bwyVHN9PtKC4yQ@mail.gmail.com>
	<20120103202401.GB17472@phenom.dumpdata.com>
	<CAH5ygH0tV_9UYtopmBZBULm51NAPryJOznouMZm0Oj2MbHHAQw@mail.gmail.com>
	<20120109122953.GC4424@type.bordeaux.inria.fr>
Date: Mon, 9 Jan 2012 11:36:10 -0500
X-Google-Sender-Auth: 40AnRlS6RtBXKHQtgOYVcHmb4JE
Message-ID: <CAH5ygH0qMkk6K0Rs5AKu2EndsC8hb32k8QEQ_y9Xj_rOOcEZRw@mail.gmail.com>
From: John Sherwood <jrs@vt.edu>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>, John Sherwood <jrs@vt.edu>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 10 Jan 2012 14:29:00 +0000
Subject: Re: [Xen-devel] extending 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="===============0375396426608364131=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0375396426608364131==
Content-Type: multipart/alternative; boundary=90e6ba3fd25d05f64404b61aff99

--90e6ba3fd25d05f64404b61aff99
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 9, 2012 at 7:29 AM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> John Sherwood, le Tue 03 Jan 2012 15:45:17 -0500, a =E9crit :
> > On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com>
> > wrote:
> >     Can't do that. The PS/2 is one of those legacy beasts that depends =
on
> >     ioports.
> >     But now that I think of it, maybe you can. In the guest config you
> can
> >     specify
> >     the ioports that you want to pass in. I hadn't tried to do this for
> the
> >     keyboard
> >     ports but maybe that will work for you?
> >
> >
> >
> > I tried forwarding the ioports (off the top of my head, I remember
> trying 60
> > and 64) but didn't have any luck - the kb/mouse weren't forwarded despi=
te
> > adding the requisite ioports config as per the docs.
>
> Did you also pass the IRQ?
>
> Samuel
>

I believe so, though I haven't had the time pull up the system I was
working on and look at the configuration files I tried with.

--90e6ba3fd25d05f64404b61aff99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Jan 9, 2012 at 7:29 AM, Samuel T=
hibault <span dir=3D"ltr">&lt;<a href=3D"mailto:samuel.thibault@ens-lyon.or=
g">samuel.thibault@ens-lyon.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
John Sherwood, le Tue 03 Jan 2012 15:45:17 -0500, a =E9crit :<br>
<div class=3D"im">&gt; On Tue, Jan 3, 2012 at 3:24 PM, Konrad Rzeszutek Wil=
k &lt;<a href=3D"mailto:konrad.wilk@oracle.com">konrad.wilk@oracle.com</a>&=
gt;<br>
&gt; wrote:<br>
</div><div class=3D"im">&gt; =A0 =A0 Can&#39;t do that. The PS/2 is one of =
those legacy beasts that depends on<br>
&gt; =A0 =A0 ioports.<br>
&gt; =A0 =A0 But now that I think of it, maybe you can. In the guest config=
 you can<br>
&gt; =A0 =A0 specify<br>
&gt; =A0 =A0 the ioports that you want to pass in. I hadn&#39;t tried to do=
 this for the<br>
&gt; =A0 =A0 keyboard<br>
&gt; =A0 =A0 ports but maybe that will work for you?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; I tried forwarding the ioports (off the top of my head, I remember try=
ing 60<br>
&gt; and 64) but didn&#39;t have any luck - the kb/mouse weren&#39;t forwar=
ded despite<br>
&gt; adding the requisite ioports config as per the docs.<br>
<br>
</div>Did you also pass the IRQ?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Samuel<br></font></span></blockquote><div><br>I believe so, though I haven&=
#39;t had the time pull up the system I was working on and look at the conf=
iguration files I tried with.<br></div></div><br>

--90e6ba3fd25d05f64404b61aff99--


--===============0375396426608364131==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0375396426608364131==--


From xen-devel-bounces@lists.xensource.com Tue Jan 10 14:29:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 14: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 1RkchC-0007vG-5a; Tue, 10 Jan 2012 14:29:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeff.mercer@gmail.com>) id 1RkORI-0000sT-5u
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 23:15:40 +0000
X-Env-Sender: jeff.mercer@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326150874!60268654!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28128 invoked from network); 9 Jan 2012 23:14:34 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 23:14:34 -0000
Received: by eekd4 with SMTP id d4so15249763eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 15:15:38 -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=//FvllLhPl7xz8R2Gnn45pLorqqXQ1lXrpwqqUool+U=;
	b=x2pePiE7AglJ7/85MvcFH6gsewQSS2+05SXW+7ka+3YqY5yctYmRv2BA3+M/QuRKi8
	RaHtaAlIkHa4CtKqf1H3vZmF2KWFC86DCKPZ/8ywFoma1u5ejO6vwdraIcGbQM3C/cES
	AnU3QdO5+MDtEGyi1Yqg38emItr6uNQNR+klY=
MIME-Version: 1.0
Received: by 10.14.126.11 with SMTP id a11mr7012581eei.44.1326150937102; Mon,
	09 Jan 2012 15:15:37 -0800 (PST)
Received: by 10.14.119.74 with HTTP; Mon, 9 Jan 2012 15:15:37 -0800 (PST)
Date: Mon, 9 Jan 2012 18:15:37 -0500
Message-ID: <CAHFCJmVNm=mEGE07yzBAwEmVj5pmFeHWfxZv1cHLmaPQCHSwCQ@mail.gmail.com>
From: Jeff Mercer <jeff.mercer@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 10 Jan 2012 14:29:00 +0000
Subject: [Xen-devel] VGA Passthrough Experience
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0619626305798403657=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0619626305798403657==
Content-Type: multipart/alternative; boundary=e0cb4e6fefe586491504b62093cc

--e0cb4e6fefe586491504b62093cc
Content-Type: text/plain; charset=ISO-8859-1

This is my first time posting to the mailing list, so I hope I post
everything that is needed.  I built a new computer to play around with VGA
Passthrough and I got it working.  The wiki (
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters) said post
details here.

The computer:

Motherboard: ASRock 890FX Deluxe5
CPU: AMD Phenom(tm) II X6 1090T Processor
Kernel: 3.0.6-gentoo (pvops)
Xen: 4.1.2
DomU Video Card:
Sapphire RADEON HD 6570 Graphics
07:00.0 VGA compatible controller: ATI Technologies Inc Device 6759
07:00.1 Audio device: ATI Technologies Inc Device aa90
The ATI card is secondary to the computer (I have an Nvidia card for
linux).  The ATI was passed through as a primary to the DomU
I passed through both PCI Id's since I wanted audio through the HDMI out as
well.
Guest: Windows XP
Driver: Windows says the video is driver is 8.840.0.0 from 3/9/2011
Windows says the sound driver is 5.0.40001.9 from 7/13/2007

It was a bit of a pain to get working.  The Catalyst Drivers won't install
(it hangs at 'Checking for Hardware').  I tried the version on the cd
bundled with the card and the latest on AMD's website.  Neither would
work.  I decided to click 'Update Driver' in Device Manager and point it
down the expanded Catalyst path and it was able to find the driver and
install it.  That got video to go out of the HDMI but not audio.  The same
trick did not work with the audio device.  I ended up reverting to a
snapshot prior to installing any drivers.  I allowed Windows to connect to
the internet to find the audio drivers before even trying video.  Windows
was able to find something (know idea what) and sound started working.  I
then 'installed' the video drivers and both audio and video were working.
I was able to set the screen to 1920x1080.  The computer is hooked up to a
42" LCD TV in my living room.

I was able to install and play Spore and Star Wars: Empire at War.  Star
Wars: Battlefront 2 installed and started but I was not able to actually
play the game.  It would crash as soon as I started a game.  I have not
tried any other games yet, but I am planning to.  Let me know if you need
any other details or have any questions

-Jeff

--e0cb4e6fefe586491504b62093cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is my first time posting to the mailing list, so I hope I post everyth=
ing that is needed.=A0 I built a new computer to play around with VGA Passt=
hrough and I got it working.=A0 The wiki (<a href=3D"http://wiki.xen.org/wi=
ki/Xen_VGA_Passthrough_Tested_Adapters">http://wiki.xen.org/wiki/Xen_VGA_Pa=
ssthrough_Tested_Adapters</a>) said post details here.<br>
<br>The computer:<br><br>Motherboard: ASRock 890FX Deluxe5<br>CPU: AMD Phen=
om(tm) II X6 1090T Processor<br>Kernel: 3.0.6-gentoo (pvops)<br>Xen: 4.1.2<=
br>DomU Video Card:<br><div style=3D"margin-left:40px">Sapphire RADEON HD 6=
570 Graphics <br>
07:00.0 VGA compatible controller: ATI Technologies Inc Device 6759<br>07:0=
0.1 Audio device: ATI Technologies Inc Device aa90<br></div>The ATI card is=
 secondary to the computer (I have an Nvidia card for linux).=A0 The ATI wa=
s passed through as a primary to the DomU<br>
I passed through both PCI Id&#39;s since I wanted audio through the HDMI ou=
t as well.<br>Guest: Windows XP<br>Driver: Windows says the video is driver=
 is 8.840.0.0 from 3/9/2011<br><div style=3D"margin-left:40px">Windows says=
 the sound driver is 5.0.40001.9 from 7/13/2007<br>
</div><br>It was a bit of a pain to get working.=A0 The Catalyst Drivers wo=
n&#39;t install (it hangs at &#39;Checking for Hardware&#39;).=A0 I tried t=
he version on the cd bundled with the card and the latest on AMD&#39;s webs=
ite.=A0 Neither would work.=A0 I decided to click &#39;Update Driver&#39; i=
n Device Manager and point it down the expanded Catalyst path and it was ab=
le to find the driver and install it.=A0 That got video to go out of the HD=
MI but not audio.=A0 The same trick did not work with the audio device.=A0 =
I ended up reverting to a snapshot prior to installing any drivers.=A0 I al=
lowed Windows to connect to the internet to find the audio drivers before e=
ven trying video.=A0 Windows was able to find something (know idea what) an=
d sound started working.=A0 I then &#39;installed&#39; the video drivers an=
d both audio and video were working.=A0 I was able to set the screen to 192=
0x1080.=A0 The computer is hooked up to a 42&quot; LCD TV in my living room=
.<br>
<br>I was able to install and play Spore and Star Wars: Empire at War.=A0 S=
tar Wars: Battlefront 2 installed and started but I was not able to actuall=
y play the game.=A0 It would crash as soon as I started a game.=A0 I have n=
ot tried any other games yet, but I am planning to.=A0 Let me know if you n=
eed any other details or have any questions<br>
<br>-Jeff<br><br><br>

--e0cb4e6fefe586491504b62093cc--


--===============0619626305798403657==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0619626305798403657==--


From xen-devel-bounces@lists.xensource.com Tue Jan 10 14:29:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 14: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 1RkchC-0007vG-5a; Tue, 10 Jan 2012 14:29:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeff.mercer@gmail.com>) id 1RkORI-0000sT-5u
	for xen-devel@lists.xensource.com; Mon, 09 Jan 2012 23:15:40 +0000
X-Env-Sender: jeff.mercer@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326150874!60268654!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28128 invoked from network); 9 Jan 2012 23:14:34 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	9 Jan 2012 23:14:34 -0000
Received: by eekd4 with SMTP id d4so15249763eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 09 Jan 2012 15:15:38 -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=//FvllLhPl7xz8R2Gnn45pLorqqXQ1lXrpwqqUool+U=;
	b=x2pePiE7AglJ7/85MvcFH6gsewQSS2+05SXW+7ka+3YqY5yctYmRv2BA3+M/QuRKi8
	RaHtaAlIkHa4CtKqf1H3vZmF2KWFC86DCKPZ/8ywFoma1u5ejO6vwdraIcGbQM3C/cES
	AnU3QdO5+MDtEGyi1Yqg38emItr6uNQNR+klY=
MIME-Version: 1.0
Received: by 10.14.126.11 with SMTP id a11mr7012581eei.44.1326150937102; Mon,
	09 Jan 2012 15:15:37 -0800 (PST)
Received: by 10.14.119.74 with HTTP; Mon, 9 Jan 2012 15:15:37 -0800 (PST)
Date: Mon, 9 Jan 2012 18:15:37 -0500
Message-ID: <CAHFCJmVNm=mEGE07yzBAwEmVj5pmFeHWfxZv1cHLmaPQCHSwCQ@mail.gmail.com>
From: Jeff Mercer <jeff.mercer@gmail.com>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Tue, 10 Jan 2012 14:29:00 +0000
Subject: [Xen-devel] VGA Passthrough Experience
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0619626305798403657=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0619626305798403657==
Content-Type: multipart/alternative; boundary=e0cb4e6fefe586491504b62093cc

--e0cb4e6fefe586491504b62093cc
Content-Type: text/plain; charset=ISO-8859-1

This is my first time posting to the mailing list, so I hope I post
everything that is needed.  I built a new computer to play around with VGA
Passthrough and I got it working.  The wiki (
http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters) said post
details here.

The computer:

Motherboard: ASRock 890FX Deluxe5
CPU: AMD Phenom(tm) II X6 1090T Processor
Kernel: 3.0.6-gentoo (pvops)
Xen: 4.1.2
DomU Video Card:
Sapphire RADEON HD 6570 Graphics
07:00.0 VGA compatible controller: ATI Technologies Inc Device 6759
07:00.1 Audio device: ATI Technologies Inc Device aa90
The ATI card is secondary to the computer (I have an Nvidia card for
linux).  The ATI was passed through as a primary to the DomU
I passed through both PCI Id's since I wanted audio through the HDMI out as
well.
Guest: Windows XP
Driver: Windows says the video is driver is 8.840.0.0 from 3/9/2011
Windows says the sound driver is 5.0.40001.9 from 7/13/2007

It was a bit of a pain to get working.  The Catalyst Drivers won't install
(it hangs at 'Checking for Hardware').  I tried the version on the cd
bundled with the card and the latest on AMD's website.  Neither would
work.  I decided to click 'Update Driver' in Device Manager and point it
down the expanded Catalyst path and it was able to find the driver and
install it.  That got video to go out of the HDMI but not audio.  The same
trick did not work with the audio device.  I ended up reverting to a
snapshot prior to installing any drivers.  I allowed Windows to connect to
the internet to find the audio drivers before even trying video.  Windows
was able to find something (know idea what) and sound started working.  I
then 'installed' the video drivers and both audio and video were working.
I was able to set the screen to 1920x1080.  The computer is hooked up to a
42" LCD TV in my living room.

I was able to install and play Spore and Star Wars: Empire at War.  Star
Wars: Battlefront 2 installed and started but I was not able to actually
play the game.  It would crash as soon as I started a game.  I have not
tried any other games yet, but I am planning to.  Let me know if you need
any other details or have any questions

-Jeff

--e0cb4e6fefe586491504b62093cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is my first time posting to the mailing list, so I hope I post everyth=
ing that is needed.=A0 I built a new computer to play around with VGA Passt=
hrough and I got it working.=A0 The wiki (<a href=3D"http://wiki.xen.org/wi=
ki/Xen_VGA_Passthrough_Tested_Adapters">http://wiki.xen.org/wiki/Xen_VGA_Pa=
ssthrough_Tested_Adapters</a>) said post details here.<br>
<br>The computer:<br><br>Motherboard: ASRock 890FX Deluxe5<br>CPU: AMD Phen=
om(tm) II X6 1090T Processor<br>Kernel: 3.0.6-gentoo (pvops)<br>Xen: 4.1.2<=
br>DomU Video Card:<br><div style=3D"margin-left:40px">Sapphire RADEON HD 6=
570 Graphics <br>
07:00.0 VGA compatible controller: ATI Technologies Inc Device 6759<br>07:0=
0.1 Audio device: ATI Technologies Inc Device aa90<br></div>The ATI card is=
 secondary to the computer (I have an Nvidia card for linux).=A0 The ATI wa=
s passed through as a primary to the DomU<br>
I passed through both PCI Id&#39;s since I wanted audio through the HDMI ou=
t as well.<br>Guest: Windows XP<br>Driver: Windows says the video is driver=
 is 8.840.0.0 from 3/9/2011<br><div style=3D"margin-left:40px">Windows says=
 the sound driver is 5.0.40001.9 from 7/13/2007<br>
</div><br>It was a bit of a pain to get working.=A0 The Catalyst Drivers wo=
n&#39;t install (it hangs at &#39;Checking for Hardware&#39;).=A0 I tried t=
he version on the cd bundled with the card and the latest on AMD&#39;s webs=
ite.=A0 Neither would work.=A0 I decided to click &#39;Update Driver&#39; i=
n Device Manager and point it down the expanded Catalyst path and it was ab=
le to find the driver and install it.=A0 That got video to go out of the HD=
MI but not audio.=A0 The same trick did not work with the audio device.=A0 =
I ended up reverting to a snapshot prior to installing any drivers.=A0 I al=
lowed Windows to connect to the internet to find the audio drivers before e=
ven trying video.=A0 Windows was able to find something (know idea what) an=
d sound started working.=A0 I then &#39;installed&#39; the video drivers an=
d both audio and video were working.=A0 I was able to set the screen to 192=
0x1080.=A0 The computer is hooked up to a 42&quot; LCD TV in my living room=
.<br>
<br>I was able to install and play Spore and Star Wars: Empire at War.=A0 S=
tar Wars: Battlefront 2 installed and started but I was not able to actuall=
y play the game.=A0 It would crash as soon as I started a game.=A0 I have n=
ot tried any other games yet, but I am planning to.=A0 Let me know if you n=
eed any other details or have any questions<br>
<br>-Jeff<br><br><br>

--e0cb4e6fefe586491504b62093cc--


--===============0619626305798403657==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0619626305798403657==--


From xen-devel-bounces@lists.xensource.com Tue Jan 10 14:42:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 14:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkctK-0008J1-Ke; Tue, 10 Jan 2012 14:41:34 +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 1RkctJ-0008Iw-Dy
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 14:41:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326206485!8554996!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjY0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1890 invoked from network); 10 Jan 2012 14:41:26 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Jan 2012 14:41:26 -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
	q0AEeSRV031096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Jan 2012 14:40:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0AEeRMc000633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2012 14:40:27 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
	q0AEePi6010469; Tue, 10 Jan 2012 08:40:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 06:40:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA45A40930; Tue, 10 Jan 2012 09:38:37 -0500 (EST)
Date: Tue, 10 Jan 2012 09:38:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120110143837.GB17826@phenom.dumpdata.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
	<20120109150436.GD25563@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCBE178@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10FCBE178@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F0C4DDD.0063,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Tue, Jan 10, 2012 at 05:47:48AM +0000, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Monday, January 09, 2012 11:05 PM
> > 
> > > > But more interestingly - are you building your kernel from scratch? There
> > >
> > > yes
> > >
> > > > was some requirements in having CONFIG_IOMMU_DMAR in the kernels -
> > > > otherwise
> > > > the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.
> > >
> > > Suppose you mean CONFIG_DMAR_TABLE? There's no
> > CONFIG_IOMMU_DMAR
> > > in the latest kernel. Yes, I didn't enable that option, and will have a try.
> > 
> > Yes, that is the option.
> > 
> > >
> > > But a side question is, will enabling VT-d in dom0 conflict with Xen's own
> > > VT-d operations?
> > 
> > No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux's
> > parser won't pick it up.
> 
> Hi, Konrad,
> 
> this information is really great, and now X can be started smoothly, and also
> a simple glxgear runs well! :-) This options deserves an explicit mark in the
> wiki page btw.

Done! If you have a screenshot of the "defective" kernel build that would be usefull
as we can attach it to
http://wiki.xen.org/wiki/Paravirtualized_DRM#X_shows_a_checkerboard_or_just_random_stuff_when_using_i915

> 
> 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 Jan 10 14:42:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 14:42:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkctK-0008J1-Ke; Tue, 10 Jan 2012 14:41:34 +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 1RkctJ-0008Iw-Dy
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 14:41:33 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326206485!8554996!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjY0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1890 invoked from network); 10 Jan 2012 14:41:26 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Jan 2012 14:41:26 -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
	q0AEeSRV031096
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Jan 2012 14:40:29 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0AEeRMc000633
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2012 14:40:27 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
	q0AEePi6010469; Tue, 10 Jan 2012 08:40:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 06:40:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id BA45A40930; Tue, 10 Jan 2012 09:38:37 -0500 (EST)
Date: Tue, 10 Jan 2012 09:38:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120110143837.GB17826@phenom.dumpdata.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
	<20120109150436.GD25563@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCBE178@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10FCBE178@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F0C4DDD.0063,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

On Tue, Jan 10, 2012 at 05:47:48AM +0000, Tian, Kevin wrote:
> > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > Sent: Monday, January 09, 2012 11:05 PM
> > 
> > > > But more interestingly - are you building your kernel from scratch? There
> > >
> > > yes
> > >
> > > > was some requirements in having CONFIG_IOMMU_DMAR in the kernels -
> > > > otherwise
> > > > the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.
> > >
> > > Suppose you mean CONFIG_DMAR_TABLE? There's no
> > CONFIG_IOMMU_DMAR
> > > in the latest kernel. Yes, I didn't enable that option, and will have a try.
> > 
> > Yes, that is the option.
> > 
> > >
> > > But a side question is, will enabling VT-d in dom0 conflict with Xen's own
> > > VT-d operations?
> > 
> > No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux's
> > parser won't pick it up.
> 
> Hi, Konrad,
> 
> this information is really great, and now X can be started smoothly, and also
> a simple glxgear runs well! :-) This options deserves an explicit mark in the
> wiki page btw.

Done! If you have a screenshot of the "defective" kernel build that would be usefull
as we can attach it to
http://wiki.xen.org/wiki/Paravirtualized_DRM#X_shows_a_checkerboard_or_just_random_stuff_when_using_i915

> 
> 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 Jan 10 15:17:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15: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 1RkdRU-0000Nj-9N; Tue, 10 Jan 2012 15:16:52 +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 1RkdRS-0000NT-VT
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:16:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326208603!10459391!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 25650 invoked from network); 10 Jan 2012 15:16:44 -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; 10 Jan 2012 15:16:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 15:16:43 +0000
Message-Id: <4F0C6467020000780006B98D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 15:16:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.com>
	<CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@mail.gmail.com>
In-Reply-To: <CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDEwLjAxLjEyIGF0IDE0OjMyLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiAyMDEyLzEvMTAgSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2Uu
Y29tPjoKPj4+Pj4gT24gMDkuMDEuMTIgYXQgMjE6MzcsIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIu
cGF1QGVudGVsLnVwYy5lZHU+IHdyb3RlOgo+Pj4gQEAgLTg3LDkgKzg4LDIxIEBAIDIuIGNkIHRv
IHhlbi11bnN0YWJsZSAob3Igd2hhdGV2ZXIgeW91IHMKPj4+ICAzLiBGb3IgdGhlIHZlcnkgZmly
c3QgYnVpbGQsIG9yIGlmIHlvdSB3YW50IHRvIGRlc3Ryb3kgYnVpbGQgdHJlZXMsCj4+PiAgICAg
cGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgo+Pj4KPj4+ICsgICBJZiB5b3UgYXJlIGJ1aWxk
aW5nIFhlbiBmcm9tIGEgcmVwb3NpdG9yeSAoZ2l0IG9yIG1lcmN1cmlhbCkgeW91Cj4+PiArICAg
bXVzdCBydW46Cj4+PiArCj4+PiArICAgICMgLi9hdXRvZ2VuLnNoCj4+PiArCj4+PiArICAgQmVm
b3JlIGV4ZWN1dGluZyAuL2NvbmZpZ3VyZSAodGhpcyBzdGVwIGNhbiBiZSBvbW1pdGVkIHdoZW4K
Pj4+ICsgICBidWlsZGluZyBmcm9tIGEgZGlzdHJpYnV0aW9uIHBhY2thZ2UpLgo+Pj4gKwo+Pj4g
KyAgICAjIC4vY29uZmlndXJlCj4+Cj4+IENhbiB0aGVzZSB0d28gc3RlcHMgYmUgYXV0b21hdGVk
IChpLmUuIHRoZSBuZWVkIHRvIHJ1biBlaXRoZXIKPj4gYmUgZGV0ZXJtaW5lZCBieSB0aGUgYWJz
ZW5jZSBvZiBzb21lIGZpbGUocyksIGFuZCB0aGVtIGJlaW5nCj4+IGludm9rZWQgZnJvbSB0aGUg
dG9wIGxldmVsIE1ha2VmaWxlKT8KPiAKPiBJdCBwcm9iYWJseSBjb3VsZCwganVzdCBtYWtpbmcg
YSB0YXJnZXQgZm9yIGNvbmZpZy5oIGluCj4gdG9vbHMvTWFrZWZpbGUuIEFyZSB5b3Ugc3VyZSB0
aGlzIGlzIHdoYXQgd2Ugd2FudD8gVGhlIGNvbmZpZ3VyZQo+IHNjcmlwdCBoYXMgc2V2ZXJhbCBi
dWlsZCBvcHRpb25zIHRoYXQgc2hvdWxkIGJlIHNldCBieSB0aGUgdXNlciAob3IgYXQKPiBsZWFz
dCByZXZpZXdlZCwgc28gdGhlIHVzZXIga25vdyBpdCBoYXMgYnVpbGQvaW5zdGFsbCBvcHRpb25z
KS4KCkxldCdzIHNlZSB3aGF0IG90aGVyIHdhbnQ7IG15IHRoaW5raW5nIGlzIHRoYXQgaWYgb25l
IGRpZG4ndCBjYXJlIHRvCnJ1biAuL2NvbmZpZ3VyZSBtYW51YWxseSwgZGVmYXVsdCBzZXR0aW5n
cyBhcmUgaW50ZW5kZWQuIFRoYXQncwp3aGF0IGFuIGludm9jYXRpb24gd2l0aG91dCBhcmd1bWVu
dHMgc2hvdWxkIHJlc3VsdCBpbiwgd2l0aG91dAphbnkgdXNlciBpbnRlcmFjdGlvbi4KCkphbgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 10 15:17:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15: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 1RkdRU-0000Nj-9N; Tue, 10 Jan 2012 15:16:52 +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 1RkdRS-0000NT-VT
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:16:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326208603!10459391!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 25650 invoked from network); 10 Jan 2012 15:16:44 -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; 10 Jan 2012 15:16:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 15:16:43 +0000
Message-Id: <4F0C6467020000780006B98D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 15:16:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?=" <roger.pau@entel.upc.edu>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.com>
	<CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@mail.gmail.com>
In-Reply-To: <CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Pj4+IE9uIDEwLjAxLjEyIGF0IDE0OjMyLCBSb2dlciBQYXUgTW9ubsOpPHJvZ2VyLnBhdUBlbnRl
bC51cGMuZWR1PiB3cm90ZToKPiAyMDEyLzEvMTAgSmFuIEJldWxpY2ggPEpCZXVsaWNoQHN1c2Uu
Y29tPjoKPj4+Pj4gT24gMDkuMDEuMTIgYXQgMjE6MzcsIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIu
cGF1QGVudGVsLnVwYy5lZHU+IHdyb3RlOgo+Pj4gQEAgLTg3LDkgKzg4LDIxIEBAIDIuIGNkIHRv
IHhlbi11bnN0YWJsZSAob3Igd2hhdGV2ZXIgeW91IHMKPj4+ICAzLiBGb3IgdGhlIHZlcnkgZmly
c3QgYnVpbGQsIG9yIGlmIHlvdSB3YW50IHRvIGRlc3Ryb3kgYnVpbGQgdHJlZXMsCj4+PiAgICAg
cGVyZm9ybSB0aGUgZm9sbG93aW5nIHN0ZXBzOgo+Pj4KPj4+ICsgICBJZiB5b3UgYXJlIGJ1aWxk
aW5nIFhlbiBmcm9tIGEgcmVwb3NpdG9yeSAoZ2l0IG9yIG1lcmN1cmlhbCkgeW91Cj4+PiArICAg
bXVzdCBydW46Cj4+PiArCj4+PiArICAgICMgLi9hdXRvZ2VuLnNoCj4+PiArCj4+PiArICAgQmVm
b3JlIGV4ZWN1dGluZyAuL2NvbmZpZ3VyZSAodGhpcyBzdGVwIGNhbiBiZSBvbW1pdGVkIHdoZW4K
Pj4+ICsgICBidWlsZGluZyBmcm9tIGEgZGlzdHJpYnV0aW9uIHBhY2thZ2UpLgo+Pj4gKwo+Pj4g
KyAgICAjIC4vY29uZmlndXJlCj4+Cj4+IENhbiB0aGVzZSB0d28gc3RlcHMgYmUgYXV0b21hdGVk
IChpLmUuIHRoZSBuZWVkIHRvIHJ1biBlaXRoZXIKPj4gYmUgZGV0ZXJtaW5lZCBieSB0aGUgYWJz
ZW5jZSBvZiBzb21lIGZpbGUocyksIGFuZCB0aGVtIGJlaW5nCj4+IGludm9rZWQgZnJvbSB0aGUg
dG9wIGxldmVsIE1ha2VmaWxlKT8KPiAKPiBJdCBwcm9iYWJseSBjb3VsZCwganVzdCBtYWtpbmcg
YSB0YXJnZXQgZm9yIGNvbmZpZy5oIGluCj4gdG9vbHMvTWFrZWZpbGUuIEFyZSB5b3Ugc3VyZSB0
aGlzIGlzIHdoYXQgd2Ugd2FudD8gVGhlIGNvbmZpZ3VyZQo+IHNjcmlwdCBoYXMgc2V2ZXJhbCBi
dWlsZCBvcHRpb25zIHRoYXQgc2hvdWxkIGJlIHNldCBieSB0aGUgdXNlciAob3IgYXQKPiBsZWFz
dCByZXZpZXdlZCwgc28gdGhlIHVzZXIga25vdyBpdCBoYXMgYnVpbGQvaW5zdGFsbCBvcHRpb25z
KS4KCkxldCdzIHNlZSB3aGF0IG90aGVyIHdhbnQ7IG15IHRoaW5raW5nIGlzIHRoYXQgaWYgb25l
IGRpZG4ndCBjYXJlIHRvCnJ1biAuL2NvbmZpZ3VyZSBtYW51YWxseSwgZGVmYXVsdCBzZXR0aW5n
cyBhcmUgaW50ZW5kZWQuIFRoYXQncwp3aGF0IGFuIGludm9jYXRpb24gd2l0aG91dCBhcmd1bWVu
dHMgc2hvdWxkIHJlc3VsdCBpbiwgd2l0aG91dAphbnkgdXNlciBpbnRlcmFjdGlvbi4KCkphbgoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMu
eGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 10 15:37:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkdjv-0001V4-0a; Tue, 10 Jan 2012 15:35:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rkdju-0001Uq-3f
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:35:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326209747!8561048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6151 invoked from network); 10 Jan 2012 15:35:48 -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;
	10 Jan 2012 15:35:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9926554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 15:35:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 15:35: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
	1Rkdjn-0001To-6I; Tue, 10 Jan 2012 15:35:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rkdjm-0004IA-Uy;
	Tue, 10 Jan 2012 15:35:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.23250.590966.304326@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 15:35:46 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <90f764bf02c3c7f78153.1326145234@xdev.gridcentric.ca>
References: <90f764bf02c3c7f78153.1326145234@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [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

Andres Lagar-Cavilla writes ("[PATCH] 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.

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 Jan 10 15:37:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15:37:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkdjv-0001V4-0a; Tue, 10 Jan 2012 15:35:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rkdju-0001Uq-3f
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:35:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326209747!8561048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6151 invoked from network); 10 Jan 2012 15:35:48 -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;
	10 Jan 2012 15:35:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9926554"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 15:35:47 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 15:35: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
	1Rkdjn-0001To-6I; Tue, 10 Jan 2012 15:35:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rkdjm-0004IA-Uy;
	Tue, 10 Jan 2012 15:35:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.23250.590966.304326@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 15:35:46 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <90f764bf02c3c7f78153.1326145234@xdev.gridcentric.ca>
References: <90f764bf02c3c7f78153.1326145234@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [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

Andres Lagar-Cavilla writes ("[PATCH] 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.

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 Jan 10 15:39:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15: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 1RkdnG-0001fD-M7; Tue, 10 Jan 2012 15:39:22 +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 1RkdnF-0001ez-LL
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:39:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326209954!2328847!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5776 invoked from network); 10 Jan 2012 15:39:14 -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;
	10 Jan 2012 15:39:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9926650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 15:39:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 15:39: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
	1Rkdn6-0001Uw-7x; Tue, 10 Jan 2012 15:39:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rkdn6-0004nZ-5t;
	Tue, 10 Jan 2012 15:39:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.23456.106883.226823@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 15:39:12 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <patchbomb.1326145399@xdev.gridcentric.ca>
References: <patchbomb.1326145399@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 0 of 2] Tools: memshr cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 0 of 2] Tools: memshr cleanups"):
> Clean up the coding style of memshr in preparation for sharing updates.

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 Jan 10 15:39:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15: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 1RkdnG-0001fD-M7; Tue, 10 Jan 2012 15:39:22 +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 1RkdnF-0001ez-LL
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:39:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326209954!2328847!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5776 invoked from network); 10 Jan 2012 15:39:14 -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;
	10 Jan 2012 15:39:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9926650"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 15:39:12 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 15:39: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
	1Rkdn6-0001Uw-7x; Tue, 10 Jan 2012 15:39:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rkdn6-0004nZ-5t;
	Tue, 10 Jan 2012 15:39:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.23456.106883.226823@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 15:39:12 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
In-Reply-To: <patchbomb.1326145399@xdev.gridcentric.ca>
References: <patchbomb.1326145399@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"adin@gridcentric.ca" <adin@gridcentric.ca>
Subject: Re: [Xen-devel] [PATCH 0 of 2] Tools: memshr cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[PATCH 0 of 2] Tools: memshr cleanups"):
> Clean up the coding style of memshr in preparation for sharing updates.

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 Jan 10 15:55:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rke1w-0002JQ-4D; Tue, 10 Jan 2012 15:54:32 +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 1Rke1u-0002JJ-Uu
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:54:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326210740!47964577!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTU2NzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28811 invoked from network); 10 Jan 2012 15:52:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 15:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320642000"; d="scan'208";a="20725425"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 10:54: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; Tue, 10 Jan 2012 10:54:28 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0AFsQW3005862;
	Tue, 10 Jan 2012 07:54:26 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 15:54:20 +0000
Message-ID: <1326210860-20321-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH] Add .gitignore files for files generated by the
	hypervisor build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
More or fewer .gitignore files could be used.  Let me know which is
preferred.
---
 .gitignore     |    4 ++++
 xen/.gitignore |   20 ++++++++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 xen/.gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..c937885
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,4 @@
+*.o
+*.o.d
+*.s.d
+cscope.*
diff --git a/xen/.gitignore b/xen/.gitignore
new file mode 100644
index 0000000..3495de9
--- /dev/null
+++ b/xen/.gitignore
@@ -0,0 +1,20 @@
+.banner
+arch/*/.xen.lds.d
+arch/*/asm-offsets.s
+arch/*/xen.lds
+arch/x86/.efi.lds.d
+arch/x86/boot/mkelf32
+arch/x86/boot/reloc.S
+arch/x86/efi.lds
+arch/x86/efi/disabled
+arch/x86/efi/mkreloc
+include/asm
+include/asm-*/asm-offsets.h
+include/compat/
+include/headers.chk
+include/xen/compile.h
+tools/figlet/figlet
+tools/symbols
+xen
+xen-syms
+xen.gz
-- 
1.7.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 Jan 10 15:55:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rke1w-0002JQ-4D; Tue, 10 Jan 2012 15:54:32 +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 1Rke1u-0002JJ-Uu
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:54:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326210740!47964577!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTU2NzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28811 invoked from network); 10 Jan 2012 15:52:21 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 15:52:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320642000"; d="scan'208";a="20725425"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 10:54: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; Tue, 10 Jan 2012 10:54:28 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0AFsQW3005862;
	Tue, 10 Jan 2012 07:54:26 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 15:54:20 +0000
Message-ID: <1326210860-20321-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>
Subject: [Xen-devel] [PATCH] Add .gitignore files for files generated by the
	hypervisor build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
More or fewer .gitignore files could be used.  Let me know which is
preferred.
---
 .gitignore     |    4 ++++
 xen/.gitignore |   20 ++++++++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 xen/.gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..c937885
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,4 @@
+*.o
+*.o.d
+*.s.d
+cscope.*
diff --git a/xen/.gitignore b/xen/.gitignore
new file mode 100644
index 0000000..3495de9
--- /dev/null
+++ b/xen/.gitignore
@@ -0,0 +1,20 @@
+.banner
+arch/*/.xen.lds.d
+arch/*/asm-offsets.s
+arch/*/xen.lds
+arch/x86/.efi.lds.d
+arch/x86/boot/mkelf32
+arch/x86/boot/reloc.S
+arch/x86/efi.lds
+arch/x86/efi/disabled
+arch/x86/efi/mkreloc
+include/asm
+include/asm-*/asm-offsets.h
+include/compat/
+include/headers.chk
+include/xen/compile.h
+tools/figlet/figlet
+tools/symbols
+xen
+xen-syms
+xen.gz
-- 
1.7.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 Jan 10 15:58:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rke5Z-0002S6-P5; Tue, 10 Jan 2012 15:58: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 1Rke5X-0002Rr-TN
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:58:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326211089!8534895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14082 invoked from network); 10 Jan 2012 15:58:09 -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;
	10 Jan 2012 15:58:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927224"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 15:58:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 15:58:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rke5Q-0001bu-N4; Tue, 10 Jan 2012 15:58:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rke5Q-00057P-ME;
	Tue, 10 Jan 2012 15:58:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.24592.676628.285657@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 15:58:08 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED1913@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED1913@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 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

Paul Durrant writes ("Re: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID save/restore and migrate"):
> Ping? Patch 3 was integrated on Dec 18th but I don't see the rest as yet. Is there something more I need to do?

I've applied 1,2,4 now, 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 Jan 10 15:58:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 15:58:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rke5Z-0002S6-P5; Tue, 10 Jan 2012 15:58: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 1Rke5X-0002Rr-TN
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 15:58:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326211089!8534895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14082 invoked from network); 10 Jan 2012 15:58:09 -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;
	10 Jan 2012 15:58:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927224"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 15:58:09 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 15:58:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rke5Q-0001bu-N4; Tue, 10 Jan 2012 15:58:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rke5Q-00057P-ME;
	Tue, 10 Jan 2012 15:58:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.24592.676628.285657@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 15:58:08 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B598ED1913@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED1913@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 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

Paul Durrant writes ("Re: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID save/restore and migrate"):
> Ping? Patch 3 was integrated on Dec 18th but I don't see the rest as yet. Is there something more I need to do?

I've applied 1,2,4 now, 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 Jan 10 16:04:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeAs-00035x-Ll; Tue, 10 Jan 2012 16:03: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 1RkeAr-00035m-MA
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:03:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326211419!10404281!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3234 invoked from network); 10 Jan 2012 16:03:39 -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;
	10 Jan 2012 16:03:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:03: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, 10 Jan 2012 16:03: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
	1RkeAk-0001dj-Js; Tue, 10 Jan 2012 16:03:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeAk-00058t-J1;
	Tue, 10 Jan 2012 16:03:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.24922.535085.662049@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:03:38 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@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 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

Roger Pau Monne writes ("[Xen-devel] [PATCH 0 of 4 v3] build: various fixes for building with uclibc and libiconv"):
> 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.

Applied all four, 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 Jan 10 16:04:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeAs-00035x-Ll; Tue, 10 Jan 2012 16:03: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 1RkeAr-00035m-MA
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:03:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326211419!10404281!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3234 invoked from network); 10 Jan 2012 16:03:39 -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;
	10 Jan 2012 16:03:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:03: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, 10 Jan 2012 16:03: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
	1RkeAk-0001dj-Js; Tue, 10 Jan 2012 16:03:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeAk-00058t-J1;
	Tue, 10 Jan 2012 16:03:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.24922.535085.662049@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:03:38 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1324370958@alpine.localdomain>
References: <patchbomb.1324370958@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 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

Roger Pau Monne writes ("[Xen-devel] [PATCH 0 of 4 v3] build: various fixes for building with uclibc and libiconv"):
> 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.

Applied all four, 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 Jan 10 16:06:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:06:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeCO-0003Ah-8K; Tue, 10 Jan 2012 16:05: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 1RkeCM-0003AT-KX
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:05:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326211512!2332870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31192 invoked from network); 10 Jan 2012 16:05:12 -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;
	10 Jan 2012 16:05:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:05: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, 10 Jan 2012 16:05: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
	1RkeCF-0001eR-GM; Tue, 10 Jan 2012 16:05:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeCF-0005BK-FP;
	Tue, 10 Jan 2012 16:05:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25011.994245.898040@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:05:07 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1325689529-16546-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <4F046A30.6000009@tycho.nsa.gov>
	<1325689529-16546-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 1/2] docs: Update xsm-flask documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 1/2] docs: Update xsm-flask documentation"):
> diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt

I've applied these two (the docs, and the policy update).

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 Jan 10 16:06:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:06:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeCO-0003Ah-8K; Tue, 10 Jan 2012 16:05: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 1RkeCM-0003AT-KX
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:05:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326211512!2332870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31192 invoked from network); 10 Jan 2012 16:05:12 -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;
	10 Jan 2012 16:05:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927439"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:05: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, 10 Jan 2012 16:05: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
	1RkeCF-0001eR-GM; Tue, 10 Jan 2012 16:05:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeCF-0005BK-FP;
	Tue, 10 Jan 2012 16:05:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25011.994245.898040@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:05:07 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1325689529-16546-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <4F046A30.6000009@tycho.nsa.gov>
	<1325689529-16546-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 1/2] docs: Update xsm-flask documentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 1/2] docs: Update xsm-flask documentation"):
> diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt

I've applied these two (the docs, and the policy update).

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 Jan 10 16:07:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:07:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeE5-0003HY-PF; Tue, 10 Jan 2012 16:07:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RkeE3-0003HS-OF
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:07:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326211577!51616985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17316 invoked from network); 10 Jan 2012 16:06:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:06:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 16:06: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
	1RkeDo-0001f0-Rz; Tue, 10 Jan 2012 16:06:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeDo-0005BW-QS;
	Tue, 10 Jan 2012 16:06:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25112.797298.981392@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:06:48 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1325857080.25206.499.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20229.58021.365808.925949@mariner.uk.xensource.com>
	<1325857080.25206.499.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] RFC: Still TODO for 4.2?"):
> I'd argue that the json output should be the default with sxp requiring
> a special option, even though that break backwards compat with xm. I
> have a hard time believing that the sexp printed by xl is close enough
> to the xm one that people haven't already been hacking around it in
> their parsers anyway...

Yes.  Now that we have a global xl configuration file, we could put an
option in there to revert to the weird sexps.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:07:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:07:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeE5-0003HY-PF; Tue, 10 Jan 2012 16:07:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RkeE3-0003HS-OF
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:07:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326211577!51616985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17316 invoked from network); 10 Jan 2012 16:06:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:06:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 16:06: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
	1RkeDo-0001f0-Rz; Tue, 10 Jan 2012 16:06:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeDo-0005BW-QS;
	Tue, 10 Jan 2012 16:06:48 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25112.797298.981392@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:06:48 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1325857080.25206.499.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20229.58021.365808.925949@mariner.uk.xensource.com>
	<1325857080.25206.499.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] RFC: Still TODO for 4.2?"):
> I'd argue that the json output should be the default with sxp requiring
> a special option, even though that break backwards compat with xm. I
> have a hard time believing that the sexp printed by xl is close enough
> to the xm one that people haven't already been hacking around it in
> their parsers anyway...

Yes.  Now that we have a global xl configuration file, we could put an
option in there to revert to the weird sexps.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:11:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16: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 1RkeHP-0003Yd-IP; Tue, 10 Jan 2012 16:10: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 1RkeHP-0003Y7-1m
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:10:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326211824!10335741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24053 invoked from network); 10 Jan 2012 16:10:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:10:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 16:10:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkeHI-0001gL-D4; Tue, 10 Jan 2012 16:10:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeHI-0005D4-CH;
	Tue, 10 Jan 2012 16:10:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25328.167015.28718@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:10:24 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK7HauKbX5yXA4VahVYmhUZ8udiG4mRCE1b+MpS9jF5N2w@mail.gmail.com>
References: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
	<1325608320.25206.161.camel@zakaz.uk.xensource.com>
	<CAPLaKK7HauKbX5yXA4VahVYmhUZ8udiG4mRCE1b+MpS9jF5N2w@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 v2] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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] pygrub: fix extlinux =
parsing> Can this patch be backported to 4.1 at least (I don't think 4.0 is=
 necessary)

Done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:11:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16: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 1RkeHP-0003Yd-IP; Tue, 10 Jan 2012 16:10: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 1RkeHP-0003Y7-1m
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:10:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326211824!10335741!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24053 invoked from network); 10 Jan 2012 16:10:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927657"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:10:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 16:10:24 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkeHI-0001gL-D4; Tue, 10 Jan 2012 16:10:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeHI-0005D4-CH;
	Tue, 10 Jan 2012 16:10:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25328.167015.28718@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:10:24 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK7HauKbX5yXA4VahVYmhUZ8udiG4mRCE1b+MpS9jF5N2w@mail.gmail.com>
References: <6fcc1c479ee68f27233a.1325592859@loki.upc.es>
	<1325608320.25206.161.camel@zakaz.uk.xensource.com>
	<CAPLaKK7HauKbX5yXA4VahVYmhUZ8udiG4mRCE1b+MpS9jF5N2w@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 v2] pygrub: fix extlinux parsing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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] pygrub: fix extlinux =
parsing> Can this patch be backported to 4.1 at least (I don't think 4.0 is=
 necessary)

Done.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeJ6-0003fx-9l; Tue, 10 Jan 2012 16:12: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 1RkeJ4-0003fY-Oz
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:12:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326211883!49663337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2792 invoked from network); 10 Jan 2012 16:11:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927735"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:12: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, 10 Jan 2012 16:12:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkeIy-0001h1-9X; Tue, 10 Jan 2012 16:12:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeIy-0005FC-81;
	Tue, 10 Jan 2012 16:12:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25432.188687.326943@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:12:08 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2f5a98692acde9e74d40.1325788881@probook.site>
References: <2f5a98692acde9e74d40.1325788881@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] add feature flag to xenstore
	for	XS_RESET_WATCHES
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] add feature flag to xenstore for XS_RESET_WATCHES"):
> add feature flag to xenstore for XS_RESET_WATCHES
> 
> Tell guest about availibilty of xenstoreds XS_RESET_WATCHES function.
> Guests can not issue this command unconditionally because some buggy
> toolstacks (such as EC2) do not ignore unknown commands properly.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

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 Jan 10 16:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeJ6-0003fx-9l; Tue, 10 Jan 2012 16:12: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 1RkeJ4-0003fY-Oz
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:12:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326211883!49663337!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2792 invoked from network); 10 Jan 2012 16:11:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:11:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927735"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:12: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, 10 Jan 2012 16:12:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkeIy-0001h1-9X; Tue, 10 Jan 2012 16:12:08 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeIy-0005FC-81;
	Tue, 10 Jan 2012 16:12:08 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25432.188687.326943@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:12:08 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2f5a98692acde9e74d40.1325788881@probook.site>
References: <2f5a98692acde9e74d40.1325788881@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] add feature flag to xenstore
	for	XS_RESET_WATCHES
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] add feature flag to xenstore for XS_RESET_WATCHES"):
> add feature flag to xenstore for XS_RESET_WATCHES
> 
> Tell guest about availibilty of xenstoreds XS_RESET_WATCHES function.
> Guests can not issue this command unconditionally because some buggy
> toolstacks (such as EC2) do not ignore unknown commands properly.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

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 Jan 10 16:14:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 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 1RkeKY-0003nC-PH; Tue, 10 Jan 2012 16:13: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 1RkeKW-0003md-S3
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:13:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326212018!10462635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4675 invoked from network); 10 Jan 2012 16:13:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16: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; Tue, 10 Jan 2012 16:13: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
	1RkeKQ-0001hV-Gc; Tue, 10 Jan 2012 16:13:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeKQ-0005Hm-Fg;
	Tue, 10 Jan 2012 16:13:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25522.458262.291430@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:13:38 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F05FACD.6050000@tycho.nsa.gov>
References: <alpine.DEB.2.00.1201051448320.3150@kaball-desktop>
	<20229.61565.124935.656551@mariner.uk.xensource.com>
	<4F05FACD.6050000@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xl.pod.1: introduction to FLASK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] xl.pod.1: introduction to FLASK"):
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Thanks, I've applied the patch from Stefano's mail.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:14:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 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 1RkeKY-0003nC-PH; Tue, 10 Jan 2012 16:13: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 1RkeKW-0003md-S3
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:13:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326212018!10462635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4675 invoked from network); 10 Jan 2012 16:13:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9927777"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16: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; Tue, 10 Jan 2012 16:13: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
	1RkeKQ-0001hV-Gc; Tue, 10 Jan 2012 16:13:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeKQ-0005Hm-Fg;
	Tue, 10 Jan 2012 16:13:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.25522.458262.291430@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:13:38 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F05FACD.6050000@tycho.nsa.gov>
References: <alpine.DEB.2.00.1201051448320.3150@kaball-desktop>
	<20229.61565.124935.656551@mariner.uk.xensource.com>
	<4F05FACD.6050000@tycho.nsa.gov>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xl.pod.1: introduction to FLASK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] xl.pod.1: introduction to FLASK"):
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Thanks, I've applied the patch from Stefano's mail.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:16:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeNC-0003zo-C4; Tue, 10 Jan 2012 16:16:30 +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 1RkeNB-0003zh-Gf
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:16:29 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326212166!61875438!1
X-Originating-IP: [220.181.15.44]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ0ID0+IDIwMDgy\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ0ID0+IDIwMDgy\n,HTML_20_30,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16181 invoked from network); 10 Jan 2012 16:16:07 -0000
Received: from m15-44.126.com (HELO m15-44.126.com) (220.181.15.44)
	by server-15.tower-27.messagelabs.com with SMTP;
	10 Jan 2012 16:16:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:Subject:
	MIME-Version:Content-Type; bh=xNT6i4s7C5/39PJqjqq1nxx9XbImL+nsg4
	ofAuGBElg=; b=JlsniYcb2dKlXdHeehH7EyuHQDM2sXl4r6ZERcpZK0N49pZzaG
	XAhqjPfY2P+4R18MAgLsEDJ4M/tCWXM2pGQaaPjCf7WgPwBGX22+i6Yg3K+npAtH
	NXNHRD0ZUrsInOXbPr/Iwn6y8Gxap4f59bo+u6iCLb0NjH5SwepWcET70=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr44 (Coremail)
	; Wed, 11 Jan 2012 00:16:14 +0800 (CST)
Date: Wed, 11 Jan 2012 00:16:14 +0800 (CST)
From: gavin <gbtux@126.com>
To: George.Dunlap@eu.citrix.com
Message-ID: <25c0a808.31600.134c867d1ed.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-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: jxo4imZvb3Rlcl9odG09NzUwOjgx
X-CM-TRANSID: LMqowECJy0JRZAxPKbZgAA--.3W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiWBgxnE3AJ6bs8QADs-
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] How to get the cache miss ratio of Guest 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="===============2077148942921142814=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2077148942921142814==
Content-Type: multipart/alternative; 
	boundary="----=_Part_550410_1944125638.1326212174317"

------=_Part_550410_1944125638.1326212174317
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi George,


I noticed that the credit2 scheduling algorithm has one runqueue every L2 cache that is shared by cores in one socket. If vCPUs, which need to communicate more with each other, are assigned to the cores sharing the same L2 cache, the L2 cache miss ratio of Guest VM may be reduced. And also, the performance of the Guest VM will be improved. Is it right? But, how to test the cache miss ratio of L2 in Guest VM? Are the tools that used to test the cache miss ratio in non-virtualized environment can be used in Xen Guest VM?


Thank you very much.


--
Best Regards,
Gavin
------=_Part_550410_1944125638.1326212174317
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,</div><div><br></div><div>I noticed that the credit2 scheduling algorithm has one runqueue every L2 cache that is shared by cores in one socket. If vCPUs, which need to communicate more with each other, are assigned to the cores sharing the same L2 cache, the L2 cache miss ratio of Guest VM may be reduced. And also, the performance of the Guest VM will be improved. Is it right? But, how to test the cache miss ratio of L2 in Guest VM? Are the tools that used to test the cache miss ratio in non-virtualized environment can be used in Xen Guest VM?
</div><div><br></div><div>Thank you very much.</div><br><div>--<br>Best Regards,<div>Gavin</div></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_550410_1944125638.1326212174317--



--===============2077148942921142814==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2077148942921142814==--



From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:16:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:16:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeNC-0003zo-C4; Tue, 10 Jan 2012 16:16:30 +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 1RkeNB-0003zh-Gf
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:16:29 +0000
X-Env-Sender: gbtux@126.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326212166!61875438!1
X-Originating-IP: [220.181.15.44]
X-SpamReason: No, hits=0.9 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ0ID0+IDIwMDgy\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQ0ID0+IDIwMDgy\n,HTML_20_30,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16181 invoked from network); 10 Jan 2012 16:16:07 -0000
Received: from m15-44.126.com (HELO m15-44.126.com) (220.181.15.44)
	by server-15.tower-27.messagelabs.com with SMTP;
	10 Jan 2012 16:16:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com;
	s=s110527; h=Received:Date:From:To:Cc:Message-ID:Subject:
	MIME-Version:Content-Type; bh=xNT6i4s7C5/39PJqjqq1nxx9XbImL+nsg4
	ofAuGBElg=; b=JlsniYcb2dKlXdHeehH7EyuHQDM2sXl4r6ZERcpZK0N49pZzaG
	XAhqjPfY2P+4R18MAgLsEDJ4M/tCWXM2pGQaaPjCf7WgPwBGX22+i6Yg3K+npAtH
	NXNHRD0ZUrsInOXbPr/Iwn6y8Gxap4f59bo+u6iCLb0NjH5SwepWcET70=
Received: from gbtux ( [124.16.139.196] ) by ajax-webmail-wmsvr44 (Coremail)
	; Wed, 11 Jan 2012 00:16:14 +0800 (CST)
Date: Wed, 11 Jan 2012 00:16:14 +0800 (CST)
From: gavin <gbtux@126.com>
To: George.Dunlap@eu.citrix.com
Message-ID: <25c0a808.31600.134c867d1ed.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-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: jxo4imZvb3Rlcl9odG09NzUwOjgx
X-CM-TRANSID: LMqowECJy0JRZAxPKbZgAA--.3W
X-CM-SenderInfo: pjew35a6rslhhfrp/1tbiWBgxnE3AJ6bs8QADs-
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] How to get the cache miss ratio of Guest 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="===============2077148942921142814=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2077148942921142814==
Content-Type: multipart/alternative; 
	boundary="----=_Part_550410_1944125638.1326212174317"

------=_Part_550410_1944125638.1326212174317
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi George,


I noticed that the credit2 scheduling algorithm has one runqueue every L2 cache that is shared by cores in one socket. If vCPUs, which need to communicate more with each other, are assigned to the cores sharing the same L2 cache, the L2 cache miss ratio of Guest VM may be reduced. And also, the performance of the Guest VM will be improved. Is it right? But, how to test the cache miss ratio of L2 in Guest VM? Are the tools that used to test the cache miss ratio in non-virtualized environment can be used in Xen Guest VM?


Thank you very much.


--
Best Regards,
Gavin
------=_Part_550410_1944125638.1326212174317
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,</div><div><br></div><div>I noticed that the credit2 scheduling algorithm has one runqueue every L2 cache that is shared by cores in one socket. If vCPUs, which need to communicate more with each other, are assigned to the cores sharing the same L2 cache, the L2 cache miss ratio of Guest VM may be reduced. And also, the performance of the Guest VM will be improved. Is it right? But, how to test the cache miss ratio of L2 in Guest VM? Are the tools that used to test the cache miss ratio in non-virtualized environment can be used in Xen Guest VM?
</div><div><br></div><div>Thank you very much.</div><br><div>--<br>Best Regards,<div>Gavin</div></div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_550410_1944125638.1326212174317--



--===============2077148942921142814==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2077148942921142814==--



From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:35:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkefO-0004NV-Tm; Tue, 10 Jan 2012 16:35:18 +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 1RkefN-0004NF-Bg
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:35:17 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326213246!60406823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21671 invoked from network); 10 Jan 2012 16:34:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:34:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9928674"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:35:11 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 10 Jan 2012
	16:35:11 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 10 Jan 2012 16:35:08 +0000
Thread-Topic: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID
	save/restore and migrate
Thread-Index: AczPsKXuRxB+ZsnxRg68vcZlvmAPiwABSDWw
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED1B43@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED1913@LONPMAILBOX01.citrite.net>
	<20236.24592.676628.285657@mariner.uk.xensource.com>
In-Reply-To: <20236.24592.676628.285657@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 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

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 10 January 2012 15:58
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID
> save/restore and migrate
> 
> Paul Durrant writes ("Re: [Xen-devel] [PATCH 0 of 4] Support for VM
> generation ID save/restore and migrate"):
> > Ping? Patch 3 was integrated on Dec 18th but I don't see the rest as yet. Is
> there something more I need to do?
> 
> I've applied 1,2,4 now, thanks.
> 

Excellent. Thanks :-)

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:35:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:35:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkefO-0004NV-Tm; Tue, 10 Jan 2012 16:35:18 +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 1RkefN-0004NF-Bg
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:35:17 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326213246!60406823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21671 invoked from network); 10 Jan 2012 16:34:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:34:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9928674"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:35:11 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 10 Jan 2012
	16:35:11 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 10 Jan 2012 16:35:08 +0000
Thread-Topic: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID
	save/restore and migrate
Thread-Index: AczPsKXuRxB+ZsnxRg68vcZlvmAPiwABSDWw
Message-ID: <291EDFCB1E9E224A99088639C4762022B598ED1B43@LONPMAILBOX01.citrite.net>
References: <patchbomb.1324047273@cosworth.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B598ED1913@LONPMAILBOX01.citrite.net>
	<20236.24592.676628.285657@mariner.uk.xensource.com>
In-Reply-To: <20236.24592.676628.285657@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 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

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 10 January 2012 15:58
> To: Paul Durrant
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH 0 of 4] Support for VM generation ID
> save/restore and migrate
> 
> Paul Durrant writes ("Re: [Xen-devel] [PATCH 0 of 4] Support for VM
> generation ID save/restore and migrate"):
> > Ping? Patch 3 was integrated on Dec 18th but I don't see the rest as yet. Is
> there something more I need to do?
> 
> I've applied 1,2,4 now, thanks.
> 

Excellent. Thanks :-)

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:38:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16: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 1RkeiV-0004bz-LN; Tue, 10 Jan 2012 16:38: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 1RkeiU-0004bb-V6
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:38:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326212730!10278975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24555 invoked from network); 10 Jan 2012 16:25:31 -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;
	10 Jan 2012 16:25:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9928256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:25: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, 10 Jan 2012 16: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
	1RkeVr-0001ln-DF; Tue, 10 Jan 2012 16:25:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeVr-0005M1-CV;
	Tue, 10 Jan 2012 16:25:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.26231.372276.838506@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:25:27 +0000
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F06FAF1020000780006AD0A@nat28.tlf.novell.com>
References: <4EF1A0F702000078000694AC@nat28.tlf.novell.com>
	<4F06FAF1020000780006AD0A@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Ping: [PATCH] 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("[Xen-devel] Ping: [PATCH] xenpm: assorted adjustments"):
> Ian - if it's not you to ack this (or otherwise comment on it), who would
> be the one?

Thanks for the ping.  I had kind of hoped someone else might admit to
owning this but I guess not :-).  Looking through the patch it seemed
sane so I have applied it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:38:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16: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 1RkeiV-0004bz-LN; Tue, 10 Jan 2012 16:38: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 1RkeiU-0004bb-V6
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:38:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326212730!10278975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24555 invoked from network); 10 Jan 2012 16:25:31 -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;
	10 Jan 2012 16:25:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9928256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:25: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, 10 Jan 2012 16: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
	1RkeVr-0001ln-DF; Tue, 10 Jan 2012 16:25:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkeVr-0005M1-CV;
	Tue, 10 Jan 2012 16:25:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.26231.372276.838506@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:25:27 +0000
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F06FAF1020000780006AD0A@nat28.tlf.novell.com>
References: <4EF1A0F702000078000694AC@nat28.tlf.novell.com>
	<4F06FAF1020000780006AD0A@nat28.tlf.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Ping: [PATCH] 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("[Xen-devel] Ping: [PATCH] xenpm: assorted adjustments"):
> Ian - if it's not you to ack this (or otherwise comment on it), who would
> be the one?

Thanks for the ping.  I had kind of hoped someone else might admit to
owning this but I guess not :-).  Looking through the patch it seemed
sane so I have applied it.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:42:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkemH-0004pz-Ak; Tue, 10 Jan 2012 16:42: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 1RkemG-0004pl-4e
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:42:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326213738!10433350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2386 invoked from network); 10 Jan 2012 16:42:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9928973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:42:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 16:42: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
	1Rkem9-0001rO-8l; Tue, 10 Jan 2012 16:42:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rkem9-0005O2-7y;
	Tue, 10 Jan 2012 16:42:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.27241.232532.154157@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:42:17 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326110599.17210.81.camel@zakaz.uk.xensource.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<1326110599.17210.81.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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom checks in tools/check"):
> On Sat, 2012-01-07 at 03:20 +0000, Roger Pau Monne wrote:
> > +    # autoheader && autoconf
> 
> What does autoheader do? This should be clearly noted as being only
> necessary if building from hg and not if you are building from tarball.
> I expect we also need some makefile runes or process updates to make
> sure the generated stuff gets included in the tarball.

autoheader generates config.h.in, which is processed by configure to
make config.h.

I think the output of autoconf and autoheader should be committed to
the hg tree.  It only needs to be rerun when we change the set of
things we test for, add features, etc.  And it is not very portable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:42:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkemH-0004pz-Ak; Tue, 10 Jan 2012 16:42: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 1RkemG-0004pl-4e
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:42:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326213738!10433350!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2386 invoked from network); 10 Jan 2012 16:42:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:42:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9928973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:42:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 16:42: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
	1Rkem9-0001rO-8l; Tue, 10 Jan 2012 16:42:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rkem9-0005O2-7y;
	Tue, 10 Jan 2012 16:42:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.27241.232532.154157@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:42:17 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326110599.17210.81.camel@zakaz.uk.xensource.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<1326110599.17210.81.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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH RFC] build: add autoconf to replace custom checks in tools/check"):
> On Sat, 2012-01-07 at 03:20 +0000, Roger Pau Monne wrote:
> > +    # autoheader && autoconf
> 
> What does autoheader do? This should be clearly noted as being only
> necessary if building from hg and not if you are building from tarball.
> I expect we also need some makefile runes or process updates to make
> sure the generated stuff gets included in the tarball.

autoheader generates config.h.in, which is processed by configure to
make config.h.

I think the output of autoconf and autoheader should be committed to
the hg tree.  It only needs to be rerun when we change the set of
things we test for, add features, etc.  And it is not very portable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:44:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkenK-0004uS-Pp; Tue, 10 Jan 2012 16:43:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RkenI-0004u7-N4
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:43:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326213802!2337753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21563 invoked from network); 10 Jan 2012 16:43:22 -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;
	10 Jan 2012 16:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9929085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:43:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 16:43: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
	1RkenB-0001rr-Mf; Tue, 10 Jan 2012 16:43:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkenB-0005OH-Ls;
	Tue, 10 Jan 2012 16:43:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.27305.663129.85995@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:43:21 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@mail.gmail.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<1326110599.17210.81.camel@zakaz.uk.xensource.com>
	<CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH RFC] build: add autoconf =
to replace custom checks in tools/check"):
> We need to run automake, because it generates config.sub and
> config.guess, which is needed for certain autoconf tests.

config.sub and config.guess are fixed files which you can just copy
into your source tree.  They should be in our hg.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:44:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:44:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkenK-0004uS-Pp; Tue, 10 Jan 2012 16:43:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RkenI-0004u7-N4
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:43:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326213802!2337753!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21563 invoked from network); 10 Jan 2012 16:43:22 -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;
	10 Jan 2012 16:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; 
   d="scan'208";a="9929085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 16:43:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 16:43: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
	1RkenB-0001rr-Mf; Tue, 10 Jan 2012 16:43:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkenB-0005OH-Ls;
	Tue, 10 Jan 2012 16:43:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.27305.663129.85995@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 16:43:21 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@mail.gmail.com>
References: <e12ec1071410c946367c.1325906408@build.localdomain>
	<1326110599.17210.81.camel@zakaz.uk.xensource.com>
	<CAPLaKK5bTpwH9hv_VaYkXgLMxUM2uhq-z7wJZi_UaYSsD6gxCA@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 RFC] build: add autoconf to replace custom
 checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH RFC] build: add autoconf =
to replace custom checks in tools/check"):
> We need to run automake, because it generates config.sub and
> config.guess, which is needed for certain autoconf tests.

config.sub and config.guess are fixed files which you can just copy
into your source tree.  They should be in our hg.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:44:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16: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 1Rkeo9-0004zj-7g; Tue, 10 Jan 2012 16:44:21 +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 1Rkeo8-0004yz-7s
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:44:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326213852!7228819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTU2NzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7750 invoked from network); 10 Jan 2012 16:44:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:44:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320642000"; d="scan'208";a="20728517"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:44:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 11:44:11 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0AGi32B005990;
	Tue, 10 Jan 2012 08:44:10 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 16:40:19 +0000
Message-ID: <1326213620-20756-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
References: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] ARM: support zImage format kernels 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

From: David Vrabel <david.vrabel@citrix.com>

Allow a zImage format kernel to be used for dom0.  zImages are (by
default) hardcoded with the RAM location so adjust the RAM in the
memory map to match the physical memory map (0x80000000).

Vmlinux ELF images are loaded using a hack to locate the RAM so the
IPA is the same as the kernel's VA so the elf loader does the right
thing.  If an ELF image is loaded the RAM will be located at
0xC0000000 (as before).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile       |    1 +
 xen/arch/arm/domain_build.c |   72 ++++--------------
 xen/arch/arm/kernel.c       |  167 +++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/kernel.h       |   37 ++++++++++
 4 files changed, 221 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/kernel.c
 create mode 100644 xen/arch/arm/kernel.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5a07ae7..9bc2fc8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
 obj-y += irq.o
+obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += guestcopy.o
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f73df85..cbbc0b9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -4,10 +4,10 @@
 #include <xen/mm.h>
 #include <xen/domain_page.h>
 #include <xen/sched.h>
-#include <xen/libelf.h>
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "kernel.h"
 
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
@@ -28,25 +28,6 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
 
 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);
@@ -84,21 +65,14 @@ static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
     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 kernel_info kinfo = {};
+    int rc;
 
     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);
@@ -106,31 +80,22 @@ int construct_dom0(struct domain *d)
 
     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");
+    /* 128M at 2G physical */
+    /* TODO size and location from DT. */
+    kinfo.ram_start = 0x80000000;
+    kinfo.ram_end   = 0x88000000;
 
-    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    rc = kernel_prepare(&kinfo);
+    if (rc < 0)
+        return rc;
 
     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("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
+    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
 
     printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
     map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
@@ -161,20 +126,15 @@ int construct_dom0(struct domain *d)
     /* 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);
+    kernel_load(&kinfo);
 
-    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
 
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
 
-    regs->pc = (uint32_t)parms.virt_entry;
+    regs->pc = (uint32_t)kinfo.entry;
 
     regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
@@ -191,7 +151,7 @@ int construct_dom0(struct domain *d)
 
     regs->r0 = 0; /* SBZ */
     regs->r1 = 2272; /* Machine NR: Versatile Express */
-    regs->r2 = 0xc0000100; /* ATAGS */
+    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
new file mode 100644
index 0000000..5fb2ba0
--- /dev/null
+++ b/xen/arch/arm/kernel.c
@@ -0,0 +1,167 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#include <xen/config.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+
+#include "kernel.h"
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+static void kernel_zimage_load(struct kernel_info *info)
+{
+    paddr_t load_addr = info->zimage.load_addr;
+    paddr_t len = info->zimage.len;
+    paddr_t flash = KERNEL_FLASH_ADDRESS;
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Loading %"PRIpaddr" byte zImage from flash %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
+           len, flash, load_addr, load_addr + len);
+    for ( offs = 0; offs < len; offs += PAGE_SIZE )
+    {
+        paddr_t ma = gvirt_to_maddr(load_addr + offs);
+        void *dst = map_domain_page(ma>>PAGE_SHIFT);
+
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst, src, PAGE_SIZE);
+        clear_fixmap(FIXMAP_MISC);
+
+        unmap_domain_page(dst);
+    }
+    printk("]\n");
+}
+
+/**
+ * Check the image is a zImage and return the load address and length
+ * (FIXME: including any appended DTB).
+ */
+static int kernel_try_zimage_prepare(struct kernel_info *info)
+{
+    uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    uint32_t start, end;
+
+    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+
+    if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
+        return -EINVAL;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    clear_fixmap(FIXMAP_MISC);
+
+    /* FIXME: get RAM location from appended DTB (if there is one)? */
+
+    /*
+     * If start is zero, the zImage is position independent -- load it
+     * at 32k from start of RAM.
+     */
+    if (start == 0)
+        info->zimage.load_addr = info->ram_start + 0x8000;
+    else
+        info->zimage.load_addr = start;
+    info->zimage.len = end - start;
+
+    info->entry = info->zimage.load_addr;
+    info->load = kernel_zimage_load;
+
+    return 0;
+}
+
+static void kernel_elf_load(struct kernel_info *info)
+{
+    printk("Loading ELF image into guest memory\n");
+    info->elf.elf.dest = (void*)(unsigned long)info->elf.parms.virt_kstart;
+    elf_load_binary(&info->elf.elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(info->kernel_img, info->kernel_order);
+}
+
+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 int kernel_try_elf_prepare(struct kernel_info *info)
+{
+    int rc;
+
+    info->kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    info->kernel_img = alloc_xenheap_pages(info->kernel_order, 0);
+    if ( info->kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;
+#ifdef VERBOSE
+    elf_set_verbose(&info->elf.elf);
+#endif
+    elf_parse_binary(&info->elf.elf);
+    if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
+        return rc;
+
+    /*
+     * FIXME: can the ELF header be used to find the physical address
+     * to load the image to?  Instead of making virt == phys by
+     * relocating the guest's RAM.
+     */
+    info->ram_start = 0xc0000000;
+    info->ram_end   = 0xc8000000;
+
+    info->entry = info->elf.parms.virt_entry;
+    info->load = kernel_elf_load;
+
+    return 0;
+}
+
+int kernel_prepare(struct kernel_info *info)
+{
+    int rc;
+
+    rc = kernel_try_zimage_prepare(info);
+    if (rc < 0)
+        rc = kernel_try_elf_prepare(info);
+
+    return rc;
+}
+
+void kernel_load(struct kernel_info *info)
+{
+    info->load(info);
+}
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
new file mode 100644
index 0000000..5caebe5
--- /dev/null
+++ b/xen/arch/arm/kernel.h
@@ -0,0 +1,37 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include <xen/libelf.h>
+
+struct kernel_info {
+    paddr_t entry;
+    paddr_t ram_start;
+    paddr_t ram_end;
+
+    void *kernel_img;
+    unsigned kernel_order;
+
+    union {
+        struct {
+            paddr_t load_addr;
+            paddr_t len;
+        } zimage;
+
+        struct {
+            struct elf_binary elf;
+            struct elf_dom_parms parms;
+        } elf;
+    };
+
+    void (*load)(struct kernel_info *info);
+};
+
+int kernel_prepare(struct kernel_info *info);
+void kernel_load(struct kernel_info *info);
+
+#endif /* #ifdef __ARCH_ARM_KERNEL_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 Jan 10 16:44:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16: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 1Rkeo9-0004zj-7g; Tue, 10 Jan 2012 16:44:21 +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 1Rkeo8-0004yz-7s
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:44:20 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326213852!7228819!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTU2NzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7750 invoked from network); 10 Jan 2012 16:44:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:44:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320642000"; d="scan'208";a="20728517"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:44:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 11:44:11 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0AGi32B005990;
	Tue, 10 Jan 2012 08:44:10 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 16:40:19 +0000
Message-ID: <1326213620-20756-2-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
References: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] ARM: support zImage format kernels 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

From: David Vrabel <david.vrabel@citrix.com>

Allow a zImage format kernel to be used for dom0.  zImages are (by
default) hardcoded with the RAM location so adjust the RAM in the
memory map to match the physical memory map (0x80000000).

Vmlinux ELF images are loaded using a hack to locate the RAM so the
IPA is the same as the kernel's VA so the elf loader does the right
thing.  If an ELF image is loaded the RAM will be located at
0xC0000000 (as before).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile       |    1 +
 xen/arch/arm/domain_build.c |   72 ++++--------------
 xen/arch/arm/kernel.c       |  167 +++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/kernel.h       |   37 ++++++++++
 4 files changed, 221 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/kernel.c
 create mode 100644 xen/arch/arm/kernel.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5a07ae7..9bc2fc8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
 obj-y += irq.o
+obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += guestcopy.o
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f73df85..cbbc0b9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -4,10 +4,10 @@
 #include <xen/mm.h>
 #include <xen/domain_page.h>
 #include <xen/sched.h>
-#include <xen/libelf.h>
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "kernel.h"
 
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
@@ -28,25 +28,6 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
 
 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);
@@ -84,21 +65,14 @@ static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
     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 kernel_info kinfo = {};
+    int rc;
 
     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);
@@ -106,31 +80,22 @@ int construct_dom0(struct domain *d)
 
     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");
+    /* 128M at 2G physical */
+    /* TODO size and location from DT. */
+    kinfo.ram_start = 0x80000000;
+    kinfo.ram_end   = 0x88000000;
 
-    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    rc = kernel_prepare(&kinfo);
+    if (rc < 0)
+        return rc;
 
     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("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
+    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
 
     printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
     map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
@@ -161,20 +126,15 @@ int construct_dom0(struct domain *d)
     /* 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);
+    kernel_load(&kinfo);
 
-    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
 
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
 
-    regs->pc = (uint32_t)parms.virt_entry;
+    regs->pc = (uint32_t)kinfo.entry;
 
     regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
@@ -191,7 +151,7 @@ int construct_dom0(struct domain *d)
 
     regs->r0 = 0; /* SBZ */
     regs->r1 = 2272; /* Machine NR: Versatile Express */
-    regs->r2 = 0xc0000100; /* ATAGS */
+    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
new file mode 100644
index 0000000..5fb2ba0
--- /dev/null
+++ b/xen/arch/arm/kernel.c
@@ -0,0 +1,167 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#include <xen/config.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+
+#include "kernel.h"
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+static void kernel_zimage_load(struct kernel_info *info)
+{
+    paddr_t load_addr = info->zimage.load_addr;
+    paddr_t len = info->zimage.len;
+    paddr_t flash = KERNEL_FLASH_ADDRESS;
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Loading %"PRIpaddr" byte zImage from flash %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
+           len, flash, load_addr, load_addr + len);
+    for ( offs = 0; offs < len; offs += PAGE_SIZE )
+    {
+        paddr_t ma = gvirt_to_maddr(load_addr + offs);
+        void *dst = map_domain_page(ma>>PAGE_SHIFT);
+
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst, src, PAGE_SIZE);
+        clear_fixmap(FIXMAP_MISC);
+
+        unmap_domain_page(dst);
+    }
+    printk("]\n");
+}
+
+/**
+ * Check the image is a zImage and return the load address and length
+ * (FIXME: including any appended DTB).
+ */
+static int kernel_try_zimage_prepare(struct kernel_info *info)
+{
+    uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    uint32_t start, end;
+
+    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+
+    if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
+        return -EINVAL;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    clear_fixmap(FIXMAP_MISC);
+
+    /* FIXME: get RAM location from appended DTB (if there is one)? */
+
+    /*
+     * If start is zero, the zImage is position independent -- load it
+     * at 32k from start of RAM.
+     */
+    if (start == 0)
+        info->zimage.load_addr = info->ram_start + 0x8000;
+    else
+        info->zimage.load_addr = start;
+    info->zimage.len = end - start;
+
+    info->entry = info->zimage.load_addr;
+    info->load = kernel_zimage_load;
+
+    return 0;
+}
+
+static void kernel_elf_load(struct kernel_info *info)
+{
+    printk("Loading ELF image into guest memory\n");
+    info->elf.elf.dest = (void*)(unsigned long)info->elf.parms.virt_kstart;
+    elf_load_binary(&info->elf.elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(info->kernel_img, info->kernel_order);
+}
+
+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 int kernel_try_elf_prepare(struct kernel_info *info)
+{
+    int rc;
+
+    info->kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    info->kernel_img = alloc_xenheap_pages(info->kernel_order, 0);
+    if ( info->kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;
+#ifdef VERBOSE
+    elf_set_verbose(&info->elf.elf);
+#endif
+    elf_parse_binary(&info->elf.elf);
+    if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
+        return rc;
+
+    /*
+     * FIXME: can the ELF header be used to find the physical address
+     * to load the image to?  Instead of making virt == phys by
+     * relocating the guest's RAM.
+     */
+    info->ram_start = 0xc0000000;
+    info->ram_end   = 0xc8000000;
+
+    info->entry = info->elf.parms.virt_entry;
+    info->load = kernel_elf_load;
+
+    return 0;
+}
+
+int kernel_prepare(struct kernel_info *info)
+{
+    int rc;
+
+    rc = kernel_try_zimage_prepare(info);
+    if (rc < 0)
+        rc = kernel_try_elf_prepare(info);
+
+    return rc;
+}
+
+void kernel_load(struct kernel_info *info)
+{
+    info->load(info);
+}
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
new file mode 100644
index 0000000..5caebe5
--- /dev/null
+++ b/xen/arch/arm/kernel.h
@@ -0,0 +1,37 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include <xen/libelf.h>
+
+struct kernel_info {
+    paddr_t entry;
+    paddr_t ram_start;
+    paddr_t ram_end;
+
+    void *kernel_img;
+    unsigned kernel_order;
+
+    union {
+        struct {
+            paddr_t load_addr;
+            paddr_t len;
+        } zimage;
+
+        struct {
+            struct elf_binary elf;
+            struct elf_dom_parms parms;
+        } elf;
+    };
+
+    void (*load)(struct kernel_info *info);
+};
+
+int kernel_prepare(struct kernel_info *info);
+void kernel_load(struct kernel_info *info);
+
+#endif /* #ifdef __ARCH_ARM_KERNEL_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 Jan 10 16:44:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeoD-000519-Rb; Tue, 10 Jan 2012 16:44:25 +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 1RkeoC-0004zU-DU
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:44:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326213852!7228819!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTU2NzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7903 invoked from network); 10 Jan 2012 16:44:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:44:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320642000"; d="scan'208";a="20728535"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:44:17 -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, 10 Jan 2012 11:44:17 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0AGi32C005990;
	Tue, 10 Jan 2012 08:44:16 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 16:40:20 +0000
Message-ID: <1326213620-20756-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
References: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] ARM: copy DTB appended to zImage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

When copying a zImage from flash, also copy any appended device tree
blob.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c |   63 ++++++++++++++++++++++++++++++++++--------------
 1 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 5fb2ba0..d4ffa4f 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -10,6 +10,7 @@
 #include <xen/mm.h>
 #include <xen/domain_page.h>
 #include <xen/sched.h>
+#include <asm/byteorder.h>
 
 #include "kernel.h"
 
@@ -23,6 +24,40 @@
 
 #define ZIMAGE_MAGIC 0x016f2818
 
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p",
+           len, flash, dst);
+
+    while (len) {
+        paddr_t p;
+        unsigned long l, s;
+
+        p = flash >> PAGE_SHIFT;
+        s = flash & (PAGE_SIZE-1);
+        l = min(PAGE_SIZE - s, len);
+
+        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        memcpy(dst, src + s, l);
+
+        flash += l;
+        dst += l;
+        len -= l;
+    }
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
 static void kernel_zimage_load(struct kernel_info *info)
 {
     paddr_t load_addr = info->zimage.load_addr;
@@ -58,6 +93,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
 {
     uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
     uint32_t start, end;
+    struct minimal_dtb_header dtb_hdr;
 
     set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
 
@@ -69,6 +105,14 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
 
     clear_fixmap(FIXMAP_MISC);
 
+    /*
+     * Check for an appended DTB.
+     */
+    copy_from_flash(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
+        end += be32_to_cpu(dtb_hdr.total_size);
+    }
+
     /* FIXME: get RAM location from appended DTB (if there is one)? */
 
     /*
@@ -97,25 +141,6 @@ static void kernel_elf_load(struct kernel_info *info)
     free_xenheap_pages(info->kernel_img, info->kernel_order);
 }
 
-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 int kernel_try_elf_prepare(struct kernel_info *info)
 {
     int rc;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:44:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:44:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeoD-000519-Rb; Tue, 10 Jan 2012 16:44:25 +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 1RkeoC-0004zU-DU
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:44:24 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326213852!7228819!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTU2NzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7903 invoked from network); 10 Jan 2012 16:44:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:44:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320642000"; d="scan'208";a="20728535"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:44:17 -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, 10 Jan 2012 11:44:17 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0AGi32C005990;
	Tue, 10 Jan 2012 08:44:16 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 16:40:20 +0000
Message-ID: <1326213620-20756-3-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
References: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] ARM: copy DTB appended to zImage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

When copying a zImage from flash, also copy any appended device tree
blob.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c |   63 ++++++++++++++++++++++++++++++++++--------------
 1 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 5fb2ba0..d4ffa4f 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -10,6 +10,7 @@
 #include <xen/mm.h>
 #include <xen/domain_page.h>
 #include <xen/sched.h>
+#include <asm/byteorder.h>
 
 #include "kernel.h"
 
@@ -23,6 +24,40 @@
 
 #define ZIMAGE_MAGIC 0x016f2818
 
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p",
+           len, flash, dst);
+
+    while (len) {
+        paddr_t p;
+        unsigned long l, s;
+
+        p = flash >> PAGE_SHIFT;
+        s = flash & (PAGE_SIZE-1);
+        l = min(PAGE_SIZE - s, len);
+
+        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        memcpy(dst, src + s, l);
+
+        flash += l;
+        dst += l;
+        len -= l;
+    }
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
 static void kernel_zimage_load(struct kernel_info *info)
 {
     paddr_t load_addr = info->zimage.load_addr;
@@ -58,6 +93,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
 {
     uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
     uint32_t start, end;
+    struct minimal_dtb_header dtb_hdr;
 
     set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
 
@@ -69,6 +105,14 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
 
     clear_fixmap(FIXMAP_MISC);
 
+    /*
+     * Check for an appended DTB.
+     */
+    copy_from_flash(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
+        end += be32_to_cpu(dtb_hdr.total_size);
+    }
+
     /* FIXME: get RAM location from appended DTB (if there is one)? */
 
     /*
@@ -97,25 +141,6 @@ static void kernel_elf_load(struct kernel_info *info)
     free_xenheap_pages(info->kernel_img, info->kernel_order);
 }
 
-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 int kernel_try_elf_prepare(struct kernel_info *info)
 {
     int rc;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:45:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeoH-000522-9y; Tue, 10 Jan 2012 16:44:29 +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 1RkeoF-000504-6k
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:44:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326213858!8054655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAxNjU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17694 invoked from network); 10 Jan 2012 16:44:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:44:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320642000"; d="scan'208";a="176955540"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:44:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 11:44:05 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0AGi32A005990;
	Tue, 10 Jan 2012 08:44:04 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 16:40:18 +0000
Message-ID: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] ARM: support zImage kernels 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

These two patches add support for loading ARM kernels built as a
zImage with an appended device tree blob (DTB)
(CONFIG_ARM_APPENDED_DTB).  You can also use an vmlinux ELF as before.

This is required to run the latest kernels that support the Versatile
Express with a Cortex A15 tile.  Such a kernel can be found in the
'vexpress-dt' branch of git://xenbits.xen.org/people/dvrabel/linux.git.

The DTB for the model is named 'vexpress-v2p-aem-v7a.dtb'.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 16:45:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 16:45:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkeoH-000522-9y; Tue, 10 Jan 2012 16:44:29 +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 1RkeoF-000504-6k
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 16:44:27 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326213858!8054655!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzAxNjU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17694 invoked from network); 10 Jan 2012 16:44:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 16:44:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,487,1320642000"; d="scan'208";a="176955540"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 11:44:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 11:44:05 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0AGi32A005990;
	Tue, 10 Jan 2012 08:44:04 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 10 Jan 2012 16:40:18 +0000
Message-ID: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] ARM: support zImage kernels 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

These two patches add support for loading ARM kernels built as a
zImage with an appended device tree blob (DTB)
(CONFIG_ARM_APPENDED_DTB).  You can also use an vmlinux ELF as before.

This is required to run the latest kernels that support the Versatile
Express with a Cortex A15 tile.  Such a kernel can be found in the
'vexpress-dt' branch of git://xenbits.xen.org/people/dvrabel/linux.git.

The DTB for the model is named 'vexpress-v2p-aem-v7a.dtb'.

David


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:02:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf5Y-0005vv-PI; Tue, 10 Jan 2012 17:02:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rkf5X-0005vc-86
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:02:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326214914!52259532!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20225 invoked from network); 10 Jan 2012 17:01:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:01:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:02: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, 10 Jan 2012 17:02:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rkf5S-0001yC-Ou; Tue, 10 Jan 2012 17:02:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rkf5S-0005RA-O4;
	Tue, 10 Jan 2012 17:02:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.28438.724467.249718@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:02:14 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1326125376@probook.site>
References: <patchbomb.1326125376@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 3] tools/xenpaging: remove typedefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 3] tools/xenpaging: remove typedefs"):
> As noted by Ian Jackson, use of types with names ending in _t is
> reserved to the C implementation (compiler and runtime). This series
> removes all typedefs from xenpaging code.

Thanks, I have applied this style change.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:02:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:02:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf5Y-0005vv-PI; Tue, 10 Jan 2012 17:02:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rkf5X-0005vc-86
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:02:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326214914!52259532!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20225 invoked from network); 10 Jan 2012 17:01:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:01:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930031"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:02: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, 10 Jan 2012 17:02:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rkf5S-0001yC-Ou; Tue, 10 Jan 2012 17:02:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rkf5S-0005RA-O4;
	Tue, 10 Jan 2012 17:02:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.28438.724467.249718@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:02:14 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1326125376@probook.site>
References: <patchbomb.1326125376@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 3] tools/xenpaging: remove typedefs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 3] tools/xenpaging: remove typedefs"):
> As noted by Ian Jackson, use of types with names ending in _t is
> reserved to the C implementation (compiler and runtime). This series
> removes all typedefs from xenpaging code.

Thanks, I have applied this style change.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9Q-0006EI-0h; Tue, 10 Jan 2012 17:06:20 +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 1Rkf9N-0006CJ-FB
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326215136!47832602!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 21357 invoked from network); 10 Jan 2012 17:05:37 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:37 -0000
Received: from mail186-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:09 +0000
Received: from mail186-ch1 (localhost [127.0.0.1])	by
	mail186-ch1-R.bigfish.com (Postfix) with ESMTP id 71195440160;
	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail186-ch1 (localhost.localdomain [127.0.0.1]) by mail186-ch1
	(MessageSwitch) id 1326215173158769_4979;
	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.243])	by mail186-ch1.bigfish.com (Postfix) with ESMTP id
	174D0160042;	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:07 +0000
X-WSS-ID: 0LXLE64-02-DAI-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 24D72C8067;	Tue, 10 Jan 2012 11:06:03 -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;
	Tue, 10 Jan 2012 11:06:13 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06: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; Tue, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C6B8249C667; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id AE61159488B; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 01d2c1d4e3b992997f170d95dccc2195b9206b04
Message-ID: <01d2c1d4e3b992997f17.1326215237@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 11 of 14 V3] 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 1326213614 -3600
# Node ID 01d2c1d4e3b992997f170d95dccc2195b9206b04
# Parent  f1bf84f5fbb94f8702c8e96462e715ad5066dca2
hvmloader: Build IVRS table.
Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f1bf84f5fbb9 -r 01d2c1d4e3b9 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Tue Jan 10 17:40:11 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Tue Jan 10 17:40:14 2012 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 
+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
 #pragma pack ()
 
 struct acpi_config {
diff -r f1bf84f5fbb9 -r 01d2c1d4e3b9 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Tue Jan 10 17:40:11 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Jan 10 17:40:14 2012 +0100
@@ -23,6 +23,8 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,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 ( !strncmp(xenstore_read("iommu", "1"), "1", 1) )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
     table_ptrs[nr_tables] = 0;
     return nr_tables;
 }
diff -r f1bf84f5fbb9 -r 01d2c1d4e3b9 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Tue Jan 10 17:40:11 2012 +0100
+++ b/tools/firmware/hvmloader/pci.c	Tue Jan 10 17:40:14 2012 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf;
+
 void pci_setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
     uint32_t vga_devfn = 256;
-    uint16_t class, vendor_id, device_id;
+    uint16_t class, vendor_id, device_id, sub_vendor_id;
     unsigned int bar, pin, link, isa_irq;
 
     /* Resources assignable to PCI devices via BARs. */
@@ -72,12 +78,34 @@ void pci_setup(void)
         class     = pci_readw(devfn, PCI_CLASS_DEVICE);
         vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
         device_id = pci_readw(devfn, PCI_DEVICE_ID);
+        sub_vendor_id = pci_readw(devfn, PCI_SUBSYSTEM_VENDOR_ID);
+
         if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
             continue;
 
         ASSERT((devfn != PCI_ISA_DEVFN) ||
                ((vendor_id == 0x8086) && (device_id == 0x7000)));
 
+        /* Found amd iommu device. */
+        if ( class == 0x0806 && vendor_id == 0x1022 )
+        {
+            iommu_bdf = devfn;
+            continue;
+        }
+        /* IVRS: Detecting passthrough devices.
+         * sub_vendor_id != citrix && sub_vendor_id != qemu */
+        if ( sub_vendor_id != 0x5853 && sub_vendor_id != 0x1af4 )
+        {
+            /* found amd iommu device */
+            if ( ptdev_nr < PT_DEV_MAX_NR )
+            {
+                ptdev_bdf[ptdev_nr] = devfn;
+                ptdev_nr++;
+            }
+            else
+                printf("Number of passthru devices > PT_DEV_MAX_NR \n");
+        }
+
         switch ( class )
         {
         case 0x0300:


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9Q-0006Ee-FF; Tue, 10 Jan 2012 17:06:20 +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 1Rkf9N-0006CK-N3
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326215042!47975624!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 23213 invoked from network); 10 Jan 2012 17:04:03 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:04:03 -0000
Received: from mail186-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
Received: from mail186-tx2 (localhost [127.0.0.1])	by
	mail186-tx2-R.bigfish.com (Postfix) with ESMTP id E2EFC120246;
	Tue, 10 Jan 2012 17:06:09 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h61h)
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 mail186-tx2 (localhost.localdomain [127.0.0.1]) by mail186-tx2
	(MessageSwitch) id 1326215168969334_32189;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.243])	by
	mail186-tx2.bigfish.com (Postfix) with ESMTP id E2E29420047;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:07 +0000
X-WSS-ID: 0LXLE64-02-DAD-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 26DA1C814B;	Tue, 10 Jan 2012 11:06:03 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:13 -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, 10 Jan 2012 11:06:04 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E947449C669; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id D89ED59488D; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
Message-ID: <9e89b6485b6c91a8d563.1326215239@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 13 of 14 V3] 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 1326213620 -3600
# Node ID 9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
# Parent  2dc60e3398dd602a34ebdf92103a3957b97c02c5
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 2dc60e3398dd -r 9e89b6485b6c tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Tue Jan 10 17:40:17 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Tue Jan 10 17:40:20 2012 +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, 0, pcidev->vdevfn, pcidev->domain, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+                LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
+                return ERROR_FAIL;
+            }
+        }
     }
 
     if (!starting)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9Q-0006Ee-FF; Tue, 10 Jan 2012 17:06:20 +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 1Rkf9N-0006CK-N3
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326215042!47975624!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 23213 invoked from network); 10 Jan 2012 17:04:03 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:04:03 -0000
Received: from mail186-tx2-R.bigfish.com (10.9.14.248) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
Received: from mail186-tx2 (localhost [127.0.0.1])	by
	mail186-tx2-R.bigfish.com (Postfix) with ESMTP id E2EFC120246;
	Tue, 10 Jan 2012 17:06:09 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h61h)
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 mail186-tx2 (localhost.localdomain [127.0.0.1]) by mail186-tx2
	(MessageSwitch) id 1326215168969334_32189;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.243])	by
	mail186-tx2.bigfish.com (Postfix) with ESMTP id E2E29420047;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:07 +0000
X-WSS-ID: 0LXLE64-02-DAD-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 26DA1C814B;	Tue, 10 Jan 2012 11:06:03 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:13 -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, 10 Jan 2012 11:06:04 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E947449C669; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id D89ED59488D; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
Message-ID: <9e89b6485b6c91a8d563.1326215239@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 13 of 14 V3] 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 1326213620 -3600
# Node ID 9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
# Parent  2dc60e3398dd602a34ebdf92103a3957b97c02c5
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 2dc60e3398dd -r 9e89b6485b6c tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Tue Jan 10 17:40:17 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Tue Jan 10 17:40:20 2012 +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, 0, pcidev->vdevfn, pcidev->domain, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+                LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_bind_pt_bdf failed");
+                return ERROR_FAIL;
+            }
+        }
     }
 
     if (!starting)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9Q-0006EI-0h; Tue, 10 Jan 2012 17:06:20 +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 1Rkf9N-0006CJ-FB
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326215136!47832602!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 21357 invoked from network); 10 Jan 2012 17:05:37 -0000
Received: from ch1ehsobe005.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.185)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:37 -0000
Received: from mail186-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:09 +0000
Received: from mail186-ch1 (localhost [127.0.0.1])	by
	mail186-ch1-R.bigfish.com (Postfix) with ESMTP id 71195440160;
	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail186-ch1 (localhost.localdomain [127.0.0.1]) by mail186-ch1
	(MessageSwitch) id 1326215173158769_4979;
	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.243])	by mail186-ch1.bigfish.com (Postfix) with ESMTP id
	174D0160042;	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:07 +0000
X-WSS-ID: 0LXLE64-02-DAI-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 24D72C8067;	Tue, 10 Jan 2012 11:06:03 -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;
	Tue, 10 Jan 2012 11:06:13 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06: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; Tue, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C6B8249C667; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id AE61159488B; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 01d2c1d4e3b992997f170d95dccc2195b9206b04
Message-ID: <01d2c1d4e3b992997f17.1326215237@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 11 of 14 V3] 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 1326213614 -3600
# Node ID 01d2c1d4e3b992997f170d95dccc2195b9206b04
# Parent  f1bf84f5fbb94f8702c8e96462e715ad5066dca2
hvmloader: Build IVRS table.
Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r f1bf84f5fbb9 -r 01d2c1d4e3b9 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Tue Jan 10 17:40:11 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Tue Jan 10 17:40:14 2012 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
 #define ACPI_2_0_WAET_REVISION 0x01
 #define ACPI_1_0_FADT_REVISION 0x01
 
+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
 #pragma pack ()
 
 struct acpi_config {
diff -r f1bf84f5fbb9 -r 01d2c1d4e3b9 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Tue Jan 10 17:40:11 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Tue Jan 10 17:40:14 2012 +0100
@@ -23,6 +23,8 @@
 #include "ssdt_pm.h"
 #include "../config.h"
 #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>
 
 #define align16(sz)        (((sz) + 15) & ~15)
 #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,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 ( !strncmp(xenstore_read("iommu", "1"), "1", 1) )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
     table_ptrs[nr_tables] = 0;
     return nr_tables;
 }
diff -r f1bf84f5fbb9 -r 01d2c1d4e3b9 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Tue Jan 10 17:40:11 2012 +0100
+++ b/tools/firmware/hvmloader/pci.c	Tue Jan 10 17:40:14 2012 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
 enum virtual_vga virtual_vga = VGA_none;
 unsigned long igd_opregion_pgbase = 0;
 
+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf;
+
 void pci_setup(void)
 {
     uint32_t base, devfn, bar_reg, bar_data, bar_sz, cmd, mmio_total = 0;
     uint32_t vga_devfn = 256;
-    uint16_t class, vendor_id, device_id;
+    uint16_t class, vendor_id, device_id, sub_vendor_id;
     unsigned int bar, pin, link, isa_irq;
 
     /* Resources assignable to PCI devices via BARs. */
@@ -72,12 +78,34 @@ void pci_setup(void)
         class     = pci_readw(devfn, PCI_CLASS_DEVICE);
         vendor_id = pci_readw(devfn, PCI_VENDOR_ID);
         device_id = pci_readw(devfn, PCI_DEVICE_ID);
+        sub_vendor_id = pci_readw(devfn, PCI_SUBSYSTEM_VENDOR_ID);
+
         if ( (vendor_id == 0xffff) && (device_id == 0xffff) )
             continue;
 
         ASSERT((devfn != PCI_ISA_DEVFN) ||
                ((vendor_id == 0x8086) && (device_id == 0x7000)));
 
+        /* Found amd iommu device. */
+        if ( class == 0x0806 && vendor_id == 0x1022 )
+        {
+            iommu_bdf = devfn;
+            continue;
+        }
+        /* IVRS: Detecting passthrough devices.
+         * sub_vendor_id != citrix && sub_vendor_id != qemu */
+        if ( sub_vendor_id != 0x5853 && sub_vendor_id != 0x1af4 )
+        {
+            /* found amd iommu device */
+            if ( ptdev_nr < PT_DEV_MAX_NR )
+            {
+                ptdev_bdf[ptdev_nr] = devfn;
+                ptdev_nr++;
+            }
+            else
+                printf("Number of passthru devices > PT_DEV_MAX_NR \n");
+        }
+
         switch ( class )
         {
         case 0x0300:


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9P-0006E2-Jb; Tue, 10 Jan 2012 17:06:19 +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 1Rkf9N-0006CI-8X
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326215169!8263171!2
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 5502 invoked from network); 10 Jan 2012 17:06:10 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-15.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:10 -0000
Received: from mail212-ch1-R.bigfish.com (10.43.68.254) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail212-ch1 (localhost [127.0.0.1])	by
	mail212-ch1-R.bigfish.com (Postfix) with ESMTP id C82CD10021B;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail212-ch1 (localhost.localdomain [127.0.0.1]) by mail212-ch1
	(MessageSwitch) id 1326215166514750_13145;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail212-ch1.bigfish.com (Postfix) with ESMTP id
	76969300046;	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:05 +0000
X-WSS-ID: 0LXLE63-02-DA6-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 28983C8145;	Tue, 10 Jan 2012 11:06:02 -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;
	Tue, 10 Jan 2012 11:06:12 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:03 -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, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 5CBEE49C662; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 46383594887; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3d252e3969bae12e85e5a1f2f339dad169d0d892
Message-ID: <3d252e3969bae12e85e5.1326215232@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 06 of 14 V3] 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 1326213597 -3600
# Node ID 3d252e3969bae12e85e5a1f2f339dad169d0d892
# Parent  e698b7b63a9dc75c5cad4dbe02d38d90bdaf1512
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 e698b7b63a9d -r 3d252e3969ba xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:53 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:57 2012 +0100
@@ -355,75 +355,92 @@ 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,
+                          unsigned int entry_size,
+                          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 * 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)
@@ -595,30 +612,95 @@ 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, 
+                   sizeof(event_entry_t), 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, 
+                   sizeof(ppr_entry_t), 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;
@@ -631,8 +713,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 Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9O-0006DO-MC; Tue, 10 Jan 2012 17:06:18 +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 1Rkf9M-0006CF-R1
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326215169!8263171!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 5491 invoked from network); 10 Jan 2012 17:06:10 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-15.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:10 -0000
Received: from mail196-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; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail196-ch1 (localhost [127.0.0.1])	by
	mail196-ch1-R.bigfish.com (Postfix) with ESMTP id 16BD7300312;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail196-ch1 (localhost.localdomain [127.0.0.1]) by mail196-ch1
	(MessageSwitch) id 1326215165853578_3460;
	Tue, 10 Jan 2012 17:06:05 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail196-ch1.bigfish.com (Postfix) with ESMTP id
	CB067360046;	Tue, 10 Jan 2012 17:06:05 +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; Tue, 10 Jan 2012 17:06:07 +0000
X-WSS-ID: 0LXLE64-02-DAH-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 29A08C8147;	Tue, 10 Jan 2012 11:06:04 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:13 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06: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; Tue, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 89CF849C664; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 770225940FF; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 82f5e77e13c43f0e4e34dfefdd218aec092f9542
Message-ID: <82f5e77e13c43f0e4e34.1326215234@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 08 of 14 V3] 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 1326213604 -3600
# Node ID 82f5e77e13c43f0e4e34dfefdd218aec092f9542
# Parent  31e61ed495ae1429e3317f8b0359ff37fdcbb6cd
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 31e61ed495ae -r 82f5e77e13c4 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 10 17:40:01 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 10 17:40:04 2012 +0100
@@ -821,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;
 
@@ -880,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);
@@ -904,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);
 
@@ -921,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) );
 }
@@ -938,7 +942,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);
@@ -964,7 +968,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 31e61ed495ae -r 82f5e77e13c4 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:40:01 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:40:04 2012 +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)
 {
@@ -765,6 +766,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);
 
 }
diff -r 31e61ed495ae -r 82f5e77e13c4 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:40:01 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:40:04 2012 +0100
@@ -182,4 +182,6 @@ struct guest_iommu {
     struct guest_iommu_msi  msi;
 };
 
+extern bool_t iommuv2_enabled;
+
 #endif /* _ASM_X86_64_AMD_IOMMU_H */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9P-0006E2-Jb; Tue, 10 Jan 2012 17:06:19 +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 1Rkf9N-0006CI-8X
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326215169!8263171!2
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 5502 invoked from network); 10 Jan 2012 17:06:10 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-15.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:10 -0000
Received: from mail212-ch1-R.bigfish.com (10.43.68.254) by
	CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail212-ch1 (localhost [127.0.0.1])	by
	mail212-ch1-R.bigfish.com (Postfix) with ESMTP id C82CD10021B;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail212-ch1 (localhost.localdomain [127.0.0.1]) by mail212-ch1
	(MessageSwitch) id 1326215166514750_13145;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.247])	by mail212-ch1.bigfish.com (Postfix) with ESMTP id
	76969300046;	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:05 +0000
X-WSS-ID: 0LXLE63-02-DA6-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 28983C8145;	Tue, 10 Jan 2012 11:06:02 -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;
	Tue, 10 Jan 2012 11:06:12 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:03 -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, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 5CBEE49C662; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 46383594887; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3d252e3969bae12e85e5a1f2f339dad169d0d892
Message-ID: <3d252e3969bae12e85e5.1326215232@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 06 of 14 V3] 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 1326213597 -3600
# Node ID 3d252e3969bae12e85e5a1f2f339dad169d0d892
# Parent  e698b7b63a9dc75c5cad4dbe02d38d90bdaf1512
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 e698b7b63a9d -r 3d252e3969ba xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:53 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:57 2012 +0100
@@ -355,75 +355,92 @@ 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,
+                          unsigned int entry_size,
+                          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 * 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)
@@ -595,30 +612,95 @@ 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, 
+                   sizeof(event_entry_t), 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, 
+                   sizeof(ppr_entry_t), 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;
@@ -631,8 +713,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 Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9O-0006DO-MC; Tue, 10 Jan 2012 17:06:18 +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 1Rkf9M-0006CF-R1
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326215169!8263171!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 5491 invoked from network); 10 Jan 2012 17:06:10 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-15.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:10 -0000
Received: from mail196-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; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail196-ch1 (localhost [127.0.0.1])	by
	mail196-ch1-R.bigfish.com (Postfix) with ESMTP id 16BD7300312;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail196-ch1 (localhost.localdomain [127.0.0.1]) by mail196-ch1
	(MessageSwitch) id 1326215165853578_3460;
	Tue, 10 Jan 2012 17:06:05 +0000 (UTC)
Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail196-ch1.bigfish.com (Postfix) with ESMTP id
	CB067360046;	Tue, 10 Jan 2012 17:06:05 +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; Tue, 10 Jan 2012 17:06:07 +0000
X-WSS-ID: 0LXLE64-02-DAH-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 29A08C8147;	Tue, 10 Jan 2012 11:06:04 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:13 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06: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; Tue, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 89CF849C664; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 770225940FF; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 82f5e77e13c43f0e4e34dfefdd218aec092f9542
Message-ID: <82f5e77e13c43f0e4e34.1326215234@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 08 of 14 V3] 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 1326213604 -3600
# Node ID 82f5e77e13c43f0e4e34dfefdd218aec092f9542
# Parent  31e61ed495ae1429e3317f8b0359ff37fdcbb6cd
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 31e61ed495ae -r 82f5e77e13c4 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 10 17:40:01 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 10 17:40:04 2012 +0100
@@ -821,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;
 
@@ -880,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);
@@ -904,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);
 
@@ -921,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) );
 }
@@ -938,7 +942,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);
@@ -964,7 +968,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 31e61ed495ae -r 82f5e77e13c4 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:40:01 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:40:04 2012 +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)
 {
@@ -765,6 +766,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);
 
 }
diff -r 31e61ed495ae -r 82f5e77e13c4 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:40:01 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:40:04 2012 +0100
@@ -182,4 +182,6 @@ struct guest_iommu {
     struct guest_iommu_msi  msi;
 };
 
+extern bool_t iommuv2_enabled;
+
 #endif /* _ASM_X86_64_AMD_IOMMU_H */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9R-0006FJ-1o; Tue, 10 Jan 2012 17:06:21 +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 1Rkf9O-0006CS-Ub
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:19 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326215153!61882891!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 24066 invoked from network); 10 Jan 2012 17:05:55 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-15.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:55 -0000
Received: from mail169-ch1-R.bigfish.com (10.43.68.240) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:13 +0000
Received: from mail169-ch1 (localhost [127.0.0.1])	by
	mail169-ch1-R.bigfish.com (Postfix) with ESMTP id 8321E180195;
	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail169-ch1 (localhost.localdomain [127.0.0.1]) by mail169-ch1
	(MessageSwitch) id 1326215173174416_8623;
	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.251])	by mail169-ch1.bigfish.com (Postfix) with ESMTP id
	10F0E320045;	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
X-WSS-ID: 0LXLE69-01-DUN-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 297F71028122;	Tue, 10 Jan 2012 11:06:08 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:17 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:08 -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, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0C82949C66A; Tue, 10 Jan 2012
	17:05:58 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id EE7A1594883; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 39eb093ea89eeaa4dbff29439499f2a289291ff0
Message-ID: <39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 14 of 14 V3] 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 1326213623 -3600
# Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
# Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
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 9e89b6485b6c -r 39eb093ea89e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Jan 10 17:40:20 2012 +0100
+++ b/tools/libxl/libxl_create.c	Tue Jan 10 17:40:23 2012 +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;
@@ -189,13 +190,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] = "iommu";
+        localents[7] = (info->u.hvm.iommu) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 9e89b6485b6c -r 39eb093ea89e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 17:40:20 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 17:40:23 2012 +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 9e89b6485b6c -r 39eb093ea89e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:20 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:23 2012 +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);
@@ -766,6 +767,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 Tue Jan 10 17:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkf9R-0006FJ-1o; Tue, 10 Jan 2012 17:06:21 +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 1Rkf9O-0006CS-Ub
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:19 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326215153!61882891!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 24066 invoked from network); 10 Jan 2012 17:05:55 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-15.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:55 -0000
Received: from mail169-ch1-R.bigfish.com (10.43.68.240) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:13 +0000
Received: from mail169-ch1 (localhost [127.0.0.1])	by
	mail169-ch1-R.bigfish.com (Postfix) with ESMTP id 8321E180195;
	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail169-ch1 (localhost.localdomain [127.0.0.1]) by mail169-ch1
	(MessageSwitch) id 1326215173174416_8623;
	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.251])	by mail169-ch1.bigfish.com (Postfix) with ESMTP id
	10F0E320045;	Tue, 10 Jan 2012 17:06:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
X-WSS-ID: 0LXLE69-01-DUN-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 297F71028122;	Tue, 10 Jan 2012 11:06:08 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:17 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:08 -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, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0C82949C66A; Tue, 10 Jan 2012
	17:05:58 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id EE7A1594883; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 39eb093ea89eeaa4dbff29439499f2a289291ff0
Message-ID: <39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 14 of 14 V3] 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 1326213623 -3600
# Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
# Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
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 9e89b6485b6c -r 39eb093ea89e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Jan 10 17:40:20 2012 +0100
+++ b/tools/libxl/libxl_create.c	Tue Jan 10 17:40:23 2012 +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;
@@ -189,13 +190,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] = "iommu";
+        localents[7] = (info->u.hvm.iommu) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 9e89b6485b6c -r 39eb093ea89e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 17:40:20 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 17:40:23 2012 +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 9e89b6485b6c -r 39eb093ea89e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:20 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:23 2012 +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);
@@ -766,6 +767,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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9R-0006Fy-Sj; Tue, 10 Jan 2012 17:06: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 1Rkf9Q-0006CN-0E
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326215171!1617162!1
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 20495 invoked from network); 10 Jan 2012 17:06:12 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:12 -0000
Received: from mail18-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
Received: from mail18-ch1 (localhost [127.0.0.1])	by mail18-ch1-R.bigfish.com
	(Postfix) with ESMTP id A509E400535;
	Tue, 10 Jan 2012 17:06:10 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail18-ch1 (localhost.localdomain [127.0.0.1]) by mail18-ch1
	(MessageSwitch) id 1326215166518751_21259;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail18-ch1.bigfish.com (Postfix) with ESMTP id
	730665E0047;	Tue, 10 Jan 2012 17:06:06 +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; Tue, 10 Jan 2012 17:06:03 +0000
X-WSS-ID: 0LXLE61-02-DA3-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 283B0C814B;	Tue, 10 Jan 2012 11:06:01 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:10 -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, 10 Jan 2012 11:06:02 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:00 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0C72E49C65E; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id EC679594883; Tue, 10 Jan 2012
	18:05:56 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dfdc0df7d68fa4551271b29671a2d333b185a48c
Message-ID: <dfdc0df7d68fa4551271.1326215228@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07:08 +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 14 V3] amd iommu: Introduces new helper
 functions to simplify 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 1326213581 -3600
# Node ID dfdc0df7d68fa4551271b29671a2d333b185a48c
# Parent  9c9ddf2dd700119fdaf8a420fb051c22279853cc
amd iommu: Introduces new helper functions to simplify bitwise operations

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 9c9ddf2dd700 -r dfdc0df7d68f xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:36 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:41 2012 +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 9c9ddf2dd700 -r dfdc0df7d68f xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:36 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:41 2012 +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->cmd_buffer.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->event_log.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 9c9ddf2dd700 -r dfdc0df7d68f xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:36 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:41 2012 +0100
@@ -82,10 +82,6 @@
 /* Device Table */
 #define IOMMU_DEV_TABLE_BASE_LOW_OFFSET		0x00
 #define IOMMU_DEV_TABLE_BASE_HIGH_OFFSET	0x04
-#define IOMMU_DEV_TABLE_BASE_LOW_MASK		0xFFFFF000
-#define IOMMU_DEV_TABLE_BASE_LOW_SHIFT		12
-#define IOMMU_DEV_TABLE_BASE_HIGH_MASK		0x000FFFFF
-#define IOMMU_DEV_TABLE_BASE_HIGH_SHIFT		0
 #define IOMMU_DEV_TABLE_SIZE_MASK		0x000001FF
 #define IOMMU_DEV_TABLE_SIZE_SHIFT		0
 
@@ -164,22 +160,13 @@
 #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
 #define IOMMU_CMD_BUFFER_HEAD_OFFSET		0x2000
 #define IOMMU_CMD_BUFFER_TAIL_OFFSET		0x2008
-#define IOMMU_CMD_BUFFER_BASE_LOW_MASK		0xFFFFF000
-#define IOMMU_CMD_BUFFER_BASE_LOW_SHIFT		12
-#define IOMMU_CMD_BUFFER_BASE_HIGH_MASK		0x000FFFFF
-#define IOMMU_CMD_BUFFER_BASE_HIGH_SHIFT	0
 #define IOMMU_CMD_BUFFER_LENGTH_MASK		0x0F000000
 #define IOMMU_CMD_BUFFER_LENGTH_SHIFT		24
-#define IOMMU_CMD_BUFFER_HEAD_MASK		0x0007FFF0
-#define IOMMU_CMD_BUFFER_HEAD_SHIFT		4
-#define IOMMU_CMD_BUFFER_TAIL_MASK		0x0007FFF0
-#define IOMMU_CMD_BUFFER_TAIL_SHIFT		4
 
 #define IOMMU_CMD_BUFFER_ENTRY_SIZE			16
 #define IOMMU_CMD_BUFFER_POWER_OF2_ENTRIES_PER_PAGE	8
@@ -251,10 +238,6 @@
 #define IOMMU_EVENT_LOG_BASE_HIGH_OFFSET	0x14
 #define IOMMU_EVENT_LOG_HEAD_OFFSET		0x2010
 #define IOMMU_EVENT_LOG_TAIL_OFFSET		0x2018
-#define IOMMU_EVENT_LOG_BASE_LOW_MASK		0xFFFFF000
-#define IOMMU_EVENT_LOG_BASE_LOW_SHIFT		12
-#define IOMMU_EVENT_LOG_BASE_HIGH_MASK		0x000FFFFF
-#define IOMMU_EVENT_LOG_BASE_HIGH_SHIFT		0
 #define IOMMU_EVENT_LOG_LENGTH_MASK		0x0F000000
 #define IOMMU_EVENT_LOG_LENGTH_SHIFT		24
 #define IOMMU_EVENT_LOG_HEAD_MASK		0x0007FFF0
@@ -440,4 +423,20 @@
 
 #define INV_IOMMU_ALL_PAGES_ADDRESS      ((1ULL << 63) - 1)
 
+#define IOMMU_RING_BUFFER_PTR_MASK                  0x0007FFF0
+#define IOMMU_RING_BUFFER_PTR_SHIFT                 4
+
+#define IOMMU_CMD_DEVICE_ID_MASK                    0x0000FFFF
+#define IOMMU_CMD_DEVICE_ID_SHIFT                   0
+
+#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
+
+#define IOMMU_REG_BASE_ADDR_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
+
 #endif /* _ASM_X86_64_AMD_IOMMU_DEFS_H */
diff -r 9c9ddf2dd700 -r dfdc0df7d68f xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Tue Jan 10 17:39:36 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Tue Jan 10 17:39:41 2012 +0100
@@ -192,4 +192,71 @@ static inline int iommu_has_feature(stru
     return !!(iommu->features & (1U << bit));
 }
 
+/* access tail or head pointer of ring buffer */
+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 id field from iommu cmd */
+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 */
+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);
+}
+
+/* access address field from event log entry */
+#define iommu_get_devid_from_event          iommu_get_devid_from_cmd
+
+/* access iommu base addresses field from mmio regs */
+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_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_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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9R-0006Fy-Sj; Tue, 10 Jan 2012 17:06: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 1Rkf9Q-0006CN-0E
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326215171!1617162!1
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 20495 invoked from network); 10 Jan 2012 17:06:12 -0000
Received: from ch1ehsobe001.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.181)
	by server-9.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:12 -0000
Received: from mail18-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
Received: from mail18-ch1 (localhost [127.0.0.1])	by mail18-ch1-R.bigfish.com
	(Postfix) with ESMTP id A509E400535;
	Tue, 10 Jan 2012 17:06:10 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail18-ch1 (localhost.localdomain [127.0.0.1]) by mail18-ch1
	(MessageSwitch) id 1326215166518751_21259;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.242])	by mail18-ch1.bigfish.com (Postfix) with ESMTP id
	730665E0047;	Tue, 10 Jan 2012 17:06:06 +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; Tue, 10 Jan 2012 17:06:03 +0000
X-WSS-ID: 0LXLE61-02-DA3-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 283B0C814B;	Tue, 10 Jan 2012 11:06:01 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:10 -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, 10 Jan 2012 11:06:02 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:00 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 0C72E49C65E; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id EC679594883; Tue, 10 Jan 2012
	18:05:56 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dfdc0df7d68fa4551271b29671a2d333b185a48c
Message-ID: <dfdc0df7d68fa4551271.1326215228@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07:08 +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 14 V3] amd iommu: Introduces new helper
 functions to simplify 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 1326213581 -3600
# Node ID dfdc0df7d68fa4551271b29671a2d333b185a48c
# Parent  9c9ddf2dd700119fdaf8a420fb051c22279853cc
amd iommu: Introduces new helper functions to simplify bitwise operations

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 9c9ddf2dd700 -r dfdc0df7d68f xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:36 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:41 2012 +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 9c9ddf2dd700 -r dfdc0df7d68f xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:36 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:41 2012 +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->cmd_buffer.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->event_log.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 9c9ddf2dd700 -r dfdc0df7d68f xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:36 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:41 2012 +0100
@@ -82,10 +82,6 @@
 /* Device Table */
 #define IOMMU_DEV_TABLE_BASE_LOW_OFFSET		0x00
 #define IOMMU_DEV_TABLE_BASE_HIGH_OFFSET	0x04
-#define IOMMU_DEV_TABLE_BASE_LOW_MASK		0xFFFFF000
-#define IOMMU_DEV_TABLE_BASE_LOW_SHIFT		12
-#define IOMMU_DEV_TABLE_BASE_HIGH_MASK		0x000FFFFF
-#define IOMMU_DEV_TABLE_BASE_HIGH_SHIFT		0
 #define IOMMU_DEV_TABLE_SIZE_MASK		0x000001FF
 #define IOMMU_DEV_TABLE_SIZE_SHIFT		0
 
@@ -164,22 +160,13 @@
 #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
 #define IOMMU_CMD_BUFFER_HEAD_OFFSET		0x2000
 #define IOMMU_CMD_BUFFER_TAIL_OFFSET		0x2008
-#define IOMMU_CMD_BUFFER_BASE_LOW_MASK		0xFFFFF000
-#define IOMMU_CMD_BUFFER_BASE_LOW_SHIFT		12
-#define IOMMU_CMD_BUFFER_BASE_HIGH_MASK		0x000FFFFF
-#define IOMMU_CMD_BUFFER_BASE_HIGH_SHIFT	0
 #define IOMMU_CMD_BUFFER_LENGTH_MASK		0x0F000000
 #define IOMMU_CMD_BUFFER_LENGTH_SHIFT		24
-#define IOMMU_CMD_BUFFER_HEAD_MASK		0x0007FFF0
-#define IOMMU_CMD_BUFFER_HEAD_SHIFT		4
-#define IOMMU_CMD_BUFFER_TAIL_MASK		0x0007FFF0
-#define IOMMU_CMD_BUFFER_TAIL_SHIFT		4
 
 #define IOMMU_CMD_BUFFER_ENTRY_SIZE			16
 #define IOMMU_CMD_BUFFER_POWER_OF2_ENTRIES_PER_PAGE	8
@@ -251,10 +238,6 @@
 #define IOMMU_EVENT_LOG_BASE_HIGH_OFFSET	0x14
 #define IOMMU_EVENT_LOG_HEAD_OFFSET		0x2010
 #define IOMMU_EVENT_LOG_TAIL_OFFSET		0x2018
-#define IOMMU_EVENT_LOG_BASE_LOW_MASK		0xFFFFF000
-#define IOMMU_EVENT_LOG_BASE_LOW_SHIFT		12
-#define IOMMU_EVENT_LOG_BASE_HIGH_MASK		0x000FFFFF
-#define IOMMU_EVENT_LOG_BASE_HIGH_SHIFT		0
 #define IOMMU_EVENT_LOG_LENGTH_MASK		0x0F000000
 #define IOMMU_EVENT_LOG_LENGTH_SHIFT		24
 #define IOMMU_EVENT_LOG_HEAD_MASK		0x0007FFF0
@@ -440,4 +423,20 @@
 
 #define INV_IOMMU_ALL_PAGES_ADDRESS      ((1ULL << 63) - 1)
 
+#define IOMMU_RING_BUFFER_PTR_MASK                  0x0007FFF0
+#define IOMMU_RING_BUFFER_PTR_SHIFT                 4
+
+#define IOMMU_CMD_DEVICE_ID_MASK                    0x0000FFFF
+#define IOMMU_CMD_DEVICE_ID_SHIFT                   0
+
+#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
+
+#define IOMMU_REG_BASE_ADDR_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
+
 #endif /* _ASM_X86_64_AMD_IOMMU_DEFS_H */
diff -r 9c9ddf2dd700 -r dfdc0df7d68f xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Tue Jan 10 17:39:36 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Tue Jan 10 17:39:41 2012 +0100
@@ -192,4 +192,71 @@ static inline int iommu_has_feature(stru
     return !!(iommu->features & (1U << bit));
 }
 
+/* access tail or head pointer of ring buffer */
+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 id field from iommu cmd */
+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 */
+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);
+}
+
+/* access address field from event log entry */
+#define iommu_get_devid_from_event          iommu_get_devid_from_cmd
+
+/* access iommu base addresses field from mmio regs */
+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_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_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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9O-0006DE-8c; Tue, 10 Jan 2012 17:06:18 +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 1Rkf9M-0006CD-EG
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:16 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326215168!10476369!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 4344 invoked from network); 10 Jan 2012 17:06:09 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-9.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:09 -0000
Received: from mail69-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; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail69-ch1 (localhost [127.0.0.1])	by mail69-ch1-R.bigfish.com
	(Postfix) with ESMTP id 876D726020F;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail69-ch1 (localhost.localdomain [127.0.0.1]) by mail69-ch1
	(MessageSwitch) id 1326215166291999_4141;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail69-ch1.bigfish.com (Postfix) with ESMTP id
	42293640049;	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:04 +0000
X-WSS-ID: 0LXLE62-01-DU4-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 2F99F1028142;	Tue, 10 Jan 2012 11:06:01 -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;
	Tue, 10 Jan 2012 11:06:11 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:02 -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, 10 Jan 2012
	12:05:58 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 337F849C660; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 1F0A9594885; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 6cb08a39044171124b9b9176b50d2ea9196420bb
Message-ID: <6cb08a39044171124b9b.1326215230@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 04 of 14 V3] 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 1326213589 -3600
# Node ID 6cb08a39044171124b9b9176b50d2ea9196420bb
# Parent  6789e0d335e67e700f97942dd094c548fbbd80f3
amd iommu: Enable ppr log.
IOMMUv2 writes peripheral page service request (PPR) records into ppr log
to report guest OS pending DMA page requests from ATS devices.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 6789e0d335e6 -r 6cb08a390441 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:45 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:49 2012 +0100
@@ -126,14 +126,15 @@ static void register_iommu_dev_table_in_
 
 static void register_iommu_cmd_buffer_in_mmio_space(struct amd_iommu *iommu)
 {
-    u64 addr_64, addr_lo, addr_hi;
+    u64 addr_64;
+    u32 addr_lo, addr_hi;
     u32 power_of2_entries;
     u32 entry;
 
     ASSERT( iommu->cmd_buffer.buffer );
 
-    addr_64 = (u64)virt_to_maddr(iommu->cmd_buffer.buffer);
-    addr_lo = addr_64 & DMA_32BIT_MASK;
+    addr_64 = virt_to_maddr(iommu->cmd_buffer.buffer);
+    addr_lo = addr_64;
     addr_hi = addr_64 >> 32;
 
     entry = 0;
@@ -153,14 +154,15 @@ static void register_iommu_cmd_buffer_in
 
 static void register_iommu_event_log_in_mmio_space(struct amd_iommu *iommu)
 {
-    u64 addr_64, addr_lo, addr_hi;
+    u64 addr_64;
+    u32 addr_lo, addr_hi;
     u32 power_of2_entries;
     u32 entry;
 
     ASSERT( iommu->event_log.buffer );
 
-    addr_64 = (u64)virt_to_maddr(iommu->event_log.buffer);
-    addr_lo = addr_64 & DMA_32BIT_MASK;
+    addr_64 = virt_to_maddr(iommu->event_log.buffer);
+    addr_lo = addr_64;
     addr_hi = addr_64 >> 32;
 
     entry = 0;
@@ -178,6 +180,35 @@ 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;
+    u32 addr_lo, addr_hi;
+    u32 power_of2_entries;
+    u32 entry;
+
+    ASSERT ( iommu->ppr_log.buffer );
+
+    addr_64 = virt_to_maddr(iommu->ppr_log.buffer);
+    addr_lo = addr_64;
+    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)
 {
@@ -215,10 +246,10 @@ static void set_iommu_command_buffer_con
 
 static void register_iommu_exclusion_range(struct amd_iommu *iommu)
 {
-    u64 addr_lo, addr_hi;
+    u32 addr_lo, addr_hi;
     u32 entry;
 
-    addr_lo = iommu->exclusion_limit & DMA_32BIT_MASK;
+    addr_lo = iommu->exclusion_limit;
     addr_hi = iommu->exclusion_limit >> 32;
 
     set_field_in_reg_u32((u32)addr_hi, 0,
@@ -278,6 +309,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 +645,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) )
@@ -671,16 +738,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;
@@ -693,8 +773,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++;
@@ -717,6 +795,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);
@@ -915,6 +994,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 6789e0d335e6 -r 6cb08a390441 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:45 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:49 2012 +0100
@@ -93,6 +93,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 6789e0d335e6 -r 6cb08a390441 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:45 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:49 2012 +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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9O-0006DE-8c; Tue, 10 Jan 2012 17:06:18 +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 1Rkf9M-0006CD-EG
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:16 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326215168!10476369!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 4344 invoked from network); 10 Jan 2012 17:06:09 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-9.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:09 -0000
Received: from mail69-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; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail69-ch1 (localhost [127.0.0.1])	by mail69-ch1-R.bigfish.com
	(Postfix) with ESMTP id 876D726020F;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail69-ch1 (localhost.localdomain [127.0.0.1]) by mail69-ch1
	(MessageSwitch) id 1326215166291999_4141;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.248])	by mail69-ch1.bigfish.com (Postfix) with ESMTP id
	42293640049;	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:04 +0000
X-WSS-ID: 0LXLE62-01-DU4-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 2F99F1028142;	Tue, 10 Jan 2012 11:06:01 -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;
	Tue, 10 Jan 2012 11:06:11 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:02 -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, 10 Jan 2012
	12:05:58 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 337F849C660; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 1F0A9594885; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 6cb08a39044171124b9b9176b50d2ea9196420bb
Message-ID: <6cb08a39044171124b9b.1326215230@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 04 of 14 V3] 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 1326213589 -3600
# Node ID 6cb08a39044171124b9b9176b50d2ea9196420bb
# Parent  6789e0d335e67e700f97942dd094c548fbbd80f3
amd iommu: Enable ppr log.
IOMMUv2 writes peripheral page service request (PPR) records into ppr log
to report guest OS pending DMA page requests from ATS devices.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 6789e0d335e6 -r 6cb08a390441 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:45 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:49 2012 +0100
@@ -126,14 +126,15 @@ static void register_iommu_dev_table_in_
 
 static void register_iommu_cmd_buffer_in_mmio_space(struct amd_iommu *iommu)
 {
-    u64 addr_64, addr_lo, addr_hi;
+    u64 addr_64;
+    u32 addr_lo, addr_hi;
     u32 power_of2_entries;
     u32 entry;
 
     ASSERT( iommu->cmd_buffer.buffer );
 
-    addr_64 = (u64)virt_to_maddr(iommu->cmd_buffer.buffer);
-    addr_lo = addr_64 & DMA_32BIT_MASK;
+    addr_64 = virt_to_maddr(iommu->cmd_buffer.buffer);
+    addr_lo = addr_64;
     addr_hi = addr_64 >> 32;
 
     entry = 0;
@@ -153,14 +154,15 @@ static void register_iommu_cmd_buffer_in
 
 static void register_iommu_event_log_in_mmio_space(struct amd_iommu *iommu)
 {
-    u64 addr_64, addr_lo, addr_hi;
+    u64 addr_64;
+    u32 addr_lo, addr_hi;
     u32 power_of2_entries;
     u32 entry;
 
     ASSERT( iommu->event_log.buffer );
 
-    addr_64 = (u64)virt_to_maddr(iommu->event_log.buffer);
-    addr_lo = addr_64 & DMA_32BIT_MASK;
+    addr_64 = virt_to_maddr(iommu->event_log.buffer);
+    addr_lo = addr_64;
     addr_hi = addr_64 >> 32;
 
     entry = 0;
@@ -178,6 +180,35 @@ 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;
+    u32 addr_lo, addr_hi;
+    u32 power_of2_entries;
+    u32 entry;
+
+    ASSERT ( iommu->ppr_log.buffer );
+
+    addr_64 = virt_to_maddr(iommu->ppr_log.buffer);
+    addr_lo = addr_64;
+    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)
 {
@@ -215,10 +246,10 @@ static void set_iommu_command_buffer_con
 
 static void register_iommu_exclusion_range(struct amd_iommu *iommu)
 {
-    u64 addr_lo, addr_hi;
+    u32 addr_lo, addr_hi;
     u32 entry;
 
-    addr_lo = iommu->exclusion_limit & DMA_32BIT_MASK;
+    addr_lo = iommu->exclusion_limit;
     addr_hi = iommu->exclusion_limit >> 32;
 
     set_field_in_reg_u32((u32)addr_hi, 0,
@@ -278,6 +309,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 +645,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) )
@@ -671,16 +738,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;
@@ -693,8 +773,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++;
@@ -717,6 +795,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);
@@ -915,6 +994,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 6789e0d335e6 -r 6cb08a390441 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:45 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:49 2012 +0100
@@ -93,6 +93,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 6789e0d335e6 -r 6cb08a390441 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:45 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:49 2012 +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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9P-0006DY-1u; Tue, 10 Jan 2012 17:06:19 +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 1Rkf9M-0006CG-TP
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326215169!8581663!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 27169 invoked from network); 10 Jan 2012 17:06:10 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:10 -0000
Received: from mail171-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; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail171-tx2 (localhost [127.0.0.1])	by
	mail171-tx2-R.bigfish.com (Postfix) with ESMTP id 1FD703E0362;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail171-tx2 (localhost.localdomain [127.0.0.1]) by mail171-tx2
	(MessageSwitch) id 1326215167991836_25489;
	Tue, 10 Jan 2012 17:06:07 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.245])	by
	mail171-tx2.bigfish.com (Postfix) with ESMTP id E952A300044;
	Tue, 10 Jan 2012 17:06:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:04 +0000
X-WSS-ID: 0LXLE63-01-DU5-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 2A6E91028125;	Tue, 10 Jan 2012 11:06:02 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:12 -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, 10 Jan 2012 11:06:03 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:01 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A8EE149C666; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 963A059488A; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f1bf84f5fbb94f8702c8e96462e715ad5066dca2
Message-ID: <f1bf84f5fbb94f8702c8.1326215236@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 10 of 14 V3] 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 1326213611 -3600
# Node ID f1bf84f5fbb94f8702c8e96462e715ad5066dca2
# Parent  2f9c68c3b521efccebebffe76d17ace7dbae5e25
amd iommu: Enable FC bit in iommu host level PTE

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 2f9c68c3b521 -r f1bf84f5fbb9 xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Tue Jan 10 17:40:08 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Tue Jan 10 17:40:11 2012 +0100
@@ -83,6 +83,13 @@ 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);
+
+    /* FC bit should be enabled in PTE, this helps to solve potential
+     * issues with ATS devices 
+     */
+    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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9M-0006CU-Ec; Tue, 10 Jan 2012 17:06:16 +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 1Rkf9K-0006C9-NU
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:14 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326215103!60411129!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10921 invoked from network); 10 Jan 2012 17:05:04 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-7.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:04 -0000
Received: from mail124-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; Tue, 10 Jan 2012 17:06:07 +0000
Received: from mail124-tx2 (localhost [127.0.0.1])	by
	mail124-tx2-R.bigfish.com (Postfix) with ESMTP id E9D7D30039E;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zz14ffO4015Lzz1202hzzz2dhc1ahc1bh668h839h944h61h)
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 mail124-tx2 (localhost.localdomain [127.0.0.1]) by mail124-tx2
	(MessageSwitch) id 1326215165737570_8509;
	Tue, 10 Jan 2012 17:06:05 +0000 (UTC)
Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.253])	by
	mail124-tx2.bigfish.com (Postfix) with ESMTP id ACBED2C0056;
	Tue, 10 Jan 2012 17:06:05 +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; Tue, 10 Jan 2012 17:06:04 +0000
X-WSS-ID: 0LXLE62-01-DU0-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 28442102812C;	Tue, 10 Jan 2012 11:06: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;
	Tue, 10 Jan 2012 11:06:10 -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, 10 Jan 2012 11:06:01 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:00 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D992A49C58B; Tue, 10 Jan 2012
	17:05:56 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C8F5F5940FF; Tue, 10 Jan 2012
	18:05:56 +0100 (CET)
MIME-Version: 1.0
Message-ID: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07:06 +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 14 V3] 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

Hi all, this is patch v3.
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 v3:
* Use xenstore to receive guest iommu configuration instead of adding in a new field in hvm_info_table.
* Support pci segment in vbdf to mbdf bind.
* Make hypercalls visible for non-x86 platforms.
* A few code cleanups according to comments from Jan and Ian.

Changes in v2:
* Do not use linked list to access guest iommu tables.
* Do not parse iommu parameter in libxl_device_model_info again.
* Fix incorrect logical calculation in patch 11.
* Fix hypercall definition for non-x86 systems.

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9P-0006DY-1u; Tue, 10 Jan 2012 17:06:19 +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 1Rkf9M-0006CG-TP
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:17 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326215169!8581663!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 27169 invoked from network); 10 Jan 2012 17:06:10 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE009.bigfish.com) (65.55.88.14)
	by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:10 -0000
Received: from mail171-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; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail171-tx2 (localhost [127.0.0.1])	by
	mail171-tx2-R.bigfish.com (Postfix) with ESMTP id 1FD703E0362;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail171-tx2 (localhost.localdomain [127.0.0.1]) by mail171-tx2
	(MessageSwitch) id 1326215167991836_25489;
	Tue, 10 Jan 2012 17:06:07 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.245])	by
	mail171-tx2.bigfish.com (Postfix) with ESMTP id E952A300044;
	Tue, 10 Jan 2012 17:06:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:04 +0000
X-WSS-ID: 0LXLE63-01-DU5-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 2A6E91028125;	Tue, 10 Jan 2012 11:06:02 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:12 -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, 10 Jan 2012 11:06:03 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:01 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id A8EE149C666; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 963A059488A; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f1bf84f5fbb94f8702c8e96462e715ad5066dca2
Message-ID: <f1bf84f5fbb94f8702c8.1326215236@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 10 of 14 V3] 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 1326213611 -3600
# Node ID f1bf84f5fbb94f8702c8e96462e715ad5066dca2
# Parent  2f9c68c3b521efccebebffe76d17ace7dbae5e25
amd iommu: Enable FC bit in iommu host level PTE

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 2f9c68c3b521 -r f1bf84f5fbb9 xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Tue Jan 10 17:40:08 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Tue Jan 10 17:40:11 2012 +0100
@@ -83,6 +83,13 @@ 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);
+
+    /* FC bit should be enabled in PTE, this helps to solve potential
+     * issues with ATS devices 
+     */
+    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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9R-0006Fe-Eo; Tue, 10 Jan 2012 17:06:21 +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 1Rkf9P-0006CT-IT
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326215132!59658063!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 16577 invoked from network); 10 Jan 2012 17:05:33 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:33 -0000
Received: from mail49-tx2-R.bigfish.com (10.9.14.239) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:11 +0000
Received: from mail49-tx2 (localhost [127.0.0.1])	by mail49-tx2-R.bigfish.com
	(Postfix) with ESMTP id 9945C800C1;
	Tue, 10 Jan 2012 17:06:11 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc8kzz1202hzz8275bh5eeeKz2dhc1ahc1bh668h839h944h61h)
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 mail49-tx2 (localhost.localdomain [127.0.0.1]) by mail49-tx2
	(MessageSwitch) id 1326215168759159_30172;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.252])	by
	mail49-tx2.bigfish.com (Postfix) with ESMTP id 9D7A41C0228;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:04 +0000
X-WSS-ID: 0LXLE63-01-DU7-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 24195102811E;	Tue, 10 Jan 2012 11:06:02 -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, 10 Jan 2012 11:06: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;
	Tue, 10 Jan 2012 11:06:02 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:00 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1F17549C65F; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 0C557594884; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 6789e0d335e67e700f97942dd094c548fbbd80f3
Message-ID: <6789e0d335e67e700f97.1326215229@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 03 of 14 V3] 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 1326213585 -3600
# Node ID 6789e0d335e67e700f97942dd094c548fbbd80f3
# Parent  dfdc0df7d68fa4551271b29671a2d333b185a48c
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 guest OS. We have to expose iommu functionality to HVM guest, if we want assign ATS device
to it. A new hypervisor mmio handler is added to intercept iommu mmio accesses from 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 dfdc0df7d68f -r 6789e0d335e6 xen/arch/x86/hvm/intercept.c
--- a/xen/arch/x86/hvm/intercept.c	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/arch/x86/hvm/intercept.c	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/drivers/passthrough/amd/Makefile
--- a/xen/drivers/passthrough/amd/Makefile	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/drivers/passthrough/amd/Makefile	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 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	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:45 2012 +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))
@@ -129,4 +130,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 dfdc0df7d68f -r 6789e0d335e6 xen/include/asm-x86/hvm/io.h
--- a/xen/include/asm-x86/hvm/io.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/asm-x86/hvm/io.h	Tue Jan 10 17:39:45 2012 +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(
diff -r dfdc0df7d68f -r 6789e0d335e6 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:45 2012 +0100
@@ -113,6 +113,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
@@ -123,6 +130,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
@@ -151,6 +160,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
@@ -179,6 +190,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 */
@@ -265,6 +277,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
@@ -292,6 +326,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
@@ -325,7 +364,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
@@ -342,6 +382,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 dfdc0df7d68f -r 6789e0d335e6 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/include/xen/hvm/iommu.h
--- a/xen/include/xen/hvm/iommu.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/xen/hvm/iommu.h	Tue Jan 10 17:39:45 2012 +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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9M-0006CU-Ec; Tue, 10 Jan 2012 17:06:16 +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 1Rkf9K-0006C9-NU
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:14 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326215103!60411129!1
X-Originating-IP: [65.55.88.14]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10921 invoked from network); 10 Jan 2012 17:05:04 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-7.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:04 -0000
Received: from mail124-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; Tue, 10 Jan 2012 17:06:07 +0000
Received: from mail124-tx2 (localhost [127.0.0.1])	by
	mail124-tx2-R.bigfish.com (Postfix) with ESMTP id E9D7D30039E;
	Tue, 10 Jan 2012 17:06:06 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zz14ffO4015Lzz1202hzzz2dhc1ahc1bh668h839h944h61h)
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 mail124-tx2 (localhost.localdomain [127.0.0.1]) by mail124-tx2
	(MessageSwitch) id 1326215165737570_8509;
	Tue, 10 Jan 2012 17:06:05 +0000 (UTC)
Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.253])	by
	mail124-tx2.bigfish.com (Postfix) with ESMTP id ACBED2C0056;
	Tue, 10 Jan 2012 17:06:05 +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; Tue, 10 Jan 2012 17:06:04 +0000
X-WSS-ID: 0LXLE62-01-DU0-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 28442102812C;	Tue, 10 Jan 2012 11:06: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;
	Tue, 10 Jan 2012 11:06:10 -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, 10 Jan 2012 11:06:01 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:00 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D992A49C58B; Tue, 10 Jan 2012
	17:05:56 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C8F5F5940FF; Tue, 10 Jan 2012
	18:05:56 +0100 (CET)
MIME-Version: 1.0
Message-ID: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07:06 +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 14 V3] 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

Hi all, this is patch v3.
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 v3:
* Use xenstore to receive guest iommu configuration instead of adding in a new field in hvm_info_table.
* Support pci segment in vbdf to mbdf bind.
* Make hypercalls visible for non-x86 platforms.
* A few code cleanups according to comments from Jan and Ian.

Changes in v2:
* Do not use linked list to access guest iommu tables.
* Do not parse iommu parameter in libxl_device_model_info again.
* Fix incorrect logical calculation in patch 11.
* Fix hypercall definition for non-x86 systems.

Thanks,
Wei


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9U-0006IG-5V; Tue, 10 Jan 2012 17:06: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 1Rkf9S-0006Cr-P2
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326215155!61882897!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 24093 invoked from network); 10 Jan 2012 17:05:56 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-15.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:56 -0000
Received: from mail191-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:15 +0000
Received: from mail191-ch1 (localhost [127.0.0.1])	by
	mail191-ch1-R.bigfish.com (Postfix) with ESMTP id DF09BE013A;
	Tue, 10 Jan 2012 17:06:14 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail191-ch1 (localhost.localdomain [127.0.0.1]) by mail191-ch1
	(MessageSwitch) id 1326215172717576_13644;
	Tue, 10 Jan 2012 17:06:12 +0000 (UTC)
Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.254])	by mail191-ch1.bigfish.com (Postfix) with ESMTP id
	A9F03480046;	Tue, 10 Jan 2012 17:06:12 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
X-WSS-ID: 0LXLE68-01-DUJ-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 2D8C81028120;	Tue, 10 Jan 2012 11:06:07 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:16 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:07 -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, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D8C1849C668; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C5892594884; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2dc60e3398dd602a34ebdf92103a3957b97c02c5
Message-ID: <2dc60e3398dd602a34eb.1326215238@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 12 of 14 V3] 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 1326213617 -3600
# Node ID 2dc60e3398dd602a34ebdf92103a3957b97c02c5
# Parent  01d2c1d4e3b992997f170d95dccc2195b9206b04
libxc: add wrappers for new hypercalls

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 01d2c1d4e3b9 -r 2dc60e3398dd tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Tue Jan 10 17:40:14 2012 +0100
+++ b/tools/libxc/xc_domain.c	Tue Jan 10 17:40:17 2012 +0100
@@ -1352,6 +1352,59 @@ int xc_domain_bind_pt_isa_irq(
                                   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+    uint32_t domid,
+    uint16_t gseg,
+    uint16_t gbdf,
+    uint16_t mseg,
+    uint16_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_seg = gseg;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_seg = mseg;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
 int xc_domain_memory_mapping(
     xc_interface *xch,
     uint32_t domid,
diff -r 01d2c1d4e3b9 -r 2dc60e3398dd tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Tue Jan 10 17:40:14 2012 +0100
+++ b/tools/libxc/xenctrl.h	Tue Jan 10 17:40:17 2012 +0100
@@ -1697,6 +1697,21 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                               uint32_t domid,
                               uint8_t machine_irq);
 
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint16_t gseg,
+                          uint16_t gbdf,
+                          uint16_t mseg, 
+                          uint16_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
 int xc_domain_set_machine_address_size(xc_interface *xch,
 				       uint32_t domid,
 				       unsigned int width);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9R-0006Fe-Eo; Tue, 10 Jan 2012 17:06:21 +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 1Rkf9P-0006CT-IT
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326215132!59658063!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 16577 invoked from network); 10 Jan 2012 17:05:33 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-9.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:33 -0000
Received: from mail49-tx2-R.bigfish.com (10.9.14.239) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:11 +0000
Received: from mail49-tx2 (localhost [127.0.0.1])	by mail49-tx2-R.bigfish.com
	(Postfix) with ESMTP id 9945C800C1;
	Tue, 10 Jan 2012 17:06:11 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc8kzz1202hzz8275bh5eeeKz2dhc1ahc1bh668h839h944h61h)
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 mail49-tx2 (localhost.localdomain [127.0.0.1]) by mail49-tx2
	(MessageSwitch) id 1326215168759159_30172;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.252])	by
	mail49-tx2.bigfish.com (Postfix) with ESMTP id 9D7A41C0228;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:04 +0000
X-WSS-ID: 0LXLE63-01-DU7-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 24195102811E;	Tue, 10 Jan 2012 11:06:02 -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, 10 Jan 2012 11:06: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;
	Tue, 10 Jan 2012 11:06:02 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:00 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 1F17549C65F; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 0C557594884; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 6789e0d335e67e700f97942dd094c548fbbd80f3
Message-ID: <6789e0d335e67e700f97.1326215229@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 03 of 14 V3] 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 1326213585 -3600
# Node ID 6789e0d335e67e700f97942dd094c548fbbd80f3
# Parent  dfdc0df7d68fa4551271b29671a2d333b185a48c
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 guest OS. We have to expose iommu functionality to HVM guest, if we want assign ATS device
to it. A new hypervisor mmio handler is added to intercept iommu mmio accesses from 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 dfdc0df7d68f -r 6789e0d335e6 xen/arch/x86/hvm/intercept.c
--- a/xen/arch/x86/hvm/intercept.c	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/arch/x86/hvm/intercept.c	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/drivers/passthrough/amd/Makefile
--- a/xen/drivers/passthrough/amd/Makefile	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/drivers/passthrough/amd/Makefile	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 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	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/drivers/passthrough/amd/iommu_map.c
--- a/xen/drivers/passthrough/amd/iommu_map.c	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_map.c	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/drivers/passthrough/amd/pci_amd_iommu.c
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:45 2012 +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))
@@ -129,4 +130,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 dfdc0df7d68f -r 6789e0d335e6 xen/include/asm-x86/hvm/io.h
--- a/xen/include/asm-x86/hvm/io.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/asm-x86/hvm/io.h	Tue Jan 10 17:39:45 2012 +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(
diff -r dfdc0df7d68f -r 6789e0d335e6 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-defs.h	Tue Jan 10 17:39:45 2012 +0100
@@ -113,6 +113,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
@@ -123,6 +130,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
@@ -151,6 +160,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
@@ -179,6 +190,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 */
@@ -265,6 +277,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
@@ -292,6 +326,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
@@ -325,7 +364,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
@@ -342,6 +382,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 dfdc0df7d68f -r 6789e0d335e6 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Tue Jan 10 17:39:45 2012 +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 dfdc0df7d68f -r 6789e0d335e6 xen/include/xen/hvm/iommu.h
--- a/xen/include/xen/hvm/iommu.h	Tue Jan 10 17:39:41 2012 +0100
+++ b/xen/include/xen/hvm/iommu.h	Tue Jan 10 17:39:45 2012 +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 Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9U-0006IG-5V; Tue, 10 Jan 2012 17:06: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 1Rkf9S-0006Cr-P2
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:22 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326215155!61882897!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 24093 invoked from network); 10 Jan 2012 17:05:56 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-15.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:56 -0000
Received: from mail191-ch1-R.bigfish.com (10.43.68.247) by
	CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:15 +0000
Received: from mail191-ch1 (localhost [127.0.0.1])	by
	mail191-ch1-R.bigfish.com (Postfix) with ESMTP id DF09BE013A;
	Tue, 10 Jan 2012 17:06:14 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail191-ch1 (localhost.localdomain [127.0.0.1]) by mail191-ch1
	(MessageSwitch) id 1326215172717576_13644;
	Tue, 10 Jan 2012 17:06:12 +0000 (UTC)
Received: from CH1EHSMHS003.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.254])	by mail191-ch1.bigfish.com (Postfix) with ESMTP id
	A9F03480046;	Tue, 10 Jan 2012 17:06:12 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
X-WSS-ID: 0LXLE68-01-DUJ-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 2D8C81028120;	Tue, 10 Jan 2012 11:06:07 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:16 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:07 -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, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D8C1849C668; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id C5892594884; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2dc60e3398dd602a34ebdf92103a3957b97c02c5
Message-ID: <2dc60e3398dd602a34eb.1326215238@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 12 of 14 V3] 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 1326213617 -3600
# Node ID 2dc60e3398dd602a34ebdf92103a3957b97c02c5
# Parent  01d2c1d4e3b992997f170d95dccc2195b9206b04
libxc: add wrappers for new hypercalls

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 01d2c1d4e3b9 -r 2dc60e3398dd tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Tue Jan 10 17:40:14 2012 +0100
+++ b/tools/libxc/xc_domain.c	Tue Jan 10 17:40:17 2012 +0100
@@ -1352,6 +1352,59 @@ int xc_domain_bind_pt_isa_irq(
                                   PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
 }
 
+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+    uint32_t domid,
+    uint16_t gseg,
+    uint16_t gbdf,
+    uint16_t mseg,
+    uint16_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_seg = gseg;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_seg = mseg;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
 int xc_domain_memory_mapping(
     xc_interface *xch,
     uint32_t domid,
diff -r 01d2c1d4e3b9 -r 2dc60e3398dd tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Tue Jan 10 17:40:14 2012 +0100
+++ b/tools/libxc/xenctrl.h	Tue Jan 10 17:40:17 2012 +0100
@@ -1697,6 +1697,21 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                               uint32_t domid,
                               uint8_t machine_irq);
 
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint16_t gseg,
+                          uint16_t gbdf,
+                          uint16_t mseg, 
+                          uint16_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
 int xc_domain_set_machine_address_size(xc_interface *xch,
 				       uint32_t domid,
 				       unsigned int width);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9T-0006HP-HV; Tue, 10 Jan 2012 17:06:23 +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 1Rkf9Q-0006EV-Np
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:21 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326215144!47832624!1
X-Originating-IP: [65.55.88.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 21876 invoked from network); 10 Jan 2012 17:05:45 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:45 -0000
Received: from mail75-tx2-R.bigfish.com (10.9.14.241) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:17 +0000
Received: from mail75-tx2 (localhost [127.0.0.1])	by mail75-tx2-R.bigfish.com
	(Postfix) with ESMTP id 4AFBB20461;
	Tue, 10 Jan 2012 17:06:17 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2
	(MessageSwitch) id 1326215174828523_8178;
	Tue, 10 Jan 2012 17:06:14 +0000 (UTC)
Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.241])	by
	mail75-tx2.bigfish.com (Postfix) with ESMTP id B94EC200045;
	Tue, 10 Jan 2012 17:06:14 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
X-WSS-ID: 0LXLE68-01-DUL-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 2506C102811E;	Tue, 10 Jan 2012 11:06:07 -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, 10 Jan 2012 11:06:16 -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, 10 Jan 2012 11:06:08 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:01 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7727749C663; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 5E025594888; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 31e61ed495ae1429e3317f8b0359ff37fdcbb6cd
Message-ID: <31e61ed495ae1429e331.1326215233@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 07 of 14 V3] 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 1326213601 -3600
# Node ID 31e61ed495ae1429e3317f8b0359ff37fdcbb6cd
# Parent  3d252e3969bae12e85e5a1f2f339dad169d0d892
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 3d252e3969ba -r 31e61ed495ae xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 10 17:40:01 2012 +0100
@@ -48,14 +48,31 @@
         (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
     } while(0)
 
-static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
+static unsigned int machine_bdf(struct domain *d, uint16_t guest_seg,
+                                uint16_t guest_bdf)
 {
-    return guest_bdf;
+    struct pci_dev *pdev;
+    uint16_t mbdf = 0;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->gbdf == guest_bdf) && (pdev->gseg == guest_seg) )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
 }
 
-static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_seg,
+                          uint16_t machine_bdf)
 {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, machine_seg, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
 }
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -207,7 +224,7 @@ void guest_iommu_add_ppr_log(struct doma
     log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));
 
     /* Convert physical device id back into virtual device id */
-    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    gdev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
     iommu_set_devid_to_cmd(&entry[0], gdev_id);
 
     memcpy(log, entry, sizeof(ppr_entry_t));
@@ -250,7 +267,7 @@ void guest_iommu_add_event_log(struct do
     log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));
 
     /* re-write physical device id into virtual device id */
-    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    dev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
     iommu_set_devid_to_cmd(&entry[0], dev_id);
     memcpy(log, entry, sizeof(event_entry_t));
 
@@ -272,7 +289,7 @@ static int do_complete_ppr_request(struc
     uint16_t dev_id;
     struct amd_iommu *iommu;
 
-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
     iommu = find_iommu_for_device(0, dev_id);
 
     if ( !iommu )
@@ -324,7 +341,7 @@ static int do_invalidate_iotlb_pages(str
     struct amd_iommu *iommu;
     uint16_t dev_id;
 
-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
 
     iommu = find_iommu_for_device(0, dev_id);
     if ( !iommu )
@@ -402,7 +419,7 @@ static int do_invalidate_dte(struct doma
 
     g_iommu = domain_iommu(d);
     gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
-    mbdf = machine_bdf(d, gbdf);
+    mbdf = machine_bdf(d, 0, gbdf);
 
     /* Guest can only update DTEs for its passthru devices */
     if ( mbdf == 0 || gbdf == 0 )
@@ -913,3 +930,45 @@ const struct hvm_mmio_handler iommu_mmio
     .read_handler = guest_iommu_mmio_read,
     .write_handler = guest_iommu_mmio_write
 };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
+                   uint16_t mseg, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() )
+        return 0;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) || 
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gseg = gseg;
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu_found() )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r 3d252e3969ba -r 31e61ed495ae xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/drivers/passthrough/iommu.c	Tue Jan 10 17:40:01 2012 +0100
@@ -648,6 +648,40 @@ int iommu_do_domctl(
         put_domain(d);
         break;
 
+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector, 
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode, 
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
+                                     guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_seg,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+
     default:
         ret = -ENOSYS;
         break;
diff -r 3d252e3969ba -r 31e61ed495ae xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/include/public/domctl.h	Tue Jan 10 17:40:01 2012 +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);
 
+/* Support for guest iommu emulation */
+struct xen_domctl_guest_iommu_op {
+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
+    uint8_t op;
+    union {
+        struct iommu_msi {
+        uint8_t  vector;
+        uint8_t  dest;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind {
+            uint16_t            g_seg;
+            uint16_t            g_bdf;
+            uint16_t            m_seg;
+            uint16_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -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
@@ -960,6 +986,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 3d252e3969ba -r 31e61ed495ae xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/include/xen/iommu.h	Tue Jan 10 17:40:01 2012 +0100
@@ -164,6 +164,12 @@ int iommu_do_domctl(struct xen_domctl *,
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
 
+/* Only used by AMD IOMMU so far */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf, 
+                   uint16_t mseg, uint16_t mbdf);
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r 3d252e3969ba -r 31e61ed495ae xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/include/xen/pci.h	Tue Jan 10 17:40:01 2012 +0100
@@ -59,6 +59,11 @@ struct pci_dev {
     const u16 seg;
     const u8 bus;
     const u8 devfn;
+
+    /* Used by iommu to represent virtual seg and bdf value in guest space */
+    u16 gseg;
+    u16 gbdf;
+
     struct pci_dev_info info;
     struct arch_pci_dev arch;
     u64 vf_rlen[6];


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9T-0006HP-HV; Tue, 10 Jan 2012 17:06:23 +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 1Rkf9Q-0006EV-Np
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:21 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326215144!47832624!1
X-Originating-IP: [65.55.88.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 21876 invoked from network); 10 Jan 2012 17:05:45 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-12.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:45 -0000
Received: from mail75-tx2-R.bigfish.com (10.9.14.241) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:17 +0000
Received: from mail75-tx2 (localhost [127.0.0.1])	by mail75-tx2-R.bigfish.com
	(Postfix) with ESMTP id 4AFBB20461;
	Tue, 10 Jan 2012 17:06:17 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail75-tx2 (localhost.localdomain [127.0.0.1]) by mail75-tx2
	(MessageSwitch) id 1326215174828523_8178;
	Tue, 10 Jan 2012 17:06:14 +0000 (UTC)
Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.241])	by
	mail75-tx2.bigfish.com (Postfix) with ESMTP id B94EC200045;
	Tue, 10 Jan 2012 17:06:14 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:10 +0000
X-WSS-ID: 0LXLE68-01-DUL-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 2506C102811E;	Tue, 10 Jan 2012 11:06:07 -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, 10 Jan 2012 11:06:16 -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, 10 Jan 2012 11:06:08 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:01 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 7727749C663; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 5E025594888; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 31e61ed495ae1429e3317f8b0359ff37fdcbb6cd
Message-ID: <31e61ed495ae1429e331.1326215233@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 07 of 14 V3] 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 1326213601 -3600
# Node ID 31e61ed495ae1429e3317f8b0359ff37fdcbb6cd
# Parent  3d252e3969bae12e85e5a1f2f339dad169d0d892
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 3d252e3969ba -r 31e61ed495ae xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 10 17:40:01 2012 +0100
@@ -48,14 +48,31 @@
         (reg)->hi = (val >> 32) & 0xFFFFFFFF; \
     } while(0)
 
-static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
+static unsigned int machine_bdf(struct domain *d, uint16_t guest_seg,
+                                uint16_t guest_bdf)
 {
-    return guest_bdf;
+    struct pci_dev *pdev;
+    uint16_t mbdf = 0;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->gbdf == guest_bdf) && (pdev->gseg == guest_seg) )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
 }
 
-static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_seg,
+                          uint16_t machine_bdf)
 {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, machine_seg, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
 }
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -207,7 +224,7 @@ void guest_iommu_add_ppr_log(struct doma
     log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));
 
     /* Convert physical device id back into virtual device id */
-    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    gdev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
     iommu_set_devid_to_cmd(&entry[0], gdev_id);
 
     memcpy(log, entry, sizeof(ppr_entry_t));
@@ -250,7 +267,7 @@ void guest_iommu_add_event_log(struct do
     log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));
 
     /* re-write physical device id into virtual device id */
-    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    dev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
     iommu_set_devid_to_cmd(&entry[0], dev_id);
     memcpy(log, entry, sizeof(event_entry_t));
 
@@ -272,7 +289,7 @@ static int do_complete_ppr_request(struc
     uint16_t dev_id;
     struct amd_iommu *iommu;
 
-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
     iommu = find_iommu_for_device(0, dev_id);
 
     if ( !iommu )
@@ -324,7 +341,7 @@ static int do_invalidate_iotlb_pages(str
     struct amd_iommu *iommu;
     uint16_t dev_id;
 
-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
 
     iommu = find_iommu_for_device(0, dev_id);
     if ( !iommu )
@@ -402,7 +419,7 @@ static int do_invalidate_dte(struct doma
 
     g_iommu = domain_iommu(d);
     gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
-    mbdf = machine_bdf(d, gbdf);
+    mbdf = machine_bdf(d, 0, gbdf);
 
     /* Guest can only update DTEs for its passthru devices */
     if ( mbdf == 0 || gbdf == 0 )
@@ -913,3 +930,45 @@ const struct hvm_mmio_handler iommu_mmio
     .read_handler = guest_iommu_mmio_read,
     .write_handler = guest_iommu_mmio_write
 };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
+                   uint16_t mseg, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() )
+        return 0;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) || 
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gseg = gseg;
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu_found() )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r 3d252e3969ba -r 31e61ed495ae xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/drivers/passthrough/iommu.c	Tue Jan 10 17:40:01 2012 +0100
@@ -648,6 +648,40 @@ int iommu_do_domctl(
         put_domain(d);
         break;
 
+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector, 
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode, 
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
+                                     guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_seg,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+
     default:
         ret = -ENOSYS;
         break;
diff -r 3d252e3969ba -r 31e61ed495ae xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/include/public/domctl.h	Tue Jan 10 17:40:01 2012 +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);
 
+/* Support for guest iommu emulation */
+struct xen_domctl_guest_iommu_op {
+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
+    uint8_t op;
+    union {
+        struct iommu_msi {
+        uint8_t  vector;
+        uint8_t  dest;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind {
+            uint16_t            g_seg;
+            uint16_t            g_bdf;
+            uint16_t            m_seg;
+            uint16_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+
 struct xen_domctl {
     uint32_t cmd;
 #define XEN_DOMCTL_createdomain                   1
@@ -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
@@ -960,6 +986,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 3d252e3969ba -r 31e61ed495ae xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/include/xen/iommu.h	Tue Jan 10 17:40:01 2012 +0100
@@ -164,6 +164,12 @@ int iommu_do_domctl(struct xen_domctl *,
 void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int page_count);
 void iommu_iotlb_flush_all(struct domain *d);
 
+/* Only used by AMD IOMMU so far */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode, 
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf, 
+                   uint16_t mseg, uint16_t mbdf);
 /*
  * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
  * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r 3d252e3969ba -r 31e61ed495ae xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Tue Jan 10 17:39:57 2012 +0100
+++ b/xen/include/xen/pci.h	Tue Jan 10 17:40:01 2012 +0100
@@ -59,6 +59,11 @@ struct pci_dev {
     const u16 seg;
     const u8 bus;
     const u8 devfn;
+
+    /* Used by iommu to represent virtual seg and bdf value in guest space */
+    u16 gseg;
+    u16 gbdf;
+
     struct pci_dev_info info;
     struct arch_pci_dev arch;
     u64 vf_rlen[6];


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9N-0006Cy-Rx; Tue, 10 Jan 2012 17:06: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 1Rkf9M-0006CE-Gg
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:16 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326215168!10476369!2
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 4364 invoked from network); 10 Jan 2012 17:06:10 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-9.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:10 -0000
Received: from mail76-ch1-R.bigfish.com (10.43.68.254) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail76-ch1 (localhost [127.0.0.1])	by mail76-ch1-R.bigfish.com
	(Postfix) with ESMTP id 9EDD04A0181;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail76-ch1 (localhost.localdomain [127.0.0.1]) by mail76-ch1
	(MessageSwitch) id 1326215168530996_11817;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.246])	by mail76-ch1.bigfish.com (Postfix) with ESMTP id
	71EED300048;	Tue, 10 Jan 2012 17:06:08 +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; Tue, 10 Jan 2012 17:06:06 +0000
X-WSS-ID: 0LXLE64-01-DUA-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 29F191028128;	Tue, 10 Jan 2012 11:06:03 -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, 10 Jan 2012 11:06:12 -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, 10 Jan 2012 11:06:04 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:01 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 965F549C665; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 8995A594882; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2f9c68c3b521efccebebffe76d17ace7dbae5e25
Message-ID: <2f9c68c3b521efccebeb.1326215235@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 09 of 14 V3] 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 1326213608 -3600
# Node ID 2f9c68c3b521efccebebffe76d17ace7dbae5e25
# Parent  82f5e77e13c43f0e4e34dfefdd218aec092f9542
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 82f5e77e13c4 -r 2f9c68c3b521 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Tue Jan 10 17:40:04 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Tue Jan 10 17:40:08 2012 +0100
@@ -65,6 +65,7 @@
 #include <public/memory.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
 
 bool_t __read_mostly hvm_enabled;
 
@@ -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 82f5e77e13c4 -r 2f9c68c3b521 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Tue Jan 10 17:40:04 2012 +0100
+++ b/xen/include/public/hvm/params.h	Tue Jan 10 17:40:08 2012 +0100
@@ -141,7 +141,8 @@
 
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
+#define HVM_PARAM_IOMMU_BASE   27
 
-#define HVM_NR_PARAMS          27
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9N-0006Cy-Rx; Tue, 10 Jan 2012 17:06: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 1Rkf9M-0006CE-Gg
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:16 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326215168!10476369!2
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 4364 invoked from network); 10 Jan 2012 17:06:10 -0000
Received: from ch1ehsobe006.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.186)
	by server-9.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:10 -0000
Received: from mail76-ch1-R.bigfish.com (10.43.68.254) by
	CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:08 +0000
Received: from mail76-ch1 (localhost [127.0.0.1])	by mail76-ch1-R.bigfish.com
	(Postfix) with ESMTP id 9EDD04A0181;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail76-ch1 (localhost.localdomain [127.0.0.1]) by mail76-ch1
	(MessageSwitch) id 1326215168530996_11817;
	Tue, 10 Jan 2012 17:06:08 +0000 (UTC)
Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.246])	by mail76-ch1.bigfish.com (Postfix) with ESMTP id
	71EED300048;	Tue, 10 Jan 2012 17:06:08 +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; Tue, 10 Jan 2012 17:06:06 +0000
X-WSS-ID: 0LXLE64-01-DUA-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 29F191028128;	Tue, 10 Jan 2012 11:06:03 -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, 10 Jan 2012 11:06:12 -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, 10 Jan 2012 11:06:04 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Tue, 10 Jan 2012
	12:06:01 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 965F549C665; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 8995A594882; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2f9c68c3b521efccebebffe76d17ace7dbae5e25
Message-ID: <2f9c68c3b521efccebeb.1326215235@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 09 of 14 V3] 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 1326213608 -3600
# Node ID 2f9c68c3b521efccebebffe76d17ace7dbae5e25
# Parent  82f5e77e13c43f0e4e34dfefdd218aec092f9542
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 82f5e77e13c4 -r 2f9c68c3b521 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Tue Jan 10 17:40:04 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Tue Jan 10 17:40:08 2012 +0100
@@ -65,6 +65,7 @@
 #include <public/memory.h>
 #include <asm/mem_event.h>
 #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>
 
 bool_t __read_mostly hvm_enabled;
 
@@ -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 82f5e77e13c4 -r 2f9c68c3b521 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Tue Jan 10 17:40:04 2012 +0100
+++ b/xen/include/public/hvm/params.h	Tue Jan 10 17:40:08 2012 +0100
@@ -141,7 +141,8 @@
 
 /* Boolean: Enable nestedhvm (hvm only) */
 #define HVM_PARAM_NESTEDHVM    24
+#define HVM_PARAM_IOMMU_BASE   27
 
-#define HVM_NR_PARAMS          27
+#define HVM_NR_PARAMS          28
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:06:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9l-0006ZH-K2; Tue, 10 Jan 2012 17:06:41 +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 1Rkf9j-0006U9-Iv
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:39 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326215191!10436471!1
X-Originating-IP: [65.55.88.13]
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 31893 invoked from network); 10 Jan 2012 17:06:32 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.13)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:32 -0000
Received: from mail121-tx2-R.bigfish.com (10.9.14.238) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:30 +0000
Received: from mail121-tx2 (localhost [127.0.0.1])	by
	mail121-tx2-R.bigfish.com (Postfix) with ESMTP id 1D4988024E;
	Tue, 10 Jan 2012 17:06:30 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail121-tx2 (localhost.localdomain [127.0.0.1]) by mail121-tx2
	(MessageSwitch) id 1326215165551133_25780;
	Tue, 10 Jan 2012 17:06:05 +0000 (UTC)
Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.252])	by
	mail121-tx2.bigfish.com (Postfix) with ESMTP id 6C5C3100042;
	Tue, 10 Jan 2012 17:06:05 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:05 +0000
X-WSS-ID: 0LXLE63-02-DA5-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 2BE1CC8147;	Tue, 10 Jan 2012 11:06:03 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:12 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:03 -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, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 464B549C661; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 33748594886; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e698b7b63a9dc75c5cad4dbe02d38d90bdaf1512
Message-ID: <e698b7b63a9dc75c5cad.1326215231@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 05 of 14 V3] 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 1326213593 -3600
# Node ID e698b7b63a9dc75c5cad4dbe02d38d90bdaf1512
# Parent  6cb08a39044171124b9b9176b50d2ea9196420bb
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 6cb08a390441 -r e698b7b63a9d xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:49 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:53 2012 +0100
@@ -223,6 +223,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)
 {
@@ -658,6 +675,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) )
@@ -998,6 +1018,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 Tue Jan 10 17:06:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9l-0006ZH-K2; Tue, 10 Jan 2012 17:06:41 +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 1Rkf9j-0006U9-Iv
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:39 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326215191!10436471!1
X-Originating-IP: [65.55.88.13]
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 31893 invoked from network); 10 Jan 2012 17:06:32 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.13)
	by server-14.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:06:32 -0000
Received: from mail121-tx2-R.bigfish.com (10.9.14.238) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:30 +0000
Received: from mail121-tx2 (localhost [127.0.0.1])	by
	mail121-tx2-R.bigfish.com (Postfix) with ESMTP id 1D4988024E;
	Tue, 10 Jan 2012 17:06:30 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail121-tx2 (localhost.localdomain [127.0.0.1]) by mail121-tx2
	(MessageSwitch) id 1326215165551133_25780;
	Tue, 10 Jan 2012 17:06:05 +0000 (UTC)
Received: from TX2EHSMHS044.bigfish.com (unknown [10.9.14.252])	by
	mail121-tx2.bigfish.com (Postfix) with ESMTP id 6C5C3100042;
	Tue, 10 Jan 2012 17:06:05 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS044.bigfish.com (10.9.99.144) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:05 +0000
X-WSS-ID: 0LXLE63-02-DA5-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 2BE1CC8147;	Tue, 10 Jan 2012 11:06:03 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:12 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:03 -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, 10 Jan 2012
	12:06:02 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 464B549C661; Tue, 10 Jan 2012
	17:05:57 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id 33748594886; Tue, 10 Jan 2012
	18:05:57 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e698b7b63a9dc75c5cad4dbe02d38d90bdaf1512
Message-ID: <e698b7b63a9dc75c5cad.1326215231@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07: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 05 of 14 V3] 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 1326213593 -3600
# Node ID e698b7b63a9dc75c5cad4dbe02d38d90bdaf1512
# Parent  6cb08a39044171124b9b9176b50d2ea9196420bb
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 6cb08a390441 -r e698b7b63a9d xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:49 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:53 2012 +0100
@@ -223,6 +223,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)
 {
@@ -658,6 +675,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) )
@@ -998,6 +1018,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 Tue Jan 10 17:06:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9m-0006Zc-0h; Tue, 10 Jan 2012 17:06:42 +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 1Rkf9j-0006XC-O8
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:40 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326215140!60252509!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 21525 invoked from network); 10 Jan 2012 17:05:42 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-2.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:42 -0000
Received: from mail152-tx2-R.bigfish.com (10.9.14.254) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:36 +0000
Received: from mail152-tx2 (localhost [127.0.0.1])	by
	mail152-tx2-R.bigfish.com (Postfix) with ESMTP id 677916A0478;
	Tue, 10 Jan 2012 17:06:36 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail152-tx2 (localhost.localdomain [127.0.0.1]) by mail152-tx2
	(MessageSwitch) id 1326215167306086_31834;
	Tue, 10 Jan 2012 17:06:07 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.236])	by
	mail152-tx2.bigfish.com (Postfix) with ESMTP id 3AD1BC004A;
	Tue, 10 Jan 2012 17:06:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:03 +0000
X-WSS-ID: 0LXLE60-01-DTW-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 201EF1028129;	Tue, 10 Jan 2012 11:06:00 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:10 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:01 -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, 10 Jan 2012
	12:05:58 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EC26F49C65D; Tue, 10 Jan 2012
	17:05:56 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id D9509594882; Tue, 10 Jan 2012
	18:05:56 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9c9ddf2dd700119fdaf8a420fb051c22279853cc
Message-ID: <9c9ddf2dd700119fdaf8.1326215227@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07:07 +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 14 V3] 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 1326213576 -3600
# Node ID 9c9ddf2dd700119fdaf8a420fb051c22279853cc
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
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 5b2676ac1321 -r 9c9ddf2dd700 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:36 2012 +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 5b2676ac1321 -r 9c9ddf2dd700 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:36 2012 +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,82 @@ 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->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 +719,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 +730,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 +841,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 5b2676ac1321 -r 9c9ddf2dd700 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:36 2012 +0100
@@ -30,12 +30,42 @@
 
 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;
+    uint32_t tail;
+    uint32_t head;
+};
+
 typedef struct iommu_cap {
     uint32_t header;                    /* offset 00h */
     uint32_t base_low;                  /* offset 04h */
@@ -60,10 +90,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 Tue Jan 10 17:06:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1Rkf9m-0006Zc-0h; Tue, 10 Jan 2012 17:06:42 +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 1Rkf9j-0006XC-O8
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:06:40 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326215140!60252509!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 21525 invoked from network); 10 Jan 2012 17:05:42 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-2.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:05:42 -0000
Received: from mail152-tx2-R.bigfish.com (10.9.14.254) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:36 +0000
Received: from mail152-tx2 (localhost [127.0.0.1])	by
	mail152-tx2-R.bigfish.com (Postfix) with ESMTP id 677916A0478;
	Tue, 10 Jan 2012 17:06:36 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail152-tx2 (localhost.localdomain [127.0.0.1]) by mail152-tx2
	(MessageSwitch) id 1326215167306086_31834;
	Tue, 10 Jan 2012 17:06:07 +0000 (UTC)
Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.236])	by
	mail152-tx2.bigfish.com (Postfix) with ESMTP id 3AD1BC004A;
	Tue, 10 Jan 2012 17:06:07 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:06:03 +0000
X-WSS-ID: 0LXLE60-01-DTW-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 201EF1028129;	Tue, 10 Jan 2012 11:06:00 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 10 Jan 2012 11:06:10 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Tue, 10 Jan 2012 11:06:01 -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, 10 Jan 2012
	12:05:58 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EC26F49C65D; Tue, 10 Jan 2012
	17:05:56 +0000 (GMT)
Received: from gran.amd.com (gran.osrc.amd.com [165.204.15.57])	by
	mail.osrc.amd.com (Postfix) with ESMTP id D9509594882; Tue, 10 Jan 2012
	18:05:56 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9c9ddf2dd700119fdaf8a420fb051c22279853cc
Message-ID: <9c9ddf2dd700119fdaf8.1326215227@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 18:07:07 +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 14 V3] 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 1326213576 -3600
# Node ID 9c9ddf2dd700119fdaf8a420fb051c22279853cc
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
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 5b2676ac1321 -r 9c9ddf2dd700 xen/drivers/passthrough/amd/iommu_cmd.c
--- a/xen/drivers/passthrough/amd/iommu_cmd.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c	Tue Jan 10 17:39:36 2012 +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 5b2676ac1321 -r 9c9ddf2dd700 xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 10 17:39:36 2012 +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,82 @@ 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->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 +719,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 +730,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 +841,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 5b2676ac1321 -r 9c9ddf2dd700 xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Tue Jan 10 17:39:36 2012 +0100
@@ -30,12 +30,42 @@
 
 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;
+    uint32_t tail;
+    uint32_t head;
+};
+
 typedef struct iommu_cap {
     uint32_t header;                    /* offset 00h */
     uint32_t base_low;                  /* offset 04h */
@@ -60,10 +90,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 Tue Jan 10 17:12:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfF7-00008O-2H; Tue, 10 Jan 2012 17:12: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 1RkfF4-000078-Hl
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:12:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326215481!49672473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26887 invoked from network); 10 Jan 2012 17:11:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:11:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:12:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 17:12: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
	1RkfF0-00021f-5J; Tue, 10 Jan 2012 17:12:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfF0-0005W2-4L;
	Tue, 10 Jan 2012 17:12:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29029.997206.496297@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:12:05 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <20227.9862.11432.52937@mariner.uk.xensource.com>,
	<39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
	<patchbomb.1324639749@gran.amd.com>
	<8ea73cd1a367b318f720.1324639764@gran.amd.com>
	<20227.9862.11432.52937@mariner.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>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest
	config file parameter [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

Wei Wang writes ("[PATCH 14 of 14 V3] libxl: Introduce a new guest config file parameter"):
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1326213623 -3600
> # Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
> # Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
> libxl: Introduce a new guest config file parameter
> Use iommu = {1,0} to enable or disable guest iommu emulation.
> Default value is 0.

Ian Jackson writes ("Re: [PATCH 15 of 16] libxl: Introduce a new guest config file parameter"):
> Wei Wang writes ("[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.
> 
> I'm not sure I like this name.  It's confusing because it's not at
> first glance clear whether it refers to the host's putative iommu, or
> some kind of provision to the guest.
> 
> And it needs documentation, which I hope will answer my other question
> which is "what is this good for?" :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:12:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:12:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfF7-00008O-2H; Tue, 10 Jan 2012 17:12: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 1RkfF4-000078-Hl
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:12:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326215481!49672473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26887 invoked from network); 10 Jan 2012 17:11:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:11:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:12:06 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 17:12: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
	1RkfF0-00021f-5J; Tue, 10 Jan 2012 17:12:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfF0-0005W2-4L;
	Tue, 10 Jan 2012 17:12:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29029.997206.496297@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:12:05 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <20227.9862.11432.52937@mariner.uk.xensource.com>,
	<39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
	<patchbomb.1324639749@gran.amd.com>
	<8ea73cd1a367b318f720.1324639764@gran.amd.com>
	<20227.9862.11432.52937@mariner.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>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest
	config file parameter [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

Wei Wang writes ("[PATCH 14 of 14 V3] libxl: Introduce a new guest config file parameter"):
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1326213623 -3600
> # Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
> # Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
> libxl: Introduce a new guest config file parameter
> Use iommu = {1,0} to enable or disable guest iommu emulation.
> Default value is 0.

Ian Jackson writes ("Re: [PATCH 15 of 16] libxl: Introduce a new guest config file parameter"):
> Wei Wang writes ("[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.
> 
> I'm not sure I like this name.  It's confusing because it's not at
> first glance clear whether it refers to the host's putative iommu, or
> some kind of provision to the guest.
> 
> And it needs documentation, which I hope will answer my other question
> which is "what is this good for?" :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfGU-0000KA-IF; Tue, 10 Jan 2012 17:13: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 1RkfGS-0000Ju-H5
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:13:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326215565!51972546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5563 invoked from network); 10 Jan 2012 17:12:46 -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;
	10 Jan 2012 17:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:13:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 17:13:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkfGR-00022A-8c; Tue, 10 Jan 2012 17:13:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfGR-0005WK-7V;
	Tue, 10 Jan 2012 17:13:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29119.219429.36496@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:13:35 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <9e89b6485b6c91a8d563.1326215239@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<9e89b6485b6c91a8d563.1326215239@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 13 of 14 V3] 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

Wei Wang writes ("[PATCH 13 of 14 V3] libxl: bind virtual bdf to physical bdf after device assignment"):
> libxl: bind virtual bdf to physical bdf after device assignment

I confess I don't understand at all why this is needed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfGU-0000KA-IF; Tue, 10 Jan 2012 17:13: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 1RkfGS-0000Ju-H5
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:13:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326215565!51972546!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5563 invoked from network); 10 Jan 2012 17:12:46 -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;
	10 Jan 2012 17:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930373"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:13:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 10 Jan 2012 17:13:35 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkfGR-00022A-8c; Tue, 10 Jan 2012 17:13:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfGR-0005WK-7V;
	Tue, 10 Jan 2012 17:13:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29119.219429.36496@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:13:35 +0000
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <9e89b6485b6c91a8d563.1326215239@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<9e89b6485b6c91a8d563.1326215239@gran.amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 13 of 14 V3] 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

Wei Wang writes ("[PATCH 13 of 14 V3] libxl: bind virtual bdf to physical bdf after device assignment"):
> libxl: bind virtual bdf to physical bdf after device assignment

I confess I don't understand at all why this is needed.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:14:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1RkfHC-0000P8-B4; Tue, 10 Jan 2012 17:14:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RkfHA-0000On-7S
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:14:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326215619!59659168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8117 invoked from network); 10 Jan 2012 17:13:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:14: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, 10 Jan 2012 17:14: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
	1RkfH8-00022P-N9; Tue, 10 Jan 2012 17:14:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfH8-0005WS-MW;
	Tue, 10 Jan 2012 17:14:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29162.682797.328342@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:14:18 +0000
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120109163557.GH12984@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>
	<20111214090338.GS12984@reaktio.net>
	<alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
	<20120109163557.GH12984@reaktio.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	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

Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] [PATCH 0 of 6] pygrub fixes to=
 support a Fedora 16	guest"):
> They're already in xen-unstable, and they should be backported to xen-4.1=
-testing.
> =

> http://xenbits.xen.org/hg/xen-unstable.hg/rev/85d7b207fabc
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/138f707fa598
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/65679fee0177
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/152049468175
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/979bc34d0ad0
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/c681dd5aecf3
> =

> In the case they don't apply as-is to xen-4.1-testing =

> Fedora 16 xen-4.1.2-2.fc16.src.rpm already contains those patches backpor=
ted to 4.1.2.

Thanks, it was trivial to fix up the one conflict myself.  I have
backported them all.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:14:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1RkfHC-0000P8-B4; Tue, 10 Jan 2012 17:14:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RkfHA-0000On-7S
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:14:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326215619!59659168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8117 invoked from network); 10 Jan 2012 17:13:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:13:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:14: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, 10 Jan 2012 17:14: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
	1RkfH8-00022P-N9; Tue, 10 Jan 2012 17:14:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfH8-0005WS-MW;
	Tue, 10 Jan 2012 17:14:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29162.682797.328342@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:14:18 +0000
To: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20120109163557.GH12984@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>
	<20111214090338.GS12984@reaktio.net>
	<alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
	<20120109163557.GH12984@reaktio.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	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

Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] [PATCH 0 of 6] pygrub fixes to=
 support a Fedora 16	guest"):
> They're already in xen-unstable, and they should be backported to xen-4.1=
-testing.
> =

> http://xenbits.xen.org/hg/xen-unstable.hg/rev/85d7b207fabc
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/138f707fa598
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/65679fee0177
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/152049468175
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/979bc34d0ad0
> http://xenbits.xen.org/hg/xen-unstable.hg/rev/c681dd5aecf3
> =

> In the case they don't apply as-is to xen-4.1-testing =

> Fedora 16 xen-4.1.2-2.fc16.src.rpm already contains those patches backpor=
ted to 4.1.2.

Thanks, it was trivial to fix up the one conflict myself.  I have
backported them all.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:15:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfIF-0000YW-2r; Tue, 10 Jan 2012 17:15: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 1RkfIC-0000Xh-Ks
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:15:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326215716!9812728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5531 invoked from network); 10 Jan 2012 17:15:17 -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;
	10 Jan 2012 17:15:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:15: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, 10 Jan 2012 17:15:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkfI3-00022m-FQ; Tue, 10 Jan 2012 17:15:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfI3-0005Wb-EY;
	Tue, 10 Jan 2012 17:15:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29219.337512.677431@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:15:15 +0000
To: <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326132001-21251-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-4-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, Tim.Deegan@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 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

stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v4 04/25] xen: implement an signed 64 bit division helper function"):
> 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.

Are we sure having callers of this function is desirable ?  I was
under the impression that this is very slow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:15:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfIF-0000YW-2r; Tue, 10 Jan 2012 17:15: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 1RkfIC-0000Xh-Ks
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:15:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326215716!9812728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5531 invoked from network); 10 Jan 2012 17:15:17 -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;
	10 Jan 2012 17:15:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930430"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:15: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, 10 Jan 2012 17:15:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkfI3-00022m-FQ; Tue, 10 Jan 2012 17:15:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfI3-0005Wb-EY;
	Tue, 10 Jan 2012 17:15:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29219.337512.677431@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:15:15 +0000
To: <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326132001-21251-4-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201091752280.3150@kaball-desktop>
	<1326132001-21251-4-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, Tim.Deegan@citrix.com, JBeulich@suse.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v4 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

stefano.stabellini@eu.citrix.com writes ("[Xen-devel] [PATCH v4 04/25] xen: implement an signed 64 bit division helper function"):
> 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.

Are we sure having callers of this function is desirable ?  I was
under the impression that this is very slow.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:25:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfRo-0000tw-SP; Tue, 10 Jan 2012 17:25:20 +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 1RkfRm-0000to-HN
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:25:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326216311!10353510!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22843 invoked from network); 10 Jan 2012 17:25:12 -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;
	10 Jan 2012 17:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:25: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, 10 Jan 2012 17:25: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
	1RkfRf-00026M-BI; Tue, 10 Jan 2012 17:25:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfRf-0005XC-AT;
	Tue, 10 Jan 2012 17:25:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29815.157736.36187@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:25:11 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F0C48E2020000780006B91F@nat28.tlf.novell.com>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.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,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace custom checks in tools/check"):
> I think Ian had asked this already, but I also think that I didn't see
> an answer: Is this relatively new version really a requirement. Not
> even SLE11 SP2, which hasn't shipped yet, has this new an
> autoconf package. And I would hope to continue to be able to
> build on SLE10 SP4, which only has 2.59, without having to
> manually build newer packages...

Indeed.  There are two parts to the answer:
  * Firstly, an older autoconf should do fine.  I think we should aim
    to be compatible with autoconf 2.59 certainly.
  * Secondly, autoconf should not be added to the build dependencies.
    Instead, we should check in the autoconf-generated files.

> > +    # ./autogen.sh
> > +
> > +   Before executing ./configure (this step can be ommited when
> > +   building from a distribution package).
> > +
> > +    # ./configure
> 
> Can these two steps be automated (i.e. the need to run either
> be determined by the absence of some file(s), and them being
> invoked from the top level Makefile)?

Automating this turns out to be very annoying.  If the autoconfery is
checked in then running autogen.sh is not necessary.

The usual approach is then to simply
  ./configure
  make
  make install

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:25:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfRo-0000tw-SP; Tue, 10 Jan 2012 17:25:20 +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 1RkfRm-0000to-HN
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:25:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326216311!10353510!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22843 invoked from network); 10 Jan 2012 17:25:12 -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;
	10 Jan 2012 17:25:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:25: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, 10 Jan 2012 17:25: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
	1RkfRf-00026M-BI; Tue, 10 Jan 2012 17:25:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfRf-0005XC-AT;
	Tue, 10 Jan 2012 17:25:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29815.157736.36187@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:25:11 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F0C48E2020000780006B91F@nat28.tlf.novell.com>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.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,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace custom checks in tools/check"):
> I think Ian had asked this already, but I also think that I didn't see
> an answer: Is this relatively new version really a requirement. Not
> even SLE11 SP2, which hasn't shipped yet, has this new an
> autoconf package. And I would hope to continue to be able to
> build on SLE10 SP4, which only has 2.59, without having to
> manually build newer packages...

Indeed.  There are two parts to the answer:
  * Firstly, an older autoconf should do fine.  I think we should aim
    to be compatible with autoconf 2.59 certainly.
  * Secondly, autoconf should not be added to the build dependencies.
    Instead, we should check in the autoconf-generated files.

> > +    # ./autogen.sh
> > +
> > +   Before executing ./configure (this step can be ommited when
> > +   building from a distribution package).
> > +
> > +    # ./configure
> 
> Can these two steps be automated (i.e. the need to run either
> be determined by the absence of some file(s), and them being
> invoked from the top level Makefile)?

Automating this turns out to be very annoying.  If the autoconfery is
checked in then running autogen.sh is not necessary.

The usual approach is then to simply
  ./configure
  make
  make install

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:27:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:27:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfUD-00012W-Ps; Tue, 10 Jan 2012 17:27:49 +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 1RkfUB-000126-Rk
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:27:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326216461!8060390!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3369 invoked from network); 10 Jan 2012 17:27:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:27:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:27: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, 10 Jan 2012 17:27: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
	1RkfU5-00027K-5J; Tue, 10 Jan 2012 17:27:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfU5-0005Xs-4f;
	Tue, 10 Jan 2012 17:27:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29965.66901.677309@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:27:41 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F0C6467020000780006B98D@nat28.tlf.novell.com>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.com>
	<CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@mail.gmail.com>
	<4F0C6467020000780006B98D@nat28.tlf.novell.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, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace custom checks in tools/check"):
> Let's see what other want; my thinking is that if one didn't care to
> run ./configure manually, default settings are intended. That's
> what an invocation without arguments should result in, without
> any user interaction.

I don't think running configure automatically is at all desirable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:27:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:27:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfUD-00012W-Ps; Tue, 10 Jan 2012 17:27:49 +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 1RkfUB-000126-Rk
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:27:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326216461!8060390!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3369 invoked from network); 10 Jan 2012 17:27:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:27:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930661"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:27: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, 10 Jan 2012 17:27: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
	1RkfU5-00027K-5J; Tue, 10 Jan 2012 17:27:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfU5-0005Xs-4f;
	Tue, 10 Jan 2012 17:27:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.29965.66901.677309@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:27:41 +0000
To: Jan Beulich <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F0C6467020000780006B98D@nat28.tlf.novell.com>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.com>
	<CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@mail.gmail.com>
	<4F0C6467020000780006B98D@nat28.tlf.novell.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, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace custom checks in tools/check"):
> Let's see what other want; my thinking is that if one didn't care to
> run ./configure manually, default settings are intended. That's
> what an invocation without arguments should result in, without
> any user interaction.

I don't think running configure automatically is at all desirable.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:29:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfVz-0001BC-I7; Tue, 10 Jan 2012 17:29:39 +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 1RkfVx-0001Af-1v
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:29:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326216571!7234996!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29778 invoked from network); 10 Jan 2012 17:29:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:29:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:29: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, 10 Jan 2012 17:29:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkfVq-00027w-QU; Tue, 10 Jan 2012 17:29:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfVq-0005Y8-Po;
	Tue, 10 Jan 2012 17:29:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.30074.784658.148457@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:29:30 +0000
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326210860-20321-1-git-send-email-david.vrabel@citrix.com>
References: <1326210860-20321-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
	the	hypervisor 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

David Vrabel writes ("[Xen-devel] [PATCH] Add .gitignore files for files generated by the hypervisor build"):
> More or fewer .gitignore files could be used.  Let me know which is
> preferred.

I have a branch containing a complete .gitignore for the whole tree.

I would have absolutely no objection to submitting it.  Would anyone
object to it going into tree ?

Obviously we will still expect patches to come with any necessary
.hgignore updates and not necessarily updates to .gitignore.  I would
be happy to be maintainer for the .gitignore (since I'm doing that
work anyway...)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:29:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:29:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfVz-0001BC-I7; Tue, 10 Jan 2012 17:29:39 +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 1RkfVx-0001Af-1v
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:29:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326216571!7234996!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDI0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29778 invoked from network); 10 Jan 2012 17:29:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 17:29:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,488,1320624000"; 
   d="scan'208";a="9930707"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	10 Jan 2012 17:29: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, 10 Jan 2012 17:29:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RkfVq-00027w-QU; Tue, 10 Jan 2012 17:29:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RkfVq-0005Y8-Po;
	Tue, 10 Jan 2012 17:29:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20236.30074.784658.148457@mariner.uk.xensource.com>
Date: Tue, 10 Jan 2012 17:29:30 +0000
To: David Vrabel <david.vrabel@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326210860-20321-1-git-send-email-david.vrabel@citrix.com>
References: <1326210860-20321-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
	the	hypervisor 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

David Vrabel writes ("[Xen-devel] [PATCH] Add .gitignore files for files generated by the hypervisor build"):
> More or fewer .gitignore files could be used.  Let me know which is
> preferred.

I have a branch containing a complete .gitignore for the whole tree.

I would have absolutely no objection to submitting it.  Would anyone
object to it going into tree ?

Obviously we will still expect patches to come with any necessary
.hgignore updates and not necessarily updates to .gitignore.  I would
be happy to be maintainer for the .gitignore (since I'm doing that
work anyway...)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:33:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1RkfZa-0001RO-JN; Tue, 10 Jan 2012 17:33: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 1RkfZY-0001RA-8I
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:33:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326216793!8566058!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 14522 invoked from network); 10 Jan 2012 17:33:14 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:33:14 -0000
Received: from mail112-am1-R.bigfish.com (10.3.201.244) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:33:13 +0000
Received: from mail112-am1 (localhost [127.0.0.1])	by
	mail112-am1-R.bigfish.com (Postfix) with ESMTP id CF9BD24026F;
	Tue, 10 Jan 2012 17:33:13 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzzz2dhc1ahc1bh668h839h)
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 mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1
	(MessageSwitch) id 1326216793736750_26485;
	Tue, 10 Jan 2012 17:33:13 +0000 (UTC)
Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.243])	by
	mail112-am1.bigfish.com (Postfix) with ESMTP id AFE0B2C0046;
	Tue, 10 Jan 2012 17:33:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:33:11 +0000
X-WSS-ID: 0LXLFF8-01-16Z-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 2273F1028125;	Tue, 10 Jan 2012 11:33:07 -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, 10 Jan 2012 11:33:17 -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, 10 Jan 2012 11:33:08 -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, 10 Jan 2012
	12:32: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 E3E2649C58B; Tue, 10 Jan 2012
	17:32: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 CCFAC5940FF; Tue, 10 Jan 2012
	18:32:43 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 10 Jan 2012 18:35:14 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1326215226@gran.amd.com>
	<9e89b6485b6c91a8d563.1326215239@gran.amd.com>
	<20236.29119.219429.36496@mariner.uk.xensource.com>
In-Reply-To: <20236.29119.219429.36496@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201101835.15686.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>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 13 of 14 V3] 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 Tuesday 10 January 2012 18:13:35 Ian Jackson wrote:
> Wei Wang writes ("[PATCH 13 of 14 V3] libxl: bind virtual bdf to physical 
bdf after device assignment"):
> > libxl: bind virtual bdf to physical bdf after device assignment
>
> I confess I don't understand at all why this is needed.
>
> Ian.

Oh, the idea of this hypercall is used to allow hypervisor to trace the 
virtual bdf of a physical bdf.  IOMMU emulator reads iommu ppr log from host 
buffer and dispatch them into guest log buffer. In the host log entry, 
physical bdf is written by iommu and needs to be changed to virtual bdf when 
write back to a guest. It might also be done if we could extend the interface 
of xc_assign_device?

Thanks,
Wei




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:33:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17: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 1RkfZa-0001RO-JN; Tue, 10 Jan 2012 17:33: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 1RkfZY-0001RA-8I
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:33:20 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326216793!8566058!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 14522 invoked from network); 10 Jan 2012 17:33:14 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	10 Jan 2012 17:33:14 -0000
Received: from mail112-am1-R.bigfish.com (10.3.201.244) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:33:13 +0000
Received: from mail112-am1 (localhost [127.0.0.1])	by
	mail112-am1-R.bigfish.com (Postfix) with ESMTP id CF9BD24026F;
	Tue, 10 Jan 2012 17:33:13 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzzz2dhc1ahc1bh668h839h)
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 mail112-am1 (localhost.localdomain [127.0.0.1]) by mail112-am1
	(MessageSwitch) id 1326216793736750_26485;
	Tue, 10 Jan 2012 17:33:13 +0000 (UTC)
Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.243])	by
	mail112-am1.bigfish.com (Postfix) with ESMTP id AFE0B2C0046;
	Tue, 10 Jan 2012 17:33:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server id
	14.1.225.23; Tue, 10 Jan 2012 17:33:11 +0000
X-WSS-ID: 0LXLFF8-01-16Z-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 2273F1028125;	Tue, 10 Jan 2012 11:33:07 -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, 10 Jan 2012 11:33:17 -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, 10 Jan 2012 11:33:08 -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, 10 Jan 2012
	12:32: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 E3E2649C58B; Tue, 10 Jan 2012
	17:32: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 CCFAC5940FF; Tue, 10 Jan 2012
	18:32:43 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 10 Jan 2012 18:35:14 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1326215226@gran.amd.com>
	<9e89b6485b6c91a8d563.1326215239@gran.amd.com>
	<20236.29119.219429.36496@mariner.uk.xensource.com>
In-Reply-To: <20236.29119.219429.36496@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201101835.15686.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>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 13 of 14 V3] 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 Tuesday 10 January 2012 18:13:35 Ian Jackson wrote:
> Wei Wang writes ("[PATCH 13 of 14 V3] libxl: bind virtual bdf to physical 
bdf after device assignment"):
> > libxl: bind virtual bdf to physical bdf after device assignment
>
> I confess I don't understand at all why this is needed.
>
> Ian.

Oh, the idea of this hypercall is used to allow hypervisor to trace the 
virtual bdf of a physical bdf.  IOMMU emulator reads iommu ppr log from host 
buffer and dispatch them into guest log buffer. In the host log entry, 
physical bdf is written by iommu and needs to be changed to virtual bdf when 
write back to a guest. It might also be done if we could extend the interface 
of xc_assign_device?

Thanks,
Wei




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 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 1Rkfcx-0001de-3A; Tue, 10 Jan 2012 17:36:51 +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 1Rkfcv-0001d7-Bo
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:36:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326216982!52263926!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 21343 invoked from network); 10 Jan 2012 17:36:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Jan 2012 17:36:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 17:36:42 +0000
Message-Id: <4F0C8571020000780006BAF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 17:37:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.com>
	<CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@mail.gmail.com>
	<4F0C6467020000780006B98D@nat28.tlf.novell.com>
	<20236.29965.66901.677309@mariner.uk.xensource.com>
In-Reply-To: <20236.29965.66901.677309@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: =?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@entel.upc.edu>,
	xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 10.01.12 at 18:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to 
> replace custom checks in tools/check"):
>> Let's see what other want; my thinking is that if one didn't care to
>> run ./configure manually, default settings are intended. That's
>> what an invocation without arguments should result in, without
>> any user interaction.
> 
> I don't think running configure automatically is at all desirable.

I can certainly put the invocation of it into the script I'm using to
build fresh trees, but I'm still curious why you think this is such
a bad idea. The usual situation - needing a Makefile to be
generated to have something to run make on - isn't the case here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 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 1Rkfcx-0001de-3A; Tue, 10 Jan 2012 17:36:51 +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 1Rkfcv-0001d7-Bo
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:36:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326216982!52263926!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 21343 invoked from network); 10 Jan 2012 17:36:22 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 10 Jan 2012 17:36:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 10 Jan 2012 17:36:42 +0000
Message-Id: <4F0C8571020000780006BAF5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 10 Jan 2012 17:37:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
References: <7d90cbdca2c26ba817f1.1326141427@build.localdomain>
	<4F0C48E2020000780006B91F@nat28.tlf.novell.com>
	<CAPLaKK4FDOW-7K1aXBGcZ18g_-oUO3z=s+8zgXtB26MtXYGVDg@mail.gmail.com>
	<4F0C6467020000780006B98D@nat28.tlf.novell.com>
	<20236.29965.66901.677309@mariner.uk.xensource.com>
In-Reply-To: <20236.29965.66901.677309@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: =?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?= <roger.pau@entel.upc.edu>,
	xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace
 custom checks in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 10.01.12 at 18:27, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to 
> replace custom checks in tools/check"):
>> Let's see what other want; my thinking is that if one didn't care to
>> run ./configure manually, default settings are intended. That's
>> what an invocation without arguments should result in, without
>> any user interaction.
> 
> I don't think running configure automatically is at all desirable.

I can certainly put the invocation of it into the script I'm using to
build fresh trees, but I'm still curious why you think this is such
a bad idea. The usual situation - needing a Makefile to be
generated to have something to run make on - isn't the case here.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:40:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfgB-0001ot-0n; Tue, 10 Jan 2012 17:40: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 1Rkfg8-0001oT-A2
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:40:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326217202!10458017!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDczMzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDczMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24404 invoked from network); 10 Jan 2012 17:40:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Jan 2012 17:40:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326217201; l=774;
	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=eNL+0GnKUJsPFIvlQXtRraEGBKw=;
	b=qBipgeLMXi/Vis8W2jyHExgdy512Eeozk9Q/aKRIk55erbFct9Ci0NF2FNjzAFzpYJi
	kajG8FYd35o8JWjJWpXh9uLGjO3TYywGM8TBxssoIds+27C3BLMxuRb8Wx/kY/xkoWHCO
	94mODYrhMKFUZVhduwY9rvwDw46IqUUOPvk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJiS0PEjgX
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-077-119.pools.arcor-ip.net [88.65.77.119])
	by smtp.strato.de (klopstock mo27) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id k06fedo0AGQqHa ;
	Tue, 10 Jan 2012 18:39:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 63A9B18637; Tue, 10 Jan 2012 18:39:57 +0100 (CET)
Date: Tue, 10 Jan 2012 18:39:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120110173956.GA2213@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
	<001301cccc1b$d7ca1470$875e3d50$@com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <001301cccc1b$d7ca1470$875e3d50$@com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "'bicky.'" <bicky.shi@huawei.com>, xen-devel@lists.xensource.com,
	'Ian Jackson' <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, Hongkaixing wrote:

> > Why wrap this up in a struct ?
> 
> We want to keep the same style with
> 
> typedef struct xenpaging_victim {
>     /* the gfn of the page to evict */
>     unsigned long gfn;
> } xenpaging_victim_t;

This dates back to the initial implementation of xenpaging.

In my testing I started a guest paused, paged it all out, and paged all
back into memory. By monitoring nr_pages I noticed that page-in got
slightly slower over time, so your suggestion to use two indexes will
speed things up a bit.


Looking through xenpaging.c, I think its best to have two flat arrays:
unsigned long slot_to_gfn[paging->max_pages]; /* was victims */
int gfn_to_slot[paging->max_pages];

I will prepare a patch to implement this.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 17:40:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 17:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkfgB-0001ot-0n; Tue, 10 Jan 2012 17:40: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 1Rkfg8-0001oT-A2
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 17:40:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326217202!10458017!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDczMzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDczMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24404 invoked from network); 10 Jan 2012 17:40:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 10 Jan 2012 17:40:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326217201; l=774;
	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=eNL+0GnKUJsPFIvlQXtRraEGBKw=;
	b=qBipgeLMXi/Vis8W2jyHExgdy512Eeozk9Q/aKRIk55erbFct9Ci0NF2FNjzAFzpYJi
	kajG8FYd35o8JWjJWpXh9uLGjO3TYywGM8TBxssoIds+27C3BLMxuRb8Wx/kY/xkoWHCO
	94mODYrhMKFUZVhduwY9rvwDw46IqUUOPvk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJiS0PEjgX
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-077-119.pools.arcor-ip.net [88.65.77.119])
	by smtp.strato.de (klopstock mo27) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id k06fedo0AGQqHa ;
	Tue, 10 Jan 2012 18:39:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 63A9B18637; Tue, 10 Jan 2012 18:39:57 +0100 (CET)
Date: Tue, 10 Jan 2012 18:39:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120110173956.GA2213@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
	<001301cccc1b$d7ca1470$875e3d50$@com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <001301cccc1b$d7ca1470$875e3d50$@com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "'bicky.'" <bicky.shi@huawei.com>, xen-devel@lists.xensource.com,
	'Ian Jackson' <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, Hongkaixing wrote:

> > Why wrap this up in a struct ?
> 
> We want to keep the same style with
> 
> typedef struct xenpaging_victim {
>     /* the gfn of the page to evict */
>     unsigned long gfn;
> } xenpaging_victim_t;

This dates back to the initial implementation of xenpaging.

In my testing I started a guest paused, paged it all out, and paged all
back into memory. By monitoring nr_pages I noticed that page-in got
slightly slower over time, so your suggestion to use two indexes will
speed things up a bit.


Looking through xenpaging.c, I think its best to have two flat arrays:
unsigned long slot_to_gfn[paging->max_pages]; /* was victims */
int gfn_to_slot[paging->max_pages];

I will prepare a patch to implement this.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 18:37:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 18: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 1RkgZ2-0002MT-C2; Tue, 10 Jan 2012 18:36:52 +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 1RkgZ1-0002ML-0i
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 18:36:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326220604!10413183!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26019 invoked from network); 10 Jan 2012 18:36:44 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 18:36:44 -0000
Received: by werg1 with SMTP id g1so10662372wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 10:36:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+mBVbGse71+mcWGFPbuyQRZFloG9Y8Vckw/5QldG5lU=;
	b=Oc9isAFvJaUcVFtmiS9diQc1ZuvdyEINAh05VQncs7HuKP7YaWvwv6ky+qnHj9D3JF
	z5f/fdp7R4E52QDdnN01XsxFMkMC9TDKJy7jBAOm1Ti4pOzLh+rztrdTbYzz0a+r4vtR
	kHBkc6pAYVwe814ZGHvgtbT696Ngx4M8sMIEY=
Received: by 10.216.132.98 with SMTP id n76mr10180120wei.36.1326220604168;
	Tue, 10 Jan 2012 10:36:44 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fg15sm84433099wbb.7.2012.01.10.10.36.42
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 10:36:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Jan 2012 18:36:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CB3235B4.287E2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Add .gitignore files for files generated by
	the hypervisor build
Thread-Index: AczPxshtcPb+ousw6E2Gowu1YCqR+A==
In-Reply-To: <20236.30074.784658.148457@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
 the hypervisor 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

On 10/01/2012 17:29, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> David Vrabel writes ("[Xen-devel] [PATCH] Add .gitignore files for files
> generated by the hypervisor build"):
>> More or fewer .gitignore files could be used.  Let me know which is
>> preferred.
> 
> I have a branch containing a complete .gitignore for the whole tree.
> 
> I would have absolutely no objection to submitting it.  Would anyone
> object to it going into tree ?

I'm sure we've done both .hgignore/.gitignore in some repositories in the
past. It sounds fine to me.

 -- Keir

> Obviously we will still expect patches to come with any necessary
> .hgignore updates and not necessarily updates to .gitignore.  I would
> be happy to be maintainer for the .gitignore (since I'm doing that
> work anyway...)
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 18:37:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 18: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 1RkgZ2-0002MT-C2; Tue, 10 Jan 2012 18:36:52 +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 1RkgZ1-0002ML-0i
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 18:36:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326220604!10413183!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26019 invoked from network); 10 Jan 2012 18:36:44 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 18:36:44 -0000
Received: by werg1 with SMTP id g1so10662372wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 10:36:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=+mBVbGse71+mcWGFPbuyQRZFloG9Y8Vckw/5QldG5lU=;
	b=Oc9isAFvJaUcVFtmiS9diQc1ZuvdyEINAh05VQncs7HuKP7YaWvwv6ky+qnHj9D3JF
	z5f/fdp7R4E52QDdnN01XsxFMkMC9TDKJy7jBAOm1Ti4pOzLh+rztrdTbYzz0a+r4vtR
	kHBkc6pAYVwe814ZGHvgtbT696Ngx4M8sMIEY=
Received: by 10.216.132.98 with SMTP id n76mr10180120wei.36.1326220604168;
	Tue, 10 Jan 2012 10:36:44 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fg15sm84433099wbb.7.2012.01.10.10.36.42
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 10:36:43 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Jan 2012 18:36:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Message-ID: <CB3235B4.287E2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Add .gitignore files for files generated by
	the hypervisor build
Thread-Index: AczPxshtcPb+ousw6E2Gowu1YCqR+A==
In-Reply-To: <20236.30074.784658.148457@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
 the hypervisor 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

On 10/01/2012 17:29, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> David Vrabel writes ("[Xen-devel] [PATCH] Add .gitignore files for files
> generated by the hypervisor build"):
>> More or fewer .gitignore files could be used.  Let me know which is
>> preferred.
> 
> I have a branch containing a complete .gitignore for the whole tree.
> 
> I would have absolutely no objection to submitting it.  Would anyone
> object to it going into tree ?

I'm sure we've done both .hgignore/.gitignore in some repositories in the
past. It sounds fine to me.

 -- Keir

> Obviously we will still expect patches to come with any necessary
> .hgignore updates and not necessarily updates to .gitignore.  I would
> be happy to be maintainer for the .gitignore (since I'm doing that
> work anyway...)
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 20:09:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 20: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 1Rki0U-0002mj-FX; Tue, 10 Jan 2012 20:09:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <joseph.cihula@intel.com>) id 1Rki0S-0002me-TR
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 20:09:17 +0000
X-Env-Sender: joseph.cihula@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326226149!8076652!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwNTEyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13094 invoked from network); 10 Jan 2012 20:09:09 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	10 Jan 2012 20:09:09 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 10 Jan 2012 12:09:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110805483"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by fmsmga002.fm.intel.com with ESMTP; 10 Jan 2012 12:09:08 -0800
Received: from orsmsx104.amr.corp.intel.com (10.22.225.131) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 10 Jan 2012 12:09:07 -0800
Received: from orsmsx101.amr.corp.intel.com ([169.254.8.57]) by
	ORSMSX104.amr.corp.intel.com ([169.254.3.219]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 12:09:07 -0800
From: "Cihula, Joseph" <joseph.cihula@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rjw@sisk.pl"
	<rjw@sisk.pl>, "x86@kernel.org" <x86@kernel.org>, "Brown, Len"
	<len.brown@intel.com>, "linux-pm@lists.linux-foundation.org"
	<linux-pm@lists.linux-foundation.org>, "tboot-devel@lists.sourceforge.net"
	<tboot-devel@lists.sourceforge.net>, "linux-acpi@vger.kernel.org"
	<linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>
Thread-Topic: [PATCH 1/7] x86, acpi, tboot: Have a ACPI os prepare sleep
	instead of calling tboot_sleep.
Thread-Index: AQHMyjtbdYuM2MdwO0GLk3xKcuZUZ5YEwS7g
Date: Tue, 10 Jan 2012 20:09:06 +0000
Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC2420CB97@ORSMSX101.amr.corp.intel.com>
References: <1324075099-11397-1-git-send-email-konrad.wilk@oracle.com>
	<1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
	<20120103171318.GA25341@phenom.dumpdata.com>
In-Reply-To: <20120103171318.GA25341@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Wang, Shane" <shane.wang@intel.com>, Thomas Gleixner <tglx@linutronix.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ACK

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Tuesday, January 03, 2012 9:13 AM
> To: linux-kernel@vger.kernel.org; rjw@sisk.pl; x86@kernel.org; Brown, Len; Cihula, Joseph; linux-
> pm@lists.linux-foundation.org; tboot-devel@lists.sourceforge.net; linux-acpi@vger.kernel.org;
> liang.tang@oracle.com
> Cc: hpa@zytor.com; Thomas Gleixner; Wang, Shane; xen-devel@lists.xensource.com
> Subject: Re: [PATCH 1/7] x86, acpi, tboot: Have a ACPI os prepare sleep instead of calling
> tboot_sleep.
> 
> On Fri, Dec 16, 2011 at 05:38:13PM -0500, Konrad Rzeszutek Wilk wrote:
> > From: Tang Liang <liang.tang@oracle.com>
> 
> Hey Joseph,
> 
> I remember you acked the initial rfc patches I had posted.
> But I was wondering if these ones are to your liking (I think they are - they aren't that much
> different, but I didn't want to blindly sticking 'Acked-by' as they did change a bit).
> 
> Thanks!
> >
> > 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 Tue Jan 10 20:09:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 20: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 1Rki0U-0002mj-FX; Tue, 10 Jan 2012 20:09:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <joseph.cihula@intel.com>) id 1Rki0S-0002me-TR
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 20:09:17 +0000
X-Env-Sender: joseph.cihula@intel.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326226149!8076652!1
X-Originating-IP: [192.55.52.93]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjkzID0+IDMwNTEyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13094 invoked from network); 10 Jan 2012 20:09:09 -0000
Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93)
	by server-8.tower-21.messagelabs.com with SMTP;
	10 Jan 2012 20:09:09 -0000
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
	by fmsmga102.fm.intel.com with ESMTP; 10 Jan 2012 12:09:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="110805483"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by fmsmga002.fm.intel.com with ESMTP; 10 Jan 2012 12:09:08 -0800
Received: from orsmsx104.amr.corp.intel.com (10.22.225.131) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 10 Jan 2012 12:09:07 -0800
Received: from orsmsx101.amr.corp.intel.com ([169.254.8.57]) by
	ORSMSX104.amr.corp.intel.com ([169.254.3.219]) with mapi id
	14.01.0355.002; Tue, 10 Jan 2012 12:09:07 -0800
From: "Cihula, Joseph" <joseph.cihula@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rjw@sisk.pl"
	<rjw@sisk.pl>, "x86@kernel.org" <x86@kernel.org>, "Brown, Len"
	<len.brown@intel.com>, "linux-pm@lists.linux-foundation.org"
	<linux-pm@lists.linux-foundation.org>, "tboot-devel@lists.sourceforge.net"
	<tboot-devel@lists.sourceforge.net>, "linux-acpi@vger.kernel.org"
	<linux-acpi@vger.kernel.org>,
	"liang.tang@oracle.com" <liang.tang@oracle.com>
Thread-Topic: [PATCH 1/7] x86, acpi, tboot: Have a ACPI os prepare sleep
	instead of calling tboot_sleep.
Thread-Index: AQHMyjtbdYuM2MdwO0GLk3xKcuZUZ5YEwS7g
Date: Tue, 10 Jan 2012 20:09:06 +0000
Message-ID: <9F57BF860713DF4BA3EFA4F8C6DFEDAC2420CB97@ORSMSX101.amr.corp.intel.com>
References: <1324075099-11397-1-git-send-email-konrad.wilk@oracle.com>
	<1324075099-11397-2-git-send-email-konrad.wilk@oracle.com>
	<20120103171318.GA25341@phenom.dumpdata.com>
In-Reply-To: <20120103171318.GA25341@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.138]
MIME-Version: 1.0
Cc: "Wang, Shane" <shane.wang@intel.com>, Thomas Gleixner <tglx@linutronix.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"hpa@zytor.com" <hpa@zytor.com>
Subject: Re: [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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

ACK

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Tuesday, January 03, 2012 9:13 AM
> To: linux-kernel@vger.kernel.org; rjw@sisk.pl; x86@kernel.org; Brown, Len; Cihula, Joseph; linux-
> pm@lists.linux-foundation.org; tboot-devel@lists.sourceforge.net; linux-acpi@vger.kernel.org;
> liang.tang@oracle.com
> Cc: hpa@zytor.com; Thomas Gleixner; Wang, Shane; xen-devel@lists.xensource.com
> Subject: Re: [PATCH 1/7] x86, acpi, tboot: Have a ACPI os prepare sleep instead of calling
> tboot_sleep.
> 
> On Fri, Dec 16, 2011 at 05:38:13PM -0500, Konrad Rzeszutek Wilk wrote:
> > From: Tang Liang <liang.tang@oracle.com>
> 
> Hey Joseph,
> 
> I remember you acked the initial rfc patches I had posted.
> But I was wondering if these ones are to your liking (I think they are - they aren't that much
> different, but I didn't want to blindly sticking 'Acked-by' as they did change a bit).
> 
> Thanks!
> >
> > 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 Tue Jan 10 20:31:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 20: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 1RkiL3-0003JN-Aa; Tue, 10 Jan 2012 20:30:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RkiL1-0003JG-JE
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 20:30:31 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326227422!10367449!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjY0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14963 invoked from network); 10 Jan 2012 20:30:24 -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 Jan 2012 20:30:24 -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
	q0AKULv7025752
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Tue, 10 Jan 2012 20:30:22 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
	q0AKUK89000643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Tue, 10 Jan 2012 20:30:21 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0AKUJQR017190
	for <xen-devel@lists.xensource.com>; Tue, 10 Jan 2012 14:30:20 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 12:30:19 -0800
MIME-Version: 1.0
X-Mercurial-Node: a78507899bea4824901d209d818b69545f607312
Message-Id: <a78507899bea4824901d.1326227419@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Tue, 10 Jan 2012 15:30:19 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel@lists.xensource.com
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F0C9FDE.00A4,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [PATCH] libxl: fix typo iff -> if
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1326227259 18000
# Node ID a78507899bea4824901d209d818b69545f607312
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
libxl: fix typo iff -> if

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r 03138a08366b -r a78507899bea tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 15:27:39 2012 -0500
@@ -106,7 +106,7 @@ libxl_dominfo = Struct("dominfo",[
     ("dying",       bool),
 
     ("shutdown_reason", uint8, False,
-"""Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
+"""Valid SHUTDOWN_* value from xen/sched.h if (shutdown||dying).
 
 Otherwise set to a value guaranteed not to clash with any valid
 SHUTDOWN_* constant."""),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 20:31:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 20: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 1RkiL3-0003JN-Aa; Tue, 10 Jan 2012 20:30:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RkiL1-0003JG-JE
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 20:30:31 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326227422!10367449!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjY0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14963 invoked from network); 10 Jan 2012 20:30:24 -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 Jan 2012 20:30:24 -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
	q0AKULv7025752
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Tue, 10 Jan 2012 20:30:22 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
	q0AKUK89000643
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Tue, 10 Jan 2012 20:30:21 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0AKUJQR017190
	for <xen-devel@lists.xensource.com>; Tue, 10 Jan 2012 14:30:20 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 12:30:19 -0800
MIME-Version: 1.0
X-Mercurial-Node: a78507899bea4824901d209d818b69545f607312
Message-Id: <a78507899bea4824901d.1326227419@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Tue, 10 Jan 2012 15:30:19 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel@lists.xensource.com
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F0C9FDE.00A4,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [PATCH] libxl: fix typo iff -> if
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1326227259 18000
# Node ID a78507899bea4824901d209d818b69545f607312
# Parent  03138a08366b895d79e143119d4c9c72833cdbcd
libxl: fix typo iff -> if

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r 03138a08366b -r a78507899bea tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Dec 09 16:19:36 2011 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 15:27:39 2012 -0500
@@ -106,7 +106,7 @@ libxl_dominfo = Struct("dominfo",[
     ("dying",       bool),
 
     ("shutdown_reason", uint8, False,
-"""Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
+"""Valid SHUTDOWN_* value from xen/sched.h if (shutdown||dying).
 
 Otherwise set to a value guaranteed not to clash with any valid
 SHUTDOWN_* constant."""),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 20:31:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 20:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkiLE-0003Jv-3N; Tue, 10 Jan 2012 20:30:44 +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 1RkiLB-0003JX-NR
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 20:30:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326227433!10458068!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4MjgzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21574 invoked from network); 10 Jan 2012 20:30:34 -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; 10 Jan 2012 20:30:34 -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
	q0AKUSD1012010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Jan 2012 20:30:29 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
	q0AKUQGD003001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2012 20:30:27 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0AKUQ05021678; Tue, 10 Jan 2012 14:30:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 12:30:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A9110402F5; Tue, 10 Jan 2012 15:28:38 -0500 (EST)
Date: Tue, 10 Jan 2012 15:28:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: tj@kernel.org, linux-kernel@vger.kernel.org, rjw@sisk.pl
Message-ID: <20120110202838.GA10402@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F0C9FE6.0090,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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,

With that patch I get this when trying to launch a 4GB xen guest:

kernel="/mnt/lab/latest/vmlinuz"
ramdisk="/mnt/lab/latest/initramfs.cpio.gz"
extra="console=hvc0 debug earlyprintk=xen" 
memory=4096
maxmem=8192
vcpus=4
on_crash="preserve"
vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'

If I change the "memory" to be "4000" it or if I revert the
mention git commit it boots. This is what I get with the mentioned
git commit:

(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-04371-g6b3da11 (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #2 SMP PREEMPT Tue Jan 10 12:47:50 EST 2012
(early) [    0.000000] Command line: console=hvc0 debug earlyprintk=xen
(early) [    0.000000] Disabled fast string operations
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Released 0 pages of unused memory
(early) [    0.000000] Set 0 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 - 0000000200800000 (usable)
(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] e820 update range: 0000000000000000 - 0000000000010000 (early) (usable)(early)  ==> (early) (reserved)(early) 
(early) [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (early) (usable)(early) 
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x200800 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
(early) [    0.000000] initial memory mapped : 0 - 0fbec000
(early) [    0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480
(early) [    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
(early) [    0.000000]  0000000000 - 0100000000 page 4k
(early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
(early) [    0.000000] Pid: 0, comm: swapper Not tainted 3.2.0-04371-g6b3da11 #2
(early) [    0.000000] Call Trace:
(early) [    0.000000]  [<ffffffff8163f230>] panic+0x9b/0x1c9
(early) [    0.000000]  [<ffffffff8163f39f>] ? printk+0x41/0x43
(early) [    0.000000]  [<ffffffff81621462>] init_memory_mapping+0x562/0x590
(early) [    0.000000]  [<ffffffff81af58cb>] setup_arch+0x63a/0xafb
(early) [    0.000000]  [<ffffffff8163f39f>] ? printk+0x41/0x43
(early) [    0.000000]  [<ffffffff81aefbaf>] start_kernel+0xe6/0x408
(early) [    0.000000]  [<ffffffff81aef346>] x86_64_start_reservations+0x131/0x136
(early) [    0.000000]  [<ffffffff81af2b62>] xen_start_kernel+0x60d/0x614


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 20:31:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 20:31:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkiLE-0003Jv-3N; Tue, 10 Jan 2012 20:30:44 +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 1RkiLB-0003JX-NR
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 20:30:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326227433!10458068!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4MjgzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21574 invoked from network); 10 Jan 2012 20:30:34 -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; 10 Jan 2012 20:30:34 -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
	q0AKUSD1012010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Jan 2012 20:30:29 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
	q0AKUQGD003001
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2012 20:30:27 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0AKUQ05021678; Tue, 10 Jan 2012 14:30:26 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 12:30:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A9110402F5; Tue, 10 Jan 2012 15:28:38 -0500 (EST)
Date: Tue, 10 Jan 2012 15:28:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: tj@kernel.org, linux-kernel@vger.kernel.org, rjw@sisk.pl
Message-ID: <20120110202838.GA10402@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F0C9FE6.0090,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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,

With that patch I get this when trying to launch a 4GB xen guest:

kernel="/mnt/lab/latest/vmlinuz"
ramdisk="/mnt/lab/latest/initramfs.cpio.gz"
extra="console=hvc0 debug earlyprintk=xen" 
memory=4096
maxmem=8192
vcpus=4
on_crash="preserve"
vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'

If I change the "memory" to be "4000" it or if I revert the
mention git commit it boots. This is what I get with the mentioned
git commit:

(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-04371-g6b3da11 (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #2 SMP PREEMPT Tue Jan 10 12:47:50 EST 2012
(early) [    0.000000] Command line: console=hvc0 debug earlyprintk=xen
(early) [    0.000000] Disabled fast string operations
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Released 0 pages of unused memory
(early) [    0.000000] Set 0 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 - 0000000200800000 (usable)
(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] e820 update range: 0000000000000000 - 0000000000010000 (early) (usable)(early)  ==> (early) (reserved)(early) 
(early) [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (early) (usable)(early) 
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x200800 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
(early) [    0.000000] initial memory mapped : 0 - 0fbec000
(early) [    0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480
(early) [    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
(early) [    0.000000]  0000000000 - 0100000000 page 4k
(early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
(early) [    0.000000] Pid: 0, comm: swapper Not tainted 3.2.0-04371-g6b3da11 #2
(early) [    0.000000] Call Trace:
(early) [    0.000000]  [<ffffffff8163f230>] panic+0x9b/0x1c9
(early) [    0.000000]  [<ffffffff8163f39f>] ? printk+0x41/0x43
(early) [    0.000000]  [<ffffffff81621462>] init_memory_mapping+0x562/0x590
(early) [    0.000000]  [<ffffffff81af58cb>] setup_arch+0x63a/0xafb
(early) [    0.000000]  [<ffffffff8163f39f>] ? printk+0x41/0x43
(early) [    0.000000]  [<ffffffff81aefbaf>] start_kernel+0xe6/0x408
(early) [    0.000000]  [<ffffffff81aef346>] x86_64_start_reservations+0x131/0x136
(early) [    0.000000]  [<ffffffff81af2b62>] xen_start_kernel+0x60d/0x614


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 21:05:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 21: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 1Rkis6-0003hW-1x; Tue, 10 Jan 2012 21:04:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rkis4-0003hF-9z
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 21:04:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326229429!51993968!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 27095 invoked from network); 10 Jan 2012 21:03:49 -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;
	10 Jan 2012 21:03:49 -0000
Received: by wgbdt11 with SMTP id dt11so5900wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 13:04: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=AQ6+SSw9SBofaTRVk6PjQF7807LvLlDoNz7LfjTpYak=;
	b=TE51873ogmJSbvpCBi6Uhq99P+1K7tMbQ1beUSpXkQKvlb692pquXShgrBHM9dx4mp
	1W8ILZGFF/ZXr5DeS6MFDeTu6CiYe5dmJllh06TWquRafomkLRwbAVB3C1vPbRTNrAOD
	LgihPF5QAkoFUReS+W0QI53jHNApZJaxF+lxk=
Received: by 10.180.72.162 with SMTP id e2mr14980729wiv.8.1326229478776;
	Tue, 10 Jan 2012 13:04:38 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id ej7sm13440842wbb.20.2012.01.10.13.04.36
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 13:04:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Jan 2012 21:04:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>, <xen-devel@lists.xensource.com>
Message-ID: <CB32585E.287FC%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: fix typo iff -> if
Thread-Index: AczP23G+m+xJhUjI+0emppPL4bOcuQ==
In-Reply-To: <a78507899bea4824901d.1326227419@zhigang.us.oracle.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] libxl: fix typo iff -> if
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/01/2012 20:30, "Zhigang Wang" <zhigang.x.wang@oracle.com> wrote:

> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1326227259 18000
> # Node ID a78507899bea4824901d209d818b69545f607312
> # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> libxl: fix typo iff -> if

Iff means "if and only if". It was almost certainly intended here.

 -- Keir

> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> 
> diff -r 03138a08366b -r a78507899bea tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_types.idl Tue Jan 10 15:27:39 2012 -0500
> @@ -106,7 +106,7 @@ libxl_dominfo = Struct("dominfo",[
>      ("dying",       bool),
>  
>      ("shutdown_reason", uint8, False,
> -"""Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
> +"""Valid SHUTDOWN_* value from xen/sched.h if (shutdown||dying).
>  
>  Otherwise set to a value guaranteed not to clash with any valid
>  SHUTDOWN_* constant."""),
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 10 21:05:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 21: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 1Rkis6-0003hW-1x; Tue, 10 Jan 2012 21:04:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rkis4-0003hF-9z
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 21:04:40 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326229429!51993968!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 27095 invoked from network); 10 Jan 2012 21:03:49 -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;
	10 Jan 2012 21:03:49 -0000
Received: by wgbdt11 with SMTP id dt11so5900wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 13:04: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=AQ6+SSw9SBofaTRVk6PjQF7807LvLlDoNz7LfjTpYak=;
	b=TE51873ogmJSbvpCBi6Uhq99P+1K7tMbQ1beUSpXkQKvlb692pquXShgrBHM9dx4mp
	1W8ILZGFF/ZXr5DeS6MFDeTu6CiYe5dmJllh06TWquRafomkLRwbAVB3C1vPbRTNrAOD
	LgihPF5QAkoFUReS+W0QI53jHNApZJaxF+lxk=
Received: by 10.180.72.162 with SMTP id e2mr14980729wiv.8.1326229478776;
	Tue, 10 Jan 2012 13:04:38 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id ej7sm13440842wbb.20.2012.01.10.13.04.36
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 13:04:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 10 Jan 2012 21:04:30 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>, <xen-devel@lists.xensource.com>
Message-ID: <CB32585E.287FC%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] libxl: fix typo iff -> if
Thread-Index: AczP23G+m+xJhUjI+0emppPL4bOcuQ==
In-Reply-To: <a78507899bea4824901d.1326227419@zhigang.us.oracle.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] libxl: fix typo iff -> if
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 10/01/2012 20:30, "Zhigang Wang" <zhigang.x.wang@oracle.com> wrote:

> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1326227259 18000
> # Node ID a78507899bea4824901d209d818b69545f607312
> # Parent  03138a08366b895d79e143119d4c9c72833cdbcd
> libxl: fix typo iff -> if

Iff means "if and only if". It was almost certainly intended here.

 -- Keir

> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>
> 
> diff -r 03138a08366b -r a78507899bea tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl Fri Dec 09 16:19:36 2011 +0000
> +++ b/tools/libxl/libxl_types.idl Tue Jan 10 15:27:39 2012 -0500
> @@ -106,7 +106,7 @@ libxl_dominfo = Struct("dominfo",[
>      ("dying",       bool),
>  
>      ("shutdown_reason", uint8, False,
> -"""Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
> +"""Valid SHUTDOWN_* value from xen/sched.h if (shutdown||dying).
>  
>  Otherwise set to a value guaranteed not to clash with any valid
>  SHUTDOWN_* constant."""),
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 10 21:42:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 21:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkjRu-0003vO-4G; Tue, 10 Jan 2012 21:41:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RkjRs-0003vJ-2s
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 21:41:40 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326231693!11828890!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQzNzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28422 invoked from network); 10 Jan 2012 21:41:34 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Jan 2012 21:41:34 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 0EB82232C;
	Tue, 10 Jan 2012 23:41:31 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5324D20058; Tue, 10 Jan 2012 23:41:31 +0200 (EET)
Date: Tue, 10 Jan 2012 23:41:31 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120110214131.GI12984@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>
	<20111214090338.GS12984@reaktio.net>
	<alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
	<20120109163557.GH12984@reaktio.net>
	<20236.29162.682797.328342@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20236.29162.682797.328342@mariner.uk.xensource.com>
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 Tue, Jan 10, 2012 at 05:14:18PM +0000, Ian Jackson wrote:
> Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] [PATCH 0 of 6] pygrub fixes =
to support a Fedora 16	guest"):
> > They're already in xen-unstable, and they should be backported to xen-4=
.1-testing.
> > =

> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/85d7b207fabc
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/138f707fa598
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/65679fee0177
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/152049468175
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/979bc34d0ad0
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/c681dd5aecf3
> > =

> > In the case they don't apply as-is to xen-4.1-testing =

> > Fedora 16 xen-4.1.2-2.fc16.src.rpm already contains those patches backp=
orted to 4.1.2.
> =

> Thanks, it was trivial to fix up the one conflict myself.  I have
> backported them all.
> =


Great, thanks a lot!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 21:42:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 21:42:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkjRu-0003vO-4G; Tue, 10 Jan 2012 21:41:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RkjRs-0003vJ-2s
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 21:41:40 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326231693!11828890!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDQzNzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28422 invoked from network); 10 Jan 2012 21:41:34 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Jan 2012 21:41:34 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 0EB82232C;
	Tue, 10 Jan 2012 23:41:31 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 5324D20058; Tue, 10 Jan 2012 23:41:31 +0200 (EET)
Date: Tue, 10 Jan 2012 23:41:31 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120110214131.GI12984@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>
	<20111214090338.GS12984@reaktio.net>
	<alpine.DEB.2.00.1112141151340.11802@vega-a.dur.ac.uk>
	<20120109163557.GH12984@reaktio.net>
	<20236.29162.682797.328342@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20236.29162.682797.328342@mariner.uk.xensource.com>
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 Tue, Jan 10, 2012 at 05:14:18PM +0000, Ian Jackson wrote:
> Pasi K=E4rkk=E4inen writes ("Re: [Xen-devel] [PATCH 0 of 6] pygrub fixes =
to support a Fedora 16	guest"):
> > They're already in xen-unstable, and they should be backported to xen-4=
.1-testing.
> > =

> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/85d7b207fabc
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/138f707fa598
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/65679fee0177
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/152049468175
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/979bc34d0ad0
> > http://xenbits.xen.org/hg/xen-unstable.hg/rev/c681dd5aecf3
> > =

> > In the case they don't apply as-is to xen-4.1-testing =

> > Fedora 16 xen-4.1.2-2.fc16.src.rpm already contains those patches backp=
orted to 4.1.2.
> =

> Thanks, it was trivial to fix up the one conflict myself.  I have
> backported them all.
> =


Great, thanks a lot!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 21:58:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 21: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 1Rkji5-00047w-VI; Tue, 10 Jan 2012 21:58:25 +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 1Rkji4-00047r-4D
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 21:58:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326232696!10483823!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjY0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10181 invoked from network); 10 Jan 2012 21:58:17 -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; 10 Jan 2012 21:58:17 -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
	q0ALvQ82000928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Jan 2012 21:57: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
	q0ALvN3Q002635
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2012 21:57:24 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0ALvKXb015324; Tue, 10 Jan 2012 15:57:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 13:57:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 54DF040334; Tue, 10 Jan 2012 16:55:33 -0500 (EST)
Date: Tue, 10 Jan 2012 16:55:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120110215533.GA21862@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111219145609.GB28969@andromeda.dapyr.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.0A090208.4F0CB448.0037,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, lersek@redhat.com,
	zhenzhong.duan@oracle.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Carsten Schiers <carsten@schiers.de>
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 19, 2011 at 10:56:09AM -0400, Konrad Rzeszutek Wilk wrote:
> 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.

Good news is I am able to reproduce this with my 32-bit NIC with 3.2 domU:

[  771.896140] SWIOTLB is 11% full
[  776.896116] 0 [e1000 0000:00:00.0] bounce: from:222028(slow:0)to:2 map:222037 unmap:227220 sync:0
[  776.896126] 1 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:5188 map:5188 unmap:0 sync:0
[  776.896133] 3 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:1 map:1 unmap:0 sync:0

but interestingly enough, if I boot the guest as the first one I do not get these bounce
requests. I will shortly bootup a Xen-O-Linux kernel and see if I get these same
numbers.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 21:58:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 21: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 1Rkji5-00047w-VI; Tue, 10 Jan 2012 21:58:25 +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 1Rkji4-00047r-4D
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 21:58:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326232696!10483823!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgwMjY0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10181 invoked from network); 10 Jan 2012 21:58:17 -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; 10 Jan 2012 21:58:17 -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
	q0ALvQ82000928
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Jan 2012 21:57: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
	q0ALvN3Q002635
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2012 21:57:24 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0ALvKXb015324; Tue, 10 Jan 2012 15:57:22 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 13:57:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 54DF040334; Tue, 10 Jan 2012 16:55:33 -0500 (EST)
Date: Tue, 10 Jan 2012 16:55:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120110215533.GA21862@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20111219145609.GB28969@andromeda.dapyr.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.0A090208.4F0CB448.0037,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>, lersek@redhat.com,
	zhenzhong.duan@oracle.com, Sander Eikelenboom <linux@eikelenboom.it>,
	Carsten Schiers <carsten@schiers.de>
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 19, 2011 at 10:56:09AM -0400, Konrad Rzeszutek Wilk wrote:
> 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.

Good news is I am able to reproduce this with my 32-bit NIC with 3.2 domU:

[  771.896140] SWIOTLB is 11% full
[  776.896116] 0 [e1000 0000:00:00.0] bounce: from:222028(slow:0)to:2 map:222037 unmap:227220 sync:0
[  776.896126] 1 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:5188 map:5188 unmap:0 sync:0
[  776.896133] 3 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:1 map:1 unmap:0 sync:0

but interestingly enough, if I boot the guest as the first one I do not get these bounce
requests. I will shortly bootup a Xen-O-Linux kernel and see if I get these same
numbers.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 22:48:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 22:48:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkkTi-0004Pm-2w; Tue, 10 Jan 2012 22:47:38 +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 1RkkTg-0004Ph-9X
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 22:47:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326235605!49699151!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NDQzMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15691 invoked from network); 10 Jan 2012 22:46:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Jan 2012 22:46:46 -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
	q0AMlR56011763
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Jan 2012 22:47:28 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
	q0AMlOwf011172
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2012 22:47:26 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
	q0AMlOL8013793; Tue, 10 Jan 2012 16:47:24 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 14:47:24 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 27CB2402F6; Tue, 10 Jan 2012 17:45:37 -0500 (EST)
Date: Tue, 10 Jan 2012 17:45:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tejun Heo <tj@kernel.org>
Message-ID: <20120110224537.GA6572@phenom.dumpdata.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120110222625.GA26832@google.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F0CC000.00A5,ss=1,re=0.000,fgs=0
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 10, 2012 at 02:26:25PM -0800, Tejun Heo wrote:
> On Tue, Jan 10, 2012 at 03:28:38PM -0500, Konrad Rzeszutek Wilk wrote:
> > With that patch I get this when trying to launch a 4GB xen guest:
> > 
> > kernel="/mnt/lab/latest/vmlinuz"
> > ramdisk="/mnt/lab/latest/initramfs.cpio.gz"
> > extra="console=hvc0 debug earlyprintk=xen" 
> > memory=4096
> > maxmem=8192
> > vcpus=4
> > on_crash="preserve"
> > vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
> > vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'
> > 
> > If I change the "memory" to be "4000" it or if I revert the
> > mention git commit it boots. This is what I get with the mentioned
> > git commit:
> 
> Heh, interesting.  Can you please apply the following patch and report
> the failing boot log?
> 
> Thanks.
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2f55f19..978b58eff 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -102,6 +102,10 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>  	/* align @size to avoid excessive fragmentation on reserved array */
>  	size = round_up(size, align);
>  
> +	printk("memblock_find: [0x%llx, 0x%llx) size=%llu align=%llu nid=%d\n",
> +	       (unsigned long long)start, (unsigned long long)end,
> +	       (unsigned long long)size, (unsigned long long)align, nid);
> +
>  	/* pump up @end */
>  	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
>  		end = memblock.current_limit;
> @@ -110,13 +114,27 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>  	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
>  	end = max(start, end);
>  
> +	printk("memblock_find: [0x%llx, 0x%llx) - adjusted\n",
> +	       (unsigned long long)start, (unsigned long long)end);
> +
>  	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
> +		printk("memblock_find: cand [0x%llx, 0x%llx) -> ",
> +		       (unsigned long long)this_start,
> +		       (unsigned long long)this_end);
> +
>  		this_start = clamp(this_start, start, end);
>  		this_end = clamp(this_end, start, end);
>  
> +		printk("[0x%llx, 0x%llx) ",
> +		       (unsigned long long)this_start,
> +		       (unsigned long long)this_end);
> +
>  		cand = round_down(this_end - size, align);
> -		if (cand >= this_start)
> +		if (cand >= this_start) {
> +			printk("- success %llx\n", (unsigned long long)cand);
>  			return cand;
> +		}
> +		printk("- rejected\n");
>  	}
>  	return 0;
>  }

Using config file "/mnt/lab/latest/pv.xm".
Started domain latest (id=28)
(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-05808-g597987c (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP PREEMPT Tue Jan 10 17:31:15 EST 2012
(early) [    0.000000] Command line: console=hvc0 debug earlyprintk=xenboot memblock=debug loglevel=8
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Released 0 pages of unused memory
(early) [    0.000000] Set 0 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 - 0000000200800000 (usable)
(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] e820 update range: 0000000000000000 - 0000000000010000 (early) (usable)(early)  ==> (early) (reserved)(early) 
(early) [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (early) (usable)(early) 
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x200800 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
(early) [    0.000000] memblock_reserve: [0x00000001dec000-0x00000001e03000] setup_arch+0x592/0xafb
(early) [    0.000000] MEMBLOCK configuration:
(early) [    0.000000]  memory size = 0x200790000 reserved size = 0x10f960000
(early) [    0.000000]  memory.cnt  = 0x2
(early) [    0.000000]  memory[0x0]	[0x00000000010000-0x0000000009ffff], 0x90000 bytes
(early) [    0.000000]  memory[0x1]	[0x00000000100000-0x000002007fffff], 0x200700000 bytes
(early) [    0.000000]  reserved.cnt  = 0x3
(early) [    0.000000]  reserved[0x0]	[0x00000001000000-0x00000001e02fff], 0xe03000 bytes
(early) [    0.000000]  reserved[0x1]	[0x0000000220a000-0x00000010566fff], 0xe35d000 bytes
(early) [    0.000000]  reserved[0x2]	[0x00000100000000-0x000002007fffff], 0x100800000 bytes
(early) [    0.000000] initial memory mapped : 0 - 0fcdd000
(early) [    0.000000] memblock_find: [0x0, 0x100000) size=20480 align=4096 nid=1024
(early) [    0.000000] memblock_find: [0x5000, 0x100000) - adjusted
(early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0x100000, 0x100000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x100000, 0x100000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x100000, 0x100000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x10000, 0xa0000) -> (early) [0x10000, 0xa0000) (early) - success 9b000
(early) [    0.000000] memblock_reserve: [0x0000000009b000-0x000000000a0000] setup_trampolines+0x66/0x9c
(early) [    0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480
(early) [    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
(early) [    0.000000]  0000000000 - 0100000000 page 4k
(early) [    0.000000] memblock_find: [0x0, 0xfcdd000) size=8409088 align=4096 nid=1024
(early) [    0.000000] memblock_find: [0x805000, 0xfcdd000) - adjusted
(early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0xfcdd000, 0xfcdd000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x1e03000, 0x220a000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x805000, 0x1000000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x10000, 0x9b000) -> (early) [0x805000, 0x805000) (early) - rejected
(early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
(early) [    0.000000] Pid: 0, comm: swapper Not tainted 3.2.0-05808-g597987c #1
(early) [    0.000000] Call Trace:
(early) [    0.000000]  [<ffffffff816011e5>] panic+0x96/0x1c4
(early) [    0.000000]  [<ffffffff815e4612>] init_memory_mapping+0x562/0x590
(early) [    0.000000]  [<ffffffff81ae88c6>] setup_arch+0x63a/0xafb
(early) [    0.000000]  [<ffffffff8160134f>] ? printk+0x3c/0x3e
(early) [    0.000000]  [<ffffffff81ae2baf>] start_kernel+0xe6/0x403
(early) [    0.000000]  [<ffffffff81ae2346>] x86_64_start_reservations+0x131/0x136
(early) [    0.000000]  [<ffffffff81ae5b5d>] xen_start_kernel+0x60d/0x614

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 10 22:48:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 10 Jan 2012 22:48:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkkTi-0004Pm-2w; Tue, 10 Jan 2012 22:47:38 +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 1RkkTg-0004Ph-9X
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 22:47:36 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326235605!49699151!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NDQzMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15691 invoked from network); 10 Jan 2012 22:46:46 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 10 Jan 2012 22:46:46 -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
	q0AMlR56011763
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 10 Jan 2012 22:47:28 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
	q0AMlOwf011172
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 10 Jan 2012 22:47:26 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
	q0AMlOL8013793; Tue, 10 Jan 2012 16:47:24 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 10 Jan 2012 14:47:24 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 27CB2402F6; Tue, 10 Jan 2012 17:45:37 -0500 (EST)
Date: Tue, 10 Jan 2012 17:45:37 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tejun Heo <tj@kernel.org>
Message-ID: <20120110224537.GA6572@phenom.dumpdata.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120110222625.GA26832@google.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F0CC000.00A5,ss=1,re=0.000,fgs=0
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 10, 2012 at 02:26:25PM -0800, Tejun Heo wrote:
> On Tue, Jan 10, 2012 at 03:28:38PM -0500, Konrad Rzeszutek Wilk wrote:
> > With that patch I get this when trying to launch a 4GB xen guest:
> > 
> > kernel="/mnt/lab/latest/vmlinuz"
> > ramdisk="/mnt/lab/latest/initramfs.cpio.gz"
> > extra="console=hvc0 debug earlyprintk=xen" 
> > memory=4096
> > maxmem=8192
> > vcpus=4
> > on_crash="preserve"
> > vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
> > vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'
> > 
> > If I change the "memory" to be "4000" it or if I revert the
> > mention git commit it boots. This is what I get with the mentioned
> > git commit:
> 
> Heh, interesting.  Can you please apply the following patch and report
> the failing boot log?
> 
> Thanks.
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2f55f19..978b58eff 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -102,6 +102,10 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>  	/* align @size to avoid excessive fragmentation on reserved array */
>  	size = round_up(size, align);
>  
> +	printk("memblock_find: [0x%llx, 0x%llx) size=%llu align=%llu nid=%d\n",
> +	       (unsigned long long)start, (unsigned long long)end,
> +	       (unsigned long long)size, (unsigned long long)align, nid);
> +
>  	/* pump up @end */
>  	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
>  		end = memblock.current_limit;
> @@ -110,13 +114,27 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>  	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
>  	end = max(start, end);
>  
> +	printk("memblock_find: [0x%llx, 0x%llx) - adjusted\n",
> +	       (unsigned long long)start, (unsigned long long)end);
> +
>  	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
> +		printk("memblock_find: cand [0x%llx, 0x%llx) -> ",
> +		       (unsigned long long)this_start,
> +		       (unsigned long long)this_end);
> +
>  		this_start = clamp(this_start, start, end);
>  		this_end = clamp(this_end, start, end);
>  
> +		printk("[0x%llx, 0x%llx) ",
> +		       (unsigned long long)this_start,
> +		       (unsigned long long)this_end);
> +
>  		cand = round_down(this_end - size, align);
> -		if (cand >= this_start)
> +		if (cand >= this_start) {
> +			printk("- success %llx\n", (unsigned long long)cand);
>  			return cand;
> +		}
> +		printk("- rejected\n");
>  	}
>  	return 0;
>  }

Using config file "/mnt/lab/latest/pv.xm".
Started domain latest (id=28)
(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-05808-g597987c (konrad@build.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP PREEMPT Tue Jan 10 17:31:15 EST 2012
(early) [    0.000000] Command line: console=hvc0 debug earlyprintk=xenboot memblock=debug loglevel=8
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Released 0 pages of unused memory
(early) [    0.000000] Set 0 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 - 0000000200800000 (usable)
(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] e820 update range: 0000000000000000 - 0000000000010000 (early) (usable)(early)  ==> (early) (reserved)(early) 
(early) [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (early) (usable)(early) 
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x200800 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
(early) [    0.000000] memblock_reserve: [0x00000001dec000-0x00000001e03000] setup_arch+0x592/0xafb
(early) [    0.000000] MEMBLOCK configuration:
(early) [    0.000000]  memory size = 0x200790000 reserved size = 0x10f960000
(early) [    0.000000]  memory.cnt  = 0x2
(early) [    0.000000]  memory[0x0]	[0x00000000010000-0x0000000009ffff], 0x90000 bytes
(early) [    0.000000]  memory[0x1]	[0x00000000100000-0x000002007fffff], 0x200700000 bytes
(early) [    0.000000]  reserved.cnt  = 0x3
(early) [    0.000000]  reserved[0x0]	[0x00000001000000-0x00000001e02fff], 0xe03000 bytes
(early) [    0.000000]  reserved[0x1]	[0x0000000220a000-0x00000010566fff], 0xe35d000 bytes
(early) [    0.000000]  reserved[0x2]	[0x00000100000000-0x000002007fffff], 0x100800000 bytes
(early) [    0.000000] initial memory mapped : 0 - 0fcdd000
(early) [    0.000000] memblock_find: [0x0, 0x100000) size=20480 align=4096 nid=1024
(early) [    0.000000] memblock_find: [0x5000, 0x100000) - adjusted
(early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0x100000, 0x100000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x100000, 0x100000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x100000, 0x100000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x10000, 0xa0000) -> (early) [0x10000, 0xa0000) (early) - success 9b000
(early) [    0.000000] memblock_reserve: [0x0000000009b000-0x000000000a0000] setup_trampolines+0x66/0x9c
(early) [    0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480
(early) [    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
(early) [    0.000000]  0000000000 - 0100000000 page 4k
(early) [    0.000000] memblock_find: [0x0, 0xfcdd000) size=8409088 align=4096 nid=1024
(early) [    0.000000] memblock_find: [0x805000, 0xfcdd000) - adjusted
(early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0xfcdd000, 0xfcdd000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x1e03000, 0x220a000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x805000, 0x1000000) (early) - rejected
(early) [    0.000000] memblock_find: cand [0x10000, 0x9b000) -> (early) [0x805000, 0x805000) (early) - rejected
(early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
(early) [    0.000000] Pid: 0, comm: swapper Not tainted 3.2.0-05808-g597987c #1
(early) [    0.000000] Call Trace:
(early) [    0.000000]  [<ffffffff816011e5>] panic+0x96/0x1c4
(early) [    0.000000]  [<ffffffff815e4612>] init_memory_mapping+0x562/0x590
(early) [    0.000000]  [<ffffffff81ae88c6>] setup_arch+0x63a/0xafb
(early) [    0.000000]  [<ffffffff8160134f>] ? printk+0x3c/0x3e
(early) [    0.000000]  [<ffffffff81ae2baf>] start_kernel+0xe6/0x403
(early) [    0.000000]  [<ffffffff81ae2346>] x86_64_start_reservations+0x131/0x136
(early) [    0.000000]  [<ffffffff81ae5b5d>] xen_start_kernel+0x60d/0x614

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 03:58:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 03:58:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkpJY-0002Mz-Oo; Wed, 11 Jan 2012 03:57:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1RkpJX-0002Mu-PG
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 03:57:27 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326254239!10394562!1
X-Originating-IP: [203.10.76.15]
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 30144 invoked from network); 11 Jan 2012 03:57:20 -0000
Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15)
	by server-2.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 03:57:20 -0000
Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by calzone.tip.net.au (Postfix) with ESMTPSA id A1CE63A8004;
	Wed, 11 Jan 2012 14:57:14 +1100 (EST)
Date: Wed, 11 Jan 2012 14:57:09 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Xen Devel
	<Xen-devel@lists.xensource.com>
Message-Id: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.8; i486-pc-linux-gnu)
Mime-Version: 1.0
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] linux-next: manual merge of the xen tree with Linus'
	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: multipart/mixed; boundary="===============9182187689910964876=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9182187689910964876==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="PGP-SHA256";
 boundary="Signature=_Wed__11_Jan_2012_14_57_09_+1100_3.I5m9WLz+XWRtAh"

--Signature=_Wed__11_Jan_2012_14_57_09_+1100_3.I5m9WLz+XWRtAh
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

Today's linux-next merge of the xen tree got a conflict in
arch/x86/xen/Kconfig between commit 10fe570fc167 ("Revert "xen/debug:
WARN_ON when identity PFN has no _PAGE_IOMAP flag set."") from Linus'
tree and commit 23757fb5d678 ("xen: add CPU microcode update driver")
from the xen tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/xen/Kconfig
index fdce49c,4d04d4f..0000000
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@@ -50,3 -50,14 +50,6 @@@ config XEN_DEBUG_F
  	  Enable statistics output and various tuning options in debugfs.
  	  Enabling this option may incur a significant performance overhead.
 =20
 -config XEN_DEBUG
 -	bool "Enable Xen debug checks"
 -	depends on XEN
 -	default n
 -	help
 -	  Enable various WARN_ON checks in the Xen MMU code.
 -	  Enabling this option WILL incur a significant performance overhead.
 -
+ config MICROCODE_XEN
+        def_bool y
+        depends on XEN_DOM0 && MICROCODE

--Signature=_Wed__11_Jan_2012_14_57_09_+1100_3.I5m9WLz+XWRtAh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPDQiVAAoJEECxmPOUX5FEG7AP/Rssqi+tUaxgVskTmlim2KNY
kWhpjgiZ0j6Hq1gNncJa/YntMH+GP2IAaCOkXqf2KSzfi6/2ZxpB64qhpwUv6m7x
Vy7qag1Qw6hIZ20jue9IdkI2Zw5nmk3kPwpvE9pYbvd8zUqTS2RSUyk4dxLTd2A2
2YRqEGfGsJQ4axMLX5y2S4bTzIezUNWuw0z+SXs3wpiaiXUWl7Ge2XQfnN/gkNiu
7bGw7nTwZirdZ5d70As5EEDmb42rEJ7OtU+3VSj4R90d/2m22a0IZyfwbcEFOYn+
hzd1boox/8nWEHQXVYsWMvnD3b71c57ydcb1MBbJ+mxX0NLEwKQBzemwKywFafwV
7mx4a58NkkvKvGQ4IDRry7gCzM+/8osI0rukLivLji6plJDLvwnB3Q2T+vI/G+dj
gBZAIdwEjlry6Y4YmOu9EbGw4Cq/DRb5t+EcvGFKzfcE41tXdhVhBeL7W+gKaE1J
844Yvfm2xtbthYv4tDjVer+gQr8IbVZ1IMfvS+A/TDqJqHzJKN1dL1wrAyKLKtAX
EnrlfGr9dnS68yhR89bCCTfDCGJ8KN/FSIaHSlhHg+8dzHim2l6NAnuroI0ROJvt
UVfjgNYNVtj1XJMFgoCo+w3wbonrF71bFh3TRRCE3Eb9jt3VQjar5QRVBQjxOT5m
r3D7nPvrJGUr9G5pUvvl
=NhaO
-----END PGP SIGNATURE-----

--Signature=_Wed__11_Jan_2012_14_57_09_+1100_3.I5m9WLz+XWRtAh--


--===============9182187689910964876==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9182187689910964876==--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 03:58:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 03:58:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkpJY-0002Mz-Oo; Wed, 11 Jan 2012 03:57:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1RkpJX-0002Mu-PG
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 03:57:27 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326254239!10394562!1
X-Originating-IP: [203.10.76.15]
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 30144 invoked from network); 11 Jan 2012 03:57:20 -0000
Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15)
	by server-2.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 03:57:20 -0000
Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by calzone.tip.net.au (Postfix) with ESMTPSA id A1CE63A8004;
	Wed, 11 Jan 2012 14:57:14 +1100 (EST)
Date: Wed, 11 Jan 2012 14:57:09 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Xen Devel
	<Xen-devel@lists.xensource.com>
Message-Id: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.8; i486-pc-linux-gnu)
Mime-Version: 1.0
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] linux-next: manual merge of the xen tree with Linus'
	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: multipart/mixed; boundary="===============9182187689910964876=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9182187689910964876==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="PGP-SHA256";
 boundary="Signature=_Wed__11_Jan_2012_14_57_09_+1100_3.I5m9WLz+XWRtAh"

--Signature=_Wed__11_Jan_2012_14_57_09_+1100_3.I5m9WLz+XWRtAh
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi all,

Today's linux-next merge of the xen tree got a conflict in
arch/x86/xen/Kconfig between commit 10fe570fc167 ("Revert "xen/debug:
WARN_ON when identity PFN has no _PAGE_IOMAP flag set."") from Linus'
tree and commit 23757fb5d678 ("xen: add CPU microcode update driver")
from the xen tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/xen/Kconfig
index fdce49c,4d04d4f..0000000
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@@ -50,3 -50,14 +50,6 @@@ config XEN_DEBUG_F
  	  Enable statistics output and various tuning options in debugfs.
  	  Enabling this option may incur a significant performance overhead.
 =20
 -config XEN_DEBUG
 -	bool "Enable Xen debug checks"
 -	depends on XEN
 -	default n
 -	help
 -	  Enable various WARN_ON checks in the Xen MMU code.
 -	  Enabling this option WILL incur a significant performance overhead.
 -
+ config MICROCODE_XEN
+        def_bool y
+        depends on XEN_DOM0 && MICROCODE

--Signature=_Wed__11_Jan_2012_14_57_09_+1100_3.I5m9WLz+XWRtAh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPDQiVAAoJEECxmPOUX5FEG7AP/Rssqi+tUaxgVskTmlim2KNY
kWhpjgiZ0j6Hq1gNncJa/YntMH+GP2IAaCOkXqf2KSzfi6/2ZxpB64qhpwUv6m7x
Vy7qag1Qw6hIZ20jue9IdkI2Zw5nmk3kPwpvE9pYbvd8zUqTS2RSUyk4dxLTd2A2
2YRqEGfGsJQ4axMLX5y2S4bTzIezUNWuw0z+SXs3wpiaiXUWl7Ge2XQfnN/gkNiu
7bGw7nTwZirdZ5d70As5EEDmb42rEJ7OtU+3VSj4R90d/2m22a0IZyfwbcEFOYn+
hzd1boox/8nWEHQXVYsWMvnD3b71c57ydcb1MBbJ+mxX0NLEwKQBzemwKywFafwV
7mx4a58NkkvKvGQ4IDRry7gCzM+/8osI0rukLivLji6plJDLvwnB3Q2T+vI/G+dj
gBZAIdwEjlry6Y4YmOu9EbGw4Cq/DRb5t+EcvGFKzfcE41tXdhVhBeL7W+gKaE1J
844Yvfm2xtbthYv4tDjVer+gQr8IbVZ1IMfvS+A/TDqJqHzJKN1dL1wrAyKLKtAX
EnrlfGr9dnS68yhR89bCCTfDCGJ8KN/FSIaHSlhHg+8dzHim2l6NAnuroI0ROJvt
UVfjgNYNVtj1XJMFgoCo+w3wbonrF71bFh3TRRCE3Eb9jt3VQjar5QRVBQjxOT5m
r3D7nPvrJGUr9G5pUvvl
=NhaO
-----END PGP SIGNATURE-----

--Signature=_Wed__11_Jan_2012_14_57_09_+1100_3.I5m9WLz+XWRtAh--


--===============9182187689910964876==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9182187689910964876==--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 04:31:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 04:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkpq0-0002dp-J1; Wed, 11 Jan 2012 04:31:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1Rkppz-0002dk-Ct
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 04:30:59 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326256251!10526724!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.8 required=7.0 tests=DATE_IN_PAST_24_48
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2132 invoked from network); 11 Jan 2012 04:30:53 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 04:30:53 -0000
Received: from saboo.goop.org (114-198-82-92.dyn.iinet.net.au [114.198.82.92])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 5307A93A4;
	Tue, 10 Jan 2012 20:30:50 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id B38AB2049A;
	Tue, 10 Jan 2012 11:57:42 +1100 (EST)
Message-ID: <4F0B8D06.8050501@goop.org>
Date: Tue, 10 Jan 2012 11:57:42 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <3f35c565-bcaf-49d2-ba46-c61ca95aa51b@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091838490.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201091838490.3150@kaball-desktop>
X-Enigmail-Version: 1.3.4
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/10/2012 05:44 AM, Stefano Stabellini wrote:
> On Mon, 9 Jan 2012, Andrew Jones wrote:
>> I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in
>> arch/x86/pci/xen.c it would be pretty easy to review for equivalence.
>> Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere else and
>> compile in the 3 files. I don't think it makes much sense to do it
>> though. XEN_DOM0 keeps things tidier now and might be useful later.
> we can keep things clean with the following:
>
> #ifdef CONFIG_LOCAL_APIC && CONFIG_IO_APIC && CONFIG_ACPI && CONFIG_PCI_XEN
>
> #define XEN_DOM0
>
> #endif
>
> in include/xen/xen.h.
>
> So in the source files we can still '#ifdef XEN_DOM0', but at the same
> time we can get rid of the build symbol: everybody wins.

No, really, I think this is silly.  This kind of dependency information
should be encoded in the Kconfig system, and not reimplemented in an
ad-hoc way.

If there were a clean way to do what Andrew wants then I'd support it,
but this thread has descended into a spiral of madness, which makes me
think its a lost cause.

If the root complaint is that "customers think that anything set in
.config is a supported feature", then the solutions are to support all
the features in .config, re-educate the customers that they're wrong, or
maintain a local patch to do this stuff.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 04:31:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 04:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkpq0-0002dp-J1; Wed, 11 Jan 2012 04:31:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1Rkppz-0002dk-Ct
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 04:30:59 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326256251!10526724!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.8 required=7.0 tests=DATE_IN_PAST_24_48
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2132 invoked from network); 11 Jan 2012 04:30:53 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 04:30:53 -0000
Received: from saboo.goop.org (114-198-82-92.dyn.iinet.net.au [114.198.82.92])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 5307A93A4;
	Tue, 10 Jan 2012 20:30:50 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id B38AB2049A;
	Tue, 10 Jan 2012 11:57:42 +1100 (EST)
Message-ID: <4F0B8D06.8050501@goop.org>
Date: Tue, 10 Jan 2012 11:57:42 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <3f35c565-bcaf-49d2-ba46-c61ca95aa51b@zmail13.collab.prod.int.phx2.redhat.com>
	<alpine.DEB.2.00.1201091838490.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201091838490.3150@kaball-desktop>
X-Enigmail-Version: 1.3.4
Cc: Andrew Jones <drjones@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/10/2012 05:44 AM, Stefano Stabellini wrote:
> On Mon, 9 Jan 2012, Andrew Jones wrote:
>> I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in
>> arch/x86/pci/xen.c it would be pretty easy to review for equivalence.
>> Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere else and
>> compile in the 3 files. I don't think it makes much sense to do it
>> though. XEN_DOM0 keeps things tidier now and might be useful later.
> we can keep things clean with the following:
>
> #ifdef CONFIG_LOCAL_APIC && CONFIG_IO_APIC && CONFIG_ACPI && CONFIG_PCI_XEN
>
> #define XEN_DOM0
>
> #endif
>
> in include/xen/xen.h.
>
> So in the source files we can still '#ifdef XEN_DOM0', but at the same
> time we can get rid of the build symbol: everybody wins.

No, really, I think this is silly.  This kind of dependency information
should be encoded in the Kconfig system, and not reimplemented in an
ad-hoc way.

If there were a clean way to do what Andrew wants then I'd support it,
but this thread has descended into a spiral of madness, which makes me
think its a lost cause.

If the root complaint is that "customers think that anything set in
.config is a supported feature", then the solutions are to support all
the features in .config, re-educate the customers that they're wrong, or
maintain a local patch to do this stuff.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 07:17:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 07: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 1RksQ6-0003Tv-7n; Wed, 11 Jan 2012 07:16:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RksQ4-0003Tq-HK
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 07:16:24 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326266174!8427341!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNzQ4MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15132 invoked from network); 11 Jan 2012 07:16:16 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-14.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 07:16:16 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXM00LPEHIY1G@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:16:11 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXM0039QHGY6Y@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:16:10 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGJ28743; Wed,
	11 Jan 2012 15:16:09 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136)
	by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 15:16:00 +0800
Received: from h00166998 (10.166.80.196) by szxeml409-hub.china.huawei.com
	(10.82.67.136) with Microsoft SMTP Server id 14.1.323.3; Wed,
	11 Jan 2012 15:15:46 +0800
Date: Wed, 11 Jan 2012 15:15:43 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120110173956.GA2213@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <000901ccd030$d6f01e50$84d05af0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczPvvK7Twewij9aReW4oSdyq5HoNQAbgAqA
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
	<001301cccc1b$d7ca1470$875e3d50$@com> <20120110173956.GA2213@aepfle.de>
Cc: "'bicky.'" <bicky.shi@huawei.com>, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, 'Ian Jackson' <Ian.Jackson@eu.citrix.com>,
	yanqiangjun@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, this mail is sent out in hurry. In fact we send out 2 patches , and this is only one patch. The second patch is the key.

The second patch is about adding a fast way to trigger page-in. 
Titile is [PATCH 2 of 2] xenpaging:change page-in process to speed up page-in in xenpaging.

http://lists.xen.org/archives/html/xen-devel/2012-01/msg00210.html

In this patch, we get the return value from p2m_mem_paging_populate(). 
Because we want to known whether this p2mt is changed by balloon or others.

After this patch is published, we have received much advice, so a more perfect patch will be sent out later 

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, January 11, 2012 1:40 AM
> To: Hongkaixing
> Cc: 'Ian Jackson'; xen-devel@lists.xensource.com; 'bicky.'
> Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in in xenpaging
> 
> On Fri, Jan 06, Hongkaixing wrote:
> 
> > > Why wrap this up in a struct ?
> >
> > We want to keep the same style with
> >
> > typedef struct xenpaging_victim {
> >     /* the gfn of the page to evict */
> >     unsigned long gfn;
> > } xenpaging_victim_t;
> 
> This dates back to the initial implementation of xenpaging.
> 
> In my testing I started a guest paused, paged it all out, and paged all
> back into memory. By monitoring nr_pages I noticed that page-in got
> slightly slower over time, so your suggestion to use two indexes will
> speed things up a bit.
> 
> 
> Looking through xenpaging.c, I think its best to have two flat arrays:
> unsigned long slot_to_gfn[paging->max_pages]; /* was victims */
> int gfn_to_slot[paging->max_pages];
> 
> I will prepare a patch to implement this.
> 
> Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 07:17:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 07: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 1RksQ6-0003Tv-7n; Wed, 11 Jan 2012 07:16:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RksQ4-0003Tq-HK
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 07:16:24 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326266174!8427341!1
X-Originating-IP: [119.145.14.67]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NyA9PiAyNzQ4MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15132 invoked from network); 11 Jan 2012 07:16:16 -0000
Received: from szxga04-in.huawei.com (HELO szxga04-in.huawei.com)
	(119.145.14.67) by server-14.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 07:16:16 -0000
Received: from huawei.com (szxga04-in [172.24.2.12])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXM00LPEHIY1G@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:16:11 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXM0039QHGY6Y@szxga04-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:16:10 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGJ28743; Wed,
	11 Jan 2012 15:16:09 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136)
	by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 15:16:00 +0800
Received: from h00166998 (10.166.80.196) by szxeml409-hub.china.huawei.com
	(10.82.67.136) with Microsoft SMTP Server id 14.1.323.3; Wed,
	11 Jan 2012 15:15:46 +0800
Date: Wed, 11 Jan 2012 15:15:43 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <20120110173956.GA2213@aepfle.de>
X-Originating-IP: [10.166.80.196]
To: 'Olaf Hering' <olaf@aepfle.de>
Message-id: <000901ccd030$d6f01e50$84d05af0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczPvvK7Twewij9aReW4oSdyq5HoNQAbgAqA
X-CFilter-Loop: Reflected
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
	<001301cccc1b$d7ca1470$875e3d50$@com> <20120110173956.GA2213@aepfle.de>
Cc: "'bicky.'" <bicky.shi@huawei.com>, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, 'Ian Jackson' <Ian.Jackson@eu.citrix.com>,
	yanqiangjun@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry, this mail is sent out in hurry. In fact we send out 2 patches , and this is only one patch. The second patch is the key.

The second patch is about adding a fast way to trigger page-in. 
Titile is [PATCH 2 of 2] xenpaging:change page-in process to speed up page-in in xenpaging.

http://lists.xen.org/archives/html/xen-devel/2012-01/msg00210.html

In this patch, we get the return value from p2m_mem_paging_populate(). 
Because we want to known whether this p2mt is changed by balloon or others.

After this patch is published, we have received much advice, so a more perfect patch will be sent out later 

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, January 11, 2012 1:40 AM
> To: Hongkaixing
> Cc: 'Ian Jackson'; xen-devel@lists.xensource.com; 'bicky.'
> Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up page-in in xenpaging
> 
> On Fri, Jan 06, Hongkaixing wrote:
> 
> > > Why wrap this up in a struct ?
> >
> > We want to keep the same style with
> >
> > typedef struct xenpaging_victim {
> >     /* the gfn of the page to evict */
> >     unsigned long gfn;
> > } xenpaging_victim_t;
> 
> This dates back to the initial implementation of xenpaging.
> 
> In my testing I started a guest paused, paged it all out, and paged all
> back into memory. By monitoring nr_pages I noticed that page-in got
> slightly slower over time, so your suggestion to use two indexes will
> speed things up a bit.
> 
> 
> Looking through xenpaging.c, I think its best to have two flat arrays:
> unsigned long slot_to_gfn[paging->max_pages]; /* was victims */
> int gfn_to_slot[paging->max_pages];
> 
> I will prepare a patch to implement this.
> 
> Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 07:46:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 07:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkssb-00041M-9j; Wed, 11 Jan 2012 07:45:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Rkssa-00041H-8B
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 07:45:52 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326267944!2677721!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNzMwMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22982 invoked from network); 11 Jan 2012 07:45:44 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-5.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 07:45:44 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXM00KDKIW6Z2@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:45:42 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXM00B5EIW650@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:45:42 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGJ32380; Wed,
	11 Jan 2012 15:45:40 +0800
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 15:45:34 +0800
Received: from h00166998 (10.166.80.196) by szxeml410-hub.china.huawei.com
	(10.82.67.137) with Microsoft SMTP Server id 14.1.323.3; Wed,
	11 Jan 2012 15:45:19 +0800
Date: Wed, 11 Jan 2012 15:45:17 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
X-Originating-IP: [10.166.80.196]
To: 'Andres Lagar-Cavilla' <andres@lagarcavilla.org>,
	xen-devel@lists.xensource.com
Message-id: <000a01ccd034$f7037ee0$e50a7ca0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczPF2aiRHSBXeuWRh+o3X4+oI5MZgBHC6uw
X-CFilter-Loop: Reflected
References: <patchbomb.1326145285@xdev.gridcentric.ca>
	<f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, andres@gridcentric.ca,
	yanqiangjun@huawei.com, tim@xen.org, bicky.shi@huawei.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
 p2m_ram_paged_out state to be loaded
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

    I think it may have many unpredicted risks. 
    After p2mt is changed to p2m_ram_rw, Domain guest can access this page unrestrictedly without being trapped in xen.
 But at this time, the page is not prepared.

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres Lagar-Cavilla
> Sent: Tuesday, January 10, 2012 5:41 AM
> To: xen-devel@lists.xensource.com
> Cc: andres@gridcentric.ca; tim@xen.org; olaf@aepfle.de; adin@gridcentric.ca
> Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in p2m_ram_paged_out state to be loaded
> 
>  xen/arch/x86/mm/p2m.c |  15 +++++++++++----
>  1 files changed, 11 insertions(+), 4 deletions(-)
> 
> 
> This removes the need for a page to be accessed in order to be pageable
> again. A pager can now page-in pages at will with no need to map them
> in a separate thread.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Acked-by: Tim Deegan <tim@xen.org>
> 
> diff -r 90f764bf02c3 -r f7c330d5b4b5 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -964,7 +964,7 @@ void p2m_mem_paging_populate(struct doma
>  int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
>  {
>      struct page_info *page;
> -    p2m_type_t p2mt;
> +    p2m_type_t p2mt, target_p2mt;
>      p2m_access_t a;
>      mfn_t mfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> @@ -982,8 +982,8 @@ int p2m_mem_paging_prep(struct domain *d
>      mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
> 
>      ret = -ENOENT;
> -    /* Allow only missing pages */
> -    if ( p2mt != p2m_ram_paging_in_start )
> +    /* Allow missing pages */
> +    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
>          goto out;
> 
>      /* Allocate a page if the gfn does not have one yet */
> @@ -1018,8 +1018,15 @@ int p2m_mem_paging_prep(struct domain *d
>          }
>      }
> 
> +    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
> +        /* If we kicked the pager with a populate event, the pager will send
> +         * a resume event back */
> +        p2m_ram_paging_in :
> +        /* If this was called asynchronously by the pager, then we can
> +         * transition directly to the final guest-accessible type */
> +        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
>      /* Fix p2m mapping */
> -    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
> +    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
> 
>      atomic_dec(&d->paged_pages);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 11 07:46:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 07:46:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkssb-00041M-9j; Wed, 11 Jan 2012 07:45:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1Rkssa-00041H-8B
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 07:45:52 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326267944!2677721!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNzMwMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22982 invoked from network); 11 Jan 2012 07:45:44 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-5.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 07:45:44 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXM00KDKIW6Z2@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:45:42 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXM00B5EIW650@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:45:42 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119])
	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGJ32380; Wed,
	11 Jan 2012 15:45:40 +0800
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137)
	by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Wed, 11 Jan 2012 15:45:34 +0800
Received: from h00166998 (10.166.80.196) by szxeml410-hub.china.huawei.com
	(10.82.67.137) with Microsoft SMTP Server id 14.1.323.3; Wed,
	11 Jan 2012 15:45:19 +0800
Date: Wed, 11 Jan 2012 15:45:17 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
X-Originating-IP: [10.166.80.196]
To: 'Andres Lagar-Cavilla' <andres@lagarcavilla.org>,
	xen-devel@lists.xensource.com
Message-id: <000a01ccd034$f7037ee0$e50a7ca0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczPF2aiRHSBXeuWRh+o3X4+oI5MZgBHC6uw
X-CFilter-Loop: Reflected
References: <patchbomb.1326145285@xdev.gridcentric.ca>
	<f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, andres@gridcentric.ca,
	yanqiangjun@huawei.com, tim@xen.org, bicky.shi@huawei.com,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
 p2m_ram_paged_out state to be loaded
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

    I think it may have many unpredicted risks. 
    After p2mt is changed to p2m_ram_rw, Domain guest can access this page unrestrictedly without being trapped in xen.
 But at this time, the page is not prepared.

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres Lagar-Cavilla
> Sent: Tuesday, January 10, 2012 5:41 AM
> To: xen-devel@lists.xensource.com
> Cc: andres@gridcentric.ca; tim@xen.org; olaf@aepfle.de; adin@gridcentric.ca
> Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in p2m_ram_paged_out state to be loaded
> 
>  xen/arch/x86/mm/p2m.c |  15 +++++++++++----
>  1 files changed, 11 insertions(+), 4 deletions(-)
> 
> 
> This removes the need for a page to be accessed in order to be pageable
> again. A pager can now page-in pages at will with no need to map them
> in a separate thread.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Acked-by: Tim Deegan <tim@xen.org>
> 
> diff -r 90f764bf02c3 -r f7c330d5b4b5 xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -964,7 +964,7 @@ void p2m_mem_paging_populate(struct doma
>  int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
>  {
>      struct page_info *page;
> -    p2m_type_t p2mt;
> +    p2m_type_t p2mt, target_p2mt;
>      p2m_access_t a;
>      mfn_t mfn;
>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> @@ -982,8 +982,8 @@ int p2m_mem_paging_prep(struct domain *d
>      mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
> 
>      ret = -ENOENT;
> -    /* Allow only missing pages */
> -    if ( p2mt != p2m_ram_paging_in_start )
> +    /* Allow missing pages */
> +    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
>          goto out;
> 
>      /* Allocate a page if the gfn does not have one yet */
> @@ -1018,8 +1018,15 @@ int p2m_mem_paging_prep(struct domain *d
>          }
>      }
> 
> +    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
> +        /* If we kicked the pager with a populate event, the pager will send
> +         * a resume event back */
> +        p2m_ram_paging_in :
> +        /* If this was called asynchronously by the pager, then we can
> +         * transition directly to the final guest-accessible type */
> +        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
>      /* Fix p2m mapping */
> -    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
> +    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
> 
>      atomic_dec(&d->paged_pages);
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 11 08:03:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 08: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 1Rkt9b-0004uC-U6; Wed, 11 Jan 2012 08:03:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yufang521247@gmail.com>) id 1Rkt9Z-0004u4-QA
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 08:03:26 +0000
X-Env-Sender: yufang521247@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326268976!55187226!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26026 invoked from network); 11 Jan 2012 08:02:57 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 08:02:57 -0000
Received: by vcbfl11 with SMTP id fl11so1477768vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 00:03:22 -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=9BlD1NvtMUpojebU1LKt+jAQl57ww52qavKnPrBRoQQ=;
	b=ZcuPM2VW+Y/WvdhxH1HaQhO/BBSiFxEPGYrLRK7e1YAaqjH0xG6/ZBSNG99fEXRtuJ
	aV81KyKl2D6niCH6d0yE/Rfuuwyq1/DFJD/uHA555zN0pbei8hXYVRyP/b8as/cNQGVd
	LMlL+TbakYUgkRtVi6QPBtA9s0SsJ2BWjkx9w=
MIME-Version: 1.0
Received: by 10.52.156.101 with SMTP id wd5mr10868585vdb.1.1326269002399; Wed,
	11 Jan 2012 00:03:22 -0800 (PST)
Received: by 10.52.171.45 with HTTP; Wed, 11 Jan 2012 00:03:22 -0800 (PST)
Date: Wed, 11 Jan 2012 16:03:22 +0800
Message-ID: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
From: Yufang Zhang <yufang521247@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=bcaec53aeea4c3bde804b63c10a0
Subject: [Xen-devel] Cannot start up HVM guest when maxmem is not equal to
 memory and HAP is enabled.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--bcaec53aeea4c3bde804b63c10a0
Content-Type: multipart/alternative; boundary=bcaec53aeea4c3bde404b63c109e

--bcaec53aeea4c3bde404b63c109e
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

On my production deployment with xen-3.4.4-rc1, HVM guest would not start
up when maxmem is set not equal to memory, unless HAP is disable(hap=0).
The guest just hangs at 'Booting from Hard Disk...' as shown in the
attachment. I find that both Oracle VM and Fedora have the same problem per
the following links:

http://docs.oracle.com/cd/E15458_01/doc.22/e15443/toc.htm#BABBIBFD
http://docs.oracle.com/cd/E26996_01/e18546/CJAGDAGB.html#id419003
https://bugzilla.redhat.com/show_bug.cgi?id=645319

Could I ask if there is any work in upstream/xen-unstable to fix this
problem?

Thanks.

Below is the xm dmesg output related with the hvm guest:
(XEN) HVM3: HVM Loader
(XEN) HVM3: Detected Xen v3.4.4-rc1-pre
(XEN) HVM3: CPU speed is 2267 MHz
(XEN) irq.c:243: Dom3 PCI link 0 changed 0 -> 5
(XEN) HVM3: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:243: Dom3 PCI link 1 changed 0 -> 10
(XEN) HVM3: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:243: Dom3 PCI link 2 changed 0 -> 11
(XEN) HVM3: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:243: Dom3 PCI link 3 changed 0 -> 5
(XEN) HVM3: PCI-ISA link 3 routed to IRQ5
(XEN) HVM3: pci dev 01:2 INTD->IRQ5
(XEN) HVM3: pci dev 01:3 INTA->IRQ10
(XEN) HVM3: pci dev 03:0 INTA->IRQ5
(XEN) HVM3: pci dev 04:0 INTA->IRQ5
(XEN) HVM3: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000
(XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101
(XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000
(XEN) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201
(XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c221
(XEN) HVM3: Multiprocessor initialisation:
(XEN) HVM3:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ...
done.
(XEN) HVM3: Writing SMBIOS tables ...
(XEN) HVM3: Loading ROMBIOS ...
(XEN) HVM3: 10332 bytes of ROMBIOS high-memory extensions:
(XEN) HVM3:   Relocating to 0xfc000000-0xfc00285c ... done
(XEN) HVM3: Creating MP tables ...
(XEN) HVM3: Loading Cirrus VGABIOS ...
(XEN) HVM3: Loading PCI Option ROM ...
(XEN) HVM3:  - Manufacturer: http://etherboot.org
(XEN) HVM3:  - Product name: gPXE
(XEN) HVM3: Loading ACPI ...
(XEN) HVM3:  - Lo data: 000ea020-000ea04f
(XEN) HVM3:  - Hi data: fc002c00-fc0060bf
(XEN) HVM3: vm86 TSS at fc006400
(XEN) HVM3: BIOS map:
(XEN) HVM3:  c0000-c8fff: VGA BIOS
(XEN) HVM3:  c9000-d57ff: Etherboot ROM
(XEN) HVM3:  eb000-eb150: SMBIOS tables
(XEN) HVM3:  f0000-fffff: Main BIOS
(XEN) HVM3: Invoking ROMBIOS ...
(XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d3 entering stdvga and caching modes
(XEN) HVM3: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM3: Bochs BIOS - build: 06/23/99
(XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM3: Options: apmbios pcibios eltorito PMM
(XEN) HVM3:
(XEN) HVM3: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)
(XEN) HVM3: IDE time out
(XEN) HVM3:
(XEN) HVM3:
(XEN) HVM3:
(XEN) HVM3: Press F12 for boot menu.
(XEN) HVM3:
(XEN) HVM3: Booting from Hard Disk...
(XEN) HVM3: Booting from 0000:7c00
(XEN) io.c:199:d3 MMIO emulation failed @ 0008:4013b1: 90 86 95 21 08 83

--bcaec53aeea4c3bde404b63c109e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,=A0<div><br></div><div>On my production deployment with xen-3.4.4-rc=
1, HVM guest would not start up when maxmem is set not equal to memory, unl=
ess=A0HAP is disable(hap=3D0). The guest just hangs at &#39;Booting from Ha=
rd Disk...&#39; as shown in the attachment. I find that both Oracle VM and =
Fedora have the same problem per the following links:=A0</div>
<div><br></div><div><a href=3D"http://docs.oracle.com/cd/E15458_01/doc.22/e=
15443/toc.htm#BABBIBFD">http://docs.oracle.com/cd/E15458_01/doc.22/e15443/t=
oc.htm#BABBIBFD</a></div><div><a href=3D"http://docs.oracle.com/cd/E26996_0=
1/e18546/CJAGDAGB.html#id419003">http://docs.oracle.com/cd/E26996_01/e18546=
/CJAGDAGB.html#id419003</a></div>
<div><a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D645319">https=
://bugzilla.redhat.com/show_bug.cgi?id=3D645319</a></div><div><br></div><di=
v>Could I ask if there is any work in upstream/xen-unstable to fix this pro=
blem?=A0</div>
<div><br></div><div>Thanks.</div><div><br></div><div>Below is the xm dmesg =
output related with the hvm guest:</div><div><div>(XEN) HVM3: HVM Loader</d=
iv><div>(XEN) HVM3: Detected Xen v3.4.4-rc1-pre</div><div>(XEN) HVM3: CPU s=
peed is 2267 MHz</div>
<div>(XEN) irq.c:243: Dom3 PCI link 0 changed 0 -&gt; 5</div><div>(XEN) HVM=
3: PCI-ISA link 0 routed to IRQ5</div><div>(XEN) irq.c:243: Dom3 PCI link 1=
 changed 0 -&gt; 10</div><div>(XEN) HVM3: PCI-ISA link 1 routed to IRQ10</d=
iv>
<div>(XEN) irq.c:243: Dom3 PCI link 2 changed 0 -&gt; 11</div><div>(XEN) HV=
M3: PCI-ISA link 2 routed to IRQ11</div><div>(XEN) irq.c:243: Dom3 PCI link=
 3 changed 0 -&gt; 5</div><div>(XEN) HVM3: PCI-ISA link 3 routed to IRQ5</d=
iv>
<div>(XEN) HVM3: pci dev 01:2 INTD-&gt;IRQ5</div><div>(XEN) HVM3: pci dev 0=
1:3 INTA-&gt;IRQ10</div><div>(XEN) HVM3: pci dev 03:0 INTA-&gt;IRQ5</div><d=
iv>(XEN) HVM3: pci dev 04:0 INTA-&gt;IRQ5</div><div>(XEN) HVM3: pci dev 02:=
0 bar 10 size 02000000: f0000008</div>
<div>(XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008</div><div>(XEN=
) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000</div><div>(XEN) HVM3: p=
ci dev 03:0 bar 10 size 00000100: 0000c001</div><div>(XEN) HVM3: pci dev 04=
:0 bar 10 size 00000100: 0000c101</div>
<div>(XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000</div><div>(XEN=
) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201</div><div>(XEN) HVM3: p=
ci dev 01:1 bar 20 size 00000010: 0000c221</div><div>(XEN) HVM3: Multiproce=
ssor initialisation:</div>
<div>(XEN) HVM3: =A0- CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2=
/8] ... done.</div><div>(XEN) HVM3: Writing SMBIOS tables ...</div><div>(XE=
N) HVM3: Loading ROMBIOS ...</div><div>(XEN) HVM3: 10332 bytes of ROMBIOS h=
igh-memory extensions:</div>
<div>(XEN) HVM3: =A0 Relocating to 0xfc000000-0xfc00285c ... done</div><div=
>(XEN) HVM3: Creating MP tables ...</div><div>(XEN) HVM3: Loading Cirrus VG=
ABIOS ...</div><div>(XEN) HVM3: Loading PCI Option ROM ...</div><div>(XEN) =
HVM3: =A0- Manufacturer: <a href=3D"http://etherboot.org">http://etherboot.=
org</a></div>
<div>(XEN) HVM3: =A0- Product name: gPXE</div><div>(XEN) HVM3: Loading ACPI=
 ...</div><div>(XEN) HVM3: =A0- Lo data: 000ea020-000ea04f</div><div>(XEN) =
HVM3: =A0- Hi data: fc002c00-fc0060bf</div><div>(XEN) HVM3: vm86 TSS at fc0=
06400</div>
<div>(XEN) HVM3: BIOS map:</div><div>(XEN) HVM3: =A0c0000-c8fff: VGA BIOS</=
div><div>(XEN) HVM3: =A0c9000-d57ff: Etherboot ROM</div><div>(XEN) HVM3: =
=A0eb000-eb150: SMBIOS tables</div><div>(XEN) HVM3: =A0f0000-fffff: Main BI=
OS</div>
<div>(XEN) HVM3: Invoking ROMBIOS ...</div><div>(XEN) HVM3: $Revision: 1.22=
1 $ $Date: 2008/12/07 17:32:29 $</div><div>(XEN) stdvga.c:147:d3 entering s=
tdvga and caching modes</div><div>(XEN) HVM3: VGABios $Id: vgabios.c,v 1.67=
 2008/01/27 09:44:12 vruppert Exp $</div>
<div>(XEN) HVM3: Bochs BIOS - build: 06/23/99</div><div>(XEN) HVM3: $Revisi=
on: 1.221 $ $Date: 2008/12/07 17:32:29 $</div><div>(XEN) HVM3: Options: apm=
bios pcibios eltorito PMM=A0</div><div>(XEN) HVM3:=A0</div><div>(XEN) HVM3:=
 ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255/63</div>
<div>(XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)</=
div><div>(XEN) HVM3: IDE time out</div><div>(XEN) HVM3:=A0</div><div>(XEN) =
HVM3:=A0</div><div>(XEN) HVM3:=A0</div><div>(XEN) HVM3: Press F12 for boot =
menu.</div>
<div>(XEN) HVM3:=A0</div><div>(XEN) HVM3: Booting from Hard Disk...</div><d=
iv>(XEN) HVM3: Booting from 0000:7c00</div><div>(XEN) io.c:199:d3 MMIO emul=
ation failed @ 0008:4013b1: 90 86 95 21 08 83</div></div>

--bcaec53aeea4c3bde404b63c109e--
--bcaec53aeea4c3bde804b63c10a0
Content-Type: image/png; name="guest_hang_screen.png"
Content-Disposition: attachment; filename="guest_hang_screen.png"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gxa1polc1

iVBORw0KGgoAAAANSUhEUgAAAtcAAAGVCAYAAAA19t2nAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAFBnSURBVHhe7Z0LsiQpkmxrl7PF3GW+ijcS0gwN
qJph7uGf0yIpVXXdHOxzADVudOQ/f5v//fPPP3/5Qw5gAAZgAAZgAAZgAAZgwGOg1dKff/8Hce0l
DsDIEwzAAAzAAAzAAAzAQM/AUlz/z79PR39GILV2R4J2lj+R2HfjPSt3Hz+/c/U+j37e52AW58dO
MeHEOPNtN7877zt5Wfnt5DBisxPL09+dcXjXuDN7XSYHK8Z/lbvq2J29xbH5VT6YF/EGA/diQN5c
9xuOIySOgsA9BKo2yUjsuzFX+az8cMW1G7sSze44K+GvYjrqeYR1h83IeKtm5ah47zzuWevnrBw5
PI3WTCYPozWcGacqN9Wxqz2qzWOmOamKm3HuJZ6oF/VaMfA4cb1zKPQba0QY7i60Hb8jczviemXT
ztXaOeNeUUCvbuNXB61iw83hd363/q5dhIkn2L4hL4q5KEu9vbOef8VKNvZWWM/Ws2Pzq7iZFwEH
A/dk4DRx3W9gSsiODgrnRiN7yGbHVnH1tyKOCFU2zk1MVDRGD1YnX5GbNRVTVZ7djUpxpA579X7v
h2vv2q1uvme5VjH19XTGWdVV1XTE5GzfqBBIEX9mTaa73l0OnXmyLM3Etaqrer7rj/O+2iOdMTI2
mbrxzj3FEXWjbjsM2OJaiZ+RkFrdpDjibGWjNvjIYas2ajVX9ABUcbmiNCO0VKyrOq7inL2nBIsa
U40bZcxdLCq3Ki71fvZgj44byY8jrnvxqOrzFcPO2Nk9wWV2VfuquZ1xXAZHQn22XkaNiDvPrIlp
GxknLmdvcX1acdvX24ndWTeOTdR/7BFoMPBOBmxx7QCiNlclSCKHyWzzdQ4BR9A5AteZy92ws+LD
qYsT7+yAmjUpo1ru5kPxo+Jwc+3kTI21+/wK4lr54NYjU/dqflb1cOZS9VwJeGftOswpm9U8jsCc
jT8b99fi2qnpSmir/ULxr+rB83eKJupO3R0GThXXjkORQ8wRwNHxVhuyc4g6NqM8uO+1QsHNp3PI
qMPZ8S8jsqK+zZqq/uetMKjMk5rffZ492B0R6PDl2Lji2hmrKt4dn1YcOHmNzL27Tp2cRvyJxp5Z
71X+rPZstb52fHAYyOwlvIMYg4H3MXA5cd3fMinxlTkEnM3bEe67YjIi5LPiJHNIZ+PKvpc5MNVB
qJ6rzU69n30+E/1qPJWj3Xgc3iM+qHjU89lcO+IpKjAza6dynaqxqnKRXbfZ945gVbHp8ObYKN95
/j4RRc2p+YiBn4nrzMaceSciGqKHWZU/jo/OXJFFvmpiKv1xmp/MweiMu3tYrt53xnZ8VLGr5tKt
ucOP628mdrW2Zg1vxifHv6w/rZ9OTmdxqbplxz4qdtcflR8Vt8uBs0dF104md0482CC+YOB9DIT+
EpkVIK5Ya+2czW92uM7GGW3uH9t+LgV7H4+6Jdr1xxERI59UHE7NZjZ9TG0encPWzaFzIDuxOzbR
fK3idA5jtS6c2LMCbSYgXVZXAmYVuxOzs06zAqpf727NI/xE4j/aHzffap2r/bgqP6oes31jlEcV
u7MHOTbKZ56/TzxRc2q+YkDeXAMQAMEADMAADMAADMAADMCAxwDi+t+/EhxYyAEMwAAMwAAMwAAM
wEAFA4hrxDXNBQzAAAzAAAzAAAzAQBEDiOuiRFZ0OoxBxwwDMAADMAADMAAD92YAcY24plOFARiA
ARiAARiAARgoYgBxXZRIusx7d5nUj/rBAAzAAAzAAAxUMLAtrldfm/T96qToVx3NvroqOo5KkPoa
p8/7T7OJfJ2Wyh/P2YR2GVitL+cr2Xa+ErLdZ6J7i7tHZfPj+OPYjPaw3vedPTz69XjOXN+cqb1X
7WV//vz5+/nT1mD0M1Wj7zujf47e7ef82jj+9HPMxo/6pGLkOXs5DNQyUCau2028/3fnv0cb6qjY
/WG6+r7ZFSzOOG+wyeaPhVi7EN+Yz4r11Qqsfg9pc1oxV3aPyta2wudI81Gxhyuf2+ezf1/VLVLj
VoCuBK5Tn14Yz0T6aM6IuP7YqgagfT77dycmbNjDYeA4BkrE9WzDG90MuZvjTPSpzduBxRn7qTaR
RsfJJTbHLc4n53a1vpS4Wt04j/he/WxHgDt7xE4Nnb1O2bjiOrOHf/O62tNHNs5czpizG/hezFYI
0Nmtc1tfNY9zc+2K65lgn92a73DIu+zxMBBnYFtcq4NwtZGuxLd7SGZuXp1D8ak2Z4vr2a+BR9ys
fg3MOH+XH1G6Wn7UZuyu2/52sx93FvdKePXPjt6jVC5mz5VwdtayI64ze/goh25NlXB2/HHiqvzo
RC+c+5o5wtmxccT1TNBnOJvlaDTH6iMrjPO/H0Ga/eaC/LwvP6eL6/YwVJvoagOdjeNsMP2B/T0o
3vBz50B2cohNvJMlZ//JmSvEVg1Xz3KkORvVYiTUd/ao3Xorf9r4d/dVR/BGauHE7jDgXHLMfB/d
JKuPXMz8Vp+FdoSzY3O2uHbqhA17PQzEGThdXI/E3eyQcG4nMkV/g4iexYi4ji+SDGO8s87ziE+1
3p3bUkdkOjfXbmOvfN7hICo+XV9W47rPnFqo2KPxRRud2eekMx+dcG+uRzeUX78R1+y9ak3w/DmM
/ERcuwLPPSyiQDq3IU+1cXMfzenMfnT71h/M2NzrIx9OvRQ/7tpWAqxqHGddVM6l8jO7hOjf631S
/63GdcX1yH9VK+V7ZEynFq6YdWqhbryduRybs2+u+bjC+z6u0DLGR1n+U/92H6hYF4jr5nuuV7e9
38Tf3cYREc5hg81zOuxf1NIRRzMh2DZnVeM466JyLifnjlhVYtr1ebS/OWJY1eKb14hwbm2dS46Z
766YdWrxa3E9u21XfjmxYcNeDgP1DLxSXDsH6VtsnAOchVe/8Mjpf75DfiXsqsSjGsdZ765QdeZy
6u+sTTWX63NGXDtj79yEz5qrVdPViv2niOuVgEZcszc7ewk253NSJq77XxWPbh9WtxyRjdo5dByY
Vj73h41zSNzBpo+5rYmTM2zOX6RPznnLY3/LOWJVicmVSF6x3/vhiO3sXE49o3uT06CMYpzt0/2+
4NTi7D1T7WVV4lr9nxk/cbtzrT6T3Y6j7Ea2DlfYsH/DwDkMlIlrCnZOwcgzeYYBGIABGIABGICB
6zKAuG4+cw2o1wWV2lAbGIABGIABGICBOzCAuEZc/70DqPjIhgoDMAADMAADMHAHBhDXiGvENQzA
AAzAAAzAAAzAQBEDiOuiRN6hk8JHOn4YgAEYgAEYgAEYOJYBxDXimk4VBmAABmAABmAABmCgiAHE
dVEi6QKP7QLJL/mFARiAARiAARi4AwOIa8Q1nSoMwAAMwAAMwAAMwEARA4jrokTeoZPCRzp+GIAB
GIABGIABGDiWAcQ14ppOFQZgAAZgAAZgAAZgoIgBxHVRIukCj+0CyS/5hQEYgAEYgAEYuAMDiGvE
NZ0qDMAADMAADMAADMBAEQOI66JE3qGTwkc6fhiAARiAARiAARg4lgHENeKaThUGYAAGYAAGYAAG
YKCIAcR1USLpAo/tAskv+YUBGIABGIABGLgDA4hrxDWdKgzAAAzAAAzAAAzAQBEDiOuiRN6hk8JH
On4YgAEYgAEYgAEYOJYBxDXimk4VBmAABmAABmAABmCgiAHEdVEi6QKP7QLJL/mFARiAARiAARi4
AwOIa8Q1nSoMwAAMwAAMwAAMwEARA4jrokTeoZPCRzp+GIABGIABGIABGDiWAcQ14ppOFQZgAAZg
AAZgAAZgoIiBpbj+n3+fjv6MOp7W7o0d0Tf+3didcT42u/Pw/rFdK/klvzAAAzAAAzDwTgbkzXUv
9lbizxGGTwWtKnY1jnr+1PwS1zs3KOpO3WEABmAABu7GAOK66FcAZxW+UlxXjnVW/MzDJgsDMAAD
MAADMHBlBk4T187HS3ob9fGTmTh05lJFUWO376uPxLj+rMaJfERHxfZ9jrhmc3JZwQ5WYAAGYAAG
YMBjwBbXSkB+Ep4RpLNCjcZyfubYOHBEYqmMXQle9dyJDRtvcZAn8gQDMAADMAADMBBlwBbXzsBK
kKobXPV8JWL721hnrFVMKpb+3arPoivxrJ47dcKGjQIGYAAGYAAGYAAGjmHgVHEdEbOOWP3YRERu
BKJKcd02BSOfW7+UeFbPIzFie8yiIq/kFQZgAAZgAAbey8AtxXV/Sx0RpxHYeyHrCH41vhLHu8/V
/EflKjIvtu/dcKg9tYcBGIABGHg6Az8T10q4up+dVuO0t8aZYvYfL5mNEbnp3hHp7btKiKt4d99X
4/OcDRQGYAAGYAAGYOBtDIT+EplVcpQIdT4D3drMRHF0nAoBqcaoiL3/6Mjq4yN9nt4GLfGyUcMA
DMAADMAADFyVAXlzfVXH8YtFBQMwAAMwAAMwAAMwcDUGENc3+0tkrgYQ/rCpwQAMwAAMwAAMwMB/
GEBcI67/6xtXWCBskjAAAzAAAzAAAzCQYwBxjbhGXMMADMAADMAADMAADBQxgLguSiTdXa67I2/k
DQZgAAZgAAZg4EkMIK4R13SqMAADMAADMAADMAADRQyUimv1tw9WdSXqq++cr7X7xVf6VcWvxnHy
o8ZwcnhXm9bvVR7UVzA6OTzLxuHZ9cXhp8rmz58/f9s/Ix+vZuPm8Qy7Pjef/87Oe7U8X82fbF55
jxtZGHgfA2Xi+iwhkvlLYyrecQXZrxeRE6vjozPOHW36hmCWizt9l7j7Fy5dre5f8fT1q//vz8+v
ZuPk8CwbJ1+uL1fL89X8cfOI3ftEFDWn5iMGbiWunb8F0bEZJSIjFK+2qLKx93E449zRpvKm/Wq1
d2uYualva11V95Ew7MX01WyuXvNRM+L4fLU8X80fJ4fYILBgAAZaBrbF9ejX0f3HQ0aH8+gjJGqs
qoPdESKVt4HOolO/1ndy6ORnJDCdxqJ9r//3Nr4jhJgTl2Mz83NWnzN+G1NRd4fnq9X9agLK8cdZ
x66N+jhH64/62Ew75+o2e/YxCyf2N9u4NcUOcQUDMPBlYFtcfwdSQqT/NbuyH0E6E27Rn7siSwmf
qoXkCnmVQycPjs/OOHe0cevuMu3kcmVTVfdoXE4zcXR9R+Lx49eVf75b7+/77sc5elGtBO7sufL7
yjm/gm8qfzxHUMEADPQMnC6ud4RL1YHv+OAKn4pF5TYa6obZyY/jrzPOHW2iItSti5NT1SxGRHj0
lt7178yaXkE0RX1w86jsXBHsfO64n8sdu30vmoe32at68hxhBQMwcBlxvRIb/Y2xEsPRjyJ8xlPC
6Q7ius+hK7pGN/Kfn1Xn2fHnTJuniOusUL9S3dUtbH+L7YjBo22qDlBXALt2s7i/Px99BOXzs/75
SqjfsV5VPlfVnXEQYDDwHgZ+dnOdgexoIabElxLkmZgcoa9Er3oe9fvoPEeboSp/VH3dZiVb5+z4
qn7quetvVZ6dcaqEz5njuHlUdq5odu2UuM76M7uhPrqJObOmzlwqfzx/j2Ci1tTaZeAQcX3kra/6
aMRIrFa8ExHBbvJXojibQydWxz9nnDvaqEYkKsCdXM5s3Bor8eyO4/h6Zk2djz1czcbJobKJfuZ6
Np47jvLn8/xqeb6aP04OsUF4wQAMfBkoE9et+Gw/YtD/vH+WgbH/9fZojJXN7Nfjyu8K35XQan0b
CT0ltCrzvZvnXsiufD9rrlntV7l2cp7heFQrxaDD+owh18ezatGKutUtbf+xhlEcZ9q4eVzZjT6q
0do78Yzy137cI+qnM+ebbaL5xB6hBQPvZaBUXAPSe0Gi9tQeBmAABmAABmAABv7ptfXf//MTEsQi
gQEYgAEYgAEYgAEYgAGfAW6u//28IcCQAxiAARiAARiAARiAgQoGENeIa5oLGIABGIABGIABGICB
IgYQ10WJrOh0GIOOGQZgAAZgAAZgAAbuzQDiGnFNpwoDMAADMAADMAADMFDEwOni2vmasIqvvHPm
+XSGVV+z5oxTHddovNFXzbUdsPM1hI5NVVft1qlqvspxzvzKuhWrkXqd7XNlvivGcv5ilvbr5mZz
7nzl3XdMZ56PreOzkxtnnOq4+vFGX0E4+07r1dcVOuM4OXFs3Do5Y51tc+ZXJ65YzdTrjK/nPLse
zHfv2+hI/U4X10rQOiLVDdAZy7Fx5lPjqOeZOfoxR3M4P8vaOD47NhW5ceaptMnkfifPqybEGXe0
7pz3sjaVua4cyxGYStC6Yzh+O2M5NhVzVcyj/vKX0RzOz7I2Tl4cm4rcOPNU2qhajDjfyfOqCXHG
bWOPjOWMfcf6VbLAWOeL+teL67Og2xWQs/fVuI44+gqvNhez947Il4rhiDl3xnRqUWXTiuJInhzx
3wvuSp938nuFd51bswo/r3To7/oye1+N64ijrxAcCbD+ZxV16cdQMRwx586YTi2qbFqRHsmTmt/l
om8S1Lg7eeXd80XqXXNeIq77WzV1SK8En/NrazfZSow4t4Efm+98Tly9b308zhgjv9R7s5wocd3G
NxPXMxu3DsrOqXnGZuT3qB7Rmjm1qLJRDY9b9yp/nHFUvX/1fHUb9vWptfn8+0jMrWyisSkx4tzg
tX4qYdHHNBJGzhgjv9R7s9woETXyeSSoormP2Ds1z9i49ZiJ/dmcTi2qbFTDs1P32RpcNT9OXJHa
Y4ugzjCwLa4rb8g+AShBHAnSGUuJhag4dsVOJI4+L63PTqOixOPIF0fMRmNwcpOtmWoiZmw5883y
59ZlVi/n5xlxrXLhzLtjU8XFEeOsxGz7zLXb9VGJ615EOmI/Ky4cX1bxzvKXyWVGqO7WIhNbVjh+
3+tzoxoNN0anFlU2GXHtxKlsdvx384gdwjrLwCni2hXgVxTXKwEVET4ZETcbX4lr5Vf//kpcf+PP
Aua85/ARuXFWIt4Za+X3jvCMvqtquRL+UX6ivkU4dDg4w8YVnhlBmPHfEbSOz05joOZSz1V8jthx
hVg/1mhux0b57D6PiOC2MejHVznum4rVWJlmwKlR1Mat6ayh6H8+ysHo3aifKvcuC9ghuB0GENf/
ZuAjElYixRERSjy7z2c3xuqGXQnKKpHmQBW1UeJaPR/FpmrqiOedWjj1cmwidVsx5sxVZROt/5n2
jlD9+IO4/u8DdCb8XNEUEWGOEHJsqthS4lo9H8X+eScqvpUQjdTCWQuOTXVdVzE4/jg2VVwwDkJ7
xgDi+iLiWi1SR/iMxlAfEYiIcuVj9rkSz+p5ZdxODE4tqmwQ17Wbt3vwIq7jeXdzq5oX57lr46xn
x0aJZ/V8NMcoX1UNg1OLKhvEdXytOMxhc++8Xlpcq9teBZ/zflQEOfZK7Dl+qTE+zx3R+RZx7cTp
2Cimvs8zuXfmz9w+z3zqY/mFz24+z7JzBIUSbrNfR2dicMSU47Pjk5rLGUPF6IrMiC+zOdUYytfI
cxWXej5jKvue43tmbEfw7zSekZo53O/k1ckhNvcWuL+s37a4bkVe+2v02cH+/XW9IyJGv9p3kzX7
lX77/sqm9W/2772oUaJ5lZ+quPqY+hzu5sX1M2KnfO4ZGzUWGQ5VvVQMVblU44zyM1obTjxqrlEe
R3lwxlH5O/v597BWh/bnuSuwv7aZWJQ/rQ9K9Chh7MzVz5eJSfn8HdMRaLs2Wf9H7/X5G9W9tVGi
r7dt53TmcmNz6l5hM/J5lSPlv/JJPXc5VH7wHHGdZaBEXI8Ea9Yh3gNmGIABGIABGIABGICBuzKw
La6dXzXfNTn4zcKGARiAARiAARiAARiIMLAtrj+T3fFXxJEkYcuiggEYgAEYgAEYgAEYcBgoEdfO
RNgAJAzAAAzAAAzAAAzAwNMZQFz/e/P+9CITHzWGARiAARiAARiAgXMYQFwjrmkuYAAGYAAGYAAG
YAAGihhAXBclkm7wnG6QPJNnGIABGIABGICBKzOAuEZc06nCAAzAAAzAAAzAAAwUMYC4LkrklTso
fKPDhwEYgAEYgAEYgIFzGEBcI67pVGEABmAABmAABmAABooYQFwXJZJu8JxukDyTZxiAARiAARiA
gSszgLhGXNOpwgAMwAAMwAAMwAAMFDGAuC5K5JU7KHyjw4cBGIABGIABGICBcxhAXCOu6VRhAAZg
AAZgAAZgAAaKGEBcFyWSbvCcbpA8k2cYgAEYgAEYgIErM4C4RlzTqcIADMAADMAADMAADBQxgLgu
SuSVOyh8o8OHARiAARiAARiAgXMYQFwjrulUYQAGYAAGYAAGYAAGihhAXBclkm7wnG6QPJNnGIAB
GIABGICBKzOAuEZc06nCAAzAAAzAAAzAAAwUMYC4LkrklTsofKPDhwEYgAEYgAEYgIFzGEBcI67p
VGEABmAABmAABmAABooYeLS4/p9/o/v8ObpT+86zmq/Cph9jJ7YKf9q87sb+GSsyRh/7KDer/JzF
xtHsXXn8SsZUvf78+fO3/ZPNizPOETYrf7/z9Ta9H6P4HZvZuNkcPvm9Csac/BzB2GfM0dzOXI7P
2JxzI0qe75FnxPVml9If+iMRUGHjjOsuugp/RsJ6JGaduVph7YwxE+IVc7k5xG69wTm1cGwUG5/n
vficiVFVM2eco2xmvikxV+XPd341n8rhG55n+XJzU1XTqnFcv7G7h+ijTufU6ZLiWt1SXQWOmZ/t
z4+0cW56+1xV+fMdd3U76czViyf3Nt5pNlY2d2Fs1MRchf+ZH07dHRuHDXWr2/u4Y++8u2Mz83Ul
5kbP+htKx6ZtUo4Wj1fnV/l3ZH52+GnfrRpH5YLn5wg18ny/PJeI69Gv5GeirrWNHs6jw3Ymxlbz
jMTv6sZ0JiAdgXCkza/FtWoinNiz4jErrvum4MhN62rrQvlztXXhsOGIiHacHXvn3R0bdXs9et4L
qiqb2UcIKtZL/zGEVTMwu0kfCcmRz2quUVMxi70fSzVDrj+t3Q4/iOv7CbCK9cQY16z7trjOipzM
zaEzl3MgtyJ9R2zNxOURP480FqvFdrRvs/wrIT6qiWrQ1PPVLXiGv8gm5rDq2DhzOuM4NldbF85a
ngmK6O2iM061jRJr3/idm+sdm/7daO4cRlexjObrRXXGZvVO1p9WjKumLZPHasZ6f6PjR2qL7TVF
HnX5TV0OEdejYlaImdHNW+b29moiIip4r9QQrG5DnbgcAeXy1LOQZaNqM3KYd2yUP+66cOaK5HDm
l1N3x8ZhwxELKn+7AsTxQd0qOuJ4FEc/bsZmdLubEYaRPKsbZUfwKxsnhowAV0LfbZqcWn3GugKf
Tm2x+Y2II+/XzPtp4roVtKsbxRUojjhwDmRXXM9EixK30VvaWVxqnGg+RnGPYnH86evk3oy6PqgN
w5nv1+LaZb7lTMXtNhpK+M7WoCOuz1oXzlqeCShHWLXjO+McaVMhrmc1r8pFhs3+HdcXx07ZqOe9
aP36mhHtzlztfDMBfiRjK5HurIWK+jPGNYUgdamvy6niWolS9TwqJiPiKjq2KxIdoZq1icQXya3j
D+I6thgdvpRNpi5KZKs6Kp8iYl81i+6acoSAI1Ki4zhjZm0Q1/93PTliVdmo578Q10rEZPnJCGdn
LuUvz2PnAPl6T74OEdeR26/s4azE4uqgHj3LiAh3nEw+Mu+0uYwI791b4Igoivi1qvGuz9l6u5tj
1r+j8uP44/Ls5CDDbyb2kUCqEqqZjww4/jjjOsJ/Jg77+jgi053Pqf3Kxo3d8VnZOHNlbJx33NqM
cqVuzh3GKm12a8777xGU1Po/td4W1+2BvPr19uhXyZlCuOP0dv1c7jiOj2quUY5WTYW6oVzl2fG3
yp9e/Lp+O7X4jDVqFmaxj+rZjzFjdWTn5nFl5zDm2Di+OONU2Tj+VDHm1nX2a3bX16+dM06FTT/G
579nolh9hMBpJpQQjcQfzakTV2tTkd9ZPG6eVz6PhGv7s9b/bK6qclA1TjYO3kNYv5WBEnF9x+Qd
fXN5x5zgMxsh6wIG2AdgAAZgAAb2GEBcb/4NjQC4ByD5u1b+ENfXqgfrg3rAAAzAwP0YeKW4dj7G
Acz3g5ma7dWMdbGXP/gjfzAAAzAAAx8GXimugR/4YQAGYAAGYAAGYAAGjmAAcc3HQv7r/0h1BGiM
yQYGAzAAAzAAAzDwBgYQ14hrxDUMwAAMwAAMwAAMwEARA2Xi2vn6Icfmah1N1VcZOeN8YldfmeWM
U2HjfFVYRa3c74x153Jid8ea2VX5PMrx0WukMj+jrzVrGXZjUcxX1cv1Z3e+ivd/wcbK7+h+cHRN
K3LMGNygwgAMHMVAibhuN1K1qarnRwWaGbf31RFVWZtelIz8PcsfJ4ZMPlcxtUIty4iTnwq/RyIt
4/PsncxYkbgqxldjXG1PiPgTyeVRtjN/Vd6P8qdv/JUf6vmRfjI2ggkGYODXDJSL6+8mHLn1+3US
HCH7tXEO6ajN6Lav98kRYlU2kXzs1q6/EesPcXf8VezuGK5dpc9unV3fHLsK4aPGOKvRceIdMaX8
d8c9ym7VbLbPjprf2QOunsMzc8NciDkYgIGWgUPE9Qqy1YY8Ei0z8fE9YEbj9eOMDqORzepAO1pc
j8ZvY68Szs44Zwq+WR36mqmaOgf9ipXIxljls5PnUaO2K64cBtoYRxyqteqK69k8/XpQdqp+jj9Z
xkY16htm5V9mz3TZiNRqlWcnh07cKs87ueJdBA4MwMAVGNgW12rjdgSEc0vi3j5VC6h+XnWQZux3
RPSv/KmCdyYQVKPjHvQqt44oXzE84z/K4cqPXvBkfFZ5mDV3jhB31q8Tn7NXZGNXvDj1cnOh5oqu
HSd33/Wi8pONwd1/M5cEyudovrBHXMEADPyagW1xPdp0M7cw/Y1H5WGXSfIRonU2piN8fuHPGYfe
TIjcRVzPbuocfpUQiQpel3NHrCnfFBsRgRnxx41RCXXHP8fGEZ0qVyqmSH5W3PVN2mrfcfiN+OXs
cSoPPEcwwQAM3IWBy4hr5yBzbHpR0Iq00QbfHjhK0PUHqXML5Ng4B48zTpVNtGHagT17iEdYWAnF
jPCp8tnNc8bH3Qb3KuJ61rxEmVO8RGva2mfGjvifFbGO8I80cCpOZx9z9+dIfrBFcMEADFyNgceK
ayUOVCGqhKozjnMoOeMcbaNylnkeFTURMfAVF1cV10o07TI8q4eaN9pkjuapFGIVeVD+RDlEXK+/
NtRtCF27zN7COwguGICBXzHwOHHtHJJustWB7N4MOeM4AsIZp8KmMocq185cjo1TC3ecs3x2mqFR
XMo/9bxaXKu8KgHl5mEnFysxPBt3tpa+P+//GW38VJ0ye0I/prMfOGunt7lCTd38YYfAggEYOJuB
bXE9O2BWt1nqMP3enK0O7Xbe2YGysnET7cRXYaMO7P6gdQRS1mbmy7cubu4cOyXMZnHPfFG1cPO8
8r3K51We+zWgxIyT61YgqTUYEXZ9LUZxzfzL1MuNdZedEWOOWHVs3BhW+VG5G8WvGonZnnm1mrr5
ww5RBQMw8AsGtsX1L5x2Dv5f+sXc91nMVaKVmt+n5tTqv2vFOoBf1gUMwEAdA7cS15U3QkBUB9Fd
c4mggIG7slvtN2uBtVDNFOPB1JsZuJW4dn6t/eZiEvt6M4v8aptccjC8hQH34yVvyQdxsvZhAAZ2
GbiduN4NmPdZNDAAAzAAAzAAAzAAA0cxgLj+B7iOgotxYQsGYAAGYAAGYOBtDCCuEdd/3wY98bLR
wwAMwAAMwAAMHMXAY8W18znCCpvo53hXX+O2Gmv1tW0tHFF/jgKr/3z8kfOs4h/N69T9+97q/+jl
jhMZw/lau9FXxDn+nlWDX8zj1OJMm5b/WT5mX3vX2+/w84tanLH2j9oP3f3ZqelsnTocOus5Mo7i
wGVRjaOeOz47NtH1tdozlc9Xe+7kx7F5cw7PqOkjxXW/Qa42zNUmpsZxxp0Jv9HPVwVfHbCRGM6A
KhpblU+qXqPNxBUuSvDMxlkdWi4/TlxnCJqqOlWP4+TnTBunFs56VuO4/FTn2x3PjdEdL7qvRPPj
rlW11iP78dH7TyS3R9bL3XuddarWhTtXJDdXsXXy49i8OYdn1fJx4trZ+KpsRkVSY0c3/NVGrQTf
aJM5C6yI3xU+qbyvcrGqSaRes00tcmg580X9rcjvVceoqnvVOP2h9RnXWaervcTx7ez15vAQ4d4Z
Lyquq/ZnR6w5NXJs+jo6+0FV7X9Rr3ZONz9tExRZX0fGF+U3Y+/kx7HZ2aPunsNM3rPvlIjrHvYV
8G7xZxvGaK52Pmf8Khv30FQbiANs1sZ5LwvPE+veH6QVh1ukBs58q/Eic51Z935PcNbg6BDo33PG
OdPGEYDRGjn+VwmsFRPOelcHtxtLdp9XTKv1FfVP5V3t/Uq4K38d3tycqNjbmszOvr5uR+QnMmZF
fqL56/e62T5GDp/9ee9tcR1Z/NFFET2EVsJotsnt/NxZuI4YUAeJIzL63K42QrVZOM/duu8eLo4v
R9V9dPC5czlszGrmbLqzvGTWjJtjJx+ujRIVrk876/eId526O+vdGcc9tN1cruyuut5nYm6UPycG
JTBnZ9hRLCmfnf3VrauaS53fmXmieXPWhTNmxZpw9zo3r8onJy7H5mo5VHHf9XmZuB4dGKsNbtTd
jQ6LaGIduKpsnM1mdpDO4nfGdDb4yDjRHM8OdWcTUYdXVhxW1dSplzOXs4GN8r6Tw9lmn6nv7J1o
ftTcjjg649B2aurYOHV3anzEOKoWTp5X+3wf12ot79bdXTu93cxH9/xy9l6HE2Xj5nk2jlNrt17Z
PXnGsIq938fUmbGq8U5+IjmM8uOMnYnLyW10bzk6h5lc3OGdMnHtbMyu4ItsypkNwlmsjk1GzLgb
lWPnxO6MkwHVHdfx0eFitHl9fqbedTYGh7fohuTYuwKhKoeZOitx4sYQ2R9GuZuJMWednmnj1H3k
T5TB2d7jrssoC864EU7V3qnWe5Y7FYfDysh35z3HxllvmXGcfDkMtnvuL9Zpdn0p3qLrQZ07q3yT
w2d/HORb+8uJ69kh6sLvbDxH22SFhLNxrGyih7abU2djno3lHrhXqfsRh5s60FXd3RwedYAo/5yc
KT4iOXL8iTZVVXtC1DfnkHZ8c8Y5er1nOM3WPbsnqfncXLuxRjl01pLro6q3G4PDdHSuEa/RuKrs
le8V5zk5fIegbut8iLhWi9ZdFGojVAf26sBRPo6ESuad7GaZmevX4tqZP2vjbIBVOXM2QmcuJXic
XDgcOv46+XNsHJ8dm2hckQPOmf9Im6q6V4/j1NfdU536HbnPV9XP2Z/7WHfiiuwboxzPmMiclY4v
Tp5drjLzreKKPMvkx4nLyY9j48zlrDnXRu0t0XFc/99kty2u2yJ8Ifr8c7ZpfZ85C221uagitb6M
/Bn5PRpzNU7/bBW/mm801iqHaoNXvqj8Oc8rfFZxOH60NlV1V/XKPF9tsrN6zRhz2JhxH82pM1fU
5qp1r+DHqVl27fQ1dcbZrXd/EF9ln3did2xm8UXiVmNE96jM/pKpc1/LzB4Vmfes9eXkL+L3ytZh
zLFx/XliDt3Y72RXIq7vFDC+vu/XM9ScmsMADMAADMAADJzFAOL6H2A7CzbmgTUYgAEYgAEYgIGn
M4C4Rlz/10d4ng498bGxwwAMwAAMwAAMHMUA4hpxjbiGARiAARiAARiAARgoYgBxXZTIo7ofxqWz
hgEYgAEYgAEYgIH7MIC4RlzTqcIADMAADMAADMAADBQxcLq4dr4ibvY1XZGureLratr53K8oWvmu
4nJy8/Wpwp9IPs+wVflxfKiq+2qc2Vetzb76Tn3tnFN3ZVP5VU9Onlc2ytfd8Ufvn1H3fu0pXiN1
d9dzH/uV6h6pq1MvZzxnnDvafGJXfLk2Ko9nrteKWrjMO3Op3FzxuRPXmTZXzNEVfDpdXDsbgrOp
OIe7I0RXNqPD1BXcq0NwJQ4cKFabYZ+73Vw6/lTZ7PrqxF5hE/FTHVztWEqMzfK8EmZVtYmOE8lR
dOzZ2tpd7xVsqD3D2f9mNhn/dnN7xPtOHM68zjh3tGnr//FfrfuVjcqjs/+oMdznFbVw9zpnLtfv
K9k5cZ1pc6XcXM2XS4rrnSQ5AsWxGR2Szia2WvyReZ0NdeTPbP6dnN7hXSe3R9usGqoZO2ojdESq
e+CcWUfH7wp/jq6pIz5mNXR8i+TAyaljE5mz2rYqJ844d7TphbXaN3brPWK3uuarhjKzvjLNtdvU
HhF71ZhX47kqrqeOUyKuv0Vv/zlKWG+nbNTz0XxVAPaL0d3EVnaObyvQohvRbGOugtmpu2PTHyi/
rLtTI5eFvkFbxTWzdeY6W1w7NVVrfcTyiNfRXK3dTr0y62nlozr0HR5UU+3uD1VrvB1H1d2pqVOv
kcAciUBVC2euq9mM8n1kzSP7y+p8P2udZvbQnXXnrKM+L6v9+Ao5rGLeyc2bbbbFtXuwOwdZxSKY
zbPzc7frVRuVgnolSKKHi/JlF3qn7o5N9DBxxMdOrSPvrurlxqXqqg6tfs2sNu/dms/Wgaqz4n5n
3UfqtWqYq8Zx6u7WNJKXK6z3UZO84jtyJqwal6raXWEch5+ojdozV+yote3uKVW5ne13s5zsMObE
pvbvyJ6p5qvKYdU4yt+3Py8T16MDY3Y4qINAPV8VrQqc2QH4+flofsdnV2SMFqTrTx//UYBn/FG+
ODlUB8XZAsoRQJHDK7NZVx2Aqj69eOoZWB36jo+Z+lev911+ssInsjeshKZTw4yNWxvFr1Mvxz9n
nDvaRPlx6+Lsmzs2qmZVtXDOXmcu5a/7XPHunA+ZuZwYj7Zx/X6rXZm4dgXvSDhGDouZqFMQz0Bz
N7OIQIpuUo7wcHO0u9m6CyEyT1uzCCej2swEnSNOqmycDT7LlbNZZ2zcuio7t+4ZH1fr4Ap1d/hx
6+6sZyfXjo2qqfPcnUfZuTk8a593/DnTJsqPyreqrfu+2sPPqpez9zr1Unlxnzv7XK9NPu+s4rjj
Xufm6012txPXqjjOwnJsnMNPCXp3jKeLazdP7kbvbLCjOZ26OzaR+T+2q7jU5uyw4diodeM+d2uk
4hrlxR3bESDtWE5Nq2wc3xx+nFw4Nm5dlZ07l7Jz8qx8Wa2pX9XdicuxifKj8q1yGX0/aq/2/mi9
dtZO1vdVDp19ztUB2VpFc+hw6Ngof9/+/BBxrYBTkKvnqmhq/szBHhFIM/8iwKocRMZS+co8dwSd
YxM9THY3ugo2KuNSG6Mzl2OTqbFzkM2ETkWeXZ+r5qoaJyIoZrZOTR0bN4fKzp1L7VuZvdfdTx0f
72Cj+Dlyz3SEoFNjZ+/I1MJ5p5Kx6LrI+qfmOXqfcPzO1t2N7Wl22+K6Bfmb/M8/Z4v0+0yJw91C
tr6M/Bn5rTZx5bP7/grkVQ77BTYTA7u5cyHvc6zqvvLLqZfjlzNOhU029jZHzhiZ9XV0/R2/q2yc
mrtruaLuzlyj2Pu1ofIzG0Pxc2Ttoz6vaufUwqm9M87dbLL8zM4591xy7aLzjJqBnbNAcajOSYer
iI3jj2Pjznk1nl2/32ZXIq7fljTi/Ye/IrXor0h9M0tHCsE355XY2Z9g4DcMsKf9Ju9X5B1xjUhC
KMPATxjgIOIguuKhiE9w6TLQ72HsabDzZQdxjbD6ibByNy/snrlZOb/apPbPrD11pa5PYoC9DJ5H
PCOuEdeIaxiAARiAARiAARiAgSIGENdFiXxSJ04sdOIwAAMwAAMwAAMwkGMAcY24plOFARiAARiA
ARiAARgoYkCK68qvkPl0QM7X+PB/Csh1Sm2tnG7zqXmexfX0/LjxOWvQ4cexcRg72p/IV5v1MbX+
K66cfGCT29vIG3mDARi4EwNLcT06TJzDcpYA913X7k6JPsvXSO4itmf5XzGP8x2qzjx3zI/yWT13
8hKxUfOp55G5Vrbq/9U/akz6nzk2Vf4yDkICBmAABu7LwCXF9dWAOksAVMR9J18r4o2O8fT8qPjU
82g+d+3P8icirkc33d/fus1uwY++fd/NM+/f95CmdtQOBu7HwLa4Hv3atD9onF/LfuEZ3Q61YM0O
vv79/jDs4VTjjObMAt7PNfNl5fPq1myVn5nPu3meiY1ojhx+InNF47p6fiKxt7YO7yNBqNaFW6/M
+sv44/KGuL7f4eTWFjtqCwMwcDUGtsX16ECf3Ua5t1SR90e27kFaKaDdwrqxzWJQjcpI/CgBuRL7
o6ZlJuLc+qr5VP1WIjLyTPnr1spdA2q+UZ0cviMcr3xw5+obmOiYrr+uP87ayzQNfV1naytTV8dn
bBAMMAADMHBPBl4prpUAq4ZZHeyOOHMPdkeYzgTz6ueVQqdCXK9qFBF7Edtf5GfWTI1ueR2uo/E6
dY+O+UtxvdNoRpqt6j2E8e55wFI36gYD72TgteK6FSIzoVKxKFyxq+yuKK6rchiJ3alJROxFbKPi
uiI/0VtRZR+N1xHX2UZHNQO7c7sifuXHbN1FxnaYxeadBzB1p+4w8EwGXi2u1Q2u+zwiLtzbr5Xg
XB34Sqg6oiAjapSo28lRdOyIgIzYZsT1LkOVsVeJ2YhPyjaafzVe9GZa1Qdx/cyDD0FDXWEABo5k
4GfiOnqozoSBIwQdwZnxxymMM/cotquLayfvTn6isSsxFBWQmbo7sTs2Tn6i4yjxGWnMImuuQtQ6
a0XFV+HHrAF1G2OnrthwsMMADMDAcxko+UtkvodO+091yH1sRzb9WL2NM1fkkHZ83l0A/RwrwTTz
ZyaKZrGquCrzrOZS+YvUVM1VEVcrKpWgWvnjxKVyM/Ilu3b6xmQ0jvJZ5XckTJUgPjqHjs+qzqum
TcXn1Bib5x6y1JbawsD7GJDi2oGCw2UfnDfn8M2xO+sLm/31RQ7JIQzAAAzAwFkMIK6L/h753YK9
WWC+OfZdbnifwwIGYAAGYAAGrsXAtrh2fuVK0ddFf3MO3xw76+JamyH1oB4wAAMwAAMVDGyL6won
GAOYYQAGYAAGYAAGYAAGnsAA4voiHwt5AkzEwKYIAzAAAzAAAzDwdgYQ14jr4be2vH1hED+HAwzA
AAzAAAzAQIYBxDXiGnENAzAAAzAAAzAAAzBQxADiuiiRmc6Gd+iIYQAGYAAGYAAGYOBZDCCuEdd0
qjAAAzAAAzAAAzAAA0UMIK6LEknX+ayuk3pSTxiAARiAARiAgQwDiGvENZ0qDMAADMAADMAADMBA
EQOI66JEZjob3qEjhgEYgAEYgAEYgIFnMYC4RlzTqcIADMAADMAADMAADBQxgLguSiRd57O6TupJ
PWEABmAABmAABjIMIK4R13SqMAADMAADMAADMAADRQwgrosSmelseIeOGAZgAAZgAAZgAAaexQDi
GnFNpwoDMAADMAADMAADMFDEAOK6KJF0nc/qOqkn9YQBGIABGIABGMgwgLhGXNOpwgAMwAAMwAAM
wAAMFDGAuC5KZKaz4R06YhiAARiAARiAARh4FgOIa8Q1nSoMwAAMwAAMwAAMwEARA4jrokTSdT6r
66Se1BMGYAAGYAAGYCDDQKm4/vPnz3bX8xmj/ZMJ6hfvVMR+lt99jnvfR8+/P/v62P/36Ocjm9l7
q9ij48xqMYurnVvl5mPr2PT5UPmaMT/6eSaHfYyjfK/qPsrpDvMOY856iLLhjOnY7OxREX5a3hy/
epsdP6NrMrs2XBZXsWXXhFqXs5h22P+Omaln9J1sXqLzYI8AhYH/y0CZuK5YxK6Au1oRK2I/KyZX
jKharETf9+Bx51KxR8ZRYkLF1YuZyOE7i8MZY9W0OD6rHI7E/kysODlQeVb+RGoaFXlnrcededp3
1TjqeSbX6p1ozmdNgGJ/JFIdNhwbJ0ZnHxvFtlOTnXedmFbrOvM+7yCcYSDOwGXEtdqEr1zcO22W
7qE0sxuJtPaAUqIhk6uMzy5PzthZm5VgjoiRKnHt1GbmcyuC1DjZtXokG1mfMiLTmauqppm5nHei
jWKGZ3eNzsauEJGjvWsluNWadnKb4dwZ9yhWd+fm/bgwI2f3z5kU1/3mM9vQonbuxhjdiJyNsd2s
V+PPRKMSmE6OWpuRWGnFjJsrZ0E6QrE/zEa+OIeSO5fy2xnHsRkd0s57WRvnIHb4rhCzTgwzJtXP
nRhUjV0B5ayFVayOoBvtIaMc7MTtiuuoL6u16vCo6uTsl4oX5UeU1Sw7o3Ngdo6pejk+z/bM6Hkx
8xtxfX9BptYfz+9TYymudzfKEQxqI9oRE47o2z2gnfdXB4g6/HcOC7X4VO57vyNiZCTK+8M+I0hW
Nd3JsxPbrBbqsHXXTX9QrtZLJnfR/BwhfBSTO7w7bLjrtReyaq1U1iMqWl0unTXp1EdxMds3RmLf
GcsVojvsrHIzW9+zZkex4u4HzjiOjct8pPbY3kfYUavf10qK69Em5wrm0YbibE4V4lodKk5c7uHp
HIxqvohY21k47sbc18DdrFXt3Jyqw8g5/FSsVxHXSmz07GTqHxWhKjcrnqvmcuJUNY6IPrUG1fO+
UVrVzRlLceEKywp+sr44e2O2zm78q/EV57O4nfq5Y6tz0mU8E6eTe2x+L9Sowf1qsBTXzgaS2XQj
m0VUjM3E3Ur0OQfAx2YGuPO+WhzRONV4EV8j9VD1/rW4zory1XtOfioYmIkFlVOHBScGlTvHP8cX
Zx53HCcudx9Ta9Adx/E9Mpbr12yPeqq4VnnJ1CErph0O1d4ZbRbauqpYK3Kl5uD5/QQgNTuuZojr
5qvVsp1/hbCKbH4R2z6mXqhFBFN7eM98UEIw47tzcDk2o1id97I26jB1xnV9VpukO1eVz8ofNc/O
+0q4OuyO5lfjuj5Ha+quGScud6xZLNG9Lmrvzrsbh+JP1Vo9XwnlqpyoGCqb2Ajb2B4n2MjtfXJ7
iLhWG49zCES7+NFGMxN6yr+I4Oxtq8d2DvnIghvlxBFeTlwqFxU1nR0oTgyuqFENghOnc7BV+qwY
cOdSB3Z0nIxf6h2VW8Wqu//0fqhxs34roRjx16mPmk/FseuPYkzlPbo/r+JxY1G1d/Kuzig3rshc
2T1XMcDz+4g8avWbWoU+c60W6nfRf/452yC/z9Smlj0AooJ65U8bj/LHjX21Mao5qhaJimv0XB0u
SvSu8qPicg6TiE3L5yyunXqOxJ/Le792Rn5kOHHy09fQfSfjT1RgzRiJ+jhb7z3zaj61jzmCzlkT
yq/IWq7K+eocUP60765iy8Sd4VCtS9ffiF1vuzorlX+KoUxO1H7M89+INfJ+r7xLcU1B71XQaL3Y
fJ9d3ygP2MMDDNQwwN5ak0d4JI93ZABx/e9nru9YuCqf1c1H1TyM827OqD/1fxMDCGt4fxPvxPrf
vCOuXy6uWRQcAjAAAzCwx4DzcRhyvJdj8kf+7sQA4hpx/eqb+zstVnzlcIEBGIABGICB6zOAuEZc
I65hAAZgAAZgAAZgAAaKGEBcFyWSTvL6nSQ1okYwAAMwAAMwAANHM4C4RlzTqcIADMAADMAADMAA
DBQxgLguSuTRXRDj02nDAAzAAAzAAAzAwPUZQFwjrulUYQAGYAAGYAAGYAAGihhAXBclkk7y+p0k
NaJGMAADMAADMAADRzOAuEZc06nCAAzAAAzAAAzAAAwUMYC4Lkrk0V0Q49NpwwAMwAAMwAAMwMD1
GUBcI67pVGEABmAABmAABmAABooYQFwXJZJO8vqdJDWiRjAAAzAAAzAAA0czgLhGXNOpwgAMwAAM
wAAMwAAMFDGAuC5K5NFdEOPTacMADMAADMAADMDA9RlAXCOu6VRhAAZgAAZgAAZgAAaKGEBcFyWS
TvL6nSQ1okYwAAMwAAMwAANHM4C4RlzTqcIADMAADMAADMAADBQxgLguSuTRXRDj02nDAAzAAAzA
AAzAwPUZQFwjrulUYQAGYAAGYAAGYAAGihhAXBclkk7y+p0kNaJGMAADMAADMAADRzOwLa7//Pnz
d/Sndfz7vA+m/flsnM/Pd5Iwmrudyxnb8cGxcea6ms0srmgOd+I6c66e2x2/z353ts7O9uM7X7+m
R344No7/kXF28xSZa+W7Gkftq2fm2dnnK/1xY3fY+NiomqtaROdZnTurs3F1Do724lVcFTl06h45
31ca4Bf8nFH3lj91ljn+ODYur9gd12Rsi+vRxtUvNmfxOeNEQXA2HjWm2pSdjVvNcdXnKnb1vDKu
M+e6c03PztOsxs4e4Ng4DEXGUYebmi8ylyOse0Ex++8Zk44/jo2K292fI3O558LuelQ1j/icydNI
NDp1b/1aiXVXdGf3BpWfUX77nzk2VYytcuU0Nk6NI+NU+qNqEfUd+5uL6+yi+b6XAUBtJOr56pDr
/XHHcuKIjjXaWEf+OXNH44r6mvEhUoed8aOxV85VPdaZdRn57ogmx2Z1gCkulBhx1o3LRDTfq9hX
cbkHqxJlWbGq5nficmoaYUqtnVbUuSI0mx+XyVV9Wh9H+e7niKyjKKezeGYc9LkexenYrNZdJN6I
AFa1m3HmMO+Iaycux0atB54fJ6b73Mqb63YxzDYdtelmNoTM4RfZuNUBtNoEZvGoRdTncvcQcTZL
R2T0uXZi71lQC38W+2wDnm2wq5hHfqtxsrE7m5TyJxO7c/A7XDj+Z20UC6sYnHeddb7ak7L5ifoW
PZBVXNF9NpPnVc3V/NG8uvauXcR3JaZ25lScqH1B+aY4cc9pd327dV+dG7Nnoz2wWlyrc9nJ59PW
slt77PJifCmu1aJaicwMjP0C3Cms2hx7sac2xMzGPdsklW9O3M4Y7qaSjV3lMDr/x945GKLjrg6r
bOyqRlEfZ7G7a3DngFCxRJ/PDszoz515M2M6a2c0tzNX1GdnX5nti44/jo3jc7su+3UfEYNRTrO1
Wgm0mQ+O0HNy5ewpzlnnxL6y6edwxltx79Td4e1oG4cxx4edWs/4u8padmLDJi+sP7krFddOMZzN
4LuRO+NlRPxIwDkb4tFzufE6m6SKZ7TxugfS7DCdCUE1lyMglc0oXvXOiIOsUHByl/HRicGZ22Fr
dhh/fu68P8qdc4jtiJrI+IpDFaMzlxpjxZx6d8WC49tOnh2/nX3JET5Va9CZy8mbqou7/lb742gO
J5+OzW4+1RzqrHH3WacWjo0Tb2ScVf1VblzN4Pjj2ERZxX5PQK/yd6q47g83d1PKAKCgd0WLGidz
6DhjuosyuilH5la2KofqfWcTnNmouUd1GfnjHAxV/EXmd+OO1j8TS/QdJ6eOjTNvZhyXS3d/io4X
tY+yMDuEHbG5IySica3so2MpVqKc7MwfmWs3BxE/I7YRVpx4z7TJnMmRsyiSG/ccr8qPWgc8P05M
97k9TVxnxNB3kWSAUBuJ44+zSB0bdy41lopJve88j2wcKi7HX9enzFzqndXcru/u5jmbS83jxOCK
wMw6yrxzxEHhjOmyq3IeqanLr+Pbx6+IuHVy4ti4NVZ5W801mqPSNxVDdC4Va6ROK+GGuP7fr/J1
92Knjk7tnHEUU8rnCCOOP46N4zM25wjsU8S1C0VGSEQAXh1wjo9Zm0hczhzRw18d7M6cIxsVl/OO
K04q5nL96X3KHIDuXOogUHFfTVjPhISTj0yeR/xEcxrJYbQe7lrN+uz449g4B67yMVoLZ99ZCVPn
mWNTlR81l7MG1F4dYTU6lsuq60Mbr1trpxbKxs2zGsdZE1HmlSD/+BRpxpw16caBXa3oDn1byAra
zME4Wnzfn7X/3Cm68lltiO1iaMGfbTAjm4qYVnO3MTi5ivgzq8Po5yrXznO1wa+4cOJybHomnLqP
/FZz9c93Yl9t2g4TR9g48Tk2jm/uOI6dOrCcMSp8dudx7Byblc+R9x3blc1o3axq4jxTPqnnTj37
s6LfN1b73+o8Ge0/sxyNBLXiebfus/Hbnzs2o313tvdW8XNG3RUX0ZpV+ewyjV1OdEtxPSo8yY4l
e2dzI9exXD89X7AED09nnPhgHAZg4O4MlHws5O5JONp/BBEbRZaxnh1YgqUsS7wHOzAAAzBwDgPy
5ppfQewVgvzt5Y+N4J///3/4af+QE5iCARiAARiAgesyIMU1xbtu8agNtYEBGIABGIABGICBazGA
uP73b9IBSnIAAzAAAzAAAzAAAzBQwQDiGnFNcwEDMAADMAADMAADMFDEAOK6KJEVnQ5j0DHDAAzA
AAzAAAzAwL0ZQFwjrulUYQAGYAAGYAAGYAAGihhAXBclki7z3l0m9aN+MAADMAADMAADFQwgrhHX
dKowAAMwAAMwAAMwAANFDCCuixJZ0ekwBh0zDMAADMAADMAADNybAcQ14ppOFQZgAAZgAAZgAAZg
oIgBxHVRIuky791lUj/qBwMwAAMwAAMwUMEA4hpxTacKAzAAAzAAAzAAAzBQxADiuiiRFZ0OY9Ax
wwAMwAAMwAAMwMC9GUBcI67pVGEABmAABmAABmAABooYQFwXJZIu895dJvWjfjAAAzAAAzAAAxUM
IK4R13SqMAADMAADMAADMAADRQwgrosSWdHpMAYdMwzAAAzAAAzAAAzcmwHENeKaThUGYAAGYAAG
YAAGYKCIAcR1USLpMu/dZVI/6gcDMAADMAADMFDBAOIacU2nCgMwAAMwAAMwAAMwUMTAUlz/+fPn
7+hPhar/5RizuD4/H/n1tV89a8fMxlYxRnbu9r1f+THLf0VMjMFtBAzAAAzAAAzAwBkMyJvrXliu
hOYZDlfN4ca1EpqjXGTz076XHaMqN59xzvbh7Pkqc8VYbNYwAAMwAAMwAANfBhDXza8A+pvT/obb
WThZkTgS+858R9lk48j6c/Z8WT95j80TBmAABmAABmBgxcC2uB7duI5+ve98vKTKxoG+93v1jiv8
XLvVx0scP2a36W4tIvnZ/UiMqunoeebjIaOcrH6zsJND97ceTp6xYYOGARiAARiAgWcxYItr5+MR
X1HkiI+jbFxAI7fSjmh2bGa+Ob6shGI7bl+nrF8joT6aZ/Uz1+eKj6HMRPoRcTjsuhxi96wNlXpS
TxiAARiAAVtcOzeqX5uZ+HBvMSNzZSGuvLnOClglVtVzR7xmfVMCMjv3zJ+snyPmZoJ6JcAjTYLK
TZZJ3mNDhgEYgAEYgIH7M3CIuO7BiAin1Q15L6S+N+UZEDM+jeaJjLPTNDhituIGWDVIs+ejuV2f
K/xWgjoyhxLP6nmGR965/2ZKDakhDMAADMDAh4HLieuVeNsR7TvvHnXbqm6m1fOIeI0ueCUgnbkd
m0i93ebEEdruWE7TUNVgRWuEPZs4DMAADMAADFyPgZ+JayXeHFETuY08S1xnhZZ6zxWqahx3Ear6
OP44NiNxnYnBEdSuP9HYlb/quVsT7K63gVITagIDMAADMNAzEPpLZEYAtR/jWH1Mo7cb2VbZKNB3
fG79HvmbEVI7/oxutzM+zJqP1rejbHqBveJoVltHXLfNmBPX6la9f3+V84p6KKZ5zuYOAzAAAzAA
A9dgQN5cU6hrFIo6UAcYgAEYgAEYgAEYuD4DiOuiv0ce2K8POzWiRjAAAzAAAzAAA0czgLhGXP89
GjLGZyODARiAARiAARh4CwOIa8Q14hoGYAAGYAAGYAAGYKCIAcR1USLf0o0RJzcPMAADMAADMAAD
MDBnAHGNuKZThQEYgAEYgAEYgAEYKGIAcV2USDo4ungYgAEYgAEYgAEYgAHENeKaThUGYAAGYAAG
YAAGYKCIAcR1USLpVOlUYQAGYAAGYAAGYAAGENeIazpVGIABGIABGIABGICBIgYQ10WJpFOlU4UB
GIABGIABGIABGEBcI67pVGEABmAABmAABmAABooYQFwXJZJOlU4VBmAABmAABmAABmAAcY24plOF
ARiAARiAARiAARgoYgBxXZRIOlU6VRiAARiAARiAARiAAcQ14ppOFQZgAAZgAAZgAAZgoIgBxHVR
IulU6VRhAAZgAAZgAAZgAAYQ14hrOlUYgAEYgAEYgAEYgIEiBhDXRYmkU6VThQEYgAEYgAEYgAEY
QFwjrulUYQAGYAAGYAAGYAAGihhAXBclkk6VThUGYAAGYAAGYAAGYABxjbimU4UBGIABGIABGIAB
GChiYCmu//z583f05+iu7DOnmuPrl7I743mbozPm25ljlLczcrmToyiDO/Hs+LlTF97lpgMGYAAG
YAAGnsGAvLnuhcqOcHGgccd37Zw5d2xaP67i0yqeX4nrj087+YnkeWeeXT93WOLdZ2yq1JE6wgAM
wMC7GbituL4KuKPm4yq+jfx4grg+WgDvivMr1x/f3r3hU3/qDwMwAAPHM1Airp1f2yubyEdQVr+6
H91wjj5m0o+RFVTqvYw/KwHcxqLm3hHXfT36sdy4WiGc8fc7r/sbFPWxDsXhSLjv+M0mdvwmRo7J
MQzAAAzAwJUYsMX1TLQ4N6GOzUxEzZK1EjxKiKnnboGUAO1j+gpjZ/6ZTaQJWYlrR2SqmjgNykiE
u/lt7Zycuf6uxu3FNcKaDTvDK+/ADQzAAAy8lwFbXEduEB0hNBMtrpi5grh2P56g8uE0HzOR6uZr
JTxX869ugqNxRX2tFtfReu34y6b63k2V2lN7GIABGHg3A4jrwv+jXeaWfSb4VsJ15zY4KuRXglSJ
TyW+I5tPZCzXr+9vEno/3N9IRPzH9t0bLfWn/jAAAzDwHgYQ14jr//oWD1fIuiJWfVzD2XBcn9zb
abdpUDE6vmPzng2VWlNrGIABGICBS4vryEc/Ih8hiAg1tUgc8aVsorfJb7+5zuTT/Q3ByC7LYaSp
UDEpDnnOZg4DMAADMAAD12Cg5C+R6X+NPvp1u2PTi5Hsr+0d8RzxR33cwxFfSjwpf2aCWo07+8jD
qhlpBea3BrOcqvnbuCK3yiP/+rFGdVEf6XDz3LLn1He1oakcZfPCJnqNTZQ6UAcYgAEYgIGWAXlz
/QZgHPHzhjwQI5sDDMAADMAADMAADOwx8Epx7dxsA9YeWOSP/MEADMAADMAADLyRgVeK6/5jD7OP
n7wRCGJmI4QBGIABGIABGICBPAOvFddAk4eG3JE7GIABGIABGIABGBgzgLj+96v4gIMcwAAMwAAM
wAAMwAAMVDCAuEZc01zAAAzAAAzAAAzAAAwUMYC4LkpkRafDGHTMMAADMAADMAADMHBvBhDXiGs6
VRiAARiAARiAARiAgSIGENdFiaTLvHeXSf2oHwzAAAzAAAzAQAUDiGvENZ0qDMAADMAADMAADMBA
EQOI66JEVnQ6jEHHDAMwAAMwAAMwAAP3ZgBxjbimU4UBGIABGIABGIABGChiAHFdlEi6zHt3mdSP
+sEADMAADMAADFQwgLhGXNOpwgAMwAAMwAAMwAAMFDGAuC5KZEWnwxh0zDAAAzAAAzAAAzBwbwYQ
14hrOlUYgAEYgAEYgAEYgIEiBhDXRYmky7x3l0n9qB8MwAAMwAAMwEAFA4hrxDWdKgzAAAzAAAzA
AAzAQBEDS3H958+fv+pPhcJnDDpFGIABGIABGIABGICBJzCAuC7qUp4AAzGwqcEADMAADMAADMDA
HgN8LARxza+BYAAGYAAGYAAGYAAGihhAXBclki5vr8sjf+QPBmAABmAABmDgCQwgrhHXdKowAAMw
AAMwAAMwAANFDCCuixL5hE6LGLgxgAEYgAEYgAEYgIE9BhDXiGs6VRiAARiAARiAARiAgSIGENdF
iaTL2+vyyB/5gwEYgAEYgAEYeAIDiGvENZ0qDMAADMAADMAADMBAEQOI66JEPqHTIgZuDGAABmAA
BmAABmBgjwHENeKaThUGYAAGYAAGYAAGYKCIAcR1USLp8va6PPJH/mAABmAABmAABp7AAOIacU2n
CgMwAAMwAAMwAAMwUMQA4rookU/otIiBGwMYgAEYgAEYgAEY2GMAcY24plOFARiAARiAARiAARgo
YgBxXZRIury9Lo/8kT8YgAEYgAEYgIEnMIC4RlzTqcIADMAADMAADMAADBQxgLguSuQTOi1i4MYA
BmAABmAABmAABvYYQFwjrulUYQAGYAAGYAAGYAAGihhAXBclki5vr8sjf+QPBmAABmAABmDgCQwg
rhHXdKowAAMwAAMwAAMwAANFDCCuixL5hE6LGLgxgAEYgAEYgAEYgIE9BhDXiGs6VRiAARiAARiA
ARiAgSIGENdFiaTL2+vyyB/5gwEYgAEYgAEYeAIDiGvENZ0qDMAADMAADMAADMBAEQOI66JEPqHT
IgZuDGAABmAABmAABmBgjwHENeKaThUGYAAGYAAGYAAGYKCIAcR1USLp8va6PPJH/mAABmAABmAA
Bp7AAOIacU2nCgMwAAMwAAMwAAMwUMQA4rookU/otIiBGwMYgAEYgAEYgAEY2GMAcY24plOFARiA
ARiAARiAARgoYgBxXZRIury9Lo/8kT8YgAEYgAEYgIEnMIC4RlzTqcIADMAADMAADMAADBQxgLgu
SuQTOi1i4MYABmAABmAABmAABvYYQFwjrulUYQAGYAAGYAAGYAAGihhAXBclki5vr8sjf+QPBmAA
BmAABmDgCQwgrhHXdKowAAMwAAMwAAMwAANFDCCuixL5hE6LGLgxgAEYgAEYgAEYgIE9BhDXiGs6
VRiAARiAARiAARiAgSIGENdFiaTL2+vyyB/5gwEYgAEYgAEYeAIDiGvENZ0qDMAADMAADMAADMBA
EQOI66JEPqHTIgZuDGAABmAABmAABmBgjwHENeKaThUGYAAGYAAGYAAGYKCIAcR1USLp8va6PPJH
/mAABmAABmAABp7AAOIacU2nCgMwAAMwAAMwAAMwUMQA4rookU/otIiBGwMYgAEYgAEYgAEY2GMA
cY24plOFARiAARiAARiAARgoYgBxXZRIury9Lo/8kT8YgAEYgAEYgIEnMIC4RlzTqcIADMAADMAA
DMAADBQxgLguSuQTOi1i4MYABmAABmAABmAABvYYQFwjrulUYQAGYAAGYAAGYAAGihhAXBclki5v
r8sjf+QPBmAABmAABmDgCQwgrhHXdKowAAMwAAMwAAMwAANFDCCuixL5hE6LGLgxgAEYgAEYgAEY
gIE9BhDXiGs6VRiAARiAARiAARiAgSIGENdFiaTL2+vyyB/5gwEYgAEYgAEYeAIDiGvENZ0qDMAA
DMAADMAADMBAEQOI66JEPqHTIgZuDGAABmAABmAABmBgjwHENeKaThUGYAAGYAAGYAAGYKCIAcR1
USLp8va6PPJH/mAABmAABmAABp7AAOIacU2nCgMwAAMwAAMwAAMwUMQA4rookU/otIiBGwMYgAEY
gAEYgAEY2GMAcY24plOFARiAARiAARiAARgoYgBxXZRIury9Lo/8kT8YgAEYgAEYgIEnMIC4RlzT
qcIADMAADMAADMAADBQxgLguSuQTOi1i4MYABmAABmAABmAABvYYWIrr/iH/TQbIABkgA2SADJAB
MkAGyICfgX98UyzJABkgA2SADJABMkAGyAAZWGUAcQ0fZIAMkAEyQAbIABkgA2SgKAOI66JEMgwZ
IANkgAyQATJABsgAGUBcwwAZIANkgAyQATJABsgAGSjKwP8DrVX41Lf8qLIAAAAASUVORK5CYII=
--bcaec53aeea4c3bde804b63c10a0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--bcaec53aeea4c3bde804b63c10a0--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 08:03:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 08: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 1Rkt9b-0004uC-U6; Wed, 11 Jan 2012 08:03:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yufang521247@gmail.com>) id 1Rkt9Z-0004u4-QA
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 08:03:26 +0000
X-Env-Sender: yufang521247@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326268976!55187226!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26026 invoked from network); 11 Jan 2012 08:02:57 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 08:02:57 -0000
Received: by vcbfl11 with SMTP id fl11so1477768vcb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 00:03:22 -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=9BlD1NvtMUpojebU1LKt+jAQl57ww52qavKnPrBRoQQ=;
	b=ZcuPM2VW+Y/WvdhxH1HaQhO/BBSiFxEPGYrLRK7e1YAaqjH0xG6/ZBSNG99fEXRtuJ
	aV81KyKl2D6niCH6d0yE/Rfuuwyq1/DFJD/uHA555zN0pbei8hXYVRyP/b8as/cNQGVd
	LMlL+TbakYUgkRtVi6QPBtA9s0SsJ2BWjkx9w=
MIME-Version: 1.0
Received: by 10.52.156.101 with SMTP id wd5mr10868585vdb.1.1326269002399; Wed,
	11 Jan 2012 00:03:22 -0800 (PST)
Received: by 10.52.171.45 with HTTP; Wed, 11 Jan 2012 00:03:22 -0800 (PST)
Date: Wed, 11 Jan 2012 16:03:22 +0800
Message-ID: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
From: Yufang Zhang <yufang521247@gmail.com>
To: xen-devel@lists.xensource.com
Content-Type: multipart/mixed; boundary=bcaec53aeea4c3bde804b63c10a0
Subject: [Xen-devel] Cannot start up HVM guest when maxmem is not equal to
 memory and HAP is enabled.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--bcaec53aeea4c3bde804b63c10a0
Content-Type: multipart/alternative; boundary=bcaec53aeea4c3bde404b63c109e

--bcaec53aeea4c3bde404b63c109e
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

On my production deployment with xen-3.4.4-rc1, HVM guest would not start
up when maxmem is set not equal to memory, unless HAP is disable(hap=0).
The guest just hangs at 'Booting from Hard Disk...' as shown in the
attachment. I find that both Oracle VM and Fedora have the same problem per
the following links:

http://docs.oracle.com/cd/E15458_01/doc.22/e15443/toc.htm#BABBIBFD
http://docs.oracle.com/cd/E26996_01/e18546/CJAGDAGB.html#id419003
https://bugzilla.redhat.com/show_bug.cgi?id=645319

Could I ask if there is any work in upstream/xen-unstable to fix this
problem?

Thanks.

Below is the xm dmesg output related with the hvm guest:
(XEN) HVM3: HVM Loader
(XEN) HVM3: Detected Xen v3.4.4-rc1-pre
(XEN) HVM3: CPU speed is 2267 MHz
(XEN) irq.c:243: Dom3 PCI link 0 changed 0 -> 5
(XEN) HVM3: PCI-ISA link 0 routed to IRQ5
(XEN) irq.c:243: Dom3 PCI link 1 changed 0 -> 10
(XEN) HVM3: PCI-ISA link 1 routed to IRQ10
(XEN) irq.c:243: Dom3 PCI link 2 changed 0 -> 11
(XEN) HVM3: PCI-ISA link 2 routed to IRQ11
(XEN) irq.c:243: Dom3 PCI link 3 changed 0 -> 5
(XEN) HVM3: PCI-ISA link 3 routed to IRQ5
(XEN) HVM3: pci dev 01:2 INTD->IRQ5
(XEN) HVM3: pci dev 01:3 INTA->IRQ10
(XEN) HVM3: pci dev 03:0 INTA->IRQ5
(XEN) HVM3: pci dev 04:0 INTA->IRQ5
(XEN) HVM3: pci dev 02:0 bar 10 size 02000000: f0000008
(XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008
(XEN) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000
(XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101
(XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000
(XEN) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201
(XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c221
(XEN) HVM3: Multiprocessor initialisation:
(XEN) HVM3:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8] ...
done.
(XEN) HVM3: Writing SMBIOS tables ...
(XEN) HVM3: Loading ROMBIOS ...
(XEN) HVM3: 10332 bytes of ROMBIOS high-memory extensions:
(XEN) HVM3:   Relocating to 0xfc000000-0xfc00285c ... done
(XEN) HVM3: Creating MP tables ...
(XEN) HVM3: Loading Cirrus VGABIOS ...
(XEN) HVM3: Loading PCI Option ROM ...
(XEN) HVM3:  - Manufacturer: http://etherboot.org
(XEN) HVM3:  - Product name: gPXE
(XEN) HVM3: Loading ACPI ...
(XEN) HVM3:  - Lo data: 000ea020-000ea04f
(XEN) HVM3:  - Hi data: fc002c00-fc0060bf
(XEN) HVM3: vm86 TSS at fc006400
(XEN) HVM3: BIOS map:
(XEN) HVM3:  c0000-c8fff: VGA BIOS
(XEN) HVM3:  c9000-d57ff: Etherboot ROM
(XEN) HVM3:  eb000-eb150: SMBIOS tables
(XEN) HVM3:  f0000-fffff: Main BIOS
(XEN) HVM3: Invoking ROMBIOS ...
(XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d3 entering stdvga and caching modes
(XEN) HVM3: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
(XEN) HVM3: Bochs BIOS - build: 06/23/99
(XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) HVM3: Options: apmbios pcibios eltorito PMM
(XEN) HVM3:
(XEN) HVM3: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
(XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)
(XEN) HVM3: IDE time out
(XEN) HVM3:
(XEN) HVM3:
(XEN) HVM3:
(XEN) HVM3: Press F12 for boot menu.
(XEN) HVM3:
(XEN) HVM3: Booting from Hard Disk...
(XEN) HVM3: Booting from 0000:7c00
(XEN) io.c:199:d3 MMIO emulation failed @ 0008:4013b1: 90 86 95 21 08 83

--bcaec53aeea4c3bde404b63c109e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi all,=A0<div><br></div><div>On my production deployment with xen-3.4.4-rc=
1, HVM guest would not start up when maxmem is set not equal to memory, unl=
ess=A0HAP is disable(hap=3D0). The guest just hangs at &#39;Booting from Ha=
rd Disk...&#39; as shown in the attachment. I find that both Oracle VM and =
Fedora have the same problem per the following links:=A0</div>
<div><br></div><div><a href=3D"http://docs.oracle.com/cd/E15458_01/doc.22/e=
15443/toc.htm#BABBIBFD">http://docs.oracle.com/cd/E15458_01/doc.22/e15443/t=
oc.htm#BABBIBFD</a></div><div><a href=3D"http://docs.oracle.com/cd/E26996_0=
1/e18546/CJAGDAGB.html#id419003">http://docs.oracle.com/cd/E26996_01/e18546=
/CJAGDAGB.html#id419003</a></div>
<div><a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D645319">https=
://bugzilla.redhat.com/show_bug.cgi?id=3D645319</a></div><div><br></div><di=
v>Could I ask if there is any work in upstream/xen-unstable to fix this pro=
blem?=A0</div>
<div><br></div><div>Thanks.</div><div><br></div><div>Below is the xm dmesg =
output related with the hvm guest:</div><div><div>(XEN) HVM3: HVM Loader</d=
iv><div>(XEN) HVM3: Detected Xen v3.4.4-rc1-pre</div><div>(XEN) HVM3: CPU s=
peed is 2267 MHz</div>
<div>(XEN) irq.c:243: Dom3 PCI link 0 changed 0 -&gt; 5</div><div>(XEN) HVM=
3: PCI-ISA link 0 routed to IRQ5</div><div>(XEN) irq.c:243: Dom3 PCI link 1=
 changed 0 -&gt; 10</div><div>(XEN) HVM3: PCI-ISA link 1 routed to IRQ10</d=
iv>
<div>(XEN) irq.c:243: Dom3 PCI link 2 changed 0 -&gt; 11</div><div>(XEN) HV=
M3: PCI-ISA link 2 routed to IRQ11</div><div>(XEN) irq.c:243: Dom3 PCI link=
 3 changed 0 -&gt; 5</div><div>(XEN) HVM3: PCI-ISA link 3 routed to IRQ5</d=
iv>
<div>(XEN) HVM3: pci dev 01:2 INTD-&gt;IRQ5</div><div>(XEN) HVM3: pci dev 0=
1:3 INTA-&gt;IRQ10</div><div>(XEN) HVM3: pci dev 03:0 INTA-&gt;IRQ5</div><d=
iv>(XEN) HVM3: pci dev 04:0 INTA-&gt;IRQ5</div><div>(XEN) HVM3: pci dev 02:=
0 bar 10 size 02000000: f0000008</div>
<div>(XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008</div><div>(XEN=
) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000</div><div>(XEN) HVM3: p=
ci dev 03:0 bar 10 size 00000100: 0000c001</div><div>(XEN) HVM3: pci dev 04=
:0 bar 10 size 00000100: 0000c101</div>
<div>(XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000</div><div>(XEN=
) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201</div><div>(XEN) HVM3: p=
ci dev 01:1 bar 20 size 00000010: 0000c221</div><div>(XEN) HVM3: Multiproce=
ssor initialisation:</div>
<div>(XEN) HVM3: =A0- CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2=
/8] ... done.</div><div>(XEN) HVM3: Writing SMBIOS tables ...</div><div>(XE=
N) HVM3: Loading ROMBIOS ...</div><div>(XEN) HVM3: 10332 bytes of ROMBIOS h=
igh-memory extensions:</div>
<div>(XEN) HVM3: =A0 Relocating to 0xfc000000-0xfc00285c ... done</div><div=
>(XEN) HVM3: Creating MP tables ...</div><div>(XEN) HVM3: Loading Cirrus VG=
ABIOS ...</div><div>(XEN) HVM3: Loading PCI Option ROM ...</div><div>(XEN) =
HVM3: =A0- Manufacturer: <a href=3D"http://etherboot.org">http://etherboot.=
org</a></div>
<div>(XEN) HVM3: =A0- Product name: gPXE</div><div>(XEN) HVM3: Loading ACPI=
 ...</div><div>(XEN) HVM3: =A0- Lo data: 000ea020-000ea04f</div><div>(XEN) =
HVM3: =A0- Hi data: fc002c00-fc0060bf</div><div>(XEN) HVM3: vm86 TSS at fc0=
06400</div>
<div>(XEN) HVM3: BIOS map:</div><div>(XEN) HVM3: =A0c0000-c8fff: VGA BIOS</=
div><div>(XEN) HVM3: =A0c9000-d57ff: Etherboot ROM</div><div>(XEN) HVM3: =
=A0eb000-eb150: SMBIOS tables</div><div>(XEN) HVM3: =A0f0000-fffff: Main BI=
OS</div>
<div>(XEN) HVM3: Invoking ROMBIOS ...</div><div>(XEN) HVM3: $Revision: 1.22=
1 $ $Date: 2008/12/07 17:32:29 $</div><div>(XEN) stdvga.c:147:d3 entering s=
tdvga and caching modes</div><div>(XEN) HVM3: VGABios $Id: vgabios.c,v 1.67=
 2008/01/27 09:44:12 vruppert Exp $</div>
<div>(XEN) HVM3: Bochs BIOS - build: 06/23/99</div><div>(XEN) HVM3: $Revisi=
on: 1.221 $ $Date: 2008/12/07 17:32:29 $</div><div>(XEN) HVM3: Options: apm=
bios pcibios eltorito PMM=A0</div><div>(XEN) HVM3:=A0</div><div>(XEN) HVM3:=
 ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255/63</div>
<div>(XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)</=
div><div>(XEN) HVM3: IDE time out</div><div>(XEN) HVM3:=A0</div><div>(XEN) =
HVM3:=A0</div><div>(XEN) HVM3:=A0</div><div>(XEN) HVM3: Press F12 for boot =
menu.</div>
<div>(XEN) HVM3:=A0</div><div>(XEN) HVM3: Booting from Hard Disk...</div><d=
iv>(XEN) HVM3: Booting from 0000:7c00</div><div>(XEN) io.c:199:d3 MMIO emul=
ation failed @ 0008:4013b1: 90 86 95 21 08 83</div></div>

--bcaec53aeea4c3bde404b63c109e--
--bcaec53aeea4c3bde804b63c10a0
Content-Type: image/png; name="guest_hang_screen.png"
Content-Disposition: attachment; filename="guest_hang_screen.png"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gxa1polc1

iVBORw0KGgoAAAANSUhEUgAAAtcAAAGVCAYAAAA19t2nAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAFBnSURBVHhe7Z0LsiQpkmxrl7PF3GW+ijcS0gwN
qJph7uGf0yIpVXXdHOxzADVudOQ/f5v//fPPP3/5Qw5gAAZgAAZgAAZgAAZgwGOg1dKff/8Hce0l
DsDIEwzAAAzAAAzAAAzAQM/AUlz/z79PR39GILV2R4J2lj+R2HfjPSt3Hz+/c/U+j37e52AW58dO
MeHEOPNtN7877zt5Wfnt5DBisxPL09+dcXjXuDN7XSYHK8Z/lbvq2J29xbH5VT6YF/EGA/diQN5c
9xuOIySOgsA9BKo2yUjsuzFX+az8cMW1G7sSze44K+GvYjrqeYR1h83IeKtm5ah47zzuWevnrBw5
PI3WTCYPozWcGacqN9Wxqz2qzWOmOamKm3HuJZ6oF/VaMfA4cb1zKPQba0QY7i60Hb8jczviemXT
ztXaOeNeUUCvbuNXB61iw83hd363/q5dhIkn2L4hL4q5KEu9vbOef8VKNvZWWM/Ws2Pzq7iZFwEH
A/dk4DRx3W9gSsiODgrnRiN7yGbHVnH1tyKOCFU2zk1MVDRGD1YnX5GbNRVTVZ7djUpxpA579X7v
h2vv2q1uvme5VjH19XTGWdVV1XTE5GzfqBBIEX9mTaa73l0OnXmyLM3Etaqrer7rj/O+2iOdMTI2
mbrxzj3FEXWjbjsM2OJaiZ+RkFrdpDjibGWjNvjIYas2ajVX9ABUcbmiNCO0VKyrOq7inL2nBIsa
U40bZcxdLCq3Ki71fvZgj44byY8jrnvxqOrzFcPO2Nk9wWV2VfuquZ1xXAZHQn22XkaNiDvPrIlp
GxknLmdvcX1acdvX24ndWTeOTdR/7BFoMPBOBmxx7QCiNlclSCKHyWzzdQ4BR9A5AteZy92ws+LD
qYsT7+yAmjUpo1ru5kPxo+Jwc+3kTI21+/wK4lr54NYjU/dqflb1cOZS9VwJeGftOswpm9U8jsCc
jT8b99fi2qnpSmir/ULxr+rB83eKJupO3R0GThXXjkORQ8wRwNHxVhuyc4g6NqM8uO+1QsHNp3PI
qMPZ8S8jsqK+zZqq/uetMKjMk5rffZ492B0R6PDl2Lji2hmrKt4dn1YcOHmNzL27Tp2cRvyJxp5Z
71X+rPZstb52fHAYyOwlvIMYg4H3MXA5cd3fMinxlTkEnM3bEe67YjIi5LPiJHNIZ+PKvpc5MNVB
qJ6rzU69n30+E/1qPJWj3Xgc3iM+qHjU89lcO+IpKjAza6dynaqxqnKRXbfZ945gVbHp8ObYKN95
/j4RRc2p+YiBn4nrzMaceSciGqKHWZU/jo/OXJFFvmpiKv1xmp/MweiMu3tYrt53xnZ8VLGr5tKt
ucOP628mdrW2Zg1vxifHv6w/rZ9OTmdxqbplxz4qdtcflR8Vt8uBs0dF104md0482CC+YOB9DIT+
EpkVIK5Ya+2czW92uM7GGW3uH9t+LgV7H4+6Jdr1xxERI59UHE7NZjZ9TG0encPWzaFzIDuxOzbR
fK3idA5jtS6c2LMCbSYgXVZXAmYVuxOzs06zAqpf727NI/xE4j/aHzffap2r/bgqP6oes31jlEcV
u7MHOTbKZ56/TzxRc2q+YkDeXAMQAMEADMAADMAADMAADMCAxwDi+t+/EhxYyAEMwAAMwAAMwAAM
wEAFA4hrxDXNBQzAAAzAAAzAAAzAQBEDiOuiRFZ0OoxBxwwDMAADMAADMAAD92YAcY24plOFARiA
ARiAARiAARgoYgBxXZRIusx7d5nUj/rBAAzAAAzAAAxUMLAtrldfm/T96qToVx3NvroqOo5KkPoa
p8/7T7OJfJ2Wyh/P2YR2GVitL+cr2Xa+ErLdZ6J7i7tHZfPj+OPYjPaw3vedPTz69XjOXN+cqb1X
7WV//vz5+/nT1mD0M1Wj7zujf47e7ef82jj+9HPMxo/6pGLkOXs5DNQyUCau2028/3fnv0cb6qjY
/WG6+r7ZFSzOOG+wyeaPhVi7EN+Yz4r11Qqsfg9pc1oxV3aPyta2wudI81Gxhyuf2+ezf1/VLVLj
VoCuBK5Tn14Yz0T6aM6IuP7YqgagfT77dycmbNjDYeA4BkrE9WzDG90MuZvjTPSpzduBxRn7qTaR
RsfJJTbHLc4n53a1vpS4Wt04j/he/WxHgDt7xE4Nnb1O2bjiOrOHf/O62tNHNs5czpizG/hezFYI
0Nmtc1tfNY9zc+2K65lgn92a73DIu+zxMBBnYFtcq4NwtZGuxLd7SGZuXp1D8ak2Z4vr2a+BR9ys
fg3MOH+XH1G6Wn7UZuyu2/52sx93FvdKePXPjt6jVC5mz5VwdtayI64ze/goh25NlXB2/HHiqvzo
RC+c+5o5wtmxccT1TNBnOJvlaDTH6iMrjPO/H0Ga/eaC/LwvP6eL6/YwVJvoagOdjeNsMP2B/T0o
3vBz50B2cohNvJMlZ//JmSvEVg1Xz3KkORvVYiTUd/ao3Xorf9r4d/dVR/BGauHE7jDgXHLMfB/d
JKuPXMz8Vp+FdoSzY3O2uHbqhA17PQzEGThdXI/E3eyQcG4nMkV/g4iexYi4ji+SDGO8s87ziE+1
3p3bUkdkOjfXbmOvfN7hICo+XV9W47rPnFqo2KPxRRud2eekMx+dcG+uRzeUX78R1+y9ak3w/DmM
/ERcuwLPPSyiQDq3IU+1cXMfzenMfnT71h/M2NzrIx9OvRQ/7tpWAqxqHGddVM6l8jO7hOjf631S
/63GdcX1yH9VK+V7ZEynFq6YdWqhbryduRybs2+u+bjC+z6u0DLGR1n+U/92H6hYF4jr5nuuV7e9
38Tf3cYREc5hg81zOuxf1NIRRzMh2DZnVeM466JyLifnjlhVYtr1ebS/OWJY1eKb14hwbm2dS46Z
766YdWrxa3E9u21XfjmxYcNeDgP1DLxSXDsH6VtsnAOchVe/8Mjpf75DfiXsqsSjGsdZ765QdeZy
6u+sTTWX63NGXDtj79yEz5qrVdPViv2niOuVgEZcszc7ewk253NSJq77XxWPbh9WtxyRjdo5dByY
Vj73h41zSNzBpo+5rYmTM2zOX6RPznnLY3/LOWJVicmVSF6x3/vhiO3sXE49o3uT06CMYpzt0/2+
4NTi7D1T7WVV4lr9nxk/cbtzrT6T3Y6j7Ea2DlfYsH/DwDkMlIlrCnZOwcgzeYYBGIABGIABGICB
6zKAuG4+cw2o1wWV2lAbGIABGIABGICBOzCAuEZc/70DqPjIhgoDMAADMAADMHAHBhDXiGvENQzA
AAzAAAzAAAzAQBEDiOuiRN6hk8JHOn4YgAEYgAEYgAEYOJYBxDXimk4VBmAABmAABmAABmCgiAHE
dVEi6QKP7QLJL/mFARiAARiAARi4AwOIa8Q1nSoMwAAMwAAMwAAMwEARA4jrokTeoZPCRzp+GIAB
GIABGIABGDiWAcQ14ppOFQZgAAZgAAZgAAZgoIgBxHVRIukCj+0CyS/5hQEYgAEYgAEYuAMDiGvE
NZ0qDMAADMAADMAADMBAEQOI66JE3qGTwkc6fhiAARiAARiAARg4lgHENeKaThUGYAAGYAAGYAAG
YKCIAcR1USLpAo/tAskv+YUBGIABGIABGLgDA4hrxDWdKgzAAAzAAAzAAAzAQBEDiOuiRN6hk8JH
On4YgAEYgAEYgAEYOJYBxDXimk4VBmAABmAABmAABmCgiAHEdVEi6QKP7QLJL/mFARiAARiAARi4
AwOIa8Q1nSoMwAAMwAAMwAAMwEARA4jrokTeoZPCRzp+GIABGIABGIABGDiWAcQ14ppOFQZgAAZg
AAZgAAZgoIiBpbj+n3+fjv6MOp7W7o0d0Tf+3didcT42u/Pw/rFdK/klvzAAAzAAAzDwTgbkzXUv
9lbizxGGTwWtKnY1jnr+1PwS1zs3KOpO3WEABmAABu7GAOK66FcAZxW+UlxXjnVW/MzDJgsDMAAD
MAADMHBlBk4T187HS3ob9fGTmTh05lJFUWO376uPxLj+rMaJfERHxfZ9jrhmc3JZwQ5WYAAGYAAG
YMBjwBbXSkB+Ep4RpLNCjcZyfubYOHBEYqmMXQle9dyJDRtvcZAn8gQDMAADMAADMBBlwBbXzsBK
kKobXPV8JWL721hnrFVMKpb+3arPoivxrJ47dcKGjQIGYAAGYAAGYAAGjmHgVHEdEbOOWP3YRERu
BKJKcd02BSOfW7+UeFbPIzFie8yiIq/kFQZgAAZgAAbey8AtxXV/Sx0RpxHYeyHrCH41vhLHu8/V
/EflKjIvtu/dcKg9tYcBGIABGHg6Az8T10q4up+dVuO0t8aZYvYfL5mNEbnp3hHp7btKiKt4d99X
4/OcDRQGYAAGYAAGYOBtDIT+EplVcpQIdT4D3drMRHF0nAoBqcaoiL3/6Mjq4yN9nt4GLfGyUcMA
DMAADMAADFyVAXlzfVXH8YtFBQMwAAMwAAMwAAMwcDUGENc3+0tkrgYQ/rCpwQAMwAAMwAAMwMB/
GEBcI67/6xtXWCBskjAAAzAAAzAAAzCQYwBxjbhGXMMADMAADMAADMAADBQxgLguSiTdXa67I2/k
DQZgAAZgAAZg4EkMIK4R13SqMAADMAADMAADMAADRQyUimv1tw9WdSXqq++cr7X7xVf6VcWvxnHy
o8ZwcnhXm9bvVR7UVzA6OTzLxuHZ9cXhp8rmz58/f9s/Ix+vZuPm8Qy7Pjef/87Oe7U8X82fbF55
jxtZGHgfA2Xi+iwhkvlLYyrecQXZrxeRE6vjozPOHW36hmCWizt9l7j7Fy5dre5f8fT1q//vz8+v
ZuPk8CwbJ1+uL1fL89X8cfOI3ftEFDWn5iMGbiWunb8F0bEZJSIjFK+2qLKx93E449zRpvKm/Wq1
d2uYualva11V95Ew7MX01WyuXvNRM+L4fLU8X80fJ4fYILBgAAZaBrbF9ejX0f3HQ0aH8+gjJGqs
qoPdESKVt4HOolO/1ndy6ORnJDCdxqJ9r//3Nr4jhJgTl2Mz83NWnzN+G1NRd4fnq9X9agLK8cdZ
x66N+jhH64/62Ew75+o2e/YxCyf2N9u4NcUOcQUDMPBlYFtcfwdSQqT/NbuyH0E6E27Rn7siSwmf
qoXkCnmVQycPjs/OOHe0cevuMu3kcmVTVfdoXE4zcXR9R+Lx49eVf75b7+/77sc5elGtBO7sufL7
yjm/gm8qfzxHUMEADPQMnC6ud4RL1YHv+OAKn4pF5TYa6obZyY/jrzPOHW2iItSti5NT1SxGRHj0
lt7178yaXkE0RX1w86jsXBHsfO64n8sdu30vmoe32at68hxhBQMwcBlxvRIb/Y2xEsPRjyJ8xlPC
6Q7ius+hK7pGN/Kfn1Xn2fHnTJuniOusUL9S3dUtbH+L7YjBo22qDlBXALt2s7i/Px99BOXzs/75
SqjfsV5VPlfVnXEQYDDwHgZ+dnOdgexoIabElxLkmZgcoa9Er3oe9fvoPEeboSp/VH3dZiVb5+z4
qn7quetvVZ6dcaqEz5njuHlUdq5odu2UuM76M7uhPrqJObOmzlwqfzx/j2Ci1tTaZeAQcX3kra/6
aMRIrFa8ExHBbvJXojibQydWxz9nnDvaqEYkKsCdXM5s3Bor8eyO4/h6Zk2djz1czcbJobKJfuZ6
Np47jvLn8/xqeb6aP04OsUF4wQAMfBkoE9et+Gw/YtD/vH+WgbH/9fZojJXN7Nfjyu8K35XQan0b
CT0ltCrzvZvnXsiufD9rrlntV7l2cp7heFQrxaDD+owh18ezatGKutUtbf+xhlEcZ9q4eVzZjT6q
0do78Yzy137cI+qnM+ebbaL5xB6hBQPvZaBUXAPSe0Gi9tQeBmAABmAABmAABv7ptfXf//MTEsQi
gQEYgAEYgAEYgAEYgAGfAW6u//28IcCQAxiAARiAARiAARiAgQoGENeIa5oLGIABGIABGIABGICB
IgYQ10WJrOh0GIOOGQZgAAZgAAZgAAbuzQDiGnFNpwoDMAADMAADMAADMFDEwOni2vmasIqvvHPm
+XSGVV+z5oxTHddovNFXzbUdsPM1hI5NVVft1qlqvspxzvzKuhWrkXqd7XNlvivGcv5ilvbr5mZz
7nzl3XdMZ56PreOzkxtnnOq4+vFGX0E4+07r1dcVOuM4OXFs3Do5Y51tc+ZXJ65YzdTrjK/nPLse
zHfv2+hI/U4X10rQOiLVDdAZy7Fx5lPjqOeZOfoxR3M4P8vaOD47NhW5ceaptMnkfifPqybEGXe0
7pz3sjaVua4cyxGYStC6Yzh+O2M5NhVzVcyj/vKX0RzOz7I2Tl4cm4rcOPNU2qhajDjfyfOqCXHG
bWOPjOWMfcf6VbLAWOeL+teL67Og2xWQs/fVuI44+gqvNhez947Il4rhiDl3xnRqUWXTiuJInhzx
3wvuSp938nuFd51bswo/r3To7/oye1+N64ijrxAcCbD+ZxV16cdQMRwx586YTi2qbFqRHsmTmt/l
om8S1Lg7eeXd80XqXXNeIq77WzV1SK8En/NrazfZSow4t4Efm+98Tly9b308zhgjv9R7s5wocd3G
NxPXMxu3DsrOqXnGZuT3qB7Rmjm1qLJRDY9b9yp/nHFUvX/1fHUb9vWptfn8+0jMrWyisSkx4tzg
tX4qYdHHNBJGzhgjv9R7s9woETXyeSSoormP2Ds1z9i49ZiJ/dmcTi2qbFTDs1P32RpcNT9OXJHa
Y4ugzjCwLa4rb8g+AShBHAnSGUuJhag4dsVOJI4+L63PTqOixOPIF0fMRmNwcpOtmWoiZmw5883y
59ZlVi/n5xlxrXLhzLtjU8XFEeOsxGz7zLXb9VGJ615EOmI/Ky4cX1bxzvKXyWVGqO7WIhNbVjh+
3+tzoxoNN0anFlU2GXHtxKlsdvx384gdwjrLwCni2hXgVxTXKwEVET4ZETcbX4lr5Vf//kpcf+PP
Aua85/ARuXFWIt4Za+X3jvCMvqtquRL+UX6ivkU4dDg4w8YVnhlBmPHfEbSOz05joOZSz1V8jthx
hVg/1mhux0b57D6PiOC2MejHVznum4rVWJlmwKlR1Mat6ayh6H8+ysHo3aifKvcuC9ghuB0GENf/
ZuAjElYixRERSjy7z2c3xuqGXQnKKpHmQBW1UeJaPR/FpmrqiOedWjj1cmwidVsx5sxVZROt/5n2
jlD9+IO4/u8DdCb8XNEUEWGOEHJsqthS4lo9H8X+eScqvpUQjdTCWQuOTXVdVzE4/jg2VVwwDkJ7
xgDi+iLiWi1SR/iMxlAfEYiIcuVj9rkSz+p5ZdxODE4tqmwQ17Wbt3vwIq7jeXdzq5oX57lr46xn
x0aJZ/V8NMcoX1UNg1OLKhvEdXytOMxhc++8Xlpcq9teBZ/zflQEOfZK7Dl+qTE+zx3R+RZx7cTp
2Cimvs8zuXfmz9w+z3zqY/mFz24+z7JzBIUSbrNfR2dicMSU47Pjk5rLGUPF6IrMiC+zOdUYytfI
cxWXej5jKvue43tmbEfw7zSekZo53O/k1ckhNvcWuL+s37a4bkVe+2v02cH+/XW9IyJGv9p3kzX7
lX77/sqm9W/2772oUaJ5lZ+quPqY+hzu5sX1M2KnfO4ZGzUWGQ5VvVQMVblU44zyM1obTjxqrlEe
R3lwxlH5O/v597BWh/bnuSuwv7aZWJQ/rQ9K9Chh7MzVz5eJSfn8HdMRaLs2Wf9H7/X5G9W9tVGi
r7dt53TmcmNz6l5hM/J5lSPlv/JJPXc5VH7wHHGdZaBEXI8Ea9Yh3gNmGIABGIABGIABGICBuzKw
La6dXzXfNTn4zcKGARiAARiAARiAARiIMLAtrj+T3fFXxJEkYcuiggEYgAEYgAEYgAEYcBgoEdfO
RNgAJAzAAAzAAAzAAAzAwNMZQFz/e/P+9CITHzWGARiAARiAARiAgXMYQFwjrmkuYAAGYAAGYAAG
YAAGihhAXBclkm7wnG6QPJNnGIABGIABGICBKzOAuEZc06nCAAzAAAzAAAzAAAwUMYC4LkrklTso
fKPDhwEYgAEYgAEYgIFzGEBcI67pVGEABmAABmAABmAABooYQFwXJZJu8JxukDyTZxiAARiAARiA
gSszgLhGXNOpwgAMwAAMwAAMwAAMFDGAuC5K5JU7KHyjw4cBGIABGIABGICBcxhAXCOu6VRhAAZg
AAZgAAZgAAaKGEBcFyWSbvCcbpA8k2cYgAEYgAEYgIErM4C4RlzTqcIADMAADMAADMAADBQxgLgu
SuSVOyh8o8OHARiAARiAARiAgXMYQFwjrulUYQAGYAAGYAAGYAAGihhAXBclkm7wnG6QPJNnGIAB
GIABGICBKzOAuEZc06nCAAzAAAzAAAzAAAwUMYC4LkrklTsofKPDhwEYgAEYgAEYgIFzGEBcI67p
VGEABmAABmAABmAABooYeLS4/p9/o/v8ObpT+86zmq/Cph9jJ7YKf9q87sb+GSsyRh/7KDer/JzF
xtHsXXn8SsZUvf78+fO3/ZPNizPOETYrf7/z9Ta9H6P4HZvZuNkcPvm9Csac/BzB2GfM0dzOXI7P
2JxzI0qe75FnxPVml9If+iMRUGHjjOsuugp/RsJ6JGaduVph7YwxE+IVc7k5xG69wTm1cGwUG5/n
vficiVFVM2eco2xmvikxV+XPd341n8rhG55n+XJzU1XTqnFcv7G7h+ijTufU6ZLiWt1SXQWOmZ/t
z4+0cW56+1xV+fMdd3U76czViyf3Nt5pNlY2d2Fs1MRchf+ZH07dHRuHDXWr2/u4Y++8u2Mz83Ul
5kbP+htKx6ZtUo4Wj1fnV/l3ZH52+GnfrRpH5YLn5wg18ny/PJeI69Gv5GeirrWNHs6jw3Ymxlbz
jMTv6sZ0JiAdgXCkza/FtWoinNiz4jErrvum4MhN62rrQvlztXXhsOGIiHacHXvn3R0bdXs9et4L
qiqb2UcIKtZL/zGEVTMwu0kfCcmRz2quUVMxi70fSzVDrj+t3Q4/iOv7CbCK9cQY16z7trjOipzM
zaEzl3MgtyJ9R2zNxOURP480FqvFdrRvs/wrIT6qiWrQ1PPVLXiGv8gm5rDq2DhzOuM4NldbF85a
ngmK6O2iM061jRJr3/idm+sdm/7daO4cRlexjObrRXXGZvVO1p9WjKumLZPHasZ6f6PjR2qL7TVF
HnX5TV0OEdejYlaImdHNW+b29moiIip4r9QQrG5DnbgcAeXy1LOQZaNqM3KYd2yUP+66cOaK5HDm
l1N3x8ZhwxELKn+7AsTxQd0qOuJ4FEc/bsZmdLubEYaRPKsbZUfwKxsnhowAV0LfbZqcWn3GugKf
Tm2x+Y2II+/XzPtp4roVtKsbxRUojjhwDmRXXM9EixK30VvaWVxqnGg+RnGPYnH86evk3oy6PqgN
w5nv1+LaZb7lTMXtNhpK+M7WoCOuz1oXzlqeCShHWLXjO+McaVMhrmc1r8pFhs3+HdcXx07ZqOe9
aP36mhHtzlztfDMBfiRjK5HurIWK+jPGNYUgdamvy6niWolS9TwqJiPiKjq2KxIdoZq1icQXya3j
D+I6thgdvpRNpi5KZKs6Kp8iYl81i+6acoSAI1Ki4zhjZm0Q1/93PTliVdmo578Q10rEZPnJCGdn
LuUvz2PnAPl6T74OEdeR26/s4azE4uqgHj3LiAh3nEw+Mu+0uYwI791b4Igoivi1qvGuz9l6u5tj
1r+j8uP44/Ls5CDDbyb2kUCqEqqZjww4/jjjOsJ/Jg77+jgi053Pqf3Kxo3d8VnZOHNlbJx33NqM
cqVuzh3GKm12a8777xGU1Po/td4W1+2BvPr19uhXyZlCuOP0dv1c7jiOj2quUY5WTYW6oVzl2fG3
yp9e/Lp+O7X4jDVqFmaxj+rZjzFjdWTn5nFl5zDm2Di+OONU2Tj+VDHm1nX2a3bX16+dM06FTT/G
579nolh9hMBpJpQQjcQfzakTV2tTkd9ZPG6eVz6PhGv7s9b/bK6qclA1TjYO3kNYv5WBEnF9x+Qd
fXN5x5zgMxsh6wIG2AdgAAZgAAb2GEBcb/4NjQC4ByD5u1b+ENfXqgfrg3rAAAzAwP0YeKW4dj7G
Acz3g5ma7dWMdbGXP/gjfzAAAzAAAx8GXimugR/4YQAGYAAGYAAGYAAGjmAAcc3HQv7r/0h1BGiM
yQYGAzAAAzAAAzDwBgYQ14hrxDUMwAAMwAAMwAAMwEARA2Xi2vn6Icfmah1N1VcZOeN8YldfmeWM
U2HjfFVYRa3c74x153Jid8ea2VX5PMrx0WukMj+jrzVrGXZjUcxX1cv1Z3e+ivd/wcbK7+h+cHRN
K3LMGNygwgAMHMVAibhuN1K1qarnRwWaGbf31RFVWZtelIz8PcsfJ4ZMPlcxtUIty4iTnwq/RyIt
4/PsncxYkbgqxldjXG1PiPgTyeVRtjN/Vd6P8qdv/JUf6vmRfjI2ggkGYODXDJSL6+8mHLn1+3US
HCH7tXEO6ajN6Lav98kRYlU2kXzs1q6/EesPcXf8VezuGK5dpc9unV3fHLsK4aPGOKvRceIdMaX8
d8c9ym7VbLbPjprf2QOunsMzc8NciDkYgIGWgUPE9Qqy1YY8Ei0z8fE9YEbj9eOMDqORzepAO1pc
j8ZvY68Szs44Zwq+WR36mqmaOgf9ipXIxljls5PnUaO2K64cBtoYRxyqteqK69k8/XpQdqp+jj9Z
xkY16htm5V9mz3TZiNRqlWcnh07cKs87ueJdBA4MwMAVGNgW12rjdgSEc0vi3j5VC6h+XnWQZux3
RPSv/KmCdyYQVKPjHvQqt44oXzE84z/K4cqPXvBkfFZ5mDV3jhB31q8Tn7NXZGNXvDj1cnOh5oqu
HSd33/Wi8pONwd1/M5cEyudovrBHXMEADPyagW1xPdp0M7cw/Y1H5WGXSfIRonU2piN8fuHPGYfe
TIjcRVzPbuocfpUQiQpel3NHrCnfFBsRgRnxx41RCXXHP8fGEZ0qVyqmSH5W3PVN2mrfcfiN+OXs
cSoPPEcwwQAM3IWBy4hr5yBzbHpR0Iq00QbfHjhK0PUHqXML5Ng4B48zTpVNtGHagT17iEdYWAnF
jPCp8tnNc8bH3Qb3KuJ61rxEmVO8RGva2mfGjvifFbGO8I80cCpOZx9z9+dIfrBFcMEADFyNgceK
ayUOVCGqhKozjnMoOeMcbaNylnkeFTURMfAVF1cV10o07TI8q4eaN9pkjuapFGIVeVD+RDlEXK+/
NtRtCF27zN7COwguGICBXzHwOHHtHJJustWB7N4MOeM4AsIZp8KmMocq185cjo1TC3ecs3x2mqFR
XMo/9bxaXKu8KgHl5mEnFysxPBt3tpa+P+//GW38VJ0ye0I/prMfOGunt7lCTd38YYfAggEYOJuB
bXE9O2BWt1nqMP3enK0O7Xbe2YGysnET7cRXYaMO7P6gdQRS1mbmy7cubu4cOyXMZnHPfFG1cPO8
8r3K51We+zWgxIyT61YgqTUYEXZ9LUZxzfzL1MuNdZedEWOOWHVs3BhW+VG5G8WvGonZnnm1mrr5
ww5RBQMw8AsGtsX1L5x2Dv5f+sXc91nMVaKVmt+n5tTqv2vFOoBf1gUMwEAdA7cS15U3QkBUB9Fd
c4mggIG7slvtN2uBtVDNFOPB1JsZuJW4dn6t/eZiEvt6M4v8aptccjC8hQH34yVvyQdxsvZhAAZ2
GbiduN4NmPdZNDAAAzAAAzAAAzAAA0cxgLj+B7iOgotxYQsGYAAGYAAGYOBtDCCuEdd/3wY98bLR
wwAMwAAMwAAMHMXAY8W18znCCpvo53hXX+O2Gmv1tW0tHFF/jgKr/3z8kfOs4h/N69T9+97q/+jl
jhMZw/lau9FXxDn+nlWDX8zj1OJMm5b/WT5mX3vX2+/w84tanLH2j9oP3f3ZqelsnTocOus5Mo7i
wGVRjaOeOz47NtH1tdozlc9Xe+7kx7F5cw7PqOkjxXW/Qa42zNUmpsZxxp0Jv9HPVwVfHbCRGM6A
KhpblU+qXqPNxBUuSvDMxlkdWi4/TlxnCJqqOlWP4+TnTBunFs56VuO4/FTn2x3PjdEdL7qvRPPj
rlW11iP78dH7TyS3R9bL3XuddarWhTtXJDdXsXXy49i8OYdn1fJx4trZ+KpsRkVSY0c3/NVGrQTf
aJM5C6yI3xU+qbyvcrGqSaRes00tcmg580X9rcjvVceoqnvVOP2h9RnXWaervcTx7ez15vAQ4d4Z
Lyquq/ZnR6w5NXJs+jo6+0FV7X9Rr3ZONz9tExRZX0fGF+U3Y+/kx7HZ2aPunsNM3rPvlIjrHvYV
8G7xZxvGaK52Pmf8Khv30FQbiANs1sZ5LwvPE+veH6QVh1ukBs58q/Eic51Z935PcNbg6BDo33PG
OdPGEYDRGjn+VwmsFRPOelcHtxtLdp9XTKv1FfVP5V3t/Uq4K38d3tycqNjbmszOvr5uR+QnMmZF
fqL56/e62T5GDp/9ee9tcR1Z/NFFET2EVsJotsnt/NxZuI4YUAeJIzL63K42QrVZOM/duu8eLo4v
R9V9dPC5czlszGrmbLqzvGTWjJtjJx+ujRIVrk876/eId526O+vdGcc9tN1cruyuut5nYm6UPycG
JTBnZ9hRLCmfnf3VrauaS53fmXmieXPWhTNmxZpw9zo3r8onJy7H5mo5VHHf9XmZuB4dGKsNbtTd
jQ6LaGIduKpsnM1mdpDO4nfGdDb4yDjRHM8OdWcTUYdXVhxW1dSplzOXs4GN8r6Tw9lmn6nv7J1o
ftTcjjg649B2aurYOHV3anzEOKoWTp5X+3wf12ot79bdXTu93cxH9/xy9l6HE2Xj5nk2jlNrt17Z
PXnGsIq938fUmbGq8U5+IjmM8uOMnYnLyW10bzk6h5lc3OGdMnHtbMyu4ItsypkNwlmsjk1GzLgb
lWPnxO6MkwHVHdfx0eFitHl9fqbedTYGh7fohuTYuwKhKoeZOitx4sYQ2R9GuZuJMWednmnj1H3k
T5TB2d7jrssoC864EU7V3qnWe5Y7FYfDysh35z3HxllvmXGcfDkMtnvuL9Zpdn0p3qLrQZ07q3yT
w2d/HORb+8uJ69kh6sLvbDxH22SFhLNxrGyih7abU2djno3lHrhXqfsRh5s60FXd3RwedYAo/5yc
KT4iOXL8iTZVVXtC1DfnkHZ8c8Y5er1nOM3WPbsnqfncXLuxRjl01pLro6q3G4PDdHSuEa/RuKrs
le8V5zk5fIegbut8iLhWi9ZdFGojVAf26sBRPo6ESuad7GaZmevX4tqZP2vjbIBVOXM2QmcuJXic
XDgcOv46+XNsHJ8dm2hckQPOmf9Im6q6V4/j1NfdU536HbnPV9XP2Z/7WHfiiuwboxzPmMiclY4v
Tp5drjLzreKKPMvkx4nLyY9j48zlrDnXRu0t0XFc/99kty2u2yJ8Ifr8c7ZpfZ85C221uagitb6M
/Bn5PRpzNU7/bBW/mm801iqHaoNXvqj8Oc8rfFZxOH60NlV1V/XKPF9tsrN6zRhz2JhxH82pM1fU
5qp1r+DHqVl27fQ1dcbZrXd/EF9ln3did2xm8UXiVmNE96jM/pKpc1/LzB4Vmfes9eXkL+L3ytZh
zLFx/XliDt3Y72RXIq7vFDC+vu/XM9ScmsMADMAADMAADJzFAOL6H2A7CzbmgTUYgAEYgAEYgIGn
M4C4Rlz/10d4ng498bGxwwAMwAAMwAAMHMUA4hpxjbiGARiAARiAARiAARgoYgBxXZTIo7ofxqWz
hgEYgAEYgAEYgIH7MIC4RlzTqcIADMAADMAADMAADBQxcLq4dr4ibvY1XZGureLratr53K8oWvmu
4nJy8/Wpwp9IPs+wVflxfKiq+2qc2Vetzb76Tn3tnFN3ZVP5VU9Onlc2ytfd8Ufvn1H3fu0pXiN1
d9dzH/uV6h6pq1MvZzxnnDvafGJXfLk2Ko9nrteKWrjMO3Op3FzxuRPXmTZXzNEVfDpdXDsbgrOp
OIe7I0RXNqPD1BXcq0NwJQ4cKFabYZ+73Vw6/lTZ7PrqxF5hE/FTHVztWEqMzfK8EmZVtYmOE8lR
dOzZ2tpd7xVsqD3D2f9mNhn/dnN7xPtOHM68zjh3tGnr//FfrfuVjcqjs/+oMdznFbVw9zpnLtfv
K9k5cZ1pc6XcXM2XS4rrnSQ5AsWxGR2Szia2WvyReZ0NdeTPbP6dnN7hXSe3R9usGqoZO2ojdESq
e+CcWUfH7wp/jq6pIz5mNXR8i+TAyaljE5mz2rYqJ844d7TphbXaN3brPWK3uuarhjKzvjLNtdvU
HhF71ZhX47kqrqeOUyKuv0Vv/zlKWG+nbNTz0XxVAPaL0d3EVnaObyvQohvRbGOugtmpu2PTHyi/
rLtTI5eFvkFbxTWzdeY6W1w7NVVrfcTyiNfRXK3dTr0y62nlozr0HR5UU+3uD1VrvB1H1d2pqVOv
kcAciUBVC2euq9mM8n1kzSP7y+p8P2udZvbQnXXnrKM+L6v9+Ao5rGLeyc2bbbbFtXuwOwdZxSKY
zbPzc7frVRuVgnolSKKHi/JlF3qn7o5N9DBxxMdOrSPvrurlxqXqqg6tfs2sNu/dms/Wgaqz4n5n
3UfqtWqYq8Zx6u7WNJKXK6z3UZO84jtyJqwal6raXWEch5+ojdozV+yote3uKVW5ne13s5zsMObE
pvbvyJ6p5qvKYdU4yt+3Py8T16MDY3Y4qINAPV8VrQqc2QH4+flofsdnV2SMFqTrTx//UYBn/FG+
ODlUB8XZAsoRQJHDK7NZVx2Aqj69eOoZWB36jo+Z+lev911+ssInsjeshKZTw4yNWxvFr1Mvxz9n
nDvaRPlx6+Lsmzs2qmZVtXDOXmcu5a/7XPHunA+ZuZwYj7Zx/X6rXZm4dgXvSDhGDouZqFMQz0Bz
N7OIQIpuUo7wcHO0u9m6CyEyT1uzCCej2swEnSNOqmycDT7LlbNZZ2zcuio7t+4ZH1fr4Ap1d/hx
6+6sZyfXjo2qqfPcnUfZuTk8a593/DnTJsqPyreqrfu+2sPPqpez9zr1Unlxnzv7XK9NPu+s4rjj
Xufm6012txPXqjjOwnJsnMNPCXp3jKeLazdP7kbvbLCjOZ26OzaR+T+2q7jU5uyw4diodeM+d2uk
4hrlxR3bESDtWE5Nq2wc3xx+nFw4Nm5dlZ07l7Jz8qx8Wa2pX9XdicuxifKj8q1yGX0/aq/2/mi9
dtZO1vdVDp19ztUB2VpFc+hw6Ngof9/+/BBxrYBTkKvnqmhq/szBHhFIM/8iwKocRMZS+co8dwSd
YxM9THY3ugo2KuNSG6Mzl2OTqbFzkM2ETkWeXZ+r5qoaJyIoZrZOTR0bN4fKzp1L7VuZvdfdTx0f
72Cj+Dlyz3SEoFNjZ+/I1MJ5p5Kx6LrI+qfmOXqfcPzO1t2N7Wl22+K6Bfmb/M8/Z4v0+0yJw91C
tr6M/Bn5rTZx5bP7/grkVQ77BTYTA7u5cyHvc6zqvvLLqZfjlzNOhU029jZHzhiZ9XV0/R2/q2yc
mrtruaLuzlyj2Pu1ofIzG0Pxc2Ttoz6vaufUwqm9M87dbLL8zM4591xy7aLzjJqBnbNAcajOSYer
iI3jj2Pjznk1nl2/32ZXIq7fljTi/Ye/IrXor0h9M0tHCsE355XY2Z9g4DcMsKf9Ju9X5B1xjUhC
KMPATxjgIOIguuKhiE9w6TLQ72HsabDzZQdxjbD6ibByNy/snrlZOb/apPbPrD11pa5PYoC9DJ5H
PCOuEdeIaxiAARiAARiAARiAgSIGENdFiXxSJ04sdOIwAAMwAAMwAAMwkGMAcY24plOFARiAARiA
ARiAARgoYkCK68qvkPl0QM7X+PB/Csh1Sm2tnG7zqXmexfX0/LjxOWvQ4cexcRg72p/IV5v1MbX+
K66cfGCT29vIG3mDARi4EwNLcT06TJzDcpYA913X7k6JPsvXSO4itmf5XzGP8x2qzjx3zI/yWT13
8hKxUfOp55G5Vrbq/9U/akz6nzk2Vf4yDkICBmAABu7LwCXF9dWAOksAVMR9J18r4o2O8fT8qPjU
82g+d+3P8icirkc33d/fus1uwY++fd/NM+/f95CmdtQOBu7HwLa4Hv3atD9onF/LfuEZ3Q61YM0O
vv79/jDs4VTjjObMAt7PNfNl5fPq1myVn5nPu3meiY1ojhx+InNF47p6fiKxt7YO7yNBqNaFW6/M
+sv44/KGuL7f4eTWFjtqCwMwcDUGtsX16ECf3Ua5t1SR90e27kFaKaDdwrqxzWJQjcpI/CgBuRL7
o6ZlJuLc+qr5VP1WIjLyTPnr1spdA2q+UZ0cviMcr3xw5+obmOiYrr+uP87ayzQNfV1naytTV8dn
bBAMMAADMHBPBl4prpUAq4ZZHeyOOHMPdkeYzgTz6ueVQqdCXK9qFBF7Edtf5GfWTI1ueR2uo/E6
dY+O+UtxvdNoRpqt6j2E8e55wFI36gYD72TgteK6FSIzoVKxKFyxq+yuKK6rchiJ3alJROxFbKPi
uiI/0VtRZR+N1xHX2UZHNQO7c7sifuXHbN1FxnaYxeadBzB1p+4w8EwGXi2u1Q2u+zwiLtzbr5Xg
XB34Sqg6oiAjapSo28lRdOyIgIzYZsT1LkOVsVeJ2YhPyjaafzVe9GZa1Qdx/cyDD0FDXWEABo5k
4GfiOnqozoSBIwQdwZnxxymMM/cotquLayfvTn6isSsxFBWQmbo7sTs2Tn6i4yjxGWnMImuuQtQ6
a0XFV+HHrAF1G2OnrthwsMMADMDAcxko+UtkvodO+091yH1sRzb9WL2NM1fkkHZ83l0A/RwrwTTz
ZyaKZrGquCrzrOZS+YvUVM1VEVcrKpWgWvnjxKVyM/Ilu3b6xmQ0jvJZ5XckTJUgPjqHjs+qzqum
TcXn1Bib5x6y1JbawsD7GJDi2oGCw2UfnDfn8M2xO+sLm/31RQ7JIQzAAAzAwFkMIK6L/h753YK9
WWC+OfZdbnifwwIGYAAGYAAGrsXAtrh2fuVK0ddFf3MO3xw76+JamyH1oB4wAAMwAAMVDGyL6won
GAOYYQAGYAAGYAAGYAAGnsAA4voiHwt5AkzEwKYIAzAAAzAAAzDwdgYQ14jr4be2vH1hED+HAwzA
AAzAAAzAQIYBxDXiGnENAzAAAzAAAzAAAzBQxADiuiiRmc6Gd+iIYQAGYAAGYAAGYOBZDCCuEdd0
qjAAAzAAAzAAAzAAA0UMIK6LEknX+ayuk3pSTxiAARiAARiAgQwDiGvENZ0qDMAADMAADMAADMBA
EQOI66JEZjob3qEjhgEYgAEYgAEYgIFnMYC4RlzTqcIADMAADMAADMAADBQxgLguSiRd57O6TupJ
PWEABmAABmAABjIMIK4R13SqMAADMAADMAADMAADRQwgrosSmelseIeOGAZgAAZgAAZgAAaexQDi
GnFNpwoDMAADMAADMAADMFDEAOK6KJF0nc/qOqkn9YQBGIABGIABGMgwgLhGXNOpwgAMwAAMwAAM
wAAMFDGAuC5KZKaz4R06YhiAARiAARiAARh4FgOIa8Q1nSoMwAAMwAAMwAAMwEARA4jrokTSdT6r
66Se1BMGYAAGYAAGYCDDQKm4/vPnz3bX8xmj/ZMJ6hfvVMR+lt99jnvfR8+/P/v62P/36Ocjm9l7
q9ij48xqMYurnVvl5mPr2PT5UPmaMT/6eSaHfYyjfK/qPsrpDvMOY856iLLhjOnY7OxREX5a3hy/
epsdP6NrMrs2XBZXsWXXhFqXs5h22P+Omaln9J1sXqLzYI8AhYH/y0CZuK5YxK6Au1oRK2I/KyZX
jKharETf9+Bx51KxR8ZRYkLF1YuZyOE7i8MZY9W0OD6rHI7E/kysODlQeVb+RGoaFXlnrcededp3
1TjqeSbX6p1ozmdNgGJ/JFIdNhwbJ0ZnHxvFtlOTnXedmFbrOvM+7yCcYSDOwGXEtdqEr1zcO22W
7qE0sxuJtPaAUqIhk6uMzy5PzthZm5VgjoiRKnHt1GbmcyuC1DjZtXokG1mfMiLTmauqppm5nHei
jWKGZ3eNzsauEJGjvWsluNWadnKb4dwZ9yhWd+fm/bgwI2f3z5kU1/3mM9vQonbuxhjdiJyNsd2s
V+PPRKMSmE6OWpuRWGnFjJsrZ0E6QrE/zEa+OIeSO5fy2xnHsRkd0s57WRvnIHb4rhCzTgwzJtXP
nRhUjV0B5ayFVayOoBvtIaMc7MTtiuuoL6u16vCo6uTsl4oX5UeU1Sw7o3Ngdo6pejk+z/bM6Hkx
8xtxfX9BptYfz+9TYymudzfKEQxqI9oRE47o2z2gnfdXB4g6/HcOC7X4VO57vyNiZCTK+8M+I0hW
Nd3JsxPbrBbqsHXXTX9QrtZLJnfR/BwhfBSTO7w7bLjrtReyaq1U1iMqWl0unTXp1EdxMds3RmLf
GcsVojvsrHIzW9+zZkex4u4HzjiOjct8pPbY3kfYUavf10qK69Em5wrm0YbibE4V4lodKk5c7uHp
HIxqvohY21k47sbc18DdrFXt3Jyqw8g5/FSsVxHXSmz07GTqHxWhKjcrnqvmcuJUNY6IPrUG1fO+
UVrVzRlLceEKywp+sr44e2O2zm78q/EV57O4nfq5Y6tz0mU8E6eTe2x+L9Sowf1qsBTXzgaS2XQj
m0VUjM3E3Ur0OQfAx2YGuPO+WhzRONV4EV8j9VD1/rW4zory1XtOfioYmIkFlVOHBScGlTvHP8cX
Zx53HCcudx9Ta9Adx/E9Mpbr12yPeqq4VnnJ1CErph0O1d4ZbRbauqpYK3Kl5uD5/QQgNTuuZojr
5qvVsp1/hbCKbH4R2z6mXqhFBFN7eM98UEIw47tzcDk2o1id97I26jB1xnV9VpukO1eVz8ofNc/O
+0q4OuyO5lfjuj5Ha+quGScud6xZLNG9Lmrvzrsbh+JP1Vo9XwnlqpyoGCqb2Ajb2B4n2MjtfXJ7
iLhWG49zCES7+NFGMxN6yr+I4Oxtq8d2DvnIghvlxBFeTlwqFxU1nR0oTgyuqFENghOnc7BV+qwY
cOdSB3Z0nIxf6h2VW8Wqu//0fqhxs34roRjx16mPmk/FseuPYkzlPbo/r+JxY1G1d/Kuzig3rshc
2T1XMcDz+4g8avWbWoU+c60W6nfRf/452yC/z9Smlj0AooJ65U8bj/LHjX21Mao5qhaJimv0XB0u
SvSu8qPicg6TiE3L5yyunXqOxJ/Le792Rn5kOHHy09fQfSfjT1RgzRiJ+jhb7z3zaj61jzmCzlkT
yq/IWq7K+eocUP60765iy8Sd4VCtS9ffiF1vuzorlX+KoUxO1H7M89+INfJ+r7xLcU1B71XQaL3Y
fJ9d3ygP2MMDDNQwwN5ak0d4JI93ZABx/e9nru9YuCqf1c1H1TyM827OqD/1fxMDCGt4fxPvxPrf
vCOuXy6uWRQcAjAAAzCwx4DzcRhyvJdj8kf+7sQA4hpx/eqb+zstVnzlcIEBGIABGICB6zOAuEZc
I65hAAZgAAZgAAZgAAaKGEBcFyWSTvL6nSQ1okYwAAMwAAMwAANHM4C4RlzTqcIADMAADMAADMAA
DBQxgLguSuTRXRDj02nDAAzAAAzAAAzAwPUZQFwjrulUYQAGYAAGYAAGYAAGihhAXBclkk7y+p0k
NaJGMAADMAADMAADRzOAuEZc06nCAAzAAAzAAAzAAAwUMYC4Lkrk0V0Q49NpwwAMwAAMwAAMwMD1
GUBcI67pVGEABmAABmAABmAABooYQFwXJZJO8vqdJDWiRjAAAzAAAzAAA0czgLhGXNOpwgAMwAAM
wAAMwAAMFDGAuC5K5NFdEOPTacMADMAADMAADMDA9RlAXCOu6VRhAAZgAAZgAAZgAAaKGEBcFyWS
TvL6nSQ1okYwAAMwAAMwAANHM4C4RlzTqcIADMAADMAADMAADBQxgLguSuTRXRDj02nDAAzAAAzA
AAzAwPUZQFwjrulUYQAGYAAGYAAGYAAGihhAXBclkk7y+p0kNaJGMAADMAADMAADRzOwLa7//Pnz
d/Sndfz7vA+m/flsnM/Pd5Iwmrudyxnb8cGxcea6ms0srmgOd+I6c66e2x2/z353ts7O9uM7X7+m
R344No7/kXF28xSZa+W7Gkftq2fm2dnnK/1xY3fY+NiomqtaROdZnTurs3F1Do724lVcFTl06h45
31ca4Bf8nFH3lj91ljn+ODYur9gd12Rsi+vRxtUvNmfxOeNEQXA2HjWm2pSdjVvNcdXnKnb1vDKu
M+e6c03PztOsxs4e4Ng4DEXGUYebmi8ylyOse0Ex++8Zk44/jo2K292fI3O558LuelQ1j/icydNI
NDp1b/1aiXVXdGf3BpWfUX77nzk2VYytcuU0Nk6NI+NU+qNqEfUd+5uL6+yi+b6XAUBtJOr56pDr
/XHHcuKIjjXaWEf+OXNH44r6mvEhUoed8aOxV85VPdaZdRn57ogmx2Z1gCkulBhx1o3LRDTfq9hX
cbkHqxJlWbGq5nficmoaYUqtnVbUuSI0mx+XyVV9Wh9H+e7niKyjKKezeGYc9LkexenYrNZdJN6I
AFa1m3HmMO+Iaycux0atB54fJ6b73Mqb63YxzDYdtelmNoTM4RfZuNUBtNoEZvGoRdTncvcQcTZL
R2T0uXZi71lQC38W+2wDnm2wq5hHfqtxsrE7m5TyJxO7c/A7XDj+Z20UC6sYnHeddb7ak7L5ifoW
PZBVXNF9NpPnVc3V/NG8uvauXcR3JaZ25lScqH1B+aY4cc9pd327dV+dG7Nnoz2wWlyrc9nJ59PW
slt77PJifCmu1aJaicwMjP0C3Cms2hx7sac2xMzGPdsklW9O3M4Y7qaSjV3lMDr/x945GKLjrg6r
bOyqRlEfZ7G7a3DngFCxRJ/PDszoz515M2M6a2c0tzNX1GdnX5nti44/jo3jc7su+3UfEYNRTrO1
Wgm0mQ+O0HNy5ewpzlnnxL6y6edwxltx79Td4e1oG4cxx4edWs/4u8padmLDJi+sP7krFddOMZzN
4LuRO+NlRPxIwDkb4tFzufE6m6SKZ7TxugfS7DCdCUE1lyMglc0oXvXOiIOsUHByl/HRicGZ22Fr
dhh/fu68P8qdc4jtiJrI+IpDFaMzlxpjxZx6d8WC49tOnh2/nX3JET5Va9CZy8mbqou7/lb742gO
J5+OzW4+1RzqrHH3WacWjo0Tb2ScVf1VblzN4Pjj2ERZxX5PQK/yd6q47g83d1PKAKCgd0WLGidz
6DhjuosyuilH5la2KofqfWcTnNmouUd1GfnjHAxV/EXmd+OO1j8TS/QdJ6eOjTNvZhyXS3d/io4X
tY+yMDuEHbG5IySica3so2MpVqKc7MwfmWs3BxE/I7YRVpx4z7TJnMmRsyiSG/ccr8qPWgc8P05M
97k9TVxnxNB3kWSAUBuJ44+zSB0bdy41lopJve88j2wcKi7HX9enzFzqndXcru/u5jmbS83jxOCK
wMw6yrxzxEHhjOmyq3IeqanLr+Pbx6+IuHVy4ti4NVZ5W801mqPSNxVDdC4Va6ROK+GGuP7fr/J1
92Knjk7tnHEUU8rnCCOOP46N4zM25wjsU8S1C0VGSEQAXh1wjo9Zm0hczhzRw18d7M6cIxsVl/OO
K04q5nL96X3KHIDuXOogUHFfTVjPhISTj0yeR/xEcxrJYbQe7lrN+uz449g4B67yMVoLZ99ZCVPn
mWNTlR81l7MG1F4dYTU6lsuq60Mbr1trpxbKxs2zGsdZE1HmlSD/+BRpxpw16caBXa3oDn1byAra
zME4Wnzfn7X/3Cm68lltiO1iaMGfbTAjm4qYVnO3MTi5ivgzq8Po5yrXznO1wa+4cOJybHomnLqP
/FZz9c93Yl9t2g4TR9g48Tk2jm/uOI6dOrCcMSp8dudx7Byblc+R9x3blc1o3axq4jxTPqnnTj37
s6LfN1b73+o8Ge0/sxyNBLXiebfus/Hbnzs2o313tvdW8XNG3RUX0ZpV+ewyjV1OdEtxPSo8yY4l
e2dzI9exXD89X7AED09nnPhgHAZg4O4MlHws5O5JONp/BBEbRZaxnh1YgqUsS7wHOzAAAzBwDgPy
5ppfQewVgvzt5Y+N4J///3/4af+QE5iCARiAARiAgesyIMU1xbtu8agNtYEBGIABGIABGICBazGA
uP73b9IBSnIAAzAAAzAAAzAAAzBQwQDiGnFNcwEDMAADMAADMAADMFDEAOK6KJEVnQ5j0DHDAAzA
AAzAAAzAwL0ZQFwjrulUYQAGYAAGYAAGYAAGihhAXBclki7z3l0m9aN+MAADMAADMAADFQwgrhHX
dKowAAMwAAMwAAMwAANFDCCuixJZ0ekwBh0zDMAADMAADMAADNybAcQ14ppOFQZgAAZgAAZgAAZg
oIgBxHVRIuky791lUj/qBwMwAAMwAAMwUMEA4hpxTacKAzAAAzAAAzAAAzBQxADiuiiRFZ0OY9Ax
wwAMwAAMwAAMwMC9GUBcI67pVGEABmAABmAABmAABooYQFwXJZIu895dJvWjfjAAAzAAAzAAAxUM
IK4R13SqMAADMAADMAADMAADRQwgrosSWdHpMAYdMwzAAAzAAAzAAAzcmwHENeKaThUGYAAGYAAG
YAAGYKCIAcR1USLpMu/dZVI/6gcDMAADMAADMFDBAOIacU2nCgMwAAMwAAMwAAMwUMTAUlz/+fPn
7+hPhar/5RizuD4/H/n1tV89a8fMxlYxRnbu9r1f+THLf0VMjMFtBAzAAAzAAAzAwBkMyJvrXliu
hOYZDlfN4ca1EpqjXGTz076XHaMqN59xzvbh7Pkqc8VYbNYwAAMwAAMwAANfBhDXza8A+pvT/obb
WThZkTgS+858R9lk48j6c/Z8WT95j80TBmAABmAABmBgxcC2uB7duI5+ve98vKTKxoG+93v1jiv8
XLvVx0scP2a36W4tIvnZ/UiMqunoeebjIaOcrH6zsJND97ceTp6xYYOGARiAARiAgWcxYItr5+MR
X1HkiI+jbFxAI7fSjmh2bGa+Ob6shGI7bl+nrF8joT6aZ/Uz1+eKj6HMRPoRcTjsuhxi96wNlXpS
TxiAARiAAVtcOzeqX5uZ+HBvMSNzZSGuvLnOClglVtVzR7xmfVMCMjv3zJ+snyPmZoJ6JcAjTYLK
TZZJ3mNDhgEYgAEYgIH7M3CIuO7BiAin1Q15L6S+N+UZEDM+jeaJjLPTNDhituIGWDVIs+ejuV2f
K/xWgjoyhxLP6nmGR965/2ZKDakhDMAADMDAh4HLieuVeNsR7TvvHnXbqm6m1fOIeI0ueCUgnbkd
m0i93ebEEdruWE7TUNVgRWuEPZs4DMAADMAADFyPgZ+JayXeHFETuY08S1xnhZZ6zxWqahx3Ear6
OP44NiNxnYnBEdSuP9HYlb/quVsT7K63gVITagIDMAADMNAzEPpLZEYAtR/jWH1Mo7cb2VbZKNB3
fG79HvmbEVI7/oxutzM+zJqP1rejbHqBveJoVltHXLfNmBPX6la9f3+V84p6KKZ5zuYOAzAAAzAA
A9dgQN5cU6hrFIo6UAcYgAEYgAEYgAEYuD4DiOuiv0ce2K8POzWiRjAAAzAAAzAAA0czgLhGXP89
GjLGZyODARiAARiAARh4CwOIa8Q14hoGYAAGYAAGYAAGYKCIAcR1USLf0o0RJzcPMAADMAADMAAD
MDBnAHGNuKZThQEYgAEYgAEYgAEYKGIAcV2USDo4ungYgAEYgAEYgAEYgAHENeKaThUGYAAGYAAG
YAAGYKCIAcR1USLpVOlUYQAGYAAGYAAGYAAGENeIazpVGIABGIABGIABGICBIgYQ10WJpFOlU4UB
GIABGIABGIABGEBcI67pVGEABmAABmAABmAABooYQFwXJZJOlU4VBmAABmAABmAABmAAcY24plOF
ARiAARiAARiAARgoYgBxXZRIOlU6VRiAARiAARiAARiAAcQ14ppOFQZgAAZgAAZgAAZgoIgBxHVR
IulU6VRhAAZgAAZgAAZgAAYQ14hrOlUYgAEYgAEYgAEYgIEiBhDXRYmkU6VThQEYgAEYgAEYgAEY
QFwjrulUYQAGYAAGYAAGYAAGihhAXBclkk6VThUGYAAGYAAGYAAGYABxjbimU4UBGIABGIABGIAB
GChiYCmu//z583f05+iu7DOnmuPrl7I743mbozPm25ljlLczcrmToyiDO/Hs+LlTF97lpgMGYAAG
YAAGnsGAvLnuhcqOcHGgccd37Zw5d2xaP67i0yqeX4nrj087+YnkeWeeXT93WOLdZ2yq1JE6wgAM
wMC7GbituL4KuKPm4yq+jfx4grg+WgDvivMr1x/f3r3hU3/qDwMwAAPHM1Airp1f2yubyEdQVr+6
H91wjj5m0o+RFVTqvYw/KwHcxqLm3hHXfT36sdy4WiGc8fc7r/sbFPWxDsXhSLjv+M0mdvwmRo7J
MQzAAAzAwJUYsMX1TLQ4N6GOzUxEzZK1EjxKiKnnboGUAO1j+gpjZ/6ZTaQJWYlrR2SqmjgNykiE
u/lt7Zycuf6uxu3FNcKaDTvDK+/ADQzAAAy8lwFbXEduEB0hNBMtrpi5grh2P56g8uE0HzOR6uZr
JTxX869ugqNxRX2tFtfReu34y6b63k2V2lN7GIABGHg3A4jrwv+jXeaWfSb4VsJ15zY4KuRXglSJ
TyW+I5tPZCzXr+9vEno/3N9IRPzH9t0bLfWn/jAAAzDwHgYQ14jr//oWD1fIuiJWfVzD2XBcn9zb
abdpUDE6vmPzng2VWlNrGIABGICBS4vryEc/Ih8hiAg1tUgc8aVsorfJb7+5zuTT/Q3ByC7LYaSp
UDEpDnnOZg4DMAADMAAD12Cg5C+R6X+NPvp1u2PTi5Hsr+0d8RzxR33cwxFfSjwpf2aCWo07+8jD
qhlpBea3BrOcqvnbuCK3yiP/+rFGdVEf6XDz3LLn1He1oakcZfPCJnqNTZQ6UAcYgAEYgIGWAXlz
/QZgHPHzhjwQI5sDDMAADMAADMAADOwx8Epx7dxsA9YeWOSP/MEADMAADMAADLyRgVeK6/5jD7OP
n7wRCGJmI4QBGIABGIABGICBPAOvFddAk4eG3JE7GIABGIABGIABGBgzgLj+96v4gIMcwAAMwAAM
wAAMwAAMVDCAuEZc01zAAAzAAAzAAAzAAAwUMYC4LkpkRafDGHTMMAADMAADMAADMHBvBhDXiGs6
VRiAARiAARiAARiAgSIGENdFiaTLvHeXSf2oHwzAAAzAAAzAQAUDiGvENZ0qDMAADMAADMAADMBA
EQOI66JEVnQ6jEHHDAMwAAMwAAMwAAP3ZgBxjbimU4UBGIABGIABGIABGChiAHFdlEi6zHt3mdSP
+sEADMAADMAADFQwgLhGXNOpwgAMwAAMwAAMwAAMFDGAuC5KZEWnwxh0zDAAAzAAAzAAAzBwbwYQ
14hrOlUYgAEYgAEYgAEYgIEiBhDXRYmky7x3l0n9qB8MwAAMwAAMwEAFA4hrxDWdKgzAAAzAAAzA
AAzAQBEDS3H958+fv+pPhcJnDDpFGIABGIABGIABGICBJzCAuC7qUp4AAzGwqcEADMAADMAADMDA
HgN8LARxza+BYAAGYAAGYAAGYAAGihhAXBclki5vr8sjf+QPBmAABmAABmDgCQwgrhHXdKowAAMw
AAMwAAMwAANFDCCuixL5hE6LGLgxgAEYgAEYgAEYgIE9BhDXiGs6VRiAARiAARiAARiAgSIGENdF
iaTL2+vyyB/5gwEYgAEYgAEYeAIDiGvENZ0qDMAADMAADMAADMBAEQOI66JEPqHTIgZuDGAABmAA
BmAABmBgjwHENeKaThUGYAAGYAAGYAAGYKCIAcR1USLp8va6PPJH/mAABmAABmAABp7AAOIacU2n
CgMwAAMwAAMwAAMwUMQA4rookU/otIiBGwMYgAEYgAEYgAEY2GMAcY24plOFARiAARiAARiAARgo
YgBxXZRIury9Lo/8kT8YgAEYgAEYgIEnMIC4RlzTqcIADMAADMAADMAADBQxgLguSuQTOi1i4MYA
BmAABmAABmAABvYYQFwjrulUYQAGYAAGYAAGYAAGihhAXBclki5vr8sjf+QPBmAABmAABmDgCQwg
rhHXdKowAAMwAAMwAAMwAANFDCCuixL5hE6LGLgxgAEYgAEYgAEYgIE9BhDXiGs6VRiAARiAARiA
ARiAgSIGENdFiaTL2+vyyB/5gwEYgAEYgAEYeAIDiGvENZ0qDMAADMAADMAADMBAEQOI66JEPqHT
IgZuDGAABmAABmAABmBgjwHENeKaThUGYAAGYAAGYAAGYKCIAcR1USLp8va6PPJH/mAABmAABmAA
Bp7AAOIacU2nCgMwAAMwAAMwAAMwUMQA4rookU/otIiBGwMYgAEYgAEYgAEY2GMAcY24plOFARiA
ARiAARiAARgoYgBxXZRIury9Lo/8kT8YgAEYgAEYgIEnMIC4RlzTqcIADMAADMAADMAADBQxgLgu
SuQTOi1i4MYABmAABmAABmAABvYYQFwjrulUYQAGYAAGYAAGYAAGihhAXBclki5vr8sjf+QPBmAA
BmAABmDgCQwgrhHXdKowAAMwAAMwAAMwAANFDCCuixL5hE6LGLgxgAEYgAEYgAEYgIE9BhDXiGs6
VRiAARiAARiAARiAgSIGENdFiaTL2+vyyB/5gwEYgAEYgAEYeAIDiGvENZ0qDMAADMAADMAADMBA
EQOI66JEPqHTIgZuDGAABmAABmAABmBgjwHENeKaThUGYAAGYAAGYAAGYKCIAcR1USLp8va6PPJH
/mAABmAABmAABp7AAOIacU2nCgMwAAMwAAMwAAMwUMQA4rookU/otIiBGwMYgAEYgAEYgAEY2GMA
cY24plOFARiAARiAARiAARgoYgBxXZRIury9Lo/8kT8YgAEYgAEYgIEnMIC4RlzTqcIADMAADMAA
DMAADBQxgLguSuQTOi1i4MYABmAABmAABmAABvYYQFwjrulUYQAGYAAGYAAGYAAGihhAXBclki5v
r8sjf+QPBmAABmAABmDgCQwgrhHXdKowAAMwAAMwAAMwAANFDCCuixL5hE6LGLgxgAEYgAEYgAEY
gIE9BhDXiGs6VRiAARiAARiAARiAgSIGENdFiaTL2+vyyB/5gwEYgAEYgAEYeAIDiGvENZ0qDMAA
DMAADMAADMBAEQOI66JEPqHTIgZuDGAABmAABmAABmBgjwHENeKaThUGYAAGYAAGYAAGYKCIAcR1
USLp8va6PPJH/mAABmAABmAABp7AAOIacU2nCgMwAAMwAAMwAAMwUMQA4rookU/otIiBGwMYgAEY
gAEYgAEY2GMAcY24plOFARiAARiAARiAARgoYgBxXZRIury9Lo/8kT8YgAEYgAEYgIEnMIC4RlzT
qcIADMAADMAADMAADBQxgLguSuQTOi1i4MYABmAABmAABmAABvYYWIrr/iH/TQbIABkgA2SADJAB
MkAGyICfgX98UyzJABkgA2SADJABMkAGyAAZWGUAcQ0fZIAMkAEyQAbIABkgA2SgKAOI66JEMgwZ
IANkgAyQATJABsgAGUBcwwAZIANkgAyQATJABsgAGSjKwP8DrVX41Lf8qLIAAAAASUVORK5CYII=
--bcaec53aeea4c3bde804b63c10a0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--bcaec53aeea4c3bde804b63c10a0--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 08:44:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 08:44:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rktmj-0005eK-GA; Wed, 11 Jan 2012 08:43:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rktmh-0005eC-O6
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 08:43:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326271425!8636147!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDQxNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22664 invoked from network); 11 Jan 2012 08:43:45 -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;
	11 Jan 2012 08:43:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; 
   d="scan'208";a="9939021"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 08:43:45 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Jan 2012 08:43:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
Organization: Citrix Systems, Inc.
Date: Wed, 11 Jan 2012 08:43:44 +0000
Message-ID: <1326271424.29084.93.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
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 14 V3] 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

On Tue, 2012-01-10 at 17:07 +0000, Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1326213623 -3600
> # Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
> # Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
> libxl: Introduce a new guest config file parameter
> Use iommu = {1,0} to enable or disable guest iommu emulation.
> Default value is 0.

Please patch docs/man/xl.cfg.pod.5 to explain this new option to the
users, when/why they would enable it etc.

A description of the hardware requirements might be useful, although
perhaps not in that document. Likewise the guest OS requirements. Is
there a passthru page on the wiki which could be amended?

> Signed-off-by: Wei Wang <wei.wang2@amd.com>
[...]
> diff -r 9e89b6485b6c -r 39eb093ea89e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:20 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:23 2012 +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);

I wonder if we should stop adding new stuff to this output, it's for
legacy users anyway.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 08:44:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 08:44:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rktmj-0005eK-GA; Wed, 11 Jan 2012 08:43:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rktmh-0005eC-O6
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 08:43:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326271425!8636147!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDQxNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22664 invoked from network); 11 Jan 2012 08:43:45 -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;
	11 Jan 2012 08:43:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; 
   d="scan'208";a="9939021"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 08:43:45 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 11 Jan 2012 08:43:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Wang <wei.wang2@amd.com>
In-Reply-To: <39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
Organization: Citrix Systems, Inc.
Date: Wed, 11 Jan 2012 08:43:44 +0000
Message-ID: <1326271424.29084.93.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
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 14 V3] 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

On Tue, 2012-01-10 at 17:07 +0000, Wei Wang wrote:
> # HG changeset patch
> # User Wei Wang <wei.wang2@amd.com>
> # Date 1326213623 -3600
> # Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
> # Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
> libxl: Introduce a new guest config file parameter
> Use iommu = {1,0} to enable or disable guest iommu emulation.
> Default value is 0.

Please patch docs/man/xl.cfg.pod.5 to explain this new option to the
users, when/why they would enable it etc.

A description of the hardware requirements might be useful, although
perhaps not in that document. Likewise the guest OS requirements. Is
there a passthru page on the wiki which could be amended?

> Signed-off-by: Wei Wang <wei.wang2@amd.com>
[...]
> diff -r 9e89b6485b6c -r 39eb093ea89e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:20 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:23 2012 +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);

I wonder if we should stop adding new stuff to this output, it's for
legacy users anyway.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 09:08:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 09:08:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rku9m-0005sd-K4; Wed, 11 Jan 2012 09:07:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rku9l-0005sY-Qk
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 09:07:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326272794!60488204!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 26251 invoked from network); 11 Jan 2012 09:06:36 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 09:06:36 -0000
Received: by daec6 with SMTP id c6so2981811dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 01:07: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;
	bh=nQ8cDqV11elYyk3Dcg+pJl0WqWYOoC8YLzYyPSsxzP4=;
	b=Qgnw//o4M90t/6rxyEAjxsRwoOtLnfs0Udb9YPKCdDkABn0G69qxlapnznd+6MKl5C
	cGURWwa3lfF4PbLm9sm2nm7Xe2Ff83crpG48xIg5D++wGD7hrEgzX6pYss5H4JTmI9Cb
	qj7x0x+kBy2nLgKuDzYiKTRps5NqIn8fGquMQ=
MIME-Version: 1.0
Received: by 10.68.189.101 with SMTP id gh5mr1153115pbc.26.1326272858708; Wed,
	11 Jan 2012 01:07:38 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 11 Jan 2012 01:07:38 -0800 (PST)
In-Reply-To: <20236.24922.535085.662049@mariner.uk.xensource.com>
References: <patchbomb.1324370958@alpine.localdomain>
	<20236.24922.535085.662049@mariner.uk.xensource.com>
Date: Wed, 11 Jan 2012 10:07:38 +0100
X-Google-Sender-Auth: 4h5gIyH1keToUHvWkv2QpPOrxhw
Message-ID: <CAPLaKK7F+XbO2xDav8aQNRP00w6meWjV01puYqavtnm_hAumQg@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 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

2012/1/10 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 0 of 4 v3] build: various fixes for building with uclibc and libiconv"):
>> 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.
>
> Applied all four, thanks.

I was waiting to rework #3 once we had a working configure, but thanks
anyway. I will remove the CONFIG_LIBICONV once the configure script is
in.

>
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 09:08:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 09:08:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rku9m-0005sd-K4; Wed, 11 Jan 2012 09:07:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rku9l-0005sY-Qk
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 09:07:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326272794!60488204!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 26251 invoked from network); 11 Jan 2012 09:06:36 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 09:06:36 -0000
Received: by daec6 with SMTP id c6so2981811dae.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 01:07: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;
	bh=nQ8cDqV11elYyk3Dcg+pJl0WqWYOoC8YLzYyPSsxzP4=;
	b=Qgnw//o4M90t/6rxyEAjxsRwoOtLnfs0Udb9YPKCdDkABn0G69qxlapnznd+6MKl5C
	cGURWwa3lfF4PbLm9sm2nm7Xe2Ff83crpG48xIg5D++wGD7hrEgzX6pYss5H4JTmI9Cb
	qj7x0x+kBy2nLgKuDzYiKTRps5NqIn8fGquMQ=
MIME-Version: 1.0
Received: by 10.68.189.101 with SMTP id gh5mr1153115pbc.26.1326272858708; Wed,
	11 Jan 2012 01:07:38 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 11 Jan 2012 01:07:38 -0800 (PST)
In-Reply-To: <20236.24922.535085.662049@mariner.uk.xensource.com>
References: <patchbomb.1324370958@alpine.localdomain>
	<20236.24922.535085.662049@mariner.uk.xensource.com>
Date: Wed, 11 Jan 2012 10:07:38 +0100
X-Google-Sender-Auth: 4h5gIyH1keToUHvWkv2QpPOrxhw
Message-ID: <CAPLaKK7F+XbO2xDav8aQNRP00w6meWjV01puYqavtnm_hAumQg@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 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

2012/1/10 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 0 of 4 v3] build: various fixes for building with uclibc and libiconv"):
>> 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.
>
> Applied all four, thanks.

I was waiting to rework #3 once we had a working configure, but thanks
anyway. I will remove the CONFIG_LIBICONV once the configure script is
in.

>
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 10:05:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkv3N-000798-2z; Wed, 11 Jan 2012 10:05:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <htejun@gmail.com>) id 1Rkk9N-0004MR-MS
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 22:26:37 +0000
X-Env-Sender: htejun@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326234390!10312842!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 31818 invoked from network); 10 Jan 2012 22:26:31 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 22:26:31 -0000
Received: by iabz21 with SMTP id z21so424723iab.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 14:26: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=6PfKNiqPE2pdl3PJwYDgnstAEsqBaAHN8wo4Tg9OLG8=;
	b=SxJpbByLAdJ3GIz6/xPqZYSu2BGobUm9CaYItQ+kQMpvTMoJ9b9tq6aSSqLOEHXsjL
	xS2CZc7sJ6fN3zkPD7wT52N845hKHLfTAKg9SPkwXhnUsZmg2Q6aQeTuElJDwTb2mnxE
	lBPMC1gbH7mRgXM6dQSPeb5fKPacUySka6+0Q=
Received: by 10.42.150.130 with SMTP id a2mr23506829icw.43.1326234389681;
	Tue, 10 Jan 2012 14:26:29 -0800 (PST)
Received: from google.com (wtj.mtv.corp.google.com [172.18.96.96])
	by mx.google.com with ESMTPS id py4sm5048674igc.2.2012.01.10.14.26.27
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 14:26:28 -0800 (PST)
Date: Tue, 10 Jan 2012 14:26:25 -0800
From: Tejun Heo <tj@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120110222625.GA26832@google.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120110202838.GA10402@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 11 Jan 2012 10:05:07 +0000
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 10, 2012 at 03:28:38PM -0500, Konrad Rzeszutek Wilk wrote:
> With that patch I get this when trying to launch a 4GB xen guest:
> 
> kernel="/mnt/lab/latest/vmlinuz"
> ramdisk="/mnt/lab/latest/initramfs.cpio.gz"
> extra="console=hvc0 debug earlyprintk=xen" 
> memory=4096
> maxmem=8192
> vcpus=4
> on_crash="preserve"
> vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
> vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'
> 
> If I change the "memory" to be "4000" it or if I revert the
> mention git commit it boots. This is what I get with the mentioned
> git commit:

Heh, interesting.  Can you please apply the following patch and report
the failing boot log?

Thanks.

diff --git a/mm/memblock.c b/mm/memblock.c
index 2f55f19..978b58eff 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -102,6 +102,10 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
 	/* align @size to avoid excessive fragmentation on reserved array */
 	size = round_up(size, align);
 
+	printk("memblock_find: [0x%llx, 0x%llx) size=%llu align=%llu nid=%d\n",
+	       (unsigned long long)start, (unsigned long long)end,
+	       (unsigned long long)size, (unsigned long long)align, nid);
+
 	/* pump up @end */
 	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
 		end = memblock.current_limit;
@@ -110,13 +114,27 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
 	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
 	end = max(start, end);
 
+	printk("memblock_find: [0x%llx, 0x%llx) - adjusted\n",
+	       (unsigned long long)start, (unsigned long long)end);
+
 	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
+		printk("memblock_find: cand [0x%llx, 0x%llx) -> ",
+		       (unsigned long long)this_start,
+		       (unsigned long long)this_end);
+
 		this_start = clamp(this_start, start, end);
 		this_end = clamp(this_end, start, end);
 
+		printk("[0x%llx, 0x%llx) ",
+		       (unsigned long long)this_start,
+		       (unsigned long long)this_end);
+
 		cand = round_down(this_end - size, align);
-		if (cand >= this_start)
+		if (cand >= this_start) {
+			printk("- success %llx\n", (unsigned long long)cand);
 			return cand;
+		}
+		printk("- rejected\n");
 	}
 	return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 10:05:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10:05:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkv3N-000798-2z; Wed, 11 Jan 2012 10:05:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <htejun@gmail.com>) id 1Rkk9N-0004MR-MS
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 22:26:37 +0000
X-Env-Sender: htejun@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326234390!10312842!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 31818 invoked from network); 10 Jan 2012 22:26:31 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	10 Jan 2012 22:26:31 -0000
Received: by iabz21 with SMTP id z21so424723iab.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 14:26: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=6PfKNiqPE2pdl3PJwYDgnstAEsqBaAHN8wo4Tg9OLG8=;
	b=SxJpbByLAdJ3GIz6/xPqZYSu2BGobUm9CaYItQ+kQMpvTMoJ9b9tq6aSSqLOEHXsjL
	xS2CZc7sJ6fN3zkPD7wT52N845hKHLfTAKg9SPkwXhnUsZmg2Q6aQeTuElJDwTb2mnxE
	lBPMC1gbH7mRgXM6dQSPeb5fKPacUySka6+0Q=
Received: by 10.42.150.130 with SMTP id a2mr23506829icw.43.1326234389681;
	Tue, 10 Jan 2012 14:26:29 -0800 (PST)
Received: from google.com (wtj.mtv.corp.google.com [172.18.96.96])
	by mx.google.com with ESMTPS id py4sm5048674igc.2.2012.01.10.14.26.27
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 14:26:28 -0800 (PST)
Date: Tue, 10 Jan 2012 14:26:25 -0800
From: Tejun Heo <tj@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120110222625.GA26832@google.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120110202838.GA10402@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 11 Jan 2012 10:05:07 +0000
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 10, 2012 at 03:28:38PM -0500, Konrad Rzeszutek Wilk wrote:
> With that patch I get this when trying to launch a 4GB xen guest:
> 
> kernel="/mnt/lab/latest/vmlinuz"
> ramdisk="/mnt/lab/latest/initramfs.cpio.gz"
> extra="console=hvc0 debug earlyprintk=xen" 
> memory=4096
> maxmem=8192
> vcpus=4
> on_crash="preserve"
> vif = [ 'mac=00:0F:4B:00:00:68, bridge=switch' ]
> vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'
> 
> If I change the "memory" to be "4000" it or if I revert the
> mention git commit it boots. This is what I get with the mentioned
> git commit:

Heh, interesting.  Can you please apply the following patch and report
the failing boot log?

Thanks.

diff --git a/mm/memblock.c b/mm/memblock.c
index 2f55f19..978b58eff 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -102,6 +102,10 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
 	/* align @size to avoid excessive fragmentation on reserved array */
 	size = round_up(size, align);
 
+	printk("memblock_find: [0x%llx, 0x%llx) size=%llu align=%llu nid=%d\n",
+	       (unsigned long long)start, (unsigned long long)end,
+	       (unsigned long long)size, (unsigned long long)align, nid);
+
 	/* pump up @end */
 	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
 		end = memblock.current_limit;
@@ -110,13 +114,27 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
 	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
 	end = max(start, end);
 
+	printk("memblock_find: [0x%llx, 0x%llx) - adjusted\n",
+	       (unsigned long long)start, (unsigned long long)end);
+
 	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
+		printk("memblock_find: cand [0x%llx, 0x%llx) -> ",
+		       (unsigned long long)this_start,
+		       (unsigned long long)this_end);
+
 		this_start = clamp(this_start, start, end);
 		this_end = clamp(this_end, start, end);
 
+		printk("[0x%llx, 0x%llx) ",
+		       (unsigned long long)this_start,
+		       (unsigned long long)this_end);
+
 		cand = round_down(this_end - size, align);
-		if (cand >= this_start)
+		if (cand >= this_start) {
+			printk("- success %llx\n", (unsigned long long)cand);
 			return cand;
+		}
+		printk("- rejected\n");
 	}
 	return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 10:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkv3N-00079G-Eu; Wed, 11 Jan 2012 10:05:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <htejun@gmail.com>) id 1Rkl2y-0004vY-GX
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 23:24:04 +0000
X-Env-Sender: htejun@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326237836!10368684!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 2097 invoked from network); 10 Jan 2012 23:23:58 -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;
	10 Jan 2012 23:23:58 -0000
Received: by iabz21 with SMTP id z21so724356iab.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 15:23:56 -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=bz+YpS4FejBghma9BtBtTeDry6DWE3VD/0rF4JeQZH0=;
	b=j6zqXPjbg0YCcx/1SCnmQOV+wbTwzucfVCoE7jBzN2YMwO1WzPd4Xe4rahnK+SO7X7
	mCKHQ0VzLslNdM2iHF7D3vzWNbPsOQpGPoCJvw122cKeIKsafSGBKaJmASVRSyMg5gQo
	IWXHC54mYbVdv8Oa/h4Iu9eZk+6Vj+Hz3Vlck=
Received: by 10.43.53.1 with SMTP id vo1mr28212361icb.2.1326237356819;
	Tue, 10 Jan 2012 15:15:56 -0800 (PST)
Received: from google.com (wtj.mtv.corp.google.com [172.18.96.96])
	by mx.google.com with ESMTPS id h9sm268017353ibh.11.2012.01.10.15.15.54
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 15:15:55 -0800 (PST)
Date: Tue, 10 Jan 2012 15:15:52 -0800
From: Tejun Heo <tj@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120110231552.GB26832@google.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
	<20120110224537.GA6572@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120110224537.GA6572@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 11 Jan 2012 10:05:07 +0000
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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,

On Tue, Jan 10, 2012 at 05:45:37PM -0500, Konrad Rzeszutek Wilk wrote:
> (early) [    0.000000] memblock_find: [0x0, 0xfcdd000) size=8409088 align=4096 nid=1024
> (early) [    0.000000] memblock_find: [0x805000, 0xfcdd000) - adjusted
> (early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0xfcdd000, 0xfcdd000) (early) - rejected
> (early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x1e03000, 0x220a000) (early) - rejected
> (early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x805000, 0x1000000) (early) - rejected
> (early) [    0.000000] memblock_find: cand [0x10000, 0x9b000) -> (early) [0x805000, 0x805000) (early) - rejected
> (early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables

So, it actually is a legitimate alloc failure.  It seems I've tried a
bit too hard at simplifying the allocator.  Does the following fix the
problem?

Thanks.

diff --git a/mm/memblock.c b/mm/memblock.c
index 2f55f19..77b5f22 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -106,14 +106,17 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
 	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
 		end = memblock.current_limit;
 
-	/* adjust @start to avoid underflow and allocating the first page */
-	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
+	/* avoid allocating the first page */
+	start = max_t(phys_addr_t, start, PAGE_SIZE);
 	end = max(start, end);
 
 	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
 		this_start = clamp(this_start, start, end);
 		this_end = clamp(this_end, start, end);
 
+		if (this_end < size)
+			continue;
+
 		cand = round_down(this_end - size, align);
 		if (cand >= this_start)
 			return cand;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 10:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkv3N-00079G-Eu; Wed, 11 Jan 2012 10:05:09 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <htejun@gmail.com>) id 1Rkl2y-0004vY-GX
	for xen-devel@lists.xensource.com; Tue, 10 Jan 2012 23:24:04 +0000
X-Env-Sender: htejun@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326237836!10368684!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 2097 invoked from network); 10 Jan 2012 23:23:58 -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;
	10 Jan 2012 23:23:58 -0000
Received: by iabz21 with SMTP id z21so724356iab.30
	for <xen-devel@lists.xensource.com>;
	Tue, 10 Jan 2012 15:23:56 -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=bz+YpS4FejBghma9BtBtTeDry6DWE3VD/0rF4JeQZH0=;
	b=j6zqXPjbg0YCcx/1SCnmQOV+wbTwzucfVCoE7jBzN2YMwO1WzPd4Xe4rahnK+SO7X7
	mCKHQ0VzLslNdM2iHF7D3vzWNbPsOQpGPoCJvw122cKeIKsafSGBKaJmASVRSyMg5gQo
	IWXHC54mYbVdv8Oa/h4Iu9eZk+6Vj+Hz3Vlck=
Received: by 10.43.53.1 with SMTP id vo1mr28212361icb.2.1326237356819;
	Tue, 10 Jan 2012 15:15:56 -0800 (PST)
Received: from google.com (wtj.mtv.corp.google.com [172.18.96.96])
	by mx.google.com with ESMTPS id h9sm268017353ibh.11.2012.01.10.15.15.54
	(version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 15:15:55 -0800 (PST)
Date: Tue, 10 Jan 2012 15:15:52 -0800
From: Tejun Heo <tj@kernel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120110231552.GB26832@google.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
	<20120110224537.GA6572@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120110224537.GA6572@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 11 Jan 2012 10:05:07 +0000
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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,

On Tue, Jan 10, 2012 at 05:45:37PM -0500, Konrad Rzeszutek Wilk wrote:
> (early) [    0.000000] memblock_find: [0x0, 0xfcdd000) size=8409088 align=4096 nid=1024
> (early) [    0.000000] memblock_find: [0x805000, 0xfcdd000) - adjusted
> (early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0xfcdd000, 0xfcdd000) (early) - rejected
> (early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x1e03000, 0x220a000) (early) - rejected
> (early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x805000, 0x1000000) (early) - rejected
> (early) [    0.000000] memblock_find: cand [0x10000, 0x9b000) -> (early) [0x805000, 0x805000) (early) - rejected
> (early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables

So, it actually is a legitimate alloc failure.  It seems I've tried a
bit too hard at simplifying the allocator.  Does the following fix the
problem?

Thanks.

diff --git a/mm/memblock.c b/mm/memblock.c
index 2f55f19..77b5f22 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -106,14 +106,17 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
 	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
 		end = memblock.current_limit;
 
-	/* adjust @start to avoid underflow and allocating the first page */
-	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
+	/* avoid allocating the first page */
+	start = max_t(phys_addr_t, start, PAGE_SIZE);
 	end = max(start, end);
 
 	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
 		this_start = clamp(this_start, start, end);
 		this_end = clamp(this_end, start, end);
 
+		if (this_end < size)
+			continue;
+
 		cand = round_down(this_end - size, align);
 		if (cand >= this_start)
 			return cand;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 10:18:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10: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 1RkvFb-0007XK-Pw; Wed, 11 Jan 2012 10:17:47 +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 1RkvFa-0007XC-1X
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 10:17:46 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326277059!9980695!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 12007 invoked from network); 11 Jan 2012 10:17:40 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Jan 2012 10:17:40 -0000
Received: from mail77-am1-R.bigfish.com (10.3.201.250) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Jan 2012 10:17:39 +0000
Received: from mail77-am1 (localhost [127.0.0.1])	by mail77-am1-R.bigfish.com
	(Postfix) with ESMTP id DBC9932036B;
	Wed, 11 Jan 2012 10:17:39 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dhc1ahc1bh668h839h)
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 mail77-am1 (localhost.localdomain [127.0.0.1]) by mail77-am1
	(MessageSwitch) id 1326277059710108_10444;
	Wed, 11 Jan 2012 10:17:39 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.254])	by
	mail77-am1.bigfish.com (Postfix) with ESMTP id A00A6400045;
	Wed, 11 Jan 2012 10:17:39 +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, 11 Jan 2012 10:17:38 +0000
X-WSS-ID: 0LXMPX8-02-4BM-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 29B86C814A;	Wed, 11 Jan 2012 04:17:32 -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, 11 Jan 2012 04:17:47 -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, 11 Jan 2012 04:17:36 -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, 11 Jan 2012
	05:17:35 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E34B649C20C; Wed, 11 Jan 2012
	10:17: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 C8B045940FF; Wed, 11 Jan 2012
	11:17:33 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Jan 2012 11:20:00 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1326215226@gran.amd.com>
	<20227.9862.11432.52937@mariner.uk.xensource.com>
	<20236.29029.997206.496297@mariner.uk.xensource.com>
In-Reply-To: <20236.29029.997206.496297@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201111120.05565.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>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest
	config file parameter [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

On Tuesday 10 January 2012 18:12:05 Ian Jackson wrote:
> Wei Wang writes ("[PATCH 14 of 14 V3] libxl: Introduce a new guest config 
file parameter"):
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1326213623 -3600
> > # Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
> > # Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
> > libxl: Introduce a new guest config file parameter
> > Use iommu = {1,0} to enable or disable guest iommu emulation.
> > Default value is 0.
>
> Ian Jackson writes ("Re: [PATCH 15 of 16] libxl: Introduce a new guest 
config file parameter"):
> > Wei Wang writes ("[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.
> >
> > I'm not sure I like this name.  It's confusing because it's not at
> > first glance clear whether it refers to the host's putative iommu, or
> > some kind of provision to the guest.
How about guest_iommu = {1, 0} or ats_passthru = {1, 0}?  Actually the idea of 
the whole patch queue is to enable passthru  for sophisticated ats devices 
(e.g. Tahiti the latest AMD gfx/gpgpu), so that we utilize the device to do 
general-purpose computations in guest. 

> > And it needs documentation, which I hope will answer my other question
> > which is "what is this good for?" :-).

Sure, I am working on the docs now. It will be sent together with the next try 
after I had collected enough comments of this version.

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 Wed Jan 11 10:18:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10: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 1RkvFb-0007XK-Pw; Wed, 11 Jan 2012 10:17:47 +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 1RkvFa-0007XC-1X
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 10:17:46 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326277059!9980695!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 12007 invoked from network); 11 Jan 2012 10:17:40 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Jan 2012 10:17:40 -0000
Received: from mail77-am1-R.bigfish.com (10.3.201.250) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Jan 2012 10:17:39 +0000
Received: from mail77-am1 (localhost [127.0.0.1])	by mail77-am1-R.bigfish.com
	(Postfix) with ESMTP id DBC9932036B;
	Wed, 11 Jan 2012 10:17:39 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N98dK4015Lzz1202hzz8275bhz2dhc1ahc1bh668h839h)
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 mail77-am1 (localhost.localdomain [127.0.0.1]) by mail77-am1
	(MessageSwitch) id 1326277059710108_10444;
	Wed, 11 Jan 2012 10:17:39 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.254])	by
	mail77-am1.bigfish.com (Postfix) with ESMTP id A00A6400045;
	Wed, 11 Jan 2012 10:17:39 +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, 11 Jan 2012 10:17:38 +0000
X-WSS-ID: 0LXMPX8-02-4BM-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 29B86C814A;	Wed, 11 Jan 2012 04:17:32 -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, 11 Jan 2012 04:17:47 -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, 11 Jan 2012 04:17:36 -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, 11 Jan 2012
	05:17:35 -0500
Received: from mail.osrc.amd.com (silizium.osrc.amd.com [165.204.15.142])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E34B649C20C; Wed, 11 Jan 2012
	10:17: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 C8B045940FF; Wed, 11 Jan 2012
	11:17:33 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 11 Jan 2012 11:20:00 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1326215226@gran.amd.com>
	<20227.9862.11432.52937@mariner.uk.xensource.com>
	<20236.29029.997206.496297@mariner.uk.xensource.com>
In-Reply-To: <20236.29029.997206.496297@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201111120.05565.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>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest
	config file parameter [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

On Tuesday 10 January 2012 18:12:05 Ian Jackson wrote:
> Wei Wang writes ("[PATCH 14 of 14 V3] libxl: Introduce a new guest config 
file parameter"):
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1326213623 -3600
> > # Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
> > # Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
> > libxl: Introduce a new guest config file parameter
> > Use iommu = {1,0} to enable or disable guest iommu emulation.
> > Default value is 0.
>
> Ian Jackson writes ("Re: [PATCH 15 of 16] libxl: Introduce a new guest 
config file parameter"):
> > Wei Wang writes ("[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.
> >
> > I'm not sure I like this name.  It's confusing because it's not at
> > first glance clear whether it refers to the host's putative iommu, or
> > some kind of provision to the guest.
How about guest_iommu = {1, 0} or ats_passthru = {1, 0}?  Actually the idea of 
the whole patch queue is to enable passthru  for sophisticated ats devices 
(e.g. Tahiti the latest AMD gfx/gpgpu), so that we utilize the device to do 
general-purpose computations in guest. 

> > And it needs documentation, which I hope will answer my other question
> > which is "what is this good for?" :-).

Sure, I am working on the docs now. It will be sent together with the next try 
after I had collected enough comments of this version.

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 Wed Jan 11 10:22:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkvJG-0007dp-OB; Wed, 11 Jan 2012 10:21:34 +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 1RkvJF-0007de-9B
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 10:21:33 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326277286!10421128!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28370 invoked from network); 11 Jan 2012 10:21:26 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-9.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 10:21:26 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id A9E70673019;
	Wed, 11 Jan 2012 11:19:32 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 80415164B103;
	Wed, 11 Jan 2012 11:19:32 +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 62K2Hdi0hv2s; Wed, 11 Jan 2012 11:19:31 +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 82D95673019;
	Wed, 11 Jan 2012 11:19:31 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: libvir-list@redhat.com
Date: Wed, 11 Jan 2012 11:20:18 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
MIME-Version: 1.0
Message-Id: <201201111121.22236.hahn@univention.de>
Cc: xen-devel@lists.xensource.com, John Levon <john.levon@sun.com>
Subject: [Xen-devel] [BUG,
	PATCH-RFC] libvirt localtime and rtc_timeoffset handling in
	xen-sexpr/sxpr/sxp
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8084545960630526182=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8084545960630526182==
Content-Type: multipart/signed;
  boundary="nextPart1364855.lg51dqPocx";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1364855.lg51dqPocx
Content-Type: multipart/mixed;
  boundary="Boundary-01=_iJWDPu42lbAemiP"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_iJWDPu42lbAemiP
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I'm currently tracking a problem in libvirt regarding Xens handling of=20
localtime and rtc_timeoffset. My current understanding (Xen-3.4.3 and=20
Xen-4.1.2 under Linux) of Xend (the depcrecated Python one still used by=20
libvirt) is as this:
=2D for HV domains, the RTC gets setup to either UTC or localtime depending=
=20
on "/domain/image/hvm/localtime" =C2=B1 "/domain/image/hvm/rtc_offset".
=2D if the OS of a domU changes its RTC, the rtc_offset gets adjusted and i=
s=20
saved in XenStore as "/vm/$UUID/rtc/timeoffset".
=2D if the dom0 accesses its RTC, is accesses the real HW-RTC.
=2D the Xen-Hypervisor initially read the HW-RTC to setup its Wallclock onc=
e,=20
which is than used to simulate the domU RTCs. (The HW-RTC is otherwise only=
=20
accessed on (ACPI-)Suspend and Resume, and with NTP-drift-correction from=20
dom0).
=2D on shut-down the rtc_offset is stored by Xend in=20
the "/var/lib/xend/domains/$uuid/config.sxp" file=20
in "/domain/image/hvm/rtc_timeoffset", from where it is loaded again on nex=
t=20
start.
=2D since PV domains don't have a RTC, they somehow(?) get either initializ=
ed to=20
the localtime or UTC time depending on "/domain/image/linux/localtime".

@xen:
Did I figure out that correct?

@xen:
Is there some documentation on the Xen-sxp domain configuration? For the=20
Python based xen-xm format, I found (and updated)=20
<http://wiki.xen.org/wiki/XenConfigurationFileOptions>, but for Xen-sxp I s=
o=20
far found no documentation, especially on what changed between xen-1, xen-2=
,=20
xen-3.x, xen-4.x.

@libvirt:
Comparing Xend handling to <http://libvirt.org/formatdomain.html#elementsTi=
me>=20
the current translation done by libvirt looks wrong; I think is mandates ba=
ck=20
to the time when Xen supported only PV-domUs:
libvirt translates the Xen configuration to "localtime" and "utc" ignoring=
=20
the "rtc_offset", which exists for HV domains. For localtime=3D0 this=20
translates to libvirts offset=3D"variable"-case, but for localtime=3D1 ther=
e is=20
no matching mapping in libvirt.
Since for PV domains no rtc_timeoffset is tracked, there the mapping to "ut=
c"=20
and "localtime" looks right.


=46or libvirt there was a patch=20
<http://www.redhat.com/archives/libvir-list/2009-January/msg00757.html> whi=
ch=20
added some special handling for "localtime" to be either placed=20
in "/domain/localtime" or "/domain/image/{hvm,linux}/localtime". Xend from=
=20
3.4.3 und 4.1.2 seems to accept either one, but /domain/image/hvm/localtime=
=20
is preferred and overwrites the first one. When reading back the=20
configuration the setting is always returned=20
as /domain/image/{hvm,linux}/localtime.

@John:
Is there a case, where /domain/localtime is returned or is that key=20
always translated to /domain/linux/{hvm,linux}/localtime? As you had a=20
sun.com email address, was this some special case when using Xen with=20
Solaris?

@libvirt:
The attached patch (for 0.8.7) would change the implementation to match the=
=20
following:
1. For Xen-PV-domUs, use clock/@offset=3D'utc' and clock/@offset=3D'localti=
me'.
2. For Xen-HV-domUs, use clock/@offset=3D'variable'.
3. For backward compatibility with old libvirt-XML-files convert=20
clock/@offset=3D'utc' =E2=86=92 (localtime 0)(rtc_timeoffset 0) and=20
clock/@offset=3D'localtime' =E2=86=92 (localtime 1)(rtc_timeosset 0). On re=
adback that=20
will be returned as clock/@offset=3D'variable'!
4. For Xen-HV-domUs with (localtime=3D1)(rtc_timeoffset=E2=89=A00) print a =
warning that=20
there is no mapping to libvirts XML.
5. Always put the (localtime)(rtc_offset)-SEXPRs in "(image ({linux,hvm})",=
=20
since this is where Xend-3.4 and Xend-4.1 return them.
I also checked Xen-3.2, where this is okay, but the I don't have any older=
=20
versions of Xen available (and running), the I can't verify that it still=20
works there.

Which leads me to a another question: Which versions of Xen are still=20
supported by libvirt (and must be checked for regressions)? I don't want so=
=20
actively remove the code for old Xen versions, but it gets harder and harde=
r=20
to maintain all those versions. So a statement like "Xen-3.x and Xen-4.y ar=
e=20
actively supported by libvirt-0.a.b; older versions might still work (by=20
accident ;-)"

Before I forward-port that change to 0.9.10 I'd like to get some comments.=
=20
Thanks in advance.

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/

--Boundary-01=_iJWDPu42lbAemiP
Content-Type: text/x-diff;
  charset="iso-8859-15";
  name="localtime.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="localtime.diff"

diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index 835c230..e112aa3 100644
=2D-- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -903,7 +903,6 @@ xenDaemonListDomainsOld(virConnectPtr xend)
  *
  * Returns 0 for success, -1 (with errno) on error
  */
=2D
 int
 xenDaemonDomainCreateXML(virConnectPtr xend, const char *sexpr)
 {
@@ -2148,7 +2147,6 @@ xenDaemonParseSxpr(virConnectPtr conn,
     } else
         def->onCrash =3D VIR_DOMAIN_LIFECYCLE_DESTROY;
=20
=2D    def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_UTC;
     if (hvm) {
         if (sexpr_int(root, "domain/image/hvm/acpi"))
             def->features |=3D (1 << VIR_DOMAIN_FEATURE_ACPI);
@@ -2157,15 +2155,18 @@ xenDaemonParseSxpr(virConnectPtr conn,
         if (sexpr_int(root, "domain/image/hvm/pae"))
             def->features |=3D (1 << VIR_DOMAIN_FEATURE_PAE);
=20
=2D        /* Old XenD only allows localtime here for HVM */
=2D        if (sexpr_int(root, "domain/image/hvm/localtime"))
+        def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_VARIABLE;
+        def->clock.data.adjustment =3D sexpr_int(root, "domain/image/hvm/r=
tc_timeoffset");
+        if (def->clock.data.adjustment && sexpr_int(root, "domain/image/hv=
m/localtime")) {
+            virXendError(VIR_ERR_INTERNAL_ERROR, _("Ignoring localtime=3D1=
 while rtc_timeoffset!=3D0"));
+        }
+    } else { /* !hvm */
+        if (sexpr_int(root, "domain/image/linux/localtime"))
             def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME;
+        else
+            def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_UTC;
     }
=20
=2D    /* Current XenD allows localtime here, for PV and HVM */
=2D    if (sexpr_int(root, "domain/localtime"))
=2D        def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME;
=2D
     if (sexpr_node_copy(root, hvm ?
                         "domain/image/hvm/device_model" :
                         "domain/image/linux/device_model",
@@ -5759,31 +5760,15 @@ xenDaemonFormatSxpr(virConnectPtr conn,
     }
     virBufferVSprintf(&buf, "(on_crash '%s')", tmp);
=20
=2D    /* Set localtime here for current XenD (both PV & HVM) */
=2D    if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME) {
=2D        if (def->clock.data.timezone) {
=2D            virXendError(VIR_ERR_CONFIG_UNSUPPORTED,
=2D                         "%s", _("configurable timezones are not support=
ed"));
=2D            goto error;
=2D        }
+    if (STREQ(def->os.type, "hvm"))
+        hvm =3D 1;
=20
=2D        virBufferAddLit(&buf, "(localtime 1)");
=2D    } else if (def->clock.offset !=3D VIR_DOMAIN_CLOCK_OFFSET_UTC) {
=2D        virXendError(VIR_ERR_CONFIG_UNSUPPORTED,
=2D                     _("unsupported clock offset '%s'"),
=2D                     virDomainClockOffsetTypeToString(def->clock.offset)=
);
=2D        goto error;
=2D    }
+    if (hvm)
+        virBufferAddLit(&buf, "(image (hvm ");
+    else
+        virBufferAddLit(&buf, "(image (linux ");
=20
     if (!def->os.bootloader) {
=2D        if (STREQ(def->os.type, "hvm"))
=2D            hvm =3D 1;
=2D
=2D        if (hvm)
=2D            virBufferAddLit(&buf, "(image (hvm ");
=2D        else
=2D            virBufferAddLit(&buf, "(image (linux ");
=2D
         if (hvm &&
             def->os.loader =3D=3D NULL) {
             virXendError(VIR_ERR_INTERNAL_ERROR,
@@ -5893,17 +5878,13 @@ xenDaemonFormatSxpr(virConnectPtr conn,
                 virBufferAddLit(&buf, "(serial none)");
             }
=20
=2D            /* Set localtime here to keep old XenD happy for HVM */
=2D            if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTI=
ME)
=2D                virBufferAddLit(&buf, "(localtime 1)");
=2D
             if (def->sounds) {
                 virBufferAddLit(&buf, "(soundhw '");
                 if (xenDaemonFormatSxprSound(def, &buf) < 0)
                     goto error;
                 virBufferAddLit(&buf, "')");
             }
=2D        }
+        } /* hvm */
=20
         /* get the device emulation model */
         if (def->emulator && (hvm || xendConfigVersion >=3D 3))
@@ -5918,10 +5899,37 @@ xenDaemonFormatSxpr(virConnectPtr conn,
                                                &buf, xendConfigVersion) < =
0)
                 goto error;
         }
+    } /* os.bootloader */
+
+    if (hvm) {
+        /* Set localtime here to keep old XenD happy for HVM */
+        if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_VARIABLE) {
+            virBufferVSprintf(&buf, "(localtime 0)(rtc_timeoffset %d)", de=
f->clock.data.adjustment);
+        } else if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_LOCALT=
IME) {
+            if (def->clock.data.timezone) {
+                virXendError(VIR_ERR_CONFIG_UNSUPPORTED,
+                             "%s", _("configurable timezones are not suppo=
rted"));
+                goto error;
+            }
=20
=2D        virBufferAddLit(&buf, "))");
+            virBufferAddLit(&buf, "(localtime 1)(rtc_timeoffset 0)");
+        } else if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_UTC) {
+            virBufferAddLit(&buf, "(localtime 0)(rtc_timeoffset 0)");
+        } else {
+            virXendError(VIR_ERR_CONFIG_UNSUPPORTED,
+                         _("unsupported clock offset '%s'"),
+                         virDomainClockOffsetTypeToString(def->clock.offse=
t));
+            goto error;
+        }
+    } else { /* !hvm */
+        if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME)
+            virBufferAddLit(&buf, "(localtime 1)");
+        else if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_UTC)
+            virBufferAddLit(&buf, "(localtime 0)");
     }
=20
+    virBufferAddLit(&buf, "))"); /* image/{kvm,linux}/ */
+
     for (i =3D 0 ; i < def->ndisks ; i++)
         if (xenDaemonFormatSxprDisk(conn, def->disks[i],
                                     &buf, hvm, xendConfigVersion, 0) < 0)

--Boundary-01=_iJWDPu42lbAemiP--

--nextPart1364855.lg51dqPocx
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)

iEYEABECAAYFAk8NYmIACgkQYPlgoZpUDjkxCACgoeZ/J6dEOk6bt8H13Zf6uz2l
Bt0An2dy19TrrvtDu0IGZa3F3yCKCbVs
=dp1P
-----END PGP SIGNATURE-----

--nextPart1364855.lg51dqPocx--


--===============8084545960630526182==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8084545960630526182==--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 10:22:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkvJG-0007dp-OB; Wed, 11 Jan 2012 10:21:34 +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 1RkvJF-0007de-9B
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 10:21:33 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326277286!10421128!1
X-Originating-IP: [82.198.197.8]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28370 invoked from network); 11 Jan 2012 10:21:26 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-9.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 10:21:26 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id A9E70673019;
	Wed, 11 Jan 2012 11:19:32 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id 80415164B103;
	Wed, 11 Jan 2012 11:19:32 +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 62K2Hdi0hv2s; Wed, 11 Jan 2012 11:19:31 +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 82D95673019;
	Wed, 11 Jan 2012 11:19:31 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: libvir-list@redhat.com
Date: Wed, 11 Jan 2012 11:20:18 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
MIME-Version: 1.0
Message-Id: <201201111121.22236.hahn@univention.de>
Cc: xen-devel@lists.xensource.com, John Levon <john.levon@sun.com>
Subject: [Xen-devel] [BUG,
	PATCH-RFC] libvirt localtime and rtc_timeoffset handling in
	xen-sexpr/sxpr/sxp
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8084545960630526182=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8084545960630526182==
Content-Type: multipart/signed;
  boundary="nextPart1364855.lg51dqPocx";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1364855.lg51dqPocx
Content-Type: multipart/mixed;
  boundary="Boundary-01=_iJWDPu42lbAemiP"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--Boundary-01=_iJWDPu42lbAemiP
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I'm currently tracking a problem in libvirt regarding Xens handling of=20
localtime and rtc_timeoffset. My current understanding (Xen-3.4.3 and=20
Xen-4.1.2 under Linux) of Xend (the depcrecated Python one still used by=20
libvirt) is as this:
=2D for HV domains, the RTC gets setup to either UTC or localtime depending=
=20
on "/domain/image/hvm/localtime" =C2=B1 "/domain/image/hvm/rtc_offset".
=2D if the OS of a domU changes its RTC, the rtc_offset gets adjusted and i=
s=20
saved in XenStore as "/vm/$UUID/rtc/timeoffset".
=2D if the dom0 accesses its RTC, is accesses the real HW-RTC.
=2D the Xen-Hypervisor initially read the HW-RTC to setup its Wallclock onc=
e,=20
which is than used to simulate the domU RTCs. (The HW-RTC is otherwise only=
=20
accessed on (ACPI-)Suspend and Resume, and with NTP-drift-correction from=20
dom0).
=2D on shut-down the rtc_offset is stored by Xend in=20
the "/var/lib/xend/domains/$uuid/config.sxp" file=20
in "/domain/image/hvm/rtc_timeoffset", from where it is loaded again on nex=
t=20
start.
=2D since PV domains don't have a RTC, they somehow(?) get either initializ=
ed to=20
the localtime or UTC time depending on "/domain/image/linux/localtime".

@xen:
Did I figure out that correct?

@xen:
Is there some documentation on the Xen-sxp domain configuration? For the=20
Python based xen-xm format, I found (and updated)=20
<http://wiki.xen.org/wiki/XenConfigurationFileOptions>, but for Xen-sxp I s=
o=20
far found no documentation, especially on what changed between xen-1, xen-2=
,=20
xen-3.x, xen-4.x.

@libvirt:
Comparing Xend handling to <http://libvirt.org/formatdomain.html#elementsTi=
me>=20
the current translation done by libvirt looks wrong; I think is mandates ba=
ck=20
to the time when Xen supported only PV-domUs:
libvirt translates the Xen configuration to "localtime" and "utc" ignoring=
=20
the "rtc_offset", which exists for HV domains. For localtime=3D0 this=20
translates to libvirts offset=3D"variable"-case, but for localtime=3D1 ther=
e is=20
no matching mapping in libvirt.
Since for PV domains no rtc_timeoffset is tracked, there the mapping to "ut=
c"=20
and "localtime" looks right.


=46or libvirt there was a patch=20
<http://www.redhat.com/archives/libvir-list/2009-January/msg00757.html> whi=
ch=20
added some special handling for "localtime" to be either placed=20
in "/domain/localtime" or "/domain/image/{hvm,linux}/localtime". Xend from=
=20
3.4.3 und 4.1.2 seems to accept either one, but /domain/image/hvm/localtime=
=20
is preferred and overwrites the first one. When reading back the=20
configuration the setting is always returned=20
as /domain/image/{hvm,linux}/localtime.

@John:
Is there a case, where /domain/localtime is returned or is that key=20
always translated to /domain/linux/{hvm,linux}/localtime? As you had a=20
sun.com email address, was this some special case when using Xen with=20
Solaris?

@libvirt:
The attached patch (for 0.8.7) would change the implementation to match the=
=20
following:
1. For Xen-PV-domUs, use clock/@offset=3D'utc' and clock/@offset=3D'localti=
me'.
2. For Xen-HV-domUs, use clock/@offset=3D'variable'.
3. For backward compatibility with old libvirt-XML-files convert=20
clock/@offset=3D'utc' =E2=86=92 (localtime 0)(rtc_timeoffset 0) and=20
clock/@offset=3D'localtime' =E2=86=92 (localtime 1)(rtc_timeosset 0). On re=
adback that=20
will be returned as clock/@offset=3D'variable'!
4. For Xen-HV-domUs with (localtime=3D1)(rtc_timeoffset=E2=89=A00) print a =
warning that=20
there is no mapping to libvirts XML.
5. Always put the (localtime)(rtc_offset)-SEXPRs in "(image ({linux,hvm})",=
=20
since this is where Xend-3.4 and Xend-4.1 return them.
I also checked Xen-3.2, where this is okay, but the I don't have any older=
=20
versions of Xen available (and running), the I can't verify that it still=20
works there.

Which leads me to a another question: Which versions of Xen are still=20
supported by libvirt (and must be checked for regressions)? I don't want so=
=20
actively remove the code for old Xen versions, but it gets harder and harde=
r=20
to maintain all those versions. So a statement like "Xen-3.x and Xen-4.y ar=
e=20
actively supported by libvirt-0.a.b; older versions might still work (by=20
accident ;-)"

Before I forward-port that change to 0.9.10 I'd like to get some comments.=
=20
Thanks in advance.

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/

--Boundary-01=_iJWDPu42lbAemiP
Content-Type: text/x-diff;
  charset="iso-8859-15";
  name="localtime.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="localtime.diff"

diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c
index 835c230..e112aa3 100644
=2D-- a/src/xen/xend_internal.c
+++ b/src/xen/xend_internal.c
@@ -903,7 +903,6 @@ xenDaemonListDomainsOld(virConnectPtr xend)
  *
  * Returns 0 for success, -1 (with errno) on error
  */
=2D
 int
 xenDaemonDomainCreateXML(virConnectPtr xend, const char *sexpr)
 {
@@ -2148,7 +2147,6 @@ xenDaemonParseSxpr(virConnectPtr conn,
     } else
         def->onCrash =3D VIR_DOMAIN_LIFECYCLE_DESTROY;
=20
=2D    def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_UTC;
     if (hvm) {
         if (sexpr_int(root, "domain/image/hvm/acpi"))
             def->features |=3D (1 << VIR_DOMAIN_FEATURE_ACPI);
@@ -2157,15 +2155,18 @@ xenDaemonParseSxpr(virConnectPtr conn,
         if (sexpr_int(root, "domain/image/hvm/pae"))
             def->features |=3D (1 << VIR_DOMAIN_FEATURE_PAE);
=20
=2D        /* Old XenD only allows localtime here for HVM */
=2D        if (sexpr_int(root, "domain/image/hvm/localtime"))
+        def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_VARIABLE;
+        def->clock.data.adjustment =3D sexpr_int(root, "domain/image/hvm/r=
tc_timeoffset");
+        if (def->clock.data.adjustment && sexpr_int(root, "domain/image/hv=
m/localtime")) {
+            virXendError(VIR_ERR_INTERNAL_ERROR, _("Ignoring localtime=3D1=
 while rtc_timeoffset!=3D0"));
+        }
+    } else { /* !hvm */
+        if (sexpr_int(root, "domain/image/linux/localtime"))
             def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME;
+        else
+            def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_UTC;
     }
=20
=2D    /* Current XenD allows localtime here, for PV and HVM */
=2D    if (sexpr_int(root, "domain/localtime"))
=2D        def->clock.offset =3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME;
=2D
     if (sexpr_node_copy(root, hvm ?
                         "domain/image/hvm/device_model" :
                         "domain/image/linux/device_model",
@@ -5759,31 +5760,15 @@ xenDaemonFormatSxpr(virConnectPtr conn,
     }
     virBufferVSprintf(&buf, "(on_crash '%s')", tmp);
=20
=2D    /* Set localtime here for current XenD (both PV & HVM) */
=2D    if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME) {
=2D        if (def->clock.data.timezone) {
=2D            virXendError(VIR_ERR_CONFIG_UNSUPPORTED,
=2D                         "%s", _("configurable timezones are not support=
ed"));
=2D            goto error;
=2D        }
+    if (STREQ(def->os.type, "hvm"))
+        hvm =3D 1;
=20
=2D        virBufferAddLit(&buf, "(localtime 1)");
=2D    } else if (def->clock.offset !=3D VIR_DOMAIN_CLOCK_OFFSET_UTC) {
=2D        virXendError(VIR_ERR_CONFIG_UNSUPPORTED,
=2D                     _("unsupported clock offset '%s'"),
=2D                     virDomainClockOffsetTypeToString(def->clock.offset)=
);
=2D        goto error;
=2D    }
+    if (hvm)
+        virBufferAddLit(&buf, "(image (hvm ");
+    else
+        virBufferAddLit(&buf, "(image (linux ");
=20
     if (!def->os.bootloader) {
=2D        if (STREQ(def->os.type, "hvm"))
=2D            hvm =3D 1;
=2D
=2D        if (hvm)
=2D            virBufferAddLit(&buf, "(image (hvm ");
=2D        else
=2D            virBufferAddLit(&buf, "(image (linux ");
=2D
         if (hvm &&
             def->os.loader =3D=3D NULL) {
             virXendError(VIR_ERR_INTERNAL_ERROR,
@@ -5893,17 +5878,13 @@ xenDaemonFormatSxpr(virConnectPtr conn,
                 virBufferAddLit(&buf, "(serial none)");
             }
=20
=2D            /* Set localtime here to keep old XenD happy for HVM */
=2D            if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTI=
ME)
=2D                virBufferAddLit(&buf, "(localtime 1)");
=2D
             if (def->sounds) {
                 virBufferAddLit(&buf, "(soundhw '");
                 if (xenDaemonFormatSxprSound(def, &buf) < 0)
                     goto error;
                 virBufferAddLit(&buf, "')");
             }
=2D        }
+        } /* hvm */
=20
         /* get the device emulation model */
         if (def->emulator && (hvm || xendConfigVersion >=3D 3))
@@ -5918,10 +5899,37 @@ xenDaemonFormatSxpr(virConnectPtr conn,
                                                &buf, xendConfigVersion) < =
0)
                 goto error;
         }
+    } /* os.bootloader */
+
+    if (hvm) {
+        /* Set localtime here to keep old XenD happy for HVM */
+        if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_VARIABLE) {
+            virBufferVSprintf(&buf, "(localtime 0)(rtc_timeoffset %d)", de=
f->clock.data.adjustment);
+        } else if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_LOCALT=
IME) {
+            if (def->clock.data.timezone) {
+                virXendError(VIR_ERR_CONFIG_UNSUPPORTED,
+                             "%s", _("configurable timezones are not suppo=
rted"));
+                goto error;
+            }
=20
=2D        virBufferAddLit(&buf, "))");
+            virBufferAddLit(&buf, "(localtime 1)(rtc_timeoffset 0)");
+        } else if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_UTC) {
+            virBufferAddLit(&buf, "(localtime 0)(rtc_timeoffset 0)");
+        } else {
+            virXendError(VIR_ERR_CONFIG_UNSUPPORTED,
+                         _("unsupported clock offset '%s'"),
+                         virDomainClockOffsetTypeToString(def->clock.offse=
t));
+            goto error;
+        }
+    } else { /* !hvm */
+        if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_LOCALTIME)
+            virBufferAddLit(&buf, "(localtime 1)");
+        else if (def->clock.offset =3D=3D VIR_DOMAIN_CLOCK_OFFSET_UTC)
+            virBufferAddLit(&buf, "(localtime 0)");
     }
=20
+    virBufferAddLit(&buf, "))"); /* image/{kvm,linux}/ */
+
     for (i =3D 0 ; i < def->ndisks ; i++)
         if (xenDaemonFormatSxprDisk(conn, def->disks[i],
                                     &buf, hvm, xendConfigVersion, 0) < 0)

--Boundary-01=_iJWDPu42lbAemiP--

--nextPart1364855.lg51dqPocx
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)

iEYEABECAAYFAk8NYmIACgkQYPlgoZpUDjkxCACgoeZ/J6dEOk6bt8H13Zf6uz2l
Bt0An2dy19TrrvtDu0IGZa3F3yCKCbVs
=dp1P
-----END PGP SIGNATURE-----

--nextPart1364855.lg51dqPocx--


--===============8084545960630526182==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8084545960630526182==--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 10:46:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkvgq-0007vQ-2w; Wed, 11 Jan 2012 10:45:56 +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 1Rkvgo-0007vL-9O
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 10:45:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326278746!8668583!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 28560 invoked from network); 11 Jan 2012 10:45:48 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.12)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Jan 2012 10:45:48 -0000
Received: from mail116-tx2-R.bigfish.com (10.9.14.236) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Jan 2012 10:45:45 +0000
Received: from mail116-tx2 (localhost [127.0.0.1])	by
	mail116-tx2-R.bigfish.com (Postfix) with ESMTP id AB5AE70042C;
	Wed, 11 Jan 2012 10:45:45 +0000 (UTC)
X-SpamScore: -17
X-BigFish: VPS-17(zz936eK1521M1432N98dKzz1202hzz8275bh8275dhz2dhc1ahc1bh668h839h62h)
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
X-FB-SS: 0,
Received: from mail116-tx2 (localhost.localdomain [127.0.0.1]) by mail116-tx2
	(MessageSwitch) id 1326278713325312_5254;
	Wed, 11 Jan 2012 10:45:13 +0000 (UTC)
Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.244])	by
	mail116-tx2.bigfish.com (Postfix) with ESMTP id 3E8B1100042;
	Wed, 11 Jan 2012 10:45:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Jan 2012 10:45:13 +0000
X-WSS-ID: 0LXMR79-01-BTR-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 23F241028007;	Wed, 11 Jan 2012 04:45:09 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 11 Jan 2012 04:45:24 -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, 11 Jan 2012 04:45:12 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 11 Jan 2012
	05:45: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 0FD5849C20C; Wed, 11 Jan 2012
	10:45:11 +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 DADF85940FF; Wed, 11 Jan 2012
	11:45:10 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 11 Jan 2012 11:47:41 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1326215226@gran.amd.com>
	<39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
	<1326271424.29084.93.camel@dagon.hellion.org.uk>
In-Reply-To: <1326271424.29084.93.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201111147.42721.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 14 V3] 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

On Wednesday 11 January 2012 09:43:44 Ian Campbell wrote:
> On Tue, 2012-01-10 at 17:07 +0000, Wei Wang wrote:
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1326213623 -3600
> > # Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
> > # Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
> > libxl: Introduce a new guest config file parameter
> > Use iommu = {1,0} to enable or disable guest iommu emulation.
> > Default value is 0.
>
> Please patch docs/man/xl.cfg.pod.5 to explain this new option to the
> users, when/why they would enable it etc.
Sure, will do that

> A description of the hardware requirements might be useful, although
> perhaps not in that document. Likewise the guest OS requirements. Is
> there a passthru page on the wiki which could be amended?
I could add new section in http://wiki.xen.org/wiki/VTdHowTo 
describing how to use iommu emulation for ats/gpgpu passthru and the hw/sw 
requirement. 

> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
>
> [...]
>
> > diff -r 9e89b6485b6c -r 39eb093ea89e tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:20 2012 +0100
> > +++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:23 2012 +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);
>
> I wonder if we should stop adding new stuff to this output, it's for
> legacy users anyway.
Sounds like I could remove 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 Wed Jan 11 10:46:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 10:46:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkvgq-0007vQ-2w; Wed, 11 Jan 2012 10:45:56 +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 1Rkvgo-0007vL-9O
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 10:45:54 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326278746!8668583!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 28560 invoked from network); 11 Jan 2012 10:45:48 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.12)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Jan 2012 10:45:48 -0000
Received: from mail116-tx2-R.bigfish.com (10.9.14.236) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Jan 2012 10:45:45 +0000
Received: from mail116-tx2 (localhost [127.0.0.1])	by
	mail116-tx2-R.bigfish.com (Postfix) with ESMTP id AB5AE70042C;
	Wed, 11 Jan 2012 10:45:45 +0000 (UTC)
X-SpamScore: -17
X-BigFish: VPS-17(zz936eK1521M1432N98dKzz1202hzz8275bh8275dhz2dhc1ahc1bh668h839h62h)
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
X-FB-SS: 0,
Received: from mail116-tx2 (localhost.localdomain [127.0.0.1]) by mail116-tx2
	(MessageSwitch) id 1326278713325312_5254;
	Wed, 11 Jan 2012 10:45:13 +0000 (UTC)
Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.244])	by
	mail116-tx2.bigfish.com (Postfix) with ESMTP id 3E8B1100042;
	Wed, 11 Jan 2012 10:45:13 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Jan 2012 10:45:13 +0000
X-WSS-ID: 0LXMR79-01-BTR-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 23F241028007;	Wed, 11 Jan 2012 04:45:09 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 11 Jan 2012 04:45:24 -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, 11 Jan 2012 04:45:12 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 11 Jan 2012
	05:45: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 0FD5849C20C; Wed, 11 Jan 2012
	10:45:11 +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 DADF85940FF; Wed, 11 Jan 2012
	11:45:10 +0100 (CET)
From: Wei Wang2 <wei.wang2@amd.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 11 Jan 2012 11:47:41 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
References: <patchbomb.1326215226@gran.amd.com>
	<39eb093ea89eeaa4dbff.1326215240@gran.amd.com>
	<1326271424.29084.93.camel@dagon.hellion.org.uk>
In-Reply-To: <1326271424.29084.93.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
Message-ID: <201201111147.42721.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 14 V3] 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

On Wednesday 11 January 2012 09:43:44 Ian Campbell wrote:
> On Tue, 2012-01-10 at 17:07 +0000, Wei Wang wrote:
> > # HG changeset patch
> > # User Wei Wang <wei.wang2@amd.com>
> > # Date 1326213623 -3600
> > # Node ID 39eb093ea89eeaa4dbff29439499f2a289291ff0
> > # Parent  9e89b6485b6c91a8d563c46c47a8d768eee7d1f2
> > libxl: Introduce a new guest config file parameter
> > Use iommu = {1,0} to enable or disable guest iommu emulation.
> > Default value is 0.
>
> Please patch docs/man/xl.cfg.pod.5 to explain this new option to the
> users, when/why they would enable it etc.
Sure, will do that

> A description of the hardware requirements might be useful, although
> perhaps not in that document. Likewise the guest OS requirements. Is
> there a passthru page on the wiki which could be amended?
I could add new section in http://wiki.xen.org/wiki/VTdHowTo 
describing how to use iommu emulation for ats/gpgpu passthru and the hw/sw 
requirement. 

> > Signed-off-by: Wei Wang <wei.wang2@amd.com>
>
> [...]
>
> > diff -r 9e89b6485b6c -r 39eb093ea89e tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:20 2012 +0100
> > +++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:40:23 2012 +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);
>
> I wonder if we should stop adding new stuff to this output, it's for
> legacy users anyway.
Sounds like I could remove 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 Wed Jan 11 11:05:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 11:05:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkvzM-00088g-Ru; Wed, 11 Jan 2012 11:05:04 +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 1RkvzL-00088Y-ND; Wed, 11 Jan 2012 11:05:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326279897!10458985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23662 invoked from network); 11 Jan 2012 11:04:57 -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;
	11 Jan 2012 11:04:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; 
   d="scan'208";a="9942904"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 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;
	Wed, 11 Jan 2012 11:04:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-users@lists.xensource.com>, <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 11:04:57 +0000
In-Reply-To: <4F0C4754.1090702@xen.org>
References: <4F0C4754.1090702@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326279897.17210.173.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@xen.org>
Subject: [Xen-devel] FOSDEM: Deploying Xen: troubleshooting surgery &
 discussion with Xen.org developers (Was: Virtualization and Cloud Devroom
 agenda 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, 2012-01-10 at 14:12 +0000, Lars Kurth wrote:
> Please see:
> http://fosdem.org/2012/schedule/track/virtualization_and_cloud_devroom

This program includes "Deploying Xen: troubleshooting surgery &
discussion with Xen.org developers"[0].

This session will consist of a short presentation of some of the current
and future user-visible changes to Xen followed by a chance for members
of the audience to quiz a panel of Xen developers and expert users.

We would like to discuss the real-world issues and decisions which
people face when deploying Xen and attempt to provide advice and
guidance on next steps, trouble-shooting tips etc as well help identify
areas for improvement and what can be done to help address them. Maybe
we'll even manage to solve some real bugs along the way!

The panel will include (at least) folks knowledgeable about XCP
(including xapi & Project Kronos), the xl/libxl toolstack, the
hypervisor, PVops Linux.

So if you are attending FOSDEM and please feel to come along and pick
our collective brains. 

Likewise if you are a developer or experienced user you are very welcome
to either sit on the panel or participate from the floor. In particular
if you have experience outside the above areas that would be very
useful. If you'd like to be on the panel please let me know!

Thanks,

Ian.

[0] http://fosdem.org/2012/schedule/event/xen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 11:05:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 11:05:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkvzM-00088g-Ru; Wed, 11 Jan 2012 11:05:04 +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 1RkvzL-00088Y-ND; Wed, 11 Jan 2012 11:05:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326279897!10458985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23662 invoked from network); 11 Jan 2012 11:04:57 -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;
	11 Jan 2012 11:04:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; 
   d="scan'208";a="9942904"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 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;
	Wed, 11 Jan 2012 11:04:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-users@lists.xensource.com>, <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 11:04:57 +0000
In-Reply-To: <4F0C4754.1090702@xen.org>
References: <4F0C4754.1090702@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326279897.17210.173.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Lars Kurth <lars.kurth@xen.org>
Subject: [Xen-devel] FOSDEM: Deploying Xen: troubleshooting surgery &
 discussion with Xen.org developers (Was: Virtualization and Cloud Devroom
 agenda 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, 2012-01-10 at 14:12 +0000, Lars Kurth wrote:
> Please see:
> http://fosdem.org/2012/schedule/track/virtualization_and_cloud_devroom

This program includes "Deploying Xen: troubleshooting surgery &
discussion with Xen.org developers"[0].

This session will consist of a short presentation of some of the current
and future user-visible changes to Xen followed by a chance for members
of the audience to quiz a panel of Xen developers and expert users.

We would like to discuss the real-world issues and decisions which
people face when deploying Xen and attempt to provide advice and
guidance on next steps, trouble-shooting tips etc as well help identify
areas for improvement and what can be done to help address them. Maybe
we'll even manage to solve some real bugs along the way!

The panel will include (at least) folks knowledgeable about XCP
(including xapi & Project Kronos), the xl/libxl toolstack, the
hypervisor, PVops Linux.

So if you are attending FOSDEM and please feel to come along and pick
our collective brains. 

Likewise if you are a developer or experienced user you are very welcome
to either sit on the panel or participate from the floor. In particular
if you have experience outside the above areas that would be very
useful. If you'd like to be on the panel please let me know!

Thanks,

Ian.

[0] http://fosdem.org/2012/schedule/event/xen


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 11:28:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 11:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkwLQ-0000Jl-01; Wed, 11 Jan 2012 11:27:52 +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 1RkwLP-0000Jd-1C
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 11:27:51 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326281263!7334383!1
X-Originating-IP: [209.85.161.171]
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 10239 invoked from network); 11 Jan 2012 11:27:44 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 11:27:44 -0000
Received: by ggnh1 with SMTP id h1so5424376ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 03:27: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=LdtY1EI0GfcPKcKHpK/k1xrQanJ6kuEntiy4iDmTkY4=;
	b=FwnOj91E99IiDhSu0o1CkbNYI9x16H/PRFOA3qWAGzC25RtBMTC7AlSoRqaCfjllib
	Hp7SUaEZ4bz3yedKg+pJBMtFW3879TTXn5yVi4vWlcdBCNyDx7ZUKxn4rc8ZN8i7ewhC
	tf8zeDHYUxdVC4li4jo0bHsLXUpD6ySppda/c=
MIME-Version: 1.0
Received: by 10.50.182.199 with SMTP id eg7mr6367465igc.22.1326281262949; Wed,
	11 Jan 2012 03:27:42 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Wed, 11 Jan 2012 03:27:42 -0800 (PST)
In-Reply-To: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
References: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
Date: Wed, 11 Jan 2012 11:27:42 +0000
X-Google-Sender-Auth: a_ymY2JDIhIHHxkbTOmZO9zffWA
Message-ID: <CAFLBxZbtqJ9sFPnDTVxioZodWEydiZVjOV_iXDsBksm9WdxWgQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Yufang Zhang <yufang521247@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Cannot start up HVM guest when maxmem is not equal
 to memory and HAP is enabled.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 8:03 AM, Yufang Zhang <yufang521247@gmail.com> wrot=
e:
> Hi all,
>
> On my production deployment with xen-3.4.4-rc1, HVM guest would not start=
 up
> when maxmem is set not equal to memory, unless=A0HAP is disable(hap=3D0).=
 The
> guest just hangs at 'Booting from Hard Disk...' as shown in the attachmen=
t.

Is there a reason you want to set maxmem !=3D memory?  Starting in 4.0,
this will cause the VM to boot in "populate-on-demand" mode; but I
think in 3.4, this may have undefined behavior.

> I find that both Oracle VM and Fedora have the same problem per the
> following links:
>
> http://docs.oracle.com/cd/E15458_01/doc.22/e15443/toc.htm#BABBIBFD
> http://docs.oracle.com/cd/E26996_01/e18546/CJAGDAGB.html#id419003
> https://bugzilla.redhat.com/show_bug.cgi?id=3D645319
>
> Could I ask if there is any work in upstream/xen-unstable to fix this
> problem?

Setting maxmem !=3D memory in 4.1 will definitely have a different
effect -- if your guest has a balloon driver, you will start your VM
"pre-ballooned"; if your guest does not, it will crash as soon as it
dirties more than "memory" amount of memory.

 -George

>
> Thanks.
>
> Below is the xm dmesg output related with the hvm guest:
> (XEN) HVM3: HVM Loader
> (XEN) HVM3: Detected Xen v3.4.4-rc1-pre
> (XEN) HVM3: CPU speed is 2267 MHz
> (XEN) irq.c:243: Dom3 PCI link 0 changed 0 -> 5
> (XEN) HVM3: PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:243: Dom3 PCI link 1 changed 0 -> 10
> (XEN) HVM3: PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:243: Dom3 PCI link 2 changed 0 -> 11
> (XEN) HVM3: PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:243: Dom3 PCI link 3 changed 0 -> 5
> (XEN) HVM3: PCI-ISA link 3 routed to IRQ5
> (XEN) HVM3: pci dev 01:2 INTD->IRQ5
> (XEN) HVM3: pci dev 01:3 INTA->IRQ10
> (XEN) HVM3: pci dev 03:0 INTA->IRQ5
> (XEN) HVM3: pci dev 04:0 INTA->IRQ5
> (XEN) HVM3: pci dev 02:0 bar 10 size 02000000: f0000008
> (XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008
> (XEN) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000
> (XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001
> (XEN) HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101
> (XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000
> (XEN) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201
> (XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c221
> (XEN) HVM3: Multiprocessor initialisation:
> (XEN) HVM3: =A0- CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8]=
 ...
> done.
> (XEN) HVM3: Writing SMBIOS tables ...
> (XEN) HVM3: Loading ROMBIOS ...
> (XEN) HVM3: 10332 bytes of ROMBIOS high-memory extensions:
> (XEN) HVM3: =A0 Relocating to 0xfc000000-0xfc00285c ... done
> (XEN) HVM3: Creating MP tables ...
> (XEN) HVM3: Loading Cirrus VGABIOS ...
> (XEN) HVM3: Loading PCI Option ROM ...
> (XEN) HVM3: =A0- Manufacturer: http://etherboot.org
> (XEN) HVM3: =A0- Product name: gPXE
> (XEN) HVM3: Loading ACPI ...
> (XEN) HVM3: =A0- Lo data: 000ea020-000ea04f
> (XEN) HVM3: =A0- Hi data: fc002c00-fc0060bf
> (XEN) HVM3: vm86 TSS at fc006400
> (XEN) HVM3: BIOS map:
> (XEN) HVM3: =A0c0000-c8fff: VGA BIOS
> (XEN) HVM3: =A0c9000-d57ff: Etherboot ROM
> (XEN) HVM3: =A0eb000-eb150: SMBIOS tables
> (XEN) HVM3: =A0f0000-fffff: Main BIOS
> (XEN) HVM3: Invoking ROMBIOS ...
> (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) stdvga.c:147:d3 entering stdvga and caching modes
> (XEN) HVM3: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Ex=
p $
> (XEN) HVM3: Bochs BIOS - build: 06/23/99
> (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) HVM3: Options: apmbios pcibios eltorito PMM
> (XEN) HVM3:
> (XEN) HVM3: ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255/=
63
> (XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)
> (XEN) HVM3: IDE time out
> (XEN) HVM3:
> (XEN) HVM3:
> (XEN) HVM3:
> (XEN) HVM3: Press F12 for boot menu.
> (XEN) HVM3:
> (XEN) HVM3: Booting from Hard Disk...
> (XEN) HVM3: Booting from 0000:7c00
> (XEN) io.c:199:d3 MMIO emulation failed @ 0008:4013b1: 90 86 95 21 08 83
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 11 11:28:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 11:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkwLQ-0000Jl-01; Wed, 11 Jan 2012 11:27:52 +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 1RkwLP-0000Jd-1C
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 11:27:51 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326281263!7334383!1
X-Originating-IP: [209.85.161.171]
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 10239 invoked from network); 11 Jan 2012 11:27:44 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 11:27:44 -0000
Received: by ggnh1 with SMTP id h1so5424376ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 03:27: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=LdtY1EI0GfcPKcKHpK/k1xrQanJ6kuEntiy4iDmTkY4=;
	b=FwnOj91E99IiDhSu0o1CkbNYI9x16H/PRFOA3qWAGzC25RtBMTC7AlSoRqaCfjllib
	Hp7SUaEZ4bz3yedKg+pJBMtFW3879TTXn5yVi4vWlcdBCNyDx7ZUKxn4rc8ZN8i7ewhC
	tf8zeDHYUxdVC4li4jo0bHsLXUpD6ySppda/c=
MIME-Version: 1.0
Received: by 10.50.182.199 with SMTP id eg7mr6367465igc.22.1326281262949; Wed,
	11 Jan 2012 03:27:42 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Wed, 11 Jan 2012 03:27:42 -0800 (PST)
In-Reply-To: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
References: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
Date: Wed, 11 Jan 2012 11:27:42 +0000
X-Google-Sender-Auth: a_ymY2JDIhIHHxkbTOmZO9zffWA
Message-ID: <CAFLBxZbtqJ9sFPnDTVxioZodWEydiZVjOV_iXDsBksm9WdxWgQ@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Yufang Zhang <yufang521247@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Cannot start up HVM guest when maxmem is not equal
 to memory and HAP is enabled.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 8:03 AM, Yufang Zhang <yufang521247@gmail.com> wrot=
e:
> Hi all,
>
> On my production deployment with xen-3.4.4-rc1, HVM guest would not start=
 up
> when maxmem is set not equal to memory, unless=A0HAP is disable(hap=3D0).=
 The
> guest just hangs at 'Booting from Hard Disk...' as shown in the attachmen=
t.

Is there a reason you want to set maxmem !=3D memory?  Starting in 4.0,
this will cause the VM to boot in "populate-on-demand" mode; but I
think in 3.4, this may have undefined behavior.

> I find that both Oracle VM and Fedora have the same problem per the
> following links:
>
> http://docs.oracle.com/cd/E15458_01/doc.22/e15443/toc.htm#BABBIBFD
> http://docs.oracle.com/cd/E26996_01/e18546/CJAGDAGB.html#id419003
> https://bugzilla.redhat.com/show_bug.cgi?id=3D645319
>
> Could I ask if there is any work in upstream/xen-unstable to fix this
> problem?

Setting maxmem !=3D memory in 4.1 will definitely have a different
effect -- if your guest has a balloon driver, you will start your VM
"pre-ballooned"; if your guest does not, it will crash as soon as it
dirties more than "memory" amount of memory.

 -George

>
> Thanks.
>
> Below is the xm dmesg output related with the hvm guest:
> (XEN) HVM3: HVM Loader
> (XEN) HVM3: Detected Xen v3.4.4-rc1-pre
> (XEN) HVM3: CPU speed is 2267 MHz
> (XEN) irq.c:243: Dom3 PCI link 0 changed 0 -> 5
> (XEN) HVM3: PCI-ISA link 0 routed to IRQ5
> (XEN) irq.c:243: Dom3 PCI link 1 changed 0 -> 10
> (XEN) HVM3: PCI-ISA link 1 routed to IRQ10
> (XEN) irq.c:243: Dom3 PCI link 2 changed 0 -> 11
> (XEN) HVM3: PCI-ISA link 2 routed to IRQ11
> (XEN) irq.c:243: Dom3 PCI link 3 changed 0 -> 5
> (XEN) HVM3: PCI-ISA link 3 routed to IRQ5
> (XEN) HVM3: pci dev 01:2 INTD->IRQ5
> (XEN) HVM3: pci dev 01:3 INTA->IRQ10
> (XEN) HVM3: pci dev 03:0 INTA->IRQ5
> (XEN) HVM3: pci dev 04:0 INTA->IRQ5
> (XEN) HVM3: pci dev 02:0 bar 10 size 02000000: f0000008
> (XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008
> (XEN) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000
> (XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001
> (XEN) HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101
> (XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000
> (XEN) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201
> (XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c221
> (XEN) HVM3: Multiprocessor initialisation:
> (XEN) HVM3: =A0- CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8]=
 ...
> done.
> (XEN) HVM3: Writing SMBIOS tables ...
> (XEN) HVM3: Loading ROMBIOS ...
> (XEN) HVM3: 10332 bytes of ROMBIOS high-memory extensions:
> (XEN) HVM3: =A0 Relocating to 0xfc000000-0xfc00285c ... done
> (XEN) HVM3: Creating MP tables ...
> (XEN) HVM3: Loading Cirrus VGABIOS ...
> (XEN) HVM3: Loading PCI Option ROM ...
> (XEN) HVM3: =A0- Manufacturer: http://etherboot.org
> (XEN) HVM3: =A0- Product name: gPXE
> (XEN) HVM3: Loading ACPI ...
> (XEN) HVM3: =A0- Lo data: 000ea020-000ea04f
> (XEN) HVM3: =A0- Hi data: fc002c00-fc0060bf
> (XEN) HVM3: vm86 TSS at fc006400
> (XEN) HVM3: BIOS map:
> (XEN) HVM3: =A0c0000-c8fff: VGA BIOS
> (XEN) HVM3: =A0c9000-d57ff: Etherboot ROM
> (XEN) HVM3: =A0eb000-eb150: SMBIOS tables
> (XEN) HVM3: =A0f0000-fffff: Main BIOS
> (XEN) HVM3: Invoking ROMBIOS ...
> (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) stdvga.c:147:d3 entering stdvga and caching modes
> (XEN) HVM3: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Ex=
p $
> (XEN) HVM3: Bochs BIOS - build: 06/23/99
> (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> (XEN) HVM3: Options: apmbios pcibios eltorito PMM
> (XEN) HVM3:
> (XEN) HVM3: ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/255/=
63
> (XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)
> (XEN) HVM3: IDE time out
> (XEN) HVM3:
> (XEN) HVM3:
> (XEN) HVM3:
> (XEN) HVM3: Press F12 for boot menu.
> (XEN) HVM3:
> (XEN) HVM3: Booting from Hard Disk...
> (XEN) HVM3: Booting from 0000:7c00
> (XEN) io.c:199:d3 MMIO emulation failed @ 0008:4013b1: 90 86 95 21 08 83
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 11 11:51:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 11:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkwhw-0000WS-5F; Wed, 11 Jan 2012 11:51:08 +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 1Rkwhu-0000WN-Dr
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 11:51:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326282658!10477100!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 31601 invoked from network); 11 Jan 2012 11:51:00 -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;
	11 Jan 2012 11:51:00 -0000
Received: by pbbb11 with SMTP id b11so4127362pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 03:50: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=aCR4lqn0e7VdV16nXuYt0m7kNcYQIXYiFPHQf7wRWAk=;
	b=rot8Nq4N5xeb3Gd7F+S4v7hASxWpvImkKER97zI2SO2/XQvFvCeVgtx6o7QNYgX3ZH
	nomp1f5edflBEFmGp4h/h0AH7e+LAY6HypAvg3erM+z/n2djX0W6DnokkmC5yLJYvcYm
	ya8ua3FwTwl2eZgYYEmqhCNPAPRqDUdmrkEMc=
MIME-Version: 1.0
Received: by 10.68.75.199 with SMTP id e7mr60512986pbw.128.1326282658139; Wed,
	11 Jan 2012 03:50:58 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 11 Jan 2012 03:50:57 -0800 (PST)
In-Reply-To: <20236.28931.127139.752426@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
Date: Wed, 11 Jan 2012 12:50:57 +0100
X-Google-Sender-Auth: DcwisGX5Arbf2SaFgiyJhm8-Q8g
Message-ID: <CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@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,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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,

This comes from my experience with Xen and hotplug scripts, and it
might be wrong, since I wasn't able to find any document explaining
exactly how hotplug execution works and who does what. I'm gonna try
to list the sequence of events that happens when a device is added (I
really don't want to keep on with the discusion if this is a protocol
or not):

1. Toolstack writes: /local/domain/0/backend/<vbd or vif>/... with "state = 1".
2. Kernel acks xenstore backend device creation, creates the device
and sets backend "state = 2".
3. xenbackendd notices backend device with "state == 2" and launches
hotplug script.
4. Hotplug script executes necessary actions and sets backend
"hotplug-status = connected".
5. Kernel notices "hotplug-status == connected", plugs the device, and
sets xenstore backend device "state = 4".

This is true on NetBSD, because there aren't any userspace hotplug
devices, someone should probably add the missing bits if the device is
implemented in userspace (I'm not really sure of what happens inside
the kernel in #2 and #5, specially when using blktap or qdisk).

Regarding device shutdown/destroy:

1. Guest sets frontend state to 6 (closed)
2. Kernel unplugs the device and sets backend "state = 6".
3. xenbackendd notices device with "state == 6", and performs the
necessary cleanup.
3. Toolstack notices device with "state == 6" and removes xenstore
backend entries.

Notice that I've used two #3, that's where the race condition happens,
because there's no synchronization between toolstack and
hotplug/xenbackendd to know when hotplug scripts have been executed
(however we should be able to synchronize this watching
"hotplug-status" instead of "state", and waiting for it to change to
"disconnected").

Now, we have to decide how to fix the shutdown/destroy race and how to
implement this outside of the Dom0. I'm not really sure if it's a good
idea to try so hard to keep this flow intact, I think it's best to try
to define a flow that solves our current problems, regardless of how
things are now, and then try to map both flows to see what should be
changed and how.

Since the device will be plugged from a Domain different than Dom0,
the toolstack doesn't really (and probably shouldn't) know anything
about which backend type will be used (phy, blktap, qdisk...). Having
that in mind, I don't know how can we write
/local/domain/<driverdom_id>/backend/... from Dom0, instead we should
create something like:

/hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/params
/hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/script
/hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/state
[This seem like the minimum necessary parameters, but probably there
are others, so add what you feel necessary]

With that the driver domain should be able to create
/local/domain/<driverdomain_id>/backend/... and the frontend also.

I'm not sure if we should control the execution of hotplug scripts
from Dom0, or instead let the driver domain decide when it's best to
execute each script. This adds /hotplug to xenstore, but the
plug/unplug sequence could be the same as the one we currently have,
the only change is that each driver domain is in charge of writing
it's own xenstore backend/frontend entries to trigger the plug
sequence.

Hope that helps, Roger.

(xen-devel mailing list was removed at some point during the
conversation, so I'm adding it again)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 11:51:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 11:51:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkwhw-0000WS-5F; Wed, 11 Jan 2012 11:51:08 +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 1Rkwhu-0000WN-Dr
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 11:51:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326282658!10477100!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 31601 invoked from network); 11 Jan 2012 11:51:00 -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;
	11 Jan 2012 11:51:00 -0000
Received: by pbbb11 with SMTP id b11so4127362pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 03:50: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=aCR4lqn0e7VdV16nXuYt0m7kNcYQIXYiFPHQf7wRWAk=;
	b=rot8Nq4N5xeb3Gd7F+S4v7hASxWpvImkKER97zI2SO2/XQvFvCeVgtx6o7QNYgX3ZH
	nomp1f5edflBEFmGp4h/h0AH7e+LAY6HypAvg3erM+z/n2djX0W6DnokkmC5yLJYvcYm
	ya8ua3FwTwl2eZgYYEmqhCNPAPRqDUdmrkEMc=
MIME-Version: 1.0
Received: by 10.68.75.199 with SMTP id e7mr60512986pbw.128.1326282658139; Wed,
	11 Jan 2012 03:50:58 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 11 Jan 2012 03:50:57 -0800 (PST)
In-Reply-To: <20236.28931.127139.752426@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
Date: Wed, 11 Jan 2012 12:50:57 +0100
X-Google-Sender-Auth: DcwisGX5Arbf2SaFgiyJhm8-Q8g
Message-ID: <CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@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,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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,

This comes from my experience with Xen and hotplug scripts, and it
might be wrong, since I wasn't able to find any document explaining
exactly how hotplug execution works and who does what. I'm gonna try
to list the sequence of events that happens when a device is added (I
really don't want to keep on with the discusion if this is a protocol
or not):

1. Toolstack writes: /local/domain/0/backend/<vbd or vif>/... with "state = 1".
2. Kernel acks xenstore backend device creation, creates the device
and sets backend "state = 2".
3. xenbackendd notices backend device with "state == 2" and launches
hotplug script.
4. Hotplug script executes necessary actions and sets backend
"hotplug-status = connected".
5. Kernel notices "hotplug-status == connected", plugs the device, and
sets xenstore backend device "state = 4".

This is true on NetBSD, because there aren't any userspace hotplug
devices, someone should probably add the missing bits if the device is
implemented in userspace (I'm not really sure of what happens inside
the kernel in #2 and #5, specially when using blktap or qdisk).

Regarding device shutdown/destroy:

1. Guest sets frontend state to 6 (closed)
2. Kernel unplugs the device and sets backend "state = 6".
3. xenbackendd notices device with "state == 6", and performs the
necessary cleanup.
3. Toolstack notices device with "state == 6" and removes xenstore
backend entries.

Notice that I've used two #3, that's where the race condition happens,
because there's no synchronization between toolstack and
hotplug/xenbackendd to know when hotplug scripts have been executed
(however we should be able to synchronize this watching
"hotplug-status" instead of "state", and waiting for it to change to
"disconnected").

Now, we have to decide how to fix the shutdown/destroy race and how to
implement this outside of the Dom0. I'm not really sure if it's a good
idea to try so hard to keep this flow intact, I think it's best to try
to define a flow that solves our current problems, regardless of how
things are now, and then try to map both flows to see what should be
changed and how.

Since the device will be plugged from a Domain different than Dom0,
the toolstack doesn't really (and probably shouldn't) know anything
about which backend type will be used (phy, blktap, qdisk...). Having
that in mind, I don't know how can we write
/local/domain/<driverdom_id>/backend/... from Dom0, instead we should
create something like:

/hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/params
/hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/script
/hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/state
[This seem like the minimum necessary parameters, but probably there
are others, so add what you feel necessary]

With that the driver domain should be able to create
/local/domain/<driverdomain_id>/backend/... and the frontend also.

I'm not sure if we should control the execution of hotplug scripts
from Dom0, or instead let the driver domain decide when it's best to
execute each script. This adds /hotplug to xenstore, but the
plug/unplug sequence could be the same as the one we currently have,
the only change is that each driver domain is in charge of writing
it's own xenstore backend/frontend entries to trigger the plug
sequence.

Hope that helps, Roger.

(xen-devel mailing list was removed at some point during the
conversation, so I'm adding it again)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 11:54:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 11:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkwku-0000cR-OE; Wed, 11 Jan 2012 11:54: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 1Rkwks-0000cD-TK
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 11:54:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326282844!10546491!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20493 invoked from network); 11 Jan 2012 11:54:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 11:54:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; 
   d="scan'208";a="9944565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:54: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, 11 Jan 2012 11:54:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Wed, 11 Jan 2012 11:54:04 +0000
In-Reply-To: <201201111121.22236.hahn@univention.de>
References: <201201111121.22236.hahn@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326282844.17210.190.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>,
	John Levon <john.levon@sun.com>
Subject: Re: [Xen-devel] [BUG,
 PATCH-RFC] libvirt localtime and rtc_timeoffset handling
 in	xen-sexpr/sxpr/sxp
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTExIGF0IDEwOjIwICswMDAwLCBQaGlsaXBwIEhhaG4gd3JvdGU6Cj4g
SGVsbG8sCj4gCj4gSSdtIGN1cnJlbnRseSB0cmFja2luZyBhIHByb2JsZW0gaW4gbGlidmlydCBy
ZWdhcmRpbmcgWGVucyBoYW5kbGluZyBvZiAKPiBsb2NhbHRpbWUgYW5kIHJ0Y190aW1lb2Zmc2V0
LiBNeSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgKFhlbi0zLjQuMyBhbmQgCj4gWGVuLTQuMS4yIHVu
ZGVyIExpbnV4KSBvZiBYZW5kICh0aGUgZGVwY3JlY2F0ZWQgUHl0aG9uIG9uZSBzdGlsbCB1c2Vk
IGJ5IAo+IGxpYnZpcnQpIGlzIGFzIHRoaXM6Cj4gLSBmb3IgSFYgZG9tYWlucywgdGhlIFJUQyBn
ZXRzIHNldHVwIHRvIGVpdGhlciBVVEMgb3IgbG9jYWx0aW1lIGRlcGVuZGluZyAKPiBvbiAiL2Rv
bWFpbi9pbWFnZS9odm0vbG9jYWx0aW1lIiDCsSAiL2RvbWFpbi9pbWFnZS9odm0vcnRjX29mZnNl
dCIuCgpBcmUgdGhvc2UgeGVuc3RvcmUgcGF0aHMgb3IgYSByZWZlcmVuY2UgdG8gYSBjb25maWcg
ZmlsZS9zeHAgdmFyPwoKSSBkb24ndCBzZWUgdGhlIHN0cmluZyAicnRjX29mZnNldCIgYW55d2hl
cmUgdW5kZXIgdG9vbHMgaW4KeGVuLXVuc3RhYmxlLgoKPiAtIGlmIHRoZSBPUyBvZiBhIGRvbVUg
Y2hhbmdlcyBpdHMgUlRDLCB0aGUgcnRjX29mZnNldCBnZXRzIGFkanVzdGVkIGFuZCBpcyAKPiBz
YXZlZCBpbiBYZW5TdG9yZSBhcyAiL3ZtLyRVVUlEL3J0Yy90aW1lb2Zmc2V0Ii4KCkkgdGhpbmsg
c28sIHllcywgcWVtdSBhcHBlYXJzIHRvIGRvIHRoaXMuCgo+IC0gaWYgdGhlIGRvbTAgYWNjZXNz
ZXMgaXRzIFJUQywgaXMgYWNjZXNzZXMgdGhlIHJlYWwgSFctUlRDLgo+IC0gdGhlIFhlbi1IeXBl
cnZpc29yIGluaXRpYWxseSByZWFkIHRoZSBIVy1SVEMgdG8gc2V0dXAgaXRzIFdhbGxjbG9jayBv
bmNlLCAKPiB3aGljaCBpcyB0aGFuIHVzZWQgdG8gc2ltdWxhdGUgdGhlIGRvbVUgUlRDcy4gKFRo
ZSBIVy1SVEMgaXMgb3RoZXJ3aXNlIG9ubHkgCj4gYWNjZXNzZWQgb24gKEFDUEktKVN1c3BlbmQg
YW5kIFJlc3VtZSwgYW5kIHdpdGggTlRQLWRyaWZ0LWNvcnJlY3Rpb24gZnJvbSAKPiBkb20wKS4K
PiAtIG9uIHNodXQtZG93biB0aGUgcnRjX29mZnNldCBpcyBzdG9yZWQgYnkgWGVuZCBpbiAKPiB0
aGUgIi92YXIvbGliL3hlbmQvZG9tYWlucy8kdXVpZC9jb25maWcuc3hwIiBmaWxlIAo+IGluICIv
ZG9tYWluL2ltYWdlL2h2bS9ydGNfdGltZW9mZnNldCIsIGZyb20gd2hlcmUgaXQgaXMgbG9hZGVk
IGFnYWluIG9uIG5leHQgCj4gc3RhcnQuCj4gLSBzaW5jZSBQViBkb21haW5zIGRvbid0IGhhdmUg
YSBSVEMsIHRoZXkgc29tZWhvdyg/KSBnZXQgZWl0aGVyIGluaXRpYWxpemVkIHRvIAo+IHRoZSBs
b2NhbHRpbWUgb3IgVVRDIHRpbWUgZGVwZW5kaW5nIG9uICIvZG9tYWluL2ltYWdlL2xpbnV4L2xv
Y2FsdGltZSIuCgpUaGV5IGdldCBQViB0aW1lIGRpcmVjdCBmcm9tIHRoZSBoeXBlcnZpc29yIHdo
aWNoIGV4cG9zZXMgdGhlCmh5cGVydmlzb3IncyB3YWxsY2xvY2sgdG8gZ3Vlc3RzIHZpYSB0aGUg
c2hhcmVkIGluZm8uIEl0IGlzIGFsd2F5cyBVVEMuClNlZQpodHRwOi8veGVuYml0cy54ZW4ub3Jn
L2RvY3MvdW5zdGFibGUvaHlwZXJjYWxsL2luY2x1ZGUscHVibGljLHhlbi5oLmh0bWwjU3RydWN0
X3NoYXJlZF9pbmZvCmluIHBhcnRpY3VsYXIgdGhlIHdjXyogZmllbGRzLgoKQSBwdm9wcyBkb21V
IHdpbGwgb25seSBzYW1wbGUgdGhpcyBhdCBzdGFydCBvZiBkYXkgYW5kIHRoZW4gd2lsbAptYWlu
dGFpbiBmcmVlLXJ1bm5pbmcgd2FsbGNsb2NrIHRpbWUgaXRzZWxmIGZyb20gdGhlbiBvbiAoaXQg
aXMKcmVjb21tZW5kZWQgdG8gcnVuIG50cCB3aXRoaW4gc3VjaCBkb21VcykuCgpDbGFzc2ljLVhl
biBrZXJuZWxzIGJ5IGRlZmF1bHQgd2lsbCB0YWtlIHdhbGxjbG9jayB0aW1lIGZyb20gdGhlIHNo
YXJlZAppbmZvIGZvciBlYWNoIGdldHRpbWVvZmRheSBidXQgY2FuIGJlIGNvbmZpZ3VyZWQgdG8g
YmUgZnJlZS1ydW5uaW5nCih0aGF0IGlzIHRoZSAiaW5kZXBlbmRlbnRfd2FsbGNsb2NrIiBtb2Rl
KS4KCj4gQHhlbjoKPiBEaWQgSSBmaWd1cmUgb3V0IHRoYXQgY29ycmVjdD8KPiAKPiBAeGVuOgo+
IElzIHRoZXJlIHNvbWUgZG9jdW1lbnRhdGlvbiBvbiB0aGUgWGVuLXN4cCBkb21haW4gY29uZmln
dXJhdGlvbj8gRm9yIHRoZSAKPiBQeXRob24gYmFzZWQgeGVuLXhtIGZvcm1hdCwgSSBmb3VuZCAo
YW5kIHVwZGF0ZWQpIAo+IDxodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuQ29uZmlndXJhdGlv
bkZpbGVPcHRpb25zPiwgYnV0IGZvciBYZW4tc3hwIEkgc28gCj4gZmFyIGZvdW5kIG5vIGRvY3Vt
ZW50YXRpb24sIGVzcGVjaWFsbHkgb24gd2hhdCBjaGFuZ2VkIGJldHdlZW4geGVuLTEsIHhlbi0y
LCAKPiB4ZW4tMy54LCB4ZW4tNC54LgoKWGVuLTEgYW5kIC0yIGhhZCBkaWZmZXJlbnQgYXJjaGl0
ZWN0dXJlcyBhbmQgdG9vbHN0YWNrcyBJSVJDIHNvIHdlIGNhbgpkaXNjb3VudCB0aGVtIEkgdGhp
bmsuCgpJJ20gYWZyYWlkIEkgZG9uJ3Qga25vdyBvZiBhbnkgcmVzb3VyY2UgZm9yIHRoZSAtMy80
IHN4cCBzdHVmZi4KCj4gCj4gQGxpYnZpcnQ6Cj4gQ29tcGFyaW5nIFhlbmQgaGFuZGxpbmcgdG8g
PGh0dHA6Ly9saWJ2aXJ0Lm9yZy9mb3JtYXRkb21haW4uaHRtbCNlbGVtZW50c1RpbWU+IAo+IHRo
ZSBjdXJyZW50IHRyYW5zbGF0aW9uIGRvbmUgYnkgbGlidmlydCBsb29rcyB3cm9uZzsgSSB0aGlu
ayBpcyBtYW5kYXRlcyBiYWNrIAo+IHRvIHRoZSB0aW1lIHdoZW4gWGVuIHN1cHBvcnRlZCBvbmx5
IFBWLWRvbVVzOgo+IGxpYnZpcnQgdHJhbnNsYXRlcyB0aGUgWGVuIGNvbmZpZ3VyYXRpb24gdG8g
ImxvY2FsdGltZSIgYW5kICJ1dGMiIGlnbm9yaW5nIAo+IHRoZSAicnRjX29mZnNldCIsIHdoaWNo
IGV4aXN0cyBmb3IgSFYgZG9tYWlucy4gRm9yIGxvY2FsdGltZT0wIHRoaXMgCj4gdHJhbnNsYXRl
cyB0byBsaWJ2aXJ0cyBvZmZzZXQ9InZhcmlhYmxlIi1jYXNlLCBidXQgZm9yIGxvY2FsdGltZT0x
IHRoZXJlIGlzIAo+IG5vIG1hdGNoaW5nIG1hcHBpbmcgaW4gbGlidmlydC4KPiBTaW5jZSBmb3Ig
UFYgZG9tYWlucyBubyBydGNfdGltZW9mZnNldCBpcyB0cmFja2VkLCB0aGVyZSB0aGUgbWFwcGlu
ZyB0byAidXRjIiAKPiBhbmQgImxvY2FsdGltZSIgbG9va3MgcmlnaHQuCj4gCj4gCj4gRm9yIGxp
YnZpcnQgdGhlcmUgd2FzIGEgcGF0Y2ggCj4gPGh0dHA6Ly93d3cucmVkaGF0LmNvbS9hcmNoaXZl
cy9saWJ2aXItbGlzdC8yMDA5LUphbnVhcnkvbXNnMDA3NTcuaHRtbD4gd2hpY2ggCj4gYWRkZWQg
c29tZSBzcGVjaWFsIGhhbmRsaW5nIGZvciAibG9jYWx0aW1lIiB0byBiZSBlaXRoZXIgcGxhY2Vk
IAo+IGluICIvZG9tYWluL2xvY2FsdGltZSIgb3IgIi9kb21haW4vaW1hZ2Uve2h2bSxsaW51eH0v
bG9jYWx0aW1lIi4gWGVuZCBmcm9tIAo+IDMuNC4zIHVuZCA0LjEuMiBzZWVtcyB0byBhY2NlcHQg
ZWl0aGVyIG9uZSwgYnV0IC9kb21haW4vaW1hZ2UvaHZtL2xvY2FsdGltZSAKPiBpcyBwcmVmZXJy
ZWQgYW5kIG92ZXJ3cml0ZXMgdGhlIGZpcnN0IG9uZS4gV2hlbiByZWFkaW5nIGJhY2sgdGhlIAo+
IGNvbmZpZ3VyYXRpb24gdGhlIHNldHRpbmcgaXMgYWx3YXlzIHJldHVybmVkIAo+IGFzIC9kb21h
aW4vaW1hZ2Uve2h2bSxsaW51eH0vbG9jYWx0aW1lLgo+IAo+IEBKb2huOgo+IElzIHRoZXJlIGEg
Y2FzZSwgd2hlcmUgL2RvbWFpbi9sb2NhbHRpbWUgaXMgcmV0dXJuZWQgb3IgaXMgdGhhdCBrZXkg
Cj4gYWx3YXlzIHRyYW5zbGF0ZWQgdG8gL2RvbWFpbi9saW51eC97aHZtLGxpbnV4fS9sb2NhbHRp
bWU/IEFzIHlvdSBoYWQgYSAKPiBzdW4uY29tIGVtYWlsIGFkZHJlc3MsIHdhcyB0aGlzIHNvbWUg
c3BlY2lhbCBjYXNlIHdoZW4gdXNpbmcgWGVuIHdpdGggCj4gU29sYXJpcz8KPiAKPiBAbGlidmly
dDoKPiBUaGUgYXR0YWNoZWQgcGF0Y2ggKGZvciAwLjguNykgd291bGQgY2hhbmdlIHRoZSBpbXBs
ZW1lbnRhdGlvbiB0byBtYXRjaCB0aGUgCj4gZm9sbG93aW5nOgo+IDEuIEZvciBYZW4tUFYtZG9t
VXMsIHVzZSBjbG9jay9Ab2Zmc2V0PSd1dGMnIGFuZCBjbG9jay9Ab2Zmc2V0PSdsb2NhbHRpbWUn
Lgo+IDIuIEZvciBYZW4tSFYtZG9tVXMsIHVzZSBjbG9jay9Ab2Zmc2V0PSd2YXJpYWJsZScuCj4g
My4gRm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBvbGQgbGlidmlydC1YTUwtZmlsZXMg
Y29udmVydCAKPiBjbG9jay9Ab2Zmc2V0PSd1dGMnIOKGkiAobG9jYWx0aW1lIDApKHJ0Y190aW1l
b2Zmc2V0IDApIGFuZCAKPiBjbG9jay9Ab2Zmc2V0PSdsb2NhbHRpbWUnIOKGkiAobG9jYWx0aW1l
IDEpKHJ0Y190aW1lb3NzZXQgMCkuIE9uIHJlYWRiYWNrIHRoYXQgCj4gd2lsbCBiZSByZXR1cm5l
ZCBhcyBjbG9jay9Ab2Zmc2V0PSd2YXJpYWJsZSchCj4gNC4gRm9yIFhlbi1IVi1kb21VcyB3aXRo
IChsb2NhbHRpbWU9MSkocnRjX3RpbWVvZmZzZXTiiaAwKSBwcmludCBhIHdhcm5pbmcgdGhhdCAK
PiB0aGVyZSBpcyBubyBtYXBwaW5nIHRvIGxpYnZpcnRzIFhNTC4KPiA1LiBBbHdheXMgcHV0IHRo
ZSAobG9jYWx0aW1lKShydGNfb2Zmc2V0KS1TRVhQUnMgaW4gIihpbWFnZSAoe2xpbnV4LGh2bX0p
IiwgCj4gc2luY2UgdGhpcyBpcyB3aGVyZSBYZW5kLTMuNCBhbmQgWGVuZC00LjEgcmV0dXJuIHRo
ZW0uCj4gSSBhbHNvIGNoZWNrZWQgWGVuLTMuMiwgd2hlcmUgdGhpcyBpcyBva2F5LCBidXQgdGhl
IEkgZG9uJ3QgaGF2ZSBhbnkgb2xkZXIgCj4gdmVyc2lvbnMgb2YgWGVuIGF2YWlsYWJsZSAoYW5k
IHJ1bm5pbmcpLCB0aGUgSSBjYW4ndCB2ZXJpZnkgdGhhdCBpdCBzdGlsbCAKPiB3b3JrcyB0aGVy
ZS4KPiAKPiBXaGljaCBsZWFkcyBtZSB0byBhIGFub3RoZXIgcXVlc3Rpb246IFdoaWNoIHZlcnNp
b25zIG9mIFhlbiBhcmUgc3RpbGwgCj4gc3VwcG9ydGVkIGJ5IGxpYnZpcnQgKGFuZCBtdXN0IGJl
IGNoZWNrZWQgZm9yIHJlZ3Jlc3Npb25zKT8gSSBkb24ndCB3YW50IHNvIAo+IGFjdGl2ZWx5IHJl
bW92ZSB0aGUgY29kZSBmb3Igb2xkIFhlbiB2ZXJzaW9ucywgYnV0IGl0IGdldHMgaGFyZGVyIGFu
ZCBoYXJkZXIgCj4gdG8gbWFpbnRhaW4gYWxsIHRob3NlIHZlcnNpb25zLiBTbyBhIHN0YXRlbWVu
dCBsaWtlICJYZW4tMy54IGFuZCBYZW4tNC55IGFyZSAKPiBhY3RpdmVseSBzdXBwb3J0ZWQgYnkg
bGlidmlydC0wLmEuYjsgb2xkZXIgdmVyc2lvbnMgbWlnaHQgc3RpbGwgd29yayAoYnkgCj4gYWNj
aWRlbnQgOy0pIgo+IAo+IEJlZm9yZSBJIGZvcndhcmQtcG9ydCB0aGF0IGNoYW5nZSB0byAwLjku
MTAgSSdkIGxpa2UgdG8gZ2V0IHNvbWUgY29tbWVudHMuIAo+IFRoYW5rcyBpbiBhZHZhbmNlLgo+
IAo+IFNpbmNlcmVseQo+IFBoaWxpcHAgSGFobgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 11 11:54:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 11:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkwku-0000cR-OE; Wed, 11 Jan 2012 11:54: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 1Rkwks-0000cD-TK
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 11:54:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326282844!10546491!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20493 invoked from network); 11 Jan 2012 11:54:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 11:54:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,492,1320624000"; 
   d="scan'208";a="9944565"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:54: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, 11 Jan 2012 11:54:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Philipp Hahn <hahn@univention.de>
Date: Wed, 11 Jan 2012 11:54:04 +0000
In-Reply-To: <201201111121.22236.hahn@univention.de>
References: <201201111121.22236.hahn@univention.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326282844.17210.190.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>,
	John Levon <john.levon@sun.com>
Subject: Re: [Xen-devel] [BUG,
 PATCH-RFC] libvirt localtime and rtc_timeoffset handling
 in	xen-sexpr/sxpr/sxp
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTExIGF0IDEwOjIwICswMDAwLCBQaGlsaXBwIEhhaG4gd3JvdGU6Cj4g
SGVsbG8sCj4gCj4gSSdtIGN1cnJlbnRseSB0cmFja2luZyBhIHByb2JsZW0gaW4gbGlidmlydCBy
ZWdhcmRpbmcgWGVucyBoYW5kbGluZyBvZiAKPiBsb2NhbHRpbWUgYW5kIHJ0Y190aW1lb2Zmc2V0
LiBNeSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgKFhlbi0zLjQuMyBhbmQgCj4gWGVuLTQuMS4yIHVu
ZGVyIExpbnV4KSBvZiBYZW5kICh0aGUgZGVwY3JlY2F0ZWQgUHl0aG9uIG9uZSBzdGlsbCB1c2Vk
IGJ5IAo+IGxpYnZpcnQpIGlzIGFzIHRoaXM6Cj4gLSBmb3IgSFYgZG9tYWlucywgdGhlIFJUQyBn
ZXRzIHNldHVwIHRvIGVpdGhlciBVVEMgb3IgbG9jYWx0aW1lIGRlcGVuZGluZyAKPiBvbiAiL2Rv
bWFpbi9pbWFnZS9odm0vbG9jYWx0aW1lIiDCsSAiL2RvbWFpbi9pbWFnZS9odm0vcnRjX29mZnNl
dCIuCgpBcmUgdGhvc2UgeGVuc3RvcmUgcGF0aHMgb3IgYSByZWZlcmVuY2UgdG8gYSBjb25maWcg
ZmlsZS9zeHAgdmFyPwoKSSBkb24ndCBzZWUgdGhlIHN0cmluZyAicnRjX29mZnNldCIgYW55d2hl
cmUgdW5kZXIgdG9vbHMgaW4KeGVuLXVuc3RhYmxlLgoKPiAtIGlmIHRoZSBPUyBvZiBhIGRvbVUg
Y2hhbmdlcyBpdHMgUlRDLCB0aGUgcnRjX29mZnNldCBnZXRzIGFkanVzdGVkIGFuZCBpcyAKPiBz
YXZlZCBpbiBYZW5TdG9yZSBhcyAiL3ZtLyRVVUlEL3J0Yy90aW1lb2Zmc2V0Ii4KCkkgdGhpbmsg
c28sIHllcywgcWVtdSBhcHBlYXJzIHRvIGRvIHRoaXMuCgo+IC0gaWYgdGhlIGRvbTAgYWNjZXNz
ZXMgaXRzIFJUQywgaXMgYWNjZXNzZXMgdGhlIHJlYWwgSFctUlRDLgo+IC0gdGhlIFhlbi1IeXBl
cnZpc29yIGluaXRpYWxseSByZWFkIHRoZSBIVy1SVEMgdG8gc2V0dXAgaXRzIFdhbGxjbG9jayBv
bmNlLCAKPiB3aGljaCBpcyB0aGFuIHVzZWQgdG8gc2ltdWxhdGUgdGhlIGRvbVUgUlRDcy4gKFRo
ZSBIVy1SVEMgaXMgb3RoZXJ3aXNlIG9ubHkgCj4gYWNjZXNzZWQgb24gKEFDUEktKVN1c3BlbmQg
YW5kIFJlc3VtZSwgYW5kIHdpdGggTlRQLWRyaWZ0LWNvcnJlY3Rpb24gZnJvbSAKPiBkb20wKS4K
PiAtIG9uIHNodXQtZG93biB0aGUgcnRjX29mZnNldCBpcyBzdG9yZWQgYnkgWGVuZCBpbiAKPiB0
aGUgIi92YXIvbGliL3hlbmQvZG9tYWlucy8kdXVpZC9jb25maWcuc3hwIiBmaWxlIAo+IGluICIv
ZG9tYWluL2ltYWdlL2h2bS9ydGNfdGltZW9mZnNldCIsIGZyb20gd2hlcmUgaXQgaXMgbG9hZGVk
IGFnYWluIG9uIG5leHQgCj4gc3RhcnQuCj4gLSBzaW5jZSBQViBkb21haW5zIGRvbid0IGhhdmUg
YSBSVEMsIHRoZXkgc29tZWhvdyg/KSBnZXQgZWl0aGVyIGluaXRpYWxpemVkIHRvIAo+IHRoZSBs
b2NhbHRpbWUgb3IgVVRDIHRpbWUgZGVwZW5kaW5nIG9uICIvZG9tYWluL2ltYWdlL2xpbnV4L2xv
Y2FsdGltZSIuCgpUaGV5IGdldCBQViB0aW1lIGRpcmVjdCBmcm9tIHRoZSBoeXBlcnZpc29yIHdo
aWNoIGV4cG9zZXMgdGhlCmh5cGVydmlzb3IncyB3YWxsY2xvY2sgdG8gZ3Vlc3RzIHZpYSB0aGUg
c2hhcmVkIGluZm8uIEl0IGlzIGFsd2F5cyBVVEMuClNlZQpodHRwOi8veGVuYml0cy54ZW4ub3Jn
L2RvY3MvdW5zdGFibGUvaHlwZXJjYWxsL2luY2x1ZGUscHVibGljLHhlbi5oLmh0bWwjU3RydWN0
X3NoYXJlZF9pbmZvCmluIHBhcnRpY3VsYXIgdGhlIHdjXyogZmllbGRzLgoKQSBwdm9wcyBkb21V
IHdpbGwgb25seSBzYW1wbGUgdGhpcyBhdCBzdGFydCBvZiBkYXkgYW5kIHRoZW4gd2lsbAptYWlu
dGFpbiBmcmVlLXJ1bm5pbmcgd2FsbGNsb2NrIHRpbWUgaXRzZWxmIGZyb20gdGhlbiBvbiAoaXQg
aXMKcmVjb21tZW5kZWQgdG8gcnVuIG50cCB3aXRoaW4gc3VjaCBkb21VcykuCgpDbGFzc2ljLVhl
biBrZXJuZWxzIGJ5IGRlZmF1bHQgd2lsbCB0YWtlIHdhbGxjbG9jayB0aW1lIGZyb20gdGhlIHNo
YXJlZAppbmZvIGZvciBlYWNoIGdldHRpbWVvZmRheSBidXQgY2FuIGJlIGNvbmZpZ3VyZWQgdG8g
YmUgZnJlZS1ydW5uaW5nCih0aGF0IGlzIHRoZSAiaW5kZXBlbmRlbnRfd2FsbGNsb2NrIiBtb2Rl
KS4KCj4gQHhlbjoKPiBEaWQgSSBmaWd1cmUgb3V0IHRoYXQgY29ycmVjdD8KPiAKPiBAeGVuOgo+
IElzIHRoZXJlIHNvbWUgZG9jdW1lbnRhdGlvbiBvbiB0aGUgWGVuLXN4cCBkb21haW4gY29uZmln
dXJhdGlvbj8gRm9yIHRoZSAKPiBQeXRob24gYmFzZWQgeGVuLXhtIGZvcm1hdCwgSSBmb3VuZCAo
YW5kIHVwZGF0ZWQpIAo+IDxodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuQ29uZmlndXJhdGlv
bkZpbGVPcHRpb25zPiwgYnV0IGZvciBYZW4tc3hwIEkgc28gCj4gZmFyIGZvdW5kIG5vIGRvY3Vt
ZW50YXRpb24sIGVzcGVjaWFsbHkgb24gd2hhdCBjaGFuZ2VkIGJldHdlZW4geGVuLTEsIHhlbi0y
LCAKPiB4ZW4tMy54LCB4ZW4tNC54LgoKWGVuLTEgYW5kIC0yIGhhZCBkaWZmZXJlbnQgYXJjaGl0
ZWN0dXJlcyBhbmQgdG9vbHN0YWNrcyBJSVJDIHNvIHdlIGNhbgpkaXNjb3VudCB0aGVtIEkgdGhp
bmsuCgpJJ20gYWZyYWlkIEkgZG9uJ3Qga25vdyBvZiBhbnkgcmVzb3VyY2UgZm9yIHRoZSAtMy80
IHN4cCBzdHVmZi4KCj4gCj4gQGxpYnZpcnQ6Cj4gQ29tcGFyaW5nIFhlbmQgaGFuZGxpbmcgdG8g
PGh0dHA6Ly9saWJ2aXJ0Lm9yZy9mb3JtYXRkb21haW4uaHRtbCNlbGVtZW50c1RpbWU+IAo+IHRo
ZSBjdXJyZW50IHRyYW5zbGF0aW9uIGRvbmUgYnkgbGlidmlydCBsb29rcyB3cm9uZzsgSSB0aGlu
ayBpcyBtYW5kYXRlcyBiYWNrIAo+IHRvIHRoZSB0aW1lIHdoZW4gWGVuIHN1cHBvcnRlZCBvbmx5
IFBWLWRvbVVzOgo+IGxpYnZpcnQgdHJhbnNsYXRlcyB0aGUgWGVuIGNvbmZpZ3VyYXRpb24gdG8g
ImxvY2FsdGltZSIgYW5kICJ1dGMiIGlnbm9yaW5nIAo+IHRoZSAicnRjX29mZnNldCIsIHdoaWNo
IGV4aXN0cyBmb3IgSFYgZG9tYWlucy4gRm9yIGxvY2FsdGltZT0wIHRoaXMgCj4gdHJhbnNsYXRl
cyB0byBsaWJ2aXJ0cyBvZmZzZXQ9InZhcmlhYmxlIi1jYXNlLCBidXQgZm9yIGxvY2FsdGltZT0x
IHRoZXJlIGlzIAo+IG5vIG1hdGNoaW5nIG1hcHBpbmcgaW4gbGlidmlydC4KPiBTaW5jZSBmb3Ig
UFYgZG9tYWlucyBubyBydGNfdGltZW9mZnNldCBpcyB0cmFja2VkLCB0aGVyZSB0aGUgbWFwcGlu
ZyB0byAidXRjIiAKPiBhbmQgImxvY2FsdGltZSIgbG9va3MgcmlnaHQuCj4gCj4gCj4gRm9yIGxp
YnZpcnQgdGhlcmUgd2FzIGEgcGF0Y2ggCj4gPGh0dHA6Ly93d3cucmVkaGF0LmNvbS9hcmNoaXZl
cy9saWJ2aXItbGlzdC8yMDA5LUphbnVhcnkvbXNnMDA3NTcuaHRtbD4gd2hpY2ggCj4gYWRkZWQg
c29tZSBzcGVjaWFsIGhhbmRsaW5nIGZvciAibG9jYWx0aW1lIiB0byBiZSBlaXRoZXIgcGxhY2Vk
IAo+IGluICIvZG9tYWluL2xvY2FsdGltZSIgb3IgIi9kb21haW4vaW1hZ2Uve2h2bSxsaW51eH0v
bG9jYWx0aW1lIi4gWGVuZCBmcm9tIAo+IDMuNC4zIHVuZCA0LjEuMiBzZWVtcyB0byBhY2NlcHQg
ZWl0aGVyIG9uZSwgYnV0IC9kb21haW4vaW1hZ2UvaHZtL2xvY2FsdGltZSAKPiBpcyBwcmVmZXJy
ZWQgYW5kIG92ZXJ3cml0ZXMgdGhlIGZpcnN0IG9uZS4gV2hlbiByZWFkaW5nIGJhY2sgdGhlIAo+
IGNvbmZpZ3VyYXRpb24gdGhlIHNldHRpbmcgaXMgYWx3YXlzIHJldHVybmVkIAo+IGFzIC9kb21h
aW4vaW1hZ2Uve2h2bSxsaW51eH0vbG9jYWx0aW1lLgo+IAo+IEBKb2huOgo+IElzIHRoZXJlIGEg
Y2FzZSwgd2hlcmUgL2RvbWFpbi9sb2NhbHRpbWUgaXMgcmV0dXJuZWQgb3IgaXMgdGhhdCBrZXkg
Cj4gYWx3YXlzIHRyYW5zbGF0ZWQgdG8gL2RvbWFpbi9saW51eC97aHZtLGxpbnV4fS9sb2NhbHRp
bWU/IEFzIHlvdSBoYWQgYSAKPiBzdW4uY29tIGVtYWlsIGFkZHJlc3MsIHdhcyB0aGlzIHNvbWUg
c3BlY2lhbCBjYXNlIHdoZW4gdXNpbmcgWGVuIHdpdGggCj4gU29sYXJpcz8KPiAKPiBAbGlidmly
dDoKPiBUaGUgYXR0YWNoZWQgcGF0Y2ggKGZvciAwLjguNykgd291bGQgY2hhbmdlIHRoZSBpbXBs
ZW1lbnRhdGlvbiB0byBtYXRjaCB0aGUgCj4gZm9sbG93aW5nOgo+IDEuIEZvciBYZW4tUFYtZG9t
VXMsIHVzZSBjbG9jay9Ab2Zmc2V0PSd1dGMnIGFuZCBjbG9jay9Ab2Zmc2V0PSdsb2NhbHRpbWUn
Lgo+IDIuIEZvciBYZW4tSFYtZG9tVXMsIHVzZSBjbG9jay9Ab2Zmc2V0PSd2YXJpYWJsZScuCj4g
My4gRm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBvbGQgbGlidmlydC1YTUwtZmlsZXMg
Y29udmVydCAKPiBjbG9jay9Ab2Zmc2V0PSd1dGMnIOKGkiAobG9jYWx0aW1lIDApKHJ0Y190aW1l
b2Zmc2V0IDApIGFuZCAKPiBjbG9jay9Ab2Zmc2V0PSdsb2NhbHRpbWUnIOKGkiAobG9jYWx0aW1l
IDEpKHJ0Y190aW1lb3NzZXQgMCkuIE9uIHJlYWRiYWNrIHRoYXQgCj4gd2lsbCBiZSByZXR1cm5l
ZCBhcyBjbG9jay9Ab2Zmc2V0PSd2YXJpYWJsZSchCj4gNC4gRm9yIFhlbi1IVi1kb21VcyB3aXRo
IChsb2NhbHRpbWU9MSkocnRjX3RpbWVvZmZzZXTiiaAwKSBwcmludCBhIHdhcm5pbmcgdGhhdCAK
PiB0aGVyZSBpcyBubyBtYXBwaW5nIHRvIGxpYnZpcnRzIFhNTC4KPiA1LiBBbHdheXMgcHV0IHRo
ZSAobG9jYWx0aW1lKShydGNfb2Zmc2V0KS1TRVhQUnMgaW4gIihpbWFnZSAoe2xpbnV4LGh2bX0p
IiwgCj4gc2luY2UgdGhpcyBpcyB3aGVyZSBYZW5kLTMuNCBhbmQgWGVuZC00LjEgcmV0dXJuIHRo
ZW0uCj4gSSBhbHNvIGNoZWNrZWQgWGVuLTMuMiwgd2hlcmUgdGhpcyBpcyBva2F5LCBidXQgdGhl
IEkgZG9uJ3QgaGF2ZSBhbnkgb2xkZXIgCj4gdmVyc2lvbnMgb2YgWGVuIGF2YWlsYWJsZSAoYW5k
IHJ1bm5pbmcpLCB0aGUgSSBjYW4ndCB2ZXJpZnkgdGhhdCBpdCBzdGlsbCAKPiB3b3JrcyB0aGVy
ZS4KPiAKPiBXaGljaCBsZWFkcyBtZSB0byBhIGFub3RoZXIgcXVlc3Rpb246IFdoaWNoIHZlcnNp
b25zIG9mIFhlbiBhcmUgc3RpbGwgCj4gc3VwcG9ydGVkIGJ5IGxpYnZpcnQgKGFuZCBtdXN0IGJl
IGNoZWNrZWQgZm9yIHJlZ3Jlc3Npb25zKT8gSSBkb24ndCB3YW50IHNvIAo+IGFjdGl2ZWx5IHJl
bW92ZSB0aGUgY29kZSBmb3Igb2xkIFhlbiB2ZXJzaW9ucywgYnV0IGl0IGdldHMgaGFyZGVyIGFu
ZCBoYXJkZXIgCj4gdG8gbWFpbnRhaW4gYWxsIHRob3NlIHZlcnNpb25zLiBTbyBhIHN0YXRlbWVu
dCBsaWtlICJYZW4tMy54IGFuZCBYZW4tNC55IGFyZSAKPiBhY3RpdmVseSBzdXBwb3J0ZWQgYnkg
bGlidmlydC0wLmEuYjsgb2xkZXIgdmVyc2lvbnMgbWlnaHQgc3RpbGwgd29yayAoYnkgCj4gYWNj
aWRlbnQgOy0pIgo+IAo+IEJlZm9yZSBJIGZvcndhcmQtcG9ydCB0aGF0IGNoYW5nZSB0byAwLjku
MTAgSSdkIGxpa2UgdG8gZ2V0IHNvbWUgY29tbWVudHMuIAo+IFRoYW5rcyBpbiBhZHZhbmNlLgo+
IAo+IFNpbmNlcmVseQo+IFBoaWxpcHAgSGFobgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:08:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12: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 1RkwyD-0000uO-8k; Wed, 11 Jan 2012 12:07:57 +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 1RkwyB-0000uJ-Ie
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:07:55 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326283668!2722175!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4437 invoked from network); 11 Jan 2012 12:07:49 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 12:07:49 -0000
Received: by ggnh1 with SMTP id h1so5621550ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 04:07:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=U9M6Zg1d4pWQLJNCyOMhcJKkQ+5gSuyUUVGcHp8OZoY=;
	b=pjIObZ8U9VQMhRQZWmybrcNFT7EPLYmDZNzN6c/IN+Zl0E3dnIqK6doi34KmS4Zcjh
	LuooyEkepW5ZFE0Mji4W1T4a70OV7e5KSH/3nqWj76iq/NENIIk9qxqQO6NeOCKsrGwm
	9Aoc/OKF9lQ83YCiNvtBstlTHbuVPjp9+QU+Q=
MIME-Version: 1.0
Received: by 10.50.182.199 with SMTP id eg7mr6550462igc.22.1326283668095; Wed,
	11 Jan 2012 04:07:48 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Wed, 11 Jan 2012 04:07:48 -0800 (PST)
In-Reply-To: <25c0a808.31600.134c867d1ed.Coremail.gbtux@126.com>
References: <25c0a808.31600.134c867d1ed.Coremail.gbtux@126.com>
Date: Wed, 11 Jan 2012 12:07:48 +0000
X-Google-Sender-Auth: FGx0nvoAXsV9bpqrVXBPvdLu1is
Message-ID: <CAFLBxZbstsEoky98Qtqaxkrk70aY2+zXiW5ZiRzN-J2DgQEhoA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: gavin <gbtux@126.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to get the cache miss ratio of Guest 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/10 gavin <gbtux@126.com>:
> I noticed that the credit2 scheduling algorithm has one runqueue every L2
> cache that is shared by cores in one socket. If vCPUs, which need to
> communicate more with each other, are assigned to the cores sharing the same
> L2 cache, the L2 cache miss ratio of Guest VM may be reduced. And also, the
> performance of the Guest VM will be improved. Is it right? But, how to test
> the cache miss ratio of L2 in Guest VM? Are the tools that used to test the
> cache miss ratio in non-virtualized environment can be used in Xen Guest VM?

Looking through the code, it looks like performance counters are
passed-through to HVM guests, both on AMD and Intel.  And it appears
that Fujitsu is regularly using the performance counters on Intel at
least (since Deitmar Hahn has been the one posting patches for new
performance counters).

It appears that there is no support for access to performance counters
in PV mode, other than to use them for xenoprofile (which will not
allow you to read the counters directly).

So it's worth trying whatever method you normally use to look at
performance counters while running in an HVM guest.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:08:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12: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 1RkwyD-0000uO-8k; Wed, 11 Jan 2012 12:07:57 +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 1RkwyB-0000uJ-Ie
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:07:55 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326283668!2722175!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4437 invoked from network); 11 Jan 2012 12:07:49 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 12:07:49 -0000
Received: by ggnh1 with SMTP id h1so5621550ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 04:07:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	bh=U9M6Zg1d4pWQLJNCyOMhcJKkQ+5gSuyUUVGcHp8OZoY=;
	b=pjIObZ8U9VQMhRQZWmybrcNFT7EPLYmDZNzN6c/IN+Zl0E3dnIqK6doi34KmS4Zcjh
	LuooyEkepW5ZFE0Mji4W1T4a70OV7e5KSH/3nqWj76iq/NENIIk9qxqQO6NeOCKsrGwm
	9Aoc/OKF9lQ83YCiNvtBstlTHbuVPjp9+QU+Q=
MIME-Version: 1.0
Received: by 10.50.182.199 with SMTP id eg7mr6550462igc.22.1326283668095; Wed,
	11 Jan 2012 04:07:48 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Wed, 11 Jan 2012 04:07:48 -0800 (PST)
In-Reply-To: <25c0a808.31600.134c867d1ed.Coremail.gbtux@126.com>
References: <25c0a808.31600.134c867d1ed.Coremail.gbtux@126.com>
Date: Wed, 11 Jan 2012 12:07:48 +0000
X-Google-Sender-Auth: FGx0nvoAXsV9bpqrVXBPvdLu1is
Message-ID: <CAFLBxZbstsEoky98Qtqaxkrk70aY2+zXiW5ZiRzN-J2DgQEhoA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: gavin <gbtux@126.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to get the cache miss ratio of Guest 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/10 gavin <gbtux@126.com>:
> I noticed that the credit2 scheduling algorithm has one runqueue every L2
> cache that is shared by cores in one socket. If vCPUs, which need to
> communicate more with each other, are assigned to the cores sharing the same
> L2 cache, the L2 cache miss ratio of Guest VM may be reduced. And also, the
> performance of the Guest VM will be improved. Is it right? But, how to test
> the cache miss ratio of L2 in Guest VM? Are the tools that used to test the
> cache miss ratio in non-virtualized environment can be used in Xen Guest VM?

Looking through the code, it looks like performance counters are
passed-through to HVM guests, both on AMD and Intel.  And it appears
that Fujitsu is regularly using the performance counters on Intel at
least (since Deitmar Hahn has been the one posting patches for new
performance counters).

It appears that there is no support for access to performance counters
in PV mode, other than to use them for xenoprofile (which will not
allow you to read the counters directly).

So it's worth trying whatever method you normally use to look at
performance counters while running in an HVM guest.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:18:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkx7t-00016P-1V; Wed, 11 Jan 2012 12:17: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 1Rkx7r-00015v-H1
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:17:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326284268!7342745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13855 invoked from network); 11 Jan 2012 12:17:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 12:17:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9945060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 12:17: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;
	Wed, 11 Jan 2012 12:17:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 11 Jan 2012 12:17:46 +0000
In-Reply-To: <CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326284268.17210.200.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTExIGF0IDExOjUwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IFRoaXMgY29tZXMgZnJvbSBteSBleHBlcmllbmNlIHdpdGggWGVuIGFu
ZCBob3RwbHVnIHNjcmlwdHMsIGFuZCBpdAo+IG1pZ2h0IGJlIHdyb25nLCBzaW5jZSBJIHdhc24n
dCBhYmxlIHRvIGZpbmQgYW55IGRvY3VtZW50IGV4cGxhaW5pbmcKPiBleGFjdGx5IGhvdyBob3Rw
bHVnIGV4ZWN1dGlvbiB3b3JrcyBhbmQgd2hvIGRvZXMgd2hhdC4gSSdtIGdvbm5hIHRyeQo+IHRv
IGxpc3QgdGhlIHNlcXVlbmNlIG9mIGV2ZW50cyB0aGF0IGhhcHBlbnMgd2hlbiBhIGRldmljZSBp
cyBhZGRlZCAoSQo+IHJlYWxseSBkb24ndCB3YW50IHRvIGtlZXAgb24gd2l0aCB0aGUgZGlzY3Vz
aW9uIGlmIHRoaXMgaXMgYSBwcm90b2NvbAo+IG9yIG5vdCk6Cj4gCj4gMS4gVG9vbHN0YWNrIHdy
aXRlczogL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvPHZiZCBvciB2aWY+Ly4uLiB3aXRoICJzdGF0
ZSA9IDEiLgo+IDIuIEtlcm5lbCBhY2tzIHhlbnN0b3JlIGJhY2tlbmQgZGV2aWNlIGNyZWF0aW9u
LCBjcmVhdGVzIHRoZSBkZXZpY2UKPiBhbmQgc2V0cyBiYWNrZW5kICJzdGF0ZSA9IDIiLgo+IDMu
IHhlbmJhY2tlbmRkIG5vdGljZXMgYmFja2VuZCBkZXZpY2Ugd2l0aCAic3RhdGUgPT0gMiIgYW5k
IGxhdW5jaGVzCj4gaG90cGx1ZyBzY3JpcHQuCgpJbiB0aGUgTGludXggSSB0aGluayBzdGF0ZSA9
PSAyIGNvcnJlc3BvbmRzIHRvIHRoZSBnZW5lcmF0aW9uIG9mIGEKdWV2ZW50IHdoaWNoIHRyaWdn
ZXJzIHVkZXYgdG8gcnVuIHRoZSBob3RwbHVnIHNjcmlwdC4gSSdtIG5vdCAxMDAlIHN1cmUKdGhh
dCBhbGwgZGV2aWNlcyBkbyB0aGlzIGF0IHRoZSBzYW1lIHBvaW50IHRob3VnaC4KCj4gNC4gSG90
cGx1ZyBzY3JpcHQgZXhlY3V0ZXMgbmVjZXNzYXJ5IGFjdGlvbnMgYW5kIHNldHMgYmFja2VuZAo+
ICJob3RwbHVnLXN0YXR1cyA9IGNvbm5lY3RlZCIuCj4gNS4gS2VybmVsIG5vdGljZXMgImhvdHBs
dWctc3RhdHVzID09IGNvbm5lY3RlZCIsIHBsdWdzIHRoZSBkZXZpY2UsIGFuZAo+IHNldHMgeGVu
c3RvcmUgYmFja2VuZCBkZXZpY2UgInN0YXRlID0gNCIuCgpJIHRoaW5rIDQrNSBhcmUgY29ycmVj
dCBmb3IgTGludXggbmV0YmFjayBidXQgZm9yIGJsa2JhY2sgaXQgYWN0dWFsbHkKd2FpdHMgZm9y
IHBoeXMtZGV2IChvciB3aGF0ZXZlciBpdCdzIHJlYWwgbmFtZSBpcykgdG8gYmUgd3JpdHRlbiB3
YXRoZXIKdGhhbiB0aGUgaG90cGx1Zy1zdGF0dXMgbm9kZS4KCj4gVGhpcyBpcyB0cnVlIG9uIE5l
dEJTRCwgYmVjYXVzZSB0aGVyZSBhcmVuJ3QgYW55IHVzZXJzcGFjZSBob3RwbHVnCj4gZGV2aWNl
cywgc29tZW9uZSBzaG91bGQgcHJvYmFibHkgYWRkIHRoZSBtaXNzaW5nIGJpdHMgaWYgdGhlIGRl
dmljZSBpcwo+IGltcGxlbWVudGVkIGluIHVzZXJzcGFjZSAoSSdtIG5vdCByZWFsbHkgc3VyZSBv
ZiB3aGF0IGhhcHBlbnMgaW5zaWRlCj4gdGhlIGtlcm5lbCBpbiAjMiBhbmQgIzUsIHNwZWNpYWxs
eSB3aGVuIHVzaW5nIGJsa3RhcCBvciBxZGlzaykuCgpOb3RoaW5nIGhhcHBlbnMgaW4gdGhlIGtl
cm5lbCBmb3IgcWRpc2suIEl0IGlzIGEgc2VwYXJhdGUgYmFja2VuZCBwYXRoCndoaWNoIHRoZSBr
ZXJuZWwgZG9lc24ndCB3YXRjaCBvciBoYXZlIGEgZHJpdmVyIGZvci4KCmJsa3RhcDEgYmVoYXZl
cyBhIGxvdCBsaWtlIGJsa2JhY2ssIEkgdGhpbmsuCgpibGt0YXAyIGRvZXNuJ3QgdXNlIHhlbmJ1
cyBJSVJDLCByYXRoZXIgaXQgaXMgY3JlYXRlZCB2aWEgdXNlcnNwYWNlCnRvb2xzL2xpYnJhcmll
cy4gVGhlcmUgX21pZ2h0XyBiZSBzb21lIGhvdHBsdWcgc2NyaXB0IGludGVyYWN0aW9uIHdoaWNo
CmNhdXNlcyB0aGUgcGh5cy1kZXYgbm9kZSB0byBnZXQgd3JpdHRlbiB0byB0aGUgYXNzb2NpYXRl
ZCBibGtiYWNrIGRldmljZQpidXQgSSB0aGluayB0aGlzIGlzIG5vdCB0aGUgY2FzZSBhbmQgdGhl
IHRvb2xzdGFjayBqdXN0IHdyaXRlcyB0aGUKcGh5cy1kZXYgYmVjYXVzZSBpdCBrbm93cyB3aGF0
IGl0IGlzIGZyb20gd2hlbiBpdCBjcmVhdGVkIGl0LgoKPiBSZWdhcmRpbmcgZGV2aWNlIHNodXRk
b3duL2Rlc3Ryb3k6CgpXZSBuZWVkIHRvIGNvbnNpZGVyIDMgY2FzZXM6CiAgICAgICogZ3Vlc3Qg
aW5pdGlhdGVkIGdyYWNlZnVsIHNodXRkb3duCiAgICAgICogdG9vbHN0YWNrIGluaXRpYXRlZCBn
cmFjZWZ1bCBzaHV0ZG93bgogICAgICAqIHRvb2xzdGFjayBpbml0aWF0ZWQgZm9yY2VmdWwgZGVz
dHJveS4KCj4gMS4gR3Vlc3Qgc2V0cyBmcm9udGVuZCBzdGF0ZSB0byA2IChjbG9zZWQpCj4gMi4g
S2VybmVsIHVucGx1Z3MgdGhlIGRldmljZSBhbmQgc2V0cyBiYWNrZW5kICJzdGF0ZSA9IDYiLgo+
IDMuIHhlbmJhY2tlbmRkIG5vdGljZXMgZGV2aWNlIHdpdGggInN0YXRlID09IDYiLCBhbmQgcGVy
Zm9ybXMgdGhlCj4gbmVjZXNzYXJ5IGNsZWFudXAuCj4gMy4gVG9vbHN0YWNrIG5vdGljZXMgZGV2
aWNlIHdpdGggInN0YXRlID09IDYiIGFuZCByZW1vdmVzIHhlbnN0b3JlCj4gYmFja2VuZCBlbnRy
aWVzLgoKQXQgbGVhc3Qgc29tZSBiYWNrZW5kL2Zyb250ZW5kcyBtYWtlIHVzZSBvZiBzdGF0ZSA1
IGFzIHBhcnQgb2YgdGhpcywKcHJvYmFibHkgYXQgIzEgb3IgIzIuCgpUaGUgb3JkZXJpbmcgb2Yg
IzEgYW5kICMyIHByb2JhYmx5IGRlcGVuZHMgb24gd2hldGhlciB0aGUgZnJvbnRlbmQgb3IKdGhl
IGJhY2tlbmQgaW5pdGlhdGVzIHRoaW5ncy4KClRoZSBmb3JjZWZ1bCBkZXN0cm95IGNhc2UgaXMg
ZGlmZmVyZW50LCBpdCBpcyBlZmZlY3RpdmVseToKMS4gcm0gYmFja2VuZCBkaXIgaW4geGVuc3Rv
cmUuCgpTb21ld2hlcmUgaW4gYm90aCBvZiB0aGVzZSBhIExpbnV4IGJhY2tlbmQgd2lsbCBnZW5l
cmF0ZSBhIGhvdHBsdWcgZXZlbnQKd2hpY2ggd2lsbCBjYXVzZSBhIHNjcmlwdCB0byBydW4sIGFs
dGhvdWdoIGluIHNvbWUgY2FzZXMgdGhlIHNjcmlwdApjYW4ndCBkbyBtdWNoIGJlY2F1c2UgdGhl
IGJhY2tlbmQgZGlyIGlzIGFscmVhZHkgZ29uZS4uLgoKPiBOb3RpY2UgdGhhdCBJJ3ZlIHVzZWQg
dHdvICMzLCB0aGF0J3Mgd2hlcmUgdGhlIHJhY2UgY29uZGl0aW9uIGhhcHBlbnMsCj4gYmVjYXVz
ZSB0aGVyZSdzIG5vIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRvb2xzdGFjayBhbmQKPiBob3Rw
bHVnL3hlbmJhY2tlbmRkIHRvIGtub3cgd2hlbiBob3RwbHVnIHNjcmlwdHMgaGF2ZSBiZWVuIGV4
ZWN1dGVkCj4gKGhvd2V2ZXIgd2Ugc2hvdWxkIGJlIGFibGUgdG8gc3luY2hyb25pemUgdGhpcyB3
YXRjaGluZwo+ICJob3RwbHVnLXN0YXR1cyIgaW5zdGVhZCBvZiAic3RhdGUiLCBhbmQgd2FpdGlu
ZyBmb3IgaXQgdG8gY2hhbmdlIHRvCj4gImRpc2Nvbm5lY3RlZCIpLgo+IAo+IE5vdywgd2UgaGF2
ZSB0byBkZWNpZGUgaG93IHRvIGZpeCB0aGUgc2h1dGRvd24vZGVzdHJveSByYWNlIGFuZCBob3cg
dG8KPiBpbXBsZW1lbnQgdGhpcyBvdXRzaWRlIG9mIHRoZSBEb20wLiBJJ20gbm90IHJlYWxseSBz
dXJlIGlmIGl0J3MgYSBnb29kCj4gaWRlYSB0byB0cnkgc28gaGFyZCB0byBrZWVwIHRoaXMgZmxv
dyBpbnRhY3QsIEkgdGhpbmsgaXQncyBiZXN0IHRvIHRyeQo+IHRvIGRlZmluZSBhIGZsb3cgdGhh
dCBzb2x2ZXMgb3VyIGN1cnJlbnQgcHJvYmxlbXMsIHJlZ2FyZGxlc3Mgb2YgaG93Cj4gdGhpbmdz
IGFyZSBub3csIGFuZCB0aGVuIHRyeSB0byBtYXAgYm90aCBmbG93cyB0byBzZWUgd2hhdCBzaG91
bGQgYmUKPiBjaGFuZ2VkIGFuZCBob3cuCj4gCj4gU2luY2UgdGhlIGRldmljZSB3aWxsIGJlIHBs
dWdnZWQgZnJvbSBhIERvbWFpbiBkaWZmZXJlbnQgdGhhbiBEb20wLAo+IHRoZSB0b29sc3RhY2sg
ZG9lc24ndCByZWFsbHkgKGFuZCBwcm9iYWJseSBzaG91bGRuJ3QpIGtub3cgYW55dGhpbmcKPiBh
Ym91dCB3aGljaCBiYWNrZW5kIHR5cGUgd2lsbCBiZSB1c2VkIChwaHksIGJsa3RhcCwgcWRpc2su
Li4pLiBIYXZpbmcKPiB0aGF0IGluIG1pbmQsIEkgZG9uJ3Qga25vdyBob3cgY2FuIHdlIHdyaXRl
Cj4gL2xvY2FsL2RvbWFpbi88ZHJpdmVyZG9tX2lkPi9iYWNrZW5kLy4uLiBmcm9tIERvbTAsIGlu
c3RlYWQgd2Ugc2hvdWxkCj4gY3JlYXRlIHNvbWV0aGluZyBsaWtlOgo+IAo+IC9ob3RwbHVnL2Rv
bWFpbi88ZHJpdmVyZG9tX2lkPi88dmJkIG9yIHZpZj4vPGRvbXVfaWQ+LzxkZXZpY2VfaWQ+L3Bh
cmFtcwo+IC9ob3RwbHVnL2RvbWFpbi88ZHJpdmVyZG9tX2lkPi88dmJkIG9yIHZpZj4vPGRvbXVf
aWQ+LzxkZXZpY2VfaWQ+L3NjcmlwdAo+IC9ob3RwbHVnL2RvbWFpbi88ZHJpdmVyZG9tX2lkPi88
dmJkIG9yIHZpZj4vPGRvbXVfaWQ+LzxkZXZpY2VfaWQ+L3N0YXRlCj4gW1RoaXMgc2VlbSBsaWtl
IHRoZSBtaW5pbXVtIG5lY2Vzc2FyeSBwYXJhbWV0ZXJzLCBidXQgcHJvYmFibHkgdGhlcmUKPiBh
cmUgb3RoZXJzLCBzbyBhZGQgd2hhdCB5b3UgZmVlbCBuZWNlc3NhcnldCj4gCj4gV2l0aCB0aGF0
IHRoZSBkcml2ZXIgZG9tYWluIHNob3VsZCBiZSBhYmxlIHRvIGNyZWF0ZQo+IC9sb2NhbC9kb21h
aW4vPGRyaXZlcmRvbWFpbl9pZD4vYmFja2VuZC8uLi4gYW5kIHRoZSBmcm9udGVuZCBhbHNvLgo+
IAo+IEknbSBub3Qgc3VyZSBpZiB3ZSBzaG91bGQgY29udHJvbCB0aGUgZXhlY3V0aW9uIG9mIGhv
dHBsdWcgc2NyaXB0cwo+IGZyb20gRG9tMCwgb3IgaW5zdGVhZCBsZXQgdGhlIGRyaXZlciBkb21h
aW4gZGVjaWRlIHdoZW4gaXQncyBiZXN0IHRvCj4gZXhlY3V0ZSBlYWNoIHNjcmlwdC4gVGhpcyBh
ZGRzIC9ob3RwbHVnIHRvIHhlbnN0b3JlLCBidXQgdGhlCj4gcGx1Zy91bnBsdWcgc2VxdWVuY2Ug
Y291bGQgYmUgdGhlIHNhbWUgYXMgdGhlIG9uZSB3ZSBjdXJyZW50bHkgaGF2ZSwKPiB0aGUgb25s
eSBjaGFuZ2UgaXMgdGhhdCBlYWNoIGRyaXZlciBkb21haW4gaXMgaW4gY2hhcmdlIG9mIHdyaXRp
bmcKPiBpdCdzIG93biB4ZW5zdG9yZSBiYWNrZW5kL2Zyb250ZW5kIGVudHJpZXMgdG8gdHJpZ2dl
ciB0aGUgcGx1Zwo+IHNlcXVlbmNlLgo+IAo+IEhvcGUgdGhhdCBoZWxwcywgUm9nZXIuCj4gCj4g
KHhlbi1kZXZlbCBtYWlsaW5nIGxpc3Qgd2FzIHJlbW92ZWQgYXQgc29tZSBwb2ludCBkdXJpbmcg
dGhlCj4gY29udmVyc2F0aW9uLCBzbyBJJ20gYWRkaW5nIGl0IGFnYWluKQo+IAo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhl
bnNvdXJjZS5jb20veGVuLWRldmVsCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:18:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkx7t-00016P-1V; Wed, 11 Jan 2012 12:17: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 1Rkx7r-00015v-H1
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:17:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326284268!7342745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13855 invoked from network); 11 Jan 2012 12:17:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 12:17:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9945060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 12:17: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;
	Wed, 11 Jan 2012 12:17:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 11 Jan 2012 12:17:46 +0000
In-Reply-To: <CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326284268.17210.200.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTExIGF0IDExOjUwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IEhlbGxvLAo+IAo+IFRoaXMgY29tZXMgZnJvbSBteSBleHBlcmllbmNlIHdpdGggWGVuIGFu
ZCBob3RwbHVnIHNjcmlwdHMsIGFuZCBpdAo+IG1pZ2h0IGJlIHdyb25nLCBzaW5jZSBJIHdhc24n
dCBhYmxlIHRvIGZpbmQgYW55IGRvY3VtZW50IGV4cGxhaW5pbmcKPiBleGFjdGx5IGhvdyBob3Rw
bHVnIGV4ZWN1dGlvbiB3b3JrcyBhbmQgd2hvIGRvZXMgd2hhdC4gSSdtIGdvbm5hIHRyeQo+IHRv
IGxpc3QgdGhlIHNlcXVlbmNlIG9mIGV2ZW50cyB0aGF0IGhhcHBlbnMgd2hlbiBhIGRldmljZSBp
cyBhZGRlZCAoSQo+IHJlYWxseSBkb24ndCB3YW50IHRvIGtlZXAgb24gd2l0aCB0aGUgZGlzY3Vz
aW9uIGlmIHRoaXMgaXMgYSBwcm90b2NvbAo+IG9yIG5vdCk6Cj4gCj4gMS4gVG9vbHN0YWNrIHdy
aXRlczogL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvPHZiZCBvciB2aWY+Ly4uLiB3aXRoICJzdGF0
ZSA9IDEiLgo+IDIuIEtlcm5lbCBhY2tzIHhlbnN0b3JlIGJhY2tlbmQgZGV2aWNlIGNyZWF0aW9u
LCBjcmVhdGVzIHRoZSBkZXZpY2UKPiBhbmQgc2V0cyBiYWNrZW5kICJzdGF0ZSA9IDIiLgo+IDMu
IHhlbmJhY2tlbmRkIG5vdGljZXMgYmFja2VuZCBkZXZpY2Ugd2l0aCAic3RhdGUgPT0gMiIgYW5k
IGxhdW5jaGVzCj4gaG90cGx1ZyBzY3JpcHQuCgpJbiB0aGUgTGludXggSSB0aGluayBzdGF0ZSA9
PSAyIGNvcnJlc3BvbmRzIHRvIHRoZSBnZW5lcmF0aW9uIG9mIGEKdWV2ZW50IHdoaWNoIHRyaWdn
ZXJzIHVkZXYgdG8gcnVuIHRoZSBob3RwbHVnIHNjcmlwdC4gSSdtIG5vdCAxMDAlIHN1cmUKdGhh
dCBhbGwgZGV2aWNlcyBkbyB0aGlzIGF0IHRoZSBzYW1lIHBvaW50IHRob3VnaC4KCj4gNC4gSG90
cGx1ZyBzY3JpcHQgZXhlY3V0ZXMgbmVjZXNzYXJ5IGFjdGlvbnMgYW5kIHNldHMgYmFja2VuZAo+
ICJob3RwbHVnLXN0YXR1cyA9IGNvbm5lY3RlZCIuCj4gNS4gS2VybmVsIG5vdGljZXMgImhvdHBs
dWctc3RhdHVzID09IGNvbm5lY3RlZCIsIHBsdWdzIHRoZSBkZXZpY2UsIGFuZAo+IHNldHMgeGVu
c3RvcmUgYmFja2VuZCBkZXZpY2UgInN0YXRlID0gNCIuCgpJIHRoaW5rIDQrNSBhcmUgY29ycmVj
dCBmb3IgTGludXggbmV0YmFjayBidXQgZm9yIGJsa2JhY2sgaXQgYWN0dWFsbHkKd2FpdHMgZm9y
IHBoeXMtZGV2IChvciB3aGF0ZXZlciBpdCdzIHJlYWwgbmFtZSBpcykgdG8gYmUgd3JpdHRlbiB3
YXRoZXIKdGhhbiB0aGUgaG90cGx1Zy1zdGF0dXMgbm9kZS4KCj4gVGhpcyBpcyB0cnVlIG9uIE5l
dEJTRCwgYmVjYXVzZSB0aGVyZSBhcmVuJ3QgYW55IHVzZXJzcGFjZSBob3RwbHVnCj4gZGV2aWNl
cywgc29tZW9uZSBzaG91bGQgcHJvYmFibHkgYWRkIHRoZSBtaXNzaW5nIGJpdHMgaWYgdGhlIGRl
dmljZSBpcwo+IGltcGxlbWVudGVkIGluIHVzZXJzcGFjZSAoSSdtIG5vdCByZWFsbHkgc3VyZSBv
ZiB3aGF0IGhhcHBlbnMgaW5zaWRlCj4gdGhlIGtlcm5lbCBpbiAjMiBhbmQgIzUsIHNwZWNpYWxs
eSB3aGVuIHVzaW5nIGJsa3RhcCBvciBxZGlzaykuCgpOb3RoaW5nIGhhcHBlbnMgaW4gdGhlIGtl
cm5lbCBmb3IgcWRpc2suIEl0IGlzIGEgc2VwYXJhdGUgYmFja2VuZCBwYXRoCndoaWNoIHRoZSBr
ZXJuZWwgZG9lc24ndCB3YXRjaCBvciBoYXZlIGEgZHJpdmVyIGZvci4KCmJsa3RhcDEgYmVoYXZl
cyBhIGxvdCBsaWtlIGJsa2JhY2ssIEkgdGhpbmsuCgpibGt0YXAyIGRvZXNuJ3QgdXNlIHhlbmJ1
cyBJSVJDLCByYXRoZXIgaXQgaXMgY3JlYXRlZCB2aWEgdXNlcnNwYWNlCnRvb2xzL2xpYnJhcmll
cy4gVGhlcmUgX21pZ2h0XyBiZSBzb21lIGhvdHBsdWcgc2NyaXB0IGludGVyYWN0aW9uIHdoaWNo
CmNhdXNlcyB0aGUgcGh5cy1kZXYgbm9kZSB0byBnZXQgd3JpdHRlbiB0byB0aGUgYXNzb2NpYXRl
ZCBibGtiYWNrIGRldmljZQpidXQgSSB0aGluayB0aGlzIGlzIG5vdCB0aGUgY2FzZSBhbmQgdGhl
IHRvb2xzdGFjayBqdXN0IHdyaXRlcyB0aGUKcGh5cy1kZXYgYmVjYXVzZSBpdCBrbm93cyB3aGF0
IGl0IGlzIGZyb20gd2hlbiBpdCBjcmVhdGVkIGl0LgoKPiBSZWdhcmRpbmcgZGV2aWNlIHNodXRk
b3duL2Rlc3Ryb3k6CgpXZSBuZWVkIHRvIGNvbnNpZGVyIDMgY2FzZXM6CiAgICAgICogZ3Vlc3Qg
aW5pdGlhdGVkIGdyYWNlZnVsIHNodXRkb3duCiAgICAgICogdG9vbHN0YWNrIGluaXRpYXRlZCBn
cmFjZWZ1bCBzaHV0ZG93bgogICAgICAqIHRvb2xzdGFjayBpbml0aWF0ZWQgZm9yY2VmdWwgZGVz
dHJveS4KCj4gMS4gR3Vlc3Qgc2V0cyBmcm9udGVuZCBzdGF0ZSB0byA2IChjbG9zZWQpCj4gMi4g
S2VybmVsIHVucGx1Z3MgdGhlIGRldmljZSBhbmQgc2V0cyBiYWNrZW5kICJzdGF0ZSA9IDYiLgo+
IDMuIHhlbmJhY2tlbmRkIG5vdGljZXMgZGV2aWNlIHdpdGggInN0YXRlID09IDYiLCBhbmQgcGVy
Zm9ybXMgdGhlCj4gbmVjZXNzYXJ5IGNsZWFudXAuCj4gMy4gVG9vbHN0YWNrIG5vdGljZXMgZGV2
aWNlIHdpdGggInN0YXRlID09IDYiIGFuZCByZW1vdmVzIHhlbnN0b3JlCj4gYmFja2VuZCBlbnRy
aWVzLgoKQXQgbGVhc3Qgc29tZSBiYWNrZW5kL2Zyb250ZW5kcyBtYWtlIHVzZSBvZiBzdGF0ZSA1
IGFzIHBhcnQgb2YgdGhpcywKcHJvYmFibHkgYXQgIzEgb3IgIzIuCgpUaGUgb3JkZXJpbmcgb2Yg
IzEgYW5kICMyIHByb2JhYmx5IGRlcGVuZHMgb24gd2hldGhlciB0aGUgZnJvbnRlbmQgb3IKdGhl
IGJhY2tlbmQgaW5pdGlhdGVzIHRoaW5ncy4KClRoZSBmb3JjZWZ1bCBkZXN0cm95IGNhc2UgaXMg
ZGlmZmVyZW50LCBpdCBpcyBlZmZlY3RpdmVseToKMS4gcm0gYmFja2VuZCBkaXIgaW4geGVuc3Rv
cmUuCgpTb21ld2hlcmUgaW4gYm90aCBvZiB0aGVzZSBhIExpbnV4IGJhY2tlbmQgd2lsbCBnZW5l
cmF0ZSBhIGhvdHBsdWcgZXZlbnQKd2hpY2ggd2lsbCBjYXVzZSBhIHNjcmlwdCB0byBydW4sIGFs
dGhvdWdoIGluIHNvbWUgY2FzZXMgdGhlIHNjcmlwdApjYW4ndCBkbyBtdWNoIGJlY2F1c2UgdGhl
IGJhY2tlbmQgZGlyIGlzIGFscmVhZHkgZ29uZS4uLgoKPiBOb3RpY2UgdGhhdCBJJ3ZlIHVzZWQg
dHdvICMzLCB0aGF0J3Mgd2hlcmUgdGhlIHJhY2UgY29uZGl0aW9uIGhhcHBlbnMsCj4gYmVjYXVz
ZSB0aGVyZSdzIG5vIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRvb2xzdGFjayBhbmQKPiBob3Rw
bHVnL3hlbmJhY2tlbmRkIHRvIGtub3cgd2hlbiBob3RwbHVnIHNjcmlwdHMgaGF2ZSBiZWVuIGV4
ZWN1dGVkCj4gKGhvd2V2ZXIgd2Ugc2hvdWxkIGJlIGFibGUgdG8gc3luY2hyb25pemUgdGhpcyB3
YXRjaGluZwo+ICJob3RwbHVnLXN0YXR1cyIgaW5zdGVhZCBvZiAic3RhdGUiLCBhbmQgd2FpdGlu
ZyBmb3IgaXQgdG8gY2hhbmdlIHRvCj4gImRpc2Nvbm5lY3RlZCIpLgo+IAo+IE5vdywgd2UgaGF2
ZSB0byBkZWNpZGUgaG93IHRvIGZpeCB0aGUgc2h1dGRvd24vZGVzdHJveSByYWNlIGFuZCBob3cg
dG8KPiBpbXBsZW1lbnQgdGhpcyBvdXRzaWRlIG9mIHRoZSBEb20wLiBJJ20gbm90IHJlYWxseSBz
dXJlIGlmIGl0J3MgYSBnb29kCj4gaWRlYSB0byB0cnkgc28gaGFyZCB0byBrZWVwIHRoaXMgZmxv
dyBpbnRhY3QsIEkgdGhpbmsgaXQncyBiZXN0IHRvIHRyeQo+IHRvIGRlZmluZSBhIGZsb3cgdGhh
dCBzb2x2ZXMgb3VyIGN1cnJlbnQgcHJvYmxlbXMsIHJlZ2FyZGxlc3Mgb2YgaG93Cj4gdGhpbmdz
IGFyZSBub3csIGFuZCB0aGVuIHRyeSB0byBtYXAgYm90aCBmbG93cyB0byBzZWUgd2hhdCBzaG91
bGQgYmUKPiBjaGFuZ2VkIGFuZCBob3cuCj4gCj4gU2luY2UgdGhlIGRldmljZSB3aWxsIGJlIHBs
dWdnZWQgZnJvbSBhIERvbWFpbiBkaWZmZXJlbnQgdGhhbiBEb20wLAo+IHRoZSB0b29sc3RhY2sg
ZG9lc24ndCByZWFsbHkgKGFuZCBwcm9iYWJseSBzaG91bGRuJ3QpIGtub3cgYW55dGhpbmcKPiBh
Ym91dCB3aGljaCBiYWNrZW5kIHR5cGUgd2lsbCBiZSB1c2VkIChwaHksIGJsa3RhcCwgcWRpc2su
Li4pLiBIYXZpbmcKPiB0aGF0IGluIG1pbmQsIEkgZG9uJ3Qga25vdyBob3cgY2FuIHdlIHdyaXRl
Cj4gL2xvY2FsL2RvbWFpbi88ZHJpdmVyZG9tX2lkPi9iYWNrZW5kLy4uLiBmcm9tIERvbTAsIGlu
c3RlYWQgd2Ugc2hvdWxkCj4gY3JlYXRlIHNvbWV0aGluZyBsaWtlOgo+IAo+IC9ob3RwbHVnL2Rv
bWFpbi88ZHJpdmVyZG9tX2lkPi88dmJkIG9yIHZpZj4vPGRvbXVfaWQ+LzxkZXZpY2VfaWQ+L3Bh
cmFtcwo+IC9ob3RwbHVnL2RvbWFpbi88ZHJpdmVyZG9tX2lkPi88dmJkIG9yIHZpZj4vPGRvbXVf
aWQ+LzxkZXZpY2VfaWQ+L3NjcmlwdAo+IC9ob3RwbHVnL2RvbWFpbi88ZHJpdmVyZG9tX2lkPi88
dmJkIG9yIHZpZj4vPGRvbXVfaWQ+LzxkZXZpY2VfaWQ+L3N0YXRlCj4gW1RoaXMgc2VlbSBsaWtl
IHRoZSBtaW5pbXVtIG5lY2Vzc2FyeSBwYXJhbWV0ZXJzLCBidXQgcHJvYmFibHkgdGhlcmUKPiBh
cmUgb3RoZXJzLCBzbyBhZGQgd2hhdCB5b3UgZmVlbCBuZWNlc3NhcnldCj4gCj4gV2l0aCB0aGF0
IHRoZSBkcml2ZXIgZG9tYWluIHNob3VsZCBiZSBhYmxlIHRvIGNyZWF0ZQo+IC9sb2NhbC9kb21h
aW4vPGRyaXZlcmRvbWFpbl9pZD4vYmFja2VuZC8uLi4gYW5kIHRoZSBmcm9udGVuZCBhbHNvLgo+
IAo+IEknbSBub3Qgc3VyZSBpZiB3ZSBzaG91bGQgY29udHJvbCB0aGUgZXhlY3V0aW9uIG9mIGhv
dHBsdWcgc2NyaXB0cwo+IGZyb20gRG9tMCwgb3IgaW5zdGVhZCBsZXQgdGhlIGRyaXZlciBkb21h
aW4gZGVjaWRlIHdoZW4gaXQncyBiZXN0IHRvCj4gZXhlY3V0ZSBlYWNoIHNjcmlwdC4gVGhpcyBh
ZGRzIC9ob3RwbHVnIHRvIHhlbnN0b3JlLCBidXQgdGhlCj4gcGx1Zy91bnBsdWcgc2VxdWVuY2Ug
Y291bGQgYmUgdGhlIHNhbWUgYXMgdGhlIG9uZSB3ZSBjdXJyZW50bHkgaGF2ZSwKPiB0aGUgb25s
eSBjaGFuZ2UgaXMgdGhhdCBlYWNoIGRyaXZlciBkb21haW4gaXMgaW4gY2hhcmdlIG9mIHdyaXRp
bmcKPiBpdCdzIG93biB4ZW5zdG9yZSBiYWNrZW5kL2Zyb250ZW5kIGVudHJpZXMgdG8gdHJpZ2dl
ciB0aGUgcGx1Zwo+IHNlcXVlbmNlLgo+IAo+IEhvcGUgdGhhdCBoZWxwcywgUm9nZXIuCj4gCj4g
KHhlbi1kZXZlbCBtYWlsaW5nIGxpc3Qgd2FzIHJlbW92ZWQgYXQgc29tZSBwb2ludCBkdXJpbmcg
dGhlCj4gY29udmVyc2F0aW9uLCBzbyBJJ20gYWRkaW5nIGl0IGFnYWluKQo+IAo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhl
bnNvdXJjZS5jb20veGVuLWRldmVsCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12: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 1RkxGM-0001V8-1w; Wed, 11 Jan 2012 12:26:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RkxGK-0001V1-DJ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:26:40 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326284759!55496486!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2794 invoked from network); 11 Jan 2012 12:25:59 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-4.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 12:25:59 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id BB732164B103;
	Wed, 11 Jan 2012 13:24:44 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id A4CD5164B105;
	Wed, 11 Jan 2012 13:24:44 +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 ZtFJqlO77J8K; Wed, 11 Jan 2012 13:24:44 +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 0360C164B103;
	Wed, 11 Jan 2012 13:24:43 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 11 Jan 2012 13:26:31 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <201201111121.22236.hahn@univention.de>
	<1326282844.17210.190.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326282844.17210.190.camel@zakaz.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201201111326.36514.hahn@univention.de>
Cc: "libvir-list@redhat.com" <libvir-list@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	John Levon <john.levon@sun.com>
Subject: Re: [Xen-devel]
 =?utf-8?q?=5BBUG=2C_=09PATCH-RFC=5D_libvirt_localtime?=
 =?utf-8?q?_and_rtc=5Ftimeoffset_handling_in=09xen-sexpr/sxpr/sxp?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8544545575936504529=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8544545575936504529==
Content-Type: multipart/signed;
  boundary="nextPart3555235.afP0mmBqrI";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3555235.afP0mmBqrI
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ian,

Am Mittwoch 11 Januar 2012 12:54:04 schrieb Ian Campbell:
> On Wed, 2012-01-11 at 10:20 +0000, Philipp Hahn wrote:
> > I'm currently tracking a problem in libvirt regarding Xens handling of
> > localtime and rtc_timeoffset. My current understanding (Xen-3.4.3 and
> > Xen-4.1.2 under Linux) of Xend (the depcrecated Python one still used by
> > libvirt) is as this:
> > - for HV domains, the RTC gets setup to either UTC or localtime dependi=
ng
> > on "/domain/image/hvm/localtime" =C2=B1 "/domain/image/hvm/rtc_offset".
>
> Are those xenstore paths or a reference to a config file/sxp var?

Those are XenStore paths.

> I don't see the string "rtc_offset" anywhere under tools in
> xen-unstable.

I missed the "time", it's "rtc_timeoffset". Best search for RegExp=20
rtc.timeoffset, since so you'll find 'rtc/timeoffset' as well.

=2E..
> They get PV time direct from the hypervisor which exposes the
> hypervisor's wallclock to guests via the shared info. It is always UTC.
> See
> http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#=
St
>ruct_shared_info in particular the wc_* fields.

Yes, I figured that out as well, but thanks for the link.

> Classic-Xen kernels by default will take wallclock time from the shared
> info for each gettimeofday but can be configured to be free-running
> (that is the "independent_wallclock" mode).

A lot of documentation still talks about /proc/xen/independent_wallclock,=20
which doesn't exist in 2.6.32 any more. I wish they would mention the Xen=20
version and Linux kerbel version they were using ...

Thank you for your fast feedback.

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/

--nextPart3555235.afP0mmBqrI
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)

iEYEABECAAYFAk8Nf/cACgkQYPlgoZpUDjki0ACglLO2FDAi5GvciI+dKGnaJ/vM
cJ8AnRZzYTTZtoNGRW9Xy0BKY+WvwT5Y
=MpVs
-----END PGP SIGNATURE-----

--nextPart3555235.afP0mmBqrI--


--===============8544545575936504529==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8544545575936504529==--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12: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 1RkxGM-0001V8-1w; Wed, 11 Jan 2012 12:26:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hahn@univention.de>) id 1RkxGK-0001V1-DJ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:26:40 +0000
X-Env-Sender: hahn@univention.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326284759!55496486!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2794 invoked from network); 11 Jan 2012 12:25:59 -0000
Received: from mail.univention.de (HELO mail.univention.de) (82.198.197.8)
	by server-4.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 12:25:59 -0000
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id BB732164B103;
	Wed, 11 Jan 2012 13:24:44 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by slugis.knut.univention.de (Postfix) with ESMTP id A4CD5164B105;
	Wed, 11 Jan 2012 13:24:44 +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 ZtFJqlO77J8K; Wed, 11 Jan 2012 13:24:44 +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 0360C164B103;
	Wed, 11 Jan 2012 13:24:43 +0100 (CET)
From: Philipp Hahn <hahn@univention.de>
Organization: Univention.de
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 11 Jan 2012 13:26:31 +0100
User-Agent: KMail/1.9.10 (enterprise35 20100903.1171286)
References: <201201111121.22236.hahn@univention.de>
	<1326282844.17210.190.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326282844.17210.190.camel@zakaz.uk.xensource.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Message-Id: <201201111326.36514.hahn@univention.de>
Cc: "libvir-list@redhat.com" <libvir-list@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	John Levon <john.levon@sun.com>
Subject: Re: [Xen-devel]
 =?utf-8?q?=5BBUG=2C_=09PATCH-RFC=5D_libvirt_localtime?=
 =?utf-8?q?_and_rtc=5Ftimeoffset_handling_in=09xen-sexpr/sxpr/sxp?=
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8544545575936504529=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8544545575936504529==
Content-Type: multipart/signed;
  boundary="nextPart3555235.afP0mmBqrI";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart3555235.afP0mmBqrI
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello Ian,

Am Mittwoch 11 Januar 2012 12:54:04 schrieb Ian Campbell:
> On Wed, 2012-01-11 at 10:20 +0000, Philipp Hahn wrote:
> > I'm currently tracking a problem in libvirt regarding Xens handling of
> > localtime and rtc_timeoffset. My current understanding (Xen-3.4.3 and
> > Xen-4.1.2 under Linux) of Xend (the depcrecated Python one still used by
> > libvirt) is as this:
> > - for HV domains, the RTC gets setup to either UTC or localtime dependi=
ng
> > on "/domain/image/hvm/localtime" =C2=B1 "/domain/image/hvm/rtc_offset".
>
> Are those xenstore paths or a reference to a config file/sxp var?

Those are XenStore paths.

> I don't see the string "rtc_offset" anywhere under tools in
> xen-unstable.

I missed the "time", it's "rtc_timeoffset". Best search for RegExp=20
rtc.timeoffset, since so you'll find 'rtc/timeoffset' as well.

=2E..
> They get PV time direct from the hypervisor which exposes the
> hypervisor's wallclock to guests via the shared info. It is always UTC.
> See
> http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#=
St
>ruct_shared_info in particular the wc_* fields.

Yes, I figured that out as well, but thanks for the link.

> Classic-Xen kernels by default will take wallclock time from the shared
> info for each gettimeofday but can be configured to be free-running
> (that is the "independent_wallclock" mode).

A lot of documentation still talks about /proc/xen/independent_wallclock,=20
which doesn't exist in 2.6.32 any more. I wish they would mention the Xen=20
version and Linux kerbel version they were using ...

Thank you for your fast feedback.

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/

--nextPart3555235.afP0mmBqrI
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)

iEYEABECAAYFAk8Nf/cACgkQYPlgoZpUDjki0ACglLO2FDAi5GvciI+dKGnaJ/vM
cJ8AnRZzYTTZtoNGRW9Xy0BKY+WvwT5Y
=MpVs
-----END PGP SIGNATURE-----

--nextPart3555235.afP0mmBqrI--


--===============8544545575936504529==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8544545575936504529==--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:42:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkxVH-0001lK-Lc; Wed, 11 Jan 2012 12:42:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RkxVG-0001lF-0I
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:42:06 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326285609!10396903!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2NzcwNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 532 invoked from network); 11 Jan 2012 12:40:13 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 12:40:13 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=eOAsTKb1fMfVJRKAIxaGacxADfTjLS/TrQA2Ag1RVPYv134f8On935RN
	d6JRg3N+KLA7Aa0ToORnXtzv5S3vhZg3CKxhgr7zkrVRxSVGjSENq88Ml
	gyEkQOGgfc4B0z9+qZ6D0IhKSlgQ2uJT3lUVXr8b1xAwjDiYtIvGuYqLQ
	v2ln7QJj4qS25T9i8vo7EzeZBp8Jo/IZ2SVfZWSilTrWUkDixJEoPyoDd
	9TOFVn9zRsk1jY7IEPM4toKZM/WTo;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326285613; x=1357821613;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=gl2wlFWVuW3xEUt+YM/6zNarOTFvFKFI9ew94s14ImQ=;
	b=XjjKWLk2UK/Qy5GMzRFmayYUk7cAL+CSPCTKlenSdfB82RturGskAYZ9
	irhrg1DcnvL2715gAL4IaCrBILIZBBERbO+AMMc7Bl1OzStlrLSSbrn+a
	kBp2ovHSsO68iGVn+6/ir3hbvDDgFn8aW1EUs2ccSEry9bJwm96AfMoMb
	JSOYWdfaWcY7lssNst5x3564iC+bi7IVa1fae6YchucKuKrrJZHoXXhYz
	rZAcqYCV3wuczOiDceblhT4j5lRKZ;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,493,1320620400"; d="scan'208";a="83148455"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 11 Jan 2012 13:40:09 +0100
X-IronPort-AV: E=Sophos;i="4.71,492,1320620400"; d="scan'208";a="126869292"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 11 Jan 2012 13:40:08 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id B12DE95E674;
	Wed, 11 Jan 2012 13:40:08 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 13:40:08 +0100
Message-ID: <49133461.ZjjkJcqGmj@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CAFLBxZbstsEoky98Qtqaxkrk70aY2+zXiW5ZiRzN-J2DgQEhoA@mail.gmail.com>
References: <25c0a808.31600.134c867d1ed.Coremail.gbtux@126.com>
	<CAFLBxZbstsEoky98Qtqaxkrk70aY2+zXiW5ZiRzN-J2DgQEhoA@mail.gmail.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, gavin <gbtux@126.com>
Subject: Re: [Xen-devel] How to get the cache miss ratio of Guest 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: 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 Mittwoch 11 Januar 2012, 12:07:48 schrieb George Dunlap:
> 2012/1/10 gavin <gbtux@126.com>:
> > I noticed that the credit2 scheduling algorithm has one runqueue every L2
> > cache that is shared by cores in one socket. If vCPUs, which need to
> > communicate more with each other, are assigned to the cores sharing the same
> > L2 cache, the L2 cache miss ratio of Guest VM may be reduced. And also, the
> > performance of the Guest VM will be improved. Is it right? But, how to test
> > the cache miss ratio of L2 in Guest VM? Are the tools that used to test the
> > cache miss ratio in non-virtualized environment can be used in Xen Guest VM?
> 
> Looking through the code, it looks like performance counters are
> passed-through to HVM guests, both on AMD and Intel.  And it appears
> that Fujitsu is regularly using the performance counters on Intel at
> least (since Deitmar Hahn has been the one posting patches for new
> performance counters).
> 
> It appears that there is no support for access to performance counters
> in PV mode, other than to use them for xenoprofile (which will not
> allow you to read the counters directly).
> 
> So it's worth trying whatever method you normally use to look at
> performance counters while running in an HVM guest.

Yes, only HVM guests. On Intel (for what I sent patches) only some processors
are supported.
You have to add the hypervisor boot variable 'vpmu' in your grub/menu.lst or
whatever.
If your processor is not supported you will see a message in the hypervisor
boot logging (it's printed from the sorce xen/arch/x86/hvm/vpmu.c function
vpmu_initialise()). 

Dietmar.

>  -George

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:42:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkxVH-0001lK-Lc; Wed, 11 Jan 2012 12:42:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RkxVG-0001lF-0I
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:42:06 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326285609!10396903!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2NzcwNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 532 invoked from network); 11 Jan 2012 12:40:13 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 12:40:13 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=eOAsTKb1fMfVJRKAIxaGacxADfTjLS/TrQA2Ag1RVPYv134f8On935RN
	d6JRg3N+KLA7Aa0ToORnXtzv5S3vhZg3CKxhgr7zkrVRxSVGjSENq88Ml
	gyEkQOGgfc4B0z9+qZ6D0IhKSlgQ2uJT3lUVXr8b1xAwjDiYtIvGuYqLQ
	v2ln7QJj4qS25T9i8vo7EzeZBp8Jo/IZ2SVfZWSilTrWUkDixJEoPyoDd
	9TOFVn9zRsk1jY7IEPM4toKZM/WTo;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326285613; x=1357821613;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=gl2wlFWVuW3xEUt+YM/6zNarOTFvFKFI9ew94s14ImQ=;
	b=XjjKWLk2UK/Qy5GMzRFmayYUk7cAL+CSPCTKlenSdfB82RturGskAYZ9
	irhrg1DcnvL2715gAL4IaCrBILIZBBERbO+AMMc7Bl1OzStlrLSSbrn+a
	kBp2ovHSsO68iGVn+6/ir3hbvDDgFn8aW1EUs2ccSEry9bJwm96AfMoMb
	JSOYWdfaWcY7lssNst5x3564iC+bi7IVa1fae6YchucKuKrrJZHoXXhYz
	rZAcqYCV3wuczOiDceblhT4j5lRKZ;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,493,1320620400"; d="scan'208";a="83148455"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 11 Jan 2012 13:40:09 +0100
X-IronPort-AV: E=Sophos;i="4.71,492,1320620400"; d="scan'208";a="126869292"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 11 Jan 2012 13:40:08 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id B12DE95E674;
	Wed, 11 Jan 2012 13:40:08 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 13:40:08 +0100
Message-ID: <49133461.ZjjkJcqGmj@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CAFLBxZbstsEoky98Qtqaxkrk70aY2+zXiW5ZiRzN-J2DgQEhoA@mail.gmail.com>
References: <25c0a808.31600.134c867d1ed.Coremail.gbtux@126.com>
	<CAFLBxZbstsEoky98Qtqaxkrk70aY2+zXiW5ZiRzN-J2DgQEhoA@mail.gmail.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, gavin <gbtux@126.com>
Subject: Re: [Xen-devel] How to get the cache miss ratio of Guest 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: 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 Mittwoch 11 Januar 2012, 12:07:48 schrieb George Dunlap:
> 2012/1/10 gavin <gbtux@126.com>:
> > I noticed that the credit2 scheduling algorithm has one runqueue every L2
> > cache that is shared by cores in one socket. If vCPUs, which need to
> > communicate more with each other, are assigned to the cores sharing the same
> > L2 cache, the L2 cache miss ratio of Guest VM may be reduced. And also, the
> > performance of the Guest VM will be improved. Is it right? But, how to test
> > the cache miss ratio of L2 in Guest VM? Are the tools that used to test the
> > cache miss ratio in non-virtualized environment can be used in Xen Guest VM?
> 
> Looking through the code, it looks like performance counters are
> passed-through to HVM guests, both on AMD and Intel.  And it appears
> that Fujitsu is regularly using the performance counters on Intel at
> least (since Deitmar Hahn has been the one posting patches for new
> performance counters).
> 
> It appears that there is no support for access to performance counters
> in PV mode, other than to use them for xenoprofile (which will not
> allow you to read the counters directly).
> 
> So it's worth trying whatever method you normally use to look at
> performance counters while running in an HVM guest.

Yes, only HVM guests. On Intel (for what I sent patches) only some processors
are supported.
You have to add the hypervisor boot variable 'vpmu' in your grub/menu.lst or
whatever.
If your processor is not supported you will see a message in the hypervisor
boot logging (it's printed from the sorce xen/arch/x86/hvm/vpmu.c function
vpmu_initialise()). 

Dietmar.

>  -George

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:51:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12:51:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkxdk-0001vE-KU; Wed, 11 Jan 2012 12:50:52 +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 1Rkxdi-0001v4-6B
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:50:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326286243!6834726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10691 invoked from network); 11 Jan 2012 12:50:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 12:50:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9945778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 12:50: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, 11 Jan 2012 12:50:42 +0000
Date: Wed, 11 Jan 2012 12:50:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201111245150.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-764571601-1326286268=:3150"
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] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-764571601-1326286268=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Wed, 11 Jan 2012, Roger Pau Monné wrote:
> Hello,
> 
> This comes from my experience with Xen and hotplug scripts, and it
> might be wrong, since I wasn't able to find any document explaining
> exactly how hotplug execution works and who does what. I'm gonna try
> to list the sequence of events that happens when a device is added (I
> really don't want to keep on with the discusion if this is a protocol
> or not):
> 
> 1. Toolstack writes: /local/domain/0/backend/<vbd or vif>/... with "state = 1".
> 2. Kernel acks xenstore backend device creation, creates the device
> and sets backend "state = 2".
> 3. xenbackendd notices backend device with "state == 2" and launches
> hotplug script.
> 4. Hotplug script executes necessary actions and sets backend
> "hotplug-status = connected".
> 5. Kernel notices "hotplug-status == connected", plugs the device, and
> sets xenstore backend device "state = 4".
> 
> This is true on NetBSD, because there aren't any userspace hotplug
> devices, someone should probably add the missing bits if the device is
> implemented in userspace (I'm not really sure of what happens inside
> the kernel in #2 and #5, specially when using blktap or qdisk).
> 
> Regarding device shutdown/destroy:
> 
> 1. Guest sets frontend state to 6 (closed)
> 2. Kernel unplugs the device and sets backend "state = 6".
> 3. xenbackendd notices device with "state == 6", and performs the
> necessary cleanup.
> 3. Toolstack notices device with "state == 6" and removes xenstore
> backend entries.
> 
> Notice that I've used two #3, that's where the race condition happens,
> because there's no synchronization between toolstack and
> hotplug/xenbackendd to know when hotplug scripts have been executed
> (however we should be able to synchronize this watching
> "hotplug-status" instead of "state", and waiting for it to change to
> "disconnected").
> 
> Now, we have to decide how to fix the shutdown/destroy race and how to
> implement this outside of the Dom0. I'm not really sure if it's a good
> idea to try so hard to keep this flow intact, I think it's best to try
> to define a flow that solves our current problems, regardless of how
> things are now, and then try to map both flows to see what should be
> changed and how.
> 
> Since the device will be plugged from a Domain different than Dom0,
> the toolstack doesn't really (and probably shouldn't) know anything
> about which backend type will be used (phy, blktap, qdisk...). Having
> that in mind, I don't know how can we write
> /local/domain/<driverdom_id>/backend/... from Dom0, instead we should
> create something like:
> 
> /hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/params
> /hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/script
> /hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/state
> [This seem like the minimum necessary parameters, but probably there
> are others, so add what you feel necessary]
> 
> With that the driver domain should be able to create
> /local/domain/<driverdomain_id>/backend/... and the frontend also.
 
What you are proposing is good enough to solve the problem I was
describing before: xenbackendd in the driver domain would have the
liberty of running any setup script it needs to run, before writing the
backend nodes to xenstore.
Also, considering that xenbackendd would be in charge of both running
the script and writing/removing the backend nodes it would have full
control over the sequence of events, that gives us a lot of flexibility
to deal with complex scenarios.
For these reasons, I support this idea.


> I'm not sure if we should control the execution of hotplug scripts
> from Dom0, or instead let the driver domain decide when it's best to
> execute each script. 

At this point it is best to keep the driver domain in charge of its own
scripts.
--8323329-764571601-1326286268=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-764571601-1326286268=:3150--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 12:51:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 12:51:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkxdk-0001vE-KU; Wed, 11 Jan 2012 12:50:52 +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 1Rkxdi-0001v4-6B
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 12:50:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326286243!6834726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10691 invoked from network); 11 Jan 2012 12:50:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 12:50:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9945778"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 12:50: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, 11 Jan 2012 12:50:42 +0000
Date: Wed, 11 Jan 2012 12:50:53 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201111245150.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-764571601-1326286268=:3150"
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] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-764571601-1326286268=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Wed, 11 Jan 2012, Roger Pau Monné wrote:
> Hello,
> 
> This comes from my experience with Xen and hotplug scripts, and it
> might be wrong, since I wasn't able to find any document explaining
> exactly how hotplug execution works and who does what. I'm gonna try
> to list the sequence of events that happens when a device is added (I
> really don't want to keep on with the discusion if this is a protocol
> or not):
> 
> 1. Toolstack writes: /local/domain/0/backend/<vbd or vif>/... with "state = 1".
> 2. Kernel acks xenstore backend device creation, creates the device
> and sets backend "state = 2".
> 3. xenbackendd notices backend device with "state == 2" and launches
> hotplug script.
> 4. Hotplug script executes necessary actions and sets backend
> "hotplug-status = connected".
> 5. Kernel notices "hotplug-status == connected", plugs the device, and
> sets xenstore backend device "state = 4".
> 
> This is true on NetBSD, because there aren't any userspace hotplug
> devices, someone should probably add the missing bits if the device is
> implemented in userspace (I'm not really sure of what happens inside
> the kernel in #2 and #5, specially when using blktap or qdisk).
> 
> Regarding device shutdown/destroy:
> 
> 1. Guest sets frontend state to 6 (closed)
> 2. Kernel unplugs the device and sets backend "state = 6".
> 3. xenbackendd notices device with "state == 6", and performs the
> necessary cleanup.
> 3. Toolstack notices device with "state == 6" and removes xenstore
> backend entries.
> 
> Notice that I've used two #3, that's where the race condition happens,
> because there's no synchronization between toolstack and
> hotplug/xenbackendd to know when hotplug scripts have been executed
> (however we should be able to synchronize this watching
> "hotplug-status" instead of "state", and waiting for it to change to
> "disconnected").
> 
> Now, we have to decide how to fix the shutdown/destroy race and how to
> implement this outside of the Dom0. I'm not really sure if it's a good
> idea to try so hard to keep this flow intact, I think it's best to try
> to define a flow that solves our current problems, regardless of how
> things are now, and then try to map both flows to see what should be
> changed and how.
> 
> Since the device will be plugged from a Domain different than Dom0,
> the toolstack doesn't really (and probably shouldn't) know anything
> about which backend type will be used (phy, blktap, qdisk...). Having
> that in mind, I don't know how can we write
> /local/domain/<driverdom_id>/backend/... from Dom0, instead we should
> create something like:
> 
> /hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/params
> /hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/script
> /hotplug/domain/<driverdom_id>/<vbd or vif>/<domu_id>/<device_id>/state
> [This seem like the minimum necessary parameters, but probably there
> are others, so add what you feel necessary]
> 
> With that the driver domain should be able to create
> /local/domain/<driverdomain_id>/backend/... and the frontend also.
 
What you are proposing is good enough to solve the problem I was
describing before: xenbackendd in the driver domain would have the
liberty of running any setup script it needs to run, before writing the
backend nodes to xenstore.
Also, considering that xenbackendd would be in charge of both running
the script and writing/removing the backend nodes it would have full
control over the sequence of events, that gives us a lot of flexibility
to deal with complex scenarios.
For these reasons, I support this idea.


> I'm not sure if we should control the execution of hotplug scripts
> from Dom0, or instead let the driver domain decide when it's best to
> execute each script. 

At this point it is best to keep the driver domain in charge of its own
scripts.
--8323329-764571601-1326286268=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-764571601-1326286268=:3150--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:07:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkxta-0002Am-BY; Wed, 11 Jan 2012 13:07:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1RkxtY-0002Ae-OK
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:07:12 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326287224!10010494!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8809 invoked from network); 11 Jan 2012 13:07:06 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 13:07:06 -0000
Received: by obbwd20 with SMTP id wd20so2736300obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 05:07:04 -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=xjxhJj33YWudEzS6ETbqsGgGNP3ec3Wv8mgVjLTN998=;
	b=PJHvR0dpnQ12uCDNfK85xaNC/fBath+ET7HfhDdqt0qqZu/T0RcgNnYBtAVY5sB6Er
	fXNbTM5sctjpPl6hbx/VhpjJNy0nWqmI6OMJLm6c0Ya6I0QE++3gdCIhIBxNq/+IAx5w
	5vWwtriOYYFAWQYWE9VAdgYzoGJg9C1CaVQ9Y=
Received: by 10.182.117.97 with SMTP id kd1mr22171038obb.50.1326287224215;
	Wed, 11 Jan 2012 05:07:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.22.163 with HTTP; Wed, 11 Jan 2012 05:06:43 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 11 Jan 2012 13:06:43 +0000
X-Google-Sender-Auth: Yt1rOKEVNMbrbVO8ikKpweaqvkA
Message-ID: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen randomly stuck in mdelay() during MP 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

Hi,

When trying to boot xen 4.1 on new hardware, Xen become stuck in
wakeup_secondary_cpu() in the mdelay function.

    Dprintk("Waiting for send to finish...\n");
    timeout = 0;
    do {
        Dprintk("+");
        udelay(100);
        if ( !x2apic_enabled )
            send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
    } while ( send_status && (timeout++ < 1000) );

    printk("before mdelay\n");
    mdelay(10);
    printk("after mdelay\n");

    Dprintk("Deasserting INIT.\n");

The hang can happen randomly with any of the CPUs to wake up and
sometime doesn't happen at all.
Replacing mdelay(10) with udelay(10) seems to fix the issue.

-- 
Julian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:07:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13:07:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkxta-0002Am-BY; Wed, 11 Jan 2012 13:07:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1RkxtY-0002Ae-OK
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:07:12 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326287224!10010494!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8809 invoked from network); 11 Jan 2012 13:07:06 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 13:07:06 -0000
Received: by obbwd20 with SMTP id wd20so2736300obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 05:07:04 -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=xjxhJj33YWudEzS6ETbqsGgGNP3ec3Wv8mgVjLTN998=;
	b=PJHvR0dpnQ12uCDNfK85xaNC/fBath+ET7HfhDdqt0qqZu/T0RcgNnYBtAVY5sB6Er
	fXNbTM5sctjpPl6hbx/VhpjJNy0nWqmI6OMJLm6c0Ya6I0QE++3gdCIhIBxNq/+IAx5w
	5vWwtriOYYFAWQYWE9VAdgYzoGJg9C1CaVQ9Y=
Received: by 10.182.117.97 with SMTP id kd1mr22171038obb.50.1326287224215;
	Wed, 11 Jan 2012 05:07:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.22.163 with HTTP; Wed, 11 Jan 2012 05:06:43 -0800 (PST)
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 11 Jan 2012 13:06:43 +0000
X-Google-Sender-Auth: Yt1rOKEVNMbrbVO8ikKpweaqvkA
Message-ID: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Xen randomly stuck in mdelay() during MP 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

Hi,

When trying to boot xen 4.1 on new hardware, Xen become stuck in
wakeup_secondary_cpu() in the mdelay function.

    Dprintk("Waiting for send to finish...\n");
    timeout = 0;
    do {
        Dprintk("+");
        udelay(100);
        if ( !x2apic_enabled )
            send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
    } while ( send_status && (timeout++ < 1000) );

    printk("before mdelay\n");
    mdelay(10);
    printk("after mdelay\n");

    Dprintk("Deasserting INIT.\n");

The hang can happen randomly with any of the CPUs to wake up and
sometime doesn't happen at all.
Replacing mdelay(10) with udelay(10) seems to fix the issue.

-- 
Julian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:28:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkyDK-0002MK-78; Wed, 11 Jan 2012 13:27:38 +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 1RkyDI-0002MF-LL
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:27:36 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326288414!59780532!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDUxMjc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16719 invoked from network); 11 Jan 2012 13:26:55 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 13:26:55 -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 63ABE17ED;
	Wed, 11 Jan 2012 15:27:34 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 45D6320058; Wed, 11 Jan 2012 15:27:34 +0200 (EET)
Date: Wed, 11 Jan 2012 15:27:34 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Julian Pidancet <julian.pidancet@gmail.com>
Message-ID: <20120111132733.GM12984@reaktio.net>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during
	MP	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 Wed, Jan 11, 2012 at 01:06:43PM +0000, Julian Pidancet wrote:
> Hi,
> 

Hello,

> When trying to boot xen 4.1 on new hardware, Xen become stuck in
> wakeup_secondary_cpu() in the mdelay function.
> 

Can you define "new hardware" ?


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:28:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13:28:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkyDK-0002MK-78; Wed, 11 Jan 2012 13:27:38 +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 1RkyDI-0002MF-LL
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:27:36 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326288414!59780532!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDUxMjc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16719 invoked from network); 11 Jan 2012 13:26:55 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 13:26:55 -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 63ABE17ED;
	Wed, 11 Jan 2012 15:27:34 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 45D6320058; Wed, 11 Jan 2012 15:27:34 +0200 (EET)
Date: Wed, 11 Jan 2012 15:27:34 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Julian Pidancet <julian.pidancet@gmail.com>
Message-ID: <20120111132733.GM12984@reaktio.net>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during
	MP	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 Wed, Jan 11, 2012 at 01:06:43PM +0000, Julian Pidancet wrote:
> Hi,
> 

Hello,

> When trying to boot xen 4.1 on new hardware, Xen become stuck in
> wakeup_secondary_cpu() in the mdelay function.
> 

Can you define "new hardware" ?


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:29:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13: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 1RkyEa-0002PA-MK; Wed, 11 Jan 2012 13:28:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RkyEY-0002Ox-Ad
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:28:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326288415!59253847!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 10275 invoked from network); 11 Jan 2012 13:26:55 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 13:26:55 -0000
Received: by wgbed3 with SMTP id ed3so4136822wgb.0
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 05:28: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=inKQ8zrQarzFVHgWp1LaQBVbE3eWBaj6Rycw+FlhqoQ=;
	b=ZvJ/+IVjD4yuO8XCkm+RuR4U8ZJ35TwwjaBKblnWToC8iWWKR9zlrUV/GmtNZYSLl2
	8+kkd55iuZxNqAdF10WpvdIxByWJzYiOrQ+5MM/RHOXSlRHSSupDxxdVBvbegqNxvMdb
	rfljb9mLn08HIfJJhQdg9v5U4Il/1LOgFVIOI=
Received: by 10.180.19.6 with SMTP id a6mr19663365wie.14.1326288529989;
	Wed, 11 Jan 2012 05:28:49 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id o17sm1668578wbh.19.2012.01.11.05.28.48
	(version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 05:28:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Jan 2012 13:28:40 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Julian Pidancet <julian.pidancet@gmail.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB333F08.28854%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen randomly stuck in mdelay() during MP
	initialization
Thread-Index: AczQZO5J3TIEAKDHbU2OUNEw8VVzcw==
In-Reply-To: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
 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 11/01/2012 13:06, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:

> Hi,
> 
> When trying to boot xen 4.1 on new hardware, Xen become stuck in
> wakeup_secondary_cpu() in the mdelay function.
> 
>     Dprintk("Waiting for send to finish...\n");
>     timeout = 0;
>     do {
>         Dprintk("+");
>         udelay(100);
>         if ( !x2apic_enabled )
>             send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>     } while ( send_status && (timeout++ < 1000) );
> 
>     printk("before mdelay\n");
>     mdelay(10);
>     printk("after mdelay\n");
> 
>     Dprintk("Deasserting INIT.\n");
> 
> The hang can happen randomly with any of the CPUs to wake up and
> sometime doesn't happen at all.
> Replacing mdelay(10) with udelay(10) seems to fix the issue.

Do you see this in xen-unstable? Hopefully it is working there, and we can
simply backport the fix.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:29:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13: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 1RkyEa-0002PA-MK; Wed, 11 Jan 2012 13:28:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RkyEY-0002Ox-Ad
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:28:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326288415!59253847!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 10275 invoked from network); 11 Jan 2012 13:26:55 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 13:26:55 -0000
Received: by wgbed3 with SMTP id ed3so4136822wgb.0
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 05:28: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:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=inKQ8zrQarzFVHgWp1LaQBVbE3eWBaj6Rycw+FlhqoQ=;
	b=ZvJ/+IVjD4yuO8XCkm+RuR4U8ZJ35TwwjaBKblnWToC8iWWKR9zlrUV/GmtNZYSLl2
	8+kkd55iuZxNqAdF10WpvdIxByWJzYiOrQ+5MM/RHOXSlRHSSupDxxdVBvbegqNxvMdb
	rfljb9mLn08HIfJJhQdg9v5U4Il/1LOgFVIOI=
Received: by 10.180.19.6 with SMTP id a6mr19663365wie.14.1326288529989;
	Wed, 11 Jan 2012 05:28:49 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id o17sm1668578wbh.19.2012.01.11.05.28.48
	(version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 05:28:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Jan 2012 13:28:40 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Julian Pidancet <julian.pidancet@gmail.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB333F08.28854%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen randomly stuck in mdelay() during MP
	initialization
Thread-Index: AczQZO5J3TIEAKDHbU2OUNEw8VVzcw==
In-Reply-To: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
 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 11/01/2012 13:06, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:

> Hi,
> 
> When trying to boot xen 4.1 on new hardware, Xen become stuck in
> wakeup_secondary_cpu() in the mdelay function.
> 
>     Dprintk("Waiting for send to finish...\n");
>     timeout = 0;
>     do {
>         Dprintk("+");
>         udelay(100);
>         if ( !x2apic_enabled )
>             send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>     } while ( send_status && (timeout++ < 1000) );
> 
>     printk("before mdelay\n");
>     mdelay(10);
>     printk("after mdelay\n");
> 
>     Dprintk("Deasserting INIT.\n");
> 
> The hang can happen randomly with any of the CPUs to wake up and
> sometime doesn't happen at all.
> Replacing mdelay(10) with udelay(10) seems to fix the issue.

Do you see this in xen-unstable? Hopefully it is working there, and we can
simply backport the fix.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:56:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkyen-0002iF-4u; Wed, 11 Jan 2012 13:56:01 +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 1Rkyem-0002iA-2g
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:56:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326290152!10481894!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5548 invoked from network); 11 Jan 2012 13:55:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 11 Jan 2012 13:55:52 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326290151; l=10589;
	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=XbZfTjQnftH8M70b/uarHLwIqXU=;
	b=Njs9zVXI0AtL+AE1Qbu3PnNkqB8ClMlAbAxXEkvBxTDDojNHtYtTTqtN2T4wfGFy/Sl
	BhvB6XnC/gn5rhP4VxuaRVZKExmYLCRKzWCXcZ0ICJqm4s3xriAXIfprXElPyNPW/2IpA
	Ce0/EpRZR2Vas8jF2QoaTYsfsuhJs1l7+M0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzAQEURr
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-113-021.pools.arcor-ip.net [88.65.113.21])
	by post.strato.de (mrclete mo48) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R027efo0BCYi1L
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 14:55:47 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 689EE18634
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 14:55:46 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 83cc7a3fbf4feb1f2a4492b1dcca4778ad81226a
Message-Id: <83cc7a3fbf4feb1f2a44.1326290144@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Jan 2012 14:55:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: use flat index for pagefile and
	page-in requests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326290042 -3600
# Node ID 83cc7a3fbf4feb1f2a4492b1dcca4778ad81226a
# Parent  9cdcedc133e5227c635dbb00bd4779015311107a
xenpaging: use flat index for pagefile and page-in requests

This change is based on an idea by <hongkaixing@huawei.com> and
<bicky.shi@huawei.com>.

Scanning the victims[] array is time consuming with a large number of
target pages. Replace the loop to find the slot in the pagefile which
holds the requested gfn with an index.

Remove the victims array and replace it with a flat array. This array
holds the gfn for a given slot in the pagefile. Adjust all users of the
victims array.

Rename variable in main() from i to slot to clearify the meaning.

Update xenpaging_evict_page() to pass a pointer to xen_pfn_t to
xc_map_foreign_pages().

Update policy_choose_victim() to return either a gfn or INVALID_MFN.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9cdcedc133e5 -r 83cc7a3fbf4f tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -29,7 +29,7 @@
 
 
 int policy_init(struct xenpaging *paging);
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim);
+unsigned long policy_choose_victim(struct xenpaging *paging);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r 9cdcedc133e5 -r 83cc7a3fbf4f tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -77,7 +77,7 @@ int policy_init(struct xenpaging *paging
     return rc;
 }
 
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim)
+unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
@@ -102,16 +102,13 @@ int policy_choose_victim(struct xenpagin
                 /* One more round before returning ENOSPC */
                 continue;
             }
-            victim->gfn = INVALID_MFN;
-            return -ENOSPC;
+            return INVALID_MFN;
         }
     }
     while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
 
     set_bit(current_gfn, unconsumed);
-    victim->gfn = current_gfn;
-
-    return 0;
+    return current_gfn;
 }
 
 void policy_notify_paged_out(unsigned long gfn)
diff -r 9cdcedc133e5 -r 83cc7a3fbf4f tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -430,6 +430,11 @@ static struct xenpaging *xenpaging_init(
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
+    paging->slot_to_gfn = calloc(paging->max_pages, sizeof(*paging->slot_to_gfn));
+    paging->gfn_to_slot = calloc(paging->max_pages, sizeof(*paging->gfn_to_slot));
+    if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -468,6 +473,8 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->slot_to_gfn);
+        free(paging->gfn_to_slot);
         free(paging->bitmap);
         free(paging);
     }
@@ -561,31 +568,29 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
-    unsigned long gfn;
+    xen_pfn_t victim = gfn;
     int ret;
 
     DECLARE_DOMCTL;
 
     /* Map page */
-    gfn = victim->gfn;
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
-                                PROT_READ | PROT_WRITE, &gfn, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ | PROT_WRITE, &victim, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page %lx", victim->gfn);
+        PERROR("Error mapping page %lx", gfn);
         goto out;
     }
 
     /* Copy page */
-    ret = write_page(fd, page, i);
+    ret = write_page(fd, page, slot);
     if ( ret != 0 )
     {
-        PERROR("Error copying page %lx", victim->gfn);
+        PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
         goto out;
     }
@@ -593,17 +598,20 @@ static int xenpaging_evict_page(struct x
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
-                              victim->gfn);
+    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
     if ( ret != 0 )
     {
-        PERROR("Error evicting page %lx", victim->gfn);
+        PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
-    DPRINTF("evict_page > gfn %lx pageslot %d\n", victim->gfn, i);
+    DPRINTF("evict_page > gfn %lx pageslot %d\n", gfn, slot);
     /* Notify policy of page being paged out */
-    policy_notify_paged_out(victim->gfn);
+    policy_notify_paged_out(gfn);
+
+    /* Update index */
+    paging->slot_to_gfn[slot] = gfn;
+    paging->gfn_to_slot[gfn] = slot;
 
     /* Record number of evicted pages */
     paging->num_paged_out++;
@@ -710,19 +718,19 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
-static int evict_victim(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
+    unsigned long gfn;
     int j = 0;
     int ret;
 
     do
     {
-        ret = policy_choose_victim(paging, victim);
-        if ( ret != 0 )
+        gfn = policy_choose_victim(paging);
+        if ( gfn == INVALID_MFN )
         {
-            if ( ret != -ENOSPC )
-                ERROR("Error choosing victim");
+            ret = -ENOSPC;
             goto out;
         }
 
@@ -731,9 +739,9 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, victim->gfn);
+        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, victim, fd, i);
+            ret = xenpaging_evict_page(paging, gfn, fd, slot);
         else
         {
             if ( j++ % 1000 == 0 )
@@ -743,7 +751,7 @@ static int evict_victim(struct xenpaging
     }
     while ( ret );
 
-    if ( test_and_set_bit(victim->gfn, paging->bitmap) )
+    if ( test_and_set_bit(gfn, paging->bitmap) )
         ERROR("Page has been evicted before");
 
     ret = 0;
@@ -753,7 +761,7 @@ static int evict_victim(struct xenpaging
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(struct xenpaging *paging, int fd, struct victim *victims, int num_pages)
+static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -761,10 +769,10 @@ static int evict_pages(struct xenpaging 
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
-        if ( victims[slot].gfn != INVALID_MFN )
+        if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, &victims[slot], fd, slot);
+        rc = evict_victim(paging, fd, slot);
         if ( rc == -ENOSPC )
             break;
         if ( rc == -EINTR )
@@ -780,11 +788,10 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     struct xenpaging *paging;
-    struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int num, prev_num = 0;
-    int i;
+    int slot;
     int tot_pages;
     int rc = -1;
     int rc1;
@@ -813,15 +820,6 @@ int main(int argc, char *argv[])
         return 2;
     }
 
-    /* Allocate upper limit of pages to allow growing and shrinking */
-    victims = calloc(paging->max_pages, sizeof(struct victim));
-    if ( !victims )
-        goto out;
-
-    /* Mark all slots as unallocated */
-    for ( i = 0; i < paging->max_pages; i++ )
-        victims[i].gfn = INVALID_MFN;
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -853,32 +851,35 @@ int main(int argc, char *argv[])
         {
             get_request(&paging->mem_event, &req);
 
+            if ( req.gfn > paging->max_pages )
+            {
+                ERROR("Requested gfn %"PRIx64" higher than max_pages %lx\n", req.gfn, paging->max_pages);
+                goto out;
+            }
+
             /* Check if the page has already been paged in */
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->max_pages; i++ )
+                slot = paging->gfn_to_slot[req.gfn];
+
+                /* Sanity check */
+                if ( paging->slot_to_gfn[slot] != req.gfn )
                 {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->max_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
+                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.gfn, slot, paging->slot_to_gfn[slot]);
                     goto out;
                 }
-                
+
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
-                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, i);
+                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, slot);
                     /* Notify policy of page being dropped */
                     policy_notify_dropped(req.gfn);
                 }
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, i);
+                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
                     if ( rc != 0 )
                     {
                         PERROR("Error populating page %"PRIx64"", req.gfn);
@@ -899,7 +900,7 @@ int main(int argc, char *argv[])
                 }
 
                 /* Clear this pagefile slot */
-                victims[i].gfn = INVALID_MFN;
+                paging->slot_to_gfn[slot] = 0;
             }
             else
             {
@@ -969,7 +970,7 @@ int main(int argc, char *argv[])
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
                 num = 42;
-            evict_pages(paging, fd, victims, num);
+            evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -989,7 +990,6 @@ int main(int argc, char *argv[])
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 9cdcedc133e5 -r 83cc7a3fbf4f tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -46,6 +46,9 @@ struct xenpaging {
 
     unsigned long *bitmap;
 
+    unsigned long *slot_to_gfn;
+    int *gfn_to_slot;
+
     struct mem_event mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
@@ -56,13 +59,6 @@ struct xenpaging {
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 
-
-struct victim {
-    /* the gfn of the page to evict */
-    unsigned long gfn;
-};
-
-
 extern void create_page_in_thread(struct xenpaging *paging);
 extern void page_in_trigger(void);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:56:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkyen-0002iF-4u; Wed, 11 Jan 2012 13:56:01 +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 1Rkyem-0002iA-2g
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:56:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326290152!10481894!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5548 invoked from network); 11 Jan 2012 13:55:52 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 11 Jan 2012 13:55:52 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326290151; l=10589;
	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=XbZfTjQnftH8M70b/uarHLwIqXU=;
	b=Njs9zVXI0AtL+AE1Qbu3PnNkqB8ClMlAbAxXEkvBxTDDojNHtYtTTqtN2T4wfGFy/Sl
	BhvB6XnC/gn5rhP4VxuaRVZKExmYLCRKzWCXcZ0ICJqm4s3xriAXIfprXElPyNPW/2IpA
	Ce0/EpRZR2Vas8jF2QoaTYsfsuhJs1l7+M0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzAQEURr
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-113-021.pools.arcor-ip.net [88.65.113.21])
	by post.strato.de (mrclete mo48) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R027efo0BCYi1L
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 14:55:47 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 689EE18634
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 14:55:46 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 83cc7a3fbf4feb1f2a4492b1dcca4778ad81226a
Message-Id: <83cc7a3fbf4feb1f2a44.1326290144@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Jan 2012 14:55:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: use flat index for pagefile and
	page-in requests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326290042 -3600
# Node ID 83cc7a3fbf4feb1f2a4492b1dcca4778ad81226a
# Parent  9cdcedc133e5227c635dbb00bd4779015311107a
xenpaging: use flat index for pagefile and page-in requests

This change is based on an idea by <hongkaixing@huawei.com> and
<bicky.shi@huawei.com>.

Scanning the victims[] array is time consuming with a large number of
target pages. Replace the loop to find the slot in the pagefile which
holds the requested gfn with an index.

Remove the victims array and replace it with a flat array. This array
holds the gfn for a given slot in the pagefile. Adjust all users of the
victims array.

Rename variable in main() from i to slot to clearify the meaning.

Update xenpaging_evict_page() to pass a pointer to xen_pfn_t to
xc_map_foreign_pages().

Update policy_choose_victim() to return either a gfn or INVALID_MFN.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 9cdcedc133e5 -r 83cc7a3fbf4f tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -29,7 +29,7 @@
 
 
 int policy_init(struct xenpaging *paging);
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim);
+unsigned long policy_choose_victim(struct xenpaging *paging);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r 9cdcedc133e5 -r 83cc7a3fbf4f tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -77,7 +77,7 @@ int policy_init(struct xenpaging *paging
     return rc;
 }
 
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim)
+unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
@@ -102,16 +102,13 @@ int policy_choose_victim(struct xenpagin
                 /* One more round before returning ENOSPC */
                 continue;
             }
-            victim->gfn = INVALID_MFN;
-            return -ENOSPC;
+            return INVALID_MFN;
         }
     }
     while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
 
     set_bit(current_gfn, unconsumed);
-    victim->gfn = current_gfn;
-
-    return 0;
+    return current_gfn;
 }
 
 void policy_notify_paged_out(unsigned long gfn)
diff -r 9cdcedc133e5 -r 83cc7a3fbf4f tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -430,6 +430,11 @@ static struct xenpaging *xenpaging_init(
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
+    paging->slot_to_gfn = calloc(paging->max_pages, sizeof(*paging->slot_to_gfn));
+    paging->gfn_to_slot = calloc(paging->max_pages, sizeof(*paging->gfn_to_slot));
+    if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -468,6 +473,8 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->slot_to_gfn);
+        free(paging->gfn_to_slot);
         free(paging->bitmap);
         free(paging);
     }
@@ -561,31 +568,29 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
-    unsigned long gfn;
+    xen_pfn_t victim = gfn;
     int ret;
 
     DECLARE_DOMCTL;
 
     /* Map page */
-    gfn = victim->gfn;
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
-                                PROT_READ | PROT_WRITE, &gfn, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ | PROT_WRITE, &victim, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page %lx", victim->gfn);
+        PERROR("Error mapping page %lx", gfn);
         goto out;
     }
 
     /* Copy page */
-    ret = write_page(fd, page, i);
+    ret = write_page(fd, page, slot);
     if ( ret != 0 )
     {
-        PERROR("Error copying page %lx", victim->gfn);
+        PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
         goto out;
     }
@@ -593,17 +598,20 @@ static int xenpaging_evict_page(struct x
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
-                              victim->gfn);
+    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
     if ( ret != 0 )
     {
-        PERROR("Error evicting page %lx", victim->gfn);
+        PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
-    DPRINTF("evict_page > gfn %lx pageslot %d\n", victim->gfn, i);
+    DPRINTF("evict_page > gfn %lx pageslot %d\n", gfn, slot);
     /* Notify policy of page being paged out */
-    policy_notify_paged_out(victim->gfn);
+    policy_notify_paged_out(gfn);
+
+    /* Update index */
+    paging->slot_to_gfn[slot] = gfn;
+    paging->gfn_to_slot[gfn] = slot;
 
     /* Record number of evicted pages */
     paging->num_paged_out++;
@@ -710,19 +718,19 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
-static int evict_victim(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
+    unsigned long gfn;
     int j = 0;
     int ret;
 
     do
     {
-        ret = policy_choose_victim(paging, victim);
-        if ( ret != 0 )
+        gfn = policy_choose_victim(paging);
+        if ( gfn == INVALID_MFN )
         {
-            if ( ret != -ENOSPC )
-                ERROR("Error choosing victim");
+            ret = -ENOSPC;
             goto out;
         }
 
@@ -731,9 +739,9 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, victim->gfn);
+        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, victim, fd, i);
+            ret = xenpaging_evict_page(paging, gfn, fd, slot);
         else
         {
             if ( j++ % 1000 == 0 )
@@ -743,7 +751,7 @@ static int evict_victim(struct xenpaging
     }
     while ( ret );
 
-    if ( test_and_set_bit(victim->gfn, paging->bitmap) )
+    if ( test_and_set_bit(gfn, paging->bitmap) )
         ERROR("Page has been evicted before");
 
     ret = 0;
@@ -753,7 +761,7 @@ static int evict_victim(struct xenpaging
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(struct xenpaging *paging, int fd, struct victim *victims, int num_pages)
+static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -761,10 +769,10 @@ static int evict_pages(struct xenpaging 
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
-        if ( victims[slot].gfn != INVALID_MFN )
+        if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, &victims[slot], fd, slot);
+        rc = evict_victim(paging, fd, slot);
         if ( rc == -ENOSPC )
             break;
         if ( rc == -EINTR )
@@ -780,11 +788,10 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     struct xenpaging *paging;
-    struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int num, prev_num = 0;
-    int i;
+    int slot;
     int tot_pages;
     int rc = -1;
     int rc1;
@@ -813,15 +820,6 @@ int main(int argc, char *argv[])
         return 2;
     }
 
-    /* Allocate upper limit of pages to allow growing and shrinking */
-    victims = calloc(paging->max_pages, sizeof(struct victim));
-    if ( !victims )
-        goto out;
-
-    /* Mark all slots as unallocated */
-    for ( i = 0; i < paging->max_pages; i++ )
-        victims[i].gfn = INVALID_MFN;
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -853,32 +851,35 @@ int main(int argc, char *argv[])
         {
             get_request(&paging->mem_event, &req);
 
+            if ( req.gfn > paging->max_pages )
+            {
+                ERROR("Requested gfn %"PRIx64" higher than max_pages %lx\n", req.gfn, paging->max_pages);
+                goto out;
+            }
+
             /* Check if the page has already been paged in */
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->max_pages; i++ )
+                slot = paging->gfn_to_slot[req.gfn];
+
+                /* Sanity check */
+                if ( paging->slot_to_gfn[slot] != req.gfn )
                 {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->max_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
+                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.gfn, slot, paging->slot_to_gfn[slot]);
                     goto out;
                 }
-                
+
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
-                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, i);
+                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, slot);
                     /* Notify policy of page being dropped */
                     policy_notify_dropped(req.gfn);
                 }
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, i);
+                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
                     if ( rc != 0 )
                     {
                         PERROR("Error populating page %"PRIx64"", req.gfn);
@@ -899,7 +900,7 @@ int main(int argc, char *argv[])
                 }
 
                 /* Clear this pagefile slot */
-                victims[i].gfn = INVALID_MFN;
+                paging->slot_to_gfn[slot] = 0;
             }
             else
             {
@@ -969,7 +970,7 @@ int main(int argc, char *argv[])
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
                 num = 42;
-            evict_pages(paging, fd, victims, num);
+            evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -989,7 +990,6 @@ int main(int argc, char *argv[])
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 9cdcedc133e5 -r 83cc7a3fbf4f tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -46,6 +46,9 @@ struct xenpaging {
 
     unsigned long *bitmap;
 
+    unsigned long *slot_to_gfn;
+    int *gfn_to_slot;
+
     struct mem_event mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
@@ -56,13 +59,6 @@ struct xenpaging {
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 
-
-struct victim {
-    /* the gfn of the page to evict */
-    unsigned long gfn;
-};
-
-
 extern void create_page_in_thread(struct xenpaging *paging);
 extern void page_in_trigger(void);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:57:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13:57:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkyfY-0002k6-JT; Wed, 11 Jan 2012 13:56:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RkyfX-0002jk-GN
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:56:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326290200!8024358!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDk1NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDk1NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29973 invoked from network); 11 Jan 2012 13:56:41 -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; 11 Jan 2012 13:56:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326290200; l=854;
	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=VqQOvpOVzXLmD+HdWJKiW93eGdM=;
	b=DnxtJ9SnaNJ++Eo9BPrS12iMUyZyf6fj1KSTyNnb57r5/EXq4pyByKs4yRjwqhdJ9X2
	dQr3aD82fUWt3uW1sdsK+4OALrEgtdsjChR7TjiOgMOPTFiEkpGl/dX0/br4nPrmjnZUm
	YAO/g9/qU97GQKxzyuSdWiW9ZilmQD1K4sA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzAQEURr
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-113-021.pools.arcor-ip.net [88.65.113.21])
	by smtp.strato.de (cohen mo61) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id o05f73o0BDsWZs
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 14:56:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B6E7318634
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 14:56:18 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ce095edc4f970b7b1bd6fa223137fc84607b2654
Message-Id: <ce095edc4f970b7b1bd6.1326290178@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Jan 2012 14:56:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: mmap guest pages read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326290155 -3600
# Node ID ce095edc4f970b7b1bd6fa223137fc84607b2654
# Parent  17b173dbf8663f44790355b2503cb91f9788b84d
xenpaging: mmap guest pages read-only

xenpaging does not write to the gfn, so map the gfn to page-out in
read-only mode.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 17b173dbf866 -r ce095edc4f97 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -584,7 +584,7 @@ static int xenpaging_evict_page(struct x
 
     /* Map page */
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ | PROT_WRITE, &victim, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 13:57:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 13:57:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkyfY-0002k6-JT; Wed, 11 Jan 2012 13:56:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RkyfX-0002jk-GN
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 13:56:47 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326290200!8024358!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDk1NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNDk1NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29973 invoked from network); 11 Jan 2012 13:56:41 -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; 11 Jan 2012 13:56:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326290200; l=854;
	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=VqQOvpOVzXLmD+HdWJKiW93eGdM=;
	b=DnxtJ9SnaNJ++Eo9BPrS12iMUyZyf6fj1KSTyNnb57r5/EXq4pyByKs4yRjwqhdJ9X2
	dQr3aD82fUWt3uW1sdsK+4OALrEgtdsjChR7TjiOgMOPTFiEkpGl/dX0/br4nPrmjnZUm
	YAO/g9/qU97GQKxzyuSdWiW9ZilmQD1K4sA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzAQEURr
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-113-021.pools.arcor-ip.net [88.65.113.21])
	by smtp.strato.de (cohen mo61) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id o05f73o0BDsWZs
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 14:56:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B6E7318634
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 14:56:18 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ce095edc4f970b7b1bd6fa223137fc84607b2654
Message-Id: <ce095edc4f970b7b1bd6.1326290178@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 11 Jan 2012 14:56:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: mmap guest pages read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326290155 -3600
# Node ID ce095edc4f970b7b1bd6fa223137fc84607b2654
# Parent  17b173dbf8663f44790355b2503cb91f9788b84d
xenpaging: mmap guest pages read-only

xenpaging does not write to the gfn, so map the gfn to page-out in
read-only mode.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 17b173dbf866 -r ce095edc4f97 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -584,7 +584,7 @@ static int xenpaging_evict_page(struct x
 
     /* Map page */
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ | PROT_WRITE, &victim, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:27:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14: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 1Rkz8w-0003g9-E6; Wed, 11 Jan 2012 14:27:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@eu.citrix.com>) id 1Rkz8v-0003fw-4P
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:27:09 +0000
X-Env-Sender: Dave.Scott@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326292022!1751740!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25386 invoked from network); 11 Jan 2012 14:27:03 -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;
	11 Jan 2012 14:27:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9948204"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 14:26:40 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 11 Jan 2012
	14:26:39 +0000
From: Dave Scott <Dave.Scott@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@entel.upc.edu>
Date: Wed, 11 Jan 2012 14:26:39 +0000
Thread-Topic: [Xen-devel] Driver domains and hotplug scripts, redux
Thread-Index: AczQWxQdUJ3hCtDhSTCwcrBZla//VgAD3+ig
Message-ID: <81A73678E76EA642801C8F2E4823AD21C4F901F5A9@LONPMAILBOX01.citrite.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326284268.17210.200.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Hi,

Ian Campbell wrote:
> blktap2 doesn't use xenbus IIRC, rather it is created via userspace
> tools/libraries. There _might_ be some hotplug script interaction which
> causes the phys-dev node to get written to the associated blkback
> device
> but I think this is not the case and the toolstack just writes the
> phys-dev because it knows what it is from when it created it.

FYI XCP/xapi is a heavy user of blktap2 and we use it like this:

0. user calls VM.start
1. xapi invokes one of its "storage managers" (plugin scripts, one per
   storage type) telling it to "attach" a disk.
2. the storage manager zones-in the relevant LUN and runs "tap-ctl"
   commands to create a block device. This is returned to xapi.
3. xapi creates the block backend directory in xenstore with
   "params=<block device>".

Xapi used to write the physical-device key directly but I stopped
it doing that when I discovered that using the "params" key worked for
both FreeBSD and Linux storage driver domains. (In the case of a
driver domain on XCP, the "storage manager" code runs inside the driver
domain and xapi talks to it over an RPC mechanism -- currently JSON-rpc
over a network but we'll probably support something else in future: maybe
DBUS-over-libvchan)

We used to store cleanup information in xenstore (under /xapi) but we
don't need to do this anymore, now that xapi remembers which disks it
has "attach"ed.

Cheers,
Dave
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:27:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14: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 1Rkz8w-0003g9-E6; Wed, 11 Jan 2012 14:27:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@eu.citrix.com>) id 1Rkz8v-0003fw-4P
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:27:09 +0000
X-Env-Sender: Dave.Scott@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326292022!1751740!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25386 invoked from network); 11 Jan 2012 14:27:03 -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;
	11 Jan 2012 14:27:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9948204"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 14:26:40 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Wed, 11 Jan 2012
	14:26:39 +0000
From: Dave Scott <Dave.Scott@eu.citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	=?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@entel.upc.edu>
Date: Wed, 11 Jan 2012 14:26:39 +0000
Thread-Topic: [Xen-devel] Driver domains and hotplug scripts, redux
Thread-Index: AczQWxQdUJ3hCtDhSTCwcrBZla//VgAD3+ig
Message-ID: <81A73678E76EA642801C8F2E4823AD21C4F901F5A9@LONPMAILBOX01.citrite.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326284268.17210.200.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Hi,

Ian Campbell wrote:
> blktap2 doesn't use xenbus IIRC, rather it is created via userspace
> tools/libraries. There _might_ be some hotplug script interaction which
> causes the phys-dev node to get written to the associated blkback
> device
> but I think this is not the case and the toolstack just writes the
> phys-dev because it knows what it is from when it created it.

FYI XCP/xapi is a heavy user of blktap2 and we use it like this:

0. user calls VM.start
1. xapi invokes one of its "storage managers" (plugin scripts, one per
   storage type) telling it to "attach" a disk.
2. the storage manager zones-in the relevant LUN and runs "tap-ctl"
   commands to create a block device. This is returned to xapi.
3. xapi creates the block backend directory in xenstore with
   "params=<block device>".

Xapi used to write the physical-device key directly but I stopped
it doing that when I discovered that using the "params" key worked for
both FreeBSD and Linux storage driver domains. (In the case of a
driver domain on XCP, the "storage manager" code runs inside the driver
domain and xapi talks to it over an RPC mechanism -- currently JSON-rpc
over a network but we'll probably support something else in future: maybe
DBUS-over-libvchan)

We used to store cleanup information in xenstore (under /xapi) but we
don't need to do this anymore, now that xapi remembers which disks it
has "attach"ed.

Cheers,
Dave
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:45:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14: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 1RkzQL-0004mA-D9; Wed, 11 Jan 2012 14:45:09 +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 1RkzQJ-0004lT-NA
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:45:07 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326293097!1755072!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 31335 invoked from network); 11 Jan 2012 14:44:59 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 14:44:59 -0000
Received: by pbbb11 with SMTP id b11so4812869pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 06:44: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=nQhVnXYD0gg5gaUGhIXjjExeP14WRK4/YXoa6ah5sjQ=;
	b=HdJ0lBCRjsegoGvL+oM4JlPPJOzVLiQ9mK1OTbA2OlI/5gvMvJhDmZ5Gg5IAD5Q7qA
	NpZ+UqgHLcq/Zv95NqFLlmsEW87NGz7kFnl3vNFWWCM5NZ53R1n2S3km0LCCjf/I1HIH
	BEzXO5u8tLVQ9Y+Ffq5QvcwdMNSrK9Ec9KKWo=
MIME-Version: 1.0
Received: by 10.68.75.135 with SMTP id c7mr11027pbw.43.1326293096358; Wed, 11
	Jan 2012 06:44:56 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 11 Jan 2012 06:44:56 -0800 (PST)
In-Reply-To: <1326284268.17210.200.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
Date: Wed, 11 Jan 2012 15:44:56 +0100
X-Google-Sender-Auth: eRLbcbzXhlZtGJXNmNhnDXv7Log
Message-ID: <CAPLaKK4ZTbPK2kosoGHteVSwsoHZy_swFw4PsH4Kfi+sWLLZJA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzExIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMS0xMSBhdCAxMTo1MCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
SGVsbG8sCj4+Cj4+IFRoaXMgY29tZXMgZnJvbSBteSBleHBlcmllbmNlIHdpdGggWGVuIGFuZCBo
b3RwbHVnIHNjcmlwdHMsIGFuZCBpdAo+PiBtaWdodCBiZSB3cm9uZywgc2luY2UgSSB3YXNuJ3Qg
YWJsZSB0byBmaW5kIGFueSBkb2N1bWVudCBleHBsYWluaW5nCj4+IGV4YWN0bHkgaG93IGhvdHBs
dWcgZXhlY3V0aW9uIHdvcmtzIGFuZCB3aG8gZG9lcyB3aGF0LiBJJ20gZ29ubmEgdHJ5Cj4+IHRv
IGxpc3QgdGhlIHNlcXVlbmNlIG9mIGV2ZW50cyB0aGF0IGhhcHBlbnMgd2hlbiBhIGRldmljZSBp
cyBhZGRlZCAoSQo+PiByZWFsbHkgZG9uJ3Qgd2FudCB0byBrZWVwIG9uIHdpdGggdGhlIGRpc2N1
c2lvbiBpZiB0aGlzIGlzIGEgcHJvdG9jb2wKPj4gb3Igbm90KToKPj4KPj4gMS4gVG9vbHN0YWNr
IHdyaXRlczogL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvPHZiZCBvciB2aWY+Ly4uLiB3aXRoICJz
dGF0ZSA9IDEiLgo+PiAyLiBLZXJuZWwgYWNrcyB4ZW5zdG9yZSBiYWNrZW5kIGRldmljZSBjcmVh
dGlvbiwgY3JlYXRlcyB0aGUgZGV2aWNlCj4+IGFuZCBzZXRzIGJhY2tlbmQgInN0YXRlID0gMiIu
Cj4+IDMuIHhlbmJhY2tlbmRkIG5vdGljZXMgYmFja2VuZCBkZXZpY2Ugd2l0aCAic3RhdGUgPT0g
MiIgYW5kIGxhdW5jaGVzCj4+IGhvdHBsdWcgc2NyaXB0Lgo+Cj4gSW4gdGhlIExpbnV4IEkgdGhp
bmsgc3RhdGUgPT0gMiBjb3JyZXNwb25kcyB0byB0aGUgZ2VuZXJhdGlvbiBvZiBhCj4gdWV2ZW50
IHdoaWNoIHRyaWdnZXJzIHVkZXYgdG8gcnVuIHRoZSBob3RwbHVnIHNjcmlwdC4gSSdtIG5vdCAx
MDAlIHN1cmUKPiB0aGF0IGFsbCBkZXZpY2VzIGRvIHRoaXMgYXQgdGhlIHNhbWUgcG9pbnQgdGhv
dWdoLgo+Cj4+IDQuIEhvdHBsdWcgc2NyaXB0IGV4ZWN1dGVzIG5lY2Vzc2FyeSBhY3Rpb25zIGFu
ZCBzZXRzIGJhY2tlbmQKPj4gImhvdHBsdWctc3RhdHVzID0gY29ubmVjdGVkIi4KPj4gNS4gS2Vy
bmVsIG5vdGljZXMgImhvdHBsdWctc3RhdHVzID09IGNvbm5lY3RlZCIsIHBsdWdzIHRoZSBkZXZp
Y2UsIGFuZAo+PiBzZXRzIHhlbnN0b3JlIGJhY2tlbmQgZGV2aWNlICJzdGF0ZSA9IDQiLgo+Cj4g
SSB0aGluayA0KzUgYXJlIGNvcnJlY3QgZm9yIExpbnV4IG5ldGJhY2sgYnV0IGZvciBibGtiYWNr
IGl0IGFjdHVhbGx5Cj4gd2FpdHMgZm9yIHBoeXMtZGV2IChvciB3aGF0ZXZlciBpdCdzIHJlYWwg
bmFtZSBpcykgdG8gYmUgd3JpdHRlbiB3YXRoZXIKPiB0aGFuIHRoZSBob3RwbHVnLXN0YXR1cyBu
b2RlLgo+Cj4+IFRoaXMgaXMgdHJ1ZSBvbiBOZXRCU0QsIGJlY2F1c2UgdGhlcmUgYXJlbid0IGFu
eSB1c2Vyc3BhY2UgaG90cGx1Zwo+PiBkZXZpY2VzLCBzb21lb25lIHNob3VsZCBwcm9iYWJseSBh
ZGQgdGhlIG1pc3NpbmcgYml0cyBpZiB0aGUgZGV2aWNlIGlzCj4+IGltcGxlbWVudGVkIGluIHVz
ZXJzcGFjZSAoSSdtIG5vdCByZWFsbHkgc3VyZSBvZiB3aGF0IGhhcHBlbnMgaW5zaWRlCj4+IHRo
ZSBrZXJuZWwgaW4gIzIgYW5kICM1LCBzcGVjaWFsbHkgd2hlbiB1c2luZyBibGt0YXAgb3IgcWRp
c2spLgo+Cj4gTm90aGluZyBoYXBwZW5zIGluIHRoZSBrZXJuZWwgZm9yIHFkaXNrLiBJdCBpcyBh
IHNlcGFyYXRlIGJhY2tlbmQgcGF0aAo+IHdoaWNoIHRoZSBrZXJuZWwgZG9lc24ndCB3YXRjaCBv
ciBoYXZlIGEgZHJpdmVyIGZvci4KPgo+IGJsa3RhcDEgYmVoYXZlcyBhIGxvdCBsaWtlIGJsa2Jh
Y2ssIEkgdGhpbmsuCj4KPiBibGt0YXAyIGRvZXNuJ3QgdXNlIHhlbmJ1cyBJSVJDLCByYXRoZXIg
aXQgaXMgY3JlYXRlZCB2aWEgdXNlcnNwYWNlCj4gdG9vbHMvbGlicmFyaWVzLiBUaGVyZSBfbWln
aHRfIGJlIHNvbWUgaG90cGx1ZyBzY3JpcHQgaW50ZXJhY3Rpb24gd2hpY2gKPiBjYXVzZXMgdGhl
IHBoeXMtZGV2IG5vZGUgdG8gZ2V0IHdyaXR0ZW4gdG8gdGhlIGFzc29jaWF0ZWQgYmxrYmFjayBk
ZXZpY2UKPiBidXQgSSB0aGluayB0aGlzIGlzIG5vdCB0aGUgY2FzZSBhbmQgdGhlIHRvb2xzdGFj
ayBqdXN0IHdyaXRlcyB0aGUKPiBwaHlzLWRldiBiZWNhdXNlIGl0IGtub3dzIHdoYXQgaXQgaXMg
ZnJvbSB3aGVuIGl0IGNyZWF0ZWQgaXQuCj4KPj4gUmVnYXJkaW5nIGRldmljZSBzaHV0ZG93bi9k
ZXN0cm95Ogo+Cj4gV2UgbmVlZCB0byBjb25zaWRlciAzIGNhc2VzOgo+IMKgIMKgIMKgKiBndWVz
dCBpbml0aWF0ZWQgZ3JhY2VmdWwgc2h1dGRvd24KPiDCoCDCoCDCoCogdG9vbHN0YWNrIGluaXRp
YXRlZCBncmFjZWZ1bCBzaHV0ZG93bgo+IMKgIMKgIMKgKiB0b29sc3RhY2sgaW5pdGlhdGVkIGZv
cmNlZnVsIGRlc3Ryb3kuCj4KPj4gMS4gR3Vlc3Qgc2V0cyBmcm9udGVuZCBzdGF0ZSB0byA2IChj
bG9zZWQpCj4+IDIuIEtlcm5lbCB1bnBsdWdzIHRoZSBkZXZpY2UgYW5kIHNldHMgYmFja2VuZCAi
c3RhdGUgPSA2Ii4KPj4gMy4geGVuYmFja2VuZGQgbm90aWNlcyBkZXZpY2Ugd2l0aCAic3RhdGUg
PT0gNiIsIGFuZCBwZXJmb3JtcyB0aGUKPj4gbmVjZXNzYXJ5IGNsZWFudXAuCj4+IDMuIFRvb2xz
dGFjayBub3RpY2VzIGRldmljZSB3aXRoICJzdGF0ZSA9PSA2IiBhbmQgcmVtb3ZlcyB4ZW5zdG9y
ZQo+PiBiYWNrZW5kIGVudHJpZXMuCj4KPiBBdCBsZWFzdCBzb21lIGJhY2tlbmQvZnJvbnRlbmRz
IG1ha2UgdXNlIG9mIHN0YXRlIDUgYXMgcGFydCBvZiB0aGlzLAo+IHByb2JhYmx5IGF0ICMxIG9y
ICMyLgo+Cj4gVGhlIG9yZGVyaW5nIG9mICMxIGFuZCAjMiBwcm9iYWJseSBkZXBlbmRzIG9uIHdo
ZXRoZXIgdGhlIGZyb250ZW5kIG9yCj4gdGhlIGJhY2tlbmQgaW5pdGlhdGVzIHRoaW5ncy4KCkkg
ZG9uJ3QgdGhpbmsgZ3JhY2VmdWwgc2h1dGRvd24gcHJlc2VudHMgYW55IHByb2JsZW1zLCBzaW5j
ZSBpdCBjYW4gYmUKaGFuZGxlZCBieSB0aGUgZHJpdmVyIGRvbWFpbiB0aGUgc2FtZSB3YXkgaXQg
aXMgaGFuZGxlZCBieSB0aGUKdG9vbHN0YWNrIHJpZ2h0IG5vdywgYW5kIHRoZSB0b29sc3RhY2sg
c2hvdWxkIGp1c3Qgd2FpdCBmb3I6CgovaG90cGx1Zy9kb21haW4vPGRyaXZlcmRvbV9pZD4vPHZi
ZCBvciB2aWY+Lzxkb211X2lkPi88ZGV2aWNlX2lkPi9zdGF0ZQoKdG8gYmUgc2V0IHRvICJjbG9z
ZWQiLgoKVGhlIGZvcmNlZnVsIHNodXRkb3duIGhvd2V2ZXIsIHByZXNlbnRzIHNvbWUgcHJvYmxl
bXMsIGFuZCBJIGRvbid0CnRoaW5rIHRoZSB0b29sc3RhY2sgc2hvdWxkIHJlbW92ZSB0aGUgYmFj
a2VuZCwgaW5zdGVhZCB3ZSBzaG91bGQgYWRkCnNvbWV0aGluZyBsaWtlOgoKL2hvdHBsdWcvZG9t
YWluLzxkcml2ZXJkb21faWQ+Lzx2YmQgb3IgdmlmPi88ZG9tdV9pZD4vPGRldmljZV9pZD4vZGVz
dHJveQoKQW5kIGxldCB0aGUgdG9vbHN0YWNrIHNldCB0aGlzIHRvIDEgYW5kIHdhaXQgZm9yIGhv
dHBsdWcgc3RhdGUgdG8gYmUKc2V0IHRvICJjbG9zZWQiIChqdXN0IGxpa2UgYSBub3JtYWwgc2h1
dGRvd24pLCB0aGVuIHRoZSBkcml2ZXIgZG9tYWluCnNob3VsZCB0YWtlIGNhcmUgb2YgZGVzdHJv
eWluZyB0aGUgZGV2aWNlIGFuZCByZW1vdmluZyB0aGUgYmFja2VuZCBhbmQKZnJvbnRlbmQgbm9k
ZXMsIHNpbmNlIGl0IHdhcyB0aGUgb25lIHRoYXQgY3JlYXRlZCB0aGVtLgoKPiBUaGUgZm9yY2Vm
dWwgZGVzdHJveSBjYXNlIGlzIGRpZmZlcmVudCwgaXQgaXMgZWZmZWN0aXZlbHk6Cj4gMS4gcm0g
YmFja2VuZCBkaXIgaW4geGVuc3RvcmUuCj4KPiBTb21ld2hlcmUgaW4gYm90aCBvZiB0aGVzZSBh
IExpbnV4IGJhY2tlbmQgd2lsbCBnZW5lcmF0ZSBhIGhvdHBsdWcgZXZlbnQKPiB3aGljaCB3aWxs
IGNhdXNlIGEgc2NyaXB0IHRvIHJ1biwgYWx0aG91Z2ggaW4gc29tZSBjYXNlcyB0aGUgc2NyaXB0
Cj4gY2FuJ3QgZG8gbXVjaCBiZWNhdXNlIHRoZSBiYWNrZW5kIGRpciBpcyBhbHJlYWR5IGdvbmUu
Li4KPgo+PiBOb3RpY2UgdGhhdCBJJ3ZlIHVzZWQgdHdvICMzLCB0aGF0J3Mgd2hlcmUgdGhlIHJh
Y2UgY29uZGl0aW9uIGhhcHBlbnMsCj4+IGJlY2F1c2UgdGhlcmUncyBubyBzeW5jaHJvbml6YXRp
b24gYmV0d2VlbiB0b29sc3RhY2sgYW5kCj4+IGhvdHBsdWcveGVuYmFja2VuZGQgdG8ga25vdyB3
aGVuIGhvdHBsdWcgc2NyaXB0cyBoYXZlIGJlZW4gZXhlY3V0ZWQKPj4gKGhvd2V2ZXIgd2Ugc2hv
dWxkIGJlIGFibGUgdG8gc3luY2hyb25pemUgdGhpcyB3YXRjaGluZwo+PiAiaG90cGx1Zy1zdGF0
dXMiIGluc3RlYWQgb2YgInN0YXRlIiwgYW5kIHdhaXRpbmcgZm9yIGl0IHRvIGNoYW5nZSB0bwo+
PiAiZGlzY29ubmVjdGVkIikuCj4+Cj4+IE5vdywgd2UgaGF2ZSB0byBkZWNpZGUgaG93IHRvIGZp
eCB0aGUgc2h1dGRvd24vZGVzdHJveSByYWNlIGFuZCBob3cgdG8KPj4gaW1wbGVtZW50IHRoaXMg
b3V0c2lkZSBvZiB0aGUgRG9tMC4gSSdtIG5vdCByZWFsbHkgc3VyZSBpZiBpdCdzIGEgZ29vZAo+
PiBpZGVhIHRvIHRyeSBzbyBoYXJkIHRvIGtlZXAgdGhpcyBmbG93IGludGFjdCwgSSB0aGluayBp
dCdzIGJlc3QgdG8gdHJ5Cj4+IHRvIGRlZmluZSBhIGZsb3cgdGhhdCBzb2x2ZXMgb3VyIGN1cnJl
bnQgcHJvYmxlbXMsIHJlZ2FyZGxlc3Mgb2YgaG93Cj4+IHRoaW5ncyBhcmUgbm93LCBhbmQgdGhl
biB0cnkgdG8gbWFwIGJvdGggZmxvd3MgdG8gc2VlIHdoYXQgc2hvdWxkIGJlCj4+IGNoYW5nZWQg
YW5kIGhvdy4KPj4KPj4gU2luY2UgdGhlIGRldmljZSB3aWxsIGJlIHBsdWdnZWQgZnJvbSBhIERv
bWFpbiBkaWZmZXJlbnQgdGhhbiBEb20wLAo+PiB0aGUgdG9vbHN0YWNrIGRvZXNuJ3QgcmVhbGx5
IChhbmQgcHJvYmFibHkgc2hvdWxkbid0KSBrbm93IGFueXRoaW5nCj4+IGFib3V0IHdoaWNoIGJh
Y2tlbmQgdHlwZSB3aWxsIGJlIHVzZWQgKHBoeSwgYmxrdGFwLCBxZGlzay4uLikuIEhhdmluZwo+
PiB0aGF0IGluIG1pbmQsIEkgZG9uJ3Qga25vdyBob3cgY2FuIHdlIHdyaXRlCj4+IC9sb2NhbC9k
b21haW4vPGRyaXZlcmRvbV9pZD4vYmFja2VuZC8uLi4gZnJvbSBEb20wLCBpbnN0ZWFkIHdlIHNo
b3VsZAo+PiBjcmVhdGUgc29tZXRoaW5nIGxpa2U6Cj4+Cj4+IC9ob3RwbHVnL2RvbWFpbi88ZHJp
dmVyZG9tX2lkPi88dmJkIG9yIHZpZj4vPGRvbXVfaWQ+LzxkZXZpY2VfaWQ+L3BhcmFtcwo+PiAv
aG90cGx1Zy9kb21haW4vPGRyaXZlcmRvbV9pZD4vPHZiZCBvciB2aWY+Lzxkb211X2lkPi88ZGV2
aWNlX2lkPi9zY3JpcHQKPj4gL2hvdHBsdWcvZG9tYWluLzxkcml2ZXJkb21faWQ+Lzx2YmQgb3Ig
dmlmPi88ZG9tdV9pZD4vPGRldmljZV9pZD4vc3RhdGUKPj4gW1RoaXMgc2VlbSBsaWtlIHRoZSBt
aW5pbXVtIG5lY2Vzc2FyeSBwYXJhbWV0ZXJzLCBidXQgcHJvYmFibHkgdGhlcmUKPj4gYXJlIG90
aGVycywgc28gYWRkIHdoYXQgeW91IGZlZWwgbmVjZXNzYXJ5XQo+Pgo+PiBXaXRoIHRoYXQgdGhl
IGRyaXZlciBkb21haW4gc2hvdWxkIGJlIGFibGUgdG8gY3JlYXRlCj4+IC9sb2NhbC9kb21haW4v
PGRyaXZlcmRvbWFpbl9pZD4vYmFja2VuZC8uLi4gYW5kIHRoZSBmcm9udGVuZCBhbHNvLgo+Pgo+
PiBJJ20gbm90IHN1cmUgaWYgd2Ugc2hvdWxkIGNvbnRyb2wgdGhlIGV4ZWN1dGlvbiBvZiBob3Rw
bHVnIHNjcmlwdHMKPj4gZnJvbSBEb20wLCBvciBpbnN0ZWFkIGxldCB0aGUgZHJpdmVyIGRvbWFp
biBkZWNpZGUgd2hlbiBpdCdzIGJlc3QgdG8KPj4gZXhlY3V0ZSBlYWNoIHNjcmlwdC4gVGhpcyBh
ZGRzIC9ob3RwbHVnIHRvIHhlbnN0b3JlLCBidXQgdGhlCj4+IHBsdWcvdW5wbHVnIHNlcXVlbmNl
IGNvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZSBvbmUgd2UgY3VycmVudGx5IGhhdmUsCj4+IHRoZSBv
bmx5IGNoYW5nZSBpcyB0aGF0IGVhY2ggZHJpdmVyIGRvbWFpbiBpcyBpbiBjaGFyZ2Ugb2Ygd3Jp
dGluZwo+PiBpdCdzIG93biB4ZW5zdG9yZSBiYWNrZW5kL2Zyb250ZW5kIGVudHJpZXMgdG8gdHJp
Z2dlciB0aGUgcGx1Zwo+PiBzZXF1ZW5jZS4KPj4KPj4gSG9wZSB0aGF0IGhlbHBzLCBSb2dlci4K
Pj4KPj4gKHhlbi1kZXZlbCBtYWlsaW5nIGxpc3Qgd2FzIHJlbW92ZWQgYXQgc29tZSBwb2ludCBk
dXJpbmcgdGhlCj4+IGNvbnZlcnNhdGlvbiwgc28gSSdtIGFkZGluZyBpdCBhZ2FpbikKPj4KPj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRl
dmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+PiBodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPgo+CgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:45:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14: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 1RkzQL-0004mA-D9; Wed, 11 Jan 2012 14:45:09 +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 1RkzQJ-0004lT-NA
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:45:07 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326293097!1755072!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 31335 invoked from network); 11 Jan 2012 14:44:59 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 14:44:59 -0000
Received: by pbbb11 with SMTP id b11so4812869pbb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 06:44: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=nQhVnXYD0gg5gaUGhIXjjExeP14WRK4/YXoa6ah5sjQ=;
	b=HdJ0lBCRjsegoGvL+oM4JlPPJOzVLiQ9mK1OTbA2OlI/5gvMvJhDmZ5Gg5IAD5Q7qA
	NpZ+UqgHLcq/Zv95NqFLlmsEW87NGz7kFnl3vNFWWCM5NZ53R1n2S3km0LCCjf/I1HIH
	BEzXO5u8tLVQ9Y+Ffq5QvcwdMNSrK9Ec9KKWo=
MIME-Version: 1.0
Received: by 10.68.75.135 with SMTP id c7mr11027pbw.43.1326293096358; Wed, 11
	Jan 2012 06:44:56 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 11 Jan 2012 06:44:56 -0800 (PST)
In-Reply-To: <1326284268.17210.200.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.23822.715733.455559@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101547540.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
Date: Wed, 11 Jan 2012 15:44:56 +0100
X-Google-Sender-Auth: eRLbcbzXhlZtGJXNmNhnDXv7Log
Message-ID: <CAPLaKK4ZTbPK2kosoGHteVSwsoHZy_swFw4PsH4Kfi+sWLLZJA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzExIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMS0xMSBhdCAxMTo1MCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
SGVsbG8sCj4+Cj4+IFRoaXMgY29tZXMgZnJvbSBteSBleHBlcmllbmNlIHdpdGggWGVuIGFuZCBo
b3RwbHVnIHNjcmlwdHMsIGFuZCBpdAo+PiBtaWdodCBiZSB3cm9uZywgc2luY2UgSSB3YXNuJ3Qg
YWJsZSB0byBmaW5kIGFueSBkb2N1bWVudCBleHBsYWluaW5nCj4+IGV4YWN0bHkgaG93IGhvdHBs
dWcgZXhlY3V0aW9uIHdvcmtzIGFuZCB3aG8gZG9lcyB3aGF0LiBJJ20gZ29ubmEgdHJ5Cj4+IHRv
IGxpc3QgdGhlIHNlcXVlbmNlIG9mIGV2ZW50cyB0aGF0IGhhcHBlbnMgd2hlbiBhIGRldmljZSBp
cyBhZGRlZCAoSQo+PiByZWFsbHkgZG9uJ3Qgd2FudCB0byBrZWVwIG9uIHdpdGggdGhlIGRpc2N1
c2lvbiBpZiB0aGlzIGlzIGEgcHJvdG9jb2wKPj4gb3Igbm90KToKPj4KPj4gMS4gVG9vbHN0YWNr
IHdyaXRlczogL2xvY2FsL2RvbWFpbi8wL2JhY2tlbmQvPHZiZCBvciB2aWY+Ly4uLiB3aXRoICJz
dGF0ZSA9IDEiLgo+PiAyLiBLZXJuZWwgYWNrcyB4ZW5zdG9yZSBiYWNrZW5kIGRldmljZSBjcmVh
dGlvbiwgY3JlYXRlcyB0aGUgZGV2aWNlCj4+IGFuZCBzZXRzIGJhY2tlbmQgInN0YXRlID0gMiIu
Cj4+IDMuIHhlbmJhY2tlbmRkIG5vdGljZXMgYmFja2VuZCBkZXZpY2Ugd2l0aCAic3RhdGUgPT0g
MiIgYW5kIGxhdW5jaGVzCj4+IGhvdHBsdWcgc2NyaXB0Lgo+Cj4gSW4gdGhlIExpbnV4IEkgdGhp
bmsgc3RhdGUgPT0gMiBjb3JyZXNwb25kcyB0byB0aGUgZ2VuZXJhdGlvbiBvZiBhCj4gdWV2ZW50
IHdoaWNoIHRyaWdnZXJzIHVkZXYgdG8gcnVuIHRoZSBob3RwbHVnIHNjcmlwdC4gSSdtIG5vdCAx
MDAlIHN1cmUKPiB0aGF0IGFsbCBkZXZpY2VzIGRvIHRoaXMgYXQgdGhlIHNhbWUgcG9pbnQgdGhv
dWdoLgo+Cj4+IDQuIEhvdHBsdWcgc2NyaXB0IGV4ZWN1dGVzIG5lY2Vzc2FyeSBhY3Rpb25zIGFu
ZCBzZXRzIGJhY2tlbmQKPj4gImhvdHBsdWctc3RhdHVzID0gY29ubmVjdGVkIi4KPj4gNS4gS2Vy
bmVsIG5vdGljZXMgImhvdHBsdWctc3RhdHVzID09IGNvbm5lY3RlZCIsIHBsdWdzIHRoZSBkZXZp
Y2UsIGFuZAo+PiBzZXRzIHhlbnN0b3JlIGJhY2tlbmQgZGV2aWNlICJzdGF0ZSA9IDQiLgo+Cj4g
SSB0aGluayA0KzUgYXJlIGNvcnJlY3QgZm9yIExpbnV4IG5ldGJhY2sgYnV0IGZvciBibGtiYWNr
IGl0IGFjdHVhbGx5Cj4gd2FpdHMgZm9yIHBoeXMtZGV2IChvciB3aGF0ZXZlciBpdCdzIHJlYWwg
bmFtZSBpcykgdG8gYmUgd3JpdHRlbiB3YXRoZXIKPiB0aGFuIHRoZSBob3RwbHVnLXN0YXR1cyBu
b2RlLgo+Cj4+IFRoaXMgaXMgdHJ1ZSBvbiBOZXRCU0QsIGJlY2F1c2UgdGhlcmUgYXJlbid0IGFu
eSB1c2Vyc3BhY2UgaG90cGx1Zwo+PiBkZXZpY2VzLCBzb21lb25lIHNob3VsZCBwcm9iYWJseSBh
ZGQgdGhlIG1pc3NpbmcgYml0cyBpZiB0aGUgZGV2aWNlIGlzCj4+IGltcGxlbWVudGVkIGluIHVz
ZXJzcGFjZSAoSSdtIG5vdCByZWFsbHkgc3VyZSBvZiB3aGF0IGhhcHBlbnMgaW5zaWRlCj4+IHRo
ZSBrZXJuZWwgaW4gIzIgYW5kICM1LCBzcGVjaWFsbHkgd2hlbiB1c2luZyBibGt0YXAgb3IgcWRp
c2spLgo+Cj4gTm90aGluZyBoYXBwZW5zIGluIHRoZSBrZXJuZWwgZm9yIHFkaXNrLiBJdCBpcyBh
IHNlcGFyYXRlIGJhY2tlbmQgcGF0aAo+IHdoaWNoIHRoZSBrZXJuZWwgZG9lc24ndCB3YXRjaCBv
ciBoYXZlIGEgZHJpdmVyIGZvci4KPgo+IGJsa3RhcDEgYmVoYXZlcyBhIGxvdCBsaWtlIGJsa2Jh
Y2ssIEkgdGhpbmsuCj4KPiBibGt0YXAyIGRvZXNuJ3QgdXNlIHhlbmJ1cyBJSVJDLCByYXRoZXIg
aXQgaXMgY3JlYXRlZCB2aWEgdXNlcnNwYWNlCj4gdG9vbHMvbGlicmFyaWVzLiBUaGVyZSBfbWln
aHRfIGJlIHNvbWUgaG90cGx1ZyBzY3JpcHQgaW50ZXJhY3Rpb24gd2hpY2gKPiBjYXVzZXMgdGhl
IHBoeXMtZGV2IG5vZGUgdG8gZ2V0IHdyaXR0ZW4gdG8gdGhlIGFzc29jaWF0ZWQgYmxrYmFjayBk
ZXZpY2UKPiBidXQgSSB0aGluayB0aGlzIGlzIG5vdCB0aGUgY2FzZSBhbmQgdGhlIHRvb2xzdGFj
ayBqdXN0IHdyaXRlcyB0aGUKPiBwaHlzLWRldiBiZWNhdXNlIGl0IGtub3dzIHdoYXQgaXQgaXMg
ZnJvbSB3aGVuIGl0IGNyZWF0ZWQgaXQuCj4KPj4gUmVnYXJkaW5nIGRldmljZSBzaHV0ZG93bi9k
ZXN0cm95Ogo+Cj4gV2UgbmVlZCB0byBjb25zaWRlciAzIGNhc2VzOgo+IMKgIMKgIMKgKiBndWVz
dCBpbml0aWF0ZWQgZ3JhY2VmdWwgc2h1dGRvd24KPiDCoCDCoCDCoCogdG9vbHN0YWNrIGluaXRp
YXRlZCBncmFjZWZ1bCBzaHV0ZG93bgo+IMKgIMKgIMKgKiB0b29sc3RhY2sgaW5pdGlhdGVkIGZv
cmNlZnVsIGRlc3Ryb3kuCj4KPj4gMS4gR3Vlc3Qgc2V0cyBmcm9udGVuZCBzdGF0ZSB0byA2IChj
bG9zZWQpCj4+IDIuIEtlcm5lbCB1bnBsdWdzIHRoZSBkZXZpY2UgYW5kIHNldHMgYmFja2VuZCAi
c3RhdGUgPSA2Ii4KPj4gMy4geGVuYmFja2VuZGQgbm90aWNlcyBkZXZpY2Ugd2l0aCAic3RhdGUg
PT0gNiIsIGFuZCBwZXJmb3JtcyB0aGUKPj4gbmVjZXNzYXJ5IGNsZWFudXAuCj4+IDMuIFRvb2xz
dGFjayBub3RpY2VzIGRldmljZSB3aXRoICJzdGF0ZSA9PSA2IiBhbmQgcmVtb3ZlcyB4ZW5zdG9y
ZQo+PiBiYWNrZW5kIGVudHJpZXMuCj4KPiBBdCBsZWFzdCBzb21lIGJhY2tlbmQvZnJvbnRlbmRz
IG1ha2UgdXNlIG9mIHN0YXRlIDUgYXMgcGFydCBvZiB0aGlzLAo+IHByb2JhYmx5IGF0ICMxIG9y
ICMyLgo+Cj4gVGhlIG9yZGVyaW5nIG9mICMxIGFuZCAjMiBwcm9iYWJseSBkZXBlbmRzIG9uIHdo
ZXRoZXIgdGhlIGZyb250ZW5kIG9yCj4gdGhlIGJhY2tlbmQgaW5pdGlhdGVzIHRoaW5ncy4KCkkg
ZG9uJ3QgdGhpbmsgZ3JhY2VmdWwgc2h1dGRvd24gcHJlc2VudHMgYW55IHByb2JsZW1zLCBzaW5j
ZSBpdCBjYW4gYmUKaGFuZGxlZCBieSB0aGUgZHJpdmVyIGRvbWFpbiB0aGUgc2FtZSB3YXkgaXQg
aXMgaGFuZGxlZCBieSB0aGUKdG9vbHN0YWNrIHJpZ2h0IG5vdywgYW5kIHRoZSB0b29sc3RhY2sg
c2hvdWxkIGp1c3Qgd2FpdCBmb3I6CgovaG90cGx1Zy9kb21haW4vPGRyaXZlcmRvbV9pZD4vPHZi
ZCBvciB2aWY+Lzxkb211X2lkPi88ZGV2aWNlX2lkPi9zdGF0ZQoKdG8gYmUgc2V0IHRvICJjbG9z
ZWQiLgoKVGhlIGZvcmNlZnVsIHNodXRkb3duIGhvd2V2ZXIsIHByZXNlbnRzIHNvbWUgcHJvYmxl
bXMsIGFuZCBJIGRvbid0CnRoaW5rIHRoZSB0b29sc3RhY2sgc2hvdWxkIHJlbW92ZSB0aGUgYmFj
a2VuZCwgaW5zdGVhZCB3ZSBzaG91bGQgYWRkCnNvbWV0aGluZyBsaWtlOgoKL2hvdHBsdWcvZG9t
YWluLzxkcml2ZXJkb21faWQ+Lzx2YmQgb3IgdmlmPi88ZG9tdV9pZD4vPGRldmljZV9pZD4vZGVz
dHJveQoKQW5kIGxldCB0aGUgdG9vbHN0YWNrIHNldCB0aGlzIHRvIDEgYW5kIHdhaXQgZm9yIGhv
dHBsdWcgc3RhdGUgdG8gYmUKc2V0IHRvICJjbG9zZWQiIChqdXN0IGxpa2UgYSBub3JtYWwgc2h1
dGRvd24pLCB0aGVuIHRoZSBkcml2ZXIgZG9tYWluCnNob3VsZCB0YWtlIGNhcmUgb2YgZGVzdHJv
eWluZyB0aGUgZGV2aWNlIGFuZCByZW1vdmluZyB0aGUgYmFja2VuZCBhbmQKZnJvbnRlbmQgbm9k
ZXMsIHNpbmNlIGl0IHdhcyB0aGUgb25lIHRoYXQgY3JlYXRlZCB0aGVtLgoKPiBUaGUgZm9yY2Vm
dWwgZGVzdHJveSBjYXNlIGlzIGRpZmZlcmVudCwgaXQgaXMgZWZmZWN0aXZlbHk6Cj4gMS4gcm0g
YmFja2VuZCBkaXIgaW4geGVuc3RvcmUuCj4KPiBTb21ld2hlcmUgaW4gYm90aCBvZiB0aGVzZSBh
IExpbnV4IGJhY2tlbmQgd2lsbCBnZW5lcmF0ZSBhIGhvdHBsdWcgZXZlbnQKPiB3aGljaCB3aWxs
IGNhdXNlIGEgc2NyaXB0IHRvIHJ1biwgYWx0aG91Z2ggaW4gc29tZSBjYXNlcyB0aGUgc2NyaXB0
Cj4gY2FuJ3QgZG8gbXVjaCBiZWNhdXNlIHRoZSBiYWNrZW5kIGRpciBpcyBhbHJlYWR5IGdvbmUu
Li4KPgo+PiBOb3RpY2UgdGhhdCBJJ3ZlIHVzZWQgdHdvICMzLCB0aGF0J3Mgd2hlcmUgdGhlIHJh
Y2UgY29uZGl0aW9uIGhhcHBlbnMsCj4+IGJlY2F1c2UgdGhlcmUncyBubyBzeW5jaHJvbml6YXRp
b24gYmV0d2VlbiB0b29sc3RhY2sgYW5kCj4+IGhvdHBsdWcveGVuYmFja2VuZGQgdG8ga25vdyB3
aGVuIGhvdHBsdWcgc2NyaXB0cyBoYXZlIGJlZW4gZXhlY3V0ZWQKPj4gKGhvd2V2ZXIgd2Ugc2hv
dWxkIGJlIGFibGUgdG8gc3luY2hyb25pemUgdGhpcyB3YXRjaGluZwo+PiAiaG90cGx1Zy1zdGF0
dXMiIGluc3RlYWQgb2YgInN0YXRlIiwgYW5kIHdhaXRpbmcgZm9yIGl0IHRvIGNoYW5nZSB0bwo+
PiAiZGlzY29ubmVjdGVkIikuCj4+Cj4+IE5vdywgd2UgaGF2ZSB0byBkZWNpZGUgaG93IHRvIGZp
eCB0aGUgc2h1dGRvd24vZGVzdHJveSByYWNlIGFuZCBob3cgdG8KPj4gaW1wbGVtZW50IHRoaXMg
b3V0c2lkZSBvZiB0aGUgRG9tMC4gSSdtIG5vdCByZWFsbHkgc3VyZSBpZiBpdCdzIGEgZ29vZAo+
PiBpZGVhIHRvIHRyeSBzbyBoYXJkIHRvIGtlZXAgdGhpcyBmbG93IGludGFjdCwgSSB0aGluayBp
dCdzIGJlc3QgdG8gdHJ5Cj4+IHRvIGRlZmluZSBhIGZsb3cgdGhhdCBzb2x2ZXMgb3VyIGN1cnJl
bnQgcHJvYmxlbXMsIHJlZ2FyZGxlc3Mgb2YgaG93Cj4+IHRoaW5ncyBhcmUgbm93LCBhbmQgdGhl
biB0cnkgdG8gbWFwIGJvdGggZmxvd3MgdG8gc2VlIHdoYXQgc2hvdWxkIGJlCj4+IGNoYW5nZWQg
YW5kIGhvdy4KPj4KPj4gU2luY2UgdGhlIGRldmljZSB3aWxsIGJlIHBsdWdnZWQgZnJvbSBhIERv
bWFpbiBkaWZmZXJlbnQgdGhhbiBEb20wLAo+PiB0aGUgdG9vbHN0YWNrIGRvZXNuJ3QgcmVhbGx5
IChhbmQgcHJvYmFibHkgc2hvdWxkbid0KSBrbm93IGFueXRoaW5nCj4+IGFib3V0IHdoaWNoIGJh
Y2tlbmQgdHlwZSB3aWxsIGJlIHVzZWQgKHBoeSwgYmxrdGFwLCBxZGlzay4uLikuIEhhdmluZwo+
PiB0aGF0IGluIG1pbmQsIEkgZG9uJ3Qga25vdyBob3cgY2FuIHdlIHdyaXRlCj4+IC9sb2NhbC9k
b21haW4vPGRyaXZlcmRvbV9pZD4vYmFja2VuZC8uLi4gZnJvbSBEb20wLCBpbnN0ZWFkIHdlIHNo
b3VsZAo+PiBjcmVhdGUgc29tZXRoaW5nIGxpa2U6Cj4+Cj4+IC9ob3RwbHVnL2RvbWFpbi88ZHJp
dmVyZG9tX2lkPi88dmJkIG9yIHZpZj4vPGRvbXVfaWQ+LzxkZXZpY2VfaWQ+L3BhcmFtcwo+PiAv
aG90cGx1Zy9kb21haW4vPGRyaXZlcmRvbV9pZD4vPHZiZCBvciB2aWY+Lzxkb211X2lkPi88ZGV2
aWNlX2lkPi9zY3JpcHQKPj4gL2hvdHBsdWcvZG9tYWluLzxkcml2ZXJkb21faWQ+Lzx2YmQgb3Ig
dmlmPi88ZG9tdV9pZD4vPGRldmljZV9pZD4vc3RhdGUKPj4gW1RoaXMgc2VlbSBsaWtlIHRoZSBt
aW5pbXVtIG5lY2Vzc2FyeSBwYXJhbWV0ZXJzLCBidXQgcHJvYmFibHkgdGhlcmUKPj4gYXJlIG90
aGVycywgc28gYWRkIHdoYXQgeW91IGZlZWwgbmVjZXNzYXJ5XQo+Pgo+PiBXaXRoIHRoYXQgdGhl
IGRyaXZlciBkb21haW4gc2hvdWxkIGJlIGFibGUgdG8gY3JlYXRlCj4+IC9sb2NhbC9kb21haW4v
PGRyaXZlcmRvbWFpbl9pZD4vYmFja2VuZC8uLi4gYW5kIHRoZSBmcm9udGVuZCBhbHNvLgo+Pgo+
PiBJJ20gbm90IHN1cmUgaWYgd2Ugc2hvdWxkIGNvbnRyb2wgdGhlIGV4ZWN1dGlvbiBvZiBob3Rw
bHVnIHNjcmlwdHMKPj4gZnJvbSBEb20wLCBvciBpbnN0ZWFkIGxldCB0aGUgZHJpdmVyIGRvbWFp
biBkZWNpZGUgd2hlbiBpdCdzIGJlc3QgdG8KPj4gZXhlY3V0ZSBlYWNoIHNjcmlwdC4gVGhpcyBh
ZGRzIC9ob3RwbHVnIHRvIHhlbnN0b3JlLCBidXQgdGhlCj4+IHBsdWcvdW5wbHVnIHNlcXVlbmNl
IGNvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZSBvbmUgd2UgY3VycmVudGx5IGhhdmUsCj4+IHRoZSBv
bmx5IGNoYW5nZSBpcyB0aGF0IGVhY2ggZHJpdmVyIGRvbWFpbiBpcyBpbiBjaGFyZ2Ugb2Ygd3Jp
dGluZwo+PiBpdCdzIG93biB4ZW5zdG9yZSBiYWNrZW5kL2Zyb250ZW5kIGVudHJpZXMgdG8gdHJp
Z2dlciB0aGUgcGx1Zwo+PiBzZXF1ZW5jZS4KPj4KPj4gSG9wZSB0aGF0IGhlbHBzLCBSb2dlci4K
Pj4KPj4gKHhlbi1kZXZlbCBtYWlsaW5nIGxpc3Qgd2FzIHJlbW92ZWQgYXQgc29tZSBwb2ludCBk
dXJpbmcgdGhlCj4+IGNvbnZlcnNhdGlvbiwgc28gSSdtIGFkZGluZyBpdCBhZ2FpbikKPj4KPj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVuLWRl
dmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+PiBodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPgo+CgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:51:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkzWe-00059m-94; Wed, 11 Jan 2012 14:51:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1RkzWd-00059N-9l
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:51:39 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326293491!8716048!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13739 invoked from network); 11 Jan 2012 14:51:32 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 14:51:32 -0000
Received: by obbwd20 with SMTP id wd20so2966499obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 06:51:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=Emd4CIPS34x3S5tV5NoU6NF1yzEpDVdOkPR1CZ2/A/0=;
	b=Y8Kh2KXVHJm5OT9j3LhlMg2VEso1xpq4FaTczmYkBYjIQT1IB3lZszV/Ag2jPHo2Or
	tyzYjsDI/7L20rVazIzG3a/L7yKC3ycGM5yRWq1QX1UqgnRhm5kCageBCqR7Vp4vdWFN
	yShw0vWZ+izlKnbBfTidubUS44LO/hTI1+fmY=
Received: by 10.182.59.41 with SMTP id w9mr22596958obq.70.1326293491209; Wed,
	11 Jan 2012 06:51:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.22.163 with HTTP; Wed, 11 Jan 2012 06:51:10 -0800 (PST)
In-Reply-To: <CB333F08.28854%keir.xen@gmail.com>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
	<CB333F08.28854%keir.xen@gmail.com>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 11 Jan 2012 14:51:10 +0000
X-Google-Sender-Auth: rvjjdqX-xrATWXc0GbyMV3UJVyw
Message-ID: <CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBKYW4gMTEsIDIwMTIgYXQgMToyOCBQTSwgS2VpciBGcmFzZXIgPGtlaXIueGVuQGdt
YWlsLmNvbT4gd3JvdGU6Cj4gT24gMTEvMDEvMjAxMiAxMzowNiwgIkp1bGlhbiBQaWRhbmNldCIg
PGp1bGlhbi5waWRhbmNldEBnbWFpbC5jb20+IHdyb3RlOgo+Cj4+IEhpLAo+Pgo+PiBXaGVuIHRy
eWluZyB0byBib290IHhlbiA0LjEgb24gbmV3IGhhcmR3YXJlLCBYZW4gYmVjb21lIHN0dWNrIGlu
Cj4+IHdha2V1cF9zZWNvbmRhcnlfY3B1KCkgaW4gdGhlIG1kZWxheSBmdW5jdGlvbi4KPj4KPj4g
wqAgwqAgRHByaW50aygiV2FpdGluZyBmb3Igc2VuZCB0byBmaW5pc2guLi5cbiIpOwo+PiDCoCDC
oCB0aW1lb3V0ID0gMDsKPj4gwqAgwqAgZG8gewo+PiDCoCDCoCDCoCDCoCBEcHJpbnRrKCIrIik7
Cj4+IMKgIMKgIMKgIMKgIHVkZWxheSgxMDApOwo+PiDCoCDCoCDCoCDCoCBpZiAoICF4MmFwaWNf
ZW5hYmxlZCApCj4+IMKgIMKgIMKgIMKgIMKgIMKgIHNlbmRfc3RhdHVzID0gYXBpY19yZWFkKEFQ
SUNfSUNSKSAmIEFQSUNfSUNSX0JVU1k7Cj4+IMKgIMKgIH0gd2hpbGUgKCBzZW5kX3N0YXR1cyAm
JiAodGltZW91dCsrIDwgMTAwMCkgKTsKPj4KPj4gwqAgwqAgcHJpbnRrKCJiZWZvcmUgbWRlbGF5
XG4iKTsKPj4gwqAgwqAgbWRlbGF5KDEwKTsKPj4gwqAgwqAgcHJpbnRrKCJhZnRlciBtZGVsYXlc
biIpOwo+Pgo+PiDCoCDCoCBEcHJpbnRrKCJEZWFzc2VydGluZyBJTklULlxuIik7Cj4+Cj4+IFRo
ZSBoYW5nIGNhbiBoYXBwZW4gcmFuZG9tbHkgd2l0aCBhbnkgb2YgdGhlIENQVXMgdG8gd2FrZSB1
cCBhbmQKPj4gc29tZXRpbWUgZG9lc24ndCBoYXBwZW4gYXQgYWxsLgo+PiBSZXBsYWNpbmcgbWRl
bGF5KDEwKSB3aXRoIHVkZWxheSgxMCkgc2VlbXMgdG8gZml4IHRoZSBpc3N1ZS4KPgo+IERvIHlv
dSBzZWUgdGhpcyBpbiB4ZW4tdW5zdGFibGU/IEhvcGVmdWxseSBpdCBpcyB3b3JraW5nIHRoZXJl
LCBhbmQgd2UgY2FuCj4gc2ltcGx5IGJhY2twb3J0IHRoZSBmaXguCj4KCkkgY2hlY2tlZCB5ZXN0
ZXJkYXkgYW5kIHRoZSBjb2RlIG9mIHRoaXMgZnVuY3Rpb24gaXMgdGhlIHNhbWUgaW4KeGVuLXVu
c3RhYmxlLCBidXQgSSBkb24ndCBlbmNvdW50ZXIgdGhlIHByb2JsZW0gd2l0aCB4ZW4tdW5zdGFi
bGUuCgpXaGF0IGNvbmNlcm5zIG1lIGlzIHRoYXQgdGhpcyBpcyB0aGUgb25seSBwbGFjZSBpbiB0
aGUgZnVuY3Rpb24gd2hlcmUKbWRlbGF5KCkgaXMgdXNlZCwgdGhlIHJlc3Qgb2YgdGhlIGZ1bmN0
aW9uIHNlZW1zIHRvIGJlIHVzaW5nIHVkZWxheSgpLgpXaGF0J3MgdGhlIGRpZmZlcmVuY2UgYmV0
d2VlbiB0aGUgdHdvID8KRG9lcyBtZGVsYXkoKSByZWxpZXMgb24gc29tZSBmb3JtIG9mIHRpbWVy
IHRvIGV4ZWN1dGUgPwoKLS0gCkp1bGlhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:51:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14:51:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkzWe-00059m-94; Wed, 11 Jan 2012 14:51:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1RkzWd-00059N-9l
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:51:39 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326293491!8716048!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13739 invoked from network); 11 Jan 2012 14:51:32 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 14:51:32 -0000
Received: by obbwd20 with SMTP id wd20so2966499obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 06:51:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type
	:content-transfer-encoding;
	bh=Emd4CIPS34x3S5tV5NoU6NF1yzEpDVdOkPR1CZ2/A/0=;
	b=Y8Kh2KXVHJm5OT9j3LhlMg2VEso1xpq4FaTczmYkBYjIQT1IB3lZszV/Ag2jPHo2Or
	tyzYjsDI/7L20rVazIzG3a/L7yKC3ycGM5yRWq1QX1UqgnRhm5kCageBCqR7Vp4vdWFN
	yShw0vWZ+izlKnbBfTidubUS44LO/hTI1+fmY=
Received: by 10.182.59.41 with SMTP id w9mr22596958obq.70.1326293491209; Wed,
	11 Jan 2012 06:51:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.22.163 with HTTP; Wed, 11 Jan 2012 06:51:10 -0800 (PST)
In-Reply-To: <CB333F08.28854%keir.xen@gmail.com>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
	<CB333F08.28854%keir.xen@gmail.com>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 11 Jan 2012 14:51:10 +0000
X-Google-Sender-Auth: rvjjdqX-xrATWXc0GbyMV3UJVyw
Message-ID: <CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
	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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBKYW4gMTEsIDIwMTIgYXQgMToyOCBQTSwgS2VpciBGcmFzZXIgPGtlaXIueGVuQGdt
YWlsLmNvbT4gd3JvdGU6Cj4gT24gMTEvMDEvMjAxMiAxMzowNiwgIkp1bGlhbiBQaWRhbmNldCIg
PGp1bGlhbi5waWRhbmNldEBnbWFpbC5jb20+IHdyb3RlOgo+Cj4+IEhpLAo+Pgo+PiBXaGVuIHRy
eWluZyB0byBib290IHhlbiA0LjEgb24gbmV3IGhhcmR3YXJlLCBYZW4gYmVjb21lIHN0dWNrIGlu
Cj4+IHdha2V1cF9zZWNvbmRhcnlfY3B1KCkgaW4gdGhlIG1kZWxheSBmdW5jdGlvbi4KPj4KPj4g
wqAgwqAgRHByaW50aygiV2FpdGluZyBmb3Igc2VuZCB0byBmaW5pc2guLi5cbiIpOwo+PiDCoCDC
oCB0aW1lb3V0ID0gMDsKPj4gwqAgwqAgZG8gewo+PiDCoCDCoCDCoCDCoCBEcHJpbnRrKCIrIik7
Cj4+IMKgIMKgIMKgIMKgIHVkZWxheSgxMDApOwo+PiDCoCDCoCDCoCDCoCBpZiAoICF4MmFwaWNf
ZW5hYmxlZCApCj4+IMKgIMKgIMKgIMKgIMKgIMKgIHNlbmRfc3RhdHVzID0gYXBpY19yZWFkKEFQ
SUNfSUNSKSAmIEFQSUNfSUNSX0JVU1k7Cj4+IMKgIMKgIH0gd2hpbGUgKCBzZW5kX3N0YXR1cyAm
JiAodGltZW91dCsrIDwgMTAwMCkgKTsKPj4KPj4gwqAgwqAgcHJpbnRrKCJiZWZvcmUgbWRlbGF5
XG4iKTsKPj4gwqAgwqAgbWRlbGF5KDEwKTsKPj4gwqAgwqAgcHJpbnRrKCJhZnRlciBtZGVsYXlc
biIpOwo+Pgo+PiDCoCDCoCBEcHJpbnRrKCJEZWFzc2VydGluZyBJTklULlxuIik7Cj4+Cj4+IFRo
ZSBoYW5nIGNhbiBoYXBwZW4gcmFuZG9tbHkgd2l0aCBhbnkgb2YgdGhlIENQVXMgdG8gd2FrZSB1
cCBhbmQKPj4gc29tZXRpbWUgZG9lc24ndCBoYXBwZW4gYXQgYWxsLgo+PiBSZXBsYWNpbmcgbWRl
bGF5KDEwKSB3aXRoIHVkZWxheSgxMCkgc2VlbXMgdG8gZml4IHRoZSBpc3N1ZS4KPgo+IERvIHlv
dSBzZWUgdGhpcyBpbiB4ZW4tdW5zdGFibGU/IEhvcGVmdWxseSBpdCBpcyB3b3JraW5nIHRoZXJl
LCBhbmQgd2UgY2FuCj4gc2ltcGx5IGJhY2twb3J0IHRoZSBmaXguCj4KCkkgY2hlY2tlZCB5ZXN0
ZXJkYXkgYW5kIHRoZSBjb2RlIG9mIHRoaXMgZnVuY3Rpb24gaXMgdGhlIHNhbWUgaW4KeGVuLXVu
c3RhYmxlLCBidXQgSSBkb24ndCBlbmNvdW50ZXIgdGhlIHByb2JsZW0gd2l0aCB4ZW4tdW5zdGFi
bGUuCgpXaGF0IGNvbmNlcm5zIG1lIGlzIHRoYXQgdGhpcyBpcyB0aGUgb25seSBwbGFjZSBpbiB0
aGUgZnVuY3Rpb24gd2hlcmUKbWRlbGF5KCkgaXMgdXNlZCwgdGhlIHJlc3Qgb2YgdGhlIGZ1bmN0
aW9uIHNlZW1zIHRvIGJlIHVzaW5nIHVkZWxheSgpLgpXaGF0J3MgdGhlIGRpZmZlcmVuY2UgYmV0
d2VlbiB0aGUgdHdvID8KRG9lcyBtZGVsYXkoKSByZWxpZXMgb24gc29tZSBmb3JtIG9mIHRpbWVy
IHRvIGV4ZWN1dGUgPwoKLS0gCkp1bGlhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:53:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14:53:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkzYA-0005GE-PI; Wed, 11 Jan 2012 14:53:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1RkzY9-0005G4-Sc
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:53:14 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326293552!59796451!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18357 invoked from network); 11 Jan 2012 14:52:32 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 14:52: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 q0BErBdZ018474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 09:53:11 -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 q0BErBkH027303
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 09:53:11 -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 q0BErA06013890
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 09:53:10 -0500
Message-ID: <4F0DA255.2030703@redhat.com>
Date: Wed, 11 Jan 2012 15:53:09 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
In-Reply-To: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/11/2012 02:06 PM, Julian Pidancet wrote:
> Hi,
>
> When trying to boot xen 4.1 on new hardware, Xen become stuck in
> wakeup_secondary_cpu() in the mdelay function.
>
>      Dprintk("Waiting for send to finish...\n");
>      timeout = 0;
>      do {
>          Dprintk("+");
>          udelay(100);
>          if ( !x2apic_enabled )
>              send_status = apic_read(APIC_ICR)&  APIC_ICR_BUSY;
>      } while ( send_status&&  (timeout++<  1000) );
>
>      printk("before mdelay\n");
>      mdelay(10);
>      printk("after mdelay\n");
>
>      Dprintk("Deasserting INIT.\n");
>
> The hang can happen randomly with any of the CPUs to wake up and
> sometime doesn't happen at all.
> Replacing mdelay(10) with udelay(10) seems to fix the issue.
>

Essentially the same issue, check out
   http://article.gmane.org/gmane.comp.emulators.xen.devel/114776/match=ivy+bridge

Problem is that udelay uses 32 bit value from tsc for measuring
elapsed time and at early boot stage something steals
(most likely SMI) boot cpu with a following wrapping of tsc value
in udelay. And in case of mdelay this happens multiple times.
Replacing mdelay with udelay or removing it helps but it may
break boot on other hardware.
I suspect it's a BIOS issue.

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:53:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14:53:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkzYA-0005GE-PI; Wed, 11 Jan 2012 14:53:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1RkzY9-0005G4-Sc
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:53:14 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326293552!59796451!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18357 invoked from network); 11 Jan 2012 14:52:32 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 14:52: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 q0BErBdZ018474
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 09:53:11 -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 q0BErBkH027303
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 09:53:11 -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 q0BErA06013890
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 09:53:10 -0500
Message-ID: <4F0DA255.2030703@redhat.com>
Date: Wed, 11 Jan 2012 15:53:09 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
In-Reply-To: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/11/2012 02:06 PM, Julian Pidancet wrote:
> Hi,
>
> When trying to boot xen 4.1 on new hardware, Xen become stuck in
> wakeup_secondary_cpu() in the mdelay function.
>
>      Dprintk("Waiting for send to finish...\n");
>      timeout = 0;
>      do {
>          Dprintk("+");
>          udelay(100);
>          if ( !x2apic_enabled )
>              send_status = apic_read(APIC_ICR)&  APIC_ICR_BUSY;
>      } while ( send_status&&  (timeout++<  1000) );
>
>      printk("before mdelay\n");
>      mdelay(10);
>      printk("after mdelay\n");
>
>      Dprintk("Deasserting INIT.\n");
>
> The hang can happen randomly with any of the CPUs to wake up and
> sometime doesn't happen at all.
> Replacing mdelay(10) with udelay(10) seems to fix the issue.
>

Essentially the same issue, check out
   http://article.gmane.org/gmane.comp.emulators.xen.devel/114776/match=ivy+bridge

Problem is that udelay uses 32 bit value from tsc for measuring
elapsed time and at early boot stage something steals
(most likely SMI) boot cpu with a following wrapping of tsc value
in udelay. And in case of mdelay this happens multiple times.
Replacing mdelay with udelay or removing it helps but it may
break boot on other hardware.
I suspect it's a BIOS issue.

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:56:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkzbM-0005Sg-Cx; Wed, 11 Jan 2012 14:56: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 1RkzbK-0005SA-Je
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:56:30 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326293783!10614614!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTcyNzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30553 invoked from network); 11 Jan 2012 14:56:24 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 14:56:24 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 51E0845807C;
	Wed, 11 Jan 2012 06:56: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=NIIJjhoKfwEL1FsUIpGdcMPjvDztpLbzlkFqEG2WohDF
	ElyEqqqgGdBOVicvBg9V/S2dUyXYYUTbC1jPjqPmfTsXUewwfI8bL7RaUmwFYxu8
	O+GvsR05kNE1aY3F8U/k0dKOur9um90Zj4sBIr1wVJuzsrwIhzeJIDXj8pszapc=
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=5jvU122dTfmV66v+hLdjaf5mOm0=; b=XaD3Rzow
	y/+amhHO9gBnorMzhVQ4QSRjdQPwl9LbhJGH1wNxgzHkcfaA4dEs+Fa5DHlbHywt
	nQYeBKR2i4mdrc0izsI8FRDXrbnMO5KtW3WMozdTcReHIauj4qqaaAAMgAA4oOvh
	rz7QpHO0oIcRYfBnie0wyS/nRSYvu8+4SUY=
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 DD55545807B; 
	Wed, 11 Jan 2012 06:56:22 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 11 Jan 2012 06:57:21 -0800
Message-ID: <d3c062de69d4de2a251193814609365c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <000a01ccd034$f7037ee0$e50a7ca0$@com>
References: <patchbomb.1326145285@xdev.gridcentric.ca>
	<f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
	<000a01ccd034$f7037ee0$e50a7ca0$@com>
Date: Wed, 11 Jan 2012 06:57:21 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Hongkaixing" <hongkaixing@huawei.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, xen-devel@lists.xensource.com,
	andres@gridcentric.ca, yanqiangjun@huawei.com, tim@xen.org,
	bicky.shi@huawei.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
 p2m_ram_paged_out state to be loaded
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 think top-posting is frowned upon. Below...
>     I think it may have many unpredicted risks.
>     After p2mt is changed to p2m_ram_rw, Domain guest can access this page
> unrestrictedly without being trapped in xen.
>  But at this time, the page is not prepared.

Nope. The page has already been allocated and paged-in (copy_from_user out
of user_ptr) by the time the p2mt is changed

Andres
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres
>> Lagar-Cavilla
>> Sent: Tuesday, January 10, 2012 5:41 AM
>> To: xen-devel@lists.xensource.com
>> Cc: andres@gridcentric.ca; tim@xen.org; olaf@aepfle.de;
>> adin@gridcentric.ca
>> Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
>> p2m_ram_paged_out state to be loaded
>>
>>  xen/arch/x86/mm/p2m.c |  15 +++++++++++----
>>  1 files changed, 11 insertions(+), 4 deletions(-)
>>
>>
>> This removes the need for a page to be accessed in order to be pageable
>> again. A pager can now page-in pages at will with no need to map them
>> in a separate thread.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Acked-by: Tim Deegan <tim@xen.org>
>>
>> diff -r 90f764bf02c3 -r f7c330d5b4b5 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -964,7 +964,7 @@ void p2m_mem_paging_populate(struct doma
>>  int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t
>> buffer)
>>  {
>>      struct page_info *page;
>> -    p2m_type_t p2mt;
>> +    p2m_type_t p2mt, target_p2mt;
>>      p2m_access_t a;
>>      mfn_t mfn;
>>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> @@ -982,8 +982,8 @@ int p2m_mem_paging_prep(struct domain *d
>>      mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
>>
>>      ret = -ENOENT;
>> -    /* Allow only missing pages */
>> -    if ( p2mt != p2m_ram_paging_in_start )
>> +    /* Allow missing pages */
>> +    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
>>          goto out;
>>
>>      /* Allocate a page if the gfn does not have one yet */
>> @@ -1018,8 +1018,15 @@ int p2m_mem_paging_prep(struct domain *d
>>          }
>>      }
>>
>> +    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
>> +        /* If we kicked the pager with a populate event, the pager will
>> send
>> +         * a resume event back */
>> +        p2m_ram_paging_in :
>> +        /* If this was called asynchronously by the pager, then we can
>> +         * transition directly to the final guest-accessible type */
>> +        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
>>      /* Fix p2m mapping */
>> -    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
>> +    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
>>
>>      atomic_dec(&d->paged_pages);
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/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 Jan 11 14:56:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14:56:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkzbM-0005Sg-Cx; Wed, 11 Jan 2012 14:56: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 1RkzbK-0005SA-Je
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:56:30 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326293783!10614614!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTcyNzA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30553 invoked from network); 11 Jan 2012 14:56:24 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 14:56:24 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 51E0845807C;
	Wed, 11 Jan 2012 06:56: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=NIIJjhoKfwEL1FsUIpGdcMPjvDztpLbzlkFqEG2WohDF
	ElyEqqqgGdBOVicvBg9V/S2dUyXYYUTbC1jPjqPmfTsXUewwfI8bL7RaUmwFYxu8
	O+GvsR05kNE1aY3F8U/k0dKOur9um90Zj4sBIr1wVJuzsrwIhzeJIDXj8pszapc=
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=5jvU122dTfmV66v+hLdjaf5mOm0=; b=XaD3Rzow
	y/+amhHO9gBnorMzhVQ4QSRjdQPwl9LbhJGH1wNxgzHkcfaA4dEs+Fa5DHlbHywt
	nQYeBKR2i4mdrc0izsI8FRDXrbnMO5KtW3WMozdTcReHIauj4qqaaAAMgAA4oOvh
	rz7QpHO0oIcRYfBnie0wyS/nRSYvu8+4SUY=
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 DD55545807B; 
	Wed, 11 Jan 2012 06:56:22 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 11 Jan 2012 06:57:21 -0800
Message-ID: <d3c062de69d4de2a251193814609365c.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <000a01ccd034$f7037ee0$e50a7ca0$@com>
References: <patchbomb.1326145285@xdev.gridcentric.ca>
	<f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
	<000a01ccd034$f7037ee0$e50a7ca0$@com>
Date: Wed, 11 Jan 2012 06:57:21 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Hongkaixing" <hongkaixing@huawei.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, xen-devel@lists.xensource.com,
	andres@gridcentric.ca, yanqiangjun@huawei.com, tim@xen.org,
	bicky.shi@huawei.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
 p2m_ram_paged_out state to be loaded
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 think top-posting is frowned upon. Below...
>     I think it may have many unpredicted risks.
>     After p2mt is changed to p2m_ram_rw, Domain guest can access this page
> unrestrictedly without being trapped in xen.
>  But at this time, the page is not prepared.

Nope. The page has already been allocated and paged-in (copy_from_user out
of user_ptr) by the time the p2mt is changed

Andres
>
>> -----Original Message-----
>> From: xen-devel-bounces@lists.xensource.com
>> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres
>> Lagar-Cavilla
>> Sent: Tuesday, January 10, 2012 5:41 AM
>> To: xen-devel@lists.xensource.com
>> Cc: andres@gridcentric.ca; tim@xen.org; olaf@aepfle.de;
>> adin@gridcentric.ca
>> Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
>> p2m_ram_paged_out state to be loaded
>>
>>  xen/arch/x86/mm/p2m.c |  15 +++++++++++----
>>  1 files changed, 11 insertions(+), 4 deletions(-)
>>
>>
>> This removes the need for a page to be accessed in order to be pageable
>> again. A pager can now page-in pages at will with no need to map them
>> in a separate thread.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Acked-by: Tim Deegan <tim@xen.org>
>>
>> diff -r 90f764bf02c3 -r f7c330d5b4b5 xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -964,7 +964,7 @@ void p2m_mem_paging_populate(struct doma
>>  int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t
>> buffer)
>>  {
>>      struct page_info *page;
>> -    p2m_type_t p2mt;
>> +    p2m_type_t p2mt, target_p2mt;
>>      p2m_access_t a;
>>      mfn_t mfn;
>>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> @@ -982,8 +982,8 @@ int p2m_mem_paging_prep(struct domain *d
>>      mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
>>
>>      ret = -ENOENT;
>> -    /* Allow only missing pages */
>> -    if ( p2mt != p2m_ram_paging_in_start )
>> +    /* Allow missing pages */
>> +    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
>>          goto out;
>>
>>      /* Allocate a page if the gfn does not have one yet */
>> @@ -1018,8 +1018,15 @@ int p2m_mem_paging_prep(struct domain *d
>>          }
>>      }
>>
>> +    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
>> +        /* If we kicked the pager with a populate event, the pager will
>> send
>> +         * a resume event back */
>> +        p2m_ram_paging_in :
>> +        /* If this was called asynchronously by the pager, then we can
>> +         * transition directly to the final guest-accessible type */
>> +        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
>>      /* Fix p2m mapping */
>> -    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
>> +    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
>>
>>      atomic_dec(&d->paged_pages);
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/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 Jan 11 14:59:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkzdb-0005bQ-UP; Wed, 11 Jan 2012 14:58:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rkzda-0005bK-Dd
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:58:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326293907!52400723!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19653 invoked from network); 11 Jan 2012 14:58:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 11 Jan 2012 14:58:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326293927; l=3032;
	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=FhSUp6WidJu2XcptavRaTCzEH8U=;
	b=TGBlIesJO/LpUQ6Or7CgOfICUR0/Q5eTNH6e8hrhbZwoSQd7Tpgh3LY0bT555KBM2u9
	MLjC8gTxPqifYW9wezM5v5wOi9KxzosgFUF+HGWSmMgI16I4GMq747lZCe/vGFfemwvnS
	cTjjO/IUHZywXIKCyGBI7/yIZ7TwxfrGNow=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzAQEURr
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-113-021.pools.arcor-ip.net [88.65.113.21])
	by smtp.strato.de (klopstock mo63) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 200deeo0BEaMKN ;
	Wed, 11 Jan 2012 15:58:22 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D228818637; Wed, 11 Jan 2012 15:58:21 +0100 (CET)
Date: Wed, 11 Jan 2012 15:58:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <george.dunlap@citrix.com>
Message-ID: <20120111145821.GA28944@aepfle.de>
References: <ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326196936.5154.39.camel@elijah>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.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 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 10, George Dunlap wrote:

> On Mon, 2012-01-09 at 19:21 +0000, Olaf Hering wrote:
> > So there is that maxmem= setting to let the guest OS configure itself
> > for a given amount of pseudo-physical memory. Then there is a way to cut
> > down the guest OS memory usage, both with balloon driver in guest and
> > later with PoD.
> > Isnt paging a better (or: just different) way to control the memory
> > usage of a guest OS (It costs diskspace in dom0)?
> 
> On the contrary, hypervisor swapping is definitely *much worse* than
> using a balloon driver.  The balloon driver was an innovation developed
> specifically to avoid hypervisor swapping if at all possible[1].  We
> need hypervisor swapping as a back-stop for situations where the balloon
> driver is non-existent, or can't function immediately for some reason
> (e.g., we've been using page-sharing to do memory overcommit and
> suddenly have a bunch of pages un-shared); but it should always be a
> last resort, and would ideally be mitigated by the balloon driver as
> soon as possible.

Isnt that up to the host admin to decide where to take the memory from?
So if its acceptable to swap parts of a VM (independent from what the
guest OS thinks it has), so be it.

We just need to right knobs.

So far we have two knobs:
maxmem=  xl mem-max
memory=  xl mem-set  (and guest OS balloon driver via sysfs)

Another knob for paging is needed. A while ago you proposed two new
commands: mem-balloon_target and mem-swap_target. Perhaps these terms
should be used also in the config file to set the initial memory/target
and memory/target-tot_pages values. If the latter is set, start the
pager. And if the latter is called, start the pager if it doesnt run
already.

At some point we will have the code ready so that PoD and paging can
coexist, so that the guests memory usage can grow on guests demand as it
does now. This is just a detail, independent from config options and
commands.


To summarize:

maxmem=  ; xl mem-max
memory=  mem-balloon_target= ; xl mem-balloon_target, xl mem-set
mem-swap_target= ; xl mem-swap_target

The rule could be like this:
mem-swap_target <= mem-balloon_target <= mem-max


> > What if the config format is like this:
> > 
> > Do things as they were done until now (PoD + balloon driver):
> >   memory=3072
> >   maxmem=4096
> >   paging=0 (or not specified at all)
> > 
> > Do things with pager instead of balloon driver and/or PoD:
> >   memory=3072
> >   maxmem=4096
> >   paging=1, or xenpaging=1
> >   xenpaging_extra=[ '-f', '/path/to/pagefile_guestname' ] (optional)
> 
> Except that this makes paging and ballooning mutually exclusive.  What
> we want is to make them work together -- to have paging as a back-up
> when ballooning fails (or isn't fast enough).

ballooning in the guest will still work. For example via sysfs, the
guest driver can release pages any time it wants to. But with the above
knobs the balloon driver can still be tweaked from the host.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 14:59:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 14:59:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkzdb-0005bQ-UP; Wed, 11 Jan 2012 14:58:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rkzda-0005bK-Dd
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 14:58:50 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326293907!52400723!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19653 invoked from network); 11 Jan 2012 14:58:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-11.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 11 Jan 2012 14:58:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326293927; l=3032;
	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=FhSUp6WidJu2XcptavRaTCzEH8U=;
	b=TGBlIesJO/LpUQ6Or7CgOfICUR0/Q5eTNH6e8hrhbZwoSQd7Tpgh3LY0bT555KBM2u9
	MLjC8gTxPqifYW9wezM5v5wOi9KxzosgFUF+HGWSmMgI16I4GMq747lZCe/vGFfemwvnS
	cTjjO/IUHZywXIKCyGBI7/yIZ7TwxfrGNow=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzAQEURr
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-113-021.pools.arcor-ip.net [88.65.113.21])
	by smtp.strato.de (klopstock mo63) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 200deeo0BEaMKN ;
	Wed, 11 Jan 2012 15:58:22 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D228818637; Wed, 11 Jan 2012 15:58:21 +0100 (CET)
Date: Wed, 11 Jan 2012 15:58:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <george.dunlap@citrix.com>
Message-ID: <20120111145821.GA28944@aepfle.de>
References: <ab5406a5b1d01e3828f0.1320245140@probook.site>
	<alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326196936.5154.39.camel@elijah>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.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 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 10, George Dunlap wrote:

> On Mon, 2012-01-09 at 19:21 +0000, Olaf Hering wrote:
> > So there is that maxmem= setting to let the guest OS configure itself
> > for a given amount of pseudo-physical memory. Then there is a way to cut
> > down the guest OS memory usage, both with balloon driver in guest and
> > later with PoD.
> > Isnt paging a better (or: just different) way to control the memory
> > usage of a guest OS (It costs diskspace in dom0)?
> 
> On the contrary, hypervisor swapping is definitely *much worse* than
> using a balloon driver.  The balloon driver was an innovation developed
> specifically to avoid hypervisor swapping if at all possible[1].  We
> need hypervisor swapping as a back-stop for situations where the balloon
> driver is non-existent, or can't function immediately for some reason
> (e.g., we've been using page-sharing to do memory overcommit and
> suddenly have a bunch of pages un-shared); but it should always be a
> last resort, and would ideally be mitigated by the balloon driver as
> soon as possible.

Isnt that up to the host admin to decide where to take the memory from?
So if its acceptable to swap parts of a VM (independent from what the
guest OS thinks it has), so be it.

We just need to right knobs.

So far we have two knobs:
maxmem=  xl mem-max
memory=  xl mem-set  (and guest OS balloon driver via sysfs)

Another knob for paging is needed. A while ago you proposed two new
commands: mem-balloon_target and mem-swap_target. Perhaps these terms
should be used also in the config file to set the initial memory/target
and memory/target-tot_pages values. If the latter is set, start the
pager. And if the latter is called, start the pager if it doesnt run
already.

At some point we will have the code ready so that PoD and paging can
coexist, so that the guests memory usage can grow on guests demand as it
does now. This is just a detail, independent from config options and
commands.


To summarize:

maxmem=  ; xl mem-max
memory=  mem-balloon_target= ; xl mem-balloon_target, xl mem-set
mem-swap_target= ; xl mem-swap_target

The rule could be like this:
mem-swap_target <= mem-balloon_target <= mem-max


> > What if the config format is like this:
> > 
> > Do things as they were done until now (PoD + balloon driver):
> >   memory=3072
> >   maxmem=4096
> >   paging=0 (or not specified at all)
> > 
> > Do things with pager instead of balloon driver and/or PoD:
> >   memory=3072
> >   maxmem=4096
> >   paging=1, or xenpaging=1
> >   xenpaging_extra=[ '-f', '/path/to/pagefile_guestname' ] (optional)
> 
> Except that this makes paging and ballooning mutually exclusive.  What
> we want is to make them work together -- to have paging as a back-up
> when ballooning fails (or isn't fast enough).

ballooning in the guest will still work. For example via sysfs, the
guest driver can release pages any time it wants to. But with the above
knobs the balloon driver can still be tweaked from the host.


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:04:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkziY-0005su-U2; Wed, 11 Jan 2012 15:03:58 +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 1RkziX-0005sl-Pb
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:03:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326294230!10492820!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 6960 invoked from network); 11 Jan 2012 15:03:51 -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; 11 Jan 2012 15:03:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Jan 2012 15:03:49 +0000
Message-Id: <4F0DB31D020000780006BDB2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Jan 2012 15:04:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1326215226@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 00 of 14 V3] 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 10.01.12 at 18:07, Wei Wang <wei.wang2@amd.com> wrote:
> Hi all, this is patch v3.
> 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.

I would look into committing 1-6 and 10 (if that one is independent of
7-9), if you can confirm that those on their own provide meaningful
benefit (enabling the ppr log probably is what I'm after, but I'd still
like your confirmation - patch 3 in particular doesn't look very useful
without the later ones). So ideally the ones leading up to the ppr log
enabling would all be first (or even a separate series), and the guest
iommu ones would follow (as those make only sense when the tools
maintainers are okay with the changes too).

Jan

> changes in v3:
> * Use xenstore to receive guest iommu configuration instead of adding in a 
> new field in hvm_info_table.
> * Support pci segment in vbdf to mbdf bind.
> * Make hypercalls visible for non-x86 platforms.
> * A few code cleanups according to comments from Jan and Ian.
> 
> Changes in v2:
> * Do not use linked list to access guest iommu tables.
> * Do not parse iommu parameter in libxl_device_model_info again.
> * Fix incorrect logical calculation in patch 11.
> * Fix hypercall definition for non-x86 systems.
> 
> Thanks,
> Wei




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:04:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:04:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RkziY-0005su-U2; Wed, 11 Jan 2012 15:03:58 +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 1RkziX-0005sl-Pb
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:03:57 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326294230!10492820!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 6960 invoked from network); 11 Jan 2012 15:03:51 -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; 11 Jan 2012 15:03:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Jan 2012 15:03:49 +0000
Message-Id: <4F0DB31D020000780006BDB2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Jan 2012 15:04:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1326215226@gran.amd.com>
In-Reply-To: <patchbomb.1326215226@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 00 of 14 V3] 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 10.01.12 at 18:07, Wei Wang <wei.wang2@amd.com> wrote:
> Hi all, this is patch v3.
> 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.

I would look into committing 1-6 and 10 (if that one is independent of
7-9), if you can confirm that those on their own provide meaningful
benefit (enabling the ppr log probably is what I'm after, but I'd still
like your confirmation - patch 3 in particular doesn't look very useful
without the later ones). So ideally the ones leading up to the ppr log
enabling would all be first (or even a separate series), and the guest
iommu ones would follow (as those make only sense when the tools
maintainers are okay with the changes too).

Jan

> changes in v3:
> * Use xenstore to receive guest iommu configuration instead of adding in a 
> new field in hvm_info_table.
> * Support pci segment in vbdf to mbdf bind.
> * Make hypercalls visible for non-x86 platforms.
> * A few code cleanups according to comments from Jan and Ian.
> 
> Changes in v2:
> * Do not use linked list to access guest iommu tables.
> * Do not parse iommu parameter in libxl_device_model_info again.
> * Fix incorrect logical calculation in patch 11.
> * Fix hypercall definition for non-x86 systems.
> 
> Thanks,
> Wei




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkzpj-00065v-R8; Wed, 11 Jan 2012 15:11: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 1Rkzph-00065p-NW
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:11:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326294674!8686558!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 19941 invoked from network); 11 Jan 2012 15:11:15 -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; 11 Jan 2012 15:11:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Jan 2012 15:11:14 +0000
Message-Id: <4F0DB4D9020000780006BDC7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Jan 2012 15:12:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julian Pidancet" <julian.pidancet@gmail.com>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
	<CB333F08.28854%keir.xen@gmail.com>
	<CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
In-Reply-To: <CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
 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 11.01.12 at 15:51, Julian Pidancet <julian.pidancet@gmail.com> wrote:
> On Wed, Jan 11, 2012 at 1:28 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 11/01/2012 13:06, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> When trying to boot xen 4.1 on new hardware, Xen become stuck in
>>> wakeup_secondary_cpu() in the mdelay function.
>>>
>>>     Dprintk("Waiting for send to finish...\n");
>>>     timeout = 0;
>>>     do {
>>>         Dprintk("+");
>>>         udelay(100);
>>>         if ( !x2apic_enabled )
>>>             send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>>     } while ( send_status && (timeout++ < 1000) );
>>>
>>>     printk("before mdelay\n");
>>>     mdelay(10);
>>>     printk("after mdelay\n");
>>>
>>>     Dprintk("Deasserting INIT.\n");
>>>
>>> The hang can happen randomly with any of the CPUs to wake up and
>>> sometime doesn't happen at all.
>>> Replacing mdelay(10) with udelay(10) seems to fix the issue.
>>
>> Do you see this in xen-unstable? Hopefully it is working there, and we can
>> simply backport the fix.
>>
> 
> I checked yesterday and the code of this function is the same in
> xen-unstable,

Hardly.

> but I don't encounter the problem with xen-unstable.

Running in x2apic mode, perhaps? (Despite having been asked
already, you still didn't really provide technical details about your
systems. Nor did you care to attach a log of the successful
attempt with -unstable...)

> What concerns me is that this is the only place in the function where
> mdelay() is used, the rest of the function seems to be using udelay().
> What's the difference between the two ?

Quite obviously the former delays by a number of milliseconds,
while the value passed to the latter is in microseconds.

> Does mdelay() relies on some form of timer to execute ?

No. mdelay() is simply a loop around udelay() - see
xen/include/xen/delay.h.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rkzpj-00065v-R8; Wed, 11 Jan 2012 15:11: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 1Rkzph-00065p-NW
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:11:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326294674!8686558!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 19941 invoked from network); 11 Jan 2012 15:11:15 -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; 11 Jan 2012 15:11:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Jan 2012 15:11:14 +0000
Message-Id: <4F0DB4D9020000780006BDC7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Jan 2012 15:12:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julian Pidancet" <julian.pidancet@gmail.com>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
	<CB333F08.28854%keir.xen@gmail.com>
	<CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
In-Reply-To: <CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
 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 11.01.12 at 15:51, Julian Pidancet <julian.pidancet@gmail.com> wrote:
> On Wed, Jan 11, 2012 at 1:28 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 11/01/2012 13:06, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> When trying to boot xen 4.1 on new hardware, Xen become stuck in
>>> wakeup_secondary_cpu() in the mdelay function.
>>>
>>>     Dprintk("Waiting for send to finish...\n");
>>>     timeout = 0;
>>>     do {
>>>         Dprintk("+");
>>>         udelay(100);
>>>         if ( !x2apic_enabled )
>>>             send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>>     } while ( send_status && (timeout++ < 1000) );
>>>
>>>     printk("before mdelay\n");
>>>     mdelay(10);
>>>     printk("after mdelay\n");
>>>
>>>     Dprintk("Deasserting INIT.\n");
>>>
>>> The hang can happen randomly with any of the CPUs to wake up and
>>> sometime doesn't happen at all.
>>> Replacing mdelay(10) with udelay(10) seems to fix the issue.
>>
>> Do you see this in xen-unstable? Hopefully it is working there, and we can
>> simply backport the fix.
>>
> 
> I checked yesterday and the code of this function is the same in
> xen-unstable,

Hardly.

> but I don't encounter the problem with xen-unstable.

Running in x2apic mode, perhaps? (Despite having been asked
already, you still didn't really provide technical details about your
systems. Nor did you care to attach a log of the successful
attempt with -unstable...)

> What concerns me is that this is the only place in the function where
> mdelay() is used, the rest of the function seems to be using udelay().
> What's the difference between the two ?

Quite obviously the former delays by a number of milliseconds,
while the value passed to the latter is in microseconds.

> Does mdelay() relies on some form of timer to execute ?

No. mdelay() is simply a loop around udelay() - see
xen/include/xen/delay.h.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:28:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl05C-0006H0-Dv; Wed, 11 Jan 2012 15:27:22 +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 1Rl05B-0006Gv-IM
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:27:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326295635!10503252!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14047 invoked from network); 11 Jan 2012 15:27:15 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 15:27:15 -0000
Received: by wibhq7 with SMTP id hq7so1172649wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 07:27:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=x7U3yBSByxiRpK0/MvgKpTOWFy2mM9Jk5dENVY9mKpU=;
	b=a/Tia10WXojTt9jkO50ldxAFJqzAbJVcR/iWlHhQQbVXKZyS/AKqnDV4Np73iII7kc
	N4Ys21NFlOaJd3Q9v+PoabtIDit6IKTgh9jVtTfV8lnVoibQIszSMY+96qOs0Qa6GnuI
	STRl+PWOYGVEoqt71SIu/6p7qSdLrmFqajWR4=
Received: by 10.180.101.3 with SMTP id fc3mr20331569wib.22.1326295635123;
	Wed, 11 Jan 2012 07:27:15 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fy5sm3218747wib.7.2012.01.11.07.27.13
	(version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 07:27:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Jan 2012 15:27:10 +0000
From: Keir Fraser <keir@xen.org>
To: Julian Pidancet <julian.pidancet@gmail.com>
Message-ID: <CB335ACE.371D2%keir@xen.org>
Thread-Topic: [Xen-devel] Xen randomly stuck in mdelay() during MP
	initialization
Thread-Index: AczQdXwtrMNXYcsO2Ue9mzZZMkcOmg==
In-Reply-To: <CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
 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 11/01/2012 14:51, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:

> On Wed, Jan 11, 2012 at 1:28 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 11/01/2012 13:06, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
>> =

>>> Hi,
>>> =

>>> When trying to boot xen 4.1 on new hardware, Xen become stuck in
>>> wakeup_secondary_cpu() in the mdelay function.
>>> =

>>> =A0 =A0 Dprintk("Waiting for send to finish...\n");
>>> =A0 =A0 timeout =3D 0;
>>> =A0 =A0 do {
>>> =A0 =A0 =A0 =A0 Dprintk("+");
>>> =A0 =A0 =A0 =A0 udelay(100);
>>> =A0 =A0 =A0 =A0 if ( !x2apic_enabled )
>>> =A0 =A0 =A0 =A0 =A0 =A0 send_status =3D apic_read(APIC_ICR) & APIC_ICR_=
BUSY;
>>> =A0 =A0 } while ( send_status && (timeout++ < 1000) );
>>> =

>>> =A0 =A0 printk("before mdelay\n");
>>> =A0 =A0 mdelay(10);
>>> =A0 =A0 printk("after mdelay\n");
>>> =

>>> =A0 =A0 Dprintk("Deasserting INIT.\n");
>>> =

>>> The hang can happen randomly with any of the CPUs to wake up and
>>> sometime doesn't happen at all.
>>> Replacing mdelay(10) with udelay(10) seems to fix the issue.
>> =

>> Do you see this in xen-unstable? Hopefully it is working there, and we c=
an
>> simply backport the fix.
>> =

> =

> I checked yesterday and the code of this function is the same in
> xen-unstable, but I don't encounter the problem with xen-unstable.

Well that would be because the code of this function is not the same in
xen-4.1 and xen-unstable.

> What concerns me is that this is the only place in the function where
> mdelay() is used, the rest of the function seems to be using udelay().
> What's the difference between the two ?
> Does mdelay() relies on some form of timer to execute ?

mdelay(ms) just calls udelay(1000) ms times.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:28:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl05C-0006H0-Dv; Wed, 11 Jan 2012 15:27:22 +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 1Rl05B-0006Gv-IM
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:27:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326295635!10503252!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14047 invoked from network); 11 Jan 2012 15:27:15 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 15:27:15 -0000
Received: by wibhq7 with SMTP id hq7so1172649wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 07:27:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=x7U3yBSByxiRpK0/MvgKpTOWFy2mM9Jk5dENVY9mKpU=;
	b=a/Tia10WXojTt9jkO50ldxAFJqzAbJVcR/iWlHhQQbVXKZyS/AKqnDV4Np73iII7kc
	N4Ys21NFlOaJd3Q9v+PoabtIDit6IKTgh9jVtTfV8lnVoibQIszSMY+96qOs0Qa6GnuI
	STRl+PWOYGVEoqt71SIu/6p7qSdLrmFqajWR4=
Received: by 10.180.101.3 with SMTP id fc3mr20331569wib.22.1326295635123;
	Wed, 11 Jan 2012 07:27:15 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fy5sm3218747wib.7.2012.01.11.07.27.13
	(version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 07:27:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Jan 2012 15:27:10 +0000
From: Keir Fraser <keir@xen.org>
To: Julian Pidancet <julian.pidancet@gmail.com>
Message-ID: <CB335ACE.371D2%keir@xen.org>
Thread-Topic: [Xen-devel] Xen randomly stuck in mdelay() during MP
	initialization
Thread-Index: AczQdXwtrMNXYcsO2Ue9mzZZMkcOmg==
In-Reply-To: <CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
 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 11/01/2012 14:51, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:

> On Wed, Jan 11, 2012 at 1:28 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 11/01/2012 13:06, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
>> =

>>> Hi,
>>> =

>>> When trying to boot xen 4.1 on new hardware, Xen become stuck in
>>> wakeup_secondary_cpu() in the mdelay function.
>>> =

>>> =A0 =A0 Dprintk("Waiting for send to finish...\n");
>>> =A0 =A0 timeout =3D 0;
>>> =A0 =A0 do {
>>> =A0 =A0 =A0 =A0 Dprintk("+");
>>> =A0 =A0 =A0 =A0 udelay(100);
>>> =A0 =A0 =A0 =A0 if ( !x2apic_enabled )
>>> =A0 =A0 =A0 =A0 =A0 =A0 send_status =3D apic_read(APIC_ICR) & APIC_ICR_=
BUSY;
>>> =A0 =A0 } while ( send_status && (timeout++ < 1000) );
>>> =

>>> =A0 =A0 printk("before mdelay\n");
>>> =A0 =A0 mdelay(10);
>>> =A0 =A0 printk("after mdelay\n");
>>> =

>>> =A0 =A0 Dprintk("Deasserting INIT.\n");
>>> =

>>> The hang can happen randomly with any of the CPUs to wake up and
>>> sometime doesn't happen at all.
>>> Replacing mdelay(10) with udelay(10) seems to fix the issue.
>> =

>> Do you see this in xen-unstable? Hopefully it is working there, and we c=
an
>> simply backport the fix.
>> =

> =

> I checked yesterday and the code of this function is the same in
> xen-unstable, but I don't encounter the problem with xen-unstable.

Well that would be because the code of this function is not the same in
xen-4.1 and xen-unstable.

> What concerns me is that this is the only place in the function where
> mdelay() is used, the rest of the function seems to be using udelay().
> What's the difference between the two ?
> Does mdelay() relies on some form of timer to execute ?

mdelay(ms) just calls udelay(1000) ms times.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:28:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl06S-0006Kr-T6; Wed, 11 Jan 2012 15:28:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1Rl06R-0006KO-4e
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:28:39 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326295711!8688195!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7178 invoked from network); 11 Jan 2012 15:28:32 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 15:28:32 -0000
Received: by obbwd20 with SMTP id wd20so3039570obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 07:28: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=VqzTSJYDc5m75cDH/19UmeirZbtsiA/Mdvcns+BKwco=;
	b=WvJVxKYQi66s2Kadj1nZzi8EQ6XiqKpJ6mqiRRaI35EuPxoQKUSJxB1NZtFIHNmYLx
	BW2iC4KMUEUYo30HsDRbBxivP3ZVGeybfoI4lnidpnDx5VHn6GCjhOIBSWPYRz4SFLoH
	M2Fva2/a6JxoqG9RWG8seYCIogkM9Y3lsuK7g=
Received: by 10.182.15.104 with SMTP id w8mr14933047obc.20.1326295711189; Wed,
	11 Jan 2012 07:28:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.22.163 with HTTP; Wed, 11 Jan 2012 07:28:10 -0800 (PST)
In-Reply-To: <4F0DB4D9020000780006BDC7@nat28.tlf.novell.com>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
	<CB333F08.28854%keir.xen@gmail.com>
	<CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
	<4F0DB4D9020000780006BDC7@nat28.tlf.novell.com>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 11 Jan 2012 15:28:10 +0000
X-Google-Sender-Auth: HjL7IUfg4aWJNEonm0fampPPTvk
Message-ID: <CAKZ=5EXjQbRcegXERM7FVv2aW75NS7-coO3bxmUu-6FR57aNNQ@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
	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 Wed, Jan 11, 2012 at 3:12 PM, Jan Beulich <JBeulich@suse.com> wrote:
>
> Hardly.
>
>> but I don't encounter the problem with xen-unstable.
>
> Running in x2apic mode, perhaps? (Despite having been asked
> already, you still didn't really provide technical details about your
> systems. Nor did you care to attach a log of the successful
> attempt with -unstable...)
>

Yes, disabling x2apic fixes the issue, thank you.
Is x2apic disabled by default on xen-unstable ? It could explain why
it doesn't hang with it.

>> Does mdelay() relies on some form of timer to execute ?
>
> No. mdelay() is simply a loop around udelay() - see
> xen/include/xen/delay.h.
>

Yes, that was quite a stupid question from me, what it does is pretty
obvious by looking at the code.

-- 
Julian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:28:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl06S-0006Kr-T6; Wed, 11 Jan 2012 15:28:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <swaplinker@gmail.com>) id 1Rl06R-0006KO-4e
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:28:39 +0000
X-Env-Sender: swaplinker@gmail.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326295711!8688195!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7178 invoked from network); 11 Jan 2012 15:28:32 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 15:28:32 -0000
Received: by obbwd20 with SMTP id wd20so3039570obb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 07:28: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=VqzTSJYDc5m75cDH/19UmeirZbtsiA/Mdvcns+BKwco=;
	b=WvJVxKYQi66s2Kadj1nZzi8EQ6XiqKpJ6mqiRRaI35EuPxoQKUSJxB1NZtFIHNmYLx
	BW2iC4KMUEUYo30HsDRbBxivP3ZVGeybfoI4lnidpnDx5VHn6GCjhOIBSWPYRz4SFLoH
	M2Fva2/a6JxoqG9RWG8seYCIogkM9Y3lsuK7g=
Received: by 10.182.15.104 with SMTP id w8mr14933047obc.20.1326295711189; Wed,
	11 Jan 2012 07:28:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.22.163 with HTTP; Wed, 11 Jan 2012 07:28:10 -0800 (PST)
In-Reply-To: <4F0DB4D9020000780006BDC7@nat28.tlf.novell.com>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
	<CB333F08.28854%keir.xen@gmail.com>
	<CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
	<4F0DB4D9020000780006BDC7@nat28.tlf.novell.com>
From: Julian Pidancet <julian.pidancet@gmail.com>
Date: Wed, 11 Jan 2012 15:28:10 +0000
X-Google-Sender-Auth: HjL7IUfg4aWJNEonm0fampPPTvk
Message-ID: <CAKZ=5EXjQbRcegXERM7FVv2aW75NS7-coO3bxmUu-6FR57aNNQ@mail.gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
	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 Wed, Jan 11, 2012 at 3:12 PM, Jan Beulich <JBeulich@suse.com> wrote:
>
> Hardly.
>
>> but I don't encounter the problem with xen-unstable.
>
> Running in x2apic mode, perhaps? (Despite having been asked
> already, you still didn't really provide technical details about your
> systems. Nor did you care to attach a log of the successful
> attempt with -unstable...)
>

Yes, disabling x2apic fixes the issue, thank you.
Is x2apic disabled by default on xen-unstable ? It could explain why
it doesn't hang with it.

>> Does mdelay() relies on some form of timer to execute ?
>
> No. mdelay() is simply a loop around udelay() - see
> xen/include/xen/delay.h.
>

Yes, that was quite a stupid question from me, what it does is pretty
obvious by looking at the code.

-- 
Julian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:30:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15: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 1Rl07X-0006Qz-BT; Wed, 11 Jan 2012 15:29:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo@elte.hu>) id 1Rl07V-0006QF-Dp
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:29:45 +0000
X-Env-Sender: mingo@elte.hu
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326295778!10473309!1
X-Originating-IP: [157.181.1.138]
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 25744 invoked from network); 11 Jan 2012 15:29:39 -0000
Received: from mx3.mail.elte.hu (HELO mx3.mail.elte.hu) (157.181.1.138)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 15:29:39 -0000
Received: from elvis.elte.hu ([157.181.1.14])
	by mx3.mail.elte.hu with esmtp (Exim) id 1Rl06x-0004wM-Eq
	from <mingo@elte.hu>; Wed, 11 Jan 2012 16:29:28 +0100
Received: by elvis.elte.hu (Postfix, from userid 1004)
	id 8B1113E25BF; Wed, 11 Jan 2012 16:29:00 +0100 (CET)
Date: Wed, 11 Jan 2012 16:29:05 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Message-ID: <20120111152905.GA26659@elte.hu>
References: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
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: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] linux-next: manual merge of the xen tree with
	Linus' 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

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/xen/Kconfig between commit 10fe570fc167 ("Revert "xen/debug:
> WARN_ON when identity PFN has no _PAGE_IOMAP flag set."") from Linus'
> tree and commit 23757fb5d678 ("xen: add CPU microcode update driver")
> from the xen tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/x86/xen/Kconfig
> index fdce49c,4d04d4f..0000000
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@@ -50,3 -50,14 +50,6 @@@ config XEN_DEBUG_F
>   	  Enable statistics output and various tuning options in debugfs.
>   	  Enabling this option may incur a significant performance overhead.
>   
>  -config XEN_DEBUG
>  -	bool "Enable Xen debug checks"
>  -	depends on XEN
>  -	default n
>  -	help
>  -	  Enable various WARN_ON checks in the Xen MMU code.
>  -	  Enabling this option WILL incur a significant performance overhead.
>  -
> + config MICROCODE_XEN
> +        def_bool y
> +        depends on XEN_DOM0 && MICROCODE

Jeremy, Konrad, the current Xen microcode crap was objected to 
early last year by the people developing the x86 microcode 
subsystem - still you have put it into the Xen tree, without 
even Cc:-ing the people involved!

To make it even clearer, because you don't seem to be able to 
follow the proper upstream workflow unless forced to:

 NAKed-By: Ingo Molnar <mingo@elte.hu>

Please remove it from the Xen tree until the proper agreeement 
is reached.

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:30:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15: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 1Rl07X-0006Qz-BT; Wed, 11 Jan 2012 15:29:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mingo@elte.hu>) id 1Rl07V-0006QF-Dp
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:29:45 +0000
X-Env-Sender: mingo@elte.hu
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326295778!10473309!1
X-Originating-IP: [157.181.1.138]
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 25744 invoked from network); 11 Jan 2012 15:29:39 -0000
Received: from mx3.mail.elte.hu (HELO mx3.mail.elte.hu) (157.181.1.138)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 15:29:39 -0000
Received: from elvis.elte.hu ([157.181.1.14])
	by mx3.mail.elte.hu with esmtp (Exim) id 1Rl06x-0004wM-Eq
	from <mingo@elte.hu>; Wed, 11 Jan 2012 16:29:28 +0100
Received: by elvis.elte.hu (Postfix, from userid 1004)
	id 8B1113E25BF; Wed, 11 Jan 2012 16:29:00 +0100 (CET)
Date: Wed, 11 Jan 2012 16:29:05 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Message-ID: <20120111152905.GA26659@elte.hu>
References: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
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: Jeremy Fitzhardinge <jeremy@goop.org>,
	Xen Devel <Xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
	Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Xen-devel] linux-next: manual merge of the xen tree with
	Linus' 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

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/xen/Kconfig between commit 10fe570fc167 ("Revert "xen/debug:
> WARN_ON when identity PFN has no _PAGE_IOMAP flag set."") from Linus'
> tree and commit 23757fb5d678 ("xen: add CPU microcode update driver")
> from the xen tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc arch/x86/xen/Kconfig
> index fdce49c,4d04d4f..0000000
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@@ -50,3 -50,14 +50,6 @@@ config XEN_DEBUG_F
>   	  Enable statistics output and various tuning options in debugfs.
>   	  Enabling this option may incur a significant performance overhead.
>   
>  -config XEN_DEBUG
>  -	bool "Enable Xen debug checks"
>  -	depends on XEN
>  -	default n
>  -	help
>  -	  Enable various WARN_ON checks in the Xen MMU code.
>  -	  Enabling this option WILL incur a significant performance overhead.
>  -
> + config MICROCODE_XEN
> +        def_bool y
> +        depends on XEN_DOM0 && MICROCODE

Jeremy, Konrad, the current Xen microcode crap was objected to 
early last year by the people developing the x86 microcode 
subsystem - still you have put it into the Xen tree, without 
even Cc:-ing the people involved!

To make it even clearer, because you don't seem to be able to 
follow the proper upstream workflow unless forced to:

 NAKed-By: Ingo Molnar <mingo@elte.hu>

Please remove it from the Xen tree until the proper agreeement 
is reached.

Thanks,

	Ingo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:35:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15: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 1Rl0CN-0006k5-3Q; Wed, 11 Jan 2012 15:34:47 +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 1Rl0CK-0006ju-NT
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:34:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326296077!10485575!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 5403 invoked from network); 11 Jan 2012 15:34:38 -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; 11 Jan 2012 15:34:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Jan 2012 15:34:37 +0000
Message-Id: <4F0DBA52020000780006BDF6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Jan 2012 15:35:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julian Pidancet" <julian.pidancet@gmail.com>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
	<CB333F08.28854%keir.xen@gmail.com>
	<CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
	<4F0DB4D9020000780006BDC7@nat28.tlf.novell.com>
	<CAKZ=5EXjQbRcegXERM7FVv2aW75NS7-coO3bxmUu-6FR57aNNQ@mail.gmail.com>
In-Reply-To: <CAKZ=5EXjQbRcegXERM7FVv2aW75NS7-coO3bxmUu-6FR57aNNQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
 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 11.01.12 at 16:28, Julian Pidancet <julian.pidancet@gmail.com> wrote:
> On Wed, Jan 11, 2012 at 3:12 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>> Hardly.
>>
>>> but I don't encounter the problem with xen-unstable.
>>
>> Running in x2apic mode, perhaps? (Despite having been asked
>> already, you still didn't really provide technical details about your
>> systems. Nor did you care to attach a log of the successful
>> attempt with -unstable...)
>>
> 
> Yes, disabling x2apic fixes the issue, thank you.
> Is x2apic disabled by default on xen-unstable ? It could explain why
> it doesn't hang with it.

No, it's enabled by default. But AP bringup was changed for the
x2apic case some time ago (which was the reason for my "Hardly"
above).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:35:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15: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 1Rl0CN-0006k5-3Q; Wed, 11 Jan 2012 15:34:47 +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 1Rl0CK-0006ju-NT
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:34:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326296077!10485575!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 5403 invoked from network); 11 Jan 2012 15:34:38 -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; 11 Jan 2012 15:34:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 11 Jan 2012 15:34:37 +0000
Message-Id: <4F0DBA52020000780006BDF6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 11 Jan 2012 15:35:30 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Julian Pidancet" <julian.pidancet@gmail.com>
References: <CAKZ=5EUEYzopp7yOTm839ZVW3QVxRwQJDmoNr3Xc_DoBjpZP2w@mail.gmail.com>
	<CB333F08.28854%keir.xen@gmail.com>
	<CAKZ=5EVXak0SBJAY1gft4qxYFsBavrLYjxJV4tViUST_9uNUMw@mail.gmail.com>
	<4F0DB4D9020000780006BDC7@nat28.tlf.novell.com>
	<CAKZ=5EXjQbRcegXERM7FVv2aW75NS7-coO3bxmUu-6FR57aNNQ@mail.gmail.com>
In-Reply-To: <CAKZ=5EXjQbRcegXERM7FVv2aW75NS7-coO3bxmUu-6FR57aNNQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Keir Fraser <keir.xen@gmail.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen randomly stuck in mdelay() during MP
 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 11.01.12 at 16:28, Julian Pidancet <julian.pidancet@gmail.com> wrote:
> On Wed, Jan 11, 2012 at 3:12 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>> Hardly.
>>
>>> but I don't encounter the problem with xen-unstable.
>>
>> Running in x2apic mode, perhaps? (Despite having been asked
>> already, you still didn't really provide technical details about your
>> systems. Nor did you care to attach a log of the successful
>> attempt with -unstable...)
>>
> 
> Yes, disabling x2apic fixes the issue, thank you.
> Is x2apic disabled by default on xen-unstable ? It could explain why
> it doesn't hang with it.

No, it's enabled by default. But AP bringup was changed for the
x2apic case some time ago (which was the reason for my "Hardly"
above).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:38:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:38:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0FK-0006ru-My; Wed, 11 Jan 2012 15:37:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl0FJ-0006rf-A1
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:37:49 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326296261!8662507!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjQ5MTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31647 invoked from network); 11 Jan 2012 15:37:42 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-12.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 15:37:42 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0BFbahU029850;
	Wed, 11 Jan 2012 10:37:36 -0500
Date: Wed, 11 Jan 2012 10:37:36 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <8e643150-6be5-44ba-aba3-a987b22fc82b@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4F0B8D06.8050501@goop.org>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On 01/10/2012 05:44 AM, Stefano Stabellini wrote:
> > On Mon, 9 Jan 2012, Andrew Jones wrote:
> >> I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in
> >> arch/x86/pci/xen.c it would be pretty easy to review for
> >> equivalence.
> >> Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere
> >> else and
> >> compile in the 3 files. I don't think it makes much sense to do it
> >> though. XEN_DOM0 keeps things tidier now and might be useful
> >> later.
> > we can keep things clean with the following:
> >
> > #ifdef CONFIG_LOCAL_APIC && CONFIG_IO_APIC && CONFIG_ACPI &&
> > CONFIG_PCI_XEN
> >
> > #define XEN_DOM0
> >
> > #endif
> >
> > in include/xen/xen.h.
> >
> > So in the source files we can still '#ifdef XEN_DOM0', but at the
> > same
> > time we can get rid of the build symbol: everybody wins.
> 
> No, really, I think this is silly.  This kind of dependency
> information
> should be encoded in the Kconfig system, and not reimplemented in an
> ad-hoc way.
> 
> If there were a clean way to do what Andrew wants then I'd support
> it,
> but this thread has descended into a spiral of madness, which makes
> me
> think its a lost cause.
> 
> If the root complaint is that "customers think that anything set in
> .config is a supported feature", then the solutions are to support
> all
> the features in .config, re-educate the customers that they're wrong,
> or
> maintain a local patch to do this stuff.

If only re-educating people was free, like preempting questions is.
Local patches are of course always an option, and perhaps in this
case it's the best one. However, I think we already made a case for
better xen configurability for the driver domains, so I'm not 100%
convinced my initial patch (making dom0 configurable) isn't worthy
of upstream. Also, I didn't see any comments on my v2[*] of that
patch, which I believe satisfies the menu complexity issue and
brings in more configurability. That said, I'm about to reply to
that patch myself, since there's an issue with it.

Drew

[*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:38:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 15:38:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0FK-0006ru-My; Wed, 11 Jan 2012 15:37:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl0FJ-0006rf-A1
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:37:49 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326296261!8662507!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjQ5MTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31647 invoked from network); 11 Jan 2012 15:37:42 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-12.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 15:37:42 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0BFbahU029850;
	Wed, 11 Jan 2012 10:37:36 -0500
Date: Wed, 11 Jan 2012 10:37:36 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <8e643150-6be5-44ba-aba3-a987b22fc82b@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <4F0B8D06.8050501@goop.org>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On 01/10/2012 05:44 AM, Stefano Stabellini wrote:
> > On Mon, 9 Jan 2012, Andrew Jones wrote:
> >> I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in
> >> arch/x86/pci/xen.c it would be pretty easy to review for
> >> equivalence.
> >> Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere
> >> else and
> >> compile in the 3 files. I don't think it makes much sense to do it
> >> though. XEN_DOM0 keeps things tidier now and might be useful
> >> later.
> > we can keep things clean with the following:
> >
> > #ifdef CONFIG_LOCAL_APIC && CONFIG_IO_APIC && CONFIG_ACPI &&
> > CONFIG_PCI_XEN
> >
> > #define XEN_DOM0
> >
> > #endif
> >
> > in include/xen/xen.h.
> >
> > So in the source files we can still '#ifdef XEN_DOM0', but at the
> > same
> > time we can get rid of the build symbol: everybody wins.
> 
> No, really, I think this is silly.  This kind of dependency
> information
> should be encoded in the Kconfig system, and not reimplemented in an
> ad-hoc way.
> 
> If there were a clean way to do what Andrew wants then I'd support
> it,
> but this thread has descended into a spiral of madness, which makes
> me
> think its a lost cause.
> 
> If the root complaint is that "customers think that anything set in
> .config is a supported feature", then the solutions are to support
> all
> the features in .config, re-educate the customers that they're wrong,
> or
> maintain a local patch to do this stuff.

If only re-educating people was free, like preempting questions is.
Local patches are of course always an option, and perhaps in this
case it's the best one. However, I think we already made a case for
better xen configurability for the driver domains, so I'm not 100%
convinced my initial patch (making dom0 configurable) isn't worthy
of upstream. Also, I didn't see any comments on my v2[*] of that
patch, which I believe satisfies the menu complexity issue and
brings in more configurability. That said, I'm about to reply to
that patch myself, since there's an issue with it.

Drew

[*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:46:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 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 1Rl0NM-00074v-Mf; Wed, 11 Jan 2012 15:46:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl0NL-00074p-0y
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:46:07 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326296716!48169394!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzE5Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24678 invoked from network); 11 Jan 2012 15:45:17 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-10.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 15:45:17 -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 q0BFjthI022915;
	Wed, 11 Jan 2012 10:45:55 -0500
Date: Wed, 11 Jan 2012 10:45:55 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Message-ID: <7aa66b79-0850-458c-981b-6cd998d93e3b@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1326132476-10047-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, stefano stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 3/4 v2] xen kconfig: add dom0 support help
	text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 -----
> Describe dom0 support in the config menu and supply help text for it.
> 
> v2 adds 'if EXPERT' to keep it out of the "standard" menu.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/x86/xen/Kconfig |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..31ec975 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
>  	  Xen hypervisor.
>  
>  config XEN_DOM0
> -	def_bool y
> +	bool "Xen Initial Domain (Dom0) support" if EXPERT
> +	default y
>  	depends on XEN && PCI_XEN && SWIOTLB_XEN
>  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> +	help
> +	  This allows the kernel to be used for the initial Xen domain,
> +	  Domain0. This is a privileged guest that supplies backends
> +	  and is used to manage the other Xen domains.
>  
>  # Dummy symbol since people have come to rely on the
>  PRIVILEGED_GUEST
>  # name in tools.
> --
> 1.7.7.5

There's currently an issue using EXPERT. It doesn't make this
patch wrong, but any users that would want to turn EXPERT on, in
order to turn DOM0 off, would find that their configs have gotten
twisted in other ways as well. I've posted a patch for EXPERT, and
if it gets merged, then I really can't see any good arguments against
this patch.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 15:46:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 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 1Rl0NM-00074v-Mf; Wed, 11 Jan 2012 15:46:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl0NL-00074p-0y
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 15:46:07 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326296716!48169394!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzE5Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24678 invoked from network); 11 Jan 2012 15:45:17 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-10.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 15:45:17 -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 q0BFjthI022915;
	Wed, 11 Jan 2012 10:45:55 -0500
Date: Wed, 11 Jan 2012 10:45:55 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: xen-devel@lists.xensource.com
Message-ID: <7aa66b79-0850-458c-981b-6cd998d93e3b@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <1326132476-10047-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, stefano stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	konrad wilk <konrad.wilk@oracle.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 3/4 v2] xen kconfig: add dom0 support help
	text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 -----
> Describe dom0 support in the config menu and supply help text for it.
> 
> v2 adds 'if EXPERT' to keep it out of the "standard" menu.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/x86/xen/Kconfig |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..31ec975 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
>  	  Xen hypervisor.
>  
>  config XEN_DOM0
> -	def_bool y
> +	bool "Xen Initial Domain (Dom0) support" if EXPERT
> +	default y
>  	depends on XEN && PCI_XEN && SWIOTLB_XEN
>  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> +	help
> +	  This allows the kernel to be used for the initial Xen domain,
> +	  Domain0. This is a privileged guest that supplies backends
> +	  and is used to manage the other Xen domains.
>  
>  # Dummy symbol since people have come to rely on the
>  PRIVILEGED_GUEST
>  # name in tools.
> --
> 1.7.7.5

There's currently an issue using EXPERT. It doesn't make this
patch wrong, but any users that would want to turn EXPERT on, in
order to turn DOM0 off, would find that their configs have gotten
twisted in other ways as well. I've posted a patch for EXPERT, and
if it gets merged, then I really can't see any good arguments against
this patch.

Drew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:10:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:10:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0l0-0007nC-PT; Wed, 11 Jan 2012 16:10: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 1Rl0kz-0007mo-69
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:10:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298226!10588370!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 4904 invoked from network); 11 Jan 2012 16:10:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 16:10:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rl0kp-0005yB-Fi; Wed, 11 Jan 2012 16:10:23 +0000
Date: Wed, 11 Jan 2012 16:10:23 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120111161023.GD81891@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111145821.GA28944@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl 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

At 15:58 +0100 on 11 Jan (1326297501), Olaf Hering wrote:
> On Tue, Jan 10, George Dunlap wrote:
> 
> > On Mon, 2012-01-09 at 19:21 +0000, Olaf Hering wrote:
> > > So there is that maxmem= setting to let the guest OS configure itself
> > > for a given amount of pseudo-physical memory. Then there is a way to cut
> > > down the guest OS memory usage, both with balloon driver in guest and
> > > later with PoD.
> > > Isnt paging a better (or: just different) way to control the memory
> > > usage of a guest OS (It costs diskspace in dom0)?
> > 
> > On the contrary, hypervisor swapping is definitely *much worse* than
> > using a balloon driver.  The balloon driver was an innovation developed
> > specifically to avoid hypervisor swapping if at all possible[1].  We
> > need hypervisor swapping as a back-stop for situations where the balloon
> > driver is non-existent, or can't function immediately for some reason
> > (e.g., we've been using page-sharing to do memory overcommit and
> > suddenly have a bunch of pages un-shared); but it should always be a
> > last resort, and would ideally be mitigated by the balloon driver as
> > soon as possible.
> 
> Isnt that up to the host admin to decide where to take the memory from?
> So if its acceptable to swap parts of a VM (independent from what the
> guest OS thinks it has), so be it.

Why?  The _only_ reason I can imagine for wanting to use paging is when
the balloon driver can't or won't do its job.  There's no advantage to
paging except that you can always force it to happen.

I think it makes sense to have two separate targets at the libxl level
(one for the balloon driver and one for the external pager/PoD), but at the
xl level (i.e. in config files and commands) there should be only one
target for memroy-actually-in-use-by-the-guest and xl should DTRT to
achieve it.  This interface is already baffling enough. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:10:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:10:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0l0-0007nC-PT; Wed, 11 Jan 2012 16:10: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 1Rl0kz-0007mo-69
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:10:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298226!10588370!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 4904 invoked from network); 11 Jan 2012 16:10:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 16:10:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rl0kp-0005yB-Fi; Wed, 11 Jan 2012 16:10:23 +0000
Date: Wed, 11 Jan 2012 16:10:23 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120111161023.GD81891@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1111071053160.3519@kaball-desktop>
	<20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111145821.GA28944@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl 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

At 15:58 +0100 on 11 Jan (1326297501), Olaf Hering wrote:
> On Tue, Jan 10, George Dunlap wrote:
> 
> > On Mon, 2012-01-09 at 19:21 +0000, Olaf Hering wrote:
> > > So there is that maxmem= setting to let the guest OS configure itself
> > > for a given amount of pseudo-physical memory. Then there is a way to cut
> > > down the guest OS memory usage, both with balloon driver in guest and
> > > later with PoD.
> > > Isnt paging a better (or: just different) way to control the memory
> > > usage of a guest OS (It costs diskspace in dom0)?
> > 
> > On the contrary, hypervisor swapping is definitely *much worse* than
> > using a balloon driver.  The balloon driver was an innovation developed
> > specifically to avoid hypervisor swapping if at all possible[1].  We
> > need hypervisor swapping as a back-stop for situations where the balloon
> > driver is non-existent, or can't function immediately for some reason
> > (e.g., we've been using page-sharing to do memory overcommit and
> > suddenly have a bunch of pages un-shared); but it should always be a
> > last resort, and would ideally be mitigated by the balloon driver as
> > soon as possible.
> 
> Isnt that up to the host admin to decide where to take the memory from?
> So if its acceptable to swap parts of a VM (independent from what the
> guest OS thinks it has), so be it.

Why?  The _only_ reason I can imagine for wanting to use paging is when
the balloon driver can't or won't do its job.  There's no advantage to
paging except that you can always force it to happen.

I think it makes sense to have two separate targets at the libxl level
(one for the balloon driver and one for the external pager/PoD), but at the
xl level (i.e. in config files and commands) there should be only one
target for memroy-actually-in-use-by-the-guest and xl should DTRT to
achieve it.  This interface is already baffling enough. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:12:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0mE-0007uR-87; Wed, 11 Jan 2012 16:11:50 +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 1Rl0mC-0007td-9f
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:11:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326298300!10504251!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 17436 invoked from network); 11 Jan 2012 16:11:41 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 16:11: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
	q0BGBVoO018622
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Jan 2012 11:11:31 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0BGBVsn018620;
	Wed, 11 Jan 2012 11:11:31 -0500
Date: Wed, 11 Jan 2012 12:11:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111161130.GA18203@andromeda.dapyr.net>
References: <725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com>
	<1326131501-9610-1-git-send-email-drjones@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326131501-9610-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	FlorianSchandinat@gmx.de, dmitry.torokhov@gmail.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 09, 2012 at 06:51:41PM +0100, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't

Ok, but PV does?
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

That sounds like it would be universal irregardless if it is
PV or PVonHVM?
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..3e38c2f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2263,7 +2263,7 @@ config FB_VIRTUAL
>  
>  config XEN_FBDEV_FRONTEND
>  	tristate "Xen virtual frame buffer support"
> -	depends on FB && XEN
> +	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
>  	select FB_SYS_FILLRECT
>  	select FB_SYS_COPYAREA
>  	select FB_SYS_IMAGEBLIT
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:12:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0mE-0007uR-87; Wed, 11 Jan 2012 16:11:50 +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 1Rl0mC-0007td-9f
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:11:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326298300!10504251!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 17436 invoked from network); 11 Jan 2012 16:11:41 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 16:11: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
	q0BGBVoO018622
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Jan 2012 11:11:31 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0BGBVsn018620;
	Wed, 11 Jan 2012 11:11:31 -0500
Date: Wed, 11 Jan 2012 12:11:31 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111161130.GA18203@andromeda.dapyr.net>
References: <725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com>
	<1326131501-9610-1-git-send-email-drjones@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326131501-9610-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.9i
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, konrad.wilk@oracle.com,
	FlorianSchandinat@gmx.de, dmitry.torokhov@gmail.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 09, 2012 at 06:51:41PM +0100, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't

Ok, but PV does?
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

That sounds like it would be universal irregardless if it is
PV or PVonHVM?
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..3e38c2f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2263,7 +2263,7 @@ config FB_VIRTUAL
>  
>  config XEN_FBDEV_FRONTEND
>  	tristate "Xen virtual frame buffer support"
> -	depends on FB && XEN
> +	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
>  	select FB_SYS_FILLRECT
>  	select FB_SYS_COPYAREA
>  	select FB_SYS_IMAGEBLIT
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:18:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0s0-0008Jf-6Z; Wed, 11 Jan 2012 16:17:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0ry-0008JK-IQ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:17:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326298660!8712728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9341 invoked from network); 11 Jan 2012 16:17:40 -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;
	11 Jan 2012 16:17:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9951769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 16:17:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 16:17:40 +0000
Date: Wed, 11 Jan 2012 16:17:50 +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.1201101352430.3150@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 v5 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 fifth 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 v5:

- fix compilation after rebase;

- route interrupt 34 (peripheral timer) to dom0;

- GICD_ICFGR ... GICD_ICFGRN return 1;

- expand tabs;

- keep the diff of arch/arm/lib with Linux's equivalents small;

- check the size of the arguments of elf_load_image;


Changes in v4:

- fix arm build after rebasing on xen-unstable
87c607efbfece009360f615b2bf98959f4ea48e8;

- use ABS() in __ldivmod_helper;

- return a negative integer in case of errors in elf_load_image.


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 +
 tools/libxc/xc_dom_elfloader.c         |    8 +-
 tools/libxc/xc_hvm_build.c             |    5 +-
 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            |  213 +++++++++++
 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              |   87 +++++
 xen/arch/arm/lib/changebit.S           |   18 +
 xen/arch/arm/lib/clearbit.S            |   19 +
 xen/arch/arm/lib/copy_template.S       |  267 ++++++++++++++
 xen/arch/arm/lib/div64.S               |  211 +++++++++++
 xen/arch/arm/lib/findbit.S             |  198 +++++++++++
 xen/arch/arm/lib/lib1funcs.S           |  389 ++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S              |   63 ++++
 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/domain_build.c            |    7 +-
 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      |   30 ++-
 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                  |    4 +-
 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           |  236 ++++++++++++
 xen/include/asm-arm/bitops.h           |  213 +++++++++++
 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           |  125 +++++++
 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/pci.h              |    7 +
 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               |    4 +-
 xen/include/xen/list.h                 |    1 +
 xen/include/xen/paging.h               |    2 +-
 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 ++
 143 files changed, 10993 insertions(+), 62 deletions(-)

A git branch is available here, based on xen-unstable (git CS
775163293ff2933a5ffafb97045aa4962b75165b):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v5


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:18:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0s0-0008Jf-6Z; Wed, 11 Jan 2012 16:17:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0ry-0008JK-IQ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:17:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326298660!8712728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9341 invoked from network); 11 Jan 2012 16:17:40 -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;
	11 Jan 2012 16:17:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9951769"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 16:17:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 16:17:40 +0000
Date: Wed, 11 Jan 2012 16:17:50 +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.1201101352430.3150@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 v5 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 fifth 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 v5:

- fix compilation after rebase;

- route interrupt 34 (peripheral timer) to dom0;

- GICD_ICFGR ... GICD_ICFGRN return 1;

- expand tabs;

- keep the diff of arch/arm/lib with Linux's equivalents small;

- check the size of the arguments of elf_load_image;


Changes in v4:

- fix arm build after rebasing on xen-unstable
87c607efbfece009360f615b2bf98959f4ea48e8;

- use ABS() in __ldivmod_helper;

- return a negative integer in case of errors in elf_load_image.


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 +
 tools/libxc/xc_dom_elfloader.c         |    8 +-
 tools/libxc/xc_hvm_build.c             |    5 +-
 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            |  213 +++++++++++
 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              |   87 +++++
 xen/arch/arm/lib/changebit.S           |   18 +
 xen/arch/arm/lib/clearbit.S            |   19 +
 xen/arch/arm/lib/copy_template.S       |  267 ++++++++++++++
 xen/arch/arm/lib/div64.S               |  211 +++++++++++
 xen/arch/arm/lib/findbit.S             |  198 +++++++++++
 xen/arch/arm/lib/lib1funcs.S           |  389 ++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S              |   63 ++++
 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/domain_build.c            |    7 +-
 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      |   30 ++-
 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                  |    4 +-
 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           |  236 ++++++++++++
 xen/include/asm-arm/bitops.h           |  213 +++++++++++
 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           |  125 +++++++
 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/pci.h              |    7 +
 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               |    4 +-
 xen/include/xen/list.h                 |    1 +
 xen/include/xen/paging.h               |    2 +-
 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 ++
 143 files changed, 10993 insertions(+), 62 deletions(-)

A git branch is available here, based on xen-unstable (git CS
775163293ff2933a5ffafb97045aa4962b75165b):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v5


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:19:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0tW-0008PH-59; Wed, 11 Jan 2012 16:19: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 1Rl0tU-0008Oa-8j
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326298751!3877763!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1571 invoked from network); 11 Jan 2012 16:19:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763291"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4W009276;
	Wed, 11 Jan 2012 08:19:00 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:57 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 160a47f..de1a0ed 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2390,6 +2390,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)
 {
@@ -2476,6 +2566,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 Wed Jan 11 16:19:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0tW-0008PH-59; Wed, 11 Jan 2012 16:19: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 1Rl0tU-0008Oa-8j
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326298751!3877763!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1571 invoked from network); 11 Jan 2012 16:19:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763291"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4W009276;
	Wed, 11 Jan 2012 08:19:00 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:57 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 160a47f..de1a0ed 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2390,6 +2390,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)
 {
@@ -2476,6 +2566,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 Wed Jan 11 16:19:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tT-0008Ow-Nf; Wed, 11 Jan 2012 16:19:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tS-0008OX-S8
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326298751!3877763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1526 invoked from network); 11 Jan 2012 16:19:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763289"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4V009276;
	Wed, 11 Jan 2012 08:18:59 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:56 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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.


Changes in v4:

- use ABS().


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..e9d0637 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 = ABS(a);
+    ub = ABS(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 Wed Jan 11 16:19:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tT-0008Ow-Nf; Wed, 11 Jan 2012 16:19:19 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tS-0008OX-S8
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326298751!3877763!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1526 invoked from network); 11 Jan 2012 16:19:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763289"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4V009276;
	Wed, 11 Jan 2012 08:18:59 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:56 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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.


Changes in v4:

- use ABS().


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..e9d0637 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 = ABS(a);
+    ub = ABS(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 Wed Jan 11 16:19:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tb-0008Qq-7Z; Wed, 11 Jan 2012 16:19:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tZ-0008P4-MZ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298754!10589678!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5468 invoked from network); 11 Jan 2012 16:19:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763294"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0BGIr4X009276;
	Wed, 11 Jan 2012 08:19:02 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:58 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v5:

- check the size of the arguments of elf_load_image.


Changes in v4:

- return a negative integer in case of errors in elf_load_image;
propagate errors to elf_load_binary and further up the call chain.


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>
---
 tools/libxc/xc_dom_elfloader.c    |    8 +++++++-
 tools/libxc/xc_hvm_build.c        |    5 +++--
 xen/arch/x86/domain_build.c       |    7 ++++++-
 xen/common/libelf/libelf-loader.c |   30 +++++++++++++++++++++++++++---
 xen/include/xen/libelf.h          |    2 +-
 5 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 4d7b8e0..2e69559 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -310,9 +310,15 @@ static int xc_dom_parse_elf_kernel(struct xc_dom_image *dom)
 static int xc_dom_load_elf_kernel(struct xc_dom_image *dom)
 {
     struct elf_binary *elf = dom->private_loader;
+    int rc;
 
     elf->dest = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
-    elf_load_binary(elf);
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+    {
+        DOMPRINTF("%s: failed to load elf binary", __FUNCTION__);
+        return rc;
+    }
     if ( dom->parms.bsd_symtab )
         xc_dom_load_elf_symtab(dom, elf, 1);
     return 0;
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 9831bab..1fa5658 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -109,8 +109,9 @@ static int loadelfimage(
     elf->dest += elf->pstart & (PAGE_SIZE - 1);
 
     /* Load the initial elf image. */
-    elf_load_binary(elf);
-    rc = 0;
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
 
     munmap(elf->dest, pages << PAGE_SHIFT);
     elf->dest = NULL;
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 1b3818f..b3c5d4c 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -903,7 +903,12 @@ int __init construct_dom0(
 
     /* Copy the OS image and free temporary buffer. */
     elf.dest = (void*)vkern_start;
-    elf_load_binary(&elf);
+    rc = elf_load_binary(&elf);
+    if ( rc < 0 )
+    {
+        printk("Failed to load the kernel binary\n");
+        return rc;
+    }
     bootstrap_map(NULL);
 
     if ( UNSET_ADDR != parms.virt_hypercall )
diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..ab58b8b 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,34 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+    return 0;
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    int rc;
+    if ( filesz > ULONG_MAX || memsz > ULONG_MAX )
+        return -1;
+    rc = raw_copy_to_guest(dst, src, filesz);
+    if ( rc != 0 )
+        return -1;
+    rc = raw_clear_guest(dst + filesz, memsz - filesz);
+    if ( rc != 0 )
+        return -1;
+    return 0;
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -237,7 +260,7 @@ void elf_parse_binary(struct elf_binary *elf)
             __FUNCTION__, elf->pstart, elf->pend);
 }
 
-void elf_load_binary(struct elf_binary *elf)
+int elf_load_binary(struct elf_binary *elf)
 {
     const elf_phdr *phdr;
     uint64_t i, count, paddr, offset, filesz, memsz;
@@ -256,11 +279,12 @@ 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);
+        if ( elf_load_image(dest, elf->image + offset, filesz, memsz) != 0 )
+            return -1;
     }
 
     elf_load_bsdsyms(elf);
+    return 0;
 }
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d77bda6 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -198,7 +198,7 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback*,
 #endif
 
 void elf_parse_binary(struct elf_binary *elf);
-void elf_load_binary(struct elf_binary *elf);
+int elf_load_binary(struct elf_binary *elf);
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr);
 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 Wed Jan 11 16:19:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tb-0008Qq-7Z; Wed, 11 Jan 2012 16:19:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tZ-0008P4-MZ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298754!10589678!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5468 invoked from network); 11 Jan 2012 16:19:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763294"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0BGIr4X009276;
	Wed, 11 Jan 2012 08:19:02 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:58 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v5:

- check the size of the arguments of elf_load_image.


Changes in v4:

- return a negative integer in case of errors in elf_load_image;
propagate errors to elf_load_binary and further up the call chain.


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>
---
 tools/libxc/xc_dom_elfloader.c    |    8 +++++++-
 tools/libxc/xc_hvm_build.c        |    5 +++--
 xen/arch/x86/domain_build.c       |    7 ++++++-
 xen/common/libelf/libelf-loader.c |   30 +++++++++++++++++++++++++++---
 xen/include/xen/libelf.h          |    2 +-
 5 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 4d7b8e0..2e69559 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -310,9 +310,15 @@ static int xc_dom_parse_elf_kernel(struct xc_dom_image *dom)
 static int xc_dom_load_elf_kernel(struct xc_dom_image *dom)
 {
     struct elf_binary *elf = dom->private_loader;
+    int rc;
 
     elf->dest = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
-    elf_load_binary(elf);
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+    {
+        DOMPRINTF("%s: failed to load elf binary", __FUNCTION__);
+        return rc;
+    }
     if ( dom->parms.bsd_symtab )
         xc_dom_load_elf_symtab(dom, elf, 1);
     return 0;
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 9831bab..1fa5658 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -109,8 +109,9 @@ static int loadelfimage(
     elf->dest += elf->pstart & (PAGE_SIZE - 1);
 
     /* Load the initial elf image. */
-    elf_load_binary(elf);
-    rc = 0;
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
 
     munmap(elf->dest, pages << PAGE_SHIFT);
     elf->dest = NULL;
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 1b3818f..b3c5d4c 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -903,7 +903,12 @@ int __init construct_dom0(
 
     /* Copy the OS image and free temporary buffer. */
     elf.dest = (void*)vkern_start;
-    elf_load_binary(&elf);
+    rc = elf_load_binary(&elf);
+    if ( rc < 0 )
+    {
+        printk("Failed to load the kernel binary\n");
+        return rc;
+    }
     bootstrap_map(NULL);
 
     if ( UNSET_ADDR != parms.virt_hypercall )
diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..ab58b8b 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,34 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+    return 0;
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    int rc;
+    if ( filesz > ULONG_MAX || memsz > ULONG_MAX )
+        return -1;
+    rc = raw_copy_to_guest(dst, src, filesz);
+    if ( rc != 0 )
+        return -1;
+    rc = raw_clear_guest(dst + filesz, memsz - filesz);
+    if ( rc != 0 )
+        return -1;
+    return 0;
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -237,7 +260,7 @@ void elf_parse_binary(struct elf_binary *elf)
             __FUNCTION__, elf->pstart, elf->pend);
 }
 
-void elf_load_binary(struct elf_binary *elf)
+int elf_load_binary(struct elf_binary *elf)
 {
     const elf_phdr *phdr;
     uint64_t i, count, paddr, offset, filesz, memsz;
@@ -256,11 +279,12 @@ 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);
+        if ( elf_load_image(dest, elf->image + offset, filesz, memsz) != 0 )
+            return -1;
     }
 
     elf_load_bsdsyms(elf);
+    return 0;
 }
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d77bda6 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -198,7 +198,7 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback*,
 #endif
 
 void elf_parse_binary(struct elf_binary *elf);
-void elf_load_binary(struct elf_binary *elf);
+int elf_load_binary(struct elf_binary *elf);
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr);
 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 Wed Jan 11 16:19:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tW-0008Ph-P6; Wed, 11 Jan 2012 16:19:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tV-0008Oe-Vm
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298754!10589678!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5298 invoked from network); 11 Jan 2012 16:19:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4U009276;
	Wed, 11 Jan 2012 08:18:57 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:55 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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;

- guest_physmap_add_page should be ((void)0).


Changes in v4:

- fix guest_physmap_add_page;


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/paging.h      |    2 +-
 xen/include/xen/time.h        |    1 +
 7 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1100517..3c6c5af 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -635,7 +635,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
 
     xfree(d->mem_event);
 
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 65825b4..ac2be2a 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/paging.h b/xen/include/xen/paging.h
index abe276d..a5d3261 100644
--- a/xen/include/xen/paging.h
+++ b/xen/include/xen/paging.h
@@ -20,7 +20,7 @@
 
 #define paging_mode_translate(d)              (0)
 #define paging_mode_external(d)               (0)
-#define guest_physmap_add_page(d, p, m, o)    (0)
+#define guest_physmap_add_page(d, p, m, o)    ((void)0)
 #define guest_physmap_remove_page(d, p, m, o) ((void)0)
 
 #endif
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 Wed Jan 11 16:19:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tW-0008Ph-P6; Wed, 11 Jan 2012 16:19:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tV-0008Oe-Vm
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298754!10589678!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5298 invoked from network); 11 Jan 2012 16:19:15 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763292"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4U009276;
	Wed, 11 Jan 2012 08:18:57 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:55 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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;

- guest_physmap_add_page should be ((void)0).


Changes in v4:

- fix guest_physmap_add_page;


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/paging.h      |    2 +-
 xen/include/xen/time.h        |    1 +
 7 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1100517..3c6c5af 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -635,7 +635,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
 
     xfree(d->mem_event);
 
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 65825b4..ac2be2a 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/paging.h b/xen/include/xen/paging.h
index abe276d..a5d3261 100644
--- a/xen/include/xen/paging.h
+++ b/xen/include/xen/paging.h
@@ -20,7 +20,7 @@
 
 #define paging_mode_translate(d)              (0)
 #define paging_mode_external(d)               (0)
-#define guest_physmap_add_page(d, p, m, o)    (0)
+#define guest_physmap_add_page(d, p, m, o)    ((void)0)
 #define guest_physmap_remove_page(d, p, m, o) ((void)0)
 
 #endif
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 Wed Jan 11 16:19:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tg-0008TJ-Mj; Wed, 11 Jan 2012 16:19:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rl0tf-0008QR-0F
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:31 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326298763!10591034!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 6510 invoked from network); 11 Jan 2012 16:19:24 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 16:19:24 -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
	q0BGJBHe019101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Jan 2012 11:19:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0BGJBlY019099;
	Wed, 11 Jan 2012 11:19:11 -0500
Date: Wed, 11 Jan 2012 12:19:11 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111161911.GB18203@andromeda.dapyr.net>
References: <4F0B8D06.8050501@goop.org>
	<8e643150-6be5-44ba-aba3-a987b22fc82b@zmail13.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8e643150-6be5-44ba-aba3-a987b22fc82b@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > If the root complaint is that "customers think that anything set in
> > .config is a supported feature", then the solutions are to support
> > all
> > the features in .config, re-educate the customers that they're wrong,
> > or
> > maintain a local patch to do this stuff.
> 
> If only re-educating people was free, like preempting questions is.
> Local patches are of course always an option, and perhaps in this
> case it's the best one. However, I think we already made a case for
> better xen configurability for the driver domains, so I'm not 100%

Could you repost those backend patches please? At this point I am not
sure which one we have discarded?

> convinced my initial patch (making dom0 configurable) isn't worthy
> of upstream. Also, I didn't see any comments on my v2[*] of that
> patch, which I believe satisfies the menu complexity issue and
> brings in more configurability. That said, I'm about to reply to
> that patch myself, since there's an issue with it.
> 
> Drew
> 
> [*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 11 16:19:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tg-0008TJ-Mj; Wed, 11 Jan 2012 16:19:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <darnok@68k.org>) id 1Rl0tf-0008QR-0F
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:31 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326298763!10591034!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 6510 invoked from network); 11 Jan 2012 16:19:24 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 16:19:24 -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
	q0BGJBHe019101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 11 Jan 2012 11:19:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0BGJBlY019099;
	Wed, 11 Jan 2012 11:19:11 -0500
Date: Wed, 11 Jan 2012 12:19:11 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111161911.GB18203@andromeda.dapyr.net>
References: <4F0B8D06.8050501@goop.org>
	<8e643150-6be5-44ba-aba3-a987b22fc82b@zmail13.collab.prod.int.phx2.redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <8e643150-6be5-44ba-aba3-a987b22fc82b@zmail13.collab.prod.int.phx2.redhat.com>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > If the root complaint is that "customers think that anything set in
> > .config is a supported feature", then the solutions are to support
> > all
> > the features in .config, re-educate the customers that they're wrong,
> > or
> > maintain a local patch to do this stuff.
> 
> If only re-educating people was free, like preempting questions is.
> Local patches are of course always an option, and perhaps in this
> case it's the best one. However, I think we already made a case for
> better xen configurability for the driver domains, so I'm not 100%

Could you repost those backend patches please? At this point I am not
sure which one we have discarded?

> convinced my initial patch (making dom0 configurable) isn't worthy
> of upstream. Also, I didn't see any comments on my v2[*] of that
> patch, which I believe satisfies the menu complexity issue and
> brings in more configurability. That said, I'm about to reply to
> that patch myself, since there's an issue with it.
> 
> Drew
> 
> [*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 11 16:19:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0td-0008Rd-MA; Wed, 11 Jan 2012 16:19: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 1Rl0tc-0008R6-2f
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326298637!48132121!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24741 invoked from network); 11 Jan 2012 16:17:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:17:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763300"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:25 -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 q0BGIr4e009276;
	Wed, 11 Jan 2012 08:19:13 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:05 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v5:

- route interrupt 34 (peripheral timer) to dom0.

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>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c        |  213 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 4 files changed, 222 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..f73df85
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,213 @@
+#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, 34, "timer0");
+    /*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 d77bda6..0ff8b5b 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 Wed Jan 11 16:19:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0td-0008Rd-MA; Wed, 11 Jan 2012 16:19: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 1Rl0tc-0008R6-2f
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326298637!48132121!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24741 invoked from network); 11 Jan 2012 16:17:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:17:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763300"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:25 -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 q0BGIr4e009276;
	Wed, 11 Jan 2012 08:19:13 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:05 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v5:

- route interrupt 34 (peripheral timer) to dom0.

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>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c        |  213 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 4 files changed, 222 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..f73df85
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,213 @@
+#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, 34, "timer0");
+    /*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 d77bda6..0ff8b5b 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 Wed Jan 11 16:19:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0tg-0008Sj-3K; Wed, 11 Jan 2012 16:19:32 +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 1Rl0td-0008Q4-UQ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298754!10589678!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5918 invoked from network); 11 Jan 2012 16:19:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763297"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4c009276;
	Wed, 11 Jan 2012 08:19:09 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:03 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:19:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0tg-0008Sj-3K; Wed, 11 Jan 2012 16:19:32 +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 1Rl0td-0008Q4-UQ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298754!10589678!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5918 invoked from network); 11 Jan 2012 16:19:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763297"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4c009276;
	Wed, 11 Jan 2012 08:19:09 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:03 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:19:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tj-0008Ui-4P; Wed, 11 Jan 2012 16:19: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 1Rl0tg-0008R3-V4
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298754!10589678!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6204 invoked from network); 11 Jan 2012 16:19:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763299"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0BGIr4a009276;
	Wed, 11 Jan 2012 08:19:06 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:01 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v4:

- bring atomic access routines in line with upstream changes;

- fix build for -wunused-values;


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      |  236 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  213 +++++++++++++++++++++++++++++
 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/pci.h         |    7 +
 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 +
 40 files changed, 2469 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/pci.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..c7eadd6
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,236 @@
+/*
+ *  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(read_u8_atomic, "b", uint8_t, "=q")
+build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
+//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
+build_atomic_read(read_int_atomic, "", int, "=r")
+
+build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
+build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
+build_atomic_write(write_u32_atomic, "", uint32_t, "r")
+//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
+build_atomic_write(write_int_atomic, "", int, "r")
+
+void __bad_atomic_size(void);
+
+#define read_atomic(p) ({                                               \
+    typeof(*p) __x;                                                     \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: __x = (typeof(*p))read_u8_atomic((uint8_t *)p); break;      \
+    case 2: __x = (typeof(*p))read_u16_atomic((uint16_t *)p); break;    \
+    case 4: __x = (typeof(*p))read_u32_atomic((uint32_t *)p); break;    \
+    default: __x = 0; __bad_atomic_size(); break;                       \
+    }                                                                   \
+    __x;                                                                \
+})
+
+#define write_atomic(p, x) ({                                           \
+    typeof(*p) __x = (x);                                               \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: write_u8_atomic((uint8_t *)p, (uint8_t)__x); break;         \
+    case 2: write_u16_atomic((uint16_t *)p, (uint16_t)__x); break;      \
+    case 4: write_u32_atomic((uint32_t *)p, (uint32_t)__x); break;      \
+    default: __bad_atomic_size(); break;                                \
+    }                                                                   \
+    __x;                                                                \
+})
+
+/*
+ * 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..e5c1781
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,213 @@
+/*
+ * 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)));
+}
+
+/*
+ * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
+ */
+extern int _find_first_zero_bit_le(const void * p, unsigned size);
+extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+
+/*
+ * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
+ */
+extern int _find_first_zero_bit_be(const void * p, unsigned size);
+extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+
+#ifndef __ARMEB__
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
+
+#else
+/*
+ * These are the big endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
+
+#endif
+
+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..452613a
--- /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) ((void) 0)
+#define debugger_trap_immediate() ((void) 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..e49aa8d
--- /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) do {} while (0)
+#define gnttab_create_shared_page(d, t, i) do {} while (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/pci.h b/xen/include/asm-arm/pci.h
new file mode 100644
index 0000000..de13359
--- /dev/null
+++ b/xen/include/asm-arm/pci.h
@@ -0,0 +1,7 @@
+#ifndef __X86_PCI_H__
+#define __X86_PCI_H__
+
+struct arch_pci_dev {
+};
+
+#endif /* __X86_PCI_H__ */
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..c430cf3
--- /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 41b14ea..68bce71 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 Wed Jan 11 16:19:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tj-0008Ui-4P; Wed, 11 Jan 2012 16:19: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 1Rl0tg-0008R3-V4
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326298754!10589678!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6204 invoked from network); 11 Jan 2012 16:19:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763299"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0BGIr4a009276;
	Wed, 11 Jan 2012 08:19:06 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:01 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v4:

- bring atomic access routines in line with upstream changes;

- fix build for -wunused-values;


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      |  236 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  213 +++++++++++++++++++++++++++++
 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/pci.h         |    7 +
 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 +
 40 files changed, 2469 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/pci.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..c7eadd6
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,236 @@
+/*
+ *  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(read_u8_atomic, "b", uint8_t, "=q")
+build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
+//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
+build_atomic_read(read_int_atomic, "", int, "=r")
+
+build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
+build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
+build_atomic_write(write_u32_atomic, "", uint32_t, "r")
+//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
+build_atomic_write(write_int_atomic, "", int, "r")
+
+void __bad_atomic_size(void);
+
+#define read_atomic(p) ({                                               \
+    typeof(*p) __x;                                                     \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: __x = (typeof(*p))read_u8_atomic((uint8_t *)p); break;      \
+    case 2: __x = (typeof(*p))read_u16_atomic((uint16_t *)p); break;    \
+    case 4: __x = (typeof(*p))read_u32_atomic((uint32_t *)p); break;    \
+    default: __x = 0; __bad_atomic_size(); break;                       \
+    }                                                                   \
+    __x;                                                                \
+})
+
+#define write_atomic(p, x) ({                                           \
+    typeof(*p) __x = (x);                                               \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: write_u8_atomic((uint8_t *)p, (uint8_t)__x); break;         \
+    case 2: write_u16_atomic((uint16_t *)p, (uint16_t)__x); break;      \
+    case 4: write_u32_atomic((uint32_t *)p, (uint32_t)__x); break;      \
+    default: __bad_atomic_size(); break;                                \
+    }                                                                   \
+    __x;                                                                \
+})
+
+/*
+ * 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..e5c1781
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,213 @@
+/*
+ * 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)));
+}
+
+/*
+ * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
+ */
+extern int _find_first_zero_bit_le(const void * p, unsigned size);
+extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+
+/*
+ * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
+ */
+extern int _find_first_zero_bit_be(const void * p, unsigned size);
+extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+
+#ifndef __ARMEB__
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
+
+#else
+/*
+ * These are the big endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
+
+#endif
+
+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..452613a
--- /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) ((void) 0)
+#define debugger_trap_immediate() ((void) 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..e49aa8d
--- /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) do {} while (0)
+#define gnttab_create_shared_page(d, t, i) do {} while (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/pci.h b/xen/include/asm-arm/pci.h
new file mode 100644
index 0000000..de13359
--- /dev/null
+++ b/xen/include/asm-arm/pci.h
@@ -0,0 +1,7 @@
+#ifndef __X86_PCI_H__
+#define __X86_PCI_H__
+
+struct arch_pci_dev {
+};
+
+#endif /* __X86_PCI_H__ */
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..c430cf3
--- /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 41b14ea..68bce71 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 Wed Jan 11 16:19:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tr-00008t-0X; Wed, 11 Jan 2012 16:19:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0to-0008Ut-Qx
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326298772!6870550!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7937 invoked from network); 11 Jan 2012 16:19:33 -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;
	11 Jan 2012 16:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763304"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4f009276;
	Wed, 11 Jan 2012 08:19:14 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:06 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 4bb54ca..26f2d49 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..adc10bb
--- /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 Wed Jan 11 16:19:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tr-00008t-0X; Wed, 11 Jan 2012 16:19:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0to-0008Ut-Qx
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326298772!6870550!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7937 invoked from network); 11 Jan 2012 16:19:33 -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;
	11 Jan 2012 16:19:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763304"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4f009276;
	Wed, 11 Jan 2012 08:19:14 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:06 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 4bb54ca..26f2d49 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..adc10bb
--- /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 Wed Jan 11 16:19:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tr-00009D-FR; Wed, 11 Jan 2012 16:19:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tp-0008VL-H4
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326298772!6870550!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8004 invoked from network); 11 Jan 2012 16:19:35 -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;
	11 Jan 2012 16:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763330"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:34 -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 q0BGIr4k009276;
	Wed, 11 Jan 2012 08:19:22 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:11 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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..51afb31
--- /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 Wed Jan 11 16:19:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tr-00009D-FR; Wed, 11 Jan 2012 16:19:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tp-0008VL-H4
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:41 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326298772!6870550!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8004 invoked from network); 11 Jan 2012 16:19:35 -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;
	11 Jan 2012 16:19:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763330"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:34 -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 q0BGIr4k009276;
	Wed, 11 Jan 2012 08:19:22 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:11 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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..51afb31
--- /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 Wed Jan 11 16:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0tw-0000CW-4u; Wed, 11 Jan 2012 16:19:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tv-000082-6P
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326298778!8725792!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9758 invoked from network); 11 Jan 2012 16:19:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110693"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4S009276;
	Wed, 11 Jan 2012 08:18:54 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:53 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 52a63ef..1100517 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 Wed Jan 11 16:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0tw-0000CW-4u; Wed, 11 Jan 2012 16:19:48 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0tv-000082-6P
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326298778!8725792!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9758 invoked from network); 11 Jan 2012 16:19:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110693"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4S009276;
	Wed, 11 Jan 2012 08:18:54 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:53 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 52a63ef..1100517 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 Wed Jan 11 16:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tz-0000Fh-Vc; Wed, 11 Jan 2012 16:19: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 1Rl0tx-00009y-R4
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326298782!10442076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18486 invoked from network); 11 Jan 2012 16:19:43 -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;
	11 Jan 2012 16:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763334"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19: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; Wed, 11 Jan 2012 11:19: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 q0BGIr4o009276;
	Wed, 11 Jan 2012 08:19:29 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:15 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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.


Changes in v5:

- GICD_ICFGR ... GICD_ICFGRN need to return 1.


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>
Signed-off-by: David Vrabel <david.vrabel@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 72034f3..d33b692 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 17c939c..f9d663b 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..584e682
--- /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 1;
+
+    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 Wed Jan 11 16:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tz-0000Fh-Vc; Wed, 11 Jan 2012 16:19: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 1Rl0tx-00009y-R4
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326298782!10442076!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYwOTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18486 invoked from network); 11 Jan 2012 16:19:43 -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;
	11 Jan 2012 16:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="20763334"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19: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; Wed, 11 Jan 2012 11:19: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 q0BGIr4o009276;
	Wed, 11 Jan 2012 08:19:29 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:15 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, David Vrabel <david.vrabel@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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.


Changes in v5:

- GICD_ICFGR ... GICD_ICFGRN need to return 1.


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>
Signed-off-by: David Vrabel <david.vrabel@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 72034f3..d33b692 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 17c939c..f9d663b 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..584e682
--- /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 1;
+
+    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 Wed Jan 11 16:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u0-0000Gm-Pz; Wed, 11 Jan 2012 16:19:52 +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 1Rl0ty-0000E1-9s
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326298671!59284939!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1395 invoked from network); 11 Jan 2012 16:17:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:17:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110753"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0BGIr4d009276;
	Wed, 11 Jan 2012 08:19:11 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:04 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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..4bb54ca
--- /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 Wed Jan 11 16:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u0-0000Gm-Pz; Wed, 11 Jan 2012 16:19:52 +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 1Rl0ty-0000E1-9s
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326298671!59284939!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1395 invoked from network); 11 Jan 2012 16:17:54 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:17:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110753"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0BGIr4d009276;
	Wed, 11 Jan 2012 08:19:11 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:04 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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..4bb54ca
--- /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 Wed Jan 11 16:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tz-0000FQ-IR; Wed, 11 Jan 2012 16:19:51 +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 1Rl0tx-00009q-GD
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326298778!8725792!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9848 invoked from network); 11 Jan 2012 16:19:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110717"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4Z009276;
	Wed, 11 Jan 2012 08:19:05 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:00 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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; 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 |    4 +++-
 2 files changed, 5 insertions(+), 2 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 15f1806..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)
 {
-- 
1.7.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 Jan 11 16:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0tz-0000FQ-IR; Wed, 11 Jan 2012 16:19:51 +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 1Rl0tx-00009q-GD
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326298778!8725792!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9848 invoked from network); 11 Jan 2012 16:19:43 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110717"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4Z009276;
	Wed, 11 Jan 2012 08:19:05 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:00 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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; 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 |    4 +++-
 2 files changed, 5 insertions(+), 2 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 15f1806..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)
 {
-- 
1.7.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 Jan 11 16:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u0-0000G3-C5; Wed, 11 Jan 2012 16:19:52 +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 1Rl0tx-0000DV-Ow
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326298671!59284939!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1359 invoked from network); 11 Jan 2012 16:17:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:17:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110763"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:26 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:25 -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 q0BGIr4b009276;
	Wed, 11 Jan 2012 08:19:08 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:02 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v5:

- keep the diff with Linux small for this library.

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        |   87 +++++++++
 xen/arch/arm/lib/changebit.S     |   18 ++
 xen/arch/arm/lib/clearbit.S      |   19 ++
 xen/arch/arm/lib/copy_template.S |  267 ++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  211 +++++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  198 +++++++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  389 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   63 ++++++
 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/include/asm-arm/config.h     |    3 +
 18 files changed, 1837 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..689f2e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,87 @@
+#include <xen/config.h>
+
+#if __LINUX_ARM_ARCH__ >= 6
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
+#else
+	.macro	bitop, name, instr
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r2, r0, #31
+	mov	r0, r0, lsr #5
+	mov	r3, #1
+	mov	r3, r3, lsl r2
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]
+	\instr	r2, r2, r3
+	str	r2, [r1, r0, lsl #2]
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
+
+/**
+ * testop - implement a test_and_xxx_bit operation.
+ * @instr: operational instruction
+ * @store: store instruction
+ *
+ * Note: we can trivially conditionalise the store instruction
+ * to avoid dirtying the data cache.
+ */
+	.macro	testop, name, instr, store
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r3, r0, #31
+	mov	r0, r0, lsr #5
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]!
+	mov	r0, #1
+	tst	r2, r0, lsl r3
+	\instr	r2, r2, r0, lsl r3
+	\store	r2, [r1]
+	moveq	r0, #0
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
+#endif
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..805e3f8
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,267 @@
+/*
+ *  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..83a5f22
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,211 @@
+/*
+ *  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"
+	
+#ifdef __ARMEB__
+#define xh r0
+#define xl r1
+#define yh r2
+#define yl r3
+#else
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+#endif
+
+/*
+ * __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)
+UNWIND(.fnstart)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ 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.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+#else
+
+	mov	yl, r4
+	mov	ip, #1
+1:	cmp	yl, #0x80000000
+	cmpcc	yl, xh
+	movcc	yl, yl, lsl #1
+	movcc	ip, ip, lsl #1
+	bcc	1b
+
+#endif
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ 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.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+#else
+
+7:	movs	xl, xl, lsl #1
+	mov	ip, ip, lsr #1
+	bcc	7b
+
+#endif
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+#else
+
+	mov	yl, r4
+	cmp	r4, #(1 << 16)
+	mov	ip, #0
+	movhs	yl, yl, lsr #16
+	movhs	ip, #16
+
+	cmp	yl, #(1 << 8)
+	movhs	yl, yl, lsr #8
+	addhs	ip, ip, #8
+
+	cmp	yl, #(1 << 4)
+	movhs	yl, yl, lsr #4
+	addhs	ip, ip, #4
+
+	cmp	yl, #(1 << 2)
+	addhi	ip, ip, #3
+	addls	ip, ip, yl, lsr #1
+
+#endif
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+UNWIND(.fnend)
+
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+Ldiv0_64:
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+UNWIND(.fnend)
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..2fbcc82
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,198 @@
+/*
+ *  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_le)
+		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_le)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit_le)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit_le)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit_le)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+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_le)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit_le)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit_le)
+
+#ifdef __ARMEB__
+
+ENTRY(_find_first_zero_bit_be)
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit_be)
+
+ENTRY(_find_next_zero_bit_be)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit_be)
+
+ENTRY(_find_first_bit_be)
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit_be)
+
+ENTRY(_find_next_bit_be)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit_be)
+
+#endif
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+#if __LINUX_ARM_ARCH__ >= 5
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+#else
+		tst	r3, #0x0f
+		addeq	r2, r2, #4
+		movne	r3, r3, lsl #4
+		tst	r3, #0x30
+		addeq	r2, r2, #2
+		movne	r3, r3, lsl #2
+		tst	r3, #0x40
+		addeq	r2, r2, #1
+		mov	r0, r2
+#endif
+		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..95ee312
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,389 @@
+/*
+ * 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
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+#else
+
+	@ Initially shift the divisor left 3 bits if possible,
+	@ set curbit accordingly.  This allows for curbit to be located
+	@ at the left end of each 4 bit nibbles in the division loop
+	@ to save one loop in most cases.
+	tst	\divisor, #0xe0000000
+	moveq	\divisor, \divisor, lsl #3
+	moveq	\curbit, #8
+	movne	\curbit, #1
+
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	movlo	\curbit, \curbit, lsl #4
+	blo	1b
+
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	movlo	\curbit, \curbit, lsl #1
+	blo	1b
+
+	mov	\result, #0
+
+#endif
+
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+#else
+
+	cmp	\divisor, #(1 << 16)
+	movhs	\divisor, \divisor, lsr #16
+	movhs	\order, #16
+	movlo	\order, #0
+
+	cmp	\divisor, #(1 << 8)
+	movhs	\divisor, \divisor, lsr #8
+	addhs	\order, \order, #8
+
+	cmp	\divisor, #(1 << 4)
+	movhs	\divisor, \divisor, lsr #4
+	addhs	\order, \order, #4
+
+	cmp	\divisor, #(1 << 2)
+	addhi	\order, \order, #3
+	addls	\order, \order, \divisor, lsr #1
+
+#endif
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+#else
+
+	mov	\order, #0
+
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	addlo	\order, \order, #4
+	blo	1b
+
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	addlo	\order, \order, #1
+	blo	1b
+
+#endif
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+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)
+
+#ifdef CONFIG_AEABI
+
+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_ldivmod)
+#endif
+
+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..d1ab9fb
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,63 @@
+/*
+ *  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)
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 12285dd..9294f8f 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -30,6 +30,9 @@
 
 #define asmlinkage /* Nothing needed */
 
+#define __LINUX_ARM_ARCH__ 7
+#define CONFIG_AEABI
+
 /* Linkage for ARM */
 #define __ALIGN .align 2
 #define __ALIGN_STR ".align 2"
-- 
1.7.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 Jan 11 16:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u0-0000G3-C5; Wed, 11 Jan 2012 16:19:52 +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 1Rl0tx-0000DV-Ow
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326298671!59284939!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1359 invoked from network); 11 Jan 2012 16:17:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:17:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110763"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:26 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19:25 -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 q0BGIr4b009276;
	Wed, 11 Jan 2012 08:19:08 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:02 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v5:

- keep the diff with Linux small for this library.

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        |   87 +++++++++
 xen/arch/arm/lib/changebit.S     |   18 ++
 xen/arch/arm/lib/clearbit.S      |   19 ++
 xen/arch/arm/lib/copy_template.S |  267 ++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  211 +++++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  198 +++++++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  389 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   63 ++++++
 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/include/asm-arm/config.h     |    3 +
 18 files changed, 1837 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..689f2e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,87 @@
+#include <xen/config.h>
+
+#if __LINUX_ARM_ARCH__ >= 6
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
+#else
+	.macro	bitop, name, instr
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r2, r0, #31
+	mov	r0, r0, lsr #5
+	mov	r3, #1
+	mov	r3, r3, lsl r2
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]
+	\instr	r2, r2, r3
+	str	r2, [r1, r0, lsl #2]
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
+
+/**
+ * testop - implement a test_and_xxx_bit operation.
+ * @instr: operational instruction
+ * @store: store instruction
+ *
+ * Note: we can trivially conditionalise the store instruction
+ * to avoid dirtying the data cache.
+ */
+	.macro	testop, name, instr, store
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r3, r0, #31
+	mov	r0, r0, lsr #5
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]!
+	mov	r0, #1
+	tst	r2, r0, lsl r3
+	\instr	r2, r2, r0, lsl r3
+	\store	r2, [r1]
+	moveq	r0, #0
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
+#endif
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..805e3f8
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,267 @@
+/*
+ *  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..83a5f22
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,211 @@
+/*
+ *  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"
+	
+#ifdef __ARMEB__
+#define xh r0
+#define xl r1
+#define yh r2
+#define yl r3
+#else
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+#endif
+
+/*
+ * __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)
+UNWIND(.fnstart)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ 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.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+#else
+
+	mov	yl, r4
+	mov	ip, #1
+1:	cmp	yl, #0x80000000
+	cmpcc	yl, xh
+	movcc	yl, yl, lsl #1
+	movcc	ip, ip, lsl #1
+	bcc	1b
+
+#endif
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ 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.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+#else
+
+7:	movs	xl, xl, lsl #1
+	mov	ip, ip, lsr #1
+	bcc	7b
+
+#endif
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+#else
+
+	mov	yl, r4
+	cmp	r4, #(1 << 16)
+	mov	ip, #0
+	movhs	yl, yl, lsr #16
+	movhs	ip, #16
+
+	cmp	yl, #(1 << 8)
+	movhs	yl, yl, lsr #8
+	addhs	ip, ip, #8
+
+	cmp	yl, #(1 << 4)
+	movhs	yl, yl, lsr #4
+	addhs	ip, ip, #4
+
+	cmp	yl, #(1 << 2)
+	addhi	ip, ip, #3
+	addls	ip, ip, yl, lsr #1
+
+#endif
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+UNWIND(.fnend)
+
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+Ldiv0_64:
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+UNWIND(.fnend)
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..2fbcc82
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,198 @@
+/*
+ *  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_le)
+		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_le)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit_le)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit_le)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit_le)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+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_le)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit_le)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit_le)
+
+#ifdef __ARMEB__
+
+ENTRY(_find_first_zero_bit_be)
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit_be)
+
+ENTRY(_find_next_zero_bit_be)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit_be)
+
+ENTRY(_find_first_bit_be)
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit_be)
+
+ENTRY(_find_next_bit_be)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit_be)
+
+#endif
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+#if __LINUX_ARM_ARCH__ >= 5
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+#else
+		tst	r3, #0x0f
+		addeq	r2, r2, #4
+		movne	r3, r3, lsl #4
+		tst	r3, #0x30
+		addeq	r2, r2, #2
+		movne	r3, r3, lsl #2
+		tst	r3, #0x40
+		addeq	r2, r2, #1
+		mov	r0, r2
+#endif
+		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..95ee312
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,389 @@
+/*
+ * 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
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+#else
+
+	@ Initially shift the divisor left 3 bits if possible,
+	@ set curbit accordingly.  This allows for curbit to be located
+	@ at the left end of each 4 bit nibbles in the division loop
+	@ to save one loop in most cases.
+	tst	\divisor, #0xe0000000
+	moveq	\divisor, \divisor, lsl #3
+	moveq	\curbit, #8
+	movne	\curbit, #1
+
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	movlo	\curbit, \curbit, lsl #4
+	blo	1b
+
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	movlo	\curbit, \curbit, lsl #1
+	blo	1b
+
+	mov	\result, #0
+
+#endif
+
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+#else
+
+	cmp	\divisor, #(1 << 16)
+	movhs	\divisor, \divisor, lsr #16
+	movhs	\order, #16
+	movlo	\order, #0
+
+	cmp	\divisor, #(1 << 8)
+	movhs	\divisor, \divisor, lsr #8
+	addhs	\order, \order, #8
+
+	cmp	\divisor, #(1 << 4)
+	movhs	\divisor, \divisor, lsr #4
+	addhs	\order, \order, #4
+
+	cmp	\divisor, #(1 << 2)
+	addhi	\order, \order, #3
+	addls	\order, \order, \divisor, lsr #1
+
+#endif
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+#else
+
+	mov	\order, #0
+
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	addlo	\order, \order, #4
+	blo	1b
+
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	addlo	\order, \order, #1
+	blo	1b
+
+#endif
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+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)
+
+#ifdef CONFIG_AEABI
+
+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_ldivmod)
+#endif
+
+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..d1ab9fb
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,63 @@
+/*
+ *  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)
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 12285dd..9294f8f 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -30,6 +30,9 @@
 
 #define asmlinkage /* Nothing needed */
 
+#define __LINUX_ARM_ARCH__ 7
+#define CONFIG_AEABI
+
 /* Linkage for ARM */
 #define __ALIGN .align 2
 #define __ALIGN_STR ".align 2"
-- 
1.7.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 Jan 11 16:19:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u1-0000HD-5k; Wed, 11 Jan 2012 16:19:53 +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 1Rl0ty-0000AO-K7
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326298778!8725792!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9897 invoked from network); 11 Jan 2012 16:19:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110719"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4T009276;
	Wed, 11 Jan 2012 08:18:56 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:54 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 d6ae09b..14ab515 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 014734d..b024016 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 f22fe05..1051a86 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 c796137..8d45439 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 2fb2309..92d1a4f 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 3904afe..6546757 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 76ab440..fdbeed1 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 Wed Jan 11 16:19:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u1-0000HD-5k; Wed, 11 Jan 2012 16:19:53 +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 1Rl0ty-0000AO-K7
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326298778!8725792!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9897 invoked from network); 11 Jan 2012 16:19:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110719"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4T009276;
	Wed, 11 Jan 2012 08:18:56 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:54 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 d6ae09b..14ab515 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 014734d..b024016 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 f22fe05..1051a86 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 c796137..8d45439 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 2fb2309..92d1a4f 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 3904afe..6546757 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 76ab440..fdbeed1 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 Wed Jan 11 16:19:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u5-0000Nw-W7; Wed, 11 Jan 2012 16:19:57 +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 1Rl0u4-0000FO-RZ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326298788!10497696!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19448 invoked from network); 11 Jan 2012 16:19:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110777"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4h009276;
	Wed, 11 Jan 2012 08:19:18 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:08 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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..17c939c
--- /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 Wed Jan 11 16:19:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:19:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u5-0000Nw-W7; Wed, 11 Jan 2012 16:19:57 +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 1Rl0u4-0000FO-RZ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326298788!10497696!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19448 invoked from network); 11 Jan 2012 16:19:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110777"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4h009276;
	Wed, 11 Jan 2012 08:19:18 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:08 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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..17c939c
--- /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 Wed Jan 11 16:20:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u9-0000RO-Co; Wed, 11 Jan 2012 16:20:01 +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 1Rl0u6-0000HL-M2
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326298788!10497696!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19482 invoked from network); 11 Jan 2012 16:19:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110791"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4i009276;
	Wed, 11 Jan 2012 08:19:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:09 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v4:

- fix build for -wunused-values;


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 26f2d49..72034f3 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..f721c54
--- /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), (void)(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 Wed Jan 11 16:20:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0u9-0000RO-Co; Wed, 11 Jan 2012 16:20:01 +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 1Rl0u6-0000HL-M2
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:19:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326298788!10497696!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19482 invoked from network); 11 Jan 2012 16:19:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110791"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4i009276;
	Wed, 11 Jan 2012 08:19:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:09 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 v4:

- fix build for -wunused-values;


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 26f2d49..72034f3 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..f721c54
--- /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), (void)(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 Wed Jan 11 16:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uD-0000Vj-8g; Wed, 11 Jan 2012 16:20:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0uB-0000Oj-Vs
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16555 invoked from network); 11 Jan 2012 16:19:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110815"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4l009276;
	Wed, 11 Jan 2012 08:19:24 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:12 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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..cad84f5
--- /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 Wed Jan 11 16:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uD-0000Vj-8g; Wed, 11 Jan 2012 16:20:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0uB-0000Oj-Vs
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16555 invoked from network); 11 Jan 2012 16:19:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110815"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4l009276;
	Wed, 11 Jan 2012 08:19:24 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:12 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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..cad84f5
--- /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 Wed Jan 11 16:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uE-0000XL-Ml; Wed, 11 Jan 2012 16:20:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0uC-0000PJ-L8
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16615 invoked from network); 11 Jan 2012 16:19:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110799"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4g009276;
	Wed, 11 Jan 2012 08:19:16 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:07 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uE-0000XL-Ml; Wed, 11 Jan 2012 16:20:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0uC-0000PJ-L8
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16615 invoked from network); 11 Jan 2012 16:19:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110799"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4g009276;
	Wed, 11 Jan 2012 08:19:16 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:07 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uJ-0000cY-IM; Wed, 11 Jan 2012 16:20:11 +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 1Rl0uI-0000VT-AI
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17197 invoked from network); 11 Jan 2012 16:20:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:20:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110837"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4m009276;
	Wed, 11 Jan 2012 08:19:26 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:13 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uJ-0000cY-IM; Wed, 11 Jan 2012 16:20:11 +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 1Rl0uI-0000VT-AI
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17197 invoked from network); 11 Jan 2012 16:20:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:20:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110837"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4m009276;
	Wed, 11 Jan 2012 08:19:26 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:13 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uJ-0000bz-3S; Wed, 11 Jan 2012 16:20:11 +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 1Rl0uH-0000Uh-Eu
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17015 invoked from network); 11 Jan 2012 16:20:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:20:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110835"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4p009276;
	Wed, 11 Jan 2012 08:19:30 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:16 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 d33b692..ada89af 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..6b1152e
--- /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 Wed Jan 11 16:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uJ-0000bz-3S; Wed, 11 Jan 2012 16:20:11 +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 1Rl0uH-0000Uh-Eu
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17015 invoked from network); 11 Jan 2012 16:20:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:20:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110835"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:43 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4p009276;
	Wed, 11 Jan 2012 08:19:30 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:16 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 d33b692..ada89af 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..6b1152e
--- /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 Wed Jan 11 16:20:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0uN-0000i0-7f; Wed, 11 Jan 2012 16:20:15 +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 1Rl0uL-0000Z0-FA
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17417 invoked from network); 11 Jan 2012 16:20:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:20:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110843"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4n009276;
	Wed, 11 Jan 2012 08:19:27 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:14 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:20:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl0uN-0000i0-7f; Wed, 11 Jan 2012 16:20:15 +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 1Rl0uL-0000Z0-FA
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326298796!2494196!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17417 invoked from network); 11 Jan 2012 16:20:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:20:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110843"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4n009276;
	Wed, 11 Jan 2012 08:19:27 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:14 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:20:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uQ-0000mT-O5; Wed, 11 Jan 2012 16:20:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0uP-0000cs-2W
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326298802!10591135!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9590 invoked from network); 11 Jan 2012 16:20:10 -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;
	11 Jan 2012 16:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4q009276;
	Wed, 11 Jan 2012 08:19:32 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:17 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:20:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0uQ-0000mT-O5; Wed, 11 Jan 2012 16:20:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl0uP-0000cs-2W
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:20:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326298802!10591135!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9590 invoked from network); 11 Jan 2012 16:20:10 -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;
	11 Jan 2012 16:20:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110840"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:44 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11: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 q0BGIr4q009276;
	Wed, 11 Jan 2012 08:19:32 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:19:17 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:22:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0w9-0002GN-HY; Wed, 11 Jan 2012 16:22:05 +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 1Rl0w7-0002As-79
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:22:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326298785!10432560!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25313 invoked from network); 11 Jan 2012 16:19:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110745"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4Y009276;
	Wed, 11 Jan 2012 08:19:03 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:59 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:22:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl0w9-0002GN-HY; Wed, 11 Jan 2012 16:22:05 +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 1Rl0w7-0002As-79
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:22:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326298785!10432560!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzA2MDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25313 invoked from network); 11 Jan 2012 16:19:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 16:19:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320642000"; d="scan'208";a="177110745"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 11:19:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 11:19: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 q0BGIr4Y009276;
	Wed, 11 Jan 2012 08:19:03 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 16:18:59 +0000
Message-ID: <1326298757-9846-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.1201101352430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Tim.Deegan@citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v5 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 Wed Jan 11 16:30:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl147-00046Z-Sb; Wed, 11 Jan 2012 16:30:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl146-00046U-SW
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:30:19 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326299411!10609830!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzE5Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16692 invoked from network); 11 Jan 2012 16:30:12 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 16:30:12 -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 q0BGTK1r028460;
	Wed, 11 Jan 2012 11:29:20 -0500
Date: Wed, 11 Jan 2012 11:29:20 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <7e004a73-b1ef-49f4-91e8-68fdf48c3ccb@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111161130.GA18203@andromeda.dapyr.net>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>, FlorianSchandinat@gmx.de,
	dmitry torokhov <dmitry.torokhov@gmail.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Mon, Jan 09, 2012 at 06:51:41PM +0100, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
> > but
> > they don't use the xen frame buffer frontend. For this case it
> > doesn't
> 
> Ok, but PV does?
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
> > i.e.
> > if you're using xenfb, then you'll want xenkbd. Switch the
> > dependencies.
> 
> That sounds like it would be universal irregardless if it is
> PV or PVonHVM?

This patch makes it such that if you want to use both, then you must
select both. It also says that if you want FB, then you need the
KBD. However, if you only want the KBD then you're fine with just
that. So there isn't any risk of breaking configs designed to use
FB, because FB should be manually selected for those configs anyway.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/input/misc/Kconfig |    2 +-
> >  drivers/video/Kconfig      |    2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/input/misc/Kconfig
> > b/drivers/input/misc/Kconfig
> > index 22d875f..36c15bf 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> >  
> >  config INPUT_XEN_KBDDEV_FRONTEND
> >  	tristate "Xen virtual keyboard and mouse support"
> > -	depends on XEN_FBDEV_FRONTEND
> > +	depends on XEN
> >  	default y
> >  	select XEN_XENBUS_FRONTEND
> >  	help
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index d83e967..3e38c2f 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -2263,7 +2263,7 @@ config FB_VIRTUAL
> >  
> >  config XEN_FBDEV_FRONTEND
> >  	tristate "Xen virtual frame buffer support"
> > -	depends on FB && XEN
> > +	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
> >  	select FB_SYS_FILLRECT
> >  	select FB_SYS_COPYAREA
> >  	select FB_SYS_IMAGEBLIT
> > --
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:30:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16: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 1Rl147-00046Z-Sb; Wed, 11 Jan 2012 16:30:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl146-00046U-SW
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:30:19 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326299411!10609830!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzE5Mzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16692 invoked from network); 11 Jan 2012 16:30:12 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 16:30:12 -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 q0BGTK1r028460;
	Wed, 11 Jan 2012 11:29:20 -0500
Date: Wed, 11 Jan 2012 11:29:20 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <7e004a73-b1ef-49f4-91e8-68fdf48c3ccb@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111161130.GA18203@andromeda.dapyr.net>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	konrad wilk <konrad.wilk@oracle.com>, FlorianSchandinat@gmx.de,
	dmitry torokhov <dmitry.torokhov@gmail.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Mon, Jan 09, 2012 at 06:51:41PM +0100, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
> > but
> > they don't use the xen frame buffer frontend. For this case it
> > doesn't
> 
> Ok, but PV does?
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
> > i.e.
> > if you're using xenfb, then you'll want xenkbd. Switch the
> > dependencies.
> 
> That sounds like it would be universal irregardless if it is
> PV or PVonHVM?

This patch makes it such that if you want to use both, then you must
select both. It also says that if you want FB, then you need the
KBD. However, if you only want the KBD then you're fine with just
that. So there isn't any risk of breaking configs designed to use
FB, because FB should be manually selected for those configs anyway.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/input/misc/Kconfig |    2 +-
> >  drivers/video/Kconfig      |    2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/input/misc/Kconfig
> > b/drivers/input/misc/Kconfig
> > index 22d875f..36c15bf 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> >  
> >  config INPUT_XEN_KBDDEV_FRONTEND
> >  	tristate "Xen virtual keyboard and mouse support"
> > -	depends on XEN_FBDEV_FRONTEND
> > +	depends on XEN
> >  	default y
> >  	select XEN_XENBUS_FRONTEND
> >  	help
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index d83e967..3e38c2f 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -2263,7 +2263,7 @@ config FB_VIRTUAL
> >  
> >  config XEN_FBDEV_FRONTEND
> >  	tristate "Xen virtual frame buffer support"
> > -	depends on FB && XEN
> > +	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
> >  	select FB_SYS_FILLRECT
> >  	select FB_SYS_COPYAREA
> >  	select FB_SYS_IMAGEBLIT
> > --
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:37:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 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 1Rl1BL-0004bg-4Z; Wed, 11 Jan 2012 16:37:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl1BJ-0004bG-Ez
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:37:45 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326299858!2496721!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4930 invoked from network); 11 Jan 2012 16:37:38 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 16:37:38 -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 q0BGalew020275
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 11:36:47 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0BGajIn005239; Wed, 11 Jan 2012 11:36:45 -0500
From: Andrew Jones <drjones@redhat.com>
To: konrad@darnok.org
Date: Wed, 11 Jan 2012 17:36:38 +0100
Message-Id: <1326299801-7966-1-git-send-email-drjones@redhat.com>
In-Reply-To: <20120111161911.GB18203@andromeda.dapyr.net>
References: <20120111161911.GB18203@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..1d24061 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
 	 but will have no xen contents.
 
 config XEN_XENBUS_FRONTEND
-	tristate
+	bool
 
 config XEN_GNTDEV
 	tristate "userspace grant access device driver"
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:37:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 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 1Rl1BL-0004bg-4Z; Wed, 11 Jan 2012 16:37:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl1BJ-0004bG-Ez
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:37:45 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326299858!2496721!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4930 invoked from network); 11 Jan 2012 16:37:38 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 16:37:38 -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 q0BGalew020275
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 11:36:47 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0BGajIn005239; Wed, 11 Jan 2012 11:36:45 -0500
From: Andrew Jones <drjones@redhat.com>
To: konrad@darnok.org
Date: Wed, 11 Jan 2012 17:36:38 +0100
Message-Id: <1326299801-7966-1-git-send-email-drjones@redhat.com>
In-Reply-To: <20120111161911.GB18203@andromeda.dapyr.net>
References: <20120111161911.GB18203@andromeda.dapyr.net>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 XEN_XENBUS_FRONTEND gets selected as a module it can lead to
unbootable configs. If we need it, then we should just build it in.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8795480..1d24061 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
 	 but will have no xen contents.
 
 config XEN_XENBUS_FRONTEND
-	tristate
+	bool
 
 config XEN_GNTDEV
 	tristate "userspace grant access device driver"
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:37:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1BP-0004cM-Vv; Wed, 11 Jan 2012 16:37:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl1BP-0004bb-7G
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:37:51 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326299864!10525336!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6319 invoked from network); 11 Jan 2012 16:37:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 16:37:45 -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 q0BGas0M020628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 11:36:54 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0BGajIq005239; Wed, 11 Jan 2012 11:36:52 -0500
From: Andrew Jones <drjones@redhat.com>
To: konrad@darnok.org
Date: Wed, 11 Jan 2012 17:36:41 +0100
Message-Id: <1326299801-7966-4-git-send-email-drjones@redhat.com>
In-Reply-To: <1326299801-7966-1-git-send-email-drjones@redhat.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 description to the config menu for xen tmem.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d24061..7e8d728 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -143,7 +143,7 @@ config SWIOTLB_XEN
 	select SWIOTLB
 
 config XEN_TMEM
-	bool
+	bool "Xen Transcendent Memory (tmem)"
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:37:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:37:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1BP-0004cM-Vv; Wed, 11 Jan 2012 16:37:51 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl1BP-0004bb-7G
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:37:51 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326299864!10525336!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6319 invoked from network); 11 Jan 2012 16:37:45 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 16:37:45 -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 q0BGas0M020628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 11:36:54 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0BGajIq005239; Wed, 11 Jan 2012 11:36:52 -0500
From: Andrew Jones <drjones@redhat.com>
To: konrad@darnok.org
Date: Wed, 11 Jan 2012 17:36:41 +0100
Message-Id: <1326299801-7966-4-git-send-email-drjones@redhat.com>
In-Reply-To: <1326299801-7966-1-git-send-email-drjones@redhat.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 description to the config menu for xen tmem.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/xen/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 1d24061..7e8d728 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -143,7 +143,7 @@ config SWIOTLB_XEN
 	select SWIOTLB
 
 config XEN_TMEM
-	bool
+	bool "Xen Transcendent Memory (tmem)"
 	default y if (CLEANCACHE || FRONTSWAP)
 	help
 	  Shim to interface in-kernel Transcendent Memory hooks
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:38:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1BO-0004c4-IB; Wed, 11 Jan 2012 16:37:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl1BM-0004bO-Bw
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:37:48 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326299861!8727954!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13114 invoked from network); 11 Jan 2012 16:37:42 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 16:37:42 -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 q0BGantF020291
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 11:36:50 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0BGajIo005239; Wed, 11 Jan 2012 11:36:48 -0500
From: Andrew Jones <drjones@redhat.com>
To: konrad@darnok.org
Date: Wed, 11 Jan 2012 17:36:39 +0100
Message-Id: <1326299801-7966-2-git-send-email-drjones@redhat.com>
In-Reply-To: <1326299801-7966-1-git-send-email-drjones@redhat.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..3e38c2f 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2263,7 +2263,7 @@ config FB_VIRTUAL
 
 config XEN_FBDEV_FRONTEND
 	tristate "Xen virtual frame buffer support"
-	depends on FB && XEN
+	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
 	select FB_SYS_FILLRECT
 	select FB_SYS_COPYAREA
 	select FB_SYS_IMAGEBLIT
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:38:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1BO-0004c4-IB; Wed, 11 Jan 2012 16:37:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl1BM-0004bO-Bw
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:37:48 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326299861!8727954!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13114 invoked from network); 11 Jan 2012 16:37:42 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 16:37:42 -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 q0BGantF020291
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 11:36:50 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0BGajIo005239; Wed, 11 Jan 2012 11:36:48 -0500
From: Andrew Jones <drjones@redhat.com>
To: konrad@darnok.org
Date: Wed, 11 Jan 2012 17:36:39 +0100
Message-Id: <1326299801-7966-2-git-send-email-drjones@redhat.com>
In-Reply-To: <1326299801-7966-1-git-send-email-drjones@redhat.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
they don't use the xen frame buffer frontend. For this case it doesn't
make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 drivers/input/misc/Kconfig |    2 +-
 drivers/video/Kconfig      |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 22d875f..36c15bf 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
 
 config INPUT_XEN_KBDDEV_FRONTEND
 	tristate "Xen virtual keyboard and mouse support"
-	depends on XEN_FBDEV_FRONTEND
+	depends on XEN
 	default y
 	select XEN_XENBUS_FRONTEND
 	help
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d83e967..3e38c2f 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2263,7 +2263,7 @@ config FB_VIRTUAL
 
 config XEN_FBDEV_FRONTEND
 	tristate "Xen virtual frame buffer support"
-	depends on FB && XEN
+	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
 	select FB_SYS_FILLRECT
 	select FB_SYS_COPYAREA
 	select FB_SYS_IMAGEBLIT
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:38:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:38:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1Bq-0004iU-EF; Wed, 11 Jan 2012 16:38:18 +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 1Rl1Bo-0004hM-ER
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:38:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326299853!55540352!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8968 invoked from network); 11 Jan 2012 16:37:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 11 Jan 2012 16:37:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326299891; l=580;
	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=FdF3c99KW8j7ACboamYWNXs0MUU=;
	b=dSGpQ4vLNEI8ED2jJGsCxPUYl4P4kczNMosL5h5bVaiKBv02BMnOncfyAIxZwk5xeLk
	ElqbPjOu3nI8ex7c53/XM/72sV9Y6URt4WRaxynh4Df/HkfzdCv2Lr2BIDBaspQweMhQC
	hYyLT6yeVvz1RVWP+kaEcfy7TcFHy4LB7Uo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzAQEURr
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-113-021.pools.arcor-ip.net [88.65.113.21])
	by smtp.strato.de (fruni mo36) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x01471o0BEO656 ;
	Wed, 11 Jan 2012 17:38:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 81CD118637; Wed, 11 Jan 2012 17:38:03 +0100 (CET)
Date: Wed, 11 Jan 2012 17:38:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120111163803.GA30142@aepfle.de>
References: <20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
	<20120111161023.GD81891@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111161023.GD81891@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, Tim Deegan wrote:

> > Isnt that up to the host admin to decide where to take the memory from?
> > So if its acceptable to swap parts of a VM (independent from what the
> > guest OS thinks it has), so be it.
> 
> Why?  The _only_ reason I can imagine for wanting to use paging is when
> the balloon driver can't or won't do its job.  There's no advantage to
> paging except that you can always force it to happen.

Isnt that the whole point of paging, to make it happen at will without
the guest (or the application at process level) noticing it?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:38:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:38:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1Bq-0004iU-EF; Wed, 11 Jan 2012 16:38:18 +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 1Rl1Bo-0004hM-ER
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:38:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326299853!55540352!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYyMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8968 invoked from network); 11 Jan 2012 16:37:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 11 Jan 2012 16:37:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326299891; l=580;
	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=FdF3c99KW8j7ACboamYWNXs0MUU=;
	b=dSGpQ4vLNEI8ED2jJGsCxPUYl4P4kczNMosL5h5bVaiKBv02BMnOncfyAIxZwk5xeLk
	ElqbPjOu3nI8ex7c53/XM/72sV9Y6URt4WRaxynh4Df/HkfzdCv2Lr2BIDBaspQweMhQC
	hYyLT6yeVvz1RVWP+kaEcfy7TcFHy4LB7Uo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzAQEURr
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-113-021.pools.arcor-ip.net [88.65.113.21])
	by smtp.strato.de (fruni mo36) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x01471o0BEO656 ;
	Wed, 11 Jan 2012 17:38:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 81CD118637; Wed, 11 Jan 2012 17:38:03 +0100 (CET)
Date: Wed, 11 Jan 2012 17:38:03 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120111163803.GA30142@aepfle.de>
References: <20111107125535.GA16522@aepfle.de>
	<alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
	<20120111161023.GD81891@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111161023.GD81891@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, Tim Deegan wrote:

> > Isnt that up to the host admin to decide where to take the memory from?
> > So if its acceptable to swap parts of a VM (independent from what the
> > guest OS thinks it has), so be it.
> 
> Why?  The _only_ reason I can imagine for wanting to use paging is when
> the balloon driver can't or won't do its job.  There's no advantage to
> paging except that you can always force it to happen.

Isnt that the whole point of paging, to make it happen at will without
the guest (or the application at process level) noticing it?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:38:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1CC-0004ns-Sp; Wed, 11 Jan 2012 16:38:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl1CB-0004lx-5X
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:38:39 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326299863!10435290!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24916 invoked from network); 11 Jan 2012 16:37:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 16:37: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 q0BGaq3h020614
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 11:36:52 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0BGajIp005239; Wed, 11 Jan 2012 11:36:50 -0500
From: Andrew Jones <drjones@redhat.com>
To: konrad@darnok.org
Date: Wed, 11 Jan 2012 17:36:40 +0100
Message-Id: <1326299801-7966-3-git-send-email-drjones@redhat.com>
In-Reply-To: <1326299801-7966-1-git-send-email-drjones@redhat.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3/4 v2] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Describe dom0 support in the config menu and supply help text for it.

v2 adds 'if EXPERT' to keep it out of the "standard" menu.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..31ec975 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support" if EXPERT
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:38:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:38:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1CC-0004ns-Sp; Wed, 11 Jan 2012 16:38:40 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1Rl1CB-0004lx-5X
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:38:39 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326299863!10435290!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNDk1NTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24916 invoked from network); 11 Jan 2012 16:37:44 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 16:37: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 q0BGaq3h020614
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 11:36:52 -0500
Received: from turtle.usersys.redhat.com (dhcp-1-174.brq.redhat.com
	[10.34.1.174])
	by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0BGajIp005239; Wed, 11 Jan 2012 11:36:50 -0500
From: Andrew Jones <drjones@redhat.com>
To: konrad@darnok.org
Date: Wed, 11 Jan 2012 17:36:40 +0100
Message-Id: <1326299801-7966-3-git-send-email-drjones@redhat.com>
In-Reply-To: <1326299801-7966-1-git-send-email-drjones@redhat.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	konrad.wilk@oracle.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 3/4 v2] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Describe dom0 support in the config menu and supply help text for it.

v2 adds 'if EXPERT' to keep it out of the "standard" menu.

Signed-off-by: Andrew Jones <drjones@redhat.com>
---
 arch/x86/xen/Kconfig |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 26c731a..31ec975 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -14,9 +14,14 @@ config XEN
 	  Xen hypervisor.
 
 config XEN_DOM0
-	def_bool y
+	bool "Xen Initial Domain (Dom0) support" if EXPERT
+	default y
 	depends on XEN && PCI_XEN && SWIOTLB_XEN
 	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
+	help
+	  This allows the kernel to be used for the initial Xen domain,
+	  Domain0. This is a privileged guest that supplies backends
+	  and is used to manage the other Xen domains.
 
 # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
 # name in tools.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:51:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:51:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1O7-0005aP-8O; Wed, 11 Jan 2012 16:50:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl1O6-0005aJ-4W
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:50:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326300607!52131988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20685 invoked from network); 11 Jan 2012 16:50:07 -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;
	11 Jan 2012 16:50:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9952858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 16:50: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; Wed, 11 Jan 2012 16:50:56 +0000
Date: Wed, 11 Jan 2012 16:51:17 +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: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.00.1201111650450.3150@kaball-desktop>
References: <1326213620-20756-1-git-send-email-david.vrabel@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] ARM: support zImage kernels 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 Tue, 10 Jan 2012, David Vrabel wrote:
> These two patches add support for loading ARM kernels built as a
> zImage with an appended device tree blob (DTB)
> (CONFIG_ARM_APPENDED_DTB).  You can also use an vmlinux ELF as before.
> 
> This is required to run the latest kernels that support the Versatile
> Express with a Cortex A15 tile.  Such a kernel can be found in the
> 'vexpress-dt' branch of git://xenbits.xen.org/people/dvrabel/linux.git.
> 
> The DTB for the model is named 'vexpress-v2p-aem-v7a.dtb'.

both patches are fine, thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:51:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:51:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1O7-0005aP-8O; Wed, 11 Jan 2012 16:50:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rl1O6-0005aJ-4W
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:50:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326300607!52131988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20685 invoked from network); 11 Jan 2012 16:50:07 -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;
	11 Jan 2012 16:50:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9952858"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 16:50: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; Wed, 11 Jan 2012 16:50:56 +0000
Date: Wed, 11 Jan 2012 16:51:17 +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: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
Message-ID: <alpine.DEB.2.00.1201111650450.3150@kaball-desktop>
References: <1326213620-20756-1-git-send-email-david.vrabel@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/2] ARM: support zImage kernels 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 Tue, 10 Jan 2012, David Vrabel wrote:
> These two patches add support for loading ARM kernels built as a
> zImage with an appended device tree blob (DTB)
> (CONFIG_ARM_APPENDED_DTB).  You can also use an vmlinux ELF as before.
> 
> This is required to run the latest kernels that support the Versatile
> Express with a Cortex A15 tile.  Such a kernel can be found in the
> 'vexpress-dt' branch of git://xenbits.xen.org/people/dvrabel/linux.git.
> 
> The DTB for the model is named 'vexpress-v2p-aem-v7a.dtb'.

both patches are fine, thanks

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:59:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:59:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1Vy-0005pv-Ia; Wed, 11 Jan 2012 16:59:06 +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 1Rl1Vx-0005pq-Lk
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:59:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326301138!2770428!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 6709 invoked from network); 11 Jan 2012 16:58:59 -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; 11 Jan 2012 16:58:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rl1Vn-0006Cy-Sd; Wed, 11 Jan 2012 16:58:55 +0000
Date: Wed, 11 Jan 2012 16:58:55 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120111165855.GE81891@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
	<20120111161023.GD81891@ocelot.phlegethon.org>
	<20120111163803.GA30142@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111163803.GA30142@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl 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

At 17:38 +0100 on 11 Jan (1326303483), Olaf Hering wrote:
> On Wed, Jan 11, Tim Deegan wrote:
> 
> > > Isnt that up to the host admin to decide where to take the memory from?
> > > So if its acceptable to swap parts of a VM (independent from what the
> > > guest OS thinks it has), so be it.
> > 
> > Why?  The _only_ reason I can imagine for wanting to use paging is when
> > the balloon driver can't or won't do its job.  There's no advantage to
> > paging except that you can always force it to happen.
> 
> Isnt that the whole point of paging, to make it happen at will without
> the guest (or the application at process level) noticing it?

Yes, but that's a _bad_ thing. :)  If the guest can co-operate, you'll
get way better eviction choices, better performance, and better
accounting (since the I/O is done by the guest to guest-owned disk).

That's why I think both mechanisms should be visible up to the libxl
layer, but xl itself should just implement the one sensible policy:
try ballooning first, then page if that fails.  

Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 16:59:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 16:59:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1Vy-0005pv-Ia; Wed, 11 Jan 2012 16:59:06 +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 1Rl1Vx-0005pq-Lk
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 16:59:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326301138!2770428!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 6709 invoked from network); 11 Jan 2012 16:58:59 -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; 11 Jan 2012 16:58:59 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rl1Vn-0006Cy-Sd; Wed, 11 Jan 2012 16:58:55 +0000
Date: Wed, 11 Jan 2012 16:58:55 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120111165855.GE81891@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1111071328130.3519@kaball-desktop>
	<20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
	<20120111161023.GD81891@ocelot.phlegethon.org>
	<20120111163803.GA30142@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111163803.GA30142@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl 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

At 17:38 +0100 on 11 Jan (1326303483), Olaf Hering wrote:
> On Wed, Jan 11, Tim Deegan wrote:
> 
> > > Isnt that up to the host admin to decide where to take the memory from?
> > > So if its acceptable to swap parts of a VM (independent from what the
> > > guest OS thinks it has), so be it.
> > 
> > Why?  The _only_ reason I can imagine for wanting to use paging is when
> > the balloon driver can't or won't do its job.  There's no advantage to
> > paging except that you can always force it to happen.
> 
> Isnt that the whole point of paging, to make it happen at will without
> the guest (or the application at process level) noticing it?

Yes, but that's a _bad_ thing. :)  If the guest can co-operate, you'll
get way better eviction choices, better performance, and better
accounting (since the I/O is done by the guest to guest-owned disk).

That's why I think both mechanisms should be visible up to the libxl
layer, but xl itself should just implement the one sensible policy:
try ballooning first, then page if that fails.  

Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sH-0006Dx-KN; Wed, 11 Jan 2012 17:22:09 +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 1Rl1sG-0006Dm-9s
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326302505!52425140!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 27727 invoked from network); 11 Jan 2012 17:21:45 -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;
	11 Jan 2012 17:21:45 -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
	q0BHM5cZ019688
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Y7012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:29 -0500
Message-Id: <1326302490-19428-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 17/18] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 7b63a68..65ceb2c 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -491,7 +491,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -829,11 +829,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index b100aa4..5bf16e8 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -336,7 +336,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -413,7 +413,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -465,7 +465,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -502,7 +502,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sH-0006Dx-KN; Wed, 11 Jan 2012 17:22:09 +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 1Rl1sG-0006Dm-9s
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:08 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326302505!52425140!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 27727 invoked from network); 11 Jan 2012 17:21:45 -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;
	11 Jan 2012 17:21:45 -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
	q0BHM5cZ019688
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Y7012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:29 -0500
Message-Id: <1326302490-19428-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 17/18] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 7b63a68..65ceb2c 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -491,7 +491,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -829,11 +829,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index b100aa4..5bf16e8 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -336,7 +336,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -413,7 +413,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -465,7 +465,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -502,7 +502,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sM-0006Ff-BZ; Wed, 11 Jan 2012 17:22:14 +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 1Rl1sK-0006Dj-F9
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326302525!10597161!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 8403 invoked from network); 11 Jan 2012 17:22:05 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22:05 -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
	q0BHM4qt029359
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xs012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:16 -0500
Message-Id: <1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to use or preserve v2-only features such as sub-page grants
will produce invalid v1 grant entries, which (while they will not work)
is not a problem since a guest can always produce such invalid entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c |   38 +++++++++++++++++++++++++++++++-------
 1 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 014734d..8d4a4cb 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2126,7 +2127,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2151,15 +2152,38 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1) {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    } else if (gt->gt_version == 2) {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
-    {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1) {
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    } else if (gt->gt_version != 0 && op.version == 2) {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sM-0006Ff-BZ; Wed, 11 Jan 2012 17:22:14 +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 1Rl1sK-0006Dj-F9
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326302525!10597161!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 8403 invoked from network); 11 Jan 2012 17:22:05 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22:05 -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
	q0BHM4qt029359
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xs012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:16 -0500
Message-Id: <1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to use or preserve v2-only features such as sub-page grants
will produce invalid v1 grant entries, which (while they will not work)
is not a problem since a guest can always produce such invalid entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c |   38 +++++++++++++++++++++++++++++++-------
 1 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 014734d..8d4a4cb 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2126,7 +2127,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2151,15 +2152,38 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1) {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    } else if (gt->gt_version == 2) {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
-    {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1) {
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    } else if (gt->gt_version != 0 && op.version == 2) {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sL-0006FL-UI; Wed, 11 Jan 2012 17:22:13 +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 1Rl1sK-0006Dk-E2
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326302498!55287698!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 5732 invoked from network); 11 Jan 2012 17:21:39 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 17:21:39 -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
	q0BHM4cZ019671
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xo012565
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:12 -0500
Message-Id: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
Subject: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 allows xenstored to run in a stub domian started by
dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html


A domain configuration for starting xenstored looks like:

kernel='/home/daniel/xen/stubdom/mini-os-x86_64-xenstore/mini-os'
extra=''
memory=50
name='xenstore'

Once xenstore is started, "xenstore_dom=1" needs to be added to other
domain's configurations in order to set up the xenstore connection to
domain 1.

The following program handles post-creation parts of xenstored. To use
it, run "xl create -p xenstore" and then "init-xenstore $domid". The
running xenstored must be stopped to prevent xl using the UNIX sockets,
and xenconsoled needs to be restarted after switching xenstores.

/* init-xenstore.c: link with -lxenctrl */

#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/mman.h>

#define __XEN_TOOLS__
#include <xen/domctl.h>
#include "xenctrl.h"

#define IOCTL_XENBUS_BACKEND_SETUP _IOC(_IOC_NONE, 'B', 1, 0)
#define IOCTL_XENBUS_BACKEND_COMMIT _IOC(_IOC_NONE, 'B', 2, 0)

static void set_virq(int domid, int virq)
{
	struct xen_domctl command;
	xc_interface *xch;

	xch = xc_interface_open(NULL, NULL, 0);

	memset(&command, 0, sizeof(command)); 
	command.cmd               = XEN_DOMCTL_set_virq_handler;
	command.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
	command.domain            = domid;
	command.u.set_virq_handler.virq = virq;
	xc_domctl(xch, &command);
	xc_interface_close(xch);
}

int main(int argc, char** argv)
{
	char buf[512];
	int domid = atoi(argv[1]);

	set_virq(domid, VIRQ_DOM_EXC);

	int fd = open("/dev/xen/xenbus_backend", O_RDWR);
	void *map = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
	int rv = ioctl(fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
	*(uint16_t*)(map + 0x810) = rv;
	snprintf(buf, 512, "xl unpause %d", domid);
	system(buf);
	ioctl(fd, IOCTL_XENBUS_BACKEND_COMMIT, 0);
	return 0;
}

-------------------------------------------------

Dom0 kernel changes:
    [PATCH] xenbus: Add support for xenbus backend in stub domain

This is based on the new /dev/xen devices introduced in Linux 3.3.

Hypervisor changes:
    [PATCH 01/18] xen: reinstate previously unused
    [PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
    [PATCH 03/18] xsm: allow use of XEN_DOMCTL_getdomaininfo by
    [PATCH 04/18] xen: Preserve reserved grant entries when switching

Patch 1 & 4 are required for setting up grant entries in new domains.
Patch 2 & 3 allow xenstored to run in an unprivileged domain. This
currently requires XSM to be enabled to avoid allowing all domUs access
to XEN_DOMCTL_getdomaininfo, so the patch only allows this hypercall if
XSM is being compiled in.

Toolstack changes:
    [PATCH 05/18] tools/libxl: Add xenstore and console backend domain
    [PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and

These patches populate two of the eight reserved grant entries in new
domains with the xenstore and console shared pages, which is required
if xenstored is not run in a privileged domain.

Minios and xenstored:
    [PATCH 07/18] mini-os: avoid crash if no console is provided
    [PATCH 08/18] mini-os: avoid crash if no xenstore is provided
    [PATCH 09/18] mini-os: remove per-fd evtchn limit
    [PATCH 10/18] xenstored: use grant references instead of
    [PATCH 11/18] xenstored: add NO_SOCKETS compilation option
    [PATCH 12/18] xenstored support for in-memory rather than FS based
    [PATCH 13/18] xenstored: support running in minios stubdom
    [PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
    [PATCH 15/18] xenstored: add --event parameter for bootstrapping
    [PATCH 16/18] xenstored: pull dom0 event port from shared page
    [PATCH 17/18] xenstored: use domain_is_unprivileged instead of
    [PATCH 18/18] xenstored: add --priv-domid parameter

Support for running in a stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sU-0006Mh-1p; Wed, 11 Jan 2012 17:22:22 +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 1Rl1sR-0006Fo-T9
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326302532!10598606!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 12935 invoked from network); 11 Jan 2012 17:22:12 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-15.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 17:22:12 -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
	q0BHM4qt029358; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xq012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:14 -0500
Message-Id: <1326302490-19428-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |   10 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   63 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   18 ++++++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 18 files changed, 140 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52a63ef..c4d98d9 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -116,7 +116,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -492,7 +492,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -633,7 +633,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -659,6 +659,8 @@ static void complete_domain_destroy(struct rcu_head *head)
 
     watchdog_domain_destroy(d);
 
+    clear_global_virq_handlers(d);
+
     rangeset_domain_destroy(d);
 
     cpupool_rm_domain(d);
@@ -690,7 +692,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d6ae09b..a775aa3 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -994,6 +994,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        int virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..77c7a27 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,67 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain* global_virq_handlers[NR_VIRQS];
+
+spinlock_t global_virq_handlers_lock = SPIN_LOCK_UNLOCKED;
+
+static struct domain* _get_global_virq_handler(int virq)
+{
+    struct domain *d;
+
+    d = global_virq_handlers[virq];
+    return d != NULL ? d : dom0;
+}
+
+void send_global_virq(int virq)
+{
+    ASSERT(virq >= 0 && virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(_get_global_virq_handler(virq), virq);
+}
+
+int set_global_virq_handler(struct domain *d, int virq)
+{
+    struct domain *old;
+
+    if (virq < 0 || virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    if (old != NULL)
+        put_domain(old);
+    spin_unlock(&global_virq_handlers_lock);
+
+    return 0;
+}
+
+void clear_global_virq_handlers(struct domain *d)
+{
+    int virq;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++) {
+        if (global_virq_handlers[virq] == d) {
+            global_virq_handlers[virq] = NULL;
+            put_domain(d);
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..79b266f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -287,7 +287,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -314,7 +314,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..b1eb425 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              71
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 7e5ad7b..2df65a0 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -24,11 +24,23 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(int virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, int virq);
+
+/*
+ * clear_global_virq_handlers: Remove a domain as a handler for global VIRQs.
+ *  @d:        Domain to no longer handle global virtual IRQs
+ */
+void clear_global_virq_handlers(struct domain *d);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..c89c6ed 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, int virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, int virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..59db86d 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, int virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..a1feb8d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, int virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sL-0006FL-UI; Wed, 11 Jan 2012 17:22:13 +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 1Rl1sK-0006Dk-E2
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326302498!55287698!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 5732 invoked from network); 11 Jan 2012 17:21:39 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 17:21:39 -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
	q0BHM4cZ019671
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xo012565
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:12 -0500
Message-Id: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
Subject: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 allows xenstored to run in a stub domian started by
dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html


A domain configuration for starting xenstored looks like:

kernel='/home/daniel/xen/stubdom/mini-os-x86_64-xenstore/mini-os'
extra=''
memory=50
name='xenstore'

Once xenstore is started, "xenstore_dom=1" needs to be added to other
domain's configurations in order to set up the xenstore connection to
domain 1.

The following program handles post-creation parts of xenstored. To use
it, run "xl create -p xenstore" and then "init-xenstore $domid". The
running xenstored must be stopped to prevent xl using the UNIX sockets,
and xenconsoled needs to be restarted after switching xenstores.

/* init-xenstore.c: link with -lxenctrl */

#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <stdint.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/mman.h>

#define __XEN_TOOLS__
#include <xen/domctl.h>
#include "xenctrl.h"

#define IOCTL_XENBUS_BACKEND_SETUP _IOC(_IOC_NONE, 'B', 1, 0)
#define IOCTL_XENBUS_BACKEND_COMMIT _IOC(_IOC_NONE, 'B', 2, 0)

static void set_virq(int domid, int virq)
{
	struct xen_domctl command;
	xc_interface *xch;

	xch = xc_interface_open(NULL, NULL, 0);

	memset(&command, 0, sizeof(command)); 
	command.cmd               = XEN_DOMCTL_set_virq_handler;
	command.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
	command.domain            = domid;
	command.u.set_virq_handler.virq = virq;
	xc_domctl(xch, &command);
	xc_interface_close(xch);
}

int main(int argc, char** argv)
{
	char buf[512];
	int domid = atoi(argv[1]);

	set_virq(domid, VIRQ_DOM_EXC);

	int fd = open("/dev/xen/xenbus_backend", O_RDWR);
	void *map = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
	int rv = ioctl(fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
	*(uint16_t*)(map + 0x810) = rv;
	snprintf(buf, 512, "xl unpause %d", domid);
	system(buf);
	ioctl(fd, IOCTL_XENBUS_BACKEND_COMMIT, 0);
	return 0;
}

-------------------------------------------------

Dom0 kernel changes:
    [PATCH] xenbus: Add support for xenbus backend in stub domain

This is based on the new /dev/xen devices introduced in Linux 3.3.

Hypervisor changes:
    [PATCH 01/18] xen: reinstate previously unused
    [PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
    [PATCH 03/18] xsm: allow use of XEN_DOMCTL_getdomaininfo by
    [PATCH 04/18] xen: Preserve reserved grant entries when switching

Patch 1 & 4 are required for setting up grant entries in new domains.
Patch 2 & 3 allow xenstored to run in an unprivileged domain. This
currently requires XSM to be enabled to avoid allowing all domUs access
to XEN_DOMCTL_getdomaininfo, so the patch only allows this hypercall if
XSM is being compiled in.

Toolstack changes:
    [PATCH 05/18] tools/libxl: Add xenstore and console backend domain
    [PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and

These patches populate two of the eight reserved grant entries in new
domains with the xenstore and console shared pages, which is required
if xenstored is not run in a privileged domain.

Minios and xenstored:
    [PATCH 07/18] mini-os: avoid crash if no console is provided
    [PATCH 08/18] mini-os: avoid crash if no xenstore is provided
    [PATCH 09/18] mini-os: remove per-fd evtchn limit
    [PATCH 10/18] xenstored: use grant references instead of
    [PATCH 11/18] xenstored: add NO_SOCKETS compilation option
    [PATCH 12/18] xenstored support for in-memory rather than FS based
    [PATCH 13/18] xenstored: support running in minios stubdom
    [PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
    [PATCH 15/18] xenstored: add --event parameter for bootstrapping
    [PATCH 16/18] xenstored: pull dom0 event port from shared page
    [PATCH 17/18] xenstored: use domain_is_unprivileged instead of
    [PATCH 18/18] xenstored: add --priv-domid parameter

Support for running in a stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sU-0006NB-EP; Wed, 11 Jan 2012 17:22:22 +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 1Rl1sS-0006GG-Gi
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326302532!10446050!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 12686 invoked from network); 11 Jan 2012 17:22:13 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM5cZ019676; Wed, 11 Jan 2012 17:22: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 q0BHM4Y0012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:22 -0500
Message-Id: <1326302490-19428-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 10/18] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_domain.c |   45 ++++++++++++++++++++++++++++++++-----
 1 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..0b8353b 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -174,8 +176,12 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		if (*xcg_handle >= 0 && domain->domid != 0)
+			xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
+		else
+			munmap(domain->interface, getpagesize());
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +350,17 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		if (*xcg_handle >= 0) {
+			/* this is the preferred method */
+			interface = xc_gnttab_map_grant_ref(
+				*xcg_handle, domid,
+				GNTTAB_RESERVED_XENSTORE,
+				PROT_READ|PROT_WRITE);
+		} else {
+			interface = xc_map_foreign_range(
+				*xc_handle, domid,
+				getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		}
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +368,10 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			if (*xcg_handle >= 0)
+				xc_gnttab_munmap(*xcg_handle, interface, 1);
+			else
+				munmap(interface, getpagesize());
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +569,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +626,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sP-0006IM-LD; Wed, 11 Jan 2012 17:22:17 +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 1Rl1sM-0006Dw-IS
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326302527!8678131!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 3102 invoked from network); 11 Jan 2012 17:22:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0BHM5cZ019686
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:06 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 q0BHM4Y5012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:27 -0500
Message-Id: <1326302490-19428-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/18] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   13 ++++++++++++-
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 2d4a7e1..7b63a68 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1774,6 +1774,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1787,6 +1788,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1849,6 +1851,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index aca2149..648eb1d 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -593,8 +593,19 @@ void restore_existing_connections(void)
 }
 
 #ifdef __MINIOS__
-static inline int dom0_init(void) 
+static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sR-0006KT-Ln; Wed, 11 Jan 2012 17:22:19 +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 1Rl1sQ-0006F4-S3
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326302532!2773906!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 10402 invoked from network); 11 Jan 2012 17:22:12 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22:12 -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
	q0BHM5qt029367; Wed, 11 Jan 2012 17:22: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 q0BHM4Y2012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:24 -0500
Message-Id: <1326302490-19428-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 12/18] xenstored support for in-memory rather
	than FS based trivial DB (needed to run on mini-OS)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

tdb_copy (a xen modification to tdb?) should honor the TDB_INTERNAL flag
for in-memory databases.

TODO: leaks memory on error case

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/tdb.c |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..639ce6e 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,42 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+
+		return copy;
+intfail:
+		/* TODO (leaking memory is easier) */
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sN-0006Gm-UR; Wed, 11 Jan 2012 17:22:15 +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 1Rl1sL-0006Dp-Ku
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326302526!8555630!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 3798 invoked from network); 11 Jan 2012 17:22:06 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-16.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22:06 -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
	q0BHM5cZ019675
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Xw012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:20 -0500
Message-Id: <1326302490-19428-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/18] mini-os: avoid crash if no xenstore is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/xenbus/xenbus.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
index a8081fd..e475e2c 100644
--- a/extras/mini-os/xenbus/xenbus.c
+++ b/extras/mini-os/xenbus/xenbus.c
@@ -328,6 +328,10 @@ static int allocate_xenbus_id(void)
 void init_xenbus(void)
 {
     int err;
+    if (!start_info.store_evtchn) {
+        printk("Skipping initialization of xenbus\n");
+        return;
+    }
     printk("Initialising xenbus\n");
     DEBUG("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
@@ -435,6 +439,11 @@ xenbus_msg_reply(int type,
     DEFINE_WAIT(w);
     struct xsd_sockmsg *rep;
 
+    if (!xenstore_buf) {
+        printk("xenbus_msg_reply called but no xenstore!\n");
+        return NULL;
+    }
+
     id = allocate_xenbus_id();
     add_waiter(w, req_info[id].waitq);
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sU-0006Mh-1p; Wed, 11 Jan 2012 17:22:22 +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 1Rl1sR-0006Fo-T9
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326302532!10598606!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 12935 invoked from network); 11 Jan 2012 17:22:12 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-15.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 17:22:12 -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
	q0BHM4qt029358; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xq012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:14 -0500
Message-Id: <1326302490-19428-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |   10 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   63 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   18 ++++++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 18 files changed, 140 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52a63ef..c4d98d9 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -116,7 +116,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -492,7 +492,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -633,7 +633,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -659,6 +659,8 @@ static void complete_domain_destroy(struct rcu_head *head)
 
     watchdog_domain_destroy(d);
 
+    clear_global_virq_handlers(d);
+
     rangeset_domain_destroy(d);
 
     cpupool_rm_domain(d);
@@ -690,7 +692,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d6ae09b..a775aa3 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -994,6 +994,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        int virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..77c7a27 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,67 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain* global_virq_handlers[NR_VIRQS];
+
+spinlock_t global_virq_handlers_lock = SPIN_LOCK_UNLOCKED;
+
+static struct domain* _get_global_virq_handler(int virq)
+{
+    struct domain *d;
+
+    d = global_virq_handlers[virq];
+    return d != NULL ? d : dom0;
+}
+
+void send_global_virq(int virq)
+{
+    ASSERT(virq >= 0 && virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(_get_global_virq_handler(virq), virq);
+}
+
+int set_global_virq_handler(struct domain *d, int virq)
+{
+    struct domain *old;
+
+    if (virq < 0 || virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    if (old != NULL)
+        put_domain(old);
+    spin_unlock(&global_virq_handlers_lock);
+
+    return 0;
+}
+
+void clear_global_virq_handlers(struct domain *d)
+{
+    int virq;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++) {
+        if (global_virq_handlers[virq] == d) {
+            global_virq_handlers[virq] = NULL;
+            put_domain(d);
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..79b266f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -287,7 +287,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -314,7 +314,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..b1eb425 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              71
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 7e5ad7b..2df65a0 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -24,11 +24,23 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(int virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, int virq);
+
+/*
+ * clear_global_virq_handlers: Remove a domain as a handler for global VIRQs.
+ *  @d:        Domain to no longer handle global virtual IRQs
+ */
+void clear_global_virq_handlers(struct domain *d);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..c89c6ed 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, int virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, int virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..59db86d 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, int virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..a1feb8d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, int virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sU-0006NB-EP; Wed, 11 Jan 2012 17:22:22 +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 1Rl1sS-0006GG-Gi
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326302532!10446050!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 12686 invoked from network); 11 Jan 2012 17:22:13 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM5cZ019676; Wed, 11 Jan 2012 17:22: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 q0BHM4Y0012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:22 -0500
Message-Id: <1326302490-19428-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 10/18] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_domain.c |   45 ++++++++++++++++++++++++++++++++-----
 1 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..0b8353b 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -174,8 +176,12 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		if (*xcg_handle >= 0 && domain->domid != 0)
+			xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
+		else
+			munmap(domain->interface, getpagesize());
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +350,17 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		if (*xcg_handle >= 0) {
+			/* this is the preferred method */
+			interface = xc_gnttab_map_grant_ref(
+				*xcg_handle, domid,
+				GNTTAB_RESERVED_XENSTORE,
+				PROT_READ|PROT_WRITE);
+		} else {
+			interface = xc_map_foreign_range(
+				*xc_handle, domid,
+				getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		}
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +368,10 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			if (*xcg_handle >= 0)
+				xc_gnttab_munmap(*xcg_handle, interface, 1);
+			else
+				munmap(interface, getpagesize());
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +569,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +626,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sP-0006IM-LD; Wed, 11 Jan 2012 17:22:17 +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 1Rl1sM-0006Dw-IS
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326302527!8678131!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 3102 invoked from network); 11 Jan 2012 17:22:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0BHM5cZ019686
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:06 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 q0BHM4Y5012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:27 -0500
Message-Id: <1326302490-19428-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/18] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   13 ++++++++++++-
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 2d4a7e1..7b63a68 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1774,6 +1774,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1787,6 +1788,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1849,6 +1851,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index aca2149..648eb1d 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -593,8 +593,19 @@ void restore_existing_connections(void)
 }
 
 #ifdef __MINIOS__
-static inline int dom0_init(void) 
+static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sN-0006GT-H1; Wed, 11 Jan 2012 17:22: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 1Rl1sL-0006Do-Cq
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326302526!10512801!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 24585 invoked from network); 11 Jan 2012 17:22: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;
	11 Jan 2012 17:22: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
	q0BHM5qt029372
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Y4012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:26 -0500
Message-Id: <1326302490-19428-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 14/18] xenstored: always use xc_gnttab_munmap in
	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>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/xenstore/xenstored_domain.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 811ae3c..aca2149 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -177,10 +177,14 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
+#else
 		if (*xcg_handle >= 0 && domain->domid != 0)
 			xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
 		else
 			munmap(domain->interface, getpagesize());
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sN-0006Gm-UR; Wed, 11 Jan 2012 17:22:15 +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 1Rl1sL-0006Dp-Ku
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326302526!8555630!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 3798 invoked from network); 11 Jan 2012 17:22:06 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-16.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22:06 -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
	q0BHM5cZ019675
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Xw012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:20 -0500
Message-Id: <1326302490-19428-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/18] mini-os: avoid crash if no xenstore is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/xenbus/xenbus.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
index a8081fd..e475e2c 100644
--- a/extras/mini-os/xenbus/xenbus.c
+++ b/extras/mini-os/xenbus/xenbus.c
@@ -328,6 +328,10 @@ static int allocate_xenbus_id(void)
 void init_xenbus(void)
 {
     int err;
+    if (!start_info.store_evtchn) {
+        printk("Skipping initialization of xenbus\n");
+        return;
+    }
     printk("Initialising xenbus\n");
     DEBUG("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
@@ -435,6 +439,11 @@ xenbus_msg_reply(int type,
     DEFINE_WAIT(w);
     struct xsd_sockmsg *rep;
 
+    if (!xenstore_buf) {
+        printk("xenbus_msg_reply called but no xenstore!\n");
+        return NULL;
+    }
+
     id = allocate_xenbus_id();
     add_waiter(w, req_info[id].waitq);
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sR-0006KT-Ln; Wed, 11 Jan 2012 17:22:19 +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 1Rl1sQ-0006F4-S3
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326302532!2773906!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 10402 invoked from network); 11 Jan 2012 17:22:12 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22:12 -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
	q0BHM5qt029367; Wed, 11 Jan 2012 17:22: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 q0BHM4Y2012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:24 -0500
Message-Id: <1326302490-19428-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 12/18] xenstored support for in-memory rather
	than FS based trivial DB (needed to run on mini-OS)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

tdb_copy (a xen modification to tdb?) should honor the TDB_INTERNAL flag
for in-memory databases.

TODO: leaks memory on error case

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/tdb.c |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..639ce6e 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,42 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+
+		return copy;
+intfail:
+		/* TODO (leaking memory is easier) */
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sV-0006Oo-7c; Wed, 11 Jan 2012 17:22:23 +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 1Rl1sS-0006GI-Hr
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326302532!8734749!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 11879 invoked from network); 11 Jan 2012 17:22:13 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM5cZ019673; Wed, 11 Jan 2012 17:22: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 q0BHM4Xu012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:18 -0500
Message-Id: <1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 06/18] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

This has not been tested with any kind of migration.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  164 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   17 ++++
 tools/libxc/xc_hvm_build.c        |    1 +
 tools/libxl/libxl_dom.c           |   17 ++++-
 tools/libxl/libxl_internal.h      |    2 +
 xen/include/public/grant_table.h  |    6 ++
 8 files changed, 220 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..1a55a6d 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    DECLARE_HYPERCALL;
+    gnttab_setup_table_t setup_table;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+	unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+	if (gmfnp == NULL)
+		return -1;
+
+    setup_table.dom = domid;
+    setup_table.nr_frames = 1;
+    set_xen_guest_handle(setup_table.frame_list, gmfnp);
+    setup_table.status = 0;
+
+    hypercall.op = __HYPERVISOR_grant_table_op;
+    hypercall.arg[0] = GNTTABOP_setup_table;
+    hypercall.arg[1] = (unsigned long) &setup_table;
+    hypercall.arg[2] = 1;
+
+    rc = do_xen_hypercall(xch, &hypercall);
+	gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup_table.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup_table.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0, /* TODO: what's this? */
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+    .domid = domid,
+    .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..23619da 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -2018,6 +2018,15 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+/* TODO don't hardcode zero here */
+    rc = xc_dom_gnttab_seed(xch, dom,
+                            *console_mfn, *store_mfn, 0, 0);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+	/* TODO don't hardcode zero here */
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn, 0, 0);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 9831bab..453f8a5 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -24,6 +24,7 @@
 
 #include "xg_private.h"
 #include "xc_private.h"
+#include "xc_dom.h"
 
 #include <xen/foreign/x86_32.h>
 #include <xen/foreign/x86_64.h>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e12d687..7f7bca6 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -104,7 +104,9 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
+    state->store_domid = info->xenstore_dom;
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, info->xenstore_dom);
+    state->console_domid = info->console_dom;
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, info->console_dom);
     state->vm_generationid_addr = 0;
     return 0;
@@ -223,7 +225,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -249,6 +253,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -262,7 +270,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -295,6 +304,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -348,7 +359,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 288c03c..97ead08 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -219,9 +219,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..36d1ac7 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,12 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* External tools reserve first few grant table entries. */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+/* (the next 6 are reserved for future use) */
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sO-0006H5-BK; Wed, 11 Jan 2012 17:22:16 +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 1Rl1sL-0006Dv-Vz
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326302527!10617506!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 27508 invoked from network); 11 Jan 2012 17:22:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 17:22:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0BHM6cZ019707
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:06 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 q0BHM4Y8012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:30 -0500
Message-Id: <1326302490-19428-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/18] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 65ceb2c..4437c8d 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1777,6 +1777,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1789,6 +1790,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1854,6 +1856,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 5bf16e8..ba9a5ef 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sM-0006Fx-Na; Wed, 11 Jan 2012 17:22:14 +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 1Rl1sL-0006Dn-7u
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326302526!7392860!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 11787 invoked from network); 11 Jan 2012 17:22:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0BHM5cZ019687
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Y6012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:28 -0500
Message-Id: <1326302490-19428-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 16/18] xenstored: pull dom0 event port from
	shared 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>
MIME-Version: 1.0
Content-Type: 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 building the xenstored domain using xl, it is difficult to specify
the event channel number on the command line because the command line is
parsed prior to domain creation, while the event channel cannot be
created until after domain creation. To avoid needing a special domain
builder for the xenstore domain, store the event channel port in an
unused field of the shared page.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_domain.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 648eb1d..b100aa4 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -598,10 +598,18 @@ static int dom0_init(void)
 	struct domain *domain;
 	int domid = 0;
 	evtchn_port_t port = dom0_event;
+	void *interface;
 
-	domain = new_domain(NULL, domid, port);
-	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+	interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
 			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+
+	if (!port) {
+		port = *(uint16_t*)(interface +
+			sizeof(struct xenstore_domain_interface));
+	}
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = interface;
 	talloc_steal(domain->conn, domain);
 
 	xc_evtchn_notify(xce_handle, domain->port);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sN-0006GT-H1; Wed, 11 Jan 2012 17:22: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 1Rl1sL-0006Do-Cq
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326302526!10512801!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 24585 invoked from network); 11 Jan 2012 17:22: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;
	11 Jan 2012 17:22: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
	q0BHM5qt029372
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Y4012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:26 -0500
Message-Id: <1326302490-19428-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 14/18] xenstored: always use xc_gnttab_munmap in
	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>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/xenstore/xenstored_domain.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 811ae3c..aca2149 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -177,10 +177,14 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
+#else
 		if (*xcg_handle >= 0 && domain->domid != 0)
 			xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
 		else
 			munmap(domain->interface, getpagesize());
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sV-0006Oo-7c; Wed, 11 Jan 2012 17:22:23 +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 1Rl1sS-0006GI-Hr
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326302532!8734749!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 11879 invoked from network); 11 Jan 2012 17:22:13 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM5cZ019673; Wed, 11 Jan 2012 17:22: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 q0BHM4Xu012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:18 -0500
Message-Id: <1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 06/18] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

This has not been tested with any kind of migration.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  164 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   17 ++++
 tools/libxc/xc_hvm_build.c        |    1 +
 tools/libxl/libxl_dom.c           |   17 ++++-
 tools/libxl/libxl_internal.h      |    2 +
 xen/include/public/grant_table.h  |    6 ++
 8 files changed, 220 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..1a55a6d 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    DECLARE_HYPERCALL;
+    gnttab_setup_table_t setup_table;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+	unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+	if (gmfnp == NULL)
+		return -1;
+
+    setup_table.dom = domid;
+    setup_table.nr_frames = 1;
+    set_xen_guest_handle(setup_table.frame_list, gmfnp);
+    setup_table.status = 0;
+
+    hypercall.op = __HYPERVISOR_grant_table_op;
+    hypercall.arg[0] = GNTTABOP_setup_table;
+    hypercall.arg[1] = (unsigned long) &setup_table;
+    hypercall.arg[2] = 1;
+
+    rc = do_xen_hypercall(xch, &hypercall);
+	gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup_table.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup_table.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0, /* TODO: what's this? */
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+    .domid = domid,
+    .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..23619da 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -2018,6 +2018,15 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+/* TODO don't hardcode zero here */
+    rc = xc_dom_gnttab_seed(xch, dom,
+                            *console_mfn, *store_mfn, 0, 0);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+	/* TODO don't hardcode zero here */
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn, 0, 0);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 9831bab..453f8a5 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -24,6 +24,7 @@
 
 #include "xg_private.h"
 #include "xc_private.h"
+#include "xc_dom.h"
 
 #include <xen/foreign/x86_32.h>
 #include <xen/foreign/x86_64.h>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e12d687..7f7bca6 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -104,7 +104,9 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
+    state->store_domid = info->xenstore_dom;
     state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, info->xenstore_dom);
+    state->console_domid = info->console_dom;
     state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, info->console_dom);
     state->vm_generationid_addr = 0;
     return 0;
@@ -223,7 +225,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -249,6 +253,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -262,7 +270,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -295,6 +304,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -348,7 +359,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 288c03c..97ead08 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -219,9 +219,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..36d1ac7 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,12 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* External tools reserve first few grant table entries. */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+/* (the next 6 are reserved for future use) */
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sO-0006H5-BK; Wed, 11 Jan 2012 17:22:16 +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 1Rl1sL-0006Dv-Vz
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326302527!10617506!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 27508 invoked from network); 11 Jan 2012 17:22:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 17:22:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0BHM6cZ019707
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:06 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 q0BHM4Y8012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:30 -0500
Message-Id: <1326302490-19428-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/18] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 65ceb2c..4437c8d 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1777,6 +1777,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1789,6 +1790,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1854,6 +1856,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 5bf16e8..ba9a5ef 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sM-0006Fx-Na; Wed, 11 Jan 2012 17:22:14 +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 1Rl1sL-0006Dn-7u
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326302526!7392860!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 11787 invoked from network); 11 Jan 2012 17:22:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0BHM5cZ019687
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Y6012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:28 -0500
Message-Id: <1326302490-19428-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 16/18] xenstored: pull dom0 event port from
	shared 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>
MIME-Version: 1.0
Content-Type: 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 building the xenstored domain using xl, it is difficult to specify
the event channel number on the command line because the command line is
parsed prior to domain creation, while the event channel cannot be
created until after domain creation. To avoid needing a special domain
builder for the xenstore domain, store the event channel port in an
unused field of the shared page.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_domain.c |   12 ++++++++++--
 1 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 648eb1d..b100aa4 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -598,10 +598,18 @@ static int dom0_init(void)
 	struct domain *domain;
 	int domid = 0;
 	evtchn_port_t port = dom0_event;
+	void *interface;
 
-	domain = new_domain(NULL, domid, port);
-	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+	interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
 			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+
+	if (!port) {
+		port = *(uint16_t*)(interface +
+			sizeof(struct xenstore_domain_interface));
+	}
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = interface;
 	talloc_steal(domain->conn, domain);
 
 	xc_evtchn_notify(xce_handle, domain->port);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sU-0006O7-Qm; Wed, 11 Jan 2012 17:22:22 +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 1Rl1sS-0006GH-Gz
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326302532!8746614!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 27031 invoked from network); 11 Jan 2012 17:22:13 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM5cZ019674; Wed, 11 Jan 2012 17:22: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 q0BHM4Xx012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:21 -0500
Message-Id: <1326302490-19428-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/18] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Changes the minios evtchn implementation to use a list instead of an array.
This allows it to grow as necessary to support any number of ports.
Unfortunately, it's still limited by NR_EVS in events.c.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sQ-0006Iz-93; Wed, 11 Jan 2012 17:22:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rl1sP-0006FU-IS
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326302498!47994584!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 3421 invoked from network); 11 Jan 2012 17:21:38 -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;
	11 Jan 2012 17:21:38 -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
	q0BHM4qt029357; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xp012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:13 -0500
Message-Id: <1326302490-19428-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/ia64/xen/mm.c          |   34 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm.c               |   35 +++++++++++++++++++++++++++++++++++
 xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
 xen/include/public/memory.h     |   16 ++++++++++++++++
 xen/include/xlat.lst            |    1 +
 xen/include/xsm/xsm.h           |    6 ++++++
 xen/xsm/dummy.c                 |    6 ++++++
 xen/xsm/flask/hooks.c           |    6 ++++++
 8 files changed, 118 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
index 694bf95..1b42e25 100644
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3447,6 +3447,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = gmfn_to_mfn(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
+
     case XENMEM_machine_memory_map:
     {
         struct xen_memory_map memmap;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 52222dd..0b5332b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4871,6 +4871,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         return rc;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     case XENMEM_set_memory_map:
     {
         struct xen_foreign_memory_map fmap;
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index bea94fe..dde5430 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -82,6 +82,20 @@ int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct compat_remove_from_physmap cmp;
+        struct xen_remove_from_physmap *nat = (void *)COMPAT_ARG_XLAT_VIRT_BASE;
+
+        if ( copy_from_guest(&cmp, arg, 1) )
+            return -EFAULT;
+
+        XLAT_remove_from_physmap(nat, &cmp);
+        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
+
+        break;
+    }
+
     case XENMEM_set_memory_map:
     {
         struct compat_foreign_memory_map cmp;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..9e67259 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -54,6 +54,7 @@
 !	kexec_image			kexec.h
 !	kexec_range			kexec.h
 !	add_to_physmap			memory.h
+!	remove_from_physmap		memory.h
 !	foreign_memory_map		memory.h
 !	memory_exchange			memory.h
 !	memory_map			memory.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sJ-0006EO-4w; Wed, 11 Jan 2012 17:22:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rl1sI-0006Dh-BQ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326302475!52136161!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 8756 invoked from network); 11 Jan 2012 17:21:16 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 17:21:16 -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
	q0BHM4cZ019672
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xr012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:15 -0500
Message-Id: <1326302490-19428-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/18] xsm: allow use of
	XEN_DOMCTL_getdomaininfo by non-IS_PRIV 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>
MIME-Version: 1.0
Content-Type: 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 domctl does not allow manipulation of domains, only basic
information such as size and state. XSM modules can also provide
fine-grained control over what domains are visible to domains that call
getdomaininfo.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a775aa3..2c1ca85 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sU-0006O7-Qm; Wed, 11 Jan 2012 17:22:22 +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 1Rl1sS-0006GH-Gz
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326302532!8746614!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 27031 invoked from network); 11 Jan 2012 17:22:13 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM5cZ019674; Wed, 11 Jan 2012 17:22: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 q0BHM4Xx012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:21 -0500
Message-Id: <1326302490-19428-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/18] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Changes the minios evtchn implementation to use a list instead of an array.
This allows it to grow as necessary to support any number of ports.
Unfortunately, it's still limited by NR_EVS in events.c.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sJ-0006EO-4w; Wed, 11 Jan 2012 17:22:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rl1sI-0006Dh-BQ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:10 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326302475!52136161!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 8756 invoked from network); 11 Jan 2012 17:21:16 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 17:21:16 -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
	q0BHM4cZ019672
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xr012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:15 -0500
Message-Id: <1326302490-19428-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/18] xsm: allow use of
	XEN_DOMCTL_getdomaininfo by non-IS_PRIV 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>
MIME-Version: 1.0
Content-Type: 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 domctl does not allow manipulation of domains, only basic
information such as size and state. XSM modules can also provide
fine-grained control over what domains are visible to domains that call
getdomaininfo.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index a775aa3..2c1ca85 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:22:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1sQ-0006Iz-93; Wed, 11 Jan 2012 17:22:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rl1sP-0006FU-IS
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326302498!47994584!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 3421 invoked from network); 11 Jan 2012 17:21:38 -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;
	11 Jan 2012 17:21:38 -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
	q0BHM4qt029357; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xp012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:13 -0500
Message-Id: <1326302490-19428-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/ia64/xen/mm.c          |   34 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm.c               |   35 +++++++++++++++++++++++++++++++++++
 xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
 xen/include/public/memory.h     |   16 ++++++++++++++++
 xen/include/xlat.lst            |    1 +
 xen/include/xsm/xsm.h           |    6 ++++++
 xen/xsm/dummy.c                 |    6 ++++++
 xen/xsm/flask/hooks.c           |    6 ++++++
 8 files changed, 118 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
index 694bf95..1b42e25 100644
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3447,6 +3447,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = gmfn_to_mfn(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
+
     case XENMEM_machine_memory_map:
     {
         struct xen_memory_map memmap;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 52222dd..0b5332b 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4871,6 +4871,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         return rc;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     case XENMEM_set_memory_map:
     {
         struct xen_foreign_memory_map fmap;
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index bea94fe..dde5430 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -82,6 +82,20 @@ int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct compat_remove_from_physmap cmp;
+        struct xen_remove_from_physmap *nat = (void *)COMPAT_ARG_XLAT_VIRT_BASE;
+
+        if ( copy_from_guest(&cmp, arg, 1) )
+            return -EFAULT;
+
+        XLAT_remove_from_physmap(nat, &cmp);
+        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
+
+        break;
+    }
+
     case XENMEM_set_memory_map:
     {
         struct compat_foreign_memory_map cmp;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..9e67259 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -54,6 +54,7 @@
 !	kexec_image			kexec.h
 !	kexec_range			kexec.h
 !	add_to_physmap			memory.h
+!	remove_from_physmap		memory.h
 !	foreign_memory_map		memory.h
 !	memory_exchange			memory.h
 !	memory_map			memory.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sP-0006Hj-4b; Wed, 11 Jan 2012 17:22:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rl1sM-0006FF-5B
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326302505!55287711!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 5922 invoked from network); 11 Jan 2012 17:21:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 17:21:45 -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
	q0BHM5cZ019677; Wed, 11 Jan 2012 17:22: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 q0BHM4Y1012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:23 -0500
Message-Id: <1326302490-19428-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 11/18] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

option for compiling xenstored without unix sockets to support running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c |   35 +++++++++++++++++++++++++++++++----
 tools/xenstore/xs.c             |    2 ++
 tools/xenstore/xs_lib.c         |    4 ++++
 3 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..0623aac 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -308,7 +310,10 @@ static void set_fd(int fd, fd_set *set, int *max)
 }
 
 
-static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
+static int initialize_set(fd_set *inset, fd_set *outset,
+#ifndef NO_SOCKETS
+			  int sock, int ro_sock,
+#endif
 			  struct timeval **ptimeout)
 {
 	static struct timeval zero_timeout = { 0 };
@@ -320,8 +325,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
+#ifndef NO_SOCKETS
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
+#endif
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -343,12 +350,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
+#ifndef NO_SOCKETS
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
 	close(*fd);
 	return 0;
 }
+#endif
 
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
@@ -1352,6 +1361,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifndef NO_SOCKETS
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1406,6 +1416,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1752,8 +1763,11 @@ extern void dump_conn(struct connection *conn);
 
 int main(int argc, char *argv[])
 {
-	int opt, *sock, *ro_sock, max;
+	int opt, max;
+#ifndef NO_SOCKETS
+	int *sock, *ro_sock;
 	struct sockaddr_un addr;
+#endif
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,6 +1851,7 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
+#ifndef NO_SOCKETS
 	/* Create sockets for them to listen to. */
 	sock = talloc(talloc_autofree_context(), int);
 	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
@@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
 		barf_perror("Could not create socket");
 	talloc_set_destructor(sock, destroy_fd);
 	talloc_set_destructor(ro_sock, destroy_fd);
+#endif
 
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
+#ifndef NO_SOCKETS
 	/* FIXME: Be more sophisticated, don't mug running daemon. */
 	unlink(xs_daemon_socket());
 	unlink(xs_daemon_socket_ro());
@@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
 	if (listen(*sock, 1) != 0
 	    || listen(*ro_sock, 1) != 0)
 		barf_perror("Could not listen on sockets");
+#endif
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
@@ -1909,7 +1927,11 @@ int main(int argc, char *argv[])
 		evtchn_fd = xc_evtchn_fd(xce_handle);
 
 	/* Get ready to listen to the tools. */
+#ifndef NO_SOCKETS
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
+#else
+	max = initialize_set(&inset, &outset, &timeout);
+#endif
 
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
@@ -1931,11 +1953,13 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
+#ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
 		if (FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
+#endif
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
 			handle_event();
@@ -1977,7 +2001,10 @@ int main(int argc, char *argv[])
 			}
 		}
 
-		max = initialize_set(&inset, &outset, *sock, *ro_sock,
+		max = initialize_set(&inset, &outset,
+#ifndef NO_SOCKETS
+				     *sock, *ro_sock,
+#endif
 				     &timeout);
 	}
 }
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index 8e54fe0..119d945 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
 {
 	struct xs_handle *xsh = NULL;
 
+#ifndef NO_SOCKETS
 	if (flags & XS_OPEN_READONLY)
 		xsh = get_handle(xs_daemon_socket_ro());
 	else
 		xsh = get_handle(xs_daemon_socket());
+#endif
 
 	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
 		xsh = get_handle(xs_domain_dev());
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
index 03a9ee4..af3db6b 100644
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
 	return (s ? s : "/var/run/xenstored");
 }
 
+#ifndef NO_SOCKETS
 static const char *xs_daemon_path(void)
 {
 	static char buf[PATH_MAX];
@@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_daemon_tdb(void)
 {
@@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
 	return buf;
 }
 
+#ifndef NO_SOCKETS
 const char *xs_daemon_socket(void)
 {
 	return xs_daemon_path();
@@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_domain_dev(void)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sL-0006F7-IM; Wed, 11 Jan 2012 17:22:13 +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 1Rl1sK-0006Di-9H
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326302525!8185399!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 9342 invoked from network); 11 Jan 2012 17:22:06 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM5qt029362
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Xv012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:19 -0500
Message-Id: <1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 07/18] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..14a8bd1 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+    if (!intf)
+        return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sO-0006HR-NS; Wed, 11 Jan 2012 17:22:16 +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 1Rl1sL-0006Du-Vi
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326302526!11966396!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 22587 invoked from network); 11 Jan 2012 17:22:06 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 17:22:06 -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
	q0BHM5cZ019685
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Y3012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:25 -0500
Message-Id: <1326302490-19428-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Originally-by: Diego Ongaro <diego.ongaro@citrix.com>
Originally-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h          |    6 ++--
 extras/mini-os/main.c                  |    4 +++
 stubdom/Makefile                       |   29 +++++++++++++++++--
 tools/xenstore/Makefile                |    9 +++++-
 tools/xenstore/tdb.c                   |    6 ++--
 tools/xenstore/utils.h                 |    2 +
 tools/xenstore/xenstored_core.c        |   47 ++++++++++++++++++++++++++++++-
 tools/xenstore/xenstored_domain.c      |    7 +++++
 tools/xenstore/xenstored_transaction.c |    2 +
 9 files changed, 100 insertions(+), 12 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..cd89849 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -60,6 +60,7 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
+#ifndef CONFIG_XENSTORE
 #ifndef CONFIG_GRUB
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
@@ -67,6 +68,7 @@ static void call_main(void *p)
 #endif
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU
     /* Fetch argc, argv from XenStore */
@@ -169,9 +171,11 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
+#ifndef CONFIG_XENSTORE
 #ifdef HAVE_LWIP
     stop_networking();
 #endif
+#endif
     stop_kernel();
     if (!ret) {
 	/* No problem, just shutdown.  */
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 3705059..e0a90a9 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_XENSTORE $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..3a061d6 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 639ce6e..75ffd2a 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 
 		/* Iterate through chain */
 		while( tlock->off) {
-			tdb_off current;
+			tdb_off mycurrent;
 			if (rec_read(tdb, tlock->off, rec) == -1)
 				goto fail;
 
@@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 			}
 
 			/* Try to clean dead ones from old traverses */
-			current = tlock->off;
+			mycurrent = tlock->off;
 			tlock->off = rec->next;
 			if (!tdb->read_only && 
-			    do_delete(tdb, current, rec) != 0)
+			    do_delete(tdb, mycurrent, rec) != 0)
 				goto fail;
 		}
 		tdb_unlock(tdb, tlock->hash, F_WRLCK);
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0623aac..2d4a7e1 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -32,7 +32,9 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#ifndef NO_SYSLOG
 #include <syslog.h>
+#endif
 #include <string.h>
 #include <errno.h>
 #include <dirent.h>
@@ -61,13 +63,24 @@ LIST_HEAD(connections);
 static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
+#ifndef NO_REOPEN_LOG
 static int reopen_log_pipe[2];
+#endif
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
 
+#ifdef __MINIOS__
+#define lockf(...) (-ENOSYS)
+#endif
+
+#ifdef NO_SYSLOG
+#define openlog(...) ((void) 0)
+#define syslog(...)  ((void) 0)
+#endif
+
 #define log(...)							\
 	do {								\
 		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
@@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
+#ifndef __MINIOS__
 	if (rename(newname, xs_daemon_tdb()) != 0)
 		return false;
+#endif
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -195,6 +210,7 @@ void trace_destroy(const void *data, const char *type)
 	trace("DESTROY %s %p\n", type, data);
 }
 
+#ifndef NO_REOPEN_LOG
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
@@ -222,7 +238,7 @@ static void reopen_log(void)
 			trace("\n***\n");
 	}
 }
-
+#endif
 
 static bool write_messages(struct connection *conn)
 {
@@ -329,7 +345,9 @@ static int initialize_set(fd_set *inset, fd_set *outset,
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
 #endif
+#ifndef NO_REOPEN_LOG
 	set_fd(reopen_log_pipe[0], inset, &max);
+#endif
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1418,7 +1436,11 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
+#ifdef __MINIOS__
+#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
+#else
 #define TDB_FLAGS 0
+#endif
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1443,7 +1465,11 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
+#ifdef __MINIOS__
+	tdb_ctx = NULL;
+#else
 	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+#endif
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1669,6 +1695,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifndef __MINIOS__
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1715,7 +1742,7 @@ static void daemonize(void)
 	/* Discard our parent's old-fashioned umask prejudices. */
 	umask(0);
 }
-
+#endif
 
 static void usage(void)
 {
@@ -1769,7 +1796,11 @@ int main(int argc, char *argv[])
 	struct sockaddr_un addr;
 #endif
 	fd_set inset, outset;
+#ifdef __MINIOS__
+	bool dofork = false;
+#else
 	bool dofork = true;
+#endif
 	bool outputpid = false;
 	bool no_domain_init = false;
 	const char *pidfile = NULL;
@@ -1823,8 +1854,11 @@ int main(int argc, char *argv[])
 	if (optind != argc)
 		barf("%s: No arguments desired", argv[0]);
 
+#ifndef NO_REOPEN_LOG
 	reopen_log();
+#endif
 
+#ifndef __MINIOS__
 	/* make sure xenstored directory exists */
 	if (mkdir(xs_daemon_rundir(), 0755)) {
 		if (errno != EEXIST) {
@@ -1846,6 +1880,7 @@ int main(int argc, char *argv[])
 	}
 	if (pidfile)
 		write_pidfile(pidfile);
+#endif
 
 	/* Talloc leak reports go to stderr, which is closed if we fork. */
 	if (!dofork)
@@ -1890,9 +1925,11 @@ int main(int argc, char *argv[])
 		barf_perror("Could not listen on sockets");
 #endif
 
+#ifndef NO_REOPEN_LOG
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1921,7 +1958,9 @@ int main(int argc, char *argv[])
 		xprintf = trace;
 	}
 
+#ifndef NO_REOPEN_LOG
 	signal(SIGHUP, trigger_reopen_log);
+#endif
 
 	if (xce_handle != NULL)
 		evtchn_fd = xc_evtchn_fd(xce_handle);
@@ -1933,8 +1972,10 @@ int main(int argc, char *argv[])
 	max = initialize_set(&inset, &outset, &timeout);
 #endif
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1946,12 +1987,14 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
+#ifndef NO_REOPEN_LOG
 		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
 			reopen_log();
 		}
+#endif
 
 #ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 0b8353b..811ae3c 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -588,6 +588,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static inline int dom0_init(void) 
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -611,6 +617,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
index 380c691..c59acfb 100644
--- a/tools/xenstore/xenstored_transaction.c
+++ b/tools/xenstore/xenstored_transaction.c
@@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
 	trace_destroy(trans, "transaction");
 	if (trans->tdb)
 		tdb_close(trans->tdb);
+#ifndef __MINIOS__
 	unlink(trans->tdb_name);
+#endif
 	return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sP-0006Hj-4b; Wed, 11 Jan 2012 17:22:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rl1sM-0006FF-5B
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326302505!55287711!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 5922 invoked from network); 11 Jan 2012 17:21:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 17:21:45 -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
	q0BHM5cZ019677; Wed, 11 Jan 2012 17:22: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 q0BHM4Y1012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:23 -0500
Message-Id: <1326302490-19428-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 11/18] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

option for compiling xenstored without unix sockets to support running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c |   35 +++++++++++++++++++++++++++++++----
 tools/xenstore/xs.c             |    2 ++
 tools/xenstore/xs_lib.c         |    4 ++++
 3 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..0623aac 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -308,7 +310,10 @@ static void set_fd(int fd, fd_set *set, int *max)
 }
 
 
-static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
+static int initialize_set(fd_set *inset, fd_set *outset,
+#ifndef NO_SOCKETS
+			  int sock, int ro_sock,
+#endif
 			  struct timeval **ptimeout)
 {
 	static struct timeval zero_timeout = { 0 };
@@ -320,8 +325,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
+#ifndef NO_SOCKETS
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
+#endif
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -343,12 +350,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
+#ifndef NO_SOCKETS
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
 	close(*fd);
 	return 0;
 }
+#endif
 
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
@@ -1352,6 +1361,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifndef NO_SOCKETS
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1406,6 +1416,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1752,8 +1763,11 @@ extern void dump_conn(struct connection *conn);
 
 int main(int argc, char *argv[])
 {
-	int opt, *sock, *ro_sock, max;
+	int opt, max;
+#ifndef NO_SOCKETS
+	int *sock, *ro_sock;
 	struct sockaddr_un addr;
+#endif
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,6 +1851,7 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
+#ifndef NO_SOCKETS
 	/* Create sockets for them to listen to. */
 	sock = talloc(talloc_autofree_context(), int);
 	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
@@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
 		barf_perror("Could not create socket");
 	talloc_set_destructor(sock, destroy_fd);
 	talloc_set_destructor(ro_sock, destroy_fd);
+#endif
 
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
+#ifndef NO_SOCKETS
 	/* FIXME: Be more sophisticated, don't mug running daemon. */
 	unlink(xs_daemon_socket());
 	unlink(xs_daemon_socket_ro());
@@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
 	if (listen(*sock, 1) != 0
 	    || listen(*ro_sock, 1) != 0)
 		barf_perror("Could not listen on sockets");
+#endif
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
@@ -1909,7 +1927,11 @@ int main(int argc, char *argv[])
 		evtchn_fd = xc_evtchn_fd(xce_handle);
 
 	/* Get ready to listen to the tools. */
+#ifndef NO_SOCKETS
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
+#else
+	max = initialize_set(&inset, &outset, &timeout);
+#endif
 
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
@@ -1931,11 +1953,13 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
+#ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
 		if (FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
+#endif
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
 			handle_event();
@@ -1977,7 +2001,10 @@ int main(int argc, char *argv[])
 			}
 		}
 
-		max = initialize_set(&inset, &outset, *sock, *ro_sock,
+		max = initialize_set(&inset, &outset,
+#ifndef NO_SOCKETS
+				     *sock, *ro_sock,
+#endif
 				     &timeout);
 	}
 }
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index 8e54fe0..119d945 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
 {
 	struct xs_handle *xsh = NULL;
 
+#ifndef NO_SOCKETS
 	if (flags & XS_OPEN_READONLY)
 		xsh = get_handle(xs_daemon_socket_ro());
 	else
 		xsh = get_handle(xs_daemon_socket());
+#endif
 
 	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
 		xsh = get_handle(xs_domain_dev());
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
index 03a9ee4..af3db6b 100644
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
 	return (s ? s : "/var/run/xenstored");
 }
 
+#ifndef NO_SOCKETS
 static const char *xs_daemon_path(void)
 {
 	static char buf[PATH_MAX];
@@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_daemon_tdb(void)
 {
@@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
 	return buf;
 }
 
+#ifndef NO_SOCKETS
 const char *xs_daemon_socket(void)
 {
 	return xs_daemon_path();
@@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_domain_dev(void)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sL-0006F7-IM; Wed, 11 Jan 2012 17:22:13 +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 1Rl1sK-0006Di-9H
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326302525!8185399!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 9342 invoked from network); 11 Jan 2012 17:22:06 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM5qt029362
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Xv012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:19 -0500
Message-Id: <1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 07/18] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..14a8bd1 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+    if (!intf)
+        return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sO-0006HR-NS; Wed, 11 Jan 2012 17:22:16 +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 1Rl1sL-0006Du-Vi
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326302526!11966396!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 22587 invoked from network); 11 Jan 2012 17:22:06 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 17:22:06 -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
	q0BHM5cZ019685
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22: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 q0BHM4Y3012565; 
	Wed, 11 Jan 2012 12:22:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:25 -0500
Message-Id: <1326302490-19428-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Originally-by: Diego Ongaro <diego.ongaro@citrix.com>
Originally-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h          |    6 ++--
 extras/mini-os/main.c                  |    4 +++
 stubdom/Makefile                       |   29 +++++++++++++++++--
 tools/xenstore/Makefile                |    9 +++++-
 tools/xenstore/tdb.c                   |    6 ++--
 tools/xenstore/utils.h                 |    2 +
 tools/xenstore/xenstored_core.c        |   47 ++++++++++++++++++++++++++++++-
 tools/xenstore/xenstored_domain.c      |    7 +++++
 tools/xenstore/xenstored_transaction.c |    2 +
 9 files changed, 100 insertions(+), 12 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..cd89849 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -60,6 +60,7 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
+#ifndef CONFIG_XENSTORE
 #ifndef CONFIG_GRUB
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
@@ -67,6 +68,7 @@ static void call_main(void *p)
 #endif
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU
     /* Fetch argc, argv from XenStore */
@@ -169,9 +171,11 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
+#ifndef CONFIG_XENSTORE
 #ifdef HAVE_LWIP
     stop_networking();
 #endif
+#endif
     stop_kernel();
     if (!ret) {
 	/* No problem, just shutdown.  */
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 3705059..e0a90a9 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_XENSTORE $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..3a061d6 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 639ce6e..75ffd2a 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 
 		/* Iterate through chain */
 		while( tlock->off) {
-			tdb_off current;
+			tdb_off mycurrent;
 			if (rec_read(tdb, tlock->off, rec) == -1)
 				goto fail;
 
@@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 			}
 
 			/* Try to clean dead ones from old traverses */
-			current = tlock->off;
+			mycurrent = tlock->off;
 			tlock->off = rec->next;
 			if (!tdb->read_only && 
-			    do_delete(tdb, current, rec) != 0)
+			    do_delete(tdb, mycurrent, rec) != 0)
 				goto fail;
 		}
 		tdb_unlock(tdb, tlock->hash, F_WRLCK);
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0623aac..2d4a7e1 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -32,7 +32,9 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#ifndef NO_SYSLOG
 #include <syslog.h>
+#endif
 #include <string.h>
 #include <errno.h>
 #include <dirent.h>
@@ -61,13 +63,24 @@ LIST_HEAD(connections);
 static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
+#ifndef NO_REOPEN_LOG
 static int reopen_log_pipe[2];
+#endif
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
 
+#ifdef __MINIOS__
+#define lockf(...) (-ENOSYS)
+#endif
+
+#ifdef NO_SYSLOG
+#define openlog(...) ((void) 0)
+#define syslog(...)  ((void) 0)
+#endif
+
 #define log(...)							\
 	do {								\
 		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
@@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
+#ifndef __MINIOS__
 	if (rename(newname, xs_daemon_tdb()) != 0)
 		return false;
+#endif
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -195,6 +210,7 @@ void trace_destroy(const void *data, const char *type)
 	trace("DESTROY %s %p\n", type, data);
 }
 
+#ifndef NO_REOPEN_LOG
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
@@ -222,7 +238,7 @@ static void reopen_log(void)
 			trace("\n***\n");
 	}
 }
-
+#endif
 
 static bool write_messages(struct connection *conn)
 {
@@ -329,7 +345,9 @@ static int initialize_set(fd_set *inset, fd_set *outset,
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
 #endif
+#ifndef NO_REOPEN_LOG
 	set_fd(reopen_log_pipe[0], inset, &max);
+#endif
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1418,7 +1436,11 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
+#ifdef __MINIOS__
+#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
+#else
 #define TDB_FLAGS 0
+#endif
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1443,7 +1465,11 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
+#ifdef __MINIOS__
+	tdb_ctx = NULL;
+#else
 	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+#endif
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1669,6 +1695,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifndef __MINIOS__
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1715,7 +1742,7 @@ static void daemonize(void)
 	/* Discard our parent's old-fashioned umask prejudices. */
 	umask(0);
 }
-
+#endif
 
 static void usage(void)
 {
@@ -1769,7 +1796,11 @@ int main(int argc, char *argv[])
 	struct sockaddr_un addr;
 #endif
 	fd_set inset, outset;
+#ifdef __MINIOS__
+	bool dofork = false;
+#else
 	bool dofork = true;
+#endif
 	bool outputpid = false;
 	bool no_domain_init = false;
 	const char *pidfile = NULL;
@@ -1823,8 +1854,11 @@ int main(int argc, char *argv[])
 	if (optind != argc)
 		barf("%s: No arguments desired", argv[0]);
 
+#ifndef NO_REOPEN_LOG
 	reopen_log();
+#endif
 
+#ifndef __MINIOS__
 	/* make sure xenstored directory exists */
 	if (mkdir(xs_daemon_rundir(), 0755)) {
 		if (errno != EEXIST) {
@@ -1846,6 +1880,7 @@ int main(int argc, char *argv[])
 	}
 	if (pidfile)
 		write_pidfile(pidfile);
+#endif
 
 	/* Talloc leak reports go to stderr, which is closed if we fork. */
 	if (!dofork)
@@ -1890,9 +1925,11 @@ int main(int argc, char *argv[])
 		barf_perror("Could not listen on sockets");
 #endif
 
+#ifndef NO_REOPEN_LOG
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1921,7 +1958,9 @@ int main(int argc, char *argv[])
 		xprintf = trace;
 	}
 
+#ifndef NO_REOPEN_LOG
 	signal(SIGHUP, trigger_reopen_log);
+#endif
 
 	if (xce_handle != NULL)
 		evtchn_fd = xc_evtchn_fd(xce_handle);
@@ -1933,8 +1972,10 @@ int main(int argc, char *argv[])
 	max = initialize_set(&inset, &outset, &timeout);
 #endif
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1946,12 +1987,14 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
+#ifndef NO_REOPEN_LOG
 		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
 			reopen_log();
 		}
+#endif
 
 #ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 0b8353b..811ae3c 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -588,6 +588,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static inline int dom0_init(void) 
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -611,6 +617,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
index 380c691..c59acfb 100644
--- a/tools/xenstore/xenstored_transaction.c
+++ b/tools/xenstore/xenstored_transaction.c
@@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
 	trace_destroy(trans, "transaction");
 	if (trans->tdb)
 		tdb_close(trans->tdb);
+#ifndef __MINIOS__
 	unlink(trans->tdb_name);
+#endif
 	return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sN-0006GD-2t; Wed, 11 Jan 2012 17:22:15 +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 1Rl1sL-0006Dl-79
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326302525!8738328!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 27974 invoked from network); 11 Jan 2012 17:22:06 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM4qt029360
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xt012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:17 -0500
Message-Id: <1326302490-19428-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/18] tools/libxl: Add xenstore and console
	backend domain IDs to config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 changes the event channels set up in the start_info structure of
newly built domains to be associated with a domain other than dom0,
to support xenstored or xenconsoled running in stub domains.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxl/libxl_dom.c     |    4 ++--
 tools/libxl/libxl_types.idl |    2 ++
 tools/libxl/xl_cmdimpl.c    |    6 ++++++
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a4725fe..e12d687 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -104,8 +104,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, info->xenstore_dom);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, info->console_dom);
     state->vm_generationid_addr = 0;
     return 0;
 }
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 574dec7..013f5c6 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -168,6 +168,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("video_memkb",     uint32),
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
+    ("xenstore_dom",    uint32),
+    ("console_dom",     uint32),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
     ("u", KeyedUnion(None, libxl_domain_type, "type",
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 8c30de1..bb1bb5b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -661,6 +661,12 @@ static void parse_config_data(const char *configfile_filename_report,
     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus = l;
 
+    if (!xlu_cfg_get_long (config, "xenstore_dom", &l, 0))
+        b_info->xenstore_dom = l;
+
+    if (!xlu_cfg_get_long (config, "console_dom", &l, 0))
+        b_info->console_dom = l;
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sN-0006GD-2t; Wed, 11 Jan 2012 17:22:15 +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 1Rl1sL-0006Dl-79
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326302525!8738328!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 27974 invoked from network); 11 Jan 2012 17:22:06 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:22: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
	q0BHM4qt029360
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:04 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 q0BHM4Xt012565; 
	Wed, 11 Jan 2012 12:22:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:21:17 -0500
Message-Id: <1326302490-19428-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/18] tools/libxl: Add xenstore and console
	backend domain IDs to config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 changes the event channels set up in the start_info structure of
newly built domains to be associated with a domain other than dom0,
to support xenstored or xenconsoled running in stub domains.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxl/libxl_dom.c     |    4 ++--
 tools/libxl/libxl_types.idl |    2 ++
 tools/libxl/xl_cmdimpl.c    |    6 ++++++
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a4725fe..e12d687 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -104,8 +104,8 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, info->xenstore_dom);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, info->console_dom);
     state->vm_generationid_addr = 0;
     return 0;
 }
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 574dec7..013f5c6 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -168,6 +168,8 @@ libxl_domain_build_info = Struct("domain_build_info",[
     ("video_memkb",     uint32),
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
+    ("xenstore_dom",    uint32),
+    ("console_dom",     uint32),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
     ("u", KeyedUnion(None, libxl_domain_type, "type",
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 8c30de1..bb1bb5b 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -661,6 +661,12 @@ static void parse_config_data(const char *configfile_filename_report,
     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus = l;
 
+    if (!xlu_cfg_get_long (config, "xenstore_dom", &l, 0))
+        b_info->xenstore_dom = l;
+
+    if (!xlu_cfg_get_long (config, "console_dom", &l, 0))
+        b_info->console_dom = l;
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb = l * 1024;
         b_info->target_memkb = b_info->max_memkb;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sX-0006R6-Hc; Wed, 11 Jan 2012 17:22:25 +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 1Rl1sV-0006Ij-IS
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326302536!2773919!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 10573 invoked from network); 11 Jan 2012 17:22:17 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0BHMGqt029402
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:16 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 q0BHMG78012711; 
	Wed, 11 Jan 2012 12:22:16 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:22:09 -0500
Message-Id: <1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in stub
	domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
xenbus backend to be started after the kernel has booted. This is
intended to allow dom0 to start another domain to run xenstore.

IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
started; the domain ID is passed as the ioctl argument. This sets up a
listening event channel and grant reference to xenbus, but does not
start using this interface. It returns the local event channel port.

IOCTL_XENBUS_BACKEND_REMOTE_COMMIT causes the kernel to begin using the
event channel set up in the previous ioctl, reregistering all watches
and deallocating the previous xenstored event channel.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_comms.c       |    6 +++
 drivers/xen/xenbus/xenbus_comms.h       |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   57 +++++++++++++++++++++++++++++++
 include/xen/grant_table.h               |    2 +
 include/xen/xenbus_dev.h                |    6 +++
 5 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 2eff7a6..52fe7ad 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -234,3 +234,9 @@ int xb_init_comms(void)
 
 	return 0;
 }
+
+void xb_deinit_comms(void)
+{
+	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
+	xenbus_irq = 0;
+}
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index 6e42800..c8abd3b 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -35,6 +35,7 @@
 
 int xs_init(void);
 int xb_init_comms(void);
+void xb_deinit_comms(void);
 
 /* Low level routines. */
 int xb_write(const void *data, unsigned len);
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index 3d3be78..4138ba2 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -8,7 +8,11 @@
 
 #include <xen/xen.h>
 #include <xen/page.h>
+#include <xen/xenbus.h>
 #include <xen/xenbus_dev.h>
+#include <xen/grant_table.h>
+#include <xen/events.h>
+#include <asm/xen/hypervisor.h>
 
 #include "xenbus_comms.h"
 
@@ -22,6 +26,53 @@ static int xenbus_backend_open(struct inode *inode, struct file *filp)
 	return nonseekable_open(inode, filp);
 }
 
+static int pending_xsd_port;
+
+static long xenbus_backend_remote_setup(domid_t domid)
+{
+	struct evtchn_alloc_unbound arg;
+	int err;
+
+	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, domid,
+			virt_to_mfn(xen_store_interface), 0 /* writable */);
+
+	if (pending_xsd_port) {
+		struct evtchn_close close;
+		close.port = pending_xsd_port;
+		err = HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
+		WARN_ON(err);
+	}
+
+	arg.dom = DOMID_SELF;
+	arg.remote_dom = domid;
+
+	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
+	if (err)
+		return err;
+
+	pending_xsd_port = arg.port;
+
+	return arg.port;
+}
+
+static long xenbus_backend_remote_commit(unsigned long data)
+{
+	if (!pending_xsd_port)
+		return -EINVAL;
+
+	xs_suspend();
+
+	if (xen_store_evtchn > 0)
+		xb_deinit_comms();
+
+	xen_store_evtchn = pending_xsd_port;
+	pending_xsd_port = 0;
+
+	xs_resume();
+
+	return 0;
+}
+
 static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
 {
 	if (!capable(CAP_SYS_ADMIN))
@@ -33,6 +84,12 @@ static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned l
 				return xen_store_evtchn;
 			return -ENODEV;
 
+		case IOCTL_XENBUS_BACKEND_REMOTE_SETUP:
+			return xenbus_backend_remote_setup(data);
+
+		case IOCTL_XENBUS_BACKEND_REMOTE_COMMIT:
+			return xenbus_backend_remote_commit(data);
+
 		default:
 			return -ENOTTY;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 15f8a00..11e27c3 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -46,6 +46,8 @@
 
 #include <xen/features.h>
 
+#define GNTTAB_RESERVED_XENSTORE 1
+
 /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
 #define NR_GRANT_FRAMES 4
 
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
index ac5f0fe..24d5028 100644
--- a/include/xen/xenbus_dev.h
+++ b/include/xen/xenbus_dev.h
@@ -38,4 +38,10 @@
 #define IOCTL_XENBUS_BACKEND_EVTCHN			\
 	_IOC(_IOC_NONE, 'B', 0, 0)
 
+#define IOCTL_XENBUS_BACKEND_REMOTE_SETUP		\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#define IOCTL_XENBUS_BACKEND_REMOTE_COMMIT		\
+	_IOC(_IOC_NONE, 'B', 2, 0)
+
 #endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:22:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl1sX-0006R6-Hc; Wed, 11 Jan 2012 17:22:25 +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 1Rl1sV-0006Ij-IS
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:22:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326302536!2773919!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 10573 invoked from network); 11 Jan 2012 17:22:17 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 17:22:17 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0BHMGqt029402
	for <xen-devel@lists.xensource.com>; Wed, 11 Jan 2012 17:22:16 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 q0BHMG78012711; 
	Wed, 11 Jan 2012 12:22:16 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 11 Jan 2012 12:22:09 -0500
Message-Id: <1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in stub
	domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
xenbus backend to be started after the kernel has booted. This is
intended to allow dom0 to start another domain to run xenstore.

IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
started; the domain ID is passed as the ioctl argument. This sets up a
listening event channel and grant reference to xenbus, but does not
start using this interface. It returns the local event channel port.

IOCTL_XENBUS_BACKEND_REMOTE_COMMIT causes the kernel to begin using the
event channel set up in the previous ioctl, reregistering all watches
and deallocating the previous xenstored event channel.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_comms.c       |    6 +++
 drivers/xen/xenbus/xenbus_comms.h       |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   57 +++++++++++++++++++++++++++++++
 include/xen/grant_table.h               |    2 +
 include/xen/xenbus_dev.h                |    6 +++
 5 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 2eff7a6..52fe7ad 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -234,3 +234,9 @@ int xb_init_comms(void)
 
 	return 0;
 }
+
+void xb_deinit_comms(void)
+{
+	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
+	xenbus_irq = 0;
+}
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index 6e42800..c8abd3b 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -35,6 +35,7 @@
 
 int xs_init(void);
 int xb_init_comms(void);
+void xb_deinit_comms(void);
 
 /* Low level routines. */
 int xb_write(const void *data, unsigned len);
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index 3d3be78..4138ba2 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -8,7 +8,11 @@
 
 #include <xen/xen.h>
 #include <xen/page.h>
+#include <xen/xenbus.h>
 #include <xen/xenbus_dev.h>
+#include <xen/grant_table.h>
+#include <xen/events.h>
+#include <asm/xen/hypervisor.h>
 
 #include "xenbus_comms.h"
 
@@ -22,6 +26,53 @@ static int xenbus_backend_open(struct inode *inode, struct file *filp)
 	return nonseekable_open(inode, filp);
 }
 
+static int pending_xsd_port;
+
+static long xenbus_backend_remote_setup(domid_t domid)
+{
+	struct evtchn_alloc_unbound arg;
+	int err;
+
+	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, domid,
+			virt_to_mfn(xen_store_interface), 0 /* writable */);
+
+	if (pending_xsd_port) {
+		struct evtchn_close close;
+		close.port = pending_xsd_port;
+		err = HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
+		WARN_ON(err);
+	}
+
+	arg.dom = DOMID_SELF;
+	arg.remote_dom = domid;
+
+	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
+	if (err)
+		return err;
+
+	pending_xsd_port = arg.port;
+
+	return arg.port;
+}
+
+static long xenbus_backend_remote_commit(unsigned long data)
+{
+	if (!pending_xsd_port)
+		return -EINVAL;
+
+	xs_suspend();
+
+	if (xen_store_evtchn > 0)
+		xb_deinit_comms();
+
+	xen_store_evtchn = pending_xsd_port;
+	pending_xsd_port = 0;
+
+	xs_resume();
+
+	return 0;
+}
+
 static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
 {
 	if (!capable(CAP_SYS_ADMIN))
@@ -33,6 +84,12 @@ static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned l
 				return xen_store_evtchn;
 			return -ENODEV;
 
+		case IOCTL_XENBUS_BACKEND_REMOTE_SETUP:
+			return xenbus_backend_remote_setup(data);
+
+		case IOCTL_XENBUS_BACKEND_REMOTE_COMMIT:
+			return xenbus_backend_remote_commit(data);
+
 		default:
 			return -ENOTTY;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 15f8a00..11e27c3 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -46,6 +46,8 @@
 
 #include <xen/features.h>
 
+#define GNTTAB_RESERVED_XENSTORE 1
+
 /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
 #define NR_GRANT_FRAMES 4
 
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
index ac5f0fe..24d5028 100644
--- a/include/xen/xenbus_dev.h
+++ b/include/xen/xenbus_dev.h
@@ -38,4 +38,10 @@
 #define IOCTL_XENBUS_BACKEND_EVTCHN			\
 	_IOC(_IOC_NONE, 'B', 0, 0)
 
+#define IOCTL_XENBUS_BACKEND_REMOTE_SETUP		\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#define IOCTL_XENBUS_BACKEND_REMOTE_COMMIT		\
+	_IOC(_IOC_NONE, 'B', 2, 0)
+
 #endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:27:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:27:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1xI-0000Z3-Ly; Wed, 11 Jan 2012 17:27: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 1Rl1xH-0000XW-Fd
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:27:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326302833!8747239!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 10910 invoked from network); 11 Jan 2012 17:27:13 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 17:27:13 -0000
Received: by wgbdt11 with SMTP id dt11so979491wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 09:27:13 -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=oqpSMLvcmmdRiy+lMZRIEONU5MmQno+V8jsooE6pqKo=;
	b=BV56PyyEh7wg4jE2Pu7sL99GgMj1v+Q/3HlXTQ8qQH6dJZVb1xm890GQeEKXkWN2b3
	Vv0Tm/3OL6WTppAcNCDXkaYN9wsAt11JKr6dqrL/l4GlKfo5vtGTbp2zj0I56saeVdrA
	5EqZkkD5OuvNDX/HSk1obCLPbEADaVBYAamYk=
Received: by 10.181.13.162 with SMTP id ez2mr190008wid.17.1326302833215;
	Wed, 11 Jan 2012 09:27:13 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fy5sm3826428wib.7.2012.01.11.09.27.11
	(version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 09:27:11 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Jan 2012 17:27:09 +0000
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3376ED.3724E%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 03/18] xsm: allow use of
	XEN_DOMCTL_getdomaininfo by non-IS_PRIV domains
Thread-Index: AczQhj8dJea+/L5bxUK9kA9FOZNvHA==
In-Reply-To: <1326302490-19428-4-git-send-email-dgdegra@tycho.nsa.gov>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 03/18] xsm: allow use of
 XEN_DOMCTL_getdomaininfo by non-IS_PRIV 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 11/01/2012 17:21, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> This domctl does not allow manipulation of domains, only basic
> information such as size and state. XSM modules can also provide
> fine-grained control over what domains are visible to domains that call
> getdomaininfo.

Well there's a reason we might not disallow the hypercall. But why would we
actually care to allow it?

 -- Keir

> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/common/domctl.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index a775aa3..2c1ca85 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
>              return -EPERM;
>          break;
>      }
> +#ifdef XSM_ENABLE
> +    case XEN_DOMCTL_getdomaininfo:
> +        break;
> +#endif
>      default:
>          if ( !IS_PRIV(current->domain) )
>              return -EPERM;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:27:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:27:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1xI-0000Z3-Ly; Wed, 11 Jan 2012 17:27: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 1Rl1xH-0000XW-Fd
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:27:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326302833!8747239!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 10910 invoked from network); 11 Jan 2012 17:27:13 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 17:27:13 -0000
Received: by wgbdt11 with SMTP id dt11so979491wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 09:27:13 -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=oqpSMLvcmmdRiy+lMZRIEONU5MmQno+V8jsooE6pqKo=;
	b=BV56PyyEh7wg4jE2Pu7sL99GgMj1v+Q/3HlXTQ8qQH6dJZVb1xm890GQeEKXkWN2b3
	Vv0Tm/3OL6WTppAcNCDXkaYN9wsAt11JKr6dqrL/l4GlKfo5vtGTbp2zj0I56saeVdrA
	5EqZkkD5OuvNDX/HSk1obCLPbEADaVBYAamYk=
Received: by 10.181.13.162 with SMTP id ez2mr190008wid.17.1326302833215;
	Wed, 11 Jan 2012 09:27:13 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fy5sm3826428wib.7.2012.01.11.09.27.11
	(version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 09:27:11 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Jan 2012 17:27:09 +0000
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3376ED.3724E%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 03/18] xsm: allow use of
	XEN_DOMCTL_getdomaininfo by non-IS_PRIV domains
Thread-Index: AczQhj8dJea+/L5bxUK9kA9FOZNvHA==
In-Reply-To: <1326302490-19428-4-git-send-email-dgdegra@tycho.nsa.gov>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 03/18] xsm: allow use of
 XEN_DOMCTL_getdomaininfo by non-IS_PRIV 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 11/01/2012 17:21, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:

> This domctl does not allow manipulation of domains, only basic
> information such as size and state. XSM modules can also provide
> fine-grained control over what domains are visible to domains that call
> getdomaininfo.

Well there's a reason we might not disallow the hypercall. But why would we
actually care to allow it?

 -- Keir

> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/common/domctl.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index a775aa3..2c1ca85 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
>              return -EPERM;
>          break;
>      }
> +#ifdef XSM_ENABLE
> +    case XEN_DOMCTL_getdomaininfo:
> +        break;
> +#endif
>      default:
>          if ( !IS_PRIV(current->domain) )
>              return -EPERM;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:30:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1zt-000156-94; Wed, 11 Jan 2012 17:30:01 +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 1Rl1zs-00013R-3W
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:30:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326302992!8733940!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgxNDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19021 invoked from network); 11 Jan 2012 17:29:53 -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; 11 Jan 2012 17:29:53 -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
	q0BHSrUx001900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 17:28:54 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
	q0BHSnpm015553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 17:28:49 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0BHSm4b014122; Wed, 11 Jan 2012 11:28:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 09:28:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B816D40077; Wed, 11 Jan 2012 12:27:00 -0500 (EST)
Date: Wed, 11 Jan 2012 12:27:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120111172700.GA4449@phenom.dumpdata.com>
References: <4F0B8D06.8050501@goop.org>
	<8e643150-6be5-44ba-aba3-a987b22fc82b@zmail13.collab.prod.int.phx2.redhat.com>
	<20120111161911.GB18203@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111161911.GB18203@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.0A090202.4F0DC6D7.0005,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 12:19:11PM -0400, Konrad Rzeszutek Wilk wrote:
> > > If the root complaint is that "customers think that anything set in
> > > .config is a supported feature", then the solutions are to support
> > > all
> > > the features in .config, re-educate the customers that they're wrong,
> > > or
> > > maintain a local patch to do this stuff.
> > 
> > If only re-educating people was free, like preempting questions is.
> > Local patches are of course always an option, and perhaps in this
> > case it's the best one. However, I think we already made a case for
> > better xen configurability for the driver domains, so I'm not 100%
> 
> Could you repost those backend patches please? At this point I am not
> sure which one we have discarded?

hm, I was thinking in terms of the XenBus ones. We had somewhere in this
converstion something about seperating the backend's from depending on
CONFIG_XEN_DOM0 as they can be run in any domain nowadays.

> 
> > convinced my initial patch (making dom0 configurable) isn't worthy
> > of upstream. Also, I didn't see any comments on my v2[*] of that
> > patch, which I believe satisfies the menu complexity issue and
> > brings in more configurability. That said, I'm about to reply to
> > that patch myself, since there's an issue with it.
> > 
> > Drew
> > 
> > [*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/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 Jan 11 17:30:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:30:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl1zt-000156-94; Wed, 11 Jan 2012 17:30:01 +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 1Rl1zs-00013R-3W
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:30:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326302992!8733940!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgxNDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19021 invoked from network); 11 Jan 2012 17:29:53 -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; 11 Jan 2012 17:29:53 -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
	q0BHSrUx001900
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 17:28:54 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
	q0BHSnpm015553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 17:28:49 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0BHSm4b014122; Wed, 11 Jan 2012 11:28:48 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 09:28:48 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B816D40077; Wed, 11 Jan 2012 12:27:00 -0500 (EST)
Date: Wed, 11 Jan 2012 12:27:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120111172700.GA4449@phenom.dumpdata.com>
References: <4F0B8D06.8050501@goop.org>
	<8e643150-6be5-44ba-aba3-a987b22fc82b@zmail13.collab.prod.int.phx2.redhat.com>
	<20120111161911.GB18203@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111161911.GB18203@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.0A090202.4F0DC6D7.0005,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 12:19:11PM -0400, Konrad Rzeszutek Wilk wrote:
> > > If the root complaint is that "customers think that anything set in
> > > .config is a supported feature", then the solutions are to support
> > > all
> > > the features in .config, re-educate the customers that they're wrong,
> > > or
> > > maintain a local patch to do this stuff.
> > 
> > If only re-educating people was free, like preempting questions is.
> > Local patches are of course always an option, and perhaps in this
> > case it's the best one. However, I think we already made a case for
> > better xen configurability for the driver domains, so I'm not 100%
> 
> Could you repost those backend patches please? At this point I am not
> sure which one we have discarded?

hm, I was thinking in terms of the XenBus ones. We had somewhere in this
converstion something about seperating the backend's from depending on
CONFIG_XEN_DOM0 as they can be run in any domain nowadays.

> 
> > convinced my initial patch (making dom0 configurable) isn't worthy
> > of upstream. Also, I didn't see any comments on my v2[*] of that
> > patch, which I believe satisfies the menu complexity issue and
> > brings in more configurability. That said, I'm about to reply to
> > that patch myself, since there's an issue with it.
> > 
> > Drew
> > 
> > [*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/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 Jan 11 17:31:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl21T-0001FS-Qz; Wed, 11 Jan 2012 17:31: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 1Rl21S-0001FB-Cd
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:31:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326303091!10618058!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgxNDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18264 invoked from network); 11 Jan 2012 17:31:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 17:31: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
	q0BHULGm003960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 17:30:22 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0BHUKTS011553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 17:30:21 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
	q0BHUJJs015440; Wed, 11 Jan 2012 11:30:19 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 09:30:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7057A40077; Wed, 11 Jan 2012 12:28:32 -0500 (EST)
Date: Wed, 11 Jan 2012 12:28:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111172832.GB4449@phenom.dumpdata.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326299801-7966-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F0DC72E.013B,ss=1,re=0.000,fgs=0
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
> unbootable configs. If we need it, then we should just build it in.

Hm, don't the frontends by themsevles load this module? So if you
do 'modprobe xen-pcifront' it would load this automatically?

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/xen/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 8795480..1d24061 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
>  	 but will have no xen contents.
>  
>  config XEN_XENBUS_FRONTEND
> -	tristate
> +	bool
>  
>  config XEN_GNTDEV
>  	tristate "userspace grant access device driver"
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:31:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl21T-0001FS-Qz; Wed, 11 Jan 2012 17:31: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 1Rl21S-0001FB-Cd
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:31:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326303091!10618058!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgxNDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18264 invoked from network); 11 Jan 2012 17:31:32 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 17:31: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
	q0BHULGm003960
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 17:30:22 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0BHUKTS011553
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 17:30:21 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
	q0BHUJJs015440; Wed, 11 Jan 2012 11:30:19 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 09:30:19 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7057A40077; Wed, 11 Jan 2012 12:28:32 -0500 (EST)
Date: Wed, 11 Jan 2012 12:28:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111172832.GB4449@phenom.dumpdata.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326299801-7966-1-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F0DC72E.013B,ss=1,re=0.000,fgs=0
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
> unbootable configs. If we need it, then we should just build it in.

Hm, don't the frontends by themsevles load this module? So if you
do 'modprobe xen-pcifront' it would load this automatically?

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/xen/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 8795480..1d24061 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
>  	 but will have no xen contents.
>  
>  config XEN_XENBUS_FRONTEND
> -	tristate
> +	bool
>  
>  config XEN_GNTDEV
>  	tristate "userspace grant access device driver"
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:32:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl21r-0001Iv-8B; Wed, 11 Jan 2012 17:32:03 +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 1Rl21q-0001Hz-Bp
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:32:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326303116!10490664!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23399 invoked from network); 11 Jan 2012 17:31:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 17:31:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9954348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 17:31:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 17:31:45 +0000
Date: Wed, 11 Jan 2012 17:32:07 +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: <1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/10] 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, 6 Jan 2012, Ian Jackson wrote:
> +struct libxl__egc {
> +    /* for event-generating functions only */
> +    struct libxl__gc gc;
> +};

[...]

>  /*
> + * Calling context and GC for event-generating functions:
> + *
> + * These are for use by parts of libxl which directly or indirectly
> + * call libxl__event_occurred.  These contain a gc but also a list of
> + * deferred events.
> + *
> + * Most code in libxlshould not need to initialise their own egc.
> + * Even functions which generate specific kinds of events don't need
> + * to - rather, they will be passed an egc into their own callback
> + * function and should just use the one they're given.
> + *
> + * A handy idiom for functions taking an egc is:
> + *     libxl__gc *gc = &egc->gc;
> + *
> + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> + * within libxl, because libxl__egc_cleanup may call back into the
> + * application.  This should be documented near the function
> + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
> + *
> + * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
> + * with the ctx *unlocked*.  So the right pattern has the EGC_...
> + * macro calls on the outside of the CTX_... ones.
> + */
> +
> +/* egc initialisation and destruction: */
> +
> +#define LIBXL_INIT_EGC(egc,ctx) do{             \
> +        LIBXL_INIT_GC((egc).gc,ctx);            \
> +        /* list of occurred events tbd */       \
> +    } while(0)
> +
> +_hidden void libxl__egc_cleanup(libxl__egc *egc);
> +
> +/* convenience macros: */
> +
> +#define EGC_INIT(ctx)                       \
> +    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
> +    libxl__gc *gc = &egc->gc
> +
> +#define EGC_FREE           libxl__egc_cleanup(egc)

I still prefer the approach prototyped in
http://marc.info/?l=xen-devel&m=132371797519877: avoid introducing
restrictions on how libxl functions have to be called, unify egc and gc,
make it possible to take the lock recursively and use the nested counter
to figure out when to call the callbacks.
It would make my head hurt less when I have to read/write this code,
however others might react differently.

I don't think we'll ever get an agreement on this so I'll just step back
and let other people decide what is the right approach.

Only one more thing: I would kindly ask to move all these event related
functions to a different source file, to make it easier for people to
understand which ones are different from the rest of the library.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:32:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:32:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl21r-0001Iv-8B; Wed, 11 Jan 2012 17:32:03 +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 1Rl21q-0001Hz-Bp
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:32:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326303116!10490664!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYxNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23399 invoked from network); 11 Jan 2012 17:31:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 17:31:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; 
   d="scan'208";a="9954348"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	11 Jan 2012 17:31:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 11 Jan 2012 17:31:45 +0000
Date: Wed, 11 Jan 2012 17:32:07 +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: <1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/10] 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, 6 Jan 2012, Ian Jackson wrote:
> +struct libxl__egc {
> +    /* for event-generating functions only */
> +    struct libxl__gc gc;
> +};

[...]

>  /*
> + * Calling context and GC for event-generating functions:
> + *
> + * These are for use by parts of libxl which directly or indirectly
> + * call libxl__event_occurred.  These contain a gc but also a list of
> + * deferred events.
> + *
> + * Most code in libxlshould not need to initialise their own egc.
> + * Even functions which generate specific kinds of events don't need
> + * to - rather, they will be passed an egc into their own callback
> + * function and should just use the one they're given.
> + *
> + * A handy idiom for functions taking an egc is:
> + *     libxl__gc *gc = &egc->gc;
> + *
> + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> + * within libxl, because libxl__egc_cleanup may call back into the
> + * application.  This should be documented near the function
> + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
> + *
> + * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
> + * with the ctx *unlocked*.  So the right pattern has the EGC_...
> + * macro calls on the outside of the CTX_... ones.
> + */
> +
> +/* egc initialisation and destruction: */
> +
> +#define LIBXL_INIT_EGC(egc,ctx) do{             \
> +        LIBXL_INIT_GC((egc).gc,ctx);            \
> +        /* list of occurred events tbd */       \
> +    } while(0)
> +
> +_hidden void libxl__egc_cleanup(libxl__egc *egc);
> +
> +/* convenience macros: */
> +
> +#define EGC_INIT(ctx)                       \
> +    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
> +    libxl__gc *gc = &egc->gc
> +
> +#define EGC_FREE           libxl__egc_cleanup(egc)

I still prefer the approach prototyped in
http://marc.info/?l=xen-devel&m=132371797519877: avoid introducing
restrictions on how libxl functions have to be called, unify egc and gc,
make it possible to take the lock recursively and use the nested counter
to figure out when to call the callbacks.
It would make my head hurt less when I have to read/write this code,
however others might react differently.

I don't think we'll ever get an agreement on this so I'll just step back
and let other people decide what is the right approach.

Only one more thing: I would kindly ask to move all these event related
functions to a different source file, to make it easier for people to
understand which ones are different from the rest of the library.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:33:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl22i-0001RJ-Ms; Wed, 11 Jan 2012 17:32:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rl22h-0001Qj-5b
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:32:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326303167!10051683!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgxNDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17665 invoked from network); 11 Jan 2012 17:32:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 17:32:49 -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
	q0BHVvFK006389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 17:31:58 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
	q0BHVuZT017485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 17:31:57 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
	q0BHVuFr032064; Wed, 11 Jan 2012 11:31:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 09:31:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0F20340077; Wed, 11 Jan 2012 12:30:09 -0500 (EST)
Date: Wed, 11 Jan 2012 12:30:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111173009.GC4449@phenom.dumpdata.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
	<1326299801-7966-2-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326299801-7966-2-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F0DC78F.001F,ss=1,re=0.000,fgs=0
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 05:36:39PM +0100, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.

What is the disadvantege of keeping it as is?

> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.
> 
You are missing the CC to the proper maintainer.

Also, did you test this with PV and PVonHVM guests?

> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..3e38c2f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2263,7 +2263,7 @@ config FB_VIRTUAL
>  
>  config XEN_FBDEV_FRONTEND
>  	tristate "Xen virtual frame buffer support"
> -	depends on FB && XEN
> +	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
>  	select FB_SYS_FILLRECT
>  	select FB_SYS_COPYAREA
>  	select FB_SYS_IMAGEBLIT
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:33:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:33:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl22i-0001RJ-Ms; Wed, 11 Jan 2012 17:32:56 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rl22h-0001Qj-5b
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:32:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326303167!10051683!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgxNDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17665 invoked from network); 11 Jan 2012 17:32:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 17:32:49 -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
	q0BHVvFK006389
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 17:31:58 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
	q0BHVuZT017485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 17:31:57 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
	q0BHVuFr032064; Wed, 11 Jan 2012 11:31:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 09:31:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0F20340077; Wed, 11 Jan 2012 12:30:09 -0500 (EST)
Date: Wed, 11 Jan 2012 12:30:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111173009.GC4449@phenom.dumpdata.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
	<1326299801-7966-2-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326299801-7966-2-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F0DC78F.001F,ss=1,re=0.000,fgs=0
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 05:36:39PM +0100, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.

What is the disadvantege of keeping it as is?

> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.
> 
You are missing the CC to the proper maintainer.

Also, did you test this with PV and PVonHVM guests?

> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..3e38c2f 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2263,7 +2263,7 @@ config FB_VIRTUAL
>  
>  config XEN_FBDEV_FRONTEND
>  	tristate "Xen virtual frame buffer support"
> -	depends on FB && XEN
> +	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
>  	select FB_SYS_FILLRECT
>  	select FB_SYS_COPYAREA
>  	select FB_SYS_IMAGEBLIT
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:36:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl266-0001lF-IW; Wed, 11 Jan 2012 17:36:26 +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 1Rl265-0001km-Di
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:36:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326303378!8713374!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 22028 invoked from network); 11 Jan 2012 17:36:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:36:18 -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
	q0BHaHcZ023623; Wed, 11 Jan 2012 17:36:17 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 q0BHaH1R014303; 
	Wed, 11 Jan 2012 12:36:17 -0500
Message-ID: <4F0DC88E.10205@tycho.nsa.gov>
Date: Wed, 11 Jan 2012 12:36:14 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CB3376ED.3724E%keir@xen.org>
In-Reply-To: <CB3376ED.3724E%keir@xen.org>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 03/18] xsm: allow use of
 XEN_DOMCTL_getdomaininfo by non-IS_PRIV 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 01/11/2012 12:27 PM, Keir Fraser wrote:
> On 11/01/2012 17:21, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> 
>> This domctl does not allow manipulation of domains, only basic
>> information such as size and state. XSM modules can also provide
>> fine-grained control over what domains are visible to domains that call
>> getdomaininfo.
> 
> Well there's a reason we might not disallow the hypercall. But why would we
> actually care to allow it?
> 
>  -- Keir
> 

Xenstored needs to be able to call getdomaininfo to determine what domain(s)
have been shut down when it receives the DOM_EXC VIRQ. This is used both to
clean up references to the domain (event/grant) and to fire the @releaseDomain
watch so that other domains also clean up after the domain.

Other than this hypercall, there is no reason to make xenstored's domain
privileged (the VIRQ must be delegated by dom0).

>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  xen/common/domctl.c |    4 ++++
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> index a775aa3..2c1ca85 100644
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
>>              return -EPERM;
>>          break;
>>      }
>> +#ifdef XSM_ENABLE
>> +    case XEN_DOMCTL_getdomaininfo:
>> +        break;
>> +#endif
>>      default:
>>          if ( !IS_PRIV(current->domain) )
>>              return -EPERM;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:36:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl266-0001lF-IW; Wed, 11 Jan 2012 17:36:26 +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 1Rl265-0001km-Di
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:36:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326303378!8713374!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 22028 invoked from network); 11 Jan 2012 17:36:18 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:36:18 -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
	q0BHaHcZ023623; Wed, 11 Jan 2012 17:36:17 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 q0BHaH1R014303; 
	Wed, 11 Jan 2012 12:36:17 -0500
Message-ID: <4F0DC88E.10205@tycho.nsa.gov>
Date: Wed, 11 Jan 2012 12:36:14 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Keir Fraser <keir@xen.org>
References: <CB3376ED.3724E%keir@xen.org>
In-Reply-To: <CB3376ED.3724E%keir@xen.org>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 03/18] xsm: allow use of
 XEN_DOMCTL_getdomaininfo by non-IS_PRIV 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 01/11/2012 12:27 PM, Keir Fraser wrote:
> On 11/01/2012 17:21, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> 
>> This domctl does not allow manipulation of domains, only basic
>> information such as size and state. XSM modules can also provide
>> fine-grained control over what domains are visible to domains that call
>> getdomaininfo.
> 
> Well there's a reason we might not disallow the hypercall. But why would we
> actually care to allow it?
> 
>  -- Keir
> 

Xenstored needs to be able to call getdomaininfo to determine what domain(s)
have been shut down when it receives the DOM_EXC VIRQ. This is used both to
clean up references to the domain (event/grant) and to fire the @releaseDomain
watch so that other domains also clean up after the domain.

Other than this hypercall, there is no reason to make xenstored's domain
privileged (the VIRQ must be delegated by dom0).

>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  xen/common/domctl.c |    4 ++++
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> index a775aa3..2c1ca85 100644
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
>>              return -EPERM;
>>          break;
>>      }
>> +#ifdef XSM_ENABLE
>> +    case XEN_DOMCTL_getdomaininfo:
>> +        break;
>> +#endif
>>      default:
>>          if ( !IS_PRIV(current->domain) )
>>              return -EPERM;
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 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 1Rl26a-0001ot-5H; Wed, 11 Jan 2012 17:36:56 +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 1Rl26Z-0001o6-3l
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:36:55 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326303408!8723356!1
X-Originating-IP: [213.199.154.204]
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 517 invoked from network); 11 Jan 2012 17:36:48 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Jan 2012 17:36:48 -0000
Received: from mail85-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, 11 Jan 2012 17:36:47 +0000
Received: from mail85-am1 (localhost [127.0.0.1])	by mail85-am1-R.bigfish.com
	(Postfix) with ESMTP id D91587000A2;
	Wed, 11 Jan 2012 17:36:46 +0000 (UTC)
X-SpamScore: -25
X-BigFish: VPS-25(zz148cM1432N98dK14ffO4015Lzz1202hzz8275bhz2dhc1ahc1bh668h839h)
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 mail85-am1 (localhost.localdomain [127.0.0.1]) by mail85-am1
	(MessageSwitch) id 1326303406739627_1836;
	Wed, 11 Jan 2012 17:36:46 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.244])	by
	mail85-am1.bigfish.com (Postfix) with ESMTP id A55D11C0045;
	Wed, 11 Jan 2012 17:36:46 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Jan 2012 17:36:46 +0000
X-WSS-ID: 0LXNA98-01-RG1-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 2BE901028127;	Wed, 11 Jan 2012 11:36:43 -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, 11 Jan 2012 11:36:56 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 11 Jan 2012 11:36:44 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 11 Jan 2012
	12:36:43 -0500
Received: from [165.204.15.179] (antimon.osrc.amd.com [165.204.15.179])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EF44149C20C; Wed, 11 Jan 2012
	17:36:41 +0000 (GMT)
Message-ID: <4F0DC8A9.8060106@amd.com>
Date: Wed, 11 Jan 2012 18:36:41 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de;
	rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1326215226@gran.amd.com>
	<4F0DB31D020000780006BDB2@nat28.tlf.novell.com>
In-Reply-To: <4F0DB31D020000780006BDB2@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 00 of 14 V3] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am 11.01.2012 16:04, schrieb Jan Beulich:
>>>> On 10.01.12 at 18:07, Wei Wang<wei.wang2@amd.com>  wrote:
>> Hi all, this is patch v3.
>> 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.
> I would look into committing 1-6 and 10 (if that one is independent of
> 7-9), if you can confirm that those on their own provide meaningful
> benefit (enabling the ppr log probably is what I'm after, but I'd still
> like your confirmation - patch 3 in particular doesn't look very useful
> without the later ones). So ideally the ones leading up to the ppr log
> enabling would all be first (or even a separate series), and the guest
> iommu ones would follow (as those make only sense when the tools
> maintainers are okay with the changes too)
Hi Jan,
Thanks for doing this. It sounds great! Even without guest iommu
being enabled, patch 1-6 and 10 would still be useful for turn on ppr and
GT features. Patch 6 will call some functions from patch 3. If you want to
leave patch 3 behind, I could send a new version to move patch 6 ahead.
Thanks,
Wei

> Jan
>
>> changes in v3:
>> * Use xenstore to receive guest iommu configuration instead of adding in a
>> new field in hvm_info_table.
>> * Support pci segment in vbdf to mbdf bind.
>> * Make hypercalls visible for non-x86 platforms.
>> * A few code cleanups according to comments from Jan and Ian.
>>
>> Changes in v2:
>> * Do not use linked list to access guest iommu tables.
>> * Do not parse iommu parameter in libxl_device_model_info again.
>> * Fix incorrect logical calculation in patch 11.
>> * Fix hypercall definition for non-x86 systems.
>>
>> Thanks,
>> Wei
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 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 1Rl26a-0001ot-5H; Wed, 11 Jan 2012 17:36:56 +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 1Rl26Z-0001o6-3l
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:36:55 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326303408!8723356!1
X-Originating-IP: [213.199.154.204]
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 517 invoked from network); 11 Jan 2012 17:36:48 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-4.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	11 Jan 2012 17:36:48 -0000
Received: from mail85-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, 11 Jan 2012 17:36:47 +0000
Received: from mail85-am1 (localhost [127.0.0.1])	by mail85-am1-R.bigfish.com
	(Postfix) with ESMTP id D91587000A2;
	Wed, 11 Jan 2012 17:36:46 +0000 (UTC)
X-SpamScore: -25
X-BigFish: VPS-25(zz148cM1432N98dK14ffO4015Lzz1202hzz8275bhz2dhc1ahc1bh668h839h)
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 mail85-am1 (localhost.localdomain [127.0.0.1]) by mail85-am1
	(MessageSwitch) id 1326303406739627_1836;
	Wed, 11 Jan 2012 17:36:46 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.244])	by
	mail85-am1.bigfish.com (Postfix) with ESMTP id A55D11C0045;
	Wed, 11 Jan 2012 17:36:46 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server id
	14.1.225.23; Wed, 11 Jan 2012 17:36:46 +0000
X-WSS-ID: 0LXNA98-01-RG1-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 2BE901028127;	Wed, 11 Jan 2012 11:36:43 -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, 11 Jan 2012 11:36:56 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag02.amd.com
	(163.181.55.2) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 11 Jan 2012 11:36:44 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Wed, 11 Jan 2012
	12:36:43 -0500
Received: from [165.204.15.179] (antimon.osrc.amd.com [165.204.15.179])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id EF44149C20C; Wed, 11 Jan 2012
	17:36:41 +0000 (GMT)
Message-ID: <4F0DC8A9.8060106@amd.com>
Date: Wed, 11 Jan 2012 18:36:41 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de;
	rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1326215226@gran.amd.com>
	<4F0DB31D020000780006BDB2@nat28.tlf.novell.com>
In-Reply-To: <4F0DB31D020000780006BDB2@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 00 of 14 V3] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am 11.01.2012 16:04, schrieb Jan Beulich:
>>>> On 10.01.12 at 18:07, Wei Wang<wei.wang2@amd.com>  wrote:
>> Hi all, this is patch v3.
>> 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.
> I would look into committing 1-6 and 10 (if that one is independent of
> 7-9), if you can confirm that those on their own provide meaningful
> benefit (enabling the ppr log probably is what I'm after, but I'd still
> like your confirmation - patch 3 in particular doesn't look very useful
> without the later ones). So ideally the ones leading up to the ppr log
> enabling would all be first (or even a separate series), and the guest
> iommu ones would follow (as those make only sense when the tools
> maintainers are okay with the changes too)
Hi Jan,
Thanks for doing this. It sounds great! Even without guest iommu
being enabled, patch 1-6 and 10 would still be useful for turn on ppr and
GT features. Patch 6 will call some functions from patch 3. If you want to
leave patch 3 behind, I could send a new version to move patch 6 ahead.
Thanks,
Wei

> Jan
>
>> changes in v3:
>> * Use xenstore to receive guest iommu configuration instead of adding in a
>> new field in hvm_info_table.
>> * Support pci segment in vbdf to mbdf bind.
>> * Make hypercalls visible for non-x86 platforms.
>> * A few code cleanups according to comments from Jan and Ian.
>>
>> Changes in v2:
>> * Do not use linked list to access guest iommu tables.
>> * Do not parse iommu parameter in libxl_device_model_info again.
>> * Fix incorrect logical calculation in patch 11.
>> * Fix hypercall definition for non-x86 systems.
>>
>> Thanks,
>> Wei
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:38:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl281-0001yN-M1; Wed, 11 Jan 2012 17:38: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 1Rl280-0001xk-3a
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:38:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326303496!2504540!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgxNDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7556 invoked from network); 11 Jan 2012 17:38:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 17:38:17 -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
	q0BHbPtn015177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 17:37: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
	q0BHbOC0001333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 17:37:24 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
	q0BHbN2K021340; Wed, 11 Jan 2012 11:37:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 09:37:23 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6B42440077; Wed, 11 Jan 2012 12:35:36 -0500 (EST)
Date: Wed, 11 Jan 2012 12:35:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111173536.GD4449@phenom.dumpdata.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
	<1326299801-7966-4-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326299801-7966-4-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F0DC8D6.00F9,ss=1,re=0.000,fgs=0
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 05:36:41PM +0100, Andrew Jones wrote:
> Add a description to the config menu for xen tmem.

We will have another config option asked during 'make oldconfig' right?

I thought part of this cleanup patch is to remove some of this
complexity - not make it _more_ complex.

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/xen/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 1d24061..7e8d728 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -143,7 +143,7 @@ config SWIOTLB_XEN
>  	select SWIOTLB
>  
>  config XEN_TMEM
> -	bool
> +	bool "Xen Transcendent Memory (tmem)"
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:38:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl281-0001yN-M1; Wed, 11 Jan 2012 17:38: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 1Rl280-0001xk-3a
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:38:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326303496!2504540!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDgxNDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7556 invoked from network); 11 Jan 2012 17:38:17 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 17:38:17 -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
	q0BHbPtn015177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 17:37: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
	q0BHbOC0001333
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 17:37:24 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
	q0BHbN2K021340; Wed, 11 Jan 2012 11:37:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 09:37:23 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6B42440077; Wed, 11 Jan 2012 12:35:36 -0500 (EST)
Date: Wed, 11 Jan 2012 12:35:36 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120111173536.GD4449@phenom.dumpdata.com>
References: <20120111161911.GB18203@andromeda.dapyr.net>
	<1326299801-7966-1-git-send-email-drjones@redhat.com>
	<1326299801-7966-4-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326299801-7966-4-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F0DC8D6.00F9,ss=1,re=0.000,fgs=0
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org, stefano.stabellini@eu.citrix.com
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 05:36:41PM +0100, Andrew Jones wrote:
> Add a description to the config menu for xen tmem.

We will have another config option asked during 'make oldconfig' right?

I thought part of this cleanup patch is to remove some of this
complexity - not make it _more_ complex.

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/xen/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 1d24061..7e8d728 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -143,7 +143,7 @@ config SWIOTLB_XEN
>  	select SWIOTLB
>  
>  config XEN_TMEM
> -	bool
> +	bool "Xen Transcendent Memory (tmem)"
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:49:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:49:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl2Im-0002Je-TP; Wed, 11 Jan 2012 17:49:32 +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 1Rl2Il-0002JZ-Cf
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:49:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326304164!8736298!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 17002 invoked from network); 11 Jan 2012 17:49:25 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 17:49:25 -0000
Received: by wibhq7 with SMTP id hq7so1427973wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 09:49: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=qCO19pcBV6AkEyRQQAYe0sPNSAIodBLJnOoMKTVQZmk=;
	b=H5w60PbkmwB4WF6rEhPaaYlOlltwpCbs8w3OUKTvGhEdkmSWPBr5g1prASdXl0gPNe
	Y+K/cWzPmq5x29AONqhOSZKsCRmOcBZ4Sdl4ueUN+d3ZKFgHWE8e9w22xP65kkw2C+Gd
	6uyWB5bude9U6KeiClUjNtjmUYslt3lCgBMI8=
Received: by 10.181.13.208 with SMTP id fa16mr391923wid.12.1326304164696;
	Wed, 11 Jan 2012 09:49:24 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id gy6sm5060186wib.11.2012.01.11.09.49.22
	(version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 09:49:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Jan 2012 17:49:14 +0000
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB337C1A.373C1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 03/18] xsm: allow use of
	XEN_DOMCTL_getdomaininfo by non-IS_PRIV domains
Thread-Index: AczQhj8dJea+/L5bxUK9kA9FOZNvHAAAxXAQ
In-Reply-To: <CB3376ED.3724E%keir@xen.org>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 03/18] xsm: allow use of
 XEN_DOMCTL_getdomaininfo by non-IS_PRIV 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 11/01/2012 17:27, "Keir Fraser" <keir@xen.org> wrote:

> On 11/01/2012 17:21, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> 
>> This domctl does not allow manipulation of domains, only basic
>> information such as size and state. XSM modules can also provide
>> fine-grained control over what domains are visible to domains that call
>> getdomaininfo.
> 
> Well there's a reason we might not disallow the hypercall. But why would we
> actually care to allow it?

Ah, I've now seen patch 00/18, so this is for xenstore stubdom.

Also this applies only to the XSM-enabled case, and just allows you to get
as far as the finer-grained xsm_getdomaininfo() check. Somehow I got the
ifdef the wrong way round in my head!

Okay, makes a lot of sense. However, if the dummy xsm module is supposed to
behave very similarly to a !XSM_ENABLE build (which is what I personally
would expect), then I think dummy_getdomaininfo() should be changed to
return 0 only when IS_PRIV(current->domain).

This of course will require a 'proper' XSM setup to be able to use the
xenstore stubdom, but probably setting eg XSM/Flask should be a core part of
setting up such a hardened Xen host anyway.

 -- Keir

>  -- Keir
> 
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  xen/common/domctl.c |    4 ++++
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>> 
>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> index a775aa3..2c1ca85 100644
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
>>              return -EPERM;
>>          break;
>>      }
>> +#ifdef XSM_ENABLE
>> +    case XEN_DOMCTL_getdomaininfo:
>> +        break;
>> +#endif
>>      default:
>>          if ( !IS_PRIV(current->domain) )
>>              return -EPERM;
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:49:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17:49:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl2Im-0002Je-TP; Wed, 11 Jan 2012 17:49:32 +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 1Rl2Il-0002JZ-Cf
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:49:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326304164!8736298!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 17002 invoked from network); 11 Jan 2012 17:49:25 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 17:49:25 -0000
Received: by wibhq7 with SMTP id hq7so1427973wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 09:49: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=qCO19pcBV6AkEyRQQAYe0sPNSAIodBLJnOoMKTVQZmk=;
	b=H5w60PbkmwB4WF6rEhPaaYlOlltwpCbs8w3OUKTvGhEdkmSWPBr5g1prASdXl0gPNe
	Y+K/cWzPmq5x29AONqhOSZKsCRmOcBZ4Sdl4ueUN+d3ZKFgHWE8e9w22xP65kkw2C+Gd
	6uyWB5bude9U6KeiClUjNtjmUYslt3lCgBMI8=
Received: by 10.181.13.208 with SMTP id fa16mr391923wid.12.1326304164696;
	Wed, 11 Jan 2012 09:49:24 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id gy6sm5060186wib.11.2012.01.11.09.49.22
	(version=SSLv3 cipher=OTHER); Wed, 11 Jan 2012 09:49:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 11 Jan 2012 17:49:14 +0000
From: Keir Fraser <keir@xen.org>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB337C1A.373C1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 03/18] xsm: allow use of
	XEN_DOMCTL_getdomaininfo by non-IS_PRIV domains
Thread-Index: AczQhj8dJea+/L5bxUK9kA9FOZNvHAAAxXAQ
In-Reply-To: <CB3376ED.3724E%keir@xen.org>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 03/18] xsm: allow use of
 XEN_DOMCTL_getdomaininfo by non-IS_PRIV 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 11/01/2012 17:27, "Keir Fraser" <keir@xen.org> wrote:

> On 11/01/2012 17:21, "Daniel De Graaf" <dgdegra@tycho.nsa.gov> wrote:
> 
>> This domctl does not allow manipulation of domains, only basic
>> information such as size and state. XSM modules can also provide
>> fine-grained control over what domains are visible to domains that call
>> getdomaininfo.
> 
> Well there's a reason we might not disallow the hypercall. But why would we
> actually care to allow it?

Ah, I've now seen patch 00/18, so this is for xenstore stubdom.

Also this applies only to the XSM-enabled case, and just allows you to get
as far as the finer-grained xsm_getdomaininfo() check. Somehow I got the
ifdef the wrong way round in my head!

Okay, makes a lot of sense. However, if the dummy xsm module is supposed to
behave very similarly to a !XSM_ENABLE build (which is what I personally
would expect), then I think dummy_getdomaininfo() should be changed to
return 0 only when IS_PRIV(current->domain).

This of course will require a 'proper' XSM setup to be able to use the
xenstore stubdom, but probably setting eg XSM/Flask should be a core part of
setting up such a hardened Xen host anyway.

 -- Keir

>  -- Keir
> 
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  xen/common/domctl.c |    4 ++++
>>  1 files changed, 4 insertions(+), 0 deletions(-)
>> 
>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> index a775aa3..2c1ca85 100644
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
>>              return -EPERM;
>>          break;
>>      }
>> +#ifdef XSM_ENABLE
>> +    case XEN_DOMCTL_getdomaininfo:
>> +        break;
>> +#endif
>>      default:
>>          if ( !IS_PRIV(current->domain) )
>>              return -EPERM;
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:50:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl2JW-0002NY-BY; Wed, 11 Jan 2012 17:50:18 +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 1Rl2JU-0002N8-6f
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:50:16 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326304209!8709703!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 10162 invoked from network); 11 Jan 2012 17:50:09 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:50:09 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.3.80])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74430422; Wed, 11 Jan 2012 18:50:09 +0100
Message-ID: <1326304198.2401.6.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 17:49:58 +0000
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] libxl: Extend CPU affinity specification
 and enable it in config 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: multipart/mixed; boundary="===============1016852203499038270=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1016852203499038270==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-v5gJK/CiQuBTR+reZxBV"


--=-v5gJK/CiQuBTR+reZxBV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Everyone,

This series slightly extends the current support for specifying CPU
affinity, basically adding the support for "^<cpuid>" kind of entries
(i.e., "^6", meaning "not on CPU#6), and enables doing so in a VM's
config file, like it (probably?) was possible with `xm'.

Should you have any comments or questions, feel free to throw them. :-)

Thanks and Regards,
Dario Faggioli

--
A generalize-vcpupin-parsig.patch
A support-cpus-par-in-config-file.patch
A adjust-examples.patch
--=20
tools/examples/xmexample.hvm         |    2 --
 tools/examples/xmexample.hvm-stubdom |    2 --
 tools/examples/xmexample.pv-grub     |    2 --
 tools/examples/xmexample.vti         |    2 --
 tools/examples/xmexample1            |    2 --
 tools/examples/xmexample2            |    3 ---
 tools/examples/xmexample3            |    3 ---
 tools/libxl/libxl_create.c           |    2 ++
 tools/libxl/libxl_dom.c              |    8 +++++++-
 tools/libxl/libxl_types.idl          |    1 +
 tools/libxl/libxl_utils.h            |    2 ++
 tools/libxl/xl_cmdimpl.c             |  109 ++++++++++++++++++++++++++++++=
++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------=
----
 12 files changed, 92 insertions(+), 46 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)



--=-v5gJK/CiQuBTR+reZxBV
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)

iEYEABECAAYFAk8Ny8YACgkQk4XaBE3IOsQlBgCdHmtrdcim2eI9EcaW0mwdB3lG
ia0AnjbsIjlrPmqsvA5aJOdQkMKUAAsr
=Hm1m
-----END PGP SIGNATURE-----

--=-v5gJK/CiQuBTR+reZxBV--



--===============1016852203499038270==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1016852203499038270==--



From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:50:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl2JW-0002NY-BY; Wed, 11 Jan 2012 17:50:18 +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 1Rl2JU-0002N8-6f
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:50:16 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326304209!8709703!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 10162 invoked from network); 11 Jan 2012 17:50:09 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	11 Jan 2012 17:50:09 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.3.80])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74430422; Wed, 11 Jan 2012 18:50:09 +0100
Message-ID: <1326304198.2401.6.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 17:49:58 +0000
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0 of 3] libxl: Extend CPU affinity specification
 and enable it in config 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: multipart/mixed; boundary="===============1016852203499038270=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1016852203499038270==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-v5gJK/CiQuBTR+reZxBV"


--=-v5gJK/CiQuBTR+reZxBV
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Everyone,

This series slightly extends the current support for specifying CPU
affinity, basically adding the support for "^<cpuid>" kind of entries
(i.e., "^6", meaning "not on CPU#6), and enables doing so in a VM's
config file, like it (probably?) was possible with `xm'.

Should you have any comments or questions, feel free to throw them. :-)

Thanks and Regards,
Dario Faggioli

--
A generalize-vcpupin-parsig.patch
A support-cpus-par-in-config-file.patch
A adjust-examples.patch
--=20
tools/examples/xmexample.hvm         |    2 --
 tools/examples/xmexample.hvm-stubdom |    2 --
 tools/examples/xmexample.pv-grub     |    2 --
 tools/examples/xmexample.vti         |    2 --
 tools/examples/xmexample1            |    2 --
 tools/examples/xmexample2            |    3 ---
 tools/examples/xmexample3            |    3 ---
 tools/libxl/libxl_create.c           |    2 ++
 tools/libxl/libxl_dom.c              |    8 +++++++-
 tools/libxl/libxl_types.idl          |    1 +
 tools/libxl/libxl_utils.h            |    2 ++
 tools/libxl/xl_cmdimpl.c             |  109 ++++++++++++++++++++++++++++++=
++++++++++++++++++++++++++++++++++++++++++++++++++-------------------------=
----
 12 files changed, 92 insertions(+), 46 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)



--=-v5gJK/CiQuBTR+reZxBV
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)

iEYEABECAAYFAk8Ny8YACgkQk4XaBE3IOsQlBgCdHmtrdcim2eI9EcaW0mwdB3lG
ia0AnjbsIjlrPmqsvA5aJOdQkMKUAAsr
=Hm1m
-----END PGP SIGNATURE-----

--=-v5gJK/CiQuBTR+reZxBV--



--===============1016852203499038270==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1016852203499038270==--



From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:55:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl2OS-0002ni-4D; Wed, 11 Jan 2012 17:55: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 1Rl2OQ-0002na-OI
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:55:22 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326304514!11970096!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30468 invoked from network); 11 Jan 2012 17:55:16 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 17:55:16 -0000
Received: by ggnh1 with SMTP id h1so6562410ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 09:55:14 -0800 (PST)
Received: by 10.50.170.1 with SMTP id ai1mr7640643igc.13.1326304514149;
	Wed, 11 Jan 2012 09:55: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 va6sm3915272igc.6.2012.01.11.09.55.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Jan 2012 09:55:12 -0800 (PST)
Message-ID: <4F0DCCFD.8050805@codemonkey.ws>
Date: Wed, 11 Jan 2012 11:55: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: 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>,
	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-Transfer-Encoding: 7bit
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/2011 05:55 AM, 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.


I don't think this is a good idea.  We shouldn't present an ad-hoc mechanism to 
configure devices in the device state.

I think this is fundamentally a Xen problem.  Where QEMU locates the buffer it 
uses to represent video RAM is entirely its own business.

What are ya'll doing that necessitates doing something special with video RAM?

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 Wed Jan 11 17:55:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl2OS-0002ni-4D; Wed, 11 Jan 2012 17:55: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 1Rl2OQ-0002na-OI
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:55:22 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326304514!11970096!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30468 invoked from network); 11 Jan 2012 17:55:16 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 17:55:16 -0000
Received: by ggnh1 with SMTP id h1so6562410ggn.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 09:55:14 -0800 (PST)
Received: by 10.50.170.1 with SMTP id ai1mr7640643igc.13.1326304514149;
	Wed, 11 Jan 2012 09:55: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 va6sm3915272igc.6.2012.01.11.09.55.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Jan 2012 09:55:12 -0800 (PST)
Message-ID: <4F0DCCFD.8050805@codemonkey.ws>
Date: Wed, 11 Jan 2012 11:55: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: 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>,
	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-Transfer-Encoding: 7bit
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/2011 05:55 AM, 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.


I don't think this is a good idea.  We shouldn't present an ad-hoc mechanism to 
configure devices in the device state.

I think this is fundamentally a Xen problem.  Where QEMU locates the buffer it 
uses to represent video RAM is entirely its own business.

What are ya'll doing that necessitates doing something special with video RAM?

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 Wed Jan 11 17:59:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl2SA-0002yw-Vq; Wed, 11 Jan 2012 17:59:14 +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 1Rl2S9-0002ym-4g
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:59:13 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326304633!59298689!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 30909 invoked from network); 11 Jan 2012 17:57:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 17:57:13 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.3.80])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74430619; Wed, 11 Jan 2012 18:59:07 +0100
Message-ID: <1326304739.12973.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 17:58:59 +0000
In-Reply-To: <1326304198.2401.6.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for
	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8700287909111958057=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8700287909111958057==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-vjWktQsj5cH8ZdAXfFoK"


--=-vjWktQsj5cH8ZdAXfFoK
Content-Type: multipart/mixed; boundary="=-GQccQM3Pp0wIV3b1dl2K"


--=-GQccQM3Pp0wIV3b1dl2K
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Allow for "^<cpuid>" syntax while specifying the pCPUs list
during a vcpu-pin. This enables doing the following:

 xl vcpu-pin 1 1 0-4,^2

and achieving:

 xl vcpu-list
 Name                                ID  VCPU   CPU State   Time(s) CPU Aff=
inity
 ...
 Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
 ...

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 9cdcedc133e5 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Wed Jan 11 10:34:45 2012 +0100
+++ b/tools/libxl/libxl_utils.h	Wed Jan 11 17:38:04 2012 +0000
@@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
+#define libxl_for_each_set_cpu(var, map) for (var =3D 0; var < (map).size =
* 8; var++) \
+                                             if (libxl_cpumap_test(&(map),=
 var))
=20
 int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
=20
diff -r 9cdcedc133e5 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 10:34:45 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:38:04 2012 +0000
@@ -3501,13 +3501,67 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb;
+    int i, rmcpu, ret =3D 0;
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap))
+        return ENOMEM;
+
+    if (strcmp(cpu, "all")) {
+        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
+            rmcpu =3D 0;
+            if (*toka =3D=3D '^') {
+                toka++; rmcpu =3D 1;
+            }
+            cpuida =3D strtoul(toka, &endptr, 10);
+            if (toka =3D=3D endptr) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                ret =3D EINVAL;
+                goto vcpp_out;
+            }
+            if (rmcpu) {
+                libxl_cpumap_set(&exclude_cpumap, cpuida);
+            } else if (*endptr =3D=3D '-') {
+                tokb =3D endptr + 1;
+                cpuidb =3D strtoul(tokb, &endptr, 10);
+                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
+                    fprintf(stderr, "Error: Invalid argument.\n");
+                    ret =3D EINVAL;
+                    goto vcpp_out;
+                }
+                while (cpuida <=3D cpuidb) {
+                    libxl_cpumap_set(cpumap, cpuida);
+                    ++cpuida;
+                }
+            } else {
+                libxl_cpumap_set(cpumap, cpuida);
+            }
+        }
+
+        libxl_for_each_set_cpu(i, exclude_cpumap) {
+            libxl_cpumap_reset(cpumap, i);
+        }
+    } else {
+        memset(cpumap->map, -1, cpumap->size);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return ret;
+}
+
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_cpumap cpumap;
=20
-    uint32_t vcpuid, cpuida, cpuidb;
-    char *endptr, *toka, *tokb;
+    uint32_t vcpuid;
+    char *endptr;
     int i, nb_vcpu;
=20
     vcpuid =3D strtoul(vcpu, &endptr, 10);
@@ -3524,32 +3578,9 @@ static void vcpupin(const char *d, const
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
-    if (strcmp(cpu, "all")) {
-        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
-            cpuida =3D strtoul(toka, &endptr, 10);
-            if (toka =3D=3D endptr) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                goto vcpupin_out1;
-            }
-            if (*endptr =3D=3D '-') {
-                tokb =3D endptr + 1;
-                cpuidb =3D strtoul(tokb, &endptr, 10);
-                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
-                    fprintf(stderr, "Error: Invalid argument.\n");
-                    goto vcpupin_out1;
-                }
-                while (cpuida <=3D cpuidb) {
-                    libxl_cpumap_set(&cpumap, cpuida);
-                    ++cpuida;
-                }
-            } else {
-                libxl_cpumap_set(&cpumap, cpuida);
-            }
-        }
-    }
-    else {
-        memset(cpumap.map, -1, cpumap.size);
-    }
+
+    if (vcpupin_parse(cpu, &cpumap))
+        goto vcpupin_out1;
=20
     if (vcpuid !=3D -1) {
         if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) =3D=3D -1)=
 {

--=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)



--=-GQccQM3Pp0wIV3b1dl2K
Content-Disposition: attachment; filename="generalize-vcpupin-parsig.patch"
Content-Type: text/x-patch; name="generalize-vcpupin-parsig.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDljZGNlZGMxMzNlNTIyN2M2MzVkYmIwMGJk
NDc3OTAxNTMxMTEwN2ENCmxpYnhsOiBleHRlbmQgcENQVXMgc3BlY2lmaWNhdGlvbiBmb3IgdmNw
dS1waW4uDQoNCkFsbG93IGZvciAiXjxjcHVpZD4iIHN5bnRheCB3aGlsZSBzcGVjaWZ5aW5nIHRo
ZSBwQ1BVcyBsaXN0DQpkdXJpbmcgYSB2Y3B1LXBpbi4gVGhpcyBlbmFibGVzIGRvaW5nIHRoZSBm
b2xsb3dpbmc6DQoNCiB4bCB2Y3B1LXBpbiAxIDEgMC00LF4yDQoNCmFuZCBhY2hpZXZpbmc6DQoN
CiB4bCB2Y3B1LWxpc3QNCiBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAg
VkNQVSAgIENQVSBTdGF0ZSAgIFRpbWUocykgQ1BVIEFmZmluaXR5DQogLi4uDQogU3F1ZWV6ZV9w
diAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgIDEgICAgMyAgIC1iLSAgICAgICAyLjQg
IDAtMSwzLTQNCiAuLi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZh
Z2dpb2xpQGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgOWNkY2VkYzEzM2U1IHRvb2xzL2xpYnhsL2xp
YnhsX3V0aWxzLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgJV2VkIEphbiAxMSAx
MDozNDo0NSAyMDEyICswMTAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF91dGlscy5oCVdlZCBK
YW4gMTEgMTc6Mzg6MDQgMjAxMiArMDAwMA0KQEAgLTcxLDYgKzcxLDggQEAgaW50IGxpYnhsX2Nw
dW1hcF90ZXN0KGxpYnhsX2NwdW1hcCAqY3B1bQ0KIHZvaWQgbGlieGxfY3B1bWFwX3NldChsaWJ4
bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4bF9jcHVtYXBfcmVzZXQobGli
eGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KICNkZWZpbmUgbGlieGxfZm9yX2VhY2hfY3B1
KHZhciwgbWFwKSBmb3IgKHZhciA9IDA7IHZhciA8IChtYXApLnNpemUgKiA4OyB2YXIrKykNCisj
ZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUodmFyLCBtYXApIGZvciAodmFyID0gMDsgdmFy
IDwgKG1hcCkuc2l6ZSAqIDg7IHZhcisrKSBcDQorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaWYgKGxpYnhsX2NwdW1hcF90ZXN0KCYobWFwKSwgdmFyKSkNCiAN
CiBpbnQgbGlieGxfY3B1YXJyYXlfYWxsb2MobGlieGxfY3R4ICpjdHgsIGxpYnhsX2NwdWFycmF5
ICpjcHVhcnJheSk7DQogDQpkaWZmIC1yIDljZGNlZGMxMzNlNSB0b29scy9saWJ4bC94bF9jbWRp
bXBsLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgSmFuIDExIDEwOjM0OjQ1
IDIwMTIgKzAxMDANCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgSmFuIDExIDE3
OjM4OjA0IDIwMTIgKzAwMDANCkBAIC0zNTAxLDEzICszNTAxLDY3IEBAIGludCBtYWluX3ZjcHVs
aXN0KGludCBhcmdjLCBjaGFyICoqYXJndikNCiAgICAgcmV0dXJuIDA7DQogfQ0KIA0KK3N0YXRp
YyBpbnQgdmNwdXBpbl9wYXJzZShjaGFyICpjcHUsIGxpYnhsX2NwdW1hcCAqY3B1bWFwKQ0KK3sN
CisgICAgbGlieGxfY3B1bWFwIGV4Y2x1ZGVfY3B1bWFwOw0KKyAgICB1aW50MzJfdCBjcHVpZGEs
IGNwdWlkYjsNCisgICAgY2hhciAqZW5kcHRyLCAqdG9rYSwgKnRva2I7DQorICAgIGludCBpLCBy
bWNwdSwgcmV0ID0gMDsNCisNCisgICAgaWYgKGxpYnhsX2NwdW1hcF9hbGxvYyhjdHgsICZleGNs
dWRlX2NwdW1hcCkpDQorICAgICAgICByZXR1cm4gRU5PTUVNOw0KKw0KKyAgICBpZiAoc3RyY21w
KGNwdSwgImFsbCIpKSB7DQorICAgICAgICBmb3IgKHRva2EgPSBzdHJ0b2soY3B1LCAiLCIpLCBp
ID0gMDsgdG9rYTsgdG9rYSA9IHN0cnRvayhOVUxMLCAiLCIpLCArK2kpIHsNCisgICAgICAgICAg
ICBybWNwdSA9IDA7DQorICAgICAgICAgICAgaWYgKCp0b2thID09ICdeJykgew0KKyAgICAgICAg
ICAgICAgICB0b2thKys7IHJtY3B1ID0gMTsNCisgICAgICAgICAgICB9DQorICAgICAgICAgICAg
Y3B1aWRhID0gc3RydG91bCh0b2thLCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAgaWYgKHRv
a2EgPT0gZW5kcHRyKSB7DQorICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6
IEludmFsaWQgYXJndW1lbnQuXG4iKTsNCisgICAgICAgICAgICAgICAgcmV0ID0gRUlOVkFMOw0K
KyAgICAgICAgICAgICAgICBnb3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgICAgIH0NCisgICAgICAg
ICAgICBpZiAocm1jcHUpIHsNCisgICAgICAgICAgICAgICAgbGlieGxfY3B1bWFwX3NldCgmZXhj
bHVkZV9jcHVtYXAsIGNwdWlkYSk7DQorICAgICAgICAgICAgfSBlbHNlIGlmICgqZW5kcHRyID09
ICctJykgew0KKyAgICAgICAgICAgICAgICB0b2tiID0gZW5kcHRyICsgMTsNCisgICAgICAgICAg
ICAgICAgY3B1aWRiID0gc3RydG91bCh0b2tiLCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAg
ICAgIGlmICgodG9rYiA9PSBlbmRwdHIpIHx8IChjcHVpZGEgPiBjcHVpZGIpKSB7DQorICAgICAg
ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBJbnZhbGlkIGFyZ3VtZW50Llxu
Iik7DQorICAgICAgICAgICAgICAgICAgICByZXQgPSBFSU5WQUw7DQorICAgICAgICAgICAgICAg
ICAgICBnb3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgICAgICAgICB9DQorICAgICAgICAgICAgICAg
IHdoaWxlIChjcHVpZGEgPD0gY3B1aWRiKSB7DQorICAgICAgICAgICAgICAgICAgICBsaWJ4bF9j
cHVtYXBfc2V0KGNwdW1hcCwgY3B1aWRhKTsNCisgICAgICAgICAgICAgICAgICAgICsrY3B1aWRh
Ow0KKyAgICAgICAgICAgICAgICB9DQorICAgICAgICAgICAgfSBlbHNlIHsNCisgICAgICAgICAg
ICAgICAgbGlieGxfY3B1bWFwX3NldChjcHVtYXAsIGNwdWlkYSk7DQorICAgICAgICAgICAgfQ0K
KyAgICAgICAgfQ0KKw0KKyAgICAgICAgbGlieGxfZm9yX2VhY2hfc2V0X2NwdShpLCBleGNsdWRl
X2NwdW1hcCkgew0KKyAgICAgICAgICAgIGxpYnhsX2NwdW1hcF9yZXNldChjcHVtYXAsIGkpOw0K
KyAgICAgICAgfQ0KKyAgICB9IGVsc2Ugew0KKyAgICAgICAgbWVtc2V0KGNwdW1hcC0+bWFwLCAt
MSwgY3B1bWFwLT5zaXplKTsNCisgICAgfQ0KKw0KK3ZjcHBfb3V0Og0KKyAgICBsaWJ4bF9jcHVt
YXBfZGlzcG9zZSgmZXhjbHVkZV9jcHVtYXApOw0KKw0KKyAgICByZXR1cm4gcmV0Ow0KK30NCisN
CiBzdGF0aWMgdm9pZCB2Y3B1cGluKGNvbnN0IGNoYXIgKmQsIGNvbnN0IGNoYXIgKnZjcHUsIGNo
YXIgKmNwdSkNCiB7DQogICAgIGxpYnhsX3ZjcHVpbmZvICp2Y3B1aW5mbzsNCiAgICAgbGlieGxf
Y3B1bWFwIGNwdW1hcDsNCiANCi0gICAgdWludDMyX3QgdmNwdWlkLCBjcHVpZGEsIGNwdWlkYjsN
Ci0gICAgY2hhciAqZW5kcHRyLCAqdG9rYSwgKnRva2I7DQorICAgIHVpbnQzMl90IHZjcHVpZDsN
CisgICAgY2hhciAqZW5kcHRyOw0KICAgICBpbnQgaSwgbmJfdmNwdTsNCiANCiAgICAgdmNwdWlk
ID0gc3RydG91bCh2Y3B1LCAmZW5kcHRyLCAxMCk7DQpAQCAtMzUyNCwzMiArMzU3OCw5IEBAIHN0
YXRpYyB2b2lkIHZjcHVwaW4oY29uc3QgY2hhciAqZCwgY29uc3QNCiAgICAgaWYgKGxpYnhsX2Nw
dW1hcF9hbGxvYyhjdHgsICZjcHVtYXApKSB7DQogICAgICAgICBnb3RvIHZjcHVwaW5fb3V0Ow0K
ICAgICB9DQotICAgIGlmIChzdHJjbXAoY3B1LCAiYWxsIikpIHsNCi0gICAgICAgIGZvciAodG9r
YSA9IHN0cnRvayhjcHUsICIsIiksIGkgPSAwOyB0b2thOyB0b2thID0gc3RydG9rKE5VTEwsICIs
IiksICsraSkgew0KLSAgICAgICAgICAgIGNwdWlkYSA9IHN0cnRvdWwodG9rYSwgJmVuZHB0ciwg
MTApOw0KLSAgICAgICAgICAgIGlmICh0b2thID09IGVuZHB0cikgew0KLSAgICAgICAgICAgICAg
ICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBJbnZhbGlkIGFyZ3VtZW50LlxuIik7DQotICAgICAg
ICAgICAgICAgIGdvdG8gdmNwdXBpbl9vdXQxOw0KLSAgICAgICAgICAgIH0NCi0gICAgICAgICAg
ICBpZiAoKmVuZHB0ciA9PSAnLScpIHsNCi0gICAgICAgICAgICAgICAgdG9rYiA9IGVuZHB0ciAr
IDE7DQotICAgICAgICAgICAgICAgIGNwdWlkYiA9IHN0cnRvdWwodG9rYiwgJmVuZHB0ciwgMTAp
Ow0KLSAgICAgICAgICAgICAgICBpZiAoKHRva2IgPT0gZW5kcHRyKSB8fCAoY3B1aWRhID4gY3B1
aWRiKSkgew0KLSAgICAgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogSW52
YWxpZCBhcmd1bWVudC5cbiIpOw0KLSAgICAgICAgICAgICAgICAgICAgZ290byB2Y3B1cGluX291
dDE7DQotICAgICAgICAgICAgICAgIH0NCi0gICAgICAgICAgICAgICAgd2hpbGUgKGNwdWlkYSA8
PSBjcHVpZGIpIHsNCi0gICAgICAgICAgICAgICAgICAgIGxpYnhsX2NwdW1hcF9zZXQoJmNwdW1h
cCwgY3B1aWRhKTsNCi0gICAgICAgICAgICAgICAgICAgICsrY3B1aWRhOw0KLSAgICAgICAgICAg
ICAgICB9DQotICAgICAgICAgICAgfSBlbHNlIHsNCi0gICAgICAgICAgICAgICAgbGlieGxfY3B1
bWFwX3NldCgmY3B1bWFwLCBjcHVpZGEpOw0KLSAgICAgICAgICAgIH0NCi0gICAgICAgIH0NCi0g
ICAgfQ0KLSAgICBlbHNlIHsNCi0gICAgICAgIG1lbXNldChjcHVtYXAubWFwLCAtMSwgY3B1bWFw
LnNpemUpOw0KLSAgICB9DQorDQorICAgIGlmICh2Y3B1cGluX3BhcnNlKGNwdSwgJmNwdW1hcCkp
DQorICAgICAgICBnb3RvIHZjcHVwaW5fb3V0MTsNCiANCiAgICAgaWYgKHZjcHVpZCAhPSAtMSkg
ew0KICAgICAgICAgaWYgKGxpYnhsX3NldF92Y3B1YWZmaW5pdHkoY3R4LCBkb21pZCwgdmNwdWlk
LCAmY3B1bWFwKSA9PSAtMSkgew0K


--=-GQccQM3Pp0wIV3b1dl2K--

--=-vjWktQsj5cH8ZdAXfFoK
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)

iEYEABECAAYFAk8NzeMACgkQk4XaBE3IOsTm1ACfRmKrPRE+v6ZEpnl7InKI2AEA
b/AAnRPlNHAjapzaASkFm16wmFhCr9Jh
=fv6F
-----END PGP SIGNATURE-----

--=-vjWktQsj5cH8ZdAXfFoK--



--===============8700287909111958057==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8700287909111958057==--



From xen-devel-bounces@lists.xensource.com Wed Jan 11 17:59:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 17: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 1Rl2SA-0002yw-Vq; Wed, 11 Jan 2012 17:59:14 +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 1Rl2S9-0002ym-4g
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 17:59:13 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326304633!59298689!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 30909 invoked from network); 11 Jan 2012 17:57:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 17:57:13 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.3.80])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74430619; Wed, 11 Jan 2012 18:59:07 +0100
Message-ID: <1326304739.12973.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 17:58:59 +0000
In-Reply-To: <1326304198.2401.6.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for
	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8700287909111958057=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8700287909111958057==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-vjWktQsj5cH8ZdAXfFoK"


--=-vjWktQsj5cH8ZdAXfFoK
Content-Type: multipart/mixed; boundary="=-GQccQM3Pp0wIV3b1dl2K"


--=-GQccQM3Pp0wIV3b1dl2K
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Allow for "^<cpuid>" syntax while specifying the pCPUs list
during a vcpu-pin. This enables doing the following:

 xl vcpu-pin 1 1 0-4,^2

and achieving:

 xl vcpu-list
 Name                                ID  VCPU   CPU State   Time(s) CPU Aff=
inity
 ...
 Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
 ...

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 9cdcedc133e5 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Wed Jan 11 10:34:45 2012 +0100
+++ b/tools/libxl/libxl_utils.h	Wed Jan 11 17:38:04 2012 +0000
@@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
+#define libxl_for_each_set_cpu(var, map) for (var =3D 0; var < (map).size =
* 8; var++) \
+                                             if (libxl_cpumap_test(&(map),=
 var))
=20
 int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
=20
diff -r 9cdcedc133e5 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 10:34:45 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:38:04 2012 +0000
@@ -3501,13 +3501,67 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb;
+    int i, rmcpu, ret =3D 0;
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap))
+        return ENOMEM;
+
+    if (strcmp(cpu, "all")) {
+        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
+            rmcpu =3D 0;
+            if (*toka =3D=3D '^') {
+                toka++; rmcpu =3D 1;
+            }
+            cpuida =3D strtoul(toka, &endptr, 10);
+            if (toka =3D=3D endptr) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                ret =3D EINVAL;
+                goto vcpp_out;
+            }
+            if (rmcpu) {
+                libxl_cpumap_set(&exclude_cpumap, cpuida);
+            } else if (*endptr =3D=3D '-') {
+                tokb =3D endptr + 1;
+                cpuidb =3D strtoul(tokb, &endptr, 10);
+                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
+                    fprintf(stderr, "Error: Invalid argument.\n");
+                    ret =3D EINVAL;
+                    goto vcpp_out;
+                }
+                while (cpuida <=3D cpuidb) {
+                    libxl_cpumap_set(cpumap, cpuida);
+                    ++cpuida;
+                }
+            } else {
+                libxl_cpumap_set(cpumap, cpuida);
+            }
+        }
+
+        libxl_for_each_set_cpu(i, exclude_cpumap) {
+            libxl_cpumap_reset(cpumap, i);
+        }
+    } else {
+        memset(cpumap->map, -1, cpumap->size);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return ret;
+}
+
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_cpumap cpumap;
=20
-    uint32_t vcpuid, cpuida, cpuidb;
-    char *endptr, *toka, *tokb;
+    uint32_t vcpuid;
+    char *endptr;
     int i, nb_vcpu;
=20
     vcpuid =3D strtoul(vcpu, &endptr, 10);
@@ -3524,32 +3578,9 @@ static void vcpupin(const char *d, const
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
-    if (strcmp(cpu, "all")) {
-        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
-            cpuida =3D strtoul(toka, &endptr, 10);
-            if (toka =3D=3D endptr) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                goto vcpupin_out1;
-            }
-            if (*endptr =3D=3D '-') {
-                tokb =3D endptr + 1;
-                cpuidb =3D strtoul(tokb, &endptr, 10);
-                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
-                    fprintf(stderr, "Error: Invalid argument.\n");
-                    goto vcpupin_out1;
-                }
-                while (cpuida <=3D cpuidb) {
-                    libxl_cpumap_set(&cpumap, cpuida);
-                    ++cpuida;
-                }
-            } else {
-                libxl_cpumap_set(&cpumap, cpuida);
-            }
-        }
-    }
-    else {
-        memset(cpumap.map, -1, cpumap.size);
-    }
+
+    if (vcpupin_parse(cpu, &cpumap))
+        goto vcpupin_out1;
=20
     if (vcpuid !=3D -1) {
         if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) =3D=3D -1)=
 {

--=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)



--=-GQccQM3Pp0wIV3b1dl2K
Content-Disposition: attachment; filename="generalize-vcpupin-parsig.patch"
Content-Type: text/x-patch; name="generalize-vcpupin-parsig.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDljZGNlZGMxMzNlNTIyN2M2MzVkYmIwMGJk
NDc3OTAxNTMxMTEwN2ENCmxpYnhsOiBleHRlbmQgcENQVXMgc3BlY2lmaWNhdGlvbiBmb3IgdmNw
dS1waW4uDQoNCkFsbG93IGZvciAiXjxjcHVpZD4iIHN5bnRheCB3aGlsZSBzcGVjaWZ5aW5nIHRo
ZSBwQ1BVcyBsaXN0DQpkdXJpbmcgYSB2Y3B1LXBpbi4gVGhpcyBlbmFibGVzIGRvaW5nIHRoZSBm
b2xsb3dpbmc6DQoNCiB4bCB2Y3B1LXBpbiAxIDEgMC00LF4yDQoNCmFuZCBhY2hpZXZpbmc6DQoN
CiB4bCB2Y3B1LWxpc3QNCiBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAg
VkNQVSAgIENQVSBTdGF0ZSAgIFRpbWUocykgQ1BVIEFmZmluaXR5DQogLi4uDQogU3F1ZWV6ZV9w
diAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgIDEgICAgMyAgIC1iLSAgICAgICAyLjQg
IDAtMSwzLTQNCiAuLi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZh
Z2dpb2xpQGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgOWNkY2VkYzEzM2U1IHRvb2xzL2xpYnhsL2xp
YnhsX3V0aWxzLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgJV2VkIEphbiAxMSAx
MDozNDo0NSAyMDEyICswMTAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF91dGlscy5oCVdlZCBK
YW4gMTEgMTc6Mzg6MDQgMjAxMiArMDAwMA0KQEAgLTcxLDYgKzcxLDggQEAgaW50IGxpYnhsX2Nw
dW1hcF90ZXN0KGxpYnhsX2NwdW1hcCAqY3B1bQ0KIHZvaWQgbGlieGxfY3B1bWFwX3NldChsaWJ4
bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4bF9jcHVtYXBfcmVzZXQobGli
eGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KICNkZWZpbmUgbGlieGxfZm9yX2VhY2hfY3B1
KHZhciwgbWFwKSBmb3IgKHZhciA9IDA7IHZhciA8IChtYXApLnNpemUgKiA4OyB2YXIrKykNCisj
ZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUodmFyLCBtYXApIGZvciAodmFyID0gMDsgdmFy
IDwgKG1hcCkuc2l6ZSAqIDg7IHZhcisrKSBcDQorICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaWYgKGxpYnhsX2NwdW1hcF90ZXN0KCYobWFwKSwgdmFyKSkNCiAN
CiBpbnQgbGlieGxfY3B1YXJyYXlfYWxsb2MobGlieGxfY3R4ICpjdHgsIGxpYnhsX2NwdWFycmF5
ICpjcHVhcnJheSk7DQogDQpkaWZmIC1yIDljZGNlZGMxMzNlNSB0b29scy9saWJ4bC94bF9jbWRp
bXBsLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgSmFuIDExIDEwOjM0OjQ1
IDIwMTIgKzAxMDANCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgSmFuIDExIDE3
OjM4OjA0IDIwMTIgKzAwMDANCkBAIC0zNTAxLDEzICszNTAxLDY3IEBAIGludCBtYWluX3ZjcHVs
aXN0KGludCBhcmdjLCBjaGFyICoqYXJndikNCiAgICAgcmV0dXJuIDA7DQogfQ0KIA0KK3N0YXRp
YyBpbnQgdmNwdXBpbl9wYXJzZShjaGFyICpjcHUsIGxpYnhsX2NwdW1hcCAqY3B1bWFwKQ0KK3sN
CisgICAgbGlieGxfY3B1bWFwIGV4Y2x1ZGVfY3B1bWFwOw0KKyAgICB1aW50MzJfdCBjcHVpZGEs
IGNwdWlkYjsNCisgICAgY2hhciAqZW5kcHRyLCAqdG9rYSwgKnRva2I7DQorICAgIGludCBpLCBy
bWNwdSwgcmV0ID0gMDsNCisNCisgICAgaWYgKGxpYnhsX2NwdW1hcF9hbGxvYyhjdHgsICZleGNs
dWRlX2NwdW1hcCkpDQorICAgICAgICByZXR1cm4gRU5PTUVNOw0KKw0KKyAgICBpZiAoc3RyY21w
KGNwdSwgImFsbCIpKSB7DQorICAgICAgICBmb3IgKHRva2EgPSBzdHJ0b2soY3B1LCAiLCIpLCBp
ID0gMDsgdG9rYTsgdG9rYSA9IHN0cnRvayhOVUxMLCAiLCIpLCArK2kpIHsNCisgICAgICAgICAg
ICBybWNwdSA9IDA7DQorICAgICAgICAgICAgaWYgKCp0b2thID09ICdeJykgew0KKyAgICAgICAg
ICAgICAgICB0b2thKys7IHJtY3B1ID0gMTsNCisgICAgICAgICAgICB9DQorICAgICAgICAgICAg
Y3B1aWRhID0gc3RydG91bCh0b2thLCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAgaWYgKHRv
a2EgPT0gZW5kcHRyKSB7DQorICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6
IEludmFsaWQgYXJndW1lbnQuXG4iKTsNCisgICAgICAgICAgICAgICAgcmV0ID0gRUlOVkFMOw0K
KyAgICAgICAgICAgICAgICBnb3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgICAgIH0NCisgICAgICAg
ICAgICBpZiAocm1jcHUpIHsNCisgICAgICAgICAgICAgICAgbGlieGxfY3B1bWFwX3NldCgmZXhj
bHVkZV9jcHVtYXAsIGNwdWlkYSk7DQorICAgICAgICAgICAgfSBlbHNlIGlmICgqZW5kcHRyID09
ICctJykgew0KKyAgICAgICAgICAgICAgICB0b2tiID0gZW5kcHRyICsgMTsNCisgICAgICAgICAg
ICAgICAgY3B1aWRiID0gc3RydG91bCh0b2tiLCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAg
ICAgIGlmICgodG9rYiA9PSBlbmRwdHIpIHx8IChjcHVpZGEgPiBjcHVpZGIpKSB7DQorICAgICAg
ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBJbnZhbGlkIGFyZ3VtZW50Llxu
Iik7DQorICAgICAgICAgICAgICAgICAgICByZXQgPSBFSU5WQUw7DQorICAgICAgICAgICAgICAg
ICAgICBnb3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgICAgICAgICB9DQorICAgICAgICAgICAgICAg
IHdoaWxlIChjcHVpZGEgPD0gY3B1aWRiKSB7DQorICAgICAgICAgICAgICAgICAgICBsaWJ4bF9j
cHVtYXBfc2V0KGNwdW1hcCwgY3B1aWRhKTsNCisgICAgICAgICAgICAgICAgICAgICsrY3B1aWRh
Ow0KKyAgICAgICAgICAgICAgICB9DQorICAgICAgICAgICAgfSBlbHNlIHsNCisgICAgICAgICAg
ICAgICAgbGlieGxfY3B1bWFwX3NldChjcHVtYXAsIGNwdWlkYSk7DQorICAgICAgICAgICAgfQ0K
KyAgICAgICAgfQ0KKw0KKyAgICAgICAgbGlieGxfZm9yX2VhY2hfc2V0X2NwdShpLCBleGNsdWRl
X2NwdW1hcCkgew0KKyAgICAgICAgICAgIGxpYnhsX2NwdW1hcF9yZXNldChjcHVtYXAsIGkpOw0K
KyAgICAgICAgfQ0KKyAgICB9IGVsc2Ugew0KKyAgICAgICAgbWVtc2V0KGNwdW1hcC0+bWFwLCAt
MSwgY3B1bWFwLT5zaXplKTsNCisgICAgfQ0KKw0KK3ZjcHBfb3V0Og0KKyAgICBsaWJ4bF9jcHVt
YXBfZGlzcG9zZSgmZXhjbHVkZV9jcHVtYXApOw0KKw0KKyAgICByZXR1cm4gcmV0Ow0KK30NCisN
CiBzdGF0aWMgdm9pZCB2Y3B1cGluKGNvbnN0IGNoYXIgKmQsIGNvbnN0IGNoYXIgKnZjcHUsIGNo
YXIgKmNwdSkNCiB7DQogICAgIGxpYnhsX3ZjcHVpbmZvICp2Y3B1aW5mbzsNCiAgICAgbGlieGxf
Y3B1bWFwIGNwdW1hcDsNCiANCi0gICAgdWludDMyX3QgdmNwdWlkLCBjcHVpZGEsIGNwdWlkYjsN
Ci0gICAgY2hhciAqZW5kcHRyLCAqdG9rYSwgKnRva2I7DQorICAgIHVpbnQzMl90IHZjcHVpZDsN
CisgICAgY2hhciAqZW5kcHRyOw0KICAgICBpbnQgaSwgbmJfdmNwdTsNCiANCiAgICAgdmNwdWlk
ID0gc3RydG91bCh2Y3B1LCAmZW5kcHRyLCAxMCk7DQpAQCAtMzUyNCwzMiArMzU3OCw5IEBAIHN0
YXRpYyB2b2lkIHZjcHVwaW4oY29uc3QgY2hhciAqZCwgY29uc3QNCiAgICAgaWYgKGxpYnhsX2Nw
dW1hcF9hbGxvYyhjdHgsICZjcHVtYXApKSB7DQogICAgICAgICBnb3RvIHZjcHVwaW5fb3V0Ow0K
ICAgICB9DQotICAgIGlmIChzdHJjbXAoY3B1LCAiYWxsIikpIHsNCi0gICAgICAgIGZvciAodG9r
YSA9IHN0cnRvayhjcHUsICIsIiksIGkgPSAwOyB0b2thOyB0b2thID0gc3RydG9rKE5VTEwsICIs
IiksICsraSkgew0KLSAgICAgICAgICAgIGNwdWlkYSA9IHN0cnRvdWwodG9rYSwgJmVuZHB0ciwg
MTApOw0KLSAgICAgICAgICAgIGlmICh0b2thID09IGVuZHB0cikgew0KLSAgICAgICAgICAgICAg
ICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBJbnZhbGlkIGFyZ3VtZW50LlxuIik7DQotICAgICAg
ICAgICAgICAgIGdvdG8gdmNwdXBpbl9vdXQxOw0KLSAgICAgICAgICAgIH0NCi0gICAgICAgICAg
ICBpZiAoKmVuZHB0ciA9PSAnLScpIHsNCi0gICAgICAgICAgICAgICAgdG9rYiA9IGVuZHB0ciAr
IDE7DQotICAgICAgICAgICAgICAgIGNwdWlkYiA9IHN0cnRvdWwodG9rYiwgJmVuZHB0ciwgMTAp
Ow0KLSAgICAgICAgICAgICAgICBpZiAoKHRva2IgPT0gZW5kcHRyKSB8fCAoY3B1aWRhID4gY3B1
aWRiKSkgew0KLSAgICAgICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogSW52
YWxpZCBhcmd1bWVudC5cbiIpOw0KLSAgICAgICAgICAgICAgICAgICAgZ290byB2Y3B1cGluX291
dDE7DQotICAgICAgICAgICAgICAgIH0NCi0gICAgICAgICAgICAgICAgd2hpbGUgKGNwdWlkYSA8
PSBjcHVpZGIpIHsNCi0gICAgICAgICAgICAgICAgICAgIGxpYnhsX2NwdW1hcF9zZXQoJmNwdW1h
cCwgY3B1aWRhKTsNCi0gICAgICAgICAgICAgICAgICAgICsrY3B1aWRhOw0KLSAgICAgICAgICAg
ICAgICB9DQotICAgICAgICAgICAgfSBlbHNlIHsNCi0gICAgICAgICAgICAgICAgbGlieGxfY3B1
bWFwX3NldCgmY3B1bWFwLCBjcHVpZGEpOw0KLSAgICAgICAgICAgIH0NCi0gICAgICAgIH0NCi0g
ICAgfQ0KLSAgICBlbHNlIHsNCi0gICAgICAgIG1lbXNldChjcHVtYXAubWFwLCAtMSwgY3B1bWFw
LnNpemUpOw0KLSAgICB9DQorDQorICAgIGlmICh2Y3B1cGluX3BhcnNlKGNwdSwgJmNwdW1hcCkp
DQorICAgICAgICBnb3RvIHZjcHVwaW5fb3V0MTsNCiANCiAgICAgaWYgKHZjcHVpZCAhPSAtMSkg
ew0KICAgICAgICAgaWYgKGxpYnhsX3NldF92Y3B1YWZmaW5pdHkoY3R4LCBkb21pZCwgdmNwdWlk
LCAmY3B1bWFwKSA9PSAtMSkgew0K


--=-GQccQM3Pp0wIV3b1dl2K--

--=-vjWktQsj5cH8ZdAXfFoK
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)

iEYEABECAAYFAk8NzeMACgkQk4XaBE3IOsTm1ACfRmKrPRE+v6ZEpnl7InKI2AEA
b/AAnRPlNHAjapzaASkFm16wmFhCr9Jh
=fv6F
-----END PGP SIGNATURE-----

--=-vjWktQsj5cH8ZdAXfFoK--



--===============8700287909111958057==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8700287909111958057==--



From xen-devel-bounces@lists.xensource.com Wed Jan 11 18:00:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 18:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl2Ta-00039R-GU; Wed, 11 Jan 2012 18:00:42 +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 1Rl2TY-000398-3d
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:00:40 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326304832!10621407!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 32063 invoked from network); 11 Jan 2012 18:00:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 18:00:32 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.3.80])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74430659; Wed, 11 Jan 2012 19:00:31 +0100
Message-ID: <1326304831.12973.3.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 18:00:31 +0000
In-Reply-To: <1326304198.2401.6.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============9085282458491062159=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============9085282458491062159==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-b6KUWioMSlndeAHaI1gC"


--=-b6KUWioMSlndeAHaI1gC
Content-Type: multipart/mixed; boundary="=-bOAc/zXSoQcOhM1YSutG"


--=-bOAc/zXSoQcOhM1YSutG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Enable CPU affinity specification in a VM's config file with the
exact syntax `xl vcpu-pin' provides.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 9ce68a4036b1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 17:38:04 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:40:45 2012 +0000
@@ -78,6 +78,8 @@ int libxl_init_build_info(libxl_ctx *ctx
     memset(b_info, '\0', sizeof(*b_info));
     b_info->max_vcpus =3D 1;
     b_info->cur_vcpus =3D 1;
+    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
+        return ERROR_NOMEM;
     b_info->max_memkb =3D 32 * 1024;
     b_info->target_memkb =3D b_info->max_memkb;
     b_info->disable_migrate =3D 0;
diff -r 9ce68a4036b1 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Jan 11 17:38:04 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Jan 11 17:40:45 2012 +0000
@@ -72,8 +72,14 @@ int libxl__build_pre(libxl__gc *gc, uint
               libxl_domain_build_info *info, libxl__domain_build_state *st=
ate)
 {
     libxl_ctx *ctx =3D libxl__gc_owner(gc);
-    int tsc_mode;
+    int i, tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
+    for (i =3D 0; i < info->max_vcpus; i++) {
+        if (libxl_set_vcpuaffinity(ctx, domid, i, &info->cpumap) =3D=3D -1=
) {
+                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "libxl_set_vcpuaffinit=
y failed. "
+                           "Going ahead without setting affinity for cpu %=
d.\n", i);
+        }
+    }
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM=
_CONSTANT);
     if (info->type =3D=3D LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
diff -r 9ce68a4036b1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 11 17:38:04 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 11 17:40:45 2012 +0000
@@ -162,6 +162,7 @@ libxl_domain_create_info =3D Struct("domai
 libxl_domain_build_info =3D Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
+    ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
diff -r 9ce68a4036b1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:38:04 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:40:45 2012 +0000
@@ -288,16 +288,24 @@ static void dolog(const char *file, int=20
         libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
 }
=20
+static void print_bitmap(uint8_t *map, int maplen, FILE *stream);
+
 static void printf_info(int domid,
                         libxl_domain_config *d_config,
                         libxl_device_model_info *dm_info)
 {
-    int i;
+    int i, nr_cpus =3D -1;
     libxl_dominfo info;
+    libxl_physinfo physinfo;
=20
     libxl_domain_create_info *c_info =3D &d_config->c_info;
     libxl_domain_build_info *b_info =3D &d_config->b_info;
=20
+    if (libxl_get_physinfo(ctx, &physinfo) =3D=3D 0)
+        nr_cpus =3D physinfo.nr_cpus;
+    else
+        fprintf(stderr, "libxl_physinfo failed.\n");
+
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM);
@@ -328,6 +336,9 @@ static void printf_info(int domid,
=20
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
+    printf("\t(CPU affinity ");
+    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);
+    printf(")\n");
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode)=
);
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
@@ -569,6 +580,8 @@ static void split_string_into_string_lis
     free(s);
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -661,6 +674,13 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus =3D l;
=20
+    if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
+        char *buf2 =3D strdup(buf);
+        vcpupin_parse(buf2, &b_info->cpumap);
+    } else {
+        memset(b_info->cpumap.map, -1, b_info->cpumap.size);
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb =3D l * 1024;
         b_info->target_memkb =3D b_info->max_memkb;

--=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)



--=-bOAc/zXSoQcOhM1YSutG
Content-Disposition: attachment; filename="support-cpus-par-in-config-file.patch"
Content-Type: text/x-patch; name="support-cpus-par-in-config-file.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDljZTY4YTQwMzZiMWEwMWIxN2VjZjVkYjBi
ZGU1YzExNDY1NWVjMGINCmxpYnhsOiBhbGxvdyBmb3Igc3BlY2lmeWluZyB0aGUgQ1BVIGFmZmlu
aXR5IGluIHRoZSBjb25maWcgZmlsZS4NCg0KRW5hYmxlIENQVSBhZmZpbml0eSBzcGVjaWZpY2F0
aW9uIGluIGEgVk0ncyBjb25maWcgZmlsZSB3aXRoIHRoZQ0KZXhhY3Qgc3ludGF4IGB4bCB2Y3B1
LXBpbicgcHJvdmlkZXMuDQoNClNpZ25lZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5m
YWdnaW9saUBjaXRyaXguY29tPg0KDQpkaWZmIC1yIDljZTY4YTQwMzZiMSB0b29scy9saWJ4bC9s
aWJ4bF9jcmVhdGUuYw0KLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMJV2VkIEphbiAx
MSAxNzozODowNCAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlX
ZWQgSmFuIDExIDE3OjQwOjQ1IDIwMTIgKzAwMDANCkBAIC03OCw2ICs3OCw4IEBAIGludCBsaWJ4
bF9pbml0X2J1aWxkX2luZm8obGlieGxfY3R4ICpjdHgNCiAgICAgbWVtc2V0KGJfaW5mbywgJ1ww
Jywgc2l6ZW9mKCpiX2luZm8pKTsNCiAgICAgYl9pbmZvLT5tYXhfdmNwdXMgPSAxOw0KICAgICBi
X2luZm8tPmN1cl92Y3B1cyA9IDE7DQorICAgIGlmIChsaWJ4bF9jcHVtYXBfYWxsb2MoY3R4LCAm
Yl9pbmZvLT5jcHVtYXApKQ0KKyAgICAgICAgcmV0dXJuIEVSUk9SX05PTUVNOw0KICAgICBiX2lu
Zm8tPm1heF9tZW1rYiA9IDMyICogMTAyNDsNCiAgICAgYl9pbmZvLT50YXJnZXRfbWVta2IgPSBi
X2luZm8tPm1heF9tZW1rYjsNCiAgICAgYl9pbmZvLT5kaXNhYmxlX21pZ3JhdGUgPSAwOw0KZGlm
ZiAtciA5Y2U2OGE0MDM2YjEgdG9vbHMvbGlieGwvbGlieGxfZG9tLmMNCi0tLSBhL3Rvb2xzL2xp
YnhsL2xpYnhsX2RvbS5jCVdlZCBKYW4gMTEgMTc6Mzg6MDQgMjAxMiArMDAwMA0KKysrIGIvdG9v
bHMvbGlieGwvbGlieGxfZG9tLmMJV2VkIEphbiAxMSAxNzo0MDo0NSAyMDEyICswMDAwDQpAQCAt
NzIsOCArNzIsMTQgQEAgaW50IGxpYnhsX19idWlsZF9wcmUobGlieGxfX2djICpnYywgdWludA0K
ICAgICAgICAgICAgICAgbGlieGxfZG9tYWluX2J1aWxkX2luZm8gKmluZm8sIGxpYnhsX19kb21h
aW5fYnVpbGRfc3RhdGUgKnN0YXRlKQ0KIHsNCiAgICAgbGlieGxfY3R4ICpjdHggPSBsaWJ4bF9f
Z2Nfb3duZXIoZ2MpOw0KLSAgICBpbnQgdHNjX21vZGU7DQorICAgIGludCBpLCB0c2NfbW9kZTsN
CiAgICAgeGNfZG9tYWluX21heF92Y3B1cyhjdHgtPnhjaCwgZG9taWQsIGluZm8tPm1heF92Y3B1
cyk7DQorICAgIGZvciAoaSA9IDA7IGkgPCBpbmZvLT5tYXhfdmNwdXM7IGkrKykgew0KKyAgICAg
ICAgaWYgKGxpYnhsX3NldF92Y3B1YWZmaW5pdHkoY3R4LCBkb21pZCwgaSwgJmluZm8tPmNwdW1h
cCkgPT0gLTEpIHsNCisgICAgICAgICAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0df
V0FSTklORywgImxpYnhsX3NldF92Y3B1YWZmaW5pdHkgZmFpbGVkLiAiDQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIkdvaW5nIGFoZWFkIHdpdGhvdXQgc2V0dGluZyBhZmZpbml0eSBmb3Ig
Y3B1ICVkLlxuIiwgaSk7DQorICAgICAgICB9DQorICAgIH0NCiAgICAgeGNfZG9tYWluX3NldG1h
eG1lbShjdHgtPnhjaCwgZG9taWQsIGluZm8tPnRhcmdldF9tZW1rYiArIExJQlhMX01BWE1FTV9D
T05TVEFOVCk7DQogICAgIGlmIChpbmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX1BWKQ0K
ICAgICAgICAgeGNfZG9tYWluX3NldF9tZW1tYXBfbGltaXQoY3R4LT54Y2gsIGRvbWlkLA0KZGlm
ZiAtciA5Y2U2OGE0MDM2YjEgdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsDQotLS0gYS90b29s
cy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJV2VkIEphbiAxMSAxNzozODowNCAyMDEyICswMDAwDQor
KysgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJV2VkIEphbiAxMSAxNzo0MDo0NSAyMDEy
ICswMDAwDQpAQCAtMTYyLDYgKzE2Miw3IEBAIGxpYnhsX2RvbWFpbl9jcmVhdGVfaW5mbyA9IFN0
cnVjdCgiZG9tYWkNCiBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyA9IFN0cnVjdCgiZG9tYWluX2J1
aWxkX2luZm8iLFsNCiAgICAgKCJtYXhfdmNwdXMiLCAgICAgICBpbnRlZ2VyKSwNCiAgICAgKCJj
dXJfdmNwdXMiLCAgICAgICBpbnRlZ2VyKSwNCisgICAgKCJjcHVtYXAiLCAgICAgICAgICBsaWJ4
bF9jcHVtYXApLA0KICAgICAoInRzY19tb2RlIiwgICAgICAgIGxpYnhsX3RzY19tb2RlKSwNCiAg
ICAgKCJtYXhfbWVta2IiLCAgICAgICB1aW50MzIpLA0KICAgICAoInRhcmdldF9tZW1rYiIsICAg
IHVpbnQzMiksDQpkaWZmIC1yIDljZTY4YTQwMzZiMSB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMN
Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgSmFuIDExIDE3OjM4OjA0IDIwMTIg
KzAwMDANCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgSmFuIDExIDE3OjQwOjQ1
IDIwMTIgKzAwMDANCkBAIC0yODgsMTYgKzI4OCwyNCBAQCBzdGF0aWMgdm9pZCBkb2xvZyhjb25z
dCBjaGFyICpmaWxlLCBpbnQgDQogICAgICAgICBsaWJ4bF93cml0ZV9leGFjdGx5KE5VTEwsIGxv
Z2ZpbGUsIHMsIHJjLCBOVUxMLCBOVUxMKTsNCiB9DQogDQorc3RhdGljIHZvaWQgcHJpbnRfYml0
bWFwKHVpbnQ4X3QgKm1hcCwgaW50IG1hcGxlbiwgRklMRSAqc3RyZWFtKTsNCisNCiBzdGF0aWMg
dm9pZCBwcmludGZfaW5mbyhpbnQgZG9taWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgbGli
eGxfZG9tYWluX2NvbmZpZyAqZF9jb25maWcsDQogICAgICAgICAgICAgICAgICAgICAgICAgbGli
eGxfZGV2aWNlX21vZGVsX2luZm8gKmRtX2luZm8pDQogew0KLSAgICBpbnQgaTsNCisgICAgaW50
IGksIG5yX2NwdXMgPSAtMTsNCiAgICAgbGlieGxfZG9taW5mbyBpbmZvOw0KKyAgICBsaWJ4bF9w
aHlzaW5mbyBwaHlzaW5mbzsNCiANCiAgICAgbGlieGxfZG9tYWluX2NyZWF0ZV9pbmZvICpjX2lu
Zm8gPSAmZF9jb25maWctPmNfaW5mbzsNCiAgICAgbGlieGxfZG9tYWluX2J1aWxkX2luZm8gKmJf
aW5mbyA9ICZkX2NvbmZpZy0+Yl9pbmZvOw0KIA0KKyAgICBpZiAobGlieGxfZ2V0X3BoeXNpbmZv
KGN0eCwgJnBoeXNpbmZvKSA9PSAwKQ0KKyAgICAgICAgbnJfY3B1cyA9IHBoeXNpbmZvLm5yX2Nw
dXM7DQorICAgIGVsc2UNCisgICAgICAgIGZwcmludGYoc3RkZXJyLCAibGlieGxfcGh5c2luZm8g
ZmFpbGVkLlxuIik7DQorDQogICAgIHByaW50ZigiKGRvbWFpblxuXHQoZG9taWQgJWQpXG4iLCBk
b21pZCk7DQogICAgIHByaW50ZigiXHQoY3JlYXRlX2luZm8pXG4iKTsNCiAgICAgcHJpbnRmKCJc
dChodm0gJWQpXG4iLCBjX2luZm8tPnR5cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfSFZNKTsNCkBA
IC0zMjgsNiArMzM2LDkgQEAgc3RhdGljIHZvaWQgcHJpbnRmX2luZm8oaW50IGRvbWlkLA0KIA0K
ICAgICBwcmludGYoIlx0KGJ1aWxkX2luZm8pXG4iKTsNCiAgICAgcHJpbnRmKCJcdChtYXhfdmNw
dXMgJWQpXG4iLCBiX2luZm8tPm1heF92Y3B1cyk7DQorICAgIHByaW50ZigiXHQoQ1BVIGFmZmlu
aXR5ICIpOw0KKyAgICBwcmludF9iaXRtYXAoYl9pbmZvLT5jcHVtYXAubWFwLCBucl9jcHVzLCBz
dGRvdXQpOw0KKyAgICBwcmludGYoIilcbiIpOw0KICAgICBwcmludGYoIlx0KHRzY19tb2RlICVz
KVxuIiwgbGlieGxfdHNjX21vZGVfdG9fc3RyaW5nKGJfaW5mby0+dHNjX21vZGUpKTsNCiAgICAg
cHJpbnRmKCJcdChtYXhfbWVta2IgJWQpXG4iLCBiX2luZm8tPm1heF9tZW1rYik7DQogICAgIHBy
aW50ZigiXHQodGFyZ2V0X21lbWtiICVkKVxuIiwgYl9pbmZvLT50YXJnZXRfbWVta2IpOw0KQEAg
LTU2OSw2ICs1ODAsOCBAQCBzdGF0aWMgdm9pZCBzcGxpdF9zdHJpbmdfaW50b19zdHJpbmdfbGlz
DQogICAgIGZyZWUocyk7DQogfQ0KIA0KK3N0YXRpYyBpbnQgdmNwdXBpbl9wYXJzZShjaGFyICpj
cHUsIGxpYnhsX2NwdW1hcCAqY3B1bWFwKTsNCisNCiBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdf
ZGF0YShjb25zdCBjaGFyICpjb25maWdmaWxlX2ZpbGVuYW1lX3JlcG9ydCwNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpjb25maWdmaWxlX2RhdGEsDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaW50IGNvbmZpZ2ZpbGVfbGVuLA0KQEAgLTY2MSw2ICs2
NzQsMTMgQEAgc3RhdGljIHZvaWQgcGFyc2VfY29uZmlnX2RhdGEoY29uc3QgY2hhcg0KICAgICBp
ZiAoIXhsdV9jZmdfZ2V0X2xvbmcgKGNvbmZpZywgIm1heHZjcHVzIiwgJmwsIDApKQ0KICAgICAg
ICAgYl9pbmZvLT5tYXhfdmNwdXMgPSBsOw0KIA0KKyAgICBpZiAoIXhsdV9jZmdfZ2V0X3N0cmlu
ZyAoY29uZmlnLCAiY3B1cyIsICZidWYsIDApKSB7DQorICAgICAgICBjaGFyICpidWYyID0gc3Ry
ZHVwKGJ1Zik7DQorICAgICAgICB2Y3B1cGluX3BhcnNlKGJ1ZjIsICZiX2luZm8tPmNwdW1hcCk7
DQorICAgIH0gZWxzZSB7DQorICAgICAgICBtZW1zZXQoYl9pbmZvLT5jcHVtYXAubWFwLCAtMSwg
Yl9pbmZvLT5jcHVtYXAuc2l6ZSk7DQorICAgIH0NCisNCiAgICAgaWYgKCF4bHVfY2ZnX2dldF9s
b25nIChjb25maWcsICJtZW1vcnkiLCAmbCwgMCkpIHsNCiAgICAgICAgIGJfaW5mby0+bWF4X21l
bWtiID0gbCAqIDEwMjQ7DQogICAgICAgICBiX2luZm8tPnRhcmdldF9tZW1rYiA9IGJfaW5mby0+
bWF4X21lbWtiOw0K


--=-bOAc/zXSoQcOhM1YSutG--

--=-b6KUWioMSlndeAHaI1gC
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)

iEYEABECAAYFAk8Nzj8ACgkQk4XaBE3IOsTSbwCfUyzQmlmhn9nFmsAmgl1k6qNc
VdoAoJTbwE6cpBROZAEZ0aftyuWw90Jb
=UPPu
-----END PGP SIGNATURE-----

--=-b6KUWioMSlndeAHaI1gC--



--===============9085282458491062159==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9085282458491062159==--



From xen-devel-bounces@lists.xensource.com Wed Jan 11 18:00:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 18:00:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl2Ta-00039R-GU; Wed, 11 Jan 2012 18:00:42 +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 1Rl2TY-000398-3d
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:00:40 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326304832!10621407!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 32063 invoked from network); 11 Jan 2012 18:00:32 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 18:00:32 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.3.80])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74430659; Wed, 11 Jan 2012 19:00:31 +0100
Message-ID: <1326304831.12973.3.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 18:00:31 +0000
In-Reply-To: <1326304198.2401.6.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============9085282458491062159=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============9085282458491062159==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-b6KUWioMSlndeAHaI1gC"


--=-b6KUWioMSlndeAHaI1gC
Content-Type: multipart/mixed; boundary="=-bOAc/zXSoQcOhM1YSutG"


--=-bOAc/zXSoQcOhM1YSutG
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Enable CPU affinity specification in a VM's config file with the
exact syntax `xl vcpu-pin' provides.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 9ce68a4036b1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 17:38:04 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:40:45 2012 +0000
@@ -78,6 +78,8 @@ int libxl_init_build_info(libxl_ctx *ctx
     memset(b_info, '\0', sizeof(*b_info));
     b_info->max_vcpus =3D 1;
     b_info->cur_vcpus =3D 1;
+    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
+        return ERROR_NOMEM;
     b_info->max_memkb =3D 32 * 1024;
     b_info->target_memkb =3D b_info->max_memkb;
     b_info->disable_migrate =3D 0;
diff -r 9ce68a4036b1 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Jan 11 17:38:04 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Jan 11 17:40:45 2012 +0000
@@ -72,8 +72,14 @@ int libxl__build_pre(libxl__gc *gc, uint
               libxl_domain_build_info *info, libxl__domain_build_state *st=
ate)
 {
     libxl_ctx *ctx =3D libxl__gc_owner(gc);
-    int tsc_mode;
+    int i, tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
+    for (i =3D 0; i < info->max_vcpus; i++) {
+        if (libxl_set_vcpuaffinity(ctx, domid, i, &info->cpumap) =3D=3D -1=
) {
+                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "libxl_set_vcpuaffinit=
y failed. "
+                           "Going ahead without setting affinity for cpu %=
d.\n", i);
+        }
+    }
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM=
_CONSTANT);
     if (info->type =3D=3D LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
diff -r 9ce68a4036b1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 11 17:38:04 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 11 17:40:45 2012 +0000
@@ -162,6 +162,7 @@ libxl_domain_create_info =3D Struct("domai
 libxl_domain_build_info =3D Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
+    ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
diff -r 9ce68a4036b1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:38:04 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:40:45 2012 +0000
@@ -288,16 +288,24 @@ static void dolog(const char *file, int=20
         libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
 }
=20
+static void print_bitmap(uint8_t *map, int maplen, FILE *stream);
+
 static void printf_info(int domid,
                         libxl_domain_config *d_config,
                         libxl_device_model_info *dm_info)
 {
-    int i;
+    int i, nr_cpus =3D -1;
     libxl_dominfo info;
+    libxl_physinfo physinfo;
=20
     libxl_domain_create_info *c_info =3D &d_config->c_info;
     libxl_domain_build_info *b_info =3D &d_config->b_info;
=20
+    if (libxl_get_physinfo(ctx, &physinfo) =3D=3D 0)
+        nr_cpus =3D physinfo.nr_cpus;
+    else
+        fprintf(stderr, "libxl_physinfo failed.\n");
+
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM);
@@ -328,6 +336,9 @@ static void printf_info(int domid,
=20
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
+    printf("\t(CPU affinity ");
+    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);
+    printf(")\n");
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode)=
);
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
@@ -569,6 +580,8 @@ static void split_string_into_string_lis
     free(s);
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -661,6 +674,13 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus =3D l;
=20
+    if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
+        char *buf2 =3D strdup(buf);
+        vcpupin_parse(buf2, &b_info->cpumap);
+    } else {
+        memset(b_info->cpumap.map, -1, b_info->cpumap.size);
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb =3D l * 1024;
         b_info->target_memkb =3D b_info->max_memkb;

--=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)



--=-bOAc/zXSoQcOhM1YSutG
Content-Disposition: attachment; filename="support-cpus-par-in-config-file.patch"
Content-Type: text/x-patch; name="support-cpus-par-in-config-file.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDljZTY4YTQwMzZiMWEwMWIxN2VjZjVkYjBi
ZGU1YzExNDY1NWVjMGINCmxpYnhsOiBhbGxvdyBmb3Igc3BlY2lmeWluZyB0aGUgQ1BVIGFmZmlu
aXR5IGluIHRoZSBjb25maWcgZmlsZS4NCg0KRW5hYmxlIENQVSBhZmZpbml0eSBzcGVjaWZpY2F0
aW9uIGluIGEgVk0ncyBjb25maWcgZmlsZSB3aXRoIHRoZQ0KZXhhY3Qgc3ludGF4IGB4bCB2Y3B1
LXBpbicgcHJvdmlkZXMuDQoNClNpZ25lZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5m
YWdnaW9saUBjaXRyaXguY29tPg0KDQpkaWZmIC1yIDljZTY4YTQwMzZiMSB0b29scy9saWJ4bC9s
aWJ4bF9jcmVhdGUuYw0KLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMJV2VkIEphbiAx
MSAxNzozODowNCAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlX
ZWQgSmFuIDExIDE3OjQwOjQ1IDIwMTIgKzAwMDANCkBAIC03OCw2ICs3OCw4IEBAIGludCBsaWJ4
bF9pbml0X2J1aWxkX2luZm8obGlieGxfY3R4ICpjdHgNCiAgICAgbWVtc2V0KGJfaW5mbywgJ1ww
Jywgc2l6ZW9mKCpiX2luZm8pKTsNCiAgICAgYl9pbmZvLT5tYXhfdmNwdXMgPSAxOw0KICAgICBi
X2luZm8tPmN1cl92Y3B1cyA9IDE7DQorICAgIGlmIChsaWJ4bF9jcHVtYXBfYWxsb2MoY3R4LCAm
Yl9pbmZvLT5jcHVtYXApKQ0KKyAgICAgICAgcmV0dXJuIEVSUk9SX05PTUVNOw0KICAgICBiX2lu
Zm8tPm1heF9tZW1rYiA9IDMyICogMTAyNDsNCiAgICAgYl9pbmZvLT50YXJnZXRfbWVta2IgPSBi
X2luZm8tPm1heF9tZW1rYjsNCiAgICAgYl9pbmZvLT5kaXNhYmxlX21pZ3JhdGUgPSAwOw0KZGlm
ZiAtciA5Y2U2OGE0MDM2YjEgdG9vbHMvbGlieGwvbGlieGxfZG9tLmMNCi0tLSBhL3Rvb2xzL2xp
YnhsL2xpYnhsX2RvbS5jCVdlZCBKYW4gMTEgMTc6Mzg6MDQgMjAxMiArMDAwMA0KKysrIGIvdG9v
bHMvbGlieGwvbGlieGxfZG9tLmMJV2VkIEphbiAxMSAxNzo0MDo0NSAyMDEyICswMDAwDQpAQCAt
NzIsOCArNzIsMTQgQEAgaW50IGxpYnhsX19idWlsZF9wcmUobGlieGxfX2djICpnYywgdWludA0K
ICAgICAgICAgICAgICAgbGlieGxfZG9tYWluX2J1aWxkX2luZm8gKmluZm8sIGxpYnhsX19kb21h
aW5fYnVpbGRfc3RhdGUgKnN0YXRlKQ0KIHsNCiAgICAgbGlieGxfY3R4ICpjdHggPSBsaWJ4bF9f
Z2Nfb3duZXIoZ2MpOw0KLSAgICBpbnQgdHNjX21vZGU7DQorICAgIGludCBpLCB0c2NfbW9kZTsN
CiAgICAgeGNfZG9tYWluX21heF92Y3B1cyhjdHgtPnhjaCwgZG9taWQsIGluZm8tPm1heF92Y3B1
cyk7DQorICAgIGZvciAoaSA9IDA7IGkgPCBpbmZvLT5tYXhfdmNwdXM7IGkrKykgew0KKyAgICAg
ICAgaWYgKGxpYnhsX3NldF92Y3B1YWZmaW5pdHkoY3R4LCBkb21pZCwgaSwgJmluZm8tPmNwdW1h
cCkgPT0gLTEpIHsNCisgICAgICAgICAgICAgICAgTElCWExfX0xPRyhjdHgsIExJQlhMX19MT0df
V0FSTklORywgImxpYnhsX3NldF92Y3B1YWZmaW5pdHkgZmFpbGVkLiAiDQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIkdvaW5nIGFoZWFkIHdpdGhvdXQgc2V0dGluZyBhZmZpbml0eSBmb3Ig
Y3B1ICVkLlxuIiwgaSk7DQorICAgICAgICB9DQorICAgIH0NCiAgICAgeGNfZG9tYWluX3NldG1h
eG1lbShjdHgtPnhjaCwgZG9taWQsIGluZm8tPnRhcmdldF9tZW1rYiArIExJQlhMX01BWE1FTV9D
T05TVEFOVCk7DQogICAgIGlmIChpbmZvLT50eXBlID09IExJQlhMX0RPTUFJTl9UWVBFX1BWKQ0K
ICAgICAgICAgeGNfZG9tYWluX3NldF9tZW1tYXBfbGltaXQoY3R4LT54Y2gsIGRvbWlkLA0KZGlm
ZiAtciA5Y2U2OGE0MDM2YjEgdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsDQotLS0gYS90b29s
cy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJV2VkIEphbiAxMSAxNzozODowNCAyMDEyICswMDAwDQor
KysgYi90b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwJV2VkIEphbiAxMSAxNzo0MDo0NSAyMDEy
ICswMDAwDQpAQCAtMTYyLDYgKzE2Miw3IEBAIGxpYnhsX2RvbWFpbl9jcmVhdGVfaW5mbyA9IFN0
cnVjdCgiZG9tYWkNCiBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyA9IFN0cnVjdCgiZG9tYWluX2J1
aWxkX2luZm8iLFsNCiAgICAgKCJtYXhfdmNwdXMiLCAgICAgICBpbnRlZ2VyKSwNCiAgICAgKCJj
dXJfdmNwdXMiLCAgICAgICBpbnRlZ2VyKSwNCisgICAgKCJjcHVtYXAiLCAgICAgICAgICBsaWJ4
bF9jcHVtYXApLA0KICAgICAoInRzY19tb2RlIiwgICAgICAgIGxpYnhsX3RzY19tb2RlKSwNCiAg
ICAgKCJtYXhfbWVta2IiLCAgICAgICB1aW50MzIpLA0KICAgICAoInRhcmdldF9tZW1rYiIsICAg
IHVpbnQzMiksDQpkaWZmIC1yIDljZTY4YTQwMzZiMSB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMN
Ci0tLSBhL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgSmFuIDExIDE3OjM4OjA0IDIwMTIg
KzAwMDANCisrKyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwlXZWQgSmFuIDExIDE3OjQwOjQ1
IDIwMTIgKzAwMDANCkBAIC0yODgsMTYgKzI4OCwyNCBAQCBzdGF0aWMgdm9pZCBkb2xvZyhjb25z
dCBjaGFyICpmaWxlLCBpbnQgDQogICAgICAgICBsaWJ4bF93cml0ZV9leGFjdGx5KE5VTEwsIGxv
Z2ZpbGUsIHMsIHJjLCBOVUxMLCBOVUxMKTsNCiB9DQogDQorc3RhdGljIHZvaWQgcHJpbnRfYml0
bWFwKHVpbnQ4X3QgKm1hcCwgaW50IG1hcGxlbiwgRklMRSAqc3RyZWFtKTsNCisNCiBzdGF0aWMg
dm9pZCBwcmludGZfaW5mbyhpbnQgZG9taWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgbGli
eGxfZG9tYWluX2NvbmZpZyAqZF9jb25maWcsDQogICAgICAgICAgICAgICAgICAgICAgICAgbGli
eGxfZGV2aWNlX21vZGVsX2luZm8gKmRtX2luZm8pDQogew0KLSAgICBpbnQgaTsNCisgICAgaW50
IGksIG5yX2NwdXMgPSAtMTsNCiAgICAgbGlieGxfZG9taW5mbyBpbmZvOw0KKyAgICBsaWJ4bF9w
aHlzaW5mbyBwaHlzaW5mbzsNCiANCiAgICAgbGlieGxfZG9tYWluX2NyZWF0ZV9pbmZvICpjX2lu
Zm8gPSAmZF9jb25maWctPmNfaW5mbzsNCiAgICAgbGlieGxfZG9tYWluX2J1aWxkX2luZm8gKmJf
aW5mbyA9ICZkX2NvbmZpZy0+Yl9pbmZvOw0KIA0KKyAgICBpZiAobGlieGxfZ2V0X3BoeXNpbmZv
KGN0eCwgJnBoeXNpbmZvKSA9PSAwKQ0KKyAgICAgICAgbnJfY3B1cyA9IHBoeXNpbmZvLm5yX2Nw
dXM7DQorICAgIGVsc2UNCisgICAgICAgIGZwcmludGYoc3RkZXJyLCAibGlieGxfcGh5c2luZm8g
ZmFpbGVkLlxuIik7DQorDQogICAgIHByaW50ZigiKGRvbWFpblxuXHQoZG9taWQgJWQpXG4iLCBk
b21pZCk7DQogICAgIHByaW50ZigiXHQoY3JlYXRlX2luZm8pXG4iKTsNCiAgICAgcHJpbnRmKCJc
dChodm0gJWQpXG4iLCBjX2luZm8tPnR5cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfSFZNKTsNCkBA
IC0zMjgsNiArMzM2LDkgQEAgc3RhdGljIHZvaWQgcHJpbnRmX2luZm8oaW50IGRvbWlkLA0KIA0K
ICAgICBwcmludGYoIlx0KGJ1aWxkX2luZm8pXG4iKTsNCiAgICAgcHJpbnRmKCJcdChtYXhfdmNw
dXMgJWQpXG4iLCBiX2luZm8tPm1heF92Y3B1cyk7DQorICAgIHByaW50ZigiXHQoQ1BVIGFmZmlu
aXR5ICIpOw0KKyAgICBwcmludF9iaXRtYXAoYl9pbmZvLT5jcHVtYXAubWFwLCBucl9jcHVzLCBz
dGRvdXQpOw0KKyAgICBwcmludGYoIilcbiIpOw0KICAgICBwcmludGYoIlx0KHRzY19tb2RlICVz
KVxuIiwgbGlieGxfdHNjX21vZGVfdG9fc3RyaW5nKGJfaW5mby0+dHNjX21vZGUpKTsNCiAgICAg
cHJpbnRmKCJcdChtYXhfbWVta2IgJWQpXG4iLCBiX2luZm8tPm1heF9tZW1rYik7DQogICAgIHBy
aW50ZigiXHQodGFyZ2V0X21lbWtiICVkKVxuIiwgYl9pbmZvLT50YXJnZXRfbWVta2IpOw0KQEAg
LTU2OSw2ICs1ODAsOCBAQCBzdGF0aWMgdm9pZCBzcGxpdF9zdHJpbmdfaW50b19zdHJpbmdfbGlz
DQogICAgIGZyZWUocyk7DQogfQ0KIA0KK3N0YXRpYyBpbnQgdmNwdXBpbl9wYXJzZShjaGFyICpj
cHUsIGxpYnhsX2NwdW1hcCAqY3B1bWFwKTsNCisNCiBzdGF0aWMgdm9pZCBwYXJzZV9jb25maWdf
ZGF0YShjb25zdCBjaGFyICpjb25maWdmaWxlX2ZpbGVuYW1lX3JlcG9ydCwNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBjb25zdCBjaGFyICpjb25maWdmaWxlX2RhdGEsDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaW50IGNvbmZpZ2ZpbGVfbGVuLA0KQEAgLTY2MSw2ICs2
NzQsMTMgQEAgc3RhdGljIHZvaWQgcGFyc2VfY29uZmlnX2RhdGEoY29uc3QgY2hhcg0KICAgICBp
ZiAoIXhsdV9jZmdfZ2V0X2xvbmcgKGNvbmZpZywgIm1heHZjcHVzIiwgJmwsIDApKQ0KICAgICAg
ICAgYl9pbmZvLT5tYXhfdmNwdXMgPSBsOw0KIA0KKyAgICBpZiAoIXhsdV9jZmdfZ2V0X3N0cmlu
ZyAoY29uZmlnLCAiY3B1cyIsICZidWYsIDApKSB7DQorICAgICAgICBjaGFyICpidWYyID0gc3Ry
ZHVwKGJ1Zik7DQorICAgICAgICB2Y3B1cGluX3BhcnNlKGJ1ZjIsICZiX2luZm8tPmNwdW1hcCk7
DQorICAgIH0gZWxzZSB7DQorICAgICAgICBtZW1zZXQoYl9pbmZvLT5jcHVtYXAubWFwLCAtMSwg
Yl9pbmZvLT5jcHVtYXAuc2l6ZSk7DQorICAgIH0NCisNCiAgICAgaWYgKCF4bHVfY2ZnX2dldF9s
b25nIChjb25maWcsICJtZW1vcnkiLCAmbCwgMCkpIHsNCiAgICAgICAgIGJfaW5mby0+bWF4X21l
bWtiID0gbCAqIDEwMjQ7DQogICAgICAgICBiX2luZm8tPnRhcmdldF9tZW1rYiA9IGJfaW5mby0+
bWF4X21lbWtiOw0K


--=-bOAc/zXSoQcOhM1YSutG--

--=-b6KUWioMSlndeAHaI1gC
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)

iEYEABECAAYFAk8Nzj8ACgkQk4XaBE3IOsTSbwCfUyzQmlmhn9nFmsAmgl1k6qNc
VdoAoJTbwE6cpBROZAEZ0aftyuWw90Jb
=UPPu
-----END PGP SIGNATURE-----

--=-b6KUWioMSlndeAHaI1gC--



--===============9085282458491062159==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9085282458491062159==--



From xen-devel-bounces@lists.xensource.com Wed Jan 11 18:02:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 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 1Rl2V0-0003JZ-CB; Wed, 11 Jan 2012 18:02:10 +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 1Rl2Uy-0003Ia-Kk
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:02:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326304921!2778559!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 12880 invoked from network); 11 Jan 2012 18:02:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 18:02:01 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.3.80])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74430680; Wed, 11 Jan 2012 19:02:00 +0100
Message-ID: <1326304919.12973.5.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 18:01:59 +0000
In-Reply-To: <1326304198.2401.6.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] libxl: Align examples with current code.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6288012544328851556=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6288012544328851556==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-kAYgasmKBl9sKJO0wAYY"


--=-kAYgasmKBl9sKJO0wAYY
Content-Type: multipart/mixed; boundary="=-1vLiKAUMVhc3Ke1u4zse"


--=-1vLiKAUMVhc3Ke1u4zse
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just make sure the syntax proposed in the various examples is
the right one.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm
--- a/tools/examples/xmexample.hvm	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample.hvm	Wed Jan 11 17:32:34 2012 +0000
@@ -59,10 +59,8 @@ name =3D "ExampleHVMDomain"
 # xen_extended_power_mgmt=3D0
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Optionally define mac and/or bridge for the network interfaces.
 # Random MACs are assigned if not given.
diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm-stubdom
--- a/tools/examples/xmexample.hvm-stubdom	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample.hvm-stubdom	Wed Jan 11 17:32:34 2012 +0000
@@ -50,10 +50,8 @@ name =3D "xmexample.hvm"
 #apic=3D1
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Optionally define mac and/or bridge for the network interfaces.
 # Random MACs are assigned if not given.
diff -r 897ea4d3c2d7 tools/examples/xmexample.pv-grub
--- a/tools/examples/xmexample.pv-grub	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample.pv-grub	Wed Jan 11 17:32:34 2012 +0000
@@ -35,10 +35,8 @@ name =3D "ExampleDomain"
 #uuid =3D "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Number of Virtual CPUS to use, default is 1
 #vcpus =3D 1
diff -r 897ea4d3c2d7 tools/examples/xmexample.vti
--- a/tools/examples/xmexample.vti	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample.vti	Wed Jan 11 17:32:34 2012 +0000
@@ -31,10 +31,8 @@ name =3D "ExampleVTIDomain"
 #vcpus=3D1
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Log2 of VHPT size, default=3D23 (8MB), minimum=3D15 (32KB).
 # In Windows OS, smaller size shows better performance.
diff -r 897ea4d3c2d7 tools/examples/xmexample1
--- a/tools/examples/xmexample1	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample1	Wed Jan 11 17:32:34 2012 +0000
@@ -31,10 +31,8 @@ name =3D "ExampleDomain"
 #uuid =3D "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Number of Virtual CPUS to use, default is 1
 #vcpus =3D 1
diff -r 897ea4d3c2d7 tools/examples/xmexample2
--- a/tools/examples/xmexample2	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample2	Wed Jan 11 17:32:34 2012 +0000
@@ -60,11 +60,8 @@ name =3D "VM%d" % vmid
 #uuid =3D "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
-#cpus =3D "%s" % vmid # set based on vmid (mod number of CPUs)
=20
 # Number of Virtual CPUS to use, default is 1
 #vcpus =3D 1
diff -r 897ea4d3c2d7 tools/examples/xmexample3
--- a/tools/examples/xmexample3	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample3	Wed Jan 11 17:32:34 2012 +0000
@@ -60,11 +60,8 @@ name =3D "VM%d" % vmid
 #uuid =3D "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
-cpus =3D "%s" % vmid # set based on vmid (mod number of CPUs)
=20
 #-------------------------------------------------------------------------=
---
 # Define network interfaces.

--=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)



--=-1vLiKAUMVhc3Ke1u4zse
Content-Disposition: attachment; filename="adjust-examples.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="adjust-examples.patch"; charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDg5N2VhNGQzYzJkNzYxNzQ0MmU0Yjk3YTcy
MzcwNDY0Y2Y3ZmM5M2YNCmxpYnhsOiBBbGlnbiBleGFtcGxlcyB3aXRoIGN1cnJlbnQgY29kZS4N
Cg0KSnVzdCBtYWtlIHN1cmUgdGhlIHN5bnRheCBwcm9wb3NlZCBpbiB0aGUgdmFyaW91cyBleGFt
cGxlcyBpcw0KdGhlIHJpZ2h0IG9uZS4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkg
PGRhcmlvLmZhZ2dpb2xpQGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgODk3ZWE0ZDNjMmQ3IHRvb2xz
L2V4YW1wbGVzL3htZXhhbXBsZS5odm0NCi0tLSBhL3Rvb2xzL2V4YW1wbGVzL3htZXhhbXBsZS5o
dm0JV2VkIEphbiAxMSAxNzoyODo1MyAyMDEyICswMDAwDQorKysgYi90b29scy9leGFtcGxlcy94
bWV4YW1wbGUuaHZtCVdlZCBKYW4gMTEgMTc6MzI6MzQgMjAxMiArMDAwMA0KQEAgLTU5LDEwICs1
OSw4IEBAIG5hbWUgPSAiRXhhbXBsZUhWTURvbWFpbiINCiAjIHhlbl9leHRlbmRlZF9wb3dlcl9t
Z210PTANCiANCiAjIExpc3Qgb2Ygd2hpY2ggQ1BVUyB0aGlzIGRvbWFpbiBpcyBhbGxvd2VkIHRv
IHVzZSwgZGVmYXVsdCBYZW4gcGlja3MNCi0jY3B1cyA9ICIiICAgICAgICAgIyBsZWF2ZSB0byBY
ZW4gdG8gcGljaw0KICNjcHVzID0gIjAiICAgICAgICAjIGFsbCB2Y3B1cyBydW4gb24gQ1BVMA0K
ICNjcHVzID0gIjAtMyw1LF4xIiAjIGFsbCB2Y3B1cyBydW4gb24gY3B1cyAwLDIsMyw1DQotI2Nw
dXMgPSBbIjIiLCAiMyJdICMgVkNQVTAgcnVucyBvbiBDUFUyLCBWQ1BVMSBydW5zIG9uIENQVTMN
CiANCiAjIE9wdGlvbmFsbHkgZGVmaW5lIG1hYyBhbmQvb3IgYnJpZGdlIGZvciB0aGUgbmV0d29y
ayBpbnRlcmZhY2VzLg0KICMgUmFuZG9tIE1BQ3MgYXJlIGFzc2lnbmVkIGlmIG5vdCBnaXZlbi4N
CmRpZmYgLXIgODk3ZWE0ZDNjMmQ3IHRvb2xzL2V4YW1wbGVzL3htZXhhbXBsZS5odm0tc3R1YmRv
bQ0KLS0tIGEvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxlLmh2bS1zdHViZG9tCVdlZCBKYW4gMTEg
MTc6Mjg6NTMgMjAxMiArMDAwMA0KKysrIGIvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxlLmh2bS1z
dHViZG9tCVdlZCBKYW4gMTEgMTc6MzI6MzQgMjAxMiArMDAwMA0KQEAgLTUwLDEwICs1MCw4IEBA
IG5hbWUgPSAieG1leGFtcGxlLmh2bSINCiAjYXBpYz0xDQogDQogIyBMaXN0IG9mIHdoaWNoIENQ
VVMgdGhpcyBkb21haW4gaXMgYWxsb3dlZCB0byB1c2UsIGRlZmF1bHQgWGVuIHBpY2tzDQotI2Nw
dXMgPSAiIiAgICAgICAgICMgbGVhdmUgdG8gWGVuIHRvIHBpY2sNCiAjY3B1cyA9ICIwIiAgICAg
ICAgIyBhbGwgdmNwdXMgcnVuIG9uIENQVTANCiAjY3B1cyA9ICIwLTMsNSxeMSIgIyBhbGwgdmNw
dXMgcnVuIG9uIGNwdXMgMCwyLDMsNQ0KLSNjcHVzID0gWyIyIiwgIjMiXSAjIFZDUFUwIHJ1bnMg
b24gQ1BVMiwgVkNQVTEgcnVucyBvbiBDUFUzDQogDQogIyBPcHRpb25hbGx5IGRlZmluZSBtYWMg
YW5kL29yIGJyaWRnZSBmb3IgdGhlIG5ldHdvcmsgaW50ZXJmYWNlcy4NCiAjIFJhbmRvbSBNQUNz
IGFyZSBhc3NpZ25lZCBpZiBub3QgZ2l2ZW4uDQpkaWZmIC1yIDg5N2VhNGQzYzJkNyB0b29scy9l
eGFtcGxlcy94bWV4YW1wbGUucHYtZ3J1Yg0KLS0tIGEvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxl
LnB2LWdydWIJV2VkIEphbiAxMSAxNzoyODo1MyAyMDEyICswMDAwDQorKysgYi90b29scy9leGFt
cGxlcy94bWV4YW1wbGUucHYtZ3J1YglXZWQgSmFuIDExIDE3OjMyOjM0IDIwMTIgKzAwMDANCkBA
IC0zNSwxMCArMzUsOCBAQCBuYW1lID0gIkV4YW1wbGVEb21haW4iDQogI3V1aWQgPSAiMDZlZDAw
ZmUtMTE2Mi00ZmM0LWI1ZDgtMTE5OTNlZTRhOGI5Ig0KIA0KICMgTGlzdCBvZiB3aGljaCBDUFVT
IHRoaXMgZG9tYWluIGlzIGFsbG93ZWQgdG8gdXNlLCBkZWZhdWx0IFhlbiBwaWNrcw0KLSNjcHVz
ID0gIiIgICAgICAgICAjIGxlYXZlIHRvIFhlbiB0byBwaWNrDQogI2NwdXMgPSAiMCIgICAgICAg
ICMgYWxsIHZjcHVzIHJ1biBvbiBDUFUwDQogI2NwdXMgPSAiMC0zLDUsXjEiICMgYWxsIHZjcHVz
IHJ1biBvbiBjcHVzIDAsMiwzLDUNCi0jY3B1cyA9IFsiMiIsICIzIl0gIyBWQ1BVMCBydW5zIG9u
IENQVTIsIFZDUFUxIHJ1bnMgb24gQ1BVMw0KIA0KICMgTnVtYmVyIG9mIFZpcnR1YWwgQ1BVUyB0
byB1c2UsIGRlZmF1bHQgaXMgMQ0KICN2Y3B1cyA9IDENCmRpZmYgLXIgODk3ZWE0ZDNjMmQ3IHRv
b2xzL2V4YW1wbGVzL3htZXhhbXBsZS52dGkNCi0tLSBhL3Rvb2xzL2V4YW1wbGVzL3htZXhhbXBs
ZS52dGkJV2VkIEphbiAxMSAxNzoyODo1MyAyMDEyICswMDAwDQorKysgYi90b29scy9leGFtcGxl
cy94bWV4YW1wbGUudnRpCVdlZCBKYW4gMTEgMTc6MzI6MzQgMjAxMiArMDAwMA0KQEAgLTMxLDEw
ICszMSw4IEBAIG5hbWUgPSAiRXhhbXBsZVZUSURvbWFpbiINCiAjdmNwdXM9MQ0KIA0KICMgTGlz
dCBvZiB3aGljaCBDUFVTIHRoaXMgZG9tYWluIGlzIGFsbG93ZWQgdG8gdXNlLCBkZWZhdWx0IFhl
biBwaWNrcw0KLSNjcHVzID0gIiIgICAgICAgICAjIGxlYXZlIHRvIFhlbiB0byBwaWNrDQogI2Nw
dXMgPSAiMCIgICAgICAgICMgYWxsIHZjcHVzIHJ1biBvbiBDUFUwDQogI2NwdXMgPSAiMC0zLDUs
XjEiICMgYWxsIHZjcHVzIHJ1biBvbiBjcHVzIDAsMiwzLDUNCi0jY3B1cyA9IFsiMiIsICIzIl0g
IyBWQ1BVMCBydW5zIG9uIENQVTIsIFZDUFUxIHJ1bnMgb24gQ1BVMw0KIA0KICMgTG9nMiBvZiBW
SFBUIHNpemUsIGRlZmF1bHQ9MjMgKDhNQiksIG1pbmltdW09MTUgKDMyS0IpLg0KICMgSW4gV2lu
ZG93cyBPUywgc21hbGxlciBzaXplIHNob3dzIGJldHRlciBwZXJmb3JtYW5jZS4NCmRpZmYgLXIg
ODk3ZWE0ZDNjMmQ3IHRvb2xzL2V4YW1wbGVzL3htZXhhbXBsZTENCi0tLSBhL3Rvb2xzL2V4YW1w
bGVzL3htZXhhbXBsZTEJV2VkIEphbiAxMSAxNzoyODo1MyAyMDEyICswMDAwDQorKysgYi90b29s
cy9leGFtcGxlcy94bWV4YW1wbGUxCVdlZCBKYW4gMTEgMTc6MzI6MzQgMjAxMiArMDAwMA0KQEAg
LTMxLDEwICszMSw4IEBAIG5hbWUgPSAiRXhhbXBsZURvbWFpbiINCiAjdXVpZCA9ICIwNmVkMDBm
ZS0xMTYyLTRmYzQtYjVkOC0xMTk5M2VlNGE4YjkiDQogDQogIyBMaXN0IG9mIHdoaWNoIENQVVMg
dGhpcyBkb21haW4gaXMgYWxsb3dlZCB0byB1c2UsIGRlZmF1bHQgWGVuIHBpY2tzDQotI2NwdXMg
PSAiIiAgICAgICAgICMgbGVhdmUgdG8gWGVuIHRvIHBpY2sNCiAjY3B1cyA9ICIwIiAgICAgICAg
IyBhbGwgdmNwdXMgcnVuIG9uIENQVTANCiAjY3B1cyA9ICIwLTMsNSxeMSIgIyBhbGwgdmNwdXMg
cnVuIG9uIGNwdXMgMCwyLDMsNQ0KLSNjcHVzID0gWyIyIiwgIjMiXSAjIFZDUFUwIHJ1bnMgb24g
Q1BVMiwgVkNQVTEgcnVucyBvbiBDUFUzDQogDQogIyBOdW1iZXIgb2YgVmlydHVhbCBDUFVTIHRv
IHVzZSwgZGVmYXVsdCBpcyAxDQogI3ZjcHVzID0gMQ0KZGlmZiAtciA4OTdlYTRkM2MyZDcgdG9v
bHMvZXhhbXBsZXMveG1leGFtcGxlMg0KLS0tIGEvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxlMglX
ZWQgSmFuIDExIDE3OjI4OjUzIDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2V4YW1wbGVzL3htZXhh
bXBsZTIJV2VkIEphbiAxMSAxNzozMjozNCAyMDEyICswMDAwDQpAQCAtNjAsMTEgKzYwLDggQEAg
bmFtZSA9ICJWTSVkIiAlIHZtaWQNCiAjdXVpZCA9ICIwNmVkMDBmZS0xMTYyLTRmYzQtYjVkOC0x
MTk5M2VlNGE4YjkiDQogDQogIyBMaXN0IG9mIHdoaWNoIENQVVMgdGhpcyBkb21haW4gaXMgYWxs
b3dlZCB0byB1c2UsIGRlZmF1bHQgWGVuIHBpY2tzDQotI2NwdXMgPSAiIiAgICAgICAgICMgbGVh
dmUgdG8gWGVuIHRvIHBpY2sNCiAjY3B1cyA9ICIwIiAgICAgICAgIyBhbGwgdmNwdXMgcnVuIG9u
IENQVTANCiAjY3B1cyA9ICIwLTMsNSxeMSIgIyBhbGwgdmNwdXMgcnVuIG9uIGNwdXMgMCwyLDMs
NQ0KLSNjcHVzID0gWyIyIiwgIjMiXSAjIFZDUFUwIHJ1bnMgb24gQ1BVMiwgVkNQVTEgcnVucyBv
biBDUFUzDQotI2NwdXMgPSAiJXMiICUgdm1pZCAjIHNldCBiYXNlZCBvbiB2bWlkIChtb2QgbnVt
YmVyIG9mIENQVXMpDQogDQogIyBOdW1iZXIgb2YgVmlydHVhbCBDUFVTIHRvIHVzZSwgZGVmYXVs
dCBpcyAxDQogI3ZjcHVzID0gMQ0KZGlmZiAtciA4OTdlYTRkM2MyZDcgdG9vbHMvZXhhbXBsZXMv
eG1leGFtcGxlMw0KLS0tIGEvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxlMwlXZWQgSmFuIDExIDE3
OjI4OjUzIDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2V4YW1wbGVzL3htZXhhbXBsZTMJV2VkIEph
biAxMSAxNzozMjozNCAyMDEyICswMDAwDQpAQCAtNjAsMTEgKzYwLDggQEAgbmFtZSA9ICJWTSVk
IiAlIHZtaWQNCiAjdXVpZCA9ICIwNmVkMDBmZS0xMTYyLTRmYzQtYjVkOC0xMTk5M2VlNGE4Yjki
DQogDQogIyBMaXN0IG9mIHdoaWNoIENQVVMgdGhpcyBkb21haW4gaXMgYWxsb3dlZCB0byB1c2Us
IGRlZmF1bHQgWGVuIHBpY2tzDQotI2NwdXMgPSAiIiAgICAgICAgICMgbGVhdmUgdG8gWGVuIHRv
IHBpY2sNCiAjY3B1cyA9ICIwIiAgICAgICAgIyBhbGwgdmNwdXMgcnVuIG9uIENQVTANCiAjY3B1
cyA9ICIwLTMsNSxeMSIgIyBhbGwgdmNwdXMgcnVuIG9uIGNwdXMgMCwyLDMsNQ0KLSNjcHVzID0g
WyIyIiwgIjMiXSAjIFZDUFUwIHJ1bnMgb24gQ1BVMiwgVkNQVTEgcnVucyBvbiBDUFUzDQotY3B1
cyA9ICIlcyIgJSB2bWlkICMgc2V0IGJhc2VkIG9uIHZtaWQgKG1vZCBudW1iZXIgb2YgQ1BVcykN
CiANCiAjLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICMgRGVmaW5lIG5ldHdvcmsgaW50ZXJmYWNlcy4N
Cg==


--=-1vLiKAUMVhc3Ke1u4zse--

--=-kAYgasmKBl9sKJO0wAYY
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)

iEYEABECAAYFAk8NzpcACgkQk4XaBE3IOsTY4wCdFIwyH6bQsa/kM3qcasrxrj3d
HqoAn0W7hWCNNXNq86QiHfK5lI+GgQbB
=ntXt
-----END PGP SIGNATURE-----

--=-kAYgasmKBl9sKJO0wAYY--



--===============6288012544328851556==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6288012544328851556==--



From xen-devel-bounces@lists.xensource.com Wed Jan 11 18:02:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 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 1Rl2V0-0003JZ-CB; Wed, 11 Jan 2012 18:02:10 +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 1Rl2Uy-0003Ia-Kk
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:02:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326304921!2778559!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 12880 invoked from network); 11 Jan 2012 18:02:01 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-21.messagelabs.com with SMTP;
	11 Jan 2012 18:02:01 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.3.80])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74430680; Wed, 11 Jan 2012 19:02:00 +0100
Message-ID: <1326304919.12973.5.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 18:01:59 +0000
In-Reply-To: <1326304198.2401.6.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3 of 3] libxl: Align examples with current code.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6288012544328851556=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6288012544328851556==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-kAYgasmKBl9sKJO0wAYY"


--=-kAYgasmKBl9sKJO0wAYY
Content-Type: multipart/mixed; boundary="=-1vLiKAUMVhc3Ke1u4zse"


--=-1vLiKAUMVhc3Ke1u4zse
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just make sure the syntax proposed in the various examples is
the right one.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm
--- a/tools/examples/xmexample.hvm	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample.hvm	Wed Jan 11 17:32:34 2012 +0000
@@ -59,10 +59,8 @@ name =3D "ExampleHVMDomain"
 # xen_extended_power_mgmt=3D0
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Optionally define mac and/or bridge for the network interfaces.
 # Random MACs are assigned if not given.
diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm-stubdom
--- a/tools/examples/xmexample.hvm-stubdom	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample.hvm-stubdom	Wed Jan 11 17:32:34 2012 +0000
@@ -50,10 +50,8 @@ name =3D "xmexample.hvm"
 #apic=3D1
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Optionally define mac and/or bridge for the network interfaces.
 # Random MACs are assigned if not given.
diff -r 897ea4d3c2d7 tools/examples/xmexample.pv-grub
--- a/tools/examples/xmexample.pv-grub	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample.pv-grub	Wed Jan 11 17:32:34 2012 +0000
@@ -35,10 +35,8 @@ name =3D "ExampleDomain"
 #uuid =3D "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Number of Virtual CPUS to use, default is 1
 #vcpus =3D 1
diff -r 897ea4d3c2d7 tools/examples/xmexample.vti
--- a/tools/examples/xmexample.vti	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample.vti	Wed Jan 11 17:32:34 2012 +0000
@@ -31,10 +31,8 @@ name =3D "ExampleVTIDomain"
 #vcpus=3D1
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Log2 of VHPT size, default=3D23 (8MB), minimum=3D15 (32KB).
 # In Windows OS, smaller size shows better performance.
diff -r 897ea4d3c2d7 tools/examples/xmexample1
--- a/tools/examples/xmexample1	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample1	Wed Jan 11 17:32:34 2012 +0000
@@ -31,10 +31,8 @@ name =3D "ExampleDomain"
 #uuid =3D "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
=20
 # Number of Virtual CPUS to use, default is 1
 #vcpus =3D 1
diff -r 897ea4d3c2d7 tools/examples/xmexample2
--- a/tools/examples/xmexample2	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample2	Wed Jan 11 17:32:34 2012 +0000
@@ -60,11 +60,8 @@ name =3D "VM%d" % vmid
 #uuid =3D "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
-#cpus =3D "%s" % vmid # set based on vmid (mod number of CPUs)
=20
 # Number of Virtual CPUS to use, default is 1
 #vcpus =3D 1
diff -r 897ea4d3c2d7 tools/examples/xmexample3
--- a/tools/examples/xmexample3	Wed Jan 11 17:28:53 2012 +0000
+++ b/tools/examples/xmexample3	Wed Jan 11 17:32:34 2012 +0000
@@ -60,11 +60,8 @@ name =3D "VM%d" % vmid
 #uuid =3D "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
=20
 # List of which CPUS this domain is allowed to use, default Xen picks
-#cpus =3D ""         # leave to Xen to pick
 #cpus =3D "0"        # all vcpus run on CPU0
 #cpus =3D "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
-#cpus =3D ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
-cpus =3D "%s" % vmid # set based on vmid (mod number of CPUs)
=20
 #-------------------------------------------------------------------------=
---
 # Define network interfaces.

--=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)



--=-1vLiKAUMVhc3Ke1u4zse
Content-Disposition: attachment; filename="adjust-examples.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="adjust-examples.patch"; charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDg5N2VhNGQzYzJkNzYxNzQ0MmU0Yjk3YTcy
MzcwNDY0Y2Y3ZmM5M2YNCmxpYnhsOiBBbGlnbiBleGFtcGxlcyB3aXRoIGN1cnJlbnQgY29kZS4N
Cg0KSnVzdCBtYWtlIHN1cmUgdGhlIHN5bnRheCBwcm9wb3NlZCBpbiB0aGUgdmFyaW91cyBleGFt
cGxlcyBpcw0KdGhlIHJpZ2h0IG9uZS4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkg
PGRhcmlvLmZhZ2dpb2xpQGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgODk3ZWE0ZDNjMmQ3IHRvb2xz
L2V4YW1wbGVzL3htZXhhbXBsZS5odm0NCi0tLSBhL3Rvb2xzL2V4YW1wbGVzL3htZXhhbXBsZS5o
dm0JV2VkIEphbiAxMSAxNzoyODo1MyAyMDEyICswMDAwDQorKysgYi90b29scy9leGFtcGxlcy94
bWV4YW1wbGUuaHZtCVdlZCBKYW4gMTEgMTc6MzI6MzQgMjAxMiArMDAwMA0KQEAgLTU5LDEwICs1
OSw4IEBAIG5hbWUgPSAiRXhhbXBsZUhWTURvbWFpbiINCiAjIHhlbl9leHRlbmRlZF9wb3dlcl9t
Z210PTANCiANCiAjIExpc3Qgb2Ygd2hpY2ggQ1BVUyB0aGlzIGRvbWFpbiBpcyBhbGxvd2VkIHRv
IHVzZSwgZGVmYXVsdCBYZW4gcGlja3MNCi0jY3B1cyA9ICIiICAgICAgICAgIyBsZWF2ZSB0byBY
ZW4gdG8gcGljaw0KICNjcHVzID0gIjAiICAgICAgICAjIGFsbCB2Y3B1cyBydW4gb24gQ1BVMA0K
ICNjcHVzID0gIjAtMyw1LF4xIiAjIGFsbCB2Y3B1cyBydW4gb24gY3B1cyAwLDIsMyw1DQotI2Nw
dXMgPSBbIjIiLCAiMyJdICMgVkNQVTAgcnVucyBvbiBDUFUyLCBWQ1BVMSBydW5zIG9uIENQVTMN
CiANCiAjIE9wdGlvbmFsbHkgZGVmaW5lIG1hYyBhbmQvb3IgYnJpZGdlIGZvciB0aGUgbmV0d29y
ayBpbnRlcmZhY2VzLg0KICMgUmFuZG9tIE1BQ3MgYXJlIGFzc2lnbmVkIGlmIG5vdCBnaXZlbi4N
CmRpZmYgLXIgODk3ZWE0ZDNjMmQ3IHRvb2xzL2V4YW1wbGVzL3htZXhhbXBsZS5odm0tc3R1YmRv
bQ0KLS0tIGEvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxlLmh2bS1zdHViZG9tCVdlZCBKYW4gMTEg
MTc6Mjg6NTMgMjAxMiArMDAwMA0KKysrIGIvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxlLmh2bS1z
dHViZG9tCVdlZCBKYW4gMTEgMTc6MzI6MzQgMjAxMiArMDAwMA0KQEAgLTUwLDEwICs1MCw4IEBA
IG5hbWUgPSAieG1leGFtcGxlLmh2bSINCiAjYXBpYz0xDQogDQogIyBMaXN0IG9mIHdoaWNoIENQ
VVMgdGhpcyBkb21haW4gaXMgYWxsb3dlZCB0byB1c2UsIGRlZmF1bHQgWGVuIHBpY2tzDQotI2Nw
dXMgPSAiIiAgICAgICAgICMgbGVhdmUgdG8gWGVuIHRvIHBpY2sNCiAjY3B1cyA9ICIwIiAgICAg
ICAgIyBhbGwgdmNwdXMgcnVuIG9uIENQVTANCiAjY3B1cyA9ICIwLTMsNSxeMSIgIyBhbGwgdmNw
dXMgcnVuIG9uIGNwdXMgMCwyLDMsNQ0KLSNjcHVzID0gWyIyIiwgIjMiXSAjIFZDUFUwIHJ1bnMg
b24gQ1BVMiwgVkNQVTEgcnVucyBvbiBDUFUzDQogDQogIyBPcHRpb25hbGx5IGRlZmluZSBtYWMg
YW5kL29yIGJyaWRnZSBmb3IgdGhlIG5ldHdvcmsgaW50ZXJmYWNlcy4NCiAjIFJhbmRvbSBNQUNz
IGFyZSBhc3NpZ25lZCBpZiBub3QgZ2l2ZW4uDQpkaWZmIC1yIDg5N2VhNGQzYzJkNyB0b29scy9l
eGFtcGxlcy94bWV4YW1wbGUucHYtZ3J1Yg0KLS0tIGEvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxl
LnB2LWdydWIJV2VkIEphbiAxMSAxNzoyODo1MyAyMDEyICswMDAwDQorKysgYi90b29scy9leGFt
cGxlcy94bWV4YW1wbGUucHYtZ3J1YglXZWQgSmFuIDExIDE3OjMyOjM0IDIwMTIgKzAwMDANCkBA
IC0zNSwxMCArMzUsOCBAQCBuYW1lID0gIkV4YW1wbGVEb21haW4iDQogI3V1aWQgPSAiMDZlZDAw
ZmUtMTE2Mi00ZmM0LWI1ZDgtMTE5OTNlZTRhOGI5Ig0KIA0KICMgTGlzdCBvZiB3aGljaCBDUFVT
IHRoaXMgZG9tYWluIGlzIGFsbG93ZWQgdG8gdXNlLCBkZWZhdWx0IFhlbiBwaWNrcw0KLSNjcHVz
ID0gIiIgICAgICAgICAjIGxlYXZlIHRvIFhlbiB0byBwaWNrDQogI2NwdXMgPSAiMCIgICAgICAg
ICMgYWxsIHZjcHVzIHJ1biBvbiBDUFUwDQogI2NwdXMgPSAiMC0zLDUsXjEiICMgYWxsIHZjcHVz
IHJ1biBvbiBjcHVzIDAsMiwzLDUNCi0jY3B1cyA9IFsiMiIsICIzIl0gIyBWQ1BVMCBydW5zIG9u
IENQVTIsIFZDUFUxIHJ1bnMgb24gQ1BVMw0KIA0KICMgTnVtYmVyIG9mIFZpcnR1YWwgQ1BVUyB0
byB1c2UsIGRlZmF1bHQgaXMgMQ0KICN2Y3B1cyA9IDENCmRpZmYgLXIgODk3ZWE0ZDNjMmQ3IHRv
b2xzL2V4YW1wbGVzL3htZXhhbXBsZS52dGkNCi0tLSBhL3Rvb2xzL2V4YW1wbGVzL3htZXhhbXBs
ZS52dGkJV2VkIEphbiAxMSAxNzoyODo1MyAyMDEyICswMDAwDQorKysgYi90b29scy9leGFtcGxl
cy94bWV4YW1wbGUudnRpCVdlZCBKYW4gMTEgMTc6MzI6MzQgMjAxMiArMDAwMA0KQEAgLTMxLDEw
ICszMSw4IEBAIG5hbWUgPSAiRXhhbXBsZVZUSURvbWFpbiINCiAjdmNwdXM9MQ0KIA0KICMgTGlz
dCBvZiB3aGljaCBDUFVTIHRoaXMgZG9tYWluIGlzIGFsbG93ZWQgdG8gdXNlLCBkZWZhdWx0IFhl
biBwaWNrcw0KLSNjcHVzID0gIiIgICAgICAgICAjIGxlYXZlIHRvIFhlbiB0byBwaWNrDQogI2Nw
dXMgPSAiMCIgICAgICAgICMgYWxsIHZjcHVzIHJ1biBvbiBDUFUwDQogI2NwdXMgPSAiMC0zLDUs
XjEiICMgYWxsIHZjcHVzIHJ1biBvbiBjcHVzIDAsMiwzLDUNCi0jY3B1cyA9IFsiMiIsICIzIl0g
IyBWQ1BVMCBydW5zIG9uIENQVTIsIFZDUFUxIHJ1bnMgb24gQ1BVMw0KIA0KICMgTG9nMiBvZiBW
SFBUIHNpemUsIGRlZmF1bHQ9MjMgKDhNQiksIG1pbmltdW09MTUgKDMyS0IpLg0KICMgSW4gV2lu
ZG93cyBPUywgc21hbGxlciBzaXplIHNob3dzIGJldHRlciBwZXJmb3JtYW5jZS4NCmRpZmYgLXIg
ODk3ZWE0ZDNjMmQ3IHRvb2xzL2V4YW1wbGVzL3htZXhhbXBsZTENCi0tLSBhL3Rvb2xzL2V4YW1w
bGVzL3htZXhhbXBsZTEJV2VkIEphbiAxMSAxNzoyODo1MyAyMDEyICswMDAwDQorKysgYi90b29s
cy9leGFtcGxlcy94bWV4YW1wbGUxCVdlZCBKYW4gMTEgMTc6MzI6MzQgMjAxMiArMDAwMA0KQEAg
LTMxLDEwICszMSw4IEBAIG5hbWUgPSAiRXhhbXBsZURvbWFpbiINCiAjdXVpZCA9ICIwNmVkMDBm
ZS0xMTYyLTRmYzQtYjVkOC0xMTk5M2VlNGE4YjkiDQogDQogIyBMaXN0IG9mIHdoaWNoIENQVVMg
dGhpcyBkb21haW4gaXMgYWxsb3dlZCB0byB1c2UsIGRlZmF1bHQgWGVuIHBpY2tzDQotI2NwdXMg
PSAiIiAgICAgICAgICMgbGVhdmUgdG8gWGVuIHRvIHBpY2sNCiAjY3B1cyA9ICIwIiAgICAgICAg
IyBhbGwgdmNwdXMgcnVuIG9uIENQVTANCiAjY3B1cyA9ICIwLTMsNSxeMSIgIyBhbGwgdmNwdXMg
cnVuIG9uIGNwdXMgMCwyLDMsNQ0KLSNjcHVzID0gWyIyIiwgIjMiXSAjIFZDUFUwIHJ1bnMgb24g
Q1BVMiwgVkNQVTEgcnVucyBvbiBDUFUzDQogDQogIyBOdW1iZXIgb2YgVmlydHVhbCBDUFVTIHRv
IHVzZSwgZGVmYXVsdCBpcyAxDQogI3ZjcHVzID0gMQ0KZGlmZiAtciA4OTdlYTRkM2MyZDcgdG9v
bHMvZXhhbXBsZXMveG1leGFtcGxlMg0KLS0tIGEvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxlMglX
ZWQgSmFuIDExIDE3OjI4OjUzIDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2V4YW1wbGVzL3htZXhh
bXBsZTIJV2VkIEphbiAxMSAxNzozMjozNCAyMDEyICswMDAwDQpAQCAtNjAsMTEgKzYwLDggQEAg
bmFtZSA9ICJWTSVkIiAlIHZtaWQNCiAjdXVpZCA9ICIwNmVkMDBmZS0xMTYyLTRmYzQtYjVkOC0x
MTk5M2VlNGE4YjkiDQogDQogIyBMaXN0IG9mIHdoaWNoIENQVVMgdGhpcyBkb21haW4gaXMgYWxs
b3dlZCB0byB1c2UsIGRlZmF1bHQgWGVuIHBpY2tzDQotI2NwdXMgPSAiIiAgICAgICAgICMgbGVh
dmUgdG8gWGVuIHRvIHBpY2sNCiAjY3B1cyA9ICIwIiAgICAgICAgIyBhbGwgdmNwdXMgcnVuIG9u
IENQVTANCiAjY3B1cyA9ICIwLTMsNSxeMSIgIyBhbGwgdmNwdXMgcnVuIG9uIGNwdXMgMCwyLDMs
NQ0KLSNjcHVzID0gWyIyIiwgIjMiXSAjIFZDUFUwIHJ1bnMgb24gQ1BVMiwgVkNQVTEgcnVucyBv
biBDUFUzDQotI2NwdXMgPSAiJXMiICUgdm1pZCAjIHNldCBiYXNlZCBvbiB2bWlkIChtb2QgbnVt
YmVyIG9mIENQVXMpDQogDQogIyBOdW1iZXIgb2YgVmlydHVhbCBDUFVTIHRvIHVzZSwgZGVmYXVs
dCBpcyAxDQogI3ZjcHVzID0gMQ0KZGlmZiAtciA4OTdlYTRkM2MyZDcgdG9vbHMvZXhhbXBsZXMv
eG1leGFtcGxlMw0KLS0tIGEvdG9vbHMvZXhhbXBsZXMveG1leGFtcGxlMwlXZWQgSmFuIDExIDE3
OjI4OjUzIDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2V4YW1wbGVzL3htZXhhbXBsZTMJV2VkIEph
biAxMSAxNzozMjozNCAyMDEyICswMDAwDQpAQCAtNjAsMTEgKzYwLDggQEAgbmFtZSA9ICJWTSVk
IiAlIHZtaWQNCiAjdXVpZCA9ICIwNmVkMDBmZS0xMTYyLTRmYzQtYjVkOC0xMTk5M2VlNGE4Yjki
DQogDQogIyBMaXN0IG9mIHdoaWNoIENQVVMgdGhpcyBkb21haW4gaXMgYWxsb3dlZCB0byB1c2Us
IGRlZmF1bHQgWGVuIHBpY2tzDQotI2NwdXMgPSAiIiAgICAgICAgICMgbGVhdmUgdG8gWGVuIHRv
IHBpY2sNCiAjY3B1cyA9ICIwIiAgICAgICAgIyBhbGwgdmNwdXMgcnVuIG9uIENQVTANCiAjY3B1
cyA9ICIwLTMsNSxeMSIgIyBhbGwgdmNwdXMgcnVuIG9uIGNwdXMgMCwyLDMsNQ0KLSNjcHVzID0g
WyIyIiwgIjMiXSAjIFZDUFUwIHJ1bnMgb24gQ1BVMiwgVkNQVTEgcnVucyBvbiBDUFUzDQotY3B1
cyA9ICIlcyIgJSB2bWlkICMgc2V0IGJhc2VkIG9uIHZtaWQgKG1vZCBudW1iZXIgb2YgQ1BVcykN
CiANCiAjLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICMgRGVmaW5lIG5ldHdvcmsgaW50ZXJmYWNlcy4N
Cg==


--=-1vLiKAUMVhc3Ke1u4zse--

--=-kAYgasmKBl9sKJO0wAYY
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)

iEYEABECAAYFAk8NzpcACgkQk4XaBE3IOsTY4wCdFIwyH6bQsa/kM3qcasrxrj3d
HqoAn0W7hWCNNXNq86QiHfK5lI+GgQbB
=ntXt
-----END PGP SIGNATURE-----

--=-kAYgasmKBl9sKJO0wAYY--



--===============6288012544328851556==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6288012544328851556==--



From xen-devel-bounces@lists.xensource.com Wed Jan 11 18:03:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 18:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl2Vo-0003QL-Rm; Wed, 11 Jan 2012 18:03: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 1Rl2Vm-0003Pc-Ab
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:02:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326304960!10445607!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE3MjM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22585 invoked from network); 11 Jan 2012 18:02:40 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-16.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 18:02:40 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id A70A25EC07E;
	Wed, 11 Jan 2012 10:02:39 -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=KcfuU1hiwxLI29i03CDG0OjU9oFM0omIhMUrxeiFgKea
	0J2UVombECNB2sT/dwsYqpE2iXP4/+uj7VQU1JEmbyuy15jn7dl8hUrZ25Th3DLz
	LJgtoHxyuhj8cpvABc1iUftH62LNLfaKwXNJRvF/ORdhLZCE+WEUlT9yURhDHfI=
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=dj5EepKoAgMyf2Fs+FgP+rJ6tJQ=; b=ty8aJS6W
	SGYFLHYiES9s8fT4CKy4VTRe8V1SvsZqYhysun4P8ilY0++tJRBTho+T/CBpZMm4
	Y3rGRVWVZ4QbTAboP9wq1dhnjapD4eFDhk5MGfOqGTyoXCaiHB6te5xn2tMHfhRL
	mo0CKVUKKw/C3nbtjYyTKLOGLf85pX8IHlY=
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 F33EC5EC072; 
	Wed, 11 Jan 2012 10:02:38 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 11 Jan 2012 10:02:39 -0800
Message-ID: <63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 10:02:39 -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, 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

> 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
> Message-ID: <d910d738f31b4ee1a6b0.1324294786@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # 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.

Olaf,
thanks for the post. We'll have to nack this patch in its current form. It
hard reboots our host during our testing.

What we did is take this patch, amalgamate it with some bits from our ring
management approach. We're ready to submit that, along with a description
of how we test it. It works for us, and it involves wait queue's for
corner cases.

Stay tuned, test, and hopefully, ack.
Thanks
Andres


>
> 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
>
>
> End of Xen-devel Digest, Vol 82, Issue 325
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 18:03:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 18:03:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl2Vo-0003QL-Rm; Wed, 11 Jan 2012 18:03: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 1Rl2Vm-0003Pc-Ab
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:02:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326304960!10445607!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE3MjM1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22585 invoked from network); 11 Jan 2012 18:02:40 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-16.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 18:02:40 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id A70A25EC07E;
	Wed, 11 Jan 2012 10:02:39 -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=KcfuU1hiwxLI29i03CDG0OjU9oFM0omIhMUrxeiFgKea
	0J2UVombECNB2sT/dwsYqpE2iXP4/+uj7VQU1JEmbyuy15jn7dl8hUrZ25Th3DLz
	LJgtoHxyuhj8cpvABc1iUftH62LNLfaKwXNJRvF/ORdhLZCE+WEUlT9yURhDHfI=
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=dj5EepKoAgMyf2Fs+FgP+rJ6tJQ=; b=ty8aJS6W
	SGYFLHYiES9s8fT4CKy4VTRe8V1SvsZqYhysun4P8ilY0++tJRBTho+T/CBpZMm4
	Y3rGRVWVZ4QbTAboP9wq1dhnjapD4eFDhk5MGfOqGTyoXCaiHB6te5xn2tMHfhRL
	mo0CKVUKKw/C3nbtjYyTKLOGLf85pX8IHlY=
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 F33EC5EC072; 
	Wed, 11 Jan 2012 10:02:38 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Wed, 11 Jan 2012 10:02:39 -0800
Message-ID: <63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
Date: Wed, 11 Jan 2012 10:02:39 -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, 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

> 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
> Message-ID: <d910d738f31b4ee1a6b0.1324294786@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # 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.

Olaf,
thanks for the post. We'll have to nack this patch in its current form. It
hard reboots our host during our testing.

What we did is take this patch, amalgamate it with some bits from our ring
management approach. We're ready to submit that, along with a description
of how we test it. It works for us, and it involves wait queue's for
corner cases.

Stay tuned, test, and hopefully, ack.
Thanks
Andres


>
> 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
>
>
> End of Xen-devel Digest, Vol 82, Issue 325
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 18:24:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 18:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl2qQ-00040T-1L; Wed, 11 Jan 2012 18:24:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rl2qO-00040L-Na
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:24:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326306249!10605602!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcwMTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22493 invoked from network); 11 Jan 2012 18:24:09 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 18:24:09 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 9E6B94B008F;
	Wed, 11 Jan 2012 10:24: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=Yg4+1IDlWg+tsAN+7FXnfB
	mJEBQZ8TvBQ+kYFVyaXNwsr71kRBxEbjVVKzczTNa3rf8EVkMSP1RSQLdGvUonau
	VQlP0lmC6lTWP0n+z06EaACKs7UcBzC8SVgJ9VByS1JRGnNf/OjdotWTtgilr3ML
	DDV2lK48oDhqjdOoor9BE=
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=iRFlAJZRl8hl
	xNUakOHQKfppCPY=; b=VU5+ucPVKGdZ1NaUMPzgPYG+X+6TnisQyMeGWwoW6V5r
	vcuDOSvnnjWgx3cqjiWWHepYLTOWCtmW8P4fWzq23+XowMpKr6NxA9WVdGur8QoK
	jaJk3HzzgXulbKqUnQZthF85n4DYoqAX6Uy8fni7EAw/M9hj7V2fEYYFljyd1Xo=
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 8ED984B0090; 
	Wed, 11 Jan 2012 10:24:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a85e7d46401b1d419629c75cfe8f7e70a354e5c2
Message-Id: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 11 Jan 2012 13:28:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: 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          |   18 +-
 xen/arch/x86/mm/mem_event.c     |  298 +++++++++++++++++++++++++++++++++------
 xen/arch/x86/mm/mem_sharing.c   |   30 +--
 xen/arch/x86/mm/p2m.c           |   81 +++++-----
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   22 +-
 xen/include/asm-x86/p2m.h       |   12 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |   22 ++-
 9 files changed, 359 insertions(+), 133 deletions(-)


This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
and our work.

It combines logic changes to simplify the memory event API, as well as
leveraging wait queues to deal with extreme conditions in which too many events are
generated by a guest vcpu.

In order to generate a new event, a slot in the ring is claimed. If a guest vcpu
is generating the event and there is no space, it is put on a wait queue. If a
foreign vcpu is generating the event and there is no space, the vcpu is expected
to retry its operation. If an error happens later, the function returns the
claimed slot via a cancel operation.

Thus, the API has only four calls: claim slot, cancel claimed slot, put request
in the ring, consume the response.

With all these mechanisms, no guest events are lost.
Our testing includes 1. ballooning down 512 MiBs; 2. using mem access n2rwx, 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.

For full disclosure, here is Olaf's log of changes:

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: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4188,25 +4188,31 @@ static int hvm_memory_event_traps(long p
                                   unsigned long value, unsigned long old, 
                                   bool_t gla_valid, unsigned long gla) 
 {
+    int rc;
     struct vcpu* v = current;
     struct domain *d = v->domain;
     mem_event_request_t req;
-    int rc;
 
     if ( !(p & HVMPME_MODE_MASK) ) 
         return 0;
 
     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 == -ENOSYS )
+    {
+        /* If there was no ring to handle the event, then
+         * simple continue executing normally. */
+        return 1;
+    }
+    else if ( rc < 0 )
         return rc;
-    
+
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
-    
+
     if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
     {
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
diff -r d3342b370b6f -r a85e7d46401b 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;
@@ -93,6 +95,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,
@@ -110,8 +115,11 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    /* Save the pause flag for this particular ring. */
+    med->pause_flag = pause_flag;
+
+    /* Initialize the last-chance wait queue. */
+    init_waitqueue_head(&med->wq);
 
     return 0;
 
@@ -125,48 +133,218 @@ static int mem_event_enable(
     return rc;
 }
 
-static int mem_event_disable(struct mem_event_domain *med)
+static int mem_event_ring_available(struct mem_event_domain *med)
 {
-    unmap_domain_page(med->ring_page);
-    med->ring_page = NULL;
+    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
+    avail_req -= med->target_producers;
+    avail_req -= med->foreign_producers;
 
-    unmap_domain_page(med->shared_page);
-    med->shared_page = NULL;
+    BUG_ON(avail_req < 0);
+
+    return avail_req;
+}
+
+/*
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. These vCPUs were paused on their way out after placing an event,
+ * but need to be resumed where the ring is capable of processing at least
+ * one event from them.
+ */
+static void mem_event_wake_blocked(struct domain *d, struct mem_event_domain *med)
+{
+    struct vcpu *v;
+    int online = d->max_vcpus;
+    int avail_req = mem_event_ring_available(med);
+
+    if( avail_req <= 0 || med->blocked == 0 )
+        return;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit). 
+     * See comment below in mem_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(med->pause_flag, &v->pause_flags) )
+            online--;
+
+    ASSERT(online == (d->max_vcpus - med->blocked));
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        int i, j, k;
+
+        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v )
+                continue;
+
+            if ( !(med->blocked) || online >= avail_req )
+               break;
+
+            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                med->blocked--;
+                med->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+/*
+ * In the event that a vCPU attempted to place an event in the ring and
+ * was unable to do so, it is queued on a wait queue.  These are woken as
+ * needed, and take precedence over the blocked vCPUs.
+ */
+static void mem_event_wake_queued(struct domain *d, struct mem_event_domain *med)
+{
+    int avail_req = mem_event_ring_available(med);
+
+    if ( avail_req > 0 )
+        wake_up_nr(&med->wq, avail_req);
+}
+
+/*
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
+ * become available.  If we have queued vCPUs, they get top priority. We
+ * are guaranteed that they will go through code paths that will eventually
+ * call mem_event_wake() again, ensuring that any blocked vCPUs will get
+ * unpaused once all the queued vCPUs have made it through.
+ */
+void mem_event_wake(struct domain *d, struct mem_event_domain *med)
+{
+    if (!list_empty(&med->wq.list))
+        mem_event_wake_queued(d, med);
+    else
+        mem_event_wake_blocked(d, med);
+}
+
+static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
+{
+    if( med->ring_page )
+    {
+        struct vcpu *v;
+
+        mem_event_ring_lock(med);
+
+        if (!list_empty(&med->wq.list))
+        {
+            mem_event_ring_unlock(med);
+            return -EBUSY;
+        }
+
+        unmap_domain_page(med->ring_page);
+        med->ring_page = NULL;
+
+        unmap_domain_page(med->shared_page);
+        med->shared_page = NULL;
+
+        /* Wake up everybody */
+        wake_up_all(&med->wq);
+
+        /* Unblock all vCPUs */ 
+        for_each_vcpu ( d, v )
+        {
+            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                med->blocked--;
+            }
+        }
+
+        mem_event_ring_unlock(med);
+    }
 
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static inline void mem_event_release_slot(struct domain *d,
+                                          struct mem_event_domain *med)
+{
+    /* Update the accounting */
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
+
+    /* Kick any waiters */
+    mem_event_wake(d, med);
+}
+
+/*
+ * mem_event_mark_and_pause() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
+{
+    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        med->blocked++;
+    }
+}
+
+/*
+ * This must be preceeded by a call to claim_slot(), and is guaranteed to
+ * succeed.  As a side-effect however, the vCPU may be paused if the ring is
+ * overly full and its continued execution would cause stalling and excessive
+ * waiting.  The vCPU will be automatically unpaused when the ring clears.
+ */
+void mem_event_put_request(struct domain *d,
+                           struct mem_event_domain *med,
+                           mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req, avail_req;
     RING_IDX req_prod;
 
-    mem_event_ring_lock(med);
-
-    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) );
     }
 
+    mem_event_ring_lock(med);
+
+    /* Due to the reservations, this step must succeed. */
+    front_ring = &med->front_ring;
+    free_req = RING_FREE_REQUESTS(front_ring);
+    ASSERT(free_req > 0);
+
     /* Copy request */
+    req_prod = front_ring->req_prod_pvt;
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
+    /* We've actually *used* our reservation, so release the slot. */
+    mem_event_release_slot(d, med);
+
+    /* Give this vCPU a black eye if necessary, on the way out.
+     * See the comments above wake_blocked() for more information
+     * on how this mechanism works to avoid waiting. */
+    avail_req = mem_event_ring_available(med);
+    if( current->domain == d && avail_req < d->max_vcpus )
+        mem_event_mark_and_pause(current, med);
+
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
 }
 
-int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med, mem_event_response_t *rsp)
 {
     mem_event_front_ring_t *front_ring;
     RING_IDX rsp_cons;
@@ -190,57 +368,81 @@ int mem_event_get_response(struct mem_ev
     front_ring->rsp_cons = rsp_cons;
     front_ring->sring->rsp_event = rsp_cons + 1;
 
+    /* Kick any waiters -- since we've just consumed an event,
+     * there may be additional space available in the ring. */
+    mem_event_wake(d, med);
+
     mem_event_ring_unlock(med);
 
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
-{
-    struct vcpu *v;
-
-    for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
-            vcpu_wake(v);
-}
-
-void mem_event_mark_and_pause(struct vcpu *v)
-{
-    set_bit(_VPF_mem_event, &v->pause_flags);
-    vcpu_sleep_nosync(v);
-}
-
-void mem_event_put_req_producers(struct mem_event_domain *med)
+void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    mem_event_release_slot(d, med);
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+static int mem_event_grab_slot(struct mem_event_domain *med, int foreign)
 {
-    struct vcpu *curr = current;
-    int free_requests;
-    int ring_full = 1;
+    int avail_req;
 
     if ( !med->ring_page )
-        return -1;
+        return -ENOSYS;
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    avail_req = mem_event_ring_available(med);
+    if( avail_req <= 0 )
     {
-        med->req_producers++;
-        ring_full = 0;
+        mem_event_ring_unlock(med);
+        return -EBUSY;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
+    if ( !foreign )
+        med->target_producers++;
+    else
+        med->foreign_producers++;
 
     mem_event_ring_unlock(med);
 
-    return ring_full;
+    return 0;
+}
+
+/* Simple try_grab wrapper for use in the wait_event() macro. */
+static int mem_event_wait_try_grab(struct mem_event_domain *med, int *rc)
+{
+    *rc = mem_event_grab_slot(med, 0);
+    return *rc;
+}
+
+/* Call mem_event_grab_slot() until the ring doesn't exist, or is available. */
+static int mem_event_wait_slot(struct mem_event_domain *med)
+{
+    int rc = -EBUSY;
+    wait_event(med->wq, mem_event_wait_try_grab(med, &rc) != -EBUSY);
+    return rc;
+}
+
+/*
+ * Determines whether or not the current vCPU belongs to the target domain,
+ * and calls the appropriate wait function.  If it is a guest vCPU, then we
+ * use mem_event_wait_slot() to reserve a slot.  As long as there is a ring,
+ * this function will always return 0 for a guest.  For a non-guest, we check
+ * for space and return -EBUSY if the ring is not available.
+ *
+ * Return codes: -ENOSYS: the ring is not yet configured
+ *               -EBUSY: the ring is busy
+ *               0: a spot has been reserved
+ *
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
+{
+    if ( current->domain == d )
+        return mem_event_wait_slot(med);
+    else
+        return mem_event_grab_slot(med, 1);
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */
@@ -316,14 +518,14 @@ 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;
 
         case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
@@ -355,14 +557,14 @@ 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;
 
         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 d3342b370b6f -r a85e7d46401b 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,21 @@ 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;
     }
 
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+    {
+        return;
+    }
+
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     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);
-
-    return page;
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -301,7 +294,7 @@ int mem_sharing_sharing_resume(struct do
     mem_event_response_t rsp;
 
     /* Get all requests off the ring */
-    while ( mem_event_get_response(&d->mem_event->share, &rsp) )
+    while ( mem_event_get_response(d, &d->mem_event->share, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -658,13 +651,14 @@ 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
          * gfn_info to relevant list */
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
+        mem_sharing_notify_helper(d, gfn);
         shr_unlock();
         return -ENOMEM;
     }
diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -859,22 +859,26 @@ int p2m_mem_paging_evict(struct domain *
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+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 */
-    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;
+    /* We allow no ring in this unique case, because it won't affect
+     * correctness of the guest execution at this point.  If this is the only
+     * page that happens to be paged-out, we'll be okay..  but it's likely the
+     * guest will crash shortly anyways. */
+    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    if ( rc < 0 )
+        return rc;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    /* Send release notification to pager */
+    memset(&req, 0, sizeof(req));
+    req.type = MEM_EVENT_TYPE_PAGING;
+    req.gfn = gfn;
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
+
+    mem_event_put_request(d, &d->mem_event->paging, &req);
+    return 0;
 }
 
 /**
@@ -898,7 +902,7 @@ void p2m_mem_paging_drop_page(struct dom
  * already sent to the pager. In this case the caller has to try again until the
  * gfn is fully paged in again.
  */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
@@ -907,9 +911,17 @@ 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 */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
-        return;
+    /* We're paging. There should be a ring */
+    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    if ( rc == -ENOSYS )
+    {
+        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
+                             "in place\n", d->domain_id, gfn);
+        domain_crash(d);
+        return 0;
+    }
+    else if ( rc < 0 )
+        return rc;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -929,7 +941,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_unlock(p2m);
 
     /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain == d )
+    if ( p2m_is_paging(p2mt) && v->domain == d )
     {
         vcpu_pause_nosync(v);
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
@@ -938,8 +950,8 @@ 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;
+        mem_event_cancel_slot(d, &d->mem_event->paging);
+        return 0;
     }
 
     /* Send request to pager */
@@ -948,6 +960,7 @@ void p2m_mem_paging_populate(struct doma
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->paging, &req);
+    return 0;
 }
 
 /**
@@ -1065,7 +1078,7 @@ void p2m_mem_paging_resume(struct domain
     mfn_t mfn;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(&d->mem_event->paging, &rsp) )
+    while( mem_event_get_response(d, &d->mem_event->paging, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -1090,9 +1103,6 @@ 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);
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1103,7 +1113,6 @@ bool_t p2m_mem_access_check(unsigned lon
     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;
@@ -1126,17 +1135,16 @@ 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);
-    if ( res < 0 ) 
+    if ( mem_event_claim_slot(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);
+            return 0;
         }
         else
         {
@@ -1149,11 +1157,7 @@ bool_t p2m_mem_access_check(unsigned lon
             }
             return 1;
         }
-
-        return 0;
     }
-    else if ( res > 0 )
-        return 0;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1188,7 +1192,7 @@ void p2m_mem_access_resume(struct domain
     mem_event_response_t rsp;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(&d->mem_event->access, &rsp) )
+    while( mem_event_get_response(d, &d->mem_event->access, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -1196,13 +1200,8 @@ 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);
 }
 
-
 /* Set access type for a region of pfns.
  * If start_pfn == -1ul, sets the default access type */
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn, 
diff -r d3342b370b6f -r a85e7d46401b 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 d3342b370b6f -r a85e7d46401b xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,18 +24,24 @@
 #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_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);
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
+ * available space. For success or -EBUSY, the vCPU may be left blocked
+ * temporarily to ensure that the ring does not lose future events.  In
+ * general, you must follow a claim_slot() call with either put_request() or
+ * cancel_slot(), both of which are guaranteed to succeed. */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+
+void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med);
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                            mem_event_request_t *req);
+
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
+                           mem_event_response_t *rsp);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
 
-
 #endif /* __MEM_EVENT_H__ */
 
 
diff -r d3342b370b6f -r a85e7d46401b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -478,18 +478,18 @@ 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);
+int 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, uint64_t buffer);
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
-{ }
-static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
-{ }
+static inline int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+{ return 0; }
+static inline int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+{ return 0; }
 #endif
 
 #ifdef __x86_64__
diff -r d3342b370b6f -r a85e7d46401b 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 d3342b370b6f -r a85e7d46401b 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,9 @@ 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 target_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +195,14 @@ 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;
+    /* the number of vCPUs blocked */
+    unsigned int blocked;
+    /* The last vcpu woken up */
+    unsigned int last_vcpu_wake_up;
 };
 
 struct mem_event_per_domain
@@ -615,9 +626,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 Wed Jan 11 18:24:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 18:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl2qQ-00040T-1L; Wed, 11 Jan 2012 18:24:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rl2qO-00040L-Na
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:24:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326306249!10605602!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcwMTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22493 invoked from network); 11 Jan 2012 18:24:09 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-216.messagelabs.com with SMTP;
	11 Jan 2012 18:24:09 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 9E6B94B008F;
	Wed, 11 Jan 2012 10:24: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=Yg4+1IDlWg+tsAN+7FXnfB
	mJEBQZ8TvBQ+kYFVyaXNwsr71kRBxEbjVVKzczTNa3rf8EVkMSP1RSQLdGvUonau
	VQlP0lmC6lTWP0n+z06EaACKs7UcBzC8SVgJ9VByS1JRGnNf/OjdotWTtgilr3ML
	DDV2lK48oDhqjdOoor9BE=
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=iRFlAJZRl8hl
	xNUakOHQKfppCPY=; b=VU5+ucPVKGdZ1NaUMPzgPYG+X+6TnisQyMeGWwoW6V5r
	vcuDOSvnnjWgx3cqjiWWHepYLTOWCtmW8P4fWzq23+XowMpKr6NxA9WVdGur8QoK
	jaJk3HzzgXulbKqUnQZthF85n4DYoqAX6Uy8fni7EAw/M9hj7V2fEYYFljyd1Xo=
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 8ED984B0090; 
	Wed, 11 Jan 2012 10:24:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a85e7d46401b1d419629c75cfe8f7e70a354e5c2
Message-Id: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 11 Jan 2012 13:28:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, olaf@aepfle.de, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: 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          |   18 +-
 xen/arch/x86/mm/mem_event.c     |  298 +++++++++++++++++++++++++++++++++------
 xen/arch/x86/mm/mem_sharing.c   |   30 +--
 xen/arch/x86/mm/p2m.c           |   81 +++++-----
 xen/common/memory.c             |    7 +-
 xen/include/asm-x86/mem_event.h |   22 +-
 xen/include/asm-x86/p2m.h       |   12 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |   22 ++-
 9 files changed, 359 insertions(+), 133 deletions(-)


This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
and our work.

It combines logic changes to simplify the memory event API, as well as
leveraging wait queues to deal with extreme conditions in which too many events are
generated by a guest vcpu.

In order to generate a new event, a slot in the ring is claimed. If a guest vcpu
is generating the event and there is no space, it is put on a wait queue. If a
foreign vcpu is generating the event and there is no space, the vcpu is expected
to retry its operation. If an error happens later, the function returns the
claimed slot via a cancel operation.

Thus, the API has only four calls: claim slot, cancel claimed slot, put request
in the ring, consume the response.

With all these mechanisms, no guest events are lost.
Our testing includes 1. ballooning down 512 MiBs; 2. using mem access n2rwx, 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.

For full disclosure, here is Olaf's log of changes:

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: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4188,25 +4188,31 @@ static int hvm_memory_event_traps(long p
                                   unsigned long value, unsigned long old, 
                                   bool_t gla_valid, unsigned long gla) 
 {
+    int rc;
     struct vcpu* v = current;
     struct domain *d = v->domain;
     mem_event_request_t req;
-    int rc;
 
     if ( !(p & HVMPME_MODE_MASK) ) 
         return 0;
 
     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 == -ENOSYS )
+    {
+        /* If there was no ring to handle the event, then
+         * simple continue executing normally. */
+        return 1;
+    }
+    else if ( rc < 0 )
         return rc;
-    
+
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
-    
+
     if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
     {
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
diff -r d3342b370b6f -r a85e7d46401b 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;
@@ -93,6 +95,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,
@@ -110,8 +115,11 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    /* Save the pause flag for this particular ring. */
+    med->pause_flag = pause_flag;
+
+    /* Initialize the last-chance wait queue. */
+    init_waitqueue_head(&med->wq);
 
     return 0;
 
@@ -125,48 +133,218 @@ static int mem_event_enable(
     return rc;
 }
 
-static int mem_event_disable(struct mem_event_domain *med)
+static int mem_event_ring_available(struct mem_event_domain *med)
 {
-    unmap_domain_page(med->ring_page);
-    med->ring_page = NULL;
+    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
+    avail_req -= med->target_producers;
+    avail_req -= med->foreign_producers;
 
-    unmap_domain_page(med->shared_page);
-    med->shared_page = NULL;
+    BUG_ON(avail_req < 0);
+
+    return avail_req;
+}
+
+/*
+ * mem_event_wake_requesters() will wakeup vcpus waiting for room in the
+ * ring. These vCPUs were paused on their way out after placing an event,
+ * but need to be resumed where the ring is capable of processing at least
+ * one event from them.
+ */
+static void mem_event_wake_blocked(struct domain *d, struct mem_event_domain *med)
+{
+    struct vcpu *v;
+    int online = d->max_vcpus;
+    int avail_req = mem_event_ring_available(med);
+
+    if( avail_req <= 0 || med->blocked == 0 )
+        return;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit). 
+     * See comment below in mem_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(med->pause_flag, &v->pause_flags) )
+            online--;
+
+    ASSERT(online == (d->max_vcpus - med->blocked));
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        int i, j, k;
+
+        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v )
+                continue;
+
+            if ( !(med->blocked) || online >= avail_req )
+               break;
+
+            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                med->blocked--;
+                med->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+/*
+ * In the event that a vCPU attempted to place an event in the ring and
+ * was unable to do so, it is queued on a wait queue.  These are woken as
+ * needed, and take precedence over the blocked vCPUs.
+ */
+static void mem_event_wake_queued(struct domain *d, struct mem_event_domain *med)
+{
+    int avail_req = mem_event_ring_available(med);
+
+    if ( avail_req > 0 )
+        wake_up_nr(&med->wq, avail_req);
+}
+
+/*
+ * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to
+ * become available.  If we have queued vCPUs, they get top priority. We
+ * are guaranteed that they will go through code paths that will eventually
+ * call mem_event_wake() again, ensuring that any blocked vCPUs will get
+ * unpaused once all the queued vCPUs have made it through.
+ */
+void mem_event_wake(struct domain *d, struct mem_event_domain *med)
+{
+    if (!list_empty(&med->wq.list))
+        mem_event_wake_queued(d, med);
+    else
+        mem_event_wake_blocked(d, med);
+}
+
+static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
+{
+    if( med->ring_page )
+    {
+        struct vcpu *v;
+
+        mem_event_ring_lock(med);
+
+        if (!list_empty(&med->wq.list))
+        {
+            mem_event_ring_unlock(med);
+            return -EBUSY;
+        }
+
+        unmap_domain_page(med->ring_page);
+        med->ring_page = NULL;
+
+        unmap_domain_page(med->shared_page);
+        med->shared_page = NULL;
+
+        /* Wake up everybody */
+        wake_up_all(&med->wq);
+
+        /* Unblock all vCPUs */ 
+        for_each_vcpu ( d, v )
+        {
+            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                med->blocked--;
+            }
+        }
+
+        mem_event_ring_unlock(med);
+    }
 
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static inline void mem_event_release_slot(struct domain *d,
+                                          struct mem_event_domain *med)
+{
+    /* Update the accounting */
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
+
+    /* Kick any waiters */
+    mem_event_wake(d, med);
+}
+
+/*
+ * mem_event_mark_and_pause() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
+{
+    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        med->blocked++;
+    }
+}
+
+/*
+ * This must be preceeded by a call to claim_slot(), and is guaranteed to
+ * succeed.  As a side-effect however, the vCPU may be paused if the ring is
+ * overly full and its continued execution would cause stalling and excessive
+ * waiting.  The vCPU will be automatically unpaused when the ring clears.
+ */
+void mem_event_put_request(struct domain *d,
+                           struct mem_event_domain *med,
+                           mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req, avail_req;
     RING_IDX req_prod;
 
-    mem_event_ring_lock(med);
-
-    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) );
     }
 
+    mem_event_ring_lock(med);
+
+    /* Due to the reservations, this step must succeed. */
+    front_ring = &med->front_ring;
+    free_req = RING_FREE_REQUESTS(front_ring);
+    ASSERT(free_req > 0);
+
     /* Copy request */
+    req_prod = front_ring->req_prod_pvt;
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
+    /* We've actually *used* our reservation, so release the slot. */
+    mem_event_release_slot(d, med);
+
+    /* Give this vCPU a black eye if necessary, on the way out.
+     * See the comments above wake_blocked() for more information
+     * on how this mechanism works to avoid waiting. */
+    avail_req = mem_event_ring_available(med);
+    if( current->domain == d && avail_req < d->max_vcpus )
+        mem_event_mark_and_pause(current, med);
+
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
 }
 
-int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med, mem_event_response_t *rsp)
 {
     mem_event_front_ring_t *front_ring;
     RING_IDX rsp_cons;
@@ -190,57 +368,81 @@ int mem_event_get_response(struct mem_ev
     front_ring->rsp_cons = rsp_cons;
     front_ring->sring->rsp_event = rsp_cons + 1;
 
+    /* Kick any waiters -- since we've just consumed an event,
+     * there may be additional space available in the ring. */
+    mem_event_wake(d, med);
+
     mem_event_ring_unlock(med);
 
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
-{
-    struct vcpu *v;
-
-    for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
-            vcpu_wake(v);
-}
-
-void mem_event_mark_and_pause(struct vcpu *v)
-{
-    set_bit(_VPF_mem_event, &v->pause_flags);
-    vcpu_sleep_nosync(v);
-}
-
-void mem_event_put_req_producers(struct mem_event_domain *med)
+void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    mem_event_release_slot(d, med);
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+static int mem_event_grab_slot(struct mem_event_domain *med, int foreign)
 {
-    struct vcpu *curr = current;
-    int free_requests;
-    int ring_full = 1;
+    int avail_req;
 
     if ( !med->ring_page )
-        return -1;
+        return -ENOSYS;
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    avail_req = mem_event_ring_available(med);
+    if( avail_req <= 0 )
     {
-        med->req_producers++;
-        ring_full = 0;
+        mem_event_ring_unlock(med);
+        return -EBUSY;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
+    if ( !foreign )
+        med->target_producers++;
+    else
+        med->foreign_producers++;
 
     mem_event_ring_unlock(med);
 
-    return ring_full;
+    return 0;
+}
+
+/* Simple try_grab wrapper for use in the wait_event() macro. */
+static int mem_event_wait_try_grab(struct mem_event_domain *med, int *rc)
+{
+    *rc = mem_event_grab_slot(med, 0);
+    return *rc;
+}
+
+/* Call mem_event_grab_slot() until the ring doesn't exist, or is available. */
+static int mem_event_wait_slot(struct mem_event_domain *med)
+{
+    int rc = -EBUSY;
+    wait_event(med->wq, mem_event_wait_try_grab(med, &rc) != -EBUSY);
+    return rc;
+}
+
+/*
+ * Determines whether or not the current vCPU belongs to the target domain,
+ * and calls the appropriate wait function.  If it is a guest vCPU, then we
+ * use mem_event_wait_slot() to reserve a slot.  As long as there is a ring,
+ * this function will always return 0 for a guest.  For a non-guest, we check
+ * for space and return -EBUSY if the ring is not available.
+ *
+ * Return codes: -ENOSYS: the ring is not yet configured
+ *               -EBUSY: the ring is busy
+ *               0: a spot has been reserved
+ *
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
+{
+    if ( current->domain == d )
+        return mem_event_wait_slot(med);
+    else
+        return mem_event_grab_slot(med, 1);
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */
@@ -316,14 +518,14 @@ 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;
 
         case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
@@ -355,14 +557,14 @@ 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;
 
         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 d3342b370b6f -r a85e7d46401b 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,21 @@ 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;
     }
 
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+    {
+        return;
+    }
+
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     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);
-
-    return page;
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -301,7 +294,7 @@ int mem_sharing_sharing_resume(struct do
     mem_event_response_t rsp;
 
     /* Get all requests off the ring */
-    while ( mem_event_get_response(&d->mem_event->share, &rsp) )
+    while ( mem_event_get_response(d, &d->mem_event->share, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -658,13 +651,14 @@ 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
          * gfn_info to relevant list */
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
+        mem_sharing_notify_helper(d, gfn);
         shr_unlock();
         return -ENOMEM;
     }
diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -859,22 +859,26 @@ int p2m_mem_paging_evict(struct domain *
  * released by the guest. The pager is supposed to drop its reference of the
  * gfn.
  */
-void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+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 */
-    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;
+    /* We allow no ring in this unique case, because it won't affect
+     * correctness of the guest execution at this point.  If this is the only
+     * page that happens to be paged-out, we'll be okay..  but it's likely the
+     * guest will crash shortly anyways. */
+    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    if ( rc < 0 )
+        return rc;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    /* Send release notification to pager */
+    memset(&req, 0, sizeof(req));
+    req.type = MEM_EVENT_TYPE_PAGING;
+    req.gfn = gfn;
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
+
+    mem_event_put_request(d, &d->mem_event->paging, &req);
+    return 0;
 }
 
 /**
@@ -898,7 +902,7 @@ void p2m_mem_paging_drop_page(struct dom
  * already sent to the pager. In this case the caller has to try again until the
  * gfn is fully paged in again.
  */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
@@ -907,9 +911,17 @@ 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 */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
-        return;
+    /* We're paging. There should be a ring */
+    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    if ( rc == -ENOSYS )
+    {
+        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
+                             "in place\n", d->domain_id, gfn);
+        domain_crash(d);
+        return 0;
+    }
+    else if ( rc < 0 )
+        return rc;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -929,7 +941,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_unlock(p2m);
 
     /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain == d )
+    if ( p2m_is_paging(p2mt) && v->domain == d )
     {
         vcpu_pause_nosync(v);
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
@@ -938,8 +950,8 @@ 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;
+        mem_event_cancel_slot(d, &d->mem_event->paging);
+        return 0;
     }
 
     /* Send request to pager */
@@ -948,6 +960,7 @@ void p2m_mem_paging_populate(struct doma
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->paging, &req);
+    return 0;
 }
 
 /**
@@ -1065,7 +1078,7 @@ void p2m_mem_paging_resume(struct domain
     mfn_t mfn;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(&d->mem_event->paging, &rsp) )
+    while( mem_event_get_response(d, &d->mem_event->paging, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -1090,9 +1103,6 @@ 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);
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1103,7 +1113,6 @@ bool_t p2m_mem_access_check(unsigned lon
     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;
@@ -1126,17 +1135,16 @@ 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);
-    if ( res < 0 ) 
+    if ( mem_event_claim_slot(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);
+            return 0;
         }
         else
         {
@@ -1149,11 +1157,7 @@ bool_t p2m_mem_access_check(unsigned lon
             }
             return 1;
         }
-
-        return 0;
     }
-    else if ( res > 0 )
-        return 0;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1188,7 +1192,7 @@ void p2m_mem_access_resume(struct domain
     mem_event_response_t rsp;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(&d->mem_event->access, &rsp) )
+    while( mem_event_get_response(d, &d->mem_event->access, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -1196,13 +1200,8 @@ 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);
 }
 
-
 /* Set access type for a region of pfns.
  * If start_pfn == -1ul, sets the default access type */
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn, 
diff -r d3342b370b6f -r a85e7d46401b 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 d3342b370b6f -r a85e7d46401b xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,18 +24,24 @@
 #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_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);
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
+ * available space. For success or -EBUSY, the vCPU may be left blocked
+ * temporarily to ensure that the ring does not lose future events.  In
+ * general, you must follow a claim_slot() call with either put_request() or
+ * cancel_slot(), both of which are guaranteed to succeed. */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+
+void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med);
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                            mem_event_request_t *req);
+
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
+                           mem_event_response_t *rsp);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
 
-
 #endif /* __MEM_EVENT_H__ */
 
 
diff -r d3342b370b6f -r a85e7d46401b xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -478,18 +478,18 @@ 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);
+int 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, uint64_t buffer);
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
-{ }
-static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
-{ }
+static inline int p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
+{ return 0; }
+static inline int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+{ return 0; }
 #endif
 
 #ifdef __x86_64__
diff -r d3342b370b6f -r a85e7d46401b 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 d3342b370b6f -r a85e7d46401b 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,9 @@ 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 target_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +195,14 @@ 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;
+    /* the number of vCPUs blocked */
+    unsigned int blocked;
+    /* The last vcpu woken up */
+    unsigned int last_vcpu_wake_up;
 };
 
 struct mem_event_per_domain
@@ -615,9 +626,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 Wed Jan 11 18:39:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 18:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl34J-0004IC-MN; Wed, 11 Jan 2012 18:38:39 +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 1Rl34H-0004I7-LS
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:38:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326307094!52433055!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNjk3Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1356 invoked from network); 11 Jan 2012 18:38:14 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.83) by server-11.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 18:38:14 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 0630E250078;
	Wed, 11 Jan 2012 10:38:35 -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=ZgSXyt8pUdkte+4s9qVN1X
	imBBaOycRE0N6KpLhqDyVFadSDo2EcBHevdsGVZRIvNeD2se+csSx3OvssL5uId5
	DOTyXkH1jZmNarW0Czl0IPXnblhpaTtXOAhdpVLvWtQ1vmnu7anOoGwHB4PWDtTe
	Pwnj+EV8CHVGybbsMEAx0=
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=WQ3mRKsNIS/v
	QAIqXSUMFEQI1Ik=; b=HlpSMrFTXfgUAtwqi0ooaMhSfk3v0Dc5dYrH2hDu8VP5
	ef94UL9Oh7QRU8A/tHDwXFL2TwhnURU3PDC4uaIquMFHKwW1YyGTZvgcYfLamkRe
	LJeXKyJQwrBCOxYtROdsUOraxrTgMRP5ZDFsxsYbdevMI41xZAbJFUIO1PxPas0=
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 46B3825006C; 
	Wed, 11 Jan 2012 10:38:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ed4d429d7026a3cd2b336c69c6f2ada94e6c000b
Message-Id: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 11 Jan 2012 13:42:52 -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, olaf@apefle.de,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c       |   12 +-
 tools/libxc/xc_mem_event.c        |   23 +++-
 tools/libxc/xc_mem_paging.c       |   44 ++++----
 tools/libxc/xc_memshr.c           |  192 ++++++++++++++++++-------------------
 tools/libxc/xc_private.c          |   10 -
 tools/libxc/xenctrl.h             |    6 +-
 tools/memshr/interface.c          |    4 +-
 xen/arch/x86/domctl.c             |    1 -
 xen/arch/x86/mm/mem_access.c      |    7 +-
 xen/arch/x86/mm/mem_event.c       |   68 +++++++++++--
 xen/arch/x86/mm/mem_paging.c      |   13 +-
 xen/arch/x86/mm/mem_sharing.c     |  101 +++++++++++--------
 xen/arch/x86/x86_64/compat/mm.c   |   23 ++++
 xen/arch/x86/x86_64/mm.c          |   23 ++++
 xen/include/asm-x86/mem_access.h  |    3 +-
 xen/include/asm-x86/mem_event.h   |    2 +
 xen/include/asm-x86/mem_paging.h  |    3 +-
 xen/include/asm-x86/mem_sharing.h |    3 +
 xen/include/public/domctl.h       |   91 +++++------------
 xen/include/public/memory.h       |   74 ++++++++++++++
 20 files changed, 426 insertions(+), 277 deletions(-)


Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking vcpus
in the domctl lock is that dom0 is prevented from re-scheduling.

In this proposal we retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page operations
to use the memory_op hypercalls (e.g XENMEM_*).

While we naturally welcome comments on the correctness of the approach, we are also
concerned about the viability of this API change. With 4.2 coming, this is the right
time to get an interface right, for the long run.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -30,7 +30,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -38,15 +38,15 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_access_op_resume,
+                                XENMEM_access_op,
+                                gfn, NULL);
 }
 
 /*
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,8 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page,
-                         void *ring_page, unsigned long gfn)
+                         unsigned int mode, void *page, void *ring_page)
 {
     DECLARE_DOMCTL;
 
@@ -34,11 +33,25 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
+    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
-
-    domctl.u.mem_event_op.gfn = gfn;
     
     return do_domctl(xch, &domctl);
 }
 
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer)
+{
+    xen_mem_event_op_t meo;
+
+    memset(&meo, 0, sizeof(meo));
+
+    meo.op      = op;
+    meo.domain  = domain_id;
+    meo.gfn     = gfn;
+    meo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, mode, &meo, sizeof(meo));
+}
+
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -30,7 +30,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -38,31 +38,31 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_nominate,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_evict,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
@@ -79,10 +79,10 @@ int xc_mem_paging_load(xc_interface *xch
     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);
+    rc = xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, buffer);
 
     (void)munlock(buffer, XC_PAGE_SIZE);
     return rc;
@@ -90,10 +90,10 @@ int xc_mem_paging_load(xc_interface *xch
 
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_resume,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -36,32 +36,38 @@ int xc_memshr_control(xc_interface *xch,
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
     domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
+    op->op = XEN_DOMCTL_MEM_SHARING_CONTROL;
     op->u.enable = enable;
 
     return do_domctl(xch, &domctl);
 }
 
+static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
+                            xen_mem_sharing_op_t *mso)
+{
+    mso->domain = domid;
+
+    return do_memory_op(xch, XENMEM_sharing_op, mso, sizeof(*mso));
+}
+
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
-    op->u.nominate.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gfn;
+    mso.u.nominate.u.gfn = gfn; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
@@ -69,21 +75,19 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
-    op->u.nominate.u.grant_ref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gref;
+    mso.u.nominate.u.grant_ref = gref; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_share_gfns(xc_interface *xch,
@@ -94,21 +98,19 @@ int xc_memshr_share_gfns(xc_interface *x
                          unsigned long client_gfn,
                          uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    op->u.share.source_gfn    = source_gfn;
-    op->u.share.client_domain = client_domain;
-    op->u.share.client_gfn    = client_gfn;
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_share_grefs(xc_interface *xch,
@@ -119,21 +121,19 @@ int xc_memshr_share_grefs(xc_interface *
                           grant_ref_t client_gref,
                           uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
-    op->u.share.client_domain = client_domain;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.source_gfn, source_gref);
+    mso.u.share.client_domain = client_domain;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.client_gfn, client_gref);
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_add_to_physmap(xc_interface *xch,
@@ -143,85 +143,81 @@ int xc_memshr_add_to_physmap(xc_interfac
                     domid_t client_domain,
                     unsigned long client_gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain               = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
-    op->u.share.source_gfn      = source_gfn;
-    op->u.share.source_handle   = source_handle;
-    op->u.share.client_gfn      = client_gfn;
-    op->u.share.client_domain   = client_domain;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_add_physmap;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_resume;
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
-    op->u.debug.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gfn;
+    mso.u.debug.u.gfn = gfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long mfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
-    op->u.debug.u.mfn = mfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_mfn;
+    mso.u.debug.u.mfn = mfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
-    op->u.debug.u.gref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gref;
+    mso.u.debug.u.gref = gref; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
+long xc_sharing_freed_pages(xc_interface *xch)
+{
+    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);
+}
+
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_private.c
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -533,16 +533,6 @@ 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 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1872,8 +1872,10 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
-                          void *ring_page, unsigned long gfn);
+                         unsigned int mode, void *shared_page, void *ring_page);
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -186,12 +186,12 @@ int memshr_vbd_issue_ro_request(char *bu
            remove the relevant ones from the map */
         switch(ret)
         {
-            case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_S_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
                 if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
                                     source_st.domain, source_st.frame, source_st.handle);
                 break;
-            case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_C_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
                 if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
                                     client_st.domain, client_st.frame, client_st.handle);
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1463,7 +1463,6 @@ long arch_do_domctl(
             if ( !ret )
                 ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
         } 
     }
     break;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -25,14 +25,13 @@
 #include <asm/mem_event.h>
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
 {
     int rc;
 
-    switch( mec->op )
+    switch( meo->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
+    case XENMEM_access_op_resume:
     {
         p2m_mem_access_resume(d);
         rc = 0;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -28,6 +28,7 @@
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
+#include <asm/mem_sharing.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -49,7 +50,7 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->u.shared_addr;
+    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
@@ -457,6 +458,54 @@ static void mem_access_notification(stru
     p2m_mem_access_resume(v->domain);
 }
 
+struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
+{
+    struct domain *d;
+
+    /* Get the target domain */
+    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
+    if ( *rc != 0 )
+        return NULL;
+
+    /* Not dying? */
+    if ( d->is_dying )
+    {
+        rcu_unlock_domain(d);
+        *rc = -EINVAL;
+        return NULL;
+    }
+    
+    return d;
+}
+
+int do_mem_event_op(int op, uint32_t domain, void *arg)
+{
+    int ret;
+    struct domain *d;
+
+    d = get_mem_event_op_target(domain, &ret);
+    if ( !d )
+        return ret;
+
+    switch (op)
+    {
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_access_op:
+            ret = mem_access_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+        default:
+            ret = -ENOSYS;
+    }
+
+    rcu_unlock_domain(d);
+    return ret;
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -530,11 +579,8 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_paging_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
@@ -569,14 +615,14 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_access_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
+
+    default:
+        rc = -ENOSYS;
     }
 
     return rc;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,33 +25,32 @@
 #include <asm/mem_event.h>
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
     switch( mec->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE:
+    case XENMEM_paging_op_nominate:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT:
+    case XENMEM_paging_op_evict:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
+    case XENMEM_paging_op_prep:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
+        return p2m_mem_paging_prep(d, gfn, mec->buffer);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME:
+    case XENMEM_paging_op_resume:
     {
         p2m_mem_paging_resume(d);
         return 0;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -745,12 +745,12 @@ int mem_sharing_share_pages(struct domai
     }
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = firstpg = __grab_shared_page(smfn, &pld);
         if ( spage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = secondpg = __grab_shared_page(cmfn, &pld);
         if ( cpage == NULL )
         {
@@ -758,12 +758,12 @@ int mem_sharing_share_pages(struct domai
             goto err_out;
         }
     } else {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = firstpg = __grab_shared_page(cmfn, &pld);
         if ( cpage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = secondpg = __grab_shared_page(smfn, &pld);
         if ( spage == NULL )
         {
@@ -778,14 +778,14 @@ int mem_sharing_share_pages(struct domai
     /* Check that the handles match */
     if ( spage->shared_info->handle != sh )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_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;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg, &pld);
         mem_sharing_page_unlock(firstpg, &pld);
         goto err_out;
@@ -849,7 +849,7 @@ int mem_sharing_add_to_physmap(struct do
     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;
+    ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
     spage = __grab_shared_page(smfn, &pld);
     if ( spage == NULL )
         goto err_out;
@@ -863,7 +863,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( mfn_valid(cmfn) ||
          (!(p2m_is_ram(cmfn_type))) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
     }
 
@@ -1014,9 +1014,9 @@ private_page_found:
     return 0;
 }
 
-int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
-    int rc;
+    int rc = 0;
 
     /* Only HAP is supported */
     if ( !hap_enabled(d) )
@@ -1024,14 +1024,7 @@ int mem_sharing_domctl(struct domain *d,
 
     switch(mec->op)
     {
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL:
-        {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
-            rc = 0;
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN:
+        case XENMEM_sharing_op_nominate_gfn:
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
@@ -1042,7 +1035,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF:
+        case XENMEM_sharing_op_nominate_gref:
         {
             grant_ref_t gref = mec->u.nominate.u.grant_ref;
             unsigned long gfn;
@@ -1057,47 +1050,48 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
+        case XENMEM_sharing_op_share:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
             shr_handle_t sh, ch;
+            int rc;
 
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.source_gfn));
                 if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
                 sgfn  = mec->u.share.source_gfn;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.client_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.client_gfn));
                 if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
@@ -1109,33 +1103,34 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        case XENMEM_sharing_op_add_physmap:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
             shr_handle_t sh;
+            int rc;
 
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 /* Cannot add a gref to the physmap */
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
@@ -1145,11 +1140,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
+        case XENMEM_sharing_op_resume:
         {
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
@@ -1157,21 +1152,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN:
+        case XENMEM_sharing_op_debug_gfn:
         {
             unsigned long gfn = mec->u.debug.u.gfn;
             rc = mem_sharing_debug_gfn(d, gfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
+        case XENMEM_sharing_op_debug_mfn:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
             rc = mem_sharing_debug_mfn(mfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF:
+        case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;
             rc = mem_sharing_debug_gref(d, gref);
@@ -1188,6 +1183,30 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+{
+    int rc;
+
+    /* Only HAP is supported */
+    if ( !hap_enabled(d) )
+         return -ENODEV;
+
+    switch(mec->op)
+    {
+        case XEN_DOMCTL_MEM_SHARING_CONTROL:
+        {
+            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
+            rc = 0;
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -2,6 +2,7 @@
 #include <xen/multicall.h>
 #include <compat/memory.h>
 #include <compat/xen.h>
+#include <asm/mem_event.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -211,6 +212,28 @@ int compat_arch_memory_op(int op, XEN_GU
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_event.h>
 #include <asm/mem_sharing.h>
 #include <public/memory.h>
 
@@ -1100,6 +1101,28 @@ long subarch_memory_op(int op, XEN_GUEST
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -39,6 +39,8 @@ void mem_event_put_request(struct domain
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
+struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
+int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
 
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/asm-x86/mem_paging.h
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -23,6 +23,7 @@
 #define __MEM_SHARING_H__
 
 #include <public/domctl.h>
+#include <public/memory.h>
 
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 1
@@ -56,6 +57,8 @@ int mem_sharing_unshare_page(struct doma
                              unsigned long gfn, 
                              uint16_t flags);
 int mem_sharing_sharing_resume(struct domain *d);
+int mem_sharing_memop(struct domain *d, 
+                       xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
 void mem_sharing_init(void);
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -711,47 +711,46 @@ struct xen_domctl_gdbsx_domstatus {
 
 /*
 * Domain memory paging
- * Page memory in and out. 
+ * Page memory in and out.
+ * Domctl interface to set up and tear down the 
+ * pager<->hypervisor interface. Use XENMEM_paging_op*
+ * to perform per-page operations.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE   2
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
 
 /*
  * Access permissions.
  *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
  * There are HVM hypercalls to set the per-page access permissions of every
  * page in a domain.  When one of these permissions--independent, read, 
  * write, and execute--is violated, the VCPU is paused and a memory event 
- * is sent with what happened.  (See public/mem_event.h)  The memory event 
- * handler can then resume the VCPU and redo the access with an 
- * ACCESS_RESUME mode for the following domctl.
+ * is sent with what happened.  (See public/mem_event.h) .
+ *
+ * The memory event handler can then resume the VCPU and redo the access 
+ * with a XENMEM_access_op_resume hypercall.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME     2
 
+/* Use for teardown/setup of helper<->hypervisor interface for paging, 
+ * access and sharing.*/
 struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    union {
-        /* OP_ENABLE IN:  Virtual address of shared page */
-        uint64_aligned_t shared_addr;  
-        /* PAGING_PREP IN: buffer to immediately fill page in */
-        uint64_aligned_t buffer;
-    } u;
+    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
 
-    /* Other OPs */
-    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
+    /* For binary backwards compatibility */
+    uint64_aligned_t pad;
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
@@ -759,59 +758,23 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 /*
  * Memory sharing operations
  */
-/* XEN_DOMCTL_mem_sharing_op */
+/* XEN_DOMCTL_mem_sharing_op.
+ * The CONTROL sub-domctl is used for bringup/teardown. */
 
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING                3
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL        0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN   1
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF  2
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE          3
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME         4
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
-
-#define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
-#define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
-
-#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))
+#define XEN_DOMCTL_MEM_SHARING_CONTROL          0
 
 struct xen_domctl_mem_sharing_op {
-    uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
+    uint8_t op; /* XEN_DOMCTL_MEM_SHARING_* */
 
     union {
-        uint8_t enable;                   /* OP_CONTROL                */
+        uint8_t enable;                   /* CONTROL */
 
-        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
-            union {
-                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
-                uint32_t      grant_ref;  /* IN: grant ref to nominate */
-            } u;
-            uint64_aligned_t  handle;     /* OUT: the handle           */
-        } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
-            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
-            uint64_aligned_t source_handle; /* IN: handle to the source page */
-            domid_t          client_domain; /* IN: the client domain id */
-            uint64_aligned_t client_gfn;    /* IN: the client gfn */
-            uint64_aligned_t client_handle; /* IN: handle to the client page */
-        } share; 
-        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
-            union {
-                uint64_aligned_t gfn;      /* IN: gfn to debug          */
-                uint64_aligned_t mfn;      /* IN: mfn to debug          */
-                grant_ref_t    gref;       /* IN: gref to debug         */
-            } u;
-        } debug;
+        /* For binary backwards compatibility */
+        struct __pad {
+            uint64_aligned_t pad1[2];
+            domid_t          pad2;
+            uint64_aligned_t pad3[2];
+        } pad; 
     } u;
 };
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -296,6 +296,80 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_get_sharing_freed_pages    18
 #define XENMEM_get_sharing_shared_pages   19
 
+#define XENMEM_paging_op                    20
+#define XENMEM_paging_op_nominate           0
+#define XENMEM_paging_op_evict              1
+#define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_resume             3
+
+#define XENMEM_access_op                    21
+#define XENMEM_access_op_resume             0
+
+struct xen_mem_event_op {
+    uint8_t       op;           /* XENMEM_*_op_* */
+    domid_t       domain;
+
+    /* PAGING_PREP IN: buffer to immediately fill page in */
+    uint64_t buffer;
+    /* Other OPs */
+    uint64_t gfn;          /* IN:  gfn of page being operated on */
+};
+typedef struct xen_mem_event_op xen_mem_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op_t);
+
+#define XENMEM_sharing_op                   22
+#define XENMEM_sharing_op_nominate_gfn      0
+#define XENMEM_sharing_op_nominate_gref     1
+#define XENMEM_sharing_op_share             2
+#define XENMEM_sharing_op_resume            3
+#define XENMEM_sharing_op_debug_gfn         4
+#define XENMEM_sharing_op_debug_mfn         5
+#define XENMEM_sharing_op_debug_gref        6
+#define XENMEM_sharing_op_add_physmap       7
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
+
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field)         \
+    ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field)        \
+    ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+    uint8_t op; /* XENMEM_sharing_op_* */
+    domid_t domain;
+
+    union {
+        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
+            union {
+                uint64_t gfn;     /* IN: gfn to nominate       */
+                uint32_t      grant_ref;  /* IN: grant ref to nominate */
+            } u;
+            uint64_t  handle;     /* OUT: the handle           */
+        } nominate;
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
+            uint64_t source_gfn;    /* IN: the gfn of the source page */
+            uint64_t source_handle; /* IN: handle to the source page */
+            domid_t  client_domain; /* IN: the client domain id */
+            uint64_t client_gfn;    /* IN: the client gfn */
+            uint64_t client_handle; /* IN: handle to the client page */
+        } share; 
+        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
+            union {
+                uint64_t gfn;      /* IN: gfn to debug          */
+                uint64_t mfn;      /* IN: mfn to debug          */
+                uint32_t gref;     /* IN: gref to debug         */
+            } u;
+        } debug;
+    } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 18:39:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 18:39:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl34J-0004IC-MN; Wed, 11 Jan 2012 18:38:39 +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 1Rl34H-0004I7-LS
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 18:38:38 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326307094!52433055!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNjk3Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1356 invoked from network); 11 Jan 2012 18:38:14 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a18.g.dreamhost.com)
	(208.97.132.83) by server-11.tower-27.messagelabs.com with SMTP;
	11 Jan 2012 18:38:14 -0000
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 0630E250078;
	Wed, 11 Jan 2012 10:38:35 -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=ZgSXyt8pUdkte+4s9qVN1X
	imBBaOycRE0N6KpLhqDyVFadSDo2EcBHevdsGVZRIvNeD2se+csSx3OvssL5uId5
	DOTyXkH1jZmNarW0Czl0IPXnblhpaTtXOAhdpVLvWtQ1vmnu7anOoGwHB4PWDtTe
	Pwnj+EV8CHVGybbsMEAx0=
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=WQ3mRKsNIS/v
	QAIqXSUMFEQI1Ik=; b=HlpSMrFTXfgUAtwqi0ooaMhSfk3v0Dc5dYrH2hDu8VP5
	ef94UL9Oh7QRU8A/tHDwXFL2TwhnURU3PDC4uaIquMFHKwW1YyGTZvgcYfLamkRe
	LJeXKyJQwrBCOxYtROdsUOraxrTgMRP5ZDFsxsYbdevMI41xZAbJFUIO1PxPas0=
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 46B3825006C; 
	Wed, 11 Jan 2012 10:38:33 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: ed4d429d7026a3cd2b336c69c6f2ada94e6c000b
Message-Id: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 11 Jan 2012 13:42:52 -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, olaf@apefle.de,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c       |   12 +-
 tools/libxc/xc_mem_event.c        |   23 +++-
 tools/libxc/xc_mem_paging.c       |   44 ++++----
 tools/libxc/xc_memshr.c           |  192 ++++++++++++++++++-------------------
 tools/libxc/xc_private.c          |   10 -
 tools/libxc/xenctrl.h             |    6 +-
 tools/memshr/interface.c          |    4 +-
 xen/arch/x86/domctl.c             |    1 -
 xen/arch/x86/mm/mem_access.c      |    7 +-
 xen/arch/x86/mm/mem_event.c       |   68 +++++++++++--
 xen/arch/x86/mm/mem_paging.c      |   13 +-
 xen/arch/x86/mm/mem_sharing.c     |  101 +++++++++++--------
 xen/arch/x86/x86_64/compat/mm.c   |   23 ++++
 xen/arch/x86/x86_64/mm.c          |   23 ++++
 xen/include/asm-x86/mem_access.h  |    3 +-
 xen/include/asm-x86/mem_event.h   |    2 +
 xen/include/asm-x86/mem_paging.h  |    3 +-
 xen/include/asm-x86/mem_sharing.h |    3 +
 xen/include/public/domctl.h       |   91 +++++------------
 xen/include/public/memory.h       |   74 ++++++++++++++
 20 files changed, 426 insertions(+), 277 deletions(-)


Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking vcpus
in the domctl lock is that dom0 is prevented from re-scheduling.

In this proposal we retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page operations
to use the memory_op hypercalls (e.g XENMEM_*).

While we naturally welcome comments on the correctness of the approach, we are also
concerned about the viability of this API change. With 4.2 coming, this is the right
time to get an interface right, for the long run.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>

diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -30,7 +30,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -38,15 +38,15 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_access_op_resume,
+                                XENMEM_access_op,
+                                gfn, NULL);
 }
 
 /*
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,8 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page,
-                         void *ring_page, unsigned long gfn)
+                         unsigned int mode, void *page, void *ring_page)
 {
     DECLARE_DOMCTL;
 
@@ -34,11 +33,25 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
+    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
-
-    domctl.u.mem_event_op.gfn = gfn;
     
     return do_domctl(xch, &domctl);
 }
 
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer)
+{
+    xen_mem_event_op_t meo;
+
+    memset(&meo, 0, sizeof(meo));
+
+    meo.op      = op;
+    meo.domain  = domain_id;
+    meo.gfn     = gfn;
+    meo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, mode, &meo, sizeof(meo));
+}
+
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -30,7 +30,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -38,31 +38,31 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_nominate,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_evict,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
@@ -79,10 +79,10 @@ int xc_mem_paging_load(xc_interface *xch
     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);
+    rc = xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, buffer);
 
     (void)munlock(buffer, XC_PAGE_SIZE);
     return rc;
@@ -90,10 +90,10 @@ int xc_mem_paging_load(xc_interface *xch
 
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_resume,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -36,32 +36,38 @@ int xc_memshr_control(xc_interface *xch,
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
     domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
+    op->op = XEN_DOMCTL_MEM_SHARING_CONTROL;
     op->u.enable = enable;
 
     return do_domctl(xch, &domctl);
 }
 
+static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
+                            xen_mem_sharing_op_t *mso)
+{
+    mso->domain = domid;
+
+    return do_memory_op(xch, XENMEM_sharing_op, mso, sizeof(*mso));
+}
+
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
-    op->u.nominate.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gfn;
+    mso.u.nominate.u.gfn = gfn; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
@@ -69,21 +75,19 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
-    op->u.nominate.u.grant_ref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gref;
+    mso.u.nominate.u.grant_ref = gref; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_share_gfns(xc_interface *xch,
@@ -94,21 +98,19 @@ int xc_memshr_share_gfns(xc_interface *x
                          unsigned long client_gfn,
                          uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    op->u.share.source_gfn    = source_gfn;
-    op->u.share.client_domain = client_domain;
-    op->u.share.client_gfn    = client_gfn;
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_share_grefs(xc_interface *xch,
@@ -119,21 +121,19 @@ int xc_memshr_share_grefs(xc_interface *
                           grant_ref_t client_gref,
                           uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
-    op->u.share.client_domain = client_domain;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.source_gfn, source_gref);
+    mso.u.share.client_domain = client_domain;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.client_gfn, client_gref);
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_add_to_physmap(xc_interface *xch,
@@ -143,85 +143,81 @@ int xc_memshr_add_to_physmap(xc_interfac
                     domid_t client_domain,
                     unsigned long client_gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain               = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
-    op->u.share.source_gfn      = source_gfn;
-    op->u.share.source_handle   = source_handle;
-    op->u.share.client_gfn      = client_gfn;
-    op->u.share.client_domain   = client_domain;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_add_physmap;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_resume;
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
-    op->u.debug.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gfn;
+    mso.u.debug.u.gfn = gfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long mfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
-    op->u.debug.u.mfn = mfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_mfn;
+    mso.u.debug.u.mfn = mfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
-    op->u.debug.u.gref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gref;
+    mso.u.debug.u.gref = gref; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
+long xc_sharing_freed_pages(xc_interface *xch)
+{
+    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);
+}
+
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xc_private.c
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -533,16 +533,6 @@ 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 3b1c596bc1b4 -r ed4d429d7026 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1872,8 +1872,10 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
-                          void *ring_page, unsigned long gfn);
+                         unsigned int mode, void *shared_page, void *ring_page);
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 3b1c596bc1b4 -r ed4d429d7026 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -186,12 +186,12 @@ int memshr_vbd_issue_ro_request(char *bu
            remove the relevant ones from the map */
         switch(ret)
         {
-            case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_S_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
                 if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
                                     source_st.domain, source_st.frame, source_st.handle);
                 break;
-            case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_C_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
                 if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
                                     client_st.domain, client_st.frame, client_st.handle);
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1463,7 +1463,6 @@ long arch_do_domctl(
             if ( !ret )
                 ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
         } 
     }
     break;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -25,14 +25,13 @@
 #include <asm/mem_event.h>
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
 {
     int rc;
 
-    switch( mec->op )
+    switch( meo->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
+    case XENMEM_access_op_resume:
     {
         p2m_mem_access_resume(d);
         rc = 0;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -28,6 +28,7 @@
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
+#include <asm/mem_sharing.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -49,7 +50,7 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->u.shared_addr;
+    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
@@ -457,6 +458,54 @@ static void mem_access_notification(stru
     p2m_mem_access_resume(v->domain);
 }
 
+struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
+{
+    struct domain *d;
+
+    /* Get the target domain */
+    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
+    if ( *rc != 0 )
+        return NULL;
+
+    /* Not dying? */
+    if ( d->is_dying )
+    {
+        rcu_unlock_domain(d);
+        *rc = -EINVAL;
+        return NULL;
+    }
+    
+    return d;
+}
+
+int do_mem_event_op(int op, uint32_t domain, void *arg)
+{
+    int ret;
+    struct domain *d;
+
+    d = get_mem_event_op_target(domain, &ret);
+    if ( !d )
+        return ret;
+
+    switch (op)
+    {
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_access_op:
+            ret = mem_access_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+        default:
+            ret = -ENOSYS;
+    }
+
+    rcu_unlock_domain(d);
+    return ret;
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -530,11 +579,8 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_paging_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
@@ -569,14 +615,14 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_access_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
+
+    default:
+        rc = -ENOSYS;
     }
 
     return rc;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,33 +25,32 @@
 #include <asm/mem_event.h>
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
     switch( mec->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE:
+    case XENMEM_paging_op_nominate:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT:
+    case XENMEM_paging_op_evict:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
+    case XENMEM_paging_op_prep:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
+        return p2m_mem_paging_prep(d, gfn, mec->buffer);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME:
+    case XENMEM_paging_op_resume:
     {
         p2m_mem_paging_resume(d);
         return 0;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -745,12 +745,12 @@ int mem_sharing_share_pages(struct domai
     }
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = firstpg = __grab_shared_page(smfn, &pld);
         if ( spage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = secondpg = __grab_shared_page(cmfn, &pld);
         if ( cpage == NULL )
         {
@@ -758,12 +758,12 @@ int mem_sharing_share_pages(struct domai
             goto err_out;
         }
     } else {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = firstpg = __grab_shared_page(cmfn, &pld);
         if ( cpage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = secondpg = __grab_shared_page(smfn, &pld);
         if ( spage == NULL )
         {
@@ -778,14 +778,14 @@ int mem_sharing_share_pages(struct domai
     /* Check that the handles match */
     if ( spage->shared_info->handle != sh )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_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;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg, &pld);
         mem_sharing_page_unlock(firstpg, &pld);
         goto err_out;
@@ -849,7 +849,7 @@ int mem_sharing_add_to_physmap(struct do
     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;
+    ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
     spage = __grab_shared_page(smfn, &pld);
     if ( spage == NULL )
         goto err_out;
@@ -863,7 +863,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( mfn_valid(cmfn) ||
          (!(p2m_is_ram(cmfn_type))) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
     }
 
@@ -1014,9 +1014,9 @@ private_page_found:
     return 0;
 }
 
-int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
-    int rc;
+    int rc = 0;
 
     /* Only HAP is supported */
     if ( !hap_enabled(d) )
@@ -1024,14 +1024,7 @@ int mem_sharing_domctl(struct domain *d,
 
     switch(mec->op)
     {
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL:
-        {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
-            rc = 0;
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN:
+        case XENMEM_sharing_op_nominate_gfn:
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
@@ -1042,7 +1035,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF:
+        case XENMEM_sharing_op_nominate_gref:
         {
             grant_ref_t gref = mec->u.nominate.u.grant_ref;
             unsigned long gfn;
@@ -1057,47 +1050,48 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
+        case XENMEM_sharing_op_share:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
             shr_handle_t sh, ch;
+            int rc;
 
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.source_gfn));
                 if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
                 sgfn  = mec->u.share.source_gfn;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.client_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.client_gfn));
                 if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
@@ -1109,33 +1103,34 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        case XENMEM_sharing_op_add_physmap:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
             shr_handle_t sh;
+            int rc;
 
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 /* Cannot add a gref to the physmap */
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
@@ -1145,11 +1140,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
+        case XENMEM_sharing_op_resume:
         {
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
@@ -1157,21 +1152,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN:
+        case XENMEM_sharing_op_debug_gfn:
         {
             unsigned long gfn = mec->u.debug.u.gfn;
             rc = mem_sharing_debug_gfn(d, gfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
+        case XENMEM_sharing_op_debug_mfn:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
             rc = mem_sharing_debug_mfn(mfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF:
+        case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;
             rc = mem_sharing_debug_gref(d, gref);
@@ -1188,6 +1183,30 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+{
+    int rc;
+
+    /* Only HAP is supported */
+    if ( !hap_enabled(d) )
+         return -ENODEV;
+
+    switch(mec->op)
+    {
+        case XEN_DOMCTL_MEM_SHARING_CONTROL:
+        {
+            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
+            rc = 0;
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -2,6 +2,7 @@
 #include <xen/multicall.h>
 #include <compat/memory.h>
 #include <compat/xen.h>
+#include <asm/mem_event.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -211,6 +212,28 @@ int compat_arch_memory_op(int op, XEN_GU
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_event.h>
 #include <asm/mem_sharing.h>
 #include <public/memory.h>
 
@@ -1100,6 +1101,28 @@ long subarch_memory_op(int op, XEN_GUEST
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -39,6 +39,8 @@ void mem_event_put_request(struct domain
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
+struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
+int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
 
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/asm-x86/mem_paging.h
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -23,6 +23,7 @@
 #define __MEM_SHARING_H__
 
 #include <public/domctl.h>
+#include <public/memory.h>
 
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 1
@@ -56,6 +57,8 @@ int mem_sharing_unshare_page(struct doma
                              unsigned long gfn, 
                              uint16_t flags);
 int mem_sharing_sharing_resume(struct domain *d);
+int mem_sharing_memop(struct domain *d, 
+                       xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
 void mem_sharing_init(void);
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -711,47 +711,46 @@ struct xen_domctl_gdbsx_domstatus {
 
 /*
 * Domain memory paging
- * Page memory in and out. 
+ * Page memory in and out.
+ * Domctl interface to set up and tear down the 
+ * pager<->hypervisor interface. Use XENMEM_paging_op*
+ * to perform per-page operations.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE   2
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
 
 /*
  * Access permissions.
  *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
  * There are HVM hypercalls to set the per-page access permissions of every
  * page in a domain.  When one of these permissions--independent, read, 
  * write, and execute--is violated, the VCPU is paused and a memory event 
- * is sent with what happened.  (See public/mem_event.h)  The memory event 
- * handler can then resume the VCPU and redo the access with an 
- * ACCESS_RESUME mode for the following domctl.
+ * is sent with what happened.  (See public/mem_event.h) .
+ *
+ * The memory event handler can then resume the VCPU and redo the access 
+ * with a XENMEM_access_op_resume hypercall.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME     2
 
+/* Use for teardown/setup of helper<->hypervisor interface for paging, 
+ * access and sharing.*/
 struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    union {
-        /* OP_ENABLE IN:  Virtual address of shared page */
-        uint64_aligned_t shared_addr;  
-        /* PAGING_PREP IN: buffer to immediately fill page in */
-        uint64_aligned_t buffer;
-    } u;
+    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
 
-    /* Other OPs */
-    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
+    /* For binary backwards compatibility */
+    uint64_aligned_t pad;
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
@@ -759,59 +758,23 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 /*
  * Memory sharing operations
  */
-/* XEN_DOMCTL_mem_sharing_op */
+/* XEN_DOMCTL_mem_sharing_op.
+ * The CONTROL sub-domctl is used for bringup/teardown. */
 
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING                3
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL        0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN   1
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF  2
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE          3
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME         4
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
-
-#define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
-#define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
-
-#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))
+#define XEN_DOMCTL_MEM_SHARING_CONTROL          0
 
 struct xen_domctl_mem_sharing_op {
-    uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
+    uint8_t op; /* XEN_DOMCTL_MEM_SHARING_* */
 
     union {
-        uint8_t enable;                   /* OP_CONTROL                */
+        uint8_t enable;                   /* CONTROL */
 
-        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
-            union {
-                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
-                uint32_t      grant_ref;  /* IN: grant ref to nominate */
-            } u;
-            uint64_aligned_t  handle;     /* OUT: the handle           */
-        } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
-            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
-            uint64_aligned_t source_handle; /* IN: handle to the source page */
-            domid_t          client_domain; /* IN: the client domain id */
-            uint64_aligned_t client_gfn;    /* IN: the client gfn */
-            uint64_aligned_t client_handle; /* IN: handle to the client page */
-        } share; 
-        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
-            union {
-                uint64_aligned_t gfn;      /* IN: gfn to debug          */
-                uint64_aligned_t mfn;      /* IN: mfn to debug          */
-                grant_ref_t    gref;       /* IN: gref to debug         */
-            } u;
-        } debug;
+        /* For binary backwards compatibility */
+        struct __pad {
+            uint64_aligned_t pad1[2];
+            domid_t          pad2;
+            uint64_aligned_t pad3[2];
+        } pad; 
     } u;
 };
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
diff -r 3b1c596bc1b4 -r ed4d429d7026 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -296,6 +296,80 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_get_sharing_freed_pages    18
 #define XENMEM_get_sharing_shared_pages   19
 
+#define XENMEM_paging_op                    20
+#define XENMEM_paging_op_nominate           0
+#define XENMEM_paging_op_evict              1
+#define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_resume             3
+
+#define XENMEM_access_op                    21
+#define XENMEM_access_op_resume             0
+
+struct xen_mem_event_op {
+    uint8_t       op;           /* XENMEM_*_op_* */
+    domid_t       domain;
+
+    /* PAGING_PREP IN: buffer to immediately fill page in */
+    uint64_t buffer;
+    /* Other OPs */
+    uint64_t gfn;          /* IN:  gfn of page being operated on */
+};
+typedef struct xen_mem_event_op xen_mem_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op_t);
+
+#define XENMEM_sharing_op                   22
+#define XENMEM_sharing_op_nominate_gfn      0
+#define XENMEM_sharing_op_nominate_gref     1
+#define XENMEM_sharing_op_share             2
+#define XENMEM_sharing_op_resume            3
+#define XENMEM_sharing_op_debug_gfn         4
+#define XENMEM_sharing_op_debug_mfn         5
+#define XENMEM_sharing_op_debug_gref        6
+#define XENMEM_sharing_op_add_physmap       7
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
+
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field)         \
+    ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field)        \
+    ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+    uint8_t op; /* XENMEM_sharing_op_* */
+    domid_t domain;
+
+    union {
+        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
+            union {
+                uint64_t gfn;     /* IN: gfn to nominate       */
+                uint32_t      grant_ref;  /* IN: grant ref to nominate */
+            } u;
+            uint64_t  handle;     /* OUT: the handle           */
+        } nominate;
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
+            uint64_t source_gfn;    /* IN: the gfn of the source page */
+            uint64_t source_handle; /* IN: handle to the source page */
+            domid_t  client_domain; /* IN: the client domain id */
+            uint64_t client_gfn;    /* IN: the client gfn */
+            uint64_t client_handle; /* IN: handle to the client page */
+        } share; 
+        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
+            union {
+                uint64_t gfn;      /* IN: gfn to debug          */
+                uint64_t mfn;      /* IN: mfn to debug          */
+                uint32_t gref;     /* IN: gref to debug         */
+            } u;
+        } debug;
+    } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 20:07:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 20: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 1Rl4RV-0005dX-Fb; Wed, 11 Jan 2012 20:06:41 +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 1Rl4RU-0005dS-Ad
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 20:06:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326312391!10529100!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NjQ0OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23690 invoked from network); 11 Jan 2012 20:06:32 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 20:06:32 -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
	q0BK6Pgf030215
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 20:06:26 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
	q0BK6OOu002190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 20:06:24 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0BK6NU3017632; Wed, 11 Jan 2012 14:06:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 12:06:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 985C340101; Wed, 11 Jan 2012 15:04:35 -0500 (EST)
Date: Wed, 11 Jan 2012 15:04:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tejun Heo <tj@kernel.org>
Message-ID: <20120111200435.GA8680@phenom.dumpdata.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
	<20120110224537.GA6572@phenom.dumpdata.com>
	<20120110231552.GB26832@google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120110231552.GB26832@google.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.4F0DEBC3.0015,ss=1,re=-2.300,fgs=0
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 10, 2012 at 03:15:52PM -0800, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 10, 2012 at 05:45:37PM -0500, Konrad Rzeszutek Wilk wrote:
> > (early) [    0.000000] memblock_find: [0x0, 0xfcdd000) size=8409088 align=4096 nid=1024
> > (early) [    0.000000] memblock_find: [0x805000, 0xfcdd000) - adjusted
> > (early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0xfcdd000, 0xfcdd000) (early) - rejected
> > (early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x1e03000, 0x220a000) (early) - rejected
> > (early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x805000, 0x1000000) (early) - rejected
> > (early) [    0.000000] memblock_find: cand [0x10000, 0x9b000) -> (early) [0x805000, 0x805000) (early) - rejected
> > (early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
> 
> So, it actually is a legitimate alloc failure.  It seems I've tried a
> bit too hard at simplifying the allocator.  Does the following fix the
> problem?
> 
> Thanks.
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2f55f19..77b5f22 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -106,14 +106,17 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>  	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
>  		end = memblock.current_limit;
>  
> -	/* adjust @start to avoid underflow and allocating the first page */
> -	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
> +	/* avoid allocating the first page */
> +	start = max_t(phys_addr_t, start, PAGE_SIZE);
>  	end = max(start, end);
>  
>  	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
>  		this_start = clamp(this_start, start, end);
>  		this_end = clamp(this_end, start, end);
>  
> +		if (this_end < size)
> +			continue;
> +
>  		cand = round_down(this_end - size, align);
>  		if (cand >= this_start)
>  			return cand;

With that patch it boots!


(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-05693-g2c81411 (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP PREEMPT Wed Jan 11 13:19:30 EST 2012
(early) [    0.000000] Command line: console=hvc0 debug earlyprintk=xen
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Released 0 pages of unused memory
(early) [    0.000000] Set 0 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 - 0000000200800000 (usable)
(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] e820 update range: 0000000000000000 - 0000000000010000 (early) (usable)(early)  ==> (early) (reserved)(early) 
(early) [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (early) (usable)(early) 
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x200800 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
(early) [    0.000000] initial memory mapped : 0 - 10006000
(early) [    0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480
(early) [    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
(early) [    0.000000]  0000000000 - 0100000000 page 4k
(early) [    0.000000] kernel direct mapping tables up to 100000000 @ 7fb000-1000000
(early) [    0.000000] xen: setting RW the range f74000 - 1000000
(early) [    0.000000] init_memory_mapping: 0000000100000000-0000000200800000
(early) [    0.000000]  0100000000 - 0200800000 page 4k
(early) [    0.000000] kernel direct mapping tables up to 200800000 @ feff2000-100000000
(early) [    0.000000] xen: setting RW the range ff7fb000 - 100000000
(early) [    0.000000] RAMDISK: 02249000 - 10006000
(early) [    0.000000] No NUMA configuration found
(early) [    0.000000] Faking a node at 0000000000000000-0000000200800000
(early) [    0.000000] Initmem setup node 0 0000000000000000-0000000200800000
(early) [    0.000000]   NODE_DATA [00000000fffd9000 - 00000000ffffffff]
(early) [    0.000000] Zone PFN ranges:
(early) [    0.000000]   DMA      (early) 0x00000010 -> 0x00001000
(early) [    0.000000]   DMA32    (early) 0x00001000 -> 0x00100000
(early) [    0.000000]   Normal   (early) 0x00100000 -> 0x00200800
(early) [    0.000000] Movable zone start PFN for each node
(early) [    0.000000] Early memory PFN ranges
(early) [    0.000000]     0: 0x00000010 -> 0x000000a0
(early) [    0.000000]     0: 0x00000100 -> 0x00200800
(early) [    0.000000] On node 0 totalpages: 2099088
(early) [    0.000000]   DMA zone: 64 pages used for memmap
(early) [    0.000000]   DMA zone: 1918 pages reserved
(early) [    0.000000]   DMA zone: 2002 pages, LIFO batch:0
(early) [    0.000000]   DMA32 zone: 16320 pages used for memmap
(early) [    0.000000]   DMA32 zone: 1028160 pages, LIFO batch:31
(early) [    0.000000]   Normal zone: 16416 pages used for memmap
(early) [    0.000000]   Normal zone: 1034208 pages, LIFO batch:31
(early) [    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
(early) [    0.000000] No local APIC present
(early) [    0.000000] APIC: disable apic facility
(early) [    0.000000] APIC: switched to apic NOOP
(early) [    0.000000] nr_irqs_gsi: 16
(early) [    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
(early) [    0.000000] PCI: Warning: Cannot find a gap in the 32bit address range
(early) [    0.000000] PCI: Unassigned devices with 32bit resource registers may break!
(early) [    0.000000] Allocating PCI resources starting at 200900000 (gap: 200900000:400000)
(early) [    0.000000] Booting paravirtualized kernel on Xen
(early) [    0.000000] Xen version: 4.1-120111 (preserve-AD)
(early) [    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
(early) [    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8800fff31000 s82752 r8192 d23744 u114688
(early) [    0.000000] pcpu-alloc: s82752 r8192 d23744 u114688 alloc=28*4096(early) 
(early) [    0.000000] pcpu-alloc: (early) [0] (early) 0 (early) [0] (early) 1 (early) [0] (early) 2 (early) [0] (early) 3 (early) 
(early) [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2064370
(early) [    0.000000] Policy zone: Normal
(early) [    0.000000] Kernel command line: console=hvc0 debug earlyprintk=xen
(early) [    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
(early) [    0.000000] Checking aperture...
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] Calgary: detecting Calgary via BIOS EBDA area
(early) [    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
(early) [    0.000000] Memory: 3727344k/8396800k available (6482k kernel code, 448k absent, 4669008k reserved, 4624k data, 1256k init)
(early) [    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
(early) [    0.000000] Preemptible hierarchical RCU implementation.
(early) [    0.000000] NR_IRQS:262400 nr_irqs:304 16
(early) [    0.000000] kmemleak: Early log buffer exceeded, please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE
(early) [    0.000000] kmemleak: Kernel memory leak detector disabled
(early) [    0.000000] Console: colour dummy device 80x25
(early) [    0.000000] console [tty0] enabled
[    0.000000] console [hvc0] enabled, bootconsole disabled
(early) [    0.000000] console [hvc0] enabled, bootconsole disabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] Detected 3292.616 MHz processor.
[    0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 6585.23 BogoMIPS (lpj=3292616)
[    0.000999] pid_max: default: 32768 minimum: 301
[    0.000999] Security Framework initialized
[    0.000999] SELinux:  Initializing.
[    0.000999] SELinux:  Starting in permissive mode
[    0.002170] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    0.004675] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.005213] Mount-cache hash table entries: 256
[    0.005428] Initializing cgroup subsys cpuacct
[    0.005436] Initializing cgroup subsys freezer
[    0.005497] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    0.005498] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[    0.005510] CPU: Physical Processor ID: 0
[    0.005515] CPU: Processor Core ID: 0
[    0.005576] SMP alternatives: switching to UP code
[    0.005999] ftrace: allocating 23453 entries in 92 pages
[    0.006057] cpu 0 spinlock event irq 17
[    0.006112] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only.
[    0.012038] NMI watchdog disabled (cpu0): hardware events not enabled
[    0.018010] installing Xen timer for CPU 1
[    0.018028] cpu 1 spinlock event irq 23
[    0.018051] SMP alternatives: switching to SMP code
[    0.019085] NMI watchdog disabled (cpu1): hardware events not enabled
[    0.025009] installing Xen timer for CPU 2
[    0.025027] cpu 2 spinlock event irq 29
[    0.025121] NMI watchdog disabled (cpu2): hardware events not enabled
[    0.031008] installing Xen timer for CPU 3
[    0.031024] cpu 3 spinlock event irq 35
[    0.031118] NMI watchdog disabled (cpu3): hardware events not enabled
[    0.033006] Brought up 4 CPUs
[    0.033666] kworker/u:0 used greatest stack depth: 5272 bytes left
[    0.033666] Grant tables using version 2 layout.
[    0.033666] Grant table initialized
[    0.052849] RTC time: 165:165:165, date: 165/165/65
[    0.053033] NET: Registered protocol family 16
[    0.054556] PCI: setting up Xen PCI frontend stub
[    0.054565] PCI: pci_cache_line_size set to 64 bytes
[    0.065198] bio: create slab <bio-0> at 0
[    0.065198] ACPI: Interpreter disabled.
[    0.066004] xen/balloon: Initialising balloon driver.
[    0.076187] xen-balloon: Initialising balloon driver.
[    0.076187] vgaarb: loaded
[    0.077064] usbcore: registered new interface driver usbfs
[    0.077067] usbcore: registered new interface driver hub
[    0.077107] usbcore: registered new device driver usb
[    0.077107] PCI: System does not support PCI
[    0.077107] PCI: System does not support PCI
[    0.078054] NetLabel: Initializing
[    0.078054] NetLabel:  domain hash size = 128
[    0.078054] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.078054] NetLabel:  unlabeled traffic allowed by default
[    0.078109] Switching to clocksource xen
[    0.083574] pnp: PnP ACPI: disabled
[    0.089832] PCI: max bus depth: 0 pci_try_num: 1
[    0.089877] NET: Registered protocol family 2
[    0.090665] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.093957] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.095324] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.095466] TCP: Hash tables configured (established 524288 bind 65536)
[    0.095474] TCP reno registered
[    0.095526] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[    0.095597] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[    0.095720] NET: Registered protocol family 1
[    0.095957] RPC: Registered named UNIX socket transport module.
[    0.095965] RPC: Registered udp transport module.
[    0.095970] RPC: Registered tcp transport module.
[    0.095976] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.095984] PCI: CLS 0 bytes, default 64
[    0.096219] Trying to unpack rootfs image as initramfs...
[    0.431565] Freeing initrd memory: 227060k freed
[    0.475737] DMA-API: preallocated 32768 debug entries
[    0.475961] DMA-API: debugging enabled by kernel config
[    0.475969] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.475977] Placing 64MB software IO TLB between ffff8800f2800000 - ffff8800f6800000
[    0.475984] software IO TLB at phys 0xf2800000 - 0xf6800000
[    0.476324] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.476472] Machine check injector initialized
[    0.477452] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x17
[    0.477466] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x17
[    0.477486] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x17
[    0.477503] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x17
[    0.477586] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    0.478032] audit: initializing netlink socket (disabled)
[    0.478053] type=2000 audit(1326338469.110:1): initialized
[    0.494006] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    0.499995] VFS: Disk quotas dquot_6.5.2
[    0.500208] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.501045] NTFS driver 2.1.30 [Flags: R/W].
[    0.501365] msgmni has been set to 7723
[    0.501583] SELinux:  Registering netfilter hooks
[    0.502294] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.502303] io scheduler noop registered
[    0.502309] io scheduler deadline registered
[    0.502405] io scheduler cfq registered (default)
[    0.502633] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.542586] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.573641] Non-volatile memory driver v1.3
[    0.573649] Linux agpgart interface v0.103
[    0.574083] [drm] Initialized drm 1.1.0 20060810
[    0.577049] brd: module loaded
[    0.578684] loop: module loaded
[    0.579544] Fixed MDIO Bus: probed
[    0.579551] tun: Universal TUN/TAP device driver, 1.6
[    0.579556] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    0.580300] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.580308] ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96
[    0.580386] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.580392] ohci_hcd: block sizes: ed 80 td 96
[    0.580466] uhci_hcd: USB Universal Host Controller Interface driver
[    0.580701] usbcore: registered new interface driver usblp
[    0.580780] usbcore: registered new interface driver libusual
[    0.581039] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    0.581865] i8042: No controller found
[    0.581951] mousedev: PS/2 mouse device common for all mice
[    0.622367] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    0.622469] rtc_cmos: probe of rtc_cmos failed with error -38
[    0.622730] EFI Variables Facility v0.08 2004-May-17
[    0.622805] zram: num_devices not specified. Using default: 1
[    0.622812] zram: Creating 1 devices ...
[    0.623448] Netfilter messages via NETLINK v0.30.
[    0.623467] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    0.623780] ctnetlink v0.93: registering with nfnetlink.
[    0.625065] ip_tables: (C) 2000-2006 Netfilter Core Team
[    0.625099] TCP cubic registered
[    0.625105] Initializing XFRM netlink socket
[    0.625468] NET: Registered protocol family 10
[    0.627394] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    0.627485] IPv6 over IPv4 tunneling driver
[    0.629062] NET: Registered protocol family 17
[    0.629097] Registering the dns_resolver key type
[    0.629362] PM: Hibernation image not present or could not be loaded.
[    0.629386] registered taskstats version 1
[    0.629448] XENBUS: Device with no driver: device/vif/0
[    0.629454] XENBUS: Device with no driver: device/vfb/0
[    0.629460] XENBUS: Device with no driver: device/vkbd/0
[    0.629475]   Magic number: 1:252:3141
[    0.630415] Freeing unused kernel memory: 1256k freed
[    0.630622] Write protecting the kernel read-only data: 10240k
[    0.636139] Freeing unused kernel memory: 1688k freed
[    0.636508] Freeing unused kernel memory: 112k freed
init started: BusyBox v1.14.3 (2012-01-11 13:22:11 EST)
[    0.641820] consoletype used greatest stack depth: 5232 bytes left
Mounting directories  [  OK  ]
[    0.860513] modprobe used greatest stack depth: 5008 bytes left
mount: mount point /sys/kernel/config does not exist
[    0.865846] core_filesystem used greatest stack depth: 4880 bytes left
[    0.874814] input: Xen Virtual Keyboard as /devices/virtual/input/input0
[    0.875019] input: Xen Virtual Pointer as /devices/virtual/input/input1
[    1.086237] Initialising Xen virtual ethernet driver.
[    1.201417] udevd (1186): /proc/1186/oom_adj is deprecated, please use /proc/1186/oom_score_adj instead.
udevd-work[1202]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory

[    1.307448] ip used greatest stack depth: 3696 bytes left
Waiting for devices [  OK  ]
Waiting for fb [  OK  ]
Starting..[/dev/fb0]
/dev/fb0: len:0
/dev/fb0: bits/pixel32
(7fa51499a000): Writting .. [800:600]
Done!
FATAL: Module agpgart_intel not found.
[    1.464693] Console: switching to colour frame buffer device 100x37
[    1.478942] [drm] radeon kernel modesetting enabled.
WARNING: Error inserting video (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/acpi/video.ko): No such device
WARNING: Error inserting mxm_wmi (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/platform/x86/mxm-wmi.ko): No such device
WARNING: Error inserting drm_kms_helper (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
WARNING: Error inserting ttm (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/ttm/ttm.ko): No such device
FATAL: Error inserting nouveau (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/nouveau/nouveau.ko): No such device
WARNING: Error inserting drm_kms_helper (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
FATAL: Error inserting i915 (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/i915/i915.ko): No such device
Starting..[/dev/fb0]
/dev/fb0: len:0
/dev/fb0: bits/pixel32
(7fc2635c3000): Writting .. [800:600]
Done!
VGA: 0000:
Waiting for network [  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  [    1.743980] device eth0 entered promiscuous mode
[  OK  ]
Bringing up interface switch:  
Determining IP information for switch...[    1.790208] switch: port 1(eth0) entering forwarding state
[    1.790244] switch: port 1(eth0) entering forwarding state
[    1.790880] ip used greatest stack depth: 3376 bytes left
 done.
[  OK  ]
Waiting for init.custom [  OK  ]

Starting SSHd ...

    SSH started [2314]


Waiting for SSHd [  OK  ]
WARNING: ssh currently running [2314] ignoring start request
FATAL: Module dump_dma not found.
ERROR: Module dump_dma does not exist in /proc/modules
[    3.562254] SCSI subsystem initialized
[    3.563911] Loading iSCSI transport class v2.0-870.
[    3.566452] iscsi: registered transport (tcp)
iscsistart: transport class version 2.0-870. iscsid version 2.0-872
Could not get list of targets from firmware.
Jan 12 03:21:12 g-pvops syslogd 1.5.0: restart.
FATAL: Module evtchn not found.
[    3.595640] Event-channel device installed.
xencommons should be started first.
           CPU0       CPU1       CPU2       CPU3       
 16:       1330          0          0          0  xen-percpu-virq      timer0
 17:          6          0          0          0  xen-percpu-ipi       spinlock0
 18:       1872          0          0          0  xen-percpu-ipi       resched0
 19:        129          0          0          0  xen-percpu-ipi       callfunc0
 20:          0          0          0          0  xen-percpu-virq      debug0
 21:         77          0          0          0  xen-percpu-ipi       callfuncsingle0
 22:          0       1811          0          0  xen-percpu-virq      timer1
 23:          0         14          0          0  xen-percpu-ipi       spinlock1
 24:          0       2411          0          0  xen-percpu-ipi       resched1
 25:          0        140          0          0  xen-percpu-ipi       callfunc1
 26:          0          0          0          0  xen-percpu-virq      debug1
 27:          0         78          0          0  xen-percpu-ipi       callfuncsingle1
 28:          0          0       1204          0  xen-percpu-virq      timer2
 29:          0          0          5          0  xen-percpu-ipi       spinlock2
 30:          0          0       3713          0  xen-percpu-ipi       resched2
 31:          0          0        148          0  xen-percpu-ipi       callfunc2
 32:          0          0          0          0  xen-percpu-virq      debug2
 33:          0          0        103          0  xen-percpu-ipi       callfuncsingle2
 34:          0          0          0       1373  xen-percpu-virq      timer3
 35:          0          0          0          5  xen-percpu-ipi       spinlock3
 36:          0          0          0       2474  xen-percpu-ipi       resched3
 37:          0          0          0        131  xen-percpu-ipi       callfunc3
 38:          0          0          0          0  xen-percpu-virq      debug3
 39:          0          0          0         88  xen-percpu-ipi       callfuncsingle3
 40:        423          0          0          0   xen-dyn-event     xenbus
 41:         81          0          0          0   xen-dyn-event     hvc_console
 42:          0          0          0          0   xen-dyn-event     vkbd
 43:         70          0          0          0   xen-dyn-event     vfb
 44:         20          0          0          0   xen-dyn-event     eth0
NMI:          0          0          0          0   Non-maskable interrupts
LOC:          0          0          0          0   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RTR:          0          0          0          0   APIC ICR read retries
RES:       1872       2411       3713       2474   Rescheduling interrupts
CAL:        206        218        251        219   Function call interrupts
TLB:          0          0          0          0   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:          0          0          0          0   Machine check polls
ERR:          0
MIS:          0
00000000-0000ffff : reserved
00010000-0009ffff : System RAM
000a0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-2007fffff : System RAM
  01000000-016549db : Kernel code
  016549dc-01ad89ff : Kernel data
  01c1a000-01e2afff : Kernel bss
Waiting for init.late [  OK  ]
PING build.dumpdata.com (192.168.101.3) 56(84) bytes of data.

--- build.dumpdata.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.329/0.329/0.329/0.000 ms
NFS done
 [0x0->0x100000] pfn
 [0x0->0x100000] level entry
 [0x100000->0x7cfffff] missing
 [0x100000->0x7cfffff] level top
libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running?
failed to stat /var/run/xenstored.pid: No such file or directory
cannot init xl context
[    4.481012] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
[    4.482152] device-mapper: multipath: version 1.3.0 loaded
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260]
Jan 12 03:21:13 g-pvops iscsid: transport class version 2.0-870. iscsid version 2.0-872
Jan 12 03:21:13 g-pvops iscsid: iSCSI daemon with pid=2387 started!
[    4.747529] scsi0 : iSCSI Initiator over TCP/IP
[    4.751948]  connection1:0: detected conn error (1020)
iscsiadm: Could not login to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260].
iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
Jan 12 03:21:14 g-pvops iscsid: conn 0 login rejected: initiator failed authorization with target
Jan 12 03:21:14 g-pvops iscsid: Connection1:0 to [target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260] through [iface: default] is shutdown.

poweroff
  No matching physical volumes found
  No volume groups found
Jan 12 03:21:18 g-pvops init: starting pid 2466, tty '/dev/tty2': '/bin/sh'
Jan 12 03:21:18 g-pvops init: starting pid 2469, tty '/dev/tty1': '/bin/sh'
Jan 12 03:21:18 g-pvops init: starting pid 2470, tty '/dev/ttyS0': '/bin/sh'
Jan 12 03:21:18 g-pvops init: starting pid 2471, tty '/dev/hvc0': '/bin/sh'

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.9 |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2001-2010  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2012-01-11 18:23) 
sh-4.1# 
sh-4.1# poweroff
(*) Direct/Memcpy: Using Generic 64bit memcpy()
Jan 12 03:21:18 g-pvops init: starting pid 2477, tty '': '/etc/init.d/halt'
sh-4.1# Usage: /etc/init.d/halt {start}
The system is going down NOW!
Sent SIGTERM to all processes
(!) [ 2465:    0.000] --> Caught signal 15 (sent by pid 1, uid 0) <--
(!) [ 2465:    0.000] --> Caught signal 11 (at 0x38, invalid address) <--
Sent SIGKILL to all processes
Requesting system poweroff
[   12.086915] System halted.
Parsing config file /mnt/lab/tst018/pv.xm
Daemon running with PID 3972

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 20:07:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 20: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 1Rl4RV-0005dX-Fb; Wed, 11 Jan 2012 20:06:41 +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 1Rl4RU-0005dS-Ad
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 20:06:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326312391!10529100!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4NjQ0OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23690 invoked from network); 11 Jan 2012 20:06:32 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 11 Jan 2012 20:06:32 -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
	q0BK6Pgf030215
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 11 Jan 2012 20:06:26 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
	q0BK6OOu002190
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 11 Jan 2012 20:06:24 GMT
Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0BK6NU3017632; Wed, 11 Jan 2012 14:06:23 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 11 Jan 2012 12:06:22 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 985C340101; Wed, 11 Jan 2012 15:04:35 -0500 (EST)
Date: Wed, 11 Jan 2012 15:04:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tejun Heo <tj@kernel.org>
Message-ID: <20120111200435.GA8680@phenom.dumpdata.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
	<20120110224537.GA6572@phenom.dumpdata.com>
	<20120110231552.GB26832@google.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120110231552.GB26832@google.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.4F0DEBC3.0015,ss=1,re=-2.300,fgs=0
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 10, 2012 at 03:15:52PM -0800, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 10, 2012 at 05:45:37PM -0500, Konrad Rzeszutek Wilk wrote:
> > (early) [    0.000000] memblock_find: [0x0, 0xfcdd000) size=8409088 align=4096 nid=1024
> > (early) [    0.000000] memblock_find: [0x805000, 0xfcdd000) - adjusted
> > (early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0xfcdd000, 0xfcdd000) (early) - rejected
> > (early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x1e03000, 0x220a000) (early) - rejected
> > (early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x805000, 0x1000000) (early) - rejected
> > (early) [    0.000000] memblock_find: cand [0x10000, 0x9b000) -> (early) [0x805000, 0x805000) (early) - rejected
> > (early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
> 
> So, it actually is a legitimate alloc failure.  It seems I've tried a
> bit too hard at simplifying the allocator.  Does the following fix the
> problem?
> 
> Thanks.
> 
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 2f55f19..77b5f22 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -106,14 +106,17 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
>  	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
>  		end = memblock.current_limit;
>  
> -	/* adjust @start to avoid underflow and allocating the first page */
> -	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
> +	/* avoid allocating the first page */
> +	start = max_t(phys_addr_t, start, PAGE_SIZE);
>  	end = max(start, end);
>  
>  	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
>  		this_start = clamp(this_start, start, end);
>  		this_end = clamp(this_end, start, end);
>  
> +		if (this_end < size)
> +			continue;
> +
>  		cand = round_down(this_end - size, align);
>  		if (cand >= this_start)
>  			return cand;

With that patch it boots!


(early) [    0.000000] Initializing cgroup subsys cpuset
(early) [    0.000000] Initializing cgroup subsys cpu
(early) [    0.000000] Linux version 3.2.0-05693-g2c81411 (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP PREEMPT Wed Jan 11 13:19:30 EST 2012
(early) [    0.000000] Command line: console=hvc0 debug earlyprintk=xen
(early) [    0.000000] ACPI in unprivileged domain disabled
(early) [    0.000000] Released 0 pages of unused memory
(early) [    0.000000] Set 0 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 - 0000000200800000 (usable)
(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] e820 update range: 0000000000000000 - 0000000000010000 (early) (usable)(early)  ==> (early) (reserved)(early) 
(early) [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (early) (usable)(early) 
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] last_pfn = 0x200800 max_arch_pfn = 0x400000000
(early) [    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
(early) [    0.000000] initial memory mapped : 0 - 10006000
(early) [    0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480
(early) [    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
(early) [    0.000000]  0000000000 - 0100000000 page 4k
(early) [    0.000000] kernel direct mapping tables up to 100000000 @ 7fb000-1000000
(early) [    0.000000] xen: setting RW the range f74000 - 1000000
(early) [    0.000000] init_memory_mapping: 0000000100000000-0000000200800000
(early) [    0.000000]  0100000000 - 0200800000 page 4k
(early) [    0.000000] kernel direct mapping tables up to 200800000 @ feff2000-100000000
(early) [    0.000000] xen: setting RW the range ff7fb000 - 100000000
(early) [    0.000000] RAMDISK: 02249000 - 10006000
(early) [    0.000000] No NUMA configuration found
(early) [    0.000000] Faking a node at 0000000000000000-0000000200800000
(early) [    0.000000] Initmem setup node 0 0000000000000000-0000000200800000
(early) [    0.000000]   NODE_DATA [00000000fffd9000 - 00000000ffffffff]
(early) [    0.000000] Zone PFN ranges:
(early) [    0.000000]   DMA      (early) 0x00000010 -> 0x00001000
(early) [    0.000000]   DMA32    (early) 0x00001000 -> 0x00100000
(early) [    0.000000]   Normal   (early) 0x00100000 -> 0x00200800
(early) [    0.000000] Movable zone start PFN for each node
(early) [    0.000000] Early memory PFN ranges
(early) [    0.000000]     0: 0x00000010 -> 0x000000a0
(early) [    0.000000]     0: 0x00000100 -> 0x00200800
(early) [    0.000000] On node 0 totalpages: 2099088
(early) [    0.000000]   DMA zone: 64 pages used for memmap
(early) [    0.000000]   DMA zone: 1918 pages reserved
(early) [    0.000000]   DMA zone: 2002 pages, LIFO batch:0
(early) [    0.000000]   DMA32 zone: 16320 pages used for memmap
(early) [    0.000000]   DMA32 zone: 1028160 pages, LIFO batch:31
(early) [    0.000000]   Normal zone: 16416 pages used for memmap
(early) [    0.000000]   Normal zone: 1034208 pages, LIFO batch:31
(early) [    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
(early) [    0.000000] No local APIC present
(early) [    0.000000] APIC: disable apic facility
(early) [    0.000000] APIC: switched to apic NOOP
(early) [    0.000000] nr_irqs_gsi: 16
(early) [    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
(early) [    0.000000] PCI: Warning: Cannot find a gap in the 32bit address range
(early) [    0.000000] PCI: Unassigned devices with 32bit resource registers may break!
(early) [    0.000000] Allocating PCI resources starting at 200900000 (gap: 200900000:400000)
(early) [    0.000000] Booting paravirtualized kernel on Xen
(early) [    0.000000] Xen version: 4.1-120111 (preserve-AD)
(early) [    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
(early) [    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8800fff31000 s82752 r8192 d23744 u114688
(early) [    0.000000] pcpu-alloc: s82752 r8192 d23744 u114688 alloc=28*4096(early) 
(early) [    0.000000] pcpu-alloc: (early) [0] (early) 0 (early) [0] (early) 1 (early) [0] (early) 2 (early) [0] (early) 3 (early) 
(early) [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2064370
(early) [    0.000000] Policy zone: Normal
(early) [    0.000000] Kernel command line: console=hvc0 debug earlyprintk=xen
(early) [    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
(early) [    0.000000] Checking aperture...
(early) [    0.000000] No AGP bridge found
(early) [    0.000000] Calgary: detecting Calgary via BIOS EBDA area
(early) [    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
(early) [    0.000000] Memory: 3727344k/8396800k available (6482k kernel code, 448k absent, 4669008k reserved, 4624k data, 1256k init)
(early) [    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
(early) [    0.000000] Preemptible hierarchical RCU implementation.
(early) [    0.000000] NR_IRQS:262400 nr_irqs:304 16
(early) [    0.000000] kmemleak: Early log buffer exceeded, please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE
(early) [    0.000000] kmemleak: Kernel memory leak detector disabled
(early) [    0.000000] Console: colour dummy device 80x25
(early) [    0.000000] console [tty0] enabled
[    0.000000] console [hvc0] enabled, bootconsole disabled
(early) [    0.000000] console [hvc0] enabled, bootconsole disabled
[    0.000000] Xen: using vcpuop timer interface
[    0.000000] installing Xen timer for CPU 0
[    0.000000] Detected 3292.616 MHz processor.
[    0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 6585.23 BogoMIPS (lpj=3292616)
[    0.000999] pid_max: default: 32768 minimum: 301
[    0.000999] Security Framework initialized
[    0.000999] SELinux:  Initializing.
[    0.000999] SELinux:  Starting in permissive mode
[    0.002170] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[    0.004675] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.005213] Mount-cache hash table entries: 256
[    0.005428] Initializing cgroup subsys cpuacct
[    0.005436] Initializing cgroup subsys freezer
[    0.005497] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[    0.005498] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
[    0.005510] CPU: Physical Processor ID: 0
[    0.005515] CPU: Processor Core ID: 0
[    0.005576] SMP alternatives: switching to UP code
[    0.005999] ftrace: allocating 23453 entries in 92 pages
[    0.006057] cpu 0 spinlock event irq 17
[    0.006112] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only.
[    0.012038] NMI watchdog disabled (cpu0): hardware events not enabled
[    0.018010] installing Xen timer for CPU 1
[    0.018028] cpu 1 spinlock event irq 23
[    0.018051] SMP alternatives: switching to SMP code
[    0.019085] NMI watchdog disabled (cpu1): hardware events not enabled
[    0.025009] installing Xen timer for CPU 2
[    0.025027] cpu 2 spinlock event irq 29
[    0.025121] NMI watchdog disabled (cpu2): hardware events not enabled
[    0.031008] installing Xen timer for CPU 3
[    0.031024] cpu 3 spinlock event irq 35
[    0.031118] NMI watchdog disabled (cpu3): hardware events not enabled
[    0.033006] Brought up 4 CPUs
[    0.033666] kworker/u:0 used greatest stack depth: 5272 bytes left
[    0.033666] Grant tables using version 2 layout.
[    0.033666] Grant table initialized
[    0.052849] RTC time: 165:165:165, date: 165/165/65
[    0.053033] NET: Registered protocol family 16
[    0.054556] PCI: setting up Xen PCI frontend stub
[    0.054565] PCI: pci_cache_line_size set to 64 bytes
[    0.065198] bio: create slab <bio-0> at 0
[    0.065198] ACPI: Interpreter disabled.
[    0.066004] xen/balloon: Initialising balloon driver.
[    0.076187] xen-balloon: Initialising balloon driver.
[    0.076187] vgaarb: loaded
[    0.077064] usbcore: registered new interface driver usbfs
[    0.077067] usbcore: registered new interface driver hub
[    0.077107] usbcore: registered new device driver usb
[    0.077107] PCI: System does not support PCI
[    0.077107] PCI: System does not support PCI
[    0.078054] NetLabel: Initializing
[    0.078054] NetLabel:  domain hash size = 128
[    0.078054] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.078054] NetLabel:  unlabeled traffic allowed by default
[    0.078109] Switching to clocksource xen
[    0.083574] pnp: PnP ACPI: disabled
[    0.089832] PCI: max bus depth: 0 pci_try_num: 1
[    0.089877] NET: Registered protocol family 2
[    0.090665] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.093957] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.095324] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.095466] TCP: Hash tables configured (established 524288 bind 65536)
[    0.095474] TCP reno registered
[    0.095526] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[    0.095597] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[    0.095720] NET: Registered protocol family 1
[    0.095957] RPC: Registered named UNIX socket transport module.
[    0.095965] RPC: Registered udp transport module.
[    0.095970] RPC: Registered tcp transport module.
[    0.095976] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.095984] PCI: CLS 0 bytes, default 64
[    0.096219] Trying to unpack rootfs image as initramfs...
[    0.431565] Freeing initrd memory: 227060k freed
[    0.475737] DMA-API: preallocated 32768 debug entries
[    0.475961] DMA-API: debugging enabled by kernel config
[    0.475969] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.475977] Placing 64MB software IO TLB between ffff8800f2800000 - ffff8800f6800000
[    0.475984] software IO TLB at phys 0xf2800000 - 0xf6800000
[    0.476324] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    0.476472] Machine check injector initialized
[    0.477452] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x17
[    0.477466] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x17
[    0.477486] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x17
[    0.477503] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x17
[    0.477586] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    0.478032] audit: initializing netlink socket (disabled)
[    0.478053] type=2000 audit(1326338469.110:1): initialized
[    0.494006] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    0.499995] VFS: Disk quotas dquot_6.5.2
[    0.500208] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.501045] NTFS driver 2.1.30 [Flags: R/W].
[    0.501365] msgmni has been set to 7723
[    0.501583] SELinux:  Registering netfilter hooks
[    0.502294] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.502303] io scheduler noop registered
[    0.502309] io scheduler deadline registered
[    0.502405] io scheduler cfq registered (default)
[    0.502633] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.542586] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.573641] Non-volatile memory driver v1.3
[    0.573649] Linux agpgart interface v0.103
[    0.574083] [drm] Initialized drm 1.1.0 20060810
[    0.577049] brd: module loaded
[    0.578684] loop: module loaded
[    0.579544] Fixed MDIO Bus: probed
[    0.579551] tun: Universal TUN/TAP device driver, 1.6
[    0.579556] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    0.580300] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.580308] ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96
[    0.580386] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.580392] ohci_hcd: block sizes: ed 80 td 96
[    0.580466] uhci_hcd: USB Universal Host Controller Interface driver
[    0.580701] usbcore: registered new interface driver usblp
[    0.580780] usbcore: registered new interface driver libusual
[    0.581039] i8042: PNP: No PS/2 controller found. Probing ports directly.
[    0.581865] i8042: No controller found
[    0.581951] mousedev: PS/2 mouse device common for all mice
[    0.622367] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    0.622469] rtc_cmos: probe of rtc_cmos failed with error -38
[    0.622730] EFI Variables Facility v0.08 2004-May-17
[    0.622805] zram: num_devices not specified. Using default: 1
[    0.622812] zram: Creating 1 devices ...
[    0.623448] Netfilter messages via NETLINK v0.30.
[    0.623467] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[    0.623780] ctnetlink v0.93: registering with nfnetlink.
[    0.625065] ip_tables: (C) 2000-2006 Netfilter Core Team
[    0.625099] TCP cubic registered
[    0.625105] Initializing XFRM netlink socket
[    0.625468] NET: Registered protocol family 10
[    0.627394] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    0.627485] IPv6 over IPv4 tunneling driver
[    0.629062] NET: Registered protocol family 17
[    0.629097] Registering the dns_resolver key type
[    0.629362] PM: Hibernation image not present or could not be loaded.
[    0.629386] registered taskstats version 1
[    0.629448] XENBUS: Device with no driver: device/vif/0
[    0.629454] XENBUS: Device with no driver: device/vfb/0
[    0.629460] XENBUS: Device with no driver: device/vkbd/0
[    0.629475]   Magic number: 1:252:3141
[    0.630415] Freeing unused kernel memory: 1256k freed
[    0.630622] Write protecting the kernel read-only data: 10240k
[    0.636139] Freeing unused kernel memory: 1688k freed
[    0.636508] Freeing unused kernel memory: 112k freed
init started: BusyBox v1.14.3 (2012-01-11 13:22:11 EST)
[    0.641820] consoletype used greatest stack depth: 5232 bytes left
Mounting directories  [  OK  ]
[    0.860513] modprobe used greatest stack depth: 5008 bytes left
mount: mount point /sys/kernel/config does not exist
[    0.865846] core_filesystem used greatest stack depth: 4880 bytes left
[    0.874814] input: Xen Virtual Keyboard as /devices/virtual/input/input0
[    0.875019] input: Xen Virtual Pointer as /devices/virtual/input/input1
[    1.086237] Initialising Xen virtual ethernet driver.
[    1.201417] udevd (1186): /proc/1186/oom_adj is deprecated, please use /proc/1186/oom_score_adj instead.
udevd-work[1202]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory

[    1.307448] ip used greatest stack depth: 3696 bytes left
Waiting for devices [  OK  ]
Waiting for fb [  OK  ]
Starting..[/dev/fb0]
/dev/fb0: len:0
/dev/fb0: bits/pixel32
(7fa51499a000): Writting .. [800:600]
Done!
FATAL: Module agpgart_intel not found.
[    1.464693] Console: switching to colour frame buffer device 100x37
[    1.478942] [drm] radeon kernel modesetting enabled.
WARNING: Error inserting video (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/acpi/video.ko): No such device
WARNING: Error inserting mxm_wmi (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/platform/x86/mxm-wmi.ko): No such device
WARNING: Error inserting drm_kms_helper (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
WARNING: Error inserting ttm (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/ttm/ttm.ko): No such device
FATAL: Error inserting nouveau (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/nouveau/nouveau.ko): No such device
WARNING: Error inserting drm_kms_helper (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
FATAL: Error inserting i915 (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/i915/i915.ko): No such device
Starting..[/dev/fb0]
/dev/fb0: len:0
/dev/fb0: bits/pixel32
(7fc2635c3000): Writting .. [800:600]
Done!
VGA: 0000:
Waiting for network [  OK  ]
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:  [    1.743980] device eth0 entered promiscuous mode
[  OK  ]
Bringing up interface switch:  
Determining IP information for switch...[    1.790208] switch: port 1(eth0) entering forwarding state
[    1.790244] switch: port 1(eth0) entering forwarding state
[    1.790880] ip used greatest stack depth: 3376 bytes left
 done.
[  OK  ]
Waiting for init.custom [  OK  ]

Starting SSHd ...

    SSH started [2314]


Waiting for SSHd [  OK  ]
WARNING: ssh currently running [2314] ignoring start request
FATAL: Module dump_dma not found.
ERROR: Module dump_dma does not exist in /proc/modules
[    3.562254] SCSI subsystem initialized
[    3.563911] Loading iSCSI transport class v2.0-870.
[    3.566452] iscsi: registered transport (tcp)
iscsistart: transport class version 2.0-870. iscsid version 2.0-872
Could not get list of targets from firmware.
Jan 12 03:21:12 g-pvops syslogd 1.5.0: restart.
FATAL: Module evtchn not found.
[    3.595640] Event-channel device installed.
xencommons should be started first.
           CPU0       CPU1       CPU2       CPU3       
 16:       1330          0          0          0  xen-percpu-virq      timer0
 17:          6          0          0          0  xen-percpu-ipi       spinlock0
 18:       1872          0          0          0  xen-percpu-ipi       resched0
 19:        129          0          0          0  xen-percpu-ipi       callfunc0
 20:          0          0          0          0  xen-percpu-virq      debug0
 21:         77          0          0          0  xen-percpu-ipi       callfuncsingle0
 22:          0       1811          0          0  xen-percpu-virq      timer1
 23:          0         14          0          0  xen-percpu-ipi       spinlock1
 24:          0       2411          0          0  xen-percpu-ipi       resched1
 25:          0        140          0          0  xen-percpu-ipi       callfunc1
 26:          0          0          0          0  xen-percpu-virq      debug1
 27:          0         78          0          0  xen-percpu-ipi       callfuncsingle1
 28:          0          0       1204          0  xen-percpu-virq      timer2
 29:          0          0          5          0  xen-percpu-ipi       spinlock2
 30:          0          0       3713          0  xen-percpu-ipi       resched2
 31:          0          0        148          0  xen-percpu-ipi       callfunc2
 32:          0          0          0          0  xen-percpu-virq      debug2
 33:          0          0        103          0  xen-percpu-ipi       callfuncsingle2
 34:          0          0          0       1373  xen-percpu-virq      timer3
 35:          0          0          0          5  xen-percpu-ipi       spinlock3
 36:          0          0          0       2474  xen-percpu-ipi       resched3
 37:          0          0          0        131  xen-percpu-ipi       callfunc3
 38:          0          0          0          0  xen-percpu-virq      debug3
 39:          0          0          0         88  xen-percpu-ipi       callfuncsingle3
 40:        423          0          0          0   xen-dyn-event     xenbus
 41:         81          0          0          0   xen-dyn-event     hvc_console
 42:          0          0          0          0   xen-dyn-event     vkbd
 43:         70          0          0          0   xen-dyn-event     vfb
 44:         20          0          0          0   xen-dyn-event     eth0
NMI:          0          0          0          0   Non-maskable interrupts
LOC:          0          0          0          0   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RTR:          0          0          0          0   APIC ICR read retries
RES:       1872       2411       3713       2474   Rescheduling interrupts
CAL:        206        218        251        219   Function call interrupts
TLB:          0          0          0          0   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:          0          0          0          0   Machine check polls
ERR:          0
MIS:          0
00000000-0000ffff : reserved
00010000-0009ffff : System RAM
000a0000-000fffff : reserved
  000f0000-000fffff : System ROM
00100000-2007fffff : System RAM
  01000000-016549db : Kernel code
  016549dc-01ad89ff : Kernel data
  01c1a000-01e2afff : Kernel bss
Waiting for init.late [  OK  ]
PING build.dumpdata.com (192.168.101.3) 56(84) bytes of data.

--- build.dumpdata.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.329/0.329/0.329/0.000 ms
NFS done
 [0x0->0x100000] pfn
 [0x0->0x100000] level entry
 [0x100000->0x7cfffff] missing
 [0x100000->0x7cfffff] level top
libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running?
failed to stat /var/run/xenstored.pid: No such file or directory
cannot init xl context
[    4.481012] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
[    4.482152] device-mapper: multipath: version 1.3.0 loaded
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260]
Jan 12 03:21:13 g-pvops iscsid: transport class version 2.0-870. iscsid version 2.0-872
Jan 12 03:21:13 g-pvops iscsid: iSCSI daemon with pid=2387 started!
[    4.747529] scsi0 : iSCSI Initiator over TCP/IP
[    4.751948]  connection1:0: detected conn error (1020)
iscsiadm: Could not login to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260].
iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
Jan 12 03:21:14 g-pvops iscsid: conn 0 login rejected: initiator failed authorization with target
Jan 12 03:21:14 g-pvops iscsid: Connection1:0 to [target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260] through [iface: default] is shutdown.

poweroff
  No matching physical volumes found
  No volume groups found
Jan 12 03:21:18 g-pvops init: starting pid 2466, tty '/dev/tty2': '/bin/sh'
Jan 12 03:21:18 g-pvops init: starting pid 2469, tty '/dev/tty1': '/bin/sh'
Jan 12 03:21:18 g-pvops init: starting pid 2470, tty '/dev/ttyS0': '/bin/sh'
Jan 12 03:21:18 g-pvops init: starting pid 2471, tty '/dev/hvc0': '/bin/sh'

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.9 |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2001-2010  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2012-01-11 18:23) 
sh-4.1# 
sh-4.1# poweroff
(*) Direct/Memcpy: Using Generic 64bit memcpy()
Jan 12 03:21:18 g-pvops init: starting pid 2477, tty '': '/etc/init.d/halt'
sh-4.1# Usage: /etc/init.d/halt {start}
The system is going down NOW!
Sent SIGTERM to all processes
(!) [ 2465:    0.000] --> Caught signal 15 (sent by pid 1, uid 0) <--
(!) [ 2465:    0.000] --> Caught signal 11 (at 0x38, invalid address) <--
Sent SIGKILL to all processes
Requesting system poweroff
[   12.086915] System halted.
Parsing config file /mnt/lab/tst018/pv.xm
Daemon running with PID 3972

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 21:31:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 21: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 1Rl5k0-0000WL-Ne; Wed, 11 Jan 2012 21:29:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1Rl5jy-0000WG-US
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 21:29:51 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326317350!48015218!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18178 invoked from network); 11 Jan 2012 21:29:12 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 21:29:12 -0000
Received: from saboo.goop.org (114-198-82-92.dyn.iinet.net.au [114.198.82.92])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 9D04E95C3;
	Wed, 11 Jan 2012 13:29:43 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 912E920A67;
	Thu, 12 Jan 2012 08:29:29 +1100 (EST)
Message-ID: <4F0DFF39.8090103@goop.org>
Date: Thu, 12 Jan 2012 08:29:29 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
In-Reply-To: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
X-Enigmail-Version: 1.3.4
Cc: Xen Devel <Xen-devel@lists.xensource.com>, linux-next@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: manual merge of the xen tree with
	Linus' 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 01/11/2012 02:57 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/xen/Kconfig between commit 10fe570fc167 ("Revert "xen/debug:
> WARN_ON when identity PFN has no _PAGE_IOMAP flag set."") from Linus'
> tree and commit 23757fb5d678 ("xen: add CPU microcode update driver")
> from the xen tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.

Do you know which branch this is coming from?  Are you by some chance
still (or again) pulling from my "git://github.com/jsgf/linux-xen.git
upstream/xen" repo, which contains a number of obsolete changes,
including the microcode stuff (now removed)?

I just created a new (empty)
"git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
upstream/linux-next" branch; could you make sure that replaces any other
branch you have from either kernel.org xen.git or github.com/jsgf/linux-xen?

Thanks,
    J


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 21:31:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 21: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 1Rl5k0-0000WL-Ne; Wed, 11 Jan 2012 21:29:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1Rl5jy-0000WG-US
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 21:29:51 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326317350!48015218!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18178 invoked from network); 11 Jan 2012 21:29:12 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 21:29:12 -0000
Received: from saboo.goop.org (114-198-82-92.dyn.iinet.net.au [114.198.82.92])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 9D04E95C3;
	Wed, 11 Jan 2012 13:29:43 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 912E920A67;
	Thu, 12 Jan 2012 08:29:29 +1100 (EST)
Message-ID: <4F0DFF39.8090103@goop.org>
Date: Thu, 12 Jan 2012 08:29:29 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
In-Reply-To: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
X-Enigmail-Version: 1.3.4
Cc: Xen Devel <Xen-devel@lists.xensource.com>, linux-next@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: manual merge of the xen tree with
	Linus' 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 01/11/2012 02:57 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/xen/Kconfig between commit 10fe570fc167 ("Revert "xen/debug:
> WARN_ON when identity PFN has no _PAGE_IOMAP flag set."") from Linus'
> tree and commit 23757fb5d678 ("xen: add CPU microcode update driver")
> from the xen tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.

Do you know which branch this is coming from?  Are you by some chance
still (or again) pulling from my "git://github.com/jsgf/linux-xen.git
upstream/xen" repo, which contains a number of obsolete changes,
including the microcode stuff (now removed)?

I just created a new (empty)
"git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
upstream/linux-next" branch; could you make sure that replaces any other
branch you have from either kernel.org xen.git or github.com/jsgf/linux-xen?

Thanks,
    J


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 21:35:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 21:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl5oH-0000iL-Oc; Wed, 11 Jan 2012 21:34:17 +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 1Rl5oG-0000iB-UT
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 21:34:17 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326317647!8759510!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 32555 invoked from network); 11 Jan 2012 21:34:10 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Jan 2012 21:34:10 -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 1Rl5o4-0007eQ-Fk; Thu, 12 Jan 2012 08:34:04 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 12 Jan 2012 08:34:04 +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;
	Thu, 12 Jan 2012 08:34:03 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH v5 00/25] xen: ARMv7 with virtualization
	extensions
Thread-Index: AQHM0H2ARTlegmGoV02fQk5feWVtlZYHr+3g
Date: Wed, 11 Jan 2012 21:34:02 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0A2720@BITCOM1.int.sbss.com.au>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Jan 2012 21:34:04.0276 (UTC)
	FILETIME=[BDB54B40:01CCD0A8]
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] [PATCH v5 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

Are any of the free ARM emulators capable of emulating an ARMv7 platform?

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 21:35:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 21:35:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rl5oH-0000iL-Oc; Wed, 11 Jan 2012 21:34:17 +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 1Rl5oG-0000iB-UT
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 21:34:17 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326317647!8759510!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 32555 invoked from network); 11 Jan 2012 21:34:10 -0000
Received: from mail.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-7.tower-174.messagelabs.com with AES256-SHA encrypted SMTP;
	11 Jan 2012 21:34:10 -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 1Rl5o4-0007eQ-Fk; Thu, 12 Jan 2012 08:34:04 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 12 Jan 2012 08:34:04 +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;
	Thu, 12 Jan 2012 08:34:03 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] [PATCH v5 00/25] xen: ARMv7 with virtualization
	extensions
Thread-Index: AQHM0H2ARTlegmGoV02fQk5feWVtlZYHr+3g
Date: Wed, 11 Jan 2012 21:34:02 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0A2720@BITCOM1.int.sbss.com.au>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 11 Jan 2012 21:34:04.0276 (UTC)
	FILETIME=[BDB54B40:01CCD0A8]
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] [PATCH v5 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

Are any of the free ARM emulators capable of emulating an ARMv7 platform?

Thanks

James


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 21:45:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 21: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 1Rl5yJ-0000vm-T8; Wed, 11 Jan 2012 21:44:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1Rl5yH-0000vh-Vw
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 21:44:38 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326318270!7415857!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15862 invoked from network); 11 Jan 2012 21:44:31 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 21:44:31 -0000
Received: from saboo.goop.org (114-198-82-92.dyn.iinet.net.au [114.198.82.92])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 03C7895EA;
	Wed, 11 Jan 2012 13:44:29 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 020B520FBA;
	Thu, 12 Jan 2012 08:44:18 +1100 (EST)
Message-ID: <4F0E02B2.7010908@goop.org>
Date: Thu, 12 Jan 2012 08:44:18 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
	<4F0DFF39.8090103@goop.org>
In-Reply-To: <4F0DFF39.8090103@goop.org>
X-Enigmail-Version: 1.3.4
Cc: Xen Devel <Xen-devel@lists.xensource.com>, linux-next@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: manual merge of the xen tree with
	Linus' 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 01/12/2012 08:29 AM, Jeremy Fitzhardinge wrote:
> Are you by some chance still (or again) pulling from my
> "git://github.com/jsgf/linux-xen.git upstream/xen" repo, which
> contains a number of obsolete changes...

Which looks like my mistake, because I don't think I had asked you to
switch back to git.kernel.org.

Thanks,
    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 21:45:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 21: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 1Rl5yJ-0000vm-T8; Wed, 11 Jan 2012 21:44:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1Rl5yH-0000vh-Vw
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 21:44:38 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326318270!7415857!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15862 invoked from network); 11 Jan 2012 21:44:31 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 11 Jan 2012 21:44:31 -0000
Received: from saboo.goop.org (114-198-82-92.dyn.iinet.net.au [114.198.82.92])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 03C7895EA;
	Wed, 11 Jan 2012 13:44:29 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 020B520FBA;
	Thu, 12 Jan 2012 08:44:18 +1100 (EST)
Message-ID: <4F0E02B2.7010908@goop.org>
Date: Thu, 12 Jan 2012 08:44:18 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stephen Rothwell <sfr@canb.auug.org.au>
References: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
	<4F0DFF39.8090103@goop.org>
In-Reply-To: <4F0DFF39.8090103@goop.org>
X-Enigmail-Version: 1.3.4
Cc: Xen Devel <Xen-devel@lists.xensource.com>, linux-next@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: manual merge of the xen tree with
	Linus' 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 01/12/2012 08:29 AM, Jeremy Fitzhardinge wrote:
> Are you by some chance still (or again) pulling from my
> "git://github.com/jsgf/linux-xen.git upstream/xen" repo, which
> contains a number of obsolete changes...

Which looks like my mistake, because I don't think I had asked you to
switch back to git.kernel.org.

Thanks,
    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 11 22:46:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 22: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 1Rl6vE-0001Ix-MQ; Wed, 11 Jan 2012 22:45:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1Rl6vC-0001Is-SH
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 22:45:31 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326321923!9995789!1
X-Originating-IP: [203.10.76.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10419 invoked from network); 11 Jan 2012 22:45:23 -0000
Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15)
	by server-13.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 22:45:23 -0000
Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by calzone.tip.net.au (Postfix) with ESMTPSA id 4A486128620;
	Thu, 12 Jan 2012 09:45:18 +1100 (EST)
Date: Thu, 12 Jan 2012 09:45:12 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-Id: <20120112094512.51c8ced573da371780da0b26@canb.auug.org.au>
In-Reply-To: <4F0E02B2.7010908@goop.org>
References: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
	<4F0DFF39.8090103@goop.org> <4F0E02B2.7010908@goop.org>
X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.8; i486-pc-linux-gnu)
Mime-Version: 1.0
Cc: Xen Devel <Xen-devel@lists.xensource.com>, linux-next@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: manual merge of the xen tree with
	Linus' 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: multipart/mixed; boundary="===============2338244804837264897=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2338244804837264897==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="PGP-SHA256";
 boundary="Signature=_Thu__12_Jan_2012_09_45_12_+1100_Le9EI3tlalrxcjDL"

--Signature=_Thu__12_Jan_2012_09_45_12_+1100_Le9EI3tlalrxcjDL
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

On Thu, 12 Jan 2012 08:44:18 +1100 Jeremy Fitzhardinge <jeremy@goop.org> wr=
ote:
>
> On 01/12/2012 08:29 AM, Jeremy Fitzhardinge wrote:
> > Are you by some chance still (or again) pulling from my
> > "git://github.com/jsgf/linux-xen.git upstream/xen" repo, which
> > contains a number of obsolete changes...
>=20
> Which looks like my mistake, because I don't think I had asked you to
> switch back to git.kernel.org.

OK, I will switch back to kernel.org today.

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

--Signature=_Thu__12_Jan_2012_09_45_12_+1100_Le9EI3tlalrxcjDL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPDhD4AAoJEECxmPOUX5FEcfUP/038+64uRiHuVPki4HBREdZZ
wbYYNvcoa3y6VQ9VUNOoJvWb0z0Tu0/HxCgk49gdSz/iX4HiSem43FUPIkY17UUv
15j7jUNce4oWI4kFgIQR76rPTCdloIAr+ir5qiZoVTQv1CFRZ7TBmeU0YQ8ESTLd
/Ro9EYXMuUTi+fgjKgktFgsl7TPq01U6Z9OAN8c6KlZr37Fj0JJ4BcWy5LMyzbcL
Up7dUnIB1R1PfJ9pjNQ31gZbghRUho40e3xDuhDPN/agmTR4kaDWiYUe6lvN22hA
5TNIxJd7MHyFkT0G3rDIlLnQ84IBSQWAXfkaE8peTFqa5tgIEqxppWCVD+feHX6M
NWJIv2njaVO3i4txpFZPDFBhWx0Gq3U6fpY7hgXkf4niJAGFiMwkbIoF8nTZrVw0
Pv1DUcIHGcnEGfZ7ef/Af4f8X3Cu5608SiRAmuRDpYb6XcgAwvFhBzeKBnfQaCI8
86xbiiwVCRk0CAi2F28S2kynFUZaEa9CuPt8kV3Mp4gsV2P4Tix+Ki60ygge/o+C
VySNT/8d+dgY229VBLdRKI1hytbd980AZdgAWvReynIzIbD8wEZru5y3Kr3PY/Ah
FQG1nPoaAiLivPSpNONr03h+4B5SFZzQ5YSU65CJsMD1prXYGFOilrOGgGR+c8mm
mvTbMAAlI4QPL1E69+k3
=qpz7
-----END PGP SIGNATURE-----

--Signature=_Thu__12_Jan_2012_09_45_12_+1100_Le9EI3tlalrxcjDL--


--===============2338244804837264897==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2338244804837264897==--


From xen-devel-bounces@lists.xensource.com Wed Jan 11 22:46:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 11 Jan 2012 22: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 1Rl6vE-0001Ix-MQ; Wed, 11 Jan 2012 22:45:32 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <sfr@canb.auug.org.au>) id 1Rl6vC-0001Is-SH
	for Xen-devel@lists.xensource.com; Wed, 11 Jan 2012 22:45:31 +0000
X-Env-Sender: sfr@canb.auug.org.au
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326321923!9995789!1
X-Originating-IP: [203.10.76.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10419 invoked from network); 11 Jan 2012 22:45:23 -0000
Received: from calzone.tip.net.au (HELO calzone.tip.net.au) (203.10.76.15)
	by server-13.tower-182.messagelabs.com with SMTP;
	11 Jan 2012 22:45:23 -0000
Received: from canb.auug.org.au (ibmaus65.lnk.telstra.net [165.228.126.9])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by calzone.tip.net.au (Postfix) with ESMTPSA id 4A486128620;
	Thu, 12 Jan 2012 09:45:18 +1100 (EST)
Date: Thu, 12 Jan 2012 09:45:12 +1100
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-Id: <20120112094512.51c8ced573da371780da0b26@canb.auug.org.au>
In-Reply-To: <4F0E02B2.7010908@goop.org>
References: <20120111145709.77ef7d68996cd5fa724326e5@canb.auug.org.au>
	<4F0DFF39.8090103@goop.org> <4F0E02B2.7010908@goop.org>
X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.8; i486-pc-linux-gnu)
Mime-Version: 1.0
Cc: Xen Devel <Xen-devel@lists.xensource.com>, linux-next@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux-next: manual merge of the xen tree with
	Linus' 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: multipart/mixed; boundary="===============2338244804837264897=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2338244804837264897==
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="PGP-SHA256";
 boundary="Signature=_Thu__12_Jan_2012_09_45_12_+1100_Le9EI3tlalrxcjDL"

--Signature=_Thu__12_Jan_2012_09_45_12_+1100_Le9EI3tlalrxcjDL
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Jeremy,

On Thu, 12 Jan 2012 08:44:18 +1100 Jeremy Fitzhardinge <jeremy@goop.org> wr=
ote:
>
> On 01/12/2012 08:29 AM, Jeremy Fitzhardinge wrote:
> > Are you by some chance still (or again) pulling from my
> > "git://github.com/jsgf/linux-xen.git upstream/xen" repo, which
> > contains a number of obsolete changes...
>=20
> Which looks like my mistake, because I don't think I had asked you to
> switch back to git.kernel.org.

OK, I will switch back to kernel.org today.

--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

--Signature=_Thu__12_Jan_2012_09_45_12_+1100_Le9EI3tlalrxcjDL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPDhD4AAoJEECxmPOUX5FEcfUP/038+64uRiHuVPki4HBREdZZ
wbYYNvcoa3y6VQ9VUNOoJvWb0z0Tu0/HxCgk49gdSz/iX4HiSem43FUPIkY17UUv
15j7jUNce4oWI4kFgIQR76rPTCdloIAr+ir5qiZoVTQv1CFRZ7TBmeU0YQ8ESTLd
/Ro9EYXMuUTi+fgjKgktFgsl7TPq01U6Z9OAN8c6KlZr37Fj0JJ4BcWy5LMyzbcL
Up7dUnIB1R1PfJ9pjNQ31gZbghRUho40e3xDuhDPN/agmTR4kaDWiYUe6lvN22hA
5TNIxJd7MHyFkT0G3rDIlLnQ84IBSQWAXfkaE8peTFqa5tgIEqxppWCVD+feHX6M
NWJIv2njaVO3i4txpFZPDFBhWx0Gq3U6fpY7hgXkf4niJAGFiMwkbIoF8nTZrVw0
Pv1DUcIHGcnEGfZ7ef/Af4f8X3Cu5608SiRAmuRDpYb6XcgAwvFhBzeKBnfQaCI8
86xbiiwVCRk0CAi2F28S2kynFUZaEa9CuPt8kV3Mp4gsV2P4Tix+Ki60ygge/o+C
VySNT/8d+dgY229VBLdRKI1hytbd980AZdgAWvReynIzIbD8wEZru5y3Kr3PY/Ah
FQG1nPoaAiLivPSpNONr03h+4B5SFZzQ5YSU65CJsMD1prXYGFOilrOGgGR+c8mm
mvTbMAAlI4QPL1E69+k3
=qpz7
-----END PGP SIGNATURE-----

--Signature=_Thu__12_Jan_2012_09_45_12_+1100_Le9EI3tlalrxcjDL--


--===============2338244804837264897==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2338244804837264897==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 02:25:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 02: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 1RlALe-0007SR-9z; Thu, 12 Jan 2012 02:25:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RlALc-0007SM-DK
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 02:25:00 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326335091!7892956!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNzk2NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5461 invoked from network); 12 Jan 2012 02:24:52 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-3.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 02:24:52 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXN002M0YPDQS@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:24:49 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXN002B9YOJT4@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:24:49 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG44164; Thu,
	12 Jan 2012 10:24:34 +0800
Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 12 Jan 2012 10:24:12 +0800
Received: from h00166998 (10.166.80.196) by szxeml424-hub.china.huawei.com
	(10.82.67.163) with Microsoft SMTP Server id 14.1.323.3; Thu,
	12 Jan 2012 10:24:05 +0800
Date: Thu, 12 Jan 2012 10:24:06 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <d3c062de69d4de2a251193814609365c.squirrel@webmail.lagarcavilla.org>
X-Originating-IP: [10.166.80.196]
To: andres@lagarcavilla.org
Message-id: <000001ccd0d1$43bfd750$cb3f85f0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczQcTLbsa/i4JSqTS+b0bHNMz7hNAAXgBew
X-CFilter-Loop: Reflected
References: <patchbomb.1326145285@xdev.gridcentric.ca>
	<f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
	<000a01ccd034$f7037ee0$e50a7ca0$@com>
	<d3c062de69d4de2a251193814609365c.squirrel@webmail.lagarcavilla.org>
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, xen-devel@lists.xensource.com,
	andres@gridcentric.ca, yanqiangjun@huawei.com, tim@xen.org,
	bicky.shi@huawei.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
 p2m_ram_paged_out state to be loaded
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, January 11, 2012 10:57 PM
> To: Hongkaixing
> Cc: xen-devel@lists.xensource.com; andres@gridcentric.ca; tim@xen.org; olaf@aepfle.de; adin@gridcentric.ca;
> yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com
> Subject: RE: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in p2m_ram_paged_out state to be loaded
> 
> I think top-posting is frowned upon. Below...
> >     I think it may have many unpredicted risks.
> >     After p2mt is changed to p2m_ram_rw, Domain guest can access this page
> > unrestrictedly without being trapped in xen.
> >  But at this time, the page is not prepared.
> 
> Nope. The page has already been allocated and paged-in (copy_from_user out
> of user_ptr) by the time the p2mt is changed


I have got it,  first change p2mt to p2m_ram_paging_in, prepare a page, use copy_from_usr to copy, then change p2mt to ram_rw . It
is a good idea.



> Andres
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xensource.com
> >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres
> >> Lagar-Cavilla
> >> Sent: Tuesday, January 10, 2012 5:41 AM
> >> To: xen-devel@lists.xensource.com
> >> Cc: andres@gridcentric.ca; tim@xen.org; olaf@aepfle.de;
> >> adin@gridcentric.ca
> >> Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
> >> p2m_ram_paged_out state to be loaded
> >>
> >>  xen/arch/x86/mm/p2m.c |  15 +++++++++++----
> >>  1 files changed, 11 insertions(+), 4 deletions(-)
> >>
> >>
> >> This removes the need for a page to be accessed in order to be pageable
> >> again. A pager can now page-in pages at will with no need to map them
> >> in a separate thread.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> Acked-by: Tim Deegan <tim@xen.org>
> >>
> >> diff -r 90f764bf02c3 -r f7c330d5b4b5 xen/arch/x86/mm/p2m.c
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -964,7 +964,7 @@ void p2m_mem_paging_populate(struct doma
> >>  int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t
> >> buffer)
> >>  {
> >>      struct page_info *page;
> >> -    p2m_type_t p2mt;
> >> +    p2m_type_t p2mt, target_p2mt;
> >>      p2m_access_t a;
> >>      mfn_t mfn;
> >>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> @@ -982,8 +982,8 @@ int p2m_mem_paging_prep(struct domain *d
> >>      mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
> >>
> >>      ret = -ENOENT;
> >> -    /* Allow only missing pages */
> >> -    if ( p2mt != p2m_ram_paging_in_start )
> >> +    /* Allow missing pages */
> >> +    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
> >>          goto out;
> >>
> >>      /* Allocate a page if the gfn does not have one yet */
> >> @@ -1018,8 +1018,15 @@ int p2m_mem_paging_prep(struct domain *d
> >>          }
> >>      }
> >>
> >> +    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
> >> +        /* If we kicked the pager with a populate event, the pager will
> >> send
> >> +         * a resume event back */
> >> +        p2m_ram_paging_in :
> >> +        /* If this was called asynchronously by the pager, then we can
> >> +         * transition directly to the final guest-accessible type */
> >> +        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
> >>      /* Fix p2m mapping */
> >> -    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
> >> +    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
> >>
> >>      atomic_dec(&d->paged_pages);
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/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 Jan 12 02:25:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 02: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 1RlALe-0007SR-9z; Thu, 12 Jan 2012 02:25:02 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hongkaixing@huawei.com>) id 1RlALc-0007SM-DK
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 02:25:00 +0000
X-Env-Sender: hongkaixing@huawei.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326335091!7892956!1
X-Originating-IP: [119.145.14.64]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTE5LjE0NS4xNC42NCA9PiAxNzk2NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5461 invoked from network); 12 Jan 2012 02:24:52 -0000
Received: from szxga01-in.huawei.com (HELO szxga01-in.huawei.com)
	(119.145.14.64) by server-3.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 02:24:52 -0000
Received: from huawei.com (szxga05-in [172.24.2.49])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXN002M0YPDQS@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:24:49 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119])
	by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14
	(built Aug
	8 2006)) with ESMTP id <0LXN002B9YOJT4@szxga05-in.huawei.com> for
	xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:24:49 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119])
	by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AGG44164; Thu,
	12 Jan 2012 10:24:34 +0800
Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163)
	by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP
	Server (TLS) id 14.1.323.3; Thu, 12 Jan 2012 10:24:12 +0800
Received: from h00166998 (10.166.80.196) by szxeml424-hub.china.huawei.com
	(10.82.67.163) with Microsoft SMTP Server id 14.1.323.3; Thu,
	12 Jan 2012 10:24:05 +0800
Date: Thu, 12 Jan 2012 10:24:06 +0800
From: Hongkaixing <hongkaixing@huawei.com>
In-reply-to: <d3c062de69d4de2a251193814609365c.squirrel@webmail.lagarcavilla.org>
X-Originating-IP: [10.166.80.196]
To: andres@lagarcavilla.org
Message-id: <000001ccd0d1$43bfd750$cb3f85f0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-language: zh-cn
Thread-index: AczQcTLbsa/i4JSqTS+b0bHNMz7hNAAXgBew
X-CFilter-Loop: Reflected
References: <patchbomb.1326145285@xdev.gridcentric.ca>
	<f7c330d5b4b5c78155bd.1326145286@xdev.gridcentric.ca>
	<000a01ccd034$f7037ee0$e50a7ca0$@com>
	<d3c062de69d4de2a251193814609365c.squirrel@webmail.lagarcavilla.org>
Cc: xiaowei.yang@huawei.com, olaf@aepfle.de, xen-devel@lists.xensource.com,
	andres@gridcentric.ca, yanqiangjun@huawei.com, tim@xen.org,
	bicky.shi@huawei.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
 p2m_ram_paged_out state to be loaded
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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: Andres Lagar-Cavilla [mailto:andres@lagarcavilla.org]
> Sent: Wednesday, January 11, 2012 10:57 PM
> To: Hongkaixing
> Cc: xen-devel@lists.xensource.com; andres@gridcentric.ca; tim@xen.org; olaf@aepfle.de; adin@gridcentric.ca;
> yanqiangjun@huawei.com; bicky.shi@huawei.com; xiaowei.yang@huawei.com
> Subject: RE: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in p2m_ram_paged_out state to be loaded
> 
> I think top-posting is frowned upon. Below...
> >     I think it may have many unpredicted risks.
> >     After p2mt is changed to p2m_ram_rw, Domain guest can access this page
> > unrestrictedly without being trapped in xen.
> >  But at this time, the page is not prepared.
> 
> Nope. The page has already been allocated and paged-in (copy_from_user out
> of user_ptr) by the time the p2mt is changed


I have got it,  first change p2mt to p2m_ram_paging_in, prepare a page, use copy_from_usr to copy, then change p2mt to ram_rw . It
is a good idea.



> Andres
> >
> >> -----Original Message-----
> >> From: xen-devel-bounces@lists.xensource.com
> >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Andres
> >> Lagar-Cavilla
> >> Sent: Tuesday, January 10, 2012 5:41 AM
> >> To: xen-devel@lists.xensource.com
> >> Cc: andres@gridcentric.ca; tim@xen.org; olaf@aepfle.de;
> >> adin@gridcentric.ca
> >> Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Allow a page in
> >> p2m_ram_paged_out state to be loaded
> >>
> >>  xen/arch/x86/mm/p2m.c |  15 +++++++++++----
> >>  1 files changed, 11 insertions(+), 4 deletions(-)
> >>
> >>
> >> This removes the need for a page to be accessed in order to be pageable
> >> again. A pager can now page-in pages at will with no need to map them
> >> in a separate thread.
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >> Acked-by: Tim Deegan <tim@xen.org>
> >>
> >> diff -r 90f764bf02c3 -r f7c330d5b4b5 xen/arch/x86/mm/p2m.c
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -964,7 +964,7 @@ void p2m_mem_paging_populate(struct doma
> >>  int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t
> >> buffer)
> >>  {
> >>      struct page_info *page;
> >> -    p2m_type_t p2mt;
> >> +    p2m_type_t p2mt, target_p2mt;
> >>      p2m_access_t a;
> >>      mfn_t mfn;
> >>      struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> @@ -982,8 +982,8 @@ int p2m_mem_paging_prep(struct domain *d
> >>      mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, p2m_query, NULL);
> >>
> >>      ret = -ENOENT;
> >> -    /* Allow only missing pages */
> >> -    if ( p2mt != p2m_ram_paging_in_start )
> >> +    /* Allow missing pages */
> >> +    if ( (p2mt != p2m_ram_paging_in_start) && (p2mt != p2m_ram_paged) )
> >>          goto out;
> >>
> >>      /* Allocate a page if the gfn does not have one yet */
> >> @@ -1018,8 +1018,15 @@ int p2m_mem_paging_prep(struct domain *d
> >>          }
> >>      }
> >>
> >> +    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
> >> +        /* If we kicked the pager with a populate event, the pager will
> >> send
> >> +         * a resume event back */
> >> +        p2m_ram_paging_in :
> >> +        /* If this was called asynchronously by the pager, then we can
> >> +         * transition directly to the final guest-accessible type */
> >> +        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
> >>      /* Fix p2m mapping */
> >> -    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, p2m_ram_paging_in, a);
> >> +    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
> >>
> >>      atomic_dec(&d->paged_pages);
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/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 Jan 12 02:29:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 02: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 1RlAPM-0007Yd-1y; Thu, 12 Jan 2012 02:28:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RlAPK-0007YS-Ng
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 02:28:50 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326335324!10638608!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIzNzA1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17394 invoked from network); 12 Jan 2012 02:28:44 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-4.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 02:28:44 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 11 Jan 2012 18:28:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="95485410"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 11 Jan 2012 18:28:42 -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; Thu, 12 Jan 2012 10:27:46 +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; Thu, 12 Jan 2012 10:27:46 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Thu, 12 Jan 2012 10:27:44 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4AACb/RMAACRHyAAI09hpAACpZegAAvdLuwAAHtaoAAW7sc4A==
Date: Thu, 12 Jan 2012 02:27:43 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10FCC4442@SHSMSX102.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
	<20120109150436.GD25563@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCBE178@SHSMSX102.ccr.corp.intel.com>
	<20120110143837.GB17826@phenom.dumpdata.com>
In-Reply-To: <20120110143837.GB17826@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Tuesday, January 10, 2012 10:39 PM
> 
> On Tue, Jan 10, 2012 at 05:47:48AM +0000, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Monday, January 09, 2012 11:05 PM
> > >
> > > > > But more interestingly - are you building your kernel from scratch?
> There
> > > >
> > > > yes
> > > >
> > > > > was some requirements in having CONFIG_IOMMU_DMAR in the
> kernels -
> > > > > otherwise
> > > > > the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.
> > > >
> > > > Suppose you mean CONFIG_DMAR_TABLE? There's no
> > > CONFIG_IOMMU_DMAR
> > > > in the latest kernel. Yes, I didn't enable that option, and will have a try.
> > >
> > > Yes, that is the option.
> > >
> > > >
> > > > But a side question is, will enabling VT-d in dom0 conflict with Xen's own
> > > > VT-d operations?
> > >
> > > No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux's
> > > parser won't pick it up.
> >
> > Hi, Konrad,
> >
> > this information is really great, and now X can be started smoothly, and also
> > a simple glxgear runs well! :-) This options deserves an explicit mark in the
> > wiki page btw.
> 
> Done! If you have a screenshot of the "defective" kernel build that would be
> usefull
> as we can attach it to
> http://wiki.xen.org/wiki/Paravirtualized_DRM#X_shows_a_checkerboard_or_j
> ust_random_stuff_when_using_i915

I'll see whether I can take one. Need to find a way which can capture the screen
before X is fully started. My working environment prevents from using camera. :/

Thanks
Kevin

> 
> >
> > Thanks
> > Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 02:29:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 02: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 1RlAPM-0007Yd-1y; Thu, 12 Jan 2012 02:28:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kevin.tian@intel.com>) id 1RlAPK-0007YS-Ng
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 02:28:50 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326335324!10638608!1
X-Originating-IP: [134.134.136.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjQgPT4gMzIzNzA1\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17394 invoked from network); 12 Jan 2012 02:28:44 -0000
Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24)
	by server-4.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 02:28:44 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 11 Jan 2012 18:28:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="95485410"
Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81])
	by orsmga001.jf.intel.com with ESMTP; 11 Jan 2012 18:28:42 -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; Thu, 12 Jan 2012 10:27:46 +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; Thu, 12 Jan 2012 10:27:46 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Thu, 12 Jan 2012 10:27:44 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thread-Topic: [Xen-devel] question about i915 driver in dom0
Thread-Index: AczEYxGiaxw3o8ecRW2obuwyqnfvvwFkudyAAIXmO4AACb/RMAACRHyAAI09hpAACpZegAAvdLuwAAHtaoAAW7sc4A==
Date: Thu, 12 Jan 2012 02:27:43 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10FCC4442@SHSMSX102.ccr.corp.intel.com>
References: <AADFC41AFE54684AB9EE6CBC0274A5D10158AE@SHSMSX102.ccr.corp.intel.com>
	<20120103165917.GB749@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D597@SHSMSX102.ccr.corp.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102DDA2@SHSMSX102.ccr.corp.intel.com>
	<20120106143719.GA5078@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCB5812@SHSMSX101.ccr.corp.intel.com>
	<20120109150436.GD25563@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCBE178@SHSMSX102.ccr.corp.intel.com>
	<20120110143837.GB17826@phenom.dumpdata.com>
In-Reply-To: <20120110143837.GB17826@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [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

> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Tuesday, January 10, 2012 10:39 PM
> 
> On Tue, Jan 10, 2012 at 05:47:48AM +0000, Tian, Kevin wrote:
> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > Sent: Monday, January 09, 2012 11:05 PM
> > >
> > > > > But more interestingly - are you building your kernel from scratch?
> There
> > > >
> > > > yes
> > > >
> > > > > was some requirements in having CONFIG_IOMMU_DMAR in the
> kernels -
> > > > > otherwise
> > > > > the intel-gtt.c would use the 'virt_to_phys' code instead of the DMA API.
> > > >
> > > > Suppose you mean CONFIG_DMAR_TABLE? There's no
> > > CONFIG_IOMMU_DMAR
> > > > in the latest kernel. Yes, I didn't enable that option, and will have a try.
> > >
> > > Yes, that is the option.
> > >
> > > >
> > > > But a side question is, will enabling VT-d in dom0 conflict with Xen's own
> > > > VT-d operations?
> > >
> > > No conflict. The Xen re-writes the DMAR table to be called XMAR so Linux's
> > > parser won't pick it up.
> >
> > Hi, Konrad,
> >
> > this information is really great, and now X can be started smoothly, and also
> > a simple glxgear runs well! :-) This options deserves an explicit mark in the
> > wiki page btw.
> 
> Done! If you have a screenshot of the "defective" kernel build that would be
> usefull
> as we can attach it to
> http://wiki.xen.org/wiki/Paravirtualized_DRM#X_shows_a_checkerboard_or_j
> ust_random_stuff_when_using_i915

I'll see whether I can take one. Need to find a way which can capture the screen
before X is fully started. My working environment prevents from using camera. :/

Thanks
Kevin

> 
> >
> > Thanks
> > Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 06:46:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 06:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlEQ5-0000wz-9Z; Thu, 12 Jan 2012 06:45: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 1RlEQ4-0000wr-5n
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 06:45:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326350746!3943937!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14403 invoked from network); 12 Jan 2012 06:45:46 -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;
	12 Jan 2012 06:45:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,496,1320624000"; 
   d="scan'208";a="9961730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 06:45:45 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 06:45:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0A2720@BITCOM1.int.sbss.com.au>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<6035A0D088A63A46850C3988ED045A4B0A2720@BITCOM1.int.sbss.com.au>
Organization: Citrix Systems, Inc.
Date: Thu, 12 Jan 2012 06:45:44 +0000
Message-ID: <1326350744.29084.101.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 v5 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

On Wed, 2012-01-11 at 21:34 +0000, James Harper wrote:
> Are any of the free ARM emulators capable of emulating an ARMv7 platform?

ARMv7 possibly qemu does, but ARMv7+virt extensions I don't think any of
them do.

I think you can get an evaluation license for ARM's tools by registering
on their website though. That's what we used early on in this port.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 06:46:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 06:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlEQ5-0000wz-9Z; Thu, 12 Jan 2012 06:45: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 1RlEQ4-0000wr-5n
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 06:45:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326350746!3943937!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14403 invoked from network); 12 Jan 2012 06:45:46 -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;
	12 Jan 2012 06:45:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,496,1320624000"; 
   d="scan'208";a="9961730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 06:45:45 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 06:45:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: James Harper <james.harper@bendigoit.com.au>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0A2720@BITCOM1.int.sbss.com.au>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<6035A0D088A63A46850C3988ED045A4B0A2720@BITCOM1.int.sbss.com.au>
Organization: Citrix Systems, Inc.
Date: Thu, 12 Jan 2012 06:45:44 +0000
Message-ID: <1326350744.29084.101.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 v5 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

On Wed, 2012-01-11 at 21:34 +0000, James Harper wrote:
> Are any of the free ARM emulators capable of emulating an ARMv7 platform?

ARMv7 possibly qemu does, but ARMv7+virt extensions I don't think any of
them do.

I think you can get an evaluation license for ARM's tools by registering
on their website though. That's what we used early on in this port.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:22:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 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 1RlFut-0002Yw-DY; Thu, 12 Jan 2012 08:21:47 +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 1RlFur-0002Yl-E3
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:21:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326356499!10694315!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 23652 invoked from network); 12 Jan 2012 08:21:39 -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; 12 Jan 2012 08:21:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 08:21:38 +0000
Message-Id: <4F0EA65B020000780006BFEC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 08:22:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-2-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302490-19428-2-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

>>> On 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -54,6 +54,7 @@
>  !	kexec_image			kexec.h
>  !	kexec_range			kexec.h
>  !	add_to_physmap			memory.h
> +!	remove_from_physmap		memory.h
>  !	foreign_memory_map		memory.h
>  !	memory_exchange			memory.h
>  !	memory_map			memory.h

Alphabetically, please.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:22:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 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 1RlFut-0002Yw-DY; Thu, 12 Jan 2012 08:21:47 +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 1RlFur-0002Yl-E3
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:21:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326356499!10694315!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 23652 invoked from network); 12 Jan 2012 08:21:39 -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; 12 Jan 2012 08:21:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 08:21:38 +0000
Message-Id: <4F0EA65B020000780006BFEC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 08:22:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-2-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302490-19428-2-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

>>> On 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -54,6 +54,7 @@
>  !	kexec_image			kexec.h
>  !	kexec_range			kexec.h
>  !	add_to_physmap			memory.h
> +!	remove_from_physmap		memory.h
>  !	foreign_memory_map		memory.h
>  !	memory_exchange			memory.h
>  !	memory_map			memory.h

Alphabetically, please.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:38:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08: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 1RlGAf-0002nU-0N; Thu, 12 Jan 2012 08:38:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlGAe-0002nP-98
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:38:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326357478!8497261!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7194 invoked from network); 12 Jan 2012 08:37:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 08:37:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9963206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 08:37:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 08:37:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Jan 2012 08:37:57 +0000
In-Reply-To: <1326304919.12973.5.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304919.12973.5.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326357477.17210.208.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] libxl: Align examples with current
	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, 2012-01-11 at 18:01 +0000, Dario Faggioli wrote:
> Just make sure the syntax proposed in the various examples is
> the right one.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm
> --- a/tools/examples/xmexample.hvm	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample.hvm	Wed Jan 11 17:32:34 2012 +0000

These are the xend/xm examples which you didn't change. Or is it that
the current examples don't actually reflect the current xend syntax
either?

The xl examples are xl* in the same directory. These are more minimal
examples so I don't think including affinity there is necessary. Instead
you need to patch docs/man/xl.cfg.pod.5 to reflect the new syntax (and
if necessary deprecate the old).

BTW, I think we are in general happy for docs updates to go in the same
patch as the corresponding code update.

Ian.

> @@ -59,10 +59,8 @@ name = "ExampleHVMDomain"
>  # xen_extended_power_mgmt=0
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Optionally define mac and/or bridge for the network interfaces.
>  # Random MACs are assigned if not given.
> diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm-stubdom
> --- a/tools/examples/xmexample.hvm-stubdom	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample.hvm-stubdom	Wed Jan 11 17:32:34 2012 +0000
> @@ -50,10 +50,8 @@ name = "xmexample.hvm"
>  #apic=1
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Optionally define mac and/or bridge for the network interfaces.
>  # Random MACs are assigned if not given.
> diff -r 897ea4d3c2d7 tools/examples/xmexample.pv-grub
> --- a/tools/examples/xmexample.pv-grub	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample.pv-grub	Wed Jan 11 17:32:34 2012 +0000
> @@ -35,10 +35,8 @@ name = "ExampleDomain"
>  #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Number of Virtual CPUS to use, default is 1
>  #vcpus = 1
> diff -r 897ea4d3c2d7 tools/examples/xmexample.vti
> --- a/tools/examples/xmexample.vti	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample.vti	Wed Jan 11 17:32:34 2012 +0000
> @@ -31,10 +31,8 @@ name = "ExampleVTIDomain"
>  #vcpus=1
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Log2 of VHPT size, default=23 (8MB), minimum=15 (32KB).
>  # In Windows OS, smaller size shows better performance.
> diff -r 897ea4d3c2d7 tools/examples/xmexample1
> --- a/tools/examples/xmexample1	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample1	Wed Jan 11 17:32:34 2012 +0000
> @@ -31,10 +31,8 @@ name = "ExampleDomain"
>  #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Number of Virtual CPUS to use, default is 1
>  #vcpus = 1
> diff -r 897ea4d3c2d7 tools/examples/xmexample2
> --- a/tools/examples/xmexample2	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample2	Wed Jan 11 17:32:34 2012 +0000
> @@ -60,11 +60,8 @@ name = "VM%d" % vmid
>  #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
> -#cpus = "%s" % vmid # set based on vmid (mod number of CPUs)
>  
>  # Number of Virtual CPUS to use, default is 1
>  #vcpus = 1
> diff -r 897ea4d3c2d7 tools/examples/xmexample3
> --- a/tools/examples/xmexample3	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample3	Wed Jan 11 17:32:34 2012 +0000
> @@ -60,11 +60,8 @@ name = "VM%d" % vmid
>  #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
> -cpus = "%s" % vmid # set based on vmid (mod number of CPUs)
>  
>  #----------------------------------------------------------------------------
>  # Define network interfaces.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:38:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08: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 1RlGAf-0002nU-0N; Thu, 12 Jan 2012 08:38:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlGAe-0002nP-98
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:38:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326357478!8497261!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7194 invoked from network); 12 Jan 2012 08:37:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 08:37:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9963206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 08:37:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 08:37:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Jan 2012 08:37:57 +0000
In-Reply-To: <1326304919.12973.5.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304919.12973.5.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326357477.17210.208.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] libxl: Align examples with current
	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, 2012-01-11 at 18:01 +0000, Dario Faggioli wrote:
> Just make sure the syntax proposed in the various examples is
> the right one.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm
> --- a/tools/examples/xmexample.hvm	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample.hvm	Wed Jan 11 17:32:34 2012 +0000

These are the xend/xm examples which you didn't change. Or is it that
the current examples don't actually reflect the current xend syntax
either?

The xl examples are xl* in the same directory. These are more minimal
examples so I don't think including affinity there is necessary. Instead
you need to patch docs/man/xl.cfg.pod.5 to reflect the new syntax (and
if necessary deprecate the old).

BTW, I think we are in general happy for docs updates to go in the same
patch as the corresponding code update.

Ian.

> @@ -59,10 +59,8 @@ name = "ExampleHVMDomain"
>  # xen_extended_power_mgmt=0
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Optionally define mac and/or bridge for the network interfaces.
>  # Random MACs are assigned if not given.
> diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm-stubdom
> --- a/tools/examples/xmexample.hvm-stubdom	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample.hvm-stubdom	Wed Jan 11 17:32:34 2012 +0000
> @@ -50,10 +50,8 @@ name = "xmexample.hvm"
>  #apic=1
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Optionally define mac and/or bridge for the network interfaces.
>  # Random MACs are assigned if not given.
> diff -r 897ea4d3c2d7 tools/examples/xmexample.pv-grub
> --- a/tools/examples/xmexample.pv-grub	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample.pv-grub	Wed Jan 11 17:32:34 2012 +0000
> @@ -35,10 +35,8 @@ name = "ExampleDomain"
>  #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Number of Virtual CPUS to use, default is 1
>  #vcpus = 1
> diff -r 897ea4d3c2d7 tools/examples/xmexample.vti
> --- a/tools/examples/xmexample.vti	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample.vti	Wed Jan 11 17:32:34 2012 +0000
> @@ -31,10 +31,8 @@ name = "ExampleVTIDomain"
>  #vcpus=1
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Log2 of VHPT size, default=23 (8MB), minimum=15 (32KB).
>  # In Windows OS, smaller size shows better performance.
> diff -r 897ea4d3c2d7 tools/examples/xmexample1
> --- a/tools/examples/xmexample1	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample1	Wed Jan 11 17:32:34 2012 +0000
> @@ -31,10 +31,8 @@ name = "ExampleDomain"
>  #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
>  
>  # Number of Virtual CPUS to use, default is 1
>  #vcpus = 1
> diff -r 897ea4d3c2d7 tools/examples/xmexample2
> --- a/tools/examples/xmexample2	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample2	Wed Jan 11 17:32:34 2012 +0000
> @@ -60,11 +60,8 @@ name = "VM%d" % vmid
>  #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
> -#cpus = "%s" % vmid # set based on vmid (mod number of CPUs)
>  
>  # Number of Virtual CPUS to use, default is 1
>  #vcpus = 1
> diff -r 897ea4d3c2d7 tools/examples/xmexample3
> --- a/tools/examples/xmexample3	Wed Jan 11 17:28:53 2012 +0000
> +++ b/tools/examples/xmexample3	Wed Jan 11 17:32:34 2012 +0000
> @@ -60,11 +60,8 @@ name = "VM%d" % vmid
>  #uuid = "06ed00fe-1162-4fc4-b5d8-11993ee4a8b9"
>  
>  # List of which CPUS this domain is allowed to use, default Xen picks
> -#cpus = ""         # leave to Xen to pick
>  #cpus = "0"        # all vcpus run on CPU0
>  #cpus = "0-3,5,^1" # all vcpus run on cpus 0,2,3,5
> -#cpus = ["2", "3"] # VCPU0 runs on CPU2, VCPU1 runs on CPU3
> -cpus = "%s" % vmid # set based on vmid (mod number of CPUs)
>  
>  #----------------------------------------------------------------------------
>  # Define network interfaces.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:38:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlGAs-0002od-J8; Thu, 12 Jan 2012 08:38:18 +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 1RlGAq-0002o7-Q9
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:38:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326357490!10038303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 487 invoked from network); 12 Jan 2012 08:38:10 -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;
	12 Jan 2012 08:38:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9963214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 08:38: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, 12 Jan 2012 08:38:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Jan 2012 08:38:09 +0000
In-Reply-To: <1326304739.12973.1.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326357489.17210.209.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
	for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:58 +0000, Dario Faggioli wrote:
> Allow for "^<cpuid>" syntax while specifying the pCPUs list
> during a vcpu-pin. This enables doing the following:
> 
>  xl vcpu-pin 1 1 0-4,^2
> 
> and achieving:
> 
>  xl vcpu-list
>  Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>  ...
>  Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
>  ...
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 9cdcedc133e5 tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h	Wed Jan 11 10:34:45 2012 +0100
> +++ b/tools/libxl/libxl_utils.h	Wed Jan 11 17:38:04 2012 +0000
> @@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
>  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
>  #define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
> +#define libxl_for_each_set_cpu(var, map) for (var = 0; var < (map).size * 8; var++) \
> +                                             if (libxl_cpumap_test(&(map), var))
>  
>  int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
>  
> diff -r 9cdcedc133e5 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 10:34:45 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:38:04 2012 +0000
> @@ -3501,13 +3501,67 @@ int main_vcpulist(int argc, char **argv)
>      return 0;
>  }
>  
> +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> +{
> +    libxl_cpumap exclude_cpumap;
> +    uint32_t cpuida, cpuidb;
> +    char *endptr, *toka, *tokb;
> +    int i, rmcpu, ret = 0;
> +
> +    if (libxl_cpumap_alloc(ctx, &exclude_cpumap))
> +        return ENOMEM;
> +
> +    if (strcmp(cpu, "all")) {
> +        for (toka = strtok(cpu, ","), i = 0; toka; toka = strtok(NULL, ","), ++i) {
> +            rmcpu = 0;
> +            if (*toka == '^') {
> +                toka++; rmcpu = 1;
> +            }
> +            cpuida = strtoul(toka, &endptr, 10);
> +            if (toka == endptr) {
> +                fprintf(stderr, "Error: Invalid argument.\n");
> +                ret = EINVAL;
> +                goto vcpp_out;
> +            }
> +            if (rmcpu) {
> +                libxl_cpumap_set(&exclude_cpumap, cpuida);
> +            } else if (*endptr == '-') {
> +                tokb = endptr + 1;
> +                cpuidb = strtoul(tokb, &endptr, 10);
> +                if ((tokb == endptr) || (cpuida > cpuidb)) {
> +                    fprintf(stderr, "Error: Invalid argument.\n");
> +                    ret = EINVAL;
> +                    goto vcpp_out;
> +                }
> +                while (cpuida <= cpuidb) {
> +                    libxl_cpumap_set(cpumap, cpuida);
> +                    ++cpuida;
> +                }
> +            } else {
> +                libxl_cpumap_set(cpumap, cpuida);
> +            }
> +        }
> +
> +        libxl_for_each_set_cpu(i, exclude_cpumap) {
> +            libxl_cpumap_reset(cpumap, i);
> +        }
> +    } else {
> +        memset(cpumap->map, -1, cpumap->size);
> +    }
> +
> +vcpp_out:
> +    libxl_cpumap_dispose(&exclude_cpumap);
> +
> +    return ret;
> +}
> +
>  static void vcpupin(const char *d, const char *vcpu, char *cpu)
>  {
>      libxl_vcpuinfo *vcpuinfo;
>      libxl_cpumap cpumap;
>  
> -    uint32_t vcpuid, cpuida, cpuidb;
> -    char *endptr, *toka, *tokb;
> +    uint32_t vcpuid;
> +    char *endptr;
>      int i, nb_vcpu;
>  
>      vcpuid = strtoul(vcpu, &endptr, 10);
> @@ -3524,32 +3578,9 @@ static void vcpupin(const char *d, const
>      if (libxl_cpumap_alloc(ctx, &cpumap)) {
>          goto vcpupin_out;
>      }
> -    if (strcmp(cpu, "all")) {
> -        for (toka = strtok(cpu, ","), i = 0; toka; toka = strtok(NULL, ","), ++i) {
> -            cpuida = strtoul(toka, &endptr, 10);
> -            if (toka == endptr) {
> -                fprintf(stderr, "Error: Invalid argument.\n");
> -                goto vcpupin_out1;
> -            }
> -            if (*endptr == '-') {
> -                tokb = endptr + 1;
> -                cpuidb = strtoul(tokb, &endptr, 10);
> -                if ((tokb == endptr) || (cpuida > cpuidb)) {
> -                    fprintf(stderr, "Error: Invalid argument.\n");
> -                    goto vcpupin_out1;
> -                }
> -                while (cpuida <= cpuidb) {
> -                    libxl_cpumap_set(&cpumap, cpuida);
> -                    ++cpuida;
> -                }
> -            } else {
> -                libxl_cpumap_set(&cpumap, cpuida);
> -            }
> -        }
> -    }
> -    else {
> -        memset(cpumap.map, -1, cpumap.size);
> -    }
> +
> +    if (vcpupin_parse(cpu, &cpumap))
> +        goto vcpupin_out1;
>  
>      if (vcpuid != -1) {
>          if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) == -1) {
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:38:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlGAs-0002od-J8; Thu, 12 Jan 2012 08:38:18 +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 1RlGAq-0002o7-Q9
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:38:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326357490!10038303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDYyNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 487 invoked from network); 12 Jan 2012 08:38:10 -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;
	12 Jan 2012 08:38:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9963214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 08:38: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, 12 Jan 2012 08:38:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Jan 2012 08:38:09 +0000
In-Reply-To: <1326304739.12973.1.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326357489.17210.209.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
	for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:58 +0000, Dario Faggioli wrote:
> Allow for "^<cpuid>" syntax while specifying the pCPUs list
> during a vcpu-pin. This enables doing the following:
> 
>  xl vcpu-pin 1 1 0-4,^2
> 
> and achieving:
> 
>  xl vcpu-list
>  Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>  ...
>  Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
>  ...
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 9cdcedc133e5 tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h	Wed Jan 11 10:34:45 2012 +0100
> +++ b/tools/libxl/libxl_utils.h	Wed Jan 11 17:38:04 2012 +0000
> @@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
>  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
>  #define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
> +#define libxl_for_each_set_cpu(var, map) for (var = 0; var < (map).size * 8; var++) \
> +                                             if (libxl_cpumap_test(&(map), var))
>  
>  int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
>  
> diff -r 9cdcedc133e5 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 10:34:45 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:38:04 2012 +0000
> @@ -3501,13 +3501,67 @@ int main_vcpulist(int argc, char **argv)
>      return 0;
>  }
>  
> +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> +{
> +    libxl_cpumap exclude_cpumap;
> +    uint32_t cpuida, cpuidb;
> +    char *endptr, *toka, *tokb;
> +    int i, rmcpu, ret = 0;
> +
> +    if (libxl_cpumap_alloc(ctx, &exclude_cpumap))
> +        return ENOMEM;
> +
> +    if (strcmp(cpu, "all")) {
> +        for (toka = strtok(cpu, ","), i = 0; toka; toka = strtok(NULL, ","), ++i) {
> +            rmcpu = 0;
> +            if (*toka == '^') {
> +                toka++; rmcpu = 1;
> +            }
> +            cpuida = strtoul(toka, &endptr, 10);
> +            if (toka == endptr) {
> +                fprintf(stderr, "Error: Invalid argument.\n");
> +                ret = EINVAL;
> +                goto vcpp_out;
> +            }
> +            if (rmcpu) {
> +                libxl_cpumap_set(&exclude_cpumap, cpuida);
> +            } else if (*endptr == '-') {
> +                tokb = endptr + 1;
> +                cpuidb = strtoul(tokb, &endptr, 10);
> +                if ((tokb == endptr) || (cpuida > cpuidb)) {
> +                    fprintf(stderr, "Error: Invalid argument.\n");
> +                    ret = EINVAL;
> +                    goto vcpp_out;
> +                }
> +                while (cpuida <= cpuidb) {
> +                    libxl_cpumap_set(cpumap, cpuida);
> +                    ++cpuida;
> +                }
> +            } else {
> +                libxl_cpumap_set(cpumap, cpuida);
> +            }
> +        }
> +
> +        libxl_for_each_set_cpu(i, exclude_cpumap) {
> +            libxl_cpumap_reset(cpumap, i);
> +        }
> +    } else {
> +        memset(cpumap->map, -1, cpumap->size);
> +    }
> +
> +vcpp_out:
> +    libxl_cpumap_dispose(&exclude_cpumap);
> +
> +    return ret;
> +}
> +
>  static void vcpupin(const char *d, const char *vcpu, char *cpu)
>  {
>      libxl_vcpuinfo *vcpuinfo;
>      libxl_cpumap cpumap;
>  
> -    uint32_t vcpuid, cpuida, cpuidb;
> -    char *endptr, *toka, *tokb;
> +    uint32_t vcpuid;
> +    char *endptr;
>      int i, nb_vcpu;
>  
>      vcpuid = strtoul(vcpu, &endptr, 10);
> @@ -3524,32 +3578,9 @@ static void vcpupin(const char *d, const
>      if (libxl_cpumap_alloc(ctx, &cpumap)) {
>          goto vcpupin_out;
>      }
> -    if (strcmp(cpu, "all")) {
> -        for (toka = strtok(cpu, ","), i = 0; toka; toka = strtok(NULL, ","), ++i) {
> -            cpuida = strtoul(toka, &endptr, 10);
> -            if (toka == endptr) {
> -                fprintf(stderr, "Error: Invalid argument.\n");
> -                goto vcpupin_out1;
> -            }
> -            if (*endptr == '-') {
> -                tokb = endptr + 1;
> -                cpuidb = strtoul(tokb, &endptr, 10);
> -                if ((tokb == endptr) || (cpuida > cpuidb)) {
> -                    fprintf(stderr, "Error: Invalid argument.\n");
> -                    goto vcpupin_out1;
> -                }
> -                while (cpuida <= cpuidb) {
> -                    libxl_cpumap_set(&cpumap, cpuida);
> -                    ++cpuida;
> -                }
> -            } else {
> -                libxl_cpumap_set(&cpumap, cpuida);
> -            }
> -        }
> -    }
> -    else {
> -        memset(cpumap.map, -1, cpumap.size);
> -    }
> +
> +    if (vcpupin_parse(cpu, &cpumap))
> +        goto vcpupin_out1;
>  
>      if (vcpuid != -1) {
>          if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) == -1) {
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlGFa-00034S-AR; Thu, 12 Jan 2012 08:43: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 1RlGFY-00034F-MT
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:43:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326357782!8018302!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31798 invoked from network); 12 Jan 2012 08:43:02 -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;
	12 Jan 2012 08:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9963316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 08: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;
	Thu, 12 Jan 2012 08:43:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Jan 2012 08:43:01 +0000
In-Reply-To: <1326304831.12973.3.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304831.12973.3.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326357782.17210.213.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 18:00 +0000, Dario Faggioli wrote:
> Enable CPU affinity specification in a VM's config file with the
> exact syntax `xl vcpu-pin' provides.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 9ce68a4036b1 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Wed Jan 11 17:38:04 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:40:45 2012 +0000
> @@ -78,6 +78,8 @@ int libxl_init_build_info(libxl_ctx *ctx
>      memset(b_info, '\0', sizeof(*b_info));
>      b_info->max_vcpus = 1;
>      b_info->cur_vcpus = 1;
> +    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
> +        return ERROR_NOMEM;

Should probably set all here since that is the best default?

>      b_info->max_memkb = 32 * 1024;
>      b_info->target_memkb = b_info->max_memkb;
>      b_info->disable_migrate = 0;
> diff -r 9ce68a4036b1 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Wed Jan 11 17:38:04 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Wed Jan 11 17:40:45 2012 +0000
> @@ -72,8 +72,14 @@ int libxl__build_pre(libxl__gc *gc, uint
>                libxl_domain_build_info *info, libxl__domain_build_state *state)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> -    int tsc_mode;
> +    int i, tsc_mode;
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> +    for (i = 0; i < info->max_vcpus; i++) {
> +        if (libxl_set_vcpuaffinity(ctx, domid, i, &info->cpumap) == -1) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "libxl_set_vcpuaffinity failed. "
> +                           "Going ahead without setting affinity for cpu %d.\n", i);
> +        }
> +    }4b
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
>      if (info->type == LIBXL_DOMAIN_TYPE_PV)
>          xc_domain_set_memmap_limit(ctx->xch, domid,
> diff -r 9ce68a4036b1 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Jan 11 17:38:04 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Wed Jan 11 17:40:45 2012 +0000
> @@ -162,6 +162,7 @@ libxl_domain_create_info = Struct("domai
>  libxl_domain_build_info = Struct("domain_build_info",[
>      ("max_vcpus",       integer),
>      ("cur_vcpus",       integer),
> +    ("cpumap",          libxl_cpumap),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       uint32),
>      ("target_memkb",    uint32),
> diff -r 9ce68a4036b1 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:38:04 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:40:45 2012 +0000
> @@ -288,16 +288,24 @@ static void dolog(const char *file, int 
>          libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
>  }
>  
> +static void print_bitmap(uint8_t *map, int maplen, FILE *stream);

Just move the function up? If we are going to do this sort of forward
declaration there should be single block of them near the top somewhere.

> +
>  static void printf_info(int domid,
>                          libxl_domain_config *d_config,
>                          libxl_device_model_info *dm_info)
>  {
> -    int i;
> +    int i, nr_cpus = -1;
>      libxl_dominfo info;
> +    libxl_physinfo physinfo;
>  
>      libxl_domain_create_info *c_info = &d_config->c_info;
>      libxl_domain_build_info *b_info = &d_config->b_info;
>  
> +    if (libxl_get_physinfo(ctx, &physinfo) == 0)
> +        nr_cpus = physinfo.nr_cpus;
> +    else
> +        fprintf(stderr, "libxl_physinfo failed.\n");
> +
>      printf("(domain\n\t(domid %d)\n", domid);
>      printf("\t(create_info)\n");
>      printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
> @@ -328,6 +336,9 @@ static void printf_info(int domid,
>  
>      printf("\t(build_info)\n");
>      printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
> +    printf("\t(CPU affinity ");
> +    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);
> +    printf(")\n");
>      printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
>      printf("\t(max_memkb %d)\n", b_info->max_memkb);
>      printf("\t(target_memkb %d)\n", b_info->target_memkb);
> @@ -569,6 +580,8 @@ static void split_string_into_string_lis
>      free(s);
>  }
>  
> +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);

Again, maybe just reorder the functions?

>  static void parse_config_data(const char *configfile_filename_report,
>                                const char *configfile_data,
>                                int configfile_len,
> @@ -661,6 +674,13 @@ static void parse_config_data(const char
>      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
>          b_info->max_vcpus = l;
>  
> +    if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {

The syntax supported here is different to that in a cpupool cfg? (see
main_cpupoolcreate) Perhaps they should be similar?

> +        char *buf2 = strdup(buf);
> +        vcpupin_parse(buf2, &b_info->cpumap);
> +    } else {
> +        memset(b_info->cpumap.map, -1, b_info->cpumap.size);

This could do with a helper function in libxl_utils.h.

Ian.


> +    }
> +
>      if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
>          b_info->max_memkb = l * 1024;
>          b_info->target_memkb = b_info->max_memkb;
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlGFa-00034S-AR; Thu, 12 Jan 2012 08:43: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 1RlGFY-00034F-MT
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:43:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326357782!8018302!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31798 invoked from network); 12 Jan 2012 08:43:02 -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;
	12 Jan 2012 08:43:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9963316"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 08: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;
	Thu, 12 Jan 2012 08:43:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Thu, 12 Jan 2012 08:43:01 +0000
In-Reply-To: <1326304831.12973.3.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304831.12973.3.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326357782.17210.213.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 18:00 +0000, Dario Faggioli wrote:
> Enable CPU affinity specification in a VM's config file with the
> exact syntax `xl vcpu-pin' provides.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 9ce68a4036b1 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Wed Jan 11 17:38:04 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:40:45 2012 +0000
> @@ -78,6 +78,8 @@ int libxl_init_build_info(libxl_ctx *ctx
>      memset(b_info, '\0', sizeof(*b_info));
>      b_info->max_vcpus = 1;
>      b_info->cur_vcpus = 1;
> +    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
> +        return ERROR_NOMEM;

Should probably set all here since that is the best default?

>      b_info->max_memkb = 32 * 1024;
>      b_info->target_memkb = b_info->max_memkb;
>      b_info->disable_migrate = 0;
> diff -r 9ce68a4036b1 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Wed Jan 11 17:38:04 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Wed Jan 11 17:40:45 2012 +0000
> @@ -72,8 +72,14 @@ int libxl__build_pre(libxl__gc *gc, uint
>                libxl_domain_build_info *info, libxl__domain_build_state *state)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> -    int tsc_mode;
> +    int i, tsc_mode;
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> +    for (i = 0; i < info->max_vcpus; i++) {
> +        if (libxl_set_vcpuaffinity(ctx, domid, i, &info->cpumap) == -1) {
> +                LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "libxl_set_vcpuaffinity failed. "
> +                           "Going ahead without setting affinity for cpu %d.\n", i);
> +        }
> +    }4b
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
>      if (info->type == LIBXL_DOMAIN_TYPE_PV)
>          xc_domain_set_memmap_limit(ctx->xch, domid,
> diff -r 9ce68a4036b1 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Jan 11 17:38:04 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Wed Jan 11 17:40:45 2012 +0000
> @@ -162,6 +162,7 @@ libxl_domain_create_info = Struct("domai
>  libxl_domain_build_info = Struct("domain_build_info",[
>      ("max_vcpus",       integer),
>      ("cur_vcpus",       integer),
> +    ("cpumap",          libxl_cpumap),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       uint32),
>      ("target_memkb",    uint32),
> diff -r 9ce68a4036b1 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:38:04 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:40:45 2012 +0000
> @@ -288,16 +288,24 @@ static void dolog(const char *file, int 
>          libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
>  }
>  
> +static void print_bitmap(uint8_t *map, int maplen, FILE *stream);

Just move the function up? If we are going to do this sort of forward
declaration there should be single block of them near the top somewhere.

> +
>  static void printf_info(int domid,
>                          libxl_domain_config *d_config,
>                          libxl_device_model_info *dm_info)
>  {
> -    int i;
> +    int i, nr_cpus = -1;
>      libxl_dominfo info;
> +    libxl_physinfo physinfo;
>  
>      libxl_domain_create_info *c_info = &d_config->c_info;
>      libxl_domain_build_info *b_info = &d_config->b_info;
>  
> +    if (libxl_get_physinfo(ctx, &physinfo) == 0)
> +        nr_cpus = physinfo.nr_cpus;
> +    else
> +        fprintf(stderr, "libxl_physinfo failed.\n");
> +
>      printf("(domain\n\t(domid %d)\n", domid);
>      printf("\t(create_info)\n");
>      printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
> @@ -328,6 +336,9 @@ static void printf_info(int domid,
>  
>      printf("\t(build_info)\n");
>      printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
> +    printf("\t(CPU affinity ");
> +    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);
> +    printf(")\n");
>      printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
>      printf("\t(max_memkb %d)\n", b_info->max_memkb);
>      printf("\t(target_memkb %d)\n", b_info->target_memkb);
> @@ -569,6 +580,8 @@ static void split_string_into_string_lis
>      free(s);
>  }
>  
> +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);

Again, maybe just reorder the functions?

>  static void parse_config_data(const char *configfile_filename_report,
>                                const char *configfile_data,
>                                int configfile_len,
> @@ -661,6 +674,13 @@ static void parse_config_data(const char
>      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
>          b_info->max_vcpus = l;
>  
> +    if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {

The syntax supported here is different to that in a cpupool cfg? (see
main_cpupoolcreate) Perhaps they should be similar?

> +        char *buf2 = strdup(buf);
> +        vcpupin_parse(buf2, &b_info->cpumap);
> +    } else {
> +        memset(b_info->cpumap.map, -1, b_info->cpumap.size);

This could do with a helper function in libxl_utils.h.

Ian.


> +    }
> +
>      if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
>          b_info->max_memkb = l * 1024;
>          b_info->target_memkb = b_info->max_memkb;
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlGFf-00034x-NZ; Thu, 12 Jan 2012 08:43:15 +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 1RlGFe-00034M-9Q
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:43:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326357787!8781649!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 27591 invoked from network); 12 Jan 2012 08:43:07 -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; 12 Jan 2012 08:43:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 08:43:06 +0000
Message-Id: <4F0EAB5F020000780006C02F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 08:43:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-3-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302490-19428-3-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> @@ -659,6 +659,8 @@ static void complete_domain_destroy(struct rcu_head *head)
>  
>      watchdog_domain_destroy(d);
>  
> +    clear_global_virq_handlers(d);

This is too late, I'm afraid. The domain can't possibly service the vIRQ(s)
anymore as soon as its destruction begins.

> +
>      rangeset_domain_destroy(d);
>  
>      cpupool_rm_domain(d);
> @@ -739,6 +739,67 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
>      return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
>  }
>  
> +static struct domain* global_virq_handlers[NR_VIRQS];

__read_mostly?

Also, the formatting is wrong (also elsewhere in the patch) - the
space should be before the star, not after.

> +
> +spinlock_t global_virq_handlers_lock = SPIN_LOCK_UNLOCKED;

static? DEFINE_SPINLOCK()?

> +
> +static struct domain* _get_global_virq_handler(int virq)
> +{
> +    struct domain *d;
> +
> +    d = global_virq_handlers[virq];
> +    return d != NULL ? d : dom0;

This can be done in a single line:

    return global_virq_handlers[virq] ?: dom0;

> +}
> +
> +void send_global_virq(int virq)
> +{
> +    ASSERT(virq >= 0 && virq < NR_VIRQS);
> +    ASSERT(virq_is_global(virq));
> +
> +    send_guest_global_virq(_get_global_virq_handler(virq), virq);
> +}
> +
> +int set_global_virq_handler(struct domain *d, int virq)

In the domctl interface structure the virq (correctly) is uint32_t,
so why is it (signed) int here (and elsewhere)?

> +{
> +    struct domain *old;
> +
> +    if (virq < 0 || virq >= NR_VIRQS)

The < 0 part would then become unnecessary.

> +        return -EINVAL;
> +    if (!virq_is_global(virq))
> +        return -EINVAL;
> +
> +    if (global_virq_handlers[virq] == d)
> +        return 0;
> +
> +    if (unlikely(!get_domain(d)))
> +        return -EINVAL;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +
> +    old = global_virq_handlers[virq];
> +    global_virq_handlers[virq] = d;
> +    if (old != NULL)
> +        put_domain(old);

This should happen outside the lock.

> +    spin_unlock(&global_virq_handlers_lock);
> +
> +    return 0;
> +}
> +
> +void clear_global_virq_handlers(struct domain *d)
> +{
> +    int virq;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +
> +    for (virq = 0; virq < NR_VIRQS; virq++) {
> +        if (global_virq_handlers[virq] == d) {
> +            global_virq_handlers[virq] = NULL;
> +            put_domain(d);

Same here (albeit resulting in some code growth).

> +        }
> +    }
> +
> +    spin_unlock(&global_virq_handlers_lock);
> +}
>  
>  static long evtchn_status(evtchn_status_t *status)
>  {
> @@ -912,6 +918,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_set_virq_handler              71

Any reason for picking a non-contiguous value here?

>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlGFf-00034x-NZ; Thu, 12 Jan 2012 08:43:15 +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 1RlGFe-00034M-9Q
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:43:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326357787!8781649!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 27591 invoked from network); 12 Jan 2012 08:43:07 -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; 12 Jan 2012 08:43:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 08:43:06 +0000
Message-Id: <4F0EAB5F020000780006C02F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 08:43:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-3-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302490-19428-3-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> @@ -659,6 +659,8 @@ static void complete_domain_destroy(struct rcu_head *head)
>  
>      watchdog_domain_destroy(d);
>  
> +    clear_global_virq_handlers(d);

This is too late, I'm afraid. The domain can't possibly service the vIRQ(s)
anymore as soon as its destruction begins.

> +
>      rangeset_domain_destroy(d);
>  
>      cpupool_rm_domain(d);
> @@ -739,6 +739,67 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
>      return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
>  }
>  
> +static struct domain* global_virq_handlers[NR_VIRQS];

__read_mostly?

Also, the formatting is wrong (also elsewhere in the patch) - the
space should be before the star, not after.

> +
> +spinlock_t global_virq_handlers_lock = SPIN_LOCK_UNLOCKED;

static? DEFINE_SPINLOCK()?

> +
> +static struct domain* _get_global_virq_handler(int virq)
> +{
> +    struct domain *d;
> +
> +    d = global_virq_handlers[virq];
> +    return d != NULL ? d : dom0;

This can be done in a single line:

    return global_virq_handlers[virq] ?: dom0;

> +}
> +
> +void send_global_virq(int virq)
> +{
> +    ASSERT(virq >= 0 && virq < NR_VIRQS);
> +    ASSERT(virq_is_global(virq));
> +
> +    send_guest_global_virq(_get_global_virq_handler(virq), virq);
> +}
> +
> +int set_global_virq_handler(struct domain *d, int virq)

In the domctl interface structure the virq (correctly) is uint32_t,
so why is it (signed) int here (and elsewhere)?

> +{
> +    struct domain *old;
> +
> +    if (virq < 0 || virq >= NR_VIRQS)

The < 0 part would then become unnecessary.

> +        return -EINVAL;
> +    if (!virq_is_global(virq))
> +        return -EINVAL;
> +
> +    if (global_virq_handlers[virq] == d)
> +        return 0;
> +
> +    if (unlikely(!get_domain(d)))
> +        return -EINVAL;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +
> +    old = global_virq_handlers[virq];
> +    global_virq_handlers[virq] = d;
> +    if (old != NULL)
> +        put_domain(old);

This should happen outside the lock.

> +    spin_unlock(&global_virq_handlers_lock);
> +
> +    return 0;
> +}
> +
> +void clear_global_virq_handlers(struct domain *d)
> +{
> +    int virq;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +
> +    for (virq = 0; virq < NR_VIRQS; virq++) {
> +        if (global_virq_handlers[virq] == d) {
> +            global_virq_handlers[virq] = NULL;
> +            put_domain(d);

Same here (albeit resulting in some code growth).

> +        }
> +    }
> +
> +    spin_unlock(&global_virq_handlers_lock);
> +}
>  
>  static long evtchn_status(evtchn_status_t *status)
>  {
> @@ -912,6 +918,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_set_virq_handler              71

Any reason for picking a non-contiguous value here?

>  #define XEN_DOMCTL_gdbsx_guestmemio            1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu             1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu           1002

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:53:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08: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 1RlGOz-0003R0-Qt; Thu, 12 Jan 2012 08:52:53 +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 1RlGOy-0003Qu-BJ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:52:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326358365!8805515!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 10957 invoked from network); 12 Jan 2012 08:52:46 -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; 12 Jan 2012 08:52:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 08:52:45 +0000
Message-Id: <4F0EADA5020000780006C053@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 08:53:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries
 when switching 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 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      struct domain *d = current->domain;
>      struct grant_table *gt = d->grant_table;
>      struct active_grant_entry *act;
> +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];

How much stack space does this consume? (Or in other words, where
does GNTTAB_NR_RESERVED_ENTRIES get defined? It's not in this
patch, I can't find it in earlier patches, and it also doesn't exist in the
current staging tree.)

Jan

>      long res;
>      int i;
>  
> @@ -2126,7 +2127,7 @@ 
> gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      /* (You need to change the version number for e.g. kexec.) */
>      if ( gt->gt_version != 0 )
>      {
> -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ 
> )
>          {
>              act = &active_entry(gt, i);
>              if ( act->pin != 0 )
> @@ -2151,15 +2152,38 @@ 
> gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>              goto out_unlock;
>      }
>  
> +    /* Preserve the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version == 1) {
> +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> +    } else if (gt->gt_version == 2) {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < 
> nr_grant_entries(gt); i++ )
> +        {
> +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> +            reserved_entries[i].frame = shared_entry_v2(gt, 
> i).full_page.frame;
> +            reserved_entries[i].flags |= status_entry(gt, i);
> +        }
> +    }
> +
>      if ( op.version < 2 && gt->gt_version == 2 )
>          gnttab_unpopulate_status_frames(d, gt);
>  
> -    if ( op.version != gt->gt_version )
> -    {
> -        /* Make sure there's no crud left over in the table from the
> -           old version. */
> -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +    /* Make sure there's no crud left over in the table from the
> +       old version. */
> +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +
> +    /* Restore the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version != 0 && op.version == 1) {
> +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> +    } else if (gt->gt_version != 0 && op.version == 2) {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> +        {
> +            status_entry(gt, i) = reserved_entries[i].flags & 
> (GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & 
> ~(GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> +            shared_entry_v2(gt, i).full_page.frame = 
> reserved_entries[i].frame;
> +        }
>      }
>  
>      gt->gt_version = op.version;
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:53:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08: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 1RlGOz-0003R0-Qt; Thu, 12 Jan 2012 08:52:53 +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 1RlGOy-0003Qu-BJ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:52:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326358365!8805515!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 10957 invoked from network); 12 Jan 2012 08:52:46 -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; 12 Jan 2012 08:52:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 08:52:45 +0000
Message-Id: <4F0EADA5020000780006C053@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 08:53:41 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries
 when switching 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 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      struct domain *d = current->domain;
>      struct grant_table *gt = d->grant_table;
>      struct active_grant_entry *act;
> +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];

How much stack space does this consume? (Or in other words, where
does GNTTAB_NR_RESERVED_ENTRIES get defined? It's not in this
patch, I can't find it in earlier patches, and it also doesn't exist in the
current staging tree.)

Jan

>      long res;
>      int i;
>  
> @@ -2126,7 +2127,7 @@ 
> gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      /* (You need to change the version number for e.g. kexec.) */
>      if ( gt->gt_version != 0 )
>      {
> -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ 
> )
>          {
>              act = &active_entry(gt, i);
>              if ( act->pin != 0 )
> @@ -2151,15 +2152,38 @@ 
> gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>              goto out_unlock;
>      }
>  
> +    /* Preserve the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version == 1) {
> +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> +    } else if (gt->gt_version == 2) {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < 
> nr_grant_entries(gt); i++ )
> +        {
> +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> +            reserved_entries[i].frame = shared_entry_v2(gt, 
> i).full_page.frame;
> +            reserved_entries[i].flags |= status_entry(gt, i);
> +        }
> +    }
> +
>      if ( op.version < 2 && gt->gt_version == 2 )
>          gnttab_unpopulate_status_frames(d, gt);
>  
> -    if ( op.version != gt->gt_version )
> -    {
> -        /* Make sure there's no crud left over in the table from the
> -           old version. */
> -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +    /* Make sure there's no crud left over in the table from the
> +       old version. */
> +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +
> +    /* Restore the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version != 0 && op.version == 1) {
> +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> +    } else if (gt->gt_version != 0 && op.version == 2) {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> +        {
> +            status_entry(gt, i) = reserved_entries[i].flags & 
> (GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & 
> ~(GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> +            shared_entry_v2(gt, i).full_page.frame = 
> reserved_entries[i].frame;
> +        }
>      }
>  
>      gt->gt_version = op.version;
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:59:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08: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 1RlGUe-0003ac-Kk; Thu, 12 Jan 2012 08:58:44 +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 1RlGUd-0003aV-4F
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:58:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326358716!8805805!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 28521 invoked from network); 12 Jan 2012 08:58:36 -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 Jan 2012 08:58:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 08:58:36 +0000
Message-Id: <4F0EAF05020000780006C061@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 08:59:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
> xenbus backend to be started after the kernel has booted. This is
> intended to allow dom0 to start another domain to run xenstore.
> 
> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
> started; the domain ID is passed as the ioctl argument. This sets up a
> listening event channel and grant reference to xenbus, but does not
> start using this interface. It returns the local event channel port.

Any chance to get at least the setup part matched with the
legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?

Jan

> IOCTL_XENBUS_BACKEND_REMOTE_COMMIT causes the kernel to begin using the
> event channel set up in the previous ioctl, reregistering all watches
> and deallocating the previous xenstored event channel.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_comms.c       |    6 +++
>  drivers/xen/xenbus/xenbus_comms.h       |    1 +
>  drivers/xen/xenbus/xenbus_dev_backend.c |   57 
> +++++++++++++++++++++++++++++++
>  include/xen/grant_table.h               |    2 +
>  include/xen/xenbus_dev.h                |    6 +++
>  5 files changed, 72 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c 
> b/drivers/xen/xenbus/xenbus_comms.c
> index 2eff7a6..52fe7ad 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -234,3 +234,9 @@ int xb_init_comms(void)
>  
>  	return 0;
>  }
> +
> +void xb_deinit_comms(void)
> +{
> +	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
> +	xenbus_irq = 0;
> +}
> diff --git a/drivers/xen/xenbus/xenbus_comms.h 
> b/drivers/xen/xenbus/xenbus_comms.h
> index 6e42800..c8abd3b 100644
> --- a/drivers/xen/xenbus/xenbus_comms.h
> +++ b/drivers/xen/xenbus/xenbus_comms.h
> @@ -35,6 +35,7 @@
>  
>  int xs_init(void);
>  int xb_init_comms(void);
> +void xb_deinit_comms(void);
>  
>  /* Low level routines. */
>  int xb_write(const void *data, unsigned len);
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c 
> b/drivers/xen/xenbus/xenbus_dev_backend.c
> index 3d3be78..4138ba2 100644
> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -8,7 +8,11 @@
>  
>  #include <xen/xen.h>
>  #include <xen/page.h>
> +#include <xen/xenbus.h>
>  #include <xen/xenbus_dev.h>
> +#include <xen/grant_table.h>
> +#include <xen/events.h>
> +#include <asm/xen/hypervisor.h>
>  
>  #include "xenbus_comms.h"
>  
> @@ -22,6 +26,53 @@ static int xenbus_backend_open(struct inode *inode, struct 
> file *filp)
>  	return nonseekable_open(inode, filp);
>  }
>  
> +static int pending_xsd_port;
> +
> +static long xenbus_backend_remote_setup(domid_t domid)
> +{
> +	struct evtchn_alloc_unbound arg;
> +	int err;
> +
> +	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, domid,
> +			virt_to_mfn(xen_store_interface), 0 /* writable */);
> +
> +	if (pending_xsd_port) {
> +		struct evtchn_close close;
> +		close.port = pending_xsd_port;
> +		err = HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
> +		WARN_ON(err);
> +	}
> +
> +	arg.dom = DOMID_SELF;
> +	arg.remote_dom = domid;
> +
> +	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
> +	if (err)
> +		return err;
> +
> +	pending_xsd_port = arg.port;
> +
> +	return arg.port;
> +}
> +
> +static long xenbus_backend_remote_commit(unsigned long data)
> +{
> +	if (!pending_xsd_port)
> +		return -EINVAL;
> +
> +	xs_suspend();
> +
> +	if (xen_store_evtchn > 0)
> +		xb_deinit_comms();
> +
> +	xen_store_evtchn = pending_xsd_port;
> +	pending_xsd_port = 0;
> +
> +	xs_resume();
> +
> +	return 0;
> +}
> +
>  static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, 
> unsigned long data)
>  {
>  	if (!capable(CAP_SYS_ADMIN))
> @@ -33,6 +84,12 @@ static long xenbus_backend_ioctl(struct file *file, 
> unsigned int cmd, unsigned l
>  				return xen_store_evtchn;
>  			return -ENODEV;
>  
> +		case IOCTL_XENBUS_BACKEND_REMOTE_SETUP:
> +			return xenbus_backend_remote_setup(data);
> +
> +		case IOCTL_XENBUS_BACKEND_REMOTE_COMMIT:
> +			return xenbus_backend_remote_commit(data);
> +
>  		default:
>  			return -ENOTTY;
>  	}
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 15f8a00..11e27c3 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -46,6 +46,8 @@
>  
>  #include <xen/features.h>
>  
> +#define GNTTAB_RESERVED_XENSTORE 1
> +
>  /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
>  #define NR_GRANT_FRAMES 4
>  
> diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
> index ac5f0fe..24d5028 100644
> --- a/include/xen/xenbus_dev.h
> +++ b/include/xen/xenbus_dev.h
> @@ -38,4 +38,10 @@
>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>  	_IOC(_IOC_NONE, 'B', 0, 0)
>  
> +#define IOCTL_XENBUS_BACKEND_REMOTE_SETUP		\
> +	_IOC(_IOC_NONE, 'B', 1, 0)
> +
> +#define IOCTL_XENBUS_BACKEND_REMOTE_COMMIT		\
> +	_IOC(_IOC_NONE, 'B', 2, 0)
> +
>  #endif /* __LINUX_XEN_XENBUS_DEV_H__ */
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 08:59:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 08: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 1RlGUe-0003ac-Kk; Thu, 12 Jan 2012 08:58:44 +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 1RlGUd-0003aV-4F
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 08:58:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326358716!8805805!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 28521 invoked from network); 12 Jan 2012 08:58:36 -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 Jan 2012 08:58:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 08:58:36 +0000
Message-Id: <4F0EAF05020000780006C061@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 08:59:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
> xenbus backend to be started after the kernel has booted. This is
> intended to allow dom0 to start another domain to run xenstore.
> 
> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
> started; the domain ID is passed as the ioctl argument. This sets up a
> listening event channel and grant reference to xenbus, but does not
> start using this interface. It returns the local event channel port.

Any chance to get at least the setup part matched with the
legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?

Jan

> IOCTL_XENBUS_BACKEND_REMOTE_COMMIT causes the kernel to begin using the
> event channel set up in the previous ioctl, reregistering all watches
> and deallocating the previous xenstored event channel.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_comms.c       |    6 +++
>  drivers/xen/xenbus/xenbus_comms.h       |    1 +
>  drivers/xen/xenbus/xenbus_dev_backend.c |   57 
> +++++++++++++++++++++++++++++++
>  include/xen/grant_table.h               |    2 +
>  include/xen/xenbus_dev.h                |    6 +++
>  5 files changed, 72 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c 
> b/drivers/xen/xenbus/xenbus_comms.c
> index 2eff7a6..52fe7ad 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -234,3 +234,9 @@ int xb_init_comms(void)
>  
>  	return 0;
>  }
> +
> +void xb_deinit_comms(void)
> +{
> +	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
> +	xenbus_irq = 0;
> +}
> diff --git a/drivers/xen/xenbus/xenbus_comms.h 
> b/drivers/xen/xenbus/xenbus_comms.h
> index 6e42800..c8abd3b 100644
> --- a/drivers/xen/xenbus/xenbus_comms.h
> +++ b/drivers/xen/xenbus/xenbus_comms.h
> @@ -35,6 +35,7 @@
>  
>  int xs_init(void);
>  int xb_init_comms(void);
> +void xb_deinit_comms(void);
>  
>  /* Low level routines. */
>  int xb_write(const void *data, unsigned len);
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c 
> b/drivers/xen/xenbus/xenbus_dev_backend.c
> index 3d3be78..4138ba2 100644
> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -8,7 +8,11 @@
>  
>  #include <xen/xen.h>
>  #include <xen/page.h>
> +#include <xen/xenbus.h>
>  #include <xen/xenbus_dev.h>
> +#include <xen/grant_table.h>
> +#include <xen/events.h>
> +#include <asm/xen/hypervisor.h>
>  
>  #include "xenbus_comms.h"
>  
> @@ -22,6 +26,53 @@ static int xenbus_backend_open(struct inode *inode, struct 
> file *filp)
>  	return nonseekable_open(inode, filp);
>  }
>  
> +static int pending_xsd_port;
> +
> +static long xenbus_backend_remote_setup(domid_t domid)
> +{
> +	struct evtchn_alloc_unbound arg;
> +	int err;
> +
> +	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, domid,
> +			virt_to_mfn(xen_store_interface), 0 /* writable */);
> +
> +	if (pending_xsd_port) {
> +		struct evtchn_close close;
> +		close.port = pending_xsd_port;
> +		err = HYPERVISOR_event_channel_op(EVTCHNOP_close, &close);
> +		WARN_ON(err);
> +	}
> +
> +	arg.dom = DOMID_SELF;
> +	arg.remote_dom = domid;
> +
> +	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
> +	if (err)
> +		return err;
> +
> +	pending_xsd_port = arg.port;
> +
> +	return arg.port;
> +}
> +
> +static long xenbus_backend_remote_commit(unsigned long data)
> +{
> +	if (!pending_xsd_port)
> +		return -EINVAL;
> +
> +	xs_suspend();
> +
> +	if (xen_store_evtchn > 0)
> +		xb_deinit_comms();
> +
> +	xen_store_evtchn = pending_xsd_port;
> +	pending_xsd_port = 0;
> +
> +	xs_resume();
> +
> +	return 0;
> +}
> +
>  static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, 
> unsigned long data)
>  {
>  	if (!capable(CAP_SYS_ADMIN))
> @@ -33,6 +84,12 @@ static long xenbus_backend_ioctl(struct file *file, 
> unsigned int cmd, unsigned l
>  				return xen_store_evtchn;
>  			return -ENODEV;
>  
> +		case IOCTL_XENBUS_BACKEND_REMOTE_SETUP:
> +			return xenbus_backend_remote_setup(data);
> +
> +		case IOCTL_XENBUS_BACKEND_REMOTE_COMMIT:
> +			return xenbus_backend_remote_commit(data);
> +
>  		default:
>  			return -ENOTTY;
>  	}
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 15f8a00..11e27c3 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -46,6 +46,8 @@
>  
>  #include <xen/features.h>
>  
> +#define GNTTAB_RESERVED_XENSTORE 1
> +
>  /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
>  #define NR_GRANT_FRAMES 4
>  
> diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
> index ac5f0fe..24d5028 100644
> --- a/include/xen/xenbus_dev.h
> +++ b/include/xen/xenbus_dev.h
> @@ -38,4 +38,10 @@
>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>  	_IOC(_IOC_NONE, 'B', 0, 0)
>  
> +#define IOCTL_XENBUS_BACKEND_REMOTE_SETUP		\
> +	_IOC(_IOC_NONE, 'B', 1, 0)
> +
> +#define IOCTL_XENBUS_BACKEND_REMOTE_COMMIT		\
> +	_IOC(_IOC_NONE, 'B', 2, 0)
> +
>  #endif /* __LINUX_XEN_XENBUS_DEV_H__ */
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 09:15:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlGku-0003qY-GY; Thu, 12 Jan 2012 09:15:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yufang521247@gmail.com>) id 1RlGkt-0003qS-Je
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:15:32 +0000
X-Env-Sender: yufang521247@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326359678!48259195!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,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 28467 invoked from network); 12 Jan 2012 09:14:39 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 09:14:39 -0000
Received: by vbbfa15 with SMTP id fa15so1080118vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 01:15:23 -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=lsa4k/XOjZpKlTHUjz54Rdd7hXrqjd0vZl2ba9LXfDE=;
	b=hv64LaYgHxv9rG/Ij+w3f7AJBzekXxbRlC4qPoBhq6iT5GER8R+UdwubGVBASXBrnK
	xqAQUYPteSNHuxQH81/Pl3PkPYtdYBWd+7vpH0VPLL7WIzd7JI/3CIz8CnZ2d3+wy1Wh
	oHrlkhHKoKXN4s1g/dpOvhnqXBVMG8EpjOd8A=
MIME-Version: 1.0
Received: by 10.52.32.163 with SMTP id k3mr1314179vdi.35.1326359723181; Thu,
	12 Jan 2012 01:15:23 -0800 (PST)
Received: by 10.52.171.45 with HTTP; Thu, 12 Jan 2012 01:15:23 -0800 (PST)
In-Reply-To: <CAFLBxZbtqJ9sFPnDTVxioZodWEydiZVjOV_iXDsBksm9WdxWgQ@mail.gmail.com>
References: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
	<CAFLBxZbtqJ9sFPnDTVxioZodWEydiZVjOV_iXDsBksm9WdxWgQ@mail.gmail.com>
Date: Thu, 12 Jan 2012 17:15:23 +0800
Message-ID: <CAPWDu3r0FcEd+jGEL3HD+obePgSc9sF6Qa4q1azj4SpsRHq4Uw@mail.gmail.com>
From: Yufang Zhang <yufang521247@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Cannot start up HVM guest when maxmem is not equal
 to memory and HAP is enabled.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8639733458500934109=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8639733458500934109==
Content-Type: multipart/alternative; boundary=bcaec51d276625074504b651305d

--bcaec51d276625074504b651305d
Content-Type: text/plain; charset=ISO-8859-1

2012/1/11 George Dunlap <George.Dunlap@eu.citrix.com>

> On Wed, Jan 11, 2012 at 8:03 AM, Yufang Zhang <yufang521247@gmail.com>
> wrote:
> > Hi all,
> >
> > On my production deployment with xen-3.4.4-rc1, HVM guest would not
> start up
> > when maxmem is set not equal to memory, unless HAP is disable(hap=0). The
> > guest just hangs at 'Booting from Hard Disk...' as shown in the
> attachment.
>
> Is there a reason you want to set maxmem != memory?  Starting in 4.0,
> this will cause the VM to boot in "populate-on-demand" mode; but I
> think in 3.4, this may have undefined behavior.
>
>
Actually, you would be exposed to this problem whenever you restart xend
and then reboot the hvm guest, even you set  maxmem == memory in the config
file of that guest. When xend is restarted, it tries to recreate guest
information. memory_dynamic_max and memory_static_max, which are used
to calculate memory and maxmem, are re-calculated from mem_kb and maxmem_kb
respectively.  mem_kb is not equal to maxmem_kb. Thus memory != maxmem
after xend restarts, and rebooting this hvm guest later would leads guest
crash/hang.

> I find that both Oracle VM and Fedora have the same problem per the
> > following links:
> >
> > http://docs.oracle.com/cd/E15458_01/doc.22/e15443/toc.htm#BABBIBFD
> > http://docs.oracle.com/cd/E26996_01/e18546/CJAGDAGB.html#id419003
> > https://bugzilla.redhat.com/show_bug.cgi?id=645319
> >
> > Could I ask if there is any work in upstream/xen-unstable to fix this
> > problem?
>
> Setting maxmem != memory in 4.1 will definitely have a different
> effect -- if your guest has a balloon driver, you will start your VM
> "pre-ballooned"; if your guest does not, it will crash as soon as it
> dirties more than "memory" amount of memory.
>
>  -George


I check the xend code of xen-unstable,  the related logic didn't change
since xen-3.4. So I *guess* a hvm guest without balloon driver would crash
after some time(when it dirties enough memory) after you restarting xend
and rebooting the guest on xen-4.1.

>
> > Thanks.
> >
> > Below is the xm dmesg output related with the hvm guest:
> > (XEN) HVM3: HVM Loader
> > (XEN) HVM3: Detected Xen v3.4.4-rc1-pre
> > (XEN) HVM3: CPU speed is 2267 MHz
> > (XEN) irq.c:243: Dom3 PCI link 0 changed 0 -> 5
> > (XEN) HVM3: PCI-ISA link 0 routed to IRQ5
> > (XEN) irq.c:243: Dom3 PCI link 1 changed 0 -> 10
> > (XEN) HVM3: PCI-ISA link 1 routed to IRQ10
> > (XEN) irq.c:243: Dom3 PCI link 2 changed 0 -> 11
> > (XEN) HVM3: PCI-ISA link 2 routed to IRQ11
> > (XEN) irq.c:243: Dom3 PCI link 3 changed 0 -> 5
> > (XEN) HVM3: PCI-ISA link 3 routed to IRQ5
> > (XEN) HVM3: pci dev 01:2 INTD->IRQ5
> > (XEN) HVM3: pci dev 01:3 INTA->IRQ10
> > (XEN) HVM3: pci dev 03:0 INTA->IRQ5
> > (XEN) HVM3: pci dev 04:0 INTA->IRQ5
> > (XEN) HVM3: pci dev 02:0 bar 10 size 02000000: f0000008
> > (XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008
> > (XEN) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000
> > (XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001
> > (XEN) HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101
> > (XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000
> > (XEN) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201
> > (XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c221
> > (XEN) HVM3: Multiprocessor initialisation:
> > (XEN) HVM3:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8]
> ...
> > done.
> > (XEN) HVM3: Writing SMBIOS tables ...
> > (XEN) HVM3: Loading ROMBIOS ...
> > (XEN) HVM3: 10332 bytes of ROMBIOS high-memory extensions:
> > (XEN) HVM3:   Relocating to 0xfc000000-0xfc00285c ... done
> > (XEN) HVM3: Creating MP tables ...
> > (XEN) HVM3: Loading Cirrus VGABIOS ...
> > (XEN) HVM3: Loading PCI Option ROM ...
> > (XEN) HVM3:  - Manufacturer: http://etherboot.org
> > (XEN) HVM3:  - Product name: gPXE
> > (XEN) HVM3: Loading ACPI ...
> > (XEN) HVM3:  - Lo data: 000ea020-000ea04f
> > (XEN) HVM3:  - Hi data: fc002c00-fc0060bf
> > (XEN) HVM3: vm86 TSS at fc006400
> > (XEN) HVM3: BIOS map:
> > (XEN) HVM3:  c0000-c8fff: VGA BIOS
> > (XEN) HVM3:  c9000-d57ff: Etherboot ROM
> > (XEN) HVM3:  eb000-eb150: SMBIOS tables
> > (XEN) HVM3:  f0000-fffff: Main BIOS
> > (XEN) HVM3: Invoking ROMBIOS ...
> > (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> > (XEN) stdvga.c:147:d3 entering stdvga and caching modes
> > (XEN) HVM3: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert
> Exp $
> > (XEN) HVM3: Bochs BIOS - build: 06/23/99
> > (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> > (XEN) HVM3: Options: apmbios pcibios eltorito PMM
> > (XEN) HVM3:
> > (XEN) HVM3: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> > (XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)
> > (XEN) HVM3: IDE time out
> > (XEN) HVM3:
> > (XEN) HVM3:
> > (XEN) HVM3:
> > (XEN) HVM3: Press F12 for boot menu.
> > (XEN) HVM3:
> > (XEN) HVM3: Booting from Hard Disk...
> > (XEN) HVM3: Booting from 0000:7c00
> > (XEN) io.c:199:d3 MMIO emulation failed @ 0008:4013b1: 90 86 95 21 08 83
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
>

--bcaec51d276625074504b651305d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2012/1/11 George Dunlap <span dir=3D"ltr=
">&lt;<a href=3D"mailto:George.Dunlap@eu.citrix.com" target=3D"_blank">Geor=
ge.Dunlap@eu.citrix.com</a>&gt;</span><br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Wed, Jan 11, 2012 at 8:03 AM, Yufang Zhang &lt;<a href=3D"mailto:yu=
fang521247@gmail.com" target=3D"_blank">yufang521247@gmail.com</a>&gt; wrot=
e:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; On my production deployment with xen-3.4.4-rc1, HVM guest would not st=
art up<br>
&gt; when maxmem is set not equal to memory, unless=A0HAP is disable(hap=3D=
0). The<br>
&gt; guest just hangs at &#39;Booting from Hard Disk...&#39; as shown in th=
e attachment.<br>
<br>
</div>Is there a reason you want to set maxmem !=3D memory? =A0Starting in =
4.0,<br>
this will cause the VM to boot in &quot;populate-on-demand&quot; mode; but =
I<br>
think in 3.4, this may have undefined behavior.<br>
<div><br></div></blockquote><div><br></div><div>Actually, you would be expo=
sed to this problem whenever you restart xend and then reboot the hvm guest=
, even you set =A0maxmem =3D=3D memory in the config file of that guest. Wh=
en xend is restarted, it tries to recreate guest information.=A0memory_dyna=
mic_max and=A0memory_static_max, which are used to=A0calculate memory and m=
axmem,=A0are re-calculated=A0from=A0mem_kb and=A0maxmem_kb respectively.=A0=
=A0mem_kb is not equal to=A0maxmem_kb.=A0Thus memory !=3D maxmem after xend=
 restarts, and rebooting this hvm guest later would leads guest crash/hang.=
 =A0=A0</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div>
&gt; I find that both Oracle VM and Fedora have the same problem per the<br=
>
&gt; following links:<br>
&gt;<br>
&gt; <a href=3D"http://docs.oracle.com/cd/E15458_01/doc.22/e15443/toc.htm#B=
ABBIBFD" target=3D"_blank">http://docs.oracle.com/cd/E15458_01/doc.22/e1544=
3/toc.htm#BABBIBFD</a><br>
&gt; <a href=3D"http://docs.oracle.com/cd/E26996_01/e18546/CJAGDAGB.html#id=
419003" target=3D"_blank">http://docs.oracle.com/cd/E26996_01/e18546/CJAGDA=
GB.html#id419003</a><br>
&gt; <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D645319" targe=
t=3D"_blank">https://bugzilla.redhat.com/show_bug.cgi?id=3D645319</a><br>
&gt;<br>
&gt; Could I ask if there is any work in upstream/xen-unstable to fix this<=
br>
&gt; problem?<br>
<br>
</div>Setting maxmem !=3D memory in 4.1 will definitely have a different<br=
>
effect -- if your guest has a balloon driver, you will start your VM<br>
&quot;pre-ballooned&quot;; if your guest does not, it will crash as soon as=
 it<br>
dirties more than &quot;memory&quot; amount of memory.<br>
<br>
=A0-George</blockquote><div><br></div><div>I check the xend code of xen-uns=
table, =A0the related logic didn&#39;t change since xen-3.4. So I *guess* a=
 hvm guest without balloon driver would crash after some time(when it=A0dir=
ties enough memory) after you restarting xend and rebooting the guest on xe=
n-4.1.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div><div>
&gt;<br>
&gt; Thanks.<br>
&gt;<br>
&gt; Below is the xm dmesg output related with the hvm guest:<br>
&gt; (XEN) HVM3: HVM Loader<br>
&gt; (XEN) HVM3: Detected Xen v3.4.4-rc1-pre<br>
&gt; (XEN) HVM3: CPU speed is 2267 MHz<br>
&gt; (XEN) irq.c:243: Dom3 PCI link 0 changed 0 -&gt; 5<br>
&gt; (XEN) HVM3: PCI-ISA link 0 routed to IRQ5<br>
&gt; (XEN) irq.c:243: Dom3 PCI link 1 changed 0 -&gt; 10<br>
&gt; (XEN) HVM3: PCI-ISA link 1 routed to IRQ10<br>
&gt; (XEN) irq.c:243: Dom3 PCI link 2 changed 0 -&gt; 11<br>
&gt; (XEN) HVM3: PCI-ISA link 2 routed to IRQ11<br>
&gt; (XEN) irq.c:243: Dom3 PCI link 3 changed 0 -&gt; 5<br>
&gt; (XEN) HVM3: PCI-ISA link 3 routed to IRQ5<br>
&gt; (XEN) HVM3: pci dev 01:2 INTD-&gt;IRQ5<br>
&gt; (XEN) HVM3: pci dev 01:3 INTA-&gt;IRQ10<br>
&gt; (XEN) HVM3: pci dev 03:0 INTA-&gt;IRQ5<br>
&gt; (XEN) HVM3: pci dev 04:0 INTA-&gt;IRQ5<br>
&gt; (XEN) HVM3: pci dev 02:0 bar 10 size 02000000: f0000008<br>
&gt; (XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008<br>
&gt; (XEN) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000<br>
&gt; (XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001<br>
&gt; (XEN) HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101<br>
&gt; (XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000<br>
&gt; (XEN) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201<br>
&gt; (XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c221<br>
&gt; (XEN) HVM3: Multiprocessor initialisation:<br>
&gt; (XEN) HVM3: =A0- CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2=
/8] ...<br>
&gt; done.<br>
&gt; (XEN) HVM3: Writing SMBIOS tables ...<br>
&gt; (XEN) HVM3: Loading ROMBIOS ...<br>
&gt; (XEN) HVM3: 10332 bytes of ROMBIOS high-memory extensions:<br>
&gt; (XEN) HVM3: =A0 Relocating to 0xfc000000-0xfc00285c ... done<br>
&gt; (XEN) HVM3: Creating MP tables ...<br>
&gt; (XEN) HVM3: Loading Cirrus VGABIOS ...<br>
&gt; (XEN) HVM3: Loading PCI Option ROM ...<br>
&gt; (XEN) HVM3: =A0- Manufacturer: <a href=3D"http://etherboot.org" target=
=3D"_blank">http://etherboot.org</a><br>
&gt; (XEN) HVM3: =A0- Product name: gPXE<br>
&gt; (XEN) HVM3: Loading ACPI ...<br>
&gt; (XEN) HVM3: =A0- Lo data: 000ea020-000ea04f<br>
&gt; (XEN) HVM3: =A0- Hi data: fc002c00-fc0060bf<br>
&gt; (XEN) HVM3: vm86 TSS at fc006400<br>
&gt; (XEN) HVM3: BIOS map:<br>
&gt; (XEN) HVM3: =A0c0000-c8fff: VGA BIOS<br>
&gt; (XEN) HVM3: =A0c9000-d57ff: Etherboot ROM<br>
&gt; (XEN) HVM3: =A0eb000-eb150: SMBIOS tables<br>
&gt; (XEN) HVM3: =A0f0000-fffff: Main BIOS<br>
&gt; (XEN) HVM3: Invoking ROMBIOS ...<br>
&gt; (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $<br>
&gt; (XEN) stdvga.c:147:d3 entering stdvga and caching modes<br>
&gt; (XEN) HVM3: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert=
 Exp $<br>
&gt; (XEN) HVM3: Bochs BIOS - build: 06/23/99<br>
&gt; (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $<br>
&gt; (XEN) HVM3: Options: apmbios pcibios eltorito PMM<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3: ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/2=
55/63<br>
&gt; (XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)<b=
r>
&gt; (XEN) HVM3: IDE time out<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3: Press F12 for boot menu.<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3: Booting from Hard Disk...<br>
&gt; (XEN) HVM3: Booting from 0000:7c00<br>
&gt; (XEN) io.c:199:d3 MMIO emulation failed @ 0008:4013b1: 90 86 95 21 08 =
83<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen=
-devel@lists.xensource.com</a><br>
&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">htt=
p://lists.xensource.com/xen-devel</a><br>
&gt;<br>
</blockquote></div><br>

--bcaec51d276625074504b651305d--


--===============8639733458500934109==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8639733458500934109==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 09:15:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09:15:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlGku-0003qY-GY; Thu, 12 Jan 2012 09:15:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <yufang521247@gmail.com>) id 1RlGkt-0003qS-Je
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:15:32 +0000
X-Env-Sender: yufang521247@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326359678!48259195!1
X-Originating-IP: [209.85.212.43]
X-SpamReason: No, hits=2.0 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,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 28467 invoked from network); 12 Jan 2012 09:14:39 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 09:14:39 -0000
Received: by vbbfa15 with SMTP id fa15so1080118vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 01:15:23 -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=lsa4k/XOjZpKlTHUjz54Rdd7hXrqjd0vZl2ba9LXfDE=;
	b=hv64LaYgHxv9rG/Ij+w3f7AJBzekXxbRlC4qPoBhq6iT5GER8R+UdwubGVBASXBrnK
	xqAQUYPteSNHuxQH81/Pl3PkPYtdYBWd+7vpH0VPLL7WIzd7JI/3CIz8CnZ2d3+wy1Wh
	oHrlkhHKoKXN4s1g/dpOvhnqXBVMG8EpjOd8A=
MIME-Version: 1.0
Received: by 10.52.32.163 with SMTP id k3mr1314179vdi.35.1326359723181; Thu,
	12 Jan 2012 01:15:23 -0800 (PST)
Received: by 10.52.171.45 with HTTP; Thu, 12 Jan 2012 01:15:23 -0800 (PST)
In-Reply-To: <CAFLBxZbtqJ9sFPnDTVxioZodWEydiZVjOV_iXDsBksm9WdxWgQ@mail.gmail.com>
References: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
	<CAFLBxZbtqJ9sFPnDTVxioZodWEydiZVjOV_iXDsBksm9WdxWgQ@mail.gmail.com>
Date: Thu, 12 Jan 2012 17:15:23 +0800
Message-ID: <CAPWDu3r0FcEd+jGEL3HD+obePgSc9sF6Qa4q1azj4SpsRHq4Uw@mail.gmail.com>
From: Yufang Zhang <yufang521247@gmail.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Cannot start up HVM guest when maxmem is not equal
 to memory and HAP is enabled.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8639733458500934109=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8639733458500934109==
Content-Type: multipart/alternative; boundary=bcaec51d276625074504b651305d

--bcaec51d276625074504b651305d
Content-Type: text/plain; charset=ISO-8859-1

2012/1/11 George Dunlap <George.Dunlap@eu.citrix.com>

> On Wed, Jan 11, 2012 at 8:03 AM, Yufang Zhang <yufang521247@gmail.com>
> wrote:
> > Hi all,
> >
> > On my production deployment with xen-3.4.4-rc1, HVM guest would not
> start up
> > when maxmem is set not equal to memory, unless HAP is disable(hap=0). The
> > guest just hangs at 'Booting from Hard Disk...' as shown in the
> attachment.
>
> Is there a reason you want to set maxmem != memory?  Starting in 4.0,
> this will cause the VM to boot in "populate-on-demand" mode; but I
> think in 3.4, this may have undefined behavior.
>
>
Actually, you would be exposed to this problem whenever you restart xend
and then reboot the hvm guest, even you set  maxmem == memory in the config
file of that guest. When xend is restarted, it tries to recreate guest
information. memory_dynamic_max and memory_static_max, which are used
to calculate memory and maxmem, are re-calculated from mem_kb and maxmem_kb
respectively.  mem_kb is not equal to maxmem_kb. Thus memory != maxmem
after xend restarts, and rebooting this hvm guest later would leads guest
crash/hang.

> I find that both Oracle VM and Fedora have the same problem per the
> > following links:
> >
> > http://docs.oracle.com/cd/E15458_01/doc.22/e15443/toc.htm#BABBIBFD
> > http://docs.oracle.com/cd/E26996_01/e18546/CJAGDAGB.html#id419003
> > https://bugzilla.redhat.com/show_bug.cgi?id=645319
> >
> > Could I ask if there is any work in upstream/xen-unstable to fix this
> > problem?
>
> Setting maxmem != memory in 4.1 will definitely have a different
> effect -- if your guest has a balloon driver, you will start your VM
> "pre-ballooned"; if your guest does not, it will crash as soon as it
> dirties more than "memory" amount of memory.
>
>  -George


I check the xend code of xen-unstable,  the related logic didn't change
since xen-3.4. So I *guess* a hvm guest without balloon driver would crash
after some time(when it dirties enough memory) after you restarting xend
and rebooting the guest on xen-4.1.

>
> > Thanks.
> >
> > Below is the xm dmesg output related with the hvm guest:
> > (XEN) HVM3: HVM Loader
> > (XEN) HVM3: Detected Xen v3.4.4-rc1-pre
> > (XEN) HVM3: CPU speed is 2267 MHz
> > (XEN) irq.c:243: Dom3 PCI link 0 changed 0 -> 5
> > (XEN) HVM3: PCI-ISA link 0 routed to IRQ5
> > (XEN) irq.c:243: Dom3 PCI link 1 changed 0 -> 10
> > (XEN) HVM3: PCI-ISA link 1 routed to IRQ10
> > (XEN) irq.c:243: Dom3 PCI link 2 changed 0 -> 11
> > (XEN) HVM3: PCI-ISA link 2 routed to IRQ11
> > (XEN) irq.c:243: Dom3 PCI link 3 changed 0 -> 5
> > (XEN) HVM3: PCI-ISA link 3 routed to IRQ5
> > (XEN) HVM3: pci dev 01:2 INTD->IRQ5
> > (XEN) HVM3: pci dev 01:3 INTA->IRQ10
> > (XEN) HVM3: pci dev 03:0 INTA->IRQ5
> > (XEN) HVM3: pci dev 04:0 INTA->IRQ5
> > (XEN) HVM3: pci dev 02:0 bar 10 size 02000000: f0000008
> > (XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008
> > (XEN) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000
> > (XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001
> > (XEN) HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101
> > (XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000
> > (XEN) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201
> > (XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c221
> > (XEN) HVM3: Multiprocessor initialisation:
> > (XEN) HVM3:  - CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2/8]
> ...
> > done.
> > (XEN) HVM3: Writing SMBIOS tables ...
> > (XEN) HVM3: Loading ROMBIOS ...
> > (XEN) HVM3: 10332 bytes of ROMBIOS high-memory extensions:
> > (XEN) HVM3:   Relocating to 0xfc000000-0xfc00285c ... done
> > (XEN) HVM3: Creating MP tables ...
> > (XEN) HVM3: Loading Cirrus VGABIOS ...
> > (XEN) HVM3: Loading PCI Option ROM ...
> > (XEN) HVM3:  - Manufacturer: http://etherboot.org
> > (XEN) HVM3:  - Product name: gPXE
> > (XEN) HVM3: Loading ACPI ...
> > (XEN) HVM3:  - Lo data: 000ea020-000ea04f
> > (XEN) HVM3:  - Hi data: fc002c00-fc0060bf
> > (XEN) HVM3: vm86 TSS at fc006400
> > (XEN) HVM3: BIOS map:
> > (XEN) HVM3:  c0000-c8fff: VGA BIOS
> > (XEN) HVM3:  c9000-d57ff: Etherboot ROM
> > (XEN) HVM3:  eb000-eb150: SMBIOS tables
> > (XEN) HVM3:  f0000-fffff: Main BIOS
> > (XEN) HVM3: Invoking ROMBIOS ...
> > (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> > (XEN) stdvga.c:147:d3 entering stdvga and caching modes
> > (XEN) HVM3: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert
> Exp $
> > (XEN) HVM3: Bochs BIOS - build: 06/23/99
> > (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> > (XEN) HVM3: Options: apmbios pcibios eltorito PMM
> > (XEN) HVM3:
> > (XEN) HVM3: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63
> > (XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)
> > (XEN) HVM3: IDE time out
> > (XEN) HVM3:
> > (XEN) HVM3:
> > (XEN) HVM3:
> > (XEN) HVM3: Press F12 for boot menu.
> > (XEN) HVM3:
> > (XEN) HVM3: Booting from Hard Disk...
> > (XEN) HVM3: Booting from 0000:7c00
> > (XEN) io.c:199:d3 MMIO emulation failed @ 0008:4013b1: 90 86 95 21 08 83
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
>

--bcaec51d276625074504b651305d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2012/1/11 George Dunlap <span dir=3D"ltr=
">&lt;<a href=3D"mailto:George.Dunlap@eu.citrix.com" target=3D"_blank">Geor=
ge.Dunlap@eu.citrix.com</a>&gt;</span><br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Wed, Jan 11, 2012 at 8:03 AM, Yufang Zhang &lt;<a href=3D"mailto:yu=
fang521247@gmail.com" target=3D"_blank">yufang521247@gmail.com</a>&gt; wrot=
e:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; On my production deployment with xen-3.4.4-rc1, HVM guest would not st=
art up<br>
&gt; when maxmem is set not equal to memory, unless=A0HAP is disable(hap=3D=
0). The<br>
&gt; guest just hangs at &#39;Booting from Hard Disk...&#39; as shown in th=
e attachment.<br>
<br>
</div>Is there a reason you want to set maxmem !=3D memory? =A0Starting in =
4.0,<br>
this will cause the VM to boot in &quot;populate-on-demand&quot; mode; but =
I<br>
think in 3.4, this may have undefined behavior.<br>
<div><br></div></blockquote><div><br></div><div>Actually, you would be expo=
sed to this problem whenever you restart xend and then reboot the hvm guest=
, even you set =A0maxmem =3D=3D memory in the config file of that guest. Wh=
en xend is restarted, it tries to recreate guest information.=A0memory_dyna=
mic_max and=A0memory_static_max, which are used to=A0calculate memory and m=
axmem,=A0are re-calculated=A0from=A0mem_kb and=A0maxmem_kb respectively.=A0=
=A0mem_kb is not equal to=A0maxmem_kb.=A0Thus memory !=3D maxmem after xend=
 restarts, and rebooting this hvm guest later would leads guest crash/hang.=
 =A0=A0</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div>
&gt; I find that both Oracle VM and Fedora have the same problem per the<br=
>
&gt; following links:<br>
&gt;<br>
&gt; <a href=3D"http://docs.oracle.com/cd/E15458_01/doc.22/e15443/toc.htm#B=
ABBIBFD" target=3D"_blank">http://docs.oracle.com/cd/E15458_01/doc.22/e1544=
3/toc.htm#BABBIBFD</a><br>
&gt; <a href=3D"http://docs.oracle.com/cd/E26996_01/e18546/CJAGDAGB.html#id=
419003" target=3D"_blank">http://docs.oracle.com/cd/E26996_01/e18546/CJAGDA=
GB.html#id419003</a><br>
&gt; <a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D645319" targe=
t=3D"_blank">https://bugzilla.redhat.com/show_bug.cgi?id=3D645319</a><br>
&gt;<br>
&gt; Could I ask if there is any work in upstream/xen-unstable to fix this<=
br>
&gt; problem?<br>
<br>
</div>Setting maxmem !=3D memory in 4.1 will definitely have a different<br=
>
effect -- if your guest has a balloon driver, you will start your VM<br>
&quot;pre-ballooned&quot;; if your guest does not, it will crash as soon as=
 it<br>
dirties more than &quot;memory&quot; amount of memory.<br>
<br>
=A0-George</blockquote><div><br></div><div>I check the xend code of xen-uns=
table, =A0the related logic didn&#39;t change since xen-3.4. So I *guess* a=
 hvm guest without balloon driver would crash after some time(when it=A0dir=
ties enough memory) after you restarting xend and rebooting the guest on xe=
n-4.1.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div><div>
&gt;<br>
&gt; Thanks.<br>
&gt;<br>
&gt; Below is the xm dmesg output related with the hvm guest:<br>
&gt; (XEN) HVM3: HVM Loader<br>
&gt; (XEN) HVM3: Detected Xen v3.4.4-rc1-pre<br>
&gt; (XEN) HVM3: CPU speed is 2267 MHz<br>
&gt; (XEN) irq.c:243: Dom3 PCI link 0 changed 0 -&gt; 5<br>
&gt; (XEN) HVM3: PCI-ISA link 0 routed to IRQ5<br>
&gt; (XEN) irq.c:243: Dom3 PCI link 1 changed 0 -&gt; 10<br>
&gt; (XEN) HVM3: PCI-ISA link 1 routed to IRQ10<br>
&gt; (XEN) irq.c:243: Dom3 PCI link 2 changed 0 -&gt; 11<br>
&gt; (XEN) HVM3: PCI-ISA link 2 routed to IRQ11<br>
&gt; (XEN) irq.c:243: Dom3 PCI link 3 changed 0 -&gt; 5<br>
&gt; (XEN) HVM3: PCI-ISA link 3 routed to IRQ5<br>
&gt; (XEN) HVM3: pci dev 01:2 INTD-&gt;IRQ5<br>
&gt; (XEN) HVM3: pci dev 01:3 INTA-&gt;IRQ10<br>
&gt; (XEN) HVM3: pci dev 03:0 INTA-&gt;IRQ5<br>
&gt; (XEN) HVM3: pci dev 04:0 INTA-&gt;IRQ5<br>
&gt; (XEN) HVM3: pci dev 02:0 bar 10 size 02000000: f0000008<br>
&gt; (XEN) HVM3: pci dev 03:0 bar 14 size 01000000: f2000008<br>
&gt; (XEN) HVM3: pci dev 02:0 bar 14 size 00001000: f3000000<br>
&gt; (XEN) HVM3: pci dev 03:0 bar 10 size 00000100: 0000c001<br>
&gt; (XEN) HVM3: pci dev 04:0 bar 10 size 00000100: 0000c101<br>
&gt; (XEN) HVM3: pci dev 04:0 bar 14 size 00000100: f3001000<br>
&gt; (XEN) HVM3: pci dev 01:2 bar 20 size 00000020: 0000c201<br>
&gt; (XEN) HVM3: pci dev 01:1 bar 20 size 00000010: 0000c221<br>
&gt; (XEN) HVM3: Multiprocessor initialisation:<br>
&gt; (XEN) HVM3: =A0- CPU0 ... 40-bit phys ... fixed MTRRs ... var MTRRs [2=
/8] ...<br>
&gt; done.<br>
&gt; (XEN) HVM3: Writing SMBIOS tables ...<br>
&gt; (XEN) HVM3: Loading ROMBIOS ...<br>
&gt; (XEN) HVM3: 10332 bytes of ROMBIOS high-memory extensions:<br>
&gt; (XEN) HVM3: =A0 Relocating to 0xfc000000-0xfc00285c ... done<br>
&gt; (XEN) HVM3: Creating MP tables ...<br>
&gt; (XEN) HVM3: Loading Cirrus VGABIOS ...<br>
&gt; (XEN) HVM3: Loading PCI Option ROM ...<br>
&gt; (XEN) HVM3: =A0- Manufacturer: <a href=3D"http://etherboot.org" target=
=3D"_blank">http://etherboot.org</a><br>
&gt; (XEN) HVM3: =A0- Product name: gPXE<br>
&gt; (XEN) HVM3: Loading ACPI ...<br>
&gt; (XEN) HVM3: =A0- Lo data: 000ea020-000ea04f<br>
&gt; (XEN) HVM3: =A0- Hi data: fc002c00-fc0060bf<br>
&gt; (XEN) HVM3: vm86 TSS at fc006400<br>
&gt; (XEN) HVM3: BIOS map:<br>
&gt; (XEN) HVM3: =A0c0000-c8fff: VGA BIOS<br>
&gt; (XEN) HVM3: =A0c9000-d57ff: Etherboot ROM<br>
&gt; (XEN) HVM3: =A0eb000-eb150: SMBIOS tables<br>
&gt; (XEN) HVM3: =A0f0000-fffff: Main BIOS<br>
&gt; (XEN) HVM3: Invoking ROMBIOS ...<br>
&gt; (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $<br>
&gt; (XEN) stdvga.c:147:d3 entering stdvga and caching modes<br>
&gt; (XEN) HVM3: VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert=
 Exp $<br>
&gt; (XEN) HVM3: Bochs BIOS - build: 06/23/99<br>
&gt; (XEN) HVM3: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $<br>
&gt; (XEN) HVM3: Options: apmbios pcibios eltorito PMM<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3: ata0-0: PCHS=3D16383/16/63 translation=3Dlba LCHS=3D1024/2=
55/63<br>
&gt; (XEN) HVM3: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (8192 MBytes)<b=
r>
&gt; (XEN) HVM3: IDE time out<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3: Press F12 for boot menu.<br>
&gt; (XEN) HVM3:<br>
&gt; (XEN) HVM3: Booting from Hard Disk...<br>
&gt; (XEN) HVM3: Booting from 0000:7c00<br>
&gt; (XEN) io.c:199:d3 MMIO emulation failed @ 0008:4013b1: 90 86 95 21 08 =
83<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; Xen-devel mailing list<br>
&gt; <a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen=
-devel@lists.xensource.com</a><br>
&gt; <a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">htt=
p://lists.xensource.com/xen-devel</a><br>
&gt;<br>
</blockquote></div><br>

--bcaec51d276625074504b651305d--


--===============8639733458500934109==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8639733458500934109==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 09:50:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09: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 1RlHIJ-0004VB-Ee; Thu, 12 Jan 2012 09:50:03 +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 1RlHIH-0004V6-0h
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:50:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326361794!10611779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24148 invoked from network); 12 Jan 2012 09:49:55 -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;
	12 Jan 2012 09:49:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9964930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:49: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, 12 Jan 2012 09:49:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 12 Jan 2012 09:49:51 +0000
In-Reply-To: <4F0EADA5020000780006C053@nat28.tlf.novell.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EADA5020000780006C053@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326361791.17210.221.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries
 when switching 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 Thu, 2012-01-12 at 08:53 +0000, Jan Beulich wrote:
> >>> On 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> >      struct domain *d = current->domain;
> >      struct grant_table *gt = d->grant_table;
> >      struct active_grant_entry *act;
> > +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
> 
> How much stack space does this consume? (Or in other words, where
> does GNTTAB_NR_RESERVED_ENTRIES get defined? It's not in this
> patch, I can't find it in earlier patches, and it also doesn't exist in the
> current staging tree.)

I could have sworn I'd seen this somewhere but I can't for the life of
me find it now :-/

One place I did find it is in the Linux gnttab driver, but that's not
canonical.

Ian.

> 
> Jan
> 
> >      long res;
> >      int i;
> >  
> > @@ -2126,7 +2127,7 @@ 
> > gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> >      /* (You need to change the version number for e.g. kexec.) */
> >      if ( gt->gt_version != 0 )
> >      {
> > -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> > +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ 
> > )
> >          {
> >              act = &active_entry(gt, i);
> >              if ( act->pin != 0 )
> > @@ -2151,15 +2152,38 @@ 
> > gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> >              goto out_unlock;
> >      }
> >  
> > +    /* Preserve the first 8 entries (toolstack reserved grants) */
> > +    if (gt->gt_version == 1) {
> > +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> > +    } else if (gt->gt_version == 2) {
> > +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < 
> > nr_grant_entries(gt); i++ )
> > +        {
> > +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> > +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> > +            reserved_entries[i].frame = shared_entry_v2(gt, 
> > i).full_page.frame;
> > +            reserved_entries[i].flags |= status_entry(gt, i);
> > +        }
> > +    }
> > +
> >      if ( op.version < 2 && gt->gt_version == 2 )
> >          gnttab_unpopulate_status_frames(d, gt);
> >  
> > -    if ( op.version != gt->gt_version )
> > -    {
> > -        /* Make sure there's no crud left over in the table from the
> > -           old version. */
> > -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> > -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> > +    /* Make sure there's no crud left over in the table from the
> > +       old version. */
> > +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> > +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> > +
> > +    /* Restore the first 8 entries (toolstack reserved grants) */
> > +    if (gt->gt_version != 0 && op.version == 1) {
> > +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> > +    } else if (gt->gt_version != 0 && op.version == 2) {
> > +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> > +        {
> > +            status_entry(gt, i) = reserved_entries[i].flags & 
> > (GTF_reading|GTF_writing);
> > +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & 
> > ~(GTF_reading|GTF_writing);
> > +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> > +            shared_entry_v2(gt, i).full_page.frame = 
> > reserved_entries[i].frame;
> > +        }
> >      }
> >  
> >      gt->gt_version = op.version;
> > -- 
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com 
> > http://lists.xensource.com/xen-devel 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 09:50:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09: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 1RlHIJ-0004VB-Ee; Thu, 12 Jan 2012 09:50:03 +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 1RlHIH-0004V6-0h
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:50:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326361794!10611779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24148 invoked from network); 12 Jan 2012 09:49:55 -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;
	12 Jan 2012 09:49:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9964930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:49: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, 12 Jan 2012 09:49:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 12 Jan 2012 09:49:51 +0000
In-Reply-To: <4F0EADA5020000780006C053@nat28.tlf.novell.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EADA5020000780006C053@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326361791.17210.221.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries
 when switching 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 Thu, 2012-01-12 at 08:53 +0000, Jan Beulich wrote:
> >>> On 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> >      struct domain *d = current->domain;
> >      struct grant_table *gt = d->grant_table;
> >      struct active_grant_entry *act;
> > +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
> 
> How much stack space does this consume? (Or in other words, where
> does GNTTAB_NR_RESERVED_ENTRIES get defined? It's not in this
> patch, I can't find it in earlier patches, and it also doesn't exist in the
> current staging tree.)

I could have sworn I'd seen this somewhere but I can't for the life of
me find it now :-/

One place I did find it is in the Linux gnttab driver, but that's not
canonical.

Ian.

> 
> Jan
> 
> >      long res;
> >      int i;
> >  
> > @@ -2126,7 +2127,7 @@ 
> > gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> >      /* (You need to change the version number for e.g. kexec.) */
> >      if ( gt->gt_version != 0 )
> >      {
> > -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> > +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ 
> > )
> >          {
> >              act = &active_entry(gt, i);
> >              if ( act->pin != 0 )
> > @@ -2151,15 +2152,38 @@ 
> > gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> >              goto out_unlock;
> >      }
> >  
> > +    /* Preserve the first 8 entries (toolstack reserved grants) */
> > +    if (gt->gt_version == 1) {
> > +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> > +    } else if (gt->gt_version == 2) {
> > +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < 
> > nr_grant_entries(gt); i++ )
> > +        {
> > +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> > +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> > +            reserved_entries[i].frame = shared_entry_v2(gt, 
> > i).full_page.frame;
> > +            reserved_entries[i].flags |= status_entry(gt, i);
> > +        }
> > +    }
> > +
> >      if ( op.version < 2 && gt->gt_version == 2 )
> >          gnttab_unpopulate_status_frames(d, gt);
> >  
> > -    if ( op.version != gt->gt_version )
> > -    {
> > -        /* Make sure there's no crud left over in the table from the
> > -           old version. */
> > -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> > -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> > +    /* Make sure there's no crud left over in the table from the
> > +       old version. */
> > +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> > +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> > +
> > +    /* Restore the first 8 entries (toolstack reserved grants) */
> > +    if (gt->gt_version != 0 && op.version == 1) {
> > +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> > +    } else if (gt->gt_version != 0 && op.version == 2) {
> > +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> > +        {
> > +            status_entry(gt, i) = reserved_entries[i].flags & 
> > (GTF_reading|GTF_writing);
> > +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & 
> > ~(GTF_reading|GTF_writing);
> > +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> > +            shared_entry_v2(gt, i).full_page.frame = 
> > reserved_entries[i].frame;
> > +        }
> >      }
> >  
> >      gt->gt_version = op.version;
> > -- 
> > 1.7.7.5
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com 
> > http://lists.xensource.com/xen-devel 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 09:52:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09: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 1RlHKD-0004Zr-67; Thu, 12 Jan 2012 09:52: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 1RlHKC-0004Ze-1z
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:52:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326361913!10050439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30016 invoked from network); 12 Jan 2012 09:51:53 -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;
	12 Jan 2012 09:51:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9964976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:51:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 09:51:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 09:51:53 +0000
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326361913.17210.223.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 PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> This patch series allows xenstored to run in a stub domian started by
> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html
> 
> 
> A domain configuration for starting xenstored looks like:
> 
> kernel='/home/daniel/xen/stubdom/mini-os-x86_64-xenstore/mini-os'
> extra=''
> memory=50
> name='xenstore'
> 
> Once xenstore is started, "xenstore_dom=1" needs to be added to other
> domain's configurations in order to set up the xenstore connection to
> domain 1.

The domid should be written to xenstore so that the toolstack can pull
it back out as necessary.

> The following program handles post-creation parts of xenstored. To use
> it, run "xl create -p xenstore" and then "init-xenstore $domid". The
> running xenstored must be stopped to prevent xl using the UNIX sockets,
> and xenconsoled needs to be restarted after switching xenstores.

So the model is that you start a normal xenstored process in dom0 and
then use it to start the stub-xenstore before switching over?

How does that work wrt watches which are already registered, e.g. by
backend drivers?

I had imagined a init-xenstore.c which actually built the domain using
libxc directly from a mostly hardcoded configuration as well as
performing the necessary IOCTLs to get around the handover issue.

Ian,

> 
> /* init-xenstore.c: link with -lxenctrl */
> 
> #include <fcntl.h>
> #include <stdio.h>
> #include <string.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <sys/ioctl.h>
> #include <sys/mman.h>
> 
> #define __XEN_TOOLS__
> #include <xen/domctl.h>
> #include "xenctrl.h"
> 
> #define IOCTL_XENBUS_BACKEND_SETUP _IOC(_IOC_NONE, 'B', 1, 0)
> #define IOCTL_XENBUS_BACKEND_COMMIT _IOC(_IOC_NONE, 'B', 2, 0)
> 
> static void set_virq(int domid, int virq)
> {
> 	struct xen_domctl command;
> 	xc_interface *xch;
> 
> 	xch = xc_interface_open(NULL, NULL, 0);
> 
> 	memset(&command, 0, sizeof(command)); 
> 	command.cmd               = XEN_DOMCTL_set_virq_handler;
> 	command.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
> 	command.domain            = domid;
> 	command.u.set_virq_handler.virq = virq;
> 	xc_domctl(xch, &command);
> 	xc_interface_close(xch);
> }
> 
> int main(int argc, char** argv)
> {
> 	char buf[512];
> 	int domid = atoi(argv[1]);
> 
> 	set_virq(domid, VIRQ_DOM_EXC);
> 
> 	int fd = open("/dev/xen/xenbus_backend", O_RDWR);
> 	void *map = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> 	int rv = ioctl(fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
> 	*(uint16_t*)(map + 0x810) = rv;
> 	snprintf(buf, 512, "xl unpause %d", domid);
> 	system(buf);
> 	ioctl(fd, IOCTL_XENBUS_BACKEND_COMMIT, 0);
> 	return 0;
> }
> 
> -------------------------------------------------
> 
> Dom0 kernel changes:
>     [PATCH] xenbus: Add support for xenbus backend in stub domain
> 
> This is based on the new /dev/xen devices introduced in Linux 3.3.
> 
> Hypervisor changes:
>     [PATCH 01/18] xen: reinstate previously unused
>     [PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
>     [PATCH 03/18] xsm: allow use of XEN_DOMCTL_getdomaininfo by
>     [PATCH 04/18] xen: Preserve reserved grant entries when switching
> 
> Patch 1 & 4 are required for setting up grant entries in new domains.
> Patch 2 & 3 allow xenstored to run in an unprivileged domain. This
> currently requires XSM to be enabled to avoid allowing all domUs access
> to XEN_DOMCTL_getdomaininfo, so the patch only allows this hypercall if
> XSM is being compiled in.
> 
> Toolstack changes:
>     [PATCH 05/18] tools/libxl: Add xenstore and console backend domain
>     [PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and
> 
> These patches populate two of the eight reserved grant entries in new
> domains with the xenstore and console shared pages, which is required
> if xenstored is not run in a privileged domain.
> 
> Minios and xenstored:
>     [PATCH 07/18] mini-os: avoid crash if no console is provided
>     [PATCH 08/18] mini-os: avoid crash if no xenstore is provided
>     [PATCH 09/18] mini-os: remove per-fd evtchn limit
>     [PATCH 10/18] xenstored: use grant references instead of
>     [PATCH 11/18] xenstored: add NO_SOCKETS compilation option
>     [PATCH 12/18] xenstored support for in-memory rather than FS based
>     [PATCH 13/18] xenstored: support running in minios stubdom
>     [PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
>     [PATCH 15/18] xenstored: add --event parameter for bootstrapping
>     [PATCH 16/18] xenstored: pull dom0 event port from shared page
>     [PATCH 17/18] xenstored: use domain_is_unprivileged instead of
>     [PATCH 18/18] xenstored: add --priv-domid parameter
> 
> Support for running in a stub domain
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 09:52:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09: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 1RlHKD-0004Zr-67; Thu, 12 Jan 2012 09:52: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 1RlHKC-0004Ze-1z
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:52:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326361913!10050439!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30016 invoked from network); 12 Jan 2012 09:51:53 -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;
	12 Jan 2012 09:51:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9964976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:51:53 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 09:51:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 09:51:53 +0000
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326361913.17210.223.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 PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> This patch series allows xenstored to run in a stub domian started by
> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html
> 
> 
> A domain configuration for starting xenstored looks like:
> 
> kernel='/home/daniel/xen/stubdom/mini-os-x86_64-xenstore/mini-os'
> extra=''
> memory=50
> name='xenstore'
> 
> Once xenstore is started, "xenstore_dom=1" needs to be added to other
> domain's configurations in order to set up the xenstore connection to
> domain 1.

The domid should be written to xenstore so that the toolstack can pull
it back out as necessary.

> The following program handles post-creation parts of xenstored. To use
> it, run "xl create -p xenstore" and then "init-xenstore $domid". The
> running xenstored must be stopped to prevent xl using the UNIX sockets,
> and xenconsoled needs to be restarted after switching xenstores.

So the model is that you start a normal xenstored process in dom0 and
then use it to start the stub-xenstore before switching over?

How does that work wrt watches which are already registered, e.g. by
backend drivers?

I had imagined a init-xenstore.c which actually built the domain using
libxc directly from a mostly hardcoded configuration as well as
performing the necessary IOCTLs to get around the handover issue.

Ian,

> 
> /* init-xenstore.c: link with -lxenctrl */
> 
> #include <fcntl.h>
> #include <stdio.h>
> #include <string.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <sys/ioctl.h>
> #include <sys/mman.h>
> 
> #define __XEN_TOOLS__
> #include <xen/domctl.h>
> #include "xenctrl.h"
> 
> #define IOCTL_XENBUS_BACKEND_SETUP _IOC(_IOC_NONE, 'B', 1, 0)
> #define IOCTL_XENBUS_BACKEND_COMMIT _IOC(_IOC_NONE, 'B', 2, 0)
> 
> static void set_virq(int domid, int virq)
> {
> 	struct xen_domctl command;
> 	xc_interface *xch;
> 
> 	xch = xc_interface_open(NULL, NULL, 0);
> 
> 	memset(&command, 0, sizeof(command)); 
> 	command.cmd               = XEN_DOMCTL_set_virq_handler;
> 	command.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
> 	command.domain            = domid;
> 	command.u.set_virq_handler.virq = virq;
> 	xc_domctl(xch, &command);
> 	xc_interface_close(xch);
> }
> 
> int main(int argc, char** argv)
> {
> 	char buf[512];
> 	int domid = atoi(argv[1]);
> 
> 	set_virq(domid, VIRQ_DOM_EXC);
> 
> 	int fd = open("/dev/xen/xenbus_backend", O_RDWR);
> 	void *map = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> 	int rv = ioctl(fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
> 	*(uint16_t*)(map + 0x810) = rv;
> 	snprintf(buf, 512, "xl unpause %d", domid);
> 	system(buf);
> 	ioctl(fd, IOCTL_XENBUS_BACKEND_COMMIT, 0);
> 	return 0;
> }
> 
> -------------------------------------------------
> 
> Dom0 kernel changes:
>     [PATCH] xenbus: Add support for xenbus backend in stub domain
> 
> This is based on the new /dev/xen devices introduced in Linux 3.3.
> 
> Hypervisor changes:
>     [PATCH 01/18] xen: reinstate previously unused
>     [PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
>     [PATCH 03/18] xsm: allow use of XEN_DOMCTL_getdomaininfo by
>     [PATCH 04/18] xen: Preserve reserved grant entries when switching
> 
> Patch 1 & 4 are required for setting up grant entries in new domains.
> Patch 2 & 3 allow xenstored to run in an unprivileged domain. This
> currently requires XSM to be enabled to avoid allowing all domUs access
> to XEN_DOMCTL_getdomaininfo, so the patch only allows this hypercall if
> XSM is being compiled in.
> 
> Toolstack changes:
>     [PATCH 05/18] tools/libxl: Add xenstore and console backend domain
>     [PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and
> 
> These patches populate two of the eight reserved grant entries in new
> domains with the xenstore and console shared pages, which is required
> if xenstored is not run in a privileged domain.
> 
> Minios and xenstored:
>     [PATCH 07/18] mini-os: avoid crash if no console is provided
>     [PATCH 08/18] mini-os: avoid crash if no xenstore is provided
>     [PATCH 09/18] mini-os: remove per-fd evtchn limit
>     [PATCH 10/18] xenstored: use grant references instead of
>     [PATCH 11/18] xenstored: add NO_SOCKETS compilation option
>     [PATCH 12/18] xenstored support for in-memory rather than FS based
>     [PATCH 13/18] xenstored: support running in minios stubdom
>     [PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
>     [PATCH 15/18] xenstored: add --event parameter for bootstrapping
>     [PATCH 16/18] xenstored: pull dom0 event port from shared page
>     [PATCH 17/18] xenstored: use domain_is_unprivileged instead of
>     [PATCH 18/18] xenstored: add --priv-domid parameter
> 
> Support for running in a stub domain
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 09:56:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHOI-0004lE-Ec; Thu, 12 Jan 2012 09:56:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlHOH-0004l6-G5
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:56:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326362107!60655858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32155 invoked from network); 12 Jan 2012 09:55:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 09:55:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:56:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 09:56:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 12 Jan 2012 09:56:11 +0000
In-Reply-To: <1326361791.17210.221.camel@zakaz.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EADA5020000780006C053@nat28.tlf.novell.com>
	<1326361791.17210.221.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362172.17210.224.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries
 when switching 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 Thu, 2012-01-12 at 09:49 +0000, Ian Campbell wrote:
> On Thu, 2012-01-12 at 08:53 +0000, Jan Beulich wrote:
> > >>> On 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> > > --- a/xen/common/grant_table.c
> > > +++ b/xen/common/grant_table.c
> > > @@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> > >      struct domain *d = current->domain;
> > >      struct grant_table *gt = d->grant_table;
> > >      struct active_grant_entry *act;
> > > +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
> > 
> > How much stack space does this consume? (Or in other words, where
> > does GNTTAB_NR_RESERVED_ENTRIES get defined? It's not in this
> > patch, I can't find it in earlier patches, and it also doesn't exist in the
> > current staging tree.)
> 
> I could have sworn I'd seen this somewhere but I can't for the life of
> me find it now :-/

Found it in patch #6.

+/* External tools reserve first few grant table entries. */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+/* (the next 6 are reserved for future use) */

These patches need to be reordered to make sure each step builds.

Ian.

> 
> One place I did find it is in the Linux gnttab driver, but that's not
> canonical.
> 
> Ian.
> 
> > 
> > Jan
> > 
> > >      long res;
> > >      int i;
> > >  
> > > @@ -2126,7 +2127,7 @@ 
> > > gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> > >      /* (You need to change the version number for e.g. kexec.) */
> > >      if ( gt->gt_version != 0 )
> > >      {
> > > -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> > > +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ 
> > > )
> > >          {
> > >              act = &active_entry(gt, i);
> > >              if ( act->pin != 0 )
> > > @@ -2151,15 +2152,38 @@ 
> > > gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> > >              goto out_unlock;
> > >      }
> > >  
> > > +    /* Preserve the first 8 entries (toolstack reserved grants) */
> > > +    if (gt->gt_version == 1) {
> > > +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> > > +    } else if (gt->gt_version == 2) {
> > > +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < 
> > > nr_grant_entries(gt); i++ )
> > > +        {
> > > +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> > > +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> > > +            reserved_entries[i].frame = shared_entry_v2(gt, 
> > > i).full_page.frame;
> > > +            reserved_entries[i].flags |= status_entry(gt, i);
> > > +        }
> > > +    }
> > > +
> > >      if ( op.version < 2 && gt->gt_version == 2 )
> > >          gnttab_unpopulate_status_frames(d, gt);
> > >  
> > > -    if ( op.version != gt->gt_version )
> > > -    {
> > > -        /* Make sure there's no crud left over in the table from the
> > > -           old version. */
> > > -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> > > -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> > > +    /* Make sure there's no crud left over in the table from the
> > > +       old version. */
> > > +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> > > +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> > > +
> > > +    /* Restore the first 8 entries (toolstack reserved grants) */
> > > +    if (gt->gt_version != 0 && op.version == 1) {
> > > +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> > > +    } else if (gt->gt_version != 0 && op.version == 2) {
> > > +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> > > +        {
> > > +            status_entry(gt, i) = reserved_entries[i].flags & 
> > > (GTF_reading|GTF_writing);
> > > +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & 
> > > ~(GTF_reading|GTF_writing);
> > > +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> > > +            shared_entry_v2(gt, i).full_page.frame = 
> > > reserved_entries[i].frame;
> > > +        }
> > >      }
> > >  
> > >      gt->gt_version = op.version;
> > > -- 
> > > 1.7.7.5
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com 
> > > http://lists.xensource.com/xen-devel 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 09:56:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHOI-0004lE-Ec; Thu, 12 Jan 2012 09:56:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlHOH-0004l6-G5
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:56:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326362107!60655858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32155 invoked from network); 12 Jan 2012 09:55:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 09:55:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:56:12 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 09:56:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 12 Jan 2012 09:56:11 +0000
In-Reply-To: <1326361791.17210.221.camel@zakaz.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-5-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EADA5020000780006C053@nat28.tlf.novell.com>
	<1326361791.17210.221.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362172.17210.224.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries
 when switching 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 Thu, 2012-01-12 at 09:49 +0000, Ian Campbell wrote:
> On Thu, 2012-01-12 at 08:53 +0000, Jan Beulich wrote:
> > >>> On 11.01.12 at 18:21, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> > > --- a/xen/common/grant_table.c
> > > +++ b/xen/common/grant_table.c
> > > @@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> > >      struct domain *d = current->domain;
> > >      struct grant_table *gt = d->grant_table;
> > >      struct active_grant_entry *act;
> > > +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
> > 
> > How much stack space does this consume? (Or in other words, where
> > does GNTTAB_NR_RESERVED_ENTRIES get defined? It's not in this
> > patch, I can't find it in earlier patches, and it also doesn't exist in the
> > current staging tree.)
> 
> I could have sworn I'd seen this somewhere but I can't for the life of
> me find it now :-/

Found it in patch #6.

+/* External tools reserve first few grant table entries. */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+/* (the next 6 are reserved for future use) */

These patches need to be reordered to make sure each step builds.

Ian.

> 
> One place I did find it is in the Linux gnttab driver, but that's not
> canonical.
> 
> Ian.
> 
> > 
> > Jan
> > 
> > >      long res;
> > >      int i;
> > >  
> > > @@ -2126,7 +2127,7 @@ 
> > > gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> > >      /* (You need to change the version number for e.g. kexec.) */
> > >      if ( gt->gt_version != 0 )
> > >      {
> > > -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> > > +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ 
> > > )
> > >          {
> > >              act = &active_entry(gt, i);
> > >              if ( act->pin != 0 )
> > > @@ -2151,15 +2152,38 @@ 
> > > gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
> > >              goto out_unlock;
> > >      }
> > >  
> > > +    /* Preserve the first 8 entries (toolstack reserved grants) */
> > > +    if (gt->gt_version == 1) {
> > > +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> > > +    } else if (gt->gt_version == 2) {
> > > +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < 
> > > nr_grant_entries(gt); i++ )
> > > +        {
> > > +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> > > +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> > > +            reserved_entries[i].frame = shared_entry_v2(gt, 
> > > i).full_page.frame;
> > > +            reserved_entries[i].flags |= status_entry(gt, i);
> > > +        }
> > > +    }
> > > +
> > >      if ( op.version < 2 && gt->gt_version == 2 )
> > >          gnttab_unpopulate_status_frames(d, gt);
> > >  
> > > -    if ( op.version != gt->gt_version )
> > > -    {
> > > -        /* Make sure there's no crud left over in the table from the
> > > -           old version. */
> > > -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> > > -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> > > +    /* Make sure there's no crud left over in the table from the
> > > +       old version. */
> > > +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> > > +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> > > +
> > > +    /* Restore the first 8 entries (toolstack reserved grants) */
> > > +    if (gt->gt_version != 0 && op.version == 1) {
> > > +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> > > +    } else if (gt->gt_version != 0 && op.version == 2) {
> > > +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> > > +        {
> > > +            status_entry(gt, i) = reserved_entries[i].flags & 
> > > (GTF_reading|GTF_writing);
> > > +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & 
> > > ~(GTF_reading|GTF_writing);
> > > +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> > > +            shared_entry_v2(gt, i).full_page.frame = 
> > > reserved_entries[i].frame;
> > > +        }
> > >      }
> > >  
> > >      gt->gt_version = op.version;
> > > -- 
> > > 1.7.7.5
> > > 
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com 
> > > http://lists.xensource.com/xen-devel 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 09:58:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHQ2-0004uR-58; Thu, 12 Jan 2012 09:58:02 +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 1RlHQ0-0004tn-F2
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:58:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326362274!10051184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11688 invoked from network); 12 Jan 2012 09:57:54 -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 Jan 2012 09:57:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:57:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 09:57:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 09:57:53 +0000
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362273.17210.225.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 PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> This patch series allows xenstored to run in a stub domian started by
> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html

BTW did you come across any patches for stub-oxenstored while you were
doing this? I thought there had been such at some point in the past.

Ian.

> 
> 
> A domain configuration for starting xenstored looks like:
> 
> kernel='/home/daniel/xen/stubdom/mini-os-x86_64-xenstore/mini-os'
> extra=''
> memory=50
> name='xenstore'
> 
> Once xenstore is started, "xenstore_dom=1" needs to be added to other
> domain's configurations in order to set up the xenstore connection to
> domain 1.
> 
> The following program handles post-creation parts of xenstored. To use
> it, run "xl create -p xenstore" and then "init-xenstore $domid". The
> running xenstored must be stopped to prevent xl using the UNIX sockets,
> and xenconsoled needs to be restarted after switching xenstores.
> 
> /* init-xenstore.c: link with -lxenctrl */
> 
> #include <fcntl.h>
> #include <stdio.h>
> #include <string.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <sys/ioctl.h>
> #include <sys/mman.h>
> 
> #define __XEN_TOOLS__
> #include <xen/domctl.h>
> #include "xenctrl.h"
> 
> #define IOCTL_XENBUS_BACKEND_SETUP _IOC(_IOC_NONE, 'B', 1, 0)
> #define IOCTL_XENBUS_BACKEND_COMMIT _IOC(_IOC_NONE, 'B', 2, 0)
> 
> static void set_virq(int domid, int virq)
> {
> 	struct xen_domctl command;
> 	xc_interface *xch;
> 
> 	xch = xc_interface_open(NULL, NULL, 0);
> 
> 	memset(&command, 0, sizeof(command)); 
> 	command.cmd               = XEN_DOMCTL_set_virq_handler;
> 	command.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
> 	command.domain            = domid;
> 	command.u.set_virq_handler.virq = virq;
> 	xc_domctl(xch, &command);
> 	xc_interface_close(xch);
> }
> 
> int main(int argc, char** argv)
> {
> 	char buf[512];
> 	int domid = atoi(argv[1]);
> 
> 	set_virq(domid, VIRQ_DOM_EXC);
> 
> 	int fd = open("/dev/xen/xenbus_backend", O_RDWR);
> 	void *map = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> 	int rv = ioctl(fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
> 	*(uint16_t*)(map + 0x810) = rv;
> 	snprintf(buf, 512, "xl unpause %d", domid);
> 	system(buf);
> 	ioctl(fd, IOCTL_XENBUS_BACKEND_COMMIT, 0);
> 	return 0;
> }
> 
> -------------------------------------------------
> 
> Dom0 kernel changes:
>     [PATCH] xenbus: Add support for xenbus backend in stub domain
> 
> This is based on the new /dev/xen devices introduced in Linux 3.3.
> 
> Hypervisor changes:
>     [PATCH 01/18] xen: reinstate previously unused
>     [PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
>     [PATCH 03/18] xsm: allow use of XEN_DOMCTL_getdomaininfo by
>     [PATCH 04/18] xen: Preserve reserved grant entries when switching
> 
> Patch 1 & 4 are required for setting up grant entries in new domains.
> Patch 2 & 3 allow xenstored to run in an unprivileged domain. This
> currently requires XSM to be enabled to avoid allowing all domUs access
> to XEN_DOMCTL_getdomaininfo, so the patch only allows this hypercall if
> XSM is being compiled in.
> 
> Toolstack changes:
>     [PATCH 05/18] tools/libxl: Add xenstore and console backend domain
>     [PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and
> 
> These patches populate two of the eight reserved grant entries in new
> domains with the xenstore and console shared pages, which is required
> if xenstored is not run in a privileged domain.
> 
> Minios and xenstored:
>     [PATCH 07/18] mini-os: avoid crash if no console is provided
>     [PATCH 08/18] mini-os: avoid crash if no xenstore is provided
>     [PATCH 09/18] mini-os: remove per-fd evtchn limit
>     [PATCH 10/18] xenstored: use grant references instead of
>     [PATCH 11/18] xenstored: add NO_SOCKETS compilation option
>     [PATCH 12/18] xenstored support for in-memory rather than FS based
>     [PATCH 13/18] xenstored: support running in minios stubdom
>     [PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
>     [PATCH 15/18] xenstored: add --event parameter for bootstrapping
>     [PATCH 16/18] xenstored: pull dom0 event port from shared page
>     [PATCH 17/18] xenstored: use domain_is_unprivileged instead of
>     [PATCH 18/18] xenstored: add --priv-domid parameter
> 
> Support for running in a stub domain
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 09:58:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 09:58:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHQ2-0004uR-58; Thu, 12 Jan 2012 09:58:02 +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 1RlHQ0-0004tn-F2
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 09:58:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326362274!10051184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11688 invoked from network); 12 Jan 2012 09:57:54 -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 Jan 2012 09:57:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965137"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:57:54 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 09:57:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 09:57:53 +0000
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362273.17210.225.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 PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> This patch series allows xenstored to run in a stub domian started by
> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html

BTW did you come across any patches for stub-oxenstored while you were
doing this? I thought there had been such at some point in the past.

Ian.

> 
> 
> A domain configuration for starting xenstored looks like:
> 
> kernel='/home/daniel/xen/stubdom/mini-os-x86_64-xenstore/mini-os'
> extra=''
> memory=50
> name='xenstore'
> 
> Once xenstore is started, "xenstore_dom=1" needs to be added to other
> domain's configurations in order to set up the xenstore connection to
> domain 1.
> 
> The following program handles post-creation parts of xenstored. To use
> it, run "xl create -p xenstore" and then "init-xenstore $domid". The
> running xenstored must be stopped to prevent xl using the UNIX sockets,
> and xenconsoled needs to be restarted after switching xenstores.
> 
> /* init-xenstore.c: link with -lxenctrl */
> 
> #include <fcntl.h>
> #include <stdio.h>
> #include <string.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <sys/ioctl.h>
> #include <sys/mman.h>
> 
> #define __XEN_TOOLS__
> #include <xen/domctl.h>
> #include "xenctrl.h"
> 
> #define IOCTL_XENBUS_BACKEND_SETUP _IOC(_IOC_NONE, 'B', 1, 0)
> #define IOCTL_XENBUS_BACKEND_COMMIT _IOC(_IOC_NONE, 'B', 2, 0)
> 
> static void set_virq(int domid, int virq)
> {
> 	struct xen_domctl command;
> 	xc_interface *xch;
> 
> 	xch = xc_interface_open(NULL, NULL, 0);
> 
> 	memset(&command, 0, sizeof(command)); 
> 	command.cmd               = XEN_DOMCTL_set_virq_handler;
> 	command.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
> 	command.domain            = domid;
> 	command.u.set_virq_handler.virq = virq;
> 	xc_domctl(xch, &command);
> 	xc_interface_close(xch);
> }
> 
> int main(int argc, char** argv)
> {
> 	char buf[512];
> 	int domid = atoi(argv[1]);
> 
> 	set_virq(domid, VIRQ_DOM_EXC);
> 
> 	int fd = open("/dev/xen/xenbus_backend", O_RDWR);
> 	void *map = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> 	int rv = ioctl(fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
> 	*(uint16_t*)(map + 0x810) = rv;
> 	snprintf(buf, 512, "xl unpause %d", domid);
> 	system(buf);
> 	ioctl(fd, IOCTL_XENBUS_BACKEND_COMMIT, 0);
> 	return 0;
> }
> 
> -------------------------------------------------
> 
> Dom0 kernel changes:
>     [PATCH] xenbus: Add support for xenbus backend in stub domain
> 
> This is based on the new /dev/xen devices introduced in Linux 3.3.
> 
> Hypervisor changes:
>     [PATCH 01/18] xen: reinstate previously unused
>     [PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
>     [PATCH 03/18] xsm: allow use of XEN_DOMCTL_getdomaininfo by
>     [PATCH 04/18] xen: Preserve reserved grant entries when switching
> 
> Patch 1 & 4 are required for setting up grant entries in new domains.
> Patch 2 & 3 allow xenstored to run in an unprivileged domain. This
> currently requires XSM to be enabled to avoid allowing all domUs access
> to XEN_DOMCTL_getdomaininfo, so the patch only allows this hypercall if
> XSM is being compiled in.
> 
> Toolstack changes:
>     [PATCH 05/18] tools/libxl: Add xenstore and console backend domain
>     [PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and
> 
> These patches populate two of the eight reserved grant entries in new
> domains with the xenstore and console shared pages, which is required
> if xenstored is not run in a privileged domain.
> 
> Minios and xenstored:
>     [PATCH 07/18] mini-os: avoid crash if no console is provided
>     [PATCH 08/18] mini-os: avoid crash if no xenstore is provided
>     [PATCH 09/18] mini-os: remove per-fd evtchn limit
>     [PATCH 10/18] xenstored: use grant references instead of
>     [PATCH 11/18] xenstored: add NO_SOCKETS compilation option
>     [PATCH 12/18] xenstored support for in-memory rather than FS based
>     [PATCH 13/18] xenstored: support running in minios stubdom
>     [PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
>     [PATCH 15/18] xenstored: add --event parameter for bootstrapping
>     [PATCH 16/18] xenstored: pull dom0 event port from shared page
>     [PATCH 17/18] xenstored: use domain_is_unprivileged instead of
>     [PATCH 18/18] xenstored: add --priv-domid parameter
> 
> Support for running in a stub domain
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:00:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 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 1RlHS2-00056x-Mu; Thu, 12 Jan 2012 10:00: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 1RlHS0-00052c-Pr
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:00:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326362398!10681928!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22748 invoked from network); 12 Jan 2012 09:59:58 -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;
	12 Jan 2012 09:59:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:59: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, 12 Jan 2012 09:59:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 09:59:58 +0000
In-Reply-To: <1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362398.17210.227.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> This patch claims one reserved grant entry for the console and another
> for the xenstore. It modifies the builder to fill in the grant table
> entries for the console and the xenstore.
> 
> This has not been tested with any kind of migration.
> 
[...]
> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..23619da 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -2018,6 +2018,15 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
> 
> +/* TODO don't hardcode zero here */
> +    rc = xc_dom_gnttab_seed(xch, dom,
> +                            *console_mfn, *store_mfn, 0, 0);

Presumably this TODO is the source of the comment in the changelog WRT
migration.

Does it Just Work or is there a legitimate TODO item here?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:00:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 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 1RlHS2-00056x-Mu; Thu, 12 Jan 2012 10:00: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 1RlHS0-00052c-Pr
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:00:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326362398!10681928!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22748 invoked from network); 12 Jan 2012 09:59:58 -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;
	12 Jan 2012 09:59:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 09:59: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, 12 Jan 2012 09:59:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 09:59:58 +0000
In-Reply-To: <1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362398.17210.227.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> This patch claims one reserved grant entry for the console and another
> for the xenstore. It modifies the builder to fill in the grant table
> entries for the console and the xenstore.
> 
> This has not been tested with any kind of migration.
> 
[...]
> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..23619da 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -2018,6 +2018,15 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
> 
> +/* TODO don't hardcode zero here */
> +    rc = xc_dom_gnttab_seed(xch, dom,
> +                            *console_mfn, *store_mfn, 0, 0);

Presumably this TODO is the source of the comment in the changelog WRT
migration.

Does it Just Work or is there a legitimate TODO item here?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:03:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10: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 1RlHVG-0005JS-BO; Thu, 12 Jan 2012 10:03: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 1RlHVF-0005J2-J2
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326362598!10614177!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21755 invoked from network); 12 Jan 2012 10:03:19 -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;
	12 Jan 2012 10:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 10:03: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, 12 Jan 2012 10:03:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:03:18 +0000
In-Reply-To: <1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362598.17210.230.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 07/18] mini-os: avoid crash if no console is
 provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:

When/why does this happen? 

I guess it is because when starting the xenstore domain you cannot use
xenstore to communicate with xenconsoled (and/or it isn't even running
yet).

I wonder if there is a way we can do lazy-setup of the console for just
the xenstore domain?

Alternatively I seem to recall a little tool which Diego wrote to pull
the console ring out of a domain directly as a debuging aid but that
relies on us setting up a console ring and evtchn even if xenconsoled
cannot be involved which makes this patch unnecessary.

Ian.

> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/console/xencons_ring.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
> index 22fd618..14a8bd1 100644
> --- a/extras/mini-os/console/xencons_ring.c
> +++ b/extras/mini-os/console/xencons_ring.c
> @@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
>  
>  static inline struct xencons_interface *xencons_interface(void)
>  {
> -    return mfn_to_virt(start_info.console.domU.mfn);
> +    if (start_info.console.domU.evtchn)
> +        return mfn_to_virt(start_info.console.domU.mfn);
> +    else
> +        return NULL;
>  } 
>   
>  int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
> @@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
>              intf = xencons_interface();
>          else
>              intf = dev->ring;
> +    if (!intf)
> +        return sent;
>  
>  	cons = intf->out_cons;
>  	prod = intf->out_prod;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:03:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10: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 1RlHVG-0005JS-BO; Thu, 12 Jan 2012 10:03: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 1RlHVF-0005J2-J2
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326362598!10614177!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21755 invoked from network); 12 Jan 2012 10:03:19 -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;
	12 Jan 2012 10:03:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 10:03: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, 12 Jan 2012 10:03:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:03:18 +0000
In-Reply-To: <1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362598.17210.230.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 07/18] mini-os: avoid crash if no console is
 provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:

When/why does this happen? 

I guess it is because when starting the xenstore domain you cannot use
xenstore to communicate with xenconsoled (and/or it isn't even running
yet).

I wonder if there is a way we can do lazy-setup of the console for just
the xenstore domain?

Alternatively I seem to recall a little tool which Diego wrote to pull
the console ring out of a domain directly as a debuging aid but that
relies on us setting up a console ring and evtchn even if xenconsoled
cannot be involved which makes this patch unnecessary.

Ian.

> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/console/xencons_ring.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
> index 22fd618..14a8bd1 100644
> --- a/extras/mini-os/console/xencons_ring.c
> +++ b/extras/mini-os/console/xencons_ring.c
> @@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
>  
>  static inline struct xencons_interface *xencons_interface(void)
>  {
> -    return mfn_to_virt(start_info.console.domU.mfn);
> +    if (start_info.console.domU.evtchn)
> +        return mfn_to_virt(start_info.console.domU.mfn);
> +    else
> +        return NULL;
>  } 
>   
>  int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
> @@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
>              intf = xencons_interface();
>          else
>              intf = dev->ring;
> +    if (!intf)
> +        return sent;
>  
>  	cons = intf->out_cons;
>  	prod = intf->out_prod;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:06:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHXp-0005SU-U4; Thu, 12 Jan 2012 10:06:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlHXo-0005SK-5U
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:06:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326362737!62127577!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17446 invoked from network); 12 Jan 2012 10:05:38 -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 Jan 2012 10:05:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 10:05:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 10:05:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:05:57 +0000
In-Reply-To: <1326302490-19428-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362757.17210.232.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 11/18] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> @@ -308,7 +310,10 @@ static void set_fd(int fd, fd_set *set, int *max)
>  }
>  
>  
> -static int initialize_set(fd_set *inset, fd_set *outset, int sock,
> int ro_sock,
> +static int initialize_set(fd_set *inset, fd_set *outset,
> +#ifndef NO_SOCKETS
> +                         int sock, int ro_sock,
> +#endif
>                           struct timeval **ptimeout)
>  {
>         static struct timeval zero_timeout = { 0 }; 

Rather than removing the argument why not simply accept -1 as a "no
sock" value and DTWT with that, this ought to reduce the amount of
ifdeffery substantially

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:06:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:06:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHXp-0005SU-U4; Thu, 12 Jan 2012 10:06:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlHXo-0005SK-5U
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:06:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326362737!62127577!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17446 invoked from network); 12 Jan 2012 10:05:38 -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 Jan 2012 10:05:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 10:05:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 10:05:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:05:57 +0000
In-Reply-To: <1326302490-19428-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326362757.17210.232.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 11/18] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> @@ -308,7 +310,10 @@ static void set_fd(int fd, fd_set *set, int *max)
>  }
>  
>  
> -static int initialize_set(fd_set *inset, fd_set *outset, int sock,
> int ro_sock,
> +static int initialize_set(fd_set *inset, fd_set *outset,
> +#ifndef NO_SOCKETS
> +                         int sock, int ro_sock,
> +#endif
>                           struct timeval **ptimeout)
>  {
>         static struct timeval zero_timeout = { 0 }; 

Rather than removing the argument why not simply accept -1 as a "no
sock" value and DTWT with that, this ought to reduce the amount of
ifdeffery substantially

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:21:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHmE-0005hP-D1; Thu, 12 Jan 2012 10:20: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 1RlHmC-0005hK-BN
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:20:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326363650!10533091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 931 invoked from network); 12 Jan 2012 10:20:50 -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 Jan 2012 10:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 10:20: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;
	Thu, 12 Jan 2012 10:20:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:20:48 +0000
In-Reply-To: <1326302490-19428-19-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-19-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326363649.17210.234.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 18/18] xenstored: add --priv-domid 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

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> This parameter identifies an alternative service domain which has
> superuser access to the xenstore database, which is currently required
> to set up a new domain's xenstore entries.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_core.c   |    5 +++++
>  tools/xenstore/xenstored_core.h   |    1 +
>  tools/xenstore/xenstored_domain.c |    2 +-
>  3 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 65ceb2c..4437c8d 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -1777,6 +1777,7 @@ static struct option options[] = {
>  	{ "event", 1, NULL, 'e' },
>  	{ "help", 0, NULL, 'H' },
>  	{ "no-fork", 0, NULL, 'N' },
> +	{ "priv-domid", 1, NULL, 'p' },
>  	{ "output-pid", 0, NULL, 'P' },
>  	{ "entry-size", 1, NULL, 'S' },
>  	{ "trace-file", 1, NULL, 'T' },
> @@ -1789,6 +1790,7 @@ static struct option options[] = {
>  
>  extern void dump_conn(struct connection *conn); 
>  int dom0_event = 0;
> +int priv_domid = 0;
>  
>  int main(int argc, char *argv[])
>  {
> @@ -1854,6 +1856,9 @@ int main(int argc, char *argv[])
>  		case 'e':
>  			dom0_event = strtol(optarg, NULL, 10);
>  			break;
> +		case 'p':
> +			priv_domid = strtol(optarg, NULL, 10);
> +			break;
>  		}
>  	}
>  	if (optind != argc)
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index d3040ba..03e2e48 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>  
>  extern int event_fd;
>  extern int dom0_event;
> +extern int priv_domid;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 5bf16e8..ba9a5ef 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
>  
>  bool domain_is_unprivileged(struct connection *conn)
>  {
> -	return (conn && conn->domain && conn->domain->domid != 0);
> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);

Is it deliberate / desirable that both dom0 and domPRIV are privileged
when this option is used? Or should it be just one or the other, which
is equivalent to removing the domid!=0 check since priv_domid defaults
to 0.

Ian.

>  }
>  
>  bool domain_can_write(struct connection *conn)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:21:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHmE-0005hP-D1; Thu, 12 Jan 2012 10:20: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 1RlHmC-0005hK-BN
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:20:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326363650!10533091!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 931 invoked from network); 12 Jan 2012 10:20:50 -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 Jan 2012 10:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 10:20: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;
	Thu, 12 Jan 2012 10:20:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:20:48 +0000
In-Reply-To: <1326302490-19428-19-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-19-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326363649.17210.234.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 18/18] xenstored: add --priv-domid 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

On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> This parameter identifies an alternative service domain which has
> superuser access to the xenstore database, which is currently required
> to set up a new domain's xenstore entries.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_core.c   |    5 +++++
>  tools/xenstore/xenstored_core.h   |    1 +
>  tools/xenstore/xenstored_domain.c |    2 +-
>  3 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 65ceb2c..4437c8d 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -1777,6 +1777,7 @@ static struct option options[] = {
>  	{ "event", 1, NULL, 'e' },
>  	{ "help", 0, NULL, 'H' },
>  	{ "no-fork", 0, NULL, 'N' },
> +	{ "priv-domid", 1, NULL, 'p' },
>  	{ "output-pid", 0, NULL, 'P' },
>  	{ "entry-size", 1, NULL, 'S' },
>  	{ "trace-file", 1, NULL, 'T' },
> @@ -1789,6 +1790,7 @@ static struct option options[] = {
>  
>  extern void dump_conn(struct connection *conn); 
>  int dom0_event = 0;
> +int priv_domid = 0;
>  
>  int main(int argc, char *argv[])
>  {
> @@ -1854,6 +1856,9 @@ int main(int argc, char *argv[])
>  		case 'e':
>  			dom0_event = strtol(optarg, NULL, 10);
>  			break;
> +		case 'p':
> +			priv_domid = strtol(optarg, NULL, 10);
> +			break;
>  		}
>  	}
>  	if (optind != argc)
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index d3040ba..03e2e48 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>  
>  extern int event_fd;
>  extern int dom0_event;
> +extern int priv_domid;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 5bf16e8..ba9a5ef 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
>  
>  bool domain_is_unprivileged(struct connection *conn)
>  {
> -	return (conn && conn->domain && conn->domain->domid != 0);
> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);

Is it deliberate / desirable that both dom0 and domPRIV are privileged
when this option is used? Or should it be just one or the other, which
is equivalent to removing the domid!=0 check since priv_domid defaults
to 0.

Ian.

>  }
>  
>  bool domain_can_write(struct connection *conn)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:22:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 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 1RlHnJ-0005kL-Rt; Thu, 12 Jan 2012 10:22:05 +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 1RlHnI-0005k8-J1
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:22:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326363718!12055243!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8909 invoked from network); 12 Jan 2012 10:21:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 10:21:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 10:21: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; Thu, 12 Jan 2012 10:21:37 +0000
Date: Thu, 12 Jan 2012 10:21:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326350744.29084.101.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1201121020590.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<6035A0D088A63A46850C3988ED045A4B0A2720@BITCOM1.int.sbss.com.au>
	<1326350744.29084.101.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 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

On Thu, 12 Jan 2012, Ian Campbell wrote:
> On Wed, 2012-01-11 at 21:34 +0000, James Harper wrote:
> > Are any of the free ARM emulators capable of emulating an ARMv7 platform?
> 
> ARMv7 possibly qemu does, but ARMv7+virt extensions I don't think any of
> them do.

Yes, ARMv7 is in the works right in qemu now but they are not going to
support the virtualization extensions.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:22:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 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 1RlHnJ-0005kL-Rt; Thu, 12 Jan 2012 10:22:05 +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 1RlHnI-0005k8-J1
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:22:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326363718!12055243!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8909 invoked from network); 12 Jan 2012 10:21:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 10:21:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9965860"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 10:21: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; Thu, 12 Jan 2012 10:21:37 +0000
Date: Thu, 12 Jan 2012 10:21:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326350744.29084.101.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1201121020590.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<6035A0D088A63A46850C3988ED045A4B0A2720@BITCOM1.int.sbss.com.au>
	<1326350744.29084.101.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 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

On Thu, 12 Jan 2012, Ian Campbell wrote:
> On Wed, 2012-01-11 at 21:34 +0000, James Harper wrote:
> > Are any of the free ARM emulators capable of emulating an ARMv7 platform?
> 
> ARMv7 possibly qemu does, but ARMv7+virt extensions I don't think any of
> them do.

Yes, ARMv7 is in the works right in qemu now but they are not going to
support the virtualization extensions.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:33:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHyL-00060z-2o; Thu, 12 Jan 2012 10:33:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RlHyJ-00060u-CO
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:33:27 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326364400!10535362!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3NzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22019 invoked from network); 12 Jan 2012 10:33:21 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 10:33:21 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C186F225DE
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 05:33:19 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute3.internal (MEProxy); Thu, 12 Jan 2012 05:33:19 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=so
	M4qyVAcvgXnAh+88rGEe0L5FM=; b=R1T6yjvJyAmo2wonSA9MqvjaLWGTGBWgDd
	BJ/bjPKzPOihNISISlE6i5UN3aLpNqflGvdN3E+JjaullsoeTopF86iGvahyg7Hp
	NqBiLtsw4+1Zn456JLKVRzkLaeDx7KRJERoTLQGF/urW55W96kTdoEgDz23yUK1x
	yZaqJ/DCo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=soM4
	qyVAcvgXnAh+88rGEe0L5FM=; b=SOuWZ+LrikAHzn2sh9n/m+4nj/zRBJd6Yuwa
	zE1e8T0vlys6VBpzSxH407OR74XBYtugfpk2ui2jlakkSTw7ZTvdsplDFMouWqmi
	4Sta5otJ0EorK6hOSd/No0Ostg7o7SjTxCXK8N7wzEVXojmikdZwaIakPYzAbeWs
	zt1Ev6s=
X-Sasl-enc: 7mPl/k+5MTPnxM1Y3g8y28HJxKqLv+Pab3r2I13ji3GB 1326364399
Received: from [10.137.2.12] (afmg220.neoplus.adsl.tpnet.pl [178.42.58.220])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 22CBC482487;
	Thu, 12 Jan 2012 05:33:19 -0500 (EST)
Message-ID: <4F0EB6ED.3030900@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 11:33:17 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4596669422603345087=="
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)
--===============4596669422603345087==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigF17F1250A6A75B76D03CE292"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF17F1250A6A75B76D03CE292
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/11/12 18:21, Daniel De Graaf wrote:
> This patch series allows xenstored to run in a stub domian started by
> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg014=
88.html
>=20

Daniel,

Can you explain what is the rationale for moving the xenstored into a
stubdom? After all, if an attacker is able to compromise the xenstored,
there should be many ways now how to compromise other VMs in the system?
And it shouldn't matter whether the xenstored is in stubdom or whether
in Dom0. E.g. the attacker might redirect the block fronts to us some
false block backends, so that the VMs get compromised fs. One could
probably think of other attacks as well...?

joanna.


--------------enigF17F1250A6A75B76D03CE292
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPDrbtAAoJEDaIqHeRBUM0KQwH/2Dzfv12e78sjJIPsl67rPXR
j3bFj0gqSbwStDI+RtLYW6bwwe1JEJHC4PUCiaoPVF2V7zGXG04E9VfAyOSUvreP
UwgtxzTZQa7T/RqgRE8EdGrLwMtJnukiOXujbVtBMUGFxVUjxMt9w7peXSJM9fE0
KY3OIMglz0OR3ZB1YUOEyMKP9rsXQeazJ8pEdXn0j+sWcGZSV3/gZ+1BXqqqpWOV
RjjCQav3idMkWzQhPZ8acRQvyZlU7LeyfSFMBAktES0D+qenP1KetUkyan4yPVeR
MVYqQiEPrgMXvQWGjlUoVR00nElmbXtlaZNJ6VmdWTISMagSAxpqIammRSdVxvg=
=5CNv
-----END PGP SIGNATURE-----

--------------enigF17F1250A6A75B76D03CE292--


--===============4596669422603345087==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4596669422603345087==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:33:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlHyL-00060z-2o; Thu, 12 Jan 2012 10:33:29 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RlHyJ-00060u-CO
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:33:27 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326364400!10535362!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3NzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22019 invoked from network); 12 Jan 2012 10:33:21 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 10:33:21 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C186F225DE
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 05:33:19 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute3.internal (MEProxy); Thu, 12 Jan 2012 05:33:19 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=so
	M4qyVAcvgXnAh+88rGEe0L5FM=; b=R1T6yjvJyAmo2wonSA9MqvjaLWGTGBWgDd
	BJ/bjPKzPOihNISISlE6i5UN3aLpNqflGvdN3E+JjaullsoeTopF86iGvahyg7Hp
	NqBiLtsw4+1Zn456JLKVRzkLaeDx7KRJERoTLQGF/urW55W96kTdoEgDz23yUK1x
	yZaqJ/DCo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=soM4
	qyVAcvgXnAh+88rGEe0L5FM=; b=SOuWZ+LrikAHzn2sh9n/m+4nj/zRBJd6Yuwa
	zE1e8T0vlys6VBpzSxH407OR74XBYtugfpk2ui2jlakkSTw7ZTvdsplDFMouWqmi
	4Sta5otJ0EorK6hOSd/No0Ostg7o7SjTxCXK8N7wzEVXojmikdZwaIakPYzAbeWs
	zt1Ev6s=
X-Sasl-enc: 7mPl/k+5MTPnxM1Y3g8y28HJxKqLv+Pab3r2I13ji3GB 1326364399
Received: from [10.137.2.12] (afmg220.neoplus.adsl.tpnet.pl [178.42.58.220])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 22CBC482487;
	Thu, 12 Jan 2012 05:33:19 -0500 (EST)
Message-ID: <4F0EB6ED.3030900@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 11:33:17 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4596669422603345087=="
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)
--===============4596669422603345087==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigF17F1250A6A75B76D03CE292"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF17F1250A6A75B76D03CE292
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/11/12 18:21, Daniel De Graaf wrote:
> This patch series allows xenstored to run in a stub domian started by
> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg014=
88.html
>=20

Daniel,

Can you explain what is the rationale for moving the xenstored into a
stubdom? After all, if an attacker is able to compromise the xenstored,
there should be many ways now how to compromise other VMs in the system?
And it shouldn't matter whether the xenstored is in stubdom or whether
in Dom0. E.g. the attacker might redirect the block fronts to us some
false block backends, so that the VMs get compromised fs. One could
probably think of other attacks as well...?

joanna.


--------------enigF17F1250A6A75B76D03CE292
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPDrbtAAoJEDaIqHeRBUM0KQwH/2Dzfv12e78sjJIPsl67rPXR
j3bFj0gqSbwStDI+RtLYW6bwwe1JEJHC4PUCiaoPVF2V7zGXG04E9VfAyOSUvreP
UwgtxzTZQa7T/RqgRE8EdGrLwMtJnukiOXujbVtBMUGFxVUjxMt9w7peXSJM9fE0
KY3OIMglz0OR3ZB1YUOEyMKP9rsXQeazJ8pEdXn0j+sWcGZSV3/gZ+1BXqqqpWOV
RjjCQav3idMkWzQhPZ8acRQvyZlU7LeyfSFMBAktES0D+qenP1KetUkyan4yPVeR
MVYqQiEPrgMXvQWGjlUoVR00nElmbXtlaZNJ6VmdWTISMagSAxpqIammRSdVxvg=
=5CNv
-----END PGP SIGNATURE-----

--------------enigF17F1250A6A75B76D03CE292--


--===============4596669422603345087==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4596669422603345087==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10: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 1RlICe-0006ET-NU; Thu, 12 Jan 2012 10:48: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 1RlICc-0006EL-Nv
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:48:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326365288!8824887!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 27799 invoked from network); 12 Jan 2012 10:48:08 -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; 12 Jan 2012 10:48:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlICR-000CZx-Ju; Thu, 12 Jan 2012 10:48:03 +0000
Date: Thu, 12 Jan 2012 10:48:02 +0000
From: Tim Deegan <tim@xen.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120112104802.GA47092@ocelot.phlegethon.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0EB6ED.3030900@invisiblethingslab.com>
User-Agent: Mutt/1.4.2.1i
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> Daniel,
> 
> Can you explain what is the rationale for moving the xenstored into a
> stubdom? After all, if an attacker is able to compromise the xenstored,
> there should be many ways now how to compromise other VMs in the system?
> And it shouldn't matter whether the xenstored is in stubdom or whether
> in Dom0. E.g. the attacker might redirect the block fronts to us some
> false block backends, so that the VMs get compromised fs. One could
> probably think of other attacks as well...?

I think the point is to protect xenstore from dom0, not dom0 from
xenstore.  With stub-xenstore and driver domains, only the domain
builder and PCIback need to have any privilege, and they can be moved
out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
http://tjd.phlegethon.org/words/sosp11-xoar.html)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10: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 1RlICe-0006ET-NU; Thu, 12 Jan 2012 10:48: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 1RlICc-0006EL-Nv
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:48:14 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326365288!8824887!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 27799 invoked from network); 12 Jan 2012 10:48:08 -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; 12 Jan 2012 10:48:08 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlICR-000CZx-Ju; Thu, 12 Jan 2012 10:48:03 +0000
Date: Thu, 12 Jan 2012 10:48:02 +0000
From: Tim Deegan <tim@xen.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120112104802.GA47092@ocelot.phlegethon.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0EB6ED.3030900@invisiblethingslab.com>
User-Agent: Mutt/1.4.2.1i
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> Daniel,
> 
> Can you explain what is the rationale for moving the xenstored into a
> stubdom? After all, if an attacker is able to compromise the xenstored,
> there should be many ways now how to compromise other VMs in the system?
> And it shouldn't matter whether the xenstored is in stubdom or whether
> in Dom0. E.g. the attacker might redirect the block fronts to us some
> false block backends, so that the VMs get compromised fs. One could
> probably think of other attacks as well...?

I think the point is to protect xenstore from dom0, not dom0 from
xenstore.  With stub-xenstore and driver domains, only the domain
builder and PCIback need to have any privilege, and they can be moved
out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
http://tjd.phlegethon.org/words/sosp11-xoar.html)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:51:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:51:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIFO-0006KF-9l; Thu, 12 Jan 2012 10:51:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlIFN-0006K9-7n
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:51:05 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326365410!52227488!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjUzODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22621 invoked from network); 12 Jan 2012 10:50:10 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-3.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 10:50:10 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0CAnvEH030190;
	Thu, 12 Jan 2012 05:49:58 -0500
Date: Thu, 12 Jan 2012 05:49:57 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <e37e8bec-f4ec-4420-81f0-da0ef90a6120@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111172832.GB4449@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep
	XEN_XENBUS_FRONTEND	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> > When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
> > unbootable configs. If we need it, then we should just build it in.
> 
> Hm, don't the frontends by themsevles load this module? So if you
> do 'modprobe xen-pcifront' it would load this automatically?
> 

The problem is on boot, getting it there before we need xen-blkfront.
I think it might solvable if you make sure your tooling pushes the
xenbus module into your initrd. However we've had problems with
platform_pci being a module in the past, and if I'm not mistaken
that was one of the motivators for building it in (5fbdc10395cd). I
see this as a similar story.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/xen/Kconfig |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 8795480..1d24061 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
> >  	 but will have no xen contents.
> >  
> >  config XEN_XENBUS_FRONTEND
> > -	tristate
> > +	bool
> >  
> >  config XEN_GNTDEV
> >  	tristate "userspace grant access device driver"
> > --
> > 1.7.7.5
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:51:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:51:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIFO-0006KF-9l; Thu, 12 Jan 2012 10:51:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlIFN-0006K9-7n
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:51:05 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326365410!52227488!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjUzODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22621 invoked from network); 12 Jan 2012 10:50:10 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-3.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 10:50:10 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0CAnvEH030190;
	Thu, 12 Jan 2012 05:49:58 -0500
Date: Thu, 12 Jan 2012 05:49:57 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <e37e8bec-f4ec-4420-81f0-da0ef90a6120@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111172832.GB4449@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep
	XEN_XENBUS_FRONTEND	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> > When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
> > unbootable configs. If we need it, then we should just build it in.
> 
> Hm, don't the frontends by themsevles load this module? So if you
> do 'modprobe xen-pcifront' it would load this automatically?
> 

The problem is on boot, getting it there before we need xen-blkfront.
I think it might solvable if you make sure your tooling pushes the
xenbus module into your initrd. However we've had problems with
platform_pci being a module in the past, and if I'm not mistaken
that was one of the motivators for building it in (5fbdc10395cd). I
see this as a similar story.

Drew

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/xen/Kconfig |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 8795480..1d24061 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
> >  	 but will have no xen contents.
> >  
> >  config XEN_XENBUS_FRONTEND
> > -	tristate
> > +	bool
> >  
> >  config XEN_GNTDEV
> >  	tristate "userspace grant access device driver"
> > --
> > 1.7.7.5
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:54:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIIK-0006Tf-SP; Thu, 12 Jan 2012 10:54:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlIIJ-0006TS-5y
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:54:07 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326365639!8149838!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjUzODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19410 invoked from network); 12 Jan 2012 10:53:59 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-13.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 10:53:59 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0CArGtP030643;
	Thu, 12 Jan 2012 05:53:16 -0500
Date: Thu, 12 Jan 2012 05:53:16 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <2498642a-56c9-497e-84f1-be06a7a5aa26@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111172700.GA4449@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Wed, Jan 11, 2012 at 12:19:11PM -0400, Konrad Rzeszutek Wilk
> wrote:
> > > > If the root complaint is that "customers think that anything
> > > > set in
> > > > .config is a supported feature", then the solutions are to
> > > > support
> > > > all
> > > > the features in .config, re-educate the customers that they're
> > > > wrong,
> > > > or
> > > > maintain a local patch to do this stuff.
> > > 
> > > If only re-educating people was free, like preempting questions
> > > is.
> > > Local patches are of course always an option, and perhaps in this
> > > case it's the best one. However, I think we already made a case
> > > for
> > > better xen configurability for the driver domains, so I'm not
> > > 100%
> > 
> > Could you repost those backend patches please? At this point I am
> > not
> > sure which one we have discarded?
> 
> hm, I was thinking in terms of the XenBus ones. We had somewhere in
> this
> converstion something about seperating the backend's from depending
> on
> CONFIG_XEN_DOM0 as they can be run in any domain nowadays.
> 

Ah, I still haven't posted anything like that. So nothing got lost :-)
It's a good idea, but it's probably best done and tested by someone
working with driver domains, or even with the backends at all, which
I'm not.

Drew

> > 
> > > convinced my initial patch (making dom0 configurable) isn't
> > > worthy
> > > of upstream. Also, I didn't see any comments on my v2[*] of that
> > > patch, which I believe satisfies the menu complexity issue and
> > > brings in more configurability. That said, I'm about to reply to
> > > that patch myself, since there's an issue with it.
> > > 
> > > Drew
> > > 
> > > [*]
> > > http://article.gmane.org/gmane.linux.kernel.virtualization/14635
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/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 Jan 12 10:54:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:54:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIIK-0006Tf-SP; Thu, 12 Jan 2012 10:54:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlIIJ-0006TS-5y
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:54:07 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326365639!8149838!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjUzODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19410 invoked from network); 12 Jan 2012 10:53:59 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-13.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 10:53:59 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0CArGtP030643;
	Thu, 12 Jan 2012 05:53:16 -0500
Date: Thu, 12 Jan 2012 05:53:16 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <2498642a-56c9-497e-84f1-be06a7a5aa26@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111172700.GA4449@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen: remove CONFIG_XEN_DOM0 compile option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Wed, Jan 11, 2012 at 12:19:11PM -0400, Konrad Rzeszutek Wilk
> wrote:
> > > > If the root complaint is that "customers think that anything
> > > > set in
> > > > .config is a supported feature", then the solutions are to
> > > > support
> > > > all
> > > > the features in .config, re-educate the customers that they're
> > > > wrong,
> > > > or
> > > > maintain a local patch to do this stuff.
> > > 
> > > If only re-educating people was free, like preempting questions
> > > is.
> > > Local patches are of course always an option, and perhaps in this
> > > case it's the best one. However, I think we already made a case
> > > for
> > > better xen configurability for the driver domains, so I'm not
> > > 100%
> > 
> > Could you repost those backend patches please? At this point I am
> > not
> > sure which one we have discarded?
> 
> hm, I was thinking in terms of the XenBus ones. We had somewhere in
> this
> converstion something about seperating the backend's from depending
> on
> CONFIG_XEN_DOM0 as they can be run in any domain nowadays.
> 

Ah, I still haven't posted anything like that. So nothing got lost :-)
It's a good idea, but it's probably best done and tested by someone
working with driver domains, or even with the backends at all, which
I'm not.

Drew

> > 
> > > convinced my initial patch (making dom0 configurable) isn't
> > > worthy
> > > of upstream. Also, I didn't see any comments on my v2[*] of that
> > > patch, which I believe satisfies the menu complexity issue and
> > > brings in more configurability. That said, I'm about to reply to
> > > that patch myself, since there's an issue with it.
> > > 
> > > Drew
> > > 
> > > [*]
> > > http://article.gmane.org/gmane.linux.kernel.virtualization/14635
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/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 Jan 12 10:56:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIJu-0006ac-Cf; Thu, 12 Jan 2012 10:55:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlIJt-0006a8-4d
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:55:45 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326365738!10606791!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzI2MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11271 invoked from network); 12 Jan 2012 10:55:38 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-6.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 10:55:38 -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 q0CAsndA022252;
	Thu, 12 Jan 2012 05:54:49 -0500
Date: Thu, 12 Jan 2012 05:54:49 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <929b2415-1926-4efa-90b1-eef07e1f2c9c@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111173536.GD4449@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	stefano stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Wed, Jan 11, 2012 at 05:36:41PM +0100, Andrew Jones wrote:
> > Add a description to the config menu for xen tmem.
> 
> We will have another config option asked during 'make oldconfig'
> right?
> 
> I thought part of this cleanup patch is to remove some of this
> complexity - not make it _more_ complex.
> 

Another candidate for 'if EXPERT' then, IMHO.

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/xen/Kconfig |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 1d24061..7e8d728 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -143,7 +143,7 @@ config SWIOTLB_XEN
> >  	select SWIOTLB
> >  
> >  config XEN_TMEM
> > -	bool
> > +	bool "Xen Transcendent Memory (tmem)"
> >  	default y if (CLEANCACHE || FRONTSWAP)
> >  	help
> >  	  Shim to interface in-kernel Transcendent Memory hooks
> > --
> > 1.7.7.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 10:56:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 10:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIJu-0006ac-Cf; Thu, 12 Jan 2012 10:55:46 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlIJt-0006a8-4d
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 10:55:45 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326365738!10606791!1
X-Originating-IP: [209.132.183.24]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjQgPT4gNzI2MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11271 invoked from network); 12 Jan 2012 10:55:38 -0000
Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24)
	by server-6.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 10:55:38 -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 q0CAsndA022252;
	Thu, 12 Jan 2012 05:54:49 -0500
Date: Thu, 12 Jan 2012 05:54:49 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <929b2415-1926-4efa-90b1-eef07e1f2c9c@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111173536.GD4449@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	stefano stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Wed, Jan 11, 2012 at 05:36:41PM +0100, Andrew Jones wrote:
> > Add a description to the config menu for xen tmem.
> 
> We will have another config option asked during 'make oldconfig'
> right?
> 
> I thought part of this cleanup patch is to remove some of this
> complexity - not make it _more_ complex.
> 

Another candidate for 'if EXPERT' then, IMHO.

> > 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/xen/Kconfig |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 1d24061..7e8d728 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -143,7 +143,7 @@ config SWIOTLB_XEN
> >  	select SWIOTLB
> >  
> >  config XEN_TMEM
> > -	bool
> > +	bool "Xen Transcendent Memory (tmem)"
> >  	default y if (CLEANCACHE || FRONTSWAP)
> >  	help
> >  	  Shim to interface in-kernel Transcendent Memory hooks
> > --
> > 1.7.7.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:01:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIOf-0006s4-69; Thu, 12 Jan 2012 11:00:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlIOe-0006rx-6q
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:00:40 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326366032!8772097!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjUzODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23707 invoked from network); 12 Jan 2012 11:00:33 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-12.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 11:00:33 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0CAxaon031231;
	Thu, 12 Jan 2012 05:59:36 -0500
Date: Thu, 12 Jan 2012 05:59:36 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <16672c9d-d57d-44b4-8220-049a2d0e3a3f@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111173009.GC4449@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	dmitry.torokhov@gmail.com, FlorianSchandinat@gmx.de,
	virtualization@lists.linux-foundation.org, konrad@darnok.org
Subject: Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Wed, Jan 11, 2012 at 05:36:39PM +0100, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
> > but
> > they don't use the xen frame buffer frontend. For this case it
> > doesn't
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
> > i.e.
> 
> What is the disadvantege of keeping it as is?

If you don't want FB, but you do want KBD, then you're stuck with FB
anyway, even though it isn't necessary. Perhaps I'm the only one who
ever considering building a config without FB?

> 
> > if you're using xenfb, then you'll want xenkbd. Switch the
> > dependencies.
> > 
> You are missing the CC to the proper maintainer.
> 

I added them the last time you reminded me. See the following
message-ids for the thread where this patch was discussed and then
led to the V2 here.

20120109075911.GA4049@core.coreip.homeip.net
725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com
1326131501-9610-1-git-send-email-drjones@redhat.com

I've re-added them to this thread, since the multiple
posting/reposting must have lost them again.

> Also, did you test this with PV and PVonHVM guests?

Testing-wise you don't really need to do much more then
'make oldconfig'. FB doesn't work on pv-on-hvm, the mod wouldn't
even init if you tried as there's a

        if (!xen_pv_domain())
                return -ENODEV;

I have tested a pv-on-hvm guest after this patch with FB off though,
which worked. For PV guests using FB, they'll work the same, as you
wouldn't want to change your config.

Drew

> 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/input/misc/Kconfig |    2 +-
> >  drivers/video/Kconfig      |    2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/input/misc/Kconfig
> > b/drivers/input/misc/Kconfig
> > index 22d875f..36c15bf 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> >  
> >  config INPUT_XEN_KBDDEV_FRONTEND
> >  	tristate "Xen virtual keyboard and mouse support"
> > -	depends on XEN_FBDEV_FRONTEND
> > +	depends on XEN
> >  	default y
> >  	select XEN_XENBUS_FRONTEND
> >  	help
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index d83e967..3e38c2f 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -2263,7 +2263,7 @@ config FB_VIRTUAL
> >  
> >  config XEN_FBDEV_FRONTEND
> >  	tristate "Xen virtual frame buffer support"
> > -	depends on FB && XEN
> > +	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
> >  	select FB_SYS_FILLRECT
> >  	select FB_SYS_COPYAREA
> >  	select FB_SYS_IMAGEBLIT
> > --
> > 1.7.7.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:01:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIOf-0006s4-69; Thu, 12 Jan 2012 11:00:41 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlIOe-0006rx-6q
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:00:40 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326366032!8772097!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjUzODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23707 invoked from network); 12 Jan 2012 11:00:33 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-12.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 11:00:33 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0CAxaon031231;
	Thu, 12 Jan 2012 05:59:36 -0500
Date: Thu, 12 Jan 2012 05:59:36 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <16672c9d-d57d-44b4-8220-049a2d0e3a3f@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120111173009.GC4449@phenom.dumpdata.com>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	dmitry.torokhov@gmail.com, FlorianSchandinat@gmx.de,
	virtualization@lists.linux-foundation.org, konrad@darnok.org
Subject: Re: [Xen-devel] [PATCH 2/4 v2] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Wed, Jan 11, 2012 at 05:36:39PM +0100, Andrew Jones wrote:
> > PV-on-HVM guests may want to use the xen keyboard/mouse frontend,
> > but
> > they don't use the xen frame buffer frontend. For this case it
> > doesn't
> > make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> > XEN_FBDEV_FRONTEND. The opposite direction always makes more sense,
> > i.e.
> 
> What is the disadvantege of keeping it as is?

If you don't want FB, but you do want KBD, then you're stuck with FB
anyway, even though it isn't necessary. Perhaps I'm the only one who
ever considering building a config without FB?

> 
> > if you're using xenfb, then you'll want xenkbd. Switch the
> > dependencies.
> > 
> You are missing the CC to the proper maintainer.
> 

I added them the last time you reminded me. See the following
message-ids for the thread where this patch was discussed and then
led to the V2 here.

20120109075911.GA4049@core.coreip.homeip.net
725950ad-d5cf-4ddb-9870-a5c8d75cfa51@zmail13.collab.prod.int.phx2.redhat.com
1326131501-9610-1-git-send-email-drjones@redhat.com

I've re-added them to this thread, since the multiple
posting/reposting must have lost them again.

> Also, did you test this with PV and PVonHVM guests?

Testing-wise you don't really need to do much more then
'make oldconfig'. FB doesn't work on pv-on-hvm, the mod wouldn't
even init if you tried as there's a

        if (!xen_pv_domain())
                return -ENODEV;

I have tested a pv-on-hvm guest after this patch with FB off though,
which worked. For PV guests using FB, they'll work the same, as you
wouldn't want to change your config.

Drew

> 
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> >  drivers/input/misc/Kconfig |    2 +-
> >  drivers/video/Kconfig      |    2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/input/misc/Kconfig
> > b/drivers/input/misc/Kconfig
> > index 22d875f..36c15bf 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
> >  
> >  config INPUT_XEN_KBDDEV_FRONTEND
> >  	tristate "Xen virtual keyboard and mouse support"
> > -	depends on XEN_FBDEV_FRONTEND
> > +	depends on XEN
> >  	default y
> >  	select XEN_XENBUS_FRONTEND
> >  	help
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index d83e967..3e38c2f 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -2263,7 +2263,7 @@ config FB_VIRTUAL
> >  
> >  config XEN_FBDEV_FRONTEND
> >  	tristate "Xen virtual frame buffer support"
> > -	depends on FB && XEN
> > +	depends on FB && XEN && INPUT_XEN_KBDDEV_FRONTEND
> >  	select FB_SYS_FILLRECT
> >  	select FB_SYS_COPYAREA
> >  	select FB_SYS_IMAGEBLIT
> > --
> > 1.7.7.5
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:01:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:01:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIPF-0006uV-K1; Thu, 12 Jan 2012 11:01:17 +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 1RlIPE-0006tz-98
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:01:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326366069!10721072!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 22009 invoked from network); 12 Jan 2012 11:01:10 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 11:01:10 -0000
Received: by werg1 with SMTP id g1so3190122wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 03:01:09 -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=dg+s5CzCMp0O0TsgmW1YykpkEDwLT/Kw8vQcNzaNrc8=;
	b=tQXnSVaF6j+s6JcimRplrgyM7MpC06ccWy5y8CLgD/UFJpsq/rQe+V4xOfU19tO0pW
	78zpLEvOEDZaM0TwscIV9JwW/N7XjXNMPM4TJaQS9eCltdkpLLsaYgVyjBQwVF4wzIfW
	ezTAJYF4xzBC37gaYFfpODO+6Cwx8Ci5Z7oXE=
Received: by 10.216.138.5 with SMTP id z5mr4541673wei.37.1326366069059;
	Thu, 12 Jan 2012 03:01:09 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fc6sm865411wbb.16.2012.01.12.03.01.05
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 03:01:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 11:00:57 +0000
From: Keir Fraser <keir@xen.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <CB346DE9.37475%keir@xen.org>
Thread-Topic: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
Thread-Index: AczRGXXwD1hCE8tX/kWP8sAFj4p9Vw==
In-Reply-To: <4F0EB6ED.3030900@invisiblethingslab.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/01/2012 10:33, "Joanna Rutkowska" <joanna@invisiblethingslab.com>
wrote:

> On 01/11/12 18:21, Daniel De Graaf wrote:
>> This patch series allows xenstored to run in a stub domian started by
>> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
>> 
http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.htm>>
l
>> 
> 
> Daniel,
> 
> Can you explain what is the rationale for moving the xenstored into a
> stubdom? After all, if an attacker is able to compromise the xenstored,
> there should be many ways now how to compromise other VMs in the system?
> And it shouldn't matter whether the xenstored is in stubdom or whether
> in Dom0. E.g. the attacker might redirect the block fronts to us some
> false block backends, so that the VMs get compromised fs. One could
> probably think of other attacks as well...?

As you point out it's a critical component in itself, so I suppose this work
is mainly about isolating it from the big attack surfaces in dom0. It's of
questionable value unless dom0 itself can be deprivileged, or the big attack
surfaces themselves shuffled off into lesser-privileged domains. In a well
locked down dom0 I would say that the biggest attack surfaces are via things
like domain build, save/restore, and qemu, being intrinsic (ie unavoidable)
components of a Xen system which consume complex inputs. We can already do
qemu stubdoms, perhaps with some features missing still. Launching isolated,
de-privileged (eg can only act on the one specified domain),
domain-builder/saver/restorer stubdoms would be an interesting direction
imo. It's easy to be impressed with any disaggregation effort almost for its
own sake, and lose sight of the importance of basic security analysis as a
starting point.

 -- Keir

> joanna.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 11:01:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:01:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIPF-0006uV-K1; Thu, 12 Jan 2012 11:01:17 +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 1RlIPE-0006tz-98
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:01:16 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326366069!10721072!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 22009 invoked from network); 12 Jan 2012 11:01:10 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 11:01:10 -0000
Received: by werg1 with SMTP id g1so3190122wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 03:01:09 -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=dg+s5CzCMp0O0TsgmW1YykpkEDwLT/Kw8vQcNzaNrc8=;
	b=tQXnSVaF6j+s6JcimRplrgyM7MpC06ccWy5y8CLgD/UFJpsq/rQe+V4xOfU19tO0pW
	78zpLEvOEDZaM0TwscIV9JwW/N7XjXNMPM4TJaQS9eCltdkpLLsaYgVyjBQwVF4wzIfW
	ezTAJYF4xzBC37gaYFfpODO+6Cwx8Ci5Z7oXE=
Received: by 10.216.138.5 with SMTP id z5mr4541673wei.37.1326366069059;
	Thu, 12 Jan 2012 03:01:09 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fc6sm865411wbb.16.2012.01.12.03.01.05
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 03:01:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 11:00:57 +0000
From: Keir Fraser <keir@xen.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Message-ID: <CB346DE9.37475%keir@xen.org>
Thread-Topic: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
Thread-Index: AczRGXXwD1hCE8tX/kWP8sAFj4p9Vw==
In-Reply-To: <4F0EB6ED.3030900@invisiblethingslab.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12/01/2012 10:33, "Joanna Rutkowska" <joanna@invisiblethingslab.com>
wrote:

> On 01/11/12 18:21, Daniel De Graaf wrote:
>> This patch series allows xenstored to run in a stub domian started by
>> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
>> 
http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.htm>>
l
>> 
> 
> Daniel,
> 
> Can you explain what is the rationale for moving the xenstored into a
> stubdom? After all, if an attacker is able to compromise the xenstored,
> there should be many ways now how to compromise other VMs in the system?
> And it shouldn't matter whether the xenstored is in stubdom or whether
> in Dom0. E.g. the attacker might redirect the block fronts to us some
> false block backends, so that the VMs get compromised fs. One could
> probably think of other attacks as well...?

As you point out it's a critical component in itself, so I suppose this work
is mainly about isolating it from the big attack surfaces in dom0. It's of
questionable value unless dom0 itself can be deprivileged, or the big attack
surfaces themselves shuffled off into lesser-privileged domains. In a well
locked down dom0 I would say that the biggest attack surfaces are via things
like domain build, save/restore, and qemu, being intrinsic (ie unavoidable)
components of a Xen system which consume complex inputs. We can already do
qemu stubdoms, perhaps with some features missing still. Launching isolated,
de-privileged (eg can only act on the one specified domain),
domain-builder/saver/restorer stubdoms would be an interesting direction
imo. It's easy to be impressed with any disaggregation effort almost for its
own sake, and lose sight of the importance of basic security analysis as a
starting point.

 -- Keir

> joanna.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 11:03:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:03:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIQp-00072S-49; Thu, 12 Jan 2012 11:02: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 1RlIQn-000725-FP
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:02:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326365871!10533204!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 11297 invoked from network); 12 Jan 2012 10:57:51 -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; 12 Jan 2012 10:57:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlILs-000Cdd-5K; Thu, 12 Jan 2012 10:57:48 +0000
Date: Thu, 12 Jan 2012 10:57:48 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112105748.GB47092@ocelot.phlegethon.org>
References: <patchbomb.1326145285@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1326145285@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] x86/mm: Two hypervisor paging 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 16:41 -0500 on 09 Jan (1326127285), Andres Lagar-Cavilla wrote:
> - Disallow for good paging_prep: it's unsafe
> - Allow paging in of a page in paged-out state. This shortcuts the 
>   need to reference the page and trigger a populate event, thus saving
>   a complete control stack round-trip.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Acked-by: Tim Deegan <tim@xen.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 Jan 12 11:03:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:03:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIQp-00072S-49; Thu, 12 Jan 2012 11:02: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 1RlIQn-000725-FP
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:02:53 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326365871!10533204!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 11297 invoked from network); 12 Jan 2012 10:57:51 -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; 12 Jan 2012 10:57:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlILs-000Cdd-5K; Thu, 12 Jan 2012 10:57:48 +0000
Date: Thu, 12 Jan 2012 10:57:48 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112105748.GB47092@ocelot.phlegethon.org>
References: <patchbomb.1326145285@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1326145285@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] x86/mm: Two hypervisor paging 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 16:41 -0500 on 09 Jan (1326127285), Andres Lagar-Cavilla wrote:
> - Disallow for good paging_prep: it's unsafe
> - Allow paging in of a page in paged-out state. This shortcuts the 
>   need to reference the page and trigger a populate event, thus saving
>   a complete control stack round-trip.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Acked-by: Tim Deegan <tim@xen.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 Jan 12 11:04:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIS5-00079d-Jh; Thu, 12 Jan 2012 11:04:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RlIS4-000793-Hm
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:04:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326366131!59386655!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 15189 invoked from network); 12 Jan 2012 11:02:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 11:02:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlIRx-000Cft-Hv; Thu, 12 Jan 2012 11:04:05 +0000
Date: Thu, 12 Jan 2012 11:04:05 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112110405.GC47092@ocelot.phlegethon.org>
References: <2ed49e894084fb18ea58.1326145507@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2ed49e894084fb18ea58.1326145507@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 16:45 -0500 on 09 Jan (1326127507), Andres Lagar-Cavilla wrote:
> No functional changes, only code style issues.
> 
> One small diff in mem_sharing_gref_to_gfn() looks like a logic change,
> but it's not.  The flow was confusing, so it's been clarified.
> 
> This version does not differ from the last iteration.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:04:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:04:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIS5-00079d-Jh; Thu, 12 Jan 2012 11:04:13 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RlIS4-000793-Hm
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:04:12 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326366131!59386655!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 15189 invoked from network); 12 Jan 2012 11:02:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 11:02:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlIRx-000Cft-Hv; Thu, 12 Jan 2012 11:04:05 +0000
Date: Thu, 12 Jan 2012 11:04:05 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112110405.GC47092@ocelot.phlegethon.org>
References: <2ed49e894084fb18ea58.1326145507@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2ed49e894084fb18ea58.1326145507@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 16:45 -0500 on 09 Jan (1326127507), Andres Lagar-Cavilla wrote:
> No functional changes, only code style issues.
> 
> One small diff in mem_sharing_gref_to_gfn() looks like a logic change,
> but it's not.  The flow was confusing, so it's been clarified.
> 
> This version does not differ from the last iteration.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Applied, thanks.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:19:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:19:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIgO-0007VT-8p; Thu, 12 Jan 2012 11:19:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RlIgM-0007VO-Ad
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:18:58 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326367131!10584837!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3NzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16584 invoked from network); 12 Jan 2012 11:18:51 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 11:18:51 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 08B6420F96
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:18:51 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute1.internal (MEProxy); Thu, 12 Jan 2012 06:18:51 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=FL
	2k97obw8FTUtMsj9C+C7oxglY=; b=UBi3V7o2ObDIZ4b/UILtnpcYmWNDx1MS2g
	5cAcmyuD8deTELJ22im1NDw/cjoaQ/i+zEuRf6LwBcTLgdWQNY6N4AyQzqmyuUNv
	NPwebGyety8rNJiKw/o8t6hbZtjKETlVroAuu8cwTlBB+v7wulZ9nVFyy7n61dEW
	5wud5FGqI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=FL2k
	97obw8FTUtMsj9C+C7oxglY=; b=ihUNe2loThq65QYjNt6MmQwKNxNkZvHlWVJ6
	EqMWjEnqsacFIDV2skBs+bojGBDqQPUqoE0h+A94NUuiqJiZbOP+GOyV3SyI4ObC
	OAGd//D7h6V1C/QNvUWeHugWKrGk4cBPyaF4ughvMvNK90XhDJ8IH30q216zHHRc
	DnqxNk8=
X-Sasl-enc: 9FAfrMAhVqGzLa/x7LByGNQBIKqGoOFVUG1w4ENU/BqX 1326367130
Received: from [10.137.2.12] (afmg220.neoplus.adsl.tpnet.pl [178.42.58.220])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 425F78E023A;
	Thu, 12 Jan 2012 06:18:50 -0500 (EST)
Message-ID: <4F0EC198.9050406@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 12:18:48 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
In-Reply-To: <20120112104802.GA47092@ocelot.phlegethon.org>
X-Enigmail-Version: 1.3.4
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: [Xen-devel] On Dom0 disaggregation (was: Re: [RFC PATCH 0/18]
 Xenstore stub domain)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3507973325927486997=="
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)
--===============3507973325927486997==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig35F849397C618C67501DE8C7"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig35F849397C618C67501DE8C7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/12/12 11:48, Tim Deegan wrote:
> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
>> Daniel,
>>
>> Can you explain what is the rationale for moving the xenstored into a
>> stubdom? After all, if an attacker is able to compromise the xenstored=
,
>> there should be many ways now how to compromise other VMs in the syste=
m?
>> And it shouldn't matter whether the xenstored is in stubdom or whether=

>> in Dom0. E.g. the attacker might redirect the block fronts to us some
>> false block backends, so that the VMs get compromised fs. One could
>> probably think of other attacks as well...?
>=20
> I think the point is to protect xenstore from dom0, not dom0 from
> xenstore.  With stub-xenstore and driver domains, only the domain
> builder and PCIback need to have any privilege, and they can be moved
> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=3D1346278 ,
> http://tjd.phlegethon.org/words/sosp11-xoar.html)
>=20

In order for this to make sense from security point of view, you would
need to deprivilige Dom0. When considering this task, one should answer
the following questions:

1) Who manages the chipset (MCH)?
2) Who manages the input (keyboard, mouse)
3) Who manages the output (GPU, specifically critical on client systems)

=46rom the security point of view there is no point of isolating the
entities that manage the above between each other, because a compromise
of any of those entities leads to full system compromise (again, #3
applies to client systems).

Now, as you pointed out, we shall probably add another bullet to the
list, which is:

4) the xenstored

(although I'm not 100% if we couldn't somehow deprivilige xenstored).

So, we end up with a conclusion that there is no point separating those
4 functionalists between each other, and so it only make sense to host
them in the same domain. How about we call this domain "Dom0", then? ;)

(Sure, this "new Dom0" doesn't include net, USB, and perhaps even SATA
drivers, but we already have been doing this on Qubes, except for moving
out SATA/blkbackend from Dom0).

joanna.


--------------enig35F849397C618C67501DE8C7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPDsGYAAoJEDaIqHeRBUM0UI8IAIFfX9qU/P3IyCJ7KPdyExkG
BEaKBUu0EUPhbYeFTRNW1U8T8C35efs4ae0ZrSVqHKGKSg0Sq/lX6m1okfbVWW9J
Yrue/NYmFRTdIQWQVZusyf8doAhpN/WGlRtThjAzLWFUthe0Z3OX1lKf+ddwJZHW
UHNAsTVZObm0U5VcUmkFafOrpQYypVDcDEb4plBO1OesztNP+tQpw/wGMAcg6bf2
Xqf25Z9UpP5jnTTuxfEvpYDWBpPsnioAwmgssSsVNBNalbu4Q8JbqFzqrjDviOjO
d13kiVDub/4fJeBgvWB1Nvc/pJR/Pp3OQOFfdEHEO57oViJfDdAphS3OHU2bOA0=
=Uysv
-----END PGP SIGNATURE-----

--------------enig35F849397C618C67501DE8C7--


--===============3507973325927486997==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3507973325927486997==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:19:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:19:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIgO-0007VT-8p; Thu, 12 Jan 2012 11:19:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RlIgM-0007VO-Ad
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:18:58 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326367131!10584837!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3NzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16584 invoked from network); 12 Jan 2012 11:18:51 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 11:18:51 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 08B6420F96
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:18:51 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute1.internal (MEProxy); Thu, 12 Jan 2012 06:18:51 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=FL
	2k97obw8FTUtMsj9C+C7oxglY=; b=UBi3V7o2ObDIZ4b/UILtnpcYmWNDx1MS2g
	5cAcmyuD8deTELJ22im1NDw/cjoaQ/i+zEuRf6LwBcTLgdWQNY6N4AyQzqmyuUNv
	NPwebGyety8rNJiKw/o8t6hbZtjKETlVroAuu8cwTlBB+v7wulZ9nVFyy7n61dEW
	5wud5FGqI=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=FL2k
	97obw8FTUtMsj9C+C7oxglY=; b=ihUNe2loThq65QYjNt6MmQwKNxNkZvHlWVJ6
	EqMWjEnqsacFIDV2skBs+bojGBDqQPUqoE0h+A94NUuiqJiZbOP+GOyV3SyI4ObC
	OAGd//D7h6V1C/QNvUWeHugWKrGk4cBPyaF4ughvMvNK90XhDJ8IH30q216zHHRc
	DnqxNk8=
X-Sasl-enc: 9FAfrMAhVqGzLa/x7LByGNQBIKqGoOFVUG1w4ENU/BqX 1326367130
Received: from [10.137.2.12] (afmg220.neoplus.adsl.tpnet.pl [178.42.58.220])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 425F78E023A;
	Thu, 12 Jan 2012 06:18:50 -0500 (EST)
Message-ID: <4F0EC198.9050406@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 12:18:48 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
In-Reply-To: <20120112104802.GA47092@ocelot.phlegethon.org>
X-Enigmail-Version: 1.3.4
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: [Xen-devel] On Dom0 disaggregation (was: Re: [RFC PATCH 0/18]
 Xenstore stub domain)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3507973325927486997=="
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)
--===============3507973325927486997==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig35F849397C618C67501DE8C7"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig35F849397C618C67501DE8C7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/12/12 11:48, Tim Deegan wrote:
> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
>> Daniel,
>>
>> Can you explain what is the rationale for moving the xenstored into a
>> stubdom? After all, if an attacker is able to compromise the xenstored=
,
>> there should be many ways now how to compromise other VMs in the syste=
m?
>> And it shouldn't matter whether the xenstored is in stubdom or whether=

>> in Dom0. E.g. the attacker might redirect the block fronts to us some
>> false block backends, so that the VMs get compromised fs. One could
>> probably think of other attacks as well...?
>=20
> I think the point is to protect xenstore from dom0, not dom0 from
> xenstore.  With stub-xenstore and driver domains, only the domain
> builder and PCIback need to have any privilege, and they can be moved
> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=3D1346278 ,
> http://tjd.phlegethon.org/words/sosp11-xoar.html)
>=20

In order for this to make sense from security point of view, you would
need to deprivilige Dom0. When considering this task, one should answer
the following questions:

1) Who manages the chipset (MCH)?
2) Who manages the input (keyboard, mouse)
3) Who manages the output (GPU, specifically critical on client systems)

=46rom the security point of view there is no point of isolating the
entities that manage the above between each other, because a compromise
of any of those entities leads to full system compromise (again, #3
applies to client systems).

Now, as you pointed out, we shall probably add another bullet to the
list, which is:

4) the xenstored

(although I'm not 100% if we couldn't somehow deprivilige xenstored).

So, we end up with a conclusion that there is no point separating those
4 functionalists between each other, and so it only make sense to host
them in the same domain. How about we call this domain "Dom0", then? ;)

(Sure, this "new Dom0" doesn't include net, USB, and perhaps even SATA
drivers, but we already have been doing this on Qubes, except for moving
out SATA/blkbackend from Dom0).

joanna.


--------------enig35F849397C618C67501DE8C7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPDsGYAAoJEDaIqHeRBUM0UI8IAIFfX9qU/P3IyCJ7KPdyExkG
BEaKBUu0EUPhbYeFTRNW1U8T8C35efs4ae0ZrSVqHKGKSg0Sq/lX6m1okfbVWW9J
Yrue/NYmFRTdIQWQVZusyf8doAhpN/WGlRtThjAzLWFUthe0Z3OX1lKf+ddwJZHW
UHNAsTVZObm0U5VcUmkFafOrpQYypVDcDEb4plBO1OesztNP+tQpw/wGMAcg6bf2
Xqf25Z9UpP5jnTTuxfEvpYDWBpPsnioAwmgssSsVNBNalbu4Q8JbqFzqrjDviOjO
d13kiVDub/4fJeBgvWB1Nvc/pJR/Pp3OQOFfdEHEO57oViJfDdAphS3OHU2bOA0=
=Uysv
-----END PGP SIGNATURE-----

--------------enig35F849397C618C67501DE8C7--


--===============3507973325927486997==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3507973325927486997==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:28:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIp1-0007hw-6D; Thu, 12 Jan 2012 11:27: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 1RlIoz-0007hr-B1
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:27:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326367666!8624526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16449 invoked from network); 12 Jan 2012 11:27:47 -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;
	12 Jan 2012 11:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9967598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 11:27: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, 12 Jan 2012 11:27:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 12 Jan 2012 11:27:46 +0000
In-Reply-To: <20120112104802.GA47092@ocelot.phlegethon.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326367666.17210.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> > Daniel,
> > 
> > Can you explain what is the rationale for moving the xenstored into a
> > stubdom? After all, if an attacker is able to compromise the xenstored,
> > there should be many ways now how to compromise other VMs in the system?
> > And it shouldn't matter whether the xenstored is in stubdom or whether
> > in Dom0. E.g. the attacker might redirect the block fronts to us some
> > false block backends, so that the VMs get compromised fs. One could
> > probably think of other attacks as well...?
> 
> I think the point is to protect xenstore from dom0, not dom0 from
> xenstore.  With stub-xenstore and driver domains, only the domain
> builder and PCIback need to have any privilege, and they can be moved
> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> http://tjd.phlegethon.org/words/sosp11-xoar.html)

Also by isolating components you gain the ability to restart them
independently. Since xenstored is one of (the only?) dom0 component
which cannot be trivially restarted so putting it in a separate domain
means you can restart dom0.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:28:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:28:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIp1-0007hw-6D; Thu, 12 Jan 2012 11:27: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 1RlIoz-0007hr-B1
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:27:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326367666!8624526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16449 invoked from network); 12 Jan 2012 11:27:47 -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;
	12 Jan 2012 11:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9967598"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 11:27: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, 12 Jan 2012 11:27:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Thu, 12 Jan 2012 11:27:46 +0000
In-Reply-To: <20120112104802.GA47092@ocelot.phlegethon.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326367666.17210.244.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> > Daniel,
> > 
> > Can you explain what is the rationale for moving the xenstored into a
> > stubdom? After all, if an attacker is able to compromise the xenstored,
> > there should be many ways now how to compromise other VMs in the system?
> > And it shouldn't matter whether the xenstored is in stubdom or whether
> > in Dom0. E.g. the attacker might redirect the block fronts to us some
> > false block backends, so that the VMs get compromised fs. One could
> > probably think of other attacks as well...?
> 
> I think the point is to protect xenstore from dom0, not dom0 from
> xenstore.  With stub-xenstore and driver domains, only the domain
> builder and PCIback need to have any privilege, and they can be moved
> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> http://tjd.phlegethon.org/words/sosp11-xoar.html)

Also by isolating components you gain the ability to restart them
independently. Since xenstored is one of (the only?) dom0 component
which cannot be trivially restarted so putting it in a separate domain
means you can restart dom0.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:28:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIpJ-0007iv-JB; Thu, 12 Jan 2012 11:28: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 1RlIpH-0007iW-UL
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:28:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326367685!10698939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31406 invoked from network); 12 Jan 2012 11:28:05 -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 Jan 2012 11:28:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9967604"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 11:28:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 11:28:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 12 Jan 2012 11:28:04 +0000
In-Reply-To: <alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326367684.17210.245.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 07/10] 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 Wed, 2012-01-11 at 17:32 +0000, Stefano Stabellini wrote:
> On Fri, 6 Jan 2012, Ian Jackson wrote:
> > +struct libxl__egc {
> > +    /* for event-generating functions only */
> > +    struct libxl__gc gc;
> > +};
> 
> [...]
> 
> >  /*
> > + * Calling context and GC for event-generating functions:
> > + *
> > + * These are for use by parts of libxl which directly or indirectly
> > + * call libxl__event_occurred.  These contain a gc but also a list of
> > + * deferred events.
> > + *
> > + * Most code in libxlshould not need to initialise their own egc.
> > + * Even functions which generate specific kinds of events don't need
> > + * to - rather, they will be passed an egc into their own callback
> > + * function and should just use the one they're given.
> > + *
> > + * A handy idiom for functions taking an egc is:
> > + *     libxl__gc *gc = &egc->gc;
> > + *
> > + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> > + * within libxl, because libxl__egc_cleanup may call back into the
> > + * application.  This should be documented near the function
> > + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
> > + *
> > + * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
> > + * with the ctx *unlocked*.  So the right pattern has the EGC_...
> > + * macro calls on the outside of the CTX_... ones.
> > + */
> > +
> > +/* egc initialisation and destruction: */
> > +
> > +#define LIBXL_INIT_EGC(egc,ctx) do{             \
> > +        LIBXL_INIT_GC((egc).gc,ctx);            \
> > +        /* list of occurred events tbd */       \
> > +    } while(0)
> > +
> > +_hidden void libxl__egc_cleanup(libxl__egc *egc);
> > +
> > +/* convenience macros: */
> > +
> > +#define EGC_INIT(ctx)                       \
> > +    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
> > +    libxl__gc *gc = &egc->gc
> > +
> > +#define EGC_FREE           libxl__egc_cleanup(egc)
> 
> I still prefer the approach prototyped in
> http://marc.info/?l=xen-devel&m=132371797519877

I pointed out some issues with this in
http://marc.info/?l=xen-devel&m=132378496608354&w=2 which have gone
unanswered.

In particular error handling for the pthread_setspecific in
libxl__free_all seems pretty nasty to me since you would be introducing
a new failure path at the end of pretty much every libxl function. Worse
it is after the actual action of each function is otherwise complete so
you may end up having to undo stuff. I think it is going to be a lot of
work to fix all of those up properly.

Having frequently used pro/epilogue code (especially epilogue) which
cannot fail seems much simpler in general to me.

It occurred to me just now that having a different type of this type of
gc has the benefit that since libxl__event_occurred takes one it will
necessarily filter back up the call chain and help enforce/highlight the
requirement that functions which directly or indirectly call
libxl__event_occurred use an egc.

Ian.


> : avoid introducing
> restrictions on how libxl functions have to be called, unify egc and gc,
> make it possible to take the lock recursively and use the nested counter
> to figure out when to call the callbacks.
> It would make my head hurt less when I have to read/write this code,
> however others might react differently.
> 
> I don't think we'll ever get an agreement on this so I'll just step back
> and let other people decide what is the right approach.
> 
> Only one more thing: I would kindly ask to move all these event related
> functions to a different source file, to make it easier for people to
> understand which ones are different from the rest of the library.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:28:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:28:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIpJ-0007iv-JB; Thu, 12 Jan 2012 11:28: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 1RlIpH-0007iW-UL
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:28:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326367685!10698939!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31406 invoked from network); 12 Jan 2012 11:28:05 -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 Jan 2012 11:28:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9967604"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 11:28:05 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 11:28:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 12 Jan 2012 11:28:04 +0000
In-Reply-To: <alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326367684.17210.245.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 07/10] 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 Wed, 2012-01-11 at 17:32 +0000, Stefano Stabellini wrote:
> On Fri, 6 Jan 2012, Ian Jackson wrote:
> > +struct libxl__egc {
> > +    /* for event-generating functions only */
> > +    struct libxl__gc gc;
> > +};
> 
> [...]
> 
> >  /*
> > + * Calling context and GC for event-generating functions:
> > + *
> > + * These are for use by parts of libxl which directly or indirectly
> > + * call libxl__event_occurred.  These contain a gc but also a list of
> > + * deferred events.
> > + *
> > + * Most code in libxlshould not need to initialise their own egc.
> > + * Even functions which generate specific kinds of events don't need
> > + * to - rather, they will be passed an egc into their own callback
> > + * function and should just use the one they're given.
> > + *
> > + * A handy idiom for functions taking an egc is:
> > + *     libxl__gc *gc = &egc->gc;
> > + *
> > + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> > + * within libxl, because libxl__egc_cleanup may call back into the
> > + * application.  This should be documented near the function
> > + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
> > + *
> > + * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
> > + * with the ctx *unlocked*.  So the right pattern has the EGC_...
> > + * macro calls on the outside of the CTX_... ones.
> > + */
> > +
> > +/* egc initialisation and destruction: */
> > +
> > +#define LIBXL_INIT_EGC(egc,ctx) do{             \
> > +        LIBXL_INIT_GC((egc).gc,ctx);            \
> > +        /* list of occurred events tbd */       \
> > +    } while(0)
> > +
> > +_hidden void libxl__egc_cleanup(libxl__egc *egc);
> > +
> > +/* convenience macros: */
> > +
> > +#define EGC_INIT(ctx)                       \
> > +    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
> > +    libxl__gc *gc = &egc->gc
> > +
> > +#define EGC_FREE           libxl__egc_cleanup(egc)
> 
> I still prefer the approach prototyped in
> http://marc.info/?l=xen-devel&m=132371797519877

I pointed out some issues with this in
http://marc.info/?l=xen-devel&m=132378496608354&w=2 which have gone
unanswered.

In particular error handling for the pthread_setspecific in
libxl__free_all seems pretty nasty to me since you would be introducing
a new failure path at the end of pretty much every libxl function. Worse
it is after the actual action of each function is otherwise complete so
you may end up having to undo stuff. I think it is going to be a lot of
work to fix all of those up properly.

Having frequently used pro/epilogue code (especially epilogue) which
cannot fail seems much simpler in general to me.

It occurred to me just now that having a different type of this type of
gc has the benefit that since libxl__event_occurred takes one it will
necessarily filter back up the call chain and help enforce/highlight the
requirement that functions which directly or indirectly call
libxl__event_occurred use an egc.

Ian.


> : avoid introducing
> restrictions on how libxl functions have to be called, unify egc and gc,
> make it possible to take the lock recursively and use the nested counter
> to figure out when to call the callbacks.
> It would make my head hurt less when I have to read/write this code,
> however others might react differently.
> 
> I don't think we'll ever get an agreement on this so I'll just step back
> and let other people decide what is the right approach.
> 
> Only one more thing: I would kindly ask to move all these event related
> functions to a different source file, to make it easier for people to
> understand which ones are different from the rest of the library.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:34:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIv5-00080r-J5; Thu, 12 Jan 2012 11:34:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RlIv4-00080X-6W
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:34:10 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326368042!10666384!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11733 invoked from network); 12 Jan 2012 11:34:03 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 11:34:03 -0000
Received: by lagu2 with SMTP id u2so1262327lag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 03:34:02 -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
	:content-transfer-encoding;
	bh=rsxAEKMo9ELLN7pXXTwgeSyyUZKn+mDuUJ2Lwq61YVA=;
	b=QjqvwRO2EP/ilAEmefTHZyBHGSl/yNwEI1EnIOFTlvNrWJleimDNbMCQYYoPdXeX/t
	56gSf/Hrux9PyPAivI5K+ZK6qB93WpjTc748kWiGNWiayCPqGoxbVGYPISdl6fNTuyfH
	yxYdzz+RASYeLRHCOYwR3tHMUMdW9HL4Z7nFk=
Received: by 10.112.99.231 with SMTP id et7mr682221lbb.57.1326368042294; Thu,
	12 Jan 2012 03:34:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.131.194 with HTTP; Thu, 12 Jan 2012 03:33:46 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <1326367666.17210.244.camel@zakaz.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<1326367666.17210.244.camel@zakaz.uk.xensource.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 12 Jan 2012 15:33:46 +0400
X-Google-Sender-Auth: CDF5hWdc0XnrpwFtkhEz2Sa1wZc
Message-ID: <CACaajQu8_40trBFye83PBwdB-BwH2jRpxf9i9pwkLJbo3xB2gg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEyIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFRo
dSwgMjAxMi0wMS0xMiBhdCAxMDo0OCArMDAwMCwgVGltIERlZWdhbiB3cm90ZToKPj4gQXQgMTE6
MzMgKzAxMDAgb24gMTIgSmFuICgxMzI2MzY3OTk3KSwgSm9hbm5hIFJ1dGtvd3NrYSB3cm90ZToK
Pj4gPiBEYW5pZWwsCj4+ID4KPj4gPiBDYW4geW91IGV4cGxhaW4gd2hhdCBpcyB0aGUgcmF0aW9u
YWxlIGZvciBtb3ZpbmcgdGhlIHhlbnN0b3JlZCBpbnRvIGEKPj4gPiBzdHViZG9tPyBBZnRlciBh
bGwsIGlmIGFuIGF0dGFja2VyIGlzIGFibGUgdG8gY29tcHJvbWlzZSB0aGUgeGVuc3RvcmVkLAo+
PiA+IHRoZXJlIHNob3VsZCBiZSBtYW55IHdheXMgbm93IGhvdyB0byBjb21wcm9taXNlIG90aGVy
IFZNcyBpbiB0aGUgc3lzdGVtPwo+PiA+IEFuZCBpdCBzaG91bGRuJ3QgbWF0dGVyIHdoZXRoZXIg
dGhlIHhlbnN0b3JlZCBpcyBpbiBzdHViZG9tIG9yIHdoZXRoZXIKPj4gPiBpbiBEb20wLiBFLmcu
IHRoZSBhdHRhY2tlciBtaWdodCByZWRpcmVjdCB0aGUgYmxvY2sgZnJvbnRzIHRvIHVzIHNvbWUK
Pj4gPiBmYWxzZSBibG9jayBiYWNrZW5kcywgc28gdGhhdCB0aGUgVk1zIGdldCBjb21wcm9taXNl
ZCBmcy4gT25lIGNvdWxkCj4+ID4gcHJvYmFibHkgdGhpbmsgb2Ygb3RoZXIgYXR0YWNrcyBhcyB3
ZWxsLi4uPwo+Pgo+PiBJIHRoaW5rIHRoZSBwb2ludCBpcyB0byBwcm90ZWN0IHhlbnN0b3JlIGZy
b20gZG9tMCwgbm90IGRvbTAgZnJvbQo+PiB4ZW5zdG9yZS4gwqBXaXRoIHN0dWIteGVuc3RvcmUg
YW5kIGRyaXZlciBkb21haW5zLCBvbmx5IHRoZSBkb21haW4KPj4gYnVpbGRlciBhbmQgUENJYmFj
ayBuZWVkIHRvIGhhdmUgYW55IHByaXZpbGVnZSwgYW5kIHRoZXkgY2FuIGJlIG1vdmVkCj4+IG91
dCBvZiBkb20wIHRvbyAoZS5nLiwgaHR0cDovL2RsLmFjbS5vcmcvY2l0YXRpb24uY2ZtP2lkPTEz
NDYyNzggLAo+PiBodHRwOi8vdGpkLnBobGVnZXRob24ub3JnL3dvcmRzL3Nvc3AxMS14b2FyLmh0
bWwpCj4KPiBBbHNvIGJ5IGlzb2xhdGluZyBjb21wb25lbnRzIHlvdSBnYWluIHRoZSBhYmlsaXR5
IHRvIHJlc3RhcnQgdGhlbQo+IGluZGVwZW5kZW50bHkuIFNpbmNlIHhlbnN0b3JlZCBpcyBvbmUg
b2YgKHRoZSBvbmx5PykgZG9tMCBjb21wb25lbnQKPiB3aGljaCBjYW5ub3QgYmUgdHJpdmlhbGx5
IHJlc3RhcnRlZCBzbyBwdXR0aW5nIGl0IGluIGEgc2VwYXJhdGUgZG9tYWluCj4gbWVhbnMgeW91
IGNhbiByZXN0YXJ0IGRvbTAuCj4KPgoKSXMgdGhhdCBwb3NzaWJsZSBub3cgKG9yIGluIHNvbWUg
ZmVhdHVyZSkgdG8gcmVzdGFydCB4ZW5zdG9yZSBkb21haW4KYW5kIG5vdCBsb29zZSB3YXRjaGVz
PyBOb3cgaWYgaSBzYXZlIGFsbCBjb250ZW50cyBpbiB4ZW5zdG9yZSBhbmQKcmVzdGFydCB4ZW5z
dG9yZWQgaSdtIGxvb3NpbmcgYWxsIHdhdGNoZXMgYW5kIGRvbVUncyBub3QgYWJsZSB0byB3b3Jr
CmNvcnJlY3RseS4uLgoKLS0gClZhc2lsaXkgVG9sc3RvdiwKQ2xvZG8ucnUKZS1tYWlsOiB2LnRv
bHN0b3ZAc2VsZmlwLnJ1CmphYmJlcjogdmFzZUBzZWxmaXAucnUKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:34:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:34:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIv5-00080r-J5; Thu, 12 Jan 2012 11:34:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RlIv4-00080X-6W
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:34:10 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326368042!10666384!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11733 invoked from network); 12 Jan 2012 11:34:03 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 11:34:03 -0000
Received: by lagu2 with SMTP id u2so1262327lag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 03:34:02 -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
	:content-transfer-encoding;
	bh=rsxAEKMo9ELLN7pXXTwgeSyyUZKn+mDuUJ2Lwq61YVA=;
	b=QjqvwRO2EP/ilAEmefTHZyBHGSl/yNwEI1EnIOFTlvNrWJleimDNbMCQYYoPdXeX/t
	56gSf/Hrux9PyPAivI5K+ZK6qB93WpjTc748kWiGNWiayCPqGoxbVGYPISdl6fNTuyfH
	yxYdzz+RASYeLRHCOYwR3tHMUMdW9HL4Z7nFk=
Received: by 10.112.99.231 with SMTP id et7mr682221lbb.57.1326368042294; Thu,
	12 Jan 2012 03:34:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.131.194 with HTTP; Thu, 12 Jan 2012 03:33:46 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <1326367666.17210.244.camel@zakaz.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<1326367666.17210.244.camel@zakaz.uk.xensource.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 12 Jan 2012 15:33:46 +0400
X-Google-Sender-Auth: CDF5hWdc0XnrpwFtkhEz2Sa1wZc
Message-ID: <CACaajQu8_40trBFye83PBwdB-BwH2jRpxf9i9pwkLJbo3xB2gg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEyIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFRo
dSwgMjAxMi0wMS0xMiBhdCAxMDo0OCArMDAwMCwgVGltIERlZWdhbiB3cm90ZToKPj4gQXQgMTE6
MzMgKzAxMDAgb24gMTIgSmFuICgxMzI2MzY3OTk3KSwgSm9hbm5hIFJ1dGtvd3NrYSB3cm90ZToK
Pj4gPiBEYW5pZWwsCj4+ID4KPj4gPiBDYW4geW91IGV4cGxhaW4gd2hhdCBpcyB0aGUgcmF0aW9u
YWxlIGZvciBtb3ZpbmcgdGhlIHhlbnN0b3JlZCBpbnRvIGEKPj4gPiBzdHViZG9tPyBBZnRlciBh
bGwsIGlmIGFuIGF0dGFja2VyIGlzIGFibGUgdG8gY29tcHJvbWlzZSB0aGUgeGVuc3RvcmVkLAo+
PiA+IHRoZXJlIHNob3VsZCBiZSBtYW55IHdheXMgbm93IGhvdyB0byBjb21wcm9taXNlIG90aGVy
IFZNcyBpbiB0aGUgc3lzdGVtPwo+PiA+IEFuZCBpdCBzaG91bGRuJ3QgbWF0dGVyIHdoZXRoZXIg
dGhlIHhlbnN0b3JlZCBpcyBpbiBzdHViZG9tIG9yIHdoZXRoZXIKPj4gPiBpbiBEb20wLiBFLmcu
IHRoZSBhdHRhY2tlciBtaWdodCByZWRpcmVjdCB0aGUgYmxvY2sgZnJvbnRzIHRvIHVzIHNvbWUK
Pj4gPiBmYWxzZSBibG9jayBiYWNrZW5kcywgc28gdGhhdCB0aGUgVk1zIGdldCBjb21wcm9taXNl
ZCBmcy4gT25lIGNvdWxkCj4+ID4gcHJvYmFibHkgdGhpbmsgb2Ygb3RoZXIgYXR0YWNrcyBhcyB3
ZWxsLi4uPwo+Pgo+PiBJIHRoaW5rIHRoZSBwb2ludCBpcyB0byBwcm90ZWN0IHhlbnN0b3JlIGZy
b20gZG9tMCwgbm90IGRvbTAgZnJvbQo+PiB4ZW5zdG9yZS4gwqBXaXRoIHN0dWIteGVuc3RvcmUg
YW5kIGRyaXZlciBkb21haW5zLCBvbmx5IHRoZSBkb21haW4KPj4gYnVpbGRlciBhbmQgUENJYmFj
ayBuZWVkIHRvIGhhdmUgYW55IHByaXZpbGVnZSwgYW5kIHRoZXkgY2FuIGJlIG1vdmVkCj4+IG91
dCBvZiBkb20wIHRvbyAoZS5nLiwgaHR0cDovL2RsLmFjbS5vcmcvY2l0YXRpb24uY2ZtP2lkPTEz
NDYyNzggLAo+PiBodHRwOi8vdGpkLnBobGVnZXRob24ub3JnL3dvcmRzL3Nvc3AxMS14b2FyLmh0
bWwpCj4KPiBBbHNvIGJ5IGlzb2xhdGluZyBjb21wb25lbnRzIHlvdSBnYWluIHRoZSBhYmlsaXR5
IHRvIHJlc3RhcnQgdGhlbQo+IGluZGVwZW5kZW50bHkuIFNpbmNlIHhlbnN0b3JlZCBpcyBvbmUg
b2YgKHRoZSBvbmx5PykgZG9tMCBjb21wb25lbnQKPiB3aGljaCBjYW5ub3QgYmUgdHJpdmlhbGx5
IHJlc3RhcnRlZCBzbyBwdXR0aW5nIGl0IGluIGEgc2VwYXJhdGUgZG9tYWluCj4gbWVhbnMgeW91
IGNhbiByZXN0YXJ0IGRvbTAuCj4KPgoKSXMgdGhhdCBwb3NzaWJsZSBub3cgKG9yIGluIHNvbWUg
ZmVhdHVyZSkgdG8gcmVzdGFydCB4ZW5zdG9yZSBkb21haW4KYW5kIG5vdCBsb29zZSB3YXRjaGVz
PyBOb3cgaWYgaSBzYXZlIGFsbCBjb250ZW50cyBpbiB4ZW5zdG9yZSBhbmQKcmVzdGFydCB4ZW5z
dG9yZWQgaSdtIGxvb3NpbmcgYWxsIHdhdGNoZXMgYW5kIGRvbVUncyBub3QgYWJsZSB0byB3b3Jr
CmNvcnJlY3RseS4uLgoKLS0gClZhc2lsaXkgVG9sc3RvdiwKQ2xvZG8ucnUKZS1tYWlsOiB2LnRv
bHN0b3ZAc2VsZmlwLnJ1CmphYmJlcjogdmFzZUBzZWxmaXAucnUKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVu
LWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVu
LWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:35:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIwF-00084V-2H; Thu, 12 Jan 2012 11:35:23 +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 1RlIwD-00084C-Mq
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:35:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326368076!55645207!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 773 invoked from network); 12 Jan 2012 11:34:36 -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; 12 Jan 2012 11:34:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 11:35:15 +0000
Message-Id: <4F0ED3BC020000780006C120@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 11:36:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<6789e0d335e67e700f97.1326215229@gran.amd.com>
In-Reply-To: <6789e0d335e67e700f97.1326215229@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 03 of 14 V3] 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 10.01.12 at 18:07, Wei Wang <wei.wang2@amd.com> wrote:
> +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);

I suppose that this isn't really correct - addr_lo shouldn't really
need any shifting, or else base_raw would be a pretty odd entity.
I'll convert the function to use reg_to_u64() instead. While I
won't do this, I then also wonder whether the first two operations
could be converted to u64_to_reg(), and if so, what the purpose
of the whole function is (it would then merely shift the input
value to obtain a frame number).

Jan

> +
> +    ASSERT ( addr64 != 0 );
> +
> +    return addr64 >> PAGE_SHIFT;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:35:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:35:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIwF-00084V-2H; Thu, 12 Jan 2012 11:35:23 +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 1RlIwD-00084C-Mq
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:35:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326368076!55645207!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 773 invoked from network); 12 Jan 2012 11:34:36 -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; 12 Jan 2012 11:34:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 11:35:15 +0000
Message-Id: <4F0ED3BC020000780006C120@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 11:36:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<6789e0d335e67e700f97.1326215229@gran.amd.com>
In-Reply-To: <6789e0d335e67e700f97.1326215229@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org, xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 03 of 14 V3] 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 10.01.12 at 18:07, Wei Wang <wei.wang2@amd.com> wrote:
> +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);

I suppose that this isn't really correct - addr_lo shouldn't really
need any shifting, or else base_raw would be a pretty odd entity.
I'll convert the function to use reg_to_u64() instead. While I
won't do this, I then also wonder whether the first two operations
could be converted to u64_to_reg(), and if so, what the purpose
of the whole function is (it would then merely shift the input
value to obtain a frame number).

Jan

> +
> +    ASSERT ( addr64 != 0 );
> +
> +    return addr64 >> PAGE_SHIFT;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:36:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIwv-00088q-GQ; Thu, 12 Jan 2012 11:36:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RlIwt-00087l-P6
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:36:04 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326368156!10614302!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3NzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32442 invoked from network); 12 Jan 2012 11:35:57 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 11:35:57 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8DAF021FE3
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:35:56 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Thu, 12 Jan 2012 06:35:56 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=Bw
	AjaQdvt9xic4+m4Ss4IYsAYKs=; b=RF5PdDGTiTNWqMSe6RdmQIARvewQhl2ys8
	OeYu1xr+K4s/GfPvBl5tcsK0PLRN8+pc+5Gtvi7A38zk1evTDMeOMI3gnAqIn2qM
	pnaSuN+Uw4yw/tJW3jHLDSTY5c529GKQJhmJnl+IGDFXkdKoqwAgAGjJXIOIPh3+
	MJ3KPO7nw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=BwAj
	aQdvt9xic4+m4Ss4IYsAYKs=; b=Fj6V6hCR/3XWbdfYgVrR0uQLdOlIyeWl5nfJ
	x9hFXNzbjZnDKTKCBBeQzd2aDv+yJT0xmZJ+ccjYormW09isJ3D/mkLcc78B9VMO
	rvUDTer/5yiG252imXuhQucurgZzsqD9wZ33F4EXt1ESwLObbJMAUJht7yiW8js9
	mOCSRoo=
X-Sasl-enc: QK06BZ2CVks4RRYvvwC3FRYzlP0N4KFUB42mvNqTZ/TU 1326368156
Received: from [10.137.2.12] (afmg220.neoplus.adsl.tpnet.pl [178.42.58.220])
	by mail.messagingengine.com (Postfix) with ESMTPSA id B0710482487;
	Thu, 12 Jan 2012 06:35:55 -0500 (EST)
Message-ID: <4F0EC59A.8070905@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 12:35:54 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
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: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<1326367666.17210.244.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326367666.17210.244.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7296830909815970996=="
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)
--===============7296830909815970996==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig100C243CF697D91A379B3543"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig100C243CF697D91A379B3543
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/12/12 12:27, Ian Campbell wrote:
> On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
>> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
>>> Daniel,
>>>
>>> Can you explain what is the rationale for moving the xenstored into a=

>>> stubdom? After all, if an attacker is able to compromise the xenstore=
d,
>>> there should be many ways now how to compromise other VMs in the syst=
em?
>>> And it shouldn't matter whether the xenstored is in stubdom or whethe=
r
>>> in Dom0. E.g. the attacker might redirect the block fronts to us some=

>>> false block backends, so that the VMs get compromised fs. One could
>>> probably think of other attacks as well...?
>>
>> I think the point is to protect xenstore from dom0, not dom0 from
>> xenstore.  With stub-xenstore and driver domains, only the domain
>> builder and PCIback need to have any privilege, and they can be moved
>> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=3D1346278 ,
>> http://tjd.phlegethon.org/words/sosp11-xoar.html)
>=20
> Also by isolating components you gain the ability to restart them
> independently. Since xenstored is one of (the only?) dom0 component
> which cannot be trivially restarted so putting it in a separate domain
> means you can restart dom0.
>=20

But why would anybody want to restart Dom0, in the first place?


--------------enig100C243CF697D91A379B3543
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPDsWaAAoJEDaIqHeRBUM0XkkIAI250bLkYKJWp37SCHppU+Av
J1/xZ4n7dW2KvipFwSmmfj2ucPuH1BDhRVOTvQx3LmGJbjyUzXt6FI48NQTWJ+IL
cKH+Wb31ARUX6IH7ANA5i4DS8Sce4k22fTHfAsZzg0OAEqABZEmTXIeSQbvMmjBv
LHpB+ThMDTzLNOtK2MBpXZ9zHISKgH/pW1znE1K/fSM5WgGsxVwAH6DNnzmD7x/t
XSONKx4UhfOcOw+8tuzK9bPiAtewiUxleXO88JLXUt7FjDhrxdKv64y51KesIW22
8/0+aBpd7u0VaBsoO8FFSLTQxTi5WOL3dtiQ/xXN8JoRCy5Lqugp0eHwCGR2x5E=
=fTaE
-----END PGP SIGNATURE-----

--------------enig100C243CF697D91A379B3543--


--===============7296830909815970996==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7296830909815970996==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:36:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:36:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlIwv-00088q-GQ; Thu, 12 Jan 2012 11:36:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RlIwt-00087l-P6
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:36:04 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326368156!10614302!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3NzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32442 invoked from network); 12 Jan 2012 11:35:57 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 11:35:57 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8DAF021FE3
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:35:56 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
	by compute5.internal (MEProxy); Thu, 12 Jan 2012 06:35:56 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=Bw
	AjaQdvt9xic4+m4Ss4IYsAYKs=; b=RF5PdDGTiTNWqMSe6RdmQIARvewQhl2ys8
	OeYu1xr+K4s/GfPvBl5tcsK0PLRN8+pc+5Gtvi7A38zk1evTDMeOMI3gnAqIn2qM
	pnaSuN+Uw4yw/tJW3jHLDSTY5c529GKQJhmJnl+IGDFXkdKoqwAgAGjJXIOIPh3+
	MJ3KPO7nw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=BwAj
	aQdvt9xic4+m4Ss4IYsAYKs=; b=Fj6V6hCR/3XWbdfYgVrR0uQLdOlIyeWl5nfJ
	x9hFXNzbjZnDKTKCBBeQzd2aDv+yJT0xmZJ+ccjYormW09isJ3D/mkLcc78B9VMO
	rvUDTer/5yiG252imXuhQucurgZzsqD9wZ33F4EXt1ESwLObbJMAUJht7yiW8js9
	mOCSRoo=
X-Sasl-enc: QK06BZ2CVks4RRYvvwC3FRYzlP0N4KFUB42mvNqTZ/TU 1326368156
Received: from [10.137.2.12] (afmg220.neoplus.adsl.tpnet.pl [178.42.58.220])
	by mail.messagingengine.com (Postfix) with ESMTPSA id B0710482487;
	Thu, 12 Jan 2012 06:35:55 -0500 (EST)
Message-ID: <4F0EC59A.8070905@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 12:35:54 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
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: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<1326367666.17210.244.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326367666.17210.244.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7296830909815970996=="
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)
--===============7296830909815970996==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig100C243CF697D91A379B3543"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig100C243CF697D91A379B3543
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/12/12 12:27, Ian Campbell wrote:
> On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
>> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
>>> Daniel,
>>>
>>> Can you explain what is the rationale for moving the xenstored into a=

>>> stubdom? After all, if an attacker is able to compromise the xenstore=
d,
>>> there should be many ways now how to compromise other VMs in the syst=
em?
>>> And it shouldn't matter whether the xenstored is in stubdom or whethe=
r
>>> in Dom0. E.g. the attacker might redirect the block fronts to us some=

>>> false block backends, so that the VMs get compromised fs. One could
>>> probably think of other attacks as well...?
>>
>> I think the point is to protect xenstore from dom0, not dom0 from
>> xenstore.  With stub-xenstore and driver domains, only the domain
>> builder and PCIback need to have any privilege, and they can be moved
>> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=3D1346278 ,
>> http://tjd.phlegethon.org/words/sosp11-xoar.html)
>=20
> Also by isolating components you gain the ability to restart them
> independently. Since xenstored is one of (the only?) dom0 component
> which cannot be trivially restarted so putting it in a separate domain
> means you can restart dom0.
>=20

But why would anybody want to restart Dom0, in the first place?


--------------enig100C243CF697D91A379B3543
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPDsWaAAoJEDaIqHeRBUM0XkkIAI250bLkYKJWp37SCHppU+Av
J1/xZ4n7dW2KvipFwSmmfj2ucPuH1BDhRVOTvQx3LmGJbjyUzXt6FI48NQTWJ+IL
cKH+Wb31ARUX6IH7ANA5i4DS8Sce4k22fTHfAsZzg0OAEqABZEmTXIeSQbvMmjBv
LHpB+ThMDTzLNOtK2MBpXZ9zHISKgH/pW1znE1K/fSM5WgGsxVwAH6DNnzmD7x/t
XSONKx4UhfOcOw+8tuzK9bPiAtewiUxleXO88JLXUt7FjDhrxdKv64y51KesIW22
8/0+aBpd7u0VaBsoO8FFSLTQxTi5WOL3dtiQ/xXN8JoRCy5Lqugp0eHwCGR2x5E=
=fTaE
-----END PGP SIGNATURE-----

--------------enig100C243CF697D91A379B3543--


--===============7296830909815970996==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7296830909815970996==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:47:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJ7X-0008VA-MB; Thu, 12 Jan 2012 11:47: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 1RlJ7V-0008V4-HI
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:47:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326368814!8812433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18607 invoked from network); 12 Jan 2012 11:46:54 -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;
	12 Jan 2012 11:46:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9967998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 11:46:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 11:46:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 12 Jan 2012 11:46:30 +0000
In-Reply-To: <CACaajQu8_40trBFye83PBwdB-BwH2jRpxf9i9pwkLJbo3xB2gg@mail.gmail.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<1326367666.17210.244.camel@zakaz.uk.xensource.com>
	<CACaajQu8_40trBFye83PBwdB-BwH2jRpxf9i9pwkLJbo3xB2gg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326368790.17210.247.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 11:33 +0000, Vasiliy Tolstov wrote:
> 2012/1/12 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
> >> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> >> > Daniel,
> >> >
> >> > Can you explain what is the rationale for moving the xenstored into a
> >> > stubdom? After all, if an attacker is able to compromise the xenstored,
> >> > there should be many ways now how to compromise other VMs in the system?
> >> > And it shouldn't matter whether the xenstored is in stubdom or whether
> >> > in Dom0. E.g. the attacker might redirect the block fronts to us some
> >> > false block backends, so that the VMs get compromised fs. One could
> >> > probably think of other attacks as well...?
> >>
> >> I think the point is to protect xenstore from dom0, not dom0 from
> >> xenstore.  With stub-xenstore and driver domains, only the domain
> >> builder and PCIback need to have any privilege, and they can be moved
> >> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> >> http://tjd.phlegethon.org/words/sosp11-xoar.html)
> >
> > Also by isolating components you gain the ability to restart them
> > independently. Since xenstored is one of (the only?) dom0 component
> > which cannot be trivially restarted so putting it in a separate domain
> > means you can restart dom0.
> >
> >
> 
> Is that possible now (or in some feature) to restart xenstore domain
> and not loose watches? Now if i save all contents in xenstore and
> restart xenstored i'm loosing all watches and domU's not able to work
> correctly...

I've heard that it is possible to do this with the ocaml xenstored. I
haven't tried it myself.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:47:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJ7X-0008VA-MB; Thu, 12 Jan 2012 11:47: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 1RlJ7V-0008V4-HI
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:47:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326368814!8812433!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18607 invoked from network); 12 Jan 2012 11:46:54 -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;
	12 Jan 2012 11:46:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9967998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 11:46:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 12 Jan 2012 11:46:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Thu, 12 Jan 2012 11:46:30 +0000
In-Reply-To: <CACaajQu8_40trBFye83PBwdB-BwH2jRpxf9i9pwkLJbo3xB2gg@mail.gmail.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<1326367666.17210.244.camel@zakaz.uk.xensource.com>
	<CACaajQu8_40trBFye83PBwdB-BwH2jRpxf9i9pwkLJbo3xB2gg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326368790.17210.247.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 11:33 +0000, Vasiliy Tolstov wrote:
> 2012/1/12 Ian Campbell <Ian.Campbell@citrix.com>:
> > On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
> >> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> >> > Daniel,
> >> >
> >> > Can you explain what is the rationale for moving the xenstored into a
> >> > stubdom? After all, if an attacker is able to compromise the xenstored,
> >> > there should be many ways now how to compromise other VMs in the system?
> >> > And it shouldn't matter whether the xenstored is in stubdom or whether
> >> > in Dom0. E.g. the attacker might redirect the block fronts to us some
> >> > false block backends, so that the VMs get compromised fs. One could
> >> > probably think of other attacks as well...?
> >>
> >> I think the point is to protect xenstore from dom0, not dom0 from
> >> xenstore.  With stub-xenstore and driver domains, only the domain
> >> builder and PCIback need to have any privilege, and they can be moved
> >> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> >> http://tjd.phlegethon.org/words/sosp11-xoar.html)
> >
> > Also by isolating components you gain the ability to restart them
> > independently. Since xenstored is one of (the only?) dom0 component
> > which cannot be trivially restarted so putting it in a separate domain
> > means you can restart dom0.
> >
> >
> 
> Is that possible now (or in some feature) to restart xenstore domain
> and not loose watches? Now if i save all contents in xenstore and
> restart xenstored i'm loosing all watches and domU's not able to work
> correctly...

I've heard that it is possible to do this with the ocaml xenstored. I
haven't tried it myself.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:47:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJ7Z-0008VL-2G; Thu, 12 Jan 2012 11:47:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlJ7X-0008V5-OA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326368814!8812433!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18747 invoked from network); 12 Jan 2012 11:46:57 -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;
	12 Jan 2012 11:46:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9968006"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 11:46: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, 12 Jan 2012 11:46:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 11:46:43 +0000
In-Reply-To: <4F0EC59A.8070905@invisiblethingslab.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<1326367666.17210.244.camel@zakaz.uk.xensource.com>
	<4F0EC59A.8070905@invisiblethingslab.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326368803.17210.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 11:35 +0000, Joanna Rutkowska wrote:
> On 01/12/12 12:27, Ian Campbell wrote:
> > On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
> >> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> >>> Daniel,
> >>>
> >>> Can you explain what is the rationale for moving the xenstored into a
> >>> stubdom? After all, if an attacker is able to compromise the xenstored,
> >>> there should be many ways now how to compromise other VMs in the system?
> >>> And it shouldn't matter whether the xenstored is in stubdom or whether
> >>> in Dom0. E.g. the attacker might redirect the block fronts to us some
> >>> false block backends, so that the VMs get compromised fs. One could
> >>> probably think of other attacks as well...?
> >>
> >> I think the point is to protect xenstore from dom0, not dom0 from
> >> xenstore.  With stub-xenstore and driver domains, only the domain
> >> builder and PCIback need to have any privilege, and they can be moved
> >> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> >> http://tjd.phlegethon.org/words/sosp11-xoar.html)
> > 
> > Also by isolating components you gain the ability to restart them
> > independently. Since xenstored is one of (the only?) dom0 component
> > which cannot be trivially restarted so putting it in a separate domain
> > means you can restart dom0.
> > 
> 
> But why would anybody want to restart Dom0, in the first place?

To patch the kernel?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:47:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:47:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJ7Z-0008VL-2G; Thu, 12 Jan 2012 11:47:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlJ7X-0008V5-OA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:47:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326368814!8812433!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18747 invoked from network); 12 Jan 2012 11:46:57 -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;
	12 Jan 2012 11:46:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9968006"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 11:46: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, 12 Jan 2012 11:46:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 11:46:43 +0000
In-Reply-To: <4F0EC59A.8070905@invisiblethingslab.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<1326367666.17210.244.camel@zakaz.uk.xensource.com>
	<4F0EC59A.8070905@invisiblethingslab.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326368803.17210.248.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 11:35 +0000, Joanna Rutkowska wrote:
> On 01/12/12 12:27, Ian Campbell wrote:
> > On Thu, 2012-01-12 at 10:48 +0000, Tim Deegan wrote:
> >> At 11:33 +0100 on 12 Jan (1326367997), Joanna Rutkowska wrote:
> >>> Daniel,
> >>>
> >>> Can you explain what is the rationale for moving the xenstored into a
> >>> stubdom? After all, if an attacker is able to compromise the xenstored,
> >>> there should be many ways now how to compromise other VMs in the system?
> >>> And it shouldn't matter whether the xenstored is in stubdom or whether
> >>> in Dom0. E.g. the attacker might redirect the block fronts to us some
> >>> false block backends, so that the VMs get compromised fs. One could
> >>> probably think of other attacks as well...?
> >>
> >> I think the point is to protect xenstore from dom0, not dom0 from
> >> xenstore.  With stub-xenstore and driver domains, only the domain
> >> builder and PCIback need to have any privilege, and they can be moved
> >> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> >> http://tjd.phlegethon.org/words/sosp11-xoar.html)
> > 
> > Also by isolating components you gain the ability to restart them
> > independently. Since xenstored is one of (the only?) dom0 component
> > which cannot be trivially restarted so putting it in a separate domain
> > means you can restart dom0.
> > 
> 
> But why would anybody want to restart Dom0, in the first place?

To patch the kernel?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 11:57:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJHB-0000S6-Ch; Thu, 12 Jan 2012 11:57:01 +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 1RlJHA-0000S1-LH
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:57:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326369412!2880604!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 27915 invoked from network); 12 Jan 2012 11:56:53 -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; 12 Jan 2012 11:56:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlJH0-000Cv1-JY; Thu, 12 Jan 2012 11:56:50 +0000
Date: Thu, 12 Jan 2012 11:56:50 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112115650.GD47092@ocelot.phlegethon.org>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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

Hi, 

This looks fine to me; this time I'd like Olaf to review and test it
before I commit it. :)

A few comments inline below -- mostly nits about style. 

At 13:28 -0500 on 11 Jan (1326288504), Andres Lagar-Cavilla wrote:
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Housekeeping: please keep Olaf's Signed-off-by: line to cover the parts
of this patch that he's certifying. 

> diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4188,25 +4188,31 @@ static int hvm_memory_event_traps(long p
>                                    unsigned long value, unsigned long old, 
>                                    bool_t gla_valid, unsigned long gla) 
>  {
> +    int rc;
>      struct vcpu* v = current;
>      struct domain *d = v->domain;
>      mem_event_request_t req;
> -    int rc;
>  

Please try to avoid this kind of unrelated shuffling (and I saw some
whitespace changes later on as well).  It's not a big deal, but it makes
reviewing a bit easier and avoids unnecessarily clashing with other
patches. 

> diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c

> +
> +/*
> + * mem_event_wake_requesters() will wakeup vcpus waiting for room in the

DYM mem_event_wake_blocked() ?

> + * ring. These vCPUs were paused on their way out after placing an event,
> + * but need to be resumed where the ring is capable of processing at least
> + * one event from them.
> + */
> +static void mem_event_wake_blocked(struct domain *d, struct mem_event_domain *med)
> +{
> +    struct vcpu *v;
> +    int online = d->max_vcpus;
> +    int avail_req = mem_event_ring_available(med);
> +
> +    if( avail_req <= 0 || med->blocked == 0 )

s/if(/if (/

> +        return;
> +
> +    /*
> +     * We ensure that we only have vCPUs online if there are enough free slots
> +     * for their memory events to be processed.  This will ensure that no
> +     * memory events are lost (due to the fact that certain types of events
> +     * cannot be replayed, we need to ensure that there is space in the ring
> +     * for when they are hit). 
> +     * See comment below in mem_event_put_request().
> +     */
> +    for_each_vcpu ( d, v )
> +        if ( test_bit(med->pause_flag, &v->pause_flags) )
> +            online--;
> +
> +    ASSERT(online == (d->max_vcpus - med->blocked));

Maybe better to do the cheap calculation as the default and the more
expensive one for the ASSERT?

> +    /* We remember which vcpu last woke up to avoid scanning always linearly
> +     * from zero and starving higher-numbered vcpus under high load */
> +    if ( d->vcpu )
> +    {
> +        int i, j, k;
> +
> +        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
> +        {
> +            k = i % d->max_vcpus;
> +            v = d->vcpu[k];
> +            if ( !v )
> +                continue;
> +
> +            if ( !(med->blocked) || online >= avail_req )
> +               break;
> +
> +            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
> +            {
> +                vcpu_unpause(v);
> +                online++;
> +                med->blocked--;
> +                med->last_vcpu_wake_up = k;
> +            }
> +        }
> +    }
> +}
> +
> +/*
> + * In the event that a vCPU attempted to place an event in the ring and
> + * was unable to do so, it is queued on a wait queue.  These are woken as
> + * needed, and take precedence over the blocked vCPUs.
> + */
> +static void mem_event_wake_queued(struct domain *d, struct mem_event_domain *med)
> +{
> +    int avail_req = mem_event_ring_available(med);
> +
> +    if ( avail_req > 0 )
> +        wake_up_nr(&med->wq, avail_req);
> +}
> +
> +/*
> + * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to

DYM mem_event_wake() ?

> + * become available.  If we have queued vCPUs, they get top priority. We
> + * are guaranteed that they will go through code paths that will eventually
> + * call mem_event_wake() again, ensuring that any blocked vCPUs will get
> + * unpaused once all the queued vCPUs have made it through.
> + */
> +void mem_event_wake(struct domain *d, struct mem_event_domain *med)
> +{
> +    if (!list_empty(&med->wq.list))
> +        mem_event_wake_queued(d, med);
> +    else
> +        mem_event_wake_blocked(d, med);
> +}
> +
> +static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
> +{
> +    if( med->ring_page )

s/if(/if (/g  :)

> +    {
> +        struct vcpu *v;
> +
> +        mem_event_ring_lock(med);
> +
> +        if (!list_empty(&med->wq.list))

if ( ... ) 

> +        {
> +            mem_event_ring_unlock(med);
> +            return -EBUSY;
> +        }
> +
> +        unmap_domain_page(med->ring_page);
> +        med->ring_page = NULL;
> +
> +        unmap_domain_page(med->shared_page);
> +        med->shared_page = NULL;
> +
> +        /* Wake up everybody */
> +        wake_up_all(&med->wq);
> +
> +        /* Unblock all vCPUs */ 
> +        for_each_vcpu ( d, v )
> +        {
> +            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
> +            {
> +                vcpu_unpause(v);
> +                med->blocked--;
> +            }
> +        }
> +
> +        mem_event_ring_unlock(med);
> +    }
>  
>      return 0;
>  }
>  
> -void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
> +static inline void mem_event_release_slot(struct domain *d,
> +                                          struct mem_event_domain *med)
> +{
> +    /* Update the accounting */
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
> +
> +    /* Kick any waiters */
> +    mem_event_wake(d, med);
> +}
> +
> +/*
> + * mem_event_mark_and_pause() tags vcpu and put it to sleep.
> + * The vcpu will resume execution in mem_event_wake_waiters().
> + */
> +void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
> +{
> +    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
> +    {
> +        vcpu_pause_nosync(v);
> +        med->blocked++;
> +    }
> +}
> +
> +/*
> + * This must be preceeded by a call to claim_slot(), and is guaranteed to

preceded

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 Jan 12 11:57:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 11:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJHB-0000S6-Ch; Thu, 12 Jan 2012 11:57:01 +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 1RlJHA-0000S1-LH
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 11:57:00 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326369412!2880604!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 27915 invoked from network); 12 Jan 2012 11:56:53 -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; 12 Jan 2012 11:56:53 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlJH0-000Cv1-JY; Thu, 12 Jan 2012 11:56:50 +0000
Date: Thu, 12 Jan 2012 11:56:50 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112115650.GD47092@ocelot.phlegethon.org>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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

Hi, 

This looks fine to me; this time I'd like Olaf to review and test it
before I commit it. :)

A few comments inline below -- mostly nits about style. 

At 13:28 -0500 on 11 Jan (1326288504), Andres Lagar-Cavilla wrote:
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Housekeeping: please keep Olaf's Signed-off-by: line to cover the parts
of this patch that he's certifying. 

> diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4188,25 +4188,31 @@ static int hvm_memory_event_traps(long p
>                                    unsigned long value, unsigned long old, 
>                                    bool_t gla_valid, unsigned long gla) 
>  {
> +    int rc;
>      struct vcpu* v = current;
>      struct domain *d = v->domain;
>      mem_event_request_t req;
> -    int rc;
>  

Please try to avoid this kind of unrelated shuffling (and I saw some
whitespace changes later on as well).  It's not a big deal, but it makes
reviewing a bit easier and avoids unnecessarily clashing with other
patches. 

> diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/mm/mem_event.c
> --- a/xen/arch/x86/mm/mem_event.c
> +++ b/xen/arch/x86/mm/mem_event.c

> +
> +/*
> + * mem_event_wake_requesters() will wakeup vcpus waiting for room in the

DYM mem_event_wake_blocked() ?

> + * ring. These vCPUs were paused on their way out after placing an event,
> + * but need to be resumed where the ring is capable of processing at least
> + * one event from them.
> + */
> +static void mem_event_wake_blocked(struct domain *d, struct mem_event_domain *med)
> +{
> +    struct vcpu *v;
> +    int online = d->max_vcpus;
> +    int avail_req = mem_event_ring_available(med);
> +
> +    if( avail_req <= 0 || med->blocked == 0 )

s/if(/if (/

> +        return;
> +
> +    /*
> +     * We ensure that we only have vCPUs online if there are enough free slots
> +     * for their memory events to be processed.  This will ensure that no
> +     * memory events are lost (due to the fact that certain types of events
> +     * cannot be replayed, we need to ensure that there is space in the ring
> +     * for when they are hit). 
> +     * See comment below in mem_event_put_request().
> +     */
> +    for_each_vcpu ( d, v )
> +        if ( test_bit(med->pause_flag, &v->pause_flags) )
> +            online--;
> +
> +    ASSERT(online == (d->max_vcpus - med->blocked));

Maybe better to do the cheap calculation as the default and the more
expensive one for the ASSERT?

> +    /* We remember which vcpu last woke up to avoid scanning always linearly
> +     * from zero and starving higher-numbered vcpus under high load */
> +    if ( d->vcpu )
> +    {
> +        int i, j, k;
> +
> +        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
> +        {
> +            k = i % d->max_vcpus;
> +            v = d->vcpu[k];
> +            if ( !v )
> +                continue;
> +
> +            if ( !(med->blocked) || online >= avail_req )
> +               break;
> +
> +            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
> +            {
> +                vcpu_unpause(v);
> +                online++;
> +                med->blocked--;
> +                med->last_vcpu_wake_up = k;
> +            }
> +        }
> +    }
> +}
> +
> +/*
> + * In the event that a vCPU attempted to place an event in the ring and
> + * was unable to do so, it is queued on a wait queue.  These are woken as
> + * needed, and take precedence over the blocked vCPUs.
> + */
> +static void mem_event_wake_queued(struct domain *d, struct mem_event_domain *med)
> +{
> +    int avail_req = mem_event_ring_available(med);
> +
> +    if ( avail_req > 0 )
> +        wake_up_nr(&med->wq, avail_req);
> +}
> +
> +/*
> + * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring to

DYM mem_event_wake() ?

> + * become available.  If we have queued vCPUs, they get top priority. We
> + * are guaranteed that they will go through code paths that will eventually
> + * call mem_event_wake() again, ensuring that any blocked vCPUs will get
> + * unpaused once all the queued vCPUs have made it through.
> + */
> +void mem_event_wake(struct domain *d, struct mem_event_domain *med)
> +{
> +    if (!list_empty(&med->wq.list))
> +        mem_event_wake_queued(d, med);
> +    else
> +        mem_event_wake_blocked(d, med);
> +}
> +
> +static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
> +{
> +    if( med->ring_page )

s/if(/if (/g  :)

> +    {
> +        struct vcpu *v;
> +
> +        mem_event_ring_lock(med);
> +
> +        if (!list_empty(&med->wq.list))

if ( ... ) 

> +        {
> +            mem_event_ring_unlock(med);
> +            return -EBUSY;
> +        }
> +
> +        unmap_domain_page(med->ring_page);
> +        med->ring_page = NULL;
> +
> +        unmap_domain_page(med->shared_page);
> +        med->shared_page = NULL;
> +
> +        /* Wake up everybody */
> +        wake_up_all(&med->wq);
> +
> +        /* Unblock all vCPUs */ 
> +        for_each_vcpu ( d, v )
> +        {
> +            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
> +            {
> +                vcpu_unpause(v);
> +                med->blocked--;
> +            }
> +        }
> +
> +        mem_event_ring_unlock(med);
> +    }
>  
>      return 0;
>  }
>  
> -void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
> +static inline void mem_event_release_slot(struct domain *d,
> +                                          struct mem_event_domain *med)
> +{
> +    /* Update the accounting */
> +    if ( current->domain == d )
> +        med->target_producers--;
> +    else
> +        med->foreign_producers--;
> +
> +    /* Kick any waiters */
> +    mem_event_wake(d, med);
> +}
> +
> +/*
> + * mem_event_mark_and_pause() tags vcpu and put it to sleep.
> + * The vcpu will resume execution in mem_event_wake_waiters().
> + */
> +void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
> +{
> +    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
> +    {
> +        vcpu_pause_nosync(v);
> +        med->blocked++;
> +    }
> +}
> +
> +/*
> + * This must be preceeded by a call to claim_slot(), and is guaranteed to

preceded

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 Jan 12 12:13:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJWs-0000jF-6G; Thu, 12 Jan 2012 12:13:14 +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 1RlJWr-0000iz-15
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:13:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326370386!8811044!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 16115 invoked from network); 12 Jan 2012 12:13:06 -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; 12 Jan 2012 12:13:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlJWi-000Cyh-1Z; Thu, 12 Jan 2012 12:13:04 +0000
Date: Thu, 12 Jan 2012 12:13:03 +0000
From: Tim Deegan <tim@xen.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120112121303.GE47092@ocelot.phlegethon.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<4F0EC198.9050406@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0EC198.9050406@invisiblethingslab.com>
User-Agent: Mutt/1.4.2.1i
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] On Dom0 disaggregation (was: Re: [RFC PATCH 0/18]
	Xenstore stub domain)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:18 +0100 on 12 Jan (1326370728), Joanna Rutkowska wrote:
> On 01/12/12 11:48, Tim Deegan wrote:
> > I think the point is to protect xenstore from dom0, not dom0 from
> > xenstore.  With stub-xenstore and driver domains, only the domain
> > builder and PCIback need to have any privilege, and they can be moved
> > out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> > http://tjd.phlegethon.org/words/sosp11-xoar.html)
> 
> In order for this to make sense from security point of view, you would
> need to deprivilige Dom0.

Yep.  That's what Xoar did (or, if you prefer, it moved all dom0's
components out and then got rid of it).

> When considering this task, one should answer
> the following questions:
> 
> 1) Who manages the chipset (MCH)?

A driver domain that contains PCIback.  It doesn't need general
privlege (e.g. for scheduler or memory operations).

> 2) Who manages the input (keyboard, mouse)
> 3) Who manages the output (GPU, specifically critical on client systems)
> 
> From the security point of view there is no point of isolating the
> entities that manage the above between each other, because a compromise
> of any of those entities leads to full system compromise (again, #3
> applies to client systems).

#2 is really a client-only thing as well.  Serial console input for
servers is owned directly by the hypervisor.

> Now, as you pointed out, we shall probably add another bullet to the
> list, which is:
> 
> 4) the xenstored
> 
> (although I'm not 100% if we couldn't somehow deprivilige xenstored).

Yes we could (and Xoar did).  IIRC the only reason it needs privilege is
to map the rings and that can be sorted out by having the builder
pre-load a grant entry.

> So, we end up with a conclusion that there is no point separating those
> 4 functionalists between each other, and so it only make sense to host
> them in the same domain. How about we call this domain "Dom0", then? ;)

So you're saying that the PCIback domain (which owns the chipsets) might
as well host Xenstore since either of them could hose the system.
Maybe so.  In Xoar we had two reasons not to do that:
 - in some configurations you could shut that domain down after boot
   (though tbh doing that leads to poor error handling!); and
 - we were doing other hardening of Xenstore that involved breaking it 
   up into more than one VM. 

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 Jan 12 12:13:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:13:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJWs-0000jF-6G; Thu, 12 Jan 2012 12:13:14 +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 1RlJWr-0000iz-15
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:13:13 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326370386!8811044!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 16115 invoked from network); 12 Jan 2012 12:13:06 -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; 12 Jan 2012 12:13:06 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlJWi-000Cyh-1Z; Thu, 12 Jan 2012 12:13:04 +0000
Date: Thu, 12 Jan 2012 12:13:03 +0000
From: Tim Deegan <tim@xen.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120112121303.GE47092@ocelot.phlegethon.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<4F0EC198.9050406@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0EC198.9050406@invisiblethingslab.com>
User-Agent: Mutt/1.4.2.1i
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] On Dom0 disaggregation (was: Re: [RFC PATCH 0/18]
	Xenstore stub domain)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:18 +0100 on 12 Jan (1326370728), Joanna Rutkowska wrote:
> On 01/12/12 11:48, Tim Deegan wrote:
> > I think the point is to protect xenstore from dom0, not dom0 from
> > xenstore.  With stub-xenstore and driver domains, only the domain
> > builder and PCIback need to have any privilege, and they can be moved
> > out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
> > http://tjd.phlegethon.org/words/sosp11-xoar.html)
> 
> In order for this to make sense from security point of view, you would
> need to deprivilige Dom0.

Yep.  That's what Xoar did (or, if you prefer, it moved all dom0's
components out and then got rid of it).

> When considering this task, one should answer
> the following questions:
> 
> 1) Who manages the chipset (MCH)?

A driver domain that contains PCIback.  It doesn't need general
privlege (e.g. for scheduler or memory operations).

> 2) Who manages the input (keyboard, mouse)
> 3) Who manages the output (GPU, specifically critical on client systems)
> 
> From the security point of view there is no point of isolating the
> entities that manage the above between each other, because a compromise
> of any of those entities leads to full system compromise (again, #3
> applies to client systems).

#2 is really a client-only thing as well.  Serial console input for
servers is owned directly by the hypervisor.

> Now, as you pointed out, we shall probably add another bullet to the
> list, which is:
> 
> 4) the xenstored
> 
> (although I'm not 100% if we couldn't somehow deprivilige xenstored).

Yes we could (and Xoar did).  IIRC the only reason it needs privilege is
to map the rings and that can be sorted out by having the builder
pre-load a grant entry.

> So, we end up with a conclusion that there is no point separating those
> 4 functionalists between each other, and so it only make sense to host
> them in the same domain. How about we call this domain "Dom0", then? ;)

So you're saying that the PCIback domain (which owns the chipsets) might
as well host Xenstore since either of them could hose the system.
Maybe so.  In Xoar we had two reasons not to do that:
 - in some configurations you could shut that domain down after boot
   (though tbh doing that leads to poor error handling!); and
 - we were doing other hardening of Xenstore that involved breaking it 
   up into more than one VM. 

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 Jan 12 12:25:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJiZ-0000uJ-By; Thu, 12 Jan 2012 12:25: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 1RlJiX-0000uE-DX
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:25:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326371110!8782606!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 16453 invoked from network); 12 Jan 2012 12:25:11 -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; 12 Jan 2012 12:25:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:25:10 +0000
Message-Id: <4F0EDF6E020000780006C14F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:26:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH] libxl: fix build with make prior to 3.81
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Up to 3.80, make only supported simple 'else' constructs, which got
violated by 24432:e0effa7c04f5.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -35,12 +35,14 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
-else ifeq ($(CONFIG_Linux),y)
+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
+endif
 
 LIBXL_LIBS += -lyajl
 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:25:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:25:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJiZ-0000uJ-By; Thu, 12 Jan 2012 12:25: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 1RlJiX-0000uE-DX
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:25:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326371110!8782606!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 16453 invoked from network); 12 Jan 2012 12:25:11 -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; 12 Jan 2012 12:25:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:25:10 +0000
Message-Id: <4F0EDF6E020000780006C14F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:26:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH] libxl: fix build with make prior to 3.81
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Up to 3.80, make only supported simple 'else' constructs, which got
violated by 24432:e0effa7c04f5.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -35,12 +35,14 @@ LIBXL_OBJS-$(CONFIG_IA64) += libxl_nocpu
 
 ifeq ($(CONFIG_NetBSD),y)
 LIBXL_OBJS-y += libxl_netbsd.o
-else ifeq ($(CONFIG_Linux),y)
+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
+endif
 
 LIBXL_LIBS += -lyajl
 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:28:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:28:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJlc-00010L-Vb; Thu, 12 Jan 2012 12:28: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 1RlJla-00010D-Op
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:28:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326371299!8850131!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 24309 invoked from network); 12 Jan 2012 12:28:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 12:28:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:28:19 +0000
Message-Id: <4F0EE02C020000780006C15B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:29:16 +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="=__PartF7D9BB0C.0__="
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH] ia64: fix build (once 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.

--=__PartF7D9BB0C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

24423:069c08b7de46 failed to add a necessary include, and for a long
time kexec.h suffered from a missing structure forward declaration.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -180,6 +180,7 @@
 #include <xen/guest_access.h>
 #include <asm/page.h>
 #include <asm/dom_fw_common.h>
+#include <xsm/xsm.h>
 #include <public/memory.h>
 #include <asm/event.h>
 #include <asm/debugger.h>
--- a/xen/include/asm-ia64/kexec.h
+++ b/xen/include/asm-ia64/kexec.h
@@ -4,6 +4,8 @@
 #include <xen/types.h>
 #include <xen/kexec.h>
=20
+struct rsvd_region;
+
 extern const unsigned int relocate_new_kernel_size;
 extern void relocate_new_kernel(unsigned long indirection_page,
                                 unsigned long start_address,




--=__PartF7D9BB0C.0__=
Content-Type: text/plain; name="ia64-build.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ia64-build.patch"

ia64: fix build (once again)=0A=0A24423:069c08b7de46 failed to add a =
necessary include, and for a long=0Atime kexec.h suffered from a missing =
structure forward declaration.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/xen/arch/ia64/xen/mm.c=0A+++ b/xen/arch/ia64/xen/mm.c=0A=
@@ -180,6 +180,7 @@=0A #include <xen/guest_access.h>=0A #include <asm/page.=
h>=0A #include <asm/dom_fw_common.h>=0A+#include <xsm/xsm.h>=0A #include =
<public/memory.h>=0A #include <asm/event.h>=0A #include <asm/debugger.h>=0A=
--- a/xen/include/asm-ia64/kexec.h=0A+++ b/xen/include/asm-ia64/kexec.h=0A@=
@ -4,6 +4,8 @@=0A #include <xen/types.h>=0A #include <xen/kexec.h>=0A =
=0A+struct rsvd_region;=0A+=0A extern const unsigned int relocate_new_kerne=
l_size;=0A extern void relocate_new_kernel(unsigned long indirection_page,=
=0A                                 unsigned long start_address,=0A
--=__PartF7D9BB0C.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

--=__PartF7D9BB0C.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:28:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:28:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJlc-00010L-Vb; Thu, 12 Jan 2012 12:28: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 1RlJla-00010D-Op
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:28:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326371299!8850131!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 24309 invoked from network); 12 Jan 2012 12:28:20 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 12:28:20 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:28:19 +0000
Message-Id: <4F0EE02C020000780006C15B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:29:16 +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="=__PartF7D9BB0C.0__="
Cc: dgdegra@tycho.nsa.gov
Subject: [Xen-devel] [PATCH] ia64: fix build (once 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.

--=__PartF7D9BB0C.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

24423:069c08b7de46 failed to add a necessary include, and for a long
time kexec.h suffered from a missing structure forward declaration.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -180,6 +180,7 @@
 #include <xen/guest_access.h>
 #include <asm/page.h>
 #include <asm/dom_fw_common.h>
+#include <xsm/xsm.h>
 #include <public/memory.h>
 #include <asm/event.h>
 #include <asm/debugger.h>
--- a/xen/include/asm-ia64/kexec.h
+++ b/xen/include/asm-ia64/kexec.h
@@ -4,6 +4,8 @@
 #include <xen/types.h>
 #include <xen/kexec.h>
=20
+struct rsvd_region;
+
 extern const unsigned int relocate_new_kernel_size;
 extern void relocate_new_kernel(unsigned long indirection_page,
                                 unsigned long start_address,




--=__PartF7D9BB0C.0__=
Content-Type: text/plain; name="ia64-build.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="ia64-build.patch"

ia64: fix build (once again)=0A=0A24423:069c08b7de46 failed to add a =
necessary include, and for a long=0Atime kexec.h suffered from a missing =
structure forward declaration.=0A=0ASigned-off-by: Jan Beulich <jbeulich@su=
se.com>=0A=0A--- a/xen/arch/ia64/xen/mm.c=0A+++ b/xen/arch/ia64/xen/mm.c=0A=
@@ -180,6 +180,7 @@=0A #include <xen/guest_access.h>=0A #include <asm/page.=
h>=0A #include <asm/dom_fw_common.h>=0A+#include <xsm/xsm.h>=0A #include =
<public/memory.h>=0A #include <asm/event.h>=0A #include <asm/debugger.h>=0A=
--- a/xen/include/asm-ia64/kexec.h=0A+++ b/xen/include/asm-ia64/kexec.h=0A@=
@ -4,6 +4,8 @@=0A #include <xen/types.h>=0A #include <xen/kexec.h>=0A =
=0A+struct rsvd_region;=0A+=0A extern const unsigned int relocate_new_kerne=
l_size;=0A extern void relocate_new_kernel(unsigned long indirection_page,=
=0A                                 unsigned long start_address,=0A
--=__PartF7D9BB0C.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

--=__PartF7D9BB0C.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:31:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:31:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJoO-000196-IP; Thu, 12 Jan 2012 12:31:20 +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 1RlJoM-00018m-QQ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:31:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326371471!8850294!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 32382 invoked from network); 12 Jan 2012 12:31:11 -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; 12 Jan 2012 12:31:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:31:11 +0000
Message-Id: <4F0EE0D8020000780006C15F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:32:08 +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="=__Part230D6FD8.0__="
Subject: [Xen-devel] [PATCH] move declarations of some required per-arch
 functions into common 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.

--=__Part230D6FD8.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... since it is pointless to have each arch declare them on their own
(and now and the - see ia64 - forget to do so).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2012-01-12.orig/xen/arch/ia64/xen/dom0_ops.c	2011-11-16 =
12:40:48.000000000 +0100
+++ 2012-01-12/xen/arch/ia64/xen/dom0_ops.c	2012-01-12 11:47:51.0000000=
00 +0100
@@ -19,6 +19,7 @@
 #include <xen/console.h>
 #include <xen/grant_table.h>
 #include <xen/guest_access.h>
+#include <xen/hypercall.h>
 #include <xen/pci.h>
 #include <asm/vmx.h>
 #include <asm/dom_fw.h>
--- 2012-01-12.orig/xen/arch/ia64/xen/domain.c	2011-11-16 12:40:48.0000000=
00 +0100
+++ 2012-01-12/xen/arch/ia64/xen/domain.c	2012-01-12 11:45:30.0000000=
00 +0100
@@ -31,6 +31,7 @@
 #include <asm/processor.h>
 #include <xen/event.h>
 #include <xen/console.h>
+#include <xen/hypercall.h>
 #include <xen/version.h>
 #include <xen/libelf.h>
 #include <asm/pgalloc.h>
--- 2012-01-12.orig/xen/arch/ia64/xen/xensetup.c	2011-11-02 =
09:22:59.000000000 +0100
+++ 2012-01-12/xen/arch/ia64/xen/xensetup.c	2012-01-12 11:52:35.0000000=
00 +0100
@@ -10,7 +10,7 @@
 #include <xen/multiboot.h>
 #include <xen/sched.h>
 #include <xen/mm.h>
-#include <public/version.h>
+#include <xen/hypercall.h>
 #include <xen/gdbstub.h>
 #include <xen/version.h>
 #include <xen/console.h>
--- 2012-01-12.orig/xen/arch/x86/domain.c	2011-11-11 10:11:23.0000000=
00 +0100
+++ 2012-01-12/xen/arch/x86/domain.c	2012-01-12 11:45:59.000000000 =
+0100
@@ -23,6 +23,7 @@
 #include <xen/grant_table.h>
 #include <xen/iocap.h>
 #include <xen/kernel.h>
+#include <xen/hypercall.h>
 #include <xen/multicall.h>
 #include <xen/irq.h>
 #include <xen/event.h>
@@ -46,7 +47,6 @@
 #include <asm/xstate.h>
 #include <asm/mpspec.h>
 #include <asm/ldt.h>
-#include <asm/hypercall.h>
 #include <asm/fixmap.h>
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/support.h>
--- 2012-01-12.orig/xen/arch/x86/x86_64/domain.c	2009-08-19 =
17:01:49.000000000 +0200
+++ 2012-01-12/xen/arch/x86/x86_64/domain.c	2012-01-12 11:46:27.0000000=
00 +0100
@@ -6,7 +6,7 @@
 #include <xen/config.h>
 #include <xen/types.h>
 #include <xen/guest_access.h>
-#include <asm/hypercall.h>
+#include <xen/hypercall.h>
 #include <compat/vcpu.h>
=20
 #define xen_vcpu_info vcpu_info
--- 2012-01-12.orig/xen/common/kernel.c	2011-08-08 08:29:50.000000000 =
+0200
+++ 2012-01-12/xen/common/kernel.c	2012-01-12 11:51:52.000000000 =
+0100
@@ -13,13 +13,10 @@
 #include <xen/paging.h>
 #include <xen/nmi.h>
 #include <xen/guest_access.h>
+#include <xen/hypercall.h>
 #include <asm/current.h>
 #include <public/nmi.h>
 #include <public/version.h>
-#ifdef CONFIG_X86
-#include <asm/shared.h>
-#include <asm/setup.h>
-#endif
=20
 #ifndef COMPAT
=20
--- 2012-01-12.orig/xen/include/asm-ia64/hypercall.h	2007-03-26 =
16:26:13.000000000 +0200
+++ 2012-01-12/xen/include/asm-ia64/hypercall.h	2012-01-12 11:42:06.0000000=
00 +0100
@@ -22,7 +22,4 @@ vmx_do_mmu_update(
     u64 *pdone,
     u64 foreigndom);
=20
-extern long
-arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
-
 #endif /* __ASM_IA64_HYPERCALL_H__ */
--- 2012-01-12.orig/xen/include/asm-x86/hypercall.h	2011-11-16 =
12:40:48.000000000 +0100
+++ 2012-01-12/xen/include/asm-x86/hypercall.h	2012-01-12 11:43:21.0000000=
00 +0100
@@ -90,16 +90,6 @@ extern unsigned long
 do_iret(
     void);
=20
-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,=20
-    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
-
 extern int
 do_kexec(
     unsigned long op, unsigned arg1, XEN_GUEST_HANDLE(void) uarg);
--- 2012-01-12.orig/xen/include/asm-x86/setup.h	2011-12-23 08:54:33.0000000=
00 +0100
+++ 2012-01-12/xen/include/asm-x86/setup.h	2012-01-12 11:49:09.0000000=
00 +0100
@@ -2,7 +2,6 @@
 #define __X86_SETUP_H_
=20
 #include <xen/multiboot.h>
-#include <public/version.h>
=20
 extern bool_t early_boot;
 extern unsigned long xenheap_initial_phys_start;
@@ -40,7 +39,6 @@ unsigned long initial_images_nrpages(voi
 void discard_initial_images(void);
=20
 int xen_in_range(unsigned long mfn);
-void arch_get_xen_caps(xen_capabilities_info_t *info);
=20
 void microcode_grab_module(
     unsigned long *, const multiboot_info_t *, void *(*)(const module_t =
*));
--- 2012-01-12.orig/xen/include/xen/hypercall.h	2011-11-16 12:40:48.0000000=
00 +0100
+++ 2012-01-12/xen/include/xen/hypercall.h	2012-01-12 11:50:17.0000000=
00 +0100
@@ -14,6 +14,7 @@
 #include <public/platform.h>
 #include <public/event_channel.h>
 #include <public/tmem.h>
+#include <public/version.h>
 #include <asm/hypercall.h>
 #include <xsm/xsm.h>
=20
@@ -45,6 +46,11 @@ do_sysctl(
     XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
=20
 extern long
+arch_do_sysctl(
+    struct xen_sysctl *sysctl,
+    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+
+extern long
 do_platform_op(
     XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op);
=20
@@ -102,6 +108,12 @@ do_vcpu_op(
     int vcpuid,
     XEN_GUEST_HANDLE(void) arg);
=20
+struct vcpu;
+extern long
+arch_do_vcpu_op(int cmd,
+    struct vcpu *v,
+    XEN_GUEST_HANDLE(void) arg);
+
 extern long
 do_nmi_op(
     unsigned int cmd,
@@ -167,4 +179,6 @@ compat_set_timer_op(
=20
 #endif
=20
+void arch_get_xen_caps(xen_capabilities_info_t *info);
+
 #endif /* __XEN_HYPERCALL_H__ */



--=__Part230D6FD8.0__=
Content-Type: text/plain; name="arch-decls.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arch-decls.patch"

move declarations of some required per-arch functions into common =
headers=0A=0A... since it is pointless to have each arch declare them on =
their own=0A(and now and the - see ia64 - forget to do so).=0A=0ASigned-off=
-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2012-01-12.orig/xen/arch/ia64=
/xen/dom0_ops.c	2011-11-16 12:40:48.000000000 +0100=0A+++ 2012-01-12/xen/ar=
ch/ia64/xen/dom0_ops.c	2012-01-12 11:47:51.000000000 +0100=0A@@ -19,6 =
+19,7 @@=0A #include <xen/console.h>=0A #include <xen/grant_table.h>=0A =
#include <xen/guest_access.h>=0A+#include <xen/hypercall.h>=0A #include =
<xen/pci.h>=0A #include <asm/vmx.h>=0A #include <asm/dom_fw.h>=0A--- =
2012-01-12.orig/xen/arch/ia64/xen/domain.c	2011-11-16 12:40:48.0000000=
00 +0100=0A+++ 2012-01-12/xen/arch/ia64/xen/domain.c	2012-01-12 =
11:45:30.000000000 +0100=0A@@ -31,6 +31,7 @@=0A #include <asm/processor.h>=
=0A #include <xen/event.h>=0A #include <xen/console.h>=0A+#include =
<xen/hypercall.h>=0A #include <xen/version.h>=0A #include <xen/libelf.h>=0A=
 #include <asm/pgalloc.h>=0A--- 2012-01-12.orig/xen/arch/ia64/xen/xensetup.=
c	2011-11-02 09:22:59.000000000 +0100=0A+++ 2012-01-12/xen/arch/ia64/=
xen/xensetup.c	2012-01-12 11:52:35.000000000 +0100=0A@@ -10,7 +10,7 @@=0A =
#include <xen/multiboot.h>=0A #include <xen/sched.h>=0A #include <xen/mm.h>=
=0A-#include <public/version.h>=0A+#include <xen/hypercall.h>=0A #include =
<xen/gdbstub.h>=0A #include <xen/version.h>=0A #include <xen/console.h>=0A-=
-- 2012-01-12.orig/xen/arch/x86/domain.c	2011-11-11 10:11:23.0000000=
00 +0100=0A+++ 2012-01-12/xen/arch/x86/domain.c	2012-01-12 11:45:59.0000000=
00 +0100=0A@@ -23,6 +23,7 @@=0A #include <xen/grant_table.h>=0A #include =
<xen/iocap.h>=0A #include <xen/kernel.h>=0A+#include <xen/hypercall.h>=0A =
#include <xen/multicall.h>=0A #include <xen/irq.h>=0A #include <xen/event.h=
>=0A@@ -46,7 +47,6 @@=0A #include <asm/xstate.h>=0A #include <asm/mpspec.h>=
=0A #include <asm/ldt.h>=0A-#include <asm/hypercall.h>=0A #include =
<asm/fixmap.h>=0A #include <asm/hvm/hvm.h>=0A #include <asm/hvm/support.h>=
=0A--- 2012-01-12.orig/xen/arch/x86/x86_64/domain.c	2009-08-19 =
17:01:49.000000000 +0200=0A+++ 2012-01-12/xen/arch/x86/x86_64/domain.c	=
2012-01-12 11:46:27.000000000 +0100=0A@@ -6,7 +6,7 @@=0A #include =
<xen/config.h>=0A #include <xen/types.h>=0A #include <xen/guest_access.h>=
=0A-#include <asm/hypercall.h>=0A+#include <xen/hypercall.h>=0A #include =
<compat/vcpu.h>=0A =0A #define xen_vcpu_info vcpu_info=0A--- 2012-01-12.ori=
g/xen/common/kernel.c	2011-08-08 08:29:50.000000000 +0200=0A+++ =
2012-01-12/xen/common/kernel.c	2012-01-12 11:51:52.000000000 +0100=0A@@ =
-13,13 +13,10 @@=0A #include <xen/paging.h>=0A #include <xen/nmi.h>=0A =
#include <xen/guest_access.h>=0A+#include <xen/hypercall.h>=0A #include =
<asm/current.h>=0A #include <public/nmi.h>=0A #include <public/version.h>=
=0A-#ifdef CONFIG_X86=0A-#include <asm/shared.h>=0A-#include <asm/setup.h>=
=0A-#endif=0A =0A #ifndef COMPAT=0A =0A--- 2012-01-12.orig/xen/include/asm-=
ia64/hypercall.h	2007-03-26 16:26:13.000000000 +0200=0A+++ =
2012-01-12/xen/include/asm-ia64/hypercall.h	2012-01-12 11:42:06.0000000=
00 +0100=0A@@ -22,7 +22,4 @@ vmx_do_mmu_update(=0A     u64 *pdone,=0A     =
u64 foreigndom);=0A =0A-extern long=0A-arch_do_vcpu_op(int cmd, struct =
vcpu *v, XEN_GUEST_HANDLE(void) arg);=0A-=0A #endif /* __ASM_IA64_HYPERCALL=
_H__ */=0A--- 2012-01-12.orig/xen/include/asm-x86/hypercall.h	2011-11-16 =
12:40:48.000000000 +0100=0A+++ 2012-01-12/xen/include/asm-x86/hypercall.h	=
2012-01-12 11:43:21.000000000 +0100=0A@@ -90,16 +90,6 @@ extern unsigned =
long=0A do_iret(=0A     void);=0A =0A-struct vcpu;=0A-extern long=0A-arch_d=
o_vcpu_op(=0A-    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) =
arg);=0A-=0A-extern long=0A-arch_do_sysctl(=0A-    struct xen_sysctl *op, =
=0A-    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);=0A-=0A extern int=0A =
do_kexec(=0A     unsigned long op, unsigned arg1, XEN_GUEST_HANDLE(void) =
uarg);=0A--- 2012-01-12.orig/xen/include/asm-x86/setup.h	2011-12-23 =
08:54:33.000000000 +0100=0A+++ 2012-01-12/xen/include/asm-x86/setup.h	=
2012-01-12 11:49:09.000000000 +0100=0A@@ -2,7 +2,6 @@=0A #define __X86_SETU=
P_H_=0A =0A #include <xen/multiboot.h>=0A-#include <public/version.h>=0A =
=0A extern bool_t early_boot;=0A extern unsigned long xenheap_initial_phys_=
start;=0A@@ -40,7 +39,6 @@ unsigned long initial_images_nrpages(voi=0A =
void discard_initial_images(void);=0A =0A int xen_in_range(unsigned long =
mfn);=0A-void arch_get_xen_caps(xen_capabilities_info_t *info);=0A =0A =
void microcode_grab_module(=0A     unsigned long *, const multiboot_info_t =
*, void *(*)(const module_t *));=0A--- 2012-01-12.orig/xen/include/xen/hype=
rcall.h	2011-11-16 12:40:48.000000000 +0100=0A+++ 2012-01-12/xen/include/xe=
n/hypercall.h	2012-01-12 11:50:17.000000000 +0100=0A@@ -14,6 +14,7 @@=0A =
#include <public/platform.h>=0A #include <public/event_channel.h>=0A =
#include <public/tmem.h>=0A+#include <public/version.h>=0A #include =
<asm/hypercall.h>=0A #include <xsm/xsm.h>=0A =0A@@ -45,6 +46,11 @@ =
do_sysctl(=0A     XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);=0A =0A extern =
long=0A+arch_do_sysctl(=0A+    struct xen_sysctl *sysctl,=0A+    XEN_GUEST_=
HANDLE(xen_sysctl_t) u_sysctl);=0A+=0A+extern long=0A do_platform_op(=0A   =
  XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op);=0A =0A@@ -102,6 +108,12 =
@@ do_vcpu_op(=0A     int vcpuid,=0A     XEN_GUEST_HANDLE(void) arg);=0A =
=0A+struct vcpu;=0A+extern long=0A+arch_do_vcpu_op(int cmd,=0A+    struct =
vcpu *v,=0A+    XEN_GUEST_HANDLE(void) arg);=0A+=0A extern long=0A =
do_nmi_op(=0A     unsigned int cmd,=0A@@ -167,4 +179,6 @@ compat_set_timer_=
op(=0A =0A #endif=0A =0A+void arch_get_xen_caps(xen_capabilities_info_t =
*info);=0A+=0A #endif /* __XEN_HYPERCALL_H__ */=0A
--=__Part230D6FD8.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

--=__Part230D6FD8.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:31:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:31:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJoO-000196-IP; Thu, 12 Jan 2012 12:31:20 +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 1RlJoM-00018m-QQ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:31:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326371471!8850294!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 32382 invoked from network); 12 Jan 2012 12:31:11 -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; 12 Jan 2012 12:31:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:31:11 +0000
Message-Id: <4F0EE0D8020000780006C15F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:32:08 +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="=__Part230D6FD8.0__="
Subject: [Xen-devel] [PATCH] move declarations of some required per-arch
 functions into common 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.

--=__Part230D6FD8.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... since it is pointless to have each arch declare them on their own
(and now and the - see ia64 - forget to do so).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- 2012-01-12.orig/xen/arch/ia64/xen/dom0_ops.c	2011-11-16 =
12:40:48.000000000 +0100
+++ 2012-01-12/xen/arch/ia64/xen/dom0_ops.c	2012-01-12 11:47:51.0000000=
00 +0100
@@ -19,6 +19,7 @@
 #include <xen/console.h>
 #include <xen/grant_table.h>
 #include <xen/guest_access.h>
+#include <xen/hypercall.h>
 #include <xen/pci.h>
 #include <asm/vmx.h>
 #include <asm/dom_fw.h>
--- 2012-01-12.orig/xen/arch/ia64/xen/domain.c	2011-11-16 12:40:48.0000000=
00 +0100
+++ 2012-01-12/xen/arch/ia64/xen/domain.c	2012-01-12 11:45:30.0000000=
00 +0100
@@ -31,6 +31,7 @@
 #include <asm/processor.h>
 #include <xen/event.h>
 #include <xen/console.h>
+#include <xen/hypercall.h>
 #include <xen/version.h>
 #include <xen/libelf.h>
 #include <asm/pgalloc.h>
--- 2012-01-12.orig/xen/arch/ia64/xen/xensetup.c	2011-11-02 =
09:22:59.000000000 +0100
+++ 2012-01-12/xen/arch/ia64/xen/xensetup.c	2012-01-12 11:52:35.0000000=
00 +0100
@@ -10,7 +10,7 @@
 #include <xen/multiboot.h>
 #include <xen/sched.h>
 #include <xen/mm.h>
-#include <public/version.h>
+#include <xen/hypercall.h>
 #include <xen/gdbstub.h>
 #include <xen/version.h>
 #include <xen/console.h>
--- 2012-01-12.orig/xen/arch/x86/domain.c	2011-11-11 10:11:23.0000000=
00 +0100
+++ 2012-01-12/xen/arch/x86/domain.c	2012-01-12 11:45:59.000000000 =
+0100
@@ -23,6 +23,7 @@
 #include <xen/grant_table.h>
 #include <xen/iocap.h>
 #include <xen/kernel.h>
+#include <xen/hypercall.h>
 #include <xen/multicall.h>
 #include <xen/irq.h>
 #include <xen/event.h>
@@ -46,7 +47,6 @@
 #include <asm/xstate.h>
 #include <asm/mpspec.h>
 #include <asm/ldt.h>
-#include <asm/hypercall.h>
 #include <asm/fixmap.h>
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/support.h>
--- 2012-01-12.orig/xen/arch/x86/x86_64/domain.c	2009-08-19 =
17:01:49.000000000 +0200
+++ 2012-01-12/xen/arch/x86/x86_64/domain.c	2012-01-12 11:46:27.0000000=
00 +0100
@@ -6,7 +6,7 @@
 #include <xen/config.h>
 #include <xen/types.h>
 #include <xen/guest_access.h>
-#include <asm/hypercall.h>
+#include <xen/hypercall.h>
 #include <compat/vcpu.h>
=20
 #define xen_vcpu_info vcpu_info
--- 2012-01-12.orig/xen/common/kernel.c	2011-08-08 08:29:50.000000000 =
+0200
+++ 2012-01-12/xen/common/kernel.c	2012-01-12 11:51:52.000000000 =
+0100
@@ -13,13 +13,10 @@
 #include <xen/paging.h>
 #include <xen/nmi.h>
 #include <xen/guest_access.h>
+#include <xen/hypercall.h>
 #include <asm/current.h>
 #include <public/nmi.h>
 #include <public/version.h>
-#ifdef CONFIG_X86
-#include <asm/shared.h>
-#include <asm/setup.h>
-#endif
=20
 #ifndef COMPAT
=20
--- 2012-01-12.orig/xen/include/asm-ia64/hypercall.h	2007-03-26 =
16:26:13.000000000 +0200
+++ 2012-01-12/xen/include/asm-ia64/hypercall.h	2012-01-12 11:42:06.0000000=
00 +0100
@@ -22,7 +22,4 @@ vmx_do_mmu_update(
     u64 *pdone,
     u64 foreigndom);
=20
-extern long
-arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
-
 #endif /* __ASM_IA64_HYPERCALL_H__ */
--- 2012-01-12.orig/xen/include/asm-x86/hypercall.h	2011-11-16 =
12:40:48.000000000 +0100
+++ 2012-01-12/xen/include/asm-x86/hypercall.h	2012-01-12 11:43:21.0000000=
00 +0100
@@ -90,16 +90,6 @@ extern unsigned long
 do_iret(
     void);
=20
-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,=20
-    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
-
 extern int
 do_kexec(
     unsigned long op, unsigned arg1, XEN_GUEST_HANDLE(void) uarg);
--- 2012-01-12.orig/xen/include/asm-x86/setup.h	2011-12-23 08:54:33.0000000=
00 +0100
+++ 2012-01-12/xen/include/asm-x86/setup.h	2012-01-12 11:49:09.0000000=
00 +0100
@@ -2,7 +2,6 @@
 #define __X86_SETUP_H_
=20
 #include <xen/multiboot.h>
-#include <public/version.h>
=20
 extern bool_t early_boot;
 extern unsigned long xenheap_initial_phys_start;
@@ -40,7 +39,6 @@ unsigned long initial_images_nrpages(voi
 void discard_initial_images(void);
=20
 int xen_in_range(unsigned long mfn);
-void arch_get_xen_caps(xen_capabilities_info_t *info);
=20
 void microcode_grab_module(
     unsigned long *, const multiboot_info_t *, void *(*)(const module_t =
*));
--- 2012-01-12.orig/xen/include/xen/hypercall.h	2011-11-16 12:40:48.0000000=
00 +0100
+++ 2012-01-12/xen/include/xen/hypercall.h	2012-01-12 11:50:17.0000000=
00 +0100
@@ -14,6 +14,7 @@
 #include <public/platform.h>
 #include <public/event_channel.h>
 #include <public/tmem.h>
+#include <public/version.h>
 #include <asm/hypercall.h>
 #include <xsm/xsm.h>
=20
@@ -45,6 +46,11 @@ do_sysctl(
     XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
=20
 extern long
+arch_do_sysctl(
+    struct xen_sysctl *sysctl,
+    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
+
+extern long
 do_platform_op(
     XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op);
=20
@@ -102,6 +108,12 @@ do_vcpu_op(
     int vcpuid,
     XEN_GUEST_HANDLE(void) arg);
=20
+struct vcpu;
+extern long
+arch_do_vcpu_op(int cmd,
+    struct vcpu *v,
+    XEN_GUEST_HANDLE(void) arg);
+
 extern long
 do_nmi_op(
     unsigned int cmd,
@@ -167,4 +179,6 @@ compat_set_timer_op(
=20
 #endif
=20
+void arch_get_xen_caps(xen_capabilities_info_t *info);
+
 #endif /* __XEN_HYPERCALL_H__ */



--=__Part230D6FD8.0__=
Content-Type: text/plain; name="arch-decls.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="arch-decls.patch"

move declarations of some required per-arch functions into common =
headers=0A=0A... since it is pointless to have each arch declare them on =
their own=0A(and now and the - see ia64 - forget to do so).=0A=0ASigned-off=
-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- 2012-01-12.orig/xen/arch/ia64=
/xen/dom0_ops.c	2011-11-16 12:40:48.000000000 +0100=0A+++ 2012-01-12/xen/ar=
ch/ia64/xen/dom0_ops.c	2012-01-12 11:47:51.000000000 +0100=0A@@ -19,6 =
+19,7 @@=0A #include <xen/console.h>=0A #include <xen/grant_table.h>=0A =
#include <xen/guest_access.h>=0A+#include <xen/hypercall.h>=0A #include =
<xen/pci.h>=0A #include <asm/vmx.h>=0A #include <asm/dom_fw.h>=0A--- =
2012-01-12.orig/xen/arch/ia64/xen/domain.c	2011-11-16 12:40:48.0000000=
00 +0100=0A+++ 2012-01-12/xen/arch/ia64/xen/domain.c	2012-01-12 =
11:45:30.000000000 +0100=0A@@ -31,6 +31,7 @@=0A #include <asm/processor.h>=
=0A #include <xen/event.h>=0A #include <xen/console.h>=0A+#include =
<xen/hypercall.h>=0A #include <xen/version.h>=0A #include <xen/libelf.h>=0A=
 #include <asm/pgalloc.h>=0A--- 2012-01-12.orig/xen/arch/ia64/xen/xensetup.=
c	2011-11-02 09:22:59.000000000 +0100=0A+++ 2012-01-12/xen/arch/ia64/=
xen/xensetup.c	2012-01-12 11:52:35.000000000 +0100=0A@@ -10,7 +10,7 @@=0A =
#include <xen/multiboot.h>=0A #include <xen/sched.h>=0A #include <xen/mm.h>=
=0A-#include <public/version.h>=0A+#include <xen/hypercall.h>=0A #include =
<xen/gdbstub.h>=0A #include <xen/version.h>=0A #include <xen/console.h>=0A-=
-- 2012-01-12.orig/xen/arch/x86/domain.c	2011-11-11 10:11:23.0000000=
00 +0100=0A+++ 2012-01-12/xen/arch/x86/domain.c	2012-01-12 11:45:59.0000000=
00 +0100=0A@@ -23,6 +23,7 @@=0A #include <xen/grant_table.h>=0A #include =
<xen/iocap.h>=0A #include <xen/kernel.h>=0A+#include <xen/hypercall.h>=0A =
#include <xen/multicall.h>=0A #include <xen/irq.h>=0A #include <xen/event.h=
>=0A@@ -46,7 +47,6 @@=0A #include <asm/xstate.h>=0A #include <asm/mpspec.h>=
=0A #include <asm/ldt.h>=0A-#include <asm/hypercall.h>=0A #include =
<asm/fixmap.h>=0A #include <asm/hvm/hvm.h>=0A #include <asm/hvm/support.h>=
=0A--- 2012-01-12.orig/xen/arch/x86/x86_64/domain.c	2009-08-19 =
17:01:49.000000000 +0200=0A+++ 2012-01-12/xen/arch/x86/x86_64/domain.c	=
2012-01-12 11:46:27.000000000 +0100=0A@@ -6,7 +6,7 @@=0A #include =
<xen/config.h>=0A #include <xen/types.h>=0A #include <xen/guest_access.h>=
=0A-#include <asm/hypercall.h>=0A+#include <xen/hypercall.h>=0A #include =
<compat/vcpu.h>=0A =0A #define xen_vcpu_info vcpu_info=0A--- 2012-01-12.ori=
g/xen/common/kernel.c	2011-08-08 08:29:50.000000000 +0200=0A+++ =
2012-01-12/xen/common/kernel.c	2012-01-12 11:51:52.000000000 +0100=0A@@ =
-13,13 +13,10 @@=0A #include <xen/paging.h>=0A #include <xen/nmi.h>=0A =
#include <xen/guest_access.h>=0A+#include <xen/hypercall.h>=0A #include =
<asm/current.h>=0A #include <public/nmi.h>=0A #include <public/version.h>=
=0A-#ifdef CONFIG_X86=0A-#include <asm/shared.h>=0A-#include <asm/setup.h>=
=0A-#endif=0A =0A #ifndef COMPAT=0A =0A--- 2012-01-12.orig/xen/include/asm-=
ia64/hypercall.h	2007-03-26 16:26:13.000000000 +0200=0A+++ =
2012-01-12/xen/include/asm-ia64/hypercall.h	2012-01-12 11:42:06.0000000=
00 +0100=0A@@ -22,7 +22,4 @@ vmx_do_mmu_update(=0A     u64 *pdone,=0A     =
u64 foreigndom);=0A =0A-extern long=0A-arch_do_vcpu_op(int cmd, struct =
vcpu *v, XEN_GUEST_HANDLE(void) arg);=0A-=0A #endif /* __ASM_IA64_HYPERCALL=
_H__ */=0A--- 2012-01-12.orig/xen/include/asm-x86/hypercall.h	2011-11-16 =
12:40:48.000000000 +0100=0A+++ 2012-01-12/xen/include/asm-x86/hypercall.h	=
2012-01-12 11:43:21.000000000 +0100=0A@@ -90,16 +90,6 @@ extern unsigned =
long=0A do_iret(=0A     void);=0A =0A-struct vcpu;=0A-extern long=0A-arch_d=
o_vcpu_op(=0A-    int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) =
arg);=0A-=0A-extern long=0A-arch_do_sysctl(=0A-    struct xen_sysctl *op, =
=0A-    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);=0A-=0A extern int=0A =
do_kexec(=0A     unsigned long op, unsigned arg1, XEN_GUEST_HANDLE(void) =
uarg);=0A--- 2012-01-12.orig/xen/include/asm-x86/setup.h	2011-12-23 =
08:54:33.000000000 +0100=0A+++ 2012-01-12/xen/include/asm-x86/setup.h	=
2012-01-12 11:49:09.000000000 +0100=0A@@ -2,7 +2,6 @@=0A #define __X86_SETU=
P_H_=0A =0A #include <xen/multiboot.h>=0A-#include <public/version.h>=0A =
=0A extern bool_t early_boot;=0A extern unsigned long xenheap_initial_phys_=
start;=0A@@ -40,7 +39,6 @@ unsigned long initial_images_nrpages(voi=0A =
void discard_initial_images(void);=0A =0A int xen_in_range(unsigned long =
mfn);=0A-void arch_get_xen_caps(xen_capabilities_info_t *info);=0A =0A =
void microcode_grab_module(=0A     unsigned long *, const multiboot_info_t =
*, void *(*)(const module_t *));=0A--- 2012-01-12.orig/xen/include/xen/hype=
rcall.h	2011-11-16 12:40:48.000000000 +0100=0A+++ 2012-01-12/xen/include/xe=
n/hypercall.h	2012-01-12 11:50:17.000000000 +0100=0A@@ -14,6 +14,7 @@=0A =
#include <public/platform.h>=0A #include <public/event_channel.h>=0A =
#include <public/tmem.h>=0A+#include <public/version.h>=0A #include =
<asm/hypercall.h>=0A #include <xsm/xsm.h>=0A =0A@@ -45,6 +46,11 @@ =
do_sysctl(=0A     XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);=0A =0A extern =
long=0A+arch_do_sysctl(=0A+    struct xen_sysctl *sysctl,=0A+    XEN_GUEST_=
HANDLE(xen_sysctl_t) u_sysctl);=0A+=0A+extern long=0A do_platform_op(=0A   =
  XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op);=0A =0A@@ -102,6 +108,12 =
@@ do_vcpu_op(=0A     int vcpuid,=0A     XEN_GUEST_HANDLE(void) arg);=0A =
=0A+struct vcpu;=0A+extern long=0A+arch_do_vcpu_op(int cmd,=0A+    struct =
vcpu *v,=0A+    XEN_GUEST_HANDLE(void) arg);=0A+=0A extern long=0A =
do_nmi_op(=0A     unsigned int cmd,=0A@@ -167,4 +179,6 @@ compat_set_timer_=
op(=0A =0A #endif=0A =0A+void arch_get_xen_caps(xen_capabilities_info_t =
*info);=0A+=0A #endif /* __XEN_HYPERCALL_H__ */=0A
--=__Part230D6FD8.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

--=__Part230D6FD8.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJsF-0001Lh-8A; Thu, 12 Jan 2012 12:35:19 +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 1RlJsE-0001LT-4c
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:35:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326371711!10727579!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 3647 invoked from network); 12 Jan 2012 12:35:11 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 12:35:11 -0000
Received: by werg1 with SMTP id g1so3330933wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 04:35:11 -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=bFL39phngQZ7QiYZOe4CjBvxu4IAQq1YOxKJOcqmb9I=;
	b=OxXRsW3zHHmf5rfAl9GetwY4v7zsSQkqiL+svpcg9woQ68IzTxTNWOGwfqoKNBraFo
	Qw5TbNTanhcpdIdIFTi/yaG/UMJdHsw+H29Rp6iTkn244h9imdjzOurLC95BHKSAz+t5
	57T0oCaAB6j/jTv6kREP8gU9m47HzsQIUphyw=
Received: by 10.216.136.75 with SMTP id v53mr1403226wei.42.1326371710993;
	Thu, 12 Jan 2012 04:35:10 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id q34sm5561607wbm.15.2012.01.12.04.35.10
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 04:35:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 12:35:07 +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: <CB3483FB.374A3%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ia64: fix build (once again)
Thread-Index: AczRJp2aPv69IcIAVEeGpsye6CA4qQ==
In-Reply-To: <4F0EE02C020000780006C15B@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH] ia64: fix build (once 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 12/01/2012 12:29, "Jan Beulich" <JBeulich@suse.com> wrote:

> 24423:069c08b7de46 failed to add a necessary include, and for a long
> time kexec.h suffered from a missing structure forward declaration.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/xen/mm.c
> +++ b/xen/arch/ia64/xen/mm.c
> @@ -180,6 +180,7 @@
>  #include <xen/guest_access.h>
>  #include <asm/page.h>
>  #include <asm/dom_fw_common.h>
> +#include <xsm/xsm.h>
>  #include <public/memory.h>
>  #include <asm/event.h>
>  #include <asm/debugger.h>
> --- a/xen/include/asm-ia64/kexec.h
> +++ b/xen/include/asm-ia64/kexec.h
> @@ -4,6 +4,8 @@
>  #include <xen/types.h>
>  #include <xen/kexec.h>
>  
> +struct rsvd_region;
> +
>  extern const unsigned int relocate_new_kernel_size;
>  extern void relocate_new_kernel(unsigned long indirection_page,
>                                  unsigned long start_address,
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 12:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJsF-0001Lh-8A; Thu, 12 Jan 2012 12:35:19 +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 1RlJsE-0001LT-4c
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:35:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326371711!10727579!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 3647 invoked from network); 12 Jan 2012 12:35:11 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 12:35:11 -0000
Received: by werg1 with SMTP id g1so3330933wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 04:35:11 -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=bFL39phngQZ7QiYZOe4CjBvxu4IAQq1YOxKJOcqmb9I=;
	b=OxXRsW3zHHmf5rfAl9GetwY4v7zsSQkqiL+svpcg9woQ68IzTxTNWOGwfqoKNBraFo
	Qw5TbNTanhcpdIdIFTi/yaG/UMJdHsw+H29Rp6iTkn244h9imdjzOurLC95BHKSAz+t5
	57T0oCaAB6j/jTv6kREP8gU9m47HzsQIUphyw=
Received: by 10.216.136.75 with SMTP id v53mr1403226wei.42.1326371710993;
	Thu, 12 Jan 2012 04:35:10 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id q34sm5561607wbm.15.2012.01.12.04.35.10
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 04:35:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 12:35:07 +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: <CB3483FB.374A3%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] ia64: fix build (once again)
Thread-Index: AczRJp2aPv69IcIAVEeGpsye6CA4qQ==
In-Reply-To: <4F0EE02C020000780006C15B@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: dgdegra@tycho.nsa.gov
Subject: Re: [Xen-devel] [PATCH] ia64: fix build (once 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 12/01/2012 12:29, "Jan Beulich" <JBeulich@suse.com> wrote:

> 24423:069c08b7de46 failed to add a necessary include, and for a long
> time kexec.h suffered from a missing structure forward declaration.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/xen/mm.c
> +++ b/xen/arch/ia64/xen/mm.c
> @@ -180,6 +180,7 @@
>  #include <xen/guest_access.h>
>  #include <asm/page.h>
>  #include <asm/dom_fw_common.h>
> +#include <xsm/xsm.h>
>  #include <public/memory.h>
>  #include <asm/event.h>
>  #include <asm/debugger.h>
> --- a/xen/include/asm-ia64/kexec.h
> +++ b/xen/include/asm-ia64/kexec.h
> @@ -4,6 +4,8 @@
>  #include <xen/types.h>
>  #include <xen/kexec.h>
>  
> +struct rsvd_region;
> +
>  extern const unsigned int relocate_new_kernel_size;
>  extern void relocate_new_kernel(unsigned long indirection_page,
>                                  unsigned long start_address,
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 12:36:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJsq-0001Np-M0; Thu, 12 Jan 2012 12:35: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 1RlJso-0001NP-Ip
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:35:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326371748!10707718!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 8615 invoked from network); 12 Jan 2012 12:35:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 12:35:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:35:47 +0000
Message-Id: <4F0EE1EC020000780006C16D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:36:44 +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="=__Part36187ACC.0__="
Subject: [Xen-devel] [PATCH] x86: move and fold certain type property
	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.

--=__Part36187ACC.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Not only is it less code to have them consolidated, it also permits
their use virtually everywhere (since config.h is required to be
included everywhere. (Shouldn't we, btw, follow Linux and remove the
explicit inclusion in favor of command line enforced one?)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -8,11 +8,16 @@
 #define __X86_CONFIG_H__
=20
 #if defined(__x86_64__)
+# define LONG_BYTEORDER 3
 # define CONFIG_PAGING_LEVELS 4
 #else
+# define LONG_BYTEORDER 2
 # define CONFIG_PAGING_LEVELS 3
 #endif
=20
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
+#define BITS_PER_LONG (BYTES_PER_LONG << 3)
+
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
 #define CONFIG_PAGING_ASSISTANCE 1
--- a/xen/include/asm-x86/types.h
+++ b/xen/include/asm-x86/types.h
@@ -55,14 +55,4 @@ typedef char bool_t;
=20
 #endif /* __ASSEMBLY__ */
=20
-#if defined(__i386__)
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
-#define LONG_BYTEORDER 2
-#elif defined(__x86_64__)
-#define BITS_PER_LONG 64
-#define BYTES_PER_LONG 8
-#define LONG_BYTEORDER 3
-#endif
-
 #endif /* __X86_TYPES_H__ */




--=__Part36187ACC.0__=
Content-Type: text/plain; name="x86-type-config.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-type-config.patch"

x86: move and fold certain type property definitions=0A=0ANot only is it =
less code to have them consolidated, it also permits=0Atheir use virtually =
everywhere (since config.h is required to be=0Aincluded everywhere. =
(Shouldn't we, btw, follow Linux and remove the=0Aexplicit inclusion in =
favor of command line enforced one?)=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/include/asm-x86/config.h=0A+++ =
b/xen/include/asm-x86/config.h=0A@@ -8,11 +8,16 @@=0A #define __X86_CONFIG_=
H__=0A =0A #if defined(__x86_64__)=0A+# define LONG_BYTEORDER 3=0A # =
define CONFIG_PAGING_LEVELS 4=0A #else=0A+# define LONG_BYTEORDER 2=0A # =
define CONFIG_PAGING_LEVELS 3=0A #endif=0A =0A+#define BYTES_PER_LONG (1 =
<< LONG_BYTEORDER)=0A+#define BITS_PER_LONG (BYTES_PER_LONG << 3)=0A+=0A =
#define CONFIG_X86 1=0A #define CONFIG_X86_HT 1=0A #define CONFIG_PAGING_AS=
SISTANCE 1=0A--- a/xen/include/asm-x86/types.h=0A+++ b/xen/include/asm-x86/=
types.h=0A@@ -55,14 +55,4 @@ typedef char bool_t;=0A =0A #endif /* =
__ASSEMBLY__ */=0A =0A-#if defined(__i386__)=0A-#define BITS_PER_LONG =
32=0A-#define BYTES_PER_LONG 4=0A-#define LONG_BYTEORDER 2=0A-#elif =
defined(__x86_64__)=0A-#define BITS_PER_LONG 64=0A-#define BYTES_PER_LONG =
8=0A-#define LONG_BYTEORDER 3=0A-#endif=0A-=0A #endif /* __X86_TYPES_H__ =
*/=0A
--=__Part36187ACC.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

--=__Part36187ACC.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:36:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:36:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJsq-0001Np-M0; Thu, 12 Jan 2012 12:35: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 1RlJso-0001NP-Ip
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:35:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326371748!10707718!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 8615 invoked from network); 12 Jan 2012 12:35:48 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 12:35:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:35:47 +0000
Message-Id: <4F0EE1EC020000780006C16D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:36:44 +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="=__Part36187ACC.0__="
Subject: [Xen-devel] [PATCH] x86: move and fold certain type property
	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.

--=__Part36187ACC.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Not only is it less code to have them consolidated, it also permits
their use virtually everywhere (since config.h is required to be
included everywhere. (Shouldn't we, btw, follow Linux and remove the
explicit inclusion in favor of command line enforced one?)

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -8,11 +8,16 @@
 #define __X86_CONFIG_H__
=20
 #if defined(__x86_64__)
+# define LONG_BYTEORDER 3
 # define CONFIG_PAGING_LEVELS 4
 #else
+# define LONG_BYTEORDER 2
 # define CONFIG_PAGING_LEVELS 3
 #endif
=20
+#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
+#define BITS_PER_LONG (BYTES_PER_LONG << 3)
+
 #define CONFIG_X86 1
 #define CONFIG_X86_HT 1
 #define CONFIG_PAGING_ASSISTANCE 1
--- a/xen/include/asm-x86/types.h
+++ b/xen/include/asm-x86/types.h
@@ -55,14 +55,4 @@ typedef char bool_t;
=20
 #endif /* __ASSEMBLY__ */
=20
-#if defined(__i386__)
-#define BITS_PER_LONG 32
-#define BYTES_PER_LONG 4
-#define LONG_BYTEORDER 2
-#elif defined(__x86_64__)
-#define BITS_PER_LONG 64
-#define BYTES_PER_LONG 8
-#define LONG_BYTEORDER 3
-#endif
-
 #endif /* __X86_TYPES_H__ */




--=__Part36187ACC.0__=
Content-Type: text/plain; name="x86-type-config.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-type-config.patch"

x86: move and fold certain type property definitions=0A=0ANot only is it =
less code to have them consolidated, it also permits=0Atheir use virtually =
everywhere (since config.h is required to be=0Aincluded everywhere. =
(Shouldn't we, btw, follow Linux and remove the=0Aexplicit inclusion in =
favor of command line enforced one?)=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/include/asm-x86/config.h=0A+++ =
b/xen/include/asm-x86/config.h=0A@@ -8,11 +8,16 @@=0A #define __X86_CONFIG_=
H__=0A =0A #if defined(__x86_64__)=0A+# define LONG_BYTEORDER 3=0A # =
define CONFIG_PAGING_LEVELS 4=0A #else=0A+# define LONG_BYTEORDER 2=0A # =
define CONFIG_PAGING_LEVELS 3=0A #endif=0A =0A+#define BYTES_PER_LONG (1 =
<< LONG_BYTEORDER)=0A+#define BITS_PER_LONG (BYTES_PER_LONG << 3)=0A+=0A =
#define CONFIG_X86 1=0A #define CONFIG_X86_HT 1=0A #define CONFIG_PAGING_AS=
SISTANCE 1=0A--- a/xen/include/asm-x86/types.h=0A+++ b/xen/include/asm-x86/=
types.h=0A@@ -55,14 +55,4 @@ typedef char bool_t;=0A =0A #endif /* =
__ASSEMBLY__ */=0A =0A-#if defined(__i386__)=0A-#define BITS_PER_LONG =
32=0A-#define BYTES_PER_LONG 4=0A-#define LONG_BYTEORDER 2=0A-#elif =
defined(__x86_64__)=0A-#define BITS_PER_LONG 64=0A-#define BYTES_PER_LONG =
8=0A-#define LONG_BYTEORDER 3=0A-#endif=0A-=0A #endif /* __X86_TYPES_H__ =
*/=0A
--=__Part36187ACC.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

--=__Part36187ACC.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:36:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJtG-0001R8-8X; Thu, 12 Jan 2012 12:36:22 +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 1RlJtE-0001QF-TL
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:36:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326371773!8538993!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 17288 invoked from network); 12 Jan 2012 12:36:14 -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;
	12 Jan 2012 12:36:14 -0000
Received: by wibhj8 with SMTP id hj8so700894wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 04:36:13 -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=l0rOEb7nq5VeSnHSvIW2lftHoI6ru5mX1FF0Yxnh/bc=;
	b=jaHV5MnDfT9LC1TrhIyTlmlrtInEis/vxgZ3g6eaM1ncBoGKmYWI0w49NX2oFao4np
	jNFd65IzDhYstURFRkvRj1ziNqkY5J1yD49he+iWFNd8KfwMS2+cL3y+KiXT6SlIR483
	htWhs+dUyA+hH3PBP2KRO2wQA4wxTL4SKoxCg=
Received: by 10.180.83.231 with SMTP id t7mr5597607wiy.20.1326371773249;
	Thu, 12 Jan 2012 04:36:13 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id ek1sm231708wib.10.2012.01.12.04.36.12
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 04:36:12 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 12:36: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: <CB348433.374A4%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] move declarations of some required per-arch
	functions into common headers
Thread-Index: AczRJr773C93nI376Uqm3MdlkkadgQ==
In-Reply-To: <4F0EE0D8020000780006C15F@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] move declarations of some required per-arch
 functions into common 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/01/2012 12:32, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... since it is pointless to have each arch declare them on their own
> (and now and the - see ia64 - forget to do so).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2012-01-12.orig/xen/arch/ia64/xen/dom0_ops.c 2011-11-16 12:40:48.000000000
> +0100
> +++ 2012-01-12/xen/arch/ia64/xen/dom0_ops.c 2012-01-12 11:47:51.000000000
> +0100
> @@ -19,6 +19,7 @@
>  #include <xen/console.h>
>  #include <xen/grant_table.h>
>  #include <xen/guest_access.h>
> +#include <xen/hypercall.h>
>  #include <xen/pci.h>
>  #include <asm/vmx.h>
>  #include <asm/dom_fw.h>
> --- 2012-01-12.orig/xen/arch/ia64/xen/domain.c 2011-11-16 12:40:48.000000000
> +0100
> +++ 2012-01-12/xen/arch/ia64/xen/domain.c 2012-01-12 11:45:30.000000000 +0100
> @@ -31,6 +31,7 @@
>  #include <asm/processor.h>
>  #include <xen/event.h>
>  #include <xen/console.h>
> +#include <xen/hypercall.h>
>  #include <xen/version.h>
>  #include <xen/libelf.h>
>  #include <asm/pgalloc.h>
> --- 2012-01-12.orig/xen/arch/ia64/xen/xensetup.c 2011-11-02 09:22:59.000000000
> +0100
> +++ 2012-01-12/xen/arch/ia64/xen/xensetup.c 2012-01-12 11:52:35.000000000
> +0100
> @@ -10,7 +10,7 @@
>  #include <xen/multiboot.h>
>  #include <xen/sched.h>
>  #include <xen/mm.h>
> -#include <public/version.h>
> +#include <xen/hypercall.h>
>  #include <xen/gdbstub.h>
>  #include <xen/version.h>
>  #include <xen/console.h>
> --- 2012-01-12.orig/xen/arch/x86/domain.c 2011-11-11 10:11:23.000000000 +0100
> +++ 2012-01-12/xen/arch/x86/domain.c 2012-01-12 11:45:59.000000000 +0100
> @@ -23,6 +23,7 @@
>  #include <xen/grant_table.h>
>  #include <xen/iocap.h>
>  #include <xen/kernel.h>
> +#include <xen/hypercall.h>
>  #include <xen/multicall.h>
>  #include <xen/irq.h>
>  #include <xen/event.h>
> @@ -46,7 +47,6 @@
>  #include <asm/xstate.h>
>  #include <asm/mpspec.h>
>  #include <asm/ldt.h>
> -#include <asm/hypercall.h>
>  #include <asm/fixmap.h>
>  #include <asm/hvm/hvm.h>
>  #include <asm/hvm/support.h>
> --- 2012-01-12.orig/xen/arch/x86/x86_64/domain.c 2009-08-19 17:01:49.000000000
> +0200
> +++ 2012-01-12/xen/arch/x86/x86_64/domain.c 2012-01-12 11:46:27.000000000
> +0100
> @@ -6,7 +6,7 @@
>  #include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/guest_access.h>
> -#include <asm/hypercall.h>
> +#include <xen/hypercall.h>
>  #include <compat/vcpu.h>
>  
>  #define xen_vcpu_info vcpu_info
> --- 2012-01-12.orig/xen/common/kernel.c 2011-08-08 08:29:50.000000000 +0200
> +++ 2012-01-12/xen/common/kernel.c 2012-01-12 11:51:52.000000000 +0100
> @@ -13,13 +13,10 @@
>  #include <xen/paging.h>
>  #include <xen/nmi.h>
>  #include <xen/guest_access.h>
> +#include <xen/hypercall.h>
>  #include <asm/current.h>
>  #include <public/nmi.h>
>  #include <public/version.h>
> -#ifdef CONFIG_X86
> -#include <asm/shared.h>
> -#include <asm/setup.h>
> -#endif
>  
>  #ifndef COMPAT
>  
> --- 2012-01-12.orig/xen/include/asm-ia64/hypercall.h 2007-03-26
> 16:26:13.000000000 +0200
> +++ 2012-01-12/xen/include/asm-ia64/hypercall.h 2012-01-12 11:42:06.000000000
> +0100
> @@ -22,7 +22,4 @@ vmx_do_mmu_update(
>      u64 *pdone,
>      u64 foreigndom);
>  
> -extern long
> -arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
> -
>  #endif /* __ASM_IA64_HYPERCALL_H__ */
> --- 2012-01-12.orig/xen/include/asm-x86/hypercall.h 2011-11-16
> 12:40:48.000000000 +0100
> +++ 2012-01-12/xen/include/asm-x86/hypercall.h 2012-01-12 11:43:21.000000000
> +0100
> @@ -90,16 +90,6 @@ extern unsigned long
>  do_iret(
>      void);
>  
> -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);
> -
>  extern int
>  do_kexec(
>      unsigned long op, unsigned arg1, XEN_GUEST_HANDLE(void) uarg);
> --- 2012-01-12.orig/xen/include/asm-x86/setup.h 2011-12-23 08:54:33.000000000
> +0100
> +++ 2012-01-12/xen/include/asm-x86/setup.h 2012-01-12 11:49:09.000000000 +0100
> @@ -2,7 +2,6 @@
>  #define __X86_SETUP_H_
>  
>  #include <xen/multiboot.h>
> -#include <public/version.h>
>  
>  extern bool_t early_boot;
>  extern unsigned long xenheap_initial_phys_start;
> @@ -40,7 +39,6 @@ unsigned long initial_images_nrpages(voi
>  void discard_initial_images(void);
>  
>  int xen_in_range(unsigned long mfn);
> -void arch_get_xen_caps(xen_capabilities_info_t *info);
>  
>  void microcode_grab_module(
>      unsigned long *, const multiboot_info_t *, void *(*)(const module_t *));
> --- 2012-01-12.orig/xen/include/xen/hypercall.h 2011-11-16 12:40:48.000000000
> +0100
> +++ 2012-01-12/xen/include/xen/hypercall.h 2012-01-12 11:50:17.000000000 +0100
> @@ -14,6 +14,7 @@
>  #include <public/platform.h>
>  #include <public/event_channel.h>
>  #include <public/tmem.h>
> +#include <public/version.h>
>  #include <asm/hypercall.h>
>  #include <xsm/xsm.h>
>  
> @@ -45,6 +46,11 @@ do_sysctl(
>      XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
>  
>  extern long
> +arch_do_sysctl(
> +    struct xen_sysctl *sysctl,
> +    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
> +
> +extern long
>  do_platform_op(
>      XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op);
>  
> @@ -102,6 +108,12 @@ do_vcpu_op(
>      int vcpuid,
>      XEN_GUEST_HANDLE(void) arg);
>  
> +struct vcpu;
> +extern long
> +arch_do_vcpu_op(int cmd,
> +    struct vcpu *v,
> +    XEN_GUEST_HANDLE(void) arg);
> +
>  extern long
>  do_nmi_op(
>      unsigned int cmd,
> @@ -167,4 +179,6 @@ compat_set_timer_op(
>  
>  #endif
>  
> +void arch_get_xen_caps(xen_capabilities_info_t *info);
> +
>  #endif /* __XEN_HYPERCALL_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 Thu Jan 12 12:36:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJtG-0001R8-8X; Thu, 12 Jan 2012 12:36:22 +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 1RlJtE-0001QF-TL
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:36:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326371773!8538993!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 17288 invoked from network); 12 Jan 2012 12:36:14 -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;
	12 Jan 2012 12:36:14 -0000
Received: by wibhj8 with SMTP id hj8so700894wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 04:36:13 -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=l0rOEb7nq5VeSnHSvIW2lftHoI6ru5mX1FF0Yxnh/bc=;
	b=jaHV5MnDfT9LC1TrhIyTlmlrtInEis/vxgZ3g6eaM1ncBoGKmYWI0w49NX2oFao4np
	jNFd65IzDhYstURFRkvRj1ziNqkY5J1yD49he+iWFNd8KfwMS2+cL3y+KiXT6SlIR483
	htWhs+dUyA+hH3PBP2KRO2wQA4wxTL4SKoxCg=
Received: by 10.180.83.231 with SMTP id t7mr5597607wiy.20.1326371773249;
	Thu, 12 Jan 2012 04:36:13 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id ek1sm231708wib.10.2012.01.12.04.36.12
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 04:36:12 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 12:36: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: <CB348433.374A4%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] move declarations of some required per-arch
	functions into common headers
Thread-Index: AczRJr773C93nI376Uqm3MdlkkadgQ==
In-Reply-To: <4F0EE0D8020000780006C15F@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] move declarations of some required per-arch
 functions into common 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/01/2012 12:32, "Jan Beulich" <JBeulich@suse.com> wrote:

> ... since it is pointless to have each arch declare them on their own
> (and now and the - see ia64 - forget to do so).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- 2012-01-12.orig/xen/arch/ia64/xen/dom0_ops.c 2011-11-16 12:40:48.000000000
> +0100
> +++ 2012-01-12/xen/arch/ia64/xen/dom0_ops.c 2012-01-12 11:47:51.000000000
> +0100
> @@ -19,6 +19,7 @@
>  #include <xen/console.h>
>  #include <xen/grant_table.h>
>  #include <xen/guest_access.h>
> +#include <xen/hypercall.h>
>  #include <xen/pci.h>
>  #include <asm/vmx.h>
>  #include <asm/dom_fw.h>
> --- 2012-01-12.orig/xen/arch/ia64/xen/domain.c 2011-11-16 12:40:48.000000000
> +0100
> +++ 2012-01-12/xen/arch/ia64/xen/domain.c 2012-01-12 11:45:30.000000000 +0100
> @@ -31,6 +31,7 @@
>  #include <asm/processor.h>
>  #include <xen/event.h>
>  #include <xen/console.h>
> +#include <xen/hypercall.h>
>  #include <xen/version.h>
>  #include <xen/libelf.h>
>  #include <asm/pgalloc.h>
> --- 2012-01-12.orig/xen/arch/ia64/xen/xensetup.c 2011-11-02 09:22:59.000000000
> +0100
> +++ 2012-01-12/xen/arch/ia64/xen/xensetup.c 2012-01-12 11:52:35.000000000
> +0100
> @@ -10,7 +10,7 @@
>  #include <xen/multiboot.h>
>  #include <xen/sched.h>
>  #include <xen/mm.h>
> -#include <public/version.h>
> +#include <xen/hypercall.h>
>  #include <xen/gdbstub.h>
>  #include <xen/version.h>
>  #include <xen/console.h>
> --- 2012-01-12.orig/xen/arch/x86/domain.c 2011-11-11 10:11:23.000000000 +0100
> +++ 2012-01-12/xen/arch/x86/domain.c 2012-01-12 11:45:59.000000000 +0100
> @@ -23,6 +23,7 @@
>  #include <xen/grant_table.h>
>  #include <xen/iocap.h>
>  #include <xen/kernel.h>
> +#include <xen/hypercall.h>
>  #include <xen/multicall.h>
>  #include <xen/irq.h>
>  #include <xen/event.h>
> @@ -46,7 +47,6 @@
>  #include <asm/xstate.h>
>  #include <asm/mpspec.h>
>  #include <asm/ldt.h>
> -#include <asm/hypercall.h>
>  #include <asm/fixmap.h>
>  #include <asm/hvm/hvm.h>
>  #include <asm/hvm/support.h>
> --- 2012-01-12.orig/xen/arch/x86/x86_64/domain.c 2009-08-19 17:01:49.000000000
> +0200
> +++ 2012-01-12/xen/arch/x86/x86_64/domain.c 2012-01-12 11:46:27.000000000
> +0100
> @@ -6,7 +6,7 @@
>  #include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/guest_access.h>
> -#include <asm/hypercall.h>
> +#include <xen/hypercall.h>
>  #include <compat/vcpu.h>
>  
>  #define xen_vcpu_info vcpu_info
> --- 2012-01-12.orig/xen/common/kernel.c 2011-08-08 08:29:50.000000000 +0200
> +++ 2012-01-12/xen/common/kernel.c 2012-01-12 11:51:52.000000000 +0100
> @@ -13,13 +13,10 @@
>  #include <xen/paging.h>
>  #include <xen/nmi.h>
>  #include <xen/guest_access.h>
> +#include <xen/hypercall.h>
>  #include <asm/current.h>
>  #include <public/nmi.h>
>  #include <public/version.h>
> -#ifdef CONFIG_X86
> -#include <asm/shared.h>
> -#include <asm/setup.h>
> -#endif
>  
>  #ifndef COMPAT
>  
> --- 2012-01-12.orig/xen/include/asm-ia64/hypercall.h 2007-03-26
> 16:26:13.000000000 +0200
> +++ 2012-01-12/xen/include/asm-ia64/hypercall.h 2012-01-12 11:42:06.000000000
> +0100
> @@ -22,7 +22,4 @@ vmx_do_mmu_update(
>      u64 *pdone,
>      u64 foreigndom);
>  
> -extern long
> -arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg);
> -
>  #endif /* __ASM_IA64_HYPERCALL_H__ */
> --- 2012-01-12.orig/xen/include/asm-x86/hypercall.h 2011-11-16
> 12:40:48.000000000 +0100
> +++ 2012-01-12/xen/include/asm-x86/hypercall.h 2012-01-12 11:43:21.000000000
> +0100
> @@ -90,16 +90,6 @@ extern unsigned long
>  do_iret(
>      void);
>  
> -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);
> -
>  extern int
>  do_kexec(
>      unsigned long op, unsigned arg1, XEN_GUEST_HANDLE(void) uarg);
> --- 2012-01-12.orig/xen/include/asm-x86/setup.h 2011-12-23 08:54:33.000000000
> +0100
> +++ 2012-01-12/xen/include/asm-x86/setup.h 2012-01-12 11:49:09.000000000 +0100
> @@ -2,7 +2,6 @@
>  #define __X86_SETUP_H_
>  
>  #include <xen/multiboot.h>
> -#include <public/version.h>
>  
>  extern bool_t early_boot;
>  extern unsigned long xenheap_initial_phys_start;
> @@ -40,7 +39,6 @@ unsigned long initial_images_nrpages(voi
>  void discard_initial_images(void);
>  
>  int xen_in_range(unsigned long mfn);
> -void arch_get_xen_caps(xen_capabilities_info_t *info);
>  
>  void microcode_grab_module(
>      unsigned long *, const multiboot_info_t *, void *(*)(const module_t *));
> --- 2012-01-12.orig/xen/include/xen/hypercall.h 2011-11-16 12:40:48.000000000
> +0100
> +++ 2012-01-12/xen/include/xen/hypercall.h 2012-01-12 11:50:17.000000000 +0100
> @@ -14,6 +14,7 @@
>  #include <public/platform.h>
>  #include <public/event_channel.h>
>  #include <public/tmem.h>
> +#include <public/version.h>
>  #include <asm/hypercall.h>
>  #include <xsm/xsm.h>
>  
> @@ -45,6 +46,11 @@ do_sysctl(
>      XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
>  
>  extern long
> +arch_do_sysctl(
> +    struct xen_sysctl *sysctl,
> +    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl);
> +
> +extern long
>  do_platform_op(
>      XEN_GUEST_HANDLE(xen_platform_op_t) u_xenpf_op);
>  
> @@ -102,6 +108,12 @@ do_vcpu_op(
>      int vcpuid,
>      XEN_GUEST_HANDLE(void) arg);
>  
> +struct vcpu;
> +extern long
> +arch_do_vcpu_op(int cmd,
> +    struct vcpu *v,
> +    XEN_GUEST_HANDLE(void) arg);
> +
>  extern long
>  do_nmi_op(
>      unsigned int cmd,
> @@ -167,4 +179,6 @@ compat_set_timer_op(
>  
>  #endif
>  
> +void arch_get_xen_caps(xen_capabilities_info_t *info);
> +
>  #endif /* __XEN_HYPERCALL_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 Thu Jan 12 12:38:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJvJ-0001hr-S8; Thu, 12 Jan 2012 12:38:29 +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 1RlJvH-0001h5-Tq
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:38:28 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326371900!3209703!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 14882 invoked from network); 12 Jan 2012 12:38:21 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 12:38:21 -0000
Received: by vbbfa15 with SMTP id fa15so1560398vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 04:38:20 -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=VKVQFZvoHQ28p/aD06TdnPs/oSVr1Y/VqCNYSqPDNYY=;
	b=CAnf3KrVLg6iKkEMOrDExA8RKqSUCbHtOyLnRWTXI8lq319NpSc/4eEk7fJZipLTxN
	3jKeaeVk8of/Vz99TCKINr0bw5PaZjxOwtpR1WqVzRV5zEMHoz7quygqYC/Kqie24Q1z
	c559K5m/LoytyMzkUH4uehUgBCX0EbaI0rKb4=
Received: by 10.52.174.102 with SMTP id br6mr1466364vdc.68.1326371900128; Thu,
	12 Jan 2012 04:38:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.108.207 with HTTP; Thu, 12 Jan 2012 04:37:59 -0800 (PST)
In-Reply-To: <20111212163229.GA23490@andromeda.dapyr.net>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
	<20111212163229.GA23490@andromeda.dapyr.net>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 12 Jan 2012 12:37:59 +0000
Message-ID: <CAEBdQ93PCGjbxixbF8vg2T2dOGxvcZSm+JFtoMxawHReiejZwA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xensource.com,
	allen.m.kay@intel.com, Jean Guyader <jean.guyader@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12 December 2011 16:32, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> 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>
>> ---
>> =A0hw/pass-through.c | =A0 =A08 ++--
>> =A0hw/pass-through.h | =A0 =A04 ++
>> =A0hw/pt-graphics.c =A0| =A0 96 ++++++++++++++++++++++++++++++++++++++++=
++----------
>> =A03 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:
>> =A0 =A0 =A0return index;
>> =A0}
>>
>> -static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_=
t val,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int len)
>> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, =
int len)
>> =A0{
>> =A0 =A0 =A0struct pt_dev *assigned_device =3D (struct pt_dev *)d;
>> =A0 =A0 =A0struct pci_dev *pci_dev =3D assigned_device->pci_dev;
>> @@ -1637,7 +1636,7 @@ exit:
>> =A0 =A0 =A0return;
>> =A0}
>>
>> -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)
>> =A0{
>> =A0 =A0 =A0struct pt_dev *assigned_device =3D (struct pt_dev *)d;
>> =A0 =A0 =A0struct pci_dev *pci_dev =3D assigned_device->pci_dev;
>> @@ -4191,7 +4190,8 @@ static struct pt_dev * register_real_device(PCIBus=
 *e_bus,
>> =A0 =A0 =A0/* Register device */
>> =A0 =A0 =A0assigned_device =3D (struct pt_dev *) pci_register_device(e_b=
us, e_dev_name,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeo=
f(struct pt_dev), e_devfn,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pt_pci_=
read_config, pt_pci_write_config);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfx_pas=
sthru ? vgapt_pci_read_config : pt_pci_read_config,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfx_pas=
sthru ? vgapt_pci_write_config : pt_pci_write_config);
>> =A0 =A0 =A0if ( assigned_device =3D=3D NULL )
>> =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0PT_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 devf=
n, uint16_t vid,
>> =A0 =A0 =A0 =A0 =A0 =A0 uint16_t did, const char *name, uint16_t revisio=
n);
>> =A0void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t=
 val, int len);
>> =A0uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int l=
en);
>> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, u=
int32_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);
>>
>> =A0#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 @@
>> =A0extern int gfx_passthru;
>> =A0extern int igd_passthru;
>>
>> +static uint32_t igd_guest_opregion =3D 0;
>> +
>> =A0static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>> =A0{
>> =A0 =A0 =A0PT_LOG("pch_map_irq called\n");
>> @@ -37,6 +39,77 @@ void intel_pch_init(PCIBus *bus)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pch_map_irq, "intel_b=
ridge_1f");
>> =A0}
>>
>> +static void igd_write_opregion(PCIDevice *pci_dev, uint32_t val, int le=
n)
>> +{
>> + =A0 =A0struct pt_dev *real_dev =3D (struct pt_dev *)pci_dev;
>> + =A0 =A0uint32_t host_opregion =3D 0;
>> + =A0 =A0int ret;
>> +
>> + =A0 =A0if ( igd_guest_opregion || len !=3D 4 )
>> + =A0 =A0 =A0 =A0return;
>> +
>> + =A0 =A0host_opregion =3D pt_pci_host_read(real_dev->pci_dev,
>> + =A0 =A0 =A0 =A0 =A0 =A0PCI_INTEL_OPREGION, len);
>
> The tabs here are a bit weird.
>> + =A0 =A0igd_guest_opregion =3D (val & ~0xfff) | (host_opregion & 0xfff);
>> + =A0 =A0PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opr=
egion);
>> +
>> + =A0 =A0ret =3D xc_domain_memory_mapping(xc_handle, domid,
>> + =A0 =A0 =A0 =A0 =A0 =A0igd_guest_opregion >> XC_PAGE_SHIFT,
>> + =A0 =A0 =A0 =A0 =A0 =A0host_opregion >> XC_PAGE_SHIFT,
>> + =A0 =A0 =A0 =A0 =A0 =A02,
>> + =A0 =A0 =A0 =A0 =A0 =A0DPCI_ADD_MAPPING);
>> +
>
> Shouldn't you unmap the older region first?
>

We don't really need to. This region can't be remapped.

The trick I used here will only work once. Once the page has been mapped
by hvmloader it will stay where it is.

Jean

>> + =A0 =A0if ( ret !=3D 0 )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0PT_LOG("Error: Can't map opregion\n");
>> + =A0 =A0 =A0 =A0igd_guest_opregion =3D 0;
>> + =A0 =A0}
>> +}
>> +
>> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, u=
int32_t val, int len)
>> +{
>> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
>> + =A0 =A0PT_LOG("vgapt_pci_write_config: %x:%x.%x: addr=3D%x len=3D%x va=
l=3D%x\n",
>> + =A0 =A0 =A0 =A0 =A0 =A0pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->de=
vfn),
>> + =A0 =A0 =A0 =A0 =A0 =A0PCI_FUNC(pci_dev->devfn), config_addr, len, val=
);
>> +#endif
>> +
>> + =A0 =A0if ( igd_passthru )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0switch ( config_addr )
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0case 0xfc : /* Opregion */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_write_opregion(pci_dev, val, len);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return;
>
> No default case? I would think the compiler would throw a fit for that.
>
>> + =A0 =A0 =A0 =A0}
>> + =A0 =A0}
>> +
>> + =A0 =A0pt_pci_write_config(pci_dev, config_addr, val, len);
>> +}
>> +
>> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr=
, int len)
>> +{
>> + =A0 =A0uint32_t val;
>> +
>> + =A0 =A0val =3D pt_pci_read_config(pci_dev, config_addr, len);
>> +
>> + =A0 =A0if ( igd_passthru )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0switch ( config_addr )
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0case 0xfc: /* OpRegion */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( igd_guest_opregion )
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0val =3D igd_guest_opregion;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> + =A0 =A0 =A0 =A0}
>> + =A0 =A0}
>> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
>> + =A0 =A0PT_LOG_DEV(pci_dev, "vgapt_pci_read_config: %x:%x.%x: addr=3D%x=
 len=3D%x val=3D%x\n",
>> + =A0 =A0 =A0 =A0 =A0 =A0config_addr, len, val);
>> +#endif
>> + =A0 =A0return val;
>> +}
>> +
>> =A0void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t=
 val, int len)
>> =A0{
>> =A0 =A0 =A0struct pci_dev *pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, =
0);
>> @@ -99,7 +172,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t co=
nfig_addr, int len)
>> =A0int register_vga_regions(struct pt_dev *real_device)
>> =A0{
>> =A0 =A0 =A0u16 vendor_id;
>> - =A0 =A0int igd_opregion;
>> =A0 =A0 =A0int ret =3D 0;
>>
>> =A0 =A0 =A0if ( !gfx_passthru || real_device->pci_dev->device_class !=3D=
 0x0300 )
>> @@ -117,19 +189,6 @@ int register_vga_regions(struct pt_dev *real_device)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A00x20,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0DPCI_ADD_MAPPING);
>>
>> - =A0 =A0/* 1:1 map ASL Storage register value */
>> - =A0 =A0vendor_id =3D pt_pci_host_read(real_device->pci_dev, 0, 2);
>> - =A0 =A0igd_opregion =3D pt_pci_host_read(real_device->pci_dev, PCI_INT=
EL_OPREGION, 4);
>> - =A0 =A0if ( (vendor_id =3D=3D PCI_VENDOR_ID_INTEL ) && igd_opregion )
>> - =A0 =A0{
>> - =A0 =A0 =A0 =A0ret |=3D xc_domain_memory_mapping(xc_handle, domid,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_opregion >> XC_PAGE_SHIFT,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_opregion >> XC_PAGE_SHIFT,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPCI_ADD_MAPPING);
>> - =A0 =A0 =A0 =A0PT_LOG("register_vga: igd_opregion =3D %x\n", igd_opreg=
ion);
>> - =A0 =A0}
>> -
>> =A0 =A0 =A0if ( ret !=3D 0 )
>> =A0 =A0 =A0 =A0 =A0PT_LOG("VGA region mapping failed\n");
>>
>> @@ -141,7 +200,7 @@ int register_vga_regions(struct pt_dev *real_device)
>> =A0 */
>> =A0int unregister_vga_regions(struct pt_dev *real_device)
>> =A0{
>> - =A0 =A0u32 vendor_id, igd_opregion;
>> + =A0 =A0u32 vendor_id;
>> =A0 =A0 =A0int ret =3D 0;
>>
>> =A0 =A0 =A0if ( !gfx_passthru || real_device->pci_dev->device_class !=3D=
 0x0300 )
>> @@ -160,12 +219,11 @@ int unregister_vga_regions(struct pt_dev *real_dev=
ice)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0DPCI_REMOVE_MAPPING);
>>
>> =A0 =A0 =A0vendor_id =3D pt_pci_host_read(real_device->pci_dev, PCI_VEND=
OR_ID, 2);
>> - =A0 =A0igd_opregion =3D pt_pci_host_read(real_device->pci_dev, PCI_INT=
EL_OPREGION, 4);
>> - =A0 =A0if ( (vendor_id =3D=3D PCI_VENDOR_ID_INTEL) && igd_opregion )
>> + =A0 =A0if ( (vendor_id =3D=3D PCI_VENDOR_ID_INTEL) && igd_guest_opregi=
on )
>> =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0ret |=3D xc_domain_memory_mapping(xc_handle, domid,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_opregion >> XC_PAGE_SHIFT,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_opregion >> XC_PAGE_SHIFT,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_guest_opregion >> XC_PAGE_SHIFT,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_guest_opregion >> XC_PAGE_SHIFT,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPCI_REMOVE_MAPPING);
>> =A0 =A0 =A0}
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:38:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:38:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJvJ-0001hr-S8; Thu, 12 Jan 2012 12:38:29 +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 1RlJvH-0001h5-Tq
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:38:28 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326371900!3209703!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 14882 invoked from network); 12 Jan 2012 12:38:21 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 12:38:21 -0000
Received: by vbbfa15 with SMTP id fa15so1560398vbb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 04:38:20 -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=VKVQFZvoHQ28p/aD06TdnPs/oSVr1Y/VqCNYSqPDNYY=;
	b=CAnf3KrVLg6iKkEMOrDExA8RKqSUCbHtOyLnRWTXI8lq319NpSc/4eEk7fJZipLTxN
	3jKeaeVk8of/Vz99TCKINr0bw5PaZjxOwtpR1WqVzRV5zEMHoz7quygqYC/Kqie24Q1z
	c559K5m/LoytyMzkUH4uehUgBCX0EbaI0rKb4=
Received: by 10.52.174.102 with SMTP id br6mr1466364vdc.68.1326371900128; Thu,
	12 Jan 2012 04:38:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.108.207 with HTTP; Thu, 12 Jan 2012 04:37:59 -0800 (PST)
In-Reply-To: <20111212163229.GA23490@andromeda.dapyr.net>
References: <1322411006-12629-1-git-send-email-jean.guyader@eu.citrix.com>
	<20111212163229.GA23490@andromeda.dapyr.net>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Thu, 12 Jan 2012 12:37:59 +0000
Message-ID: <CAEBdQ93PCGjbxixbF8vg2T2dOGxvcZSm+JFtoMxawHReiejZwA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xensource.com,
	allen.m.kay@intel.com, Jean Guyader <jean.guyader@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12 December 2011 16:32, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> 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>
>> ---
>> =A0hw/pass-through.c | =A0 =A08 ++--
>> =A0hw/pass-through.h | =A0 =A04 ++
>> =A0hw/pt-graphics.c =A0| =A0 96 ++++++++++++++++++++++++++++++++++++++++=
++----------
>> =A03 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:
>> =A0 =A0 =A0return index;
>> =A0}
>>
>> -static void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_=
t val,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int len)
>> +void pt_pci_write_config(PCIDevice *d, uint32_t address, uint32_t val, =
int len)
>> =A0{
>> =A0 =A0 =A0struct pt_dev *assigned_device =3D (struct pt_dev *)d;
>> =A0 =A0 =A0struct pci_dev *pci_dev =3D assigned_device->pci_dev;
>> @@ -1637,7 +1636,7 @@ exit:
>> =A0 =A0 =A0return;
>> =A0}
>>
>> -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)
>> =A0{
>> =A0 =A0 =A0struct pt_dev *assigned_device =3D (struct pt_dev *)d;
>> =A0 =A0 =A0struct pci_dev *pci_dev =3D assigned_device->pci_dev;
>> @@ -4191,7 +4190,8 @@ static struct pt_dev * register_real_device(PCIBus=
 *e_bus,
>> =A0 =A0 =A0/* Register device */
>> =A0 =A0 =A0assigned_device =3D (struct pt_dev *) pci_register_device(e_b=
us, e_dev_name,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeo=
f(struct pt_dev), e_devfn,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pt_pci_=
read_config, pt_pci_write_config);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfx_pas=
sthru ? vgapt_pci_read_config : pt_pci_read_config,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gfx_pas=
sthru ? vgapt_pci_write_config : pt_pci_write_config);
>> =A0 =A0 =A0if ( assigned_device =3D=3D NULL )
>> =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0PT_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 devf=
n, uint16_t vid,
>> =A0 =A0 =A0 =A0 =A0 =A0 uint16_t did, const char *name, uint16_t revisio=
n);
>> =A0void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t=
 val, int len);
>> =A0uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int l=
en);
>> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, u=
int32_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);
>>
>> =A0#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 @@
>> =A0extern int gfx_passthru;
>> =A0extern int igd_passthru;
>>
>> +static uint32_t igd_guest_opregion =3D 0;
>> +
>> =A0static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
>> =A0{
>> =A0 =A0 =A0PT_LOG("pch_map_irq called\n");
>> @@ -37,6 +39,77 @@ void intel_pch_init(PCIBus *bus)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pch_map_irq, "intel_b=
ridge_1f");
>> =A0}
>>
>> +static void igd_write_opregion(PCIDevice *pci_dev, uint32_t val, int le=
n)
>> +{
>> + =A0 =A0struct pt_dev *real_dev =3D (struct pt_dev *)pci_dev;
>> + =A0 =A0uint32_t host_opregion =3D 0;
>> + =A0 =A0int ret;
>> +
>> + =A0 =A0if ( igd_guest_opregion || len !=3D 4 )
>> + =A0 =A0 =A0 =A0return;
>> +
>> + =A0 =A0host_opregion =3D pt_pci_host_read(real_dev->pci_dev,
>> + =A0 =A0 =A0 =A0 =A0 =A0PCI_INTEL_OPREGION, len);
>
> The tabs here are a bit weird.
>> + =A0 =A0igd_guest_opregion =3D (val & ~0xfff) | (host_opregion & 0xfff);
>> + =A0 =A0PT_LOG("Map OpRegion: %x -> %x\n", host_opregion, igd_guest_opr=
egion);
>> +
>> + =A0 =A0ret =3D xc_domain_memory_mapping(xc_handle, domid,
>> + =A0 =A0 =A0 =A0 =A0 =A0igd_guest_opregion >> XC_PAGE_SHIFT,
>> + =A0 =A0 =A0 =A0 =A0 =A0host_opregion >> XC_PAGE_SHIFT,
>> + =A0 =A0 =A0 =A0 =A0 =A02,
>> + =A0 =A0 =A0 =A0 =A0 =A0DPCI_ADD_MAPPING);
>> +
>
> Shouldn't you unmap the older region first?
>

We don't really need to. This region can't be remapped.

The trick I used here will only work once. Once the page has been mapped
by hvmloader it will stay where it is.

Jean

>> + =A0 =A0if ( ret !=3D 0 )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0PT_LOG("Error: Can't map opregion\n");
>> + =A0 =A0 =A0 =A0igd_guest_opregion =3D 0;
>> + =A0 =A0}
>> +}
>> +
>> +void vgapt_pci_write_config(PCIDevice *pci_dev, uint32_t config_addr, u=
int32_t val, int len)
>> +{
>> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
>> + =A0 =A0PT_LOG("vgapt_pci_write_config: %x:%x.%x: addr=3D%x len=3D%x va=
l=3D%x\n",
>> + =A0 =A0 =A0 =A0 =A0 =A0pci_bus_num(pci_dev->bus), PCI_SLOT(pci_dev->de=
vfn),
>> + =A0 =A0 =A0 =A0 =A0 =A0PCI_FUNC(pci_dev->devfn), config_addr, len, val=
);
>> +#endif
>> +
>> + =A0 =A0if ( igd_passthru )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0switch ( config_addr )
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0case 0xfc : /* Opregion */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_write_opregion(pci_dev, val, len);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return;
>
> No default case? I would think the compiler would throw a fit for that.
>
>> + =A0 =A0 =A0 =A0}
>> + =A0 =A0}
>> +
>> + =A0 =A0pt_pci_write_config(pci_dev, config_addr, val, len);
>> +}
>> +
>> +uint32_t vgapt_pci_read_config(PCIDevice *pci_dev, uint32_t config_addr=
, int len)
>> +{
>> + =A0 =A0uint32_t val;
>> +
>> + =A0 =A0val =3D pt_pci_read_config(pci_dev, config_addr, len);
>> +
>> + =A0 =A0if ( igd_passthru )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0switch ( config_addr )
>> + =A0 =A0 =A0 =A0{
>> + =A0 =A0 =A0 =A0 =A0 =A0case 0xfc: /* OpRegion */
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( igd_guest_opregion )
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0val =3D igd_guest_opregion;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
>> + =A0 =A0 =A0 =A0}
>> + =A0 =A0}
>> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
>> + =A0 =A0PT_LOG_DEV(pci_dev, "vgapt_pci_read_config: %x:%x.%x: addr=3D%x=
 len=3D%x val=3D%x\n",
>> + =A0 =A0 =A0 =A0 =A0 =A0config_addr, len, val);
>> +#endif
>> + =A0 =A0return val;
>> +}
>> +
>> =A0void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t=
 val, int len)
>> =A0{
>> =A0 =A0 =A0struct pci_dev *pci_dev_host_bridge =3D pt_pci_get_dev(0, 0, =
0);
>> @@ -99,7 +172,6 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t co=
nfig_addr, int len)
>> =A0int register_vga_regions(struct pt_dev *real_device)
>> =A0{
>> =A0 =A0 =A0u16 vendor_id;
>> - =A0 =A0int igd_opregion;
>> =A0 =A0 =A0int ret =3D 0;
>>
>> =A0 =A0 =A0if ( !gfx_passthru || real_device->pci_dev->device_class !=3D=
 0x0300 )
>> @@ -117,19 +189,6 @@ int register_vga_regions(struct pt_dev *real_device)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A00x20,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0DPCI_ADD_MAPPING);
>>
>> - =A0 =A0/* 1:1 map ASL Storage register value */
>> - =A0 =A0vendor_id =3D pt_pci_host_read(real_device->pci_dev, 0, 2);
>> - =A0 =A0igd_opregion =3D pt_pci_host_read(real_device->pci_dev, PCI_INT=
EL_OPREGION, 4);
>> - =A0 =A0if ( (vendor_id =3D=3D PCI_VENDOR_ID_INTEL ) && igd_opregion )
>> - =A0 =A0{
>> - =A0 =A0 =A0 =A0ret |=3D xc_domain_memory_mapping(xc_handle, domid,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_opregion >> XC_PAGE_SHIFT,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_opregion >> XC_PAGE_SHIFT,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPCI_ADD_MAPPING);
>> - =A0 =A0 =A0 =A0PT_LOG("register_vga: igd_opregion =3D %x\n", igd_opreg=
ion);
>> - =A0 =A0}
>> -
>> =A0 =A0 =A0if ( ret !=3D 0 )
>> =A0 =A0 =A0 =A0 =A0PT_LOG("VGA region mapping failed\n");
>>
>> @@ -141,7 +200,7 @@ int register_vga_regions(struct pt_dev *real_device)
>> =A0 */
>> =A0int unregister_vga_regions(struct pt_dev *real_device)
>> =A0{
>> - =A0 =A0u32 vendor_id, igd_opregion;
>> + =A0 =A0u32 vendor_id;
>> =A0 =A0 =A0int ret =3D 0;
>>
>> =A0 =A0 =A0if ( !gfx_passthru || real_device->pci_dev->device_class !=3D=
 0x0300 )
>> @@ -160,12 +219,11 @@ int unregister_vga_regions(struct pt_dev *real_dev=
ice)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0DPCI_REMOVE_MAPPING);
>>
>> =A0 =A0 =A0vendor_id =3D pt_pci_host_read(real_device->pci_dev, PCI_VEND=
OR_ID, 2);
>> - =A0 =A0igd_opregion =3D pt_pci_host_read(real_device->pci_dev, PCI_INT=
EL_OPREGION, 4);
>> - =A0 =A0if ( (vendor_id =3D=3D PCI_VENDOR_ID_INTEL) && igd_opregion )
>> + =A0 =A0if ( (vendor_id =3D=3D PCI_VENDOR_ID_INTEL) && igd_guest_opregi=
on )
>> =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0ret |=3D xc_domain_memory_mapping(xc_handle, domid,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_opregion >> XC_PAGE_SHIFT,
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_opregion >> XC_PAGE_SHIFT,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_guest_opregion >> XC_PAGE_SHIFT,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0igd_guest_opregion >> XC_PAGE_SHIFT,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DPCI_REMOVE_MAPPING);
>> =A0 =A0 =A0}
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:39:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJvc-0001kG-A1; Thu, 12 Jan 2012 12:38:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RlJvZ-0001jT-NS
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:38:46 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326371912!8299286!1
X-Originating-IP: [188.40.164.121]
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 24944 invoked from network); 12 Jan 2012 12:38:33 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jan 2012 12:38:33 -0000
Received: from 25-72-ftth.onsneteindhoven.nl ([88.159.72.25]:52147
	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 1RlJtA-00007F-U8; Thu, 12 Jan 2012 13:36:17 +0100
Date: Thu, 12 Jan 2012 13:38:32 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <498097597.20120112133832@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0B61A709518B22542"
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
	Failed to query current memory allocation of 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

------------0B61A709518B22542
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Konrad,

Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).

It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.

dmesg and xm dmesg attached

--
Sander


Dom0 shows:
             total       used       free     shared    buffers     cached
Mem:        938860     220484     718376          0      27812      72128
-/+ buffers/cache:     120544     818316
Swap:      2097148          0    2097148


xentop:

xentop - 13:34:31   Xen 4.1.3-rc1-pre
1 domains: 1 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 8386732k total, 1165260k used, 7221472k free    CPUs: 6 @ 3200MHz
      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR  VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r         82    1.3    1048192   12.5   no limit       n/a     6    0        0        0    0        0        0        0          0          0    0



------------0B61A709518B22542
Content-Type: text/plain;
 name="dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="dmesg.txt"

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAg
IDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAw
MDBdIExpbnV4IHZlcnNpb24gMy4yLjAtcmMwKyAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdj
YyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjOSBTTVAgVGh1IEphbiAxMiAx
Mjo0MDoyNCBDRVQgMjAxMg0KWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiByb290PS9k
ZXYvbWFwcGVyL3NlcnZlZXJzdGVydGplLXJvb3Qgcm8gdmVyYm9zZSBtZW09MTAyNE0gY29u
c29sZT1odmMwIGNvbnNvbGU9dHR5MCBub21vZGVzZXQgdmdhPTc5NCB2aWRlbz12ZXNhZmIg
ZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgeGVuLXBjaWJh
Y2sucGFzc3Rocm91Z2g9MSB4ZW4tcGNpYmFjay5oaWRlPSgwMzowNi4wKSgwNDowMC4wKSgw
NDowMC4xKSgwNDowMC4yKSgwNDowMC4zKSgwNDowMC40KSgwNDowMC41KSgwNDowMC42KSgw
NDowMC43KSgwYTowMC4wKSgwYTowMC4xKSgwYTowMC4yKSgwYTowMC4zKSgwYTowMC40KSgw
YTowMC41KSgwYTowMC42KSgwYTowMC43KSgwNTowMC4wKSgwNTowMC4xKSgwNzowMS4wKSgw
NzowMS4xKSgwNzowMS4yKSBwY2k9cmVzb3VyY2VfYWxpZ25tZW50PTA3OjAxLjA7MDc6MDEu
MTswNzowMS4yIGRlYnVnIGRlYnVnIGxvZ2xldmVsPTEwDQpbICAgIDAuMDAwMDAwXSBGcmVl
aW5nICA5Yi0xMDAgcGZuIHJhbmdlOiAxMDEgcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBd
IDEtMSBtYXBwaW5nIG9uIDliLT4xMDANClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9u
IGFmZTkwLT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDEwMSBwYWdlcyBvZiB1
bnVzZWQgbWVtb3J5DQpbICAgIDAuMDAwMDAwXSBTZXQgMzI4MTQ5IHBhZ2UocykgdG8gMS0x
IG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1h
cDoNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw
MDliMDAwICh1c2FibGUpDQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMDliMDAw
IC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQpbICAgIDAuMDAwMDAwXSAgWGVuOiAw
MDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmU5MDAwMCAodXNhYmxlKQ0KWyAgICAwLjAw
MDAwMF0gIFhlbjogMDAwMDAwMDBhZmU5MDAwMCAtIDAwMDAwMDAwYWZlOWUwMDAgKEFDUEkg
ZGF0YSkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYWZlOWUwMDAgLSAwMDAwMDAw
MGFmZWUwMDAwIChBQ1BJIE5WUykNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYWZl
ZTAwMDAgLSAwMDAwMDAwMGFmZjAwMDAwIChyZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdICBY
ZW46IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkNClsg
ICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVjMjAwMDAgLSAwMDAwMDAwMGZlYzIxMDAw
IChyZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAw
MDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw
MDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNClsgICAgMC4wMDAw
MDBdICBYZW46IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjUwMDAwMDAwICh1c2FibGUp
DQpbICAgIDAuMDAwMDAwXSBlODIwIHJlbW92ZSByYW5nZTogMDAwMDAwMDA0MDAwMDAwMCAt
IGZmZmZmZmZmZmZmZmZmZmYgKHVzYWJsZSkNClsgICAgMC4wMDAwMDBdIGJvb3Rjb25zb2xl
IFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJs
ZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAwXSB1c2VyLWRlZmluZWQgcGh5
c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMDAwMDAwMDAw
IC0gMDAwMDAwMDAwMDA5YjAwMCAodXNhYmxlKQ0KWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAw
MDAwMDAwMDAwOWIwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkNClsgICAgMC4w
MDAwMDBdICB1c2VyOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDA0MDAwMDAwMCAodXNh
YmxlKQ0KWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAwYWZlOTAwMDAgLSAwMDAwMDAw
MGFmZTllMDAwIChBQ1BJIGRhdGEpDQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDBh
ZmU5ZTAwMCAtIDAwMDAwMDAwYWZlZTAwMDAgKEFDUEkgTlZTKQ0KWyAgICAwLjAwMDAwMF0g
IHVzZXI6IDAwMDAwMDAwYWZlZTAwMDAgLSAwMDAwMDAwMGFmZjAwMDAwIChyZXNlcnZlZCkN
ClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMw
MTAwMCAocmVzZXJ2ZWQpDQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDBmZWMyMDAw
MCAtIDAwMDAwMDAwZmVjMjEwMDAgKHJlc2VydmVkKQ0KWyAgICAwLjAwMDAwMF0gIHVzZXI6
IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkNClsgICAg
MC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAo
cmVzZXJ2ZWQpDQpbICAgIDAuMDAwMDAwXSBETUkgcHJlc2VudC4NClsgICAgMC4wMDAwMDBd
IERNSTogTVNJIE1TLTc2NDAvODkwRlhBLUdENzAgKE1TLTc2NDApICAsIEJJT1MgVjEuN0I1
IDA2LzIyLzIwMTANClsgICAgMC4wMDAwMDBdIGU4MjAgdXBkYXRlIHJhbmdlOiAwMDAwMDAw
MDAwMDAwMDAwIC0gMDAwMDAwMDAwMDAxMDAwMCAodXNhYmxlKSA9PT4gKHJlc2VydmVkKQ0K
WyAgICAwLjAwMDAwMF0gZTgyMCByZW1vdmUgcmFuZ2U6IDAwMDAwMDAwMDAwYTAwMDAgLSAw
MDAwMDAwMDAwMTAwMDAwICh1c2FibGUpDQpbICAgIDAuMDAwMDAwXSBObyBBR1AgYnJpZGdl
IGZvdW5kDQpbICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4NDAwMDAgbWF4X2FyY2hfcGZu
ID0gMHg0MDAwMDAwMDANClsgICAgMC4wMDAwMDBdIGZvdW5kIFNNUCBNUC10YWJsZSBhdCBb
ZmZmZjg4MDAwMDBmZjc4MF0gZmY3ODANClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5
IG1hcHBlZCA6IDAgLSAwMzFlYjAwMA0KWyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJh
bXBvbGluZSBhdCBbZmZmZjg4MDAwMDA5OTAwMF0gOTkwMDAgc2l6ZSA4MTkyDQpbICAgIDAu
MDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAw
NDAwMDAwMDANClsgICAgMC4wMDAwMDBdICAwMDAwMDAwMDAwIC0gMDA0MDAwMDAwMCBwYWdl
IDRrDQpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRv
IDQwMDAwMDAwIEAgMjk1ODAwMC0yYjVhMDAwDQpbICAgIDAuMDAwMDAwXSB4ZW46IHNldHRp
bmcgUlcgdGhlIHJhbmdlIDJiMzgwMDAgLSAyYjVhMDAwDQpbICAgIDAuMDAwMDAwXSBSQU1E
SVNLOiAwMmI1YTAwMCAtIDAzMWViMDAwDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQIDAw
MDAwMDAwMDAwZmIxMjAgMDAwMTQgKHYwMCBBQ1BJQU0pDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBSU0RUIDAwMDAwMDAwYWZlOTAwMDAgMDAwNDggKHYwMSBNU0kgICAgT0VNU0xJQyAgMjAx
MDA2MjIgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1AgMDAwMDAw
MDBhZmU5MDIwMCAwMDA4NCAodjAxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUIDAw
MDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAwMDAwMDAwMGFmZTkwNWUwIDA5
NDQ5ICh2MDEgIEE3NjQwIEE3NjQwMTAwIDAwMDAwMTAwIElOVEwgMjAwNTExMTcpDQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBGQUNTIDAwMDAwMDAwYWZlOWUwMDAgMDAwNDANClsgICAgMC4w
MDAwMDBdIEFDUEk6IEFQSUMgMDAwMDAwMDBhZmU5MDM5MCAwMDA4OCAodjAxIDc2NDBNUyBB
NzY0MDEwMCAyMDEwMDYyMiBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TUNGRyAwMDAwMDAwMGFmZTkwNDIwIDAwMDNDICh2MDEgNzY0ME1TIE9FTU1DRkcgIDIwMTAw
NjIyIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTTElDIDAwMDAwMDAw
YWZlOTA0NjAgMDAxNzYgKHYwMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA2MjIgTVNGVCAwMDAw
MDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IE9FTUIgMDAwMDAwMDBhZmU5ZTA0MCAwMDA3
MiAodjAxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogU1JBVCAwMDAwMDAwMGFmZTlhNWUwIDAwMTA4ICh2MDMgQU1EICAg
IEZBTV9GXzEwIDAwMDAwMDAyIEFNRCAgMDAwMDAwMDEpDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBIUEVUIDAwMDAwMDAwYWZlOWE2ZjAgMDAwMzggKHYwMSA3NjQwTVMgT0VNSFBFVCAgMjAx
MDA2MjIgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IElWUlMgMDAwMDAw
MDBhZmU5YTczMCAwMDEwMCAodjAxICBBTUQgICAgIFJEODkwUyAwMDIwMjAzMSBBTUQgIDAw
MDAwMDAwKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCAwMDAwMDAwMGFmZTlhODMwIDAw
REE0ICh2MDEgQSBNIEkgIFBPV0VSTk9XIDAwMDAwMDAxIEFNRCAgMDAwMDAwMDEpDQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAw
LjAwMDAwMF0gU2Nhbm5pbmcgTlVNQSB0b3BvbG9neSBpbiBOb3J0aGJyaWRnZSAyNA0KWyAg
ICAwLjAwMDAwMF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQpbICAgIDAuMDAwMDAw
XSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA0MDAwMDAwMA0K
WyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgMDAwMDAwMDAwMDAwMDAwMC0w
MDAwMDAwMDQwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSAgIE5PREVfREFUQSBbMDAwMDAwMDAz
ZmZmYjAwMCAtIDAwMDAwMDAwM2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBab25lIFBGTiBy
YW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERNQSAgICAgIDB4MDAwMDAwMTAgLT4gMHgwMDAw
MTAwMA0KWyAgICAwLjAwMDAwMF0gICBETUEzMiAgICAweDAwMDAxMDAwIC0+IDB4MDAxMDAw
MDANClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1v
dmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAwMF0gRWFy
bHkgbWVtb3J5IFBGTiByYW5nZXMNClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEw
IC0+IDB4MDAwMDAwOWINClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMTAwIC0+IDB4
MDAwNDAwMDANClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNjIwMjcN
ClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDY0IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMiBwYWdlcyByZXNlcnZlZA0KWyAgICAwLjAw
MDAwMF0gICBETUEgem9uZTogMzkxMyBwYWdlcywgTElGTyBiYXRjaDowDQpbICAgIDAuMDAw
MDAwXSAgIERNQTMyIHpvbmU6IDQwMzIgcGFnZXMgdXNlZCBmb3IgbWVtbWFwDQpbICAgIDAu
MDAwMDAwXSAgIERNQTMyIHpvbmU6IDI1NDAxNiBwYWdlcywgTElGTyBiYXRjaDozMQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg4MDgNClsgICAgMC4wMDAw
MDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0K
WyAgICAwLjAwMDAwMF0gQklPUyBidWc6IEFQSUMgdmVyc2lvbiBpcyAwIGZvciBDUFUgMC8w
eDAsIGZpeGluZyB1cCB0byAweDEwDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVu
YWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBp
Y19pZFsweDA0XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6
IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsg
ICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDI1NSwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yNTUNClsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAo
aWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pDQpbICAgIDAuMDAw
MDAwXSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAyNTUsIGFkZHJlc3MgMHhmZWMy
MDAwMCwgR1NJIDI0LTI3OQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1
cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNClsgICAgMC4wMDAwMDBdIEFD
UEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZl
bCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NClsgICAg
MC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAwMDBd
IEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAwMDBdIFVzaW5nIEFD
UEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KWyAgICAwLjAw
MDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDANClsgICAgMC4w
MDAwMDBdIFNNUDogQWxsb3dpbmcgNiBDUFVzLCAwIGhvdHBsdWcgQ1BVcw0KWyAgICAwLjAw
MDAwMF0gbnJfaXJxc19nc2k6IDI5Ng0KWyAgICAwLjAwMDAwMF0gQWxsb2NhdGluZyBQQ0kg
cmVzb3VyY2VzIHN0YXJ0aW5nIGF0IDQwMDAwMDAwIChnYXA6IDQwMDAwMDAwOjZmZTkwMDAw
KQ0KWyAgICAwLjAwMDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhl
bg0KWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb246IDQuMS4zLXJjMS1wcmUgKHByZXNlcnZl
LUFEKQ0KWyAgICAwLjAwMDAwMF0gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjY0IG5yX2NwdW1h
c2tfYml0czo2NCBucl9jcHVfaWRzOjYgbnJfbm9kZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0g
UEVSQ1BVOiBFbWJlZGRlZCAyNyBwYWdlcy9jcHUgQGZmZmY4ODAwM2ZmM2UwMDAgczc4Nzg0
IHI4MTkyIGQyMzYxNiB1MTEwNTkyDQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzNzg3
ODQgcjgxOTIgZDIzNjE2IHUxMTA1OTIgYWxsb2M9MjcqNDA5Ng0KWyAgICAwLjAwMDAwMF0g
cGNwdS1hbGxvYzogWzBdIDAgWzBdIDEgWzBdIDIgWzBdIDMgWzBdIDQgWzBdIDUgDQpbICAg
IDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2RlIG9yZGVyLCBtb2JpbGl0eSBn
cm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAyNTc5MjkNClsgICAgMC4wMDAwMDBdIFBvbGlj
eSB6b25lOiBETUEzMg0KWyAgICAwLjAwMDAwMF0gS2VybmVsIGNvbW1hbmQgbGluZTogcm9v
dD0vZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1yb290IHJvIHZlcmJvc2UgbWVtPTEwMjRN
IGNvbnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT03OTQgdmlkZW89dmVz
YWZiIGVhcmx5cHJpbnRrPXhlbiBtYXhfbG9vcD01MCBsb29wX21heF9wYXJ0PTEwIHhlbi1w
Y2liYWNrLnBhc3N0aHJvdWdoPTEgeGVuLXBjaWJhY2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAu
MCkoMDQ6MDAuMSkoMDQ6MDAuMikoMDQ6MDAuMykoMDQ6MDAuNCkoMDQ6MDAuNSkoMDQ6MDAu
NikoMDQ6MDAuNykoMGE6MDAuMCkoMGE6MDAuMSkoMGE6MDAuMikoMGE6MDAuMykoMGE6MDAu
NCkoMGE6MDAuNSkoMGE6MDAuNikoMGE6MDAuNykoMDU6MDAuMCkoMDU6MDAuMSkoMDc6MDEu
MCkoMDc6MDEuMSkoMDc6MDEuMikgcGNpPXJlc291cmNlX2FsaWdubWVudD0wNzowMS4wOzA3
OjAxLjE7MDc6MDEuMiBkZWJ1ZyBkZWJ1ZyBsb2dsZXZlbD0xMA0KWyAgICAwLjAwMDAwMF0g
UElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQ0K
WyAgICAwLjAwMDAwMF0gUGxhY2luZyA2NE1CIHNvZnR3YXJlIElPIFRMQiBiZXR3ZWVuIGZm
ZmY4ODAwM2E2MDAwMDAgLSBmZmZmODgwMDNlNjAwMDAwDQpbICAgIDAuMDAwMDAwXSBzb2Z0
d2FyZSBJTyBUTEIgYXQgcGh5cyAweDNhNjAwMDAwIC0gMHgzZTYwMDAwMA0KWyAgICAwLjAw
MDAwMF0gTWVtb3J5OiA5MzAyMTJrLzEwNDg1NzZrIGF2YWlsYWJsZSAoOTExMWsga2VybmVs
IGNvZGUsIDQ2OGsgYWJzZW50LCAxMTc4OTZrIHJlc2VydmVkLCA2MDU2ayBkYXRhLCA2NDRr
IGluaXQpDQpbICAgIDAuMDAwMDAwXSBTTFVCOiBHZW5zbGFicz0xNSwgSFdhbGlnbj02NCwg
T3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9NiwgTm9kZXM9MQ0KWyAgICAwLjAwMDAw
MF0gSGllcmFyY2hpY2FsIFJDVSBpbXBsZW1lbnRhdGlvbi4NClsgICAgMC4wMDAwMDBdIE5S
X0lSUVM6NDM1MiBucl9pcnFzOjE1MzYgMTYNClsgICAgMC4wMDAwMDBdIHhlbjogc2NpIG92
ZXJyaWRlOiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTENClsgICAgMC4wMDAw
MDBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsg
ICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpDQpbICAgIDAu
MDAwMDAwXSB4ZW46IGFjcGkgc2NpIDkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9
MSAtPiBpcnE9MSAoZ3NpPTEpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTIgLT4g
aXJxPTIgKGdzaT0yKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0zIC0+IGlycT0z
IChnc2k9MykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3Np
PTQpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTUgLT4gaXJxPTUgKGdzaT01KQ0K
WyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT02IC0+IGlycT02IChnc2k9NikNClsgICAg
MC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpDQpbICAgIDAuMDAw
MDAwXSB4ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04KQ0KWyAgICAwLjAwMDAwMF0g
eGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA5IGZvciBnc2kgOQ0KWyAgICAwLjAw
MDAwMF0geGVuOiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkNClsgICAgMC4wMDAwMDBd
IHhlbjogLS0+IHBpcnE9MTAgLT4gaXJxPTEwIChnc2k9MTApDQpbICAgIDAuMDAwMDAwXSB4
ZW46IC0tPiBwaXJxPTExIC0+IGlycT0xMSAoZ3NpPTExKQ0KWyAgICAwLjAwMDAwMF0geGVu
OiAtLT4gcGlycT0xMiAtPiBpcnE9MTIgKGdzaT0xMikNClsgICAgMC4wMDAwMDBdIHhlbjog
LS0+IHBpcnE9MTMgLT4gaXJxPTEzIChnc2k9MTMpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0t
PiBwaXJxPTE0IC0+IGlycT0xNCAoZ3NpPTE0KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4g
cGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkNClsgICAgMC4wMDAwMDBdIENvbnNvbGU6IGNv
bG91ciBkdW1teSBkZXZpY2UgODB4MjUNClsgICAgMC4wMDAwMDBdIGNvbnNvbGUgW3R0eTBd
IGVuYWJsZWQsIGJvb3Rjb25zb2xlIGRpc2FibGVkDQpbICAgIDAuMDAwMDAwXSBjb25zb2xl
IFtodmMwXSBlbmFibGVkDQpbICAgIDAuMDAwMDAwXSBMb2NrIGRlcGVuZGVuY3kgdmFsaWRh
dG9yOiBDb3B5cmlnaHQgKGMpIDIwMDYgUmVkIEhhdCwgSW5jLiwgSW5nbyBNb2xuYXINClsg
ICAgMC4wMDAwMDBdIC4uLiBNQVhfTE9DS0RFUF9TVUJDTEFTU0VTOiAgOA0KWyAgICAwLjAw
MDAwMF0gLi4uIE1BWF9MT0NLX0RFUFRIOiAgICAgICAgICA0OA0KWyAgICAwLjAwMDAwMF0g
Li4uIE1BWF9MT0NLREVQX0tFWVM6ICAgICAgICA4MTkxDQpbICAgIDAuMDAwMDAwXSAuLi4g
Q0xBU1NIQVNIX1NJWkU6ICAgICAgICAgIDQwOTYNClsgICAgMC4wMDAwMDBdIC4uLiBNQVhf
TE9DS0RFUF9FTlRSSUVTOiAgICAgMTYzODQNClsgICAgMC4wMDAwMDBdIC4uLiBNQVhfTE9D
S0RFUF9DSEFJTlM6ICAgICAgMzI3NjgNClsgICAgMC4wMDAwMDBdIC4uLiBDSEFJTkhBU0hf
U0laRTogICAgICAgICAgMTYzODQNClsgICAgMC4wMDAwMDBdICBtZW1vcnkgdXNlZCBieSBs
b2NrIGRlcGVuZGVuY3kgaW5mbzogNTgyMyBrQg0KWyAgICAwLjAwMDAwMF0gIHBlciB0YXNr
LXN0cnVjdCBtZW1vcnkgZm9vdHByaW50OiAxOTIwIGJ5dGVzDQpbICAgIDAuMDAwMDAwXSBY
ZW46IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UNClsgICAgMC4wMDAwMDBdIGluc3Rh
bGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMA0KWyAgICAwLjAwMDAwMF0gRGV0ZWN0ZWQgMzIw
MC4xNjAgTUh6IHByb2Nlc3Nvci4NClsgICAgMC4wMDA5OTldIENhbGlicmF0aW5nIGRlbGF5
IGxvb3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5j
eS4uIDY0MDAuMzIgQm9nb01JUFMgKGxwaj0zMjAwMTYwKQ0KWyAgICAwLjAwMDk5OV0gcGlk
X21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxDQpbICAgIDAuMDAwOTk5XSBTZWN1
cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQNClsgICAgMC4wMDA5OTldIFNFTGludXg6ICBJ
bml0aWFsaXppbmcuDQpbICAgIDAuMDAwOTk5XSBTRUxpbnV4OiAgU3RhcnRpbmcgaW4gcGVy
bWlzc2l2ZSBtb2RlDQpbICAgIDAuMDAwOTk5XSBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBl
bnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA4LCAxMDQ4NTc2IGJ5dGVzKQ0KWyAgICAwLjAwMDk5
OV0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUy
NDI4OCBieXRlcykNClsgICAgMC4wMDA5OTldIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50
cmllczogMjU2DQpbICAgIDAuMDAxMzc4XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBj
cHVhY2N0DQpbICAgIDAuMDAxMzg0XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVl
emVyDQpbICAgIDAuMDAxNDQ1XSB0c2VnOiAwMDAwMDAwMDAwDQpbICAgIDAuMDAxNDY2XSBD
UFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMA0KWyAgICAwLjAwMTQ3MF0gQ1BVOiBQcm9j
ZXNzb3IgQ29yZSBJRDogMA0KWyAgICAwLjAwMjI3MV0gQUNQSTogQ29yZSByZXZpc2lvbiAy
MDExMDYyMw0KWyAgICAwLjAxMzEzMl0gY3B1IDAgc3BpbmxvY2sgZXZlbnQgaXJxIDI5Nw0K
WyAgICAwLjAxMzI1OF0gUGVyZm9ybWFuY2UgRXZlbnRzOiBCcm9rZW4gUE1VIGhhcmR3YXJl
IGRldGVjdGVkLCB1c2luZyBzb2Z0d2FyZSBldmVudHMgb25seS4NClsgICAgMC4wMTM1MDFd
IE1DRTogSW4ta2VybmVsIE1DRSBkZWNvZGluZyBlbmFibGVkLg0KWyAgICAwLjAxMzUxNV0g
Tk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHUwKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBlbmFi
bGVkDQpbICAgIDAuMDEzNjg0XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDENClsg
ICAgMC4wMTM3MDRdIGNwdSAxIHNwaW5sb2NrIGV2ZW50IGlycSAzMDMNClsgICAgMC4wMTM3
MjldIGxvY2tkZXA6IGZpeGluZyB1cCBhbHRlcm5hdGl2ZXMuDQpbICAgIDAuMDEzODU0XSBO
TUkgd2F0Y2hkb2cgZGlzYWJsZWQgKGNwdTEpOiBoYXJkd2FyZSBldmVudHMgbm90IGVuYWJs
ZWQNClsgICAgMC4wMTM5OThdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMg0KWyAg
ICAwLjAxMzk5OF0gY3B1IDIgc3BpbmxvY2sgZXZlbnQgaXJxIDMwOQ0KWyAgICAwLjAxNDA5
OF0gTk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHUyKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBl
bmFibGVkDQpbICAgIDAuMDE0MjY4XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMN
ClsgICAgMC4wMTQyODddIGNwdSAzIHNwaW5sb2NrIGV2ZW50IGlycSAzMTUNClsgICAgMC4w
MTQ0MDhdIE5NSSB3YXRjaGRvZyBkaXNhYmxlZCAoY3B1Myk6IGhhcmR3YXJlIGV2ZW50cyBu
b3QgZW5hYmxlZA0KWyAgICAwLjAxNDU2MF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQ
VSA0DQpbICAgIDAuMDE0NTgxXSBjcHUgNCBzcGlubG9jayBldmVudCBpcnEgMzIxDQpbICAg
IDAuMDE0NzAyXSBOTUkgd2F0Y2hkb2cgZGlzYWJsZWQgKGNwdTQpOiBoYXJkd2FyZSBldmVu
dHMgbm90IGVuYWJsZWQNClsgICAgMC4wMTQ4NTddIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZv
ciBDUFUgNQ0KWyAgICAwLjAxNDg3Nl0gY3B1IDUgc3BpbmxvY2sgZXZlbnQgaXJxIDMyNw0K
WyAgICAwLjAxNTA2N10gTk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHU1KTogaGFyZHdhcmUg
ZXZlbnRzIG5vdCBlbmFibGVkDQpbICAgIDAuMDE1MTIwXSBCcm91Z2h0IHVwIDYgQ1BVcw0K
WyAgICAwLjAxNjU2MV0gR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMiBsYXlvdXQuDQpb
ICAgIDAuMDE2NTYxXSBHcmFudCB0YWJsZSBpbml0aWFsaXplZA0KWyAgICAwLjAxNjU2MV0g
UlRDIHRpbWU6IDEyOjI1OjEyLCBkYXRlOiAwMS8xMi8xMg0KWyAgICAwLjAxNjU2MV0gTkVU
OiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNg0KWyAgICAwLjAxODEzOV0gbm9kZSAw
IGxpbmsgMDogaW8gcG9ydCBbMTAwMCwgZmZmZmZmXQ0KWyAgICAwLjAxODEzOV0gVE9NOiAw
MDAwMDAwMGIwMDAwMDAwIGFrYSAyODE2TQ0KWyAgICAwLjAxODEzOV0gRmFtIDEwaCBtbWNv
bmYgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdDQpbICAgIDAuMDE4MTM5XSBub2RlIDAg
bGluayAwOiBtbWlvIFtlMDAwMDAwMCwgZWZmZmZmZmZdID09PiBub25lDQpbICAgIDAuMDE4
MTM5XSBub2RlIDAgbGluayAwOiBtbWlvIFtmMDAwMDAwMCwgZmZmZmZmZmZdDQpbICAgIDAu
MDE4MTM5XSBub2RlIDAgbGluayAwOiBtbWlvIFthMDAwMCwgYmZmZmZdDQpbICAgIDAuMDE4
MTM5XSBub2RlIDAgbGluayAwOiBtbWlvIFtiMDAwMDAwMCwgZGZmZmZmZmZdDQpbICAgIDAu
MDE4MTM5XSBUT00yOiAwMDAwMDAwMjUwMDAwMDAwIGFrYSA5NDcyTQ0KWyAgICAwLjAxODEz
OV0gYnVzOiBbMDAsIDA3XSBvbiBub2RlIDAgbGluayAwDQpbICAgIDAuMDE4MTM5XSBidXM6
IDAwIGluZGV4IDAgW2lvICAweDAwMDAtMHhmZmZmXQ0KWyAgICAwLjAxODEzOV0gYnVzOiAw
MCBpbmRleCAxIFttZW0gMHhmMDAwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjAxODEzOV0g
YnVzOiAwMCBpbmRleCAyIFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0KWyAgICAwLjAx
ODEzOV0gYnVzOiAwMCBpbmRleCAzIFttZW0gMHhiMDAwMDAwMC0weGRmZmZmZmZmXQ0KWyAg
ICAwLjAxODEzOV0gYnVzOiAwMCBpbmRleCA0IFttZW0gMHgyNTAwMDAwMDAtMHhmY2ZmZmZm
ZmZmXQ0KWyAgICAwLjAxODMwOV0gQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVyZWQNClsg
ICAgMC4wMTgzODFdIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZd
IGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQ0KWyAg
ICAwLjAxODM4MV0gUENJOiBub3QgdXNpbmcgTU1DT05GSUcNClsgICAgMC4wMTgzODFdIFBD
STogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNzDQpbICAgIDAu
MDE4MzgxXSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBleHRlbmRlZCBh
Y2Nlc3MNClsgICAgMC4wNjgxMDJdIGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwDQpb
ICAgIDAuMDY4MTE5XSBBQ1BJOiBBZGRlZCBfT1NJKE1vZHVsZSBEZXZpY2UpDQpbICAgIDAu
MDY4MTE5XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBEZXZpY2UpDQpbICAgIDAuMDY4
MTE5XSBBQ1BJOiBBZGRlZCBfT1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMpDQpbICAgIDAuMDY4
MTE5XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dyZWdhdG9yIERldmljZSkNClsg
ICAgMC4wNzM1MjNdIEFDUEk6IEVDOiBMb29rIHVwIEVDIGluIERTRFQNClsgICAgMC4wNzUy
MDddIEFDUEk6IEV4ZWN1dGVkIDMgYmxvY2tzIG9mIG1vZHVsZS1sZXZlbCBleGVjdXRhYmxl
IEFNTCBjb2RlDQpbICAgIDAuMDg4OTYwXSBBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkDQpb
ICAgIDAuMDg4OTY3XSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzUpDQpbICAgIDAuMDg4OTkyXSBB
Q1BJOiBVc2luZyBJT0FQSUMgZm9yIGludGVycnVwdCByb3V0aW5nDQpbICAgIDAuMDg4OTky
XSBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBhdCBbbWVtIDB4
ZTAwMDAwMDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkNClsgICAgMC4wOTE3ODBd
IFBDSTogTU1DT05GSUcgYXQgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIHJlc2VydmVk
IGluIEFDUEkgbW90aGVyYm9hcmQgcmVzb3VyY2VzDQpbICAgIDAuMTg1NTA0XSBBQ1BJOiBO
byBkb2NrIGRldmljZXMgZm91bmQuDQpbICAgIDAuMTg1NTEyXSBQQ0k6IFVzaW5nIGhvc3Qg
YnJpZGdlIHdpbmRvd3MgZnJvbSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPW5vY3Jz
IiBhbmQgcmVwb3J0IGEgYnVnDQpbICAgIDAuMTg2MzA3XSBBQ1BJOiBQQ0kgUm9vdCBCcmlk
Z2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkNClsgICAgMC4xODY2MzNdIHBj
aV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0weDBj
ZjddDQpbICAgIDAuMTg2NjQwXSBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3
aW5kb3cgW2lvICAweDBkMDAtMHhmZmZmXQ0KWyAgICAwLjE4NjY0Nl0gcGNpX3Jvb3QgUE5Q
MEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZm
XQ0KWyAgICAwLjE4NjY1Ml0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2lu
ZG93IFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmXQ0KWyAgICAwLjE4NjY1OV0gcGNpX3Jv
b3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhiMDAwMDAwMC0weGRm
ZmZmZmZmXQ0KWyAgICAwLjE4NjY3Ml0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlk
Z2Ugd2luZG93IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQ0KWyAgICAwLjE4NjgwOF0g
UENJIGhvc3QgYnJpZGdlIHRvIGJ1cyAwMDAwOjAwDQpbICAgIDAuMTg2ODA4XSBwY2lfYnVz
IDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFtpbyAgMHgwMDAwLTB4MGNmN10NClsgICAg
MC4xODY4MDhdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBk
MDAtMHhmZmZmXQ0KWyAgICAwLjE4NjgwOF0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyBy
ZXNvdXJjZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0NClsgICAgMC4xODY4MDhdIHBj
aV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweDAwMGQwMDAwLTB4MDAw
ZGZmZmZdDQpbICAgIDAuMTg2ODA4XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291
cmNlIFttZW0gMHhiMDAwMDAwMC0weGRmZmZmZmZmXQ0KWyAgICAwLjE4NjgwOF0gcGNpX2J1
cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4ZjAwMDAwMDAtMHhmZWJmZmZm
Zl0NClsgICAgMC4xODY4MDhdIHBjaSAwMDAwOjAwOjAwLjA6IFsxMDAyOjVhMTFdIHR5cGUg
MCBjbGFzcyAweDAwMDYwMA0KWyAgICAwLjE4NjgwOF0gcGNpIDAwMDA6MDA6MDAuMjogWzEw
MDI6NWEyM10gdHlwZSAwIGNsYXNzIDB4MDAwODA2DQpbICAgIDAuMTg3MDAwXSBwY2kgMDAw
MDowMDowMi4wOiBbMTAwMjo1YTE2XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsgICAgMC4x
ODcxMjddIHBjaSAwMDAwOjAwOjAyLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkDQpbICAgIDAuMTg3MTc2XSBwY2kgMDAwMDowMDowMy4wOiBbMTAwMjo1YTE3XSB0
eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsgICAgMC4xODczMjJdIHBjaSAwMDAwOjAwOjAzLjA6
IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQpbICAgIDAuMTg3MzY4XSBw
Y2kgMDAwMDowMDowNS4wOiBbMTAwMjo1YTE5XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsg
ICAgMC4xODc0OTNdIHBjaSAwMDAwOjAwOjA1LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAg
RDNob3QgRDNjb2xkDQpbICAgIDAuMTg3NTM2XSBwY2kgMDAwMDowMDowNi4wOiBbMTAwMjo1
YTFhXSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsgICAgMC4xODc2NjFdIHBjaSAwMDAwOjAw
OjA2LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQpbICAgIDAuMTg3
NzEzXSBwY2kgMDAwMDowMDowYS4wOiBbMTAwMjo1YTFkXSB0eXBlIDEgY2xhc3MgMHgwMDA2
MDQNClsgICAgMC4xODc4NDFdIHBjaSAwMDAwOjAwOjBhLjA6IFBNRSMgc3VwcG9ydGVkIGZy
b20gRDAgRDNob3QgRDNjb2xkDQpbICAgIDAuMTg3ODg0XSBwY2kgMDAwMDowMDowYi4wOiBb
MTAwMjo1YTFmXSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsgICAgMC4xODc5ODBdIHBjaSAw
MDAwOjAwOjBiLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQpbICAg
IDAuMTg3OTgwXSBwY2kgMDAwMDowMDowZC4wOiBbMTAwMjo1YTFlXSB0eXBlIDEgY2xhc3Mg
MHgwMDA2MDQNClsgICAgMC4xODc5ODBdIHBjaSAwMDAwOjAwOjBkLjA6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQpbICAgIDAuMTg3OTgwXSBwY2kgMDAwMDowMDox
MS4wOiBbMTAwMjo0MzkxXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDYNClsgICAgMC4xODc5ODBd
IHBjaSAwMDAwOjAwOjExLjA6IHJlZyAxMDogW2lvICAweDcwMDAtMHg3MDA3XQ0KWyAgICAw
LjE4Nzk4MF0gcGNpIDAwMDA6MDA6MTEuMDogcmVnIDE0OiBbaW8gIDB4NjAwMC0weDYwMDNd
DQpbICAgIDAuMTg3OTgwXSBwY2kgMDAwMDowMDoxMS4wOiByZWcgMTg6IFtpbyAgMHg1MDAw
LTB4NTAwN10NClsgICAgMC4xODc5ODBdIHBjaSAwMDAwOjAwOjExLjA6IHJlZyAxYzogW2lv
ICAweDMwMDAtMHgzMDAzXQ0KWyAgICAwLjE4Nzk4MF0gcGNpIDAwMDA6MDA6MTEuMDogcmVn
IDIwOiBbaW8gIDB4MjAwMC0weDIwMGZdDQpbICAgIDAuMTg3OTgwXSBwY2kgMDAwMDowMDox
MS4wOiByZWcgMjQ6IFttZW0gMHhmOThmZjAwMC0weGY5OGZmM2ZmXQ0KWyAgICAwLjE4Nzk5
Nl0gcGNpIDAwMDA6MDA6MTIuMDogWzEwMDI6NDM5N10gdHlwZSAwIGNsYXNzIDB4MDAwYzAz
DQpbICAgIDAuMTg4MDI3XSBwY2kgMDAwMDowMDoxMi4wOiByZWcgMTA6IFttZW0gMHhmOThm
YjAwMC0weGY5OGZiZmZmXQ0KWyAgICAwLjE4ODE3OV0gcGNpIDAwMDA6MDA6MTIuMjogWzEw
MDI6NDM5Nl0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzDQpbICAgIDAuMTg4MjExXSBwY2kgMDAw
MDowMDoxMi4yOiByZWcgMTA6IFttZW0gMHhmOThmZjQwMC0weGY5OGZmNGZmXQ0KWyAgICAw
LjE4ODM1NF0gcGNpIDAwMDA6MDA6MTIuMjogc3VwcG9ydHMgRDEgRDINClsgICAgMC4xODgz
NjVdIHBjaSAwMDAwOjAwOjEyLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNo
b3QNClsgICAgMC4xODg0MDZdIHBjaSAwMDAwOjAwOjEzLjA6IFsxMDAyOjQzOTddIHR5cGUg
MCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE4ODQyOV0gcGNpIDAwMDA6MDA6MTMuMDogcmVn
IDEwOiBbbWVtIDB4Zjk4ZmMwMDAtMHhmOThmY2ZmZl0NClsgICAgMC4xODg1NjJdIHBjaSAw
MDAwOjAwOjEzLjI6IFsxMDAyOjQzOTZdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAw
LjE4ODU5NF0gcGNpIDAwMDA6MDA6MTMuMjogcmVnIDEwOiBbbWVtIDB4Zjk4ZmY4MDAtMHhm
OThmZjhmZl0NClsgICAgMC4xODg3NDRdIHBjaSAwMDAwOjAwOjEzLjI6IHN1cHBvcnRzIEQx
IEQyDQpbICAgIDAuMTg4NzQ4XSBwY2kgMDAwMDowMDoxMy4yOiBQTUUjIHN1cHBvcnRlZCBm
cm9tIEQwIEQxIEQyIEQzaG90DQpbICAgIDAuMTg4Nzg3XSBwY2kgMDAwMDowMDoxNC4wOiBb
MTAwMjo0Mzg1XSB0eXBlIDAgY2xhc3MgMHgwMDBjMDUNClsgICAgMC4xODg5MjddIHBjaSAw
MDAwOjAwOjE0LjM6IFsxMDAyOjQzOWRdIHR5cGUgMCBjbGFzcyAweDAwMDYwMQ0KWyAgICAw
LjE4ODk4MF0gcGNpIDAwMDA6MDA6MTQuNDogWzEwMDI6NDM4NF0gdHlwZSAxIGNsYXNzIDB4
MDAwNjA0DQpbICAgIDAuMTg4OTgwXSBwY2kgMDAwMDowMDoxNC41OiBbMTAwMjo0Mzk5XSB0
eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4xODg5ODBdIHBjaSAwMDAwOjAwOjE0LjU6
IHJlZyAxMDogW21lbSAweGY5OGZkMDAwLTB4Zjk4ZmRmZmZdDQpbICAgIDAuMTg5MDAyXSBw
Y2kgMDAwMDowMDoxNS4wOiBbMTAwMjo0M2EwXSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsg
ICAgMC4xODkxNTNdIHBjaSAwMDAwOjAwOjE1LjA6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAu
MTg5MjM3XSBwY2kgMDAwMDowMDoxNi4wOiBbMTAwMjo0Mzk3XSB0eXBlIDAgY2xhc3MgMHgw
MDBjMDMNClsgICAgMC4xODkyNjBdIHBjaSAwMDAwOjAwOjE2LjA6IHJlZyAxMDogW21lbSAw
eGY5OGZlMDAwLTB4Zjk4ZmVmZmZdDQpbICAgIDAuMTg5Mzg1XSBwY2kgMDAwMDowMDoxNi4y
OiBbMTAwMjo0Mzk2XSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4xODk0MTddIHBj
aSAwMDAwOjAwOjE2LjI6IHJlZyAxMDogW21lbSAweGY5OGZmYzAwLTB4Zjk4ZmZjZmZdDQpb
ICAgIDAuMTg5NTY3XSBwY2kgMDAwMDowMDoxNi4yOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAw
LjE4OTU3MV0gcGNpIDAwMDA6MDA6MTYuMjogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBE
MiBEM2hvdA0KWyAgICAwLjE4OTYxNF0gcGNpIDAwMDA6MDA6MTguMDogWzEwMjI6MTIwMF0g
dHlwZSAwIGNsYXNzIDB4MDAwNjAwDQpbICAgIDAuMTg5NzAwXSBwY2kgMDAwMDowMDoxOC4x
OiBbMTAyMjoxMjAxXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDANClsgICAgMC4xODk3NjVdIHBj
aSAwMDAwOjAwOjE4LjI6IFsxMDIyOjEyMDJdIHR5cGUgMCBjbGFzcyAweDAwMDYwMA0KWyAg
ICAwLjE4OTgzNF0gcGNpIDAwMDA6MDA6MTguMzogWzEwMjI6MTIwM10gdHlwZSAwIGNsYXNz
IDB4MDAwNjAwDQpbICAgIDAuMTg5OTIwXSBwY2kgMDAwMDowMDoxOC40OiBbMTAyMjoxMjA0
XSB0eXBlIDAgY2xhc3MgMHgwMDA2MDANClsgICAgMC4xOTAwMDRdIHBjaSAwMDAwOjBiOjAw
LjA6IFsxMGRlOjA2ZTRdIHR5cGUgMCBjbGFzcyAweDAwMDMwMA0KWyAgICAwLjE5MDAyNl0g
cGNpIDAwMDA6MGI6MDAuMDogcmVnIDEwOiBbbWVtIDB4ZmQwMDAwMDAtMHhmZGZmZmZmZl0N
ClsgICAgMC4xOTAwNTBdIHBjaSAwMDAwOjBiOjAwLjA6IHJlZyAxNDogW21lbSAweGQwMDAw
MDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4xOTAwODJdIHBjaSAwMDAwOjBi
OjAwLjA6IHJlZyAxYzogW21lbSAweGZhMDAwMDAwLTB4ZmJmZmZmZmYgNjRiaXRdDQpbICAg
IDAuMTkwMDk5XSBwY2kgMDAwMDowYjowMC4wOiByZWcgMjQ6IFtpbyAgMHhlODAwLTB4ZTg3
Zl0NClsgICAgMC4xOTAxMTZdIHBjaSAwMDAwOjBiOjAwLjA6IHJlZyAzMDogW21lbSAweGZl
OWUwMDAwLTB4ZmU5ZmZmZmYgcHJlZl0NClsgICAgMC4xOTIwMTldIHBjaSAwMDAwOjAwOjAy
LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwYi0wYl0NClsgICAgMC4xOTIwMzJdIHBjaSAwMDAw
OjAwOjAyLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZTAwMC0weGVmZmZdDQpbICAgIDAu
MTkyMDQwXSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZhMDAw
MDAwLTB4ZmU5ZmZmZmZdDQpbICAgIDAuMTkyMDU3XSBwY2kgMDAwMDowMDowMi4wOiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJlZl0NClsg
ICAgMC4xOTIxNjZdIHBjaSAwMDAwOjBhOjAwLjA6IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFz
cyAweDAwMGMwMw0KWyAgICAwLjE5MjE5NF0gcGNpIDAwMDA6MGE6MDAuMDogcmVnIDEwOiBb
bWVtIDB4ZjlmZjgwMDAtMHhmOWZmOGZmZl0NClsgICAgMC4xOTI0MDRdIHBjaSAwMDAwOjBh
OjAwLjA6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMTkyNDA4XSBwY2kgMDAwMDowYTowMC4w
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQpbICAgIDAuMTkyNDcxXSBw
Y2kgMDAwMDowYTowMC4xOiBbOTcxMDo5OTkwXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsg
ICAgMC4xOTI1MDRdIHBjaSAwMDAwOjBhOjAwLjE6IHJlZyAxMDogW21lbSAweGY5ZmY5MDAw
LTB4ZjlmZjlmZmZdDQpbICAgIDAuMTkyNzAxXSBwY2kgMDAwMDowYTowMC4xOiBzdXBwb3J0
cyBEMSBEMg0KWyAgICAwLjE5MjcwNV0gcGNpIDAwMDA6MGE6MDAuMTogUE1FIyBzdXBwb3J0
ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KWyAgICAwLjE5Mjc3NF0gcGNpIDAwMDA6MGE6MDAu
MjogWzk3MTA6OTk5MF0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzDQpbICAgIDAuMTkyODAxXSBw
Y2kgMDAwMDowYTowMC4yOiByZWcgMTA6IFttZW0gMHhmOWZmYTAwMC0weGY5ZmZhZmZmXQ0K
WyAgICAwLjE5Mjk3OV0gcGNpIDAwMDA6MGE6MDAuMjogc3VwcG9ydHMgRDEgRDINClsgICAg
MC4xOTI5NzldIHBjaSAwMDAwOjBhOjAwLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEg
RDIgRDNob3QNClsgICAgMC4xOTI5NzldIHBjaSAwMDAwOjBhOjAwLjM6IFs5NzEwOjk5OTBd
IHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE5Mjk3OV0gcGNpIDAwMDA6MGE6MDAu
MzogcmVnIDEwOiBbbWVtIDB4ZjlmZmIwMDAtMHhmOWZmYmZmZl0NClsgICAgMC4xOTI5Nzld
IHBjaSAwMDAwOjBhOjAwLjM6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMTkyOTc5XSBwY2kg
MDAwMDowYTowMC4zOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQpbICAg
IDAuMTkzMDM4XSBwY2kgMDAwMDowYTowMC40OiBbOTcxMDo5OTkwXSB0eXBlIDAgY2xhc3Mg
MHgwMDBjMDMNClsgICAgMC4xOTMwNzRdIHBjaSAwMDAwOjBhOjAwLjQ6IHJlZyAxMDogW21l
bSAweGY5ZmZjMDAwLTB4ZjlmZmNmZmZdDQpbICAgIDAuMTkzMjg2XSBwY2kgMDAwMDowYTow
MC40OiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjE5MzI5MF0gcGNpIDAwMDA6MGE6MDAuNDog
UE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KWyAgICAwLjE5MzM1N10gcGNp
IDAwMDA6MGE6MDAuNTogWzk3MTA6OTk5MF0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzDQpbICAg
IDAuMTkzMzg0XSBwY2kgMDAwMDowYTowMC41OiByZWcgMTA6IFttZW0gMHhmOWZmZDAwMC0w
eGY5ZmZkZmZmXQ0KWyAgICAwLjE5MzU4OF0gcGNpIDAwMDA6MGE6MDAuNTogc3VwcG9ydHMg
RDEgRDINClsgICAgMC4xOTM1OTJdIHBjaSAwMDAwOjBhOjAwLjU6IFBNRSMgc3VwcG9ydGVk
IGZyb20gRDAgRDEgRDIgRDNob3QNClsgICAgMC4xOTM2NTNdIHBjaSAwMDAwOjBhOjAwLjY6
IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE5MzY4N10gcGNp
IDAwMDA6MGE6MDAuNjogcmVnIDEwOiBbbWVtIDB4ZjlmZmUwMDAtMHhmOWZmZWZmZl0NClsg
ICAgMC4xOTM4ODNdIHBjaSAwMDAwOjBhOjAwLjY6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAu
MTkzODg3XSBwY2kgMDAwMDowYTowMC42OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQy
IEQzaG90DQpbICAgIDAuMTkzOTU4XSBwY2kgMDAwMDowYTowMC43OiBbOTcxMDo5OTkwXSB0
eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4xOTM5NzldIHBjaSAwMDAwOjBhOjAwLjc6
IHJlZyAxMDogW21lbSAweGY5ZmZmMDAwLTB4ZjlmZmZmZmZdDQpbICAgIDAuMTkzOTc5XSBw
Y2kgMDAwMDowYTowMC43OiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjE5Mzk3OV0gcGNpIDAw
MDA6MGE6MDAuNzogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KWyAgICAw
LjE5NTA1OF0gcGNpIDAwMDA6MDA6MDMuMDogUENJIGJyaWRnZSB0byBbYnVzIDBhLTBhXQ0K
WyAgICAwLjE5NTA3MV0gcGNpIDAwMDA6MDA6MDMuMDogICBicmlkZ2Ugd2luZG93IFttZW0g
MHhmOWYwMDAwMC0weGY5ZmZmZmZmXQ0KWyAgICAwLjE5NTIwNV0gcGNpIDAwMDA6MDk6MDAu
MDogWzEwZWM6ODE2OF0gdHlwZSAwIGNsYXNzIDB4MDAwMjAwDQpbICAgIDAuMTk1MjI5XSBw
Y2kgMDAwMDowOTowMC4wOiByZWcgMTA6IFtpbyAgMHhkODAwLTB4ZDhmZl0NClsgICAgMC4x
OTUyNzddIHBjaSAwMDAwOjA5OjAwLjA6IHJlZyAxODogW21lbSAweGNmZmZmMDAwLTB4Y2Zm
ZmZmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4xOTUzMDRdIHBjaSAwMDAwOjA5OjAwLjA6IHJl
ZyAyMDogW21lbSAweGNmZmY4MDAwLTB4Y2ZmZmJmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4x
OTUzMjRdIHBjaSAwMDAwOjA5OjAwLjA6IHJlZyAzMDogW21lbSAweGY5ZWUwMDAwLTB4Zjll
ZmZmZmYgcHJlZl0NClsgICAgMC4xOTU0MzBdIHBjaSAwMDAwOjA5OjAwLjA6IHN1cHBvcnRz
IEQxIEQyDQpbICAgIDAuMTk1NDM0XSBwY2kgMDAwMDowOTowMC4wOiBQTUUjIHN1cHBvcnRl
ZCBmcm9tIEQwIEQxIEQyIEQzaG90IEQzY29sZA0KWyAgICAwLjE5NzAxOF0gcGNpIDAwMDA6
MDA6MDUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA5LTA5XQ0KWyAgICAwLjE5NzAzMF0gcGNp
IDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0NClsg
ICAgMC4xOTcwMzhdIHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4
ZjllMDAwMDAtMHhmOWVmZmZmZl0NClsgICAgMC4xOTcwNDldIHBjaSAwMDAwOjAwOjA1LjA6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4Y2ZmMDAwMDAtMHhjZmZmZmZmZiA2NGJpdCBwcmVm
XQ0KWyAgICAwLjE5NzE1MV0gcGNpIDAwMDA6MDg6MDAuMDogWzEwZWM6ODE2OF0gdHlwZSAw
IGNsYXNzIDB4MDAwMjAwDQpbICAgIDAuMTk3MTgyXSBwY2kgMDAwMDowODowMC4wOiByZWcg
MTA6IFtpbyAgMHhjODAwLTB4YzhmZl0NClsgICAgMC4xOTcyMjJdIHBjaSAwMDAwOjA4OjAw
LjA6IHJlZyAxODogW21lbSAweGNmZWZmMDAwLTB4Y2ZlZmZmZmYgNjRiaXQgcHJlZl0NClsg
ICAgMC4xOTcyNDldIHBjaSAwMDAwOjA4OjAwLjA6IHJlZyAyMDogW21lbSAweGNmZWY4MDAw
LTB4Y2ZlZmJmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4xOTcyNzVdIHBjaSAwMDAwOjA4OjAw
LjA6IHJlZyAzMDogW21lbSAweGY5ZGUwMDAwLTB4ZjlkZmZmZmYgcHJlZl0NClsgICAgMC4x
OTczNzVdIHBjaSAwMDAwOjA4OjAwLjA6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMTk3Mzc5
XSBwY2kgMDAwMDowODowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90
IEQzY29sZA0KWyAgICAwLjE5OTAwMl0gcGNpIDAwMDA6MDA6MDYuMDogUENJIGJyaWRnZSB0
byBbYnVzIDA4LTA4XQ0KWyAgICAwLjE5OTAxMl0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlk
Z2Ugd2luZG93IFtpbyAgMHhjMDAwLTB4Y2ZmZl0NClsgICAgMC4xOTkwMjBdIHBjaSAwMDAw
OjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjlkMDAwMDAtMHhmOWRmZmZmZl0N
ClsgICAgMC4xOTkwMzBdIHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IDB4Y2ZlMDAwMDAtMHhjZmVmZmZmZiA2NGJpdCBwcmVmXQ0KWyAgICAwLjE5OTE0MF0gcGNp
IDAwMDA6MDY6MDAuMDogWzEwNGM6ODIzMV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0DQpbICAg
IDAuMTk5MzM1XSBwY2kgMDAwMDowNjowMC4wOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjE5
OTM3N10gcGNpIDAwMDA6MDY6MDAuMDogZGlzYWJsaW5nIEFTUE0gb24gcHJlLTEuMSBQQ0ll
IGRldmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0IHdpdGggJ3BjaWVfYXNwbT1mb3JjZScNClsg
ICAgMC4xOTkzOTZdIHBjaSAwMDAwOjAwOjBhLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNi0w
N10NClsgICAgMC4xOTk0MTBdIHBjaSAwMDAwOjAwOjBhLjA6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIDB4ZjljMDAwMDAtMHhmOWNmZmZmZl0NClsgICAgMC4xOTk1NjFdIHBjaSAwMDAwOjA3
OjAxLjA6IFsxMDMzOjAwMzVdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE5OTYw
MF0gcGNpIDAwMDA6MDc6MDEuMDogcmVnIDEwOiBbbWVtIDB4ZjljZmQwMDAtMHhmOWNmZGZm
Zl0NClsgICAgMC4xOTk3MzVdIHBjaSAwMDAwOjA3OjAxLjA6IERpc2FibGluZyBtZW1vcnkg
ZGVjb2RpbmcgYW5kIHJlbGVhc2luZyBtZW1vcnkgcmVzb3VyY2VzLg0KWyAgICAwLjE5OTgw
M10gcGNpIDAwMDA6MDc6MDEuMDogc3VwcG9ydHMgRDEgRDINClsgICAgMC4xOTk4MDddIHBj
aSAwMDAwOjA3OjAxLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNClsg
ICAgMC4xOTk4NjRdIHBjaSAwMDAwOjA3OjAxLjE6IFsxMDMzOjAwMzVdIHR5cGUgMCBjbGFz
cyAweDAwMGMwMw0KWyAgICAwLjE5OTkxMF0gcGNpIDAwMDA6MDc6MDEuMTogcmVnIDEwOiBb
bWVtIDB4ZjljZmUwMDAtMHhmOWNmZWZmZl0NClsgICAgMC4xOTk5NzhdIHBjaSAwMDAwOjA3
OjAxLjE6IERpc2FibGluZyBtZW1vcnkgZGVjb2RpbmcgYW5kIHJlbGVhc2luZyBtZW1vcnkg
cmVzb3VyY2VzLg0KWyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDc6MDEuMTogc3VwcG9ydHMg
RDEgRDINClsgICAgMC4xOTk5NzhdIHBjaSAwMDAwOjA3OjAxLjE6IFBNRSMgc3VwcG9ydGVk
IGZyb20gRDAgRDEgRDIgRDNob3QNClsgICAgMC4xOTk5NzhdIHBjaSAwMDAwOjA3OjAxLjI6
IFsxMDMzOjAwZTBdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE5OTk3OF0gcGNp
IDAwMDA6MDc6MDEuMjogcmVnIDEwOiBbbWVtIDB4ZjljZmZjMDAtMHhmOWNmZmNmZl0NClsg
ICAgMC4xOTk5NzhdIHBjaSAwMDAwOjA3OjAxLjI6IERpc2FibGluZyBtZW1vcnkgZGVjb2Rp
bmcgYW5kIHJlbGVhc2luZyBtZW1vcnkgcmVzb3VyY2VzLg0KWyAgICAwLjE5OTk3OF0gcGNp
IDAwMDA6MDc6MDEuMjogUm91bmRpbmcgdXAgc2l6ZSBvZiByZXNvdXJjZSAjMCB0byAweDEw
MDAuDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAwMDowNzowMS4yOiBzdXBwb3J0cyBEMSBEMg0K
WyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDc6MDEuMjogUE1FIyBzdXBwb3J0ZWQgZnJvbSBE
MCBEMSBEMiBEM2hvdA0KWyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDY6MDAuMDogUENJIGJy
aWRnZSB0byBbYnVzIDA3LTA3XQ0KWyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDY6MDAuMDog
ICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWMwMDAwMC0weGY5Y2ZmZmZmXQ0KWyAgICAwLjE5
OTk3OF0gcGNpIDAwMDA6MDU6MDAuMDogWzEwMDI6OTVjNV0gdHlwZSAwIGNsYXNzIDB4MDAw
MzAwDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAwMDowNTowMC4wOiByZWcgMTA6IFttZW0gMHhi
MDAwMDAwMC0weGJmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAw
MDowNTowMC4wOiByZWcgMTg6IFttZW0gMHhmOWJlMDAwMC0weGY5YmVmZmZmIDY0Yml0XQ0K
WyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDU6MDAuMDogcmVnIDIwOiBbaW8gIDB4YjAwMC0w
eGIwZmZdDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAwMDowNTowMC4wOiByZWcgMzA6IFttZW0g
MHhmOWJjMDAwMC0weGY5YmRmZmZmIHByZWZdDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAwMDow
NTowMC4wOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjIwMDAxN10gcGNpIDAwMDA6MDU6MDAu
MTogWzEwMDI6YWEyOF0gdHlwZSAwIGNsYXNzIDB4MDAwNDAzDQpbICAgIDAuMjAwMDYwXSBw
Y2kgMDAwMDowNTowMC4xOiByZWcgMTA6IFttZW0gMHhmOWJmYzAwMC0weGY5YmZmZmZmIDY0
Yml0XQ0KWyAgICAwLjIwMDI0MF0gcGNpIDAwMDA6MDU6MDAuMTogc3VwcG9ydHMgRDEgRDIN
ClsgICAgMC4yMDIwMDFdIHBjaSAwMDAwOjAwOjBiLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
NS0wNV0NClsgICAgMC4yMDIwMTFdIHBjaSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRv
dyBbaW8gIDB4YjAwMC0weGJmZmZdDQpbICAgIDAuMjAyMDE4XSBwY2kgMDAwMDowMDowYi4w
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YjAwMDAwLTB4ZjliZmZmZmZdDQpbICAgIDAu
MjAyMDI5XSBwY2kgMDAwMDowMDowYi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGIwMDAw
MDAwLTB4YmZmZmZmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4yMDIxMzNdIHBjaSAwMDAwOjA0
OjAwLjA6IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjIwMjE1
OV0gcGNpIDAwMDA6MDQ6MDAuMDogcmVnIDEwOiBbbWVtIDB4ZjlhZjgwMDAtMHhmOWFmOGZm
Zl0NClsgICAgMC4yMDIzNTRdIHBjaSAwMDAwOjA0OjAwLjA6IHN1cHBvcnRzIEQxIEQyDQpb
ICAgIDAuMjAyMzU4XSBwY2kgMDAwMDowNDowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQw
IEQxIEQyIEQzaG90DQpbICAgIDAuMjAyNDI2XSBwY2kgMDAwMDowNDowMC4xOiBbOTcxMDo5
OTkwXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4yMDI0NTJdIHBjaSAwMDAwOjA0
OjAwLjE6IHJlZyAxMDogW21lbSAweGY5YWY5MDAwLTB4ZjlhZjlmZmZdDQpbICAgIDAuMjAy
NjUzXSBwY2kgMDAwMDowNDowMC4xOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjIwMjY1OF0g
cGNpIDAwMDA6MDQ6MDAuMTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0K
WyAgICAwLjIwMjcxN10gcGNpIDAwMDA6MDQ6MDAuMjogWzk3MTA6OTk5MF0gdHlwZSAwIGNs
YXNzIDB4MDAwYzAzDQpbICAgIDAuMjAyNzUwXSBwY2kgMDAwMDowNDowMC4yOiByZWcgMTA6
IFttZW0gMHhmOWFmYTAwMC0weGY5YWZhZmZmXQ0KWyAgICAwLjIwMjk0NV0gcGNpIDAwMDA6
MDQ6MDAuMjogc3VwcG9ydHMgRDEgRDINClsgICAgMC4yMDI5NDldIHBjaSAwMDAwOjA0OjAw
LjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNClsgICAgMC4yMDI5Nzhd
IHBjaSAwMDAwOjA0OjAwLjM6IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0K
WyAgICAwLjIwMjk3OF0gcGNpIDAwMDA6MDQ6MDAuMzogcmVnIDEwOiBbbWVtIDB4ZjlhZmIw
MDAtMHhmOWFmYmZmZl0NClsgICAgMC4yMDMwNTRdIHBjaSAwMDAwOjA0OjAwLjM6IHN1cHBv
cnRzIEQxIEQyDQpbICAgIDAuMjAzMDY1XSBwY2kgMDAwMDowNDowMC4zOiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQpbICAgIDAuMjAzMTI0XSBwY2kgMDAwMDowNDow
MC40OiBbOTcxMDo5OTkwXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4yMDMxODVd
IHBjaSAwMDAwOjA0OjAwLjQ6IHJlZyAxMDogW21lbSAweGY5YWZjMDAwLTB4ZjlhZmNmZmZd
DQpbICAgIDAuMjAzMzczXSBwY2kgMDAwMDowNDowMC40OiBzdXBwb3J0cyBEMSBEMg0KWyAg
ICAwLjIwMzM4MF0gcGNpIDAwMDA6MDQ6MDAuNDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE
MSBEMiBEM2hvdA0KWyAgICAwLjIwMzQ0N10gcGNpIDAwMDA6MDQ6MDAuNTogWzk3MTA6OTk5
MF0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzDQpbICAgIDAuMjAzNDc0XSBwY2kgMDAwMDowNDow
MC41OiByZWcgMTA6IFttZW0gMHhmOWFmZDAwMC0weGY5YWZkZmZmXQ0KWyAgICAwLjIwMzY3
NV0gcGNpIDAwMDA6MDQ6MDAuNTogc3VwcG9ydHMgRDEgRDINClsgICAgMC4yMDM2NzldIHBj
aSAwMDAwOjA0OjAwLjU6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNClsg
ICAgMC4yMDM3MzhdIHBjaSAwMDAwOjA0OjAwLjY6IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFz
cyAweDAwMGMwMw0KWyAgICAwLjIwMzc3MV0gcGNpIDAwMDA6MDQ6MDAuNjogcmVnIDEwOiBb
bWVtIDB4ZjlhZmUwMDAtMHhmOWFmZWZmZl0NClsgICAgMC4yMDM5NjZdIHBjaSAwMDAwOjA0
OjAwLjY6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMjAzOTcwXSBwY2kgMDAwMDowNDowMC42
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQpbICAgIDAuMjAzOTc3XSBw
Y2kgMDAwMDowNDowMC43OiBbOTcxMDo5OTkwXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsg
ICAgMC4yMDM5NzddIHBjaSAwMDAwOjA0OjAwLjc6IHJlZyAxMDogW21lbSAweGY5YWZmMDAw
LTB4ZjlhZmZmZmZdDQpbICAgIDAuMjAzOTc3XSBwY2kgMDAwMDowNDowMC43OiBzdXBwb3J0
cyBEMSBEMg0KWyAgICAwLjIwMzk3N10gcGNpIDAwMDA6MDQ6MDAuNzogUE1FIyBzdXBwb3J0
ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KWyAgICAwLjIwNTA3MF0gcGNpIDAwMDA6MDA6MGQu
MDogUENJIGJyaWRnZSB0byBbYnVzIDA0LTA0XQ0KWyAgICAwLjIwNTA4NV0gcGNpIDAwMDA6
MDA6MGQuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWEwMDAwMC0weGY5YWZmZmZmXQ0K
WyAgICAwLjIwNTE1Ml0gcGNpIDAwMDA6MDM6MDYuMDogWzEzZjY6MDExMV0gdHlwZSAwIGNs
YXNzIDB4MDAwNDAxDQpbICAgIDAuMjA1MTk0XSBwY2kgMDAwMDowMzowNi4wOiByZWcgMTA6
IFtpbyAgMHhhODAwLTB4YThmZl0NClsgICAgMC4yMDUzNTJdIHBjaSAwMDAwOjAzOjA2LjA6
IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMjA1NDMyXSBwY2kgMDAwMDowMDoxNC40OiBQQ0kg
YnJpZGdlIHRvIFtidXMgMDMtMDNdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMjA1
NDc2XSBwY2kgMDAwMDowMDoxNC40OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGEwMDAtMHhh
ZmZmXQ0KWyAgICAwLjIwNTQ4OF0gcGNpIDAwMDA6MDA6MTQuNDogICBicmlkZ2Ugd2luZG93
IFtpbyAgMHgwMDAwLTB4MGNmN10gKHN1YnRyYWN0aXZlIGRlY29kZSkNClsgICAgMC4yMDU0
OTRdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZm
ZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMjA1NTAwXSBwY2kgMDAwMDowMDox
NC40OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdIChzdWJ0
cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMjA1NTA2XSBwY2kgMDAwMDowMDoxNC40OiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZmZmZdIChzdWJ0cmFjdGl2ZSBk
ZWNvZGUpDQpbICAgIDAuMjA1NTEyXSBwY2kgMDAwMDowMDoxNC40OiAgIGJyaWRnZSB3aW5k
b3cgW21lbSAweGIwMDAwMDAwLTB4ZGZmZmZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpb
ICAgIDAuMjA1NTE4XSBwY2kgMDAwMDowMDoxNC40OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAw
eGYwMDAwMDAwLTB4ZmViZmZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMjA1
NjA0XSBwY2kgMDAwMDowMDoxNS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdDQpbICAg
IDAuMjA1Njg3XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBD
STAuX1BSVF0NClsgICAgMC4yMDU5MjZdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBU
YWJsZSBbXF9TQl8uUENJMC5QQzAyLl9QUlRdDQpbICAgIDAuMjA1OTc3XSBBQ1BJOiBQQ0kg
SW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEMwMy5fUFJUXQ0KWyAgICAw
LjIwNTk3N10gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kw
LlBDMDUuX1BSVF0NClsgICAgMC4yMDU5NzddIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGlu
ZyBUYWJsZSBbXF9TQl8uUENJMC5QQzA2Ll9QUlRdDQpbICAgIDAuMjA1OTc3XSBBQ1BJOiBQ
Q0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEMwQS5fUFJUXQ0KWyAg
ICAwLjIwNTk3N10gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5Q
Q0kwLlBDMEIuX1BSVF0NClsgICAgMC4yMDU5NzddIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91
dGluZyBUYWJsZSBbXF9TQl8uUENJMC5QQzBELl9QUlRdDQpbICAgIDAuMjA1OTc3XSBBQ1BJ
OiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUDBQQy5fUFJUXQ0K
WyAgICAwLjIwNTk4MV0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NC
Xy5QQ0kwLlBFMjAuX1BSVF0NClsgICAgMC4yMDYyNDFdICBwY2kwMDAwOjAwOiBSZXF1ZXN0
aW5nIEFDUEkgX09TQyBjb250cm9sICgweDFkKQ0KWyAgICAwLjIwNjU3MV0gIHBjaTAwMDA6
MDA6IEFDUEkgX09TQyBjb250cm9sICgweDFkKSBncmFudGVkDQpbICAgIDAuMjMzMTg2XSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUp
DQpbICAgIDAuMjM0MDAzXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFz
IDQgNyAxMCAqMTEgMTQgMTUpDQpbICAgIDAuMjM0MTY5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0
IExpbmsgW0xOS0NdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpDQpbICAgIDAuMjM0MzIxXSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0RdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUp
DQpbICAgIDAuMjM0NDU3XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIChJUlFz
IDQgKjcgMTAgMTEgMTQgMTUpDQpbICAgIDAuMjM0NTU5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0
IExpbmsgW0xOS0ZdIChJUlFzIDQgNyAxMCAqMTEgMTQgMTUpDQpbICAgIDAuMjM0NjU2XSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0ddIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUp
DQpbICAgIDAuMjM0NzU1XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJUlFz
IDQgNyAqMTAgMTEgMTQgMTUpDQpbICAgIDAuMjM1MDI1XSB4ZW4vYmFsbG9vbjogSW5pdGlh
bGlzaW5nIGJhbGxvb24gZHJpdmVyLg0KWyAgICAwLjIzNTA3NF0geGVuLWJhbGxvb246IElu
aXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4NClsgICAgMC4yMzUxNThdIHZnYWFyYjogZGV2
aWNlIGFkZGVkOiBQQ0k6MDAwMDowYjowMC4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVt
LGxvY2tzPW5vbmUNClsgICAgMC4yMzUxNThdIHZnYWFyYjogZGV2aWNlIGFkZGVkOiBQQ0k6
MDAwMDowNTowMC4wLGRlY29kZXM9aW8rbWVtLG93bnM9bm9uZSxsb2Nrcz1ub25lDQpbICAg
IDAuMjM1MTU4XSB2Z2FhcmI6IGxvYWRlZA0KWyAgICAwLjIzNTE1OF0gdmdhYXJiOiBicmlk
Z2UgY29udHJvbCBwb3NzaWJsZSAwMDAwOjA1OjAwLjANClsgICAgMC4yMzUxNThdIHZnYWFy
YjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowYjowMC4wDQpbICAgIDAuMjM2MDY2
XSBTQ1NJIHN1YnN5c3RlbSBpbml0aWFsaXplZA0KWyAgICAwLjIzNjA4Nl0gbGliYXRhIHZl
cnNpb24gMy4wMCBsb2FkZWQuDQpbICAgIDAuMjM2MDg2XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZzDQpbICAgIDAuMjM3MDMyXSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1Yg0KWyAgICAwLjIzNzA3NV0gdXNi
Y29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1c2INClsgICAgMC4yMzcxNDNd
IEFkdmFuY2VkIExpbnV4IFNvdW5kIEFyY2hpdGVjdHVyZSBEcml2ZXIgVmVyc2lvbiAxLjAu
MjQuDQpbICAgIDAuMjM3MTQzXSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nDQpb
ICAgIDAuMjQ0OTcxXSBQQ0k6IHBjaV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVz
DQpbICAgIDAuMjQ1MDM1XSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwMDAwOWIwMDAg
LSAwMDAwMDAwMDAwMDlmZmZmIA0KWyAgICAwLjI0NTE1OF0gTmV0TGFiZWw6IEluaXRpYWxp
emluZw0KWyAgICAwLjI0NTE1OF0gTmV0TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4
DQpbICAgIDAuMjQ1MTU4XSBOZXRMYWJlbDogIHByb3RvY29scyA9IFVOTEFCRUxFRCBDSVBT
T3Y0DQpbICAgIDAuMjQ1MTU4XSBOZXRMYWJlbDogIHVubGFiZWxlZCB0cmFmZmljIGFsbG93
ZWQgYnkgZGVmYXVsdA0KWyAgICAwLjI0NTMxM10gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNl
IHhlbg0KWyAgICAwLjI0NTQ0OF0gcG5wOiBQblAgQUNQSSBpbml0DQpbICAgIDAuMjQ1NDQ4
XSBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZA0KWyAgICAwLjI0NTQ5NF0gcG5wIDAw
OjAwOiBbYnVzIDAwLWZmXQ0KWyAgICAwLjI0NTQ5OV0gcG5wIDAwOjAwOiBbaW8gIDB4MGNm
OC0weDBjZmZdDQpbICAgIDAuMjQ1NTA1XSBwbnAgMDA6MDA6IFtpbyAgMHgwMDAwLTB4MGNm
NyB3aW5kb3ddDQpbICAgIDAuMjQ1NTA5XSBwbnAgMDA6MDA6IFtpbyAgMHgwZDAwLTB4ZmZm
ZiB3aW5kb3ddDQpbICAgIDAuMjQ1NTE0XSBwbnAgMDA6MDA6IFttZW0gMHgwMDBhMDAwMC0w
eDAwMGJmZmZmIHdpbmRvd10NClsgICAgMC4yNDU1MTldIHBucCAwMDowMDogW21lbSAweDAw
MGQwMDAwLTB4MDAwZGZmZmYgd2luZG93XQ0KWyAgICAwLjI0NTUyNV0gcG5wIDAwOjAwOiBb
bWVtIDB4YjAwMDAwMDAtMHhkZmZmZmZmZiB3aW5kb3ddDQpbICAgIDAuMjQ1NTMwXSBwbnAg
MDA6MDA6IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmIHdpbmRvd10NClsgICAgMC4yNDU4
MjFdIHBucCAwMDowMDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBhMDMg
KGFjdGl2ZSkNClsgICAgMC4yNDU5OTRdIHBucCAwMDowMTogW21lbSAweDAwMDAwMDAwLTB4
ZmZmZmZmZmZmZmZmZmZmZiBkaXNhYmxlZF0NClsgICAgMC4yNDYwMDBdIHBucCAwMDowMTog
W21lbSAweGZlYzIwMDAwLTB4ZmVjMjAwZmZdDQpbICAgIDAuMjQ2MjY2XSBzeXN0ZW0gMDA6
MDE6IFttZW0gMHhmZWMyMDAwMC0weGZlYzIwMGZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQN
ClsgICAgMC4yNDYyNzVdIHN5c3RlbSAwMDowMTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmlj
ZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkNClsgICAgMC4yNDY0MDJdIHBucCAwMDowMjogW21l
bSAweGY2MDAwMDAwLTB4ZjYwMDNmZmZdDQpbICAgIDAuMjQ2NjQ2XSBzeXN0ZW0gMDA6MDI6
IFttZW0gMHhmNjAwMDAwMC0weGY2MDAzZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAw
LjI0NjY1NF0gc3lzdGVtIDAwOjAyOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMGMwMiAoYWN0aXZlKQ0KWyAgICAwLjI0NjkzOV0gcG5wIDAwOjAzOiBbZG1hIDRdDQpb
ICAgIDAuMjQ2OTQzXSBwbnAgMDA6MDM6IFtpbyAgMHgwMDAwLTB4MDAwZl0NClsgICAgMC4y
NDY5NDZdIHBucCAwMDowMzogW2lvICAweDAwODEtMHgwMDgzXQ0KWyAgICAwLjI0Njk1MF0g
cG5wIDAwOjAzOiBbaW8gIDB4MDA4N10NClsgICAgMC4yNDY5NTRdIHBucCAwMDowMzogW2lv
ICAweDAwODktMHgwMDhiXQ0KWyAgICAwLjI0Njk1N10gcG5wIDAwOjAzOiBbaW8gIDB4MDA4
Zl0NClsgICAgMC4yNDY5NjNdIHBucCAwMDowMzogW2lvICAweDAwYzAtMHgwMGRmXQ0KWyAg
ICAwLjI0NzE2N10gcG5wIDAwOjAzOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDIwMCAoYWN0aXZlKQ0KWyAgICAwLjI0NzE5OF0gcG5wIDAwOjA0OiBbaW8gIDB4MDA3
MC0weDAwNzFdDQpbICAgIDAuMjQ3MjAzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA4IHRyaWdn
ZXJpbmcgMSBwb2xhcml0eSAwDQpbICAgIDAuMjQ3MjExXSB4ZW5fbWFwX3BpcnFfZ3NpOiBy
ZXR1cm5pbmcgaXJxIDggZm9yIGdzaSA4DQpbICAgIDAuMjQ3MjE1XSB4ZW46IC0tPiBwaXJx
PTggLT4gaXJxPTggKGdzaT04KQ0KWyAgICAwLjI0NzIzMl0gcG5wIDAwOjA0OiBbaXJxIDhd
DQpbICAgIDAuMjQ3NDMzXSBwbnAgMDA6MDQ6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2Us
IElEcyBQTlAwYjAwIChhY3RpdmUpDQpbICAgIDAuMjQ3NTE0XSBwbnAgMDA6MDU6IFtpbyAg
MHgwMDYxXQ0KWyAgICAwLjI0Nzc1M10gcG5wIDAwOjA1OiBQbHVnIGFuZCBQbGF5IEFDUEkg
ZGV2aWNlLCBJRHMgUE5QMDgwMCAoYWN0aXZlKQ0KWyAgICAwLjI0Nzc3Ml0gcG5wIDAwOjA2
OiBbaW8gIDB4MDBmMC0weDAwZmZdDQpbICAgIDAuMjQ3Nzc3XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxMyB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMA0KWyAgICAwLjI0Nzc4Ml0geGVuX21h
cF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxMyBmb3IgZ3NpIDEzDQpbICAgIDAuMjQ3Nzg3
XSB4ZW46IC0tPiBwaXJxPTEzIC0+IGlycT0xMyAoZ3NpPTEzKQ0KWyAgICAwLjI0NzgwM10g
cG5wIDAwOjA2OiBbaXJxIDEzXQ0KWyAgICAwLjI0Nzk5OV0gcG5wIDAwOjA2OiBQbHVnIGFu
ZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwNCAoYWN0aXZlKQ0KWyAgICAwLjI0ODQz
MV0gcG5wIDAwOjA3OiBbaW8gIDB4MDNmOC0weDAzZmZdDQpbICAgIDAuMjQ4NDM2XSB4ZW46
IHJlZ2lzdGVyaW5nIGdzaSA0IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwDQpbICAgIDAuMjQ4
NDQyXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDQgZm9yIGdzaSA0DQpbICAg
IDAuMjQ4NDQ2XSB4ZW46IC0tPiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQ0KWyAgICAwLjI0
ODQ1MF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0DQpbICAgIDAuMjQ4NDU0XSBwbnAgMDA6
MDc6IFtpcnEgNF0NClsgICAgMC4yNDg0NTddIHBucCAwMDowNzogW2RtYSAwIGRpc2FibGVk
XQ0KWyAgICAwLjI0ODY5OV0gcG5wIDAwOjA3OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNl
LCBJRHMgUE5QMDUwMSAoYWN0aXZlKQ0KWyAgICAwLjI0ODg2MF0gcG5wIDAwOjA4OiBbaW8g
IDB4MDAwMC0weGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdDQpbICAgIDAuMjQ4ODY1XSBw
bnAgMDA6MDg6IFtpbyAgMHgwNjAwLTB4MDZkZl0NClsgICAgMC4yNDg4NjldIHBucCAwMDow
ODogW2lvICAweDBhZTAtMHgwYWVmXQ0KWyAgICAwLjI0OTE5OF0gc3lzdGVtIDAwOjA4OiBb
aW8gIDB4MDYwMC0weDA2ZGZdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjQ5MjA1XSBz
eXN0ZW0gMDA6MDg6IFtpbyAgMHgwYWUwLTB4MGFlZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsg
ICAgMC4yNDkyMTJdIHN5c3RlbSAwMDowODogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwg
SURzIFBOUDBjMDIgKGFjdGl2ZSkNClsgICAgMC4yNDkyNjVdIHBucCAwMDowOTogW21lbSAw
eGZlZDAwMDAwLTB4ZmVkMDAzZmZdDQpbICAgIDAuMjQ5NDc5XSBwbnAgMDA6MDk6IFBsdWcg
YW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwMTAzIChhY3RpdmUpDQpbICAgIDAuMjQ5
NjM3XSBwbnAgMDA6MGE6IFtpbyAgMHgwMDYwXQ0KWyAgICAwLjI0OTY0MV0gcG5wIDAwOjBh
OiBbaW8gIDB4MDA2NF0NClsgICAgMC4yNDk2NDVdIHBucCAwMDowYTogW21lbSAweGZlYzAw
MDAwLTB4ZmVjMDBmZmZdDQpbICAgIDAuMjQ5NjQ5XSBwbnAgMDA6MGE6IFttZW0gMHhmZWUw
MDAwMC0weGZlZTAwZmZmXQ0KWyAgICAwLjI0OTk0NF0gc3lzdGVtIDAwOjBhOiBbbWVtIDB4
ZmVjMDAwMDAtMHhmZWMwMGZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQpbICAgIDAuMjQ5
OTUxXSBzeXN0ZW0gMDA6MGE6IFttZW0gMHhmZWUwMDAwMC0weGZlZTAwZmZmXSBoYXMgYmVl
biByZXNlcnZlZA0KWyAgICAwLjI0OTk1OF0gc3lzdGVtIDAwOjBhOiBQbHVnIGFuZCBQbGF5
IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMiAoYWN0aXZlKQ0KWyAgICAwLjI1MDI0NF0gcG5w
IDAwOjBiOiBbaW8gIDB4MDAxMC0weDAwMWZdDQpbICAgIDAuMjUwMjQ4XSBwbnAgMDA6MGI6
IFtpbyAgMHgwMDIyLTB4MDAzZl0NClsgICAgMC4yNTAyNTVdIHBucCAwMDowYjogW2lvICAw
eDAwNjItMHgwMDYzXQ0KWyAgICAwLjI1MDI1OV0gcG5wIDAwOjBiOiBbaW8gIDB4MDA2NS0w
eDAwNmZdDQpbICAgIDAuMjUwMjYzXSBwbnAgMDA6MGI6IFtpbyAgMHgwMDcyLTB4MDA3Zl0N
ClsgICAgMC4yNTAyNjZdIHBucCAwMDowYjogW2lvICAweDAwODBdDQpbICAgIDAuMjUwMjcw
XSBwbnAgMDA6MGI6IFtpbyAgMHgwMDg0LTB4MDA4Nl0NClsgICAgMC4yNTAyNzRdIHBucCAw
MDowYjogW2lvICAweDAwODhdDQpbICAgIDAuMjUwMjc3XSBwbnAgMDA6MGI6IFtpbyAgMHgw
MDhjLTB4MDA4ZV0NClsgICAgMC4yNTAyODFdIHBucCAwMDowYjogW2lvICAweDAwOTAtMHgw
MDlmXQ0KWyAgICAwLjI1MDI4NF0gcG5wIDAwOjBiOiBbaW8gIDB4MDBhMi0weDAwYmZdDQpb
ICAgIDAuMjUwMjg4XSBwbnAgMDA6MGI6IFtpbyAgMHgwMGIxXQ0KWyAgICAwLjI1MDI5Ml0g
cG5wIDAwOjBiOiBbaW8gIDB4MDBlMC0weDAwZWZdDQpbICAgIDAuMjUwMjk1XSBwbnAgMDA6
MGI6IFtpbyAgMHgwNGQwLTB4MDRkMV0NClsgICAgMC4yNTAyOTldIHBucCAwMDowYjogW2lv
ICAweDA0MGJdDQpbICAgIDAuMjUwMzAzXSBwbnAgMDA6MGI6IFtpbyAgMHgwNGQ2XQ0KWyAg
ICAwLjI1MDMwNl0gcG5wIDAwOjBiOiBbaW8gIDB4MGMwMC0weDBjMDFdDQpbICAgIDAuMjUw
MzE3XSBwbnAgMDA6MGI6IFtpbyAgMHgwYzE0XQ0KWyAgICAwLjI1MDMyMF0gcG5wIDAwOjBi
OiBbaW8gIDB4MGM1MC0weDBjNTFdDQpbICAgIDAuMjUwMzI0XSBwbnAgMDA6MGI6IFtpbyAg
MHgwYzUyXQ0KWyAgICAwLjI1MDMyN10gcG5wIDAwOjBiOiBbaW8gIDB4MGM2Y10NClsgICAg
MC4yNTAzMzFdIHBucCAwMDowYjogW2lvICAweDBjNmZdDQpbICAgIDAuMjUwMzM0XSBwbnAg
MDA6MGI6IFtpbyAgMHgwY2QwLTB4MGNkMV0NClsgICAgMC4yNTAzMzhdIHBucCAwMDowYjog
W2lvICAweDBjZDItMHgwY2QzXQ0KWyAgICAwLjI1MDM0Ml0gcG5wIDAwOjBiOiBbaW8gIDB4
MGNkNC0weDBjZDVdDQpbICAgIDAuMjUwMzQ2XSBwbnAgMDA6MGI6IFtpbyAgMHgwY2Q2LTB4
MGNkN10NClsgICAgMC4yNTAzNDldIHBucCAwMDowYjogW2lvICAweDBjZDgtMHgwY2RmXQ0K
WyAgICAwLjI1MDM1M10gcG5wIDAwOjBiOiBbaW8gIDB4MDgwMC0weDA4OWZdDQpbICAgIDAu
MjUwMzU3XSBwbnAgMDA6MGI6IFtpbyAgMHgwMDAwLTB4ZmZmZmZmZmZmZmZmZmZmZiBkaXNh
YmxlZF0NClsgICAgMC4yNTAzNjJdIHBucCAwMDowYjogW2lvICAweDBiMDAtMHgwYjFmXQ0K
WyAgICAwLjI1MDM2NV0gcG5wIDAwOjBiOiBbaW8gIDB4MGIyMC0weDBiM2ZdDQpbICAgIDAu
MjUwMzY5XSBwbnAgMDA6MGI6IFtpbyAgMHgwOTAwLTB4MDkwZl0NClsgICAgMC4yNTAzNzNd
IHBucCAwMDowYjogW2lvICAweDA5MTAtMHgwOTFmXQ0KWyAgICAwLjI1MDM3N10gcG5wIDAw
OjBiOiBbaW8gIDB4ZmUwMC0weGZlZmVdDQpbICAgIDAuMjUwMzgwXSBwbnAgMDA6MGI6IFtp
byAgMHgwMDYwXQ0KWyAgICAwLjI1MDM4NF0gcG5wIDAwOjBiOiBbaW8gIDB4MDA2NF0NClsg
ICAgMC4yNTAzODhdIHBucCAwMDowYjogW21lbSAweDAwMDAwMDAwLTB4ZmZmZmZmZmZmZmZm
ZmZmZiBkaXNhYmxlZF0NClsgICAgMC4yNTAzOTNdIHBucCAwMDowYjogW21lbSAweGZmYjgw
MDAwLTB4ZmZiZmZmZmZdDQpbICAgIDAuMjUwNDA0XSBwbnAgMDA6MGI6IFttZW0gMHhmZWMx
MDAwMC0weGZlYzEwMDFmXQ0KWyAgICAwLjI1MDQwOF0gcG5wIDAwOjBiOiBbbWVtIDB4ZmVk
ODAwMDAtMHhmZWQ4MGZmZl0NClsgICAgMC4yNTA0MTJdIHBucCAwMDowYjogW21lbSAweDAw
MDAwMDAwLTB4ZmZmZmZmZmZmZmZmZmZmZiBkaXNhYmxlZF0NClsgICAgMC4yNTA3OTBdIHN5
c3RlbSAwMDowYjogW2lvICAweDA0ZDAtMHgwNGQxXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAg
ICAwLjI1MDc5Nl0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4MDQwYl0gaGFzIGJlZW4gcmVzZXJ2
ZWQNClsgICAgMC4yNTA4MDFdIHN5c3RlbSAwMDowYjogW2lvICAweDA0ZDZdIGhhcyBiZWVu
IHJlc2VydmVkDQpbICAgIDAuMjUwODA2XSBzeXN0ZW0gMDA6MGI6IFtpbyAgMHgwYzAwLTB4
MGMwMV0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4yNTA4MTFdIHN5c3RlbSAwMDowYjog
W2lvICAweDBjMTRdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwODE2XSBzeXN0ZW0g
MDA6MGI6IFtpbyAgMHgwYzUwLTB4MGM1MV0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4y
NTA4MjFdIHN5c3RlbSAwMDowYjogW2lvICAweDBjNTJdIGhhcyBiZWVuIHJlc2VydmVkDQpb
ICAgIDAuMjUwODI2XSBzeXN0ZW0gMDA6MGI6IFtpbyAgMHgwYzZjXSBoYXMgYmVlbiByZXNl
cnZlZA0KWyAgICAwLjI1MDgzOF0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4MGM2Zl0gaGFzIGJl
ZW4gcmVzZXJ2ZWQNClsgICAgMC4yNTA4NDNdIHN5c3RlbSAwMDowYjogW2lvICAweDBjZDAt
MHgwY2QxXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjI1MDg0OF0gc3lzdGVtIDAwOjBi
OiBbaW8gIDB4MGNkMi0weDBjZDNdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwODUz
XSBzeXN0ZW0gMDA6MGI6IFtpbyAgMHgwY2Q0LTB4MGNkNV0gaGFzIGJlZW4gcmVzZXJ2ZWQN
ClsgICAgMC4yNTA4NTldIHN5c3RlbSAwMDowYjogW2lvICAweDBjZDYtMHgwY2Q3XSBoYXMg
YmVlbiByZXNlcnZlZA0KWyAgICAwLjI1MDg2NF0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4MGNk
OC0weDBjZGZdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwODY5XSBzeXN0ZW0gMDA6
MGI6IFtpbyAgMHgwODAwLTB4MDg5Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4yNTA4
NzRdIHN5c3RlbSAwMDowYjogW2lvICAweDBiMDAtMHgwYjFmXSBoYXMgYmVlbiByZXNlcnZl
ZA0KWyAgICAwLjI1MDg3OV0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4MGIyMC0weDBiM2ZdIGhh
cyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwODg1XSBzeXN0ZW0gMDA6MGI6IFtpbyAgMHgw
OTAwLTB4MDkwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4yNTA4OTBdIHN5c3RlbSAw
MDowYjogW2lvICAweDA5MTAtMHgwOTFmXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjI1
MDg5NV0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4ZmUwMC0weGZlZmVdIGhhcyBiZWVuIHJlc2Vy
dmVkDQpbICAgIDAuMjUwOTAxXSBzeXN0ZW0gMDA6MGI6IFttZW0gMHhmZmI4MDAwMC0weGZm
YmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjI1MDkwN10gc3lzdGVtIDAwOjBi
OiBbbWVtIDB4ZmVjMTAwMDAtMHhmZWMxMDAxZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAg
MC4yNTA5MTJdIHN5c3RlbSAwMDowYjogW21lbSAweGZlZDgwMDAwLTB4ZmVkODBmZmZdIGhh
cyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwOTI3XSBzeXN0ZW0gMDA6MGI6IFBsdWcgYW5k
IFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpDQpbICAgIDAuMjUxMDE1
XSBwbnAgMDA6MGM6IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXQ0KWyAgICAwLjI1MTMz
M10gc3lzdGVtIDAwOjBjOiBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gaGFzIGJlZW4g
cmVzZXJ2ZWQNClsgICAgMC4yNTEzNDJdIHN5c3RlbSAwMDowYzogUGx1ZyBhbmQgUGxheSBB
Q1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkNClsgICAgMC4yNTE1NjldIHBucCAw
MDowZDogW21lbSAweDAwMDAwMDAwLTB4MDAwOWZmZmZdDQpbICAgIDAuMjUxNTczXSBwbnAg
MDA6MGQ6IFttZW0gMHgwMDBjMDAwMC0weDAwMGNmZmZmXQ0KWyAgICAwLjI1MTU3OF0gcG5w
IDAwOjBkOiBbbWVtIDB4MDAwZTAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC4yNTE1ODJdIHBu
cCAwMDowZDogW21lbSAweDAwMTAwMDAwLTB4YWZmZmZmZmZdDQpbICAgIDAuMjUxNTg2XSBw
bnAgMDA6MGQ6IFttZW0gMHhmZWMwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjI1MTkyN10g
c3lzdGVtIDAwOjBkOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA5ZmZmZl0gY291bGQgbm90IGJl
IHJlc2VydmVkDQpbICAgIDAuMjUxOTM0XSBzeXN0ZW0gMDA6MGQ6IFttZW0gMHgwMDBjMDAw
MC0weDAwMGNmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQNClsgICAgMC4yNTE5MzldIHN5
c3RlbSAwMDowZDogW21lbSAweDAwMGUwMDAwLTB4MDAwZmZmZmZdIGNvdWxkIG5vdCBiZSBy
ZXNlcnZlZA0KWyAgICAwLjI1MTk0NV0gc3lzdGVtIDAwOjBkOiBbbWVtIDB4MDAxMDAwMDAt
MHhhZmZmZmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQpbICAgIDAuMjUxOTUyXSBzeXN0
ZW0gMDA6MGQ6IFttZW0gMHhmZWMwMDAwMC0weGZmZmZmZmZmXSBjb3VsZCBub3QgYmUgcmVz
ZXJ2ZWQNClsgICAgMC4yNTE5NjBdIHN5c3RlbSAwMDowZDogUGx1ZyBhbmQgUGxheSBBQ1BJ
IGRldmljZSwgSURzIFBOUDBjMDEgKGFjdGl2ZSkNClsgICAgMC4yNTIxOTldIHBucDogUG5Q
IEFDUEk6IGZvdW5kIDE0IGRldmljZXMNClsgICAgMC4yNTIyMDNdIEFDUEk6IEFDUEkgYnVz
IHR5cGUgcG5wIHVucmVnaXN0ZXJlZA0KWyAgICAwLjI1NDQwMV0gcGNpYmFjayAwMDAwOjBh
OjAwLjA6IHNlaXppbmcgZGV2aWNlDQpbICAgIDAuMjU0NDg3XSBwY2liYWNrIDAwMDA6MGE6
MDAuMTogc2VpemluZyBkZXZpY2UNClsgICAgMC4yNTQ1NjZdIHBjaWJhY2sgMDAwMDowYTow
MC4yOiBzZWl6aW5nIGRldmljZQ0KWyAgICAwLjI1NDYzOV0gcGNpYmFjayAwMDAwOjBhOjAw
LjM6IHNlaXppbmcgZGV2aWNlDQpbICAgIDAuMjU0NzQ2XSBwY2liYWNrIDAwMDA6MGE6MDAu
NDogc2VpemluZyBkZXZpY2UNClsgICAgMC4yNTQ4MjVdIHBjaWJhY2sgMDAwMDowYTowMC41
OiBzZWl6aW5nIGRldmljZQ0KWyAgICAwLjI1NDkwN10gcGNpYmFjayAwMDAwOjBhOjAwLjY6
IHNlaXppbmcgZGV2aWNlDQpbICAgIDAuMjU0OTgyXSBwY2liYWNrIDAwMDA6MGE6MDAuNzog
c2VpemluZyBkZXZpY2UNClsgICAgMC4yNTUyOTZdIHBjaWJhY2sgMDAwMDowNzowMS4wOiBz
ZWl6aW5nIGRldmljZQ0KWyAgICAwLjI1NTM3NV0gcGNpYmFjayAwMDAwOjA3OjAxLjE6IHNl
aXppbmcgZGV2aWNlDQpbICAgIDAuMjU1NDU1XSBwY2liYWNrIDAwMDA6MDc6MDEuMjogc2Vp
emluZyBkZXZpY2UNClsgICAgMC4yNTU1MjldIHBjaWJhY2sgMDAwMDowNTowMC4wOiBzZWl6
aW5nIGRldmljZQ0KWyAgICAwLjI1NTYwOF0gcGNpYmFjayAwMDAwOjA1OjAwLjE6IHNlaXpp
bmcgZGV2aWNlDQpbICAgIDAuMjU1NjkwXSBwY2liYWNrIDAwMDA6MDQ6MDAuMDogc2Vpemlu
ZyBkZXZpY2UNClsgICAgMC4yNTU3NjJdIHBjaWJhY2sgMDAwMDowNDowMC4xOiBzZWl6aW5n
IGRldmljZQ0KWyAgICAwLjI1NTg0Ml0gcGNpYmFjayAwMDAwOjA0OjAwLjI6IHNlaXppbmcg
ZGV2aWNlDQpbICAgIDAuMjU1OTIyXSBwY2liYWNrIDAwMDA6MDQ6MDAuMzogc2VpemluZyBk
ZXZpY2UNClsgICAgMC4yNTYwMDFdIHBjaWJhY2sgMDAwMDowNDowMC40OiBzZWl6aW5nIGRl
dmljZQ0KWyAgICAwLjI1NjExN10gcGNpYmFjayAwMDAwOjA0OjAwLjU6IHNlaXppbmcgZGV2
aWNlDQpbICAgIDAuMjU2MTkyXSBwY2liYWNrIDAwMDA6MDQ6MDAuNjogc2VpemluZyBkZXZp
Y2UNClsgICAgMC4yNTYyNzRdIHBjaWJhY2sgMDAwMDowNDowMC43OiBzZWl6aW5nIGRldmlj
ZQ0KWyAgICAwLjI1NjM1M10gcGNpYmFjayAwMDAwOjAzOjA2LjA6IHNlaXppbmcgZGV2aWNl
DQpbICAgIDAuMjY2NDU2XSBQTS1UaW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgw
eDB4ZmZmZmZmKSAtIGFib3J0aW5nLg0KWyAgICAwLjI2NjU1MV0gUENJOiBtYXggYnVzIGRl
cHRoOiAyIHBjaV90cnlfbnVtOiAzDQpbICAgIDAuMjY2NjU3XSBwY2kgMDAwMDowMDowMi4w
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMGItMGJdDQpbICAgIDAuMjY2NjY0XSBwY2kgMDAwMDow
MDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQ0KWyAgICAwLjI2
NjY3M10gcGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYTAwMDAw
MC0weGZlOWZmZmZmXQ0KWyAgICAwLjI2NjY4MV0gcGNpIDAwMDA6MDA6MDIuMDogICBicmlk
Z2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAg
IDAuMjY2NzAwXSBwY2kgMDAwMDowMDowMy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGEtMGFd
DQpbICAgIDAuMjY2NzA4XSBwY2kgMDAwMDowMDowMy4wOiAgIGJyaWRnZSB3aW5kb3cgW21l
bSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQpbICAgIDAuMjY2NzIxXSBwY2kgMDAwMDowMDow
NS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDktMDldDQpbICAgIDAuMjY2NzI3XSBwY2kgMDAw
MDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQ0KWyAgICAw
LjI2NjczNV0gcGNpIDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWUw
MDAwMC0weGY5ZWZmZmZmXQ0KWyAgICAwLjI2Njc0M10gcGNpIDAwMDA6MDA6MDUuMDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhjZmYwMDAwMC0weGNmZmZmZmZmIDY0Yml0IHByZWZdDQpb
ICAgIDAuMjY2NzU0XSBwY2kgMDAwMDowMDowNi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDgt
MDhdDQpbICAgIDAuMjY2NzYwXSBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cg
W2lvICAweGMwMDAtMHhjZmZmXQ0KWyAgICAwLjI2Njc2OV0gcGNpIDAwMDA6MDA6MDYuMDog
ICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWQwMDAwMC0weGY5ZGZmZmZmXQ0KWyAgICAwLjI2
Njc4M10gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhjZmUwMDAw
MC0weGNmZWZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY2Nzk2XSBwY2liYWNrIDAwMDA6
MDc6MDEuMDogQkFSIDA6IGFzc2lnbmVkIFttZW0gMHhmOWMwMDAwMC0weGY5YzAwZmZmXQ0K
WyAgICAwLjI2NjgwOF0gcGNpYmFjayAwMDAwOjA3OjAxLjE6IEJBUiAwOiBhc3NpZ25lZCBb
bWVtIDB4ZjljMDEwMDAtMHhmOWMwMWZmZl0NClsgICAgMC4yNjY4MThdIHBjaWJhY2sgMDAw
MDowNzowMS4yOiBCQVIgMDogYXNzaWduZWQgW21lbSAweGY5YzAyMDAwLTB4ZjljMDJmZmZd
DQpbICAgIDAuMjY2ODI5XSBwY2kgMDAwMDowNjowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMg
MDctMDddDQpbICAgIDAuMjY2ODQwXSBwY2kgMDAwMDowNjowMC4wOiAgIGJyaWRnZSB3aW5k
b3cgW21lbSAweGY5YzAwMDAwLTB4ZjljZmZmZmZdDQpbICAgIDAuMjY2ODU4XSBwY2kgMDAw
MDowMDowYS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDYtMDddDQpbICAgIDAuMjY2ODczXSBw
Y2kgMDAwMDowMDowYS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YzAwMDAwLTB4Zjlj
ZmZmZmZdDQpbICAgIDAuMjY2ODg3XSBwY2kgMDAwMDowMDowYi4wOiBQQ0kgYnJpZGdlIHRv
IFtidXMgMDUtMDVdDQpbICAgIDAuMjY2ODkyXSBwY2kgMDAwMDowMDowYi4wOiAgIGJyaWRn
ZSB3aW5kb3cgW2lvICAweGIwMDAtMHhiZmZmXQ0KWyAgICAwLjI2NjkwMV0gcGNpIDAwMDA6
MDA6MGIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWIwMDAwMC0weGY5YmZmZmZmXQ0K
WyAgICAwLjI2NjkwOV0gcGNpIDAwMDA6MDA6MGIuMDogICBicmlkZ2Ugd2luZG93IFttZW0g
MHhiMDAwMDAwMC0weGJmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY2OTIwXSBwY2kg
MDAwMDowMDowZC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdDQpbICAgIDAuMjY2OTI5
XSBwY2kgMDAwMDowMDowZC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YTAwMDAwLTB4
ZjlhZmZmZmZdDQpbICAgIDAuMjY2OTQyXSBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdl
IHRvIFtidXMgMDMtMDNdDQpbICAgIDAuMjY2OTU2XSBwY2kgMDAwMDowMDoxNC40OiAgIGJy
aWRnZSB3aW5kb3cgW2lvICAweGEwMDAtMHhhZmZmXQ0KWyAgICAwLjI2Njk3Nl0gcGNpIDAw
MDA6MDA6MTUuMDogUENJIGJyaWRnZSB0byBbYnVzIDAyLTAyXQ0KWyAgICAwLjI2NzAwNF0g
eGVuOiByZWdpc3RlcmluZyBnc2kgNTIgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAg
MC4yNjcwMjBdIHhlbjogLS0+IHBpcnE9NTIgLT4gaXJxPTUyIChnc2k9NTIpDQpbICAgIDAu
MjY3MDQ4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA1MiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg
MQ0KWyAgICAwLjI2NzA3Nl0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA1MiBm
b3IgZ3NpIDUyDQpbICAgIDAuMjY3MDgxXSB4ZW46IC0tPiBwaXJxPTUyIC0+IGlycT01MiAo
Z3NpPTUyKQ0KWyAgICAwLjI2NzA4NV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo1Mg0KWyAg
ICAwLjI2NzA5NV0geGVuOiByZWdpc3RlcmluZyBnc2kgNTIgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDENClsgICAgMC4yNjcxMDBdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEg
NTIgZm9yIGdzaSA1Mg0KWyAgICAwLjI2NzEwNV0geGVuOiAtLT4gcGlycT01MiAtPiBpcnE9
NTIgKGdzaT01MikNClsgICAgMC4yNjcxMDldIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NTIN
ClsgICAgMC4yNjcxMThdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDUzIHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgIDAuMjY3MTY0XSB4ZW46IC0tPiBwaXJxPTUzIC0+IGlycT01MyAo
Z3NpPTUzKQ0KWyAgICAwLjI2NzE4MV0geGVuOiByZWdpc3RlcmluZyBnc2kgNTQgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAgMC4yNjcxOTFdIHhlbjogLS0+IHBpcnE9NTQgLT4g
aXJxPTU0IChnc2k9NTQpDQpbICAgIDAuMjY3MjE1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA1
NCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAwLjI2NzIyMF0geGVuX21hcF9waXJx
X2dzaTogcmV0dXJuaW5nIGlycSA1NCBmb3IgZ3NpIDU0DQpbICAgIDAuMjY3MjI1XSB4ZW46
IC0tPiBwaXJxPTU0IC0+IGlycT01NCAoZ3NpPTU0KQ0KWyAgICAwLjI2NzIyOV0gQWxyZWFk
eSBzZXR1cCB0aGUgR1NJIDo1NA0KWyAgICAwLjI2NzIzOV0geGVuOiByZWdpc3RlcmluZyBn
c2kgNTQgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC4yNjcyNDNdIHhlbl9tYXBf
cGlycV9nc2k6IHJldHVybmluZyBpcnEgNTQgZm9yIGdzaSA1NA0KWyAgICAwLjI2NzI0OF0g
eGVuOiAtLT4gcGlycT01NCAtPiBpcnE9NTQgKGdzaT01NCkNClsgICAgMC4yNjcyNTJdIEFs
cmVhZHkgc2V0dXAgdGhlIEdTSSA6NTQNClsgICAgMC4yNjcyNzBdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuMjY3MjgwXSB4ZW46
IC0tPiBwaXJxPTE2IC0+IGlycT0xNiAoZ3NpPTE2KQ0KWyAgICAwLjI2NzMwMl0gcGNpX2J1
cyAwMDAwOjAwOiByZXNvdXJjZSA0IFtpbyAgMHgwMDAwLTB4MGNmN10NClsgICAgMC4yNjcz
MDddIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNSBbaW8gIDB4MGQwMC0weGZmZmZdDQpb
ICAgIDAuMjY3MzExXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDYgW21lbSAweDAwMGEw
MDAwLTB4MDAwYmZmZmZdDQpbICAgIDAuMjY3MzE2XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291
cmNlIDcgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZmZmZdDQpbICAgIDAuMjY3MzIxXSBwY2lf
YnVzIDAwMDA6MDA6IHJlc291cmNlIDggW21lbSAweGIwMDAwMDAwLTB4ZGZmZmZmZmZdDQpb
ICAgIDAuMjY3MzI2XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDkgW21lbSAweGYwMDAw
MDAwLTB4ZmViZmZmZmZdDQpbICAgIDAuMjY3MzMxXSBwY2lfYnVzIDAwMDA6MGI6IHJlc291
cmNlIDAgW2lvICAweGUwMDAtMHhlZmZmXQ0KWyAgICAwLjI2NzMzNV0gcGNpX2J1cyAwMDAw
OjBiOiByZXNvdXJjZSAxIFttZW0gMHhmYTAwMDAwMC0weGZlOWZmZmZmXQ0KWyAgICAwLjI2
NzM0MF0gcGNpX2J1cyAwMDAwOjBiOiByZXNvdXJjZSAyIFttZW0gMHhkMDAwMDAwMC0weGRm
ZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY3MzQ2XSBwY2lfYnVzIDAwMDA6MGE6IHJl
c291cmNlIDEgW21lbSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQpbICAgIDAuMjY3MzUxXSBw
Y2lfYnVzIDAwMDA6MDk6IHJlc291cmNlIDAgW2lvICAweGQwMDAtMHhkZmZmXQ0KWyAgICAw
LjI2NzM1NV0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAxIFttZW0gMHhmOWUwMDAwMC0w
eGY5ZWZmZmZmXQ0KWyAgICAwLjI2NzM2MF0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAy
IFttZW0gMHhjZmYwMDAwMC0weGNmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY3MzY2
XSBwY2lfYnVzIDAwMDA6MDg6IHJlc291cmNlIDAgW2lvICAweGMwMDAtMHhjZmZmXQ0KWyAg
ICAwLjI2NzM3MF0gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJjZSAxIFttZW0gMHhmOWQwMDAw
MC0weGY5ZGZmZmZmXQ0KWyAgICAwLjI2NzM3NV0gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJj
ZSAyIFttZW0gMHhjZmUwMDAwMC0weGNmZWZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY3
Mzg4XSBwY2lfYnVzIDAwMDA6MDY6IHJlc291cmNlIDEgW21lbSAweGY5YzAwMDAwLTB4Zjlj
ZmZmZmZdDQpbICAgIDAuMjY3MzkzXSBwY2lfYnVzIDAwMDA6MDc6IHJlc291cmNlIDEgW21l
bSAweGY5YzAwMDAwLTB4ZjljZmZmZmZdDQpbICAgIDAuMjY3Mzk4XSBwY2lfYnVzIDAwMDA6
MDU6IHJlc291cmNlIDAgW2lvICAweGIwMDAtMHhiZmZmXQ0KWyAgICAwLjI2NzQwMl0gcGNp
X2J1cyAwMDAwOjA1OiByZXNvdXJjZSAxIFttZW0gMHhmOWIwMDAwMC0weGY5YmZmZmZmXQ0K
WyAgICAwLjI2NzQwN10gcGNpX2J1cyAwMDAwOjA1OiByZXNvdXJjZSAyIFttZW0gMHhiMDAw
MDAwMC0weGJmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY3NDEzXSBwY2lfYnVzIDAw
MDA6MDQ6IHJlc291cmNlIDEgW21lbSAweGY5YTAwMDAwLTB4ZjlhZmZmZmZdDQpbICAgIDAu
MjY3NDE4XSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDAgW2lvICAweGEwMDAtMHhhZmZm
XQ0KWyAgICAwLjI2NzQyMl0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSA0IFtpbyAgMHgw
MDAwLTB4MGNmN10NClsgICAgMC4yNjc0MjddIHBjaV9idXMgMDAwMDowMzogcmVzb3VyY2Ug
NSBbaW8gIDB4MGQwMC0weGZmZmZdDQpbICAgIDAuMjY3NDMxXSBwY2lfYnVzIDAwMDA6MDM6
IHJlc291cmNlIDYgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdDQpbICAgIDAuMjY3NDM2
XSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDcgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZm
ZmZdDQpbICAgIDAuMjY3NDQxXSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDggW21lbSAw
eGIwMDAwMDAwLTB4ZGZmZmZmZmZdDQpbICAgIDAuMjY3NDQ2XSBwY2lfYnVzIDAwMDA6MDM6
IHJlc291cmNlIDkgW21lbSAweGYwMDAwMDAwLTB4ZmViZmZmZmZdDQpbICAgIDAuMjY3NTA0
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDINClsgICAgMC4yNjc4MjNdIElQ
IHJvdXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMzI3NjggKG9yZGVyOiA2LCAyNjIx
NDQgYnl0ZXMpDQpbICAgIDAuMjY4OTUxXSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBl
bnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA5LCAyMDk3MTUyIGJ5dGVzKQ0KWyAgICAwLjI3MDQ4
MV0gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDEwLCA0MTk0
MzA0IGJ5dGVzKQ0KWyAgICAwLjI3ODc4OF0gVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVk
IChlc3RhYmxpc2hlZCAxMzEwNzIgYmluZCA2NTUzNikNClsgICAgMC4yNzg4MTFdIFRDUCBy
ZW5vIHJlZ2lzdGVyZWQNClsgICAgMC4yNzg4NDZdIFVEUCBoYXNoIHRhYmxlIGVudHJpZXM6
IDUxMiAob3JkZXI6IDQsIDgxOTIwIGJ5dGVzKQ0KWyAgICAwLjI3ODk5NV0gVURQLUxpdGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyOiA0LCA4MTkyMCBieXRlcykNClsgICAg
MC4yNzkzMDRdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQ0KWyAgICAwLjI3
OTYwMV0gUlBDOiBSZWdpc3RlcmVkIG5hbWVkIFVOSVggc29ja2V0IHRyYW5zcG9ydCBtb2R1
bGUuDQpbICAgIDAuMjc5NjQxXSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRyYW5zcG9ydCBtb2R1
bGUuDQpbICAgIDAuMjc5NjQ1XSBSUEM6IFJlZ2lzdGVyZWQgdGNwIHRyYW5zcG9ydCBtb2R1
bGUuDQpbICAgIDAuMjc5NjQ5XSBSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2No
YW5uZWwgdHJhbnNwb3J0IG1vZHVsZS4NClsgICAgMC41NjgxNzZdIHBjaSAwMDAwOjBiOjAw
LjA6IEJvb3QgdmlkZW8gZGV2aWNlDQpbICAgIDAuNTY4MzU1XSBwY2kgMDAwMDowNjowMC4w
OiBUSSBYSU8yMDAwYSBxdWlyayBkZXRlY3RlZDsgc2Vjb25kYXJ5IGJ1cyBmYXN0IGJhY2st
dG8tYmFjayB0cmFuc2ZlcnMgZGlzYWJsZWQNClsgICAgMC41Njg1NzNdIFBDSTogQ0xTIDY0
IGJ5dGVzLCBkZWZhdWx0IDY0DQpbICAgIDAuNTY4NzA0XSBUcnlpbmcgdG8gdW5wYWNrIHJv
b3RmcyBpbWFnZSBhcyBpbml0cmFtZnMuLi4NClsgICAgMC41ODIxMDVdIEZyZWVpbmcgaW5p
dHJkIG1lbW9yeTogNjcyNGsgZnJlZWQNClsgICAgMC41ODc5NjddIERNQS1BUEk6IHByZWFs
bG9jYXRlZCAzMjc2OCBkZWJ1ZyBlbnRyaWVzDQpbICAgIDAuNTg3OTc4XSBETUEtQVBJOiBk
ZWJ1Z2dpbmcgZW5hYmxlZCBieSBrZXJuZWwgY29uZmlnDQpbICAgIDAuNTkwNDg1XSBtaWNy
b2NvZGU6IENQVTA6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYNClsgICAgMC41OTA1MTJdIG1p
Y3JvY29kZTogQ1BVMTogcGF0Y2hfbGV2ZWw9MHgwMTAwMDBiZg0KWyAgICAwLjU5MDU1NV0g
bWljcm9jb2RlOiBDUFUyOiBwYXRjaF9sZXZlbD0weDAxMDAwMGJmDQpbICAgIDAuNTkwNjMy
XSBtaWNyb2NvZGU6IENQVTM6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYNClsgICAgMC41OTA3
MjRdIG1pY3JvY29kZTogQ1BVNDogcGF0Y2hfbGV2ZWw9MHgwMTAwMDBiZg0KWyAgICAwLjU5
MDc5OV0gbWljcm9jb2RlOiBDUFU1OiBwYXRjaF9sZXZlbD0weDAxMDAwMGJmDQpbICAgIDAu
NTkwOTUyXSBtaWNyb2NvZGU6IE1pY3JvY29kZSBVcGRhdGUgRHJpdmVyOiB2Mi4wMCA8dGln
cmFuQGFpdmF6aWFuLmZzbmV0LmNvLnVrPiwgUGV0ZXIgT3J1YmENClsgICAgMC41OTE4MjNd
IEludGVsIEFFUy1OSSBpbnN0cnVjdGlvbnMgYXJlIG5vdCBkZXRlY3RlZC4NClsgICAgMC41
OTIzMzFdIGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzb2NrZXQgKGRpc2FibGVkKQ0K
WyAgICAwLjU5MjM3MV0gdHlwZT0yMDAwIGF1ZGl0KDEzMjYzNzExMTQuMDY5OjEpOiBpbml0
aWFsaXplZA0KWyAgICAwLjYxMzMyNV0gSHVnZVRMQiByZWdpc3RlcmVkIDIgTUIgcGFnZSBz
aXplLCBwcmUtYWxsb2NhdGVkIDAgcGFnZXMNClsgICAgMC42MjM1MjldIFZGUzogRGlzayBx
dW90YXMgZHF1b3RfNi41LjINClsgICAgMC42MjM3NjhdIERxdW90LWNhY2hlIGhhc2ggdGFi
bGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQ0KWyAgICAwLjYyNjQ0MV0g
TlRGUyBkcml2ZXIgMi4xLjMwIFtGbGFnczogUi9XXS4NClsgICAgMC42MjY4MTVdIGZ1c2Ug
aW5pdCAoQVBJIHZlcnNpb24gNy4xNykNClsgICAgMC42Mjg0NzFdIEJ0cmZzIGxvYWRlZA0K
WyAgICAwLjYyODQ4M10gbXNnbW5pIGhhcyBiZWVuIHNldCB0byAxODI5DQpbICAgIDAuNjI4
ODUxXSBTRUxpbnV4OiAgUmVnaXN0ZXJpbmcgbmV0ZmlsdGVyIGhvb2tzDQpbICAgIDAuNjMw
NTU5XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40
IGxvYWRlZCAobWFqb3IgMjUzKQ0KWyAgICAwLjYzMDU3NV0gaW8gc2NoZWR1bGVyIG5vb3Ag
cmVnaXN0ZXJlZA0KWyAgICAwLjYzMDU3OV0gaW8gc2NoZWR1bGVyIGRlYWRsaW5lIHJlZ2lz
dGVyZWQNClsgICAgMC42MzA3MDldIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVm
YXVsdCkNClsgICAgMC42MzA3MTVdIHN0YXJ0IHBsaXN0IHRlc3QNClsgICAgMC42MzE3MDBd
IGVuZCBwbGlzdCB0ZXN0DQpbICAgIDAuNjMxNzA0XSBsaXN0X3NvcnRfdGVzdDogc3RhcnQg
dGVzdGluZyBsaXN0X3NvcnQoKQ0KWyAgICAwLjYzNTkzNV0gcGNpX2hvdHBsdWc6IFBDSSBI
b3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUNClsgICAgMC42MzYyMzldIHBjaWVocDog
UENJIEV4cHJlc3MgSG90IFBsdWcgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjogMC40DQpb
ICAgIDAuNjM2NTQxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IHVkbGZiDQpbICAgIDAuNjM2NjUxXSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMyLCBs
aW5lbGVuZ3RoPTUxMjAsIHBhZ2VzPTANClsgICAgMC42MzY2NTddIHZlc2FmYjogc2Nyb2xs
aW5nOiByZWRyYXcNClsgICAgMC42MzY2NjFdIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTg6
ODo4OjgsIHNoaWZ0PTI0OjE2Ojg6MA0KWyAgICAwLjYzOTY0MF0gdmVzYWZiOiBmcmFtZWJ1
ZmZlciBhdCAweGZiMDAwMDAwLCBtYXBwZWQgdG8gMHhmZmZmYzkwMDEwODgwMDAwLCB1c2lu
ZyAxMDI0MGssIHRvdGFsIDE0MzM2aw0KWyAgICAwLjY2MTI3Ml0gQ29uc29sZTogc3dpdGNo
aW5nIHRvIGNvbG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDE2MHg2NA0KWyAgICAwLjY4MTcy
OV0gZmIwOiBWRVNBIFZHQSBmcmFtZSBidWZmZXIgZGV2aWNlDQpbICAgIDAuNjgyMjY4XSBp
bnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL2RldmljZTowMC9Q
TlAwQzBDOjAwL2lucHV0L2lucHV0MA0KWyAgICAwLjY4MjQ4MF0gQUNQSTogUG93ZXIgQnV0
dG9uIFtQV1JCXQ0KWyAgICAwLjY4Mjc1Nl0gaW5wdXQ6IFBvd2VyIEJ1dHRvbiBhcyAvZGV2
aWNlcy9MTlhTWVNUTTowMC9MTlhQV1JCTjowMC9pbnB1dC9pbnB1dDENClsgICAgMC42ODI5
MzldIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0NClsgICAgMC42ODc4NDhdIEV2ZW50LWNo
YW5uZWwgZGV2aWNlIGluc3RhbGxlZC4NClsgICAgMC42ODgzMDVdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDIyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuNjg4NDYyXSB4ZW46
IC0tPiBwaXJxPTIyIC0+IGlycT0yMiAoZ3NpPTIyKQ0KWyAgICAwLjY4ODY1Ml0geGVuOiBy
ZWdpc3RlcmluZyBnc2kgNDMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC42ODg4
MDZdIHhlbjogLS0+IHBpcnE9NDMgLT4gaXJxPTQzIChnc2k9NDMpDQpbICAgIDAuNjg4OTgy
XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0MyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAg
ICAwLjY4OTEzOV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA0MyBmb3IgZ3Np
IDQzDQpbICAgIDAuNjg5Mjc2XSB4ZW46IC0tPiBwaXJxPTQzIC0+IGlycT00MyAoZ3NpPTQz
KQ0KWyAgICAwLjY4OTM5OF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0Mw0KWyAgICAwLjY4
OTU0MF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDIgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
ClsgICAgMC42ODk3MTZdIHhlbjogLS0+IHBpcnE9NDIgLT4gaXJxPTQyIChnc2k9NDIpDQpb
ICAgIDAuNjg5ODkzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0MiB0cmlnZ2VyaW5nIDAgcG9s
YXJpdHkgMQ0KWyAgICAwLjY5MDA0MV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGly
cSA0MiBmb3IgZ3NpIDQyDQpbICAgIDAuNjkwMTM0XSB4ZW46IC0tPiBwaXJxPTQyIC0+IGly
cT00MiAoZ3NpPTQyKQ0KWyAgICAwLjY5MDMwOF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0
Mg0KWyAgICAwLjY5MDQ1N10geGVuOiByZWdpc3RlcmluZyBnc2kgNDEgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDENClsgICAgMC42OTA2MTBdIHhlbjogLS0+IHBpcnE9NDEgLT4gaXJxPTQx
IChnc2k9NDEpDQpbICAgIDAuNjkwNzg1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0MSB0cmln
Z2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAwLjY5MDkyN10geGVuX21hcF9waXJxX2dzaTog
cmV0dXJuaW5nIGlycSA0MSBmb3IgZ3NpIDQxDQpbICAgIDAuNjkxMDk4XSB4ZW46IC0tPiBw
aXJxPTQxIC0+IGlycT00MSAoZ3NpPTQxKQ0KWyAgICAwLjY5MTIxOF0gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDo0MQ0KWyAgICAwLjY5MTM2MV0geGVuOiByZWdpc3RlcmluZyBnc2kgNDAg
dHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC42OTE1MTZdIHhlbjogLS0+IHBpcnE9
NDAgLT4gaXJxPTQwIChnc2k9NDApDQpbICAgIDAuNjkxNjkxXSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSA0MCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAwLjY5MTgzOV0geGVuX21h
cF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA0MCBmb3IgZ3NpIDQwDQpbICAgIDAuNjkxOTgz
XSB4ZW46IC0tPiBwaXJxPTQwIC0+IGlycT00MCAoZ3NpPTQwKQ0KWyAgICAwLjY5MjEwM10g
QWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0MA0KWyAgICAwLjY5MjI0N10geGVuOiByZWdpc3Rl
cmluZyBnc2kgMzMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC42OTIzOTVdIHhl
bjogLS0+IHBpcnE9MzMgLT4gaXJxPTMzIChnc2k9MzMpDQpbICAgIDAuNjk4NzMwXSBwY2li
YWNrIDAwMDA6MDU6MDAuMDogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDMpDQpbICAg
IDAuNjk5NjgzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAzMiB0cmlnZ2VyaW5nIDAgcG9sYXJp
dHkgMQ0KWyAgICAwLjcxMTMzMl0geGVuOiAtLT4gcGlycT0zMiAtPiBpcnE9MzIgKGdzaT0z
MikNClsgICAgMC43MTc2MTRdIHBjaWJhY2sgMDAwMDowNzowMS4yOiBlbmFibGluZyBkZXZp
Y2UgKDAxMTQgLT4gMDExNikNClsgICAgMC43MTg1NzZdIHhlbjogcmVnaXN0ZXJpbmcgZ3Np
IDQ2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuNzMwMzQxXSB4ZW46IC0tPiBw
aXJxPTQ2IC0+IGlycT00NiAoZ3NpPTQ2KQ0KWyAgICAwLjczNjc1Ml0gcGNpYmFjayAwMDAw
OjA3OjAxLjE6IGVuYWJsaW5nIGRldmljZSAoMDExNCAtPiAwMTE2KQ0KWyAgICAwLjczNzcx
MV0geGVuOiByZWdpc3RlcmluZyBnc2kgNDUgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsg
ICAgMC43NDk2NzhdIHhlbjogLS0+IHBpcnE9NDUgLT4gaXJxPTQ1IChnc2k9NDUpDQpbICAg
IDAuNzU2MDYxXSBwY2liYWNrIDAwMDA6MDc6MDEuMDogZW5hYmxpbmcgZGV2aWNlICgwMTE0
IC0+IDAxMTYpDQpbICAgIDAuNzU3MDAzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0NCB0cmln
Z2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAwLjc2OTAzM10geGVuOiAtLT4gcGlycT00NCAt
PiBpcnE9NDQgKGdzaT00NCkNClsgICAgMC43NzU1NzldIHhlbjogcmVnaXN0ZXJpbmcgZ3Np
IDMxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuNzgyMTY3XSB4ZW46IC0tPiBw
aXJxPTMxIC0+IGlycT0zMSAoZ3NpPTMxKQ0KWyAgICAwLjc4ODgyMV0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMzEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC43OTU0MzhdIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMzEgZm9yIGdzaSAzMQ0KWyAgICAwLjc5
NjQzNF0geGVuOiAtLT4gcGlycT0zMSAtPiBpcnE9MzEgKGdzaT0zMSkNClsgICAgMC44MDg1
NzldIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MzENClsgICAgMC44MTUxNDNdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDMwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuODIxNjg1
XSB4ZW46IC0tPiBwaXJxPTMwIC0+IGlycT0zMCAoZ3NpPTMwKQ0KWyAgICAwLjgyODIwNl0g
eGVuOiByZWdpc3RlcmluZyBnc2kgMzAgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAg
MC44MzQ3NDBdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMzAgZm9yIGdzaSAz
MA0KWyAgICAwLjg0MTA4OF0geGVuOiAtLT4gcGlycT0zMCAtPiBpcnE9MzAgKGdzaT0zMCkN
ClsgICAgMC44NDEyNThdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MzANClsgICAgMC44NDEz
MjNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDI5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpb
ICAgIDAuODQxMzMyXSB4ZW46IC0tPiBwaXJxPTI5IC0+IGlycT0yOSAoZ3NpPTI5KQ0KWyAg
ICAwLjg0MTQyM10geGVuOiByZWdpc3RlcmluZyBnc2kgMjkgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDENClsgICAgMC44NDE0MjVdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEg
MjkgZm9yIGdzaSAyOQ0KWyAgICAwLjg0MTQyNl0geGVuOiAtLT4gcGlycT0yOSAtPiBpcnE9
MjkgKGdzaT0yOSkNClsgICAgMC44NDE0MjddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjkN
ClsgICAgMC44NDE1MDRdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDI4IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgIDAuODQxNTEyXSB4ZW46IC0tPiBwaXJxPTI4IC0+IGlycT0yOCAo
Z3NpPTI4KQ0KWyAgICAwLjg0MTU5N10geGVuOiByZWdpc3RlcmluZyBnc2kgMjggdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAgMC44NDE1OTldIHhlbl9tYXBfcGlycV9nc2k6IHJl
dHVybmluZyBpcnEgMjggZm9yIGdzaSAyOA0KWyAgICAwLjg0MTYwMF0geGVuOiAtLT4gcGly
cT0yOCAtPiBpcnE9MjggKGdzaT0yOCkNClsgICAgMC44NDE2MDJdIEFscmVhZHkgc2V0dXAg
dGhlIEdTSSA6MjgNClsgICAgMC44NDE3OTZdIHhlbi1wY2liYWNrOiBiYWNrZW5kIGlzIHBh
c3N0aHJvdWdoDQpbICAgIDAuODQzMTc1XSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0
IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVkDQpbICAgIDAuOTY4NjMzXSBocGV0X2FjcGlf
YWRkOiBubyBhZGRyZXNzIG9yIGlycXMgaW4gX0NSUw0KWyAgICAwLjk3NDk0Nl0gTm9uLXZv
bGF0aWxlIG1lbW9yeSBkcml2ZXIgdjEuMw0KWyAgICAwLjk3NTkzM10gTGludXggYWdwZ2Fy
dCBpbnRlcmZhY2UgdjAuMTAzDQpbICAgIDAuOTg5ODMwXSBbZHJtXSBJbml0aWFsaXplZCBk
cm0gMS4xLjAgMjAwNjA4MTANClsgICAgMC45OTA4MDddIFtkcm06aTkxNV9pbml0XSAqRVJS
T1IqIGRybS9pOTE1IGNhbid0IHdvcmsgd2l0aG91dCBpbnRlbF9hZ3AgbW9kdWxlIQ0KWyAg
ICAxLjAwMjEzNl0gaTJjLWNvcmU6IGRyaXZlciBbY2g3MDA2XSB1c2luZyBsZWdhY3kgc3Vz
cGVuZCBtZXRob2QNClsgICAgMS4wMDMxMzFdIGkyYy1jb3JlOiBkcml2ZXIgW2NoNzAwNl0g
dXNpbmcgbGVnYWN5IHJlc3VtZSBtZXRob2QNClsgICAgMS4wMTkyNjddIGJyZDogbW9kdWxl
IGxvYWRlZA0KWyAgICAxLjA0MTcxNF0gbG9vcDogbW9kdWxlIGxvYWRlZA0KWyAgICAxLjA0
OTI2MV0gYWhjaSAwMDAwOjAwOjExLjA6IHZlcnNpb24gMy4wDQpbICAgIDEuMDUwMjQ1XSB4
ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAx
LjA2MTQyOF0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkNClsgICAgMS4w
Njc2OTBdIGFoY2kgMDAwMDowMDoxMS4wOiBBSENJIDAwMDEuMDIwMCAzMiBzbG90cyA2IHBv
cnRzIDYgR2JwcyAweDNmIGltcGwgU0FUQSBtb2RlDQpbICAgIDEuMDczOTEzXSBhaGNpIDAw
MDA6MDA6MTEuMDogZmxhZ3M6IDY0Yml0IG5jcSBzbnRmIGlsY2sgcG0gbGVkIGNsbyBwbXAg
cGlvIHNsdW0gcGFydCANClsgICAgMS4wODMxNjBdIHNjc2kwIDogYWhjaQ0KWyAgICAxLjA4
OTczMF0gc2NzaTEgOiBhaGNpDQpbICAgIDEuMDk2MTg1XSBzY3NpMiA6IGFoY2kNClsgICAg
MS4xMDI2MzVdIHNjc2kzIDogYWhjaQ0KWyAgICAxLjEwODkxM10gc2NzaTQgOiBhaGNpDQpb
ICAgIDEuMTE1MDg2XSBzY3NpNSA6IGFoY2kNClsgICAgMS4xMjEzMzFdIGF0YTE6IFNBVEEg
bWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmOThmZjAwMCBwb3J0IDB4Zjk4ZmYxMDAgaXJx
IDM0Mg0KWyAgICAxLjEyMjI3NV0gYXRhMjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAy
NEAweGY5OGZmMDAwIHBvcnQgMHhmOThmZjE4MCBpcnEgMzQyDQpbICAgIDEuMTIyMjc1XSBh
dGEzOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4Zjk4ZmYwMDAgcG9ydCAweGY5
OGZmMjAwIGlycSAzNDINClsgICAgMS4xMjIyNzVdIGF0YTQ6IFNBVEEgbWF4IFVETUEvMTMz
IGFiYXIgbTEwMjRAMHhmOThmZjAwMCBwb3J0IDB4Zjk4ZmYyODAgaXJxIDM0Mg0KWyAgICAx
LjEyMjI3NV0gYXRhNTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGY5OGZmMDAw
IHBvcnQgMHhmOThmZjMwMCBpcnEgMzQyDQpbICAgIDEuMTIyMjc1XSBhdGE2OiBTQVRBIG1h
eCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4Zjk4ZmYwMDAgcG9ydCAweGY5OGZmMzgwIGlycSAz
NDINClsgICAgMS4xNTYyMzldIHR1bjogVW5pdmVyc2FsIFRVTi9UQVAgZGV2aWNlIGRyaXZl
ciwgMS42DQpbICAgIDEuMTU3MjM0XSB0dW46IChDKSAxOTk5LTIwMDQgTWF4IEtyYXNueWFu
c2t5IDxtYXhrQHF1YWxjb21tLmNvbT4NClsgICAgMS4xNjcyOTZdIGUxMDAwOiBJbnRlbChS
KSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gNy4zLjIxLWs4LU5BUEkNClsg
ICAgMS4xNjgyODhdIGUxMDAwOiBDb3B5cmlnaHQgKGMpIDE5OTktMjAwNiBJbnRlbCBDb3Jw
b3JhdGlvbi4NClsgICAgMS4xNzgyNThdIHNreTI6IGRyaXZlciB2ZXJzaW9uIDEuMzANClsg
ICAgMS4xODQwMzJdIHI4MTY5IEdpZ2FiaXQgRXRoZXJuZXQgZHJpdmVyIDIuM0xLLU5BUEkg
bG9hZGVkDQpbICAgIDEuMTg1MDE5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0NiB0cmlnZ2Vy
aW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAxLjE5NDg5OV0geGVuX21hcF9waXJxX2dzaTogcmV0
dXJuaW5nIGlycSA0NiBmb3IgZ3NpIDQ2DQpbICAgIDEuMTk1ODg5XSB4ZW46IC0tPiBwaXJx
PTQ2IC0+IGlycT00NiAoZ3NpPTQ2KQ0KWyAgICAxLjIwNTcyMV0gQWxyZWFkeSBzZXR1cCB0
aGUgR1NJIDo0Ng0KWyAgICAxLjIxMjE0Ml0gcjgxNjkgMDAwMDowOTowMC4wOiBldGgwOiBS
VEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMDAxZjgwMDAsIDQwOjYxOjg2OmY0OjY3OmQ5
LCBYSUQgMDgxMDAwYzAgSVJRIDM0Mw0KWyAgICAxLjIxMzA2MV0gcjgxNjkgMDAwMDowOTow
MC4wOiBldGgwOiBqdW1ibyBmZWF0dXJlcyBbZnJhbWVzOiA5MjAwIGJ5dGVzLCB0eCBjaGVj
a3N1bW1pbmc6IGtvXQ0KWyAgICAxLjIyMzY4M10gcjgxNjkgR2lnYWJpdCBFdGhlcm5ldCBk
cml2ZXIgMi4zTEstTkFQSSBsb2FkZWQNClsgICAgMS4yMjkzNjJdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDUxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDEuMjM1MDU4XSB4ZW46
IC0tPiBwaXJxPTUxIC0+IGlycT01MSAoZ3NpPTUxKQ0KWyAgICAxLjI0MTgwMl0gcjgxNjkg
MDAwMDowODowMC4wOiBldGgxOiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMDAxZmEw
MDAsIDQwOjYxOjg2OmY0OjY3OmQ4LCBYSUQgMDgxMDAwYzAgSVJRIDM0NA0KWyAgICAxLjI0
MjI3OF0gcjgxNjkgMDAwMDowODowMC4wOiBldGgxOiBqdW1ibyBmZWF0dXJlcyBbZnJhbWVz
OiA5MjAwIGJ5dGVzLCB0eCBjaGVja3N1bW1pbmc6IGtvXQ0KWyAgICAxLjI1NTEyOV0gZWhj
aV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENvbnRyb2xsZXIgKEVIQ0kpIERyaXZl
cg0KWyAgICAxLjI1NjA5OV0gZWhjaV9oY2Q6IGJsb2NrIHNpemVzOiBxaCAxMTIgcXRkIDk2
IGl0ZCAxOTIgc2l0ZCA5Ng0KWyAgICAxLjI2NzMzMl0geGVuOiByZWdpc3RlcmluZyBnc2kg
MTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS4yNzMzNTddIHhlbjogLS0+IHBp
cnE9MTcgLT4gaXJxPTE3IChnc2k9MTcpDQpbICAgIDEuMjc5Mzk4XSBlaGNpX2hjZCAwMDAw
OjAwOjEyLjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDEuMjg1NDg5XSBkcml2ZXJz
L3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5nIGZpbGUgJ2RldmljZXMnDQpbICAgIDEuMjg2
NDY0XSBkcml2ZXJzL3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5nIGZpbGUgJzAwMScNClsg
ICAgMS4yOTc4MDNdIGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogbmV3IFVTQiBidXMgcmVnaXN0
ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQpbICAgIDEuMjk4Nzg2XSBlaGNpX2hjZCAw
MDAwOjAwOjEyLjI6IHJlc2V0IGhjc19wYXJhbXMgMHgxMDE1MDUgZGJnPTEgY2M9MSBwY2M9
NSBvcmRlcmVkICFwcGMgcG9ydHM9NQ0KWyAgICAxLjI5ODc4Nl0gZWhjaV9oY2QgMDAwMDow
MDoxMi4yOiByZXNldCBoY2NfcGFyYW1zIGEwNzIgdGhyZXNoIDcgdWZyYW1lcyAyNTYvNTEy
LzEwMjQNClsgICAgMS4zMTYzMTJdIGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogYXBwbHlpbmcg
QU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQpb
ICAgIDEuMzIyNzUxXSBRVUlSSzogRW5hYmxlIEFNRCBQTEwgZml4DQpbICAgIDEuMzIzNjU4
XSBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IGRlYnVnIHBvcnQgMQ0KWyAgICAxLjMyMzY1OF0g
ZWhjaV9oY2QgMDAwMDowMDoxMi4yOiByZXNldCBjb21tYW5kIDAwODAwMDIgKHBhcmspPTAg
aXRocmVzaD04IHBlcmlvZD0xMDI0IFJlc2V0IEhBTFQNClsgICAgMS4zMjM2NThdIGVoY2lf
aGNkIDAwMDA6MDA6MTIuMjogTVdJIGFjdGl2ZQ0KWyAgICAxLjMyMzY1OF0gZWhjaV9oY2Qg
MDAwMDowMDoxMi4yOiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAgICAxLjM1NDEy
NF0gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBpcnEgMTcsIGlvIG1lbSAweGY5OGZmNDAwDQpb
ICAgIDEuMzU1MDg0XSBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IGluaXQgY29tbWFuZCAwMDEw
MDA1IChwYXJrKT0wIGl0aHJlc2g9MSBwZXJpb2Q9NTEyIFJVTg0KWyAgICAxLjM3MzA4Ml0g
ZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAg
ICAxLjM3OTQ5OF0gdXNiIHVzYjE6IGRlZmF1bHQgbGFuZ3VhZ2UgMHgwNDA5DQpbICAgIDEu
Mzg1NzY0XSB1c2IgdXNiMTogdWRldiAxLCBidXNudW0gMSwgbWlub3IgPSAwDQpbICAgIDEu
Mzg2NzE0XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAyDQpbICAgIDEuMzg2NzE0XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMS4z
ODY3MTRdIHVzYiB1c2IxOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAx
LjM4NjcxNF0gdXNiIHVzYjE6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMwKyBlaGNp
X2hjZA0KWyAgICAxLjM4NjcxNF0gdXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDox
Mi4yDQpbICAgIDEuNDIzNTM4XSB1c2IgdXNiMTogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAx
LjQyNDUyNF0gdXNiIHVzYjE6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9p
Y2UNClsgICAgMS40MzU5NTddIHVzYiB1c2IxOiBhZGRpbmcgMS0wOjEuMCAoY29uZmlnICMx
LCBpbnRlcmZhY2UgMCkNClsgICAgMS40NDIyNjBdIGh1YiAxLTA6MS4wOiB1c2JfcHJvYmVf
aW50ZXJmYWNlDQpbICAgIDEuNDQzMjE2XSBodWIgMS0wOjEuMDogdXNiX3Byb2JlX2ludGVy
ZmFjZSAtIGdvdCBpZA0KWyAgICAxLjQ0MzIxNl0gaHViIDEtMDoxLjA6IFVTQiBodWIgZm91
bmQNClsgICAgMS40NjAxOTBdIGF0YTI6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0Nv
bnRyb2wgMzAwKQ0KWyAgICAxLjQ2MDI1NV0gYXRhNDogU0FUQSBsaW5rIGRvd24gKFNTdGF0
dXMgMCBTQ29udHJvbCAzMDApDQpbICAgIDEuNDYwMzI0XSBhdGE1OiBTQVRBIGxpbmsgZG93
biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkNClsgICAgMS40NjAzNjhdIGF0YTY6IFNBVEEg
bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KWyAgICAxLjQ4NTE4N10gaHVi
IDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMS40ODYxNjldIGh1YiAxLTA6MS4w
OiBzdGFuZGFsb25lIGh1Yg0KWyAgICAxLjQ4NjE2OV0gaHViIDEtMDoxLjA6IG5vIHBvd2Vy
IHN3aXRjaGluZyAodXNiIDEuMCkNClsgICAgMS40ODYxNjldIGh1YiAxLTA6MS4wOiBpbmRp
dmlkdWFsIHBvcnQgb3Zlci1jdXJyZW50IHByb3RlY3Rpb24NClsgICAgMS40ODYxNjldIGh1
YiAxLTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRpbWU6IDIwbXMNClsgICAgMS41
MTYzODddIGh1YiAxLTA6MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAx
LjUxNzM2Ml0gaHViIDEtMDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBu
b24tc3dpdGNoYWJsZSBodWINClsgICAgMS41MjkxMTFdIGRyaXZlcnMvdXNiL2NvcmUvaW5v
ZGUuYzogY3JlYXRpbmcgZmlsZSAnMDAxJw0KWyAgICAxLjUzNTcwNF0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS41NDE5NjhdIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNw0KWyAgICAxLjU0
Mjk2MF0geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTcgKGdzaT0xNykNClsgICAgMS41NTQ1
MjldIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcNClsgICAgMS41NjA3NDBdIGVoY2lfaGNk
IDAwMDA6MDA6MTMuMjogRUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS41NjcwMDRdIGRy
aXZlcnMvdXNiL2NvcmUvaW5vZGUuYzogY3JlYXRpbmcgZmlsZSAnMDAyJw0KWyAgICAxLjU3
MzQ2MF0gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBh
c3NpZ25lZCBidXMgbnVtYmVyIDINClsgICAgMS41NzQ0MzddIGVoY2lfaGNkIDAwMDA6MDA6
MTMuMjogcmVzZXQgaGNzX3BhcmFtcyAweDEwMTUwNSBkYmc9MSBjYz0xIHBjYz01IG9yZGVy
ZWQgIXBwYyBwb3J0cz01DQpbICAgIDEuNTg2MTk3XSBlaGNpX2hjZCAwMDAwOjAwOjEzLjI6
IHJlc2V0IGhjY19wYXJhbXMgYTA3MiB0aHJlc2ggNyB1ZnJhbWVzIDI1Ni81MTIvMTAyNA0K
WyAgICAxLjU4NzE4Nl0gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBhcHBseWluZyBBTUQgU0I3
MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmthcm91bmQNClsgICAgMS41
ODcxODZdIGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogZGVidWcgcG9ydCAxDQpbICAgIDEuNTg3
MTg2XSBlaGNpX2hjZCAwMDAwOjAwOjEzLjI6IHJlc2V0IGNvbW1hbmQgMDA4MDAwMiAocGFy
ayk9MCBpdGhyZXNoPTggcGVyaW9kPTEwMjQgUmVzZXQgSEFMVA0KWyAgICAxLjYxMTI2MV0g
ZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBNV0kgYWN0aXZlDQpbICAgIDEuNjE1MTIyXSBhdGEz
OiBTQVRBIGxpbmsgdXAgNi4wIEdicHMgKFNTdGF0dXMgMTMzIFNDb250cm9sIDMwMCkNClsg
ICAgMS42MTUxNjhdIGF0YTE6IFNBVEEgbGluayB1cCAzLjAgR2JwcyAoU1N0YXR1cyAxMjMg
U0NvbnRyb2wgMzAwKQ0KWyAgICAxLjYxMjIzMl0gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBz
dXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAgICAxLjYzNTMwN10gZWhjaV9oY2QgMDAw
MDowMDoxMy4yOiBpcnEgMTcsIGlvIG1lbSAweGY5OGZmODAwDQpbICAgIDEuNjQwMTEzXSBl
aGNpX2hjZCAwMDAwOjAwOjEzLjI6IGluaXQgY29tbWFuZCAwMDEwMDA1IChwYXJrKT0wIGl0
aHJlc2g9MSBwZXJpb2Q9NTEyIFJVTg0KWyAgICAxLjY0MTIxNl0gYXRhMy4wMDogQVRBLTg6
IFNUMjAwMERMMDAzLTlWVDE2NiwgQ0M0NSwgbWF4IFVETUEvMTMzDQpbICAgIDEuNjQxMjE5
XSBhdGEzLjAwOiAzOTA3MDI5MTY4IHNlY3RvcnMsIG11bHRpIDA6IExCQTQ4IE5DUSAoZGVw
dGggMzEvMzIpDQpbICAgIDEuNjQxMjc1XSBodWIgMS0wOjEuMDogc3RhdGUgNyBwb3J0cyA1
IGNoZyAwMDAwIGV2dCAwMDAwDQpbICAgIDEuNjQxNDAyXSBhdGExLjAwOiBBVEEtODogSGl0
YWNoaSBIRFM3MjIwMjBBTEEzMzAsIEpLQU9BMjBOLCBtYXggVURNQS8xMzMNClsgICAgMS42
NDE0MDRdIGF0YTEuMDA6IDM5MDcwMjkxNjggc2VjdG9ycywgbXVsdGkgMDogTEJBNDggTkNR
IChkZXB0aCAzMS8zMiksIEFBDQpbICAgIDEuNjQyMDMyXSBhdGEzLjAwOiBjb25maWd1cmVk
IGZvciBVRE1BLzEzMw0KWyAgICAxLjY0MjkzMl0gYXRhMS4wMDogY29uZmlndXJlZCBmb3Ig
VURNQS8xMzMNClsgICAgMS42NDMxOTldIHNjc2kgMDowOjA6MDogRGlyZWN0LUFjY2VzcyAg
ICAgQVRBICAgICAgSGl0YWNoaSBIRFM3MjIwMiBKS0FPIFBROiAwIEFOU0k6IDUNClsgICAg
MS42NDM3NDJdIHNkIDA6MDowOjA6IFtzZGFdIDM5MDcwMjkxNjggNTEyLWJ5dGUgbG9naWNh
bCBibG9ja3M6ICgyLjAwIFRCLzEuODEgVGlCKQ0KWyAgICAxLjY0Mzg1NF0gc2QgMDowOjA6
MDogW3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYNClsgICAgMS42NDM4NTldIHNkIDA6MDow
OjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpbICAgIDEuNjQzOTMyXSBzZCAw
OjA6MDowOiBbc2RhXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxl
ZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUENClsgICAgMS42NDgwNzldIGVoY2lfaGNk
IDAwMDA6MDA6MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDANClsgICAgMS42NDgx
NThdIHVzYiB1c2IyOiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQwOQ0KWyAgICAxLjY0ODE3MF0g
dXNiIHVzYjI6IHVkZXYgMSwgYnVzbnVtIDIsIG1pbm9yID0gMTI4DQpbICAgIDEuNjQ4MTcx
XSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJv
ZHVjdD0wMDAyDQpbICAgIDEuNjQ4MTczXSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ugc3Ry
aW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMS42NDgxNzRd
IHVzYiB1c2IyOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAxLjY0ODE3
Nl0gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMwKyBlaGNpX2hjZA0K
WyAgICAxLjY0ODE3N10gdXNiIHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4yDQpb
ICAgIDEuNzU3MTc2XSB1c2IgdXNiMjogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAxLjc1NzI1
OF0gc2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMCB0eXBlIDANClsgICAg
MS43NTc1OTNdIHNjc2kgMjowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgU1Qy
MDAwREwwMDMtOVZUMSBDQzQ1IFBROiAwIEFOU0k6IDUNClsgICAgMS43NTgwOThdIHNkIDI6
MDowOjA6IFtzZGJdIDM5MDcwMjkxNjggNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICgyLjAw
IFRCLzEuODEgVGlCKQ0KWyAgICAxLjc1ODEwMF0gc2QgMjowOjA6MDogW3NkYl0gNDA5Ni1i
eXRlIHBoeXNpY2FsIGJsb2Nrcw0KWyAgICAxLjc1ODIxNV0gc2QgMjowOjA6MDogW3NkYl0g
V3JpdGUgUHJvdGVjdCBpcyBvZmYNClsgICAgMS43NTgyMTddIHNkIDI6MDowOjA6IFtzZGJd
IE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpbICAgIDEuNzU4MjYzXSBzZCAyOjA6MDowOiBb
c2RiXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24n
dCBzdXBwb3J0IERQTyBvciBGVUENClsgICAgMS43NTkxNjBdIHNkIDI6MDowOjA6IEF0dGFj
aGVkIHNjc2kgZ2VuZXJpYyBzZzEgdHlwZSAwDQpbICAgIDEuNzU4NTk2XSB1c2IgdXNiMjog
Y29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KWyAgICAxLjgxOTY1NV0g
dXNiIHVzYjI6IGFkZGluZyAyLTA6MS4wIChjb25maWcgIzEsIGludGVyZmFjZSAwKQ0KWyAg
ICAxLjgxOTcxN10gIHNkYjogc2RiMQ0KWyAgICAxLjgxOTczNV0gIHNkYTogc2RhMSBzZGEy
IHNkYTMNClsgICAgMS44Mzk4NjVdIGh1YiAyLTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNl
DQpbICAgIDEuODQwNTI3XSBzZCAyOjA6MDowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJIGRpc2sN
ClsgICAgMS44NDA2MjBdIHNkIDA6MDowOjA6IFtzZGFdIEF0dGFjaGVkIFNDU0kgZGlzaw0K
WyAgICAxLjg1OTExOF0gaHViIDItMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3Qg
aWQNClsgICAgMS44NTkxMThdIGh1YiAyLTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDEu
ODU5NTI3XSBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICAxLjg1OTUyOV0g
aHViIDItMDoxLjA6IHN0YW5kYWxvbmUgaHViDQpbICAgIDEuODU5NTMwXSBodWIgMi0wOjEu
MDogbm8gcG93ZXIgc3dpdGNoaW5nICh1c2IgMS4wKQ0KWyAgICAxLjg1OTUzMl0gaHViIDIt
MDoxLjA6IGluZGl2aWR1YWwgcG9ydCBvdmVyLWN1cnJlbnQgcHJvdGVjdGlvbg0KWyAgICAx
Ljg1OTUzM10gaHViIDItMDoxLjA6IHBvd2VyIG9uIHRvIHBvd2VyIGdvb2QgdGltZTogMjBt
cw0KWyAgICAxLjg1OTU0M10gaHViIDItMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJjZSBpcyBn
b29kDQpbICAgIDEuODU5NTQ1XSBodWIgMi0wOjEuMDogdHJ5aW5nIHRvIGVuYWJsZSBwb3J0
IHBvd2VyIG9uIG5vbi1zd2l0Y2hhYmxlIGh1Yg0KWyAgICAxLjg1OTYyMF0gZHJpdmVycy91
c2IvY29yZS9pbm9kZS5jOiBjcmVhdGluZyBmaWxlICcwMDEnDQpbICAgIDEuODU5OTMwXSB4
ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAx
Ljg1OTkzNV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNyBmb3IgZ3NpIDE3
DQpbICAgIDEuODU5OTM3XSB4ZW46IC0tPiBwaXJxPTE3IC0+IGlycT0xNyAoZ3NpPTE3KQ0K
WyAgICAxLjg1OTkzOV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNw0KWyAgICAxLjg2MDAx
M10gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAx
Ljg2MDAyNV0gZHJpdmVycy91c2IvY29yZS9pbm9kZS5jOiBjcmVhdGluZyBmaWxlICcwMDMn
DQpbICAgIDEuODYwNDMzXSBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IG5ldyBVU0IgYnVzIHJl
Z2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMw0KWyAgICAxLjg2MDQ0MV0gZWhjaV9o
Y2QgMDAwMDowMDoxNi4yOiByZXNldCBoY3NfcGFyYW1zIDB4MTAxNDA0IGRiZz0xIGNjPTEg
cGNjPTQgb3JkZXJlZCAhcHBjIHBvcnRzPTQNClsgICAgMS44NjA0NDRdIGVoY2lfaGNkIDAw
MDA6MDA6MTYuMjogcmVzZXQgaGNjX3BhcmFtcyBhMDcyIHRocmVzaCA3IHVmcmFtZXMgMjU2
LzUxMi8xMDI0DQpbICAgIDEuODYwNDQ5XSBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGFwcGx5
aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3Vu
ZA0KWyAgICAxLjg2MDUzN10gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBkZWJ1ZyBwb3J0IDEN
ClsgICAgMS44NjA1NDJdIGVoY2lfaGNkIDAwMDA6MDA6MTYuMjogcmVzZXQgY29tbWFuZCAw
MDgwMDAyIChwYXJrKT0wIGl0aHJlc2g9OCBwZXJpb2Q9MTAyNCBSZXNldCBIQUxUDQpbICAg
IDEuODYwNTY1XSBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IE1XSSBhY3RpdmUNClsgICAgMS44
NjA1NjZdIGVoY2lfaGNkIDAwMDA6MDA6MTYuMjogc3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtl
dXANClsgICAgMS44NjA1NzVdIGVoY2lfaGNkIDAwMDA6MDA6MTYuMjogaXJxIDE3LCBpbyBt
ZW0gMHhmOThmZmMwMA0KWyAgICAxLjg2MDU3OV0gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBp
bml0IGNvbW1hbmQgMDAxMDAwNSAocGFyayk9MCBpdGhyZXNoPTEgcGVyaW9kPTUxMiBSVU4N
ClsgICAgMS44NjcwOTZdIGVoY2lfaGNkIDAwMDA6MDA6MTYuMjogVVNCIDIuMCBzdGFydGVk
LCBFSENJIDEuMDANClsgICAgMS44NjcxNjldIHVzYiB1c2IzOiBkZWZhdWx0IGxhbmd1YWdl
IDB4MDQwOQ0KWyAgICAxLjg2NzE4Ml0gdXNiIHVzYjM6IHVkZXYgMSwgYnVzbnVtIDMsIG1p
bm9yID0gMjU2DQpbICAgIDEuODY3MTg0XSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2UgZm91
bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyDQpbICAgIDEuODY3MTg1XSB1c2Ig
dXNiMzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFs
TnVtYmVyPTENClsgICAgMS44NjcxODddIHVzYiB1c2IzOiBQcm9kdWN0OiBFSENJIEhvc3Qg
Q29udHJvbGxlcg0KWyAgICAxLjg2NzE4OV0gdXNiIHVzYjM6IE1hbnVmYWN0dXJlcjogTGlu
dXggMy4yLjAtcmMwKyBlaGNpX2hjZA0KWyAgICAxLjg2NzE5MF0gdXNiIHVzYjM6IFNlcmlh
bE51bWJlcjogMDAwMDowMDoxNi4yDQpbICAgIDEuODY3MzkxXSB1c2IgdXNiMzogdXNiX3By
b2JlX2RldmljZQ0KWyAgICAxLjg2NzM5M10gdXNiIHVzYjM6IGNvbmZpZ3VyYXRpb24gIzEg
Y2hvc2VuIGZyb20gMSBjaG9pY2UNClsgICAgMS44Njc0MTNdIHVzYiB1c2IzOiBhZGRpbmcg
My0wOjEuMCAoY29uZmlnICMxLCBpbnRlcmZhY2UgMCkNClsgICAgMS44Njc1MzVdIGh1YiAz
LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlDQpbICAgIDEuODY3NTM3XSBodWIgMy0wOjEu
MDogdXNiX3Byb2JlX2ludGVyZmFjZSAtIGdvdCBpZA0KWyAgICAxLjg2NzUzOF0gaHViIDMt
MDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgMS44Njc1NDVdIGh1YiAzLTA6MS4wOiA0IHBv
cnRzIGRldGVjdGVkDQpbICAgIDEuODY3NTQ2XSBodWIgMy0wOjEuMDogc3RhbmRhbG9uZSBo
dWINClsgICAgMS44Njc1NDddIGh1YiAzLTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcgKHVz
YiAxLjApDQpbICAgIDEuODY3NTQ5XSBodWIgMy0wOjEuMDogaW5kaXZpZHVhbCBwb3J0IG92
ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDEuODY3NTUwXSBodWIgMy0wOjEuMDogcG93
ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiAyMG1zDQpbICAgIDEuODY3NTU5XSBodWIgMy0w
OjEuMDogbG9jYWwgcG93ZXIgc291cmNlIGlzIGdvb2QNClsgICAgMS44Njc1NjFdIGh1YiAz
LTA6MS4wOiB0cnlpbmcgdG8gZW5hYmxlIHBvcnQgcG93ZXIgb24gbm9uLXN3aXRjaGFibGUg
aHViDQpbICAgIDEuODY3NjE4XSBkcml2ZXJzL3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5n
IGZpbGUgJzAwMScNClsgICAgMS44NjgwNDhdIG9oY2lfaGNkOiBVU0IgMS4xICdPcGVuJyBI
b3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlcg0KWyAgICAxLjg2ODA1MV0gb2hjaV9oY2Q6
IGJsb2NrIHNpemVzOiBlZCA4MCB0ZCA5Ng0KWyAgICAxLjg2ODE2OF0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS44NjgxOTJdIHhl
bjogLS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpDQpbICAgIDEuODY4MjI4XSBvaGNp
X2hjZCAwMDAwOjAwOjEyLjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDEuODY4MjQ0
XSBkcml2ZXJzL3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5nIGZpbGUgJzAwNCcNClsgICAg
MS44Njg2NTddIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJl
ZCwgYXNzaWduZWQgYnVzIG51bWJlciA0DQpbICAgIDEuODY4NjcyXSBvaGNpX2hjZCAwMDAw
OjAwOjEyLjA6IGVuYWJsZWQgQU1EIHByZWZldGNoIHF1aXJrDQpbICAgIDEuODY4NzQxXSBv
aGNpX2hjZCAwMDAwOjAwOjEyLjA6IGNyZWF0ZWQgZGVidWcgZmlsZXMNClsgICAgMS44Njg3
NDNdIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogc3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtldXAN
ClsgICAgMS44Njg4MDJdIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogaXJxIDE4LCBpbyBtZW0g
MHhmOThmYjAwMA0KWyAgICAxLjkyNDIwNl0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBPSENJ
IGNvbnRyb2xsZXIgc3RhdGUNClsgICAgMS45MjQyMTNdIG9oY2lfaGNkIDAwMDA6MDA6MTIu
MDogT0hDSSAxLjAsIE5PIGxlZ2FjeSBzdXBwb3J0IHJlZ2lzdGVycywgcmggc3RhdGUgcnVu
bmluZw0KWyAgICAxLjkyNDIxN10gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBjb250cm9sIDB4
MjgzIFJXQyBIQ0ZTPW9wZXJhdGlvbmFsIENCU1I9Mw0KWyAgICAxLjkyNDIyMF0gb2hjaV9o
Y2QgMDAwMDowMDoxMi4wOiBjbWRzdGF0dXMgMHgwMDAwMCBTT0M9MA0KWyAgICAxLjkyNDIy
NF0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBpbnRyc3RhdHVzIDB4MDAwMDAwMDQgU0YNClsg
ICAgMS45MjQyMjddIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogaW50cmVuYWJsZSAweDgwMDAw
MDVhIE1JRSBSSFNDIFVFIFJEIFdESA0KWyAgICAxLjkyNDIzN10gb2hjaV9oY2QgMDAwMDow
MDoxMi4wOiBoY2NhIGZyYW1lICMwMDA1DQpbICAgIDEuOTI0MjQxXSBvaGNpX2hjZCAwMDAw
OjAwOjEyLjA6IHJvb3RodWIuYSAwMjAwMTIwNSBQT1RQR1Q9MiBOT0NQIE5QUyBORFA9NSg1
KQ0KWyAgICAxLjkyNDI1N10gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiByb290aHViLmIgMDAw
MDAwMDAgUFBDTT0wMDAwIERSPTAwMDANClsgICAgMS45MjQyNjBdIG9oY2lfaGNkIDAwMDA6
MDA6MTIuMDogcm9vdGh1Yi5zdGF0dXMgMDAwMDgwMDAgRFJXRQ0KWyAgICAxLjkyNDI2NF0g
b2hjaV9oY2QgMDAwMDowMDoxMi4wOiByb290aHViLnBvcnRzdGF0dXMgWzBdIDB4MDAwMDAx
MDAgUFBTDQpbICAgIDEuOTI0MjY3XSBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IHJvb3RodWIu
cG9ydHN0YXR1cyBbMV0gMHgwMDAwMDEwMCBQUFMNClsgICAgMS45MjQyNzFdIG9oY2lfaGNk
IDAwMDA6MDA6MTIuMDogcm9vdGh1Yi5wb3J0c3RhdHVzIFsyXSAweDAwMDAwMTAwIFBQUw0K
WyAgICAxLjkyNDI3NF0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiByb290aHViLnBvcnRzdGF0
dXMgWzNdIDB4MDAwMDAxMDAgUFBTDQpbICAgIDEuOTI0Mjc4XSBvaGNpX2hjZCAwMDAwOjAw
OjEyLjA6IHJvb3RodWIucG9ydHN0YXR1cyBbNF0gMHgwMDAwMDEwMCBQUFMNClsgICAgMS45
MjQzMDBdIHVzYiB1c2I0OiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQwOQ0KWyAgICAxLjkyNDMx
Ml0gdXNiIHVzYjQ6IHVkZXYgMSwgYnVzbnVtIDQsIG1pbm9yID0gMzg0DQpbICAgIDEuOTI0
MzE0XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlk
UHJvZHVjdD0wMDAxDQpbICAgIDEuOTI0MzE2XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ug
c3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMS45MjQz
MTddIHVzYiB1c2I0OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAxLjky
NDMxOV0gdXNiIHVzYjQ6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMwKyBvaGNpX2hj
ZA0KWyAgICAxLjkyNDMyMF0gdXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMi4w
DQpbICAgIDEuOTI0Nzk2XSB1c2IgdXNiNDogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAxLjky
NDc5OF0gdXNiIHVzYjQ6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UN
ClsgICAgMS45MjQ4MTBdIHVzYiB1c2I0OiBhZGRpbmcgNC0wOjEuMCAoY29uZmlnICMxLCBp
bnRlcmZhY2UgMCkNClsgICAgMS45MjQ5MzFdIGh1YiA0LTA6MS4wOiB1c2JfcHJvYmVfaW50
ZXJmYWNlDQpbICAgIDEuOTI0OTMzXSBodWIgNC0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFj
ZSAtIGdvdCBpZA0KWyAgICAxLjkyNDkzNV0gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQN
ClsgICAgMS45MjQ5NTRdIGh1YiA0LTA6MS4wOiA1IHBvcnRzIGRldGVjdGVkDQpbICAgIDEu
OTI0OTU1XSBodWIgNC0wOjEuMDogc3RhbmRhbG9uZSBodWINClsgICAgMS45MjQ5NTZdIGh1
YiA0LTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcgKHVzYiAxLjApDQpbICAgIDEuOTI0OTU3
XSBodWIgNC0wOjEuMDogbm8gb3Zlci1jdXJyZW50IHByb3RlY3Rpb24NClsgICAgMS45MjQ5
NTldIGh1YiA0LTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRpbWU6IDRtcw0KWyAg
ICAxLjkyNDk2OV0gaHViIDQtMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJjZSBpcyBnb29kDQpb
ICAgIDEuOTI0OTcwXSBodWIgNC0wOjEuMDogdHJ5aW5nIHRvIGVuYWJsZSBwb3J0IHBvd2Vy
IG9uIG5vbi1zd2l0Y2hhYmxlIGh1Yg0KWyAgICAxLjkyNTAwOV0gZHJpdmVycy91c2IvY29y
ZS9pbm9kZS5jOiBjcmVhdGluZyBmaWxlICcwMDEnDQpbICAgIDEuOTI1MDkzXSBlaGNpX2hj
ZCAwMDAwOjAwOjEyLjI6IEhTIGNvbXBhbmlvbiBmb3IgMDAwMDowMDoxMi4wDQpbICAgIDEu
OTI1Mzk4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg
MQ0KWyAgICAxLjkyNTQwMl0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOCBm
b3IgZ3NpIDE4DQpbICAgIDEuOTI1NDA0XSB4ZW46IC0tPiBwaXJxPTE4IC0+IGlycT0xOCAo
Z3NpPTE4KQ0KWyAgICAxLjkyNTQwNl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAg
ICAxLjkyNTQyNV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBPSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgICAxLjkyNTQzN10gZHJpdmVycy91c2IvY29yZS9pbm9kZS5jOiBjcmVhdGluZyBm
aWxlICcwMDUnDQpbICAgIDEuOTI1NjkzXSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IG5ldyBV
U0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNQ0KWyAgICAxLjkyNTcw
NV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBlbmFibGVkIEFNRCBwcmVmZXRjaCBxdWlyaw0K
WyAgICAxLjkyNTc2OV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBjcmVhdGVkIGRlYnVnIGZp
bGVzDQpbICAgIDEuOTI1NzcxXSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IHN1cHBvcnRzIFVT
QiByZW1vdGUgd2FrZXVwDQpbICAgIDEuOTI1Nzc4XSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6
IGlycSAxOCwgaW8gbWVtIDB4Zjk4ZmMwMDANClsgICAgMS45NjAxNThdIGh1YiAyLTA6MS4w
OiBzdGF0ZSA3IHBvcnRzIDUgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS45NjgyMTldIGh1
YiAzLTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDQgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS45
ODExNjhdIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogT0hDSSBjb250cm9sbGVyIHN0YXRlDQpb
ICAgIDEuOTgxMTczXSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IE9IQ0kgMS4wLCBOTyBsZWdh
Y3kgc3VwcG9ydCByZWdpc3RlcnMsIHJoIHN0YXRlIHJ1bm5pbmcNClsgICAgMS45ODExNzdd
IG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogY29udHJvbCAweDI4MyBSV0MgSENGUz1vcGVyYXRp
b25hbCBDQlNSPTMNClsgICAgMS45ODExODBdIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogY21k
c3RhdHVzIDB4MDAwMDAgU09DPTANClsgICAgMS45ODExOTNdIG9oY2lfaGNkIDAwMDA6MDA6
MTMuMDogaW50cnN0YXR1cyAweDAwMDAwMDA0IFNGDQpbICAgIDEuOTgxMTk2XSBvaGNpX2hj
ZCAwMDAwOjAwOjEzLjA6IGludHJlbmFibGUgMHg4MDAwMDA1YSBNSUUgUkhTQyBVRSBSRCBX
REgNClsgICAgMS45ODEyMDddIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogaGNjYSBmcmFtZSAj
MDAwNQ0KWyAgICAxLjk4MTIxMV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiByb290aHViLmEg
MDIwMDEyMDUgUE9UUEdUPTIgTk9DUCBOUFMgTkRQPTUoNSkNClsgICAgMS45ODEyMTRdIG9o
Y2lfaGNkIDAwMDA6MDA6MTMuMDogcm9vdGh1Yi5iIDAwMDAwMDAwIFBQQ009MDAwMCBEUj0w
MDAwDQpbICAgIDEuOTgxMjE3XSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IHJvb3RodWIuc3Rh
dHVzIDAwMDA4MDAwIERSV0UNClsgICAgMS45ODEyMjFdIG9oY2lfaGNkIDAwMDA6MDA6MTMu
MDogcm9vdGh1Yi5wb3J0c3RhdHVzIFswXSAweDAwMDAwMTAwIFBQUw0KWyAgICAxLjk4MTIy
NF0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiByb290aHViLnBvcnRzdGF0dXMgWzFdIDB4MDAw
MDAxMDAgUFBTDQpbICAgIDEuOTgxMjI3XSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IHJvb3Ro
dWIucG9ydHN0YXR1cyBbMl0gMHgwMDAwMDEwMCBQUFMNClsgICAgMS45ODEyMzFdIG9oY2lf
aGNkIDAwMDA6MDA6MTMuMDogcm9vdGh1Yi5wb3J0c3RhdHVzIFszXSAweDAwMDAwMTAwIFBQ
Uw0KWyAgICAxLjk4MTIzNF0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiByb290aHViLnBvcnRz
dGF0dXMgWzRdIDB4MDAwMDAxMDAgUFBTDQpbICAgIDEuOTgxMjU2XSB1c2IgdXNiNTogZGVm
YXVsdCBsYW5ndWFnZSAweDA0MDkNClsgICAgMS45ODEyNzldIHVzYiB1c2I1OiB1ZGV2IDEs
IGJ1c251bSA1LCBtaW5vciA9IDUxMg0KWyAgICAxLjk4MTI4MV0gdXNiIHVzYjU6IE5ldyBV
U0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICAx
Ljk4MTI4Ml0gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9k
dWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDEuOTgxMjg0XSB1c2IgdXNiNTogUHJvZHVj
dDogT0hDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS45ODEyODVdIHVzYiB1c2I1OiBNYW51
ZmFjdHVyZXI6IExpbnV4IDMuMi4wLXJjMCsgb2hjaV9oY2QNClsgICAgMS45ODEyODddIHVz
YiB1c2I1OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTMuMA0KWyAgICAxLjk4MTYyOV0gdXNi
IHVzYjU6IHVzYl9wcm9iZV9kZXZpY2UNClsgICAgMS45ODE2MzFdIHVzYiB1c2I1OiBjb25m
aWd1cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpbICAgIDEuOTgxNjQxXSB1c2Ig
dXNiNTogYWRkaW5nIDUtMDoxLjAgKGNvbmZpZyAjMSwgaW50ZXJmYWNlIDApDQpbICAgIDEu
OTgxNzg2XSBodWIgNS0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZQ0KWyAgICAxLjk4MTc4
OF0gaHViIDUtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3QgaWQNClsgICAgMS45
ODE3OTldIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDEuOTgxODA4XSBodWIg
NS0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICAxLjk4MTgwOV0gaHViIDUtMDoxLjA6
IHN0YW5kYWxvbmUgaHViDQpbICAgIDEuOTgxODEwXSBodWIgNS0wOjEuMDogbm8gcG93ZXIg
c3dpdGNoaW5nICh1c2IgMS4wKQ0KWyAgICAxLjk4MTgxMl0gaHViIDUtMDoxLjA6IG5vIG92
ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDEuOTgxODEzXSBodWIgNS0wOjEuMDogcG93
ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiA0bXMNClsgICAgMS45ODE4MjNdIGh1YiA1LTA6
MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAxLjk4MTgyNV0gaHViIDUt
MDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJsZSBo
dWINClsgICAgMS45ODE4NjZdIGRyaXZlcnMvdXNiL2NvcmUvaW5vZGUuYzogY3JlYXRpbmcg
ZmlsZSAnMDAxJw0KWyAgICAxLjk4MTkzM10gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBIUyBj
b21wYW5pb24gZm9yIDAwMDA6MDA6MTMuMA0KWyAgICAxLjk4MjI5NV0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS45ODIyOTldIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOA0KWyAgICAxLjk4
MjMwMV0geGVuOiAtLT4gcGlycT0xOCAtPiBpcnE9MTggKGdzaT0xOCkNClsgICAgMS45ODIz
MDJdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAgMS45ODIzMjldIG9oY2lfaGNk
IDAwMDA6MDA6MTQuNTogT0hDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS45ODIzMzhdIGRy
aXZlcnMvdXNiL2NvcmUvaW5vZGUuYzogY3JlYXRpbmcgZmlsZSAnMDA2Jw0KWyAgICAxLjk4
Mjc2N10gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBh
c3NpZ25lZCBidXMgbnVtYmVyIDYNClsgICAgMS45ODI3NzldIG9oY2lfaGNkIDAwMDA6MDA6
MTQuNTogZW5hYmxlZCBBTUQgcHJlZmV0Y2ggcXVpcmsNClsgICAgMS45ODI4NTJdIG9oY2lf
aGNkIDAwMDA6MDA6MTQuNTogY3JlYXRlZCBkZWJ1ZyBmaWxlcw0KWyAgICAxLjk4Mjg1NF0g
b2hjaV9oY2QgMDAwMDowMDoxNC41OiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAg
ICAxLjk4Mjg2MV0gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBpcnEgMTgsIGlvIG1lbSAweGY5
OGZkMDAwDQpbICAgIDIuMDI1MTUyXSBodWIgNC0wOjEuMDogc3RhdGUgNyBwb3J0cyA1IGNo
ZyAwMDAwIGV2dCAwMDAwDQpbICAgIDIuMDM4MTg1XSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6
IE9IQ0kgY29udHJvbGxlciBzdGF0ZQ0KWyAgICAyLjAzODE4OV0gb2hjaV9oY2QgMDAwMDow
MDoxNC41OiBPSENJIDEuMCwgTk8gbGVnYWN5IHN1cHBvcnQgcmVnaXN0ZXJzLCByaCBzdGF0
ZSBydW5uaW5nDQpbICAgIDIuMDM4MTkzXSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IGNvbnRy
b2wgMHgyODMgUldDIEhDRlM9b3BlcmF0aW9uYWwgQ0JTUj0zDQpbICAgIDIuMDM4MTk2XSBv
aGNpX2hjZCAwMDAwOjAwOjE0LjU6IGNtZHN0YXR1cyAweDAwMDAwIFNPQz0wDQpbICAgIDIu
MDM4MjAwXSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IGludHJzdGF0dXMgMHgwMDAwMDAwNCBT
Rg0KWyAgICAyLjAzODIwM10gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBpbnRyZW5hYmxlIDB4
ODAwMDAwNWEgTUlFIFJIU0MgVUUgUkQgV0RIDQpbICAgIDIuMDM4MjIzXSBvaGNpX2hjZCAw
MDAwOjAwOjE0LjU6IGhjY2EgZnJhbWUgIzAwMDUNClsgICAgMi4wMzgyMjddIG9oY2lfaGNk
IDAwMDA6MDA6MTQuNTogcm9vdGh1Yi5hIDAyMDAxMjAyIFBPVFBHVD0yIE5PQ1AgTlBTIE5E
UD0yKDIpDQpbICAgIDIuMDM4MjMwXSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IHJvb3RodWIu
YiAwMDAwMDAwMCBQUENNPTAwMDAgRFI9MDAwMA0KWyAgICAyLjAzODIzM10gb2hjaV9oY2Qg
MDAwMDowMDoxNC41OiByb290aHViLnN0YXR1cyAwMDAwODAwMCBEUldFDQpbICAgIDIuMDM4
MjM3XSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IHJvb3RodWIucG9ydHN0YXR1cyBbMF0gMHgw
MDAwMDEwMCBQUFMNClsgICAgMi4wMzgyNDBdIG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogcm9v
dGh1Yi5wb3J0c3RhdHVzIFsxXSAweDAwMDAwMTAwIFBQUw0KWyAgICAyLjAzODI2NF0gdXNi
IHVzYjY6IGRlZmF1bHQgbGFuZ3VhZ2UgMHgwNDA5DQpbICAgIDIuMDM4MjgwXSB1c2IgdXNi
NjogdWRldiAxLCBidXNudW0gNiwgbWlub3IgPSA2NDANClsgICAgMi4wMzgyODJdIHVzYiB1
c2I2OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAw
MDENClsgICAgMi4wMzgyODNdIHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBN
ZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgICAyLjAzODI4NV0gdXNiIHVz
YjY6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDIuMDM4Mjg2XSB1c2Ig
dXNiNjogTWFudWZhY3R1cmVyOiBMaW51eCAzLjIuMC1yYzArIG9oY2lfaGNkDQpbICAgIDIu
MDM4Mjg4XSB1c2IgdXNiNjogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjE0LjUNClsgICAgMi4w
Mzg2MTZdIHVzYiB1c2I2OiB1c2JfcHJvYmVfZGV2aWNlDQpbICAgIDIuMDM4NjE4XSB1c2Ig
dXNiNjogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KWyAgICAyLjAz
ODYyN10gdXNiIHVzYjY6IGFkZGluZyA2LTA6MS4wIChjb25maWcgIzEsIGludGVyZmFjZSAw
KQ0KWyAgICAyLjAzODc4MV0gaHViIDYtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UNClsg
ICAgMi4wMzg3ODNdIGh1YiA2LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlIC0gZ290IGlk
DQpbICAgIDIuMDM4Nzg0XSBodWIgNi0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgICAyLjAz
ODc5M10gaHViIDYtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMi4wMzg3OTVdIGh1
YiA2LTA6MS4wOiBzdGFuZGFsb25lIGh1Yg0KWyAgICAyLjAzODc5Nl0gaHViIDYtMDoxLjA6
IG5vIHBvd2VyIHN3aXRjaGluZyAodXNiIDEuMCkNClsgICAgMi4wMzg3OTddIGh1YiA2LTA6
MS4wOiBubyBvdmVyLWN1cnJlbnQgcHJvdGVjdGlvbg0KWyAgICAyLjAzODc5OV0gaHViIDYt
MDoxLjA6IHBvd2VyIG9uIHRvIHBvd2VyIGdvb2QgdGltZTogNG1zDQpbICAgIDIuMDM4ODA5
XSBodWIgNi0wOjEuMDogbG9jYWwgcG93ZXIgc291cmNlIGlzIGdvb2QNClsgICAgMi4wMzg4
MTBdIGh1YiA2LTA6MS4wOiB0cnlpbmcgdG8gZW5hYmxlIHBvcnQgcG93ZXIgb24gbm9uLXN3
aXRjaGFibGUgaHViDQpbICAgIDIuMDM4ODg4XSBkcml2ZXJzL3VzYi9jb3JlL2lub2RlLmM6
IGNyZWF0aW5nIGZpbGUgJzAwMScNClsgICAgMi4wMzkyOTNdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDIuMDM5Mjk3XSB4ZW5fbWFw
X3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgNClsgICAgMi4wMzkyOThd
IHhlbjogLS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpDQpbICAgIDIuMDM5MzAwXSBB
bHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgIDIuMDM5MzE4XSBvaGNpX2hjZCAwMDAw
OjAwOjE2LjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDIuMDM5MzI3XSBkcml2ZXJz
L3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5nIGZpbGUgJzAwNycNClsgICAgMi4wMzk1NTRd
IG9oY2lfaGNkIDAwMDA6MDA6MTYuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWdu
ZWQgYnVzIG51bWJlciA3DQpbICAgIDIuMDM5NTY2XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6
IGVuYWJsZWQgQU1EIHByZWZldGNoIHF1aXJrDQpbICAgIDIuMDM5NjM4XSBvaGNpX2hjZCAw
MDAwOjAwOjE2LjA6IGNyZWF0ZWQgZGVidWcgZmlsZXMNClsgICAgMi4wMzk2MzldIG9oY2lf
aGNkIDAwMDA6MDA6MTYuMDogc3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtldXANClsgICAgMi4w
Mzk2NDddIG9oY2lfaGNkIDAwMDA6MDA6MTYuMDogaXJxIDE4LCBpbyBtZW0gMHhmOThmZTAw
MA0KWyAgICAyLjA4MjE0NF0gaHViIDUtMDoxLjA6IHN0YXRlIDcgcG9ydHMgNSBjaGcgMDAw
MCBldnQgMDAwMA0KWyAgICAyLjA5NTIwN10gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBPSENJ
IGNvbnRyb2xsZXIgc3RhdGUNClsgICAgMi4wOTUyMTRdIG9oY2lfaGNkIDAwMDA6MDA6MTYu
MDogT0hDSSAxLjAsIE5PIGxlZ2FjeSBzdXBwb3J0IHJlZ2lzdGVycywgcmggc3RhdGUgcnVu
bmluZw0KWyAgICAyLjA5NTIxOF0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBjb250cm9sIDB4
MjgzIFJXQyBIQ0ZTPW9wZXJhdGlvbmFsIENCU1I9Mw0KWyAgICAyLjA5NTIyMV0gb2hjaV9o
Y2QgMDAwMDowMDoxNi4wOiBjbWRzdGF0dXMgMHgwMDAwMCBTT0M9MA0KWyAgICAyLjA5NTIy
NF0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBpbnRyc3RhdHVzIDB4MDAwMDAwMDQgU0YNClsg
ICAgMi4wOTUyMjhdIG9oY2lfaGNkIDAwMDA6MDA6MTYuMDogaW50cmVuYWJsZSAweDgwMDAw
MDVhIE1JRSBSSFNDIFVFIFJEIFdESA0KWyAgICAyLjA5NTI1MF0gb2hjaV9oY2QgMDAwMDow
MDoxNi4wOiBoY2NhIGZyYW1lICMwMDA1DQpbICAgIDIuMDk1MjUzXSBvaGNpX2hjZCAwMDAw
OjAwOjE2LjA6IHJvb3RodWIuYSAwMjAwMTIwNCBQT1RQR1Q9MiBOT0NQIE5QUyBORFA9NCg0
KQ0KWyAgICAyLjA5NTI1Nl0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiByb290aHViLmIgMDAw
MDAwMDAgUFBDTT0wMDAwIERSPTAwMDANClsgICAgMi4wOTUyNjBdIG9oY2lfaGNkIDAwMDA6
MDA6MTYuMDogcm9vdGh1Yi5zdGF0dXMgMDAwMDgwMDAgRFJXRQ0KWyAgICAyLjA5NTI2M10g
b2hjaV9oY2QgMDAwMDowMDoxNi4wOiByb290aHViLnBvcnRzdGF0dXMgWzBdIDB4MDAwMDAx
MDAgUFBTDQpbICAgIDIuMDk1MjY3XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IHJvb3RodWIu
cG9ydHN0YXR1cyBbMV0gMHgwMDAwMDEwMCBQUFMNClsgICAgMi4wOTUyNzBdIG9oY2lfaGNk
IDAwMDA6MDA6MTYuMDogcm9vdGh1Yi5wb3J0c3RhdHVzIFsyXSAweDAwMDAwMTAwIFBQUw0K
WyAgICAyLjA5NTI3M10gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiByb290aHViLnBvcnRzdGF0
dXMgWzNdIDB4MDAwMDAxMDAgUFBTDQpbICAgIDIuMDk1MjkyXSB1c2IgdXNiNzogZGVmYXVs
dCBsYW5ndWFnZSAweDA0MDkNClsgICAgMi4wOTUzMDVdIHVzYiB1c2I3OiB1ZGV2IDEsIGJ1
c251bSA3LCBtaW5vciA9IDc2OA0KWyAgICAyLjA5NTMwN10gdXNiIHVzYjc6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICAyLjA5
NTMwOF0gdXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0
PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDIuMDk1MzEwXSB1c2IgdXNiNzogUHJvZHVjdDog
T0hDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMi4wOTUzMTFdIHVzYiB1c2I3OiBNYW51ZmFj
dHVyZXI6IExpbnV4IDMuMi4wLXJjMCsgb2hjaV9oY2QNClsgICAgMi4wOTUzMTNdIHVzYiB1
c2I3OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMA0KWyAgICAyLjA5NTY0Ml0gdXNiIHVz
Yjc6IHVzYl9wcm9iZV9kZXZpY2UNClsgICAgMi4wOTU2NDRdIHVzYiB1c2I3OiBjb25maWd1
cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpbICAgIDIuMDk1NjUzXSB1c2IgdXNi
NzogYWRkaW5nIDctMDoxLjAgKGNvbmZpZyAjMSwgaW50ZXJmYWNlIDApDQpbICAgIDIuMDk1
ODIwXSBodWIgNy0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZQ0KWyAgICAyLjA5NTgyMl0g
aHViIDctMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3QgaWQNClsgICAgMi4wOTU4
MjNdIGh1YiA3LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDIuMDk1ODMzXSBodWIgNy0w
OjEuMDogNCBwb3J0cyBkZXRlY3RlZA0KWyAgICAyLjA5NTgzNF0gaHViIDctMDoxLjA6IHN0
YW5kYWxvbmUgaHViDQpbICAgIDIuMDk1ODM1XSBodWIgNy0wOjEuMDogbm8gcG93ZXIgc3dp
dGNoaW5nICh1c2IgMS4wKQ0KWyAgICAyLjA5NTg0Nl0gaHViIDctMDoxLjA6IG5vIG92ZXIt
Y3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDIuMDk1ODQ4XSBodWIgNy0wOjEuMDogcG93ZXIg
b24gdG8gcG93ZXIgZ29vZCB0aW1lOiA0bXMNClsgICAgMi4wOTU4NThdIGh1YiA3LTA6MS4w
OiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAyLjA5NTg1OV0gaHViIDctMDox
LjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJsZSBodWIN
ClsgICAgMi4wOTU4OThdIGRyaXZlcnMvdXNiL2NvcmUvaW5vZGUuYzogY3JlYXRpbmcgZmls
ZSAnMDAxJw0KWyAgICAyLjA5NTk5M10gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBIUyBjb21w
YW5pb24gZm9yIDAwMDA6MDA6MTYuMA0KWyAgICAyLjA5NjM0NV0gdWhjaV9oY2Q6IFVTQiBV
bml2ZXJzYWwgSG9zdCBDb250cm9sbGVyIEludGVyZmFjZSBkcml2ZXINClsgICAgMi4wOTY2
NTRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNibHANClsg
ICAgMi4wOTY2NTVdIEluaXRpYWxpemluZyBVU0IgTWFzcyBTdG9yYWdlIGRyaXZlci4uLg0K
WyAgICAyLjA5Njc4OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZl
ciB1c2Itc3RvcmFnZQ0KWyAgICAyLjA5Njc5OV0gVVNCIE1hc3MgU3RvcmFnZSBzdXBwb3J0
IHJlZ2lzdGVyZWQuDQpbICAgIDIuMDk2OTQ1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBp
bnRlcmZhY2UgZHJpdmVyIGxpYnVzdWFsDQpbICAgIDIuMDk3MjQxXSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYnNlcmlhbA0KWyAgICAyLjA5NzI0NV0g
dXNic2VyaWFsOiBVU0IgU2VyaWFsIERyaXZlciBjb3JlDQpbICAgIDIuMDk3MzU4XSBVU0Ig
U2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgY3AyMTB4DQpbICAgIDIuMDk3NDcxXSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNwMjEweA0KWyAgICAy
LjA5NzQ3Ml0gY3AyMTB4OiB2MC4wOTpTaWxpY29uIExhYnMgQ1AyMTB4IFJTMjMyIHNlcmlh
bCBhZGFwdG9yIGRyaXZlcg0KWyAgICAyLjA5NzU5MF0gVVNCIFNlcmlhbCBzdXBwb3J0IHJl
Z2lzdGVyZWQgZm9yIERlTG9ybWUgRWFydGhtYXRlIFVTQg0KWyAgICAyLjA5NzY4N10gVVNC
IFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIEhJRC0+Q09NIFJTMjMyIEFkYXB0ZXIN
ClsgICAgMi4wOTc3ODJdIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBOb2tp
YSBDQS00MiBWMiBBZGFwdGVyDQpbICAgIDIuMDk3ODkxXSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIGN5cHJlc3MNClsgICAgMi4wOTc4OTNdIGN5cHJlc3Nf
bTg6IHYxLjEwOkN5cHJlc3MgVVNCIHRvIFNlcmlhbCBEcml2ZXINClsgICAgMi4wOTc5OTJd
IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDIgcG9ydCBhZGFw
dGVyDQpbICAgIDIuMDk3OTk0XSBtb3M3NzIwOiAyLjE6TW9zY2hpcCBVU0IgU2VyaWFsIERy
aXZlcg0KWyAgICAyLjA5ODE0MV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciBtb3NjaGlwNzcyMA0KWyAgICAyLjA5ODI0NF0gVVNCIFNlcmlhbCBzdXBwb3J0
IHJlZ2lzdGVyZWQgZm9yIE1vc2NoaXAgNzg0MC83ODIwIFVTQiBTZXJpYWwgRHJpdmVyDQpb
ICAgIDIuMDk4MjQ2XSBtb3M3ODQwOiAxLjMuMjpNb3NjaGlwIDc4NDAvNzgyMCBVU0IgU2Vy
aWFsIERyaXZlcg0KWyAgICAyLjA5ODM3Ml0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciBtb3M3ODQwDQpbICAgIDIuMDk4ODE0XSBpODA0MjogUE5QOiBObyBQ
Uy8yIGNvbnRyb2xsZXIgZm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuDQpbICAgIDIu
MDk5NTQzXSBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxDQpbICAg
IDIuMDk5NTU3XSBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMg0K
WyAgICAyLjEwMDAyMl0gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3Ig
YWxsIG1pY2UNClsgICAgMi4xMDA2NzddIHJ0Y19jbW9zIDAwOjA0OiBSVEMgY2FuIHdha2Ug
ZnJvbSBTNA0KWyAgICAyLjEwMTE4MF0gcnRjX2Ntb3MgMDA6MDQ6IHJ0YyBjb3JlOiByZWdp
c3RlcmVkIHJ0Y19jbW9zIGFzIHJ0YzANClsgICAgMi4xMDEyODBdIHJ0YzA6IGFsYXJtcyB1
cCB0byBvbmUgbW9udGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtDQpbICAgIDIuMTAxOTYzXSBs
aXJjX2RldjogSVIgUmVtb3RlIENvbnRyb2wgZHJpdmVyIHJlZ2lzdGVyZWQsIG1ham9yIDI1
MSANClsgICAgMi4xMDE5NzZdIElSIE5FQyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVk
DQpbICAgIDIuMTAxOTc4XSBJUiBSQzUoeCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXpl
ZA0KWyAgICAyLjEwMTk4MF0gSVIgUkM2IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQN
ClsgICAgMi4xMDE5ODJdIElSIEpWQyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpb
ICAgIDIuMTAxOTgzXSBJUiBTb255IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsg
ICAgMi4xMDE5ODVdIElSIFJDNSAoc3RyZWFtemFwKSBwcm90b2NvbCBoYW5kbGVyIGluaXRp
YWxpemVkDQpbICAgIDIuMTAxOTg3XSBJUiBNQ0UgS2V5Ym9hcmQvbW91c2UgcHJvdG9jb2wg
aGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAyLjEwMTk4OV0gSVIgTElSQyBicmlkZ2UgaGFu
ZGxlciBpbml0aWFsaXplZA0KWyAgICAyLjEwMTk5MF0gTGludXggdmlkZW8gY2FwdHVyZSBp
bnRlcmZhY2U6IHYyLjAwDQpbICAgIDIuMTAyMjE1XSBpMmMtY29yZTogZHJpdmVyIFt0dW5l
cl0gdXNpbmcgbGVnYWN5IHN1c3BlbmQgbWV0aG9kDQpbICAgIDIuMTAyMjE2XSBpMmMtY29y
ZTogZHJpdmVyIFt0dW5lcl0gdXNpbmcgbGVnYWN5IHJlc3VtZSBtZXRob2QNClsgICAgMi4x
MDI0MTBdIGkyYy1jb3JlOiBkcml2ZXIgW21zcDM0MDBdIHVzaW5nIGxlZ2FjeSBzdXNwZW5k
IG1ldGhvZA0KWyAgICAyLjEwMjQxMl0gaTJjLWNvcmU6IGRyaXZlciBbbXNwMzQwMF0gdXNp
bmcgbGVnYWN5IHJlc3VtZSBtZXRob2QNClsgICAgMi4xMDI4NzldIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgcG9zZWlkb24NClsgICAgMi4xMDI5OTFdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3gyMzF4eA0KWyAgICAy
LjEwMzEzOF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2J2
aXNpb24NClsgICAgMi4xMDMxNDBdIFVTQlZpc2lvbiBVU0IgVmlkZW8gRGV2aWNlIERyaXZl
ciBmb3IgTGludXggOiAwLjkuMTENClsgICAgMi4xMDM0NTNdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgcHZydXNiMg0KWyAgICAyLjEwMzQ1NF0gcHZydXNi
MjogVjRMIGluLXRyZWUgdmVyc2lvbjpIYXVwcGF1Z2UgV2luVFYtUFZSLVVTQjIgTVBFRzIg
RW5jb2Rlci9UdW5lcg0KWyAgICAyLjEwMzQ1Nl0gcHZydXNiMjogRGVidWcgbWFzayBpcyAz
MSAoMHgxZikNClsgICAgMi4xMDM1ODZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgdG02MDAwDQpbICAgIDIuMTAzNjk4XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIHpyMzY0eHgNClsgICAgMi4xMDM4MzBdIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc3Rrd2ViY2FtDQpbICAgIDIuMTAz
OTQwXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuOWMxMDIN
ClsgICAgMi4xMDQwNzFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgZXQ2MXgyNTENClsgICAgMi4xMDQxODldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu
dGVyZmFjZSBkcml2ZXIgUGhpbGlwcyB3ZWJjYW0NClsgICAgMi4xMDQxOTFdIGdzcGNhX21h
aW46IHYyLjE0LjAgcmVnaXN0ZXJlZA0KWyAgICAyLjEwNDMwN10gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBiZW5xDQpbICAgIDIuMTA0NDMyXSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNvbmV4DQpbICAgIDIuMTA0NTQw
XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNwaWExDQpbICAg
IDIuMTA0NjQ5XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGV0
b21zDQpbICAgIDIuMTA0NzU3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIGZpbmVwaXgNClsgICAgMi4xMDQ4NzRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3
IGludGVyZmFjZSBkcml2ZXIgamVpbGluag0KWyAgICAyLjEwNDk4NV0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBraW5lY3QNClsgICAgMi4xMDUxMjJdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIga29uaWNhDQpbICAgIDIu
MTA1MjI4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1hcnMN
ClsgICAgMi4xMDUzNTVdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgbXI5NzMxMGENClsgICAgMi4xMDU1MTNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu
dGVyZmFjZSBkcml2ZXIgbnc4MHgNClsgICAgMi4xMDU2NDddIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgb3Y1MTkNClsgICAgMi4xMDU3NTddIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgb3Y1MzQNClsgICAgMi4xMDU4Njdd
IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgb3Y1MzRfOQ0KWyAg
ICAyLjEwNTk5NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBw
YWMyMDcNClsgICAgMi4xMDYxMjVdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgcGFjNzMwMg0KWyAgICAyLjEwNjI1OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBwYWM3MzExDQpbICAgIDIuMTA2MzY0XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNlNDAxDQpbICAgIDIuMTA2NDcwXSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuOWMyMDI4DQpbICAg
IDIuMTA2NTk0XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNu
OWMyMHgNClsgICAgMi4xMDY3MTJdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgc29uaXhiDQpbICAgIDIuMTA2ODMxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIHNvbml4ag0KWyAgICAyLjEwNjk0OV0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzcGNhNTAwDQpbICAgIDIuMTA3MDgxXSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNwY2E1MDENClsgICAg
Mi4xMDcyMTFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc3Bj
YTUwNQ0KWyAgICAyLjEwNzMyNl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciBzcGNhNTA2DQpbICAgIDIuMTA3NDMyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIHNwY2E1MDgNClsgICAgMi4xMDc1NTldIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc3BjYTU2MQ0KWyAgICAyLjEwNzY3MF0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzcGNhMTUyOA0KWyAg
ICAyLjEwNzc3OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBz
cTkwNQ0KWyAgICAyLjEwNzkwNF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciBzcTkwNWMNClsgICAgMi4xMDgwMTRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3
IGludGVyZmFjZSBkcml2ZXIgc3E5MzB4DQpbICAgIDIuMTA4MTk2XSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHN1bnBsdXMNClsgICAgMi4xMDgzMDldIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc3RrMDE0DQpbICAgIDIu
MTA4NDI3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHN0djA2
ODANClsgICAgMi4xMDg1MzVdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk
cml2ZXIgdDYxMw0KWyAgICAyLjEwODY0NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciB0djg1MzINClsgICAgMi4xMDg3NzJdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdmMwMzJ4DQpbICAgIDIuMTA4ODc5XSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHZpY2FtDQpbICAgIDIuMTA4OTky
XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHhpcmxpbmstY2l0
DQpbICAgIDIuMTA5MTQ1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJp
dmVyIHpjM3h4DQpbICAgIDIuMTA5MjY3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIEFMaSBtNTYwMg0KWyAgICAyLjEwOTM4OF0gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBTVFYwNnh4DQpbICAgIDIuMTA5NTAxXSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGdzcGNhX2dsODYwDQpbICAg
IDIuMTA5NjYzXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGhk
cHZyDQpbICAgIDIuMTA5Nzc2XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIHMyMjU1DQpbICAgIDIuMTA5OTAyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBp
bnRlcmZhY2UgZHJpdmVyIHV2Y3ZpZGVvDQpbICAgIDIuMTA5OTAzXSBVU0IgVmlkZW8gQ2xh
c3MgZHJpdmVyICgxLjEuMSkNClsgICAgMi4xMTAxMTJdIGY3MTg4MmZnOiBGb3VuZCBmNzE4
ODllZCBjaGlwIGF0IDB4NjAwLCByZXZpc2lvbiAxNg0KWyAgICAyLjExMDQ2NF0gZjcxODgy
ZmcgZjcxODgyZmcuMTUzNjogRmFuOiAxIGlzIGluIGR1dHktY3ljbGUgbW9kZQ0KWyAgICAy
LjExMDUxMl0gZjcxODgyZmcgZjcxODgyZmcuMTUzNjogRmFuOiAyIGlzIGluIGR1dHktY3lj
bGUgbW9kZQ0KWyAgICAyLjExMDU1NF0gZjcxODgyZmcgZjcxODgyZmcuMTUzNjogRmFuOiAz
IGlzIGluIGR1dHktY3ljbGUgbW9kZQ0KWyAgICAyLjExMTc5Ml0gZjcxODA4ZV93ZHQ6IFVu
cmVjb2duaXplZCBGaW50ZWsgZGV2aWNlOiAwOTA5DQpbICAgIDIuMTExNzk4XSBTUDUxMDAg
VENPIHRpbWVyOiBTUDUxMDAgVENPIFdhdGNoRG9nIFRpbWVyIERyaXZlciB2MC4wMQ0KWyAg
ICAyLjExMjA5N10gU1A1MTAwIFRDTyB0aW1lcjogbW1pbyBhZGRyZXNzIDB4YjhmZTAwIGFs
cmVhZHkgaW4gdXNlDQpbICAgIDIuMTEyMTA3XSB3ZHQ6IFhlbiBXYXRjaERvZyBUaW1lciBE
cml2ZXIgdjAuMDENClsgICAgMi4xMTI0ODddIHdkdDogaW5pdGlhbGl6ZWQgKHRpbWVvdXQ9
NjBzLCBub3dheW91dD0wKQ0KWyAgICAyLjExMzEyOV0gZGV2aWNlLW1hcHBlcjogaW9jdGw6
IDQuMjIuMC1pb2N0bCAoMjAxMS0xMC0xOSkgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhh
dC5jb20NClsgICAgMi4xMTM0ODZdIEVGSSBWYXJpYWJsZXMgRmFjaWxpdHkgdjAuMDggMjAw
NC1NYXktMTcNClsgICAgMi4xMTYwOTZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgdXNiaGlkDQpbICAgIDIuMTE2MDk4XSB1c2JoaWQ6IFVTQiBISUQgY29y
ZSBkcml2ZXINClsgICAgMi4xMjA5NDBdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgc25kLXVzYi1hdWRpbw0KWyAgICAyLjEyMTA5Ml0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdWExMDENClsgICAgMi4xMjEyMDhd
IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi11c3gy
eQ0KWyAgICAyLjEyMTMzOF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy
aXZlciBzbmQtdXNiLXVzMTIybA0KWyAgICAyLjEyMTQ1NF0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWNhaWFxDQpbICAgIDIuMTIxNTY5XSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItNmZpcmUN
ClsgICAgMi4xMjE1NzFdIEFMU0EgZGV2aWNlIGxpc3Q6DQpbICAgIDIuMTIxNTcyXSAgIE5v
IHNvdW5kY2FyZHMgZm91bmQuDQpbICAgIDIuMTIxNjM2XSBOZXRmaWx0ZXIgbWVzc2FnZXMg
dmlhIE5FVExJTksgdjAuMzAuDQpbICAgIDIuMTIxNjk3XSBuZl9jb25udHJhY2sgdmVyc2lv
biAwLjUuMCAoNzMxOSBidWNrZXRzLCAyOTI3NiBtYXgpDQpbICAgIDIuMTIyNDcwXSBjdG5l
dGxpbmsgdjAuOTM6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLg0KWyAgICAyLjEyMzE4
NV0geHRfdGltZToga2VybmVsIHRpbWV6b25lIGlzIC0wMDAwDQpbICAgIDIuMTIzMjAxXSBp
cF9zZXQ6IHByb3RvY29sIDYNClsgICAgMi4xMjMyNTNdIElQVlM6IFJlZ2lzdGVyZWQgcHJv
dG9jb2xzICgpDQpbICAgIDIuMTIzMjc4XSBJUFZTOiBDb25uZWN0aW9uIGhhc2ggdGFibGUg
Y29uZmlndXJlZCAoc2l6ZT00MDk2LCBtZW1vcnk9NjRLYnl0ZXMpDQpbICAgIDIuMTIzNTgz
XSBJUFZTOiBDcmVhdGluZyBuZXRucyBzaXplPTE5MTIgaWQ9MA0KWyAgICAyLjEyMzU5MF0g
SVBWUzogaXB2cyBsb2FkZWQuDQpbICAgIDIuMTI1NTQyXSBpcF90YWJsZXM6IChDKSAyMDAw
LTIwMDYgTmV0ZmlsdGVyIENvcmUgVGVhbQ0KWyAgICAyLjEyNTY2OF0gVENQIGN1YmljIHJl
Z2lzdGVyZWQNClsgICAgMi4xMjU2NzFdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p
bHkgMTcNClsgICAgMi4xMjU3OTJdIEJyaWRnZSBmaXJld2FsbGluZyByZWdpc3RlcmVkDQpb
ICAgIDIuMTI1ODA2XSBFYnRhYmxlcyB2Mi4wIHJlZ2lzdGVyZWQNClsgICAgMi4xMjU4NTBd
IFJlZ2lzdGVyaW5nIHRoZSBkbnNfcmVzb2x2ZXIga2V5IHR5cGUNClsgICAgMi4xMjY1Mzdd
IHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQ0KWyAgICAyLjEyODQ3MV0gICBNYWdp
YyBudW1iZXI6IDEyOjUxNTo0MzANClsgICAgMi4xMzkxNDRdIGh1YiA2LTA6MS4wOiBzdGF0
ZSA3IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMi4xOTUxNThdIGh1YiA3LTA6
MS4wOiBzdGF0ZSA3IHBvcnRzIDQgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMy41NTYxMzVd
IGNvbnNvbGUgW25ldGNvbjBdIGVuYWJsZWQNClsgICAgMy41NjAxMTRdIG5ldGNvbnNvbGU6
IG5ldHdvcmsgbG9nZ2luZyBzdGFydGVkDQpbICAgIDMuNTY1MTgzXSBGcmVlaW5nIHVudXNl
ZCBrZXJuZWwgbWVtb3J5OiA2NDRrIGZyZWVkDQpbICAgIDMuNTY2MDU0XSBXcml0ZSBwcm90
ZWN0aW5nIHRoZSBrZXJuZWwgcmVhZC1vbmx5IGRhdGE6IDE0MzM2aw0KWyAgICAzLjU4MjU4
MV0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTEwOGsgZnJlZWQNClsgICAgMy41
ODc4MTldIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE3MmsgZnJlZWQNClsgICAg
NC4zNzU2NzldIEVYVDQtZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRl
cmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpDQpbICAgIDUuNzM1NzE3XSB1ZGV2WzE5Mjhd
OiBzdGFydGluZyB2ZXJzaW9uIDE2NA0KWyAgICA2LjYxOTUwMl0gYXRhMS4wMDogY29uZmln
dXJlZCBmb3IgVURNQS8xMzMNClsgICAgNi42MjA0ODZdIGF0YTE6IEVIIGNvbXBsZXRlDQpb
ICAgIDYuOTg5NDExXSBhdGExLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzEzMw0KWyAgICA2
Ljk4OTQxNl0gYXRhMTogRUggY29tcGxldGUNClsgICAgNy41NDQzNTVdIEVYVDQtZnMgKGRt
LTApOiByZS1tb3VudGVkLiBPcHRzOiAobnVsbCkNClsgICAgNy43NTAyMjhdIEVYVDQtZnMg
KGRtLTApOiByZS1tb3VudGVkLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8N
ClsgICAxMy42NDYzODNdIEFkZGluZyAyMDk3MTQ4ayBzd2FwIG9uIC9kZXYvbWFwcGVyL3Nl
cnZlZXJzdGVydGplLXN3YXAuICBQcmlvcml0eTotMSBleHRlbnRzOjEgYWNyb3NzOjIwOTcx
NDhrIA0KWyAgIDE0LjY4OTk5NF0gRVhUNC1mcyAoc2RhMSk6IG1vdW50ZWQgZmlsZXN5c3Rl
bSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91
bnQtcm8NClsgICAxNS45MjM2NTFdIHI4MTY5IDAwMDA6MDg6MDAuMDogZXRoMTogbGluayBk
b3duDQpbICAgMTUuOTI0NjU5XSByODE2OSAwMDAwOjA4OjAwLjA6IGV0aDE6IGxpbmsgZG93
bg0KWyAgIDE2LjExNDkwNV0gcjgxNjkgMDAwMDowOTowMC4wOiBldGgwOiBsaW5rIGRvd24N
ClsgICAxNi4xMTU5NDJdIHI4MTY5IDAwMDA6MDk6MDAuMDogZXRoMDogbGluayBkb3duDQpb
ICAgMTcuNjQyNTA0XSByODE2OSAwMDAwOjA4OjAwLjA6IGV0aDE6IGxpbmsgdXANClsgICAx
OC4wMjI0MzZdIHI4MTY5IDAwMDA6MDk6MDAuMDogZXRoMDogbGluayB1cA0KWyAgIDI0LjA4
MzMwNF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4x
NTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MTgyNTAgRFBUPTUzIExFTj00NyANClsgICAy
NC4wODMzMjZdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9
ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgw
MCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTE4MjUwIERQVD01MyBMRU49NDcgDQpb
ICAgMjQuMTE2NTQ2XSBGVzogaXBtYXNxLCBGb3J3YXJkIC4uIEVvQzogSU49ZXRoMSBPVVQ9
ZXRoMCBNQUM9NDA6NjE6ODY6ZjQ6Njc6ZDg6MDA6MTM6ZTg6Yjg6MDM6N2Y6MDg6MDAgU1JD
PTE3Mi4xNi4xLjIwIERTVD02NC40LjM0LjE5MSBMRU49NDAgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD0xMjcgSUQ9MTU2MTggREYgUFJPVE89VENQIFNQVD00OTE5NCBEUFQ9MTg2MyBXSU5E
T1c9MCBSRVM9MHgwMCBBQ0sgUlNUIFVSR1A9MCANClsgICAyNC4xMTkwMjJdIEZXOiBpcG1h
c3EsIEZvcndhcmQgLi4gRW9DOiBJTj1ldGgxIE9VVD1ldGgwIE1BQz00MDo2MTo4NjpmNDo2
NzpkODowMDoxMzplODpiODowMzo3ZjowODowMCBTUkM9MTcyLjE2LjEuMjAgRFNUPTY0LjQu
NDQuNzIgTEVOPTQ1IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9MTI3IElEPTE1NjE5IERGIFBS
T1RPPVRDUCBTUFQ9NTIwNTkgRFBUPTE4NjMgV0lORE9XPTY1IFJFUz0weDAwIEFDSyBQU0gg
RklOIFVSR1A9MCANClsgICAyNC40OTcwMjNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6
IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3
IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzYgREYgUFJPVE89VURQIFNQVD00
NjExMiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5NzEyNl0gRlc6IGlwbWFzcSwgT3V0cHV0
IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIw
MSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3NyBERiBQUk9UTz1V
RFAgU1BUPTM4MTczIERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk3MTczXSBGVzogaXBtYXNx
LCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODgu
MTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc3IERG
IFBST1RPPVVEUCBTUFQ9NDI0NjIgRFBUPTUzIExFTj00NyANClsgICAyNC40OTcyMTldIEZX
OiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1
IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9
NTIxNzcgREYgUFJPVE89VURQIFNQVD01MjQ5OCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5
NzI2M10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4x
NTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD02NCBJRD01MjE3NyBERiBQUk9UTz1VRFAgU1BUPTQxOTgxIERQVD01MyBMRU49NDcgDQpb
ICAgMjQuNDk3MzA3XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAg
U1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVD
PTB4MDAgVFRMPTY0IElEPTUyMTc3IERGIFBST1RPPVVEUCBTUFQ9NDQ5NTAgRFBUPTUzIExF
Tj00NyANClsgICAyNC40OTczNTZdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBP
VVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0w
eDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzcgREYgUFJPVE89VURQIFNQVD01Nzc0OSBE
UFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5NzQwMl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVv
QzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49
NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3NyBERiBQUk9UTz1VRFAgU1BU
PTQwNzQ3IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk3NDgwXSBGVzogaXBtYXNxLCBPdXRw
dXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEu
MjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc3IERGIFBST1RP
PVVEUCBTUFQ9NTYwNDQgRFBUPTUzIExFTj00NyANClsgICAyNC40OTc1MjddIEZXOiBpcG1h
c3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04
OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzcg
REYgUFJPVE89VURQIFNQVD01NjUzMCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5NzU3MV0g
Rlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIu
MjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJ
RD01MjE3NyBERiBQUk9UTz1VRFAgU1BUPTU5NzQ2IERQVD01MyBMRU49NDcgDQpbICAgMjQu
NDk3NjE1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4
LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAg
VFRMPTY0IElEPTUyMTc3IERGIFBST1RPPVVEUCBTUFQ9NTg0MjIgRFBUPTUzIExFTj00NyAN
ClsgICAyNC40OTc2NzFdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRo
MCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBS
RUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzcgREYgUFJPVE89VURQIFNQVD0zNTE5MiBEUFQ9NTMg
TEVOPTQ3IA0KWyAgIDI0LjQ5NzcxM10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49
IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9T
PTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3NyBERiBQUk9UTz1VRFAgU1BUPTUyNjgx
IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk3NzUzXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4g
RW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExF
Tj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc3IERGIFBST1RPPVVEUCBT
UFQ9MzQ2NjEgRFBUPTUzIExFTj00NyANClsgICAyNC40OTc3OTNdIEZXOiBpcG1hc3EsIE91
dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTku
MS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzcgREYgUFJP
VE89VURQIFNQVD00MzQwNiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5ODAwM10gRlc6IGlw
bWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNU
PTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3
NyBERiBQUk9UTz1VRFAgU1BUPTQwMTg3IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk4MDQz
XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43
Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0
IElEPTUyMTc3IERGIFBST1RPPVVEUCBTUFQ9NTI1OTIgRFBUPTUzIExFTj00NyANClsgICAy
NC40OTgxMjNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9
ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgw
MCBUVEw9NjQgSUQ9NTIxNzggREYgUFJPVE89VURQIFNQVD00MDA3MyBEUFQ9NTMgTEVOPTQ3
IA0KWyAgIDI0LjQ5ODE2OV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1l
dGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAg
UFJFQz0weDAwIFRUTD02NCBJRD01MjE3OCBERiBQUk9UTz1VRFAgU1BUPTQ4MjMyIERQVD01
MyBMRU49NDcgDQpbICAgMjQuNDk4MjEzXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJ
Tj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBU
T1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc4IERGIFBST1RPPVVEUCBTUFQ9NTY0
MDEgRFBUPTUzIExFTj00NyANClsgICAyNC40OTgyNjRdIEZXOiBpcG1hc3EsIE91dHB1dCAu
LiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEg
TEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzggREYgUFJPVE89VURQ
IFNQVD00MjI5NSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5ODMwOF0gRlc6IGlwbWFzcSwg
T3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1
OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OCBERiBQ
Uk9UTz1VRFAgU1BUPTM3NDI4IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk4MzUzXSBGVzog
aXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBE
U1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUy
MTc4IERGIFBST1RPPVVEUCBTUFQ9Mzk3OTMgRFBUPTUzIExFTj00NyANClsgICAyNC40OTgz
OTldIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5
LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9
NjQgSUQ9NTIxNzggREYgUFJPVE89VURQIFNQVD0zOTU1MCBEUFQ9NTMgTEVOPTQ3IA0KWyAg
IDI0LjQ5ODQ0Nl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNS
Qz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0w
eDAwIFRUTD02NCBJRD01MjE3OCBERiBQUk9UTz1VRFAgU1BUPTUxMDE0IERQVD01MyBMRU49
NDcgDQpbICAgMjQuNDk4NDg2XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VU
PWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgw
MCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc4IERGIFBST1RPPVVEUCBTUFQ9MzMxMTQgRFBU
PTUzIExFTj00NyANClsgICAyNC40OTg1MjVdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6
IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3
IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzggREYgUFJPVE89VURQIFNQVD00
NjQ3MyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5ODU2NV0gRlc6IGlwbWFzcSwgT3V0cHV0
IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIw
MCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OCBERiBQUk9UTz1V
RFAgU1BUPTU0ODU3IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk4NjA2XSBGVzogaXBtYXNx
LCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODgu
MTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc4IERG
IFBST1RPPVVEUCBTUFQ9NTA1NDcgRFBUPTUzIExFTj00NyANClsgICAyNC40OTg2NDVdIEZX
OiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1
IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9
NTIxNzggREYgUFJPVE89VURQIFNQVD01NzE3MiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5
ODY4NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4x
NTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD02NCBJRD01MjE3OCBERiBQUk9UTz1VRFAgU1BUPTM1MDE4IERQVD01MyBMRU49NDcgDQpb
ICAgMjQuNDk4ODc5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAg
U1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVD
PTB4MDAgVFRMPTY0IElEPTUyMTc4IERGIFBST1RPPVVEUCBTUFQ9MzkyMzMgRFBUPTUzIExF
Tj00NyANClsgICAyNC40OTg5MjBdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBP
VVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0w
eDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzggREYgUFJPVE89VURQIFNQVD01NTU5MSBE
UFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5ODk2MF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVv
QzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49
NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OCBERiBQUk9UTz1VRFAgU1BU
PTQ5MzA5IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk4OTk5XSBGVzogaXBtYXNxLCBPdXRw
dXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEu
MjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc4IERGIFBST1RP
PVVEUCBTUFQ9NTUyOTIgRFBUPTUzIExFTj00NyANClsgICAyNC40OTkwMzldIEZXOiBpcG1h
c3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04
OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzgg
REYgUFJPVE89VURQIFNQVD01MjE3MyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5OTEyMV0g
Rlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIu
MjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJ
RD01MjE3OSBERiBQUk9UTz1VRFAgU1BUPTQwOTAxIERQVD01MyBMRU49NDcgDQpbICAgMjQu
NDk5MTY2XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4
LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAg
VFRMPTY0IElEPTUyMTc5IERGIFBST1RPPVVEUCBTUFQ9NTc0NTkgRFBUPTUzIExFTj00NyAN
ClsgICAyNC40OTkyMTFdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRo
MCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBS
RUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQIFNQVD00NDM5MCBEUFQ9NTMg
TEVOPTQ3IA0KWyAgIDI0LjQ5OTI2MF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49
IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9T
PTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OSBERiBQUk9UTz1VRFAgU1BUPTU3MTIy
IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk5MzA1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4g
RW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExF
Tj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc5IERGIFBST1RPPVVEUCBT
UFQ9MzM3MDMgRFBUPTUzIExFTj00NyANClsgICAyNC40OTkzNDldIEZXOiBpcG1hc3EsIE91
dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTku
MS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJP
VE89VURQIFNQVD01MDgzOSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5OTM5Nl0gRlc6IGlw
bWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNU
PTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3
OSBERiBQUk9UTz1VRFAgU1BUPTM3MzM5IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk5NDQx
XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43
Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0
IElEPTUyMTc5IERGIFBST1RPPVVEUCBTUFQ9NTYyODIgRFBUPTUzIExFTj00NyANClsgICAy
NC40OTk0ODVdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9
ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgw
MCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQIFNQVD0zNjk5OSBEUFQ9NTMgTEVOPTQ3
IA0KWyAgIDI0LjQ5OTUzMF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1l
dGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAg
UFJFQz0weDAwIFRUTD02NCBJRD01MjE3OSBERiBQUk9UTz1VRFAgU1BUPTQwNzQ1IERQVD01
MyBMRU49NDcgDQpbICAgMjQuNDk5NTc5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJ
Tj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBU
T1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc5IERGIFBST1RPPVVEUCBTUFQ9NTcy
NzUgRFBUPTUzIExFTj00NyANClsgICAyNC40OTk3NzJdIEZXOiBpcG1hc3EsIE91dHB1dCAu
LiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAg
TEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQ
IFNQVD02MDE2MiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5OTgxMl0gRlc6IGlwbWFzcSwg
T3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1
OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OSBERiBQ
Uk9UTz1VRFAgU1BUPTQ3Njg1IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk5ODUxXSBGVzog
aXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBE
U1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUy
MTc5IERGIFBST1RPPVVEUCBTUFQ9NDQ1NDkgRFBUPTUzIExFTj00NyANClsgICAyNC40OTk4
OTBdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5
LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9
NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQIFNQVD02MDI4MCBEUFQ9NTMgTEVOPTQ3IA0KWyAg
IDI0LjQ5OTkyOV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNS
Qz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0w
eDAwIFRUTD02NCBJRD01MjE3OSBERiBQUk9UTz1VRFAgU1BUPTQ5OTY2IERQVD01MyBMRU49
NDcgDQpbICAgMjQuNDk5OTY5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VU
PWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgw
MCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc5IERGIFBST1RPPVVEUCBTUFQ9NjA3OTUgRFBU
PTUzIExFTj00NyANClsgICAyNC41MDAwMDhdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6
IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3
IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQIFNQVD00
MDM3OSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjUwMDA0OF0gRlc6IGlwbWFzcSwgT3V0cHV0
IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIw
MSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OSBERiBQUk9UTz1V
RFAgU1BUPTQxODE1IERQVD01MyBMRU49NDcgDQpbICAgMjQuNTAwMTI5XSBGVzogaXBtYXNx
LCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODgu
MTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTgwIERG
IFBST1RPPVVEUCBTUFQ9NDczMzYgRFBUPTUzIExFTj00NyANClsgICAyNC41MDAxNzRdIEZX
OiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1
IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9
NTIxODAgREYgUFJPVE89VURQIFNQVD0zNDM4NSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjUw
MDIxOF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4x
NTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD02NCBJRD01MjE4MCBERiBQUk9UTz1VRFAgU1BUPTM0MDg5IERQVD01MyBMRU49NDcgDQpb
ICAgMjQuNTAwMjYzXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAg
U1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVD
PTB4MDAgVFRMPTY0IElEPTUyMTgwIERGIFBST1RPPVVEUCBTUFQ9NTM5NTggRFBUPTUzIExF
Tj00NyANClsgICAyNC41MDAzMDddIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBP
VVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0w
eDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxODAgREYgUFJPVE89VURQIFNQVD00MTY5OCBE
UFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjUwMDM1MV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVv
QzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49
NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE4MCBERiBQUk9UTz1VRFAgU1BU
PTU0OTI1IERQVD01MyBMRU49NDcgDQpbICAgMjQuNTAwMzk1XSBGVzogaXBtYXNxLCBPdXRw
dXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEu
MjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTgwIERGIFBST1RP
PVVEUCBTUFQ9NDM1OTcgRFBUPTUzIExFTj00NyANClsgICAyNC41MDA0NDBdIEZXOiBpcG1h
c3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04
OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxODAg
REYgUFJPVE89VURQIFNQVD0zNjQ0NyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI3LjM0OTg0M10g
c3NoZCAoNTE2Mik6IC9wcm9jLzUxNjIvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2Ug
dXNlIC9wcm9jLzUxNjIvb29tX3Njb3JlX2FkaiBpbnN0ZWFkLg0KWyAgIDI4LjA4MjQwOV0g
RVhUNC1mcyAoZG0tMik6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBt
b2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8NClsgICAyOC43MDU0MDVd
IEVYVDQtZnMgKGRtLTM2KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRh
IG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDI5LjI0OTEz
MV0gRVhUNC1mcyAoZG0tMzcpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRh
dGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQpbICAgMjkuNzE1
MjA2XSBFWFQ0LWZzIChkbS0zOCk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQg
ZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8NClsgICAzMC4z
ODg1NjFdIEVYVDQtZnMgKGRtLTM5KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJl
ZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDMw
LjQ2ODc5NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04
OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MTE0MTggRFBUPTUzIExFTj00NyANClsg
ICAzMC40OTA3OTddIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBT
UkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9
MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTExNDE4IERQVD01MyBMRU49NDcg
DQpbICAgMzAuNzU2MTUxXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0
aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQ
UkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD02MjU1OSBEUFQ9NTMgTEVO
PTQ3IA0KWyAgIDMwLjc3OTEyM10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9V
VD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NjI1NTkgRFBUPTUz
IExFTj00NyANClsgICAzMC44MDgwMDhdIEVYVDQtZnMgKGRtLTQwKTogbW91bnRlZCBmaWxl
c3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9
cmVtb3VudC1ybw0KWyAgIDMwLjgxMjc5NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzog
SU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49Njcg
VE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9Mjg1MjEg
RFBUPTUzIExFTj00NyANClsgICAzMC44MTI4MTFdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBF
b0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVO
PTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTI4
NTIxIERQVD01MyBMRU49NDcgDQpbICAgMzAuODI1NjE5XSBGVzogaXBtYXNxLCBPdXRwdXQg
Li4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAw
IExFTj02MCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQ
VD02MTQ4MCBEUFQ9NTMgTEVOPTQwIA0KWyAgIDMwLjgyNTYzNl0gRlc6IGlwbWFzcSwgT3V0
cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4x
LjIwMSBMRU49NjAgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVE
UCBTUFQ9NjE0ODAgRFBUPTUzIExFTj00MCANClsgICAzMC44MjYzNDNdIEZXOiBpcG1hc3Es
IE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4x
NTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9U
Tz1VRFAgU1BUPTI4NjUxIERQVD01MyBMRU49NDcgDQpbICAgMzAuODI2MzU5XSBGVzogaXBt
YXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9
ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYg
UFJPVE89VURQIFNQVD0yODY1MSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMwLjg0MTA4NV0gRlc6
IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUg
RFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0w
IERGIFBST1RPPVVEUCBTUFQ9MjQ0ODYgRFBUPTUzIExFTj00NyANClsgICAzMC44NDExMDFd
IEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5Ljcy
LjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQg
SUQ9MCBERiBQUk9UTz1VRFAgU1BUPTI0NDg2IERQVD01MyBMRU49NDcgDQpbICAgMzAuODU2
NTIxXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1
OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRM
PTY0IElEPTAgREYgUFJPVE89VURQIFNQVD01ODk4NCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMw
Ljg1NjUzOF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04
OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NTg5ODQgRFBUPTUzIExFTj00NyANClsg
ICAzMC44NzIwOTJdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBT
UkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9
MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTUyMzQ4IERQVD01MyBMRU49NDcg
DQpbICAgMzAuODcyMTE4XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0
aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQ
UkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD01MjM0OCBEUFQ9NTMgTEVO
PTQ3IA0KWyAgIDMwLjg4NzcxNl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9V
VD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NjE2MDkgRFBUPTUz
IExFTj00NyANClsgICAzMC44ODc3MzNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElO
PSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRP
Uz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTYxNjA5IERQ
VD01MyBMRU49NDcgDQpbICAgMzAuOTAzMzc3XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9D
OiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02
NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0yMjQ0
OCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMwLjkwMzM5NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4u
IEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBM
RU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9
MjI0NDggRFBUPTUzIExFTj00NyANClsgICAzMC45MjAxNDJdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTE1Nzc0IERQVD01MyBMRU49NDcgDQpbICAgMzAuOTIwMTU4XSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0xNTc3NCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMwLjkzNDQ1MF0gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9MzM4ODAgRFBUPTUzIExFTj00NyANClsgICAzMC45MzQ0NjZdIEZXOiBp
cG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERT
VD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBE
RiBQUk9UTz1VRFAgU1BUPTMzODgwIERQVD01MyBMRU49NDcgDQpbICAgMzAuOTUwNDY4XSBG
VzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4y
NSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElE
PTAgREYgUFJPVE89VURQIFNQVD02MzA3MiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMwLjk1MDQ4
NV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTku
NzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02
NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NjMwNzIgRFBUPTUzIExFTj00NyANClsgICAzMC45
NjYzMDhdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODgu
MTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBU
VEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTEzMDYxIERQVD01MyBMRU49NDcgDQpbICAg
MzAuOTY2MzI1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JD
PTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4
MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0xMzA2MSBEUFQ9NTMgTEVOPTQ3IA0K
WyAgIDMwLjk4MTk2Nl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgw
IFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJF
Qz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NDc4MzYgRFBUPTUzIExFTj00
NyANClsgICAzMC45ODE5ODNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9
ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAw
IFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTQ3ODM2IERQVD01MyBM
RU49NDcgDQpbICAgMzAuOTk3MzQxXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0g
T1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9
MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD01NTE5NCBEUFQ9
NTMgTEVOPTQ3IA0KWyAgIDMwLjk5NzM1N10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzog
SU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49Njcg
VE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NTUxOTQg
RFBUPTUzIExFTj00NyANClsgICAzMS4wMTM0MzhdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBF
b0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVO
PTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTUw
NDc3IERQVD01MyBMRU49NDcgDQpbICAgMzEuMDEzNDU1XSBGVzogaXBtYXNxLCBPdXRwdXQg
Li4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAx
IExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQ
VD01MDQ3NyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjAyOTgxMV0gRlc6IGlwbWFzcSwgT3V0
cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4x
LjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVE
UCBTUFQ9MTM5MjggRFBUPTUzIExFTj00NyANClsgICAzMS4wMjk4MjhdIEZXOiBpcG1hc3Es
IE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4x
NTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9U
Tz1VRFAgU1BUPTEzOTI4IERQVD01MyBMRU49NDcgDQpbICAgMzEuMDQ0NjAwXSBGVzogaXBt
YXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9
ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYg
UFJPVE89VURQIFNQVD00MTIwMSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjA0NDYxNl0gRlc6
IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUg
RFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0w
IERGIFBST1RPPVVEUCBTUFQ9NDEyMDEgRFBUPTUzIExFTj00NyANClsgICAzMS4wNjAwMDdd
IEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5Ljcy
LjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQg
SUQ9MCBERiBQUk9UTz1VRFAgU1BUPTY0NzgzIERQVD01MyBMRU49NDcgDQpbICAgMzEuMDYw
MDI1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1
OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRM
PTY0IElEPTAgREYgUFJPVE89VURQIFNQVD02NDc4MyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMx
LjA3NTUzNl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04
OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NDU3MjMgRFBUPTUzIExFTj00NyANClsg
ICAzMS4wNzU1NTJdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBT
UkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9
MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTQ1NzIzIERQVD01MyBMRU49NDcg
DQpbICAgMzEuMDkxMDQxXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0
aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQ
UkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0yNjgxOSBEUFQ9NTMgTEVO
PTQ3IA0KWyAgIDMxLjA5MTEwMV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9V
VD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MjY4MTkgRFBUPTUz
IExFTj00NyANClsgICAzMS4xMDY4NzldIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElO
PSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRP
Uz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTU5MTggRFBU
PTUzIExFTj00NyANClsgICAzMS4xMDY4OTZdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6
IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3
IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTU5MTgg
RFBUPTUzIExFTj00NyANClsgICAzMS4xMjM4NjJdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBF
b0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVO
PTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTg0
ODYgRFBUPTUzIExFTj00NyANClsgICAzMS4xMjM4ODBdIEZXOiBpcG1hc3EsIE91dHB1dCAu
LiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEg
TEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BU
PTg0ODYgRFBUPTUzIExFTj00NyANClsgICAzMS4xMzgyOTNdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTMwMzI1IERQVD01MyBMRU49NDcgDQpbICAgMzEuMTM4MzEyXSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0zMDMyNSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjE1MzUxMV0gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9NTAwMDQgRFBUPTUzIExFTj00NyANClsgICAzMS4xNTM1MjddIEZXOiBp
cG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERT
VD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBE
RiBQUk9UTz1VRFAgU1BUPTUwMDA0IERQVD01MyBMRU49NDcgDQpbICAgMzEuMTY5MDAwXSBG
VzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4y
NSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElE
PTAgREYgUFJPVE89VURQIFNQVD0zOTQyNSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjE2OTAx
N10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTku
NzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02
NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9Mzk0MjUgRFBUPTUzIExFTj00NyANClsgICAzMS4x
ODQ4NzddIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODgu
MTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBU
VEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTg4MzggRFBUPTUzIExFTj00NyANClsgICAz
MS4xODQ5MzRdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9
ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgw
MCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTg4MzggRFBUPTUzIExFTj00NyANClsg
ICAzMS4yMDAzNDNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBT
UkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9
MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTQyODMwIERQVD01MyBMRU49NDcg
DQpbICAgMzEuMjAwMzU5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0
aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQ
UkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD00MjgzMCBEUFQ9NTMgTEVO
PTQ3IA0KWyAgIDMxLjIxNjAxOV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9V
VD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MjU5MTcgRFBUPTUz
IExFTj00NyANClsgICAzMS4yMTYwNDZdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElO
PSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRP
Uz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTI1OTE3IERQ
VD01MyBMRU49NDcgDQpbICAgMzEuMjMyMDk0XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9D
OiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02
NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0xMTkx
MCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjIzMjExMl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4u
IEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBM
RU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9
MTE5MTAgRFBUPTUzIExFTj00NyANClsgICAzMS4zMDQ0MDZdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTc1IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTE0NjE4IERQVD01MyBMRU49NTUgDQpbICAgMzEuMzA0NDIzXSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj03NSBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0xNDYxOCBEUFQ9NTMgTEVOPTU1IA0KWyAgIDMxLjUyNTg0M10gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NjIgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9NTcwNjYgRFBUPTUzIExFTj00MiANClsgICAzMS41MjU4NTldIEZXOiBp
cG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERT
VD04OC4xNTkuMS4yMDEgTEVOPTYyIFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBE
RiBQUk9UTz1VRFAgU1BUPTU3MDY2IERQVD01MyBMRU49NDIgDQpbICAgMzMuMzcwMzc3XSBF
WFQ0LWZzIChzZGIxKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1v
ZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDM4LjcwODExMF0g
Rlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIu
MjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJ
RD0wIERGIFBST1RPPVVEUCBTUFQ9NTkwODYgRFBUPTUzIExFTj00NyANClsgICAzOC43NDA3
MDVdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5
LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9
NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTU5MDg2IERQVD01MyBMRU49NDcgDQpbICAgNDAu
Njk5ODM5XSBGVzogaXBtYXNxLCBGb3J3YXJkIC4uIEVvQzogSU49ZXRoMSBPVVQ9ZXRoMCBN
QUM9NDA6NjE6ODY6ZjQ6Njc6ZDg6MDA6MTM6ZTg6Yjg6MDM6N2Y6MDg6MDAgU1JDPTE3Mi4x
Ni4xLjIwIERTVD02NC40LjQ0LjcyIExFTj00MCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEy
NyBJRD0xNTY2OSBERiBQUk9UTz1UQ1AgU1BUPTUyMDU5IERQVD0xODYzIFdJTkRPVz0wIFJF
Uz0weDAwIEFDSyBSU1QgVVJHUD0wIA0KWyAgIDQwLjg0MzAxNl0gWEVOQlVTOiBVbmFibGUg
dG8gcmVhZCBjcHUgc3RhdGUNClsgICA0MC44NTk3NjZdIFhFTkJVUzogVW5hYmxlIHRvIHJl
YWQgY3B1IHN0YXRlDQpbICAgNDAuODU5OTQzXSBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNw
dSBzdGF0ZQ0KWyAgIDQwLjg2MDE2NV0gWEVOQlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3Rh
dGUNClsgICA0MC44NjAzMjRdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlDQpb
ICAgNDAuODYwNTIxXSBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQ0KWyAgIDQ3
LjI1NTc2NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04
OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NzAgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD02NCBJRD05Mzk5IERGIFBST1RPPVVEUCBTUFQ9NTYzNzAgRFBUPTUzIExFTj01MCAN
ClsgICA0Ny4yODQzOTJdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRo
MCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTcwIFRPUz0weDAwIFBS
RUM9MHgwMCBUVEw9NjQgSUQ9OTQyOCBERiBQUk9UTz1VRFAgU1BUPTM4ODQ4IERQVD01MyBM
RU49NTAgDQpbICAgNDcuMzE1MzE3XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0g
T1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj03MCBUT1M9
MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTk0NTkgREYgUFJPVE89VURQIFNQVD01NzIzMCBE
UFQ9NTMgTEVOPTUwIA0KWyAgIDQ3LjM0NjAwMF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVv
QzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49
NzAgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD05NDg5IERGIFBST1RPPVVEUCBTUFQ9
Mzc5MTkgRFBUPTUzIExFTj01MCANClsgICA2MC44OTEzMzRdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTI0OTA3IERQVD01MyBMRU49NDcgDQpbICAgNjAuOTE5ODUzXSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0yNDkwNyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDYwLjk0OTY0Ml0gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NjAgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9MzYwMTEgRFBUPTUzIExFTj00MCANClsgICA2MC45NzkzNzZdIEZXOiBp
cG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERT
VD04OC4xNTkuMS4yMDEgTEVOPTYwIFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBE
RiBQUk9UTz1VRFAgU1BUPTM2MDExIERQVD01MyBMRU49NDAgDQpbICAgNjEuMDA5MTkwXSBG
VzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4y
NSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElE
PTAgREYgUFJPVE89VURQIFNQVD00MjgzMiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDYxLjAzODk4
M10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTku
NzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02
NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NDI4MzIgRFBUPTUzIExFTj00NyANClsgICA2MS4w
NzQzNzFdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODgu
MTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBU
VEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTIzNDYxIERQVD01MyBMRU49NDcgDQpbICAg
NjEuMTAzNzU1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JD
PTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4
MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0yMzQ2MSBEUFQ9NTMgTEVOPTQ3IA0K
WyAgIDYxLjEzNzA0MV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgw
IFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJF
Qz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NTY1MzIgRFBUPTUzIExFTj00
NyANClsgICA2MS4xNjY1NjNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9
ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAw
IFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTU2NTMyIERQVD01MyBM
RU49NDcgDQpbICAgNjEuMTk5NzQ5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0g
T1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9
MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0xNzIxMyBEUFQ9
NTMgTEVOPTQ3IA0KWyAgIDYxLjIyOTkzN10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzog
SU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49Njcg
VE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MTcyMTMg
RFBUPTUzIExFTj00NyANClsgICA2MS4yNzc2ODNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBF
b0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVO
PTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTgy
MzEgRFBUPTUzIExFTj00NyANClsgICA2MS4zMDYyMjldIEZXOiBpcG1hc3EsIE91dHB1dCAu
LiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEg
TEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BU
PTgyMzEgRFBUPTUzIExFTj00NyANClsgICA2MS4zNDcxMTVdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTEyMzk3IERQVD01MyBMRU49NDcgDQpbICAgNjEuMzc2MzI0XSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0xMjM5NyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDYxLjQ0ODcyOF0gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NzUgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9NjM3NiBEUFQ9NTMgTEVOPTU1IA0KWyAgIDYxLjQ3ODIyOV0gRlc6IGlw
bWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNU
PTg4LjE1OS4xLjIwMSBMRU49NzUgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERG
IFBST1RPPVVEUCBTUFQ9NjM3NiBEUFQ9NTMgTEVOPTU1IA0KWyAgIDYxLjY5Njc1M10gRlc6
IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUg
RFNUPTg4LjE1OS4xLjIwMCBMRU49NjIgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0w
IERGIFBST1RPPVVEUCBTUFQ9NDQ5NjMgRFBUPTUzIExFTj00MiANClsgICA2MS43MjY2NjBd
IEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5Ljcy
LjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTYyIFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQg
SUQ9MCBERiBQUk9UTz1VRFAgU1BUPTQ0OTYzIERQVD01MyBMRU49NDIgDQo=
------------0B61A709518B22542
Content-Type: text/plain;
 name="xm-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xm-dmesg.txt"

ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkN
CihYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNCihYRU4pIFBy
b2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj
MyAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
NV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQ
SUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNf
aWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNSAwOjEwIEFQSUMgdmVyc2lv
biAxNg0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBd
IGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDYsIHZlcnNpb24gMzMs
IGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRb
MHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pDQooWEVOKSBJT0FQSUNb
MV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQt
NTUNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2ly
cSAyIGRmbCBkZmwpDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5
IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3Zl
cnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJ
OiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBG
bGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MNCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBi
YXNlOiAweGZlZDAwMDAwDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNl
IGUwMDAwMDAwIHNlZ21lbnQgMCBidXNlcyAwIC0gMjU1DQooWEVOKSBQQ0k6IE5vdCB1c2lu
ZyBNTUNPTkZJRy4NCihYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCihYRU4pIFVzaW5nIEFD
UEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgbWFw
cGVkIEFQSUMgdG8gZmZmZjgyYzNmZmZmZTAwMCAoZmVlMDAwMDApDQooWEVOKSBtYXBwZWQg
SU9BUElDIHRvIGZmZmY4MmMzZmZmZmQwMDAgKGZlYzAwMDAwKQ0KKFhFTikgbWFwcGVkIElP
QVBJQyB0byBmZmZmODJjM2ZmZmZjMDAwIChmZWMyMDAwMCkNCihYRU4pIElSUSBsaW1pdHM6
IDU2IEdTSSwgMTExMiBNU0kvTVNJLVgNCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENy
ZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERldGVjdGVkIDMyMDAuMTYwIE1IeiBw
cm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgQU1EIEZh
bTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkDQooWEVOKSBBTUQtVmk6IEZv
dW5kIE1TSSBjYXBhYmlsaXR5IGJsb2NrIA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0K
KFhFTikgQU1ELVZpOiAgU2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAw
eDEwMA0KKFhFTikgQU1ELVZpOiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBDaGVj
a1N1bSAweDY2DQooWEVOKSBBTUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1WaTog
IE9FTV9UYWJsZV9JZCBSRDg5MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDIw
MjAzMQ0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6ICBD
cmVhdG9yX1JldmlzaW9uIDB4MA0KKFhFTikgQU1ELVZpOiBJVlJTIEJsb2NrOg0KKFhFTikg
QU1ELVZpOiAgVHlwZSAweDEwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDNlDQooWEVOKSBB
TUQtVmk6ICBMZW5ndGggMHhkMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4Mg0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgwIC0+IDB4Mg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4p
IEFNRC1WaTogIERldl9JZCAweGIwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDIN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTAwDQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHhhMDAgLT4gMHhhMDcNCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MjgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5MDANCihYRU4pIEFNRC1WaTogIEZs
YWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1W
aTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgzMA0KKFhFTikgQU1ELVZp
OiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikg
QU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDgwMA0KKFhFTikg
QU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0K
KFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDUwDQoo
WEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
NjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQzDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHg3MDgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIFJhbmdlOiAweDcwOCAtPiAweDdmZg0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IEFsaWFzOiAweDcwMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4p
IEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1OA0KKFhFTikg
QU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0K
KFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDUwMA0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6
IDB4NTAwIC0+IDB4NTAxDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhF
TikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDY4DQooWEVO
KSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NDAw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5n
ZTogMHg0MDAgLT4gMHg0MDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQoo
WEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4ODgNCihY
RU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5
MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFu
Z2U6IDB4OTAgLT4gMHg5Mg0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihY
RU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5OA0KKFhF
TikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4
OTggLT4gMHg5YQ0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMA0KKFhFTikgQU1E
LVZpOiAgRmxhZ3MgMHhkNw0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihY
RU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMw0KKFhF
TikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweGE0
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQzDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgMHgzMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIFJhbmdlOiAweDMwMCAtPiAweDNmZg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIEFs
aWFzOiAweGE0DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1E
LVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweGE1DQooWEVOKSBBTUQt
Vmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVO
KSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTgNCihYRU4p
IEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhOQ0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAw
eDEwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweGIwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHhiMCAtPiAweGIyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCAw
eDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0OA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHhkNw0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0OA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAwMCwgaW50ZXJ1cHQg
dGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVu
dHJ5OiBkZXZpY2UgaWQgPSAweDAwMDEsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDAN
CihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgw
MDAyLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBk
ZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAxMCwgaW50ZXJ1cHQgdGFibGUg
PSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBk
ZXZpY2UgaWQgPSAweDAwMTgsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4p
IEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDI4LCBp
bnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2Ug
dGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAzMCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0
ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2Ug
aWQgPSAweDAwNTAsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1W
aTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDU4LCBpbnRlcnVw
dCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUg
ZW50cnk6IGRldmljZSBpZCA9IDB4MDA2OCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAw
MA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAw
eDAwODgsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRk
IGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDkwLCBpbnRlcnVwdCB0YWJs
ZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6
IGRldmljZSBpZCA9IDB4MDA5MSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhF
TikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwOTIs
IGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmlj
ZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDk4LCBpbnRlcnVwdCB0YWJsZSA9IDB4
MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmlj
ZSBpZCA9IDB4MDA5OSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1E
LVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwOWEsIGludGVy
dXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJs
ZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMGEwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFl
MDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9
IDB4MDBhMywgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBB
ZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYTQsIGludGVydXB0IHRh
YmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRy
eTogZGV2aWNlIGlkID0gMHgwMGE1LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQoo
WEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBh
OCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2
aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYTksIGludGVydXB0IHRhYmxlID0g
MHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2
aWNlIGlkID0gMHgwMGIwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBB
TUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBiMSwgaW50
ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRh
YmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYjIsIGludGVydXB0IHRhYmxlID0gMHgyNGRm
MWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlk
ID0gMHgwMTAwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6
IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwMCwgaW50ZXJ1cHQg
dGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVu
dHJ5OiBkZXZpY2UgaWQgPSAweDA0MDEsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDAN
CihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgw
NDAyLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBk
ZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwMywgaW50ZXJ1cHQgdGFibGUg
PSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBk
ZXZpY2UgaWQgPSAweDA0MDQsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4p
IEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNDA1LCBp
bnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2Ug
dGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwNiwgaW50ZXJ1cHQgdGFibGUgPSAweDI0
ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2Ug
aWQgPSAweDA0MDcsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1W
aTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNTAwLCBpbnRlcnVw
dCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUg
ZW50cnk6IGRldmljZSBpZCA9IDB4MDUwMSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAw
MA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAw
eDA2MDAsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRk
IGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNzAwLCBpbnRlcnVwdCB0YWJs
ZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6
IGRldmljZSBpZCA9IDB4MDgwMCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhF
TikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDA5MDAs
IGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmlj
ZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwYTAwLCBpbnRlcnVwdCB0YWJsZSA9IDB4
MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmlj
ZSBpZCA9IDB4MGEwMSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1E
LVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBhMDIsIGludGVy
dXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJs
ZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwYTAzLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFl
MDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9
IDB4MGEwNCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBB
ZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBhMDUsIGludGVydXB0IHRh
YmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRy
eTogZGV2aWNlIGlkID0gMHgwYTA2LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQoo
WEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MGEw
NywgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2
aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBiMDAsIGludGVydXB0IHRhYmxlID0g
MHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogSU9NTVUgMCBFbmFibGVkLg0KKFhFTikgQU1E
LVZpOiBFbmFibGluZyBnbG9iYWwgdmVjdG9yIG1hcA0KKFhFTikgSS9PIHZpcnR1YWxpc2F0
aW9uIGVuYWJsZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikgR2V0dGlu
ZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0K
KFhFTikgR2V0dGluZyBJRDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihYRU4pIEdl
dHRpbmcgTFZUMTogNDAwDQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0KKFhFTikg
RVNSIHZhbHVlIGJlZm9yZSBlbmFibGluZyB2ZWN0b3I6IDB4MDAwMDAwMDQgIGFmdGVyOiAw
eDAwMDAwMDAwDQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2lu
ZyBuZXcgQUNLIG1ldGhvZA0KKFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1B
UElDIChhcGljaWQtcGluKSA2LTAsIDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYt
MjEsIDYtMjIsIDYtMjMsIDctMCwgNy0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03
LCA3LTgsIDctOSwgNy0xMCwgNy0xMSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwg
Ny0xNywgNy0xOCwgNy0xOSwgNy0yMCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwg
Ny0yNiwgNy0yNywgNy0yOCwgNy0yOSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhF
TikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0t
MQ0KKFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBv
ZiBJTy1BUElDICM2IHJlZ2lzdGVyczogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAj
NyByZWdpc3RlcnM6IDMyLg0KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uDQooWEVOKSBJTyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMDogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlk
OiAwNg0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4u
Li4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAx
NzgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAw
MTcNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4u
Li4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAj
MDI6IDA2MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhF
TikgLi4uLiByZWdpc3RlciAjMDM6IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJv
b3QgRFQgICAgOiAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4p
ICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAg
DQooWEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDAxIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
MzANCihYRU4pICAwMiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IEYwDQooWEVOKSAgMDMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICAzOA0KKFhFTikgIDA0IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgRjENCihYRU4pICAwNSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDQwDQooWEVOKSAgMDYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA0OA0KKFhFTikgIDA3IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgNTANCihYRU4pICAwOCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDU4DQooWEVOKSAgMDkgMDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEg
ICAgMSAgICA2MA0KKFhFTikgIDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgNjgNCihYRU4pICAwYiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIDcwDQooWEVOKSAgMGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICA3OA0KKFhFTikgIDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgODgNCihYRU4pICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDkwDQooWEVOKSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAw
ICAgIDEgICAgMSAgICA5OA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVO
KSAuLi4uIHJlZ2lzdGVyICMwMDogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlz
aWNhbCBBUElDIGlkOiAwNw0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDAN
CihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMTogMDAxRjgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9u
IGVudHJpZXM6IDAwMUYNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAx
DQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4u
LiByZWdpc3RlciAjMDI6IDAwMDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0
aW9uOiAwMA0KKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIg
TG9nIFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhF
TikgIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDAzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMDUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDA2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMDggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDA5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMGIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDBjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMGUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQg
aW5kZXhpbmcNCihYRU4pIElSUSB0byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4g
MDoyDQooWEVOKSBJUlE0OCAtPiAwOjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJR
MjQxIC0+IDA6NA0KKFhFTikgSVJRNjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihY
RU4pIElSUTgwIC0+IDA6Nw0KKFhFTikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAw
OjkNCihYRU4pIElSUTEwNCAtPiAwOjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikg
SVJRMTIwIC0+IDA6MTINCihYRU4pIElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4g
MDoxNA0KKFhFTikgSVJRMTUyIC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBp
bnRlcnJ1cHRzLg0KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4u
Li4uIENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjE4NjggTUh6Lg0KKFhFTikgLi4uLi4gaG9z
dCBidXMgY2xvY2sgc3BlZWQgaXMgMjAwLjAxMTUgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3Nj
YWxlID0gMHgwMDAwQ0NENw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTBdIFBsYXRmb3Jt
IHRpbWVyIGFwcGVhcnMgdG8gaGF2ZSB1bmV4cGVjdGVkbHkgd3JhcHBlZCAxMCBvciBtb3Jl
IHRpbWVzLg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTBdIFBsYXRmb3JtIHRpbWVyIGlz
IDE0LjMxOE1IeiBIUEVUDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0gQWxsb2NhdGVk
IGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0g
SFZNOiBBU0lEcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTBdIFNWTTog
U3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6
MTBdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6
MjU6MTBdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBWaXJ0dWFsaXNhdGlvbg0KKFhF
TikgWzIwMTItMDEtMTIgMTI6MjU6MTBdICAtIE5leHQtUklQIFNhdmVkIG9uICNWTUVYSVQN
CihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEwXSAgLSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVy
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0gSFZNOiBTVk0gZW5hYmxlZA0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTBdIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIGRl
dGVjdGVkLg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MDldIG1hc2tlZCBFeHRJTlQgb24g
Q1BVIzENCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjA5XSBtYXNrZWQgRXh0SU5UIG9uIENQ
VSMyDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNTowOV0gbWFza2VkIEV4dElOVCBvbiBDUFUj
Mw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MDldIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzQN
CihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjA5XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM1DQoo
WEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0gQnJvdWdodCB1cCA2IENQVXMNCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjEwXSBIUEVUJ3MgTVNJIG1vZGUgaGFzbid0IGJlZW4gc3VwcG9y
dGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBlbmFibGVkLg0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTBdIEFDUEkgc2xlZXAgbW9kZXM6IFMzDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxMF0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5n
IGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTBdIG1jaGVja19wb2xsOiBN
YWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsyMDEyLTAxLTEy
IDEyOjI1OjEwXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0
LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0gKioq
IExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIFhl
biAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzINCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjExXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAw
MCAtPiAweDJiNWEwMDANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBQSFlTSUNBTCBN
RU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIERvbTAg
YWxsb2MuOiAgIDAwMDAwMDAyNDQwMDAwMDAtPjAwMDAwMDAyNDgwMDAwMDAgKDI0NDA3OSBw
YWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIElu
aXQuIHJhbWRpc2s6IDAwMDAwMDAyNGY5NmYwMDAtPjAwMDAwMDAyNGZmZmY0MDANCihYRU4p
IFsyMDEyLTAxLTEyIDEyOjI1OjExXSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAw
MDAwMC0+ZmZmZmZmZmY4MmI1YTAwMA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdICBJ
bml0LiByYW1kaXNrOiBmZmZmZmZmZjgyYjVhMDAwLT5mZmZmZmZmZjgzMWVhNDAwDQooWEVO
KSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODMxZWIw
MDAtPmZmZmZmZmZmODMzZWIwMDANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSAgU3Rh
cnQgaW5mbzogICAgZmZmZmZmZmY4MzNlYjAwMC0+ZmZmZmZmZmY4MzNlYjRiNA0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTFdICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzM2VjMDAw
LT5mZmZmZmZmZjgzNDBiMDAwDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIEJvb3Qg
c3RhY2s6ICAgIGZmZmZmZmZmODM0MGIwMDAtPmZmZmZmZmZmODM0MGMwMDANCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjExXSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+
ZmZmZmZmZmY4MzgwMDAwMA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdICBFTlRSWSBB
RERSRVNTOiBmZmZmZmZmZjgxZWU1MjAwDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0g
RG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDAwLCByb290
IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDAwMiwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMTAsIHJvb3QgdGFi
bGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwMDE4LCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAyOCwgcm9vdCB0YWJsZSA9
IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDAwMzAsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDUwLCByb290IHRhYmxlID0gMHgy
NGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEt
MTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDA1OCwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjgsIHJvb3QgdGFibGUgPSAweDI0ZGUy
ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAx
MjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
MDg4LCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5MCwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1
OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTIs
IHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwMDk4LCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5YSwgcm9v
dCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDAwYTAsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGEzLCByb290IHRh
YmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDBhNCwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTUsIHJvb3QgdGFibGUg
PSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMGE4LCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBiMCwgcm9vdCB0YWJsZSA9IDB4
MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAx
LTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwYjIsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBObyBpb21t
dSBmb3IgZGV2aWNlIDAwOjE4LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQt
Vmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDA6MTguMQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6
MjU6MTFdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDoxOC4yDQooWEVOKSBbMjAx
Mi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwOjE4LjMN
CihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZp
Y2UgMDA6MTguNA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMCwgcm9vdCB0YWJsZSA9IDB4MjRk
ZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEy
IDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDA0MDEsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAyLCByb290IHRhYmxlID0gMHgyNGRlMmQw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6
MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQw
Mywgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDQsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNTox
MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA1LCBy
b290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MDQwNiwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDcsIHJvb3Qg
dGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHgwNTAwLCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDUwMSwgcm9vdCB0YWJs
ZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDA2MDAsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCByb290IHRhYmxlID0g
MHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MDgwMCwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA5MDAsIHJvb3QgdGFibGUgPSAweDI0
ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwYTAwLCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MjRkZTJk
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBh
MDIsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAzLCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6
MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwg
cm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDBhMDUsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA2LCByb290
IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MGEwNywgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBiMDAsIHJvb3QgdGFi
bGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wMS0xMiAxMjoyNToxMV0gU2NydWJiaW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLmRvbmUuDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gWGVuIHRyYWNlIGJ1ZmZl
cnM6IGRpc2FibGVkDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gU3RkLiBMb2dsZXZl
bDogQWxsDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gR3Vlc3QgTG9nbGV2ZWw6IE5v
dGhpbmcgKFJhdGUtbGltaXRlZDogRXJyb3JzIGFuZCB3YXJuaW5ncykNCihYRU4pIFsyMDEy
LTAxLTEyIDEyOjI1OjEzXSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5
cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4p
IFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBGcmVlZCAyMjBrQiBpbml0IG1lbW9yeS4NCihYRU4p
IFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNi05IC0+IDB4NjAgLT4gSVJRIDkgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTNdIHRyYXBzLmM6MjQzMjpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBlZmYyZmVmMzFmMGMgdG8gMHgwMDAwMDAw
MDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNl
IDAwOjAwLjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAw
MDowMC4yDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6
MDIuMA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjAz
LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDowNS4w
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6MDYuMA0K
KFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjBhLjANCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDowYi4wDQooWEVO
KSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6MGQuMA0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjExLjANCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDoxMi4wDQooWEVOKSBbMjAx
Mi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6MTIuMg0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjEzLjANCihYRU4pIFsyMDEyLTAx
LTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDoxMy4yDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6MTQuMA0KKFhFTikgWzIwMTItMDEtMTIg
MTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjE0LjMNCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDoxNC40DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoy
NToxM10gUENJIGFkZCBkZXZpY2UgMDA6MTQuNQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6
MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjE1LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEz
XSBQQ0kgYWRkIGRldmljZSAwMDoxNi4wDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10g
UENJIGFkZCBkZXZpY2UgMDA6MTYuMg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBD
SSBhZGQgZGV2aWNlIDAwOjE4LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kg
YWRkIGRldmljZSAwMDoxOC4xDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFk
ZCBkZXZpY2UgMDA6MTguMg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQg
ZGV2aWNlIDAwOjE4LjMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRl
dmljZSAwMDoxOC40DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZp
Y2UgMGI6MDAuMA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNl
IDBhOjAwLjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAw
YTowMC4xDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMGE6
MDAuMg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDBhOjAw
LjMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwYTowMC40
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMGE6MDAuNQ0K
KFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDBhOjAwLjYNCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwYTowMC43DQooWEVO
KSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDk6MDAuMA0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDA4OjAwLjANCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwNjowMC4wDQooWEVOKSBbMjAx
Mi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDc6MDEuMA0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDA3OjAxLjENCihYRU4pIFsyMDEyLTAx
LTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwNzowMS4yDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDU6MDAuMA0KKFhFTikgWzIwMTItMDEtMTIg
MTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDA1OjAwLjENCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwNDowMC4wDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoy
NToxM10gUENJIGFkZCBkZXZpY2UgMDQ6MDAuMQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6
MTNdIFBDSSBhZGQgZGV2aWNlIDA0OjAwLjINCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEz
XSBQQ0kgYWRkIGRldmljZSAwNDowMC4zDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10g
UENJIGFkZCBkZXZpY2UgMDQ6MDAuNA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBD
SSBhZGQgZGV2aWNlIDA0OjAwLjUNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kg
YWRkIGRldmljZSAwNDowMC42DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFk
ZCBkZXZpY2UgMDQ6MDAuNw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQg
ZGV2aWNlIDAzOjA2LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBJT0FQSUNbMF06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi04IC0+IDB4NTggLT4gSVJRIDggTW9kZTowIEFj
dGl2ZTowKQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTEzIC0+IDB4ODggLT4gSVJRIDEzIE1vZGU6MCBBY3RpdmU6
MCkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0yOCAtPiAweGEwIC0+IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctMjkgLT4gMHhhOCAtPiBJUlEgNTMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTNdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTMwIC0+IDB4YjAgLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTAxLTEyIDEyOjI1OjEzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0x
NiAtPiAweGI4IC0+IElSUSAxNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxNF0gcGh5c2Rldi5jOjE1NTogZG9tMDogd3JvbmcgbWFwX3BpcnEgdHlwZSAz
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxNF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDYtMjIgLT4gMHg0MSAtPiBJUlEgMjIgTW9kZToxIEFjdGl2ZToxKQ0KKFhF
TikgWzIwMTItMDEtMTIgMTI6MjU6MTRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTE5IC0+IDB4NDkgLT4gSVJRIDQzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny0xOCAtPiAweDUxIC0+IElSUSA0MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
MS0xMiAxMjoyNToxNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTcg
LT4gMHg1OSAtPiBJUlEgNDEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDEtMTIg
MTI6MjU6MTRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE2IC0+IDB4
NjEgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1
OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy05IC0+IDB4NjkgLT4g
SVJRIDMzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE0XSBJ
T0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy04IC0+IDB4NzEgLT4gSVJRIDMy
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNb
MV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAweDc5IC0+IElSUSA0NiBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxNF0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjEgLT4gMHg4MSAtPiBJUlEgNDUgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTRdIElPQVBJQ1sxXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg3LTIwIC0+IDB4ODkgLT4gSVJRIDQ0IE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy03IC0+IDB4OTEgLT4gSVJRIDMxIE1vZGU6MSBBY3RpdmU6MSkNCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy02IC0+IDB4OTkgLT4gSVJRIDMwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny01IC0+IDB4YTEgLT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAx
LTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy00IC0+
IDB4YTkgLT4gSVJRIDI4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjE0XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOSAtPiAweGIx
IC0+IElSUSAxOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNTox
NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHhjOSAtPiBJ
UlEgNTEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTRdIElP
QVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4ZDkgLT4gSVJRIDE3
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE1XSBJT0FQSUNb
MF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOCAtPiAweDIyIC0+IElSUSAxOCBNb2Rl
OjEgQWN0aXZlOjEpDQo=
------------0B61A709518B22542
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------------0B61A709518B22542--



From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:39:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJvc-0001kG-A1; Thu, 12 Jan 2012 12:38:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RlJvZ-0001jT-NS
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:38:46 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326371912!8299286!1
X-Originating-IP: [188.40.164.121]
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 24944 invoked from network); 12 Jan 2012 12:38:33 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-10.tower-21.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jan 2012 12:38:33 -0000
Received: from 25-72-ftth.onsneteindhoven.nl ([88.159.72.25]:52147
	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 1RlJtA-00007F-U8; Thu, 12 Jan 2012 13:36:17 +0100
Date: Thu, 12 Jan 2012 13:38:32 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <498097597.20120112133832@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="----------0B61A709518B22542"
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
	Failed to query current memory allocation of 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

------------0B61A709518B22542
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Konrad,

Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).

It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.

dmesg and xm dmesg attached

--
Sander


Dom0 shows:
             total       used       free     shared    buffers     cached
Mem:        938860     220484     718376          0      27812      72128
-/+ buffers/cache:     120544     818316
Swap:      2097148          0    2097148


xentop:

xentop - 13:34:31   Xen 4.1.3-rc1-pre
1 domains: 1 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
Mem: 8386732k total, 1165260k used, 7221472k free    CPUs: 6 @ 3200MHz
      NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR  VBD_RSECT  VBD_WSECT SSID
  Domain-0 -----r         82    1.3    1048192   12.5   no limit       n/a     6    0        0        0    0        0        0        0          0          0    0



------------0B61A709518B22542
Content-Type: text/plain;
 name="dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="dmesg.txt"

WyAgICAwLjAwMDAwMF0gSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1c2V0DQpbICAg
IDAuMDAwMDAwXSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBjcHUNClsgICAgMC4wMDAw
MDBdIExpbnV4IHZlcnNpb24gMy4yLjAtcmMwKyAocm9vdEBzZXJ2ZWVyc3RlcnRqZSkgKGdj
YyB2ZXJzaW9uIDQuNC41IChEZWJpYW4gNC40LjUtOCkgKSAjOSBTTVAgVGh1IEphbiAxMiAx
Mjo0MDoyNCBDRVQgMjAxMg0KWyAgICAwLjAwMDAwMF0gQ29tbWFuZCBsaW5lOiByb290PS9k
ZXYvbWFwcGVyL3NlcnZlZXJzdGVydGplLXJvb3Qgcm8gdmVyYm9zZSBtZW09MTAyNE0gY29u
c29sZT1odmMwIGNvbnNvbGU9dHR5MCBub21vZGVzZXQgdmdhPTc5NCB2aWRlbz12ZXNhZmIg
ZWFybHlwcmludGs9eGVuIG1heF9sb29wPTUwIGxvb3BfbWF4X3BhcnQ9MTAgeGVuLXBjaWJh
Y2sucGFzc3Rocm91Z2g9MSB4ZW4tcGNpYmFjay5oaWRlPSgwMzowNi4wKSgwNDowMC4wKSgw
NDowMC4xKSgwNDowMC4yKSgwNDowMC4zKSgwNDowMC40KSgwNDowMC41KSgwNDowMC42KSgw
NDowMC43KSgwYTowMC4wKSgwYTowMC4xKSgwYTowMC4yKSgwYTowMC4zKSgwYTowMC40KSgw
YTowMC41KSgwYTowMC42KSgwYTowMC43KSgwNTowMC4wKSgwNTowMC4xKSgwNzowMS4wKSgw
NzowMS4xKSgwNzowMS4yKSBwY2k9cmVzb3VyY2VfYWxpZ25tZW50PTA3OjAxLjA7MDc6MDEu
MTswNzowMS4yIGRlYnVnIGRlYnVnIGxvZ2xldmVsPTEwDQpbICAgIDAuMDAwMDAwXSBGcmVl
aW5nICA5Yi0xMDAgcGZuIHJhbmdlOiAxMDEgcGFnZXMgZnJlZWQNClsgICAgMC4wMDAwMDBd
IDEtMSBtYXBwaW5nIG9uIDliLT4xMDANClsgICAgMC4wMDAwMDBdIDEtMSBtYXBwaW5nIG9u
IGFmZTkwLT4xMDAwMDANClsgICAgMC4wMDAwMDBdIFJlbGVhc2VkIDEwMSBwYWdlcyBvZiB1
bnVzZWQgbWVtb3J5DQpbICAgIDAuMDAwMDAwXSBTZXQgMzI4MTQ5IHBhZ2UocykgdG8gMS0x
IG1hcHBpbmcNClsgICAgMC4wMDAwMDBdIEJJT1MtcHJvdmlkZWQgcGh5c2ljYWwgUkFNIG1h
cDoNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwMDAwMDAwMDAgLSAwMDAwMDAwMDAw
MDliMDAwICh1c2FibGUpDQpbICAgIDAuMDAwMDAwXSAgWGVuOiAwMDAwMDAwMDAwMDliMDAw
IC0gMDAwMDAwMDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQpbICAgIDAuMDAwMDAwXSAgWGVuOiAw
MDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDBhZmU5MDAwMCAodXNhYmxlKQ0KWyAgICAwLjAw
MDAwMF0gIFhlbjogMDAwMDAwMDBhZmU5MDAwMCAtIDAwMDAwMDAwYWZlOWUwMDAgKEFDUEkg
ZGF0YSkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYWZlOWUwMDAgLSAwMDAwMDAw
MGFmZWUwMDAwIChBQ1BJIE5WUykNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwYWZl
ZTAwMDAgLSAwMDAwMDAwMGFmZjAwMDAwIChyZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdICBY
ZW46IDAwMDAwMDAwZmVjMDAwMDAgLSAwMDAwMDAwMGZlYzAxMDAwIChyZXNlcnZlZCkNClsg
ICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVjMjAwMDAgLSAwMDAwMDAwMGZlYzIxMDAw
IChyZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAwMDAwZmVlMDAwMDAgLSAw
MDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkNClsgICAgMC4wMDAwMDBdICBYZW46IDAwMDAw
MDAwZmZlMDAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkNClsgICAgMC4wMDAw
MDBdICBYZW46IDAwMDAwMDAxMDAwMDAwMDAgLSAwMDAwMDAwMjUwMDAwMDAwICh1c2FibGUp
DQpbICAgIDAuMDAwMDAwXSBlODIwIHJlbW92ZSByYW5nZTogMDAwMDAwMDA0MDAwMDAwMCAt
IGZmZmZmZmZmZmZmZmZmZmYgKHVzYWJsZSkNClsgICAgMC4wMDAwMDBdIGJvb3Rjb25zb2xl
IFt4ZW5ib290MF0gZW5hYmxlZA0KWyAgICAwLjAwMDAwMF0gTlggKEV4ZWN1dGUgRGlzYWJs
ZSkgcHJvdGVjdGlvbjogYWN0aXZlDQpbICAgIDAuMDAwMDAwXSB1c2VyLWRlZmluZWQgcGh5
c2ljYWwgUkFNIG1hcDoNClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMDAwMDAwMDAw
IC0gMDAwMDAwMDAwMDA5YjAwMCAodXNhYmxlKQ0KWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAw
MDAwMDAwMDAwOWIwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkNClsgICAgMC4w
MDAwMDBdICB1c2VyOiAwMDAwMDAwMDAwMTAwMDAwIC0gMDAwMDAwMDA0MDAwMDAwMCAodXNh
YmxlKQ0KWyAgICAwLjAwMDAwMF0gIHVzZXI6IDAwMDAwMDAwYWZlOTAwMDAgLSAwMDAwMDAw
MGFmZTllMDAwIChBQ1BJIGRhdGEpDQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDBh
ZmU5ZTAwMCAtIDAwMDAwMDAwYWZlZTAwMDAgKEFDUEkgTlZTKQ0KWyAgICAwLjAwMDAwMF0g
IHVzZXI6IDAwMDAwMDAwYWZlZTAwMDAgLSAwMDAwMDAwMGFmZjAwMDAwIChyZXNlcnZlZCkN
ClsgICAgMC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMw
MTAwMCAocmVzZXJ2ZWQpDQpbICAgIDAuMDAwMDAwXSAgdXNlcjogMDAwMDAwMDBmZWMyMDAw
MCAtIDAwMDAwMDAwZmVjMjEwMDAgKHJlc2VydmVkKQ0KWyAgICAwLjAwMDAwMF0gIHVzZXI6
IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZTAxMDAwIChyZXNlcnZlZCkNClsgICAg
MC4wMDAwMDBdICB1c2VyOiAwMDAwMDAwMGZmZTAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAo
cmVzZXJ2ZWQpDQpbICAgIDAuMDAwMDAwXSBETUkgcHJlc2VudC4NClsgICAgMC4wMDAwMDBd
IERNSTogTVNJIE1TLTc2NDAvODkwRlhBLUdENzAgKE1TLTc2NDApICAsIEJJT1MgVjEuN0I1
IDA2LzIyLzIwMTANClsgICAgMC4wMDAwMDBdIGU4MjAgdXBkYXRlIHJhbmdlOiAwMDAwMDAw
MDAwMDAwMDAwIC0gMDAwMDAwMDAwMDAxMDAwMCAodXNhYmxlKSA9PT4gKHJlc2VydmVkKQ0K
WyAgICAwLjAwMDAwMF0gZTgyMCByZW1vdmUgcmFuZ2U6IDAwMDAwMDAwMDAwYTAwMDAgLSAw
MDAwMDAwMDAwMTAwMDAwICh1c2FibGUpDQpbICAgIDAuMDAwMDAwXSBObyBBR1AgYnJpZGdl
IGZvdW5kDQpbICAgIDAuMDAwMDAwXSBsYXN0X3BmbiA9IDB4NDAwMDAgbWF4X2FyY2hfcGZu
ID0gMHg0MDAwMDAwMDANClsgICAgMC4wMDAwMDBdIGZvdW5kIFNNUCBNUC10YWJsZSBhdCBb
ZmZmZjg4MDAwMDBmZjc4MF0gZmY3ODANClsgICAgMC4wMDAwMDBdIGluaXRpYWwgbWVtb3J5
IG1hcHBlZCA6IDAgLSAwMzFlYjAwMA0KWyAgICAwLjAwMDAwMF0gQmFzZSBtZW1vcnkgdHJh
bXBvbGluZSBhdCBbZmZmZjg4MDAwMDA5OTAwMF0gOTkwMDAgc2l6ZSA4MTkyDQpbICAgIDAu
MDAwMDAwXSBpbml0X21lbW9yeV9tYXBwaW5nOiAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDAw
NDAwMDAwMDANClsgICAgMC4wMDAwMDBdICAwMDAwMDAwMDAwIC0gMDA0MDAwMDAwMCBwYWdl
IDRrDQpbICAgIDAuMDAwMDAwXSBrZXJuZWwgZGlyZWN0IG1hcHBpbmcgdGFibGVzIHVwIHRv
IDQwMDAwMDAwIEAgMjk1ODAwMC0yYjVhMDAwDQpbICAgIDAuMDAwMDAwXSB4ZW46IHNldHRp
bmcgUlcgdGhlIHJhbmdlIDJiMzgwMDAgLSAyYjVhMDAwDQpbICAgIDAuMDAwMDAwXSBSQU1E
SVNLOiAwMmI1YTAwMCAtIDAzMWViMDAwDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBSU0RQIDAw
MDAwMDAwMDAwZmIxMjAgMDAwMTQgKHYwMCBBQ1BJQU0pDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBSU0RUIDAwMDAwMDAwYWZlOTAwMDAgMDAwNDggKHYwMSBNU0kgICAgT0VNU0xJQyAgMjAx
MDA2MjIgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IEZBQ1AgMDAwMDAw
MDBhZmU5MDIwMCAwMDA4NCAodjAxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUIDAw
MDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogRFNEVCAwMDAwMDAwMGFmZTkwNWUwIDA5
NDQ5ICh2MDEgIEE3NjQwIEE3NjQwMTAwIDAwMDAwMTAwIElOVEwgMjAwNTExMTcpDQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBGQUNTIDAwMDAwMDAwYWZlOWUwMDAgMDAwNDANClsgICAgMC4w
MDAwMDBdIEFDUEk6IEFQSUMgMDAwMDAwMDBhZmU5MDM5MCAwMDA4OCAodjAxIDc2NDBNUyBB
NzY0MDEwMCAyMDEwMDYyMiBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAwLjAwMDAwMF0gQUNQSTog
TUNGRyAwMDAwMDAwMGFmZTkwNDIwIDAwMDNDICh2MDEgNzY0ME1TIE9FTU1DRkcgIDIwMTAw
NjIyIE1TRlQgMDAwMDAwOTcpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBTTElDIDAwMDAwMDAw
YWZlOTA0NjAgMDAxNzYgKHYwMSBNU0kgICAgT0VNU0xJQyAgMjAxMDA2MjIgTVNGVCAwMDAw
MDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IE9FTUIgMDAwMDAwMDBhZmU5ZTA0MCAwMDA3
MiAodjAxIDc2NDBNUyBBNzY0MDEwMCAyMDEwMDYyMiBNU0ZUIDAwMDAwMDk3KQ0KWyAgICAw
LjAwMDAwMF0gQUNQSTogU1JBVCAwMDAwMDAwMGFmZTlhNWUwIDAwMTA4ICh2MDMgQU1EICAg
IEZBTV9GXzEwIDAwMDAwMDAyIEFNRCAgMDAwMDAwMDEpDQpbICAgIDAuMDAwMDAwXSBBQ1BJ
OiBIUEVUIDAwMDAwMDAwYWZlOWE2ZjAgMDAwMzggKHYwMSA3NjQwTVMgT0VNSFBFVCAgMjAx
MDA2MjIgTVNGVCAwMDAwMDA5NykNClsgICAgMC4wMDAwMDBdIEFDUEk6IElWUlMgMDAwMDAw
MDBhZmU5YTczMCAwMDEwMCAodjAxICBBTUQgICAgIFJEODkwUyAwMDIwMjAzMSBBTUQgIDAw
MDAwMDAwKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogU1NEVCAwMDAwMDAwMGFmZTlhODMwIDAw
REE0ICh2MDEgQSBNIEkgIFBPV0VSTk9XIDAwMDAwMDAxIEFNRCAgMDAwMDAwMDEpDQpbICAg
IDAuMDAwMDAwXSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KWyAgICAw
LjAwMDAwMF0gU2Nhbm5pbmcgTlVNQSB0b3BvbG9neSBpbiBOb3J0aGJyaWRnZSAyNA0KWyAg
ICAwLjAwMDAwMF0gTm8gTlVNQSBjb25maWd1cmF0aW9uIGZvdW5kDQpbICAgIDAuMDAwMDAw
XSBGYWtpbmcgYSBub2RlIGF0IDAwMDAwMDAwMDAwMDAwMDAtMDAwMDAwMDA0MDAwMDAwMA0K
WyAgICAwLjAwMDAwMF0gSW5pdG1lbSBzZXR1cCBub2RlIDAgMDAwMDAwMDAwMDAwMDAwMC0w
MDAwMDAwMDQwMDAwMDAwDQpbICAgIDAuMDAwMDAwXSAgIE5PREVfREFUQSBbMDAwMDAwMDAz
ZmZmYjAwMCAtIDAwMDAwMDAwM2ZmZmZmZmZdDQpbICAgIDAuMDAwMDAwXSBab25lIFBGTiBy
YW5nZXM6DQpbICAgIDAuMDAwMDAwXSAgIERNQSAgICAgIDB4MDAwMDAwMTAgLT4gMHgwMDAw
MTAwMA0KWyAgICAwLjAwMDAwMF0gICBETUEzMiAgICAweDAwMDAxMDAwIC0+IDB4MDAxMDAw
MDANClsgICAgMC4wMDAwMDBdICAgTm9ybWFsICAgZW1wdHkNClsgICAgMC4wMDAwMDBdIE1v
dmFibGUgem9uZSBzdGFydCBQRk4gZm9yIGVhY2ggbm9kZQ0KWyAgICAwLjAwMDAwMF0gRWFy
bHkgbWVtb3J5IFBGTiByYW5nZXMNClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMDEw
IC0+IDB4MDAwMDAwOWINClsgICAgMC4wMDAwMDBdICAgICAwOiAweDAwMDAwMTAwIC0+IDB4
MDAwNDAwMDANClsgICAgMC4wMDAwMDBdIE9uIG5vZGUgMCB0b3RhbHBhZ2VzOiAyNjIwMjcN
ClsgICAgMC4wMDAwMDBdICAgRE1BIHpvbmU6IDY0IHBhZ2VzIHVzZWQgZm9yIG1lbW1hcA0K
WyAgICAwLjAwMDAwMF0gICBETUEgem9uZTogMiBwYWdlcyByZXNlcnZlZA0KWyAgICAwLjAw
MDAwMF0gICBETUEgem9uZTogMzkxMyBwYWdlcywgTElGTyBiYXRjaDowDQpbICAgIDAuMDAw
MDAwXSAgIERNQTMyIHpvbmU6IDQwMzIgcGFnZXMgdXNlZCBmb3IgbWVtbWFwDQpbICAgIDAu
MDAwMDAwXSAgIERNQTMyIHpvbmU6IDI1NDAxNiBwYWdlcywgTElGTyBiYXRjaDozMQ0KWyAg
ICAwLjAwMDAwMF0gQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHg4MDgNClsgICAgMC4wMDAw
MDBdIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQpbICAgIDAuMDAwMDAw
XSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAxXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0K
WyAgICAwLjAwMDAwMF0gQklPUyBidWc6IEFQSUMgdmVyc2lvbiBpcyAwIGZvciBDUFUgMC8w
eDAsIGZpeGluZyB1cCB0byAweDEwDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNw
aV9pZFsweDAyXSBsYXBpY19pZFsweDAxXSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQ
STogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNClsgICAg
MC4wMDAwMDBdIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDNdIGVu
YWJsZWQpDQpbICAgIDAuMDAwMDAwXSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA1XSBsYXBp
Y19pZFsweDA0XSBlbmFibGVkKQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogTEFQSUMgKGFjcGlf
aWRbMHgwNl0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNClsgICAgMC4wMDAwMDBdIEFDUEk6
IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNClsg
ICAgMC4wMDAwMDBdIElPQVBJQ1swXTogYXBpY19pZCA2LCB2ZXJzaW9uIDI1NSwgYWRkcmVz
cyAweGZlYzAwMDAwLCBHU0kgMC0yNTUNClsgICAgMC4wMDAwMDBdIEFDUEk6IElPQVBJQyAo
aWRbMHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pDQpbICAgIDAuMDAw
MDAwXSBJT0FQSUNbMV06IGFwaWNfaWQgNywgdmVyc2lvbiAyNTUsIGFkZHJlc3MgMHhmZWMy
MDAwMCwgR1NJIDI0LTI3OQ0KWyAgICAwLjAwMDAwMF0gQUNQSTogSU5UX1NSQ19PVlIgKGJ1
cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJxIDIgZGZsIGRmbCkNClsgICAgMC4wMDAwMDBdIEFD
UEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkgZ2xvYmFsX2lycSA5IGxvdyBsZXZl
bCkNClsgICAgMC4wMDAwMDBdIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NClsgICAg
MC4wMDAwMDBdIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAwMDBd
IEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlkZS4NClsgICAgMC4wMDAwMDBdIFVzaW5nIEFD
UEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KWyAgICAwLjAw
MDAwMF0gQUNQSTogSFBFVCBpZDogMHg4MzAwIGJhc2U6IDB4ZmVkMDAwMDANClsgICAgMC4w
MDAwMDBdIFNNUDogQWxsb3dpbmcgNiBDUFVzLCAwIGhvdHBsdWcgQ1BVcw0KWyAgICAwLjAw
MDAwMF0gbnJfaXJxc19nc2k6IDI5Ng0KWyAgICAwLjAwMDAwMF0gQWxsb2NhdGluZyBQQ0kg
cmVzb3VyY2VzIHN0YXJ0aW5nIGF0IDQwMDAwMDAwIChnYXA6IDQwMDAwMDAwOjZmZTkwMDAw
KQ0KWyAgICAwLjAwMDAwMF0gQm9vdGluZyBwYXJhdmlydHVhbGl6ZWQga2VybmVsIG9uIFhl
bg0KWyAgICAwLjAwMDAwMF0gWGVuIHZlcnNpb246IDQuMS4zLXJjMS1wcmUgKHByZXNlcnZl
LUFEKQ0KWyAgICAwLjAwMDAwMF0gc2V0dXBfcGVyY3B1OiBOUl9DUFVTOjY0IG5yX2NwdW1h
c2tfYml0czo2NCBucl9jcHVfaWRzOjYgbnJfbm9kZV9pZHM6MQ0KWyAgICAwLjAwMDAwMF0g
UEVSQ1BVOiBFbWJlZGRlZCAyNyBwYWdlcy9jcHUgQGZmZmY4ODAwM2ZmM2UwMDAgczc4Nzg0
IHI4MTkyIGQyMzYxNiB1MTEwNTkyDQpbICAgIDAuMDAwMDAwXSBwY3B1LWFsbG9jOiBzNzg3
ODQgcjgxOTIgZDIzNjE2IHUxMTA1OTIgYWxsb2M9MjcqNDA5Ng0KWyAgICAwLjAwMDAwMF0g
cGNwdS1hbGxvYzogWzBdIDAgWzBdIDEgWzBdIDIgWzBdIDMgWzBdIDQgWzBdIDUgDQpbICAg
IDAuMDAwMDAwXSBCdWlsdCAxIHpvbmVsaXN0cyBpbiBOb2RlIG9yZGVyLCBtb2JpbGl0eSBn
cm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAyNTc5MjkNClsgICAgMC4wMDAwMDBdIFBvbGlj
eSB6b25lOiBETUEzMg0KWyAgICAwLjAwMDAwMF0gS2VybmVsIGNvbW1hbmQgbGluZTogcm9v
dD0vZGV2L21hcHBlci9zZXJ2ZWVyc3RlcnRqZS1yb290IHJvIHZlcmJvc2UgbWVtPTEwMjRN
IGNvbnNvbGU9aHZjMCBjb25zb2xlPXR0eTAgbm9tb2Rlc2V0IHZnYT03OTQgdmlkZW89dmVz
YWZiIGVhcmx5cHJpbnRrPXhlbiBtYXhfbG9vcD01MCBsb29wX21heF9wYXJ0PTEwIHhlbi1w
Y2liYWNrLnBhc3N0aHJvdWdoPTEgeGVuLXBjaWJhY2suaGlkZT0oMDM6MDYuMCkoMDQ6MDAu
MCkoMDQ6MDAuMSkoMDQ6MDAuMikoMDQ6MDAuMykoMDQ6MDAuNCkoMDQ6MDAuNSkoMDQ6MDAu
NikoMDQ6MDAuNykoMGE6MDAuMCkoMGE6MDAuMSkoMGE6MDAuMikoMGE6MDAuMykoMGE6MDAu
NCkoMGE6MDAuNSkoMGE6MDAuNikoMGE6MDAuNykoMDU6MDAuMCkoMDU6MDAuMSkoMDc6MDEu
MCkoMDc6MDEuMSkoMDc6MDEuMikgcGNpPXJlc291cmNlX2FsaWdubWVudD0wNzowMS4wOzA3
OjAxLjE7MDc6MDEuMiBkZWJ1ZyBkZWJ1ZyBsb2dsZXZlbD0xMA0KWyAgICAwLjAwMDAwMF0g
UElEIGhhc2ggdGFibGUgZW50cmllczogNDA5NiAob3JkZXI6IDMsIDMyNzY4IGJ5dGVzKQ0K
WyAgICAwLjAwMDAwMF0gUGxhY2luZyA2NE1CIHNvZnR3YXJlIElPIFRMQiBiZXR3ZWVuIGZm
ZmY4ODAwM2E2MDAwMDAgLSBmZmZmODgwMDNlNjAwMDAwDQpbICAgIDAuMDAwMDAwXSBzb2Z0
d2FyZSBJTyBUTEIgYXQgcGh5cyAweDNhNjAwMDAwIC0gMHgzZTYwMDAwMA0KWyAgICAwLjAw
MDAwMF0gTWVtb3J5OiA5MzAyMTJrLzEwNDg1NzZrIGF2YWlsYWJsZSAoOTExMWsga2VybmVs
IGNvZGUsIDQ2OGsgYWJzZW50LCAxMTc4OTZrIHJlc2VydmVkLCA2MDU2ayBkYXRhLCA2NDRr
IGluaXQpDQpbICAgIDAuMDAwMDAwXSBTTFVCOiBHZW5zbGFicz0xNSwgSFdhbGlnbj02NCwg
T3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9NiwgTm9kZXM9MQ0KWyAgICAwLjAwMDAw
MF0gSGllcmFyY2hpY2FsIFJDVSBpbXBsZW1lbnRhdGlvbi4NClsgICAgMC4wMDAwMDBdIE5S
X0lSUVM6NDM1MiBucl9pcnFzOjE1MzYgMTYNClsgICAgMC4wMDAwMDBdIHhlbjogc2NpIG92
ZXJyaWRlOiBnbG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTENClsgICAgMC4wMDAw
MDBdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDkgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsg
ICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9OSAtPiBpcnE9OSAoZ3NpPTkpDQpbICAgIDAu
MDAwMDAwXSB4ZW46IGFjcGkgc2NpIDkNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9
MSAtPiBpcnE9MSAoZ3NpPTEpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTIgLT4g
aXJxPTIgKGdzaT0yKQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT0zIC0+IGlycT0z
IChnc2k9MykNClsgICAgMC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NCAtPiBpcnE9NCAoZ3Np
PTQpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0tPiBwaXJxPTUgLT4gaXJxPTUgKGdzaT01KQ0K
WyAgICAwLjAwMDAwMF0geGVuOiAtLT4gcGlycT02IC0+IGlycT02IChnc2k9NikNClsgICAg
MC4wMDAwMDBdIHhlbjogLS0+IHBpcnE9NyAtPiBpcnE9NyAoZ3NpPTcpDQpbICAgIDAuMDAw
MDAwXSB4ZW46IC0tPiBwaXJxPTggLT4gaXJxPTggKGdzaT04KQ0KWyAgICAwLjAwMDAwMF0g
eGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA5IGZvciBnc2kgOQ0KWyAgICAwLjAw
MDAwMF0geGVuOiAtLT4gcGlycT05IC0+IGlycT05IChnc2k9OSkNClsgICAgMC4wMDAwMDBd
IHhlbjogLS0+IHBpcnE9MTAgLT4gaXJxPTEwIChnc2k9MTApDQpbICAgIDAuMDAwMDAwXSB4
ZW46IC0tPiBwaXJxPTExIC0+IGlycT0xMSAoZ3NpPTExKQ0KWyAgICAwLjAwMDAwMF0geGVu
OiAtLT4gcGlycT0xMiAtPiBpcnE9MTIgKGdzaT0xMikNClsgICAgMC4wMDAwMDBdIHhlbjog
LS0+IHBpcnE9MTMgLT4gaXJxPTEzIChnc2k9MTMpDQpbICAgIDAuMDAwMDAwXSB4ZW46IC0t
PiBwaXJxPTE0IC0+IGlycT0xNCAoZ3NpPTE0KQ0KWyAgICAwLjAwMDAwMF0geGVuOiAtLT4g
cGlycT0xNSAtPiBpcnE9MTUgKGdzaT0xNSkNClsgICAgMC4wMDAwMDBdIENvbnNvbGU6IGNv
bG91ciBkdW1teSBkZXZpY2UgODB4MjUNClsgICAgMC4wMDAwMDBdIGNvbnNvbGUgW3R0eTBd
IGVuYWJsZWQsIGJvb3Rjb25zb2xlIGRpc2FibGVkDQpbICAgIDAuMDAwMDAwXSBjb25zb2xl
IFtodmMwXSBlbmFibGVkDQpbICAgIDAuMDAwMDAwXSBMb2NrIGRlcGVuZGVuY3kgdmFsaWRh
dG9yOiBDb3B5cmlnaHQgKGMpIDIwMDYgUmVkIEhhdCwgSW5jLiwgSW5nbyBNb2xuYXINClsg
ICAgMC4wMDAwMDBdIC4uLiBNQVhfTE9DS0RFUF9TVUJDTEFTU0VTOiAgOA0KWyAgICAwLjAw
MDAwMF0gLi4uIE1BWF9MT0NLX0RFUFRIOiAgICAgICAgICA0OA0KWyAgICAwLjAwMDAwMF0g
Li4uIE1BWF9MT0NLREVQX0tFWVM6ICAgICAgICA4MTkxDQpbICAgIDAuMDAwMDAwXSAuLi4g
Q0xBU1NIQVNIX1NJWkU6ICAgICAgICAgIDQwOTYNClsgICAgMC4wMDAwMDBdIC4uLiBNQVhf
TE9DS0RFUF9FTlRSSUVTOiAgICAgMTYzODQNClsgICAgMC4wMDAwMDBdIC4uLiBNQVhfTE9D
S0RFUF9DSEFJTlM6ICAgICAgMzI3NjgNClsgICAgMC4wMDAwMDBdIC4uLiBDSEFJTkhBU0hf
U0laRTogICAgICAgICAgMTYzODQNClsgICAgMC4wMDAwMDBdICBtZW1vcnkgdXNlZCBieSBs
b2NrIGRlcGVuZGVuY3kgaW5mbzogNTgyMyBrQg0KWyAgICAwLjAwMDAwMF0gIHBlciB0YXNr
LXN0cnVjdCBtZW1vcnkgZm9vdHByaW50OiAxOTIwIGJ5dGVzDQpbICAgIDAuMDAwMDAwXSBY
ZW46IHVzaW5nIHZjcHVvcCB0aW1lciBpbnRlcmZhY2UNClsgICAgMC4wMDAwMDBdIGluc3Rh
bGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMA0KWyAgICAwLjAwMDAwMF0gRGV0ZWN0ZWQgMzIw
MC4xNjAgTUh6IHByb2Nlc3Nvci4NClsgICAgMC4wMDA5OTldIENhbGlicmF0aW5nIGRlbGF5
IGxvb3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5j
eS4uIDY0MDAuMzIgQm9nb01JUFMgKGxwaj0zMjAwMTYwKQ0KWyAgICAwLjAwMDk5OV0gcGlk
X21heDogZGVmYXVsdDogMzI3NjggbWluaW11bTogMzAxDQpbICAgIDAuMDAwOTk5XSBTZWN1
cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQNClsgICAgMC4wMDA5OTldIFNFTGludXg6ICBJ
bml0aWFsaXppbmcuDQpbICAgIDAuMDAwOTk5XSBTRUxpbnV4OiAgU3RhcnRpbmcgaW4gcGVy
bWlzc2l2ZSBtb2RlDQpbICAgIDAuMDAwOTk5XSBEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBl
bnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA4LCAxMDQ4NTc2IGJ5dGVzKQ0KWyAgICAwLjAwMDk5
OV0gSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUy
NDI4OCBieXRlcykNClsgICAgMC4wMDA5OTldIE1vdW50LWNhY2hlIGhhc2ggdGFibGUgZW50
cmllczogMjU2DQpbICAgIDAuMDAxMzc4XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBj
cHVhY2N0DQpbICAgIDAuMDAxMzg0XSBJbml0aWFsaXppbmcgY2dyb3VwIHN1YnN5cyBmcmVl
emVyDQpbICAgIDAuMDAxNDQ1XSB0c2VnOiAwMDAwMDAwMDAwDQpbICAgIDAuMDAxNDY2XSBD
UFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMA0KWyAgICAwLjAwMTQ3MF0gQ1BVOiBQcm9j
ZXNzb3IgQ29yZSBJRDogMA0KWyAgICAwLjAwMjI3MV0gQUNQSTogQ29yZSByZXZpc2lvbiAy
MDExMDYyMw0KWyAgICAwLjAxMzEzMl0gY3B1IDAgc3BpbmxvY2sgZXZlbnQgaXJxIDI5Nw0K
WyAgICAwLjAxMzI1OF0gUGVyZm9ybWFuY2UgRXZlbnRzOiBCcm9rZW4gUE1VIGhhcmR3YXJl
IGRldGVjdGVkLCB1c2luZyBzb2Z0d2FyZSBldmVudHMgb25seS4NClsgICAgMC4wMTM1MDFd
IE1DRTogSW4ta2VybmVsIE1DRSBkZWNvZGluZyBlbmFibGVkLg0KWyAgICAwLjAxMzUxNV0g
Tk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHUwKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBlbmFi
bGVkDQpbICAgIDAuMDEzNjg0XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDENClsg
ICAgMC4wMTM3MDRdIGNwdSAxIHNwaW5sb2NrIGV2ZW50IGlycSAzMDMNClsgICAgMC4wMTM3
MjldIGxvY2tkZXA6IGZpeGluZyB1cCBhbHRlcm5hdGl2ZXMuDQpbICAgIDAuMDEzODU0XSBO
TUkgd2F0Y2hkb2cgZGlzYWJsZWQgKGNwdTEpOiBoYXJkd2FyZSBldmVudHMgbm90IGVuYWJs
ZWQNClsgICAgMC4wMTM5OThdIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMg0KWyAg
ICAwLjAxMzk5OF0gY3B1IDIgc3BpbmxvY2sgZXZlbnQgaXJxIDMwOQ0KWyAgICAwLjAxNDA5
OF0gTk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHUyKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBl
bmFibGVkDQpbICAgIDAuMDE0MjY4XSBpbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDMN
ClsgICAgMC4wMTQyODddIGNwdSAzIHNwaW5sb2NrIGV2ZW50IGlycSAzMTUNClsgICAgMC4w
MTQ0MDhdIE5NSSB3YXRjaGRvZyBkaXNhYmxlZCAoY3B1Myk6IGhhcmR3YXJlIGV2ZW50cyBu
b3QgZW5hYmxlZA0KWyAgICAwLjAxNDU2MF0gaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQ
VSA0DQpbICAgIDAuMDE0NTgxXSBjcHUgNCBzcGlubG9jayBldmVudCBpcnEgMzIxDQpbICAg
IDAuMDE0NzAyXSBOTUkgd2F0Y2hkb2cgZGlzYWJsZWQgKGNwdTQpOiBoYXJkd2FyZSBldmVu
dHMgbm90IGVuYWJsZWQNClsgICAgMC4wMTQ4NTddIGluc3RhbGxpbmcgWGVuIHRpbWVyIGZv
ciBDUFUgNQ0KWyAgICAwLjAxNDg3Nl0gY3B1IDUgc3BpbmxvY2sgZXZlbnQgaXJxIDMyNw0K
WyAgICAwLjAxNTA2N10gTk1JIHdhdGNoZG9nIGRpc2FibGVkIChjcHU1KTogaGFyZHdhcmUg
ZXZlbnRzIG5vdCBlbmFibGVkDQpbICAgIDAuMDE1MTIwXSBCcm91Z2h0IHVwIDYgQ1BVcw0K
WyAgICAwLjAxNjU2MV0gR3JhbnQgdGFibGVzIHVzaW5nIHZlcnNpb24gMiBsYXlvdXQuDQpb
ICAgIDAuMDE2NTYxXSBHcmFudCB0YWJsZSBpbml0aWFsaXplZA0KWyAgICAwLjAxNjU2MV0g
UlRDIHRpbWU6IDEyOjI1OjEyLCBkYXRlOiAwMS8xMi8xMg0KWyAgICAwLjAxNjU2MV0gTkVU
OiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNg0KWyAgICAwLjAxODEzOV0gbm9kZSAw
IGxpbmsgMDogaW8gcG9ydCBbMTAwMCwgZmZmZmZmXQ0KWyAgICAwLjAxODEzOV0gVE9NOiAw
MDAwMDAwMGIwMDAwMDAwIGFrYSAyODE2TQ0KWyAgICAwLjAxODEzOV0gRmFtIDEwaCBtbWNv
bmYgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdDQpbICAgIDAuMDE4MTM5XSBub2RlIDAg
bGluayAwOiBtbWlvIFtlMDAwMDAwMCwgZWZmZmZmZmZdID09PiBub25lDQpbICAgIDAuMDE4
MTM5XSBub2RlIDAgbGluayAwOiBtbWlvIFtmMDAwMDAwMCwgZmZmZmZmZmZdDQpbICAgIDAu
MDE4MTM5XSBub2RlIDAgbGluayAwOiBtbWlvIFthMDAwMCwgYmZmZmZdDQpbICAgIDAuMDE4
MTM5XSBub2RlIDAgbGluayAwOiBtbWlvIFtiMDAwMDAwMCwgZGZmZmZmZmZdDQpbICAgIDAu
MDE4MTM5XSBUT00yOiAwMDAwMDAwMjUwMDAwMDAwIGFrYSA5NDcyTQ0KWyAgICAwLjAxODEz
OV0gYnVzOiBbMDAsIDA3XSBvbiBub2RlIDAgbGluayAwDQpbICAgIDAuMDE4MTM5XSBidXM6
IDAwIGluZGV4IDAgW2lvICAweDAwMDAtMHhmZmZmXQ0KWyAgICAwLjAxODEzOV0gYnVzOiAw
MCBpbmRleCAxIFttZW0gMHhmMDAwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjAxODEzOV0g
YnVzOiAwMCBpbmRleCAyIFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZmXQ0KWyAgICAwLjAx
ODEzOV0gYnVzOiAwMCBpbmRleCAzIFttZW0gMHhiMDAwMDAwMC0weGRmZmZmZmZmXQ0KWyAg
ICAwLjAxODEzOV0gYnVzOiAwMCBpbmRleCA0IFttZW0gMHgyNTAwMDAwMDAtMHhmY2ZmZmZm
ZmZmXQ0KWyAgICAwLjAxODMwOV0gQUNQSTogYnVzIHR5cGUgcGNpIHJlZ2lzdGVyZWQNClsg
ICAgMC4wMTgzODFdIFBDSTogTU1DT05GSUcgZm9yIGRvbWFpbiAwMDAwIFtidXMgMDAtZmZd
IGF0IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXSAoYmFzZSAweGUwMDAwMDAwKQ0KWyAg
ICAwLjAxODM4MV0gUENJOiBub3QgdXNpbmcgTU1DT05GSUcNClsgICAgMC4wMTgzODFdIFBD
STogVXNpbmcgY29uZmlndXJhdGlvbiB0eXBlIDEgZm9yIGJhc2UgYWNjZXNzDQpbICAgIDAu
MDE4MzgxXSBQQ0k6IFVzaW5nIGNvbmZpZ3VyYXRpb24gdHlwZSAxIGZvciBleHRlbmRlZCBh
Y2Nlc3MNClsgICAgMC4wNjgxMDJdIGJpbzogY3JlYXRlIHNsYWIgPGJpby0wPiBhdCAwDQpb
ICAgIDAuMDY4MTE5XSBBQ1BJOiBBZGRlZCBfT1NJKE1vZHVsZSBEZXZpY2UpDQpbICAgIDAu
MDY4MTE5XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBEZXZpY2UpDQpbICAgIDAuMDY4
MTE5XSBBQ1BJOiBBZGRlZCBfT1NJKDMuMCBfU0NQIEV4dGVuc2lvbnMpDQpbICAgIDAuMDY4
MTE5XSBBQ1BJOiBBZGRlZCBfT1NJKFByb2Nlc3NvciBBZ2dyZWdhdG9yIERldmljZSkNClsg
ICAgMC4wNzM1MjNdIEFDUEk6IEVDOiBMb29rIHVwIEVDIGluIERTRFQNClsgICAgMC4wNzUy
MDddIEFDUEk6IEV4ZWN1dGVkIDMgYmxvY2tzIG9mIG1vZHVsZS1sZXZlbCBleGVjdXRhYmxl
IEFNTCBjb2RlDQpbICAgIDAuMDg4OTYwXSBBQ1BJOiBJbnRlcnByZXRlciBlbmFibGVkDQpb
ICAgIDAuMDg4OTY3XSBBQ1BJOiAoc3VwcG9ydHMgUzAgUzUpDQpbICAgIDAuMDg4OTkyXSBB
Q1BJOiBVc2luZyBJT0FQSUMgZm9yIGludGVycnVwdCByb3V0aW5nDQpbICAgIDAuMDg4OTky
XSBQQ0k6IE1NQ09ORklHIGZvciBkb21haW4gMDAwMCBbYnVzIDAwLWZmXSBhdCBbbWVtIDB4
ZTAwMDAwMDAtMHhlZmZmZmZmZl0gKGJhc2UgMHhlMDAwMDAwMCkNClsgICAgMC4wOTE3ODBd
IFBDSTogTU1DT05GSUcgYXQgW21lbSAweGUwMDAwMDAwLTB4ZWZmZmZmZmZdIHJlc2VydmVk
IGluIEFDUEkgbW90aGVyYm9hcmQgcmVzb3VyY2VzDQpbICAgIDAuMTg1NTA0XSBBQ1BJOiBO
byBkb2NrIGRldmljZXMgZm91bmQuDQpbICAgIDAuMTg1NTEyXSBQQ0k6IFVzaW5nIGhvc3Qg
YnJpZGdlIHdpbmRvd3MgZnJvbSBBQ1BJOyBpZiBuZWNlc3NhcnksIHVzZSAicGNpPW5vY3Jz
IiBhbmQgcmVwb3J0IGEgYnVnDQpbICAgIDAuMTg2MzA3XSBBQ1BJOiBQQ0kgUm9vdCBCcmlk
Z2UgW1BDSTBdIChkb21haW4gMDAwMCBbYnVzIDAwLWZmXSkNClsgICAgMC4xODY2MzNdIHBj
aV9yb290IFBOUDBBMDM6MDA6IGhvc3QgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MDAwMC0weDBj
ZjddDQpbICAgIDAuMTg2NjQwXSBwY2lfcm9vdCBQTlAwQTAzOjAwOiBob3N0IGJyaWRnZSB3
aW5kb3cgW2lvICAweDBkMDAtMHhmZmZmXQ0KWyAgICAwLjE4NjY0Nl0gcGNpX3Jvb3QgUE5Q
MEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHgwMDBhMDAwMC0weDAwMGJmZmZm
XQ0KWyAgICAwLjE4NjY1Ml0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2lu
ZG93IFttZW0gMHgwMDBkMDAwMC0weDAwMGRmZmZmXQ0KWyAgICAwLjE4NjY1OV0gcGNpX3Jv
b3QgUE5QMEEwMzowMDogaG9zdCBicmlkZ2Ugd2luZG93IFttZW0gMHhiMDAwMDAwMC0weGRm
ZmZmZmZmXQ0KWyAgICAwLjE4NjY3Ml0gcGNpX3Jvb3QgUE5QMEEwMzowMDogaG9zdCBicmlk
Z2Ugd2luZG93IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmXQ0KWyAgICAwLjE4NjgwOF0g
UENJIGhvc3QgYnJpZGdlIHRvIGJ1cyAwMDAwOjAwDQpbICAgIDAuMTg2ODA4XSBwY2lfYnVz
IDAwMDA6MDA6IHJvb3QgYnVzIHJlc291cmNlIFtpbyAgMHgwMDAwLTB4MGNmN10NClsgICAg
MC4xODY4MDhdIHBjaV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW2lvICAweDBk
MDAtMHhmZmZmXQ0KWyAgICAwLjE4NjgwOF0gcGNpX2J1cyAwMDAwOjAwOiByb290IGJ1cyBy
ZXNvdXJjZSBbbWVtIDB4MDAwYTAwMDAtMHgwMDBiZmZmZl0NClsgICAgMC4xODY4MDhdIHBj
aV9idXMgMDAwMDowMDogcm9vdCBidXMgcmVzb3VyY2UgW21lbSAweDAwMGQwMDAwLTB4MDAw
ZGZmZmZdDQpbICAgIDAuMTg2ODA4XSBwY2lfYnVzIDAwMDA6MDA6IHJvb3QgYnVzIHJlc291
cmNlIFttZW0gMHhiMDAwMDAwMC0weGRmZmZmZmZmXQ0KWyAgICAwLjE4NjgwOF0gcGNpX2J1
cyAwMDAwOjAwOiByb290IGJ1cyByZXNvdXJjZSBbbWVtIDB4ZjAwMDAwMDAtMHhmZWJmZmZm
Zl0NClsgICAgMC4xODY4MDhdIHBjaSAwMDAwOjAwOjAwLjA6IFsxMDAyOjVhMTFdIHR5cGUg
MCBjbGFzcyAweDAwMDYwMA0KWyAgICAwLjE4NjgwOF0gcGNpIDAwMDA6MDA6MDAuMjogWzEw
MDI6NWEyM10gdHlwZSAwIGNsYXNzIDB4MDAwODA2DQpbICAgIDAuMTg3MDAwXSBwY2kgMDAw
MDowMDowMi4wOiBbMTAwMjo1YTE2XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsgICAgMC4x
ODcxMjddIHBjaSAwMDAwOjAwOjAyLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3Qg
RDNjb2xkDQpbICAgIDAuMTg3MTc2XSBwY2kgMDAwMDowMDowMy4wOiBbMTAwMjo1YTE3XSB0
eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsgICAgMC4xODczMjJdIHBjaSAwMDAwOjAwOjAzLjA6
IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQpbICAgIDAuMTg3MzY4XSBw
Y2kgMDAwMDowMDowNS4wOiBbMTAwMjo1YTE5XSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsg
ICAgMC4xODc0OTNdIHBjaSAwMDAwOjAwOjA1LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAg
RDNob3QgRDNjb2xkDQpbICAgIDAuMTg3NTM2XSBwY2kgMDAwMDowMDowNi4wOiBbMTAwMjo1
YTFhXSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsgICAgMC4xODc2NjFdIHBjaSAwMDAwOjAw
OjA2LjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQpbICAgIDAuMTg3
NzEzXSBwY2kgMDAwMDowMDowYS4wOiBbMTAwMjo1YTFkXSB0eXBlIDEgY2xhc3MgMHgwMDA2
MDQNClsgICAgMC4xODc4NDFdIHBjaSAwMDAwOjAwOjBhLjA6IFBNRSMgc3VwcG9ydGVkIGZy
b20gRDAgRDNob3QgRDNjb2xkDQpbICAgIDAuMTg3ODg0XSBwY2kgMDAwMDowMDowYi4wOiBb
MTAwMjo1YTFmXSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsgICAgMC4xODc5ODBdIHBjaSAw
MDAwOjAwOjBiLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQpbICAg
IDAuMTg3OTgwXSBwY2kgMDAwMDowMDowZC4wOiBbMTAwMjo1YTFlXSB0eXBlIDEgY2xhc3Mg
MHgwMDA2MDQNClsgICAgMC4xODc5ODBdIHBjaSAwMDAwOjAwOjBkLjA6IFBNRSMgc3VwcG9y
dGVkIGZyb20gRDAgRDNob3QgRDNjb2xkDQpbICAgIDAuMTg3OTgwXSBwY2kgMDAwMDowMDox
MS4wOiBbMTAwMjo0MzkxXSB0eXBlIDAgY2xhc3MgMHgwMDAxMDYNClsgICAgMC4xODc5ODBd
IHBjaSAwMDAwOjAwOjExLjA6IHJlZyAxMDogW2lvICAweDcwMDAtMHg3MDA3XQ0KWyAgICAw
LjE4Nzk4MF0gcGNpIDAwMDA6MDA6MTEuMDogcmVnIDE0OiBbaW8gIDB4NjAwMC0weDYwMDNd
DQpbICAgIDAuMTg3OTgwXSBwY2kgMDAwMDowMDoxMS4wOiByZWcgMTg6IFtpbyAgMHg1MDAw
LTB4NTAwN10NClsgICAgMC4xODc5ODBdIHBjaSAwMDAwOjAwOjExLjA6IHJlZyAxYzogW2lv
ICAweDMwMDAtMHgzMDAzXQ0KWyAgICAwLjE4Nzk4MF0gcGNpIDAwMDA6MDA6MTEuMDogcmVn
IDIwOiBbaW8gIDB4MjAwMC0weDIwMGZdDQpbICAgIDAuMTg3OTgwXSBwY2kgMDAwMDowMDox
MS4wOiByZWcgMjQ6IFttZW0gMHhmOThmZjAwMC0weGY5OGZmM2ZmXQ0KWyAgICAwLjE4Nzk5
Nl0gcGNpIDAwMDA6MDA6MTIuMDogWzEwMDI6NDM5N10gdHlwZSAwIGNsYXNzIDB4MDAwYzAz
DQpbICAgIDAuMTg4MDI3XSBwY2kgMDAwMDowMDoxMi4wOiByZWcgMTA6IFttZW0gMHhmOThm
YjAwMC0weGY5OGZiZmZmXQ0KWyAgICAwLjE4ODE3OV0gcGNpIDAwMDA6MDA6MTIuMjogWzEw
MDI6NDM5Nl0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzDQpbICAgIDAuMTg4MjExXSBwY2kgMDAw
MDowMDoxMi4yOiByZWcgMTA6IFttZW0gMHhmOThmZjQwMC0weGY5OGZmNGZmXQ0KWyAgICAw
LjE4ODM1NF0gcGNpIDAwMDA6MDA6MTIuMjogc3VwcG9ydHMgRDEgRDINClsgICAgMC4xODgz
NjVdIHBjaSAwMDAwOjAwOjEyLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNo
b3QNClsgICAgMC4xODg0MDZdIHBjaSAwMDAwOjAwOjEzLjA6IFsxMDAyOjQzOTddIHR5cGUg
MCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE4ODQyOV0gcGNpIDAwMDA6MDA6MTMuMDogcmVn
IDEwOiBbbWVtIDB4Zjk4ZmMwMDAtMHhmOThmY2ZmZl0NClsgICAgMC4xODg1NjJdIHBjaSAw
MDAwOjAwOjEzLjI6IFsxMDAyOjQzOTZdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAw
LjE4ODU5NF0gcGNpIDAwMDA6MDA6MTMuMjogcmVnIDEwOiBbbWVtIDB4Zjk4ZmY4MDAtMHhm
OThmZjhmZl0NClsgICAgMC4xODg3NDRdIHBjaSAwMDAwOjAwOjEzLjI6IHN1cHBvcnRzIEQx
IEQyDQpbICAgIDAuMTg4NzQ4XSBwY2kgMDAwMDowMDoxMy4yOiBQTUUjIHN1cHBvcnRlZCBm
cm9tIEQwIEQxIEQyIEQzaG90DQpbICAgIDAuMTg4Nzg3XSBwY2kgMDAwMDowMDoxNC4wOiBb
MTAwMjo0Mzg1XSB0eXBlIDAgY2xhc3MgMHgwMDBjMDUNClsgICAgMC4xODg5MjddIHBjaSAw
MDAwOjAwOjE0LjM6IFsxMDAyOjQzOWRdIHR5cGUgMCBjbGFzcyAweDAwMDYwMQ0KWyAgICAw
LjE4ODk4MF0gcGNpIDAwMDA6MDA6MTQuNDogWzEwMDI6NDM4NF0gdHlwZSAxIGNsYXNzIDB4
MDAwNjA0DQpbICAgIDAuMTg4OTgwXSBwY2kgMDAwMDowMDoxNC41OiBbMTAwMjo0Mzk5XSB0
eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4xODg5ODBdIHBjaSAwMDAwOjAwOjE0LjU6
IHJlZyAxMDogW21lbSAweGY5OGZkMDAwLTB4Zjk4ZmRmZmZdDQpbICAgIDAuMTg5MDAyXSBw
Y2kgMDAwMDowMDoxNS4wOiBbMTAwMjo0M2EwXSB0eXBlIDEgY2xhc3MgMHgwMDA2MDQNClsg
ICAgMC4xODkxNTNdIHBjaSAwMDAwOjAwOjE1LjA6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAu
MTg5MjM3XSBwY2kgMDAwMDowMDoxNi4wOiBbMTAwMjo0Mzk3XSB0eXBlIDAgY2xhc3MgMHgw
MDBjMDMNClsgICAgMC4xODkyNjBdIHBjaSAwMDAwOjAwOjE2LjA6IHJlZyAxMDogW21lbSAw
eGY5OGZlMDAwLTB4Zjk4ZmVmZmZdDQpbICAgIDAuMTg5Mzg1XSBwY2kgMDAwMDowMDoxNi4y
OiBbMTAwMjo0Mzk2XSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4xODk0MTddIHBj
aSAwMDAwOjAwOjE2LjI6IHJlZyAxMDogW21lbSAweGY5OGZmYzAwLTB4Zjk4ZmZjZmZdDQpb
ICAgIDAuMTg5NTY3XSBwY2kgMDAwMDowMDoxNi4yOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAw
LjE4OTU3MV0gcGNpIDAwMDA6MDA6MTYuMjogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBE
MiBEM2hvdA0KWyAgICAwLjE4OTYxNF0gcGNpIDAwMDA6MDA6MTguMDogWzEwMjI6MTIwMF0g
dHlwZSAwIGNsYXNzIDB4MDAwNjAwDQpbICAgIDAuMTg5NzAwXSBwY2kgMDAwMDowMDoxOC4x
OiBbMTAyMjoxMjAxXSB0eXBlIDAgY2xhc3MgMHgwMDA2MDANClsgICAgMC4xODk3NjVdIHBj
aSAwMDAwOjAwOjE4LjI6IFsxMDIyOjEyMDJdIHR5cGUgMCBjbGFzcyAweDAwMDYwMA0KWyAg
ICAwLjE4OTgzNF0gcGNpIDAwMDA6MDA6MTguMzogWzEwMjI6MTIwM10gdHlwZSAwIGNsYXNz
IDB4MDAwNjAwDQpbICAgIDAuMTg5OTIwXSBwY2kgMDAwMDowMDoxOC40OiBbMTAyMjoxMjA0
XSB0eXBlIDAgY2xhc3MgMHgwMDA2MDANClsgICAgMC4xOTAwMDRdIHBjaSAwMDAwOjBiOjAw
LjA6IFsxMGRlOjA2ZTRdIHR5cGUgMCBjbGFzcyAweDAwMDMwMA0KWyAgICAwLjE5MDAyNl0g
cGNpIDAwMDA6MGI6MDAuMDogcmVnIDEwOiBbbWVtIDB4ZmQwMDAwMDAtMHhmZGZmZmZmZl0N
ClsgICAgMC4xOTAwNTBdIHBjaSAwMDAwOjBiOjAwLjA6IHJlZyAxNDogW21lbSAweGQwMDAw
MDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4xOTAwODJdIHBjaSAwMDAwOjBi
OjAwLjA6IHJlZyAxYzogW21lbSAweGZhMDAwMDAwLTB4ZmJmZmZmZmYgNjRiaXRdDQpbICAg
IDAuMTkwMDk5XSBwY2kgMDAwMDowYjowMC4wOiByZWcgMjQ6IFtpbyAgMHhlODAwLTB4ZTg3
Zl0NClsgICAgMC4xOTAxMTZdIHBjaSAwMDAwOjBiOjAwLjA6IHJlZyAzMDogW21lbSAweGZl
OWUwMDAwLTB4ZmU5ZmZmZmYgcHJlZl0NClsgICAgMC4xOTIwMTldIHBjaSAwMDAwOjAwOjAy
LjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwYi0wYl0NClsgICAgMC4xOTIwMzJdIHBjaSAwMDAw
OjAwOjAyLjA6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4ZTAwMC0weGVmZmZdDQpbICAgIDAu
MTkyMDQwXSBwY2kgMDAwMDowMDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGZhMDAw
MDAwLTB4ZmU5ZmZmZmZdDQpbICAgIDAuMTkyMDU3XSBwY2kgMDAwMDowMDowMi4wOiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYgNjRiaXQgcHJlZl0NClsg
ICAgMC4xOTIxNjZdIHBjaSAwMDAwOjBhOjAwLjA6IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFz
cyAweDAwMGMwMw0KWyAgICAwLjE5MjE5NF0gcGNpIDAwMDA6MGE6MDAuMDogcmVnIDEwOiBb
bWVtIDB4ZjlmZjgwMDAtMHhmOWZmOGZmZl0NClsgICAgMC4xOTI0MDRdIHBjaSAwMDAwOjBh
OjAwLjA6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMTkyNDA4XSBwY2kgMDAwMDowYTowMC4w
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQpbICAgIDAuMTkyNDcxXSBw
Y2kgMDAwMDowYTowMC4xOiBbOTcxMDo5OTkwXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsg
ICAgMC4xOTI1MDRdIHBjaSAwMDAwOjBhOjAwLjE6IHJlZyAxMDogW21lbSAweGY5ZmY5MDAw
LTB4ZjlmZjlmZmZdDQpbICAgIDAuMTkyNzAxXSBwY2kgMDAwMDowYTowMC4xOiBzdXBwb3J0
cyBEMSBEMg0KWyAgICAwLjE5MjcwNV0gcGNpIDAwMDA6MGE6MDAuMTogUE1FIyBzdXBwb3J0
ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KWyAgICAwLjE5Mjc3NF0gcGNpIDAwMDA6MGE6MDAu
MjogWzk3MTA6OTk5MF0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzDQpbICAgIDAuMTkyODAxXSBw
Y2kgMDAwMDowYTowMC4yOiByZWcgMTA6IFttZW0gMHhmOWZmYTAwMC0weGY5ZmZhZmZmXQ0K
WyAgICAwLjE5Mjk3OV0gcGNpIDAwMDA6MGE6MDAuMjogc3VwcG9ydHMgRDEgRDINClsgICAg
MC4xOTI5NzldIHBjaSAwMDAwOjBhOjAwLjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEg
RDIgRDNob3QNClsgICAgMC4xOTI5NzldIHBjaSAwMDAwOjBhOjAwLjM6IFs5NzEwOjk5OTBd
IHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE5Mjk3OV0gcGNpIDAwMDA6MGE6MDAu
MzogcmVnIDEwOiBbbWVtIDB4ZjlmZmIwMDAtMHhmOWZmYmZmZl0NClsgICAgMC4xOTI5Nzld
IHBjaSAwMDAwOjBhOjAwLjM6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMTkyOTc5XSBwY2kg
MDAwMDowYTowMC4zOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQpbICAg
IDAuMTkzMDM4XSBwY2kgMDAwMDowYTowMC40OiBbOTcxMDo5OTkwXSB0eXBlIDAgY2xhc3Mg
MHgwMDBjMDMNClsgICAgMC4xOTMwNzRdIHBjaSAwMDAwOjBhOjAwLjQ6IHJlZyAxMDogW21l
bSAweGY5ZmZjMDAwLTB4ZjlmZmNmZmZdDQpbICAgIDAuMTkzMjg2XSBwY2kgMDAwMDowYTow
MC40OiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjE5MzI5MF0gcGNpIDAwMDA6MGE6MDAuNDog
UE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KWyAgICAwLjE5MzM1N10gcGNp
IDAwMDA6MGE6MDAuNTogWzk3MTA6OTk5MF0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzDQpbICAg
IDAuMTkzMzg0XSBwY2kgMDAwMDowYTowMC41OiByZWcgMTA6IFttZW0gMHhmOWZmZDAwMC0w
eGY5ZmZkZmZmXQ0KWyAgICAwLjE5MzU4OF0gcGNpIDAwMDA6MGE6MDAuNTogc3VwcG9ydHMg
RDEgRDINClsgICAgMC4xOTM1OTJdIHBjaSAwMDAwOjBhOjAwLjU6IFBNRSMgc3VwcG9ydGVk
IGZyb20gRDAgRDEgRDIgRDNob3QNClsgICAgMC4xOTM2NTNdIHBjaSAwMDAwOjBhOjAwLjY6
IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE5MzY4N10gcGNp
IDAwMDA6MGE6MDAuNjogcmVnIDEwOiBbbWVtIDB4ZjlmZmUwMDAtMHhmOWZmZWZmZl0NClsg
ICAgMC4xOTM4ODNdIHBjaSAwMDAwOjBhOjAwLjY6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAu
MTkzODg3XSBwY2kgMDAwMDowYTowMC42OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQy
IEQzaG90DQpbICAgIDAuMTkzOTU4XSBwY2kgMDAwMDowYTowMC43OiBbOTcxMDo5OTkwXSB0
eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4xOTM5NzldIHBjaSAwMDAwOjBhOjAwLjc6
IHJlZyAxMDogW21lbSAweGY5ZmZmMDAwLTB4ZjlmZmZmZmZdDQpbICAgIDAuMTkzOTc5XSBw
Y2kgMDAwMDowYTowMC43OiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjE5Mzk3OV0gcGNpIDAw
MDA6MGE6MDAuNzogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KWyAgICAw
LjE5NTA1OF0gcGNpIDAwMDA6MDA6MDMuMDogUENJIGJyaWRnZSB0byBbYnVzIDBhLTBhXQ0K
WyAgICAwLjE5NTA3MV0gcGNpIDAwMDA6MDA6MDMuMDogICBicmlkZ2Ugd2luZG93IFttZW0g
MHhmOWYwMDAwMC0weGY5ZmZmZmZmXQ0KWyAgICAwLjE5NTIwNV0gcGNpIDAwMDA6MDk6MDAu
MDogWzEwZWM6ODE2OF0gdHlwZSAwIGNsYXNzIDB4MDAwMjAwDQpbICAgIDAuMTk1MjI5XSBw
Y2kgMDAwMDowOTowMC4wOiByZWcgMTA6IFtpbyAgMHhkODAwLTB4ZDhmZl0NClsgICAgMC4x
OTUyNzddIHBjaSAwMDAwOjA5OjAwLjA6IHJlZyAxODogW21lbSAweGNmZmZmMDAwLTB4Y2Zm
ZmZmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4xOTUzMDRdIHBjaSAwMDAwOjA5OjAwLjA6IHJl
ZyAyMDogW21lbSAweGNmZmY4MDAwLTB4Y2ZmZmJmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4x
OTUzMjRdIHBjaSAwMDAwOjA5OjAwLjA6IHJlZyAzMDogW21lbSAweGY5ZWUwMDAwLTB4Zjll
ZmZmZmYgcHJlZl0NClsgICAgMC4xOTU0MzBdIHBjaSAwMDAwOjA5OjAwLjA6IHN1cHBvcnRz
IEQxIEQyDQpbICAgIDAuMTk1NDM0XSBwY2kgMDAwMDowOTowMC4wOiBQTUUjIHN1cHBvcnRl
ZCBmcm9tIEQwIEQxIEQyIEQzaG90IEQzY29sZA0KWyAgICAwLjE5NzAxOF0gcGNpIDAwMDA6
MDA6MDUuMDogUENJIGJyaWRnZSB0byBbYnVzIDA5LTA5XQ0KWyAgICAwLjE5NzAzMF0gcGNp
IDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFtpbyAgMHhkMDAwLTB4ZGZmZl0NClsg
ICAgMC4xOTcwMzhdIHBjaSAwMDAwOjAwOjA1LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4
ZjllMDAwMDAtMHhmOWVmZmZmZl0NClsgICAgMC4xOTcwNDldIHBjaSAwMDAwOjAwOjA1LjA6
ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4Y2ZmMDAwMDAtMHhjZmZmZmZmZiA2NGJpdCBwcmVm
XQ0KWyAgICAwLjE5NzE1MV0gcGNpIDAwMDA6MDg6MDAuMDogWzEwZWM6ODE2OF0gdHlwZSAw
IGNsYXNzIDB4MDAwMjAwDQpbICAgIDAuMTk3MTgyXSBwY2kgMDAwMDowODowMC4wOiByZWcg
MTA6IFtpbyAgMHhjODAwLTB4YzhmZl0NClsgICAgMC4xOTcyMjJdIHBjaSAwMDAwOjA4OjAw
LjA6IHJlZyAxODogW21lbSAweGNmZWZmMDAwLTB4Y2ZlZmZmZmYgNjRiaXQgcHJlZl0NClsg
ICAgMC4xOTcyNDldIHBjaSAwMDAwOjA4OjAwLjA6IHJlZyAyMDogW21lbSAweGNmZWY4MDAw
LTB4Y2ZlZmJmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4xOTcyNzVdIHBjaSAwMDAwOjA4OjAw
LjA6IHJlZyAzMDogW21lbSAweGY5ZGUwMDAwLTB4ZjlkZmZmZmYgcHJlZl0NClsgICAgMC4x
OTczNzVdIHBjaSAwMDAwOjA4OjAwLjA6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMTk3Mzc5
XSBwY2kgMDAwMDowODowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90
IEQzY29sZA0KWyAgICAwLjE5OTAwMl0gcGNpIDAwMDA6MDA6MDYuMDogUENJIGJyaWRnZSB0
byBbYnVzIDA4LTA4XQ0KWyAgICAwLjE5OTAxMl0gcGNpIDAwMDA6MDA6MDYuMDogICBicmlk
Z2Ugd2luZG93IFtpbyAgMHhjMDAwLTB4Y2ZmZl0NClsgICAgMC4xOTkwMjBdIHBjaSAwMDAw
OjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVtIDB4ZjlkMDAwMDAtMHhmOWRmZmZmZl0N
ClsgICAgMC4xOTkwMzBdIHBjaSAwMDAwOjAwOjA2LjA6ICAgYnJpZGdlIHdpbmRvdyBbbWVt
IDB4Y2ZlMDAwMDAtMHhjZmVmZmZmZiA2NGJpdCBwcmVmXQ0KWyAgICAwLjE5OTE0MF0gcGNp
IDAwMDA6MDY6MDAuMDogWzEwNGM6ODIzMV0gdHlwZSAxIGNsYXNzIDB4MDAwNjA0DQpbICAg
IDAuMTk5MzM1XSBwY2kgMDAwMDowNjowMC4wOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjE5
OTM3N10gcGNpIDAwMDA6MDY6MDAuMDogZGlzYWJsaW5nIEFTUE0gb24gcHJlLTEuMSBQQ0ll
IGRldmljZS4gIFlvdSBjYW4gZW5hYmxlIGl0IHdpdGggJ3BjaWVfYXNwbT1mb3JjZScNClsg
ICAgMC4xOTkzOTZdIHBjaSAwMDAwOjAwOjBhLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAwNi0w
N10NClsgICAgMC4xOTk0MTBdIHBjaSAwMDAwOjAwOjBhLjA6ICAgYnJpZGdlIHdpbmRvdyBb
bWVtIDB4ZjljMDAwMDAtMHhmOWNmZmZmZl0NClsgICAgMC4xOTk1NjFdIHBjaSAwMDAwOjA3
OjAxLjA6IFsxMDMzOjAwMzVdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE5OTYw
MF0gcGNpIDAwMDA6MDc6MDEuMDogcmVnIDEwOiBbbWVtIDB4ZjljZmQwMDAtMHhmOWNmZGZm
Zl0NClsgICAgMC4xOTk3MzVdIHBjaSAwMDAwOjA3OjAxLjA6IERpc2FibGluZyBtZW1vcnkg
ZGVjb2RpbmcgYW5kIHJlbGVhc2luZyBtZW1vcnkgcmVzb3VyY2VzLg0KWyAgICAwLjE5OTgw
M10gcGNpIDAwMDA6MDc6MDEuMDogc3VwcG9ydHMgRDEgRDINClsgICAgMC4xOTk4MDddIHBj
aSAwMDAwOjA3OjAxLjA6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNClsg
ICAgMC4xOTk4NjRdIHBjaSAwMDAwOjA3OjAxLjE6IFsxMDMzOjAwMzVdIHR5cGUgMCBjbGFz
cyAweDAwMGMwMw0KWyAgICAwLjE5OTkxMF0gcGNpIDAwMDA6MDc6MDEuMTogcmVnIDEwOiBb
bWVtIDB4ZjljZmUwMDAtMHhmOWNmZWZmZl0NClsgICAgMC4xOTk5NzhdIHBjaSAwMDAwOjA3
OjAxLjE6IERpc2FibGluZyBtZW1vcnkgZGVjb2RpbmcgYW5kIHJlbGVhc2luZyBtZW1vcnkg
cmVzb3VyY2VzLg0KWyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDc6MDEuMTogc3VwcG9ydHMg
RDEgRDINClsgICAgMC4xOTk5NzhdIHBjaSAwMDAwOjA3OjAxLjE6IFBNRSMgc3VwcG9ydGVk
IGZyb20gRDAgRDEgRDIgRDNob3QNClsgICAgMC4xOTk5NzhdIHBjaSAwMDAwOjA3OjAxLjI6
IFsxMDMzOjAwZTBdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjE5OTk3OF0gcGNp
IDAwMDA6MDc6MDEuMjogcmVnIDEwOiBbbWVtIDB4ZjljZmZjMDAtMHhmOWNmZmNmZl0NClsg
ICAgMC4xOTk5NzhdIHBjaSAwMDAwOjA3OjAxLjI6IERpc2FibGluZyBtZW1vcnkgZGVjb2Rp
bmcgYW5kIHJlbGVhc2luZyBtZW1vcnkgcmVzb3VyY2VzLg0KWyAgICAwLjE5OTk3OF0gcGNp
IDAwMDA6MDc6MDEuMjogUm91bmRpbmcgdXAgc2l6ZSBvZiByZXNvdXJjZSAjMCB0byAweDEw
MDAuDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAwMDowNzowMS4yOiBzdXBwb3J0cyBEMSBEMg0K
WyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDc6MDEuMjogUE1FIyBzdXBwb3J0ZWQgZnJvbSBE
MCBEMSBEMiBEM2hvdA0KWyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDY6MDAuMDogUENJIGJy
aWRnZSB0byBbYnVzIDA3LTA3XQ0KWyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDY6MDAuMDog
ICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWMwMDAwMC0weGY5Y2ZmZmZmXQ0KWyAgICAwLjE5
OTk3OF0gcGNpIDAwMDA6MDU6MDAuMDogWzEwMDI6OTVjNV0gdHlwZSAwIGNsYXNzIDB4MDAw
MzAwDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAwMDowNTowMC4wOiByZWcgMTA6IFttZW0gMHhi
MDAwMDAwMC0weGJmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAw
MDowNTowMC4wOiByZWcgMTg6IFttZW0gMHhmOWJlMDAwMC0weGY5YmVmZmZmIDY0Yml0XQ0K
WyAgICAwLjE5OTk3OF0gcGNpIDAwMDA6MDU6MDAuMDogcmVnIDIwOiBbaW8gIDB4YjAwMC0w
eGIwZmZdDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAwMDowNTowMC4wOiByZWcgMzA6IFttZW0g
MHhmOWJjMDAwMC0weGY5YmRmZmZmIHByZWZdDQpbICAgIDAuMTk5OTc4XSBwY2kgMDAwMDow
NTowMC4wOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjIwMDAxN10gcGNpIDAwMDA6MDU6MDAu
MTogWzEwMDI6YWEyOF0gdHlwZSAwIGNsYXNzIDB4MDAwNDAzDQpbICAgIDAuMjAwMDYwXSBw
Y2kgMDAwMDowNTowMC4xOiByZWcgMTA6IFttZW0gMHhmOWJmYzAwMC0weGY5YmZmZmZmIDY0
Yml0XQ0KWyAgICAwLjIwMDI0MF0gcGNpIDAwMDA6MDU6MDAuMTogc3VwcG9ydHMgRDEgRDIN
ClsgICAgMC4yMDIwMDFdIHBjaSAwMDAwOjAwOjBiLjA6IFBDSSBicmlkZ2UgdG8gW2J1cyAw
NS0wNV0NClsgICAgMC4yMDIwMTFdIHBjaSAwMDAwOjAwOjBiLjA6ICAgYnJpZGdlIHdpbmRv
dyBbaW8gIDB4YjAwMC0weGJmZmZdDQpbICAgIDAuMjAyMDE4XSBwY2kgMDAwMDowMDowYi4w
OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YjAwMDAwLTB4ZjliZmZmZmZdDQpbICAgIDAu
MjAyMDI5XSBwY2kgMDAwMDowMDowYi4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGIwMDAw
MDAwLTB4YmZmZmZmZmYgNjRiaXQgcHJlZl0NClsgICAgMC4yMDIxMzNdIHBjaSAwMDAwOjA0
OjAwLjA6IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0KWyAgICAwLjIwMjE1
OV0gcGNpIDAwMDA6MDQ6MDAuMDogcmVnIDEwOiBbbWVtIDB4ZjlhZjgwMDAtMHhmOWFmOGZm
Zl0NClsgICAgMC4yMDIzNTRdIHBjaSAwMDAwOjA0OjAwLjA6IHN1cHBvcnRzIEQxIEQyDQpb
ICAgIDAuMjAyMzU4XSBwY2kgMDAwMDowNDowMC4wOiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQw
IEQxIEQyIEQzaG90DQpbICAgIDAuMjAyNDI2XSBwY2kgMDAwMDowNDowMC4xOiBbOTcxMDo5
OTkwXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4yMDI0NTJdIHBjaSAwMDAwOjA0
OjAwLjE6IHJlZyAxMDogW21lbSAweGY5YWY5MDAwLTB4ZjlhZjlmZmZdDQpbICAgIDAuMjAy
NjUzXSBwY2kgMDAwMDowNDowMC4xOiBzdXBwb3J0cyBEMSBEMg0KWyAgICAwLjIwMjY1OF0g
cGNpIDAwMDA6MDQ6MDAuMTogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0K
WyAgICAwLjIwMjcxN10gcGNpIDAwMDA6MDQ6MDAuMjogWzk3MTA6OTk5MF0gdHlwZSAwIGNs
YXNzIDB4MDAwYzAzDQpbICAgIDAuMjAyNzUwXSBwY2kgMDAwMDowNDowMC4yOiByZWcgMTA6
IFttZW0gMHhmOWFmYTAwMC0weGY5YWZhZmZmXQ0KWyAgICAwLjIwMjk0NV0gcGNpIDAwMDA6
MDQ6MDAuMjogc3VwcG9ydHMgRDEgRDINClsgICAgMC4yMDI5NDldIHBjaSAwMDAwOjA0OjAw
LjI6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNClsgICAgMC4yMDI5Nzhd
IHBjaSAwMDAwOjA0OjAwLjM6IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFzcyAweDAwMGMwMw0K
WyAgICAwLjIwMjk3OF0gcGNpIDAwMDA6MDQ6MDAuMzogcmVnIDEwOiBbbWVtIDB4ZjlhZmIw
MDAtMHhmOWFmYmZmZl0NClsgICAgMC4yMDMwNTRdIHBjaSAwMDAwOjA0OjAwLjM6IHN1cHBv
cnRzIEQxIEQyDQpbICAgIDAuMjAzMDY1XSBwY2kgMDAwMDowNDowMC4zOiBQTUUjIHN1cHBv
cnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQpbICAgIDAuMjAzMTI0XSBwY2kgMDAwMDowNDow
MC40OiBbOTcxMDo5OTkwXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsgICAgMC4yMDMxODVd
IHBjaSAwMDAwOjA0OjAwLjQ6IHJlZyAxMDogW21lbSAweGY5YWZjMDAwLTB4ZjlhZmNmZmZd
DQpbICAgIDAuMjAzMzczXSBwY2kgMDAwMDowNDowMC40OiBzdXBwb3J0cyBEMSBEMg0KWyAg
ICAwLjIwMzM4MF0gcGNpIDAwMDA6MDQ6MDAuNDogUE1FIyBzdXBwb3J0ZWQgZnJvbSBEMCBE
MSBEMiBEM2hvdA0KWyAgICAwLjIwMzQ0N10gcGNpIDAwMDA6MDQ6MDAuNTogWzk3MTA6OTk5
MF0gdHlwZSAwIGNsYXNzIDB4MDAwYzAzDQpbICAgIDAuMjAzNDc0XSBwY2kgMDAwMDowNDow
MC41OiByZWcgMTA6IFttZW0gMHhmOWFmZDAwMC0weGY5YWZkZmZmXQ0KWyAgICAwLjIwMzY3
NV0gcGNpIDAwMDA6MDQ6MDAuNTogc3VwcG9ydHMgRDEgRDINClsgICAgMC4yMDM2NzldIHBj
aSAwMDAwOjA0OjAwLjU6IFBNRSMgc3VwcG9ydGVkIGZyb20gRDAgRDEgRDIgRDNob3QNClsg
ICAgMC4yMDM3MzhdIHBjaSAwMDAwOjA0OjAwLjY6IFs5NzEwOjk5OTBdIHR5cGUgMCBjbGFz
cyAweDAwMGMwMw0KWyAgICAwLjIwMzc3MV0gcGNpIDAwMDA6MDQ6MDAuNjogcmVnIDEwOiBb
bWVtIDB4ZjlhZmUwMDAtMHhmOWFmZWZmZl0NClsgICAgMC4yMDM5NjZdIHBjaSAwMDAwOjA0
OjAwLjY6IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMjAzOTcwXSBwY2kgMDAwMDowNDowMC42
OiBQTUUjIHN1cHBvcnRlZCBmcm9tIEQwIEQxIEQyIEQzaG90DQpbICAgIDAuMjAzOTc3XSBw
Y2kgMDAwMDowNDowMC43OiBbOTcxMDo5OTkwXSB0eXBlIDAgY2xhc3MgMHgwMDBjMDMNClsg
ICAgMC4yMDM5NzddIHBjaSAwMDAwOjA0OjAwLjc6IHJlZyAxMDogW21lbSAweGY5YWZmMDAw
LTB4ZjlhZmZmZmZdDQpbICAgIDAuMjAzOTc3XSBwY2kgMDAwMDowNDowMC43OiBzdXBwb3J0
cyBEMSBEMg0KWyAgICAwLjIwMzk3N10gcGNpIDAwMDA6MDQ6MDAuNzogUE1FIyBzdXBwb3J0
ZWQgZnJvbSBEMCBEMSBEMiBEM2hvdA0KWyAgICAwLjIwNTA3MF0gcGNpIDAwMDA6MDA6MGQu
MDogUENJIGJyaWRnZSB0byBbYnVzIDA0LTA0XQ0KWyAgICAwLjIwNTA4NV0gcGNpIDAwMDA6
MDA6MGQuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWEwMDAwMC0weGY5YWZmZmZmXQ0K
WyAgICAwLjIwNTE1Ml0gcGNpIDAwMDA6MDM6MDYuMDogWzEzZjY6MDExMV0gdHlwZSAwIGNs
YXNzIDB4MDAwNDAxDQpbICAgIDAuMjA1MTk0XSBwY2kgMDAwMDowMzowNi4wOiByZWcgMTA6
IFtpbyAgMHhhODAwLTB4YThmZl0NClsgICAgMC4yMDUzNTJdIHBjaSAwMDAwOjAzOjA2LjA6
IHN1cHBvcnRzIEQxIEQyDQpbICAgIDAuMjA1NDMyXSBwY2kgMDAwMDowMDoxNC40OiBQQ0kg
YnJpZGdlIHRvIFtidXMgMDMtMDNdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMjA1
NDc2XSBwY2kgMDAwMDowMDoxNC40OiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGEwMDAtMHhh
ZmZmXQ0KWyAgICAwLjIwNTQ4OF0gcGNpIDAwMDA6MDA6MTQuNDogICBicmlkZ2Ugd2luZG93
IFtpbyAgMHgwMDAwLTB4MGNmN10gKHN1YnRyYWN0aXZlIGRlY29kZSkNClsgICAgMC4yMDU0
OTRdIHBjaSAwMDAwOjAwOjE0LjQ6ICAgYnJpZGdlIHdpbmRvdyBbaW8gIDB4MGQwMC0weGZm
ZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMjA1NTAwXSBwY2kgMDAwMDowMDox
NC40OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdIChzdWJ0
cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMjA1NTA2XSBwY2kgMDAwMDowMDoxNC40OiAgIGJy
aWRnZSB3aW5kb3cgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZmZmZdIChzdWJ0cmFjdGl2ZSBk
ZWNvZGUpDQpbICAgIDAuMjA1NTEyXSBwY2kgMDAwMDowMDoxNC40OiAgIGJyaWRnZSB3aW5k
b3cgW21lbSAweGIwMDAwMDAwLTB4ZGZmZmZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpb
ICAgIDAuMjA1NTE4XSBwY2kgMDAwMDowMDoxNC40OiAgIGJyaWRnZSB3aW5kb3cgW21lbSAw
eGYwMDAwMDAwLTB4ZmViZmZmZmZdIChzdWJ0cmFjdGl2ZSBkZWNvZGUpDQpbICAgIDAuMjA1
NjA0XSBwY2kgMDAwMDowMDoxNS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDItMDJdDQpbICAg
IDAuMjA1Njg3XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBD
STAuX1BSVF0NClsgICAgMC4yMDU5MjZdIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBU
YWJsZSBbXF9TQl8uUENJMC5QQzAyLl9QUlRdDQpbICAgIDAuMjA1OTc3XSBBQ1BJOiBQQ0kg
SW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEMwMy5fUFJUXQ0KWyAgICAw
LjIwNTk3N10gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5QQ0kw
LlBDMDUuX1BSVF0NClsgICAgMC4yMDU5NzddIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGlu
ZyBUYWJsZSBbXF9TQl8uUENJMC5QQzA2Ll9QUlRdDQpbICAgIDAuMjA1OTc3XSBBQ1BJOiBQ
Q0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUEMwQS5fUFJUXQ0KWyAg
ICAwLjIwNTk3N10gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NCXy5Q
Q0kwLlBDMEIuX1BSVF0NClsgICAgMC4yMDU5NzddIEFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91
dGluZyBUYWJsZSBbXF9TQl8uUENJMC5QQzBELl9QUlRdDQpbICAgIDAuMjA1OTc3XSBBQ1BJ
OiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuUDBQQy5fUFJUXQ0K
WyAgICAwLjIwNTk4MV0gQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRhYmxlIFtcX1NC
Xy5QQ0kwLlBFMjAuX1BSVF0NClsgICAgMC4yMDYyNDFdICBwY2kwMDAwOjAwOiBSZXF1ZXN0
aW5nIEFDUEkgX09TQyBjb250cm9sICgweDFkKQ0KWyAgICAwLjIwNjU3MV0gIHBjaTAwMDA6
MDA6IEFDUEkgX09TQyBjb250cm9sICgweDFkKSBncmFudGVkDQpbICAgIDAuMjMzMTg2XSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0FdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUp
DQpbICAgIDAuMjM0MDAzXSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIChJUlFz
IDQgNyAxMCAqMTEgMTQgMTUpDQpbICAgIDAuMjM0MTY5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0
IExpbmsgW0xOS0NdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUpDQpbICAgIDAuMjM0MzIxXSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0RdIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUp
DQpbICAgIDAuMjM0NDU3XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIChJUlFz
IDQgKjcgMTAgMTEgMTQgMTUpDQpbICAgIDAuMjM0NTU5XSBBQ1BJOiBQQ0kgSW50ZXJydXB0
IExpbmsgW0xOS0ZdIChJUlFzIDQgNyAxMCAqMTEgMTQgMTUpDQpbICAgIDAuMjM0NjU2XSBB
Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0ddIChJUlFzIDQgNyAqMTAgMTEgMTQgMTUp
DQpbICAgIDAuMjM0NzU1XSBBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJUlFz
IDQgNyAqMTAgMTEgMTQgMTUpDQpbICAgIDAuMjM1MDI1XSB4ZW4vYmFsbG9vbjogSW5pdGlh
bGlzaW5nIGJhbGxvb24gZHJpdmVyLg0KWyAgICAwLjIzNTA3NF0geGVuLWJhbGxvb246IElu
aXRpYWxpc2luZyBiYWxsb29uIGRyaXZlci4NClsgICAgMC4yMzUxNThdIHZnYWFyYjogZGV2
aWNlIGFkZGVkOiBQQ0k6MDAwMDowYjowMC4wLGRlY29kZXM9aW8rbWVtLG93bnM9aW8rbWVt
LGxvY2tzPW5vbmUNClsgICAgMC4yMzUxNThdIHZnYWFyYjogZGV2aWNlIGFkZGVkOiBQQ0k6
MDAwMDowNTowMC4wLGRlY29kZXM9aW8rbWVtLG93bnM9bm9uZSxsb2Nrcz1ub25lDQpbICAg
IDAuMjM1MTU4XSB2Z2FhcmI6IGxvYWRlZA0KWyAgICAwLjIzNTE1OF0gdmdhYXJiOiBicmlk
Z2UgY29udHJvbCBwb3NzaWJsZSAwMDAwOjA1OjAwLjANClsgICAgMC4yMzUxNThdIHZnYWFy
YjogYnJpZGdlIGNvbnRyb2wgcG9zc2libGUgMDAwMDowYjowMC4wDQpbICAgIDAuMjM2MDY2
XSBTQ1NJIHN1YnN5c3RlbSBpbml0aWFsaXplZA0KWyAgICAwLjIzNjA4Nl0gbGliYXRhIHZl
cnNpb24gMy4wMCBsb2FkZWQuDQpbICAgIDAuMjM2MDg2XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYmZzDQpbICAgIDAuMjM3MDMyXSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGh1Yg0KWyAgICAwLjIzNzA3NV0gdXNi
Y29yZTogcmVnaXN0ZXJlZCBuZXcgZGV2aWNlIGRyaXZlciB1c2INClsgICAgMC4yMzcxNDNd
IEFkdmFuY2VkIExpbnV4IFNvdW5kIEFyY2hpdGVjdHVyZSBEcml2ZXIgVmVyc2lvbiAxLjAu
MjQuDQpbICAgIDAuMjM3MTQzXSBQQ0k6IFVzaW5nIEFDUEkgZm9yIElSUSByb3V0aW5nDQpb
ICAgIDAuMjQ0OTcxXSBQQ0k6IHBjaV9jYWNoZV9saW5lX3NpemUgc2V0IHRvIDY0IGJ5dGVz
DQpbICAgIDAuMjQ1MDM1XSByZXNlcnZlIFJBTSBidWZmZXI6IDAwMDAwMDAwMDAwOWIwMDAg
LSAwMDAwMDAwMDAwMDlmZmZmIA0KWyAgICAwLjI0NTE1OF0gTmV0TGFiZWw6IEluaXRpYWxp
emluZw0KWyAgICAwLjI0NTE1OF0gTmV0TGFiZWw6ICBkb21haW4gaGFzaCBzaXplID0gMTI4
DQpbICAgIDAuMjQ1MTU4XSBOZXRMYWJlbDogIHByb3RvY29scyA9IFVOTEFCRUxFRCBDSVBT
T3Y0DQpbICAgIDAuMjQ1MTU4XSBOZXRMYWJlbDogIHVubGFiZWxlZCB0cmFmZmljIGFsbG93
ZWQgYnkgZGVmYXVsdA0KWyAgICAwLjI0NTMxM10gU3dpdGNoaW5nIHRvIGNsb2Nrc291cmNl
IHhlbg0KWyAgICAwLjI0NTQ0OF0gcG5wOiBQblAgQUNQSSBpbml0DQpbICAgIDAuMjQ1NDQ4
XSBBQ1BJOiBidXMgdHlwZSBwbnAgcmVnaXN0ZXJlZA0KWyAgICAwLjI0NTQ5NF0gcG5wIDAw
OjAwOiBbYnVzIDAwLWZmXQ0KWyAgICAwLjI0NTQ5OV0gcG5wIDAwOjAwOiBbaW8gIDB4MGNm
OC0weDBjZmZdDQpbICAgIDAuMjQ1NTA1XSBwbnAgMDA6MDA6IFtpbyAgMHgwMDAwLTB4MGNm
NyB3aW5kb3ddDQpbICAgIDAuMjQ1NTA5XSBwbnAgMDA6MDA6IFtpbyAgMHgwZDAwLTB4ZmZm
ZiB3aW5kb3ddDQpbICAgIDAuMjQ1NTE0XSBwbnAgMDA6MDA6IFttZW0gMHgwMDBhMDAwMC0w
eDAwMGJmZmZmIHdpbmRvd10NClsgICAgMC4yNDU1MTldIHBucCAwMDowMDogW21lbSAweDAw
MGQwMDAwLTB4MDAwZGZmZmYgd2luZG93XQ0KWyAgICAwLjI0NTUyNV0gcG5wIDAwOjAwOiBb
bWVtIDB4YjAwMDAwMDAtMHhkZmZmZmZmZiB3aW5kb3ddDQpbICAgIDAuMjQ1NTMwXSBwbnAg
MDA6MDA6IFttZW0gMHhmMDAwMDAwMC0weGZlYmZmZmZmIHdpbmRvd10NClsgICAgMC4yNDU4
MjFdIHBucCAwMDowMDogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwgSURzIFBOUDBhMDMg
KGFjdGl2ZSkNClsgICAgMC4yNDU5OTRdIHBucCAwMDowMTogW21lbSAweDAwMDAwMDAwLTB4
ZmZmZmZmZmZmZmZmZmZmZiBkaXNhYmxlZF0NClsgICAgMC4yNDYwMDBdIHBucCAwMDowMTog
W21lbSAweGZlYzIwMDAwLTB4ZmVjMjAwZmZdDQpbICAgIDAuMjQ2MjY2XSBzeXN0ZW0gMDA6
MDE6IFttZW0gMHhmZWMyMDAwMC0weGZlYzIwMGZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQN
ClsgICAgMC4yNDYyNzVdIHN5c3RlbSAwMDowMTogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmlj
ZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkNClsgICAgMC4yNDY0MDJdIHBucCAwMDowMjogW21l
bSAweGY2MDAwMDAwLTB4ZjYwMDNmZmZdDQpbICAgIDAuMjQ2NjQ2XSBzeXN0ZW0gMDA6MDI6
IFttZW0gMHhmNjAwMDAwMC0weGY2MDAzZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAw
LjI0NjY1NF0gc3lzdGVtIDAwOjAyOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMGMwMiAoYWN0aXZlKQ0KWyAgICAwLjI0NjkzOV0gcG5wIDAwOjAzOiBbZG1hIDRdDQpb
ICAgIDAuMjQ2OTQzXSBwbnAgMDA6MDM6IFtpbyAgMHgwMDAwLTB4MDAwZl0NClsgICAgMC4y
NDY5NDZdIHBucCAwMDowMzogW2lvICAweDAwODEtMHgwMDgzXQ0KWyAgICAwLjI0Njk1MF0g
cG5wIDAwOjAzOiBbaW8gIDB4MDA4N10NClsgICAgMC4yNDY5NTRdIHBucCAwMDowMzogW2lv
ICAweDAwODktMHgwMDhiXQ0KWyAgICAwLjI0Njk1N10gcG5wIDAwOjAzOiBbaW8gIDB4MDA4
Zl0NClsgICAgMC4yNDY5NjNdIHBucCAwMDowMzogW2lvICAweDAwYzAtMHgwMGRmXQ0KWyAg
ICAwLjI0NzE2N10gcG5wIDAwOjAzOiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMg
UE5QMDIwMCAoYWN0aXZlKQ0KWyAgICAwLjI0NzE5OF0gcG5wIDAwOjA0OiBbaW8gIDB4MDA3
MC0weDAwNzFdDQpbICAgIDAuMjQ3MjAzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA4IHRyaWdn
ZXJpbmcgMSBwb2xhcml0eSAwDQpbICAgIDAuMjQ3MjExXSB4ZW5fbWFwX3BpcnFfZ3NpOiBy
ZXR1cm5pbmcgaXJxIDggZm9yIGdzaSA4DQpbICAgIDAuMjQ3MjE1XSB4ZW46IC0tPiBwaXJx
PTggLT4gaXJxPTggKGdzaT04KQ0KWyAgICAwLjI0NzIzMl0gcG5wIDAwOjA0OiBbaXJxIDhd
DQpbICAgIDAuMjQ3NDMzXSBwbnAgMDA6MDQ6IFBsdWcgYW5kIFBsYXkgQUNQSSBkZXZpY2Us
IElEcyBQTlAwYjAwIChhY3RpdmUpDQpbICAgIDAuMjQ3NTE0XSBwbnAgMDA6MDU6IFtpbyAg
MHgwMDYxXQ0KWyAgICAwLjI0Nzc1M10gcG5wIDAwOjA1OiBQbHVnIGFuZCBQbGF5IEFDUEkg
ZGV2aWNlLCBJRHMgUE5QMDgwMCAoYWN0aXZlKQ0KWyAgICAwLjI0Nzc3Ml0gcG5wIDAwOjA2
OiBbaW8gIDB4MDBmMC0weDAwZmZdDQpbICAgIDAuMjQ3Nzc3XSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSAxMyB0cmlnZ2VyaW5nIDEgcG9sYXJpdHkgMA0KWyAgICAwLjI0Nzc4Ml0geGVuX21h
cF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxMyBmb3IgZ3NpIDEzDQpbICAgIDAuMjQ3Nzg3
XSB4ZW46IC0tPiBwaXJxPTEzIC0+IGlycT0xMyAoZ3NpPTEzKQ0KWyAgICAwLjI0NzgwM10g
cG5wIDAwOjA2OiBbaXJxIDEzXQ0KWyAgICAwLjI0Nzk5OV0gcG5wIDAwOjA2OiBQbHVnIGFu
ZCBQbGF5IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwNCAoYWN0aXZlKQ0KWyAgICAwLjI0ODQz
MV0gcG5wIDAwOjA3OiBbaW8gIDB4MDNmOC0weDAzZmZdDQpbICAgIDAuMjQ4NDM2XSB4ZW46
IHJlZ2lzdGVyaW5nIGdzaSA0IHRyaWdnZXJpbmcgMSBwb2xhcml0eSAwDQpbICAgIDAuMjQ4
NDQyXSB4ZW5fbWFwX3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDQgZm9yIGdzaSA0DQpbICAg
IDAuMjQ4NDQ2XSB4ZW46IC0tPiBwaXJxPTQgLT4gaXJxPTQgKGdzaT00KQ0KWyAgICAwLjI0
ODQ1MF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0DQpbICAgIDAuMjQ4NDU0XSBwbnAgMDA6
MDc6IFtpcnEgNF0NClsgICAgMC4yNDg0NTddIHBucCAwMDowNzogW2RtYSAwIGRpc2FibGVk
XQ0KWyAgICAwLjI0ODY5OV0gcG5wIDAwOjA3OiBQbHVnIGFuZCBQbGF5IEFDUEkgZGV2aWNl
LCBJRHMgUE5QMDUwMSAoYWN0aXZlKQ0KWyAgICAwLjI0ODg2MF0gcG5wIDAwOjA4OiBbaW8g
IDB4MDAwMC0weGZmZmZmZmZmZmZmZmZmZmYgZGlzYWJsZWRdDQpbICAgIDAuMjQ4ODY1XSBw
bnAgMDA6MDg6IFtpbyAgMHgwNjAwLTB4MDZkZl0NClsgICAgMC4yNDg4NjldIHBucCAwMDow
ODogW2lvICAweDBhZTAtMHgwYWVmXQ0KWyAgICAwLjI0OTE5OF0gc3lzdGVtIDAwOjA4OiBb
aW8gIDB4MDYwMC0weDA2ZGZdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjQ5MjA1XSBz
eXN0ZW0gMDA6MDg6IFtpbyAgMHgwYWUwLTB4MGFlZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsg
ICAgMC4yNDkyMTJdIHN5c3RlbSAwMDowODogUGx1ZyBhbmQgUGxheSBBQ1BJIGRldmljZSwg
SURzIFBOUDBjMDIgKGFjdGl2ZSkNClsgICAgMC4yNDkyNjVdIHBucCAwMDowOTogW21lbSAw
eGZlZDAwMDAwLTB4ZmVkMDAzZmZdDQpbICAgIDAuMjQ5NDc5XSBwbnAgMDA6MDk6IFBsdWcg
YW5kIFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwMTAzIChhY3RpdmUpDQpbICAgIDAuMjQ5
NjM3XSBwbnAgMDA6MGE6IFtpbyAgMHgwMDYwXQ0KWyAgICAwLjI0OTY0MV0gcG5wIDAwOjBh
OiBbaW8gIDB4MDA2NF0NClsgICAgMC4yNDk2NDVdIHBucCAwMDowYTogW21lbSAweGZlYzAw
MDAwLTB4ZmVjMDBmZmZdDQpbICAgIDAuMjQ5NjQ5XSBwbnAgMDA6MGE6IFttZW0gMHhmZWUw
MDAwMC0weGZlZTAwZmZmXQ0KWyAgICAwLjI0OTk0NF0gc3lzdGVtIDAwOjBhOiBbbWVtIDB4
ZmVjMDAwMDAtMHhmZWMwMGZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQpbICAgIDAuMjQ5
OTUxXSBzeXN0ZW0gMDA6MGE6IFttZW0gMHhmZWUwMDAwMC0weGZlZTAwZmZmXSBoYXMgYmVl
biByZXNlcnZlZA0KWyAgICAwLjI0OTk1OF0gc3lzdGVtIDAwOjBhOiBQbHVnIGFuZCBQbGF5
IEFDUEkgZGV2aWNlLCBJRHMgUE5QMGMwMiAoYWN0aXZlKQ0KWyAgICAwLjI1MDI0NF0gcG5w
IDAwOjBiOiBbaW8gIDB4MDAxMC0weDAwMWZdDQpbICAgIDAuMjUwMjQ4XSBwbnAgMDA6MGI6
IFtpbyAgMHgwMDIyLTB4MDAzZl0NClsgICAgMC4yNTAyNTVdIHBucCAwMDowYjogW2lvICAw
eDAwNjItMHgwMDYzXQ0KWyAgICAwLjI1MDI1OV0gcG5wIDAwOjBiOiBbaW8gIDB4MDA2NS0w
eDAwNmZdDQpbICAgIDAuMjUwMjYzXSBwbnAgMDA6MGI6IFtpbyAgMHgwMDcyLTB4MDA3Zl0N
ClsgICAgMC4yNTAyNjZdIHBucCAwMDowYjogW2lvICAweDAwODBdDQpbICAgIDAuMjUwMjcw
XSBwbnAgMDA6MGI6IFtpbyAgMHgwMDg0LTB4MDA4Nl0NClsgICAgMC4yNTAyNzRdIHBucCAw
MDowYjogW2lvICAweDAwODhdDQpbICAgIDAuMjUwMjc3XSBwbnAgMDA6MGI6IFtpbyAgMHgw
MDhjLTB4MDA4ZV0NClsgICAgMC4yNTAyODFdIHBucCAwMDowYjogW2lvICAweDAwOTAtMHgw
MDlmXQ0KWyAgICAwLjI1MDI4NF0gcG5wIDAwOjBiOiBbaW8gIDB4MDBhMi0weDAwYmZdDQpb
ICAgIDAuMjUwMjg4XSBwbnAgMDA6MGI6IFtpbyAgMHgwMGIxXQ0KWyAgICAwLjI1MDI5Ml0g
cG5wIDAwOjBiOiBbaW8gIDB4MDBlMC0weDAwZWZdDQpbICAgIDAuMjUwMjk1XSBwbnAgMDA6
MGI6IFtpbyAgMHgwNGQwLTB4MDRkMV0NClsgICAgMC4yNTAyOTldIHBucCAwMDowYjogW2lv
ICAweDA0MGJdDQpbICAgIDAuMjUwMzAzXSBwbnAgMDA6MGI6IFtpbyAgMHgwNGQ2XQ0KWyAg
ICAwLjI1MDMwNl0gcG5wIDAwOjBiOiBbaW8gIDB4MGMwMC0weDBjMDFdDQpbICAgIDAuMjUw
MzE3XSBwbnAgMDA6MGI6IFtpbyAgMHgwYzE0XQ0KWyAgICAwLjI1MDMyMF0gcG5wIDAwOjBi
OiBbaW8gIDB4MGM1MC0weDBjNTFdDQpbICAgIDAuMjUwMzI0XSBwbnAgMDA6MGI6IFtpbyAg
MHgwYzUyXQ0KWyAgICAwLjI1MDMyN10gcG5wIDAwOjBiOiBbaW8gIDB4MGM2Y10NClsgICAg
MC4yNTAzMzFdIHBucCAwMDowYjogW2lvICAweDBjNmZdDQpbICAgIDAuMjUwMzM0XSBwbnAg
MDA6MGI6IFtpbyAgMHgwY2QwLTB4MGNkMV0NClsgICAgMC4yNTAzMzhdIHBucCAwMDowYjog
W2lvICAweDBjZDItMHgwY2QzXQ0KWyAgICAwLjI1MDM0Ml0gcG5wIDAwOjBiOiBbaW8gIDB4
MGNkNC0weDBjZDVdDQpbICAgIDAuMjUwMzQ2XSBwbnAgMDA6MGI6IFtpbyAgMHgwY2Q2LTB4
MGNkN10NClsgICAgMC4yNTAzNDldIHBucCAwMDowYjogW2lvICAweDBjZDgtMHgwY2RmXQ0K
WyAgICAwLjI1MDM1M10gcG5wIDAwOjBiOiBbaW8gIDB4MDgwMC0weDA4OWZdDQpbICAgIDAu
MjUwMzU3XSBwbnAgMDA6MGI6IFtpbyAgMHgwMDAwLTB4ZmZmZmZmZmZmZmZmZmZmZiBkaXNh
YmxlZF0NClsgICAgMC4yNTAzNjJdIHBucCAwMDowYjogW2lvICAweDBiMDAtMHgwYjFmXQ0K
WyAgICAwLjI1MDM2NV0gcG5wIDAwOjBiOiBbaW8gIDB4MGIyMC0weDBiM2ZdDQpbICAgIDAu
MjUwMzY5XSBwbnAgMDA6MGI6IFtpbyAgMHgwOTAwLTB4MDkwZl0NClsgICAgMC4yNTAzNzNd
IHBucCAwMDowYjogW2lvICAweDA5MTAtMHgwOTFmXQ0KWyAgICAwLjI1MDM3N10gcG5wIDAw
OjBiOiBbaW8gIDB4ZmUwMC0weGZlZmVdDQpbICAgIDAuMjUwMzgwXSBwbnAgMDA6MGI6IFtp
byAgMHgwMDYwXQ0KWyAgICAwLjI1MDM4NF0gcG5wIDAwOjBiOiBbaW8gIDB4MDA2NF0NClsg
ICAgMC4yNTAzODhdIHBucCAwMDowYjogW21lbSAweDAwMDAwMDAwLTB4ZmZmZmZmZmZmZmZm
ZmZmZiBkaXNhYmxlZF0NClsgICAgMC4yNTAzOTNdIHBucCAwMDowYjogW21lbSAweGZmYjgw
MDAwLTB4ZmZiZmZmZmZdDQpbICAgIDAuMjUwNDA0XSBwbnAgMDA6MGI6IFttZW0gMHhmZWMx
MDAwMC0weGZlYzEwMDFmXQ0KWyAgICAwLjI1MDQwOF0gcG5wIDAwOjBiOiBbbWVtIDB4ZmVk
ODAwMDAtMHhmZWQ4MGZmZl0NClsgICAgMC4yNTA0MTJdIHBucCAwMDowYjogW21lbSAweDAw
MDAwMDAwLTB4ZmZmZmZmZmZmZmZmZmZmZiBkaXNhYmxlZF0NClsgICAgMC4yNTA3OTBdIHN5
c3RlbSAwMDowYjogW2lvICAweDA0ZDAtMHgwNGQxXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAg
ICAwLjI1MDc5Nl0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4MDQwYl0gaGFzIGJlZW4gcmVzZXJ2
ZWQNClsgICAgMC4yNTA4MDFdIHN5c3RlbSAwMDowYjogW2lvICAweDA0ZDZdIGhhcyBiZWVu
IHJlc2VydmVkDQpbICAgIDAuMjUwODA2XSBzeXN0ZW0gMDA6MGI6IFtpbyAgMHgwYzAwLTB4
MGMwMV0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4yNTA4MTFdIHN5c3RlbSAwMDowYjog
W2lvICAweDBjMTRdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwODE2XSBzeXN0ZW0g
MDA6MGI6IFtpbyAgMHgwYzUwLTB4MGM1MV0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4y
NTA4MjFdIHN5c3RlbSAwMDowYjogW2lvICAweDBjNTJdIGhhcyBiZWVuIHJlc2VydmVkDQpb
ICAgIDAuMjUwODI2XSBzeXN0ZW0gMDA6MGI6IFtpbyAgMHgwYzZjXSBoYXMgYmVlbiByZXNl
cnZlZA0KWyAgICAwLjI1MDgzOF0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4MGM2Zl0gaGFzIGJl
ZW4gcmVzZXJ2ZWQNClsgICAgMC4yNTA4NDNdIHN5c3RlbSAwMDowYjogW2lvICAweDBjZDAt
MHgwY2QxXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjI1MDg0OF0gc3lzdGVtIDAwOjBi
OiBbaW8gIDB4MGNkMi0weDBjZDNdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwODUz
XSBzeXN0ZW0gMDA6MGI6IFtpbyAgMHgwY2Q0LTB4MGNkNV0gaGFzIGJlZW4gcmVzZXJ2ZWQN
ClsgICAgMC4yNTA4NTldIHN5c3RlbSAwMDowYjogW2lvICAweDBjZDYtMHgwY2Q3XSBoYXMg
YmVlbiByZXNlcnZlZA0KWyAgICAwLjI1MDg2NF0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4MGNk
OC0weDBjZGZdIGhhcyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwODY5XSBzeXN0ZW0gMDA6
MGI6IFtpbyAgMHgwODAwLTB4MDg5Zl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4yNTA4
NzRdIHN5c3RlbSAwMDowYjogW2lvICAweDBiMDAtMHgwYjFmXSBoYXMgYmVlbiByZXNlcnZl
ZA0KWyAgICAwLjI1MDg3OV0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4MGIyMC0weDBiM2ZdIGhh
cyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwODg1XSBzeXN0ZW0gMDA6MGI6IFtpbyAgMHgw
OTAwLTB4MDkwZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAgMC4yNTA4OTBdIHN5c3RlbSAw
MDowYjogW2lvICAweDA5MTAtMHgwOTFmXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjI1
MDg5NV0gc3lzdGVtIDAwOjBiOiBbaW8gIDB4ZmUwMC0weGZlZmVdIGhhcyBiZWVuIHJlc2Vy
dmVkDQpbICAgIDAuMjUwOTAxXSBzeXN0ZW0gMDA6MGI6IFttZW0gMHhmZmI4MDAwMC0weGZm
YmZmZmZmXSBoYXMgYmVlbiByZXNlcnZlZA0KWyAgICAwLjI1MDkwN10gc3lzdGVtIDAwOjBi
OiBbbWVtIDB4ZmVjMTAwMDAtMHhmZWMxMDAxZl0gaGFzIGJlZW4gcmVzZXJ2ZWQNClsgICAg
MC4yNTA5MTJdIHN5c3RlbSAwMDowYjogW21lbSAweGZlZDgwMDAwLTB4ZmVkODBmZmZdIGhh
cyBiZWVuIHJlc2VydmVkDQpbICAgIDAuMjUwOTI3XSBzeXN0ZW0gMDA6MGI6IFBsdWcgYW5k
IFBsYXkgQUNQSSBkZXZpY2UsIElEcyBQTlAwYzAyIChhY3RpdmUpDQpbICAgIDAuMjUxMDE1
XSBwbnAgMDA6MGM6IFttZW0gMHhlMDAwMDAwMC0weGVmZmZmZmZmXQ0KWyAgICAwLjI1MTMz
M10gc3lzdGVtIDAwOjBjOiBbbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZl0gaGFzIGJlZW4g
cmVzZXJ2ZWQNClsgICAgMC4yNTEzNDJdIHN5c3RlbSAwMDowYzogUGx1ZyBhbmQgUGxheSBB
Q1BJIGRldmljZSwgSURzIFBOUDBjMDIgKGFjdGl2ZSkNClsgICAgMC4yNTE1NjldIHBucCAw
MDowZDogW21lbSAweDAwMDAwMDAwLTB4MDAwOWZmZmZdDQpbICAgIDAuMjUxNTczXSBwbnAg
MDA6MGQ6IFttZW0gMHgwMDBjMDAwMC0weDAwMGNmZmZmXQ0KWyAgICAwLjI1MTU3OF0gcG5w
IDAwOjBkOiBbbWVtIDB4MDAwZTAwMDAtMHgwMDBmZmZmZl0NClsgICAgMC4yNTE1ODJdIHBu
cCAwMDowZDogW21lbSAweDAwMTAwMDAwLTB4YWZmZmZmZmZdDQpbICAgIDAuMjUxNTg2XSBw
bnAgMDA6MGQ6IFttZW0gMHhmZWMwMDAwMC0weGZmZmZmZmZmXQ0KWyAgICAwLjI1MTkyN10g
c3lzdGVtIDAwOjBkOiBbbWVtIDB4MDAwMDAwMDAtMHgwMDA5ZmZmZl0gY291bGQgbm90IGJl
IHJlc2VydmVkDQpbICAgIDAuMjUxOTM0XSBzeXN0ZW0gMDA6MGQ6IFttZW0gMHgwMDBjMDAw
MC0weDAwMGNmZmZmXSBjb3VsZCBub3QgYmUgcmVzZXJ2ZWQNClsgICAgMC4yNTE5MzldIHN5
c3RlbSAwMDowZDogW21lbSAweDAwMGUwMDAwLTB4MDAwZmZmZmZdIGNvdWxkIG5vdCBiZSBy
ZXNlcnZlZA0KWyAgICAwLjI1MTk0NV0gc3lzdGVtIDAwOjBkOiBbbWVtIDB4MDAxMDAwMDAt
MHhhZmZmZmZmZl0gY291bGQgbm90IGJlIHJlc2VydmVkDQpbICAgIDAuMjUxOTUyXSBzeXN0
ZW0gMDA6MGQ6IFttZW0gMHhmZWMwMDAwMC0weGZmZmZmZmZmXSBjb3VsZCBub3QgYmUgcmVz
ZXJ2ZWQNClsgICAgMC4yNTE5NjBdIHN5c3RlbSAwMDowZDogUGx1ZyBhbmQgUGxheSBBQ1BJ
IGRldmljZSwgSURzIFBOUDBjMDEgKGFjdGl2ZSkNClsgICAgMC4yNTIxOTldIHBucDogUG5Q
IEFDUEk6IGZvdW5kIDE0IGRldmljZXMNClsgICAgMC4yNTIyMDNdIEFDUEk6IEFDUEkgYnVz
IHR5cGUgcG5wIHVucmVnaXN0ZXJlZA0KWyAgICAwLjI1NDQwMV0gcGNpYmFjayAwMDAwOjBh
OjAwLjA6IHNlaXppbmcgZGV2aWNlDQpbICAgIDAuMjU0NDg3XSBwY2liYWNrIDAwMDA6MGE6
MDAuMTogc2VpemluZyBkZXZpY2UNClsgICAgMC4yNTQ1NjZdIHBjaWJhY2sgMDAwMDowYTow
MC4yOiBzZWl6aW5nIGRldmljZQ0KWyAgICAwLjI1NDYzOV0gcGNpYmFjayAwMDAwOjBhOjAw
LjM6IHNlaXppbmcgZGV2aWNlDQpbICAgIDAuMjU0NzQ2XSBwY2liYWNrIDAwMDA6MGE6MDAu
NDogc2VpemluZyBkZXZpY2UNClsgICAgMC4yNTQ4MjVdIHBjaWJhY2sgMDAwMDowYTowMC41
OiBzZWl6aW5nIGRldmljZQ0KWyAgICAwLjI1NDkwN10gcGNpYmFjayAwMDAwOjBhOjAwLjY6
IHNlaXppbmcgZGV2aWNlDQpbICAgIDAuMjU0OTgyXSBwY2liYWNrIDAwMDA6MGE6MDAuNzog
c2VpemluZyBkZXZpY2UNClsgICAgMC4yNTUyOTZdIHBjaWJhY2sgMDAwMDowNzowMS4wOiBz
ZWl6aW5nIGRldmljZQ0KWyAgICAwLjI1NTM3NV0gcGNpYmFjayAwMDAwOjA3OjAxLjE6IHNl
aXppbmcgZGV2aWNlDQpbICAgIDAuMjU1NDU1XSBwY2liYWNrIDAwMDA6MDc6MDEuMjogc2Vp
emluZyBkZXZpY2UNClsgICAgMC4yNTU1MjldIHBjaWJhY2sgMDAwMDowNTowMC4wOiBzZWl6
aW5nIGRldmljZQ0KWyAgICAwLjI1NTYwOF0gcGNpYmFjayAwMDAwOjA1OjAwLjE6IHNlaXpp
bmcgZGV2aWNlDQpbICAgIDAuMjU1NjkwXSBwY2liYWNrIDAwMDA6MDQ6MDAuMDogc2Vpemlu
ZyBkZXZpY2UNClsgICAgMC4yNTU3NjJdIHBjaWJhY2sgMDAwMDowNDowMC4xOiBzZWl6aW5n
IGRldmljZQ0KWyAgICAwLjI1NTg0Ml0gcGNpYmFjayAwMDAwOjA0OjAwLjI6IHNlaXppbmcg
ZGV2aWNlDQpbICAgIDAuMjU1OTIyXSBwY2liYWNrIDAwMDA6MDQ6MDAuMzogc2VpemluZyBk
ZXZpY2UNClsgICAgMC4yNTYwMDFdIHBjaWJhY2sgMDAwMDowNDowMC40OiBzZWl6aW5nIGRl
dmljZQ0KWyAgICAwLjI1NjExN10gcGNpYmFjayAwMDAwOjA0OjAwLjU6IHNlaXppbmcgZGV2
aWNlDQpbICAgIDAuMjU2MTkyXSBwY2liYWNrIDAwMDA6MDQ6MDAuNjogc2VpemluZyBkZXZp
Y2UNClsgICAgMC4yNTYyNzRdIHBjaWJhY2sgMDAwMDowNDowMC43OiBzZWl6aW5nIGRldmlj
ZQ0KWyAgICAwLjI1NjM1M10gcGNpYmFjayAwMDAwOjAzOjA2LjA6IHNlaXppbmcgZGV2aWNl
DQpbICAgIDAuMjY2NDU2XSBQTS1UaW1lciBmYWlsZWQgY29uc2lzdGVuY3kgY2hlY2sgICgw
eDB4ZmZmZmZmKSAtIGFib3J0aW5nLg0KWyAgICAwLjI2NjU1MV0gUENJOiBtYXggYnVzIGRl
cHRoOiAyIHBjaV90cnlfbnVtOiAzDQpbICAgIDAuMjY2NjU3XSBwY2kgMDAwMDowMDowMi4w
OiBQQ0kgYnJpZGdlIHRvIFtidXMgMGItMGJdDQpbICAgIDAuMjY2NjY0XSBwY2kgMDAwMDow
MDowMi4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGUwMDAtMHhlZmZmXQ0KWyAgICAwLjI2
NjY3M10gcGNpIDAwMDA6MDA6MDIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmYTAwMDAw
MC0weGZlOWZmZmZmXQ0KWyAgICAwLjI2NjY4MV0gcGNpIDAwMDA6MDA6MDIuMDogICBicmlk
Z2Ugd2luZG93IFttZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAg
IDAuMjY2NzAwXSBwY2kgMDAwMDowMDowMy4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMGEtMGFd
DQpbICAgIDAuMjY2NzA4XSBwY2kgMDAwMDowMDowMy4wOiAgIGJyaWRnZSB3aW5kb3cgW21l
bSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQpbICAgIDAuMjY2NzIxXSBwY2kgMDAwMDowMDow
NS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDktMDldDQpbICAgIDAuMjY2NzI3XSBwY2kgMDAw
MDowMDowNS4wOiAgIGJyaWRnZSB3aW5kb3cgW2lvICAweGQwMDAtMHhkZmZmXQ0KWyAgICAw
LjI2NjczNV0gcGNpIDAwMDA6MDA6MDUuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWUw
MDAwMC0weGY5ZWZmZmZmXQ0KWyAgICAwLjI2Njc0M10gcGNpIDAwMDA6MDA6MDUuMDogICBi
cmlkZ2Ugd2luZG93IFttZW0gMHhjZmYwMDAwMC0weGNmZmZmZmZmIDY0Yml0IHByZWZdDQpb
ICAgIDAuMjY2NzU0XSBwY2kgMDAwMDowMDowNi4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDgt
MDhdDQpbICAgIDAuMjY2NzYwXSBwY2kgMDAwMDowMDowNi4wOiAgIGJyaWRnZSB3aW5kb3cg
W2lvICAweGMwMDAtMHhjZmZmXQ0KWyAgICAwLjI2Njc2OV0gcGNpIDAwMDA6MDA6MDYuMDog
ICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWQwMDAwMC0weGY5ZGZmZmZmXQ0KWyAgICAwLjI2
Njc4M10gcGNpIDAwMDA6MDA6MDYuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhjZmUwMDAw
MC0weGNmZWZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY2Nzk2XSBwY2liYWNrIDAwMDA6
MDc6MDEuMDogQkFSIDA6IGFzc2lnbmVkIFttZW0gMHhmOWMwMDAwMC0weGY5YzAwZmZmXQ0K
WyAgICAwLjI2NjgwOF0gcGNpYmFjayAwMDAwOjA3OjAxLjE6IEJBUiAwOiBhc3NpZ25lZCBb
bWVtIDB4ZjljMDEwMDAtMHhmOWMwMWZmZl0NClsgICAgMC4yNjY4MThdIHBjaWJhY2sgMDAw
MDowNzowMS4yOiBCQVIgMDogYXNzaWduZWQgW21lbSAweGY5YzAyMDAwLTB4ZjljMDJmZmZd
DQpbICAgIDAuMjY2ODI5XSBwY2kgMDAwMDowNjowMC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMg
MDctMDddDQpbICAgIDAuMjY2ODQwXSBwY2kgMDAwMDowNjowMC4wOiAgIGJyaWRnZSB3aW5k
b3cgW21lbSAweGY5YzAwMDAwLTB4ZjljZmZmZmZdDQpbICAgIDAuMjY2ODU4XSBwY2kgMDAw
MDowMDowYS4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDYtMDddDQpbICAgIDAuMjY2ODczXSBw
Y2kgMDAwMDowMDowYS4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YzAwMDAwLTB4Zjlj
ZmZmZmZdDQpbICAgIDAuMjY2ODg3XSBwY2kgMDAwMDowMDowYi4wOiBQQ0kgYnJpZGdlIHRv
IFtidXMgMDUtMDVdDQpbICAgIDAuMjY2ODkyXSBwY2kgMDAwMDowMDowYi4wOiAgIGJyaWRn
ZSB3aW5kb3cgW2lvICAweGIwMDAtMHhiZmZmXQ0KWyAgICAwLjI2NjkwMV0gcGNpIDAwMDA6
MDA6MGIuMDogICBicmlkZ2Ugd2luZG93IFttZW0gMHhmOWIwMDAwMC0weGY5YmZmZmZmXQ0K
WyAgICAwLjI2NjkwOV0gcGNpIDAwMDA6MDA6MGIuMDogICBicmlkZ2Ugd2luZG93IFttZW0g
MHhiMDAwMDAwMC0weGJmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY2OTIwXSBwY2kg
MDAwMDowMDowZC4wOiBQQ0kgYnJpZGdlIHRvIFtidXMgMDQtMDRdDQpbICAgIDAuMjY2OTI5
XSBwY2kgMDAwMDowMDowZC4wOiAgIGJyaWRnZSB3aW5kb3cgW21lbSAweGY5YTAwMDAwLTB4
ZjlhZmZmZmZdDQpbICAgIDAuMjY2OTQyXSBwY2kgMDAwMDowMDoxNC40OiBQQ0kgYnJpZGdl
IHRvIFtidXMgMDMtMDNdDQpbICAgIDAuMjY2OTU2XSBwY2kgMDAwMDowMDoxNC40OiAgIGJy
aWRnZSB3aW5kb3cgW2lvICAweGEwMDAtMHhhZmZmXQ0KWyAgICAwLjI2Njk3Nl0gcGNpIDAw
MDA6MDA6MTUuMDogUENJIGJyaWRnZSB0byBbYnVzIDAyLTAyXQ0KWyAgICAwLjI2NzAwNF0g
eGVuOiByZWdpc3RlcmluZyBnc2kgNTIgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAg
MC4yNjcwMjBdIHhlbjogLS0+IHBpcnE9NTIgLT4gaXJxPTUyIChnc2k9NTIpDQpbICAgIDAu
MjY3MDQ4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA1MiB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg
MQ0KWyAgICAwLjI2NzA3Nl0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA1MiBm
b3IgZ3NpIDUyDQpbICAgIDAuMjY3MDgxXSB4ZW46IC0tPiBwaXJxPTUyIC0+IGlycT01MiAo
Z3NpPTUyKQ0KWyAgICAwLjI2NzA4NV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo1Mg0KWyAg
ICAwLjI2NzA5NV0geGVuOiByZWdpc3RlcmluZyBnc2kgNTIgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDENClsgICAgMC4yNjcxMDBdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEg
NTIgZm9yIGdzaSA1Mg0KWyAgICAwLjI2NzEwNV0geGVuOiAtLT4gcGlycT01MiAtPiBpcnE9
NTIgKGdzaT01MikNClsgICAgMC4yNjcxMDldIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6NTIN
ClsgICAgMC4yNjcxMThdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDUzIHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgIDAuMjY3MTY0XSB4ZW46IC0tPiBwaXJxPTUzIC0+IGlycT01MyAo
Z3NpPTUzKQ0KWyAgICAwLjI2NzE4MV0geGVuOiByZWdpc3RlcmluZyBnc2kgNTQgdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAgMC4yNjcxOTFdIHhlbjogLS0+IHBpcnE9NTQgLT4g
aXJxPTU0IChnc2k9NTQpDQpbICAgIDAuMjY3MjE1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA1
NCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAwLjI2NzIyMF0geGVuX21hcF9waXJx
X2dzaTogcmV0dXJuaW5nIGlycSA1NCBmb3IgZ3NpIDU0DQpbICAgIDAuMjY3MjI1XSB4ZW46
IC0tPiBwaXJxPTU0IC0+IGlycT01NCAoZ3NpPTU0KQ0KWyAgICAwLjI2NzIyOV0gQWxyZWFk
eSBzZXR1cCB0aGUgR1NJIDo1NA0KWyAgICAwLjI2NzIzOV0geGVuOiByZWdpc3RlcmluZyBn
c2kgNTQgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC4yNjcyNDNdIHhlbl9tYXBf
cGlycV9nc2k6IHJldHVybmluZyBpcnEgNTQgZm9yIGdzaSA1NA0KWyAgICAwLjI2NzI0OF0g
eGVuOiAtLT4gcGlycT01NCAtPiBpcnE9NTQgKGdzaT01NCkNClsgICAgMC4yNjcyNTJdIEFs
cmVhZHkgc2V0dXAgdGhlIEdTSSA6NTQNClsgICAgMC4yNjcyNzBdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDE2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuMjY3MjgwXSB4ZW46
IC0tPiBwaXJxPTE2IC0+IGlycT0xNiAoZ3NpPTE2KQ0KWyAgICAwLjI2NzMwMl0gcGNpX2J1
cyAwMDAwOjAwOiByZXNvdXJjZSA0IFtpbyAgMHgwMDAwLTB4MGNmN10NClsgICAgMC4yNjcz
MDddIHBjaV9idXMgMDAwMDowMDogcmVzb3VyY2UgNSBbaW8gIDB4MGQwMC0weGZmZmZdDQpb
ICAgIDAuMjY3MzExXSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDYgW21lbSAweDAwMGEw
MDAwLTB4MDAwYmZmZmZdDQpbICAgIDAuMjY3MzE2XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291
cmNlIDcgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZmZmZdDQpbICAgIDAuMjY3MzIxXSBwY2lf
YnVzIDAwMDA6MDA6IHJlc291cmNlIDggW21lbSAweGIwMDAwMDAwLTB4ZGZmZmZmZmZdDQpb
ICAgIDAuMjY3MzI2XSBwY2lfYnVzIDAwMDA6MDA6IHJlc291cmNlIDkgW21lbSAweGYwMDAw
MDAwLTB4ZmViZmZmZmZdDQpbICAgIDAuMjY3MzMxXSBwY2lfYnVzIDAwMDA6MGI6IHJlc291
cmNlIDAgW2lvICAweGUwMDAtMHhlZmZmXQ0KWyAgICAwLjI2NzMzNV0gcGNpX2J1cyAwMDAw
OjBiOiByZXNvdXJjZSAxIFttZW0gMHhmYTAwMDAwMC0weGZlOWZmZmZmXQ0KWyAgICAwLjI2
NzM0MF0gcGNpX2J1cyAwMDAwOjBiOiByZXNvdXJjZSAyIFttZW0gMHhkMDAwMDAwMC0weGRm
ZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY3MzQ2XSBwY2lfYnVzIDAwMDA6MGE6IHJl
c291cmNlIDEgW21lbSAweGY5ZjAwMDAwLTB4ZjlmZmZmZmZdDQpbICAgIDAuMjY3MzUxXSBw
Y2lfYnVzIDAwMDA6MDk6IHJlc291cmNlIDAgW2lvICAweGQwMDAtMHhkZmZmXQ0KWyAgICAw
LjI2NzM1NV0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAxIFttZW0gMHhmOWUwMDAwMC0w
eGY5ZWZmZmZmXQ0KWyAgICAwLjI2NzM2MF0gcGNpX2J1cyAwMDAwOjA5OiByZXNvdXJjZSAy
IFttZW0gMHhjZmYwMDAwMC0weGNmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY3MzY2
XSBwY2lfYnVzIDAwMDA6MDg6IHJlc291cmNlIDAgW2lvICAweGMwMDAtMHhjZmZmXQ0KWyAg
ICAwLjI2NzM3MF0gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJjZSAxIFttZW0gMHhmOWQwMDAw
MC0weGY5ZGZmZmZmXQ0KWyAgICAwLjI2NzM3NV0gcGNpX2J1cyAwMDAwOjA4OiByZXNvdXJj
ZSAyIFttZW0gMHhjZmUwMDAwMC0weGNmZWZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY3
Mzg4XSBwY2lfYnVzIDAwMDA6MDY6IHJlc291cmNlIDEgW21lbSAweGY5YzAwMDAwLTB4Zjlj
ZmZmZmZdDQpbICAgIDAuMjY3MzkzXSBwY2lfYnVzIDAwMDA6MDc6IHJlc291cmNlIDEgW21l
bSAweGY5YzAwMDAwLTB4ZjljZmZmZmZdDQpbICAgIDAuMjY3Mzk4XSBwY2lfYnVzIDAwMDA6
MDU6IHJlc291cmNlIDAgW2lvICAweGIwMDAtMHhiZmZmXQ0KWyAgICAwLjI2NzQwMl0gcGNp
X2J1cyAwMDAwOjA1OiByZXNvdXJjZSAxIFttZW0gMHhmOWIwMDAwMC0weGY5YmZmZmZmXQ0K
WyAgICAwLjI2NzQwN10gcGNpX2J1cyAwMDAwOjA1OiByZXNvdXJjZSAyIFttZW0gMHhiMDAw
MDAwMC0weGJmZmZmZmZmIDY0Yml0IHByZWZdDQpbICAgIDAuMjY3NDEzXSBwY2lfYnVzIDAw
MDA6MDQ6IHJlc291cmNlIDEgW21lbSAweGY5YTAwMDAwLTB4ZjlhZmZmZmZdDQpbICAgIDAu
MjY3NDE4XSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDAgW2lvICAweGEwMDAtMHhhZmZm
XQ0KWyAgICAwLjI2NzQyMl0gcGNpX2J1cyAwMDAwOjAzOiByZXNvdXJjZSA0IFtpbyAgMHgw
MDAwLTB4MGNmN10NClsgICAgMC4yNjc0MjddIHBjaV9idXMgMDAwMDowMzogcmVzb3VyY2Ug
NSBbaW8gIDB4MGQwMC0weGZmZmZdDQpbICAgIDAuMjY3NDMxXSBwY2lfYnVzIDAwMDA6MDM6
IHJlc291cmNlIDYgW21lbSAweDAwMGEwMDAwLTB4MDAwYmZmZmZdDQpbICAgIDAuMjY3NDM2
XSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDcgW21lbSAweDAwMGQwMDAwLTB4MDAwZGZm
ZmZdDQpbICAgIDAuMjY3NDQxXSBwY2lfYnVzIDAwMDA6MDM6IHJlc291cmNlIDggW21lbSAw
eGIwMDAwMDAwLTB4ZGZmZmZmZmZdDQpbICAgIDAuMjY3NDQ2XSBwY2lfYnVzIDAwMDA6MDM6
IHJlc291cmNlIDkgW21lbSAweGYwMDAwMDAwLTB4ZmViZmZmZmZdDQpbICAgIDAuMjY3NTA0
XSBORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDINClsgICAgMC4yNjc4MjNdIElQ
IHJvdXRlIGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMzI3NjggKG9yZGVyOiA2LCAyNjIx
NDQgYnl0ZXMpDQpbICAgIDAuMjY4OTUxXSBUQ1AgZXN0YWJsaXNoZWQgaGFzaCB0YWJsZSBl
bnRyaWVzOiAxMzEwNzIgKG9yZGVyOiA5LCAyMDk3MTUyIGJ5dGVzKQ0KWyAgICAwLjI3MDQ4
MV0gVENQIGJpbmQgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDEwLCA0MTk0
MzA0IGJ5dGVzKQ0KWyAgICAwLjI3ODc4OF0gVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVk
IChlc3RhYmxpc2hlZCAxMzEwNzIgYmluZCA2NTUzNikNClsgICAgMC4yNzg4MTFdIFRDUCBy
ZW5vIHJlZ2lzdGVyZWQNClsgICAgMC4yNzg4NDZdIFVEUCBoYXNoIHRhYmxlIGVudHJpZXM6
IDUxMiAob3JkZXI6IDQsIDgxOTIwIGJ5dGVzKQ0KWyAgICAwLjI3ODk5NV0gVURQLUxpdGUg
aGFzaCB0YWJsZSBlbnRyaWVzOiA1MTIgKG9yZGVyOiA0LCA4MTkyMCBieXRlcykNClsgICAg
MC4yNzkzMDRdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQ0KWyAgICAwLjI3
OTYwMV0gUlBDOiBSZWdpc3RlcmVkIG5hbWVkIFVOSVggc29ja2V0IHRyYW5zcG9ydCBtb2R1
bGUuDQpbICAgIDAuMjc5NjQxXSBSUEM6IFJlZ2lzdGVyZWQgdWRwIHRyYW5zcG9ydCBtb2R1
bGUuDQpbICAgIDAuMjc5NjQ1XSBSUEM6IFJlZ2lzdGVyZWQgdGNwIHRyYW5zcG9ydCBtb2R1
bGUuDQpbICAgIDAuMjc5NjQ5XSBSUEM6IFJlZ2lzdGVyZWQgdGNwIE5GU3Y0LjEgYmFja2No
YW5uZWwgdHJhbnNwb3J0IG1vZHVsZS4NClsgICAgMC41NjgxNzZdIHBjaSAwMDAwOjBiOjAw
LjA6IEJvb3QgdmlkZW8gZGV2aWNlDQpbICAgIDAuNTY4MzU1XSBwY2kgMDAwMDowNjowMC4w
OiBUSSBYSU8yMDAwYSBxdWlyayBkZXRlY3RlZDsgc2Vjb25kYXJ5IGJ1cyBmYXN0IGJhY2st
dG8tYmFjayB0cmFuc2ZlcnMgZGlzYWJsZWQNClsgICAgMC41Njg1NzNdIFBDSTogQ0xTIDY0
IGJ5dGVzLCBkZWZhdWx0IDY0DQpbICAgIDAuNTY4NzA0XSBUcnlpbmcgdG8gdW5wYWNrIHJv
b3RmcyBpbWFnZSBhcyBpbml0cmFtZnMuLi4NClsgICAgMC41ODIxMDVdIEZyZWVpbmcgaW5p
dHJkIG1lbW9yeTogNjcyNGsgZnJlZWQNClsgICAgMC41ODc5NjddIERNQS1BUEk6IHByZWFs
bG9jYXRlZCAzMjc2OCBkZWJ1ZyBlbnRyaWVzDQpbICAgIDAuNTg3OTc4XSBETUEtQVBJOiBk
ZWJ1Z2dpbmcgZW5hYmxlZCBieSBrZXJuZWwgY29uZmlnDQpbICAgIDAuNTkwNDg1XSBtaWNy
b2NvZGU6IENQVTA6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYNClsgICAgMC41OTA1MTJdIG1p
Y3JvY29kZTogQ1BVMTogcGF0Y2hfbGV2ZWw9MHgwMTAwMDBiZg0KWyAgICAwLjU5MDU1NV0g
bWljcm9jb2RlOiBDUFUyOiBwYXRjaF9sZXZlbD0weDAxMDAwMGJmDQpbICAgIDAuNTkwNjMy
XSBtaWNyb2NvZGU6IENQVTM6IHBhdGNoX2xldmVsPTB4MDEwMDAwYmYNClsgICAgMC41OTA3
MjRdIG1pY3JvY29kZTogQ1BVNDogcGF0Y2hfbGV2ZWw9MHgwMTAwMDBiZg0KWyAgICAwLjU5
MDc5OV0gbWljcm9jb2RlOiBDUFU1OiBwYXRjaF9sZXZlbD0weDAxMDAwMGJmDQpbICAgIDAu
NTkwOTUyXSBtaWNyb2NvZGU6IE1pY3JvY29kZSBVcGRhdGUgRHJpdmVyOiB2Mi4wMCA8dGln
cmFuQGFpdmF6aWFuLmZzbmV0LmNvLnVrPiwgUGV0ZXIgT3J1YmENClsgICAgMC41OTE4MjNd
IEludGVsIEFFUy1OSSBpbnN0cnVjdGlvbnMgYXJlIG5vdCBkZXRlY3RlZC4NClsgICAgMC41
OTIzMzFdIGF1ZGl0OiBpbml0aWFsaXppbmcgbmV0bGluayBzb2NrZXQgKGRpc2FibGVkKQ0K
WyAgICAwLjU5MjM3MV0gdHlwZT0yMDAwIGF1ZGl0KDEzMjYzNzExMTQuMDY5OjEpOiBpbml0
aWFsaXplZA0KWyAgICAwLjYxMzMyNV0gSHVnZVRMQiByZWdpc3RlcmVkIDIgTUIgcGFnZSBz
aXplLCBwcmUtYWxsb2NhdGVkIDAgcGFnZXMNClsgICAgMC42MjM1MjldIFZGUzogRGlzayBx
dW90YXMgZHF1b3RfNi41LjINClsgICAgMC42MjM3NjhdIERxdW90LWNhY2hlIGhhc2ggdGFi
bGUgZW50cmllczogNTEyIChvcmRlciAwLCA0MDk2IGJ5dGVzKQ0KWyAgICAwLjYyNjQ0MV0g
TlRGUyBkcml2ZXIgMi4xLjMwIFtGbGFnczogUi9XXS4NClsgICAgMC42MjY4MTVdIGZ1c2Ug
aW5pdCAoQVBJIHZlcnNpb24gNy4xNykNClsgICAgMC42Mjg0NzFdIEJ0cmZzIGxvYWRlZA0K
WyAgICAwLjYyODQ4M10gbXNnbW5pIGhhcyBiZWVuIHNldCB0byAxODI5DQpbICAgIDAuNjI4
ODUxXSBTRUxpbnV4OiAgUmVnaXN0ZXJpbmcgbmV0ZmlsdGVyIGhvb2tzDQpbICAgIDAuNjMw
NTU5XSBCbG9jayBsYXllciBTQ1NJIGdlbmVyaWMgKGJzZykgZHJpdmVyIHZlcnNpb24gMC40
IGxvYWRlZCAobWFqb3IgMjUzKQ0KWyAgICAwLjYzMDU3NV0gaW8gc2NoZWR1bGVyIG5vb3Ag
cmVnaXN0ZXJlZA0KWyAgICAwLjYzMDU3OV0gaW8gc2NoZWR1bGVyIGRlYWRsaW5lIHJlZ2lz
dGVyZWQNClsgICAgMC42MzA3MDldIGlvIHNjaGVkdWxlciBjZnEgcmVnaXN0ZXJlZCAoZGVm
YXVsdCkNClsgICAgMC42MzA3MTVdIHN0YXJ0IHBsaXN0IHRlc3QNClsgICAgMC42MzE3MDBd
IGVuZCBwbGlzdCB0ZXN0DQpbICAgIDAuNjMxNzA0XSBsaXN0X3NvcnRfdGVzdDogc3RhcnQg
dGVzdGluZyBsaXN0X3NvcnQoKQ0KWyAgICAwLjYzNTkzNV0gcGNpX2hvdHBsdWc6IFBDSSBI
b3QgUGx1ZyBQQ0kgQ29yZSB2ZXJzaW9uOiAwLjUNClsgICAgMC42MzYyMzldIHBjaWVocDog
UENJIEV4cHJlc3MgSG90IFBsdWcgQ29udHJvbGxlciBEcml2ZXIgdmVyc2lvbjogMC40DQpb
ICAgIDAuNjM2NTQxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVy
IHVkbGZiDQpbICAgIDAuNjM2NjUxXSB2ZXNhZmI6IG1vZGUgaXMgMTI4MHgxMDI0eDMyLCBs
aW5lbGVuZ3RoPTUxMjAsIHBhZ2VzPTANClsgICAgMC42MzY2NTddIHZlc2FmYjogc2Nyb2xs
aW5nOiByZWRyYXcNClsgICAgMC42MzY2NjFdIHZlc2FmYjogVHJ1ZWNvbG9yOiBzaXplPTg6
ODo4OjgsIHNoaWZ0PTI0OjE2Ojg6MA0KWyAgICAwLjYzOTY0MF0gdmVzYWZiOiBmcmFtZWJ1
ZmZlciBhdCAweGZiMDAwMDAwLCBtYXBwZWQgdG8gMHhmZmZmYzkwMDEwODgwMDAwLCB1c2lu
ZyAxMDI0MGssIHRvdGFsIDE0MzM2aw0KWyAgICAwLjY2MTI3Ml0gQ29uc29sZTogc3dpdGNo
aW5nIHRvIGNvbG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDE2MHg2NA0KWyAgICAwLjY4MTcy
OV0gZmIwOiBWRVNBIFZHQSBmcmFtZSBidWZmZXIgZGV2aWNlDQpbICAgIDAuNjgyMjY4XSBp
bnB1dDogUG93ZXIgQnV0dG9uIGFzIC9kZXZpY2VzL0xOWFNZU1RNOjAwL2RldmljZTowMC9Q
TlAwQzBDOjAwL2lucHV0L2lucHV0MA0KWyAgICAwLjY4MjQ4MF0gQUNQSTogUG93ZXIgQnV0
dG9uIFtQV1JCXQ0KWyAgICAwLjY4Mjc1Nl0gaW5wdXQ6IFBvd2VyIEJ1dHRvbiBhcyAvZGV2
aWNlcy9MTlhTWVNUTTowMC9MTlhQV1JCTjowMC9pbnB1dC9pbnB1dDENClsgICAgMC42ODI5
MzldIEFDUEk6IFBvd2VyIEJ1dHRvbiBbUFdSRl0NClsgICAgMC42ODc4NDhdIEV2ZW50LWNo
YW5uZWwgZGV2aWNlIGluc3RhbGxlZC4NClsgICAgMC42ODgzMDVdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDIyIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuNjg4NDYyXSB4ZW46
IC0tPiBwaXJxPTIyIC0+IGlycT0yMiAoZ3NpPTIyKQ0KWyAgICAwLjY4ODY1Ml0geGVuOiBy
ZWdpc3RlcmluZyBnc2kgNDMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC42ODg4
MDZdIHhlbjogLS0+IHBpcnE9NDMgLT4gaXJxPTQzIChnc2k9NDMpDQpbICAgIDAuNjg4OTgy
XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0MyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAg
ICAwLjY4OTEzOV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA0MyBmb3IgZ3Np
IDQzDQpbICAgIDAuNjg5Mjc2XSB4ZW46IC0tPiBwaXJxPTQzIC0+IGlycT00MyAoZ3NpPTQz
KQ0KWyAgICAwLjY4OTM5OF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0Mw0KWyAgICAwLjY4
OTU0MF0geGVuOiByZWdpc3RlcmluZyBnc2kgNDIgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDEN
ClsgICAgMC42ODk3MTZdIHhlbjogLS0+IHBpcnE9NDIgLT4gaXJxPTQyIChnc2k9NDIpDQpb
ICAgIDAuNjg5ODkzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0MiB0cmlnZ2VyaW5nIDAgcG9s
YXJpdHkgMQ0KWyAgICAwLjY5MDA0MV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGly
cSA0MiBmb3IgZ3NpIDQyDQpbICAgIDAuNjkwMTM0XSB4ZW46IC0tPiBwaXJxPTQyIC0+IGly
cT00MiAoZ3NpPTQyKQ0KWyAgICAwLjY5MDMwOF0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0
Mg0KWyAgICAwLjY5MDQ1N10geGVuOiByZWdpc3RlcmluZyBnc2kgNDEgdHJpZ2dlcmluZyAw
IHBvbGFyaXR5IDENClsgICAgMC42OTA2MTBdIHhlbjogLS0+IHBpcnE9NDEgLT4gaXJxPTQx
IChnc2k9NDEpDQpbICAgIDAuNjkwNzg1XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0MSB0cmln
Z2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAwLjY5MDkyN10geGVuX21hcF9waXJxX2dzaTog
cmV0dXJuaW5nIGlycSA0MSBmb3IgZ3NpIDQxDQpbICAgIDAuNjkxMDk4XSB4ZW46IC0tPiBw
aXJxPTQxIC0+IGlycT00MSAoZ3NpPTQxKQ0KWyAgICAwLjY5MTIxOF0gQWxyZWFkeSBzZXR1
cCB0aGUgR1NJIDo0MQ0KWyAgICAwLjY5MTM2MV0geGVuOiByZWdpc3RlcmluZyBnc2kgNDAg
dHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC42OTE1MTZdIHhlbjogLS0+IHBpcnE9
NDAgLT4gaXJxPTQwIChnc2k9NDApDQpbICAgIDAuNjkxNjkxXSB4ZW46IHJlZ2lzdGVyaW5n
IGdzaSA0MCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAwLjY5MTgzOV0geGVuX21h
cF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSA0MCBmb3IgZ3NpIDQwDQpbICAgIDAuNjkxOTgz
XSB4ZW46IC0tPiBwaXJxPTQwIC0+IGlycT00MCAoZ3NpPTQwKQ0KWyAgICAwLjY5MjEwM10g
QWxyZWFkeSBzZXR1cCB0aGUgR1NJIDo0MA0KWyAgICAwLjY5MjI0N10geGVuOiByZWdpc3Rl
cmluZyBnc2kgMzMgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC42OTIzOTVdIHhl
bjogLS0+IHBpcnE9MzMgLT4gaXJxPTMzIChnc2k9MzMpDQpbICAgIDAuNjk4NzMwXSBwY2li
YWNrIDAwMDA6MDU6MDAuMDogZW5hYmxpbmcgZGV2aWNlICgwMDAwIC0+IDAwMDMpDQpbICAg
IDAuNjk5NjgzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAzMiB0cmlnZ2VyaW5nIDAgcG9sYXJp
dHkgMQ0KWyAgICAwLjcxMTMzMl0geGVuOiAtLT4gcGlycT0zMiAtPiBpcnE9MzIgKGdzaT0z
MikNClsgICAgMC43MTc2MTRdIHBjaWJhY2sgMDAwMDowNzowMS4yOiBlbmFibGluZyBkZXZp
Y2UgKDAxMTQgLT4gMDExNikNClsgICAgMC43MTg1NzZdIHhlbjogcmVnaXN0ZXJpbmcgZ3Np
IDQ2IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuNzMwMzQxXSB4ZW46IC0tPiBw
aXJxPTQ2IC0+IGlycT00NiAoZ3NpPTQ2KQ0KWyAgICAwLjczNjc1Ml0gcGNpYmFjayAwMDAw
OjA3OjAxLjE6IGVuYWJsaW5nIGRldmljZSAoMDExNCAtPiAwMTE2KQ0KWyAgICAwLjczNzcx
MV0geGVuOiByZWdpc3RlcmluZyBnc2kgNDUgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsg
ICAgMC43NDk2NzhdIHhlbjogLS0+IHBpcnE9NDUgLT4gaXJxPTQ1IChnc2k9NDUpDQpbICAg
IDAuNzU2MDYxXSBwY2liYWNrIDAwMDA6MDc6MDEuMDogZW5hYmxpbmcgZGV2aWNlICgwMTE0
IC0+IDAxMTYpDQpbICAgIDAuNzU3MDAzXSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0NCB0cmln
Z2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAwLjc2OTAzM10geGVuOiAtLT4gcGlycT00NCAt
PiBpcnE9NDQgKGdzaT00NCkNClsgICAgMC43NzU1NzldIHhlbjogcmVnaXN0ZXJpbmcgZ3Np
IDMxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuNzgyMTY3XSB4ZW46IC0tPiBw
aXJxPTMxIC0+IGlycT0zMSAoZ3NpPTMxKQ0KWyAgICAwLjc4ODgyMV0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMzEgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMC43OTU0MzhdIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMzEgZm9yIGdzaSAzMQ0KWyAgICAwLjc5
NjQzNF0geGVuOiAtLT4gcGlycT0zMSAtPiBpcnE9MzEgKGdzaT0zMSkNClsgICAgMC44MDg1
NzldIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MzENClsgICAgMC44MTUxNDNdIHhlbjogcmVn
aXN0ZXJpbmcgZ3NpIDMwIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDAuODIxNjg1
XSB4ZW46IC0tPiBwaXJxPTMwIC0+IGlycT0zMCAoZ3NpPTMwKQ0KWyAgICAwLjgyODIwNl0g
eGVuOiByZWdpc3RlcmluZyBnc2kgMzAgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAg
MC44MzQ3NDBdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMzAgZm9yIGdzaSAz
MA0KWyAgICAwLjg0MTA4OF0geGVuOiAtLT4gcGlycT0zMCAtPiBpcnE9MzAgKGdzaT0zMCkN
ClsgICAgMC44NDEyNThdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MzANClsgICAgMC44NDEz
MjNdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDI5IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpb
ICAgIDAuODQxMzMyXSB4ZW46IC0tPiBwaXJxPTI5IC0+IGlycT0yOSAoZ3NpPTI5KQ0KWyAg
ICAwLjg0MTQyM10geGVuOiByZWdpc3RlcmluZyBnc2kgMjkgdHJpZ2dlcmluZyAwIHBvbGFy
aXR5IDENClsgICAgMC44NDE0MjVdIHhlbl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEg
MjkgZm9yIGdzaSAyOQ0KWyAgICAwLjg0MTQyNl0geGVuOiAtLT4gcGlycT0yOSAtPiBpcnE9
MjkgKGdzaT0yOSkNClsgICAgMC44NDE0MjddIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MjkN
ClsgICAgMC44NDE1MDRdIHhlbjogcmVnaXN0ZXJpbmcgZ3NpIDI4IHRyaWdnZXJpbmcgMCBw
b2xhcml0eSAxDQpbICAgIDAuODQxNTEyXSB4ZW46IC0tPiBwaXJxPTI4IC0+IGlycT0yOCAo
Z3NpPTI4KQ0KWyAgICAwLjg0MTU5N10geGVuOiByZWdpc3RlcmluZyBnc2kgMjggdHJpZ2dl
cmluZyAwIHBvbGFyaXR5IDENClsgICAgMC44NDE1OTldIHhlbl9tYXBfcGlycV9nc2k6IHJl
dHVybmluZyBpcnEgMjggZm9yIGdzaSAyOA0KWyAgICAwLjg0MTYwMF0geGVuOiAtLT4gcGly
cT0yOCAtPiBpcnE9MjggKGdzaT0yOCkNClsgICAgMC44NDE2MDJdIEFscmVhZHkgc2V0dXAg
dGhlIEdTSSA6MjgNClsgICAgMC44NDE3OTZdIHhlbi1wY2liYWNrOiBiYWNrZW5kIGlzIHBh
c3N0aHJvdWdoDQpbICAgIDAuODQzMTc1XSBTZXJpYWw6IDgyNTAvMTY1NTAgZHJpdmVyLCA0
IHBvcnRzLCBJUlEgc2hhcmluZyBlbmFibGVkDQpbICAgIDAuOTY4NjMzXSBocGV0X2FjcGlf
YWRkOiBubyBhZGRyZXNzIG9yIGlycXMgaW4gX0NSUw0KWyAgICAwLjk3NDk0Nl0gTm9uLXZv
bGF0aWxlIG1lbW9yeSBkcml2ZXIgdjEuMw0KWyAgICAwLjk3NTkzM10gTGludXggYWdwZ2Fy
dCBpbnRlcmZhY2UgdjAuMTAzDQpbICAgIDAuOTg5ODMwXSBbZHJtXSBJbml0aWFsaXplZCBk
cm0gMS4xLjAgMjAwNjA4MTANClsgICAgMC45OTA4MDddIFtkcm06aTkxNV9pbml0XSAqRVJS
T1IqIGRybS9pOTE1IGNhbid0IHdvcmsgd2l0aG91dCBpbnRlbF9hZ3AgbW9kdWxlIQ0KWyAg
ICAxLjAwMjEzNl0gaTJjLWNvcmU6IGRyaXZlciBbY2g3MDA2XSB1c2luZyBsZWdhY3kgc3Vz
cGVuZCBtZXRob2QNClsgICAgMS4wMDMxMzFdIGkyYy1jb3JlOiBkcml2ZXIgW2NoNzAwNl0g
dXNpbmcgbGVnYWN5IHJlc3VtZSBtZXRob2QNClsgICAgMS4wMTkyNjddIGJyZDogbW9kdWxl
IGxvYWRlZA0KWyAgICAxLjA0MTcxNF0gbG9vcDogbW9kdWxlIGxvYWRlZA0KWyAgICAxLjA0
OTI2MV0gYWhjaSAwMDAwOjAwOjExLjA6IHZlcnNpb24gMy4wDQpbICAgIDEuMDUwMjQ1XSB4
ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOSB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAx
LjA2MTQyOF0geGVuOiAtLT4gcGlycT0xOSAtPiBpcnE9MTkgKGdzaT0xOSkNClsgICAgMS4w
Njc2OTBdIGFoY2kgMDAwMDowMDoxMS4wOiBBSENJIDAwMDEuMDIwMCAzMiBzbG90cyA2IHBv
cnRzIDYgR2JwcyAweDNmIGltcGwgU0FUQSBtb2RlDQpbICAgIDEuMDczOTEzXSBhaGNpIDAw
MDA6MDA6MTEuMDogZmxhZ3M6IDY0Yml0IG5jcSBzbnRmIGlsY2sgcG0gbGVkIGNsbyBwbXAg
cGlvIHNsdW0gcGFydCANClsgICAgMS4wODMxNjBdIHNjc2kwIDogYWhjaQ0KWyAgICAxLjA4
OTczMF0gc2NzaTEgOiBhaGNpDQpbICAgIDEuMDk2MTg1XSBzY3NpMiA6IGFoY2kNClsgICAg
MS4xMDI2MzVdIHNjc2kzIDogYWhjaQ0KWyAgICAxLjEwODkxM10gc2NzaTQgOiBhaGNpDQpb
ICAgIDEuMTE1MDg2XSBzY3NpNSA6IGFoY2kNClsgICAgMS4xMjEzMzFdIGF0YTE6IFNBVEEg
bWF4IFVETUEvMTMzIGFiYXIgbTEwMjRAMHhmOThmZjAwMCBwb3J0IDB4Zjk4ZmYxMDAgaXJx
IDM0Mg0KWyAgICAxLjEyMjI3NV0gYXRhMjogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAy
NEAweGY5OGZmMDAwIHBvcnQgMHhmOThmZjE4MCBpcnEgMzQyDQpbICAgIDEuMTIyMjc1XSBh
dGEzOiBTQVRBIG1heCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4Zjk4ZmYwMDAgcG9ydCAweGY5
OGZmMjAwIGlycSAzNDINClsgICAgMS4xMjIyNzVdIGF0YTQ6IFNBVEEgbWF4IFVETUEvMTMz
IGFiYXIgbTEwMjRAMHhmOThmZjAwMCBwb3J0IDB4Zjk4ZmYyODAgaXJxIDM0Mg0KWyAgICAx
LjEyMjI3NV0gYXRhNTogU0FUQSBtYXggVURNQS8xMzMgYWJhciBtMTAyNEAweGY5OGZmMDAw
IHBvcnQgMHhmOThmZjMwMCBpcnEgMzQyDQpbICAgIDEuMTIyMjc1XSBhdGE2OiBTQVRBIG1h
eCBVRE1BLzEzMyBhYmFyIG0xMDI0QDB4Zjk4ZmYwMDAgcG9ydCAweGY5OGZmMzgwIGlycSAz
NDINClsgICAgMS4xNTYyMzldIHR1bjogVW5pdmVyc2FsIFRVTi9UQVAgZGV2aWNlIGRyaXZl
ciwgMS42DQpbICAgIDEuMTU3MjM0XSB0dW46IChDKSAxOTk5LTIwMDQgTWF4IEtyYXNueWFu
c2t5IDxtYXhrQHF1YWxjb21tLmNvbT4NClsgICAgMS4xNjcyOTZdIGUxMDAwOiBJbnRlbChS
KSBQUk8vMTAwMCBOZXR3b3JrIERyaXZlciAtIHZlcnNpb24gNy4zLjIxLWs4LU5BUEkNClsg
ICAgMS4xNjgyODhdIGUxMDAwOiBDb3B5cmlnaHQgKGMpIDE5OTktMjAwNiBJbnRlbCBDb3Jw
b3JhdGlvbi4NClsgICAgMS4xNzgyNThdIHNreTI6IGRyaXZlciB2ZXJzaW9uIDEuMzANClsg
ICAgMS4xODQwMzJdIHI4MTY5IEdpZ2FiaXQgRXRoZXJuZXQgZHJpdmVyIDIuM0xLLU5BUEkg
bG9hZGVkDQpbICAgIDEuMTg1MDE5XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSA0NiB0cmlnZ2Vy
aW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAxLjE5NDg5OV0geGVuX21hcF9waXJxX2dzaTogcmV0
dXJuaW5nIGlycSA0NiBmb3IgZ3NpIDQ2DQpbICAgIDEuMTk1ODg5XSB4ZW46IC0tPiBwaXJx
PTQ2IC0+IGlycT00NiAoZ3NpPTQ2KQ0KWyAgICAxLjIwNTcyMV0gQWxyZWFkeSBzZXR1cCB0
aGUgR1NJIDo0Ng0KWyAgICAxLjIxMjE0Ml0gcjgxNjkgMDAwMDowOTowMC4wOiBldGgwOiBS
VEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMDAxZjgwMDAsIDQwOjYxOjg2OmY0OjY3OmQ5
LCBYSUQgMDgxMDAwYzAgSVJRIDM0Mw0KWyAgICAxLjIxMzA2MV0gcjgxNjkgMDAwMDowOTow
MC4wOiBldGgwOiBqdW1ibyBmZWF0dXJlcyBbZnJhbWVzOiA5MjAwIGJ5dGVzLCB0eCBjaGVj
a3N1bW1pbmc6IGtvXQ0KWyAgICAxLjIyMzY4M10gcjgxNjkgR2lnYWJpdCBFdGhlcm5ldCBk
cml2ZXIgMi4zTEstTkFQSSBsb2FkZWQNClsgICAgMS4yMjkzNjJdIHhlbjogcmVnaXN0ZXJp
bmcgZ3NpIDUxIHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDEuMjM1MDU4XSB4ZW46
IC0tPiBwaXJxPTUxIC0+IGlycT01MSAoZ3NpPTUxKQ0KWyAgICAxLjI0MTgwMl0gcjgxNjkg
MDAwMDowODowMC4wOiBldGgxOiBSVEw4MTY4ZC84MTExZCBhdCAweGZmZmZjOTAwMDAxZmEw
MDAsIDQwOjYxOjg2OmY0OjY3OmQ4LCBYSUQgMDgxMDAwYzAgSVJRIDM0NA0KWyAgICAxLjI0
MjI3OF0gcjgxNjkgMDAwMDowODowMC4wOiBldGgxOiBqdW1ibyBmZWF0dXJlcyBbZnJhbWVz
OiA5MjAwIGJ5dGVzLCB0eCBjaGVja3N1bW1pbmc6IGtvXQ0KWyAgICAxLjI1NTEyOV0gZWhj
aV9oY2Q6IFVTQiAyLjAgJ0VuaGFuY2VkJyBIb3N0IENvbnRyb2xsZXIgKEVIQ0kpIERyaXZl
cg0KWyAgICAxLjI1NjA5OV0gZWhjaV9oY2Q6IGJsb2NrIHNpemVzOiBxaCAxMTIgcXRkIDk2
IGl0ZCAxOTIgc2l0ZCA5Ng0KWyAgICAxLjI2NzMzMl0geGVuOiByZWdpc3RlcmluZyBnc2kg
MTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS4yNzMzNTddIHhlbjogLS0+IHBp
cnE9MTcgLT4gaXJxPTE3IChnc2k9MTcpDQpbICAgIDEuMjc5Mzk4XSBlaGNpX2hjZCAwMDAw
OjAwOjEyLjI6IEVIQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDEuMjg1NDg5XSBkcml2ZXJz
L3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5nIGZpbGUgJ2RldmljZXMnDQpbICAgIDEuMjg2
NDY0XSBkcml2ZXJzL3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5nIGZpbGUgJzAwMScNClsg
ICAgMS4yOTc4MDNdIGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogbmV3IFVTQiBidXMgcmVnaXN0
ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQpbICAgIDEuMjk4Nzg2XSBlaGNpX2hjZCAw
MDAwOjAwOjEyLjI6IHJlc2V0IGhjc19wYXJhbXMgMHgxMDE1MDUgZGJnPTEgY2M9MSBwY2M9
NSBvcmRlcmVkICFwcGMgcG9ydHM9NQ0KWyAgICAxLjI5ODc4Nl0gZWhjaV9oY2QgMDAwMDow
MDoxMi4yOiByZXNldCBoY2NfcGFyYW1zIGEwNzIgdGhyZXNoIDcgdWZyYW1lcyAyNTYvNTEy
LzEwMjQNClsgICAgMS4zMTYzMTJdIGVoY2lfaGNkIDAwMDA6MDA6MTIuMjogYXBwbHlpbmcg
QU1EIFNCNzAwL1NCODAwL0h1ZHNvbi0yLzMgRUhDSSBkdW1teSBxaCB3b3JrYXJvdW5kDQpb
ICAgIDEuMzIyNzUxXSBRVUlSSzogRW5hYmxlIEFNRCBQTEwgZml4DQpbICAgIDEuMzIzNjU4
XSBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IGRlYnVnIHBvcnQgMQ0KWyAgICAxLjMyMzY1OF0g
ZWhjaV9oY2QgMDAwMDowMDoxMi4yOiByZXNldCBjb21tYW5kIDAwODAwMDIgKHBhcmspPTAg
aXRocmVzaD04IHBlcmlvZD0xMDI0IFJlc2V0IEhBTFQNClsgICAgMS4zMjM2NThdIGVoY2lf
aGNkIDAwMDA6MDA6MTIuMjogTVdJIGFjdGl2ZQ0KWyAgICAxLjMyMzY1OF0gZWhjaV9oY2Qg
MDAwMDowMDoxMi4yOiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAgICAxLjM1NDEy
NF0gZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBpcnEgMTcsIGlvIG1lbSAweGY5OGZmNDAwDQpb
ICAgIDEuMzU1MDg0XSBlaGNpX2hjZCAwMDAwOjAwOjEyLjI6IGluaXQgY29tbWFuZCAwMDEw
MDA1IChwYXJrKT0wIGl0aHJlc2g9MSBwZXJpb2Q9NTEyIFJVTg0KWyAgICAxLjM3MzA4Ml0g
ZWhjaV9oY2QgMDAwMDowMDoxMi4yOiBVU0IgMi4wIHN0YXJ0ZWQsIEVIQ0kgMS4wMA0KWyAg
ICAxLjM3OTQ5OF0gdXNiIHVzYjE6IGRlZmF1bHQgbGFuZ3VhZ2UgMHgwNDA5DQpbICAgIDEu
Mzg1NzY0XSB1c2IgdXNiMTogdWRldiAxLCBidXNudW0gMSwgbWlub3IgPSAwDQpbICAgIDEu
Mzg2NzE0XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIs
IGlkUHJvZHVjdD0wMDAyDQpbICAgIDEuMzg2NzE0XSB1c2IgdXNiMTogTmV3IFVTQiBkZXZp
Y2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMS4z
ODY3MTRdIHVzYiB1c2IxOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAx
LjM4NjcxNF0gdXNiIHVzYjE6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMwKyBlaGNp
X2hjZA0KWyAgICAxLjM4NjcxNF0gdXNiIHVzYjE6IFNlcmlhbE51bWJlcjogMDAwMDowMDox
Mi4yDQpbICAgIDEuNDIzNTM4XSB1c2IgdXNiMTogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAx
LjQyNDUyNF0gdXNiIHVzYjE6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9p
Y2UNClsgICAgMS40MzU5NTddIHVzYiB1c2IxOiBhZGRpbmcgMS0wOjEuMCAoY29uZmlnICMx
LCBpbnRlcmZhY2UgMCkNClsgICAgMS40NDIyNjBdIGh1YiAxLTA6MS4wOiB1c2JfcHJvYmVf
aW50ZXJmYWNlDQpbICAgIDEuNDQzMjE2XSBodWIgMS0wOjEuMDogdXNiX3Byb2JlX2ludGVy
ZmFjZSAtIGdvdCBpZA0KWyAgICAxLjQ0MzIxNl0gaHViIDEtMDoxLjA6IFVTQiBodWIgZm91
bmQNClsgICAgMS40NjAxOTBdIGF0YTI6IFNBVEEgbGluayBkb3duIChTU3RhdHVzIDAgU0Nv
bnRyb2wgMzAwKQ0KWyAgICAxLjQ2MDI1NV0gYXRhNDogU0FUQSBsaW5rIGRvd24gKFNTdGF0
dXMgMCBTQ29udHJvbCAzMDApDQpbICAgIDEuNDYwMzI0XSBhdGE1OiBTQVRBIGxpbmsgZG93
biAoU1N0YXR1cyAwIFNDb250cm9sIDMwMCkNClsgICAgMS40NjAzNjhdIGF0YTY6IFNBVEEg
bGluayBkb3duIChTU3RhdHVzIDAgU0NvbnRyb2wgMzAwKQ0KWyAgICAxLjQ4NTE4N10gaHVi
IDEtMDoxLjA6IDUgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMS40ODYxNjldIGh1YiAxLTA6MS4w
OiBzdGFuZGFsb25lIGh1Yg0KWyAgICAxLjQ4NjE2OV0gaHViIDEtMDoxLjA6IG5vIHBvd2Vy
IHN3aXRjaGluZyAodXNiIDEuMCkNClsgICAgMS40ODYxNjldIGh1YiAxLTA6MS4wOiBpbmRp
dmlkdWFsIHBvcnQgb3Zlci1jdXJyZW50IHByb3RlY3Rpb24NClsgICAgMS40ODYxNjldIGh1
YiAxLTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRpbWU6IDIwbXMNClsgICAgMS41
MTYzODddIGh1YiAxLTA6MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAx
LjUxNzM2Ml0gaHViIDEtMDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBu
b24tc3dpdGNoYWJsZSBodWINClsgICAgMS41MjkxMTFdIGRyaXZlcnMvdXNiL2NvcmUvaW5v
ZGUuYzogY3JlYXRpbmcgZmlsZSAnMDAxJw0KWyAgICAxLjUzNTcwNF0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTcgdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS41NDE5NjhdIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTcgZm9yIGdzaSAxNw0KWyAgICAxLjU0
Mjk2MF0geGVuOiAtLT4gcGlycT0xNyAtPiBpcnE9MTcgKGdzaT0xNykNClsgICAgMS41NTQ1
MjldIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTcNClsgICAgMS41NjA3NDBdIGVoY2lfaGNk
IDAwMDA6MDA6MTMuMjogRUhDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS41NjcwMDRdIGRy
aXZlcnMvdXNiL2NvcmUvaW5vZGUuYzogY3JlYXRpbmcgZmlsZSAnMDAyJw0KWyAgICAxLjU3
MzQ2MF0gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBh
c3NpZ25lZCBidXMgbnVtYmVyIDINClsgICAgMS41NzQ0MzddIGVoY2lfaGNkIDAwMDA6MDA6
MTMuMjogcmVzZXQgaGNzX3BhcmFtcyAweDEwMTUwNSBkYmc9MSBjYz0xIHBjYz01IG9yZGVy
ZWQgIXBwYyBwb3J0cz01DQpbICAgIDEuNTg2MTk3XSBlaGNpX2hjZCAwMDAwOjAwOjEzLjI6
IHJlc2V0IGhjY19wYXJhbXMgYTA3MiB0aHJlc2ggNyB1ZnJhbWVzIDI1Ni81MTIvMTAyNA0K
WyAgICAxLjU4NzE4Nl0gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBhcHBseWluZyBBTUQgU0I3
MDAvU0I4MDAvSHVkc29uLTIvMyBFSENJIGR1bW15IHFoIHdvcmthcm91bmQNClsgICAgMS41
ODcxODZdIGVoY2lfaGNkIDAwMDA6MDA6MTMuMjogZGVidWcgcG9ydCAxDQpbICAgIDEuNTg3
MTg2XSBlaGNpX2hjZCAwMDAwOjAwOjEzLjI6IHJlc2V0IGNvbW1hbmQgMDA4MDAwMiAocGFy
ayk9MCBpdGhyZXNoPTggcGVyaW9kPTEwMjQgUmVzZXQgSEFMVA0KWyAgICAxLjYxMTI2MV0g
ZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBNV0kgYWN0aXZlDQpbICAgIDEuNjE1MTIyXSBhdGEz
OiBTQVRBIGxpbmsgdXAgNi4wIEdicHMgKFNTdGF0dXMgMTMzIFNDb250cm9sIDMwMCkNClsg
ICAgMS42MTUxNjhdIGF0YTE6IFNBVEEgbGluayB1cCAzLjAgR2JwcyAoU1N0YXR1cyAxMjMg
U0NvbnRyb2wgMzAwKQ0KWyAgICAxLjYxMjIzMl0gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBz
dXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAgICAxLjYzNTMwN10gZWhjaV9oY2QgMDAw
MDowMDoxMy4yOiBpcnEgMTcsIGlvIG1lbSAweGY5OGZmODAwDQpbICAgIDEuNjQwMTEzXSBl
aGNpX2hjZCAwMDAwOjAwOjEzLjI6IGluaXQgY29tbWFuZCAwMDEwMDA1IChwYXJrKT0wIGl0
aHJlc2g9MSBwZXJpb2Q9NTEyIFJVTg0KWyAgICAxLjY0MTIxNl0gYXRhMy4wMDogQVRBLTg6
IFNUMjAwMERMMDAzLTlWVDE2NiwgQ0M0NSwgbWF4IFVETUEvMTMzDQpbICAgIDEuNjQxMjE5
XSBhdGEzLjAwOiAzOTA3MDI5MTY4IHNlY3RvcnMsIG11bHRpIDA6IExCQTQ4IE5DUSAoZGVw
dGggMzEvMzIpDQpbICAgIDEuNjQxMjc1XSBodWIgMS0wOjEuMDogc3RhdGUgNyBwb3J0cyA1
IGNoZyAwMDAwIGV2dCAwMDAwDQpbICAgIDEuNjQxNDAyXSBhdGExLjAwOiBBVEEtODogSGl0
YWNoaSBIRFM3MjIwMjBBTEEzMzAsIEpLQU9BMjBOLCBtYXggVURNQS8xMzMNClsgICAgMS42
NDE0MDRdIGF0YTEuMDA6IDM5MDcwMjkxNjggc2VjdG9ycywgbXVsdGkgMDogTEJBNDggTkNR
IChkZXB0aCAzMS8zMiksIEFBDQpbICAgIDEuNjQyMDMyXSBhdGEzLjAwOiBjb25maWd1cmVk
IGZvciBVRE1BLzEzMw0KWyAgICAxLjY0MjkzMl0gYXRhMS4wMDogY29uZmlndXJlZCBmb3Ig
VURNQS8xMzMNClsgICAgMS42NDMxOTldIHNjc2kgMDowOjA6MDogRGlyZWN0LUFjY2VzcyAg
ICAgQVRBICAgICAgSGl0YWNoaSBIRFM3MjIwMiBKS0FPIFBROiAwIEFOU0k6IDUNClsgICAg
MS42NDM3NDJdIHNkIDA6MDowOjA6IFtzZGFdIDM5MDcwMjkxNjggNTEyLWJ5dGUgbG9naWNh
bCBibG9ja3M6ICgyLjAwIFRCLzEuODEgVGlCKQ0KWyAgICAxLjY0Mzg1NF0gc2QgMDowOjA6
MDogW3NkYV0gV3JpdGUgUHJvdGVjdCBpcyBvZmYNClsgICAgMS42NDM4NTldIHNkIDA6MDow
OjA6IFtzZGFdIE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpbICAgIDEuNjQzOTMyXSBzZCAw
OjA6MDowOiBbc2RhXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxl
ZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUENClsgICAgMS42NDgwNzldIGVoY2lfaGNk
IDAwMDA6MDA6MTMuMjogVVNCIDIuMCBzdGFydGVkLCBFSENJIDEuMDANClsgICAgMS42NDgx
NThdIHVzYiB1c2IyOiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQwOQ0KWyAgICAxLjY0ODE3MF0g
dXNiIHVzYjI6IHVkZXYgMSwgYnVzbnVtIDIsIG1pbm9yID0gMTI4DQpbICAgIDEuNjQ4MTcx
XSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJv
ZHVjdD0wMDAyDQpbICAgIDEuNjQ4MTczXSB1c2IgdXNiMjogTmV3IFVTQiBkZXZpY2Ugc3Ry
aW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMS42NDgxNzRd
IHVzYiB1c2IyOiBQcm9kdWN0OiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAxLjY0ODE3
Nl0gdXNiIHVzYjI6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMwKyBlaGNpX2hjZA0K
WyAgICAxLjY0ODE3N10gdXNiIHVzYjI6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMy4yDQpb
ICAgIDEuNzU3MTc2XSB1c2IgdXNiMjogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAxLjc1NzI1
OF0gc2QgMDowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMCB0eXBlIDANClsgICAg
MS43NTc1OTNdIHNjc2kgMjowOjA6MDogRGlyZWN0LUFjY2VzcyAgICAgQVRBICAgICAgU1Qy
MDAwREwwMDMtOVZUMSBDQzQ1IFBROiAwIEFOU0k6IDUNClsgICAgMS43NTgwOThdIHNkIDI6
MDowOjA6IFtzZGJdIDM5MDcwMjkxNjggNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6ICgyLjAw
IFRCLzEuODEgVGlCKQ0KWyAgICAxLjc1ODEwMF0gc2QgMjowOjA6MDogW3NkYl0gNDA5Ni1i
eXRlIHBoeXNpY2FsIGJsb2Nrcw0KWyAgICAxLjc1ODIxNV0gc2QgMjowOjA6MDogW3NkYl0g
V3JpdGUgUHJvdGVjdCBpcyBvZmYNClsgICAgMS43NTgyMTddIHNkIDI6MDowOjA6IFtzZGJd
IE1vZGUgU2Vuc2U6IDAwIDNhIDAwIDAwDQpbICAgIDEuNzU4MjYzXSBzZCAyOjA6MDowOiBb
c2RiXSBXcml0ZSBjYWNoZTogZW5hYmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24n
dCBzdXBwb3J0IERQTyBvciBGVUENClsgICAgMS43NTkxNjBdIHNkIDI6MDowOjA6IEF0dGFj
aGVkIHNjc2kgZ2VuZXJpYyBzZzEgdHlwZSAwDQpbICAgIDEuNzU4NTk2XSB1c2IgdXNiMjog
Y29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KWyAgICAxLjgxOTY1NV0g
dXNiIHVzYjI6IGFkZGluZyAyLTA6MS4wIChjb25maWcgIzEsIGludGVyZmFjZSAwKQ0KWyAg
ICAxLjgxOTcxN10gIHNkYjogc2RiMQ0KWyAgICAxLjgxOTczNV0gIHNkYTogc2RhMSBzZGEy
IHNkYTMNClsgICAgMS44Mzk4NjVdIGh1YiAyLTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNl
DQpbICAgIDEuODQwNTI3XSBzZCAyOjA6MDowOiBbc2RiXSBBdHRhY2hlZCBTQ1NJIGRpc2sN
ClsgICAgMS44NDA2MjBdIHNkIDA6MDowOjA6IFtzZGFdIEF0dGFjaGVkIFNDU0kgZGlzaw0K
WyAgICAxLjg1OTExOF0gaHViIDItMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3Qg
aWQNClsgICAgMS44NTkxMThdIGh1YiAyLTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDEu
ODU5NTI3XSBodWIgMi0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICAxLjg1OTUyOV0g
aHViIDItMDoxLjA6IHN0YW5kYWxvbmUgaHViDQpbICAgIDEuODU5NTMwXSBodWIgMi0wOjEu
MDogbm8gcG93ZXIgc3dpdGNoaW5nICh1c2IgMS4wKQ0KWyAgICAxLjg1OTUzMl0gaHViIDIt
MDoxLjA6IGluZGl2aWR1YWwgcG9ydCBvdmVyLWN1cnJlbnQgcHJvdGVjdGlvbg0KWyAgICAx
Ljg1OTUzM10gaHViIDItMDoxLjA6IHBvd2VyIG9uIHRvIHBvd2VyIGdvb2QgdGltZTogMjBt
cw0KWyAgICAxLjg1OTU0M10gaHViIDItMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJjZSBpcyBn
b29kDQpbICAgIDEuODU5NTQ1XSBodWIgMi0wOjEuMDogdHJ5aW5nIHRvIGVuYWJsZSBwb3J0
IHBvd2VyIG9uIG5vbi1zd2l0Y2hhYmxlIGh1Yg0KWyAgICAxLjg1OTYyMF0gZHJpdmVycy91
c2IvY29yZS9pbm9kZS5jOiBjcmVhdGluZyBmaWxlICcwMDEnDQpbICAgIDEuODU5OTMwXSB4
ZW46IHJlZ2lzdGVyaW5nIGdzaSAxNyB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkgMQ0KWyAgICAx
Ljg1OTkzNV0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxNyBmb3IgZ3NpIDE3
DQpbICAgIDEuODU5OTM3XSB4ZW46IC0tPiBwaXJxPTE3IC0+IGlycT0xNyAoZ3NpPTE3KQ0K
WyAgICAxLjg1OTkzOV0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxNw0KWyAgICAxLjg2MDAx
M10gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAx
Ljg2MDAyNV0gZHJpdmVycy91c2IvY29yZS9pbm9kZS5jOiBjcmVhdGluZyBmaWxlICcwMDMn
DQpbICAgIDEuODYwNDMzXSBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IG5ldyBVU0IgYnVzIHJl
Z2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMw0KWyAgICAxLjg2MDQ0MV0gZWhjaV9o
Y2QgMDAwMDowMDoxNi4yOiByZXNldCBoY3NfcGFyYW1zIDB4MTAxNDA0IGRiZz0xIGNjPTEg
cGNjPTQgb3JkZXJlZCAhcHBjIHBvcnRzPTQNClsgICAgMS44NjA0NDRdIGVoY2lfaGNkIDAw
MDA6MDA6MTYuMjogcmVzZXQgaGNjX3BhcmFtcyBhMDcyIHRocmVzaCA3IHVmcmFtZXMgMjU2
LzUxMi8xMDI0DQpbICAgIDEuODYwNDQ5XSBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IGFwcGx5
aW5nIEFNRCBTQjcwMC9TQjgwMC9IdWRzb24tMi8zIEVIQ0kgZHVtbXkgcWggd29ya2Fyb3Vu
ZA0KWyAgICAxLjg2MDUzN10gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBkZWJ1ZyBwb3J0IDEN
ClsgICAgMS44NjA1NDJdIGVoY2lfaGNkIDAwMDA6MDA6MTYuMjogcmVzZXQgY29tbWFuZCAw
MDgwMDAyIChwYXJrKT0wIGl0aHJlc2g9OCBwZXJpb2Q9MTAyNCBSZXNldCBIQUxUDQpbICAg
IDEuODYwNTY1XSBlaGNpX2hjZCAwMDAwOjAwOjE2LjI6IE1XSSBhY3RpdmUNClsgICAgMS44
NjA1NjZdIGVoY2lfaGNkIDAwMDA6MDA6MTYuMjogc3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtl
dXANClsgICAgMS44NjA1NzVdIGVoY2lfaGNkIDAwMDA6MDA6MTYuMjogaXJxIDE3LCBpbyBt
ZW0gMHhmOThmZmMwMA0KWyAgICAxLjg2MDU3OV0gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBp
bml0IGNvbW1hbmQgMDAxMDAwNSAocGFyayk9MCBpdGhyZXNoPTEgcGVyaW9kPTUxMiBSVU4N
ClsgICAgMS44NjcwOTZdIGVoY2lfaGNkIDAwMDA6MDA6MTYuMjogVVNCIDIuMCBzdGFydGVk
LCBFSENJIDEuMDANClsgICAgMS44NjcxNjldIHVzYiB1c2IzOiBkZWZhdWx0IGxhbmd1YWdl
IDB4MDQwOQ0KWyAgICAxLjg2NzE4Ml0gdXNiIHVzYjM6IHVkZXYgMSwgYnVzbnVtIDMsIG1p
bm9yID0gMjU2DQpbICAgIDEuODY3MTg0XSB1c2IgdXNiMzogTmV3IFVTQiBkZXZpY2UgZm91
bmQsIGlkVmVuZG9yPTFkNmIsIGlkUHJvZHVjdD0wMDAyDQpbICAgIDEuODY3MTg1XSB1c2Ig
dXNiMzogTmV3IFVTQiBkZXZpY2Ugc3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFs
TnVtYmVyPTENClsgICAgMS44NjcxODddIHVzYiB1c2IzOiBQcm9kdWN0OiBFSENJIEhvc3Qg
Q29udHJvbGxlcg0KWyAgICAxLjg2NzE4OV0gdXNiIHVzYjM6IE1hbnVmYWN0dXJlcjogTGlu
dXggMy4yLjAtcmMwKyBlaGNpX2hjZA0KWyAgICAxLjg2NzE5MF0gdXNiIHVzYjM6IFNlcmlh
bE51bWJlcjogMDAwMDowMDoxNi4yDQpbICAgIDEuODY3MzkxXSB1c2IgdXNiMzogdXNiX3By
b2JlX2RldmljZQ0KWyAgICAxLjg2NzM5M10gdXNiIHVzYjM6IGNvbmZpZ3VyYXRpb24gIzEg
Y2hvc2VuIGZyb20gMSBjaG9pY2UNClsgICAgMS44Njc0MTNdIHVzYiB1c2IzOiBhZGRpbmcg
My0wOjEuMCAoY29uZmlnICMxLCBpbnRlcmZhY2UgMCkNClsgICAgMS44Njc1MzVdIGh1YiAz
LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlDQpbICAgIDEuODY3NTM3XSBodWIgMy0wOjEu
MDogdXNiX3Byb2JlX2ludGVyZmFjZSAtIGdvdCBpZA0KWyAgICAxLjg2NzUzOF0gaHViIDMt
MDoxLjA6IFVTQiBodWIgZm91bmQNClsgICAgMS44Njc1NDVdIGh1YiAzLTA6MS4wOiA0IHBv
cnRzIGRldGVjdGVkDQpbICAgIDEuODY3NTQ2XSBodWIgMy0wOjEuMDogc3RhbmRhbG9uZSBo
dWINClsgICAgMS44Njc1NDddIGh1YiAzLTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcgKHVz
YiAxLjApDQpbICAgIDEuODY3NTQ5XSBodWIgMy0wOjEuMDogaW5kaXZpZHVhbCBwb3J0IG92
ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDEuODY3NTUwXSBodWIgMy0wOjEuMDogcG93
ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiAyMG1zDQpbICAgIDEuODY3NTU5XSBodWIgMy0w
OjEuMDogbG9jYWwgcG93ZXIgc291cmNlIGlzIGdvb2QNClsgICAgMS44Njc1NjFdIGh1YiAz
LTA6MS4wOiB0cnlpbmcgdG8gZW5hYmxlIHBvcnQgcG93ZXIgb24gbm9uLXN3aXRjaGFibGUg
aHViDQpbICAgIDEuODY3NjE4XSBkcml2ZXJzL3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5n
IGZpbGUgJzAwMScNClsgICAgMS44NjgwNDhdIG9oY2lfaGNkOiBVU0IgMS4xICdPcGVuJyBI
b3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlcg0KWyAgICAxLjg2ODA1MV0gb2hjaV9oY2Q6
IGJsb2NrIHNpemVzOiBlZCA4MCB0ZCA5Ng0KWyAgICAxLjg2ODE2OF0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS44NjgxOTJdIHhl
bjogLS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpDQpbICAgIDEuODY4MjI4XSBvaGNp
X2hjZCAwMDAwOjAwOjEyLjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDEuODY4MjQ0
XSBkcml2ZXJzL3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5nIGZpbGUgJzAwNCcNClsgICAg
MS44Njg2NTddIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJl
ZCwgYXNzaWduZWQgYnVzIG51bWJlciA0DQpbICAgIDEuODY4NjcyXSBvaGNpX2hjZCAwMDAw
OjAwOjEyLjA6IGVuYWJsZWQgQU1EIHByZWZldGNoIHF1aXJrDQpbICAgIDEuODY4NzQxXSBv
aGNpX2hjZCAwMDAwOjAwOjEyLjA6IGNyZWF0ZWQgZGVidWcgZmlsZXMNClsgICAgMS44Njg3
NDNdIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogc3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtldXAN
ClsgICAgMS44Njg4MDJdIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogaXJxIDE4LCBpbyBtZW0g
MHhmOThmYjAwMA0KWyAgICAxLjkyNDIwNl0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBPSENJ
IGNvbnRyb2xsZXIgc3RhdGUNClsgICAgMS45MjQyMTNdIG9oY2lfaGNkIDAwMDA6MDA6MTIu
MDogT0hDSSAxLjAsIE5PIGxlZ2FjeSBzdXBwb3J0IHJlZ2lzdGVycywgcmggc3RhdGUgcnVu
bmluZw0KWyAgICAxLjkyNDIxN10gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBjb250cm9sIDB4
MjgzIFJXQyBIQ0ZTPW9wZXJhdGlvbmFsIENCU1I9Mw0KWyAgICAxLjkyNDIyMF0gb2hjaV9o
Y2QgMDAwMDowMDoxMi4wOiBjbWRzdGF0dXMgMHgwMDAwMCBTT0M9MA0KWyAgICAxLjkyNDIy
NF0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiBpbnRyc3RhdHVzIDB4MDAwMDAwMDQgU0YNClsg
ICAgMS45MjQyMjddIG9oY2lfaGNkIDAwMDA6MDA6MTIuMDogaW50cmVuYWJsZSAweDgwMDAw
MDVhIE1JRSBSSFNDIFVFIFJEIFdESA0KWyAgICAxLjkyNDIzN10gb2hjaV9oY2QgMDAwMDow
MDoxMi4wOiBoY2NhIGZyYW1lICMwMDA1DQpbICAgIDEuOTI0MjQxXSBvaGNpX2hjZCAwMDAw
OjAwOjEyLjA6IHJvb3RodWIuYSAwMjAwMTIwNSBQT1RQR1Q9MiBOT0NQIE5QUyBORFA9NSg1
KQ0KWyAgICAxLjkyNDI1N10gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiByb290aHViLmIgMDAw
MDAwMDAgUFBDTT0wMDAwIERSPTAwMDANClsgICAgMS45MjQyNjBdIG9oY2lfaGNkIDAwMDA6
MDA6MTIuMDogcm9vdGh1Yi5zdGF0dXMgMDAwMDgwMDAgRFJXRQ0KWyAgICAxLjkyNDI2NF0g
b2hjaV9oY2QgMDAwMDowMDoxMi4wOiByb290aHViLnBvcnRzdGF0dXMgWzBdIDB4MDAwMDAx
MDAgUFBTDQpbICAgIDEuOTI0MjY3XSBvaGNpX2hjZCAwMDAwOjAwOjEyLjA6IHJvb3RodWIu
cG9ydHN0YXR1cyBbMV0gMHgwMDAwMDEwMCBQUFMNClsgICAgMS45MjQyNzFdIG9oY2lfaGNk
IDAwMDA6MDA6MTIuMDogcm9vdGh1Yi5wb3J0c3RhdHVzIFsyXSAweDAwMDAwMTAwIFBQUw0K
WyAgICAxLjkyNDI3NF0gb2hjaV9oY2QgMDAwMDowMDoxMi4wOiByb290aHViLnBvcnRzdGF0
dXMgWzNdIDB4MDAwMDAxMDAgUFBTDQpbICAgIDEuOTI0Mjc4XSBvaGNpX2hjZCAwMDAwOjAw
OjEyLjA6IHJvb3RodWIucG9ydHN0YXR1cyBbNF0gMHgwMDAwMDEwMCBQUFMNClsgICAgMS45
MjQzMDBdIHVzYiB1c2I0OiBkZWZhdWx0IGxhbmd1YWdlIDB4MDQwOQ0KWyAgICAxLjkyNDMx
Ml0gdXNiIHVzYjQ6IHVkZXYgMSwgYnVzbnVtIDQsIG1pbm9yID0gMzg0DQpbICAgIDEuOTI0
MzE0XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2UgZm91bmQsIGlkVmVuZG9yPTFkNmIsIGlk
UHJvZHVjdD0wMDAxDQpbICAgIDEuOTI0MzE2XSB1c2IgdXNiNDogTmV3IFVTQiBkZXZpY2Ug
c3RyaW5nczogTWZyPTMsIFByb2R1Y3Q9MiwgU2VyaWFsTnVtYmVyPTENClsgICAgMS45MjQz
MTddIHVzYiB1c2I0OiBQcm9kdWN0OiBPSENJIEhvc3QgQ29udHJvbGxlcg0KWyAgICAxLjky
NDMxOV0gdXNiIHVzYjQ6IE1hbnVmYWN0dXJlcjogTGludXggMy4yLjAtcmMwKyBvaGNpX2hj
ZA0KWyAgICAxLjkyNDMyMF0gdXNiIHVzYjQ6IFNlcmlhbE51bWJlcjogMDAwMDowMDoxMi4w
DQpbICAgIDEuOTI0Nzk2XSB1c2IgdXNiNDogdXNiX3Byb2JlX2RldmljZQ0KWyAgICAxLjky
NDc5OF0gdXNiIHVzYjQ6IGNvbmZpZ3VyYXRpb24gIzEgY2hvc2VuIGZyb20gMSBjaG9pY2UN
ClsgICAgMS45MjQ4MTBdIHVzYiB1c2I0OiBhZGRpbmcgNC0wOjEuMCAoY29uZmlnICMxLCBp
bnRlcmZhY2UgMCkNClsgICAgMS45MjQ5MzFdIGh1YiA0LTA6MS4wOiB1c2JfcHJvYmVfaW50
ZXJmYWNlDQpbICAgIDEuOTI0OTMzXSBodWIgNC0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFj
ZSAtIGdvdCBpZA0KWyAgICAxLjkyNDkzNV0gaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQN
ClsgICAgMS45MjQ5NTRdIGh1YiA0LTA6MS4wOiA1IHBvcnRzIGRldGVjdGVkDQpbICAgIDEu
OTI0OTU1XSBodWIgNC0wOjEuMDogc3RhbmRhbG9uZSBodWINClsgICAgMS45MjQ5NTZdIGh1
YiA0LTA6MS4wOiBubyBwb3dlciBzd2l0Y2hpbmcgKHVzYiAxLjApDQpbICAgIDEuOTI0OTU3
XSBodWIgNC0wOjEuMDogbm8gb3Zlci1jdXJyZW50IHByb3RlY3Rpb24NClsgICAgMS45MjQ5
NTldIGh1YiA0LTA6MS4wOiBwb3dlciBvbiB0byBwb3dlciBnb29kIHRpbWU6IDRtcw0KWyAg
ICAxLjkyNDk2OV0gaHViIDQtMDoxLjA6IGxvY2FsIHBvd2VyIHNvdXJjZSBpcyBnb29kDQpb
ICAgIDEuOTI0OTcwXSBodWIgNC0wOjEuMDogdHJ5aW5nIHRvIGVuYWJsZSBwb3J0IHBvd2Vy
IG9uIG5vbi1zd2l0Y2hhYmxlIGh1Yg0KWyAgICAxLjkyNTAwOV0gZHJpdmVycy91c2IvY29y
ZS9pbm9kZS5jOiBjcmVhdGluZyBmaWxlICcwMDEnDQpbICAgIDEuOTI1MDkzXSBlaGNpX2hj
ZCAwMDAwOjAwOjEyLjI6IEhTIGNvbXBhbmlvbiBmb3IgMDAwMDowMDoxMi4wDQpbICAgIDEu
OTI1Mzk4XSB4ZW46IHJlZ2lzdGVyaW5nIGdzaSAxOCB0cmlnZ2VyaW5nIDAgcG9sYXJpdHkg
MQ0KWyAgICAxLjkyNTQwMl0geGVuX21hcF9waXJxX2dzaTogcmV0dXJuaW5nIGlycSAxOCBm
b3IgZ3NpIDE4DQpbICAgIDEuOTI1NDA0XSB4ZW46IC0tPiBwaXJxPTE4IC0+IGlycT0xOCAo
Z3NpPTE4KQ0KWyAgICAxLjkyNTQwNl0gQWxyZWFkeSBzZXR1cCB0aGUgR1NJIDoxOA0KWyAg
ICAxLjkyNTQyNV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBPSENJIEhvc3QgQ29udHJvbGxl
cg0KWyAgICAxLjkyNTQzN10gZHJpdmVycy91c2IvY29yZS9pbm9kZS5jOiBjcmVhdGluZyBm
aWxlICcwMDUnDQpbICAgIDEuOTI1NjkzXSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IG5ldyBV
U0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNQ0KWyAgICAxLjkyNTcw
NV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBlbmFibGVkIEFNRCBwcmVmZXRjaCBxdWlyaw0K
WyAgICAxLjkyNTc2OV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiBjcmVhdGVkIGRlYnVnIGZp
bGVzDQpbICAgIDEuOTI1NzcxXSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IHN1cHBvcnRzIFVT
QiByZW1vdGUgd2FrZXVwDQpbICAgIDEuOTI1Nzc4XSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6
IGlycSAxOCwgaW8gbWVtIDB4Zjk4ZmMwMDANClsgICAgMS45NjAxNThdIGh1YiAyLTA6MS4w
OiBzdGF0ZSA3IHBvcnRzIDUgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS45NjgyMTldIGh1
YiAzLTA6MS4wOiBzdGF0ZSA3IHBvcnRzIDQgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMS45
ODExNjhdIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogT0hDSSBjb250cm9sbGVyIHN0YXRlDQpb
ICAgIDEuOTgxMTczXSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IE9IQ0kgMS4wLCBOTyBsZWdh
Y3kgc3VwcG9ydCByZWdpc3RlcnMsIHJoIHN0YXRlIHJ1bm5pbmcNClsgICAgMS45ODExNzdd
IG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogY29udHJvbCAweDI4MyBSV0MgSENGUz1vcGVyYXRp
b25hbCBDQlNSPTMNClsgICAgMS45ODExODBdIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogY21k
c3RhdHVzIDB4MDAwMDAgU09DPTANClsgICAgMS45ODExOTNdIG9oY2lfaGNkIDAwMDA6MDA6
MTMuMDogaW50cnN0YXR1cyAweDAwMDAwMDA0IFNGDQpbICAgIDEuOTgxMTk2XSBvaGNpX2hj
ZCAwMDAwOjAwOjEzLjA6IGludHJlbmFibGUgMHg4MDAwMDA1YSBNSUUgUkhTQyBVRSBSRCBX
REgNClsgICAgMS45ODEyMDddIG9oY2lfaGNkIDAwMDA6MDA6MTMuMDogaGNjYSBmcmFtZSAj
MDAwNQ0KWyAgICAxLjk4MTIxMV0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiByb290aHViLmEg
MDIwMDEyMDUgUE9UUEdUPTIgTk9DUCBOUFMgTkRQPTUoNSkNClsgICAgMS45ODEyMTRdIG9o
Y2lfaGNkIDAwMDA6MDA6MTMuMDogcm9vdGh1Yi5iIDAwMDAwMDAwIFBQQ009MDAwMCBEUj0w
MDAwDQpbICAgIDEuOTgxMjE3XSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IHJvb3RodWIuc3Rh
dHVzIDAwMDA4MDAwIERSV0UNClsgICAgMS45ODEyMjFdIG9oY2lfaGNkIDAwMDA6MDA6MTMu
MDogcm9vdGh1Yi5wb3J0c3RhdHVzIFswXSAweDAwMDAwMTAwIFBQUw0KWyAgICAxLjk4MTIy
NF0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiByb290aHViLnBvcnRzdGF0dXMgWzFdIDB4MDAw
MDAxMDAgUFBTDQpbICAgIDEuOTgxMjI3XSBvaGNpX2hjZCAwMDAwOjAwOjEzLjA6IHJvb3Ro
dWIucG9ydHN0YXR1cyBbMl0gMHgwMDAwMDEwMCBQUFMNClsgICAgMS45ODEyMzFdIG9oY2lf
aGNkIDAwMDA6MDA6MTMuMDogcm9vdGh1Yi5wb3J0c3RhdHVzIFszXSAweDAwMDAwMTAwIFBQ
Uw0KWyAgICAxLjk4MTIzNF0gb2hjaV9oY2QgMDAwMDowMDoxMy4wOiByb290aHViLnBvcnRz
dGF0dXMgWzRdIDB4MDAwMDAxMDAgUFBTDQpbICAgIDEuOTgxMjU2XSB1c2IgdXNiNTogZGVm
YXVsdCBsYW5ndWFnZSAweDA0MDkNClsgICAgMS45ODEyNzldIHVzYiB1c2I1OiB1ZGV2IDEs
IGJ1c251bSA1LCBtaW5vciA9IDUxMg0KWyAgICAxLjk4MTI4MV0gdXNiIHVzYjU6IE5ldyBV
U0IgZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICAx
Ljk4MTI4Ml0gdXNiIHVzYjU6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9k
dWN0PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDEuOTgxMjg0XSB1c2IgdXNiNTogUHJvZHVj
dDogT0hDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS45ODEyODVdIHVzYiB1c2I1OiBNYW51
ZmFjdHVyZXI6IExpbnV4IDMuMi4wLXJjMCsgb2hjaV9oY2QNClsgICAgMS45ODEyODddIHVz
YiB1c2I1OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTMuMA0KWyAgICAxLjk4MTYyOV0gdXNi
IHVzYjU6IHVzYl9wcm9iZV9kZXZpY2UNClsgICAgMS45ODE2MzFdIHVzYiB1c2I1OiBjb25m
aWd1cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpbICAgIDEuOTgxNjQxXSB1c2Ig
dXNiNTogYWRkaW5nIDUtMDoxLjAgKGNvbmZpZyAjMSwgaW50ZXJmYWNlIDApDQpbICAgIDEu
OTgxNzg2XSBodWIgNS0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZQ0KWyAgICAxLjk4MTc4
OF0gaHViIDUtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3QgaWQNClsgICAgMS45
ODE3OTldIGh1YiA1LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDEuOTgxODA4XSBodWIg
NS0wOjEuMDogNSBwb3J0cyBkZXRlY3RlZA0KWyAgICAxLjk4MTgwOV0gaHViIDUtMDoxLjA6
IHN0YW5kYWxvbmUgaHViDQpbICAgIDEuOTgxODEwXSBodWIgNS0wOjEuMDogbm8gcG93ZXIg
c3dpdGNoaW5nICh1c2IgMS4wKQ0KWyAgICAxLjk4MTgxMl0gaHViIDUtMDoxLjA6IG5vIG92
ZXItY3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDEuOTgxODEzXSBodWIgNS0wOjEuMDogcG93
ZXIgb24gdG8gcG93ZXIgZ29vZCB0aW1lOiA0bXMNClsgICAgMS45ODE4MjNdIGh1YiA1LTA6
MS4wOiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAxLjk4MTgyNV0gaHViIDUt
MDoxLjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJsZSBo
dWINClsgICAgMS45ODE4NjZdIGRyaXZlcnMvdXNiL2NvcmUvaW5vZGUuYzogY3JlYXRpbmcg
ZmlsZSAnMDAxJw0KWyAgICAxLjk4MTkzM10gZWhjaV9oY2QgMDAwMDowMDoxMy4yOiBIUyBj
b21wYW5pb24gZm9yIDAwMDA6MDA6MTMuMA0KWyAgICAxLjk4MjI5NV0geGVuOiByZWdpc3Rl
cmluZyBnc2kgMTggdHJpZ2dlcmluZyAwIHBvbGFyaXR5IDENClsgICAgMS45ODIyOTldIHhl
bl9tYXBfcGlycV9nc2k6IHJldHVybmluZyBpcnEgMTggZm9yIGdzaSAxOA0KWyAgICAxLjk4
MjMwMV0geGVuOiAtLT4gcGlycT0xOCAtPiBpcnE9MTggKGdzaT0xOCkNClsgICAgMS45ODIz
MDJdIEFscmVhZHkgc2V0dXAgdGhlIEdTSSA6MTgNClsgICAgMS45ODIzMjldIG9oY2lfaGNk
IDAwMDA6MDA6MTQuNTogT0hDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMS45ODIzMzhdIGRy
aXZlcnMvdXNiL2NvcmUvaW5vZGUuYzogY3JlYXRpbmcgZmlsZSAnMDA2Jw0KWyAgICAxLjk4
Mjc2N10gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBh
c3NpZ25lZCBidXMgbnVtYmVyIDYNClsgICAgMS45ODI3NzldIG9oY2lfaGNkIDAwMDA6MDA6
MTQuNTogZW5hYmxlZCBBTUQgcHJlZmV0Y2ggcXVpcmsNClsgICAgMS45ODI4NTJdIG9oY2lf
aGNkIDAwMDA6MDA6MTQuNTogY3JlYXRlZCBkZWJ1ZyBmaWxlcw0KWyAgICAxLjk4Mjg1NF0g
b2hjaV9oY2QgMDAwMDowMDoxNC41OiBzdXBwb3J0cyBVU0IgcmVtb3RlIHdha2V1cA0KWyAg
ICAxLjk4Mjg2MV0gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBpcnEgMTgsIGlvIG1lbSAweGY5
OGZkMDAwDQpbICAgIDIuMDI1MTUyXSBodWIgNC0wOjEuMDogc3RhdGUgNyBwb3J0cyA1IGNo
ZyAwMDAwIGV2dCAwMDAwDQpbICAgIDIuMDM4MTg1XSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6
IE9IQ0kgY29udHJvbGxlciBzdGF0ZQ0KWyAgICAyLjAzODE4OV0gb2hjaV9oY2QgMDAwMDow
MDoxNC41OiBPSENJIDEuMCwgTk8gbGVnYWN5IHN1cHBvcnQgcmVnaXN0ZXJzLCByaCBzdGF0
ZSBydW5uaW5nDQpbICAgIDIuMDM4MTkzXSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IGNvbnRy
b2wgMHgyODMgUldDIEhDRlM9b3BlcmF0aW9uYWwgQ0JTUj0zDQpbICAgIDIuMDM4MTk2XSBv
aGNpX2hjZCAwMDAwOjAwOjE0LjU6IGNtZHN0YXR1cyAweDAwMDAwIFNPQz0wDQpbICAgIDIu
MDM4MjAwXSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IGludHJzdGF0dXMgMHgwMDAwMDAwNCBT
Rg0KWyAgICAyLjAzODIwM10gb2hjaV9oY2QgMDAwMDowMDoxNC41OiBpbnRyZW5hYmxlIDB4
ODAwMDAwNWEgTUlFIFJIU0MgVUUgUkQgV0RIDQpbICAgIDIuMDM4MjIzXSBvaGNpX2hjZCAw
MDAwOjAwOjE0LjU6IGhjY2EgZnJhbWUgIzAwMDUNClsgICAgMi4wMzgyMjddIG9oY2lfaGNk
IDAwMDA6MDA6MTQuNTogcm9vdGh1Yi5hIDAyMDAxMjAyIFBPVFBHVD0yIE5PQ1AgTlBTIE5E
UD0yKDIpDQpbICAgIDIuMDM4MjMwXSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IHJvb3RodWIu
YiAwMDAwMDAwMCBQUENNPTAwMDAgRFI9MDAwMA0KWyAgICAyLjAzODIzM10gb2hjaV9oY2Qg
MDAwMDowMDoxNC41OiByb290aHViLnN0YXR1cyAwMDAwODAwMCBEUldFDQpbICAgIDIuMDM4
MjM3XSBvaGNpX2hjZCAwMDAwOjAwOjE0LjU6IHJvb3RodWIucG9ydHN0YXR1cyBbMF0gMHgw
MDAwMDEwMCBQUFMNClsgICAgMi4wMzgyNDBdIG9oY2lfaGNkIDAwMDA6MDA6MTQuNTogcm9v
dGh1Yi5wb3J0c3RhdHVzIFsxXSAweDAwMDAwMTAwIFBQUw0KWyAgICAyLjAzODI2NF0gdXNi
IHVzYjY6IGRlZmF1bHQgbGFuZ3VhZ2UgMHgwNDA5DQpbICAgIDIuMDM4MjgwXSB1c2IgdXNi
NjogdWRldiAxLCBidXNudW0gNiwgbWlub3IgPSA2NDANClsgICAgMi4wMzgyODJdIHVzYiB1
c2I2OiBOZXcgVVNCIGRldmljZSBmb3VuZCwgaWRWZW5kb3I9MWQ2YiwgaWRQcm9kdWN0PTAw
MDENClsgICAgMi4wMzgyODNdIHVzYiB1c2I2OiBOZXcgVVNCIGRldmljZSBzdHJpbmdzOiBN
ZnI9MywgUHJvZHVjdD0yLCBTZXJpYWxOdW1iZXI9MQ0KWyAgICAyLjAzODI4NV0gdXNiIHVz
YjY6IFByb2R1Y3Q6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDIuMDM4Mjg2XSB1c2Ig
dXNiNjogTWFudWZhY3R1cmVyOiBMaW51eCAzLjIuMC1yYzArIG9oY2lfaGNkDQpbICAgIDIu
MDM4Mjg4XSB1c2IgdXNiNjogU2VyaWFsTnVtYmVyOiAwMDAwOjAwOjE0LjUNClsgICAgMi4w
Mzg2MTZdIHVzYiB1c2I2OiB1c2JfcHJvYmVfZGV2aWNlDQpbICAgIDIuMDM4NjE4XSB1c2Ig
dXNiNjogY29uZmlndXJhdGlvbiAjMSBjaG9zZW4gZnJvbSAxIGNob2ljZQ0KWyAgICAyLjAz
ODYyN10gdXNiIHVzYjY6IGFkZGluZyA2LTA6MS4wIChjb25maWcgIzEsIGludGVyZmFjZSAw
KQ0KWyAgICAyLjAzODc4MV0gaHViIDYtMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UNClsg
ICAgMi4wMzg3ODNdIGh1YiA2LTA6MS4wOiB1c2JfcHJvYmVfaW50ZXJmYWNlIC0gZ290IGlk
DQpbICAgIDIuMDM4Nzg0XSBodWIgNi0wOjEuMDogVVNCIGh1YiBmb3VuZA0KWyAgICAyLjAz
ODc5M10gaHViIDYtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNClsgICAgMi4wMzg3OTVdIGh1
YiA2LTA6MS4wOiBzdGFuZGFsb25lIGh1Yg0KWyAgICAyLjAzODc5Nl0gaHViIDYtMDoxLjA6
IG5vIHBvd2VyIHN3aXRjaGluZyAodXNiIDEuMCkNClsgICAgMi4wMzg3OTddIGh1YiA2LTA6
MS4wOiBubyBvdmVyLWN1cnJlbnQgcHJvdGVjdGlvbg0KWyAgICAyLjAzODc5OV0gaHViIDYt
MDoxLjA6IHBvd2VyIG9uIHRvIHBvd2VyIGdvb2QgdGltZTogNG1zDQpbICAgIDIuMDM4ODA5
XSBodWIgNi0wOjEuMDogbG9jYWwgcG93ZXIgc291cmNlIGlzIGdvb2QNClsgICAgMi4wMzg4
MTBdIGh1YiA2LTA6MS4wOiB0cnlpbmcgdG8gZW5hYmxlIHBvcnQgcG93ZXIgb24gbm9uLXN3
aXRjaGFibGUgaHViDQpbICAgIDIuMDM4ODg4XSBkcml2ZXJzL3VzYi9jb3JlL2lub2RlLmM6
IGNyZWF0aW5nIGZpbGUgJzAwMScNClsgICAgMi4wMzkyOTNdIHhlbjogcmVnaXN0ZXJpbmcg
Z3NpIDE4IHRyaWdnZXJpbmcgMCBwb2xhcml0eSAxDQpbICAgIDIuMDM5Mjk3XSB4ZW5fbWFw
X3BpcnFfZ3NpOiByZXR1cm5pbmcgaXJxIDE4IGZvciBnc2kgMTgNClsgICAgMi4wMzkyOThd
IHhlbjogLS0+IHBpcnE9MTggLT4gaXJxPTE4IChnc2k9MTgpDQpbICAgIDIuMDM5MzAwXSBB
bHJlYWR5IHNldHVwIHRoZSBHU0kgOjE4DQpbICAgIDIuMDM5MzE4XSBvaGNpX2hjZCAwMDAw
OjAwOjE2LjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpbICAgIDIuMDM5MzI3XSBkcml2ZXJz
L3VzYi9jb3JlL2lub2RlLmM6IGNyZWF0aW5nIGZpbGUgJzAwNycNClsgICAgMi4wMzk1NTRd
IG9oY2lfaGNkIDAwMDA6MDA6MTYuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWdu
ZWQgYnVzIG51bWJlciA3DQpbICAgIDIuMDM5NTY2XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6
IGVuYWJsZWQgQU1EIHByZWZldGNoIHF1aXJrDQpbICAgIDIuMDM5NjM4XSBvaGNpX2hjZCAw
MDAwOjAwOjE2LjA6IGNyZWF0ZWQgZGVidWcgZmlsZXMNClsgICAgMi4wMzk2MzldIG9oY2lf
aGNkIDAwMDA6MDA6MTYuMDogc3VwcG9ydHMgVVNCIHJlbW90ZSB3YWtldXANClsgICAgMi4w
Mzk2NDddIG9oY2lfaGNkIDAwMDA6MDA6MTYuMDogaXJxIDE4LCBpbyBtZW0gMHhmOThmZTAw
MA0KWyAgICAyLjA4MjE0NF0gaHViIDUtMDoxLjA6IHN0YXRlIDcgcG9ydHMgNSBjaGcgMDAw
MCBldnQgMDAwMA0KWyAgICAyLjA5NTIwN10gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBPSENJ
IGNvbnRyb2xsZXIgc3RhdGUNClsgICAgMi4wOTUyMTRdIG9oY2lfaGNkIDAwMDA6MDA6MTYu
MDogT0hDSSAxLjAsIE5PIGxlZ2FjeSBzdXBwb3J0IHJlZ2lzdGVycywgcmggc3RhdGUgcnVu
bmluZw0KWyAgICAyLjA5NTIxOF0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBjb250cm9sIDB4
MjgzIFJXQyBIQ0ZTPW9wZXJhdGlvbmFsIENCU1I9Mw0KWyAgICAyLjA5NTIyMV0gb2hjaV9o
Y2QgMDAwMDowMDoxNi4wOiBjbWRzdGF0dXMgMHgwMDAwMCBTT0M9MA0KWyAgICAyLjA5NTIy
NF0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiBpbnRyc3RhdHVzIDB4MDAwMDAwMDQgU0YNClsg
ICAgMi4wOTUyMjhdIG9oY2lfaGNkIDAwMDA6MDA6MTYuMDogaW50cmVuYWJsZSAweDgwMDAw
MDVhIE1JRSBSSFNDIFVFIFJEIFdESA0KWyAgICAyLjA5NTI1MF0gb2hjaV9oY2QgMDAwMDow
MDoxNi4wOiBoY2NhIGZyYW1lICMwMDA1DQpbICAgIDIuMDk1MjUzXSBvaGNpX2hjZCAwMDAw
OjAwOjE2LjA6IHJvb3RodWIuYSAwMjAwMTIwNCBQT1RQR1Q9MiBOT0NQIE5QUyBORFA9NCg0
KQ0KWyAgICAyLjA5NTI1Nl0gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiByb290aHViLmIgMDAw
MDAwMDAgUFBDTT0wMDAwIERSPTAwMDANClsgICAgMi4wOTUyNjBdIG9oY2lfaGNkIDAwMDA6
MDA6MTYuMDogcm9vdGh1Yi5zdGF0dXMgMDAwMDgwMDAgRFJXRQ0KWyAgICAyLjA5NTI2M10g
b2hjaV9oY2QgMDAwMDowMDoxNi4wOiByb290aHViLnBvcnRzdGF0dXMgWzBdIDB4MDAwMDAx
MDAgUFBTDQpbICAgIDIuMDk1MjY3XSBvaGNpX2hjZCAwMDAwOjAwOjE2LjA6IHJvb3RodWIu
cG9ydHN0YXR1cyBbMV0gMHgwMDAwMDEwMCBQUFMNClsgICAgMi4wOTUyNzBdIG9oY2lfaGNk
IDAwMDA6MDA6MTYuMDogcm9vdGh1Yi5wb3J0c3RhdHVzIFsyXSAweDAwMDAwMTAwIFBQUw0K
WyAgICAyLjA5NTI3M10gb2hjaV9oY2QgMDAwMDowMDoxNi4wOiByb290aHViLnBvcnRzdGF0
dXMgWzNdIDB4MDAwMDAxMDAgUFBTDQpbICAgIDIuMDk1MjkyXSB1c2IgdXNiNzogZGVmYXVs
dCBsYW5ndWFnZSAweDA0MDkNClsgICAgMi4wOTUzMDVdIHVzYiB1c2I3OiB1ZGV2IDEsIGJ1
c251bSA3LCBtaW5vciA9IDc2OA0KWyAgICAyLjA5NTMwN10gdXNiIHVzYjc6IE5ldyBVU0Ig
ZGV2aWNlIGZvdW5kLCBpZFZlbmRvcj0xZDZiLCBpZFByb2R1Y3Q9MDAwMQ0KWyAgICAyLjA5
NTMwOF0gdXNiIHVzYjc6IE5ldyBVU0IgZGV2aWNlIHN0cmluZ3M6IE1mcj0zLCBQcm9kdWN0
PTIsIFNlcmlhbE51bWJlcj0xDQpbICAgIDIuMDk1MzEwXSB1c2IgdXNiNzogUHJvZHVjdDog
T0hDSSBIb3N0IENvbnRyb2xsZXINClsgICAgMi4wOTUzMTFdIHVzYiB1c2I3OiBNYW51ZmFj
dHVyZXI6IExpbnV4IDMuMi4wLXJjMCsgb2hjaV9oY2QNClsgICAgMi4wOTUzMTNdIHVzYiB1
c2I3OiBTZXJpYWxOdW1iZXI6IDAwMDA6MDA6MTYuMA0KWyAgICAyLjA5NTY0Ml0gdXNiIHVz
Yjc6IHVzYl9wcm9iZV9kZXZpY2UNClsgICAgMi4wOTU2NDRdIHVzYiB1c2I3OiBjb25maWd1
cmF0aW9uICMxIGNob3NlbiBmcm9tIDEgY2hvaWNlDQpbICAgIDIuMDk1NjUzXSB1c2IgdXNi
NzogYWRkaW5nIDctMDoxLjAgKGNvbmZpZyAjMSwgaW50ZXJmYWNlIDApDQpbICAgIDIuMDk1
ODIwXSBodWIgNy0wOjEuMDogdXNiX3Byb2JlX2ludGVyZmFjZQ0KWyAgICAyLjA5NTgyMl0g
aHViIDctMDoxLjA6IHVzYl9wcm9iZV9pbnRlcmZhY2UgLSBnb3QgaWQNClsgICAgMi4wOTU4
MjNdIGh1YiA3LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpbICAgIDIuMDk1ODMzXSBodWIgNy0w
OjEuMDogNCBwb3J0cyBkZXRlY3RlZA0KWyAgICAyLjA5NTgzNF0gaHViIDctMDoxLjA6IHN0
YW5kYWxvbmUgaHViDQpbICAgIDIuMDk1ODM1XSBodWIgNy0wOjEuMDogbm8gcG93ZXIgc3dp
dGNoaW5nICh1c2IgMS4wKQ0KWyAgICAyLjA5NTg0Nl0gaHViIDctMDoxLjA6IG5vIG92ZXIt
Y3VycmVudCBwcm90ZWN0aW9uDQpbICAgIDIuMDk1ODQ4XSBodWIgNy0wOjEuMDogcG93ZXIg
b24gdG8gcG93ZXIgZ29vZCB0aW1lOiA0bXMNClsgICAgMi4wOTU4NThdIGh1YiA3LTA6MS4w
OiBsb2NhbCBwb3dlciBzb3VyY2UgaXMgZ29vZA0KWyAgICAyLjA5NTg1OV0gaHViIDctMDox
LjA6IHRyeWluZyB0byBlbmFibGUgcG9ydCBwb3dlciBvbiBub24tc3dpdGNoYWJsZSBodWIN
ClsgICAgMi4wOTU4OThdIGRyaXZlcnMvdXNiL2NvcmUvaW5vZGUuYzogY3JlYXRpbmcgZmls
ZSAnMDAxJw0KWyAgICAyLjA5NTk5M10gZWhjaV9oY2QgMDAwMDowMDoxNi4yOiBIUyBjb21w
YW5pb24gZm9yIDAwMDA6MDA6MTYuMA0KWyAgICAyLjA5NjM0NV0gdWhjaV9oY2Q6IFVTQiBV
bml2ZXJzYWwgSG9zdCBDb250cm9sbGVyIEludGVyZmFjZSBkcml2ZXINClsgICAgMi4wOTY2
NTRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdXNibHANClsg
ICAgMi4wOTY2NTVdIEluaXRpYWxpemluZyBVU0IgTWFzcyBTdG9yYWdlIGRyaXZlci4uLg0K
WyAgICAyLjA5Njc4OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZl
ciB1c2Itc3RvcmFnZQ0KWyAgICAyLjA5Njc5OV0gVVNCIE1hc3MgU3RvcmFnZSBzdXBwb3J0
IHJlZ2lzdGVyZWQuDQpbICAgIDIuMDk2OTQ1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBp
bnRlcmZhY2UgZHJpdmVyIGxpYnVzdWFsDQpbICAgIDIuMDk3MjQxXSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHVzYnNlcmlhbA0KWyAgICAyLjA5NzI0NV0g
dXNic2VyaWFsOiBVU0IgU2VyaWFsIERyaXZlciBjb3JlDQpbICAgIDIuMDk3MzU4XSBVU0Ig
U2VyaWFsIHN1cHBvcnQgcmVnaXN0ZXJlZCBmb3IgY3AyMTB4DQpbICAgIDIuMDk3NDcxXSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNwMjEweA0KWyAgICAy
LjA5NzQ3Ml0gY3AyMTB4OiB2MC4wOTpTaWxpY29uIExhYnMgQ1AyMTB4IFJTMjMyIHNlcmlh
bCBhZGFwdG9yIGRyaXZlcg0KWyAgICAyLjA5NzU5MF0gVVNCIFNlcmlhbCBzdXBwb3J0IHJl
Z2lzdGVyZWQgZm9yIERlTG9ybWUgRWFydGhtYXRlIFVTQg0KWyAgICAyLjA5NzY4N10gVVNC
IFNlcmlhbCBzdXBwb3J0IHJlZ2lzdGVyZWQgZm9yIEhJRC0+Q09NIFJTMjMyIEFkYXB0ZXIN
ClsgICAgMi4wOTc3ODJdIFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBOb2tp
YSBDQS00MiBWMiBBZGFwdGVyDQpbICAgIDIuMDk3ODkxXSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIGN5cHJlc3MNClsgICAgMi4wOTc4OTNdIGN5cHJlc3Nf
bTg6IHYxLjEwOkN5cHJlc3MgVVNCIHRvIFNlcmlhbCBEcml2ZXINClsgICAgMi4wOTc5OTJd
IFVTQiBTZXJpYWwgc3VwcG9ydCByZWdpc3RlcmVkIGZvciBNb3NjaGlwIDIgcG9ydCBhZGFw
dGVyDQpbICAgIDIuMDk3OTk0XSBtb3M3NzIwOiAyLjE6TW9zY2hpcCBVU0IgU2VyaWFsIERy
aXZlcg0KWyAgICAyLjA5ODE0MV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciBtb3NjaGlwNzcyMA0KWyAgICAyLjA5ODI0NF0gVVNCIFNlcmlhbCBzdXBwb3J0
IHJlZ2lzdGVyZWQgZm9yIE1vc2NoaXAgNzg0MC83ODIwIFVTQiBTZXJpYWwgRHJpdmVyDQpb
ICAgIDIuMDk4MjQ2XSBtb3M3ODQwOiAxLjMuMjpNb3NjaGlwIDc4NDAvNzgyMCBVU0IgU2Vy
aWFsIERyaXZlcg0KWyAgICAyLjA5ODM3Ml0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciBtb3M3ODQwDQpbICAgIDIuMDk4ODE0XSBpODA0MjogUE5QOiBObyBQ
Uy8yIGNvbnRyb2xsZXIgZm91bmQuIFByb2JpbmcgcG9ydHMgZGlyZWN0bHkuDQpbICAgIDIu
MDk5NTQzXSBzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxDQpbICAg
IDIuMDk5NTU3XSBzZXJpbzogaTgwNDIgQVVYIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMg0K
WyAgICAyLjEwMDAyMl0gbW91c2VkZXY6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3Ig
YWxsIG1pY2UNClsgICAgMi4xMDA2NzddIHJ0Y19jbW9zIDAwOjA0OiBSVEMgY2FuIHdha2Ug
ZnJvbSBTNA0KWyAgICAyLjEwMTE4MF0gcnRjX2Ntb3MgMDA6MDQ6IHJ0YyBjb3JlOiByZWdp
c3RlcmVkIHJ0Y19jbW9zIGFzIHJ0YzANClsgICAgMi4xMDEyODBdIHJ0YzA6IGFsYXJtcyB1
cCB0byBvbmUgbW9udGgsIHkzaywgMTE0IGJ5dGVzIG52cmFtDQpbICAgIDIuMTAxOTYzXSBs
aXJjX2RldjogSVIgUmVtb3RlIENvbnRyb2wgZHJpdmVyIHJlZ2lzdGVyZWQsIG1ham9yIDI1
MSANClsgICAgMi4xMDE5NzZdIElSIE5FQyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVk
DQpbICAgIDIuMTAxOTc4XSBJUiBSQzUoeCkgcHJvdG9jb2wgaGFuZGxlciBpbml0aWFsaXpl
ZA0KWyAgICAyLjEwMTk4MF0gSVIgUkM2IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQN
ClsgICAgMi4xMDE5ODJdIElSIEpWQyBwcm90b2NvbCBoYW5kbGVyIGluaXRpYWxpemVkDQpb
ICAgIDIuMTAxOTgzXSBJUiBTb255IHByb3RvY29sIGhhbmRsZXIgaW5pdGlhbGl6ZWQNClsg
ICAgMi4xMDE5ODVdIElSIFJDNSAoc3RyZWFtemFwKSBwcm90b2NvbCBoYW5kbGVyIGluaXRp
YWxpemVkDQpbICAgIDIuMTAxOTg3XSBJUiBNQ0UgS2V5Ym9hcmQvbW91c2UgcHJvdG9jb2wg
aGFuZGxlciBpbml0aWFsaXplZA0KWyAgICAyLjEwMTk4OV0gSVIgTElSQyBicmlkZ2UgaGFu
ZGxlciBpbml0aWFsaXplZA0KWyAgICAyLjEwMTk5MF0gTGludXggdmlkZW8gY2FwdHVyZSBp
bnRlcmZhY2U6IHYyLjAwDQpbICAgIDIuMTAyMjE1XSBpMmMtY29yZTogZHJpdmVyIFt0dW5l
cl0gdXNpbmcgbGVnYWN5IHN1c3BlbmQgbWV0aG9kDQpbICAgIDIuMTAyMjE2XSBpMmMtY29y
ZTogZHJpdmVyIFt0dW5lcl0gdXNpbmcgbGVnYWN5IHJlc3VtZSBtZXRob2QNClsgICAgMi4x
MDI0MTBdIGkyYy1jb3JlOiBkcml2ZXIgW21zcDM0MDBdIHVzaW5nIGxlZ2FjeSBzdXNwZW5k
IG1ldGhvZA0KWyAgICAyLjEwMjQxMl0gaTJjLWNvcmU6IGRyaXZlciBbbXNwMzQwMF0gdXNp
bmcgbGVnYWN5IHJlc3VtZSBtZXRob2QNClsgICAgMi4xMDI4NzldIHVzYmNvcmU6IHJlZ2lz
dGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgcG9zZWlkb24NClsgICAgMi4xMDI5OTFdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgY3gyMzF4eA0KWyAgICAy
LjEwMzEzOF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciB1c2J2
aXNpb24NClsgICAgMi4xMDMxNDBdIFVTQlZpc2lvbiBVU0IgVmlkZW8gRGV2aWNlIERyaXZl
ciBmb3IgTGludXggOiAwLjkuMTENClsgICAgMi4xMDM0NTNdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgcHZydXNiMg0KWyAgICAyLjEwMzQ1NF0gcHZydXNi
MjogVjRMIGluLXRyZWUgdmVyc2lvbjpIYXVwcGF1Z2UgV2luVFYtUFZSLVVTQjIgTVBFRzIg
RW5jb2Rlci9UdW5lcg0KWyAgICAyLjEwMzQ1Nl0gcHZydXNiMjogRGVidWcgbWFzayBpcyAz
MSAoMHgxZikNClsgICAgMi4xMDM1ODZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgdG02MDAwDQpbICAgIDIuMTAzNjk4XSB1c2Jjb3JlOiByZWdpc3RlcmVk
IG5ldyBpbnRlcmZhY2UgZHJpdmVyIHpyMzY0eHgNClsgICAgMi4xMDM4MzBdIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc3Rrd2ViY2FtDQpbICAgIDIuMTAz
OTQwXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuOWMxMDIN
ClsgICAgMi4xMDQwNzFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgZXQ2MXgyNTENClsgICAgMi4xMDQxODldIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu
dGVyZmFjZSBkcml2ZXIgUGhpbGlwcyB3ZWJjYW0NClsgICAgMi4xMDQxOTFdIGdzcGNhX21h
aW46IHYyLjE0LjAgcmVnaXN0ZXJlZA0KWyAgICAyLjEwNDMwN10gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBiZW5xDQpbICAgIDIuMTA0NDMyXSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNvbmV4DQpbICAgIDIuMTA0NTQw
XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGNwaWExDQpbICAg
IDIuMTA0NjQ5XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGV0
b21zDQpbICAgIDIuMTA0NzU3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIGZpbmVwaXgNClsgICAgMi4xMDQ4NzRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3
IGludGVyZmFjZSBkcml2ZXIgamVpbGluag0KWyAgICAyLjEwNDk4NV0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBraW5lY3QNClsgICAgMi4xMDUxMjJdIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIga29uaWNhDQpbICAgIDIu
MTA1MjI4XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIG1hcnMN
ClsgICAgMi4xMDUzNTVdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2
ZXIgbXI5NzMxMGENClsgICAgMi4xMDU1MTNdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGlu
dGVyZmFjZSBkcml2ZXIgbnc4MHgNClsgICAgMi4xMDU2NDddIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgb3Y1MTkNClsgICAgMi4xMDU3NTddIHVzYmNvcmU6
IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgb3Y1MzQNClsgICAgMi4xMDU4Njdd
IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgb3Y1MzRfOQ0KWyAg
ICAyLjEwNTk5NF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBw
YWMyMDcNClsgICAgMi4xMDYxMjVdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgcGFjNzMwMg0KWyAgICAyLjEwNjI1OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBu
ZXcgaW50ZXJmYWNlIGRyaXZlciBwYWM3MzExDQpbICAgIDIuMTA2MzY0XSB1c2Jjb3JlOiBy
ZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNlNDAxDQpbICAgIDIuMTA2NDcwXSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuOWMyMDI4DQpbICAg
IDIuMTA2NTk0XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNu
OWMyMHgNClsgICAgMi4xMDY3MTJdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFj
ZSBkcml2ZXIgc29uaXhiDQpbICAgIDIuMTA2ODMxXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIHNvbml4ag0KWyAgICAyLjEwNjk0OV0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzcGNhNTAwDQpbICAgIDIuMTA3MDgxXSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNwY2E1MDENClsgICAg
Mi4xMDcyMTFdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc3Bj
YTUwNQ0KWyAgICAyLjEwNzMyNl0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciBzcGNhNTA2DQpbICAgIDIuMTA3NDMyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5l
dyBpbnRlcmZhY2UgZHJpdmVyIHNwY2E1MDgNClsgICAgMi4xMDc1NTldIHVzYmNvcmU6IHJl
Z2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc3BjYTU2MQ0KWyAgICAyLjEwNzY3MF0g
dXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzcGNhMTUyOA0KWyAg
ICAyLjEwNzc3OF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBz
cTkwNQ0KWyAgICAyLjEwNzkwNF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNl
IGRyaXZlciBzcTkwNWMNClsgICAgMi4xMDgwMTRdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3
IGludGVyZmFjZSBkcml2ZXIgc3E5MzB4DQpbICAgIDIuMTA4MTk2XSB1c2Jjb3JlOiByZWdp
c3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHN1bnBsdXMNClsgICAgMi4xMDgzMDldIHVz
YmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc3RrMDE0DQpbICAgIDIu
MTA4NDI3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHN0djA2
ODANClsgICAgMi4xMDg1MzVdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBk
cml2ZXIgdDYxMw0KWyAgICAyLjEwODY0NV0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50
ZXJmYWNlIGRyaXZlciB0djg1MzINClsgICAgMi4xMDg3NzJdIHVzYmNvcmU6IHJlZ2lzdGVy
ZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgdmMwMzJ4DQpbICAgIDIuMTA4ODc5XSB1c2Jjb3Jl
OiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHZpY2FtDQpbICAgIDIuMTA4OTky
XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHhpcmxpbmstY2l0
DQpbICAgIDIuMTA5MTQ1XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJp
dmVyIHpjM3h4DQpbICAgIDIuMTA5MjY3XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRl
cmZhY2UgZHJpdmVyIEFMaSBtNTYwMg0KWyAgICAyLjEwOTM4OF0gdXNiY29yZTogcmVnaXN0
ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBTVFYwNnh4DQpbICAgIDIuMTA5NTAxXSB1c2Jj
b3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGdzcGNhX2dsODYwDQpbICAg
IDIuMTA5NjYzXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIGhk
cHZyDQpbICAgIDIuMTA5Nzc2XSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2Ug
ZHJpdmVyIHMyMjU1DQpbICAgIDIuMTA5OTAyXSB1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBp
bnRlcmZhY2UgZHJpdmVyIHV2Y3ZpZGVvDQpbICAgIDIuMTA5OTAzXSBVU0IgVmlkZW8gQ2xh
c3MgZHJpdmVyICgxLjEuMSkNClsgICAgMi4xMTAxMTJdIGY3MTg4MmZnOiBGb3VuZCBmNzE4
ODllZCBjaGlwIGF0IDB4NjAwLCByZXZpc2lvbiAxNg0KWyAgICAyLjExMDQ2NF0gZjcxODgy
ZmcgZjcxODgyZmcuMTUzNjogRmFuOiAxIGlzIGluIGR1dHktY3ljbGUgbW9kZQ0KWyAgICAy
LjExMDUxMl0gZjcxODgyZmcgZjcxODgyZmcuMTUzNjogRmFuOiAyIGlzIGluIGR1dHktY3lj
bGUgbW9kZQ0KWyAgICAyLjExMDU1NF0gZjcxODgyZmcgZjcxODgyZmcuMTUzNjogRmFuOiAz
IGlzIGluIGR1dHktY3ljbGUgbW9kZQ0KWyAgICAyLjExMTc5Ml0gZjcxODA4ZV93ZHQ6IFVu
cmVjb2duaXplZCBGaW50ZWsgZGV2aWNlOiAwOTA5DQpbICAgIDIuMTExNzk4XSBTUDUxMDAg
VENPIHRpbWVyOiBTUDUxMDAgVENPIFdhdGNoRG9nIFRpbWVyIERyaXZlciB2MC4wMQ0KWyAg
ICAyLjExMjA5N10gU1A1MTAwIFRDTyB0aW1lcjogbW1pbyBhZGRyZXNzIDB4YjhmZTAwIGFs
cmVhZHkgaW4gdXNlDQpbICAgIDIuMTEyMTA3XSB3ZHQ6IFhlbiBXYXRjaERvZyBUaW1lciBE
cml2ZXIgdjAuMDENClsgICAgMi4xMTI0ODddIHdkdDogaW5pdGlhbGl6ZWQgKHRpbWVvdXQ9
NjBzLCBub3dheW91dD0wKQ0KWyAgICAyLjExMzEyOV0gZGV2aWNlLW1hcHBlcjogaW9jdGw6
IDQuMjIuMC1pb2N0bCAoMjAxMS0xMC0xOSkgaW5pdGlhbGlzZWQ6IGRtLWRldmVsQHJlZGhh
dC5jb20NClsgICAgMi4xMTM0ODZdIEVGSSBWYXJpYWJsZXMgRmFjaWxpdHkgdjAuMDggMjAw
NC1NYXktMTcNClsgICAgMi4xMTYwOTZdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgdXNiaGlkDQpbICAgIDIuMTE2MDk4XSB1c2JoaWQ6IFVTQiBISUQgY29y
ZSBkcml2ZXINClsgICAgMi4xMjA5NDBdIHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVy
ZmFjZSBkcml2ZXIgc25kLXVzYi1hdWRpbw0KWyAgICAyLjEyMTA5Ml0gdXNiY29yZTogcmVn
aXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdWExMDENClsgICAgMi4xMjEyMDhd
IHVzYmNvcmU6IHJlZ2lzdGVyZWQgbmV3IGludGVyZmFjZSBkcml2ZXIgc25kLXVzYi11c3gy
eQ0KWyAgICAyLjEyMTMzOF0gdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgaW50ZXJmYWNlIGRy
aXZlciBzbmQtdXNiLXVzMTIybA0KWyAgICAyLjEyMTQ1NF0gdXNiY29yZTogcmVnaXN0ZXJl
ZCBuZXcgaW50ZXJmYWNlIGRyaXZlciBzbmQtdXNiLWNhaWFxDQpbICAgIDIuMTIxNTY5XSB1
c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBpbnRlcmZhY2UgZHJpdmVyIHNuZC11c2ItNmZpcmUN
ClsgICAgMi4xMjE1NzFdIEFMU0EgZGV2aWNlIGxpc3Q6DQpbICAgIDIuMTIxNTcyXSAgIE5v
IHNvdW5kY2FyZHMgZm91bmQuDQpbICAgIDIuMTIxNjM2XSBOZXRmaWx0ZXIgbWVzc2FnZXMg
dmlhIE5FVExJTksgdjAuMzAuDQpbICAgIDIuMTIxNjk3XSBuZl9jb25udHJhY2sgdmVyc2lv
biAwLjUuMCAoNzMxOSBidWNrZXRzLCAyOTI3NiBtYXgpDQpbICAgIDIuMTIyNDcwXSBjdG5l
dGxpbmsgdjAuOTM6IHJlZ2lzdGVyaW5nIHdpdGggbmZuZXRsaW5rLg0KWyAgICAyLjEyMzE4
NV0geHRfdGltZToga2VybmVsIHRpbWV6b25lIGlzIC0wMDAwDQpbICAgIDIuMTIzMjAxXSBp
cF9zZXQ6IHByb3RvY29sIDYNClsgICAgMi4xMjMyNTNdIElQVlM6IFJlZ2lzdGVyZWQgcHJv
dG9jb2xzICgpDQpbICAgIDIuMTIzMjc4XSBJUFZTOiBDb25uZWN0aW9uIGhhc2ggdGFibGUg
Y29uZmlndXJlZCAoc2l6ZT00MDk2LCBtZW1vcnk9NjRLYnl0ZXMpDQpbICAgIDIuMTIzNTgz
XSBJUFZTOiBDcmVhdGluZyBuZXRucyBzaXplPTE5MTIgaWQ9MA0KWyAgICAyLjEyMzU5MF0g
SVBWUzogaXB2cyBsb2FkZWQuDQpbICAgIDIuMTI1NTQyXSBpcF90YWJsZXM6IChDKSAyMDAw
LTIwMDYgTmV0ZmlsdGVyIENvcmUgVGVhbQ0KWyAgICAyLjEyNTY2OF0gVENQIGN1YmljIHJl
Z2lzdGVyZWQNClsgICAgMi4xMjU2NzFdIE5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1p
bHkgMTcNClsgICAgMi4xMjU3OTJdIEJyaWRnZSBmaXJld2FsbGluZyByZWdpc3RlcmVkDQpb
ICAgIDIuMTI1ODA2XSBFYnRhYmxlcyB2Mi4wIHJlZ2lzdGVyZWQNClsgICAgMi4xMjU4NTBd
IFJlZ2lzdGVyaW5nIHRoZSBkbnNfcmVzb2x2ZXIga2V5IHR5cGUNClsgICAgMi4xMjY1Mzdd
IHJlZ2lzdGVyZWQgdGFza3N0YXRzIHZlcnNpb24gMQ0KWyAgICAyLjEyODQ3MV0gICBNYWdp
YyBudW1iZXI6IDEyOjUxNTo0MzANClsgICAgMi4xMzkxNDRdIGh1YiA2LTA6MS4wOiBzdGF0
ZSA3IHBvcnRzIDIgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMi4xOTUxNThdIGh1YiA3LTA6
MS4wOiBzdGF0ZSA3IHBvcnRzIDQgY2hnIDAwMDAgZXZ0IDAwMDANClsgICAgMy41NTYxMzVd
IGNvbnNvbGUgW25ldGNvbjBdIGVuYWJsZWQNClsgICAgMy41NjAxMTRdIG5ldGNvbnNvbGU6
IG5ldHdvcmsgbG9nZ2luZyBzdGFydGVkDQpbICAgIDMuNTY1MTgzXSBGcmVlaW5nIHVudXNl
ZCBrZXJuZWwgbWVtb3J5OiA2NDRrIGZyZWVkDQpbICAgIDMuNTY2MDU0XSBXcml0ZSBwcm90
ZWN0aW5nIHRoZSBrZXJuZWwgcmVhZC1vbmx5IGRhdGE6IDE0MzM2aw0KWyAgICAzLjU4MjU4
MV0gRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTEwOGsgZnJlZWQNClsgICAgMy41
ODc4MTldIEZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE3MmsgZnJlZWQNClsgICAg
NC4zNzU2NzldIEVYVDQtZnMgKGRtLTApOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRl
cmVkIGRhdGEgbW9kZS4gT3B0czogKG51bGwpDQpbICAgIDUuNzM1NzE3XSB1ZGV2WzE5Mjhd
OiBzdGFydGluZyB2ZXJzaW9uIDE2NA0KWyAgICA2LjYxOTUwMl0gYXRhMS4wMDogY29uZmln
dXJlZCBmb3IgVURNQS8xMzMNClsgICAgNi42MjA0ODZdIGF0YTE6IEVIIGNvbXBsZXRlDQpb
ICAgIDYuOTg5NDExXSBhdGExLjAwOiBjb25maWd1cmVkIGZvciBVRE1BLzEzMw0KWyAgICA2
Ljk4OTQxNl0gYXRhMTogRUggY29tcGxldGUNClsgICAgNy41NDQzNTVdIEVYVDQtZnMgKGRt
LTApOiByZS1tb3VudGVkLiBPcHRzOiAobnVsbCkNClsgICAgNy43NTAyMjhdIEVYVDQtZnMg
KGRtLTApOiByZS1tb3VudGVkLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8N
ClsgICAxMy42NDYzODNdIEFkZGluZyAyMDk3MTQ4ayBzd2FwIG9uIC9kZXYvbWFwcGVyL3Nl
cnZlZXJzdGVydGplLXN3YXAuICBQcmlvcml0eTotMSBleHRlbnRzOjEgYWNyb3NzOjIwOTcx
NDhrIA0KWyAgIDE0LjY4OTk5NF0gRVhUNC1mcyAoc2RhMSk6IG1vdW50ZWQgZmlsZXN5c3Rl
bSB3aXRoIG9yZGVyZWQgZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91
bnQtcm8NClsgICAxNS45MjM2NTFdIHI4MTY5IDAwMDA6MDg6MDAuMDogZXRoMTogbGluayBk
b3duDQpbICAgMTUuOTI0NjU5XSByODE2OSAwMDAwOjA4OjAwLjA6IGV0aDE6IGxpbmsgZG93
bg0KWyAgIDE2LjExNDkwNV0gcjgxNjkgMDAwMDowOTowMC4wOiBldGgwOiBsaW5rIGRvd24N
ClsgICAxNi4xMTU5NDJdIHI4MTY5IDAwMDA6MDk6MDAuMDogZXRoMDogbGluayBkb3duDQpb
ICAgMTcuNjQyNTA0XSByODE2OSAwMDAwOjA4OjAwLjA6IGV0aDE6IGxpbmsgdXANClsgICAx
OC4wMjI0MzZdIHI4MTY5IDAwMDA6MDk6MDAuMDogZXRoMDogbGluayB1cA0KWyAgIDI0LjA4
MzMwNF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4x
NTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MTgyNTAgRFBUPTUzIExFTj00NyANClsgICAy
NC4wODMzMjZdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9
ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgw
MCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTE4MjUwIERQVD01MyBMRU49NDcgDQpb
ICAgMjQuMTE2NTQ2XSBGVzogaXBtYXNxLCBGb3J3YXJkIC4uIEVvQzogSU49ZXRoMSBPVVQ9
ZXRoMCBNQUM9NDA6NjE6ODY6ZjQ6Njc6ZDg6MDA6MTM6ZTg6Yjg6MDM6N2Y6MDg6MDAgU1JD
PTE3Mi4xNi4xLjIwIERTVD02NC40LjM0LjE5MSBMRU49NDAgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD0xMjcgSUQ9MTU2MTggREYgUFJPVE89VENQIFNQVD00OTE5NCBEUFQ9MTg2MyBXSU5E
T1c9MCBSRVM9MHgwMCBBQ0sgUlNUIFVSR1A9MCANClsgICAyNC4xMTkwMjJdIEZXOiBpcG1h
c3EsIEZvcndhcmQgLi4gRW9DOiBJTj1ldGgxIE9VVD1ldGgwIE1BQz00MDo2MTo4NjpmNDo2
NzpkODowMDoxMzplODpiODowMzo3ZjowODowMCBTUkM9MTcyLjE2LjEuMjAgRFNUPTY0LjQu
NDQuNzIgTEVOPTQ1IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9MTI3IElEPTE1NjE5IERGIFBS
T1RPPVRDUCBTUFQ9NTIwNTkgRFBUPTE4NjMgV0lORE9XPTY1IFJFUz0weDAwIEFDSyBQU0gg
RklOIFVSR1A9MCANClsgICAyNC40OTcwMjNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6
IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3
IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzYgREYgUFJPVE89VURQIFNQVD00
NjExMiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5NzEyNl0gRlc6IGlwbWFzcSwgT3V0cHV0
IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIw
MSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3NyBERiBQUk9UTz1V
RFAgU1BUPTM4MTczIERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk3MTczXSBGVzogaXBtYXNx
LCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODgu
MTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc3IERG
IFBST1RPPVVEUCBTUFQ9NDI0NjIgRFBUPTUzIExFTj00NyANClsgICAyNC40OTcyMTldIEZX
OiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1
IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9
NTIxNzcgREYgUFJPVE89VURQIFNQVD01MjQ5OCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5
NzI2M10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4x
NTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD02NCBJRD01MjE3NyBERiBQUk9UTz1VRFAgU1BUPTQxOTgxIERQVD01MyBMRU49NDcgDQpb
ICAgMjQuNDk3MzA3XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAg
U1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVD
PTB4MDAgVFRMPTY0IElEPTUyMTc3IERGIFBST1RPPVVEUCBTUFQ9NDQ5NTAgRFBUPTUzIExF
Tj00NyANClsgICAyNC40OTczNTZdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBP
VVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0w
eDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzcgREYgUFJPVE89VURQIFNQVD01Nzc0OSBE
UFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5NzQwMl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVv
QzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49
NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3NyBERiBQUk9UTz1VRFAgU1BU
PTQwNzQ3IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk3NDgwXSBGVzogaXBtYXNxLCBPdXRw
dXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEu
MjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc3IERGIFBST1RP
PVVEUCBTUFQ9NTYwNDQgRFBUPTUzIExFTj00NyANClsgICAyNC40OTc1MjddIEZXOiBpcG1h
c3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04
OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzcg
REYgUFJPVE89VURQIFNQVD01NjUzMCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5NzU3MV0g
Rlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIu
MjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJ
RD01MjE3NyBERiBQUk9UTz1VRFAgU1BUPTU5NzQ2IERQVD01MyBMRU49NDcgDQpbICAgMjQu
NDk3NjE1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4
LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAg
VFRMPTY0IElEPTUyMTc3IERGIFBST1RPPVVEUCBTUFQ9NTg0MjIgRFBUPTUzIExFTj00NyAN
ClsgICAyNC40OTc2NzFdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRo
MCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBS
RUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzcgREYgUFJPVE89VURQIFNQVD0zNTE5MiBEUFQ9NTMg
TEVOPTQ3IA0KWyAgIDI0LjQ5NzcxM10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49
IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9T
PTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3NyBERiBQUk9UTz1VRFAgU1BUPTUyNjgx
IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk3NzUzXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4g
RW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExF
Tj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc3IERGIFBST1RPPVVEUCBT
UFQ9MzQ2NjEgRFBUPTUzIExFTj00NyANClsgICAyNC40OTc3OTNdIEZXOiBpcG1hc3EsIE91
dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTku
MS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzcgREYgUFJP
VE89VURQIFNQVD00MzQwNiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5ODAwM10gRlc6IGlw
bWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNU
PTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3
NyBERiBQUk9UTz1VRFAgU1BUPTQwMTg3IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk4MDQz
XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43
Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0
IElEPTUyMTc3IERGIFBST1RPPVVEUCBTUFQ9NTI1OTIgRFBUPTUzIExFTj00NyANClsgICAy
NC40OTgxMjNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9
ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgw
MCBUVEw9NjQgSUQ9NTIxNzggREYgUFJPVE89VURQIFNQVD00MDA3MyBEUFQ9NTMgTEVOPTQ3
IA0KWyAgIDI0LjQ5ODE2OV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1l
dGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAg
UFJFQz0weDAwIFRUTD02NCBJRD01MjE3OCBERiBQUk9UTz1VRFAgU1BUPTQ4MjMyIERQVD01
MyBMRU49NDcgDQpbICAgMjQuNDk4MjEzXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJ
Tj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBU
T1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc4IERGIFBST1RPPVVEUCBTUFQ9NTY0
MDEgRFBUPTUzIExFTj00NyANClsgICAyNC40OTgyNjRdIEZXOiBpcG1hc3EsIE91dHB1dCAu
LiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEg
TEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzggREYgUFJPVE89VURQ
IFNQVD00MjI5NSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5ODMwOF0gRlc6IGlwbWFzcSwg
T3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1
OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OCBERiBQ
Uk9UTz1VRFAgU1BUPTM3NDI4IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk4MzUzXSBGVzog
aXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBE
U1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUy
MTc4IERGIFBST1RPPVVEUCBTUFQ9Mzk3OTMgRFBUPTUzIExFTj00NyANClsgICAyNC40OTgz
OTldIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5
LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9
NjQgSUQ9NTIxNzggREYgUFJPVE89VURQIFNQVD0zOTU1MCBEUFQ9NTMgTEVOPTQ3IA0KWyAg
IDI0LjQ5ODQ0Nl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNS
Qz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0w
eDAwIFRUTD02NCBJRD01MjE3OCBERiBQUk9UTz1VRFAgU1BUPTUxMDE0IERQVD01MyBMRU49
NDcgDQpbICAgMjQuNDk4NDg2XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VU
PWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgw
MCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc4IERGIFBST1RPPVVEUCBTUFQ9MzMxMTQgRFBU
PTUzIExFTj00NyANClsgICAyNC40OTg1MjVdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6
IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3
IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzggREYgUFJPVE89VURQIFNQVD00
NjQ3MyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5ODU2NV0gRlc6IGlwbWFzcSwgT3V0cHV0
IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIw
MCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OCBERiBQUk9UTz1V
RFAgU1BUPTU0ODU3IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk4NjA2XSBGVzogaXBtYXNx
LCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODgu
MTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc4IERG
IFBST1RPPVVEUCBTUFQ9NTA1NDcgRFBUPTUzIExFTj00NyANClsgICAyNC40OTg2NDVdIEZX
OiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1
IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9
NTIxNzggREYgUFJPVE89VURQIFNQVD01NzE3MiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5
ODY4NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4x
NTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD02NCBJRD01MjE3OCBERiBQUk9UTz1VRFAgU1BUPTM1MDE4IERQVD01MyBMRU49NDcgDQpb
ICAgMjQuNDk4ODc5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAg
U1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVD
PTB4MDAgVFRMPTY0IElEPTUyMTc4IERGIFBST1RPPVVEUCBTUFQ9MzkyMzMgRFBUPTUzIExF
Tj00NyANClsgICAyNC40OTg5MjBdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBP
VVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0w
eDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzggREYgUFJPVE89VURQIFNQVD01NTU5MSBE
UFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5ODk2MF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVv
QzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49
NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OCBERiBQUk9UTz1VRFAgU1BU
PTQ5MzA5IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk4OTk5XSBGVzogaXBtYXNxLCBPdXRw
dXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEu
MjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc4IERGIFBST1RP
PVVEUCBTUFQ9NTUyOTIgRFBUPTUzIExFTj00NyANClsgICAyNC40OTkwMzldIEZXOiBpcG1h
c3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04
OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzgg
REYgUFJPVE89VURQIFNQVD01MjE3MyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5OTEyMV0g
Rlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIu
MjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJ
RD01MjE3OSBERiBQUk9UTz1VRFAgU1BUPTQwOTAxIERQVD01MyBMRU49NDcgDQpbICAgMjQu
NDk5MTY2XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4
LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAg
VFRMPTY0IElEPTUyMTc5IERGIFBST1RPPVVEUCBTUFQ9NTc0NTkgRFBUPTUzIExFTj00NyAN
ClsgICAyNC40OTkyMTFdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRo
MCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBS
RUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQIFNQVD00NDM5MCBEUFQ9NTMg
TEVOPTQ3IA0KWyAgIDI0LjQ5OTI2MF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49
IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9T
PTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OSBERiBQUk9UTz1VRFAgU1BUPTU3MTIy
IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk5MzA1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4g
RW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExF
Tj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc5IERGIFBST1RPPVVEUCBT
UFQ9MzM3MDMgRFBUPTUzIExFTj00NyANClsgICAyNC40OTkzNDldIEZXOiBpcG1hc3EsIE91
dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTku
MS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJP
VE89VURQIFNQVD01MDgzOSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5OTM5Nl0gRlc6IGlw
bWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNU
PTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3
OSBERiBQUk9UTz1VRFAgU1BUPTM3MzM5IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk5NDQx
XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43
Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0
IElEPTUyMTc5IERGIFBST1RPPVVEUCBTUFQ9NTYyODIgRFBUPTUzIExFTj00NyANClsgICAy
NC40OTk0ODVdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9
ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgw
MCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQIFNQVD0zNjk5OSBEUFQ9NTMgTEVOPTQ3
IA0KWyAgIDI0LjQ5OTUzMF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1l
dGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAg
UFJFQz0weDAwIFRUTD02NCBJRD01MjE3OSBERiBQUk9UTz1VRFAgU1BUPTQwNzQ1IERQVD01
MyBMRU49NDcgDQpbICAgMjQuNDk5NTc5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJ
Tj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBU
T1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc5IERGIFBST1RPPVVEUCBTUFQ9NTcy
NzUgRFBUPTUzIExFTj00NyANClsgICAyNC40OTk3NzJdIEZXOiBpcG1hc3EsIE91dHB1dCAu
LiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAg
TEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQ
IFNQVD02MDE2MiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjQ5OTgxMl0gRlc6IGlwbWFzcSwg
T3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1
OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OSBERiBQ
Uk9UTz1VRFAgU1BUPTQ3Njg1IERQVD01MyBMRU49NDcgDQpbICAgMjQuNDk5ODUxXSBGVzog
aXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBE
U1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUy
MTc5IERGIFBST1RPPVVEUCBTUFQ9NDQ1NDkgRFBUPTUzIExFTj00NyANClsgICAyNC40OTk4
OTBdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5
LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9
NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQIFNQVD02MDI4MCBEUFQ9NTMgTEVOPTQ3IA0KWyAg
IDI0LjQ5OTkyOV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNS
Qz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0w
eDAwIFRUTD02NCBJRD01MjE3OSBERiBQUk9UTz1VRFAgU1BUPTQ5OTY2IERQVD01MyBMRU49
NDcgDQpbICAgMjQuNDk5OTY5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VU
PWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgw
MCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTc5IERGIFBST1RPPVVEUCBTUFQ9NjA3OTUgRFBU
PTUzIExFTj00NyANClsgICAyNC41MDAwMDhdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6
IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3
IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxNzkgREYgUFJPVE89VURQIFNQVD00
MDM3OSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjUwMDA0OF0gRlc6IGlwbWFzcSwgT3V0cHV0
IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIw
MSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE3OSBERiBQUk9UTz1V
RFAgU1BUPTQxODE1IERQVD01MyBMRU49NDcgDQpbICAgMjQuNTAwMTI5XSBGVzogaXBtYXNx
LCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODgu
MTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTgwIERG
IFBST1RPPVVEUCBTUFQ9NDczMzYgRFBUPTUzIExFTj00NyANClsgICAyNC41MDAxNzRdIEZX
OiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1
IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9
NTIxODAgREYgUFJPVE89VURQIFNQVD0zNDM4NSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjUw
MDIxOF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4x
NTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRU
TD02NCBJRD01MjE4MCBERiBQUk9UTz1VRFAgU1BUPTM0MDg5IERQVD01MyBMRU49NDcgDQpb
ICAgMjQuNTAwMjYzXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAg
U1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVD
PTB4MDAgVFRMPTY0IElEPTUyMTgwIERGIFBST1RPPVVEUCBTUFQ9NTM5NTggRFBUPTUzIExF
Tj00NyANClsgICAyNC41MDAzMDddIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBP
VVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0w
eDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxODAgREYgUFJPVE89VURQIFNQVD00MTY5OCBE
UFQ9NTMgTEVOPTQ3IA0KWyAgIDI0LjUwMDM1MV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVv
QzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49
NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD01MjE4MCBERiBQUk9UTz1VRFAgU1BU
PTU0OTI1IERQVD01MyBMRU49NDcgDQpbICAgMjQuNTAwMzk1XSBGVzogaXBtYXNxLCBPdXRw
dXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEu
MjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTUyMTgwIERGIFBST1RP
PVVEUCBTUFQ9NDM1OTcgRFBUPTUzIExFTj00NyANClsgICAyNC41MDA0NDBdIEZXOiBpcG1h
c3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04
OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9NTIxODAg
REYgUFJPVE89VURQIFNQVD0zNjQ0NyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDI3LjM0OTg0M10g
c3NoZCAoNTE2Mik6IC9wcm9jLzUxNjIvb29tX2FkaiBpcyBkZXByZWNhdGVkLCBwbGVhc2Ug
dXNlIC9wcm9jLzUxNjIvb29tX3Njb3JlX2FkaiBpbnN0ZWFkLg0KWyAgIDI4LjA4MjQwOV0g
RVhUNC1mcyAoZG0tMik6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQgZGF0YSBt
b2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8NClsgICAyOC43MDU0MDVd
IEVYVDQtZnMgKGRtLTM2KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRh
IG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDI5LjI0OTEz
MV0gRVhUNC1mcyAoZG0tMzcpOiBtb3VudGVkIGZpbGVzeXN0ZW0gd2l0aCBvcmRlcmVkIGRh
dGEgbW9kZS4gT3B0czogYmFycmllcj0xLGVycm9ycz1yZW1vdW50LXJvDQpbICAgMjkuNzE1
MjA2XSBFWFQ0LWZzIChkbS0zOCk6IG1vdW50ZWQgZmlsZXN5c3RlbSB3aXRoIG9yZGVyZWQg
ZGF0YSBtb2RlLiBPcHRzOiBiYXJyaWVyPTEsZXJyb3JzPXJlbW91bnQtcm8NClsgICAzMC4z
ODg1NjFdIEVYVDQtZnMgKGRtLTM5KTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJl
ZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDMw
LjQ2ODc5NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04
OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MTE0MTggRFBUPTUzIExFTj00NyANClsg
ICAzMC40OTA3OTddIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBT
UkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9
MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTExNDE4IERQVD01MyBMRU49NDcg
DQpbICAgMzAuNzU2MTUxXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0
aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQ
UkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD02MjU1OSBEUFQ9NTMgTEVO
PTQ3IA0KWyAgIDMwLjc3OTEyM10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9V
VD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NjI1NTkgRFBUPTUz
IExFTj00NyANClsgICAzMC44MDgwMDhdIEVYVDQtZnMgKGRtLTQwKTogbW91bnRlZCBmaWxl
c3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1vZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9
cmVtb3VudC1ybw0KWyAgIDMwLjgxMjc5NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzog
SU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49Njcg
VE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9Mjg1MjEg
RFBUPTUzIExFTj00NyANClsgICAzMC44MTI4MTFdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBF
b0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVO
PTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTI4
NTIxIERQVD01MyBMRU49NDcgDQpbICAgMzAuODI1NjE5XSBGVzogaXBtYXNxLCBPdXRwdXQg
Li4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAw
IExFTj02MCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQ
VD02MTQ4MCBEUFQ9NTMgTEVOPTQwIA0KWyAgIDMwLjgyNTYzNl0gRlc6IGlwbWFzcSwgT3V0
cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4x
LjIwMSBMRU49NjAgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVE
UCBTUFQ9NjE0ODAgRFBUPTUzIExFTj00MCANClsgICAzMC44MjYzNDNdIEZXOiBpcG1hc3Es
IE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4x
NTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9U
Tz1VRFAgU1BUPTI4NjUxIERQVD01MyBMRU49NDcgDQpbICAgMzAuODI2MzU5XSBGVzogaXBt
YXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9
ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYg
UFJPVE89VURQIFNQVD0yODY1MSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMwLjg0MTA4NV0gRlc6
IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUg
RFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0w
IERGIFBST1RPPVVEUCBTUFQ9MjQ0ODYgRFBUPTUzIExFTj00NyANClsgICAzMC44NDExMDFd
IEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5Ljcy
LjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQg
SUQ9MCBERiBQUk9UTz1VRFAgU1BUPTI0NDg2IERQVD01MyBMRU49NDcgDQpbICAgMzAuODU2
NTIxXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1
OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRM
PTY0IElEPTAgREYgUFJPVE89VURQIFNQVD01ODk4NCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMw
Ljg1NjUzOF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04
OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NTg5ODQgRFBUPTUzIExFTj00NyANClsg
ICAzMC44NzIwOTJdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBT
UkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9
MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTUyMzQ4IERQVD01MyBMRU49NDcg
DQpbICAgMzAuODcyMTE4XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0
aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQ
UkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD01MjM0OCBEUFQ9NTMgTEVO
PTQ3IA0KWyAgIDMwLjg4NzcxNl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9V
VD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NjE2MDkgRFBUPTUz
IExFTj00NyANClsgICAzMC44ODc3MzNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElO
PSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRP
Uz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTYxNjA5IERQ
VD01MyBMRU49NDcgDQpbICAgMzAuOTAzMzc3XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9D
OiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02
NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0yMjQ0
OCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMwLjkwMzM5NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4u
IEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBM
RU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9
MjI0NDggRFBUPTUzIExFTj00NyANClsgICAzMC45MjAxNDJdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTE1Nzc0IERQVD01MyBMRU49NDcgDQpbICAgMzAuOTIwMTU4XSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0xNTc3NCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMwLjkzNDQ1MF0gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9MzM4ODAgRFBUPTUzIExFTj00NyANClsgICAzMC45MzQ0NjZdIEZXOiBp
cG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERT
VD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBE
RiBQUk9UTz1VRFAgU1BUPTMzODgwIERQVD01MyBMRU49NDcgDQpbICAgMzAuOTUwNDY4XSBG
VzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4y
NSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElE
PTAgREYgUFJPVE89VURQIFNQVD02MzA3MiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMwLjk1MDQ4
NV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTku
NzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02
NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NjMwNzIgRFBUPTUzIExFTj00NyANClsgICAzMC45
NjYzMDhdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODgu
MTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBU
VEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTEzMDYxIERQVD01MyBMRU49NDcgDQpbICAg
MzAuOTY2MzI1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JD
PTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4
MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0xMzA2MSBEUFQ9NTMgTEVOPTQ3IA0K
WyAgIDMwLjk4MTk2Nl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgw
IFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJF
Qz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NDc4MzYgRFBUPTUzIExFTj00
NyANClsgICAzMC45ODE5ODNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9
ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAw
IFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTQ3ODM2IERQVD01MyBM
RU49NDcgDQpbICAgMzAuOTk3MzQxXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0g
T1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9
MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD01NTE5NCBEUFQ9
NTMgTEVOPTQ3IA0KWyAgIDMwLjk5NzM1N10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzog
SU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49Njcg
VE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NTUxOTQg
RFBUPTUzIExFTj00NyANClsgICAzMS4wMTM0MzhdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBF
b0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVO
PTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTUw
NDc3IERQVD01MyBMRU49NDcgDQpbICAgMzEuMDEzNDU1XSBGVzogaXBtYXNxLCBPdXRwdXQg
Li4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAx
IExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQ
VD01MDQ3NyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjAyOTgxMV0gRlc6IGlwbWFzcSwgT3V0
cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4x
LjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVE
UCBTUFQ9MTM5MjggRFBUPTUzIExFTj00NyANClsgICAzMS4wMjk4MjhdIEZXOiBpcG1hc3Es
IE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4x
NTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9U
Tz1VRFAgU1BUPTEzOTI4IERQVD01MyBMRU49NDcgDQpbICAgMzEuMDQ0NjAwXSBGVzogaXBt
YXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9
ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYg
UFJPVE89VURQIFNQVD00MTIwMSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjA0NDYxNl0gRlc6
IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUg
RFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0w
IERGIFBST1RPPVVEUCBTUFQ9NDEyMDEgRFBUPTUzIExFTj00NyANClsgICAzMS4wNjAwMDdd
IEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5Ljcy
LjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQg
SUQ9MCBERiBQUk9UTz1VRFAgU1BUPTY0NzgzIERQVD01MyBMRU49NDcgDQpbICAgMzEuMDYw
MDI1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1
OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRM
PTY0IElEPTAgREYgUFJPVE89VURQIFNQVD02NDc4MyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMx
LjA3NTUzNl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04
OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NDU3MjMgRFBUPTUzIExFTj00NyANClsg
ICAzMS4wNzU1NTJdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBT
UkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9
MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTQ1NzIzIERQVD01MyBMRU49NDcg
DQpbICAgMzEuMDkxMDQxXSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0
aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQ
UkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0yNjgxOSBEUFQ9NTMgTEVO
PTQ3IA0KWyAgIDMxLjA5MTEwMV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9V
VD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MjY4MTkgRFBUPTUz
IExFTj00NyANClsgICAzMS4xMDY4NzldIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElO
PSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRP
Uz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTU5MTggRFBU
PTUzIExFTj00NyANClsgICAzMS4xMDY4OTZdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6
IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3
IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTU5MTgg
RFBUPTUzIExFTj00NyANClsgICAzMS4xMjM4NjJdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBF
b0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVO
PTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTg0
ODYgRFBUPTUzIExFTj00NyANClsgICAzMS4xMjM4ODBdIEZXOiBpcG1hc3EsIE91dHB1dCAu
LiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEg
TEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BU
PTg0ODYgRFBUPTUzIExFTj00NyANClsgICAzMS4xMzgyOTNdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTMwMzI1IERQVD01MyBMRU49NDcgDQpbICAgMzEuMTM4MzEyXSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0zMDMyNSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjE1MzUxMV0gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9NTAwMDQgRFBUPTUzIExFTj00NyANClsgICAzMS4xNTM1MjddIEZXOiBp
cG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERT
VD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBE
RiBQUk9UTz1VRFAgU1BUPTUwMDA0IERQVD01MyBMRU49NDcgDQpbICAgMzEuMTY5MDAwXSBG
VzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4y
NSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElE
PTAgREYgUFJPVE89VURQIFNQVD0zOTQyNSBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjE2OTAx
N10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTku
NzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02
NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9Mzk0MjUgRFBUPTUzIExFTj00NyANClsgICAzMS4x
ODQ4NzddIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODgu
MTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBU
VEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTg4MzggRFBUPTUzIExFTj00NyANClsgICAz
MS4xODQ5MzRdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9
ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgw
MCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTg4MzggRFBUPTUzIExFTj00NyANClsg
ICAzMS4yMDAzNDNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBT
UkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9
MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTQyODMwIERQVD01MyBMRU49NDcg
DQpbICAgMzEuMjAwMzU5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0
aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQ
UkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD00MjgzMCBEUFQ9NTMgTEVO
PTQ3IA0KWyAgIDMxLjIxNjAxOV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9V
VD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4
MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MjU5MTcgRFBUPTUz
IExFTj00NyANClsgICAzMS4yMTYwNDZdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElO
PSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRP
Uz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTI1OTE3IERQ
VD01MyBMRU49NDcgDQpbICAgMzEuMjMyMDk0XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9D
OiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02
NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0xMTkx
MCBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDMxLjIzMjExMl0gRlc6IGlwbWFzcSwgT3V0cHV0IC4u
IEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBM
RU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9
MTE5MTAgRFBUPTUzIExFTj00NyANClsgICAzMS4zMDQ0MDZdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTc1IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTE0NjE4IERQVD01MyBMRU49NTUgDQpbICAgMzEuMzA0NDIzXSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj03NSBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0xNDYxOCBEUFQ9NTMgTEVOPTU1IA0KWyAgIDMxLjUyNTg0M10gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NjIgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9NTcwNjYgRFBUPTUzIExFTj00MiANClsgICAzMS41MjU4NTldIEZXOiBp
cG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERT
VD04OC4xNTkuMS4yMDEgTEVOPTYyIFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBE
RiBQUk9UTz1VRFAgU1BUPTU3MDY2IERQVD01MyBMRU49NDIgDQpbICAgMzMuMzcwMzc3XSBF
WFQ0LWZzIChzZGIxKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJlZCBkYXRhIG1v
ZGUuIE9wdHM6IGJhcnJpZXI9MSxlcnJvcnM9cmVtb3VudC1ybw0KWyAgIDM4LjcwODExMF0g
Rlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIu
MjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJ
RD0wIERGIFBST1RPPVVEUCBTUFQ9NTkwODYgRFBUPTUzIExFTj00NyANClsgICAzOC43NDA3
MDVdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5
LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9
NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTU5MDg2IERQVD01MyBMRU49NDcgDQpbICAgNDAu
Njk5ODM5XSBGVzogaXBtYXNxLCBGb3J3YXJkIC4uIEVvQzogSU49ZXRoMSBPVVQ9ZXRoMCBN
QUM9NDA6NjE6ODY6ZjQ6Njc6ZDg6MDA6MTM6ZTg6Yjg6MDM6N2Y6MDg6MDAgU1JDPTE3Mi4x
Ni4xLjIwIERTVD02NC40LjQ0LjcyIExFTj00MCBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTEy
NyBJRD0xNTY2OSBERiBQUk9UTz1UQ1AgU1BUPTUyMDU5IERQVD0xODYzIFdJTkRPVz0wIFJF
Uz0weDAwIEFDSyBSU1QgVVJHUD0wIA0KWyAgIDQwLjg0MzAxNl0gWEVOQlVTOiBVbmFibGUg
dG8gcmVhZCBjcHUgc3RhdGUNClsgICA0MC44NTk3NjZdIFhFTkJVUzogVW5hYmxlIHRvIHJl
YWQgY3B1IHN0YXRlDQpbICAgNDAuODU5OTQzXSBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNw
dSBzdGF0ZQ0KWyAgIDQwLjg2MDE2NV0gWEVOQlVTOiBVbmFibGUgdG8gcmVhZCBjcHUgc3Rh
dGUNClsgICA0MC44NjAzMjRdIFhFTkJVUzogVW5hYmxlIHRvIHJlYWQgY3B1IHN0YXRlDQpb
ICAgNDAuODYwNTIxXSBYRU5CVVM6IFVuYWJsZSB0byByZWFkIGNwdSBzdGF0ZQ0KWyAgIDQ3
LjI1NTc2NF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04
OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NzAgVE9TPTB4MDAgUFJFQz0weDAw
IFRUTD02NCBJRD05Mzk5IERGIFBST1RPPVVEUCBTUFQ9NTYzNzAgRFBUPTUzIExFTj01MCAN
ClsgICA0Ny4yODQzOTJdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRo
MCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTcwIFRPUz0weDAwIFBS
RUM9MHgwMCBUVEw9NjQgSUQ9OTQyOCBERiBQUk9UTz1VRFAgU1BUPTM4ODQ4IERQVD01MyBM
RU49NTAgDQpbICAgNDcuMzE1MzE3XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0g
T1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj03MCBUT1M9
MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTk0NTkgREYgUFJPVE89VURQIFNQVD01NzIzMCBE
UFQ9NTMgTEVOPTUwIA0KWyAgIDQ3LjM0NjAwMF0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVv
QzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49
NzAgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD05NDg5IERGIFBST1RPPVVEUCBTUFQ9
Mzc5MTkgRFBUPTUzIExFTj01MCANClsgICA2MC44OTEzMzRdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTI0OTA3IERQVD01MyBMRU49NDcgDQpbICAgNjAuOTE5ODUzXSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0yNDkwNyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDYwLjk0OTY0Ml0gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NjAgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9MzYwMTEgRFBUPTUzIExFTj00MCANClsgICA2MC45NzkzNzZdIEZXOiBp
cG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERT
VD04OC4xNTkuMS4yMDEgTEVOPTYwIFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBE
RiBQUk9UTz1VRFAgU1BUPTM2MDExIERQVD01MyBMRU49NDAgDQpbICAgNjEuMDA5MTkwXSBG
VzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4y
NSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElE
PTAgREYgUFJPVE89VURQIFNQVD00MjgzMiBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDYxLjAzODk4
M10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTku
NzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49NjcgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02
NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NDI4MzIgRFBUPTUzIExFTj00NyANClsgICA2MS4w
NzQzNzFdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODgu
MTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBU
VEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTIzNDYxIERQVD01MyBMRU49NDcgDQpbICAg
NjEuMTAzNzU1XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JD
PTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4
MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0yMzQ2MSBEUFQ9NTMgTEVOPTQ3IA0K
WyAgIDYxLjEzNzA0MV0gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgw
IFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMCBMRU49NjcgVE9TPTB4MDAgUFJF
Qz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9NTY1MzIgRFBUPTUzIExFTj00
NyANClsgICA2MS4xNjY1NjNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9
ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTY3IFRPUz0weDAw
IFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTU2NTMyIERQVD01MyBM
RU49NDcgDQpbICAgNjEuMTk5NzQ5XSBGVzogaXBtYXNxLCBPdXRwdXQgLi4gRW9DOiBJTj0g
T1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5LjEuMjAwIExFTj02NyBUT1M9
MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89VURQIFNQVD0xNzIxMyBEUFQ9
NTMgTEVOPTQ3IA0KWyAgIDYxLjIyOTkzN10gRlc6IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzog
SU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4LjE1OS4xLjIwMSBMRU49Njcg
VE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBST1RPPVVEUCBTUFQ9MTcyMTMg
RFBUPTUzIExFTj00NyANClsgICA2MS4yNzc2ODNdIEZXOiBpcG1hc3EsIE91dHB1dCAuLiBF
b0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDAgTEVO
PTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BUPTgy
MzEgRFBUPTUzIExFTj00NyANClsgICA2MS4zMDYyMjldIEZXOiBpcG1hc3EsIE91dHB1dCAu
LiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4yMDEg
TEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAgU1BU
PTgyMzEgRFBUPTUzIExFTj00NyANClsgICA2MS4zNDcxMTVdIEZXOiBpcG1hc3EsIE91dHB1
dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5LjcyLjI1IERTVD04OC4xNTkuMS4y
MDAgTEVOPTY3IFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQgSUQ9MCBERiBQUk9UTz1VRFAg
U1BUPTEyMzk3IERQVD01MyBMRU49NDcgDQpbICAgNjEuMzc2MzI0XSBGVzogaXBtYXNxLCBP
dXRwdXQgLi4gRW9DOiBJTj0gT1VUPWV0aDAgU1JDPTg4LjE1OS43Mi4yNSBEU1Q9ODguMTU5
LjEuMjAxIExFTj02NyBUT1M9MHgwMCBQUkVDPTB4MDAgVFRMPTY0IElEPTAgREYgUFJPVE89
VURQIFNQVD0xMjM5NyBEUFQ9NTMgTEVOPTQ3IA0KWyAgIDYxLjQ0ODcyOF0gRlc6IGlwbWFz
cSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNUPTg4
LjE1OS4xLjIwMCBMRU49NzUgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERGIFBS
T1RPPVVEUCBTUFQ9NjM3NiBEUFQ9NTMgTEVOPTU1IA0KWyAgIDYxLjQ3ODIyOV0gRlc6IGlw
bWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUgRFNU
PTg4LjE1OS4xLjIwMSBMRU49NzUgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0wIERG
IFBST1RPPVVEUCBTUFQ9NjM3NiBEUFQ9NTMgTEVOPTU1IA0KWyAgIDYxLjY5Njc1M10gRlc6
IGlwbWFzcSwgT3V0cHV0IC4uIEVvQzogSU49IE9VVD1ldGgwIFNSQz04OC4xNTkuNzIuMjUg
RFNUPTg4LjE1OS4xLjIwMCBMRU49NjIgVE9TPTB4MDAgUFJFQz0weDAwIFRUTD02NCBJRD0w
IERGIFBST1RPPVVEUCBTUFQ9NDQ5NjMgRFBUPTUzIExFTj00MiANClsgICA2MS43MjY2NjBd
IEZXOiBpcG1hc3EsIE91dHB1dCAuLiBFb0M6IElOPSBPVVQ9ZXRoMCBTUkM9ODguMTU5Ljcy
LjI1IERTVD04OC4xNTkuMS4yMDEgTEVOPTYyIFRPUz0weDAwIFBSRUM9MHgwMCBUVEw9NjQg
SUQ9MCBERiBQUk9UTz1VRFAgU1BUPTQ0OTYzIERQVD01MyBMRU49NDIgDQo=
------------0B61A709518B22542
Content-Type: text/plain;
 name="xm-dmesg.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment;
 filename="xm-dmesg.txt"

ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMCAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhF
TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkN
CihYRU4pIFByb2Nlc3NvciAjMSAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTog
TEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwMl0gZW5hYmxlZCkNCihYRU4pIFBy
b2Nlc3NvciAjMiAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFj
cGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj
MyAwOjEwIEFQSUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw
NV0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCAwOjEwIEFQ
SUMgdmVyc2lvbiAxNg0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNf
aWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNSAwOjEwIEFQSUMgdmVyc2lv
biAxNg0KKFhFTikgQUNQSTogSU9BUElDIChpZFsweDA2XSBhZGRyZXNzWzB4ZmVjMDAwMDBd
IGdzaV9iYXNlWzBdKQ0KKFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDYsIHZlcnNpb24gMzMs
IGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6IElPQVBJQyAoaWRb
MHgwN10gYWRkcmVzc1sweGZlYzIwMDAwXSBnc2lfYmFzZVsyNF0pDQooWEVOKSBJT0FQSUNb
MV06IGFwaWNfaWQgNywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzIwMDAwLCBHU0kgMjQt
NTUNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDAgZ2xvYmFsX2ly
cSAyIGRmbCBkZmwpDQooWEVOKSBBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAgYnVzX2lycSA5
IGdsb2JhbF9pcnEgOSBsb3cgbGV2ZWwpDQooWEVOKSBBQ1BJOiBJUlEwIHVzZWQgYnkgb3Zl
cnJpZGUuDQooWEVOKSBBQ1BJOiBJUlEyIHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBBQ1BJ
OiBJUlE5IHVzZWQgYnkgb3ZlcnJpZGUuDQooWEVOKSBFbmFibGluZyBBUElDIG1vZGU6ICBG
bGF0LiAgVXNpbmcgMiBJL08gQVBJQ3MNCihYRU4pIEFDUEk6IEhQRVQgaWQ6IDB4ODMwMCBi
YXNlOiAweGZlZDAwMDAwDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNl
IGUwMDAwMDAwIHNlZ21lbnQgMCBidXNlcyAwIC0gMjU1DQooWEVOKSBQQ0k6IE5vdCB1c2lu
ZyBNTUNPTkZJRy4NCihYRU4pIFRhYmxlIGlzIG5vdCBmb3VuZCENCihYRU4pIFVzaW5nIEFD
UEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgbWFw
cGVkIEFQSUMgdG8gZmZmZjgyYzNmZmZmZTAwMCAoZmVlMDAwMDApDQooWEVOKSBtYXBwZWQg
SU9BUElDIHRvIGZmZmY4MmMzZmZmZmQwMDAgKGZlYzAwMDAwKQ0KKFhFTikgbWFwcGVkIElP
QVBJQyB0byBmZmZmODJjM2ZmZmZjMDAwIChmZWMyMDAwMCkNCihYRU4pIElSUSBsaW1pdHM6
IDU2IEdTSSwgMTExMiBNU0kvTVNJLVgNCihYRU4pIFVzaW5nIHNjaGVkdWxlcjogU01QIENy
ZWRpdCBTY2hlZHVsZXIgKGNyZWRpdCkNCihYRU4pIERldGVjdGVkIDMyMDAuMTYwIE1IeiBw
cm9jZXNzb3IuDQooWEVOKSBJbml0aW5nIG1lbW9yeSBzaGFyaW5nLg0KKFhFTikgQU1EIEZh
bTEwaCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkDQooWEVOKSBBTUQtVmk6IEZv
dW5kIE1TSSBjYXBhYmlsaXR5IGJsb2NrIA0KKFhFTikgQU1ELVZpOiBBQ1BJIFRhYmxlOg0K
KFhFTikgQU1ELVZpOiAgU2lnbmF0dXJlIElWUlMNCihYRU4pIEFNRC1WaTogIExlbmd0aCAw
eDEwMA0KKFhFTikgQU1ELVZpOiAgUmV2aXNpb24gMHgxDQooWEVOKSBBTUQtVmk6ICBDaGVj
a1N1bSAweDY2DQooWEVOKSBBTUQtVmk6ICBPRU1fSWQgQU1EICANCihYRU4pIEFNRC1WaTog
IE9FTV9UYWJsZV9JZCBSRDg5MFMNCihYRU4pIEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDIw
MjAzMQ0KKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBBTUQgDQooWEVOKSBBTUQtVmk6ICBD
cmVhdG9yX1JldmlzaW9uIDB4MA0KKFhFTikgQU1ELVZpOiBJVlJTIEJsb2NrOg0KKFhFTikg
QU1ELVZpOiAgVHlwZSAweDEwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDNlDQooWEVOKSBB
TUQtVmk6ICBMZW5ndGggMHhkMA0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4Mg0KKFhFTikg
QU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQoo
WEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihY
RU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHgwIC0+IDB4Mg0KKFhFTikgQU1ELVZpOiBJ
VkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQt
Vmk6ICBEZXZfSWQgMHgxMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQt
Vmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4p
IEFNRC1WaTogIERldl9JZCAweGIwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVO
KSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDIN
CihYRU4pIEFNRC1WaTogIERldl9JZCAweDE4DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDAN
CihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBl
IDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTAwDQooWEVOKSBBTUQtVmk6ICBGbGFn
cyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5nZTogMHhhMDAgLT4gMHhhMDcNCihY
RU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4
Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4MjgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4
MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5
cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5MDANCihYRU4pIEFNRC1WaTogIEZs
YWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFNRC1W
aTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHgzMA0KKFhFTikgQU1ELVZp
OiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikg
QU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDgwMA0KKFhFTikg
QU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0K
KFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDUwDQoo
WEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50
cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4
NjAwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZp
Y2UgRW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQg
RGV2aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQzDQooWEVOKSBBTUQtVmk6
ICBEZXZfSWQgMHg3MDgNCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIFJhbmdlOiAweDcwOCAtPiAweDdmZg0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IEFsaWFzOiAweDcwMA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4p
IEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg1OA0KKFhFTikg
QU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0K
KFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERldl9JZCAweDUwMA0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6
IDB4NTAwIC0+IDB4NTAxDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhF
TikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweDY4DQooWEVO
KSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6
DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4Mw0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4NDAw
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCBSYW5n
ZTogMHg0MDAgLT4gMHg0MDcNCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQoo
WEVOKSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4ODgNCihY
RU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRy
eToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5
MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFu
Z2U6IDB4OTAgLT4gMHg5Mg0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihY
RU4pIEFNRC1WaTogIFR5cGUgMHgzDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHg5OA0KKFhF
TikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgUmFuZ2U6IDB4
OTggLT4gMHg5YQ0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihYRU4pIEFN
RC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMA0KKFhFTikgQU1E
LVZpOiAgRmxhZ3MgMHhkNw0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToNCihY
RU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhMw0KKFhF
TikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5
Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweGE0
DQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2Ug
RW50cnk6DQooWEVOKSBBTUQtVmk6ICBUeXBlIDB4MA0KKFhFTikgQU1ELVZpOiAgRGV2X0lk
IDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDQzDQooWEVOKSBBTUQtVmk6ICBE
ZXZfSWQgMHgzMDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiAg
RGV2X0lkIFJhbmdlOiAweDMwMCAtPiAweDNmZg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIEFs
aWFzOiAweGE0DQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVudHJ5Og0KKFhFTikgQU1E
LVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAweGE1DQooWEVOKSBBTUQt
Vmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6DQooWEVO
KSBBTUQtVmk6ICBUeXBlIDB4Mg0KKFhFTikgQU1ELVZpOiAgRGV2X0lkIDB4YTgNCihYRU4p
IEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmljZSBFbnRyeToN
CihYRU4pIEFNRC1WaTogIFR5cGUgMHgyDQooWEVOKSBBTUQtVmk6ICBEZXZfSWQgMHhhOQ0K
KFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDINCihYRU4pIEFNRC1WaTogIERldl9JZCAw
eDEwMA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2
aWNlIEVudHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDMNCihYRU4pIEFNRC1WaTogIERl
dl9JZCAweGIwDQooWEVOKSBBTUQtVmk6ICBGbGFncyAweDANCihYRU4pIEFNRC1WaTogIERl
dl9JZCBSYW5nZTogMHhiMCAtPiAweGIyDQooWEVOKSBBTUQtVmk6IElWSEQgRGV2aWNlIEVu
dHJ5Og0KKFhFTikgQU1ELVZpOiAgVHlwZSAweDANCihYRU4pIEFNRC1WaTogIERldl9JZCAw
eDANCihYRU4pIEFNRC1WaTogIEZsYWdzIDB4MA0KKFhFTikgQU1ELVZpOiBJVkhEIERldmlj
ZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0OA0KKFhFTikgQU1ELVZpOiAgRGV2
X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHhkNw0KKFhFTikgQU1ELVZpOiBJVkhE
IERldmljZSBFbnRyeToNCihYRU4pIEFNRC1WaTogIFR5cGUgMHg0OA0KKFhFTikgQU1ELVZp
OiAgRGV2X0lkIDB4MA0KKFhFTikgQU1ELVZpOiAgRmxhZ3MgMHgwDQooWEVOKSBBTUQtVmk6
IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAwMCwgaW50ZXJ1cHQg
dGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVu
dHJ5OiBkZXZpY2UgaWQgPSAweDAwMDEsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDAN
CihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgw
MDAyLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBk
ZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAxMCwgaW50ZXJ1cHQgdGFibGUg
PSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBk
ZXZpY2UgaWQgPSAweDAwMTgsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4p
IEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDI4LCBp
bnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2Ug
dGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDAzMCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0
ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2Ug
aWQgPSAweDAwNTAsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1W
aTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDU4LCBpbnRlcnVw
dCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUg
ZW50cnk6IGRldmljZSBpZCA9IDB4MDA2OCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAw
MA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAw
eDAwODgsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRk
IGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDkwLCBpbnRlcnVwdCB0YWJs
ZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6
IGRldmljZSBpZCA9IDB4MDA5MSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhF
TikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwOTIs
IGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmlj
ZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMDk4LCBpbnRlcnVwdCB0YWJsZSA9IDB4
MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmlj
ZSBpZCA9IDB4MDA5OSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1E
LVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwOWEsIGludGVy
dXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJs
ZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwMGEwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFl
MDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9
IDB4MDBhMywgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBB
ZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYTQsIGludGVydXB0IHRh
YmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRy
eTogZGV2aWNlIGlkID0gMHgwMGE1LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQoo
WEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBh
OCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2
aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYTksIGludGVydXB0IHRhYmxlID0g
MHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2
aWNlIGlkID0gMHgwMGIwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBB
TUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDBiMSwgaW50
ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRh
YmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDAwYjIsIGludGVydXB0IHRhYmxlID0gMHgyNGRm
MWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlk
ID0gMHgwMTAwLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6
IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwMCwgaW50ZXJ1cHQg
dGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVu
dHJ5OiBkZXZpY2UgaWQgPSAweDA0MDEsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDAN
CihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgw
NDAyLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBk
ZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwMywgaW50ZXJ1cHQgdGFibGUg
PSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBk
ZXZpY2UgaWQgPSAweDA0MDQsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4p
IEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNDA1LCBp
bnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2Ug
dGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MDQwNiwgaW50ZXJ1cHQgdGFibGUgPSAweDI0
ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2Ug
aWQgPSAweDA0MDcsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1W
aTogQWRkIGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNTAwLCBpbnRlcnVw
dCB0YWJsZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUg
ZW50cnk6IGRldmljZSBpZCA9IDB4MDUwMSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAw
MA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAw
eDA2MDAsIGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRk
IGRldmljZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwNzAwLCBpbnRlcnVwdCB0YWJs
ZSA9IDB4MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6
IGRldmljZSBpZCA9IDB4MDgwMCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhF
TikgQU1ELVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDA5MDAs
IGludGVydXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmlj
ZSB0YWJsZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwYTAwLCBpbnRlcnVwdCB0YWJsZSA9IDB4
MjRkZjFlMDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmlj
ZSBpZCA9IDB4MGEwMSwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1E
LVZpOiBBZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBhMDIsIGludGVy
dXB0IHRhYmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJs
ZSBlbnRyeTogZGV2aWNlIGlkID0gMHgwYTAzLCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFl
MDAwDQooWEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9
IDB4MGEwNCwgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBB
ZGQgZGV2aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBhMDUsIGludGVydXB0IHRh
YmxlID0gMHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogQWRkIGRldmljZSB0YWJsZSBlbnRy
eTogZGV2aWNlIGlkID0gMHgwYTA2LCBpbnRlcnVwdCB0YWJsZSA9IDB4MjRkZjFlMDAwDQoo
WEVOKSBBTUQtVmk6IEFkZCBkZXZpY2UgdGFibGUgZW50cnk6IGRldmljZSBpZCA9IDB4MGEw
NywgaW50ZXJ1cHQgdGFibGUgPSAweDI0ZGYxZTAwMA0KKFhFTikgQU1ELVZpOiBBZGQgZGV2
aWNlIHRhYmxlIGVudHJ5OiBkZXZpY2UgaWQgPSAweDBiMDAsIGludGVydXB0IHRhYmxlID0g
MHgyNGRmMWUwMDANCihYRU4pIEFNRC1WaTogSU9NTVUgMCBFbmFibGVkLg0KKFhFTikgQU1E
LVZpOiBFbmFibGluZyBnbG9iYWwgdmVjdG9yIG1hcA0KKFhFTikgSS9PIHZpcnR1YWxpc2F0
aW9uIGVuYWJsZWQNCihYRU4pICAtIERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikgR2V0dGlu
ZyBWRVJTSU9OOiA4MDA1MDAxMA0KKFhFTikgR2V0dGluZyBWRVJTSU9OOiA4MDA1MDAxMA0K
KFhFTikgR2V0dGluZyBJRDogMA0KKFhFTikgR2V0dGluZyBMVlQwOiA3MDANCihYRU4pIEdl
dHRpbmcgTFZUMTogNDAwDQooWEVOKSBlbmFibGVkIEV4dElOVCBvbiBDUFUjMA0KKFhFTikg
RVNSIHZhbHVlIGJlZm9yZSBlbmFibGluZyB2ZWN0b3I6IDB4MDAwMDAwMDQgIGFmdGVyOiAw
eDAwMDAwMDAwDQooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMNCihYRU4pICAtPiBVc2lu
ZyBuZXcgQUNLIG1ldGhvZA0KKFhFTikgaW5pdCBJT19BUElDIElSUXMNCihYRU4pICBJTy1B
UElDIChhcGljaWQtcGluKSA2LTAsIDYtMTYsIDYtMTcsIDYtMTgsIDYtMTksIDYtMjAsIDYt
MjEsIDYtMjIsIDYtMjMsIDctMCwgNy0xLCA3LTIsIDctMywgNy00LCA3LTUsIDctNiwgNy03
LCA3LTgsIDctOSwgNy0xMCwgNy0xMSwgNy0xMiwgNy0xMywgNy0xNCwgNy0xNSwgNy0xNiwg
Ny0xNywgNy0xOCwgNy0xOSwgNy0yMCwgNy0yMSwgNy0yMiwgNy0yMywgNy0yNCwgNy0yNSwg
Ny0yNiwgNy0yNywgNy0yOCwgNy0yOSwgNy0zMCwgNy0zMSBub3QgY29ubmVjdGVkLg0KKFhF
TikgLi5USU1FUjogdmVjdG9yPTB4RjAgYXBpYzE9MCBwaW4xPTIgYXBpYzI9LTEgcGluMj0t
MQ0KKFhFTikgbnVtYmVyIG9mIE1QIElSUSBzb3VyY2VzOiAxNS4NCihYRU4pIG51bWJlciBv
ZiBJTy1BUElDICM2IHJlZ2lzdGVyczogMjQuDQooWEVOKSBudW1iZXIgb2YgSU8tQVBJQyAj
NyByZWdpc3RlcnM6IDMyLg0KKFhFTikgdGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uDQooWEVOKSBJTyBBUElDICM2Li4uLi4uDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMDogMDYwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlzaWNhbCBBUElDIGlk
OiAwNg0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCihYRU4pIC4uLi4u
Li4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lzdGVyICMwMTogMDAx
NzgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAw
MTcNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAxDQooWEVOKSAuLi4u
Li4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4uLiByZWdpc3RlciAj
MDI6IDA2MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0aW9uOiAwNg0KKFhF
TikgLi4uLiByZWdpc3RlciAjMDM6IDA3MDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IEJv
b3QgRFQgICAgOiAwDQooWEVOKSAuLi4uIElSUSByZWRpcmVjdGlvbiB0YWJsZToNCihYRU4p
ICBOUiBMb2cgUGh5IE1hc2sgVHJpZyBJUlIgUG9sIFN0YXQgRGVzdCBEZWxpIFZlY3Q6ICAg
DQooWEVOKSAgMDAgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDAxIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg
MzANCihYRU4pICAwMiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAg
IEYwDQooWEVOKSAgMDMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAg
ICAzOA0KKFhFTikgIDA0IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEg
ICAgRjENCihYRU4pICAwNSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAx
ICAgIDQwDQooWEVOKSAgMDYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAg
MSAgICA0OA0KKFhFTikgIDA3IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAg
IDEgICAgNTANCihYRU4pICAwOCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg
ICAxICAgIDU4DQooWEVOKSAgMDkgMDAxIDAxICAxICAgIDEgICAgMCAgIDEgICAwICAgIDEg
ICAgMSAgICA2MA0KKFhFTikgIDBhIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAx
ICAgIDEgICAgNjgNCihYRU4pICAwYiAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAg
MSAgICAxICAgIDcwDQooWEVOKSAgMGMgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAg
IDEgICAgMSAgICA3OA0KKFhFTikgIDBkIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAg
ICAxICAgIDEgICAgODgNCihYRU4pICAwZSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAg
ICAgMSAgICAxICAgIDkwDQooWEVOKSAgMGYgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAw
ICAgIDEgICAgMSAgICA5OA0KKFhFTikgIDEwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDEzIDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNCAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTUgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE2IDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNyAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBJTyBBUElDICM3Li4uLi4uDQooWEVO
KSAuLi4uIHJlZ2lzdGVyICMwMDogMDcwMDAwMDANCihYRU4pIC4uLi4uLi4gICAgOiBwaHlz
aWNhbCBBUElDIGlkOiAwNw0KKFhFTikgLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDAN
CihYRU4pIC4uLi4uLi4gICAgOiBMVFMgICAgICAgICAgOiAwDQooWEVOKSAuLi4uIHJlZ2lz
dGVyICMwMTogMDAxRjgwMjENCihYRU4pIC4uLi4uLi4gICAgIDogbWF4IHJlZGlyZWN0aW9u
IGVudHJpZXM6IDAwMUYNCihYRU4pIC4uLi4uLi4gICAgIDogUFJRIGltcGxlbWVudGVkOiAx
DQooWEVOKSAuLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAyMQ0KKFhFTikgLi4u
LiByZWdpc3RlciAjMDI6IDAwMDAwMDAwDQooWEVOKSAuLi4uLi4uICAgICA6IGFyYml0cmF0
aW9uOiAwMA0KKFhFTikgLi4uLiBJUlEgcmVkaXJlY3Rpb24gdGFibGU6DQooWEVOKSAgTlIg
TG9nIFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERlc3QgRGVsaSBWZWN0OiAgIA0KKFhF
TikgIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihY
RU4pICAwMSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQoo
WEVOKSAgMDIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0K
KFhFTikgIDAzIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDAN
CihYRU4pICAwNCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAw
DQooWEVOKSAgMDUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAw
MA0KKFhFTikgIDA2IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAg
MDANCihYRU4pICAwNyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg
IDAwDQooWEVOKSAgMDggMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAg
ICAwMA0KKFhFTikgIDA5IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAg
ICAgMDANCihYRU4pICAwYSAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAw
ICAgIDAwDQooWEVOKSAgMGIgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAg
MCAgICAwMA0KKFhFTikgIDBjIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg
IDAgICAgMDANCihYRU4pICAwZCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAg
ICAwICAgIDAwDQooWEVOKSAgMGUgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAg
ICAgMCAgICAwMA0KKFhFTikgIDBmIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw
ICAgIDAgICAgMDANCihYRU4pICAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAg
MCAgICAwICAgIDAwDQooWEVOKSAgMTEgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAg
IDAgICAgMCAgICAwMA0KKFhFTikgIDEyIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAg
ICAwICAgIDAgICAgMDANCihYRU4pICAxMyAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAg
ICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAw
ICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAg
MCAgICAwICAgIDAgICAgMDANCihYRU4pICAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAg
IDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg
ICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDE4IDAwMCAwMCAgMSAgICAwICAgIDAgICAw
ICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxOSAwMDAgMDAgIDEgICAgMCAgICAwICAg
MCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWEgMDAwIDAwICAxICAgIDAgICAgMCAg
IDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFiIDAwMCAwMCAgMSAgICAwICAgIDAg
ICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxYyAwMDAgMDAgIDEgICAgMCAgICAw
ICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSAgMWQgMDAwIDAwICAxICAgIDAgICAg
MCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KKFhFTikgIDFlIDAwMCAwMCAgMSAgICAwICAg
IDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCihYRU4pICAxZiAwMDAgMDAgIDEgICAgMCAg
ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQooWEVOKSBVc2luZyB2ZWN0b3ItYmFzZWQg
aW5kZXhpbmcNCihYRU4pIElSUSB0byBwaW4gbWFwcGluZ3M6DQooWEVOKSBJUlEyNDAgLT4g
MDoyDQooWEVOKSBJUlE0OCAtPiAwOjENCihYRU4pIElSUTU2IC0+IDA6Mw0KKFhFTikgSVJR
MjQxIC0+IDA6NA0KKFhFTikgSVJRNjQgLT4gMDo1DQooWEVOKSBJUlE3MiAtPiAwOjYNCihY
RU4pIElSUTgwIC0+IDA6Nw0KKFhFTikgSVJRODggLT4gMDo4DQooWEVOKSBJUlE5NiAtPiAw
OjkNCihYRU4pIElSUTEwNCAtPiAwOjEwDQooWEVOKSBJUlExMTIgLT4gMDoxMQ0KKFhFTikg
SVJRMTIwIC0+IDA6MTINCihYRU4pIElSUTEzNiAtPiAwOjEzDQooWEVOKSBJUlExNDQgLT4g
MDoxNA0KKFhFTikgSVJRMTUyIC0+IDA6MTUNCihYRU4pIC4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLiBkb25lLg0KKFhFTikgVXNpbmcgbG9jYWwgQVBJQyB0aW1lciBp
bnRlcnJ1cHRzLg0KKFhFTikgY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCihYRU4pIC4u
Li4uIENQVSBjbG9jayBzcGVlZCBpcyAzMjAwLjE4NjggTUh6Lg0KKFhFTikgLi4uLi4gaG9z
dCBidXMgY2xvY2sgc3BlZWQgaXMgMjAwLjAxMTUgTUh6Lg0KKFhFTikgLi4uLi4gYnVzX3Nj
YWxlID0gMHgwMDAwQ0NENw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTBdIFBsYXRmb3Jt
IHRpbWVyIGFwcGVhcnMgdG8gaGF2ZSB1bmV4cGVjdGVkbHkgd3JhcHBlZCAxMCBvciBtb3Jl
IHRpbWVzLg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTBdIFBsYXRmb3JtIHRpbWVyIGlz
IDE0LjMxOE1IeiBIUEVUDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0gQWxsb2NhdGVk
IGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0g
SFZNOiBBU0lEcyBlbmFibGVkLg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTBdIFNWTTog
U3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6
MTBdICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6
MjU6MTBdICAtIExhc3QgQnJhbmNoIFJlY29yZCAoTEJSKSBWaXJ0dWFsaXNhdGlvbg0KKFhF
TikgWzIwMTItMDEtMTIgMTI6MjU6MTBdICAtIE5leHQtUklQIFNhdmVkIG9uICNWTUVYSVQN
CihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEwXSAgLSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVy
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0gSFZNOiBTVk0gZW5hYmxlZA0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTBdIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIGRl
dGVjdGVkLg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MDldIG1hc2tlZCBFeHRJTlQgb24g
Q1BVIzENCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjA5XSBtYXNrZWQgRXh0SU5UIG9uIENQ
VSMyDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNTowOV0gbWFza2VkIEV4dElOVCBvbiBDUFUj
Mw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MDldIG1hc2tlZCBFeHRJTlQgb24gQ1BVIzQN
CihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjA5XSBtYXNrZWQgRXh0SU5UIG9uIENQVSM1DQoo
WEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0gQnJvdWdodCB1cCA2IENQVXMNCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjEwXSBIUEVUJ3MgTVNJIG1vZGUgaGFzbid0IGJlZW4gc3VwcG9y
dGVkIHdoZW4gSW50ZXJydXB0IFJlbWFwcGluZyBpcyBlbmFibGVkLg0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTBdIEFDUEkgc2xlZXAgbW9kZXM6IFMzDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxMF0gTUNBOiBVc2UgaHcgdGhyZXNob2xkaW5nIHRvIGFkanVzdCBwb2xsaW5n
IGZyZXF1ZW5jeQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTBdIG1jaGVja19wb2xsOiBN
YWNoaW5lIGNoZWNrIHBvbGxpbmcgdGltZXIgc3RhcnRlZC4NCihYRU4pIFsyMDEyLTAxLTEy
IDEyOjI1OjEwXSBYZW5vcHJvZmlsZTogRmFpbGVkIHRvIHNldHVwIElCUyBMVlQgb2Zmc2V0
LCBJQlNDVEwgPSAweGZmZmZmZmZmDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMF0gKioq
IExPQURJTkcgRE9NQUlOIDAgKioqDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIFhl
biAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0MzINCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjExXSAgRG9tMCBrZXJuZWw6IDY0LWJpdCwgUEFFLCBsc2IsIHBhZGRyIDB4MTAwMDAw
MCAtPiAweDJiNWEwMDANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBQSFlTSUNBTCBN
RU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIERvbTAg
YWxsb2MuOiAgIDAwMDAwMDAyNDQwMDAwMDAtPjAwMDAwMDAyNDgwMDAwMDAgKDI0NDA3OSBw
YWdlcyB0byBiZSBhbGxvY2F0ZWQpDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIElu
aXQuIHJhbWRpc2s6IDAwMDAwMDAyNGY5NmYwMDAtPjAwMDAwMDAyNGZmZmY0MDANCihYRU4p
IFsyMDEyLTAxLTEyIDEyOjI1OjExXSBWSVJUVUFMIE1FTU9SWSBBUlJBTkdFTUVOVDoNCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAw
MDAwMC0+ZmZmZmZmZmY4MmI1YTAwMA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdICBJ
bml0LiByYW1kaXNrOiBmZmZmZmZmZjgyYjVhMDAwLT5mZmZmZmZmZjgzMWVhNDAwDQooWEVO
KSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIFBoeXMtTWFjaCBtYXA6IGZmZmZmZmZmODMxZWIw
MDAtPmZmZmZmZmZmODMzZWIwMDANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSAgU3Rh
cnQgaW5mbzogICAgZmZmZmZmZmY4MzNlYjAwMC0+ZmZmZmZmZmY4MzNlYjRiNA0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTFdICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjgzM2VjMDAw
LT5mZmZmZmZmZjgzNDBiMDAwDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gIEJvb3Qg
c3RhY2s6ICAgIGZmZmZmZmZmODM0MGIwMDAtPmZmZmZmZmZmODM0MGMwMDANCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjExXSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+
ZmZmZmZmZmY4MzgwMDAwMA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdICBFTlRSWSBB
RERSRVNTOiBmZmZmZmZmZjgxZWU1MjAwDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0g
RG9tMCBoYXMgbWF4aW11bSA2IFZDUFVzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDAwLCByb290
IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MDAwMiwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwMTAsIHJvb3QgdGFi
bGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2
aWNlIGlkID0gMHgwMDE4LCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAs
IHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTog
U2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDAyOCwgcm9vdCB0YWJsZSA9
IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEy
LTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2Ug
aWQgPSAweDAwMzAsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFn
aW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1
cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMDUwLCByb290IHRhYmxlID0gMHgy
NGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEt
MTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9
IDB4MDA1OCwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcg
bW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkv
TyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwNjgsIHJvb3QgdGFibGUgPSAweDI0ZGUy
ZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAx
MjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgw
MDg4LCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2Rl
ID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBh
Z2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5MCwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAw
LCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1
OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwOTIs
IHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAz
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0
YWJsZTogZGV2aWNlIGlkID0gMHgwMDk4LCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRv
bWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFd
IEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDA5YSwgcm9v
dCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxl
OiBkZXZpY2UgaWQgPSAweDAwYTAsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWlu
ID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1E
LVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwMGEzLCByb290IHRh
YmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRl
dmljZSBpZCA9IDB4MDBhNCwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAw
LCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6
IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDAwYTUsIHJvb3QgdGFibGUg
PSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAx
Mi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNl
IGlkID0gMHgwMGE4LCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBh
Z2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0
dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDBiMCwgcm9vdCB0YWJsZSA9IDB4
MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAx
LTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQg
PSAweDAwYjIsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5n
IG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBObyBpb21t
dSBmb3IgZGV2aWNlIDAwOjE4LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQt
Vmk6IE5vIGlvbW11IGZvciBkZXZpY2UgMDA6MTguMQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6
MjU6MTFdIEFNRC1WaTogTm8gaW9tbXUgZm9yIGRldmljZSAwMDoxOC4yDQooWEVOKSBbMjAx
Mi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBObyBpb21tdSBmb3IgZGV2aWNlIDAwOjE4LjMN
CihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IE5vIGlvbW11IGZvciBkZXZp
Y2UgMDA6MTguNA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAg
SS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQwMCwgcm9vdCB0YWJsZSA9IDB4MjRk
ZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEy
IDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAw
eDA0MDEsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1v
ZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08g
cGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDAyLCByb290IHRhYmxlID0gMHgyNGRlMmQw
MDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6
MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDQw
Mywgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9
IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdl
IHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDQsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwg
ZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNTox
MV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNDA1LCBy
b290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0K
KFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFi
bGU6IGRldmljZSBpZCA9IDB4MDQwNiwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21h
aW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBB
TUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA0MDcsIHJvb3Qg
dGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVO
KSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTog
ZGV2aWNlIGlkID0gMHgwNTAwLCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9
IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1W
aTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MDUwMSwgcm9vdCB0YWJs
ZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZp
Y2UgaWQgPSAweDA2MDAsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwg
cGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBT
ZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwNzAwLCByb290IHRhYmxlID0g
MHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBp
ZCA9IDB4MDgwMCwgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdp
bmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVw
IEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDA5MDAsIHJvb3QgdGFibGUgPSAweDI0
ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0g
MHgwYTAwLCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBt
b2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9P
IHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwMSwgcm9vdCB0YWJsZSA9IDB4MjRkZTJk
MDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBh
MDIsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUg
PSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0gQU1ELVZpOiBTZXR1cCBJL08gcGFn
ZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTAzLCByb290IHRhYmxlID0gMHgyNGRlMmQwMDAs
IGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6
MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6IGRldmljZSBpZCA9IDB4MGEwNCwg
cm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4gPSAwLCBwYWdpbmcgbW9kZSA9IDMN
CihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQtVmk6IFNldHVwIEkvTyBwYWdlIHRh
YmxlOiBkZXZpY2UgaWQgPSAweDBhMDUsIHJvb3QgdGFibGUgPSAweDI0ZGUyZDAwMCwgZG9t
YWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxMV0g
QU1ELVZpOiBTZXR1cCBJL08gcGFnZSB0YWJsZTogZGV2aWNlIGlkID0gMHgwYTA2LCByb290
IHRhYmxlID0gMHgyNGRlMmQwMDAsIGRvbWFpbiA9IDAsIHBhZ2luZyBtb2RlID0gMw0KKFhF
TikgWzIwMTItMDEtMTIgMTI6MjU6MTFdIEFNRC1WaTogU2V0dXAgSS9PIHBhZ2UgdGFibGU6
IGRldmljZSBpZCA9IDB4MGEwNywgcm9vdCB0YWJsZSA9IDB4MjRkZTJkMDAwLCBkb21haW4g
PSAwLCBwYWdpbmcgbW9kZSA9IDMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjExXSBBTUQt
Vmk6IFNldHVwIEkvTyBwYWdlIHRhYmxlOiBkZXZpY2UgaWQgPSAweDBiMDAsIHJvb3QgdGFi
bGUgPSAweDI0ZGUyZDAwMCwgZG9tYWluID0gMCwgcGFnaW5nIG1vZGUgPSAzDQooWEVOKSBb
MjAxMi0wMS0xMiAxMjoyNToxMV0gU2NydWJiaW5nIEZyZWUgUkFNOiAuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLmRvbmUuDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gWGVuIHRyYWNlIGJ1ZmZl
cnM6IGRpc2FibGVkDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gU3RkLiBMb2dsZXZl
bDogQWxsDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gR3Vlc3QgTG9nbGV2ZWw6IE5v
dGhpbmcgKFJhdGUtbGltaXRlZDogRXJyb3JzIGFuZCB3YXJuaW5ncykNCihYRU4pIFsyMDEy
LTAxLTEyIDEyOjI1OjEzXSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSAqKiogU2VyaWFsIGlucHV0IC0+IERPTTAgKHR5
cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0IHRvIFhlbikNCihYRU4p
IFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBGcmVlZCAyMjBrQiBpbml0IG1lbW9yeS4NCihYRU4p
IFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRy
eSAoNi05IC0+IDB4NjAgLT4gSVJRIDkgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTNdIHRyYXBzLmM6MjQzMjpkMCBEb21haW4gYXR0ZW1wdGVkIFdSTVNS
IDAwMDAwMDAwYzAwMTAwMDQgZnJvbSAweDAwMDBlZmYyZmVmMzFmMGMgdG8gMHgwMDAwMDAw
MDAwMDBhYmNkLg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNl
IDAwOjAwLjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAw
MDowMC4yDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6
MDIuMA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjAz
LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDowNS4w
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6MDYuMA0K
KFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjBhLjANCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDowYi4wDQooWEVO
KSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6MGQuMA0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjExLjANCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDoxMi4wDQooWEVOKSBbMjAx
Mi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6MTIuMg0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjEzLjANCihYRU4pIFsyMDEyLTAx
LTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDoxMy4yDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDA6MTQuMA0KKFhFTikgWzIwMTItMDEtMTIg
MTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjE0LjMNCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwMDoxNC40DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoy
NToxM10gUENJIGFkZCBkZXZpY2UgMDA6MTQuNQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6
MTNdIFBDSSBhZGQgZGV2aWNlIDAwOjE1LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEz
XSBQQ0kgYWRkIGRldmljZSAwMDoxNi4wDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10g
UENJIGFkZCBkZXZpY2UgMDA6MTYuMg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBD
SSBhZGQgZGV2aWNlIDAwOjE4LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kg
YWRkIGRldmljZSAwMDoxOC4xDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFk
ZCBkZXZpY2UgMDA6MTguMg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQg
ZGV2aWNlIDAwOjE4LjMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRl
dmljZSAwMDoxOC40DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZp
Y2UgMGI6MDAuMA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNl
IDBhOjAwLjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAw
YTowMC4xDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMGE6
MDAuMg0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDBhOjAw
LjMNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwYTowMC40
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMGE6MDAuNQ0K
KFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDBhOjAwLjYNCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwYTowMC43DQooWEVO
KSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDk6MDAuMA0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDA4OjAwLjANCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwNjowMC4wDQooWEVOKSBbMjAx
Mi0wMS0xMiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDc6MDEuMA0KKFhFTikgWzIwMTIt
MDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDA3OjAxLjENCihYRU4pIFsyMDEyLTAx
LTEyIDEyOjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwNzowMS4yDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxM10gUENJIGFkZCBkZXZpY2UgMDU6MDAuMA0KKFhFTikgWzIwMTItMDEtMTIg
MTI6MjU6MTNdIFBDSSBhZGQgZGV2aWNlIDA1OjAwLjENCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjEzXSBQQ0kgYWRkIGRldmljZSAwNDowMC4wDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoy
NToxM10gUENJIGFkZCBkZXZpY2UgMDQ6MDAuMQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6
MTNdIFBDSSBhZGQgZGV2aWNlIDA0OjAwLjINCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEz
XSBQQ0kgYWRkIGRldmljZSAwNDowMC4zDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10g
UENJIGFkZCBkZXZpY2UgMDQ6MDAuNA0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBD
SSBhZGQgZGV2aWNlIDA0OjAwLjUNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBQQ0kg
YWRkIGRldmljZSAwNDowMC42DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gUENJIGFk
ZCBkZXZpY2UgMDQ6MDAuNw0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIFBDSSBhZGQg
ZGV2aWNlIDAzOjA2LjANCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBJT0FQSUNbMF06
IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi04IC0+IDB4NTggLT4gSVJRIDggTW9kZTowIEFj
dGl2ZTowKQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTNdIElPQVBJQ1swXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg2LTEzIC0+IDB4ODggLT4gSVJRIDEzIE1vZGU6MCBBY3RpdmU6
MCkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjEzXSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy0yOCAtPiAweGEwIC0+IElSUSA1MiBNb2RlOjEgQWN0aXZlOjEpDQoo
WEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxM10gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcg
ZW50cnkgKDctMjkgLT4gMHhhOCAtPiBJUlEgNTMgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikg
WzIwMTItMDEtMTIgMTI6MjU6MTNdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5
ICg3LTMwIC0+IDB4YjAgLT4gSVJRIDU0IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEy
LTAxLTEyIDEyOjI1OjEzXSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0x
NiAtPiAweGI4IC0+IElSUSAxNiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wMS0x
MiAxMjoyNToxNF0gcGh5c2Rldi5jOjE1NTogZG9tMDogd3JvbmcgbWFwX3BpcnEgdHlwZSAz
DQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxNF0gSU9BUElDWzBdOiBTZXQgUENJIHJvdXRp
bmcgZW50cnkgKDYtMjIgLT4gMHg0MSAtPiBJUlEgMjIgTW9kZToxIEFjdGl2ZToxKQ0KKFhF
TikgWzIwMTItMDEtMTIgMTI6MjU6MTRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVu
dHJ5ICg3LTE5IC0+IDB4NDkgLT4gSVJRIDQzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny0xOCAtPiAweDUxIC0+IElSUSA0MiBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0w
MS0xMiAxMjoyNToxNF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMTcg
LT4gMHg1OSAtPiBJUlEgNDEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDEtMTIg
MTI6MjU6MTRdIElPQVBJQ1sxXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg3LTE2IC0+IDB4
NjEgLT4gSVJRIDQwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1
OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy05IC0+IDB4NjkgLT4g
SVJRIDMzIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE0XSBJ
T0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy04IC0+IDB4NzEgLT4gSVJRIDMy
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNb
MV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy0yMiAtPiAweDc5IC0+IElSUSA0NiBNb2Rl
OjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNToxNF0gSU9BUElDWzFdOiBT
ZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjEgLT4gMHg4MSAtPiBJUlEgNDUgTW9kZToxIEFj
dGl2ZToxKQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTRdIElPQVBJQ1sxXTogU2V0IFBD
SSByb3V0aW5nIGVudHJ5ICg3LTIwIC0+IDB4ODkgLT4gSVJRIDQ0IE1vZGU6MSBBY3RpdmU6
MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91
dGluZyBlbnRyeSAoNy03IC0+IDB4OTEgLT4gSVJRIDMxIE1vZGU6MSBBY3RpdmU6MSkNCihY
RU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBl
bnRyeSAoNy02IC0+IDB4OTkgLT4gSVJRIDMwIE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsy
MDEyLTAxLTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAo
Ny01IC0+IDB4YTEgLT4gSVJRIDI5IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAx
LTEyIDEyOjI1OjE0XSBJT0FQSUNbMV06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNy00IC0+
IDB4YTkgLT4gSVJRIDI4IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEy
OjI1OjE0XSBJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOSAtPiAweGIx
IC0+IElSUSAxOSBNb2RlOjEgQWN0aXZlOjEpDQooWEVOKSBbMjAxMi0wMS0xMiAxMjoyNTox
NF0gSU9BUElDWzFdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDctMjcgLT4gMHhjOSAtPiBJ
UlEgNTEgTW9kZToxIEFjdGl2ZToxKQ0KKFhFTikgWzIwMTItMDEtMTIgMTI6MjU6MTRdIElP
QVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICg2LTE3IC0+IDB4ZDkgLT4gSVJRIDE3
IE1vZGU6MSBBY3RpdmU6MSkNCihYRU4pIFsyMDEyLTAxLTEyIDEyOjI1OjE1XSBJT0FQSUNb
MF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoNi0xOCAtPiAweDIyIC0+IElSUSAxOCBNb2Rl
OjEgQWN0aXZlOjEpDQo=
------------0B61A709518B22542
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

------------0B61A709518B22542--



From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:39:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJwH-0001s7-6a; Thu, 12 Jan 2012 12:39: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 1RlJwF-0001qq-Tm
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:39:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326371961!10618546!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 29735 invoked from network); 12 Jan 2012 12:39:21 -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; 12 Jan 2012 12:39:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:39:21 +0000
Message-Id: <4F0EE2C2020000780006C18C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:40:18 +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="=__Part5F7113A2.0__="
Subject: [Xen-devel] [PATCH] x86: properly define size_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>
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.

--=__Part5F7113A2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Having it defined unilaterally as 'unsigned long' got me surprised
recently when I tried to use the 'z' printk type modifier, as that is
expected by the compiler to be used only on the type it knows size_t
is supposed to have.

Generally the compiler provides a construct to do this, so use it when
available.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -183,10 +183,10 @@ static int get_next_ucode_from_buffer_am
     struct microcode_amd *mc_amd,
     const void *buf,
     size_t bufsize,
-    unsigned long *offset)
+    size_t *offset)
 {
     const uint8_t *bufp =3D buf;
-    unsigned long off;
+    size_t off;
     const struct mpbhdr *mpbuf;
=20
     off =3D *offset;
@@ -203,7 +203,7 @@ static int get_next_ucode_from_buffer_am
         return -EINVAL;
     }
=20
-    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
+    printk(KERN_DEBUG "microcode: size %zu, block size %u, offset %zu\n",
            bufsize, mpbuf->len, off);
=20
     if ( (off + mpbuf->len) > bufsize )
@@ -234,7 +234,7 @@ static int get_next_ucode_from_buffer_am
 static int install_equiv_cpu_table(
     struct microcode_amd *mc_amd,
     const uint32_t *buf,
-    unsigned long *offset)
+    size_t *offset)
 {
     const struct mpbhdr *mpbuf =3D (const struct mpbhdr *)&buf[1];
=20
--- a/xen/include/asm-x86/types.h
+++ b/xen/include/asm-x86/types.h
@@ -47,7 +47,13 @@ typedef unsigned long paddr_t;
 #define PRIpaddr "016lx"
 #endif
=20
+#if defined(__SIZE_TYPE__)
+typedef __SIZE_TYPE__ size_t;
+#elif defined(__i386__)
+typedef unsigned int size_t;
+#else
 typedef unsigned long size_t;
+#endif
=20
 typedef char bool_t;
 #define test_and_set_bool(b)   xchg(&(b), 1)




--=__Part5F7113A2.0__=
Content-Type: text/plain; name="x86-size_t.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-size_t.patch"

x86: properly define size_t=0A=0AHaving it defined unilaterally as =
'unsigned long' got me surprised=0Arecently when I tried to use the 'z' =
printk type modifier, as that is=0Aexpected by the compiler to be used =
only on the type it knows size_t=0Ais supposed to have.=0A=0AGenerally the =
compiler provides a construct to do this, so use it when=0Aavailable.=0A=0A=
Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/micr=
ocode_amd.c=0A+++ b/xen/arch/x86/microcode_amd.c=0A@@ -183,10 +183,10 @@ =
static int get_next_ucode_from_buffer_am=0A     struct microcode_amd =
*mc_amd,=0A     const void *buf,=0A     size_t bufsize,=0A-    unsigned =
long *offset)=0A+    size_t *offset)=0A {=0A     const uint8_t *bufp =3D =
buf;=0A-    unsigned long off;=0A+    size_t off;=0A     const struct =
mpbhdr *mpbuf;=0A =0A     off =3D *offset;=0A@@ -203,7 +203,7 @@ static =
int get_next_ucode_from_buffer_am=0A         return -EINVAL;=0A     }=0A =
=0A-    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset =
%ld\n",=0A+    printk(KERN_DEBUG "microcode: size %zu, block size %u, =
offset %zu\n",=0A            bufsize, mpbuf->len, off);=0A =0A     if ( =
(off + mpbuf->len) > bufsize )=0A@@ -234,7 +234,7 @@ static int get_next_uc=
ode_from_buffer_am=0A static int install_equiv_cpu_table(=0A     struct =
microcode_amd *mc_amd,=0A     const uint32_t *buf,=0A-    unsigned long =
*offset)=0A+    size_t *offset)=0A {=0A     const struct mpbhdr *mpbuf =3D =
(const struct mpbhdr *)&buf[1];=0A =0A--- a/xen/include/asm-x86/types.h=0A+=
++ b/xen/include/asm-x86/types.h=0A@@ -47,7 +47,13 @@ typedef unsigned =
long paddr_t;=0A #define PRIpaddr "016lx"=0A #endif=0A =0A+#if defined(__SI=
ZE_TYPE__)=0A+typedef __SIZE_TYPE__ size_t;=0A+#elif defined(__i386__)=0A+t=
ypedef unsigned int size_t;=0A+#else=0A typedef unsigned long size_t;=0A+#e=
ndif=0A =0A typedef char bool_t;=0A #define test_and_set_bool(b)   =
xchg(&(b), 1)=0A
--=__Part5F7113A2.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

--=__Part5F7113A2.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:39:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJwH-0001s7-6a; Thu, 12 Jan 2012 12:39: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 1RlJwF-0001qq-Tm
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:39:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326371961!10618546!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 29735 invoked from network); 12 Jan 2012 12:39:21 -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; 12 Jan 2012 12:39:21 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:39:21 +0000
Message-Id: <4F0EE2C2020000780006C18C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:40:18 +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="=__Part5F7113A2.0__="
Subject: [Xen-devel] [PATCH] x86: properly define size_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>
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.

--=__Part5F7113A2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Having it defined unilaterally as 'unsigned long' got me surprised
recently when I tried to use the 'z' printk type modifier, as that is
expected by the compiler to be used only on the type it knows size_t
is supposed to have.

Generally the compiler provides a construct to do this, so use it when
available.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/microcode_amd.c
+++ b/xen/arch/x86/microcode_amd.c
@@ -183,10 +183,10 @@ static int get_next_ucode_from_buffer_am
     struct microcode_amd *mc_amd,
     const void *buf,
     size_t bufsize,
-    unsigned long *offset)
+    size_t *offset)
 {
     const uint8_t *bufp =3D buf;
-    unsigned long off;
+    size_t off;
     const struct mpbhdr *mpbuf;
=20
     off =3D *offset;
@@ -203,7 +203,7 @@ static int get_next_ucode_from_buffer_am
         return -EINVAL;
     }
=20
-    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
+    printk(KERN_DEBUG "microcode: size %zu, block size %u, offset %zu\n",
            bufsize, mpbuf->len, off);
=20
     if ( (off + mpbuf->len) > bufsize )
@@ -234,7 +234,7 @@ static int get_next_ucode_from_buffer_am
 static int install_equiv_cpu_table(
     struct microcode_amd *mc_amd,
     const uint32_t *buf,
-    unsigned long *offset)
+    size_t *offset)
 {
     const struct mpbhdr *mpbuf =3D (const struct mpbhdr *)&buf[1];
=20
--- a/xen/include/asm-x86/types.h
+++ b/xen/include/asm-x86/types.h
@@ -47,7 +47,13 @@ typedef unsigned long paddr_t;
 #define PRIpaddr "016lx"
 #endif
=20
+#if defined(__SIZE_TYPE__)
+typedef __SIZE_TYPE__ size_t;
+#elif defined(__i386__)
+typedef unsigned int size_t;
+#else
 typedef unsigned long size_t;
+#endif
=20
 typedef char bool_t;
 #define test_and_set_bool(b)   xchg(&(b), 1)




--=__Part5F7113A2.0__=
Content-Type: text/plain; name="x86-size_t.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-size_t.patch"

x86: properly define size_t=0A=0AHaving it defined unilaterally as =
'unsigned long' got me surprised=0Arecently when I tried to use the 'z' =
printk type modifier, as that is=0Aexpected by the compiler to be used =
only on the type it knows size_t=0Ais supposed to have.=0A=0AGenerally the =
compiler provides a construct to do this, so use it when=0Aavailable.=0A=0A=
Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/micr=
ocode_amd.c=0A+++ b/xen/arch/x86/microcode_amd.c=0A@@ -183,10 +183,10 @@ =
static int get_next_ucode_from_buffer_am=0A     struct microcode_amd =
*mc_amd,=0A     const void *buf,=0A     size_t bufsize,=0A-    unsigned =
long *offset)=0A+    size_t *offset)=0A {=0A     const uint8_t *bufp =3D =
buf;=0A-    unsigned long off;=0A+    size_t off;=0A     const struct =
mpbhdr *mpbuf;=0A =0A     off =3D *offset;=0A@@ -203,7 +203,7 @@ static =
int get_next_ucode_from_buffer_am=0A         return -EINVAL;=0A     }=0A =
=0A-    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset =
%ld\n",=0A+    printk(KERN_DEBUG "microcode: size %zu, block size %u, =
offset %zu\n",=0A            bufsize, mpbuf->len, off);=0A =0A     if ( =
(off + mpbuf->len) > bufsize )=0A@@ -234,7 +234,7 @@ static int get_next_uc=
ode_from_buffer_am=0A static int install_equiv_cpu_table(=0A     struct =
microcode_amd *mc_amd,=0A     const uint32_t *buf,=0A-    unsigned long =
*offset)=0A+    size_t *offset)=0A {=0A     const struct mpbhdr *mpbuf =3D =
(const struct mpbhdr *)&buf[1];=0A =0A--- a/xen/include/asm-x86/types.h=0A+=
++ b/xen/include/asm-x86/types.h=0A@@ -47,7 +47,13 @@ typedef unsigned =
long paddr_t;=0A #define PRIpaddr "016lx"=0A #endif=0A =0A+#if defined(__SI=
ZE_TYPE__)=0A+typedef __SIZE_TYPE__ size_t;=0A+#elif defined(__i386__)=0A+t=
ypedef unsigned int size_t;=0A+#else=0A typedef unsigned long size_t;=0A+#e=
ndif=0A =0A typedef char bool_t;=0A #define test_and_set_bool(b)   =
xchg(&(b), 1)=0A
--=__Part5F7113A2.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

--=__Part5F7113A2.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:42:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12: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 1RlJyi-0002B6-8P; Thu, 12 Jan 2012 12:42:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RlJyg-0002AL-MM
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:41:58 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326372112!8299950!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5719 invoked from network); 12 Jan 2012 12:41:52 -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;
	12 Jan 2012 12:41:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9969369"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 12:41: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, 12 Jan 2012 12:41:25 +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 1RlJy9-0001Te-AA;
	Thu, 12 Jan 2012 12:41:25 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RlJy2-0005Rq-Ta;
	Thu, 12 Jan 2012 12:41:18 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 12 Jan 2012 12:41:01 +0000
Message-ID: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, konrad@darnok.org, 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. (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

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>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:42:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12: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 1RlJyi-0002B6-8P; Thu, 12 Jan 2012 12:42:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RlJyg-0002AL-MM
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:41:58 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326372112!8299950!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5719 invoked from network); 12 Jan 2012 12:41:52 -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;
	12 Jan 2012 12:41:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9969369"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 12:41: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, 12 Jan 2012 12:41:25 +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 1RlJy9-0001Te-AA;
	Thu, 12 Jan 2012 12:41:25 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RlJy2-0005Rq-Ta;
	Thu, 12 Jan 2012 12:41:18 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 12 Jan 2012 12:41:01 +0000
Message-ID: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, konrad@darnok.org, 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. (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

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>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:42:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:42:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJyc-0002AQ-RD; Thu, 12 Jan 2012 12:41:54 +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 1RlJya-00029t-S2
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:41:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326372106!10619046!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 30395 invoked from network); 12 Jan 2012 12:41:46 -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; 12 Jan 2012 12:41:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:41:46 +0000
Message-Id: <4F0EE353020000780006C190@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:42: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="=__PartAF81E353.0__="
Subject: [Xen-devel] [PATCH] x86-64: globally use -mno-sse
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartAF81E353.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This eliminates pointless prologue code from functions having variable
argument lists (since that way xmm registers can't possibly be passed).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -41,7 +41,7 @@ x86_64 :=3D n
 endif
=20
 ifeq ($(TARGET_SUBARCH),x86_64)
-CFLAGS +=3D -mno-red-zone -fpic
+CFLAGS +=3D -mno-red-zone -mno-sse -fpic
 CFLAGS +=3D -fno-asynchronous-unwind-tables
 # -fvisibility=3Dhidden reduces -fpic cost, if it's available
 ifneq ($(call cc-option,$(CC),-fvisibility=3Dhidden,n),n)
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,4 +1,4 @@
-CFLAGS +=3D -fshort-wchar -mno-sse
+CFLAGS +=3D -fshort-wchar
=20
 obj-y +=3D stub.o
=20




--=__PartAF81E353.0__=
Content-Type: text/plain; name="x86_64-no-SSE.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-no-SSE.patch"

x86-64: globally use -mno-sse=0A=0AThis eliminates pointless prologue code =
from functions having variable=0Aargument lists (since that way xmm =
registers can't possibly be passed).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/Rules.mk=0A+++ b/xen/arch/x86/R=
ules.mk=0A@@ -41,7 +41,7 @@ x86_64 :=3D n=0A endif=0A =0A ifeq ($(TARGET_SU=
BARCH),x86_64)=0A-CFLAGS +=3D -mno-red-zone -fpic=0A+CFLAGS +=3D -mno-red-z=
one -mno-sse -fpic=0A CFLAGS +=3D -fno-asynchronous-unwind-tables=0A # =
-fvisibility=3Dhidden reduces -fpic cost, if it's available=0A ifneq =
($(call cc-option,$(CC),-fvisibility=3Dhidden,n),n)=0A--- a/xen/arch/x86/ef=
i/Makefile=0A+++ b/xen/arch/x86/efi/Makefile=0A@@ -1,4 +1,4 @@=0A-CFLAGS =
+=3D -fshort-wchar -mno-sse=0A+CFLAGS +=3D -fshort-wchar=0A =0A obj-y +=3D =
stub.o=0A =0A
--=__PartAF81E353.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

--=__PartAF81E353.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:42:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:42:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJyc-0002AQ-RD; Thu, 12 Jan 2012 12:41:54 +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 1RlJya-00029t-S2
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:41:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326372106!10619046!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 30395 invoked from network); 12 Jan 2012 12:41:46 -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; 12 Jan 2012 12:41:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 12:41:46 +0000
Message-Id: <4F0EE353020000780006C190@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 12:42: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="=__PartAF81E353.0__="
Subject: [Xen-devel] [PATCH] x86-64: globally use -mno-sse
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartAF81E353.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This eliminates pointless prologue code from functions having variable
argument lists (since that way xmm registers can't possibly be passed).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -41,7 +41,7 @@ x86_64 :=3D n
 endif
=20
 ifeq ($(TARGET_SUBARCH),x86_64)
-CFLAGS +=3D -mno-red-zone -fpic
+CFLAGS +=3D -mno-red-zone -mno-sse -fpic
 CFLAGS +=3D -fno-asynchronous-unwind-tables
 # -fvisibility=3Dhidden reduces -fpic cost, if it's available
 ifneq ($(call cc-option,$(CC),-fvisibility=3Dhidden,n),n)
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,4 +1,4 @@
-CFLAGS +=3D -fshort-wchar -mno-sse
+CFLAGS +=3D -fshort-wchar
=20
 obj-y +=3D stub.o
=20




--=__PartAF81E353.0__=
Content-Type: text/plain; name="x86_64-no-SSE.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86_64-no-SSE.patch"

x86-64: globally use -mno-sse=0A=0AThis eliminates pointless prologue code =
from functions having variable=0Aargument lists (since that way xmm =
registers can't possibly be passed).=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/xen/arch/x86/Rules.mk=0A+++ b/xen/arch/x86/R=
ules.mk=0A@@ -41,7 +41,7 @@ x86_64 :=3D n=0A endif=0A =0A ifeq ($(TARGET_SU=
BARCH),x86_64)=0A-CFLAGS +=3D -mno-red-zone -fpic=0A+CFLAGS +=3D -mno-red-z=
one -mno-sse -fpic=0A CFLAGS +=3D -fno-asynchronous-unwind-tables=0A # =
-fvisibility=3Dhidden reduces -fpic cost, if it's available=0A ifneq =
($(call cc-option,$(CC),-fvisibility=3Dhidden,n),n)=0A--- a/xen/arch/x86/ef=
i/Makefile=0A+++ b/xen/arch/x86/efi/Makefile=0A@@ -1,4 +1,4 @@=0A-CFLAGS =
+=3D -fshort-wchar -mno-sse=0A+CFLAGS +=3D -fshort-wchar=0A =0A obj-y +=3D =
stub.o=0A =0A
--=__PartAF81E353.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

--=__PartAF81E353.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:43:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:43:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJzo-0002MM-OB; Thu, 12 Jan 2012 12:43:08 +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 1RlJzn-0002Lo-H3
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:43:07 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326372181!10729570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22398 invoked from network); 12 Jan 2012 12:43:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 12:43:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9969398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 12:43: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, 12 Jan 2012 12:43:01 +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 1RlJzg-0001UF-Tb;
	Thu, 12 Jan 2012 12:43:00 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RlJza-0005SY-HW;
	Thu, 12 Jan 2012 12:42:54 +0000
Date: Thu, 12 Jan 2012 12:42:54 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <20120112124254.GB11262@spongy.cam.xci-test.com>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
In-Reply-To: <1326372062-20905-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>,
	"konrad@darnok.org" <konrad@darnok.org>,
	"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. (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

--wac7ysb48OaltWcw
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline

On 12/01 12:41, 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>

Oups, patch is missing.

Jean

--wac7ysb48OaltWcw
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment;
	filename="qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch"

commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Wed Nov 23 07:53:30 2011 +0000

    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.
    
    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.

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..7ee3c61 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -238,6 +238,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).
@@ -444,6 +452,16 @@ 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,
     },
+    /* Intel IGFX OpRegion reg */
+    {
+        .offset     = PCI_INTEL_OPREGION,
+        .size       = 4,
+        .init_val   = 0,
+        .no_wb      = 1,
+        .u.dw.read   = pt_intel_opregion_read,
+        .u.dw.write  = pt_intel_opregion_write,
+        .u.dw.restore  = NULL,
+    },
     {
         .size = 0,
     },
@@ -737,7 +755,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 */
@@ -3006,6 +3024,19 @@ 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)
+{
+    /*
+    ** By default we will trap up to 0x40 in the cfg space.
+    ** If an intel device is pass through we need to trap 0xfc,
+    ** therefore the size should be 0xff.
+    */
+    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)
@@ -4154,6 +4185,22 @@ 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..c61a7fb 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -422,6 +422,8 @@ 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);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..a60673f 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 == 0 )
+        return -1;
+
+    val = igd_guest_opregion;
+#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);
     }

--wac7ysb48OaltWcw
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--wac7ysb48OaltWcw--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 12:43:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 12:43:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlJzo-0002MM-OB; Thu, 12 Jan 2012 12:43:08 +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 1RlJzn-0002Lo-H3
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 12:43:07 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326372181!10729570!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22398 invoked from network); 12 Jan 2012 12:43:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 12:43:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,497,1320624000"; 
   d="scan'208";a="9969398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 12:43: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, 12 Jan 2012 12:43:01 +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 1RlJzg-0001UF-Tb;
	Thu, 12 Jan 2012 12:43:00 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RlJza-0005SY-HW;
	Thu, 12 Jan 2012 12:42:54 +0000
Date: Thu, 12 Jan 2012 12:42:54 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <20120112124254.GB11262@spongy.cam.xci-test.com>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="wac7ysb48OaltWcw"
Content-Disposition: inline
In-Reply-To: <1326372062-20905-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>,
	"konrad@darnok.org" <konrad@darnok.org>,
	"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. (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

--wac7ysb48OaltWcw
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline

On 12/01 12:41, 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>

Oups, patch is missing.

Jean

--wac7ysb48OaltWcw
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment;
	filename="qemu-xen-Intel-GPU-passthrough-fix-OpRegion-mapping.patch"

commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
Author: Jean Guyader <jean.guyader@eu.citrix.com>
Date:   Wed Nov 23 07:53:30 2011 +0000

    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.
    
    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.

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..7ee3c61 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -238,6 +238,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).
@@ -444,6 +452,16 @@ 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,
     },
+    /* Intel IGFX OpRegion reg */
+    {
+        .offset     = PCI_INTEL_OPREGION,
+        .size       = 4,
+        .init_val   = 0,
+        .no_wb      = 1,
+        .u.dw.read   = pt_intel_opregion_read,
+        .u.dw.write  = pt_intel_opregion_write,
+        .u.dw.restore  = NULL,
+    },
     {
         .size = 0,
     },
@@ -737,7 +755,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 */
@@ -3006,6 +3024,19 @@ 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)
+{
+    /*
+    ** By default we will trap up to 0x40 in the cfg space.
+    ** If an intel device is pass through we need to trap 0xfc,
+    ** therefore the size should be 0xff.
+    */
+    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)
@@ -4154,6 +4185,22 @@ 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..c61a7fb 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -422,6 +422,8 @@ 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);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..a60673f 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 == 0 )
+        return -1;
+
+    val = igd_guest_opregion;
+#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);
     }

--wac7ysb48OaltWcw
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--wac7ysb48OaltWcw--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:01:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13: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 1RlKHZ-0002uX-QU; Thu, 12 Jan 2012 13:01: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 1RlKHZ-0002uS-1u
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:01:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326373282!8862980!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 15929 invoked from network); 12 Jan 2012 13:01:22 -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; 12 Jan 2012 13:01:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlKHQ-000D8L-OF; Thu, 12 Jan 2012 13:01:20 +0000
Date: Thu, 12 Jan 2012 13:01:20 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112130120.GF47092@ocelot.phlegethon.org>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, olaf@apefle.de, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
	and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:42 -0500 on 11 Jan (1326289372), Andres Lagar-Cavilla wrote:
> Per page operations in the paging, sharing, and access tracking subsystems are
> all implemented with domctls (e.g. a domctl to evict one page, or to share one
> page).
> 
> Under heavy load, the domctl path reveals a lack of scalability. The domctl
> lock serializes dom0's vcpus in the hypervisor. When performing thousands of
> per-page operations on dozens of domains, these vcpus will spin in the
> hypervisor. Beyond the aggressive locking, an added inefficiency of blocking vcpus
> in the domctl lock is that dom0 is prevented from re-scheduling.
> 
> In this proposal we retain the domctl interface for setting up and tearing down
> paging/sharing/mem access for a domain. But we migrate all the per page operations
> to use the memory_op hypercalls (e.g XENMEM_*).
> 
> While we naturally welcome comments on the correctness of the approach, we are also
> concerned about the viability of this API change. With 4.2 coming, this is the right
> time to get an interface right, for the long run.

I'm happy with the API change but I'd like the other users of it to
comment.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:01:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13: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 1RlKHZ-0002uX-QU; Thu, 12 Jan 2012 13:01: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 1RlKHZ-0002uS-1u
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:01:29 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326373282!8862980!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 15929 invoked from network); 12 Jan 2012 13:01:22 -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; 12 Jan 2012 13:01:22 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlKHQ-000D8L-OF; Thu, 12 Jan 2012 13:01:20 +0000
Date: Thu, 12 Jan 2012 13:01:20 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112130120.GF47092@ocelot.phlegethon.org>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, olaf@apefle.de, keir.xen@gmail.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
	and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 13:42 -0500 on 11 Jan (1326289372), Andres Lagar-Cavilla wrote:
> Per page operations in the paging, sharing, and access tracking subsystems are
> all implemented with domctls (e.g. a domctl to evict one page, or to share one
> page).
> 
> Under heavy load, the domctl path reveals a lack of scalability. The domctl
> lock serializes dom0's vcpus in the hypervisor. When performing thousands of
> per-page operations on dozens of domains, these vcpus will spin in the
> hypervisor. Beyond the aggressive locking, an added inefficiency of blocking vcpus
> in the domctl lock is that dom0 is prevented from re-scheduling.
> 
> In this proposal we retain the domctl interface for setting up and tearing down
> paging/sharing/mem access for a domain. But we migrate all the per page operations
> to use the memory_op hypercalls (e.g XENMEM_*).
> 
> While we naturally welcome comments on the correctness of the approach, we are also
> concerned about the viability of this API change. With 4.2 coming, this is the right
> time to get an interface right, for the long run.

I'm happy with the API change but I'd like the other users of it to
comment.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:31:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlKjv-000391-AA; Thu, 12 Jan 2012 13:30:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RlKju-00038t-6c
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:30:46 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326374994!50317970!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3NzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30746 invoked from network); 12 Jan 2012 13:29:55 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 13:29:55 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3C1E02264C
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:30:39 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute2.internal (MEProxy); Thu, 12 Jan 2012 08:30:39 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=22
	9g0nbShFvO2rCVf9TVfFq6tnA=; b=cY1QTeJrMOZVXAt8O2PPYOF/9AxD9Wskqa
	Z0KxLprvId2wfLVWRS47Tl6hHK/ex5w/3lnA8f19xs9sUEXOtmfm5BoDrMei7Pmm
	hzcBhdGIgKWJnDfsstwWiKLqK+QYoh/v4kg492VBB5FAmiKJhUQ/8J7ly/iddBtB
	CTVOYeEjs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=229g
	0nbShFvO2rCVf9TVfFq6tnA=; b=GKfN/O9+CsEvz0tN5i8HA+QpdHP/1G0ojsbm
	cd+BK3HnBEfcitnUTFcoeWjv+nFvkledPilp8cfTR09E3LvOwBfg59zrPPS/KFHp
	RLYDQPCWrgQRyaUwt0eaNW0rBA9HKpmWShTJNoQWajh+Vp9SJzrC0Ubj6B7US/l8
	TSjUOns=
X-Sasl-enc: 5z4hc97JetRkoIh7FCF2q/A8OSx7OsEsxrDm/FaWrE1L 1326375038
Received: from [10.137.2.12] (afmg220.neoplus.adsl.tpnet.pl [178.42.58.220])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 6E2FB8E0246;
	Thu, 12 Jan 2012 08:30:38 -0500 (EST)
Message-ID: <4F0EE07C.2070603@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 14:30:36 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<4F0EC198.9050406@invisiblethingslab.com>
	<20120112121303.GE47092@ocelot.phlegethon.org>
In-Reply-To: <20120112121303.GE47092@ocelot.phlegethon.org>
X-Enigmail-Version: 1.3.4
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] On Dom0 disaggregation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1464406276883005477=="
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)
--===============1464406276883005477==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig7A1A6172AC755654923F9A44"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7A1A6172AC755654923F9A44
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/12/12 13:13, Tim Deegan wrote:
> At 12:18 +0100 on 12 Jan (1326370728), Joanna Rutkowska wrote:
>> On 01/12/12 11:48, Tim Deegan wrote:
>>> I think the point is to protect xenstore from dom0, not dom0 from
>>> xenstore.  With stub-xenstore and driver domains, only the domain
>>> builder and PCIback need to have any privilege, and they can be moved=

>>> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=3D1346278 ,
>>> http://tjd.phlegethon.org/words/sosp11-xoar.html)
>>
>> In order for this to make sense from security point of view, you would=

>> need to deprivilige Dom0.
>=20
> Yep.  That's what Xoar did (or, if you prefer, it moved all dom0's
> components out and then got rid of it).
>=20
>> When considering this task, one should answer
>> the following questions:
>>
>> 1) Who manages the chipset (MCH)?
>=20
> A driver domain that contains PCIback.  It doesn't need general
> privlege (e.g. for scheduler or memory operations).
>=20
>> 2) Who manages the input (keyboard, mouse)
>> 3) Who manages the output (GPU, specifically critical on client system=
s)
>>
>> From the security point of view there is no point of isolating the
>> entities that manage the above between each other, because a compromis=
e
>> of any of those entities leads to full system compromise (again, #3
>> applies to client systems).
>=20
> #2 is really a client-only thing as well.  Serial console input for
> servers is owned directly by the hypervisor.
>=20
>> Now, as you pointed out, we shall probably add another bullet to the
>> list, which is:
>>
>> 4) the xenstored
>>
>> (although I'm not 100% if we couldn't somehow deprivilige xenstored).
>=20
> Yes we could (and Xoar did).  IIRC the only reason it needs privilege i=
s
> to map the rings and that can be sorted out by having the builder
> pre-load a grant entry.
>=20
>> So, we end up with a conclusion that there is no point separating thos=
e
>> 4 functionalists between each other, and so it only make sense to host=

>> them in the same domain. How about we call this domain "Dom0", then? ;=
)
>=20
> So you're saying that the PCIback domain (which owns the chipsets) migh=
t
> as well host Xenstore since either of them could hose the system.
> Maybe so.  In Xoar we had two reasons not to do that:
>  - in some configurations you could shut that domain down after boot
>    (though tbh doing that leads to poor error handling!); and
>  - we were doing other hardening of Xenstore that involved breaking it =

>    up into more than one VM.=20
>=20

But the paper says the PCIBack is destroyed after init -- who manages
the chipset (MCH, ICH, platform power management), then?

Also, if I correctly interpret your architecture, then BlkBack VM must
be trusted, as it has access to the disk, and thus can serve compromised
fs/kernel/initramfs images to VMs, and also modify boot partition to
load compromised Xen on the next boot (unless you use something like
Intel TXT for Xen load). So, what's the reason of separating it from
(the trusted) Xenstored VM?

Unless the kernel/initramfs images (at least for PV domains) come from
some trusted source, not from blkbackend? Then they could contain code
to verify integrity of the fs served from blkbackend. Have you
considered this in your architecture?

Also, if this was a client system, where would you put user input/output
handling?

joanna.


--------------enig7A1A6172AC755654923F9A44
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPDuB8AAoJEDaIqHeRBUM07uIH/0gurG5pMd68qCsAFNW9sx9o
cfFP8RQhX2WLmj7o0Qu5eylzozQNJpeca/Bup/tTXWh8Yj0buuy4BS36y5siAUde
+rlZ9683amnZ0F/dx5pACR49b6RuPGmc0XkSsZJt/SfLVACYpaOABce9Ylu3uZgb
YNVFGEGHNTIqFE4Dp9r6xU3IQF5dgxLO0wIN2mnHGkLNPRCDu7BBj59d7tAIgx+/
xlX/txzcHNWjbjCsSaoqmNYu2/KKWWKb3DK3EJFzHosQs6gv6/UKb0pYQ1FVSd2R
JD8z7934UBK1QcAti1hifym/ah226FevdX6v4KU4wOJHhUl6wFw1OsyV9WzKk2E=
=OaQD
-----END PGP SIGNATURE-----

--------------enig7A1A6172AC755654923F9A44--


--===============1464406276883005477==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1464406276883005477==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:31:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13:31:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlKjv-000391-AA; Thu, 12 Jan 2012 13:30:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joanna@invisiblethingslab.com>) id 1RlKju-00038t-6c
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:30:46 +0000
X-Env-Sender: joanna@invisiblethingslab.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326374994!50317970!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMTY3NzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30746 invoked from network); 12 Jan 2012 13:29:55 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 13:29:55 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 3C1E02264C
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:30:39 -0500 (EST)
Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160])
	by compute2.internal (MEProxy); Thu, 12 Jan 2012 08:30:39 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	invisiblethingslab.com; h=message-id:date:from:mime-version:to
	:cc:subject:references:in-reply-to:content-type; s=mesmtp; bh=22
	9g0nbShFvO2rCVf9TVfFq6tnA=; b=cY1QTeJrMOZVXAt8O2PPYOF/9AxD9Wskqa
	Z0KxLprvId2wfLVWRS47Tl6hHK/ex5w/3lnA8f19xs9sUEXOtmfm5BoDrMei7Pmm
	hzcBhdGIgKWJnDfsstwWiKLqK+QYoh/v4kg492VBB5FAmiKJhUQ/8J7ly/iddBtB
	CTVOYeEjs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type; s=smtpout; bh=229g
	0nbShFvO2rCVf9TVfFq6tnA=; b=GKfN/O9+CsEvz0tN5i8HA+QpdHP/1G0ojsbm
	cd+BK3HnBEfcitnUTFcoeWjv+nFvkledPilp8cfTR09E3LvOwBfg59zrPPS/KFHp
	RLYDQPCWrgQRyaUwt0eaNW0rBA9HKpmWShTJNoQWajh+Vp9SJzrC0Ubj6B7US/l8
	TSjUOns=
X-Sasl-enc: 5z4hc97JetRkoIh7FCF2q/A8OSx7OsEsxrDm/FaWrE1L 1326375038
Received: from [10.137.2.12] (afmg220.neoplus.adsl.tpnet.pl [178.42.58.220])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 6E2FB8E0246;
	Thu, 12 Jan 2012 08:30:38 -0500 (EST)
Message-ID: <4F0EE07C.2070603@invisiblethingslab.com>
Date: Thu, 12 Jan 2012 14:30:36 +0100
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: Tim Deegan <tim@xen.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<4F0EC198.9050406@invisiblethingslab.com>
	<20120112121303.GE47092@ocelot.phlegethon.org>
In-Reply-To: <20120112121303.GE47092@ocelot.phlegethon.org>
X-Enigmail-Version: 1.3.4
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] On Dom0 disaggregation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1464406276883005477=="
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)
--===============1464406276883005477==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig7A1A6172AC755654923F9A44"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7A1A6172AC755654923F9A44
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 01/12/12 13:13, Tim Deegan wrote:
> At 12:18 +0100 on 12 Jan (1326370728), Joanna Rutkowska wrote:
>> On 01/12/12 11:48, Tim Deegan wrote:
>>> I think the point is to protect xenstore from dom0, not dom0 from
>>> xenstore.  With stub-xenstore and driver domains, only the domain
>>> builder and PCIback need to have any privilege, and they can be moved=

>>> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=3D1346278 ,
>>> http://tjd.phlegethon.org/words/sosp11-xoar.html)
>>
>> In order for this to make sense from security point of view, you would=

>> need to deprivilige Dom0.
>=20
> Yep.  That's what Xoar did (or, if you prefer, it moved all dom0's
> components out and then got rid of it).
>=20
>> When considering this task, one should answer
>> the following questions:
>>
>> 1) Who manages the chipset (MCH)?
>=20
> A driver domain that contains PCIback.  It doesn't need general
> privlege (e.g. for scheduler or memory operations).
>=20
>> 2) Who manages the input (keyboard, mouse)
>> 3) Who manages the output (GPU, specifically critical on client system=
s)
>>
>> From the security point of view there is no point of isolating the
>> entities that manage the above between each other, because a compromis=
e
>> of any of those entities leads to full system compromise (again, #3
>> applies to client systems).
>=20
> #2 is really a client-only thing as well.  Serial console input for
> servers is owned directly by the hypervisor.
>=20
>> Now, as you pointed out, we shall probably add another bullet to the
>> list, which is:
>>
>> 4) the xenstored
>>
>> (although I'm not 100% if we couldn't somehow deprivilige xenstored).
>=20
> Yes we could (and Xoar did).  IIRC the only reason it needs privilege i=
s
> to map the rings and that can be sorted out by having the builder
> pre-load a grant entry.
>=20
>> So, we end up with a conclusion that there is no point separating thos=
e
>> 4 functionalists between each other, and so it only make sense to host=

>> them in the same domain. How about we call this domain "Dom0", then? ;=
)
>=20
> So you're saying that the PCIback domain (which owns the chipsets) migh=
t
> as well host Xenstore since either of them could hose the system.
> Maybe so.  In Xoar we had two reasons not to do that:
>  - in some configurations you could shut that domain down after boot
>    (though tbh doing that leads to poor error handling!); and
>  - we were doing other hardening of Xenstore that involved breaking it =

>    up into more than one VM.=20
>=20

But the paper says the PCIBack is destroyed after init -- who manages
the chipset (MCH, ICH, platform power management), then?

Also, if I correctly interpret your architecture, then BlkBack VM must
be trusted, as it has access to the disk, and thus can serve compromised
fs/kernel/initramfs images to VMs, and also modify boot partition to
load compromised Xen on the next boot (unless you use something like
Intel TXT for Xen load). So, what's the reason of separating it from
(the trusted) Xenstored VM?

Unless the kernel/initramfs images (at least for PV domains) come from
some trusted source, not from blkbackend? Then they could contain code
to verify integrity of the fs served from blkbackend. Have you
considered this in your architecture?

Also, if this was a client system, where would you put user input/output
handling?

joanna.


--------------enig7A1A6172AC755654923F9A44
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJPDuB8AAoJEDaIqHeRBUM07uIH/0gurG5pMd68qCsAFNW9sx9o
cfFP8RQhX2WLmj7o0Qu5eylzozQNJpeca/Bup/tTXWh8Yj0buuy4BS36y5siAUde
+rlZ9683amnZ0F/dx5pACR49b6RuPGmc0XkSsZJt/SfLVACYpaOABce9Ylu3uZgb
YNVFGEGHNTIqFE4Dp9r6xU3IQF5dgxLO0wIN2mnHGkLNPRCDu7BBj59d7tAIgx+/
xlX/txzcHNWjbjCsSaoqmNYu2/KKWWKb3DK3EJFzHosQs6gv6/UKb0pYQ1FVSd2R
JD8z7934UBK1QcAti1hifym/ah226FevdX6v4KU4wOJHhUl6wFw1OsyV9WzKk2E=
=OaQD
-----END PGP SIGNATURE-----

--------------enig7A1A6172AC755654923F9A44--


--===============1464406276883005477==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1464406276883005477==--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:41:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlKtD-0003Mh-La; Thu, 12 Jan 2012 13:40:23 +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 1RlKtC-0003Mc-1p
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:40:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326375615!10567587!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31022 invoked from network); 12 Jan 2012 13:40:15 -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;
	12 Jan 2012 13:40:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9970825"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 13:40: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, 12 Jan 2012 13:40:11 +0000
Date: Thu, 12 Jan 2012 13:40:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323784748.20077.304.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201121222120.3150@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>
	<1323784748.20077.304.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 Tue, 13 Dec 2011, Ian Campbell wrote:
> 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.

good point

> > [...]
> 
> > @@ -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. 

right, I'll handle that

> > [...]
> 
> >  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.

this pthread_setspecific call, with the NULL paramter, can only fail if
the key is invalid, so I think that we don't need to handle that error.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:41:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13:41:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlKtD-0003Mh-La; Thu, 12 Jan 2012 13:40:23 +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 1RlKtC-0003Mc-1p
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:40:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326375615!10567587!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31022 invoked from network); 12 Jan 2012 13:40:15 -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;
	12 Jan 2012 13:40:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9970825"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 13:40: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, 12 Jan 2012 13:40:11 +0000
Date: Thu, 12 Jan 2012 13:40:35 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1323784748.20077.304.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201121222120.3150@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>
	<1323784748.20077.304.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 Tue, 13 Dec 2011, Ian Campbell wrote:
> 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.

good point

> > [...]
> 
> > @@ -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. 

right, I'll handle that

> > [...]
> 
> >  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.

this pthread_setspecific call, with the NULL paramter, can only fail if
the key is invalid, so I think that we don't need to handle that error.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:49:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13: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 1RlL1N-0003Wr-MQ; Thu, 12 Jan 2012 13:48:49 +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 1RlL1L-0003Wj-Ed
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:48:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326376121!2902004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 666 invoked from network); 12 Jan 2012 13:48:41 -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;
	12 Jan 2012 13:48:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9971012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 13:48:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Jan 2012 13:48:41 +0000
Date: Thu, 12 Jan 2012 13:49:05 +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: <1326367684.17210.245.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201121229040.3150@kaball-desktop>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
	<1326367684.17210.245.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 07/10] 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, 12 Jan 2012, Ian Campbell wrote:
> > I still prefer the approach prototyped in
> > http://marc.info/?l=xen-devel&m=132371797519877
> 
> I pointed out some issues with this in
> http://marc.info/?l=xen-devel&m=132378496608354&w=2 which have gone
> unanswered.

I was asked by Ian to wait for his next version and so I did.


> In particular error handling for the pthread_setspecific in
> libxl__free_all seems pretty nasty to me since you would be introducing
> a new failure path at the end of pretty much every libxl function. Worse
> it is after the actual action of each function is otherwise complete so
> you may end up having to undo stuff. I think it is going to be a lot of
> work to fix all of those up properly.
> 
> Having frequently used pro/epilogue code (especially epilogue) which
> cannot fail seems much simpler in general to me.

The epilogue is not a problem because pthread_setspecific could only
fail if the key is invalid so we don't need to handle that error.
However the prologue still needs error handling.
Personally I don't think there is anything wrong with a GC_INIT that can
fail. We can decide whether to handle the error within the macro (like
it is done now in the new updated patch) or outside the macro. Both are
fine by me.


diff -r 5b2676ac1321 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Jan 12 13:44:16 2012 +0000
@@ -60,6 +60,12 @@ int libxl_ctx_alloc(libxl_ctx **pctx, in
      * 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);
@@ -93,6 +99,8 @@ 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);
+    if (pthread_key_delete(ctx->tls_key) < 0)
+        return ERROR_FAIL;
     free(ctx);
     return 0;
 }
diff -r 5b2676ac1321 tools/libxl/libxl_internal.c
--- a/tools/libxl/libxl_internal.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_internal.c	Thu Jan 12 13:44:16 2012 +0000
@@ -17,6 +17,7 @@
 
 #include <stdio.h>
 
+#include <pthread.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
@@ -61,11 +62,38 @@ int libxl__ptr_add(libxl__gc *gc, void *
     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->nested = 0;
+        gc->owner = ctx;
+        gc->nested = 1;
+        if (pthread_setspecific(ctx->tls_key, gc) < 0) {
+            free(gc);
+            return NULL;
+        }
+    } 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;
@@ -74,6 +102,8 @@ void libxl__free_all(libxl__gc *gc)
     free(gc->alloc_ptrs);
     gc->alloc_ptrs = 0;
     gc->alloc_maxsize = 0;
+    pthread_setspecific(CTX->tls_key, NULL);
+    free(gc);
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff -r 5b2676ac1321 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Jan 12 13:44:16 2012 +0000
@@ -98,6 +98,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.
        *
@@ -145,9 +147,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;
@@ -721,7 +723,8 @@ libxl__device_model_version_running(libx
  * 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)
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:49:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13: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 1RlL1N-0003Wr-MQ; Thu, 12 Jan 2012 13:48:49 +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 1RlL1L-0003Wj-Ed
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:48:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326376121!2902004!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 666 invoked from network); 12 Jan 2012 13:48:41 -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;
	12 Jan 2012 13:48:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9971012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 13:48:41 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Jan 2012 13:48:41 +0000
Date: Thu, 12 Jan 2012 13:49:05 +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: <1326367684.17210.245.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201121229040.3150@kaball-desktop>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
	<1326367684.17210.245.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 07/10] 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, 12 Jan 2012, Ian Campbell wrote:
> > I still prefer the approach prototyped in
> > http://marc.info/?l=xen-devel&m=132371797519877
> 
> I pointed out some issues with this in
> http://marc.info/?l=xen-devel&m=132378496608354&w=2 which have gone
> unanswered.

I was asked by Ian to wait for his next version and so I did.


> In particular error handling for the pthread_setspecific in
> libxl__free_all seems pretty nasty to me since you would be introducing
> a new failure path at the end of pretty much every libxl function. Worse
> it is after the actual action of each function is otherwise complete so
> you may end up having to undo stuff. I think it is going to be a lot of
> work to fix all of those up properly.
> 
> Having frequently used pro/epilogue code (especially epilogue) which
> cannot fail seems much simpler in general to me.

The epilogue is not a problem because pthread_setspecific could only
fail if the key is invalid so we don't need to handle that error.
However the prologue still needs error handling.
Personally I don't think there is anything wrong with a GC_INIT that can
fail. We can decide whether to handle the error within the macro (like
it is done now in the new updated patch) or outside the macro. Both are
fine by me.


diff -r 5b2676ac1321 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl.c	Thu Jan 12 13:44:16 2012 +0000
@@ -60,6 +60,12 @@ int libxl_ctx_alloc(libxl_ctx **pctx, in
      * 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);
@@ -93,6 +99,8 @@ 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);
+    if (pthread_key_delete(ctx->tls_key) < 0)
+        return ERROR_FAIL;
     free(ctx);
     return 0;
 }
diff -r 5b2676ac1321 tools/libxl/libxl_internal.c
--- a/tools/libxl/libxl_internal.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_internal.c	Thu Jan 12 13:44:16 2012 +0000
@@ -17,6 +17,7 @@
 
 #include <stdio.h>
 
+#include <pthread.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
@@ -61,11 +62,38 @@ int libxl__ptr_add(libxl__gc *gc, void *
     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->nested = 0;
+        gc->owner = ctx;
+        gc->nested = 1;
+        if (pthread_setspecific(ctx->tls_key, gc) < 0) {
+            free(gc);
+            return NULL;
+        }
+    } 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;
@@ -74,6 +102,8 @@ void libxl__free_all(libxl__gc *gc)
     free(gc->alloc_ptrs);
     gc->alloc_ptrs = 0;
     gc->alloc_maxsize = 0;
+    pthread_setspecific(CTX->tls_key, NULL);
+    free(gc);
 }
 
 void *libxl__zalloc(libxl__gc *gc, int bytes)
diff -r 5b2676ac1321 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Thu Jan 12 13:44:16 2012 +0000
@@ -98,6 +98,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.
        *
@@ -145,9 +147,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;
@@ -721,7 +723,8 @@ libxl__device_model_version_running(libx
  * 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)
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:53:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlL5m-0003eK-Ce; Thu, 12 Jan 2012 13:53:22 +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 1RlL5k-0003e7-KA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:53:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326376393!8830412!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31697 invoked from network); 12 Jan 2012 13:53:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 12 Jan 2012 13:53:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326376393; l=2969;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=X6Rg3zN9hR3a7o+4QJ3b3HFlrL4=;
	b=gBn4hnDq4DE7i3Pe2Nc1am51QyjsWvTw95ImUgAmeM4lKXJEdwVluC35lHGfFtCSRyj
	HNHodTZm568iNSWwNIc9CNieIbvN7+gMrKD8mqP646XF2U5HpTCnQC72WXYgBxvejsHAc
	j2AK79NsbRXrQDo5ZNSGWu0NCYfGonem81o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (fruni mo6) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z02699o0CDYeUs ;
	Thu, 12 Jan 2012 14:52:52 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CB15318634;
	Thu, 12 Jan 2012 14:52:51 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 94f71dded5ab5a31224b852aac6b238b590b7b25
Message-Id: <94f71dded5ab5a31224b.1326376371@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 12 Jan 2012 14:52:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326374876 -3600
# Node ID 94f71dded5ab5a31224b852aac6b238b590b7b25
# Parent  223e8ad4c7557960e29a7c294bb94723b2cd7f09
xenalyze: add missing casts to fix 64bit build

xenalyze.c: In function 'hvm_mmio_summary':
xenalyze.c:3728: error: cast from pointer to integer of different size
xenalyze.c: In function 'hvm_mmio_assist_postprocess':
xenalyze.c:3743: error: cast to pointer from integer of different size
xenalyze.c:3747: error: cast to pointer from integer of different size
xenalyze.c:3759: error: cast to pointer from integer of different size
xenalyze.c: In function 'hvm_cr_write_summary':
xenalyze.c:4251: error: cast from pointer to integer of different size
xenalyze.c: In function 'hvm_generic_summary':
xenalyze.c:4800: error: cast from pointer to integer of different size
xenalyze.c: In function 'hvm_generic_postprocess':
xenalyze.c:4871: error: cast to pointer from integer of different size
make: *** [xenalyze] Error 1

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 223e8ad4c755 -r 94f71dded5ab xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -3725,7 +3725,7 @@ void enumerate_mmio(struct hvm_data *h)
 
 void hvm_mmio_summary(struct hvm_data *h, void *data)
 {
-    int reason=(int)data;
+    int reason=(long)data;
 
     PRINT_SUMMARY(h->summary.mmio[reason],
                   "   mmio ");
@@ -3740,11 +3740,11 @@ void hvm_mmio_assist_postprocess(struct 
     case VMEXIT_NPF:
     case EXIT_REASON_EPT_VIOLATION:
         reason=NONPF_MMIO_NPF;
-        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
         break;
     case EXIT_REASON_APIC_ACCESS:
         reason=NONPF_MMIO_APIC;
-        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
         break;
     default:
     {
@@ -3756,7 +3756,7 @@ void hvm_mmio_assist_postprocess(struct 
             warned=1;
         }
         reason=NONPF_MMIO_UNKNOWN;
-        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
         break;
     }
     }
@@ -4248,7 +4248,7 @@ void hvm_cr3_write_summary(struct hvm_da
 
 void hvm_cr_write_summary(struct hvm_data *h, void *data)
 {
-    int cr=(int)data;
+    int cr=(long)data;
 
     PRINT_SUMMARY(h->summary.cr_write[cr],
                   "   cr%d ", cr);
@@ -4797,7 +4797,7 @@ void hvm_rdtsc_process(struct record_inf
 
 void hvm_generic_summary(struct hvm_data *h, void *data)
 {
-    int evt = (int)data;
+    int evt = (long)data;
 
     assert(evt < HVM_EVENT_HANDLER_MAX);
 
@@ -4868,7 +4868,7 @@ void hvm_generic_postprocess(struct hvm_
         else
         {
             int ret;
-            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)evt)))
+            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)(long)evt)))
                 fprintf(stderr, "%s: hvm_set_summary_handler returned %d\n",
                         __func__, ret);
             registered[evt]=h->exit_reason+1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:53:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13:53:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlL5m-0003eK-Ce; Thu, 12 Jan 2012 13:53:22 +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 1RlL5k-0003e7-KA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:53:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326376393!8830412!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31697 invoked from network); 12 Jan 2012 13:53:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-2.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 12 Jan 2012 13:53:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326376393; l=2969;
	s=domk; d=aepfle.de;
	h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
	Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=X6Rg3zN9hR3a7o+4QJ3b3HFlrL4=;
	b=gBn4hnDq4DE7i3Pe2Nc1am51QyjsWvTw95ImUgAmeM4lKXJEdwVluC35lHGfFtCSRyj
	HNHodTZm568iNSWwNIc9CNieIbvN7+gMrKD8mqP646XF2U5HpTCnQC72WXYgBxvejsHAc
	j2AK79NsbRXrQDo5ZNSGWu0NCYfGonem81o=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (fruni mo6) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z02699o0CDYeUs ;
	Thu, 12 Jan 2012 14:52:52 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id CB15318634;
	Thu, 12 Jan 2012 14:52:51 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 94f71dded5ab5a31224b852aac6b238b590b7b25
Message-Id: <94f71dded5ab5a31224b.1326376371@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 12 Jan 2012 14:52:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit 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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326374876 -3600
# Node ID 94f71dded5ab5a31224b852aac6b238b590b7b25
# Parent  223e8ad4c7557960e29a7c294bb94723b2cd7f09
xenalyze: add missing casts to fix 64bit build

xenalyze.c: In function 'hvm_mmio_summary':
xenalyze.c:3728: error: cast from pointer to integer of different size
xenalyze.c: In function 'hvm_mmio_assist_postprocess':
xenalyze.c:3743: error: cast to pointer from integer of different size
xenalyze.c:3747: error: cast to pointer from integer of different size
xenalyze.c:3759: error: cast to pointer from integer of different size
xenalyze.c: In function 'hvm_cr_write_summary':
xenalyze.c:4251: error: cast from pointer to integer of different size
xenalyze.c: In function 'hvm_generic_summary':
xenalyze.c:4800: error: cast from pointer to integer of different size
xenalyze.c: In function 'hvm_generic_postprocess':
xenalyze.c:4871: error: cast to pointer from integer of different size
make: *** [xenalyze] Error 1

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 223e8ad4c755 -r 94f71dded5ab xenalyze.c
--- a/xenalyze.c
+++ b/xenalyze.c
@@ -3725,7 +3725,7 @@ void enumerate_mmio(struct hvm_data *h)
 
 void hvm_mmio_summary(struct hvm_data *h, void *data)
 {
-    int reason=(int)data;
+    int reason=(long)data;
 
     PRINT_SUMMARY(h->summary.mmio[reason],
                   "   mmio ");
@@ -3740,11 +3740,11 @@ void hvm_mmio_assist_postprocess(struct 
     case VMEXIT_NPF:
     case EXIT_REASON_EPT_VIOLATION:
         reason=NONPF_MMIO_NPF;
-        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
         break;
     case EXIT_REASON_APIC_ACCESS:
         reason=NONPF_MMIO_APIC;
-        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
         break;
     default:
     {
@@ -3756,7 +3756,7 @@ void hvm_mmio_assist_postprocess(struct 
             warned=1;
         }
         reason=NONPF_MMIO_UNKNOWN;
-        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
+        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
         break;
     }
     }
@@ -4248,7 +4248,7 @@ void hvm_cr3_write_summary(struct hvm_da
 
 void hvm_cr_write_summary(struct hvm_data *h, void *data)
 {
-    int cr=(int)data;
+    int cr=(long)data;
 
     PRINT_SUMMARY(h->summary.cr_write[cr],
                   "   cr%d ", cr);
@@ -4797,7 +4797,7 @@ void hvm_rdtsc_process(struct record_inf
 
 void hvm_generic_summary(struct hvm_data *h, void *data)
 {
-    int evt = (int)data;
+    int evt = (long)data;
 
     assert(evt < HVM_EVENT_HANDLER_MAX);
 
@@ -4868,7 +4868,7 @@ void hvm_generic_postprocess(struct hvm_
         else
         {
             int ret;
-            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)evt)))
+            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)(long)evt)))
                 fprintf(stderr, "%s: hvm_set_summary_handler returned %d\n",
                         __func__, ret);
             registered[evt]=h->exit_reason+1;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:54:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13: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 1RlL6U-0003gm-Qa; Thu, 12 Jan 2012 13:54:06 +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 1RlL6T-0003gO-79
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:54:05 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326376437!10625379!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19721 invoked from network); 12 Jan 2012 13:53:58 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE002.bigfish.com) (65.55.88.11)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Jan 2012 13:53:58 -0000
Received: from mail83-tx2-R.bigfish.com (10.9.14.252) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Jan 2012 13:53:56 +0000
Received: from mail83-tx2 (localhost [127.0.0.1])	by mail83-tx2-R.bigfish.com
	(Postfix) with ESMTP id 78F703C03C6;
	Thu, 12 Jan 2012 13:53:56 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1ahc1bh668h839h61h)
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 mail83-tx2 (localhost.localdomain [127.0.0.1]) by mail83-tx2
	(MessageSwitch) id 1326376380351773_31045;
	Thu, 12 Jan 2012 13:53:00 +0000 (UTC)
Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.242])	by
	mail83-tx2.bigfish.com (Postfix) with ESMTP id 4ED37300042;
	Thu, 12 Jan 2012 13:53:00 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Jan 2012 13:53:00 +0000
X-WSS-ID: 0LXOUK6-02-GYR-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 276BEC807A;	Thu, 12 Jan 2012 07:52:53 -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, 12 Jan 2012 07:53:13 -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;
	Thu, 12 Jan 2012 07:52:58 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Jan 2012
	08:52:57 -0500
Message-ID: <4F0EE5B8.30407@amd.com>
Date: Thu, 12 Jan 2012 14:52:56 +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: <4F0EE2C2020000780006C18C@nat28.tlf.novell.com>
In-Reply-To: <4F0EE2C2020000780006C18C@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: properly define size_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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/12 13:40, Jan Beulich wrote:
> Having it defined unilaterally as 'unsigned long' got me surprised
> recently when I tried to use the 'z' printk type modifier, as that is
> expected by the compiler to be used only on the type it knows size_t
> is supposed to have.
>
> Generally the compiler provides a construct to do this, so use it when
> available.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>

Acked-by: Christoph Egger <Christoph.Egger@amd.com>

>
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -183,10 +183,10 @@ static int get_next_ucode_from_buffer_am
>       struct microcode_amd *mc_amd,
>       const void *buf,
>       size_t bufsize,
> -    unsigned long *offset)
> +    size_t *offset)
>   {
>       const uint8_t *bufp = buf;
> -    unsigned long off;
> +    size_t off;
>       const struct mpbhdr *mpbuf;
>
>       off = *offset;
> @@ -203,7 +203,7 @@ static int get_next_ucode_from_buffer_am
>           return -EINVAL;
>       }
>
> -    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
> +    printk(KERN_DEBUG "microcode: size %zu, block size %u, offset %zu\n",
>              bufsize, mpbuf->len, off);
>
>       if ( (off + mpbuf->len)>  bufsize )
> @@ -234,7 +234,7 @@ static int get_next_ucode_from_buffer_am
>   static int install_equiv_cpu_table(
>       struct microcode_amd *mc_amd,
>       const uint32_t *buf,
> -    unsigned long *offset)
> +    size_t *offset)
>   {
>       const struct mpbhdr *mpbuf = (const struct mpbhdr *)&buf[1];
>
> --- a/xen/include/asm-x86/types.h
> +++ b/xen/include/asm-x86/types.h
> @@ -47,7 +47,13 @@ typedef unsigned long paddr_t;
>   #define PRIpaddr "016lx"
>   #endif
>
> +#if defined(__SIZE_TYPE__)
> +typedef __SIZE_TYPE__ size_t;
> +#elif defined(__i386__)
> +typedef unsigned int size_t;
> +#else
>   typedef unsigned long size_t;
> +#endif
>
>   typedef char bool_t;
>   #define test_and_set_bool(b)   xchg(&(b), 1)
>
>
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 13:54:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 13: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 1RlL6U-0003gm-Qa; Thu, 12 Jan 2012 13:54:06 +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 1RlL6T-0003gO-79
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 13:54:05 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326376437!10625379!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19721 invoked from network); 12 Jan 2012 13:53:58 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE002.bigfish.com) (65.55.88.11)
	by server-4.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	12 Jan 2012 13:53:58 -0000
Received: from mail83-tx2-R.bigfish.com (10.9.14.252) by
	TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Jan 2012 13:53:56 +0000
Received: from mail83-tx2 (localhost [127.0.0.1])	by mail83-tx2-R.bigfish.com
	(Postfix) with ESMTP id 78F703C03C6;
	Thu, 12 Jan 2012 13:53:56 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1ahc1bh668h839h61h)
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 mail83-tx2 (localhost.localdomain [127.0.0.1]) by mail83-tx2
	(MessageSwitch) id 1326376380351773_31045;
	Thu, 12 Jan 2012 13:53:00 +0000 (UTC)
Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.242])	by
	mail83-tx2.bigfish.com (Postfix) with ESMTP id 4ED37300042;
	Thu, 12 Jan 2012 13:53:00 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server id
	14.1.225.23; Thu, 12 Jan 2012 13:53:00 +0000
X-WSS-ID: 0LXOUK6-02-GYR-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 276BEC807A;	Thu, 12 Jan 2012 07:52:53 -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, 12 Jan 2012 07:53:13 -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;
	Thu, 12 Jan 2012 07:52:58 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Jan 2012
	08:52:57 -0500
Message-ID: <4F0EE5B8.30407@amd.com>
Date: Thu, 12 Jan 2012 14:52:56 +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: <4F0EE2C2020000780006C18C@nat28.tlf.novell.com>
In-Reply-To: <4F0EE2C2020000780006C18C@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86: properly define size_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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/12 13:40, Jan Beulich wrote:
> Having it defined unilaterally as 'unsigned long' got me surprised
> recently when I tried to use the 'z' printk type modifier, as that is
> expected by the compiler to be used only on the type it knows size_t
> is supposed to have.
>
> Generally the compiler provides a construct to do this, so use it when
> available.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>

Acked-by: Christoph Egger <Christoph.Egger@amd.com>

>
> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -183,10 +183,10 @@ static int get_next_ucode_from_buffer_am
>       struct microcode_amd *mc_amd,
>       const void *buf,
>       size_t bufsize,
> -    unsigned long *offset)
> +    size_t *offset)
>   {
>       const uint8_t *bufp = buf;
> -    unsigned long off;
> +    size_t off;
>       const struct mpbhdr *mpbuf;
>
>       off = *offset;
> @@ -203,7 +203,7 @@ static int get_next_ucode_from_buffer_am
>           return -EINVAL;
>       }
>
> -    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
> +    printk(KERN_DEBUG "microcode: size %zu, block size %u, offset %zu\n",
>              bufsize, mpbuf->len, off);
>
>       if ( (off + mpbuf->len)>  bufsize )
> @@ -234,7 +234,7 @@ static int get_next_ucode_from_buffer_am
>   static int install_equiv_cpu_table(
>       struct microcode_amd *mc_amd,
>       const uint32_t *buf,
> -    unsigned long *offset)
> +    size_t *offset)
>   {
>       const struct mpbhdr *mpbuf = (const struct mpbhdr *)&buf[1];
>
> --- a/xen/include/asm-x86/types.h
> +++ b/xen/include/asm-x86/types.h
> @@ -47,7 +47,13 @@ typedef unsigned long paddr_t;
>   #define PRIpaddr "016lx"
>   #endif
>
> +#if defined(__SIZE_TYPE__)
> +typedef __SIZE_TYPE__ size_t;
> +#elif defined(__i386__)
> +typedef unsigned int size_t;
> +#else
>   typedef unsigned long size_t;
> +#endif
>
>   typedef char bool_t;
>   #define test_and_set_bool(b)   xchg(&(b), 1)
>
>
>


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:00:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLCT-00043H-Nx; Thu, 12 Jan 2012 14:00:17 +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 1RlLCS-000439-5l
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:00:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326376809!8857538!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21904 invoked from network); 12 Jan 2012 14:00:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 12 Jan 2012 14:00:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326376805; l=1898;
	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=iwLP6NNElhgS3Dp2domSNTr3pT0=;
	b=URBt5PRGnUJAN0s74TUjSLR4nMZqwgYIlGjI3hfr6zuk1jHprDIV3FOGOnfw00AZilE
	k+GvE2YiSeku/ZZl18zW62AMLgARCU3ZtOCa0H1wzH61hRuWm/eJ0TjwK2JYhk7Ucdrwy
	FaIw/JuKBpOFNT8fd9upg7XTGABO4ZUu2jQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (klopstock mo58) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p00b3fo0CCfKHw ;
	Thu, 12 Jan 2012 14:59:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 279AC18637; Thu, 12 Jan 2012 14:59:46 +0100 (CET)
Date: Thu, 12 Jan 2012 14:59:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112135945.GA8324@aepfle.de>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
	<63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <63e491f50b2d490e00741aaffbc6df80.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 Wed, Jan 11, Andres Lagar-Cavilla wrote:

> > mem_event: use wait queue when ring is full
> >
> > This change is based on an idea/patch from Adin Scannell.
> 
> Olaf,
> thanks for the post. We'll have to nack this patch in its current form. It
> hard reboots our host during our testing.

Thats very unfortunate. I have seen such unexpected reboots myself a few
weeks ago. I suspect they were caused by an incorrect debug change which
I had on top of my waitqueue changes. Also the fixes Keir provided a few
weeks ago may have helped.

Is it an otherwise unmodified xen-unstable build, or do you use other
patches as well? Whats your environment and workload anyway in dom0 and
domU?

It would be very good to know why the reboots happen. Perhaps such
failures can not be debugged without special hardware, or a detailed
code review.


I just tested an otherwise unmodified xen-unstable build and did not
encounter reboots while ballooning a single 2G guest up and down. The
guest did just hang after a few iterations, most likely because v7 of my
patch again (or still?) has the math wrong in the ring accounting. I
will check what the issue is. I think v6 was ok in that respect, but I
will double check that older version as well.


> What we did is take this patch, amalgamate it with some bits from our ring
> management approach. We're ready to submit that, along with a description
> of how we test it. It works for us, and it involves wait queue's for
> corner cases.

Now if the patch you just sent out uses wait queues as well, and using
wait queues causes sudden host reboots for reasons not yet known, how is
your patch any better other that the reboots dont appear to happen
anymore?

I did not use anything but paging for testing, perhaps I should also run
some access tests. How should I use tools/tests/xen-access/xen-access.c?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:00:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:00:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLCT-00043H-Nx; Thu, 12 Jan 2012 14:00:17 +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 1RlLCS-000439-5l
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:00:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326376809!8857538!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21904 invoked from network); 12 Jan 2012 14:00:10 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 12 Jan 2012 14:00:10 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326376805; l=1898;
	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=iwLP6NNElhgS3Dp2domSNTr3pT0=;
	b=URBt5PRGnUJAN0s74TUjSLR4nMZqwgYIlGjI3hfr6zuk1jHprDIV3FOGOnfw00AZilE
	k+GvE2YiSeku/ZZl18zW62AMLgARCU3ZtOCa0H1wzH61hRuWm/eJ0TjwK2JYhk7Ucdrwy
	FaIw/JuKBpOFNT8fd9upg7XTGABO4ZUu2jQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (klopstock mo58) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p00b3fo0CCfKHw ;
	Thu, 12 Jan 2012 14:59:46 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 279AC18637; Thu, 12 Jan 2012 14:59:46 +0100 (CET)
Date: Thu, 12 Jan 2012 14:59:46 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112135945.GA8324@aepfle.de>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
	<63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <63e491f50b2d490e00741aaffbc6df80.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 Wed, Jan 11, Andres Lagar-Cavilla wrote:

> > mem_event: use wait queue when ring is full
> >
> > This change is based on an idea/patch from Adin Scannell.
> 
> Olaf,
> thanks for the post. We'll have to nack this patch in its current form. It
> hard reboots our host during our testing.

Thats very unfortunate. I have seen such unexpected reboots myself a few
weeks ago. I suspect they were caused by an incorrect debug change which
I had on top of my waitqueue changes. Also the fixes Keir provided a few
weeks ago may have helped.

Is it an otherwise unmodified xen-unstable build, or do you use other
patches as well? Whats your environment and workload anyway in dom0 and
domU?

It would be very good to know why the reboots happen. Perhaps such
failures can not be debugged without special hardware, or a detailed
code review.


I just tested an otherwise unmodified xen-unstable build and did not
encounter reboots while ballooning a single 2G guest up and down. The
guest did just hang after a few iterations, most likely because v7 of my
patch again (or still?) has the math wrong in the ring accounting. I
will check what the issue is. I think v6 was ok in that respect, but I
will double check that older version as well.


> What we did is take this patch, amalgamate it with some bits from our ring
> management approach. We're ready to submit that, along with a description
> of how we test it. It works for us, and it involves wait queue's for
> corner cases.

Now if the patch you just sent out uses wait queues as well, and using
wait queues causes sudden host reboots for reasons not yet known, how is
your patch any better other that the reboots dont appear to happen
anymore?

I did not use anything but paging for testing, perhaps I should also run
some access tests. How should I use tools/tests/xen-access/xen-access.c?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:07:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLIt-0004E1-Jg; Thu, 12 Jan 2012 14:06:55 +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 1RlLIs-0004Dn-4i
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:06:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326377207!10633249!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,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1045 invoked from network); 12 Jan 2012 14:06:48 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 14:06:48 -0000
Received: by wibhj8 with SMTP id hj8so846171wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:06:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=uJZVnsltuGUmFv4uqJ26vvJxoTpTbrdSks3b5L2/1yQ=;
	b=ZYz87trUWdLw/KvsKee1qE1WbWbcpNMGT505J18uYvttwuSYDJmXEtOOe37O2jMVok
	TRCNr0OplwOnE9LPCICT0Ys7EVtOjF+IkR/rlDdHiVS3WGYQMx7a8rPJWI2IxNY/73Xh
	nU0y8tdIl2B0mNSUgyGCj4uGpiWoe1kkc9BEI=
Received: by 10.180.20.69 with SMTP id l5mr481893wie.19.1326377207656;
	Thu, 12 Jan 2012 06:06:47 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id v28sm5847868wbo.18.2012.01.12.06.06.46
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 06:06:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 14:06:43 +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: <CB349973.288E2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: move and fold certain type property
	definitions
Thread-Index: AczRM2l5DIB8RZqX+EqbsQrMsPOpYA==
In-Reply-To: <4F0EE1EC020000780006C16D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: move and fold certain type property
 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/01/2012 12:36, "Jan Beulich" <JBeulich@suse.com> wrote:

> Not only is it less code to have them consolidated, it also permits
> their use virtually everywhere (since config.h is required to be
> included everywhere. (Shouldn't we, btw, follow Linux and remove the
> explicit inclusion in favor of command line enforced one?)

Yes, could do.

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -8,11 +8,16 @@
>  #define __X86_CONFIG_H__
>  
>  #if defined(__x86_64__)
> +# define LONG_BYTEORDER 3
>  # define CONFIG_PAGING_LEVELS 4
>  #else
> +# define LONG_BYTEORDER 2
>  # define CONFIG_PAGING_LEVELS 3
>  #endif
>  
> +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
> +#define BITS_PER_LONG (BYTES_PER_LONG << 3)
> +
>  #define CONFIG_X86 1
>  #define CONFIG_X86_HT 1
>  #define CONFIG_PAGING_ASSISTANCE 1
> --- a/xen/include/asm-x86/types.h
> +++ b/xen/include/asm-x86/types.h
> @@ -55,14 +55,4 @@ typedef char bool_t;
>  
>  #endif /* __ASSEMBLY__ */
>  
> -#if defined(__i386__)
> -#define BITS_PER_LONG 32
> -#define BYTES_PER_LONG 4
> -#define LONG_BYTEORDER 2
> -#elif defined(__x86_64__)
> -#define BITS_PER_LONG 64
> -#define BYTES_PER_LONG 8
> -#define LONG_BYTEORDER 3
> -#endif
> -
>  #endif /* __X86_TYPES_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 Thu Jan 12 14:07:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:07:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLIt-0004E1-Jg; Thu, 12 Jan 2012 14:06:55 +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 1RlLIs-0004Dn-4i
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:06:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326377207!10633249!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,UPPERCASE_25_50,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1045 invoked from network); 12 Jan 2012 14:06:48 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 14:06:48 -0000
Received: by wibhj8 with SMTP id hj8so846171wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:06:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=uJZVnsltuGUmFv4uqJ26vvJxoTpTbrdSks3b5L2/1yQ=;
	b=ZYz87trUWdLw/KvsKee1qE1WbWbcpNMGT505J18uYvttwuSYDJmXEtOOe37O2jMVok
	TRCNr0OplwOnE9LPCICT0Ys7EVtOjF+IkR/rlDdHiVS3WGYQMx7a8rPJWI2IxNY/73Xh
	nU0y8tdIl2B0mNSUgyGCj4uGpiWoe1kkc9BEI=
Received: by 10.180.20.69 with SMTP id l5mr481893wie.19.1326377207656;
	Thu, 12 Jan 2012 06:06:47 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id v28sm5847868wbo.18.2012.01.12.06.06.46
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 06:06:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 14:06:43 +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: <CB349973.288E2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: move and fold certain type property
	definitions
Thread-Index: AczRM2l5DIB8RZqX+EqbsQrMsPOpYA==
In-Reply-To: <4F0EE1EC020000780006C16D@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: move and fold certain type property
 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/01/2012 12:36, "Jan Beulich" <JBeulich@suse.com> wrote:

> Not only is it less code to have them consolidated, it also permits
> their use virtually everywhere (since config.h is required to be
> included everywhere. (Shouldn't we, btw, follow Linux and remove the
> explicit inclusion in favor of command line enforced one?)

Yes, could do.

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -8,11 +8,16 @@
>  #define __X86_CONFIG_H__
>  
>  #if defined(__x86_64__)
> +# define LONG_BYTEORDER 3
>  # define CONFIG_PAGING_LEVELS 4
>  #else
> +# define LONG_BYTEORDER 2
>  # define CONFIG_PAGING_LEVELS 3
>  #endif
>  
> +#define BYTES_PER_LONG (1 << LONG_BYTEORDER)
> +#define BITS_PER_LONG (BYTES_PER_LONG << 3)
> +
>  #define CONFIG_X86 1
>  #define CONFIG_X86_HT 1
>  #define CONFIG_PAGING_ASSISTANCE 1
> --- a/xen/include/asm-x86/types.h
> +++ b/xen/include/asm-x86/types.h
> @@ -55,14 +55,4 @@ typedef char bool_t;
>  
>  #endif /* __ASSEMBLY__ */
>  
> -#if defined(__i386__)
> -#define BITS_PER_LONG 32
> -#define BYTES_PER_LONG 4
> -#define LONG_BYTEORDER 2
> -#elif defined(__x86_64__)
> -#define BITS_PER_LONG 64
> -#define BYTES_PER_LONG 8
> -#define LONG_BYTEORDER 3
> -#endif
> -
>  #endif /* __X86_TYPES_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 Thu Jan 12 14:07:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:07:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLJK-0004GA-D4; Thu, 12 Jan 2012 14:07:22 +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 1RlLJI-0004Fu-Rr
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:07:21 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326377234!8858604!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13858 invoked from network); 12 Jan 2012 14:07:14 -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;
	12 Jan 2012 14:07:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9971621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 14:07:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Jan 2012 14:07:13 +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 1RlLJA-0001yP-Tv;
	Thu, 12 Jan 2012 14:07:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RlLJ4-0007Wj-GP;
	Thu, 12 Jan 2012 14:07:06 +0000
From: <y@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 12 Jan 2012 14:07:05 +0000
Message-ID: <1326377225-28900-1-git-send-email-y>
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>
Subject: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config 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>
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


Expose more host bridge config space value to make
the driver happy for all the different revisions
of the device.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-Intel-GPU-passthrough-Host-bridge-config-space.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-Intel-GPU-passthrough-Host-bridge-config-space.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..17ce8c0 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -74,6 +74,9 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
     {
         case 0x00:        /* vendor id */
         case 0x02:        /* device id */
+        case 0x08:        /* revision id */
+        case 0x2c:        /* sybsystem vendor id */
+        case 0x2e:        /* sybsystem id */
         case 0x50:        /* SNB: processor graphics control register */
         case 0x52:        /* processor graphics control register */
         case 0xa0:        /* top of memory */

--------------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 Thu Jan 12 14:07:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:07:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLJK-0004GA-D4; Thu, 12 Jan 2012 14:07:22 +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 1RlLJI-0004Fu-Rr
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:07:21 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326377234!8858604!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13858 invoked from network); 12 Jan 2012 14:07:14 -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;
	12 Jan 2012 14:07:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9971621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 14:07:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Jan 2012 14:07:13 +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 1RlLJA-0001yP-Tv;
	Thu, 12 Jan 2012 14:07:12 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RlLJ4-0007Wj-GP;
	Thu, 12 Jan 2012 14:07:06 +0000
From: <y@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 12 Jan 2012 14:07:05 +0000
Message-ID: <1326377225-28900-1-git-send-email-y>
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>
Subject: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config 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>
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


Expose more host bridge config space value to make
the driver happy for all the different revisions
of the device.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-Intel-GPU-passthrough-Host-bridge-config-space.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-Intel-GPU-passthrough-Host-bridge-config-space.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..17ce8c0 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -74,6 +74,9 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
     {
         case 0x00:        /* vendor id */
         case 0x02:        /* device id */
+        case 0x08:        /* revision id */
+        case 0x2c:        /* sybsystem vendor id */
+        case 0x2e:        /* sybsystem id */
         case 0x50:        /* SNB: processor graphics control register */
         case 0x52:        /* processor graphics control register */
         case 0xa0:        /* top of memory */

--------------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 Thu Jan 12 14:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLKo-0004Os-TI; Thu, 12 Jan 2012 14:08:54 +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 1RlLKo-0004OF-41
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:08:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326377327!8848337!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 16126 invoked from network); 12 Jan 2012 14:08:47 -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;
	12 Jan 2012 14:08:47 -0000
Received: by wgbdt11 with SMTP id dt11so1854640wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:08:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ddOD1P85ZptmAaEvFT+ZFztD593TzlU72rorsZjxDf4=;
	b=oUlEcyBno1iPiUrkgr2Adevis9ou/FyhXyrEgQb23S496qCFevgvbPpxH7r4GtrQHF
	6iFXS2R3lTXm4ljvKNHKSAPkLhR/n+hvzf+4BwF5jXP3+KxuV/seQBQRkrDX9YW7eL/0
	BiDAIgVEAaK9CimXlaPpWdK2IQILyK8yMn8oM=
Received: by 10.181.13.17 with SMTP id eu17mr6408081wid.12.1326377327118;
	Thu, 12 Jan 2012 06:08:47 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fd1sm582979wib.0.2012.01.12.06.08.44
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 06:08:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 14:08:41 +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: <CB3499E9.288E3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: properly define size_t
Thread-Index: AczRM6/Ol0f6PCiBWkmNaia/exSQvA==
In-Reply-To: <4F0EE2C2020000780006C18C@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: properly define size_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>
Content-Type: text/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/01/2012 12:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> Having it defined unilaterally as 'unsigned long' got me surprised
> recently when I tried to use the 'z' printk type modifier, as that is
> expected by the compiler to be used only on the type it knows size_t
> is supposed to have.
> 
> Generally the compiler provides a construct to do this, so use it when
> available.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -183,10 +183,10 @@ static int get_next_ucode_from_buffer_am
>      struct microcode_amd *mc_amd,
>      const void *buf,
>      size_t bufsize,
> -    unsigned long *offset)
> +    size_t *offset)
>  {
>      const uint8_t *bufp = buf;
> -    unsigned long off;
> +    size_t off;
>      const struct mpbhdr *mpbuf;
>  
>      off = *offset;
> @@ -203,7 +203,7 @@ static int get_next_ucode_from_buffer_am
>          return -EINVAL;
>      }
>  
> -    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
> +    printk(KERN_DEBUG "microcode: size %zu, block size %u, offset %zu\n",
>             bufsize, mpbuf->len, off);
>  
>      if ( (off + mpbuf->len) > bufsize )
> @@ -234,7 +234,7 @@ static int get_next_ucode_from_buffer_am
>  static int install_equiv_cpu_table(
>      struct microcode_amd *mc_amd,
>      const uint32_t *buf,
> -    unsigned long *offset)
> +    size_t *offset)
>  {
>      const struct mpbhdr *mpbuf = (const struct mpbhdr *)&buf[1];
>  
> --- a/xen/include/asm-x86/types.h
> +++ b/xen/include/asm-x86/types.h
> @@ -47,7 +47,13 @@ typedef unsigned long paddr_t;
>  #define PRIpaddr "016lx"
>  #endif
>  
> +#if defined(__SIZE_TYPE__)
> +typedef __SIZE_TYPE__ size_t;
> +#elif defined(__i386__)
> +typedef unsigned int size_t;
> +#else
>  typedef unsigned long size_t;
> +#endif
>  
>  typedef char bool_t;
>  #define test_and_set_bool(b)   xchg(&(b), 1)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:09:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:09:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLKo-0004Os-TI; Thu, 12 Jan 2012 14:08:54 +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 1RlLKo-0004OF-41
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:08:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326377327!8848337!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 16126 invoked from network); 12 Jan 2012 14:08:47 -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;
	12 Jan 2012 14:08:47 -0000
Received: by wgbdt11 with SMTP id dt11so1854640wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:08:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ddOD1P85ZptmAaEvFT+ZFztD593TzlU72rorsZjxDf4=;
	b=oUlEcyBno1iPiUrkgr2Adevis9ou/FyhXyrEgQb23S496qCFevgvbPpxH7r4GtrQHF
	6iFXS2R3lTXm4ljvKNHKSAPkLhR/n+hvzf+4BwF5jXP3+KxuV/seQBQRkrDX9YW7eL/0
	BiDAIgVEAaK9CimXlaPpWdK2IQILyK8yMn8oM=
Received: by 10.181.13.17 with SMTP id eu17mr6408081wid.12.1326377327118;
	Thu, 12 Jan 2012 06:08:47 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id fd1sm582979wib.0.2012.01.12.06.08.44
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 06:08:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 14:08:41 +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: <CB3499E9.288E3%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86: properly define size_t
Thread-Index: AczRM6/Ol0f6PCiBWkmNaia/exSQvA==
In-Reply-To: <4F0EE2C2020000780006C18C@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86: properly define size_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>
Content-Type: text/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/01/2012 12:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> Having it defined unilaterally as 'unsigned long' got me surprised
> recently when I tried to use the 'z' printk type modifier, as that is
> expected by the compiler to be used only on the type it knows size_t
> is supposed to have.
> 
> Generally the compiler provides a construct to do this, so use it when
> available.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/microcode_amd.c
> +++ b/xen/arch/x86/microcode_amd.c
> @@ -183,10 +183,10 @@ static int get_next_ucode_from_buffer_am
>      struct microcode_amd *mc_amd,
>      const void *buf,
>      size_t bufsize,
> -    unsigned long *offset)
> +    size_t *offset)
>  {
>      const uint8_t *bufp = buf;
> -    unsigned long off;
> +    size_t off;
>      const struct mpbhdr *mpbuf;
>  
>      off = *offset;
> @@ -203,7 +203,7 @@ static int get_next_ucode_from_buffer_am
>          return -EINVAL;
>      }
>  
> -    printk(KERN_DEBUG "microcode: size %lu, block size %u, offset %ld\n",
> +    printk(KERN_DEBUG "microcode: size %zu, block size %u, offset %zu\n",
>             bufsize, mpbuf->len, off);
>  
>      if ( (off + mpbuf->len) > bufsize )
> @@ -234,7 +234,7 @@ static int get_next_ucode_from_buffer_am
>  static int install_equiv_cpu_table(
>      struct microcode_amd *mc_amd,
>      const uint32_t *buf,
> -    unsigned long *offset)
> +    size_t *offset)
>  {
>      const struct mpbhdr *mpbuf = (const struct mpbhdr *)&buf[1];
>  
> --- a/xen/include/asm-x86/types.h
> +++ b/xen/include/asm-x86/types.h
> @@ -47,7 +47,13 @@ typedef unsigned long paddr_t;
>  #define PRIpaddr "016lx"
>  #endif
>  
> +#if defined(__SIZE_TYPE__)
> +typedef __SIZE_TYPE__ size_t;
> +#elif defined(__i386__)
> +typedef unsigned int size_t;
> +#else
>  typedef unsigned long size_t;
> +#endif
>  
>  typedef char bool_t;
>  #define test_and_set_bool(b)   xchg(&(b), 1)
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:09:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLL7-0004RH-A8; Thu, 12 Jan 2012 14:09:13 +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 1RlLL5-0004Q9-QE
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:09:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326377345!10645587!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 5556 invoked from network); 12 Jan 2012 14:09:05 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 14:09:05 -0000
Received: by wibhj8 with SMTP id hj8so850272wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:09:05 -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=BMWmlG/kF8PknG8beLGCQFE2/qJ+6ZM+hqGgbWuz6gc=;
	b=nA/uZKbmlohkGcCZsXCfvqtrNMZog4FhYbM4TNwQ8gmssuQXuiMOu/gnPxNOOkVgLb
	VT2VWN1vHBQon089RLA/jR055BQi2lKJtH7n079TbG4JALvHOOZ0iGK6UCOcbpQIbxUM
	GUzJYYX3D8/vDaHkgrGxCqAAYXFWnfT0c+mvs=
Received: by 10.181.13.208 with SMTP id fa16mr6439003wid.12.1326377345397;
	Thu, 12 Jan 2012 06:09:05 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id eu3sm9189389wib.6.2012.01.12.06.09.04
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 06:09:04 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 14:09:01 +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: <CB3499FD.288E4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86-64: globally use -mno-sse
Thread-Index: AczRM7u6zvsY/wwUX0OSi/BJAsLQUQ==
In-Reply-To: <4F0EE353020000780006C190@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: globally use -mno-sse
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 12:42, "Jan Beulich" <JBeulich@suse.com> wrote:

> This eliminates pointless prologue code from functions having variable
> argument lists (since that way xmm registers can't possibly be passed).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -41,7 +41,7 @@ x86_64 := n
>  endif
>  
>  ifeq ($(TARGET_SUBARCH),x86_64)
> -CFLAGS += -mno-red-zone -fpic
> +CFLAGS += -mno-red-zone -mno-sse -fpic
>  CFLAGS += -fno-asynchronous-unwind-tables
>  # -fvisibility=hidden reduces -fpic cost, if it's available
>  ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -1,4 +1,4 @@
> -CFLAGS += -fshort-wchar -mno-sse
> +CFLAGS += -fshort-wchar
>  
>  obj-y += stub.o
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 14:09:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:09:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLL7-0004RH-A8; Thu, 12 Jan 2012 14:09:13 +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 1RlLL5-0004Q9-QE
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:09:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326377345!10645587!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 5556 invoked from network); 12 Jan 2012 14:09:05 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 14:09:05 -0000
Received: by wibhj8 with SMTP id hj8so850272wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 06:09:05 -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=BMWmlG/kF8PknG8beLGCQFE2/qJ+6ZM+hqGgbWuz6gc=;
	b=nA/uZKbmlohkGcCZsXCfvqtrNMZog4FhYbM4TNwQ8gmssuQXuiMOu/gnPxNOOkVgLb
	VT2VWN1vHBQon089RLA/jR055BQi2lKJtH7n079TbG4JALvHOOZ0iGK6UCOcbpQIbxUM
	GUzJYYX3D8/vDaHkgrGxCqAAYXFWnfT0c+mvs=
Received: by 10.181.13.208 with SMTP id fa16mr6439003wid.12.1326377345397;
	Thu, 12 Jan 2012 06:09:05 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id eu3sm9189389wib.6.2012.01.12.06.09.04
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 06:09:04 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 14:09:01 +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: <CB3499FD.288E4%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86-64: globally use -mno-sse
Thread-Index: AczRM7u6zvsY/wwUX0OSi/BJAsLQUQ==
In-Reply-To: <4F0EE353020000780006C190@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] x86-64: globally use -mno-sse
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 12:42, "Jan Beulich" <JBeulich@suse.com> wrote:

> This eliminates pointless prologue code from functions having variable
> argument lists (since that way xmm registers can't possibly be passed).
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -41,7 +41,7 @@ x86_64 := n
>  endif
>  
>  ifeq ($(TARGET_SUBARCH),x86_64)
> -CFLAGS += -mno-red-zone -fpic
> +CFLAGS += -mno-red-zone -mno-sse -fpic
>  CFLAGS += -fno-asynchronous-unwind-tables
>  # -fvisibility=hidden reduces -fpic cost, if it's available
>  ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -1,4 +1,4 @@
> -CFLAGS += -fshort-wchar -mno-sse
> +CFLAGS += -fshort-wchar
>  
>  obj-y += stub.o
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 14:10:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14: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 1RlLMW-0004cQ-Pw; Thu, 12 Jan 2012 14:10:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RlLMV-0004c7-Ih
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:10:39 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326377373!60703052!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11519 invoked from network); 12 Jan 2012 14:09:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 14:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9971733"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 14:10: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, 12 Jan 2012 14:10:36 +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 1RlLMN-0001zd-Ij;
	Thu, 12 Jan 2012 14:10:31 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RlLMH-0007YS-69;
	Thu, 12 Jan 2012 14:10:25 +0000
Date: Thu, 12 Jan 2012 14:10:25 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <jean.guyader@citrix.com>
Message-ID: <20120112141025.GA29015@spongy.cam.xci-test.com>
References: <1326377225-28900-1-git-send-email-y>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326377225-28900-1-git-send-email-y>
User-Agent: Mutt/1.5.21 (2010-09-15)
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>
Subject: Re: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config
	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 12/01 02:07, y@citrix.com wrote:
> 
> Expose more host bridge config space value to make
> the driver happy for all the different revisions
> of the device.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

Sorry about the wrong "from", something went wrong.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:10:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14: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 1RlLMW-0004cQ-Pw; Thu, 12 Jan 2012 14:10:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RlLMV-0004c7-Ih
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:10:39 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326377373!60703052!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11519 invoked from network); 12 Jan 2012 14:09:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 14:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9971733"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 14:10: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, 12 Jan 2012 14:10:36 +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 1RlLMN-0001zd-Ij;
	Thu, 12 Jan 2012 14:10:31 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RlLMH-0007YS-69;
	Thu, 12 Jan 2012 14:10:25 +0000
Date: Thu, 12 Jan 2012 14:10:25 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <jean.guyader@citrix.com>
Message-ID: <20120112141025.GA29015@spongy.cam.xci-test.com>
References: <1326377225-28900-1-git-send-email-y>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326377225-28900-1-git-send-email-y>
User-Agent: Mutt/1.5.21 (2010-09-15)
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>
Subject: Re: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config
	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 12/01 02:07, y@citrix.com wrote:
> 
> Expose more host bridge config space value to make
> the driver happy for all the different revisions
> of the device.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

Sorry about the wrong "from", something went wrong.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:13:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLOa-0004s9-Aw; Thu, 12 Jan 2012 14:12:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RlLOY-0004rr-AX
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:12:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326377516!50326052!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjY1NDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjY1NDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5468 invoked from network); 12 Jan 2012 14:11:57 -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; 12 Jan 2012 14:11:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326377561; l=1487;
	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=sz292VZQBIr2hoVID8eHeIIi+8M=;
	b=VVbRrzMLKA1ltiVGNpKmY+JC8iOVYLYcEMwuU7odAotgEUdQuck+n392Sr9EgxrThsz
	P1LFzpi979I3FlN3Yq7EpQDZ0ivg9VVf7TBwlHj6ZkeG5fStINRnwMuApiXbOL0Ib7i1W
	3Wa6UjQw0cOh8eBvA+y0K9SP18dz0bZxf0M=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by post.strato.de (mrclete mo3) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id g01c83o0CDSv44 ;
	Thu, 12 Jan 2012 15:12:36 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id CDCE118637; Thu, 12 Jan 2012 15:12:35 +0100 (CET)
Date: Thu, 12 Jan 2012 15:12:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120112141235.GB8324@aepfle.de>
References: <20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
	<20120111161023.GD81891@ocelot.phlegethon.org>
	<20120111163803.GA30142@aepfle.de>
	<20120111165855.GE81891@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111165855.GE81891@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, Tim Deegan wrote:

> At 17:38 +0100 on 11 Jan (1326303483), Olaf Hering wrote:
> > On Wed, Jan 11, Tim Deegan wrote:
> > 
> > > > Isnt that up to the host admin to decide where to take the memory from?
> > > > So if its acceptable to swap parts of a VM (independent from what the
> > > > guest OS thinks it has), so be it.
> > > 
> > > Why?  The _only_ reason I can imagine for wanting to use paging is when
> > > the balloon driver can't or won't do its job.  There's no advantage to
> > > paging except that you can always force it to happen.
> > 
> > Isnt that the whole point of paging, to make it happen at will without
> > the guest (or the application at process level) noticing it?
> 
> Yes, but that's a _bad_ thing. :)  If the guest can co-operate, you'll
> get way better eviction choices, better performance, and better
> accounting (since the I/O is done by the guest to guest-owned disk).

Hmm, I think its slightly like an 'rm -rf *' accident: bad, but allowed.

> That's why I think both mechanisms should be visible up to the libxl
> layer, but xl itself should just implement the one sensible policy:
> try ballooning first, then page if that fails.  

So you are saying xl should take care of an improved mem-set command?
Perhaps by tweaking memory/target first, monitoring something like
tot_pages, and if memory/target isnt reached after some time, tweak
memory/target-tot_pages so that xenpaging takes care of the rest?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:13:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLOa-0004s9-Aw; Thu, 12 Jan 2012 14:12:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RlLOY-0004rr-AX
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:12:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326377516!50326052!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjY1NDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjY1NDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5468 invoked from network); 12 Jan 2012 14:11:57 -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; 12 Jan 2012 14:11:57 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326377561; l=1487;
	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=sz292VZQBIr2hoVID8eHeIIi+8M=;
	b=VVbRrzMLKA1ltiVGNpKmY+JC8iOVYLYcEMwuU7odAotgEUdQuck+n392Sr9EgxrThsz
	P1LFzpi979I3FlN3Yq7EpQDZ0ivg9VVf7TBwlHj6ZkeG5fStINRnwMuApiXbOL0Ib7i1W
	3Wa6UjQw0cOh8eBvA+y0K9SP18dz0bZxf0M=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by post.strato.de (mrclete mo3) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id g01c83o0CDSv44 ;
	Thu, 12 Jan 2012 15:12:36 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id CDCE118637; Thu, 12 Jan 2012 15:12:35 +0100 (CET)
Date: Thu, 12 Jan 2012 15:12:35 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120112141235.GB8324@aepfle.de>
References: <20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de>
	<1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
	<20120111161023.GD81891@ocelot.phlegethon.org>
	<20120111163803.GA30142@aepfle.de>
	<20120111165855.GE81891@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111165855.GE81891@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, Tim Deegan wrote:

> At 17:38 +0100 on 11 Jan (1326303483), Olaf Hering wrote:
> > On Wed, Jan 11, Tim Deegan wrote:
> > 
> > > > Isnt that up to the host admin to decide where to take the memory from?
> > > > So if its acceptable to swap parts of a VM (independent from what the
> > > > guest OS thinks it has), so be it.
> > > 
> > > Why?  The _only_ reason I can imagine for wanting to use paging is when
> > > the balloon driver can't or won't do its job.  There's no advantage to
> > > paging except that you can always force it to happen.
> > 
> > Isnt that the whole point of paging, to make it happen at will without
> > the guest (or the application at process level) noticing it?
> 
> Yes, but that's a _bad_ thing. :)  If the guest can co-operate, you'll
> get way better eviction choices, better performance, and better
> accounting (since the I/O is done by the guest to guest-owned disk).

Hmm, I think its slightly like an 'rm -rf *' accident: bad, but allowed.

> That's why I think both mechanisms should be visible up to the libxl
> layer, but xl itself should just implement the one sensible policy:
> try ballooning first, then page if that fails.  

So you are saying xl should take care of an improved mem-set command?
Perhaps by tweaking memory/target first, monitoring something like
tot_pages, and if memory/target isnt reached after some time, tweak
memory/target-tot_pages so that xenpaging takes care of the rest?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:20:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLVf-0005Bt-7j; Thu, 12 Jan 2012 14:20: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 1RlLVd-0005Bn-VJ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:20:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326377998!8850401!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31889 invoked from network); 12 Jan 2012 14:19:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 14:19:59 -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
	q0CEJpHh019290
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 14:19:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0CEJn22028057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 14:19:50 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
	q0CEJkf9022022; Thu, 12 Jan 2012 08:19:47 -0600
Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive
	Gateway v4.0) with ESMTP ; Thu, 12 Jan 2012 06:19:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000) id ED01F40306;
	Thu, 12 Jan 2012 09:17:45 -0500 (EST)
USER-AGENT: Mutt/1.5.21 (2010-09-15)
MIME-Version: 1.0
Message-ID: <20120112141745.GA7685@phenom.dumpdata.com>
Date: Thu, 12 Jan 2012 06:17:45 -0800 (PST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>, Ian Campbell
	<Ian.Campbell@eu.citrix.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
In-Reply-To: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A020208.4F0EEC09.00DD,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	gurudas.pai@oracle.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Tina.Yang" <tina.yang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
> add polling interface to xen-netfront device to support netconsole
> 

Ian, any thoughts on the spinlock changes?

> Signed-off-by: Tina.Yang <tina.yang@oracle.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
> Tested-by: gurudas.pai <gurudas.pai@oracle.com>
> ---
>  drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
>  1 files changed, 34 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index fa67905..db638b4 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  	int frags = skb_shinfo(skb)->nr_frags;
>  	unsigned int offset = offset_in_page(data);
>  	unsigned int len = skb_headlen(skb);
> +	unsigned long flags;
>  
>  	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
>  	if (unlikely(frags > MAX_SKB_FRAGS + 1)) {
> @@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  		goto drop;
>  	}
>  
> -	spin_lock_irq(&np->tx_lock);
> +	spin_lock_irqsave(&np->tx_lock, flags);
>  
>  	if (unlikely(!netif_carrier_ok(dev) ||
>  		     (frags > 1 && !xennet_can_sg(dev)) ||
>  		     netif_needs_gso(skb, netif_skb_features(skb)))) {
> -		spin_unlock_irq(&np->tx_lock);
> +		spin_unlock_irqrestore(&np->tx_lock, flags);
>  		goto drop;
>  	}
>  
> @@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  	if (!netfront_tx_slot_available(np))
>  		netif_stop_queue(dev);
>  
> -	spin_unlock_irq(&np->tx_lock);
> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>  
>  	return NETDEV_TX_OK;
>  
> @@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
>  	return 0;
>  }
>  
> +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> +{
> +	struct net_device *dev = dev_id;
> +	struct netfront_info *np = netdev_priv(dev);
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&np->tx_lock, flags);
> +
> +	if (likely(netif_carrier_ok(dev))) {
> +		xennet_tx_buf_gc(dev);
> +		/* Under tx_lock: protects access to rx shared-ring indexes. */
> +		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> +			napi_schedule(&np->napi);
> +	}
> +
> +	spin_unlock_irqrestore(&np->tx_lock, flags);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +static void xennet_poll_controller(struct net_device *dev)
> +{
> +	xennet_interrupt(0, dev);
> +}
> +#endif
> +
>  static const struct net_device_ops xennet_netdev_ops = {
>  	.ndo_open            = xennet_open,
>  	.ndo_uninit          = xennet_uninit,
> @@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
>  	.ndo_validate_addr   = eth_validate_addr,
>  	.ndo_fix_features    = xennet_fix_features,
>  	.ndo_set_features    = xennet_set_features,
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +	.ndo_poll_controller = xennet_poll_controller,
> +#endif
>  };
>  
>  static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
> @@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
>  	return 0;
>  }
>  
> -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> -{
> -	struct net_device *dev = dev_id;
> -	struct netfront_info *np = netdev_priv(dev);
> -	unsigned long flags;
> -
> -	spin_lock_irqsave(&np->tx_lock, flags);
> -
> -	if (likely(netif_carrier_ok(dev))) {
> -		xennet_tx_buf_gc(dev);
> -		/* Under tx_lock: protects access to rx shared-ring indexes. */
> -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> -			napi_schedule(&np->napi);
> -	}
> -
> -	spin_unlock_irqrestore(&np->tx_lock, flags);
> -
> -	return IRQ_HANDLED;
> -}
> -
>  static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  {
>  	struct xen_netif_tx_sring *txs;
> -- 
> 1.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:20:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLVf-0005Bt-7j; Thu, 12 Jan 2012 14:20: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 1RlLVd-0005Bn-VJ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:20:06 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326377998!8850401!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31889 invoked from network); 12 Jan 2012 14:19:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 14:19:59 -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
	q0CEJpHh019290
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 14:19:52 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0CEJn22028057
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 14:19:50 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
	q0CEJkf9022022; Thu, 12 Jan 2012 08:19:47 -0600
Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive
	Gateway v4.0) with ESMTP ; Thu, 12 Jan 2012 06:19:37 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000) id ED01F40306;
	Thu, 12 Jan 2012 09:17:45 -0500 (EST)
USER-AGENT: Mutt/1.5.21 (2010-09-15)
MIME-Version: 1.0
Message-ID: <20120112141745.GA7685@phenom.dumpdata.com>
Date: Thu, 12 Jan 2012 06:17:45 -0800 (PST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Zhenzhong Duan <zhenzhong.duan@oracle.com>, Ian Campbell
	<Ian.Campbell@eu.citrix.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
In-Reply-To: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A020208.4F0EEC09.00DD,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	gurudas.pai@oracle.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Tina.Yang" <tina.yang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
> add polling interface to xen-netfront device to support netconsole
> 

Ian, any thoughts on the spinlock changes?

> Signed-off-by: Tina.Yang <tina.yang@oracle.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
> Tested-by: gurudas.pai <gurudas.pai@oracle.com>
> ---
>  drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
>  1 files changed, 34 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index fa67905..db638b4 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  	int frags = skb_shinfo(skb)->nr_frags;
>  	unsigned int offset = offset_in_page(data);
>  	unsigned int len = skb_headlen(skb);
> +	unsigned long flags;
>  
>  	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
>  	if (unlikely(frags > MAX_SKB_FRAGS + 1)) {
> @@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  		goto drop;
>  	}
>  
> -	spin_lock_irq(&np->tx_lock);
> +	spin_lock_irqsave(&np->tx_lock, flags);
>  
>  	if (unlikely(!netif_carrier_ok(dev) ||
>  		     (frags > 1 && !xennet_can_sg(dev)) ||
>  		     netif_needs_gso(skb, netif_skb_features(skb)))) {
> -		spin_unlock_irq(&np->tx_lock);
> +		spin_unlock_irqrestore(&np->tx_lock, flags);
>  		goto drop;
>  	}
>  
> @@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  	if (!netfront_tx_slot_available(np))
>  		netif_stop_queue(dev);
>  
> -	spin_unlock_irq(&np->tx_lock);
> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>  
>  	return NETDEV_TX_OK;
>  
> @@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
>  	return 0;
>  }
>  
> +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> +{
> +	struct net_device *dev = dev_id;
> +	struct netfront_info *np = netdev_priv(dev);
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&np->tx_lock, flags);
> +
> +	if (likely(netif_carrier_ok(dev))) {
> +		xennet_tx_buf_gc(dev);
> +		/* Under tx_lock: protects access to rx shared-ring indexes. */
> +		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> +			napi_schedule(&np->napi);
> +	}
> +
> +	spin_unlock_irqrestore(&np->tx_lock, flags);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +static void xennet_poll_controller(struct net_device *dev)
> +{
> +	xennet_interrupt(0, dev);
> +}
> +#endif
> +
>  static const struct net_device_ops xennet_netdev_ops = {
>  	.ndo_open            = xennet_open,
>  	.ndo_uninit          = xennet_uninit,
> @@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
>  	.ndo_validate_addr   = eth_validate_addr,
>  	.ndo_fix_features    = xennet_fix_features,
>  	.ndo_set_features    = xennet_set_features,
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +	.ndo_poll_controller = xennet_poll_controller,
> +#endif
>  };
>  
>  static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
> @@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
>  	return 0;
>  }
>  
> -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> -{
> -	struct net_device *dev = dev_id;
> -	struct netfront_info *np = netdev_priv(dev);
> -	unsigned long flags;
> -
> -	spin_lock_irqsave(&np->tx_lock, flags);
> -
> -	if (likely(netif_carrier_ok(dev))) {
> -		xennet_tx_buf_gc(dev);
> -		/* Under tx_lock: protects access to rx shared-ring indexes. */
> -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> -			napi_schedule(&np->napi);
> -	}
> -
> -	spin_unlock_irqrestore(&np->tx_lock, flags);
> -
> -	return IRQ_HANDLED;
> -}
> -
>  static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  {
>  	struct xen_netif_tx_sring *txs;
> -- 
> 1.7.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:21:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14: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 1RlLWU-0005ER-Nc; Thu, 12 Jan 2012 14:20: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 1RlLWT-0005EA-CQ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:20:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326378050!10641801!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTE1ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTE1ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14977 invoked from network); 12 Jan 2012 14:20:51 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 14:20:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326378050; l=898;
	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=2iigoIFg746SdCZsJeQ3IuL6gVA=;
	b=ZWm0ImUg10iLolo7FboPXDZny1qRn5kT9BC6a1Kv5TeCG0bnQo0EPa6oCZ4jPmw+TNM
	nIVhOL4cgQ7dhzhLBrKW9LV2nrR/shS0dWIPYootwKP0FpX1PkqeC+S/eymPRLLCRZlSA
	WaYsI22rjFJA2BKo0NBsERWdX1FlfBgiO0k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (cohen mo34) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j04b13o0CDWPeT ;
	Thu, 12 Jan 2012 15:20:33 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0DD0218637; Thu, 12 Jan 2012 15:20:32 +0100 (CET)
Date: Thu, 12 Jan 2012 15:20:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120112142032.GD8324@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
	<001301cccc1b$d7ca1470$875e3d50$@com>
	<20120110173956.GA2213@aepfle.de>
	<000901ccd030$d6f01e50$84d05af0$@com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <000901ccd030$d6f01e50$84d05af0$@com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "'bicky.'" <bicky.shi@huawei.com>, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, 'Ian Jackson' <Ian.Jackson@eu.citrix.com>,
	yanqiangjun@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, Hongkaixing wrote:

> Sorry, this mail is sent out in hurry. In fact we send out 2 patches , and this is only one patch. The second patch is the key.
> 
> The second patch is about adding a fast way to trigger page-in. 
> Titile is [PATCH 2 of 2] xenpaging:change page-in process to speed up page-in in xenpaging.
> 
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg00210.html
> 
> In this patch, we get the return value from p2m_mem_paging_populate(). 
> Because we want to known whether this p2mt is changed by balloon or others.
> 
> After this patch is published, we have received much advice, so a more perfect patch will be sent out later 

There is work being done to do page-in and page-out in a different way.
Please have a look at this work, it replaces what is currently done:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg00753.html

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:21:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14: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 1RlLWU-0005ER-Nc; Thu, 12 Jan 2012 14:20: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 1RlLWT-0005EA-CQ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:20:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326378050!10641801!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTE1ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTE1ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14977 invoked from network); 12 Jan 2012 14:20:51 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 14:20:51 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326378050; l=898;
	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=2iigoIFg746SdCZsJeQ3IuL6gVA=;
	b=ZWm0ImUg10iLolo7FboPXDZny1qRn5kT9BC6a1Kv5TeCG0bnQo0EPa6oCZ4jPmw+TNM
	nIVhOL4cgQ7dhzhLBrKW9LV2nrR/shS0dWIPYootwKP0FpX1PkqeC+S/eymPRLLCRZlSA
	WaYsI22rjFJA2BKo0NBsERWdX1FlfBgiO0k=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (cohen mo34) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j04b13o0CDWPeT ;
	Thu, 12 Jan 2012 15:20:33 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0DD0218637; Thu, 12 Jan 2012 15:20:32 +0100 (CET)
Date: Thu, 12 Jan 2012 15:20:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Hongkaixing <hongkaixing@huawei.com>
Message-ID: <20120112142032.GD8324@aepfle.de>
References: <052727b8165ce6e05002.1325732917@h00166998.china.huawei.com>
	<20229.60517.106414.825193@mariner.uk.xensource.com>
	<001301cccc1b$d7ca1470$875e3d50$@com>
	<20120110173956.GA2213@aepfle.de>
	<000901ccd030$d6f01e50$84d05af0$@com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <000901ccd030$d6f01e50$84d05af0$@com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "'bicky.'" <bicky.shi@huawei.com>, xiaowei.yang@huawei.com,
	xen-devel@lists.xensource.com, 'Ian Jackson' <Ian.Jackson@eu.citrix.com>,
	yanqiangjun@huawei.com
Subject: Re: [Xen-devel] [PATCH] xenpaging:add a new array to speed up
 page-in in xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, Hongkaixing wrote:

> Sorry, this mail is sent out in hurry. In fact we send out 2 patches , and this is only one patch. The second patch is the key.
> 
> The second patch is about adding a fast way to trigger page-in. 
> Titile is [PATCH 2 of 2] xenpaging:change page-in process to speed up page-in in xenpaging.
> 
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg00210.html
> 
> In this patch, we get the return value from p2m_mem_paging_populate(). 
> Because we want to known whether this p2mt is changed by balloon or others.
> 
> After this patch is published, we have received much advice, so a more perfect patch will be sent out later 

There is work being done to do page-in and page-out in a different way.
Please have a look at this work, it replaces what is currently done:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg00753.html

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:21:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLWr-0005HR-AP; Thu, 12 Jan 2012 14:21:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RlLWp-0005Gn-0P
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:21:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326378072!10730389!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 29434 invoked from network); 12 Jan 2012 14:21:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 14:21:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlLWf-000DQC-K0; Thu, 12 Jan 2012 14:21:09 +0000
Date: Thu, 12 Jan 2012 14:21:09 +0000
From: Tim Deegan <tim@xen.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120112142109.GG47092@ocelot.phlegethon.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<4F0EC198.9050406@invisiblethingslab.com>
	<20120112121303.GE47092@ocelot.phlegethon.org>
	<4F0EE07C.2070603@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0EE07C.2070603@invisiblethingslab.com>
User-Agent: Mutt/1.4.2.1i
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] On Dom0 disaggregation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:30 +0100 on 12 Jan (1326378636), Joanna Rutkowska wrote:
> > So you're saying that the PCIback domain (which owns the chipsets) might
> > as well host Xenstore since either of them could hose the system.
> > Maybe so.  In Xoar we had two reasons not to do that:
> >  - in some configurations you could shut that domain down after boot
> >    (though tbh doing that leads to poor error handling!); and
> >  - we were doing other hardening of Xenstore that involved breaking it 
> >    up into more than one VM. 
> > 
> 
> But the paper says the PCIBack is destroyed after init -- who manages
> the chipset (MCH, ICH, platform power management), then?

Nobody.  Like I said, it's not ideal. :)

You don't have to destroy PCIBack -- you can keep it around to do those
things.  And if you do, it has a _much_ narrower interface to the rest
of the world than dom0 does.  It has no network access, and no direct
interface to customer (i.e. non-driver) VMs.  A malicious customer VM
must break at least one other system VM before it can attack it.

> Also, if I correctly interpret your architecture, then BlkBack VM must
> be trusted, as it has access to the disk, and thus can serve compromised
> fs/kernel/initramfs images to VMs, and also modify boot partition to
> load compromised Xen on the next boot (unless you use something like
> Intel TXT for Xen load). So, what's the reason of separating it from
> (the trusted) Xenstored VM?

Well, you can have multiple block driver domains, if you have multiple
HBAs, and arrange that two customers' data don't share a blkback.

And there are the usual reasons for driver domains.  For example you're
not tied to a particular OS for all your drivers.  And device-driver
crashes don't take out xenstore.

Trusted boot is orthogonal to the Xoar work.  We didn't go into it in
the paper but it's fairly obvious how it would fit in.  And once you've
got a TPM you could also use vTPMs to protect VMs' disk images.

> Also, if this was a client system, where would you put user input/output
> handling?

I'd probably make a console driver VM that owned the GPU and the USB
controller.  It might make sense for the toolstack (or at least the
parts that compose the display and demux the inputs) to live in that VM
too.  Or maybe it would be better to isolate those drivers; I haven't
given it a lot of thought. 

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 Jan 12 14:21:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLWr-0005HR-AP; Thu, 12 Jan 2012 14:21:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RlLWp-0005Gn-0P
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:21:19 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326378072!10730389!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 29434 invoked from network); 12 Jan 2012 14:21:12 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 14:21:12 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlLWf-000DQC-K0; Thu, 12 Jan 2012 14:21:09 +0000
Date: Thu, 12 Jan 2012 14:21:09 +0000
From: Tim Deegan <tim@xen.org>
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Message-ID: <20120112142109.GG47092@ocelot.phlegethon.org>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<4F0EC198.9050406@invisiblethingslab.com>
	<20120112121303.GE47092@ocelot.phlegethon.org>
	<4F0EE07C.2070603@invisiblethingslab.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F0EE07C.2070603@invisiblethingslab.com>
User-Agent: Mutt/1.4.2.1i
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] On Dom0 disaggregation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:30 +0100 on 12 Jan (1326378636), Joanna Rutkowska wrote:
> > So you're saying that the PCIback domain (which owns the chipsets) might
> > as well host Xenstore since either of them could hose the system.
> > Maybe so.  In Xoar we had two reasons not to do that:
> >  - in some configurations you could shut that domain down after boot
> >    (though tbh doing that leads to poor error handling!); and
> >  - we were doing other hardening of Xenstore that involved breaking it 
> >    up into more than one VM. 
> > 
> 
> But the paper says the PCIBack is destroyed after init -- who manages
> the chipset (MCH, ICH, platform power management), then?

Nobody.  Like I said, it's not ideal. :)

You don't have to destroy PCIBack -- you can keep it around to do those
things.  And if you do, it has a _much_ narrower interface to the rest
of the world than dom0 does.  It has no network access, and no direct
interface to customer (i.e. non-driver) VMs.  A malicious customer VM
must break at least one other system VM before it can attack it.

> Also, if I correctly interpret your architecture, then BlkBack VM must
> be trusted, as it has access to the disk, and thus can serve compromised
> fs/kernel/initramfs images to VMs, and also modify boot partition to
> load compromised Xen on the next boot (unless you use something like
> Intel TXT for Xen load). So, what's the reason of separating it from
> (the trusted) Xenstored VM?

Well, you can have multiple block driver domains, if you have multiple
HBAs, and arrange that two customers' data don't share a blkback.

And there are the usual reasons for driver domains.  For example you're
not tied to a particular OS for all your drivers.  And device-driver
crashes don't take out xenstore.

Trusted boot is orthogonal to the Xoar work.  We didn't go into it in
the paper but it's fairly obvious how it would fit in.  And once you've
got a TPM you could also use vTPMs to protect VMs' disk images.

> Also, if this was a client system, where would you put user input/output
> handling?

I'd probably make a console driver VM that owned the GPU and the USB
controller.  It might make sense for the toolstack (or at least the
parts that compose the display and demux the inputs) to live in that VM
too.  Or maybe it would be better to isolate those drivers; I haven't
given it a lot of thought. 

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 Jan 12 14:23:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:23:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLYy-0005Vt-SF; Thu, 12 Jan 2012 14:23:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihirn@cs.ubc.ca>) id 1RlLYx-0005VE-Oa
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:23:31 +0000
X-Env-Sender: mihirn@cs.ubc.ca
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326378203!8655588!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17680 invoked from network); 12 Jan 2012 14:23:25 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 14:23:25 -0000
Received: from [192.168.2.2] (S0106944452c5a909.vc.shawcable.net
	[24.84.40.131]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0CENIC9019079
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 12 Jan 2012 06:23:19 -0800
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<4F0EC198.9050406@invisiblethingslab.com>
	<20120112121303.GE47092@ocelot.phlegethon.org>
	<4F0EE07C.2070603@invisiblethingslab.com>
In-Reply-To: <4F0EE07C.2070603@invisiblethingslab.com>
Mime-Version: 1.0 (1.0)
Message-Id: <8D70893B-F948-4178-B1FB-4F016AFFAE0D@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Mihir Nanavati <mihirn@cs.ubc.ca>
Date: Thu, 12 Jan 2012 06:23:15 -0800
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Cc: Mihir Nanavati <mihirn@cs.ubc.ca>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] On Dom0 disaggregation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2012-01-12, at 5:31 AM, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:

> On 01/12/12 13:13, Tim Deegan wrote:
>> At 12:18 +0100 on 12 Jan (1326370728), Joanna Rutkowska wrote:
>>> On 01/12/12 11:48, Tim Deegan wrote:
>>>> I think the point is to protect xenstore from dom0, not dom0 from
>>>> xenstore.  With stub-xenstore and driver domains, only the domain
>>>> builder and PCIback need to have any privilege, and they can be moved
>>>> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
>>>> http://tjd.phlegethon.org/words/sosp11-xoar.html)
>>> 
>>> In order for this to make sense from security point of view, you would
>>> need to deprivilige Dom0.
>> 
>> Yep.  That's what Xoar did (or, if you prefer, it moved all dom0's
>> components out and then got rid of it).
>> 
>>> When considering this task, one should answer
>>> the following questions:
>>> 
>>> 1) Who manages the chipset (MCH)?
>> 
>> A driver domain that contains PCIback.  It doesn't need general
>> privlege (e.g. for scheduler or memory operations).
>> 
>>> 2) Who manages the input (keyboard, mouse)
>>> 3) Who manages the output (GPU, specifically critical on client systems)
>>> 
>>> From the security point of view there is no point of isolating the
>>> entities that manage the above between each other, because a compromise
>>> of any of those entities leads to full system compromise (again, #3
>>> applies to client systems).
>> 
>> #2 is really a client-only thing as well.  Serial console input for
>> servers is owned directly by the hypervisor.
>> 
>>> Now, as you pointed out, we shall probably add another bullet to the
>>> list, which is:
>>> 
>>> 4) the xenstored
>>> 
>>> (although I'm not 100% if we couldn't somehow deprivilige xenstored).
>> 
>> Yes we could (and Xoar did).  IIRC the only reason it needs privilege is
>> to map the rings and that can be sorted out by having the builder
>> pre-load a grant entry.
>> 
>>> So, we end up with a conclusion that there is no point separating those
>>> 4 functionalists between each other, and so it only make sense to host
>>> them in the same domain. How about we call this domain "Dom0", then? ;)
>> 
>> So you're saying that the PCIback domain (which owns the chipsets) might
>> as well host Xenstore since either of them could hose the system.
>> Maybe so.  In Xoar we had two reasons not to do that:
>> - in some configurations you could shut that domain down after boot
>>   (though tbh doing that leads to poor error handling!); and
>> - we were doing other hardening of Xenstore that involved breaking it 
>>   up into more than one VM. 
>> 
> 
> But the paper says the PCIBack is destroyed after init -- who manages
> the chipset (MCH, ICH, platform power management), then?
> 
> Also, if I correctly interpret your architecture, then BlkBack VM must
> be trusted, as it has access to the disk, and thus can serve compromised
> fs/kernel/initramfs images to VMs, and also modify boot partition to
> load compromised Xen on the next boot (unless you use something like
> Intel TXT for Xen load). So, what's the reason of separating it from
> (the trusted) Xenstored VM?
> 
> Unless the kernel/initramfs images (at least for PV domains) come from
> some trusted source, not from blkbackend? Then they could contain code
> to verify integrity of the fs served from blkbackend. Have you
> considered this in your architecture?

Indeed. The domain builder only builds known good kernels, currently which are served from its ramdisk. There is an alternative architecture where it's served by a special storage domain via shared memory too.

You're right about the block backend needing to be trusted to some extent; it's only a matter of reducing who needs to trust it. On a system with multiple disk controllers, the one serving Xen could be split from the one serving the VMs. With only a single controller, you'd probably use TXT.


> 
> Also, if this was a client system, where would you put user input/output
> handling?

I'm afraid I'm not sure I know exactly what you mean here...

~M

> 
> joanna.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 14:23:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:23:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLYy-0005Vt-SF; Thu, 12 Jan 2012 14:23:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mihirn@cs.ubc.ca>) id 1RlLYx-0005VE-Oa
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:23:31 +0000
X-Env-Sender: mihirn@cs.ubc.ca
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326378203!8655588!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17680 invoked from network); 12 Jan 2012 14:23:25 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 14:23:25 -0000
Received: from [192.168.2.2] (S0106944452c5a909.vc.shawcable.net
	[24.84.40.131]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0CENIC9019079
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 12 Jan 2012 06:23:19 -0800
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
	<20120112104802.GA47092@ocelot.phlegethon.org>
	<4F0EC198.9050406@invisiblethingslab.com>
	<20120112121303.GE47092@ocelot.phlegethon.org>
	<4F0EE07C.2070603@invisiblethingslab.com>
In-Reply-To: <4F0EE07C.2070603@invisiblethingslab.com>
Mime-Version: 1.0 (1.0)
Message-Id: <8D70893B-F948-4178-B1FB-4F016AFFAE0D@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Mihir Nanavati <mihirn@cs.ubc.ca>
Date: Thu, 12 Jan 2012 06:23:15 -0800
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
Cc: Mihir Nanavati <mihirn@cs.ubc.ca>, Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] On Dom0 disaggregation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 2012-01-12, at 5:31 AM, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:

> On 01/12/12 13:13, Tim Deegan wrote:
>> At 12:18 +0100 on 12 Jan (1326370728), Joanna Rutkowska wrote:
>>> On 01/12/12 11:48, Tim Deegan wrote:
>>>> I think the point is to protect xenstore from dom0, not dom0 from
>>>> xenstore.  With stub-xenstore and driver domains, only the domain
>>>> builder and PCIback need to have any privilege, and they can be moved
>>>> out of dom0 too (e.g., http://dl.acm.org/citation.cfm?id=1346278 ,
>>>> http://tjd.phlegethon.org/words/sosp11-xoar.html)
>>> 
>>> In order for this to make sense from security point of view, you would
>>> need to deprivilige Dom0.
>> 
>> Yep.  That's what Xoar did (or, if you prefer, it moved all dom0's
>> components out and then got rid of it).
>> 
>>> When considering this task, one should answer
>>> the following questions:
>>> 
>>> 1) Who manages the chipset (MCH)?
>> 
>> A driver domain that contains PCIback.  It doesn't need general
>> privlege (e.g. for scheduler or memory operations).
>> 
>>> 2) Who manages the input (keyboard, mouse)
>>> 3) Who manages the output (GPU, specifically critical on client systems)
>>> 
>>> From the security point of view there is no point of isolating the
>>> entities that manage the above between each other, because a compromise
>>> of any of those entities leads to full system compromise (again, #3
>>> applies to client systems).
>> 
>> #2 is really a client-only thing as well.  Serial console input for
>> servers is owned directly by the hypervisor.
>> 
>>> Now, as you pointed out, we shall probably add another bullet to the
>>> list, which is:
>>> 
>>> 4) the xenstored
>>> 
>>> (although I'm not 100% if we couldn't somehow deprivilige xenstored).
>> 
>> Yes we could (and Xoar did).  IIRC the only reason it needs privilege is
>> to map the rings and that can be sorted out by having the builder
>> pre-load a grant entry.
>> 
>>> So, we end up with a conclusion that there is no point separating those
>>> 4 functionalists between each other, and so it only make sense to host
>>> them in the same domain. How about we call this domain "Dom0", then? ;)
>> 
>> So you're saying that the PCIback domain (which owns the chipsets) might
>> as well host Xenstore since either of them could hose the system.
>> Maybe so.  In Xoar we had two reasons not to do that:
>> - in some configurations you could shut that domain down after boot
>>   (though tbh doing that leads to poor error handling!); and
>> - we were doing other hardening of Xenstore that involved breaking it 
>>   up into more than one VM. 
>> 
> 
> But the paper says the PCIBack is destroyed after init -- who manages
> the chipset (MCH, ICH, platform power management), then?
> 
> Also, if I correctly interpret your architecture, then BlkBack VM must
> be trusted, as it has access to the disk, and thus can serve compromised
> fs/kernel/initramfs images to VMs, and also modify boot partition to
> load compromised Xen on the next boot (unless you use something like
> Intel TXT for Xen load). So, what's the reason of separating it from
> (the trusted) Xenstored VM?
> 
> Unless the kernel/initramfs images (at least for PV domains) come from
> some trusted source, not from blkbackend? Then they could contain code
> to verify integrity of the fs served from blkbackend. Have you
> considered this in your architecture?

Indeed. The domain builder only builds known good kernels, currently which are served from its ramdisk. There is an alternative architecture where it's served by a special storage domain via shared memory too.

You're right about the block backend needing to be trusted to some extent; it's only a matter of reducing who needs to trust it. On a system with multiple disk controllers, the one serving Xen could be split from the one serving the VMs. With only a single controller, you'd probably use TXT.


> 
> Also, if this was a client system, where would you put user input/output
> handling?

I'm afraid I'm not sure I know exactly what you mean here...

~M

> 
> joanna.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 12 14:34:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLjF-0005rY-0i; Thu, 12 Jan 2012 14:34:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RlLjD-0005rS-9m
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:34:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326378840!1886819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15829 invoked from network); 12 Jan 2012 14:34:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 14:34:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9972534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 14:34: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; Thu, 12 Jan 2012 14:34:00 +0000
Date: Thu, 12 Jan 2012 14:34:13 +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: <20120112124254.GB11262@spongy.cam.xci-test.com>
Message-ID: <alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (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 Thu, 12 Jan 2012, Jean Guyader wrote:
> On 12/01 12:41, 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>
> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> Date:   Wed Nov 23 07:53:30 2011 +0000
> 
>     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.
>     
>     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.
> 
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index dbe8804..7ee3c61 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -238,6 +238,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).
> @@ -444,6 +452,16 @@ 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,
>      },
> +    /* Intel IGFX OpRegion reg */
> +    {
> +        .offset     = PCI_INTEL_OPREGION,
> +        .size       = 4,
> +        .init_val   = 0,
> +        .no_wb      = 1,
> +        .u.dw.read   = pt_intel_opregion_read,
> +        .u.dw.write  = pt_intel_opregion_write,
> +        .u.dw.restore  = NULL,
> +    },
>      {
>          .size = 0,
>      },
> @@ -737,7 +755,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 */
> @@ -3006,6 +3024,19 @@ 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)
> +{
> +    /*
> +    ** By default we will trap up to 0x40 in the cfg space.
> +    ** If an intel device is pass through we need to trap 0xfc,
> +    ** therefore the size should be 0xff.
> +    */
> +    if (igd_passthru)
> +        return 0xFF;
> +    return grp_reg->grp_size;
> +}

Apart from the trivial code style error in the comment above, is this
going to have the unintended side effect of initializing as 0 all the
emulated registers between 0x40 and 0xff, that previously were probably
passed through?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:34:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:34:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLjF-0005rY-0i; Thu, 12 Jan 2012 14:34:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RlLjD-0005rS-9m
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:34:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326378840!1886819!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15829 invoked from network); 12 Jan 2012 14:34:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 14:34:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9972534"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 14:34: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; Thu, 12 Jan 2012 14:34:00 +0000
Date: Thu, 12 Jan 2012 14:34:13 +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: <20120112124254.GB11262@spongy.cam.xci-test.com>
Message-ID: <alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (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 Thu, 12 Jan 2012, Jean Guyader wrote:
> On 12/01 12:41, 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>
> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> Date:   Wed Nov 23 07:53:30 2011 +0000
> 
>     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.
>     
>     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.
> 
> diff --git a/hw/pass-through.c b/hw/pass-through.c
> index dbe8804..7ee3c61 100644
> --- a/hw/pass-through.c
> +++ b/hw/pass-through.c
> @@ -238,6 +238,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).
> @@ -444,6 +452,16 @@ 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,
>      },
> +    /* Intel IGFX OpRegion reg */
> +    {
> +        .offset     = PCI_INTEL_OPREGION,
> +        .size       = 4,
> +        .init_val   = 0,
> +        .no_wb      = 1,
> +        .u.dw.read   = pt_intel_opregion_read,
> +        .u.dw.write  = pt_intel_opregion_write,
> +        .u.dw.restore  = NULL,
> +    },
>      {
>          .size = 0,
>      },
> @@ -737,7 +755,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 */
> @@ -3006,6 +3024,19 @@ 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)
> +{
> +    /*
> +    ** By default we will trap up to 0x40 in the cfg space.
> +    ** If an intel device is pass through we need to trap 0xfc,
> +    ** therefore the size should be 0xff.
> +    */
> +    if (igd_passthru)
> +        return 0xFF;
> +    return grp_reg->grp_size;
> +}

Apart from the trivial code style error in the comment above, is this
going to have the unintended side effect of initializing as 0 all the
emulated registers between 0x40 and 0xff, that previously were probably
passed through?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:41:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:41:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLqC-00061y-1m; Thu, 12 Jan 2012 14:41:20 +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 1RlLqA-00061s-Ku
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:41:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326379269!10767692!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22577 invoked from network); 12 Jan 2012 14:41:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 14:41:11 -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
	q0CEdcuK012289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 14:39:38 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
	q0CEdbrU005976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 14:39:37 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CEdaFZ022127; Thu, 12 Jan 2012 08:39:36 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 06:39:36 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 564A540306; Thu, 12 Jan 2012 09:37:45 -0500 (EST)
Date: Thu, 12 Jan 2012 09:37:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>, waldi@debian.org
Message-ID: <20120112143745.GE7685@phenom.dumpdata.com>
References: <20120111172832.GB4449@phenom.dumpdata.com>
	<e37e8bec-f4ec-4420-81f0-da0ef90a6120@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e37e8bec-f4ec-4420-81f0-da0ef90a6120@zmail13.collab.prod.int.phx2.redhat.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.0A090206.4F0EF0AB.0067,ss=1,re=0.000,fgs=0
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep
	XEN_XENBUS_FRONTEND	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 05:49:57AM -0500, Andrew Jones wrote:
> 
> 
> ----- Original Message -----
> > On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> > > When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
> > > unbootable configs. If we need it, then we should just build it in.
> > 
> > Hm, don't the frontends by themsevles load this module? So if you
> > do 'modprobe xen-pcifront' it would load this automatically?
> > 
> 
> The problem is on boot, getting it there before we need xen-blkfront.
> I think it might solvable if you make sure your tooling pushes the
> xenbus module into your initrd. However we've had problems with

So it seems we also need patches for dracut and initramfs here?

Or is it possible to make the modules (fb) try to load xenbus frontend
automatically? Preferrably one would do this:

modprobe xen_fbfront
which would then automatically load xenbus_module, xen_kbdfront

Better yet if udev/kudzu figured out this automtically and loaded
the modules.

Is there a mechanism to automatically have udev do all of this loading?
Let CC the Debian maintainer on this converstation as he might have
some ideas in this.


> platform_pci being a module in the past, and if I'm not mistaken

Right, but that driver is not tied in with the frontends. It just
pokes at the ioport to disable QEMU HVM drivers.

> that was one of the motivators for building it in (5fbdc10395cd). I
> see this as a similar story.
> 
> Drew
> 
> > > 
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > >  drivers/xen/Kconfig |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > > index 8795480..1d24061 100644
> > > --- a/drivers/xen/Kconfig
> > > +++ b/drivers/xen/Kconfig
> > > @@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
> > >  	 but will have no xen contents.
> > >  
> > >  config XEN_XENBUS_FRONTEND
> > > -	tristate
> > > +	bool
> > >  
> > >  config XEN_GNTDEV
> > >  	tristate "userspace grant access device driver"
> > > --
> > > 1.7.7.5
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:41:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:41:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLqC-00061y-1m; Thu, 12 Jan 2012 14:41:20 +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 1RlLqA-00061s-Ku
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:41:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326379269!10767692!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22577 invoked from network); 12 Jan 2012 14:41:11 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 14:41:11 -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
	q0CEdcuK012289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 14:39:38 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
	q0CEdbrU005976
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 14:39:37 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CEdaFZ022127; Thu, 12 Jan 2012 08:39:36 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 06:39:36 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 564A540306; Thu, 12 Jan 2012 09:37:45 -0500 (EST)
Date: Thu, 12 Jan 2012 09:37:45 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>, waldi@debian.org
Message-ID: <20120112143745.GE7685@phenom.dumpdata.com>
References: <20120111172832.GB4449@phenom.dumpdata.com>
	<e37e8bec-f4ec-4420-81f0-da0ef90a6120@zmail13.collab.prod.int.phx2.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e37e8bec-f4ec-4420-81f0-da0ef90a6120@zmail13.collab.prod.int.phx2.redhat.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.0A090206.4F0EF0AB.0067,ss=1,re=0.000,fgs=0
Cc: konrad@darnok.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep
	XEN_XENBUS_FRONTEND	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 05:49:57AM -0500, Andrew Jones wrote:
> 
> 
> ----- Original Message -----
> > On Wed, Jan 11, 2012 at 05:36:38PM +0100, Andrew Jones wrote:
> > > When XEN_XENBUS_FRONTEND gets selected as a module it can lead to
> > > unbootable configs. If we need it, then we should just build it in.
> > 
> > Hm, don't the frontends by themsevles load this module? So if you
> > do 'modprobe xen-pcifront' it would load this automatically?
> > 
> 
> The problem is on boot, getting it there before we need xen-blkfront.
> I think it might solvable if you make sure your tooling pushes the
> xenbus module into your initrd. However we've had problems with

So it seems we also need patches for dracut and initramfs here?

Or is it possible to make the modules (fb) try to load xenbus frontend
automatically? Preferrably one would do this:

modprobe xen_fbfront
which would then automatically load xenbus_module, xen_kbdfront

Better yet if udev/kudzu figured out this automtically and loaded
the modules.

Is there a mechanism to automatically have udev do all of this loading?
Let CC the Debian maintainer on this converstation as he might have
some ideas in this.


> platform_pci being a module in the past, and if I'm not mistaken

Right, but that driver is not tied in with the frontends. It just
pokes at the ioport to disable QEMU HVM drivers.

> that was one of the motivators for building it in (5fbdc10395cd). I
> see this as a similar story.
> 
> Drew
> 
> > > 
> > > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > > ---
> > >  drivers/xen/Kconfig |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > > index 8795480..1d24061 100644
> > > --- a/drivers/xen/Kconfig
> > > +++ b/drivers/xen/Kconfig
> > > @@ -118,7 +118,7 @@ config XEN_SYS_HYPERVISOR
> > >  	 but will have no xen contents.
> > >  
> > >  config XEN_XENBUS_FRONTEND
> > > -	tristate
> > > +	bool
> > >  
> > >  config XEN_GNTDEV
> > >  	tristate "userspace grant access device driver"
> > > --
> > > 1.7.7.5
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:44:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLsZ-00067E-Jk; Thu, 12 Jan 2012 14:43:47 +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 1RlLsY-00066x-LN
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:43:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326379419!2912427!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7013 invoked from network); 12 Jan 2012 14:43:40 -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; 12 Jan 2012 14:43:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326379419; l=1080;
	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=XExQXGuK3tcFrCxlaSIU/+OXTBY=;
	b=PQaTi4XZ44N0jcCv4oCxrsS4Ky65ickk+jrixIf++8yO/WYhOuKJO514sioCkdRxYuJ
	fqd0hbZT0NOwoITnTFVmEkPhmTRsdrOFSZQ4Mb/tnSrbI0SkXyC+6kvzqob4SW7AN4Cwa
	rVh1aUvL2PZnAaefHlX3g03XSV2IoguzNUc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (cohen mo33) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c04a65o0CE3Kgh ;
	Thu, 12 Jan 2012 15:43:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 47D2518637; Thu, 12 Jan 2012 15:43:25 +0100 (CET)
Date: Thu, 12 Jan 2012 15:43:25 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112144325.GE8324@aepfle.de>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ed4d429d7026a3cd2b33.1326307372@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,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, Andres Lagar-Cavilla wrote:

> +++ b/xen/include/public/domctl.h

> +/* Use for teardown/setup of helper<->hypervisor interface for paging, 
> + * access and sharing.*/
>  struct xen_domctl_mem_event_op {
>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
>  
> -    union {
> -        /* OP_ENABLE IN:  Virtual address of shared page */
> -        uint64_aligned_t shared_addr;  
> -        /* PAGING_PREP IN: buffer to immediately fill page in */
> -        uint64_aligned_t buffer;
> -    } u;
> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
>  
> -    /* Other OPs */
> -    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
> +    /* For binary backwards compatibility */
> +    uint64_aligned_t pad;
>  };

Assuming this struct is routed through libxc, and libxc gets a new
SONAME for every release, doesnt this mean that every old binary has to
be recompiled anyway for the new release?
If so, the padding is not needed.

Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 14:44:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 14:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlLsZ-00067E-Jk; Thu, 12 Jan 2012 14:43:47 +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 1RlLsY-00066x-LN
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 14:43:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326379419!2912427!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg5MDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7013 invoked from network); 12 Jan 2012 14:43:40 -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; 12 Jan 2012 14:43:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326379419; l=1080;
	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=XExQXGuK3tcFrCxlaSIU/+OXTBY=;
	b=PQaTi4XZ44N0jcCv4oCxrsS4Ky65ickk+jrixIf++8yO/WYhOuKJO514sioCkdRxYuJ
	fqd0hbZT0NOwoITnTFVmEkPhmTRsdrOFSZQ4Mb/tnSrbI0SkXyC+6kvzqob4SW7AN4Cwa
	rVh1aUvL2PZnAaefHlX3g03XSV2IoguzNUc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (cohen mo33) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id c04a65o0CE3Kgh ;
	Thu, 12 Jan 2012 15:43:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 47D2518637; Thu, 12 Jan 2012 15:43:25 +0100 (CET)
Date: Thu, 12 Jan 2012 15:43:25 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112144325.GE8324@aepfle.de>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ed4d429d7026a3cd2b33.1326307372@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,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, Andres Lagar-Cavilla wrote:

> +++ b/xen/include/public/domctl.h

> +/* Use for teardown/setup of helper<->hypervisor interface for paging, 
> + * access and sharing.*/
>  struct xen_domctl_mem_event_op {
>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
>  
> -    union {
> -        /* OP_ENABLE IN:  Virtual address of shared page */
> -        uint64_aligned_t shared_addr;  
> -        /* PAGING_PREP IN: buffer to immediately fill page in */
> -        uint64_aligned_t buffer;
> -    } u;
> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
>  
> -    /* Other OPs */
> -    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
> +    /* For binary backwards compatibility */
> +    uint64_aligned_t pad;
>  };

Assuming this struct is routed through libxc, and libxc gets a new
SONAME for every release, doesnt this mean that every old binary has to
be recompiled anyway for the new release?
If so, the padding is not needed.

Olaf


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:11:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlMIm-0006TU-TG; Thu, 12 Jan 2012 15:10:52 +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 1RlMIk-0006TM-IM
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:10:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326381042!10737383!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28680 invoked from network); 12 Jan 2012 15:10:43 -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; 12 Jan 2012 15:10:43 -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
	q0CFAIYJ005412
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 15:10: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
	q0CFAH2E026105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 15:10:18 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
	q0CFAGxp013333; Thu, 12 Jan 2012 09:10:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive
	Gateway v4.0) with ESMTP ; Thu, 12 Jan 2012 07:09:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 2BE8040306;
	Thu, 12 Jan 2012 10:07:17 -0500 (EST)
USER-AGENT: Mutt/1.5.21 (2010-09-15)
MIME-Version: 1.0
Message-ID: <20120112150717.GH7685@phenom.dumpdata.com>
Date: Thu, 12 Jan 2012 07:07:17 -0800 (PST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <498097597.20120112133832@eikelenboom.it>
In-Reply-To: <498097597.20120112133832@eikelenboom.it>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F0EF7E0.0038,ss=1,re=-15.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> 
> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.

Does it work if you use 'xl'?

> 
> dmesg and xm dmesg attached
> 
> --
> Sander
> 
> 
> Dom0 shows:
>              total       used       free     shared    buffers     cached
> Mem:        938860     220484     718376          0      27812      72128
> -/+ buffers/cache:     120544     818316
> Swap:      2097148          0    2097148
> 
> 
> xentop:
> 
> xentop - 13:34:31   Xen 4.1.3-rc1-pre
> 1 domains: 1 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
> Mem: 8386732k total, 1165260k used, 7221472k free    CPUs: 6 @ 3200MHz
>       NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR  VBD_RSECT  VBD_WSECT SSID
>   Domain-0 -----r         82    1.3    1048192   12.5   no limit       n/a     6    0        0        0    0        0        0        0          0          0    0
> 
> 

> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.0-rc0+ (root@serveerstertje) (gcc version 4.4.5 (Debian 4.4.5-8) ) #9 SMP Thu Jan 12 12:40:24 CET 2012
> [    0.000000] Command line: root=/dev/mapper/serveerstertje-root ro verbose mem=1024M console=hvc0 console=tty0 nomodeset vga=794 video=vesafb earlyprintk=xen max_loop=50 loop_max_part=10 xen-pciback.passthrough=1 xen-pciback.hide=(03:06.0)(04:00.0)(04:00.1)(04:00.2)(04:00.3)(04:00.4)(04:00.5)(04:00.6)(04:00.7)(0a:00.0)(0a:00.1)(0a:00.2)(0a:00.3)(0a:00.4)(0a:00.5)(0a:00.6)(0a:00.7)(05:00.0)(05:00.1)(07:01.0)(07:01.1)(07:01.2) pci=resource_alignment=07:01.0;07:01.1;07:01.2 debug debug loglevel=10
> [    0.000000] Freeing  9b-100 pfn range: 101 pages freed
> [    0.000000] 1-1 mapping on 9b->100
> [    0.000000] 1-1 mapping on afe90->100000
> [    0.000000] Released 101 pages of unused memory
> [    0.000000] Set 328149 page(s) to 1-1 mapping
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  Xen: 0000000000000000 - 000000000009b000 (usable)
> [    0.000000]  Xen: 000000000009b000 - 0000000000100000 (reserved)
> [    0.000000]  Xen: 0000000000100000 - 00000000afe90000 (usable)
> [    0.000000]  Xen: 00000000afe90000 - 00000000afe9e000 (ACPI data)
> [    0.000000]  Xen: 00000000afe9e000 - 00000000afee0000 (ACPI NVS)
> [    0.000000]  Xen: 00000000afee0000 - 00000000aff00000 (reserved)
> [    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
> [    0.000000]  Xen: 00000000fec20000 - 00000000fec21000 (reserved)
> [    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  Xen: 00000000ffe00000 - 0000000100000000 (reserved)
> [    0.000000]  Xen: 0000000100000000 - 0000000250000000 (usable)
> [    0.000000] e820 remove range: 0000000040000000 - ffffffffffffffff (usable)
> [    0.000000] bootconsole [xenboot0] enabled
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] user-defined physical RAM map:
> [    0.000000]  user: 0000000000000000 - 000000000009b000 (usable)
> [    0.000000]  user: 000000000009b000 - 0000000000100000 (reserved)
> [    0.000000]  user: 0000000000100000 - 0000000040000000 (usable)
> [    0.000000]  user: 00000000afe90000 - 00000000afe9e000 (ACPI data)
> [    0.000000]  user: 00000000afe9e000 - 00000000afee0000 (ACPI NVS)
> [    0.000000]  user: 00000000afee0000 - 00000000aff00000 (reserved)
> [    0.000000]  user: 00000000fec00000 - 00000000fec01000 (reserved)
> [    0.000000]  user: 00000000fec20000 - 00000000fec21000 (reserved)
> [    0.000000]  user: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  user: 00000000ffe00000 - 0000000100000000 (reserved)
> [    0.000000] DMI present.
> [    0.000000] DMI: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS V1.7B5 06/22/2010
> [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
> [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> [    0.000000] No AGP bridge found
> [    0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000
> [    0.000000] found SMP MP-table at [ffff8800000ff780] ff780
> [    0.000000] initial memory mapped : 0 - 031eb000
> [    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 8192
> [    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
> [    0.000000]  0000000000 - 0040000000 page 4k
> [    0.000000] kernel direct mapping tables up to 40000000 @ 2958000-2b5a000
> [    0.000000] xen: setting RW the range 2b38000 - 2b5a000
> [    0.000000] RAMDISK: 02b5a000 - 031eb000
> [    0.000000] ACPI: RSDP 00000000000fb120 00014 (v00 ACPIAM)
> [    0.000000] ACPI: RSDT 00000000afe90000 00048 (v01 MSI    OEMSLIC  20100622 MSFT 00000097)
> [    0.000000] ACPI: FACP 00000000afe90200 00084 (v01 7640MS A7640100 20100622 MSFT 00000097)
> [    0.000000] ACPI: DSDT 00000000afe905e0 09449 (v01  A7640 A7640100 00000100 INTL 20051117)
> [    0.000000] ACPI: FACS 00000000afe9e000 00040
> [    0.000000] ACPI: APIC 00000000afe90390 00088 (v01 7640MS A7640100 20100622 MSFT 00000097)
> [    0.000000] ACPI: MCFG 00000000afe90420 0003C (v01 7640MS OEMMCFG  20100622 MSFT 00000097)
> [    0.000000] ACPI: SLIC 00000000afe90460 00176 (v01 MSI    OEMSLIC  20100622 MSFT 00000097)
> [    0.000000] ACPI: OEMB 00000000afe9e040 00072 (v01 7640MS A7640100 20100622 MSFT 00000097)
> [    0.000000] ACPI: SRAT 00000000afe9a5e0 00108 (v03 AMD    FAM_F_10 00000002 AMD  00000001)
> [    0.000000] ACPI: HPET 00000000afe9a6f0 00038 (v01 7640MS OEMHPET  20100622 MSFT 00000097)
> [    0.000000] ACPI: IVRS 00000000afe9a730 00100 (v01  AMD     RD890S 00202031 AMD  00000000)
> [    0.000000] ACPI: SSDT 00000000afe9a830 00DA4 (v01 A M I  POWERNOW 00000001 AMD  00000001)
> [    0.000000] ACPI: Local APIC address 0xfee00000
> [    0.000000] Scanning NUMA topology in Northbridge 24
> [    0.000000] No NUMA configuration found
> [    0.000000] Faking a node at 0000000000000000-0000000040000000
> [    0.000000] Initmem setup node 0 0000000000000000-0000000040000000
> [    0.000000]   NODE_DATA [000000003fffb000 - 000000003fffffff]
> [    0.000000] Zone PFN ranges:
> [    0.000000]   DMA      0x00000010 -> 0x00001000
> [    0.000000]   DMA32    0x00001000 -> 0x00100000
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start PFN for each node
> [    0.000000] Early memory PFN ranges
> [    0.000000]     0: 0x00000010 -> 0x0000009b
> [    0.000000]     0: 0x00000100 -> 0x00040000
> [    0.000000] On node 0 totalpages: 262027
> [    0.000000]   DMA zone: 64 pages used for memmap
> [    0.000000]   DMA zone: 2 pages reserved
> [    0.000000]   DMA zone: 3913 pages, LIFO batch:0
> [    0.000000]   DMA32 zone: 4032 pages used for memmap
> [    0.000000]   DMA32 zone: 254016 pages, LIFO batch:31
> [    0.000000] ACPI: PM-Timer IO Port: 0x808
> [    0.000000] ACPI: Local APIC address 0xfee00000
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [    0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled)
> [    0.000000] ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 6, version 255, address 0xfec00000, GSI 0-255
> [    0.000000] ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> [    0.000000] IOAPIC[1]: apic_id 7, version 255, address 0xfec20000, GSI 24-279
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
> [    0.000000] ACPI: IRQ0 used by override.
> [    0.000000] ACPI: IRQ2 used by override.
> [    0.000000] ACPI: IRQ9 used by override.
> [    0.000000] Using ACPI (MADT) for SMP configuration information
> [    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
> [    0.000000] SMP: Allowing 6 CPUs, 0 hotplug CPUs
> [    0.000000] nr_irqs_gsi: 296
> [    0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:6fe90000)
> [    0.000000] Booting paravirtualized kernel on Xen
> [    0.000000] Xen version: 4.1.3-rc1-pre (preserve-AD)
> [    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:6 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88003ff3e000 s78784 r8192 d23616 u110592
> [    0.000000] pcpu-alloc: s78784 r8192 d23616 u110592 alloc=27*4096
> [    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 
> [    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 257929
> [    0.000000] Policy zone: DMA32
> [    0.000000] Kernel command line: root=/dev/mapper/serveerstertje-root ro verbose mem=1024M console=hvc0 console=tty0 nomodeset vga=794 video=vesafb earlyprintk=xen max_loop=50 loop_max_part=10 xen-pciback.passthrough=1 xen-pciback.hide=(03:06.0)(04:00.0)(04:00.1)(04:00.2)(04:00.3)(04:00.4)(04:00.5)(04:00.6)(04:00.7)(0a:00.0)(0a:00.1)(0a:00.2)(0a:00.3)(0a:00.4)(0a:00.5)(0a:00.6)(0a:00.7)(05:00.0)(05:00.1)(07:01.0)(07:01.1)(07:01.2) pci=resource_alignment=07:01.0;07:01.1;07:01.2 debug debug loglevel=10
> [    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
> [    0.000000] Placing 64MB software IO TLB between ffff88003a600000 - ffff88003e600000
> [    0.000000] software IO TLB at phys 0x3a600000 - 0x3e600000
> [    0.000000] Memory: 930212k/1048576k available (9111k kernel code, 468k absent, 117896k reserved, 6056k data, 644k init)
> [    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
> [    0.000000] Hierarchical RCU implementation.
> [    0.000000] NR_IRQS:4352 nr_irqs:1536 16
> [    0.000000] xen: sci override: global_irq=9 trigger=0 polarity=1
> [    0.000000] xen: registering gsi 9 triggering 0 polarity 1
> [    0.000000] xen: --> pirq=9 -> irq=9 (gsi=9)
> [    0.000000] xen: acpi sci 9
> [    0.000000] xen: --> pirq=1 -> irq=1 (gsi=1)
> [    0.000000] xen: --> pirq=2 -> irq=2 (gsi=2)
> [    0.000000] xen: --> pirq=3 -> irq=3 (gsi=3)
> [    0.000000] xen: --> pirq=4 -> irq=4 (gsi=4)
> [    0.000000] xen: --> pirq=5 -> irq=5 (gsi=5)
> [    0.000000] xen: --> pirq=6 -> irq=6 (gsi=6)
> [    0.000000] xen: --> pirq=7 -> irq=7 (gsi=7)
> [    0.000000] xen: --> pirq=8 -> irq=8 (gsi=8)
> [    0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9
> [    0.000000] xen: --> pirq=9 -> irq=9 (gsi=9)
> [    0.000000] xen: --> pirq=10 -> irq=10 (gsi=10)
> [    0.000000] xen: --> pirq=11 -> irq=11 (gsi=11)
> [    0.000000] xen: --> pirq=12 -> irq=12 (gsi=12)
> [    0.000000] xen: --> pirq=13 -> irq=13 (gsi=13)
> [    0.000000] xen: --> pirq=14 -> irq=14 (gsi=14)
> [    0.000000] xen: --> pirq=15 -> irq=15 (gsi=15)
> [    0.000000] Console: colour dummy device 80x25
> [    0.000000] console [tty0] enabled, bootconsole disabled
> [    0.000000] console [hvc0] enabled
> [    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> [    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
> [    0.000000] ... MAX_LOCK_DEPTH:          48
> [    0.000000] ... MAX_LOCKDEP_KEYS:        8191
> [    0.000000] ... CLASSHASH_SIZE:          4096
> [    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
> [    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
> [    0.000000] ... CHAINHASH_SIZE:          16384
> [    0.000000]  memory used by lock dependency info: 5823 kB
> [    0.000000]  per task-struct memory footprint: 1920 bytes
> [    0.000000] Xen: using vcpuop timer interface
> [    0.000000] installing Xen timer for CPU 0
> [    0.000000] Detected 3200.160 MHz processor.
> [    0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 6400.32 BogoMIPS (lpj=3200160)
> [    0.000999] pid_max: default: 32768 minimum: 301
> [    0.000999] Security Framework initialized
> [    0.000999] SELinux:  Initializing.
> [    0.000999] SELinux:  Starting in permissive mode
> [    0.000999] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> [    0.000999] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> [    0.000999] Mount-cache hash table entries: 256
> [    0.001378] Initializing cgroup subsys cpuacct
> [    0.001384] Initializing cgroup subsys freezer
> [    0.001445] tseg: 0000000000
> [    0.001466] CPU: Physical Processor ID: 0
> [    0.001470] CPU: Processor Core ID: 0
> [    0.002271] ACPI: Core revision 20110623
> [    0.013132] cpu 0 spinlock event irq 297
> [    0.013258] Performance Events: Broken PMU hardware detected, using software events only.
> [    0.013501] MCE: In-kernel MCE decoding enabled.
> [    0.013515] NMI watchdog disabled (cpu0): hardware events not enabled
> [    0.013684] installing Xen timer for CPU 1
> [    0.013704] cpu 1 spinlock event irq 303
> [    0.013729] lockdep: fixing up alternatives.
> [    0.013854] NMI watchdog disabled (cpu1): hardware events not enabled
> [    0.013998] installing Xen timer for CPU 2
> [    0.013998] cpu 2 spinlock event irq 309
> [    0.014098] NMI watchdog disabled (cpu2): hardware events not enabled
> [    0.014268] installing Xen timer for CPU 3
> [    0.014287] cpu 3 spinlock event irq 315
> [    0.014408] NMI watchdog disabled (cpu3): hardware events not enabled
> [    0.014560] installing Xen timer for CPU 4
> [    0.014581] cpu 4 spinlock event irq 321
> [    0.014702] NMI watchdog disabled (cpu4): hardware events not enabled
> [    0.014857] installing Xen timer for CPU 5
> [    0.014876] cpu 5 spinlock event irq 327
> [    0.015067] NMI watchdog disabled (cpu5): hardware events not enabled
> [    0.015120] Brought up 6 CPUs
> [    0.016561] Grant tables using version 2 layout.
> [    0.016561] Grant table initialized
> [    0.016561] RTC time: 12:25:12, date: 01/12/12
> [    0.016561] NET: Registered protocol family 16
> [    0.018139] node 0 link 0: io port [1000, ffffff]
> [    0.018139] TOM: 00000000b0000000 aka 2816M
> [    0.018139] Fam 10h mmconf [mem 0xe0000000-0xefffffff]
> [    0.018139] node 0 link 0: mmio [e0000000, efffffff] ==> none
> [    0.018139] node 0 link 0: mmio [f0000000, ffffffff]
> [    0.018139] node 0 link 0: mmio [a0000, bffff]
> [    0.018139] node 0 link 0: mmio [b0000000, dfffffff]
> [    0.018139] TOM2: 0000000250000000 aka 9472M
> [    0.018139] bus: [00, 07] on node 0 link 0
> [    0.018139] bus: 00 index 0 [io  0x0000-0xffff]
> [    0.018139] bus: 00 index 1 [mem 0xf0000000-0xffffffff]
> [    0.018139] bus: 00 index 2 [mem 0x000a0000-0x000bffff]
> [    0.018139] bus: 00 index 3 [mem 0xb0000000-0xdfffffff]
> [    0.018139] bus: 00 index 4 [mem 0x250000000-0xfcffffffff]
> [    0.018309] ACPI: bus type pci registered
> [    0.018381] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
> [    0.018381] PCI: not using MMCONFIG
> [    0.018381] PCI: Using configuration type 1 for base access
> [    0.018381] PCI: Using configuration type 1 for extended access
> [    0.068102] bio: create slab <bio-0> at 0
> [    0.068119] ACPI: Added _OSI(Module Device)
> [    0.068119] ACPI: Added _OSI(Processor Device)
> [    0.068119] ACPI: Added _OSI(3.0 _SCP Extensions)
> [    0.068119] ACPI: Added _OSI(Processor Aggregator Device)
> [    0.073523] ACPI: EC: Look up EC in DSDT
> [    0.075207] ACPI: Executed 3 blocks of module-level executable AML code
> [    0.088960] ACPI: Interpreter enabled
> [    0.088967] ACPI: (supports S0 S5)
> [    0.088992] ACPI: Using IOAPIC for interrupt routing
> [    0.088992] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
> [    0.091780] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
> [    0.185504] ACPI: No dock devices found.
> [    0.185512] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
> [    0.186307] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
> [    0.186633] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
> [    0.186640] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
> [    0.186646] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
> [    0.186652] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff]
> [    0.186659] pci_root PNP0A03:00: host bridge window [mem 0xb0000000-0xdfffffff]
> [    0.186672] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
> [    0.186808] PCI host bridge to bus 0000:00
> [    0.186808] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> [    0.186808] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    0.186808] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> [    0.186808] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]
> [    0.186808] pci_bus 0000:00: root bus resource [mem 0xb0000000-0xdfffffff]
> [    0.186808] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff]
> [    0.186808] pci 0000:00:00.0: [1002:5a11] type 0 class 0x000600
> [    0.186808] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806
> [    0.187000] pci 0000:00:02.0: [1002:5a16] type 1 class 0x000604
> [    0.187127] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
> [    0.187176] pci 0000:00:03.0: [1002:5a17] type 1 class 0x000604
> [    0.187322] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
> [    0.187368] pci 0000:00:05.0: [1002:5a19] type 1 class 0x000604
> [    0.187493] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
> [    0.187536] pci 0000:00:06.0: [1002:5a1a] type 1 class 0x000604
> [    0.187661] pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
> [    0.187713] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604
> [    0.187841] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
> [    0.187884] pci 0000:00:0b.0: [1002:5a1f] type 1 class 0x000604
> [    0.187980] pci 0000:00:0b.0: PME# supported from D0 D3hot D3cold
> [    0.187980] pci 0000:00:0d.0: [1002:5a1e] type 1 class 0x000604
> [    0.187980] pci 0000:00:0d.0: PME# supported from D0 D3hot D3cold
> [    0.187980] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106
> [    0.187980] pci 0000:00:11.0: reg 10: [io  0x7000-0x7007]
> [    0.187980] pci 0000:00:11.0: reg 14: [io  0x6000-0x6003]
> [    0.187980] pci 0000:00:11.0: reg 18: [io  0x5000-0x5007]
> [    0.187980] pci 0000:00:11.0: reg 1c: [io  0x3000-0x3003]
> [    0.187980] pci 0000:00:11.0: reg 20: [io  0x2000-0x200f]
> [    0.187980] pci 0000:00:11.0: reg 24: [mem 0xf98ff000-0xf98ff3ff]
> [    0.187996] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03
> [    0.188027] pci 0000:00:12.0: reg 10: [mem 0xf98fb000-0xf98fbfff]
> [    0.188179] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03
> [    0.188211] pci 0000:00:12.2: reg 10: [mem 0xf98ff400-0xf98ff4ff]
> [    0.188354] pci 0000:00:12.2: supports D1 D2
> [    0.188365] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
> [    0.188406] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03
> [    0.188429] pci 0000:00:13.0: reg 10: [mem 0xf98fc000-0xf98fcfff]
> [    0.188562] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03
> [    0.188594] pci 0000:00:13.2: reg 10: [mem 0xf98ff800-0xf98ff8ff]
> [    0.188744] pci 0000:00:13.2: supports D1 D2
> [    0.188748] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
> [    0.188787] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05
> [    0.188927] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601
> [    0.188980] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604
> [    0.188980] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03
> [    0.188980] pci 0000:00:14.5: reg 10: [mem 0xf98fd000-0xf98fdfff]
> [    0.189002] pci 0000:00:15.0: [1002:43a0] type 1 class 0x000604
> [    0.189153] pci 0000:00:15.0: supports D1 D2
> [    0.189237] pci 0000:00:16.0: [1002:4397] type 0 class 0x000c03
> [    0.189260] pci 0000:00:16.0: reg 10: [mem 0xf98fe000-0xf98fefff]
> [    0.189385] pci 0000:00:16.2: [1002:4396] type 0 class 0x000c03
> [    0.189417] pci 0000:00:16.2: reg 10: [mem 0xf98ffc00-0xf98ffcff]
> [    0.189567] pci 0000:00:16.2: supports D1 D2
> [    0.189571] pci 0000:00:16.2: PME# supported from D0 D1 D2 D3hot
> [    0.189614] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600
> [    0.189700] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600
> [    0.189765] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600
> [    0.189834] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600
> [    0.189920] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600
> [    0.190004] pci 0000:0b:00.0: [10de:06e4] type 0 class 0x000300
> [    0.190026] pci 0000:0b:00.0: reg 10: [mem 0xfd000000-0xfdffffff]
> [    0.190050] pci 0000:0b:00.0: reg 14: [mem 0xd0000000-0xdfffffff 64bit pref]
> [    0.190082] pci 0000:0b:00.0: reg 1c: [mem 0xfa000000-0xfbffffff 64bit]
> [    0.190099] pci 0000:0b:00.0: reg 24: [io  0xe800-0xe87f]
> [    0.190116] pci 0000:0b:00.0: reg 30: [mem 0xfe9e0000-0xfe9fffff pref]
> [    0.192019] pci 0000:00:02.0: PCI bridge to [bus 0b-0b]
> [    0.192032] pci 0000:00:02.0:   bridge window [io  0xe000-0xefff]
> [    0.192040] pci 0000:00:02.0:   bridge window [mem 0xfa000000-0xfe9fffff]
> [    0.192057] pci 0000:00:02.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
> [    0.192166] pci 0000:0a:00.0: [9710:9990] type 0 class 0x000c03
> [    0.192194] pci 0000:0a:00.0: reg 10: [mem 0xf9ff8000-0xf9ff8fff]
> [    0.192404] pci 0000:0a:00.0: supports D1 D2
> [    0.192408] pci 0000:0a:00.0: PME# supported from D0 D1 D2 D3hot
> [    0.192471] pci 0000:0a:00.1: [9710:9990] type 0 class 0x000c03
> [    0.192504] pci 0000:0a:00.1: reg 10: [mem 0xf9ff9000-0xf9ff9fff]
> [    0.192701] pci 0000:0a:00.1: supports D1 D2
> [    0.192705] pci 0000:0a:00.1: PME# supported from D0 D1 D2 D3hot
> [    0.192774] pci 0000:0a:00.2: [9710:9990] type 0 class 0x000c03
> [    0.192801] pci 0000:0a:00.2: reg 10: [mem 0xf9ffa000-0xf9ffafff]
> [    0.192979] pci 0000:0a:00.2: supports D1 D2
> [    0.192979] pci 0000:0a:00.2: PME# supported from D0 D1 D2 D3hot
> [    0.192979] pci 0000:0a:00.3: [9710:9990] type 0 class 0x000c03
> [    0.192979] pci 0000:0a:00.3: reg 10: [mem 0xf9ffb000-0xf9ffbfff]
> [    0.192979] pci 0000:0a:00.3: supports D1 D2
> [    0.192979] pci 0000:0a:00.3: PME# supported from D0 D1 D2 D3hot
> [    0.193038] pci 0000:0a:00.4: [9710:9990] type 0 class 0x000c03
> [    0.193074] pci 0000:0a:00.4: reg 10: [mem 0xf9ffc000-0xf9ffcfff]
> [    0.193286] pci 0000:0a:00.4: supports D1 D2
> [    0.193290] pci 0000:0a:00.4: PME# supported from D0 D1 D2 D3hot
> [    0.193357] pci 0000:0a:00.5: [9710:9990] type 0 class 0x000c03
> [    0.193384] pci 0000:0a:00.5: reg 10: [mem 0xf9ffd000-0xf9ffdfff]
> [    0.193588] pci 0000:0a:00.5: supports D1 D2
> [    0.193592] pci 0000:0a:00.5: PME# supported from D0 D1 D2 D3hot
> [    0.193653] pci 0000:0a:00.6: [9710:9990] type 0 class 0x000c03
> [    0.193687] pci 0000:0a:00.6: reg 10: [mem 0xf9ffe000-0xf9ffefff]
> [    0.193883] pci 0000:0a:00.6: supports D1 D2
> [    0.193887] pci 0000:0a:00.6: PME# supported from D0 D1 D2 D3hot
> [    0.193958] pci 0000:0a:00.7: [9710:9990] type 0 class 0x000c03
> [    0.193979] pci 0000:0a:00.7: reg 10: [mem 0xf9fff000-0xf9ffffff]
> [    0.193979] pci 0000:0a:00.7: supports D1 D2
> [    0.193979] pci 0000:0a:00.7: PME# supported from D0 D1 D2 D3hot
> [    0.195058] pci 0000:00:03.0: PCI bridge to [bus 0a-0a]
> [    0.195071] pci 0000:00:03.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
> [    0.195205] pci 0000:09:00.0: [10ec:8168] type 0 class 0x000200
> [    0.195229] pci 0000:09:00.0: reg 10: [io  0xd800-0xd8ff]
> [    0.195277] pci 0000:09:00.0: reg 18: [mem 0xcffff000-0xcfffffff 64bit pref]
> [    0.195304] pci 0000:09:00.0: reg 20: [mem 0xcfff8000-0xcfffbfff 64bit pref]
> [    0.195324] pci 0000:09:00.0: reg 30: [mem 0xf9ee0000-0xf9efffff pref]
> [    0.195430] pci 0000:09:00.0: supports D1 D2
> [    0.195434] pci 0000:09:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [    0.197018] pci 0000:00:05.0: PCI bridge to [bus 09-09]
> [    0.197030] pci 0000:00:05.0:   bridge window [io  0xd000-0xdfff]
> [    0.197038] pci 0000:00:05.0:   bridge window [mem 0xf9e00000-0xf9efffff]
> [    0.197049] pci 0000:00:05.0:   bridge window [mem 0xcff00000-0xcfffffff 64bit pref]
> [    0.197151] pci 0000:08:00.0: [10ec:8168] type 0 class 0x000200
> [    0.197182] pci 0000:08:00.0: reg 10: [io  0xc800-0xc8ff]
> [    0.197222] pci 0000:08:00.0: reg 18: [mem 0xcfeff000-0xcfefffff 64bit pref]
> [    0.197249] pci 0000:08:00.0: reg 20: [mem 0xcfef8000-0xcfefbfff 64bit pref]
> [    0.197275] pci 0000:08:00.0: reg 30: [mem 0xf9de0000-0xf9dfffff pref]
> [    0.197375] pci 0000:08:00.0: supports D1 D2
> [    0.197379] pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [    0.199002] pci 0000:00:06.0: PCI bridge to [bus 08-08]
> [    0.199012] pci 0000:00:06.0:   bridge window [io  0xc000-0xcfff]
> [    0.199020] pci 0000:00:06.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
> [    0.199030] pci 0000:00:06.0:   bridge window [mem 0xcfe00000-0xcfefffff 64bit pref]
> [    0.199140] pci 0000:06:00.0: [104c:8231] type 1 class 0x000604
> [    0.199335] pci 0000:06:00.0: supports D1 D2
> [    0.199377] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
> [    0.199396] pci 0000:00:0a.0: PCI bridge to [bus 06-07]
> [    0.199410] pci 0000:00:0a.0:   bridge window [mem 0xf9c00000-0xf9cfffff]
> [    0.199561] pci 0000:07:01.0: [1033:0035] type 0 class 0x000c03
> [    0.199600] pci 0000:07:01.0: reg 10: [mem 0xf9cfd000-0xf9cfdfff]
> [    0.199735] pci 0000:07:01.0: Disabling memory decoding and releasing memory resources.
> [    0.199803] pci 0000:07:01.0: supports D1 D2
> [    0.199807] pci 0000:07:01.0: PME# supported from D0 D1 D2 D3hot
> [    0.199864] pci 0000:07:01.1: [1033:0035] type 0 class 0x000c03
> [    0.199910] pci 0000:07:01.1: reg 10: [mem 0xf9cfe000-0xf9cfefff]
> [    0.199978] pci 0000:07:01.1: Disabling memory decoding and releasing memory resources.
> [    0.199978] pci 0000:07:01.1: supports D1 D2
> [    0.199978] pci 0000:07:01.1: PME# supported from D0 D1 D2 D3hot
> [    0.199978] pci 0000:07:01.2: [1033:00e0] type 0 class 0x000c03
> [    0.199978] pci 0000:07:01.2: reg 10: [mem 0xf9cffc00-0xf9cffcff]
> [    0.199978] pci 0000:07:01.2: Disabling memory decoding and releasing memory resources.
> [    0.199978] pci 0000:07:01.2: Rounding up size of resource #0 to 0x1000.
> [    0.199978] pci 0000:07:01.2: supports D1 D2
> [    0.199978] pci 0000:07:01.2: PME# supported from D0 D1 D2 D3hot
> [    0.199978] pci 0000:06:00.0: PCI bridge to [bus 07-07]
> [    0.199978] pci 0000:06:00.0:   bridge window [mem 0xf9c00000-0xf9cfffff]
> [    0.199978] pci 0000:05:00.0: [1002:95c5] type 0 class 0x000300
> [    0.199978] pci 0000:05:00.0: reg 10: [mem 0xb0000000-0xbfffffff 64bit pref]
> [    0.199978] pci 0000:05:00.0: reg 18: [mem 0xf9be0000-0xf9beffff 64bit]
> [    0.199978] pci 0000:05:00.0: reg 20: [io  0xb000-0xb0ff]
> [    0.199978] pci 0000:05:00.0: reg 30: [mem 0xf9bc0000-0xf9bdffff pref]
> [    0.199978] pci 0000:05:00.0: supports D1 D2
> [    0.200017] pci 0000:05:00.1: [1002:aa28] type 0 class 0x000403
> [    0.200060] pci 0000:05:00.1: reg 10: [mem 0xf9bfc000-0xf9bfffff 64bit]
> [    0.200240] pci 0000:05:00.1: supports D1 D2
> [    0.202001] pci 0000:00:0b.0: PCI bridge to [bus 05-05]
> [    0.202011] pci 0000:00:0b.0:   bridge window [io  0xb000-0xbfff]
> [    0.202018] pci 0000:00:0b.0:   bridge window [mem 0xf9b00000-0xf9bfffff]
> [    0.202029] pci 0000:00:0b.0:   bridge window [mem 0xb0000000-0xbfffffff 64bit pref]
> [    0.202133] pci 0000:04:00.0: [9710:9990] type 0 class 0x000c03
> [    0.202159] pci 0000:04:00.0: reg 10: [mem 0xf9af8000-0xf9af8fff]
> [    0.202354] pci 0000:04:00.0: supports D1 D2
> [    0.202358] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot
> [    0.202426] pci 0000:04:00.1: [9710:9990] type 0 class 0x000c03
> [    0.202452] pci 0000:04:00.1: reg 10: [mem 0xf9af9000-0xf9af9fff]
> [    0.202653] pci 0000:04:00.1: supports D1 D2
> [    0.202658] pci 0000:04:00.1: PME# supported from D0 D1 D2 D3hot
> [    0.202717] pci 0000:04:00.2: [9710:9990] type 0 class 0x000c03
> [    0.202750] pci 0000:04:00.2: reg 10: [mem 0xf9afa000-0xf9afafff]
> [    0.202945] pci 0000:04:00.2: supports D1 D2
> [    0.202949] pci 0000:04:00.2: PME# supported from D0 D1 D2 D3hot
> [    0.202978] pci 0000:04:00.3: [9710:9990] type 0 class 0x000c03
> [    0.202978] pci 0000:04:00.3: reg 10: [mem 0xf9afb000-0xf9afbfff]
> [    0.203054] pci 0000:04:00.3: supports D1 D2
> [    0.203065] pci 0000:04:00.3: PME# supported from D0 D1 D2 D3hot
> [    0.203124] pci 0000:04:00.4: [9710:9990] type 0 class 0x000c03
> [    0.203185] pci 0000:04:00.4: reg 10: [mem 0xf9afc000-0xf9afcfff]
> [    0.203373] pci 0000:04:00.4: supports D1 D2
> [    0.203380] pci 0000:04:00.4: PME# supported from D0 D1 D2 D3hot
> [    0.203447] pci 0000:04:00.5: [9710:9990] type 0 class 0x000c03
> [    0.203474] pci 0000:04:00.5: reg 10: [mem 0xf9afd000-0xf9afdfff]
> [    0.203675] pci 0000:04:00.5: supports D1 D2
> [    0.203679] pci 0000:04:00.5: PME# supported from D0 D1 D2 D3hot
> [    0.203738] pci 0000:04:00.6: [9710:9990] type 0 class 0x000c03
> [    0.203771] pci 0000:04:00.6: reg 10: [mem 0xf9afe000-0xf9afefff]
> [    0.203966] pci 0000:04:00.6: supports D1 D2
> [    0.203970] pci 0000:04:00.6: PME# supported from D0 D1 D2 D3hot
> [    0.203977] pci 0000:04:00.7: [9710:9990] type 0 class 0x000c03
> [    0.203977] pci 0000:04:00.7: reg 10: [mem 0xf9aff000-0xf9afffff]
> [    0.203977] pci 0000:04:00.7: supports D1 D2
> [    0.203977] pci 0000:04:00.7: PME# supported from D0 D1 D2 D3hot
> [    0.205070] pci 0000:00:0d.0: PCI bridge to [bus 04-04]
> [    0.205085] pci 0000:00:0d.0:   bridge window [mem 0xf9a00000-0xf9afffff]
> [    0.205152] pci 0000:03:06.0: [13f6:0111] type 0 class 0x000401
> [    0.205194] pci 0000:03:06.0: reg 10: [io  0xa800-0xa8ff]
> [    0.205352] pci 0000:03:06.0: supports D1 D2
> [    0.205432] pci 0000:00:14.4: PCI bridge to [bus 03-03] (subtractive decode)
> [    0.205476] pci 0000:00:14.4:   bridge window [io  0xa000-0xafff]
> [    0.205488] pci 0000:00:14.4:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
> [    0.205494] pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff] (subtractive decode)
> [    0.205500] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
> [    0.205506] pci 0000:00:14.4:   bridge window [mem 0x000d0000-0x000dffff] (subtractive decode)
> [    0.205512] pci 0000:00:14.4:   bridge window [mem 0xb0000000-0xdfffffff] (subtractive decode)
> [    0.205518] pci 0000:00:14.4:   bridge window [mem 0xf0000000-0xfebfffff] (subtractive decode)
> [    0.205604] pci 0000:00:15.0: PCI bridge to [bus 02-02]
> [    0.205687] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> [    0.205926] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC02._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC03._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC05._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC06._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0B._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0D._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
> [    0.205981] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE20._PRT]
> [    0.206241]  pci0000:00: Requesting ACPI _OSC control (0x1d)
> [    0.206571]  pci0000:00: ACPI _OSC control (0x1d) granted
> [    0.233186] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 7 *10 11 14 15)
> [    0.234003] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 14 15)
> [    0.234169] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 14 15)
> [    0.234321] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15)
> [    0.234457] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15)
> [    0.234559] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15)
> [    0.234656] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15)
> [    0.234755] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 *10 11 14 15)
> [    0.235025] xen/balloon: Initialising balloon driver.
> [    0.235074] xen-balloon: Initialising balloon driver.
> [    0.235158] vgaarb: device added: PCI:0000:0b:00.0,decodes=io+mem,owns=io+mem,locks=none
> [    0.235158] vgaarb: device added: PCI:0000:05:00.0,decodes=io+mem,owns=none,locks=none
> [    0.235158] vgaarb: loaded
> [    0.235158] vgaarb: bridge control possible 0000:05:00.0
> [    0.235158] vgaarb: bridge control possible 0000:0b:00.0
> [    0.236066] SCSI subsystem initialized
> [    0.236086] libata version 3.00 loaded.
> [    0.236086] usbcore: registered new interface driver usbfs
> [    0.237032] usbcore: registered new interface driver hub
> [    0.237075] usbcore: registered new device driver usb
> [    0.237143] Advanced Linux Sound Architecture Driver Version 1.0.24.
> [    0.237143] PCI: Using ACPI for IRQ routing
> [    0.244971] PCI: pci_cache_line_size set to 64 bytes
> [    0.245035] reserve RAM buffer: 000000000009b000 - 000000000009ffff 
> [    0.245158] NetLabel: Initializing
> [    0.245158] NetLabel:  domain hash size = 128
> [    0.245158] NetLabel:  protocols = UNLABELED CIPSOv4
> [    0.245158] NetLabel:  unlabeled traffic allowed by default
> [    0.245313] Switching to clocksource xen
> [    0.245448] pnp: PnP ACPI init
> [    0.245448] ACPI: bus type pnp registered
> [    0.245494] pnp 00:00: [bus 00-ff]
> [    0.245499] pnp 00:00: [io  0x0cf8-0x0cff]
> [    0.245505] pnp 00:00: [io  0x0000-0x0cf7 window]
> [    0.245509] pnp 00:00: [io  0x0d00-0xffff window]
> [    0.245514] pnp 00:00: [mem 0x000a0000-0x000bffff window]
> [    0.245519] pnp 00:00: [mem 0x000d0000-0x000dffff window]
> [    0.245525] pnp 00:00: [mem 0xb0000000-0xdfffffff window]
> [    0.245530] pnp 00:00: [mem 0xf0000000-0xfebfffff window]
> [    0.245821] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
> [    0.245994] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled]
> [    0.246000] pnp 00:01: [mem 0xfec20000-0xfec200ff]
> [    0.246266] system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved
> [    0.246275] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.246402] pnp 00:02: [mem 0xf6000000-0xf6003fff]
> [    0.246646] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved
> [    0.246654] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.246939] pnp 00:03: [dma 4]
> [    0.246943] pnp 00:03: [io  0x0000-0x000f]
> [    0.246946] pnp 00:03: [io  0x0081-0x0083]
> [    0.246950] pnp 00:03: [io  0x0087]
> [    0.246954] pnp 00:03: [io  0x0089-0x008b]
> [    0.246957] pnp 00:03: [io  0x008f]
> [    0.246963] pnp 00:03: [io  0x00c0-0x00df]
> [    0.247167] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)
> [    0.247198] pnp 00:04: [io  0x0070-0x0071]
> [    0.247203] xen: registering gsi 8 triggering 1 polarity 0
> [    0.247211] xen_map_pirq_gsi: returning irq 8 for gsi 8
> [    0.247215] xen: --> pirq=8 -> irq=8 (gsi=8)
> [    0.247232] pnp 00:04: [irq 8]
> [    0.247433] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)
> [    0.247514] pnp 00:05: [io  0x0061]
> [    0.247753] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
> [    0.247772] pnp 00:06: [io  0x00f0-0x00ff]
> [    0.247777] xen: registering gsi 13 triggering 1 polarity 0
> [    0.247782] xen_map_pirq_gsi: returning irq 13 for gsi 13
> [    0.247787] xen: --> pirq=13 -> irq=13 (gsi=13)
> [    0.247803] pnp 00:06: [irq 13]
> [    0.247999] pnp 00:06: Plug and Play ACPI device, IDs PNP0c04 (active)
> [    0.248431] pnp 00:07: [io  0x03f8-0x03ff]
> [    0.248436] xen: registering gsi 4 triggering 1 polarity 0
> [    0.248442] xen_map_pirq_gsi: returning irq 4 for gsi 4
> [    0.248446] xen: --> pirq=4 -> irq=4 (gsi=4)
> [    0.248450] Already setup the GSI :4
> [    0.248454] pnp 00:07: [irq 4]
> [    0.248457] pnp 00:07: [dma 0 disabled]
> [    0.248699] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active)
> [    0.248860] pnp 00:08: [io  0x0000-0xffffffffffffffff disabled]
> [    0.248865] pnp 00:08: [io  0x0600-0x06df]
> [    0.248869] pnp 00:08: [io  0x0ae0-0x0aef]
> [    0.249198] system 00:08: [io  0x0600-0x06df] has been reserved
> [    0.249205] system 00:08: [io  0x0ae0-0x0aef] has been reserved
> [    0.249212] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.249265] pnp 00:09: [mem 0xfed00000-0xfed003ff]
> [    0.249479] pnp 00:09: Plug and Play ACPI device, IDs PNP0103 (active)
> [    0.249637] pnp 00:0a: [io  0x0060]
> [    0.249641] pnp 00:0a: [io  0x0064]
> [    0.249645] pnp 00:0a: [mem 0xfec00000-0xfec00fff]
> [    0.249649] pnp 00:0a: [mem 0xfee00000-0xfee00fff]
> [    0.249944] system 00:0a: [mem 0xfec00000-0xfec00fff] could not be reserved
> [    0.249951] system 00:0a: [mem 0xfee00000-0xfee00fff] has been reserved
> [    0.249958] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.250244] pnp 00:0b: [io  0x0010-0x001f]
> [    0.250248] pnp 00:0b: [io  0x0022-0x003f]
> [    0.250255] pnp 00:0b: [io  0x0062-0x0063]
> [    0.250259] pnp 00:0b: [io  0x0065-0x006f]
> [    0.250263] pnp 00:0b: [io  0x0072-0x007f]
> [    0.250266] pnp 00:0b: [io  0x0080]
> [    0.250270] pnp 00:0b: [io  0x0084-0x0086]
> [    0.250274] pnp 00:0b: [io  0x0088]
> [    0.250277] pnp 00:0b: [io  0x008c-0x008e]
> [    0.250281] pnp 00:0b: [io  0x0090-0x009f]
> [    0.250284] pnp 00:0b: [io  0x00a2-0x00bf]
> [    0.250288] pnp 00:0b: [io  0x00b1]
> [    0.250292] pnp 00:0b: [io  0x00e0-0x00ef]
> [    0.250295] pnp 00:0b: [io  0x04d0-0x04d1]
> [    0.250299] pnp 00:0b: [io  0x040b]
> [    0.250303] pnp 00:0b: [io  0x04d6]
> [    0.250306] pnp 00:0b: [io  0x0c00-0x0c01]
> [    0.250317] pnp 00:0b: [io  0x0c14]
> [    0.250320] pnp 00:0b: [io  0x0c50-0x0c51]
> [    0.250324] pnp 00:0b: [io  0x0c52]
> [    0.250327] pnp 00:0b: [io  0x0c6c]
> [    0.250331] pnp 00:0b: [io  0x0c6f]
> [    0.250334] pnp 00:0b: [io  0x0cd0-0x0cd1]
> [    0.250338] pnp 00:0b: [io  0x0cd2-0x0cd3]
> [    0.250342] pnp 00:0b: [io  0x0cd4-0x0cd5]
> [    0.250346] pnp 00:0b: [io  0x0cd6-0x0cd7]
> [    0.250349] pnp 00:0b: [io  0x0cd8-0x0cdf]
> [    0.250353] pnp 00:0b: [io  0x0800-0x089f]
> [    0.250357] pnp 00:0b: [io  0x0000-0xffffffffffffffff disabled]
> [    0.250362] pnp 00:0b: [io  0x0b00-0x0b1f]
> [    0.250365] pnp 00:0b: [io  0x0b20-0x0b3f]
> [    0.250369] pnp 00:0b: [io  0x0900-0x090f]
> [    0.250373] pnp 00:0b: [io  0x0910-0x091f]
> [    0.250377] pnp 00:0b: [io  0xfe00-0xfefe]
> [    0.250380] pnp 00:0b: [io  0x0060]
> [    0.250384] pnp 00:0b: [io  0x0064]
> [    0.250388] pnp 00:0b: [mem 0x00000000-0xffffffffffffffff disabled]
> [    0.250393] pnp 00:0b: [mem 0xffb80000-0xffbfffff]
> [    0.250404] pnp 00:0b: [mem 0xfec10000-0xfec1001f]
> [    0.250408] pnp 00:0b: [mem 0xfed80000-0xfed80fff]
> [    0.250412] pnp 00:0b: [mem 0x00000000-0xffffffffffffffff disabled]
> [    0.250790] system 00:0b: [io  0x04d0-0x04d1] has been reserved
> [    0.250796] system 00:0b: [io  0x040b] has been reserved
> [    0.250801] system 00:0b: [io  0x04d6] has been reserved
> [    0.250806] system 00:0b: [io  0x0c00-0x0c01] has been reserved
> [    0.250811] system 00:0b: [io  0x0c14] has been reserved
> [    0.250816] system 00:0b: [io  0x0c50-0x0c51] has been reserved
> [    0.250821] system 00:0b: [io  0x0c52] has been reserved
> [    0.250826] system 00:0b: [io  0x0c6c] has been reserved
> [    0.250838] system 00:0b: [io  0x0c6f] has been reserved
> [    0.250843] system 00:0b: [io  0x0cd0-0x0cd1] has been reserved
> [    0.250848] system 00:0b: [io  0x0cd2-0x0cd3] has been reserved
> [    0.250853] system 00:0b: [io  0x0cd4-0x0cd5] has been reserved
> [    0.250859] system 00:0b: [io  0x0cd6-0x0cd7] has been reserved
> [    0.250864] system 00:0b: [io  0x0cd8-0x0cdf] has been reserved
> [    0.250869] system 00:0b: [io  0x0800-0x089f] has been reserved
> [    0.250874] system 00:0b: [io  0x0b00-0x0b1f] has been reserved
> [    0.250879] system 00:0b: [io  0x0b20-0x0b3f] has been reserved
> [    0.250885] system 00:0b: [io  0x0900-0x090f] has been reserved
> [    0.250890] system 00:0b: [io  0x0910-0x091f] has been reserved
> [    0.250895] system 00:0b: [io  0xfe00-0xfefe] has been reserved
> [    0.250901] system 00:0b: [mem 0xffb80000-0xffbfffff] has been reserved
> [    0.250907] system 00:0b: [mem 0xfec10000-0xfec1001f] has been reserved
> [    0.250912] system 00:0b: [mem 0xfed80000-0xfed80fff] has been reserved
> [    0.250927] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.251015] pnp 00:0c: [mem 0xe0000000-0xefffffff]
> [    0.251333] system 00:0c: [mem 0xe0000000-0xefffffff] has been reserved
> [    0.251342] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.251569] pnp 00:0d: [mem 0x00000000-0x0009ffff]
> [    0.251573] pnp 00:0d: [mem 0x000c0000-0x000cffff]
> [    0.251578] pnp 00:0d: [mem 0x000e0000-0x000fffff]
> [    0.251582] pnp 00:0d: [mem 0x00100000-0xafffffff]
> [    0.251586] pnp 00:0d: [mem 0xfec00000-0xffffffff]
> [    0.251927] system 00:0d: [mem 0x00000000-0x0009ffff] could not be reserved
> [    0.251934] system 00:0d: [mem 0x000c0000-0x000cffff] could not be reserved
> [    0.251939] system 00:0d: [mem 0x000e0000-0x000fffff] could not be reserved
> [    0.251945] system 00:0d: [mem 0x00100000-0xafffffff] could not be reserved
> [    0.251952] system 00:0d: [mem 0xfec00000-0xffffffff] could not be reserved
> [    0.251960] system 00:0d: Plug and Play ACPI device, IDs PNP0c01 (active)
> [    0.252199] pnp: PnP ACPI: found 14 devices
> [    0.252203] ACPI: ACPI bus type pnp unregistered
> [    0.254401] pciback 0000:0a:00.0: seizing device
> [    0.254487] pciback 0000:0a:00.1: seizing device
> [    0.254566] pciback 0000:0a:00.2: seizing device
> [    0.254639] pciback 0000:0a:00.3: seizing device
> [    0.254746] pciback 0000:0a:00.4: seizing device
> [    0.254825] pciback 0000:0a:00.5: seizing device
> [    0.254907] pciback 0000:0a:00.6: seizing device
> [    0.254982] pciback 0000:0a:00.7: seizing device
> [    0.255296] pciback 0000:07:01.0: seizing device
> [    0.255375] pciback 0000:07:01.1: seizing device
> [    0.255455] pciback 0000:07:01.2: seizing device
> [    0.255529] pciback 0000:05:00.0: seizing device
> [    0.255608] pciback 0000:05:00.1: seizing device
> [    0.255690] pciback 0000:04:00.0: seizing device
> [    0.255762] pciback 0000:04:00.1: seizing device
> [    0.255842] pciback 0000:04:00.2: seizing device
> [    0.255922] pciback 0000:04:00.3: seizing device
> [    0.256001] pciback 0000:04:00.4: seizing device
> [    0.256117] pciback 0000:04:00.5: seizing device
> [    0.256192] pciback 0000:04:00.6: seizing device
> [    0.256274] pciback 0000:04:00.7: seizing device
> [    0.256353] pciback 0000:03:06.0: seizing device
> [    0.266456] PM-Timer failed consistency check  (0x0xffffff) - aborting.
> [    0.266551] PCI: max bus depth: 2 pci_try_num: 3
> [    0.266657] pci 0000:00:02.0: PCI bridge to [bus 0b-0b]
> [    0.266664] pci 0000:00:02.0:   bridge window [io  0xe000-0xefff]
> [    0.266673] pci 0000:00:02.0:   bridge window [mem 0xfa000000-0xfe9fffff]
> [    0.266681] pci 0000:00:02.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
> [    0.266700] pci 0000:00:03.0: PCI bridge to [bus 0a-0a]
> [    0.266708] pci 0000:00:03.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
> [    0.266721] pci 0000:00:05.0: PCI bridge to [bus 09-09]
> [    0.266727] pci 0000:00:05.0:   bridge window [io  0xd000-0xdfff]
> [    0.266735] pci 0000:00:05.0:   bridge window [mem 0xf9e00000-0xf9efffff]
> [    0.266743] pci 0000:00:05.0:   bridge window [mem 0xcff00000-0xcfffffff 64bit pref]
> [    0.266754] pci 0000:00:06.0: PCI bridge to [bus 08-08]
> [    0.266760] pci 0000:00:06.0:   bridge window [io  0xc000-0xcfff]
> [    0.266769] pci 0000:00:06.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
> [    0.266783] pci 0000:00:06.0:   bridge window [mem 0xcfe00000-0xcfefffff 64bit pref]
> [    0.266796] pciback 0000:07:01.0: BAR 0: assigned [mem 0xf9c00000-0xf9c00fff]
> [    0.266808] pciback 0000:07:01.1: BAR 0: assigned [mem 0xf9c01000-0xf9c01fff]
> [    0.266818] pciback 0000:07:01.2: BAR 0: assigned [mem 0xf9c02000-0xf9c02fff]
> [    0.266829] pci 0000:06:00.0: PCI bridge to [bus 07-07]
> [    0.266840] pci 0000:06:00.0:   bridge window [mem 0xf9c00000-0xf9cfffff]
> [    0.266858] pci 0000:00:0a.0: PCI bridge to [bus 06-07]
> [    0.266873] pci 0000:00:0a.0:   bridge window [mem 0xf9c00000-0xf9cfffff]
> [    0.266887] pci 0000:00:0b.0: PCI bridge to [bus 05-05]
> [    0.266892] pci 0000:00:0b.0:   bridge window [io  0xb000-0xbfff]
> [    0.266901] pci 0000:00:0b.0:   bridge window [mem 0xf9b00000-0xf9bfffff]
> [    0.266909] pci 0000:00:0b.0:   bridge window [mem 0xb0000000-0xbfffffff 64bit pref]
> [    0.266920] pci 0000:00:0d.0: PCI bridge to [bus 04-04]
> [    0.266929] pci 0000:00:0d.0:   bridge window [mem 0xf9a00000-0xf9afffff]
> [    0.266942] pci 0000:00:14.4: PCI bridge to [bus 03-03]
> [    0.266956] pci 0000:00:14.4:   bridge window [io  0xa000-0xafff]
> [    0.266976] pci 0000:00:15.0: PCI bridge to [bus 02-02]
> [    0.267004] xen: registering gsi 52 triggering 0 polarity 1
> [    0.267020] xen: --> pirq=52 -> irq=52 (gsi=52)
> [    0.267048] xen: registering gsi 52 triggering 0 polarity 1
> [    0.267076] xen_map_pirq_gsi: returning irq 52 for gsi 52
> [    0.267081] xen: --> pirq=52 -> irq=52 (gsi=52)
> [    0.267085] Already setup the GSI :52
> [    0.267095] xen: registering gsi 52 triggering 0 polarity 1
> [    0.267100] xen_map_pirq_gsi: returning irq 52 for gsi 52
> [    0.267105] xen: --> pirq=52 -> irq=52 (gsi=52)
> [    0.267109] Already setup the GSI :52
> [    0.267118] xen: registering gsi 53 triggering 0 polarity 1
> [    0.267164] xen: --> pirq=53 -> irq=53 (gsi=53)
> [    0.267181] xen: registering gsi 54 triggering 0 polarity 1
> [    0.267191] xen: --> pirq=54 -> irq=54 (gsi=54)
> [    0.267215] xen: registering gsi 54 triggering 0 polarity 1
> [    0.267220] xen_map_pirq_gsi: returning irq 54 for gsi 54
> [    0.267225] xen: --> pirq=54 -> irq=54 (gsi=54)
> [    0.267229] Already setup the GSI :54
> [    0.267239] xen: registering gsi 54 triggering 0 polarity 1
> [    0.267243] xen_map_pirq_gsi: returning irq 54 for gsi 54
> [    0.267248] xen: --> pirq=54 -> irq=54 (gsi=54)
> [    0.267252] Already setup the GSI :54
> [    0.267270] xen: registering gsi 16 triggering 0 polarity 1
> [    0.267280] xen: --> pirq=16 -> irq=16 (gsi=16)
> [    0.267302] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
> [    0.267307] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
> [    0.267311] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
> [    0.267316] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff]
> [    0.267321] pci_bus 0000:00: resource 8 [mem 0xb0000000-0xdfffffff]
> [    0.267326] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfebfffff]
> [    0.267331] pci_bus 0000:0b: resource 0 [io  0xe000-0xefff]
> [    0.267335] pci_bus 0000:0b: resource 1 [mem 0xfa000000-0xfe9fffff]
> [    0.267340] pci_bus 0000:0b: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref]
> [    0.267346] pci_bus 0000:0a: resource 1 [mem 0xf9f00000-0xf9ffffff]
> [    0.267351] pci_bus 0000:09: resource 0 [io  0xd000-0xdfff]
> [    0.267355] pci_bus 0000:09: resource 1 [mem 0xf9e00000-0xf9efffff]
> [    0.267360] pci_bus 0000:09: resource 2 [mem 0xcff00000-0xcfffffff 64bit pref]
> [    0.267366] pci_bus 0000:08: resource 0 [io  0xc000-0xcfff]
> [    0.267370] pci_bus 0000:08: resource 1 [mem 0xf9d00000-0xf9dfffff]
> [    0.267375] pci_bus 0000:08: resource 2 [mem 0xcfe00000-0xcfefffff 64bit pref]
> [    0.267388] pci_bus 0000:06: resource 1 [mem 0xf9c00000-0xf9cfffff]
> [    0.267393] pci_bus 0000:07: resource 1 [mem 0xf9c00000-0xf9cfffff]
> [    0.267398] pci_bus 0000:05: resource 0 [io  0xb000-0xbfff]
> [    0.267402] pci_bus 0000:05: resource 1 [mem 0xf9b00000-0xf9bfffff]
> [    0.267407] pci_bus 0000:05: resource 2 [mem 0xb0000000-0xbfffffff 64bit pref]
> [    0.267413] pci_bus 0000:04: resource 1 [mem 0xf9a00000-0xf9afffff]
> [    0.267418] pci_bus 0000:03: resource 0 [io  0xa000-0xafff]
> [    0.267422] pci_bus 0000:03: resource 4 [io  0x0000-0x0cf7]
> [    0.267427] pci_bus 0000:03: resource 5 [io  0x0d00-0xffff]
> [    0.267431] pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000bffff]
> [    0.267436] pci_bus 0000:03: resource 7 [mem 0x000d0000-0x000dffff]
> [    0.267441] pci_bus 0000:03: resource 8 [mem 0xb0000000-0xdfffffff]
> [    0.267446] pci_bus 0000:03: resource 9 [mem 0xf0000000-0xfebfffff]
> [    0.267504] NET: Registered protocol family 2
> [    0.267823] IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
> [    0.268951] TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
> [    0.270481] TCP bind hash table entries: 65536 (order: 10, 4194304 bytes)
> [    0.278788] TCP: Hash tables configured (established 131072 bind 65536)
> [    0.278811] TCP reno registered
> [    0.278846] UDP hash table entries: 512 (order: 4, 81920 bytes)
> [    0.278995] UDP-Lite hash table entries: 512 (order: 4, 81920 bytes)
> [    0.279304] NET: Registered protocol family 1
> [    0.279601] RPC: Registered named UNIX socket transport module.
> [    0.279641] RPC: Registered udp transport module.
> [    0.279645] RPC: Registered tcp transport module.
> [    0.279649] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.568176] pci 0000:0b:00.0: Boot video device
> [    0.568355] pci 0000:06:00.0: TI XIO2000a quirk detected; secondary bus fast back-to-back transfers disabled
> [    0.568573] PCI: CLS 64 bytes, default 64
> [    0.568704] Trying to unpack rootfs image as initramfs...
> [    0.582105] Freeing initrd memory: 6724k freed
> [    0.587967] DMA-API: preallocated 32768 debug entries
> [    0.587978] DMA-API: debugging enabled by kernel config
> [    0.590485] microcode: CPU0: patch_level=0x010000bf
> [    0.590512] microcode: CPU1: patch_level=0x010000bf
> [    0.590555] microcode: CPU2: patch_level=0x010000bf
> [    0.590632] microcode: CPU3: patch_level=0x010000bf
> [    0.590724] microcode: CPU4: patch_level=0x010000bf
> [    0.590799] microcode: CPU5: patch_level=0x010000bf
> [    0.590952] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [    0.591823] Intel AES-NI instructions are not detected.
> [    0.592331] audit: initializing netlink socket (disabled)
> [    0.592371] type=2000 audit(1326371114.069:1): initialized
> [    0.613325] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    0.623529] VFS: Disk quotas dquot_6.5.2
> [    0.623768] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    0.626441] NTFS driver 2.1.30 [Flags: R/W].
> [    0.626815] fuse init (API version 7.17)
> [    0.628471] Btrfs loaded
> [    0.628483] msgmni has been set to 1829
> [    0.628851] SELinux:  Registering netfilter hooks
> [    0.630559] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> [    0.630575] io scheduler noop registered
> [    0.630579] io scheduler deadline registered
> [    0.630709] io scheduler cfq registered (default)
> [    0.630715] start plist test
> [    0.631700] end plist test
> [    0.631704] list_sort_test: start testing list_sort()
> [    0.635935] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [    0.636239] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
> [    0.636541] usbcore: registered new interface driver udlfb
> [    0.636651] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
> [    0.636657] vesafb: scrolling: redraw
> [    0.636661] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> [    0.639640] vesafb: framebuffer at 0xfb000000, mapped to 0xffffc90010880000, using 10240k, total 14336k
> [    0.661272] Console: switching to colour frame buffer device 160x64
> [    0.681729] fb0: VESA VGA frame buffer device
> [    0.682268] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
> [    0.682480] ACPI: Power Button [PWRB]
> [    0.682756] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
> [    0.682939] ACPI: Power Button [PWRF]
> [    0.687848] Event-channel device installed.
> [    0.688305] xen: registering gsi 22 triggering 0 polarity 1
> [    0.688462] xen: --> pirq=22 -> irq=22 (gsi=22)
> [    0.688652] xen: registering gsi 43 triggering 0 polarity 1
> [    0.688806] xen: --> pirq=43 -> irq=43 (gsi=43)
> [    0.688982] xen: registering gsi 43 triggering 0 polarity 1
> [    0.689139] xen_map_pirq_gsi: returning irq 43 for gsi 43
> [    0.689276] xen: --> pirq=43 -> irq=43 (gsi=43)
> [    0.689398] Already setup the GSI :43
> [    0.689540] xen: registering gsi 42 triggering 0 polarity 1
> [    0.689716] xen: --> pirq=42 -> irq=42 (gsi=42)
> [    0.689893] xen: registering gsi 42 triggering 0 polarity 1
> [    0.690041] xen_map_pirq_gsi: returning irq 42 for gsi 42
> [    0.690134] xen: --> pirq=42 -> irq=42 (gsi=42)
> [    0.690308] Already setup the GSI :42
> [    0.690457] xen: registering gsi 41 triggering 0 polarity 1
> [    0.690610] xen: --> pirq=41 -> irq=41 (gsi=41)
> [    0.690785] xen: registering gsi 41 triggering 0 polarity 1
> [    0.690927] xen_map_pirq_gsi: returning irq 41 for gsi 41
> [    0.691098] xen: --> pirq=41 -> irq=41 (gsi=41)
> [    0.691218] Already setup the GSI :41
> [    0.691361] xen: registering gsi 40 triggering 0 polarity 1
> [    0.691516] xen: --> pirq=40 -> irq=40 (gsi=40)
> [    0.691691] xen: registering gsi 40 triggering 0 polarity 1
> [    0.691839] xen_map_pirq_gsi: returning irq 40 for gsi 40
> [    0.691983] xen: --> pirq=40 -> irq=40 (gsi=40)
> [    0.692103] Already setup the GSI :40
> [    0.692247] xen: registering gsi 33 triggering 0 polarity 1
> [    0.692395] xen: --> pirq=33 -> irq=33 (gsi=33)
> [    0.698730] pciback 0000:05:00.0: enabling device (0000 -> 0003)
> [    0.699683] xen: registering gsi 32 triggering 0 polarity 1
> [    0.711332] xen: --> pirq=32 -> irq=32 (gsi=32)
> [    0.717614] pciback 0000:07:01.2: enabling device (0114 -> 0116)
> [    0.718576] xen: registering gsi 46 triggering 0 polarity 1
> [    0.730341] xen: --> pirq=46 -> irq=46 (gsi=46)
> [    0.736752] pciback 0000:07:01.1: enabling device (0114 -> 0116)
> [    0.737711] xen: registering gsi 45 triggering 0 polarity 1
> [    0.749678] xen: --> pirq=45 -> irq=45 (gsi=45)
> [    0.756061] pciback 0000:07:01.0: enabling device (0114 -> 0116)
> [    0.757003] xen: registering gsi 44 triggering 0 polarity 1
> [    0.769033] xen: --> pirq=44 -> irq=44 (gsi=44)
> [    0.775579] xen: registering gsi 31 triggering 0 polarity 1
> [    0.782167] xen: --> pirq=31 -> irq=31 (gsi=31)
> [    0.788821] xen: registering gsi 31 triggering 0 polarity 1
> [    0.795438] xen_map_pirq_gsi: returning irq 31 for gsi 31
> [    0.796434] xen: --> pirq=31 -> irq=31 (gsi=31)
> [    0.808579] Already setup the GSI :31
> [    0.815143] xen: registering gsi 30 triggering 0 polarity 1
> [    0.821685] xen: --> pirq=30 -> irq=30 (gsi=30)
> [    0.828206] xen: registering gsi 30 triggering 0 polarity 1
> [    0.834740] xen_map_pirq_gsi: returning irq 30 for gsi 30
> [    0.841088] xen: --> pirq=30 -> irq=30 (gsi=30)
> [    0.841258] Already setup the GSI :30
> [    0.841323] xen: registering gsi 29 triggering 0 polarity 1
> [    0.841332] xen: --> pirq=29 -> irq=29 (gsi=29)
> [    0.841423] xen: registering gsi 29 triggering 0 polarity 1
> [    0.841425] xen_map_pirq_gsi: returning irq 29 for gsi 29
> [    0.841426] xen: --> pirq=29 -> irq=29 (gsi=29)
> [    0.841427] Already setup the GSI :29
> [    0.841504] xen: registering gsi 28 triggering 0 polarity 1
> [    0.841512] xen: --> pirq=28 -> irq=28 (gsi=28)
> [    0.841597] xen: registering gsi 28 triggering 0 polarity 1
> [    0.841599] xen_map_pirq_gsi: returning irq 28 for gsi 28
> [    0.841600] xen: --> pirq=28 -> irq=28 (gsi=28)
> [    0.841602] Already setup the GSI :28
> [    0.841796] xen-pciback: backend is passthrough
> [    0.843175] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    0.968633] hpet_acpi_add: no address or irqs in _CRS
> [    0.974946] Non-volatile memory driver v1.3
> [    0.975933] Linux agpgart interface v0.103
> [    0.989830] [drm] Initialized drm 1.1.0 20060810
> [    0.990807] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
> [    1.002136] i2c-core: driver [ch7006] using legacy suspend method
> [    1.003131] i2c-core: driver [ch7006] using legacy resume method
> [    1.019267] brd: module loaded
> [    1.041714] loop: module loaded
> [    1.049261] ahci 0000:00:11.0: version 3.0
> [    1.050245] xen: registering gsi 19 triggering 0 polarity 1
> [    1.061428] xen: --> pirq=19 -> irq=19 (gsi=19)
> [    1.067690] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [    1.073913] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
> [    1.083160] scsi0 : ahci
> [    1.089730] scsi1 : ahci
> [    1.096185] scsi2 : ahci
> [    1.102635] scsi3 : ahci
> [    1.108913] scsi4 : ahci
> [    1.115086] scsi5 : ahci
> [    1.121331] ata1: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff100 irq 342
> [    1.122275] ata2: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff180 irq 342
> [    1.122275] ata3: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff200 irq 342
> [    1.122275] ata4: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff280 irq 342
> [    1.122275] ata5: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff300 irq 342
> [    1.122275] ata6: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff380 irq 342
> [    1.156239] tun: Universal TUN/TAP device driver, 1.6
> [    1.157234] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [    1.167296] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
> [    1.168288] e1000: Copyright (c) 1999-2006 Intel Corporation.
> [    1.178258] sky2: driver version 1.30
> [    1.184032] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    1.185019] xen: registering gsi 46 triggering 0 polarity 1
> [    1.194899] xen_map_pirq_gsi: returning irq 46 for gsi 46
> [    1.195889] xen: --> pirq=46 -> irq=46 (gsi=46)
> [    1.205721] Already setup the GSI :46
> [    1.212142] r8169 0000:09:00.0: eth0: RTL8168d/8111d at 0xffffc900001f8000, 40:61:86:f4:67:d9, XID 081000c0 IRQ 343
> [    1.213061] r8169 0000:09:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
> [    1.223683] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    1.229362] xen: registering gsi 51 triggering 0 polarity 1
> [    1.235058] xen: --> pirq=51 -> irq=51 (gsi=51)
> [    1.241802] r8169 0000:08:00.0: eth1: RTL8168d/8111d at 0xffffc900001fa000, 40:61:86:f4:67:d8, XID 081000c0 IRQ 344
> [    1.242278] r8169 0000:08:00.0: eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko]
> [    1.255129] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    1.256099] ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96
> [    1.267332] xen: registering gsi 17 triggering 0 polarity 1
> [    1.273357] xen: --> pirq=17 -> irq=17 (gsi=17)
> [    1.279398] ehci_hcd 0000:00:12.2: EHCI Host Controller
> [    1.285489] drivers/usb/core/inode.c: creating file 'devices'
> [    1.286464] drivers/usb/core/inode.c: creating file '001'
> [    1.297803] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
> [    1.298786] ehci_hcd 0000:00:12.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
> [    1.298786] ehci_hcd 0000:00:12.2: reset hcc_params a072 thresh 7 uframes 256/512/1024
> [    1.316312] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    1.322751] QUIRK: Enable AMD PLL fix
> [    1.323658] ehci_hcd 0000:00:12.2: debug port 1
> [    1.323658] ehci_hcd 0000:00:12.2: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
> [    1.323658] ehci_hcd 0000:00:12.2: MWI active
> [    1.323658] ehci_hcd 0000:00:12.2: supports USB remote wakeup
> [    1.354124] ehci_hcd 0000:00:12.2: irq 17, io mem 0xf98ff400
> [    1.355084] ehci_hcd 0000:00:12.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    1.373082] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
> [    1.379498] usb usb1: default language 0x0409
> [    1.385764] usb usb1: udev 1, busnum 1, minor = 0
> [    1.386714] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.386714] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.386714] usb usb1: Product: EHCI Host Controller
> [    1.386714] usb usb1: Manufacturer: Linux 3.2.0-rc0+ ehci_hcd
> [    1.386714] usb usb1: SerialNumber: 0000:00:12.2
> [    1.423538] usb usb1: usb_probe_device
> [    1.424524] usb usb1: configuration #1 chosen from 1 choice
> [    1.435957] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [    1.442260] hub 1-0:1.0: usb_probe_interface
> [    1.443216] hub 1-0:1.0: usb_probe_interface - got id
> [    1.443216] hub 1-0:1.0: USB hub found
> [    1.460190] ata2: SATA link down (SStatus 0 SControl 300)
> [    1.460255] ata4: SATA link down (SStatus 0 SControl 300)
> [    1.460324] ata5: SATA link down (SStatus 0 SControl 300)
> [    1.460368] ata6: SATA link down (SStatus 0 SControl 300)
> [    1.485187] hub 1-0:1.0: 5 ports detected
> [    1.486169] hub 1-0:1.0: standalone hub
> [    1.486169] hub 1-0:1.0: no power switching (usb 1.0)
> [    1.486169] hub 1-0:1.0: individual port over-current protection
> [    1.486169] hub 1-0:1.0: power on to power good time: 20ms
> [    1.516387] hub 1-0:1.0: local power source is good
> [    1.517362] hub 1-0:1.0: trying to enable port power on non-switchable hub
> [    1.529111] drivers/usb/core/inode.c: creating file '001'
> [    1.535704] xen: registering gsi 17 triggering 0 polarity 1
> [    1.541968] xen_map_pirq_gsi: returning irq 17 for gsi 17
> [    1.542960] xen: --> pirq=17 -> irq=17 (gsi=17)
> [    1.554529] Already setup the GSI :17
> [    1.560740] ehci_hcd 0000:00:13.2: EHCI Host Controller
> [    1.567004] drivers/usb/core/inode.c: creating file '002'
> [    1.573460] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
> [    1.574437] ehci_hcd 0000:00:13.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
> [    1.586197] ehci_hcd 0000:00:13.2: reset hcc_params a072 thresh 7 uframes 256/512/1024
> [    1.587186] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    1.587186] ehci_hcd 0000:00:13.2: debug port 1
> [    1.587186] ehci_hcd 0000:00:13.2: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
> [    1.611261] ehci_hcd 0000:00:13.2: MWI active
> [    1.615122] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [    1.615168] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [    1.612232] ehci_hcd 0000:00:13.2: supports USB remote wakeup
> [    1.635307] ehci_hcd 0000:00:13.2: irq 17, io mem 0xf98ff800
> [    1.640113] ehci_hcd 0000:00:13.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    1.641216] ata3.00: ATA-8: ST2000DL003-9VT166, CC45, max UDMA/133
> [    1.641219] ata3.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> [    1.641275] hub 1-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    1.641402] ata1.00: ATA-8: Hitachi HDS722020ALA330, JKAOA20N, max UDMA/133
> [    1.641404] ata1.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
> [    1.642032] ata3.00: configured for UDMA/133
> [    1.642932] ata1.00: configured for UDMA/133
> [    1.643199] scsi 0:0:0:0: Direct-Access     ATA      Hitachi HDS72202 JKAO PQ: 0 ANSI: 5
> [    1.643742] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
> [    1.643854] sd 0:0:0:0: [sda] Write Protect is off
> [    1.643859] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [    1.643932] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [    1.648079] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
> [    1.648158] usb usb2: default language 0x0409
> [    1.648170] usb usb2: udev 1, busnum 2, minor = 128
> [    1.648171] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.648173] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.648174] usb usb2: Product: EHCI Host Controller
> [    1.648176] usb usb2: Manufacturer: Linux 3.2.0-rc0+ ehci_hcd
> [    1.648177] usb usb2: SerialNumber: 0000:00:13.2
> [    1.757176] usb usb2: usb_probe_device
> [    1.757258] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [    1.757593] scsi 2:0:0:0: Direct-Access     ATA      ST2000DL003-9VT1 CC45 PQ: 0 ANSI: 5
> [    1.758098] sd 2:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
> [    1.758100] sd 2:0:0:0: [sdb] 4096-byte physical blocks
> [    1.758215] sd 2:0:0:0: [sdb] Write Protect is off
> [    1.758217] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> [    1.758263] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [    1.759160] sd 2:0:0:0: Attached scsi generic sg1 type 0
> [    1.758596] usb usb2: configuration #1 chosen from 1 choice
> [    1.819655] usb usb2: adding 2-0:1.0 (config #1, interface 0)
> [    1.819717]  sdb: sdb1
> [    1.819735]  sda: sda1 sda2 sda3
> [    1.839865] hub 2-0:1.0: usb_probe_interface
> [    1.840527] sd 2:0:0:0: [sdb] Attached SCSI disk
> [    1.840620] sd 0:0:0:0: [sda] Attached SCSI disk
> [    1.859118] hub 2-0:1.0: usb_probe_interface - got id
> [    1.859118] hub 2-0:1.0: USB hub found
> [    1.859527] hub 2-0:1.0: 5 ports detected
> [    1.859529] hub 2-0:1.0: standalone hub
> [    1.859530] hub 2-0:1.0: no power switching (usb 1.0)
> [    1.859532] hub 2-0:1.0: individual port over-current protection
> [    1.859533] hub 2-0:1.0: power on to power good time: 20ms
> [    1.859543] hub 2-0:1.0: local power source is good
> [    1.859545] hub 2-0:1.0: trying to enable port power on non-switchable hub
> [    1.859620] drivers/usb/core/inode.c: creating file '001'
> [    1.859930] xen: registering gsi 17 triggering 0 polarity 1
> [    1.859935] xen_map_pirq_gsi: returning irq 17 for gsi 17
> [    1.859937] xen: --> pirq=17 -> irq=17 (gsi=17)
> [    1.859939] Already setup the GSI :17
> [    1.860013] ehci_hcd 0000:00:16.2: EHCI Host Controller
> [    1.860025] drivers/usb/core/inode.c: creating file '003'
> [    1.860433] ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3
> [    1.860441] ehci_hcd 0000:00:16.2: reset hcs_params 0x101404 dbg=1 cc=1 pcc=4 ordered !ppc ports=4
> [    1.860444] ehci_hcd 0000:00:16.2: reset hcc_params a072 thresh 7 uframes 256/512/1024
> [    1.860449] ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    1.860537] ehci_hcd 0000:00:16.2: debug port 1
> [    1.860542] ehci_hcd 0000:00:16.2: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
> [    1.860565] ehci_hcd 0000:00:16.2: MWI active
> [    1.860566] ehci_hcd 0000:00:16.2: supports USB remote wakeup
> [    1.860575] ehci_hcd 0000:00:16.2: irq 17, io mem 0xf98ffc00
> [    1.860579] ehci_hcd 0000:00:16.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    1.867096] ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00
> [    1.867169] usb usb3: default language 0x0409
> [    1.867182] usb usb3: udev 1, busnum 3, minor = 256
> [    1.867184] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.867185] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.867187] usb usb3: Product: EHCI Host Controller
> [    1.867189] usb usb3: Manufacturer: Linux 3.2.0-rc0+ ehci_hcd
> [    1.867190] usb usb3: SerialNumber: 0000:00:16.2
> [    1.867391] usb usb3: usb_probe_device
> [    1.867393] usb usb3: configuration #1 chosen from 1 choice
> [    1.867413] usb usb3: adding 3-0:1.0 (config #1, interface 0)
> [    1.867535] hub 3-0:1.0: usb_probe_interface
> [    1.867537] hub 3-0:1.0: usb_probe_interface - got id
> [    1.867538] hub 3-0:1.0: USB hub found
> [    1.867545] hub 3-0:1.0: 4 ports detected
> [    1.867546] hub 3-0:1.0: standalone hub
> [    1.867547] hub 3-0:1.0: no power switching (usb 1.0)
> [    1.867549] hub 3-0:1.0: individual port over-current protection
> [    1.867550] hub 3-0:1.0: power on to power good time: 20ms
> [    1.867559] hub 3-0:1.0: local power source is good
> [    1.867561] hub 3-0:1.0: trying to enable port power on non-switchable hub
> [    1.867618] drivers/usb/core/inode.c: creating file '001'
> [    1.868048] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    1.868051] ohci_hcd: block sizes: ed 80 td 96
> [    1.868168] xen: registering gsi 18 triggering 0 polarity 1
> [    1.868192] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    1.868228] ohci_hcd 0000:00:12.0: OHCI Host Controller
> [    1.868244] drivers/usb/core/inode.c: creating file '004'
> [    1.868657] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4
> [    1.868672] ohci_hcd 0000:00:12.0: enabled AMD prefetch quirk
> [    1.868741] ohci_hcd 0000:00:12.0: created debug files
> [    1.868743] ohci_hcd 0000:00:12.0: supports USB remote wakeup
> [    1.868802] ohci_hcd 0000:00:12.0: irq 18, io mem 0xf98fb000
> [    1.924206] ohci_hcd 0000:00:12.0: OHCI controller state
> [    1.924213] ohci_hcd 0000:00:12.0: OHCI 1.0, NO legacy support registers, rh state running
> [    1.924217] ohci_hcd 0000:00:12.0: control 0x283 RWC HCFS=operational CBSR=3
> [    1.924220] ohci_hcd 0000:00:12.0: cmdstatus 0x00000 SOC=0
> [    1.924224] ohci_hcd 0000:00:12.0: intrstatus 0x00000004 SF
> [    1.924227] ohci_hcd 0000:00:12.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    1.924237] ohci_hcd 0000:00:12.0: hcca frame #0005
> [    1.924241] ohci_hcd 0000:00:12.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
> [    1.924257] ohci_hcd 0000:00:12.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    1.924260] ohci_hcd 0000:00:12.0: roothub.status 00008000 DRWE
> [    1.924264] ohci_hcd 0000:00:12.0: roothub.portstatus [0] 0x00000100 PPS
> [    1.924267] ohci_hcd 0000:00:12.0: roothub.portstatus [1] 0x00000100 PPS
> [    1.924271] ohci_hcd 0000:00:12.0: roothub.portstatus [2] 0x00000100 PPS
> [    1.924274] ohci_hcd 0000:00:12.0: roothub.portstatus [3] 0x00000100 PPS
> [    1.924278] ohci_hcd 0000:00:12.0: roothub.portstatus [4] 0x00000100 PPS
> [    1.924300] usb usb4: default language 0x0409
> [    1.924312] usb usb4: udev 1, busnum 4, minor = 384
> [    1.924314] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
> [    1.924316] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.924317] usb usb4: Product: OHCI Host Controller
> [    1.924319] usb usb4: Manufacturer: Linux 3.2.0-rc0+ ohci_hcd
> [    1.924320] usb usb4: SerialNumber: 0000:00:12.0
> [    1.924796] usb usb4: usb_probe_device
> [    1.924798] usb usb4: configuration #1 chosen from 1 choice
> [    1.924810] usb usb4: adding 4-0:1.0 (config #1, interface 0)
> [    1.924931] hub 4-0:1.0: usb_probe_interface
> [    1.924933] hub 4-0:1.0: usb_probe_interface - got id
> [    1.924935] hub 4-0:1.0: USB hub found
> [    1.924954] hub 4-0:1.0: 5 ports detected
> [    1.924955] hub 4-0:1.0: standalone hub
> [    1.924956] hub 4-0:1.0: no power switching (usb 1.0)
> [    1.924957] hub 4-0:1.0: no over-current protection
> [    1.924959] hub 4-0:1.0: power on to power good time: 4ms
> [    1.924969] hub 4-0:1.0: local power source is good
> [    1.924970] hub 4-0:1.0: trying to enable port power on non-switchable hub
> [    1.925009] drivers/usb/core/inode.c: creating file '001'
> [    1.925093] ehci_hcd 0000:00:12.2: HS companion for 0000:00:12.0
> [    1.925398] xen: registering gsi 18 triggering 0 polarity 1
> [    1.925402] xen_map_pirq_gsi: returning irq 18 for gsi 18
> [    1.925404] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    1.925406] Already setup the GSI :18
> [    1.925425] ohci_hcd 0000:00:13.0: OHCI Host Controller
> [    1.925437] drivers/usb/core/inode.c: creating file '005'
> [    1.925693] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5
> [    1.925705] ohci_hcd 0000:00:13.0: enabled AMD prefetch quirk
> [    1.925769] ohci_hcd 0000:00:13.0: created debug files
> [    1.925771] ohci_hcd 0000:00:13.0: supports USB remote wakeup
> [    1.925778] ohci_hcd 0000:00:13.0: irq 18, io mem 0xf98fc000
> [    1.960158] hub 2-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    1.968219] hub 3-0:1.0: state 7 ports 4 chg 0000 evt 0000
> [    1.981168] ohci_hcd 0000:00:13.0: OHCI controller state
> [    1.981173] ohci_hcd 0000:00:13.0: OHCI 1.0, NO legacy support registers, rh state running
> [    1.981177] ohci_hcd 0000:00:13.0: control 0x283 RWC HCFS=operational CBSR=3
> [    1.981180] ohci_hcd 0000:00:13.0: cmdstatus 0x00000 SOC=0
> [    1.981193] ohci_hcd 0000:00:13.0: intrstatus 0x00000004 SF
> [    1.981196] ohci_hcd 0000:00:13.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    1.981207] ohci_hcd 0000:00:13.0: hcca frame #0005
> [    1.981211] ohci_hcd 0000:00:13.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
> [    1.981214] ohci_hcd 0000:00:13.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    1.981217] ohci_hcd 0000:00:13.0: roothub.status 00008000 DRWE
> [    1.981221] ohci_hcd 0000:00:13.0: roothub.portstatus [0] 0x00000100 PPS
> [    1.981224] ohci_hcd 0000:00:13.0: roothub.portstatus [1] 0x00000100 PPS
> [    1.981227] ohci_hcd 0000:00:13.0: roothub.portstatus [2] 0x00000100 PPS
> [    1.981231] ohci_hcd 0000:00:13.0: roothub.portstatus [3] 0x00000100 PPS
> [    1.981234] ohci_hcd 0000:00:13.0: roothub.portstatus [4] 0x00000100 PPS
> [    1.981256] usb usb5: default language 0x0409
> [    1.981279] usb usb5: udev 1, busnum 5, minor = 512
> [    1.981281] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
> [    1.981282] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.981284] usb usb5: Product: OHCI Host Controller
> [    1.981285] usb usb5: Manufacturer: Linux 3.2.0-rc0+ ohci_hcd
> [    1.981287] usb usb5: SerialNumber: 0000:00:13.0
> [    1.981629] usb usb5: usb_probe_device
> [    1.981631] usb usb5: configuration #1 chosen from 1 choice
> [    1.981641] usb usb5: adding 5-0:1.0 (config #1, interface 0)
> [    1.981786] hub 5-0:1.0: usb_probe_interface
> [    1.981788] hub 5-0:1.0: usb_probe_interface - got id
> [    1.981799] hub 5-0:1.0: USB hub found
> [    1.981808] hub 5-0:1.0: 5 ports detected
> [    1.981809] hub 5-0:1.0: standalone hub
> [    1.981810] hub 5-0:1.0: no power switching (usb 1.0)
> [    1.981812] hub 5-0:1.0: no over-current protection
> [    1.981813] hub 5-0:1.0: power on to power good time: 4ms
> [    1.981823] hub 5-0:1.0: local power source is good
> [    1.981825] hub 5-0:1.0: trying to enable port power on non-switchable hub
> [    1.981866] drivers/usb/core/inode.c: creating file '001'
> [    1.981933] ehci_hcd 0000:00:13.2: HS companion for 0000:00:13.0
> [    1.982295] xen: registering gsi 18 triggering 0 polarity 1
> [    1.982299] xen_map_pirq_gsi: returning irq 18 for gsi 18
> [    1.982301] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    1.982302] Already setup the GSI :18
> [    1.982329] ohci_hcd 0000:00:14.5: OHCI Host Controller
> [    1.982338] drivers/usb/core/inode.c: creating file '006'
> [    1.982767] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6
> [    1.982779] ohci_hcd 0000:00:14.5: enabled AMD prefetch quirk
> [    1.982852] ohci_hcd 0000:00:14.5: created debug files
> [    1.982854] ohci_hcd 0000:00:14.5: supports USB remote wakeup
> [    1.982861] ohci_hcd 0000:00:14.5: irq 18, io mem 0xf98fd000
> [    2.025152] hub 4-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    2.038185] ohci_hcd 0000:00:14.5: OHCI controller state
> [    2.038189] ohci_hcd 0000:00:14.5: OHCI 1.0, NO legacy support registers, rh state running
> [    2.038193] ohci_hcd 0000:00:14.5: control 0x283 RWC HCFS=operational CBSR=3
> [    2.038196] ohci_hcd 0000:00:14.5: cmdstatus 0x00000 SOC=0
> [    2.038200] ohci_hcd 0000:00:14.5: intrstatus 0x00000004 SF
> [    2.038203] ohci_hcd 0000:00:14.5: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    2.038223] ohci_hcd 0000:00:14.5: hcca frame #0005
> [    2.038227] ohci_hcd 0000:00:14.5: roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2)
> [    2.038230] ohci_hcd 0000:00:14.5: roothub.b 00000000 PPCM=0000 DR=0000
> [    2.038233] ohci_hcd 0000:00:14.5: roothub.status 00008000 DRWE
> [    2.038237] ohci_hcd 0000:00:14.5: roothub.portstatus [0] 0x00000100 PPS
> [    2.038240] ohci_hcd 0000:00:14.5: roothub.portstatus [1] 0x00000100 PPS
> [    2.038264] usb usb6: default language 0x0409
> [    2.038280] usb usb6: udev 1, busnum 6, minor = 640
> [    2.038282] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
> [    2.038283] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    2.038285] usb usb6: Product: OHCI Host Controller
> [    2.038286] usb usb6: Manufacturer: Linux 3.2.0-rc0+ ohci_hcd
> [    2.038288] usb usb6: SerialNumber: 0000:00:14.5
> [    2.038616] usb usb6: usb_probe_device
> [    2.038618] usb usb6: configuration #1 chosen from 1 choice
> [    2.038627] usb usb6: adding 6-0:1.0 (config #1, interface 0)
> [    2.038781] hub 6-0:1.0: usb_probe_interface
> [    2.038783] hub 6-0:1.0: usb_probe_interface - got id
> [    2.038784] hub 6-0:1.0: USB hub found
> [    2.038793] hub 6-0:1.0: 2 ports detected
> [    2.038795] hub 6-0:1.0: standalone hub
> [    2.038796] hub 6-0:1.0: no power switching (usb 1.0)
> [    2.038797] hub 6-0:1.0: no over-current protection
> [    2.038799] hub 6-0:1.0: power on to power good time: 4ms
> [    2.038809] hub 6-0:1.0: local power source is good
> [    2.038810] hub 6-0:1.0: trying to enable port power on non-switchable hub
> [    2.038888] drivers/usb/core/inode.c: creating file '001'
> [    2.039293] xen: registering gsi 18 triggering 0 polarity 1
> [    2.039297] xen_map_pirq_gsi: returning irq 18 for gsi 18
> [    2.039298] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    2.039300] Already setup the GSI :18
> [    2.039318] ohci_hcd 0000:00:16.0: OHCI Host Controller
> [    2.039327] drivers/usb/core/inode.c: creating file '007'
> [    2.039554] ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7
> [    2.039566] ohci_hcd 0000:00:16.0: enabled AMD prefetch quirk
> [    2.039638] ohci_hcd 0000:00:16.0: created debug files
> [    2.039639] ohci_hcd 0000:00:16.0: supports USB remote wakeup
> [    2.039647] ohci_hcd 0000:00:16.0: irq 18, io mem 0xf98fe000
> [    2.082144] hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    2.095207] ohci_hcd 0000:00:16.0: OHCI controller state
> [    2.095214] ohci_hcd 0000:00:16.0: OHCI 1.0, NO legacy support registers, rh state running
> [    2.095218] ohci_hcd 0000:00:16.0: control 0x283 RWC HCFS=operational CBSR=3
> [    2.095221] ohci_hcd 0000:00:16.0: cmdstatus 0x00000 SOC=0
> [    2.095224] ohci_hcd 0000:00:16.0: intrstatus 0x00000004 SF
> [    2.095228] ohci_hcd 0000:00:16.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    2.095250] ohci_hcd 0000:00:16.0: hcca frame #0005
> [    2.095253] ohci_hcd 0000:00:16.0: roothub.a 02001204 POTPGT=2 NOCP NPS NDP=4(4)
> [    2.095256] ohci_hcd 0000:00:16.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    2.095260] ohci_hcd 0000:00:16.0: roothub.status 00008000 DRWE
> [    2.095263] ohci_hcd 0000:00:16.0: roothub.portstatus [0] 0x00000100 PPS
> [    2.095267] ohci_hcd 0000:00:16.0: roothub.portstatus [1] 0x00000100 PPS
> [    2.095270] ohci_hcd 0000:00:16.0: roothub.portstatus [2] 0x00000100 PPS
> [    2.095273] ohci_hcd 0000:00:16.0: roothub.portstatus [3] 0x00000100 PPS
> [    2.095292] usb usb7: default language 0x0409
> [    2.095305] usb usb7: udev 1, busnum 7, minor = 768
> [    2.095307] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
> [    2.095308] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    2.095310] usb usb7: Product: OHCI Host Controller
> [    2.095311] usb usb7: Manufacturer: Linux 3.2.0-rc0+ ohci_hcd
> [    2.095313] usb usb7: SerialNumber: 0000:00:16.0
> [    2.095642] usb usb7: usb_probe_device
> [    2.095644] usb usb7: configuration #1 chosen from 1 choice
> [    2.095653] usb usb7: adding 7-0:1.0 (config #1, interface 0)
> [    2.095820] hub 7-0:1.0: usb_probe_interface
> [    2.095822] hub 7-0:1.0: usb_probe_interface - got id
> [    2.095823] hub 7-0:1.0: USB hub found
> [    2.095833] hub 7-0:1.0: 4 ports detected
> [    2.095834] hub 7-0:1.0: standalone hub
> [    2.095835] hub 7-0:1.0: no power switching (usb 1.0)
> [    2.095846] hub 7-0:1.0: no over-current protection
> [    2.095848] hub 7-0:1.0: power on to power good time: 4ms
> [    2.095858] hub 7-0:1.0: local power source is good
> [    2.095859] hub 7-0:1.0: trying to enable port power on non-switchable hub
> [    2.095898] drivers/usb/core/inode.c: creating file '001'
> [    2.095993] ehci_hcd 0000:00:16.2: HS companion for 0000:00:16.0
> [    2.096345] uhci_hcd: USB Universal Host Controller Interface driver
> [    2.096654] usbcore: registered new interface driver usblp
> [    2.096655] Initializing USB Mass Storage driver...
> [    2.096788] usbcore: registered new interface driver usb-storage
> [    2.096799] USB Mass Storage support registered.
> [    2.096945] usbcore: registered new interface driver libusual
> [    2.097241] usbcore: registered new interface driver usbserial
> [    2.097245] usbserial: USB Serial Driver core
> [    2.097358] USB Serial support registered for cp210x
> [    2.097471] usbcore: registered new interface driver cp210x
> [    2.097472] cp210x: v0.09:Silicon Labs CP210x RS232 serial adaptor driver
> [    2.097590] USB Serial support registered for DeLorme Earthmate USB
> [    2.097687] USB Serial support registered for HID->COM RS232 Adapter
> [    2.097782] USB Serial support registered for Nokia CA-42 V2 Adapter
> [    2.097891] usbcore: registered new interface driver cypress
> [    2.097893] cypress_m8: v1.10:Cypress USB to Serial Driver
> [    2.097992] USB Serial support registered for Moschip 2 port adapter
> [    2.097994] mos7720: 2.1:Moschip USB Serial Driver
> [    2.098141] usbcore: registered new interface driver moschip7720
> [    2.098244] USB Serial support registered for Moschip 7840/7820 USB Serial Driver
> [    2.098246] mos7840: 1.3.2:Moschip 7840/7820 USB Serial Driver
> [    2.098372] usbcore: registered new interface driver mos7840
> [    2.098814] i8042: PNP: No PS/2 controller found. Probing ports directly.
> [    2.099543] serio: i8042 KBD port at 0x60,0x64 irq 1
> [    2.099557] serio: i8042 AUX port at 0x60,0x64 irq 12
> [    2.100022] mousedev: PS/2 mouse device common for all mice
> [    2.100677] rtc_cmos 00:04: RTC can wake from S4
> [    2.101180] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
> [    2.101280] rtc0: alarms up to one month, y3k, 114 bytes nvram
> [    2.101963] lirc_dev: IR Remote Control driver registered, major 251 
> [    2.101976] IR NEC protocol handler initialized
> [    2.101978] IR RC5(x) protocol handler initialized
> [    2.101980] IR RC6 protocol handler initialized
> [    2.101982] IR JVC protocol handler initialized
> [    2.101983] IR Sony protocol handler initialized
> [    2.101985] IR RC5 (streamzap) protocol handler initialized
> [    2.101987] IR MCE Keyboard/mouse protocol handler initialized
> [    2.101989] IR LIRC bridge handler initialized
> [    2.101990] Linux video capture interface: v2.00
> [    2.102215] i2c-core: driver [tuner] using legacy suspend method
> [    2.102216] i2c-core: driver [tuner] using legacy resume method
> [    2.102410] i2c-core: driver [msp3400] using legacy suspend method
> [    2.102412] i2c-core: driver [msp3400] using legacy resume method
> [    2.102879] usbcore: registered new interface driver poseidon
> [    2.102991] usbcore: registered new interface driver cx231xx
> [    2.103138] usbcore: registered new interface driver usbvision
> [    2.103140] USBVision USB Video Device Driver for Linux : 0.9.11
> [    2.103453] usbcore: registered new interface driver pvrusb2
> [    2.103454] pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
> [    2.103456] pvrusb2: Debug mask is 31 (0x1f)
> [    2.103586] usbcore: registered new interface driver tm6000
> [    2.103698] usbcore: registered new interface driver zr364xx
> [    2.103830] usbcore: registered new interface driver stkwebcam
> [    2.103940] usbcore: registered new interface driver sn9c102
> [    2.104071] usbcore: registered new interface driver et61x251
> [    2.104189] usbcore: registered new interface driver Philips webcam
> [    2.104191] gspca_main: v2.14.0 registered
> [    2.104307] usbcore: registered new interface driver benq
> [    2.104432] usbcore: registered new interface driver conex
> [    2.104540] usbcore: registered new interface driver cpia1
> [    2.104649] usbcore: registered new interface driver etoms
> [    2.104757] usbcore: registered new interface driver finepix
> [    2.104874] usbcore: registered new interface driver jeilinj
> [    2.104985] usbcore: registered new interface driver kinect
> [    2.105122] usbcore: registered new interface driver konica
> [    2.105228] usbcore: registered new interface driver mars
> [    2.105355] usbcore: registered new interface driver mr97310a
> [    2.105513] usbcore: registered new interface driver nw80x
> [    2.105647] usbcore: registered new interface driver ov519
> [    2.105757] usbcore: registered new interface driver ov534
> [    2.105867] usbcore: registered new interface driver ov534_9
> [    2.105994] usbcore: registered new interface driver pac207
> [    2.106125] usbcore: registered new interface driver pac7302
> [    2.106258] usbcore: registered new interface driver pac7311
> [    2.106364] usbcore: registered new interface driver se401
> [    2.106470] usbcore: registered new interface driver sn9c2028
> [    2.106594] usbcore: registered new interface driver sn9c20x
> [    2.106712] usbcore: registered new interface driver sonixb
> [    2.106831] usbcore: registered new interface driver sonixj
> [    2.106949] usbcore: registered new interface driver spca500
> [    2.107081] usbcore: registered new interface driver spca501
> [    2.107211] usbcore: registered new interface driver spca505
> [    2.107326] usbcore: registered new interface driver spca506
> [    2.107432] usbcore: registered new interface driver spca508
> [    2.107559] usbcore: registered new interface driver spca561
> [    2.107670] usbcore: registered new interface driver spca1528
> [    2.107778] usbcore: registered new interface driver sq905
> [    2.107904] usbcore: registered new interface driver sq905c
> [    2.108014] usbcore: registered new interface driver sq930x
> [    2.108196] usbcore: registered new interface driver sunplus
> [    2.108309] usbcore: registered new interface driver stk014
> [    2.108427] usbcore: registered new interface driver stv0680
> [    2.108535] usbcore: registered new interface driver t613
> [    2.108645] usbcore: registered new interface driver tv8532
> [    2.108772] usbcore: registered new interface driver vc032x
> [    2.108879] usbcore: registered new interface driver vicam
> [    2.108992] usbcore: registered new interface driver xirlink-cit
> [    2.109145] usbcore: registered new interface driver zc3xx
> [    2.109267] usbcore: registered new interface driver ALi m5602
> [    2.109388] usbcore: registered new interface driver STV06xx
> [    2.109501] usbcore: registered new interface driver gspca_gl860
> [    2.109663] usbcore: registered new interface driver hdpvr
> [    2.109776] usbcore: registered new interface driver s2255
> [    2.109902] usbcore: registered new interface driver uvcvideo
> [    2.109903] USB Video Class driver (1.1.1)
> [    2.110112] f71882fg: Found f71889ed chip at 0x600, revision 16
> [    2.110464] f71882fg f71882fg.1536: Fan: 1 is in duty-cycle mode
> [    2.110512] f71882fg f71882fg.1536: Fan: 2 is in duty-cycle mode
> [    2.110554] f71882fg f71882fg.1536: Fan: 3 is in duty-cycle mode
> [    2.111792] f71808e_wdt: Unrecognized Fintek device: 0909
> [    2.111798] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01
> [    2.112097] SP5100 TCO timer: mmio address 0xb8fe00 already in use
> [    2.112107] wdt: Xen WatchDog Timer Driver v0.01
> [    2.112487] wdt: initialized (timeout=60s, nowayout=0)
> [    2.113129] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
> [    2.113486] EFI Variables Facility v0.08 2004-May-17
> [    2.116096] usbcore: registered new interface driver usbhid
> [    2.116098] usbhid: USB HID core driver
> [    2.120940] usbcore: registered new interface driver snd-usb-audio
> [    2.121092] usbcore: registered new interface driver snd-ua101
> [    2.121208] usbcore: registered new interface driver snd-usb-usx2y
> [    2.121338] usbcore: registered new interface driver snd-usb-us122l
> [    2.121454] usbcore: registered new interface driver snd-usb-caiaq
> [    2.121569] usbcore: registered new interface driver snd-usb-6fire
> [    2.121571] ALSA device list:
> [    2.121572]   No soundcards found.
> [    2.121636] Netfilter messages via NETLINK v0.30.
> [    2.121697] nf_conntrack version 0.5.0 (7319 buckets, 29276 max)
> [    2.122470] ctnetlink v0.93: registering with nfnetlink.
> [    2.123185] xt_time: kernel timezone is -0000
> [    2.123201] ip_set: protocol 6
> [    2.123253] IPVS: Registered protocols ()
> [    2.123278] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
> [    2.123583] IPVS: Creating netns size=1912 id=0
> [    2.123590] IPVS: ipvs loaded.
> [    2.125542] ip_tables: (C) 2000-2006 Netfilter Core Team
> [    2.125668] TCP cubic registered
> [    2.125671] NET: Registered protocol family 17
> [    2.125792] Bridge firewalling registered
> [    2.125806] Ebtables v2.0 registered
> [    2.125850] Registering the dns_resolver key type
> [    2.126537] registered taskstats version 1
> [    2.128471]   Magic number: 12:515:430
> [    2.139144] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [    2.195158] hub 7-0:1.0: state 7 ports 4 chg 0000 evt 0000
> [    3.556135] console [netcon0] enabled
> [    3.560114] netconsole: network logging started
> [    3.565183] Freeing unused kernel memory: 644k freed
> [    3.566054] Write protecting the kernel read-only data: 14336k
> [    3.582581] Freeing unused kernel memory: 1108k freed
> [    3.587819] Freeing unused kernel memory: 172k freed
> [    4.375679] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
> [    5.735717] udev[1928]: starting version 164
> [    6.619502] ata1.00: configured for UDMA/133
> [    6.620486] ata1: EH complete
> [    6.989411] ata1.00: configured for UDMA/133
> [    6.989416] ata1: EH complete
> [    7.544355] EXT4-fs (dm-0): re-mounted. Opts: (null)
> [    7.750228] EXT4-fs (dm-0): re-mounted. Opts: barrier=1,errors=remount-ro
> [   13.646383] Adding 2097148k swap on /dev/mapper/serveerstertje-swap.  Priority:-1 extents:1 across:2097148k 
> [   14.689994] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   15.923651] r8169 0000:08:00.0: eth1: link down
> [   15.924659] r8169 0000:08:00.0: eth1: link down
> [   16.114905] r8169 0000:09:00.0: eth0: link down
> [   16.115942] r8169 0000:09:00.0: eth0: link down
> [   17.642504] r8169 0000:08:00.0: eth1: link up
> [   18.022436] r8169 0000:09:00.0: eth0: link up
> [   24.083304] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=18250 DPT=53 LEN=47 
> [   24.083326] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=18250 DPT=53 LEN=47 
> [   24.116546] FW: ipmasq, Forward .. EoC: IN=eth1 OUT=eth0 MAC=40:61:86:f4:67:d8:00:13:e8:b8:03:7f:08:00 SRC=172.16.1.20 DST=64.4.34.191 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=15618 DF PROTO=TCP SPT=49194 DPT=1863 WINDOW=0 RES=0x00 ACK RST URGP=0 
> [   24.119022] FW: ipmasq, Forward .. EoC: IN=eth1 OUT=eth0 MAC=40:61:86:f4:67:d8:00:13:e8:b8:03:7f:08:00 SRC=172.16.1.20 DST=64.4.44.72 LEN=45 TOS=0x00 PREC=0x00 TTL=127 ID=15619 DF PROTO=TCP SPT=52059 DPT=1863 WINDOW=65 RES=0x00 ACK PSH FIN URGP=0 
> [   24.497023] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52176 DF PROTO=UDP SPT=46112 DPT=53 LEN=47 
> [   24.497126] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=38173 DPT=53 LEN=47 
> [   24.497173] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=42462 DPT=53 LEN=47 
> [   24.497219] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=52498 DPT=53 LEN=47 
> [   24.497263] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=41981 DPT=53 LEN=47 
> [   24.497307] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=44950 DPT=53 LEN=47 
> [   24.497356] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=57749 DPT=53 LEN=47 
> [   24.497402] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=40747 DPT=53 LEN=47 
> [   24.497480] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=56044 DPT=53 LEN=47 
> [   24.497527] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=56530 DPT=53 LEN=47 
> [   24.497571] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=59746 DPT=53 LEN=47 
> [   24.497615] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=58422 DPT=53 LEN=47 
> [   24.497671] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=35192 DPT=53 LEN=47 
> [   24.497713] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=52681 DPT=53 LEN=47 
> [   24.497753] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=34661 DPT=53 LEN=47 
> [   24.497793] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=43406 DPT=53 LEN=47 
> [   24.498003] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=40187 DPT=53 LEN=47 
> [   24.498043] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=52592 DPT=53 LEN=47 
> [   24.498123] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=40073 DPT=53 LEN=47 
> [   24.498169] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=48232 DPT=53 LEN=47 
> [   24.498213] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=56401 DPT=53 LEN=47 
> [   24.498264] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=42295 DPT=53 LEN=47 
> [   24.498308] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=37428 DPT=53 LEN=47 
> [   24.498353] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=39793 DPT=53 LEN=47 
> [   24.498399] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=39550 DPT=53 LEN=47 
> [   24.498446] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=51014 DPT=53 LEN=47 
> [   24.498486] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=33114 DPT=53 LEN=47 
> [   24.498525] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=46473 DPT=53 LEN=47 
> [   24.498565] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=54857 DPT=53 LEN=47 
> [   24.498606] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=50547 DPT=53 LEN=47 
> [   24.498645] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=57172 DPT=53 LEN=47 
> [   24.498684] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=35018 DPT=53 LEN=47 
> [   24.498879] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=39233 DPT=53 LEN=47 
> [   24.498920] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=55591 DPT=53 LEN=47 
> [   24.498960] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=49309 DPT=53 LEN=47 
> [   24.498999] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=55292 DPT=53 LEN=47 
> [   24.499039] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=52173 DPT=53 LEN=47 
> [   24.499121] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=40901 DPT=53 LEN=47 
> [   24.499166] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=57459 DPT=53 LEN=47 
> [   24.499211] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=44390 DPT=53 LEN=47 
> [   24.499260] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=57122 DPT=53 LEN=47 
> [   24.499305] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=33703 DPT=53 LEN=47 
> [   24.499349] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=50839 DPT=53 LEN=47 
> [   24.499396] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=37339 DPT=53 LEN=47 
> [   24.499441] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=56282 DPT=53 LEN=47 
> [   24.499485] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=36999 DPT=53 LEN=47 
> [   24.499530] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=40745 DPT=53 LEN=47 
> [   24.499579] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=57275 DPT=53 LEN=47 
> [   24.499772] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=60162 DPT=53 LEN=47 
> [   24.499812] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=47685 DPT=53 LEN=47 
> [   24.499851] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=44549 DPT=53 LEN=47 
> [   24.499890] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=60280 DPT=53 LEN=47 
> [   24.499929] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=49966 DPT=53 LEN=47 
> [   24.499969] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=60795 DPT=53 LEN=47 
> [   24.500008] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=40379 DPT=53 LEN=47 
> [   24.500048] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=41815 DPT=53 LEN=47 
> [   24.500129] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=47336 DPT=53 LEN=47 
> [   24.500174] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=34385 DPT=53 LEN=47 
> [   24.500218] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=34089 DPT=53 LEN=47 
> [   24.500263] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=53958 DPT=53 LEN=47 
> [   24.500307] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=41698 DPT=53 LEN=47 
> [   24.500351] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=54925 DPT=53 LEN=47 
> [   24.500395] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=43597 DPT=53 LEN=47 
> [   24.500440] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=36447 DPT=53 LEN=47 
> [   27.349843] sshd (5162): /proc/5162/oom_adj is deprecated, please use /proc/5162/oom_score_adj instead.
> [   28.082409] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   28.705405] EXT4-fs (dm-36): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   29.249131] EXT4-fs (dm-37): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   29.715206] EXT4-fs (dm-38): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   30.388561] EXT4-fs (dm-39): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   30.468794] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=11418 DPT=53 LEN=47 
> [   30.490797] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=11418 DPT=53 LEN=47 
> [   30.756151] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=62559 DPT=53 LEN=47 
> [   30.779123] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=62559 DPT=53 LEN=47 
> [   30.808008] EXT4-fs (dm-40): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   30.812794] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=28521 DPT=53 LEN=47 
> [   30.812811] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=28521 DPT=53 LEN=47 
> [   30.825619] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=61480 DPT=53 LEN=40 
> [   30.825636] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=61480 DPT=53 LEN=40 
> [   30.826343] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=28651 DPT=53 LEN=47 
> [   30.826359] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=28651 DPT=53 LEN=47 
> [   30.841085] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=24486 DPT=53 LEN=47 
> [   30.841101] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=24486 DPT=53 LEN=47 
> [   30.856521] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58984 DPT=53 LEN=47 
> [   30.856538] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58984 DPT=53 LEN=47 
> [   30.872092] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=52348 DPT=53 LEN=47 
> [   30.872118] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=52348 DPT=53 LEN=47 
> [   30.887716] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=61609 DPT=53 LEN=47 
> [   30.887733] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=61609 DPT=53 LEN=47 
> [   30.903377] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=22448 DPT=53 LEN=47 
> [   30.903394] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=22448 DPT=53 LEN=47 
> [   30.920142] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=15774 DPT=53 LEN=47 
> [   30.920158] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=15774 DPT=53 LEN=47 
> [   30.934450] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=33880 DPT=53 LEN=47 
> [   30.934466] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=33880 DPT=53 LEN=47 
> [   30.950468] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=63072 DPT=53 LEN=47 
> [   30.950485] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=63072 DPT=53 LEN=47 
> [   30.966308] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=13061 DPT=53 LEN=47 
> [   30.966325] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=13061 DPT=53 LEN=47 
> [   30.981966] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=47836 DPT=53 LEN=47 
> [   30.981983] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=47836 DPT=53 LEN=47 
> [   30.997341] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=55194 DPT=53 LEN=47 
> [   30.997357] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=55194 DPT=53 LEN=47 
> [   31.013438] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50477 DPT=53 LEN=47 
> [   31.013455] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50477 DPT=53 LEN=47 
> [   31.029811] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=13928 DPT=53 LEN=47 
> [   31.029828] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=13928 DPT=53 LEN=47 
> [   31.044600] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=41201 DPT=53 LEN=47 
> [   31.044616] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=41201 DPT=53 LEN=47 
> [   31.060007] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=64783 DPT=53 LEN=47 
> [   31.060025] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=64783 DPT=53 LEN=47 
> [   31.075536] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=45723 DPT=53 LEN=47 
> [   31.075552] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=45723 DPT=53 LEN=47 
> [   31.091041] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=26819 DPT=53 LEN=47 
> [   31.091101] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=26819 DPT=53 LEN=47 
> [   31.106879] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=5918 DPT=53 LEN=47 
> [   31.106896] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=5918 DPT=53 LEN=47 
> [   31.123862] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8486 DPT=53 LEN=47 
> [   31.123880] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8486 DPT=53 LEN=47 
> [   31.138293] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=30325 DPT=53 LEN=47 
> [   31.138312] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=30325 DPT=53 LEN=47 
> [   31.153511] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50004 DPT=53 LEN=47 
> [   31.153527] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50004 DPT=53 LEN=47 
> [   31.169000] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39425 DPT=53 LEN=47 
> [   31.169017] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39425 DPT=53 LEN=47 
> [   31.184877] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8838 DPT=53 LEN=47 
> [   31.184934] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8838 DPT=53 LEN=47 
> [   31.200343] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=42830 DPT=53 LEN=47 
> [   31.200359] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=42830 DPT=53 LEN=47 
> [   31.216019] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=25917 DPT=53 LEN=47 
> [   31.216046] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=25917 DPT=53 LEN=47 
> [   31.232094] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=11910 DPT=53 LEN=47 
> [   31.232112] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=11910 DPT=53 LEN=47 
> [   31.304406] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=75 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=14618 DPT=53 LEN=55 
> [   31.304423] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=75 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=14618 DPT=53 LEN=55 
> [   31.525843] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=57066 DPT=53 LEN=42 
> [   31.525859] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=57066 DPT=53 LEN=42 
> [   33.370377] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   38.708110] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=59086 DPT=53 LEN=47 
> [   38.740705] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=59086 DPT=53 LEN=47 
> [   40.699839] FW: ipmasq, Forward .. EoC: IN=eth1 OUT=eth0 MAC=40:61:86:f4:67:d8:00:13:e8:b8:03:7f:08:00 SRC=172.16.1.20 DST=64.4.44.72 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=15669 DF PROTO=TCP SPT=52059 DPT=1863 WINDOW=0 RES=0x00 ACK RST URGP=0 
> [   40.843016] XENBUS: Unable to read cpu state
> [   40.859766] XENBUS: Unable to read cpu state
> [   40.859943] XENBUS: Unable to read cpu state
> [   40.860165] XENBUS: Unable to read cpu state
> [   40.860324] XENBUS: Unable to read cpu state
> [   40.860521] XENBUS: Unable to read cpu state
> [   47.255764] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9399 DF PROTO=UDP SPT=56370 DPT=53 LEN=50 
> [   47.284392] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9428 DF PROTO=UDP SPT=38848 DPT=53 LEN=50 
> [   47.315317] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9459 DF PROTO=UDP SPT=57230 DPT=53 LEN=50 
> [   47.346000] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9489 DF PROTO=UDP SPT=37919 DPT=53 LEN=50 
> [   60.891334] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=24907 DPT=53 LEN=47 
> [   60.919853] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=24907 DPT=53 LEN=47 
> [   60.949642] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36011 DPT=53 LEN=40 
> [   60.979376] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36011 DPT=53 LEN=40 
> [   61.009190] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=42832 DPT=53 LEN=47 
> [   61.038983] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=42832 DPT=53 LEN=47 
> [   61.074371] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=23461 DPT=53 LEN=47 
> [   61.103755] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=23461 DPT=53 LEN=47 
> [   61.137041] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=56532 DPT=53 LEN=47 
> [   61.166563] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=56532 DPT=53 LEN=47 
> [   61.199749] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=17213 DPT=53 LEN=47 
> [   61.229937] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=17213 DPT=53 LEN=47 
> [   61.277683] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8231 DPT=53 LEN=47 
> [   61.306229] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8231 DPT=53 LEN=47 
> [   61.347115] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=12397 DPT=53 LEN=47 
> [   61.376324] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=12397 DPT=53 LEN=47 
> [   61.448728] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=75 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=6376 DPT=53 LEN=55 
> [   61.478229] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=75 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=6376 DPT=53 LEN=55 
> [   61.696753] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44963 DPT=53 LEN=42 
> [   61.726660] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44963 DPT=53 LEN=42 

> enabled)
> (XEN) Processor #0 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> (XEN) Processor #1 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> (XEN) Processor #2 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> (XEN) Processor #3 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
> (XEN) Processor #4 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled)
> (XEN) Processor #5 0:10 APIC version 16
> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55
> (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 low 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 2 I/O APICs
> (XEN) ACPI: HPET id: 0x8300 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) mapped IOAPIC to ffff82c3ffffc000 (fec20000)
> (XEN) IRQ limits: 56 GSI, 1112 MSI/MSI-X
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 3200.160 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) AMD Fam10h machine check reporting enabled
> (XEN) AMD-Vi: Found MSI capability block 
> (XEN) AMD-Vi: ACPI Table:
> (XEN) AMD-Vi:  Signature IVRS
> (XEN) AMD-Vi:  Length 0x100
> (XEN) AMD-Vi:  Revision 0x1
> (XEN) AMD-Vi:  CheckSum 0x66
> (XEN) AMD-Vi:  OEM_Id AMD  
> (XEN) AMD-Vi:  OEM_Table_Id RD890S
> (XEN) AMD-Vi:  OEM_Revision 0x202031
> (XEN) AMD-Vi:  Creator_Id AMD 
> (XEN) AMD-Vi:  Creator_Revision 0x0
> (XEN) AMD-Vi: IVRS Block:
> (XEN) AMD-Vi:  Type 0x10
> (XEN) AMD-Vi:  Flags 0x3e
> (XEN) AMD-Vi:  Length 0xd0
> (XEN) AMD-Vi:  Dev_Id 0x2
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x0 -> 0x2
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x10
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xb00
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x18
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0xa00
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0xa00 -> 0xa07
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x28
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x900
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x30
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x800
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x50
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x600
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x0
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x43
> (XEN) AMD-Vi:  Dev_Id 0x708
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x708 -> 0x7ff
> (XEN) AMD-Vi:  Dev_Id Alias: 0x700
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x58
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x500
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x500 -> 0x501
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x68
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x400
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x400 -> 0x407
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x88
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x90
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x90 -> 0x92
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x98
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x98 -> 0x9a
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa0
> (XEN) AMD-Vi:  Flags 0xd7
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa3
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa4
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x0
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x43
> (XEN) AMD-Vi:  Dev_Id 0x300
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x300 -> 0x3ff
> (XEN) AMD-Vi:  Dev_Id Alias: 0xa4
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa5
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa8
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa9
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x100
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0xb0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0xb0 -> 0xb2
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x0
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x48
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0xd7
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x48
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: Add device table entry: device id = 0x0000, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0001, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0002, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0010, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0018, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0028, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0030, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0050, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0058, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0068, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0088, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0090, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0091, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0092, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0098, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0099, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x009a, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a0, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a3, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a4, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a5, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a8, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a9, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00b0, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00b1, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00b2, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0100, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0400, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0401, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0402, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0403, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0404, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0405, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0406, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0407, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0500, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0501, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0600, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0700, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0800, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0900, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a00, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a01, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a02, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a03, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a04, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a05, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a06, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a07, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0b00, interupt table = 0x24df1e000
> (XEN) AMD-Vi: IOMMU 0 Enabled.
> (XEN) AMD-Vi: Enabling global vector map
> (XEN) I/O virtualisation enabled
> (XEN)  - Dom0 mode: Relaxed
> (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) 6-0, 6-16, 6-17, 6-18, 6-19, 6-20, 6-21, 6-22, 6-23, 7-0, 7-1, 7-2, 7-3, 7-4, 7-5, 7-6, 7-7, 7-8, 7-9, 7-10, 7-11, 7-12, 7-13, 7-14, 7-15, 7-16, 7-17, 7-18, 7-19, 7-20, 7-21, 7-22, 7-23, 7-24, 7-25, 7-26, 7-27, 7-28, 7-29, 7-30, 7-31 not connected.
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
> (XEN) number of MP IRQ sources: 15.
> (XEN) number of IO-APIC #6 registers: 24.
> (XEN) number of IO-APIC #7 registers: 32.
> (XEN) testing the IO APIC.......................
> (XEN) IO APIC #6......
> (XEN) .... register #00: 06000000
> (XEN) .......    : physical APIC id: 06
> (XEN) .......    : Delivery Type: 0
> (XEN) .......    : LTS          : 0
> (XEN) .... register #01: 00178021
> (XEN) .......     : max redirection entries: 0017
> (XEN) .......     : PRQ implemented: 1
> (XEN) .......     : IO APIC version: 0021
> (XEN) .... register #02: 06000000
> (XEN) .......     : arbitration: 06
> (XEN) .... register #03: 07000000
> (XEN) .......     : Boot DT    : 0
> (XEN) .... IRQ redirection table:
> (XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
> (XEN)  00 000 00  1    0    0   0   0    0    0    00
> (XEN)  01 001 01  0    0    0   0   0    1    1    30
> (XEN)  02 001 01  0    0    0   0   0    1    1    F0
> (XEN)  03 001 01  0    0    0   0   0    1    1    38
> (XEN)  04 001 01  0    0    0   0   0    1    1    F1
> (XEN)  05 001 01  0    0    0   0   0    1    1    40
> (XEN)  06 001 01  0    0    0   0   0    1    1    48
> (XEN)  07 001 01  0    0    0   0   0    1    1    50
> (XEN)  08 001 01  0    0    0   0   0    1    1    58
> (XEN)  09 001 01  1    1    0   1   0    1    1    60
> (XEN)  0a 001 01  0    0    0   0   0    1    1    68
> (XEN)  0b 001 01  0    0    0   0   0    1    1    70
> (XEN)  0c 001 01  0    0    0   0   0    1    1    78
> (XEN)  0d 001 01  0    0    0   0   0    1    1    88
> (XEN)  0e 001 01  0    0    0   0   0    1    1    90
> (XEN)  0f 001 01  0    0    0   0   0    1    1    98
> (XEN)  10 000 00  1    0    0   0   0    0    0    00
> (XEN)  11 000 00  1    0    0   0   0    0    0    00
> (XEN)  12 000 00  1    0    0   0   0    0    0    00
> (XEN)  13 000 00  1    0    0   0   0    0    0    00
> (XEN)  14 000 00  1    0    0   0   0    0    0    00
> (XEN)  15 000 00  1    0    0   0   0    0    0    00
> (XEN)  16 000 00  1    0    0   0   0    0    0    00
> (XEN)  17 000 00  1    0    0   0   0    0    0    00
> (XEN) IO APIC #7......
> (XEN) .... register #00: 07000000
> (XEN) .......    : physical APIC id: 07
> (XEN) .......    : Delivery Type: 0
> (XEN) .......    : LTS          : 0
> (XEN) .... register #01: 001F8021
> (XEN) .......     : max redirection entries: 001F
> (XEN) .......     : PRQ implemented: 1
> (XEN) .......     : IO APIC version: 0021
> (XEN) .... register #02: 00000000
> (XEN) .......     : arbitration: 00
> (XEN) .... IRQ redirection table:
> (XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
> (XEN)  00 000 00  1    0    0   0   0    0    0    00
> (XEN)  01 000 00  1    0    0   0   0    0    0    00
> (XEN)  02 000 00  1    0    0   0   0    0    0    00
> (XEN)  03 000 00  1    0    0   0   0    0    0    00
> (XEN)  04 000 00  1    0    0   0   0    0    0    00
> (XEN)  05 000 00  1    0    0   0   0    0    0    00
> (XEN)  06 000 00  1    0    0   0   0    0    0    00
> (XEN)  07 000 00  1    0    0   0   0    0    0    00
> (XEN)  08 000 00  1    0    0   0   0    0    0    00
> (XEN)  09 000 00  1    0    0   0   0    0    0    00
> (XEN)  0a 000 00  1    0    0   0   0    0    0    00
> (XEN)  0b 000 00  1    0    0   0   0    0    0    00
> (XEN)  0c 000 00  1    0    0   0   0    0    0    00
> (XEN)  0d 000 00  1    0    0   0   0    0    0    00
> (XEN)  0e 000 00  1    0    0   0   0    0    0    00
> (XEN)  0f 000 00  1    0    0   0   0    0    0    00
> (XEN)  10 000 00  1    0    0   0   0    0    0    00
> (XEN)  11 000 00  1    0    0   0   0    0    0    00
> (XEN)  12 000 00  1    0    0   0   0    0    0    00
> (XEN)  13 000 00  1    0    0   0   0    0    0    00
> (XEN)  14 000 00  1    0    0   0   0    0    0    00
> (XEN)  15 000 00  1    0    0   0   0    0    0    00
> (XEN)  16 000 00  1    0    0   0   0    0    0    00
> (XEN)  17 000 00  1    0    0   0   0    0    0    00
> (XEN)  18 000 00  1    0    0   0   0    0    0    00
> (XEN)  19 000 00  1    0    0   0   0    0    0    00
> (XEN)  1a 000 00  1    0    0   0   0    0    0    00
> (XEN)  1b 000 00  1    0    0   0   0    0    0    00
> (XEN)  1c 000 00  1    0    0   0   0    0    0    00
> (XEN)  1d 000 00  1    0    0   0   0    0    0    00
> (XEN)  1e 000 00  1    0    0   0   0    0    0    00
> (XEN)  1f 000 00  1    0    0   0   0    0    0    00
> (XEN) Using vector-based indexing
> (XEN) IRQ to pin mappings:
> (XEN) IRQ240 -> 0:2
> (XEN) IRQ48 -> 0:1
> (XEN) IRQ56 -> 0:3
> (XEN) IRQ241 -> 0:4
> (XEN) IRQ64 -> 0:5
> (XEN) IRQ72 -> 0:6
> (XEN) IRQ80 -> 0:7
> (XEN) IRQ88 -> 0:8
> (XEN) IRQ96 -> 0:9
> (XEN) IRQ104 -> 0:10
> (XEN) IRQ112 -> 0:11
> (XEN) IRQ120 -> 0:12
> (XEN) IRQ136 -> 0:13
> (XEN) IRQ144 -> 0:14
> (XEN) IRQ152 -> 0:15
> (XEN) .................................... done.
> (XEN) Using local APIC timer interrupts.
> (XEN) calibrating APIC timer ...
> (XEN) ..... CPU clock speed is 3200.1868 MHz.
> (XEN) ..... host bus clock speed is 200.0115 MHz.
> (XEN) ..... bus_scale = 0x0000CCD7
> (XEN) [2012-01-12 12:25:10] Platform timer appears to have unexpectedly wrapped 10 or more times.
> (XEN) [2012-01-12 12:25:10] Platform timer is 14.318MHz HPET
> (XEN) [2012-01-12 12:25:10] Allocated console ring of 64 KiB.
> (XEN) [2012-01-12 12:25:10] HVM: ASIDs enabled.
> (XEN) [2012-01-12 12:25:10] SVM: Supported advanced features:
> (XEN) [2012-01-12 12:25:10]  - Nested Page Tables (NPT)
> (XEN) [2012-01-12 12:25:10]  - Last Branch Record (LBR) Virtualisation
> (XEN) [2012-01-12 12:25:10]  - Next-RIP Saved on #VMEXIT
> (XEN) [2012-01-12 12:25:10]  - Pause-Intercept Filter
> (XEN) [2012-01-12 12:25:10] HVM: SVM enabled
> (XEN) [2012-01-12 12:25:10] HVM: Hardware Assisted Paging detected.
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#1
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#2
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#3
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#4
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#5
> (XEN) [2012-01-12 12:25:10] Brought up 6 CPUs
> (XEN) [2012-01-12 12:25:10] HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled.
> (XEN) [2012-01-12 12:25:10] ACPI sleep modes: S3
> (XEN) [2012-01-12 12:25:10] MCA: Use hw thresholding to adjust polling frequency
> (XEN) [2012-01-12 12:25:10] mcheck_poll: Machine check polling timer started.
> (XEN) [2012-01-12 12:25:10] Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff
> (XEN) [2012-01-12 12:25:10] *** LOADING DOMAIN 0 ***
> (XEN) [2012-01-12 12:25:11]  Xen  kernel: 64-bit, lsb, compat32
> (XEN) [2012-01-12 12:25:11]  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2b5a000
> (XEN) [2012-01-12 12:25:11] PHYSICAL MEMORY ARRANGEMENT:
> (XEN) [2012-01-12 12:25:11]  Dom0 alloc.:   0000000244000000->0000000248000000 (244079 pages to be allocated)
> (XEN) [2012-01-12 12:25:11]  Init. ramdisk: 000000024f96f000->000000024ffff400
> (XEN) [2012-01-12 12:25:11] VIRTUAL MEMORY ARRANGEMENT:
> (XEN) [2012-01-12 12:25:11]  Loaded kernel: ffffffff81000000->ffffffff82b5a000
> (XEN) [2012-01-12 12:25:11]  Init. ramdisk: ffffffff82b5a000->ffffffff831ea400
> (XEN) [2012-01-12 12:25:11]  Phys-Mach map: ffffffff831eb000->ffffffff833eb000
> (XEN) [2012-01-12 12:25:11]  Start info:    ffffffff833eb000->ffffffff833eb4b4
> (XEN) [2012-01-12 12:25:11]  Page tables:   ffffffff833ec000->ffffffff8340b000
> (XEN) [2012-01-12 12:25:11]  Boot stack:    ffffffff8340b000->ffffffff8340c000
> (XEN) [2012-01-12 12:25:11]  TOTAL:         ffffffff80000000->ffffffff83800000
> (XEN) [2012-01-12 12:25:11]  ENTRY ADDRESS: ffffffff81ee5200
> (XEN) [2012-01-12 12:25:11] Dom0 has maximum 6 VCPUs
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0000, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0002, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0010, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0018, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0028, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0030, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0050, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0058, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0068, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0088, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0090, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0092, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0098, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x009a, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a0, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a3, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a4, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a5, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a8, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00b0, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00b2, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.0
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.1
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.2
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.4
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0400, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0401, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0402, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0403, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0404, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0405, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0406, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0407, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0500, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0501, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0600, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0700, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0800, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0900, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a00, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a01, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a02, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a03, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a04, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a05, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a06, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a07, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0b00, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] Scrubbing Free RAM: .......................................................................done.
> (XEN) [2012-01-12 12:25:13] Xen trace buffers: disabled
> (XEN) [2012-01-12 12:25:13] Std. Loglevel: All
> (XEN) [2012-01-12 12:25:13] Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) [2012-01-12 12:25:13] Xen is relinquishing VGA console.
> (XEN) [2012-01-12 12:25:13] *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
> (XEN) [2012-01-12 12:25:13] Freed 220kB init memory.
> (XEN) [2012-01-12 12:25:13] IOAPIC[0]: Set PCI routing entry (6-9 -> 0x60 -> IRQ 9 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:13] traps.c:2432:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000eff2fef31f0c to 0x000000000000abcd.
> (XEN) [2012-01-12 12:25:13] PCI add device 00:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:00.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:02.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:03.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:05.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:06.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:0a.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:0b.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:0d.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:11.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:12.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:12.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:13.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:13.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:14.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:14.3
> (XEN) [2012-01-12 12:25:13] PCI add device 00:14.4
> (XEN) [2012-01-12 12:25:13] PCI add device 00:14.5
> (XEN) [2012-01-12 12:25:13] PCI add device 00:15.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:16.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:16.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.1
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.3
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.4
> (XEN) [2012-01-12 12:25:13] PCI add device 0b:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.1
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.2
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.3
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.4
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.5
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.6
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.7
> (XEN) [2012-01-12 12:25:13] PCI add device 09:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 08:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 06:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 07:01.0
> (XEN) [2012-01-12 12:25:13] PCI add device 07:01.1
> (XEN) [2012-01-12 12:25:13] PCI add device 07:01.2
> (XEN) [2012-01-12 12:25:13] PCI add device 05:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 05:00.1
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.1
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.2
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.3
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.4
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.5
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.6
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.7
> (XEN) [2012-01-12 12:25:13] PCI add device 03:06.0
> (XEN) [2012-01-12 12:25:13] IOAPIC[0]: Set PCI routing entry (6-8 -> 0x58 -> IRQ 8 Mode:0 Active:0)
> (XEN) [2012-01-12 12:25:13] IOAPIC[0]: Set PCI routing entry (6-13 -> 0x88 -> IRQ 13 Mode:0 Active:0)
> (XEN) [2012-01-12 12:25:13] IOAPIC[1]: Set PCI routing entry (7-28 -> 0xa0 -> IRQ 52 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:13] IOAPIC[1]: Set PCI routing entry (7-29 -> 0xa8 -> IRQ 53 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:13] IOAPIC[1]: Set PCI routing entry (7-30 -> 0xb0 -> IRQ 54 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:13] IOAPIC[0]: Set PCI routing entry (6-16 -> 0xb8 -> IRQ 16 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] physdev.c:155: dom0: wrong map_pirq type 3
> (XEN) [2012-01-12 12:25:14] IOAPIC[0]: Set PCI routing entry (6-22 -> 0x41 -> IRQ 22 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-19 -> 0x49 -> IRQ 43 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-18 -> 0x51 -> IRQ 42 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-17 -> 0x59 -> IRQ 41 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-16 -> 0x61 -> IRQ 40 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-9 -> 0x69 -> IRQ 33 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-8 -> 0x71 -> IRQ 32 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-22 -> 0x79 -> IRQ 46 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-21 -> 0x81 -> IRQ 45 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-20 -> 0x89 -> IRQ 44 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-7 -> 0x91 -> IRQ 31 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-6 -> 0x99 -> IRQ 30 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-5 -> 0xa1 -> IRQ 29 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-4 -> 0xa9 -> IRQ 28 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[0]: Set PCI routing entry (6-19 -> 0xb1 -> IRQ 19 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-27 -> 0xc9 -> IRQ 51 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[0]: Set PCI routing entry (6-17 -> 0xd9 -> IRQ 17 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:15] IOAPIC[0]: Set PCI routing entry (6-18 -> 0x22 -> IRQ 18 Mode:1 Active:1)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:11:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:11:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlMIm-0006TU-TG; Thu, 12 Jan 2012 15:10:52 +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 1RlMIk-0006TM-IM
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:10:51 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326381042!10737383!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28680 invoked from network); 12 Jan 2012 15:10:43 -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; 12 Jan 2012 15:10:43 -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
	q0CFAIYJ005412
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 15:10: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
	q0CFAH2E026105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 15:10:18 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
	q0CFAGxp013333; Thu, 12 Jan 2012 09:10:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33) by default (Oracle Beehive
	Gateway v4.0) with ESMTP ; Thu, 12 Jan 2012 07:09:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 2BE8040306;
	Thu, 12 Jan 2012 10:07:17 -0500 (EST)
USER-AGENT: Mutt/1.5.21 (2010-09-15)
MIME-Version: 1.0
Message-ID: <20120112150717.GH7685@phenom.dumpdata.com>
Date: Thu, 12 Jan 2012 07:07:17 -0800 (PST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
References: <498097597.20120112133832@eikelenboom.it>
In-Reply-To: <498097597.20120112133832@eikelenboom.it>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F0EF7E0.0038,ss=1,re=-15.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> 
> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.

Does it work if you use 'xl'?

> 
> dmesg and xm dmesg attached
> 
> --
> Sander
> 
> 
> Dom0 shows:
>              total       used       free     shared    buffers     cached
> Mem:        938860     220484     718376          0      27812      72128
> -/+ buffers/cache:     120544     818316
> Swap:      2097148          0    2097148
> 
> 
> xentop:
> 
> xentop - 13:34:31   Xen 4.1.3-rc1-pre
> 1 domains: 1 running, 0 blocked, 0 paused, 0 crashed, 0 dying, 0 shutdown
> Mem: 8386732k total, 1165260k used, 7221472k free    CPUs: 6 @ 3200MHz
>       NAME  STATE   CPU(sec) CPU(%)     MEM(k) MEM(%)  MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS   VBD_OO   VBD_RD   VBD_WR  VBD_RSECT  VBD_WSECT SSID
>   Domain-0 -----r         82    1.3    1048192   12.5   no limit       n/a     6    0        0        0    0        0        0        0          0          0    0
> 
> 

> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 3.2.0-rc0+ (root@serveerstertje) (gcc version 4.4.5 (Debian 4.4.5-8) ) #9 SMP Thu Jan 12 12:40:24 CET 2012
> [    0.000000] Command line: root=/dev/mapper/serveerstertje-root ro verbose mem=1024M console=hvc0 console=tty0 nomodeset vga=794 video=vesafb earlyprintk=xen max_loop=50 loop_max_part=10 xen-pciback.passthrough=1 xen-pciback.hide=(03:06.0)(04:00.0)(04:00.1)(04:00.2)(04:00.3)(04:00.4)(04:00.5)(04:00.6)(04:00.7)(0a:00.0)(0a:00.1)(0a:00.2)(0a:00.3)(0a:00.4)(0a:00.5)(0a:00.6)(0a:00.7)(05:00.0)(05:00.1)(07:01.0)(07:01.1)(07:01.2) pci=resource_alignment=07:01.0;07:01.1;07:01.2 debug debug loglevel=10
> [    0.000000] Freeing  9b-100 pfn range: 101 pages freed
> [    0.000000] 1-1 mapping on 9b->100
> [    0.000000] 1-1 mapping on afe90->100000
> [    0.000000] Released 101 pages of unused memory
> [    0.000000] Set 328149 page(s) to 1-1 mapping
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  Xen: 0000000000000000 - 000000000009b000 (usable)
> [    0.000000]  Xen: 000000000009b000 - 0000000000100000 (reserved)
> [    0.000000]  Xen: 0000000000100000 - 00000000afe90000 (usable)
> [    0.000000]  Xen: 00000000afe90000 - 00000000afe9e000 (ACPI data)
> [    0.000000]  Xen: 00000000afe9e000 - 00000000afee0000 (ACPI NVS)
> [    0.000000]  Xen: 00000000afee0000 - 00000000aff00000 (reserved)
> [    0.000000]  Xen: 00000000fec00000 - 00000000fec01000 (reserved)
> [    0.000000]  Xen: 00000000fec20000 - 00000000fec21000 (reserved)
> [    0.000000]  Xen: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  Xen: 00000000ffe00000 - 0000000100000000 (reserved)
> [    0.000000]  Xen: 0000000100000000 - 0000000250000000 (usable)
> [    0.000000] e820 remove range: 0000000040000000 - ffffffffffffffff (usable)
> [    0.000000] bootconsole [xenboot0] enabled
> [    0.000000] NX (Execute Disable) protection: active
> [    0.000000] user-defined physical RAM map:
> [    0.000000]  user: 0000000000000000 - 000000000009b000 (usable)
> [    0.000000]  user: 000000000009b000 - 0000000000100000 (reserved)
> [    0.000000]  user: 0000000000100000 - 0000000040000000 (usable)
> [    0.000000]  user: 00000000afe90000 - 00000000afe9e000 (ACPI data)
> [    0.000000]  user: 00000000afe9e000 - 00000000afee0000 (ACPI NVS)
> [    0.000000]  user: 00000000afee0000 - 00000000aff00000 (reserved)
> [    0.000000]  user: 00000000fec00000 - 00000000fec01000 (reserved)
> [    0.000000]  user: 00000000fec20000 - 00000000fec21000 (reserved)
> [    0.000000]  user: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  user: 00000000ffe00000 - 0000000100000000 (reserved)
> [    0.000000] DMI present.
> [    0.000000] DMI: MSI MS-7640/890FXA-GD70 (MS-7640)  , BIOS V1.7B5 06/22/2010
> [    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
> [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
> [    0.000000] No AGP bridge found
> [    0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000
> [    0.000000] found SMP MP-table at [ffff8800000ff780] ff780
> [    0.000000] initial memory mapped : 0 - 031eb000
> [    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 8192
> [    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
> [    0.000000]  0000000000 - 0040000000 page 4k
> [    0.000000] kernel direct mapping tables up to 40000000 @ 2958000-2b5a000
> [    0.000000] xen: setting RW the range 2b38000 - 2b5a000
> [    0.000000] RAMDISK: 02b5a000 - 031eb000
> [    0.000000] ACPI: RSDP 00000000000fb120 00014 (v00 ACPIAM)
> [    0.000000] ACPI: RSDT 00000000afe90000 00048 (v01 MSI    OEMSLIC  20100622 MSFT 00000097)
> [    0.000000] ACPI: FACP 00000000afe90200 00084 (v01 7640MS A7640100 20100622 MSFT 00000097)
> [    0.000000] ACPI: DSDT 00000000afe905e0 09449 (v01  A7640 A7640100 00000100 INTL 20051117)
> [    0.000000] ACPI: FACS 00000000afe9e000 00040
> [    0.000000] ACPI: APIC 00000000afe90390 00088 (v01 7640MS A7640100 20100622 MSFT 00000097)
> [    0.000000] ACPI: MCFG 00000000afe90420 0003C (v01 7640MS OEMMCFG  20100622 MSFT 00000097)
> [    0.000000] ACPI: SLIC 00000000afe90460 00176 (v01 MSI    OEMSLIC  20100622 MSFT 00000097)
> [    0.000000] ACPI: OEMB 00000000afe9e040 00072 (v01 7640MS A7640100 20100622 MSFT 00000097)
> [    0.000000] ACPI: SRAT 00000000afe9a5e0 00108 (v03 AMD    FAM_F_10 00000002 AMD  00000001)
> [    0.000000] ACPI: HPET 00000000afe9a6f0 00038 (v01 7640MS OEMHPET  20100622 MSFT 00000097)
> [    0.000000] ACPI: IVRS 00000000afe9a730 00100 (v01  AMD     RD890S 00202031 AMD  00000000)
> [    0.000000] ACPI: SSDT 00000000afe9a830 00DA4 (v01 A M I  POWERNOW 00000001 AMD  00000001)
> [    0.000000] ACPI: Local APIC address 0xfee00000
> [    0.000000] Scanning NUMA topology in Northbridge 24
> [    0.000000] No NUMA configuration found
> [    0.000000] Faking a node at 0000000000000000-0000000040000000
> [    0.000000] Initmem setup node 0 0000000000000000-0000000040000000
> [    0.000000]   NODE_DATA [000000003fffb000 - 000000003fffffff]
> [    0.000000] Zone PFN ranges:
> [    0.000000]   DMA      0x00000010 -> 0x00001000
> [    0.000000]   DMA32    0x00001000 -> 0x00100000
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start PFN for each node
> [    0.000000] Early memory PFN ranges
> [    0.000000]     0: 0x00000010 -> 0x0000009b
> [    0.000000]     0: 0x00000100 -> 0x00040000
> [    0.000000] On node 0 totalpages: 262027
> [    0.000000]   DMA zone: 64 pages used for memmap
> [    0.000000]   DMA zone: 2 pages reserved
> [    0.000000]   DMA zone: 3913 pages, LIFO batch:0
> [    0.000000]   DMA32 zone: 4032 pages used for memmap
> [    0.000000]   DMA32 zone: 254016 pages, LIFO batch:31
> [    0.000000] ACPI: PM-Timer IO Port: 0x808
> [    0.000000] ACPI: Local APIC address 0xfee00000
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> [    0.000000] BIOS bug: APIC version is 0 for CPU 0/0x0, fixing up to 0x10
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled)
> [    0.000000] ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 6, version 255, address 0xfec00000, GSI 0-255
> [    0.000000] ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> [    0.000000] IOAPIC[1]: apic_id 7, version 255, address 0xfec20000, GSI 24-279
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
> [    0.000000] ACPI: IRQ0 used by override.
> [    0.000000] ACPI: IRQ2 used by override.
> [    0.000000] ACPI: IRQ9 used by override.
> [    0.000000] Using ACPI (MADT) for SMP configuration information
> [    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
> [    0.000000] SMP: Allowing 6 CPUs, 0 hotplug CPUs
> [    0.000000] nr_irqs_gsi: 296
> [    0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:6fe90000)
> [    0.000000] Booting paravirtualized kernel on Xen
> [    0.000000] Xen version: 4.1.3-rc1-pre (preserve-AD)
> [    0.000000] setup_percpu: NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:6 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 27 pages/cpu @ffff88003ff3e000 s78784 r8192 d23616 u110592
> [    0.000000] pcpu-alloc: s78784 r8192 d23616 u110592 alloc=27*4096
> [    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 
> [    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 257929
> [    0.000000] Policy zone: DMA32
> [    0.000000] Kernel command line: root=/dev/mapper/serveerstertje-root ro verbose mem=1024M console=hvc0 console=tty0 nomodeset vga=794 video=vesafb earlyprintk=xen max_loop=50 loop_max_part=10 xen-pciback.passthrough=1 xen-pciback.hide=(03:06.0)(04:00.0)(04:00.1)(04:00.2)(04:00.3)(04:00.4)(04:00.5)(04:00.6)(04:00.7)(0a:00.0)(0a:00.1)(0a:00.2)(0a:00.3)(0a:00.4)(0a:00.5)(0a:00.6)(0a:00.7)(05:00.0)(05:00.1)(07:01.0)(07:01.1)(07:01.2) pci=resource_alignment=07:01.0;07:01.1;07:01.2 debug debug loglevel=10
> [    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
> [    0.000000] Placing 64MB software IO TLB between ffff88003a600000 - ffff88003e600000
> [    0.000000] software IO TLB at phys 0x3a600000 - 0x3e600000
> [    0.000000] Memory: 930212k/1048576k available (9111k kernel code, 468k absent, 117896k reserved, 6056k data, 644k init)
> [    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1
> [    0.000000] Hierarchical RCU implementation.
> [    0.000000] NR_IRQS:4352 nr_irqs:1536 16
> [    0.000000] xen: sci override: global_irq=9 trigger=0 polarity=1
> [    0.000000] xen: registering gsi 9 triggering 0 polarity 1
> [    0.000000] xen: --> pirq=9 -> irq=9 (gsi=9)
> [    0.000000] xen: acpi sci 9
> [    0.000000] xen: --> pirq=1 -> irq=1 (gsi=1)
> [    0.000000] xen: --> pirq=2 -> irq=2 (gsi=2)
> [    0.000000] xen: --> pirq=3 -> irq=3 (gsi=3)
> [    0.000000] xen: --> pirq=4 -> irq=4 (gsi=4)
> [    0.000000] xen: --> pirq=5 -> irq=5 (gsi=5)
> [    0.000000] xen: --> pirq=6 -> irq=6 (gsi=6)
> [    0.000000] xen: --> pirq=7 -> irq=7 (gsi=7)
> [    0.000000] xen: --> pirq=8 -> irq=8 (gsi=8)
> [    0.000000] xen_map_pirq_gsi: returning irq 9 for gsi 9
> [    0.000000] xen: --> pirq=9 -> irq=9 (gsi=9)
> [    0.000000] xen: --> pirq=10 -> irq=10 (gsi=10)
> [    0.000000] xen: --> pirq=11 -> irq=11 (gsi=11)
> [    0.000000] xen: --> pirq=12 -> irq=12 (gsi=12)
> [    0.000000] xen: --> pirq=13 -> irq=13 (gsi=13)
> [    0.000000] xen: --> pirq=14 -> irq=14 (gsi=14)
> [    0.000000] xen: --> pirq=15 -> irq=15 (gsi=15)
> [    0.000000] Console: colour dummy device 80x25
> [    0.000000] console [tty0] enabled, bootconsole disabled
> [    0.000000] console [hvc0] enabled
> [    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> [    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
> [    0.000000] ... MAX_LOCK_DEPTH:          48
> [    0.000000] ... MAX_LOCKDEP_KEYS:        8191
> [    0.000000] ... CLASSHASH_SIZE:          4096
> [    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
> [    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
> [    0.000000] ... CHAINHASH_SIZE:          16384
> [    0.000000]  memory used by lock dependency info: 5823 kB
> [    0.000000]  per task-struct memory footprint: 1920 bytes
> [    0.000000] Xen: using vcpuop timer interface
> [    0.000000] installing Xen timer for CPU 0
> [    0.000000] Detected 3200.160 MHz processor.
> [    0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 6400.32 BogoMIPS (lpj=3200160)
> [    0.000999] pid_max: default: 32768 minimum: 301
> [    0.000999] Security Framework initialized
> [    0.000999] SELinux:  Initializing.
> [    0.000999] SELinux:  Starting in permissive mode
> [    0.000999] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> [    0.000999] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> [    0.000999] Mount-cache hash table entries: 256
> [    0.001378] Initializing cgroup subsys cpuacct
> [    0.001384] Initializing cgroup subsys freezer
> [    0.001445] tseg: 0000000000
> [    0.001466] CPU: Physical Processor ID: 0
> [    0.001470] CPU: Processor Core ID: 0
> [    0.002271] ACPI: Core revision 20110623
> [    0.013132] cpu 0 spinlock event irq 297
> [    0.013258] Performance Events: Broken PMU hardware detected, using software events only.
> [    0.013501] MCE: In-kernel MCE decoding enabled.
> [    0.013515] NMI watchdog disabled (cpu0): hardware events not enabled
> [    0.013684] installing Xen timer for CPU 1
> [    0.013704] cpu 1 spinlock event irq 303
> [    0.013729] lockdep: fixing up alternatives.
> [    0.013854] NMI watchdog disabled (cpu1): hardware events not enabled
> [    0.013998] installing Xen timer for CPU 2
> [    0.013998] cpu 2 spinlock event irq 309
> [    0.014098] NMI watchdog disabled (cpu2): hardware events not enabled
> [    0.014268] installing Xen timer for CPU 3
> [    0.014287] cpu 3 spinlock event irq 315
> [    0.014408] NMI watchdog disabled (cpu3): hardware events not enabled
> [    0.014560] installing Xen timer for CPU 4
> [    0.014581] cpu 4 spinlock event irq 321
> [    0.014702] NMI watchdog disabled (cpu4): hardware events not enabled
> [    0.014857] installing Xen timer for CPU 5
> [    0.014876] cpu 5 spinlock event irq 327
> [    0.015067] NMI watchdog disabled (cpu5): hardware events not enabled
> [    0.015120] Brought up 6 CPUs
> [    0.016561] Grant tables using version 2 layout.
> [    0.016561] Grant table initialized
> [    0.016561] RTC time: 12:25:12, date: 01/12/12
> [    0.016561] NET: Registered protocol family 16
> [    0.018139] node 0 link 0: io port [1000, ffffff]
> [    0.018139] TOM: 00000000b0000000 aka 2816M
> [    0.018139] Fam 10h mmconf [mem 0xe0000000-0xefffffff]
> [    0.018139] node 0 link 0: mmio [e0000000, efffffff] ==> none
> [    0.018139] node 0 link 0: mmio [f0000000, ffffffff]
> [    0.018139] node 0 link 0: mmio [a0000, bffff]
> [    0.018139] node 0 link 0: mmio [b0000000, dfffffff]
> [    0.018139] TOM2: 0000000250000000 aka 9472M
> [    0.018139] bus: [00, 07] on node 0 link 0
> [    0.018139] bus: 00 index 0 [io  0x0000-0xffff]
> [    0.018139] bus: 00 index 1 [mem 0xf0000000-0xffffffff]
> [    0.018139] bus: 00 index 2 [mem 0x000a0000-0x000bffff]
> [    0.018139] bus: 00 index 3 [mem 0xb0000000-0xdfffffff]
> [    0.018139] bus: 00 index 4 [mem 0x250000000-0xfcffffffff]
> [    0.018309] ACPI: bus type pci registered
> [    0.018381] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
> [    0.018381] PCI: not using MMCONFIG
> [    0.018381] PCI: Using configuration type 1 for base access
> [    0.018381] PCI: Using configuration type 1 for extended access
> [    0.068102] bio: create slab <bio-0> at 0
> [    0.068119] ACPI: Added _OSI(Module Device)
> [    0.068119] ACPI: Added _OSI(Processor Device)
> [    0.068119] ACPI: Added _OSI(3.0 _SCP Extensions)
> [    0.068119] ACPI: Added _OSI(Processor Aggregator Device)
> [    0.073523] ACPI: EC: Look up EC in DSDT
> [    0.075207] ACPI: Executed 3 blocks of module-level executable AML code
> [    0.088960] ACPI: Interpreter enabled
> [    0.088967] ACPI: (supports S0 S5)
> [    0.088992] ACPI: Using IOAPIC for interrupt routing
> [    0.088992] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
> [    0.091780] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
> [    0.185504] ACPI: No dock devices found.
> [    0.185512] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
> [    0.186307] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
> [    0.186633] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
> [    0.186640] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
> [    0.186646] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
> [    0.186652] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff]
> [    0.186659] pci_root PNP0A03:00: host bridge window [mem 0xb0000000-0xdfffffff]
> [    0.186672] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfebfffff]
> [    0.186808] PCI host bridge to bus 0000:00
> [    0.186808] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
> [    0.186808] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
> [    0.186808] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
> [    0.186808] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]
> [    0.186808] pci_bus 0000:00: root bus resource [mem 0xb0000000-0xdfffffff]
> [    0.186808] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff]
> [    0.186808] pci 0000:00:00.0: [1002:5a11] type 0 class 0x000600
> [    0.186808] pci 0000:00:00.2: [1002:5a23] type 0 class 0x000806
> [    0.187000] pci 0000:00:02.0: [1002:5a16] type 1 class 0x000604
> [    0.187127] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
> [    0.187176] pci 0000:00:03.0: [1002:5a17] type 1 class 0x000604
> [    0.187322] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
> [    0.187368] pci 0000:00:05.0: [1002:5a19] type 1 class 0x000604
> [    0.187493] pci 0000:00:05.0: PME# supported from D0 D3hot D3cold
> [    0.187536] pci 0000:00:06.0: [1002:5a1a] type 1 class 0x000604
> [    0.187661] pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
> [    0.187713] pci 0000:00:0a.0: [1002:5a1d] type 1 class 0x000604
> [    0.187841] pci 0000:00:0a.0: PME# supported from D0 D3hot D3cold
> [    0.187884] pci 0000:00:0b.0: [1002:5a1f] type 1 class 0x000604
> [    0.187980] pci 0000:00:0b.0: PME# supported from D0 D3hot D3cold
> [    0.187980] pci 0000:00:0d.0: [1002:5a1e] type 1 class 0x000604
> [    0.187980] pci 0000:00:0d.0: PME# supported from D0 D3hot D3cold
> [    0.187980] pci 0000:00:11.0: [1002:4391] type 0 class 0x000106
> [    0.187980] pci 0000:00:11.0: reg 10: [io  0x7000-0x7007]
> [    0.187980] pci 0000:00:11.0: reg 14: [io  0x6000-0x6003]
> [    0.187980] pci 0000:00:11.0: reg 18: [io  0x5000-0x5007]
> [    0.187980] pci 0000:00:11.0: reg 1c: [io  0x3000-0x3003]
> [    0.187980] pci 0000:00:11.0: reg 20: [io  0x2000-0x200f]
> [    0.187980] pci 0000:00:11.0: reg 24: [mem 0xf98ff000-0xf98ff3ff]
> [    0.187996] pci 0000:00:12.0: [1002:4397] type 0 class 0x000c03
> [    0.188027] pci 0000:00:12.0: reg 10: [mem 0xf98fb000-0xf98fbfff]
> [    0.188179] pci 0000:00:12.2: [1002:4396] type 0 class 0x000c03
> [    0.188211] pci 0000:00:12.2: reg 10: [mem 0xf98ff400-0xf98ff4ff]
> [    0.188354] pci 0000:00:12.2: supports D1 D2
> [    0.188365] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
> [    0.188406] pci 0000:00:13.0: [1002:4397] type 0 class 0x000c03
> [    0.188429] pci 0000:00:13.0: reg 10: [mem 0xf98fc000-0xf98fcfff]
> [    0.188562] pci 0000:00:13.2: [1002:4396] type 0 class 0x000c03
> [    0.188594] pci 0000:00:13.2: reg 10: [mem 0xf98ff800-0xf98ff8ff]
> [    0.188744] pci 0000:00:13.2: supports D1 D2
> [    0.188748] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
> [    0.188787] pci 0000:00:14.0: [1002:4385] type 0 class 0x000c05
> [    0.188927] pci 0000:00:14.3: [1002:439d] type 0 class 0x000601
> [    0.188980] pci 0000:00:14.4: [1002:4384] type 1 class 0x000604
> [    0.188980] pci 0000:00:14.5: [1002:4399] type 0 class 0x000c03
> [    0.188980] pci 0000:00:14.5: reg 10: [mem 0xf98fd000-0xf98fdfff]
> [    0.189002] pci 0000:00:15.0: [1002:43a0] type 1 class 0x000604
> [    0.189153] pci 0000:00:15.0: supports D1 D2
> [    0.189237] pci 0000:00:16.0: [1002:4397] type 0 class 0x000c03
> [    0.189260] pci 0000:00:16.0: reg 10: [mem 0xf98fe000-0xf98fefff]
> [    0.189385] pci 0000:00:16.2: [1002:4396] type 0 class 0x000c03
> [    0.189417] pci 0000:00:16.2: reg 10: [mem 0xf98ffc00-0xf98ffcff]
> [    0.189567] pci 0000:00:16.2: supports D1 D2
> [    0.189571] pci 0000:00:16.2: PME# supported from D0 D1 D2 D3hot
> [    0.189614] pci 0000:00:18.0: [1022:1200] type 0 class 0x000600
> [    0.189700] pci 0000:00:18.1: [1022:1201] type 0 class 0x000600
> [    0.189765] pci 0000:00:18.2: [1022:1202] type 0 class 0x000600
> [    0.189834] pci 0000:00:18.3: [1022:1203] type 0 class 0x000600
> [    0.189920] pci 0000:00:18.4: [1022:1204] type 0 class 0x000600
> [    0.190004] pci 0000:0b:00.0: [10de:06e4] type 0 class 0x000300
> [    0.190026] pci 0000:0b:00.0: reg 10: [mem 0xfd000000-0xfdffffff]
> [    0.190050] pci 0000:0b:00.0: reg 14: [mem 0xd0000000-0xdfffffff 64bit pref]
> [    0.190082] pci 0000:0b:00.0: reg 1c: [mem 0xfa000000-0xfbffffff 64bit]
> [    0.190099] pci 0000:0b:00.0: reg 24: [io  0xe800-0xe87f]
> [    0.190116] pci 0000:0b:00.0: reg 30: [mem 0xfe9e0000-0xfe9fffff pref]
> [    0.192019] pci 0000:00:02.0: PCI bridge to [bus 0b-0b]
> [    0.192032] pci 0000:00:02.0:   bridge window [io  0xe000-0xefff]
> [    0.192040] pci 0000:00:02.0:   bridge window [mem 0xfa000000-0xfe9fffff]
> [    0.192057] pci 0000:00:02.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
> [    0.192166] pci 0000:0a:00.0: [9710:9990] type 0 class 0x000c03
> [    0.192194] pci 0000:0a:00.0: reg 10: [mem 0xf9ff8000-0xf9ff8fff]
> [    0.192404] pci 0000:0a:00.0: supports D1 D2
> [    0.192408] pci 0000:0a:00.0: PME# supported from D0 D1 D2 D3hot
> [    0.192471] pci 0000:0a:00.1: [9710:9990] type 0 class 0x000c03
> [    0.192504] pci 0000:0a:00.1: reg 10: [mem 0xf9ff9000-0xf9ff9fff]
> [    0.192701] pci 0000:0a:00.1: supports D1 D2
> [    0.192705] pci 0000:0a:00.1: PME# supported from D0 D1 D2 D3hot
> [    0.192774] pci 0000:0a:00.2: [9710:9990] type 0 class 0x000c03
> [    0.192801] pci 0000:0a:00.2: reg 10: [mem 0xf9ffa000-0xf9ffafff]
> [    0.192979] pci 0000:0a:00.2: supports D1 D2
> [    0.192979] pci 0000:0a:00.2: PME# supported from D0 D1 D2 D3hot
> [    0.192979] pci 0000:0a:00.3: [9710:9990] type 0 class 0x000c03
> [    0.192979] pci 0000:0a:00.3: reg 10: [mem 0xf9ffb000-0xf9ffbfff]
> [    0.192979] pci 0000:0a:00.3: supports D1 D2
> [    0.192979] pci 0000:0a:00.3: PME# supported from D0 D1 D2 D3hot
> [    0.193038] pci 0000:0a:00.4: [9710:9990] type 0 class 0x000c03
> [    0.193074] pci 0000:0a:00.4: reg 10: [mem 0xf9ffc000-0xf9ffcfff]
> [    0.193286] pci 0000:0a:00.4: supports D1 D2
> [    0.193290] pci 0000:0a:00.4: PME# supported from D0 D1 D2 D3hot
> [    0.193357] pci 0000:0a:00.5: [9710:9990] type 0 class 0x000c03
> [    0.193384] pci 0000:0a:00.5: reg 10: [mem 0xf9ffd000-0xf9ffdfff]
> [    0.193588] pci 0000:0a:00.5: supports D1 D2
> [    0.193592] pci 0000:0a:00.5: PME# supported from D0 D1 D2 D3hot
> [    0.193653] pci 0000:0a:00.6: [9710:9990] type 0 class 0x000c03
> [    0.193687] pci 0000:0a:00.6: reg 10: [mem 0xf9ffe000-0xf9ffefff]
> [    0.193883] pci 0000:0a:00.6: supports D1 D2
> [    0.193887] pci 0000:0a:00.6: PME# supported from D0 D1 D2 D3hot
> [    0.193958] pci 0000:0a:00.7: [9710:9990] type 0 class 0x000c03
> [    0.193979] pci 0000:0a:00.7: reg 10: [mem 0xf9fff000-0xf9ffffff]
> [    0.193979] pci 0000:0a:00.7: supports D1 D2
> [    0.193979] pci 0000:0a:00.7: PME# supported from D0 D1 D2 D3hot
> [    0.195058] pci 0000:00:03.0: PCI bridge to [bus 0a-0a]
> [    0.195071] pci 0000:00:03.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
> [    0.195205] pci 0000:09:00.0: [10ec:8168] type 0 class 0x000200
> [    0.195229] pci 0000:09:00.0: reg 10: [io  0xd800-0xd8ff]
> [    0.195277] pci 0000:09:00.0: reg 18: [mem 0xcffff000-0xcfffffff 64bit pref]
> [    0.195304] pci 0000:09:00.0: reg 20: [mem 0xcfff8000-0xcfffbfff 64bit pref]
> [    0.195324] pci 0000:09:00.0: reg 30: [mem 0xf9ee0000-0xf9efffff pref]
> [    0.195430] pci 0000:09:00.0: supports D1 D2
> [    0.195434] pci 0000:09:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [    0.197018] pci 0000:00:05.0: PCI bridge to [bus 09-09]
> [    0.197030] pci 0000:00:05.0:   bridge window [io  0xd000-0xdfff]
> [    0.197038] pci 0000:00:05.0:   bridge window [mem 0xf9e00000-0xf9efffff]
> [    0.197049] pci 0000:00:05.0:   bridge window [mem 0xcff00000-0xcfffffff 64bit pref]
> [    0.197151] pci 0000:08:00.0: [10ec:8168] type 0 class 0x000200
> [    0.197182] pci 0000:08:00.0: reg 10: [io  0xc800-0xc8ff]
> [    0.197222] pci 0000:08:00.0: reg 18: [mem 0xcfeff000-0xcfefffff 64bit pref]
> [    0.197249] pci 0000:08:00.0: reg 20: [mem 0xcfef8000-0xcfefbfff 64bit pref]
> [    0.197275] pci 0000:08:00.0: reg 30: [mem 0xf9de0000-0xf9dfffff pref]
> [    0.197375] pci 0000:08:00.0: supports D1 D2
> [    0.197379] pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [    0.199002] pci 0000:00:06.0: PCI bridge to [bus 08-08]
> [    0.199012] pci 0000:00:06.0:   bridge window [io  0xc000-0xcfff]
> [    0.199020] pci 0000:00:06.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
> [    0.199030] pci 0000:00:06.0:   bridge window [mem 0xcfe00000-0xcfefffff 64bit pref]
> [    0.199140] pci 0000:06:00.0: [104c:8231] type 1 class 0x000604
> [    0.199335] pci 0000:06:00.0: supports D1 D2
> [    0.199377] pci 0000:06:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
> [    0.199396] pci 0000:00:0a.0: PCI bridge to [bus 06-07]
> [    0.199410] pci 0000:00:0a.0:   bridge window [mem 0xf9c00000-0xf9cfffff]
> [    0.199561] pci 0000:07:01.0: [1033:0035] type 0 class 0x000c03
> [    0.199600] pci 0000:07:01.0: reg 10: [mem 0xf9cfd000-0xf9cfdfff]
> [    0.199735] pci 0000:07:01.0: Disabling memory decoding and releasing memory resources.
> [    0.199803] pci 0000:07:01.0: supports D1 D2
> [    0.199807] pci 0000:07:01.0: PME# supported from D0 D1 D2 D3hot
> [    0.199864] pci 0000:07:01.1: [1033:0035] type 0 class 0x000c03
> [    0.199910] pci 0000:07:01.1: reg 10: [mem 0xf9cfe000-0xf9cfefff]
> [    0.199978] pci 0000:07:01.1: Disabling memory decoding and releasing memory resources.
> [    0.199978] pci 0000:07:01.1: supports D1 D2
> [    0.199978] pci 0000:07:01.1: PME# supported from D0 D1 D2 D3hot
> [    0.199978] pci 0000:07:01.2: [1033:00e0] type 0 class 0x000c03
> [    0.199978] pci 0000:07:01.2: reg 10: [mem 0xf9cffc00-0xf9cffcff]
> [    0.199978] pci 0000:07:01.2: Disabling memory decoding and releasing memory resources.
> [    0.199978] pci 0000:07:01.2: Rounding up size of resource #0 to 0x1000.
> [    0.199978] pci 0000:07:01.2: supports D1 D2
> [    0.199978] pci 0000:07:01.2: PME# supported from D0 D1 D2 D3hot
> [    0.199978] pci 0000:06:00.0: PCI bridge to [bus 07-07]
> [    0.199978] pci 0000:06:00.0:   bridge window [mem 0xf9c00000-0xf9cfffff]
> [    0.199978] pci 0000:05:00.0: [1002:95c5] type 0 class 0x000300
> [    0.199978] pci 0000:05:00.0: reg 10: [mem 0xb0000000-0xbfffffff 64bit pref]
> [    0.199978] pci 0000:05:00.0: reg 18: [mem 0xf9be0000-0xf9beffff 64bit]
> [    0.199978] pci 0000:05:00.0: reg 20: [io  0xb000-0xb0ff]
> [    0.199978] pci 0000:05:00.0: reg 30: [mem 0xf9bc0000-0xf9bdffff pref]
> [    0.199978] pci 0000:05:00.0: supports D1 D2
> [    0.200017] pci 0000:05:00.1: [1002:aa28] type 0 class 0x000403
> [    0.200060] pci 0000:05:00.1: reg 10: [mem 0xf9bfc000-0xf9bfffff 64bit]
> [    0.200240] pci 0000:05:00.1: supports D1 D2
> [    0.202001] pci 0000:00:0b.0: PCI bridge to [bus 05-05]
> [    0.202011] pci 0000:00:0b.0:   bridge window [io  0xb000-0xbfff]
> [    0.202018] pci 0000:00:0b.0:   bridge window [mem 0xf9b00000-0xf9bfffff]
> [    0.202029] pci 0000:00:0b.0:   bridge window [mem 0xb0000000-0xbfffffff 64bit pref]
> [    0.202133] pci 0000:04:00.0: [9710:9990] type 0 class 0x000c03
> [    0.202159] pci 0000:04:00.0: reg 10: [mem 0xf9af8000-0xf9af8fff]
> [    0.202354] pci 0000:04:00.0: supports D1 D2
> [    0.202358] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot
> [    0.202426] pci 0000:04:00.1: [9710:9990] type 0 class 0x000c03
> [    0.202452] pci 0000:04:00.1: reg 10: [mem 0xf9af9000-0xf9af9fff]
> [    0.202653] pci 0000:04:00.1: supports D1 D2
> [    0.202658] pci 0000:04:00.1: PME# supported from D0 D1 D2 D3hot
> [    0.202717] pci 0000:04:00.2: [9710:9990] type 0 class 0x000c03
> [    0.202750] pci 0000:04:00.2: reg 10: [mem 0xf9afa000-0xf9afafff]
> [    0.202945] pci 0000:04:00.2: supports D1 D2
> [    0.202949] pci 0000:04:00.2: PME# supported from D0 D1 D2 D3hot
> [    0.202978] pci 0000:04:00.3: [9710:9990] type 0 class 0x000c03
> [    0.202978] pci 0000:04:00.3: reg 10: [mem 0xf9afb000-0xf9afbfff]
> [    0.203054] pci 0000:04:00.3: supports D1 D2
> [    0.203065] pci 0000:04:00.3: PME# supported from D0 D1 D2 D3hot
> [    0.203124] pci 0000:04:00.4: [9710:9990] type 0 class 0x000c03
> [    0.203185] pci 0000:04:00.4: reg 10: [mem 0xf9afc000-0xf9afcfff]
> [    0.203373] pci 0000:04:00.4: supports D1 D2
> [    0.203380] pci 0000:04:00.4: PME# supported from D0 D1 D2 D3hot
> [    0.203447] pci 0000:04:00.5: [9710:9990] type 0 class 0x000c03
> [    0.203474] pci 0000:04:00.5: reg 10: [mem 0xf9afd000-0xf9afdfff]
> [    0.203675] pci 0000:04:00.5: supports D1 D2
> [    0.203679] pci 0000:04:00.5: PME# supported from D0 D1 D2 D3hot
> [    0.203738] pci 0000:04:00.6: [9710:9990] type 0 class 0x000c03
> [    0.203771] pci 0000:04:00.6: reg 10: [mem 0xf9afe000-0xf9afefff]
> [    0.203966] pci 0000:04:00.6: supports D1 D2
> [    0.203970] pci 0000:04:00.6: PME# supported from D0 D1 D2 D3hot
> [    0.203977] pci 0000:04:00.7: [9710:9990] type 0 class 0x000c03
> [    0.203977] pci 0000:04:00.7: reg 10: [mem 0xf9aff000-0xf9afffff]
> [    0.203977] pci 0000:04:00.7: supports D1 D2
> [    0.203977] pci 0000:04:00.7: PME# supported from D0 D1 D2 D3hot
> [    0.205070] pci 0000:00:0d.0: PCI bridge to [bus 04-04]
> [    0.205085] pci 0000:00:0d.0:   bridge window [mem 0xf9a00000-0xf9afffff]
> [    0.205152] pci 0000:03:06.0: [13f6:0111] type 0 class 0x000401
> [    0.205194] pci 0000:03:06.0: reg 10: [io  0xa800-0xa8ff]
> [    0.205352] pci 0000:03:06.0: supports D1 D2
> [    0.205432] pci 0000:00:14.4: PCI bridge to [bus 03-03] (subtractive decode)
> [    0.205476] pci 0000:00:14.4:   bridge window [io  0xa000-0xafff]
> [    0.205488] pci 0000:00:14.4:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
> [    0.205494] pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff] (subtractive decode)
> [    0.205500] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
> [    0.205506] pci 0000:00:14.4:   bridge window [mem 0x000d0000-0x000dffff] (subtractive decode)
> [    0.205512] pci 0000:00:14.4:   bridge window [mem 0xb0000000-0xdfffffff] (subtractive decode)
> [    0.205518] pci 0000:00:14.4:   bridge window [mem 0xf0000000-0xfebfffff] (subtractive decode)
> [    0.205604] pci 0000:00:15.0: PCI bridge to [bus 02-02]
> [    0.205687] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> [    0.205926] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC02._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC03._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC05._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC06._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0A._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0B._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PC0D._PRT]
> [    0.205977] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
> [    0.205981] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PE20._PRT]
> [    0.206241]  pci0000:00: Requesting ACPI _OSC control (0x1d)
> [    0.206571]  pci0000:00: ACPI _OSC control (0x1d) granted
> [    0.233186] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 7 *10 11 14 15)
> [    0.234003] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 14 15)
> [    0.234169] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 *10 11 14 15)
> [    0.234321] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 14 15)
> [    0.234457] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 *7 10 11 14 15)
> [    0.234559] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 *11 14 15)
> [    0.234656] ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 *10 11 14 15)
> [    0.234755] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 *10 11 14 15)
> [    0.235025] xen/balloon: Initialising balloon driver.
> [    0.235074] xen-balloon: Initialising balloon driver.
> [    0.235158] vgaarb: device added: PCI:0000:0b:00.0,decodes=io+mem,owns=io+mem,locks=none
> [    0.235158] vgaarb: device added: PCI:0000:05:00.0,decodes=io+mem,owns=none,locks=none
> [    0.235158] vgaarb: loaded
> [    0.235158] vgaarb: bridge control possible 0000:05:00.0
> [    0.235158] vgaarb: bridge control possible 0000:0b:00.0
> [    0.236066] SCSI subsystem initialized
> [    0.236086] libata version 3.00 loaded.
> [    0.236086] usbcore: registered new interface driver usbfs
> [    0.237032] usbcore: registered new interface driver hub
> [    0.237075] usbcore: registered new device driver usb
> [    0.237143] Advanced Linux Sound Architecture Driver Version 1.0.24.
> [    0.237143] PCI: Using ACPI for IRQ routing
> [    0.244971] PCI: pci_cache_line_size set to 64 bytes
> [    0.245035] reserve RAM buffer: 000000000009b000 - 000000000009ffff 
> [    0.245158] NetLabel: Initializing
> [    0.245158] NetLabel:  domain hash size = 128
> [    0.245158] NetLabel:  protocols = UNLABELED CIPSOv4
> [    0.245158] NetLabel:  unlabeled traffic allowed by default
> [    0.245313] Switching to clocksource xen
> [    0.245448] pnp: PnP ACPI init
> [    0.245448] ACPI: bus type pnp registered
> [    0.245494] pnp 00:00: [bus 00-ff]
> [    0.245499] pnp 00:00: [io  0x0cf8-0x0cff]
> [    0.245505] pnp 00:00: [io  0x0000-0x0cf7 window]
> [    0.245509] pnp 00:00: [io  0x0d00-0xffff window]
> [    0.245514] pnp 00:00: [mem 0x000a0000-0x000bffff window]
> [    0.245519] pnp 00:00: [mem 0x000d0000-0x000dffff window]
> [    0.245525] pnp 00:00: [mem 0xb0000000-0xdfffffff window]
> [    0.245530] pnp 00:00: [mem 0xf0000000-0xfebfffff window]
> [    0.245821] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
> [    0.245994] pnp 00:01: [mem 0x00000000-0xffffffffffffffff disabled]
> [    0.246000] pnp 00:01: [mem 0xfec20000-0xfec200ff]
> [    0.246266] system 00:01: [mem 0xfec20000-0xfec200ff] could not be reserved
> [    0.246275] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.246402] pnp 00:02: [mem 0xf6000000-0xf6003fff]
> [    0.246646] system 00:02: [mem 0xf6000000-0xf6003fff] has been reserved
> [    0.246654] system 00:02: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.246939] pnp 00:03: [dma 4]
> [    0.246943] pnp 00:03: [io  0x0000-0x000f]
> [    0.246946] pnp 00:03: [io  0x0081-0x0083]
> [    0.246950] pnp 00:03: [io  0x0087]
> [    0.246954] pnp 00:03: [io  0x0089-0x008b]
> [    0.246957] pnp 00:03: [io  0x008f]
> [    0.246963] pnp 00:03: [io  0x00c0-0x00df]
> [    0.247167] pnp 00:03: Plug and Play ACPI device, IDs PNP0200 (active)
> [    0.247198] pnp 00:04: [io  0x0070-0x0071]
> [    0.247203] xen: registering gsi 8 triggering 1 polarity 0
> [    0.247211] xen_map_pirq_gsi: returning irq 8 for gsi 8
> [    0.247215] xen: --> pirq=8 -> irq=8 (gsi=8)
> [    0.247232] pnp 00:04: [irq 8]
> [    0.247433] pnp 00:04: Plug and Play ACPI device, IDs PNP0b00 (active)
> [    0.247514] pnp 00:05: [io  0x0061]
> [    0.247753] pnp 00:05: Plug and Play ACPI device, IDs PNP0800 (active)
> [    0.247772] pnp 00:06: [io  0x00f0-0x00ff]
> [    0.247777] xen: registering gsi 13 triggering 1 polarity 0
> [    0.247782] xen_map_pirq_gsi: returning irq 13 for gsi 13
> [    0.247787] xen: --> pirq=13 -> irq=13 (gsi=13)
> [    0.247803] pnp 00:06: [irq 13]
> [    0.247999] pnp 00:06: Plug and Play ACPI device, IDs PNP0c04 (active)
> [    0.248431] pnp 00:07: [io  0x03f8-0x03ff]
> [    0.248436] xen: registering gsi 4 triggering 1 polarity 0
> [    0.248442] xen_map_pirq_gsi: returning irq 4 for gsi 4
> [    0.248446] xen: --> pirq=4 -> irq=4 (gsi=4)
> [    0.248450] Already setup the GSI :4
> [    0.248454] pnp 00:07: [irq 4]
> [    0.248457] pnp 00:07: [dma 0 disabled]
> [    0.248699] pnp 00:07: Plug and Play ACPI device, IDs PNP0501 (active)
> [    0.248860] pnp 00:08: [io  0x0000-0xffffffffffffffff disabled]
> [    0.248865] pnp 00:08: [io  0x0600-0x06df]
> [    0.248869] pnp 00:08: [io  0x0ae0-0x0aef]
> [    0.249198] system 00:08: [io  0x0600-0x06df] has been reserved
> [    0.249205] system 00:08: [io  0x0ae0-0x0aef] has been reserved
> [    0.249212] system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.249265] pnp 00:09: [mem 0xfed00000-0xfed003ff]
> [    0.249479] pnp 00:09: Plug and Play ACPI device, IDs PNP0103 (active)
> [    0.249637] pnp 00:0a: [io  0x0060]
> [    0.249641] pnp 00:0a: [io  0x0064]
> [    0.249645] pnp 00:0a: [mem 0xfec00000-0xfec00fff]
> [    0.249649] pnp 00:0a: [mem 0xfee00000-0xfee00fff]
> [    0.249944] system 00:0a: [mem 0xfec00000-0xfec00fff] could not be reserved
> [    0.249951] system 00:0a: [mem 0xfee00000-0xfee00fff] has been reserved
> [    0.249958] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.250244] pnp 00:0b: [io  0x0010-0x001f]
> [    0.250248] pnp 00:0b: [io  0x0022-0x003f]
> [    0.250255] pnp 00:0b: [io  0x0062-0x0063]
> [    0.250259] pnp 00:0b: [io  0x0065-0x006f]
> [    0.250263] pnp 00:0b: [io  0x0072-0x007f]
> [    0.250266] pnp 00:0b: [io  0x0080]
> [    0.250270] pnp 00:0b: [io  0x0084-0x0086]
> [    0.250274] pnp 00:0b: [io  0x0088]
> [    0.250277] pnp 00:0b: [io  0x008c-0x008e]
> [    0.250281] pnp 00:0b: [io  0x0090-0x009f]
> [    0.250284] pnp 00:0b: [io  0x00a2-0x00bf]
> [    0.250288] pnp 00:0b: [io  0x00b1]
> [    0.250292] pnp 00:0b: [io  0x00e0-0x00ef]
> [    0.250295] pnp 00:0b: [io  0x04d0-0x04d1]
> [    0.250299] pnp 00:0b: [io  0x040b]
> [    0.250303] pnp 00:0b: [io  0x04d6]
> [    0.250306] pnp 00:0b: [io  0x0c00-0x0c01]
> [    0.250317] pnp 00:0b: [io  0x0c14]
> [    0.250320] pnp 00:0b: [io  0x0c50-0x0c51]
> [    0.250324] pnp 00:0b: [io  0x0c52]
> [    0.250327] pnp 00:0b: [io  0x0c6c]
> [    0.250331] pnp 00:0b: [io  0x0c6f]
> [    0.250334] pnp 00:0b: [io  0x0cd0-0x0cd1]
> [    0.250338] pnp 00:0b: [io  0x0cd2-0x0cd3]
> [    0.250342] pnp 00:0b: [io  0x0cd4-0x0cd5]
> [    0.250346] pnp 00:0b: [io  0x0cd6-0x0cd7]
> [    0.250349] pnp 00:0b: [io  0x0cd8-0x0cdf]
> [    0.250353] pnp 00:0b: [io  0x0800-0x089f]
> [    0.250357] pnp 00:0b: [io  0x0000-0xffffffffffffffff disabled]
> [    0.250362] pnp 00:0b: [io  0x0b00-0x0b1f]
> [    0.250365] pnp 00:0b: [io  0x0b20-0x0b3f]
> [    0.250369] pnp 00:0b: [io  0x0900-0x090f]
> [    0.250373] pnp 00:0b: [io  0x0910-0x091f]
> [    0.250377] pnp 00:0b: [io  0xfe00-0xfefe]
> [    0.250380] pnp 00:0b: [io  0x0060]
> [    0.250384] pnp 00:0b: [io  0x0064]
> [    0.250388] pnp 00:0b: [mem 0x00000000-0xffffffffffffffff disabled]
> [    0.250393] pnp 00:0b: [mem 0xffb80000-0xffbfffff]
> [    0.250404] pnp 00:0b: [mem 0xfec10000-0xfec1001f]
> [    0.250408] pnp 00:0b: [mem 0xfed80000-0xfed80fff]
> [    0.250412] pnp 00:0b: [mem 0x00000000-0xffffffffffffffff disabled]
> [    0.250790] system 00:0b: [io  0x04d0-0x04d1] has been reserved
> [    0.250796] system 00:0b: [io  0x040b] has been reserved
> [    0.250801] system 00:0b: [io  0x04d6] has been reserved
> [    0.250806] system 00:0b: [io  0x0c00-0x0c01] has been reserved
> [    0.250811] system 00:0b: [io  0x0c14] has been reserved
> [    0.250816] system 00:0b: [io  0x0c50-0x0c51] has been reserved
> [    0.250821] system 00:0b: [io  0x0c52] has been reserved
> [    0.250826] system 00:0b: [io  0x0c6c] has been reserved
> [    0.250838] system 00:0b: [io  0x0c6f] has been reserved
> [    0.250843] system 00:0b: [io  0x0cd0-0x0cd1] has been reserved
> [    0.250848] system 00:0b: [io  0x0cd2-0x0cd3] has been reserved
> [    0.250853] system 00:0b: [io  0x0cd4-0x0cd5] has been reserved
> [    0.250859] system 00:0b: [io  0x0cd6-0x0cd7] has been reserved
> [    0.250864] system 00:0b: [io  0x0cd8-0x0cdf] has been reserved
> [    0.250869] system 00:0b: [io  0x0800-0x089f] has been reserved
> [    0.250874] system 00:0b: [io  0x0b00-0x0b1f] has been reserved
> [    0.250879] system 00:0b: [io  0x0b20-0x0b3f] has been reserved
> [    0.250885] system 00:0b: [io  0x0900-0x090f] has been reserved
> [    0.250890] system 00:0b: [io  0x0910-0x091f] has been reserved
> [    0.250895] system 00:0b: [io  0xfe00-0xfefe] has been reserved
> [    0.250901] system 00:0b: [mem 0xffb80000-0xffbfffff] has been reserved
> [    0.250907] system 00:0b: [mem 0xfec10000-0xfec1001f] has been reserved
> [    0.250912] system 00:0b: [mem 0xfed80000-0xfed80fff] has been reserved
> [    0.250927] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.251015] pnp 00:0c: [mem 0xe0000000-0xefffffff]
> [    0.251333] system 00:0c: [mem 0xe0000000-0xefffffff] has been reserved
> [    0.251342] system 00:0c: Plug and Play ACPI device, IDs PNP0c02 (active)
> [    0.251569] pnp 00:0d: [mem 0x00000000-0x0009ffff]
> [    0.251573] pnp 00:0d: [mem 0x000c0000-0x000cffff]
> [    0.251578] pnp 00:0d: [mem 0x000e0000-0x000fffff]
> [    0.251582] pnp 00:0d: [mem 0x00100000-0xafffffff]
> [    0.251586] pnp 00:0d: [mem 0xfec00000-0xffffffff]
> [    0.251927] system 00:0d: [mem 0x00000000-0x0009ffff] could not be reserved
> [    0.251934] system 00:0d: [mem 0x000c0000-0x000cffff] could not be reserved
> [    0.251939] system 00:0d: [mem 0x000e0000-0x000fffff] could not be reserved
> [    0.251945] system 00:0d: [mem 0x00100000-0xafffffff] could not be reserved
> [    0.251952] system 00:0d: [mem 0xfec00000-0xffffffff] could not be reserved
> [    0.251960] system 00:0d: Plug and Play ACPI device, IDs PNP0c01 (active)
> [    0.252199] pnp: PnP ACPI: found 14 devices
> [    0.252203] ACPI: ACPI bus type pnp unregistered
> [    0.254401] pciback 0000:0a:00.0: seizing device
> [    0.254487] pciback 0000:0a:00.1: seizing device
> [    0.254566] pciback 0000:0a:00.2: seizing device
> [    0.254639] pciback 0000:0a:00.3: seizing device
> [    0.254746] pciback 0000:0a:00.4: seizing device
> [    0.254825] pciback 0000:0a:00.5: seizing device
> [    0.254907] pciback 0000:0a:00.6: seizing device
> [    0.254982] pciback 0000:0a:00.7: seizing device
> [    0.255296] pciback 0000:07:01.0: seizing device
> [    0.255375] pciback 0000:07:01.1: seizing device
> [    0.255455] pciback 0000:07:01.2: seizing device
> [    0.255529] pciback 0000:05:00.0: seizing device
> [    0.255608] pciback 0000:05:00.1: seizing device
> [    0.255690] pciback 0000:04:00.0: seizing device
> [    0.255762] pciback 0000:04:00.1: seizing device
> [    0.255842] pciback 0000:04:00.2: seizing device
> [    0.255922] pciback 0000:04:00.3: seizing device
> [    0.256001] pciback 0000:04:00.4: seizing device
> [    0.256117] pciback 0000:04:00.5: seizing device
> [    0.256192] pciback 0000:04:00.6: seizing device
> [    0.256274] pciback 0000:04:00.7: seizing device
> [    0.256353] pciback 0000:03:06.0: seizing device
> [    0.266456] PM-Timer failed consistency check  (0x0xffffff) - aborting.
> [    0.266551] PCI: max bus depth: 2 pci_try_num: 3
> [    0.266657] pci 0000:00:02.0: PCI bridge to [bus 0b-0b]
> [    0.266664] pci 0000:00:02.0:   bridge window [io  0xe000-0xefff]
> [    0.266673] pci 0000:00:02.0:   bridge window [mem 0xfa000000-0xfe9fffff]
> [    0.266681] pci 0000:00:02.0:   bridge window [mem 0xd0000000-0xdfffffff 64bit pref]
> [    0.266700] pci 0000:00:03.0: PCI bridge to [bus 0a-0a]
> [    0.266708] pci 0000:00:03.0:   bridge window [mem 0xf9f00000-0xf9ffffff]
> [    0.266721] pci 0000:00:05.0: PCI bridge to [bus 09-09]
> [    0.266727] pci 0000:00:05.0:   bridge window [io  0xd000-0xdfff]
> [    0.266735] pci 0000:00:05.0:   bridge window [mem 0xf9e00000-0xf9efffff]
> [    0.266743] pci 0000:00:05.0:   bridge window [mem 0xcff00000-0xcfffffff 64bit pref]
> [    0.266754] pci 0000:00:06.0: PCI bridge to [bus 08-08]
> [    0.266760] pci 0000:00:06.0:   bridge window [io  0xc000-0xcfff]
> [    0.266769] pci 0000:00:06.0:   bridge window [mem 0xf9d00000-0xf9dfffff]
> [    0.266783] pci 0000:00:06.0:   bridge window [mem 0xcfe00000-0xcfefffff 64bit pref]
> [    0.266796] pciback 0000:07:01.0: BAR 0: assigned [mem 0xf9c00000-0xf9c00fff]
> [    0.266808] pciback 0000:07:01.1: BAR 0: assigned [mem 0xf9c01000-0xf9c01fff]
> [    0.266818] pciback 0000:07:01.2: BAR 0: assigned [mem 0xf9c02000-0xf9c02fff]
> [    0.266829] pci 0000:06:00.0: PCI bridge to [bus 07-07]
> [    0.266840] pci 0000:06:00.0:   bridge window [mem 0xf9c00000-0xf9cfffff]
> [    0.266858] pci 0000:00:0a.0: PCI bridge to [bus 06-07]
> [    0.266873] pci 0000:00:0a.0:   bridge window [mem 0xf9c00000-0xf9cfffff]
> [    0.266887] pci 0000:00:0b.0: PCI bridge to [bus 05-05]
> [    0.266892] pci 0000:00:0b.0:   bridge window [io  0xb000-0xbfff]
> [    0.266901] pci 0000:00:0b.0:   bridge window [mem 0xf9b00000-0xf9bfffff]
> [    0.266909] pci 0000:00:0b.0:   bridge window [mem 0xb0000000-0xbfffffff 64bit pref]
> [    0.266920] pci 0000:00:0d.0: PCI bridge to [bus 04-04]
> [    0.266929] pci 0000:00:0d.0:   bridge window [mem 0xf9a00000-0xf9afffff]
> [    0.266942] pci 0000:00:14.4: PCI bridge to [bus 03-03]
> [    0.266956] pci 0000:00:14.4:   bridge window [io  0xa000-0xafff]
> [    0.266976] pci 0000:00:15.0: PCI bridge to [bus 02-02]
> [    0.267004] xen: registering gsi 52 triggering 0 polarity 1
> [    0.267020] xen: --> pirq=52 -> irq=52 (gsi=52)
> [    0.267048] xen: registering gsi 52 triggering 0 polarity 1
> [    0.267076] xen_map_pirq_gsi: returning irq 52 for gsi 52
> [    0.267081] xen: --> pirq=52 -> irq=52 (gsi=52)
> [    0.267085] Already setup the GSI :52
> [    0.267095] xen: registering gsi 52 triggering 0 polarity 1
> [    0.267100] xen_map_pirq_gsi: returning irq 52 for gsi 52
> [    0.267105] xen: --> pirq=52 -> irq=52 (gsi=52)
> [    0.267109] Already setup the GSI :52
> [    0.267118] xen: registering gsi 53 triggering 0 polarity 1
> [    0.267164] xen: --> pirq=53 -> irq=53 (gsi=53)
> [    0.267181] xen: registering gsi 54 triggering 0 polarity 1
> [    0.267191] xen: --> pirq=54 -> irq=54 (gsi=54)
> [    0.267215] xen: registering gsi 54 triggering 0 polarity 1
> [    0.267220] xen_map_pirq_gsi: returning irq 54 for gsi 54
> [    0.267225] xen: --> pirq=54 -> irq=54 (gsi=54)
> [    0.267229] Already setup the GSI :54
> [    0.267239] xen: registering gsi 54 triggering 0 polarity 1
> [    0.267243] xen_map_pirq_gsi: returning irq 54 for gsi 54
> [    0.267248] xen: --> pirq=54 -> irq=54 (gsi=54)
> [    0.267252] Already setup the GSI :54
> [    0.267270] xen: registering gsi 16 triggering 0 polarity 1
> [    0.267280] xen: --> pirq=16 -> irq=16 (gsi=16)
> [    0.267302] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
> [    0.267307] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
> [    0.267311] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
> [    0.267316] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff]
> [    0.267321] pci_bus 0000:00: resource 8 [mem 0xb0000000-0xdfffffff]
> [    0.267326] pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfebfffff]
> [    0.267331] pci_bus 0000:0b: resource 0 [io  0xe000-0xefff]
> [    0.267335] pci_bus 0000:0b: resource 1 [mem 0xfa000000-0xfe9fffff]
> [    0.267340] pci_bus 0000:0b: resource 2 [mem 0xd0000000-0xdfffffff 64bit pref]
> [    0.267346] pci_bus 0000:0a: resource 1 [mem 0xf9f00000-0xf9ffffff]
> [    0.267351] pci_bus 0000:09: resource 0 [io  0xd000-0xdfff]
> [    0.267355] pci_bus 0000:09: resource 1 [mem 0xf9e00000-0xf9efffff]
> [    0.267360] pci_bus 0000:09: resource 2 [mem 0xcff00000-0xcfffffff 64bit pref]
> [    0.267366] pci_bus 0000:08: resource 0 [io  0xc000-0xcfff]
> [    0.267370] pci_bus 0000:08: resource 1 [mem 0xf9d00000-0xf9dfffff]
> [    0.267375] pci_bus 0000:08: resource 2 [mem 0xcfe00000-0xcfefffff 64bit pref]
> [    0.267388] pci_bus 0000:06: resource 1 [mem 0xf9c00000-0xf9cfffff]
> [    0.267393] pci_bus 0000:07: resource 1 [mem 0xf9c00000-0xf9cfffff]
> [    0.267398] pci_bus 0000:05: resource 0 [io  0xb000-0xbfff]
> [    0.267402] pci_bus 0000:05: resource 1 [mem 0xf9b00000-0xf9bfffff]
> [    0.267407] pci_bus 0000:05: resource 2 [mem 0xb0000000-0xbfffffff 64bit pref]
> [    0.267413] pci_bus 0000:04: resource 1 [mem 0xf9a00000-0xf9afffff]
> [    0.267418] pci_bus 0000:03: resource 0 [io  0xa000-0xafff]
> [    0.267422] pci_bus 0000:03: resource 4 [io  0x0000-0x0cf7]
> [    0.267427] pci_bus 0000:03: resource 5 [io  0x0d00-0xffff]
> [    0.267431] pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000bffff]
> [    0.267436] pci_bus 0000:03: resource 7 [mem 0x000d0000-0x000dffff]
> [    0.267441] pci_bus 0000:03: resource 8 [mem 0xb0000000-0xdfffffff]
> [    0.267446] pci_bus 0000:03: resource 9 [mem 0xf0000000-0xfebfffff]
> [    0.267504] NET: Registered protocol family 2
> [    0.267823] IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
> [    0.268951] TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
> [    0.270481] TCP bind hash table entries: 65536 (order: 10, 4194304 bytes)
> [    0.278788] TCP: Hash tables configured (established 131072 bind 65536)
> [    0.278811] TCP reno registered
> [    0.278846] UDP hash table entries: 512 (order: 4, 81920 bytes)
> [    0.278995] UDP-Lite hash table entries: 512 (order: 4, 81920 bytes)
> [    0.279304] NET: Registered protocol family 1
> [    0.279601] RPC: Registered named UNIX socket transport module.
> [    0.279641] RPC: Registered udp transport module.
> [    0.279645] RPC: Registered tcp transport module.
> [    0.279649] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.568176] pci 0000:0b:00.0: Boot video device
> [    0.568355] pci 0000:06:00.0: TI XIO2000a quirk detected; secondary bus fast back-to-back transfers disabled
> [    0.568573] PCI: CLS 64 bytes, default 64
> [    0.568704] Trying to unpack rootfs image as initramfs...
> [    0.582105] Freeing initrd memory: 6724k freed
> [    0.587967] DMA-API: preallocated 32768 debug entries
> [    0.587978] DMA-API: debugging enabled by kernel config
> [    0.590485] microcode: CPU0: patch_level=0x010000bf
> [    0.590512] microcode: CPU1: patch_level=0x010000bf
> [    0.590555] microcode: CPU2: patch_level=0x010000bf
> [    0.590632] microcode: CPU3: patch_level=0x010000bf
> [    0.590724] microcode: CPU4: patch_level=0x010000bf
> [    0.590799] microcode: CPU5: patch_level=0x010000bf
> [    0.590952] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [    0.591823] Intel AES-NI instructions are not detected.
> [    0.592331] audit: initializing netlink socket (disabled)
> [    0.592371] type=2000 audit(1326371114.069:1): initialized
> [    0.613325] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    0.623529] VFS: Disk quotas dquot_6.5.2
> [    0.623768] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    0.626441] NTFS driver 2.1.30 [Flags: R/W].
> [    0.626815] fuse init (API version 7.17)
> [    0.628471] Btrfs loaded
> [    0.628483] msgmni has been set to 1829
> [    0.628851] SELinux:  Registering netfilter hooks
> [    0.630559] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> [    0.630575] io scheduler noop registered
> [    0.630579] io scheduler deadline registered
> [    0.630709] io scheduler cfq registered (default)
> [    0.630715] start plist test
> [    0.631700] end plist test
> [    0.631704] list_sort_test: start testing list_sort()
> [    0.635935] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [    0.636239] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
> [    0.636541] usbcore: registered new interface driver udlfb
> [    0.636651] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
> [    0.636657] vesafb: scrolling: redraw
> [    0.636661] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> [    0.639640] vesafb: framebuffer at 0xfb000000, mapped to 0xffffc90010880000, using 10240k, total 14336k
> [    0.661272] Console: switching to colour frame buffer device 160x64
> [    0.681729] fb0: VESA VGA frame buffer device
> [    0.682268] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
> [    0.682480] ACPI: Power Button [PWRB]
> [    0.682756] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
> [    0.682939] ACPI: Power Button [PWRF]
> [    0.687848] Event-channel device installed.
> [    0.688305] xen: registering gsi 22 triggering 0 polarity 1
> [    0.688462] xen: --> pirq=22 -> irq=22 (gsi=22)
> [    0.688652] xen: registering gsi 43 triggering 0 polarity 1
> [    0.688806] xen: --> pirq=43 -> irq=43 (gsi=43)
> [    0.688982] xen: registering gsi 43 triggering 0 polarity 1
> [    0.689139] xen_map_pirq_gsi: returning irq 43 for gsi 43
> [    0.689276] xen: --> pirq=43 -> irq=43 (gsi=43)
> [    0.689398] Already setup the GSI :43
> [    0.689540] xen: registering gsi 42 triggering 0 polarity 1
> [    0.689716] xen: --> pirq=42 -> irq=42 (gsi=42)
> [    0.689893] xen: registering gsi 42 triggering 0 polarity 1
> [    0.690041] xen_map_pirq_gsi: returning irq 42 for gsi 42
> [    0.690134] xen: --> pirq=42 -> irq=42 (gsi=42)
> [    0.690308] Already setup the GSI :42
> [    0.690457] xen: registering gsi 41 triggering 0 polarity 1
> [    0.690610] xen: --> pirq=41 -> irq=41 (gsi=41)
> [    0.690785] xen: registering gsi 41 triggering 0 polarity 1
> [    0.690927] xen_map_pirq_gsi: returning irq 41 for gsi 41
> [    0.691098] xen: --> pirq=41 -> irq=41 (gsi=41)
> [    0.691218] Already setup the GSI :41
> [    0.691361] xen: registering gsi 40 triggering 0 polarity 1
> [    0.691516] xen: --> pirq=40 -> irq=40 (gsi=40)
> [    0.691691] xen: registering gsi 40 triggering 0 polarity 1
> [    0.691839] xen_map_pirq_gsi: returning irq 40 for gsi 40
> [    0.691983] xen: --> pirq=40 -> irq=40 (gsi=40)
> [    0.692103] Already setup the GSI :40
> [    0.692247] xen: registering gsi 33 triggering 0 polarity 1
> [    0.692395] xen: --> pirq=33 -> irq=33 (gsi=33)
> [    0.698730] pciback 0000:05:00.0: enabling device (0000 -> 0003)
> [    0.699683] xen: registering gsi 32 triggering 0 polarity 1
> [    0.711332] xen: --> pirq=32 -> irq=32 (gsi=32)
> [    0.717614] pciback 0000:07:01.2: enabling device (0114 -> 0116)
> [    0.718576] xen: registering gsi 46 triggering 0 polarity 1
> [    0.730341] xen: --> pirq=46 -> irq=46 (gsi=46)
> [    0.736752] pciback 0000:07:01.1: enabling device (0114 -> 0116)
> [    0.737711] xen: registering gsi 45 triggering 0 polarity 1
> [    0.749678] xen: --> pirq=45 -> irq=45 (gsi=45)
> [    0.756061] pciback 0000:07:01.0: enabling device (0114 -> 0116)
> [    0.757003] xen: registering gsi 44 triggering 0 polarity 1
> [    0.769033] xen: --> pirq=44 -> irq=44 (gsi=44)
> [    0.775579] xen: registering gsi 31 triggering 0 polarity 1
> [    0.782167] xen: --> pirq=31 -> irq=31 (gsi=31)
> [    0.788821] xen: registering gsi 31 triggering 0 polarity 1
> [    0.795438] xen_map_pirq_gsi: returning irq 31 for gsi 31
> [    0.796434] xen: --> pirq=31 -> irq=31 (gsi=31)
> [    0.808579] Already setup the GSI :31
> [    0.815143] xen: registering gsi 30 triggering 0 polarity 1
> [    0.821685] xen: --> pirq=30 -> irq=30 (gsi=30)
> [    0.828206] xen: registering gsi 30 triggering 0 polarity 1
> [    0.834740] xen_map_pirq_gsi: returning irq 30 for gsi 30
> [    0.841088] xen: --> pirq=30 -> irq=30 (gsi=30)
> [    0.841258] Already setup the GSI :30
> [    0.841323] xen: registering gsi 29 triggering 0 polarity 1
> [    0.841332] xen: --> pirq=29 -> irq=29 (gsi=29)
> [    0.841423] xen: registering gsi 29 triggering 0 polarity 1
> [    0.841425] xen_map_pirq_gsi: returning irq 29 for gsi 29
> [    0.841426] xen: --> pirq=29 -> irq=29 (gsi=29)
> [    0.841427] Already setup the GSI :29
> [    0.841504] xen: registering gsi 28 triggering 0 polarity 1
> [    0.841512] xen: --> pirq=28 -> irq=28 (gsi=28)
> [    0.841597] xen: registering gsi 28 triggering 0 polarity 1
> [    0.841599] xen_map_pirq_gsi: returning irq 28 for gsi 28
> [    0.841600] xen: --> pirq=28 -> irq=28 (gsi=28)
> [    0.841602] Already setup the GSI :28
> [    0.841796] xen-pciback: backend is passthrough
> [    0.843175] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    0.968633] hpet_acpi_add: no address or irqs in _CRS
> [    0.974946] Non-volatile memory driver v1.3
> [    0.975933] Linux agpgart interface v0.103
> [    0.989830] [drm] Initialized drm 1.1.0 20060810
> [    0.990807] [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module!
> [    1.002136] i2c-core: driver [ch7006] using legacy suspend method
> [    1.003131] i2c-core: driver [ch7006] using legacy resume method
> [    1.019267] brd: module loaded
> [    1.041714] loop: module loaded
> [    1.049261] ahci 0000:00:11.0: version 3.0
> [    1.050245] xen: registering gsi 19 triggering 0 polarity 1
> [    1.061428] xen: --> pirq=19 -> irq=19 (gsi=19)
> [    1.067690] ahci 0000:00:11.0: AHCI 0001.0200 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
> [    1.073913] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
> [    1.083160] scsi0 : ahci
> [    1.089730] scsi1 : ahci
> [    1.096185] scsi2 : ahci
> [    1.102635] scsi3 : ahci
> [    1.108913] scsi4 : ahci
> [    1.115086] scsi5 : ahci
> [    1.121331] ata1: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff100 irq 342
> [    1.122275] ata2: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff180 irq 342
> [    1.122275] ata3: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff200 irq 342
> [    1.122275] ata4: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff280 irq 342
> [    1.122275] ata5: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff300 irq 342
> [    1.122275] ata6: SATA max UDMA/133 abar m1024@0xf98ff000 port 0xf98ff380 irq 342
> [    1.156239] tun: Universal TUN/TAP device driver, 1.6
> [    1.157234] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [    1.167296] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
> [    1.168288] e1000: Copyright (c) 1999-2006 Intel Corporation.
> [    1.178258] sky2: driver version 1.30
> [    1.184032] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    1.185019] xen: registering gsi 46 triggering 0 polarity 1
> [    1.194899] xen_map_pirq_gsi: returning irq 46 for gsi 46
> [    1.195889] xen: --> pirq=46 -> irq=46 (gsi=46)
> [    1.205721] Already setup the GSI :46
> [    1.212142] r8169 0000:09:00.0: eth0: RTL8168d/8111d at 0xffffc900001f8000, 40:61:86:f4:67:d9, XID 081000c0 IRQ 343
> [    1.213061] r8169 0000:09:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
> [    1.223683] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    1.229362] xen: registering gsi 51 triggering 0 polarity 1
> [    1.235058] xen: --> pirq=51 -> irq=51 (gsi=51)
> [    1.241802] r8169 0000:08:00.0: eth1: RTL8168d/8111d at 0xffffc900001fa000, 40:61:86:f4:67:d8, XID 081000c0 IRQ 344
> [    1.242278] r8169 0000:08:00.0: eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko]
> [    1.255129] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    1.256099] ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96
> [    1.267332] xen: registering gsi 17 triggering 0 polarity 1
> [    1.273357] xen: --> pirq=17 -> irq=17 (gsi=17)
> [    1.279398] ehci_hcd 0000:00:12.2: EHCI Host Controller
> [    1.285489] drivers/usb/core/inode.c: creating file 'devices'
> [    1.286464] drivers/usb/core/inode.c: creating file '001'
> [    1.297803] ehci_hcd 0000:00:12.2: new USB bus registered, assigned bus number 1
> [    1.298786] ehci_hcd 0000:00:12.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
> [    1.298786] ehci_hcd 0000:00:12.2: reset hcc_params a072 thresh 7 uframes 256/512/1024
> [    1.316312] ehci_hcd 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    1.322751] QUIRK: Enable AMD PLL fix
> [    1.323658] ehci_hcd 0000:00:12.2: debug port 1
> [    1.323658] ehci_hcd 0000:00:12.2: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
> [    1.323658] ehci_hcd 0000:00:12.2: MWI active
> [    1.323658] ehci_hcd 0000:00:12.2: supports USB remote wakeup
> [    1.354124] ehci_hcd 0000:00:12.2: irq 17, io mem 0xf98ff400
> [    1.355084] ehci_hcd 0000:00:12.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    1.373082] ehci_hcd 0000:00:12.2: USB 2.0 started, EHCI 1.00
> [    1.379498] usb usb1: default language 0x0409
> [    1.385764] usb usb1: udev 1, busnum 1, minor = 0
> [    1.386714] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.386714] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.386714] usb usb1: Product: EHCI Host Controller
> [    1.386714] usb usb1: Manufacturer: Linux 3.2.0-rc0+ ehci_hcd
> [    1.386714] usb usb1: SerialNumber: 0000:00:12.2
> [    1.423538] usb usb1: usb_probe_device
> [    1.424524] usb usb1: configuration #1 chosen from 1 choice
> [    1.435957] usb usb1: adding 1-0:1.0 (config #1, interface 0)
> [    1.442260] hub 1-0:1.0: usb_probe_interface
> [    1.443216] hub 1-0:1.0: usb_probe_interface - got id
> [    1.443216] hub 1-0:1.0: USB hub found
> [    1.460190] ata2: SATA link down (SStatus 0 SControl 300)
> [    1.460255] ata4: SATA link down (SStatus 0 SControl 300)
> [    1.460324] ata5: SATA link down (SStatus 0 SControl 300)
> [    1.460368] ata6: SATA link down (SStatus 0 SControl 300)
> [    1.485187] hub 1-0:1.0: 5 ports detected
> [    1.486169] hub 1-0:1.0: standalone hub
> [    1.486169] hub 1-0:1.0: no power switching (usb 1.0)
> [    1.486169] hub 1-0:1.0: individual port over-current protection
> [    1.486169] hub 1-0:1.0: power on to power good time: 20ms
> [    1.516387] hub 1-0:1.0: local power source is good
> [    1.517362] hub 1-0:1.0: trying to enable port power on non-switchable hub
> [    1.529111] drivers/usb/core/inode.c: creating file '001'
> [    1.535704] xen: registering gsi 17 triggering 0 polarity 1
> [    1.541968] xen_map_pirq_gsi: returning irq 17 for gsi 17
> [    1.542960] xen: --> pirq=17 -> irq=17 (gsi=17)
> [    1.554529] Already setup the GSI :17
> [    1.560740] ehci_hcd 0000:00:13.2: EHCI Host Controller
> [    1.567004] drivers/usb/core/inode.c: creating file '002'
> [    1.573460] ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 2
> [    1.574437] ehci_hcd 0000:00:13.2: reset hcs_params 0x101505 dbg=1 cc=1 pcc=5 ordered !ppc ports=5
> [    1.586197] ehci_hcd 0000:00:13.2: reset hcc_params a072 thresh 7 uframes 256/512/1024
> [    1.587186] ehci_hcd 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    1.587186] ehci_hcd 0000:00:13.2: debug port 1
> [    1.587186] ehci_hcd 0000:00:13.2: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
> [    1.611261] ehci_hcd 0000:00:13.2: MWI active
> [    1.615122] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [    1.615168] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [    1.612232] ehci_hcd 0000:00:13.2: supports USB remote wakeup
> [    1.635307] ehci_hcd 0000:00:13.2: irq 17, io mem 0xf98ff800
> [    1.640113] ehci_hcd 0000:00:13.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    1.641216] ata3.00: ATA-8: ST2000DL003-9VT166, CC45, max UDMA/133
> [    1.641219] ata3.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> [    1.641275] hub 1-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    1.641402] ata1.00: ATA-8: Hitachi HDS722020ALA330, JKAOA20N, max UDMA/133
> [    1.641404] ata1.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
> [    1.642032] ata3.00: configured for UDMA/133
> [    1.642932] ata1.00: configured for UDMA/133
> [    1.643199] scsi 0:0:0:0: Direct-Access     ATA      Hitachi HDS72202 JKAO PQ: 0 ANSI: 5
> [    1.643742] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
> [    1.643854] sd 0:0:0:0: [sda] Write Protect is off
> [    1.643859] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [    1.643932] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [    1.648079] ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00
> [    1.648158] usb usb2: default language 0x0409
> [    1.648170] usb usb2: udev 1, busnum 2, minor = 128
> [    1.648171] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.648173] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.648174] usb usb2: Product: EHCI Host Controller
> [    1.648176] usb usb2: Manufacturer: Linux 3.2.0-rc0+ ehci_hcd
> [    1.648177] usb usb2: SerialNumber: 0000:00:13.2
> [    1.757176] usb usb2: usb_probe_device
> [    1.757258] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [    1.757593] scsi 2:0:0:0: Direct-Access     ATA      ST2000DL003-9VT1 CC45 PQ: 0 ANSI: 5
> [    1.758098] sd 2:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB)
> [    1.758100] sd 2:0:0:0: [sdb] 4096-byte physical blocks
> [    1.758215] sd 2:0:0:0: [sdb] Write Protect is off
> [    1.758217] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> [    1.758263] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> [    1.759160] sd 2:0:0:0: Attached scsi generic sg1 type 0
> [    1.758596] usb usb2: configuration #1 chosen from 1 choice
> [    1.819655] usb usb2: adding 2-0:1.0 (config #1, interface 0)
> [    1.819717]  sdb: sdb1
> [    1.819735]  sda: sda1 sda2 sda3
> [    1.839865] hub 2-0:1.0: usb_probe_interface
> [    1.840527] sd 2:0:0:0: [sdb] Attached SCSI disk
> [    1.840620] sd 0:0:0:0: [sda] Attached SCSI disk
> [    1.859118] hub 2-0:1.0: usb_probe_interface - got id
> [    1.859118] hub 2-0:1.0: USB hub found
> [    1.859527] hub 2-0:1.0: 5 ports detected
> [    1.859529] hub 2-0:1.0: standalone hub
> [    1.859530] hub 2-0:1.0: no power switching (usb 1.0)
> [    1.859532] hub 2-0:1.0: individual port over-current protection
> [    1.859533] hub 2-0:1.0: power on to power good time: 20ms
> [    1.859543] hub 2-0:1.0: local power source is good
> [    1.859545] hub 2-0:1.0: trying to enable port power on non-switchable hub
> [    1.859620] drivers/usb/core/inode.c: creating file '001'
> [    1.859930] xen: registering gsi 17 triggering 0 polarity 1
> [    1.859935] xen_map_pirq_gsi: returning irq 17 for gsi 17
> [    1.859937] xen: --> pirq=17 -> irq=17 (gsi=17)
> [    1.859939] Already setup the GSI :17
> [    1.860013] ehci_hcd 0000:00:16.2: EHCI Host Controller
> [    1.860025] drivers/usb/core/inode.c: creating file '003'
> [    1.860433] ehci_hcd 0000:00:16.2: new USB bus registered, assigned bus number 3
> [    1.860441] ehci_hcd 0000:00:16.2: reset hcs_params 0x101404 dbg=1 cc=1 pcc=4 ordered !ppc ports=4
> [    1.860444] ehci_hcd 0000:00:16.2: reset hcc_params a072 thresh 7 uframes 256/512/1024
> [    1.860449] ehci_hcd 0000:00:16.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
> [    1.860537] ehci_hcd 0000:00:16.2: debug port 1
> [    1.860542] ehci_hcd 0000:00:16.2: reset command 0080002 (park)=0 ithresh=8 period=1024 Reset HALT
> [    1.860565] ehci_hcd 0000:00:16.2: MWI active
> [    1.860566] ehci_hcd 0000:00:16.2: supports USB remote wakeup
> [    1.860575] ehci_hcd 0000:00:16.2: irq 17, io mem 0xf98ffc00
> [    1.860579] ehci_hcd 0000:00:16.2: init command 0010005 (park)=0 ithresh=1 period=512 RUN
> [    1.867096] ehci_hcd 0000:00:16.2: USB 2.0 started, EHCI 1.00
> [    1.867169] usb usb3: default language 0x0409
> [    1.867182] usb usb3: udev 1, busnum 3, minor = 256
> [    1.867184] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.867185] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.867187] usb usb3: Product: EHCI Host Controller
> [    1.867189] usb usb3: Manufacturer: Linux 3.2.0-rc0+ ehci_hcd
> [    1.867190] usb usb3: SerialNumber: 0000:00:16.2
> [    1.867391] usb usb3: usb_probe_device
> [    1.867393] usb usb3: configuration #1 chosen from 1 choice
> [    1.867413] usb usb3: adding 3-0:1.0 (config #1, interface 0)
> [    1.867535] hub 3-0:1.0: usb_probe_interface
> [    1.867537] hub 3-0:1.0: usb_probe_interface - got id
> [    1.867538] hub 3-0:1.0: USB hub found
> [    1.867545] hub 3-0:1.0: 4 ports detected
> [    1.867546] hub 3-0:1.0: standalone hub
> [    1.867547] hub 3-0:1.0: no power switching (usb 1.0)
> [    1.867549] hub 3-0:1.0: individual port over-current protection
> [    1.867550] hub 3-0:1.0: power on to power good time: 20ms
> [    1.867559] hub 3-0:1.0: local power source is good
> [    1.867561] hub 3-0:1.0: trying to enable port power on non-switchable hub
> [    1.867618] drivers/usb/core/inode.c: creating file '001'
> [    1.868048] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    1.868051] ohci_hcd: block sizes: ed 80 td 96
> [    1.868168] xen: registering gsi 18 triggering 0 polarity 1
> [    1.868192] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    1.868228] ohci_hcd 0000:00:12.0: OHCI Host Controller
> [    1.868244] drivers/usb/core/inode.c: creating file '004'
> [    1.868657] ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 4
> [    1.868672] ohci_hcd 0000:00:12.0: enabled AMD prefetch quirk
> [    1.868741] ohci_hcd 0000:00:12.0: created debug files
> [    1.868743] ohci_hcd 0000:00:12.0: supports USB remote wakeup
> [    1.868802] ohci_hcd 0000:00:12.0: irq 18, io mem 0xf98fb000
> [    1.924206] ohci_hcd 0000:00:12.0: OHCI controller state
> [    1.924213] ohci_hcd 0000:00:12.0: OHCI 1.0, NO legacy support registers, rh state running
> [    1.924217] ohci_hcd 0000:00:12.0: control 0x283 RWC HCFS=operational CBSR=3
> [    1.924220] ohci_hcd 0000:00:12.0: cmdstatus 0x00000 SOC=0
> [    1.924224] ohci_hcd 0000:00:12.0: intrstatus 0x00000004 SF
> [    1.924227] ohci_hcd 0000:00:12.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    1.924237] ohci_hcd 0000:00:12.0: hcca frame #0005
> [    1.924241] ohci_hcd 0000:00:12.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
> [    1.924257] ohci_hcd 0000:00:12.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    1.924260] ohci_hcd 0000:00:12.0: roothub.status 00008000 DRWE
> [    1.924264] ohci_hcd 0000:00:12.0: roothub.portstatus [0] 0x00000100 PPS
> [    1.924267] ohci_hcd 0000:00:12.0: roothub.portstatus [1] 0x00000100 PPS
> [    1.924271] ohci_hcd 0000:00:12.0: roothub.portstatus [2] 0x00000100 PPS
> [    1.924274] ohci_hcd 0000:00:12.0: roothub.portstatus [3] 0x00000100 PPS
> [    1.924278] ohci_hcd 0000:00:12.0: roothub.portstatus [4] 0x00000100 PPS
> [    1.924300] usb usb4: default language 0x0409
> [    1.924312] usb usb4: udev 1, busnum 4, minor = 384
> [    1.924314] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
> [    1.924316] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.924317] usb usb4: Product: OHCI Host Controller
> [    1.924319] usb usb4: Manufacturer: Linux 3.2.0-rc0+ ohci_hcd
> [    1.924320] usb usb4: SerialNumber: 0000:00:12.0
> [    1.924796] usb usb4: usb_probe_device
> [    1.924798] usb usb4: configuration #1 chosen from 1 choice
> [    1.924810] usb usb4: adding 4-0:1.0 (config #1, interface 0)
> [    1.924931] hub 4-0:1.0: usb_probe_interface
> [    1.924933] hub 4-0:1.0: usb_probe_interface - got id
> [    1.924935] hub 4-0:1.0: USB hub found
> [    1.924954] hub 4-0:1.0: 5 ports detected
> [    1.924955] hub 4-0:1.0: standalone hub
> [    1.924956] hub 4-0:1.0: no power switching (usb 1.0)
> [    1.924957] hub 4-0:1.0: no over-current protection
> [    1.924959] hub 4-0:1.0: power on to power good time: 4ms
> [    1.924969] hub 4-0:1.0: local power source is good
> [    1.924970] hub 4-0:1.0: trying to enable port power on non-switchable hub
> [    1.925009] drivers/usb/core/inode.c: creating file '001'
> [    1.925093] ehci_hcd 0000:00:12.2: HS companion for 0000:00:12.0
> [    1.925398] xen: registering gsi 18 triggering 0 polarity 1
> [    1.925402] xen_map_pirq_gsi: returning irq 18 for gsi 18
> [    1.925404] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    1.925406] Already setup the GSI :18
> [    1.925425] ohci_hcd 0000:00:13.0: OHCI Host Controller
> [    1.925437] drivers/usb/core/inode.c: creating file '005'
> [    1.925693] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5
> [    1.925705] ohci_hcd 0000:00:13.0: enabled AMD prefetch quirk
> [    1.925769] ohci_hcd 0000:00:13.0: created debug files
> [    1.925771] ohci_hcd 0000:00:13.0: supports USB remote wakeup
> [    1.925778] ohci_hcd 0000:00:13.0: irq 18, io mem 0xf98fc000
> [    1.960158] hub 2-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    1.968219] hub 3-0:1.0: state 7 ports 4 chg 0000 evt 0000
> [    1.981168] ohci_hcd 0000:00:13.0: OHCI controller state
> [    1.981173] ohci_hcd 0000:00:13.0: OHCI 1.0, NO legacy support registers, rh state running
> [    1.981177] ohci_hcd 0000:00:13.0: control 0x283 RWC HCFS=operational CBSR=3
> [    1.981180] ohci_hcd 0000:00:13.0: cmdstatus 0x00000 SOC=0
> [    1.981193] ohci_hcd 0000:00:13.0: intrstatus 0x00000004 SF
> [    1.981196] ohci_hcd 0000:00:13.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    1.981207] ohci_hcd 0000:00:13.0: hcca frame #0005
> [    1.981211] ohci_hcd 0000:00:13.0: roothub.a 02001205 POTPGT=2 NOCP NPS NDP=5(5)
> [    1.981214] ohci_hcd 0000:00:13.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    1.981217] ohci_hcd 0000:00:13.0: roothub.status 00008000 DRWE
> [    1.981221] ohci_hcd 0000:00:13.0: roothub.portstatus [0] 0x00000100 PPS
> [    1.981224] ohci_hcd 0000:00:13.0: roothub.portstatus [1] 0x00000100 PPS
> [    1.981227] ohci_hcd 0000:00:13.0: roothub.portstatus [2] 0x00000100 PPS
> [    1.981231] ohci_hcd 0000:00:13.0: roothub.portstatus [3] 0x00000100 PPS
> [    1.981234] ohci_hcd 0000:00:13.0: roothub.portstatus [4] 0x00000100 PPS
> [    1.981256] usb usb5: default language 0x0409
> [    1.981279] usb usb5: udev 1, busnum 5, minor = 512
> [    1.981281] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
> [    1.981282] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.981284] usb usb5: Product: OHCI Host Controller
> [    1.981285] usb usb5: Manufacturer: Linux 3.2.0-rc0+ ohci_hcd
> [    1.981287] usb usb5: SerialNumber: 0000:00:13.0
> [    1.981629] usb usb5: usb_probe_device
> [    1.981631] usb usb5: configuration #1 chosen from 1 choice
> [    1.981641] usb usb5: adding 5-0:1.0 (config #1, interface 0)
> [    1.981786] hub 5-0:1.0: usb_probe_interface
> [    1.981788] hub 5-0:1.0: usb_probe_interface - got id
> [    1.981799] hub 5-0:1.0: USB hub found
> [    1.981808] hub 5-0:1.0: 5 ports detected
> [    1.981809] hub 5-0:1.0: standalone hub
> [    1.981810] hub 5-0:1.0: no power switching (usb 1.0)
> [    1.981812] hub 5-0:1.0: no over-current protection
> [    1.981813] hub 5-0:1.0: power on to power good time: 4ms
> [    1.981823] hub 5-0:1.0: local power source is good
> [    1.981825] hub 5-0:1.0: trying to enable port power on non-switchable hub
> [    1.981866] drivers/usb/core/inode.c: creating file '001'
> [    1.981933] ehci_hcd 0000:00:13.2: HS companion for 0000:00:13.0
> [    1.982295] xen: registering gsi 18 triggering 0 polarity 1
> [    1.982299] xen_map_pirq_gsi: returning irq 18 for gsi 18
> [    1.982301] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    1.982302] Already setup the GSI :18
> [    1.982329] ohci_hcd 0000:00:14.5: OHCI Host Controller
> [    1.982338] drivers/usb/core/inode.c: creating file '006'
> [    1.982767] ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 6
> [    1.982779] ohci_hcd 0000:00:14.5: enabled AMD prefetch quirk
> [    1.982852] ohci_hcd 0000:00:14.5: created debug files
> [    1.982854] ohci_hcd 0000:00:14.5: supports USB remote wakeup
> [    1.982861] ohci_hcd 0000:00:14.5: irq 18, io mem 0xf98fd000
> [    2.025152] hub 4-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    2.038185] ohci_hcd 0000:00:14.5: OHCI controller state
> [    2.038189] ohci_hcd 0000:00:14.5: OHCI 1.0, NO legacy support registers, rh state running
> [    2.038193] ohci_hcd 0000:00:14.5: control 0x283 RWC HCFS=operational CBSR=3
> [    2.038196] ohci_hcd 0000:00:14.5: cmdstatus 0x00000 SOC=0
> [    2.038200] ohci_hcd 0000:00:14.5: intrstatus 0x00000004 SF
> [    2.038203] ohci_hcd 0000:00:14.5: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    2.038223] ohci_hcd 0000:00:14.5: hcca frame #0005
> [    2.038227] ohci_hcd 0000:00:14.5: roothub.a 02001202 POTPGT=2 NOCP NPS NDP=2(2)
> [    2.038230] ohci_hcd 0000:00:14.5: roothub.b 00000000 PPCM=0000 DR=0000
> [    2.038233] ohci_hcd 0000:00:14.5: roothub.status 00008000 DRWE
> [    2.038237] ohci_hcd 0000:00:14.5: roothub.portstatus [0] 0x00000100 PPS
> [    2.038240] ohci_hcd 0000:00:14.5: roothub.portstatus [1] 0x00000100 PPS
> [    2.038264] usb usb6: default language 0x0409
> [    2.038280] usb usb6: udev 1, busnum 6, minor = 640
> [    2.038282] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
> [    2.038283] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    2.038285] usb usb6: Product: OHCI Host Controller
> [    2.038286] usb usb6: Manufacturer: Linux 3.2.0-rc0+ ohci_hcd
> [    2.038288] usb usb6: SerialNumber: 0000:00:14.5
> [    2.038616] usb usb6: usb_probe_device
> [    2.038618] usb usb6: configuration #1 chosen from 1 choice
> [    2.038627] usb usb6: adding 6-0:1.0 (config #1, interface 0)
> [    2.038781] hub 6-0:1.0: usb_probe_interface
> [    2.038783] hub 6-0:1.0: usb_probe_interface - got id
> [    2.038784] hub 6-0:1.0: USB hub found
> [    2.038793] hub 6-0:1.0: 2 ports detected
> [    2.038795] hub 6-0:1.0: standalone hub
> [    2.038796] hub 6-0:1.0: no power switching (usb 1.0)
> [    2.038797] hub 6-0:1.0: no over-current protection
> [    2.038799] hub 6-0:1.0: power on to power good time: 4ms
> [    2.038809] hub 6-0:1.0: local power source is good
> [    2.038810] hub 6-0:1.0: trying to enable port power on non-switchable hub
> [    2.038888] drivers/usb/core/inode.c: creating file '001'
> [    2.039293] xen: registering gsi 18 triggering 0 polarity 1
> [    2.039297] xen_map_pirq_gsi: returning irq 18 for gsi 18
> [    2.039298] xen: --> pirq=18 -> irq=18 (gsi=18)
> [    2.039300] Already setup the GSI :18
> [    2.039318] ohci_hcd 0000:00:16.0: OHCI Host Controller
> [    2.039327] drivers/usb/core/inode.c: creating file '007'
> [    2.039554] ohci_hcd 0000:00:16.0: new USB bus registered, assigned bus number 7
> [    2.039566] ohci_hcd 0000:00:16.0: enabled AMD prefetch quirk
> [    2.039638] ohci_hcd 0000:00:16.0: created debug files
> [    2.039639] ohci_hcd 0000:00:16.0: supports USB remote wakeup
> [    2.039647] ohci_hcd 0000:00:16.0: irq 18, io mem 0xf98fe000
> [    2.082144] hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0000
> [    2.095207] ohci_hcd 0000:00:16.0: OHCI controller state
> [    2.095214] ohci_hcd 0000:00:16.0: OHCI 1.0, NO legacy support registers, rh state running
> [    2.095218] ohci_hcd 0000:00:16.0: control 0x283 RWC HCFS=operational CBSR=3
> [    2.095221] ohci_hcd 0000:00:16.0: cmdstatus 0x00000 SOC=0
> [    2.095224] ohci_hcd 0000:00:16.0: intrstatus 0x00000004 SF
> [    2.095228] ohci_hcd 0000:00:16.0: intrenable 0x8000005a MIE RHSC UE RD WDH
> [    2.095250] ohci_hcd 0000:00:16.0: hcca frame #0005
> [    2.095253] ohci_hcd 0000:00:16.0: roothub.a 02001204 POTPGT=2 NOCP NPS NDP=4(4)
> [    2.095256] ohci_hcd 0000:00:16.0: roothub.b 00000000 PPCM=0000 DR=0000
> [    2.095260] ohci_hcd 0000:00:16.0: roothub.status 00008000 DRWE
> [    2.095263] ohci_hcd 0000:00:16.0: roothub.portstatus [0] 0x00000100 PPS
> [    2.095267] ohci_hcd 0000:00:16.0: roothub.portstatus [1] 0x00000100 PPS
> [    2.095270] ohci_hcd 0000:00:16.0: roothub.portstatus [2] 0x00000100 PPS
> [    2.095273] ohci_hcd 0000:00:16.0: roothub.portstatus [3] 0x00000100 PPS
> [    2.095292] usb usb7: default language 0x0409
> [    2.095305] usb usb7: udev 1, busnum 7, minor = 768
> [    2.095307] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
> [    2.095308] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    2.095310] usb usb7: Product: OHCI Host Controller
> [    2.095311] usb usb7: Manufacturer: Linux 3.2.0-rc0+ ohci_hcd
> [    2.095313] usb usb7: SerialNumber: 0000:00:16.0
> [    2.095642] usb usb7: usb_probe_device
> [    2.095644] usb usb7: configuration #1 chosen from 1 choice
> [    2.095653] usb usb7: adding 7-0:1.0 (config #1, interface 0)
> [    2.095820] hub 7-0:1.0: usb_probe_interface
> [    2.095822] hub 7-0:1.0: usb_probe_interface - got id
> [    2.095823] hub 7-0:1.0: USB hub found
> [    2.095833] hub 7-0:1.0: 4 ports detected
> [    2.095834] hub 7-0:1.0: standalone hub
> [    2.095835] hub 7-0:1.0: no power switching (usb 1.0)
> [    2.095846] hub 7-0:1.0: no over-current protection
> [    2.095848] hub 7-0:1.0: power on to power good time: 4ms
> [    2.095858] hub 7-0:1.0: local power source is good
> [    2.095859] hub 7-0:1.0: trying to enable port power on non-switchable hub
> [    2.095898] drivers/usb/core/inode.c: creating file '001'
> [    2.095993] ehci_hcd 0000:00:16.2: HS companion for 0000:00:16.0
> [    2.096345] uhci_hcd: USB Universal Host Controller Interface driver
> [    2.096654] usbcore: registered new interface driver usblp
> [    2.096655] Initializing USB Mass Storage driver...
> [    2.096788] usbcore: registered new interface driver usb-storage
> [    2.096799] USB Mass Storage support registered.
> [    2.096945] usbcore: registered new interface driver libusual
> [    2.097241] usbcore: registered new interface driver usbserial
> [    2.097245] usbserial: USB Serial Driver core
> [    2.097358] USB Serial support registered for cp210x
> [    2.097471] usbcore: registered new interface driver cp210x
> [    2.097472] cp210x: v0.09:Silicon Labs CP210x RS232 serial adaptor driver
> [    2.097590] USB Serial support registered for DeLorme Earthmate USB
> [    2.097687] USB Serial support registered for HID->COM RS232 Adapter
> [    2.097782] USB Serial support registered for Nokia CA-42 V2 Adapter
> [    2.097891] usbcore: registered new interface driver cypress
> [    2.097893] cypress_m8: v1.10:Cypress USB to Serial Driver
> [    2.097992] USB Serial support registered for Moschip 2 port adapter
> [    2.097994] mos7720: 2.1:Moschip USB Serial Driver
> [    2.098141] usbcore: registered new interface driver moschip7720
> [    2.098244] USB Serial support registered for Moschip 7840/7820 USB Serial Driver
> [    2.098246] mos7840: 1.3.2:Moschip 7840/7820 USB Serial Driver
> [    2.098372] usbcore: registered new interface driver mos7840
> [    2.098814] i8042: PNP: No PS/2 controller found. Probing ports directly.
> [    2.099543] serio: i8042 KBD port at 0x60,0x64 irq 1
> [    2.099557] serio: i8042 AUX port at 0x60,0x64 irq 12
> [    2.100022] mousedev: PS/2 mouse device common for all mice
> [    2.100677] rtc_cmos 00:04: RTC can wake from S4
> [    2.101180] rtc_cmos 00:04: rtc core: registered rtc_cmos as rtc0
> [    2.101280] rtc0: alarms up to one month, y3k, 114 bytes nvram
> [    2.101963] lirc_dev: IR Remote Control driver registered, major 251 
> [    2.101976] IR NEC protocol handler initialized
> [    2.101978] IR RC5(x) protocol handler initialized
> [    2.101980] IR RC6 protocol handler initialized
> [    2.101982] IR JVC protocol handler initialized
> [    2.101983] IR Sony protocol handler initialized
> [    2.101985] IR RC5 (streamzap) protocol handler initialized
> [    2.101987] IR MCE Keyboard/mouse protocol handler initialized
> [    2.101989] IR LIRC bridge handler initialized
> [    2.101990] Linux video capture interface: v2.00
> [    2.102215] i2c-core: driver [tuner] using legacy suspend method
> [    2.102216] i2c-core: driver [tuner] using legacy resume method
> [    2.102410] i2c-core: driver [msp3400] using legacy suspend method
> [    2.102412] i2c-core: driver [msp3400] using legacy resume method
> [    2.102879] usbcore: registered new interface driver poseidon
> [    2.102991] usbcore: registered new interface driver cx231xx
> [    2.103138] usbcore: registered new interface driver usbvision
> [    2.103140] USBVision USB Video Device Driver for Linux : 0.9.11
> [    2.103453] usbcore: registered new interface driver pvrusb2
> [    2.103454] pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
> [    2.103456] pvrusb2: Debug mask is 31 (0x1f)
> [    2.103586] usbcore: registered new interface driver tm6000
> [    2.103698] usbcore: registered new interface driver zr364xx
> [    2.103830] usbcore: registered new interface driver stkwebcam
> [    2.103940] usbcore: registered new interface driver sn9c102
> [    2.104071] usbcore: registered new interface driver et61x251
> [    2.104189] usbcore: registered new interface driver Philips webcam
> [    2.104191] gspca_main: v2.14.0 registered
> [    2.104307] usbcore: registered new interface driver benq
> [    2.104432] usbcore: registered new interface driver conex
> [    2.104540] usbcore: registered new interface driver cpia1
> [    2.104649] usbcore: registered new interface driver etoms
> [    2.104757] usbcore: registered new interface driver finepix
> [    2.104874] usbcore: registered new interface driver jeilinj
> [    2.104985] usbcore: registered new interface driver kinect
> [    2.105122] usbcore: registered new interface driver konica
> [    2.105228] usbcore: registered new interface driver mars
> [    2.105355] usbcore: registered new interface driver mr97310a
> [    2.105513] usbcore: registered new interface driver nw80x
> [    2.105647] usbcore: registered new interface driver ov519
> [    2.105757] usbcore: registered new interface driver ov534
> [    2.105867] usbcore: registered new interface driver ov534_9
> [    2.105994] usbcore: registered new interface driver pac207
> [    2.106125] usbcore: registered new interface driver pac7302
> [    2.106258] usbcore: registered new interface driver pac7311
> [    2.106364] usbcore: registered new interface driver se401
> [    2.106470] usbcore: registered new interface driver sn9c2028
> [    2.106594] usbcore: registered new interface driver sn9c20x
> [    2.106712] usbcore: registered new interface driver sonixb
> [    2.106831] usbcore: registered new interface driver sonixj
> [    2.106949] usbcore: registered new interface driver spca500
> [    2.107081] usbcore: registered new interface driver spca501
> [    2.107211] usbcore: registered new interface driver spca505
> [    2.107326] usbcore: registered new interface driver spca506
> [    2.107432] usbcore: registered new interface driver spca508
> [    2.107559] usbcore: registered new interface driver spca561
> [    2.107670] usbcore: registered new interface driver spca1528
> [    2.107778] usbcore: registered new interface driver sq905
> [    2.107904] usbcore: registered new interface driver sq905c
> [    2.108014] usbcore: registered new interface driver sq930x
> [    2.108196] usbcore: registered new interface driver sunplus
> [    2.108309] usbcore: registered new interface driver stk014
> [    2.108427] usbcore: registered new interface driver stv0680
> [    2.108535] usbcore: registered new interface driver t613
> [    2.108645] usbcore: registered new interface driver tv8532
> [    2.108772] usbcore: registered new interface driver vc032x
> [    2.108879] usbcore: registered new interface driver vicam
> [    2.108992] usbcore: registered new interface driver xirlink-cit
> [    2.109145] usbcore: registered new interface driver zc3xx
> [    2.109267] usbcore: registered new interface driver ALi m5602
> [    2.109388] usbcore: registered new interface driver STV06xx
> [    2.109501] usbcore: registered new interface driver gspca_gl860
> [    2.109663] usbcore: registered new interface driver hdpvr
> [    2.109776] usbcore: registered new interface driver s2255
> [    2.109902] usbcore: registered new interface driver uvcvideo
> [    2.109903] USB Video Class driver (1.1.1)
> [    2.110112] f71882fg: Found f71889ed chip at 0x600, revision 16
> [    2.110464] f71882fg f71882fg.1536: Fan: 1 is in duty-cycle mode
> [    2.110512] f71882fg f71882fg.1536: Fan: 2 is in duty-cycle mode
> [    2.110554] f71882fg f71882fg.1536: Fan: 3 is in duty-cycle mode
> [    2.111792] f71808e_wdt: Unrecognized Fintek device: 0909
> [    2.111798] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01
> [    2.112097] SP5100 TCO timer: mmio address 0xb8fe00 already in use
> [    2.112107] wdt: Xen WatchDog Timer Driver v0.01
> [    2.112487] wdt: initialized (timeout=60s, nowayout=0)
> [    2.113129] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
> [    2.113486] EFI Variables Facility v0.08 2004-May-17
> [    2.116096] usbcore: registered new interface driver usbhid
> [    2.116098] usbhid: USB HID core driver
> [    2.120940] usbcore: registered new interface driver snd-usb-audio
> [    2.121092] usbcore: registered new interface driver snd-ua101
> [    2.121208] usbcore: registered new interface driver snd-usb-usx2y
> [    2.121338] usbcore: registered new interface driver snd-usb-us122l
> [    2.121454] usbcore: registered new interface driver snd-usb-caiaq
> [    2.121569] usbcore: registered new interface driver snd-usb-6fire
> [    2.121571] ALSA device list:
> [    2.121572]   No soundcards found.
> [    2.121636] Netfilter messages via NETLINK v0.30.
> [    2.121697] nf_conntrack version 0.5.0 (7319 buckets, 29276 max)
> [    2.122470] ctnetlink v0.93: registering with nfnetlink.
> [    2.123185] xt_time: kernel timezone is -0000
> [    2.123201] ip_set: protocol 6
> [    2.123253] IPVS: Registered protocols ()
> [    2.123278] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
> [    2.123583] IPVS: Creating netns size=1912 id=0
> [    2.123590] IPVS: ipvs loaded.
> [    2.125542] ip_tables: (C) 2000-2006 Netfilter Core Team
> [    2.125668] TCP cubic registered
> [    2.125671] NET: Registered protocol family 17
> [    2.125792] Bridge firewalling registered
> [    2.125806] Ebtables v2.0 registered
> [    2.125850] Registering the dns_resolver key type
> [    2.126537] registered taskstats version 1
> [    2.128471]   Magic number: 12:515:430
> [    2.139144] hub 6-0:1.0: state 7 ports 2 chg 0000 evt 0000
> [    2.195158] hub 7-0:1.0: state 7 ports 4 chg 0000 evt 0000
> [    3.556135] console [netcon0] enabled
> [    3.560114] netconsole: network logging started
> [    3.565183] Freeing unused kernel memory: 644k freed
> [    3.566054] Write protecting the kernel read-only data: 14336k
> [    3.582581] Freeing unused kernel memory: 1108k freed
> [    3.587819] Freeing unused kernel memory: 172k freed
> [    4.375679] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
> [    5.735717] udev[1928]: starting version 164
> [    6.619502] ata1.00: configured for UDMA/133
> [    6.620486] ata1: EH complete
> [    6.989411] ata1.00: configured for UDMA/133
> [    6.989416] ata1: EH complete
> [    7.544355] EXT4-fs (dm-0): re-mounted. Opts: (null)
> [    7.750228] EXT4-fs (dm-0): re-mounted. Opts: barrier=1,errors=remount-ro
> [   13.646383] Adding 2097148k swap on /dev/mapper/serveerstertje-swap.  Priority:-1 extents:1 across:2097148k 
> [   14.689994] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   15.923651] r8169 0000:08:00.0: eth1: link down
> [   15.924659] r8169 0000:08:00.0: eth1: link down
> [   16.114905] r8169 0000:09:00.0: eth0: link down
> [   16.115942] r8169 0000:09:00.0: eth0: link down
> [   17.642504] r8169 0000:08:00.0: eth1: link up
> [   18.022436] r8169 0000:09:00.0: eth0: link up
> [   24.083304] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=18250 DPT=53 LEN=47 
> [   24.083326] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=18250 DPT=53 LEN=47 
> [   24.116546] FW: ipmasq, Forward .. EoC: IN=eth1 OUT=eth0 MAC=40:61:86:f4:67:d8:00:13:e8:b8:03:7f:08:00 SRC=172.16.1.20 DST=64.4.34.191 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=15618 DF PROTO=TCP SPT=49194 DPT=1863 WINDOW=0 RES=0x00 ACK RST URGP=0 
> [   24.119022] FW: ipmasq, Forward .. EoC: IN=eth1 OUT=eth0 MAC=40:61:86:f4:67:d8:00:13:e8:b8:03:7f:08:00 SRC=172.16.1.20 DST=64.4.44.72 LEN=45 TOS=0x00 PREC=0x00 TTL=127 ID=15619 DF PROTO=TCP SPT=52059 DPT=1863 WINDOW=65 RES=0x00 ACK PSH FIN URGP=0 
> [   24.497023] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52176 DF PROTO=UDP SPT=46112 DPT=53 LEN=47 
> [   24.497126] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=38173 DPT=53 LEN=47 
> [   24.497173] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=42462 DPT=53 LEN=47 
> [   24.497219] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=52498 DPT=53 LEN=47 
> [   24.497263] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=41981 DPT=53 LEN=47 
> [   24.497307] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=44950 DPT=53 LEN=47 
> [   24.497356] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=57749 DPT=53 LEN=47 
> [   24.497402] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=40747 DPT=53 LEN=47 
> [   24.497480] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=56044 DPT=53 LEN=47 
> [   24.497527] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=56530 DPT=53 LEN=47 
> [   24.497571] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=59746 DPT=53 LEN=47 
> [   24.497615] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=58422 DPT=53 LEN=47 
> [   24.497671] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=35192 DPT=53 LEN=47 
> [   24.497713] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=52681 DPT=53 LEN=47 
> [   24.497753] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=34661 DPT=53 LEN=47 
> [   24.497793] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=43406 DPT=53 LEN=47 
> [   24.498003] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=40187 DPT=53 LEN=47 
> [   24.498043] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52177 DF PROTO=UDP SPT=52592 DPT=53 LEN=47 
> [   24.498123] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=40073 DPT=53 LEN=47 
> [   24.498169] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=48232 DPT=53 LEN=47 
> [   24.498213] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=56401 DPT=53 LEN=47 
> [   24.498264] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=42295 DPT=53 LEN=47 
> [   24.498308] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=37428 DPT=53 LEN=47 
> [   24.498353] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=39793 DPT=53 LEN=47 
> [   24.498399] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=39550 DPT=53 LEN=47 
> [   24.498446] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=51014 DPT=53 LEN=47 
> [   24.498486] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=33114 DPT=53 LEN=47 
> [   24.498525] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=46473 DPT=53 LEN=47 
> [   24.498565] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=54857 DPT=53 LEN=47 
> [   24.498606] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=50547 DPT=53 LEN=47 
> [   24.498645] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=57172 DPT=53 LEN=47 
> [   24.498684] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=35018 DPT=53 LEN=47 
> [   24.498879] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=39233 DPT=53 LEN=47 
> [   24.498920] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=55591 DPT=53 LEN=47 
> [   24.498960] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=49309 DPT=53 LEN=47 
> [   24.498999] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=55292 DPT=53 LEN=47 
> [   24.499039] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52178 DF PROTO=UDP SPT=52173 DPT=53 LEN=47 
> [   24.499121] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=40901 DPT=53 LEN=47 
> [   24.499166] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=57459 DPT=53 LEN=47 
> [   24.499211] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=44390 DPT=53 LEN=47 
> [   24.499260] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=57122 DPT=53 LEN=47 
> [   24.499305] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=33703 DPT=53 LEN=47 
> [   24.499349] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=50839 DPT=53 LEN=47 
> [   24.499396] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=37339 DPT=53 LEN=47 
> [   24.499441] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=56282 DPT=53 LEN=47 
> [   24.499485] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=36999 DPT=53 LEN=47 
> [   24.499530] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=40745 DPT=53 LEN=47 
> [   24.499579] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=57275 DPT=53 LEN=47 
> [   24.499772] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=60162 DPT=53 LEN=47 
> [   24.499812] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=47685 DPT=53 LEN=47 
> [   24.499851] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=44549 DPT=53 LEN=47 
> [   24.499890] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=60280 DPT=53 LEN=47 
> [   24.499929] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=49966 DPT=53 LEN=47 
> [   24.499969] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=60795 DPT=53 LEN=47 
> [   24.500008] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=40379 DPT=53 LEN=47 
> [   24.500048] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52179 DF PROTO=UDP SPT=41815 DPT=53 LEN=47 
> [   24.500129] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=47336 DPT=53 LEN=47 
> [   24.500174] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=34385 DPT=53 LEN=47 
> [   24.500218] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=34089 DPT=53 LEN=47 
> [   24.500263] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=53958 DPT=53 LEN=47 
> [   24.500307] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=41698 DPT=53 LEN=47 
> [   24.500351] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=54925 DPT=53 LEN=47 
> [   24.500395] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=43597 DPT=53 LEN=47 
> [   24.500440] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=52180 DF PROTO=UDP SPT=36447 DPT=53 LEN=47 
> [   27.349843] sshd (5162): /proc/5162/oom_adj is deprecated, please use /proc/5162/oom_score_adj instead.
> [   28.082409] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   28.705405] EXT4-fs (dm-36): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   29.249131] EXT4-fs (dm-37): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   29.715206] EXT4-fs (dm-38): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   30.388561] EXT4-fs (dm-39): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   30.468794] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=11418 DPT=53 LEN=47 
> [   30.490797] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=11418 DPT=53 LEN=47 
> [   30.756151] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=62559 DPT=53 LEN=47 
> [   30.779123] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=62559 DPT=53 LEN=47 
> [   30.808008] EXT4-fs (dm-40): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   30.812794] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=28521 DPT=53 LEN=47 
> [   30.812811] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=28521 DPT=53 LEN=47 
> [   30.825619] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=61480 DPT=53 LEN=40 
> [   30.825636] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=61480 DPT=53 LEN=40 
> [   30.826343] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=28651 DPT=53 LEN=47 
> [   30.826359] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=28651 DPT=53 LEN=47 
> [   30.841085] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=24486 DPT=53 LEN=47 
> [   30.841101] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=24486 DPT=53 LEN=47 
> [   30.856521] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58984 DPT=53 LEN=47 
> [   30.856538] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58984 DPT=53 LEN=47 
> [   30.872092] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=52348 DPT=53 LEN=47 
> [   30.872118] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=52348 DPT=53 LEN=47 
> [   30.887716] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=61609 DPT=53 LEN=47 
> [   30.887733] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=61609 DPT=53 LEN=47 
> [   30.903377] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=22448 DPT=53 LEN=47 
> [   30.903394] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=22448 DPT=53 LEN=47 
> [   30.920142] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=15774 DPT=53 LEN=47 
> [   30.920158] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=15774 DPT=53 LEN=47 
> [   30.934450] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=33880 DPT=53 LEN=47 
> [   30.934466] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=33880 DPT=53 LEN=47 
> [   30.950468] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=63072 DPT=53 LEN=47 
> [   30.950485] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=63072 DPT=53 LEN=47 
> [   30.966308] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=13061 DPT=53 LEN=47 
> [   30.966325] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=13061 DPT=53 LEN=47 
> [   30.981966] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=47836 DPT=53 LEN=47 
> [   30.981983] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=47836 DPT=53 LEN=47 
> [   30.997341] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=55194 DPT=53 LEN=47 
> [   30.997357] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=55194 DPT=53 LEN=47 
> [   31.013438] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50477 DPT=53 LEN=47 
> [   31.013455] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50477 DPT=53 LEN=47 
> [   31.029811] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=13928 DPT=53 LEN=47 
> [   31.029828] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=13928 DPT=53 LEN=47 
> [   31.044600] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=41201 DPT=53 LEN=47 
> [   31.044616] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=41201 DPT=53 LEN=47 
> [   31.060007] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=64783 DPT=53 LEN=47 
> [   31.060025] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=64783 DPT=53 LEN=47 
> [   31.075536] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=45723 DPT=53 LEN=47 
> [   31.075552] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=45723 DPT=53 LEN=47 
> [   31.091041] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=26819 DPT=53 LEN=47 
> [   31.091101] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=26819 DPT=53 LEN=47 
> [   31.106879] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=5918 DPT=53 LEN=47 
> [   31.106896] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=5918 DPT=53 LEN=47 
> [   31.123862] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8486 DPT=53 LEN=47 
> [   31.123880] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8486 DPT=53 LEN=47 
> [   31.138293] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=30325 DPT=53 LEN=47 
> [   31.138312] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=30325 DPT=53 LEN=47 
> [   31.153511] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50004 DPT=53 LEN=47 
> [   31.153527] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=50004 DPT=53 LEN=47 
> [   31.169000] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39425 DPT=53 LEN=47 
> [   31.169017] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39425 DPT=53 LEN=47 
> [   31.184877] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8838 DPT=53 LEN=47 
> [   31.184934] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8838 DPT=53 LEN=47 
> [   31.200343] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=42830 DPT=53 LEN=47 
> [   31.200359] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=42830 DPT=53 LEN=47 
> [   31.216019] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=25917 DPT=53 LEN=47 
> [   31.216046] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=25917 DPT=53 LEN=47 
> [   31.232094] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=11910 DPT=53 LEN=47 
> [   31.232112] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=11910 DPT=53 LEN=47 
> [   31.304406] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=75 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=14618 DPT=53 LEN=55 
> [   31.304423] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=75 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=14618 DPT=53 LEN=55 
> [   31.525843] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=57066 DPT=53 LEN=42 
> [   31.525859] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=57066 DPT=53 LEN=42 
> [   33.370377] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: barrier=1,errors=remount-ro
> [   38.708110] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=59086 DPT=53 LEN=47 
> [   38.740705] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=59086 DPT=53 LEN=47 
> [   40.699839] FW: ipmasq, Forward .. EoC: IN=eth1 OUT=eth0 MAC=40:61:86:f4:67:d8:00:13:e8:b8:03:7f:08:00 SRC=172.16.1.20 DST=64.4.44.72 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=15669 DF PROTO=TCP SPT=52059 DPT=1863 WINDOW=0 RES=0x00 ACK RST URGP=0 
> [   40.843016] XENBUS: Unable to read cpu state
> [   40.859766] XENBUS: Unable to read cpu state
> [   40.859943] XENBUS: Unable to read cpu state
> [   40.860165] XENBUS: Unable to read cpu state
> [   40.860324] XENBUS: Unable to read cpu state
> [   40.860521] XENBUS: Unable to read cpu state
> [   47.255764] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9399 DF PROTO=UDP SPT=56370 DPT=53 LEN=50 
> [   47.284392] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9428 DF PROTO=UDP SPT=38848 DPT=53 LEN=50 
> [   47.315317] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9459 DF PROTO=UDP SPT=57230 DPT=53 LEN=50 
> [   47.346000] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=70 TOS=0x00 PREC=0x00 TTL=64 ID=9489 DF PROTO=UDP SPT=37919 DPT=53 LEN=50 
> [   60.891334] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=24907 DPT=53 LEN=47 
> [   60.919853] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=24907 DPT=53 LEN=47 
> [   60.949642] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36011 DPT=53 LEN=40 
> [   60.979376] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36011 DPT=53 LEN=40 
> [   61.009190] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=42832 DPT=53 LEN=47 
> [   61.038983] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=42832 DPT=53 LEN=47 
> [   61.074371] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=23461 DPT=53 LEN=47 
> [   61.103755] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=23461 DPT=53 LEN=47 
> [   61.137041] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=56532 DPT=53 LEN=47 
> [   61.166563] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=56532 DPT=53 LEN=47 
> [   61.199749] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=17213 DPT=53 LEN=47 
> [   61.229937] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=17213 DPT=53 LEN=47 
> [   61.277683] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8231 DPT=53 LEN=47 
> [   61.306229] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=8231 DPT=53 LEN=47 
> [   61.347115] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=12397 DPT=53 LEN=47 
> [   61.376324] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=67 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=12397 DPT=53 LEN=47 
> [   61.448728] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=75 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=6376 DPT=53 LEN=55 
> [   61.478229] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=75 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=6376 DPT=53 LEN=55 
> [   61.696753] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.200 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44963 DPT=53 LEN=42 
> [   61.726660] FW: ipmasq, Output .. EoC: IN= OUT=eth0 SRC=88.159.72.25 DST=88.159.1.201 LEN=62 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44963 DPT=53 LEN=42 

> enabled)
> (XEN) Processor #0 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
> (XEN) Processor #1 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
> (XEN) Processor #2 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
> (XEN) Processor #3 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
> (XEN) Processor #4 0:10 APIC version 16
> (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled)
> (XEN) Processor #5 0:10 APIC version 16
> (XEN) ACPI: IOAPIC (id[0x06] address[0xfec00000] gsi_base[0])
> (XEN) IOAPIC[0]: apic_id 6, version 33, address 0xfec00000, GSI 0-23
> (XEN) ACPI: IOAPIC (id[0x07] address[0xfec20000] gsi_base[24])
> (XEN) IOAPIC[1]: apic_id 7, version 33, address 0xfec20000, GSI 24-55
> (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 low 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 2 I/O APICs
> (XEN) ACPI: HPET id: 0x8300 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) mapped IOAPIC to ffff82c3ffffc000 (fec20000)
> (XEN) IRQ limits: 56 GSI, 1112 MSI/MSI-X
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Detected 3200.160 MHz processor.
> (XEN) Initing memory sharing.
> (XEN) AMD Fam10h machine check reporting enabled
> (XEN) AMD-Vi: Found MSI capability block 
> (XEN) AMD-Vi: ACPI Table:
> (XEN) AMD-Vi:  Signature IVRS
> (XEN) AMD-Vi:  Length 0x100
> (XEN) AMD-Vi:  Revision 0x1
> (XEN) AMD-Vi:  CheckSum 0x66
> (XEN) AMD-Vi:  OEM_Id AMD  
> (XEN) AMD-Vi:  OEM_Table_Id RD890S
> (XEN) AMD-Vi:  OEM_Revision 0x202031
> (XEN) AMD-Vi:  Creator_Id AMD 
> (XEN) AMD-Vi:  Creator_Revision 0x0
> (XEN) AMD-Vi: IVRS Block:
> (XEN) AMD-Vi:  Type 0x10
> (XEN) AMD-Vi:  Flags 0x3e
> (XEN) AMD-Vi:  Length 0xd0
> (XEN) AMD-Vi:  Dev_Id 0x2
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x0 -> 0x2
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x10
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xb00
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x18
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0xa00
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0xa00 -> 0xa07
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x28
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x900
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x30
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x800
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x50
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x600
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x0
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x43
> (XEN) AMD-Vi:  Dev_Id 0x708
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x708 -> 0x7ff
> (XEN) AMD-Vi:  Dev_Id Alias: 0x700
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x58
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x500
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x500 -> 0x501
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x68
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x400
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x400 -> 0x407
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x88
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x90
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x90 -> 0x92
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0x98
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x98 -> 0x9a
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa0
> (XEN) AMD-Vi:  Flags 0xd7
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa3
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa4
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x0
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x43
> (XEN) AMD-Vi:  Dev_Id 0x300
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0x300 -> 0x3ff
> (XEN) AMD-Vi:  Dev_Id Alias: 0xa4
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa5
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa8
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0xa9
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x2
> (XEN) AMD-Vi:  Dev_Id 0x100
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x3
> (XEN) AMD-Vi:  Dev_Id 0xb0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi:  Dev_Id Range: 0xb0 -> 0xb2
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x0
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x48
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0xd7
> (XEN) AMD-Vi: IVHD Device Entry:
> (XEN) AMD-Vi:  Type 0x48
> (XEN) AMD-Vi:  Dev_Id 0x0
> (XEN) AMD-Vi:  Flags 0x0
> (XEN) AMD-Vi: Add device table entry: device id = 0x0000, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0001, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0002, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0010, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0018, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0028, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0030, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0050, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0058, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0068, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0088, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0090, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0091, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0092, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0098, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0099, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x009a, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a0, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a3, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a4, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a5, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a8, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00a9, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00b0, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00b1, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x00b2, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0100, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0400, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0401, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0402, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0403, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0404, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0405, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0406, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0407, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0500, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0501, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0600, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0700, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0800, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0900, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a00, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a01, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a02, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a03, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a04, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a05, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a06, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0a07, interupt table = 0x24df1e000
> (XEN) AMD-Vi: Add device table entry: device id = 0x0b00, interupt table = 0x24df1e000
> (XEN) AMD-Vi: IOMMU 0 Enabled.
> (XEN) AMD-Vi: Enabling global vector map
> (XEN) I/O virtualisation enabled
> (XEN)  - Dom0 mode: Relaxed
> (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) 6-0, 6-16, 6-17, 6-18, 6-19, 6-20, 6-21, 6-22, 6-23, 7-0, 7-1, 7-2, 7-3, 7-4, 7-5, 7-6, 7-7, 7-8, 7-9, 7-10, 7-11, 7-12, 7-13, 7-14, 7-15, 7-16, 7-17, 7-18, 7-19, 7-20, 7-21, 7-22, 7-23, 7-24, 7-25, 7-26, 7-27, 7-28, 7-29, 7-30, 7-31 not connected.
> (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
> (XEN) number of MP IRQ sources: 15.
> (XEN) number of IO-APIC #6 registers: 24.
> (XEN) number of IO-APIC #7 registers: 32.
> (XEN) testing the IO APIC.......................
> (XEN) IO APIC #6......
> (XEN) .... register #00: 06000000
> (XEN) .......    : physical APIC id: 06
> (XEN) .......    : Delivery Type: 0
> (XEN) .......    : LTS          : 0
> (XEN) .... register #01: 00178021
> (XEN) .......     : max redirection entries: 0017
> (XEN) .......     : PRQ implemented: 1
> (XEN) .......     : IO APIC version: 0021
> (XEN) .... register #02: 06000000
> (XEN) .......     : arbitration: 06
> (XEN) .... register #03: 07000000
> (XEN) .......     : Boot DT    : 0
> (XEN) .... IRQ redirection table:
> (XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
> (XEN)  00 000 00  1    0    0   0   0    0    0    00
> (XEN)  01 001 01  0    0    0   0   0    1    1    30
> (XEN)  02 001 01  0    0    0   0   0    1    1    F0
> (XEN)  03 001 01  0    0    0   0   0    1    1    38
> (XEN)  04 001 01  0    0    0   0   0    1    1    F1
> (XEN)  05 001 01  0    0    0   0   0    1    1    40
> (XEN)  06 001 01  0    0    0   0   0    1    1    48
> (XEN)  07 001 01  0    0    0   0   0    1    1    50
> (XEN)  08 001 01  0    0    0   0   0    1    1    58
> (XEN)  09 001 01  1    1    0   1   0    1    1    60
> (XEN)  0a 001 01  0    0    0   0   0    1    1    68
> (XEN)  0b 001 01  0    0    0   0   0    1    1    70
> (XEN)  0c 001 01  0    0    0   0   0    1    1    78
> (XEN)  0d 001 01  0    0    0   0   0    1    1    88
> (XEN)  0e 001 01  0    0    0   0   0    1    1    90
> (XEN)  0f 001 01  0    0    0   0   0    1    1    98
> (XEN)  10 000 00  1    0    0   0   0    0    0    00
> (XEN)  11 000 00  1    0    0   0   0    0    0    00
> (XEN)  12 000 00  1    0    0   0   0    0    0    00
> (XEN)  13 000 00  1    0    0   0   0    0    0    00
> (XEN)  14 000 00  1    0    0   0   0    0    0    00
> (XEN)  15 000 00  1    0    0   0   0    0    0    00
> (XEN)  16 000 00  1    0    0   0   0    0    0    00
> (XEN)  17 000 00  1    0    0   0   0    0    0    00
> (XEN) IO APIC #7......
> (XEN) .... register #00: 07000000
> (XEN) .......    : physical APIC id: 07
> (XEN) .......    : Delivery Type: 0
> (XEN) .......    : LTS          : 0
> (XEN) .... register #01: 001F8021
> (XEN) .......     : max redirection entries: 001F
> (XEN) .......     : PRQ implemented: 1
> (XEN) .......     : IO APIC version: 0021
> (XEN) .... register #02: 00000000
> (XEN) .......     : arbitration: 00
> (XEN) .... IRQ redirection table:
> (XEN)  NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
> (XEN)  00 000 00  1    0    0   0   0    0    0    00
> (XEN)  01 000 00  1    0    0   0   0    0    0    00
> (XEN)  02 000 00  1    0    0   0   0    0    0    00
> (XEN)  03 000 00  1    0    0   0   0    0    0    00
> (XEN)  04 000 00  1    0    0   0   0    0    0    00
> (XEN)  05 000 00  1    0    0   0   0    0    0    00
> (XEN)  06 000 00  1    0    0   0   0    0    0    00
> (XEN)  07 000 00  1    0    0   0   0    0    0    00
> (XEN)  08 000 00  1    0    0   0   0    0    0    00
> (XEN)  09 000 00  1    0    0   0   0    0    0    00
> (XEN)  0a 000 00  1    0    0   0   0    0    0    00
> (XEN)  0b 000 00  1    0    0   0   0    0    0    00
> (XEN)  0c 000 00  1    0    0   0   0    0    0    00
> (XEN)  0d 000 00  1    0    0   0   0    0    0    00
> (XEN)  0e 000 00  1    0    0   0   0    0    0    00
> (XEN)  0f 000 00  1    0    0   0   0    0    0    00
> (XEN)  10 000 00  1    0    0   0   0    0    0    00
> (XEN)  11 000 00  1    0    0   0   0    0    0    00
> (XEN)  12 000 00  1    0    0   0   0    0    0    00
> (XEN)  13 000 00  1    0    0   0   0    0    0    00
> (XEN)  14 000 00  1    0    0   0   0    0    0    00
> (XEN)  15 000 00  1    0    0   0   0    0    0    00
> (XEN)  16 000 00  1    0    0   0   0    0    0    00
> (XEN)  17 000 00  1    0    0   0   0    0    0    00
> (XEN)  18 000 00  1    0    0   0   0    0    0    00
> (XEN)  19 000 00  1    0    0   0   0    0    0    00
> (XEN)  1a 000 00  1    0    0   0   0    0    0    00
> (XEN)  1b 000 00  1    0    0   0   0    0    0    00
> (XEN)  1c 000 00  1    0    0   0   0    0    0    00
> (XEN)  1d 000 00  1    0    0   0   0    0    0    00
> (XEN)  1e 000 00  1    0    0   0   0    0    0    00
> (XEN)  1f 000 00  1    0    0   0   0    0    0    00
> (XEN) Using vector-based indexing
> (XEN) IRQ to pin mappings:
> (XEN) IRQ240 -> 0:2
> (XEN) IRQ48 -> 0:1
> (XEN) IRQ56 -> 0:3
> (XEN) IRQ241 -> 0:4
> (XEN) IRQ64 -> 0:5
> (XEN) IRQ72 -> 0:6
> (XEN) IRQ80 -> 0:7
> (XEN) IRQ88 -> 0:8
> (XEN) IRQ96 -> 0:9
> (XEN) IRQ104 -> 0:10
> (XEN) IRQ112 -> 0:11
> (XEN) IRQ120 -> 0:12
> (XEN) IRQ136 -> 0:13
> (XEN) IRQ144 -> 0:14
> (XEN) IRQ152 -> 0:15
> (XEN) .................................... done.
> (XEN) Using local APIC timer interrupts.
> (XEN) calibrating APIC timer ...
> (XEN) ..... CPU clock speed is 3200.1868 MHz.
> (XEN) ..... host bus clock speed is 200.0115 MHz.
> (XEN) ..... bus_scale = 0x0000CCD7
> (XEN) [2012-01-12 12:25:10] Platform timer appears to have unexpectedly wrapped 10 or more times.
> (XEN) [2012-01-12 12:25:10] Platform timer is 14.318MHz HPET
> (XEN) [2012-01-12 12:25:10] Allocated console ring of 64 KiB.
> (XEN) [2012-01-12 12:25:10] HVM: ASIDs enabled.
> (XEN) [2012-01-12 12:25:10] SVM: Supported advanced features:
> (XEN) [2012-01-12 12:25:10]  - Nested Page Tables (NPT)
> (XEN) [2012-01-12 12:25:10]  - Last Branch Record (LBR) Virtualisation
> (XEN) [2012-01-12 12:25:10]  - Next-RIP Saved on #VMEXIT
> (XEN) [2012-01-12 12:25:10]  - Pause-Intercept Filter
> (XEN) [2012-01-12 12:25:10] HVM: SVM enabled
> (XEN) [2012-01-12 12:25:10] HVM: Hardware Assisted Paging detected.
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#1
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#2
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#3
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#4
> (XEN) [2012-01-12 12:25:09] masked ExtINT on CPU#5
> (XEN) [2012-01-12 12:25:10] Brought up 6 CPUs
> (XEN) [2012-01-12 12:25:10] HPET's MSI mode hasn't been supported when Interrupt Remapping is enabled.
> (XEN) [2012-01-12 12:25:10] ACPI sleep modes: S3
> (XEN) [2012-01-12 12:25:10] MCA: Use hw thresholding to adjust polling frequency
> (XEN) [2012-01-12 12:25:10] mcheck_poll: Machine check polling timer started.
> (XEN) [2012-01-12 12:25:10] Xenoprofile: Failed to setup IBS LVT offset, IBSCTL = 0xffffffff
> (XEN) [2012-01-12 12:25:10] *** LOADING DOMAIN 0 ***
> (XEN) [2012-01-12 12:25:11]  Xen  kernel: 64-bit, lsb, compat32
> (XEN) [2012-01-12 12:25:11]  Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2b5a000
> (XEN) [2012-01-12 12:25:11] PHYSICAL MEMORY ARRANGEMENT:
> (XEN) [2012-01-12 12:25:11]  Dom0 alloc.:   0000000244000000->0000000248000000 (244079 pages to be allocated)
> (XEN) [2012-01-12 12:25:11]  Init. ramdisk: 000000024f96f000->000000024ffff400
> (XEN) [2012-01-12 12:25:11] VIRTUAL MEMORY ARRANGEMENT:
> (XEN) [2012-01-12 12:25:11]  Loaded kernel: ffffffff81000000->ffffffff82b5a000
> (XEN) [2012-01-12 12:25:11]  Init. ramdisk: ffffffff82b5a000->ffffffff831ea400
> (XEN) [2012-01-12 12:25:11]  Phys-Mach map: ffffffff831eb000->ffffffff833eb000
> (XEN) [2012-01-12 12:25:11]  Start info:    ffffffff833eb000->ffffffff833eb4b4
> (XEN) [2012-01-12 12:25:11]  Page tables:   ffffffff833ec000->ffffffff8340b000
> (XEN) [2012-01-12 12:25:11]  Boot stack:    ffffffff8340b000->ffffffff8340c000
> (XEN) [2012-01-12 12:25:11]  TOTAL:         ffffffff80000000->ffffffff83800000
> (XEN) [2012-01-12 12:25:11]  ENTRY ADDRESS: ffffffff81ee5200
> (XEN) [2012-01-12 12:25:11] Dom0 has maximum 6 VCPUs
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0000, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0002, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0010, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0018, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0028, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0030, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0050, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0058, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0068, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0088, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0090, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0092, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0098, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x009a, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a0, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a3, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a4, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a5, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00a8, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00b0, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x00b2, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.0
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.1
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.2
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: No iommu for device 00:18.4
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0400, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0401, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0402, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0403, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0404, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0405, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0406, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0407, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0500, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0501, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0600, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0700, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0800, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0900, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a00, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a01, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a02, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a03, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a04, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a05, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a06, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0a07, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] AMD-Vi: Setup I/O page table: device id = 0x0b00, root table = 0x24de2d000, domain = 0, paging mode = 3
> (XEN) [2012-01-12 12:25:11] Scrubbing Free RAM: .......................................................................done.
> (XEN) [2012-01-12 12:25:13] Xen trace buffers: disabled
> (XEN) [2012-01-12 12:25:13] Std. Loglevel: All
> (XEN) [2012-01-12 12:25:13] Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
> (XEN) [2012-01-12 12:25:13] Xen is relinquishing VGA console.
> (XEN) [2012-01-12 12:25:13] *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
> (XEN) [2012-01-12 12:25:13] Freed 220kB init memory.
> (XEN) [2012-01-12 12:25:13] IOAPIC[0]: Set PCI routing entry (6-9 -> 0x60 -> IRQ 9 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:13] traps.c:2432:d0 Domain attempted WRMSR 00000000c0010004 from 0x0000eff2fef31f0c to 0x000000000000abcd.
> (XEN) [2012-01-12 12:25:13] PCI add device 00:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:00.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:02.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:03.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:05.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:06.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:0a.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:0b.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:0d.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:11.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:12.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:12.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:13.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:13.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:14.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:14.3
> (XEN) [2012-01-12 12:25:13] PCI add device 00:14.4
> (XEN) [2012-01-12 12:25:13] PCI add device 00:14.5
> (XEN) [2012-01-12 12:25:13] PCI add device 00:15.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:16.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:16.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.0
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.1
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.2
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.3
> (XEN) [2012-01-12 12:25:13] PCI add device 00:18.4
> (XEN) [2012-01-12 12:25:13] PCI add device 0b:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.1
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.2
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.3
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.4
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.5
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.6
> (XEN) [2012-01-12 12:25:13] PCI add device 0a:00.7
> (XEN) [2012-01-12 12:25:13] PCI add device 09:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 08:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 06:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 07:01.0
> (XEN) [2012-01-12 12:25:13] PCI add device 07:01.1
> (XEN) [2012-01-12 12:25:13] PCI add device 07:01.2
> (XEN) [2012-01-12 12:25:13] PCI add device 05:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 05:00.1
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.0
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.1
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.2
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.3
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.4
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.5
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.6
> (XEN) [2012-01-12 12:25:13] PCI add device 04:00.7
> (XEN) [2012-01-12 12:25:13] PCI add device 03:06.0
> (XEN) [2012-01-12 12:25:13] IOAPIC[0]: Set PCI routing entry (6-8 -> 0x58 -> IRQ 8 Mode:0 Active:0)
> (XEN) [2012-01-12 12:25:13] IOAPIC[0]: Set PCI routing entry (6-13 -> 0x88 -> IRQ 13 Mode:0 Active:0)
> (XEN) [2012-01-12 12:25:13] IOAPIC[1]: Set PCI routing entry (7-28 -> 0xa0 -> IRQ 52 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:13] IOAPIC[1]: Set PCI routing entry (7-29 -> 0xa8 -> IRQ 53 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:13] IOAPIC[1]: Set PCI routing entry (7-30 -> 0xb0 -> IRQ 54 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:13] IOAPIC[0]: Set PCI routing entry (6-16 -> 0xb8 -> IRQ 16 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] physdev.c:155: dom0: wrong map_pirq type 3
> (XEN) [2012-01-12 12:25:14] IOAPIC[0]: Set PCI routing entry (6-22 -> 0x41 -> IRQ 22 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-19 -> 0x49 -> IRQ 43 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-18 -> 0x51 -> IRQ 42 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-17 -> 0x59 -> IRQ 41 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-16 -> 0x61 -> IRQ 40 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-9 -> 0x69 -> IRQ 33 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-8 -> 0x71 -> IRQ 32 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-22 -> 0x79 -> IRQ 46 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-21 -> 0x81 -> IRQ 45 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-20 -> 0x89 -> IRQ 44 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-7 -> 0x91 -> IRQ 31 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-6 -> 0x99 -> IRQ 30 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-5 -> 0xa1 -> IRQ 29 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-4 -> 0xa9 -> IRQ 28 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[0]: Set PCI routing entry (6-19 -> 0xb1 -> IRQ 19 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[1]: Set PCI routing entry (7-27 -> 0xc9 -> IRQ 51 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:14] IOAPIC[0]: Set PCI routing entry (6-17 -> 0xd9 -> IRQ 17 Mode:1 Active:1)
> (XEN) [2012-01-12 12:25:15] IOAPIC[0]: Set PCI routing entry (6-18 -> 0x22 -> IRQ 18 Mode:1 Active:1)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:11:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15: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 1RlMJS-0006Vc-Mj; Thu, 12 Jan 2012 15:11:34 +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 1RlMJQ-0006VE-SH
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:11:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326381085!10765171!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 12866 invoked from network); 12 Jan 2012 15:11:25 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 15:11:25 -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
	q0CFBLHm006612; Thu, 12 Jan 2012 15:11:21 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 q0CFBL4p006979; 
	Thu, 12 Jan 2012 10:11:21 -0500
Message-ID: <4F0EF816.6030206@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:11:18 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326362398.17210.227.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 01/12/2012 04:59 AM, Ian Campbell wrote:
> On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>
>> This patch claims one reserved grant entry for the console and another
>> for the xenstore. It modifies the builder to fill in the grant table
>> entries for the console and the xenstore.
>>
>> This has not been tested with any kind of migration.
>>
> [...]
>> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
>> index 3fda6f8..23619da 100644
>> --- a/tools/libxc/xc_domain_restore.c
>> +++ b/tools/libxc/xc_domain_restore.c
>> @@ -2018,6 +2018,15 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
>>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
>>
>> +/* TODO don't hardcode zero here */
>> +    rc = xc_dom_gnttab_seed(xch, dom,
>> +                            *console_mfn, *store_mfn, 0, 0);
> 
> Presumably this TODO is the source of the comment in the changelog WRT
> migration.
> 
> Does it Just Work or is there a legitimate TODO item here?
> 
> Ian.
> 
> 

This causes migration to only work if xenstored/xenconsoled are both in
dom0, as the domain ID for both of them are hardcoded to zero. Determining
the correct values for these domain IDs is more difficult than the domain
build case, because they may not be the same as when the domain was built
(especially if we are migrating).

The previous patch series used a domid file named similarly to a pid file
to identify the location of xenstored and xenconsoled; this method would
allow the TODO to be resolved. I think a better solution is to refer to the
xenstore/xenconsole domains by name instead of domid, and set the names in
a configuration file (/etc/xen/xl.conf?). This would also replace the
xenstore_dom/console_dom parameters in patch #5.

-- 
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 Jan 12 15:11:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15: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 1RlMJS-0006Vc-Mj; Thu, 12 Jan 2012 15:11:34 +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 1RlMJQ-0006VE-SH
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:11:33 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326381085!10765171!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 12866 invoked from network); 12 Jan 2012 15:11:25 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 15:11:25 -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
	q0CFBLHm006612; Thu, 12 Jan 2012 15:11:21 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 q0CFBL4p006979; 
	Thu, 12 Jan 2012 10:11:21 -0500
Message-ID: <4F0EF816.6030206@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:11:18 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326362398.17210.227.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 01/12/2012 04:59 AM, Ian Campbell wrote:
> On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>
>> This patch claims one reserved grant entry for the console and another
>> for the xenstore. It modifies the builder to fill in the grant table
>> entries for the console and the xenstore.
>>
>> This has not been tested with any kind of migration.
>>
> [...]
>> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
>> index 3fda6f8..23619da 100644
>> --- a/tools/libxc/xc_domain_restore.c
>> +++ b/tools/libxc/xc_domain_restore.c
>> @@ -2018,6 +2018,15 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
>>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
>>
>> +/* TODO don't hardcode zero here */
>> +    rc = xc_dom_gnttab_seed(xch, dom,
>> +                            *console_mfn, *store_mfn, 0, 0);
> 
> Presumably this TODO is the source of the comment in the changelog WRT
> migration.
> 
> Does it Just Work or is there a legitimate TODO item here?
> 
> Ian.
> 
> 

This causes migration to only work if xenstored/xenconsoled are both in
dom0, as the domain ID for both of them are hardcoded to zero. Determining
the correct values for these domain IDs is more difficult than the domain
build case, because they may not be the same as when the domain was built
(especially if we are migrating).

The previous patch series used a domid file named similarly to a pid file
to identify the location of xenstored and xenconsoled; this method would
allow the TODO to be resolved. I think a better solution is to refer to the
xenstore/xenconsole domains by name instead of domid, and set the names in
a configuration file (/etc/xen/xl.conf?). This would also replace the
xenstore_dom/console_dom parameters in patch #5.

-- 
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 Jan 12 15:28:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 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 1RlMZj-0006q8-BF; Thu, 12 Jan 2012 15:28:23 +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 1RlMZi-0006q3-Ey
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:28:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326382095!10757006!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 24028 invoked from network); 12 Jan 2012 15:28:15 -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;
	12 Jan 2012 15:28:15 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CFSEHm011566; Thu, 12 Jan 2012 15:28:14 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0CFSEr6007916; 
	Thu, 12 Jan 2012 10:28:14 -0500
Message-ID: <4F0EFC0B.9030600@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:28:11 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EAF05020000780006C061@nat28.tlf.novell.com>
In-Reply-To: <4F0EAF05020000780006C061@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2012 03:59 AM, Jan Beulich wrote:
>>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
>> xenbus backend to be started after the kernel has booted. This is
>> intended to allow dom0 to start another domain to run xenstore.
>>
>> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
>> started; the domain ID is passed as the ioctl argument. This sets up a
>> listening event channel and grant reference to xenbus, but does not
>> start using this interface. It returns the local event channel port.
> 
> Any chance to get at least the setup part matched with the
> legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?
> 
> Jan

>From what I can tell, the legacy ioctl cannot restore watches because the
return value must be used to set up xenstore communication before they can
be used.

Or were you just asking if IOCTL_XENBUS_BACKEND_REMOTE_SETUP's parameter
can be changed to xenbus_alloc_t?  That structure could be populated in the
same way as the legacy implementation, but it wouldn't give any more
information than the current ioctl does.

> 
>> IOCTL_XENBUS_BACKEND_REMOTE_COMMIT causes the kernel to begin using the
>> event channel set up in the previous ioctl, reregistering all watches
>> and deallocating the previous xenstored event channel.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
[...]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:28:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 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 1RlMZj-0006q8-BF; Thu, 12 Jan 2012 15:28:23 +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 1RlMZi-0006q3-Ey
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:28:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326382095!10757006!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 24028 invoked from network); 12 Jan 2012 15:28:15 -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;
	12 Jan 2012 15:28:15 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CFSEHm011566; Thu, 12 Jan 2012 15:28:14 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0CFSEr6007916; 
	Thu, 12 Jan 2012 10:28:14 -0500
Message-ID: <4F0EFC0B.9030600@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:28:11 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EAF05020000780006C061@nat28.tlf.novell.com>
In-Reply-To: <4F0EAF05020000780006C061@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2012 03:59 AM, Jan Beulich wrote:
>>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
>> xenbus backend to be started after the kernel has booted. This is
>> intended to allow dom0 to start another domain to run xenstore.
>>
>> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
>> started; the domain ID is passed as the ioctl argument. This sets up a
>> listening event channel and grant reference to xenbus, but does not
>> start using this interface. It returns the local event channel port.
> 
> Any chance to get at least the setup part matched with the
> legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?
> 
> Jan

>From what I can tell, the legacy ioctl cannot restore watches because the
return value must be used to set up xenstore communication before they can
be used.

Or were you just asking if IOCTL_XENBUS_BACKEND_REMOTE_SETUP's parameter
can be changed to xenbus_alloc_t?  That structure could be populated in the
same way as the legacy implementation, but it wouldn't give any more
information than the current ioctl does.

> 
>> IOCTL_XENBUS_BACKEND_REMOTE_COMMIT causes the kernel to begin using the
>> event channel set up in the previous ioctl, reregistering all watches
>> and deallocating the previous xenstored event channel.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
[...]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:37:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:37:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlMiN-00072j-Be; Thu, 12 Jan 2012 15:37:19 +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 1RlMiL-00072b-Rc
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:37:18 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326382630!10635968!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 21552 invoked from network); 12 Jan 2012 15:37:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 15:37: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
	q0CFb9dY017154; Thu, 12 Jan 2012 15:37:09 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 q0CFb937008512; 
	Thu, 12 Jan 2012 10:37:09 -0500
Message-ID: <4F0EFE22.6040006@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:37:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-19-git-send-email-dgdegra@tycho.nsa.gov>
	<1326363649.17210.234.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326363649.17210.234.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 18/18] xenstored: add --priv-domid 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

On 01/12/2012 05:20 AM, Ian Campbell wrote:
> On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
>> This parameter identifies an alternative service domain which has
>> superuser access to the xenstore database, which is currently required
>> to set up a new domain's xenstore entries.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/xenstored_core.c   |    5 +++++
>>  tools/xenstore/xenstored_core.h   |    1 +
>>  tools/xenstore/xenstored_domain.c |    2 +-
>>  3 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index 65ceb2c..4437c8d 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -1777,6 +1777,7 @@ static struct option options[] = {
>>  	{ "event", 1, NULL, 'e' },
>>  	{ "help", 0, NULL, 'H' },
>>  	{ "no-fork", 0, NULL, 'N' },
>> +	{ "priv-domid", 1, NULL, 'p' },
>>  	{ "output-pid", 0, NULL, 'P' },
>>  	{ "entry-size", 1, NULL, 'S' },
>>  	{ "trace-file", 1, NULL, 'T' },
>> @@ -1789,6 +1790,7 @@ static struct option options[] = {
>>  
>>  extern void dump_conn(struct connection *conn); 
>>  int dom0_event = 0;
>> +int priv_domid = 0;
>>  
>>  int main(int argc, char *argv[])
>>  {
>> @@ -1854,6 +1856,9 @@ int main(int argc, char *argv[])
>>  		case 'e':
>>  			dom0_event = strtol(optarg, NULL, 10);
>>  			break;
>> +		case 'p':
>> +			priv_domid = strtol(optarg, NULL, 10);
>> +			break;
>>  		}
>>  	}
>>  	if (optind != argc)
>> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
>> index d3040ba..03e2e48 100644
>> --- a/tools/xenstore/xenstored_core.h
>> +++ b/tools/xenstore/xenstored_core.h
>> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>>  
>>  extern int event_fd;
>>  extern int dom0_event;
>> +extern int priv_domid;
>>  
>>  /* Map the kernel's xenstore page. */
>>  void *xenbus_map(void);
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 5bf16e8..ba9a5ef 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
>>  
>>  bool domain_is_unprivileged(struct connection *conn)
>>  {
>> -	return (conn && conn->domain && conn->domain->domid != 0);
>> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
> 
> Is it deliberate / desirable that both dom0 and domPRIV are privileged
> when this option is used? Or should it be just one or the other, which
> is equivalent to removing the domid!=0 check since priv_domid defaults
> to 0.
> 
> Ian.
> 

Yes. In the cases where I used this, both dom0 and domPRIV are privileged.
Since dom0 needs to introduce domPRIV, and introduction is privileged, you
can't just have domPRIV be the only privileged domain. The ideal solution is
to have more fine-grained permissions than superuser-or-domU in xenstored,
but that is a different topic from moving xenstored into a stubdom.

-- 
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 Jan 12 15:37:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:37:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlMiN-00072j-Be; Thu, 12 Jan 2012 15:37:19 +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 1RlMiL-00072b-Rc
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:37:18 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326382630!10635968!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 21552 invoked from network); 12 Jan 2012 15:37:11 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 15:37: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
	q0CFb9dY017154; Thu, 12 Jan 2012 15:37:09 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 q0CFb937008512; 
	Thu, 12 Jan 2012 10:37:09 -0500
Message-ID: <4F0EFE22.6040006@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:37:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-19-git-send-email-dgdegra@tycho.nsa.gov>
	<1326363649.17210.234.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326363649.17210.234.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 18/18] xenstored: add --priv-domid 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

On 01/12/2012 05:20 AM, Ian Campbell wrote:
> On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
>> This parameter identifies an alternative service domain which has
>> superuser access to the xenstore database, which is currently required
>> to set up a new domain's xenstore entries.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/xenstored_core.c   |    5 +++++
>>  tools/xenstore/xenstored_core.h   |    1 +
>>  tools/xenstore/xenstored_domain.c |    2 +-
>>  3 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index 65ceb2c..4437c8d 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -1777,6 +1777,7 @@ static struct option options[] = {
>>  	{ "event", 1, NULL, 'e' },
>>  	{ "help", 0, NULL, 'H' },
>>  	{ "no-fork", 0, NULL, 'N' },
>> +	{ "priv-domid", 1, NULL, 'p' },
>>  	{ "output-pid", 0, NULL, 'P' },
>>  	{ "entry-size", 1, NULL, 'S' },
>>  	{ "trace-file", 1, NULL, 'T' },
>> @@ -1789,6 +1790,7 @@ static struct option options[] = {
>>  
>>  extern void dump_conn(struct connection *conn); 
>>  int dom0_event = 0;
>> +int priv_domid = 0;
>>  
>>  int main(int argc, char *argv[])
>>  {
>> @@ -1854,6 +1856,9 @@ int main(int argc, char *argv[])
>>  		case 'e':
>>  			dom0_event = strtol(optarg, NULL, 10);
>>  			break;
>> +		case 'p':
>> +			priv_domid = strtol(optarg, NULL, 10);
>> +			break;
>>  		}
>>  	}
>>  	if (optind != argc)
>> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
>> index d3040ba..03e2e48 100644
>> --- a/tools/xenstore/xenstored_core.h
>> +++ b/tools/xenstore/xenstored_core.h
>> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>>  
>>  extern int event_fd;
>>  extern int dom0_event;
>> +extern int priv_domid;
>>  
>>  /* Map the kernel's xenstore page. */
>>  void *xenbus_map(void);
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 5bf16e8..ba9a5ef 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
>>  
>>  bool domain_is_unprivileged(struct connection *conn)
>>  {
>> -	return (conn && conn->domain && conn->domain->domid != 0);
>> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
> 
> Is it deliberate / desirable that both dom0 and domPRIV are privileged
> when this option is used? Or should it be just one or the other, which
> is equivalent to removing the domid!=0 check since priv_domid defaults
> to 0.
> 
> Ian.
> 

Yes. In the cases where I used this, both dom0 and domPRIV are privileged.
Since dom0 needs to introduce domPRIV, and introduction is privileged, you
can't just have domPRIV be the only privileged domain. The ideal solution is
to have more fine-grained permissions than superuser-or-domU in xenstored,
but that is a different topic from moving xenstored into a stubdom.

-- 
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 Jan 12 15:39:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlMkG-00077F-SU; Thu, 12 Jan 2012 15:39:16 +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 1RlMkF-000773-4r
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:39:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326382748!10159718!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 916 invoked from network); 12 Jan 2012 15:39:08 -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; 12 Jan 2012 15:39:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 15:39:08 +0000
Message-Id: <4F0F0CE3020000780006C27E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 15:40:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EAF05020000780006C061@nat28.tlf.novell.com>
	<4F0EFC0B.9030600@tycho.nsa.gov>
In-Reply-To: <4F0EFC0B.9030600@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.01.12 at 16:28, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/12/2012 03:59 AM, Jan Beulich wrote:
>>>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
>>> xenbus backend to be started after the kernel has booted. This is
>>> intended to allow dom0 to start another domain to run xenstore.
>>>
>>> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
>>> started; the domain ID is passed as the ioctl argument. This sets up a
>>> listening event channel and grant reference to xenbus, but does not
>>> start using this interface. It returns the local event channel port.
>> 
>> Any chance to get at least the setup part matched with the
>> legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?
>> 
>> Jan
> 
> From what I can tell, the legacy ioctl cannot restore watches because the
> return value must be used to set up xenstore communication before they can
> be used.

Then I must have missed something. But this was the only kernel side
patch, wasn't it?

Is the intended behavior then to have a Dom0-based xenstored
starting first, then do a brain transfer to that running in a stub
domain? That certainly wasn't the behavior of what the legacy
Linux implementation was intended for...

> Or were you just asking if IOCTL_XENBUS_BACKEND_REMOTE_SETUP's parameter
> can be changed to xenbus_alloc_t?  That structure could be populated in the
> same way as the legacy implementation, but it wouldn't give any more
> information than the current ioctl does.

No, if it functionally differs, then we really should just care that
the ioctl numbers don't collide.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:39:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlMkG-00077F-SU; Thu, 12 Jan 2012 15:39:16 +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 1RlMkF-000773-4r
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:39:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326382748!10159718!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 916 invoked from network); 12 Jan 2012 15:39:08 -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; 12 Jan 2012 15:39:08 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 15:39:08 +0000
Message-Id: <4F0F0CE3020000780006C27E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 15:40:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EAF05020000780006C061@nat28.tlf.novell.com>
	<4F0EFC0B.9030600@tycho.nsa.gov>
In-Reply-To: <4F0EFC0B.9030600@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.01.12 at 16:28, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/12/2012 03:59 AM, Jan Beulich wrote:
>>>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
>>> xenbus backend to be started after the kernel has booted. This is
>>> intended to allow dom0 to start another domain to run xenstore.
>>>
>>> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
>>> started; the domain ID is passed as the ioctl argument. This sets up a
>>> listening event channel and grant reference to xenbus, but does not
>>> start using this interface. It returns the local event channel port.
>> 
>> Any chance to get at least the setup part matched with the
>> legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?
>> 
>> Jan
> 
> From what I can tell, the legacy ioctl cannot restore watches because the
> return value must be used to set up xenstore communication before they can
> be used.

Then I must have missed something. But this was the only kernel side
patch, wasn't it?

Is the intended behavior then to have a Dom0-based xenstored
starting first, then do a brain transfer to that running in a stub
domain? That certainly wasn't the behavior of what the legacy
Linux implementation was intended for...

> Or were you just asking if IOCTL_XENBUS_BACKEND_REMOTE_SETUP's parameter
> can be changed to xenbus_alloc_t?  That structure could be populated in the
> same way as the legacy implementation, but it wouldn't give any more
> information than the current ioctl does.

No, if it functionally differs, then we really should just care that
the ioctl numbers don't collide.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:42:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlMnD-0007GR-Mc; Thu, 12 Jan 2012 15:42:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1RlMn9-0007G1-JC
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:42:16 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326382928!7024797!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 6168 invoked from network); 12 Jan 2012 15:42:09 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 15:42:09 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1198A54229; Thu, 12 Jan 2012 16:42:06 +0100 (CET)
Date: Thu, 12 Jan 2012 16:42:06 +0100
From: Bastian Blank <waldi@debian.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120112154206.GA9722@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Jones <drjones@redhat.com>, konrad@darnok.org,
	jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	stefano stabellini <stefano.stabellini@eu.citrix.com>
References: <20120111172832.GB4449@phenom.dumpdata.com>
	<e37e8bec-f4ec-4420-81f0-da0ef90a6120@zmail13.collab.prod.int.phx2.redhat.com>
	<20120112143745.GE7685@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120112143745.GE7685@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad@darnok.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
 builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 09:37:45AM -0500, Konrad Rzeszutek Wilk wrote:
> Or is it possible to make the modules (fb) try to load xenbus frontend
> automatically? Preferrably one would do this:

Which modules?

> modprobe xen_fbfront
> which would then automatically load xenbus_module, xen_kbdfront

I think you are missing something.

| video/xen-fbfront.c:      return xenbus_register_frontend(&xenfb_driver);
| xen/xenbus/xenbus_probe_frontend.c:EXPORT_SYMBOL_GPL(xenbus_register_frontend);

xen-fbfront already pulls in the module, at least in Linus' tree.

> Better yet if udev/kudzu figured out this automtically and loaded
> the modules.

No workarounds for kernel problems if not absolutely necessary.

Bastian

-- 
Military secrets are the most fleeting of all.
		-- Spock, "The Enterprise Incident", stardate 5027.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:42:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlMnD-0007GR-Mc; Thu, 12 Jan 2012 15:42:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <waldi@debian.org>) id 1RlMn9-0007G1-JC
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:42:16 +0000
X-Env-Sender: waldi@debian.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326382928!7024797!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 6168 invoked from network); 12 Jan 2012 15:42:09 -0000
Received: from wavehammer.waldi.eu.org (HELO wavehammer.waldi.eu.org)
	(82.139.201.20)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 15:42:09 -0000
Received: by wavehammer.waldi.eu.org (Postfix, from userid 1000)
	id 1198A54229; Thu, 12 Jan 2012 16:42:06 +0100 (CET)
Date: Thu, 12 Jan 2012 16:42:06 +0100
From: Bastian Blank <waldi@debian.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120112154206.GA9722@wavehammer.waldi.eu.org>
Mail-Followup-To: Bastian Blank <waldi@debian.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Jones <drjones@redhat.com>, konrad@darnok.org,
	jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org,
	stefano stabellini <stefano.stabellini@eu.citrix.com>
References: <20120111172832.GB4449@phenom.dumpdata.com>
	<e37e8bec-f4ec-4420-81f0-da0ef90a6120@zmail13.collab.prod.int.phx2.redhat.com>
	<20120112143745.GE7685@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120112143745.GE7685@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	jeremy@goop.org, virtualization@lists.linux-foundation.org,
	konrad@darnok.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
 builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 09:37:45AM -0500, Konrad Rzeszutek Wilk wrote:
> Or is it possible to make the modules (fb) try to load xenbus frontend
> automatically? Preferrably one would do this:

Which modules?

> modprobe xen_fbfront
> which would then automatically load xenbus_module, xen_kbdfront

I think you are missing something.

| video/xen-fbfront.c:      return xenbus_register_frontend(&xenfb_driver);
| xen/xenbus/xenbus_probe_frontend.c:EXPORT_SYMBOL_GPL(xenbus_register_frontend);

xen-fbfront already pulls in the module, at least in Linus' tree.

> Better yet if udev/kudzu figured out this automtically and loaded
> the modules.

No workarounds for kernel problems if not absolutely necessary.

Bastian

-- 
Military secrets are the most fleeting of all.
		-- Spock, "The Enterprise Incident", stardate 5027.4

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15: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 1RlMt2-0007Uw-5i; Thu, 12 Jan 2012 15:48:20 +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 1RlMt1-0007Um-Fg
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:48:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326383291!8201112!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12262 invoked from network); 12 Jan 2012 15:48:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 15:48:12 -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
	q0CFm7Qe014083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 15:48: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
	q0CFm5Ts005308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 15:48:06 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CFm4D6025205; Thu, 12 Jan 2012 09:48:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 07:48:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D9FCB40306; Thu, 12 Jan 2012 10:46:13 -0500 (EST)
Date: Thu, 12 Jan 2012 10:46:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, kay.sievers@vrfy.org,
	linux-kernel@vger.kernel.org
Message-ID: <20120112154613.GA10148@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <498097597.20120112133832@eikelenboom.it>
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.4F0F00B8.00A8,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> 
> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.

Hey Kay,

Your patch that converts the xen-balloon to use the regular device bus driver
(070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.

The toolstack (xen-tools) use:

/sys/devices/system/xen_memory/xen_memory0

But with the change, it is now:

/sys/devices/xen_memory0/target_kb

Which means that the tools can't find it now.

I did not see anything in feature-removal-schedule.txt so I don't know
exactly when the full sys_device structure is going away.

Is there any work-arounds that can be inserted in the kernel so that
the old directory still exists at least for 3.3 such that there will be
enough time for the tool-stack to be updated?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15: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 1RlMt2-0007Uw-5i; Thu, 12 Jan 2012 15:48:20 +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 1RlMt1-0007Um-Fg
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:48:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326383291!8201112!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12262 invoked from network); 12 Jan 2012 15:48:12 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 15:48:12 -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
	q0CFm7Qe014083
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 15:48: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
	q0CFm5Ts005308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 15:48:06 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CFm4D6025205; Thu, 12 Jan 2012 09:48:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 07:48:04 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D9FCB40306; Thu, 12 Jan 2012 10:46:13 -0500 (EST)
Date: Thu, 12 Jan 2012 10:46:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>, kay.sievers@vrfy.org,
	linux-kernel@vger.kernel.org
Message-ID: <20120112154613.GA10148@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <498097597.20120112133832@eikelenboom.it>
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.4F0F00B8.00A8,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> Hi Konrad,
> 
> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> 
> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.

Hey Kay,

Your patch that converts the xen-balloon to use the regular device bus driver
(070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.

The toolstack (xen-tools) use:

/sys/devices/system/xen_memory/xen_memory0

But with the change, it is now:

/sys/devices/xen_memory0/target_kb

Which means that the tools can't find it now.

I did not see anything in feature-removal-schedule.txt so I don't know
exactly when the full sys_device structure is going away.

Is there any work-arounds that can be inserted in the kernel so that
the old directory still exists at least for 3.3 such that there will be
enough time for the tool-stack to be updated?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:50:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15: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 1RlMuh-0007ZU-RO; Thu, 12 Jan 2012 15:50: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 1RlMuf-0007ZL-3K
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:50:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326383285!59440514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2741 invoked from network); 12 Jan 2012 15:48:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 15:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9975327"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 15:49: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, 12 Jan 2012 15:49: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
	1RlMud-0002qj-Ky; Thu, 12 Jan 2012 15:49:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlMud-00020l-EP;
	Thu, 12 Jan 2012 15:49:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.292.66143.266122@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 15:49:56 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326367684.17210.245.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
	<1326367684.17210.245.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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/10] 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 07/10] libxl: New API for providing OS events to libxl"):
> It occurred to me just now that having a different type of this type of
> gc has the benefit that since libxl__event_occurred takes one it will
> necessarily filter back up the call chain and help enforce/highlight the
> requirement that functions which directly or indirectly call
> libxl__event_occurred use an egc.

Yes, exactly.  This is a very helpful consequence of using a different
type.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:50:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15: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 1RlMuh-0007ZU-RO; Thu, 12 Jan 2012 15:50: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 1RlMuf-0007ZL-3K
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:50:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326383285!59440514!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2741 invoked from network); 12 Jan 2012 15:48:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 15:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9975327"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 15:49: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, 12 Jan 2012 15:49: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
	1RlMud-0002qj-Ky; Thu, 12 Jan 2012 15:49:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlMud-00020l-EP;
	Thu, 12 Jan 2012 15:49:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.292.66143.266122@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 15:49:56 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326367684.17210.245.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
	<1326367684.17210.245.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>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/10] 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 07/10] libxl: New API for providing OS events to libxl"):
> It occurred to me just now that having a different type of this type of
> gc has the benefit that since libxl__event_occurred takes one it will
> necessarily filter back up the call chain and help enforce/highlight the
> requirement that functions which directly or indirectly call
> libxl__event_occurred use an egc.

Yes, exactly.  This is a very helpful consequence of using a different
type.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:56:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlN0t-0007or-PE; Thu, 12 Jan 2012 15:56: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 1RlN0s-0007om-Sj
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:56:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326383780!10711801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26945 invoked from network); 12 Jan 2012 15:56:20 -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 Jan 2012 15:56:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9975631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 15:56: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, 12 Jan 2012 15:56: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
	1RlN0Z-0002tB-8Z; Thu, 12 Jan 2012 15:56:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlN0Z-000223-7k;
	Thu, 12 Jan 2012 15:56:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.663.226738.385320@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 15:56:07 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1201111713490.3150@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 07/10] 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 07/10] libxl: New API for providing OS events to libxl"):
> I still prefer the approach prototyped in
> http://marc.info/?l=xen-devel&m=132371797519877: avoid introducing
> restrictions on how libxl functions have to be called, unify egc and gc,
> make it possible to take the lock recursively and use the nested counter
> to figure out when to call the callbacks.
> It would make my head hurt less when I have to read/write this code,
> however others might react differently.

I would agree with you if it were the case that editing general code
in libxl might involve adding new event-generating functions, or
indeed might involve turning existing functions into event-generating
ones.

But this is not the case.  The event-generating portions of the code
end up completely separate in any correct implementation - and someone
using this machinery doesn't even need to be very aware of this.

> Only one more thing: I would kindly ask to move all these event related
> functions to a different source file, to make it easier for people to
> understand which ones are different from the rest of the library.

They are, in libxl_event.c.  Unless by "event related" you meant
"event generating", in which case I disagree, because I don't think
that's the most relevant distinction.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:56:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlN0t-0007or-PE; Thu, 12 Jan 2012 15:56: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 1RlN0s-0007om-Sj
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:56:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326383780!10711801!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26945 invoked from network); 12 Jan 2012 15:56:20 -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 Jan 2012 15:56:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9975631"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 15:56: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, 12 Jan 2012 15:56: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
	1RlN0Z-0002tB-8Z; Thu, 12 Jan 2012 15:56:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlN0Z-000223-7k;
	Thu, 12 Jan 2012 15:56:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.663.226738.385320@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 15:56:07 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201111713490.3150@kaball-desktop>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<alpine.DEB.2.00.1201111713490.3150@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 07/10] 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 07/10] libxl: New API for providing OS events to libxl"):
> I still prefer the approach prototyped in
> http://marc.info/?l=xen-devel&m=132371797519877: avoid introducing
> restrictions on how libxl functions have to be called, unify egc and gc,
> make it possible to take the lock recursively and use the nested counter
> to figure out when to call the callbacks.
> It would make my head hurt less when I have to read/write this code,
> however others might react differently.

I would agree with you if it were the case that editing general code
in libxl might involve adding new event-generating functions, or
indeed might involve turning existing functions into event-generating
ones.

But this is not the case.  The event-generating portions of the code
end up completely separate in any correct implementation - and someone
using this machinery doesn't even need to be very aware of this.

> Only one more thing: I would kindly ask to move all these event related
> functions to a different source file, to make it easier for people to
> understand which ones are different from the rest of the library.

They are, in libxl_event.c.  Unless by "event related" you meant
"event generating", in which case I disagree, because I don't think
that's the most relevant distinction.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 15:59:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:59:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlN3X-0007wm-GH; Thu, 12 Jan 2012 15:59: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 1RlN3V-0007wb-D1
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:59:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326383942!10664812!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 4543 invoked from network); 12 Jan 2012 15:59:03 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 15:59:03 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CFx1Hm020296; Thu, 12 Jan 2012 15:59:01 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 q0CFx1px009954; 
	Thu, 12 Jan 2012 10:59:01 -0500
Message-ID: <4F0F0342.7080105@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:58:58 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EAF05020000780006C061@nat28.tlf.novell.com>
	<4F0EFC0B.9030600@tycho.nsa.gov>
	<4F0F0CE3020000780006C27E@nat28.tlf.novell.com>
In-Reply-To: <4F0F0CE3020000780006C27E@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2012 10:40 AM, Jan Beulich wrote:
>>>> On 12.01.12 at 16:28, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 01/12/2012 03:59 AM, Jan Beulich wrote:
>>>>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
>>>> xenbus backend to be started after the kernel has booted. This is
>>>> intended to allow dom0 to start another domain to run xenstore.
>>>>
>>>> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
>>>> started; the domain ID is passed as the ioctl argument. This sets up a
>>>> listening event channel and grant reference to xenbus, but does not
>>>> start using this interface. It returns the local event channel port.
>>>
>>> Any chance to get at least the setup part matched with the
>>> legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?
>>>
>>> Jan
>>
>> From what I can tell, the legacy ioctl cannot restore watches because the
>> return value must be used to set up xenstore communication before they can
>> be used.
> 
> Then I must have missed something. But this was the only kernel side
> patch, wasn't it?
> 
> Is the intended behavior then to have a Dom0-based xenstored
> starting first, then do a brain transfer to that running in a stub
> domain? That certainly wasn't the behavior of what the legacy
> Linux implementation was intended for...
> 
>> Or were you just asking if IOCTL_XENBUS_BACKEND_REMOTE_SETUP's parameter
>> can be changed to xenbus_alloc_t?  That structure could be populated in the
>> same way as the legacy implementation, but it wouldn't give any more
>> information than the current ioctl does.
> 
> No, if it functionally differs, then we really should just care that
> the ioctl numbers don't collide.
> 
> Jan
> 

I think this depends on how the xenstore domain is constructed: if it is
started instead of the dom0-based xenstored (not the current method, but
converting init-xenstored to create the domain itself should make this
possible) then the setup/commit split of the ioctl is not needed. In that
case the older ioctl name/interface can be preserved (although the grant
field will always be populated with 1).

-- 
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 Jan 12 15:59:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 15:59:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlN3X-0007wm-GH; Thu, 12 Jan 2012 15:59: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 1RlN3V-0007wb-D1
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 15:59:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326383942!10664812!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 4543 invoked from network); 12 Jan 2012 15:59:03 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 15:59:03 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CFx1Hm020296; Thu, 12 Jan 2012 15:59:01 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 q0CFx1px009954; 
	Thu, 12 Jan 2012 10:59:01 -0500
Message-ID: <4F0F0342.7080105@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 10:58:58 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302529-19476-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EAF05020000780006C061@nat28.tlf.novell.com>
	<4F0EFC0B.9030600@tycho.nsa.gov>
	<4F0F0CE3020000780006C27E@nat28.tlf.novell.com>
In-Reply-To: <4F0F0CE3020000780006C27E@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2012 10:40 AM, Jan Beulich wrote:
>>>> On 12.01.12 at 16:28, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 01/12/2012 03:59 AM, Jan Beulich wrote:
>>>>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
>>>> xenbus backend to be started after the kernel has booted. This is
>>>> intended to allow dom0 to start another domain to run xenstore.
>>>>
>>>> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
>>>> started; the domain ID is passed as the ioctl argument. This sets up a
>>>> listening event channel and grant reference to xenbus, but does not
>>>> start using this interface. It returns the local event channel port.
>>>
>>> Any chance to get at least the setup part matched with the
>>> legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?
>>>
>>> Jan
>>
>> From what I can tell, the legacy ioctl cannot restore watches because the
>> return value must be used to set up xenstore communication before they can
>> be used.
> 
> Then I must have missed something. But this was the only kernel side
> patch, wasn't it?
> 
> Is the intended behavior then to have a Dom0-based xenstored
> starting first, then do a brain transfer to that running in a stub
> domain? That certainly wasn't the behavior of what the legacy
> Linux implementation was intended for...
> 
>> Or were you just asking if IOCTL_XENBUS_BACKEND_REMOTE_SETUP's parameter
>> can be changed to xenbus_alloc_t?  That structure could be populated in the
>> same way as the legacy implementation, but it wouldn't give any more
>> information than the current ioctl does.
> 
> No, if it functionally differs, then we really should just care that
> the ioctl numbers don't collide.
> 
> Jan
> 

I think this depends on how the xenstore domain is constructed: if it is
started instead of the dom0-based xenstored (not the current method, but
converting init-xenstored to create the domain itself should make this
possible) then the setup/commit split of the ioctl is not needed. In that
case the older ioctl name/interface can be preserved (although the grant
field will always be populated with 1).

-- 
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 Jan 12 16:05:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlN8t-00009x-9S; Thu, 12 Jan 2012 16:04: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 1RlN8s-00009r-JJ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:04:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326384275!10763256!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTgwNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27453 invoked from network); 12 Jan 2012 16:04:35 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 16:04:35 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 3BB7D604076;
	Thu, 12 Jan 2012 08:04: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=YBjKs4op9ExNaQ5PfhTWxfKVlPeFZACwD0DZi+CWVsop
	T5j5tMurBmpj3ktvyBg5PJIag9bQyUWLDm8OfUppFykkxHhUvVyNS590RLnQ8WD0
	teP+9OAUdFfXqaK2QI6ehut1tkXvrF1f9zYyAxu6tdsPZ4GE8WDIsp21n8b/spY=
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=q9q8lplSp3IT81nXiyaPA3R6BK4=; b=U0LQmdTi
	fZ7+ZQkb0V5lQRG+xGZFSv3wtk4NBBQpmScgL55c79QlGd7SiGFj1U4dA2zFogqO
	6pbOL5sfiPBBBlooIQ0ukd79GOVF47jTiNLWSj1SkMAtXV9s56B6eMTWaoYpVnnX
	E5+Hr5y82VY+Az4gouqEyjaqjks5tO7n/2c=
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 D03A5604089; 
	Thu, 12 Jan 2012 08:04:33 -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, 12 Jan 2012 08:04:34 -0800
Message-ID: <e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120112144325.GE8324@aepfle.de>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
	<20120112144325.GE8324@aepfle.de>
Date: Thu, 12 Jan 2012 08:04: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, 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] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
>> +++ b/xen/include/public/domctl.h
>
>> +/* Use for teardown/setup of helper<->hypervisor interface for paging,
>> + * access and sharing.*/
>>  struct xen_domctl_mem_event_op {
>>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
>>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
>>
>> -    union {
>> -        /* OP_ENABLE IN:  Virtual address of shared page */
>> -        uint64_aligned_t shared_addr;
>> -        /* PAGING_PREP IN: buffer to immediately fill page in */
>> -        uint64_aligned_t buffer;
>> -    } u;
>> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
>> page */
>>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page
>> */
>>
>> -    /* Other OPs */
>> -    uint64_aligned_t gfn;          /* IN:  gfn of page being operated
>> on */
>> +    /* For binary backwards compatibility */
>> +    uint64_aligned_t pad;
>>  };
>
> Assuming this struct is routed through libxc, and libxc gets a new
> SONAME for every release, doesnt this mean that every old binary has to
> be recompiled anyway for the new release?
> If so, the padding is not needed.
Agreed, basically. Waiting to hear from tools maintainers about best
approach to libxc.

It seems that there aren't that many users relying on a fixed ABI, so we
can (still, until 4.2) change things. But obviously I want to be careful.

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 Jan 12 16:05:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlN8t-00009x-9S; Thu, 12 Jan 2012 16:04: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 1RlN8s-00009r-JJ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:04:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326384275!10763256!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTgwNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27453 invoked from network); 12 Jan 2012 16:04:35 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-7.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 16:04:35 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 3BB7D604076;
	Thu, 12 Jan 2012 08:04: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=YBjKs4op9ExNaQ5PfhTWxfKVlPeFZACwD0DZi+CWVsop
	T5j5tMurBmpj3ktvyBg5PJIag9bQyUWLDm8OfUppFykkxHhUvVyNS590RLnQ8WD0
	teP+9OAUdFfXqaK2QI6ehut1tkXvrF1f9zYyAxu6tdsPZ4GE8WDIsp21n8b/spY=
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=q9q8lplSp3IT81nXiyaPA3R6BK4=; b=U0LQmdTi
	fZ7+ZQkb0V5lQRG+xGZFSv3wtk4NBBQpmScgL55c79QlGd7SiGFj1U4dA2zFogqO
	6pbOL5sfiPBBBlooIQ0ukd79GOVF47jTiNLWSj1SkMAtXV9s56B6eMTWaoYpVnnX
	E5+Hr5y82VY+Az4gouqEyjaqjks5tO7n/2c=
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 D03A5604089; 
	Thu, 12 Jan 2012 08:04:33 -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, 12 Jan 2012 08:04:34 -0800
Message-ID: <e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120112144325.GE8324@aepfle.de>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
	<20120112144325.GE8324@aepfle.de>
Date: Thu, 12 Jan 2012 08:04: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, 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] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
>> +++ b/xen/include/public/domctl.h
>
>> +/* Use for teardown/setup of helper<->hypervisor interface for paging,
>> + * access and sharing.*/
>>  struct xen_domctl_mem_event_op {
>>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
>>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
>>
>> -    union {
>> -        /* OP_ENABLE IN:  Virtual address of shared page */
>> -        uint64_aligned_t shared_addr;
>> -        /* PAGING_PREP IN: buffer to immediately fill page in */
>> -        uint64_aligned_t buffer;
>> -    } u;
>> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
>> page */
>>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page
>> */
>>
>> -    /* Other OPs */
>> -    uint64_aligned_t gfn;          /* IN:  gfn of page being operated
>> on */
>> +    /* For binary backwards compatibility */
>> +    uint64_aligned_t pad;
>>  };
>
> Assuming this struct is routed through libxc, and libxc gets a new
> SONAME for every release, doesnt this mean that every old binary has to
> be recompiled anyway for the new release?
> If so, the padding is not needed.
Agreed, basically. Waiting to hear from tools maintainers about best
approach to libxc.

It seems that there aren't that many users relying on a fixed ABI, so we
can (still, until 4.2) change things. But obviously I want to be careful.

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 Jan 12 16:05:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlN9k-0000Ch-Nf; Thu, 12 Jan 2012 16:05:36 +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 1RlN9i-0000CK-Po
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:05:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326384326!10782281!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTczODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25611 invoked from network); 12 Jan 2012 16:05:27 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 16:05:27 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id AD85B1A8083;
	Thu, 12 Jan 2012 08:05:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=c4KoY4mMqf2q1R2RJ43SmaHcc++I48Cg70pNV90+eBtU
	CqftQ/JLiuEvA1SUbd7ZvtNbi1DWwAFccREeGjgtC0IYg+S/FoWZ/LCj7bZnPXKG
	KT8ObnvCOgt15fWHT5dk0DWoKIdM3TUFkQroW0pQ8Jkkuu06Z5VsJAKHK4dG8oU=
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=/OhKAx/0yBC439HV6rljy5mLTu4=; b=uJRKCNva
	IpcbFE1ve4JR5k5Z51k013XbHLxbEHEK3QmTCgRy5IAEvXnkNd2GwXHb6lOXQfNN
	l1CwKN1LBfKGIteCDfjjyZXpYE4+u6y9IZc16it1/rQ0JWlvjV5pV7MHVz02zDd6
	ICubP4lczs6td06gS3hxEf0yZqLrfeqxSuk=
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 4C2721A8076; 
	Thu, 12 Jan 2012 08:05: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;
	Thu, 12 Jan 2012 08:05:25 -0800
Message-ID: <0afb7b5e0fa7e9a12676a548a8a8ac5a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120112115650.GD47092@ocelot.phlegethon.org>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120112115650.GD47092@ocelot.phlegethon.org>
Date: Thu, 12 Jan 2012 08:05:25 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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

> Hi,
>
> This looks fine to me; this time I'd like Olaf to review and test it
> before I commit it. :)
>
> A few comments inline below -- mostly nits about style.

Great, will address them -- once Olaf gives us a green light.
Andres

>
> At 13:28 -0500 on 11 Jan (1326288504), Andres Lagar-Cavilla wrote:
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Housekeeping: please keep Olaf's Signed-off-by: line to cover the parts
> of this patch that he's certifying.
>
>> diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4188,25 +4188,31 @@ static int hvm_memory_event_traps(long p
>>                                    unsigned long value, unsigned long
>> old,
>>                                    bool_t gla_valid, unsigned long gla)
>>  {
>> +    int rc;
>>      struct vcpu* v = current;
>>      struct domain *d = v->domain;
>>      mem_event_request_t req;
>> -    int rc;
>>
>
> Please try to avoid this kind of unrelated shuffling (and I saw some
> whitespace changes later on as well).  It's not a big deal, but it makes
> reviewing a bit easier and avoids unnecessarily clashing with other
> patches.
>
>> diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/mm/mem_event.c
>> --- a/xen/arch/x86/mm/mem_event.c
>> +++ b/xen/arch/x86/mm/mem_event.c
>
>> +
>> +/*
>> + * mem_event_wake_requesters() will wakeup vcpus waiting for room in
>> the
>
> DYM mem_event_wake_blocked() ?
>
>> + * ring. These vCPUs were paused on their way out after placing an
>> event,
>> + * but need to be resumed where the ring is capable of processing at
>> least
>> + * one event from them.
>> + */
>> +static void mem_event_wake_blocked(struct domain *d, struct
>> mem_event_domain *med)
>> +{
>> +    struct vcpu *v;
>> +    int online = d->max_vcpus;
>> +    int avail_req = mem_event_ring_available(med);
>> +
>> +    if( avail_req <= 0 || med->blocked == 0 )
>
> s/if(/if (/
>
>> +        return;
>> +
>> +    /*
>> +     * We ensure that we only have vCPUs online if there are enough
>> free slots
>> +     * for their memory events to be processed.  This will ensure that
>> no
>> +     * memory events are lost (due to the fact that certain types of
>> events
>> +     * cannot be replayed, we need to ensure that there is space in the
>> ring
>> +     * for when they are hit).
>> +     * See comment below in mem_event_put_request().
>> +     */
>> +    for_each_vcpu ( d, v )
>> +        if ( test_bit(med->pause_flag, &v->pause_flags) )
>> +            online--;
>> +
>> +    ASSERT(online == (d->max_vcpus - med->blocked));
>
> Maybe better to do the cheap calculation as the default and the more
> expensive one for the ASSERT?
>
>> +    /* We remember which vcpu last woke up to avoid scanning always
>> linearly
>> +     * from zero and starving higher-numbered vcpus under high load */
>> +    if ( d->vcpu )
>> +    {
>> +        int i, j, k;
>> +
>> +        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus;
>> i++, j++)
>> +        {
>> +            k = i % d->max_vcpus;
>> +            v = d->vcpu[k];
>> +            if ( !v )
>> +                continue;
>> +
>> +            if ( !(med->blocked) || online >= avail_req )
>> +               break;
>> +
>> +            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
>> +            {
>> +                vcpu_unpause(v);
>> +                online++;
>> +                med->blocked--;
>> +                med->last_vcpu_wake_up = k;
>> +            }
>> +        }
>> +    }
>> +}
>> +
>> +/*
>> + * In the event that a vCPU attempted to place an event in the ring and
>> + * was unable to do so, it is queued on a wait queue.  These are woken
>> as
>> + * needed, and take precedence over the blocked vCPUs.
>> + */
>> +static void mem_event_wake_queued(struct domain *d, struct
>> mem_event_domain *med)
>> +{
>> +    int avail_req = mem_event_ring_available(med);
>> +
>> +    if ( avail_req > 0 )
>> +        wake_up_nr(&med->wq, avail_req);
>> +}
>> +
>> +/*
>> + * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring
>> to
>
> DYM mem_event_wake() ?
>
>> + * become available.  If we have queued vCPUs, they get top priority.
>> We
>> + * are guaranteed that they will go through code paths that will
>> eventually
>> + * call mem_event_wake() again, ensuring that any blocked vCPUs will
>> get
>> + * unpaused once all the queued vCPUs have made it through.
>> + */
>> +void mem_event_wake(struct domain *d, struct mem_event_domain *med)
>> +{
>> +    if (!list_empty(&med->wq.list))
>> +        mem_event_wake_queued(d, med);
>> +    else
>> +        mem_event_wake_blocked(d, med);
>> +}
>> +
>> +static int mem_event_disable(struct domain *d, struct mem_event_domain
>> *med)
>> +{
>> +    if( med->ring_page )
>
> s/if(/if (/g  :)
>
>> +    {
>> +        struct vcpu *v;
>> +
>> +        mem_event_ring_lock(med);
>> +
>> +        if (!list_empty(&med->wq.list))
>
> if ( ... )
>
>> +        {
>> +            mem_event_ring_unlock(med);
>> +            return -EBUSY;
>> +        }
>> +
>> +        unmap_domain_page(med->ring_page);
>> +        med->ring_page = NULL;
>> +
>> +        unmap_domain_page(med->shared_page);
>> +        med->shared_page = NULL;
>> +
>> +        /* Wake up everybody */
>> +        wake_up_all(&med->wq);
>> +
>> +        /* Unblock all vCPUs */
>> +        for_each_vcpu ( d, v )
>> +        {
>> +            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
>> +            {
>> +                vcpu_unpause(v);
>> +                med->blocked--;
>> +            }
>> +        }
>> +
>> +        mem_event_ring_unlock(med);
>> +    }
>>
>>      return 0;
>>  }
>>
>> -void mem_event_put_request(struct domain *d, struct mem_event_domain
>> *med, mem_event_request_t *req)
>> +static inline void mem_event_release_slot(struct domain *d,
>> +                                          struct mem_event_domain *med)
>> +{
>> +    /* Update the accounting */
>> +    if ( current->domain == d )
>> +        med->target_producers--;
>> +    else
>> +        med->foreign_producers--;
>> +
>> +    /* Kick any waiters */
>> +    mem_event_wake(d, med);
>> +}
>> +
>> +/*
>> + * mem_event_mark_and_pause() tags vcpu and put it to sleep.
>> + * The vcpu will resume execution in mem_event_wake_waiters().
>> + */
>> +void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain
>> *med)
>> +{
>> +    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
>> +    {
>> +        vcpu_pause_nosync(v);
>> +        med->blocked++;
>> +    }
>> +}
>> +
>> +/*
>> + * This must be preceeded by a call to claim_slot(), and is guaranteed
>> to
>
> preceded
>
> 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 Jan 12 16:05:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlN9k-0000Ch-Nf; Thu, 12 Jan 2012 16:05:36 +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 1RlN9i-0000CK-Po
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:05:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326384326!10782281!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTczODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25611 invoked from network); 12 Jan 2012 16:05:27 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 16:05:27 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id AD85B1A8083;
	Thu, 12 Jan 2012 08:05:25 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=c4KoY4mMqf2q1R2RJ43SmaHcc++I48Cg70pNV90+eBtU
	CqftQ/JLiuEvA1SUbd7ZvtNbi1DWwAFccREeGjgtC0IYg+S/FoWZ/LCj7bZnPXKG
	KT8ObnvCOgt15fWHT5dk0DWoKIdM3TUFkQroW0pQ8Jkkuu06Z5VsJAKHK4dG8oU=
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=/OhKAx/0yBC439HV6rljy5mLTu4=; b=uJRKCNva
	IpcbFE1ve4JR5k5Z51k013XbHLxbEHEK3QmTCgRy5IAEvXnkNd2GwXHb6lOXQfNN
	l1CwKN1LBfKGIteCDfjjyZXpYE4+u6y9IZc16it1/rQ0JWlvjV5pV7MHVz02zDd6
	ICubP4lczs6td06gS3hxEf0yZqLrfeqxSuk=
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 4C2721A8076; 
	Thu, 12 Jan 2012 08:05: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;
	Thu, 12 Jan 2012 08:05:25 -0800
Message-ID: <0afb7b5e0fa7e9a12676a548a8a8ac5a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120112115650.GD47092@ocelot.phlegethon.org>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120112115650.GD47092@ocelot.phlegethon.org>
Date: Thu, 12 Jan 2012 08:05:25 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, olaf@aepfle.de,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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

> Hi,
>
> This looks fine to me; this time I'd like Olaf to review and test it
> before I commit it. :)
>
> A few comments inline below -- mostly nits about style.

Great, will address them -- once Olaf gives us a green light.
Andres

>
> At 13:28 -0500 on 11 Jan (1326288504), Andres Lagar-Cavilla wrote:
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Housekeeping: please keep Olaf's Signed-off-by: line to cover the parts
> of this patch that he's certifying.
>
>> diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/hvm/hvm.c
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4188,25 +4188,31 @@ static int hvm_memory_event_traps(long p
>>                                    unsigned long value, unsigned long
>> old,
>>                                    bool_t gla_valid, unsigned long gla)
>>  {
>> +    int rc;
>>      struct vcpu* v = current;
>>      struct domain *d = v->domain;
>>      mem_event_request_t req;
>> -    int rc;
>>
>
> Please try to avoid this kind of unrelated shuffling (and I saw some
> whitespace changes later on as well).  It's not a big deal, but it makes
> reviewing a bit easier and avoids unnecessarily clashing with other
> patches.
>
>> diff -r d3342b370b6f -r a85e7d46401b xen/arch/x86/mm/mem_event.c
>> --- a/xen/arch/x86/mm/mem_event.c
>> +++ b/xen/arch/x86/mm/mem_event.c
>
>> +
>> +/*
>> + * mem_event_wake_requesters() will wakeup vcpus waiting for room in
>> the
>
> DYM mem_event_wake_blocked() ?
>
>> + * ring. These vCPUs were paused on their way out after placing an
>> event,
>> + * but need to be resumed where the ring is capable of processing at
>> least
>> + * one event from them.
>> + */
>> +static void mem_event_wake_blocked(struct domain *d, struct
>> mem_event_domain *med)
>> +{
>> +    struct vcpu *v;
>> +    int online = d->max_vcpus;
>> +    int avail_req = mem_event_ring_available(med);
>> +
>> +    if( avail_req <= 0 || med->blocked == 0 )
>
> s/if(/if (/
>
>> +        return;
>> +
>> +    /*
>> +     * We ensure that we only have vCPUs online if there are enough
>> free slots
>> +     * for their memory events to be processed.  This will ensure that
>> no
>> +     * memory events are lost (due to the fact that certain types of
>> events
>> +     * cannot be replayed, we need to ensure that there is space in the
>> ring
>> +     * for when they are hit).
>> +     * See comment below in mem_event_put_request().
>> +     */
>> +    for_each_vcpu ( d, v )
>> +        if ( test_bit(med->pause_flag, &v->pause_flags) )
>> +            online--;
>> +
>> +    ASSERT(online == (d->max_vcpus - med->blocked));
>
> Maybe better to do the cheap calculation as the default and the more
> expensive one for the ASSERT?
>
>> +    /* We remember which vcpu last woke up to avoid scanning always
>> linearly
>> +     * from zero and starving higher-numbered vcpus under high load */
>> +    if ( d->vcpu )
>> +    {
>> +        int i, j, k;
>> +
>> +        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus;
>> i++, j++)
>> +        {
>> +            k = i % d->max_vcpus;
>> +            v = d->vcpu[k];
>> +            if ( !v )
>> +                continue;
>> +
>> +            if ( !(med->blocked) || online >= avail_req )
>> +               break;
>> +
>> +            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
>> +            {
>> +                vcpu_unpause(v);
>> +                online++;
>> +                med->blocked--;
>> +                med->last_vcpu_wake_up = k;
>> +            }
>> +        }
>> +    }
>> +}
>> +
>> +/*
>> + * In the event that a vCPU attempted to place an event in the ring and
>> + * was unable to do so, it is queued on a wait queue.  These are woken
>> as
>> + * needed, and take precedence over the blocked vCPUs.
>> + */
>> +static void mem_event_wake_queued(struct domain *d, struct
>> mem_event_domain *med)
>> +{
>> +    int avail_req = mem_event_ring_available(med);
>> +
>> +    if ( avail_req > 0 )
>> +        wake_up_nr(&med->wq, avail_req);
>> +}
>> +
>> +/*
>> + * mem_event_wake_waiters() will wakeup all vcpus waiting for the ring
>> to
>
> DYM mem_event_wake() ?
>
>> + * become available.  If we have queued vCPUs, they get top priority.
>> We
>> + * are guaranteed that they will go through code paths that will
>> eventually
>> + * call mem_event_wake() again, ensuring that any blocked vCPUs will
>> get
>> + * unpaused once all the queued vCPUs have made it through.
>> + */
>> +void mem_event_wake(struct domain *d, struct mem_event_domain *med)
>> +{
>> +    if (!list_empty(&med->wq.list))
>> +        mem_event_wake_queued(d, med);
>> +    else
>> +        mem_event_wake_blocked(d, med);
>> +}
>> +
>> +static int mem_event_disable(struct domain *d, struct mem_event_domain
>> *med)
>> +{
>> +    if( med->ring_page )
>
> s/if(/if (/g  :)
>
>> +    {
>> +        struct vcpu *v;
>> +
>> +        mem_event_ring_lock(med);
>> +
>> +        if (!list_empty(&med->wq.list))
>
> if ( ... )
>
>> +        {
>> +            mem_event_ring_unlock(med);
>> +            return -EBUSY;
>> +        }
>> +
>> +        unmap_domain_page(med->ring_page);
>> +        med->ring_page = NULL;
>> +
>> +        unmap_domain_page(med->shared_page);
>> +        med->shared_page = NULL;
>> +
>> +        /* Wake up everybody */
>> +        wake_up_all(&med->wq);
>> +
>> +        /* Unblock all vCPUs */
>> +        for_each_vcpu ( d, v )
>> +        {
>> +            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
>> +            {
>> +                vcpu_unpause(v);
>> +                med->blocked--;
>> +            }
>> +        }
>> +
>> +        mem_event_ring_unlock(med);
>> +    }
>>
>>      return 0;
>>  }
>>
>> -void mem_event_put_request(struct domain *d, struct mem_event_domain
>> *med, mem_event_request_t *req)
>> +static inline void mem_event_release_slot(struct domain *d,
>> +                                          struct mem_event_domain *med)
>> +{
>> +    /* Update the accounting */
>> +    if ( current->domain == d )
>> +        med->target_producers--;
>> +    else
>> +        med->foreign_producers--;
>> +
>> +    /* Kick any waiters */
>> +    mem_event_wake(d, med);
>> +}
>> +
>> +/*
>> + * mem_event_mark_and_pause() tags vcpu and put it to sleep.
>> + * The vcpu will resume execution in mem_event_wake_waiters().
>> + */
>> +void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain
>> *med)
>> +{
>> +    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
>> +    {
>> +        vcpu_pause_nosync(v);
>> +        med->blocked++;
>> +    }
>> +}
>> +
>> +/*
>> + * This must be preceeded by a call to claim_slot(), and is guaranteed
>> to
>
> preceded
>
> 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 Jan 12 16:06:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:06:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNAD-0000Gf-5D; Thu, 12 Jan 2012 16:06:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kay.sievers@vrfy.org>) id 1RlNAB-0000G0-Ih
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:06:03 +0000
X-Env-Sender: kay.sievers@vrfy.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326384355!10116680!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 16822 invoked from network); 12 Jan 2012 16:05:57 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:05:57 -0000
Received: by pbcc6 with SMTP id c6so3742724pbc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrfy.org; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=sQuw/eQeDPrMQDeJA6Y9hu4gm2nNm0iR1Q1SaSt89Tc=;
	b=LNpqqWylAGCv/oGB8zSxsvxR+2Dsnh60VLRYUwo+Lg18BSBeP+ENf9WGPyLcNAJZO5
	fKoriU6aHFVfu3nhcW5R36eI3QgcQXRq1wnDUlNksg6WcB0ImRXepr1VVkxPJD2ihARS
	MCMTqPDLjkxRai+QeXRnEKKHh36EXRlGc4qO4=
Received: by 10.68.74.230 with SMTP id x6mr9319591pbv.49.1326384355363; Thu,
	12 Jan 2012 08:05:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.34.14 with HTTP; Thu, 12 Jan 2012 08:05:34 -0800 (PST)
In-Reply-To: <20120112154613.GA10148@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu, 12 Jan 2012 17:05:34 +0100
Message-ID: <CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:

>> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
>>
>> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
>> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
> Your patch that converts the xen-balloon to use the regular device bus driver
> (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
>
> The toolstack (xen-tools) use:
>
> /sys/devices/system/xen_memory/xen_memory0
>
> But with the change, it is now:
>
> /sys/devices/xen_memory0/target_kb

Urks, seems like a mistake on my side.

Please try if changing:
  bus_unregister(&balloon_subsys);
to:
  subsys_system_register(&balloon_subsys, NULL);
in:
  drivers/xen/xen-balloon.c
fixes the issue.

Sorry for that,
Kay

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:06:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:06:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNAD-0000Gf-5D; Thu, 12 Jan 2012 16:06:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kay.sievers@vrfy.org>) id 1RlNAB-0000G0-Ih
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:06:03 +0000
X-Env-Sender: kay.sievers@vrfy.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326384355!10116680!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 16822 invoked from network); 12 Jan 2012 16:05:57 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:05:57 -0000
Received: by pbcc6 with SMTP id c6so3742724pbc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:05:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrfy.org; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=sQuw/eQeDPrMQDeJA6Y9hu4gm2nNm0iR1Q1SaSt89Tc=;
	b=LNpqqWylAGCv/oGB8zSxsvxR+2Dsnh60VLRYUwo+Lg18BSBeP+ENf9WGPyLcNAJZO5
	fKoriU6aHFVfu3nhcW5R36eI3QgcQXRq1wnDUlNksg6WcB0ImRXepr1VVkxPJD2ihARS
	MCMTqPDLjkxRai+QeXRnEKKHh36EXRlGc4qO4=
Received: by 10.68.74.230 with SMTP id x6mr9319591pbv.49.1326384355363; Thu,
	12 Jan 2012 08:05:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.34.14 with HTTP; Thu, 12 Jan 2012 08:05:34 -0800 (PST)
In-Reply-To: <20120112154613.GA10148@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu, 12 Jan 2012 17:05:34 +0100
Message-ID: <CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:

>> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
>>
>> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
>> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
> Your patch that converts the xen-balloon to use the regular device bus driver
> (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
>
> The toolstack (xen-tools) use:
>
> /sys/devices/system/xen_memory/xen_memory0
>
> But with the change, it is now:
>
> /sys/devices/xen_memory0/target_kb

Urks, seems like a mistake on my side.

Please try if changing:
  bus_unregister(&balloon_subsys);
to:
  subsys_system_register(&balloon_subsys, NULL);
in:
  drivers/xen/xen-balloon.c
fixes the issue.

Sorry for that,
Kay

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:10:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:10:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNEe-0000by-Tm; Thu, 12 Jan 2012 16:10:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RlNEd-0000bp-4e
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:10:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326384616!52575366!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjQ0OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3449 invoked from network); 12 Jan 2012 16:10:16 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 16:10:16 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id F0EDF4B0084;
	Thu, 12 Jan 2012 08:10: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=uD+0jfU4QtdUNh9YGSqAUAUoiACFC94lgTI/8BuOheMG
	SaZbLT237tRgnwBtzE1rzyg2KLb4yNqe07Lom5i61DVkwHpYREUXby8td3JII9mu
	SEeXm6nTMYgZzLj4lyXyXPToOCtjGQU0kBZB7tClNmgNzvICrzTXshRL9qIDhsc=
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=AMo17RYp7tgKYKWGf++d7I/TIZs=; b=h1rDi1vP
	+rWTawoNhidIUd/yvJGrmwrjQ349FhudbUnHVpusgN1bSvjQcwAGSaqvT38c2RLO
	KzTgHsoVOlCdBxsyRUICzfKeVRCvaTL0CBwfaXyPOxOJOlA86U5IgW/2i/Lp/N6J
	FzrcuyyXNT0TjDrYJy3fnEIBEnjlQsqhjyM=
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 AE1B34B006D; 
	Thu, 12 Jan 2012 08:10:36 -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, 12 Jan 2012 08:11:42 -0800
Message-ID: <cfc86d79380e4f7f4ba88de9794877c8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120112135945.GA8324@aepfle.de>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
	<63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
	<20120112135945.GA8324@aepfle.de>
Date: Thu, 12 Jan 2012 08:11:42 -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 Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
>> > mem_event: use wait queue when ring is full
>> >
>> > This change is based on an idea/patch from Adin Scannell.
>>
>> Olaf,
>> thanks for the post. We'll have to nack this patch in its current form.
>> It
>> hard reboots our host during our testing.
>
> Thats very unfortunate. I have seen such unexpected reboots myself a few
> weeks ago. I suspect they were caused by an incorrect debug change which
> I had on top of my waitqueue changes. Also the fixes Keir provided a few
> weeks ago may have helped.
>
> Is it an otherwise unmodified xen-unstable build, or do you use other
> patches as well? Whats your environment and workload anyway in dom0 and
> domU?
>
> It would be very good to know why the reboots happen. Perhaps such
> failures can not be debugged without special hardware, or a detailed
> code review.
>
>
> I just tested an otherwise unmodified xen-unstable build and did not
> encounter reboots while ballooning a single 2G guest up and down. The
> guest did just hang after a few iterations, most likely because v7 of my
> patch again (or still?) has the math wrong in the ring accounting. I
> will check what the issue is. I think v6 was ok in that respect, but I
> will double check that older version as well.
>
>
>> What we did is take this patch, amalgamate it with some bits from our
>> ring
>> management approach. We're ready to submit that, along with a
>> description
>> of how we test it. It works for us, and it involves wait queue's for
>> corner cases.
>
> Now if the patch you just sent out uses wait queues as well, and using
> wait queues causes sudden host reboots for reasons not yet known, how is
> your patch any better other that the reboots dont appear to happen
> anymore?

I believe you were missing some unlocks, which were triggering ASSERTs
going into a wait queue.

In any case, the patch was crashing, we spent quite some time merging it
all towards the endgame we all want (wait queues and better ring logic)
and now it doesn't seem to crash.

But obviously our testing rigs are quite different, which is a good thing.

I'll post the mem access testing code, with a description of how we drive
that test.

Thanks!
Andres
>
> I did not use anything but paging for testing, perhaps I should also run
> some access tests. How should I use tools/tests/xen-access/xen-access.c?
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:10:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:10:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNEe-0000by-Tm; Thu, 12 Jan 2012 16:10:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RlNEd-0000bp-4e
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:10:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326384616!52575366!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNjQ0OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3449 invoked from network); 12 Jan 2012 16:10:16 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-11.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 16:10:16 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id F0EDF4B0084;
	Thu, 12 Jan 2012 08:10: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=uD+0jfU4QtdUNh9YGSqAUAUoiACFC94lgTI/8BuOheMG
	SaZbLT237tRgnwBtzE1rzyg2KLb4yNqe07Lom5i61DVkwHpYREUXby8td3JII9mu
	SEeXm6nTMYgZzLj4lyXyXPToOCtjGQU0kBZB7tClNmgNzvICrzTXshRL9qIDhsc=
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=AMo17RYp7tgKYKWGf++d7I/TIZs=; b=h1rDi1vP
	+rWTawoNhidIUd/yvJGrmwrjQ349FhudbUnHVpusgN1bSvjQcwAGSaqvT38c2RLO
	KzTgHsoVOlCdBxsyRUICzfKeVRCvaTL0CBwfaXyPOxOJOlA86U5IgW/2i/Lp/N6J
	FzrcuyyXNT0TjDrYJy3fnEIBEnjlQsqhjyM=
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 AE1B34B006D; 
	Thu, 12 Jan 2012 08:10:36 -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, 12 Jan 2012 08:11:42 -0800
Message-ID: <cfc86d79380e4f7f4ba88de9794877c8.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120112135945.GA8324@aepfle.de>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
	<63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
	<20120112135945.GA8324@aepfle.de>
Date: Thu, 12 Jan 2012 08:11:42 -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 Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
>> > mem_event: use wait queue when ring is full
>> >
>> > This change is based on an idea/patch from Adin Scannell.
>>
>> Olaf,
>> thanks for the post. We'll have to nack this patch in its current form.
>> It
>> hard reboots our host during our testing.
>
> Thats very unfortunate. I have seen such unexpected reboots myself a few
> weeks ago. I suspect they were caused by an incorrect debug change which
> I had on top of my waitqueue changes. Also the fixes Keir provided a few
> weeks ago may have helped.
>
> Is it an otherwise unmodified xen-unstable build, or do you use other
> patches as well? Whats your environment and workload anyway in dom0 and
> domU?
>
> It would be very good to know why the reboots happen. Perhaps such
> failures can not be debugged without special hardware, or a detailed
> code review.
>
>
> I just tested an otherwise unmodified xen-unstable build and did not
> encounter reboots while ballooning a single 2G guest up and down. The
> guest did just hang after a few iterations, most likely because v7 of my
> patch again (or still?) has the math wrong in the ring accounting. I
> will check what the issue is. I think v6 was ok in that respect, but I
> will double check that older version as well.
>
>
>> What we did is take this patch, amalgamate it with some bits from our
>> ring
>> management approach. We're ready to submit that, along with a
>> description
>> of how we test it. It works for us, and it involves wait queue's for
>> corner cases.
>
> Now if the patch you just sent out uses wait queues as well, and using
> wait queues causes sudden host reboots for reasons not yet known, how is
> your patch any better other that the reboots dont appear to happen
> anymore?

I believe you were missing some unlocks, which were triggering ASSERTs
going into a wait queue.

In any case, the patch was crashing, we spent quite some time merging it
all towards the endgame we all want (wait queues and better ring logic)
and now it doesn't seem to crash.

But obviously our testing rigs are quite different, which is a good thing.

I'll post the mem access testing code, with a description of how we drive
that test.

Thanks!
Andres
>
> I did not use anything but paging for testing, perhaps I should also run
> some access tests. How should I use tools/tests/xen-access/xen-access.c?
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:12:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNGD-0000hf-V4; Thu, 12 Jan 2012 16:12:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlNGC-0000gq-Nk
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:12:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326384730!8869867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11062 invoked from network); 12 Jan 2012 16:12:10 -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 Jan 2012 16:12:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9976363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:12: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, 12 Jan 2012 16:12:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 16:12:10 +0000
In-Reply-To: <4F0EF816.6030206@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326384730.17210.251.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 Thu, 2012-01-12 at 15:11 +0000, Daniel De Graaf wrote:
> On 01/12/2012 04:59 AM, Ian Campbell wrote:
> > On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> >> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >>
> >> This patch claims one reserved grant entry for the console and another
> >> for the xenstore. It modifies the builder to fill in the grant table
> >> entries for the console and the xenstore.
> >>
> >> This has not been tested with any kind of migration.
> >>
> > [...]
> >> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> >> index 3fda6f8..23619da 100644
> >> --- a/tools/libxc/xc_domain_restore.c
> >> +++ b/tools/libxc/xc_domain_restore.c
> >> @@ -2018,6 +2018,15 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
> >>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
> >>
> >> +/* TODO don't hardcode zero here */
> >> +    rc = xc_dom_gnttab_seed(xch, dom,
> >> +                            *console_mfn, *store_mfn, 0, 0);
> > 
> > Presumably this TODO is the source of the comment in the changelog WRT
> > migration.
> > 
> > Does it Just Work or is there a legitimate TODO item here?
> > 
> > Ian.
> > 
> > 
> 
> This causes migration to only work if xenstored/xenconsoled are both in
> dom0, as the domain ID for both of them are hardcoded to zero. Determining
> the correct values for these domain IDs is more difficult than the domain
> build case, because they may not be the same as when the domain was built
> (especially if we are migrating).
> 
> The previous patch series used a domid file named similarly to a pid file
> to identify the location of xenstored and xenconsoled; this method would
> allow the TODO to be resolved. I think a better solution is to refer to the
> xenstore/xenconsole domains by name instead of domid, and set the names in
> a configuration file (/etc/xen/xl.conf?). This would also replace the
> xenstore_dom/console_dom parameters in patch #5.

That would work. You could also stash the necessary parameters in
xenstore from the tool which starts the stub-xenstored such that the
toolstack can look them up as needed. That avoids having to have an
xl.conf variable.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:12:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNGD-0000hf-V4; Thu, 12 Jan 2012 16:12:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlNGC-0000gq-Nk
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:12:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326384730!8869867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11062 invoked from network); 12 Jan 2012 16:12:10 -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 Jan 2012 16:12:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,498,1320624000"; 
   d="scan'208";a="9976363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:12: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, 12 Jan 2012 16:12:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 16:12:10 +0000
In-Reply-To: <4F0EF816.6030206@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326384730.17210.251.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 Thu, 2012-01-12 at 15:11 +0000, Daniel De Graaf wrote:
> On 01/12/2012 04:59 AM, Ian Campbell wrote:
> > On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> >> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >>
> >> This patch claims one reserved grant entry for the console and another
> >> for the xenstore. It modifies the builder to fill in the grant table
> >> entries for the console and the xenstore.
> >>
> >> This has not been tested with any kind of migration.
> >>
> > [...]
> >> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> >> index 3fda6f8..23619da 100644
> >> --- a/tools/libxc/xc_domain_restore.c
> >> +++ b/tools/libxc/xc_domain_restore.c
> >> @@ -2018,6 +2018,15 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> >>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
> >>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
> >>
> >> +/* TODO don't hardcode zero here */
> >> +    rc = xc_dom_gnttab_seed(xch, dom,
> >> +                            *console_mfn, *store_mfn, 0, 0);
> > 
> > Presumably this TODO is the source of the comment in the changelog WRT
> > migration.
> > 
> > Does it Just Work or is there a legitimate TODO item here?
> > 
> > Ian.
> > 
> > 
> 
> This causes migration to only work if xenstored/xenconsoled are both in
> dom0, as the domain ID for both of them are hardcoded to zero. Determining
> the correct values for these domain IDs is more difficult than the domain
> build case, because they may not be the same as when the domain was built
> (especially if we are migrating).
> 
> The previous patch series used a domid file named similarly to a pid file
> to identify the location of xenstored and xenconsoled; this method would
> allow the TODO to be resolved. I think a better solution is to refer to the
> xenstore/xenconsole domains by name instead of domid, and set the names in
> a configuration file (/etc/xen/xl.conf?). This would also replace the
> xenstore_dom/console_dom parameters in patch #5.

That would work. You could also stash the necessary parameters in
xenstore from the tool which starts the stub-xenstored such that the
toolstack can look them up as needed. That avoids having to have an
xl.conf variable.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:12:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNGB-0000h4-D5; Thu, 12 Jan 2012 16:12:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlNGA-0000gu-2t
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:12:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326384604!48292069!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 22925 invoked from network); 12 Jan 2012 16:10:04 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 16:10:04 -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
	q0CGC9Eq026962; Thu, 12 Jan 2012 16:12:09 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 q0CGC9AP011277; 
	Thu, 12 Jan 2012 11:12:09 -0500
Message-ID: <4F0F0656.4030402@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 11:12:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
In-Reply-To: <4F0EB6ED.3030900@invisiblethingslab.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2012 05:33 AM, Joanna Rutkowska wrote:
> On 01/11/12 18:21, Daniel De Graaf wrote:
>> This patch series allows xenstored to run in a stub domian started by
>> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
>> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html
>>
> 
> Daniel,
> 
> Can you explain what is the rationale for moving the xenstored into a
> stubdom? After all, if an attacker is able to compromise the xenstored,
> there should be many ways now how to compromise other VMs in the system?
> And it shouldn't matter whether the xenstored is in stubdom or whether
> in Dom0. E.g. the attacker might redirect the block fronts to us some
> false block backends, so that the VMs get compromised fs. One could
> probably think of other attacks as well...?
> 
> joanna.
> 

Splitting xenstored into its own domain (rather than keeping it in dom0)
means that it does not need to be privileged, so a compromise of xenstore
does not automatically give you full access to all other domains on the
system.

While it is possible to attack domains by sending them bad commands from
xenstore (device unplug/domain changes), it is also possible for a guest
VM to detect this and it becomes a denial-of-service instead of a way to
compromise the system. This is most easily done if guests use their own
full-disk encryption and run integrity checks on the unencrypted parts
(kernel/initrd; using a vTPM to unlock the guest-based FDE would work).

This split also prevents xenstored from being attacked from dom0, but this
is currently not as important security-wise since dom0 has superuser access
to the xenstore database. However, it does allow for future changes to
xenstore's security model that do not include a fully-privileged domain.

-- 
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 Jan 12 16:12:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:12:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNGB-0000h4-D5; Thu, 12 Jan 2012 16:12:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlNGA-0000gu-2t
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:12:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326384604!48292069!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 22925 invoked from network); 12 Jan 2012 16:10:04 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 16:10:04 -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
	q0CGC9Eq026962; Thu, 12 Jan 2012 16:12:09 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 q0CGC9AP011277; 
	Thu, 12 Jan 2012 11:12:09 -0500
Message-ID: <4F0F0656.4030402@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 11:12:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Joanna Rutkowska <joanna@invisiblethingslab.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0EB6ED.3030900@invisiblethingslab.com>
In-Reply-To: <4F0EB6ED.3030900@invisiblethingslab.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2012 05:33 AM, Joanna Rutkowska wrote:
> On 01/11/12 18:21, Daniel De Graaf wrote:
>> This patch series allows xenstored to run in a stub domian started by
>> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
>> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html
>>
> 
> Daniel,
> 
> Can you explain what is the rationale for moving the xenstored into a
> stubdom? After all, if an attacker is able to compromise the xenstored,
> there should be many ways now how to compromise other VMs in the system?
> And it shouldn't matter whether the xenstored is in stubdom or whether
> in Dom0. E.g. the attacker might redirect the block fronts to us some
> false block backends, so that the VMs get compromised fs. One could
> probably think of other attacks as well...?
> 
> joanna.
> 

Splitting xenstored into its own domain (rather than keeping it in dom0)
means that it does not need to be privileged, so a compromise of xenstore
does not automatically give you full access to all other domains on the
system.

While it is possible to attack domains by sending them bad commands from
xenstore (device unplug/domain changes), it is also possible for a guest
VM to detect this and it becomes a denial-of-service instead of a way to
compromise the system. This is most easily done if guests use their own
full-disk encryption and run integrity checks on the unencrypted parts
(kernel/initrd; using a vTPM to unlock the guest-based FDE would work).

This split also prevents xenstored from being attacked from dom0, but this
is currently not as important security-wise since dom0 has superuser access
to the xenstore database. However, it does allow for future changes to
xenstore's security model that do not include a fully-privileged domain.

-- 
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 Jan 12 16:14:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNI1-0000vA-FX; Thu, 12 Jan 2012 16:14: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 1RlNI0-0000uS-FZ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:14:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326384841!1905981!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3491 invoked from network); 12 Jan 2012 16:14:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 16:14:02 -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
	q0CGDu5d003119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 16:13: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
	q0CGDuYc015044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 16:13:56 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CGDtEp014029; Thu, 12 Jan 2012 10:13:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 08:13:55 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 650FA40308; Thu, 12 Jan 2012 11:12:04 -0500 (EST)
Date: Thu, 12 Jan 2012 11:12:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Message-ID: <20120112161204.GC10269@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F0F06C6.0062,ss=1,re=0.000,fgs=0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 05:05:34PM +0100, Kay Sievers wrote:
> On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> 
> >> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> >>
> >> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> >> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
> > Your patch that converts the xen-balloon to use the regular device bus driver
> > (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
> >
> > The toolstack (xen-tools) use:
> >
> > /sys/devices/system/xen_memory/xen_memory0
> >
> > But with the change, it is now:
> >
> > /sys/devices/xen_memory0/target_kb
> 
> Urks, seems like a mistake on my side.
> 
> Please try if changing:
>   bus_unregister(&balloon_subsys);
> to:
>   subsys_system_register(&balloon_subsys, NULL);
> in:
>   drivers/xen/xen-balloon.c
> fixes the issue.

Heh. I was *just* looking at d369a5d8fc70710236ae2d06a0e42dce483712df
("clocksource: convert sysdev_class to a regular subsystem") and typed up this patch
to try it out:


diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
index 3832e30..f0b206e 100644
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -221,13 +221,13 @@ static int register_balloon(struct device *dev)
 {
 	int i, error;
 
-	error = bus_register(&balloon_subsys);
+	error = subsys_system_register(&balloon_subsys, NULL);
 	if (error)
 		return error;
-
+/*
 	dev->id = 0;
 	dev->bus = &balloon_subsys;
-
+*/
 	error = device_register(dev);
 	if (error) {
 		bus_unregister(&balloon_subsys);
> 
> Sorry for that,

That is OK. That is what rc0 is for.

Anyhow, let me see if that fixes the issue. Thanks for your quick reply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:14:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:14:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNI1-0000vA-FX; Thu, 12 Jan 2012 16:14: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 1RlNI0-0000uS-FZ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:14:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326384841!1905981!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3491 invoked from network); 12 Jan 2012 16:14:02 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 16:14:02 -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
	q0CGDu5d003119
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 16:13: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
	q0CGDuYc015044
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 16:13:56 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CGDtEp014029; Thu, 12 Jan 2012 10:13:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 08:13:55 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 650FA40308; Thu, 12 Jan 2012 11:12:04 -0500 (EST)
Date: Thu, 12 Jan 2012 11:12:04 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Message-ID: <20120112161204.GC10269@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F0F06C6.0062,ss=1,re=0.000,fgs=0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 05:05:34PM +0100, Kay Sievers wrote:
> On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> 
> >> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> >>
> >> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> >> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
> > Your patch that converts the xen-balloon to use the regular device bus driver
> > (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
> >
> > The toolstack (xen-tools) use:
> >
> > /sys/devices/system/xen_memory/xen_memory0
> >
> > But with the change, it is now:
> >
> > /sys/devices/xen_memory0/target_kb
> 
> Urks, seems like a mistake on my side.
> 
> Please try if changing:
>   bus_unregister(&balloon_subsys);
> to:
>   subsys_system_register(&balloon_subsys, NULL);
> in:
>   drivers/xen/xen-balloon.c
> fixes the issue.

Heh. I was *just* looking at d369a5d8fc70710236ae2d06a0e42dce483712df
("clocksource: convert sysdev_class to a regular subsystem") and typed up this patch
to try it out:


diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
index 3832e30..f0b206e 100644
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -221,13 +221,13 @@ static int register_balloon(struct device *dev)
 {
 	int i, error;
 
-	error = bus_register(&balloon_subsys);
+	error = subsys_system_register(&balloon_subsys, NULL);
 	if (error)
 		return error;
-
+/*
 	dev->id = 0;
 	dev->bus = &balloon_subsys;
-
+*/
 	error = device_register(dev);
 	if (error) {
 		bus_unregister(&balloon_subsys);
> 
> Sorry for that,

That is OK. That is what rc0 is for.

Anyhow, let me see if that fixes the issue. Thanks for your quick reply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:16:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNJe-000185-Ve; Thu, 12 Jan 2012 16:15:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RlNJd-00017Q-R1
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:15:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326384943!8009736!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTgwNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29958 invoked from network); 12 Jan 2012 16:15:43 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-3.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 16:15:43 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id DFC78604092;
	Thu, 12 Jan 2012 08:15:42 -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=m4yzkJtHlv9ccQzdV7/l+M
	y7qoy3kg+kJcsjEjy/kfLTrQ0d7lJOmH9W8+Zu3O8smUGlzPJfsZjJJIFC6mrp+k
	kXpbtgH/iC0kPr14zN1upGsqbwJTpdGDFWg0r8l0CKyBJdsfHtFKxyhFtPTkP/hV
	NqK3V9ItsNs9Oe2QI+NK0=
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=ORVqetKBQNEQ
	ZVq7JmhtHx2ixM4=; b=PUhhxOgqi+lZBOcetiRqt2Sj6QWLvbZA3vJHihUHHK09
	jmaWbzb0PUeGDxLbo2pO1cK79tPtwSerDNH0NHIDHspW2fGrqlARn480gaZYAcbF
	KDxyGYBUL1OFDeo+DlI4hSOWRztUKYjRfWfWOuOEOGOwmANT2w8etJBkz5CAXGc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 9565B60408E; 
	Thu, 12 Jan 2012 08:15:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e7028b298fe384d1c0440fe3cbdd90ef1739c873
Message-Id: <e7028b298fe384d1c044.1326385206@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Jan 2012 11:20:06 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH] x86/mm: Fix operator associativity bug in
	mm-locks.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

 xen/arch/x86/mm/mm-locks.h |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


In an order-enforcing wrapper for an "external" recursive lock,
we aim to increment/decrement a recurse count and only update the
lock ordering on zero counts.

Unfortunately we incrementing/decrementing the pointer to the
recurse count, rather than the count itself.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 91f9a26a8d94 -r e7028b298fe3 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -81,7 +81,7 @@ static inline void _mm_enforce_order_loc
 {
     if ( recurse_count )
     {
-        if ( *recurse_count++ == 0 )
+        if ( (*recurse_count)++ == 0 )
         {
             *unlock_level = __get_lock_level();
         }
@@ -125,7 +125,7 @@ static inline void mm_enforce_order_unlo
     if ( recurse_count )
     {
         BUG_ON(*recurse_count == 0);
-        if ( *recurse_count-- == 1 )
+        if ( (*recurse_count)-- == 1 )
         {
             __set_lock_level(unlock_level);
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:16:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNJe-000185-Ve; Thu, 12 Jan 2012 16:15:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RlNJd-00017Q-R1
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:15:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326384943!8009736!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTgwNzY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29958 invoked from network); 12 Jan 2012 16:15:43 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-3.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 16:15:43 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id DFC78604092;
	Thu, 12 Jan 2012 08:15:42 -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=m4yzkJtHlv9ccQzdV7/l+M
	y7qoy3kg+kJcsjEjy/kfLTrQ0d7lJOmH9W8+Zu3O8smUGlzPJfsZjJJIFC6mrp+k
	kXpbtgH/iC0kPr14zN1upGsqbwJTpdGDFWg0r8l0CKyBJdsfHtFKxyhFtPTkP/hV
	NqK3V9ItsNs9Oe2QI+NK0=
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=ORVqetKBQNEQ
	ZVq7JmhtHx2ixM4=; b=PUhhxOgqi+lZBOcetiRqt2Sj6QWLvbZA3vJHihUHHK09
	jmaWbzb0PUeGDxLbo2pO1cK79tPtwSerDNH0NHIDHspW2fGrqlARn480gaZYAcbF
	KDxyGYBUL1OFDeo+DlI4hSOWRztUKYjRfWfWOuOEOGOwmANT2w8etJBkz5CAXGc=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 9565B60408E; 
	Thu, 12 Jan 2012 08:15:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e7028b298fe384d1c0440fe3cbdd90ef1739c873
Message-Id: <e7028b298fe384d1c044.1326385206@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Jan 2012 11:20:06 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: tim@xen.org
Subject: [Xen-devel] [PATCH] x86/mm: Fix operator associativity bug in
	mm-locks.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

 xen/arch/x86/mm/mm-locks.h |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


In an order-enforcing wrapper for an "external" recursive lock,
we aim to increment/decrement a recurse count and only update the
lock ordering on zero counts.

Unfortunately we incrementing/decrementing the pointer to the
recurse count, rather than the count itself.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 91f9a26a8d94 -r e7028b298fe3 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -81,7 +81,7 @@ static inline void _mm_enforce_order_loc
 {
     if ( recurse_count )
     {
-        if ( *recurse_count++ == 0 )
+        if ( (*recurse_count)++ == 0 )
         {
             *unlock_level = __get_lock_level();
         }
@@ -125,7 +125,7 @@ static inline void mm_enforce_order_unlo
     if ( recurse_count )
     {
         BUG_ON(*recurse_count == 0);
-        if ( *recurse_count-- == 1 )
+        if ( (*recurse_count)-- == 1 )
         {
             __set_lock_level(unlock_level);
         }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:24:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNRa-0001XE-MP; Thu, 12 Jan 2012 16:24:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RlNRX-0001X5-Vt
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:24:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326385320!59446136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26831 invoked from network); 12 Jan 2012 16:22:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:22:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9976739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:23: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, 12 Jan 2012 16:23: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
	1RlNRT-00032W-1h; Thu, 12 Jan 2012 16:23:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNRT-0002Tn-0h;
	Thu, 12 Jan 2012 16:23:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.2331.9908.618786@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:23:55 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
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;

One of my key objection to this is here.  I think that a convenience
macro should be written to avoid returning from the calling function
whereever possible.  And here, it is possible.

My other key objection is that I disapprove of the additional dynamic
allocation step, which provides additonal scope for bugs.  Dynamic
allocation with manual memory management should be avoided where it is
not necessary.  In general code should be structured so as to minimise
undetected mistakes by the programmer, which this is not.

Indeed your first version attempt at this approach has two such bugs!

Converseley the programming mistake you are trying to eliminate, of
calling an event-generating function from elsewhere in libxl, is not a
trivial mistake.

Firstly, it can only result from a fundamentally wrongheaded approach
to writing an asynchronous function.  In the correct approach the
desire to call an event-generation function (whether a slow function
like a synchronous ao call, or such as an event callback) from other
non-event-related libxl functions should not arise.

Secondly, the restriction is now enforced by the type system.

So the programmer can forget about this restriction unless they are
actually modifying the core event 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 Jan 12 16:24:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNRa-0001XE-MP; Thu, 12 Jan 2012 16:24:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RlNRX-0001X5-Vt
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:24:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326385320!59446136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26831 invoked from network); 12 Jan 2012 16:22:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:22:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9976739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:23: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, 12 Jan 2012 16:23: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
	1RlNRT-00032W-1h; Thu, 12 Jan 2012 16:23:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNRT-0002Tn-0h;
	Thu, 12 Jan 2012 16:23:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.2331.9908.618786@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:23:55 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
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;

One of my key objection to this is here.  I think that a convenience
macro should be written to avoid returning from the calling function
whereever possible.  And here, it is possible.

My other key objection is that I disapprove of the additional dynamic
allocation step, which provides additonal scope for bugs.  Dynamic
allocation with manual memory management should be avoided where it is
not necessary.  In general code should be structured so as to minimise
undetected mistakes by the programmer, which this is not.

Indeed your first version attempt at this approach has two such bugs!

Converseley the programming mistake you are trying to eliminate, of
calling an event-generating function from elsewhere in libxl, is not a
trivial mistake.

Firstly, it can only result from a fundamentally wrongheaded approach
to writing an asynchronous function.  In the correct approach the
desire to call an event-generation function (whether a slow function
like a synchronous ao call, or such as an event callback) from other
non-event-related libxl functions should not arise.

Secondly, the restriction is now enforced by the type system.

So the programmer can forget about this restriction unless they are
actually modifying the core event 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 Jan 12 16:28:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNVX-0001gH-DE; Thu, 12 Jan 2012 16:28: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 1RlNVV-0001g6-GK
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:28:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326385679!10658404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11970 invoked from network); 12 Jan 2012 16:27:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:27:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9976924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:27: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, 12 Jan 2012 16:27: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
	1RlNVO-000341-Oe; Thu, 12 Jan 2012 16:27:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNVO-0002UV-Nf;
	Thu, 12 Jan 2012 16:27:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.2574.701042.567123@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:27:58 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
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"):
> +_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;

Also of course not all functions which use GC_INIT currently return a
libxl error code.  Here is a counterexample:

  libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
  {
      int ret = 0;
      libxl__qmp_handler *qmp = NULL;
      char *qmp_socket;
      GC_INIT(ctx);

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:28:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:28:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNVX-0001gH-DE; Thu, 12 Jan 2012 16:28: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 1RlNVV-0001g6-GK
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:28:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326385679!10658404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11970 invoked from network); 12 Jan 2012 16:27:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:27:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9976924"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:27: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, 12 Jan 2012 16:27: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
	1RlNVO-000341-Oe; Thu, 12 Jan 2012 16:27:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNVO-0002UV-Nf;
	Thu, 12 Jan 2012 16:27:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.2574.701042.567123@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:27:58 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
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"):
> +_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;

Also of course not all functions which use GC_INIT currently return a
libxl error code.  Here is a counterexample:

  libxl__qmp_handler *libxl__qmp_initialize(libxl_ctx *ctx, uint32_t domid)
  {
      int ret = 0;
      libxl__qmp_handler *qmp = NULL;
      char *qmp_socket;
      GC_INIT(ctx);

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:34:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNbG-0001yg-7F; Thu, 12 Jan 2012 16:34:02 +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 1RlNbE-0001yb-Gn
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:34:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326386033!10596600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10620 invoked from network); 12 Jan 2012 16:33:53 -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;
	12 Jan 2012 16:33:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:33:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Jan 2012 16:33:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RlNb6-00035p-Ex; Thu, 12 Jan 2012 16:33:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNb6-0002X1-E1;
	Thu, 12 Jan 2012 16:33:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.2928.421883.966193@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:33:52 +0000
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB3235B4.287E2%keir.xen@gmail.com>
References: <20236.30074.784658.148457@mariner.uk.xensource.com>
	<CB3235B4.287E2%keir.xen@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>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
 the hypervisor 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

Keir Fraser writes ("Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by the hypervisor build"):
> I'm sure we've done both .hgignore/.gitignore in some repositories in the
> past. It sounds fine to me.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] .gitignore

Introduce a .gitignore file for the convenience of people who use git.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 .gitignore |  372 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 372 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..625ceee
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,372 @@
+.hg
+*.orig
+*.rej
+*~
+*.o
+*.d
+*.opic
+*.a
+*.so
+*.so.[0-9]*
+*.bin
+*.bak
+*.tmp
+TAGS
+.config
+
+dist
+tools/ioemu-dir
+tools/ioemu-remote
+stubdom/*.tar.gz
+
+build-*
+dist/*
+docs/*.aux
+docs/*.dvi
+docs/*.log
+docs/*.pdf
+docs/*.ps
+docs/*.toc
+docs/api/*
+docs/figs/xenserver.eps
+docs/html/*
+docs/interface/WARNINGS
+docs/interface/images.pl
+docs/interface/images.tex
+docs/interface/img1.png
+docs/interface/index.html
+docs/interface/interface.css
+docs/interface/interface.html
+docs/interface/labels.pl
+docs/man1/
+docs/man5/
+docs/pdf/*
+docs/ps/*
+docs/user/WARNINGS
+docs/user/images.pl
+docs/user/images.tex
+docs/user/img1.png
+docs/user/img2.png
+docs/user/img3.png
+docs/user/index.html
+docs/user/internals.pl
+docs/user/labels.pl
+docs/user/user.css
+docs/user/user.html
+docs/xen-api/vm_lifecycle.eps
+docs/xen-api/xenapi-datamodel-graph.eps
+docs/xen-api/xenapi.out
+docs/xen-api/xenapi.dvi
+docs/xen-api/xenapi.pdf
+docs/xen-api/xenapi.ps
+docs/xen-api/xenapi.toc
+extras/mini-os/arch/ia64/gen_off.s
+extras/mini-os/include/mini-os
+extras/mini-os/include/ia64/mini-os
+extras/mini-os/include/ia64/offsets.h
+extras/mini-os/include/x86/mini-os
+extras/mini-os/include/xen
+extras/mini-os/mini-os*
+install/*
+linux-[^/]*-paravirt/*
+linux-2.6[^/]*/*
+linux-[^/]*-rc/*
+linux-[^/]*-tip/*
+linux-[^/]*-git/*
+linux-[^/]*.patch
+mkddbxen
+netbsd-[^/]*-tools/*
+netbsd-[^/]*-xen0/*
+netbsd-[^/]*-xenU/*
+netbsd-[^/]*.patch
+patches/*/.makedep
+patches/ebtables-brnf-5_vs_2.4.25.diff
+patches/ebtables.diff
+patches/tmp/*
+pristine-*
+ref-*
+tmp-*
+stubdom/binutils-*
+stubdom/cross-root-*
+stubdom/gcc-*
+stubdom/include
+stubdom/ioemu
+stubdom/xenstore
+stubdom/libxc-*
+stubdom/lwip-*
+stubdom/mini-os-*
+stubdom/mk-headers-*
+stubdom/newlib-1.*
+stubdom/newlib-x86*
+stubdom/pciutils-*
+stubdom/zlib-*
+stubdom/grub-*
+stubdom/ocaml-*
+stubdom/lwip/
+stubdom/ioemu/
+stubdom/stubdompath.sh
+tools/*/build/lib*/*.py
+tools/blktap2/daemon/blktapctrl
+tools/blktap2/drivers/img2qcow
+tools/blktap2/drivers/lock-util
+tools/blktap2/drivers/qcow-create
+tools/blktap2/drivers/qcow2raw
+tools/blktap2/drivers/tapdisk
+tools/blktap2/drivers/tapdisk-client
+tools/blktap2/drivers/tapdisk-diff
+tools/blktap2/drivers/tapdisk-stream
+tools/blktap2/drivers/tapdisk2
+tools/blktap2/drivers/td-util
+tools/blktap2/vhd/vhd-update
+tools/blktap2/vhd/vhd-util
+tools/blktap/drivers/blktapctrl
+tools/blktap/drivers/img2qcow
+tools/blktap/drivers/qcow-create
+tools/blktap/drivers/qcow2raw
+tools/blktap/drivers/tapdisk
+tools/check/.*
+tools/console/xenconsole
+tools/console/xenconsoled
+tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
+tools/debugger/gdb/gdb-6.2.1/*
+tools/debugger/gdb/gdb-6.2.1.tar.bz2
+tools/debugger/gdbsx/gdbsx
+tools/debugger/xenitp/xenitp
+tools/firmware/*/biossums
+tools/firmware/*.bin
+tools/firmware/*.sym
+tools/firmware/*bios/*bios*.txt
+tools/firmware/etherboot/gpxe/*
+tools/firmware/extboot/extboot.img
+tools/firmware/extboot/signrom
+tools/firmware/hvmloader/acpi/mk_dsdt
+tools/firmware/hvmloader/acpi/dsdt*.c
+tools/firmware/hvmloader/acpi/dsdt*.asl
+tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/hvmloader
+tools/firmware/hvmloader/roms.h
+tools/firmware/hvmloader/roms.inc
+tools/firmware/rombios/BIOS-bochs-[^/]*
+tools/firmware/rombios/_rombios[^/]*_.c
+tools/firmware/rombios/rombios[^/]*.s
+tools/firmware/rombios/32bit/32bitbios_flat.h
+tools/firmware/vgabios/vbetables-gen
+tools/firmware/vgabios/vbetables.h
+tools/flask/loadpolicy/flask-loadpolicy
+tools/flask/utils/flask-getenforce
+tools/flask/utils/flask-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/*
+tools/include/xen-foreign/*.(c|h|size)
+tools/include/xen-foreign/checker
+tools/ioemu/.pc/*
+tools/ioemu/config-host.h
+tools/ioemu/config-host.mak
+tools/ioemu/i386-dm/Makefile
+tools/ioemu/i386-dm/config.h
+tools/ioemu/i386-dm/config.mak
+tools/ioemu/i386-dm/qemu-dm
+tools/ioemu/qemu-doc.html
+tools/ioemu/qemu-img.1
+tools/ioemu/qemu-img.pod
+tools/ioemu/qemu-tech.html
+tools/ioemu/qemu.1
+tools/ioemu/qemu.pod
+tools/ioemu/tapdisk-ioemu
+tools/libxc/ia64/asm/*.h
+tools/libxc/ia64/acpi/*.h
+tools/libxc/ia64/acpi/platform/*.h
+tools/libxc/ia64/dom_fw_asm.S
+tools/libxc/ia64/dom_fw_common.c
+tools/libxc/ia64/dom_fw_domu.c
+tools/libxc/ia64/xen/*.h
+tools/libxen/libxenapi-
+tools/libxen/test/test_bindings
+tools/libxen/test/test_event_handling
+tools/libxl/libxlu_cfg_y.output
+tools/libxl/xl
+tools/libxl/testenum
+tools/libxl/testenum.c
+tools/libaio/src/*.ol
+tools/libaio/src/*.os
+tools/misc/cpuperf/cpuperf-perfcntr
+tools/misc/cpuperf/cpuperf-xen
+tools/misc/lomount/lomount
+tools/misc/mbootpack/bin2c
+tools/misc/mbootpack/bootsect
+tools/misc/mbootpack/bzimage_header.c
+tools/misc/mbootpack/mbootpack
+tools/misc/mbootpack/setup
+tools/misc/miniterm/miniterm
+tools/misc/xc_shadow
+tools/misc/xen_cpuperf
+tools/misc/xen-detect
+tools/misc/xen-tmem-list-parse
+tools/misc/xenperf
+tools/misc/xenpm
+tools/misc/xen-hvmctx
+tools/misc/gtraceview
+tools/misc/gtracestat
+tools/misc/xenlockprof
+tools/pygrub/build/*
+tools/python/build/*
+tools/python/xen/util/path.py
+tools/remus/imqebt/imqebt
+tools/remus/kmod/*(.cmd|.mod|.ko|.mod.c|.symvers|.xen)
+tools/security/secpol_tool
+tools/security/xen/*
+tools/security/xensec_tool
+tools/tests/blowfish.bin
+tools/tests/blowfish.h
+tools/tests/test_x86_emulator
+tools/tests/x86_emulate
+tools/tests/regression/installed/*
+tools/tests/regression/build/*
+tools/tests/regression/downloads/*
+tools/vnet/Make.local
+tools/vnet/build/*
+tools/vnet/gc
+tools/vnet/gc*/*
+tools/vnet/vnet-module/*.ko
+tools/vnet/vnet-module/.*.cmd
+tools/vnet/vnet-module/.tmp_versions/*
+tools/vnet/vnet-module/vnet_module.mod.*
+tools/vnet/vnetd/vnetd
+tools/vtpm/tpm_emulator-*.tar.gz
+tools/vtpm/tpm_emulator/*
+tools/vtpm/vtpm/*
+tools/vtpm_manager/manager/vtpm_managerd
+tools/xcutils/lsevtchn
+tools/xcutils/xc_restore
+tools/xcutils/xc_save
+tools/xcutils/readnotes
+tools/xenfb/sdlfb
+tools/xenfb/vncfb
+tools/xenmon/xentrace_setmask
+tools/xenmon/xenbaked
+tools/xenpaging/xenpaging
+tools/xenpmd/xenpmd
+tools/xenstat/xentop/xentop
+tools/xenstore/testsuite/tmp/*
+tools/xenstore/xen
+tools/xenstore/xenstore
+tools/xenstore/xenstore-chmod
+tools/xenstore/xenstore-exists
+tools/xenstore/xenstore-list
+tools/xenstore/xenstore-read
+tools/xenstore/xenstore-rm
+tools/xenstore/xenstore-write
+tools/xenstore/xenstore-control
+tools/xenstore/xenstore-ls
+tools/xenstore/xenstored
+tools/xenstore/xenstored_test
+tools/xenstore/xs_crashme
+tools/xenstore/xs_random
+tools/xenstore/xs_stress
+tools/xenstore/xs_tdb_dump
+tools/xenstore/xs_test
+tools/xenstore/xs_watch_stress
+tools/xentrace/xentrace_setsize
+tools/xentrace/tbctl
+tools/xentrace/xenctx
+tools/xentrace/xentrace
+tools/xm-test/ramdisk/buildroot
+tools/xm-test/aclocal.m4
+tools/xm-test/autom4te
+tools/xm-test/install-sh
+tools/xm-test/mkinstalldirs
+tools/xm-test/missing
+tools/xm-test/config(ure|.log|.status|.guess|.sub)
+tools/xm-test/Makefile(.in)*
+tools/xm-test/*/Makefile(.in)*
+tools/xm-test/lib/XmTestLib/config.py
+tools/xm-test/lib/XmTestReport/xmtest.py
+tools/xm-test/tests/*.test
+tools/ioemu-remote
+tools/ioemu-dir
+tools/ocaml-xenstored*
+xen/.banner*
+xen/BLOG
+xen/System.map
+xen/arch/x86/asm-offsets.s
+xen/arch/x86/boot/mkelf32
+xen/arch/x86/xen.lds
+xen/arch/x86/boot/reloc.S
+xen/ddb/*
+xen/include/headers.chk
+xen/include/asm
+xen/include/asm-*/asm-offsets.h
+xen/include/asm-ia64/asm-xsi-offsets.h
+xen/include/asm-ia64/.offsets.h.stamp
+xen/include/asm-ia64/xen
+xen/include/compat/*
+xen/include/hypervisor-ifs/arch
+xen/include/linux
+xen/include/public/public
+xen/include/xen/*.new
+xen/include/xen/acm_policy.h
+xen/include/xen/banner.h
+xen/include/xen/compile.h
+xen/tools/figlet/figlet
+xen/tools/symbols
+xen/xen
+xen/xen-syms
+xen/xen.*
+xen/arch/ia64/asm-offsets.s
+xen/arch/ia64/asm-xsi-offsets.s
+xen/arch/ia64/map.out
+xen/arch/ia64/xen.lds.s
+unmodified_drivers/linux-2.6/.tmp_versions
+unmodified_drivers/linux-2.6/*.cmd
+unmodified_drivers/linux-2.6/*.ko
+unmodified_drivers/linux-2.6/*.mod.c
+LibVNCServer*
+
+tools/firmware/rombios/_rombios_.c
+tools/firmware/rombios/rombios.s
+tools/firmware/rombios/rombios.sym
+tools/include/xen-foreign/checker.c
+tools/include/xen-foreign/ia64.h
+tools/include/xen-foreign/structs.pyc
+tools/include/xen-foreign/x86_32.h
+tools/include/xen-foreign/x86_64.h
+
+.git
+tools/misc/xen-hptool
+tools/libxl/_*.[ch]
+tools/libxl/testidl
+tools/libxl/testidl.c
+tools/libxl/*.pyc
+tools/blktap2/control/tap-ctl
+tools/firmware/etherboot/eb-roms.h
+tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
+tools/misc/xenwatchdogd
+tools/misc/xen-hvmcrash
+tools/libvchan/vchan-node[12]
+tools/ocaml/*/.ocamldep.make
+tools/ocaml/*/*.cm[ixao]
+tools/ocaml/*/*.cmxa
+tools/ocaml/*/*.annot
+tools/ocaml/*/*/.ocamldep.make
+tools/ocaml/*/*/*.cm[ixao]
+tools/ocaml/*/*/*.cmxa
+tools/ocaml/*/*/*.annot
+tools/ocaml/*/*/META
+tools/ocaml/libs/xl/_libxl_types.inc
+tools/ocaml/libs/xl/_libxl_types.ml.in
+tools/ocaml/libs/xl/_libxl_types.mli.in
+tools/ocaml/libs/xl/xenlight.ml
+tools/ocaml/xenstored/oxenstored
+
+tools/debugger/kdd/kdd
+tools/firmware/etherboot/ipxe.tar.gz
+tools/firmware/etherboot/ipxe/
+tools/python/xen/lowlevel/xl/_pyxl_types.c
+tools/python/xen/lowlevel/xl/_pyxl_types.h
+tools/xenstore/xenstore-watch
+
+docs/txt/misc/*.txt
+docs/txt/man/*.txt
-- 
tg: (f7fd6d8..) t/xen/gitignore (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:34:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNbG-0001yg-7F; Thu, 12 Jan 2012 16:34:02 +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 1RlNbE-0001yb-Gn
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:34:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326386033!10596600!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10620 invoked from network); 12 Jan 2012 16:33:53 -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;
	12 Jan 2012 16:33:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:33:52 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 12 Jan 2012 16:33:52 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RlNb6-00035p-Ex; Thu, 12 Jan 2012 16:33:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNb6-0002X1-E1;
	Thu, 12 Jan 2012 16:33:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.2928.421883.966193@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:33:52 +0000
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB3235B4.287E2%keir.xen@gmail.com>
References: <20236.30074.784658.148457@mariner.uk.xensource.com>
	<CB3235B4.287E2%keir.xen@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>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
 the hypervisor 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

Keir Fraser writes ("Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by the hypervisor build"):
> I'm sure we've done both .hgignore/.gitignore in some repositories in the
> past. It sounds fine to me.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] .gitignore

Introduce a .gitignore file for the convenience of people who use git.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 .gitignore |  372 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 372 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..625ceee
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,372 @@
+.hg
+*.orig
+*.rej
+*~
+*.o
+*.d
+*.opic
+*.a
+*.so
+*.so.[0-9]*
+*.bin
+*.bak
+*.tmp
+TAGS
+.config
+
+dist
+tools/ioemu-dir
+tools/ioemu-remote
+stubdom/*.tar.gz
+
+build-*
+dist/*
+docs/*.aux
+docs/*.dvi
+docs/*.log
+docs/*.pdf
+docs/*.ps
+docs/*.toc
+docs/api/*
+docs/figs/xenserver.eps
+docs/html/*
+docs/interface/WARNINGS
+docs/interface/images.pl
+docs/interface/images.tex
+docs/interface/img1.png
+docs/interface/index.html
+docs/interface/interface.css
+docs/interface/interface.html
+docs/interface/labels.pl
+docs/man1/
+docs/man5/
+docs/pdf/*
+docs/ps/*
+docs/user/WARNINGS
+docs/user/images.pl
+docs/user/images.tex
+docs/user/img1.png
+docs/user/img2.png
+docs/user/img3.png
+docs/user/index.html
+docs/user/internals.pl
+docs/user/labels.pl
+docs/user/user.css
+docs/user/user.html
+docs/xen-api/vm_lifecycle.eps
+docs/xen-api/xenapi-datamodel-graph.eps
+docs/xen-api/xenapi.out
+docs/xen-api/xenapi.dvi
+docs/xen-api/xenapi.pdf
+docs/xen-api/xenapi.ps
+docs/xen-api/xenapi.toc
+extras/mini-os/arch/ia64/gen_off.s
+extras/mini-os/include/mini-os
+extras/mini-os/include/ia64/mini-os
+extras/mini-os/include/ia64/offsets.h
+extras/mini-os/include/x86/mini-os
+extras/mini-os/include/xen
+extras/mini-os/mini-os*
+install/*
+linux-[^/]*-paravirt/*
+linux-2.6[^/]*/*
+linux-[^/]*-rc/*
+linux-[^/]*-tip/*
+linux-[^/]*-git/*
+linux-[^/]*.patch
+mkddbxen
+netbsd-[^/]*-tools/*
+netbsd-[^/]*-xen0/*
+netbsd-[^/]*-xenU/*
+netbsd-[^/]*.patch
+patches/*/.makedep
+patches/ebtables-brnf-5_vs_2.4.25.diff
+patches/ebtables.diff
+patches/tmp/*
+pristine-*
+ref-*
+tmp-*
+stubdom/binutils-*
+stubdom/cross-root-*
+stubdom/gcc-*
+stubdom/include
+stubdom/ioemu
+stubdom/xenstore
+stubdom/libxc-*
+stubdom/lwip-*
+stubdom/mini-os-*
+stubdom/mk-headers-*
+stubdom/newlib-1.*
+stubdom/newlib-x86*
+stubdom/pciutils-*
+stubdom/zlib-*
+stubdom/grub-*
+stubdom/ocaml-*
+stubdom/lwip/
+stubdom/ioemu/
+stubdom/stubdompath.sh
+tools/*/build/lib*/*.py
+tools/blktap2/daemon/blktapctrl
+tools/blktap2/drivers/img2qcow
+tools/blktap2/drivers/lock-util
+tools/blktap2/drivers/qcow-create
+tools/blktap2/drivers/qcow2raw
+tools/blktap2/drivers/tapdisk
+tools/blktap2/drivers/tapdisk-client
+tools/blktap2/drivers/tapdisk-diff
+tools/blktap2/drivers/tapdisk-stream
+tools/blktap2/drivers/tapdisk2
+tools/blktap2/drivers/td-util
+tools/blktap2/vhd/vhd-update
+tools/blktap2/vhd/vhd-util
+tools/blktap/drivers/blktapctrl
+tools/blktap/drivers/img2qcow
+tools/blktap/drivers/qcow-create
+tools/blktap/drivers/qcow2raw
+tools/blktap/drivers/tapdisk
+tools/check/.*
+tools/console/xenconsole
+tools/console/xenconsoled
+tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
+tools/debugger/gdb/gdb-6.2.1/*
+tools/debugger/gdb/gdb-6.2.1.tar.bz2
+tools/debugger/gdbsx/gdbsx
+tools/debugger/xenitp/xenitp
+tools/firmware/*/biossums
+tools/firmware/*.bin
+tools/firmware/*.sym
+tools/firmware/*bios/*bios*.txt
+tools/firmware/etherboot/gpxe/*
+tools/firmware/extboot/extboot.img
+tools/firmware/extboot/signrom
+tools/firmware/hvmloader/acpi/mk_dsdt
+tools/firmware/hvmloader/acpi/dsdt*.c
+tools/firmware/hvmloader/acpi/dsdt*.asl
+tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/hvmloader
+tools/firmware/hvmloader/roms.h
+tools/firmware/hvmloader/roms.inc
+tools/firmware/rombios/BIOS-bochs-[^/]*
+tools/firmware/rombios/_rombios[^/]*_.c
+tools/firmware/rombios/rombios[^/]*.s
+tools/firmware/rombios/32bit/32bitbios_flat.h
+tools/firmware/vgabios/vbetables-gen
+tools/firmware/vgabios/vbetables.h
+tools/flask/loadpolicy/flask-loadpolicy
+tools/flask/utils/flask-getenforce
+tools/flask/utils/flask-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/*
+tools/include/xen-foreign/*.(c|h|size)
+tools/include/xen-foreign/checker
+tools/ioemu/.pc/*
+tools/ioemu/config-host.h
+tools/ioemu/config-host.mak
+tools/ioemu/i386-dm/Makefile
+tools/ioemu/i386-dm/config.h
+tools/ioemu/i386-dm/config.mak
+tools/ioemu/i386-dm/qemu-dm
+tools/ioemu/qemu-doc.html
+tools/ioemu/qemu-img.1
+tools/ioemu/qemu-img.pod
+tools/ioemu/qemu-tech.html
+tools/ioemu/qemu.1
+tools/ioemu/qemu.pod
+tools/ioemu/tapdisk-ioemu
+tools/libxc/ia64/asm/*.h
+tools/libxc/ia64/acpi/*.h
+tools/libxc/ia64/acpi/platform/*.h
+tools/libxc/ia64/dom_fw_asm.S
+tools/libxc/ia64/dom_fw_common.c
+tools/libxc/ia64/dom_fw_domu.c
+tools/libxc/ia64/xen/*.h
+tools/libxen/libxenapi-
+tools/libxen/test/test_bindings
+tools/libxen/test/test_event_handling
+tools/libxl/libxlu_cfg_y.output
+tools/libxl/xl
+tools/libxl/testenum
+tools/libxl/testenum.c
+tools/libaio/src/*.ol
+tools/libaio/src/*.os
+tools/misc/cpuperf/cpuperf-perfcntr
+tools/misc/cpuperf/cpuperf-xen
+tools/misc/lomount/lomount
+tools/misc/mbootpack/bin2c
+tools/misc/mbootpack/bootsect
+tools/misc/mbootpack/bzimage_header.c
+tools/misc/mbootpack/mbootpack
+tools/misc/mbootpack/setup
+tools/misc/miniterm/miniterm
+tools/misc/xc_shadow
+tools/misc/xen_cpuperf
+tools/misc/xen-detect
+tools/misc/xen-tmem-list-parse
+tools/misc/xenperf
+tools/misc/xenpm
+tools/misc/xen-hvmctx
+tools/misc/gtraceview
+tools/misc/gtracestat
+tools/misc/xenlockprof
+tools/pygrub/build/*
+tools/python/build/*
+tools/python/xen/util/path.py
+tools/remus/imqebt/imqebt
+tools/remus/kmod/*(.cmd|.mod|.ko|.mod.c|.symvers|.xen)
+tools/security/secpol_tool
+tools/security/xen/*
+tools/security/xensec_tool
+tools/tests/blowfish.bin
+tools/tests/blowfish.h
+tools/tests/test_x86_emulator
+tools/tests/x86_emulate
+tools/tests/regression/installed/*
+tools/tests/regression/build/*
+tools/tests/regression/downloads/*
+tools/vnet/Make.local
+tools/vnet/build/*
+tools/vnet/gc
+tools/vnet/gc*/*
+tools/vnet/vnet-module/*.ko
+tools/vnet/vnet-module/.*.cmd
+tools/vnet/vnet-module/.tmp_versions/*
+tools/vnet/vnet-module/vnet_module.mod.*
+tools/vnet/vnetd/vnetd
+tools/vtpm/tpm_emulator-*.tar.gz
+tools/vtpm/tpm_emulator/*
+tools/vtpm/vtpm/*
+tools/vtpm_manager/manager/vtpm_managerd
+tools/xcutils/lsevtchn
+tools/xcutils/xc_restore
+tools/xcutils/xc_save
+tools/xcutils/readnotes
+tools/xenfb/sdlfb
+tools/xenfb/vncfb
+tools/xenmon/xentrace_setmask
+tools/xenmon/xenbaked
+tools/xenpaging/xenpaging
+tools/xenpmd/xenpmd
+tools/xenstat/xentop/xentop
+tools/xenstore/testsuite/tmp/*
+tools/xenstore/xen
+tools/xenstore/xenstore
+tools/xenstore/xenstore-chmod
+tools/xenstore/xenstore-exists
+tools/xenstore/xenstore-list
+tools/xenstore/xenstore-read
+tools/xenstore/xenstore-rm
+tools/xenstore/xenstore-write
+tools/xenstore/xenstore-control
+tools/xenstore/xenstore-ls
+tools/xenstore/xenstored
+tools/xenstore/xenstored_test
+tools/xenstore/xs_crashme
+tools/xenstore/xs_random
+tools/xenstore/xs_stress
+tools/xenstore/xs_tdb_dump
+tools/xenstore/xs_test
+tools/xenstore/xs_watch_stress
+tools/xentrace/xentrace_setsize
+tools/xentrace/tbctl
+tools/xentrace/xenctx
+tools/xentrace/xentrace
+tools/xm-test/ramdisk/buildroot
+tools/xm-test/aclocal.m4
+tools/xm-test/autom4te
+tools/xm-test/install-sh
+tools/xm-test/mkinstalldirs
+tools/xm-test/missing
+tools/xm-test/config(ure|.log|.status|.guess|.sub)
+tools/xm-test/Makefile(.in)*
+tools/xm-test/*/Makefile(.in)*
+tools/xm-test/lib/XmTestLib/config.py
+tools/xm-test/lib/XmTestReport/xmtest.py
+tools/xm-test/tests/*.test
+tools/ioemu-remote
+tools/ioemu-dir
+tools/ocaml-xenstored*
+xen/.banner*
+xen/BLOG
+xen/System.map
+xen/arch/x86/asm-offsets.s
+xen/arch/x86/boot/mkelf32
+xen/arch/x86/xen.lds
+xen/arch/x86/boot/reloc.S
+xen/ddb/*
+xen/include/headers.chk
+xen/include/asm
+xen/include/asm-*/asm-offsets.h
+xen/include/asm-ia64/asm-xsi-offsets.h
+xen/include/asm-ia64/.offsets.h.stamp
+xen/include/asm-ia64/xen
+xen/include/compat/*
+xen/include/hypervisor-ifs/arch
+xen/include/linux
+xen/include/public/public
+xen/include/xen/*.new
+xen/include/xen/acm_policy.h
+xen/include/xen/banner.h
+xen/include/xen/compile.h
+xen/tools/figlet/figlet
+xen/tools/symbols
+xen/xen
+xen/xen-syms
+xen/xen.*
+xen/arch/ia64/asm-offsets.s
+xen/arch/ia64/asm-xsi-offsets.s
+xen/arch/ia64/map.out
+xen/arch/ia64/xen.lds.s
+unmodified_drivers/linux-2.6/.tmp_versions
+unmodified_drivers/linux-2.6/*.cmd
+unmodified_drivers/linux-2.6/*.ko
+unmodified_drivers/linux-2.6/*.mod.c
+LibVNCServer*
+
+tools/firmware/rombios/_rombios_.c
+tools/firmware/rombios/rombios.s
+tools/firmware/rombios/rombios.sym
+tools/include/xen-foreign/checker.c
+tools/include/xen-foreign/ia64.h
+tools/include/xen-foreign/structs.pyc
+tools/include/xen-foreign/x86_32.h
+tools/include/xen-foreign/x86_64.h
+
+.git
+tools/misc/xen-hptool
+tools/libxl/_*.[ch]
+tools/libxl/testidl
+tools/libxl/testidl.c
+tools/libxl/*.pyc
+tools/blktap2/control/tap-ctl
+tools/firmware/etherboot/eb-roms.h
+tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
+tools/misc/xenwatchdogd
+tools/misc/xen-hvmcrash
+tools/libvchan/vchan-node[12]
+tools/ocaml/*/.ocamldep.make
+tools/ocaml/*/*.cm[ixao]
+tools/ocaml/*/*.cmxa
+tools/ocaml/*/*.annot
+tools/ocaml/*/*/.ocamldep.make
+tools/ocaml/*/*/*.cm[ixao]
+tools/ocaml/*/*/*.cmxa
+tools/ocaml/*/*/*.annot
+tools/ocaml/*/*/META
+tools/ocaml/libs/xl/_libxl_types.inc
+tools/ocaml/libs/xl/_libxl_types.ml.in
+tools/ocaml/libs/xl/_libxl_types.mli.in
+tools/ocaml/libs/xl/xenlight.ml
+tools/ocaml/xenstored/oxenstored
+
+tools/debugger/kdd/kdd
+tools/firmware/etherboot/ipxe.tar.gz
+tools/firmware/etherboot/ipxe/
+tools/python/xen/lowlevel/xl/_pyxl_types.c
+tools/python/xen/lowlevel/xl/_pyxl_types.h
+tools/xenstore/xenstore-watch
+
+docs/txt/misc/*.txt
+docs/txt/man/*.txt
-- 
tg: (f7fd6d8..) t/xen/gitignore (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:37:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNeT-00028A-5Y; Thu, 12 Jan 2012 16:37:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RlNeR-00027u-Et
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:37:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326386108!48296310!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzA2NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27927 invoked from network); 12 Jan 2012 16:35:09 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-14.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 16:35:09 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id D4B6145807B;
	Thu, 12 Jan 2012 08:37:16 -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=B+GJQQtCWaCY7sQ4nqys42
	owiZUkYWfMBETLSiQOhTUW33KVM+jYrX2fujTm6wUd8KigtfrTGhw2EcOeQRy50A
	gYedFWJ9xXqsTIA7kv/EORZcR4z9vUTF+skymMbvI6qI8dxH/EbyOgOgTHlCFBq8
	moZhsGII231x4L6gzCLAw=
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=h0eZE/YBha7H
	JEjGT5+C9bNCJrY=; b=dYiPGFQez2Z4xKtPvAKuPHVbyH4MTFy6bulQzyZhrqaj
	dxoi/hkvMr5YBGbAeqflEcXHjsHItF13xsH6Dsd74oEQYbBNysEVlQ/TeRnTnWFx
	Nb7milmxrmE/dBN12J2K4TDXE9vxeDVV2snyIkLiF6Dh/Eo/VQFgbI0wJ4IJGIE=
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 10A43458079; 
	Thu, 12 Jan 2012 08:37:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 330baa2bb903e24d67b7a8dba801e1de687e9ce2
Message-Id: <330baa2bb903e24d67b7.1326386501@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Jan 2012 11:41:41 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Testing for mem event ring management
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/xenpaging/Makefile  |    5 +-
 tools/xenpaging/memoper.c |  627 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 631 insertions(+), 1 deletions(-)


This is example code, not meant for tree consumption. So
that others can run tests on the ring management bits.

The testing works as follows:
1. start off a Linux HVM with 4 vcpus
2. ./memoper <domid>
(recommended to run memoper inside a screen -L session as it tends
to output a lot of stuff)
3. xl unpause <domid>
4. fireworks

To really drive the ring (assuming 1GB guest RAM and four vcpus):
6. on the domain console, remount tmpfs to /dev/shm (or wherever) with
size sufficient to consume most of the guest's RAM (e.g.
mount -o remount,size=1000000000)
7. on the domain console
for i in `seq 4`; do (dd if=/dev/zero of=/dev/shm/file.$i bs=1k count=255000)& done

More fireworks!

diff -r 24f43fcefc12 -r 330baa2bb903 tools/xenpaging/Makefile
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -15,10 +15,13 @@ CFLAGS   += -Wno-unused
 CFLAGS   += -g
 
 OBJS     = $(SRCS:.c=.o)
-IBINS    = xenpaging
+IBINS    = xenpaging memoper
 
 all: $(IBINS)
 
+memoper: memoper.o
+	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
+
 xenpaging: $(OBJS)
 	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS)
 
diff -r 24f43fcefc12 -r 330baa2bb903 tools/xenpaging/memoper.c
--- /dev/null
+++ b/tools/xenpaging/memoper.c
@@ -0,0 +1,627 @@
+/******************************************************************************
+ * tools/xenpaging/memoper.c
+ *
+ * Test tool for log memory accesses by guest.
+ * Copyright (c) 2011 by GridCentric, Inc. (Andres Lagar-Cavilla) 
+ *
+ * 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
+ */
+
+#define _XOPEN_SOURCE	600
+
+#include <inttypes.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <time.h>
+#include <signal.h>
+#include <unistd.h>
+#include <poll.h>
+#include <xc_private.h>
+#include <xs.h>
+#include "xenpaging.h"
+#include "xc_bitops.h"
+
+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
+#define NRPAGES(x) (ROUNDUP(x, PAGE_SHIFT) >> PAGE_SHIFT)
+
+/* Whether we signal resume to the hypervisor via domctl or event channel */
+#define USE_EVTCHN_DOMCTL 0
+
+typedef struct memaccess_s {
+    xc_interface *xc_handle;
+    struct xs_handle *xs_handle;
+
+    xc_domaininfo_t    *domain_info;
+
+    mem_event_t mem_event;
+} memaccess_t;
+
+static char watch_token[16];
+static int interrupted;
+DECLARE_HYPERCALL_BUFFER(unsigned long, dirty_bitmap);
+
+#undef DPRINTF
+#define DPRINTF(_f, _a ...) fprintf(stderr, _f, ##_a)
+
+static void close_handler(int sig)
+{
+    interrupted = sig;
+}
+
+static int wait_for_event_or_timeout(memaccess_t *memaccess)
+{
+    xc_interface *xch = memaccess->xc_handle;
+    xc_evtchn *xce = memaccess->mem_event.xce_handle;
+    char **vec;
+    unsigned int num;
+    struct pollfd fd[2];
+    int port;
+    int rc;
+
+    /* Wait for event channel and xenstore */
+    fd[0].fd = xc_evtchn_fd(xce);
+    fd[0].events = POLLIN | POLLERR;
+    fd[1].fd = xs_fileno(memaccess->xs_handle);
+    fd[1].events = POLLIN | POLLERR;
+
+    rc = poll(fd, 2, 100);
+    if ( rc < 0 )
+    {
+        if (errno == EINTR)
+            return 0;
+
+        ERROR("Poll exited with an error");
+        return -errno;
+    }
+
+    /* First check for guest shutdown */
+    if ( rc && fd[1].revents & POLLIN )
+    {
+        DPRINTF("Got event from xenstore\n");
+        vec = xs_read_watch(memaccess->xs_handle, &num);
+        if ( vec )
+        {
+            if ( strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 )
+            {
+                /* If our guest disappeared, set interrupt flag and fall through */
+                if ( xs_is_domain_introduced(memaccess->xs_handle, memaccess->mem_event.domain_id) == false )
+                {
+                    xs_unwatch(memaccess->xs_handle, "@releaseDomain", watch_token);
+                    interrupted = SIGQUIT;
+                    rc = 0;
+                }
+            }
+            free(vec);
+        }
+    }
+
+    if ( rc && fd[0].revents & POLLIN )
+    {
+	int rv;
+        DPRINTF("Got event from evtchn\n");
+        port = xc_evtchn_pending(xce);
+        if ( port == -1 )
+        {
+            ERROR("Failed to read port from event channel");
+            rc = -1;
+            goto err;
+        }
+
+        rv = xc_evtchn_unmask(xce, port);
+        if ( rv < 0 )
+        {
+            ERROR("Failed to unmask event channel port");
+        }
+    }
+err:
+    return rc;
+}
+
+static void *init_page(void)
+{
+    void *buffer;
+    int ret;
+
+    /* Allocated page memory */
+    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
+    if ( ret != 0 )
+        goto out_alloc;
+
+    /* Lock buffer in memory so it can't be paged out */
+    ret = mlock(buffer, PAGE_SIZE);
+    if ( ret != 0 )
+        goto out_lock;
+
+    return buffer;
+
+ out_init:
+    munlock(buffer, PAGE_SIZE);
+ out_lock:
+    free(buffer);
+ out_alloc:
+    return NULL;
+}
+
+static memaccess_t *access_init(domid_t domain_id)
+{
+    memaccess_t *memaccess;
+    xc_interface *xch;
+    xentoollog_logger *dbg = NULL;
+    char *p;
+    int rc;
+
+    xch = xc_interface_open(dbg, NULL, 0);
+    if ( !xch )
+        goto err_iface;
+
+    DPRINTF("access init\n");
+
+    /* Allocate memory */
+    memaccess = malloc(sizeof(memaccess_t));
+    memset(memaccess, 0, sizeof(memaccess_t));
+
+    /* Open connection to xenstore */
+    memaccess->xs_handle = xs_open(0);
+    if ( memaccess->xs_handle == NULL )
+    {
+        ERROR("Error initialising xenstore connection");
+        goto err;
+    }
+
+    /* write domain ID to watch so we can ignore other domain shutdowns */
+    snprintf(watch_token, sizeof(watch_token), "%u", domain_id);
+    if ( xs_watch(memaccess->xs_handle, "@releaseDomain", watch_token) == false )
+    {
+        ERROR("Could not bind to shutdown watch\n");
+        goto err;
+    }
+
+    /* Open connection to xen */
+    memaccess->xc_handle = xch;
+
+    /* Set domain id */
+    memaccess->mem_event.domain_id = domain_id;
+
+    /* Initialise shared page */
+    memaccess->mem_event.shared_page = init_page();
+    if ( memaccess->mem_event.shared_page == NULL )
+    {
+        ERROR("Error initialising shared page");
+        goto err;
+    }
+
+    /* Initialise ring page */
+    memaccess->mem_event.ring_page = init_page();
+    if ( memaccess->mem_event.ring_page == NULL )
+    {
+        ERROR("Error initialising ring page");
+        goto err;
+    }
+
+    /* Initialise ring */
+    SHARED_RING_INIT((mem_event_sring_t *)memaccess->mem_event.ring_page);
+    BACK_RING_INIT(&memaccess->mem_event.back_ring,
+                   (mem_event_sring_t *)memaccess->mem_event.ring_page,
+                   PAGE_SIZE);
+    
+    /* Initialise Xen */
+    rc = xc_mem_access_enable(xch, memaccess->mem_event.domain_id,
+                             memaccess->mem_event.shared_page,
+                             memaccess->mem_event.ring_page);
+    if ( rc != 0 )
+    {
+        switch ( errno ) {
+            case EBUSY:
+                ERROR("access is (or was) active on this domain");
+                break;
+            case ENODEV:
+                ERROR("EPT not supported for this guest");
+                break;
+            case EXDEV:
+                ERROR("access is not supported in a PoD guest");
+                break;
+            default:
+                ERROR("Error initialising shared page: %s", strerror(errno));
+                break;
+        }
+        goto err;
+    }
+
+    /* Open event channel */
+    memaccess->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
+    if ( memaccess->mem_event.xce_handle == NULL )
+    {
+        ERROR("Failed to open event channel");
+        goto err;
+    }
+
+    /* Bind event notification */
+    rc = xc_evtchn_bind_interdomain(memaccess->mem_event.xce_handle,
+                                    memaccess->mem_event.domain_id,
+                                    memaccess->mem_event.shared_page->port);
+    if ( rc < 0 )
+    {
+        ERROR("Failed to bind event channel");
+        goto err;
+    }
+
+    memaccess->mem_event.port = rc;
+
+    /* Get domaininfo */
+    memaccess->domain_info = malloc(sizeof(xc_domaininfo_t));
+    if ( memaccess->domain_info == NULL )
+    {
+        ERROR("Error allocating memory for domain info");
+        goto err;
+    }
+
+    rc = xc_domain_getinfolist(xch, memaccess->mem_event.domain_id, 1,
+                               memaccess->domain_info);
+    if ( rc != 1 )
+    {
+        ERROR("Error getting domain info");
+        goto err;
+    }
+    DPRINTF("max_pages = %"PRIx64"\n", memaccess->domain_info->max_pages);
+
+    return memaccess;
+
+ err:
+    if ( memaccess )
+    {
+        if ( memaccess->xs_handle )
+            xs_close(memaccess->xs_handle);
+        xc_interface_close(xch);
+        if ( memaccess->mem_event.shared_page )
+        {
+            munlock(memaccess->mem_event.shared_page, PAGE_SIZE);
+            free(memaccess->mem_event.shared_page);
+        }
+
+        if ( memaccess->mem_event.ring_page )
+        {
+            munlock(memaccess->mem_event.ring_page, PAGE_SIZE);
+            free(memaccess->mem_event.ring_page);
+        }
+
+        free(memaccess->domain_info);
+        free(memaccess);
+    }
+
+ err_iface: 
+    return NULL;
+}
+
+static int brick_domain(memaccess_t *memaccess, int *p2m_size)
+{
+    int max, rc;
+    unsigned long mb;
+    xc_interface *xch = memaccess->xc_handle;
+
+    (void)xc_domain_pause(xch, memaccess->mem_event.domain_id);
+
+    max = xc_domain_maximum_gpfn(xch, memaccess->mem_event.domain_id);
+    if (max <= 0) {
+        fprintf(stderr, "MAX GPFN WEIRDO %d\n", max);
+        return 1;
+    }
+    fprintf(stderr, "GPFN MAX %x\n", max);
+    *p2m_size = max;
+
+    dirty_bitmap = xc_hypercall_buffer_alloc_pages(memaccess->xc_handle, 
+			dirty_bitmap, NRPAGES(bitmap_size(*p2m_size)));
+    if ( !dirty_bitmap )
+    {
+        ERROR("ERROR for bitmap %d %d\n", *p2m_size, errno);
+        return 1;
+    }
+    /* No need to memset, pages are memset by libxc */
+   
+    mb = 64;/* TUNABLE!?!? */ 
+    if ( (rc = xc_shadow_control(xch, memaccess->mem_event.domain_id,
+                               XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION,
+                               NULL, 0, &mb, 0, NULL)) < 0 )
+    {
+        fprintf(stderr, "COULD NOT ALLOCATE SHADOW RAM FOR BITMAP "
+                            "rc %d errno %d\n", rc, errno);
+        return 1;
+    }
+ 
+    rc = xc_shadow_control(xch, memaccess->mem_event.domain_id,
+                                XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY,
+                                NULL, 0, NULL, 0, NULL);
+    
+    if ( rc < 0 )
+    {
+        fprintf(stderr, "Couldn't enable shadow mode (rc %d) "
+                    "(errno %d)\n", rc, errno );
+        /* log-dirty already enabled? There's no test op,
+           so attempt to disable then reenable it */
+        rc = xc_shadow_control(xch, memaccess->mem_event.domain_id, 
+                                    XEN_DOMCTL_SHADOW_OP_OFF,
+                                    NULL, 0, NULL, 0, NULL);
+        fprintf(stderr, "Disabling shadow log dirty yielded rc %d errno "
+                        "%d\n", rc, errno);
+        rc = xc_shadow_control(xch, memaccess->mem_event.domain_id,
+                                    XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY,
+                                    NULL, 0, NULL, 0, NULL);
+        
+        if ( rc < 0 )
+        {
+            fprintf(stderr, "Couldn't enable shadow mode (rc %d) "
+                        "(errno %d)\n", rc, errno );
+            return 1;
+        }
+    } else {
+
+        errno = 0;
+        rc = xc_shadow_control(xch, memaccess->mem_event.domain_id, 
+                          XEN_DOMCTL_SHADOW_OP_CLEAN,
+                          NULL, *p2m_size, NULL, 0, NULL);
+        fprintf(stderr, "SHADOW CLEAN RC %x errno %d\n", rc, errno);
+    }
+
+    rc = xc_hvm_set_mem_access(xch, memaccess->mem_event.domain_id,
+                                HVMMEM_access_n2rwx, 0, (uint64_t) *p2m_size);
+    if (rc) {
+        fprintf(stderr, "MEMTYPE RC %d %d\n", rc, errno);
+	if ( errno != ENOMEM )
+		/* We get ENOMEM when trying to set access rights on gfn's that
+		 * have _never_ been touched, to the extent the p2m doesn't 
+		 * even know about them. This is extremely unlikely to happen
+		 * for pages that the VM will end up actually accessing, for the 
+		 * the physmap is fully populated (pod, paged, shared, normal, 
+		 * whatever, populated nonetheless) up front.*/
+        return 1;
+    }
+
+    return 0;
+}
+
+static int access_teardown(memaccess_t *memaccess)
+{
+    int rc;
+    xc_interface *xch;
+
+    if ( memaccess == NULL )
+        return 0;
+
+    xch = memaccess->xc_handle;
+    memaccess->xc_handle = NULL;
+    /* Tear down domain access in Xen */
+    rc = xc_mem_access_disable(xch, memaccess->mem_event.domain_id);
+    if ( rc != 0 )
+    {
+        ERROR("Error tearing down domain access in xen");
+    }
+
+    /* Unbind VIRQ */
+    rc = xc_evtchn_unbind(memaccess->mem_event.xce_handle, memaccess->mem_event.port);
+    if ( rc != 0 )
+    {
+        ERROR("Error unbinding event port");
+    }
+    memaccess->mem_event.port = -1;
+
+    /* Close event channel */
+    rc = xc_evtchn_close(memaccess->mem_event.xce_handle);
+    if ( rc != 0 )
+    {
+        ERROR("Error closing event channel");
+    }
+    memaccess->mem_event.xce_handle = NULL;
+    
+    /* Close connection to xenstore */
+    xs_close(memaccess->xs_handle);
+
+    /* Close connection to Xen */
+    rc = xc_interface_close(xch);
+    if ( rc != 0 )
+    {
+        ERROR("Error closing connection to xen");
+    }
+
+    return 0;
+
+ err:
+    return -1;
+}
+
+static void get_request(mem_event_t *mem_event, mem_event_request_t *req)
+{
+    mem_event_back_ring_t *back_ring;
+    RING_IDX req_cons;
+
+    back_ring = &mem_event->back_ring;
+    req_cons = back_ring->req_cons;
+
+    /* Copy request */
+    memcpy(req, RING_GET_REQUEST(back_ring, req_cons), sizeof(*req));
+    req_cons++;
+
+    /* Update ring */
+    back_ring->req_cons = req_cons;
+    back_ring->sring->req_event = req_cons + 1;
+}
+
+static void put_response(mem_event_t *mem_event, mem_event_response_t *rsp)
+{
+    mem_event_back_ring_t *back_ring;
+    RING_IDX rsp_prod;
+
+    back_ring = &mem_event->back_ring;
+    rsp_prod = back_ring->rsp_prod_pvt;
+
+    /* Copy response */
+    memcpy(RING_GET_RESPONSE(back_ring, rsp_prod), rsp, sizeof(*rsp));
+    rsp_prod++;
+
+    /* Update ring */
+    back_ring->rsp_prod_pvt = rsp_prod;
+    RING_PUSH_RESPONSES(back_ring);
+}
+
+static int resume_page(memaccess_t *memaccess, mem_event_response_t *rsp, int notify_policy)
+{
+    int ret;
+
+    /* Put the page info on the ring */
+    put_response(&memaccess->mem_event, rsp);
+
+#if USE_EVTCHN_DOMCTL
+    /* Tell Xen page is ready */
+    ret = xc_mem_access_resume(memaccess->xc_handle, memaccess->mem_event.domain_id,
+                               rsp->gfn);
+    if ( ret == 0 ) 
+#endif
+        ret = xc_evtchn_notify(memaccess->mem_event.xce_handle,
+                               memaccess->mem_event.port);
+
+ out:
+    return ret;
+}
+
+
+int main(int argc, char *argv[])
+{
+    struct sigaction act;
+    memaccess_t *memaccess;
+    mem_event_request_t req;
+    mem_event_response_t rsp;
+    unsigned long i;
+    int rc = -1;
+    int rc1, frc, p2m_size;
+    xc_interface *xch;
+
+    /* Initialise domain access */
+    memaccess = access_init(atoi(argv[1]));
+    if ( memaccess == NULL )
+    {
+        fprintf(stderr, "Error initialising access");
+        return 1;
+    }
+    xch = memaccess->xc_handle;
+
+    if ( brick_domain(memaccess, &p2m_size) )
+    {
+        int rv;
+        fprintf(stderr, "Error bricking domain\n");
+        if ( (rv = access_teardown(memaccess)) )
+            fprintf(stderr, "Further, error %d errno %d when "
+                    "tearing down\n", rv, errno);
+        return 1;
+    }
+
+    DPRINTF("starting %s %u\n", argv[0], memaccess->mem_event.domain_id);
+
+    /* ensure that if we get a signal, we'll do cleanup, then exit */
+    act.sa_handler = close_handler;
+    act.sa_flags = 0;
+    sigemptyset(&act.sa_mask);
+    sigaction(SIGHUP,  &act, NULL);
+    sigaction(SIGTERM, &act, NULL);
+    sigaction(SIGINT,  &act, NULL);
+    sigaction(SIGALRM, &act, NULL);
+
+    /* Swap pages in and out */
+    while ( 1 )
+    {
+        /* Wait for Xen to signal that a page needs paged in */
+#ifdef SLEEP_TEST_RING
+	/* SLEEP FOR TEST */ usleep(1000*1000*10);
+#endif
+        rc = wait_for_event_or_timeout(memaccess);
+        if ( rc < 0 )
+        {
+            ERROR("Error getting event");
+            goto out;
+        }
+        else if ( rc != 0 )
+        {
+            DPRINTF("Got event from Xen\n");
+        }
+
+        while ( RING_HAS_UNCONSUMED_REQUESTS(&memaccess->mem_event.back_ring) )
+        {
+            get_request(&memaccess->mem_event, &req);
+
+            DPRINTF("page accessed (domain = %d; vcpu = %d;"
+                    " gfn = %"PRIx64"; paused = %d)  %c%c%c\n",
+                    memaccess->mem_event.domain_id, req.vcpu_id, req.gfn,
+                    !!(req.flags & MEM_EVENT_FLAG_VCPU_PAUSED),
+			req.access_r ? 'R' : '-',
+			req.access_w ? 'W' : '-',
+			req.access_x ? 'X' : '-');
+
+            /* Tell Xen we consumed the event so it doesn't stall */
+            /* Prepare the response */
+            rsp.gfn = req.gfn;
+            rsp.vcpu_id = req.vcpu_id;
+            rsp.flags = req.flags;
+
+            rc = resume_page(memaccess, &rsp, 0);
+            if ( rc != 0 )
+            {
+                ERROR("Error resuming");
+                goto out;
+            }
+        }
+
+        /* Exit on any signal */
+        if ( interrupted )
+            break;
+    }
+    DPRINTF("%s got signal %d\n", argv[0], interrupted);
+
+    frc = xc_shadow_control(
+        memaccess->xc_handle, memaccess->mem_event.domain_id, 
+        XEN_DOMCTL_SHADOW_OP_CLEAN, HYPERCALL_BUFFER(dirty_bitmap),
+        p2m_size, NULL, 0, NULL);
+    if ( frc != p2m_size )
+    {
+        ERROR("Error peeking shadow bitmap");
+        xc_hypercall_buffer_free_pages(memaccess->xc_handle, dirty_bitmap, 
+                                    NRPAGES(bitmap_size(p2m_size)));
+        goto out;
+    }
+
+    for ( i = 0; i < p2m_size; i++)
+        if (test_bit(i, dirty_bitmap))
+            DPRINTF("GFN %lx DIRTY\n", i);
+
+    (void)xc_hypercall_buffer_free_pages(memaccess->xc_handle, dirty_bitmap, 
+                                          NRPAGES(bitmap_size(p2m_size)));
+
+ out:
+
+    /* Tear down */
+    rc1 = access_teardown(memaccess);
+    if ( rc1 != 0 )
+        fprintf(stderr, "Error tearing down\n");
+
+    if ( rc == 0 )
+        rc = rc1;
+    return rc;
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End: 
+ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:37:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNeT-00028A-5Y; Thu, 12 Jan 2012 16:37:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RlNeR-00027u-Et
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:37:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326386108!48296310!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzA2NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27927 invoked from network); 12 Jan 2012 16:35:09 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.83) by server-14.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 16:35:09 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id D4B6145807B;
	Thu, 12 Jan 2012 08:37:16 -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=B+GJQQtCWaCY7sQ4nqys42
	owiZUkYWfMBETLSiQOhTUW33KVM+jYrX2fujTm6wUd8KigtfrTGhw2EcOeQRy50A
	gYedFWJ9xXqsTIA7kv/EORZcR4z9vUTF+skymMbvI6qI8dxH/EbyOgOgTHlCFBq8
	moZhsGII231x4L6gzCLAw=
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=h0eZE/YBha7H
	JEjGT5+C9bNCJrY=; b=dYiPGFQez2Z4xKtPvAKuPHVbyH4MTFy6bulQzyZhrqaj
	dxoi/hkvMr5YBGbAeqflEcXHjsHItF13xsH6Dsd74oEQYbBNysEVlQ/TeRnTnWFx
	Nb7milmxrmE/dBN12J2K4TDXE9vxeDVV2snyIkLiF6Dh/Eo/VQFgbI0wJ4IJGIE=
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 10A43458079; 
	Thu, 12 Jan 2012 08:37:15 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 330baa2bb903e24d67b7a8dba801e1de687e9ce2
Message-Id: <330baa2bb903e24d67b7.1326386501@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Jan 2012 11:41:41 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Testing for mem event ring management
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/xenpaging/Makefile  |    5 +-
 tools/xenpaging/memoper.c |  627 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 631 insertions(+), 1 deletions(-)


This is example code, not meant for tree consumption. So
that others can run tests on the ring management bits.

The testing works as follows:
1. start off a Linux HVM with 4 vcpus
2. ./memoper <domid>
(recommended to run memoper inside a screen -L session as it tends
to output a lot of stuff)
3. xl unpause <domid>
4. fireworks

To really drive the ring (assuming 1GB guest RAM and four vcpus):
6. on the domain console, remount tmpfs to /dev/shm (or wherever) with
size sufficient to consume most of the guest's RAM (e.g.
mount -o remount,size=1000000000)
7. on the domain console
for i in `seq 4`; do (dd if=/dev/zero of=/dev/shm/file.$i bs=1k count=255000)& done

More fireworks!

diff -r 24f43fcefc12 -r 330baa2bb903 tools/xenpaging/Makefile
--- a/tools/xenpaging/Makefile
+++ b/tools/xenpaging/Makefile
@@ -15,10 +15,13 @@ CFLAGS   += -Wno-unused
 CFLAGS   += -g
 
 OBJS     = $(SRCS:.c=.o)
-IBINS    = xenpaging
+IBINS    = xenpaging memoper
 
 all: $(IBINS)
 
+memoper: memoper.o
+	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)
+
 xenpaging: $(OBJS)
 	$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS)
 
diff -r 24f43fcefc12 -r 330baa2bb903 tools/xenpaging/memoper.c
--- /dev/null
+++ b/tools/xenpaging/memoper.c
@@ -0,0 +1,627 @@
+/******************************************************************************
+ * tools/xenpaging/memoper.c
+ *
+ * Test tool for log memory accesses by guest.
+ * Copyright (c) 2011 by GridCentric, Inc. (Andres Lagar-Cavilla) 
+ *
+ * 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
+ */
+
+#define _XOPEN_SOURCE	600
+
+#include <inttypes.h>
+#include <stdlib.h>
+#include <stdarg.h>
+#include <time.h>
+#include <signal.h>
+#include <unistd.h>
+#include <poll.h>
+#include <xc_private.h>
+#include <xs.h>
+#include "xenpaging.h"
+#include "xc_bitops.h"
+
+#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
+#define NRPAGES(x) (ROUNDUP(x, PAGE_SHIFT) >> PAGE_SHIFT)
+
+/* Whether we signal resume to the hypervisor via domctl or event channel */
+#define USE_EVTCHN_DOMCTL 0
+
+typedef struct memaccess_s {
+    xc_interface *xc_handle;
+    struct xs_handle *xs_handle;
+
+    xc_domaininfo_t    *domain_info;
+
+    mem_event_t mem_event;
+} memaccess_t;
+
+static char watch_token[16];
+static int interrupted;
+DECLARE_HYPERCALL_BUFFER(unsigned long, dirty_bitmap);
+
+#undef DPRINTF
+#define DPRINTF(_f, _a ...) fprintf(stderr, _f, ##_a)
+
+static void close_handler(int sig)
+{
+    interrupted = sig;
+}
+
+static int wait_for_event_or_timeout(memaccess_t *memaccess)
+{
+    xc_interface *xch = memaccess->xc_handle;
+    xc_evtchn *xce = memaccess->mem_event.xce_handle;
+    char **vec;
+    unsigned int num;
+    struct pollfd fd[2];
+    int port;
+    int rc;
+
+    /* Wait for event channel and xenstore */
+    fd[0].fd = xc_evtchn_fd(xce);
+    fd[0].events = POLLIN | POLLERR;
+    fd[1].fd = xs_fileno(memaccess->xs_handle);
+    fd[1].events = POLLIN | POLLERR;
+
+    rc = poll(fd, 2, 100);
+    if ( rc < 0 )
+    {
+        if (errno == EINTR)
+            return 0;
+
+        ERROR("Poll exited with an error");
+        return -errno;
+    }
+
+    /* First check for guest shutdown */
+    if ( rc && fd[1].revents & POLLIN )
+    {
+        DPRINTF("Got event from xenstore\n");
+        vec = xs_read_watch(memaccess->xs_handle, &num);
+        if ( vec )
+        {
+            if ( strcmp(vec[XS_WATCH_TOKEN], watch_token) == 0 )
+            {
+                /* If our guest disappeared, set interrupt flag and fall through */
+                if ( xs_is_domain_introduced(memaccess->xs_handle, memaccess->mem_event.domain_id) == false )
+                {
+                    xs_unwatch(memaccess->xs_handle, "@releaseDomain", watch_token);
+                    interrupted = SIGQUIT;
+                    rc = 0;
+                }
+            }
+            free(vec);
+        }
+    }
+
+    if ( rc && fd[0].revents & POLLIN )
+    {
+	int rv;
+        DPRINTF("Got event from evtchn\n");
+        port = xc_evtchn_pending(xce);
+        if ( port == -1 )
+        {
+            ERROR("Failed to read port from event channel");
+            rc = -1;
+            goto err;
+        }
+
+        rv = xc_evtchn_unmask(xce, port);
+        if ( rv < 0 )
+        {
+            ERROR("Failed to unmask event channel port");
+        }
+    }
+err:
+    return rc;
+}
+
+static void *init_page(void)
+{
+    void *buffer;
+    int ret;
+
+    /* Allocated page memory */
+    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
+    if ( ret != 0 )
+        goto out_alloc;
+
+    /* Lock buffer in memory so it can't be paged out */
+    ret = mlock(buffer, PAGE_SIZE);
+    if ( ret != 0 )
+        goto out_lock;
+
+    return buffer;
+
+ out_init:
+    munlock(buffer, PAGE_SIZE);
+ out_lock:
+    free(buffer);
+ out_alloc:
+    return NULL;
+}
+
+static memaccess_t *access_init(domid_t domain_id)
+{
+    memaccess_t *memaccess;
+    xc_interface *xch;
+    xentoollog_logger *dbg = NULL;
+    char *p;
+    int rc;
+
+    xch = xc_interface_open(dbg, NULL, 0);
+    if ( !xch )
+        goto err_iface;
+
+    DPRINTF("access init\n");
+
+    /* Allocate memory */
+    memaccess = malloc(sizeof(memaccess_t));
+    memset(memaccess, 0, sizeof(memaccess_t));
+
+    /* Open connection to xenstore */
+    memaccess->xs_handle = xs_open(0);
+    if ( memaccess->xs_handle == NULL )
+    {
+        ERROR("Error initialising xenstore connection");
+        goto err;
+    }
+
+    /* write domain ID to watch so we can ignore other domain shutdowns */
+    snprintf(watch_token, sizeof(watch_token), "%u", domain_id);
+    if ( xs_watch(memaccess->xs_handle, "@releaseDomain", watch_token) == false )
+    {
+        ERROR("Could not bind to shutdown watch\n");
+        goto err;
+    }
+
+    /* Open connection to xen */
+    memaccess->xc_handle = xch;
+
+    /* Set domain id */
+    memaccess->mem_event.domain_id = domain_id;
+
+    /* Initialise shared page */
+    memaccess->mem_event.shared_page = init_page();
+    if ( memaccess->mem_event.shared_page == NULL )
+    {
+        ERROR("Error initialising shared page");
+        goto err;
+    }
+
+    /* Initialise ring page */
+    memaccess->mem_event.ring_page = init_page();
+    if ( memaccess->mem_event.ring_page == NULL )
+    {
+        ERROR("Error initialising ring page");
+        goto err;
+    }
+
+    /* Initialise ring */
+    SHARED_RING_INIT((mem_event_sring_t *)memaccess->mem_event.ring_page);
+    BACK_RING_INIT(&memaccess->mem_event.back_ring,
+                   (mem_event_sring_t *)memaccess->mem_event.ring_page,
+                   PAGE_SIZE);
+    
+    /* Initialise Xen */
+    rc = xc_mem_access_enable(xch, memaccess->mem_event.domain_id,
+                             memaccess->mem_event.shared_page,
+                             memaccess->mem_event.ring_page);
+    if ( rc != 0 )
+    {
+        switch ( errno ) {
+            case EBUSY:
+                ERROR("access is (or was) active on this domain");
+                break;
+            case ENODEV:
+                ERROR("EPT not supported for this guest");
+                break;
+            case EXDEV:
+                ERROR("access is not supported in a PoD guest");
+                break;
+            default:
+                ERROR("Error initialising shared page: %s", strerror(errno));
+                break;
+        }
+        goto err;
+    }
+
+    /* Open event channel */
+    memaccess->mem_event.xce_handle = xc_evtchn_open(NULL, 0);
+    if ( memaccess->mem_event.xce_handle == NULL )
+    {
+        ERROR("Failed to open event channel");
+        goto err;
+    }
+
+    /* Bind event notification */
+    rc = xc_evtchn_bind_interdomain(memaccess->mem_event.xce_handle,
+                                    memaccess->mem_event.domain_id,
+                                    memaccess->mem_event.shared_page->port);
+    if ( rc < 0 )
+    {
+        ERROR("Failed to bind event channel");
+        goto err;
+    }
+
+    memaccess->mem_event.port = rc;
+
+    /* Get domaininfo */
+    memaccess->domain_info = malloc(sizeof(xc_domaininfo_t));
+    if ( memaccess->domain_info == NULL )
+    {
+        ERROR("Error allocating memory for domain info");
+        goto err;
+    }
+
+    rc = xc_domain_getinfolist(xch, memaccess->mem_event.domain_id, 1,
+                               memaccess->domain_info);
+    if ( rc != 1 )
+    {
+        ERROR("Error getting domain info");
+        goto err;
+    }
+    DPRINTF("max_pages = %"PRIx64"\n", memaccess->domain_info->max_pages);
+
+    return memaccess;
+
+ err:
+    if ( memaccess )
+    {
+        if ( memaccess->xs_handle )
+            xs_close(memaccess->xs_handle);
+        xc_interface_close(xch);
+        if ( memaccess->mem_event.shared_page )
+        {
+            munlock(memaccess->mem_event.shared_page, PAGE_SIZE);
+            free(memaccess->mem_event.shared_page);
+        }
+
+        if ( memaccess->mem_event.ring_page )
+        {
+            munlock(memaccess->mem_event.ring_page, PAGE_SIZE);
+            free(memaccess->mem_event.ring_page);
+        }
+
+        free(memaccess->domain_info);
+        free(memaccess);
+    }
+
+ err_iface: 
+    return NULL;
+}
+
+static int brick_domain(memaccess_t *memaccess, int *p2m_size)
+{
+    int max, rc;
+    unsigned long mb;
+    xc_interface *xch = memaccess->xc_handle;
+
+    (void)xc_domain_pause(xch, memaccess->mem_event.domain_id);
+
+    max = xc_domain_maximum_gpfn(xch, memaccess->mem_event.domain_id);
+    if (max <= 0) {
+        fprintf(stderr, "MAX GPFN WEIRDO %d\n", max);
+        return 1;
+    }
+    fprintf(stderr, "GPFN MAX %x\n", max);
+    *p2m_size = max;
+
+    dirty_bitmap = xc_hypercall_buffer_alloc_pages(memaccess->xc_handle, 
+			dirty_bitmap, NRPAGES(bitmap_size(*p2m_size)));
+    if ( !dirty_bitmap )
+    {
+        ERROR("ERROR for bitmap %d %d\n", *p2m_size, errno);
+        return 1;
+    }
+    /* No need to memset, pages are memset by libxc */
+   
+    mb = 64;/* TUNABLE!?!? */ 
+    if ( (rc = xc_shadow_control(xch, memaccess->mem_event.domain_id,
+                               XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION,
+                               NULL, 0, &mb, 0, NULL)) < 0 )
+    {
+        fprintf(stderr, "COULD NOT ALLOCATE SHADOW RAM FOR BITMAP "
+                            "rc %d errno %d\n", rc, errno);
+        return 1;
+    }
+ 
+    rc = xc_shadow_control(xch, memaccess->mem_event.domain_id,
+                                XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY,
+                                NULL, 0, NULL, 0, NULL);
+    
+    if ( rc < 0 )
+    {
+        fprintf(stderr, "Couldn't enable shadow mode (rc %d) "
+                    "(errno %d)\n", rc, errno );
+        /* log-dirty already enabled? There's no test op,
+           so attempt to disable then reenable it */
+        rc = xc_shadow_control(xch, memaccess->mem_event.domain_id, 
+                                    XEN_DOMCTL_SHADOW_OP_OFF,
+                                    NULL, 0, NULL, 0, NULL);
+        fprintf(stderr, "Disabling shadow log dirty yielded rc %d errno "
+                        "%d\n", rc, errno);
+        rc = xc_shadow_control(xch, memaccess->mem_event.domain_id,
+                                    XEN_DOMCTL_SHADOW_OP_ENABLE_LOGDIRTY,
+                                    NULL, 0, NULL, 0, NULL);
+        
+        if ( rc < 0 )
+        {
+            fprintf(stderr, "Couldn't enable shadow mode (rc %d) "
+                        "(errno %d)\n", rc, errno );
+            return 1;
+        }
+    } else {
+
+        errno = 0;
+        rc = xc_shadow_control(xch, memaccess->mem_event.domain_id, 
+                          XEN_DOMCTL_SHADOW_OP_CLEAN,
+                          NULL, *p2m_size, NULL, 0, NULL);
+        fprintf(stderr, "SHADOW CLEAN RC %x errno %d\n", rc, errno);
+    }
+
+    rc = xc_hvm_set_mem_access(xch, memaccess->mem_event.domain_id,
+                                HVMMEM_access_n2rwx, 0, (uint64_t) *p2m_size);
+    if (rc) {
+        fprintf(stderr, "MEMTYPE RC %d %d\n", rc, errno);
+	if ( errno != ENOMEM )
+		/* We get ENOMEM when trying to set access rights on gfn's that
+		 * have _never_ been touched, to the extent the p2m doesn't 
+		 * even know about them. This is extremely unlikely to happen
+		 * for pages that the VM will end up actually accessing, for the 
+		 * the physmap is fully populated (pod, paged, shared, normal, 
+		 * whatever, populated nonetheless) up front.*/
+        return 1;
+    }
+
+    return 0;
+}
+
+static int access_teardown(memaccess_t *memaccess)
+{
+    int rc;
+    xc_interface *xch;
+
+    if ( memaccess == NULL )
+        return 0;
+
+    xch = memaccess->xc_handle;
+    memaccess->xc_handle = NULL;
+    /* Tear down domain access in Xen */
+    rc = xc_mem_access_disable(xch, memaccess->mem_event.domain_id);
+    if ( rc != 0 )
+    {
+        ERROR("Error tearing down domain access in xen");
+    }
+
+    /* Unbind VIRQ */
+    rc = xc_evtchn_unbind(memaccess->mem_event.xce_handle, memaccess->mem_event.port);
+    if ( rc != 0 )
+    {
+        ERROR("Error unbinding event port");
+    }
+    memaccess->mem_event.port = -1;
+
+    /* Close event channel */
+    rc = xc_evtchn_close(memaccess->mem_event.xce_handle);
+    if ( rc != 0 )
+    {
+        ERROR("Error closing event channel");
+    }
+    memaccess->mem_event.xce_handle = NULL;
+    
+    /* Close connection to xenstore */
+    xs_close(memaccess->xs_handle);
+
+    /* Close connection to Xen */
+    rc = xc_interface_close(xch);
+    if ( rc != 0 )
+    {
+        ERROR("Error closing connection to xen");
+    }
+
+    return 0;
+
+ err:
+    return -1;
+}
+
+static void get_request(mem_event_t *mem_event, mem_event_request_t *req)
+{
+    mem_event_back_ring_t *back_ring;
+    RING_IDX req_cons;
+
+    back_ring = &mem_event->back_ring;
+    req_cons = back_ring->req_cons;
+
+    /* Copy request */
+    memcpy(req, RING_GET_REQUEST(back_ring, req_cons), sizeof(*req));
+    req_cons++;
+
+    /* Update ring */
+    back_ring->req_cons = req_cons;
+    back_ring->sring->req_event = req_cons + 1;
+}
+
+static void put_response(mem_event_t *mem_event, mem_event_response_t *rsp)
+{
+    mem_event_back_ring_t *back_ring;
+    RING_IDX rsp_prod;
+
+    back_ring = &mem_event->back_ring;
+    rsp_prod = back_ring->rsp_prod_pvt;
+
+    /* Copy response */
+    memcpy(RING_GET_RESPONSE(back_ring, rsp_prod), rsp, sizeof(*rsp));
+    rsp_prod++;
+
+    /* Update ring */
+    back_ring->rsp_prod_pvt = rsp_prod;
+    RING_PUSH_RESPONSES(back_ring);
+}
+
+static int resume_page(memaccess_t *memaccess, mem_event_response_t *rsp, int notify_policy)
+{
+    int ret;
+
+    /* Put the page info on the ring */
+    put_response(&memaccess->mem_event, rsp);
+
+#if USE_EVTCHN_DOMCTL
+    /* Tell Xen page is ready */
+    ret = xc_mem_access_resume(memaccess->xc_handle, memaccess->mem_event.domain_id,
+                               rsp->gfn);
+    if ( ret == 0 ) 
+#endif
+        ret = xc_evtchn_notify(memaccess->mem_event.xce_handle,
+                               memaccess->mem_event.port);
+
+ out:
+    return ret;
+}
+
+
+int main(int argc, char *argv[])
+{
+    struct sigaction act;
+    memaccess_t *memaccess;
+    mem_event_request_t req;
+    mem_event_response_t rsp;
+    unsigned long i;
+    int rc = -1;
+    int rc1, frc, p2m_size;
+    xc_interface *xch;
+
+    /* Initialise domain access */
+    memaccess = access_init(atoi(argv[1]));
+    if ( memaccess == NULL )
+    {
+        fprintf(stderr, "Error initialising access");
+        return 1;
+    }
+    xch = memaccess->xc_handle;
+
+    if ( brick_domain(memaccess, &p2m_size) )
+    {
+        int rv;
+        fprintf(stderr, "Error bricking domain\n");
+        if ( (rv = access_teardown(memaccess)) )
+            fprintf(stderr, "Further, error %d errno %d when "
+                    "tearing down\n", rv, errno);
+        return 1;
+    }
+
+    DPRINTF("starting %s %u\n", argv[0], memaccess->mem_event.domain_id);
+
+    /* ensure that if we get a signal, we'll do cleanup, then exit */
+    act.sa_handler = close_handler;
+    act.sa_flags = 0;
+    sigemptyset(&act.sa_mask);
+    sigaction(SIGHUP,  &act, NULL);
+    sigaction(SIGTERM, &act, NULL);
+    sigaction(SIGINT,  &act, NULL);
+    sigaction(SIGALRM, &act, NULL);
+
+    /* Swap pages in and out */
+    while ( 1 )
+    {
+        /* Wait for Xen to signal that a page needs paged in */
+#ifdef SLEEP_TEST_RING
+	/* SLEEP FOR TEST */ usleep(1000*1000*10);
+#endif
+        rc = wait_for_event_or_timeout(memaccess);
+        if ( rc < 0 )
+        {
+            ERROR("Error getting event");
+            goto out;
+        }
+        else if ( rc != 0 )
+        {
+            DPRINTF("Got event from Xen\n");
+        }
+
+        while ( RING_HAS_UNCONSUMED_REQUESTS(&memaccess->mem_event.back_ring) )
+        {
+            get_request(&memaccess->mem_event, &req);
+
+            DPRINTF("page accessed (domain = %d; vcpu = %d;"
+                    " gfn = %"PRIx64"; paused = %d)  %c%c%c\n",
+                    memaccess->mem_event.domain_id, req.vcpu_id, req.gfn,
+                    !!(req.flags & MEM_EVENT_FLAG_VCPU_PAUSED),
+			req.access_r ? 'R' : '-',
+			req.access_w ? 'W' : '-',
+			req.access_x ? 'X' : '-');
+
+            /* Tell Xen we consumed the event so it doesn't stall */
+            /* Prepare the response */
+            rsp.gfn = req.gfn;
+            rsp.vcpu_id = req.vcpu_id;
+            rsp.flags = req.flags;
+
+            rc = resume_page(memaccess, &rsp, 0);
+            if ( rc != 0 )
+            {
+                ERROR("Error resuming");
+                goto out;
+            }
+        }
+
+        /* Exit on any signal */
+        if ( interrupted )
+            break;
+    }
+    DPRINTF("%s got signal %d\n", argv[0], interrupted);
+
+    frc = xc_shadow_control(
+        memaccess->xc_handle, memaccess->mem_event.domain_id, 
+        XEN_DOMCTL_SHADOW_OP_CLEAN, HYPERCALL_BUFFER(dirty_bitmap),
+        p2m_size, NULL, 0, NULL);
+    if ( frc != p2m_size )
+    {
+        ERROR("Error peeking shadow bitmap");
+        xc_hypercall_buffer_free_pages(memaccess->xc_handle, dirty_bitmap, 
+                                    NRPAGES(bitmap_size(p2m_size)));
+        goto out;
+    }
+
+    for ( i = 0; i < p2m_size; i++)
+        if (test_bit(i, dirty_bitmap))
+            DPRINTF("GFN %lx DIRTY\n", i);
+
+    (void)xc_hypercall_buffer_free_pages(memaccess->xc_handle, dirty_bitmap, 
+                                          NRPAGES(bitmap_size(p2m_size)));
+
+ out:
+
+    /* Tear down */
+    rc1 = access_teardown(memaccess);
+    if ( rc1 != 0 )
+        fprintf(stderr, "Error tearing down\n");
+
+    if ( rc == 0 )
+        rc = rc1;
+    return rc;
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End: 
+ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:38:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNfh-0002D4-L3; Thu, 12 Jan 2012 16:38:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RlNff-0002Cf-Sl
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:38:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326386306!8825640!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 25388 invoked from network); 12 Jan 2012 16:38:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 16:38:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 16:38:26 +0000
Message-Id: <4F0F1ACA020000780006C2E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 16:39:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F0EE1EC020000780006C16D@nat28.tlf.novell.com>
	<CB349973.288E2%keir.xen@gmail.com>
In-Reply-To: <CB349973.288E2%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/2] enforce inclusion of xen/config.h (Re:
 [PATCH] x86: move and fold certain type property 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.01.12 at 15:06, Keir Fraser <keir.xen@gmail.com> wrote:
> On 12/01/2012 12:36, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Not only is it less code to have them consolidated, it also permits
>> their use virtually everywhere (since config.h is required to be
>> included everywhere. (Shouldn't we, btw, follow Linux and remove the
>> explicit inclusion in favor of command line enforced one?)
> 
> Yes, could do.

This pair of patches starts this process.

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 Thu Jan 12 16:38:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:38:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNfh-0002D4-L3; Thu, 12 Jan 2012 16:38:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RlNff-0002Cf-Sl
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:38:36 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326386306!8825640!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 25388 invoked from network); 12 Jan 2012 16:38:27 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 16:38:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 16:38:26 +0000
Message-Id: <4F0F1ACA020000780006C2E3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 16:39:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F0EE1EC020000780006C16D@nat28.tlf.novell.com>
	<CB349973.288E2%keir.xen@gmail.com>
In-Reply-To: <CB349973.288E2%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH 0/2] enforce inclusion of xen/config.h (Re:
 [PATCH] x86: move and fold certain type property 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.01.12 at 15:06, Keir Fraser <keir.xen@gmail.com> wrote:
> On 12/01/2012 12:36, "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> Not only is it less code to have them consolidated, it also permits
>> their use virtually everywhere (since config.h is required to be
>> included everywhere. (Shouldn't we, btw, follow Linux and remove the
>> explicit inclusion in favor of command line enforced one?)
> 
> Yes, could do.

This pair of patches starts this process.

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 Thu Jan 12 16:39:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNgQ-0002HR-2f; Thu, 12 Jan 2012 16:39:22 +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 1RlNgN-0002GV-Io
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:39:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326386351!8899390!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 1613 invoked from network); 12 Jan 2012 16:39:11 -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 Jan 2012 16:39:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 16:39:10 +0000
Message-Id: <4F0F1AF7020000780006C2E7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 16:40:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD3FD9EF7.1__="
Subject: [Xen-devel] [PATCH 1/2] force inclusion of xen/config.h through
 compiler option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartD3FD9EF7.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As we expect all source files to include the header as the first thing
anyway, stop doing this by repeating the inclusion in each and every
source file (and in many headers), but rather enforce this uniformly
through the compiler command line.

As a first cleanup step, remove the explicit inclusion from all common
headers. Further cleanup can be done incrementally.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -41,7 +41,7 @@ ALL_OBJS-y               +=3D $(BASEDIR)/x
 ALL_OBJS-y               +=3D $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(x86)          +=3D $(BASEDIR)/crypto/built_in.o
=20
-CFLAGS-y                +=3D -g -D__XEN__
+CFLAGS-y                +=3D -g -D__XEN__ --include $(BASEDIR)/include/xen=
/config.h
 CFLAGS-$(XSM_ENABLE)    +=3D -DXSM_ENABLE
 CFLAGS-$(FLASK_ENABLE)  +=3D -DFLASK_ENABLE -DXSM_MAGIC=3D0xf97cff8c
 CFLAGS-$(FLASK_ENABLE)  +=3D -DFLASK_DEVELOP -DFLASK_BOOTPARAM -DFLASK_AVC=
_STATS
@@ -59,7 +59,7 @@ ifneq ($(max_phys_irqs),)
 CFLAGS-y                +=3D -DMAX_PHYS_IRQS=3D$(max_phys_irqs)
 endif
=20
-AFLAGS-y                +=3D -D__ASSEMBLY__
+AFLAGS-y                +=3D -D__ASSEMBLY__ --include $(BASEDIR)/include/x=
en/config.h
=20
 # Clang's built-in assembler can't handle .code16/.code32/.code64 yet
 AFLAGS-$(clang)         +=3D -no-integrated-as
--- a/xen/include/xen/bitmap.h
+++ b/xen/include/xen/bitmap.h
@@ -3,7 +3,6 @@
=20
 #ifndef __ASSEMBLY__
=20
-#include <xen/config.h>
 #include <xen/lib.h>
 #include <xen/types.h>
 #include <xen/bitops.h>
--- a/xen/include/xen/byteorder/swab.h
+++ b/xen/include/xen/byteorder/swab.h
@@ -10,8 +10,6 @@
  *    to clean up support for bizarre-endian architectures.
  */
=20
-#include <xen/compiler.h>
-
 /* casts are necessary for constants, because we never know how for sure
  * how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable =
way.
  */
--- a/xen/include/xen/cache.h
+++ b/xen/include/xen/cache.h
@@ -1,7 +1,6 @@
 #ifndef __LINUX_CACHE_H
 #define __LINUX_CACHE_H
=20
-#include <xen/config.h>
 #include <asm/cache.h>
=20
 #ifndef L1_CACHE_ALIGN
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -5,8 +5,6 @@
 #ifndef __XEN_COMPAT_H__
 #define __XEN_COMPAT_H__
=20
-#include <xen/config.h>
-
 #ifdef CONFIG_COMPAT
=20
 #include <xen/types.h>
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -75,7 +75,6 @@
  *    inside a macro, the way we do the other calls.
  */
=20
-#include <xen/config.h>
 #include <xen/bitmap.h>
 #include <xen/kernel.h>
=20
--- a/xen/include/xen/ctype.h
+++ b/xen/include/xen/ctype.h
@@ -1,8 +1,6 @@
 #ifndef _LINUX_CTYPE_H
 #define _LINUX_CTYPE_H
=20
-#include <xen/config.h>
-
 /*
  * NOTE! This ctype does not handle EOF like the standard C
  * library is required to.
--- a/xen/include/xen/domain_page.h
+++ b/xen/include/xen/domain_page.h
@@ -9,7 +9,6 @@
 #ifndef __XEN_DOMAIN_PAGE_H__
 #define __XEN_DOMAIN_PAGE_H__
=20
-#include <xen/config.h>
 #include <xen/mm.h>
=20
 #ifdef CONFIG_DOMAIN_PAGE
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -9,7 +9,6 @@
 #ifndef __XEN_EVENT_H__
 #define __XEN_EVENT_H__
=20
-#include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/softirq.h>
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -24,7 +24,6 @@
 #ifndef __XEN_GRANT_TABLE_H__
 #define __XEN_GRANT_TABLE_H__
=20
-#include <xen/config.h>
 #include <public/grant_table.h>
 #include <asm/grant_table.h>
=20
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -5,7 +5,6 @@
 #ifndef __XEN_HYPERCALL_H__
 #define __XEN_HYPERCALL_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/time.h>
 #include <public/xen.h>
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -1,7 +1,6 @@
 #ifndef _LINUX_INIT_H
 #define _LINUX_INIT_H
=20
-#include <xen/config.h>
 #include <asm/init.h>
=20
 /*
--- a/xen/include/xen/inttypes.h
+++ b/xen/include/xen/inttypes.h
@@ -23,7 +23,6 @@
 #ifndef _XEN_INTTYPES_H
 #define _XEN_INTTYPES_H	1
=20
-#include <xen/config.h>
 #include <xen/types.h>
=20
 # if BITS_PER_LONG =3D=3D 64
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -1,7 +1,6 @@
 #ifndef __XEN_IRQ_H__
 #define __XEN_IRQ_H__
=20
-#include <xen/config.h>
 #include <xen/cpumask.h>
 #include <xen/rcupdate.h>
 #include <xen/spinlock.h>
--- a/xen/include/xen/irq_cpustat.h
+++ b/xen/include/xen/irq_cpustat.h
@@ -9,7 +9,6 @@
  * Keith Owens <kaos@ocs.com.au> July 2000.
  */
=20
-#include <xen/config.h>
 #include <asm/hardirq.h>
=20
 /*
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -3,7 +3,6 @@
=20
 #include <xen/inttypes.h>
 #include <xen/stdarg.h>
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/xmalloc.h>
 #include <xen/string.h>
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -28,7 +28,6 @@
 #ifndef __XEN_MM_H__
 #define __XEN_MM_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
--- a/xen/include/xen/notifier.h
+++ b/xen/include/xen/notifier.h
@@ -10,7 +10,6 @@
 #ifndef __XEN_NOTIFIER_H__
 #define __XEN_NOTIFIER_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/errno.h>
 #include <xen/kernel.h>
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -1,7 +1,6 @@
 #ifndef _XEN_NUMA_H
 #define _XEN_NUMA_H
=20
-#include <xen/config.h>
 #include <asm/numa.h>
=20
 #ifndef NODES_SHIFT
--- a/xen/include/xen/paging.h
+++ b/xen/include/xen/paging.h
@@ -2,8 +2,6 @@
 #ifndef __XEN_PAGING_H__
 #define __XEN_PAGING_H__
=20
-#include <xen/config.h>
-
 #if defined CONFIG_PAGING_ASSISTANCE
=20
 #include <asm/paging.h>
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -7,7 +7,6 @@
 #ifndef __XEN_PCI_H__
 #define __XEN_PCI_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
--- a/xen/include/xen/percpu.h
+++ b/xen/include/xen/percpu.h
@@ -1,7 +1,6 @@
 #ifndef __XEN_PERCPU_H__
 #define __XEN_PERCPU_H__
=20
-#include <xen/config.h>
 #include <asm/percpu.h>
=20
 /*
--- a/xen/include/xen/preempt.h
+++ b/xen/include/xen/preempt.h
@@ -9,7 +9,6 @@
 #ifndef __XEN_PREEMPT_H__
 #define __XEN_PREEMPT_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/percpu.h>
=20
--- a/xen/include/xen/radix-tree.h
+++ b/xen/include/xen/radix-tree.h
@@ -20,7 +20,6 @@
 #ifndef _XEN_RADIX_TREE_H
 #define _XEN_RADIX_TREE_H
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/lib.h>
 #include <xen/rcupdate.h>
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -2,7 +2,6 @@
 #ifndef __SCHED_H__
 #define __SCHED_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/spinlock.h>
 #include <xen/shared.h>
--- a/xen/include/xen/shared.h
+++ b/xen/include/xen/shared.h
@@ -1,8 +1,6 @@
 #ifndef __XEN_SHARED_H__
 #define __XEN_SHARED_H__
=20
-#include <xen/config.h>
-
 #ifdef CONFIG_COMPAT
=20
 #include <compat/xen.h>
--- a/xen/include/xen/smp.h
+++ b/xen/include/xen/smp.h
@@ -1,7 +1,6 @@
 #ifndef __XEN_SMP_H__
 #define __XEN_SMP_H__
=20
-#include <xen/config.h>
 #include <asm/smp.h>
=20
 /*
--- a/xen/include/xen/softirq.h
+++ b/xen/include/xen/softirq.h
@@ -11,7 +11,6 @@ enum {
     NR_COMMON_SOFTIRQS
 };
=20
-#include <xen/config.h>
 #include <xen/lib.h>
 #include <xen/smp.h>
 #include <asm/bitops.h>
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -1,7 +1,6 @@
 #ifndef __SPINLOCK_H__
 #define __SPINLOCK_H__
=20
-#include <xen/config.h>
 #include <asm/system.h>
 #include <asm/spinlock.h>
=20
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -1,7 +1,6 @@
 #ifndef _XEN_SYMBOLS_H
 #define _XEN_SYMBOLS_H
=20
-#include <xen/config.h>
 #include <xen/types.h>
=20
 #define KSYM_NAME_LEN 127
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -9,7 +9,6 @@
 #ifndef __XEN_TMEM_XEN_H__
 #define __XEN_TMEM_XEN_H__
=20
-#include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
 #include <xen/xmalloc.h> /* xmalloc/xfree */
 #include <xen/sched.h>  /* struct domain */
--- a/xen/include/xen/trace.h
+++ b/xen/include/xen/trace.h
@@ -23,7 +23,6 @@
=20
 extern int tb_init_done;
=20
-#include <xen/config.h>
 #include <public/sysctl.h>
 #include <public/trace.h>
 #include <asm/trace.h>
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -1,7 +1,6 @@
 #ifndef __TYPES_H__
 #define __TYPES_H__
=20
-#include <xen/config.h>
 #include <asm/types.h>
=20
 #define BITS_TO_LONGS(bits) \
--- a/xen/include/xen/vga.h
+++ b/xen/include/xen/vga.h
@@ -9,7 +9,6 @@
 #ifndef _XEN_VGA_H
 #define _XEN_VGA_H
=20
-#include <xen/config.h>
 #include <public/xen.h>
=20
 #ifdef CONFIG_VGA
--- a/xen/include/xen/xenoprof.h
+++ b/xen/include/xen/xenoprof.h
@@ -10,7 +10,6 @@
 #ifndef __XEN_XENOPROF_H__
 #define __XEN_XENOPROF_H__
=20
-#include <xen/config.h>
 #include <xen/inttypes.h>
 #include <public/xenoprof.h>
 #include <asm/xenoprof.h>



--=__PartD3FD9EF7.1__=
Content-Type: text/plain; name="force-include-config-h.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="force-include-config-h.patch"

force inclusion of xen/config.h through compiler option=0A=0AAs we expect =
all source files to include the header as the first thing=0Aanyway, stop =
doing this by repeating the inclusion in each and every=0Asource file (and =
in many headers), but rather enforce this uniformly=0Athrough the compiler =
command line.=0A=0AAs a first cleanup step, remove the explicit inclusion =
from all common=0Aheaders. Further cleanup can be done incrementally.=0A=0A=
Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/Rules.mk=0A++=
+ b/xen/Rules.mk=0A@@ -41,7 +41,7 @@ ALL_OBJS-y               +=3D =
$(BASEDIR)/x=0A ALL_OBJS-y               +=3D $(BASEDIR)/arch/$(TARGET_ARCH=
)/built_in.o=0A ALL_OBJS-$(x86)          +=3D $(BASEDIR)/crypto/built_in.o=
=0A =0A-CFLAGS-y                +=3D -g -D__XEN__=0A+CFLAGS-y              =
  +=3D -g -D__XEN__ --include $(BASEDIR)/include/xen/config.h=0A CFLAGS-$(X=
SM_ENABLE)    +=3D -DXSM_ENABLE=0A CFLAGS-$(FLASK_ENABLE)  +=3D -DFLASK_ENA=
BLE -DXSM_MAGIC=3D0xf97cff8c=0A CFLAGS-$(FLASK_ENABLE)  +=3D -DFLASK_DEVELO=
P -DFLASK_BOOTPARAM -DFLASK_AVC_STATS=0A@@ -59,7 +59,7 @@ ifneq ($(max_phys=
_irqs),)=0A CFLAGS-y                +=3D -DMAX_PHYS_IRQS=3D$(max_phys_irqs)=
=0A endif=0A =0A-AFLAGS-y                +=3D -D__ASSEMBLY__=0A+AFLAGS-y   =
             +=3D -D__ASSEMBLY__ --include $(BASEDIR)/include/xen/config.h=
=0A =0A # Clang's built-in assembler can't handle .code16/.code32/.code64 =
yet=0A AFLAGS-$(clang)         +=3D -no-integrated-as=0A--- a/xen/include/x=
en/bitmap.h=0A+++ b/xen/include/xen/bitmap.h=0A@@ -3,7 +3,6 @@=0A =0A =
#ifndef __ASSEMBLY__=0A =0A-#include <xen/config.h>=0A #include <xen/lib.h>=
=0A #include <xen/types.h>=0A #include <xen/bitops.h>=0A--- a/xen/include/x=
en/byteorder/swab.h=0A+++ b/xen/include/xen/byteorder/swab.h=0A@@ -10,8 =
+10,6 @@=0A  *    to clean up support for bizarre-endian architectures.=0A =
 */=0A =0A-#include <xen/compiler.h>=0A-=0A /* casts are necessary for =
constants, because we never know how for sure=0A  * how U/UL/ULL map to =
__u16, __u32, __u64. At least not in a portable way.=0A  */=0A--- =
a/xen/include/xen/cache.h=0A+++ b/xen/include/xen/cache.h=0A@@ -1,7 +1,6 =
@@=0A #ifndef __LINUX_CACHE_H=0A #define __LINUX_CACHE_H=0A =0A-#include =
<xen/config.h>=0A #include <asm/cache.h>=0A =0A #ifndef L1_CACHE_ALIGN=0A--=
- a/xen/include/xen/compat.h=0A+++ b/xen/include/xen/compat.h=0A@@ -5,8 =
+5,6 @@=0A #ifndef __XEN_COMPAT_H__=0A #define __XEN_COMPAT_H__=0A =
=0A-#include <xen/config.h>=0A-=0A #ifdef CONFIG_COMPAT=0A =0A #include =
<xen/types.h>=0A--- a/xen/include/xen/cpumask.h=0A+++ b/xen/include/xen/cpu=
mask.h=0A@@ -75,7 +75,6 @@=0A  *    inside a macro, the way we do the =
other calls.=0A  */=0A =0A-#include <xen/config.h>=0A #include <xen/bitmap.=
h>=0A #include <xen/kernel.h>=0A =0A--- a/xen/include/xen/ctype.h=0A+++ =
b/xen/include/xen/ctype.h=0A@@ -1,8 +1,6 @@=0A #ifndef _LINUX_CTYPE_H=0A =
#define _LINUX_CTYPE_H=0A =0A-#include <xen/config.h>=0A-=0A /*=0A  * =
NOTE! This ctype does not handle EOF like the standard C=0A  * library is =
required to.=0A--- a/xen/include/xen/domain_page.h=0A+++ b/xen/include/xen/=
domain_page.h=0A@@ -9,7 +9,6 @@=0A #ifndef __XEN_DOMAIN_PAGE_H__=0A =
#define __XEN_DOMAIN_PAGE_H__=0A =0A-#include <xen/config.h>=0A #include =
<xen/mm.h>=0A =0A #ifdef CONFIG_DOMAIN_PAGE=0A--- a/xen/include/xen/event.h=
=0A+++ b/xen/include/xen/event.h=0A@@ -9,7 +9,6 @@=0A #ifndef __XEN_EVENT_H=
__=0A #define __XEN_EVENT_H__=0A =0A-#include <xen/config.h>=0A #include =
<xen/sched.h>=0A #include <xen/smp.h>=0A #include <xen/softirq.h>=0A--- =
a/xen/include/xen/grant_table.h=0A+++ b/xen/include/xen/grant_table.h=0A@@ =
-24,7 +24,6 @@=0A #ifndef __XEN_GRANT_TABLE_H__=0A #define __XEN_GRANT_TABL=
E_H__=0A =0A-#include <xen/config.h>=0A #include <public/grant_table.h>=0A =
#include <asm/grant_table.h>=0A =0A--- a/xen/include/xen/hypercall.h=0A+++ =
b/xen/include/xen/hypercall.h=0A@@ -5,7 +5,6 @@=0A #ifndef __XEN_HYPERCALL_=
H__=0A #define __XEN_HYPERCALL_H__=0A =0A-#include <xen/config.h>=0A =
#include <xen/types.h>=0A #include <xen/time.h>=0A #include <public/xen.h>=
=0A--- a/xen/include/xen/init.h=0A+++ b/xen/include/xen/init.h=0A@@ -1,7 =
+1,6 @@=0A #ifndef _LINUX_INIT_H=0A #define _LINUX_INIT_H=0A =0A-#include =
<xen/config.h>=0A #include <asm/init.h>=0A =0A /*=0A--- a/xen/include/xen/i=
nttypes.h=0A+++ b/xen/include/xen/inttypes.h=0A@@ -23,7 +23,6 @@=0A =
#ifndef _XEN_INTTYPES_H=0A #define _XEN_INTTYPES_H	1=0A =0A-#include =
<xen/config.h>=0A #include <xen/types.h>=0A =0A # if BITS_PER_LONG =3D=3D =
64=0A--- a/xen/include/xen/irq.h=0A+++ b/xen/include/xen/irq.h=0A@@ -1,7 =
+1,6 @@=0A #ifndef __XEN_IRQ_H__=0A #define __XEN_IRQ_H__=0A =0A-#include =
<xen/config.h>=0A #include <xen/cpumask.h>=0A #include <xen/rcupdate.h>=0A =
#include <xen/spinlock.h>=0A--- a/xen/include/xen/irq_cpustat.h=0A+++ =
b/xen/include/xen/irq_cpustat.h=0A@@ -9,7 +9,6 @@=0A  * Keith Owens =
<kaos@ocs.com.au> July 2000.=0A  */=0A =0A-#include <xen/config.h>=0A =
#include <asm/hardirq.h>=0A =0A /*=0A--- a/xen/include/xen/lib.h=0A+++ =
b/xen/include/xen/lib.h=0A@@ -3,7 +3,6 @@=0A =0A #include <xen/inttypes.h>=
=0A #include <xen/stdarg.h>=0A-#include <xen/config.h>=0A #include =
<xen/types.h>=0A #include <xen/xmalloc.h>=0A #include <xen/string.h>=0A--- =
a/xen/include/xen/mm.h=0A+++ b/xen/include/xen/mm.h=0A@@ -28,7 +28,6 @@=0A =
#ifndef __XEN_MM_H__=0A #define __XEN_MM_H__=0A =0A-#include <xen/config.h>=
=0A #include <xen/types.h>=0A #include <xen/list.h>=0A #include <xen/spinlo=
ck.h>=0A--- a/xen/include/xen/notifier.h=0A+++ b/xen/include/xen/notifier.h=
=0A@@ -10,7 +10,6 @@=0A #ifndef __XEN_NOTIFIER_H__=0A #define __XEN_NOTIFIE=
R_H__=0A =0A-#include <xen/config.h>=0A #include <xen/types.h>=0A #include =
<xen/errno.h>=0A #include <xen/kernel.h>=0A--- a/xen/include/xen/numa.h=0A+=
++ b/xen/include/xen/numa.h=0A@@ -1,7 +1,6 @@=0A #ifndef _XEN_NUMA_H=0A =
#define _XEN_NUMA_H=0A =0A-#include <xen/config.h>=0A #include <asm/numa.h>=
=0A =0A #ifndef NODES_SHIFT=0A--- a/xen/include/xen/paging.h=0A+++ =
b/xen/include/xen/paging.h=0A@@ -2,8 +2,6 @@=0A #ifndef __XEN_PAGING_H__=0A=
 #define __XEN_PAGING_H__=0A =0A-#include <xen/config.h>=0A-=0A #if =
defined CONFIG_PAGING_ASSISTANCE=0A =0A #include <asm/paging.h>=0A--- =
a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@@ -7,7 +7,6 @@=0A =
#ifndef __XEN_PCI_H__=0A #define __XEN_PCI_H__=0A =0A-#include <xen/config.=
h>=0A #include <xen/types.h>=0A #include <xen/list.h>=0A #include =
<xen/spinlock.h>=0A--- a/xen/include/xen/percpu.h=0A+++ b/xen/include/xen/p=
ercpu.h=0A@@ -1,7 +1,6 @@=0A #ifndef __XEN_PERCPU_H__=0A #define __XEN_PERC=
PU_H__=0A =0A-#include <xen/config.h>=0A #include <asm/percpu.h>=0A =0A =
/*=0A--- a/xen/include/xen/preempt.h=0A+++ b/xen/include/xen/preempt.h=0A@@=
 -9,7 +9,6 @@=0A #ifndef __XEN_PREEMPT_H__=0A #define __XEN_PREEMPT_H__=0A =
=0A-#include <xen/config.h>=0A #include <xen/types.h>=0A #include =
<xen/percpu.h>=0A =0A--- a/xen/include/xen/radix-tree.h=0A+++ b/xen/include=
/xen/radix-tree.h=0A@@ -20,7 +20,6 @@=0A #ifndef _XEN_RADIX_TREE_H=0A =
#define _XEN_RADIX_TREE_H=0A =0A-#include <xen/config.h>=0A #include =
<xen/types.h>=0A #include <xen/lib.h>=0A #include <xen/rcupdate.h>=0A--- =
a/xen/include/xen/sched.h=0A+++ b/xen/include/xen/sched.h=0A@@ -2,7 +2,6 =
@@=0A #ifndef __SCHED_H__=0A #define __SCHED_H__=0A =0A-#include <xen/confi=
g.h>=0A #include <xen/types.h>=0A #include <xen/spinlock.h>=0A #include =
<xen/shared.h>=0A--- a/xen/include/xen/shared.h=0A+++ b/xen/include/xen/sha=
red.h=0A@@ -1,8 +1,6 @@=0A #ifndef __XEN_SHARED_H__=0A #define __XEN_SHARED=
_H__=0A =0A-#include <xen/config.h>=0A-=0A #ifdef CONFIG_COMPAT=0A =0A =
#include <compat/xen.h>=0A--- a/xen/include/xen/smp.h=0A+++ b/xen/include/x=
en/smp.h=0A@@ -1,7 +1,6 @@=0A #ifndef __XEN_SMP_H__=0A #define __XEN_SMP_H_=
_=0A =0A-#include <xen/config.h>=0A #include <asm/smp.h>=0A =0A /*=0A--- =
a/xen/include/xen/softirq.h=0A+++ b/xen/include/xen/softirq.h=0A@@ -11,7 =
+11,6 @@ enum {=0A     NR_COMMON_SOFTIRQS=0A };=0A =0A-#include <xen/config=
.h>=0A #include <xen/lib.h>=0A #include <xen/smp.h>=0A #include <asm/bitops=
.h>=0A--- a/xen/include/xen/spinlock.h=0A+++ b/xen/include/xen/spinlock.h=
=0A@@ -1,7 +1,6 @@=0A #ifndef __SPINLOCK_H__=0A #define __SPINLOCK_H__=0A =
=0A-#include <xen/config.h>=0A #include <asm/system.h>=0A #include =
<asm/spinlock.h>=0A =0A--- a/xen/include/xen/symbols.h=0A+++ b/xen/include/=
xen/symbols.h=0A@@ -1,7 +1,6 @@=0A #ifndef _XEN_SYMBOLS_H=0A #define =
_XEN_SYMBOLS_H=0A =0A-#include <xen/config.h>=0A #include <xen/types.h>=0A =
=0A #define KSYM_NAME_LEN 127=0A--- a/xen/include/xen/tmem_xen.h=0A+++ =
b/xen/include/xen/tmem_xen.h=0A@@ -9,7 +9,6 @@=0A #ifndef __XEN_TMEM_XEN_H_=
_=0A #define __XEN_TMEM_XEN_H__=0A =0A-#include <xen/config.h>=0A #include =
<xen/mm.h> /* heap alloc/free */=0A #include <xen/xmalloc.h> /* xmalloc/xfr=
ee */=0A #include <xen/sched.h>  /* struct domain */=0A--- a/xen/include/xe=
n/trace.h=0A+++ b/xen/include/xen/trace.h=0A@@ -23,7 +23,6 @@=0A =0A =
extern int tb_init_done;=0A =0A-#include <xen/config.h>=0A #include =
<public/sysctl.h>=0A #include <public/trace.h>=0A #include <asm/trace.h>=0A=
--- a/xen/include/xen/types.h=0A+++ b/xen/include/xen/types.h=0A@@ -1,7 =
+1,6 @@=0A #ifndef __TYPES_H__=0A #define __TYPES_H__=0A =0A-#include =
<xen/config.h>=0A #include <asm/types.h>=0A =0A #define BITS_TO_LONGS(bits)=
 \=0A--- a/xen/include/xen/vga.h=0A+++ b/xen/include/xen/vga.h=0A@@ -9,7 =
+9,6 @@=0A #ifndef _XEN_VGA_H=0A #define _XEN_VGA_H=0A =0A-#include =
<xen/config.h>=0A #include <public/xen.h>=0A =0A #ifdef CONFIG_VGA=0A--- =
a/xen/include/xen/xenoprof.h=0A+++ b/xen/include/xen/xenoprof.h=0A@@ -10,7 =
+10,6 @@=0A #ifndef __XEN_XENOPROF_H__=0A #define __XEN_XENOPROF_H__=0A =
=0A-#include <xen/config.h>=0A #include <xen/inttypes.h>=0A #include =
<public/xenoprof.h>=0A #include <asm/xenoprof.h>=0A
--=__PartD3FD9EF7.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

--=__PartD3FD9EF7.1__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:39:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:39:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNgQ-0002HR-2f; Thu, 12 Jan 2012 16:39:22 +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 1RlNgN-0002GV-Io
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:39:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326386351!8899390!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 1613 invoked from network); 12 Jan 2012 16:39:11 -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 Jan 2012 16:39:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 16:39:10 +0000
Message-Id: <4F0F1AF7020000780006C2E7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 16:40:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartD3FD9EF7.1__="
Subject: [Xen-devel] [PATCH 1/2] force inclusion of xen/config.h through
 compiler option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartD3FD9EF7.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

As we expect all source files to include the header as the first thing
anyway, stop doing this by repeating the inclusion in each and every
source file (and in many headers), but rather enforce this uniformly
through the compiler command line.

As a first cleanup step, remove the explicit inclusion from all common
headers. Further cleanup can be done incrementally.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -41,7 +41,7 @@ ALL_OBJS-y               +=3D $(BASEDIR)/x
 ALL_OBJS-y               +=3D $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
 ALL_OBJS-$(x86)          +=3D $(BASEDIR)/crypto/built_in.o
=20
-CFLAGS-y                +=3D -g -D__XEN__
+CFLAGS-y                +=3D -g -D__XEN__ --include $(BASEDIR)/include/xen=
/config.h
 CFLAGS-$(XSM_ENABLE)    +=3D -DXSM_ENABLE
 CFLAGS-$(FLASK_ENABLE)  +=3D -DFLASK_ENABLE -DXSM_MAGIC=3D0xf97cff8c
 CFLAGS-$(FLASK_ENABLE)  +=3D -DFLASK_DEVELOP -DFLASK_BOOTPARAM -DFLASK_AVC=
_STATS
@@ -59,7 +59,7 @@ ifneq ($(max_phys_irqs),)
 CFLAGS-y                +=3D -DMAX_PHYS_IRQS=3D$(max_phys_irqs)
 endif
=20
-AFLAGS-y                +=3D -D__ASSEMBLY__
+AFLAGS-y                +=3D -D__ASSEMBLY__ --include $(BASEDIR)/include/x=
en/config.h
=20
 # Clang's built-in assembler can't handle .code16/.code32/.code64 yet
 AFLAGS-$(clang)         +=3D -no-integrated-as
--- a/xen/include/xen/bitmap.h
+++ b/xen/include/xen/bitmap.h
@@ -3,7 +3,6 @@
=20
 #ifndef __ASSEMBLY__
=20
-#include <xen/config.h>
 #include <xen/lib.h>
 #include <xen/types.h>
 #include <xen/bitops.h>
--- a/xen/include/xen/byteorder/swab.h
+++ b/xen/include/xen/byteorder/swab.h
@@ -10,8 +10,6 @@
  *    to clean up support for bizarre-endian architectures.
  */
=20
-#include <xen/compiler.h>
-
 /* casts are necessary for constants, because we never know how for sure
  * how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable =
way.
  */
--- a/xen/include/xen/cache.h
+++ b/xen/include/xen/cache.h
@@ -1,7 +1,6 @@
 #ifndef __LINUX_CACHE_H
 #define __LINUX_CACHE_H
=20
-#include <xen/config.h>
 #include <asm/cache.h>
=20
 #ifndef L1_CACHE_ALIGN
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -5,8 +5,6 @@
 #ifndef __XEN_COMPAT_H__
 #define __XEN_COMPAT_H__
=20
-#include <xen/config.h>
-
 #ifdef CONFIG_COMPAT
=20
 #include <xen/types.h>
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -75,7 +75,6 @@
  *    inside a macro, the way we do the other calls.
  */
=20
-#include <xen/config.h>
 #include <xen/bitmap.h>
 #include <xen/kernel.h>
=20
--- a/xen/include/xen/ctype.h
+++ b/xen/include/xen/ctype.h
@@ -1,8 +1,6 @@
 #ifndef _LINUX_CTYPE_H
 #define _LINUX_CTYPE_H
=20
-#include <xen/config.h>
-
 /*
  * NOTE! This ctype does not handle EOF like the standard C
  * library is required to.
--- a/xen/include/xen/domain_page.h
+++ b/xen/include/xen/domain_page.h
@@ -9,7 +9,6 @@
 #ifndef __XEN_DOMAIN_PAGE_H__
 #define __XEN_DOMAIN_PAGE_H__
=20
-#include <xen/config.h>
 #include <xen/mm.h>
=20
 #ifdef CONFIG_DOMAIN_PAGE
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -9,7 +9,6 @@
 #ifndef __XEN_EVENT_H__
 #define __XEN_EVENT_H__
=20
-#include <xen/config.h>
 #include <xen/sched.h>
 #include <xen/smp.h>
 #include <xen/softirq.h>
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -24,7 +24,6 @@
 #ifndef __XEN_GRANT_TABLE_H__
 #define __XEN_GRANT_TABLE_H__
=20
-#include <xen/config.h>
 #include <public/grant_table.h>
 #include <asm/grant_table.h>
=20
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -5,7 +5,6 @@
 #ifndef __XEN_HYPERCALL_H__
 #define __XEN_HYPERCALL_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/time.h>
 #include <public/xen.h>
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -1,7 +1,6 @@
 #ifndef _LINUX_INIT_H
 #define _LINUX_INIT_H
=20
-#include <xen/config.h>
 #include <asm/init.h>
=20
 /*
--- a/xen/include/xen/inttypes.h
+++ b/xen/include/xen/inttypes.h
@@ -23,7 +23,6 @@
 #ifndef _XEN_INTTYPES_H
 #define _XEN_INTTYPES_H	1
=20
-#include <xen/config.h>
 #include <xen/types.h>
=20
 # if BITS_PER_LONG =3D=3D 64
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -1,7 +1,6 @@
 #ifndef __XEN_IRQ_H__
 #define __XEN_IRQ_H__
=20
-#include <xen/config.h>
 #include <xen/cpumask.h>
 #include <xen/rcupdate.h>
 #include <xen/spinlock.h>
--- a/xen/include/xen/irq_cpustat.h
+++ b/xen/include/xen/irq_cpustat.h
@@ -9,7 +9,6 @@
  * Keith Owens <kaos@ocs.com.au> July 2000.
  */
=20
-#include <xen/config.h>
 #include <asm/hardirq.h>
=20
 /*
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -3,7 +3,6 @@
=20
 #include <xen/inttypes.h>
 #include <xen/stdarg.h>
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/xmalloc.h>
 #include <xen/string.h>
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -28,7 +28,6 @@
 #ifndef __XEN_MM_H__
 #define __XEN_MM_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
--- a/xen/include/xen/notifier.h
+++ b/xen/include/xen/notifier.h
@@ -10,7 +10,6 @@
 #ifndef __XEN_NOTIFIER_H__
 #define __XEN_NOTIFIER_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/errno.h>
 #include <xen/kernel.h>
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -1,7 +1,6 @@
 #ifndef _XEN_NUMA_H
 #define _XEN_NUMA_H
=20
-#include <xen/config.h>
 #include <asm/numa.h>
=20
 #ifndef NODES_SHIFT
--- a/xen/include/xen/paging.h
+++ b/xen/include/xen/paging.h
@@ -2,8 +2,6 @@
 #ifndef __XEN_PAGING_H__
 #define __XEN_PAGING_H__
=20
-#include <xen/config.h>
-
 #if defined CONFIG_PAGING_ASSISTANCE
=20
 #include <asm/paging.h>
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -7,7 +7,6 @@
 #ifndef __XEN_PCI_H__
 #define __XEN_PCI_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/list.h>
 #include <xen/spinlock.h>
--- a/xen/include/xen/percpu.h
+++ b/xen/include/xen/percpu.h
@@ -1,7 +1,6 @@
 #ifndef __XEN_PERCPU_H__
 #define __XEN_PERCPU_H__
=20
-#include <xen/config.h>
 #include <asm/percpu.h>
=20
 /*
--- a/xen/include/xen/preempt.h
+++ b/xen/include/xen/preempt.h
@@ -9,7 +9,6 @@
 #ifndef __XEN_PREEMPT_H__
 #define __XEN_PREEMPT_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/percpu.h>
=20
--- a/xen/include/xen/radix-tree.h
+++ b/xen/include/xen/radix-tree.h
@@ -20,7 +20,6 @@
 #ifndef _XEN_RADIX_TREE_H
 #define _XEN_RADIX_TREE_H
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/lib.h>
 #include <xen/rcupdate.h>
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -2,7 +2,6 @@
 #ifndef __SCHED_H__
 #define __SCHED_H__
=20
-#include <xen/config.h>
 #include <xen/types.h>
 #include <xen/spinlock.h>
 #include <xen/shared.h>
--- a/xen/include/xen/shared.h
+++ b/xen/include/xen/shared.h
@@ -1,8 +1,6 @@
 #ifndef __XEN_SHARED_H__
 #define __XEN_SHARED_H__
=20
-#include <xen/config.h>
-
 #ifdef CONFIG_COMPAT
=20
 #include <compat/xen.h>
--- a/xen/include/xen/smp.h
+++ b/xen/include/xen/smp.h
@@ -1,7 +1,6 @@
 #ifndef __XEN_SMP_H__
 #define __XEN_SMP_H__
=20
-#include <xen/config.h>
 #include <asm/smp.h>
=20
 /*
--- a/xen/include/xen/softirq.h
+++ b/xen/include/xen/softirq.h
@@ -11,7 +11,6 @@ enum {
     NR_COMMON_SOFTIRQS
 };
=20
-#include <xen/config.h>
 #include <xen/lib.h>
 #include <xen/smp.h>
 #include <asm/bitops.h>
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -1,7 +1,6 @@
 #ifndef __SPINLOCK_H__
 #define __SPINLOCK_H__
=20
-#include <xen/config.h>
 #include <asm/system.h>
 #include <asm/spinlock.h>
=20
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -1,7 +1,6 @@
 #ifndef _XEN_SYMBOLS_H
 #define _XEN_SYMBOLS_H
=20
-#include <xen/config.h>
 #include <xen/types.h>
=20
 #define KSYM_NAME_LEN 127
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -9,7 +9,6 @@
 #ifndef __XEN_TMEM_XEN_H__
 #define __XEN_TMEM_XEN_H__
=20
-#include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
 #include <xen/xmalloc.h> /* xmalloc/xfree */
 #include <xen/sched.h>  /* struct domain */
--- a/xen/include/xen/trace.h
+++ b/xen/include/xen/trace.h
@@ -23,7 +23,6 @@
=20
 extern int tb_init_done;
=20
-#include <xen/config.h>
 #include <public/sysctl.h>
 #include <public/trace.h>
 #include <asm/trace.h>
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -1,7 +1,6 @@
 #ifndef __TYPES_H__
 #define __TYPES_H__
=20
-#include <xen/config.h>
 #include <asm/types.h>
=20
 #define BITS_TO_LONGS(bits) \
--- a/xen/include/xen/vga.h
+++ b/xen/include/xen/vga.h
@@ -9,7 +9,6 @@
 #ifndef _XEN_VGA_H
 #define _XEN_VGA_H
=20
-#include <xen/config.h>
 #include <public/xen.h>
=20
 #ifdef CONFIG_VGA
--- a/xen/include/xen/xenoprof.h
+++ b/xen/include/xen/xenoprof.h
@@ -10,7 +10,6 @@
 #ifndef __XEN_XENOPROF_H__
 #define __XEN_XENOPROF_H__
=20
-#include <xen/config.h>
 #include <xen/inttypes.h>
 #include <public/xenoprof.h>
 #include <asm/xenoprof.h>



--=__PartD3FD9EF7.1__=
Content-Type: text/plain; name="force-include-config-h.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="force-include-config-h.patch"

force inclusion of xen/config.h through compiler option=0A=0AAs we expect =
all source files to include the header as the first thing=0Aanyway, stop =
doing this by repeating the inclusion in each and every=0Asource file (and =
in many headers), but rather enforce this uniformly=0Athrough the compiler =
command line.=0A=0AAs a first cleanup step, remove the explicit inclusion =
from all common=0Aheaders. Further cleanup can be done incrementally.=0A=0A=
Signed-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- a/xen/Rules.mk=0A++=
+ b/xen/Rules.mk=0A@@ -41,7 +41,7 @@ ALL_OBJS-y               +=3D =
$(BASEDIR)/x=0A ALL_OBJS-y               +=3D $(BASEDIR)/arch/$(TARGET_ARCH=
)/built_in.o=0A ALL_OBJS-$(x86)          +=3D $(BASEDIR)/crypto/built_in.o=
=0A =0A-CFLAGS-y                +=3D -g -D__XEN__=0A+CFLAGS-y              =
  +=3D -g -D__XEN__ --include $(BASEDIR)/include/xen/config.h=0A CFLAGS-$(X=
SM_ENABLE)    +=3D -DXSM_ENABLE=0A CFLAGS-$(FLASK_ENABLE)  +=3D -DFLASK_ENA=
BLE -DXSM_MAGIC=3D0xf97cff8c=0A CFLAGS-$(FLASK_ENABLE)  +=3D -DFLASK_DEVELO=
P -DFLASK_BOOTPARAM -DFLASK_AVC_STATS=0A@@ -59,7 +59,7 @@ ifneq ($(max_phys=
_irqs),)=0A CFLAGS-y                +=3D -DMAX_PHYS_IRQS=3D$(max_phys_irqs)=
=0A endif=0A =0A-AFLAGS-y                +=3D -D__ASSEMBLY__=0A+AFLAGS-y   =
             +=3D -D__ASSEMBLY__ --include $(BASEDIR)/include/xen/config.h=
=0A =0A # Clang's built-in assembler can't handle .code16/.code32/.code64 =
yet=0A AFLAGS-$(clang)         +=3D -no-integrated-as=0A--- a/xen/include/x=
en/bitmap.h=0A+++ b/xen/include/xen/bitmap.h=0A@@ -3,7 +3,6 @@=0A =0A =
#ifndef __ASSEMBLY__=0A =0A-#include <xen/config.h>=0A #include <xen/lib.h>=
=0A #include <xen/types.h>=0A #include <xen/bitops.h>=0A--- a/xen/include/x=
en/byteorder/swab.h=0A+++ b/xen/include/xen/byteorder/swab.h=0A@@ -10,8 =
+10,6 @@=0A  *    to clean up support for bizarre-endian architectures.=0A =
 */=0A =0A-#include <xen/compiler.h>=0A-=0A /* casts are necessary for =
constants, because we never know how for sure=0A  * how U/UL/ULL map to =
__u16, __u32, __u64. At least not in a portable way.=0A  */=0A--- =
a/xen/include/xen/cache.h=0A+++ b/xen/include/xen/cache.h=0A@@ -1,7 +1,6 =
@@=0A #ifndef __LINUX_CACHE_H=0A #define __LINUX_CACHE_H=0A =0A-#include =
<xen/config.h>=0A #include <asm/cache.h>=0A =0A #ifndef L1_CACHE_ALIGN=0A--=
- a/xen/include/xen/compat.h=0A+++ b/xen/include/xen/compat.h=0A@@ -5,8 =
+5,6 @@=0A #ifndef __XEN_COMPAT_H__=0A #define __XEN_COMPAT_H__=0A =
=0A-#include <xen/config.h>=0A-=0A #ifdef CONFIG_COMPAT=0A =0A #include =
<xen/types.h>=0A--- a/xen/include/xen/cpumask.h=0A+++ b/xen/include/xen/cpu=
mask.h=0A@@ -75,7 +75,6 @@=0A  *    inside a macro, the way we do the =
other calls.=0A  */=0A =0A-#include <xen/config.h>=0A #include <xen/bitmap.=
h>=0A #include <xen/kernel.h>=0A =0A--- a/xen/include/xen/ctype.h=0A+++ =
b/xen/include/xen/ctype.h=0A@@ -1,8 +1,6 @@=0A #ifndef _LINUX_CTYPE_H=0A =
#define _LINUX_CTYPE_H=0A =0A-#include <xen/config.h>=0A-=0A /*=0A  * =
NOTE! This ctype does not handle EOF like the standard C=0A  * library is =
required to.=0A--- a/xen/include/xen/domain_page.h=0A+++ b/xen/include/xen/=
domain_page.h=0A@@ -9,7 +9,6 @@=0A #ifndef __XEN_DOMAIN_PAGE_H__=0A =
#define __XEN_DOMAIN_PAGE_H__=0A =0A-#include <xen/config.h>=0A #include =
<xen/mm.h>=0A =0A #ifdef CONFIG_DOMAIN_PAGE=0A--- a/xen/include/xen/event.h=
=0A+++ b/xen/include/xen/event.h=0A@@ -9,7 +9,6 @@=0A #ifndef __XEN_EVENT_H=
__=0A #define __XEN_EVENT_H__=0A =0A-#include <xen/config.h>=0A #include =
<xen/sched.h>=0A #include <xen/smp.h>=0A #include <xen/softirq.h>=0A--- =
a/xen/include/xen/grant_table.h=0A+++ b/xen/include/xen/grant_table.h=0A@@ =
-24,7 +24,6 @@=0A #ifndef __XEN_GRANT_TABLE_H__=0A #define __XEN_GRANT_TABL=
E_H__=0A =0A-#include <xen/config.h>=0A #include <public/grant_table.h>=0A =
#include <asm/grant_table.h>=0A =0A--- a/xen/include/xen/hypercall.h=0A+++ =
b/xen/include/xen/hypercall.h=0A@@ -5,7 +5,6 @@=0A #ifndef __XEN_HYPERCALL_=
H__=0A #define __XEN_HYPERCALL_H__=0A =0A-#include <xen/config.h>=0A =
#include <xen/types.h>=0A #include <xen/time.h>=0A #include <public/xen.h>=
=0A--- a/xen/include/xen/init.h=0A+++ b/xen/include/xen/init.h=0A@@ -1,7 =
+1,6 @@=0A #ifndef _LINUX_INIT_H=0A #define _LINUX_INIT_H=0A =0A-#include =
<xen/config.h>=0A #include <asm/init.h>=0A =0A /*=0A--- a/xen/include/xen/i=
nttypes.h=0A+++ b/xen/include/xen/inttypes.h=0A@@ -23,7 +23,6 @@=0A =
#ifndef _XEN_INTTYPES_H=0A #define _XEN_INTTYPES_H	1=0A =0A-#include =
<xen/config.h>=0A #include <xen/types.h>=0A =0A # if BITS_PER_LONG =3D=3D =
64=0A--- a/xen/include/xen/irq.h=0A+++ b/xen/include/xen/irq.h=0A@@ -1,7 =
+1,6 @@=0A #ifndef __XEN_IRQ_H__=0A #define __XEN_IRQ_H__=0A =0A-#include =
<xen/config.h>=0A #include <xen/cpumask.h>=0A #include <xen/rcupdate.h>=0A =
#include <xen/spinlock.h>=0A--- a/xen/include/xen/irq_cpustat.h=0A+++ =
b/xen/include/xen/irq_cpustat.h=0A@@ -9,7 +9,6 @@=0A  * Keith Owens =
<kaos@ocs.com.au> July 2000.=0A  */=0A =0A-#include <xen/config.h>=0A =
#include <asm/hardirq.h>=0A =0A /*=0A--- a/xen/include/xen/lib.h=0A+++ =
b/xen/include/xen/lib.h=0A@@ -3,7 +3,6 @@=0A =0A #include <xen/inttypes.h>=
=0A #include <xen/stdarg.h>=0A-#include <xen/config.h>=0A #include =
<xen/types.h>=0A #include <xen/xmalloc.h>=0A #include <xen/string.h>=0A--- =
a/xen/include/xen/mm.h=0A+++ b/xen/include/xen/mm.h=0A@@ -28,7 +28,6 @@=0A =
#ifndef __XEN_MM_H__=0A #define __XEN_MM_H__=0A =0A-#include <xen/config.h>=
=0A #include <xen/types.h>=0A #include <xen/list.h>=0A #include <xen/spinlo=
ck.h>=0A--- a/xen/include/xen/notifier.h=0A+++ b/xen/include/xen/notifier.h=
=0A@@ -10,7 +10,6 @@=0A #ifndef __XEN_NOTIFIER_H__=0A #define __XEN_NOTIFIE=
R_H__=0A =0A-#include <xen/config.h>=0A #include <xen/types.h>=0A #include =
<xen/errno.h>=0A #include <xen/kernel.h>=0A--- a/xen/include/xen/numa.h=0A+=
++ b/xen/include/xen/numa.h=0A@@ -1,7 +1,6 @@=0A #ifndef _XEN_NUMA_H=0A =
#define _XEN_NUMA_H=0A =0A-#include <xen/config.h>=0A #include <asm/numa.h>=
=0A =0A #ifndef NODES_SHIFT=0A--- a/xen/include/xen/paging.h=0A+++ =
b/xen/include/xen/paging.h=0A@@ -2,8 +2,6 @@=0A #ifndef __XEN_PAGING_H__=0A=
 #define __XEN_PAGING_H__=0A =0A-#include <xen/config.h>=0A-=0A #if =
defined CONFIG_PAGING_ASSISTANCE=0A =0A #include <asm/paging.h>=0A--- =
a/xen/include/xen/pci.h=0A+++ b/xen/include/xen/pci.h=0A@@ -7,7 +7,6 @@=0A =
#ifndef __XEN_PCI_H__=0A #define __XEN_PCI_H__=0A =0A-#include <xen/config.=
h>=0A #include <xen/types.h>=0A #include <xen/list.h>=0A #include =
<xen/spinlock.h>=0A--- a/xen/include/xen/percpu.h=0A+++ b/xen/include/xen/p=
ercpu.h=0A@@ -1,7 +1,6 @@=0A #ifndef __XEN_PERCPU_H__=0A #define __XEN_PERC=
PU_H__=0A =0A-#include <xen/config.h>=0A #include <asm/percpu.h>=0A =0A =
/*=0A--- a/xen/include/xen/preempt.h=0A+++ b/xen/include/xen/preempt.h=0A@@=
 -9,7 +9,6 @@=0A #ifndef __XEN_PREEMPT_H__=0A #define __XEN_PREEMPT_H__=0A =
=0A-#include <xen/config.h>=0A #include <xen/types.h>=0A #include =
<xen/percpu.h>=0A =0A--- a/xen/include/xen/radix-tree.h=0A+++ b/xen/include=
/xen/radix-tree.h=0A@@ -20,7 +20,6 @@=0A #ifndef _XEN_RADIX_TREE_H=0A =
#define _XEN_RADIX_TREE_H=0A =0A-#include <xen/config.h>=0A #include =
<xen/types.h>=0A #include <xen/lib.h>=0A #include <xen/rcupdate.h>=0A--- =
a/xen/include/xen/sched.h=0A+++ b/xen/include/xen/sched.h=0A@@ -2,7 +2,6 =
@@=0A #ifndef __SCHED_H__=0A #define __SCHED_H__=0A =0A-#include <xen/confi=
g.h>=0A #include <xen/types.h>=0A #include <xen/spinlock.h>=0A #include =
<xen/shared.h>=0A--- a/xen/include/xen/shared.h=0A+++ b/xen/include/xen/sha=
red.h=0A@@ -1,8 +1,6 @@=0A #ifndef __XEN_SHARED_H__=0A #define __XEN_SHARED=
_H__=0A =0A-#include <xen/config.h>=0A-=0A #ifdef CONFIG_COMPAT=0A =0A =
#include <compat/xen.h>=0A--- a/xen/include/xen/smp.h=0A+++ b/xen/include/x=
en/smp.h=0A@@ -1,7 +1,6 @@=0A #ifndef __XEN_SMP_H__=0A #define __XEN_SMP_H_=
_=0A =0A-#include <xen/config.h>=0A #include <asm/smp.h>=0A =0A /*=0A--- =
a/xen/include/xen/softirq.h=0A+++ b/xen/include/xen/softirq.h=0A@@ -11,7 =
+11,6 @@ enum {=0A     NR_COMMON_SOFTIRQS=0A };=0A =0A-#include <xen/config=
.h>=0A #include <xen/lib.h>=0A #include <xen/smp.h>=0A #include <asm/bitops=
.h>=0A--- a/xen/include/xen/spinlock.h=0A+++ b/xen/include/xen/spinlock.h=
=0A@@ -1,7 +1,6 @@=0A #ifndef __SPINLOCK_H__=0A #define __SPINLOCK_H__=0A =
=0A-#include <xen/config.h>=0A #include <asm/system.h>=0A #include =
<asm/spinlock.h>=0A =0A--- a/xen/include/xen/symbols.h=0A+++ b/xen/include/=
xen/symbols.h=0A@@ -1,7 +1,6 @@=0A #ifndef _XEN_SYMBOLS_H=0A #define =
_XEN_SYMBOLS_H=0A =0A-#include <xen/config.h>=0A #include <xen/types.h>=0A =
=0A #define KSYM_NAME_LEN 127=0A--- a/xen/include/xen/tmem_xen.h=0A+++ =
b/xen/include/xen/tmem_xen.h=0A@@ -9,7 +9,6 @@=0A #ifndef __XEN_TMEM_XEN_H_=
_=0A #define __XEN_TMEM_XEN_H__=0A =0A-#include <xen/config.h>=0A #include =
<xen/mm.h> /* heap alloc/free */=0A #include <xen/xmalloc.h> /* xmalloc/xfr=
ee */=0A #include <xen/sched.h>  /* struct domain */=0A--- a/xen/include/xe=
n/trace.h=0A+++ b/xen/include/xen/trace.h=0A@@ -23,7 +23,6 @@=0A =0A =
extern int tb_init_done;=0A =0A-#include <xen/config.h>=0A #include =
<public/sysctl.h>=0A #include <public/trace.h>=0A #include <asm/trace.h>=0A=
--- a/xen/include/xen/types.h=0A+++ b/xen/include/xen/types.h=0A@@ -1,7 =
+1,6 @@=0A #ifndef __TYPES_H__=0A #define __TYPES_H__=0A =0A-#include =
<xen/config.h>=0A #include <asm/types.h>=0A =0A #define BITS_TO_LONGS(bits)=
 \=0A--- a/xen/include/xen/vga.h=0A+++ b/xen/include/xen/vga.h=0A@@ -9,7 =
+9,6 @@=0A #ifndef _XEN_VGA_H=0A #define _XEN_VGA_H=0A =0A-#include =
<xen/config.h>=0A #include <public/xen.h>=0A =0A #ifdef CONFIG_VGA=0A--- =
a/xen/include/xen/xenoprof.h=0A+++ b/xen/include/xen/xenoprof.h=0A@@ -10,7 =
+10,6 @@=0A #ifndef __XEN_XENOPROF_H__=0A #define __XEN_XENOPROF_H__=0A =
=0A-#include <xen/config.h>=0A #include <xen/inttypes.h>=0A #include =
<public/xenoprof.h>=0A #include <asm/xenoprof.h>=0A
--=__PartD3FD9EF7.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

--=__PartD3FD9EF7.1__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:40:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNgx-0002Mc-Mb; Thu, 12 Jan 2012 16:39:55 +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 1RlNgw-0002Ld-78
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:39:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326386386!8887071!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 9976 invoked from network); 12 Jan 2012 16:39:46 -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; 12 Jan 2012 16:39:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 16:39:45 +0000
Message-Id: <4F0F1B1A020000780006C2EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 16:40:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3F11721A.1__="
Subject: [Xen-devel] [PATCH 2/2] remove inclusion of asm/config.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>
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.

--=__Part3F11721A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This was always bogus (xen/config.h should have been used instead) and
is superfluous now that xen/config.h gets included through the compiler
command line.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/vmx/optvfault.S
+++ b/xen/arch/ia64/vmx/optvfault.S
@@ -6,8 +6,6 @@
  * Xuefei Xu (Anthony Xu) <anthony.xu@intel.com>
  */
=20
-#include <linux/config.h>
-#include <asm/config.h>
 #include <asm/pgtable.h>
 #include <asm/asmmacro.h>
 #include <asm/kregs.h>
--- a/xen/arch/ia64/xen/cpufreq/cpufreq.c
+++ b/xen/arch/ia64/xen/cpufreq/cpufreq.c
@@ -21,7 +21,6 @@
 #include <xen/xmalloc.h>
 #include <asm/bug.h>
 #include <asm/io.h>
-#include <asm/config.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <asm/pal.h>
--- a/xen/arch/ia64/xen/ivt.S
+++ b/xen/arch/ia64/xen/ivt.S
@@ -1,7 +1,6 @@
 #include <asm/debugger.h>
 #include <asm/vhpt.h>
 #include <public/arch-ia64.h>
-#include <asm/config.h>
 /*
  * arch/ia64/kernel/ivt.S
  *
@@ -43,8 +42,6 @@
  * Table is based upon EAS2.6 (Oct 1999)
  */
=20
-#include <linux/config.h>
-
 #include <asm/asmmacro.h>
 #include <asm/break.h>
 #include <asm/ia32.h>
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -38,7 +38,6 @@
 #include <asm/bug.h>
 #include <asm/msr.h>
 #include <asm/io.h>
-#include <asm/config.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -32,7 +32,6 @@
 #include <asm/bug.h>
 #include <asm/msr.h>
 #include <asm/io.h>
-#include <asm/config.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -41,7 +41,6 @@
 #include <xen/cpu.h>
 #include <asm/bug.h>
 #include <asm/io.h>
-#include <asm/config.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <acpi/acpi.h>
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -18,7 +18,6 @@
 #include <xen/types.h>
 #include <xen/sched.h>
 #include <xen/timer.h>
-#include <asm/config.h>
 #include <acpi/cpufreq/cpufreq.h>
=20
 #define DEF_FREQUENCY_UP_THRESHOLD              (80)
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -28,7 +28,6 @@
 #include <xen/sched.h>
 #include <xen/timer.h>
 #include <xen/trace.h>
-#include <asm/config.h>
 #include <acpi/cpufreq/cpufreq.h>
 #include <public/sysctl.h>
=20
--- a/xen/include/asm-ia64/linux-xen/asm/perfmon.h
+++ b/xen/include/asm-ia64/linux-xen/asm/perfmon.h
@@ -7,7 +7,6 @@
 #define _ASM_IA64_PERFMON_H
=20
 #ifdef XEN
-#include <asm/config.h>
 #ifndef pt_regs
 #define pt_regs cpu_user_regs
 #endif
--- a/xen/include/asm-ia64/privop_stat.h
+++ b/xen/include/asm-ia64/privop_stat.h
@@ -1,6 +1,6 @@
 #ifndef _XEN_IA64_PRIVOP_STAT_H
 #define _XEN_IA64_PRIVOP_STAT_H
-#include <asm/config.h>
+
 #include <xen/types.h>
 #include <public/xen.h>
=20
--- a/xen/include/asm-ia64/xensystem.h
+++ b/xen/include/asm-ia64/xensystem.h
@@ -10,7 +10,6 @@
  * 	Kun Tian (Kevin Tian) <kevin.tian@intel.com>
  *
  */
-#include <asm/config.h>
=20
 /* Define HV space hierarchy.
    VMM memory space is protected by CPL for paravirtualized domains and
--- a/xen/include/asm-x86/hvm/svm/nestedsvm.h
+++ b/xen/include/asm-x86/hvm/svm/nestedsvm.h
@@ -19,7 +19,6 @@
 #ifndef __ASM_X86_HVM_SVM_NESTEDSVM_H__
 #define __ASM_X86_HVM_SVM_NESTEDSVM_H__
=20
-#include <asm/config.h>
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/svm/vmcb.h>
=20
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -19,7 +19,6 @@
 #ifndef __ASM_X86_HVM_VMX_VMCS_H__
 #define __ASM_X86_HVM_VMX_VMCS_H__
=20
-#include <asm/config.h>
 #include <asm/hvm/io.h>
 #include <asm/hvm/vpmu.h>
=20




--=__Part3F11721A.1__=
Content-Type: text/plain; name="no-include-asm-config-h.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="no-include-asm-config-h.patch"

remove inclusion of asm/config.h=0A=0AThis was always bogus (xen/config.h =
should have been used instead) and=0Ais superfluous now that xen/config.h =
gets included through the compiler=0Acommand line.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/ia64/vmx/optvfault.S=0A+++ =
b/xen/arch/ia64/vmx/optvfault.S=0A@@ -6,8 +6,6 @@=0A  * Xuefei Xu (Anthony =
Xu) <anthony.xu@intel.com>=0A  */=0A =0A-#include <linux/config.h>=0A-#incl=
ude <asm/config.h>=0A #include <asm/pgtable.h>=0A #include <asm/asmmacro.h>=
=0A #include <asm/kregs.h>=0A--- a/xen/arch/ia64/xen/cpufreq/cpufreq.c=0A++=
+ b/xen/arch/ia64/xen/cpufreq/cpufreq.c=0A@@ -21,7 +21,6 @@=0A #include =
<xen/xmalloc.h>=0A #include <asm/bug.h>=0A #include <asm/io.h>=0A-#include =
<asm/config.h>=0A #include <asm/processor.h>=0A #include <asm/percpu.h>=0A =
#include <asm/pal.h>=0A--- a/xen/arch/ia64/xen/ivt.S=0A+++ b/xen/arch/ia64/=
xen/ivt.S=0A@@ -1,7 +1,6 @@=0A #include <asm/debugger.h>=0A #include =
<asm/vhpt.h>=0A #include <public/arch-ia64.h>=0A-#include <asm/config.h>=0A=
 /*=0A  * arch/ia64/kernel/ivt.S=0A  *=0A@@ -43,8 +42,6 @@=0A  * Table is =
based upon EAS2.6 (Oct 1999)=0A  */=0A =0A-#include <linux/config.h>=0A-=0A=
 #include <asm/asmmacro.h>=0A #include <asm/break.h>=0A #include <asm/ia32.=
h>=0A--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c=0A+++ b/xen/arch/x86/acpi/cp=
ufreq/cpufreq.c=0A@@ -38,7 +38,6 @@=0A #include <asm/bug.h>=0A #include =
<asm/msr.h>=0A #include <asm/io.h>=0A-#include <asm/config.h>=0A #include =
<asm/processor.h>=0A #include <asm/percpu.h>=0A #include <asm/cpufeature.h>=
=0A--- a/xen/arch/x86/acpi/cpufreq/powernow.c=0A+++ b/xen/arch/x86/acpi/cpu=
freq/powernow.c=0A@@ -32,7 +32,6 @@=0A #include <asm/bug.h>=0A #include =
<asm/msr.h>=0A #include <asm/io.h>=0A-#include <asm/config.h>=0A #include =
<asm/processor.h>=0A #include <asm/percpu.h>=0A #include <asm/cpufeature.h>=
=0A--- a/xen/drivers/cpufreq/cpufreq.c=0A+++ b/xen/drivers/cpufreq/cpufreq.=
c=0A@@ -41,7 +41,6 @@=0A #include <xen/cpu.h>=0A #include <asm/bug.h>=0A =
#include <asm/io.h>=0A-#include <asm/config.h>=0A #include <asm/processor.h=
>=0A #include <asm/percpu.h>=0A #include <acpi/acpi.h>=0A--- a/xen/drivers/=
cpufreq/cpufreq_ondemand.c=0A+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c=
=0A@@ -18,7 +18,6 @@=0A #include <xen/types.h>=0A #include <xen/sched.h>=0A=
 #include <xen/timer.h>=0A-#include <asm/config.h>=0A #include <acpi/cpufre=
q/cpufreq.h>=0A =0A #define DEF_FREQUENCY_UP_THRESHOLD              =
(80)=0A--- a/xen/drivers/cpufreq/utility.c=0A+++ b/xen/drivers/cpufreq/util=
ity.c=0A@@ -28,7 +28,6 @@=0A #include <xen/sched.h>=0A #include <xen/timer.=
h>=0A #include <xen/trace.h>=0A-#include <asm/config.h>=0A #include =
<acpi/cpufreq/cpufreq.h>=0A #include <public/sysctl.h>=0A =0A--- a/xen/incl=
ude/asm-ia64/linux-xen/asm/perfmon.h=0A+++ b/xen/include/asm-ia64/linux-xen=
/asm/perfmon.h=0A@@ -7,7 +7,6 @@=0A #define _ASM_IA64_PERFMON_H=0A =0A =
#ifdef XEN=0A-#include <asm/config.h>=0A #ifndef pt_regs=0A #define =
pt_regs cpu_user_regs=0A #endif=0A--- a/xen/include/asm-ia64/privop_stat.h=
=0A+++ b/xen/include/asm-ia64/privop_stat.h=0A@@ -1,6 +1,6 @@=0A #ifndef =
_XEN_IA64_PRIVOP_STAT_H=0A #define _XEN_IA64_PRIVOP_STAT_H=0A-#include =
<asm/config.h>=0A+=0A #include <xen/types.h>=0A #include <public/xen.h>=0A =
=0A--- a/xen/include/asm-ia64/xensystem.h=0A+++ b/xen/include/asm-ia64/xens=
ystem.h=0A@@ -10,7 +10,6 @@=0A  * 	Kun Tian (Kevin Tian) <kevin.tian@i=
ntel.com>=0A  *=0A  */=0A-#include <asm/config.h>=0A =0A /* Define HV =
space hierarchy.=0A    VMM memory space is protected by CPL for paravirtual=
ized domains and=0A--- a/xen/include/asm-x86/hvm/svm/nestedsvm.h=0A+++ =
b/xen/include/asm-x86/hvm/svm/nestedsvm.h=0A@@ -19,7 +19,6 @@=0A #ifndef =
__ASM_X86_HVM_SVM_NESTEDSVM_H__=0A #define __ASM_X86_HVM_SVM_NESTEDSVM_H__=
=0A =0A-#include <asm/config.h>=0A #include <asm/hvm/hvm.h>=0A #include =
<asm/hvm/svm/vmcb.h>=0A =0A--- a/xen/include/asm-x86/hvm/vmx/vmcs.h=0A+++ =
b/xen/include/asm-x86/hvm/vmx/vmcs.h=0A@@ -19,7 +19,6 @@=0A #ifndef =
__ASM_X86_HVM_VMX_VMCS_H__=0A #define __ASM_X86_HVM_VMX_VMCS_H__=0A =
=0A-#include <asm/config.h>=0A #include <asm/hvm/io.h>=0A #include =
<asm/hvm/vpmu.h>=0A =0A
--=__Part3F11721A.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

--=__Part3F11721A.1__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:40:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:40:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNgx-0002Mc-Mb; Thu, 12 Jan 2012 16:39:55 +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 1RlNgw-0002Ld-78
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:39:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326386386!8887071!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 9976 invoked from network); 12 Jan 2012 16:39:46 -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; 12 Jan 2012 16:39:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 12 Jan 2012 16:39:45 +0000
Message-Id: <4F0F1B1A020000780006C2EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 12 Jan 2012 16:40:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part3F11721A.1__="
Subject: [Xen-devel] [PATCH 2/2] remove inclusion of asm/config.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>
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.

--=__Part3F11721A.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This was always bogus (xen/config.h should have been used instead) and
is superfluous now that xen/config.h gets included through the compiler
command line.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ia64/vmx/optvfault.S
+++ b/xen/arch/ia64/vmx/optvfault.S
@@ -6,8 +6,6 @@
  * Xuefei Xu (Anthony Xu) <anthony.xu@intel.com>
  */
=20
-#include <linux/config.h>
-#include <asm/config.h>
 #include <asm/pgtable.h>
 #include <asm/asmmacro.h>
 #include <asm/kregs.h>
--- a/xen/arch/ia64/xen/cpufreq/cpufreq.c
+++ b/xen/arch/ia64/xen/cpufreq/cpufreq.c
@@ -21,7 +21,6 @@
 #include <xen/xmalloc.h>
 #include <asm/bug.h>
 #include <asm/io.h>
-#include <asm/config.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <asm/pal.h>
--- a/xen/arch/ia64/xen/ivt.S
+++ b/xen/arch/ia64/xen/ivt.S
@@ -1,7 +1,6 @@
 #include <asm/debugger.h>
 #include <asm/vhpt.h>
 #include <public/arch-ia64.h>
-#include <asm/config.h>
 /*
  * arch/ia64/kernel/ivt.S
  *
@@ -43,8 +42,6 @@
  * Table is based upon EAS2.6 (Oct 1999)
  */
=20
-#include <linux/config.h>
-
 #include <asm/asmmacro.h>
 #include <asm/break.h>
 #include <asm/ia32.h>
--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
+++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
@@ -38,7 +38,6 @@
 #include <asm/bug.h>
 #include <asm/msr.h>
 #include <asm/io.h>
-#include <asm/config.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
--- a/xen/arch/x86/acpi/cpufreq/powernow.c
+++ b/xen/arch/x86/acpi/cpufreq/powernow.c
@@ -32,7 +32,6 @@
 #include <asm/bug.h>
 #include <asm/msr.h>
 #include <asm/io.h>
-#include <asm/config.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <asm/cpufeature.h>
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -41,7 +41,6 @@
 #include <xen/cpu.h>
 #include <asm/bug.h>
 #include <asm/io.h>
-#include <asm/config.h>
 #include <asm/processor.h>
 #include <asm/percpu.h>
 #include <acpi/acpi.h>
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -18,7 +18,6 @@
 #include <xen/types.h>
 #include <xen/sched.h>
 #include <xen/timer.h>
-#include <asm/config.h>
 #include <acpi/cpufreq/cpufreq.h>
=20
 #define DEF_FREQUENCY_UP_THRESHOLD              (80)
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -28,7 +28,6 @@
 #include <xen/sched.h>
 #include <xen/timer.h>
 #include <xen/trace.h>
-#include <asm/config.h>
 #include <acpi/cpufreq/cpufreq.h>
 #include <public/sysctl.h>
=20
--- a/xen/include/asm-ia64/linux-xen/asm/perfmon.h
+++ b/xen/include/asm-ia64/linux-xen/asm/perfmon.h
@@ -7,7 +7,6 @@
 #define _ASM_IA64_PERFMON_H
=20
 #ifdef XEN
-#include <asm/config.h>
 #ifndef pt_regs
 #define pt_regs cpu_user_regs
 #endif
--- a/xen/include/asm-ia64/privop_stat.h
+++ b/xen/include/asm-ia64/privop_stat.h
@@ -1,6 +1,6 @@
 #ifndef _XEN_IA64_PRIVOP_STAT_H
 #define _XEN_IA64_PRIVOP_STAT_H
-#include <asm/config.h>
+
 #include <xen/types.h>
 #include <public/xen.h>
=20
--- a/xen/include/asm-ia64/xensystem.h
+++ b/xen/include/asm-ia64/xensystem.h
@@ -10,7 +10,6 @@
  * 	Kun Tian (Kevin Tian) <kevin.tian@intel.com>
  *
  */
-#include <asm/config.h>
=20
 /* Define HV space hierarchy.
    VMM memory space is protected by CPL for paravirtualized domains and
--- a/xen/include/asm-x86/hvm/svm/nestedsvm.h
+++ b/xen/include/asm-x86/hvm/svm/nestedsvm.h
@@ -19,7 +19,6 @@
 #ifndef __ASM_X86_HVM_SVM_NESTEDSVM_H__
 #define __ASM_X86_HVM_SVM_NESTEDSVM_H__
=20
-#include <asm/config.h>
 #include <asm/hvm/hvm.h>
 #include <asm/hvm/svm/vmcb.h>
=20
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -19,7 +19,6 @@
 #ifndef __ASM_X86_HVM_VMX_VMCS_H__
 #define __ASM_X86_HVM_VMX_VMCS_H__
=20
-#include <asm/config.h>
 #include <asm/hvm/io.h>
 #include <asm/hvm/vpmu.h>
=20




--=__Part3F11721A.1__=
Content-Type: text/plain; name="no-include-asm-config-h.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="no-include-asm-config-h.patch"

remove inclusion of asm/config.h=0A=0AThis was always bogus (xen/config.h =
should have been used instead) and=0Ais superfluous now that xen/config.h =
gets included through the compiler=0Acommand line.=0A=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/arch/ia64/vmx/optvfault.S=0A+++ =
b/xen/arch/ia64/vmx/optvfault.S=0A@@ -6,8 +6,6 @@=0A  * Xuefei Xu (Anthony =
Xu) <anthony.xu@intel.com>=0A  */=0A =0A-#include <linux/config.h>=0A-#incl=
ude <asm/config.h>=0A #include <asm/pgtable.h>=0A #include <asm/asmmacro.h>=
=0A #include <asm/kregs.h>=0A--- a/xen/arch/ia64/xen/cpufreq/cpufreq.c=0A++=
+ b/xen/arch/ia64/xen/cpufreq/cpufreq.c=0A@@ -21,7 +21,6 @@=0A #include =
<xen/xmalloc.h>=0A #include <asm/bug.h>=0A #include <asm/io.h>=0A-#include =
<asm/config.h>=0A #include <asm/processor.h>=0A #include <asm/percpu.h>=0A =
#include <asm/pal.h>=0A--- a/xen/arch/ia64/xen/ivt.S=0A+++ b/xen/arch/ia64/=
xen/ivt.S=0A@@ -1,7 +1,6 @@=0A #include <asm/debugger.h>=0A #include =
<asm/vhpt.h>=0A #include <public/arch-ia64.h>=0A-#include <asm/config.h>=0A=
 /*=0A  * arch/ia64/kernel/ivt.S=0A  *=0A@@ -43,8 +42,6 @@=0A  * Table is =
based upon EAS2.6 (Oct 1999)=0A  */=0A =0A-#include <linux/config.h>=0A-=0A=
 #include <asm/asmmacro.h>=0A #include <asm/break.h>=0A #include <asm/ia32.=
h>=0A--- a/xen/arch/x86/acpi/cpufreq/cpufreq.c=0A+++ b/xen/arch/x86/acpi/cp=
ufreq/cpufreq.c=0A@@ -38,7 +38,6 @@=0A #include <asm/bug.h>=0A #include =
<asm/msr.h>=0A #include <asm/io.h>=0A-#include <asm/config.h>=0A #include =
<asm/processor.h>=0A #include <asm/percpu.h>=0A #include <asm/cpufeature.h>=
=0A--- a/xen/arch/x86/acpi/cpufreq/powernow.c=0A+++ b/xen/arch/x86/acpi/cpu=
freq/powernow.c=0A@@ -32,7 +32,6 @@=0A #include <asm/bug.h>=0A #include =
<asm/msr.h>=0A #include <asm/io.h>=0A-#include <asm/config.h>=0A #include =
<asm/processor.h>=0A #include <asm/percpu.h>=0A #include <asm/cpufeature.h>=
=0A--- a/xen/drivers/cpufreq/cpufreq.c=0A+++ b/xen/drivers/cpufreq/cpufreq.=
c=0A@@ -41,7 +41,6 @@=0A #include <xen/cpu.h>=0A #include <asm/bug.h>=0A =
#include <asm/io.h>=0A-#include <asm/config.h>=0A #include <asm/processor.h=
>=0A #include <asm/percpu.h>=0A #include <acpi/acpi.h>=0A--- a/xen/drivers/=
cpufreq/cpufreq_ondemand.c=0A+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c=
=0A@@ -18,7 +18,6 @@=0A #include <xen/types.h>=0A #include <xen/sched.h>=0A=
 #include <xen/timer.h>=0A-#include <asm/config.h>=0A #include <acpi/cpufre=
q/cpufreq.h>=0A =0A #define DEF_FREQUENCY_UP_THRESHOLD              =
(80)=0A--- a/xen/drivers/cpufreq/utility.c=0A+++ b/xen/drivers/cpufreq/util=
ity.c=0A@@ -28,7 +28,6 @@=0A #include <xen/sched.h>=0A #include <xen/timer.=
h>=0A #include <xen/trace.h>=0A-#include <asm/config.h>=0A #include =
<acpi/cpufreq/cpufreq.h>=0A #include <public/sysctl.h>=0A =0A--- a/xen/incl=
ude/asm-ia64/linux-xen/asm/perfmon.h=0A+++ b/xen/include/asm-ia64/linux-xen=
/asm/perfmon.h=0A@@ -7,7 +7,6 @@=0A #define _ASM_IA64_PERFMON_H=0A =0A =
#ifdef XEN=0A-#include <asm/config.h>=0A #ifndef pt_regs=0A #define =
pt_regs cpu_user_regs=0A #endif=0A--- a/xen/include/asm-ia64/privop_stat.h=
=0A+++ b/xen/include/asm-ia64/privop_stat.h=0A@@ -1,6 +1,6 @@=0A #ifndef =
_XEN_IA64_PRIVOP_STAT_H=0A #define _XEN_IA64_PRIVOP_STAT_H=0A-#include =
<asm/config.h>=0A+=0A #include <xen/types.h>=0A #include <public/xen.h>=0A =
=0A--- a/xen/include/asm-ia64/xensystem.h=0A+++ b/xen/include/asm-ia64/xens=
ystem.h=0A@@ -10,7 +10,6 @@=0A  * 	Kun Tian (Kevin Tian) <kevin.tian@i=
ntel.com>=0A  *=0A  */=0A-#include <asm/config.h>=0A =0A /* Define HV =
space hierarchy.=0A    VMM memory space is protected by CPL for paravirtual=
ized domains and=0A--- a/xen/include/asm-x86/hvm/svm/nestedsvm.h=0A+++ =
b/xen/include/asm-x86/hvm/svm/nestedsvm.h=0A@@ -19,7 +19,6 @@=0A #ifndef =
__ASM_X86_HVM_SVM_NESTEDSVM_H__=0A #define __ASM_X86_HVM_SVM_NESTEDSVM_H__=
=0A =0A-#include <asm/config.h>=0A #include <asm/hvm/hvm.h>=0A #include =
<asm/hvm/svm/vmcb.h>=0A =0A--- a/xen/include/asm-x86/hvm/vmx/vmcs.h=0A+++ =
b/xen/include/asm-x86/hvm/vmx/vmcs.h=0A@@ -19,7 +19,6 @@=0A #ifndef =
__ASM_X86_HVM_VMX_VMCS_H__=0A #define __ASM_X86_HVM_VMX_VMCS_H__=0A =
=0A-#include <asm/config.h>=0A #include <asm/hvm/io.h>=0A #include =
<asm/hvm/vpmu.h>=0A =0A
--=__Part3F11721A.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

--=__Part3F11721A.1__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNhg-0002Up-7E; Thu, 12 Jan 2012 16:40: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 1RlNhe-0002TW-BH
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:40:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326386431!8829314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11427 invoked from network); 12 Jan 2012 16:40:32 -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 Jan 2012 16:40:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:40: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, 12 Jan 2012 16:40:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RlNhX-00038B-52; Thu, 12 Jan 2012 16:40:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNhX-0002Xd-4F;
	Thu, 12 Jan 2012 16:40:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.3327.70031.95629@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:40:31 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK7F+XbO2xDav8aQNRP00w6meWjV01puYqavtnm_hAumQg@mail.gmail.com>
References: <patchbomb.1324370958@alpine.localdomain>
	<20236.24922.535085.662049@mariner.uk.xensource.com>
	<CAPLaKK7F+XbO2xDav8aQNRP00w6meWjV01puYqavtnm_hAumQg@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] [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="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 0 of 4 v3] build: various=
 fixes for building with uclibc and libiconv"):
> 2012/1/10 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Applied all four, thanks.
> =

> I was waiting to rework #3 once we had a working configure, but thanks
> anyway. I will remove the CONFIG_LIBICONV once the configure script is
> in.

Right, that's what I was expecting, thanks.  I didn't think the
configure stuff ought to be on the critical path for the libiconv fix.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNhg-0002Up-7E; Thu, 12 Jan 2012 16:40: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 1RlNhe-0002TW-BH
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:40:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326386431!8829314!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11427 invoked from network); 12 Jan 2012 16:40:32 -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 Jan 2012 16:40:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977294"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:40: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, 12 Jan 2012 16:40:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RlNhX-00038B-52; Thu, 12 Jan 2012 16:40:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNhX-0002Xd-4F;
	Thu, 12 Jan 2012 16:40:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.3327.70031.95629@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:40:31 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK7F+XbO2xDav8aQNRP00w6meWjV01puYqavtnm_hAumQg@mail.gmail.com>
References: <patchbomb.1324370958@alpine.localdomain>
	<20236.24922.535085.662049@mariner.uk.xensource.com>
	<CAPLaKK7F+XbO2xDav8aQNRP00w6meWjV01puYqavtnm_hAumQg@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] [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="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 0 of 4 v3] build: various=
 fixes for building with uclibc and libiconv"):
> 2012/1/10 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Applied all four, thanks.
> =

> I was waiting to rework #3 once we had a working configure, but thanks
> anyway. I will remove the CONFIG_LIBICONV once the configure script is
> in.

Right, that's what I was expecting, thanks.  I didn't think the
configure stuff ought to be on the critical path for the libiconv fix.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:40:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNhg-0002Uz-JW; Thu, 12 Jan 2012 16:40: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 1RlNhe-0002Tc-UA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:40:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326386430!8339805!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 18391 invoked from network); 12 Jan 2012 16:40:30 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:40:30 -0000
Received: by wibhj8 with SMTP id hj8so1112035wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:40:29 -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=RkqtJMcUUC4QpccPxf94vLsMS5YbDHhxsCFhp77ME70=;
	b=meiL7rslsyNGkjO+93Ny8BpGC8XCBWo9yc4NAh91O5N5z2fsxE2zQnvw9l4UZIqoMv
	7eGcPJ1BVbaCAaka27y1euZmAT+U7f+2ugJC9zyx6l0UYtH8ZLRkVK2mK9K/RMtKCFFw
	naM4Z/sU6ek2ZKjneAv/9k912PFNlh2Q7RkjU=
Received: by 10.180.101.101 with SMTP id ff5mr1650924wib.14.1326386429914;
	Thu, 12 Jan 2012 08:40:29 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id ee6sm9914612wib.4.2012.01.12.08.40.28
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 08:40:29 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 16:40:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CB34BD7A.2892E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Add .gitignore files for files generated by
	the hypervisor build
Thread-Index: AczRSOLPaEM86RuYwUiCwXgL/hxg8A==
In-Reply-To: <20239.2928.421883.966193@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
 the hypervisor 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

On 12/01/2012 16:33, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Keir Fraser writes ("Re: [Xen-devel] [PATCH] Add .gitignore files for files
> generated by the hypervisor build"):
>> I'm sure we've done both .hgignore/.gitignore in some repositories in the
>> past. It sounds fine to me.
> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] .gitignore
> 
> Introduce a .gitignore file for the convenience of people who use git.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
>  .gitignore |  372
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 372 insertions(+), 0 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 0000000..625ceee
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,372 @@
> +.hg
> +*.orig
> +*.rej
> +*~
> +*.o
> +*.d
> +*.opic
> +*.a
> +*.so
> +*.so.[0-9]*
> +*.bin
> +*.bak
> +*.tmp
> +TAGS
> +.config
> +
> +dist
> +tools/ioemu-dir
> +tools/ioemu-remote
> +stubdom/*.tar.gz
> +
> +build-*
> +dist/*
> +docs/*.aux
> +docs/*.dvi
> +docs/*.log
> +docs/*.pdf
> +docs/*.ps
> +docs/*.toc
> +docs/api/*
> +docs/figs/xenserver.eps
> +docs/html/*
> +docs/interface/WARNINGS
> +docs/interface/images.pl
> +docs/interface/images.tex
> +docs/interface/img1.png
> +docs/interface/index.html
> +docs/interface/interface.css
> +docs/interface/interface.html
> +docs/interface/labels.pl
> +docs/man1/
> +docs/man5/
> +docs/pdf/*
> +docs/ps/*
> +docs/user/WARNINGS
> +docs/user/images.pl
> +docs/user/images.tex
> +docs/user/img1.png
> +docs/user/img2.png
> +docs/user/img3.png
> +docs/user/index.html
> +docs/user/internals.pl
> +docs/user/labels.pl
> +docs/user/user.css
> +docs/user/user.html
> +docs/xen-api/vm_lifecycle.eps
> +docs/xen-api/xenapi-datamodel-graph.eps
> +docs/xen-api/xenapi.out
> +docs/xen-api/xenapi.dvi
> +docs/xen-api/xenapi.pdf
> +docs/xen-api/xenapi.ps
> +docs/xen-api/xenapi.toc
> +extras/mini-os/arch/ia64/gen_off.s
> +extras/mini-os/include/mini-os
> +extras/mini-os/include/ia64/mini-os
> +extras/mini-os/include/ia64/offsets.h
> +extras/mini-os/include/x86/mini-os
> +extras/mini-os/include/xen
> +extras/mini-os/mini-os*
> +install/*
> +linux-[^/]*-paravirt/*
> +linux-2.6[^/]*/*
> +linux-[^/]*-rc/*
> +linux-[^/]*-tip/*
> +linux-[^/]*-git/*
> +linux-[^/]*.patch
> +mkddbxen
> +netbsd-[^/]*-tools/*
> +netbsd-[^/]*-xen0/*
> +netbsd-[^/]*-xenU/*
> +netbsd-[^/]*.patch
> +patches/*/.makedep
> +patches/ebtables-brnf-5_vs_2.4.25.diff
> +patches/ebtables.diff
> +patches/tmp/*
> +pristine-*
> +ref-*
> +tmp-*
> +stubdom/binutils-*
> +stubdom/cross-root-*
> +stubdom/gcc-*
> +stubdom/include
> +stubdom/ioemu
> +stubdom/xenstore
> +stubdom/libxc-*
> +stubdom/lwip-*
> +stubdom/mini-os-*
> +stubdom/mk-headers-*
> +stubdom/newlib-1.*
> +stubdom/newlib-x86*
> +stubdom/pciutils-*
> +stubdom/zlib-*
> +stubdom/grub-*
> +stubdom/ocaml-*
> +stubdom/lwip/
> +stubdom/ioemu/
> +stubdom/stubdompath.sh
> +tools/*/build/lib*/*.py
> +tools/blktap2/daemon/blktapctrl
> +tools/blktap2/drivers/img2qcow
> +tools/blktap2/drivers/lock-util
> +tools/blktap2/drivers/qcow-create
> +tools/blktap2/drivers/qcow2raw
> +tools/blktap2/drivers/tapdisk
> +tools/blktap2/drivers/tapdisk-client
> +tools/blktap2/drivers/tapdisk-diff
> +tools/blktap2/drivers/tapdisk-stream
> +tools/blktap2/drivers/tapdisk2
> +tools/blktap2/drivers/td-util
> +tools/blktap2/vhd/vhd-update
> +tools/blktap2/vhd/vhd-util
> +tools/blktap/drivers/blktapctrl
> +tools/blktap/drivers/img2qcow
> +tools/blktap/drivers/qcow-create
> +tools/blktap/drivers/qcow2raw
> +tools/blktap/drivers/tapdisk
> +tools/check/.*
> +tools/console/xenconsole
> +tools/console/xenconsoled
> +tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
> +tools/debugger/gdb/gdb-6.2.1/*
> +tools/debugger/gdb/gdb-6.2.1.tar.bz2
> +tools/debugger/gdbsx/gdbsx
> +tools/debugger/xenitp/xenitp
> +tools/firmware/*/biossums
> +tools/firmware/*.bin
> +tools/firmware/*.sym
> +tools/firmware/*bios/*bios*.txt
> +tools/firmware/etherboot/gpxe/*
> +tools/firmware/extboot/extboot.img
> +tools/firmware/extboot/signrom
> +tools/firmware/hvmloader/acpi/mk_dsdt
> +tools/firmware/hvmloader/acpi/dsdt*.c
> +tools/firmware/hvmloader/acpi/dsdt*.asl
> +tools/firmware/hvmloader/acpi/ssdt_*.h
> +tools/firmware/hvmloader/hvmloader
> +tools/firmware/hvmloader/roms.h
> +tools/firmware/hvmloader/roms.inc
> +tools/firmware/rombios/BIOS-bochs-[^/]*
> +tools/firmware/rombios/_rombios[^/]*_.c
> +tools/firmware/rombios/rombios[^/]*.s
> +tools/firmware/rombios/32bit/32bitbios_flat.h
> +tools/firmware/vgabios/vbetables-gen
> +tools/firmware/vgabios/vbetables.h
> +tools/flask/loadpolicy/flask-loadpolicy
> +tools/flask/utils/flask-getenforce
> +tools/flask/utils/flask-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/*
> +tools/include/xen-foreign/*.(c|h|size)
> +tools/include/xen-foreign/checker
> +tools/ioemu/.pc/*
> +tools/ioemu/config-host.h
> +tools/ioemu/config-host.mak
> +tools/ioemu/i386-dm/Makefile
> +tools/ioemu/i386-dm/config.h
> +tools/ioemu/i386-dm/config.mak
> +tools/ioemu/i386-dm/qemu-dm
> +tools/ioemu/qemu-doc.html
> +tools/ioemu/qemu-img.1
> +tools/ioemu/qemu-img.pod
> +tools/ioemu/qemu-tech.html
> +tools/ioemu/qemu.1
> +tools/ioemu/qemu.pod
> +tools/ioemu/tapdisk-ioemu
> +tools/libxc/ia64/asm/*.h
> +tools/libxc/ia64/acpi/*.h
> +tools/libxc/ia64/acpi/platform/*.h
> +tools/libxc/ia64/dom_fw_asm.S
> +tools/libxc/ia64/dom_fw_common.c
> +tools/libxc/ia64/dom_fw_domu.c
> +tools/libxc/ia64/xen/*.h
> +tools/libxen/libxenapi-
> +tools/libxen/test/test_bindings
> +tools/libxen/test/test_event_handling
> +tools/libxl/libxlu_cfg_y.output
> +tools/libxl/xl
> +tools/libxl/testenum
> +tools/libxl/testenum.c
> +tools/libaio/src/*.ol
> +tools/libaio/src/*.os
> +tools/misc/cpuperf/cpuperf-perfcntr
> +tools/misc/cpuperf/cpuperf-xen
> +tools/misc/lomount/lomount
> +tools/misc/mbootpack/bin2c
> +tools/misc/mbootpack/bootsect
> +tools/misc/mbootpack/bzimage_header.c
> +tools/misc/mbootpack/mbootpack
> +tools/misc/mbootpack/setup
> +tools/misc/miniterm/miniterm
> +tools/misc/xc_shadow
> +tools/misc/xen_cpuperf
> +tools/misc/xen-detect
> +tools/misc/xen-tmem-list-parse
> +tools/misc/xenperf
> +tools/misc/xenpm
> +tools/misc/xen-hvmctx
> +tools/misc/gtraceview
> +tools/misc/gtracestat
> +tools/misc/xenlockprof
> +tools/pygrub/build/*
> +tools/python/build/*
> +tools/python/xen/util/path.py
> +tools/remus/imqebt/imqebt
> +tools/remus/kmod/*(.cmd|.mod|.ko|.mod.c|.symvers|.xen)
> +tools/security/secpol_tool
> +tools/security/xen/*
> +tools/security/xensec_tool
> +tools/tests/blowfish.bin
> +tools/tests/blowfish.h
> +tools/tests/test_x86_emulator
> +tools/tests/x86_emulate
> +tools/tests/regression/installed/*
> +tools/tests/regression/build/*
> +tools/tests/regression/downloads/*
> +tools/vnet/Make.local
> +tools/vnet/build/*
> +tools/vnet/gc
> +tools/vnet/gc*/*
> +tools/vnet/vnet-module/*.ko
> +tools/vnet/vnet-module/.*.cmd
> +tools/vnet/vnet-module/.tmp_versions/*
> +tools/vnet/vnet-module/vnet_module.mod.*
> +tools/vnet/vnetd/vnetd
> +tools/vtpm/tpm_emulator-*.tar.gz
> +tools/vtpm/tpm_emulator/*
> +tools/vtpm/vtpm/*
> +tools/vtpm_manager/manager/vtpm_managerd
> +tools/xcutils/lsevtchn
> +tools/xcutils/xc_restore
> +tools/xcutils/xc_save
> +tools/xcutils/readnotes
> +tools/xenfb/sdlfb
> +tools/xenfb/vncfb
> +tools/xenmon/xentrace_setmask
> +tools/xenmon/xenbaked
> +tools/xenpaging/xenpaging
> +tools/xenpmd/xenpmd
> +tools/xenstat/xentop/xentop
> +tools/xenstore/testsuite/tmp/*
> +tools/xenstore/xen
> +tools/xenstore/xenstore
> +tools/xenstore/xenstore-chmod
> +tools/xenstore/xenstore-exists
> +tools/xenstore/xenstore-list
> +tools/xenstore/xenstore-read
> +tools/xenstore/xenstore-rm
> +tools/xenstore/xenstore-write
> +tools/xenstore/xenstore-control
> +tools/xenstore/xenstore-ls
> +tools/xenstore/xenstored
> +tools/xenstore/xenstored_test
> +tools/xenstore/xs_crashme
> +tools/xenstore/xs_random
> +tools/xenstore/xs_stress
> +tools/xenstore/xs_tdb_dump
> +tools/xenstore/xs_test
> +tools/xenstore/xs_watch_stress
> +tools/xentrace/xentrace_setsize
> +tools/xentrace/tbctl
> +tools/xentrace/xenctx
> +tools/xentrace/xentrace
> +tools/xm-test/ramdisk/buildroot
> +tools/xm-test/aclocal.m4
> +tools/xm-test/autom4te
> +tools/xm-test/install-sh
> +tools/xm-test/mkinstalldirs
> +tools/xm-test/missing
> +tools/xm-test/config(ure|.log|.status|.guess|.sub)
> +tools/xm-test/Makefile(.in)*
> +tools/xm-test/*/Makefile(.in)*
> +tools/xm-test/lib/XmTestLib/config.py
> +tools/xm-test/lib/XmTestReport/xmtest.py
> +tools/xm-test/tests/*.test
> +tools/ioemu-remote
> +tools/ioemu-dir
> +tools/ocaml-xenstored*
> +xen/.banner*
> +xen/BLOG
> +xen/System.map
> +xen/arch/x86/asm-offsets.s
> +xen/arch/x86/boot/mkelf32
> +xen/arch/x86/xen.lds
> +xen/arch/x86/boot/reloc.S
> +xen/ddb/*
> +xen/include/headers.chk
> +xen/include/asm
> +xen/include/asm-*/asm-offsets.h
> +xen/include/asm-ia64/asm-xsi-offsets.h
> +xen/include/asm-ia64/.offsets.h.stamp
> +xen/include/asm-ia64/xen
> +xen/include/compat/*
> +xen/include/hypervisor-ifs/arch
> +xen/include/linux
> +xen/include/public/public
> +xen/include/xen/*.new
> +xen/include/xen/acm_policy.h
> +xen/include/xen/banner.h
> +xen/include/xen/compile.h
> +xen/tools/figlet/figlet
> +xen/tools/symbols
> +xen/xen
> +xen/xen-syms
> +xen/xen.*
> +xen/arch/ia64/asm-offsets.s
> +xen/arch/ia64/asm-xsi-offsets.s
> +xen/arch/ia64/map.out
> +xen/arch/ia64/xen.lds.s
> +unmodified_drivers/linux-2.6/.tmp_versions
> +unmodified_drivers/linux-2.6/*.cmd
> +unmodified_drivers/linux-2.6/*.ko
> +unmodified_drivers/linux-2.6/*.mod.c
> +LibVNCServer*
> +
> +tools/firmware/rombios/_rombios_.c
> +tools/firmware/rombios/rombios.s
> +tools/firmware/rombios/rombios.sym
> +tools/include/xen-foreign/checker.c
> +tools/include/xen-foreign/ia64.h
> +tools/include/xen-foreign/structs.pyc
> +tools/include/xen-foreign/x86_32.h
> +tools/include/xen-foreign/x86_64.h
> +
> +.git
> +tools/misc/xen-hptool
> +tools/libxl/_*.[ch]
> +tools/libxl/testidl
> +tools/libxl/testidl.c
> +tools/libxl/*.pyc
> +tools/blktap2/control/tap-ctl
> +tools/firmware/etherboot/eb-roms.h
> +tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
> +tools/misc/xenwatchdogd
> +tools/misc/xen-hvmcrash
> +tools/libvchan/vchan-node[12]
> +tools/ocaml/*/.ocamldep.make
> +tools/ocaml/*/*.cm[ixao]
> +tools/ocaml/*/*.cmxa
> +tools/ocaml/*/*.annot
> +tools/ocaml/*/*/.ocamldep.make
> +tools/ocaml/*/*/*.cm[ixao]
> +tools/ocaml/*/*/*.cmxa
> +tools/ocaml/*/*/*.annot
> +tools/ocaml/*/*/META
> +tools/ocaml/libs/xl/_libxl_types.inc
> +tools/ocaml/libs/xl/_libxl_types.ml.in
> +tools/ocaml/libs/xl/_libxl_types.mli.in
> +tools/ocaml/libs/xl/xenlight.ml
> +tools/ocaml/xenstored/oxenstored
> +
> +tools/debugger/kdd/kdd
> +tools/firmware/etherboot/ipxe.tar.gz
> +tools/firmware/etherboot/ipxe/
> +tools/python/xen/lowlevel/xl/_pyxl_types.c
> +tools/python/xen/lowlevel/xl/_pyxl_types.h
> +tools/xenstore/xenstore-watch
> +
> +docs/txt/misc/*.txt
> +docs/txt/man/*.txt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:40:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:40:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNhg-0002Uz-JW; Thu, 12 Jan 2012 16:40: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 1RlNhe-0002Tc-UA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:40:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326386430!8339805!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 18391 invoked from network); 12 Jan 2012 16:40:30 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:40:30 -0000
Received: by wibhj8 with SMTP id hj8so1112035wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:40:29 -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=RkqtJMcUUC4QpccPxf94vLsMS5YbDHhxsCFhp77ME70=;
	b=meiL7rslsyNGkjO+93Ny8BpGC8XCBWo9yc4NAh91O5N5z2fsxE2zQnvw9l4UZIqoMv
	7eGcPJ1BVbaCAaka27y1euZmAT+U7f+2ugJC9zyx6l0UYtH8ZLRkVK2mK9K/RMtKCFFw
	naM4Z/sU6ek2ZKjneAv/9k912PFNlh2Q7RkjU=
Received: by 10.180.101.101 with SMTP id ff5mr1650924wib.14.1326386429914;
	Thu, 12 Jan 2012 08:40:29 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id ee6sm9914612wib.4.2012.01.12.08.40.28
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 08:40:29 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 16:40:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CB34BD7A.2892E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Add .gitignore files for files generated by
	the hypervisor build
Thread-Index: AczRSOLPaEM86RuYwUiCwXgL/hxg8A==
In-Reply-To: <20239.2928.421883.966193@mariner.uk.xensource.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
 the hypervisor 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

On 12/01/2012 16:33, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> Keir Fraser writes ("Re: [Xen-devel] [PATCH] Add .gitignore files for files
> generated by the hypervisor build"):
>> I'm sure we've done both .hgignore/.gitignore in some repositories in the
>> past. It sounds fine to me.
> 
> Ian.
> 
> From: Ian Jackson <ian.jackson@eu.citrix.com>
> Subject: [PATCH] .gitignore
> 
> Introduce a .gitignore file for the convenience of people who use git.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
>  .gitignore |  372
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 372 insertions(+), 0 deletions(-)
> 
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 0000000..625ceee
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,372 @@
> +.hg
> +*.orig
> +*.rej
> +*~
> +*.o
> +*.d
> +*.opic
> +*.a
> +*.so
> +*.so.[0-9]*
> +*.bin
> +*.bak
> +*.tmp
> +TAGS
> +.config
> +
> +dist
> +tools/ioemu-dir
> +tools/ioemu-remote
> +stubdom/*.tar.gz
> +
> +build-*
> +dist/*
> +docs/*.aux
> +docs/*.dvi
> +docs/*.log
> +docs/*.pdf
> +docs/*.ps
> +docs/*.toc
> +docs/api/*
> +docs/figs/xenserver.eps
> +docs/html/*
> +docs/interface/WARNINGS
> +docs/interface/images.pl
> +docs/interface/images.tex
> +docs/interface/img1.png
> +docs/interface/index.html
> +docs/interface/interface.css
> +docs/interface/interface.html
> +docs/interface/labels.pl
> +docs/man1/
> +docs/man5/
> +docs/pdf/*
> +docs/ps/*
> +docs/user/WARNINGS
> +docs/user/images.pl
> +docs/user/images.tex
> +docs/user/img1.png
> +docs/user/img2.png
> +docs/user/img3.png
> +docs/user/index.html
> +docs/user/internals.pl
> +docs/user/labels.pl
> +docs/user/user.css
> +docs/user/user.html
> +docs/xen-api/vm_lifecycle.eps
> +docs/xen-api/xenapi-datamodel-graph.eps
> +docs/xen-api/xenapi.out
> +docs/xen-api/xenapi.dvi
> +docs/xen-api/xenapi.pdf
> +docs/xen-api/xenapi.ps
> +docs/xen-api/xenapi.toc
> +extras/mini-os/arch/ia64/gen_off.s
> +extras/mini-os/include/mini-os
> +extras/mini-os/include/ia64/mini-os
> +extras/mini-os/include/ia64/offsets.h
> +extras/mini-os/include/x86/mini-os
> +extras/mini-os/include/xen
> +extras/mini-os/mini-os*
> +install/*
> +linux-[^/]*-paravirt/*
> +linux-2.6[^/]*/*
> +linux-[^/]*-rc/*
> +linux-[^/]*-tip/*
> +linux-[^/]*-git/*
> +linux-[^/]*.patch
> +mkddbxen
> +netbsd-[^/]*-tools/*
> +netbsd-[^/]*-xen0/*
> +netbsd-[^/]*-xenU/*
> +netbsd-[^/]*.patch
> +patches/*/.makedep
> +patches/ebtables-brnf-5_vs_2.4.25.diff
> +patches/ebtables.diff
> +patches/tmp/*
> +pristine-*
> +ref-*
> +tmp-*
> +stubdom/binutils-*
> +stubdom/cross-root-*
> +stubdom/gcc-*
> +stubdom/include
> +stubdom/ioemu
> +stubdom/xenstore
> +stubdom/libxc-*
> +stubdom/lwip-*
> +stubdom/mini-os-*
> +stubdom/mk-headers-*
> +stubdom/newlib-1.*
> +stubdom/newlib-x86*
> +stubdom/pciutils-*
> +stubdom/zlib-*
> +stubdom/grub-*
> +stubdom/ocaml-*
> +stubdom/lwip/
> +stubdom/ioemu/
> +stubdom/stubdompath.sh
> +tools/*/build/lib*/*.py
> +tools/blktap2/daemon/blktapctrl
> +tools/blktap2/drivers/img2qcow
> +tools/blktap2/drivers/lock-util
> +tools/blktap2/drivers/qcow-create
> +tools/blktap2/drivers/qcow2raw
> +tools/blktap2/drivers/tapdisk
> +tools/blktap2/drivers/tapdisk-client
> +tools/blktap2/drivers/tapdisk-diff
> +tools/blktap2/drivers/tapdisk-stream
> +tools/blktap2/drivers/tapdisk2
> +tools/blktap2/drivers/td-util
> +tools/blktap2/vhd/vhd-update
> +tools/blktap2/vhd/vhd-util
> +tools/blktap/drivers/blktapctrl
> +tools/blktap/drivers/img2qcow
> +tools/blktap/drivers/qcow-create
> +tools/blktap/drivers/qcow2raw
> +tools/blktap/drivers/tapdisk
> +tools/check/.*
> +tools/console/xenconsole
> +tools/console/xenconsoled
> +tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
> +tools/debugger/gdb/gdb-6.2.1/*
> +tools/debugger/gdb/gdb-6.2.1.tar.bz2
> +tools/debugger/gdbsx/gdbsx
> +tools/debugger/xenitp/xenitp
> +tools/firmware/*/biossums
> +tools/firmware/*.bin
> +tools/firmware/*.sym
> +tools/firmware/*bios/*bios*.txt
> +tools/firmware/etherboot/gpxe/*
> +tools/firmware/extboot/extboot.img
> +tools/firmware/extboot/signrom
> +tools/firmware/hvmloader/acpi/mk_dsdt
> +tools/firmware/hvmloader/acpi/dsdt*.c
> +tools/firmware/hvmloader/acpi/dsdt*.asl
> +tools/firmware/hvmloader/acpi/ssdt_*.h
> +tools/firmware/hvmloader/hvmloader
> +tools/firmware/hvmloader/roms.h
> +tools/firmware/hvmloader/roms.inc
> +tools/firmware/rombios/BIOS-bochs-[^/]*
> +tools/firmware/rombios/_rombios[^/]*_.c
> +tools/firmware/rombios/rombios[^/]*.s
> +tools/firmware/rombios/32bit/32bitbios_flat.h
> +tools/firmware/vgabios/vbetables-gen
> +tools/firmware/vgabios/vbetables.h
> +tools/flask/loadpolicy/flask-loadpolicy
> +tools/flask/utils/flask-getenforce
> +tools/flask/utils/flask-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/*
> +tools/include/xen-foreign/*.(c|h|size)
> +tools/include/xen-foreign/checker
> +tools/ioemu/.pc/*
> +tools/ioemu/config-host.h
> +tools/ioemu/config-host.mak
> +tools/ioemu/i386-dm/Makefile
> +tools/ioemu/i386-dm/config.h
> +tools/ioemu/i386-dm/config.mak
> +tools/ioemu/i386-dm/qemu-dm
> +tools/ioemu/qemu-doc.html
> +tools/ioemu/qemu-img.1
> +tools/ioemu/qemu-img.pod
> +tools/ioemu/qemu-tech.html
> +tools/ioemu/qemu.1
> +tools/ioemu/qemu.pod
> +tools/ioemu/tapdisk-ioemu
> +tools/libxc/ia64/asm/*.h
> +tools/libxc/ia64/acpi/*.h
> +tools/libxc/ia64/acpi/platform/*.h
> +tools/libxc/ia64/dom_fw_asm.S
> +tools/libxc/ia64/dom_fw_common.c
> +tools/libxc/ia64/dom_fw_domu.c
> +tools/libxc/ia64/xen/*.h
> +tools/libxen/libxenapi-
> +tools/libxen/test/test_bindings
> +tools/libxen/test/test_event_handling
> +tools/libxl/libxlu_cfg_y.output
> +tools/libxl/xl
> +tools/libxl/testenum
> +tools/libxl/testenum.c
> +tools/libaio/src/*.ol
> +tools/libaio/src/*.os
> +tools/misc/cpuperf/cpuperf-perfcntr
> +tools/misc/cpuperf/cpuperf-xen
> +tools/misc/lomount/lomount
> +tools/misc/mbootpack/bin2c
> +tools/misc/mbootpack/bootsect
> +tools/misc/mbootpack/bzimage_header.c
> +tools/misc/mbootpack/mbootpack
> +tools/misc/mbootpack/setup
> +tools/misc/miniterm/miniterm
> +tools/misc/xc_shadow
> +tools/misc/xen_cpuperf
> +tools/misc/xen-detect
> +tools/misc/xen-tmem-list-parse
> +tools/misc/xenperf
> +tools/misc/xenpm
> +tools/misc/xen-hvmctx
> +tools/misc/gtraceview
> +tools/misc/gtracestat
> +tools/misc/xenlockprof
> +tools/pygrub/build/*
> +tools/python/build/*
> +tools/python/xen/util/path.py
> +tools/remus/imqebt/imqebt
> +tools/remus/kmod/*(.cmd|.mod|.ko|.mod.c|.symvers|.xen)
> +tools/security/secpol_tool
> +tools/security/xen/*
> +tools/security/xensec_tool
> +tools/tests/blowfish.bin
> +tools/tests/blowfish.h
> +tools/tests/test_x86_emulator
> +tools/tests/x86_emulate
> +tools/tests/regression/installed/*
> +tools/tests/regression/build/*
> +tools/tests/regression/downloads/*
> +tools/vnet/Make.local
> +tools/vnet/build/*
> +tools/vnet/gc
> +tools/vnet/gc*/*
> +tools/vnet/vnet-module/*.ko
> +tools/vnet/vnet-module/.*.cmd
> +tools/vnet/vnet-module/.tmp_versions/*
> +tools/vnet/vnet-module/vnet_module.mod.*
> +tools/vnet/vnetd/vnetd
> +tools/vtpm/tpm_emulator-*.tar.gz
> +tools/vtpm/tpm_emulator/*
> +tools/vtpm/vtpm/*
> +tools/vtpm_manager/manager/vtpm_managerd
> +tools/xcutils/lsevtchn
> +tools/xcutils/xc_restore
> +tools/xcutils/xc_save
> +tools/xcutils/readnotes
> +tools/xenfb/sdlfb
> +tools/xenfb/vncfb
> +tools/xenmon/xentrace_setmask
> +tools/xenmon/xenbaked
> +tools/xenpaging/xenpaging
> +tools/xenpmd/xenpmd
> +tools/xenstat/xentop/xentop
> +tools/xenstore/testsuite/tmp/*
> +tools/xenstore/xen
> +tools/xenstore/xenstore
> +tools/xenstore/xenstore-chmod
> +tools/xenstore/xenstore-exists
> +tools/xenstore/xenstore-list
> +tools/xenstore/xenstore-read
> +tools/xenstore/xenstore-rm
> +tools/xenstore/xenstore-write
> +tools/xenstore/xenstore-control
> +tools/xenstore/xenstore-ls
> +tools/xenstore/xenstored
> +tools/xenstore/xenstored_test
> +tools/xenstore/xs_crashme
> +tools/xenstore/xs_random
> +tools/xenstore/xs_stress
> +tools/xenstore/xs_tdb_dump
> +tools/xenstore/xs_test
> +tools/xenstore/xs_watch_stress
> +tools/xentrace/xentrace_setsize
> +tools/xentrace/tbctl
> +tools/xentrace/xenctx
> +tools/xentrace/xentrace
> +tools/xm-test/ramdisk/buildroot
> +tools/xm-test/aclocal.m4
> +tools/xm-test/autom4te
> +tools/xm-test/install-sh
> +tools/xm-test/mkinstalldirs
> +tools/xm-test/missing
> +tools/xm-test/config(ure|.log|.status|.guess|.sub)
> +tools/xm-test/Makefile(.in)*
> +tools/xm-test/*/Makefile(.in)*
> +tools/xm-test/lib/XmTestLib/config.py
> +tools/xm-test/lib/XmTestReport/xmtest.py
> +tools/xm-test/tests/*.test
> +tools/ioemu-remote
> +tools/ioemu-dir
> +tools/ocaml-xenstored*
> +xen/.banner*
> +xen/BLOG
> +xen/System.map
> +xen/arch/x86/asm-offsets.s
> +xen/arch/x86/boot/mkelf32
> +xen/arch/x86/xen.lds
> +xen/arch/x86/boot/reloc.S
> +xen/ddb/*
> +xen/include/headers.chk
> +xen/include/asm
> +xen/include/asm-*/asm-offsets.h
> +xen/include/asm-ia64/asm-xsi-offsets.h
> +xen/include/asm-ia64/.offsets.h.stamp
> +xen/include/asm-ia64/xen
> +xen/include/compat/*
> +xen/include/hypervisor-ifs/arch
> +xen/include/linux
> +xen/include/public/public
> +xen/include/xen/*.new
> +xen/include/xen/acm_policy.h
> +xen/include/xen/banner.h
> +xen/include/xen/compile.h
> +xen/tools/figlet/figlet
> +xen/tools/symbols
> +xen/xen
> +xen/xen-syms
> +xen/xen.*
> +xen/arch/ia64/asm-offsets.s
> +xen/arch/ia64/asm-xsi-offsets.s
> +xen/arch/ia64/map.out
> +xen/arch/ia64/xen.lds.s
> +unmodified_drivers/linux-2.6/.tmp_versions
> +unmodified_drivers/linux-2.6/*.cmd
> +unmodified_drivers/linux-2.6/*.ko
> +unmodified_drivers/linux-2.6/*.mod.c
> +LibVNCServer*
> +
> +tools/firmware/rombios/_rombios_.c
> +tools/firmware/rombios/rombios.s
> +tools/firmware/rombios/rombios.sym
> +tools/include/xen-foreign/checker.c
> +tools/include/xen-foreign/ia64.h
> +tools/include/xen-foreign/structs.pyc
> +tools/include/xen-foreign/x86_32.h
> +tools/include/xen-foreign/x86_64.h
> +
> +.git
> +tools/misc/xen-hptool
> +tools/libxl/_*.[ch]
> +tools/libxl/testidl
> +tools/libxl/testidl.c
> +tools/libxl/*.pyc
> +tools/blktap2/control/tap-ctl
> +tools/firmware/etherboot/eb-roms.h
> +tools/firmware/etherboot/gpxe-git-snapshot.tar.gz
> +tools/misc/xenwatchdogd
> +tools/misc/xen-hvmcrash
> +tools/libvchan/vchan-node[12]
> +tools/ocaml/*/.ocamldep.make
> +tools/ocaml/*/*.cm[ixao]
> +tools/ocaml/*/*.cmxa
> +tools/ocaml/*/*.annot
> +tools/ocaml/*/*/.ocamldep.make
> +tools/ocaml/*/*/*.cm[ixao]
> +tools/ocaml/*/*/*.cmxa
> +tools/ocaml/*/*/*.annot
> +tools/ocaml/*/*/META
> +tools/ocaml/libs/xl/_libxl_types.inc
> +tools/ocaml/libs/xl/_libxl_types.ml.in
> +tools/ocaml/libs/xl/_libxl_types.mli.in
> +tools/ocaml/libs/xl/xenlight.ml
> +tools/ocaml/xenstored/oxenstored
> +
> +tools/debugger/kdd/kdd
> +tools/firmware/etherboot/ipxe.tar.gz
> +tools/firmware/etherboot/ipxe/
> +tools/python/xen/lowlevel/xl/_pyxl_types.c
> +tools/python/xen/lowlevel/xl/_pyxl_types.h
> +tools/xenstore/xenstore-watch
> +
> +docs/txt/misc/*.txt
> +docs/txt/man/*.txt



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:41:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNiP-0002eU-1v; Thu, 12 Jan 2012 16:41:25 +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 1RlNiN-0002dK-UA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:41:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326386477!10603296!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 13355 invoked from network); 12 Jan 2012 16:41:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 16:41:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlNiG-000E2I-Mx; Thu, 12 Jan 2012 16:41:16 +0000
Date: Thu, 12 Jan 2012 16:41:16 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112164116.GH47092@ocelot.phlegethon.org>
References: <e7028b298fe384d1c044.1326385206@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e7028b298fe384d1c044.1326385206@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/mm: Fix operator associativity bug in
	mm-locks.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

At 11:20 -0500 on 12 Jan (1326367206), Andres Lagar-Cavilla wrote:
> In an order-enforcing wrapper for an "external" recursive lock,
> we aim to increment/decrement a recurse count and only update the
> lock ordering on zero counts.
> 
> Unfortunately we incrementing/decrementing the pointer to the
> recurse count, rather than the count itself.

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 Jan 12 16:41:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:41:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNiP-0002eU-1v; Thu, 12 Jan 2012 16:41:25 +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 1RlNiN-0002dK-UA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:41:24 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326386477!10603296!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 13355 invoked from network); 12 Jan 2012 16:41:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 12 Jan 2012 16:41:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RlNiG-000E2I-Mx; Thu, 12 Jan 2012 16:41:16 +0000
Date: Thu, 12 Jan 2012 16:41:16 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120112164116.GH47092@ocelot.phlegethon.org>
References: <e7028b298fe384d1c044.1326385206@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e7028b298fe384d1c044.1326385206@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/mm: Fix operator associativity bug in
	mm-locks.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

At 11:20 -0500 on 12 Jan (1326367206), Andres Lagar-Cavilla wrote:
> In an order-enforcing wrapper for an "external" recursive lock,
> we aim to increment/decrement a recurse count and only update the
> lock ordering on zero counts.
> 
> Unfortunately we incrementing/decrementing the pointer to the
> recurse count, rather than the count itself.

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 Jan 12 16:42:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:42:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNjV-0002rr-I5; Thu, 12 Jan 2012 16:42:33 +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 1RlNjT-0002qO-Sa
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:42:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326386542!7553809!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11676 invoked from network); 12 Jan 2012 16:42:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 16:42:23 -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
	q0CGgIjZ013433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 16:42:19 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
	q0CGgHIv010893
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 16:42:17 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
	q0CGgGrZ004696; Thu, 12 Jan 2012 10:42:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 08:42:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5C9BD40308; Thu, 12 Jan 2012 11:40:25 -0500 (EST)
Date: Thu, 12 Jan 2012 11:40:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Message-ID: <20120112164025.GA22773@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120112161204.GC10269@phenom.dumpdata.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.0A090201.4F0F0D6C.0032,ss=1,re=0.000,fgs=0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 11:12:04AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 12, 2012 at 05:05:34PM +0100, Kay Sievers wrote:
> > On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > > On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> > 
> > >> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> > >>
> > >> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> > >> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
> > > Your patch that converts the xen-balloon to use the regular device bus driver
> > > (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
> > >
> > > The toolstack (xen-tools) use:
> > >
> > > /sys/devices/system/xen_memory/xen_memory0
> > >
> > > But with the change, it is now:
> > >
> > > /sys/devices/xen_memory0/target_kb
> > 
> > Urks, seems like a mistake on my side.
> > 
> > Please try if changing:
> >   bus_unregister(&balloon_subsys);
> > to:
> >   subsys_system_register(&balloon_subsys, NULL);
> > in:
> >   drivers/xen/xen-balloon.c
> > fixes the issue.
> 
> Heh. I was *just* looking at d369a5d8fc70710236ae2d06a0e42dce483712df
> ("clocksource: convert sysdev_class to a regular subsystem") and typed up this patch
> to try it out:

Kay, are you Acking this patch? (I can send it to Linus for rc0 or rc1)

commit 4e6f161986678a25c9e76af98df928408c734a27
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Jan 12 11:35:50 2012 -0500

    xen/balloon: Move the registration from device to subsystem.
    
    With git commit 070680218379e15c1901f4bf21b98e3cbf12b527
    "xen-balloon: convert sysdev_class to a regular subsystem" we would
    end up with the attributes being put in:
    
     /sys/devices/xen_memory0/target_kb
    instead of
    /sys/devices/system/xen_memory/xen_memory0/target_kb
    
    Making the tools unable to deflate the kernel to make more space
    for launching another guest and printing:

    Error: Failed to query current memory allocation of dom0
    
    Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
    Suggested-by:  Kay Sievers <kay.sievers@vrfy.org>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
index 3832e30..596e6a7 100644
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -221,7 +221,7 @@ static int register_balloon(struct device *dev)
 {
 	int i, error;
 
-	error = bus_register(&balloon_subsys);
+	error = subsys_system_register(&balloon_subsys, NULL);
 	if (error)
 		return error;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:42:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:42:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNjV-0002rr-I5; Thu, 12 Jan 2012 16:42:33 +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 1RlNjT-0002qO-Sa
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:42:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326386542!7553809!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11676 invoked from network); 12 Jan 2012 16:42:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 16:42:23 -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
	q0CGgIjZ013433
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 16:42:19 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
	q0CGgHIv010893
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 16:42:17 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
	q0CGgGrZ004696; Thu, 12 Jan 2012 10:42:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 08:42:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5C9BD40308; Thu, 12 Jan 2012 11:40:25 -0500 (EST)
Date: Thu, 12 Jan 2012 11:40:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Message-ID: <20120112164025.GA22773@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120112161204.GC10269@phenom.dumpdata.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.0A090201.4F0F0D6C.0032,ss=1,re=0.000,fgs=0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 11:12:04AM -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 12, 2012 at 05:05:34PM +0100, Kay Sievers wrote:
> > On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
> > <konrad.wilk@oracle.com> wrote:
> > > On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> > 
> > >> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> > >>
> > >> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> > >> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
> > > Your patch that converts the xen-balloon to use the regular device bus driver
> > > (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
> > >
> > > The toolstack (xen-tools) use:
> > >
> > > /sys/devices/system/xen_memory/xen_memory0
> > >
> > > But with the change, it is now:
> > >
> > > /sys/devices/xen_memory0/target_kb
> > 
> > Urks, seems like a mistake on my side.
> > 
> > Please try if changing:
> >   bus_unregister(&balloon_subsys);
> > to:
> >   subsys_system_register(&balloon_subsys, NULL);
> > in:
> >   drivers/xen/xen-balloon.c
> > fixes the issue.
> 
> Heh. I was *just* looking at d369a5d8fc70710236ae2d06a0e42dce483712df
> ("clocksource: convert sysdev_class to a regular subsystem") and typed up this patch
> to try it out:

Kay, are you Acking this patch? (I can send it to Linus for rc0 or rc1)

commit 4e6f161986678a25c9e76af98df928408c734a27
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Thu Jan 12 11:35:50 2012 -0500

    xen/balloon: Move the registration from device to subsystem.
    
    With git commit 070680218379e15c1901f4bf21b98e3cbf12b527
    "xen-balloon: convert sysdev_class to a regular subsystem" we would
    end up with the attributes being put in:
    
     /sys/devices/xen_memory0/target_kb
    instead of
    /sys/devices/system/xen_memory/xen_memory0/target_kb
    
    Making the tools unable to deflate the kernel to make more space
    for launching another guest and printing:

    Error: Failed to query current memory allocation of dom0
    
    Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
    Suggested-by:  Kay Sievers <kay.sievers@vrfy.org>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
index 3832e30..596e6a7 100644
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -221,7 +221,7 @@ static int register_balloon(struct device *dev)
 {
 	int i, error;
 
-	error = bus_register(&balloon_subsys);
+	error = subsys_system_register(&balloon_subsys, NULL);
 	if (error)
 		return error;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:46:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNmj-0003Nw-EK; Thu, 12 Jan 2012 16:45:53 +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 1RlNmi-0003Na-OH
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:45:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326386746!1911021!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8411 invoked from network); 12 Jan 2012 16:45: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;
	12 Jan 2012 16:45:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977496"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:45: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, 12 Jan 2012 16:45: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
	1RlNmc-00039w-5O; Thu, 12 Jan 2012 16:45:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNmc-0002YZ-4S;
	Thu, 12 Jan 2012 16:45:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.3642.95133.519979@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:45:46 +0000
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB34BD7A.2892E%keir.xen@gmail.com>
References: <20239.2928.421883.966193@mariner.uk.xensource.com>
	<CB34BD7A.2892E%keir.xen@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>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
 the hypervisor 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

Keir Fraser writes ("Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by the hypervisor build"):
> On 12/01/2012 16:33, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > Introduce a .gitignore file for the convenience of people who use git.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Acked-by: Keir Fraser <keir@xen.org>

Thanks, I've committed this right away before it becomes out of date ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:46:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNmj-0003Nw-EK; Thu, 12 Jan 2012 16:45:53 +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 1RlNmi-0003Na-OH
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:45:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326386746!1911021!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8411 invoked from network); 12 Jan 2012 16:45: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;
	12 Jan 2012 16:45:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977496"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:45: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, 12 Jan 2012 16:45: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
	1RlNmc-00039w-5O; Thu, 12 Jan 2012 16:45:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNmc-0002YZ-4S;
	Thu, 12 Jan 2012 16:45:46 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.3642.95133.519979@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:45:46 +0000
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB34BD7A.2892E%keir.xen@gmail.com>
References: <20239.2928.421883.966193@mariner.uk.xensource.com>
	<CB34BD7A.2892E%keir.xen@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>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by
 the hypervisor 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

Keir Fraser writes ("Re: [Xen-devel] [PATCH] Add .gitignore files for files generated by the hypervisor build"):
> On 12/01/2012 16:33, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:
> > Introduce a .gitignore file for the convenience of people who use git.
> > 
> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Acked-by: Keir Fraser <keir@xen.org>

Thanks, I've committed this right away before it becomes out of date ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:48:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNoz-0003Xl-5L; Thu, 12 Jan 2012 16:48: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 1RlNoy-0003XS-5i
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:48:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326386886!10787793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14575 invoked from network); 12 Jan 2012 16:48:06 -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 Jan 2012 16:48:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:48: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, 12 Jan 2012 16:48: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
	1RlNor-0003Ah-Jl; Thu, 12 Jan 2012 16:48:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNor-0002Yo-IN;
	Thu, 12 Jan 2012 16:48:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.3781.557131.765561@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:48:05 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326284268.17210.200.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.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>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] Driver domains and hotplug scripts, redux"):
> We need to consider 3 cases:
>       * guest initiated graceful shutdown
>       * toolstack initiated graceful shutdown
>       * toolstack initiated forceful destroy.

When we consider that the driver and toolstack domains might be
different, there are in fact three different levels of grace:
  i.   fully graceful: wait for both guest and driver domain
  ii.  semi graceful: mess up the guest, wait only for driver domain
  iii. very ungraceful: mess up the guest and the driver domain

I'm not sure whether how often we want (iii), but (ii) is going to be
the common case.  However:

> The forceful destroy case is different, it is effectively:
> 1. rm backend dir in xenstore.

That's (iii).  We want a way to do (ii) 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 Jan 12 16:48:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNoz-0003Xl-5L; Thu, 12 Jan 2012 16:48: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 1RlNoy-0003XS-5i
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:48:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326386886!10787793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14575 invoked from network); 12 Jan 2012 16:48:06 -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 Jan 2012 16:48:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977694"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:48: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, 12 Jan 2012 16:48: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
	1RlNor-0003Ah-Jl; Thu, 12 Jan 2012 16:48:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNor-0002Yo-IN;
	Thu, 12 Jan 2012 16:48:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.3781.557131.765561@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:48:05 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326284268.17210.200.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.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>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] Driver domains and hotplug scripts, redux"):
> We need to consider 3 cases:
>       * guest initiated graceful shutdown
>       * toolstack initiated graceful shutdown
>       * toolstack initiated forceful destroy.

When we consider that the driver and toolstack domains might be
different, there are in fact three different levels of grace:
  i.   fully graceful: wait for both guest and driver domain
  ii.  semi graceful: mess up the guest, wait only for driver domain
  iii. very ungraceful: mess up the guest and the driver domain

I'm not sure whether how often we want (iii), but (ii) is going to be
the common case.  However:

> The forceful destroy case is different, it is effectively:
> 1. rm backend dir in xenstore.

That's (iii).  We want a way to do (ii) 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 Jan 12 16:50:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNr0-0003g1-Mh; Thu, 12 Jan 2012 16:50: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 1RlNqy-0003fa-Vd
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:50:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326387008!10655155!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20651 invoked from network); 12 Jan 2012 16:50:10 -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;
	12 Jan 2012 16:50:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977771"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:50: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, 12 Jan 2012 16:50: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
	1RlNqp-0003BW-H1; Thu, 12 Jan 2012 16:50:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNqp-0002ZC-G2;
	Thu, 12 Jan 2012 16:50:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.3903.482693.622400@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:50:07 +0000
To: Dave Scott <Dave.Scott@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <81A73678E76EA642801C8F2E4823AD21C4F901F5A9@LONPMAILBOX01.citrite.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<81A73678E76EA642801C8F2E4823AD21C4F901F5A9@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dave Scott writes ("Re: [Xen-devel] Driver domains and hotplug scripts, redux"):
> FYI XCP/xapi is a heavy user of blktap2 and we use it like this:
> 
> 0. user calls VM.start
> 1. xapi invokes one of its "storage managers" (plugin scripts, one per
>    storage type) telling it to "attach" a disk.
> 2. the storage manager zones-in the relevant LUN and runs "tap-ctl"
>    commands to create a block device. This is returned to xapi.
> 3. xapi creates the block backend directory in xenstore with
>    "params=<block device>".

Thanks for the info.  Right, this is a model we should continue to
support in libxl.  All the "management" is done outside libxl, and
libxl is simply provided with the block device.

ATM libxl only supports taking an actual device name in /dev, and TBH
I can't really see that changing because some parts of libxl might
need to actually open it in dom0.

I guess though it wouldn't be hard for xapi to provide a name in
/dev.  It must surely make one for its own purposes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:50:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNr0-0003g1-Mh; Thu, 12 Jan 2012 16:50: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 1RlNqy-0003fa-Vd
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:50:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326387008!10655155!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20651 invoked from network); 12 Jan 2012 16:50:10 -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;
	12 Jan 2012 16:50:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9977771"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 16:50: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, 12 Jan 2012 16:50: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
	1RlNqp-0003BW-H1; Thu, 12 Jan 2012 16:50:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlNqp-0002ZC-G2;
	Thu, 12 Jan 2012 16:50:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.3903.482693.622400@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 16:50:07 +0000
To: Dave Scott <Dave.Scott@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <81A73678E76EA642801C8F2E4823AD21C4F901F5A9@LONPMAILBOX01.citrite.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<81A73678E76EA642801C8F2E4823AD21C4F901F5A9@LONPMAILBOX01.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Roger Pau Monné <roger.pau@entel.upc.edu>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dave Scott writes ("Re: [Xen-devel] Driver domains and hotplug scripts, redux"):
> FYI XCP/xapi is a heavy user of blktap2 and we use it like this:
> 
> 0. user calls VM.start
> 1. xapi invokes one of its "storage managers" (plugin scripts, one per
>    storage type) telling it to "attach" a disk.
> 2. the storage manager zones-in the relevant LUN and runs "tap-ctl"
>    commands to create a block device. This is returned to xapi.
> 3. xapi creates the block backend directory in xenstore with
>    "params=<block device>".

Thanks for the info.  Right, this is a model we should continue to
support in libxl.  All the "management" is done outside libxl, and
libxl is simply provided with the block device.

ATM libxl only supports taking an actual device name in /dev, and TBH
I can't really see that changing because some parts of libxl might
need to actually open it in dom0.

I guess though it wouldn't be hard for xapi to provide a name in
/dev.  It must surely make one for its own purposes.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:59:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNzF-000439-Qi; Thu, 12 Jan 2012 16:58:49 +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 1RlNzE-000430-E5
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:58:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326387521!7036472!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 24202 invoked from network); 12 Jan 2012 16:58:41 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:58:41 -0000
Received: by wgbdt11 with SMTP id dt11so2043620wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:58: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=b45mHDteUqKBq7mxLPLpjCplFcUaJ/WyODigcjDSDPg=;
	b=YM6E9iIMpZajEsDu3dtU7LaWH3IO3dv6kq+PFYc/rSXE9qPDHQQVX+BoTg/pQiCJhd
	5cTA81srA5zlenm/D3qYcI8E+HsmNFjAF/NbNXIGxgpdwcmJoFpwLiw4Ydpl0OhXTP0Y
	TCZeyyZ0VLLysmbr8W0zo8+R34Ogqg7LW+VGA=
Received: by 10.180.19.42 with SMTP id b10mr1805271wie.13.1326387521583;
	Thu, 12 Jan 2012 08:58:41 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id y5sm896853wiw.3.2012.01.12.08.58.38
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 08:58:41 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 16:58:26 +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: <CB34C1B2.374D7%keir@xen.org>
Thread-Topic: [PATCH 1/2] force inclusion of xen/config.h through compiler
	option
Thread-Index: AczRS2aK45Q6fNb88UKc6dH4zThJ/w==
In-Reply-To: <4F0F1AF7020000780006C2E7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1/2] force inclusion of xen/config.h through
 compiler option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 16:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> As we expect all source files to include the header as the first thing
> anyway, stop doing this by repeating the inclusion in each and every
> source file (and in many headers), but rather enforce this uniformly
> through the compiler command line.
> 
> As a first cleanup step, remove the explicit inclusion from all common
> headers. Further cleanup can be done incrementally.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -41,7 +41,7 @@ ALL_OBJS-y               += $(BASEDIR)/x
>  ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
>  ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
>  
> -CFLAGS-y                += -g -D__XEN__
> +CFLAGS-y                += -g -D__XEN__ --include
> $(BASEDIR)/include/xen/config.h
>  CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
>  CFLAGS-$(FLASK_ENABLE)  += -DFLASK_ENABLE -DXSM_MAGIC=0xf97cff8c
>  CFLAGS-$(FLASK_ENABLE)  += -DFLASK_DEVELOP -DFLASK_BOOTPARAM
> -DFLASK_AVC_STATS
> @@ -59,7 +59,7 @@ ifneq ($(max_phys_irqs),)
>  CFLAGS-y                += -DMAX_PHYS_IRQS=$(max_phys_irqs)
>  endif
>  
> -AFLAGS-y                += -D__ASSEMBLY__
> +AFLAGS-y                += -D__ASSEMBLY__ --include
> $(BASEDIR)/include/xen/config.h
>  
>  # Clang's built-in assembler can't handle .code16/.code32/.code64 yet
>  AFLAGS-$(clang)         += -no-integrated-as
> --- a/xen/include/xen/bitmap.h
> +++ b/xen/include/xen/bitmap.h
> @@ -3,7 +3,6 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -#include <xen/config.h>
>  #include <xen/lib.h>
>  #include <xen/types.h>
>  #include <xen/bitops.h>
> --- a/xen/include/xen/byteorder/swab.h
> +++ b/xen/include/xen/byteorder/swab.h
> @@ -10,8 +10,6 @@
>   *    to clean up support for bizarre-endian architectures.
>   */
>  
> -#include <xen/compiler.h>
> -
>  /* casts are necessary for constants, because we never know how for sure
>   * how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable way.
>   */
> --- a/xen/include/xen/cache.h
> +++ b/xen/include/xen/cache.h
> @@ -1,7 +1,6 @@
>  #ifndef __LINUX_CACHE_H
>  #define __LINUX_CACHE_H
>  
> -#include <xen/config.h>
>  #include <asm/cache.h>
>  
>  #ifndef L1_CACHE_ALIGN
> --- a/xen/include/xen/compat.h
> +++ b/xen/include/xen/compat.h
> @@ -5,8 +5,6 @@
>  #ifndef __XEN_COMPAT_H__
>  #define __XEN_COMPAT_H__
>  
> -#include <xen/config.h>
> -
>  #ifdef CONFIG_COMPAT
>  
>  #include <xen/types.h>
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -75,7 +75,6 @@
>   *    inside a macro, the way we do the other calls.
>   */
>  
> -#include <xen/config.h>
>  #include <xen/bitmap.h>
>  #include <xen/kernel.h>
>  
> --- a/xen/include/xen/ctype.h
> +++ b/xen/include/xen/ctype.h
> @@ -1,8 +1,6 @@
>  #ifndef _LINUX_CTYPE_H
>  #define _LINUX_CTYPE_H
>  
> -#include <xen/config.h>
> -
>  /*
>   * NOTE! This ctype does not handle EOF like the standard C
>   * library is required to.
> --- a/xen/include/xen/domain_page.h
> +++ b/xen/include/xen/domain_page.h
> @@ -9,7 +9,6 @@
>  #ifndef __XEN_DOMAIN_PAGE_H__
>  #define __XEN_DOMAIN_PAGE_H__
>  
> -#include <xen/config.h>
>  #include <xen/mm.h>
>  
>  #ifdef CONFIG_DOMAIN_PAGE
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -9,7 +9,6 @@
>  #ifndef __XEN_EVENT_H__
>  #define __XEN_EVENT_H__
>  
> -#include <xen/config.h>
>  #include <xen/sched.h>
>  #include <xen/smp.h>
>  #include <xen/softirq.h>
> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -24,7 +24,6 @@
>  #ifndef __XEN_GRANT_TABLE_H__
>  #define __XEN_GRANT_TABLE_H__
>  
> -#include <xen/config.h>
>  #include <public/grant_table.h>
>  #include <asm/grant_table.h>
>  
> --- a/xen/include/xen/hypercall.h
> +++ b/xen/include/xen/hypercall.h
> @@ -5,7 +5,6 @@
>  #ifndef __XEN_HYPERCALL_H__
>  #define __XEN_HYPERCALL_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/time.h>
>  #include <public/xen.h>
> --- a/xen/include/xen/init.h
> +++ b/xen/include/xen/init.h
> @@ -1,7 +1,6 @@
>  #ifndef _LINUX_INIT_H
>  #define _LINUX_INIT_H
>  
> -#include <xen/config.h>
>  #include <asm/init.h>
>  
>  /*
> --- a/xen/include/xen/inttypes.h
> +++ b/xen/include/xen/inttypes.h
> @@ -23,7 +23,6 @@
>  #ifndef _XEN_INTTYPES_H
>  #define _XEN_INTTYPES_H 1
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  
>  # if BITS_PER_LONG == 64
> --- a/xen/include/xen/irq.h
> +++ b/xen/include/xen/irq.h
> @@ -1,7 +1,6 @@
>  #ifndef __XEN_IRQ_H__
>  #define __XEN_IRQ_H__
>  
> -#include <xen/config.h>
>  #include <xen/cpumask.h>
>  #include <xen/rcupdate.h>
>  #include <xen/spinlock.h>
> --- a/xen/include/xen/irq_cpustat.h
> +++ b/xen/include/xen/irq_cpustat.h
> @@ -9,7 +9,6 @@
>   * Keith Owens <kaos@ocs.com.au> July 2000.
>   */
>  
> -#include <xen/config.h>
>  #include <asm/hardirq.h>
>  
>  /*
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -3,7 +3,6 @@
>  
>  #include <xen/inttypes.h>
>  #include <xen/stdarg.h>
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/xmalloc.h>
>  #include <xen/string.h>
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -28,7 +28,6 @@
>  #ifndef __XEN_MM_H__
>  #define __XEN_MM_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
> --- a/xen/include/xen/notifier.h
> +++ b/xen/include/xen/notifier.h
> @@ -10,7 +10,6 @@
>  #ifndef __XEN_NOTIFIER_H__
>  #define __XEN_NOTIFIER_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/errno.h>
>  #include <xen/kernel.h>
> --- a/xen/include/xen/numa.h
> +++ b/xen/include/xen/numa.h
> @@ -1,7 +1,6 @@
>  #ifndef _XEN_NUMA_H
>  #define _XEN_NUMA_H
>  
> -#include <xen/config.h>
>  #include <asm/numa.h>
>  
>  #ifndef NODES_SHIFT
> --- a/xen/include/xen/paging.h
> +++ b/xen/include/xen/paging.h
> @@ -2,8 +2,6 @@
>  #ifndef __XEN_PAGING_H__
>  #define __XEN_PAGING_H__
>  
> -#include <xen/config.h>
> -
>  #if defined CONFIG_PAGING_ASSISTANCE
>  
>  #include <asm/paging.h>
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -7,7 +7,6 @@
>  #ifndef __XEN_PCI_H__
>  #define __XEN_PCI_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
> --- a/xen/include/xen/percpu.h
> +++ b/xen/include/xen/percpu.h
> @@ -1,7 +1,6 @@
>  #ifndef __XEN_PERCPU_H__
>  #define __XEN_PERCPU_H__
>  
> -#include <xen/config.h>
>  #include <asm/percpu.h>
>  
>  /*
> --- a/xen/include/xen/preempt.h
> +++ b/xen/include/xen/preempt.h
> @@ -9,7 +9,6 @@
>  #ifndef __XEN_PREEMPT_H__
>  #define __XEN_PREEMPT_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/percpu.h>
>  
> --- a/xen/include/xen/radix-tree.h
> +++ b/xen/include/xen/radix-tree.h
> @@ -20,7 +20,6 @@
>  #ifndef _XEN_RADIX_TREE_H
>  #define _XEN_RADIX_TREE_H
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/lib.h>
>  #include <xen/rcupdate.h>
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -2,7 +2,6 @@
>  #ifndef __SCHED_H__
>  #define __SCHED_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/spinlock.h>
>  #include <xen/shared.h>
> --- a/xen/include/xen/shared.h
> +++ b/xen/include/xen/shared.h
> @@ -1,8 +1,6 @@
>  #ifndef __XEN_SHARED_H__
>  #define __XEN_SHARED_H__
>  
> -#include <xen/config.h>
> -
>  #ifdef CONFIG_COMPAT
>  
>  #include <compat/xen.h>
> --- a/xen/include/xen/smp.h
> +++ b/xen/include/xen/smp.h
> @@ -1,7 +1,6 @@
>  #ifndef __XEN_SMP_H__
>  #define __XEN_SMP_H__
>  
> -#include <xen/config.h>
>  #include <asm/smp.h>
>  
>  /*
> --- a/xen/include/xen/softirq.h
> +++ b/xen/include/xen/softirq.h
> @@ -11,7 +11,6 @@ enum {
>      NR_COMMON_SOFTIRQS
>  };
>  
> -#include <xen/config.h>
>  #include <xen/lib.h>
>  #include <xen/smp.h>
>  #include <asm/bitops.h>
> --- a/xen/include/xen/spinlock.h
> +++ b/xen/include/xen/spinlock.h
> @@ -1,7 +1,6 @@
>  #ifndef __SPINLOCK_H__
>  #define __SPINLOCK_H__
>  
> -#include <xen/config.h>
>  #include <asm/system.h>
>  #include <asm/spinlock.h>
>  
> --- a/xen/include/xen/symbols.h
> +++ b/xen/include/xen/symbols.h
> @@ -1,7 +1,6 @@
>  #ifndef _XEN_SYMBOLS_H
>  #define _XEN_SYMBOLS_H
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  
>  #define KSYM_NAME_LEN 127
> --- a/xen/include/xen/tmem_xen.h
> +++ b/xen/include/xen/tmem_xen.h
> @@ -9,7 +9,6 @@
>  #ifndef __XEN_TMEM_XEN_H__
>  #define __XEN_TMEM_XEN_H__
>  
> -#include <xen/config.h>
>  #include <xen/mm.h> /* heap alloc/free */
>  #include <xen/xmalloc.h> /* xmalloc/xfree */
>  #include <xen/sched.h>  /* struct domain */
> --- a/xen/include/xen/trace.h
> +++ b/xen/include/xen/trace.h
> @@ -23,7 +23,6 @@
>  
>  extern int tb_init_done;
>  
> -#include <xen/config.h>
>  #include <public/sysctl.h>
>  #include <public/trace.h>
>  #include <asm/trace.h>
> --- a/xen/include/xen/types.h
> +++ b/xen/include/xen/types.h
> @@ -1,7 +1,6 @@
>  #ifndef __TYPES_H__
>  #define __TYPES_H__
>  
> -#include <xen/config.h>
>  #include <asm/types.h>
>  
>  #define BITS_TO_LONGS(bits) \
> --- a/xen/include/xen/vga.h
> +++ b/xen/include/xen/vga.h
> @@ -9,7 +9,6 @@
>  #ifndef _XEN_VGA_H
>  #define _XEN_VGA_H
>  
> -#include <xen/config.h>
>  #include <public/xen.h>
>  
>  #ifdef CONFIG_VGA
> --- a/xen/include/xen/xenoprof.h
> +++ b/xen/include/xen/xenoprof.h
> @@ -10,7 +10,6 @@
>  #ifndef __XEN_XENOPROF_H__
>  #define __XEN_XENOPROF_H__
>  
> -#include <xen/config.h>
>  #include <xen/inttypes.h>
>  #include <public/xenoprof.h>
>  #include <asm/xenoprof.h>
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:59:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16: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 1RlNzF-000439-Qi; Thu, 12 Jan 2012 16:58:49 +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 1RlNzE-000430-E5
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:58:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326387521!7036472!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 24202 invoked from network); 12 Jan 2012 16:58:41 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:58:41 -0000
Received: by wgbdt11 with SMTP id dt11so2043620wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:58: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=b45mHDteUqKBq7mxLPLpjCplFcUaJ/WyODigcjDSDPg=;
	b=YM6E9iIMpZajEsDu3dtU7LaWH3IO3dv6kq+PFYc/rSXE9qPDHQQVX+BoTg/pQiCJhd
	5cTA81srA5zlenm/D3qYcI8E+HsmNFjAF/NbNXIGxgpdwcmJoFpwLiw4Ydpl0OhXTP0Y
	TCZeyyZ0VLLysmbr8W0zo8+R34Ogqg7LW+VGA=
Received: by 10.180.19.42 with SMTP id b10mr1805271wie.13.1326387521583;
	Thu, 12 Jan 2012 08:58:41 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id y5sm896853wiw.3.2012.01.12.08.58.38
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 08:58:41 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 16:58:26 +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: <CB34C1B2.374D7%keir@xen.org>
Thread-Topic: [PATCH 1/2] force inclusion of xen/config.h through compiler
	option
Thread-Index: AczRS2aK45Q6fNb88UKc6dH4zThJ/w==
In-Reply-To: <4F0F1AF7020000780006C2E7@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 1/2] force inclusion of xen/config.h through
 compiler option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 16:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> As we expect all source files to include the header as the first thing
> anyway, stop doing this by repeating the inclusion in each and every
> source file (and in many headers), but rather enforce this uniformly
> through the compiler command line.
> 
> As a first cleanup step, remove the explicit inclusion from all common
> headers. Further cleanup can be done incrementally.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -41,7 +41,7 @@ ALL_OBJS-y               += $(BASEDIR)/x
>  ALL_OBJS-y               += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
>  ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
>  
> -CFLAGS-y                += -g -D__XEN__
> +CFLAGS-y                += -g -D__XEN__ --include
> $(BASEDIR)/include/xen/config.h
>  CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
>  CFLAGS-$(FLASK_ENABLE)  += -DFLASK_ENABLE -DXSM_MAGIC=0xf97cff8c
>  CFLAGS-$(FLASK_ENABLE)  += -DFLASK_DEVELOP -DFLASK_BOOTPARAM
> -DFLASK_AVC_STATS
> @@ -59,7 +59,7 @@ ifneq ($(max_phys_irqs),)
>  CFLAGS-y                += -DMAX_PHYS_IRQS=$(max_phys_irqs)
>  endif
>  
> -AFLAGS-y                += -D__ASSEMBLY__
> +AFLAGS-y                += -D__ASSEMBLY__ --include
> $(BASEDIR)/include/xen/config.h
>  
>  # Clang's built-in assembler can't handle .code16/.code32/.code64 yet
>  AFLAGS-$(clang)         += -no-integrated-as
> --- a/xen/include/xen/bitmap.h
> +++ b/xen/include/xen/bitmap.h
> @@ -3,7 +3,6 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -#include <xen/config.h>
>  #include <xen/lib.h>
>  #include <xen/types.h>
>  #include <xen/bitops.h>
> --- a/xen/include/xen/byteorder/swab.h
> +++ b/xen/include/xen/byteorder/swab.h
> @@ -10,8 +10,6 @@
>   *    to clean up support for bizarre-endian architectures.
>   */
>  
> -#include <xen/compiler.h>
> -
>  /* casts are necessary for constants, because we never know how for sure
>   * how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable way.
>   */
> --- a/xen/include/xen/cache.h
> +++ b/xen/include/xen/cache.h
> @@ -1,7 +1,6 @@
>  #ifndef __LINUX_CACHE_H
>  #define __LINUX_CACHE_H
>  
> -#include <xen/config.h>
>  #include <asm/cache.h>
>  
>  #ifndef L1_CACHE_ALIGN
> --- a/xen/include/xen/compat.h
> +++ b/xen/include/xen/compat.h
> @@ -5,8 +5,6 @@
>  #ifndef __XEN_COMPAT_H__
>  #define __XEN_COMPAT_H__
>  
> -#include <xen/config.h>
> -
>  #ifdef CONFIG_COMPAT
>  
>  #include <xen/types.h>
> --- a/xen/include/xen/cpumask.h
> +++ b/xen/include/xen/cpumask.h
> @@ -75,7 +75,6 @@
>   *    inside a macro, the way we do the other calls.
>   */
>  
> -#include <xen/config.h>
>  #include <xen/bitmap.h>
>  #include <xen/kernel.h>
>  
> --- a/xen/include/xen/ctype.h
> +++ b/xen/include/xen/ctype.h
> @@ -1,8 +1,6 @@
>  #ifndef _LINUX_CTYPE_H
>  #define _LINUX_CTYPE_H
>  
> -#include <xen/config.h>
> -
>  /*
>   * NOTE! This ctype does not handle EOF like the standard C
>   * library is required to.
> --- a/xen/include/xen/domain_page.h
> +++ b/xen/include/xen/domain_page.h
> @@ -9,7 +9,6 @@
>  #ifndef __XEN_DOMAIN_PAGE_H__
>  #define __XEN_DOMAIN_PAGE_H__
>  
> -#include <xen/config.h>
>  #include <xen/mm.h>
>  
>  #ifdef CONFIG_DOMAIN_PAGE
> --- a/xen/include/xen/event.h
> +++ b/xen/include/xen/event.h
> @@ -9,7 +9,6 @@
>  #ifndef __XEN_EVENT_H__
>  #define __XEN_EVENT_H__
>  
> -#include <xen/config.h>
>  #include <xen/sched.h>
>  #include <xen/smp.h>
>  #include <xen/softirq.h>
> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -24,7 +24,6 @@
>  #ifndef __XEN_GRANT_TABLE_H__
>  #define __XEN_GRANT_TABLE_H__
>  
> -#include <xen/config.h>
>  #include <public/grant_table.h>
>  #include <asm/grant_table.h>
>  
> --- a/xen/include/xen/hypercall.h
> +++ b/xen/include/xen/hypercall.h
> @@ -5,7 +5,6 @@
>  #ifndef __XEN_HYPERCALL_H__
>  #define __XEN_HYPERCALL_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/time.h>
>  #include <public/xen.h>
> --- a/xen/include/xen/init.h
> +++ b/xen/include/xen/init.h
> @@ -1,7 +1,6 @@
>  #ifndef _LINUX_INIT_H
>  #define _LINUX_INIT_H
>  
> -#include <xen/config.h>
>  #include <asm/init.h>
>  
>  /*
> --- a/xen/include/xen/inttypes.h
> +++ b/xen/include/xen/inttypes.h
> @@ -23,7 +23,6 @@
>  #ifndef _XEN_INTTYPES_H
>  #define _XEN_INTTYPES_H 1
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  
>  # if BITS_PER_LONG == 64
> --- a/xen/include/xen/irq.h
> +++ b/xen/include/xen/irq.h
> @@ -1,7 +1,6 @@
>  #ifndef __XEN_IRQ_H__
>  #define __XEN_IRQ_H__
>  
> -#include <xen/config.h>
>  #include <xen/cpumask.h>
>  #include <xen/rcupdate.h>
>  #include <xen/spinlock.h>
> --- a/xen/include/xen/irq_cpustat.h
> +++ b/xen/include/xen/irq_cpustat.h
> @@ -9,7 +9,6 @@
>   * Keith Owens <kaos@ocs.com.au> July 2000.
>   */
>  
> -#include <xen/config.h>
>  #include <asm/hardirq.h>
>  
>  /*
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -3,7 +3,6 @@
>  
>  #include <xen/inttypes.h>
>  #include <xen/stdarg.h>
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/xmalloc.h>
>  #include <xen/string.h>
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -28,7 +28,6 @@
>  #ifndef __XEN_MM_H__
>  #define __XEN_MM_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
> --- a/xen/include/xen/notifier.h
> +++ b/xen/include/xen/notifier.h
> @@ -10,7 +10,6 @@
>  #ifndef __XEN_NOTIFIER_H__
>  #define __XEN_NOTIFIER_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/errno.h>
>  #include <xen/kernel.h>
> --- a/xen/include/xen/numa.h
> +++ b/xen/include/xen/numa.h
> @@ -1,7 +1,6 @@
>  #ifndef _XEN_NUMA_H
>  #define _XEN_NUMA_H
>  
> -#include <xen/config.h>
>  #include <asm/numa.h>
>  
>  #ifndef NODES_SHIFT
> --- a/xen/include/xen/paging.h
> +++ b/xen/include/xen/paging.h
> @@ -2,8 +2,6 @@
>  #ifndef __XEN_PAGING_H__
>  #define __XEN_PAGING_H__
>  
> -#include <xen/config.h>
> -
>  #if defined CONFIG_PAGING_ASSISTANCE
>  
>  #include <asm/paging.h>
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -7,7 +7,6 @@
>  #ifndef __XEN_PCI_H__
>  #define __XEN_PCI_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
> --- a/xen/include/xen/percpu.h
> +++ b/xen/include/xen/percpu.h
> @@ -1,7 +1,6 @@
>  #ifndef __XEN_PERCPU_H__
>  #define __XEN_PERCPU_H__
>  
> -#include <xen/config.h>
>  #include <asm/percpu.h>
>  
>  /*
> --- a/xen/include/xen/preempt.h
> +++ b/xen/include/xen/preempt.h
> @@ -9,7 +9,6 @@
>  #ifndef __XEN_PREEMPT_H__
>  #define __XEN_PREEMPT_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/percpu.h>
>  
> --- a/xen/include/xen/radix-tree.h
> +++ b/xen/include/xen/radix-tree.h
> @@ -20,7 +20,6 @@
>  #ifndef _XEN_RADIX_TREE_H
>  #define _XEN_RADIX_TREE_H
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/lib.h>
>  #include <xen/rcupdate.h>
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -2,7 +2,6 @@
>  #ifndef __SCHED_H__
>  #define __SCHED_H__
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  #include <xen/spinlock.h>
>  #include <xen/shared.h>
> --- a/xen/include/xen/shared.h
> +++ b/xen/include/xen/shared.h
> @@ -1,8 +1,6 @@
>  #ifndef __XEN_SHARED_H__
>  #define __XEN_SHARED_H__
>  
> -#include <xen/config.h>
> -
>  #ifdef CONFIG_COMPAT
>  
>  #include <compat/xen.h>
> --- a/xen/include/xen/smp.h
> +++ b/xen/include/xen/smp.h
> @@ -1,7 +1,6 @@
>  #ifndef __XEN_SMP_H__
>  #define __XEN_SMP_H__
>  
> -#include <xen/config.h>
>  #include <asm/smp.h>
>  
>  /*
> --- a/xen/include/xen/softirq.h
> +++ b/xen/include/xen/softirq.h
> @@ -11,7 +11,6 @@ enum {
>      NR_COMMON_SOFTIRQS
>  };
>  
> -#include <xen/config.h>
>  #include <xen/lib.h>
>  #include <xen/smp.h>
>  #include <asm/bitops.h>
> --- a/xen/include/xen/spinlock.h
> +++ b/xen/include/xen/spinlock.h
> @@ -1,7 +1,6 @@
>  #ifndef __SPINLOCK_H__
>  #define __SPINLOCK_H__
>  
> -#include <xen/config.h>
>  #include <asm/system.h>
>  #include <asm/spinlock.h>
>  
> --- a/xen/include/xen/symbols.h
> +++ b/xen/include/xen/symbols.h
> @@ -1,7 +1,6 @@
>  #ifndef _XEN_SYMBOLS_H
>  #define _XEN_SYMBOLS_H
>  
> -#include <xen/config.h>
>  #include <xen/types.h>
>  
>  #define KSYM_NAME_LEN 127
> --- a/xen/include/xen/tmem_xen.h
> +++ b/xen/include/xen/tmem_xen.h
> @@ -9,7 +9,6 @@
>  #ifndef __XEN_TMEM_XEN_H__
>  #define __XEN_TMEM_XEN_H__
>  
> -#include <xen/config.h>
>  #include <xen/mm.h> /* heap alloc/free */
>  #include <xen/xmalloc.h> /* xmalloc/xfree */
>  #include <xen/sched.h>  /* struct domain */
> --- a/xen/include/xen/trace.h
> +++ b/xen/include/xen/trace.h
> @@ -23,7 +23,6 @@
>  
>  extern int tb_init_done;
>  
> -#include <xen/config.h>
>  #include <public/sysctl.h>
>  #include <public/trace.h>
>  #include <asm/trace.h>
> --- a/xen/include/xen/types.h
> +++ b/xen/include/xen/types.h
> @@ -1,7 +1,6 @@
>  #ifndef __TYPES_H__
>  #define __TYPES_H__
>  
> -#include <xen/config.h>
>  #include <asm/types.h>
>  
>  #define BITS_TO_LONGS(bits) \
> --- a/xen/include/xen/vga.h
> +++ b/xen/include/xen/vga.h
> @@ -9,7 +9,6 @@
>  #ifndef _XEN_VGA_H
>  #define _XEN_VGA_H
>  
> -#include <xen/config.h>
>  #include <public/xen.h>
>  
>  #ifdef CONFIG_VGA
> --- a/xen/include/xen/xenoprof.h
> +++ b/xen/include/xen/xenoprof.h
> @@ -10,7 +10,6 @@
>  #ifndef __XEN_XENOPROF_H__
>  #define __XEN_XENOPROF_H__
>  
> -#include <xen/config.h>
>  #include <xen/inttypes.h>
>  #include <public/xenoprof.h>
>  #include <asm/xenoprof.h>
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:59:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:59:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNzM-000449-P8; Thu, 12 Jan 2012 16:58:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kay.sievers@vrfy.org>) id 1RlNzL-00043n-KT
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:58:55 +0000
X-Env-Sender: kay.sievers@vrfy.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326387512!62202953!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 28256 invoked from network); 12 Jan 2012 16:58:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:58:34 -0000
Received: by daec6 with SMTP id c6so10762646dae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrfy.org; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=KDiPMHrNwkxRlNwidaWfkECk5V+cwmegdF1x5t892lQ=;
	b=X3iIyjv41+xpmf6iMwKZWewvFDk5uPQyJIT0cDg3ATq4PBbKLJW34UgbD6vteXMsJ0
	k3RoonfWc2XddunOgyuFiITJMhluUwFQR40XqclVepB4V0EBd3uejwOjYeOWPQgYo+PZ
	qQVmYLN8E1vNJ9uY9Bu4DSCTl0t19jYzo7hbw=
Received: by 10.68.211.198 with SMTP id ne6mr9664232pbc.83.1326387532163; Thu,
	12 Jan 2012 08:58:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.34.14 with HTTP; Thu, 12 Jan 2012 08:58:31 -0800 (PST)
In-Reply-To: <20120112164025.GA22773@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
	<20120112164025.GA22773@phenom.dumpdata.com>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu, 12 Jan 2012 17:58:31 +0100
Message-ID: <CAPXgP12zOtbzVVqjzt8S8uX6OrVWgbuveyzX3uxirjtgW0xq-g@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBKYW4gMTIsIDIwMTIgYXQgMTc6NDAsIEtvbnJhZCBSemVzenV0ZWsgV2lsawo8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4gT24gVGh1LCBKYW4gMTIsIDIwMTIgYXQgMTE6
MTI6MDRBTSAtMDUwMCwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+PiBPbiBUaHUsIEph
biAxMiwgMjAxMiBhdCAwNTowNTozNFBNICswMTAwLCBLYXkgU2lldmVycyB3cm90ZToKPj4gPiBP
biBUaHUsIEphbiAxMiwgMjAxMiBhdCAxNjo0NiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCj4+ID4g
PGtvbnJhZC53aWxrQG9yYWNsZS5jb20+IHdyb3RlOgo+PiA+ID4gT24gVGh1LCBKYW4gMTIsIDIw
MTIgYXQgMDE6Mzg6MzJQTSArMDEwMCwgU2FuZGVyIEVpa2VsZW5ib29tIHdyb3RlOgo+PiA+Cj4+
ID4gPj4gVG9kYXkgaSB0cmllZCBsaW51c2VzIHRyZWUgb2YgdG9kYXkgKGxhc3QgY29tbWl0IGlz
IDRjNGQyODVhZDU2NjViZmJkOTgzYjk1ZmRlOGQ3YTQ3N2QyNGEzNjEpLgo+PiA+ID4+Cj4+ID4g
Pj4gSXQgYm9vdHMgZG9tMCBmaW5lLCBidXQgaXQgZmFpbHMgdG8gc3RhcnQgYW55IGRvbVUgd2l0
aDogIkVycm9yOiBGYWlsZWQgdG8gcXVlcnkgY3VycmVudCBtZW1vcnkgYWxsb2NhdGlvbiBvZiBk
b20wLiIKPj4gPiA+PiBXaXRoIG15IHByZXZpb3VzIDMuMS41IGtlcm5lbCBldmVyeXRoaW5nIGlz
IGZpbmUsIG5vdGhpbmcgZWxzZSBjaGFuZ2VkIGluIGNvbmZpZyBpbiBiZXR3ZWVuLgo+PiA+ID4g
WW91ciBwYXRjaCB0aGF0IGNvbnZlcnRzIHRoZSB4ZW4tYmFsbG9vbiB0byB1c2UgdGhlIHJlZ3Vs
YXIgZGV2aWNlIGJ1cyBkcml2ZXIKPj4gPiA+ICgwNzA2ODAyMTgzNzllMTVjMTkwMWY0YmYyMWI5
OGUzY2JmMTJiNTI3KSBoYXMgc29tZSBub3Qtc28taGFwcHkgY29uc2VxdWVuY2VzLgo+PiA+ID4K
Pj4gPiA+IFRoZSB0b29sc3RhY2sgKHhlbi10b29scykgdXNlOgo+PiA+ID4KPj4gPiA+IC9zeXMv
ZGV2aWNlcy9zeXN0ZW0veGVuX21lbW9yeS94ZW5fbWVtb3J5MAo+PiA+ID4KPj4gPiA+IEJ1dCB3
aXRoIHRoZSBjaGFuZ2UsIGl0IGlzIG5vdzoKPj4gPiA+Cj4+ID4gPiAvc3lzL2RldmljZXMveGVu
X21lbW9yeTAvdGFyZ2V0X2tiCj4+ID4KPj4gPiBVcmtzLCBzZWVtcyBsaWtlIGEgbWlzdGFrZSBv
biBteSBzaWRlLgo+PiA+Cj4+ID4gUGxlYXNlIHRyeSBpZiBjaGFuZ2luZzoKPj4gPiDCoCBidXNf
dW5yZWdpc3RlcigmYmFsbG9vbl9zdWJzeXMpOwo+PiA+IHRvOgo+PiA+IMKgIHN1YnN5c19zeXN0
ZW1fcmVnaXN0ZXIoJmJhbGxvb25fc3Vic3lzLCBOVUxMKTsKPj4gPiBpbjoKPj4gPiDCoCBkcml2
ZXJzL3hlbi94ZW4tYmFsbG9vbi5jCj4+ID4gZml4ZXMgdGhlIGlzc3VlLgo+Pgo+PiBIZWguIEkg
d2FzICpqdXN0KiBsb29raW5nIGF0IGQzNjlhNWQ4ZmM3MDcxMDIzNmFlMmQwNmEwZTQyZGNlNDgz
NzEyZGYKPj4gKCJjbG9ja3NvdXJjZTogY29udmVydCBzeXNkZXZfY2xhc3MgdG8gYSByZWd1bGFy
IHN1YnN5c3RlbSIpIGFuZCB0eXBlZCB1cCB0aGlzIHBhdGNoCj4+IHRvIHRyeSBpdCBvdXQ6Cj4K
PiBLYXksIGFyZSB5b3UgQWNraW5nIHRoaXMgcGF0Y2g/IChJIGNhbiBzZW5kIGl0IHRvIExpbnVz
IGZvciByYzAgb3IgcmMxKQo+Cj4gY29tbWl0IDRlNmYxNjE5ODY2NzhhMjVjOWU3NmFmOThkZjky
ODQwOGM3MzRhMjcKPiBBdXRob3I6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtA
b3JhY2xlLmNvbT4KPiBEYXRlOiDCoCBUaHUgSmFuIDEyIDExOjM1OjUwIDIwMTIgLTA1MDAKPgo+
IMKgIMKgeGVuL2JhbGxvb246IE1vdmUgdGhlIHJlZ2lzdHJhdGlvbiBmcm9tIGRldmljZSB0byBz
dWJzeXN0ZW0uCj4KPiDCoCDCoFdpdGggZ2l0IGNvbW1pdCAwNzA2ODAyMTgzNzllMTVjMTkwMWY0
YmYyMWI5OGUzY2JmMTJiNTI3Cj4gwqAgwqAieGVuLWJhbGxvb246IGNvbnZlcnQgc3lzZGV2X2Ns
YXNzIHRvIGEgcmVndWxhciBzdWJzeXN0ZW0iIHdlIHdvdWxkCj4gwqAgwqBlbmQgdXAgd2l0aCB0
aGUgYXR0cmlidXRlcyBiZWluZyBwdXQgaW46Cj4KPiDCoCDCoCAvc3lzL2RldmljZXMveGVuX21l
bW9yeTAvdGFyZ2V0X2tiCj4gwqAgwqBpbnN0ZWFkIG9mCj4gwqAgwqAvc3lzL2RldmljZXMvc3lz
dGVtL3hlbl9tZW1vcnkveGVuX21lbW9yeTAvdGFyZ2V0X2tiCj4KPiDCoCDCoE1ha2luZyB0aGUg
dG9vbHMgdW5hYmxlIHRvIGRlZmxhdGUgdGhlIGtlcm5lbCB0byBtYWtlIG1vcmUgc3BhY2UKPiDC
oCDCoGZvciBsYXVuY2hpbmcgYW5vdGhlciBndWVzdCBhbmQgcHJpbnRpbmc6Cj4KPiDCoCDCoEVy
cm9yOiBGYWlsZWQgdG8gcXVlcnkgY3VycmVudCBtZW1vcnkgYWxsb2NhdGlvbiBvZiBkb20wCj4K
PiDCoCDCoFJlcG9ydGVkLWJ5OiBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5ib29t
Lml0Pgo+IMKgIMKgU3VnZ2VzdGVkLWJ5OiDCoEtheSBTaWV2ZXJzIDxrYXkuc2lldmVyc0B2cmZ5
Lm9yZz4KPiDCoCDCoFNpZ25lZC1vZmYtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFk
LndpbGtAb3JhY2xlLmNvbT4KClN1cmUsIGxvb2tzIGdvb2QuCgpUaGFua3MgZm9yIGZpeGluZyB0
aGlzLApLYXkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:59:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:59:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNzM-000449-P8; Thu, 12 Jan 2012 16:58:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kay.sievers@vrfy.org>) id 1RlNzL-00043n-KT
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:58:55 +0000
X-Env-Sender: kay.sievers@vrfy.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326387512!62202953!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 28256 invoked from network); 12 Jan 2012 16:58:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:58:34 -0000
Received: by daec6 with SMTP id c6so10762646dae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrfy.org; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=KDiPMHrNwkxRlNwidaWfkECk5V+cwmegdF1x5t892lQ=;
	b=X3iIyjv41+xpmf6iMwKZWewvFDk5uPQyJIT0cDg3ATq4PBbKLJW34UgbD6vteXMsJ0
	k3RoonfWc2XddunOgyuFiITJMhluUwFQR40XqclVepB4V0EBd3uejwOjYeOWPQgYo+PZ
	qQVmYLN8E1vNJ9uY9Bu4DSCTl0t19jYzo7hbw=
Received: by 10.68.211.198 with SMTP id ne6mr9664232pbc.83.1326387532163; Thu,
	12 Jan 2012 08:58:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.34.14 with HTTP; Thu, 12 Jan 2012 08:58:31 -0800 (PST)
In-Reply-To: <20120112164025.GA22773@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
	<20120112164025.GA22773@phenom.dumpdata.com>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu, 12 Jan 2012 17:58:31 +0100
Message-ID: <CAPXgP12zOtbzVVqjzt8S8uX6OrVWgbuveyzX3uxirjtgW0xq-g@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBKYW4gMTIsIDIwMTIgYXQgMTc6NDAsIEtvbnJhZCBSemVzenV0ZWsgV2lsawo8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4gT24gVGh1LCBKYW4gMTIsIDIwMTIgYXQgMTE6
MTI6MDRBTSAtMDUwMCwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrIHdyb3RlOgo+PiBPbiBUaHUsIEph
biAxMiwgMjAxMiBhdCAwNTowNTozNFBNICswMTAwLCBLYXkgU2lldmVycyB3cm90ZToKPj4gPiBP
biBUaHUsIEphbiAxMiwgMjAxMiBhdCAxNjo0NiwgS29ucmFkIFJ6ZXN6dXRlayBXaWxrCj4+ID4g
PGtvbnJhZC53aWxrQG9yYWNsZS5jb20+IHdyb3RlOgo+PiA+ID4gT24gVGh1LCBKYW4gMTIsIDIw
MTIgYXQgMDE6Mzg6MzJQTSArMDEwMCwgU2FuZGVyIEVpa2VsZW5ib29tIHdyb3RlOgo+PiA+Cj4+
ID4gPj4gVG9kYXkgaSB0cmllZCBsaW51c2VzIHRyZWUgb2YgdG9kYXkgKGxhc3QgY29tbWl0IGlz
IDRjNGQyODVhZDU2NjViZmJkOTgzYjk1ZmRlOGQ3YTQ3N2QyNGEzNjEpLgo+PiA+ID4+Cj4+ID4g
Pj4gSXQgYm9vdHMgZG9tMCBmaW5lLCBidXQgaXQgZmFpbHMgdG8gc3RhcnQgYW55IGRvbVUgd2l0
aDogIkVycm9yOiBGYWlsZWQgdG8gcXVlcnkgY3VycmVudCBtZW1vcnkgYWxsb2NhdGlvbiBvZiBk
b20wLiIKPj4gPiA+PiBXaXRoIG15IHByZXZpb3VzIDMuMS41IGtlcm5lbCBldmVyeXRoaW5nIGlz
IGZpbmUsIG5vdGhpbmcgZWxzZSBjaGFuZ2VkIGluIGNvbmZpZyBpbiBiZXR3ZWVuLgo+PiA+ID4g
WW91ciBwYXRjaCB0aGF0IGNvbnZlcnRzIHRoZSB4ZW4tYmFsbG9vbiB0byB1c2UgdGhlIHJlZ3Vs
YXIgZGV2aWNlIGJ1cyBkcml2ZXIKPj4gPiA+ICgwNzA2ODAyMTgzNzllMTVjMTkwMWY0YmYyMWI5
OGUzY2JmMTJiNTI3KSBoYXMgc29tZSBub3Qtc28taGFwcHkgY29uc2VxdWVuY2VzLgo+PiA+ID4K
Pj4gPiA+IFRoZSB0b29sc3RhY2sgKHhlbi10b29scykgdXNlOgo+PiA+ID4KPj4gPiA+IC9zeXMv
ZGV2aWNlcy9zeXN0ZW0veGVuX21lbW9yeS94ZW5fbWVtb3J5MAo+PiA+ID4KPj4gPiA+IEJ1dCB3
aXRoIHRoZSBjaGFuZ2UsIGl0IGlzIG5vdzoKPj4gPiA+Cj4+ID4gPiAvc3lzL2RldmljZXMveGVu
X21lbW9yeTAvdGFyZ2V0X2tiCj4+ID4KPj4gPiBVcmtzLCBzZWVtcyBsaWtlIGEgbWlzdGFrZSBv
biBteSBzaWRlLgo+PiA+Cj4+ID4gUGxlYXNlIHRyeSBpZiBjaGFuZ2luZzoKPj4gPiDCoCBidXNf
dW5yZWdpc3RlcigmYmFsbG9vbl9zdWJzeXMpOwo+PiA+IHRvOgo+PiA+IMKgIHN1YnN5c19zeXN0
ZW1fcmVnaXN0ZXIoJmJhbGxvb25fc3Vic3lzLCBOVUxMKTsKPj4gPiBpbjoKPj4gPiDCoCBkcml2
ZXJzL3hlbi94ZW4tYmFsbG9vbi5jCj4+ID4gZml4ZXMgdGhlIGlzc3VlLgo+Pgo+PiBIZWguIEkg
d2FzICpqdXN0KiBsb29raW5nIGF0IGQzNjlhNWQ4ZmM3MDcxMDIzNmFlMmQwNmEwZTQyZGNlNDgz
NzEyZGYKPj4gKCJjbG9ja3NvdXJjZTogY29udmVydCBzeXNkZXZfY2xhc3MgdG8gYSByZWd1bGFy
IHN1YnN5c3RlbSIpIGFuZCB0eXBlZCB1cCB0aGlzIHBhdGNoCj4+IHRvIHRyeSBpdCBvdXQ6Cj4K
PiBLYXksIGFyZSB5b3UgQWNraW5nIHRoaXMgcGF0Y2g/IChJIGNhbiBzZW5kIGl0IHRvIExpbnVz
IGZvciByYzAgb3IgcmMxKQo+Cj4gY29tbWl0IDRlNmYxNjE5ODY2NzhhMjVjOWU3NmFmOThkZjky
ODQwOGM3MzRhMjcKPiBBdXRob3I6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtA
b3JhY2xlLmNvbT4KPiBEYXRlOiDCoCBUaHUgSmFuIDEyIDExOjM1OjUwIDIwMTIgLTA1MDAKPgo+
IMKgIMKgeGVuL2JhbGxvb246IE1vdmUgdGhlIHJlZ2lzdHJhdGlvbiBmcm9tIGRldmljZSB0byBz
dWJzeXN0ZW0uCj4KPiDCoCDCoFdpdGggZ2l0IGNvbW1pdCAwNzA2ODAyMTgzNzllMTVjMTkwMWY0
YmYyMWI5OGUzY2JmMTJiNTI3Cj4gwqAgwqAieGVuLWJhbGxvb246IGNvbnZlcnQgc3lzZGV2X2Ns
YXNzIHRvIGEgcmVndWxhciBzdWJzeXN0ZW0iIHdlIHdvdWxkCj4gwqAgwqBlbmQgdXAgd2l0aCB0
aGUgYXR0cmlidXRlcyBiZWluZyBwdXQgaW46Cj4KPiDCoCDCoCAvc3lzL2RldmljZXMveGVuX21l
bW9yeTAvdGFyZ2V0X2tiCj4gwqAgwqBpbnN0ZWFkIG9mCj4gwqAgwqAvc3lzL2RldmljZXMvc3lz
dGVtL3hlbl9tZW1vcnkveGVuX21lbW9yeTAvdGFyZ2V0X2tiCj4KPiDCoCDCoE1ha2luZyB0aGUg
dG9vbHMgdW5hYmxlIHRvIGRlZmxhdGUgdGhlIGtlcm5lbCB0byBtYWtlIG1vcmUgc3BhY2UKPiDC
oCDCoGZvciBsYXVuY2hpbmcgYW5vdGhlciBndWVzdCBhbmQgcHJpbnRpbmc6Cj4KPiDCoCDCoEVy
cm9yOiBGYWlsZWQgdG8gcXVlcnkgY3VycmVudCBtZW1vcnkgYWxsb2NhdGlvbiBvZiBkb20wCj4K
PiDCoCDCoFJlcG9ydGVkLWJ5OiBTYW5kZXIgRWlrZWxlbmJvb20gPGxpbnV4QGVpa2VsZW5ib29t
Lml0Pgo+IMKgIMKgU3VnZ2VzdGVkLWJ5OiDCoEtheSBTaWV2ZXJzIDxrYXkuc2lldmVyc0B2cmZ5
Lm9yZz4KPiDCoCDCoFNpZ25lZC1vZmYtYnk6IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFk
LndpbGtAb3JhY2xlLmNvbT4KClN1cmUsIGxvb2tzIGdvb2QuCgpUaGFua3MgZm9yIGZpeGluZyB0
aGlzLApLYXkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:59:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNzK-00043T-7p; Thu, 12 Jan 2012 16:58: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 1RlNzI-000432-BB
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:58:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326387525!2207593!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 27948 invoked from network); 12 Jan 2012 16:58:45 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:58:45 -0000
Received: by wibhj8 with SMTP id hj8so1146957wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08: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=4ppMauJHhAVxGQEC66Zeb7CGSg1EiIhFDcMaucosBuo=;
	b=V53lI/aaceBoV+fhJydlPZxijRgE5/t6pRlw4seMNpZ10vwAhFFbGFH7vM8t0q0c8U
	CCkBEHQAypJ5RawcUQavaSKuiTErQ0zN0DUiItfAfI/W6Q1Ihsb9BFW3xHFNj0jYqHpV
	+06GDdNCJV2cwBdP51uXpJV3CGpUM5r0UwOKo=
Received: by 10.180.94.102 with SMTP id db6mr2485964wib.0.1326387525250;
	Thu, 12 Jan 2012 08:58:45 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id y5sm896853wiw.3.2012.01.12.08.58.43
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 08:58:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 16:58:42 +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: <CB34C1C2.374D8%keir@xen.org>
Thread-Topic: [PATCH 2/2] remove inclusion of asm/config.h
Thread-Index: AczRS3AT/FDW5L2OU0Sbo9Br/JEUJA==
In-Reply-To: <4F0F1B1A020000780006C2EB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 2/2] remove inclusion of asm/config.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 12/01/2012 16:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> This was always bogus (xen/config.h should have been used instead) and
> is superfluous now that xen/config.h gets included through the compiler
> command line.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/vmx/optvfault.S
> +++ b/xen/arch/ia64/vmx/optvfault.S
> @@ -6,8 +6,6 @@
>   * Xuefei Xu (Anthony Xu) <anthony.xu@intel.com>
>   */
>  
> -#include <linux/config.h>
> -#include <asm/config.h>
>  #include <asm/pgtable.h>
>  #include <asm/asmmacro.h>
>  #include <asm/kregs.h>
> --- a/xen/arch/ia64/xen/cpufreq/cpufreq.c
> +++ b/xen/arch/ia64/xen/cpufreq/cpufreq.c
> @@ -21,7 +21,6 @@
>  #include <xen/xmalloc.h>
>  #include <asm/bug.h>
>  #include <asm/io.h>
> -#include <asm/config.h>
>  #include <asm/processor.h>
>  #include <asm/percpu.h>
>  #include <asm/pal.h>
> --- a/xen/arch/ia64/xen/ivt.S
> +++ b/xen/arch/ia64/xen/ivt.S
> @@ -1,7 +1,6 @@
>  #include <asm/debugger.h>
>  #include <asm/vhpt.h>
>  #include <public/arch-ia64.h>
> -#include <asm/config.h>
>  /*
>   * arch/ia64/kernel/ivt.S
>   *
> @@ -43,8 +42,6 @@
>   * Table is based upon EAS2.6 (Oct 1999)
>   */
>  
> -#include <linux/config.h>
> -
>  #include <asm/asmmacro.h>
>  #include <asm/break.h>
>  #include <asm/ia32.h>
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -38,7 +38,6 @@
>  #include <asm/bug.h>
>  #include <asm/msr.h>
>  #include <asm/io.h>
> -#include <asm/config.h>
>  #include <asm/processor.h>
>  #include <asm/percpu.h>
>  #include <asm/cpufeature.h>
> --- a/xen/arch/x86/acpi/cpufreq/powernow.c
> +++ b/xen/arch/x86/acpi/cpufreq/powernow.c
> @@ -32,7 +32,6 @@
>  #include <asm/bug.h>
>  #include <asm/msr.h>
>  #include <asm/io.h>
> -#include <asm/config.h>
>  #include <asm/processor.h>
>  #include <asm/percpu.h>
>  #include <asm/cpufeature.h>
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -41,7 +41,6 @@
>  #include <xen/cpu.h>
>  #include <asm/bug.h>
>  #include <asm/io.h>
> -#include <asm/config.h>
>  #include <asm/processor.h>
>  #include <asm/percpu.h>
>  #include <acpi/acpi.h>
> --- a/xen/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
> @@ -18,7 +18,6 @@
>  #include <xen/types.h>
>  #include <xen/sched.h>
>  #include <xen/timer.h>
> -#include <asm/config.h>
>  #include <acpi/cpufreq/cpufreq.h>
>  
>  #define DEF_FREQUENCY_UP_THRESHOLD              (80)
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -28,7 +28,6 @@
>  #include <xen/sched.h>
>  #include <xen/timer.h>
>  #include <xen/trace.h>
> -#include <asm/config.h>
>  #include <acpi/cpufreq/cpufreq.h>
>  #include <public/sysctl.h>
>  
> --- a/xen/include/asm-ia64/linux-xen/asm/perfmon.h
> +++ b/xen/include/asm-ia64/linux-xen/asm/perfmon.h
> @@ -7,7 +7,6 @@
>  #define _ASM_IA64_PERFMON_H
>  
>  #ifdef XEN
> -#include <asm/config.h>
>  #ifndef pt_regs
>  #define pt_regs cpu_user_regs
>  #endif
> --- a/xen/include/asm-ia64/privop_stat.h
> +++ b/xen/include/asm-ia64/privop_stat.h
> @@ -1,6 +1,6 @@
>  #ifndef _XEN_IA64_PRIVOP_STAT_H
>  #define _XEN_IA64_PRIVOP_STAT_H
> -#include <asm/config.h>
> +
>  #include <xen/types.h>
>  #include <public/xen.h>
>  
> --- a/xen/include/asm-ia64/xensystem.h
> +++ b/xen/include/asm-ia64/xensystem.h
> @@ -10,7 +10,6 @@
>   *  Kun Tian (Kevin Tian) <kevin.tian@intel.com>
>   *
>   */
> -#include <asm/config.h>
>  
>  /* Define HV space hierarchy.
>     VMM memory space is protected by CPL for paravirtualized domains and
> --- a/xen/include/asm-x86/hvm/svm/nestedsvm.h
> +++ b/xen/include/asm-x86/hvm/svm/nestedsvm.h
> @@ -19,7 +19,6 @@
>  #ifndef __ASM_X86_HVM_SVM_NESTEDSVM_H__
>  #define __ASM_X86_HVM_SVM_NESTEDSVM_H__
>  
> -#include <asm/config.h>
>  #include <asm/hvm/hvm.h>
>  #include <asm/hvm/svm/vmcb.h>
>  
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -19,7 +19,6 @@
>  #ifndef __ASM_X86_HVM_VMX_VMCS_H__
>  #define __ASM_X86_HVM_VMX_VMCS_H__
>  
> -#include <asm/config.h>
>  #include <asm/hvm/io.h>
>  #include <asm/hvm/vpmu.h>
>  
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 16:59:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 16:59:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlNzK-00043T-7p; Thu, 12 Jan 2012 16:58: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 1RlNzI-000432-BB
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 16:58:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326387525!2207593!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 27948 invoked from network); 12 Jan 2012 16:58:45 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 16:58:45 -0000
Received: by wibhj8 with SMTP id hj8so1146957wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 08: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=4ppMauJHhAVxGQEC66Zeb7CGSg1EiIhFDcMaucosBuo=;
	b=V53lI/aaceBoV+fhJydlPZxijRgE5/t6pRlw4seMNpZ10vwAhFFbGFH7vM8t0q0c8U
	CCkBEHQAypJ5RawcUQavaSKuiTErQ0zN0DUiItfAfI/W6Q1Ihsb9BFW3xHFNj0jYqHpV
	+06GDdNCJV2cwBdP51uXpJV3CGpUM5r0UwOKo=
Received: by 10.180.94.102 with SMTP id db6mr2485964wib.0.1326387525250;
	Thu, 12 Jan 2012 08:58:45 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-41.range86-153.btcentralplus.com.
	[86.153.23.41])
	by mx.google.com with ESMTPS id y5sm896853wiw.3.2012.01.12.08.58.43
	(version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 08:58:44 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 12 Jan 2012 16:58:42 +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: <CB34C1C2.374D8%keir@xen.org>
Thread-Topic: [PATCH 2/2] remove inclusion of asm/config.h
Thread-Index: AczRS3AT/FDW5L2OU0Sbo9Br/JEUJA==
In-Reply-To: <4F0F1B1A020000780006C2EB@nat28.tlf.novell.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH 2/2] remove inclusion of asm/config.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 12/01/2012 16:40, "Jan Beulich" <JBeulich@suse.com> wrote:

> This was always bogus (xen/config.h should have been used instead) and
> is superfluous now that xen/config.h gets included through the compiler
> command line.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/arch/ia64/vmx/optvfault.S
> +++ b/xen/arch/ia64/vmx/optvfault.S
> @@ -6,8 +6,6 @@
>   * Xuefei Xu (Anthony Xu) <anthony.xu@intel.com>
>   */
>  
> -#include <linux/config.h>
> -#include <asm/config.h>
>  #include <asm/pgtable.h>
>  #include <asm/asmmacro.h>
>  #include <asm/kregs.h>
> --- a/xen/arch/ia64/xen/cpufreq/cpufreq.c
> +++ b/xen/arch/ia64/xen/cpufreq/cpufreq.c
> @@ -21,7 +21,6 @@
>  #include <xen/xmalloc.h>
>  #include <asm/bug.h>
>  #include <asm/io.h>
> -#include <asm/config.h>
>  #include <asm/processor.h>
>  #include <asm/percpu.h>
>  #include <asm/pal.h>
> --- a/xen/arch/ia64/xen/ivt.S
> +++ b/xen/arch/ia64/xen/ivt.S
> @@ -1,7 +1,6 @@
>  #include <asm/debugger.h>
>  #include <asm/vhpt.h>
>  #include <public/arch-ia64.h>
> -#include <asm/config.h>
>  /*
>   * arch/ia64/kernel/ivt.S
>   *
> @@ -43,8 +42,6 @@
>   * Table is based upon EAS2.6 (Oct 1999)
>   */
>  
> -#include <linux/config.h>
> -
>  #include <asm/asmmacro.h>
>  #include <asm/break.h>
>  #include <asm/ia32.h>
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -38,7 +38,6 @@
>  #include <asm/bug.h>
>  #include <asm/msr.h>
>  #include <asm/io.h>
> -#include <asm/config.h>
>  #include <asm/processor.h>
>  #include <asm/percpu.h>
>  #include <asm/cpufeature.h>
> --- a/xen/arch/x86/acpi/cpufreq/powernow.c
> +++ b/xen/arch/x86/acpi/cpufreq/powernow.c
> @@ -32,7 +32,6 @@
>  #include <asm/bug.h>
>  #include <asm/msr.h>
>  #include <asm/io.h>
> -#include <asm/config.h>
>  #include <asm/processor.h>
>  #include <asm/percpu.h>
>  #include <asm/cpufeature.h>
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -41,7 +41,6 @@
>  #include <xen/cpu.h>
>  #include <asm/bug.h>
>  #include <asm/io.h>
> -#include <asm/config.h>
>  #include <asm/processor.h>
>  #include <asm/percpu.h>
>  #include <acpi/acpi.h>
> --- a/xen/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
> @@ -18,7 +18,6 @@
>  #include <xen/types.h>
>  #include <xen/sched.h>
>  #include <xen/timer.h>
> -#include <asm/config.h>
>  #include <acpi/cpufreq/cpufreq.h>
>  
>  #define DEF_FREQUENCY_UP_THRESHOLD              (80)
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -28,7 +28,6 @@
>  #include <xen/sched.h>
>  #include <xen/timer.h>
>  #include <xen/trace.h>
> -#include <asm/config.h>
>  #include <acpi/cpufreq/cpufreq.h>
>  #include <public/sysctl.h>
>  
> --- a/xen/include/asm-ia64/linux-xen/asm/perfmon.h
> +++ b/xen/include/asm-ia64/linux-xen/asm/perfmon.h
> @@ -7,7 +7,6 @@
>  #define _ASM_IA64_PERFMON_H
>  
>  #ifdef XEN
> -#include <asm/config.h>
>  #ifndef pt_regs
>  #define pt_regs cpu_user_regs
>  #endif
> --- a/xen/include/asm-ia64/privop_stat.h
> +++ b/xen/include/asm-ia64/privop_stat.h
> @@ -1,6 +1,6 @@
>  #ifndef _XEN_IA64_PRIVOP_STAT_H
>  #define _XEN_IA64_PRIVOP_STAT_H
> -#include <asm/config.h>
> +
>  #include <xen/types.h>
>  #include <public/xen.h>
>  
> --- a/xen/include/asm-ia64/xensystem.h
> +++ b/xen/include/asm-ia64/xensystem.h
> @@ -10,7 +10,6 @@
>   *  Kun Tian (Kevin Tian) <kevin.tian@intel.com>
>   *
>   */
> -#include <asm/config.h>
>  
>  /* Define HV space hierarchy.
>     VMM memory space is protected by CPL for paravirtualized domains and
> --- a/xen/include/asm-x86/hvm/svm/nestedsvm.h
> +++ b/xen/include/asm-x86/hvm/svm/nestedsvm.h
> @@ -19,7 +19,6 @@
>  #ifndef __ASM_X86_HVM_SVM_NESTEDSVM_H__
>  #define __ASM_X86_HVM_SVM_NESTEDSVM_H__
>  
> -#include <asm/config.h>
>  #include <asm/hvm/hvm.h>
>  #include <asm/hvm/svm/vmcb.h>
>  
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -19,7 +19,6 @@
>  #ifndef __ASM_X86_HVM_VMX_VMCS_H__
>  #define __ASM_X86_HVM_VMX_VMCS_H__
>  
> -#include <asm/config.h>
>  #include <asm/hvm/io.h>
>  #include <asm/hvm/vpmu.h>
>  
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:02:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlO2K-0004Ps-Ew; Thu, 12 Jan 2012 17:02:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>)
	id 1RlO2I-0004PL-M9; Thu, 12 Jan 2012 17:01:58 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326387711!8017010!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTAyMTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28235 invoked from network); 12 Jan 2012 17:01:52 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 17:01:52 -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 q0CH1B0J016407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 12:01:11 -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 q0CH17V3027178; Thu, 12 Jan 2012 12:01:08 -0500
Message-ID: <4F0F1236.6010705@redhat.com>
Date: Thu, 12 Jan 2012 18:02:46 +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: Ian Campbell <Ian.Campbell@citrix.com>
References: <20120109213039.GC4773@phenom.dumpdata.com>	<6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
	<1326148662.29084.77.camel@dagon.hellion.org.uk>
In-Reply-To: <1326148662.29084.77.camel@dagon.hellion.org.uk>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/09/12 23:37, Ian Campbell wrote:
> On Mon, 2012-01-09 at 22:26 +0000, James Harper wrote:
>>>   - Initial work laid out for netback page-flipping (also called zero-copying).
>>
>> Isn't this how it used to work originally?
>
> Some of the original infrastructure for doing this was not upstreamable
> (the PageForeign stuff) so while upstream netback I decided to go with a
> simpler/less-intrusive copying mode so we could have some sort of
> networking support in mainline.
>
> I've been working on re-laying the necessary infrastructure to allow for
> page flipping/mapping mode in upstream (as well as fixing another
> generic class of bug) -- you can see the "skb frag destructor" patches
> on the netdev list.

(Ultimately I found it here:

     http://lwn.net/Articles/474791/

.)

Ian, do you think the NFS fix in

     http://article.gmane.org/gmane.linux.nfs/45955

for problem

     http://marc.info/?l=linux-nfs&m=122424132729720&w=2

would be technically feasible to port to 2.6.18, based on the existing 
PageForeign stuff instead of parts 1-5 of the series?

Thanks
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:02:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlO2K-0004Ps-Ew; Thu, 12 Jan 2012 17:02:00 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>)
	id 1RlO2I-0004PL-M9; Thu, 12 Jan 2012 17:01:58 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326387711!8017010!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTAyMTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28235 invoked from network); 12 Jan 2012 17:01:52 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 17:01:52 -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 q0CH1B0J016407
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 12:01:11 -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 q0CH17V3027178; Thu, 12 Jan 2012 12:01:08 -0500
Message-ID: <4F0F1236.6010705@redhat.com>
Date: Thu, 12 Jan 2012 18:02:46 +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: Ian Campbell <Ian.Campbell@citrix.com>
References: <20120109213039.GC4773@phenom.dumpdata.com>	<6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
	<1326148662.29084.77.camel@dagon.hellion.org.uk>
In-Reply-To: <1326148662.29084.77.camel@dagon.hellion.org.uk>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/09/12 23:37, Ian Campbell wrote:
> On Mon, 2012-01-09 at 22:26 +0000, James Harper wrote:
>>>   - Initial work laid out for netback page-flipping (also called zero-copying).
>>
>> Isn't this how it used to work originally?
>
> Some of the original infrastructure for doing this was not upstreamable
> (the PageForeign stuff) so while upstream netback I decided to go with a
> simpler/less-intrusive copying mode so we could have some sort of
> networking support in mainline.
>
> I've been working on re-laying the necessary infrastructure to allow for
> page flipping/mapping mode in upstream (as well as fixing another
> generic class of bug) -- you can see the "skb frag destructor" patches
> on the netdev list.

(Ultimately I found it here:

     http://lwn.net/Articles/474791/

.)

Ian, do you think the NFS fix in

     http://article.gmane.org/gmane.linux.nfs/45955

for problem

     http://marc.info/?l=linux-nfs&m=122424132729720&w=2

would be technically feasible to port to 2.6.18, based on the existing 
PageForeign stuff instead of parts 1-5 of the series?

Thanks
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:06:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:06:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlO6A-0004hu-AI; Thu, 12 Jan 2012 17:05:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RlO68-0004hh-Sg
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:05:57 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326387950!10686969!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 25706 invoked from network); 12 Jan 2012 17:05:50 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jan 2012 17:05:50 -0000
Received: from 25-72-ftth.onsneteindhoven.nl ([88.159.72.25]:56191
	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 1RlO3m-0001Pr-Bt; Thu, 12 Jan 2012 18:03:30 +0100
Date: Thu, 12 Jan 2012 18:05:46 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <256392989.20120112180546@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120112164025.GA22773@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
	<20120112164025.GA22773@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Kay Sievers <kay.sievers@vrfy.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
	Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello Konrad,

Thursday, January 12, 2012, 5:40:25 PM, you wrote:

> On Thu, Jan 12, 2012 at 11:12:04AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jan 12, 2012 at 05:05:34PM +0100, Kay Sievers wrote:
>> > On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
>> > <konrad.wilk@oracle.com> wrote:
>> > > On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
>> > 
>> > >> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
>> > >>
>> > >> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
>> > >> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
>> > > Your patch that converts the xen-balloon to use the regular device bus driver
>> > > (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
>> > >
>> > > The toolstack (xen-tools) use:
>> > >
>> > > /sys/devices/system/xen_memory/xen_memory0
>> > >
>> > > But with the change, it is now:
>> > >
>> > > /sys/devices/xen_memory0/target_kb
>> > 
>> > Urks, seems like a mistake on my side.
>> > 
>> > Please try if changing:
>> >   bus_unregister(&balloon_subsys);
>> > to:
>> >   subsys_system_register(&balloon_subsys, NULL);
>> > in:
>> >   drivers/xen/xen-balloon.c
>> > fixes the issue.
>> 
>> Heh. I was *just* looking at d369a5d8fc70710236ae2d06a0e42dce483712df
>> ("clocksource: convert sysdev_class to a regular subsystem") and typed up this patch
>> to try it out:

> Kay, are you Acking this patch? (I can send it to Linus for rc0 or rc1)

> commit 4e6f161986678a25c9e76af98df928408c734a27
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Thu Jan 12 11:35:50 2012 -0500

>     xen/balloon: Move the registration from device to subsystem.
>     
>     With git commit 070680218379e15c1901f4bf21b98e3cbf12b527
>     "xen-balloon: convert sysdev_class to a regular subsystem" we would
>     end up with the attributes being put in:
>     
>      /sys/devices/xen_memory0/target_kb
>     instead of
>     /sys/devices/system/xen_memory/xen_memory0/target_kb
>     
>     Making the tools unable to deflate the kernel to make more space
>     for launching another guest and printing:

>     Error: Failed to query current memory allocation of dom0
>     
>     Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
>     Suggested-by:  Kay Sievers <kay.sievers@vrfy.org>
>     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
> index 3832e30..596e6a7 100644
> --- a/drivers/xen/xen-balloon.c
> +++ b/drivers/xen/xen-balloon.c
> @@ -221,7 +221,7 @@ static int register_balloon(struct device *dev)
>  {
>         int i, error;
>  
> -       error = bus_register(&balloon_subsys);
> +       error = subsys_system_register(&balloon_subsys, NULL);
>         if (error)
>                 return error;
>  


Shouldn't the

if (error) {
        bus_unregister(&balloon_subsys);
        return error;
}

right below it also be changed ?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:06:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:06:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlO6A-0004hu-AI; Thu, 12 Jan 2012 17:05:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RlO68-0004hh-Sg
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:05:57 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326387950!10686969!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 25706 invoked from network); 12 Jan 2012 17:05:50 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-5.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jan 2012 17:05:50 -0000
Received: from 25-72-ftth.onsneteindhoven.nl ([88.159.72.25]:56191
	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 1RlO3m-0001Pr-Bt; Thu, 12 Jan 2012 18:03:30 +0100
Date: Thu, 12 Jan 2012 18:05:46 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <256392989.20120112180546@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120112164025.GA22773@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
	<20120112164025.GA22773@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Kay Sievers <kay.sievers@vrfy.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
	Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello Konrad,

Thursday, January 12, 2012, 5:40:25 PM, you wrote:

> On Thu, Jan 12, 2012 at 11:12:04AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Jan 12, 2012 at 05:05:34PM +0100, Kay Sievers wrote:
>> > On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
>> > <konrad.wilk@oracle.com> wrote:
>> > > On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
>> > 
>> > >> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
>> > >>
>> > >> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
>> > >> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
>> > > Your patch that converts the xen-balloon to use the regular device bus driver
>> > > (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
>> > >
>> > > The toolstack (xen-tools) use:
>> > >
>> > > /sys/devices/system/xen_memory/xen_memory0
>> > >
>> > > But with the change, it is now:
>> > >
>> > > /sys/devices/xen_memory0/target_kb
>> > 
>> > Urks, seems like a mistake on my side.
>> > 
>> > Please try if changing:
>> >   bus_unregister(&balloon_subsys);
>> > to:
>> >   subsys_system_register(&balloon_subsys, NULL);
>> > in:
>> >   drivers/xen/xen-balloon.c
>> > fixes the issue.
>> 
>> Heh. I was *just* looking at d369a5d8fc70710236ae2d06a0e42dce483712df
>> ("clocksource: convert sysdev_class to a regular subsystem") and typed up this patch
>> to try it out:

> Kay, are you Acking this patch? (I can send it to Linus for rc0 or rc1)

> commit 4e6f161986678a25c9e76af98df928408c734a27
> Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date:   Thu Jan 12 11:35:50 2012 -0500

>     xen/balloon: Move the registration from device to subsystem.
>     
>     With git commit 070680218379e15c1901f4bf21b98e3cbf12b527
>     "xen-balloon: convert sysdev_class to a regular subsystem" we would
>     end up with the attributes being put in:
>     
>      /sys/devices/xen_memory0/target_kb
>     instead of
>     /sys/devices/system/xen_memory/xen_memory0/target_kb
>     
>     Making the tools unable to deflate the kernel to make more space
>     for launching another guest and printing:

>     Error: Failed to query current memory allocation of dom0
>     
>     Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
>     Suggested-by:  Kay Sievers <kay.sievers@vrfy.org>
>     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
> index 3832e30..596e6a7 100644
> --- a/drivers/xen/xen-balloon.c
> +++ b/drivers/xen/xen-balloon.c
> @@ -221,7 +221,7 @@ static int register_balloon(struct device *dev)
>  {
>         int i, error;
>  
> -       error = bus_register(&balloon_subsys);
> +       error = subsys_system_register(&balloon_subsys, NULL);
>         if (error)
>                 return error;
>  


Shouldn't the

if (error) {
        bus_unregister(&balloon_subsys);
        return error;
}

right below it also be changed ?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:09:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:09:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlO8z-0004ql-Ts; Thu, 12 Jan 2012 17:08:53 +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 1RlO8z-0004qb-7B
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:08:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326388125!10675688!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15510 invoked from network); 12 Jan 2012 17:08:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 17:08:46 -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
	q0CH8gG3019163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 17:08:43 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0CH8fhm009291
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 17:08:41 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CH8fFK013728; Thu, 12 Jan 2012 11:08:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 09:08:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1D5384030A; Thu, 12 Jan 2012 12:06:50 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Thu, 12 Jan 2012 12:06:47 -0500
Message-Id: <1326388007-19178-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
References: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F0F139C.011E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/pciback: Support pci_reset_function,
	aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We use the __pci_reset_function_locked to perform the action.
Also on attaching ("bind") and detaching ("unbind") we save and
restore the configuration states. When the device is disconnected
from a guest we use the "pci_reset_function" to also reset the
device before being passed to another guest.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
 drivers/xen/xen-pciback/pciback.h  |    1 +
 2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 7944a17..6f63b9d 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
 static void pcistub_device_release(struct kref *kref)
 {
 	struct pcistub_device *psdev;
+	struct xen_pcibk_dev_data *dev_data;
 
 	psdev = container_of(kref, struct pcistub_device, kref);
+	dev_data = pci_get_drvdata(psdev->dev);
 
 	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
 
 	xen_unregister_device_domain_owner(psdev->dev);
 
-	/* Clean-up the device */
+	/* Call the reset function which does not take lock as this
+	 * is called from "unbind" which takes a device_lock mutex.
+	 */
+	__pci_reset_function_locked(psdev->dev);
+	if (pci_load_and_free_saved_state(psdev->dev,
+					  &dev_data->pci_saved_state)) {
+		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
+	} else
+		pci_restore_state(psdev->dev);
+
+	/* Disable the device */
 	xen_pcibk_reset_device(psdev->dev);
+
+	kfree(dev_data);
+	pci_set_drvdata(psdev->dev, NULL);
+
+	/* Clean-up the device */
 	xen_pcibk_config_free_dyn_fields(psdev->dev);
 	xen_pcibk_config_free_dev(psdev->dev);
-	kfree(pci_get_drvdata(psdev->dev));
-	pci_set_drvdata(psdev->dev, NULL);
 
 	psdev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
 	pci_dev_put(psdev->dev);
@@ -231,7 +246,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
+
+	/* This is OK - we are running from workqueue context
+	 * and want to inhibit the user from fiddling with 'reset'
+	 */
+	pci_reset_function(dev);
+	pci_restore_state(psdev->dev);
+
+	/* This disables the device. */
 	xen_pcibk_reset_device(found_psdev->dev);
+
+	/* And cleanup up our emulated fields. */
 	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
 	xen_pcibk_config_reset_dev(found_psdev->dev);
 
@@ -328,6 +353,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	if (err)
 		goto config_release;
 
+	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
+	__pci_reset_function_locked(dev);
+
+	/* We need the device active to save the state. */
+	dev_dbg(&dev->dev, "save state of device\n");
+	pci_save_state(dev);
+	dev_data->pci_saved_state = pci_store_saved_state(dev);
+	if (!dev_data->pci_saved_state)
+		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
+
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
 	 */
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index e9b4011..a7def01 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -41,6 +41,7 @@ struct xen_pcibk_device {
 
 struct xen_pcibk_dev_data {
 	struct list_head config_fields;
+	struct pci_saved_state *pci_saved_state;
 	unsigned int permissive:1;
 	unsigned int warned_on_write:1;
 	unsigned int enable_intx:1;
-- 
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 Jan 12 17:09:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:09:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlO8z-0004ql-Ts; Thu, 12 Jan 2012 17:08:53 +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 1RlO8z-0004qb-7B
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:08:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326388125!10675688!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15510 invoked from network); 12 Jan 2012 17:08:46 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 17:08:46 -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
	q0CH8gG3019163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 17:08:43 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0CH8fhm009291
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 17:08:41 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CH8fFK013728; Thu, 12 Jan 2012 11:08:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 09:08:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1D5384030A; Thu, 12 Jan 2012 12:06:50 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Thu, 12 Jan 2012 12:06:47 -0500
Message-Id: <1326388007-19178-3-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
References: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090208.4F0F139C.011E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 2/2] xen/pciback: Support pci_reset_function,
	aka FLR or D3 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

We use the __pci_reset_function_locked to perform the action.
Also on attaching ("bind") and detaching ("unbind") we save and
restore the configuration states. When the device is disconnected
from a guest we use the "pci_reset_function" to also reset the
device before being passed to another guest.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
 drivers/xen/xen-pciback/pciback.h  |    1 +
 2 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c
index 7944a17..6f63b9d 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -85,19 +85,34 @@ static struct pcistub_device *pcistub_device_alloc(struct pci_dev *dev)
 static void pcistub_device_release(struct kref *kref)
 {
 	struct pcistub_device *psdev;
+	struct xen_pcibk_dev_data *dev_data;
 
 	psdev = container_of(kref, struct pcistub_device, kref);
+	dev_data = pci_get_drvdata(psdev->dev);
 
 	dev_dbg(&psdev->dev->dev, "pcistub_device_release\n");
 
 	xen_unregister_device_domain_owner(psdev->dev);
 
-	/* Clean-up the device */
+	/* Call the reset function which does not take lock as this
+	 * is called from "unbind" which takes a device_lock mutex.
+	 */
+	__pci_reset_function_locked(psdev->dev);
+	if (pci_load_and_free_saved_state(psdev->dev,
+					  &dev_data->pci_saved_state)) {
+		dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n");
+	} else
+		pci_restore_state(psdev->dev);
+
+	/* Disable the device */
 	xen_pcibk_reset_device(psdev->dev);
+
+	kfree(dev_data);
+	pci_set_drvdata(psdev->dev, NULL);
+
+	/* Clean-up the device */
 	xen_pcibk_config_free_dyn_fields(psdev->dev);
 	xen_pcibk_config_free_dev(psdev->dev);
-	kfree(pci_get_drvdata(psdev->dev));
-	pci_set_drvdata(psdev->dev, NULL);
 
 	psdev->dev->dev_flags &= ~PCI_DEV_FLAGS_ASSIGNED;
 	pci_dev_put(psdev->dev);
@@ -231,7 +246,17 @@ void pcistub_put_pci_dev(struct pci_dev *dev)
 	/* Cleanup our device
 	 * (so it's ready for the next domain)
 	 */
+
+	/* This is OK - we are running from workqueue context
+	 * and want to inhibit the user from fiddling with 'reset'
+	 */
+	pci_reset_function(dev);
+	pci_restore_state(psdev->dev);
+
+	/* This disables the device. */
 	xen_pcibk_reset_device(found_psdev->dev);
+
+	/* And cleanup up our emulated fields. */
 	xen_pcibk_config_free_dyn_fields(found_psdev->dev);
 	xen_pcibk_config_reset_dev(found_psdev->dev);
 
@@ -328,6 +353,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev)
 	if (err)
 		goto config_release;
 
+	dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
+	__pci_reset_function_locked(dev);
+
+	/* We need the device active to save the state. */
+	dev_dbg(&dev->dev, "save state of device\n");
+	pci_save_state(dev);
+	dev_data->pci_saved_state = pci_store_saved_state(dev);
+	if (!dev_data->pci_saved_state)
+		dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
+
 	/* Now disable the device (this also ensures some private device
 	 * data is setup before we export)
 	 */
diff --git a/drivers/xen/xen-pciback/pciback.h b/drivers/xen/xen-pciback/pciback.h
index e9b4011..a7def01 100644
--- a/drivers/xen/xen-pciback/pciback.h
+++ b/drivers/xen/xen-pciback/pciback.h
@@ -41,6 +41,7 @@ struct xen_pcibk_device {
 
 struct xen_pcibk_dev_data {
 	struct list_head config_fields;
+	struct pci_saved_state *pci_saved_state;
 	unsigned int permissive:1;
 	unsigned int warned_on_write:1;
 	unsigned int enable_intx:1;
-- 
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 Jan 12 17:09:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlO91-0004r1-B5; Thu, 12 Jan 2012 17:08:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RlO8z-0004qe-Pa
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:08:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326388071!60575605!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21025 invoked from network); 12 Jan 2012 17:07:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 17:07:53 -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
	q0CH8hkD019173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 17:08:44 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0CH8fmS009305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 17:08:42 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
	q0CH8fkq028324; Thu, 12 Jan 2012 11:08:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 09:08:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1344340309; Thu, 12 Jan 2012 12:06:50 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Thu, 12 Jan 2012 12:06:46 -0500
Message-Id: <1326388007-19178-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
References: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F0F139D.0066,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] pci: Introduce __pci_reset_function_locked
	to be used when holding device_lock.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 use case of this is when a driver wants to call FLR when a device
is attached to it using the SysFS "bind" or "unbind" functionality.

The call chain when a user does "bind" looks as so:

 echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind

and ends up calling:
  driver_bind:
    device_lock(dev);  <=== TAKES LOCK
    XXXX_probe:
         .. pci_enable_device()
         ...__pci_reset_function(), which calls
                 pci_dev_reset(dev, 0):
                        if (!0) {
                                device_lock(dev) <==== DEADLOCK

The __pci_reset_function_locked function allows the the drivers
'probe' function to call the "pci_reset_function" while still holding
the driver mutex lock.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/pci.c   |   25 +++++++++++++++++++++++++
 include/linux/pci.h |    1 +
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 97fff78..192be5d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3163,6 +3163,31 @@ int __pci_reset_function(struct pci_dev *dev)
 EXPORT_SYMBOL_GPL(__pci_reset_function);
 
 /**
+ * __pci_reset_function_locked - reset a PCI device function while holding
+ * the @dev mutex lock.
+ * @dev: PCI device to reset
+ *
+ * Some devices allow an individual function to be reset without affecting
+ * other functions in the same device.  The PCI device must be responsive
+ * to PCI config space in order to use this function.
+ *
+ * The device function is presumed to be unused and the caller is holding
+ * the device mutex lock when this function is called.
+ * Resetting the device will make the contents of PCI configuration space
+ * random, so any caller of this must be prepared to reinitialise the
+ * device including MSI, bus mastering, BARs, decoding IO and memory spaces,
+ * etc.
+ *
+ * Returns 0 if the device function was successfully reset or negative if the
+ * device doesn't support resetting a single function.
+ */
+int __pci_reset_function_locked(struct pci_dev *dev)
+{
+	return pci_dev_reset(dev, 1);
+}
+EXPORT_SYMBOL_GPL(__pci_reset_function_locked);
+
+/**
  * pci_probe_reset_function - check whether the device can be safely reset
  * @dev: PCI device to reset
  *
diff --git a/include/linux/pci.h b/include/linux/pci.h
index a16b1df..65c2d8a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -817,6 +817,7 @@ int pcie_set_readrq(struct pci_dev *dev, int rq);
 int pcie_get_mps(struct pci_dev *dev);
 int pcie_set_mps(struct pci_dev *dev, int mps);
 int __pci_reset_function(struct pci_dev *dev);
+int __pci_reset_function_locked(struct pci_dev *dev);
 int pci_reset_function(struct pci_dev *dev);
 void pci_update_resource(struct pci_dev *dev, int resno);
 int __must_check pci_assign_resource(struct pci_dev *dev, int i);
-- 
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 Jan 12 17:09:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:09:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlO91-0004r1-B5; Thu, 12 Jan 2012 17:08:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RlO8z-0004qe-Pa
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:08:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326388071!60575605!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg0NzM0\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21025 invoked from network); 12 Jan 2012 17:07:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 17:07:53 -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
	q0CH8hkD019173
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 17:08:44 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0CH8fmS009305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 17:08:42 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
	q0CH8fkq028324; Thu, 12 Jan 2012 11:08:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 09:08:41 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1344340309; Thu, 12 Jan 2012 12:06:50 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Thu, 12 Jan 2012 12:06:46 -0500
Message-Id: <1326388007-19178-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
In-Reply-To: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
References: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F0F139D.0066,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 1/2] pci: Introduce __pci_reset_function_locked
	to be used when holding device_lock.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 use case of this is when a driver wants to call FLR when a device
is attached to it using the SysFS "bind" or "unbind" functionality.

The call chain when a user does "bind" looks as so:

 echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind

and ends up calling:
  driver_bind:
    device_lock(dev);  <=== TAKES LOCK
    XXXX_probe:
         .. pci_enable_device()
         ...__pci_reset_function(), which calls
                 pci_dev_reset(dev, 0):
                        if (!0) {
                                device_lock(dev) <==== DEADLOCK

The __pci_reset_function_locked function allows the the drivers
'probe' function to call the "pci_reset_function" while still holding
the driver mutex lock.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/pci/pci.c   |   25 +++++++++++++++++++++++++
 include/linux/pci.h |    1 +
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 97fff78..192be5d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3163,6 +3163,31 @@ int __pci_reset_function(struct pci_dev *dev)
 EXPORT_SYMBOL_GPL(__pci_reset_function);
 
 /**
+ * __pci_reset_function_locked - reset a PCI device function while holding
+ * the @dev mutex lock.
+ * @dev: PCI device to reset
+ *
+ * Some devices allow an individual function to be reset without affecting
+ * other functions in the same device.  The PCI device must be responsive
+ * to PCI config space in order to use this function.
+ *
+ * The device function is presumed to be unused and the caller is holding
+ * the device mutex lock when this function is called.
+ * Resetting the device will make the contents of PCI configuration space
+ * random, so any caller of this must be prepared to reinitialise the
+ * device including MSI, bus mastering, BARs, decoding IO and memory spaces,
+ * etc.
+ *
+ * Returns 0 if the device function was successfully reset or negative if the
+ * device doesn't support resetting a single function.
+ */
+int __pci_reset_function_locked(struct pci_dev *dev)
+{
+	return pci_dev_reset(dev, 1);
+}
+EXPORT_SYMBOL_GPL(__pci_reset_function_locked);
+
+/**
  * pci_probe_reset_function - check whether the device can be safely reset
  * @dev: PCI device to reset
  *
diff --git a/include/linux/pci.h b/include/linux/pci.h
index a16b1df..65c2d8a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -817,6 +817,7 @@ int pcie_set_readrq(struct pci_dev *dev, int rq);
 int pcie_get_mps(struct pci_dev *dev);
 int pcie_set_mps(struct pci_dev *dev, int mps);
 int __pci_reset_function(struct pci_dev *dev);
+int __pci_reset_function_locked(struct pci_dev *dev);
 int pci_reset_function(struct pci_dev *dev);
 void pci_update_resource(struct pci_dev *dev, int resno);
 int __must_check pci_assign_resource(struct pci_dev *dev, int i);
-- 
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 Jan 12 17:09:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:09:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlO98-0004s2-O1; Thu, 12 Jan 2012 17:09: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 1RlO96-0004qz-F6
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:09:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326388102!52583954!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24652 invoked from network); 12 Jan 2012 17:08:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 17:08: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
	q0CH8fDI004640
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 17:08:42 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
	q0CH8f2o003495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 17:08:41 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CH8eeN013725; Thu, 12 Jan 2012 11:08:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 09:08:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0B4E340308; Thu, 12 Jan 2012 12:06:50 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Thu, 12 Jan 2012 12:06:45 -0500
Message-Id: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F0F139A.00D4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xen-pciback features for v3.4 (FLR). 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>
MIME-Version: 1.0
Content-Type: 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 pull these patches in your v3.4 branch. A bunch of folks using
Xen chatted a bit about this and it is a worthwile to have this functionality
in the kernel.

Thanks!

The two patches are:
 [PATCH 1/2] pci: Introduce __pci_reset_function_locked to be used
 [PATCH 2/2] xen/pciback: Support pci_reset_function, aka FLR or D3

 drivers/pci/pci.c                  |   25 ++++++++++++++++++++++
 drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
 drivers/xen/xen-pciback/pciback.h  |    1 +
 include/linux/pci.h                |    1 +
 4 files changed, 65 insertions(+), 3 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:09:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:09:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlO98-0004s2-O1; Thu, 12 Jan 2012 17:09: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 1RlO96-0004qz-F6
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:09:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326388102!52583954!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24652 invoked from network); 12 Jan 2012 17:08:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 17:08: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
	q0CH8fDI004640
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 17:08:42 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
	q0CH8f2o003495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 17:08:41 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CH8eeN013725; Thu, 12 Jan 2012 11:08:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 09:08:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0B4E340308; Thu, 12 Jan 2012 12:06:50 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org
Date: Thu, 12 Jan 2012 12:06:45 -0500
Message-Id: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.4
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F0F139A.00D4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xen-pciback features for v3.4 (FLR). 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>
MIME-Version: 1.0
Content-Type: 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 pull these patches in your v3.4 branch. A bunch of folks using
Xen chatted a bit about this and it is a worthwile to have this functionality
in the kernel.

Thanks!

The two patches are:
 [PATCH 1/2] pci: Introduce __pci_reset_function_locked to be used
 [PATCH 2/2] xen/pciback: Support pci_reset_function, aka FLR or D3

 drivers/pci/pci.c                  |   25 ++++++++++++++++++++++
 drivers/xen/xen-pciback/pci_stub.c |   41 +++++++++++++++++++++++++++++++++--
 drivers/xen/xen-pciback/pciback.h  |    1 +
 include/linux/pci.h                |    1 +
 4 files changed, 65 insertions(+), 3 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:12:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOCQ-0005JA-J0; Thu, 12 Jan 2012 17:12:26 +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 1RlOCO-0005IU-GC
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:12:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326388336!7558039!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21660 invoked from network); 12 Jan 2012 17:12:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 17:12:17 -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
	q0CHCCUL009876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 17:12:13 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
	q0CHCBR2011652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 17:12:12 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CHCAjP031481; Thu, 12 Jan 2012 11:12:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 09:12:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AEAD64030F; Thu, 12 Jan 2012 12:10:19 -0500 (EST)
Date: Thu, 12 Jan 2012 12:10:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120112171019.GA19771@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
	<20120112164025.GA22773@phenom.dumpdata.com>
	<256392989.20120112180546@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <256392989.20120112180546@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F0F146D.00F7,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Kay Sievers <kay.sievers@vrfy.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 06:05:46PM +0100, Sander Eikelenboom wrote:
> Hello Konrad,
> 
> Thursday, January 12, 2012, 5:40:25 PM, you wrote:
> 
> > On Thu, Jan 12, 2012 at 11:12:04AM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Jan 12, 2012 at 05:05:34PM +0100, Kay Sievers wrote:
> >> > On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
> >> > <konrad.wilk@oracle.com> wrote:
> >> > > On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> >> > 
> >> > >> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> >> > >>
> >> > >> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> >> > >> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
> >> > > Your patch that converts the xen-balloon to use the regular device bus driver
> >> > > (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
> >> > >
> >> > > The toolstack (xen-tools) use:
> >> > >
> >> > > /sys/devices/system/xen_memory/xen_memory0
> >> > >
> >> > > But with the change, it is now:
> >> > >
> >> > > /sys/devices/xen_memory0/target_kb
> >> > 
> >> > Urks, seems like a mistake on my side.
> >> > 
> >> > Please try if changing:
> >> >   bus_unregister(&balloon_subsys);
> >> > to:
> >> >   subsys_system_register(&balloon_subsys, NULL);
> >> > in:
> >> >   drivers/xen/xen-balloon.c
> >> > fixes the issue.
> >> 
> >> Heh. I was *just* looking at d369a5d8fc70710236ae2d06a0e42dce483712df
> >> ("clocksource: convert sysdev_class to a regular subsystem") and typed up this patch
> >> to try it out:
> 
> > Kay, are you Acking this patch? (I can send it to Linus for rc0 or rc1)
> 
> > commit 4e6f161986678a25c9e76af98df928408c734a27
> > Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date:   Thu Jan 12 11:35:50 2012 -0500
> 
> >     xen/balloon: Move the registration from device to subsystem.
> >     
> >     With git commit 070680218379e15c1901f4bf21b98e3cbf12b527
> >     "xen-balloon: convert sysdev_class to a regular subsystem" we would
> >     end up with the attributes being put in:
> >     
> >      /sys/devices/xen_memory0/target_kb
> >     instead of
> >     /sys/devices/system/xen_memory/xen_memory0/target_kb
> >     
> >     Making the tools unable to deflate the kernel to make more space
> >     for launching another guest and printing:
> 
> >     Error: Failed to query current memory allocation of dom0
> >     
> >     Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
> >     Suggested-by:  Kay Sievers <kay.sievers@vrfy.org>
> >     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
> > index 3832e30..596e6a7 100644
> > --- a/drivers/xen/xen-balloon.c
> > +++ b/drivers/xen/xen-balloon.c
> > @@ -221,7 +221,7 @@ static int register_balloon(struct device *dev)
> >  {
> >         int i, error;
> >  
> > -       error = bus_register(&balloon_subsys);
> > +       error = subsys_system_register(&balloon_subsys, NULL);
> >         if (error)
> >                 return error;
> >  
> 
> 
> Shouldn't the
> 
> if (error) {
>         bus_unregister(&balloon_subsys);
>         return error;
> }
> 
> right below it also be changed ?

I thought so too, but looking at how the subsys_system_register it looks
to be OK. Kay, thoughts?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:12:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOCQ-0005JA-J0; Thu, 12 Jan 2012 17:12:26 +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 1RlOCO-0005IU-GC
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:12:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326388336!7558039!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ4OTk1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21660 invoked from network); 12 Jan 2012 17:12:17 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 12 Jan 2012 17:12:17 -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
	q0CHCCUL009876
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 12 Jan 2012 17:12:13 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
	q0CHCBR2011652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 12 Jan 2012 17:12:12 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0CHCAjP031481; Thu, 12 Jan 2012 11:12:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 12 Jan 2012 09:12:10 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AEAD64030F; Thu, 12 Jan 2012 12:10:19 -0500 (EST)
Date: Thu, 12 Jan 2012 12:10:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120112171019.GA19771@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
	<20120112164025.GA22773@phenom.dumpdata.com>
	<256392989.20120112180546@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <256392989.20120112180546@eikelenboom.it>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F0F146D.00F7,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Kay Sievers <kay.sievers@vrfy.org>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 06:05:46PM +0100, Sander Eikelenboom wrote:
> Hello Konrad,
> 
> Thursday, January 12, 2012, 5:40:25 PM, you wrote:
> 
> > On Thu, Jan 12, 2012 at 11:12:04AM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Jan 12, 2012 at 05:05:34PM +0100, Kay Sievers wrote:
> >> > On Thu, Jan 12, 2012 at 16:46, Konrad Rzeszutek Wilk
> >> > <konrad.wilk@oracle.com> wrote:
> >> > > On Thu, Jan 12, 2012 at 01:38:32PM +0100, Sander Eikelenboom wrote:
> >> > 
> >> > >> Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361).
> >> > >>
> >> > >> It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0."
> >> > >> With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between.
> >> > > Your patch that converts the xen-balloon to use the regular device bus driver
> >> > > (070680218379e15c1901f4bf21b98e3cbf12b527) has some not-so-happy consequences.
> >> > >
> >> > > The toolstack (xen-tools) use:
> >> > >
> >> > > /sys/devices/system/xen_memory/xen_memory0
> >> > >
> >> > > But with the change, it is now:
> >> > >
> >> > > /sys/devices/xen_memory0/target_kb
> >> > 
> >> > Urks, seems like a mistake on my side.
> >> > 
> >> > Please try if changing:
> >> >   bus_unregister(&balloon_subsys);
> >> > to:
> >> >   subsys_system_register(&balloon_subsys, NULL);
> >> > in:
> >> >   drivers/xen/xen-balloon.c
> >> > fixes the issue.
> >> 
> >> Heh. I was *just* looking at d369a5d8fc70710236ae2d06a0e42dce483712df
> >> ("clocksource: convert sysdev_class to a regular subsystem") and typed up this patch
> >> to try it out:
> 
> > Kay, are you Acking this patch? (I can send it to Linus for rc0 or rc1)
> 
> > commit 4e6f161986678a25c9e76af98df928408c734a27
> > Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date:   Thu Jan 12 11:35:50 2012 -0500
> 
> >     xen/balloon: Move the registration from device to subsystem.
> >     
> >     With git commit 070680218379e15c1901f4bf21b98e3cbf12b527
> >     "xen-balloon: convert sysdev_class to a regular subsystem" we would
> >     end up with the attributes being put in:
> >     
> >      /sys/devices/xen_memory0/target_kb
> >     instead of
> >     /sys/devices/system/xen_memory/xen_memory0/target_kb
> >     
> >     Making the tools unable to deflate the kernel to make more space
> >     for launching another guest and printing:
> 
> >     Error: Failed to query current memory allocation of dom0
> >     
> >     Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
> >     Suggested-by:  Kay Sievers <kay.sievers@vrfy.org>
> >     Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
> > index 3832e30..596e6a7 100644
> > --- a/drivers/xen/xen-balloon.c
> > +++ b/drivers/xen/xen-balloon.c
> > @@ -221,7 +221,7 @@ static int register_balloon(struct device *dev)
> >  {
> >         int i, error;
> >  
> > -       error = bus_register(&balloon_subsys);
> > +       error = subsys_system_register(&balloon_subsys, NULL);
> >         if (error)
> >                 return error;
> >  
> 
> 
> Shouldn't the
> 
> if (error) {
>         bus_unregister(&balloon_subsys);
>         return error;
> }
> 
> right below it also be changed ?

I thought so too, but looking at how the subsys_system_register it looks
to be OK. Kay, thoughts?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:22:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOLd-0005fN-L4; Thu, 12 Jan 2012 17:21:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RlOLc-0005ey-ES
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:21:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326388909!8891555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15764 invoked from network); 12 Jan 2012 17:21:50 -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;
	12 Jan 2012 17:21:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9978662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:21: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, 12 Jan 2012 17: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
	1RlOLK-0003ME-22; Thu, 12 Jan 2012 17:21:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOLK-0002bU-1J;
	Thu, 12 Jan 2012 17:21:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.5794.29197.280475@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:21:38 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F0EF816.6030206@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@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>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
> The previous patch series used a domid file named similarly to a pid file
> to identify the location of xenstored and xenconsoled; this method would
> allow the TODO to be resolved. I think a better solution is to refer to the
> xenstore/xenconsole domains by name instead of domid, and set the names in
> a configuration file (/etc/xen/xl.conf?). This would also replace the
> xenstore_dom/console_dom parameters in patch #5.

Clearly this isn't a configuration parameter; it's a runtime value.
You don't store pids in config files.

If this can't go in xenstore itself then a file in /var/run/xen would
do just fine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:22:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:22:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOLd-0005fN-L4; Thu, 12 Jan 2012 17:21:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RlOLc-0005ey-ES
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:21:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326388909!8891555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15764 invoked from network); 12 Jan 2012 17:21:50 -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;
	12 Jan 2012 17:21:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9978662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:21: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, 12 Jan 2012 17: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
	1RlOLK-0003ME-22; Thu, 12 Jan 2012 17:21:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOLK-0002bU-1J;
	Thu, 12 Jan 2012 17:21:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.5794.29197.280475@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:21:38 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F0EF816.6030206@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@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>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
> The previous patch series used a domid file named similarly to a pid file
> to identify the location of xenstored and xenconsoled; this method would
> allow the TODO to be resolved. I think a better solution is to refer to the
> xenstore/xenconsole domains by name instead of domid, and set the names in
> a configuration file (/etc/xen/xl.conf?). This would also replace the
> xenstore_dom/console_dom parameters in patch #5.

Clearly this isn't a configuration parameter; it's a runtime value.
You don't store pids in config files.

If this can't go in xenstore itself then a file in /var/run/xen would
do just fine.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:23:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOMi-0005iy-4w; Thu, 12 Jan 2012 17:23:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RlOMg-0005ih-TX; Thu, 12 Jan 2012 17:23:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326388916!60736208!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15544 invoked from network); 12 Jan 2012 17:21:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 17:21:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9978683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:23: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;
	Thu, 12 Jan 2012 17:23:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Laszlo Ersek <lersek@redhat.com>
Date: Thu, 12 Jan 2012 17:23:01 +0000
In-Reply-To: <4F0F1236.6010705@redhat.com>
References: <20120109213039.GC4773@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
	<1326148662.29084.77.camel@dagon.hellion.org.uk>
	<4F0F1236.6010705@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326388981.17210.284.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 17:02 +0000, Laszlo Ersek wrote:
> On 01/09/12 23:37, Ian Campbell wrote:
> > On Mon, 2012-01-09 at 22:26 +0000, James Harper wrote:
> >>>   - Initial work laid out for netback page-flipping (also called zero-copying).
> >>
> >> Isn't this how it used to work originally?
> >
> > Some of the original infrastructure for doing this was not upstreamable
> > (the PageForeign stuff) so while upstream netback I decided to go with a
> > simpler/less-intrusive copying mode so we could have some sort of
> > networking support in mainline.
> >
> > I've been working on re-laying the necessary infrastructure to allow for
> > page flipping/mapping mode in upstream (as well as fixing another
> > generic class of bug) -- you can see the "skb frag destructor" patches
> > on the netdev list.
> 
> (Ultimately I found it here:
> 
>      http://lwn.net/Articles/474791/
> 
> .)


The most recent posting starts at: 
http://thread.gmane.org/gmane.linux.network/217006

> Ian, do you think the NFS fix in
> 
>      http://article.gmane.org/gmane.linux.nfs/45955
> 
> for problem
> 
>      http://marc.info/?l=linux-nfs&m=122424132729720&w=2
> 
> would be technically feasible to port to 2.6.18, based on the existing 
> PageForeign stuff instead of parts 1-5 of the series?

I don't think so -- PageForeign is triggered by the last core page
reference getting dropped, but in the NFS case the running process holds
at least one so you won't actually complete until the process exits...

This is similar to the sorts of issue I described in:
http://thread.gmane.org/gmane.linux.network/217006

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:23:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOMi-0005iy-4w; Thu, 12 Jan 2012 17:23:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1RlOMg-0005ih-TX; Thu, 12 Jan 2012 17:23:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326388916!60736208!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15544 invoked from network); 12 Jan 2012 17:21:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 17:21:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9978683"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:23: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;
	Thu, 12 Jan 2012 17:23:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Laszlo Ersek <lersek@redhat.com>
Date: Thu, 12 Jan 2012 17:23:01 +0000
In-Reply-To: <4F0F1236.6010705@redhat.com>
References: <20120109213039.GC4773@phenom.dumpdata.com>
	<6035A0D088A63A46850C3988ED045A4B09AFCB@BITCOM1.int.sbss.com.au>
	<1326148662.29084.77.camel@dagon.hellion.org.uk>
	<4F0F1236.6010705@redhat.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326388981.17210.284.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	James Harper <james.harper@bendigoit.com.au>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Konrad
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] Features and bug-fixes that went in Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 17:02 +0000, Laszlo Ersek wrote:
> On 01/09/12 23:37, Ian Campbell wrote:
> > On Mon, 2012-01-09 at 22:26 +0000, James Harper wrote:
> >>>   - Initial work laid out for netback page-flipping (also called zero-copying).
> >>
> >> Isn't this how it used to work originally?
> >
> > Some of the original infrastructure for doing this was not upstreamable
> > (the PageForeign stuff) so while upstream netback I decided to go with a
> > simpler/less-intrusive copying mode so we could have some sort of
> > networking support in mainline.
> >
> > I've been working on re-laying the necessary infrastructure to allow for
> > page flipping/mapping mode in upstream (as well as fixing another
> > generic class of bug) -- you can see the "skb frag destructor" patches
> > on the netdev list.
> 
> (Ultimately I found it here:
> 
>      http://lwn.net/Articles/474791/
> 
> .)


The most recent posting starts at: 
http://thread.gmane.org/gmane.linux.network/217006

> Ian, do you think the NFS fix in
> 
>      http://article.gmane.org/gmane.linux.nfs/45955
> 
> for problem
> 
>      http://marc.info/?l=linux-nfs&m=122424132729720&w=2
> 
> would be technically feasible to port to 2.6.18, based on the existing 
> PageForeign stuff instead of parts 1-5 of the series?

I don't think so -- PageForeign is triggered by the last core page
reference getting dropped, but in the NFS case the running process holds
at least one so you won't actually complete until the process exits...

This is similar to the sorts of issue I described in:
http://thread.gmane.org/gmane.linux.network/217006

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:32:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOW1-0006Fc-0D; Thu, 12 Jan 2012 17:32:41 +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 1RlOW0-0006FS-4r
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:32:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326389552!10690531!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 6364 invoked from network); 12 Jan 2012 17:32:33 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 17:32:33 -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
	q0CHWTsQ016743; Thu, 12 Jan 2012 17:32:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0CHWTQO017492; 
	Thu, 12 Jan 2012 12:32:29 -0500
Message-ID: <4F0F192A.5010503@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 12:32:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
	<20239.5794.29197.280475@mariner.uk.xensource.com>
In-Reply-To: <20239.5794.29197.280475@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 01/12/2012 12:21 PM, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
>> The previous patch series used a domid file named similarly to a pid file
>> to identify the location of xenstored and xenconsoled; this method would
>> allow the TODO to be resolved. I think a better solution is to refer to the
>> xenstore/xenconsole domains by name instead of domid, and set the names in
>> a configuration file (/etc/xen/xl.conf?). This would also replace the
>> xenstore_dom/console_dom parameters in patch #5.
> 
> Clearly this isn't a configuration parameter; it's a runtime value.
> You don't store pids in config files.

I was suggesting storing the domain name in the config file, which wouldn't
be a runtime value. However, I think it should be possible to place this in
xenstore, and that will probably be better as that's where you would expect
things like this to be.

> If this can't go in xenstore itself then a file in /var/run/xen would
> do just fine.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:32:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOW1-0006Fc-0D; Thu, 12 Jan 2012 17:32:41 +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 1RlOW0-0006FS-4r
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:32:40 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326389552!10690531!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 6364 invoked from network); 12 Jan 2012 17:32:33 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 17:32:33 -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
	q0CHWTsQ016743; Thu, 12 Jan 2012 17:32:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0CHWTQO017492; 
	Thu, 12 Jan 2012 12:32:29 -0500
Message-ID: <4F0F192A.5010503@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 12:32:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
	<20239.5794.29197.280475@mariner.uk.xensource.com>
In-Reply-To: <20239.5794.29197.280475@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 01/12/2012 12:21 PM, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
>> The previous patch series used a domid file named similarly to a pid file
>> to identify the location of xenstored and xenconsoled; this method would
>> allow the TODO to be resolved. I think a better solution is to refer to the
>> xenstore/xenconsole domains by name instead of domid, and set the names in
>> a configuration file (/etc/xen/xl.conf?). This would also replace the
>> xenstore_dom/console_dom parameters in patch #5.
> 
> Clearly this isn't a configuration parameter; it's a runtime value.
> You don't store pids in config files.

I was suggesting storing the domain name in the config file, which wouldn't
be a runtime value. However, I think it should be possible to place this in
xenstore, and that will probably be better as that's where you would expect
things like this to be.

> If this can't go in xenstore itself then a file in /var/run/xen would
> do just fine.
> 
> Ian.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:34:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOXi-0006Ln-JM; Thu, 12 Jan 2012 17:34: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 1RlOXg-0006LO-JG
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:34:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326389658!10667229!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 581 invoked from network); 12 Jan 2012 17:34:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 17:34:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9978989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:34: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, 12 Jan 2012 17:34: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
	1RlOXZ-0003QM-4j; Thu, 12 Jan 2012 17:34:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOXZ-0002cx-3z;
	Thu, 12 Jan 2012 17:34:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.6553.110187.528841@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:34:17 +0000
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326304739.12973.1.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>
	<1326304739.12973.1.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
	for	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Faggioli writes ("[Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for vcpu-pin."):
> Allow for "^<cpuid>" syntax while specifying the pCPUs list
> during a vcpu-pin. This enables doing the following:
> 
>  xl vcpu-pin 1 1 0-4,^2
...
> +    if (strcmp(cpu, "all")) {
> +        for (toka = strtok(cpu, ","), i = 0; toka; toka = strtok(NULL, ","), ++i) {

OMG you used strtok.  strtok is not thread-safe.  strtok_r is but
still modifies its input string - hence your need to strdup.  If you
do want to do it this way IMO the strdup should be in vcpupin_parse
which should take a const char*.  Are you sure this is the right
approach to parsing this ?

<record type="broken">
Your patch 2 has a number of overly long lines.
</record>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:34:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOXi-0006Ln-JM; Thu, 12 Jan 2012 17:34: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 1RlOXg-0006LO-JG
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:34:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326389658!10667229!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 581 invoked from network); 12 Jan 2012 17:34:18 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 17:34:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9978989"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:34: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, 12 Jan 2012 17:34: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
	1RlOXZ-0003QM-4j; Thu, 12 Jan 2012 17:34:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOXZ-0002cx-3z;
	Thu, 12 Jan 2012 17:34:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.6553.110187.528841@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:34:17 +0000
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326304739.12973.1.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>
	<1326304739.12973.1.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
	for	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Faggioli writes ("[Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for vcpu-pin."):
> Allow for "^<cpuid>" syntax while specifying the pCPUs list
> during a vcpu-pin. This enables doing the following:
> 
>  xl vcpu-pin 1 1 0-4,^2
...
> +    if (strcmp(cpu, "all")) {
> +        for (toka = strtok(cpu, ","), i = 0; toka; toka = strtok(NULL, ","), ++i) {

OMG you used strtok.  strtok is not thread-safe.  strtok_r is but
still modifies its input string - hence your need to strdup.  If you
do want to do it this way IMO the strdup should be in vcpupin_parse
which should take a const char*.  Are you sure this is the right
approach to parsing this ?

<record type="broken">
Your patch 2 has a number of overly long lines.
</record>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOYc-0006Qj-2x; Thu, 12 Jan 2012 17:35: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 1RlOYa-0006Q3-7j
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:35:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326389713!10177437!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16304 invoked from network); 12 Jan 2012 17:35:14 -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;
	12 Jan 2012 17:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:35: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, 12 Jan 2012 17:35: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
	1RlOYS-0003Qo-Uq; Thu, 12 Jan 2012 17:35:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOYS-0002d5-UD;
	Thu, 12 Jan 2012 17:35:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.6608.925166.554645@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:35:12 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <4F0F192A.5010503@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
	<20239.5794.29197.280475@mariner.uk.xensource.com>
	<4F0F192A.5010503@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>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
> I was suggesting storing the domain name in the config file, which wouldn't
> be a runtime value. However, I think it should be possible to place this in
> xenstore, and that will probably be better as that's where you would expect
> things like this to be.

The registry of domain names is in xenstore, so that's not going to
work :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOYc-0006Qj-2x; Thu, 12 Jan 2012 17:35: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 1RlOYa-0006Q3-7j
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:35:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326389713!10177437!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16304 invoked from network); 12 Jan 2012 17:35:14 -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;
	12 Jan 2012 17:35:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:35: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, 12 Jan 2012 17:35: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
	1RlOYS-0003Qo-Uq; Thu, 12 Jan 2012 17:35:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOYS-0002d5-UD;
	Thu, 12 Jan 2012 17:35:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.6608.925166.554645@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:35:12 +0000
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
In-Reply-To: <4F0F192A.5010503@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
	<20239.5794.29197.280475@mariner.uk.xensource.com>
	<4F0F192A.5010503@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>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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

Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
> I was suggesting storing the domain name in the config file, which wouldn't
> be a runtime value. However, I think it should be possible to place this in
> xenstore, and that will probably be better as that's where you would expect
> things like this to be.

The registry of domain names is in xenstore, so that's not going to
work :-).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:38:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlObo-0006je-Ne; Thu, 12 Jan 2012 17:38: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 1RlObn-0006jN-8X
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:38:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326389898!62207784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14805 invoked from network); 12 Jan 2012 17:38:18 -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;
	12 Jan 2012 17:38:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:38: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, 12 Jan 2012 17:38:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Jan 2012 17:38:37 +0000
In-Reply-To: <20239.6608.925166.554645@mariner.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
	<20239.5794.29197.280475@mariner.uk.xensource.com>
	<4F0F192A.5010503@tycho.nsa.gov>
	<20239.6608.925166.554645@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326389918.17210.286.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 Thu, 2012-01-12 at 17:35 +0000, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
> > I was suggesting storing the domain name in the config file, which wouldn't
> > be a runtime value. However, I think it should be possible to place this in
> > xenstore, and that will probably be better as that's where you would expect
> > things like this to be.
> 
> The registry of domain names is in xenstore, so that's not going to
> work :-).

This info is used for starting subsequent domains not the xenstore
domain itself so I think it will.

Whichever process starts the xenstore stubdom watis for it to initialise
and then writes the necessary parameters to xenstore. Future toolstack
invocations can then read it back. The toolstack doesn't need to know
where the xenstore is running since it just uses /proc/xen/xenbus.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:38:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlObo-0006je-Ne; Thu, 12 Jan 2012 17:38: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 1RlObn-0006jN-8X
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:38:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326389898!62207784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14805 invoked from network); 12 Jan 2012 17:38:18 -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;
	12 Jan 2012 17:38:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:38: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, 12 Jan 2012 17:38:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Jan 2012 17:38:37 +0000
In-Reply-To: <20239.6608.925166.554645@mariner.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
	<20239.5794.29197.280475@mariner.uk.xensource.com>
	<4F0F192A.5010503@tycho.nsa.gov>
	<20239.6608.925166.554645@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326389918.17210.286.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 Thu, 2012-01-12 at 17:35 +0000, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
> > I was suggesting storing the domain name in the config file, which wouldn't
> > be a runtime value. However, I think it should be possible to place this in
> > xenstore, and that will probably be better as that's where you would expect
> > things like this to be.
> 
> The registry of domain names is in xenstore, so that's not going to
> work :-).

This info is used for starting subsequent domains not the xenstore
domain itself so I think it will.

Whichever process starts the xenstore stubdom watis for it to initialise
and then writes the necessary parameters to xenstore. Future toolstack
invocations can then read it back. The toolstack doesn't need to know
where the xenstore is running since it just uses /proc/xen/xenbus.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOjy-0006zw-N4; Thu, 12 Jan 2012 17:47:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlOjx-0006zk-GA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:47:05 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326390417!2213896!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjUxMjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14974 invoked from network); 12 Jan 2012 17:46:58 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-2.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 17:46:58 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0CHk4GM018107;
	Thu, 12 Jan 2012 12:46:04 -0500
Date: Thu, 12 Jan 2012 12:46:03 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Bastian Blank <waldi@debian.org>
Message-ID: <38f5d265-e690-4a8c-9d73-b43c804087e3@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120112154206.GA9722@wavehammer.waldi.eu.org>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	virtualization@lists.linux-foundation.org, konrad@darnok.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Thu, Jan 12, 2012 at 09:37:45AM -0500, Konrad Rzeszutek Wilk
> wrote:
> > Or is it possible to make the modules (fb) try to load xenbus
> > frontend
> > automatically? Preferrably one would do this:
> 
> Which modules?
> 
> > modprobe xen_fbfront
> > which would then automatically load xenbus_module, xen_kbdfront
> 
> I think you are missing something.

I'll look into this and see if I can get the xenbus module to
work on boot with the right initrd magic. Or at least come up with
a better story why it won't.

Drew

> 
> | video/xen-fbfront.c:      return
> | xenbus_register_frontend(&xenfb_driver);
> | xen/xenbus/xenbus_probe_frontend.c:EXPORT_SYMBOL_GPL(xenbus_register_frontend);
> 
> xen-fbfront already pulls in the module, at least in Linus' tree.
> 
> > Better yet if udev/kudzu figured out this automtically and loaded
> > the modules.
> 
> No workarounds for kernel problems if not absolutely necessary.
> 
> Bastian
> 
> --
> Military secrets are the most fleeting of all.
> 		-- Spock, "The Enterprise Incident", stardate 5027.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOjy-0006zw-N4; Thu, 12 Jan 2012 17:47:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <drjones@redhat.com>) id 1RlOjx-0006zk-GA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:47:05 +0000
X-Env-Sender: drjones@redhat.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326390417!2213896!1
X-Originating-IP: [209.132.183.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjUgPT4gNjUxMjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14974 invoked from network); 12 Jan 2012 17:46:58 -0000
Received: from mx4-phx2.redhat.com (HELO mx4-phx2.redhat.com) (209.132.183.25)
	by server-2.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 17:46:58 -0000
Received: from zmail13.collab.prod.int.phx2.redhat.com
	(zmail13.collab.prod.int.phx2.redhat.com [10.5.83.15])
	by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0CHk4GM018107;
	Thu, 12 Jan 2012 12:46:04 -0500
Date: Thu, 12 Jan 2012 12:46:03 -0500 (EST)
From: Andrew Jones <drjones@redhat.com>
To: Bastian Blank <waldi@debian.org>
Message-ID: <38f5d265-e690-4a8c-9d73-b43c804087e3@zmail13.collab.prod.int.phx2.redhat.com>
In-Reply-To: <20120112154206.GA9722@wavehammer.waldi.eu.org>
MIME-Version: 1.0
X-Originating-IP: [10.34.1.174]
X-Mailer: Zimbra 7.1.2_GA_3268 (ZimbraWebClient - FF3.0 (Linux)/7.1.2_GA_3268)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	stefano stabellini <stefano.stabellini@eu.citrix.com>,
	virtualization@lists.linux-foundation.org, konrad@darnok.org
Subject: Re: [Xen-devel] [PATCH 1/4] xen kconfig: keep XEN_XENBUS_FRONTEND
	builtin
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



----- Original Message -----
> On Thu, Jan 12, 2012 at 09:37:45AM -0500, Konrad Rzeszutek Wilk
> wrote:
> > Or is it possible to make the modules (fb) try to load xenbus
> > frontend
> > automatically? Preferrably one would do this:
> 
> Which modules?
> 
> > modprobe xen_fbfront
> > which would then automatically load xenbus_module, xen_kbdfront
> 
> I think you are missing something.

I'll look into this and see if I can get the xenbus module to
work on boot with the right initrd magic. Or at least come up with
a better story why it won't.

Drew

> 
> | video/xen-fbfront.c:      return
> | xenbus_register_frontend(&xenfb_driver);
> | xen/xenbus/xenbus_probe_frontend.c:EXPORT_SYMBOL_GPL(xenbus_register_frontend);
> 
> xen-fbfront already pulls in the module, at least in Linus' tree.
> 
> > Better yet if udev/kudzu figured out this automtically and loaded
> > the modules.
> 
> No workarounds for kernel problems if not absolutely necessary.
> 
> Bastian
> 
> --
> Military secrets are the most fleeting of all.
> 		-- Spock, "The Enterprise Incident", stardate 5027.4
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:48:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:48:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOkZ-00072u-8g; Thu, 12 Jan 2012 17:47:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlOkY-00072Q-EG
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:47:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326390407!52303571!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 22554 invoked from network); 12 Jan 2012 17:46:47 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 17:46:47 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CHlYEq021070; Thu, 12 Jan 2012 17:47:34 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 q0CHlY7Y018524; 
	Thu, 12 Jan 2012 12:47:34 -0500
Message-ID: <4F0F1CB3.6070905@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 12:47:31 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
	<20239.5794.29197.280475@mariner.uk.xensource.com>
	<4F0F192A.5010503@tycho.nsa.gov>
	<20239.6608.925166.554645@mariner.uk.xensource.com>
In-Reply-To: <20239.6608.925166.554645@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 01/12/2012 12:35 PM, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
>> I was suggesting storing the domain name in the config file, which wouldn't
>> be a runtime value. However, I think it should be possible to place this in
>> xenstore, and that will probably be better as that's where you would expect
>> things like this to be.
> 
> The registry of domain names is in xenstore, so that's not going to
> work :-).
> 
> Ian.
> 

Actually, it'll work just fine: dom0 has a connection to xenstore, it just
can't (from userspace) tell what domid it's talking to. It's really the same
thing as just storing the xenstored domid in xenstore; /tool/xenstored/domid
is where I plan to put it.

-- 
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 Jan 12 17:48:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:48:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOkZ-00072u-8g; Thu, 12 Jan 2012 17:47:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlOkY-00072Q-EG
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:47:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326390407!52303571!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 22554 invoked from network); 12 Jan 2012 17:46:47 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 17:46:47 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CHlYEq021070; Thu, 12 Jan 2012 17:47:34 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 q0CHlY7Y018524; 
	Thu, 12 Jan 2012 12:47:34 -0500
Message-ID: <4F0F1CB3.6070905@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 12:47:31 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362398.17210.227.camel@zakaz.uk.xensource.com>
	<4F0EF816.6030206@tycho.nsa.gov>
	<20239.5794.29197.280475@mariner.uk.xensource.com>
	<4F0F192A.5010503@tycho.nsa.gov>
	<20239.6608.925166.554645@mariner.uk.xensource.com>
In-Reply-To: <20239.6608.925166.554645@mariner.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 01/12/2012 12:35 PM, Ian Jackson wrote:
> Daniel De Graaf writes ("Re: [Xen-devel] [PATCH 06/18] lib{xc, xl}: Seed grant tables with xenstore and console grants"):
>> I was suggesting storing the domain name in the config file, which wouldn't
>> be a runtime value. However, I think it should be possible to place this in
>> xenstore, and that will probably be better as that's where you would expect
>> things like this to be.
> 
> The registry of domain names is in xenstore, so that's not going to
> work :-).
> 
> Ian.
> 

Actually, it'll work just fine: dom0 has a connection to xenstore, it just
can't (from userspace) tell what domid it's talking to. It's really the same
thing as just storing the xenstored domid in xenstore; /tool/xenstored/domid
is where I plan to put it.

-- 
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 Jan 12 17:49:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOli-0007Ay-Oh; Thu, 12 Jan 2012 17:48:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kay.sievers@vrfy.org>) id 1RlOlh-0007Ai-9m
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:48:53 +0000
X-Env-Sender: kay.sievers@vrfy.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326390483!50000713!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 10454 invoked from network); 12 Jan 2012 17:48:05 -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;
	12 Jan 2012 17:48:05 -0000
Received: by pbcc6 with SMTP id c6so4211320pbc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 09:48:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrfy.org; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=5Av97KR8J8phZq68IGjoDzVCV0Jaz5YSZXdpWQeNbBI=;
	b=f+c34MNID2KDJCNFznbvOdMGvpDv8nx17sluIEykQWGx4A9wtKnF63J+WvRTSSuoEm
	HL+fRPXAuQkQL/Y3p1PVjGXnlnIk2WWJpc3AmRqT+pirLAZbA2kASv4Ro1ho69aweC1p
	0WpbSeamni5GcDbrNxCaMCLd31u4K8Pc8whDw=
Received: by 10.68.125.129 with SMTP id mq1mr10074557pbb.45.1326390529171;
	Thu, 12 Jan 2012 09:48:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.34.14 with HTTP; Thu, 12 Jan 2012 09:48:28 -0800 (PST)
In-Reply-To: <20120112171019.GA19771@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
	<20120112164025.GA22773@phenom.dumpdata.com>
	<256392989.20120112180546@eikelenboom.it>
	<20120112171019.GA19771@phenom.dumpdata.com>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu, 12 Jan 2012 18:48:28 +0100
Message-ID: <CAPXgP11GwHuA3e=xYUpKgvDTEwYb1Q9FH=aV8wvivUXhOaXBVg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBKYW4gMTIsIDIwMTIgYXQgMTg6MTAsIEtvbnJhZCBSemVzenV0ZWsgV2lsawo8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4gT24gVGh1LCBKYW4gMTIsIDIwMTIgYXQgMDY6
MDU6NDZQTSArMDEwMCwgU2FuZGVyIEVpa2VsZW5ib29tIHdyb3RlOgoKPj4gU2hvdWxkbid0IHRo
ZQo+Pgo+PiBpZiAoZXJyb3IpIHsKPj4gwqAgwqAgwqAgwqAgYnVzX3VucmVnaXN0ZXIoJmJhbGxv
b25fc3Vic3lzKTsKPj4gwqAgwqAgwqAgwqAgcmV0dXJuIGVycm9yOwo+PiB9Cj4+Cj4+IHJpZ2h0
IGJlbG93IGl0IGFsc28gYmUgY2hhbmdlZCA/Cj4KPiBJIHRob3VnaHQgc28gdG9vLCBidXQgbG9v
a2luZyBhdCBob3cgdGhlIHN1YnN5c19zeXN0ZW1fcmVnaXN0ZXIgaXQgbG9va3MKPiB0byBiZSBP
Sy4gS2F5LCB0aG91Z2h0cz8KCk5vLCBpdCdzIGZpbmUsIHRoZXJlIGlzIG5vdGhpbmcgZWxzZS4K
ClRoZSBzdWJzeXNfc3lzdGVtX3JlZ2lzdGVyKCkgZnVjcnRpb24gaXMgYSBuZXcgZnVuY3Rpb24g
KGZvciBjb21wYXQKd2l0aCBvbGQgc3lzZGV2IHJ1bGVzIG9ubHkpIHRoYXQgcmVnaXN0ZXJzIGEg
YnVzLiBUaGUgY291bnRlcnBhcnQgaXMKdGhlIGJ1c191bnJlZ2lzdGVyLgoKVGhlIGxvbmctdGVy
bSBwaWN0dXJlIGlzIHRoYXQgJ3N0cnVjdCBidXNfdHlwZScgYW5kICdzdHJ1Y3QgY2xhc3MnCndp
bGwgYmUgbWVyZ2VkIGFuZCBldmVyeXRoaW5nIHdpbGwgYmUgY2FsbGVkICdzdWJzeXMnLgoKS2F5
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:49:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOli-0007Ay-Oh; Thu, 12 Jan 2012 17:48:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kay.sievers@vrfy.org>) id 1RlOlh-0007Ai-9m
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:48:53 +0000
X-Env-Sender: kay.sievers@vrfy.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326390483!50000713!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 10454 invoked from network); 12 Jan 2012 17:48:05 -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;
	12 Jan 2012 17:48:05 -0000
Received: by pbcc6 with SMTP id c6so4211320pbc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 09:48:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrfy.org; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=5Av97KR8J8phZq68IGjoDzVCV0Jaz5YSZXdpWQeNbBI=;
	b=f+c34MNID2KDJCNFznbvOdMGvpDv8nx17sluIEykQWGx4A9wtKnF63J+WvRTSSuoEm
	HL+fRPXAuQkQL/Y3p1PVjGXnlnIk2WWJpc3AmRqT+pirLAZbA2kASv4Ro1ho69aweC1p
	0WpbSeamni5GcDbrNxCaMCLd31u4K8Pc8whDw=
Received: by 10.68.125.129 with SMTP id mq1mr10074557pbb.45.1326390529171;
	Thu, 12 Jan 2012 09:48:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.34.14 with HTTP; Thu, 12 Jan 2012 09:48:28 -0800 (PST)
In-Reply-To: <20120112171019.GA19771@phenom.dumpdata.com>
References: <498097597.20120112133832@eikelenboom.it>
	<20120112154613.GA10148@phenom.dumpdata.com>
	<CAPXgP1373C5SfzU-rfo5GG53dUE6dVzECSuKzX1c_FirpXQt2g@mail.gmail.com>
	<20120112161204.GC10269@phenom.dumpdata.com>
	<20120112164025.GA22773@phenom.dumpdata.com>
	<256392989.20120112180546@eikelenboom.it>
	<20120112171019.GA19771@phenom.dumpdata.com>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Thu, 12 Jan 2012 18:48:28 +0100
Message-ID: <CAPXgP11GwHuA3e=xYUpKgvDTEwYb1Q9FH=aV8wvivUXhOaXBVg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] linux 3.3-pre-rc1: Starting domU fails with Error:
 Failed to query current memory allocation of dom0.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVGh1LCBKYW4gMTIsIDIwMTIgYXQgMTg6MTAsIEtvbnJhZCBSemVzenV0ZWsgV2lsawo8a29u
cmFkLndpbGtAb3JhY2xlLmNvbT4gd3JvdGU6Cj4gT24gVGh1LCBKYW4gMTIsIDIwMTIgYXQgMDY6
MDU6NDZQTSArMDEwMCwgU2FuZGVyIEVpa2VsZW5ib29tIHdyb3RlOgoKPj4gU2hvdWxkbid0IHRo
ZQo+Pgo+PiBpZiAoZXJyb3IpIHsKPj4gwqAgwqAgwqAgwqAgYnVzX3VucmVnaXN0ZXIoJmJhbGxv
b25fc3Vic3lzKTsKPj4gwqAgwqAgwqAgwqAgcmV0dXJuIGVycm9yOwo+PiB9Cj4+Cj4+IHJpZ2h0
IGJlbG93IGl0IGFsc28gYmUgY2hhbmdlZCA/Cj4KPiBJIHRob3VnaHQgc28gdG9vLCBidXQgbG9v
a2luZyBhdCBob3cgdGhlIHN1YnN5c19zeXN0ZW1fcmVnaXN0ZXIgaXQgbG9va3MKPiB0byBiZSBP
Sy4gS2F5LCB0aG91Z2h0cz8KCk5vLCBpdCdzIGZpbmUsIHRoZXJlIGlzIG5vdGhpbmcgZWxzZS4K
ClRoZSBzdWJzeXNfc3lzdGVtX3JlZ2lzdGVyKCkgZnVjcnRpb24gaXMgYSBuZXcgZnVuY3Rpb24g
KGZvciBjb21wYXQKd2l0aCBvbGQgc3lzZGV2IHJ1bGVzIG9ubHkpIHRoYXQgcmVnaXN0ZXJzIGEg
YnVzLiBUaGUgY291bnRlcnBhcnQgaXMKdGhlIGJ1c191bnJlZ2lzdGVyLgoKVGhlIGxvbmctdGVy
bSBwaWN0dXJlIGlzIHRoYXQgJ3N0cnVjdCBidXNfdHlwZScgYW5kICdzdHJ1Y3QgY2xhc3MnCndp
bGwgYmUgbWVyZ2VkIGFuZCBldmVyeXRoaW5nIHdpbGwgYmUgY2FsbGVkICdzdWJzeXMnLgoKS2F5
CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2
ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0
cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:51:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOnu-0007O3-BF; Thu, 12 Jan 2012 17:51:10 +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 1RlOns-0007Nd-W2
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:51:09 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326390662!10649518!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 21563 invoked from network); 12 Jan 2012 17:51:02 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 17:51:02 -0000
Received: by werg1 with SMTP id g1so3874245wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 09:51:02 -0800 (PST)
Received: by 10.216.133.82 with SMTP id p60mr467330wei.59.1326390662177; Thu,
	12 Jan 2012 09:51:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.116.206 with HTTP; Thu, 12 Jan 2012 09:50:41 -0800 (PST)
In-Reply-To: <cfc86d79380e4f7f4ba88de9794877c8.squirrel@webmail.lagarcavilla.org>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
	<63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
	<20120112135945.GA8324@aepfle.de>
	<cfc86d79380e4f7f4ba88de9794877c8.squirrel@webmail.lagarcavilla.org>
From: Adin Scannell <adin@gridcentric.ca>
Date: Thu, 12 Jan 2012 12:50:41 -0500
X-Google-Sender-Auth: ZXy6RGrnK12pl6pGs-ctE-MJKTU
Message-ID: <CAAJKtqpkOaNrV=apZrteWD1Oh=gWx-wJu4pWeJD+DEuj-0ghgw@mail.gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	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, Jan 12, 2012 at 11:11 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>>> What we did is take this patch, amalgamate it with some bits from our
>>> ring
>>> management approach. We're ready to submit that, along with a
>>> description
>>> of how we test it. It works for us, and it involves wait queue's for
>>> corner cases.
>>
>> Now if the patch you just sent out uses wait queues as well, and using
>> wait queues causes sudden host reboots for reasons not yet known, how is
>> your patch any better other that the reboots dont appear to happen
>> anymore?

I didn't spend a lot of time diagnosing exactly what was going wrong
with the patch.  I did have some local patches applied (in the process
of being submitted to the list) and some debug changes to ensure that
the correct code paths were hit, so it's quite possible that it may
have been my mistake. If so, I apologize. I didn't want to spend a lot
of time debugging and I'd had a similar experience with waitqueues in
the fall.

As Andres pointed out, we spent time merging our local approach into
your patch and testing that one. As a result of the combination, I
also did a few interface changes to ensure that callers use the
mem_event code correctly (i.e. calls to wake() are handled internally,
rather than relying on callers), and dropped some of the complexity of
accounting separately for foreign mappers.  With the waitqueue
failsafe in place, I don't think that's necessary.  Anyways, I tried
to preserve the spirit of your code, and would love to hear thoughts.

We'll be doing more testing today to ensure that we've properly
exercised all the different code paths (including wait queues).

Cheers,
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:51:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOnu-0007O3-BF; Thu, 12 Jan 2012 17:51:10 +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 1RlOns-0007Nd-W2
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:51:09 +0000
X-Env-Sender: amscanne@gridcentric.ca
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326390662!10649518!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 21563 invoked from network); 12 Jan 2012 17:51:02 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 17:51:02 -0000
Received: by werg1 with SMTP id g1so3874245wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 09:51:02 -0800 (PST)
Received: by 10.216.133.82 with SMTP id p60mr467330wei.59.1326390662177; Thu,
	12 Jan 2012 09:51:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.116.206 with HTTP; Thu, 12 Jan 2012 09:50:41 -0800 (PST)
In-Reply-To: <cfc86d79380e4f7f4ba88de9794877c8.squirrel@webmail.lagarcavilla.org>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
	<63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
	<20120112135945.GA8324@aepfle.de>
	<cfc86d79380e4f7f4ba88de9794877c8.squirrel@webmail.lagarcavilla.org>
From: Adin Scannell <adin@gridcentric.ca>
Date: Thu, 12 Jan 2012 12:50:41 -0500
X-Google-Sender-Auth: ZXy6RGrnK12pl6pGs-ctE-MJKTU
Message-ID: <CAAJKtqpkOaNrV=apZrteWD1Oh=gWx-wJu4pWeJD+DEuj-0ghgw@mail.gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	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, Jan 12, 2012 at 11:11 AM, Andres Lagar-Cavilla
<andres@lagarcavilla.org> wrote:
>>> What we did is take this patch, amalgamate it with some bits from our
>>> ring
>>> management approach. We're ready to submit that, along with a
>>> description
>>> of how we test it. It works for us, and it involves wait queue's for
>>> corner cases.
>>
>> Now if the patch you just sent out uses wait queues as well, and using
>> wait queues causes sudden host reboots for reasons not yet known, how is
>> your patch any better other that the reboots dont appear to happen
>> anymore?

I didn't spend a lot of time diagnosing exactly what was going wrong
with the patch.  I did have some local patches applied (in the process
of being submitted to the list) and some debug changes to ensure that
the correct code paths were hit, so it's quite possible that it may
have been my mistake. If so, I apologize. I didn't want to spend a lot
of time debugging and I'd had a similar experience with waitqueues in
the fall.

As Andres pointed out, we spent time merging our local approach into
your patch and testing that one. As a result of the combination, I
also did a few interface changes to ensure that callers use the
mem_event code correctly (i.e. calls to wake() are handled internally,
rather than relying on callers), and dropped some of the complexity of
accounting separately for foreign mappers.  With the waitqueue
failsafe in place, I don't think that's necessary.  Anyways, I tried
to preserve the spirit of your code, and would love to hear thoughts.

We'll be doing more testing today to ensure that we've properly
exercised all the different code paths (including wait queues).

Cheers,
-Adin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:52:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOoc-0007Sw-Pc; Thu, 12 Jan 2012 17:51:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RlOoa-0007Rv-Or
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:51:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326390578!48306661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10415 invoked from network); 12 Jan 2012 17:49:38 -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;
	12 Jan 2012 17:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979339"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:51: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, 12 Jan 2012 17:51:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RlOo2-0003WL-C4; Thu, 12 Jan 2012 17:51:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOo2-0002eh-BJ;
	Thu, 12 Jan 2012 17:51:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.7574.338642.706795@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:51:18 +0000
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F0EDF6E020000780006C14F@nat28.tlf.novell.com>
References: <4F0EDF6E020000780006C14F@nat28.tlf.novell.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] libxl: fix build with make prior to 3.81
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("[Xen-devel] [PATCH] libxl: fix build with make prior to 3.81"):
> Up to 3.80, make only supported simple 'else' constructs, which got
> violated by 24432:e0effa7c04f5.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.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 Thu Jan 12 17:52:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlOoc-0007Sw-Pc; Thu, 12 Jan 2012 17:51:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RlOoa-0007Rv-Or
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:51:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326390578!48306661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10415 invoked from network); 12 Jan 2012 17:49:38 -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;
	12 Jan 2012 17:49:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979339"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:51: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, 12 Jan 2012 17:51:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RlOo2-0003WL-C4; Thu, 12 Jan 2012 17:51:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOo2-0002eh-BJ;
	Thu, 12 Jan 2012 17:51:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.7574.338642.706795@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:51:18 +0000
To: "Jan Beulich" <JBeulich@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <4F0EDF6E020000780006C14F@nat28.tlf.novell.com>
References: <4F0EDF6E020000780006C14F@nat28.tlf.novell.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] libxl: fix build with make prior to 3.81
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jan Beulich writes ("[Xen-devel] [PATCH] libxl: fix build with make prior to 3.81"):
> Up to 3.80, make only supported simple 'else' constructs, which got
> violated by 24432:e0effa7c04f5.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.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 Thu Jan 12 17:57:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOtS-0007on-I8; Thu, 12 Jan 2012 17:56:54 +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 1RlOtR-0007oh-Ck
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:56:53 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326391006!10764903!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 20708 invoked from network); 12 Jan 2012 17:56:46 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 17:56:46 -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
	q0CHuisQ023298; Thu, 12 Jan 2012 17:56:45 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 q0CHuiZH019218; 
	Thu, 12 Jan 2012 12:56:44 -0500
Message-ID: <4F0F1EDA.7040807@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 12:56:42 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362598.17210.230.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326362598.17210.230.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/18] mini-os: avoid crash if no console is
 provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/2012 05:03 AM, Ian Campbell wrote:
> On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> 
> When/why does this happen? 

Initially, when I use a custom domain builder to create the xenstored
domain without a xenconsoled running yet (as xenconsoled needs xenstore).

> I guess it is because when starting the xenstore domain you cannot use
> xenstore to communicate with xenconsoled (and/or it isn't even running
> yet).
> 
> I wonder if there is a way we can do lazy-setup of the console for just
> the xenstore domain?

Xenstored will produce output on the hypervisor console if Xen is compiled
with debugging. If xenstored produces a lot of output, it can block on
waiting for xenconsoled, which might be blocking on xenstored - so I don't
think we want to hook it up to the console in the normal case, or at least
not the same xenconsoled that talks to domUs.
 
> Alternatively I seem to recall a little tool which Diego wrote to pull
> the console ring out of a domain directly as a debuging aid but that
> relies on us setting up a console ring and evtchn even if xenconsoled
> cannot be involved which makes this patch unnecessary.
> 
> Ian.

This runs into the same blocking problem if xenstored produces too much
output.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:57:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOtS-0007on-I8; Thu, 12 Jan 2012 17:56:54 +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 1RlOtR-0007oh-Ck
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:56:53 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326391006!10764903!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 20708 invoked from network); 12 Jan 2012 17:56:46 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-14.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 17:56:46 -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
	q0CHuisQ023298; Thu, 12 Jan 2012 17:56:45 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 q0CHuiZH019218; 
	Thu, 12 Jan 2012 12:56:44 -0500
Message-ID: <4F0F1EDA.7040807@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 12:56:42 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362598.17210.230.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326362598.17210.230.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/18] mini-os: avoid crash if no console is
 provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/2012 05:03 AM, Ian Campbell wrote:
> On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> 
> When/why does this happen? 

Initially, when I use a custom domain builder to create the xenstored
domain without a xenconsoled running yet (as xenconsoled needs xenstore).

> I guess it is because when starting the xenstore domain you cannot use
> xenstore to communicate with xenconsoled (and/or it isn't even running
> yet).
> 
> I wonder if there is a way we can do lazy-setup of the console for just
> the xenstore domain?

Xenstored will produce output on the hypervisor console if Xen is compiled
with debugging. If xenstored produces a lot of output, it can block on
waiting for xenconsoled, which might be blocking on xenstored - so I don't
think we want to hook it up to the console in the normal case, or at least
not the same xenconsoled that talks to domUs.
 
> Alternatively I seem to recall a little tool which Diego wrote to pull
> the console ring out of a domain directly as a debuging aid but that
> relies on us setting up a console ring and evtchn even if xenconsoled
> cannot be involved which makes this patch unnecessary.
> 
> Ian.

This runs into the same blocking problem if xenstored produces too much
output.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:57:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOtV-0007p2-Ug; Thu, 12 Jan 2012 17:56: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 1RlOtU-0007oi-EO
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:56:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326391010!10663278!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18426 invoked from network); 12 Jan 2012 17:56:50 -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;
	12 Jan 2012 17:56:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:56: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, 12 Jan 2012 17:56: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
	1RlOst-0003YL-NU; Thu, 12 Jan 2012 17:56:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOst-0002fQ-Mn;
	Thu, 12 Jan 2012 17:56:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.7875.692092.499697@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:56:19 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <94f71dded5ab5a31224b.1326376371@probook.site>
References: <94f71dded5ab5a31224b.1326376371@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit
	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

Olaf Hering writes ("[Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit build"):
> xenalyze: add missing casts to fix 64bit build
> 
> xenalyze.c: In function 'hvm_mmio_summary':
> xenalyze.c:3728: error: cast from pointer to integer of different size
...
> -    int reason=(int)data;
> +    int reason=(long)data;
...
>          reason=NONPF_MMIO_NPF;
> -        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
> +        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);

This is really quite ugly.  But I'll leave George to decide what
should be done ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 17:57:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 17: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 1RlOtV-0007p2-Ug; Thu, 12 Jan 2012 17:56: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 1RlOtU-0007oi-EO
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 17:56:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326391010!10663278!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18426 invoked from network); 12 Jan 2012 17:56:50 -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;
	12 Jan 2012 17:56:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 17:56: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, 12 Jan 2012 17:56: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
	1RlOst-0003YL-NU; Thu, 12 Jan 2012 17:56:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlOst-0002fQ-Mn;
	Thu, 12 Jan 2012 17:56:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20239.7875.692092.499697@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 17:56:19 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <94f71dded5ab5a31224b.1326376371@probook.site>
References: <94f71dded5ab5a31224b.1326376371@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit
	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

Olaf Hering writes ("[Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit build"):
> xenalyze: add missing casts to fix 64bit build
> 
> xenalyze.c: In function 'hvm_mmio_summary':
> xenalyze.c:3728: error: cast from pointer to integer of different size
...
> -    int reason=(int)data;
> +    int reason=(long)data;
...
>          reason=NONPF_MMIO_NPF;
> -        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
> +        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);

This is really quite ugly.  But I'll leave George to decide what
should be done ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 18:08:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 18:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlP3x-0008Em-4t; Thu, 12 Jan 2012 18:07:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@eu.citrix.com>) id 1RlP3v-0008Eh-IG
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 18:07:43 +0000
X-Env-Sender: Dave.Scott@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326391597!60741531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24616 invoked from network); 12 Jan 2012 18:06:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 18:06:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979743"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 18:07:41 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 12 Jan 2012
	18:07:41 +0000
From: Dave Scott <Dave.Scott@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Jan 2012 18:07:41 +0000
Thread-Topic: [Xen-devel] Driver domains and hotplug scripts, redux
Thread-Index: AczRSj3Csb17AgkVTZ6+x8rQcKmRqgACoTrA
Message-ID: <81A73678E76EA642801C8F2E4823AD21C4F901F5B2@LONPMAILBOX01.citrite.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<81A73678E76EA642801C8F2E4823AD21C4F901F5A9@LONPMAILBOX01.citrite.net>
	<20239.3903.482693.622400@mariner.uk.xensource.com>
In-Reply-To: <20239.3903.482693.622400@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: Roger Pau Monn? <roger.pau@entel.upc.edu>,
	"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] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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,

> Dave Scott writes ("Re: [Xen-devel] Driver domains and hotplug scripts,
> redux"):
> > FYI XCP/xapi is a heavy user of blktap2 and we use it like this:
> >
> > 0. user calls VM.start
> > 1. xapi invokes one of its "storage managers" (plugin scripts, one
> per
> >    storage type) telling it to "attach" a disk.
> > 2. the storage manager zones-in the relevant LUN and runs "tap-ctl"
> >    commands to create a block device. This is returned to xapi.
> > 3. xapi creates the block backend directory in xenstore with
> >    "params=<block device>".
> 

Ian Jackson replied:
> Thanks for the info.  Right, this is a model we should continue to
> support in libxl.  All the "management" is done outside libxl, and
> libxl is simply provided with the block device.

That would be great :-)

> ATM libxl only supports taking an actual device name in /dev, and TBH
> I can't really see that changing because some parts of libxl might
> need to actually open it in dom0.
> 
> I guess though it wouldn't be hard for xapi to provide a name in
> /dev.  It must surely make one for its own purposes.

I'm pretty sure our block devices end up in /dev -- so I think that would work for us.

Thanks,
Dave


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 18:08:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 18:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlP3x-0008Em-4t; Thu, 12 Jan 2012 18:07:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@eu.citrix.com>) id 1RlP3v-0008Eh-IG
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 18:07:43 +0000
X-Env-Sender: Dave.Scott@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326391597!60741531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDgwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24616 invoked from network); 12 Jan 2012 18:06:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 18:06:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,499,1320624000"; 
   d="scan'208";a="9979743"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	12 Jan 2012 18:07:41 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Thu, 12 Jan 2012
	18:07:41 +0000
From: Dave Scott <Dave.Scott@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Jan 2012 18:07:41 +0000
Thread-Topic: [Xen-devel] Driver domains and hotplug scripts, redux
Thread-Index: AczRSj3Csb17AgkVTZ6+x8rQcKmRqgACoTrA
Message-ID: <81A73678E76EA642801C8F2E4823AD21C4F901F5B2@LONPMAILBOX01.citrite.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<81A73678E76EA642801C8F2E4823AD21C4F901F5A9@LONPMAILBOX01.citrite.net>
	<20239.3903.482693.622400@mariner.uk.xensource.com>
In-Reply-To: <20239.3903.482693.622400@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: Roger Pau Monn? <roger.pau@entel.upc.edu>,
	"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] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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,

> Dave Scott writes ("Re: [Xen-devel] Driver domains and hotplug scripts,
> redux"):
> > FYI XCP/xapi is a heavy user of blktap2 and we use it like this:
> >
> > 0. user calls VM.start
> > 1. xapi invokes one of its "storage managers" (plugin scripts, one
> per
> >    storage type) telling it to "attach" a disk.
> > 2. the storage manager zones-in the relevant LUN and runs "tap-ctl"
> >    commands to create a block device. This is returned to xapi.
> > 3. xapi creates the block backend directory in xenstore with
> >    "params=<block device>".
> 

Ian Jackson replied:
> Thanks for the info.  Right, this is a model we should continue to
> support in libxl.  All the "management" is done outside libxl, and
> libxl is simply provided with the block device.

That would be great :-)

> ATM libxl only supports taking an actual device name in /dev, and TBH
> I can't really see that changing because some parts of libxl might
> need to actually open it in dom0.
> 
> I guess though it wouldn't be hard for xapi to provide a name in
> /dev.  It must surely make one for its own purposes.

I'm pretty sure our block devices end up in /dev -- so I think that would work for us.

Thanks,
Dave


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 18:15:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 18:15:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlPAz-0008Od-7U; Thu, 12 Jan 2012 18:15:01 +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 1RlPAx-0008OX-Nb
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 18:14:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326392091!10651695!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 12114 invoked from network); 12 Jan 2012 18:14:53 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 18:14:53 -0000
Received: by pbcc6 with SMTP id c6so4326710pbc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 10:14: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=+gRiEqiSacJR6JvFklFBbj5plusgesie46zht+SL2GI=;
	b=Uuoft4HzmA/HeulvP/Yu/earhOX8dOkuT5ewnDslZ2+MR04Xt7GWpRoLI+ob1i/XHA
	QfJI9rjzZcDTfgJJI/FG0A+FI1iLuK30Vz0IV+KmJi9gD8OOQIEjFW+TNpFTmjCQ6KyY
	qWkZtCqgFUz2TWnmc8diT2FqXzgD2jXa8XeLc=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr10028510pbc.77.1326392091533; Thu,
	12 Jan 2012 10:14:51 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Thu, 12 Jan 2012 10:14:51 -0800 (PST)
In-Reply-To: <20239.7574.338642.706795@mariner.uk.xensource.com>
References: <4F0EDF6E020000780006C14F@nat28.tlf.novell.com>
	<20239.7574.338642.706795@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 19:14:51 +0100
X-Google-Sender-Auth: jPLjzU7hXG3nh6aJUv2R3QfdIMs
Message-ID: <CAPLaKK612cZAWyxcEEyOkwdiOyx_yXkGA_9LuiPtiq4JB6dQHg@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>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix build with make prior to 3.81
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Jan Beulich writes ("[Xen-devel] [PATCH] libxl: fix build with make prior to 3.81"):
>> Up to 3.80, make only supported simple 'else' constructs, which got
>> violated by 24432:e0effa7c04f5.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Sorry, I was out of the office almost all day, thanks for the fix.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 18:15:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 18:15:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlPAz-0008Od-7U; Thu, 12 Jan 2012 18:15:01 +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 1RlPAx-0008OX-Nb
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 18:14:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326392091!10651695!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 12114 invoked from network); 12 Jan 2012 18:14:53 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 18:14:53 -0000
Received: by pbcc6 with SMTP id c6so4326710pbc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 10:14: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=+gRiEqiSacJR6JvFklFBbj5plusgesie46zht+SL2GI=;
	b=Uuoft4HzmA/HeulvP/Yu/earhOX8dOkuT5ewnDslZ2+MR04Xt7GWpRoLI+ob1i/XHA
	QfJI9rjzZcDTfgJJI/FG0A+FI1iLuK30Vz0IV+KmJi9gD8OOQIEjFW+TNpFTmjCQ6KyY
	qWkZtCqgFUz2TWnmc8diT2FqXzgD2jXa8XeLc=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr10028510pbc.77.1326392091533; Thu,
	12 Jan 2012 10:14:51 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Thu, 12 Jan 2012 10:14:51 -0800 (PST)
In-Reply-To: <20239.7574.338642.706795@mariner.uk.xensource.com>
References: <4F0EDF6E020000780006C14F@nat28.tlf.novell.com>
	<20239.7574.338642.706795@mariner.uk.xensource.com>
Date: Thu, 12 Jan 2012 19:14:51 +0100
X-Google-Sender-Auth: jPLjzU7hXG3nh6aJUv2R3QfdIMs
Message-ID: <CAPLaKK612cZAWyxcEEyOkwdiOyx_yXkGA_9LuiPtiq4JB6dQHg@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>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix build with make prior to 3.81
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Jan Beulich writes ("[Xen-devel] [PATCH] libxl: fix build with make prior to 3.81"):
>> Up to 3.80, make only supported simple 'else' constructs, which got
>> violated by 24432:e0effa7c04f5.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Sorry, I was out of the office almost all day, thanks for the fix.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 18:23:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 18:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlPIW-00006o-6U; Thu, 12 Jan 2012 18:22:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RlPIU-00006e-JM
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 18:22:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326392559!8595745!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTE1ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTE1ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14646 invoked from network); 12 Jan 2012 18:22:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 12 Jan 2012 18:22:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326392559; l=977;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=49wgLxMv6JrFroUywJ3cyxrQnfk=;
	b=LGvdNkhXeA+WQywgaO1RBS37c/4YSDewe4kPz1cy1a9EFFtMP+Wfrnpe1+uX61WnQb0
	8rwGHpXiQBvl/sfVkrdUkpf9b7FpAeYfhEdOC7R2DocmlfN5aFqLBd2ScqtnuYY61MUlj
	4ESQhS0Po6RiEUzG169wcOkeS8gJGSbZwzo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by post.strato.de (mrclete mo37) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 402141o0CGwBkR
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 19:22:24 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3F1D918637; Thu, 12 Jan 2012 19:22:23 +0100 (CET)
Date: Thu, 12 Jan 2012 19:22:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120112182222.GA12596@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] [PATCH] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a xenstore dm command to flush qemu's buffer cache.

qemu will just keep mapping pages and not release them, which causes problems
for the memory pager (since the page is mapped, it won't get paged out). When
the pager has trouble finding a page to page out, it asks qemu to flush its
buffer, which releases all the page mappings. This makes it possible to find
pages to swap out agian.

Signed-off-by: Patrick Colp <Patrick.Colp@citrix.com>
Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 ioemu-remote/xenstore.c |    3 +++
 1 file changed, 3 insertions(+)

--- ioemu-remote/xenstore.c
+++ ioemu-remote/xenstore.c
@@ -927,6 +927,9 @@ static void xenstore_process_dm_command_
         do_pci_add(par);
         free(par);
 #endif
+    } else if (!strncmp(command, "flush-cache", len)) {
+        fprintf(logfile, "dm-command: flush caches\n");
+        qemu_invalidate_map_cache();
     } else {
         fprintf(logfile, "dm-command: unknown command\"%*s\"\n", len, command);
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 18:23:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 18:23:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlPIW-00006o-6U; Thu, 12 Jan 2012 18:22:48 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RlPIU-00006e-JM
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 18:22:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326392559!8595745!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTE1ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTE1ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14646 invoked from network); 12 Jan 2012 18:22:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 12 Jan 2012 18:22:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326392559; l=977;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=49wgLxMv6JrFroUywJ3cyxrQnfk=;
	b=LGvdNkhXeA+WQywgaO1RBS37c/4YSDewe4kPz1cy1a9EFFtMP+Wfrnpe1+uX61WnQb0
	8rwGHpXiQBvl/sfVkrdUkpf9b7FpAeYfhEdOC7R2DocmlfN5aFqLBd2ScqtnuYY61MUlj
	4ESQhS0Po6RiEUzG169wcOkeS8gJGSbZwzo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by post.strato.de (mrclete mo37) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 402141o0CGwBkR
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 19:22:24 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3F1D918637; Thu, 12 Jan 2012 19:22:23 +0100 (CET)
Date: Thu, 12 Jan 2012 19:22:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120112182222.GA12596@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] [PATCH] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a xenstore dm command to flush qemu's buffer cache.

qemu will just keep mapping pages and not release them, which causes problems
for the memory pager (since the page is mapped, it won't get paged out). When
the pager has trouble finding a page to page out, it asks qemu to flush its
buffer, which releases all the page mappings. This makes it possible to find
pages to swap out agian.

Signed-off-by: Patrick Colp <Patrick.Colp@citrix.com>
Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 ioemu-remote/xenstore.c |    3 +++
 1 file changed, 3 insertions(+)

--- ioemu-remote/xenstore.c
+++ ioemu-remote/xenstore.c
@@ -927,6 +927,9 @@ static void xenstore_process_dm_command_
         do_pci_add(par);
         free(par);
 #endif
+    } else if (!strncmp(command, "flush-cache", len)) {
+        fprintf(logfile, "dm-command: flush caches\n");
+        qemu_invalidate_map_cache();
     } else {
         fprintf(logfile, "dm-command: unknown command\"%*s\"\n", len, command);
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 18:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 18:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlPQE-0000L8-Bp; Thu, 12 Jan 2012 18:30:46 +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 1RlPQD-0000L3-4Z
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 18:30:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326393038!10799975!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjY1NDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjY1NDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7439 invoked from network); 12 Jan 2012 18:30:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 12 Jan 2012 18:30:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326393038; l=734;
	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=xNiI9nfo8z7suNyE4SlHMW0PQog=;
	b=kS2KuMrB119CdVyMzHfiB293e7RNiyuGA2OFRRbbcnukGRgvPiPnPsrmmlmIMscezFa
	pS8YTq5AbiNX/TV2SO73EmnDcTvWexltnKfXoHcEbxEh1mbXkVsjIxDCcgP7qhuR4cB5i
	zGk/nEgLl/gw9GUQ7VzjbcewBozjL4zEu1A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (klopstock mo39) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id q0748eo0CHI9hZ
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 19:30:35 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C282218637; Thu, 12 Jan 2012 19:30:34 +0100 (CET)
Date: Thu, 12 Jan 2012 19:30:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120112183034.GA13035@aepfle.de>
References: <20120112182222.GA12596@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120112182222.GA12596@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: Re: [Xen-devel] [PATCH] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, Olaf Hering wrote:

> Add support for a xenstore dm command to flush qemu's buffer cache.

Something like this is most likely also needed in mainline qemu.
My search in the qemu.org git web UI did not show any of the commands in
ioemu-remote, so its not clear how to forward port this change. 

Olaf


> --- ioemu-remote/xenstore.c
> +++ ioemu-remote/xenstore.c
> @@ -927,6 +927,9 @@ static void xenstore_process_dm_command_
>          do_pci_add(par);
>          free(par);
>  #endif
> +    } else if (!strncmp(command, "flush-cache", len)) {
> +        fprintf(logfile, "dm-command: flush caches\n");
> +        qemu_invalidate_map_cache();
>      } else {
>          fprintf(logfile, "dm-command: unknown command\"%*s\"\n", len, command);
>      }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 18:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 18:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlPQE-0000L8-Bp; Thu, 12 Jan 2012 18:30:46 +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 1RlPQD-0000L3-4Z
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 18:30:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326393038!10799975!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjY1NDc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjY1NDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7439 invoked from network); 12 Jan 2012 18:30:39 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 12 Jan 2012 18:30:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326393038; l=734;
	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=xNiI9nfo8z7suNyE4SlHMW0PQog=;
	b=kS2KuMrB119CdVyMzHfiB293e7RNiyuGA2OFRRbbcnukGRgvPiPnPsrmmlmIMscezFa
	pS8YTq5AbiNX/TV2SO73EmnDcTvWexltnKfXoHcEbxEh1mbXkVsjIxDCcgP7qhuR4cB5i
	zGk/nEgLl/gw9GUQ7VzjbcewBozjL4zEu1A=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-110-122.pools.arcor-ip.net [88.65.110.122])
	by smtp.strato.de (klopstock mo39) (RZmta 27.3 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id q0748eo0CHI9hZ
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 19:30:35 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C282218637; Thu, 12 Jan 2012 19:30:34 +0100 (CET)
Date: Thu, 12 Jan 2012 19:30:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120112183034.GA13035@aepfle.de>
References: <20120112182222.GA12596@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120112182222.GA12596@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: Re: [Xen-devel] [PATCH] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, Olaf Hering wrote:

> Add support for a xenstore dm command to flush qemu's buffer cache.

Something like this is most likely also needed in mainline qemu.
My search in the qemu.org git web UI did not show any of the commands in
ioemu-remote, so its not clear how to forward port this change. 

Olaf


> --- ioemu-remote/xenstore.c
> +++ ioemu-remote/xenstore.c
> @@ -927,6 +927,9 @@ static void xenstore_process_dm_command_
>          do_pci_add(par);
>          free(par);
>  #endif
> +    } else if (!strncmp(command, "flush-cache", len)) {
> +        fprintf(logfile, "dm-command: flush caches\n");
> +        qemu_invalidate_map_cache();
>      } else {
>          fprintf(logfile, "dm-command: unknown command\"%*s\"\n", len, command);
>      }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 19:23:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 19:23:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlQEg-0000gV-4J; Thu, 12 Jan 2012 19:22:54 +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 1RlQEe-0000gQ-Q9
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 19:22:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326396144!55462528!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjA0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13510 invoked from network); 12 Jan 2012 19:22:24 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-13.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 19:22:24 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id CDA5C76C069;
	Thu, 12 Jan 2012 11:22:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Yc4353tnr2yov9q51Kymnr3nbU2bokgFeaJzgH6vA8Bv
	o43O4sHJUyQt67aJRf8Wyh/6cgQjqs/qIMhYS92YbRXQXYSKDSKhkd7FYeMURExb
	hUklctJGdFD08CdSXz8v8SU4zZnYMMrFsDAdzfEogEb8RZBh3+T0Dp9lVBs86lk=
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=3Q0G4nHWsuEDrohxYPTvtDLMbgo=; b=J0Y1Gauc
	vo5eA6aFRBsGru6nK/uvfTc6pLvknLj372+djfpbvepwFtqnGagaXVmB+jjkU/J+
	VBGB3k+VrYwWkkQXGvKmpZooXvcEg0X4pHkPhSOERmEvy7Unxf2YbdGPU9wbta2x
	fd1dayjb4qJu+6uFY/k6uq5TKUUinqxPPhg=
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 2405976C072; 
	Thu, 12 Jan 2012 11:22:50 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 12 Jan 2012 11:22:50 -0800
Message-ID: <35df1eba46857095cbc2a68fc2c9c075.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <B28ADCC9-CC5A-479D-8A7C-38FF4DB78A55@gridcentric.ca>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
	<63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
	<20120112135945.GA8324@aepfle.de>
	<cfc86d79380e4f7f4ba88de9794877c8.squirrel@webmail.lagarcavilla.org>
	<CAAJKtqpkOaNrV=apZrteWD1Oh=gWx-wJu4pWeJD+DEuj-0ghgw@mail.gmail.com>
	<B28ADCC9-CC5A-479D-8A7C-38FF4DB78A55@gridcentric.ca>
Date: Thu, 12 Jan 2012 11:22:50 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: adin@gridcentric.ca
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	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


>
> I didn't spend a lot of time diagnosing exactly what was going wrong
> with the patch.  I did have some local patches applied (in the process
> of being submitted to the list) and some debug changes to ensure that
> the correct code paths were hit, so it's quite possible that it may
> have been my mistake. If so, I apologize. I didn't want to spend a lot
> of time debugging and I'd had a similar experience with waitqueues in
> the fall.
>
> As Andres pointed out, we spent time merging our local approach into
> your patch and testing that one. As a result of the combination, I
> also did a few interface changes to ensure that callers use the
> mem_event code correctly (i.e. calls to wake() are handled internally,
> rather than relying on callers), and dropped some of the complexity of
> accounting separately for foreign mappers.  With the waitqueue
> failsafe in place, I don't think that's necessary.  Anyways, I tried
> to preserve the spirit of your code, and would love to hear thoughts.
>
> We'll be doing more testing today to ensure that we've properly
> exercised all the different code paths (including wait queues).

It works.

1. Fire off 1GB HVM with PV drivers. Enable balloon
2. Fire off xenpaging
3. xenstore write memory/target-tot_pages 524288
(wait until everything is paged)
4. xenstore write memory/target 524288

No crashes, neither domain nor host nor xenpaging. Phew ;)

Olaf, let us know if you have further concerns, afaict the patch is ready
for showtime.

Andres
>
> Cheers,
> -Adin
>>>> What we did is take this patch, amalgamate it with some bits from our
>>>> ring
>>>> management approach. We're ready to submit that, along with a
>>>> description
>>>> of how we test it. It works for us, and it involves wait queue's for
>>>> corner cases.
>>>
>>> Now if the patch you just sent out uses wait queues as well, and using
>>> wait queues causes sudden host reboots for reasons not yet known, how
>>> is
>>> your patch any better other that the reboots dont appear to happen
>>> anymore?
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 19:23:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 19:23:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlQEg-0000gV-4J; Thu, 12 Jan 2012 19:22:54 +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 1RlQEe-0000gQ-Q9
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 19:22:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326396144!55462528!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjA0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13510 invoked from network); 12 Jan 2012 19:22:24 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.74) by server-13.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 19:22:24 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id CDA5C76C069;
	Thu, 12 Jan 2012 11:22:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=Yc4353tnr2yov9q51Kymnr3nbU2bokgFeaJzgH6vA8Bv
	o43O4sHJUyQt67aJRf8Wyh/6cgQjqs/qIMhYS92YbRXQXYSKDSKhkd7FYeMURExb
	hUklctJGdFD08CdSXz8v8SU4zZnYMMrFsDAdzfEogEb8RZBh3+T0Dp9lVBs86lk=
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=3Q0G4nHWsuEDrohxYPTvtDLMbgo=; b=J0Y1Gauc
	vo5eA6aFRBsGru6nK/uvfTc6pLvknLj372+djfpbvepwFtqnGagaXVmB+jjkU/J+
	VBGB3k+VrYwWkkQXGvKmpZooXvcEg0X4pHkPhSOERmEvy7Unxf2YbdGPU9wbta2x
	fd1dayjb4qJu+6uFY/k6uq5TKUUinqxPPhg=
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 2405976C072; 
	Thu, 12 Jan 2012 11:22:50 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 12 Jan 2012 11:22:50 -0800
Message-ID: <35df1eba46857095cbc2a68fc2c9c075.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <B28ADCC9-CC5A-479D-8A7C-38FF4DB78A55@gridcentric.ca>
References: <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
	<63e491f50b2d490e00741aaffbc6df80.squirrel@webmail.lagarcavilla.org>
	<20120112135945.GA8324@aepfle.de>
	<cfc86d79380e4f7f4ba88de9794877c8.squirrel@webmail.lagarcavilla.org>
	<CAAJKtqpkOaNrV=apZrteWD1Oh=gWx-wJu4pWeJD+DEuj-0ghgw@mail.gmail.com>
	<B28ADCC9-CC5A-479D-8A7C-38FF4DB78A55@gridcentric.ca>
Date: Thu, 12 Jan 2012 11:22:50 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: adin@gridcentric.ca
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	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


>
> I didn't spend a lot of time diagnosing exactly what was going wrong
> with the patch.  I did have some local patches applied (in the process
> of being submitted to the list) and some debug changes to ensure that
> the correct code paths were hit, so it's quite possible that it may
> have been my mistake. If so, I apologize. I didn't want to spend a lot
> of time debugging and I'd had a similar experience with waitqueues in
> the fall.
>
> As Andres pointed out, we spent time merging our local approach into
> your patch and testing that one. As a result of the combination, I
> also did a few interface changes to ensure that callers use the
> mem_event code correctly (i.e. calls to wake() are handled internally,
> rather than relying on callers), and dropped some of the complexity of
> accounting separately for foreign mappers.  With the waitqueue
> failsafe in place, I don't think that's necessary.  Anyways, I tried
> to preserve the spirit of your code, and would love to hear thoughts.
>
> We'll be doing more testing today to ensure that we've properly
> exercised all the different code paths (including wait queues).

It works.

1. Fire off 1GB HVM with PV drivers. Enable balloon
2. Fire off xenpaging
3. xenstore write memory/target-tot_pages 524288
(wait until everything is paged)
4. xenstore write memory/target 524288

No crashes, neither domain nor host nor xenpaging. Phew ;)

Olaf, let us know if you have further concerns, afaict the patch is ready
for showtime.

Andres
>
> Cheers,
> -Adin
>>>> What we did is take this patch, amalgamate it with some bits from our
>>>> ring
>>>> management approach. We're ready to submit that, along with a
>>>> description
>>>> of how we test it. It works for us, and it involves wait queue's for
>>>> corner cases.
>>>
>>> Now if the patch you just sent out uses wait queues as well, and using
>>> wait queues causes sudden host reboots for reasons not yet known, how
>>> is
>>> your patch any better other that the reboots dont appear to happen
>>> anymore?
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 20:27:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 20:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlREy-00011M-2U; Thu, 12 Jan 2012 20:27: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 1RlREw-00011E-Cy
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 20:27:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326400027!7056500!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTczNzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11636 invoked from network); 12 Jan 2012 20:27:07 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 20:27:07 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 638FA458088;
	Thu, 12 Jan 2012 12:27:06 -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=NrBbWFicBp7OTuQxa3X3EL
	CATNCIRY8fZtqZedgiQAnk8DLrgJxP6y1baqrlkcg+7Wbq7j1ryX9iakSrW+n3LG
	A9g1bNjh4rFVgk2Kdi1dMtGeqXmompPRk9+BP7iU2hLnKB8KKELlUZ/z+wUHLNLa
	lKpWQuulL92HGH0OOyU6Y=
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=5lIrskBWEo74
	dqZCbvMAjTBoREY=; b=UPrMhHncrBl3pLa0rJC02gy0/xOdYVhV9m3BFP2+Zrqb
	IWkFXG/ZmpTMX6X6dBeFHyTAOeAwKOWvXYMYvVx3oUltHVacj1eopFbQEk7AI0CV
	WT+dUpRZy4eXUxkEis0sKq3hM57EAEeSjQAtXpZUWn59AVW+A4bwpku2Cy7UFeY=
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 C78A6458086; 
	Thu, 12 Jan 2012 12:27:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: fa59531b6daa3b377b92cd211bc862ad34873e37
Message-Id: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Jan 2012 15:31:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] EPT: refine epte_present test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m-ept.c |  25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)


The current test for a present ept entry checks for a permission bit
to be set.

While this is valid in contexts in which we want to know whether an entry
will fault, it is not correct when it comes to testing whether an entry is
valid. Specifically, in the ept_change_entry_type_page function which is
used to set entries to the log dirty type.

In combination with a p2m access type like n or n2rwx, log dirty will not be
set for ept entries for which it should.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r e7028b298fe3 -r fa59531b6daa xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -39,7 +39,8 @@
 #define atomic_write_ept_entry(__pepte, __epte)                     \
     write_atomic(&(__pepte)->epte, (__epte).epte)
 
-#define is_epte_present(ept_entry)      ((ept_entry)->epte & 0x7)
+#define epte_permissions(ept_entry)     ((ept_entry)->epte & 0x7)
+#define is_epte_present(ept_entry)      (!!(epte_permissions(ept_entry)))
 #define is_epte_superpage(ept_entry)    ((ept_entry)->sp)
 
 /* Non-ept "lock-and-check" wrapper */
@@ -139,6 +140,26 @@ static void ept_p2m_type_to_flags(ept_en
     
 }
 
+static inline bool_t is_epte_valid(ept_entry_t *e)
+{
+    ept_entry_t rights = { .epte = 0 };
+
+    /* Not valid if empty */
+    if (e->epte == 0) return 0;
+
+    /* Not valid if mfn not valid */
+    if ( !mfn_valid(e->mfn) ) return 0;
+
+    /* Not valid if rights different from those of 
+     * its p2m type and access combination */
+    ept_p2m_type_to_flags(&rights, e->sa_p2mt, e->access);
+    if ( epte_permissions(&rights) != epte_permissions(e) )
+        return 0;
+
+    return 1;
+}
+
+
 #define GUEST_TABLE_MAP_FAILED  0
 #define GUEST_TABLE_NORMAL_PAGE 1
 #define GUEST_TABLE_SUPER_PAGE  2
@@ -777,7 +798,7 @@ static void ept_change_entry_type_page(m
 
     for ( int i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
     {
-        if ( !is_epte_present(epte + i) )
+        if ( !is_epte_valid(epte + i) )
             continue;
 
         if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 20:27:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 20:27:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlREy-00011M-2U; Thu, 12 Jan 2012 20:27: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 1RlREw-00011E-Cy
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 20:27:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326400027!7056500!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTczNzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11636 invoked from network); 12 Jan 2012 20:27:07 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 20:27:07 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 638FA458088;
	Thu, 12 Jan 2012 12:27:06 -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=NrBbWFicBp7OTuQxa3X3EL
	CATNCIRY8fZtqZedgiQAnk8DLrgJxP6y1baqrlkcg+7Wbq7j1ryX9iakSrW+n3LG
	A9g1bNjh4rFVgk2Kdi1dMtGeqXmompPRk9+BP7iU2hLnKB8KKELlUZ/z+wUHLNLa
	lKpWQuulL92HGH0OOyU6Y=
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=5lIrskBWEo74
	dqZCbvMAjTBoREY=; b=UPrMhHncrBl3pLa0rJC02gy0/xOdYVhV9m3BFP2+Zrqb
	IWkFXG/ZmpTMX6X6dBeFHyTAOeAwKOWvXYMYvVx3oUltHVacj1eopFbQEk7AI0CV
	WT+dUpRZy4eXUxkEis0sKq3hM57EAEeSjQAtXpZUWn59AVW+A4bwpku2Cy7UFeY=
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 C78A6458086; 
	Thu, 12 Jan 2012 12:27:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: fa59531b6daa3b377b92cd211bc862ad34873e37
Message-Id: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 12 Jan 2012 15:31:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] EPT: refine epte_present test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m-ept.c |  25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)


The current test for a present ept entry checks for a permission bit
to be set.

While this is valid in contexts in which we want to know whether an entry
will fault, it is not correct when it comes to testing whether an entry is
valid. Specifically, in the ept_change_entry_type_page function which is
used to set entries to the log dirty type.

In combination with a p2m access type like n or n2rwx, log dirty will not be
set for ept entries for which it should.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r e7028b298fe3 -r fa59531b6daa xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -39,7 +39,8 @@
 #define atomic_write_ept_entry(__pepte, __epte)                     \
     write_atomic(&(__pepte)->epte, (__epte).epte)
 
-#define is_epte_present(ept_entry)      ((ept_entry)->epte & 0x7)
+#define epte_permissions(ept_entry)     ((ept_entry)->epte & 0x7)
+#define is_epte_present(ept_entry)      (!!(epte_permissions(ept_entry)))
 #define is_epte_superpage(ept_entry)    ((ept_entry)->sp)
 
 /* Non-ept "lock-and-check" wrapper */
@@ -139,6 +140,26 @@ static void ept_p2m_type_to_flags(ept_en
     
 }
 
+static inline bool_t is_epte_valid(ept_entry_t *e)
+{
+    ept_entry_t rights = { .epte = 0 };
+
+    /* Not valid if empty */
+    if (e->epte == 0) return 0;
+
+    /* Not valid if mfn not valid */
+    if ( !mfn_valid(e->mfn) ) return 0;
+
+    /* Not valid if rights different from those of 
+     * its p2m type and access combination */
+    ept_p2m_type_to_flags(&rights, e->sa_p2mt, e->access);
+    if ( epte_permissions(&rights) != epte_permissions(e) )
+        return 0;
+
+    return 1;
+}
+
+
 #define GUEST_TABLE_MAP_FAILED  0
 #define GUEST_TABLE_NORMAL_PAGE 1
 #define GUEST_TABLE_SUPER_PAGE  2
@@ -777,7 +798,7 @@ static void ept_change_entry_type_page(m
 
     for ( int i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
     {
-        if ( !is_epte_present(epte + i) )
+        if ( !is_epte_valid(epte + i) )
             continue;
 
         if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 21:02:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 21: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 1RlRm4-0001e5-GG; Thu, 12 Jan 2012 21:01:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbuday@gmail.com>) id 1RlRm3-0001da-0n
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 21:01:27 +0000
X-Env-Sender: gbuday@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326402079!8925606!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ADVANCE_FEE_1,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24996 invoked from network); 12 Jan 2012 21:01:21 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 21:01:21 -0000
Received: by obbwc7 with SMTP id wc7so3171000obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 13:01: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=ZTZRcTOQpUcugzcWFc8vsfShwungiNlZH8V92vLAbT0=;
	b=lJCBJlconzVl4ySm8Zk0CmPSHS/cOTjFI2DZO/CvCKuBPONbBB8T1cY49UjydRL5ww
	FtBfxEQ4MCVBgV8zG6IFdrE8UsEnEYGjfGnmU6hrMFItEHQ1rl6hRQFqsXEyofYvno9S
	Jc9SYF5GdLO7zg76dKXPCJypcOClnLsflVWa0=
MIME-Version: 1.0
Received: by 10.50.183.199 with SMTP id eo7mr6283607igc.5.1326402079363; Thu,
	12 Jan 2012 13:01:19 -0800 (PST)
Received: by 10.231.161.203 with HTTP; Thu, 12 Jan 2012 13:01:19 -0800 (PST)
Date: Thu, 12 Jan 2012 22:01:19 +0100
Message-ID: <CA+3iOzkUYeNkh3=rwk7-qgwsZk9NomvGLYRdkH2JrOW2j0b1wg@mail.gmail.com>
From: Gergely Buday <gbuday@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] documentation improvement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I have read in the Xen user's manual that I should contact the
maintainers here. Could you please lift your hands, and then I would
send my suggestions in private mail.

- Gergely

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 21:02:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 21: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 1RlRm4-0001e5-GG; Thu, 12 Jan 2012 21:01:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gbuday@gmail.com>) id 1RlRm3-0001da-0n
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 21:01:27 +0000
X-Env-Sender: gbuday@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326402079!8925606!1
X-Originating-IP: [209.85.214.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ADVANCE_FEE_1,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24996 invoked from network); 12 Jan 2012 21:01:21 -0000
Received: from mail-tul01m020-f171.google.com (HELO
	mail-tul01m020-f171.google.com) (209.85.214.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	12 Jan 2012 21:01:21 -0000
Received: by obbwc7 with SMTP id wc7so3171000obb.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 13:01: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=ZTZRcTOQpUcugzcWFc8vsfShwungiNlZH8V92vLAbT0=;
	b=lJCBJlconzVl4ySm8Zk0CmPSHS/cOTjFI2DZO/CvCKuBPONbBB8T1cY49UjydRL5ww
	FtBfxEQ4MCVBgV8zG6IFdrE8UsEnEYGjfGnmU6hrMFItEHQ1rl6hRQFqsXEyofYvno9S
	Jc9SYF5GdLO7zg76dKXPCJypcOClnLsflVWa0=
MIME-Version: 1.0
Received: by 10.50.183.199 with SMTP id eo7mr6283607igc.5.1326402079363; Thu,
	12 Jan 2012 13:01:19 -0800 (PST)
Received: by 10.231.161.203 with HTTP; Thu, 12 Jan 2012 13:01:19 -0800 (PST)
Date: Thu, 12 Jan 2012 22:01:19 +0100
Message-ID: <CA+3iOzkUYeNkh3=rwk7-qgwsZk9NomvGLYRdkH2JrOW2j0b1wg@mail.gmail.com>
From: Gergely Buday <gbuday@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] documentation improvement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I have read in the Xen user's manual that I should contact the
maintainers here. Could you please lift your hands, and then I would
send my suggestions in private mail.

- Gergely

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 21:19:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 21:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlS3Y-00028t-5d; Thu, 12 Jan 2012 21:19:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1RlS3W-00028o-Ay
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 21:19:30 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326403142!55470869!1
X-Originating-IP: [72.251.202.114]
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 31300 invoked from network); 12 Jan 2012 21:19:02 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-13.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 21:19:02 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 948C21F880A4
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 16:19:28 -0500 (EST)
Received: (qmail 16328 invoked by uid 108); 12 Jan 2012 16:19:28 -0500
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@131.193.36.93)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 12 Jan 2012 16:19:28 -0500
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 2DD7E4E7D67; Thu, 12 Jan 2012 15:19:28 -0600 (CST)
Date: Thu, 12 Jan 2012 15:19:28 -0600
From: "W. Michael Petullo" <mike@flyn.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120112211927.GA13328@imp.flyn.org>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] Questions about attacks on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have some questions about attacks on Xen. I am preparing a paper for
an operating system we have built on top of Xen and I want to ensure
we have certain facts straight.  Among the things I have read include
"Xen and the Art of Virtualization" and the XOAR paper.

First, what power does Dom0 have? Of course I know that Dom0 manages
the other domains and has direct access to hardware. I know that Dom0
can not directly access the Xen hypervisor code in memory (except in
the case of attacks using DMA on IOMMU-less systems). But what about
Dom0 accessing DomU memory once the domain is running?

For isolation, our operating system encrypts all network traffic and disk
I/O. We have also postulated that we could do the same of keyboard/display
I/O. We can use vTPM to ensure trusted initialization. Are there other
attack vectors other than Dom0 handling memory destined to or from an I/O
device? Could Dom0 violate our DomU by directly accessing its memory? Are
there any facilities in Xen 4 for restricting this? Where could I read
more about this?

Thank you. I appreciate any responses, especially recommended reading.

-- 
Mike

:wq

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 21:19:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 21:19:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlS3Y-00028t-5d; Thu, 12 Jan 2012 21:19:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1RlS3W-00028o-Ay
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 21:19:30 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326403142!55470869!1
X-Originating-IP: [72.251.202.114]
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 31300 invoked from network); 12 Jan 2012 21:19:02 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-13.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 21:19:02 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 948C21F880A4
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 16:19:28 -0500 (EST)
Received: (qmail 16328 invoked by uid 108); 12 Jan 2012 16:19:28 -0500
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@131.193.36.93)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 12 Jan 2012 16:19:28 -0500
Received: by imp.flyn.org (Postfix, from userid 1101)
	id 2DD7E4E7D67; Thu, 12 Jan 2012 15:19:28 -0600 (CST)
Date: Thu, 12 Jan 2012 15:19:28 -0600
From: "W. Michael Petullo" <mike@flyn.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120112211927.GA13328@imp.flyn.org>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] Questions about attacks on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have some questions about attacks on Xen. I am preparing a paper for
an operating system we have built on top of Xen and I want to ensure
we have certain facts straight.  Among the things I have read include
"Xen and the Art of Virtualization" and the XOAR paper.

First, what power does Dom0 have? Of course I know that Dom0 manages
the other domains and has direct access to hardware. I know that Dom0
can not directly access the Xen hypervisor code in memory (except in
the case of attacks using DMA on IOMMU-less systems). But what about
Dom0 accessing DomU memory once the domain is running?

For isolation, our operating system encrypts all network traffic and disk
I/O. We have also postulated that we could do the same of keyboard/display
I/O. We can use vTPM to ensure trusted initialization. Are there other
attack vectors other than Dom0 handling memory destined to or from an I/O
device? Could Dom0 violate our DomU by directly accessing its memory? Are
there any facilities in Xen 4 for restricting this? Where could I read
more about this?

Thank you. I appreciate any responses, especially recommended reading.

-- 
Mike

:wq

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 21:23:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 21:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlS6i-0002FN-RE; Thu, 12 Jan 2012 21:22: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 1RlS6i-0002FI-5Y
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 21:22:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326403301!60757575!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=ADVANCE_FEE_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23234 invoked from network); 12 Jan 2012 21:21:42 -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; 12 Jan 2012 21:21: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
	q0CLMiWZ025363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 12 Jan 2012 16:22:44 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0CLMi6R025361;
	Thu, 12 Jan 2012 16:22:44 -0500
Date: Thu, 12 Jan 2012 17:22:44 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Gergely Buday <gbuday@gmail.com>
Message-ID: <20120112212244.GA25315@andromeda.dapyr.net>
References: <CA+3iOzkUYeNkh3=rwk7-qgwsZk9NomvGLYRdkH2JrOW2j0b1wg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CA+3iOzkUYeNkh3=rwk7-qgwsZk9NomvGLYRdkH2JrOW2j0b1wg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] documentation improvement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 10:01:19PM +0100, Gergely Buday wrote:
> Hi,
> 
> I have read in the Xen user's manual that I should contact the
> maintainers here. Could you please lift your hands, and then I would
> send my suggestions in private mail.

Could you just send them to this mailing list? Preferrable as a patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 21:23:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 21:23:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlS6i-0002FN-RE; Thu, 12 Jan 2012 21:22: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 1RlS6i-0002FI-5Y
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 21:22:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326403301!60757575!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=ADVANCE_FEE_1
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23234 invoked from network); 12 Jan 2012 21:21:42 -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; 12 Jan 2012 21:21: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
	q0CLMiWZ025363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 12 Jan 2012 16:22:44 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0CLMi6R025361;
	Thu, 12 Jan 2012 16:22:44 -0500
Date: Thu, 12 Jan 2012 17:22:44 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Gergely Buday <gbuday@gmail.com>
Message-ID: <20120112212244.GA25315@andromeda.dapyr.net>
References: <CA+3iOzkUYeNkh3=rwk7-qgwsZk9NomvGLYRdkH2JrOW2j0b1wg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CA+3iOzkUYeNkh3=rwk7-qgwsZk9NomvGLYRdkH2JrOW2j0b1wg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] documentation improvement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 10:01:19PM +0100, Gergely Buday wrote:
> Hi,
> 
> I have read in the Xen user's manual that I should contact the
> maintainers here. Could you please lift your hands, and then I would
> send my suggestions in private mail.

Could you just send them to this mailing list? Preferrable as a patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 22:06:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 22:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlSmZ-0002uq-Vw; Thu, 12 Jan 2012 22:06:03 +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 1RlSmY-0002ul-Ae
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 22:06:02 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326405941!62229760!1
X-Originating-IP: [188.40.164.121]
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 2599 invoked from network); 12 Jan 2012 22:05:41 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jan 2012 22:05:41 -0000
Received: from 25-72-ftth.onsneteindhoven.nl ([88.159.72.25]:57979
	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 1RlSkL-0002lP-Sf; Thu, 12 Jan 2012 23:03:45 +0100
Date: Thu, 12 Jan 2012 23:06:01 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1442969761.20120112230601@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120110215533.GA21862@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.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

Hello Konrad,

Tuesday, January 10, 2012, 10:55:33 PM, you wrote:

> On Mon, Dec 19, 2011 at 10:56:09AM -0400, Konrad Rzeszutek Wilk wrote:
>> 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.

> Good news is I am able to reproduce this with my 32-bit NIC with 3.2 domU:

> [  771.896140] SWIOTLB is 11% full
> [  776.896116] 0 [e1000 0000:00:00.0] bounce: from:222028(slow:0)to:2 map:222037 unmap:227220 sync:0
> [  776.896126] 1 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:5188 map:5188 unmap:0 sync:0
> [  776.896133] 3 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:1 map:1 unmap:0 sync:0

> but interestingly enough, if I boot the guest as the first one I do not get these bounce
> requests. I will shortly bootup a Xen-O-Linux kernel and see if I get these same
> numbers.


I started to expiriment some more with what i encountered.

On dom0 i was seeing that my r8169 ethernet controllers where using bounce buffering with the dump-swiotlb module.
It was showing "12% full".
Checking in sysfs shows:
serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
32
serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
32

If i remember correctly wasn't the allocation for dom0 changed to be to the top of memory instead of low .. somewhere between 2.6.32 and 3.0 ?
Could that change cause the need for all devices to need bounce buffering  and could it therefore explain some people seeing more cpu usage for dom0 ?

I have forced my r8169 to use 64bits dma mask (using use_dac=1)
serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
32
serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
64

This results in dump-swiotlb reporting:

[ 1265.616106] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
[ 1265.625043] SWIOTLB is 0% full
[ 1270.626085] 0 [r8169 0000:08:00.0] bounce: from:6(slow:0)to:0 map:0 unmap:0 sync:12
[ 1270.635024] SWIOTLB is 0% full
[ 1275.635091] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
[ 1275.644261] SWIOTLB is 0% full
[ 1280.654097] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10



So it has changed from 12% to 0%, although it still reports something about bouncing ? or am i mis interpreting stuff ?


Another thing i was wondering about, couldn't the hypervisor offer a small window in 32bit addressable mem to all (or only when pci passthrough is used) domU's to be used for DMA ?

(oh yes, i haven't got i clue what i'm talking about ... so it probably make no sense at all :-) )


--
Sander




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 22:06:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 22:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlSmZ-0002uq-Vw; Thu, 12 Jan 2012 22:06:03 +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 1RlSmY-0002ul-Ae
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 22:06:02 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326405941!62229760!1
X-Originating-IP: [188.40.164.121]
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 2599 invoked from network); 12 Jan 2012 22:05:41 -0000
Received: from static.121.164.40.188.clients.your-server.de (HELO
	smtp.eikelenboom.it) (188.40.164.121)
	by server-15.tower-27.messagelabs.com with AES256-SHA encrypted SMTP;
	12 Jan 2012 22:05:41 -0000
Received: from 25-72-ftth.onsneteindhoven.nl ([88.159.72.25]:57979
	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 1RlSkL-0002lP-Sf; Thu, 12 Jan 2012 23:03:45 +0100
Date: Thu, 12 Jan 2012 23:06:01 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1442969761.20120112230601@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120110215533.GA21862@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.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

Hello Konrad,

Tuesday, January 10, 2012, 10:55:33 PM, you wrote:

> On Mon, Dec 19, 2011 at 10:56:09AM -0400, Konrad Rzeszutek Wilk wrote:
>> 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.

> Good news is I am able to reproduce this with my 32-bit NIC with 3.2 domU:

> [  771.896140] SWIOTLB is 11% full
> [  776.896116] 0 [e1000 0000:00:00.0] bounce: from:222028(slow:0)to:2 map:222037 unmap:227220 sync:0
> [  776.896126] 1 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:5188 map:5188 unmap:0 sync:0
> [  776.896133] 3 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:1 map:1 unmap:0 sync:0

> but interestingly enough, if I boot the guest as the first one I do not get these bounce
> requests. I will shortly bootup a Xen-O-Linux kernel and see if I get these same
> numbers.


I started to expiriment some more with what i encountered.

On dom0 i was seeing that my r8169 ethernet controllers where using bounce buffering with the dump-swiotlb module.
It was showing "12% full".
Checking in sysfs shows:
serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
32
serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
32

If i remember correctly wasn't the allocation for dom0 changed to be to the top of memory instead of low .. somewhere between 2.6.32 and 3.0 ?
Could that change cause the need for all devices to need bounce buffering  and could it therefore explain some people seeing more cpu usage for dom0 ?

I have forced my r8169 to use 64bits dma mask (using use_dac=1)
serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
32
serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
64

This results in dump-swiotlb reporting:

[ 1265.616106] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
[ 1265.625043] SWIOTLB is 0% full
[ 1270.626085] 0 [r8169 0000:08:00.0] bounce: from:6(slow:0)to:0 map:0 unmap:0 sync:12
[ 1270.635024] SWIOTLB is 0% full
[ 1275.635091] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
[ 1275.644261] SWIOTLB is 0% full
[ 1280.654097] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10



So it has changed from 12% to 0%, although it still reports something about bouncing ? or am i mis interpreting stuff ?


Another thing i was wondering about, couldn't the hypervisor offer a small window in 32bit addressable mem to all (or only when pci passthrough is used) domU's to be used for DMA ?

(oh yes, i haven't got i clue what i'm talking about ... so it probably make no sense at all :-) )


--
Sander




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 22:46:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 22:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlTPc-0003Qe-0J; Thu, 12 Jan 2012 22:46:24 +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 1RlTPZ-0003QL-QA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 22:46:22 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326408375!10820739!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 3269 invoked from network); 12 Jan 2012 22:46:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 22:46:15 -0000
Received: from [86.26.8.249] (account d.faggioli@sssup.it HELO [10.0.1.31])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74466868; Thu, 12 Jan 2012 23:46:14 +0100
Message-ID: <1326408359.4494.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 12 Jan 2012 22:45:59 +0000
In-Reply-To: <1326357477.17210.208.camel@zakaz.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss> <1326304919.12973.5.camel@Abyss>
	<1326357477.17210.208.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] libxl: Align examples with current
	code.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0604569034711644881=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0604569034711644881==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-meXGlBsmCDHbazc0lx0r"


--=-meXGlBsmCDHbazc0lx0r
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-01-12 at 08:37 +0000, Ian Campbell wrote:=20
> > diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm
> > --- a/tools/examples/xmexample.hvm	Wed Jan 11 17:28:53 2012 +0000
> > +++ b/tools/examples/xmexample.hvm	Wed Jan 11 17:32:34 2012 +0000
>=20
> These are the xend/xm examples which you didn't change. Or is it that
> the current examples don't actually reflect the current xend syntax
> either?
>=20
Mmm... I see. No, you're right, they are different things and these
files shouldn't be touched. For next round, I'll just drop this patch.

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)



--=-meXGlBsmCDHbazc0lx0r
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)

iEYEABECAAYFAk8PYqcACgkQk4XaBE3IOsRhyACcDG9lH4xrKTQsZc4EOG1SorMV
L2EAn1K7xpHQS/51rmWnXsNyRz3BAVhy
=BCmb
-----END PGP SIGNATURE-----

--=-meXGlBsmCDHbazc0lx0r--



--===============0604569034711644881==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0604569034711644881==--



From xen-devel-bounces@lists.xensource.com Thu Jan 12 22:46:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 22:46:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlTPc-0003Qe-0J; Thu, 12 Jan 2012 22:46:24 +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 1RlTPZ-0003QL-QA
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 22:46:22 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326408375!10820739!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 3269 invoked from network); 12 Jan 2012 22:46:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 22:46:15 -0000
Received: from [86.26.8.249] (account d.faggioli@sssup.it HELO [10.0.1.31])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74466868; Thu, 12 Jan 2012 23:46:14 +0100
Message-ID: <1326408359.4494.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 12 Jan 2012 22:45:59 +0000
In-Reply-To: <1326357477.17210.208.camel@zakaz.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss> <1326304919.12973.5.camel@Abyss>
	<1326357477.17210.208.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] libxl: Align examples with current
	code.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0604569034711644881=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0604569034711644881==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-meXGlBsmCDHbazc0lx0r"


--=-meXGlBsmCDHbazc0lx0r
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-01-12 at 08:37 +0000, Ian Campbell wrote:=20
> > diff -r 897ea4d3c2d7 tools/examples/xmexample.hvm
> > --- a/tools/examples/xmexample.hvm	Wed Jan 11 17:28:53 2012 +0000
> > +++ b/tools/examples/xmexample.hvm	Wed Jan 11 17:32:34 2012 +0000
>=20
> These are the xend/xm examples which you didn't change. Or is it that
> the current examples don't actually reflect the current xend syntax
> either?
>=20
Mmm... I see. No, you're right, they are different things and these
files shouldn't be touched. For next round, I'll just drop this patch.

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)



--=-meXGlBsmCDHbazc0lx0r
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)

iEYEABECAAYFAk8PYqcACgkQk4XaBE3IOsRhyACcDG9lH4xrKTQsZc4EOG1SorMV
L2EAn1K7xpHQS/51rmWnXsNyRz3BAVhy
=BCmb
-----END PGP SIGNATURE-----

--=-meXGlBsmCDHbazc0lx0r--



--===============0604569034711644881==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0604569034711644881==--



From xen-devel-bounces@lists.xensource.com Thu Jan 12 22:57:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 22:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlTZf-0003fh-Ki; Thu, 12 Jan 2012 22:56:47 +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 1RlTZe-0003fW-2j
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 22:56:46 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326408999!8244829!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 18983 invoked from network); 12 Jan 2012 22:56:39 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 22:56:39 -0000
Received: from [86.26.8.249] (account d.faggioli@sssup.it HELO [10.0.1.31])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74466941; Thu, 12 Jan 2012 23:56:38 +0100
Message-ID: <1326408997.4494.11.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 12 Jan 2012 22:56:37 +0000
In-Reply-To: <1326357782.17210.213.camel@zakaz.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss> <1326304831.12973.3.camel@Abyss>
	<1326357782.17210.213.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============6947405300042611861=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6947405300042611861==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-JkfLuu4wt0O9PdWyLobS"


--=-JkfLuu4wt0O9PdWyLobS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-01-12 at 08:43 +0000, Ian Campbell wrote:=20
> > diff -r 9ce68a4036b1 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c	Wed Jan 11 17:38:04 2012 +0000
> > +++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:40:45 2012 +0000
> > @@ -78,6 +78,8 @@ int libxl_init_build_info(libxl_ctx *ctx
> >      memset(b_info, '\0', sizeof(*b_info));
> >      b_info->max_vcpus =3D 1;
> >      b_info->cur_vcpus =3D 1;
> > +    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
> > +        return ERROR_NOMEM;
>=20
> Should probably set all here since that is the best default?
>=20
Having this set to "none" here simplifies a bit the code when we came to
config file parsing (if I set it to "any CPU" here, I'll have to reset
to "none" before parsing). Also, default is exactly what you're
suggesting already, as I set the map to "any CPU" if no "cpus" config
option is found.

Anyway, I guess I can do as you suggest if you really think it's
better. :-)

> > +static void print_bitmap(uint8_t *map, int maplen, FILE *stream);
>
> [..]=20
>  =20
> > +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);
>=20
> Again, maybe just reorder the functions?
>=20
Ok, fine, will do that.

> >  static void parse_config_data(const char *configfile_filename_report,
> >                                const char *configfile_data,
> >                                int configfile_len,
> > @@ -661,6 +674,13 @@ static void parse_config_data(const char
> >      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
> >          b_info->max_vcpus =3D l;
> > =20
> > +    if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
>=20
> The syntax supported here is different to that in a cpupool cfg? (see
> main_cpupoolcreate) Perhaps they should be similar?
>=20
It is different, and that was intentional. What I wanted, was the syntax
to be exactly the same of `xl vcpu-pin', which is the command line
equivalent of this option, much more than cpupool-*. If you want, I
think I can easily enable list-like CPU specification as in cpupool
config file so that _both_ syntax are allowed. What do you think?


> > +        char *buf2 =3D strdup(buf);
> > +        vcpupin_parse(buf2, &b_info->cpumap);
> > +    } else {
> > +        memset(b_info->cpumap.map, -1, b_info->cpumap.size);
>=20
> This could do with a helper function in libxl_utils.h.
>=20
Ok.

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)



--=-JkfLuu4wt0O9PdWyLobS
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)

iEYEABECAAYFAk8PZSUACgkQk4XaBE3IOsTVuQCfXRm4wnPMHS2qu8+CEmIcZizv
V0QAn3UhAvQ3PUo+XUSZhjQM3DaE/S7y
=uYou
-----END PGP SIGNATURE-----

--=-JkfLuu4wt0O9PdWyLobS--



--===============6947405300042611861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6947405300042611861==--



From xen-devel-bounces@lists.xensource.com Thu Jan 12 22:57:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 22:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlTZf-0003fh-Ki; Thu, 12 Jan 2012 22:56:47 +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 1RlTZe-0003fW-2j
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 22:56:46 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326408999!8244829!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 18983 invoked from network); 12 Jan 2012 22:56:39 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 22:56:39 -0000
Received: from [86.26.8.249] (account d.faggioli@sssup.it HELO [10.0.1.31])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74466941; Thu, 12 Jan 2012 23:56:38 +0100
Message-ID: <1326408997.4494.11.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Thu, 12 Jan 2012 22:56:37 +0000
In-Reply-To: <1326357782.17210.213.camel@zakaz.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss> <1326304831.12973.3.camel@Abyss>
	<1326357782.17210.213.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============6947405300042611861=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6947405300042611861==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-JkfLuu4wt0O9PdWyLobS"


--=-JkfLuu4wt0O9PdWyLobS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-01-12 at 08:43 +0000, Ian Campbell wrote:=20
> > diff -r 9ce68a4036b1 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c	Wed Jan 11 17:38:04 2012 +0000
> > +++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:40:45 2012 +0000
> > @@ -78,6 +78,8 @@ int libxl_init_build_info(libxl_ctx *ctx
> >      memset(b_info, '\0', sizeof(*b_info));
> >      b_info->max_vcpus =3D 1;
> >      b_info->cur_vcpus =3D 1;
> > +    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
> > +        return ERROR_NOMEM;
>=20
> Should probably set all here since that is the best default?
>=20
Having this set to "none" here simplifies a bit the code when we came to
config file parsing (if I set it to "any CPU" here, I'll have to reset
to "none" before parsing). Also, default is exactly what you're
suggesting already, as I set the map to "any CPU" if no "cpus" config
option is found.

Anyway, I guess I can do as you suggest if you really think it's
better. :-)

> > +static void print_bitmap(uint8_t *map, int maplen, FILE *stream);
>
> [..]=20
>  =20
> > +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);
>=20
> Again, maybe just reorder the functions?
>=20
Ok, fine, will do that.

> >  static void parse_config_data(const char *configfile_filename_report,
> >                                const char *configfile_data,
> >                                int configfile_len,
> > @@ -661,6 +674,13 @@ static void parse_config_data(const char
> >      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
> >          b_info->max_vcpus =3D l;
> > =20
> > +    if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
>=20
> The syntax supported here is different to that in a cpupool cfg? (see
> main_cpupoolcreate) Perhaps they should be similar?
>=20
It is different, and that was intentional. What I wanted, was the syntax
to be exactly the same of `xl vcpu-pin', which is the command line
equivalent of this option, much more than cpupool-*. If you want, I
think I can easily enable list-like CPU specification as in cpupool
config file so that _both_ syntax are allowed. What do you think?


> > +        char *buf2 =3D strdup(buf);
> > +        vcpupin_parse(buf2, &b_info->cpumap);
> > +    } else {
> > +        memset(b_info->cpumap.map, -1, b_info->cpumap.size);
>=20
> This could do with a helper function in libxl_utils.h.
>=20
Ok.

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)



--=-JkfLuu4wt0O9PdWyLobS
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)

iEYEABECAAYFAk8PZSUACgkQk4XaBE3IOsTVuQCfXRm4wnPMHS2qu8+CEmIcZizv
V0QAn3UhAvQ3PUo+XUSZhjQM3DaE/S7y
=uYou
-----END PGP SIGNATURE-----

--=-JkfLuu4wt0O9PdWyLobS--



--===============6947405300042611861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6947405300042611861==--



From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlToq-0003tA-6E; Thu, 12 Jan 2012 23:12:28 +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 1RlToo-0003t4-F7
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:12:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326409939!10760839!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 10305 invoked from network); 12 Jan 2012 23:12:19 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:12:19 -0000
Received: from [86.26.8.249] (account d.faggioli@sssup.it HELO [10.0.1.31])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74467085; Fri, 13 Jan 2012 00:12:18 +0100
Message-ID: <1326409937.4494.22.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Jan 2012 23:12:17 +0000
In-Reply-To: <20239.6553.110187.528841@mariner.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0028480868016067256=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0028480868016067256==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-MspcEc8rB+z4/L+eH8DX"


--=-MspcEc8rB+z4/L+eH8DX
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-01-12 at 17:34 +0000, Ian Jackson wrote:=20
> Dario Faggioli writes ("[Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs sp=
ecification for vcpu-pin."):
> > Allow for "^<cpuid>" syntax while specifying the pCPUs list
> > during a vcpu-pin. This enables doing the following:
> >=20
> >  xl vcpu-pin 1 1 0-4,^2
> ...
> > +    if (strcmp(cpu, "all")) {
> > +        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok=
(NULL, ","), ++i) {
>=20
> OMG you used strtok.  strtok is not thread-safe. =20
>
Well, that's not properly me, is it that?

hg annotate tools/libxl/xl_cmdimpl.c
...
21247:     if (strcmp(cpu, "all")) {=20
21247:         for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strt=
ok(NULL, ","), ++i) {
21247:             cpuida =3D strtoul(toka, &endptr, 10);
21247:             if (toka =3D=3D endptr) {
...

> strtok_r is but
> still modifies its input string - hence your need to strdup.  If you
> do want to do it this way IMO the strdup should be in vcpupin_parse
> which should take a const char*.  Are you sure this is the right
> approach to parsing this ?
>=20
Again, I know that's probably not an alibi, but that's not my code! :-P
What I did is just move this from the body of vcpupin() to an helper
function, and try to add as _less_ thing as I can to support a slightly
improved syntax.

That being said, if you think I should rewrite the parsing from scratch,
I can think about it, just wanted to clarify my position. :-)

> <record type=3D"broken">
> Your patch 2 has a number of overly long lines.
> </record>
>=20
I know. What I usually do is try to comply with the coding style I find
in a file. Thus, if there are, from time to time, lines overcoming
col80, I tend to relax such constrain a bit (especially when I change
one of those lines). Anyway, for v2 I'll double check that, as I don't
like long lines either. :-)

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)



--=-MspcEc8rB+z4/L+eH8DX
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)

iEYEABECAAYFAk8PaNEACgkQk4XaBE3IOsS9IwCfRZSAUK0G+5+lcwgnxjO7kQzQ
mTkAoITn2T2ubXHjI2a1Niakc9UBk4kO
=Cx6n
-----END PGP SIGNATURE-----

--=-MspcEc8rB+z4/L+eH8DX--



--===============0028480868016067256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0028480868016067256==--



From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:12:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23:12:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlToq-0003tA-6E; Thu, 12 Jan 2012 23:12:28 +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 1RlToo-0003t4-F7
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:12:26 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326409939!10760839!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 10305 invoked from network); 12 Jan 2012 23:12:19 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:12:19 -0000
Received: from [86.26.8.249] (account d.faggioli@sssup.it HELO [10.0.1.31])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74467085; Fri, 13 Jan 2012 00:12:18 +0100
Message-ID: <1326409937.4494.22.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 12 Jan 2012 23:12:17 +0000
In-Reply-To: <20239.6553.110187.528841@mariner.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0028480868016067256=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0028480868016067256==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-MspcEc8rB+z4/L+eH8DX"


--=-MspcEc8rB+z4/L+eH8DX
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-01-12 at 17:34 +0000, Ian Jackson wrote:=20
> Dario Faggioli writes ("[Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs sp=
ecification for vcpu-pin."):
> > Allow for "^<cpuid>" syntax while specifying the pCPUs list
> > during a vcpu-pin. This enables doing the following:
> >=20
> >  xl vcpu-pin 1 1 0-4,^2
> ...
> > +    if (strcmp(cpu, "all")) {
> > +        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok=
(NULL, ","), ++i) {
>=20
> OMG you used strtok.  strtok is not thread-safe. =20
>
Well, that's not properly me, is it that?

hg annotate tools/libxl/xl_cmdimpl.c
...
21247:     if (strcmp(cpu, "all")) {=20
21247:         for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strt=
ok(NULL, ","), ++i) {
21247:             cpuida =3D strtoul(toka, &endptr, 10);
21247:             if (toka =3D=3D endptr) {
...

> strtok_r is but
> still modifies its input string - hence your need to strdup.  If you
> do want to do it this way IMO the strdup should be in vcpupin_parse
> which should take a const char*.  Are you sure this is the right
> approach to parsing this ?
>=20
Again, I know that's probably not an alibi, but that's not my code! :-P
What I did is just move this from the body of vcpupin() to an helper
function, and try to add as _less_ thing as I can to support a slightly
improved syntax.

That being said, if you think I should rewrite the parsing from scratch,
I can think about it, just wanted to clarify my position. :-)

> <record type=3D"broken">
> Your patch 2 has a number of overly long lines.
> </record>
>=20
I know. What I usually do is try to comply with the coding style I find
in a file. Thus, if there are, from time to time, lines overcoming
col80, I tend to relax such constrain a bit (especially when I change
one of those lines). Anyway, for v2 I'll double check that, as I don't
like long lines either. :-)

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)



--=-MspcEc8rB+z4/L+eH8DX
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)

iEYEABECAAYFAk8PaNEACgkQk4XaBE3IOsS9IwCfRZSAUK0G+5+lcwgnxjO7kQzQ
mTkAoITn2T2ubXHjI2a1Niakc9UBk4kO
=Cx6n
-----END PGP SIGNATURE-----

--=-MspcEc8rB+z4/L+eH8DX--



--===============0028480868016067256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0028480868016067256==--



From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:33:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlU8d-00044L-3c; Thu, 12 Jan 2012 23:32:55 +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 1RlU8b-00044G-Cj
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:32:53 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326411056!59481861!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 22069 invoked from network); 12 Jan 2012 23:30:57 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 23:30:57 -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
	q0CNWnvx003394; Thu, 12 Jan 2012 23:32:50 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0CNWnck006887; 
	Thu, 12 Jan 2012 18:32:49 -0500
Message-ID: <4F0F6D9F.1030806@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 18:32:47 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362273.17210.225.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326362273.17210.225.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2012 04:57 AM, Ian Campbell wrote:
> On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
>> This patch series allows xenstored to run in a stub domian started by
>> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
>> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html
> 
> BTW did you come across any patches for stub-oxenstored while you were
> doing this? I thought there had been such at some point in the past.
> 
> Ian.
> 

I haven't searched for similar patches to oxenstored. If they exist,
they would probably need similar changes to use grants instead of
map_foreign_range and support for the bootstrapping. Since I am not
fluent in ocaml, I will leave this for other people to implement :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:33:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlU8d-00044L-3c; Thu, 12 Jan 2012 23:32:55 +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 1RlU8b-00044G-Cj
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:32:53 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326411056!59481861!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 22069 invoked from network); 12 Jan 2012 23:30:57 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 23:30:57 -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
	q0CNWnvx003394; Thu, 12 Jan 2012 23:32:50 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0CNWnck006887; 
	Thu, 12 Jan 2012 18:32:49 -0500
Message-ID: <4F0F6D9F.1030806@tycho.nsa.gov>
Date: Thu, 12 Jan 2012 18:32:47 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362273.17210.225.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326362273.17210.225.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/12/2012 04:57 AM, Ian Campbell wrote:
> On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
>> This patch series allows xenstored to run in a stub domian started by
>> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
>> http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.html
> 
> BTW did you come across any patches for stub-oxenstored while you were
> doing this? I thought there had been such at some point in the past.
> 
> Ian.
> 

I haven't searched for similar patches to oxenstored. If they exist,
they would probably need similar changes to use grants instead of
map_foreign_range and support for the bootstrapping. Since I am not
fluent in ocaml, I will leave this for other people to implement :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUC1-0004O5-0T; Thu, 12 Jan 2012 23:36:25 +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 1RlUBz-0004Kv-Sk
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326411341!59993957!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 25793 invoked from network); 12 Jan 2012 23:35:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-9.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 23:35: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
	q0CNaLvW008747
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:21 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 q0CNaL7W007147; 
	Thu, 12 Jan 2012 18:36:21 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:36:13 -0500
Message-Id: <1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in stub
	domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds an ioctl to the /dev/xen/xenbus_backend device allowing the
xenbus backend to be started after the kernel has booted. This is
intended to allow dom0 to start another domain to run xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_comms.c       |    6 ++++
 drivers/xen/xenbus/xenbus_comms.h       |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   44 +++++++++++++++++++++++++++++++
 include/xen/grant_table.h               |    2 +
 include/xen/xenbus_dev.h                |   14 ++++++++++
 5 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 2eff7a6..52fe7ad 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -234,3 +234,9 @@ int xb_init_comms(void)
 
 	return 0;
 }
+
+void xb_deinit_comms(void)
+{
+	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
+	xenbus_irq = 0;
+}
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index 6e42800..c8abd3b 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -35,6 +35,7 @@
 
 int xs_init(void);
 int xb_init_comms(void);
+void xb_deinit_comms(void);
 
 /* Low level routines. */
 int xb_write(const void *data, unsigned len);
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index 3d3be78..854315c 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -8,7 +8,11 @@
 
 #include <xen/xen.h>
 #include <xen/page.h>
+#include <xen/xenbus.h>
 #include <xen/xenbus_dev.h>
+#include <xen/grant_table.h>
+#include <xen/events.h>
+#include <asm/xen/hypervisor.h>
 
 #include "xenbus_comms.h"
 
@@ -22,6 +26,43 @@ static int xenbus_backend_open(struct inode *inode, struct file *filp)
 	return nonseekable_open(inode, filp);
 }
 
+static long xenbus_alloc(void __user * data)
+{
+	struct ioctl_xenbus_alloc op;
+	struct evtchn_alloc_unbound arg;
+	int err;
+
+	if (copy_from_user(&op, data, sizeof(op)))
+		return -EFAULT;
+
+	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, op.dom,
+			virt_to_mfn(xen_store_interface), 0 /* writable */);
+
+	arg.dom = DOMID_SELF;
+	arg.remote_dom = op.dom;
+
+	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
+	if (err)
+		return err;
+
+	op.port = arg.port;
+	op.grant_ref = GNTTAB_RESERVED_XENSTORE;
+
+	xs_suspend();
+
+	if (xen_store_evtchn > 0)
+		xb_deinit_comms();
+
+	xen_store_evtchn = arg.port;
+
+	xs_resume();
+
+	if (copy_to_user(data, &op, sizeof(op)))
+		return -EFAULT;
+
+	return 0;
+}
+
 static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
 {
 	if (!capable(CAP_SYS_ADMIN))
@@ -33,6 +74,9 @@ static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned l
 				return xen_store_evtchn;
 			return -ENODEV;
 
+		case IOCTL_XENBUS_ALLOC:
+			return xenbus_alloc((void __user *)data);
+
 		default:
 			return -ENOTTY;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 15f8a00..11e27c3 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -46,6 +46,8 @@
 
 #include <xen/features.h>
 
+#define GNTTAB_RESERVED_XENSTORE 1
+
 /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
 #define NR_GRANT_FRAMES 4
 
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
index ac5f0fe..b107be9 100644
--- a/include/xen/xenbus_dev.h
+++ b/include/xen/xenbus_dev.h
@@ -38,4 +38,18 @@
 #define IOCTL_XENBUS_BACKEND_EVTCHN			\
 	_IOC(_IOC_NONE, 'B', 0, 0)
 
+#define IOCTL_XENBUS_ALLOC				\
+	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
+struct ioctl_xenbus_alloc {
+	/* IN */
+	/* The domain ID (must exist) for xenstore */
+	uint16_t dom;
+	uint16_t pad;
+	/* OUT */
+	/* The port allocated for xenbus communication */
+	uint32_t port;
+	/* Always set to GNTTAB_RESERVED_XENSTORE */
+	uint32_t grant_ref;
+};
+
 #endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBt-0004DZ-Az; Thu, 12 Jan 2012 23:36:17 +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 1RlUBq-0004AY-4j
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326411367!8922226!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 26290 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-11.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa6vx003862
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dY007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:27 -0500
Message-Id: <1326411330-7915-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/18] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   13 ++++++++++++-
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index e51f2ad..4ec63f1 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1771,6 +1771,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1784,6 +1785,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1847,6 +1849,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index aca2149..648eb1d 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -593,8 +593,19 @@ void restore_existing_connections(void)
 }
 
 #ifdef __MINIOS__
-static inline int dom0_init(void) 
+static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUC1-0004O5-0T; Thu, 12 Jan 2012 23:36:25 +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 1RlUBz-0004Kv-Sk
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326411341!59993957!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 25793 invoked from network); 12 Jan 2012 23:35:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-9.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 23:35: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
	q0CNaLvW008747
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:21 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 q0CNaL7W007147; 
	Thu, 12 Jan 2012 18:36:21 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:36:13 -0500
Message-Id: <1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in stub
	domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds an ioctl to the /dev/xen/xenbus_backend device allowing the
xenbus backend to be started after the kernel has booted. This is
intended to allow dom0 to start another domain to run xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_comms.c       |    6 ++++
 drivers/xen/xenbus/xenbus_comms.h       |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   44 +++++++++++++++++++++++++++++++
 include/xen/grant_table.h               |    2 +
 include/xen/xenbus_dev.h                |   14 ++++++++++
 5 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 2eff7a6..52fe7ad 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -234,3 +234,9 @@ int xb_init_comms(void)
 
 	return 0;
 }
+
+void xb_deinit_comms(void)
+{
+	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
+	xenbus_irq = 0;
+}
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index 6e42800..c8abd3b 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -35,6 +35,7 @@
 
 int xs_init(void);
 int xb_init_comms(void);
+void xb_deinit_comms(void);
 
 /* Low level routines. */
 int xb_write(const void *data, unsigned len);
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index 3d3be78..854315c 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -8,7 +8,11 @@
 
 #include <xen/xen.h>
 #include <xen/page.h>
+#include <xen/xenbus.h>
 #include <xen/xenbus_dev.h>
+#include <xen/grant_table.h>
+#include <xen/events.h>
+#include <asm/xen/hypervisor.h>
 
 #include "xenbus_comms.h"
 
@@ -22,6 +26,43 @@ static int xenbus_backend_open(struct inode *inode, struct file *filp)
 	return nonseekable_open(inode, filp);
 }
 
+static long xenbus_alloc(void __user * data)
+{
+	struct ioctl_xenbus_alloc op;
+	struct evtchn_alloc_unbound arg;
+	int err;
+
+	if (copy_from_user(&op, data, sizeof(op)))
+		return -EFAULT;
+
+	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, op.dom,
+			virt_to_mfn(xen_store_interface), 0 /* writable */);
+
+	arg.dom = DOMID_SELF;
+	arg.remote_dom = op.dom;
+
+	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
+	if (err)
+		return err;
+
+	op.port = arg.port;
+	op.grant_ref = GNTTAB_RESERVED_XENSTORE;
+
+	xs_suspend();
+
+	if (xen_store_evtchn > 0)
+		xb_deinit_comms();
+
+	xen_store_evtchn = arg.port;
+
+	xs_resume();
+
+	if (copy_to_user(data, &op, sizeof(op)))
+		return -EFAULT;
+
+	return 0;
+}
+
 static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
 {
 	if (!capable(CAP_SYS_ADMIN))
@@ -33,6 +74,9 @@ static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned l
 				return xen_store_evtchn;
 			return -ENODEV;
 
+		case IOCTL_XENBUS_ALLOC:
+			return xenbus_alloc((void __user *)data);
+
 		default:
 			return -ENOTTY;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 15f8a00..11e27c3 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -46,6 +46,8 @@
 
 #include <xen/features.h>
 
+#define GNTTAB_RESERVED_XENSTORE 1
+
 /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
 #define NR_GRANT_FRAMES 4
 
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
index ac5f0fe..b107be9 100644
--- a/include/xen/xenbus_dev.h
+++ b/include/xen/xenbus_dev.h
@@ -38,4 +38,18 @@
 #define IOCTL_XENBUS_BACKEND_EVTCHN			\
 	_IOC(_IOC_NONE, 'B', 0, 0)
 
+#define IOCTL_XENBUS_ALLOC				\
+	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
+struct ioctl_xenbus_alloc {
+	/* IN */
+	/* The domain ID (must exist) for xenstore */
+	uint16_t dom;
+	uint16_t pad;
+	/* OUT */
+	/* The port allocated for xenbus communication */
+	uint32_t port;
+	/* Always set to GNTTAB_RESERVED_XENSTORE */
+	uint32_t grant_ref;
+};
+
 #endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBt-0004DZ-Az; Thu, 12 Jan 2012 23:36:17 +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 1RlUBq-0004AY-4j
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326411367!8922226!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 26290 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-11.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa6vx003862
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dY007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:27 -0500
Message-Id: <1326411330-7915-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/18] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   13 ++++++++++++-
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index e51f2ad..4ec63f1 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1771,6 +1771,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1784,6 +1785,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1847,6 +1849,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index aca2149..648eb1d 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -593,8 +593,19 @@ void restore_existing_connections(void)
 }
 
 #ifdef __MINIOS__
-static inline int dom0_init(void) 
+static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBy-0004JK-Co; Thu, 12 Jan 2012 23:36:22 +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 1RlUBt-0004Az-66
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326411368!8140115!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 3600 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vW008707; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dL007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:14 -0500
Message-Id: <1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   63 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 151 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 8b34769..8f3426f 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -747,6 +747,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52a63ef..f1a7ede 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -116,7 +116,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -492,7 +492,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -633,7 +633,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -690,7 +690,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d6ae09b..97c7d53 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -994,6 +994,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..e507481 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,65 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++) {
+        if (global_virq_handlers[virq] == d) {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count) {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1219,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..79b266f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -287,7 +287,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -314,7 +314,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 7e5ad7b..d505ee9 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -24,11 +24,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..c89c6ed 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, int virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, int virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..59db86d 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, int virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..a1feb8d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, int virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBy-0004JK-Co; Thu, 12 Jan 2012 23:36:22 +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 1RlUBt-0004Az-66
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326411368!8140115!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 3600 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vW008707; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dL007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:14 -0500
Message-Id: <1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   63 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 151 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 8b34769..8f3426f 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -747,6 +747,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52a63ef..f1a7ede 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -116,7 +116,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -492,7 +492,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -633,7 +633,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -690,7 +690,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d6ae09b..97c7d53 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -994,6 +994,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..e507481 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,65 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++) {
+        if (global_virq_handlers[virq] == d) {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count) {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1219,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..79b266f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -287,7 +287,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -314,7 +314,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 7e5ad7b..d505ee9 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -24,11 +24,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..c89c6ed 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, int virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, int virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..59db86d 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, int virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..a1feb8d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, int virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBt-0004Dv-Ow; Thu, 12 Jan 2012 23:36:17 +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 1RlUBq-0004Aa-79
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326411366!10157343!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 3082 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa5vx003852
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dM007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:15 -0500
Message-Id: <1326411330-7915-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/18] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 97c7d53..e1bbc9a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 59db86d..f94f616 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBn-0004Av-NJ; Thu, 12 Jan 2012 23:36:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlUBl-0004Af-Hq
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326411321!50026405!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 10709 invoked from network); 12 Jan 2012 23:35:21 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 23:35:21 -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
	q0CNa6vW008719
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5db007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:30 -0500
Message-Id: <1326411330-7915-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/18] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   55 +++++++++++++++++
 tools/xenstore/Makefile                  |    9 ++-
 tools/xenstore/init-xenstore-domain.c    |   96 ++++++++++++++++++++++++++++++
 3 files changed, 158 insertions(+), 2 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..b107be9
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,55 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_ALLOC				\
+	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
+struct ioctl_xenbus_alloc {
+	/* IN */
+	/* The domain ID (must exist) for xenstore */
+	uint16_t dom;
+	uint16_t pad;
+	/* OUT */
+	/* The port allocated for xenbus communication */
+	uint32_t port;
+	/* Always set to GNTTAB_RESERVED_XENSTORE */
+	uint32_t grant_ref;
+};
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 3a061d6..9b411a5 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
@@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..30f6c9b
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,96 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+	struct ioctl_xenbus_alloc alloc;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	alloc.dom = domid;
+	rv = ioctl(xs_fd, IOCTL_XENBUS_ALLOC, &alloc);
+	if (rv) return rv;
+	snprintf(cmdline, 512, "--event %d", alloc.port);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBs-0004CX-25; Thu, 12 Jan 2012 23:36:16 +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 1RlUBp-0004AX-Sl
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326411366!10786465!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 11208 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-15.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa5vW008708
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dO007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:17 -0500
Message-Id: <1326411330-7915-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/18] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a4725fe..5e39595 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -73,6 +73,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -104,9 +105,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 288c03c..97ead08 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -219,9 +219,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBt-0004Dv-Ow; Thu, 12 Jan 2012 23:36:17 +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 1RlUBq-0004Aa-79
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326411366!10157343!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 3082 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa5vx003852
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dM007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:15 -0500
Message-Id: <1326411330-7915-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/18] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 97c7d53..e1bbc9a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 59db86d..f94f616 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBr-0004CG-M6; Thu, 12 Jan 2012 23:36:15 +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 1RlUBp-0004AV-OZ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326411366!1971366!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 12921 invoked from network); 12 Jan 2012 23:36:06 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-9.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa5vW008703
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dJ007010
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:12 -0500
Message-Id: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH v2 00/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC
   (the new device path uses 'B' not 'X' as the base so the ioctl number
   does not match; otherwise, should be compatible).

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

----

[PATCH 01/18] xen: reinstate previously unused hypercall
[PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/18] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 04/18] xen: Preserve reserved grant entries when switching

[PATCH 05/18] tools/libxl: pull xenstore/console domids from
[PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 07/18] mini-os: avoid crash if no console is provided
[PATCH 08/18] mini-os: avoid crash if no xenstore is provided
[PATCH 09/18] mini-os: remove per-fd evtchn limit
[PATCH 10/18] xenstored: use grant references instead of
[PATCH 11/18] xenstored: add NO_SOCKETS compilation option
[PATCH 12/18] xenstored support for in-memory rather than FS based
[PATCH 13/18] xenstored: support running in minios stubdom
[PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
[PATCH 15/18] xenstored: add --event parameter for bootstrapping
Removed old #16; shared page is no longer used to pass event.
[PATCH 16/18] xenstored: use domain_is_unprivileged instead of
[PATCH 17/18] xenstored: add --priv-domid parameter

[PATCH 18/18] xenstored: Add stub domain builder

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBw-0004GI-7E; Thu, 12 Jan 2012 23:36:20 +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 1RlUBr-0004An-Re
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326411368!8890269!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 2853 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-13.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vW008710; Thu, 12 Jan 2012 23:36: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 q0CNa5dT007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:22 -0500
Message-Id: <1326411330-7915-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 10/18] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_domain.c |   45 ++++++++++++++++++++++++++++++++-----
 1 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..0b8353b 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -174,8 +176,12 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		if (*xcg_handle >= 0 && domain->domid != 0)
+			xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
+		else
+			munmap(domain->interface, getpagesize());
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +350,17 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		if (*xcg_handle >= 0) {
+			/* this is the preferred method */
+			interface = xc_gnttab_map_grant_ref(
+				*xcg_handle, domid,
+				GNTTAB_RESERVED_XENSTORE,
+				PROT_READ|PROT_WRITE);
+		} else {
+			interface = xc_map_foreign_range(
+				*xc_handle, domid,
+				getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		}
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +368,10 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			if (*xcg_handle >= 0)
+				xc_gnttab_munmap(*xcg_handle, interface, 1);
+			else
+				munmap(interface, getpagesize());
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +569,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +626,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBn-0004Av-NJ; Thu, 12 Jan 2012 23:36:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlUBl-0004Af-Hq
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:09 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326411321!50026405!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 10709 invoked from network); 12 Jan 2012 23:35:21 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 23:35:21 -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
	q0CNa6vW008719
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5db007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:30 -0500
Message-Id: <1326411330-7915-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/18] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   55 +++++++++++++++++
 tools/xenstore/Makefile                  |    9 ++-
 tools/xenstore/init-xenstore-domain.c    |   96 ++++++++++++++++++++++++++++++
 3 files changed, 158 insertions(+), 2 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..b107be9
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,55 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_ALLOC				\
+	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
+struct ioctl_xenbus_alloc {
+	/* IN */
+	/* The domain ID (must exist) for xenstore */
+	uint16_t dom;
+	uint16_t pad;
+	/* OUT */
+	/* The port allocated for xenbus communication */
+	uint32_t port;
+	/* Always set to GNTTAB_RESERVED_XENSTORE */
+	uint32_t grant_ref;
+};
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 3a061d6..9b411a5 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
@@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..30f6c9b
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,96 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+	struct ioctl_xenbus_alloc alloc;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	alloc.dom = domid;
+	rv = ioctl(xs_fd, IOCTL_XENBUS_ALLOC, &alloc);
+	if (rv) return rv;
+	snprintf(cmdline, 512, "--event %d", alloc.port);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBr-0004CG-M6; Thu, 12 Jan 2012 23:36:15 +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 1RlUBp-0004AV-OZ
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:13 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326411366!1971366!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 12921 invoked from network); 12 Jan 2012 23:36:06 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-9.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa5vW008703
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dJ007010
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:12 -0500
Message-Id: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH v2 00/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC
   (the new device path uses 'B' not 'X' as the base so the ioctl number
   does not match; otherwise, should be compatible).

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

----

[PATCH 01/18] xen: reinstate previously unused hypercall
[PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/18] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 04/18] xen: Preserve reserved grant entries when switching

[PATCH 05/18] tools/libxl: pull xenstore/console domids from
[PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 07/18] mini-os: avoid crash if no console is provided
[PATCH 08/18] mini-os: avoid crash if no xenstore is provided
[PATCH 09/18] mini-os: remove per-fd evtchn limit
[PATCH 10/18] xenstored: use grant references instead of
[PATCH 11/18] xenstored: add NO_SOCKETS compilation option
[PATCH 12/18] xenstored support for in-memory rather than FS based
[PATCH 13/18] xenstored: support running in minios stubdom
[PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
[PATCH 15/18] xenstored: add --event parameter for bootstrapping
Removed old #16; shared page is no longer used to pass event.
[PATCH 16/18] xenstored: use domain_is_unprivileged instead of
[PATCH 17/18] xenstored: add --priv-domid parameter

[PATCH 18/18] xenstored: Add stub domain builder

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBw-0004GI-7E; Thu, 12 Jan 2012 23:36:20 +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 1RlUBr-0004An-Re
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326411368!8890269!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 2853 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-13.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vW008710; Thu, 12 Jan 2012 23:36: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 q0CNa5dT007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:22 -0500
Message-Id: <1326411330-7915-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 10/18] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_domain.c |   45 ++++++++++++++++++++++++++++++++-----
 1 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..0b8353b 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -174,8 +176,12 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		if (*xcg_handle >= 0 && domain->domid != 0)
+			xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
+		else
+			munmap(domain->interface, getpagesize());
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +350,17 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		if (*xcg_handle >= 0) {
+			/* this is the preferred method */
+			interface = xc_gnttab_map_grant_ref(
+				*xcg_handle, domid,
+				GNTTAB_RESERVED_XENSTORE,
+				PROT_READ|PROT_WRITE);
+		} else {
+			interface = xc_map_foreign_range(
+				*xc_handle, domid,
+				getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		}
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +368,10 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			if (*xcg_handle >= 0)
+				xc_gnttab_munmap(*xcg_handle, interface, 1);
+			else
+				munmap(interface, getpagesize());
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +569,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +626,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBs-0004CX-25; Thu, 12 Jan 2012 23:36:16 +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 1RlUBp-0004AX-Sl
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326411366!10786465!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 11208 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-15.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa5vW008708
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dO007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:17 -0500
Message-Id: <1326411330-7915-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/18] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a4725fe..5e39595 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -73,6 +73,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -104,9 +105,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 288c03c..97ead08 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -219,9 +219,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBu-0004E6-4S; Thu, 12 Jan 2012 23:36:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlUBq-0004Ao-0k
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326411329!55736263!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 13660 invoked from network); 12 Jan 2012 23:35:29 -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;
	12 Jan 2012 23:35:29 -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
	q0CNa5vW008709; Thu, 12 Jan 2012 23:36: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 q0CNa5dP007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:18 -0500
Message-Id: <1326411330-7915-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 06/18] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  164 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 216 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..1a55a6d 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    DECLARE_HYPERCALL;
+    gnttab_setup_table_t setup_table;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+	unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+	if (gmfnp == NULL)
+		return -1;
+
+    setup_table.dom = domid;
+    setup_table.nr_frames = 1;
+    set_xen_guest_handle(setup_table.frame_list, gmfnp);
+    setup_table.status = 0;
+
+    hypercall.op = __HYPERVISOR_grant_table_op;
+    hypercall.arg[0] = GNTTABOP_setup_table;
+    hypercall.arg[1] = (unsigned long) &setup_table;
+    hypercall.arg[2] = 1;
+
+    rc = do_xen_hypercall(xch, &hypercall);
+	gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup_table.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup_table.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0, /* TODO: what's this? */
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+    .domid = domid,
+    .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..8bee684 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..3bd5549 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 5e39595..04db22f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -233,7 +233,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -259,6 +261,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -272,7 +278,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -305,6 +312,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -358,7 +367,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -396,7 +407,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBs-0004Cy-F5; Thu, 12 Jan 2012 23:36:16 +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 1RlUBp-0004AW-Ue
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326411366!7069364!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 13470 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa5vx003853
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dN007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:16 -0500
Message-Id: <1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to use or preserve v2-only features such as sub-page grants
will produce invalid v1 grant entries, which (while they will not work)
is not a problem since a guest can always produce such invalid entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c         |   38 +++++++++++++++++++++++++++++++-------
 xen/include/public/grant_table.h |    6 ++++++
 2 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 014734d..8d4a4cb 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2126,7 +2127,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2151,15 +2152,38 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1) {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    } else if (gt->gt_version == 2) {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
-    {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1) {
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    } else if (gt->gt_version != 0 && op.version == 2) {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..36d1ac7 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,12 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* External tools reserve first few grant table entries. */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+/* (the next 6 are reserved for future use) */
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBw-0004Gm-Jg; Thu, 12 Jan 2012 23:36:20 +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 1RlUBr-0004Am-NK
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326411367!8140114!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 3561 invoked from network); 12 Jan 2012 23:36:08 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa6vW008713
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dW007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:25 -0500
Message-Id: <1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Originally-by: Diego Ongaro <diego.ongaro@citrix.com>
Originally-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h          |    6 ++--
 extras/mini-os/main.c                  |    4 +++
 stubdom/Makefile                       |   29 +++++++++++++++++--
 tools/xenstore/Makefile                |    9 +++++-
 tools/xenstore/tdb.c                   |    6 ++--
 tools/xenstore/utils.h                 |    2 +
 tools/xenstore/xenstored_core.c        |   47 ++++++++++++++++++++++++++++++-
 tools/xenstore/xenstored_domain.c      |    7 +++++
 tools/xenstore/xenstored_transaction.c |    2 +
 9 files changed, 100 insertions(+), 12 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..cd89849 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -60,6 +60,7 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
+#ifndef CONFIG_XENSTORE
 #ifndef CONFIG_GRUB
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
@@ -67,6 +68,7 @@ static void call_main(void *p)
 #endif
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU
     /* Fetch argc, argv from XenStore */
@@ -169,9 +171,11 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
+#ifndef CONFIG_XENSTORE
 #ifdef HAVE_LWIP
     stop_networking();
 #endif
+#endif
     stop_kernel();
     if (!ret) {
 	/* No problem, just shutdown.  */
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 3705059..e0a90a9 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_XENSTORE $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..3a061d6 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 639ce6e..75ffd2a 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 
 		/* Iterate through chain */
 		while( tlock->off) {
-			tdb_off current;
+			tdb_off mycurrent;
 			if (rec_read(tdb, tlock->off, rec) == -1)
 				goto fail;
 
@@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 			}
 
 			/* Try to clean dead ones from old traverses */
-			current = tlock->off;
+			mycurrent = tlock->off;
 			tlock->off = rec->next;
 			if (!tdb->read_only && 
-			    do_delete(tdb, current, rec) != 0)
+			    do_delete(tdb, mycurrent, rec) != 0)
 				goto fail;
 		}
 		tdb_unlock(tdb, tlock->hash, F_WRLCK);
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 631bfe4..e51f2ad 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -32,7 +32,9 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#ifndef NO_SYSLOG
 #include <syslog.h>
+#endif
 #include <string.h>
 #include <errno.h>
 #include <dirent.h>
@@ -61,13 +63,24 @@ LIST_HEAD(connections);
 static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
+#ifndef NO_REOPEN_LOG
 static int reopen_log_pipe[2];
+#endif
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
 
+#ifdef __MINIOS__
+#define lockf(...) (-ENOSYS)
+#endif
+
+#ifdef NO_SYSLOG
+#define openlog(...) ((void) 0)
+#define syslog(...)  ((void) 0)
+#endif
+
 #define log(...)							\
 	do {								\
 		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
@@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
+#ifndef __MINIOS__
 	if (rename(newname, xs_daemon_tdb()) != 0)
 		return false;
+#endif
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -195,6 +210,7 @@ void trace_destroy(const void *data, const char *type)
 	trace("DESTROY %s %p\n", type, data);
 }
 
+#ifndef NO_REOPEN_LOG
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
@@ -222,7 +238,7 @@ static void reopen_log(void)
 			trace("\n***\n");
 	}
 }
-
+#endif
 
 static bool write_messages(struct connection *conn)
 {
@@ -326,7 +342,9 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
 #endif
+#ifndef NO_REOPEN_LOG
 	set_fd(reopen_log_pipe[0], inset, &max);
+#endif
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1415,7 +1433,11 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
+#ifdef __MINIOS__
+#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
+#else
 #define TDB_FLAGS 0
+#endif
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1440,7 +1462,11 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
+#ifdef __MINIOS__
+	tdb_ctx = NULL;
+#else
 	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+#endif
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1666,6 +1692,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifndef __MINIOS__
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1712,7 +1739,7 @@ static void daemonize(void)
 	/* Discard our parent's old-fashioned umask prejudices. */
 	umask(0);
 }
-
+#endif
 
 static void usage(void)
 {
@@ -1767,7 +1794,11 @@ int main(int argc, char *argv[])
 	struct sockaddr_un addr;
 #endif
 	fd_set inset, outset;
+#ifdef __MINIOS__
+	bool dofork = false;
+#else
 	bool dofork = true;
+#endif
 	bool outputpid = false;
 	bool no_domain_init = false;
 	const char *pidfile = NULL;
@@ -1821,8 +1852,11 @@ int main(int argc, char *argv[])
 	if (optind != argc)
 		barf("%s: No arguments desired", argv[0]);
 
+#ifndef NO_REOPEN_LOG
 	reopen_log();
+#endif
 
+#ifndef __MINIOS__
 	/* make sure xenstored directory exists */
 	if (mkdir(xs_daemon_rundir(), 0755)) {
 		if (errno != EEXIST) {
@@ -1844,6 +1878,7 @@ int main(int argc, char *argv[])
 	}
 	if (pidfile)
 		write_pidfile(pidfile);
+#endif
 
 	/* Talloc leak reports go to stderr, which is closed if we fork. */
 	if (!dofork)
@@ -1890,9 +1925,11 @@ int main(int argc, char *argv[])
 		barf_perror("Could not listen on sockets");
 #endif
 
+#ifndef NO_REOPEN_LOG
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1921,7 +1958,9 @@ int main(int argc, char *argv[])
 		xprintf = trace;
 	}
 
+#ifndef NO_REOPEN_LOG
 	signal(SIGHUP, trigger_reopen_log);
+#endif
 
 	if (xce_handle != NULL)
 		evtchn_fd = xc_evtchn_fd(xce_handle);
@@ -1929,8 +1968,10 @@ int main(int argc, char *argv[])
 	/* Get ready to listen to the tools. */
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1942,12 +1983,14 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
+#ifndef NO_REOPEN_LOG
 		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
 			reopen_log();
 		}
+#endif
 
 #ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 0b8353b..811ae3c 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -588,6 +588,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static inline int dom0_init(void) 
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -611,6 +617,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
index 380c691..c59acfb 100644
--- a/tools/xenstore/xenstored_transaction.c
+++ b/tools/xenstore/xenstored_transaction.c
@@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
 	trace_destroy(trans, "transaction");
 	if (trans->tdb)
 		tdb_close(trans->tdb);
+#ifndef __MINIOS__
 	unlink(trans->tdb_name);
+#endif
 	return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBs-0004DC-SK; Thu, 12 Jan 2012 23:36:16 +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 1RlUBq-0004AZ-1t
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326411367!10696196!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 29325 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa6vx003859
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dX007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:26 -0500
Message-Id: <1326411330-7915-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 14/18] xenstored: always use xc_gnttab_munmap in
	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>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/xenstore/xenstored_domain.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 811ae3c..aca2149 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -177,10 +177,14 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
+#else
 		if (*xcg_handle >= 0 && domain->domid != 0)
 			xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
 		else
 			munmap(domain->interface, getpagesize());
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBu-0004ES-Gz; Thu, 12 Jan 2012 23:36:18 +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 1RlUBq-0004Ab-By
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326411367!10717706!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 13631 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa6vx003863
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dZ007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:28 -0500
Message-Id: <1326411330-7915-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 16/18] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4ec63f1..eea5fd6 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -488,7 +488,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -826,11 +826,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 648eb1d..5f4a09e 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -336,7 +336,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -413,7 +413,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -465,7 +465,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -502,7 +502,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBu-0004Ej-Tq; Thu, 12 Jan 2012 23:36:18 +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 1RlUBq-0004Ac-Dm
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326411367!1521208!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 19840 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa5vx003855
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dQ007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:19 -0500
Message-Id: <1326411330-7915-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 07/18] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..14a8bd1 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+    if (!intf)
+        return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBv-0004Fv-RV; Thu, 12 Jan 2012 23:36:19 +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 1RlUBr-0004Al-J6
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:15 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326411368!10803661!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 22983 invoked from network); 12 Jan 2012 23:36:08 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa5vW008712; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dV007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:24 -0500
Message-Id: <1326411330-7915-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 12/18] xenstored support for in-memory rather
	than FS based trivial DB (needed to run on mini-OS)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

tdb_copy (a xen modification to tdb?) should honor the TDB_INTERNAL flag
for in-memory databases.

TODO: leaks memory on error case

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/tdb.c |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..639ce6e 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,42 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+
+		return copy;
+intfail:
+		/* TODO (leaking memory is easier) */
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBs-0004Cy-F5; Thu, 12 Jan 2012 23:36:16 +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 1RlUBp-0004AW-Ue
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326411366!7069364!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 13470 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa5vx003853
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dN007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:16 -0500
Message-Id: <1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to use or preserve v2-only features such as sub-page grants
will produce invalid v1 grant entries, which (while they will not work)
is not a problem since a guest can always produce such invalid entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c         |   38 +++++++++++++++++++++++++++++++-------
 xen/include/public/grant_table.h |    6 ++++++
 2 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 014734d..8d4a4cb 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2126,7 +2127,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2151,15 +2152,38 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1) {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    } else if (gt->gt_version == 2) {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
-    {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1) {
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    } else if (gt->gt_version != 0 && op.version == 2) {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..36d1ac7 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,12 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* External tools reserve first few grant table entries. */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+/* (the next 6 are reserved for future use) */
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBv-0004FD-9y; Thu, 12 Jan 2012 23:36:19 +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 1RlUBq-0004Ad-GF
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326411367!8863181!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 18242 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa6vW008716
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5da007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:29 -0500
Message-Id: <1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 17/18] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index eea5fd6..9d087de 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1774,6 +1774,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1786,6 +1787,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 5f4a09e..46bcf3e 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBu-0004E6-4S; Thu, 12 Jan 2012 23:36:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlUBq-0004Ao-0k
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326411329!55736263!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 13660 invoked from network); 12 Jan 2012 23:35:29 -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;
	12 Jan 2012 23:35:29 -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
	q0CNa5vW008709; Thu, 12 Jan 2012 23:36: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 q0CNa5dP007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:18 -0500
Message-Id: <1326411330-7915-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 06/18] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  164 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 216 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..1a55a6d 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    DECLARE_HYPERCALL;
+    gnttab_setup_table_t setup_table;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+	unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+	if (gmfnp == NULL)
+		return -1;
+
+    setup_table.dom = domid;
+    setup_table.nr_frames = 1;
+    set_xen_guest_handle(setup_table.frame_list, gmfnp);
+    setup_table.status = 0;
+
+    hypercall.op = __HYPERVISOR_grant_table_op;
+    hypercall.arg[0] = GNTTABOP_setup_table;
+    hypercall.arg[1] = (unsigned long) &setup_table;
+    hypercall.arg[2] = 1;
+
+    rc = do_xen_hypercall(xch, &hypercall);
+	gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup_table.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup_table.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0, /* TODO: what's this? */
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+    .domid = domid,
+    .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..8bee684 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..3bd5549 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 5e39595..04db22f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -233,7 +233,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -259,6 +261,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -272,7 +278,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -305,6 +312,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -358,7 +367,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -396,7 +407,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBx-0004Hn-Ck; Thu, 12 Jan 2012 23:36:21 +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 1RlUBs-0004Ap-0L
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326411368!10206481!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 27616 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vx003856; Thu, 12 Jan 2012 23:36: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 q0CNa5dS007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:21 -0500
Message-Id: <1326411330-7915-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/18] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Changes the minios evtchn implementation to use a list instead of an array.
This allows it to grow as necessary to support any number of ports.
Unfortunately, it's still limited by NR_EVS in events.c.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBx-0004HC-0J; Thu, 12 Jan 2012 23:36:21 +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 1RlUBs-0004At-1L
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326411368!10694414!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 4101 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vW008711; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dU007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:23 -0500
Message-Id: <1326411330-7915-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 11/18] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

option for compiling xenstored without unix sockets to support running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c |   22 +++++++++++++++++++++-
 tools/xenstore/xs.c             |    2 ++
 tools/xenstore/xs_lib.c         |    4 ++++
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..631bfe4 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
+#ifndef NO_SOCKETS
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
+#endif
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -343,12 +347,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
+#ifndef NO_SOCKETS
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
 	close(*fd);
 	return 0;
 }
+#endif
 
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
@@ -1352,6 +1358,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifndef NO_SOCKETS
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1406,6 +1413,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1753,7 +1761,11 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
+#ifdef NO_SOCKETS
+	int minus_one = -1;
+#else
 	struct sockaddr_un addr;
+#endif
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,6 +1849,9 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
+#ifdef NO_SOCKETS
+	sock = ro_sock = &minus_one;
+#else
 	/* Create sockets for them to listen to. */
 	sock = talloc(talloc_autofree_context(), int);
 	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
@@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
 		barf_perror("Could not create socket");
 	talloc_set_destructor(sock, destroy_fd);
 	talloc_set_destructor(ro_sock, destroy_fd);
+#endif
 
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
+#ifndef NO_SOCKETS
 	/* FIXME: Be more sophisticated, don't mug running daemon. */
 	unlink(xs_daemon_socket());
 	unlink(xs_daemon_socket_ro());
@@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
 	if (listen(*sock, 1) != 0
 	    || listen(*ro_sock, 1) != 0)
 		barf_perror("Could not listen on sockets");
+#endif
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
@@ -1931,11 +1949,13 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
+#ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
 		if (FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
+#endif
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
 			handle_event();
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index 8e54fe0..119d945 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
 {
 	struct xs_handle *xsh = NULL;
 
+#ifndef NO_SOCKETS
 	if (flags & XS_OPEN_READONLY)
 		xsh = get_handle(xs_daemon_socket_ro());
 	else
 		xsh = get_handle(xs_daemon_socket());
+#endif
 
 	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
 		xsh = get_handle(xs_domain_dev());
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
index 03a9ee4..af3db6b 100644
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
 	return (s ? s : "/var/run/xenstored");
 }
 
+#ifndef NO_SOCKETS
 static const char *xs_daemon_path(void)
 {
 	static char buf[PATH_MAX];
@@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_daemon_tdb(void)
 {
@@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
 	return buf;
 }
 
+#ifndef NO_SOCKETS
 const char *xs_daemon_socket(void)
 {
 	return xs_daemon_path();
@@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_domain_dev(void)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBs-0004DC-SK; Thu, 12 Jan 2012 23:36:16 +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 1RlUBq-0004AZ-1t
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326411367!10696196!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 29325 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa6vx003859
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dX007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:26 -0500
Message-Id: <1326411330-7915-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 14/18] xenstored: always use xc_gnttab_munmap in
	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>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/xenstore/xenstored_domain.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 811ae3c..aca2149 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -177,10 +177,14 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
+#else
 		if (*xcg_handle >= 0 && domain->domid != 0)
 			xc_gnttab_munmap(*xcg_handle, domain->interface, 1);
 		else
 			munmap(domain->interface, getpagesize());
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBu-0004Ej-Tq; Thu, 12 Jan 2012 23:36:18 +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 1RlUBq-0004Ac-Dm
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326411367!1521208!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 19840 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa5vx003855
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dQ007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:19 -0500
Message-Id: <1326411330-7915-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 07/18] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..14a8bd1 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+    if (!intf)
+        return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBv-0004Fv-RV; Thu, 12 Jan 2012 23:36:19 +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 1RlUBr-0004Al-J6
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:15 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326411368!10803661!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 22983 invoked from network); 12 Jan 2012 23:36:08 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa5vW008712; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dV007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:24 -0500
Message-Id: <1326411330-7915-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 12/18] xenstored support for in-memory rather
	than FS based trivial DB (needed to run on mini-OS)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

tdb_copy (a xen modification to tdb?) should honor the TDB_INTERNAL flag
for in-memory databases.

TODO: leaks memory on error case

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/tdb.c |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..639ce6e 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,42 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+
+		return copy;
+intfail:
+		/* TODO (leaking memory is easier) */
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBp-0004BK-8W; Thu, 12 Jan 2012 23:36:13 +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 1RlUBo-0004Ae-HN
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326411332!48188473!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 17300 invoked from network); 12 Jan 2012 23:35:32 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 23:35:32 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa5vx003854
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dR007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:20 -0500
Message-Id: <1326411330-7915-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/18] mini-os: avoid crash if no xenstore is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/xenbus/xenbus.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
index a8081fd..e475e2c 100644
--- a/extras/mini-os/xenbus/xenbus.c
+++ b/extras/mini-os/xenbus/xenbus.c
@@ -328,6 +328,10 @@ static int allocate_xenbus_id(void)
 void init_xenbus(void)
 {
     int err;
+    if (!start_info.store_evtchn) {
+        printk("Skipping initialization of xenbus\n");
+        return;
+    }
     printk("Initialising xenbus\n");
     DEBUG("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
@@ -435,6 +439,11 @@ xenbus_msg_reply(int type,
     DEFINE_WAIT(w);
     struct xsd_sockmsg *rep;
 
+    if (!xenstore_buf) {
+        printk("xenbus_msg_reply called but no xenstore!\n");
+        return NULL;
+    }
+
     id = allocate_xenbus_id();
     add_waiter(w, req_info[id].waitq);
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBv-0004FD-9y; Thu, 12 Jan 2012 23:36:19 +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 1RlUBq-0004Ad-GF
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326411367!8863181!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 18242 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-174.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa6vW008716
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5da007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:29 -0500
Message-Id: <1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 17/18] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index eea5fd6..9d087de 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1774,6 +1774,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1786,6 +1787,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 5f4a09e..46bcf3e 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBu-0004ES-Gz; Thu, 12 Jan 2012 23:36:18 +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 1RlUBq-0004Ab-By
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326411367!10717706!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 13631 invoked from network); 12 Jan 2012 23:36:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 23:36:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa6vx003863
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dZ007010; 
	Thu, 12 Jan 2012 18:36:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:28 -0500
Message-Id: <1326411330-7915-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 16/18] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4ec63f1..eea5fd6 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -488,7 +488,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -826,11 +826,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 648eb1d..5f4a09e 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -336,7 +336,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -413,7 +413,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -465,7 +465,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -502,7 +502,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBw-0004Gm-Jg; Thu, 12 Jan 2012 23:36:20 +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 1RlUBr-0004Am-NK
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326411367!8140114!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 3561 invoked from network); 12 Jan 2012 23:36:08 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-21.messagelabs.com with SMTP;
	12 Jan 2012 23:36: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
	q0CNa6vW008713
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dW007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:25 -0500
Message-Id: <1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Originally-by: Diego Ongaro <diego.ongaro@citrix.com>
Originally-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h          |    6 ++--
 extras/mini-os/main.c                  |    4 +++
 stubdom/Makefile                       |   29 +++++++++++++++++--
 tools/xenstore/Makefile                |    9 +++++-
 tools/xenstore/tdb.c                   |    6 ++--
 tools/xenstore/utils.h                 |    2 +
 tools/xenstore/xenstored_core.c        |   47 ++++++++++++++++++++++++++++++-
 tools/xenstore/xenstored_domain.c      |    7 +++++
 tools/xenstore/xenstored_transaction.c |    2 +
 9 files changed, 100 insertions(+), 12 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..cd89849 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -60,6 +60,7 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
+#ifndef CONFIG_XENSTORE
 #ifndef CONFIG_GRUB
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
@@ -67,6 +68,7 @@ static void call_main(void *p)
 #endif
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU
     /* Fetch argc, argv from XenStore */
@@ -169,9 +171,11 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
+#ifndef CONFIG_XENSTORE
 #ifdef HAVE_LWIP
     stop_networking();
 #endif
+#endif
     stop_kernel();
     if (!ret) {
 	/* No problem, just shutdown.  */
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 3705059..e0a90a9 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_XENSTORE $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..3a061d6 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 639ce6e..75ffd2a 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 
 		/* Iterate through chain */
 		while( tlock->off) {
-			tdb_off current;
+			tdb_off mycurrent;
 			if (rec_read(tdb, tlock->off, rec) == -1)
 				goto fail;
 
@@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 			}
 
 			/* Try to clean dead ones from old traverses */
-			current = tlock->off;
+			mycurrent = tlock->off;
 			tlock->off = rec->next;
 			if (!tdb->read_only && 
-			    do_delete(tdb, current, rec) != 0)
+			    do_delete(tdb, mycurrent, rec) != 0)
 				goto fail;
 		}
 		tdb_unlock(tdb, tlock->hash, F_WRLCK);
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 631bfe4..e51f2ad 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -32,7 +32,9 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#ifndef NO_SYSLOG
 #include <syslog.h>
+#endif
 #include <string.h>
 #include <errno.h>
 #include <dirent.h>
@@ -61,13 +63,24 @@ LIST_HEAD(connections);
 static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
+#ifndef NO_REOPEN_LOG
 static int reopen_log_pipe[2];
+#endif
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
 
+#ifdef __MINIOS__
+#define lockf(...) (-ENOSYS)
+#endif
+
+#ifdef NO_SYSLOG
+#define openlog(...) ((void) 0)
+#define syslog(...)  ((void) 0)
+#endif
+
 #define log(...)							\
 	do {								\
 		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
@@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
+#ifndef __MINIOS__
 	if (rename(newname, xs_daemon_tdb()) != 0)
 		return false;
+#endif
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -195,6 +210,7 @@ void trace_destroy(const void *data, const char *type)
 	trace("DESTROY %s %p\n", type, data);
 }
 
+#ifndef NO_REOPEN_LOG
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
@@ -222,7 +238,7 @@ static void reopen_log(void)
 			trace("\n***\n");
 	}
 }
-
+#endif
 
 static bool write_messages(struct connection *conn)
 {
@@ -326,7 +342,9 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
 #endif
+#ifndef NO_REOPEN_LOG
 	set_fd(reopen_log_pipe[0], inset, &max);
+#endif
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1415,7 +1433,11 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
+#ifdef __MINIOS__
+#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
+#else
 #define TDB_FLAGS 0
+#endif
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1440,7 +1462,11 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
+#ifdef __MINIOS__
+	tdb_ctx = NULL;
+#else
 	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+#endif
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1666,6 +1692,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifndef __MINIOS__
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1712,7 +1739,7 @@ static void daemonize(void)
 	/* Discard our parent's old-fashioned umask prejudices. */
 	umask(0);
 }
-
+#endif
 
 static void usage(void)
 {
@@ -1767,7 +1794,11 @@ int main(int argc, char *argv[])
 	struct sockaddr_un addr;
 #endif
 	fd_set inset, outset;
+#ifdef __MINIOS__
+	bool dofork = false;
+#else
 	bool dofork = true;
+#endif
 	bool outputpid = false;
 	bool no_domain_init = false;
 	const char *pidfile = NULL;
@@ -1821,8 +1852,11 @@ int main(int argc, char *argv[])
 	if (optind != argc)
 		barf("%s: No arguments desired", argv[0]);
 
+#ifndef NO_REOPEN_LOG
 	reopen_log();
+#endif
 
+#ifndef __MINIOS__
 	/* make sure xenstored directory exists */
 	if (mkdir(xs_daemon_rundir(), 0755)) {
 		if (errno != EEXIST) {
@@ -1844,6 +1878,7 @@ int main(int argc, char *argv[])
 	}
 	if (pidfile)
 		write_pidfile(pidfile);
+#endif
 
 	/* Talloc leak reports go to stderr, which is closed if we fork. */
 	if (!dofork)
@@ -1890,9 +1925,11 @@ int main(int argc, char *argv[])
 		barf_perror("Could not listen on sockets");
 #endif
 
+#ifndef NO_REOPEN_LOG
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1921,7 +1958,9 @@ int main(int argc, char *argv[])
 		xprintf = trace;
 	}
 
+#ifndef NO_REOPEN_LOG
 	signal(SIGHUP, trigger_reopen_log);
+#endif
 
 	if (xce_handle != NULL)
 		evtchn_fd = xc_evtchn_fd(xce_handle);
@@ -1929,8 +1968,10 @@ int main(int argc, char *argv[])
 	/* Get ready to listen to the tools. */
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1942,12 +1983,14 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
+#ifndef NO_REOPEN_LOG
 		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
 			reopen_log();
 		}
+#endif
 
 #ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 0b8353b..811ae3c 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -588,6 +588,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static inline int dom0_init(void) 
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -611,6 +617,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
index 380c691..c59acfb 100644
--- a/tools/xenstore/xenstored_transaction.c
+++ b/tools/xenstore/xenstored_transaction.c
@@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
 	trace_destroy(trans, "transaction");
 	if (trans->tdb)
 		tdb_close(trans->tdb);
+#ifndef __MINIOS__
 	unlink(trans->tdb_name);
+#endif
 	return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBx-0004HC-0J; Thu, 12 Jan 2012 23:36:21 +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 1RlUBs-0004At-1L
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326411368!10694414!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 4101 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vW008711; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dU007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:23 -0500
Message-Id: <1326411330-7915-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 11/18] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

option for compiling xenstored without unix sockets to support running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c |   22 +++++++++++++++++++++-
 tools/xenstore/xs.c             |    2 ++
 tools/xenstore/xs_lib.c         |    4 ++++
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..631bfe4 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
+#ifndef NO_SOCKETS
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
+#endif
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -343,12 +347,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
+#ifndef NO_SOCKETS
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
 	close(*fd);
 	return 0;
 }
+#endif
 
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
@@ -1352,6 +1358,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifndef NO_SOCKETS
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1406,6 +1413,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1753,7 +1761,11 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
+#ifdef NO_SOCKETS
+	int minus_one = -1;
+#else
 	struct sockaddr_un addr;
+#endif
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,6 +1849,9 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
+#ifdef NO_SOCKETS
+	sock = ro_sock = &minus_one;
+#else
 	/* Create sockets for them to listen to. */
 	sock = talloc(talloc_autofree_context(), int);
 	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
@@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
 		barf_perror("Could not create socket");
 	talloc_set_destructor(sock, destroy_fd);
 	talloc_set_destructor(ro_sock, destroy_fd);
+#endif
 
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
+#ifndef NO_SOCKETS
 	/* FIXME: Be more sophisticated, don't mug running daemon. */
 	unlink(xs_daemon_socket());
 	unlink(xs_daemon_socket_ro());
@@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
 	if (listen(*sock, 1) != 0
 	    || listen(*ro_sock, 1) != 0)
 		barf_perror("Could not listen on sockets");
+#endif
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
@@ -1931,11 +1949,13 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
+#ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
 		if (FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
+#endif
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
 			handle_event();
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index 8e54fe0..119d945 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
 {
 	struct xs_handle *xsh = NULL;
 
+#ifndef NO_SOCKETS
 	if (flags & XS_OPEN_READONLY)
 		xsh = get_handle(xs_daemon_socket_ro());
 	else
 		xsh = get_handle(xs_daemon_socket());
+#endif
 
 	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
 		xsh = get_handle(xs_domain_dev());
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
index 03a9ee4..af3db6b 100644
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
 	return (s ? s : "/var/run/xenstored");
 }
 
+#ifndef NO_SOCKETS
 static const char *xs_daemon_path(void)
 {
 	static char buf[PATH_MAX];
@@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_daemon_tdb(void)
 {
@@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
 	return buf;
 }
 
+#ifndef NO_SOCKETS
 const char *xs_daemon_socket(void)
 {
 	return xs_daemon_path();
@@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_domain_dev(void)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBp-0004BK-8W; Thu, 12 Jan 2012 23:36:13 +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 1RlUBo-0004Ae-HN
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:12 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326411332!48188473!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 17300 invoked from network); 12 Jan 2012 23:35:32 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-27.messagelabs.com with SMTP;
	12 Jan 2012 23:35:32 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0CNa5vx003854
	for <xen-devel@lists.xensource.com>; Thu, 12 Jan 2012 23:36: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 q0CNa5dR007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:20 -0500
Message-Id: <1326411330-7915-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/18] mini-os: avoid crash if no xenstore is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/xenbus/xenbus.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
index a8081fd..e475e2c 100644
--- a/extras/mini-os/xenbus/xenbus.c
+++ b/extras/mini-os/xenbus/xenbus.c
@@ -328,6 +328,10 @@ static int allocate_xenbus_id(void)
 void init_xenbus(void)
 {
     int err;
+    if (!start_info.store_evtchn) {
+        printk("Skipping initialization of xenbus\n");
+        return;
+    }
     printk("Initialising xenbus\n");
     DEBUG("init_xenbus called.\n");
     xenstore_buf = mfn_to_virt(start_info.store_mfn);
@@ -435,6 +439,11 @@ xenbus_msg_reply(int type,
     DEFINE_WAIT(w);
     struct xsd_sockmsg *rep;
 
+    if (!xenstore_buf) {
+        printk("xenbus_msg_reply called but no xenstore!\n");
+        return NULL;
+    }
+
     id = allocate_xenbus_id();
     add_waiter(w, req_info[id].waitq);
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBx-0004Hn-Ck; Thu, 12 Jan 2012 23:36:21 +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 1RlUBs-0004Ap-0L
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326411368!10206481!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 27616 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-216.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vx003856; Thu, 12 Jan 2012 23:36: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 q0CNa5dS007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:21 -0500
Message-Id: <1326411330-7915-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/18] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Changes the minios evtchn implementation to use a list instead of an array.
This allows it to grow as necessary to support any number of ports.
Unfortunately, it's still limited by NR_EVS in events.c.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBx-0004IP-PI; Thu, 12 Jan 2012 23:36:21 +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 1RlUBs-0004Au-5q
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326411368!10677409!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 27550 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vW008706; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dK007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:13 -0500
Message-Id: <1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/ia64/xen/mm.c          |   34 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm.c               |   35 +++++++++++++++++++++++++++++++++++
 xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
 xen/include/public/memory.h     |   16 ++++++++++++++++
 xen/include/xlat.lst            |    1 +
 xen/include/xsm/xsm.h           |    6 ++++++
 xen/xsm/dummy.c                 |    6 ++++++
 xen/xsm/flask/hooks.c           |    6 ++++++
 8 files changed, 118 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
index 84f6a61..a40f96a 100644
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = gmfn_to_mfn(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
+
     case XENMEM_machine_memory_map:
     {
         struct xen_memory_map memmap;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 1f996e0..39cc3c0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4871,6 +4871,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         return rc;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     case XENMEM_set_memory_map:
     {
         struct xen_foreign_memory_map fmap;
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index bea94fe..dde5430 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -82,6 +82,20 @@ int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct compat_remove_from_physmap cmp;
+        struct xen_remove_from_physmap *nat = (void *)COMPAT_ARG_XLAT_VIRT_BASE;
+
+        if ( copy_from_guest(&cmp, arg, 1) )
+            return -EFAULT;
+
+        XLAT_remove_from_physmap(nat, &cmp);
+        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
+
+        break;
+    }
+
     case XENMEM_set_memory_map:
     {
         struct compat_foreign_memory_map cmp;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..ee1772c 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -81,6 +81,7 @@
 !	processor_power			platform.h
 ?	processor_px			platform.h
 !	psd_package			platform.h
+!	remove_from_physmap		memory.h
 ?	xenpf_pcpuinfo			platform.h
 ?	xenpf_pcpu_version		platform.h
 !	sched_poll			sched.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 12 23:36:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 12 Jan 2012 23: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 1RlUBx-0004IP-PI; Thu, 12 Jan 2012 23:36:21 +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 1RlUBs-0004Au-5q
	for xen-devel@lists.xensource.com; Thu, 12 Jan 2012 23:36:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326411368!10677409!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 27550 invoked from network); 12 Jan 2012 23:36:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-182.messagelabs.com with SMTP;
	12 Jan 2012 23:36:09 -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
	q0CNa5vW008706; Thu, 12 Jan 2012 23:36:06 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 q0CNa5dK007010; 
	Thu, 12 Jan 2012 18:36:05 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 12 Jan 2012 18:35:13 -0500
Message-Id: <1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/ia64/xen/mm.c          |   34 ++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm.c               |   35 +++++++++++++++++++++++++++++++++++
 xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
 xen/include/public/memory.h     |   16 ++++++++++++++++
 xen/include/xlat.lst            |    1 +
 xen/include/xsm/xsm.h           |    6 ++++++
 xen/xsm/dummy.c                 |    6 ++++++
 xen/xsm/flask/hooks.c           |    6 ++++++
 8 files changed, 118 insertions(+), 0 deletions(-)

diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
index 84f6a61..a40f96a 100644
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = gmfn_to_mfn(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
+
     case XENMEM_machine_memory_map:
     {
         struct xen_memory_map memmap;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 1f996e0..39cc3c0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4871,6 +4871,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         return rc;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     case XENMEM_set_memory_map:
     {
         struct xen_foreign_memory_map fmap;
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index bea94fe..dde5430 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -82,6 +82,20 @@ int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct compat_remove_from_physmap cmp;
+        struct xen_remove_from_physmap *nat = (void *)COMPAT_ARG_XLAT_VIRT_BASE;
+
+        if ( copy_from_guest(&cmp, arg, 1) )
+            return -EFAULT;
+
+        XLAT_remove_from_physmap(nat, &cmp);
+        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
+
+        break;
+    }
+
     case XENMEM_set_memory_map:
     {
         struct compat_foreign_memory_map cmp;
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..ee1772c 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -81,6 +81,7 @@
 !	processor_power			platform.h
 ?	processor_px			platform.h
 !	psd_package			platform.h
+!	remove_from_physmap		memory.h
 ?	xenpf_pcpuinfo			platform.h
 ?	xenpf_pcpu_version		platform.h
 !	sched_poll			sched.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 00:56:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 00:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlVR1-00081I-Kn; Fri, 13 Jan 2012 00:55:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RlVQz-00081D-NJ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 00:55:58 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326416097!60610001!1
X-Originating-IP: [220.181.15.40]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQwID0+IDk1OTk=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQwID0+IDk1OTk=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6021 invoked from network); 13 Jan 2012 00:54:59 -0000
Received: from m15-40.126.com (HELO m15-40.126.com) (220.181.15.40)
	by server-2.tower-27.messagelabs.com with SMTP;
	13 Jan 2012 00:54:59 -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=VI1/PMBZAFRngLGQ71xABu0iO36CtVTuHb
	UN+fhDYhg=; b=byE0jNtOYyqSANyHe0NJeA5V0SKQD1fF34l2R0rkzJCBpE/CzP
	x8Go/VrkoQuXFrA2WrPrXzr01A52gkxrANZCiuUvdUF42cF7CFIGWpwscRQM1wvX
	Wk3im4jCPI+PG0szl/any2yvwnPTh4uK71MSiZofbpehnlZQPONzTWc3Q=
Received: from hxkhust ( [211.69.198.241] ) by ajax-webmail-wmsvr40
	(Coremail) ; Fri, 13 Jan 2012 08:55:53 +0800 (CST)
Date: Fri, 13 Jan 2012 08:55:53 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: xen-devel@lists.xensource.com
Message-ID: <f11ec12.21ca.134d4904a11.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [211.69.198.241]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: 8invo2Zvb3Rlcl9odG09MTU2Mjo4MQ==
X-CM-TRANSID: KMqowEDZh0MZgQ9PssBWAA--.8608W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbikgwzBU3knVUtGQABs8
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] A Problem with Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0014835184203606995=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0014835184203606995==
Content-Type: multipart/alternative; 
	boundary="----=_Part_25985_1656735142.1326416153105"

------=_Part_25985_1656735142.1326416153105
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,
 
I am a second-year graduate student.Recently,i have done some research on xen and encounter a problem.Thus i send this e-mail to you for help.
On a physical machine with xen virtualization platform installed ,VM A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM B and VM C's virtual disk image files are based on VM A's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM B get a page data from VM A's virtual disk image file. After that ,VM C also need to get the same page data as VM B got just now.Under this situation, does VMM copy the page data from VM B's memory to VM C's memory or get the page data from VM A's virtual disk image file in the physical disk again? 
 
 
HXK
Huazhong University of Science and Technology
Wuhan, 430074, China






------=_Part_25985_1656735142.1326416153105
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,</DIV>
<DIV id="isForwardContent">
<DIV style="LINE-HEIGHT: 1.7; FONT-FAMILY: arial; COLOR: #000000; FONT-SIZE: 14px">
<DIV id="isForwardContent">
<DIV style="LINE-HEIGHT: 1.7; FONT-FAMILY: arial; COLOR: #000000; FONT-SIZE: 14px">
<DIV>&nbsp;</DIV>
<DIV>I am a second-year graduate student.Recently,i have done some research on xen and encounter a problem.Thus i send this e-mail to you for help.</DIV>
<DIV>On a physical machine&nbsp;with xen virtualization platform&nbsp;installed ,VM&nbsp;A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM&nbsp;B and VM C's virtual disk image files are based on VM A's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM B get a page data from VM A's virtual disk image file. After that ,VM C also need to get the same page data as VM B got just now.Under this situation, does VMM copy the page data from VM B's memory to VM C's memory or get the page data from&nbsp;VM A's virtual disk image file in the physical disk again?&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>HXK</DIV>
<DIV>Huazhong University of Science and Technology<BR>Wuhan, 430074, China</DIV></DIV><BR><BR><SPAN title="neteasefooter"><SPAN id="netease_mail_footer"></SPAN></SPAN></DIV></DIV><BR><BR><SPAN title="neteasefooter"><SPAN id="netease_mail_footer"></SPAN></SPAN></DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_25985_1656735142.1326416153105--



--===============0014835184203606995==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0014835184203606995==--



From xen-devel-bounces@lists.xensource.com Fri Jan 13 00:56:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 00:56:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlVR1-00081I-Kn; Fri, 13 Jan 2012 00:55:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RlVQz-00081D-NJ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 00:55:58 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326416097!60610001!1
X-Originating-IP: [220.181.15.40]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQwID0+IDk1OTk=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQwID0+IDk1OTk=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6021 invoked from network); 13 Jan 2012 00:54:59 -0000
Received: from m15-40.126.com (HELO m15-40.126.com) (220.181.15.40)
	by server-2.tower-27.messagelabs.com with SMTP;
	13 Jan 2012 00:54:59 -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=VI1/PMBZAFRngLGQ71xABu0iO36CtVTuHb
	UN+fhDYhg=; b=byE0jNtOYyqSANyHe0NJeA5V0SKQD1fF34l2R0rkzJCBpE/CzP
	x8Go/VrkoQuXFrA2WrPrXzr01A52gkxrANZCiuUvdUF42cF7CFIGWpwscRQM1wvX
	Wk3im4jCPI+PG0szl/any2yvwnPTh4uK71MSiZofbpehnlZQPONzTWc3Q=
Received: from hxkhust ( [211.69.198.241] ) by ajax-webmail-wmsvr40
	(Coremail) ; Fri, 13 Jan 2012 08:55:53 +0800 (CST)
Date: Fri, 13 Jan 2012 08:55:53 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: xen-devel@lists.xensource.com
Message-ID: <f11ec12.21ca.134d4904a11.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [211.69.198.241]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: 8invo2Zvb3Rlcl9odG09MTU2Mjo4MQ==
X-CM-TRANSID: KMqowEDZh0MZgQ9PssBWAA--.8608W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbikgwzBU3knVUtGQABs8
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] A Problem with Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0014835184203606995=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0014835184203606995==
Content-Type: multipart/alternative; 
	boundary="----=_Part_25985_1656735142.1326416153105"

------=_Part_25985_1656735142.1326416153105
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,
 
I am a second-year graduate student.Recently,i have done some research on xen and encounter a problem.Thus i send this e-mail to you for help.
On a physical machine with xen virtualization platform installed ,VM A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM B and VM C's virtual disk image files are based on VM A's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM B get a page data from VM A's virtual disk image file. After that ,VM C also need to get the same page data as VM B got just now.Under this situation, does VMM copy the page data from VM B's memory to VM C's memory or get the page data from VM A's virtual disk image file in the physical disk again? 
 
 
HXK
Huazhong University of Science and Technology
Wuhan, 430074, China






------=_Part_25985_1656735142.1326416153105
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,</DIV>
<DIV id="isForwardContent">
<DIV style="LINE-HEIGHT: 1.7; FONT-FAMILY: arial; COLOR: #000000; FONT-SIZE: 14px">
<DIV id="isForwardContent">
<DIV style="LINE-HEIGHT: 1.7; FONT-FAMILY: arial; COLOR: #000000; FONT-SIZE: 14px">
<DIV>&nbsp;</DIV>
<DIV>I am a second-year graduate student.Recently,i have done some research on xen and encounter a problem.Thus i send this e-mail to you for help.</DIV>
<DIV>On a physical machine&nbsp;with xen virtualization platform&nbsp;installed ,VM&nbsp;A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM&nbsp;B and VM C's virtual disk image files are based on VM A's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM B get a page data from VM A's virtual disk image file. After that ,VM C also need to get the same page data as VM B got just now.Under this situation, does VMM copy the page data from VM B's memory to VM C's memory or get the page data from&nbsp;VM A's virtual disk image file in the physical disk again?&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>HXK</DIV>
<DIV>Huazhong University of Science and Technology<BR>Wuhan, 430074, China</DIV></DIV><BR><BR><SPAN title="neteasefooter"><SPAN id="netease_mail_footer"></SPAN></SPAN></DIV></DIV><BR><BR><SPAN title="neteasefooter"><SPAN id="netease_mail_footer"></SPAN></SPAN></DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_25985_1656735142.1326416153105--



--===============0014835184203606995==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0014835184203606995==--



From xen-devel-bounces@lists.xensource.com Fri Jan 13 05:08:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 05:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlZMR-0004jG-DJ; Fri, 13 Jan 2012 05:07:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RlZMP-0004jB-UZ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 05:07:30 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326431240!10699858!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 8613 invoked from network); 13 Jan 2012 05:07:23 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-14.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Jan 2012 05:07:23 -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 1RlZMC-0003Fn-CV; Fri, 13 Jan 2012 16:07:16 +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, 13 Jan 2012 16:07:16 +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, 13 Jan 2012 16:07:14 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "W. Michael Petullo" <mike@flyn.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Questions about attacks on Xen
Thread-Index: AQHM0XDPpDqX1nxwIEG1w6lW20fXGpYJvd3A
Date: Fri, 13 Jan 2012 05:07:14 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0A4E0F@BITCOM1.int.sbss.com.au>
References: <20120112211927.GA13328@imp.flyn.org>
In-Reply-To: <20120112211927.GA13328@imp.flyn.org>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Jan 2012 05:07:16.0582 (UTC)
	FILETIME=[37FFA860:01CCD1B1]
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] Questions about attacks on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> I have some questions about attacks on Xen. I am preparing a paper for an
> operating system we have built on top of Xen and I want to ensure we have
> certain facts straight.  Among the things I have read include "Xen and the Art
> of Virtualization" and the XOAR paper.
> 
> First, what power does Dom0 have? Of course I know that Dom0 manages
> the other domains and has direct access to hardware. I know that Dom0 can
> not directly access the Xen hypervisor code in memory (except in the case of
> attacks using DMA on IOMMU-less systems). But what about
> Dom0 accessing DomU memory once the domain is running?
> 
> For isolation, our operating system encrypts all network traffic and disk I/O.
> We have also postulated that we could do the same of keyboard/display I/O.
> We can use vTPM to ensure trusted initialization. Are there other attack
> vectors other than Dom0 handling memory destined to or from an I/O
> device? Could Dom0 violate our DomU by directly accessing its memory? Are
> there any facilities in Xen 4 for restricting this? Where could I read more
> about this?
> 
> Thank you. I appreciate any responses, especially recommended reading.
> 

Dom0 has total power over DomU. I would say that you cannot be secure if you run on a machine with a "hostile" dom0 that your "secure" domU does not trust. For a start, the 'xm save' command writes out the entire DomU memory to a disk file, so you can already see that Dom0 has access to all DomU memory and CPU state, by design.

Every time DomU does network or disk access, it must pass an entire page of memory to Dom0, even if only part of that page is used, so there is a constant potential 'leak' of information from DomU to Dom0 in terms of the parts of that page that belong to other processes in DomU.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 05:08:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 05:08:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlZMR-0004jG-DJ; Fri, 13 Jan 2012 05:07:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RlZMP-0004jB-UZ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 05:07:30 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326431240!10699858!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 8613 invoked from network); 13 Jan 2012 05:07:23 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-14.tower-182.messagelabs.com with AES256-SHA encrypted SMTP;
	13 Jan 2012 05:07:23 -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 1RlZMC-0003Fn-CV; Fri, 13 Jan 2012 16:07:16 +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, 13 Jan 2012 16:07:16 +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, 13 Jan 2012 16:07:14 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "W. Michael Petullo" <mike@flyn.org>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [Xen-devel] Questions about attacks on Xen
Thread-Index: AQHM0XDPpDqX1nxwIEG1w6lW20fXGpYJvd3A
Date: Fri, 13 Jan 2012 05:07:14 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0A4E0F@BITCOM1.int.sbss.com.au>
References: <20120112211927.GA13328@imp.flyn.org>
In-Reply-To: <20120112211927.GA13328@imp.flyn.org>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Jan 2012 05:07:16.0582 (UTC)
	FILETIME=[37FFA860:01CCD1B1]
X-Really-From-Bendigo-IT: magichashvalue
Subject: Re: [Xen-devel] Questions about attacks on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> 
> I have some questions about attacks on Xen. I am preparing a paper for an
> operating system we have built on top of Xen and I want to ensure we have
> certain facts straight.  Among the things I have read include "Xen and the Art
> of Virtualization" and the XOAR paper.
> 
> First, what power does Dom0 have? Of course I know that Dom0 manages
> the other domains and has direct access to hardware. I know that Dom0 can
> not directly access the Xen hypervisor code in memory (except in the case of
> attacks using DMA on IOMMU-less systems). But what about
> Dom0 accessing DomU memory once the domain is running?
> 
> For isolation, our operating system encrypts all network traffic and disk I/O.
> We have also postulated that we could do the same of keyboard/display I/O.
> We can use vTPM to ensure trusted initialization. Are there other attack
> vectors other than Dom0 handling memory destined to or from an I/O
> device? Could Dom0 violate our DomU by directly accessing its memory? Are
> there any facilities in Xen 4 for restricting this? Where could I read more
> about this?
> 
> Thank you. I appreciate any responses, especially recommended reading.
> 

Dom0 has total power over DomU. I would say that you cannot be secure if you run on a machine with a "hostile" dom0 that your "secure" domU does not trust. For a start, the 'xm save' command writes out the entire DomU memory to a disk file, so you can already see that Dom0 has access to all DomU memory and CPU state, by design.

Every time DomU does network or disk access, it must pass an entire page of memory to Dom0, even if only part of that page is used, so there is a constant potential 'leak' of information from DomU to Dom0 in terms of the parts of that page that belong to other processes in DomU.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 05:31:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 05: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 1RlZjS-0004uv-Ge; Fri, 13 Jan 2012 05:31:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RlZjQ-0004ul-AV
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 05:31:16 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326432636!48206955!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 30556 invoked from network); 13 Jan 2012 05:30:37 -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;
	13 Jan 2012 05:30:37 -0000
Received: by qadz30 with SMTP id z30so4083287qad.9
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 21:31: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:cc; bh=5BvAFmlPdAw6ovrs9PR7GRYdYSAbYT/XkZbWaEwQaw0=;
	b=fEg1lRJL+w1gFDtJxrjFN53CqLqPqz/Zfkfudz4tK74dIGsfNZVz4ea/EMavzkRvvh
	wxtT3WsZ5PzFF5jhSasU39D37/1EzAFNd8f1aXbV9+Qkz6Eu2vMg6q22+bGeT0sSShWi
	6Ln167Xw2xqW1KWwegomlh/y+v1OTMw/0XiHs=
Received: by 10.224.45.6 with SMTP id c6mr1015951qaf.62.1326432670781;
	Thu, 12 Jan 2012 21:31:10 -0800 (PST)
Received: from xdev.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id
	dh10sm14445961qab.19.2012.01.12.21.31.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 12 Jan 2012 21:31:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1ab50ad829d6f0bd74ccecf21bfcc02ff9c619ca
Message-Id: <1ab50ad829d6f0bd74cc.1326432818@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326432817@xdev.gridcentric.ca>
References: <patchbomb.1326432817@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Jan 2012 00:33:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Don't ASSERT() for a valid mfn
 on paged p2m entries in guest_physmap_add
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4aa843efe1ac -r 1ab50ad829d6 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -489,7 +489,7 @@ guest_physmap_add_entry(struct domain *d
             
             return -EINVAL;
         }
-        else if ( p2m_is_ram(ot) )
+        else if ( p2m_is_ram(ot) && !p2m_is_paged(ot) )
         {
             ASSERT(mfn_valid(omfn));
             set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
@@ -514,7 +514,7 @@ guest_physmap_add_entry(struct domain *d
             P2M_DEBUG("aliased! mfn=%#lx, old gfn=%#lx, new gfn=%#lx\n",
                       mfn + i, ogfn, gfn + i);
             omfn = p2m->get_entry(p2m, ogfn, &ot, &a, p2m_query, NULL);
-            if ( p2m_is_ram(ot) )
+            if ( p2m_is_ram(ot) && !p2m_is_paged(ot) )
             {
                 ASSERT(mfn_valid(omfn));
                 P2M_DEBUG("old gfn=%#lx -> mfn %#lx\n",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 05:31:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 05: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 1RlZjS-0004uv-Ge; Fri, 13 Jan 2012 05:31:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RlZjQ-0004ul-AV
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 05:31:16 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326432636!48206955!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 30556 invoked from network); 13 Jan 2012 05:30:37 -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;
	13 Jan 2012 05:30:37 -0000
Received: by qadz30 with SMTP id z30so4083287qad.9
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 21:31: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:cc; bh=5BvAFmlPdAw6ovrs9PR7GRYdYSAbYT/XkZbWaEwQaw0=;
	b=fEg1lRJL+w1gFDtJxrjFN53CqLqPqz/Zfkfudz4tK74dIGsfNZVz4ea/EMavzkRvvh
	wxtT3WsZ5PzFF5jhSasU39D37/1EzAFNd8f1aXbV9+Qkz6Eu2vMg6q22+bGeT0sSShWi
	6Ln167Xw2xqW1KWwegomlh/y+v1OTMw/0XiHs=
Received: by 10.224.45.6 with SMTP id c6mr1015951qaf.62.1326432670781;
	Thu, 12 Jan 2012 21:31:10 -0800 (PST)
Received: from xdev.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id
	dh10sm14445961qab.19.2012.01.12.21.31.09
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 12 Jan 2012 21:31:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1ab50ad829d6f0bd74ccecf21bfcc02ff9c619ca
Message-Id: <1ab50ad829d6f0bd74cc.1326432818@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326432817@xdev.gridcentric.ca>
References: <patchbomb.1326432817@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Jan 2012 00:33:38 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] x86/mm: Don't ASSERT() for a valid mfn
 on paged p2m entries in guest_physmap_add
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4aa843efe1ac -r 1ab50ad829d6 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -489,7 +489,7 @@ guest_physmap_add_entry(struct domain *d
             
             return -EINVAL;
         }
-        else if ( p2m_is_ram(ot) )
+        else if ( p2m_is_ram(ot) && !p2m_is_paged(ot) )
         {
             ASSERT(mfn_valid(omfn));
             set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
@@ -514,7 +514,7 @@ guest_physmap_add_entry(struct domain *d
             P2M_DEBUG("aliased! mfn=%#lx, old gfn=%#lx, new gfn=%#lx\n",
                       mfn + i, ogfn, gfn + i);
             omfn = p2m->get_entry(p2m, ogfn, &ot, &a, p2m_query, NULL);
-            if ( p2m_is_ram(ot) )
+            if ( p2m_is_ram(ot) && !p2m_is_paged(ot) )
             {
                 ASSERT(mfn_valid(omfn));
                 P2M_DEBUG("old gfn=%#lx -> mfn %#lx\n",

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 05:31:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 05: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 1RlZjU-0004vD-9T; Fri, 13 Jan 2012 05:31:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RlZjT-0004um-1K
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 05:31:19 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326432670!10709115!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 2883 invoked from network); 13 Jan 2012 05:31:12 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 05:31:12 -0000
Received: by mail-qy0-f171.google.com with SMTP id r14so1643944qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 21:31:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=08GFqAuoxBOfrK49pYMAEcQQ7BFXiw9RnM0sL9jEn5I=;
	b=T/FSxSE/7XdUzA9901PilJCmnk9foorkyeZte/PcbxANMIWyBCKXapYp/hM4B2Esyy
	C4XpU/7Dx5mrS4K+rSEGy/ySDOxCQqPEl/alHOZSoCkCsIEAz4MIB7lvscJcbNoAoWnM
	3V6J0mAR+u5JP2ZD2kULF5fjZEPGWaRbEs2+0=
Received: by 10.229.102.72 with SMTP id f8mr291879qco.53.1326432672219;
	Thu, 12 Jan 2012 21:31:12 -0800 (PST)
Received: from xdev.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id
	dh10sm14445961qab.19.2012.01.12.21.31.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 12 Jan 2012 21:31:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: abdb908c0aedfee298c4342bee16fece04f16cec
Message-Id: <abdb908c0aedfee298c4.1326432819@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326432817@xdev.gridcentric.ca>
References: <patchbomb.1326432817@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Jan 2012 00:33:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Correct p2m unlocking during grant table
	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>
Content-Type: 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/grant_table.c |  8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)


We were not putting gfn's consistently.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1ab50ad829d6 -r abdb908c0aed xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -141,7 +141,7 @@ shared_entry_header(struct grant_table *
 #define active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
-/* Check if the page has been paged out */
+/* Check if the page has been paged out. If rc == GNTST_okay, caller must do put_gfn(rd, gfn) */
 static int __get_paged_frame(unsigned long gfn, unsigned long *frame, int readonly, struct domain *rd)
 {
     int rc = GNTST_okay;
@@ -573,7 +573,10 @@ __gnttab_map_grant_ref(
             gfn = sha1 ? sha1->frame : sha2->full_page.frame;
             rc = __get_paged_frame(gfn, &frame, !!(op->flags & GNTMAP_readonly), rd);
             if ( rc != GNTST_okay )
+            {
+                gfn = INVALID_GFN;
                 goto unlock_out;
+            }
             act->gfn = gfn;
             act->domid = ld->domain_id;
             act->frame = frame;
@@ -700,7 +703,8 @@ __gnttab_map_grant_ref(
     op->handle       = handle;
     op->status       = GNTST_okay;
 
-    put_gfn(rd, gfn);
+    if ( gfn != INVALID_GFN )
+        put_gfn(rd, gfn);
     rcu_unlock_domain(rd);
     return;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 05:31:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 05: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 1RlZjU-0004vD-9T; Fri, 13 Jan 2012 05:31:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RlZjT-0004um-1K
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 05:31:19 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326432670!10709115!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 2883 invoked from network); 13 Jan 2012 05:31:12 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 05:31:12 -0000
Received: by mail-qy0-f171.google.com with SMTP id r14so1643944qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 21:31:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to:cc; bh=08GFqAuoxBOfrK49pYMAEcQQ7BFXiw9RnM0sL9jEn5I=;
	b=T/FSxSE/7XdUzA9901PilJCmnk9foorkyeZte/PcbxANMIWyBCKXapYp/hM4B2Esyy
	C4XpU/7Dx5mrS4K+rSEGy/ySDOxCQqPEl/alHOZSoCkCsIEAz4MIB7lvscJcbNoAoWnM
	3V6J0mAR+u5JP2ZD2kULF5fjZEPGWaRbEs2+0=
Received: by 10.229.102.72 with SMTP id f8mr291879qco.53.1326432672219;
	Thu, 12 Jan 2012 21:31:12 -0800 (PST)
Received: from xdev.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id
	dh10sm14445961qab.19.2012.01.12.21.31.10
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 12 Jan 2012 21:31:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: abdb908c0aedfee298c4342bee16fece04f16cec
Message-Id: <abdb908c0aedfee298c4.1326432819@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326432817@xdev.gridcentric.ca>
References: <patchbomb.1326432817@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Jan 2012 00:33:39 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] Correct p2m unlocking during grant table
	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>
Content-Type: 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/grant_table.c |  8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)


We were not putting gfn's consistently.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 1ab50ad829d6 -r abdb908c0aed xen/common/grant_table.c
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -141,7 +141,7 @@ shared_entry_header(struct grant_table *
 #define active_entry(t, e) \
     ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
-/* Check if the page has been paged out */
+/* Check if the page has been paged out. If rc == GNTST_okay, caller must do put_gfn(rd, gfn) */
 static int __get_paged_frame(unsigned long gfn, unsigned long *frame, int readonly, struct domain *rd)
 {
     int rc = GNTST_okay;
@@ -573,7 +573,10 @@ __gnttab_map_grant_ref(
             gfn = sha1 ? sha1->frame : sha2->full_page.frame;
             rc = __get_paged_frame(gfn, &frame, !!(op->flags & GNTMAP_readonly), rd);
             if ( rc != GNTST_okay )
+            {
+                gfn = INVALID_GFN;
                 goto unlock_out;
+            }
             act->gfn = gfn;
             act->domid = ld->domain_id;
             act->frame = frame;
@@ -700,7 +703,8 @@ __gnttab_map_grant_ref(
     op->handle       = handle;
     op->status       = GNTST_okay;
 
-    put_gfn(rd, gfn);
+    if ( gfn != INVALID_GFN )
+        put_gfn(rd, gfn);
     rcu_unlock_domain(rd);
     return;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 05:31:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 05: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 1RlZjS-0004v2-Su; Fri, 13 Jan 2012 05:31:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RlZjS-0004uk-06
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 05:31:18 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326432670!10709115!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 2853 invoked from network); 13 Jan 2012 05:31:11 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 05:31:11 -0000
Received: by qcsr14 with SMTP id r14so1643944qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 21:31: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
	:message-id:user-agent:date:from:to:cc;
	bh=aBIztjJt1F9+PBKiBA4SGU2qR3+xsxTlGaL8pdmcUhI=;
	b=vok8LLbNFUXYGgQqansV3aUm3JigkY9DuYfPPncbcVZp2QGD0g92ZdYaScOq11emIE
	AjHhQtgffANEOgwdQzxpzWQn6c5IkKk6ugWCv4tBq9kSANT+rFdmxBDqglZdveK++3cY
	lViz7Fy88UTEEtfYLxz3j26lj8IJO3MN6uF/4=
Received: by 10.229.137.19 with SMTP id u19mr294196qct.47.1326432669602;
	Thu, 12 Jan 2012 21:31:09 -0800 (PST)
Received: from xdev.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id
	dh10sm14445961qab.19.2012.01.12.21.31.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 12 Jan 2012 21:31:08 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326432817@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Jan 2012 00:33:37 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Two p2m 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

- An assert for an invalid mfn was being triggered in 
  guest_physmap_add_entry, even though the target gfn was paged out.

- Fix how gfn's are put when mapping grants.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/p2m.c    |  4 ++--
 xen/common/grant_table.c |  8 ++++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 05:31:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 05: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 1RlZjS-0004v2-Su; Fri, 13 Jan 2012 05:31:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres.lagarcavilla@gmail.com>) id 1RlZjS-0004uk-06
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 05:31:18 +0000
X-Env-Sender: andres.lagarcavilla@gmail.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326432670!10709115!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 2853 invoked from network); 13 Jan 2012 05:31:11 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 05:31:11 -0000
Received: by qcsr14 with SMTP id r14so1643944qcs.30
	for <xen-devel@lists.xensource.com>;
	Thu, 12 Jan 2012 21:31: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
	:message-id:user-agent:date:from:to:cc;
	bh=aBIztjJt1F9+PBKiBA4SGU2qR3+xsxTlGaL8pdmcUhI=;
	b=vok8LLbNFUXYGgQqansV3aUm3JigkY9DuYfPPncbcVZp2QGD0g92ZdYaScOq11emIE
	AjHhQtgffANEOgwdQzxpzWQn6c5IkKk6ugWCv4tBq9kSANT+rFdmxBDqglZdveK++3cY
	lViz7Fy88UTEEtfYLxz3j26lj8IJO3MN6uF/4=
Received: by 10.229.137.19 with SMTP id u19mr294196qct.47.1326432669602;
	Thu, 12 Jan 2012 21:31:09 -0800 (PST)
Received: from xdev.gridcentric.ca ([206.223.182.18])
	by mx.google.com with ESMTPS id
	dh10sm14445961qab.19.2012.01.12.21.31.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 12 Jan 2012 21:31:08 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326432817@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 13 Jan 2012 00:33:37 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: andres@gridcentric.ca, tim@xen.org, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] Two p2m 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

- An assert for an invalid mfn was being triggered in 
  guest_physmap_add_entry, even though the target gfn was paged out.

- Fix how gfn's are put when mapping grants.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/p2m.c    |  4 ++--
 xen/common/grant_table.c |  8 ++++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 07:55:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 07: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 1Rlbyh-0006a2-J4; Fri, 13 Jan 2012 07:55:11 +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 1Rlbyg-0006Zu-1y
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 07:55:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326441303!8959219!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 4949 invoked from network); 13 Jan 2012 07:55:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jan 2012 07:55:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 07:55:02 +0000
Message-Id: <4F0FF1A0020000780006C58E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 07:56:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

>>> On 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/arch/ia64/xen/mm.c
> +++ b/xen/arch/ia64/xen/mm.c
> @@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case XENMEM_remove_from_physmap:
> +    {
> +        struct xen_remove_from_physmap xrfp;
> +        unsigned long mfn;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xrfp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        if ( xsm_remove_from_physmap(current->domain, d) )
> +        {
> +            rcu_unlock_domain(d);
> +            return -EPERM;
> +        }
> +
> +        domain_lock(d);
> +
> +        mfn = gmfn_to_mfn(d, xrfp.gpfn);
> +
> +        if ( mfn_valid(mfn) )
> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);

Here and in the other similar paths - is it really to be considered
'success' if !mfn_valid(mfn)?

Further, given that the code looks all the same between ia64 and x86
- is this really arch-specific (the get_gfn_untyped() and put_gfn() used
in x86 should really be stubbed out for ia64 anyway)?

> +
> +        domain_unlock(d);
> +
> +        rcu_unlock_domain(d);
> +
> +        break;
> +    }
> +
> +
>      case XENMEM_machine_memory_map:
>      {
>          struct xen_memory_map memmap;
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -81,6 +81,7 @@
>  !	processor_power			platform.h
>  ?	processor_px			platform.h
>  !	psd_package			platform.h
> +!	remove_from_physmap		memory.h

Sorry, but this is not how I meant my comment on v1 to be
interpreted - I thought that by looking at the rest of the file it would
go without saying that the sorting is by header name (alphabetically),
then by type name (again alphabetically). (I realize there are other
cases where sorting is not fully correct, but as I'm striving to adjust
this via secondary changes, I'd like to avoid getting the situation
worse with new additions.)

>  ?	xenpf_pcpuinfo			platform.h
>  ?	xenpf_pcpu_version		platform.h
>  !	sched_poll			sched.h

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 07:55:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 07: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 1Rlbyh-0006a2-J4; Fri, 13 Jan 2012 07:55:11 +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 1Rlbyg-0006Zu-1y
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 07:55:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326441303!8959219!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 4949 invoked from network); 13 Jan 2012 07:55:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 13 Jan 2012 07:55:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 07:55:02 +0000
Message-Id: <4F0FF1A0020000780006C58E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 07:56:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

>>> On 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/arch/ia64/xen/mm.c
> +++ b/xen/arch/ia64/xen/mm.c
> @@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case XENMEM_remove_from_physmap:
> +    {
> +        struct xen_remove_from_physmap xrfp;
> +        unsigned long mfn;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xrfp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        if ( xsm_remove_from_physmap(current->domain, d) )
> +        {
> +            rcu_unlock_domain(d);
> +            return -EPERM;
> +        }
> +
> +        domain_lock(d);
> +
> +        mfn = gmfn_to_mfn(d, xrfp.gpfn);
> +
> +        if ( mfn_valid(mfn) )
> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);

Here and in the other similar paths - is it really to be considered
'success' if !mfn_valid(mfn)?

Further, given that the code looks all the same between ia64 and x86
- is this really arch-specific (the get_gfn_untyped() and put_gfn() used
in x86 should really be stubbed out for ia64 anyway)?

> +
> +        domain_unlock(d);
> +
> +        rcu_unlock_domain(d);
> +
> +        break;
> +    }
> +
> +
>      case XENMEM_machine_memory_map:
>      {
>          struct xen_memory_map memmap;
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -81,6 +81,7 @@
>  !	processor_power			platform.h
>  ?	processor_px			platform.h
>  !	psd_package			platform.h
> +!	remove_from_physmap		memory.h

Sorry, but this is not how I meant my comment on v1 to be
interpreted - I thought that by looking at the rest of the file it would
go without saying that the sorting is by header name (alphabetically),
then by type name (again alphabetically). (I realize there are other
cases where sorting is not fully correct, but as I'm striving to adjust
this via secondary changes, I'd like to avoid getting the situation
worse with new additions.)

>  ?	xenpf_pcpuinfo			platform.h
>  ?	xenpf_pcpu_version		platform.h
>  !	sched_poll			sched.h

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:03:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlc62-0007Cz-W6; Fri, 13 Jan 2012 08:02:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rlc62-0007Cq-Cs
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:02:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326441759!8944344!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 26739 invoked from network); 13 Jan 2012 08:02:39 -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; 13 Jan 2012 08:02:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 08:02:38 +0000
Message-Id: <4F0FF367020000780006C59D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 08:03:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> +int set_global_virq_handler(struct domain *d, uint32_t virq)
> +{
> +    struct domain *old;
> +
> +    if (virq >= NR_VIRQS)
> +        return -EINVAL;
> +    if (!virq_is_global(virq))
> +        return -EINVAL;
> +
> +    if (global_virq_handlers[virq] == d)
> +        return 0;
> +
> +    if (unlikely(!get_domain(d)))
> +        return -EINVAL;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +    old = global_virq_handlers[virq];
> +    global_virq_handlers[virq] = d;
> +    spin_unlock(&global_virq_handlers_lock);
> +
> +    if (old != NULL)
> +        put_domain(old);
> +
> +    return 0;
> +}
> +
> +static void clear_global_virq_handlers(struct domain *d)
> +{
> +    uint32_t virq;
> +    int put_count = 0;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +
> +    for (virq = 0; virq < NR_VIRQS; virq++) {
> +        if (global_virq_handlers[virq] == d) {
> +            global_virq_handlers[virq] = NULL;
> +            put_count++;
> +        }
> +    }
> +
> +    spin_unlock(&global_virq_handlers_lock);
> +
> +    while (put_count) {
> +        put_domain(d);
> +        put_count--;
> +    }
> +}

Formatting in this entire hunk should be changed to match that of the
rest of the file.

> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -64,6 +64,7 @@ struct xsm_operations {
>      int (*domain_settime) (struct domain *d);
>      int (*set_target) (struct domain *d, struct domain *e);
>      int (*domctl) (struct domain *d, int cmd);
> +    int (*set_virq_handler) (struct domain *d, int virq);

Here and further down, the 'int' still survived.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:03:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08:03:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlc62-0007Cz-W6; Fri, 13 Jan 2012 08:02:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rlc62-0007Cq-Cs
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:02:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326441759!8944344!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 26739 invoked from network); 13 Jan 2012 08:02:39 -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; 13 Jan 2012 08:02:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 08:02:38 +0000
Message-Id: <4F0FF367020000780006C59D@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 08:03:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> +int set_global_virq_handler(struct domain *d, uint32_t virq)
> +{
> +    struct domain *old;
> +
> +    if (virq >= NR_VIRQS)
> +        return -EINVAL;
> +    if (!virq_is_global(virq))
> +        return -EINVAL;
> +
> +    if (global_virq_handlers[virq] == d)
> +        return 0;
> +
> +    if (unlikely(!get_domain(d)))
> +        return -EINVAL;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +    old = global_virq_handlers[virq];
> +    global_virq_handlers[virq] = d;
> +    spin_unlock(&global_virq_handlers_lock);
> +
> +    if (old != NULL)
> +        put_domain(old);
> +
> +    return 0;
> +}
> +
> +static void clear_global_virq_handlers(struct domain *d)
> +{
> +    uint32_t virq;
> +    int put_count = 0;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +
> +    for (virq = 0; virq < NR_VIRQS; virq++) {
> +        if (global_virq_handlers[virq] == d) {
> +            global_virq_handlers[virq] = NULL;
> +            put_count++;
> +        }
> +    }
> +
> +    spin_unlock(&global_virq_handlers_lock);
> +
> +    while (put_count) {
> +        put_domain(d);
> +        put_count--;
> +    }
> +}

Formatting in this entire hunk should be changed to match that of the
rest of the file.

> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -64,6 +64,7 @@ struct xsm_operations {
>      int (*domain_settime) (struct domain *d);
>      int (*set_target) (struct domain *d, struct domain *e);
>      int (*domctl) (struct domain *d, int cmd);
> +    int (*set_virq_handler) (struct domain *d, int virq);

Here and further down, the 'int' still survived.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:07:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08: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 1Rlc9s-0007LC-Kq; Fri, 13 Jan 2012 08:06:44 +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 1Rlc9r-0007Kx-JW
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:06:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326441997!10741223!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 29768 invoked from network); 13 Jan 2012 08:06:37 -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; 13 Jan 2012 08:06:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 08:06:37 +0000
Message-Id: <4F0FF457020000780006C5B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 08:07:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries
 when switching 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 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -117,6 +117,12 @@ struct grant_entry_v1 {
>  };
>  typedef struct grant_entry_v1 grant_entry_v1_t;
>  
> +/* External tools reserve first few grant table entries. */

This reads as if they must not be used (but could without taking extra
care) by other than the tools themselves, which would be an
incompatible change. As my understanding is that the change is
backwards compatible, I would suggest adjusting the comment.

Jan

> +#define GNTTAB_NR_RESERVED_ENTRIES     8
> +#define GNTTAB_RESERVED_CONSOLE        0
> +#define GNTTAB_RESERVED_XENSTORE       1
> +/* (the next 6 are reserved for future use) */
> +
>  /*
>   * Type of grant entry.
>   *  GTF_invalid: This grant entry grants no privileges.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:07:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08: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 1Rlc9s-0007LC-Kq; Fri, 13 Jan 2012 08:06:44 +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 1Rlc9r-0007Kx-JW
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:06:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326441997!10741223!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 29768 invoked from network); 13 Jan 2012 08:06:37 -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; 13 Jan 2012 08:06:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 08:06:37 +0000
Message-Id: <4F0FF457020000780006C5B1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 08:07:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 04/18] xen: Preserve reserved grant entries
 when switching 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 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -117,6 +117,12 @@ struct grant_entry_v1 {
>  };
>  typedef struct grant_entry_v1 grant_entry_v1_t;
>  
> +/* External tools reserve first few grant table entries. */

This reads as if they must not be used (but could without taking extra
care) by other than the tools themselves, which would be an
incompatible change. As my understanding is that the change is
backwards compatible, I would suggest adjusting the comment.

Jan

> +#define GNTTAB_NR_RESERVED_ENTRIES     8
> +#define GNTTAB_RESERVED_CONSOLE        0
> +#define GNTTAB_RESERVED_XENSTORE       1
> +/* (the next 6 are reserved for future use) */
> +
>  /*
>   * Type of grant entry.
>   *  GTF_invalid: This grant entry grants no privileges.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:09:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlcCS-0007T1-8p; Fri, 13 Jan 2012 08:09:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlcCQ-0007So-8e
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:09:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326442154!8304603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDkwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7311 invoked from network); 13 Jan 2012 08:09:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 08:09:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9988466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 08:09:14 +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, 13 Jan 2012 08:09:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1326408997.4494.11.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304831.12973.3.camel@Abyss>
	<1326357782.17210.213.camel@zakaz.uk.xensource.com>
	<1326408997.4494.11.camel@Abyss>
Organization: Citrix Systems, Inc.
Date: Fri, 13 Jan 2012 08:09:13 +0000
Message-ID: <1326442153.29084.110.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 22:56 +0000, Dario Faggioli wrote:
> On Thu, 2012-01-12 at 08:43 +0000, Ian Campbell wrote: 
> > > diff -r 9ce68a4036b1 tools/libxl/libxl_create.c
> > > --- a/tools/libxl/libxl_create.c	Wed Jan 11 17:38:04 2012 +0000
> > > +++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:40:45 2012 +0000
> > > @@ -78,6 +78,8 @@ int libxl_init_build_info(libxl_ctx *ctx
> > >      memset(b_info, '\0', sizeof(*b_info));
> > >      b_info->max_vcpus = 1;
> > >      b_info->cur_vcpus = 1;
> > > +    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
> > > +        return ERROR_NOMEM;
> > 
> > Should probably set all here since that is the best default?
> > 
> Having this set to "none" here simplifies a bit the code when we came to
> config file parsing (if I set it to "any CPU" here, I'll have to reset
> to "none" before parsing). Also, default is exactly what you're
> suggesting already, as I set the map to "any CPU" if no "cpus" config
> option is found.

xl's default is "any CPU" but libxl's default is "no CPU" which will
mean every toolstack author needs to do be aware of this even if they
don't care about affinity.

> Anyway, I guess I can do as you suggest if you really think it's
> better. :-)

Please ;-)

> > >  static void parse_config_data(const char *configfile_filename_report,
> > >                                const char *configfile_data,
> > >                                int configfile_len,
> > > @@ -661,6 +674,13 @@ static void parse_config_data(const char
> > >      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
> > >          b_info->max_vcpus = l;
> > >  
> > > +    if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
> > 
> > The syntax supported here is different to that in a cpupool cfg? (see
> > main_cpupoolcreate) Perhaps they should be similar?
> > 
> It is different, and that was intentional. What I wanted, was the syntax
> to be exactly the same of `xl vcpu-pin', which is the command line
> equivalent of this option, much more than cpupool-*. If you want, I
> think I can easily enable list-like CPU specification as in cpupool
> config file so that _both_ syntax are allowed. What do you think?

I think supporting both makes sense, we do something similar in a couple
of places already.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:09:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08:09:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlcCS-0007T1-8p; Fri, 13 Jan 2012 08:09:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlcCQ-0007So-8e
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:09:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326442154!8304603!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MDkwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7311 invoked from network); 13 Jan 2012 08:09:14 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 08:09:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9988466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 08:09:14 +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, 13 Jan 2012 08:09:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1326408997.4494.11.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304831.12973.3.camel@Abyss>
	<1326357782.17210.213.camel@zakaz.uk.xensource.com>
	<1326408997.4494.11.camel@Abyss>
Organization: Citrix Systems, Inc.
Date: Fri, 13 Jan 2012 08:09:13 +0000
Message-ID: <1326442153.29084.110.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 22:56 +0000, Dario Faggioli wrote:
> On Thu, 2012-01-12 at 08:43 +0000, Ian Campbell wrote: 
> > > diff -r 9ce68a4036b1 tools/libxl/libxl_create.c
> > > --- a/tools/libxl/libxl_create.c	Wed Jan 11 17:38:04 2012 +0000
> > > +++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:40:45 2012 +0000
> > > @@ -78,6 +78,8 @@ int libxl_init_build_info(libxl_ctx *ctx
> > >      memset(b_info, '\0', sizeof(*b_info));
> > >      b_info->max_vcpus = 1;
> > >      b_info->cur_vcpus = 1;
> > > +    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
> > > +        return ERROR_NOMEM;
> > 
> > Should probably set all here since that is the best default?
> > 
> Having this set to "none" here simplifies a bit the code when we came to
> config file parsing (if I set it to "any CPU" here, I'll have to reset
> to "none" before parsing). Also, default is exactly what you're
> suggesting already, as I set the map to "any CPU" if no "cpus" config
> option is found.

xl's default is "any CPU" but libxl's default is "no CPU" which will
mean every toolstack author needs to do be aware of this even if they
don't care about affinity.

> Anyway, I guess I can do as you suggest if you really think it's
> better. :-)

Please ;-)

> > >  static void parse_config_data(const char *configfile_filename_report,
> > >                                const char *configfile_data,
> > >                                int configfile_len,
> > > @@ -661,6 +674,13 @@ static void parse_config_data(const char
> > >      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
> > >          b_info->max_vcpus = l;
> > >  
> > > +    if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
> > 
> > The syntax supported here is different to that in a cpupool cfg? (see
> > main_cpupoolcreate) Perhaps they should be similar?
> > 
> It is different, and that was intentional. What I wanted, was the syntax
> to be exactly the same of `xl vcpu-pin', which is the command line
> equivalent of this option, much more than cpupool-*. If you want, I
> think I can easily enable list-like CPU specification as in cpupool
> config file so that _both_ syntax are allowed. What do you think?

I think supporting both makes sense, we do something similar in a couple
of places already.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:11:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlcEJ-0007ah-PY; Fri, 13 Jan 2012 08:11: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 1RlcEH-0007aM-Fz
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:11:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326442270!10723273!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 21523 invoked from network); 13 Jan 2012 08:11:11 -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; 13 Jan 2012 08:11:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 08:11:10 +0000
Message-Id: <4F0FF567020000780006C5B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 08:12:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
In-Reply-To: <1442969761.20120112230601@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.01.12 at 23:06, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Another thing i was wondering about, couldn't the hypervisor offer a small 
> window in 32bit addressable mem to all (or only when pci passthrough is used) 
> domU's to be used for DMA ?

How would use of such a range be arbitrated/protected? You'd have to
ask for reservation (aka allocation) of a chunk anyway, which is as good
as using the existing interfaces to obtain address restricted memory
(and the hypervisor has a [rudimentary] mechanism to preserve some
low memory for DMA allocations).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:11:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlcEJ-0007ah-PY; Fri, 13 Jan 2012 08:11: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 1RlcEH-0007aM-Fz
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:11:17 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326442270!10723273!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 21523 invoked from network); 13 Jan 2012 08:11:11 -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; 13 Jan 2012 08:11:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 08:11:10 +0000
Message-Id: <4F0FF567020000780006C5B6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 08:12:07 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
In-Reply-To: <1442969761.20120112230601@eikelenboom.it>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 12.01.12 at 23:06, Sander Eikelenboom <linux@eikelenboom.it> wrote:
> Another thing i was wondering about, couldn't the hypervisor offer a small 
> window in 32bit addressable mem to all (or only when pci passthrough is used) 
> domU's to be used for DMA ?

How would use of such a range be arbitrated/protected? You'd have to
ask for reservation (aka allocation) of a chunk anyway, which is as good
as using the existing interfaces to obtain address restricted memory
(and the hypervisor has a [rudimentary] mechanism to preserve some
low memory for DMA allocations).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:19:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlcLx-0007zM-Dz; Fri, 13 Jan 2012 08:19:13 +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 1RlcLv-0007yx-Fy
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:19:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326442745!10730606!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 21426 invoked from network); 13 Jan 2012 08:19:05 -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; 13 Jan 2012 08:19:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 08:19:05 +0000
Message-Id: <4F0FF742020000780006C5CE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 08:20:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/include/xen/xenbus_dev.h
> +++ b/include/xen/xenbus_dev.h
> @@ -38,4 +38,18 @@
>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>  	_IOC(_IOC_NONE, 'B', 0, 0)
>  
> +#define IOCTL_XENBUS_ALLOC				\
> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
> +struct ioctl_xenbus_alloc {
> +	/* IN */
> +	/* The domain ID (must exist) for xenstore */
> +	uint16_t dom;
> +	uint16_t pad;
> +	/* OUT */
> +	/* The port allocated for xenbus communication */
> +	uint32_t port;
> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
> +	uint32_t grant_ref;
> +};

As said in my reply to the previous patch version - if the functionality
differs, the number *and* name should be different from the legacy
implementation's. Otherwise, how should compatible user space code
be written?

Jan

> +
>  #endif /* __LINUX_XEN_XENBUS_DEV_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 08:19:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 08:19:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlcLx-0007zM-Dz; Fri, 13 Jan 2012 08:19:13 +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 1RlcLv-0007yx-Fy
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 08:19:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326442745!10730606!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 21426 invoked from network); 13 Jan 2012 08:19:05 -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; 13 Jan 2012 08:19:05 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 08:19:05 +0000
Message-Id: <4F0FF742020000780006C5CE@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 08:20:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
In-Reply-To: <1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> --- a/include/xen/xenbus_dev.h
> +++ b/include/xen/xenbus_dev.h
> @@ -38,4 +38,18 @@
>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>  	_IOC(_IOC_NONE, 'B', 0, 0)
>  
> +#define IOCTL_XENBUS_ALLOC				\
> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
> +struct ioctl_xenbus_alloc {
> +	/* IN */
> +	/* The domain ID (must exist) for xenstore */
> +	uint16_t dom;
> +	uint16_t pad;
> +	/* OUT */
> +	/* The port allocated for xenbus communication */
> +	uint32_t port;
> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
> +	uint32_t grant_ref;
> +};

As said in my reply to the previous patch version - if the functionality
differs, the number *and* name should be different from the legacy
implementation's. Otherwise, how should compatible user space code
be written?

Jan

> +
>  #endif /* __LINUX_XEN_XENBUS_DEV_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 09:15:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 09:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RldCz-00007S-0Q; Fri, 13 Jan 2012 09:14:01 +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 1RldCx-00007N-79
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 09:13:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326445982!52373451!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 27827 invoked from network); 13 Jan 2012 09:13:02 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-27.messagelabs.com with SMTP;
	13 Jan 2012 09:13:02 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.116.146])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74474469; Fri, 13 Jan 2012 10:13:52 +0100
Message-ID: <1326446014.2397.2.camel@Abyss.citrite.net>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 13 Jan 2012 09:13:34 +0000
In-Reply-To: <1326442153.29084.110.camel@dagon.hellion.org.uk>
References: <1326304198.2401.6.camel@Abyss> <1326304831.12973.3.camel@Abyss>
	<1326357782.17210.213.camel@zakaz.uk.xensource.com>
	<1326408997.4494.11.camel@Abyss>
	<1326442153.29084.110.camel@dagon.hellion.org.uk>
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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============1518013184561947225=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1518013184561947225==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-qMsmrjnoslYQ35ReUtyH"


--=-qMsmrjnoslYQ35ReUtyH
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-13 at 08:09 +0000, Ian Campbell wrote:=20
> > Having this set to "none" here simplifies a bit the code when we came t=
o
> > config file parsing (if I set it to "any CPU" here, I'll have to reset
> > to "none" before parsing). Also, default is exactly what you're
> > suggesting already, as I set the map to "any CPU" if no "cpus" config
> > option is found.
>=20
> xl's default is "any CPU" but libxl's default is "no CPU" which will
> mean every toolstack author needs to do be aware of this even if they
> don't care about affinity.
>=20
Ok, I think I see your point now, which I didn't in the first place, and
neither yesterday while replying. Sorry, my fault, I agree I need to set
it to "any CPU" right here.

> > Anyway, I guess I can do as you suggest if you really think it's
> > better. :-)
>=20
> Please ;-)
>=20
Sure, will do like that.

> > It is different, and that was intentional. What I wanted, was the synta=
x
> > to be exactly the same of `xl vcpu-pin', which is the command line
> > equivalent of this option, much more than cpupool-*. If you want, I
> > think I can easily enable list-like CPU specification as in cpupool
> > config file so that _both_ syntax are allowed. What do you think?
>=20
> I think supporting both makes sense, we do something similar in a couple
> of places already.
>=20
Ok then.

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)



--=-qMsmrjnoslYQ35ReUtyH
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)

iEYEABECAAYFAk8P9b4ACgkQk4XaBE3IOsQw3wCgmylrVFHK1nncJAgZFZkrQqux
MVAAnR803uG3hKPRXUE6ejbU8WIs8VFr
=whDY
-----END PGP SIGNATURE-----

--=-qMsmrjnoslYQ35ReUtyH--



--===============1518013184561947225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1518013184561947225==--



From xen-devel-bounces@lists.xensource.com Fri Jan 13 09:15:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 09:15:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RldCz-00007S-0Q; Fri, 13 Jan 2012 09:14:01 +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 1RldCx-00007N-79
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 09:13:59 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326445982!52373451!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 27827 invoked from network); 13 Jan 2012 09:13:02 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-3.tower-27.messagelabs.com with SMTP;
	13 Jan 2012 09:13:02 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.116.146])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74474469; Fri, 13 Jan 2012 10:13:52 +0100
Message-ID: <1326446014.2397.2.camel@Abyss.citrite.net>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 13 Jan 2012 09:13:34 +0000
In-Reply-To: <1326442153.29084.110.camel@dagon.hellion.org.uk>
References: <1326304198.2401.6.camel@Abyss> <1326304831.12973.3.camel@Abyss>
	<1326357782.17210.213.camel@zakaz.uk.xensource.com>
	<1326408997.4494.11.camel@Abyss>
	<1326442153.29084.110.camel@dagon.hellion.org.uk>
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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============1518013184561947225=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1518013184561947225==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-qMsmrjnoslYQ35ReUtyH"


--=-qMsmrjnoslYQ35ReUtyH
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-13 at 08:09 +0000, Ian Campbell wrote:=20
> > Having this set to "none" here simplifies a bit the code when we came t=
o
> > config file parsing (if I set it to "any CPU" here, I'll have to reset
> > to "none" before parsing). Also, default is exactly what you're
> > suggesting already, as I set the map to "any CPU" if no "cpus" config
> > option is found.
>=20
> xl's default is "any CPU" but libxl's default is "no CPU" which will
> mean every toolstack author needs to do be aware of this even if they
> don't care about affinity.
>=20
Ok, I think I see your point now, which I didn't in the first place, and
neither yesterday while replying. Sorry, my fault, I agree I need to set
it to "any CPU" right here.

> > Anyway, I guess I can do as you suggest if you really think it's
> > better. :-)
>=20
> Please ;-)
>=20
Sure, will do like that.

> > It is different, and that was intentional. What I wanted, was the synta=
x
> > to be exactly the same of `xl vcpu-pin', which is the command line
> > equivalent of this option, much more than cpupool-*. If you want, I
> > think I can easily enable list-like CPU specification as in cpupool
> > config file so that _both_ syntax are allowed. What do you think?
>=20
> I think supporting both makes sense, we do something similar in a couple
> of places already.
>=20
Ok then.

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)



--=-qMsmrjnoslYQ35ReUtyH
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)

iEYEABECAAYFAk8P9b4ACgkQk4XaBE3IOsQw3wCgmylrVFHK1nncJAgZFZkrQqux
MVAAnR803uG3hKPRXUE6ejbU8WIs8VFr
=whDY
-----END PGP SIGNATURE-----

--=-qMsmrjnoslYQ35ReUtyH--



--===============1518013184561947225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1518013184561947225==--



From xen-devel-bounces@lists.xensource.com Fri Jan 13 09:51:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 09:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RldmT-0000OV-U7; Fri, 13 Jan 2012 09:50:41 +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 1RldmR-0000OP-V6
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 09:50:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326448232!10864354!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTcwMzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTcwMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29954 invoked from network); 13 Jan 2012 09:50:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 09:50:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326448232; l=2386;
	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=KDgJXegMN2nV3BIYkyLtJAUKm0o=;
	b=MsN6LasH8oU25YhYnnaqkqPdPQQQU70b0AdjIZrTjd0o59Xz5Nw1kbi4IL+3dbYaM5Y
	BoiRL5ewvALn/xJxlF+AxpGD8e5sM4W3Gy7NPxv1iou9OoVik/17I6ZP2VNHmydSEKU/B
	GT4ij9SO3uBOdM2rcBKFLUEztl/rsmD6O/E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhi0PFa/V
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-098-169.pools.arcor-ip.net [88.65.98.169])
	by smtp.strato.de (jimi mo64) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id t01366o0D9H3Q6 ;
	Fri, 13 Jan 2012 10:50:23 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 022CE18637; Fri, 13 Jan 2012 10:50:22 +0100 (CET)
Date: Fri, 13 Jan 2012 10:50:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120113095022.GA18130@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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, Jan 11, Andres Lagar-Cavilla wrote:

A few comments:

> -static int mem_event_disable(struct mem_event_domain *med)
> +static int mem_event_ring_available(struct mem_event_domain *med)
>  {
> -    unmap_domain_page(med->ring_page);
> -    med->ring_page = NULL;
> +    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
> +    avail_req -= med->target_producers;
> +    avail_req -= med->foreign_producers;
>  
> -    unmap_domain_page(med->shared_page);
> -    med->shared_page = NULL;
> +    BUG_ON(avail_req < 0);
> +
> +    return avail_req;
> +}
> +

mem_event_ring_available() should return unsigned since the values it
provides can only be positive. The function itself enforces this.

> -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 */
> -    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;
> +    /* We allow no ring in this unique case, because it won't affect
> +     * correctness of the guest execution at this point.  If this is the only
> +     * page that happens to be paged-out, we'll be okay..  but it's likely the
> +     * guest will crash shortly anyways. */
> +    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
> +    if ( rc < 0 )
> +        return rc;
>  
> -        mem_event_put_request(d, &d->mem_event->paging, &req);
> -    }
> +    /* Send release notification to pager */
> +    memset(&req, 0, sizeof(req));
> +    req.type = MEM_EVENT_TYPE_PAGING;
> +    req.gfn = gfn;
> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
> +
> +    mem_event_put_request(d, &d->mem_event->paging, &req);
> +    return 0;
>  }

p2m_mem_paging_drop_page() should remain void because the caller has
already done its work, making it not restartable. Also it is only called
when a gfn is in paging state, which I'm sure can not happen without a
ring.

And quilt says:
Warning: trailing whitespace in lines 167,254 of xen/arch/x86/mm/mem_event.c
Warning: trailing whitespace in line 168 of xen/common/memory.c
Warning: trailing whitespace in line 1127 of xen/arch/x86/mm/p2m.c


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 09:51:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 09:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RldmT-0000OV-U7; Fri, 13 Jan 2012 09:50:41 +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 1RldmR-0000OP-V6
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 09:50:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326448232!10864354!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTcwMzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTcwMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29954 invoked from network); 13 Jan 2012 09:50:33 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 09:50:33 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326448232; l=2386;
	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=KDgJXegMN2nV3BIYkyLtJAUKm0o=;
	b=MsN6LasH8oU25YhYnnaqkqPdPQQQU70b0AdjIZrTjd0o59Xz5Nw1kbi4IL+3dbYaM5Y
	BoiRL5ewvALn/xJxlF+AxpGD8e5sM4W3Gy7NPxv1iou9OoVik/17I6ZP2VNHmydSEKU/B
	GT4ij9SO3uBOdM2rcBKFLUEztl/rsmD6O/E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhi0PFa/V
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-098-169.pools.arcor-ip.net [88.65.98.169])
	by smtp.strato.de (jimi mo64) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id t01366o0D9H3Q6 ;
	Fri, 13 Jan 2012 10:50:23 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 022CE18637; Fri, 13 Jan 2012 10:50:22 +0100 (CET)
Date: Fri, 13 Jan 2012 10:50:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120113095022.GA18130@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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, Jan 11, Andres Lagar-Cavilla wrote:

A few comments:

> -static int mem_event_disable(struct mem_event_domain *med)
> +static int mem_event_ring_available(struct mem_event_domain *med)
>  {
> -    unmap_domain_page(med->ring_page);
> -    med->ring_page = NULL;
> +    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
> +    avail_req -= med->target_producers;
> +    avail_req -= med->foreign_producers;
>  
> -    unmap_domain_page(med->shared_page);
> -    med->shared_page = NULL;
> +    BUG_ON(avail_req < 0);
> +
> +    return avail_req;
> +}
> +

mem_event_ring_available() should return unsigned since the values it
provides can only be positive. The function itself enforces this.

> -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 */
> -    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;
> +    /* We allow no ring in this unique case, because it won't affect
> +     * correctness of the guest execution at this point.  If this is the only
> +     * page that happens to be paged-out, we'll be okay..  but it's likely the
> +     * guest will crash shortly anyways. */
> +    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
> +    if ( rc < 0 )
> +        return rc;
>  
> -        mem_event_put_request(d, &d->mem_event->paging, &req);
> -    }
> +    /* Send release notification to pager */
> +    memset(&req, 0, sizeof(req));
> +    req.type = MEM_EVENT_TYPE_PAGING;
> +    req.gfn = gfn;
> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
> +
> +    mem_event_put_request(d, &d->mem_event->paging, &req);
> +    return 0;
>  }

p2m_mem_paging_drop_page() should remain void because the caller has
already done its work, making it not restartable. Also it is only called
when a gfn is in paging state, which I'm sure can not happen without a
ring.

And quilt says:
Warning: trailing whitespace in lines 167,254 of xen/arch/x86/mm/mem_event.c
Warning: trailing whitespace in line 168 of xen/common/memory.c
Warning: trailing whitespace in line 1127 of xen/arch/x86/mm/p2m.c


Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:32:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RleQP-00011l-2f; Fri, 13 Jan 2012 10:31:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RleQN-00011f-BR
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:31:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326450664!52389891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9060 invoked from network); 13 Jan 2012 10:31:04 -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;
	13 Jan 2012 10:31:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9993962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:31:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 10:31:20 +0000
Date: Fri, 13 Jan 2012 10:31:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120112182222.GA12596@aepfle.de>
Message-ID: <alpine.DEB.2.00.1201131029270.3150@kaball-desktop>
References: <20120112182222.GA12596@aepfle.de>
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] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 12 Jan 2012, Olaf Hering wrote:
> Add support for a xenstore dm command to flush qemu's buffer cache.
> 
> qemu will just keep mapping pages and not release them, which causes problems
> for the memory pager (since the page is mapped, it won't get paged out). When
> the pager has trouble finding a page to page out, it asks qemu to flush its
> buffer, which releases all the page mappings. This makes it possible to find
> pages to swap out agian.
> 
> Signed-off-by: Patrick Colp <Patrick.Colp@citrix.com>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> ---
>  ioemu-remote/xenstore.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> --- ioemu-remote/xenstore.c
> +++ ioemu-remote/xenstore.c
> @@ -927,6 +927,9 @@ static void xenstore_process_dm_command_
>          do_pci_add(par);
>          free(par);
>  #endif
> +    } else if (!strncmp(command, "flush-cache", len)) {
> +        fprintf(logfile, "dm-command: flush caches\n");
> +        qemu_invalidate_map_cache();
>      } else {
>          fprintf(logfile, "dm-command: unknown command\"%*s\"\n", len, command);
>      }

I guess it is not possible to send the usual ioreq with type ==
IOREQ_TYPE_INVALIDATE because the pager is separate from the hypervisor,
correct?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:32:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:32:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RleQP-00011l-2f; Fri, 13 Jan 2012 10:31:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RleQN-00011f-BR
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:31:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326450664!52389891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9060 invoked from network); 13 Jan 2012 10:31:04 -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;
	13 Jan 2012 10:31:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9993962"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:31:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 10:31:20 +0000
Date: Fri, 13 Jan 2012 10:31:37 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120112182222.GA12596@aepfle.de>
Message-ID: <alpine.DEB.2.00.1201131029270.3150@kaball-desktop>
References: <20120112182222.GA12596@aepfle.de>
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] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 12 Jan 2012, Olaf Hering wrote:
> Add support for a xenstore dm command to flush qemu's buffer cache.
> 
> qemu will just keep mapping pages and not release them, which causes problems
> for the memory pager (since the page is mapped, it won't get paged out). When
> the pager has trouble finding a page to page out, it asks qemu to flush its
> buffer, which releases all the page mappings. This makes it possible to find
> pages to swap out agian.
> 
> Signed-off-by: Patrick Colp <Patrick.Colp@citrix.com>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> ---
>  ioemu-remote/xenstore.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> --- ioemu-remote/xenstore.c
> +++ ioemu-remote/xenstore.c
> @@ -927,6 +927,9 @@ static void xenstore_process_dm_command_
>          do_pci_add(par);
>          free(par);
>  #endif
> +    } else if (!strncmp(command, "flush-cache", len)) {
> +        fprintf(logfile, "dm-command: flush caches\n");
> +        qemu_invalidate_map_cache();
>      } else {
>          fprintf(logfile, "dm-command: unknown command\"%*s\"\n", len, command);
>      }

I guess it is not possible to send the usual ioreq with type ==
IOREQ_TYPE_INVALIDATE because the pager is separate from the hypervisor,
correct?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 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 1RleTJ-00019i-Li; Fri, 13 Jan 2012 10:34: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 1RleTH-00019W-Gr
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:34:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326450889!10821787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3277 invoked from network); 13 Jan 2012 10:34: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;
	13 Jan 2012 10:34:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:34:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 10:34:49 +0000
Date: Fri, 13 Jan 2012 10:35:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120112183034.GA13035@aepfle.de>
Message-ID: <alpine.DEB.2.00.1201131032250.3150@kaball-desktop>
References: <20120112182222.GA12596@aepfle.de>
	<20120112183034.GA13035@aepfle.de>
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] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 12 Jan 2012, Olaf Hering wrote:
> On Thu, Jan 12, Olaf Hering wrote:
> 
> > Add support for a xenstore dm command to flush qemu's buffer cache.
> 
> Something like this is most likely also needed in mainline qemu.
> My search in the qemu.org git web UI did not show any of the commands in
> ioemu-remote, so its not clear how to forward port this change. 
 
Yes, upstream qemu is going to need this too.
So far we haven't needed any xenstore command in upstream qemu, because
we have been using qemu's own rpc mechanism, called qmp.
There is qmp support in libxl already, so it shouldn't be difficult to
use it, instead of sending the command through xenstore.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 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 1RleTJ-00019i-Li; Fri, 13 Jan 2012 10:34: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 1RleTH-00019W-Gr
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:34:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326450889!10821787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3277 invoked from network); 13 Jan 2012 10:34: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;
	13 Jan 2012 10:34:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994076"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:34:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 10:34:49 +0000
Date: Fri, 13 Jan 2012 10:35:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120112183034.GA13035@aepfle.de>
Message-ID: <alpine.DEB.2.00.1201131032250.3150@kaball-desktop>
References: <20120112182222.GA12596@aepfle.de>
	<20120112183034.GA13035@aepfle.de>
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] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 12 Jan 2012, Olaf Hering wrote:
> On Thu, Jan 12, Olaf Hering wrote:
> 
> > Add support for a xenstore dm command to flush qemu's buffer cache.
> 
> Something like this is most likely also needed in mainline qemu.
> My search in the qemu.org git web UI did not show any of the commands in
> ioemu-remote, so its not clear how to forward port this change. 
 
Yes, upstream qemu is going to need this too.
So far we haven't needed any xenstore command in upstream qemu, because
we have been using qemu's own rpc mechanism, called qmp.
There is qmp support in libxl already, so it shouldn't be difficult to
use it, instead of sending the command through xenstore.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:36:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:36:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RleUN-0001Dv-4D; Fri, 13 Jan 2012 10:36: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 1RleUL-0001DV-Ke
	for xen-devel@lists.xen.org; Fri, 13 Jan 2012 10:36:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326450955!8950897!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32295 invoked from network); 13 Jan 2012 10:35:55 -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 Jan 2012 10:35:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:35: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;
	Fri, 13 Jan 2012 10:35:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:35:54 +0000
In-Reply-To: <20208.50697.342324.740883@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>
	<1324401307.23729.66.camel@zakaz.uk.xensource.com>
	<4EF0D3820200007800069349@nat28.tlf.novell.com>
	<20208.50697.342324.740883@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326450954.17210.308.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 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 17:29 +0000, Ian Jackson wrote:
> 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.

(trawling my backlog).

How about this for starters (the ret change is incidental and fixes an
existing warning):

8<--------------------------------------------------------------------

>From 823c4eb30f08e2f35170e4d98c9477dd6d24a387 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 13 Jan 2012 10:35:14 +0000
Subject: [PATCH] Debug vmalloc_sync_all crash

---
 arch/x86/mm/fault.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 7e7dbd1..5df9335 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -206,8 +206,18 @@ static inline pmd_t *vmalloc_sync_one(pgd_t *pgd, unsigned long address)
 
 	if (!pmd_present(*pmd))
 		set_pmd(pmd, *pmd_k);
-	else
+	else {
+		printk(KERN_CRIT "vmalloc sync one failure for %#lx\n", address);
+		printk(KERN_CRIT "  pgd %p = %#010llx\n", pgd, pgd_val(*pgd));
+		printk(KERN_CRIT "pgd_k %p = %#010llx\n", pgd_k, pgd_val(*pgd_k));
+		printk(KERN_CRIT "  pud %p = %#010llx\n", pud, pud_val(*pud));
+		printk(KERN_CRIT "pud_k %p = %#010llx\n", pud_k, pud_val(*pud_k));
+		printk(KERN_CRIT "  pmd %p = %#010llx\n", pmd, pmd_val(*pmd));
+		printk(KERN_CRIT "pmd_k %p = %#010llx\n", pmd_k, pmd_val(*pmd_k));
+		printk(KERN_CRIT "pmd page   %p\n", pmd_page(*pmd));
+		printk(KERN_CRIT "pmd_k page %p\n", pmd_page(*pmd_k));
 		BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k));
+	}
 
 	return pmd_k;
 }
@@ -229,15 +239,15 @@ void vmalloc_sync_all(void)
 		spin_lock_irqsave(&pgd_lock, flags);
 		list_for_each_entry(page, &pgd_list, lru) {
 			spinlock_t *pgt_lock;
-			int ret;
+			pmd_t *pmd;
 
 			pgt_lock = &pgd_page_get_mm(page)->page_table_lock;
 
 			spin_lock(pgt_lock);
-			ret = vmalloc_sync_one(page_address(page), address);
+			pmd = vmalloc_sync_one(page_address(page), address);
 			spin_unlock(pgt_lock);
 
-			if (!ret)
+			if (!pmd)
 				break;
 		}
 		spin_unlock_irqrestore(&pgd_lock, flags);
-- 
1.7.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 Jan 13 10:36:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:36:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RleUN-0001Dv-4D; Fri, 13 Jan 2012 10:36: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 1RleUL-0001DV-Ke
	for xen-devel@lists.xen.org; Fri, 13 Jan 2012 10:36:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326450955!8950897!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32295 invoked from network); 13 Jan 2012 10:35:55 -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 Jan 2012 10:35:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994113"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:35: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;
	Fri, 13 Jan 2012 10:35:54 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:35:54 +0000
In-Reply-To: <20208.50697.342324.740883@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>
	<1324401307.23729.66.camel@zakaz.uk.xensource.com>
	<4EF0D3820200007800069349@nat28.tlf.novell.com>
	<20208.50697.342324.740883@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326450954.17210.308.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] 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 17:29 +0000, Ian Jackson wrote:
> 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.

(trawling my backlog).

How about this for starters (the ret change is incidental and fixes an
existing warning):

8<--------------------------------------------------------------------

>From 823c4eb30f08e2f35170e4d98c9477dd6d24a387 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 13 Jan 2012 10:35:14 +0000
Subject: [PATCH] Debug vmalloc_sync_all crash

---
 arch/x86/mm/fault.c |   18 ++++++++++++++----
 1 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 7e7dbd1..5df9335 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -206,8 +206,18 @@ static inline pmd_t *vmalloc_sync_one(pgd_t *pgd, unsigned long address)
 
 	if (!pmd_present(*pmd))
 		set_pmd(pmd, *pmd_k);
-	else
+	else {
+		printk(KERN_CRIT "vmalloc sync one failure for %#lx\n", address);
+		printk(KERN_CRIT "  pgd %p = %#010llx\n", pgd, pgd_val(*pgd));
+		printk(KERN_CRIT "pgd_k %p = %#010llx\n", pgd_k, pgd_val(*pgd_k));
+		printk(KERN_CRIT "  pud %p = %#010llx\n", pud, pud_val(*pud));
+		printk(KERN_CRIT "pud_k %p = %#010llx\n", pud_k, pud_val(*pud_k));
+		printk(KERN_CRIT "  pmd %p = %#010llx\n", pmd, pmd_val(*pmd));
+		printk(KERN_CRIT "pmd_k %p = %#010llx\n", pmd_k, pmd_val(*pmd_k));
+		printk(KERN_CRIT "pmd page   %p\n", pmd_page(*pmd));
+		printk(KERN_CRIT "pmd_k page %p\n", pmd_page(*pmd_k));
 		BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k));
+	}
 
 	return pmd_k;
 }
@@ -229,15 +239,15 @@ void vmalloc_sync_all(void)
 		spin_lock_irqsave(&pgd_lock, flags);
 		list_for_each_entry(page, &pgd_list, lru) {
 			spinlock_t *pgt_lock;
-			int ret;
+			pmd_t *pmd;
 
 			pgt_lock = &pgd_page_get_mm(page)->page_table_lock;
 
 			spin_lock(pgt_lock);
-			ret = vmalloc_sync_one(page_address(page), address);
+			pmd = vmalloc_sync_one(page_address(page), address);
 			spin_unlock(pgt_lock);
 
-			if (!ret)
+			if (!pmd)
 				break;
 		}
 		spin_unlock_irqrestore(&pgd_lock, flags);
-- 
1.7.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 Jan 13 10:39:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RleXo-0001SE-On; Fri, 13 Jan 2012 10:39:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RleXn-0001Rk-LQ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:39:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326451113!50086382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21166 invoked from network); 13 Jan 2012 10:38:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 10:38:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:39: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, 13 Jan 2012 10:39:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:39:19 +0000
In-Reply-To: <1325882107-5794-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451159.17210.309.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/10] 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, 2012-01-06 at 20:34 +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>
Acked-by: Ian Campbell <ian.campbell@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);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:39:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:39:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RleXo-0001SE-On; Fri, 13 Jan 2012 10:39:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RleXn-0001Rk-LQ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:39:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326451113!50086382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21166 invoked from network); 13 Jan 2012 10:38:43 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 10:38:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994212"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:39: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, 13 Jan 2012 10:39:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:39:19 +0000
In-Reply-To: <1325882107-5794-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451159.17210.309.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/10] 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, 2012-01-06 at 20:34 +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>
Acked-by: Ian Campbell <ian.campbell@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);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:41:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10: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 1RleZT-0001Zf-9L; Fri, 13 Jan 2012 10:41:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RleZR-0001ZG-KA
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:41:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326451271!8988283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20705 invoked from network); 13 Jan 2012 10:41:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 10:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:41: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, 13 Jan 2012 10:41:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:41:10 +0000
In-Reply-To: <1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451270.17210.310.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 03/10] libxl: move a lot more includes into
 libxl_internal.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> Move a lot of
>   #include <stdfoo.h>
> from individual files into libxl_internal.h.  This helps avoid
> portability mistakes where necessary system headers are omitted from
> individual files, and is also of course a convenience when developing.
> 
> Also add
>   #include "libxl_osdeps.h" /* must come before any other headers */
> to the top of most libxl*.c files, so that anyone who adds any headers
> before libxl_internal.h will put the in the right place.

Could we put this first in libxl_internal.h and apply that constraint to
that header instead?

Either way I don't mind this patch so:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c            |   15 ---------------
>  tools/libxl/libxl_blktap2.c    |    4 +---
>  tools/libxl/libxl_bootloader.c |    7 +------
>  tools/libxl/libxl_cpuid.c      |    2 ++
>  tools/libxl/libxl_create.c     |   13 +++----------
>  tools/libxl/libxl_device.c     |   10 +---------
>  tools/libxl/libxl_dm.c         |   10 +---------
>  tools/libxl/libxl_dom.c        |   11 +----------
>  tools/libxl/libxl_exec.c       |   13 +------------
>  tools/libxl/libxl_flask.c      |    8 +-------
>  tools/libxl/libxl_internal.c   |   10 +---------
>  tools/libxl/libxl_internal.h   |   22 +++++++++++++++++++---
>  tools/libxl/libxl_json.c       |    4 +---
>  tools/libxl/libxl_linux.c      |    2 +-
>  tools/libxl/libxl_netbsd.c     |    2 +-
>  tools/libxl/libxl_noblktap2.c  |    2 ++
>  tools/libxl/libxl_nocpuid.c    |    2 ++
>  tools/libxl/libxl_paths.c      |    1 +
>  tools/libxl/libxl_pci.c        |   16 +---------------
>  tools/libxl/libxl_qmp.c        |    4 +---
>  tools/libxl/libxl_utils.c      |   13 +------------
>  tools/libxl/libxl_uuid.c       |    2 +-
>  tools/libxl/libxl_xshelp.c     |    8 +-------
>  tools/libxl/libxlu_cfg.c       |    2 ++
>  tools/libxl/libxlu_cfg_i.h     |    1 +
>  tools/libxl/libxlu_disk.c      |    1 +
>  tools/libxl/libxlu_disk_i.h    |    2 ++
>  27 files changed, 51 insertions(+), 136 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2b8f8f4..2d3e8cd 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -16,21 +16,6 @@
> 
>  #include "libxl_osdeps.h"
> 
> -#include <stdio.h>
> -#include <string.h>
> -#include <stdlib.h>
> -#include <sys/types.h>
> -#include <sys/stat.h>
> -#include <fcntl.h>
> -#include <sys/select.h>
> -#include <sys/wait.h>
> -#include <sys/time.h>
> -#include <signal.h>
> -#include <unistd.h> /* for write, unlink and close */
> -#include <stdint.h>
> -#include <inttypes.h>
> -#include <assert.h>
> -
>  #include "libxl_internal.h"
> 
>  #define PAGE_TO_MEMKB(pages) ((pages) * 4)
> diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
> index acf4110..2c40182 100644
> --- a/tools/libxl/libxl_blktap2.c
> +++ b/tools/libxl/libxl_blktap2.c
> @@ -12,13 +12,11 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
>  #include "libxl_internal.h"
> 
>  #include "tap-ctl.h"
> 
> -#include <string.h>
> -
>  int libxl__blktap_enabled(libxl__gc *gc)
>  {
>      const char *msg;
> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index ce83b8e..2da1d90 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -12,15 +12,10 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <unistd.h>
> -#include <fcntl.h>
>  #include <termios.h>
> 
> -#include <sys/stat.h>
> -#include <sys/types.h>
> -
>  #include "libxl_internal.h"
> 
>  #define XENCONSOLED_BUF_SIZE 16
> diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
> index 56a00cd..dcdb9d02 100644
> --- a/tools/libxl/libxl_cpuid.c
> +++ b/tools/libxl/libxl_cpuid.c
> @@ -10,6 +10,8 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #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 ebf2ed7..9a6a94a 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -15,20 +15,13 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <string.h>
> -#include <stdlib.h>
> -#include <unistd.h>
> -#include <fcntl.h>
> -#include <xenctrl.h>
> -#include <xc_dom.h>
> -#include <xenguest.h>
> -#include <assert.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> +#include <xc_dom.h>
> +#include <xenguest.h>
> +
>  void libxl_domain_config_dispose(libxl_domain_config *d_config)
>  {
>      int i;
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 9b1fc57..5d05e90 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -14,15 +14,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <string.h>
> -#include <stdio.h>
> -#include <sys/time.h> /* for struct timeval */
> -#include <sys/types.h>
> -#include <sys/stat.h>
> -#include <unistd.h>
> -#include <fcntl.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 97d91b4..f0bf014 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -15,15 +15,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <string.h>
> -#include <stdlib.h>
> -#include <signal.h>
> -#include <unistd.h>
> -#include <fcntl.h>
> -#include <assert.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index c898d89..b2259f8 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -13,22 +13,13 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <stdio.h>
> -#include <assert.h>
>  #include <glob.h>
> -#include <inttypes.h>
> -#include <string.h>
> -#include <sys/mman.h>
> -#include <sys/time.h> /* for struct timeval */
> -#include <sys/stat.h> /* for stat */
> -#include <unistd.h> /* for sleep(2) */
> 
>  #include <xenctrl.h>
>  #include <xc_dom.h>
>  #include <xenguest.h>
> -#include <fcntl.h>
> 
>  #include <xen/hvm/hvm_info_table.h>
> 
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index 52d40d1..b10e79f 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -15,18 +15,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <string.h>
> -#include <unistd.h>
> -#include <stdlib.h>
> -#include <unistd.h>
> -#include <assert.h>
> -#include <sys/types.h>
> -#include <sys/wait.h>
> -#include <signal.h> /* for SIGKILL */
> -#include <fcntl.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
> index 6b548dd..23f2476 100644
> --- a/tools/libxl/libxl_flask.c
> +++ b/tools/libxl/libxl_flask.c
> @@ -7,13 +7,7 @@
>   *  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_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index cfa8c61..49b0dab 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -13,15 +13,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -
> -#include <sys/types.h>
> -#include <sys/stat.h>
> -#include <fcntl.h>
> -#include <sys/mman.h>
> -#include <unistd.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1bca869..d681d73 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -17,17 +17,33 @@
>  #ifndef LIBXL_INTERNAL_H
>  #define LIBXL_INTERNAL_H
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <stdint.h>
> +#include <assert.h>
> +#include <dirent.h>
> +#include <errno.h>
> +#include <fcntl.h>
> +#include <inttypes.h>
> +#include <pthread.h>
> +#include <signal.h>
>  #include <stdarg.h>
> +#include <stddef.h>
> +#include <stdint.h>
> +#include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
> -#include <pthread.h>
> +#include <unistd.h>
> +
> +#include <sys/mman.h>
> +#include <sys/select.h>
> +#include <sys/stat.h>
>  #include <sys/time.h>
> +#include <sys/types.h>
> +#include <sys/wait.h>
> 
>  #include <xs.h>
>  #include <xenctrl.h>
> +
>  #include "xentoollog.h"
> 
>  #include <xen/io/xenbus.h>
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index c0f869e..6ff2910 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -12,10 +12,8 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <assert.h>
> -#include <string.h>
>  #include <math.h>
> 
>  #include <yajl/yajl_parse.h>
> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
> index 786c6b5..925248b 100644
> --- a/tools/libxl/libxl_linux.c
> +++ b/tools/libxl/libxl_linux.c
> @@ -13,7 +13,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include <sys/stat.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> index 1e8d622..9e0ed6d 100644
> --- a/tools/libxl/libxl_netbsd.c
> +++ b/tools/libxl/libxl_netbsd.c
> @@ -13,7 +13,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include <sys/stat.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
> index 3307551..246b0de 100644
> --- a/tools/libxl/libxl_noblktap2.c
> +++ b/tools/libxl/libxl_noblktap2.c
> @@ -12,6 +12,8 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #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 2e9490c..9e52f8d 100644
> --- a/tools/libxl/libxl_nocpuid.c
> +++ b/tools/libxl/libxl_nocpuid.c
> @@ -10,6 +10,8 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #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 e7bd1a2..a95d29f 100644
> --- a/tools/libxl/libxl_paths.c
> +++ b/tools/libxl/libxl_paths.c
> @@ -12,6 +12,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
>  #include "libxl_internal.h"
>  #include "_libxl_paths.h"
> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 8b2a1c5..c3828f6 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -14,21 +14,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <stdlib.h>
> -#include <sys/types.h>
> -#include <fcntl.h>
> -#include <sys/select.h>
> -#include <sys/mman.h>
> -#include <sys/wait.h>
> -#include <sys/stat.h>
> -#include <signal.h>
> -#include <unistd.h> /* for write, unlink and close */
> -#include <inttypes.h>
> -#include <dirent.h>
> -#include <assert.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 3dfa43a..61d9769 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -18,12 +18,10 @@
>   * Specification, see in the QEMU repository.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <unistd.h>
>  #include <sys/un.h>
>  #include <sys/queue.h>
> -#include <fcntl.h>
> 
>  #include <yajl/yajl_gen.h>
> 
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index d36c737..dbe8891 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -13,20 +13,9 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <stdlib.h>
> -#include <stdint.h>
> -#include <string.h>
> -#include <xs.h>
> -#include <xenctrl.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #include <ctype.h>
> -#include <errno.h>
> -#include <sys/stat.h>
> -#include <sys/types.h>
> -#include <unistd.h>
> -#include <assert.h>
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
> index 80ab789..7c18d71 100644
> --- a/tools/libxl/libxl_uuid.c
> +++ b/tools/libxl/libxl_uuid.c
> @@ -12,7 +12,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include <libxl_uuid.h>
> 
> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> index ea835e2..6958d21 100644
> --- a/tools/libxl/libxl_xshelp.c
> +++ b/tools/libxl/libxl_xshelp.c
> @@ -13,13 +13,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <string.h>
> -#include <stddef.h>
> -#include <stdio.h>
> -#include <stdarg.h>
> -#include <inttypes.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
> index 0d1c5d3..e3659c7 100644
> --- a/tools/libxl/libxlu_cfg.c
> +++ b/tools/libxl/libxlu_cfg.c
> @@ -16,6 +16,8 @@
>   */
> 
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #include <limits.h>
> 
>  #include "libxlu_internal.h"
> diff --git a/tools/libxl/libxlu_cfg_i.h b/tools/libxl/libxlu_cfg_i.h
> index ea6a326..54d033c 100644
> --- a/tools/libxl/libxlu_cfg_i.h
> +++ b/tools/libxl/libxlu_cfg_i.h
> @@ -18,6 +18,7 @@
>  #ifndef LIBXLU_CFG_I_H
>  #define LIBXLU_CFG_I_H
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
>  #include "libxlu_internal.h"
>  #include "libxlu_cfg_y.h"
> 
> diff --git a/tools/libxl/libxlu_disk.c b/tools/libxl/libxlu_disk.c
> index 88b79ac..6cd86e9 100644
> --- a/tools/libxl/libxlu_disk.c
> +++ b/tools/libxl/libxlu_disk.c
> @@ -1,3 +1,4 @@
> +#include "libxl_osdeps.h" /* must come before any other headers */
>  #include "libxlu_internal.h"
>  #include "libxlu_disk_l.h"
>  #include "libxlu_disk_i.h"
> diff --git a/tools/libxl/libxlu_disk_i.h b/tools/libxl/libxlu_disk_i.h
> index 4fccd4a..37246f2 100644
> --- a/tools/libxl/libxlu_disk_i.h
> +++ b/tools/libxl/libxlu_disk_i.h
> @@ -1,6 +1,8 @@
>  #ifndef LIBXLU_DISK_I_H
>  #define LIBXLU_DISK_I_H
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #include "libxlu_internal.h"
> 
> 
> --
> 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 Jan 13 10:41:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10: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 1RleZT-0001Zf-9L; Fri, 13 Jan 2012 10:41:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RleZR-0001ZG-KA
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:41:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326451271!8988283!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20705 invoked from network); 13 Jan 2012 10:41:11 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 10:41:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994266"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:41: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, 13 Jan 2012 10:41:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:41:10 +0000
In-Reply-To: <1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451270.17210.310.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 03/10] libxl: move a lot more includes into
 libxl_internal.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> Move a lot of
>   #include <stdfoo.h>
> from individual files into libxl_internal.h.  This helps avoid
> portability mistakes where necessary system headers are omitted from
> individual files, and is also of course a convenience when developing.
> 
> Also add
>   #include "libxl_osdeps.h" /* must come before any other headers */
> to the top of most libxl*.c files, so that anyone who adds any headers
> before libxl_internal.h will put the in the right place.

Could we put this first in libxl_internal.h and apply that constraint to
that header instead?

Either way I don't mind this patch so:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c            |   15 ---------------
>  tools/libxl/libxl_blktap2.c    |    4 +---
>  tools/libxl/libxl_bootloader.c |    7 +------
>  tools/libxl/libxl_cpuid.c      |    2 ++
>  tools/libxl/libxl_create.c     |   13 +++----------
>  tools/libxl/libxl_device.c     |   10 +---------
>  tools/libxl/libxl_dm.c         |   10 +---------
>  tools/libxl/libxl_dom.c        |   11 +----------
>  tools/libxl/libxl_exec.c       |   13 +------------
>  tools/libxl/libxl_flask.c      |    8 +-------
>  tools/libxl/libxl_internal.c   |   10 +---------
>  tools/libxl/libxl_internal.h   |   22 +++++++++++++++++++---
>  tools/libxl/libxl_json.c       |    4 +---
>  tools/libxl/libxl_linux.c      |    2 +-
>  tools/libxl/libxl_netbsd.c     |    2 +-
>  tools/libxl/libxl_noblktap2.c  |    2 ++
>  tools/libxl/libxl_nocpuid.c    |    2 ++
>  tools/libxl/libxl_paths.c      |    1 +
>  tools/libxl/libxl_pci.c        |   16 +---------------
>  tools/libxl/libxl_qmp.c        |    4 +---
>  tools/libxl/libxl_utils.c      |   13 +------------
>  tools/libxl/libxl_uuid.c       |    2 +-
>  tools/libxl/libxl_xshelp.c     |    8 +-------
>  tools/libxl/libxlu_cfg.c       |    2 ++
>  tools/libxl/libxlu_cfg_i.h     |    1 +
>  tools/libxl/libxlu_disk.c      |    1 +
>  tools/libxl/libxlu_disk_i.h    |    2 ++
>  27 files changed, 51 insertions(+), 136 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2b8f8f4..2d3e8cd 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -16,21 +16,6 @@
> 
>  #include "libxl_osdeps.h"
> 
> -#include <stdio.h>
> -#include <string.h>
> -#include <stdlib.h>
> -#include <sys/types.h>
> -#include <sys/stat.h>
> -#include <fcntl.h>
> -#include <sys/select.h>
> -#include <sys/wait.h>
> -#include <sys/time.h>
> -#include <signal.h>
> -#include <unistd.h> /* for write, unlink and close */
> -#include <stdint.h>
> -#include <inttypes.h>
> -#include <assert.h>
> -
>  #include "libxl_internal.h"
> 
>  #define PAGE_TO_MEMKB(pages) ((pages) * 4)
> diff --git a/tools/libxl/libxl_blktap2.c b/tools/libxl/libxl_blktap2.c
> index acf4110..2c40182 100644
> --- a/tools/libxl/libxl_blktap2.c
> +++ b/tools/libxl/libxl_blktap2.c
> @@ -12,13 +12,11 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
>  #include "libxl_internal.h"
> 
>  #include "tap-ctl.h"
> 
> -#include <string.h>
> -
>  int libxl__blktap_enabled(libxl__gc *gc)
>  {
>      const char *msg;
> diff --git a/tools/libxl/libxl_bootloader.c b/tools/libxl/libxl_bootloader.c
> index ce83b8e..2da1d90 100644
> --- a/tools/libxl/libxl_bootloader.c
> +++ b/tools/libxl/libxl_bootloader.c
> @@ -12,15 +12,10 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <unistd.h>
> -#include <fcntl.h>
>  #include <termios.h>
> 
> -#include <sys/stat.h>
> -#include <sys/types.h>
> -
>  #include "libxl_internal.h"
> 
>  #define XENCONSOLED_BUF_SIZE 16
> diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
> index 56a00cd..dcdb9d02 100644
> --- a/tools/libxl/libxl_cpuid.c
> +++ b/tools/libxl/libxl_cpuid.c
> @@ -10,6 +10,8 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #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 ebf2ed7..9a6a94a 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -15,20 +15,13 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <string.h>
> -#include <stdlib.h>
> -#include <unistd.h>
> -#include <fcntl.h>
> -#include <xenctrl.h>
> -#include <xc_dom.h>
> -#include <xenguest.h>
> -#include <assert.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> +#include <xc_dom.h>
> +#include <xenguest.h>
> +
>  void libxl_domain_config_dispose(libxl_domain_config *d_config)
>  {
>      int i;
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 9b1fc57..5d05e90 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -14,15 +14,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <string.h>
> -#include <stdio.h>
> -#include <sys/time.h> /* for struct timeval */
> -#include <sys/types.h>
> -#include <sys/stat.h>
> -#include <unistd.h>
> -#include <fcntl.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 97d91b4..f0bf014 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -15,15 +15,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <string.h>
> -#include <stdlib.h>
> -#include <signal.h>
> -#include <unistd.h>
> -#include <fcntl.h>
> -#include <assert.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index c898d89..b2259f8 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -13,22 +13,13 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <stdio.h>
> -#include <assert.h>
>  #include <glob.h>
> -#include <inttypes.h>
> -#include <string.h>
> -#include <sys/mman.h>
> -#include <sys/time.h> /* for struct timeval */
> -#include <sys/stat.h> /* for stat */
> -#include <unistd.h> /* for sleep(2) */
> 
>  #include <xenctrl.h>
>  #include <xc_dom.h>
>  #include <xenguest.h>
> -#include <fcntl.h>
> 
>  #include <xen/hvm/hvm_info_table.h>
> 
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index 52d40d1..b10e79f 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -15,18 +15,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <string.h>
> -#include <unistd.h>
> -#include <stdlib.h>
> -#include <unistd.h>
> -#include <assert.h>
> -#include <sys/types.h>
> -#include <sys/wait.h>
> -#include <signal.h> /* for SIGKILL */
> -#include <fcntl.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_flask.c b/tools/libxl/libxl_flask.c
> index 6b548dd..23f2476 100644
> --- a/tools/libxl/libxl_flask.c
> +++ b/tools/libxl/libxl_flask.c
> @@ -7,13 +7,7 @@
>   *  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_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index cfa8c61..49b0dab 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -13,15 +13,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -
> -#include <sys/types.h>
> -#include <sys/stat.h>
> -#include <fcntl.h>
> -#include <sys/mman.h>
> -#include <unistd.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 1bca869..d681d73 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -17,17 +17,33 @@
>  #ifndef LIBXL_INTERNAL_H
>  #define LIBXL_INTERNAL_H
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <stdint.h>
> +#include <assert.h>
> +#include <dirent.h>
> +#include <errno.h>
> +#include <fcntl.h>
> +#include <inttypes.h>
> +#include <pthread.h>
> +#include <signal.h>
>  #include <stdarg.h>
> +#include <stddef.h>
> +#include <stdint.h>
> +#include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
> -#include <pthread.h>
> +#include <unistd.h>
> +
> +#include <sys/mman.h>
> +#include <sys/select.h>
> +#include <sys/stat.h>
>  #include <sys/time.h>
> +#include <sys/types.h>
> +#include <sys/wait.h>
> 
>  #include <xs.h>
>  #include <xenctrl.h>
> +
>  #include "xentoollog.h"
> 
>  #include <xen/io/xenbus.h>
> diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
> index c0f869e..6ff2910 100644
> --- a/tools/libxl/libxl_json.c
> +++ b/tools/libxl/libxl_json.c
> @@ -12,10 +12,8 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <assert.h>
> -#include <string.h>
>  #include <math.h>
> 
>  #include <yajl/yajl_parse.h>
> diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
> index 786c6b5..925248b 100644
> --- a/tools/libxl/libxl_linux.c
> +++ b/tools/libxl/libxl_linux.c
> @@ -13,7 +13,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include <sys/stat.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
> index 1e8d622..9e0ed6d 100644
> --- a/tools/libxl/libxl_netbsd.c
> +++ b/tools/libxl/libxl_netbsd.c
> @@ -13,7 +13,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include <sys/stat.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_noblktap2.c b/tools/libxl/libxl_noblktap2.c
> index 3307551..246b0de 100644
> --- a/tools/libxl/libxl_noblktap2.c
> +++ b/tools/libxl/libxl_noblktap2.c
> @@ -12,6 +12,8 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #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 2e9490c..9e52f8d 100644
> --- a/tools/libxl/libxl_nocpuid.c
> +++ b/tools/libxl/libxl_nocpuid.c
> @@ -10,6 +10,8 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #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 e7bd1a2..a95d29f 100644
> --- a/tools/libxl/libxl_paths.c
> +++ b/tools/libxl/libxl_paths.c
> @@ -12,6 +12,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
>  #include "libxl_internal.h"
>  #include "_libxl_paths.h"
> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 8b2a1c5..c3828f6 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -14,21 +14,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <stdlib.h>
> -#include <sys/types.h>
> -#include <fcntl.h>
> -#include <sys/select.h>
> -#include <sys/mman.h>
> -#include <sys/wait.h>
> -#include <sys/stat.h>
> -#include <signal.h>
> -#include <unistd.h> /* for write, unlink and close */
> -#include <inttypes.h>
> -#include <dirent.h>
> -#include <assert.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 3dfa43a..61d9769 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -18,12 +18,10 @@
>   * Specification, see in the QEMU repository.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
> -#include <unistd.h>
>  #include <sys/un.h>
>  #include <sys/queue.h>
> -#include <fcntl.h>
> 
>  #include <yajl/yajl_gen.h>
> 
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index d36c737..dbe8891 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -13,20 +13,9 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <stdio.h>
> -#include <stdlib.h>
> -#include <stdint.h>
> -#include <string.h>
> -#include <xs.h>
> -#include <xenctrl.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #include <ctype.h>
> -#include <errno.h>
> -#include <sys/stat.h>
> -#include <sys/types.h>
> -#include <unistd.h>
> -#include <assert.h>
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxl_uuid.c b/tools/libxl/libxl_uuid.c
> index 80ab789..7c18d71 100644
> --- a/tools/libxl/libxl_uuid.c
> +++ b/tools/libxl/libxl_uuid.c
> @@ -12,7 +12,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include <libxl_uuid.h>
> 
> diff --git a/tools/libxl/libxl_xshelp.c b/tools/libxl/libxl_xshelp.c
> index ea835e2..6958d21 100644
> --- a/tools/libxl/libxl_xshelp.c
> +++ b/tools/libxl/libxl_xshelp.c
> @@ -13,13 +13,7 @@
>   * GNU Lesser General Public License for more details.
>   */
> 
> -#include "libxl_osdeps.h"
> -
> -#include <string.h>
> -#include <stddef.h>
> -#include <stdio.h>
> -#include <stdarg.h>
> -#include <inttypes.h>
> +#include "libxl_osdeps.h" /* must come before any other headers */
> 
>  #include "libxl_internal.h"
> 
> diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
> index 0d1c5d3..e3659c7 100644
> --- a/tools/libxl/libxlu_cfg.c
> +++ b/tools/libxl/libxlu_cfg.c
> @@ -16,6 +16,8 @@
>   */
> 
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #include <limits.h>
> 
>  #include "libxlu_internal.h"
> diff --git a/tools/libxl/libxlu_cfg_i.h b/tools/libxl/libxlu_cfg_i.h
> index ea6a326..54d033c 100644
> --- a/tools/libxl/libxlu_cfg_i.h
> +++ b/tools/libxl/libxlu_cfg_i.h
> @@ -18,6 +18,7 @@
>  #ifndef LIBXLU_CFG_I_H
>  #define LIBXLU_CFG_I_H
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
>  #include "libxlu_internal.h"
>  #include "libxlu_cfg_y.h"
> 
> diff --git a/tools/libxl/libxlu_disk.c b/tools/libxl/libxlu_disk.c
> index 88b79ac..6cd86e9 100644
> --- a/tools/libxl/libxlu_disk.c
> +++ b/tools/libxl/libxlu_disk.c
> @@ -1,3 +1,4 @@
> +#include "libxl_osdeps.h" /* must come before any other headers */
>  #include "libxlu_internal.h"
>  #include "libxlu_disk_l.h"
>  #include "libxlu_disk_i.h"
> diff --git a/tools/libxl/libxlu_disk_i.h b/tools/libxl/libxlu_disk_i.h
> index 4fccd4a..37246f2 100644
> --- a/tools/libxl/libxlu_disk_i.h
> +++ b/tools/libxl/libxlu_disk_i.h
> @@ -1,6 +1,8 @@
>  #ifndef LIBXLU_DISK_I_H
>  #define LIBXLU_DISK_I_H
> 
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
>  #include "libxlu_internal.h"
> 
> 
> --
> 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 Jan 13 10:42:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10: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 1RleaQ-0001gO-TS; Fri, 13 Jan 2012 10:42: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 1RleaP-0001fj-Eg
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:42:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326451331!10822923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27662 invoked from network); 13 Jan 2012 10:42:11 -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;
	13 Jan 2012 10:42:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:42: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;
	Fri, 13 Jan 2012 10:42:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:42:10 +0000
In-Reply-To: <1325882107-5794-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451331.17210.311.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/10] libxl: Provide more formal
 libxl__ctx_lock and _unlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> Previously the only official interface for the ctx lock was the
> CTX_LOCK and CTX_UNLOCK convenience macros, which assume and use "ctx"
> from the surrounding scope.
> 
> Instead, provide libxl__ctx_lock and _unlock functions which can be
> used by these convenience macros, and other callers who have
> nonstandard requirements.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   23 +++++++++++++----------
>  1 files changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index d681d73..1dadf15 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -115,7 +115,8 @@ struct libxl__ctx {
>      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.
> +      /* Always use libxl__ctx_lock and _unlock (or the convenience
> +       * macors 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
> @@ -749,16 +750,18 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  
>  /* 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)
> +static inline void libxl__ctx_lock(libxl_ctx *ctx) {
> +    int r = pthread_mutex_lock(&ctx->lock);
> +    assert(!r);
> +}
>  
> -#define CTX_UNLOCK do {                                 \
> -        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
> -        assert(!mutex_r);                               \
> -    } while(0)
> -        
> +static inline void libxl__ctx_unlock(libxl_ctx *ctx) {
> +    int r = pthread_mutex_unlock(&ctx->lock);
> +    assert(!r);
> +}
> +
> +#define CTX_LOCK (libxl__ctx_lock(CTX))
> +#define CTX_UNLOCK (libxl__ctx_unlock(CTX))
>  
> 
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:42:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10: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 1RleaQ-0001gO-TS; Fri, 13 Jan 2012 10:42: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 1RleaP-0001fj-Eg
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:42:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326451331!10822923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27662 invoked from network); 13 Jan 2012 10:42:11 -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;
	13 Jan 2012 10:42:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:42: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;
	Fri, 13 Jan 2012 10:42:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:42:10 +0000
In-Reply-To: <1325882107-5794-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451331.17210.311.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/10] libxl: Provide more formal
 libxl__ctx_lock and _unlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> Previously the only official interface for the ctx lock was the
> CTX_LOCK and CTX_UNLOCK convenience macros, which assume and use "ctx"
> from the surrounding scope.
> 
> Instead, provide libxl__ctx_lock and _unlock functions which can be
> used by these convenience macros, and other callers who have
> nonstandard requirements.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   23 +++++++++++++----------
>  1 files changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index d681d73..1dadf15 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -115,7 +115,8 @@ struct libxl__ctx {
>      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.
> +      /* Always use libxl__ctx_lock and _unlock (or the convenience
> +       * macors 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
> @@ -749,16 +750,18 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
>  
>  /* 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)
> +static inline void libxl__ctx_lock(libxl_ctx *ctx) {
> +    int r = pthread_mutex_lock(&ctx->lock);
> +    assert(!r);
> +}
>  
> -#define CTX_UNLOCK do {                                 \
> -        int mutex_r = pthread_mutex_unlock(&CTX->lock); \
> -        assert(!mutex_r);                               \
> -    } while(0)
> -        
> +static inline void libxl__ctx_unlock(libxl_ctx *ctx) {
> +    int r = pthread_mutex_unlock(&ctx->lock);
> +    assert(!r);
> +}
> +
> +#define CTX_LOCK (libxl__ctx_lock(CTX))
> +#define CTX_UNLOCK (libxl__ctx_unlock(CTX))
>  
> 
>  /*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:43:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:43:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlebk-0001pa-Dc; Fri, 13 Jan 2012 10:43: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 1Rlebj-0001pM-DS
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:43:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326451391!55540868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10897 invoked from network); 13 Jan 2012 10:43:11 -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;
	13 Jan 2012 10:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:43: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, 13 Jan 2012 10:43:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:43:37 +0000
In-Reply-To: <1325882107-5794-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451417.17210.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] [PATCH 05/10] libxl: Fix leaks on context init
 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 Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> Several of the error exits from libxl_ctx_alloc leaked the context
> struct itself and sometimes other resources too.
> 
> Fix this by using the standard "rc = ERROR_FOO; goto out" error
> handling style throughout.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |   20 ++++++++++++--------
>  1 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2d3e8cd..8ecce26 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -24,17 +24,17 @@
>  int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>                      unsigned flags, xentoollog_logger * lg)
>  {
> -    libxl_ctx *ctx;
> +    libxl_ctx *ctx = NULL;
>      struct stat stat_buf;
>      const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> +    int rc;
>  
> -    if (version != LIBXL_VERSION)
> -        return ERROR_VERSION;
> +    if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }

Aside: we really ought to have been cranking this number and probably
the SONAME too. 4.2 should definitely differ from 4.1 in at least one of
those, if not both. 

Ian.

>  
>      ctx = malloc(sizeof(*ctx));
>      if (!ctx) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed to allocate context\n");
> -        return ERROR_NOMEM;
> +        rc = ERROR_NOMEM; goto out;
>      }
>  
>      memset(ctx, 0, sizeof(libxl_ctx));
> @@ -48,14 +48,14 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      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);
> -        return ERROR_FAIL;
> +        rc = ERROR_FAIL; goto out;
>      }
>  
>      ctx->xch = xc_interface_open(lg,lg,0);
>      if (!ctx->xch) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
>                          "cannot open libxc handle");
> -        return ERROR_FAIL;
> +        rc = ERROR_FAIL; goto out;
>      }
>  
>      ctx->xsh = xs_daemon_open();
> @@ -64,12 +64,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      if (!ctx->xsh) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
>                          "cannot connect to xenstore");
> -        xc_interface_close(ctx->xch);
> -        return ERROR_FAIL;
> +        rc = ERROR_FAIL; goto out;
>      }
>  
>      *pctx = ctx;
>      return 0;
> +
> + out:
> +    libxl_ctx_free(ctx);
> +    *pctx = NULL;
> +    return rc;
>  }
>  
>  int libxl_ctx_free(libxl_ctx *ctx)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:43:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:43:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlebk-0001pa-Dc; Fri, 13 Jan 2012 10:43: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 1Rlebj-0001pM-DS
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:43:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326451391!55540868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10897 invoked from network); 13 Jan 2012 10:43:11 -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;
	13 Jan 2012 10:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:43: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, 13 Jan 2012 10:43:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:43:37 +0000
In-Reply-To: <1325882107-5794-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451417.17210.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] [PATCH 05/10] libxl: Fix leaks on context init
 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 Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> Several of the error exits from libxl_ctx_alloc leaked the context
> struct itself and sometimes other resources too.
> 
> Fix this by using the standard "rc = ERROR_FOO; goto out" error
> handling style throughout.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl.c |   20 ++++++++++++--------
>  1 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2d3e8cd..8ecce26 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -24,17 +24,17 @@
>  int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>                      unsigned flags, xentoollog_logger * lg)
>  {
> -    libxl_ctx *ctx;
> +    libxl_ctx *ctx = NULL;
>      struct stat stat_buf;
>      const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
> +    int rc;
>  
> -    if (version != LIBXL_VERSION)
> -        return ERROR_VERSION;
> +    if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }

Aside: we really ought to have been cranking this number and probably
the SONAME too. 4.2 should definitely differ from 4.1 in at least one of
those, if not both. 

Ian.

>  
>      ctx = malloc(sizeof(*ctx));
>      if (!ctx) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Failed to allocate context\n");
> -        return ERROR_NOMEM;
> +        rc = ERROR_NOMEM; goto out;
>      }
>  
>      memset(ctx, 0, sizeof(libxl_ctx));
> @@ -48,14 +48,14 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      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);
> -        return ERROR_FAIL;
> +        rc = ERROR_FAIL; goto out;
>      }
>  
>      ctx->xch = xc_interface_open(lg,lg,0);
>      if (!ctx->xch) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
>                          "cannot open libxc handle");
> -        return ERROR_FAIL;
> +        rc = ERROR_FAIL; goto out;
>      }
>  
>      ctx->xsh = xs_daemon_open();
> @@ -64,12 +64,16 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
>      if (!ctx->xsh) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno,
>                          "cannot connect to xenstore");
> -        xc_interface_close(ctx->xch);
> -        return ERROR_FAIL;
> +        rc = ERROR_FAIL; goto out;
>      }
>  
>      *pctx = ctx;
>      return 0;
> +
> + out:
> +    libxl_ctx_free(ctx);
> +    *pctx = NULL;
> +    return rc;
>  }
>  
>  int libxl_ctx_free(libxl_ctx *ctx)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:45:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RledD-0001zW-U5; Fri, 13 Jan 2012 10:45: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 1RledB-0001ym-Qs
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:45:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326451503!7130883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18303 invoked from network); 13 Jan 2012 10:45:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 10:45:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994404"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:45: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, 13 Jan 2012 10:45:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:45:03 +0000
In-Reply-To: <1325882107-5794-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451503.17210.313.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 09/10] libxl: introduce
 libxl_fd_set_nonblock, rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> We want a function for setting fds to nonblocking, so introduce one.
> 
> This is a very similar requirement to that for libxl_fd_set_cloexec,
> so make it common with that.
> 
> While we're at it, fix a few deficiences that make this latter
> function less desirable than it could be:
>  * Change the return from 0/-1 (like a syscall) to a libxl error code
>  * Take a boolean parameter for turning the flag on and off
>  * Log on error (and so, take a ctx for this purpose)
> 
> Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
> such errors are highly unlikely.)
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

(although I notice that you've slipped back into the
comment-follows-prototype style...)

> ---
>  tools/libxl/libxl.c      |   33 ++++++++++++++++++++++++++-------
>  tools/libxl/libxl.h      |    6 +++++-
>  tools/libxl/libxl_qmp.c  |    3 ++-
>  tools/libxl/xl_cmdimpl.c |    3 ++-
>  4 files changed, 35 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f6370d4..42b64d8 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3647,19 +3647,38 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
>      return 0;
>  }
>  
> -int libxl_fd_set_cloexec(int fd)
> +static int fd_set_flags(libxl_ctx *ctx, int fd,
> +                        int fcntlgetop, int fcntlsetop, const char *fl,
> +                        int flagmask, int set_p)
>  {
> -    int flags = 0;
> +    int flags, r;
>  
> -    if ((flags = fcntl(fd, F_GETFD)) == -1) {
> -        flags = 0;
> +    flags = fcntl(fd, fcntlgetop);
> +    if (flags == -1) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_GET%s) failed",fl);
> +        return ERROR_FAIL;
>      }
> -    if ((flags & FD_CLOEXEC)) {
> -        return 0;
> +
> +    if (set_p)
> +        flags |= flagmask;
> +    else
> +        flags &= ~flagmask;
> +
> +    r = fcntl(fd, fcntlsetop, flags);
> +    if (r == -1) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_SET%s) failed",fl);
> +        return ERROR_FAIL;
>      }
> -    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
> +
> +    return 0;
>  }
>  
> +int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
> +  { return fd_set_flags(ctx,fd, F_GETFD,F_SETFD,"FD", FD_CLOEXEC, cloexec); }
> +
> +int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
> +  { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 97ca25e..5396ba8 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -613,7 +613,11 @@ const char *libxl_run_dir_path(void);
>  const char *libxl_xenpaging_dir_path(void);
>  
>  /* misc */
> -int libxl_fd_set_cloexec(int fd);
> +int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
> +int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
> +  /* Each of these sets or clears the flag according to whether the
> +   * 2nd parameter is nonzero.  On failure, they log, and
> +   * return ERROR_FAIL, but also leave errno valid. */
>  
>  #include <libxl_event.h>
>  
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 58f5283..05df4d7 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -324,7 +324,8 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
>      if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
>          return -1;
>      }
> -    libxl_fd_set_cloexec(qmp->qmp_fd);
> +    ret = libxl_fd_set_cloexec(qmp->ctx, qmp->qmp_fd, 1);
> +    if (ret) return -1;
>  
>      memset(&qmp->addr, 0, sizeof (&qmp->addr));
>      qmp->addr.sun_family = AF_UNIX;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index a18c6b2..b88fc8a 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1490,7 +1490,8 @@ static int create_domain(struct domain_create *dom_info)
>              restore_fd = migrate_fd;
>          } else {
>              restore_fd = open(restore_file, O_RDONLY);
> -            libxl_fd_set_cloexec(restore_fd);
> +            rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
> +            if (rc) return rc;
>          }
>  
>          CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:45:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RledD-0001zW-U5; Fri, 13 Jan 2012 10:45: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 1RledB-0001ym-Qs
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:45:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326451503!7130883!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18303 invoked from network); 13 Jan 2012 10:45:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 10:45:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994404"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:45: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, 13 Jan 2012 10:45:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:45:03 +0000
In-Reply-To: <1325882107-5794-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451503.17210.313.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 09/10] libxl: introduce
 libxl_fd_set_nonblock, rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> We want a function for setting fds to nonblocking, so introduce one.
> 
> This is a very similar requirement to that for libxl_fd_set_cloexec,
> so make it common with that.
> 
> While we're at it, fix a few deficiences that make this latter
> function less desirable than it could be:
>  * Change the return from 0/-1 (like a syscall) to a libxl error code
>  * Take a boolean parameter for turning the flag on and off
>  * Log on error (and so, take a ctx for this purpose)
> 
> Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
> such errors are highly unlikely.)
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

(although I notice that you've slipped back into the
comment-follows-prototype style...)

> ---
>  tools/libxl/libxl.c      |   33 ++++++++++++++++++++++++++-------
>  tools/libxl/libxl.h      |    6 +++++-
>  tools/libxl/libxl_qmp.c  |    3 ++-
>  tools/libxl/xl_cmdimpl.c |    3 ++-
>  4 files changed, 35 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f6370d4..42b64d8 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -3647,19 +3647,38 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
>      return 0;
>  }
>  
> -int libxl_fd_set_cloexec(int fd)
> +static int fd_set_flags(libxl_ctx *ctx, int fd,
> +                        int fcntlgetop, int fcntlsetop, const char *fl,
> +                        int flagmask, int set_p)
>  {
> -    int flags = 0;
> +    int flags, r;
>  
> -    if ((flags = fcntl(fd, F_GETFD)) == -1) {
> -        flags = 0;
> +    flags = fcntl(fd, fcntlgetop);
> +    if (flags == -1) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_GET%s) failed",fl);
> +        return ERROR_FAIL;
>      }
> -    if ((flags & FD_CLOEXEC)) {
> -        return 0;
> +
> +    if (set_p)
> +        flags |= flagmask;
> +    else
> +        flags &= ~flagmask;
> +
> +    r = fcntl(fd, fcntlsetop, flags);
> +    if (r == -1) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_SET%s) failed",fl);
> +        return ERROR_FAIL;
>      }
> -    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
> +
> +    return 0;
>  }
>  
> +int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
> +  { return fd_set_flags(ctx,fd, F_GETFD,F_SETFD,"FD", FD_CLOEXEC, cloexec); }
> +
> +int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
> +  { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 97ca25e..5396ba8 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -613,7 +613,11 @@ const char *libxl_run_dir_path(void);
>  const char *libxl_xenpaging_dir_path(void);
>  
>  /* misc */
> -int libxl_fd_set_cloexec(int fd);
> +int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
> +int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
> +  /* Each of these sets or clears the flag according to whether the
> +   * 2nd parameter is nonzero.  On failure, they log, and
> +   * return ERROR_FAIL, but also leave errno valid. */
>  
>  #include <libxl_event.h>
>  
> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
> index 58f5283..05df4d7 100644
> --- a/tools/libxl/libxl_qmp.c
> +++ b/tools/libxl/libxl_qmp.c
> @@ -324,7 +324,8 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
>      if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
>          return -1;
>      }
> -    libxl_fd_set_cloexec(qmp->qmp_fd);
> +    ret = libxl_fd_set_cloexec(qmp->ctx, qmp->qmp_fd, 1);
> +    if (ret) return -1;
>  
>      memset(&qmp->addr, 0, sizeof (&qmp->addr));
>      qmp->addr.sun_family = AF_UNIX;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index a18c6b2..b88fc8a 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1490,7 +1490,8 @@ static int create_domain(struct domain_create *dom_info)
>              restore_fd = migrate_fd;
>          } else {
>              restore_fd = open(restore_file, O_RDONLY);
> -            libxl_fd_set_cloexec(restore_fd);
> +            rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
> +            if (rc) return rc;
>          }
>  
>          CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:49:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10: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 1RlehE-0002Gi-Mp; Fri, 13 Jan 2012 10:49:20 +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 1RlehD-0002GU-GI
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:49:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326451753!10738329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19317 invoked from network); 13 Jan 2012 10:49:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 10:49:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994541"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:49: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, 13 Jan 2012 10:49:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:49:13 +0000
In-Reply-To: <1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451753.17210.317.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/10] libxl: New convenience macro
 CONTAINING_STRUCT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 17:34 +0000, Ian Jackson wrote:
> Provide a convenient and type-safe wrapper which does the correct
> dance to subtract offsetof.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_internal.h |   35 +++++++++++++++++++++++++++++++++++
>  1 files changed, 35 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index e0ff15c..e0c2ad6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1224,6 +1224,41 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
>   * Convenience macros.
>   */
>  
> +/*
> + * [GET_]CONTAINING_STRUCT work like this.  Given:
> + *    typedef struct {
> + *      ...
> + *      member_type member_name;
> + *      ...
> + *    } outer_type;
> + * Then:
> + *    void GET_CONTAINING_STRUCT(outer_type *outer_var [NB:UPDATED],
> + *                               some_type *inner_ptr,
> + *                               member_name);
> + *    outer_type *CONTAINING_STRUCT(outer_type,
> + *                                  some_type *inner_ptr,
> + *                                  member_name);
> + * The semantics are that after:
> + *    outer_type outer, *outer_var;
> + *    member_type *inner_ptr = &outer->member_name;
> + *    GET_CONTAINING_STRUCT(outer_var, &outer_ptr->member_name, member_name)
> + * The following hold:
> + *    CONTAINING_STRUCT(inner_ptr, outer_type, member_name) == outer_ptr

There is no outer_ptr in the givens, did you mean outer_var or something
else?

It's not entirely clear to me what the distinction between the GET_ and
non GET_ variant is (just that one returns the thing and the other
updates a variable?) and/or why we would need both. The common operation
is to go from inner_ptr to outer_ptr I think and CONTAINING_STRUCT seems
to fill that niche just fine.

BTW, in Linux this is called container_of, which is maybe more familiar
to people?

> + *    outer_var == &outer
> + */
> +#define GET_CONTAINING_STRUCT(outer_var, inner_ptr, member_name)        \
> +    ((outer_var) = (void*)((char*)(inner_ptr) -                         \
> +                           offsetof(typeof(*(outer_var)), member_name)), \
> +     (void)(&(outer_var)->member_name ==                                \
> +           (typeof(inner_ptr))0) /* type check */,                      \
> +     (void)0)
> +#define CONTAINING_STRUCT(outer_type, inner_ptr, member_name)           \
> +    ({                                                                  \
> +        typeof(outer_type) *containing_struct;                          \
> +        GET_CONTAINING_STRUCT(containing_struct, inner_ptr, member_name); \
> +        containing_struct;                                              \
> +    })
> +
>  
>  /*
>   * All of these assume (or define)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 10:49:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 10: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 1RlehE-0002Gi-Mp; Fri, 13 Jan 2012 10:49:20 +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 1RlehD-0002GU-GI
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 10:49:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326451753!10738329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19317 invoked from network); 13 Jan 2012 10:49:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 10:49:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994541"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 10:49: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, 13 Jan 2012 10:49:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 10:49:13 +0000
In-Reply-To: <1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326451753.17210.317.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/10] libxl: New convenience macro
 CONTAINING_STRUCT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-09 at 17:34 +0000, Ian Jackson wrote:
> Provide a convenient and type-safe wrapper which does the correct
> dance to subtract offsetof.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_internal.h |   35 +++++++++++++++++++++++++++++++++++
>  1 files changed, 35 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index e0ff15c..e0c2ad6 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1224,6 +1224,41 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
>   * Convenience macros.
>   */
>  
> +/*
> + * [GET_]CONTAINING_STRUCT work like this.  Given:
> + *    typedef struct {
> + *      ...
> + *      member_type member_name;
> + *      ...
> + *    } outer_type;
> + * Then:
> + *    void GET_CONTAINING_STRUCT(outer_type *outer_var [NB:UPDATED],
> + *                               some_type *inner_ptr,
> + *                               member_name);
> + *    outer_type *CONTAINING_STRUCT(outer_type,
> + *                                  some_type *inner_ptr,
> + *                                  member_name);
> + * The semantics are that after:
> + *    outer_type outer, *outer_var;
> + *    member_type *inner_ptr = &outer->member_name;
> + *    GET_CONTAINING_STRUCT(outer_var, &outer_ptr->member_name, member_name)
> + * The following hold:
> + *    CONTAINING_STRUCT(inner_ptr, outer_type, member_name) == outer_ptr

There is no outer_ptr in the givens, did you mean outer_var or something
else?

It's not entirely clear to me what the distinction between the GET_ and
non GET_ variant is (just that one returns the thing and the other
updates a variable?) and/or why we would need both. The common operation
is to go from inner_ptr to outer_ptr I think and CONTAINING_STRUCT seems
to fill that niche just fine.

BTW, in Linux this is called container_of, which is maybe more familiar
to people?

> + *    outer_var == &outer
> + */
> +#define GET_CONTAINING_STRUCT(outer_var, inner_ptr, member_name)        \
> +    ((outer_var) = (void*)((char*)(inner_ptr) -                         \
> +                           offsetof(typeof(*(outer_var)), member_name)), \
> +     (void)(&(outer_var)->member_name ==                                \
> +           (typeof(inner_ptr))0) /* type check */,                      \
> +     (void)0)
> +#define CONTAINING_STRUCT(outer_type, inner_ptr, member_name)           \
> +    ({                                                                  \
> +        typeof(outer_type) *containing_struct;                          \
> +        GET_CONTAINING_STRUCT(containing_struct, inner_ptr, member_name); \
> +        containing_struct;                                              \
> +    })
> +
>  
>  /*
>   * All of these assume (or define)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 11:06:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 11:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlexd-0002XH-BN; Fri, 13 Jan 2012 11:06:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rlexc-0002X9-16
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 11:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326452769!8779922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17824 invoked from network); 13 Jan 2012 11:06:09 -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 Jan 2012 11:06:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9995241"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:06: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, 13 Jan 2012 11:06:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 13 Jan 2012 11:06:08 +0000
In-Reply-To: <20120112141745.GA7685@phenom.dumpdata.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326452769.17210.331.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>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Tina.Yang" <tina.yang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 14:17 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
> > add polling interface to xen-netfront device to support netconsole
> > 
> 
> Ian, any thoughts on the spinlock changes?

What are they for?

At a guess they are a necessary consequence of the new calling context.
However not all the drivers I looked at which supported netpool were
using the irqsave variants in this context so I guess it must be some
secondary effect.

Anyway, the upshot is that I think the changelog needs to explain the
rationale for the locking change.

Ian.

> 
> > Signed-off-by: Tina.Yang <tina.yang@oracle.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> > Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
> > Tested-by: gurudas.pai <gurudas.pai@oracle.com>
> > ---
> >  drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
> >  1 files changed, 34 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index fa67905..db638b4 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >  	int frags = skb_shinfo(skb)->nr_frags;
> >  	unsigned int offset = offset_in_page(data);
> >  	unsigned int len = skb_headlen(skb);
> > +	unsigned long flags;
> >  
> >  	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
> >  	if (unlikely(frags > MAX_SKB_FRAGS + 1)) {
> > @@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >  		goto drop;
> >  	}
> >  
> > -	spin_lock_irq(&np->tx_lock);
> > +	spin_lock_irqsave(&np->tx_lock, flags);
> >  
> >  	if (unlikely(!netif_carrier_ok(dev) ||
> >  		     (frags > 1 && !xennet_can_sg(dev)) ||
> >  		     netif_needs_gso(skb, netif_skb_features(skb)))) {
> > -		spin_unlock_irq(&np->tx_lock);
> > +		spin_unlock_irqrestore(&np->tx_lock, flags);
> >  		goto drop;
> >  	}
> >  
> > @@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >  	if (!netfront_tx_slot_available(np))
> >  		netif_stop_queue(dev);
> >  
> > -	spin_unlock_irq(&np->tx_lock);
> > +	spin_unlock_irqrestore(&np->tx_lock, flags);
> >  
> >  	return NETDEV_TX_OK;
> >  
> > @@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
> >  	return 0;
> >  }
> >  
> > +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> > +{
> > +	struct net_device *dev = dev_id;
> > +	struct netfront_info *np = netdev_priv(dev);
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&np->tx_lock, flags);
> > +
> > +	if (likely(netif_carrier_ok(dev))) {
> > +		xennet_tx_buf_gc(dev);
> > +		/* Under tx_lock: protects access to rx shared-ring indexes. */
> > +		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> > +			napi_schedule(&np->napi);
> > +	}
> > +
> > +	spin_unlock_irqrestore(&np->tx_lock, flags);
> > +
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > +static void xennet_poll_controller(struct net_device *dev)
> > +{
> > +	xennet_interrupt(0, dev);
> > +}
> > +#endif
> > +
> >  static const struct net_device_ops xennet_netdev_ops = {
> >  	.ndo_open            = xennet_open,
> >  	.ndo_uninit          = xennet_uninit,
> > @@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
> >  	.ndo_validate_addr   = eth_validate_addr,
> >  	.ndo_fix_features    = xennet_fix_features,
> >  	.ndo_set_features    = xennet_set_features,
> > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > +	.ndo_poll_controller = xennet_poll_controller,
> > +#endif
> >  };
> >  
> >  static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
> > @@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
> >  	return 0;
> >  }
> >  
> > -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> > -{
> > -	struct net_device *dev = dev_id;
> > -	struct netfront_info *np = netdev_priv(dev);
> > -	unsigned long flags;
> > -
> > -	spin_lock_irqsave(&np->tx_lock, flags);
> > -
> > -	if (likely(netif_carrier_ok(dev))) {
> > -		xennet_tx_buf_gc(dev);
> > -		/* Under tx_lock: protects access to rx shared-ring indexes. */
> > -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> > -			napi_schedule(&np->napi);
> > -	}
> > -
> > -	spin_unlock_irqrestore(&np->tx_lock, flags);
> > -
> > -	return IRQ_HANDLED;
> > -}
> > -
> >  static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >  {
> >  	struct xen_netif_tx_sring *txs;
> > -- 
> > 1.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 Jan 13 11:06:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 11:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlexd-0002XH-BN; Fri, 13 Jan 2012 11:06:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rlexc-0002X9-16
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 11:06:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326452769!8779922!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17824 invoked from network); 13 Jan 2012 11:06:09 -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 Jan 2012 11:06:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9995241"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:06: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, 13 Jan 2012 11:06:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 13 Jan 2012 11:06:08 +0000
In-Reply-To: <20120112141745.GA7685@phenom.dumpdata.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326452769.17210.331.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>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Tina.Yang" <tina.yang@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 14:17 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
> > add polling interface to xen-netfront device to support netconsole
> > 
> 
> Ian, any thoughts on the spinlock changes?

What are they for?

At a guess they are a necessary consequence of the new calling context.
However not all the drivers I looked at which supported netpool were
using the irqsave variants in this context so I guess it must be some
secondary effect.

Anyway, the upshot is that I think the changelog needs to explain the
rationale for the locking change.

Ian.

> 
> > Signed-off-by: Tina.Yang <tina.yang@oracle.com>
> > Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> > Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
> > Tested-by: gurudas.pai <gurudas.pai@oracle.com>
> > ---
> >  drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
> >  1 files changed, 34 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index fa67905..db638b4 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >  	int frags = skb_shinfo(skb)->nr_frags;
> >  	unsigned int offset = offset_in_page(data);
> >  	unsigned int len = skb_headlen(skb);
> > +	unsigned long flags;
> >  
> >  	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
> >  	if (unlikely(frags > MAX_SKB_FRAGS + 1)) {
> > @@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >  		goto drop;
> >  	}
> >  
> > -	spin_lock_irq(&np->tx_lock);
> > +	spin_lock_irqsave(&np->tx_lock, flags);
> >  
> >  	if (unlikely(!netif_carrier_ok(dev) ||
> >  		     (frags > 1 && !xennet_can_sg(dev)) ||
> >  		     netif_needs_gso(skb, netif_skb_features(skb)))) {
> > -		spin_unlock_irq(&np->tx_lock);
> > +		spin_unlock_irqrestore(&np->tx_lock, flags);
> >  		goto drop;
> >  	}
> >  
> > @@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >  	if (!netfront_tx_slot_available(np))
> >  		netif_stop_queue(dev);
> >  
> > -	spin_unlock_irq(&np->tx_lock);
> > +	spin_unlock_irqrestore(&np->tx_lock, flags);
> >  
> >  	return NETDEV_TX_OK;
> >  
> > @@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
> >  	return 0;
> >  }
> >  
> > +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> > +{
> > +	struct net_device *dev = dev_id;
> > +	struct netfront_info *np = netdev_priv(dev);
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&np->tx_lock, flags);
> > +
> > +	if (likely(netif_carrier_ok(dev))) {
> > +		xennet_tx_buf_gc(dev);
> > +		/* Under tx_lock: protects access to rx shared-ring indexes. */
> > +		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> > +			napi_schedule(&np->napi);
> > +	}
> > +
> > +	spin_unlock_irqrestore(&np->tx_lock, flags);
> > +
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > +static void xennet_poll_controller(struct net_device *dev)
> > +{
> > +	xennet_interrupt(0, dev);
> > +}
> > +#endif
> > +
> >  static const struct net_device_ops xennet_netdev_ops = {
> >  	.ndo_open            = xennet_open,
> >  	.ndo_uninit          = xennet_uninit,
> > @@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
> >  	.ndo_validate_addr   = eth_validate_addr,
> >  	.ndo_fix_features    = xennet_fix_features,
> >  	.ndo_set_features    = xennet_set_features,
> > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > +	.ndo_poll_controller = xennet_poll_controller,
> > +#endif
> >  };
> >  
> >  static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
> > @@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
> >  	return 0;
> >  }
> >  
> > -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> > -{
> > -	struct net_device *dev = dev_id;
> > -	struct netfront_info *np = netdev_priv(dev);
> > -	unsigned long flags;
> > -
> > -	spin_lock_irqsave(&np->tx_lock, flags);
> > -
> > -	if (likely(netif_carrier_ok(dev))) {
> > -		xennet_tx_buf_gc(dev);
> > -		/* Under tx_lock: protects access to rx shared-ring indexes. */
> > -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> > -			napi_schedule(&np->napi);
> > -	}
> > -
> > -	spin_unlock_irqrestore(&np->tx_lock, flags);
> > -
> > -	return IRQ_HANDLED;
> > -}
> > -
> >  static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >  {
> >  	struct xen_netif_tx_sring *txs;
> > -- 
> > 1.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 Jan 13 11:13:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 11:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlf3J-0002fw-4p; Fri, 13 Jan 2012 11:12: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 1Rlf3H-0002fl-5M
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 11:12:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326452442!10687126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1909 invoked from network); 13 Jan 2012 11:00:43 -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 Jan 2012 11:00:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:00: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;
	Fri, 13 Jan 2012 11:00:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 13 Jan 2012 11:00:41 +0000
In-Reply-To: <20120112141235.GB8324@aepfle.de>
References: <20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de> <1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
	<20120111161023.GD81891@ocelot.phlegethon.org>
	<20120111163803.GA30142@aepfle.de>
	<20120111165855.GE81891@ocelot.phlegethon.org>
	<20120112141235.GB8324@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326452441.17210.327.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>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 14:12 +0000, Olaf Hering wrote:
> On Wed, Jan 11, Tim Deegan wrote:
> 
> > At 17:38 +0100 on 11 Jan (1326303483), Olaf Hering wrote:
> > > On Wed, Jan 11, Tim Deegan wrote:
> > > 
> > > > > Isnt that up to the host admin to decide where to take the memory from?
> > > > > So if its acceptable to swap parts of a VM (independent from what the
> > > > > guest OS thinks it has), so be it.
> > > > 
> > > > Why?  The _only_ reason I can imagine for wanting to use paging is when
> > > > the balloon driver can't or won't do its job.  There's no advantage to
> > > > paging except that you can always force it to happen.
> > > 
> > > Isnt that the whole point of paging, to make it happen at will without
> > > the guest (or the application at process level) noticing it?
> > 
> > Yes, but that's a _bad_ thing. :)  If the guest can co-operate, you'll
> > get way better eviction choices, better performance, and better
> > accounting (since the I/O is done by the guest to guest-owned disk).
> 
> Hmm, I think its slightly like an 'rm -rf *' accident: bad, but allowed.

You analogy is bogus, the "support" for "rm -rf *" comes legitimately
(even if unfortunately) from the combined semantics of the shell and rm
and just falls out from the normal use cases.

In the case of paging we would have to add explicit support for doing
something which we think has no purpose. I think it is OK for libxl to
offer the flexibility to toolstack authors to do this however they want
but xl should only expose a single "target" value.

> > That's why I think both mechanisms should be visible up to the libxl
> > layer, but xl itself should just implement the one sensible policy:
> > try ballooning first, then page if that fails.  
> 
> So you are saying xl should take care of an improved mem-set command?
> Perhaps by tweaking memory/target first, monitoring something like
> tot_pages, and if memory/target isnt reached after some time, tweak
> memory/target-tot_pages so that xenpaging takes care of the rest?

Yes, although there is no need for monitoring, it can just be set
memory/target, wait, set memory/target-tot_pages. If the balloon driver
has caught up then setting target-tot_pages will be a nop but it still
correctly reflects the desired state of the system and so we should set
it.

Another alternative would be for the pager to add some hysteresis after
it observes a change in the target before it starts "implementing" it.
This would allow the toolstack to just set things one shot. I'm not sure
that this is better though -- it makes things a little less flexible for
the toolstack and encodes policy in the pager. 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 11:13:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 11:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlf3J-0002fw-4p; Fri, 13 Jan 2012 11:12: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 1Rlf3H-0002fl-5M
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 11:12:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326452442!10687126!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1909 invoked from network); 13 Jan 2012 11:00:43 -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 Jan 2012 11:00:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; 
   d="scan'208";a="9994932"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:00: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;
	Fri, 13 Jan 2012 11:00:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Fri, 13 Jan 2012 11:00:41 +0000
In-Reply-To: <20120112141235.GB8324@aepfle.de>
References: <20111120182951.GA4830@aepfle.de>
	<alpine.DEB.2.00.1111211053060.31179@kaball-desktop>
	<20111121151359.GA22981@aepfle.de>
	<CAFLBxZZtR4DPLwUFautc944bnhYuDJ-+wFikXxKvRsQ3khXDXA@mail.gmail.com>
	<20120109192119.GB10630@aepfle.de> <1326196936.5154.39.camel@elijah>
	<20120111145821.GA28944@aepfle.de>
	<20120111161023.GD81891@ocelot.phlegethon.org>
	<20120111163803.GA30142@aepfle.de>
	<20120111165855.GE81891@ocelot.phlegethon.org>
	<20120112141235.GB8324@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326452441.17210.327.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>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 4] xenpaging: initial libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 14:12 +0000, Olaf Hering wrote:
> On Wed, Jan 11, Tim Deegan wrote:
> 
> > At 17:38 +0100 on 11 Jan (1326303483), Olaf Hering wrote:
> > > On Wed, Jan 11, Tim Deegan wrote:
> > > 
> > > > > Isnt that up to the host admin to decide where to take the memory from?
> > > > > So if its acceptable to swap parts of a VM (independent from what the
> > > > > guest OS thinks it has), so be it.
> > > > 
> > > > Why?  The _only_ reason I can imagine for wanting to use paging is when
> > > > the balloon driver can't or won't do its job.  There's no advantage to
> > > > paging except that you can always force it to happen.
> > > 
> > > Isnt that the whole point of paging, to make it happen at will without
> > > the guest (or the application at process level) noticing it?
> > 
> > Yes, but that's a _bad_ thing. :)  If the guest can co-operate, you'll
> > get way better eviction choices, better performance, and better
> > accounting (since the I/O is done by the guest to guest-owned disk).
> 
> Hmm, I think its slightly like an 'rm -rf *' accident: bad, but allowed.

You analogy is bogus, the "support" for "rm -rf *" comes legitimately
(even if unfortunately) from the combined semantics of the shell and rm
and just falls out from the normal use cases.

In the case of paging we would have to add explicit support for doing
something which we think has no purpose. I think it is OK for libxl to
offer the flexibility to toolstack authors to do this however they want
but xl should only expose a single "target" value.

> > That's why I think both mechanisms should be visible up to the libxl
> > layer, but xl itself should just implement the one sensible policy:
> > try ballooning first, then page if that fails.  
> 
> So you are saying xl should take care of an improved mem-set command?
> Perhaps by tweaking memory/target first, monitoring something like
> tot_pages, and if memory/target isnt reached after some time, tweak
> memory/target-tot_pages so that xenpaging takes care of the rest?

Yes, although there is no need for monitoring, it can just be set
memory/target, wait, set memory/target-tot_pages. If the balloon driver
has caught up then setting target-tot_pages will be a nop but it still
correctly reflects the desired state of the system and so we should set
it.

Another alternative would be for the pager to add some hysteresis after
it observes a change in the target before it starts "implementing" it.
This would allow the toolstack to just set things one shot. I'm not sure
that this is better though -- it makes things a little less flexible for
the toolstack and encodes policy in the pager. 

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 11:57:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 11:57:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlfl6-000302-2j; Fri, 13 Jan 2012 11:57:24 +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 1Rlfl4-0002zx-BO
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 11:57:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326455835!8695980!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 20471 invoked from network); 13 Jan 2012 11:57:15 -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;
	13 Jan 2012 11:57:15 -0000
Received: by wibhj8 with SMTP id hj8so899657wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 03:57: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=M3iXNSQoDpcOHX+TtxWFlJpMYMT6GhBK2hZURJLKQFk=;
	b=OiOcJnf7w1W4P1AMCTc0OVXRGM/EPC1U+SYbjRj0/zWpH7da5yV0DzMIQkm0HtdxYk
	qnbZaTc/YTuP6VBi7xBIwjcT8Ahd5rkJS6WNRiXTgybkBT37A0YmWhONMT6TTTfB0xcE
	MBwvfQjP52YbwIlDTs61qavVBr9j+9kY2mBOg=
Received: by 10.180.93.132 with SMTP id cu4mr8197659wib.9.1326455835073;
	Fri, 13 Jan 2012 03:57:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id f19sm10771544wbo.13.2012.01.13.03.57.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 13 Jan 2012 03:57:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 887a3229fd7a50c04981e29709bc7210dafef38f
Message-Id: <887a3229fd7a50c04981.1326455824@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 13 Jan 2012 12:57:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] libxl: don't set backend state to 5 when trying
 to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326454785 -3600
# Node ID 887a3229fd7a50c04981e29709bc7210dafef38f
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
libxl: don't set backend state to 5 when trying to unplug a device

libxl__device_remove was setting backend state to 5, which could
create a race condition, since the previous check for state != 4 and
setting state to 5 was not done inside of the same transaction, so the
kernel could change the state to 6 in the space between the check for
state != 4 and setting state to 5.

I might be wrong, but since I don't think setting backend state to 5
helps in any way when disconnecting a device I've just removed the
xs_write.  If this is necessary, the state != 4 check and setting it
to 5 should happen inside the same transaction, to avoid the kernel
from changing the state behind our back.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5b2676ac1321 -r 887a3229fd7a tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_device.c	Fri Jan 13 12:39:45 2012 +0100
@@ -456,7 +456,6 @@ int libxl__device_remove(libxl__gc *gc, 
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
-    xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
             goto retry_transaction;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 11:57:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 11:57:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlfl6-000302-2j; Fri, 13 Jan 2012 11:57:24 +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 1Rlfl4-0002zx-BO
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 11:57:22 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326455835!8695980!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 20471 invoked from network); 13 Jan 2012 11:57:15 -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;
	13 Jan 2012 11:57:15 -0000
Received: by wibhj8 with SMTP id hj8so899657wib.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 03:57: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=M3iXNSQoDpcOHX+TtxWFlJpMYMT6GhBK2hZURJLKQFk=;
	b=OiOcJnf7w1W4P1AMCTc0OVXRGM/EPC1U+SYbjRj0/zWpH7da5yV0DzMIQkm0HtdxYk
	qnbZaTc/YTuP6VBi7xBIwjcT8Ahd5rkJS6WNRiXTgybkBT37A0YmWhONMT6TTTfB0xcE
	MBwvfQjP52YbwIlDTs61qavVBr9j+9kY2mBOg=
Received: by 10.180.93.132 with SMTP id cu4mr8197659wib.9.1326455835073;
	Fri, 13 Jan 2012 03:57:15 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id f19sm10771544wbo.13.2012.01.13.03.57.12
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 13 Jan 2012 03:57:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 887a3229fd7a50c04981e29709bc7210dafef38f
Message-Id: <887a3229fd7a50c04981.1326455824@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 13 Jan 2012 12:57:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] libxl: don't set backend state to 5 when trying
 to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326454785 -3600
# Node ID 887a3229fd7a50c04981e29709bc7210dafef38f
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
libxl: don't set backend state to 5 when trying to unplug a device

libxl__device_remove was setting backend state to 5, which could
create a race condition, since the previous check for state != 4 and
setting state to 5 was not done inside of the same transaction, so the
kernel could change the state to 6 in the space between the check for
state != 4 and setting state to 5.

I might be wrong, but since I don't think setting backend state to 5
helps in any way when disconnecting a device I've just removed the
xs_write.  If this is necessary, the state != 4 check and setting it
to 5 should happen inside the same transaction, to avoid the kernel
from changing the state behind our back.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5b2676ac1321 -r 887a3229fd7a tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_device.c	Fri Jan 13 12:39:45 2012 +0100
@@ -456,7 +456,6 @@ int libxl__device_remove(libxl__gc *gc, 
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
-    xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {
         if (errno == EAGAIN)
             goto retry_transaction;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 11:58:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 11:58:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlfli-00031X-Ow; Fri, 13 Jan 2012 11:58:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rlflg-000319-RT
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 11:58:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326455874!10880362!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 17255 invoked from network); 13 Jan 2012 11:57:54 -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;
	13 Jan 2012 11:57:54 -0000
Received: by wgbdt11 with SMTP id dt11so2905532wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 03:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=kzGeEoyU0L1X2efmRaAVXJoLjHvKGEgBuI+0Jk+u/kI=;
	b=m02oaq8RPdljg3kd6sYk+bmVHr37hi2pceIBmOXRrvUCv1heiYxX8+DlpwCuqY+ZWx
	pkIoCabBLtw85ZVUR3YDaPtyTEm8k5kEc97HrewNK0Pq7+P7NE6FelcO6y4xuL74k6Hu
	wcEyVNUph1XyXZO8pEuCHbG0TUpFcrgpAMpT8=
Received: by 10.180.107.195 with SMTP id he3mr1129358wib.13.1326455873714;
	Fri, 13 Jan 2012 03:57:53 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id a6sm3753367wiy.6.2012.01.13.03.57.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 13 Jan 2012 03:57:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 58c924a72ab7af658a888ff39411229a9e6a12f6
Message-Id: <58c924a72ab7af658a88.1326455852@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 13 Jan 2012 12:57:32 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] libxl: fix parse_backend_path and
 device_backend_path to be mutual
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326454799 -3600
# Node ID 58c924a72ab7af658a888ff39411229a9e6a12f6
# Parent  887a3229fd7a50c04981e29709bc7210dafef38f
libxl: fix parse_backend_path and device_backend_path to be mutual

Currently if libxl__parse_backend_path is used and then you try to get
the original path again with libxl__device_backend_path the
result is wrong. This patch fixes the issue, so transformation from
path to libxl__device and back is reciprocal.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 887a3229fd7a -r 58c924a72ab7 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Jan 13 12:39:45 2012 +0100
+++ b/tools/libxl/libxl_device.c	Fri Jan 13 12:39:59 2012 +0100
@@ -54,12 +54,11 @@ int libxl__parse_backend_path(libxl__gc 
 {
     /* /local/domain/<domid>/backend/<kind>/<domid>/<devid> */
     char strkind[16]; /* Longest is actually "console" */
-    uint32_t domain;
-    int rc = sscanf(path, "/local/domain/%d/backend/%15[^/]/%d/%d",
+    int rc = sscanf(path, "/local/domain/%d/backend/%15[^/]/%u/%d",
                     &dev->backend_domid,
                     strkind,
-                    &domain,
-                    &dev->backend_devid);
+                    &dev->domid,
+                    &dev->devid);
 
     if (rc != 4)
         return ERROR_FAIL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 11:58:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 11:58:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlfli-00031X-Ow; Fri, 13 Jan 2012 11:58:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rlflg-000319-RT
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 11:58:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326455874!10880362!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 17255 invoked from network); 13 Jan 2012 11:57:54 -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;
	13 Jan 2012 11:57:54 -0000
Received: by wgbdt11 with SMTP id dt11so2905532wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 03:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=kzGeEoyU0L1X2efmRaAVXJoLjHvKGEgBuI+0Jk+u/kI=;
	b=m02oaq8RPdljg3kd6sYk+bmVHr37hi2pceIBmOXRrvUCv1heiYxX8+DlpwCuqY+ZWx
	pkIoCabBLtw85ZVUR3YDaPtyTEm8k5kEc97HrewNK0Pq7+P7NE6FelcO6y4xuL74k6Hu
	wcEyVNUph1XyXZO8pEuCHbG0TUpFcrgpAMpT8=
Received: by 10.180.107.195 with SMTP id he3mr1129358wib.13.1326455873714;
	Fri, 13 Jan 2012 03:57:53 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id a6sm3753367wiy.6.2012.01.13.03.57.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 13 Jan 2012 03:57:52 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 58c924a72ab7af658a888ff39411229a9e6a12f6
Message-Id: <58c924a72ab7af658a88.1326455852@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 13 Jan 2012 12:57:32 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] libxl: fix parse_backend_path and
 device_backend_path to be mutual
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326454799 -3600
# Node ID 58c924a72ab7af658a888ff39411229a9e6a12f6
# Parent  887a3229fd7a50c04981e29709bc7210dafef38f
libxl: fix parse_backend_path and device_backend_path to be mutual

Currently if libxl__parse_backend_path is used and then you try to get
the original path again with libxl__device_backend_path the
result is wrong. This patch fixes the issue, so transformation from
path to libxl__device and back is reciprocal.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 887a3229fd7a -r 58c924a72ab7 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Fri Jan 13 12:39:45 2012 +0100
+++ b/tools/libxl/libxl_device.c	Fri Jan 13 12:39:59 2012 +0100
@@ -54,12 +54,11 @@ int libxl__parse_backend_path(libxl__gc 
 {
     /* /local/domain/<domid>/backend/<kind>/<domid>/<devid> */
     char strkind[16]; /* Longest is actually "console" */
-    uint32_t domain;
-    int rc = sscanf(path, "/local/domain/%d/backend/%15[^/]/%d/%d",
+    int rc = sscanf(path, "/local/domain/%d/backend/%15[^/]/%u/%d",
                     &dev->backend_domid,
                     strkind,
-                    &domain,
-                    &dev->backend_devid);
+                    &dev->domid,
+                    &dev->devid);
 
     if (rc != 4)
         return ERROR_FAIL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 12:14:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 12: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 1Rlg18-0003UT-S3; Fri, 13 Jan 2012 12:13: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 1Rlg16-0003UO-OC
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 12:13:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326456830!10778651!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI2MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI2MTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14887 invoked from network); 13 Jan 2012 12:13:50 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 12:13:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326456830; l=531;
	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=g+8EYxT07muRMZ+5LRUywarjWcQ=;
	b=hjKRpEsa2g/CRCpHTI8fnrDoi3GgsZjIUbBbO6JzfOcMP365CI4eF21uwGvdZhT3/6M
	0K6Bwh0aNV7130DKsR8g5V7HvNy6RCTTc88JlGf59OkI05lEj0CvDmRxSt67Gp51eInmo
	kEcY0QaT7jUpJEePBxlm3W8EEyhGFQoV/gs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhi0PFa/V
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-098-169.pools.arcor-ip.net [88.65.98.169])
	by smtp.strato.de (jimi mo24) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v06ad2o0DBK0hb ;
	Fri, 13 Jan 2012 13:13:35 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1AD2F18637; Fri, 13 Jan 2012 13:13:35 +0100 (CET)
Date: Fri, 13 Jan 2012 13:13:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120113121334.GA20030@aepfle.de>
References: <20120112182222.GA12596@aepfle.de>
	<alpine.DEB.2.00.1201131029270.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201131029270.3150@kaball-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 13, Stefano Stabellini wrote:

> I guess it is not possible to send the usual ioreq with type ==
> IOREQ_TYPE_INVALIDATE because the pager is separate from the hypervisor,
> correct?

Maybe send_invalidate_req() could be triggerd by the pager in some way?
Andres sent a patch to move from domctl to memop. Maybe the paging part
of it could be extended to issue another command which just calls
send_invalidate_req(). If thats possible, then I assume the upstream
qemu does not need changing as well.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 12:14:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 12: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 1Rlg18-0003UT-S3; Fri, 13 Jan 2012 12:13: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 1Rlg16-0003UO-OC
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 12:13:57 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326456830!10778651!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI2MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI2MTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14887 invoked from network); 13 Jan 2012 12:13:50 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 12:13:50 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326456830; l=531;
	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=g+8EYxT07muRMZ+5LRUywarjWcQ=;
	b=hjKRpEsa2g/CRCpHTI8fnrDoi3GgsZjIUbBbO6JzfOcMP365CI4eF21uwGvdZhT3/6M
	0K6Bwh0aNV7130DKsR8g5V7HvNy6RCTTc88JlGf59OkI05lEj0CvDmRxSt67Gp51eInmo
	kEcY0QaT7jUpJEePBxlm3W8EEyhGFQoV/gs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhi0PFa/V
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-098-169.pools.arcor-ip.net [88.65.98.169])
	by smtp.strato.de (jimi mo24) (RZmta 27.3 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id v06ad2o0DBK0hb ;
	Fri, 13 Jan 2012 13:13:35 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1AD2F18637; Fri, 13 Jan 2012 13:13:35 +0100 (CET)
Date: Fri, 13 Jan 2012 13:13:34 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120113121334.GA20030@aepfle.de>
References: <20120112182222.GA12596@aepfle.de>
	<alpine.DEB.2.00.1201131029270.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201131029270.3150@kaball-desktop>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] qemu-dm: add command to flush buffer cache
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 13, Stefano Stabellini wrote:

> I guess it is not possible to send the usual ioreq with type ==
> IOREQ_TYPE_INVALIDATE because the pager is separate from the hypervisor,
> correct?

Maybe send_invalidate_req() could be triggerd by the pager in some way?
Andres sent a patch to move from domctl to memop. Maybe the paging part
of it could be extended to issue another command which just calls
send_invalidate_req(). If thats possible, then I assume the upstream
qemu does not need changing as well.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 12:47:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 12:47:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlgWu-00042c-8T; Fri, 13 Jan 2012 12:46: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 1RlgWt-00041s-1e
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 12:46:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326458799!9009898!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 6255 invoked from network); 13 Jan 2012 12:46:40 -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;
	13 Jan 2012 12:46:40 -0000
Received: by pbcc6 with SMTP id c6so9454932pbc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 04:46: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=PwIWzqMgYlvKWzGZEpbNkPRh4oY8hIi+F1Rd2GtZMUU=;
	b=QowRx4ABlxm6/V6N7hLvTf2zcCn7OARPL8YdiLisdhBsX7djIBBOx3xrYP1APkB/bI
	+hJWG4/x7tT13HmNxqqV1CFHzONXPECDdgBhTtED31AmQX3ytQW/1S0BbNjdbnLOfuzi
	gXaptc746GTOtOnJfI1ORqMGjNGzruLB56+qE=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr1526831pbc.77.1326458798666; Fri,
	13 Jan 2012 04:46:38 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Fri, 13 Jan 2012 04:46:38 -0800 (PST)
In-Reply-To: <20231.6979.676569.115840@mariner.uk.xensource.com>
References: <4F0703B1.2010207@amd.com>
	<20231.6979.676569.115840@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:46:38 +0100
X-Google-Sender-Auth: Uy_2Mot5Tii6dr-x_NDQI6xdFw4
Message-ID: <CAPLaKK52d4ySdPK5vdBW=Y3aqgOLTdO_Gu-gjb6E87WM60oskQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] missing libxl patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzYgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IENocmlz
dG9waCBFZ2dlciB3cml0ZXMgKCJtaXNzaW5nIGxpYnhsIHBhdGNoZXMiKToKPj4gYW55IHJlYXNv
biB0byBub3QgYXBwbHkgYWxsIHBhdGNoZXMgZnJvbSBSb2dlcgo+PiAoaHR0cDovL2xpc3RzLnhl
bi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0xMi9tc2cwMTM4MC5odG1sKSA/Cj4K
PiBJIHRoaW5rIHdlJ3JlIHN0aWxsIGhhdmluZyBhIGNvbnZlcnNhdGlvbiBhYm91dCBob3cgc2Ny
aXB0cyBzaG91bGQgYmUKPiBydW4sIHdoaWNoIGlzIHRpZWQgdXAgd2l0aCB0aGUgQlNEIHhlbmJh
Y2tlbmRkIHN0dWZmLgo+Cj4gU29tZSBvZiBSb2dlcidzIHBhdGNoZXMgY291bGQgcHJvYmFibHkg
YmUgYXBwbGllZCBhbnl3YXkgYnV0IEkgaGF2ZW4ndAo+IGhhZCB0aW1lIHlldCB0byBkZWNpZGUg
ZXhhY3RseSB3aGljaC4KPgo+PiBsaWJ4bCBmYWlscyB0byBidWlsZCBmb3IgbWUgYmVjYXVzZSBQ
VEhSRUFEX1JFQ1VSU0lWRV9JTklUSUFMSVpFUl9OUAo+PiBpcyBub3QgYXZhaWxhYmxlIG9uIE5l
dEJTRC4KPgo+IFVyZ2gsIG5vdyB5b3UndmUgZHJhd24gbXkgYXR0ZW50aW9uIHRvIHRoaXMgSSd2
ZSBqdXN0IHJlYWQgdGhhdCBwYXRjaC4KPiBIb3cgdW5wbGVhc2FudC4gwqBJIHRoaW5rIHdlIHNo
b3VsZCBicmVhayB0aGF0IGludG8gaXRzIG93biBmdW5jdGlvbi4KCkknbSBnb2luZyB0byBicmVh
ayB0aGUgbXV0ZXggaW5pdGlhbGl6YXRpb24gdG8gYSBzZXBhcmF0ZSBmdW5jdGlvbiBhbmQKc3Vi
bWl0IHRoaXMgcGF0Y2ggb24gaXQncyBvd24sIHNpbmNlIGl0IGRvZXNuJ3QgaGF2ZSBhbnl0aGlu
ZyB0byBkbwp3aXRoIGhvdHBsdWcgc2NyaXB0cy4KCj4gSWFuLgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 13 12:47:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 12:47:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlgWu-00042c-8T; Fri, 13 Jan 2012 12:46: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 1RlgWt-00041s-1e
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 12:46:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326458799!9009898!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 6255 invoked from network); 13 Jan 2012 12:46:40 -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;
	13 Jan 2012 12:46:40 -0000
Received: by pbcc6 with SMTP id c6so9454932pbc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 04:46: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=PwIWzqMgYlvKWzGZEpbNkPRh4oY8hIi+F1Rd2GtZMUU=;
	b=QowRx4ABlxm6/V6N7hLvTf2zcCn7OARPL8YdiLisdhBsX7djIBBOx3xrYP1APkB/bI
	+hJWG4/x7tT13HmNxqqV1CFHzONXPECDdgBhTtED31AmQX3ytQW/1S0BbNjdbnLOfuzi
	gXaptc746GTOtOnJfI1ORqMGjNGzruLB56+qE=
MIME-Version: 1.0
Received: by 10.68.199.38 with SMTP id jh6mr1526831pbc.77.1326458798666; Fri,
	13 Jan 2012 04:46:38 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Fri, 13 Jan 2012 04:46:38 -0800 (PST)
In-Reply-To: <20231.6979.676569.115840@mariner.uk.xensource.com>
References: <4F0703B1.2010207@amd.com>
	<20231.6979.676569.115840@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:46:38 +0100
X-Google-Sender-Auth: Uy_2Mot5Tii6dr-x_NDQI6xdFw4
Message-ID: <CAPLaKK52d4ySdPK5vdBW=Y3aqgOLTdO_Gu-gjb6E87WM60oskQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>, xen-devel@lists.xensource.com,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] missing libxl patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzYgSWFuIEphY2tzb24gPElhbi5KYWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+IENocmlz
dG9waCBFZ2dlciB3cml0ZXMgKCJtaXNzaW5nIGxpYnhsIHBhdGNoZXMiKToKPj4gYW55IHJlYXNv
biB0byBub3QgYXBwbHkgYWxsIHBhdGNoZXMgZnJvbSBSb2dlcgo+PiAoaHR0cDovL2xpc3RzLnhl
bi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0xMi9tc2cwMTM4MC5odG1sKSA/Cj4K
PiBJIHRoaW5rIHdlJ3JlIHN0aWxsIGhhdmluZyBhIGNvbnZlcnNhdGlvbiBhYm91dCBob3cgc2Ny
aXB0cyBzaG91bGQgYmUKPiBydW4sIHdoaWNoIGlzIHRpZWQgdXAgd2l0aCB0aGUgQlNEIHhlbmJh
Y2tlbmRkIHN0dWZmLgo+Cj4gU29tZSBvZiBSb2dlcidzIHBhdGNoZXMgY291bGQgcHJvYmFibHkg
YmUgYXBwbGllZCBhbnl3YXkgYnV0IEkgaGF2ZW4ndAo+IGhhZCB0aW1lIHlldCB0byBkZWNpZGUg
ZXhhY3RseSB3aGljaC4KPgo+PiBsaWJ4bCBmYWlscyB0byBidWlsZCBmb3IgbWUgYmVjYXVzZSBQ
VEhSRUFEX1JFQ1VSU0lWRV9JTklUSUFMSVpFUl9OUAo+PiBpcyBub3QgYXZhaWxhYmxlIG9uIE5l
dEJTRC4KPgo+IFVyZ2gsIG5vdyB5b3UndmUgZHJhd24gbXkgYXR0ZW50aW9uIHRvIHRoaXMgSSd2
ZSBqdXN0IHJlYWQgdGhhdCBwYXRjaC4KPiBIb3cgdW5wbGVhc2FudC4gwqBJIHRoaW5rIHdlIHNo
b3VsZCBicmVhayB0aGF0IGludG8gaXRzIG93biBmdW5jdGlvbi4KCkknbSBnb2luZyB0byBicmVh
ayB0aGUgbXV0ZXggaW5pdGlhbGl6YXRpb24gdG8gYSBzZXBhcmF0ZSBmdW5jdGlvbiBhbmQKc3Vi
bWl0IHRoaXMgcGF0Y2ggb24gaXQncyBvd24sIHNpbmNlIGl0IGRvZXNuJ3QgaGF2ZSBhbnl0aGlu
ZyB0byBkbwp3aXRoIGhvdHBsdWcgc2NyaXB0cy4KCj4gSWFuLgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:07:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlgqg-0004cX-5F; Fri, 13 Jan 2012 13:07:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rlgqe-0004cP-KC
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:07:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326460026!10908188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12215 invoked from network); 13 Jan 2012 13:07:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 13:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9997981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:07: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, 13 Jan 2012 13:07:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 13 Jan 2012 13:07:05 +0000
In-Reply-To: <887a3229fd7a50c04981.1326455824@loki.upc.es>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326460025.17210.343.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: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 11:57 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1326454785 -3600
> # Node ID 887a3229fd7a50c04981e29709bc7210dafef38f
> # Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
> libxl: don't set backend state to 5 when trying to unplug a device
> 
> libxl__device_remove was setting backend state to 5, which could
> create a race condition, since the previous check for state != 4 and
> setting state to 5 was not done inside of the same transaction, so the
> kernel could change the state to 6 in the space between the check for
> state != 4 and setting state to 5.
> 
> I might be wrong, but since I don't think setting backend state to 5
> helps in any way when disconnecting a device

It's the exact thing which makes the disconnect happen at all, isn't it?

Some backends (particularly the Linux ones) might also use the online
node but I don't think that behaviour is universal.

>  I've just removed the
> xs_write.  If this is necessary, the state != 4 check and setting it
> to 5 should happen inside the same transaction, to avoid the kernel
> from changing the state behind our back.

I think that is the right solution.

Ian.

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 5b2676ac1321 -r 887a3229fd7a tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_device.c	Fri Jan 13 12:39:45 2012 +0100
> @@ -456,7 +456,6 @@ int libxl__device_remove(libxl__gc *gc, 
>  retry_transaction:
>      t = xs_transaction_start(ctx->xsh);
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
> -    xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
>      if (!xs_transaction_end(ctx->xsh, t, 0)) {
>          if (errno == EAGAIN)
>              goto retry_transaction;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 13 13:07:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:07:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlgqg-0004cX-5F; Fri, 13 Jan 2012 13:07:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rlgqe-0004cP-KC
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:07:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326460026!10908188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12215 invoked from network); 13 Jan 2012 13:07:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 13:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9997981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:07: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, 13 Jan 2012 13:07:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Date: Fri, 13 Jan 2012 13:07:05 +0000
In-Reply-To: <887a3229fd7a50c04981.1326455824@loki.upc.es>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326460025.17210.343.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: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 11:57 +0000, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1326454785 -3600
> # Node ID 887a3229fd7a50c04981e29709bc7210dafef38f
> # Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
> libxl: don't set backend state to 5 when trying to unplug a device
> 
> libxl__device_remove was setting backend state to 5, which could
> create a race condition, since the previous check for state != 4 and
> setting state to 5 was not done inside of the same transaction, so the
> kernel could change the state to 6 in the space between the check for
> state != 4 and setting state to 5.
> 
> I might be wrong, but since I don't think setting backend state to 5
> helps in any way when disconnecting a device

It's the exact thing which makes the disconnect happen at all, isn't it?

Some backends (particularly the Linux ones) might also use the online
node but I don't think that behaviour is universal.

>  I've just removed the
> xs_write.  If this is necessary, the state != 4 check and setting it
> to 5 should happen inside the same transaction, to avoid the kernel
> from changing the state behind our back.

I think that is the right solution.

Ian.

> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 5b2676ac1321 -r 887a3229fd7a tools/libxl/libxl_device.c
> --- a/tools/libxl/libxl_device.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_device.c	Fri Jan 13 12:39:45 2012 +0100
> @@ -456,7 +456,6 @@ int libxl__device_remove(libxl__gc *gc, 
>  retry_transaction:
>      t = xs_transaction_start(ctx->xsh);
>      xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
> -    xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
>      if (!xs_transaction_end(ctx->xsh, t, 0)) {
>          if (errno == EAGAIN)
>              goto retry_transaction;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 13 13:11:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:11:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlgtx-0004im-Ov; Fri, 13 Jan 2012 13:10:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rlgtv-0004ia-EQ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:10:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326460226!7678787!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 3443 invoked from network); 13 Jan 2012 13:10:28 -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;
	13 Jan 2012 13:10:28 -0000
Received: by pbcc6 with SMTP id c6so9566251pbc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 05:10: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=xzHNGPjfMJrKMwu8p4bcqpIESeV4HVPDR1wVEt55wIQ=;
	b=Djl5v8LKbvNBexyNfT7iPK6IrhhAKD1zxQ+Ipkmj9Am1sQ+peuLF4BOeKFZ6H8aean
	VidCSjluknQzMMgPaHwHRIA9EuaA7aE2N+Zc/ENCwK1HGEiwImCpx6VZclYljPaB9e+o
	fTPiOXSet1DUyyTFP9LoAnVvYNdMIN6i/9jfo=
MIME-Version: 1.0
Received: by 10.68.72.8 with SMTP id z8mr1554167pbu.111.1326460226646; Fri, 13
	Jan 2012 05:10:26 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Fri, 13 Jan 2012 05:10:26 -0800 (PST)
In-Reply-To: <1326460025.17210.343.camel@zakaz.uk.xensource.com>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
	<1326460025.17210.343.camel@zakaz.uk.xensource.com>
Date: Fri, 13 Jan 2012 14:10:26 +0100
X-Google-Sender-Auth: x1-PR42n5gS8fq-dRoeKgmOhNdE
Message-ID: <CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@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: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIEZy
aSwgMjAxMi0wMS0xMyBhdCAxMTo1NyArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiAj
IEhHIGNoYW5nZXNldCBwYXRjaAo+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVA
ZW50ZWwudXBjLmVkdT4KPj4gIyBEYXRlIDEzMjY0NTQ3ODUgLTM2MDAKPj4gIyBOb2RlIElEIDg4
N2EzMjI5ZmQ3YTUwYzA0OTgxZTI5NzA5YmM3MjEwZGFmZWYzOGYKPj4gIyBQYXJlbnQgwqA1YjI2
NzZhYzEzMjE4OTUxNjk4YzQ5ZmEwMzUwZjJhYzQ4MjIwZjNkCj4+IGxpYnhsOiBkb24ndCBzZXQg
YmFja2VuZCBzdGF0ZSB0byA1IHdoZW4gdHJ5aW5nIHRvIHVucGx1ZyBhIGRldmljZQo+Pgo+PiBs
aWJ4bF9fZGV2aWNlX3JlbW92ZSB3YXMgc2V0dGluZyBiYWNrZW5kIHN0YXRlIHRvIDUsIHdoaWNo
IGNvdWxkCj4+IGNyZWF0ZSBhIHJhY2UgY29uZGl0aW9uLCBzaW5jZSB0aGUgcHJldmlvdXMgY2hl
Y2sgZm9yIHN0YXRlICE9IDQgYW5kCj4+IHNldHRpbmcgc3RhdGUgdG8gNSB3YXMgbm90IGRvbmUg
aW5zaWRlIG9mIHRoZSBzYW1lIHRyYW5zYWN0aW9uLCBzbyB0aGUKPj4ga2VybmVsIGNvdWxkIGNo
YW5nZSB0aGUgc3RhdGUgdG8gNiBpbiB0aGUgc3BhY2UgYmV0d2VlbiB0aGUgY2hlY2sgZm9yCj4+
IHN0YXRlICE9IDQgYW5kIHNldHRpbmcgc3RhdGUgdG8gNS4KPj4KPj4gSSBtaWdodCBiZSB3cm9u
ZywgYnV0IHNpbmNlIEkgZG9uJ3QgdGhpbmsgc2V0dGluZyBiYWNrZW5kIHN0YXRlIHRvIDUKPj4g
aGVscHMgaW4gYW55IHdheSB3aGVuIGRpc2Nvbm5lY3RpbmcgYSBkZXZpY2UKPgo+IEl0J3MgdGhl
IGV4YWN0IHRoaW5nIHdoaWNoIG1ha2VzIHRoZSBkaXNjb25uZWN0IGhhcHBlbiBhdCBhbGwsIGlz
bid0IGl0PwoKV2hhdCBtYWtlcyB0aGUgZGlzY29ubmVjdCBoYXBwZW4gb24gTmV0QlNEIGFsIGxl
YXN0IGlzIHJlbW92aW5nIHRoZQpmcm9udGVuZCBvciBzZXR0aW5nIHRoZSBmcm9udGVuZCBzdGF0
ZSB0byA2LCBidXQgdGhpcyBkb2Vzbid0IGRvCmFueXRoaW5nIGF0IGFsbCAoaXQgbWlnaHQgYmUg
ZGlmZmVyZW50IG9uIExpbnV4IHRob3VnaCkuIENhbiBzb21lb25lCmNvbmZpcm0gdGhhdCB0aGlz
IGlzIGFjdHVhbGx5IHVzZWZ1bCBvbiBMaW51eD8KCj4gU29tZSBiYWNrZW5kcyAocGFydGljdWxh
cmx5IHRoZSBMaW51eCBvbmVzKSBtaWdodCBhbHNvIHVzZSB0aGUgb25saW5lCj4gbm9kZSBidXQg
SSBkb24ndCB0aGluayB0aGF0IGJlaGF2aW91ciBpcyB1bml2ZXJzYWwuCj4KPj4gwqBJJ3ZlIGp1
c3QgcmVtb3ZlZCB0aGUKPj4geHNfd3JpdGUuIMKgSWYgdGhpcyBpcyBuZWNlc3NhcnksIHRoZSBz
dGF0ZSAhPSA0IGNoZWNrIGFuZCBzZXR0aW5nIGl0Cj4+IHRvIDUgc2hvdWxkIGhhcHBlbiBpbnNp
ZGUgdGhlIHNhbWUgdHJhbnNhY3Rpb24sIHRvIGF2b2lkIHRoZSBrZXJuZWwKPj4gZnJvbSBjaGFu
Z2luZyB0aGUgc3RhdGUgYmVoaW5kIG91ciBiYWNrLgo+Cj4gSSB0aGluayB0aGF0IGlzIHRoZSBy
aWdodCBzb2x1dGlvbi4KPgo+IElhbi4KPgo+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pgo+PiBkaWZmIC1yIDViMjY3NmFjMTMyMSAt
ciA4ODdhMzIyOWZkN2EgdG9vbHMvbGlieGwvbGlieGxfZGV2aWNlLmMKPj4gLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfZGV2aWNlLmMgwqAgwqAgwqBNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAx
MDAKPj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGxfZGV2aWNlLmMgwqAgwqAgwqBGcmkgSmFuIDEz
IDEyOjM5OjQ1IDIwMTIgKzAxMDAKPj4gQEAgLTQ1Niw3ICs0NTYsNiBAQCBpbnQgbGlieGxfX2Rl
dmljZV9yZW1vdmUobGlieGxfX2djICpnYywKPj4gwqByZXRyeV90cmFuc2FjdGlvbjoKPj4gwqAg
wqAgwqB0ID0geHNfdHJhbnNhY3Rpb25fc3RhcnQoY3R4LT54c2gpOwo+PiDCoCDCoCDCoHhzX3dy
aXRlKGN0eC0+eHNoLCB0LCBsaWJ4bF9fc3ByaW50ZihnYywgIiVzL29ubGluZSIsIGJlX3BhdGgp
LCAiMCIsIHN0cmxlbigiMCIpKTsKPj4gLSDCoCDCoHhzX3dyaXRlKGN0eC0+eHNoLCB0LCBzdGF0
ZV9wYXRoLCAiNSIsIHN0cmxlbigiNSIpKTsKPj4gwqAgwqAgwqBpZiAoIXhzX3RyYW5zYWN0aW9u
X2VuZChjdHgtPnhzaCwgdCwgMCkpIHsKPj4gwqAgwqAgwqAgwqAgwqBpZiAoZXJybm8gPT0gRUFH
QUlOKQo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoGdvdG8gcmV0cnlfdHJhbnNhY3Rpb247Cj4+Cj4+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IFhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKPj4gWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPj4gaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCj4KPgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:11:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:11:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlgtx-0004im-Ov; Fri, 13 Jan 2012 13:10:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rlgtv-0004ia-EQ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:10:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326460226!7678787!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 3443 invoked from network); 13 Jan 2012 13:10:28 -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;
	13 Jan 2012 13:10:28 -0000
Received: by pbcc6 with SMTP id c6so9566251pbc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 05:10: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=xzHNGPjfMJrKMwu8p4bcqpIESeV4HVPDR1wVEt55wIQ=;
	b=Djl5v8LKbvNBexyNfT7iPK6IrhhAKD1zxQ+Ipkmj9Am1sQ+peuLF4BOeKFZ6H8aean
	VidCSjluknQzMMgPaHwHRIA9EuaA7aE2N+Zc/ENCwK1HGEiwImCpx6VZclYljPaB9e+o
	fTPiOXSet1DUyyTFP9LoAnVvYNdMIN6i/9jfo=
MIME-Version: 1.0
Received: by 10.68.72.8 with SMTP id z8mr1554167pbu.111.1326460226646; Fri, 13
	Jan 2012 05:10:26 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Fri, 13 Jan 2012 05:10:26 -0800 (PST)
In-Reply-To: <1326460025.17210.343.camel@zakaz.uk.xensource.com>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
	<1326460025.17210.343.camel@zakaz.uk.xensource.com>
Date: Fri, 13 Jan 2012 14:10:26 +0100
X-Google-Sender-Auth: x1-PR42n5gS8fq-dRoeKgmOhNdE
Message-ID: <CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@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: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIEZy
aSwgMjAxMi0wMS0xMyBhdCAxMTo1NyArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+PiAj
IEhHIGNoYW5nZXNldCBwYXRjaAo+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVA
ZW50ZWwudXBjLmVkdT4KPj4gIyBEYXRlIDEzMjY0NTQ3ODUgLTM2MDAKPj4gIyBOb2RlIElEIDg4
N2EzMjI5ZmQ3YTUwYzA0OTgxZTI5NzA5YmM3MjEwZGFmZWYzOGYKPj4gIyBQYXJlbnQgwqA1YjI2
NzZhYzEzMjE4OTUxNjk4YzQ5ZmEwMzUwZjJhYzQ4MjIwZjNkCj4+IGxpYnhsOiBkb24ndCBzZXQg
YmFja2VuZCBzdGF0ZSB0byA1IHdoZW4gdHJ5aW5nIHRvIHVucGx1ZyBhIGRldmljZQo+Pgo+PiBs
aWJ4bF9fZGV2aWNlX3JlbW92ZSB3YXMgc2V0dGluZyBiYWNrZW5kIHN0YXRlIHRvIDUsIHdoaWNo
IGNvdWxkCj4+IGNyZWF0ZSBhIHJhY2UgY29uZGl0aW9uLCBzaW5jZSB0aGUgcHJldmlvdXMgY2hl
Y2sgZm9yIHN0YXRlICE9IDQgYW5kCj4+IHNldHRpbmcgc3RhdGUgdG8gNSB3YXMgbm90IGRvbmUg
aW5zaWRlIG9mIHRoZSBzYW1lIHRyYW5zYWN0aW9uLCBzbyB0aGUKPj4ga2VybmVsIGNvdWxkIGNo
YW5nZSB0aGUgc3RhdGUgdG8gNiBpbiB0aGUgc3BhY2UgYmV0d2VlbiB0aGUgY2hlY2sgZm9yCj4+
IHN0YXRlICE9IDQgYW5kIHNldHRpbmcgc3RhdGUgdG8gNS4KPj4KPj4gSSBtaWdodCBiZSB3cm9u
ZywgYnV0IHNpbmNlIEkgZG9uJ3QgdGhpbmsgc2V0dGluZyBiYWNrZW5kIHN0YXRlIHRvIDUKPj4g
aGVscHMgaW4gYW55IHdheSB3aGVuIGRpc2Nvbm5lY3RpbmcgYSBkZXZpY2UKPgo+IEl0J3MgdGhl
IGV4YWN0IHRoaW5nIHdoaWNoIG1ha2VzIHRoZSBkaXNjb25uZWN0IGhhcHBlbiBhdCBhbGwsIGlz
bid0IGl0PwoKV2hhdCBtYWtlcyB0aGUgZGlzY29ubmVjdCBoYXBwZW4gb24gTmV0QlNEIGFsIGxl
YXN0IGlzIHJlbW92aW5nIHRoZQpmcm9udGVuZCBvciBzZXR0aW5nIHRoZSBmcm9udGVuZCBzdGF0
ZSB0byA2LCBidXQgdGhpcyBkb2Vzbid0IGRvCmFueXRoaW5nIGF0IGFsbCAoaXQgbWlnaHQgYmUg
ZGlmZmVyZW50IG9uIExpbnV4IHRob3VnaCkuIENhbiBzb21lb25lCmNvbmZpcm0gdGhhdCB0aGlz
IGlzIGFjdHVhbGx5IHVzZWZ1bCBvbiBMaW51eD8KCj4gU29tZSBiYWNrZW5kcyAocGFydGljdWxh
cmx5IHRoZSBMaW51eCBvbmVzKSBtaWdodCBhbHNvIHVzZSB0aGUgb25saW5lCj4gbm9kZSBidXQg
SSBkb24ndCB0aGluayB0aGF0IGJlaGF2aW91ciBpcyB1bml2ZXJzYWwuCj4KPj4gwqBJJ3ZlIGp1
c3QgcmVtb3ZlZCB0aGUKPj4geHNfd3JpdGUuIMKgSWYgdGhpcyBpcyBuZWNlc3NhcnksIHRoZSBz
dGF0ZSAhPSA0IGNoZWNrIGFuZCBzZXR0aW5nIGl0Cj4+IHRvIDUgc2hvdWxkIGhhcHBlbiBpbnNp
ZGUgdGhlIHNhbWUgdHJhbnNhY3Rpb24sIHRvIGF2b2lkIHRoZSBrZXJuZWwKPj4gZnJvbSBjaGFu
Z2luZyB0aGUgc3RhdGUgYmVoaW5kIG91ciBiYWNrLgo+Cj4gSSB0aGluayB0aGF0IGlzIHRoZSBy
aWdodCBzb2x1dGlvbi4KPgo+IElhbi4KPgo+PiBTaWduZWQtb2ZmLWJ5OiBSb2dlciBQYXUgTW9u
bmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1Pgo+Pgo+PiBkaWZmIC1yIDViMjY3NmFjMTMyMSAt
ciA4ODdhMzIyOWZkN2EgdG9vbHMvbGlieGwvbGlieGxfZGV2aWNlLmMKPj4gLS0tIGEvdG9vbHMv
bGlieGwvbGlieGxfZGV2aWNlLmMgwqAgwqAgwqBNb24gSmFuIDA5IDE2OjAxOjQ0IDIwMTIgKzAx
MDAKPj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGxfZGV2aWNlLmMgwqAgwqAgwqBGcmkgSmFuIDEz
IDEyOjM5OjQ1IDIwMTIgKzAxMDAKPj4gQEAgLTQ1Niw3ICs0NTYsNiBAQCBpbnQgbGlieGxfX2Rl
dmljZV9yZW1vdmUobGlieGxfX2djICpnYywKPj4gwqByZXRyeV90cmFuc2FjdGlvbjoKPj4gwqAg
wqAgwqB0ID0geHNfdHJhbnNhY3Rpb25fc3RhcnQoY3R4LT54c2gpOwo+PiDCoCDCoCDCoHhzX3dy
aXRlKGN0eC0+eHNoLCB0LCBsaWJ4bF9fc3ByaW50ZihnYywgIiVzL29ubGluZSIsIGJlX3BhdGgp
LCAiMCIsIHN0cmxlbigiMCIpKTsKPj4gLSDCoCDCoHhzX3dyaXRlKGN0eC0+eHNoLCB0LCBzdGF0
ZV9wYXRoLCAiNSIsIHN0cmxlbigiNSIpKTsKPj4gwqAgwqAgwqBpZiAoIXhzX3RyYW5zYWN0aW9u
X2VuZChjdHgtPnhzaCwgdCwgMCkpIHsKPj4gwqAgwqAgwqAgwqAgwqBpZiAoZXJybm8gPT0gRUFH
QUlOKQo+PiDCoCDCoCDCoCDCoCDCoCDCoCDCoGdvdG8gcmV0cnlfdHJhbnNhY3Rpb247Cj4+Cj4+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IFhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKPj4gWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KPj4gaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCj4KPgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlgwg-0004r1-BM; Fri, 13 Jan 2012 13:13:26 +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 1Rlgwf-0004qh-5M
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:13:25 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326460398!2332062!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 26445 invoked from network); 13 Jan 2012 13:13:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 13:13:18 -0000
Received: by wera10 with SMTP id a10so1071179wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 05:13: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
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=HV8pGcMdZGmhg6FS/qAxWahwWJYEkI0K7+LP8D1S5AQ=;
	b=VMQmZfyoK1QzBmYiuKMYAu1YTsOM/RNV1DHGqNSNZB1/FyqCUM2FxaCUzjXPCLhM7/
	dAgvw5k4zwDU83Aucfu2CO3nIdGgycWIdJlDcpNCylc41J9PIJMOEwOOrzVcHdISEPpQ
	dsCXdWUH3PyjR/j7G/7OXxCWbhIhlqKnqUya0=
Received: by 10.216.134.162 with SMTP id s34mr355450wei.59.1326460397696;
	Fri, 13 Jan 2012 05:13:17 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id fq7sm11070956wbb.1.2012.01.13.05.13.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 13 Jan 2012 05:13:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bb6b01995d64f7c2887b7174536861b83ef04364
Message-Id: <bb6b01995d64f7c2887b.1326460363@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 13 Jan 2012 14:12:43 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] 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 1326460029 -3600
# Node ID bb6b01995d64f7c2887b7174536861b83ef04364
# Parent  117ad4634ba11c10e45f3d86e6baff35d7d2691c
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 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jan 13 13:55:01 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Jan 13 14:07:09 2012 +0100
@@ -41,7 +41,6 @@ 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;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -55,10 +54,10 @@ 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 (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        return ERROR_FAIL;
+    }
 
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl_internal.c
--- a/tools/libxl/libxl_internal.c	Fri Jan 13 13:55:01 2012 +0100
+++ b/tools/libxl/libxl_internal.c	Fri Jan 13 14:07:09 2012 +0100
@@ -304,6 +304,28 @@ _hidden int libxl__compare_macs(libxl_ma
     return 0;
 }
 
+_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock)
+{
+    pthread_mutexattr_t attr;
+
+    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(lock, &attr) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to init mutex\n");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Jan 13 13:55:01 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Jan 13 14:07:09 2012 +0100
@@ -606,6 +606,8 @@ _hidden int libxl__e820_alloc(libxl__gc 
 _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);
+/* init a recursive mutex */
+_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock);
 
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:13:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlgwg-0004r1-BM; Fri, 13 Jan 2012 13:13:26 +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 1Rlgwf-0004qh-5M
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:13:25 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326460398!2332062!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 26445 invoked from network); 13 Jan 2012 13:13:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 13:13:18 -0000
Received: by wera10 with SMTP id a10so1071179wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 05:13: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
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=HV8pGcMdZGmhg6FS/qAxWahwWJYEkI0K7+LP8D1S5AQ=;
	b=VMQmZfyoK1QzBmYiuKMYAu1YTsOM/RNV1DHGqNSNZB1/FyqCUM2FxaCUzjXPCLhM7/
	dAgvw5k4zwDU83Aucfu2CO3nIdGgycWIdJlDcpNCylc41J9PIJMOEwOOrzVcHdISEPpQ
	dsCXdWUH3PyjR/j7G/7OXxCWbhIhlqKnqUya0=
Received: by 10.216.134.162 with SMTP id s34mr355450wei.59.1326460397696;
	Fri, 13 Jan 2012 05:13:17 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id fq7sm11070956wbb.1.2012.01.13.05.13.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 13 Jan 2012 05:13:16 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bb6b01995d64f7c2887b7174536861b83ef04364
Message-Id: <bb6b01995d64f7c2887b.1326460363@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 13 Jan 2012 14:12:43 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] 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 1326460029 -3600
# Node ID bb6b01995d64f7c2887b7174536861b83ef04364
# Parent  117ad4634ba11c10e45f3d86e6baff35d7d2691c
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 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jan 13 13:55:01 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Jan 13 14:07:09 2012 +0100
@@ -41,7 +41,6 @@ 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;
 
     if (version != LIBXL_VERSION)
         return ERROR_VERSION;
@@ -55,10 +54,10 @@ 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 (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        return ERROR_FAIL;
+    }
 
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl_internal.c
--- a/tools/libxl/libxl_internal.c	Fri Jan 13 13:55:01 2012 +0100
+++ b/tools/libxl/libxl_internal.c	Fri Jan 13 14:07:09 2012 +0100
@@ -304,6 +304,28 @@ _hidden int libxl__compare_macs(libxl_ma
     return 0;
 }
 
+_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock)
+{
+    pthread_mutexattr_t attr;
+
+    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(lock, &attr) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to init mutex\n");
+        return ERROR_FAIL;
+    }
+    return 0;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Jan 13 13:55:01 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Jan 13 14:07:09 2012 +0100
@@ -606,6 +606,8 @@ _hidden int libxl__e820_alloc(libxl__gc 
 _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);
+/* init a recursive mutex */
+_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock);
 
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:21:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13: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 1Rlh3t-00055c-Al; Fri, 13 Jan 2012 13:20: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 1Rlh3r-00055U-Mx
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326460845!10872330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7155 invoked from network); 13 Jan 2012 13:20:45 -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 Jan 2012 13:20:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:20: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, 13 Jan 2012 13:20: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, 13 Jan 2012 13:20:44 +0000
In-Reply-To: <CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@mail.gmail.com>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
	<1326460025.17210.343.camel@zakaz.uk.xensource.com>
	<CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326460844.17210.349.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: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDEyLTAxLTEzIGF0IDEzOjEwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8xMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIEZyaSwgMjAxMi0wMS0xMyBhdCAxMTo1NyArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3Rl
Ogo+ID4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4gPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8
cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4gPj4gIyBEYXRlIDEzMjY0NTQ3ODUgLTM2MDAKPiA+
PiAjIE5vZGUgSUQgODg3YTMyMjlmZDdhNTBjMDQ5ODFlMjk3MDliYzcyMTBkYWZlZjM4Zgo+ID4+
ICMgUGFyZW50ICA1YjI2NzZhYzEzMjE4OTUxNjk4YzQ5ZmEwMzUwZjJhYzQ4MjIwZjNkCj4gPj4g
bGlieGw6IGRvbid0IHNldCBiYWNrZW5kIHN0YXRlIHRvIDUgd2hlbiB0cnlpbmcgdG8gdW5wbHVn
IGEgZGV2aWNlCj4gPj4KPiA+PiBsaWJ4bF9fZGV2aWNlX3JlbW92ZSB3YXMgc2V0dGluZyBiYWNr
ZW5kIHN0YXRlIHRvIDUsIHdoaWNoIGNvdWxkCj4gPj4gY3JlYXRlIGEgcmFjZSBjb25kaXRpb24s
IHNpbmNlIHRoZSBwcmV2aW91cyBjaGVjayBmb3Igc3RhdGUgIT0gNCBhbmQKPiA+PiBzZXR0aW5n
IHN0YXRlIHRvIDUgd2FzIG5vdCBkb25lIGluc2lkZSBvZiB0aGUgc2FtZSB0cmFuc2FjdGlvbiwg
c28gdGhlCj4gPj4ga2VybmVsIGNvdWxkIGNoYW5nZSB0aGUgc3RhdGUgdG8gNiBpbiB0aGUgc3Bh
Y2UgYmV0d2VlbiB0aGUgY2hlY2sgZm9yCj4gPj4gc3RhdGUgIT0gNCBhbmQgc2V0dGluZyBzdGF0
ZSB0byA1Lgo+ID4+Cj4gPj4gSSBtaWdodCBiZSB3cm9uZywgYnV0IHNpbmNlIEkgZG9uJ3QgdGhp
bmsgc2V0dGluZyBiYWNrZW5kIHN0YXRlIHRvIDUKPiA+PiBoZWxwcyBpbiBhbnkgd2F5IHdoZW4g
ZGlzY29ubmVjdGluZyBhIGRldmljZQo+ID4KPiA+IEl0J3MgdGhlIGV4YWN0IHRoaW5nIHdoaWNo
IG1ha2VzIHRoZSBkaXNjb25uZWN0IGhhcHBlbiBhdCBhbGwsIGlzbid0IGl0Pwo+IAo+IFdoYXQg
bWFrZXMgdGhlIGRpc2Nvbm5lY3QgaGFwcGVuIG9uIE5ldEJTRCBhbCBsZWFzdCBpcyByZW1vdmlu
ZyB0aGUKPiBmcm9udGVuZCBvciBzZXR0aW5nIHRoZSBmcm9udGVuZCBzdGF0ZSB0byA2LCBidXQg
dGhpcyBkb2Vzbid0IGRvCj4gYW55dGhpbmcgYXQgYWxsIChpdCBtaWdodCBiZSBkaWZmZXJlbnQg
b24gTGludXggdGhvdWdoKS4KCkxpbnV4IGNlcnRhaW5seSB1c2VzIHN0YXRlIDUgKEFLQSBYZW5i
dXNTdGF0ZUNsb3NpbmcpIGluIHRoZSBzdGF0ZQptYWNoaW5lIGluIGF0IGxlYXN0IG5ldGZyb250
K2JhY2ssIGJsa2Zyb250K2JhY2sgcGNpZnJvbnQrYmFjayBhbmQKZmJmcm9udCAoZmJiYWNrIGlz
IG5vdCBhbiBpbiBrZXJuZWwgZHJpdmVyKS4KCmUuZy4gd2hlbiBuZXRmcm9udCBzZWVzIG5ldGJh
Y2sgZ28gdG8gY2xvc2luZyB0aGVuIGl0IHdpbGwgc2h1dCBpdHNlbGYKZG93biwgc2VlIGRyaXZl
cnMvbmV0L3hlbi1uZXRmcm9udC5jOm5ldGJhY2tfY2hhbmdlZAoKPiBDYW4gc29tZW9uZSBjb25m
aXJtIHRoYXQgdGhpcyBpcyBhY3R1YWxseSB1c2VmdWwgb24gTGludXg/CgpJIHRoaW5rIHJlYWxs
eSBhbnkgY2hhbmdlcyBpbiB0aGVzZSBhcmVhcyBzaG91bGQgYmUgYmFja2VkIHVwIHdpdGgKZW1w
aXJpY2FsIGV4cGVyaW1lbnRzIG9uIGEgdmFyaWV0eSBvZiBzeXN0ZW0gdHlwZXMgKGJvdGggZnJv
bnQgYW5kCmJhY2spLCBvdGhlcndpc2Ugd2UgYXJlIGJhc2luZyB0aGluZ3Mgb24gc3VwcG9zaXRp
b24gYW5kIGhlcmVzYXkgYWJvdXQKaG93IHRoaW5ncyBhcmUgc3VwcG9zZWQgdG8vZG8gd29yay4g
Tm8gb25lIHJlYWxseSBrbm93cyBmb3Igc3VyZQood2l0bmVzcyB0aGUgbnVtYmVyIG9mIHRpbWVz
IHdlJ3ZlIGFsbCBnb25lIHJvdW5kIG9uIHRoaXMpLgoKSWFuLgoKPiAKPiA+IFNvbWUgYmFja2Vu
ZHMgKHBhcnRpY3VsYXJseSB0aGUgTGludXggb25lcykgbWlnaHQgYWxzbyB1c2UgdGhlIG9ubGlu
ZQo+ID4gbm9kZSBidXQgSSBkb24ndCB0aGluayB0aGF0IGJlaGF2aW91ciBpcyB1bml2ZXJzYWwu
Cj4gPgo+ID4+ICBJJ3ZlIGp1c3QgcmVtb3ZlZCB0aGUKPiA+PiB4c193cml0ZS4gIElmIHRoaXMg
aXMgbmVjZXNzYXJ5LCB0aGUgc3RhdGUgIT0gNCBjaGVjayBhbmQgc2V0dGluZyBpdAo+ID4+IHRv
IDUgc2hvdWxkIGhhcHBlbiBpbnNpZGUgdGhlIHNhbWUgdHJhbnNhY3Rpb24sIHRvIGF2b2lkIHRo
ZSBrZXJuZWwKPiA+PiBmcm9tIGNoYW5naW5nIHRoZSBzdGF0ZSBiZWhpbmQgb3VyIGJhY2suCj4g
Pgo+ID4gSSB0aGluayB0aGF0IGlzIHRoZSByaWdodCBzb2x1dGlvbi4KPiA+Cj4gPiBJYW4uCj4g
Pgo+ID4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVw
Yy5lZHU+Cj4gPj4KPiA+PiBkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA4ODdhMzIyOWZkN2EgdG9v
bHMvbGlieGwvbGlieGxfZGV2aWNlLmMKPiA+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9kZXZp
Y2UuYyAgICAgIE1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAo+ID4+ICsrKyBiL3Rvb2xz
L2xpYnhsL2xpYnhsX2RldmljZS5jICAgICAgRnJpIEphbiAxMyAxMjozOTo0NSAyMDEyICswMTAw
Cj4gPj4gQEAgLTQ1Niw3ICs0NTYsNiBAQCBpbnQgbGlieGxfX2RldmljZV9yZW1vdmUobGlieGxf
X2djICpnYywKPiA+PiAgcmV0cnlfdHJhbnNhY3Rpb246Cj4gPj4gICAgICB0ID0geHNfdHJhbnNh
Y3Rpb25fc3RhcnQoY3R4LT54c2gpOwo+ID4+ICAgICAgeHNfd3JpdGUoY3R4LT54c2gsIHQsIGxp
YnhsX19zcHJpbnRmKGdjLCAiJXMvb25saW5lIiwgYmVfcGF0aCksICIwIiwgc3RybGVuKCIwIikp
Owo+ID4+IC0gICAgeHNfd3JpdGUoY3R4LT54c2gsIHQsIHN0YXRlX3BhdGgsICI1Iiwgc3RybGVu
KCI1IikpOwo+ID4+ICAgICAgaWYgKCF4c190cmFuc2FjdGlvbl9lbmQoY3R4LT54c2gsIHQsIDAp
KSB7Cj4gPj4gICAgICAgICAgaWYgKGVycm5vID09IEVBR0FJTikKPiA+PiAgICAgICAgICAgICAg
Z290byByZXRyeV90cmFuc2FjdGlvbjsKPiA+Pgo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+ID4+
IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gPj4gaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCj4gPgo+ID4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:21:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13: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 1Rlh3t-00055c-Al; Fri, 13 Jan 2012 13:20: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 1Rlh3r-00055U-Mx
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:20:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326460845!10872330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7155 invoked from network); 13 Jan 2012 13:20:45 -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 Jan 2012 13:20:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:20: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, 13 Jan 2012 13:20: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, 13 Jan 2012 13:20:44 +0000
In-Reply-To: <CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@mail.gmail.com>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
	<1326460025.17210.343.camel@zakaz.uk.xensource.com>
	<CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326460844.17210.349.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: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDEyLTAxLTEzIGF0IDEzOjEwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8xMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIEZyaSwgMjAxMi0wMS0xMyBhdCAxMTo1NyArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3Rl
Ogo+ID4+ICMgSEcgY2hhbmdlc2V0IHBhdGNoCj4gPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8
cm9nZXIucGF1QGVudGVsLnVwYy5lZHU+Cj4gPj4gIyBEYXRlIDEzMjY0NTQ3ODUgLTM2MDAKPiA+
PiAjIE5vZGUgSUQgODg3YTMyMjlmZDdhNTBjMDQ5ODFlMjk3MDliYzcyMTBkYWZlZjM4Zgo+ID4+
ICMgUGFyZW50ICA1YjI2NzZhYzEzMjE4OTUxNjk4YzQ5ZmEwMzUwZjJhYzQ4MjIwZjNkCj4gPj4g
bGlieGw6IGRvbid0IHNldCBiYWNrZW5kIHN0YXRlIHRvIDUgd2hlbiB0cnlpbmcgdG8gdW5wbHVn
IGEgZGV2aWNlCj4gPj4KPiA+PiBsaWJ4bF9fZGV2aWNlX3JlbW92ZSB3YXMgc2V0dGluZyBiYWNr
ZW5kIHN0YXRlIHRvIDUsIHdoaWNoIGNvdWxkCj4gPj4gY3JlYXRlIGEgcmFjZSBjb25kaXRpb24s
IHNpbmNlIHRoZSBwcmV2aW91cyBjaGVjayBmb3Igc3RhdGUgIT0gNCBhbmQKPiA+PiBzZXR0aW5n
IHN0YXRlIHRvIDUgd2FzIG5vdCBkb25lIGluc2lkZSBvZiB0aGUgc2FtZSB0cmFuc2FjdGlvbiwg
c28gdGhlCj4gPj4ga2VybmVsIGNvdWxkIGNoYW5nZSB0aGUgc3RhdGUgdG8gNiBpbiB0aGUgc3Bh
Y2UgYmV0d2VlbiB0aGUgY2hlY2sgZm9yCj4gPj4gc3RhdGUgIT0gNCBhbmQgc2V0dGluZyBzdGF0
ZSB0byA1Lgo+ID4+Cj4gPj4gSSBtaWdodCBiZSB3cm9uZywgYnV0IHNpbmNlIEkgZG9uJ3QgdGhp
bmsgc2V0dGluZyBiYWNrZW5kIHN0YXRlIHRvIDUKPiA+PiBoZWxwcyBpbiBhbnkgd2F5IHdoZW4g
ZGlzY29ubmVjdGluZyBhIGRldmljZQo+ID4KPiA+IEl0J3MgdGhlIGV4YWN0IHRoaW5nIHdoaWNo
IG1ha2VzIHRoZSBkaXNjb25uZWN0IGhhcHBlbiBhdCBhbGwsIGlzbid0IGl0Pwo+IAo+IFdoYXQg
bWFrZXMgdGhlIGRpc2Nvbm5lY3QgaGFwcGVuIG9uIE5ldEJTRCBhbCBsZWFzdCBpcyByZW1vdmlu
ZyB0aGUKPiBmcm9udGVuZCBvciBzZXR0aW5nIHRoZSBmcm9udGVuZCBzdGF0ZSB0byA2LCBidXQg
dGhpcyBkb2Vzbid0IGRvCj4gYW55dGhpbmcgYXQgYWxsIChpdCBtaWdodCBiZSBkaWZmZXJlbnQg
b24gTGludXggdGhvdWdoKS4KCkxpbnV4IGNlcnRhaW5seSB1c2VzIHN0YXRlIDUgKEFLQSBYZW5i
dXNTdGF0ZUNsb3NpbmcpIGluIHRoZSBzdGF0ZQptYWNoaW5lIGluIGF0IGxlYXN0IG5ldGZyb250
K2JhY2ssIGJsa2Zyb250K2JhY2sgcGNpZnJvbnQrYmFjayBhbmQKZmJmcm9udCAoZmJiYWNrIGlz
IG5vdCBhbiBpbiBrZXJuZWwgZHJpdmVyKS4KCmUuZy4gd2hlbiBuZXRmcm9udCBzZWVzIG5ldGJh
Y2sgZ28gdG8gY2xvc2luZyB0aGVuIGl0IHdpbGwgc2h1dCBpdHNlbGYKZG93biwgc2VlIGRyaXZl
cnMvbmV0L3hlbi1uZXRmcm9udC5jOm5ldGJhY2tfY2hhbmdlZAoKPiBDYW4gc29tZW9uZSBjb25m
aXJtIHRoYXQgdGhpcyBpcyBhY3R1YWxseSB1c2VmdWwgb24gTGludXg/CgpJIHRoaW5rIHJlYWxs
eSBhbnkgY2hhbmdlcyBpbiB0aGVzZSBhcmVhcyBzaG91bGQgYmUgYmFja2VkIHVwIHdpdGgKZW1w
aXJpY2FsIGV4cGVyaW1lbnRzIG9uIGEgdmFyaWV0eSBvZiBzeXN0ZW0gdHlwZXMgKGJvdGggZnJv
bnQgYW5kCmJhY2spLCBvdGhlcndpc2Ugd2UgYXJlIGJhc2luZyB0aGluZ3Mgb24gc3VwcG9zaXRp
b24gYW5kIGhlcmVzYXkgYWJvdXQKaG93IHRoaW5ncyBhcmUgc3VwcG9zZWQgdG8vZG8gd29yay4g
Tm8gb25lIHJlYWxseSBrbm93cyBmb3Igc3VyZQood2l0bmVzcyB0aGUgbnVtYmVyIG9mIHRpbWVz
IHdlJ3ZlIGFsbCBnb25lIHJvdW5kIG9uIHRoaXMpLgoKSWFuLgoKPiAKPiA+IFNvbWUgYmFja2Vu
ZHMgKHBhcnRpY3VsYXJseSB0aGUgTGludXggb25lcykgbWlnaHQgYWxzbyB1c2UgdGhlIG9ubGlu
ZQo+ID4gbm9kZSBidXQgSSBkb24ndCB0aGluayB0aGF0IGJlaGF2aW91ciBpcyB1bml2ZXJzYWwu
Cj4gPgo+ID4+ICBJJ3ZlIGp1c3QgcmVtb3ZlZCB0aGUKPiA+PiB4c193cml0ZS4gIElmIHRoaXMg
aXMgbmVjZXNzYXJ5LCB0aGUgc3RhdGUgIT0gNCBjaGVjayBhbmQgc2V0dGluZyBpdAo+ID4+IHRv
IDUgc2hvdWxkIGhhcHBlbiBpbnNpZGUgdGhlIHNhbWUgdHJhbnNhY3Rpb24sIHRvIGF2b2lkIHRo
ZSBrZXJuZWwKPiA+PiBmcm9tIGNoYW5naW5nIHRoZSBzdGF0ZSBiZWhpbmQgb3VyIGJhY2suCj4g
Pgo+ID4gSSB0aGluayB0aGF0IGlzIHRoZSByaWdodCBzb2x1dGlvbi4KPiA+Cj4gPiBJYW4uCj4g
Pgo+ID4+IFNpZ25lZC1vZmYtYnk6IFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVudGVsLnVw
Yy5lZHU+Cj4gPj4KPiA+PiBkaWZmIC1yIDViMjY3NmFjMTMyMSAtciA4ODdhMzIyOWZkN2EgdG9v
bHMvbGlieGwvbGlieGxfZGV2aWNlLmMKPiA+PiAtLS0gYS90b29scy9saWJ4bC9saWJ4bF9kZXZp
Y2UuYyAgICAgIE1vbiBKYW4gMDkgMTY6MDE6NDQgMjAxMiArMDEwMAo+ID4+ICsrKyBiL3Rvb2xz
L2xpYnhsL2xpYnhsX2RldmljZS5jICAgICAgRnJpIEphbiAxMyAxMjozOTo0NSAyMDEyICswMTAw
Cj4gPj4gQEAgLTQ1Niw3ICs0NTYsNiBAQCBpbnQgbGlieGxfX2RldmljZV9yZW1vdmUobGlieGxf
X2djICpnYywKPiA+PiAgcmV0cnlfdHJhbnNhY3Rpb246Cj4gPj4gICAgICB0ID0geHNfdHJhbnNh
Y3Rpb25fc3RhcnQoY3R4LT54c2gpOwo+ID4+ICAgICAgeHNfd3JpdGUoY3R4LT54c2gsIHQsIGxp
YnhsX19zcHJpbnRmKGdjLCAiJXMvb25saW5lIiwgYmVfcGF0aCksICIwIiwgc3RybGVuKCIwIikp
Owo+ID4+IC0gICAgeHNfd3JpdGUoY3R4LT54c2gsIHQsIHN0YXRlX3BhdGgsICI1Iiwgc3RybGVu
KCI1IikpOwo+ID4+ICAgICAgaWYgKCF4c190cmFuc2FjdGlvbl9lbmQoY3R4LT54c2gsIHQsIDAp
KSB7Cj4gPj4gICAgICAgICAgaWYgKGVycm5vID09IEVBR0FJTikKPiA+PiAgICAgICAgICAgICAg
Z290byByZXRyeV90cmFuc2FjdGlvbjsKPiA+Pgo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4gPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+ID4+
IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gPj4gaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCj4gPgo+ID4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMu
eGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:34:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:34:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlhGm-0005GE-Li; Fri, 13 Jan 2012 13:34:12 +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 1RlhGk-0005G9-TR
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:34:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326461644!10784310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13625 invoked from network); 13 Jan 2012 13:34:04 -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 Jan 2012 13:34:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:34: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; Fri, 13 Jan 2012 13:34: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
	1RlhGe-0003WD-AS; Fri, 13 Jan 2012 13:34:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlhGe-0003j8-82;
	Fri, 13 Jan 2012 13:34:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.13002.205604.969404@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:34:02 +0000
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1326409937.4494.22.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for vcpu-pin."):
> Well, that's not properly me, is it that?
> 
> hg annotate tools/libxl/xl_cmdimpl.c
> ...
> 21247:     if (strcmp(cpu, "all")) { 
> 21247:         for (toka = strtok(cpu, ","), i = 0; toka; toka = strtok(NULL, ","), ++i) {
> 21247:             cpuida = strtoul(toka, &endptr, 10);
> 21247:             if (toka == endptr) {
> ...

Oops, sorry for wrongly pointing the finger.

> Again, I know that's probably not an alibi, but that's not my code! :-P
> What I did is just move this from the body of vcpupin() to an helper
> function, and try to add as _less_ thing as I can to support a slightly
> improved syntax.

Right.

> That being said, if you think I should rewrite the parsing from scratch,
> I can think about it, just wanted to clarify my position. :-)

I really don't like the existing code here; feel free to do whatever
you think is best.

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 Jan 13 13:34:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:34:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlhGm-0005GE-Li; Fri, 13 Jan 2012 13:34:12 +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 1RlhGk-0005G9-TR
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:34:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326461644!10784310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13625 invoked from network); 13 Jan 2012 13:34:04 -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 Jan 2012 13:34:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:34: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; Fri, 13 Jan 2012 13:34: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
	1RlhGe-0003WD-AS; Fri, 13 Jan 2012 13:34:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlhGe-0003j8-82;
	Fri, 13 Jan 2012 13:34:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.13002.205604.969404@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:34:02 +0000
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1326409937.4494.22.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for vcpu-pin."):
> Well, that's not properly me, is it that?
> 
> hg annotate tools/libxl/xl_cmdimpl.c
> ...
> 21247:     if (strcmp(cpu, "all")) { 
> 21247:         for (toka = strtok(cpu, ","), i = 0; toka; toka = strtok(NULL, ","), ++i) {
> 21247:             cpuida = strtoul(toka, &endptr, 10);
> 21247:             if (toka == endptr) {
> ...

Oops, sorry for wrongly pointing the finger.

> Again, I know that's probably not an alibi, but that's not my code! :-P
> What I did is just move this from the body of vcpupin() to an helper
> function, and try to add as _less_ thing as I can to support a slightly
> improved syntax.

Right.

> That being said, if you think I should rewrite the parsing from scratch,
> I can think about it, just wanted to clarify my position. :-)

I really don't like the existing code here; feel free to do whatever
you think is best.

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 Jan 13 13:38:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlhKW-0005Ov-HF; Fri, 13 Jan 2012 13:38: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 1RlhKV-0005Oi-9K
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:38:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326461875!8154733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1606 invoked from network); 13 Jan 2012 13:37:56 -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 Jan 2012 13:37:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:37:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 13:37: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
	1RlhKK-0003Xc-V2; Fri, 13 Jan 2012 13:37:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlhKK-0003jk-U6;
	Fri, 13 Jan 2012 13:37:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.13232.920698.590180@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:37:52 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326451270.17210.310.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326451270.17210.310.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 03/10] libxl: move a lot more includes into
 libxl_internal.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 03/10] libxl: move a lot more includes into libxl_internal.h"):
> Could we put this first in libxl_internal.h and apply that constraint to
> that header instead?

In theory, yes.  But in practice people very much seem to like to add
new system headers to individual files.  And if you forget and add
them in the wrong place it can lead to subtle portability bugs which
you might not notice.

So I think this is a more obvious way to do it, even though it's an
extra #include line in each file.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:38:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlhKW-0005Ov-HF; Fri, 13 Jan 2012 13:38: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 1RlhKV-0005Oi-9K
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:38:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326461875!8154733!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1606 invoked from network); 13 Jan 2012 13:37:56 -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 Jan 2012 13:37:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:37:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 13:37: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
	1RlhKK-0003Xc-V2; Fri, 13 Jan 2012 13:37:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlhKK-0003jk-U6;
	Fri, 13 Jan 2012 13:37:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.13232.920698.590180@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:37:52 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326451270.17210.310.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326451270.17210.310.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 03/10] libxl: move a lot more includes into
 libxl_internal.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 03/10] libxl: move a lot more includes into libxl_internal.h"):
> Could we put this first in libxl_internal.h and apply that constraint to
> that header instead?

In theory, yes.  But in practice people very much seem to like to add
new system headers to individual files.  And if you forget and add
them in the wrong place it can lead to subtle portability bugs which
you might not notice.

So I think this is a more obvious way to do it, even though it's an
extra #include line in each file.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlhLs-0005UU-0d; Fri, 13 Jan 2012 13:39: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 1RlhLq-0005U0-8s
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:39:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326461959!8832303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16757 invoked from network); 13 Jan 2012 13:39:20 -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 Jan 2012 13:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:39: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, 13 Jan 2012 13:39:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 13:39:18 +0000
In-Reply-To: <20240.13232.920698.590180@mariner.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326451270.17210.310.camel@zakaz.uk.xensource.com>
	<20240.13232.920698.590180@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326461958.17210.350.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 03/10] libxl: move a lot more includes into
 libxl_internal.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 13:37 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 03/10] libxl: move a lot more includes into libxl_internal.h"):
> > Could we put this first in libxl_internal.h and apply that constraint to
> > that header instead?
> 
> In theory, yes.  But in practice people very much seem to like to add
> new system headers to individual files.  And if you forget and add
> them in the wrong place it can lead to subtle portability bugs which
> you might not notice.
> 
> So I think this is a more obvious way to do it, even though it's an
> extra #include line in each file.

Sure, that fine.

I suppose using -include (or whatever its real name is) on the compiler
command line is too skanky?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlhLs-0005UU-0d; Fri, 13 Jan 2012 13:39: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 1RlhLq-0005U0-8s
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:39:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326461959!8832303!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16757 invoked from network); 13 Jan 2012 13:39:20 -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 Jan 2012 13:39:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998585"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:39: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, 13 Jan 2012 13:39:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 13:39:18 +0000
In-Reply-To: <20240.13232.920698.590180@mariner.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326451270.17210.310.camel@zakaz.uk.xensource.com>
	<20240.13232.920698.590180@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326461958.17210.350.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 03/10] libxl: move a lot more includes into
 libxl_internal.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 13:37 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 03/10] libxl: move a lot more includes into libxl_internal.h"):
> > Could we put this first in libxl_internal.h and apply that constraint to
> > that header instead?
> 
> In theory, yes.  But in practice people very much seem to like to add
> new system headers to individual files.  And if you forget and add
> them in the wrong place it can lead to subtle portability bugs which
> you might not notice.
> 
> So I think this is a more obvious way to do it, even though it's an
> extra #include line in each file.

Sure, that fine.

I suppose using -include (or whatever its real name is) on the compiler
command line is too skanky?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:54:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13: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 1RlhZl-0005mi-EI; Fri, 13 Jan 2012 13:53: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 1RlhZj-0005ma-H1
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:53:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326462821!8808889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7037 invoked from network); 13 Jan 2012 13:53:41 -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 Jan 2012 13:53:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998901"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:53:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 13:53: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
	1RlhZc-0003dJ-C8; Fri, 13 Jan 2012 13:53:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlhZc-0006l7-B9;
	Fri, 13 Jan 2012 13:53:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.14180.333127.778981@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:53:40 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326451753.17210.317.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
	<1326451753.17210.317.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/10] libxl: New convenience macro
 CONTAINING_STRUCT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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/10] libxl: New convenience macro CONTAINING_STRUCT"):
> On Mon, 2012-01-09 at 17:34 +0000, Ian Jackson wrote:
> > Provide a convenient and type-safe wrapper which does the correct
> > dance to subtract offsetof.
...
> > + *    void GET_CONTAINING_STRUCT(outer_type *outer_var [NB:UPDATED],
> > + *                               some_type *inner_ptr,
> > + *                               member_name);
> > + *    outer_type *CONTAINING_STRUCT(outer_type,
> > + *                                  some_type *inner_ptr,
> > + *                                  member_name);
> > + * The semantics are that after:
> > + *    outer_type outer, *outer_var;
> > + *    member_type *inner_ptr = &outer->member_name;
> > + *    GET_CONTAINING_STRUCT(outer_var, &outer_ptr->member_name, member_name)
> > + * The following hold:
> > + *    CONTAINING_STRUCT(inner_ptr, outer_type, member_name) == outer_ptr
> 
> There is no outer_ptr in the givens, did you mean outer_var or something
> else?

I meant &outer.  Fixed.

> It's not entirely clear to me what the distinction between the GET_ and
> non GET_ variant is (just that one returns the thing and the other
> updates a variable?) and/or why we would need both.

That's exactly the difference.

> The common operation is to go from inner_ptr to outer_ptr I think
> and CONTAINING_STRUCT seems to fill that niche just fine.

The reason we need GET_CONTAINING_STRUCT is because we want to write
this:

    libxl__ev_devstate *ds;
    GET_CONTAINING_STRUCT(ds, watch, watch);

If we have to use CONTAINING_STRUCT, we have to write:

    libxl__ev_devstate *ds =
        CONTAINING_STRUCT(libxl__ev_devstate, watch, watch);

which is really unnecessarily verbose, because of the repetition of
libxl__ev_devstate.

> BTW, in Linux this is called container_of, which is maybe more familiar
> to people?

I'm not attached to the name.  If we pick Linux's name we should make
sure its semantics are identical, so the argument order should change.

Should it be called "container_of" or "CONTAINER_OF" ?

I still think we need something like the GET_... version, or some
other construct that allows us to avoid writing out the type name
twice.

Hmm, actually, in our version, you can write,

    libxl__ev_devstate *ds = CONTAINING_STRUCT(ds, watch, watch);

since we call typeof on the type argument.

So how about I change everything to use that pattern, rename it
CONTAINER_OF, and remove the GET_ version ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:54:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13: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 1RlhZl-0005mi-EI; Fri, 13 Jan 2012 13:53: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 1RlhZj-0005ma-H1
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:53:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326462821!8808889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7037 invoked from network); 13 Jan 2012 13:53:41 -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 Jan 2012 13:53:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998901"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:53:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 13:53: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
	1RlhZc-0003dJ-C8; Fri, 13 Jan 2012 13:53:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlhZc-0006l7-B9;
	Fri, 13 Jan 2012 13:53:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.14180.333127.778981@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:53:40 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326451753.17210.317.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
	<1326451753.17210.317.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/10] libxl: New convenience macro
 CONTAINING_STRUCT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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/10] libxl: New convenience macro CONTAINING_STRUCT"):
> On Mon, 2012-01-09 at 17:34 +0000, Ian Jackson wrote:
> > Provide a convenient and type-safe wrapper which does the correct
> > dance to subtract offsetof.
...
> > + *    void GET_CONTAINING_STRUCT(outer_type *outer_var [NB:UPDATED],
> > + *                               some_type *inner_ptr,
> > + *                               member_name);
> > + *    outer_type *CONTAINING_STRUCT(outer_type,
> > + *                                  some_type *inner_ptr,
> > + *                                  member_name);
> > + * The semantics are that after:
> > + *    outer_type outer, *outer_var;
> > + *    member_type *inner_ptr = &outer->member_name;
> > + *    GET_CONTAINING_STRUCT(outer_var, &outer_ptr->member_name, member_name)
> > + * The following hold:
> > + *    CONTAINING_STRUCT(inner_ptr, outer_type, member_name) == outer_ptr
> 
> There is no outer_ptr in the givens, did you mean outer_var or something
> else?

I meant &outer.  Fixed.

> It's not entirely clear to me what the distinction between the GET_ and
> non GET_ variant is (just that one returns the thing and the other
> updates a variable?) and/or why we would need both.

That's exactly the difference.

> The common operation is to go from inner_ptr to outer_ptr I think
> and CONTAINING_STRUCT seems to fill that niche just fine.

The reason we need GET_CONTAINING_STRUCT is because we want to write
this:

    libxl__ev_devstate *ds;
    GET_CONTAINING_STRUCT(ds, watch, watch);

If we have to use CONTAINING_STRUCT, we have to write:

    libxl__ev_devstate *ds =
        CONTAINING_STRUCT(libxl__ev_devstate, watch, watch);

which is really unnecessarily verbose, because of the repetition of
libxl__ev_devstate.

> BTW, in Linux this is called container_of, which is maybe more familiar
> to people?

I'm not attached to the name.  If we pick Linux's name we should make
sure its semantics are identical, so the argument order should change.

Should it be called "container_of" or "CONTAINER_OF" ?

I still think we need something like the GET_... version, or some
other construct that allows us to avoid writing out the type name
twice.

Hmm, actually, in our version, you can write,

    libxl__ev_devstate *ds = CONTAINING_STRUCT(ds, watch, watch);

since we call typeof on the type argument.

So how about I change everything to use that pattern, rename it
CONTAINER_OF, and remove the GET_ version ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:54:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13: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 1RlhaK-0005oJ-S8; Fri, 13 Jan 2012 13:54: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 1RlhaJ-0005o5-AN
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:54:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326462856!10333247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20865 invoked from network); 13 Jan 2012 13:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 13:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:54:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 13:54:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RlhaB-0003dU-Uf; Fri, 13 Jan 2012 13:54:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlhaB-0006lM-Tr;
	Fri, 13 Jan 2012 13:54:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.14215.892519.140700@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:54:15 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK52d4ySdPK5vdBW=Y3aqgOLTdO_Gu-gjb6E87WM60oskQ@mail.gmail.com>
References: <4F0703B1.2010207@amd.com>
	<20231.6979.676569.115840@mariner.uk.xensource.com>
	<CAPLaKK52d4ySdPK5vdBW=Y3aqgOLTdO_Gu-gjb6E87WM60oskQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] missing libxl patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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: missing libxl patches"):
> I'm going to break the mutex initialization to a separate function and
> submit this patch on it's own, since it doesn't have anything to do
> with hotplug scripts.

Excellent, yes, please do.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:54:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13: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 1RlhaK-0005oJ-S8; Fri, 13 Jan 2012 13:54: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 1RlhaJ-0005o5-AN
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:54:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326462856!10333247!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20865 invoked from network); 13 Jan 2012 13:54:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 13:54:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; 
   d="scan'208";a="9998911"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:54:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 13:54:16 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RlhaB-0003dU-Uf; Fri, 13 Jan 2012 13:54:15 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlhaB-0006lM-Tr;
	Fri, 13 Jan 2012 13:54:15 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.14215.892519.140700@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 13:54:15 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK52d4ySdPK5vdBW=Y3aqgOLTdO_Gu-gjb6E87WM60oskQ@mail.gmail.com>
References: <4F0703B1.2010207@amd.com>
	<20231.6979.676569.115840@mariner.uk.xensource.com>
	<CAPLaKK52d4ySdPK5vdBW=Y3aqgOLTdO_Gu-gjb6E87WM60oskQ@mail.gmail.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Christoph Egger <Christoph.Egger@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] missing libxl patches
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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: missing libxl patches"):
> I'm going to break the mutex initialization to a separate function and
> submit this patch on it's own, since it doesn't have anything to do
> with hotplug scripts.

Excellent, yes, please do.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:58:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13: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 1RlheK-00062h-HN; Fri, 13 Jan 2012 13:58:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlheI-00062R-P8
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:58:30 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326463103!9013774!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 3472 invoked from network); 13 Jan 2012 13:58:23 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-174.messagelabs.com with SMTP;
	13 Jan 2012 13:58:23 -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
	q0DDwKJe004378; Fri, 13 Jan 2012 13:58:20 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 q0DDwJ8X012241; 
	Fri, 13 Jan 2012 08:58:20 -0500
Message-ID: <4F103879.50709@tycho.nsa.gov>
Date: Fri, 13 Jan 2012 08:58:17 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF367020000780006C59D@nat28.tlf.novell.com>
In-Reply-To: <4F0FF367020000780006C59D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 01/13/2012 03:03 AM, Jan Beulich wrote:
>>>> On 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> +int set_global_virq_handler(struct domain *d, uint32_t virq)
>> +{
>> +    struct domain *old;
>> +
>> +    if (virq >= NR_VIRQS)
>> +        return -EINVAL;
>> +    if (!virq_is_global(virq))
>> +        return -EINVAL;
>> +
>> +    if (global_virq_handlers[virq] == d)
>> +        return 0;
>> +
>> +    if (unlikely(!get_domain(d)))
>> +        return -EINVAL;
>> +
>> +    spin_lock(&global_virq_handlers_lock);
>> +    old = global_virq_handlers[virq];
>> +    global_virq_handlers[virq] = d;
>> +    spin_unlock(&global_virq_handlers_lock);
>> +
>> +    if (old != NULL)
>> +        put_domain(old);
>> +
>> +    return 0;
>> +}
>> +
>> +static void clear_global_virq_handlers(struct domain *d)
>> +{
>> +    uint32_t virq;
>> +    int put_count = 0;
>> +
>> +    spin_lock(&global_virq_handlers_lock);
>> +
>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>> +        if (global_virq_handlers[virq] == d) {
>> +            global_virq_handlers[virq] = NULL;
>> +            put_count++;
>> +        }
>> +    }
>> +
>> +    spin_unlock(&global_virq_handlers_lock);
>> +
>> +    while (put_count) {
>> +        put_domain(d);
>> +        put_count--;
>> +    }
>> +}
> 
> Formatting in this entire hunk should be changed to match that of the
> rest of the file.
> 
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -64,6 +64,7 @@ struct xsm_operations {
>>      int (*domain_settime) (struct domain *d);
>>      int (*set_target) (struct domain *d, struct domain *e);
>>      int (*domctl) (struct domain *d, int cmd);
>> +    int (*set_virq_handler) (struct domain *d, int virq);
> 
> Here and further down, the 'int' still survived.
> 
> Jan
> 

Much of the existing code handling virqs uses int; should I also change
these instances to uint32_t?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 13:58:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 13: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 1RlheK-00062h-HN; Fri, 13 Jan 2012 13:58:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RlheI-00062R-P8
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 13:58:30 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326463103!9013774!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 3472 invoked from network); 13 Jan 2012 13:58:23 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-174.messagelabs.com with SMTP;
	13 Jan 2012 13:58:23 -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
	q0DDwKJe004378; Fri, 13 Jan 2012 13:58:20 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 q0DDwJ8X012241; 
	Fri, 13 Jan 2012 08:58:20 -0500
Message-ID: <4F103879.50709@tycho.nsa.gov>
Date: Fri, 13 Jan 2012 08:58:17 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF367020000780006C59D@nat28.tlf.novell.com>
In-Reply-To: <4F0FF367020000780006C59D@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 01/13/2012 03:03 AM, Jan Beulich wrote:
>>>> On 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> +int set_global_virq_handler(struct domain *d, uint32_t virq)
>> +{
>> +    struct domain *old;
>> +
>> +    if (virq >= NR_VIRQS)
>> +        return -EINVAL;
>> +    if (!virq_is_global(virq))
>> +        return -EINVAL;
>> +
>> +    if (global_virq_handlers[virq] == d)
>> +        return 0;
>> +
>> +    if (unlikely(!get_domain(d)))
>> +        return -EINVAL;
>> +
>> +    spin_lock(&global_virq_handlers_lock);
>> +    old = global_virq_handlers[virq];
>> +    global_virq_handlers[virq] = d;
>> +    spin_unlock(&global_virq_handlers_lock);
>> +
>> +    if (old != NULL)
>> +        put_domain(old);
>> +
>> +    return 0;
>> +}
>> +
>> +static void clear_global_virq_handlers(struct domain *d)
>> +{
>> +    uint32_t virq;
>> +    int put_count = 0;
>> +
>> +    spin_lock(&global_virq_handlers_lock);
>> +
>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>> +        if (global_virq_handlers[virq] == d) {
>> +            global_virq_handlers[virq] = NULL;
>> +            put_count++;
>> +        }
>> +    }
>> +
>> +    spin_unlock(&global_virq_handlers_lock);
>> +
>> +    while (put_count) {
>> +        put_domain(d);
>> +        put_count--;
>> +    }
>> +}
> 
> Formatting in this entire hunk should be changed to match that of the
> rest of the file.
> 
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -64,6 +64,7 @@ struct xsm_operations {
>>      int (*domain_settime) (struct domain *d);
>>      int (*set_target) (struct domain *d, struct domain *e);
>>      int (*domctl) (struct domain *d, int cmd);
>> +    int (*set_virq_handler) (struct domain *d, int virq);
> 
> Here and further down, the 'int' still survived.
> 
> Jan
> 

Much of the existing code handling virqs uses int; should I also change
these instances to uint32_t?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 14:01:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 14: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 1RlhhH-0006G2-4I; Fri, 13 Jan 2012 14:01:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RlhhF-0006Ft-6g
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 14:01:33 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326463285!8511586!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21891 invoked from network); 13 Jan 2012 14:01:26 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	VA3EHSOBE010.bigfish.com) (216.32.180.30)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Jan 2012 14:01:26 -0000
Received: from mail137-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Fri, 13 Jan 2012 14:01:24 +0000
Received: from mail137-va3 (localhost [127.0.0.1])	by
	mail137-va3-R.bigfish.com (Postfix) with ESMTP id D9762480285;
	Fri, 13 Jan 2012 14:01:24 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1ahc1bh668h839h61h)
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 mail137-va3 (localhost.localdomain [127.0.0.1]) by mail137-va3
	(MessageSwitch) id 1326463284145247_24583;
	Fri, 13 Jan 2012 14:01:24 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.246])	by
	mail137-va3.bigfish.com (Postfix) with ESMTP id 1E02C40049;
	Fri, 13 Jan 2012 14:01:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id
	14.1.225.22; Fri, 13 Jan 2012 14:01:22 +0000
X-WSS-ID: 0LXQPM3-02-8W1-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 2F89AC8160;	Fri, 13 Jan 2012 08:01:14 -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;
	Fri, 13 Jan 2012 08:01:37 -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;
	Fri, 13 Jan 2012 08:01: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; Fri, 13 Jan 2012
	09:01:18 -0500
Message-ID: <4F10392C.2070007@amd.com>
Date: Fri, 13 Jan 2012 15:01:16 +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: Roger Pau Monne <roger.pau@entel.upc.edu>
References: <bb6b01995d64f7c2887b.1326460363@loki.upc.es>
In-Reply-To: <bb6b01995d64f7c2887b.1326460363@loki.upc.es>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/13/12 14:12, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne<roger.pau@entel.upc.edu>
> # Date 1326460029 -3600
> # Node ID bb6b01995d64f7c2887b7174536861b83ef04364
> # Parent  117ad4634ba11c10e45f3d86e6baff35d7d2691c
> 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>

Acked-by: Christoph Egger <Christoph.Egger@amd.com>

>
> diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Fri Jan 13 13:55:01 2012 +0100
> +++ b/tools/libxl/libxl.c	Fri Jan 13 14:07:09 2012 +0100
> @@ -41,7 +41,6 @@ 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;
>
>       if (version != LIBXL_VERSION)
>           return ERROR_VERSION;
> @@ -55,10 +54,10 @@ 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 (libxl__init_recursive_mutex(ctx,&ctx->lock)<  0) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
> +        return ERROR_FAIL;
> +    }
>
>       if ( stat(XENSTORE_PID_FILE,&stat_buf) != 0 ) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
> diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl_internal.c
> --- a/tools/libxl/libxl_internal.c	Fri Jan 13 13:55:01 2012 +0100
> +++ b/tools/libxl/libxl_internal.c	Fri Jan 13 14:07:09 2012 +0100
> @@ -304,6 +304,28 @@ _hidden int libxl__compare_macs(libxl_ma
>       return 0;
>   }
>
> +_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock)
> +{
> +    pthread_mutexattr_t attr;
> +
> +    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(lock,&attr) != 0) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +                         "Failed to init mutex\n");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
>   libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
>                                                                  uint32_t domid)
>   {
> diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Jan 13 13:55:01 2012 +0100
> +++ b/tools/libxl/libxl_internal.h	Fri Jan 13 14:07:09 2012 +0100
> @@ -606,6 +606,8 @@ _hidden int libxl__e820_alloc(libxl__gc
>   _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);
> +/* init a recursive mutex */
> +_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock);
>
>   #define STRINGIFY(x) #x
>   #define TOSTRING(x) STRINGIFY(x)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
---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 Fri Jan 13 14:01:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 14: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 1RlhhH-0006G2-4I; Fri, 13 Jan 2012 14:01:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RlhhF-0006Ft-6g
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 14:01:33 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326463285!8511586!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21891 invoked from network); 13 Jan 2012 14:01:26 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	VA3EHSOBE010.bigfish.com) (216.32.180.30)
	by server-8.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	13 Jan 2012 14:01:26 -0000
Received: from mail137-va3-R.bigfish.com (10.7.14.245) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Fri, 13 Jan 2012 14:01:24 +0000
Received: from mail137-va3 (localhost [127.0.0.1])	by
	mail137-va3-R.bigfish.com (Postfix) with ESMTP id D9762480285;
	Fri, 13 Jan 2012 14:01:24 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1ahc1bh668h839h61h)
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 mail137-va3 (localhost.localdomain [127.0.0.1]) by mail137-va3
	(MessageSwitch) id 1326463284145247_24583;
	Fri, 13 Jan 2012 14:01:24 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.246])	by
	mail137-va3.bigfish.com (Postfix) with ESMTP id 1E02C40049;
	Fri, 13 Jan 2012 14:01:24 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id
	14.1.225.22; Fri, 13 Jan 2012 14:01:22 +0000
X-WSS-ID: 0LXQPM3-02-8W1-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 2F89AC8160;	Fri, 13 Jan 2012 08:01:14 -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;
	Fri, 13 Jan 2012 08:01:37 -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;
	Fri, 13 Jan 2012 08:01: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; Fri, 13 Jan 2012
	09:01:18 -0500
Message-ID: <4F10392C.2070007@amd.com>
Date: Fri, 13 Jan 2012 15:01:16 +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: Roger Pau Monne <roger.pau@entel.upc.edu>
References: <bb6b01995d64f7c2887b.1326460363@loki.upc.es>
In-Reply-To: <bb6b01995d64f7c2887b.1326460363@loki.upc.es>
X-OriginatorOrg: amd.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/13/12 14:12, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne<roger.pau@entel.upc.edu>
> # Date 1326460029 -3600
> # Node ID bb6b01995d64f7c2887b7174536861b83ef04364
> # Parent  117ad4634ba11c10e45f3d86e6baff35d7d2691c
> 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>

Acked-by: Christoph Egger <Christoph.Egger@amd.com>

>
> diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Fri Jan 13 13:55:01 2012 +0100
> +++ b/tools/libxl/libxl.c	Fri Jan 13 14:07:09 2012 +0100
> @@ -41,7 +41,6 @@ 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;
>
>       if (version != LIBXL_VERSION)
>           return ERROR_VERSION;
> @@ -55,10 +54,10 @@ 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 (libxl__init_recursive_mutex(ctx,&ctx->lock)<  0) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
> +        return ERROR_FAIL;
> +    }
>
>       if ( stat(XENSTORE_PID_FILE,&stat_buf) != 0 ) {
>           LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
> diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl_internal.c
> --- a/tools/libxl/libxl_internal.c	Fri Jan 13 13:55:01 2012 +0100
> +++ b/tools/libxl/libxl_internal.c	Fri Jan 13 14:07:09 2012 +0100
> @@ -304,6 +304,28 @@ _hidden int libxl__compare_macs(libxl_ma
>       return 0;
>   }
>
> +_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock)
> +{
> +    pthread_mutexattr_t attr;
> +
> +    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(lock,&attr) != 0) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +                         "Failed to init mutex\n");
> +        return ERROR_FAIL;
> +    }
> +    return 0;
> +}
> +
>   libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
>                                                                  uint32_t domid)
>   {
> diff -r 117ad4634ba1 -r bb6b01995d64 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Fri Jan 13 13:55:01 2012 +0100
> +++ b/tools/libxl/libxl_internal.h	Fri Jan 13 14:07:09 2012 +0100
> @@ -606,6 +606,8 @@ _hidden int libxl__e820_alloc(libxl__gc
>   _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);
> +/* init a recursive mutex */
> +_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock);
>
>   #define STRINGIFY(x) #x
>   #define TOSTRING(x) STRINGIFY(x)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


-- 
---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 Fri Jan 13 14:06:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 14: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 1RlhmA-0006Rt-SA; Fri, 13 Jan 2012 14:06:38 +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 1Rlhm9-0006Rl-EJ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 14:06:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326463590!7036014!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 26835 invoked from network); 13 Jan 2012 14:06:30 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-216.messagelabs.com with SMTP;
	13 Jan 2012 14:06:30 -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
	q0DE6TkV024004; Fri, 13 Jan 2012 14:06:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0DE6SMr013076; 
	Fri, 13 Jan 2012 09:06:29 -0500
Message-ID: <4F103A62.3000403@tycho.nsa.gov>
Date: Fri, 13 Jan 2012 09:06:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
In-Reply-To: <4F0FF742020000780006C5CE@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/include/xen/xenbus_dev.h
>> +++ b/include/xen/xenbus_dev.h
>> @@ -38,4 +38,18 @@
>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>  
>> +#define IOCTL_XENBUS_ALLOC				\
>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>> +struct ioctl_xenbus_alloc {
>> +	/* IN */
>> +	/* The domain ID (must exist) for xenstore */
>> +	uint16_t dom;
>> +	uint16_t pad;
>> +	/* OUT */
>> +	/* The port allocated for xenbus communication */
>> +	uint32_t port;
>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>> +	uint32_t grant_ref;
>> +};
> 
> As said in my reply to the previous patch version - if the functionality
> differs, the number *and* name should be different from the legacy
> implementation's. Otherwise, how should compatible user space code
> be written?
> 
> Jan
> 

This implementation has the same functionality as the legacy ioctl,
although it has a different number and is performed on a different file,
so it is already impossible to make automatically compatible userspace
code. The structure name was changed to match other ioctl arguments, but
the contents should be the same as in the legacy ioctl. If changing what
file the ioctl is performed on justifies changing the ioctl name, then I
would prefer the simpler interface where the domain ID is passed in as the
ioctl parameter instead of a structure that only has one useful output.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 14:06:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 14: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 1RlhmA-0006Rt-SA; Fri, 13 Jan 2012 14:06:38 +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 1Rlhm9-0006Rl-EJ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 14:06:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326463590!7036014!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 26835 invoked from network); 13 Jan 2012 14:06:30 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-216.messagelabs.com with SMTP;
	13 Jan 2012 14:06:30 -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
	q0DE6TkV024004; Fri, 13 Jan 2012 14:06:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0DE6SMr013076; 
	Fri, 13 Jan 2012 09:06:29 -0500
Message-ID: <4F103A62.3000403@tycho.nsa.gov>
Date: Fri, 13 Jan 2012 09:06:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
In-Reply-To: <4F0FF742020000780006C5CE@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> --- a/include/xen/xenbus_dev.h
>> +++ b/include/xen/xenbus_dev.h
>> @@ -38,4 +38,18 @@
>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>  
>> +#define IOCTL_XENBUS_ALLOC				\
>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>> +struct ioctl_xenbus_alloc {
>> +	/* IN */
>> +	/* The domain ID (must exist) for xenstore */
>> +	uint16_t dom;
>> +	uint16_t pad;
>> +	/* OUT */
>> +	/* The port allocated for xenbus communication */
>> +	uint32_t port;
>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>> +	uint32_t grant_ref;
>> +};
> 
> As said in my reply to the previous patch version - if the functionality
> differs, the number *and* name should be different from the legacy
> implementation's. Otherwise, how should compatible user space code
> be written?
> 
> Jan
> 

This implementation has the same functionality as the legacy ioctl,
although it has a different number and is performed on a different file,
so it is already impossible to make automatically compatible userspace
code. The structure name was changed to match other ioctl arguments, but
the contents should be the same as in the legacy ioctl. If changing what
file the ioctl is performed on justifies changing the ioctl name, then I
would prefer the simpler interface where the domain ID is passed in as the
ioctl parameter instead of a structure that only has one useful output.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 14:46:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 14:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RliO1-0007m6-Ee; Fri, 13 Jan 2012 14:45:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RliNz-0007m1-RY
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 14:45:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326465936!8996832!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26153 invoked from network); 13 Jan 2012 14:45:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 14:45:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10002141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 14:45:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Jan 2012 14:45:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 13 Jan 2012 14:45:35 +0000
In-Reply-To: <1326213620-20756-2-git-send-email-david.vrabel@citrix.com>
References: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
	<1326213620-20756-2-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326465936.17210.361.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 1/2] ARM: support zImage format kernels 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 Tue, 2012-01-10 at 16:40 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Allow a zImage format kernel to be used for dom0.  zImages are (by
> default) hardcoded with the RAM location so adjust the RAM in the
> memory map to match the physical memory map (0x80000000).
> 
> Vmlinux ELF images are loaded using a hack to locate the RAM so the
> IPA is the same as the kernel's VA so the elf loader does the right
> thing.  If an ELF image is loaded the RAM will be located at
> 0xC0000000 (as before).
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

These both look good to me, at first I thought there was some code
duplication going on but I see now it is all code motion.

Please can someone add the necessary Local variables to the end of both
new files.

Ian.

> ---
>  xen/arch/arm/Makefile       |    1 +
>  xen/arch/arm/domain_build.c |   72 ++++--------------
>  xen/arch/arm/kernel.c       |  167 +++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/kernel.h       |   37 ++++++++++
>  4 files changed, 221 insertions(+), 56 deletions(-)
>  create mode 100644 xen/arch/arm/kernel.c
>  create mode 100644 xen/arch/arm/kernel.h
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 5a07ae7..9bc2fc8 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -7,6 +7,7 @@ obj-y += domain_build.o
>  obj-y += gic.o
>  obj-y += io.o
>  obj-y += irq.o
> +obj-y += kernel.o
>  obj-y += mm.o
>  obj-y += p2m.o
>  obj-y += guestcopy.o
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index f73df85..cbbc0b9 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -4,10 +4,10 @@
>  #include <xen/mm.h>
>  #include <xen/domain_page.h>
>  #include <xen/sched.h>
> -#include <xen/libelf.h>
>  #include <asm/irq.h>
> 
>  #include "gic.h"
> +#include "kernel.h"
> 
>  static unsigned int __initdata opt_dom0_max_vcpus;
>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> @@ -28,25 +28,6 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
> 
>  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);
> @@ -84,21 +65,14 @@ static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
>      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 kernel_info kinfo = {};
> +    int rc;
> 
>      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);
> @@ -106,31 +80,22 @@ int construct_dom0(struct domain *d)
> 
>      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");
> +    /* 128M at 2G physical */
> +    /* TODO size and location from DT. */
> +    kinfo.ram_start = 0x80000000;
> +    kinfo.ram_end   = 0x88000000;
> 
> -    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
> +    rc = kernel_prepare(&kinfo);
> +    if (rc < 0)
> +        return rc;
> 
>      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("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
> +    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
> 
>      printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
>      map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
> @@ -161,20 +126,15 @@ int construct_dom0(struct domain *d)
>      /* 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);
> +    kernel_load(&kinfo);
> 
> -    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
> +    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
> 
>      clear_bit(_VPF_down, &v->pause_flags);
> 
>      memset(regs, 0, sizeof(*regs));
> 
> -    regs->pc = (uint32_t)parms.virt_entry;
> +    regs->pc = (uint32_t)kinfo.entry;
> 
>      regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
> 
> @@ -191,7 +151,7 @@ int construct_dom0(struct domain *d)
> 
>      regs->r0 = 0; /* SBZ */
>      regs->r1 = 2272; /* Machine NR: Versatile Express */
> -    regs->r2 = 0xc0000100; /* ATAGS */
> +    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
> 
>      WRITE_CP32(SCTLR_BASE, SCTLR);
> 
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> new file mode 100644
> index 0000000..5fb2ba0
> --- /dev/null
> +++ b/xen/arch/arm/kernel.c
> @@ -0,0 +1,167 @@
> +/*
> + * Kernel image loading.
> + *
> + * Copyright (C) 2011 Citrix Systems, Inc.
> + */
> +#include <xen/config.h>
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/mm.h>
> +#include <xen/domain_page.h>
> +#include <xen/sched.h>
> +
> +#include "kernel.h"
> +
> +/* Store kernel in first 8M of flash */
> +#define KERNEL_FLASH_ADDRESS 0x00000000UL
> +#define KERNEL_FLASH_SIZE    0x00800000UL
> +
> +#define ZIMAGE_MAGIC_OFFSET 0x24
> +#define ZIMAGE_START_OFFSET 0x28
> +#define ZIMAGE_END_OFFSET   0x2c
> +
> +#define ZIMAGE_MAGIC 0x016f2818
> +
> +static void kernel_zimage_load(struct kernel_info *info)
> +{
> +    paddr_t load_addr = info->zimage.load_addr;
> +    paddr_t len = info->zimage.len;
> +    paddr_t flash = KERNEL_FLASH_ADDRESS;
> +    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
> +    unsigned long offs;
> +
> +    printk("Loading %"PRIpaddr" byte zImage from flash %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
> +           len, flash, load_addr, load_addr + len);
> +    for ( offs = 0; offs < len; offs += PAGE_SIZE )
> +    {
> +        paddr_t ma = gvirt_to_maddr(load_addr + offs);
> +        void *dst = map_domain_page(ma>>PAGE_SHIFT);
> +
> +        if ( ( offs % (1<<20) ) == 0 )
> +            printk(".");
> +
> +        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
> +        memcpy(dst, src, PAGE_SIZE);
> +        clear_fixmap(FIXMAP_MISC);
> +
> +        unmap_domain_page(dst);
> +    }
> +    printk("]\n");
> +}
> +
> +/**
> + * Check the image is a zImage and return the load address and length
> + * (FIXME: including any appended DTB).
> + */
> +static int kernel_try_zimage_prepare(struct kernel_info *info)
> +{
> +    uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
> +    uint32_t start, end;
> +
> +    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
> +
> +    if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
> +        return -EINVAL;
> +
> +    start = zimage[ZIMAGE_START_OFFSET/4];
> +    end = zimage[ZIMAGE_END_OFFSET/4];
> +
> +    clear_fixmap(FIXMAP_MISC);
> +
> +    /* FIXME: get RAM location from appended DTB (if there is one)? */
> +
> +    /*
> +     * If start is zero, the zImage is position independent -- load it
> +     * at 32k from start of RAM.
> +     */
> +    if (start == 0)
> +        info->zimage.load_addr = info->ram_start + 0x8000;
> +    else
> +        info->zimage.load_addr = start;
> +    info->zimage.len = end - start;
> +
> +    info->entry = info->zimage.load_addr;
> +    info->load = kernel_zimage_load;
> +
> +    return 0;
> +}
> +
> +static void kernel_elf_load(struct kernel_info *info)
> +{
> +    printk("Loading ELF image into guest memory\n");
> +    info->elf.elf.dest = (void*)(unsigned long)info->elf.parms.virt_kstart;
> +    elf_load_binary(&info->elf.elf);
> +
> +    printk("Free temporary kernel buffer\n");
> +    free_xenheap_pages(info->kernel_img, info->kernel_order);
> +}
> +
> +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 int kernel_try_elf_prepare(struct kernel_info *info)
> +{
> +    int rc;
> +
> +    info->kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
> +    info->kernel_img = alloc_xenheap_pages(info->kernel_order, 0);
> +    if ( info->kernel_img == NULL )
> +        panic("Cannot allocate temporary buffer for kernel.\n");
> +
> +    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
> +
> +    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
> +        return rc;
> +#ifdef VERBOSE
> +    elf_set_verbose(&info->elf.elf);
> +#endif
> +    elf_parse_binary(&info->elf.elf);
> +    if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
> +        return rc;
> +
> +    /*
> +     * FIXME: can the ELF header be used to find the physical address
> +     * to load the image to?  Instead of making virt == phys by
> +     * relocating the guest's RAM.
> +     */
> +    info->ram_start = 0xc0000000;
> +    info->ram_end   = 0xc8000000;
> +
> +    info->entry = info->elf.parms.virt_entry;
> +    info->load = kernel_elf_load;
> +
> +    return 0;
> +}
> +
> +int kernel_prepare(struct kernel_info *info)
> +{
> +    int rc;
> +
> +    rc = kernel_try_zimage_prepare(info);
> +    if (rc < 0)
> +        rc = kernel_try_elf_prepare(info);
> +
> +    return rc;
> +}
> +
> +void kernel_load(struct kernel_info *info)
> +{
> +    info->load(info);
> +}
> diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
> new file mode 100644
> index 0000000..5caebe5
> --- /dev/null
> +++ b/xen/arch/arm/kernel.h
> @@ -0,0 +1,37 @@
> +/*
> + * Kernel image loading.
> + *
> + * Copyright (C) 2011 Citrix Systems, Inc.
> + */
> +#ifndef __ARCH_ARM_KERNEL_H__
> +#define __ARCH_ARM_KERNEL_H__
> +
> +#include <xen/libelf.h>
> +
> +struct kernel_info {
> +    paddr_t entry;
> +    paddr_t ram_start;
> +    paddr_t ram_end;
> +
> +    void *kernel_img;
> +    unsigned kernel_order;
> +
> +    union {
> +        struct {
> +            paddr_t load_addr;
> +            paddr_t len;
> +        } zimage;
> +
> +        struct {
> +            struct elf_binary elf;
> +            struct elf_dom_parms parms;
> +        } elf;
> +    };
> +
> +    void (*load)(struct kernel_info *info);
> +};
> +
> +int kernel_prepare(struct kernel_info *info);
> +void kernel_load(struct kernel_info *info);
> +
> +#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
> --
> 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 Jan 13 14:46:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 14:46:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RliO1-0007m6-Ee; Fri, 13 Jan 2012 14:45:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RliNz-0007m1-RY
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 14:45:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326465936!8996832!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26153 invoked from network); 13 Jan 2012 14:45:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 14:45:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10002141"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 14:45:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Jan 2012 14:45:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Fri, 13 Jan 2012 14:45:35 +0000
In-Reply-To: <1326213620-20756-2-git-send-email-david.vrabel@citrix.com>
References: <1326213620-20756-1-git-send-email-david.vrabel@citrix.com>
	<1326213620-20756-2-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326465936.17210.361.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 1/2] ARM: support zImage format kernels 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 Tue, 2012-01-10 at 16:40 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> Allow a zImage format kernel to be used for dom0.  zImages are (by
> default) hardcoded with the RAM location so adjust the RAM in the
> memory map to match the physical memory map (0x80000000).
> 
> Vmlinux ELF images are loaded using a hack to locate the RAM so the
> IPA is the same as the kernel's VA so the elf loader does the right
> thing.  If an ELF image is loaded the RAM will be located at
> 0xC0000000 (as before).
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

These both look good to me, at first I thought there was some code
duplication going on but I see now it is all code motion.

Please can someone add the necessary Local variables to the end of both
new files.

Ian.

> ---
>  xen/arch/arm/Makefile       |    1 +
>  xen/arch/arm/domain_build.c |   72 ++++--------------
>  xen/arch/arm/kernel.c       |  167 +++++++++++++++++++++++++++++++++++++++++++
>  xen/arch/arm/kernel.h       |   37 ++++++++++
>  4 files changed, 221 insertions(+), 56 deletions(-)
>  create mode 100644 xen/arch/arm/kernel.c
>  create mode 100644 xen/arch/arm/kernel.h
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 5a07ae7..9bc2fc8 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -7,6 +7,7 @@ obj-y += domain_build.o
>  obj-y += gic.o
>  obj-y += io.o
>  obj-y += irq.o
> +obj-y += kernel.o
>  obj-y += mm.o
>  obj-y += p2m.o
>  obj-y += guestcopy.o
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index f73df85..cbbc0b9 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -4,10 +4,10 @@
>  #include <xen/mm.h>
>  #include <xen/domain_page.h>
>  #include <xen/sched.h>
> -#include <xen/libelf.h>
>  #include <asm/irq.h>
> 
>  #include "gic.h"
> +#include "kernel.h"
> 
>  static unsigned int __initdata opt_dom0_max_vcpus;
>  integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
> @@ -28,25 +28,6 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
> 
>  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);
> @@ -84,21 +65,14 @@ static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
>      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 kernel_info kinfo = {};
> +    int rc;
> 
>      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);
> @@ -106,31 +80,22 @@ int construct_dom0(struct domain *d)
> 
>      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");
> +    /* 128M at 2G physical */
> +    /* TODO size and location from DT. */
> +    kinfo.ram_start = 0x80000000;
> +    kinfo.ram_end   = 0x88000000;
> 
> -    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
> +    rc = kernel_prepare(&kinfo);
> +    if (rc < 0)
> +        return rc;
> 
>      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("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
> +    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
> 
>      printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
>      map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
> @@ -161,20 +126,15 @@ int construct_dom0(struct domain *d)
>      /* 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);
> +    kernel_load(&kinfo);
> 
> -    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
> +    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
> 
>      clear_bit(_VPF_down, &v->pause_flags);
> 
>      memset(regs, 0, sizeof(*regs));
> 
> -    regs->pc = (uint32_t)parms.virt_entry;
> +    regs->pc = (uint32_t)kinfo.entry;
> 
>      regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
> 
> @@ -191,7 +151,7 @@ int construct_dom0(struct domain *d)
> 
>      regs->r0 = 0; /* SBZ */
>      regs->r1 = 2272; /* Machine NR: Versatile Express */
> -    regs->r2 = 0xc0000100; /* ATAGS */
> +    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
> 
>      WRITE_CP32(SCTLR_BASE, SCTLR);
> 
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> new file mode 100644
> index 0000000..5fb2ba0
> --- /dev/null
> +++ b/xen/arch/arm/kernel.c
> @@ -0,0 +1,167 @@
> +/*
> + * Kernel image loading.
> + *
> + * Copyright (C) 2011 Citrix Systems, Inc.
> + */
> +#include <xen/config.h>
> +#include <xen/errno.h>
> +#include <xen/init.h>
> +#include <xen/lib.h>
> +#include <xen/mm.h>
> +#include <xen/domain_page.h>
> +#include <xen/sched.h>
> +
> +#include "kernel.h"
> +
> +/* Store kernel in first 8M of flash */
> +#define KERNEL_FLASH_ADDRESS 0x00000000UL
> +#define KERNEL_FLASH_SIZE    0x00800000UL
> +
> +#define ZIMAGE_MAGIC_OFFSET 0x24
> +#define ZIMAGE_START_OFFSET 0x28
> +#define ZIMAGE_END_OFFSET   0x2c
> +
> +#define ZIMAGE_MAGIC 0x016f2818
> +
> +static void kernel_zimage_load(struct kernel_info *info)
> +{
> +    paddr_t load_addr = info->zimage.load_addr;
> +    paddr_t len = info->zimage.len;
> +    paddr_t flash = KERNEL_FLASH_ADDRESS;
> +    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
> +    unsigned long offs;
> +
> +    printk("Loading %"PRIpaddr" byte zImage from flash %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
> +           len, flash, load_addr, load_addr + len);
> +    for ( offs = 0; offs < len; offs += PAGE_SIZE )
> +    {
> +        paddr_t ma = gvirt_to_maddr(load_addr + offs);
> +        void *dst = map_domain_page(ma>>PAGE_SHIFT);
> +
> +        if ( ( offs % (1<<20) ) == 0 )
> +            printk(".");
> +
> +        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
> +        memcpy(dst, src, PAGE_SIZE);
> +        clear_fixmap(FIXMAP_MISC);
> +
> +        unmap_domain_page(dst);
> +    }
> +    printk("]\n");
> +}
> +
> +/**
> + * Check the image is a zImage and return the load address and length
> + * (FIXME: including any appended DTB).
> + */
> +static int kernel_try_zimage_prepare(struct kernel_info *info)
> +{
> +    uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
> +    uint32_t start, end;
> +
> +    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
> +
> +    if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
> +        return -EINVAL;
> +
> +    start = zimage[ZIMAGE_START_OFFSET/4];
> +    end = zimage[ZIMAGE_END_OFFSET/4];
> +
> +    clear_fixmap(FIXMAP_MISC);
> +
> +    /* FIXME: get RAM location from appended DTB (if there is one)? */
> +
> +    /*
> +     * If start is zero, the zImage is position independent -- load it
> +     * at 32k from start of RAM.
> +     */
> +    if (start == 0)
> +        info->zimage.load_addr = info->ram_start + 0x8000;
> +    else
> +        info->zimage.load_addr = start;
> +    info->zimage.len = end - start;
> +
> +    info->entry = info->zimage.load_addr;
> +    info->load = kernel_zimage_load;
> +
> +    return 0;
> +}
> +
> +static void kernel_elf_load(struct kernel_info *info)
> +{
> +    printk("Loading ELF image into guest memory\n");
> +    info->elf.elf.dest = (void*)(unsigned long)info->elf.parms.virt_kstart;
> +    elf_load_binary(&info->elf.elf);
> +
> +    printk("Free temporary kernel buffer\n");
> +    free_xenheap_pages(info->kernel_img, info->kernel_order);
> +}
> +
> +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 int kernel_try_elf_prepare(struct kernel_info *info)
> +{
> +    int rc;
> +
> +    info->kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
> +    info->kernel_img = alloc_xenheap_pages(info->kernel_order, 0);
> +    if ( info->kernel_img == NULL )
> +        panic("Cannot allocate temporary buffer for kernel.\n");
> +
> +    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
> +
> +    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
> +        return rc;
> +#ifdef VERBOSE
> +    elf_set_verbose(&info->elf.elf);
> +#endif
> +    elf_parse_binary(&info->elf.elf);
> +    if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
> +        return rc;
> +
> +    /*
> +     * FIXME: can the ELF header be used to find the physical address
> +     * to load the image to?  Instead of making virt == phys by
> +     * relocating the guest's RAM.
> +     */
> +    info->ram_start = 0xc0000000;
> +    info->ram_end   = 0xc8000000;
> +
> +    info->entry = info->elf.parms.virt_entry;
> +    info->load = kernel_elf_load;
> +
> +    return 0;
> +}
> +
> +int kernel_prepare(struct kernel_info *info)
> +{
> +    int rc;
> +
> +    rc = kernel_try_zimage_prepare(info);
> +    if (rc < 0)
> +        rc = kernel_try_elf_prepare(info);
> +
> +    return rc;
> +}
> +
> +void kernel_load(struct kernel_info *info)
> +{
> +    info->load(info);
> +}
> diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
> new file mode 100644
> index 0000000..5caebe5
> --- /dev/null
> +++ b/xen/arch/arm/kernel.h
> @@ -0,0 +1,37 @@
> +/*
> + * Kernel image loading.
> + *
> + * Copyright (C) 2011 Citrix Systems, Inc.
> + */
> +#ifndef __ARCH_ARM_KERNEL_H__
> +#define __ARCH_ARM_KERNEL_H__
> +
> +#include <xen/libelf.h>
> +
> +struct kernel_info {
> +    paddr_t entry;
> +    paddr_t ram_start;
> +    paddr_t ram_end;
> +
> +    void *kernel_img;
> +    unsigned kernel_order;
> +
> +    union {
> +        struct {
> +            paddr_t load_addr;
> +            paddr_t len;
> +        } zimage;
> +
> +        struct {
> +            struct elf_binary elf;
> +            struct elf_dom_parms parms;
> +        } elf;
> +    };
> +
> +    void (*load)(struct kernel_info *info);
> +};
> +
> +int kernel_prepare(struct kernel_info *info);
> +void kernel_load(struct kernel_info *info);
> +
> +#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
> --
> 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 Jan 13 14:50:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 14:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RliSY-0007tY-5d; Fri, 13 Jan 2012 14:50: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 1RliSW-0007tP-HU
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 14:50:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326466209!10857446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14114 invoked from network); 13 Jan 2012 14:50:18 -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 Jan 2012 14:50:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10002310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 14:50: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, 13 Jan 2012 14:50:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 14:50:08 +0000
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326466209.17210.364.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 v6 00/10] libxl: 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 Fri, 2012-01-06 at 20:34 +0000, Ian Jackson wrote:
> This series is the latest revision of my event handling API.  It
> includes changes in response to a number of comments made.  It also
> includes a few new consequential patches and unrelated
> fixes/improvements, as usual.
> 
> The most significant difference is the new "libxl__egc" type which is
> used instead of libxl__gc by event-generating functions.  This
> prevents accidental violation of the callback reentrancy rules.
> 
> I'm still working on this series.  At the moment I'm working on
> providing asynchronous calls for long-running operations; this
> requires more support machinery which is still not finalised.

Do we require that the async stuff is complete before we can commit the
event stuff? Obviously the former makes heavy use of the later so I
guess there will be "knock-back" effects as you implement it but the
series is becoming quite unwieldy (and long lived) so maybe it'd be
better to push part 1 and fix it up as necessary when you do the async
stuff?

> 
> Of the resulting patches in this series,
> 
> These should perhaps go in soon:
>  01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
>  03/10 libxl: move a lot more includes into libxl_internal.h
>  04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
>  05/10 libxl: Fix leaks on context init failure
>  09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
> 
> This one has now been tested and can go in IMO:
>  02/10 xenstore: New function xs_path_is_subpath

I agree that all the above can go in. I think I've acked them all.

> These are the meat:
>  07/10 libxl: New API for providing OS events to libxl
>  08/10 libxl: New event generation API
>  10/10 libxl: Permit multithreaded event waiting
> 
> And this one has become rendered obsolete.  If we are to retain the
> new libxl__egc structure, I will drop it.  Otherwise it may still be
> needed, and it's disruptive, which is why I haven't dropped it from my
> series yet:
>  06/10 DROP: libxl: rename libxl__free_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 Fri Jan 13 14:50:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 14:50:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RliSY-0007tY-5d; Fri, 13 Jan 2012 14:50: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 1RliSW-0007tP-HU
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 14:50:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326466209!10857446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14114 invoked from network); 13 Jan 2012 14:50:18 -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 Jan 2012 14:50:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10002310"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 14:50: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, 13 Jan 2012 14:50:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 14:50:08 +0000
In-Reply-To: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326466209.17210.364.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 v6 00/10] libxl: 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 Fri, 2012-01-06 at 20:34 +0000, Ian Jackson wrote:
> This series is the latest revision of my event handling API.  It
> includes changes in response to a number of comments made.  It also
> includes a few new consequential patches and unrelated
> fixes/improvements, as usual.
> 
> The most significant difference is the new "libxl__egc" type which is
> used instead of libxl__gc by event-generating functions.  This
> prevents accidental violation of the callback reentrancy rules.
> 
> I'm still working on this series.  At the moment I'm working on
> providing asynchronous calls for long-running operations; this
> requires more support machinery which is still not finalised.

Do we require that the async stuff is complete before we can commit the
event stuff? Obviously the former makes heavy use of the later so I
guess there will be "knock-back" effects as you implement it but the
series is becoming quite unwieldy (and long lived) so maybe it'd be
better to push part 1 and fix it up as necessary when you do the async
stuff?

> 
> Of the resulting patches in this series,
> 
> These should perhaps go in soon:
>  01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
>  03/10 libxl: move a lot more includes into libxl_internal.h
>  04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
>  05/10 libxl: Fix leaks on context init failure
>  09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
> 
> This one has now been tested and can go in IMO:
>  02/10 xenstore: New function xs_path_is_subpath

I agree that all the above can go in. I think I've acked them all.

> These are the meat:
>  07/10 libxl: New API for providing OS events to libxl
>  08/10 libxl: New event generation API
>  10/10 libxl: Permit multithreaded event waiting
> 
> And this one has become rendered obsolete.  If we are to retain the
> new libxl__egc structure, I will drop it.  Otherwise it may still be
> needed, and it's disruptive, which is why I haven't dropped it from my
> series yet:
>  06/10 DROP: libxl: rename libxl__free_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 Fri Jan 13 15:07:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RliiH-0008BW-Cu; Fri, 13 Jan 2012 15:06:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RliiF-0008Ax-Qa
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:06:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326467011!10725380!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19190 invoked from network); 13 Jan 2012 15:03:31 -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 Jan 2012 15:03:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10003012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:03:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 15:03: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
	1RlifC-00047X-Go; Fri, 13 Jan 2012 15:03:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlifC-0002Cz-Fp;
	Fri, 13 Jan 2012 15:03:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.18370.479047.159541@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:03:30 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326466209.17210.364.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326466209.17210.364.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 v6 00/10] libxl: 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 v6 00/10] libxl: event API"):
> Do we require that the async stuff is complete before we can commit the
> event stuff? Obviously the former makes heavy use of the later so I
> guess there will be "knock-back" effects as you implement it but the
> series is becoming quite unwieldy (and long lived) so maybe it'd be
> better to push part 1 and fix it up as necessary when you do the async
> stuff?

That's probably a good idea.  I'm refreshing it and testing it.

> > These should perhaps go in soon:
> >  01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
> >  03/10 libxl: move a lot more includes into libxl_internal.h
> >  04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
> >  05/10 libxl: Fix leaks on context init failure
> >  09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
> > 
> > This one has now been tested and can go in IMO:
> >  02/10 xenstore: New function xs_path_is_subpath
> 
> I agree that all the above can go in. I think I've acked them all.

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 Jan 13 15:07:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RliiH-0008BW-Cu; Fri, 13 Jan 2012 15:06:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RliiF-0008Ax-Qa
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:06:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326467011!10725380!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19190 invoked from network); 13 Jan 2012 15:03:31 -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 Jan 2012 15:03:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10003012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:03:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 15:03: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
	1RlifC-00047X-Go; Fri, 13 Jan 2012 15:03:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlifC-0002Cz-Fp;
	Fri, 13 Jan 2012 15:03:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.18370.479047.159541@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:03:30 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326466209.17210.364.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326466209.17210.364.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 v6 00/10] libxl: 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 v6 00/10] libxl: event API"):
> Do we require that the async stuff is complete before we can commit the
> event stuff? Obviously the former makes heavy use of the later so I
> guess there will be "knock-back" effects as you implement it but the
> series is becoming quite unwieldy (and long lived) so maybe it'd be
> better to push part 1 and fix it up as necessary when you do the async
> stuff?

That's probably a good idea.  I'm refreshing it and testing it.

> > These should perhaps go in soon:
> >  01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
> >  03/10 libxl: move a lot more includes into libxl_internal.h
> >  04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
> >  05/10 libxl: Fix leaks on context init failure
> >  09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
> > 
> > This one has now been tested and can go in IMO:
> >  02/10 xenstore: New function xs_path_is_subpath
> 
> I agree that all the above can go in. I think I've acked them all.

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 Jan 13 15:07:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rliiz-0008GS-RU; Fri, 13 Jan 2012 15:07: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 1Rliix-0008G7-RN
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:07:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326467220!52721880!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22538 invoked from network); 13 Jan 2012 15:07: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;
	13 Jan 2012 15:07:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10003379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:06: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;
	Fri, 13 Jan 2012 15:06:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 15:06:41 +0000
In-Reply-To: <20240.14180.333127.778981@mariner.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
	<1326451753.17210.317.camel@zakaz.uk.xensource.com>
	<20240.14180.333127.778981@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326467201.17210.373.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/10] libxl: New convenience macro
 CONTAINING_STRUCT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 13:53 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 12/10] libxl: New convenience macro CONTAINING_STRUCT"):
> > On Mon, 2012-01-09 at 17:34 +0000, Ian Jackson wrote:
> > > Provide a convenient and type-safe wrapper which does the correct
> > > dance to subtract offsetof.
> ...
> > > + *    void GET_CONTAINING_STRUCT(outer_type *outer_var [NB:UPDATED],
> > > + *                               some_type *inner_ptr,
> > > + *                               member_name);
> > > + *    outer_type *CONTAINING_STRUCT(outer_type,
> > > + *                                  some_type *inner_ptr,
> > > + *                                  member_name);
> > > + * The semantics are that after:
> > > + *    outer_type outer, *outer_var;
> > > + *    member_type *inner_ptr = &outer->member_name;
> > > + *    GET_CONTAINING_STRUCT(outer_var, &outer_ptr->member_name, member_name)
> > > + * The following hold:
> > > + *    CONTAINING_STRUCT(inner_ptr, outer_type, member_name) == outer_ptr
> > 
> > There is no outer_ptr in the givens, did you mean outer_var or something
> > else?
> 
> I meant &outer.  Fixed.
> 
> > It's not entirely clear to me what the distinction between the GET_ and
> > non GET_ variant is (just that one returns the thing and the other
> > updates a variable?) and/or why we would need both.
> 
> That's exactly the difference.
> 
> > The common operation is to go from inner_ptr to outer_ptr I think
> > and CONTAINING_STRUCT seems to fill that niche just fine.
> 
> The reason we need GET_CONTAINING_STRUCT is because we want to write
> this:
> 
>     libxl__ev_devstate *ds;
>     GET_CONTAINING_STRUCT(ds, watch, watch);
> 
> If we have to use CONTAINING_STRUCT, we have to write:
> 
>     libxl__ev_devstate *ds =
>         CONTAINING_STRUCT(libxl__ev_devstate, watch, watch);
> 
> which is really unnecessarily verbose, because of the repetition of
> libxl__ev_devstate.
> 
> > BTW, in Linux this is called container_of, which is maybe more familiar
> > to people?
> 
> I'm not attached to the name.  If we pick Linux's name we should make
> sure its semantics are identical, so the argument order should change.
> 
> Should it be called "container_of" or "CONTAINER_OF" ?
> 
> I still think we need something like the GET_... version, or some
> other construct that allows us to avoid writing out the type name
> twice.
> 
> Hmm, actually, in our version, you can write,
> 
>     libxl__ev_devstate *ds = CONTAINING_STRUCT(ds, watch, watch);
> 
> since we call typeof on the type argument.
> 
> So how about I change everything to use that pattern, rename it
> CONTAINER_OF, and remove the GET_ version ?

Sounds good.

RE "container_of" vs. "CONTAINER_OF" -- Linux uses lowercase but that is
against the usual style of macros being caps. I don't mind which.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:07:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:07:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rliiz-0008GS-RU; Fri, 13 Jan 2012 15:07: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 1Rliix-0008G7-RN
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:07:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326467220!52721880!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22538 invoked from network); 13 Jan 2012 15:07: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;
	13 Jan 2012 15:07:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10003379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:06: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;
	Fri, 13 Jan 2012 15:06:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 15:06:41 +0000
In-Reply-To: <20240.14180.333127.778981@mariner.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326130477-18085-3-git-send-email-ian.jackson@eu.citrix.com>
	<1326451753.17210.317.camel@zakaz.uk.xensource.com>
	<20240.14180.333127.778981@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326467201.17210.373.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/10] libxl: New convenience macro
 CONTAINING_STRUCT
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 13:53 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 12/10] libxl: New convenience macro CONTAINING_STRUCT"):
> > On Mon, 2012-01-09 at 17:34 +0000, Ian Jackson wrote:
> > > Provide a convenient and type-safe wrapper which does the correct
> > > dance to subtract offsetof.
> ...
> > > + *    void GET_CONTAINING_STRUCT(outer_type *outer_var [NB:UPDATED],
> > > + *                               some_type *inner_ptr,
> > > + *                               member_name);
> > > + *    outer_type *CONTAINING_STRUCT(outer_type,
> > > + *                                  some_type *inner_ptr,
> > > + *                                  member_name);
> > > + * The semantics are that after:
> > > + *    outer_type outer, *outer_var;
> > > + *    member_type *inner_ptr = &outer->member_name;
> > > + *    GET_CONTAINING_STRUCT(outer_var, &outer_ptr->member_name, member_name)
> > > + * The following hold:
> > > + *    CONTAINING_STRUCT(inner_ptr, outer_type, member_name) == outer_ptr
> > 
> > There is no outer_ptr in the givens, did you mean outer_var or something
> > else?
> 
> I meant &outer.  Fixed.
> 
> > It's not entirely clear to me what the distinction between the GET_ and
> > non GET_ variant is (just that one returns the thing and the other
> > updates a variable?) and/or why we would need both.
> 
> That's exactly the difference.
> 
> > The common operation is to go from inner_ptr to outer_ptr I think
> > and CONTAINING_STRUCT seems to fill that niche just fine.
> 
> The reason we need GET_CONTAINING_STRUCT is because we want to write
> this:
> 
>     libxl__ev_devstate *ds;
>     GET_CONTAINING_STRUCT(ds, watch, watch);
> 
> If we have to use CONTAINING_STRUCT, we have to write:
> 
>     libxl__ev_devstate *ds =
>         CONTAINING_STRUCT(libxl__ev_devstate, watch, watch);
> 
> which is really unnecessarily verbose, because of the repetition of
> libxl__ev_devstate.
> 
> > BTW, in Linux this is called container_of, which is maybe more familiar
> > to people?
> 
> I'm not attached to the name.  If we pick Linux's name we should make
> sure its semantics are identical, so the argument order should change.
> 
> Should it be called "container_of" or "CONTAINER_OF" ?
> 
> I still think we need something like the GET_... version, or some
> other construct that allows us to avoid writing out the type name
> twice.
> 
> Hmm, actually, in our version, you can write,
> 
>     libxl__ev_devstate *ds = CONTAINING_STRUCT(ds, watch, watch);
> 
> since we call typeof on the type argument.
> 
> So how about I change everything to use that pattern, rename it
> CONTAINER_OF, and remove the GET_ version ?

Sounds good.

RE "container_of" vs. "CONTAINER_OF" -- Linux uses lowercase but that is
against the usual style of macros being caps. I don't mind which.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:07:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlijB-0008IB-8m; Fri, 13 Jan 2012 15:07:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rlij9-0008HB-Tl
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:07:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326467249!9030596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32337 invoked from network); 13 Jan 2012 15:07:30 -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;
	13 Jan 2012 15:07:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10003406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:07:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Jan 2012 15:07:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 15:07:25 +0000
In-Reply-To: <1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326467245.17210.374.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 07/10] 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, 2012-01-06 at 20:35 +0000, 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>

I think I've mostly looked at this already so I only glanced through it
this time.

> [...]

> +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).

I think you were going to move the comments (sorry).

> [...]
> @@ -733,6 +950,49 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
> 
> 
>  /*
> + * Calling context and GC for event-generating functions:
> + *
> + * These are for use by parts of libxl which directly or indirectly
> + * call libxl__event_occurred.  These contain a gc but also a list of
> + * deferred events.
> + *
> + * Most code in libxlshould not need to initialise their own egc.

Missing space.         ^

Will any function even need to initialise their own egc and/or is it
normally provided by infrastructure code? Otherwise when should a
function initialise their own egc? Is it simply that you know if you
need to initialise one because you are calling a function which takes
one?

> + * Even functions which generate specific kinds of events don't need
> + * to - rather, they will be passed an egc into their own callback
> + * function and should just use the one they're given.
> + *
> + * A handy idiom for functions taking an egc is:
> + *     libxl__gc *gc = &egc->gc;

You've provided lots of handy macros for other things like this, perhaps
EGC by comparison with CTX. Using GC seems better on the face of it but
since it will only work in a context with an egc that is actually
confusing.

> + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> + * within libxl, because libxl__egc_cleanup may call back into the
> + * application.  This should be documented near the function
> + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.

Can we also enforce/check this with a flag in the ctx? I guess not since
multiple threads might call into libxl with the same ctx and each may
legitimately setup an egc.?

> + *
> + * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
> + * with the ctx *unlocked*.  So the right pattern has the EGC_...
> + * macro calls on the outside of the CTX_... ones.
> + */
> +
> +/* egc initialisation and destruction: */
> +
> +#define LIBXL_INIT_EGC(egc,ctx) do{             \
> +        LIBXL_INIT_GC((egc).gc,ctx);            \
> +        /* list of occurred events tbd */       \
> +    } while(0)
> +
> +_hidden void libxl__egc_cleanup(libxl__egc *egc);
> +
> +/* convenience macros: */
> +
> +#define EGC_INIT(ctx)                       \
> +    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
> +    libxl__gc *gc = &egc->gc
> +
> +#define EGC_FREE           libxl__egc_cleanup(egc)
> +
> +
> +/*
>   * Convenience macros.
>   */
> 
> --
> 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 Jan 13 15:07:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlijB-0008IB-8m; Fri, 13 Jan 2012 15:07:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rlij9-0008HB-Tl
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:07:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326467249!9030596!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32337 invoked from network); 13 Jan 2012 15:07:30 -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;
	13 Jan 2012 15:07:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10003406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:07:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Jan 2012 15:07:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 15:07:25 +0000
In-Reply-To: <1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326467245.17210.374.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 07/10] 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, 2012-01-06 at 20:35 +0000, 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>

I think I've mostly looked at this already so I only glanced through it
this time.

> [...]

> +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).

I think you were going to move the comments (sorry).

> [...]
> @@ -733,6 +950,49 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
> 
> 
>  /*
> + * Calling context and GC for event-generating functions:
> + *
> + * These are for use by parts of libxl which directly or indirectly
> + * call libxl__event_occurred.  These contain a gc but also a list of
> + * deferred events.
> + *
> + * Most code in libxlshould not need to initialise their own egc.

Missing space.         ^

Will any function even need to initialise their own egc and/or is it
normally provided by infrastructure code? Otherwise when should a
function initialise their own egc? Is it simply that you know if you
need to initialise one because you are calling a function which takes
one?

> + * Even functions which generate specific kinds of events don't need
> + * to - rather, they will be passed an egc into their own callback
> + * function and should just use the one they're given.
> + *
> + * A handy idiom for functions taking an egc is:
> + *     libxl__gc *gc = &egc->gc;

You've provided lots of handy macros for other things like this, perhaps
EGC by comparison with CTX. Using GC seems better on the face of it but
since it will only work in a context with an egc that is actually
confusing.

> + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> + * within libxl, because libxl__egc_cleanup may call back into the
> + * application.  This should be documented near the function
> + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.

Can we also enforce/check this with a flag in the ctx? I guess not since
multiple threads might call into libxl with the same ctx and each may
legitimately setup an egc.?

> + *
> + * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
> + * with the ctx *unlocked*.  So the right pattern has the EGC_...
> + * macro calls on the outside of the CTX_... ones.
> + */
> +
> +/* egc initialisation and destruction: */
> +
> +#define LIBXL_INIT_EGC(egc,ctx) do{             \
> +        LIBXL_INIT_GC((egc).gc,ctx);            \
> +        /* list of occurred events tbd */       \
> +    } while(0)
> +
> +_hidden void libxl__egc_cleanup(libxl__egc *egc);
> +
> +/* convenience macros: */
> +
> +#define EGC_INIT(ctx)                       \
> +    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
> +    libxl__gc *gc = &egc->gc
> +
> +#define EGC_FREE           libxl__egc_cleanup(egc)
> +
> +
> +/*
>   * Convenience macros.
>   */
> 
> --
> 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 Jan 13 15:13:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RlioX-0000Sw-A4; Fri, 13 Jan 2012 15:13: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 1RlioV-0000Sc-KF
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:13:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326467580!8731133!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5Mzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30673 invoked from network); 13 Jan 2012 15:13:00 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-21.messagelabs.com with SMTP;
	13 Jan 2012 15:13:00 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1CDDC76C073;
	Fri, 13 Jan 2012 07:12:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LMuFvqBKq49BJT80L0jiqBanNQ0/mFIoqq4Fy36FN+0i
	2In8Ih1XcwpFsqvFRL30wZxv0jcaR2ruMocu5sb9pIibeYeRF9Lp0wzXJtq8TbV0
	BQAxxrb7mspIcn7x7RLpC5JeAtCmpJKhgggX2HrE00ALVlCZzQqGZzCEtWKeU4Q=
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=Hn9uYiia8Zsg3tfk4sljvlBEDMM=; b=gn9YCqc+
	C4KVnDDu5820SvqGeKdCl0wym0d2STTAUZwTkEx4kSd47M+MrBrCl1uBqtw/9ttY
	15K5uhfyYXy7THqAYzm7VbyaGkujcQDDMFrQyJ0W10Jrx7kmw3t+5ieRGXE/+4Hh
	t2/6IEXO+Wbm/T9NCLAWvaXK4rl1mUoazyE=
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 A865E76C069; 
	Fri, 13 Jan 2012 07:12:58 -0800 (PST)
Received: from 75.119.234.254 (proxying for 75.119.234.254)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Jan 2012 07:14:12 -0800
Message-ID: <873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120113095022.GA18130@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
Date: Fri, 13 Jan 2012 07:14:12 -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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
> A few comments:
>
>> -static int mem_event_disable(struct mem_event_domain *med)
>> +static int mem_event_ring_available(struct mem_event_domain *med)
>>  {
>> -    unmap_domain_page(med->ring_page);
>> -    med->ring_page = NULL;
>> +    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
>> +    avail_req -= med->target_producers;
>> +    avail_req -= med->foreign_producers;
>>
>> -    unmap_domain_page(med->shared_page);
>> -    med->shared_page = NULL;
>> +    BUG_ON(avail_req < 0);
>> +
>> +    return avail_req;
>> +}
>> +
>
> mem_event_ring_available() should return unsigned since the values it
> provides can only be positive. The function itself enforces this.

Yup.
>
>> -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 */
>> -    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;
>> +    /* We allow no ring in this unique case, because it won't affect
>> +     * correctness of the guest execution at this point.  If this is
>> the only
>> +     * page that happens to be paged-out, we'll be okay..  but it's
>> likely the
>> +     * guest will crash shortly anyways. */
>> +    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
>> +    if ( rc < 0 )
>> +        return rc;
>>
>> -        mem_event_put_request(d, &d->mem_event->paging, &req);
>> -    }
>> +    /* Send release notification to pager */
>> +    memset(&req, 0, sizeof(req));
>> +    req.type = MEM_EVENT_TYPE_PAGING;
>> +    req.gfn = gfn;
>> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
>> +
>> +    mem_event_put_request(d, &d->mem_event->paging, &req);
>> +    return 0;
>>  }
>
> p2m_mem_paging_drop_page() should remain void because the caller has
> already done its work, making it not restartable. Also it is only called
> when a gfn is in paging state, which I'm sure can not happen without a
> ring.

Well, the rationale is that returning an error code can only help, should
new error conditions arise. Keep in mind that the pager and the ring can
disappear at any time, so ENOSYS can still happen.
>
> And quilt says:
> Warning: trailing whitespace in lines 167,254 of
> xen/arch/x86/mm/mem_event.c
> Warning: trailing whitespace in line 168 of xen/common/memory.c
> Warning: trailing whitespace in line 1127 of xen/arch/x86/mm/p2m.c
>
quilt ... the good times.

I'll refresh and add your signed-off-by to cover the portions of the work
that originate from your end, is that ok?

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 Fri Jan 13 15:13:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RlioX-0000Sw-A4; Fri, 13 Jan 2012 15:13: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 1RlioV-0000Sc-KF
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:13:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326467580!8731133!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5Mzc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30673 invoked from network); 13 Jan 2012 15:13:00 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-15.tower-21.messagelabs.com with SMTP;
	13 Jan 2012 15:13:00 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 1CDDC76C073;
	Fri, 13 Jan 2012 07:12:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=LMuFvqBKq49BJT80L0jiqBanNQ0/mFIoqq4Fy36FN+0i
	2In8Ih1XcwpFsqvFRL30wZxv0jcaR2ruMocu5sb9pIibeYeRF9Lp0wzXJtq8TbV0
	BQAxxrb7mspIcn7x7RLpC5JeAtCmpJKhgggX2HrE00ALVlCZzQqGZzCEtWKeU4Q=
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=Hn9uYiia8Zsg3tfk4sljvlBEDMM=; b=gn9YCqc+
	C4KVnDDu5820SvqGeKdCl0wym0d2STTAUZwTkEx4kSd47M+MrBrCl1uBqtw/9ttY
	15K5uhfyYXy7THqAYzm7VbyaGkujcQDDMFrQyJ0W10Jrx7kmw3t+5ieRGXE/+4Hh
	t2/6IEXO+Wbm/T9NCLAWvaXK4rl1mUoazyE=
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 A865E76C069; 
	Fri, 13 Jan 2012 07:12:58 -0800 (PST)
Received: from 75.119.234.254 (proxying for 75.119.234.254)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Jan 2012 07:14:12 -0800
Message-ID: <873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120113095022.GA18130@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
Date: Fri, 13 Jan 2012 07:14:12 -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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
> A few comments:
>
>> -static int mem_event_disable(struct mem_event_domain *med)
>> +static int mem_event_ring_available(struct mem_event_domain *med)
>>  {
>> -    unmap_domain_page(med->ring_page);
>> -    med->ring_page = NULL;
>> +    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
>> +    avail_req -= med->target_producers;
>> +    avail_req -= med->foreign_producers;
>>
>> -    unmap_domain_page(med->shared_page);
>> -    med->shared_page = NULL;
>> +    BUG_ON(avail_req < 0);
>> +
>> +    return avail_req;
>> +}
>> +
>
> mem_event_ring_available() should return unsigned since the values it
> provides can only be positive. The function itself enforces this.

Yup.
>
>> -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 */
>> -    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;
>> +    /* We allow no ring in this unique case, because it won't affect
>> +     * correctness of the guest execution at this point.  If this is
>> the only
>> +     * page that happens to be paged-out, we'll be okay..  but it's
>> likely the
>> +     * guest will crash shortly anyways. */
>> +    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
>> +    if ( rc < 0 )
>> +        return rc;
>>
>> -        mem_event_put_request(d, &d->mem_event->paging, &req);
>> -    }
>> +    /* Send release notification to pager */
>> +    memset(&req, 0, sizeof(req));
>> +    req.type = MEM_EVENT_TYPE_PAGING;
>> +    req.gfn = gfn;
>> +    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
>> +
>> +    mem_event_put_request(d, &d->mem_event->paging, &req);
>> +    return 0;
>>  }
>
> p2m_mem_paging_drop_page() should remain void because the caller has
> already done its work, making it not restartable. Also it is only called
> when a gfn is in paging state, which I'm sure can not happen without a
> ring.

Well, the rationale is that returning an error code can only help, should
new error conditions arise. Keep in mind that the pager and the ring can
disappear at any time, so ENOSYS can still happen.
>
> And quilt says:
> Warning: trailing whitespace in lines 167,254 of
> xen/arch/x86/mm/mem_event.c
> Warning: trailing whitespace in line 168 of xen/common/memory.c
> Warning: trailing whitespace in line 1127 of xen/arch/x86/mm/p2m.c
>
quilt ... the good times.

I'll refresh and add your signed-off-by to cover the portions of the work
that originate from your end, is that ok?

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 Fri Jan 13 15:22:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RlixQ-0000iU-Cf; Fri, 13 Jan 2012 15:22:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlixO-0000iN-7G
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:22:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326468091!50138078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8979 invoked from network); 13 Jan 2012 15:21:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 15:21:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10004167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:22: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, 13 Jan 2012 15:22:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 15:22:16 +0000
In-Reply-To: <1325882107-5794-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-9-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326468136.17210.381.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 08/10] 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, 2012-01-06 at 20:35 +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>

I think I've seen most of this before too so again I only skimmed it.
Nothing much jumped out but I must admit I'm suffering from Friday
afternoon review fatigue...


> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 78a1cc6..6728479 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"),
> @@ -394,3 +389,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
>      ("extratime", integer),
>      ("weight", 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")

This doesn't turn into libxl_libxl_ev_user in the code, does it?

No, I checked, It's right, Good ;-)

> +
> +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}"),

I've got a pending patch which does away with comments in the IDL syntax
in favour of source level comments (e.g. "# for use by...."). I don't
think anyone reads the comments in generated code in preference to the
comments in the IDL source...

Either we race here or you can just go straight for the source level
comments.

> +    ("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 8270f34..a18c6b2 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
[...]
> +        case LIBXL_EVENT_TYPE_DISK_EJECT:
> +            /* XXX what is this for? */

This is signalled by qemu when the guest opens the CD-ROM drive.

(not sure if this is your comment or an existing one which got
reindented.)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:22:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RlixQ-0000iU-Cf; Fri, 13 Jan 2012 15:22:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlixO-0000iN-7G
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:22:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326468091!50138078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8979 invoked from network); 13 Jan 2012 15:21:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 15:21:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10004167"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:22: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, 13 Jan 2012 15:22:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 15:22:16 +0000
In-Reply-To: <1325882107-5794-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-9-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326468136.17210.381.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 08/10] 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, 2012-01-06 at 20:35 +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>

I think I've seen most of this before too so again I only skimmed it.
Nothing much jumped out but I must admit I'm suffering from Friday
afternoon review fatigue...


> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 78a1cc6..6728479 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"),
> @@ -394,3 +389,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
>      ("extratime", integer),
>      ("weight", 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")

This doesn't turn into libxl_libxl_ev_user in the code, does it?

No, I checked, It's right, Good ;-)

> +
> +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}"),

I've got a pending patch which does away with comments in the IDL syntax
in favour of source level comments (e.g. "# for use by...."). I don't
think anyone reads the comments in generated code in preference to the
comments in the IDL source...

Either we race here or you can just go straight for the source level
comments.

> +    ("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 8270f34..a18c6b2 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
[...]
> +        case LIBXL_EVENT_TYPE_DISK_EJECT:
> +            /* XXX what is this for? */

This is signalled by qemu when the guest opens the CD-ROM drive.

(not sure if this is your comment or an existing one which got
reindented.)

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:24:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlizE-0000n7-TQ; Fri, 13 Jan 2012 15:24:12 +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 1RlizD-0000mx-N8
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:24:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326468243!7176456!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 9686 invoked from network); 13 Jan 2012 15:24:05 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 15:24:05 -0000
Received: by pbcc6 with SMTP id c6so10141016pbc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 07:24:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ridGyHTLLITnoX7fQb49KqDpK0dhLfBCobgguq2urco=;
	b=Mnemo3ZJ44eGFcpeyrHkhbZQ2ZRUw56BMblK6kLz6cFnC+zF0eIBYBNcvhPcCq//Va
	9TeH36xTvNhvAokpSJ8lFzWaJnrSxsmCJOz5mfcit09s4NrTw36jaqiSAjhyCNYiJqBc
	xmDfDFSlsQDwmOZzU7HLywTHghisuIRDvu5Es=
MIME-Version: 1.0
Received: by 10.68.75.199 with SMTP id e7mr2353398pbw.128.1326468242697; Fri,
	13 Jan 2012 07:24:02 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Fri, 13 Jan 2012 07:24:02 -0800 (PST)
In-Reply-To: <1326460844.17210.349.camel@zakaz.uk.xensource.com>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
	<1326460025.17210.343.camel@zakaz.uk.xensource.com>
	<CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@mail.gmail.com>
	<1326460844.17210.349.camel@zakaz.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:24:02 +0100
X-Google-Sender-Auth: oIQmmV8mwL2I10KdclbniqhTI5U
Message-ID: <CAPLaKK6NovBFv7JSD0K7K3erM9bqjzkGtomQQFdKs6QT-Y8hjw@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: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIEZy
aSwgMjAxMi0wMS0xMyBhdCAxMzoxMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzEzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IEZyaSwgMjAxMi0wMS0xMyBhdCAxMTo1NyArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+
PiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+PiA+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxy
b2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4gPj4gIyBEYXRlIDEzMjY0NTQ3ODUgLTM2MDAKPj4g
Pj4gIyBOb2RlIElEIDg4N2EzMjI5ZmQ3YTUwYzA0OTgxZTI5NzA5YmM3MjEwZGFmZWYzOGYKPj4g
Pj4gIyBQYXJlbnQgwqA1YjI2NzZhYzEzMjE4OTUxNjk4YzQ5ZmEwMzUwZjJhYzQ4MjIwZjNkCj4+
ID4+IGxpYnhsOiBkb24ndCBzZXQgYmFja2VuZCBzdGF0ZSB0byA1IHdoZW4gdHJ5aW5nIHRvIHVu
cGx1ZyBhIGRldmljZQo+PiA+Pgo+PiA+PiBsaWJ4bF9fZGV2aWNlX3JlbW92ZSB3YXMgc2V0dGlu
ZyBiYWNrZW5kIHN0YXRlIHRvIDUsIHdoaWNoIGNvdWxkCj4+ID4+IGNyZWF0ZSBhIHJhY2UgY29u
ZGl0aW9uLCBzaW5jZSB0aGUgcHJldmlvdXMgY2hlY2sgZm9yIHN0YXRlICE9IDQgYW5kCj4+ID4+
IHNldHRpbmcgc3RhdGUgdG8gNSB3YXMgbm90IGRvbmUgaW5zaWRlIG9mIHRoZSBzYW1lIHRyYW5z
YWN0aW9uLCBzbyB0aGUKPj4gPj4ga2VybmVsIGNvdWxkIGNoYW5nZSB0aGUgc3RhdGUgdG8gNiBp
biB0aGUgc3BhY2UgYmV0d2VlbiB0aGUgY2hlY2sgZm9yCj4+ID4+IHN0YXRlICE9IDQgYW5kIHNl
dHRpbmcgc3RhdGUgdG8gNS4KPj4gPj4KPj4gPj4gSSBtaWdodCBiZSB3cm9uZywgYnV0IHNpbmNl
IEkgZG9uJ3QgdGhpbmsgc2V0dGluZyBiYWNrZW5kIHN0YXRlIHRvIDUKPj4gPj4gaGVscHMgaW4g
YW55IHdheSB3aGVuIGRpc2Nvbm5lY3RpbmcgYSBkZXZpY2UKPj4gPgo+PiA+IEl0J3MgdGhlIGV4
YWN0IHRoaW5nIHdoaWNoIG1ha2VzIHRoZSBkaXNjb25uZWN0IGhhcHBlbiBhdCBhbGwsIGlzbid0
IGl0Pwo+Pgo+PiBXaGF0IG1ha2VzIHRoZSBkaXNjb25uZWN0IGhhcHBlbiBvbiBOZXRCU0QgYWwg
bGVhc3QgaXMgcmVtb3ZpbmcgdGhlCj4+IGZyb250ZW5kIG9yIHNldHRpbmcgdGhlIGZyb250ZW5k
IHN0YXRlIHRvIDYsIGJ1dCB0aGlzIGRvZXNuJ3QgZG8KPj4gYW55dGhpbmcgYXQgYWxsIChpdCBt
aWdodCBiZSBkaWZmZXJlbnQgb24gTGludXggdGhvdWdoKS4KPgo+IExpbnV4IGNlcnRhaW5seSB1
c2VzIHN0YXRlIDUgKEFLQSBYZW5idXNTdGF0ZUNsb3NpbmcpIGluIHRoZSBzdGF0ZQo+IG1hY2hp
bmUgaW4gYXQgbGVhc3QgbmV0ZnJvbnQrYmFjaywgYmxrZnJvbnQrYmFjayBwY2lmcm9udCtiYWNr
IGFuZAo+IGZiZnJvbnQgKGZiYmFjayBpcyBub3QgYW4gaW4ga2VybmVsIGRyaXZlcikuCj4KPiBl
LmcuIHdoZW4gbmV0ZnJvbnQgc2VlcyBuZXRiYWNrIGdvIHRvIGNsb3NpbmcgdGhlbiBpdCB3aWxs
IHNodXQgaXRzZWxmCj4gZG93biwgc2VlIGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOm5ldGJh
Y2tfY2hhbmdlZAo+Cj4+IENhbiBzb21lb25lIGNvbmZpcm0gdGhhdCB0aGlzIGlzIGFjdHVhbGx5
IHVzZWZ1bCBvbiBMaW51eD8KPgo+IEkgdGhpbmsgcmVhbGx5IGFueSBjaGFuZ2VzIGluIHRoZXNl
IGFyZWFzIHNob3VsZCBiZSBiYWNrZWQgdXAgd2l0aAo+IGVtcGlyaWNhbCBleHBlcmltZW50cyBv
biBhIHZhcmlldHkgb2Ygc3lzdGVtIHR5cGVzIChib3RoIGZyb250IGFuZAo+IGJhY2spLCBvdGhl
cndpc2Ugd2UgYXJlIGJhc2luZyB0aGluZ3Mgb24gc3VwcG9zaXRpb24gYW5kIGhlcmVzYXkgYWJv
dXQKPiBob3cgdGhpbmdzIGFyZSBzdXBwb3NlZCB0by9kbyB3b3JrLiBObyBvbmUgcmVhbGx5IGtu
b3dzIGZvciBzdXJlCj4gKHdpdG5lc3MgdGhlIG51bWJlciBvZiB0aW1lcyB3ZSd2ZSBhbGwgZ29u
ZSByb3VuZCBvbiB0aGlzKS4KCk9rLCBJJ20gZG9pbmcgYSBuZXcgcGF0Y2ggdGhhdCBlbmNsb3N1
cmVzIGV2ZXJ5dGhpbmcgaW5zaWRlIGEKdHJhbnNhY3Rpb24sIGFuZCBJIHdpbGwgdGVzdCBpdCBi
b3RoIG9uIE5ldEJTRCBhbmQgTGludXguIEhvd2V2ZXIsIEkKaGF2ZSBhIGRvdWJ0LCBjYW4gd2Ug
YXNzdW1lIHRoYXQgYSB0cmFuc2FjdGlvbiB0aGF0IG9ubHkgcGVyZm9ybXMgYQpyZWFkIHdpbGwg
YWx3YXlzIHN1Y2NlZWQgKHhzX3RyYW5zYWN0aW9uX2VuZCB3aWxsIG5ldmVyIHJldHVybiA8IDAp
PwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:24:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:24:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlizE-0000n7-TQ; Fri, 13 Jan 2012 15:24:12 +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 1RlizD-0000mx-N8
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:24:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326468243!7176456!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 9686 invoked from network); 13 Jan 2012 15:24:05 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 15:24:05 -0000
Received: by pbcc6 with SMTP id c6so10141016pbc.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 07:24:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ridGyHTLLITnoX7fQb49KqDpK0dhLfBCobgguq2urco=;
	b=Mnemo3ZJ44eGFcpeyrHkhbZQ2ZRUw56BMblK6kLz6cFnC+zF0eIBYBNcvhPcCq//Va
	9TeH36xTvNhvAokpSJ8lFzWaJnrSxsmCJOz5mfcit09s4NrTw36jaqiSAjhyCNYiJqBc
	xmDfDFSlsQDwmOZzU7HLywTHghisuIRDvu5Es=
MIME-Version: 1.0
Received: by 10.68.75.199 with SMTP id e7mr2353398pbw.128.1326468242697; Fri,
	13 Jan 2012 07:24:02 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Fri, 13 Jan 2012 07:24:02 -0800 (PST)
In-Reply-To: <1326460844.17210.349.camel@zakaz.uk.xensource.com>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
	<1326460025.17210.343.camel@zakaz.uk.xensource.com>
	<CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@mail.gmail.com>
	<1326460844.17210.349.camel@zakaz.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:24:02 +0100
X-Google-Sender-Auth: oIQmmV8mwL2I10KdclbniqhTI5U
Message-ID: <CAPLaKK6NovBFv7JSD0K7K3erM9bqjzkGtomQQFdKs6QT-Y8hjw@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: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIEZy
aSwgMjAxMi0wMS0xMyBhdCAxMzoxMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzEzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IEZyaSwgMjAxMi0wMS0xMyBhdCAxMTo1NyArMDAwMCwgUm9nZXIgUGF1IE1vbm5lIHdyb3RlOgo+
PiA+PiAjIEhHIGNoYW5nZXNldCBwYXRjaAo+PiA+PiAjIFVzZXIgUm9nZXIgUGF1IE1vbm5lIDxy
b2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4gPj4gIyBEYXRlIDEzMjY0NTQ3ODUgLTM2MDAKPj4g
Pj4gIyBOb2RlIElEIDg4N2EzMjI5ZmQ3YTUwYzA0OTgxZTI5NzA5YmM3MjEwZGFmZWYzOGYKPj4g
Pj4gIyBQYXJlbnQgwqA1YjI2NzZhYzEzMjE4OTUxNjk4YzQ5ZmEwMzUwZjJhYzQ4MjIwZjNkCj4+
ID4+IGxpYnhsOiBkb24ndCBzZXQgYmFja2VuZCBzdGF0ZSB0byA1IHdoZW4gdHJ5aW5nIHRvIHVu
cGx1ZyBhIGRldmljZQo+PiA+Pgo+PiA+PiBsaWJ4bF9fZGV2aWNlX3JlbW92ZSB3YXMgc2V0dGlu
ZyBiYWNrZW5kIHN0YXRlIHRvIDUsIHdoaWNoIGNvdWxkCj4+ID4+IGNyZWF0ZSBhIHJhY2UgY29u
ZGl0aW9uLCBzaW5jZSB0aGUgcHJldmlvdXMgY2hlY2sgZm9yIHN0YXRlICE9IDQgYW5kCj4+ID4+
IHNldHRpbmcgc3RhdGUgdG8gNSB3YXMgbm90IGRvbmUgaW5zaWRlIG9mIHRoZSBzYW1lIHRyYW5z
YWN0aW9uLCBzbyB0aGUKPj4gPj4ga2VybmVsIGNvdWxkIGNoYW5nZSB0aGUgc3RhdGUgdG8gNiBp
biB0aGUgc3BhY2UgYmV0d2VlbiB0aGUgY2hlY2sgZm9yCj4+ID4+IHN0YXRlICE9IDQgYW5kIHNl
dHRpbmcgc3RhdGUgdG8gNS4KPj4gPj4KPj4gPj4gSSBtaWdodCBiZSB3cm9uZywgYnV0IHNpbmNl
IEkgZG9uJ3QgdGhpbmsgc2V0dGluZyBiYWNrZW5kIHN0YXRlIHRvIDUKPj4gPj4gaGVscHMgaW4g
YW55IHdheSB3aGVuIGRpc2Nvbm5lY3RpbmcgYSBkZXZpY2UKPj4gPgo+PiA+IEl0J3MgdGhlIGV4
YWN0IHRoaW5nIHdoaWNoIG1ha2VzIHRoZSBkaXNjb25uZWN0IGhhcHBlbiBhdCBhbGwsIGlzbid0
IGl0Pwo+Pgo+PiBXaGF0IG1ha2VzIHRoZSBkaXNjb25uZWN0IGhhcHBlbiBvbiBOZXRCU0QgYWwg
bGVhc3QgaXMgcmVtb3ZpbmcgdGhlCj4+IGZyb250ZW5kIG9yIHNldHRpbmcgdGhlIGZyb250ZW5k
IHN0YXRlIHRvIDYsIGJ1dCB0aGlzIGRvZXNuJ3QgZG8KPj4gYW55dGhpbmcgYXQgYWxsIChpdCBt
aWdodCBiZSBkaWZmZXJlbnQgb24gTGludXggdGhvdWdoKS4KPgo+IExpbnV4IGNlcnRhaW5seSB1
c2VzIHN0YXRlIDUgKEFLQSBYZW5idXNTdGF0ZUNsb3NpbmcpIGluIHRoZSBzdGF0ZQo+IG1hY2hp
bmUgaW4gYXQgbGVhc3QgbmV0ZnJvbnQrYmFjaywgYmxrZnJvbnQrYmFjayBwY2lmcm9udCtiYWNr
IGFuZAo+IGZiZnJvbnQgKGZiYmFjayBpcyBub3QgYW4gaW4ga2VybmVsIGRyaXZlcikuCj4KPiBl
LmcuIHdoZW4gbmV0ZnJvbnQgc2VlcyBuZXRiYWNrIGdvIHRvIGNsb3NpbmcgdGhlbiBpdCB3aWxs
IHNodXQgaXRzZWxmCj4gZG93biwgc2VlIGRyaXZlcnMvbmV0L3hlbi1uZXRmcm9udC5jOm5ldGJh
Y2tfY2hhbmdlZAo+Cj4+IENhbiBzb21lb25lIGNvbmZpcm0gdGhhdCB0aGlzIGlzIGFjdHVhbGx5
IHVzZWZ1bCBvbiBMaW51eD8KPgo+IEkgdGhpbmsgcmVhbGx5IGFueSBjaGFuZ2VzIGluIHRoZXNl
IGFyZWFzIHNob3VsZCBiZSBiYWNrZWQgdXAgd2l0aAo+IGVtcGlyaWNhbCBleHBlcmltZW50cyBv
biBhIHZhcmlldHkgb2Ygc3lzdGVtIHR5cGVzIChib3RoIGZyb250IGFuZAo+IGJhY2spLCBvdGhl
cndpc2Ugd2UgYXJlIGJhc2luZyB0aGluZ3Mgb24gc3VwcG9zaXRpb24gYW5kIGhlcmVzYXkgYWJv
dXQKPiBob3cgdGhpbmdzIGFyZSBzdXBwb3NlZCB0by9kbyB3b3JrLiBObyBvbmUgcmVhbGx5IGtu
b3dzIGZvciBzdXJlCj4gKHdpdG5lc3MgdGhlIG51bWJlciBvZiB0aW1lcyB3ZSd2ZSBhbGwgZ29u
ZSByb3VuZCBvbiB0aGlzKS4KCk9rLCBJJ20gZG9pbmcgYSBuZXcgcGF0Y2ggdGhhdCBlbmNsb3N1
cmVzIGV2ZXJ5dGhpbmcgaW5zaWRlIGEKdHJhbnNhY3Rpb24sIGFuZCBJIHdpbGwgdGVzdCBpdCBi
b3RoIG9uIE5ldEJTRCBhbmQgTGludXguIEhvd2V2ZXIsIEkKaGF2ZSBhIGRvdWJ0LCBjYW4gd2Ug
YXNzdW1lIHRoYXQgYSB0cmFuc2FjdGlvbiB0aGF0IG9ubHkgcGVyZm9ybXMgYQpyZWFkIHdpbGwg
YWx3YXlzIHN1Y2NlZWQgKHhzX3RyYW5zYWN0aW9uX2VuZCB3aWxsIG5ldmVyIHJldHVybiA8IDAp
PwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:32:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:32:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlj6h-00011w-RZ; Fri, 13 Jan 2012 15:31: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 1Rlj6g-00011r-4A
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:31:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326468706!8526816!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 29356 invoked from network); 13 Jan 2012 15:31: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; 13 Jan 2012 15:31:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 15:31:46 +0000
Message-Id: <4F105CAA020000780006C892@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 15:32:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF367020000780006C59D@nat28.tlf.novell.com>
	<4F103879.50709@tycho.nsa.gov>
In-Reply-To: <4F103879.50709@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 13.01.12 at 14:58, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/13/2012 03:03 AM, Jan Beulich wrote:
>>>>> On 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> +int set_global_virq_handler(struct domain *d, uint32_t virq)
>>> +{
>>> +    struct domain *old;
>>> +
>>> +    if (virq >= NR_VIRQS)
>>> +        return -EINVAL;
>>> +    if (!virq_is_global(virq))
>>> +        return -EINVAL;
>>> +
>>> +    if (global_virq_handlers[virq] == d)
>>> +        return 0;
>>> +
>>> +    if (unlikely(!get_domain(d)))
>>> +        return -EINVAL;
>>> +
>>> +    spin_lock(&global_virq_handlers_lock);
>>> +    old = global_virq_handlers[virq];
>>> +    global_virq_handlers[virq] = d;
>>> +    spin_unlock(&global_virq_handlers_lock);
>>> +
>>> +    if (old != NULL)
>>> +        put_domain(old);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static void clear_global_virq_handlers(struct domain *d)
>>> +{
>>> +    uint32_t virq;
>>> +    int put_count = 0;
>>> +
>>> +    spin_lock(&global_virq_handlers_lock);
>>> +
>>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>>> +        if (global_virq_handlers[virq] == d) {
>>> +            global_virq_handlers[virq] = NULL;
>>> +            put_count++;
>>> +        }
>>> +    }
>>> +
>>> +    spin_unlock(&global_virq_handlers_lock);
>>> +
>>> +    while (put_count) {
>>> +        put_domain(d);
>>> +        put_count--;
>>> +    }
>>> +}
>> 
>> Formatting in this entire hunk should be changed to match that of the
>> rest of the file.
>> 
>>> --- a/xen/include/xsm/xsm.h
>>> +++ b/xen/include/xsm/xsm.h
>>> @@ -64,6 +64,7 @@ struct xsm_operations {
>>>      int (*domain_settime) (struct domain *d);
>>>      int (*set_target) (struct domain *d, struct domain *e);
>>>      int (*domctl) (struct domain *d, int cmd);
>>> +    int (*set_virq_handler) (struct domain *d, int virq);
>> 
>> Here and further down, the 'int' still survived.
>> 
>> Jan
>> 
> 
> Much of the existing code handling virqs uses int; should I also change
> these instances to uint32_t?

That would be nice (if you do, making this a separate patch would be
desirable). Here I'm just asking to not repeat the 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 Jan 13 15:32:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:32:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlj6h-00011w-RZ; Fri, 13 Jan 2012 15:31: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 1Rlj6g-00011r-4A
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:31:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326468706!8526816!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 29356 invoked from network); 13 Jan 2012 15:31: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; 13 Jan 2012 15:31:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 15:31:46 +0000
Message-Id: <4F105CAA020000780006C892@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 15:32:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF367020000780006C59D@nat28.tlf.novell.com>
	<4F103879.50709@tycho.nsa.gov>
In-Reply-To: <4F103879.50709@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>, xen-devel@lists.xensource.com,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 13.01.12 at 14:58, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/13/2012 03:03 AM, Jan Beulich wrote:
>>>>> On 13.01.12 at 00:35, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> +int set_global_virq_handler(struct domain *d, uint32_t virq)
>>> +{
>>> +    struct domain *old;
>>> +
>>> +    if (virq >= NR_VIRQS)
>>> +        return -EINVAL;
>>> +    if (!virq_is_global(virq))
>>> +        return -EINVAL;
>>> +
>>> +    if (global_virq_handlers[virq] == d)
>>> +        return 0;
>>> +
>>> +    if (unlikely(!get_domain(d)))
>>> +        return -EINVAL;
>>> +
>>> +    spin_lock(&global_virq_handlers_lock);
>>> +    old = global_virq_handlers[virq];
>>> +    global_virq_handlers[virq] = d;
>>> +    spin_unlock(&global_virq_handlers_lock);
>>> +
>>> +    if (old != NULL)
>>> +        put_domain(old);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static void clear_global_virq_handlers(struct domain *d)
>>> +{
>>> +    uint32_t virq;
>>> +    int put_count = 0;
>>> +
>>> +    spin_lock(&global_virq_handlers_lock);
>>> +
>>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>>> +        if (global_virq_handlers[virq] == d) {
>>> +            global_virq_handlers[virq] = NULL;
>>> +            put_count++;
>>> +        }
>>> +    }
>>> +
>>> +    spin_unlock(&global_virq_handlers_lock);
>>> +
>>> +    while (put_count) {
>>> +        put_domain(d);
>>> +        put_count--;
>>> +    }
>>> +}
>> 
>> Formatting in this entire hunk should be changed to match that of the
>> rest of the file.
>> 
>>> --- a/xen/include/xsm/xsm.h
>>> +++ b/xen/include/xsm/xsm.h
>>> @@ -64,6 +64,7 @@ struct xsm_operations {
>>>      int (*domain_settime) (struct domain *d);
>>>      int (*set_target) (struct domain *d, struct domain *e);
>>>      int (*domctl) (struct domain *d, int cmd);
>>> +    int (*set_virq_handler) (struct domain *d, int virq);
>> 
>> Here and further down, the 'int' still survived.
>> 
>> Jan
>> 
> 
> Much of the existing code handling virqs uses int; should I also change
> these instances to uint32_t?

That would be nice (if you do, making this a separate patch would be
desirable). Here I'm just asking to not repeat the 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 Jan 13 15:37:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RljBR-0001AZ-Ip; Fri, 13 Jan 2012 15:36:49 +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 1RljBP-0001AM-Ot
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:36:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326469001!8364265!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 2527 invoked from network); 13 Jan 2012 15:36:41 -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; 13 Jan 2012 15:36:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 15:36:41 +0000
Message-Id: <4F105DD1020000780006C8A5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 15:37:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
In-Reply-To: <4F103A62.3000403@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/include/xen/xenbus_dev.h
>>> +++ b/include/xen/xenbus_dev.h
>>> @@ -38,4 +38,18 @@
>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>  
>>> +#define IOCTL_XENBUS_ALLOC				\
>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>> +struct ioctl_xenbus_alloc {
>>> +	/* IN */
>>> +	/* The domain ID (must exist) for xenstore */
>>> +	uint16_t dom;
>>> +	uint16_t pad;
>>> +	/* OUT */
>>> +	/* The port allocated for xenbus communication */
>>> +	uint32_t port;
>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>> +	uint32_t grant_ref;
>>> +};
>> 
>> As said in my reply to the previous patch version - if the functionality
>> differs, the number *and* name should be different from the legacy
>> implementation's. Otherwise, how should compatible user space code
>> be written?
>> 
>> Jan
>> 
> 
> This implementation has the same functionality as the legacy ioctl,

It doesn't - none of the "OUT" fields above exist there.

> although it has a different number and is performed on a different file,
> so it is already impossible to make automatically compatible userspace
> code.

That's not what I was aiming at. The problem you're introducing is
that you name the ioctl IOCTL_XENBUS_ALLOC, identical to what
the legacy code named it. Hence one won't be able to write user
mode code to invoke, depending on runtime determination, either
the old or the new function.

Jan

> The structure name was changed to match other ioctl arguments, but
> the contents should be the same as in the legacy ioctl. If changing what
> file the ioctl is performed on justifies changing the ioctl name, then I
> would prefer the simpler interface where the domain ID is passed in as the
> ioctl parameter instead of a structure that only has one useful output.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:37:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:37:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RljBR-0001AZ-Ip; Fri, 13 Jan 2012 15:36:49 +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 1RljBP-0001AM-Ot
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:36:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326469001!8364265!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 2527 invoked from network); 13 Jan 2012 15:36:41 -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; 13 Jan 2012 15:36:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 15:36:41 +0000
Message-Id: <4F105DD1020000780006C8A5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 15:37:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
In-Reply-To: <4F103A62.3000403@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> --- a/include/xen/xenbus_dev.h
>>> +++ b/include/xen/xenbus_dev.h
>>> @@ -38,4 +38,18 @@
>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>  
>>> +#define IOCTL_XENBUS_ALLOC				\
>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>> +struct ioctl_xenbus_alloc {
>>> +	/* IN */
>>> +	/* The domain ID (must exist) for xenstore */
>>> +	uint16_t dom;
>>> +	uint16_t pad;
>>> +	/* OUT */
>>> +	/* The port allocated for xenbus communication */
>>> +	uint32_t port;
>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>> +	uint32_t grant_ref;
>>> +};
>> 
>> As said in my reply to the previous patch version - if the functionality
>> differs, the number *and* name should be different from the legacy
>> implementation's. Otherwise, how should compatible user space code
>> be written?
>> 
>> Jan
>> 
> 
> This implementation has the same functionality as the legacy ioctl,

It doesn't - none of the "OUT" fields above exist there.

> although it has a different number and is performed on a different file,
> so it is already impossible to make automatically compatible userspace
> code.

That's not what I was aiming at. The problem you're introducing is
that you name the ioctl IOCTL_XENBUS_ALLOC, identical to what
the legacy code named it. Hence one won't be able to write user
mode code to invoke, depending on runtime determination, either
the old or the new function.

Jan

> The structure name was changed to match other ioctl arguments, but
> the contents should be the same as in the legacy ioctl. If changing what
> file the ioctl is performed on justifies changing the ioctl name, then I
> would prefer the simpler interface where the domain ID is passed in as the
> ioctl parameter instead of a structure that only has one useful output.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:44:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RljIf-0001P8-4X; Fri, 13 Jan 2012 15:44:17 +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 1RljId-0001Ob-Qf
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:44:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326469449!10816553!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 1456 invoked from network); 13 Jan 2012 15:44:09 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-182.messagelabs.com with SMTP;
	13 Jan 2012 15:44:09 -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
	q0DFi7Je000624; Fri, 13 Jan 2012 15:44:07 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 q0DFi780019484; 
	Fri, 13 Jan 2012 10:44:07 -0500
Message-ID: <4F105144.8070004@tycho.nsa.gov>
Date: Fri, 13 Jan 2012 10:44:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
	<4F105DD1020000780006C8A5@nat28.tlf.novell.com>
In-Reply-To: <4F105DD1020000780006C8A5@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/13/2012 10:37 AM, Jan Beulich wrote:
>>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> --- a/include/xen/xenbus_dev.h
>>>> +++ b/include/xen/xenbus_dev.h
>>>> @@ -38,4 +38,18 @@
>>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>>  
>>>> +#define IOCTL_XENBUS_ALLOC				\
>>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>>> +struct ioctl_xenbus_alloc {
>>>> +	/* IN */
>>>> +	/* The domain ID (must exist) for xenstore */
>>>> +	uint16_t dom;
>>>> +	uint16_t pad;
>>>> +	/* OUT */
>>>> +	/* The port allocated for xenbus communication */
>>>> +	uint32_t port;
>>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>>> +	uint32_t grant_ref;
>>>> +};
>>>
>>> As said in my reply to the previous patch version - if the functionality
>>> differs, the number *and* name should be different from the legacy
>>> implementation's. Otherwise, how should compatible user space code
>>> be written?
>>>
>>> Jan
>>>
>>
>> This implementation has the same functionality as the legacy ioctl,
> 
> It doesn't - none of the "OUT" fields above exist there.

Are you looking at the same legacy ioctl as I am? I found it in 2.6.18.hg
where the structure was defined as:

typedef struct xenbus_alloc {
    domid_t dom;
    __u32 port;
    __u32 grant_ref;
} xenbus_alloc_t;

The port and grant_ref fields were outputs. I added padding for clarity
since domid_t is uint16_t.

> 
>> although it has a different number and is performed on a different file,
>> so it is already impossible to make automatically compatible userspace
>> code.
> 
> That's not what I was aiming at. The problem you're introducing is
> that you name the ioctl IOCTL_XENBUS_ALLOC, identical to what
> the legacy code named it. Hence one won't be able to write user
> mode code to invoke, depending on runtime determination, either
> the old or the new function.
> 
> Jan
> 
>> The structure name was changed to match other ioctl arguments, but
>> the contents should be the same as in the legacy ioctl. If changing what
>> file the ioctl is performed on justifies changing the ioctl name, then I
>> would prefer the simpler interface where the domain ID is passed in as the
>> ioctl parameter instead of a structure that only has one useful output.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:44:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RljIf-0001P8-4X; Fri, 13 Jan 2012 15:44:17 +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 1RljId-0001Ob-Qf
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:44:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326469449!10816553!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 1456 invoked from network); 13 Jan 2012 15:44:09 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-182.messagelabs.com with SMTP;
	13 Jan 2012 15:44:09 -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
	q0DFi7Je000624; Fri, 13 Jan 2012 15:44:07 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 q0DFi780019484; 
	Fri, 13 Jan 2012 10:44:07 -0500
Message-ID: <4F105144.8070004@tycho.nsa.gov>
Date: Fri, 13 Jan 2012 10:44:04 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
	<4F105DD1020000780006C8A5@nat28.tlf.novell.com>
In-Reply-To: <4F105DD1020000780006C8A5@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/13/2012 10:37 AM, Jan Beulich wrote:
>>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> --- a/include/xen/xenbus_dev.h
>>>> +++ b/include/xen/xenbus_dev.h
>>>> @@ -38,4 +38,18 @@
>>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>>  
>>>> +#define IOCTL_XENBUS_ALLOC				\
>>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>>> +struct ioctl_xenbus_alloc {
>>>> +	/* IN */
>>>> +	/* The domain ID (must exist) for xenstore */
>>>> +	uint16_t dom;
>>>> +	uint16_t pad;
>>>> +	/* OUT */
>>>> +	/* The port allocated for xenbus communication */
>>>> +	uint32_t port;
>>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>>> +	uint32_t grant_ref;
>>>> +};
>>>
>>> As said in my reply to the previous patch version - if the functionality
>>> differs, the number *and* name should be different from the legacy
>>> implementation's. Otherwise, how should compatible user space code
>>> be written?
>>>
>>> Jan
>>>
>>
>> This implementation has the same functionality as the legacy ioctl,
> 
> It doesn't - none of the "OUT" fields above exist there.

Are you looking at the same legacy ioctl as I am? I found it in 2.6.18.hg
where the structure was defined as:

typedef struct xenbus_alloc {
    domid_t dom;
    __u32 port;
    __u32 grant_ref;
} xenbus_alloc_t;

The port and grant_ref fields were outputs. I added padding for clarity
since domid_t is uint16_t.

> 
>> although it has a different number and is performed on a different file,
>> so it is already impossible to make automatically compatible userspace
>> code.
> 
> That's not what I was aiming at. The problem you're introducing is
> that you name the ioctl IOCTL_XENBUS_ALLOC, identical to what
> the legacy code named it. Hence one won't be able to write user
> mode code to invoke, depending on runtime determination, either
> the old or the new function.
> 
> Jan
> 
>> The structure name was changed to match other ioctl arguments, but
>> the contents should be the same as in the legacy ioctl. If changing what
>> file the ioctl is performed on justifies changing the ioctl name, then I
>> would prefer the simpler interface where the domain ID is passed in as the
>> ioctl parameter instead of a structure that only has one useful output.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RljMJ-0001iy-1S; Fri, 13 Jan 2012 15:48: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 1RljMH-0001if-J0
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:48:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326469638!55852256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29478 invoked from network); 13 Jan 2012 15:47:18 -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;
	13 Jan 2012 15:47:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10005525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:47: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, 13 Jan 2012 15:47: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
	1RljM9-0004X5-Ul; Fri, 13 Jan 2012 15:47:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RljM9-0002aJ-QK;
	Fri, 13 Jan 2012 15:47:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.21033.793660.726579@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:47:53 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326467245.17210.374.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<1326467245.17210.374.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 07/10] 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 07/10] libxl: New API for providing OS events to libxl"):
> On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> > +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).
> 
> I think you were going to move the comments (sorry).

*sigh*  OK, I will do that.

> > + * Most code in libxlshould not need to initialise their own egc.
> 
> Missing space.         ^

Fixed.

> Will any function even need to initialise their own egc and/or is it
> normally provided by infrastructure code? Otherwise when should a
> function initialise their own egc? Is it simply that you know if you
> need to initialise one because you are calling a function which takes
> one?

You don't need to because you should never end up calling a function
that takes an egc unless you've got one already from the event
machinery.

> > + * Even functions which generate specific kinds of events don't need
> > + * to - rather, they will be passed an egc into their own callback
> > + * function and should just use the one they're given.
> > + *
> > + * A handy idiom for functions taking an egc is:
> > + *     libxl__gc *gc = &egc->gc;
> 
> You've provided lots of handy macros for other things like this, perhaps
> EGC by comparison with CTX. Using GC seems better on the face of it but
> since it will only work in a context with an egc that is actually
> confusing.

How about:
  #define EGC_GC  libxl__gc *gc = &egc->gc
?

> > + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> > + * within libxl, because libxl__egc_cleanup may call back into the
> > + * application.  This should be documented near the function
> > + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
> 
> Can we also enforce/check this with a flag in the ctx? I guess not since
> multiple threads might call into libxl with the same ctx and each may
> legitimately setup an egc.?

Exactly.  This is the same disagreement I'm having with Stefano.

But this restriction is not difficult in practice because functions
that want to generate events are almost[1] invariably functions which
were themselves called in response to an OS event, and they get an egc
provided by the event machinery.

See for example disk_eject_xswatch_callback, which is the thing which
generates events of type DISK_EJECT.  It's a xenstore watch callback
function, so it gets an egc provided by the event machinery and uses
that for NEW_EVENT etc.

The code which sets up the callback, libxl_evenable_disk_eject,
doesn't need an egc because setting up a callback only needs a gc.  So
you never need to construct an egc yourself.

The functions which make their own egc, and which are therefore
forbidden for other callers inside libxl, are things like
   libxl_osevent_beforepoll
   libxl_event_wait
and if you're calling those from within libxl you are definitely doing
the whole thing entirely wrong.

Ian.

[1] libxl__ao_inprogress is a counterexample, but it's part of the
event machinery, not a normal function implementing some actual
domain-related functionality.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RljMJ-0001iy-1S; Fri, 13 Jan 2012 15:48: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 1RljMH-0001if-J0
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:48:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326469638!55852256!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29478 invoked from network); 13 Jan 2012 15:47:18 -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;
	13 Jan 2012 15:47:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10005525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:47: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, 13 Jan 2012 15:47: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
	1RljM9-0004X5-Ul; Fri, 13 Jan 2012 15:47:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RljM9-0002aJ-QK;
	Fri, 13 Jan 2012 15:47:53 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.21033.793660.726579@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:47:53 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326467245.17210.374.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<1326467245.17210.374.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 07/10] 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 07/10] libxl: New API for providing OS events to libxl"):
> On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> > +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).
> 
> I think you were going to move the comments (sorry).

*sigh*  OK, I will do that.

> > + * Most code in libxlshould not need to initialise their own egc.
> 
> Missing space.         ^

Fixed.

> Will any function even need to initialise their own egc and/or is it
> normally provided by infrastructure code? Otherwise when should a
> function initialise their own egc? Is it simply that you know if you
> need to initialise one because you are calling a function which takes
> one?

You don't need to because you should never end up calling a function
that takes an egc unless you've got one already from the event
machinery.

> > + * Even functions which generate specific kinds of events don't need
> > + * to - rather, they will be passed an egc into their own callback
> > + * function and should just use the one they're given.
> > + *
> > + * A handy idiom for functions taking an egc is:
> > + *     libxl__gc *gc = &egc->gc;
> 
> You've provided lots of handy macros for other things like this, perhaps
> EGC by comparison with CTX. Using GC seems better on the face of it but
> since it will only work in a context with an egc that is actually
> confusing.

How about:
  #define EGC_GC  libxl__gc *gc = &egc->gc
?

> > + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> > + * within libxl, because libxl__egc_cleanup may call back into the
> > + * application.  This should be documented near the function
> > + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
> 
> Can we also enforce/check this with a flag in the ctx? I guess not since
> multiple threads might call into libxl with the same ctx and each may
> legitimately setup an egc.?

Exactly.  This is the same disagreement I'm having with Stefano.

But this restriction is not difficult in practice because functions
that want to generate events are almost[1] invariably functions which
were themselves called in response to an OS event, and they get an egc
provided by the event machinery.

See for example disk_eject_xswatch_callback, which is the thing which
generates events of type DISK_EJECT.  It's a xenstore watch callback
function, so it gets an egc provided by the event machinery and uses
that for NEW_EVENT etc.

The code which sets up the callback, libxl_evenable_disk_eject,
doesn't need an egc because setting up a callback only needs a gc.  So
you never need to construct an egc yourself.

The functions which make their own egc, and which are therefore
forbidden for other callers inside libxl, are things like
   libxl_osevent_beforepoll
   libxl_event_wait
and if you're calling those from within libxl you are definitely doing
the whole thing entirely wrong.

Ian.

[1] libxl__ao_inprogress is a counterexample, but it's part of the
event machinery, not a normal function implementing some actual
domain-related functionality.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:49:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:49:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RljNq-0001qG-Hm; Fri, 13 Jan 2012 15:49: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 1RljNo-0001pk-SN
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:49:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326469770!10918886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19402 invoked from network); 13 Jan 2012 15:49:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 15:49:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10005578"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:49:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 15:49: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
	1RljNh-0004Xf-Vu; Fri, 13 Jan 2012 15:49:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RljNh-0002aW-Tm;
	Fri, 13 Jan 2012 15:49:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.21129.895691.402481@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:49:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326468136.17210.381.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-9-git-send-email-ian.jackson@eu.citrix.com>
	<1326468136.17210.381.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 08/10] 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 08/10] libxl: New event generation API"):
> I think I've seen most of this before too so again I only skimmed it.
> Nothing much jumped out but I must admit I'm suffering from Friday
> afternoon review fatigue...

Heh.

> On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 78a1cc6..6728479 100644
...
> > +libxl_event_type = Enumeration("event_type", [
> > +    (1, "DOMAIN_SHUTDOWN"),
> > +    (2, "DOMAIN_DESTROY"),
> > +    (3, "DISK_EJECT"),
> > +    ])
> > +
> > +libxl_ev_user = Number("libxl_ev_user")
> 
> This doesn't turn into libxl_libxl_ev_user in the code, does it?
> 
> No, I checked, It's right, Good ;-)

In fact to make the ocaml binding work it is necessary to write this
as
   libxl_ev_user = UInt(64);
but we can keep the typedef.  This is because the ocaml idl generator
wants to know the size of the integer.  I think this is not an
unreasonable requirement so I will keep that change even though I'm
about to disable the generation of an ocaml binding for libxl_event
for other reasons (mainly, the lack of KeyedUnion).

> > +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}"),
> 
> I've got a pending patch which does away with comments in the IDL syntax
> in favour of source level comments (e.g. "# for use by...."). I don't
> think anyone reads the comments in generated code in preference to the
> comments in the IDL source...
> 
> Either we race here or you can just go straight for the source level
> comments.

I'll do the latter.

> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 8270f34..a18c6b2 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> [...]
> > +        case LIBXL_EVENT_TYPE_DISK_EJECT:
> > +            /* XXX what is this for? */
> 
> This is signalled by qemu when the guest opens the CD-ROM drive.
> 
> (not sure if this is your comment or an existing one which got
> reindented.)

It's an existing comment, which I didn't feel confident to remove.
I guess if we're happy with all the code here I could delete it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:49:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:49:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RljNq-0001qG-Hm; Fri, 13 Jan 2012 15:49: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 1RljNo-0001pk-SN
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:49:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326469770!10918886!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19402 invoked from network); 13 Jan 2012 15:49:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 15:49:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10005578"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:49:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 15:49: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
	1RljNh-0004Xf-Vu; Fri, 13 Jan 2012 15:49:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RljNh-0002aW-Tm;
	Fri, 13 Jan 2012 15:49:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.21129.895691.402481@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:49:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326468136.17210.381.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-9-git-send-email-ian.jackson@eu.citrix.com>
	<1326468136.17210.381.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 08/10] 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 08/10] libxl: New event generation API"):
> I think I've seen most of this before too so again I only skimmed it.
> Nothing much jumped out but I must admit I'm suffering from Friday
> afternoon review fatigue...

Heh.

> On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 78a1cc6..6728479 100644
...
> > +libxl_event_type = Enumeration("event_type", [
> > +    (1, "DOMAIN_SHUTDOWN"),
> > +    (2, "DOMAIN_DESTROY"),
> > +    (3, "DISK_EJECT"),
> > +    ])
> > +
> > +libxl_ev_user = Number("libxl_ev_user")
> 
> This doesn't turn into libxl_libxl_ev_user in the code, does it?
> 
> No, I checked, It's right, Good ;-)

In fact to make the ocaml binding work it is necessary to write this
as
   libxl_ev_user = UInt(64);
but we can keep the typedef.  This is because the ocaml idl generator
wants to know the size of the integer.  I think this is not an
unreasonable requirement so I will keep that change even though I'm
about to disable the generation of an ocaml binding for libxl_event
for other reasons (mainly, the lack of KeyedUnion).

> > +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}"),
> 
> I've got a pending patch which does away with comments in the IDL syntax
> in favour of source level comments (e.g. "# for use by...."). I don't
> think anyone reads the comments in generated code in preference to the
> comments in the IDL source...
> 
> Either we race here or you can just go straight for the source level
> comments.

I'll do the latter.

> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 8270f34..a18c6b2 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> [...]
> > +        case LIBXL_EVENT_TYPE_DISK_EJECT:
> > +            /* XXX what is this for? */
> 
> This is signalled by qemu when the guest opens the CD-ROM drive.
> 
> (not sure if this is your comment or an existing one which got
> reindented.)

It's an existing comment, which I didn't feel confident to remove.
I guess if we're happy with all the code here I could delete it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:55:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RljSl-0002M8-0K; Fri, 13 Jan 2012 15: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 1RljSj-0002Lh-Mf
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:54:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326470075!7180828!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13402 invoked from network); 13 Jan 2012 15:54:35 -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;
	13 Jan 2012 15:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10006152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:54: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, 13 Jan 2012 15:54: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
	1RljSc-0004Zn-Fq; Fri, 13 Jan 2012 15:54:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RljSc-0003Tn-Ev;
	Fri, 13 Jan 2012 15:54:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.21434.449740.107652@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:54:34 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326451503.17210.313.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-10-git-send-email-ian.jackson@eu.citrix.com>
	<1326451503.17210.313.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 09/10] libxl: introduce
 libxl_fd_set_nonblock, rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 09/10] libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec"):
> On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> > We want a function for setting fds to nonblocking, so introduce one.
...
> (although I notice that you've slipped back into the
> comment-follows-prototype style...)

Fixed.

(I still think it's ridiculous.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:55:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15: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 1RljSl-0002M8-0K; Fri, 13 Jan 2012 15: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 1RljSj-0002Lh-Mf
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:54:41 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326470075!7180828!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13402 invoked from network); 13 Jan 2012 15:54:35 -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;
	13 Jan 2012 15:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10006152"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:54: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, 13 Jan 2012 15:54: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
	1RljSc-0004Zn-Fq; Fri, 13 Jan 2012 15:54:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RljSc-0003Tn-Ev;
	Fri, 13 Jan 2012 15:54:34 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.21434.449740.107652@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:54:34 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326451503.17210.313.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-10-git-send-email-ian.jackson@eu.citrix.com>
	<1326451503.17210.313.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 09/10] libxl: introduce
 libxl_fd_set_nonblock, rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 09/10] libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec"):
> On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> > We want a function for setting fds to nonblocking, so introduce one.
...
> (although I notice that you've slipped back into the
> comment-follows-prototype style...)

Fixed.

(I still think it's ridiculous.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:57:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RljV3-0002Xb-JK; Fri, 13 Jan 2012 15:57: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 1RljV1-0002X8-V6
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:57:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326470217!10789540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3147 invoked from network); 13 Jan 2012 15:56:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 15:56:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10006293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:56: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, 13 Jan 2012 15:56:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 15:56:49 +0000
In-Reply-To: <20240.21033.793660.726579@mariner.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<1326467245.17210.374.camel@zakaz.uk.xensource.com>
	<20240.21033.793660.726579@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326470209.17210.384.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 07/10] 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, 2012-01-13 at 15:47 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 07/10] libxl: New API for providing OS events to libxl"):
> > On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> > Will any function even need to initialise their own egc and/or is it
> > normally provided by infrastructure code? Otherwise when should a
> > function initialise their own egc? Is it simply that you know if you
> > need to initialise one because you are calling a function which takes
> > one?
> 
> You don't need to because you should never end up calling a function
> that takes an egc unless you've got one already from the event
> machinery.

I think it is worth stating explicitly. e.g. "You should never need to
initialise an egc unless you are part of the event machinery itself,
Otherwise you will always be given an egc if you need one". I might even
go as far as s/should never/will never/.

> > > + * Even functions which generate specific kinds of events don't need
> > > + * to - rather, they will be passed an egc into their own callback
> > > + * function and should just use the one they're given.
> > > + *
> > > + * A handy idiom for functions taking an egc is:
> > > + *     libxl__gc *gc = &egc->gc;
> > 
> > You've provided lots of handy macros for other things like this, perhaps
> > EGC by comparison with CTX. Using GC seems better on the face of it but
> > since it will only work in a context with an egc that is actually
> > confusing.
> 
> How about:
>   #define EGC_GC  libxl__gc *gc = &egc->gc
> ?

Works for me.

> 
> > > + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> > > + * within libxl, because libxl__egc_cleanup may call back into the
> > > + * application.  This should be documented near the function
> > > + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
> > 
> > Can we also enforce/check this with a flag in the ctx? I guess not since
> > multiple threads might call into libxl with the same ctx and each may
> > legitimately setup an egc.?
> 
> Exactly.  This is the same disagreement I'm having with Stefano.
> 
> But this restriction is not difficult in practice because functions
> that want to generate events are almost[1] invariably functions which
> were themselves called in response to an OS event, and they get an egc
> provided by the event machinery.
> 
> See for example disk_eject_xswatch_callback, which is the thing which
> generates events of type DISK_EJECT.  It's a xenstore watch callback
> function, so it gets an egc provided by the event machinery and uses
> that for NEW_EVENT etc.
> 
> The code which sets up the callback, libxl_evenable_disk_eject,
> doesn't need an egc because setting up a callback only needs a gc.  So
> you never need to construct an egc yourself.
> 
> The functions which make their own egc, and which are therefore
> forbidden for other callers inside libxl, are things like
>    libxl_osevent_beforepoll
>    libxl_event_wait
> and if you're calling those from within libxl you are definitely doing
> the whole thing entirely wrong.
> 
> Ian.
> 
> [1] libxl__ao_inprogress is a counterexample, but it's part of the
> event machinery, not a normal function implementing some actual
> domain-related functionality.

Makes sense, I think the wording I proposed above describes this?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 15:57:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 15:57:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RljV3-0002Xb-JK; Fri, 13 Jan 2012 15:57: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 1RljV1-0002X8-V6
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:57:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326470217!10789540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3147 invoked from network); 13 Jan 2012 15:56:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 15:56:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10006293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:56: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, 13 Jan 2012 15:56:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 15:56:49 +0000
In-Reply-To: <20240.21033.793660.726579@mariner.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<1326467245.17210.374.camel@zakaz.uk.xensource.com>
	<20240.21033.793660.726579@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326470209.17210.384.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 07/10] 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, 2012-01-13 at 15:47 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 07/10] libxl: New API for providing OS events to libxl"):
> > On Fri, 2012-01-06 at 20:35 +0000, Ian Jackson wrote:
> > Will any function even need to initialise their own egc and/or is it
> > normally provided by infrastructure code? Otherwise when should a
> > function initialise their own egc? Is it simply that you know if you
> > need to initialise one because you are calling a function which takes
> > one?
> 
> You don't need to because you should never end up calling a function
> that takes an egc unless you've got one already from the event
> machinery.

I think it is worth stating explicitly. e.g. "You should never need to
initialise an egc unless you are part of the event machinery itself,
Otherwise you will always be given an egc if you need one". I might even
go as far as s/should never/will never/.

> > > + * Even functions which generate specific kinds of events don't need
> > > + * to - rather, they will be passed an egc into their own callback
> > > + * function and should just use the one they're given.
> > > + *
> > > + * A handy idiom for functions taking an egc is:
> > > + *     libxl__gc *gc = &egc->gc;
> > 
> > You've provided lots of handy macros for other things like this, perhaps
> > EGC by comparison with CTX. Using GC seems better on the face of it but
> > since it will only work in a context with an egc that is actually
> > confusing.
> 
> How about:
>   #define EGC_GC  libxl__gc *gc = &egc->gc
> ?

Works for me.

> 
> > > + * Functions using LIBXL__INIT_EGC may *not* generally be called from
> > > + * within libxl, because libxl__egc_cleanup may call back into the
> > > + * application.  This should be documented near the function
> > > + * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
> > 
> > Can we also enforce/check this with a flag in the ctx? I guess not since
> > multiple threads might call into libxl with the same ctx and each may
> > legitimately setup an egc.?
> 
> Exactly.  This is the same disagreement I'm having with Stefano.
> 
> But this restriction is not difficult in practice because functions
> that want to generate events are almost[1] invariably functions which
> were themselves called in response to an OS event, and they get an egc
> provided by the event machinery.
> 
> See for example disk_eject_xswatch_callback, which is the thing which
> generates events of type DISK_EJECT.  It's a xenstore watch callback
> function, so it gets an egc provided by the event machinery and uses
> that for NEW_EVENT etc.
> 
> The code which sets up the callback, libxl_evenable_disk_eject,
> doesn't need an egc because setting up a callback only needs a gc.  So
> you never need to construct an egc yourself.
> 
> The functions which make their own egc, and which are therefore
> forbidden for other callers inside libxl, are things like
>    libxl_osevent_beforepoll
>    libxl_event_wait
> and if you're calling those from within libxl you are definitely doing
> the whole thing entirely wrong.
> 
> Ian.
> 
> [1] libxl__ao_inprogress is a counterexample, but it's part of the
> event machinery, not a normal function implementing some actual
> domain-related functionality.

Makes sense, I think the wording I proposed above describes this?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:00:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16: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 1RljXm-0002mv-UP; Fri, 13 Jan 2012 15:59:54 +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 1RljXl-0002lw-OR
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:59:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326470272!59601319!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 11724 invoked from network); 13 Jan 2012 15:57:52 -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; 13 Jan 2012 15:57:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 15:59:47 +0000
Message-Id: <4F10633D020000780006C8F4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 16:00:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
	<4F105DD1020000780006C8A5@nat28.tlf.novell.com>
	<4F105144.8070004@tycho.nsa.gov>
In-Reply-To: <4F105144.8070004@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.01.12 at 16:44, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/13/2012 10:37 AM, Jan Beulich wrote:
>>>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>> --- a/include/xen/xenbus_dev.h
>>>>> +++ b/include/xen/xenbus_dev.h
>>>>> @@ -38,4 +38,18 @@
>>>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>>>  
>>>>> +#define IOCTL_XENBUS_ALLOC				\
>>>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>>>> +struct ioctl_xenbus_alloc {
>>>>> +	/* IN */
>>>>> +	/* The domain ID (must exist) for xenstore */
>>>>> +	uint16_t dom;
>>>>> +	uint16_t pad;
>>>>> +	/* OUT */
>>>>> +	/* The port allocated for xenbus communication */
>>>>> +	uint32_t port;
>>>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>>>> +	uint32_t grant_ref;
>>>>> +};
>>>>
>>>> As said in my reply to the previous patch version - if the functionality
>>>> differs, the number *and* name should be different from the legacy
>>>> implementation's. Otherwise, how should compatible user space code
>>>> be written?
>>>>
>>>> Jan
>>>>
>>>
>>> This implementation has the same functionality as the legacy ioctl,
>> 
>> It doesn't - none of the "OUT" fields above exist there.
> 
> Are you looking at the same legacy ioctl as I am? I found it in 2.6.18.hg
> where the structure was defined as:
> 
> typedef struct xenbus_alloc {
>     domid_t dom;
>     __u32 port;
>     __u32 grant_ref;
> } xenbus_alloc_t;
> 
> The port and grant_ref fields were outputs. I added padding for clarity
> since domid_t is uint16_t.

Ooops, I'm sorry, indeed - I didn't look at the names and types
closely enough. They were too different, so I assumed the whole
thing is different.

That doesn't eliminate the difference between the two
IOCTL_XENBUS_ALLOC definitions, though
[_IOC(_IOC_NONE, 'X', 0, sizeof(xenbus_alloc_t)) vs
_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))] - one
still can't use both in the same source file.

Additionally (forgive if I'm not up to date in this respect) - is it okay
these days to use uintX_t in exported Linux headers, and then
without including the header that would define the necessary
types?

Jan

>>> although it has a different number and is performed on a different file,
>>> so it is already impossible to make automatically compatible userspace
>>> code.
>> 
>> That's not what I was aiming at. The problem you're introducing is
>> that you name the ioctl IOCTL_XENBUS_ALLOC, identical to what
>> the legacy code named it. Hence one won't be able to write user
>> mode code to invoke, depending on runtime determination, either
>> the old or the new function.
>> 
>> Jan
>> 
>>> The structure name was changed to match other ioctl arguments, but
>>> the contents should be the same as in the legacy ioctl. If changing what
>>> file the ioctl is performed on justifies changing the ioctl name, then I
>>> would prefer the simpler interface where the domain ID is passed in as the
>>> ioctl parameter instead of a structure that only has one useful output.
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:00:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16: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 1RljXm-0002mv-UP; Fri, 13 Jan 2012 15:59:54 +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 1RljXl-0002lw-OR
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 15:59:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326470272!59601319!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 11724 invoked from network); 13 Jan 2012 15:57:52 -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; 13 Jan 2012 15:57:52 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 13 Jan 2012 15:59:47 +0000
Message-Id: <4F10633D020000780006C8F4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 13 Jan 2012 16:00:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
	<4F105DD1020000780006C8A5@nat28.tlf.novell.com>
	<4F105144.8070004@tycho.nsa.gov>
In-Reply-To: <4F105144.8070004@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.01.12 at 16:44, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/13/2012 10:37 AM, Jan Beulich wrote:
>>>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>> --- a/include/xen/xenbus_dev.h
>>>>> +++ b/include/xen/xenbus_dev.h
>>>>> @@ -38,4 +38,18 @@
>>>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>>>  
>>>>> +#define IOCTL_XENBUS_ALLOC				\
>>>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>>>> +struct ioctl_xenbus_alloc {
>>>>> +	/* IN */
>>>>> +	/* The domain ID (must exist) for xenstore */
>>>>> +	uint16_t dom;
>>>>> +	uint16_t pad;
>>>>> +	/* OUT */
>>>>> +	/* The port allocated for xenbus communication */
>>>>> +	uint32_t port;
>>>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>>>> +	uint32_t grant_ref;
>>>>> +};
>>>>
>>>> As said in my reply to the previous patch version - if the functionality
>>>> differs, the number *and* name should be different from the legacy
>>>> implementation's. Otherwise, how should compatible user space code
>>>> be written?
>>>>
>>>> Jan
>>>>
>>>
>>> This implementation has the same functionality as the legacy ioctl,
>> 
>> It doesn't - none of the "OUT" fields above exist there.
> 
> Are you looking at the same legacy ioctl as I am? I found it in 2.6.18.hg
> where the structure was defined as:
> 
> typedef struct xenbus_alloc {
>     domid_t dom;
>     __u32 port;
>     __u32 grant_ref;
> } xenbus_alloc_t;
> 
> The port and grant_ref fields were outputs. I added padding for clarity
> since domid_t is uint16_t.

Ooops, I'm sorry, indeed - I didn't look at the names and types
closely enough. They were too different, so I assumed the whole
thing is different.

That doesn't eliminate the difference between the two
IOCTL_XENBUS_ALLOC definitions, though
[_IOC(_IOC_NONE, 'X', 0, sizeof(xenbus_alloc_t)) vs
_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))] - one
still can't use both in the same source file.

Additionally (forgive if I'm not up to date in this respect) - is it okay
these days to use uintX_t in exported Linux headers, and then
without including the header that would define the necessary
types?

Jan

>>> although it has a different number and is performed on a different file,
>>> so it is already impossible to make automatically compatible userspace
>>> code.
>> 
>> That's not what I was aiming at. The problem you're introducing is
>> that you name the ioctl IOCTL_XENBUS_ALLOC, identical to what
>> the legacy code named it. Hence one won't be able to write user
>> mode code to invoke, depending on runtime determination, either
>> the old or the new function.
>> 
>> Jan
>> 
>>> The structure name was changed to match other ioctl arguments, but
>>> the contents should be the same as in the legacy ioctl. If changing what
>>> file the ioctl is performed on justifies changing the ioctl name, then I
>>> would prefer the simpler interface where the domain ID is passed in as the
>>> ioctl parameter instead of a structure that only has one useful output.
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:12:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16: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 1Rljk1-0004Ff-IZ; Fri, 13 Jan 2012 16:12:33 +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 1Rljjz-0004Ez-Fu
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:12:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326470333!3074536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6070 invoked from network); 13 Jan 2012 15:58:53 -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;
	13 Jan 2012 15:58:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10006401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:58: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, 13 Jan 2012 15:58: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
	1RljWm-0004bK-F7; Fri, 13 Jan 2012 15:58:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RljWm-00047U-EE;
	Fri, 13 Jan 2012 15:58:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.21692.428487.238187@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:58:52 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326451417.17210.312.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-6-git-send-email-ian.jackson@eu.citrix.com>
	<1326451417.17210.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] [PATCH 05/10] libxl: Fix leaks on context init
 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 05/10] libxl: Fix leaks on context init failure"):
> Aside: we really ought to have been cranking this number and probably
> the SONAME too. 4.2 should definitely differ from 4.1 in at least one of
> those, if not both. 

Makefile's MAJOR has already been updated AFAICT:

  commit 8d3cedd3b6719d1a1f4a962f4ffece1355d77642
  Author: Ian Campbell <ian.campbell@citrix.com>
  Date:   Fri Apr 8 16:17:18 2011 +0100

      libxl: bump SONAME after binary incompatible change.

mariner:libxl> git-describe --tags 8d3cedd3
4.1.0-branched-212-g8d3cedd
mariner:libxl>

I'm not sure the version checking stuff in libxl_init serves any
useful function.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:12:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16: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 1Rljk1-0004Ff-IZ; Fri, 13 Jan 2012 16:12:33 +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 1Rljjz-0004Ez-Fu
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:12:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326470333!3074536!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6070 invoked from network); 13 Jan 2012 15:58:53 -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;
	13 Jan 2012 15:58:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,504,1320624000"; d="scan'208";a="10006401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 15:58: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, 13 Jan 2012 15:58: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
	1RljWm-0004bK-F7; Fri, 13 Jan 2012 15:58:52 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RljWm-00047U-EE;
	Fri, 13 Jan 2012 15:58:52 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.21692.428487.238187@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 15:58:52 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326451417.17210.312.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-6-git-send-email-ian.jackson@eu.citrix.com>
	<1326451417.17210.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] [PATCH 05/10] libxl: Fix leaks on context init
 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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 05/10] libxl: Fix leaks on context init failure"):
> Aside: we really ought to have been cranking this number and probably
> the SONAME too. 4.2 should definitely differ from 4.1 in at least one of
> those, if not both. 

Makefile's MAJOR has already been updated AFAICT:

  commit 8d3cedd3b6719d1a1f4a962f4ffece1355d77642
  Author: Ian Campbell <ian.campbell@citrix.com>
  Date:   Fri Apr 8 16:17:18 2011 +0100

      libxl: bump SONAME after binary incompatible change.

mariner:libxl> git-describe --tags 8d3cedd3
4.1.0-branched-212-g8d3cedd
mariner:libxl>

I'm not sure the version checking stuff in libxl_init serves any
useful function.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:24:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rljv4-0004f1-OL; Fri, 13 Jan 2012 16:23:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rljv3-0004ew-SV
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:23:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326471831!2365277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7526 invoked from network); 13 Jan 2012 16:23:52 -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;
	13 Jan 2012 16:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10007834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 16:23: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, 13 Jan 2012 16:23: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
	1Rljux-0004ju-Hw; Fri, 13 Jan 2012 16:23:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rljux-000778-Eo;
	Fri, 13 Jan 2012 16:23:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.23191.350857.897559@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:23:51 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326461958.17210.350.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326451270.17210.310.camel@zakaz.uk.xensource.com>
	<20240.13232.920698.590180@mariner.uk.xensource.com>
	<1326461958.17210.350.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 03/10] libxl: move a lot more includes into
 libxl_internal.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 03/10] libxl: move a lot more includes into libxl_internal.h"):
> On Fri, 2012-01-13 at 13:37 +0000, Ian Jackson wrote:
> > So I think this is a more obvious way to do it, even though it's an
> > extra #include line in each file.
> 
> Sure, that fine.
>
> I suppose using -include (or whatever its real name is) on the compiler
> command line is too skanky?

Personally I think that's a very annoying hack and should be avoided.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:24:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:24:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rljv4-0004f1-OL; Fri, 13 Jan 2012 16:23:58 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rljv3-0004ew-SV
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:23:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326471831!2365277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7526 invoked from network); 13 Jan 2012 16:23:52 -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;
	13 Jan 2012 16:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10007834"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 16:23: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, 13 Jan 2012 16:23: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
	1Rljux-0004ju-Hw; Fri, 13 Jan 2012 16:23:51 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rljux-000778-Eo;
	Fri, 13 Jan 2012 16:23:51 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.23191.350857.897559@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:23:51 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326461958.17210.350.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326451270.17210.310.camel@zakaz.uk.xensource.com>
	<20240.13232.920698.590180@mariner.uk.xensource.com>
	<1326461958.17210.350.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 03/10] libxl: move a lot more includes into
 libxl_internal.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 03/10] libxl: move a lot more includes into libxl_internal.h"):
> On Fri, 2012-01-13 at 13:37 +0000, Ian Jackson wrote:
> > So I think this is a more obvious way to do it, even though it's an
> > extra #include line in each file.
> 
> Sure, that fine.
>
> I suppose using -include (or whatever its real name is) on the compiler
> command line is too skanky?

Personally I think that's a very annoying hack and should be avoided.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:34:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlk4z-0004tG-2b; Fri, 13 Jan 2012 16:34: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 1Rlk4x-0004t8-Fs
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:34:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326472445!9046446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3318 invoked from network); 13 Jan 2012 16:34:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:34:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10008255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 16:34: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, 13 Jan 2012 16:34: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
	1Rlk4q-0004nF-Et; Fri, 13 Jan 2012 16:34:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlk4q-00011B-CE;
	Fri, 13 Jan 2012 16:34:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.23804.363173.486114@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:34:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326470209.17210.384.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<1326467245.17210.374.camel@zakaz.uk.xensource.com>
	<20240.21033.793660.726579@mariner.uk.xensource.com>
	<1326470209.17210.384.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 07/10] 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 07/10] libxl: New API for providing OS events to libxl"):
> I think it is worth stating explicitly. e.g. "You should never need to
> initialise an egc unless you are part of the event machinery itself,
> Otherwise you will always be given an egc if you need one". I might even
> go as far as s/should never/will never/.

Right, that's good wording, thanks.

> > How about:
> >   #define EGC_GC  libxl__gc *gc = &egc->gc
> > ?
> 
> Works for me.

I will do this.

> > The functions which make their own egc, and which are therefore
> > forbidden for other callers inside libxl, are things like
> >    libxl_osevent_beforepoll
> >    libxl_event_wait
> > and if you're calling those from within libxl you are definitely doing
> > the whole thing entirely wrong.
...
> Makes sense, I think the wording I proposed above describes this?

Right.

Ian.

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e03a5d6..c50c058 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -967,10 +967,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * call libxl__event_occurred.  These contain a gc but also a list of
  * deferred events.
  *
- * Most code in libxl should not need to initialise their own egc.
- * Even functions which generate specific kinds of events don't need
- * to - rather, they will be passed an egc into their own callback
- * function and should just use the one they're given.
+ * You should never need to initialise an egc unless you are part of
+ * the event machinery itself.  Otherwise you will always be given an
+ * egc if you need one.  Even functions which generate specific kinds
+ * of events don't need to - rather, they will be passed an egc into
+ * their own callback function and should just use the one they're
+ * given.
  *
  * A handy idiom for functions taking an egc is:
  *     libxl__gc *gc = &egc->gc;
@@ -978,7 +980,9 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
  * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
+ * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
+ * should in any case not find it necessary to call egc-creators from
+ * within libxl.
  *
  * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
  * with the ctx *unlocked*.  So the right pattern has the EGC_...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:34:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlk4z-0004tG-2b; Fri, 13 Jan 2012 16:34: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 1Rlk4x-0004t8-Fs
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:34:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326472445!9046446!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3318 invoked from network); 13 Jan 2012 16:34:05 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:34:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10008255"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 16:34: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, 13 Jan 2012 16:34: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
	1Rlk4q-0004nF-Et; Fri, 13 Jan 2012 16:34:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlk4q-00011B-CE;
	Fri, 13 Jan 2012 16:34:04 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.23804.363173.486114@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:34:04 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326470209.17210.384.camel@zakaz.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1325882107-5794-8-git-send-email-ian.jackson@eu.citrix.com>
	<1326467245.17210.374.camel@zakaz.uk.xensource.com>
	<20240.21033.793660.726579@mariner.uk.xensource.com>
	<1326470209.17210.384.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 07/10] 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 07/10] libxl: New API for providing OS events to libxl"):
> I think it is worth stating explicitly. e.g. "You should never need to
> initialise an egc unless you are part of the event machinery itself,
> Otherwise you will always be given an egc if you need one". I might even
> go as far as s/should never/will never/.

Right, that's good wording, thanks.

> > How about:
> >   #define EGC_GC  libxl__gc *gc = &egc->gc
> > ?
> 
> Works for me.

I will do this.

> > The functions which make their own egc, and which are therefore
> > forbidden for other callers inside libxl, are things like
> >    libxl_osevent_beforepoll
> >    libxl_event_wait
> > and if you're calling those from within libxl you are definitely doing
> > the whole thing entirely wrong.
...
> Makes sense, I think the wording I proposed above describes this?

Right.

Ian.

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index e03a5d6..c50c058 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -967,10 +967,12 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * call libxl__event_occurred.  These contain a gc but also a list of
  * deferred events.
  *
- * Most code in libxl should not need to initialise their own egc.
- * Even functions which generate specific kinds of events don't need
- * to - rather, they will be passed an egc into their own callback
- * function and should just use the one they're given.
+ * You should never need to initialise an egc unless you are part of
+ * the event machinery itself.  Otherwise you will always be given an
+ * egc if you need one.  Even functions which generate specific kinds
+ * of events don't need to - rather, they will be passed an egc into
+ * their own callback function and should just use the one they're
+ * given.
  *
  * A handy idiom for functions taking an egc is:
  *     libxl__gc *gc = &egc->gc;
@@ -978,7 +980,9 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
  * Functions using LIBXL__INIT_EGC may *not* generally be called from
  * within libxl, because libxl__egc_cleanup may call back into the
  * application.  This should be documented near the function
- * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.
+ * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
+ * should in any case not find it necessary to call egc-creators from
+ * within libxl.
  *
  * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
  * with the ctx *unlocked*.  So the right pattern has the EGC_...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkG8-00053g-AY; Fri, 13 Jan 2012 16:45:44 +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 1RlkG6-00053b-JW
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:45:42 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326473135!8503525!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 29701 invoked from network); 13 Jan 2012 16:45:35 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	13 Jan 2012 16:45:35 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.116.148])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74491778; Fri, 13 Jan 2012 17:45:34 +0100
Message-ID: <1326473132.2397.6.camel@Abyss.citrite.net>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 16:45:32 +0000
In-Reply-To: <20240.13002.205604.969404@mariner.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2679979749121524515=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2679979749121524515==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ic2JxjRKPN7iK70wqW92"


--=-ic2JxjRKPN7iK70wqW92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-13 at 13:34 +0000, Ian Jackson wrote:=20
> Oops, sorry for wrongly pointing the finger.
>=20
NP. :-)

> > That being said, if you think I should rewrite the parsing from scratch=
,
> > I can think about it, just wanted to clarify my position. :-)
>=20
> I really don't like the existing code here; feel free to do whatever
> you think is best.
>=20
Ok, I'm not really a "string parsing guy" but I'm interested in getting
better. I can try restructuring this with strtok_r and strdup... Would
that be better or you where thinking to something more "radical"?

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)



--=-ic2JxjRKPN7iK70wqW92
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)

iEYEABECAAYFAk8QX6wACgkQk4XaBE3IOsQmwACgnzNF68a3+tqEuq/aibDzAwbW
S7wAoK1QENObdTZN8ezRKVETns0Lc9+Q
=tSs7
-----END PGP SIGNATURE-----

--=-ic2JxjRKPN7iK70wqW92--



--===============2679979749121524515==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2679979749121524515==--



From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkG8-00053g-AY; Fri, 13 Jan 2012 16:45:44 +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 1RlkG6-00053b-JW
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:45:42 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326473135!8503525!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 29701 invoked from network); 13 Jan 2012 16:45:35 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	13 Jan 2012 16:45:35 -0000
Received: from [62.200.22.2] (account d.faggioli@sssup.it HELO [10.80.116.148])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74491778; Fri, 13 Jan 2012 17:45:34 +0100
Message-ID: <1326473132.2397.6.camel@Abyss.citrite.net>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 16:45:32 +0000
In-Reply-To: <20240.13002.205604.969404@mariner.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2679979749121524515=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2679979749121524515==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ic2JxjRKPN7iK70wqW92"


--=-ic2JxjRKPN7iK70wqW92
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-13 at 13:34 +0000, Ian Jackson wrote:=20
> Oops, sorry for wrongly pointing the finger.
>=20
NP. :-)

> > That being said, if you think I should rewrite the parsing from scratch=
,
> > I can think about it, just wanted to clarify my position. :-)
>=20
> I really don't like the existing code here; feel free to do whatever
> you think is best.
>=20
Ok, I'm not really a "string parsing guy" but I'm interested in getting
better. I can try restructuring this with strtok_r and strdup... Would
that be better or you where thinking to something more "radical"?

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)



--=-ic2JxjRKPN7iK70wqW92
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)

iEYEABECAAYFAk8QX6wACgkQk4XaBE3IOsQmwACgnzNF68a3+tqEuq/aibDzAwbW
S7wAoK1QENObdTZN8ezRKVETns0Lc9+Q
=tSs7
-----END PGP SIGNATURE-----

--=-ic2JxjRKPN7iK70wqW92--



--===============2679979749121524515==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2679979749121524515==--



From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:49:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:49:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkJF-00059v-VA; Fri, 13 Jan 2012 16:48:57 +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 1RlkJE-00059j-Fi
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:48:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326473330!10944779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19519 invoked from network); 13 Jan 2012 16:48:50 -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 Jan 2012 16:48:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10009071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 16:48: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, 13 Jan 2012 16:48: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
	1RlkJ7-0004w6-TS; Fri, 13 Jan 2012 16:48:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlkJ7-00041r-RY;
	Fri, 13 Jan 2012 16:48:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.24689.833215.133892@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:48:49 +0000
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1326473132.2397.6.camel@Abyss.citrite.net>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.com>
	<1326473132.2397.6.camel@Abyss.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for vcpu-pin."):
> Ok, I'm not really a "string parsing guy" but I'm interested in getting
> better. I can try restructuring this with strtok_r and strdup... Would
> that be better or you where thinking to something more "radical"?

Personally I'm a fan of flex although it's probably overkill for
this.  But you should use an approach your comfortable with.

What I care most about is that whatever approach you take doesn't make
it too easy to make and hide :-) programming mistakes, since otherwise
parsing code often turns out to be buggy.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:49:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:49:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkJF-00059v-VA; Fri, 13 Jan 2012 16:48:57 +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 1RlkJE-00059j-Fi
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:48:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326473330!10944779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19519 invoked from network); 13 Jan 2012 16:48:50 -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 Jan 2012 16:48:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10009071"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 16:48: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, 13 Jan 2012 16:48: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
	1RlkJ7-0004w6-TS; Fri, 13 Jan 2012 16:48:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlkJ7-00041r-RY;
	Fri, 13 Jan 2012 16:48:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.24689.833215.133892@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:48:49 +0000
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1326473132.2397.6.camel@Abyss.citrite.net>
References: <1326304198.2401.6.camel@Abyss> <1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.com>
	<1326473132.2397.6.camel@Abyss.citrite.net>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for vcpu-pin."):
> Ok, I'm not really a "string parsing guy" but I'm interested in getting
> better. I can try restructuring this with strtok_r and strdup... Would
> that be better or you where thinking to something more "radical"?

Personally I'm a fan of flex although it's probably overkill for
this.  But you should use an approach your comfortable with.

What I care most about is that whatever approach you take doesn't make
it too easy to make and hide :-) programming mistakes, since otherwise
parsing code often turns out to be buggy.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:50:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16: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 1RlkKj-0005Fg-G0; Fri, 13 Jan 2012 16:50:29 +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 1RlkKi-0005FL-KH
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:50:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326473422!8746164!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14748 invoked from network); 13 Jan 2012 16:50:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:50:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10009105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 16:50: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, 13 Jan 2012 16:50: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
	1RlkKc-0004wp-2v	for xen-devel@lists.xensource.com;
	Fri, 13 Jan 2012 16:50:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlkKb-0004G2-94	for
	xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:50:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.24780.544091.950722@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:50:20 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH].gitignore: ocaml: add xenlight.mli
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 will be committing this shortly.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] .gitignore: ocaml: add xenlight.mli

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 625ceee..297191e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -359,6 +359,7 @@ tools/ocaml/libs/xl/_libxl_types.inc
 tools/ocaml/libs/xl/_libxl_types.ml.in
 tools/ocaml/libs/xl/_libxl_types.mli.in
 tools/ocaml/libs/xl/xenlight.ml
+tools/ocaml/libs/xl/xenlight.mli
 tools/ocaml/xenstored/oxenstored
 
 tools/debugger/kdd/kdd
-- 
tg: (c16a79f..) t/xen/gitignore (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:50:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16: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 1RlkKj-0005Fg-G0; Fri, 13 Jan 2012 16:50:29 +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 1RlkKi-0005FL-KH
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:50:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326473422!8746164!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14748 invoked from network); 13 Jan 2012 16:50:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:50:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10009105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 16:50: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, 13 Jan 2012 16:50: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
	1RlkKc-0004wp-2v	for xen-devel@lists.xensource.com;
	Fri, 13 Jan 2012 16:50:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RlkKb-0004G2-94	for
	xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:50:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.24780.544091.950722@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 16:50:20 +0000
To: xen-devel@lists.xensource.com
X-Mailer: VM 7.19 under Emacs 21.4.1
Subject: [Xen-devel] [PATCH].gitignore: ocaml: add xenlight.mli
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 will be committing this shortly.

Ian.

From: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [PATCH] .gitignore: ocaml: add xenlight.mli

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index 625ceee..297191e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -359,6 +359,7 @@ tools/ocaml/libs/xl/_libxl_types.inc
 tools/ocaml/libs/xl/_libxl_types.ml.in
 tools/ocaml/libs/xl/_libxl_types.mli.in
 tools/ocaml/libs/xl/xenlight.ml
+tools/ocaml/libs/xl/xenlight.mli
 tools/ocaml/xenstored/oxenstored
 
 tools/debugger/kdd/kdd
-- 
tg: (c16a79f..) t/xen/gitignore (depends on: base)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:58:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16: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 1RlkSA-0005Z2-FL; Fri, 13 Jan 2012 16:58:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tinnycloud@hotmail.com>) id 1RlkS8-0005Yt-V1
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:58:09 +0000
X-Env-Sender: tinnycloud@hotmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326473882!10327092!1
X-Originating-IP: [65.55.111.85]
X-SpamReason: No, hits=0.2 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21303 invoked from network); 13 Jan 2012 16:58:02 -0000
Received: from blu0-omc2-s10.blu0.hotmail.com (HELO
	blu0-omc2-s10.blu0.hotmail.com) (65.55.111.85)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Jan 2012 16:58:02 -0000
Received: from BLU157-W29 ([65.55.111.72]) by blu0-omc2-s10.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 13 Jan 2012 08:58:01 -0800
Message-ID: <BLU157-W29E1907385E28747487E44DA9C0@phx.gbl>
X-Originating-IP: [125.118.65.148]
From: MaoXiaoyun <tinnycloud@hotmail.com>
To: xen devel <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 00:58:01 +0800
Importance: Normal
In-Reply-To: <mailman.161.1326471838.1471.xen-devel@lists.xensource.com>
References: <mailman.161.1326471838.1471.xen-devel@lists.xensource.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Jan 2012 16:58:01.0885 (UTC)
	FILETIME=[82947CD0:01CCD214]
Subject: [Xen-devel] How many block device in domU supports?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6692420954063396928=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6692420954063396928==
Content-Type: multipart/alternative;
	boundary="_81ea03d4-0f46-4d63-9ab9-d2a26e075233_"

--_81ea03d4-0f46-4d63-9ab9-d2a26e075233_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit


Hi:
  
       I've been thought this for a while, I want to build 1000 linux containeres in a HVM, 
and each container owns 1 block device, so there will 1000 tapdev and 1000 tapdisk
process.
 
       My question is
       1. How many devices domU support?
       2. How many tapdev device blktap2 support?
       3, Would it be a performance issue in this case?
       4. Basically, I want each container's data is write to different VHD file, since 
           it is convenient to transfer data. For ex. I can use this VHD to start a new VM.
 
       Any comments or any other better idea?
 
       thanks. 		 	   		  
--_81ea03d4-0f46-4d63-9ab9-d2a26e075233_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Hi:<BR>
&nbsp; <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I've been thought this for a while, I want to build 1000 linux containeres in a HVM, <BR>
and each container owns 1 block device, so there will 1000 tapdev and 1000 tapdisk<BR>
process.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; My question is<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. How many devices domU support?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2. How many tapdev device blktap2 support?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3, Would it be a performance issue in this case?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4. Basically, I want each container's data is write to different VHD file, since <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it is convenient&nbsp;to transfer data. For ex. I can use this VHD to start a new VM.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any comments or any other better idea?<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;thanks.<BR> 		 	   		  </div></body>
</html>
--_81ea03d4-0f46-4d63-9ab9-d2a26e075233_--


--===============6692420954063396928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6692420954063396928==--


From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:58:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16: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 1RlkSA-0005Z2-FL; Fri, 13 Jan 2012 16:58:10 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tinnycloud@hotmail.com>) id 1RlkS8-0005Yt-V1
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:58:09 +0000
X-Env-Sender: tinnycloud@hotmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326473882!10327092!1
X-Originating-IP: [65.55.111.85]
X-SpamReason: No, hits=0.2 required=7.0 tests=FORGED_HOTMAIL_RCVD,
	HTML_50_60, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_12, ML_RADAR_SPEW_LINKS_14,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21303 invoked from network); 13 Jan 2012 16:58:02 -0000
Received: from blu0-omc2-s10.blu0.hotmail.com (HELO
	blu0-omc2-s10.blu0.hotmail.com) (65.55.111.85)
	by server-13.tower-216.messagelabs.com with SMTP;
	13 Jan 2012 16:58:02 -0000
Received: from BLU157-W29 ([65.55.111.72]) by blu0-omc2-s10.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Fri, 13 Jan 2012 08:58:01 -0800
Message-ID: <BLU157-W29E1907385E28747487E44DA9C0@phx.gbl>
X-Originating-IP: [125.118.65.148]
From: MaoXiaoyun <tinnycloud@hotmail.com>
To: xen devel <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 00:58:01 +0800
Importance: Normal
In-Reply-To: <mailman.161.1326471838.1471.xen-devel@lists.xensource.com>
References: <mailman.161.1326471838.1471.xen-devel@lists.xensource.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 13 Jan 2012 16:58:01.0885 (UTC)
	FILETIME=[82947CD0:01CCD214]
Subject: [Xen-devel] How many block device in domU supports?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6692420954063396928=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6692420954063396928==
Content-Type: multipart/alternative;
	boundary="_81ea03d4-0f46-4d63-9ab9-d2a26e075233_"

--_81ea03d4-0f46-4d63-9ab9-d2a26e075233_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit


Hi:
  
       I've been thought this for a while, I want to build 1000 linux containeres in a HVM, 
and each container owns 1 block device, so there will 1000 tapdev and 1000 tapdisk
process.
 
       My question is
       1. How many devices domU support?
       2. How many tapdev device blktap2 support?
       3, Would it be a performance issue in this case?
       4. Basically, I want each container's data is write to different VHD file, since 
           it is convenient to transfer data. For ex. I can use this VHD to start a new VM.
 
       Any comments or any other better idea?
 
       thanks. 		 	   		  
--_81ea03d4-0f46-4d63-9ab9-d2a26e075233_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:΢ÈíÑźÚ
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
Hi:<BR>
&nbsp; <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I've been thought this for a while, I want to build 1000 linux containeres in a HVM, <BR>
and each container owns 1 block device, so there will 1000 tapdev and 1000 tapdisk<BR>
process.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; My question is<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. How many devices domU support?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2. How many tapdev device blktap2 support?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3, Would it be a performance issue in this case?<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4. Basically, I want each container's data is write to different VHD file, since <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it is convenient&nbsp;to transfer data. For ex. I can use this VHD to start a new VM.<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any comments or any other better idea?<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;thanks.<BR> 		 	   		  </div></body>
</html>
--_81ea03d4-0f46-4d63-9ab9-d2a26e075233_--


--===============6692420954063396928==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6692420954063396928==--


From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTk-0005gS-IP; Fri, 13 Jan 2012 16:59:48 +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 1RlkTi-0005dM-9M
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326473974!10818882!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6652 invoked from network); 13 Jan 2012 16:59:39 -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;
	13 Jan 2012 16:59:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="177465197"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 11:59:37 -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 q0DGxQEG016212;
	Fri, 13 Jan 2012 08:59:36 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:08 +0000
Message-ID: <1326473949-22389-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 5/6] netback: melt xen_netbk into xenvif
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, there is no need to keep xen_netbk and xenvif
separated.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   58 ++++++--
 drivers/net/xen-netback/interface.c |   35 ++---
 drivers/net/xen-netback/netback.c   |  279 ++++++++++++-----------------------
 drivers/net/xen-netback/page_pool.c |   10 +-
 drivers/net/xen-netback/page_pool.h |   10 +-
 5 files changed, 166 insertions(+), 226 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 1f6156d..6b99246 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,16 +45,34 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
-struct xen_netbk;
+#include "page_pool.h"
+
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+};
+typedef unsigned int pending_ring_idx_t;
+
+struct netbk_rx_meta {
+	int id;
+	int size;
+	int gso_size;
+};
+
+#define MAX_PENDING_REQS 256
+
+/* Discriminate from any valid pending_idx value. */
+#define INVALID_PENDING_IDX 0xFFFF
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
-	/* Reference to netback processing backend. */
-	struct xen_netbk *netbk;
-
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -97,6 +115,27 @@ struct xenvif {
 
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
+
+	struct sk_buff_head rx_queue;
+	struct sk_buff_head tx_queue;
+
+	idx_t mmap_pages[MAX_PENDING_REQS];
+
+	pending_ring_idx_t pending_prod;
+	pending_ring_idx_t pending_cons;
+
+	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
+	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
+
+	u16 pending_ring[MAX_PENDING_REQS];
+
+	/*
+	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
+	 * head/fragment page uses 2 copy operations because it
+	 * straddles two buffers in the frontend.
+	 */
+	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
+	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -104,9 +143,6 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
@@ -143,12 +179,8 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-/* Allocate and free xen_netbk structure */
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
-void xen_netbk_free_netbk(struct xen_netbk *netbk);
-
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
-void xen_netbk_rx_action(struct xen_netbk *netbk);
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
+void xen_netbk_rx_action(struct xenvif *vif);
 
 int xen_netbk_kthread(void *data);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 3126028..69184d1 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -55,7 +55,7 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (vif->netbk == NULL)
+	if (vif->task == NULL)
 		return IRQ_NONE;
 
 	if (xenvif_rx_schedulable(vif))
@@ -72,7 +72,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+	xen_netbk_tx_action(vif, &work_done, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -95,9 +95,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	BUG_ON(skb->dev != dev);
 
-	if (vif->netbk == NULL)
-		goto drop;
-
 	/* Drop the packet if the target domain has no receive buffers. */
 	if (!xenvif_rx_schedulable(vif))
 		goto drop;
@@ -257,6 +254,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	int err;
 	struct net_device *dev;
 	struct xenvif *vif;
+	int i;
 	char name[IFNAMSIZ] = {};
 
 	snprintf(name, IFNAMSIZ - 1, "vif%u.%u", domid, handle);
@@ -271,7 +269,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk = NULL;
 
 	vif->can_sg = 1;
 	vif->csum = 1;
@@ -290,6 +287,17 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 
 	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
 
+	skb_queue_head_init(&vif->rx_queue);
+	skb_queue_head_init(&vif->tx_queue);
+
+	vif->pending_cons = 0;
+	vif->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->mmap_pages[i] = INVALID_ENTRY;
+
 	/*
 	 * Initialise a dummy MAC address. We choose the numerically
 	 * largest non-broadcast address to prevent the address getting
@@ -337,14 +345,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	vif->netbk = xen_netbk_alloc_netbk(vif);
-	if (!vif->netbk) {
-		pr_warn("Could not allocate xen_netbk\n");
-		err = -ENOMEM;
-		goto err_unbind;
-	}
-
-
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xen_netbk_kthread,
 				   (void *)vif,
@@ -352,7 +352,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (IS_ERR(vif->task)) {
 		pr_warn("Could not create kthread\n");
 		err = PTR_ERR(vif->task);
-		goto err_free_netbk;
+		goto err_unbind;
 	}
 
 	rtnl_lock();
@@ -367,8 +367,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	wake_up_process(vif->task);
 
 	return 0;
-err_free_netbk:
-	xen_netbk_free_netbk(vif->netbk);
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
@@ -392,9 +390,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	if (vif->task)
 		kthread_stop(vif->task);
 
-	if (vif->netbk)
-		xen_netbk_free_netbk(vif->netbk);
-
 	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index e486fd6..133ebb3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -47,57 +47,13 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-};
-typedef unsigned int pending_ring_idx_t;
-
-struct netbk_rx_meta {
-	int id;
-	int size;
-	int gso_size;
-};
-
-#define MAX_PENDING_REQS 256
-
-/* Discriminate from any valid pending_idx value. */
-#define INVALID_PENDING_IDX 0xFFFF
-
-#define MAX_BUFFER_OFFSET PAGE_SIZE
-
-struct xen_netbk {
-	struct sk_buff_head rx_queue;
-	struct sk_buff_head tx_queue;
-
-	idx_t mmap_pages[MAX_PENDING_REQS];
-
-	pending_ring_idx_t pending_prod;
-	pending_ring_idx_t pending_cons;
-	struct list_head net_schedule_list;
-
-	struct xenvif *vif;
-
-	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
-	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
-
-	u16 pending_ring[MAX_PENDING_REQS];
-
-	/*
-	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
-	 * head/fragment page uses 2 copy operations because it
-	 * straddles two buffers in the frontend.
-	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
-};
-
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
 
-static inline int tx_work_todo(struct xen_netbk *netbk);
-static inline int rx_work_todo(struct xen_netbk *netbk);
+static inline int tx_work_todo(struct xenvif *vif);
+static inline int rx_work_todo(struct xenvif *vif);
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
@@ -106,16 +62,16 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      size,
 					     u16      flags);
 
-static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
+static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
-	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
+	return page_to_pfn(to_page(vif->mmap_pages[idx]));
 }
 
-static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
+static inline unsigned long idx_to_kaddr(struct xenvif *vif,
 					 u16 idx)
 {
-	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
+	return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
 }
 
 /*
@@ -143,10 +99,10 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 	return i & (MAX_PENDING_REQS-1);
 }
 
-static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
+static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 {
 	return MAX_PENDING_REQS -
-		netbk->pending_prod + netbk->pending_cons;
+		vif->pending_prod + vif->pending_cons;
 }
 
 static int max_required_rx_slots(struct xenvif *vif)
@@ -332,12 +288,12 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = to_netbk(idx);
+			struct xenvif *vif = to_vif(idx);
 			struct pending_tx_info *src_pend;
 
-			src_pend = &netbk->pending_tx_info[idx];
+			src_pend = &vif->pending_tx_info[idx];
 
-			copy_gop->source.domid = netbk->vif->domid;
+			copy_gop->source.domid = vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -495,16 +451,13 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xenvif *vif)
 {
-	struct xenvif *vif = netbk->vif;
-
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xen_netbk *netbk)
+void xen_netbk_rx_action(struct xenvif *vif)
 {
-	struct xenvif *vif = NULL;
 	s8 status;
 	u16 flags;
 	struct xen_netif_rx_response *resp;
@@ -519,15 +472,15 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
-		.copy  = netbk->grant_copy_op,
-		.meta  = netbk->meta,
+		.copy  = vif->grant_copy_op,
+		.meta  = vif->meta,
 	};
 
 	skb_queue_head_init(&rxq);
 
 	count = 0;
 
-	while ((skb = skb_dequeue(&netbk->rx_queue)) != NULL) {
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
 		vif = netdev_priv(skb->dev);
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
@@ -543,29 +496,29 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			break;
 	}
 
-	BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
+	BUG_ON(npo.meta_prod > ARRAY_SIZE(vif->meta));
 
 	if (!npo.copy_prod)
 		return;
 
-	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
+	BUG_ON(npo.copy_prod > ARRAY_SIZE(vif->grant_copy_op));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &vif->grant_copy_op,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
 
 	while ((skb = __skb_dequeue(&rxq)) != NULL) {
 		sco = (struct skb_cb_overlay *)skb->cb;
 
-		vif = netdev_priv(skb->dev);
+		/* vif = netdev_priv(skb->dev); */
 
-		if (netbk->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
+		if (vif->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
 
 			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
 
-			resp->offset = netbk->meta[npo.meta_cons].gso_size;
-			resp->id = netbk->meta[npo.meta_cons].id;
+			resp->offset = vif->meta[npo.meta_cons].gso_size;
+			resp->id = vif->meta[npo.meta_cons].id;
 			resp->status = sco->meta_slots_used;
 
 			npo.meta_cons++;
@@ -590,12 +543,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			flags |= XEN_NETRXF_data_validated;
 
 		offset = 0;
-		resp = make_rx_response(vif, netbk->meta[npo.meta_cons].id,
+		resp = make_rx_response(vif, vif->meta[npo.meta_cons].id,
 					status, offset,
-					netbk->meta[npo.meta_cons].size,
+					vif->meta[npo.meta_cons].size,
 					flags);
 
-		if (netbk->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
+		if (vif->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
 			struct xen_netif_extra_info *gso =
 				(struct xen_netif_extra_info *)
 				RING_GET_RESPONSE(&vif->rx,
@@ -603,7 +556,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 			resp->flags |= XEN_NETRXF_extra_info;
 
-			gso->u.gso.size = netbk->meta[npo.meta_cons].gso_size;
+			gso->u.gso.size = vif->meta[npo.meta_cons].gso_size;
 			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
 			gso->u.gso.pad = 0;
 			gso->u.gso.features = 0;
@@ -613,7 +566,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 		}
 
 		netbk_add_frag_responses(vif, status,
-					 netbk->meta + npo.meta_cons + 1,
+					 vif->meta + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
@@ -629,17 +582,15 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
 
-	if (!skb_queue_empty(&netbk->rx_queue))
-		xen_netbk_kick_thread(netbk);
+	if (!skb_queue_empty(&vif->rx_queue))
+		xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	struct xen_netbk *netbk = vif->netbk;
-
-	skb_queue_tail(&netbk->rx_queue, skb);
+	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(netbk);
+	xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
@@ -738,21 +689,20 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
+static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 					 struct sk_buff *skb,
 					 u16 pending_idx)
 {
 	struct page *page;
 	int idx;
-	page = page_pool_get(netbk, &idx);
+	page = page_pool_get(vif, &idx);
 	if (!page)
 		return NULL;
-	netbk->mmap_pages[pending_idx] = idx;
+	vif->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
-						  struct xenvif *vif,
+static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 						  struct sk_buff *skb,
 						  struct xen_netif_tx_request *txp,
 						  struct gnttab_copy *gop)
@@ -769,11 +719,11 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		struct page *page;
 		pending_ring_idx_t index;
 		struct pending_tx_info *pending_tx_info =
-			netbk->pending_tx_info;
+			vif->pending_tx_info;
 
-		index = pending_index(netbk->pending_cons++);
-		pending_idx = netbk->pending_ring[index];
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -797,14 +747,13 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
+static int xen_netbk_tx_check_gop(struct xenvif *vif,
 				  struct sk_buff *skb,
 				  struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = netbk->vif;
+	struct pending_tx_info *pending_tx_info = vif->pending_tx_info;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -814,10 +763,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	err = gop->status;
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
+		index = pending_index(vif->pending_prod++);
 		txp = &pending_tx_info[pending_idx].req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
+		vif->pending_ring[index] = pending_idx;
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -834,15 +783,15 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(vif, pending_idx);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		txp = &vif->pending_tx_info[pending_idx].req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
+		index = pending_index(vif->pending_prod++);
+		vif->pending_ring[index] = pending_idx;
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -850,10 +799,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -864,7 +813,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
+static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -878,16 +827,16 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		txp = &netbk->pending_tx_info[pending_idx].req;
-		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
+		txp = &vif->pending_tx_info[pending_idx].req;
+		page = virt_to_page(idx_to_kaddr(vif, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(to_page(netbk->mmap_pages[pending_idx]));
-		xen_netbk_idx_release(netbk, pending_idx);
+		get_page(to_page(vif->mmap_pages[pending_idx]));
+		xen_netbk_idx_release(vif, pending_idx);
 	}
 }
 
@@ -1048,14 +997,13 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
+static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
+	struct gnttab_copy *gop = vif->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
-	struct xenvif *vif = netbk->vif;
 
-	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
+	while ((nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1121,8 +1069,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			break;
 		}
 
-		index = pending_index(netbk->pending_cons);
-		pending_idx = netbk->pending_ring[index];
+		index = pending_index(vif->pending_cons);
+		pending_idx = vif->pending_ring[index];
 
 		data_len = (txreq.size > PKT_PROT_LEN &&
 			    ret < MAX_SKB_FRAGS) ?
@@ -1152,7 +1100,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
@@ -1172,7 +1120,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		gop++;
 
-		memcpy(&netbk->pending_tx_info[pending_idx].req,
+		memcpy(&vif->pending_tx_info[pending_idx].req,
 		       &txreq, sizeof(txreq));
 		*((u16 *)skb->data) = pending_idx;
 
@@ -1188,11 +1136,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
+		__skb_queue_tail(&vif->tx_queue, skb);
 
-		netbk->pending_cons++;
+		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(netbk, vif,
+		request_gop = xen_netbk_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
@@ -1204,31 +1152,30 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
+		if ((gop-vif->tx_copy_ops) >= ARRAY_SIZE(vif->tx_copy_ops))
 			break;
 	}
 
-	return gop - netbk->tx_copy_ops;
+	return gop - vif->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+static void xen_netbk_tx_submit(struct xenvif *vif,
 				int *work_done, int budget)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops;
+	struct gnttab_copy *gop = vif->tx_copy_ops;
 	struct sk_buff *skb;
-	struct xenvif *vif = netbk->vif;
 
 	while ((*work_done < budget) &&
-	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
 		unsigned data_len;
 
 		pending_idx = *((u16 *)skb->data);
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		txp = &vif->pending_tx_info[pending_idx].req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
+		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1237,7 +1184,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		data_len = skb->len;
 		memcpy(skb->data,
-		       (void *)(idx_to_kaddr(netbk, pending_idx)|txp->offset),
+		       (void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
 		       data_len);
 		if (data_len < txp->size) {
 			/* Append the packet payload as a fragment. */
@@ -1245,7 +1192,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1253,7 +1200,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(netbk, skb);
+		xen_netbk_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1285,45 +1232,44 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
-	if (unlikely(!tx_work_todo(netbk)))
+	if (unlikely(!tx_work_todo(vif)))
 		return;
 
-	nr_gops = xen_netbk_tx_build_gops(netbk);
+	nr_gops = xen_netbk_tx_build_gops(vif);
 
 	if (nr_gops == 0)
 		return;
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
-					netbk->tx_copy_ops, nr_gops);
+					vif->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, work_done, budget);
+	xen_netbk_tx_submit(vif, work_done, budget);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
 {
-	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
+	if (vif->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	pending_tx_info = &netbk->pending_tx_info[pending_idx];
+	pending_tx_info = &vif->pending_tx_info[pending_idx];
 
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
-	index = pending_index(netbk->pending_prod++);
-	netbk->pending_ring[index] = pending_idx;
+	index = pending_index(vif->pending_prod++);
+	vif->pending_ring[index] = pending_idx;
 
-	page_pool_put(netbk->mmap_pages[pending_idx]);
+	page_pool_put(vif->mmap_pages[pending_idx]);
 
-	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
+	vif->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1370,15 +1316,15 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 	return resp;
 }
 
-static inline int rx_work_todo(struct xen_netbk *netbk)
+static inline int rx_work_todo(struct xenvif *vif)
 {
-	return !skb_queue_empty(&netbk->rx_queue);
+	return !skb_queue_empty(&vif->rx_queue);
 }
 
-static inline int tx_work_todo(struct xen_netbk *netbk)
+static inline int tx_work_todo(struct xenvif *vif)
 {
-	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
-	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
+	    (nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
@@ -1429,54 +1375,21 @@ err:
 	return err;
 }
 
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
-{
-	int i;
-	struct xen_netbk *netbk;
-
-	netbk = vzalloc(sizeof(struct xen_netbk));
-	if (!netbk) {
-		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return NULL;
-	}
-
-	netbk->vif = vif;
-
-	skb_queue_head_init(&netbk->rx_queue);
-	skb_queue_head_init(&netbk->tx_queue);
-
-	netbk->pending_cons = 0;
-	netbk->pending_prod = MAX_PENDING_REQS;
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->pending_ring[i] = i;
-
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->mmap_pages[i] = INVALID_ENTRY;
-
-	return netbk;
-}
-
-void xen_netbk_free_netbk(struct xen_netbk *netbk)
-{
-	vfree(netbk);
-}
-
 int xen_netbk_kthread(void *data)
 {
 	struct xenvif *vif = data;
-	struct xen_netbk *netbk = vif->netbk;
 
 	while (!kthread_should_stop()) {
 		wait_event_interruptible(vif->wq,
-					 rx_work_todo(netbk) ||
+					 rx_work_todo(vif) ||
 					 kthread_should_stop());
 		cond_resched();
 
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
+		if (rx_work_todo(vif))
+			xen_netbk_rx_action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
index 8904869..19f2a21 100644
--- a/drivers/net/xen-netback/page_pool.c
+++ b/drivers/net/xen-netback/page_pool.c
@@ -105,7 +105,7 @@ int is_in_pool(struct page *page, int *pidx)
 	return get_page_ext(page, pidx);
 }
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+struct page *page_pool_get(struct xenvif *vif, int *pidx)
 {
 	int idx;
 	struct page *page;
@@ -121,7 +121,7 @@ struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
 	}
 
 	set_page_ext(page, idx);
-	pool[idx].u.netbk = netbk;
+	pool[idx].u.vif = vif;
 	pool[idx].page = page;
 
 	*pidx = idx;
@@ -134,7 +134,7 @@ void page_pool_put(int idx)
 	struct page *page = pool[idx].page;
 
 	pool[idx].page = NULL;
-	pool[idx].u.netbk = NULL;
+	pool[idx].u.vif = NULL;
 	page->mapping = 0;
 	put_page(page);
 	put_free_entry(idx);
@@ -177,7 +177,7 @@ struct page *to_page(int idx)
 	return pool[idx].page;
 }
 
-struct xen_netbk *to_netbk(int idx)
+struct xenvif *to_vif(int idx)
 {
-	return pool[idx].u.netbk;
+	return pool[idx].u.vif;
 }
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
index 52a6fc7..9bd7c55 100644
--- a/drivers/net/xen-netback/page_pool.h
+++ b/drivers/net/xen-netback/page_pool.h
@@ -37,8 +37,8 @@ typedef uint32_t idx_t;
 struct page_pool_entry {
 	struct page *page;
 	union {
-		struct xen_netbk *netbk;
-		idx_t             fl;
+		struct xenvif *vif;
+		idx_t          fl;
 	} u;
 };
 
@@ -51,11 +51,11 @@ int  page_pool_init(void);
 void page_pool_destroy(void);
 
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+struct page *page_pool_get(struct xenvif *vif, int *pidx);
 void         page_pool_put(int idx);
 int          is_in_pool(struct page *page, int *pidx);
 
-struct page      *to_page(int idx);
-struct xen_netbk *to_netbk(int idx);
+struct page   *to_page(int idx);
+struct xenvif *to_vif(int idx);
 
 #endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTk-0005gS-IP; Fri, 13 Jan 2012 16:59:48 +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 1RlkTi-0005dM-9M
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326473974!10818882!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6652 invoked from network); 13 Jan 2012 16:59:39 -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;
	13 Jan 2012 16:59:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="177465197"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 11:59:37 -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 q0DGxQEG016212;
	Fri, 13 Jan 2012 08:59:36 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:08 +0000
Message-ID: <1326473949-22389-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 5/6] netback: melt xen_netbk into xenvif
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, there is no need to keep xen_netbk and xenvif
separated.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   58 ++++++--
 drivers/net/xen-netback/interface.c |   35 ++---
 drivers/net/xen-netback/netback.c   |  279 ++++++++++++-----------------------
 drivers/net/xen-netback/page_pool.c |   10 +-
 drivers/net/xen-netback/page_pool.h |   10 +-
 5 files changed, 166 insertions(+), 226 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 1f6156d..6b99246 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,16 +45,34 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
-struct xen_netbk;
+#include "page_pool.h"
+
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+};
+typedef unsigned int pending_ring_idx_t;
+
+struct netbk_rx_meta {
+	int id;
+	int size;
+	int gso_size;
+};
+
+#define MAX_PENDING_REQS 256
+
+/* Discriminate from any valid pending_idx value. */
+#define INVALID_PENDING_IDX 0xFFFF
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
-	/* Reference to netback processing backend. */
-	struct xen_netbk *netbk;
-
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -97,6 +115,27 @@ struct xenvif {
 
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
+
+	struct sk_buff_head rx_queue;
+	struct sk_buff_head tx_queue;
+
+	idx_t mmap_pages[MAX_PENDING_REQS];
+
+	pending_ring_idx_t pending_prod;
+	pending_ring_idx_t pending_cons;
+
+	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
+	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
+
+	u16 pending_ring[MAX_PENDING_REQS];
+
+	/*
+	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
+	 * head/fragment page uses 2 copy operations because it
+	 * straddles two buffers in the frontend.
+	 */
+	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
+	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -104,9 +143,6 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
@@ -143,12 +179,8 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-/* Allocate and free xen_netbk structure */
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
-void xen_netbk_free_netbk(struct xen_netbk *netbk);
-
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
-void xen_netbk_rx_action(struct xen_netbk *netbk);
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
+void xen_netbk_rx_action(struct xenvif *vif);
 
 int xen_netbk_kthread(void *data);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 3126028..69184d1 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -55,7 +55,7 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (vif->netbk == NULL)
+	if (vif->task == NULL)
 		return IRQ_NONE;
 
 	if (xenvif_rx_schedulable(vif))
@@ -72,7 +72,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+	xen_netbk_tx_action(vif, &work_done, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -95,9 +95,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	BUG_ON(skb->dev != dev);
 
-	if (vif->netbk == NULL)
-		goto drop;
-
 	/* Drop the packet if the target domain has no receive buffers. */
 	if (!xenvif_rx_schedulable(vif))
 		goto drop;
@@ -257,6 +254,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	int err;
 	struct net_device *dev;
 	struct xenvif *vif;
+	int i;
 	char name[IFNAMSIZ] = {};
 
 	snprintf(name, IFNAMSIZ - 1, "vif%u.%u", domid, handle);
@@ -271,7 +269,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk = NULL;
 
 	vif->can_sg = 1;
 	vif->csum = 1;
@@ -290,6 +287,17 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 
 	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
 
+	skb_queue_head_init(&vif->rx_queue);
+	skb_queue_head_init(&vif->tx_queue);
+
+	vif->pending_cons = 0;
+	vif->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->mmap_pages[i] = INVALID_ENTRY;
+
 	/*
 	 * Initialise a dummy MAC address. We choose the numerically
 	 * largest non-broadcast address to prevent the address getting
@@ -337,14 +345,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	vif->netbk = xen_netbk_alloc_netbk(vif);
-	if (!vif->netbk) {
-		pr_warn("Could not allocate xen_netbk\n");
-		err = -ENOMEM;
-		goto err_unbind;
-	}
-
-
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xen_netbk_kthread,
 				   (void *)vif,
@@ -352,7 +352,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (IS_ERR(vif->task)) {
 		pr_warn("Could not create kthread\n");
 		err = PTR_ERR(vif->task);
-		goto err_free_netbk;
+		goto err_unbind;
 	}
 
 	rtnl_lock();
@@ -367,8 +367,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	wake_up_process(vif->task);
 
 	return 0;
-err_free_netbk:
-	xen_netbk_free_netbk(vif->netbk);
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
@@ -392,9 +390,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	if (vif->task)
 		kthread_stop(vif->task);
 
-	if (vif->netbk)
-		xen_netbk_free_netbk(vif->netbk);
-
 	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index e486fd6..133ebb3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -47,57 +47,13 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-};
-typedef unsigned int pending_ring_idx_t;
-
-struct netbk_rx_meta {
-	int id;
-	int size;
-	int gso_size;
-};
-
-#define MAX_PENDING_REQS 256
-
-/* Discriminate from any valid pending_idx value. */
-#define INVALID_PENDING_IDX 0xFFFF
-
-#define MAX_BUFFER_OFFSET PAGE_SIZE
-
-struct xen_netbk {
-	struct sk_buff_head rx_queue;
-	struct sk_buff_head tx_queue;
-
-	idx_t mmap_pages[MAX_PENDING_REQS];
-
-	pending_ring_idx_t pending_prod;
-	pending_ring_idx_t pending_cons;
-	struct list_head net_schedule_list;
-
-	struct xenvif *vif;
-
-	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
-	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
-
-	u16 pending_ring[MAX_PENDING_REQS];
-
-	/*
-	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
-	 * head/fragment page uses 2 copy operations because it
-	 * straddles two buffers in the frontend.
-	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
-};
-
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
 
-static inline int tx_work_todo(struct xen_netbk *netbk);
-static inline int rx_work_todo(struct xen_netbk *netbk);
+static inline int tx_work_todo(struct xenvif *vif);
+static inline int rx_work_todo(struct xenvif *vif);
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
@@ -106,16 +62,16 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      size,
 					     u16      flags);
 
-static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
+static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
-	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
+	return page_to_pfn(to_page(vif->mmap_pages[idx]));
 }
 
-static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
+static inline unsigned long idx_to_kaddr(struct xenvif *vif,
 					 u16 idx)
 {
-	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
+	return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
 }
 
 /*
@@ -143,10 +99,10 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 	return i & (MAX_PENDING_REQS-1);
 }
 
-static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
+static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 {
 	return MAX_PENDING_REQS -
-		netbk->pending_prod + netbk->pending_cons;
+		vif->pending_prod + vif->pending_cons;
 }
 
 static int max_required_rx_slots(struct xenvif *vif)
@@ -332,12 +288,12 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = to_netbk(idx);
+			struct xenvif *vif = to_vif(idx);
 			struct pending_tx_info *src_pend;
 
-			src_pend = &netbk->pending_tx_info[idx];
+			src_pend = &vif->pending_tx_info[idx];
 
-			copy_gop->source.domid = netbk->vif->domid;
+			copy_gop->source.domid = vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -495,16 +451,13 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xenvif *vif)
 {
-	struct xenvif *vif = netbk->vif;
-
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xen_netbk *netbk)
+void xen_netbk_rx_action(struct xenvif *vif)
 {
-	struct xenvif *vif = NULL;
 	s8 status;
 	u16 flags;
 	struct xen_netif_rx_response *resp;
@@ -519,15 +472,15 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
-		.copy  = netbk->grant_copy_op,
-		.meta  = netbk->meta,
+		.copy  = vif->grant_copy_op,
+		.meta  = vif->meta,
 	};
 
 	skb_queue_head_init(&rxq);
 
 	count = 0;
 
-	while ((skb = skb_dequeue(&netbk->rx_queue)) != NULL) {
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
 		vif = netdev_priv(skb->dev);
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
@@ -543,29 +496,29 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			break;
 	}
 
-	BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
+	BUG_ON(npo.meta_prod > ARRAY_SIZE(vif->meta));
 
 	if (!npo.copy_prod)
 		return;
 
-	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
+	BUG_ON(npo.copy_prod > ARRAY_SIZE(vif->grant_copy_op));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &vif->grant_copy_op,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
 
 	while ((skb = __skb_dequeue(&rxq)) != NULL) {
 		sco = (struct skb_cb_overlay *)skb->cb;
 
-		vif = netdev_priv(skb->dev);
+		/* vif = netdev_priv(skb->dev); */
 
-		if (netbk->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
+		if (vif->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
 
 			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
 
-			resp->offset = netbk->meta[npo.meta_cons].gso_size;
-			resp->id = netbk->meta[npo.meta_cons].id;
+			resp->offset = vif->meta[npo.meta_cons].gso_size;
+			resp->id = vif->meta[npo.meta_cons].id;
 			resp->status = sco->meta_slots_used;
 
 			npo.meta_cons++;
@@ -590,12 +543,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			flags |= XEN_NETRXF_data_validated;
 
 		offset = 0;
-		resp = make_rx_response(vif, netbk->meta[npo.meta_cons].id,
+		resp = make_rx_response(vif, vif->meta[npo.meta_cons].id,
 					status, offset,
-					netbk->meta[npo.meta_cons].size,
+					vif->meta[npo.meta_cons].size,
 					flags);
 
-		if (netbk->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
+		if (vif->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
 			struct xen_netif_extra_info *gso =
 				(struct xen_netif_extra_info *)
 				RING_GET_RESPONSE(&vif->rx,
@@ -603,7 +556,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 			resp->flags |= XEN_NETRXF_extra_info;
 
-			gso->u.gso.size = netbk->meta[npo.meta_cons].gso_size;
+			gso->u.gso.size = vif->meta[npo.meta_cons].gso_size;
 			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
 			gso->u.gso.pad = 0;
 			gso->u.gso.features = 0;
@@ -613,7 +566,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 		}
 
 		netbk_add_frag_responses(vif, status,
-					 netbk->meta + npo.meta_cons + 1,
+					 vif->meta + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
@@ -629,17 +582,15 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
 
-	if (!skb_queue_empty(&netbk->rx_queue))
-		xen_netbk_kick_thread(netbk);
+	if (!skb_queue_empty(&vif->rx_queue))
+		xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	struct xen_netbk *netbk = vif->netbk;
-
-	skb_queue_tail(&netbk->rx_queue, skb);
+	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(netbk);
+	xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
@@ -738,21 +689,20 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
+static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 					 struct sk_buff *skb,
 					 u16 pending_idx)
 {
 	struct page *page;
 	int idx;
-	page = page_pool_get(netbk, &idx);
+	page = page_pool_get(vif, &idx);
 	if (!page)
 		return NULL;
-	netbk->mmap_pages[pending_idx] = idx;
+	vif->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
-						  struct xenvif *vif,
+static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 						  struct sk_buff *skb,
 						  struct xen_netif_tx_request *txp,
 						  struct gnttab_copy *gop)
@@ -769,11 +719,11 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		struct page *page;
 		pending_ring_idx_t index;
 		struct pending_tx_info *pending_tx_info =
-			netbk->pending_tx_info;
+			vif->pending_tx_info;
 
-		index = pending_index(netbk->pending_cons++);
-		pending_idx = netbk->pending_ring[index];
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -797,14 +747,13 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
+static int xen_netbk_tx_check_gop(struct xenvif *vif,
 				  struct sk_buff *skb,
 				  struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = netbk->vif;
+	struct pending_tx_info *pending_tx_info = vif->pending_tx_info;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -814,10 +763,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	err = gop->status;
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
+		index = pending_index(vif->pending_prod++);
 		txp = &pending_tx_info[pending_idx].req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
+		vif->pending_ring[index] = pending_idx;
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -834,15 +783,15 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(vif, pending_idx);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		txp = &vif->pending_tx_info[pending_idx].req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
+		index = pending_index(vif->pending_prod++);
+		vif->pending_ring[index] = pending_idx;
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -850,10 +799,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -864,7 +813,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
+static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -878,16 +827,16 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		txp = &netbk->pending_tx_info[pending_idx].req;
-		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
+		txp = &vif->pending_tx_info[pending_idx].req;
+		page = virt_to_page(idx_to_kaddr(vif, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(to_page(netbk->mmap_pages[pending_idx]));
-		xen_netbk_idx_release(netbk, pending_idx);
+		get_page(to_page(vif->mmap_pages[pending_idx]));
+		xen_netbk_idx_release(vif, pending_idx);
 	}
 }
 
@@ -1048,14 +997,13 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
+static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
+	struct gnttab_copy *gop = vif->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
-	struct xenvif *vif = netbk->vif;
 
-	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
+	while ((nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1121,8 +1069,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			break;
 		}
 
-		index = pending_index(netbk->pending_cons);
-		pending_idx = netbk->pending_ring[index];
+		index = pending_index(vif->pending_cons);
+		pending_idx = vif->pending_ring[index];
 
 		data_len = (txreq.size > PKT_PROT_LEN &&
 			    ret < MAX_SKB_FRAGS) ?
@@ -1152,7 +1100,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
@@ -1172,7 +1120,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		gop++;
 
-		memcpy(&netbk->pending_tx_info[pending_idx].req,
+		memcpy(&vif->pending_tx_info[pending_idx].req,
 		       &txreq, sizeof(txreq));
 		*((u16 *)skb->data) = pending_idx;
 
@@ -1188,11 +1136,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
+		__skb_queue_tail(&vif->tx_queue, skb);
 
-		netbk->pending_cons++;
+		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(netbk, vif,
+		request_gop = xen_netbk_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
@@ -1204,31 +1152,30 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
+		if ((gop-vif->tx_copy_ops) >= ARRAY_SIZE(vif->tx_copy_ops))
 			break;
 	}
 
-	return gop - netbk->tx_copy_ops;
+	return gop - vif->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+static void xen_netbk_tx_submit(struct xenvif *vif,
 				int *work_done, int budget)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops;
+	struct gnttab_copy *gop = vif->tx_copy_ops;
 	struct sk_buff *skb;
-	struct xenvif *vif = netbk->vif;
 
 	while ((*work_done < budget) &&
-	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
 		unsigned data_len;
 
 		pending_idx = *((u16 *)skb->data);
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		txp = &vif->pending_tx_info[pending_idx].req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
+		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1237,7 +1184,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		data_len = skb->len;
 		memcpy(skb->data,
-		       (void *)(idx_to_kaddr(netbk, pending_idx)|txp->offset),
+		       (void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
 		       data_len);
 		if (data_len < txp->size) {
 			/* Append the packet payload as a fragment. */
@@ -1245,7 +1192,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1253,7 +1200,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(netbk, skb);
+		xen_netbk_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1285,45 +1232,44 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
-	if (unlikely(!tx_work_todo(netbk)))
+	if (unlikely(!tx_work_todo(vif)))
 		return;
 
-	nr_gops = xen_netbk_tx_build_gops(netbk);
+	nr_gops = xen_netbk_tx_build_gops(vif);
 
 	if (nr_gops == 0)
 		return;
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
-					netbk->tx_copy_ops, nr_gops);
+					vif->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, work_done, budget);
+	xen_netbk_tx_submit(vif, work_done, budget);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
 {
-	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
+	if (vif->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	pending_tx_info = &netbk->pending_tx_info[pending_idx];
+	pending_tx_info = &vif->pending_tx_info[pending_idx];
 
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
-	index = pending_index(netbk->pending_prod++);
-	netbk->pending_ring[index] = pending_idx;
+	index = pending_index(vif->pending_prod++);
+	vif->pending_ring[index] = pending_idx;
 
-	page_pool_put(netbk->mmap_pages[pending_idx]);
+	page_pool_put(vif->mmap_pages[pending_idx]);
 
-	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
+	vif->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1370,15 +1316,15 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 	return resp;
 }
 
-static inline int rx_work_todo(struct xen_netbk *netbk)
+static inline int rx_work_todo(struct xenvif *vif)
 {
-	return !skb_queue_empty(&netbk->rx_queue);
+	return !skb_queue_empty(&vif->rx_queue);
 }
 
-static inline int tx_work_todo(struct xen_netbk *netbk)
+static inline int tx_work_todo(struct xenvif *vif)
 {
-	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
-	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
+	    (nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
@@ -1429,54 +1375,21 @@ err:
 	return err;
 }
 
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
-{
-	int i;
-	struct xen_netbk *netbk;
-
-	netbk = vzalloc(sizeof(struct xen_netbk));
-	if (!netbk) {
-		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return NULL;
-	}
-
-	netbk->vif = vif;
-
-	skb_queue_head_init(&netbk->rx_queue);
-	skb_queue_head_init(&netbk->tx_queue);
-
-	netbk->pending_cons = 0;
-	netbk->pending_prod = MAX_PENDING_REQS;
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->pending_ring[i] = i;
-
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->mmap_pages[i] = INVALID_ENTRY;
-
-	return netbk;
-}
-
-void xen_netbk_free_netbk(struct xen_netbk *netbk)
-{
-	vfree(netbk);
-}
-
 int xen_netbk_kthread(void *data)
 {
 	struct xenvif *vif = data;
-	struct xen_netbk *netbk = vif->netbk;
 
 	while (!kthread_should_stop()) {
 		wait_event_interruptible(vif->wq,
-					 rx_work_todo(netbk) ||
+					 rx_work_todo(vif) ||
 					 kthread_should_stop());
 		cond_resched();
 
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
+		if (rx_work_todo(vif))
+			xen_netbk_rx_action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
index 8904869..19f2a21 100644
--- a/drivers/net/xen-netback/page_pool.c
+++ b/drivers/net/xen-netback/page_pool.c
@@ -105,7 +105,7 @@ int is_in_pool(struct page *page, int *pidx)
 	return get_page_ext(page, pidx);
 }
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+struct page *page_pool_get(struct xenvif *vif, int *pidx)
 {
 	int idx;
 	struct page *page;
@@ -121,7 +121,7 @@ struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
 	}
 
 	set_page_ext(page, idx);
-	pool[idx].u.netbk = netbk;
+	pool[idx].u.vif = vif;
 	pool[idx].page = page;
 
 	*pidx = idx;
@@ -134,7 +134,7 @@ void page_pool_put(int idx)
 	struct page *page = pool[idx].page;
 
 	pool[idx].page = NULL;
-	pool[idx].u.netbk = NULL;
+	pool[idx].u.vif = NULL;
 	page->mapping = 0;
 	put_page(page);
 	put_free_entry(idx);
@@ -177,7 +177,7 @@ struct page *to_page(int idx)
 	return pool[idx].page;
 }
 
-struct xen_netbk *to_netbk(int idx)
+struct xenvif *to_vif(int idx)
 {
-	return pool[idx].u.netbk;
+	return pool[idx].u.vif;
 }
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
index 52a6fc7..9bd7c55 100644
--- a/drivers/net/xen-netback/page_pool.h
+++ b/drivers/net/xen-netback/page_pool.h
@@ -37,8 +37,8 @@ typedef uint32_t idx_t;
 struct page_pool_entry {
 	struct page *page;
 	union {
-		struct xen_netbk *netbk;
-		idx_t             fl;
+		struct xenvif *vif;
+		idx_t          fl;
 	} u;
 };
 
@@ -51,11 +51,11 @@ int  page_pool_init(void);
 void page_pool_destroy(void);
 
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+struct page *page_pool_get(struct xenvif *vif, int *pidx);
 void         page_pool_put(int idx);
 int          is_in_pool(struct page *page, int *pidx);
 
-struct page      *to_page(int idx);
-struct xen_netbk *to_netbk(int idx);
+struct page   *to_page(int idx);
+struct xenvif *to_vif(int idx);
 
 #endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTe-0005dx-L6; Fri, 13 Jan 2012 16:59:42 +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 1RlkTc-0005d1-UH
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326473972!8177955!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20099 invoked from network); 13 Jan 2012 16:59:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:59:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20853678"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59: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, 13 Jan 2012 11:59:32 -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 q0DGxQED016212;
	Fri, 13 Jan 2012 08:59:31 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:05 +0000
Message-ID: <1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 2/6] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Enables users to unload netback module.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   14 ++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..263df73 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -120,6 +120,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 26af7b7..dd10c0d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1653,5 +1653,19 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int i;
+	for (i = 0; i < xen_netbk_group_nr; i++) {
+		struct xen_netbk *netbk = &xen_netbk[i];
+		del_timer(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+	page_pool_destroy();
+	xenvif_xenbus_exit();
+}
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTl-0005gl-1L; Fri, 13 Jan 2012 16:59:49 +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 1RlkTi-0005dR-II
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326473976!7063596!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9784 invoked from network); 13 Jan 2012 16:59:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:59:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20853681"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 11:59:38 -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 q0DGxQEH016212;
	Fri, 13 Jan 2012 08:59:37 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:09 +0000
Message-ID: <1326473949-22389-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 6/6] netback: alter internal
	function/structure names.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since we've melted xen_netbk into xenvif, so it is better to give
functions clearer names.

Also alter napi poll handler function prototypes a bit.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   28 +++---
 drivers/net/xen-netback/interface.c |   20 ++--
 drivers/net/xen-netback/netback.c   |  210 ++++++++++++++++++-----------------
 3 files changed, 130 insertions(+), 128 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 6b99246..f7ec35c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -52,7 +52,7 @@ struct pending_tx_info {
 };
 typedef unsigned int pending_ring_idx_t;
 
-struct netbk_rx_meta {
+struct xenvif_rx_meta {
 	int id;
 	int size;
 	int gso_size;
@@ -135,7 +135,7 @@ struct xenvif {
 	 * straddles two buffers in the frontend.
 	 */
 	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
+	struct xenvif_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -156,32 +156,32 @@ void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
-int xen_netbk_rx_ring_full(struct xenvif *vif);
+int xenvif_rx_ring_full(struct xenvif *vif);
 
-int xen_netbk_must_stop_queue(struct xenvif *vif);
+int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xenvif *vif);
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
-void xen_netbk_check_rx_xenvif(struct xenvif *vif);
+void xenvif_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
-void xen_netbk_rx_action(struct xenvif *vif);
+int xenvif_tx_action(struct xenvif *vif, int budget);
+void xenvif_rx_action(struct xenvif *vif);
 
-int xen_netbk_kthread(void *data);
+int xenvif_kthread(void *data);
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 69184d1..a71039e 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -48,7 +48,7 @@ int xenvif_schedulable(struct xenvif *vif)
 
 static int xenvif_rx_schedulable(struct xenvif *vif)
 {
-	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
+	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
@@ -72,7 +72,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif, &work_done, budget);
+	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -100,12 +100,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
+	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
 
-	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
 		netif_stop_queue(dev);
 
-	xen_netbk_queue_tx_skb(vif, skb);
+	xenvif_queue_tx_skb(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -136,7 +136,7 @@ static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
@@ -333,7 +333,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
 
@@ -346,7 +346,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	disable_irq(vif->irq);
 
 	init_waitqueue_head(&vif->wq);
-	vif->task = kthread_create(xen_netbk_kthread,
+	vif->task = kthread_create(xenvif_kthread,
 				   (void *)vif,
 				   "vif%d.%d", vif->domid, vif->handle);
 	if (IS_ERR(vif->task)) {
@@ -370,7 +370,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 err:
 	return err;
 }
@@ -399,7 +399,7 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 133ebb3..6a9b412 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -47,7 +47,7 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -115,7 +115,7 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xen_netbk_rx_ring_full(struct xenvif *vif)
+int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
@@ -124,16 +124,16 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
 }
 
-int xen_netbk_must_stop_queue(struct xenvif *vif)
+int xenvif_must_stop_queue(struct xenvif *vif)
 {
-	if (!xen_netbk_rx_ring_full(vif))
+	if (!xenvif_rx_ring_full(vif))
 		return 0;
 
 	vif->rx.sring->req_event = vif->rx_req_cons_peek +
 		max_required_rx_slots(vif);
 	mb(); /* request notification /then/ check the queue */
 
-	return xen_netbk_rx_ring_full(vif);
+	return xenvif_rx_ring_full(vif);
 }
 
 /*
@@ -179,9 +179,9 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
 /*
  * Figure out how many ring slots we're going to need to send @skb to
  * the guest. This function is essentially a dry run of
- * netbk_gop_frag_copy.
+ * xenvif_gop_frag_copy.
  */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 {
 	unsigned int count;
 	int i, copy_off;
@@ -220,15 +220,15 @@ struct netrx_pending_operations {
 	unsigned copy_prod, copy_cons;
 	unsigned meta_prod, meta_cons;
 	struct gnttab_copy *copy;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	int copy_off;
 	grant_ref_t copy_gref;
 };
 
-static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-						struct netrx_pending_operations *npo)
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+					struct netrx_pending_operations *npo)
 {
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	struct xen_netif_rx_request *req;
 
 	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
@@ -248,13 +248,13 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				struct netrx_pending_operations *npo,
-				struct page *page, unsigned long size,
-				unsigned long offset, int *head)
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				 struct netrx_pending_operations *npo,
+				 struct page *page, unsigned long size,
+				 unsigned long offset, int *head)
 {
 	struct gnttab_copy *copy_gop;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	/*
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
@@ -335,14 +335,14 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
  * zero GSO descriptors (for non-GSO packets) or one descriptor (for
  * frontend-side LRO).
  */
-static int netbk_gop_skb(struct sk_buff *skb,
-			 struct netrx_pending_operations *npo)
+static int xenvif_gop_skb(struct sk_buff *skb,
+			  struct netrx_pending_operations *npo)
 {
 	struct xenvif *vif = netdev_priv(skb->dev);
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	int i;
 	struct xen_netif_rx_request *req;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	unsigned char *data;
 	int head = 1;
 	int old_meta_prod;
@@ -379,30 +379,30 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     virt_to_page(data), len, offset, &head);
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
-				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				     skb_shinfo(skb)->frags[i].page_offset,
+				     &head);
 	}
 
 	return npo->meta_prod - old_meta_prod;
 }
 
 /*
- * This is a twin to netbk_gop_skb.  Assume that netbk_gop_skb was
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
  * used to set up the operations on the top of
  * netrx_pending_operations, which have since been done.  Check that
  * they didn't give any errors and advance over them.
  */
-static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
-			   struct netrx_pending_operations *npo)
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			    struct netrx_pending_operations *npo)
 {
 	struct gnttab_copy     *copy_op;
 	int status = XEN_NETIF_RSP_OKAY;
@@ -421,9 +421,9 @@ static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
 	return status;
 }
 
-static void netbk_add_frag_responses(struct xenvif *vif, int status,
-				     struct netbk_rx_meta *meta,
-				     int nr_meta_slots)
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				      struct xenvif_rx_meta *meta,
+				      int nr_meta_slots)
 {
 	int i;
 	unsigned long offset;
@@ -451,12 +451,12 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xenvif *vif)
+static void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xenvif *vif)
+void xenvif_rx_action(struct xenvif *vif)
 {
 	s8 status;
 	u16 flags;
@@ -485,7 +485,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
 		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = netbk_gop_skb(skb, &npo);
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
 
 		count += nr_frags + 1;
 
@@ -529,7 +529,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		vif->dev->stats.tx_bytes += skb->len;
 		vif->dev->stats.tx_packets++;
 
-		status = netbk_check_gop(vif, sco->meta_slots_used, &npo);
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
 
 		if (sco->meta_slots_used == 1)
 			flags = 0;
@@ -565,7 +565,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 			gso->flags = 0;
 		}
 
-		netbk_add_frag_responses(vif, status,
+		xenvif_add_frag_responses(vif, status,
 					 vif->meta + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
@@ -583,17 +583,17 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		notify_remote_via_irq(vif->irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
-		xen_netbk_kick_thread(vif);
+		xenvif_kick_thread(vif);
 }
 
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(vif);
+	xenvif_kick_thread(vif);
 }
 
-void xen_netbk_check_rx_xenvif(struct xenvif *vif)
+void xenvif_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
@@ -630,11 +630,11 @@ static void tx_credit_callback(unsigned long data)
 {
 	struct xenvif *vif = (struct xenvif *)data;
 	tx_add_credit(vif);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static void netbk_tx_err(struct xenvif *vif,
-			 struct xen_netif_tx_request *txp, RING_IDX end)
+static void xenvif_tx_err(struct xenvif *vif,
+			  struct xen_netif_tx_request *txp, RING_IDX end)
 {
 	RING_IDX cons = vif->tx.req_cons;
 
@@ -645,10 +645,10 @@ static void netbk_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static int netbk_count_requests(struct xenvif *vif,
+static int xenvif_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
 				int work_to_do)
@@ -689,9 +689,9 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xenvif *vif,
-					 struct sk_buff *skb,
-					 u16 pending_idx)
+static struct page *xenvif_alloc_page(struct xenvif *vif,
+				      struct sk_buff *skb,
+				      u16 pending_idx)
 {
 	struct page *page;
 	int idx;
@@ -702,10 +702,10 @@ static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
-						  struct sk_buff *skb,
-						  struct xen_netif_tx_request *txp,
-						  struct gnttab_copy *gop)
+static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+					       struct sk_buff *skb,
+					       struct xen_netif_tx_request *txp,
+					       struct gnttab_copy *gop)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
@@ -723,7 +723,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 
 		index = pending_index(vif->pending_cons++);
 		pending_idx = vif->pending_ring[index];
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -747,9 +747,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xenvif *vif,
-				  struct sk_buff *skb,
-				  struct gnttab_copy **gopp)
+static int xenvif_tx_check_gop(struct xenvif *vif,
+			       struct sk_buff *skb,
+			       struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
@@ -783,7 +783,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(vif, pending_idx);
+				xenvif_idx_release(vif, pending_idx);
 			continue;
 		}
 
@@ -799,10 +799,10 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -813,7 +813,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
+static void xenvif_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -834,15 +834,15 @@ static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
-		/* Take an extra reference to offset xen_netbk_idx_release */
+		/* Take an extra reference to offset xenvif_idx_release */
 		get_page(to_page(vif->mmap_pages[pending_idx]));
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 	}
 }
 
-static int xen_netbk_get_extras(struct xenvif *vif,
-				struct xen_netif_extra_info *extras,
-				int work_to_do)
+static int xenvif_get_extras(struct xenvif *vif,
+			     struct xen_netif_extra_info *extras,
+			     int work_to_do)
 {
 	struct xen_netif_extra_info extra;
 	RING_IDX cons = vif->tx.req_cons;
@@ -870,9 +870,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 	return work_to_do;
 }
 
-static int netbk_set_skb_gso(struct xenvif *vif,
-			     struct sk_buff *skb,
-			     struct xen_netif_extra_info *gso)
+static int xenvif_set_skb_gso(struct xenvif *vif,
+			      struct sk_buff *skb,
+			      struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
 		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
@@ -997,7 +997,7 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
+static unsigned xenvif_tx_build_gops(struct xenvif *vif)
 {
 	struct gnttab_copy *gop = vif->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
@@ -1036,18 +1036,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 
 		memset(extras, 0, sizeof(extras));
 		if (txreq.flags & XEN_NETTXF_extra_info) {
-			work_to_do = xen_netbk_get_extras(vif, extras,
+			work_to_do = xenvif_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
-		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
+		ret = xenvif_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+			xenvif_tx_err(vif, &txreq, idx - ret);
 			break;
 		}
 		idx += ret;
@@ -1055,7 +1055,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 		if (unlikely(txreq.size < ETH_HLEN)) {
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1065,7 +1065,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1081,7 +1081,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 		if (unlikely(skb == NULL)) {
 			netdev_dbg(vif->dev,
 				   "Can't allocate a skb in start_xmit.\n");
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1092,18 +1092,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 			struct xen_netif_extra_info *gso;
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
-			if (netbk_set_skb_gso(vif, skb, gso)) {
+			if (xenvif_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1140,17 +1140,17 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 
 		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(vif,
+		request_gop = xenvif_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xen_netbk_check_rx_xenvif(vif);
+		xenvif_check_rx_xenvif(vif);
 
 		if ((gop-vif->tx_copy_ops) >= ARRAY_SIZE(vif->tx_copy_ops))
 			break;
@@ -1159,13 +1159,13 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 	return gop - vif->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xenvif *vif,
-				int *work_done, int budget)
+static int xenvif_tx_submit(struct xenvif *vif, int budget)
 {
 	struct gnttab_copy *gop = vif->tx_copy_ops;
 	struct sk_buff *skb;
+	int work_done = 0;
 
-	while ((*work_done < budget) &&
+	while ((work_done < budget) &&
 	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
@@ -1175,7 +1175,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		txp = &vif->pending_tx_info[pending_idx].req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
+		if (unlikely(xenvif_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1192,7 +1192,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1200,7 +1200,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(vif, skb);
+		xenvif_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1225,33 +1225,35 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;\
 
-		(*work_done)++;
+		work_done++;
 
 		xenvif_receive_skb(vif, skb);
 	}
+
+	return work_done;
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
+int xenvif_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
 	if (unlikely(!tx_work_todo(vif)))
-		return;
+		return 0;
 
-	nr_gops = xen_netbk_tx_build_gops(vif);
+	nr_gops = xenvif_tx_build_gops(vif);
 
 	if (nr_gops == 0)
-		return;
+		return 0;
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
 					vif->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(vif, work_done, budget);
+	return xenvif_tx_submit(vif, budget);
 }
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx)
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
@@ -1330,7 +1332,7 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
 		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
@@ -1340,9 +1342,9 @@ void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 					vif->rx.sring);
 }
 
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref)
 {
 	void *addr;
 	struct xen_netif_tx_sring *txs;
@@ -1371,11 +1373,11 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	return 0;
 
 err:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
-int xen_netbk_kthread(void *data)
+int xenvif_kthread(void *data)
 {
 	struct xenvif *vif = data;
 
@@ -1389,7 +1391,7 @@ int xen_netbk_kthread(void *data)
 			break;
 
 		if (rx_work_todo(vif))
-			xen_netbk_rx_action(vif);
+			xenvif_rx_action(vif);
 	}
 
 	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 Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTl-0005gl-1L; Fri, 13 Jan 2012 16:59:49 +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 1RlkTi-0005dR-II
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:47 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326473976!7063596!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9784 invoked from network); 13 Jan 2012 16:59:39 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:59:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20853681"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 11:59:38 -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 q0DGxQEH016212;
	Fri, 13 Jan 2012 08:59:37 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:09 +0000
Message-ID: <1326473949-22389-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 6/6] netback: alter internal
	function/structure names.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since we've melted xen_netbk into xenvif, so it is better to give
functions clearer names.

Also alter napi poll handler function prototypes a bit.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   28 +++---
 drivers/net/xen-netback/interface.c |   20 ++--
 drivers/net/xen-netback/netback.c   |  210 ++++++++++++++++++-----------------
 3 files changed, 130 insertions(+), 128 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 6b99246..f7ec35c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -52,7 +52,7 @@ struct pending_tx_info {
 };
 typedef unsigned int pending_ring_idx_t;
 
-struct netbk_rx_meta {
+struct xenvif_rx_meta {
 	int id;
 	int size;
 	int gso_size;
@@ -135,7 +135,7 @@ struct xenvif {
 	 * straddles two buffers in the frontend.
 	 */
 	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
+	struct xenvif_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -156,32 +156,32 @@ void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
-int xen_netbk_rx_ring_full(struct xenvif *vif);
+int xenvif_rx_ring_full(struct xenvif *vif);
 
-int xen_netbk_must_stop_queue(struct xenvif *vif);
+int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xenvif *vif);
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
-void xen_netbk_check_rx_xenvif(struct xenvif *vif);
+void xenvif_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
-void xen_netbk_rx_action(struct xenvif *vif);
+int xenvif_tx_action(struct xenvif *vif, int budget);
+void xenvif_rx_action(struct xenvif *vif);
 
-int xen_netbk_kthread(void *data);
+int xenvif_kthread(void *data);
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 69184d1..a71039e 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -48,7 +48,7 @@ int xenvif_schedulable(struct xenvif *vif)
 
 static int xenvif_rx_schedulable(struct xenvif *vif)
 {
-	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
+	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
@@ -72,7 +72,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif, &work_done, budget);
+	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -100,12 +100,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
+	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
 
-	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
 		netif_stop_queue(dev);
 
-	xen_netbk_queue_tx_skb(vif, skb);
+	xenvif_queue_tx_skb(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -136,7 +136,7 @@ static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
@@ -333,7 +333,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
 
@@ -346,7 +346,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	disable_irq(vif->irq);
 
 	init_waitqueue_head(&vif->wq);
-	vif->task = kthread_create(xen_netbk_kthread,
+	vif->task = kthread_create(xenvif_kthread,
 				   (void *)vif,
 				   "vif%d.%d", vif->domid, vif->handle);
 	if (IS_ERR(vif->task)) {
@@ -370,7 +370,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 err:
 	return err;
 }
@@ -399,7 +399,7 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 133ebb3..6a9b412 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -47,7 +47,7 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -115,7 +115,7 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xen_netbk_rx_ring_full(struct xenvif *vif)
+int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
@@ -124,16 +124,16 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
 }
 
-int xen_netbk_must_stop_queue(struct xenvif *vif)
+int xenvif_must_stop_queue(struct xenvif *vif)
 {
-	if (!xen_netbk_rx_ring_full(vif))
+	if (!xenvif_rx_ring_full(vif))
 		return 0;
 
 	vif->rx.sring->req_event = vif->rx_req_cons_peek +
 		max_required_rx_slots(vif);
 	mb(); /* request notification /then/ check the queue */
 
-	return xen_netbk_rx_ring_full(vif);
+	return xenvif_rx_ring_full(vif);
 }
 
 /*
@@ -179,9 +179,9 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
 /*
  * Figure out how many ring slots we're going to need to send @skb to
  * the guest. This function is essentially a dry run of
- * netbk_gop_frag_copy.
+ * xenvif_gop_frag_copy.
  */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 {
 	unsigned int count;
 	int i, copy_off;
@@ -220,15 +220,15 @@ struct netrx_pending_operations {
 	unsigned copy_prod, copy_cons;
 	unsigned meta_prod, meta_cons;
 	struct gnttab_copy *copy;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	int copy_off;
 	grant_ref_t copy_gref;
 };
 
-static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-						struct netrx_pending_operations *npo)
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+					struct netrx_pending_operations *npo)
 {
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	struct xen_netif_rx_request *req;
 
 	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
@@ -248,13 +248,13 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				struct netrx_pending_operations *npo,
-				struct page *page, unsigned long size,
-				unsigned long offset, int *head)
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				 struct netrx_pending_operations *npo,
+				 struct page *page, unsigned long size,
+				 unsigned long offset, int *head)
 {
 	struct gnttab_copy *copy_gop;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	/*
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
@@ -335,14 +335,14 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
  * zero GSO descriptors (for non-GSO packets) or one descriptor (for
  * frontend-side LRO).
  */
-static int netbk_gop_skb(struct sk_buff *skb,
-			 struct netrx_pending_operations *npo)
+static int xenvif_gop_skb(struct sk_buff *skb,
+			  struct netrx_pending_operations *npo)
 {
 	struct xenvif *vif = netdev_priv(skb->dev);
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	int i;
 	struct xen_netif_rx_request *req;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	unsigned char *data;
 	int head = 1;
 	int old_meta_prod;
@@ -379,30 +379,30 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     virt_to_page(data), len, offset, &head);
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
-				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				     skb_shinfo(skb)->frags[i].page_offset,
+				     &head);
 	}
 
 	return npo->meta_prod - old_meta_prod;
 }
 
 /*
- * This is a twin to netbk_gop_skb.  Assume that netbk_gop_skb was
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
  * used to set up the operations on the top of
  * netrx_pending_operations, which have since been done.  Check that
  * they didn't give any errors and advance over them.
  */
-static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
-			   struct netrx_pending_operations *npo)
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			    struct netrx_pending_operations *npo)
 {
 	struct gnttab_copy     *copy_op;
 	int status = XEN_NETIF_RSP_OKAY;
@@ -421,9 +421,9 @@ static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
 	return status;
 }
 
-static void netbk_add_frag_responses(struct xenvif *vif, int status,
-				     struct netbk_rx_meta *meta,
-				     int nr_meta_slots)
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				      struct xenvif_rx_meta *meta,
+				      int nr_meta_slots)
 {
 	int i;
 	unsigned long offset;
@@ -451,12 +451,12 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xenvif *vif)
+static void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xenvif *vif)
+void xenvif_rx_action(struct xenvif *vif)
 {
 	s8 status;
 	u16 flags;
@@ -485,7 +485,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
 		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = netbk_gop_skb(skb, &npo);
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
 
 		count += nr_frags + 1;
 
@@ -529,7 +529,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		vif->dev->stats.tx_bytes += skb->len;
 		vif->dev->stats.tx_packets++;
 
-		status = netbk_check_gop(vif, sco->meta_slots_used, &npo);
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
 
 		if (sco->meta_slots_used == 1)
 			flags = 0;
@@ -565,7 +565,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 			gso->flags = 0;
 		}
 
-		netbk_add_frag_responses(vif, status,
+		xenvif_add_frag_responses(vif, status,
 					 vif->meta + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
@@ -583,17 +583,17 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		notify_remote_via_irq(vif->irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
-		xen_netbk_kick_thread(vif);
+		xenvif_kick_thread(vif);
 }
 
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(vif);
+	xenvif_kick_thread(vif);
 }
 
-void xen_netbk_check_rx_xenvif(struct xenvif *vif)
+void xenvif_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
@@ -630,11 +630,11 @@ static void tx_credit_callback(unsigned long data)
 {
 	struct xenvif *vif = (struct xenvif *)data;
 	tx_add_credit(vif);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static void netbk_tx_err(struct xenvif *vif,
-			 struct xen_netif_tx_request *txp, RING_IDX end)
+static void xenvif_tx_err(struct xenvif *vif,
+			  struct xen_netif_tx_request *txp, RING_IDX end)
 {
 	RING_IDX cons = vif->tx.req_cons;
 
@@ -645,10 +645,10 @@ static void netbk_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static int netbk_count_requests(struct xenvif *vif,
+static int xenvif_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
 				int work_to_do)
@@ -689,9 +689,9 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xenvif *vif,
-					 struct sk_buff *skb,
-					 u16 pending_idx)
+static struct page *xenvif_alloc_page(struct xenvif *vif,
+				      struct sk_buff *skb,
+				      u16 pending_idx)
 {
 	struct page *page;
 	int idx;
@@ -702,10 +702,10 @@ static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
-						  struct sk_buff *skb,
-						  struct xen_netif_tx_request *txp,
-						  struct gnttab_copy *gop)
+static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+					       struct sk_buff *skb,
+					       struct xen_netif_tx_request *txp,
+					       struct gnttab_copy *gop)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
@@ -723,7 +723,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 
 		index = pending_index(vif->pending_cons++);
 		pending_idx = vif->pending_ring[index];
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -747,9 +747,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xenvif *vif,
-				  struct sk_buff *skb,
-				  struct gnttab_copy **gopp)
+static int xenvif_tx_check_gop(struct xenvif *vif,
+			       struct sk_buff *skb,
+			       struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
@@ -783,7 +783,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(vif, pending_idx);
+				xenvif_idx_release(vif, pending_idx);
 			continue;
 		}
 
@@ -799,10 +799,10 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -813,7 +813,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
+static void xenvif_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -834,15 +834,15 @@ static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
-		/* Take an extra reference to offset xen_netbk_idx_release */
+		/* Take an extra reference to offset xenvif_idx_release */
 		get_page(to_page(vif->mmap_pages[pending_idx]));
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 	}
 }
 
-static int xen_netbk_get_extras(struct xenvif *vif,
-				struct xen_netif_extra_info *extras,
-				int work_to_do)
+static int xenvif_get_extras(struct xenvif *vif,
+			     struct xen_netif_extra_info *extras,
+			     int work_to_do)
 {
 	struct xen_netif_extra_info extra;
 	RING_IDX cons = vif->tx.req_cons;
@@ -870,9 +870,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 	return work_to_do;
 }
 
-static int netbk_set_skb_gso(struct xenvif *vif,
-			     struct sk_buff *skb,
-			     struct xen_netif_extra_info *gso)
+static int xenvif_set_skb_gso(struct xenvif *vif,
+			      struct sk_buff *skb,
+			      struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
 		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
@@ -997,7 +997,7 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
+static unsigned xenvif_tx_build_gops(struct xenvif *vif)
 {
 	struct gnttab_copy *gop = vif->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
@@ -1036,18 +1036,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 
 		memset(extras, 0, sizeof(extras));
 		if (txreq.flags & XEN_NETTXF_extra_info) {
-			work_to_do = xen_netbk_get_extras(vif, extras,
+			work_to_do = xenvif_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
-		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
+		ret = xenvif_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+			xenvif_tx_err(vif, &txreq, idx - ret);
 			break;
 		}
 		idx += ret;
@@ -1055,7 +1055,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 		if (unlikely(txreq.size < ETH_HLEN)) {
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1065,7 +1065,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1081,7 +1081,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 		if (unlikely(skb == NULL)) {
 			netdev_dbg(vif->dev,
 				   "Can't allocate a skb in start_xmit.\n");
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1092,18 +1092,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 			struct xen_netif_extra_info *gso;
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
-			if (netbk_set_skb_gso(vif, skb, gso)) {
+			if (xenvif_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1140,17 +1140,17 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 
 		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(vif,
+		request_gop = xenvif_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xen_netbk_check_rx_xenvif(vif);
+		xenvif_check_rx_xenvif(vif);
 
 		if ((gop-vif->tx_copy_ops) >= ARRAY_SIZE(vif->tx_copy_ops))
 			break;
@@ -1159,13 +1159,13 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif)
 	return gop - vif->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xenvif *vif,
-				int *work_done, int budget)
+static int xenvif_tx_submit(struct xenvif *vif, int budget)
 {
 	struct gnttab_copy *gop = vif->tx_copy_ops;
 	struct sk_buff *skb;
+	int work_done = 0;
 
-	while ((*work_done < budget) &&
+	while ((work_done < budget) &&
 	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
@@ -1175,7 +1175,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		txp = &vif->pending_tx_info[pending_idx].req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
+		if (unlikely(xenvif_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1192,7 +1192,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1200,7 +1200,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(vif, skb);
+		xenvif_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1225,33 +1225,35 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;\
 
-		(*work_done)++;
+		work_done++;
 
 		xenvif_receive_skb(vif, skb);
 	}
+
+	return work_done;
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
+int xenvif_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
 	if (unlikely(!tx_work_todo(vif)))
-		return;
+		return 0;
 
-	nr_gops = xen_netbk_tx_build_gops(vif);
+	nr_gops = xenvif_tx_build_gops(vif);
 
 	if (nr_gops == 0)
-		return;
+		return 0;
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
 					vif->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(vif, work_done, budget);
+	return xenvif_tx_submit(vif, budget);
 }
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx)
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
@@ -1330,7 +1332,7 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
 		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
@@ -1340,9 +1342,9 @@ void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 					vif->rx.sring);
 }
 
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref)
 {
 	void *addr;
 	struct xen_netif_tx_sring *txs;
@@ -1371,11 +1373,11 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	return 0;
 
 err:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
-int xen_netbk_kthread(void *data)
+int xenvif_kthread(void *data)
 {
 	struct xenvif *vif = data;
 
@@ -1389,7 +1391,7 @@ int xen_netbk_kthread(void *data)
 			break;
 
 		if (rx_work_todo(vif))
-			xen_netbk_rx_action(vif);
+			xenvif_rx_action(vif);
 	}
 
 	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 Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTe-0005dx-L6; Fri, 13 Jan 2012 16:59:42 +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 1RlkTc-0005d1-UH
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326473972!8177955!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20099 invoked from network); 13 Jan 2012 16:59:34 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:59:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20853678"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59: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, 13 Jan 2012 11:59:32 -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 q0DGxQED016212;
	Fri, 13 Jan 2012 08:59:31 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:05 +0000
Message-ID: <1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 2/6] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Enables users to unload netback module.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   14 ++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..263df73 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -120,6 +120,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 26af7b7..dd10c0d 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1653,5 +1653,19 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int i;
+	for (i = 0; i < xen_netbk_group_nr; i++) {
+		struct xen_netbk *netbk = &xen_netbk[i];
+		del_timer(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+	page_pool_destroy();
+	xenvif_xenbus_exit();
+}
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTg-0005eF-1g; Fri, 13 Jan 2012 16:59:44 +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 1RlkTd-0005d3-Un
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326473974!10818882!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6238 invoked from network); 13 Jan 2012 16:59:35 -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;
	13 Jan 2012 16:59:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="177465152"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 11:59:29 -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 q0DGxQEB016212;
	Fri, 13 Jan 2012 08:59:27 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:03 +0000
Message-ID: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [RFC PATCH] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A new netback implementation which includes three major features:

 - Global page pool support
 - NAPI + kthread 1:1 model
 - Netback internal name changes

This patch series is the foundation of furture work. So it is better
to get it right first. Patch 1 and 3 have the real meat.

The first benifit of 1:1 model will be scheduling fairness.

The rational behind a global page pool is that we need to limit
overall RAM consumed by all vifs.

Utilization of NAPI enables the possibility to mitigate
interrupts/events, but this is not yet done.

Netback internal changes cleans up the code structure after switching
to 1:1 model. It also prepares netback for further code layout
changes.


---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |   94 +++--
 drivers/net/xen-netback/interface.c |  115 ++++--
 drivers/net/xen-netback/netback.c   |  743 +++++++++++------------------------
 drivers/net/xen-netback/page_pool.c |  183 +++++++++
 drivers/net/xen-netback/page_pool.h |   61 +++
 drivers/net/xen-netback/xenbus.c    |    6 +-
 7 files changed, 620 insertions(+), 584 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTh-0005ep-FJ; Fri, 13 Jan 2012 16:59:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RlkTg-0005d9-0h
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326473976!7063596!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9721 invoked from network); 13 Jan 2012 16:59:37 -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;
	13 Jan 2012 16:59:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20853680"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59: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, 13 Jan 2012 11:59:36 -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 q0DGxQEF016212;
	Fri, 13 Jan 2012 08:59:34 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:07 +0000
Message-ID: <1326473949-22389-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 4/6] netback: add module get/put operations
	along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If there is vif running and user unloads netback, it will certainly
cause problems.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 93cb212..3126028 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -405,4 +407,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	module_put(THIS_MODULE);
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTh-0005ep-FJ; Fri, 13 Jan 2012 16:59:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RlkTg-0005d9-0h
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326473976!7063596!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9721 invoked from network); 13 Jan 2012 16:59:37 -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;
	13 Jan 2012 16:59:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20853680"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59: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, 13 Jan 2012 11:59:36 -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 q0DGxQEF016212;
	Fri, 13 Jan 2012 08:59:34 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:07 +0000
Message-ID: <1326473949-22389-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 4/6] netback: add module get/put operations
	along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If there is vif running and user unloads netback, it will certainly
cause problems.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 93cb212..3126028 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -405,4 +407,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	module_put(THIS_MODULE);
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTg-0005eF-1g; Fri, 13 Jan 2012 16:59:44 +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 1RlkTd-0005d3-Un
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326473974!10818882!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6238 invoked from network); 13 Jan 2012 16:59:35 -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;
	13 Jan 2012 16:59:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="177465152"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 11:59:29 -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 q0DGxQEB016212;
	Fri, 13 Jan 2012 08:59:27 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:03 +0000
Message-ID: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Subject: [Xen-devel] [RFC PATCH] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A new netback implementation which includes three major features:

 - Global page pool support
 - NAPI + kthread 1:1 model
 - Netback internal name changes

This patch series is the foundation of furture work. So it is better
to get it right first. Patch 1 and 3 have the real meat.

The first benifit of 1:1 model will be scheduling fairness.

The rational behind a global page pool is that we need to limit
overall RAM consumed by all vifs.

Utilization of NAPI enables the possibility to mitigate
interrupts/events, but this is not yet done.

Netback internal changes cleans up the code structure after switching
to 1:1 model. It also prepares netback for further code layout
changes.


---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |   94 +++--
 drivers/net/xen-netback/interface.c |  115 ++++--
 drivers/net/xen-netback/netback.c   |  743 +++++++++++------------------------
 drivers/net/xen-netback/page_pool.c |  183 +++++++++
 drivers/net/xen-netback/page_pool.h |   61 +++
 drivers/net/xen-netback/xenbus.c    |    6 +-
 7 files changed, 620 insertions(+), 584 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTh-0005ez-RU; Fri, 13 Jan 2012 16:59:45 +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 1RlkTg-0005dB-Jx
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326473974!10818882!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6334 invoked from network); 13 Jan 2012 16:59:38 -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;
	13 Jan 2012 16:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="177465179"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59: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, 13 Jan 2012 11:59:34 -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 q0DGxQEE016212;
	Fri, 13 Jan 2012 08:59:32 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:06 +0000
Message-ID: <1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements 1:1 model netback. We utilizes NAPI and kthread
to do the weight-lifting job:

  - NAPI is used for guest side TX (host side RX)
  - kthread is used for guest side RX (host side TX)

This model provides better scheduling fairness among vifs. It also
lays the foundation for future work.

The major defect for the current implementation is that in the NAPI
poll handler we don't actually disable interrupt. Xen stuff is
different from real hardware, it requires some other tuning of ring
macros.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   33 ++--
 drivers/net/xen-netback/interface.c |   92 +++++++---
 drivers/net/xen-netback/netback.c   |  363 ++++++++++-------------------------
 drivers/net/xen-netback/xenbus.c    |    1 -
 4 files changed, 183 insertions(+), 306 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 263df73..1f6156d 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -55,14 +55,17 @@ struct xenvif {
 	/* Reference to netback processing backend. */
 	struct xen_netbk *netbk;
 
+	/* Use NAPI for guest TX */
+	struct napi_struct napi;
+	/* Use kthread for guest RX */
+	struct task_struct *task;
+	wait_queue_head_t wq;
+
 	u8               fe_dev_addr[6];
 
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* List of frontends to notify after a batch of frames sent. */
-	struct list_head notify_list;
-
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
@@ -93,11 +96,7 @@ struct xenvif {
 	unsigned long rx_gso_checksum_fixup;
 
 	/* Miscellaneous private stuff. */
-	struct list_head schedule_list;
-	atomic_t         refcnt;
 	struct net_device *dev;
-
-	wait_queue_head_t waiting_to_free;
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -116,9 +115,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
-void xenvif_get(struct xenvif *vif);
-void xenvif_put(struct xenvif *vif);
-
 int xenvif_xenbus_init(void);
 void xenvif_xenbus_exit(void);
 
@@ -134,14 +130,6 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 				 grant_ref_t tx_ring_ref,
 				 grant_ref_t rx_ring_ref);
 
-/* (De)Register a xenvif with the netback backend. */
-void xen_netbk_add_xenvif(struct xenvif *vif);
-void xen_netbk_remove_xenvif(struct xenvif *vif);
-
-/* (De)Schedule backend processing for a xenvif */
-void xen_netbk_schedule_xenvif(struct xenvif *vif);
-void xen_netbk_deschedule_xenvif(struct xenvif *vif);
-
 /* Check for SKBs from frontend and schedule backend processing */
 void xen_netbk_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
@@ -155,4 +143,13 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+/* Allocate and free xen_netbk structure */
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
+void xen_netbk_free_netbk(struct xen_netbk *netbk);
+
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
+void xen_netbk_rx_action(struct xen_netbk *netbk);
+
+int xen_netbk_kthread(void *data);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1825629..93cb212 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -30,6 +30,7 @@
 
 #include "common.h"
 
+#include <linux/kthread.h>
 #include <linux/ethtool.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
@@ -38,17 +39,7 @@
 #include <asm/xen/hypercall.h>
 
 #define XENVIF_QUEUE_LENGTH 32
-
-void xenvif_get(struct xenvif *vif)
-{
-	atomic_inc(&vif->refcnt);
-}
-
-void xenvif_put(struct xenvif *vif)
-{
-	if (atomic_dec_and_test(&vif->refcnt))
-		wake_up(&vif->waiting_to_free);
-}
+#define XENVIF_NAPI_WEIGHT  XENVIF_QUEUE_LENGTH
 
 int xenvif_schedulable(struct xenvif *vif)
 {
@@ -67,14 +58,37 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (vif->netbk == NULL)
 		return IRQ_NONE;
 
-	xen_netbk_schedule_xenvif(vif);
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
+	if (likely(napi_schedule_prep(&vif->napi)))
+		__napi_schedule(&vif->napi);
+
 	return IRQ_HANDLED;
 }
 
+static int xenvif_poll(struct napi_struct *napi, int budget)
+{
+	struct xenvif *vif = container_of(napi, struct xenvif, napi);
+	int work_done = 0;
+
+	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+
+	if (work_done < budget) {
+		int more_to_do = 0;
+		unsigned long flag;
+		local_irq_save(flag);
+
+		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
+		if (!more_to_do)
+			__napi_complete(napi);
+
+		local_irq_restore(flag);
+	}
+
+	return work_done;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -90,7 +104,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Reserve ring slots for the worst-case number of fragments. */
 	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
-	xenvif_get(vif);
 
 	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
 		netif_stop_queue(dev);
@@ -107,7 +120,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	netif_rx_ni(skb);
+	netif_receive_skb(skb);
 }
 
 void xenvif_notify_tx_completion(struct xenvif *vif)
@@ -124,16 +137,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 
 static void xenvif_up(struct xenvif *vif)
 {
-	xen_netbk_add_xenvif(vif);
+	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
+	napi_disable(&vif->napi);
 	disable_irq(vif->irq);
-	xen_netbk_deschedule_xenvif(vif);
-	xen_netbk_remove_xenvif(vif);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -259,14 +271,11 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk  = NULL;
+	vif->netbk = NULL;
+
 	vif->can_sg = 1;
 	vif->csum = 1;
-	atomic_set(&vif->refcnt, 1);
-	init_waitqueue_head(&vif->waiting_to_free);
 	vif->dev = dev;
-	INIT_LIST_HEAD(&vif->schedule_list);
-	INIT_LIST_HEAD(&vif->notify_list);
 
 	vif->credit_bytes = vif->remaining_credit = ~0UL;
 	vif->credit_usec  = 0UL;
@@ -290,6 +299,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	memset(dev->dev_addr, 0xFF, ETH_ALEN);
 	dev->dev_addr[0] &= ~0x01;
 
+	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
+
 	netif_carrier_off(dev);
 
 	err = register_netdev(dev);
@@ -324,7 +335,23 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
+	vif->netbk = xen_netbk_alloc_netbk(vif);
+	if (!vif->netbk) {
+		pr_warn("Could not allocate xen_netbk\n");
+		err = -ENOMEM;
+		goto err_unbind;
+	}
+
+
+	init_waitqueue_head(&vif->wq);
+	vif->task = kthread_create(xen_netbk_kthread,
+				   (void *)vif,
+				   "vif%d.%d", vif->domid, vif->handle);
+	if (IS_ERR(vif->task)) {
+		pr_warn("Could not create kthread\n");
+		err = PTR_ERR(vif->task);
+		goto err_free_netbk;
+	}
 
 	rtnl_lock();
 	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
@@ -335,7 +362,13 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		xenvif_up(vif);
 	rtnl_unlock();
 
+	wake_up_process(vif->task);
+
 	return 0;
+err_free_netbk:
+	xen_netbk_free_netbk(vif->netbk);
+err_unbind:
+	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
@@ -345,17 +378,22 @@ err:
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
 		netif_carrier_off(dev); /* discard queued packets */
 		if (netif_running(dev))
 			xenvif_down(vif);
 		rtnl_unlock();
-		xenvif_put(vif);
 	}
 
-	atomic_dec(&vif->refcnt);
-	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
+	if (vif->task)
+		kthread_stop(vif->task);
+
+	if (vif->netbk)
+		xen_netbk_free_netbk(vif->netbk);
+
+	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index dd10c0d..e486fd6 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -49,7 +49,6 @@
 
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
-	struct xenvif *vif;
 };
 typedef unsigned int pending_ring_idx_t;
 
@@ -67,24 +66,16 @@ struct netbk_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
-	wait_queue_head_t wq;
-	struct task_struct *task;
-
 	struct sk_buff_head rx_queue;
 	struct sk_buff_head tx_queue;
 
-	struct timer_list net_timer;
-
 	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
 	struct list_head net_schedule_list;
 
-	/* Protect the net_schedule_list in netif. */
-	spinlock_t net_schedule_list_lock;
-
-	atomic_t netfront_count;
+	struct xenvif *vif;
 
 	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
@@ -100,42 +91,14 @@ struct xen_netbk {
 	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
-static struct xen_netbk *xen_netbk;
-static int xen_netbk_group_nr;
-
-void xen_netbk_add_xenvif(struct xenvif *vif)
-{
-	int i;
-	int min_netfront_count;
-	int min_group = 0;
-	struct xen_netbk *netbk;
-
-	min_netfront_count = atomic_read(&xen_netbk[0].netfront_count);
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		int netfront_count = atomic_read(&xen_netbk[i].netfront_count);
-		if (netfront_count < min_netfront_count) {
-			min_group = i;
-			min_netfront_count = netfront_count;
-		}
-	}
-
-	netbk = &xen_netbk[min_group];
-
-	vif->netbk = netbk;
-	atomic_inc(&netbk->netfront_count);
-}
-
-void xen_netbk_remove_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	vif->netbk = NULL;
-	atomic_dec(&netbk->netfront_count);
-}
-
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
+
+static inline int tx_work_todo(struct xen_netbk *netbk);
+static inline int rx_work_todo(struct xen_netbk *netbk);
+
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
 					     s8       st,
@@ -186,11 +149,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
 		netbk->pending_prod + netbk->pending_cons;
 }
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
-{
-	wake_up(&netbk->wq);
-}
-
 static int max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
@@ -379,7 +337,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 
 			src_pend = &netbk->pending_tx_info[idx];
 
-			copy_gop->source.domid = src_pend->vif->domid;
+			copy_gop->source.domid = netbk->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -537,11 +495,18 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_rx_action(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xen_netbk *netbk)
 {
-	struct xenvif *vif = NULL, *tmp;
+	struct xenvif *vif = netbk->vif;
+
+	wake_up(&vif->wq);
+}
+
+void xen_netbk_rx_action(struct xen_netbk *netbk)
+{
+	struct xenvif *vif = NULL;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -551,6 +516,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int count;
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
 		.copy  = netbk->grant_copy_op,
@@ -651,25 +617,19 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
-		if (ret && list_empty(&vif->notify_list))
-			list_add_tail(&vif->notify_list, &notify);
+		if (ret)
+			need_to_notify = 1;
 
 		xenvif_notify_tx_completion(vif);
 
-		xenvif_put(vif);
 		npo.meta_cons += sco->meta_slots_used;
 		dev_kfree_skb(skb);
 	}
 
-	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
+	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
-		list_del_init(&vif->notify_list);
-	}
 
-	/* More work to do? */
-	if (!skb_queue_empty(&netbk->rx_queue) &&
-			!timer_pending(&netbk->net_timer))
+	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
 }
 
@@ -682,86 +642,17 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 	xen_netbk_kick_thread(netbk);
 }
 
-static void xen_netbk_alarm(unsigned long data)
-{
-	struct xen_netbk *netbk = (struct xen_netbk *)data;
-	xen_netbk_kick_thread(netbk);
-}
-
-static int __on_net_schedule_list(struct xenvif *vif)
-{
-	return !list_empty(&vif->schedule_list);
-}
-
-/* Must be called with net_schedule_list_lock held */
-static void remove_from_net_schedule_list(struct xenvif *vif)
-{
-	if (likely(__on_net_schedule_list(vif))) {
-		list_del_init(&vif->schedule_list);
-		xenvif_put(vif);
-	}
-}
-
-static struct xenvif *poll_net_schedule_list(struct xen_netbk *netbk)
-{
-	struct xenvif *vif = NULL;
-
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	if (list_empty(&netbk->net_schedule_list))
-		goto out;
-
-	vif = list_first_entry(&netbk->net_schedule_list,
-			       struct xenvif, schedule_list);
-	if (!vif)
-		goto out;
-
-	xenvif_get(vif);
-
-	remove_from_net_schedule_list(vif);
-out:
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-	return vif;
-}
-
-void xen_netbk_schedule_xenvif(struct xenvif *vif)
-{
-	unsigned long flags;
-	struct xen_netbk *netbk = vif->netbk;
-
-	if (__on_net_schedule_list(vif))
-		goto kick;
-
-	spin_lock_irqsave(&netbk->net_schedule_list_lock, flags);
-	if (!__on_net_schedule_list(vif) &&
-	    likely(xenvif_schedulable(vif))) {
-		list_add_tail(&vif->schedule_list, &netbk->net_schedule_list);
-		xenvif_get(vif);
-	}
-	spin_unlock_irqrestore(&netbk->net_schedule_list_lock, flags);
-
-kick:
-	smp_mb();
-	if ((nr_pending_reqs(netbk) < (MAX_PENDING_REQS/2)) &&
-	    !list_empty(&netbk->net_schedule_list))
-		xen_netbk_kick_thread(netbk);
-}
-
-void xen_netbk_deschedule_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	remove_from_net_schedule_list(vif);
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-}
-
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
 	RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
 
+	/* In this check function, we are supposed to do fe's rx,
+	 * which means be's tx */
+
 	if (more_to_do)
-		xen_netbk_schedule_xenvif(vif);
+		napi_schedule(&vif->napi);
 }
 
 static void tx_add_credit(struct xenvif *vif)
@@ -804,7 +695,6 @@ static void netbk_tx_err(struct xenvif *vif,
 	} while (1);
 	vif->tx.req_cons = cons;
 	xen_netbk_check_rx_xenvif(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
@@ -901,8 +791,6 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		gop++;
 
 		memcpy(&pending_tx_info[pending_idx].req, txp, sizeof(*txp));
-		xenvif_get(vif);
-		pending_tx_info[pending_idx].vif = vif;
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -916,7 +804,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
+	struct xenvif *vif = netbk->vif;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -930,7 +818,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		txp = &pending_tx_info[pending_idx].req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -956,7 +843,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1167,10 +1053,9 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
+	struct xenvif *vif = netbk->vif;
 
-	while (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-		!list_empty(&netbk->net_schedule_list)) {
-		struct xenvif *vif;
+	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1181,26 +1066,19 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		unsigned int data_len;
 		pending_ring_idx_t index;
 
-		/* Get a netif from the list with work to do. */
-		vif = poll_net_schedule_list(netbk);
-		if (!vif)
-			continue;
-
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		idx = vif->tx.req_cons;
 		rmb(); /* Ensure that we see the request before we copy it. */
 		memcpy(&txreq, RING_GET_REQUEST(&vif->tx, idx), sizeof(txreq));
 
-		/* Credit-based scheduling. */
+		/* Credit-based traffic shaping. */
 		if (txreq.size > vif->remaining_credit &&
 		    tx_credit_exceeded(vif, txreq.size)) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		vif->remaining_credit -= txreq.size;
@@ -1215,14 +1093,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
 			netbk_tx_err(vif, &txreq, idx - ret);
-			continue;
+			break;
 		}
 		idx += ret;
 
@@ -1230,7 +1108,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
@@ -1240,7 +1118,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		index = pending_index(netbk->pending_cons);
@@ -1269,7 +1147,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			if (netbk_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
@@ -1278,7 +1156,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		gop->source.u.ref = txreq.gref;
@@ -1296,7 +1174,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		memcpy(&netbk->pending_tx_info[pending_idx].req,
 		       &txreq, sizeof(txreq));
-		netbk->pending_tx_info[pending_idx].vif = vif;
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1320,7 +1197,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (request_gop == NULL) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 		gop = request_gop;
 
@@ -1334,19 +1211,20 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	return gop - netbk->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk)
+static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = netbk->tx_copy_ops;
 	struct sk_buff *skb;
+	struct xenvif *vif = netbk->vif;
 
-	while ((skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	while ((*work_done < budget) &&
+	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
-		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
 
 		pending_idx = *((u16 *)skb->data);
-		vif = netbk->pending_tx_info[pending_idx].vif;
 		txp = &netbk->pending_tx_info[pending_idx].req;
 
 		/* Check the remap error code. */
@@ -1398,18 +1276,23 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		}
 
 		vif->dev->stats.rx_bytes += skb->len;
-		vif->dev->stats.rx_packets++;
+		vif->dev->stats.rx_packets++;\
+
+		(*work_done)++;
 
 		xenvif_receive_skb(vif, skb);
 	}
 }
 
 /* Called after netfront has transmitted */
-static void xen_netbk_tx_action(struct xen_netbk *netbk)
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
+	if (unlikely(!tx_work_todo(netbk)))
+		return;
+
 	nr_gops = xen_netbk_tx_build_gops(netbk);
 
 	if (nr_gops == 0)
@@ -1418,13 +1301,12 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 					netbk->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk);
-
+	xen_netbk_tx_submit(netbk, work_done, budget);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 {
-	struct xenvif *vif;
+	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 
@@ -1434,15 +1316,11 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	pending_tx_info = &netbk->pending_tx_info[pending_idx];
 
-	vif = pending_tx_info->vif;
-
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
 
-	xenvif_put(vif);
-
 	page_pool_put(netbk->mmap_pages[pending_idx]);
 
 	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
@@ -1499,37 +1377,13 @@ static inline int rx_work_todo(struct xen_netbk *netbk)
 
 static inline int tx_work_todo(struct xen_netbk *netbk)
 {
-
-	if (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-			!list_empty(&netbk->net_schedule_list))
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
+	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
 }
 
-static int xen_netbk_kthread(void *data)
-{
-	struct xen_netbk *netbk = data;
-	while (!kthread_should_stop()) {
-		wait_event_interruptible(netbk->wq,
-				rx_work_todo(netbk) ||
-				tx_work_todo(netbk) ||
-				kthread_should_stop());
-		cond_resched();
-
-		if (kthread_should_stop())
-			break;
-
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
-
-		if (tx_work_todo(netbk))
-			xen_netbk_tx_action(netbk);
-	}
-
-	return 0;
-}
-
 void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
@@ -1575,78 +1429,74 @@ err:
 	return err;
 }
 
-static int __init netback_init(void)
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 {
 	int i;
-	int rc = 0;
-	int group;
-
-	if (!xen_domain())
-		return -ENODEV;
+	struct xen_netbk *netbk;
 
-	xen_netbk_group_nr = num_online_cpus();
-	xen_netbk = vzalloc(sizeof(struct xen_netbk) * xen_netbk_group_nr);
-	if (!xen_netbk) {
+	netbk = vzalloc(sizeof(struct xen_netbk));
+	if (!netbk) {
 		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return -ENOMEM;
+		return NULL;
 	}
 
-	for (group = 0; group < xen_netbk_group_nr; group++) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		skb_queue_head_init(&netbk->rx_queue);
-		skb_queue_head_init(&netbk->tx_queue);
-
-		init_timer(&netbk->net_timer);
-		netbk->net_timer.data = (unsigned long)netbk;
-		netbk->net_timer.function = xen_netbk_alarm;
-
-		netbk->pending_cons = 0;
-		netbk->pending_prod = MAX_PENDING_REQS;
-		for (i = 0; i < MAX_PENDING_REQS; i++)
-			netbk->pending_ring[i] = i;
-
-		init_waitqueue_head(&netbk->wq);
-		netbk->task = kthread_create(xen_netbk_kthread,
-					     (void *)netbk,
-					     "netback/%u", group);
-
-		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_create() fails at netback\n");
-			del_timer(&netbk->net_timer);
-			rc = PTR_ERR(netbk->task);
-			goto failed_init;
-		}
+	netbk->vif = vif;
+
+	skb_queue_head_init(&netbk->rx_queue);
+	skb_queue_head_init(&netbk->tx_queue);
 
-		kthread_bind(netbk->task, group);
+	netbk->pending_cons = 0;
+	netbk->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->pending_ring[i] = i;
 
-		INIT_LIST_HEAD(&netbk->net_schedule_list);
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->mmap_pages[i] = INVALID_ENTRY;
 
-		spin_lock_init(&netbk->net_schedule_list_lock);
+	return netbk;
+}
 
-		atomic_set(&netbk->netfront_count, 0);
+void xen_netbk_free_netbk(struct xen_netbk *netbk)
+{
+	vfree(netbk);
+}
 
-		wake_up_process(netbk->task);
+int xen_netbk_kthread(void *data)
+{
+	struct xenvif *vif = data;
+	struct xen_netbk *netbk = vif->netbk;
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(vif->wq,
+					 rx_work_todo(netbk) ||
+					 kthread_should_stop());
+		cond_resched();
+
+		if (kthread_should_stop())
+			break;
+
+		if (rx_work_todo(netbk))
+			xen_netbk_rx_action(netbk);
 	}
 
+	return 0;
+}
+
+
+static int __init netback_init(void)
+{
+	int rc = 0;
+
+	if (!xen_domain())
+		return -ENODEV;
+
 	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
-	rc = xenvif_xenbus_init();
-	if (rc)
-		goto pool_failed_init;
-
-	return 0;
+	return xenvif_xenbus_init();
 
-pool_failed_init:
-	page_pool_destroy();
 failed_init:
-	while (--group >= 0) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	return rc;
 
 }
@@ -1655,13 +1505,6 @@ module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
-	int i;
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		struct xen_netbk *netbk = &xen_netbk[i];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	page_pool_destroy();
 	xenvif_xenbus_exit();
 }
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..f1e89ca 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -387,7 +387,6 @@ static void connect(struct backend_info *be)
 	netif_wake_queue(be->vif->dev);
 }
 
-
 static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTh-0005ez-RU; Fri, 13 Jan 2012 16:59:45 +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 1RlkTg-0005dB-Jx
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326473974!10818882!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6334 invoked from network); 13 Jan 2012 16:59:38 -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;
	13 Jan 2012 16:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="177465179"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59: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, 13 Jan 2012 11:59:34 -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 q0DGxQEE016212;
	Fri, 13 Jan 2012 08:59:32 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:06 +0000
Message-ID: <1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements 1:1 model netback. We utilizes NAPI and kthread
to do the weight-lifting job:

  - NAPI is used for guest side TX (host side RX)
  - kthread is used for guest side RX (host side TX)

This model provides better scheduling fairness among vifs. It also
lays the foundation for future work.

The major defect for the current implementation is that in the NAPI
poll handler we don't actually disable interrupt. Xen stuff is
different from real hardware, it requires some other tuning of ring
macros.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   33 ++--
 drivers/net/xen-netback/interface.c |   92 +++++++---
 drivers/net/xen-netback/netback.c   |  363 ++++++++++-------------------------
 drivers/net/xen-netback/xenbus.c    |    1 -
 4 files changed, 183 insertions(+), 306 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 263df73..1f6156d 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -55,14 +55,17 @@ struct xenvif {
 	/* Reference to netback processing backend. */
 	struct xen_netbk *netbk;
 
+	/* Use NAPI for guest TX */
+	struct napi_struct napi;
+	/* Use kthread for guest RX */
+	struct task_struct *task;
+	wait_queue_head_t wq;
+
 	u8               fe_dev_addr[6];
 
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* List of frontends to notify after a batch of frames sent. */
-	struct list_head notify_list;
-
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
@@ -93,11 +96,7 @@ struct xenvif {
 	unsigned long rx_gso_checksum_fixup;
 
 	/* Miscellaneous private stuff. */
-	struct list_head schedule_list;
-	atomic_t         refcnt;
 	struct net_device *dev;
-
-	wait_queue_head_t waiting_to_free;
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -116,9 +115,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
-void xenvif_get(struct xenvif *vif);
-void xenvif_put(struct xenvif *vif);
-
 int xenvif_xenbus_init(void);
 void xenvif_xenbus_exit(void);
 
@@ -134,14 +130,6 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 				 grant_ref_t tx_ring_ref,
 				 grant_ref_t rx_ring_ref);
 
-/* (De)Register a xenvif with the netback backend. */
-void xen_netbk_add_xenvif(struct xenvif *vif);
-void xen_netbk_remove_xenvif(struct xenvif *vif);
-
-/* (De)Schedule backend processing for a xenvif */
-void xen_netbk_schedule_xenvif(struct xenvif *vif);
-void xen_netbk_deschedule_xenvif(struct xenvif *vif);
-
 /* Check for SKBs from frontend and schedule backend processing */
 void xen_netbk_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
@@ -155,4 +143,13 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+/* Allocate and free xen_netbk structure */
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
+void xen_netbk_free_netbk(struct xen_netbk *netbk);
+
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
+void xen_netbk_rx_action(struct xen_netbk *netbk);
+
+int xen_netbk_kthread(void *data);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1825629..93cb212 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -30,6 +30,7 @@
 
 #include "common.h"
 
+#include <linux/kthread.h>
 #include <linux/ethtool.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
@@ -38,17 +39,7 @@
 #include <asm/xen/hypercall.h>
 
 #define XENVIF_QUEUE_LENGTH 32
-
-void xenvif_get(struct xenvif *vif)
-{
-	atomic_inc(&vif->refcnt);
-}
-
-void xenvif_put(struct xenvif *vif)
-{
-	if (atomic_dec_and_test(&vif->refcnt))
-		wake_up(&vif->waiting_to_free);
-}
+#define XENVIF_NAPI_WEIGHT  XENVIF_QUEUE_LENGTH
 
 int xenvif_schedulable(struct xenvif *vif)
 {
@@ -67,14 +58,37 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (vif->netbk == NULL)
 		return IRQ_NONE;
 
-	xen_netbk_schedule_xenvif(vif);
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
+	if (likely(napi_schedule_prep(&vif->napi)))
+		__napi_schedule(&vif->napi);
+
 	return IRQ_HANDLED;
 }
 
+static int xenvif_poll(struct napi_struct *napi, int budget)
+{
+	struct xenvif *vif = container_of(napi, struct xenvif, napi);
+	int work_done = 0;
+
+	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+
+	if (work_done < budget) {
+		int more_to_do = 0;
+		unsigned long flag;
+		local_irq_save(flag);
+
+		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
+		if (!more_to_do)
+			__napi_complete(napi);
+
+		local_irq_restore(flag);
+	}
+
+	return work_done;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -90,7 +104,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Reserve ring slots for the worst-case number of fragments. */
 	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
-	xenvif_get(vif);
 
 	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
 		netif_stop_queue(dev);
@@ -107,7 +120,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	netif_rx_ni(skb);
+	netif_receive_skb(skb);
 }
 
 void xenvif_notify_tx_completion(struct xenvif *vif)
@@ -124,16 +137,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 
 static void xenvif_up(struct xenvif *vif)
 {
-	xen_netbk_add_xenvif(vif);
+	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
+	napi_disable(&vif->napi);
 	disable_irq(vif->irq);
-	xen_netbk_deschedule_xenvif(vif);
-	xen_netbk_remove_xenvif(vif);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -259,14 +271,11 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk  = NULL;
+	vif->netbk = NULL;
+
 	vif->can_sg = 1;
 	vif->csum = 1;
-	atomic_set(&vif->refcnt, 1);
-	init_waitqueue_head(&vif->waiting_to_free);
 	vif->dev = dev;
-	INIT_LIST_HEAD(&vif->schedule_list);
-	INIT_LIST_HEAD(&vif->notify_list);
 
 	vif->credit_bytes = vif->remaining_credit = ~0UL;
 	vif->credit_usec  = 0UL;
@@ -290,6 +299,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	memset(dev->dev_addr, 0xFF, ETH_ALEN);
 	dev->dev_addr[0] &= ~0x01;
 
+	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
+
 	netif_carrier_off(dev);
 
 	err = register_netdev(dev);
@@ -324,7 +335,23 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
+	vif->netbk = xen_netbk_alloc_netbk(vif);
+	if (!vif->netbk) {
+		pr_warn("Could not allocate xen_netbk\n");
+		err = -ENOMEM;
+		goto err_unbind;
+	}
+
+
+	init_waitqueue_head(&vif->wq);
+	vif->task = kthread_create(xen_netbk_kthread,
+				   (void *)vif,
+				   "vif%d.%d", vif->domid, vif->handle);
+	if (IS_ERR(vif->task)) {
+		pr_warn("Could not create kthread\n");
+		err = PTR_ERR(vif->task);
+		goto err_free_netbk;
+	}
 
 	rtnl_lock();
 	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
@@ -335,7 +362,13 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		xenvif_up(vif);
 	rtnl_unlock();
 
+	wake_up_process(vif->task);
+
 	return 0;
+err_free_netbk:
+	xen_netbk_free_netbk(vif->netbk);
+err_unbind:
+	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
@@ -345,17 +378,22 @@ err:
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
 		netif_carrier_off(dev); /* discard queued packets */
 		if (netif_running(dev))
 			xenvif_down(vif);
 		rtnl_unlock();
-		xenvif_put(vif);
 	}
 
-	atomic_dec(&vif->refcnt);
-	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
+	if (vif->task)
+		kthread_stop(vif->task);
+
+	if (vif->netbk)
+		xen_netbk_free_netbk(vif->netbk);
+
+	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index dd10c0d..e486fd6 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -49,7 +49,6 @@
 
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
-	struct xenvif *vif;
 };
 typedef unsigned int pending_ring_idx_t;
 
@@ -67,24 +66,16 @@ struct netbk_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
-	wait_queue_head_t wq;
-	struct task_struct *task;
-
 	struct sk_buff_head rx_queue;
 	struct sk_buff_head tx_queue;
 
-	struct timer_list net_timer;
-
 	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
 	struct list_head net_schedule_list;
 
-	/* Protect the net_schedule_list in netif. */
-	spinlock_t net_schedule_list_lock;
-
-	atomic_t netfront_count;
+	struct xenvif *vif;
 
 	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
@@ -100,42 +91,14 @@ struct xen_netbk {
 	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
-static struct xen_netbk *xen_netbk;
-static int xen_netbk_group_nr;
-
-void xen_netbk_add_xenvif(struct xenvif *vif)
-{
-	int i;
-	int min_netfront_count;
-	int min_group = 0;
-	struct xen_netbk *netbk;
-
-	min_netfront_count = atomic_read(&xen_netbk[0].netfront_count);
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		int netfront_count = atomic_read(&xen_netbk[i].netfront_count);
-		if (netfront_count < min_netfront_count) {
-			min_group = i;
-			min_netfront_count = netfront_count;
-		}
-	}
-
-	netbk = &xen_netbk[min_group];
-
-	vif->netbk = netbk;
-	atomic_inc(&netbk->netfront_count);
-}
-
-void xen_netbk_remove_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	vif->netbk = NULL;
-	atomic_dec(&netbk->netfront_count);
-}
-
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
+
+static inline int tx_work_todo(struct xen_netbk *netbk);
+static inline int rx_work_todo(struct xen_netbk *netbk);
+
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
 					     s8       st,
@@ -186,11 +149,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
 		netbk->pending_prod + netbk->pending_cons;
 }
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
-{
-	wake_up(&netbk->wq);
-}
-
 static int max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
@@ -379,7 +337,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 
 			src_pend = &netbk->pending_tx_info[idx];
 
-			copy_gop->source.domid = src_pend->vif->domid;
+			copy_gop->source.domid = netbk->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -537,11 +495,18 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_rx_action(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xen_netbk *netbk)
 {
-	struct xenvif *vif = NULL, *tmp;
+	struct xenvif *vif = netbk->vif;
+
+	wake_up(&vif->wq);
+}
+
+void xen_netbk_rx_action(struct xen_netbk *netbk)
+{
+	struct xenvif *vif = NULL;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -551,6 +516,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int count;
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
 		.copy  = netbk->grant_copy_op,
@@ -651,25 +617,19 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
-		if (ret && list_empty(&vif->notify_list))
-			list_add_tail(&vif->notify_list, &notify);
+		if (ret)
+			need_to_notify = 1;
 
 		xenvif_notify_tx_completion(vif);
 
-		xenvif_put(vif);
 		npo.meta_cons += sco->meta_slots_used;
 		dev_kfree_skb(skb);
 	}
 
-	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
+	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
-		list_del_init(&vif->notify_list);
-	}
 
-	/* More work to do? */
-	if (!skb_queue_empty(&netbk->rx_queue) &&
-			!timer_pending(&netbk->net_timer))
+	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
 }
 
@@ -682,86 +642,17 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 	xen_netbk_kick_thread(netbk);
 }
 
-static void xen_netbk_alarm(unsigned long data)
-{
-	struct xen_netbk *netbk = (struct xen_netbk *)data;
-	xen_netbk_kick_thread(netbk);
-}
-
-static int __on_net_schedule_list(struct xenvif *vif)
-{
-	return !list_empty(&vif->schedule_list);
-}
-
-/* Must be called with net_schedule_list_lock held */
-static void remove_from_net_schedule_list(struct xenvif *vif)
-{
-	if (likely(__on_net_schedule_list(vif))) {
-		list_del_init(&vif->schedule_list);
-		xenvif_put(vif);
-	}
-}
-
-static struct xenvif *poll_net_schedule_list(struct xen_netbk *netbk)
-{
-	struct xenvif *vif = NULL;
-
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	if (list_empty(&netbk->net_schedule_list))
-		goto out;
-
-	vif = list_first_entry(&netbk->net_schedule_list,
-			       struct xenvif, schedule_list);
-	if (!vif)
-		goto out;
-
-	xenvif_get(vif);
-
-	remove_from_net_schedule_list(vif);
-out:
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-	return vif;
-}
-
-void xen_netbk_schedule_xenvif(struct xenvif *vif)
-{
-	unsigned long flags;
-	struct xen_netbk *netbk = vif->netbk;
-
-	if (__on_net_schedule_list(vif))
-		goto kick;
-
-	spin_lock_irqsave(&netbk->net_schedule_list_lock, flags);
-	if (!__on_net_schedule_list(vif) &&
-	    likely(xenvif_schedulable(vif))) {
-		list_add_tail(&vif->schedule_list, &netbk->net_schedule_list);
-		xenvif_get(vif);
-	}
-	spin_unlock_irqrestore(&netbk->net_schedule_list_lock, flags);
-
-kick:
-	smp_mb();
-	if ((nr_pending_reqs(netbk) < (MAX_PENDING_REQS/2)) &&
-	    !list_empty(&netbk->net_schedule_list))
-		xen_netbk_kick_thread(netbk);
-}
-
-void xen_netbk_deschedule_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	remove_from_net_schedule_list(vif);
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-}
-
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
 	RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
 
+	/* In this check function, we are supposed to do fe's rx,
+	 * which means be's tx */
+
 	if (more_to_do)
-		xen_netbk_schedule_xenvif(vif);
+		napi_schedule(&vif->napi);
 }
 
 static void tx_add_credit(struct xenvif *vif)
@@ -804,7 +695,6 @@ static void netbk_tx_err(struct xenvif *vif,
 	} while (1);
 	vif->tx.req_cons = cons;
 	xen_netbk_check_rx_xenvif(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
@@ -901,8 +791,6 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		gop++;
 
 		memcpy(&pending_tx_info[pending_idx].req, txp, sizeof(*txp));
-		xenvif_get(vif);
-		pending_tx_info[pending_idx].vif = vif;
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -916,7 +804,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
+	struct xenvif *vif = netbk->vif;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -930,7 +818,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		txp = &pending_tx_info[pending_idx].req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -956,7 +843,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1167,10 +1053,9 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
+	struct xenvif *vif = netbk->vif;
 
-	while (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-		!list_empty(&netbk->net_schedule_list)) {
-		struct xenvif *vif;
+	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1181,26 +1066,19 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		unsigned int data_len;
 		pending_ring_idx_t index;
 
-		/* Get a netif from the list with work to do. */
-		vif = poll_net_schedule_list(netbk);
-		if (!vif)
-			continue;
-
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		idx = vif->tx.req_cons;
 		rmb(); /* Ensure that we see the request before we copy it. */
 		memcpy(&txreq, RING_GET_REQUEST(&vif->tx, idx), sizeof(txreq));
 
-		/* Credit-based scheduling. */
+		/* Credit-based traffic shaping. */
 		if (txreq.size > vif->remaining_credit &&
 		    tx_credit_exceeded(vif, txreq.size)) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		vif->remaining_credit -= txreq.size;
@@ -1215,14 +1093,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
 			netbk_tx_err(vif, &txreq, idx - ret);
-			continue;
+			break;
 		}
 		idx += ret;
 
@@ -1230,7 +1108,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
@@ -1240,7 +1118,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		index = pending_index(netbk->pending_cons);
@@ -1269,7 +1147,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			if (netbk_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
@@ -1278,7 +1156,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		gop->source.u.ref = txreq.gref;
@@ -1296,7 +1174,6 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		memcpy(&netbk->pending_tx_info[pending_idx].req,
 		       &txreq, sizeof(txreq));
-		netbk->pending_tx_info[pending_idx].vif = vif;
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1320,7 +1197,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (request_gop == NULL) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 		gop = request_gop;
 
@@ -1334,19 +1211,20 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	return gop - netbk->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk)
+static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = netbk->tx_copy_ops;
 	struct sk_buff *skb;
+	struct xenvif *vif = netbk->vif;
 
-	while ((skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	while ((*work_done < budget) &&
+	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
-		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
 
 		pending_idx = *((u16 *)skb->data);
-		vif = netbk->pending_tx_info[pending_idx].vif;
 		txp = &netbk->pending_tx_info[pending_idx].req;
 
 		/* Check the remap error code. */
@@ -1398,18 +1276,23 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		}
 
 		vif->dev->stats.rx_bytes += skb->len;
-		vif->dev->stats.rx_packets++;
+		vif->dev->stats.rx_packets++;\
+
+		(*work_done)++;
 
 		xenvif_receive_skb(vif, skb);
 	}
 }
 
 /* Called after netfront has transmitted */
-static void xen_netbk_tx_action(struct xen_netbk *netbk)
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
+	if (unlikely(!tx_work_todo(netbk)))
+		return;
+
 	nr_gops = xen_netbk_tx_build_gops(netbk);
 
 	if (nr_gops == 0)
@@ -1418,13 +1301,12 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 					netbk->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk);
-
+	xen_netbk_tx_submit(netbk, work_done, budget);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 {
-	struct xenvif *vif;
+	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 
@@ -1434,15 +1316,11 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	pending_tx_info = &netbk->pending_tx_info[pending_idx];
 
-	vif = pending_tx_info->vif;
-
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
 
-	xenvif_put(vif);
-
 	page_pool_put(netbk->mmap_pages[pending_idx]);
 
 	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
@@ -1499,37 +1377,13 @@ static inline int rx_work_todo(struct xen_netbk *netbk)
 
 static inline int tx_work_todo(struct xen_netbk *netbk)
 {
-
-	if (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-			!list_empty(&netbk->net_schedule_list))
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
+	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
 }
 
-static int xen_netbk_kthread(void *data)
-{
-	struct xen_netbk *netbk = data;
-	while (!kthread_should_stop()) {
-		wait_event_interruptible(netbk->wq,
-				rx_work_todo(netbk) ||
-				tx_work_todo(netbk) ||
-				kthread_should_stop());
-		cond_resched();
-
-		if (kthread_should_stop())
-			break;
-
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
-
-		if (tx_work_todo(netbk))
-			xen_netbk_tx_action(netbk);
-	}
-
-	return 0;
-}
-
 void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
@@ -1575,78 +1429,74 @@ err:
 	return err;
 }
 
-static int __init netback_init(void)
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 {
 	int i;
-	int rc = 0;
-	int group;
-
-	if (!xen_domain())
-		return -ENODEV;
+	struct xen_netbk *netbk;
 
-	xen_netbk_group_nr = num_online_cpus();
-	xen_netbk = vzalloc(sizeof(struct xen_netbk) * xen_netbk_group_nr);
-	if (!xen_netbk) {
+	netbk = vzalloc(sizeof(struct xen_netbk));
+	if (!netbk) {
 		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return -ENOMEM;
+		return NULL;
 	}
 
-	for (group = 0; group < xen_netbk_group_nr; group++) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		skb_queue_head_init(&netbk->rx_queue);
-		skb_queue_head_init(&netbk->tx_queue);
-
-		init_timer(&netbk->net_timer);
-		netbk->net_timer.data = (unsigned long)netbk;
-		netbk->net_timer.function = xen_netbk_alarm;
-
-		netbk->pending_cons = 0;
-		netbk->pending_prod = MAX_PENDING_REQS;
-		for (i = 0; i < MAX_PENDING_REQS; i++)
-			netbk->pending_ring[i] = i;
-
-		init_waitqueue_head(&netbk->wq);
-		netbk->task = kthread_create(xen_netbk_kthread,
-					     (void *)netbk,
-					     "netback/%u", group);
-
-		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_create() fails at netback\n");
-			del_timer(&netbk->net_timer);
-			rc = PTR_ERR(netbk->task);
-			goto failed_init;
-		}
+	netbk->vif = vif;
+
+	skb_queue_head_init(&netbk->rx_queue);
+	skb_queue_head_init(&netbk->tx_queue);
 
-		kthread_bind(netbk->task, group);
+	netbk->pending_cons = 0;
+	netbk->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->pending_ring[i] = i;
 
-		INIT_LIST_HEAD(&netbk->net_schedule_list);
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->mmap_pages[i] = INVALID_ENTRY;
 
-		spin_lock_init(&netbk->net_schedule_list_lock);
+	return netbk;
+}
 
-		atomic_set(&netbk->netfront_count, 0);
+void xen_netbk_free_netbk(struct xen_netbk *netbk)
+{
+	vfree(netbk);
+}
 
-		wake_up_process(netbk->task);
+int xen_netbk_kthread(void *data)
+{
+	struct xenvif *vif = data;
+	struct xen_netbk *netbk = vif->netbk;
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(vif->wq,
+					 rx_work_todo(netbk) ||
+					 kthread_should_stop());
+		cond_resched();
+
+		if (kthread_should_stop())
+			break;
+
+		if (rx_work_todo(netbk))
+			xen_netbk_rx_action(netbk);
 	}
 
+	return 0;
+}
+
+
+static int __init netback_init(void)
+{
+	int rc = 0;
+
+	if (!xen_domain())
+		return -ENODEV;
+
 	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
-	rc = xenvif_xenbus_init();
-	if (rc)
-		goto pool_failed_init;
-
-	return 0;
+	return xenvif_xenbus_init();
 
-pool_failed_init:
-	page_pool_destroy();
 failed_init:
-	while (--group >= 0) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	return rc;
 
 }
@@ -1655,13 +1505,6 @@ module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
-	int i;
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		struct xen_netbk *netbk = &xen_netbk[i];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	page_pool_destroy();
 	xenvif_xenbus_exit();
 }
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..f1e89ca 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -387,7 +387,6 @@ static void connect(struct backend_info *be)
 	netif_wake_queue(be->vif->dev);
 }
 
-
 static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTd-0005dN-0K; Fri, 13 Jan 2012 16:59:41 +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 1RlkTb-0005cy-W3
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326473972!8177955!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20056 invoked from network); 13 Jan 2012 16:59:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:59:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20853675"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59: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, 13 Jan 2012 11:59:31 -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 q0DGxQEC016212;
	Fri, 13 Jan 2012 08:59:29 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:04 +0000
Message-ID: <1326473949-22389-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 1/6] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A global page pool. Since we are moving to 1:1 model netback, it is
better to limit total RAM consumed by all the vifs.

With this patch, each vif gets page from the pool and puts the page
back when it is finished with the page.

This pool is only meant to access via exported interfaces. Internals
are subject to change when we discover new requirements for the pool.

Current exported interfaces include:

page_pool_init: pool init
page_pool_destroy: pool destruction
page_pool_get: get a page from pool
page_pool_put: put page back to pool
is_in_pool: tell whether a page belongs to the pool

Current implementation has following defects:
 - Global locking
 - No starve prevention mechanism / reservation logic

Global locking tends to cause contention on the pool. No reservation
logic may cause vif to starve. A possible solution to these two
problems will be each vif maintains its local cache and claims a
portion of the pool. However the implementation will be tricky when
coming to pool management, so let's worry about that later.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/netback.c   |   93 ++++--------------
 drivers/net/xen-netback/page_pool.c |  183 +++++++++++++++++++++++++++++++++++
 drivers/net/xen-netback/page_pool.h |   61 ++++++++++++
 4 files changed, 266 insertions(+), 73 deletions(-)
 create mode 100644 drivers/net/xen-netback/page_pool.c
 create mode 100644 drivers/net/xen-netback/page_pool.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..dc4b8b1 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 59effac..26af7b7 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -33,6 +33,7 @@
  */
 
 #include "common.h"
+#include "page_pool.h"
 
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
@@ -65,21 +66,6 @@ struct netbk_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-/* extra field used in struct page */
-union page_ext {
-	struct {
-#if BITS_PER_LONG < 64
-#define IDX_WIDTH   8
-#define GROUP_WIDTH (BITS_PER_LONG - IDX_WIDTH)
-		unsigned int group:GROUP_WIDTH;
-		unsigned int idx:IDX_WIDTH;
-#else
-		unsigned int group, idx;
-#endif
-	} e;
-	void *mapping;
-};
-
 struct xen_netbk {
 	wait_queue_head_t wq;
 	struct task_struct *task;
@@ -89,7 +75,7 @@ struct xen_netbk {
 
 	struct timer_list net_timer;
 
-	struct page *mmap_pages[MAX_PENDING_REQS];
+	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
@@ -160,7 +146,7 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
 				       u16 idx)
 {
-	return page_to_pfn(netbk->mmap_pages[idx]);
+	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
 }
 
 static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
@@ -169,45 +155,6 @@ static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
 	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
 }
 
-/* extra field used in struct page */
-static inline void set_page_ext(struct page *pg, struct xen_netbk *netbk,
-				unsigned int idx)
-{
-	unsigned int group = netbk - xen_netbk;
-	union page_ext ext = { .e = { .group = group + 1, .idx = idx } };
-
-	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
-	pg->mapping = ext.mapping;
-}
-
-static int get_page_ext(struct page *pg,
-			unsigned int *pgroup, unsigned int *pidx)
-{
-	union page_ext ext = { .mapping = pg->mapping };
-	struct xen_netbk *netbk;
-	unsigned int group, idx;
-
-	group = ext.e.group - 1;
-
-	if (group < 0 || group >= xen_netbk_group_nr)
-		return 0;
-
-	netbk = &xen_netbk[group];
-
-	idx = ext.e.idx;
-
-	if ((idx < 0) || (idx >= MAX_PENDING_REQS))
-		return 0;
-
-	if (netbk->mmap_pages[idx] != pg)
-		return 0;
-
-	*pgroup = group;
-	*pidx = idx;
-
-	return 1;
-}
-
 /*
  * This is the amount of packet we copy rather than map, so that the
  * guest can't fiddle with the contents of the headers while we do
@@ -398,8 +345,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
-	unsigned int uninitialized_var(group), uninitialized_var(idx);
-	int foreign = get_page_ext(page, &group, &idx);
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
@@ -427,7 +374,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = &xen_netbk[group];
+			struct xen_netbk *netbk = to_netbk(idx);
 			struct pending_tx_info *src_pend;
 
 			src_pend = &netbk->pending_tx_info[idx];
@@ -906,11 +853,11 @@ static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
 					 u16 pending_idx)
 {
 	struct page *page;
-	page = alloc_page(GFP_KERNEL|__GFP_COLD);
+	int idx;
+	page = page_pool_get(netbk, &idx);
 	if (!page)
 		return NULL;
-	set_page_ext(page, netbk, pending_idx);
-	netbk->mmap_pages[pending_idx] = page;
+	netbk->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
@@ -1053,7 +1000,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(netbk->mmap_pages[pending_idx]);
+		get_page(to_page(netbk->mmap_pages[pending_idx]));
 		xen_netbk_idx_release(netbk, pending_idx);
 	}
 }
@@ -1482,7 +1429,7 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	pending_ring_idx_t index;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == NULL)
+	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
 	pending_tx_info = &netbk->pending_tx_info[pending_idx];
@@ -1496,9 +1443,9 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	xenvif_put(vif);
 
-	netbk->mmap_pages[pending_idx]->mapping = 0;
-	put_page(netbk->mmap_pages[pending_idx]);
-	netbk->mmap_pages[pending_idx] = NULL;
+	page_pool_put(netbk->mmap_pages[pending_idx]);
+
+	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1681,19 +1628,21 @@ static int __init netback_init(void)
 		wake_up_process(netbk->task);
 	}
 
-	rc = xenvif_xenbus_init();
+	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto pool_failed_init;
+
 	return 0;
 
+pool_failed_init:
+	page_pool_destroy();
 failed_init:
 	while (--group >= 0) {
 		struct xen_netbk *netbk = &xen_netbk[group];
-		for (i = 0; i < MAX_PENDING_REQS; i++) {
-			if (netbk->mmap_pages[i])
-				__free_page(netbk->mmap_pages[i]);
-		}
 		del_timer(&netbk->net_timer);
 		kthread_stop(netbk->task);
 	}
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
new file mode 100644
index 0000000..8904869
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.c
@@ -0,0 +1,183 @@
+/*
+ * Global page pool for netback.
+ *
+ * Wei Liu <wei.liu2@citrix.com>
+ * Copyright (c) Citrix Systems
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "common.h"
+#include "page_pool.h"
+#include <asm/xen/page.h>
+
+static idx_t free_head;
+static int free_count;
+static unsigned long pool_size;
+static DEFINE_SPINLOCK(pool_lock);
+static struct page_pool_entry *pool;
+
+static int get_free_entry(void)
+{
+	unsigned long flag;
+	int idx;
+
+	spin_lock_irqsave(&pool_lock, flag);
+
+	if (free_count == 0) {
+		spin_unlock_irqrestore(&pool_lock, flag);
+		return -ENOSPC;
+	}
+
+	idx = free_head;
+	free_count--;
+	free_head = pool[idx].u.fl;
+	pool[idx].u.fl = INVALID_ENTRY;
+
+	spin_unlock_irqrestore(&pool_lock, flag);
+
+	return idx;
+}
+
+static void put_free_entry(idx_t idx)
+{
+	unsigned long flag;
+
+	spin_lock_irqsave(&pool_lock, flag);
+
+	pool[idx].u.fl = free_head;
+	free_head = idx;
+	free_count++;
+
+	spin_unlock_irqrestore(&pool_lock, flag);
+}
+
+static inline void set_page_ext(struct page *pg, unsigned int idx)
+{
+	union page_ext ext = { .idx = idx };
+
+	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
+	pg->mapping = ext.mapping;
+}
+
+static int get_page_ext(struct page *pg, unsigned int *pidx)
+{
+	union page_ext ext = { .mapping = pg->mapping };
+	int idx;
+
+	idx = ext.idx;
+
+	if ((idx < 0) || (idx >= pool_size))
+		return 0;
+
+	if (pool[idx].page != pg)
+		return 0;
+
+	*pidx = idx;
+
+	return 1;
+}
+
+int is_in_pool(struct page *page, int *pidx)
+{
+	return get_page_ext(page, pidx);
+}
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+{
+	int idx;
+	struct page *page;
+
+	idx = get_free_entry();
+	if (idx < 0)
+		return NULL;
+	page = alloc_page(GFP_ATOMIC);
+
+	if (page == NULL) {
+		put_free_entry(idx);
+		return NULL;
+	}
+
+	set_page_ext(page, idx);
+	pool[idx].u.netbk = netbk;
+	pool[idx].page = page;
+
+	*pidx = idx;
+
+	return page;
+}
+
+void page_pool_put(int idx)
+{
+	struct page *page = pool[idx].page;
+
+	pool[idx].page = NULL;
+	pool[idx].u.netbk = NULL;
+	page->mapping = 0;
+	put_page(page);
+	put_free_entry(idx);
+}
+
+int page_pool_init()
+{
+	int cpus = 0;
+	int i;
+
+	cpus = num_online_cpus();
+	pool_size = cpus * ENTRIES_PER_CPU;
+
+	pool = vzalloc(sizeof(struct page_pool_entry) * pool_size);
+
+	if (!pool)
+		return -ENOMEM;
+
+	for (i = 0; i < pool_size - 1; i++)
+		pool[i].u.fl = i+1;
+	pool[pool_size-1].u.fl = INVALID_ENTRY;
+	free_count = pool_size;
+	free_head = 0;
+
+	return 0;
+}
+
+void page_pool_destroy()
+{
+	int i;
+	for (i = 0; i < pool_size; i++)
+		if (pool[i].page)
+			put_page(pool[i].page);
+
+	vfree(pool);
+}
+
+struct page *to_page(int idx)
+{
+	return pool[idx].page;
+}
+
+struct xen_netbk *to_netbk(int idx)
+{
+	return pool[idx].u.netbk;
+}
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
new file mode 100644
index 0000000..52a6fc7
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.h
@@ -0,0 +1,61 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __PAGE_POOL_H__
+#define __PAGE_POOL_H__
+
+#include "common.h"
+
+typedef uint32_t idx_t;
+
+#define ENTRIES_PER_CPU (1024)
+#define INVALID_ENTRY 0xffffffff
+
+struct page_pool_entry {
+	struct page *page;
+	union {
+		struct xen_netbk *netbk;
+		idx_t             fl;
+	} u;
+};
+
+union page_ext {
+	idx_t idx;
+	void *mapping;
+};
+
+int  page_pool_init(void);
+void page_pool_destroy(void);
+
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+void         page_pool_put(int idx);
+int          is_in_pool(struct page *page, int *pidx);
+
+struct page      *to_page(int idx);
+struct xen_netbk *to_netbk(int idx);
+
+#endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 16:59:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 16:59:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlkTd-0005dN-0K; Fri, 13 Jan 2012 16:59:41 +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 1RlkTb-0005cy-W3
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 16:59:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326473972!8177955!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20056 invoked from network); 13 Jan 2012 16:59:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 16:59:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20853675"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 11:59: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, 13 Jan 2012 11:59:31 -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 q0DGxQEC016212;
	Fri, 13 Jan 2012 08:59:29 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, konrad.wilk@oracle.com,
	xen-devel@lists.xensource.com, netdev@vger.kernel.org
Date: Fri, 13 Jan 2012 16:59:04 +0000
Message-ID: <1326473949-22389-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [RFC PATCH 1/6] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A global page pool. Since we are moving to 1:1 model netback, it is
better to limit total RAM consumed by all the vifs.

With this patch, each vif gets page from the pool and puts the page
back when it is finished with the page.

This pool is only meant to access via exported interfaces. Internals
are subject to change when we discover new requirements for the pool.

Current exported interfaces include:

page_pool_init: pool init
page_pool_destroy: pool destruction
page_pool_get: get a page from pool
page_pool_put: put page back to pool
is_in_pool: tell whether a page belongs to the pool

Current implementation has following defects:
 - Global locking
 - No starve prevention mechanism / reservation logic

Global locking tends to cause contention on the pool. No reservation
logic may cause vif to starve. A possible solution to these two
problems will be each vif maintains its local cache and claims a
portion of the pool. However the implementation will be tricky when
coming to pool management, so let's worry about that later.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/netback.c   |   93 ++++--------------
 drivers/net/xen-netback/page_pool.c |  183 +++++++++++++++++++++++++++++++++++
 drivers/net/xen-netback/page_pool.h |   61 ++++++++++++
 4 files changed, 266 insertions(+), 73 deletions(-)
 create mode 100644 drivers/net/xen-netback/page_pool.c
 create mode 100644 drivers/net/xen-netback/page_pool.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..dc4b8b1 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 59effac..26af7b7 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -33,6 +33,7 @@
  */
 
 #include "common.h"
+#include "page_pool.h"
 
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
@@ -65,21 +66,6 @@ struct netbk_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-/* extra field used in struct page */
-union page_ext {
-	struct {
-#if BITS_PER_LONG < 64
-#define IDX_WIDTH   8
-#define GROUP_WIDTH (BITS_PER_LONG - IDX_WIDTH)
-		unsigned int group:GROUP_WIDTH;
-		unsigned int idx:IDX_WIDTH;
-#else
-		unsigned int group, idx;
-#endif
-	} e;
-	void *mapping;
-};
-
 struct xen_netbk {
 	wait_queue_head_t wq;
 	struct task_struct *task;
@@ -89,7 +75,7 @@ struct xen_netbk {
 
 	struct timer_list net_timer;
 
-	struct page *mmap_pages[MAX_PENDING_REQS];
+	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
@@ -160,7 +146,7 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
 				       u16 idx)
 {
-	return page_to_pfn(netbk->mmap_pages[idx]);
+	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
 }
 
 static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
@@ -169,45 +155,6 @@ static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
 	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
 }
 
-/* extra field used in struct page */
-static inline void set_page_ext(struct page *pg, struct xen_netbk *netbk,
-				unsigned int idx)
-{
-	unsigned int group = netbk - xen_netbk;
-	union page_ext ext = { .e = { .group = group + 1, .idx = idx } };
-
-	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
-	pg->mapping = ext.mapping;
-}
-
-static int get_page_ext(struct page *pg,
-			unsigned int *pgroup, unsigned int *pidx)
-{
-	union page_ext ext = { .mapping = pg->mapping };
-	struct xen_netbk *netbk;
-	unsigned int group, idx;
-
-	group = ext.e.group - 1;
-
-	if (group < 0 || group >= xen_netbk_group_nr)
-		return 0;
-
-	netbk = &xen_netbk[group];
-
-	idx = ext.e.idx;
-
-	if ((idx < 0) || (idx >= MAX_PENDING_REQS))
-		return 0;
-
-	if (netbk->mmap_pages[idx] != pg)
-		return 0;
-
-	*pgroup = group;
-	*pidx = idx;
-
-	return 1;
-}
-
 /*
  * This is the amount of packet we copy rather than map, so that the
  * guest can't fiddle with the contents of the headers while we do
@@ -398,8 +345,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
-	unsigned int uninitialized_var(group), uninitialized_var(idx);
-	int foreign = get_page_ext(page, &group, &idx);
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
@@ -427,7 +374,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = &xen_netbk[group];
+			struct xen_netbk *netbk = to_netbk(idx);
 			struct pending_tx_info *src_pend;
 
 			src_pend = &netbk->pending_tx_info[idx];
@@ -906,11 +853,11 @@ static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
 					 u16 pending_idx)
 {
 	struct page *page;
-	page = alloc_page(GFP_KERNEL|__GFP_COLD);
+	int idx;
+	page = page_pool_get(netbk, &idx);
 	if (!page)
 		return NULL;
-	set_page_ext(page, netbk, pending_idx);
-	netbk->mmap_pages[pending_idx] = page;
+	netbk->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
@@ -1053,7 +1000,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(netbk->mmap_pages[pending_idx]);
+		get_page(to_page(netbk->mmap_pages[pending_idx]));
 		xen_netbk_idx_release(netbk, pending_idx);
 	}
 }
@@ -1482,7 +1429,7 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	pending_ring_idx_t index;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == NULL)
+	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
 	pending_tx_info = &netbk->pending_tx_info[pending_idx];
@@ -1496,9 +1443,9 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	xenvif_put(vif);
 
-	netbk->mmap_pages[pending_idx]->mapping = 0;
-	put_page(netbk->mmap_pages[pending_idx]);
-	netbk->mmap_pages[pending_idx] = NULL;
+	page_pool_put(netbk->mmap_pages[pending_idx]);
+
+	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1681,19 +1628,21 @@ static int __init netback_init(void)
 		wake_up_process(netbk->task);
 	}
 
-	rc = xenvif_xenbus_init();
+	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto pool_failed_init;
+
 	return 0;
 
+pool_failed_init:
+	page_pool_destroy();
 failed_init:
 	while (--group >= 0) {
 		struct xen_netbk *netbk = &xen_netbk[group];
-		for (i = 0; i < MAX_PENDING_REQS; i++) {
-			if (netbk->mmap_pages[i])
-				__free_page(netbk->mmap_pages[i]);
-		}
 		del_timer(&netbk->net_timer);
 		kthread_stop(netbk->task);
 	}
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
new file mode 100644
index 0000000..8904869
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.c
@@ -0,0 +1,183 @@
+/*
+ * Global page pool for netback.
+ *
+ * Wei Liu <wei.liu2@citrix.com>
+ * Copyright (c) Citrix Systems
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "common.h"
+#include "page_pool.h"
+#include <asm/xen/page.h>
+
+static idx_t free_head;
+static int free_count;
+static unsigned long pool_size;
+static DEFINE_SPINLOCK(pool_lock);
+static struct page_pool_entry *pool;
+
+static int get_free_entry(void)
+{
+	unsigned long flag;
+	int idx;
+
+	spin_lock_irqsave(&pool_lock, flag);
+
+	if (free_count == 0) {
+		spin_unlock_irqrestore(&pool_lock, flag);
+		return -ENOSPC;
+	}
+
+	idx = free_head;
+	free_count--;
+	free_head = pool[idx].u.fl;
+	pool[idx].u.fl = INVALID_ENTRY;
+
+	spin_unlock_irqrestore(&pool_lock, flag);
+
+	return idx;
+}
+
+static void put_free_entry(idx_t idx)
+{
+	unsigned long flag;
+
+	spin_lock_irqsave(&pool_lock, flag);
+
+	pool[idx].u.fl = free_head;
+	free_head = idx;
+	free_count++;
+
+	spin_unlock_irqrestore(&pool_lock, flag);
+}
+
+static inline void set_page_ext(struct page *pg, unsigned int idx)
+{
+	union page_ext ext = { .idx = idx };
+
+	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
+	pg->mapping = ext.mapping;
+}
+
+static int get_page_ext(struct page *pg, unsigned int *pidx)
+{
+	union page_ext ext = { .mapping = pg->mapping };
+	int idx;
+
+	idx = ext.idx;
+
+	if ((idx < 0) || (idx >= pool_size))
+		return 0;
+
+	if (pool[idx].page != pg)
+		return 0;
+
+	*pidx = idx;
+
+	return 1;
+}
+
+int is_in_pool(struct page *page, int *pidx)
+{
+	return get_page_ext(page, pidx);
+}
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+{
+	int idx;
+	struct page *page;
+
+	idx = get_free_entry();
+	if (idx < 0)
+		return NULL;
+	page = alloc_page(GFP_ATOMIC);
+
+	if (page == NULL) {
+		put_free_entry(idx);
+		return NULL;
+	}
+
+	set_page_ext(page, idx);
+	pool[idx].u.netbk = netbk;
+	pool[idx].page = page;
+
+	*pidx = idx;
+
+	return page;
+}
+
+void page_pool_put(int idx)
+{
+	struct page *page = pool[idx].page;
+
+	pool[idx].page = NULL;
+	pool[idx].u.netbk = NULL;
+	page->mapping = 0;
+	put_page(page);
+	put_free_entry(idx);
+}
+
+int page_pool_init()
+{
+	int cpus = 0;
+	int i;
+
+	cpus = num_online_cpus();
+	pool_size = cpus * ENTRIES_PER_CPU;
+
+	pool = vzalloc(sizeof(struct page_pool_entry) * pool_size);
+
+	if (!pool)
+		return -ENOMEM;
+
+	for (i = 0; i < pool_size - 1; i++)
+		pool[i].u.fl = i+1;
+	pool[pool_size-1].u.fl = INVALID_ENTRY;
+	free_count = pool_size;
+	free_head = 0;
+
+	return 0;
+}
+
+void page_pool_destroy()
+{
+	int i;
+	for (i = 0; i < pool_size; i++)
+		if (pool[i].page)
+			put_page(pool[i].page);
+
+	vfree(pool);
+}
+
+struct page *to_page(int idx)
+{
+	return pool[idx].page;
+}
+
+struct xen_netbk *to_netbk(int idx)
+{
+	return pool[idx].u.netbk;
+}
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
new file mode 100644
index 0000000..52a6fc7
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.h
@@ -0,0 +1,61 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __PAGE_POOL_H__
+#define __PAGE_POOL_H__
+
+#include "common.h"
+
+typedef uint32_t idx_t;
+
+#define ENTRIES_PER_CPU (1024)
+#define INVALID_ENTRY 0xffffffff
+
+struct page_pool_entry {
+	struct page *page;
+	union {
+		struct xen_netbk *netbk;
+		idx_t             fl;
+	} u;
+};
+
+union page_ext {
+	idx_t idx;
+	void *mapping;
+};
+
+int  page_pool_init(void);
+void page_pool_destroy(void);
+
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+void         page_pool_put(int idx);
+int          is_in_pool(struct page *page, int *pidx);
+
+struct page      *to_page(int idx);
+struct xen_netbk *to_netbk(int idx);
+
+#endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:19:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17: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 1Rlkmd-0007Ma-1D; Fri, 13 Jan 2012 17:19:19 +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 1Rlkma-0007MP-W6
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:19:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326475149!10821454!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19088 invoked from network); 13 Jan 2012 17:19:10 -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;
	13 Jan 2012 17:19:10 -0000
Received: by iahk25 with SMTP id k25so2486527iah.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 09:19: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
	:content-transfer-encoding;
	bh=QwqFaRqwWV1Xi9WgpjkkuGj961NZ+qTPOotR0ZvldEA=;
	b=p1FTvFpw1Wpy19g1oGZDGDFrYTbMLDd7aFiSoGQdlv/1CANJtU3M36GKU52H4b0PD0
	90NEx6ZG52RVWE7/Q67X/TiUAuZKwwzbRiLb8N9mL5ri1vh0XyKZUN/Fryvjo1bSJkfk
	98FsGhS31Zkl0Q7yX/C/Cjjj2FDkYsC3m4rZ8=
MIME-Version: 1.0
Received: by 10.50.222.193 with SMTP id qo1mr1557621igc.22.1326475149262; Fri,
	13 Jan 2012 09:19:09 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Fri, 13 Jan 2012 09:19:08 -0800 (PST)
In-Reply-To: <CAPWDu3r0FcEd+jGEL3HD+obePgSc9sF6Qa4q1azj4SpsRHq4Uw@mail.gmail.com>
References: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
	<CAFLBxZbtqJ9sFPnDTVxioZodWEydiZVjOV_iXDsBksm9WdxWgQ@mail.gmail.com>
	<CAPWDu3r0FcEd+jGEL3HD+obePgSc9sF6Qa4q1azj4SpsRHq4Uw@mail.gmail.com>
Date: Fri, 13 Jan 2012 17:19:08 +0000
X-Google-Sender-Auth: nQ1ApCFVhfPgAF8XEI9aI231UI8
Message-ID: <CAFLBxZZrh5AKKL9uXqDg9KHsW=0+RF-rt7XYpD7ja2fOFtM7gw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Yufang Zhang <yufang521247@gmail.com>
Cc: xen-devel@lists.xensource.com, Keith Coleman <keith.coleman@n2servers.com>
Subject: Re: [Xen-devel] Cannot start up HVM guest when maxmem is not equal
 to memory and HAP is enabled.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 9:15 AM, Yufang Zhang <yufang521247@gmail.com> wrot=
e:
> Actually, you would be exposed to this problem whenever you restart xend =
and
> then reboot the hvm guest, even you set =A0maxmem =3D=3D memory in the co=
nfig file
> of that guest. When xend is restarted, it tries to recreate guest
> information.=A0memory_dynamic_max and=A0memory_static_max, which are used
> to=A0calculate memory and maxmem,=A0are re-calculated=A0from=A0mem_kb and=
=A0maxmem_kb
> respectively.=A0=A0mem_kb is not equal to=A0maxmem_kb.=A0Thus memory !=3D=
 maxmem after
> xend restarts, and rebooting this hvm guest later would leads guest
> crash/hang.

Ah, interesting.  Yeah, that is certainly a bug -- not sure whom to
contact about fixing that.  Keith?

> I check the xend code of xen-unstable, =A0the related logic didn't change
> since xen-3.4. So I *guess* a hvm guest without balloon driver would crash
> after some time(when it=A0dirties enough memory) after you restarting xen=
d and
> rebooting the guest on xen-4.1.

Should a user be changing the "memory" setting without having a
balloon driver active?  If the balloon driver *is* active, we'd want
that setting to be preserved across reboot.  Does xend know if there
is an active balloon driver?  If not, I think we just have to leave it
as it is.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:19:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17: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 1Rlkmd-0007Ma-1D; Fri, 13 Jan 2012 17:19:19 +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 1Rlkma-0007MP-W6
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:19:17 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326475149!10821454!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG,
	MAILTO_TO_SPAM_ADDR,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19088 invoked from network); 13 Jan 2012 17:19:10 -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;
	13 Jan 2012 17:19:10 -0000
Received: by iahk25 with SMTP id k25so2486527iah.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 09:19: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
	:content-transfer-encoding;
	bh=QwqFaRqwWV1Xi9WgpjkkuGj961NZ+qTPOotR0ZvldEA=;
	b=p1FTvFpw1Wpy19g1oGZDGDFrYTbMLDd7aFiSoGQdlv/1CANJtU3M36GKU52H4b0PD0
	90NEx6ZG52RVWE7/Q67X/TiUAuZKwwzbRiLb8N9mL5ri1vh0XyKZUN/Fryvjo1bSJkfk
	98FsGhS31Zkl0Q7yX/C/Cjjj2FDkYsC3m4rZ8=
MIME-Version: 1.0
Received: by 10.50.222.193 with SMTP id qo1mr1557621igc.22.1326475149262; Fri,
	13 Jan 2012 09:19:09 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Fri, 13 Jan 2012 09:19:08 -0800 (PST)
In-Reply-To: <CAPWDu3r0FcEd+jGEL3HD+obePgSc9sF6Qa4q1azj4SpsRHq4Uw@mail.gmail.com>
References: <CAPWDu3pmdSigi=c1zfv7mnKAMuKC9=D9f319JMpQAC=_yWPLTw@mail.gmail.com>
	<CAFLBxZbtqJ9sFPnDTVxioZodWEydiZVjOV_iXDsBksm9WdxWgQ@mail.gmail.com>
	<CAPWDu3r0FcEd+jGEL3HD+obePgSc9sF6Qa4q1azj4SpsRHq4Uw@mail.gmail.com>
Date: Fri, 13 Jan 2012 17:19:08 +0000
X-Google-Sender-Auth: nQ1ApCFVhfPgAF8XEI9aI231UI8
Message-ID: <CAFLBxZZrh5AKKL9uXqDg9KHsW=0+RF-rt7XYpD7ja2fOFtM7gw@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Yufang Zhang <yufang521247@gmail.com>
Cc: xen-devel@lists.xensource.com, Keith Coleman <keith.coleman@n2servers.com>
Subject: Re: [Xen-devel] Cannot start up HVM guest when maxmem is not equal
 to memory and HAP is enabled.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 12, 2012 at 9:15 AM, Yufang Zhang <yufang521247@gmail.com> wrot=
e:
> Actually, you would be exposed to this problem whenever you restart xend =
and
> then reboot the hvm guest, even you set =A0maxmem =3D=3D memory in the co=
nfig file
> of that guest. When xend is restarted, it tries to recreate guest
> information.=A0memory_dynamic_max and=A0memory_static_max, which are used
> to=A0calculate memory and maxmem,=A0are re-calculated=A0from=A0mem_kb and=
=A0maxmem_kb
> respectively.=A0=A0mem_kb is not equal to=A0maxmem_kb.=A0Thus memory !=3D=
 maxmem after
> xend restarts, and rebooting this hvm guest later would leads guest
> crash/hang.

Ah, interesting.  Yeah, that is certainly a bug -- not sure whom to
contact about fixing that.  Keith?

> I check the xend code of xen-unstable, =A0the related logic didn't change
> since xen-3.4. So I *guess* a hvm guest without balloon driver would crash
> after some time(when it=A0dirties enough memory) after you restarting xen=
d and
> rebooting the guest on xen-4.1.

Should a user be changing the "memory" setting without having a
balloon driver active?  If the balloon driver *is* active, we'd want
that setting to be preserved across reboot.  Does xend know if there
is an active balloon driver?  If not, I think we just have to leave it
as it is.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:40:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rll6Q-00080W-TE; Fri, 13 Jan 2012 17:39:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rll6P-00080P-Nj
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:39:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326476318!60897051!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg4NTMx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23290 invoked from network); 13 Jan 2012 17:38:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 17:38:39 -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
	q0DHdeUX018476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Jan 2012 17:39:41 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0DHddQr009749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2012 17:39:40 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
	q0DHddMZ001682; Fri, 13 Jan 2012 11:39:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Jan 2012 09:39:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D803540B49; Fri, 13 Jan 2012 12:37:46 -0500 (EST)
Date: Fri, 13 Jan 2012 12:37:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120113173746.GA16182@phenom.dumpdata.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-2-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326473949-22389-2-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F106C5D.0100,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH 1/6] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +static idx_t free_head;
> +static int free_count;
> +static unsigned long pool_size;
> +static DEFINE_SPINLOCK(pool_lock);
> +static struct page_pool_entry *pool;
> +
> +static int get_free_entry(void)
> +{
> +	unsigned long flag;
> +	int idx;
> +
> +	spin_lock_irqsave(&pool_lock, flag);

What is the benfit of using the irq version of the spinlock instead
of the normal one??


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:40:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:40:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rll6Q-00080W-TE; Fri, 13 Jan 2012 17:39:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rll6P-00080P-Nj
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:39:45 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326476318!60897051!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg4NTMx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23290 invoked from network); 13 Jan 2012 17:38:39 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 17:38:39 -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
	q0DHdeUX018476
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Jan 2012 17:39:41 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0DHddQr009749
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2012 17:39:40 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
	q0DHddMZ001682; Fri, 13 Jan 2012 11:39:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Jan 2012 09:39:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D803540B49; Fri, 13 Jan 2012 12:37:46 -0500 (EST)
Date: Fri, 13 Jan 2012 12:37:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120113173746.GA16182@phenom.dumpdata.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-2-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326473949-22389-2-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F106C5D.0100,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH 1/6] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +static idx_t free_head;
> +static int free_count;
> +static unsigned long pool_size;
> +static DEFINE_SPINLOCK(pool_lock);
> +static struct page_pool_entry *pool;
> +
> +static int get_free_entry(void)
> +{
> +	unsigned long flag;
> +	int idx;
> +
> +	spin_lock_irqsave(&pool_lock, flag);

What is the benfit of using the irq version of the spinlock instead
of the normal one??


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:42:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:42:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rll95-0008Bg-GF; Fri, 13 Jan 2012 17:42:31 +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 1Rll93-0008BO-QY
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:42:30 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326476499!50519939!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 12760 invoked from network); 13 Jan 2012 17:41:40 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-27.messagelabs.com with SMTP;
	13 Jan 2012 17:41:40 -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
	q0DHgN62028166; Fri, 13 Jan 2012 17:42:23 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 q0DHgNDK028533; 
	Fri, 13 Jan 2012 12:42:23 -0500
Message-ID: <4F106CFC.1030204@tycho.nsa.gov>
Date: Fri, 13 Jan 2012 12:42:20 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
	<4F105DD1020000780006C8A5@nat28.tlf.novell.com>
	<4F105144.8070004@tycho.nsa.gov>
	<4F10633D020000780006C8F4@nat28.tlf.novell.com>
In-Reply-To: <4F10633D020000780006C8F4@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/13/2012 11:00 AM, Jan Beulich wrote:
>>>> On 13.01.12 at 16:44, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 01/13/2012 10:37 AM, Jan Beulich wrote:
>>>>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>>> --- a/include/xen/xenbus_dev.h
>>>>>> +++ b/include/xen/xenbus_dev.h
>>>>>> @@ -38,4 +38,18 @@
>>>>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>>>>  
>>>>>> +#define IOCTL_XENBUS_ALLOC				\
>>>>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>>>>> +struct ioctl_xenbus_alloc {
>>>>>> +	/* IN */
>>>>>> +	/* The domain ID (must exist) for xenstore */
>>>>>> +	uint16_t dom;
>>>>>> +	uint16_t pad;
>>>>>> +	/* OUT */
>>>>>> +	/* The port allocated for xenbus communication */
>>>>>> +	uint32_t port;
>>>>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>>>>> +	uint32_t grant_ref;
>>>>>> +};
>>>>>
>>>>> As said in my reply to the previous patch version - if the functionality
>>>>> differs, the number *and* name should be different from the legacy
>>>>> implementation's. Otherwise, how should compatible user space code
>>>>> be written?
>>>>>
>>>>> Jan
>>>>>
>>>>
>>>> This implementation has the same functionality as the legacy ioctl,
>>>
>>> It doesn't - none of the "OUT" fields above exist there.
>>
>> Are you looking at the same legacy ioctl as I am? I found it in 2.6.18.hg
>> where the structure was defined as:
>>
>> typedef struct xenbus_alloc {
>>     domid_t dom;
>>     __u32 port;
>>     __u32 grant_ref;
>> } xenbus_alloc_t;
>>
>> The port and grant_ref fields were outputs. I added padding for clarity
>> since domid_t is uint16_t.
> 
> Ooops, I'm sorry, indeed - I didn't look at the names and types
> closely enough. They were too different, so I assumed the whole
> thing is different.
> 
> That doesn't eliminate the difference between the two
> IOCTL_XENBUS_ALLOC definitions, though
> [_IOC(_IOC_NONE, 'X', 0, sizeof(xenbus_alloc_t)) vs
> _IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))] - one
> still can't use both in the same source file.

Is compatibility with 2.6.18-xen more important than keeping the ioctl
numbers in a single file consistent? The definition in 2.6.18 is also
incorrect (as was my definition) - since the argument is used, it needs
to use _IOWR() or _IOC_READ|_IOC_WRITE instead of _IOC_NONE.

Since this ioctl must already be performed a different file than the
legacy ioctl, a new name seems to be the best solution.

> Additionally (forgive if I'm not up to date in this respect) - is it okay
> these days to use uintX_t in exported Linux headers, and then
> without including the header that would define the necessary
> types?
> 
> Jan

It's done in a number of other header files (I was copying from gntdev.h)
but that doesn't mean it's officially okay. Using __u32 is probably safer.

> 
>>>> although it has a different number and is performed on a different file,
>>>> so it is already impossible to make automatically compatible userspace
>>>> code.
>>>
>>> That's not what I was aiming at. The problem you're introducing is
>>> that you name the ioctl IOCTL_XENBUS_ALLOC, identical to what
>>> the legacy code named it. Hence one won't be able to write user
>>> mode code to invoke, depending on runtime determination, either
>>> the old or the new function.
>>>
>>> Jan
>>>
>>>> The structure name was changed to match other ioctl arguments, but
>>>> the contents should be the same as in the legacy ioctl. If changing what
>>>> file the ioctl is performed on justifies changing the ioctl name, then I
>>>> would prefer the simpler interface where the domain ID is passed in as the
>>>> ioctl parameter instead of a structure that only has one useful output.
>>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:42:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:42:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rll95-0008Bg-GF; Fri, 13 Jan 2012 17:42:31 +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 1Rll93-0008BO-QY
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:42:30 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326476499!50519939!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 12760 invoked from network); 13 Jan 2012 17:41:40 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-27.messagelabs.com with SMTP;
	13 Jan 2012 17:41:40 -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
	q0DHgN62028166; Fri, 13 Jan 2012 17:42:23 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 q0DHgNDK028533; 
	Fri, 13 Jan 2012 12:42:23 -0500
Message-ID: <4F106CFC.1030204@tycho.nsa.gov>
Date: Fri, 13 Jan 2012 12:42:20 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
	<4F105DD1020000780006C8A5@nat28.tlf.novell.com>
	<4F105144.8070004@tycho.nsa.gov>
	<4F10633D020000780006C8F4@nat28.tlf.novell.com>
In-Reply-To: <4F10633D020000780006C8F4@nat28.tlf.novell.com>
X-Enigmail-Version: 1.3.4
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/13/2012 11:00 AM, Jan Beulich wrote:
>>>> On 13.01.12 at 16:44, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>> On 01/13/2012 10:37 AM, Jan Beulich wrote:
>>>>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>>> --- a/include/xen/xenbus_dev.h
>>>>>> +++ b/include/xen/xenbus_dev.h
>>>>>> @@ -38,4 +38,18 @@
>>>>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>>>>  
>>>>>> +#define IOCTL_XENBUS_ALLOC				\
>>>>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>>>>> +struct ioctl_xenbus_alloc {
>>>>>> +	/* IN */
>>>>>> +	/* The domain ID (must exist) for xenstore */
>>>>>> +	uint16_t dom;
>>>>>> +	uint16_t pad;
>>>>>> +	/* OUT */
>>>>>> +	/* The port allocated for xenbus communication */
>>>>>> +	uint32_t port;
>>>>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>>>>> +	uint32_t grant_ref;
>>>>>> +};
>>>>>
>>>>> As said in my reply to the previous patch version - if the functionality
>>>>> differs, the number *and* name should be different from the legacy
>>>>> implementation's. Otherwise, how should compatible user space code
>>>>> be written?
>>>>>
>>>>> Jan
>>>>>
>>>>
>>>> This implementation has the same functionality as the legacy ioctl,
>>>
>>> It doesn't - none of the "OUT" fields above exist there.
>>
>> Are you looking at the same legacy ioctl as I am? I found it in 2.6.18.hg
>> where the structure was defined as:
>>
>> typedef struct xenbus_alloc {
>>     domid_t dom;
>>     __u32 port;
>>     __u32 grant_ref;
>> } xenbus_alloc_t;
>>
>> The port and grant_ref fields were outputs. I added padding for clarity
>> since domid_t is uint16_t.
> 
> Ooops, I'm sorry, indeed - I didn't look at the names and types
> closely enough. They were too different, so I assumed the whole
> thing is different.
> 
> That doesn't eliminate the difference between the two
> IOCTL_XENBUS_ALLOC definitions, though
> [_IOC(_IOC_NONE, 'X', 0, sizeof(xenbus_alloc_t)) vs
> _IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))] - one
> still can't use both in the same source file.

Is compatibility with 2.6.18-xen more important than keeping the ioctl
numbers in a single file consistent? The definition in 2.6.18 is also
incorrect (as was my definition) - since the argument is used, it needs
to use _IOWR() or _IOC_READ|_IOC_WRITE instead of _IOC_NONE.

Since this ioctl must already be performed a different file than the
legacy ioctl, a new name seems to be the best solution.

> Additionally (forgive if I'm not up to date in this respect) - is it okay
> these days to use uintX_t in exported Linux headers, and then
> without including the header that would define the necessary
> types?
> 
> Jan

It's done in a number of other header files (I was copying from gntdev.h)
but that doesn't mean it's officially okay. Using __u32 is probably safer.

> 
>>>> although it has a different number and is performed on a different file,
>>>> so it is already impossible to make automatically compatible userspace
>>>> code.
>>>
>>> That's not what I was aiming at. The problem you're introducing is
>>> that you name the ioctl IOCTL_XENBUS_ALLOC, identical to what
>>> the legacy code named it. Hence one won't be able to write user
>>> mode code to invoke, depending on runtime determination, either
>>> the old or the new function.
>>>
>>> Jan
>>>
>>>> The structure name was changed to match other ioctl arguments, but
>>>> the contents should be the same as in the legacy ioctl. If changing what
>>>> file the ioctl is performed on justifies changing the ioctl name, then I
>>>> would prefer the simpler interface where the domain ID is passed in as the
>>>> ioctl parameter instead of a structure that only has one useful output.
>>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rll9p-0008G0-U9; Fri, 13 Jan 2012 17:43:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rll9o-0008Fp-KC
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:43:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326476553!60130537!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5MzYwNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9341 invoked from network); 13 Jan 2012 17:42:34 -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; 13 Jan 2012 17:42:34 -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
	q0DHhAH5009844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Jan 2012 17:43:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0DHh81H008654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2012 17:43:09 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
	q0DHh7rT019782; Fri, 13 Jan 2012 11:43:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Jan 2012 09:43:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9749040B41; Fri, 13 Jan 2012 10:13:07 -0500 (EST)
Date: Fri, 13 Jan 2012 10:13:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120113151307.GC5025@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1442969761.20120112230601@eikelenboom.it>
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.4F106D2F.003F,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.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

> >> > 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.
> 
> > Good news is I am able to reproduce this with my 32-bit NIC with 3.2 domU:
> 
> > [  771.896140] SWIOTLB is 11% full
> > [  776.896116] 0 [e1000 0000:00:00.0] bounce: from:222028(slow:0)to:2 map:222037 unmap:227220 sync:0
> > [  776.896126] 1 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:5188 map:5188 unmap:0 sync:0
> > [  776.896133] 3 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:1 map:1 unmap:0 sync:0
> 
> > but interestingly enough, if I boot the guest as the first one I do not get these bounce
> > requests. I will shortly bootup a Xen-O-Linux kernel and see if I get these same
> > numbers.
> 
> 
> I started to expiriment some more with what i encountered.
> 
> On dom0 i was seeing that my r8169 ethernet controllers where using bounce buffering with the dump-swiotlb module.
> It was showing "12% full".
> Checking in sysfs shows:
> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
> 32
> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
> 32
> 
> If i remember correctly wasn't the allocation for dom0 changed to be to the top of memory instead of low .. somewhere between 2.6.32 and 3.0 ?

? We never actually had dom0 support in the upstream kernel until 2.6.37.. The 2.6.32<->2.6.36 you are
referring to must have been the trees that I spun up - but the implementation of SWIOTLB in them
had not really changed.

> Could that change cause the need for all devices to need bounce buffering  and could it therefore explain some people seeing more cpu usage for dom0 ?

The issue I am seeing is not CPU usage in dom0, but rather the CPU usage in domU with guests.
And that the older domU's (XenOLinux) do not have this.

That I can't understand - the implementation in both cases _looks_ to do the same thing.
There was one issue I found in the upstream one, but even with that fix I still
get that "bounce" usage in domU.

Interestingly enough, I get that only if I have launched, destroyed, launched, etc, the guest multiple
times before I get this. Which leads me to believe this is not a kernel issue but that we
are simply fragmented the Xen memory so much, so that when it launches the guest all of the
memory is above 4GB. But that seems counter-intuive as by default Xen starts guests at the far end of
memory (so on my 16GB box it would stick a 4GB guest at 12GB->16GB roughly). The SWIOTLB
swizzles some memory under the 4GB , and this is where we get the bounce buffer effect
(as the memory from 4GB is then copied to the memory 12GB->16GB).

But it does not explain why on the first couple of starts I did not see this with pvops.
And it does not seem to happen with the XenOLinux kernel, so there must be something else
in here.

> 
> I have forced my r8169 to use 64bits dma mask (using use_dac=1)

Ah yes.
> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
> 32
> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
> 64
> 
> This results in dump-swiotlb reporting:
> 
> [ 1265.616106] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
> [ 1265.625043] SWIOTLB is 0% full
> [ 1270.626085] 0 [r8169 0000:08:00.0] bounce: from:6(slow:0)to:0 map:0 unmap:0 sync:12
> [ 1270.635024] SWIOTLB is 0% full
> [ 1275.635091] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
> [ 1275.644261] SWIOTLB is 0% full
> [ 1280.654097] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10

Which is what we expect. No need to bounce since the PCI adapter can reach memory
above the 4GB mark.

> 
> 
> 
> So it has changed from 12% to 0%, although it still reports something about bouncing ? or am i mis interpreting stuff ?

The bouncing can happen due to two cases:
 - Memory is above 4GB
 - Memory crosses a page-boundary (rarely happens).
> 
> 
> Another thing i was wondering about, couldn't the hypervisor offer a small window in 32bit addressable mem to all (or only when pci passthrough is used) domU's to be used for DMA ?

It does. That is what the Xen SWIOTLB does with "swizzling" the pages in its pool.
But it can't do it for every part of memory. That is why there are DMA pools
which are used by graphics adapters, video capture devices,storage and network
drivers. They are used for small packet sizes so that the driver does not have
to allocate DMA buffers when it gets a 100bytes ping response. But for large
packets (say that ISO file you are downloading) it allocates memory on the fly
and "maps" it into the PCI space using the DMA API. That "mapping" sets up
an "physical memory" -> "guest memory" translation - and if that allocated
memory is above 4GB, part of this mapping is to copy ("bounce") the memory
under the 4GB (where XenSWIOTLB has allocated a pool), so that the adapter
can physically fetch/put the data. Once that is completed it is "sync"-ed
back, which is bouncing that data to the "allocated memory".

So having a DMA pool is very good - and most drivers use it. The thing I can't
figure out is:
 - why the DVB do not seem to use it, even thought they look to use the videobuf_dma
   driver.
 - why the XenOLinux does not seem to have this problem (and this might be false - 
   perhaps it does have this problem and it just takes a couple of guest launches,
   destructions, starts, etc to actually see it).
 - are there any flags in the domain builder to say: "ok, this domain is going to
   service 32-bit cards, hence build the memory from 0->4GB". This seems like
   a good know at first, but it probably is a bad idea (imagine using it by mistake
   on every guest). And also nowadays most cards are PCIe and they can do 64-bit, so
   it would not be that important in the future.
> 
> (oh yes, i haven't got i clue what i'm talking about ... so it probably make no sense at all :-) )

Nonsense. You were on the correct path . Hopefully the level of details hasn't
scared you off now :-)

> 
> 
> --
> Sander
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rll9p-0008G0-U9; Fri, 13 Jan 2012 17:43:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rll9o-0008Fp-KC
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:43:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326476553!60130537!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5MzYwNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9341 invoked from network); 13 Jan 2012 17:42:34 -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; 13 Jan 2012 17:42:34 -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
	q0DHhAH5009844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Jan 2012 17:43:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0DHh81H008654
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2012 17:43:09 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
	q0DHh7rT019782; Fri, 13 Jan 2012 11:43:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Jan 2012 09:43:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9749040B41; Fri, 13 Jan 2012 10:13:07 -0500 (EST)
Date: Fri, 13 Jan 2012 10:13:07 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120113151307.GC5025@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1442969761.20120112230601@eikelenboom.it>
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.4F106D2F.003F,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.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

> >> > 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.
> 
> > Good news is I am able to reproduce this with my 32-bit NIC with 3.2 domU:
> 
> > [  771.896140] SWIOTLB is 11% full
> > [  776.896116] 0 [e1000 0000:00:00.0] bounce: from:222028(slow:0)to:2 map:222037 unmap:227220 sync:0
> > [  776.896126] 1 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:5188 map:5188 unmap:0 sync:0
> > [  776.896133] 3 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:1 map:1 unmap:0 sync:0
> 
> > but interestingly enough, if I boot the guest as the first one I do not get these bounce
> > requests. I will shortly bootup a Xen-O-Linux kernel and see if I get these same
> > numbers.
> 
> 
> I started to expiriment some more with what i encountered.
> 
> On dom0 i was seeing that my r8169 ethernet controllers where using bounce buffering with the dump-swiotlb module.
> It was showing "12% full".
> Checking in sysfs shows:
> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
> 32
> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
> 32
> 
> If i remember correctly wasn't the allocation for dom0 changed to be to the top of memory instead of low .. somewhere between 2.6.32 and 3.0 ?

? We never actually had dom0 support in the upstream kernel until 2.6.37.. The 2.6.32<->2.6.36 you are
referring to must have been the trees that I spun up - but the implementation of SWIOTLB in them
had not really changed.

> Could that change cause the need for all devices to need bounce buffering  and could it therefore explain some people seeing more cpu usage for dom0 ?

The issue I am seeing is not CPU usage in dom0, but rather the CPU usage in domU with guests.
And that the older domU's (XenOLinux) do not have this.

That I can't understand - the implementation in both cases _looks_ to do the same thing.
There was one issue I found in the upstream one, but even with that fix I still
get that "bounce" usage in domU.

Interestingly enough, I get that only if I have launched, destroyed, launched, etc, the guest multiple
times before I get this. Which leads me to believe this is not a kernel issue but that we
are simply fragmented the Xen memory so much, so that when it launches the guest all of the
memory is above 4GB. But that seems counter-intuive as by default Xen starts guests at the far end of
memory (so on my 16GB box it would stick a 4GB guest at 12GB->16GB roughly). The SWIOTLB
swizzles some memory under the 4GB , and this is where we get the bounce buffer effect
(as the memory from 4GB is then copied to the memory 12GB->16GB).

But it does not explain why on the first couple of starts I did not see this with pvops.
And it does not seem to happen with the XenOLinux kernel, so there must be something else
in here.

> 
> I have forced my r8169 to use 64bits dma mask (using use_dac=1)

Ah yes.
> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
> 32
> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
> 64
> 
> This results in dump-swiotlb reporting:
> 
> [ 1265.616106] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
> [ 1265.625043] SWIOTLB is 0% full
> [ 1270.626085] 0 [r8169 0000:08:00.0] bounce: from:6(slow:0)to:0 map:0 unmap:0 sync:12
> [ 1270.635024] SWIOTLB is 0% full
> [ 1275.635091] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
> [ 1275.644261] SWIOTLB is 0% full
> [ 1280.654097] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10

Which is what we expect. No need to bounce since the PCI adapter can reach memory
above the 4GB mark.

> 
> 
> 
> So it has changed from 12% to 0%, although it still reports something about bouncing ? or am i mis interpreting stuff ?

The bouncing can happen due to two cases:
 - Memory is above 4GB
 - Memory crosses a page-boundary (rarely happens).
> 
> 
> Another thing i was wondering about, couldn't the hypervisor offer a small window in 32bit addressable mem to all (or only when pci passthrough is used) domU's to be used for DMA ?

It does. That is what the Xen SWIOTLB does with "swizzling" the pages in its pool.
But it can't do it for every part of memory. That is why there are DMA pools
which are used by graphics adapters, video capture devices,storage and network
drivers. They are used for small packet sizes so that the driver does not have
to allocate DMA buffers when it gets a 100bytes ping response. But for large
packets (say that ISO file you are downloading) it allocates memory on the fly
and "maps" it into the PCI space using the DMA API. That "mapping" sets up
an "physical memory" -> "guest memory" translation - and if that allocated
memory is above 4GB, part of this mapping is to copy ("bounce") the memory
under the 4GB (where XenSWIOTLB has allocated a pool), so that the adapter
can physically fetch/put the data. Once that is completed it is "sync"-ed
back, which is bouncing that data to the "allocated memory".

So having a DMA pool is very good - and most drivers use it. The thing I can't
figure out is:
 - why the DVB do not seem to use it, even thought they look to use the videobuf_dma
   driver.
 - why the XenOLinux does not seem to have this problem (and this might be false - 
   perhaps it does have this problem and it just takes a couple of guest launches,
   destructions, starts, etc to actually see it).
 - are there any flags in the domain builder to say: "ok, this domain is going to
   service 32-bit cards, hence build the memory from 0->4GB". This seems like
   a good know at first, but it probably is a bad idea (imagine using it by mistake
   on every guest). And also nowadays most cards are PCIe and they can do 64-bit, so
   it would not be that important in the future.
> 
> (oh yes, i haven't got i clue what i'm talking about ... so it probably make no sense at all :-) )

Nonsense. You were on the correct path . Hopefully the level of details hasn't
scared you off now :-)

> 
> 
> --
> Sander
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:43:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:43:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RllAJ-0008K8-C4; Fri, 13 Jan 2012 17:43: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 1RllAH-0008Jm-Vl
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:43:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326476598!55613386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30180 invoked from network); 13 Jan 2012 17:43:18 -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;
	13 Jan 2012 17:43:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10011293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 17:43: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, 13 Jan 2012 17:43: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
	1RllAG-0005FV-J9; Fri, 13 Jan 2012 17:43:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RllAG-0001dA-9j;
	Fri, 13 Jan 2012 17:43:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.27984.55782.108638@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 17:43:44 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
In-Reply-To: <20240.18370.479047.159541@mariner.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326466209.17210.364.camel@zakaz.uk.xensource.com>
	<20240.18370.479047.159541@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v6 00/10] libxl: 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 ("Re: [Xen-devel] [PATCH v6 00/10] libxl: event API"):
> > > These should perhaps go in soon:
> > >  01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
> > >  03/10 libxl: move a lot more includes into libxl_internal.h
> > >  04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
> > >  05/10 libxl: Fix leaks on context init failure
> > >  09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
> > > 
> > > This one has now been tested and can go in IMO:
> > >  02/10 xenstore: New function xs_path_is_subpath
> > 
> > I agree that all the above can go in. I think I've acked them all.

I have applied 01-05 to xen-unstable.  09 has not yet been executed
(by me at least) so I think it should wait.

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 Jan 13 17:43:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:43:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RllAJ-0008K8-C4; Fri, 13 Jan 2012 17:43: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 1RllAH-0008Jm-Vl
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:43:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326476598!55613386!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30180 invoked from network); 13 Jan 2012 17:43:18 -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;
	13 Jan 2012 17:43:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10011293"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 17:43: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, 13 Jan 2012 17:43: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
	1RllAG-0005FV-J9; Fri, 13 Jan 2012 17:43:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RllAG-0001dA-9j;
	Fri, 13 Jan 2012 17:43:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20240.27984.55782.108638@mariner.uk.xensource.com>
Date: Fri, 13 Jan 2012 17:43:44 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
In-Reply-To: <20240.18370.479047.159541@mariner.uk.xensource.com>
References: <1325882107-5794-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326466209.17210.364.camel@zakaz.uk.xensource.com>
	<20240.18370.479047.159541@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH v6 00/10] libxl: 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 ("Re: [Xen-devel] [PATCH v6 00/10] libxl: event API"):
> > > These should perhaps go in soon:
> > >  01/10 libxl: make LIBXL_INIT_GC a statement, not an initialiser
> > >  03/10 libxl: move a lot more includes into libxl_internal.h
> > >  04/10 libxl: Provide more formal libxl__ctx_lock and _unlock
> > >  05/10 libxl: Fix leaks on context init failure
> > >  09/10 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
> > > 
> > > This one has now been tested and can go in IMO:
> > >  02/10 xenstore: New function xs_path_is_subpath
> > 
> > I agree that all the above can go in. I think I've acked them all.

I have applied 01-05 to xen-unstable.  09 has not yet been executed
(by me at least) so I think it should wait.

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 Jan 13 17:48:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RllEw-0000UI-0L; Fri, 13 Jan 2012 17:48:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RllEt-0000T5-Lc
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:48:31 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326476905!10890427!1
X-Originating-IP: [137.65.135.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6664 invoked from network); 13 Jan 2012 17:48:25 -0000
Received: from jfehlig1.provo.novell.com (HELO jfehlig1.provo.novell.com)
	(137.65.135.33) by server-3.tower-216.messagelabs.com with SMTP;
	13 Jan 2012 17:48:25 -0000
Received: by jfehlig1.provo.novell.com (Postfix, from userid 1000)
	id 0BB863EE2EB; Fri, 13 Jan 2012 10:48:24 -0700 (MST)
MIME-Version: 1.0
X-Mercurial-Node: 77587801a436ce36eb291be2d1ea677249044a6e
Message-Id: <77587801a436ce36eb29.1326476888@jfehlig1.provo.novell.com>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 13 Jan 2012 10:48:08 -0700
From: Jim Fehlig <jfehlig@suse.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Fix setting XENSTORED_ROOTDIR in xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Jim Fehlig <jfehlig@suse.com>
# Date 1326476571 25200
# Node ID 77587801a436ce36eb291be2d1ea677249044a6e
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
Fix setting XENSTORED_ROOTDIR in xencommons

Due to a logic bug, XENSTORED_ROOTDIR was not being set to
default value when zero length.

    Signed-off-by: Jim Fehlig <jfehlig@suse.com>

diff -r 5b2676ac1321 -r 77587801a436 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Jan 13 10:42:51 2012 -0700
@@ -61,7 +61,7 @@ do_start () {
 
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then
-		test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"
+		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="/var/lib/xenstored"
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
 		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:48:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RllEw-0000UI-0L; Fri, 13 Jan 2012 17:48:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RllEt-0000T5-Lc
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:48:31 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326476905!10890427!1
X-Originating-IP: [137.65.135.33]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6664 invoked from network); 13 Jan 2012 17:48:25 -0000
Received: from jfehlig1.provo.novell.com (HELO jfehlig1.provo.novell.com)
	(137.65.135.33) by server-3.tower-216.messagelabs.com with SMTP;
	13 Jan 2012 17:48:25 -0000
Received: by jfehlig1.provo.novell.com (Postfix, from userid 1000)
	id 0BB863EE2EB; Fri, 13 Jan 2012 10:48:24 -0700 (MST)
MIME-Version: 1.0
X-Mercurial-Node: 77587801a436ce36eb291be2d1ea677249044a6e
Message-Id: <77587801a436ce36eb29.1326476888@jfehlig1.provo.novell.com>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Fri, 13 Jan 2012 10:48:08 -0700
From: Jim Fehlig <jfehlig@suse.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Fix setting XENSTORED_ROOTDIR in xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Jim Fehlig <jfehlig@suse.com>
# Date 1326476571 25200
# Node ID 77587801a436ce36eb291be2d1ea677249044a6e
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
Fix setting XENSTORED_ROOTDIR in xencommons

Due to a logic bug, XENSTORED_ROOTDIR was not being set to
default value when zero length.

    Signed-off-by: Jim Fehlig <jfehlig@suse.com>

diff -r 5b2676ac1321 -r 77587801a436 tools/hotplug/Linux/init.d/xencommons
--- a/tools/hotplug/Linux/init.d/xencommons	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/hotplug/Linux/init.d/xencommons	Fri Jan 13 10:42:51 2012 -0700
@@ -61,7 +61,7 @@ do_start () {
 
 	if ! `xenstore-read -s / >/dev/null 2>&1`
 	then
-		test -z "$XENSTORED_ROOTDIR" || XENSTORED_ROOTDIR="/var/lib/xenstored"
+		test -z "$XENSTORED_ROOTDIR" && XENSTORED_ROOTDIR="/var/lib/xenstored"
 		rm -f "$XENSTORED_ROOTDIR"/tdb* &>/dev/null
 		test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:58:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RllO8-00015k-DG; Fri, 13 Jan 2012 17:58:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1RllO6-000150-Ta
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:58:03 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326477475!9022947!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22094 invoked from network); 13 Jan 2012 17:57:56 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 17:57:56 -0000
Received: by yhoo22 with SMTP id o22so10495057yho.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 09:57:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=aRgCKspu7UpyorFf9M4iSYUxva1h14as19zNwcBORM8=;
	b=qS61g9l2R+b4r9417/MIhG44DgvNPZnDzEJky2URE4He06Vxq1gGhwRY5lpN07Elow
	DFbbhcy9eUk2nLECjQY3E3n6XY6BDAS0S2WmCR4N2t/LqXMT8p35V8MJ57ipw8IalgVo
	q4Bxm52bn8dULJA4akDAiUmYq+3m0UOevyED0=
Received: by 10.236.141.37 with SMTP id f25mr3577917yhj.3.1326477475414;
	Fri, 13 Jan 2012 09:57:55 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id r68sm15698462yhm.18.2012.01.13.09.57.51
	(version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 09:57:54 -0800 (PST)
Message-ID: <4F10709B.8070804@cantab.net>
Date: Fri, 13 Jan 2012 17:57:47 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH 2/6] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/01/12 16:59, Wei Liu wrote:
> Enables users to unload netback module.
[...]
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 26af7b7..dd10c0d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1653,5 +1653,19 @@ failed_init:
>  
>  module_init(netback_init);
>  
> +static void __exit netback_exit(void)
> +{
> +	int i;
> +	for (i = 0; i < xen_netbk_group_nr; i++) {
> +		struct xen_netbk *netbk = &xen_netbk[i];
> +		del_timer(&netbk->net_timer);

This needs to be del_timer_sync().

> +		kthread_stop(netbk->task);
> +	}
> +	vfree(xen_netbk);
> +	page_pool_destroy();
> +	xenvif_xenbus_exit();
> +}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 17:58:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 17:58:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RllO8-00015k-DG; Fri, 13 Jan 2012 17:58:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1RllO6-000150-Ta
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 17:58:03 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326477475!9022947!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22094 invoked from network); 13 Jan 2012 17:57:56 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 17:57:56 -0000
Received: by yhoo22 with SMTP id o22so10495057yho.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 09:57:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=aRgCKspu7UpyorFf9M4iSYUxva1h14as19zNwcBORM8=;
	b=qS61g9l2R+b4r9417/MIhG44DgvNPZnDzEJky2URE4He06Vxq1gGhwRY5lpN07Elow
	DFbbhcy9eUk2nLECjQY3E3n6XY6BDAS0S2WmCR4N2t/LqXMT8p35V8MJ57ipw8IalgVo
	q4Bxm52bn8dULJA4akDAiUmYq+3m0UOevyED0=
Received: by 10.236.141.37 with SMTP id f25mr3577917yhj.3.1326477475414;
	Fri, 13 Jan 2012 09:57:55 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id r68sm15698462yhm.18.2012.01.13.09.57.51
	(version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 09:57:54 -0800 (PST)
Message-ID: <4F10709B.8070804@cantab.net>
Date: Fri, 13 Jan 2012 17:57:47 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH 2/6] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/01/12 16:59, Wei Liu wrote:
> Enables users to unload netback module.
[...]
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 26af7b7..dd10c0d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1653,5 +1653,19 @@ failed_init:
>  
>  module_init(netback_init);
>  
> +static void __exit netback_exit(void)
> +{
> +	int i;
> +	for (i = 0; i < xen_netbk_group_nr; i++) {
> +		struct xen_netbk *netbk = &xen_netbk[i];
> +		del_timer(&netbk->net_timer);

This needs to be del_timer_sync().

> +		kthread_stop(netbk->task);
> +	}
> +	vfree(xen_netbk);
> +	page_pool_destroy();
> +	xenvif_xenbus_exit();
> +}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:08:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18: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 1RllY3-0001qb-GE; Fri, 13 Jan 2012 18:08:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RllY1-0001qK-Vb
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:08:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326478068!55615968!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg4NTMx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17771 invoked from network); 13 Jan 2012 18:07:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 18:07:49 -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
	q0DI8AvT019877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Jan 2012 18:08:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0DI88YW023544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2012 18:08:09 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0DI87m0021618; Fri, 13 Jan 2012 12:08:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Jan 2012 10:08:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9713240327; Fri, 13 Jan 2012 09:27:03 -0500 (EST)
Date: Fri, 13 Jan 2012 09:27:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tejun Heo <tj@kernel.org>
Message-ID: <20120113142703.GA7707@phenom.dumpdata.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
	<20120110224537.GA6572@phenom.dumpdata.com>
	<20120110231552.GB26832@google.com>
	<20120111200435.GA8680@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111200435.GA8680@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F10730C.0007,ss=1,re=-2.300,fgs=0
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 03:04:35PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 10, 2012 at 03:15:52PM -0800, Tejun Heo wrote:
> > Hello,
> > 
> > On Tue, Jan 10, 2012 at 05:45:37PM -0500, Konrad Rzeszutek Wilk wrote:
> > > (early) [    0.000000] memblock_find: [0x0, 0xfcdd000) size=8409088 align=4096 nid=1024
> > > (early) [    0.000000] memblock_find: [0x805000, 0xfcdd000) - adjusted
> > > (early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0xfcdd000, 0xfcdd000) (early) - rejected
> > > (early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x1e03000, 0x220a000) (early) - rejected
> > > (early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x805000, 0x1000000) (early) - rejected
> > > (early) [    0.000000] memblock_find: cand [0x10000, 0x9b000) -> (early) [0x805000, 0x805000) (early) - rejected
> > > (early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
> > 
> > So, it actually is a legitimate alloc failure.  It seems I've tried a
> > bit too hard at simplifying the allocator.  Does the following fix the
> > problem?

Any thoughts of when this fix will show up in Ingo's tree for 3.3-rc0?

Thanks!
> > 
> > Thanks.
> > 
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 2f55f19..77b5f22 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -106,14 +106,17 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
> >  	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
> >  		end = memblock.current_limit;
> >  
> > -	/* adjust @start to avoid underflow and allocating the first page */
> > -	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
> > +	/* avoid allocating the first page */
> > +	start = max_t(phys_addr_t, start, PAGE_SIZE);
> >  	end = max(start, end);
> >  
> >  	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
> >  		this_start = clamp(this_start, start, end);
> >  		this_end = clamp(this_end, start, end);
> >  
> > +		if (this_end < size)
> > +			continue;
> > +
> >  		cand = round_down(this_end - size, align);
> >  		if (cand >= this_start)
> >  			return cand;
> 
> With that patch it boots!
> 
> 
> (early) [    0.000000] Initializing cgroup subsys cpuset
> (early) [    0.000000] Initializing cgroup subsys cpu
> (early) [    0.000000] Linux version 3.2.0-05693-g2c81411 (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP PREEMPT Wed Jan 11 13:19:30 EST 2012
> (early) [    0.000000] Command line: console=hvc0 debug earlyprintk=xen
> (early) [    0.000000] ACPI in unprivileged domain disabled
> (early) [    0.000000] Released 0 pages of unused memory
> (early) [    0.000000] Set 0 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 - 0000000200800000 (usable)
> (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] e820 update range: 0000000000000000 - 0000000000010000 (early) (usable)(early)  ==> (early) (reserved)(early) 
> (early) [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (early) (usable)(early) 
> (early) [    0.000000] No AGP bridge found
> (early) [    0.000000] last_pfn = 0x200800 max_arch_pfn = 0x400000000
> (early) [    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
> (early) [    0.000000] initial memory mapped : 0 - 10006000
> (early) [    0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480
> (early) [    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
> (early) [    0.000000]  0000000000 - 0100000000 page 4k
> (early) [    0.000000] kernel direct mapping tables up to 100000000 @ 7fb000-1000000
> (early) [    0.000000] xen: setting RW the range f74000 - 1000000
> (early) [    0.000000] init_memory_mapping: 0000000100000000-0000000200800000
> (early) [    0.000000]  0100000000 - 0200800000 page 4k
> (early) [    0.000000] kernel direct mapping tables up to 200800000 @ feff2000-100000000
> (early) [    0.000000] xen: setting RW the range ff7fb000 - 100000000
> (early) [    0.000000] RAMDISK: 02249000 - 10006000
> (early) [    0.000000] No NUMA configuration found
> (early) [    0.000000] Faking a node at 0000000000000000-0000000200800000
> (early) [    0.000000] Initmem setup node 0 0000000000000000-0000000200800000
> (early) [    0.000000]   NODE_DATA [00000000fffd9000 - 00000000ffffffff]
> (early) [    0.000000] Zone PFN ranges:
> (early) [    0.000000]   DMA      (early) 0x00000010 -> 0x00001000
> (early) [    0.000000]   DMA32    (early) 0x00001000 -> 0x00100000
> (early) [    0.000000]   Normal   (early) 0x00100000 -> 0x00200800
> (early) [    0.000000] Movable zone start PFN for each node
> (early) [    0.000000] Early memory PFN ranges
> (early) [    0.000000]     0: 0x00000010 -> 0x000000a0
> (early) [    0.000000]     0: 0x00000100 -> 0x00200800
> (early) [    0.000000] On node 0 totalpages: 2099088
> (early) [    0.000000]   DMA zone: 64 pages used for memmap
> (early) [    0.000000]   DMA zone: 1918 pages reserved
> (early) [    0.000000]   DMA zone: 2002 pages, LIFO batch:0
> (early) [    0.000000]   DMA32 zone: 16320 pages used for memmap
> (early) [    0.000000]   DMA32 zone: 1028160 pages, LIFO batch:31
> (early) [    0.000000]   Normal zone: 16416 pages used for memmap
> (early) [    0.000000]   Normal zone: 1034208 pages, LIFO batch:31
> (early) [    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> (early) [    0.000000] No local APIC present
> (early) [    0.000000] APIC: disable apic facility
> (early) [    0.000000] APIC: switched to apic NOOP
> (early) [    0.000000] nr_irqs_gsi: 16
> (early) [    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
> (early) [    0.000000] PCI: Warning: Cannot find a gap in the 32bit address range
> (early) [    0.000000] PCI: Unassigned devices with 32bit resource registers may break!
> (early) [    0.000000] Allocating PCI resources starting at 200900000 (gap: 200900000:400000)
> (early) [    0.000000] Booting paravirtualized kernel on Xen
> (early) [    0.000000] Xen version: 4.1-120111 (preserve-AD)
> (early) [    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
> (early) [    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8800fff31000 s82752 r8192 d23744 u114688
> (early) [    0.000000] pcpu-alloc: s82752 r8192 d23744 u114688 alloc=28*4096(early) 
> (early) [    0.000000] pcpu-alloc: (early) [0] (early) 0 (early) [0] (early) 1 (early) [0] (early) 2 (early) [0] (early) 3 (early) 
> (early) [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2064370
> (early) [    0.000000] Policy zone: Normal
> (early) [    0.000000] Kernel command line: console=hvc0 debug earlyprintk=xen
> (early) [    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
> (early) [    0.000000] Checking aperture...
> (early) [    0.000000] No AGP bridge found
> (early) [    0.000000] Calgary: detecting Calgary via BIOS EBDA area
> (early) [    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
> (early) [    0.000000] Memory: 3727344k/8396800k available (6482k kernel code, 448k absent, 4669008k reserved, 4624k data, 1256k init)
> (early) [    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> (early) [    0.000000] Preemptible hierarchical RCU implementation.
> (early) [    0.000000] NR_IRQS:262400 nr_irqs:304 16
> (early) [    0.000000] kmemleak: Early log buffer exceeded, please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE
> (early) [    0.000000] kmemleak: Kernel memory leak detector disabled
> (early) [    0.000000] Console: colour dummy device 80x25
> (early) [    0.000000] console [tty0] enabled
> [    0.000000] console [hvc0] enabled, bootconsole disabled
> (early) [    0.000000] console [hvc0] enabled, bootconsole disabled
> [    0.000000] Xen: using vcpuop timer interface
> [    0.000000] installing Xen timer for CPU 0
> [    0.000000] Detected 3292.616 MHz processor.
> [    0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 6585.23 BogoMIPS (lpj=3292616)
> [    0.000999] pid_max: default: 32768 minimum: 301
> [    0.000999] Security Framework initialized
> [    0.000999] SELinux:  Initializing.
> [    0.000999] SELinux:  Starting in permissive mode
> [    0.002170] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
> [    0.004675] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
> [    0.005213] Mount-cache hash table entries: 256
> [    0.005428] Initializing cgroup subsys cpuacct
> [    0.005436] Initializing cgroup subsys freezer
> [    0.005497] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
> [    0.005498] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
> [    0.005510] CPU: Physical Processor ID: 0
> [    0.005515] CPU: Processor Core ID: 0
> [    0.005576] SMP alternatives: switching to UP code
> [    0.005999] ftrace: allocating 23453 entries in 92 pages
> [    0.006057] cpu 0 spinlock event irq 17
> [    0.006112] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only.
> [    0.012038] NMI watchdog disabled (cpu0): hardware events not enabled
> [    0.018010] installing Xen timer for CPU 1
> [    0.018028] cpu 1 spinlock event irq 23
> [    0.018051] SMP alternatives: switching to SMP code
> [    0.019085] NMI watchdog disabled (cpu1): hardware events not enabled
> [    0.025009] installing Xen timer for CPU 2
> [    0.025027] cpu 2 spinlock event irq 29
> [    0.025121] NMI watchdog disabled (cpu2): hardware events not enabled
> [    0.031008] installing Xen timer for CPU 3
> [    0.031024] cpu 3 spinlock event irq 35
> [    0.031118] NMI watchdog disabled (cpu3): hardware events not enabled
> [    0.033006] Brought up 4 CPUs
> [    0.033666] kworker/u:0 used greatest stack depth: 5272 bytes left
> [    0.033666] Grant tables using version 2 layout.
> [    0.033666] Grant table initialized
> [    0.052849] RTC time: 165:165:165, date: 165/165/65
> [    0.053033] NET: Registered protocol family 16
> [    0.054556] PCI: setting up Xen PCI frontend stub
> [    0.054565] PCI: pci_cache_line_size set to 64 bytes
> [    0.065198] bio: create slab <bio-0> at 0
> [    0.065198] ACPI: Interpreter disabled.
> [    0.066004] xen/balloon: Initialising balloon driver.
> [    0.076187] xen-balloon: Initialising balloon driver.
> [    0.076187] vgaarb: loaded
> [    0.077064] usbcore: registered new interface driver usbfs
> [    0.077067] usbcore: registered new interface driver hub
> [    0.077107] usbcore: registered new device driver usb
> [    0.077107] PCI: System does not support PCI
> [    0.077107] PCI: System does not support PCI
> [    0.078054] NetLabel: Initializing
> [    0.078054] NetLabel:  domain hash size = 128
> [    0.078054] NetLabel:  protocols = UNLABELED CIPSOv4
> [    0.078054] NetLabel:  unlabeled traffic allowed by default
> [    0.078109] Switching to clocksource xen
> [    0.083574] pnp: PnP ACPI: disabled
> [    0.089832] PCI: max bus depth: 0 pci_try_num: 1
> [    0.089877] NET: Registered protocol family 2
> [    0.090665] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
> [    0.093957] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
> [    0.095324] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> [    0.095466] TCP: Hash tables configured (established 524288 bind 65536)
> [    0.095474] TCP reno registered
> [    0.095526] UDP hash table entries: 4096 (order: 5, 131072 bytes)
> [    0.095597] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
> [    0.095720] NET: Registered protocol family 1
> [    0.095957] RPC: Registered named UNIX socket transport module.
> [    0.095965] RPC: Registered udp transport module.
> [    0.095970] RPC: Registered tcp transport module.
> [    0.095976] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.095984] PCI: CLS 0 bytes, default 64
> [    0.096219] Trying to unpack rootfs image as initramfs...
> [    0.431565] Freeing initrd memory: 227060k freed
> [    0.475737] DMA-API: preallocated 32768 debug entries
> [    0.475961] DMA-API: debugging enabled by kernel config
> [    0.475969] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [    0.475977] Placing 64MB software IO TLB between ffff8800f2800000 - ffff8800f6800000
> [    0.475984] software IO TLB at phys 0xf2800000 - 0xf6800000
> [    0.476324] platform rtc_cmos: registered platform RTC device (no PNP device found)
> [    0.476472] Machine check injector initialized
> [    0.477452] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x17
> [    0.477466] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x17
> [    0.477486] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x17
> [    0.477503] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x17
> [    0.477586] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [    0.478032] audit: initializing netlink socket (disabled)
> [    0.478053] type=2000 audit(1326338469.110:1): initialized
> [    0.494006] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    0.499995] VFS: Disk quotas dquot_6.5.2
> [    0.500208] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    0.501045] NTFS driver 2.1.30 [Flags: R/W].
> [    0.501365] msgmni has been set to 7723
> [    0.501583] SELinux:  Registering netfilter hooks
> [    0.502294] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> [    0.502303] io scheduler noop registered
> [    0.502309] io scheduler deadline registered
> [    0.502405] io scheduler cfq registered (default)
> [    0.502633] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [    0.542586] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    0.573641] Non-volatile memory driver v1.3
> [    0.573649] Linux agpgart interface v0.103
> [    0.574083] [drm] Initialized drm 1.1.0 20060810
> [    0.577049] brd: module loaded
> [    0.578684] loop: module loaded
> [    0.579544] Fixed MDIO Bus: probed
> [    0.579551] tun: Universal TUN/TAP device driver, 1.6
> [    0.579556] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [    0.580300] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    0.580308] ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96
> [    0.580386] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    0.580392] ohci_hcd: block sizes: ed 80 td 96
> [    0.580466] uhci_hcd: USB Universal Host Controller Interface driver
> [    0.580701] usbcore: registered new interface driver usblp
> [    0.580780] usbcore: registered new interface driver libusual
> [    0.581039] i8042: PNP: No PS/2 controller found. Probing ports directly.
> [    0.581865] i8042: No controller found
> [    0.581951] mousedev: PS/2 mouse device common for all mice
> [    0.622367] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
> [    0.622469] rtc_cmos: probe of rtc_cmos failed with error -38
> [    0.622730] EFI Variables Facility v0.08 2004-May-17
> [    0.622805] zram: num_devices not specified. Using default: 1
> [    0.622812] zram: Creating 1 devices ...
> [    0.623448] Netfilter messages via NETLINK v0.30.
> [    0.623467] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> [    0.623780] ctnetlink v0.93: registering with nfnetlink.
> [    0.625065] ip_tables: (C) 2000-2006 Netfilter Core Team
> [    0.625099] TCP cubic registered
> [    0.625105] Initializing XFRM netlink socket
> [    0.625468] NET: Registered protocol family 10
> [    0.627394] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [    0.627485] IPv6 over IPv4 tunneling driver
> [    0.629062] NET: Registered protocol family 17
> [    0.629097] Registering the dns_resolver key type
> [    0.629362] PM: Hibernation image not present or could not be loaded.
> [    0.629386] registered taskstats version 1
> [    0.629448] XENBUS: Device with no driver: device/vif/0
> [    0.629454] XENBUS: Device with no driver: device/vfb/0
> [    0.629460] XENBUS: Device with no driver: device/vkbd/0
> [    0.629475]   Magic number: 1:252:3141
> [    0.630415] Freeing unused kernel memory: 1256k freed
> [    0.630622] Write protecting the kernel read-only data: 10240k
> [    0.636139] Freeing unused kernel memory: 1688k freed
> [    0.636508] Freeing unused kernel memory: 112k freed
> init started: BusyBox v1.14.3 (2012-01-11 13:22:11 EST)
> [    0.641820] consoletype used greatest stack depth: 5232 bytes left
> Mounting directories  [  OK  ]
> [    0.860513] modprobe used greatest stack depth: 5008 bytes left
> mount: mount point /sys/kernel/config does not exist
> [    0.865846] core_filesystem used greatest stack depth: 4880 bytes left
> [    0.874814] input: Xen Virtual Keyboard as /devices/virtual/input/input0
> [    0.875019] input: Xen Virtual Pointer as /devices/virtual/input/input1
> [    1.086237] Initialising Xen virtual ethernet driver.
> [    1.201417] udevd (1186): /proc/1186/oom_adj is deprecated, please use /proc/1186/oom_score_adj instead.
> udevd-work[1202]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory
> 
> [    1.307448] ip used greatest stack depth: 3696 bytes left
> Waiting for devices [  OK  ]
> Waiting for fb [  OK  ]
> Starting..[/dev/fb0]
> /dev/fb0: len:0
> /dev/fb0: bits/pixel32
> (7fa51499a000): Writting .. [800:600]
> Done!
> FATAL: Module agpgart_intel not found.
> [    1.464693] Console: switching to colour frame buffer device 100x37
> [    1.478942] [drm] radeon kernel modesetting enabled.
> WARNING: Error inserting video (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/acpi/video.ko): No such device
> WARNING: Error inserting mxm_wmi (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/platform/x86/mxm-wmi.ko): No such device
> WARNING: Error inserting drm_kms_helper (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
> WARNING: Error inserting ttm (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/ttm/ttm.ko): No such device
> FATAL: Error inserting nouveau (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/nouveau/nouveau.ko): No such device
> WARNING: Error inserting drm_kms_helper (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
> FATAL: Error inserting i915 (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/i915/i915.ko): No such device
> Starting..[/dev/fb0]
> /dev/fb0: len:0
> /dev/fb0: bits/pixel32
> (7fc2635c3000): Writting .. [800:600]
> Done!
> VGA: 0000:
> Waiting for network [  OK  ]
> Bringing up loopback interface:  [  OK  ]
> Bringing up interface eth0:  [    1.743980] device eth0 entered promiscuous mode
> [  OK  ]
> Bringing up interface switch:  
> Determining IP information for switch...[    1.790208] switch: port 1(eth0) entering forwarding state
> [    1.790244] switch: port 1(eth0) entering forwarding state
> [    1.790880] ip used greatest stack depth: 3376 bytes left
>  done.
> [  OK  ]
> Waiting for init.custom [  OK  ]
> 
> Starting SSHd ...
> 
>     SSH started [2314]
> 
> 
> Waiting for SSHd [  OK  ]
> WARNING: ssh currently running [2314] ignoring start request
> FATAL: Module dump_dma not found.
> ERROR: Module dump_dma does not exist in /proc/modules
> [    3.562254] SCSI subsystem initialized
> [    3.563911] Loading iSCSI transport class v2.0-870.
> [    3.566452] iscsi: registered transport (tcp)
> iscsistart: transport class version 2.0-870. iscsid version 2.0-872
> Could not get list of targets from firmware.
> Jan 12 03:21:12 g-pvops syslogd 1.5.0: restart.
> FATAL: Module evtchn not found.
> [    3.595640] Event-channel device installed.
> xencommons should be started first.
>            CPU0       CPU1       CPU2       CPU3       
>  16:       1330          0          0          0  xen-percpu-virq      timer0
>  17:          6          0          0          0  xen-percpu-ipi       spinlock0
>  18:       1872          0          0          0  xen-percpu-ipi       resched0
>  19:        129          0          0          0  xen-percpu-ipi       callfunc0
>  20:          0          0          0          0  xen-percpu-virq      debug0
>  21:         77          0          0          0  xen-percpu-ipi       callfuncsingle0
>  22:          0       1811          0          0  xen-percpu-virq      timer1
>  23:          0         14          0          0  xen-percpu-ipi       spinlock1
>  24:          0       2411          0          0  xen-percpu-ipi       resched1
>  25:          0        140          0          0  xen-percpu-ipi       callfunc1
>  26:          0          0          0          0  xen-percpu-virq      debug1
>  27:          0         78          0          0  xen-percpu-ipi       callfuncsingle1
>  28:          0          0       1204          0  xen-percpu-virq      timer2
>  29:          0          0          5          0  xen-percpu-ipi       spinlock2
>  30:          0          0       3713          0  xen-percpu-ipi       resched2
>  31:          0          0        148          0  xen-percpu-ipi       callfunc2
>  32:          0          0          0          0  xen-percpu-virq      debug2
>  33:          0          0        103          0  xen-percpu-ipi       callfuncsingle2
>  34:          0          0          0       1373  xen-percpu-virq      timer3
>  35:          0          0          0          5  xen-percpu-ipi       spinlock3
>  36:          0          0          0       2474  xen-percpu-ipi       resched3
>  37:          0          0          0        131  xen-percpu-ipi       callfunc3
>  38:          0          0          0          0  xen-percpu-virq      debug3
>  39:          0          0          0         88  xen-percpu-ipi       callfuncsingle3
>  40:        423          0          0          0   xen-dyn-event     xenbus
>  41:         81          0          0          0   xen-dyn-event     hvc_console
>  42:          0          0          0          0   xen-dyn-event     vkbd
>  43:         70          0          0          0   xen-dyn-event     vfb
>  44:         20          0          0          0   xen-dyn-event     eth0
> NMI:          0          0          0          0   Non-maskable interrupts
> LOC:          0          0          0          0   Local timer interrupts
> SPU:          0          0          0          0   Spurious interrupts
> PMI:          0          0          0          0   Performance monitoring interrupts
> IWI:          0          0          0          0   IRQ work interrupts
> RTR:          0          0          0          0   APIC ICR read retries
> RES:       1872       2411       3713       2474   Rescheduling interrupts
> CAL:        206        218        251        219   Function call interrupts
> TLB:          0          0          0          0   TLB shootdowns
> TRM:          0          0          0          0   Thermal event interrupts
> THR:          0          0          0          0   Threshold APIC interrupts
> MCE:          0          0          0          0   Machine check exceptions
> MCP:          0          0          0          0   Machine check polls
> ERR:          0
> MIS:          0
> 00000000-0000ffff : reserved
> 00010000-0009ffff : System RAM
> 000a0000-000fffff : reserved
>   000f0000-000fffff : System ROM
> 00100000-2007fffff : System RAM
>   01000000-016549db : Kernel code
>   016549dc-01ad89ff : Kernel data
>   01c1a000-01e2afff : Kernel bss
> Waiting for init.late [  OK  ]
> PING build.dumpdata.com (192.168.101.3) 56(84) bytes of data.
> 
> --- build.dumpdata.com ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.329/0.329/0.329/0.000 ms
> NFS done
>  [0x0->0x100000] pfn
>  [0x0->0x100000] level entry
>  [0x100000->0x7cfffff] missing
>  [0x100000->0x7cfffff] level top
> libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running?
> failed to stat /var/run/xenstored.pid: No such file or directory
> cannot init xl context
> [    4.481012] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
> [    4.482152] device-mapper: multipath: version 1.3.0 loaded
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260]
> Jan 12 03:21:13 g-pvops iscsid: transport class version 2.0-870. iscsid version 2.0-872
> Jan 12 03:21:13 g-pvops iscsid: iSCSI daemon with pid=2387 started!
> [    4.747529] scsi0 : iSCSI Initiator over TCP/IP
> [    4.751948]  connection1:0: detected conn error (1020)
> iscsiadm: Could not login to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260].
> iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
> Jan 12 03:21:14 g-pvops iscsid: conn 0 login rejected: initiator failed authorization with target
> Jan 12 03:21:14 g-pvops iscsid: Connection1:0 to [target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260] through [iface: default] is shutdown.
> 
> poweroff
>   No matching physical volumes found
>   No volume groups found
> Jan 12 03:21:18 g-pvops init: starting pid 2466, tty '/dev/tty2': '/bin/sh'
> Jan 12 03:21:18 g-pvops init: starting pid 2469, tty '/dev/tty1': '/bin/sh'
> Jan 12 03:21:18 g-pvops init: starting pid 2470, tty '/dev/ttyS0': '/bin/sh'
> Jan 12 03:21:18 g-pvops init: starting pid 2471, tty '/dev/hvc0': '/bin/sh'
> 
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.9 |~~~~~~~~~~~~~~~~~~~~~~~~~~
>         (c) 2001-2010  The world wide DirectFB Open Source Community
>         (c) 2000-2004  Convergence (integrated media) GmbH
>       ----------------------------------------------------------------
> 
> (*) DirectFB/Core: Single Application Core. (2012-01-11 18:23) 
> sh-4.1# 
> sh-4.1# poweroff
> (*) Direct/Memcpy: Using Generic 64bit memcpy()
> Jan 12 03:21:18 g-pvops init: starting pid 2477, tty '': '/etc/init.d/halt'
> sh-4.1# Usage: /etc/init.d/halt {start}
> The system is going down NOW!
> Sent SIGTERM to all processes
> (!) [ 2465:    0.000] --> Caught signal 15 (sent by pid 1, uid 0) <--
> (!) [ 2465:    0.000] --> Caught signal 11 (at 0x38, invalid address) <--
> Sent SIGKILL to all processes
> Requesting system poweroff
> [   12.086915] System halted.
> Parsing config file /mnt/lab/tst018/pv.xm
> Daemon running with PID 3972

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:08:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18: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 1RllY3-0001qb-GE; Fri, 13 Jan 2012 18:08:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RllY1-0001qK-Vb
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:08:18 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326478068!55615968!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDg4NTMx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17771 invoked from network); 13 Jan 2012 18:07:49 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 18:07:49 -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
	q0DI8AvT019877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Jan 2012 18:08:11 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0DI88YW023544
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2012 18:08:09 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0DI87m0021618; Fri, 13 Jan 2012 12:08:07 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Jan 2012 10:08:07 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9713240327; Fri, 13 Jan 2012 09:27:03 -0500 (EST)
Date: Fri, 13 Jan 2012 09:27:03 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tejun Heo <tj@kernel.org>
Message-ID: <20120113142703.GA7707@phenom.dumpdata.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
	<20120110224537.GA6572@phenom.dumpdata.com>
	<20120110231552.GB26832@google.com>
	<20120111200435.GA8680@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120111200435.GA8680@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F10730C.0007,ss=1,re=-2.300,fgs=0
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Bootup regression introduced by
 7bd0b0f0da3b1ec11cbcc798eb0ef747a1184077 ("memblock: Reimplement memblock
 allocation using reverse free area iterato") in v3.3-rc0
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 11, 2012 at 03:04:35PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 10, 2012 at 03:15:52PM -0800, Tejun Heo wrote:
> > Hello,
> > 
> > On Tue, Jan 10, 2012 at 05:45:37PM -0500, Konrad Rzeszutek Wilk wrote:
> > > (early) [    0.000000] memblock_find: [0x0, 0xfcdd000) size=8409088 align=4096 nid=1024
> > > (early) [    0.000000] memblock_find: [0x805000, 0xfcdd000) - adjusted
> > > (early) [    0.000000] memblock_find: cand [0x10567000, 0x100000000) -> (early) [0xfcdd000, 0xfcdd000) (early) - rejected
> > > (early) [    0.000000] memblock_find: cand [0x1e03000, 0x220a000) -> (early) [0x1e03000, 0x220a000) (early) - rejected
> > > (early) [    0.000000] memblock_find: cand [0x100000, 0x1000000) -> (early) [0x805000, 0x1000000) (early) - rejected
> > > (early) [    0.000000] memblock_find: cand [0x10000, 0x9b000) -> (early) [0x805000, 0x805000) (early) - rejected
> > > (early) [    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
> > 
> > So, it actually is a legitimate alloc failure.  It seems I've tried a
> > bit too hard at simplifying the allocator.  Does the following fix the
> > problem?

Any thoughts of when this fix will show up in Ingo's tree for 3.3-rc0?

Thanks!
> > 
> > Thanks.
> > 
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index 2f55f19..77b5f22 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -106,14 +106,17 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
> >  	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
> >  		end = memblock.current_limit;
> >  
> > -	/* adjust @start to avoid underflow and allocating the first page */
> > -	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
> > +	/* avoid allocating the first page */
> > +	start = max_t(phys_addr_t, start, PAGE_SIZE);
> >  	end = max(start, end);
> >  
> >  	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
> >  		this_start = clamp(this_start, start, end);
> >  		this_end = clamp(this_end, start, end);
> >  
> > +		if (this_end < size)
> > +			continue;
> > +
> >  		cand = round_down(this_end - size, align);
> >  		if (cand >= this_start)
> >  			return cand;
> 
> With that patch it boots!
> 
> 
> (early) [    0.000000] Initializing cgroup subsys cpuset
> (early) [    0.000000] Initializing cgroup subsys cpu
> (early) [    0.000000] Linux version 3.2.0-05693-g2c81411 (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP PREEMPT Wed Jan 11 13:19:30 EST 2012
> (early) [    0.000000] Command line: console=hvc0 debug earlyprintk=xen
> (early) [    0.000000] ACPI in unprivileged domain disabled
> (early) [    0.000000] Released 0 pages of unused memory
> (early) [    0.000000] Set 0 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 - 0000000200800000 (usable)
> (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] e820 update range: 0000000000000000 - 0000000000010000 (early) (usable)(early)  ==> (early) (reserved)(early) 
> (early) [    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (early) (usable)(early) 
> (early) [    0.000000] No AGP bridge found
> (early) [    0.000000] last_pfn = 0x200800 max_arch_pfn = 0x400000000
> (early) [    0.000000] last_pfn = 0x100000 max_arch_pfn = 0x400000000
> (early) [    0.000000] initial memory mapped : 0 - 10006000
> (early) [    0.000000] Base memory trampoline at [ffff88000009b000] 9b000 size 20480
> (early) [    0.000000] init_memory_mapping: 0000000000000000-0000000100000000
> (early) [    0.000000]  0000000000 - 0100000000 page 4k
> (early) [    0.000000] kernel direct mapping tables up to 100000000 @ 7fb000-1000000
> (early) [    0.000000] xen: setting RW the range f74000 - 1000000
> (early) [    0.000000] init_memory_mapping: 0000000100000000-0000000200800000
> (early) [    0.000000]  0100000000 - 0200800000 page 4k
> (early) [    0.000000] kernel direct mapping tables up to 200800000 @ feff2000-100000000
> (early) [    0.000000] xen: setting RW the range ff7fb000 - 100000000
> (early) [    0.000000] RAMDISK: 02249000 - 10006000
> (early) [    0.000000] No NUMA configuration found
> (early) [    0.000000] Faking a node at 0000000000000000-0000000200800000
> (early) [    0.000000] Initmem setup node 0 0000000000000000-0000000200800000
> (early) [    0.000000]   NODE_DATA [00000000fffd9000 - 00000000ffffffff]
> (early) [    0.000000] Zone PFN ranges:
> (early) [    0.000000]   DMA      (early) 0x00000010 -> 0x00001000
> (early) [    0.000000]   DMA32    (early) 0x00001000 -> 0x00100000
> (early) [    0.000000]   Normal   (early) 0x00100000 -> 0x00200800
> (early) [    0.000000] Movable zone start PFN for each node
> (early) [    0.000000] Early memory PFN ranges
> (early) [    0.000000]     0: 0x00000010 -> 0x000000a0
> (early) [    0.000000]     0: 0x00000100 -> 0x00200800
> (early) [    0.000000] On node 0 totalpages: 2099088
> (early) [    0.000000]   DMA zone: 64 pages used for memmap
> (early) [    0.000000]   DMA zone: 1918 pages reserved
> (early) [    0.000000]   DMA zone: 2002 pages, LIFO batch:0
> (early) [    0.000000]   DMA32 zone: 16320 pages used for memmap
> (early) [    0.000000]   DMA32 zone: 1028160 pages, LIFO batch:31
> (early) [    0.000000]   Normal zone: 16416 pages used for memmap
> (early) [    0.000000]   Normal zone: 1034208 pages, LIFO batch:31
> (early) [    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
> (early) [    0.000000] No local APIC present
> (early) [    0.000000] APIC: disable apic facility
> (early) [    0.000000] APIC: switched to apic NOOP
> (early) [    0.000000] nr_irqs_gsi: 16
> (early) [    0.000000] PM: Registered nosave memory: 00000000000a0000 - 0000000000100000
> (early) [    0.000000] PCI: Warning: Cannot find a gap in the 32bit address range
> (early) [    0.000000] PCI: Unassigned devices with 32bit resource registers may break!
> (early) [    0.000000] Allocating PCI resources starting at 200900000 (gap: 200900000:400000)
> (early) [    0.000000] Booting paravirtualized kernel on Xen
> (early) [    0.000000] Xen version: 4.1-120111 (preserve-AD)
> (early) [    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
> (early) [    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8800fff31000 s82752 r8192 d23744 u114688
> (early) [    0.000000] pcpu-alloc: s82752 r8192 d23744 u114688 alloc=28*4096(early) 
> (early) [    0.000000] pcpu-alloc: (early) [0] (early) 0 (early) [0] (early) 1 (early) [0] (early) 2 (early) [0] (early) 3 (early) 
> (early) [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2064370
> (early) [    0.000000] Policy zone: Normal
> (early) [    0.000000] Kernel command line: console=hvc0 debug earlyprintk=xen
> (early) [    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
> (early) [    0.000000] Checking aperture...
> (early) [    0.000000] No AGP bridge found
> (early) [    0.000000] Calgary: detecting Calgary via BIOS EBDA area
> (early) [    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
> (early) [    0.000000] Memory: 3727344k/8396800k available (6482k kernel code, 448k absent, 4669008k reserved, 4624k data, 1256k init)
> (early) [    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> (early) [    0.000000] Preemptible hierarchical RCU implementation.
> (early) [    0.000000] NR_IRQS:262400 nr_irqs:304 16
> (early) [    0.000000] kmemleak: Early log buffer exceeded, please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE
> (early) [    0.000000] kmemleak: Kernel memory leak detector disabled
> (early) [    0.000000] Console: colour dummy device 80x25
> (early) [    0.000000] console [tty0] enabled
> [    0.000000] console [hvc0] enabled, bootconsole disabled
> (early) [    0.000000] console [hvc0] enabled, bootconsole disabled
> [    0.000000] Xen: using vcpuop timer interface
> [    0.000000] installing Xen timer for CPU 0
> [    0.000000] Detected 3292.616 MHz processor.
> [    0.000999] Calibrating delay loop (skipped), value calculated using timer frequency.. 6585.23 BogoMIPS (lpj=3292616)
> [    0.000999] pid_max: default: 32768 minimum: 301
> [    0.000999] Security Framework initialized
> [    0.000999] SELinux:  Initializing.
> [    0.000999] SELinux:  Starting in permissive mode
> [    0.002170] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
> [    0.004675] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
> [    0.005213] Mount-cache hash table entries: 256
> [    0.005428] Initializing cgroup subsys cpuacct
> [    0.005436] Initializing cgroup subsys freezer
> [    0.005497] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
> [    0.005498] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8)
> [    0.005510] CPU: Physical Processor ID: 0
> [    0.005515] CPU: Processor Core ID: 0
> [    0.005576] SMP alternatives: switching to UP code
> [    0.005999] ftrace: allocating 23453 entries in 92 pages
> [    0.006057] cpu 0 spinlock event irq 17
> [    0.006112] Performance Events: unsupported p6 CPU model 42 no PMU driver, software events only.
> [    0.012038] NMI watchdog disabled (cpu0): hardware events not enabled
> [    0.018010] installing Xen timer for CPU 1
> [    0.018028] cpu 1 spinlock event irq 23
> [    0.018051] SMP alternatives: switching to SMP code
> [    0.019085] NMI watchdog disabled (cpu1): hardware events not enabled
> [    0.025009] installing Xen timer for CPU 2
> [    0.025027] cpu 2 spinlock event irq 29
> [    0.025121] NMI watchdog disabled (cpu2): hardware events not enabled
> [    0.031008] installing Xen timer for CPU 3
> [    0.031024] cpu 3 spinlock event irq 35
> [    0.031118] NMI watchdog disabled (cpu3): hardware events not enabled
> [    0.033006] Brought up 4 CPUs
> [    0.033666] kworker/u:0 used greatest stack depth: 5272 bytes left
> [    0.033666] Grant tables using version 2 layout.
> [    0.033666] Grant table initialized
> [    0.052849] RTC time: 165:165:165, date: 165/165/65
> [    0.053033] NET: Registered protocol family 16
> [    0.054556] PCI: setting up Xen PCI frontend stub
> [    0.054565] PCI: pci_cache_line_size set to 64 bytes
> [    0.065198] bio: create slab <bio-0> at 0
> [    0.065198] ACPI: Interpreter disabled.
> [    0.066004] xen/balloon: Initialising balloon driver.
> [    0.076187] xen-balloon: Initialising balloon driver.
> [    0.076187] vgaarb: loaded
> [    0.077064] usbcore: registered new interface driver usbfs
> [    0.077067] usbcore: registered new interface driver hub
> [    0.077107] usbcore: registered new device driver usb
> [    0.077107] PCI: System does not support PCI
> [    0.077107] PCI: System does not support PCI
> [    0.078054] NetLabel: Initializing
> [    0.078054] NetLabel:  domain hash size = 128
> [    0.078054] NetLabel:  protocols = UNLABELED CIPSOv4
> [    0.078054] NetLabel:  unlabeled traffic allowed by default
> [    0.078109] Switching to clocksource xen
> [    0.083574] pnp: PnP ACPI: disabled
> [    0.089832] PCI: max bus depth: 0 pci_try_num: 1
> [    0.089877] NET: Registered protocol family 2
> [    0.090665] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes)
> [    0.093957] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
> [    0.095324] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> [    0.095466] TCP: Hash tables configured (established 524288 bind 65536)
> [    0.095474] TCP reno registered
> [    0.095526] UDP hash table entries: 4096 (order: 5, 131072 bytes)
> [    0.095597] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
> [    0.095720] NET: Registered protocol family 1
> [    0.095957] RPC: Registered named UNIX socket transport module.
> [    0.095965] RPC: Registered udp transport module.
> [    0.095970] RPC: Registered tcp transport module.
> [    0.095976] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [    0.095984] PCI: CLS 0 bytes, default 64
> [    0.096219] Trying to unpack rootfs image as initramfs...
> [    0.431565] Freeing initrd memory: 227060k freed
> [    0.475737] DMA-API: preallocated 32768 debug entries
> [    0.475961] DMA-API: debugging enabled by kernel config
> [    0.475969] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
> [    0.475977] Placing 64MB software IO TLB between ffff8800f2800000 - ffff8800f6800000
> [    0.475984] software IO TLB at phys 0xf2800000 - 0xf6800000
> [    0.476324] platform rtc_cmos: registered platform RTC device (no PNP device found)
> [    0.476472] Machine check injector initialized
> [    0.477452] microcode: CPU0 sig=0x206a7, pf=0x2, revision=0x17
> [    0.477466] microcode: CPU1 sig=0x206a7, pf=0x2, revision=0x17
> [    0.477486] microcode: CPU2 sig=0x206a7, pf=0x2, revision=0x17
> [    0.477503] microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x17
> [    0.477586] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> [    0.478032] audit: initializing netlink socket (disabled)
> [    0.478053] type=2000 audit(1326338469.110:1): initialized
> [    0.494006] HugeTLB registered 2 MB page size, pre-allocated 0 pages
> [    0.499995] VFS: Disk quotas dquot_6.5.2
> [    0.500208] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [    0.501045] NTFS driver 2.1.30 [Flags: R/W].
> [    0.501365] msgmni has been set to 7723
> [    0.501583] SELinux:  Registering netfilter hooks
> [    0.502294] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> [    0.502303] io scheduler noop registered
> [    0.502309] io scheduler deadline registered
> [    0.502405] io scheduler cfq registered (default)
> [    0.502633] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> [    0.542586] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    0.573641] Non-volatile memory driver v1.3
> [    0.573649] Linux agpgart interface v0.103
> [    0.574083] [drm] Initialized drm 1.1.0 20060810
> [    0.577049] brd: module loaded
> [    0.578684] loop: module loaded
> [    0.579544] Fixed MDIO Bus: probed
> [    0.579551] tun: Universal TUN/TAP device driver, 1.6
> [    0.579556] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [    0.580300] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    0.580308] ehci_hcd: block sizes: qh 112 qtd 96 itd 192 sitd 96
> [    0.580386] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    0.580392] ohci_hcd: block sizes: ed 80 td 96
> [    0.580466] uhci_hcd: USB Universal Host Controller Interface driver
> [    0.580701] usbcore: registered new interface driver usblp
> [    0.580780] usbcore: registered new interface driver libusual
> [    0.581039] i8042: PNP: No PS/2 controller found. Probing ports directly.
> [    0.581865] i8042: No controller found
> [    0.581951] mousedev: PS/2 mouse device common for all mice
> [    0.622367] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
> [    0.622469] rtc_cmos: probe of rtc_cmos failed with error -38
> [    0.622730] EFI Variables Facility v0.08 2004-May-17
> [    0.622805] zram: num_devices not specified. Using default: 1
> [    0.622812] zram: Creating 1 devices ...
> [    0.623448] Netfilter messages via NETLINK v0.30.
> [    0.623467] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> [    0.623780] ctnetlink v0.93: registering with nfnetlink.
> [    0.625065] ip_tables: (C) 2000-2006 Netfilter Core Team
> [    0.625099] TCP cubic registered
> [    0.625105] Initializing XFRM netlink socket
> [    0.625468] NET: Registered protocol family 10
> [    0.627394] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [    0.627485] IPv6 over IPv4 tunneling driver
> [    0.629062] NET: Registered protocol family 17
> [    0.629097] Registering the dns_resolver key type
> [    0.629362] PM: Hibernation image not present or could not be loaded.
> [    0.629386] registered taskstats version 1
> [    0.629448] XENBUS: Device with no driver: device/vif/0
> [    0.629454] XENBUS: Device with no driver: device/vfb/0
> [    0.629460] XENBUS: Device with no driver: device/vkbd/0
> [    0.629475]   Magic number: 1:252:3141
> [    0.630415] Freeing unused kernel memory: 1256k freed
> [    0.630622] Write protecting the kernel read-only data: 10240k
> [    0.636139] Freeing unused kernel memory: 1688k freed
> [    0.636508] Freeing unused kernel memory: 112k freed
> init started: BusyBox v1.14.3 (2012-01-11 13:22:11 EST)
> [    0.641820] consoletype used greatest stack depth: 5232 bytes left
> Mounting directories  [  OK  ]
> [    0.860513] modprobe used greatest stack depth: 5008 bytes left
> mount: mount point /sys/kernel/config does not exist
> [    0.865846] core_filesystem used greatest stack depth: 4880 bytes left
> [    0.874814] input: Xen Virtual Keyboard as /devices/virtual/input/input0
> [    0.875019] input: Xen Virtual Pointer as /devices/virtual/input/input1
> [    1.086237] Initialising Xen virtual ethernet driver.
> [    1.201417] udevd (1186): /proc/1186/oom_adj is deprecated, please use /proc/1186/oom_score_adj instead.
> udevd-work[1202]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory
> 
> [    1.307448] ip used greatest stack depth: 3696 bytes left
> Waiting for devices [  OK  ]
> Waiting for fb [  OK  ]
> Starting..[/dev/fb0]
> /dev/fb0: len:0
> /dev/fb0: bits/pixel32
> (7fa51499a000): Writting .. [800:600]
> Done!
> FATAL: Module agpgart_intel not found.
> [    1.464693] Console: switching to colour frame buffer device 100x37
> [    1.478942] [drm] radeon kernel modesetting enabled.
> WARNING: Error inserting video (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/acpi/video.ko): No such device
> WARNING: Error inserting mxm_wmi (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/platform/x86/mxm-wmi.ko): No such device
> WARNING: Error inserting drm_kms_helper (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
> WARNING: Error inserting ttm (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/ttm/ttm.ko): No such device
> FATAL: Error inserting nouveau (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/nouveau/nouveau.ko): No such device
> WARNING: Error inserting drm_kms_helper (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device
> FATAL: Error inserting i915 (/lib/modules/3.2.0-05693-g2c81411/kernel/drivers/gpu/drm/i915/i915.ko): No such device
> Starting..[/dev/fb0]
> /dev/fb0: len:0
> /dev/fb0: bits/pixel32
> (7fc2635c3000): Writting .. [800:600]
> Done!
> VGA: 0000:
> Waiting for network [  OK  ]
> Bringing up loopback interface:  [  OK  ]
> Bringing up interface eth0:  [    1.743980] device eth0 entered promiscuous mode
> [  OK  ]
> Bringing up interface switch:  
> Determining IP information for switch...[    1.790208] switch: port 1(eth0) entering forwarding state
> [    1.790244] switch: port 1(eth0) entering forwarding state
> [    1.790880] ip used greatest stack depth: 3376 bytes left
>  done.
> [  OK  ]
> Waiting for init.custom [  OK  ]
> 
> Starting SSHd ...
> 
>     SSH started [2314]
> 
> 
> Waiting for SSHd [  OK  ]
> WARNING: ssh currently running [2314] ignoring start request
> FATAL: Module dump_dma not found.
> ERROR: Module dump_dma does not exist in /proc/modules
> [    3.562254] SCSI subsystem initialized
> [    3.563911] Loading iSCSI transport class v2.0-870.
> [    3.566452] iscsi: registered transport (tcp)
> iscsistart: transport class version 2.0-870. iscsid version 2.0-872
> Could not get list of targets from firmware.
> Jan 12 03:21:12 g-pvops syslogd 1.5.0: restart.
> FATAL: Module evtchn not found.
> [    3.595640] Event-channel device installed.
> xencommons should be started first.
>            CPU0       CPU1       CPU2       CPU3       
>  16:       1330          0          0          0  xen-percpu-virq      timer0
>  17:          6          0          0          0  xen-percpu-ipi       spinlock0
>  18:       1872          0          0          0  xen-percpu-ipi       resched0
>  19:        129          0          0          0  xen-percpu-ipi       callfunc0
>  20:          0          0          0          0  xen-percpu-virq      debug0
>  21:         77          0          0          0  xen-percpu-ipi       callfuncsingle0
>  22:          0       1811          0          0  xen-percpu-virq      timer1
>  23:          0         14          0          0  xen-percpu-ipi       spinlock1
>  24:          0       2411          0          0  xen-percpu-ipi       resched1
>  25:          0        140          0          0  xen-percpu-ipi       callfunc1
>  26:          0          0          0          0  xen-percpu-virq      debug1
>  27:          0         78          0          0  xen-percpu-ipi       callfuncsingle1
>  28:          0          0       1204          0  xen-percpu-virq      timer2
>  29:          0          0          5          0  xen-percpu-ipi       spinlock2
>  30:          0          0       3713          0  xen-percpu-ipi       resched2
>  31:          0          0        148          0  xen-percpu-ipi       callfunc2
>  32:          0          0          0          0  xen-percpu-virq      debug2
>  33:          0          0        103          0  xen-percpu-ipi       callfuncsingle2
>  34:          0          0          0       1373  xen-percpu-virq      timer3
>  35:          0          0          0          5  xen-percpu-ipi       spinlock3
>  36:          0          0          0       2474  xen-percpu-ipi       resched3
>  37:          0          0          0        131  xen-percpu-ipi       callfunc3
>  38:          0          0          0          0  xen-percpu-virq      debug3
>  39:          0          0          0         88  xen-percpu-ipi       callfuncsingle3
>  40:        423          0          0          0   xen-dyn-event     xenbus
>  41:         81          0          0          0   xen-dyn-event     hvc_console
>  42:          0          0          0          0   xen-dyn-event     vkbd
>  43:         70          0          0          0   xen-dyn-event     vfb
>  44:         20          0          0          0   xen-dyn-event     eth0
> NMI:          0          0          0          0   Non-maskable interrupts
> LOC:          0          0          0          0   Local timer interrupts
> SPU:          0          0          0          0   Spurious interrupts
> PMI:          0          0          0          0   Performance monitoring interrupts
> IWI:          0          0          0          0   IRQ work interrupts
> RTR:          0          0          0          0   APIC ICR read retries
> RES:       1872       2411       3713       2474   Rescheduling interrupts
> CAL:        206        218        251        219   Function call interrupts
> TLB:          0          0          0          0   TLB shootdowns
> TRM:          0          0          0          0   Thermal event interrupts
> THR:          0          0          0          0   Threshold APIC interrupts
> MCE:          0          0          0          0   Machine check exceptions
> MCP:          0          0          0          0   Machine check polls
> ERR:          0
> MIS:          0
> 00000000-0000ffff : reserved
> 00010000-0009ffff : System RAM
> 000a0000-000fffff : reserved
>   000f0000-000fffff : System ROM
> 00100000-2007fffff : System RAM
>   01000000-016549db : Kernel code
>   016549dc-01ad89ff : Kernel data
>   01c1a000-01e2afff : Kernel bss
> Waiting for init.late [  OK  ]
> PING build.dumpdata.com (192.168.101.3) 56(84) bytes of data.
> 
> --- build.dumpdata.com ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.329/0.329/0.329/0.000 ms
> NFS done
>  [0x0->0x100000] pfn
>  [0x0->0x100000] level entry
>  [0x100000->0x7cfffff] missing
>  [0x100000->0x7cfffff] level top
> libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running?
> failed to stat /var/run/xenstored.pid: No such file or directory
> cannot init xl context
> [    4.481012] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
> [    4.482152] device-mapper: multipath: version 1.3.0 loaded
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> 192.168.101.2:3260,1 iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb
> Logging in to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260]
> Jan 12 03:21:13 g-pvops iscsid: transport class version 2.0-870. iscsid version 2.0-872
> Jan 12 03:21:13 g-pvops iscsid: iSCSI daemon with pid=2387 started!
> [    4.747529] scsi0 : iSCSI Initiator over TCP/IP
> [    4.751948]  connection1:0: detected conn error (1020)
> iscsiadm: Could not login to [iface: default, target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260].
> iscsiadm: initiator reported error (19 - encountered non-retryable iSCSI login failure)
> Jan 12 03:21:14 g-pvops iscsid: conn 0 login rejected: initiator failed authorization with target
> Jan 12 03:21:14 g-pvops iscsid: Connection1:0 to [target: iqn.2003-01.org.linux-iscsi.target:sn.726f464255f7b1dc47c8131b3471abeb, portal: 192.168.101.2,3260] through [iface: default] is shutdown.
> 
> poweroff
>   No matching physical volumes found
>   No volume groups found
> Jan 12 03:21:18 g-pvops init: starting pid 2466, tty '/dev/tty2': '/bin/sh'
> Jan 12 03:21:18 g-pvops init: starting pid 2469, tty '/dev/tty1': '/bin/sh'
> Jan 12 03:21:18 g-pvops init: starting pid 2470, tty '/dev/ttyS0': '/bin/sh'
> Jan 12 03:21:18 g-pvops init: starting pid 2471, tty '/dev/hvc0': '/bin/sh'
> 
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.9 |~~~~~~~~~~~~~~~~~~~~~~~~~~
>         (c) 2001-2010  The world wide DirectFB Open Source Community
>         (c) 2000-2004  Convergence (integrated media) GmbH
>       ----------------------------------------------------------------
> 
> (*) DirectFB/Core: Single Application Core. (2012-01-11 18:23) 
> sh-4.1# 
> sh-4.1# poweroff
> (*) Direct/Memcpy: Using Generic 64bit memcpy()
> Jan 12 03:21:18 g-pvops init: starting pid 2477, tty '': '/etc/init.d/halt'
> sh-4.1# Usage: /etc/init.d/halt {start}
> The system is going down NOW!
> Sent SIGTERM to all processes
> (!) [ 2465:    0.000] --> Caught signal 15 (sent by pid 1, uid 0) <--
> (!) [ 2465:    0.000] --> Caught signal 11 (at 0x38, invalid address) <--
> Sent SIGKILL to all processes
> Requesting system poweroff
> [   12.086915] System halted.
> Parsing config file /mnt/lab/tst018/pv.xm
> Daemon running with PID 3972

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:14:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18: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 1Rlldl-00026y-Fs; Fri, 13 Jan 2012 18:14: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 1Rlldj-00026l-E0
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:14:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326478445!10750023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10699 invoked from network); 13 Jan 2012 18:14:05 -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 Jan 2012 18:14:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10012445"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 18:14:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 18:14: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 1Rlldc-0005QM-Lf;
	Fri, 13 Jan 2012 18:14:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlldc-00068f-6q;
	Fri, 13 Jan 2012 18:14:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10680-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 18:14:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10680: 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 10680 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10680/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           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-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-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6f5fff70668b
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 626 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 Jan 13 18:14:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18: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 1Rlldl-00026y-Fs; Fri, 13 Jan 2012 18:14: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 1Rlldj-00026l-E0
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:14:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326478445!10750023!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10699 invoked from network); 13 Jan 2012 18:14:05 -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 Jan 2012 18:14:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10012445"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 18:14:05 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 18:14: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 1Rlldc-0005QM-Lf;
	Fri, 13 Jan 2012 18:14:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlldc-00068f-6q;
	Fri, 13 Jan 2012 18:14:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10680-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 18:14:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10680: 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 10680 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10680/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           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-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-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6f5fff70668b
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 626 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 Jan 13 18:21:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rllkt-0002IO-Ga; Fri, 13 Jan 2012 18:21:35 +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 1Rllks-0002II-8Y
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:21:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326478758!48469294!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13243 invoked from network); 13 Jan 2012 18:19:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 18:19:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20857402"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:21:26 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Jan 2012
	13:21:26 -0500
Message-ID: <4F107625.7090601@citrix.com>
Date: Fri, 13 Jan 2012 18:21:25 +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: Wei Liu <wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/01/12 16:59, Wei Liu wrote:
> This patch implements 1:1 model netback. We utilizes NAPI and kthread
> to do the weight-lifting job:
> 
>   - NAPI is used for guest side TX (host side RX)
>   - kthread is used for guest side RX (host side TX)
> 
> This model provides better scheduling fairness among vifs. It also
> lays the foundation for future work.
> 
> The major defect for the current implementation is that in the NAPI
> poll handler we don't actually disable interrupt. Xen stuff is
> different from real hardware, it requires some other tuning of ring
> macros.

RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to me.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:21:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rllkt-0002IO-Ga; Fri, 13 Jan 2012 18:21:35 +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 1Rllks-0002II-8Y
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:21:34 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326478758!48469294!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTcwNzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13243 invoked from network); 13 Jan 2012 18:19:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 18:19:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320642000"; d="scan'208";a="20857402"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 13:21:26 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Fri, 13 Jan 2012
	13:21:26 -0500
Message-ID: <4F107625.7090601@citrix.com>
Date: Fri, 13 Jan 2012 18:21:25 +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: Wei Liu <wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/01/12 16:59, Wei Liu wrote:
> This patch implements 1:1 model netback. We utilizes NAPI and kthread
> to do the weight-lifting job:
> 
>   - NAPI is used for guest side TX (host side RX)
>   - kthread is used for guest side RX (host side TX)
> 
> This model provides better scheduling fairness among vifs. It also
> lays the foundation for future work.
> 
> The major defect for the current implementation is that in the NAPI
> poll handler we don't actually disable interrupt. Xen stuff is
> different from real hardware, it requires some other tuning of ring
> macros.

RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to me.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:44:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18:44:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlm7C-0002Wt-Kd; Fri, 13 Jan 2012 18:44:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Rlm7A-0002Wo-KY
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:44:36 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326480268!9065266!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 18872 invoked from network); 13 Jan 2012 18:44:29 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 18:44:29 -0000
Received: by ghbg18 with SMTP id g18so21884259ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 10:44:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=jVkFFzq7QbQ67wd7/9q9OnMq74X0g3rdWdPYN8SVEKc=;
	b=o0kkw8FS9fr46Aac6mXTaNRypBZ/rFAa5WPpburf13rndrQHcj60bZgmraCigTGXgJ
	5rdpeRgG2S1lhn3Hmag9CJ7Gvhuy+P5AIkctkc/0+HnbfitOpOPIca6qAwLg5EF6G1A7
	bPbJtqacSliuGcsWm3sRTI5/uEivxhh5H2HEY=
Received: by 10.236.173.132 with SMTP id v4mr3548300yhl.78.1326480268104;
	Fri, 13 Jan 2012 10:44:28 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id 31sm25366238ant.14.2012.01.13.10.44.26
	(version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 10:44:27 -0800 (PST)
Message-ID: <4F107B89.6000004@cantab.net>
Date: Fri, 13 Jan 2012 18:44:25 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-5-git-send-email-wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH 4/6] netback: add module get/put
 operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/01/12 16:59, Wei Liu wrote:
> If there is vif running and user unloads netback, it will certainly
> cause problems.

Is this necessary?  As part of module unload netback_remove() will be
called and this will clean everything correctly, yes?

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netback/interface.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 93cb212..3126028 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>  	if (vif->irq)
>  		return 0;
>  
> +	__module_get(THIS_MODULE);
> +
>  	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
>  	if (err < 0)
>  		goto err;
> @@ -405,4 +407,6 @@ void xenvif_disconnect(struct xenvif *vif)
>  	xen_netbk_unmap_frontend_rings(vif);
>  
>  	free_netdev(vif->dev);
> +
> +	module_put(THIS_MODULE);
>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:44:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18:44:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlm7C-0002Wt-Kd; Fri, 13 Jan 2012 18:44:38 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1Rlm7A-0002Wo-KY
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:44:36 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326480268!9065266!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 18872 invoked from network); 13 Jan 2012 18:44:29 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 18:44:29 -0000
Received: by ghbg18 with SMTP id g18so21884259ghb.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 10:44:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=jVkFFzq7QbQ67wd7/9q9OnMq74X0g3rdWdPYN8SVEKc=;
	b=o0kkw8FS9fr46Aac6mXTaNRypBZ/rFAa5WPpburf13rndrQHcj60bZgmraCigTGXgJ
	5rdpeRgG2S1lhn3Hmag9CJ7Gvhuy+P5AIkctkc/0+HnbfitOpOPIca6qAwLg5EF6G1A7
	bPbJtqacSliuGcsWm3sRTI5/uEivxhh5H2HEY=
Received: by 10.236.173.132 with SMTP id v4mr3548300yhl.78.1326480268104;
	Fri, 13 Jan 2012 10:44:28 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id 31sm25366238ant.14.2012.01.13.10.44.26
	(version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 10:44:27 -0800 (PST)
Message-ID: <4F107B89.6000004@cantab.net>
Date: Fri, 13 Jan 2012 18:44:25 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-5-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-5-git-send-email-wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH 4/6] netback: add module get/put
 operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/01/12 16:59, Wei Liu wrote:
> If there is vif running and user unloads netback, it will certainly
> cause problems.

Is this necessary?  As part of module unload netback_remove() will be
called and this will clean everything correctly, yes?

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netback/interface.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 93cb212..3126028 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>  	if (vif->irq)
>  		return 0;
>  
> +	__module_get(THIS_MODULE);
> +
>  	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
>  	if (err < 0)
>  		goto err;
> @@ -405,4 +407,6 @@ void xenvif_disconnect(struct xenvif *vif)
>  	xen_netbk_unmap_frontend_rings(vif);
>  
>  	free_netdev(vif->dev);
> +
> +	module_put(THIS_MODULE);
>  }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:48:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlmAO-0002fr-89; Fri, 13 Jan 2012 18:47:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1RlmAL-0002fi-W1
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:47:54 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326480466!3414123!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 8189 invoked from network); 13 Jan 2012 18:47:47 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 18:47:47 -0000
Received: by yenl1 with SMTP id l1so10639875yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 10:47:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=E7ytNe7nP1dA6enoE5PQcB4/tDm0F1RtKtCNhF7nAJE=;
	b=wY+Hq0YFqrLGLXMlKv9VAIzuhRCsBVH+0ihcNeeEPUTIjiG0AHq3vLM0hhqCdqQrTB
	3XPg2iGfDcmSrJWrbTZcfISDm3idpo04WUNMcMNkG50xfOBNHz4iktuDDLBe6lIi4Dhp
	fmjI7VIMZvg7/Z62mfbcgbyTYJh7tvAX/3uHg=
Received: by 10.236.145.195 with SMTP id p43mr3591557yhj.99.1326480466184;
	Fri, 13 Jan 2012 10:47:46 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id 32sm25397534ant.12.2012.01.13.10.47.42
	(version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 10:47:44 -0800 (PST)
Message-ID: <4F107C4D.7090309@cantab.net>
Date: Fri, 13 Jan 2012 18:47:41 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH 2/6] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/01/12 16:59, Wei Liu wrote:
> Enables users to unload netback module.
[...]
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 26af7b7..dd10c0d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1653,5 +1653,19 @@ failed_init:
>  
>  module_init(netback_init);
>  
> +static void __exit netback_exit(void)
> +{
> +	int i;
> +	for (i = 0; i < xen_netbk_group_nr; i++) {
> +		struct xen_netbk *netbk = &xen_netbk[i];
> +		del_timer(&netbk->net_timer);
> +		kthread_stop(netbk->task);
> +	}
> +	vfree(xen_netbk);
> +	page_pool_destroy();
> +	xenvif_xenbus_exit();

I think you need to call xenvif_xenbus_exit() first, before cleaning up
all the other bits and pieces.

> +}
> +module_exit(netback_exit);
> +
>  MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_ALIAS("xen-backend:vif");
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 410018c..65d14f2 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
>  {
>  	return xenbus_register_backend(&netback_driver);
>  }
> +
> +void xenvif_xenbus_exit(void)
> +{
> +	return xenbus_unregister_driver(&netback_driver);
> +}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:48:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18:48:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlmAO-0002fr-89; Fri, 13 Jan 2012 18:47:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1RlmAL-0002fi-W1
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:47:54 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326480466!3414123!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 8189 invoked from network); 13 Jan 2012 18:47:47 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 18:47:47 -0000
Received: by yenl1 with SMTP id l1so10639875yen.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 10:47:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=E7ytNe7nP1dA6enoE5PQcB4/tDm0F1RtKtCNhF7nAJE=;
	b=wY+Hq0YFqrLGLXMlKv9VAIzuhRCsBVH+0ihcNeeEPUTIjiG0AHq3vLM0hhqCdqQrTB
	3XPg2iGfDcmSrJWrbTZcfISDm3idpo04WUNMcMNkG50xfOBNHz4iktuDDLBe6lIi4Dhp
	fmjI7VIMZvg7/Z62mfbcgbyTYJh7tvAX/3uHg=
Received: by 10.236.145.195 with SMTP id p43mr3591557yhj.99.1326480466184;
	Fri, 13 Jan 2012 10:47:46 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id 32sm25397534ant.12.2012.01.13.10.47.42
	(version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 10:47:44 -0800 (PST)
Message-ID: <4F107C4D.7090309@cantab.net>
Date: Fri, 13 Jan 2012 18:47:41 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Wei Liu <wei.liu2@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH 2/6] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 13/01/12 16:59, Wei Liu wrote:
> Enables users to unload netback module.
[...]
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 26af7b7..dd10c0d 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1653,5 +1653,19 @@ failed_init:
>  
>  module_init(netback_init);
>  
> +static void __exit netback_exit(void)
> +{
> +	int i;
> +	for (i = 0; i < xen_netbk_group_nr; i++) {
> +		struct xen_netbk *netbk = &xen_netbk[i];
> +		del_timer(&netbk->net_timer);
> +		kthread_stop(netbk->task);
> +	}
> +	vfree(xen_netbk);
> +	page_pool_destroy();
> +	xenvif_xenbus_exit();

I think you need to call xenvif_xenbus_exit() first, before cleaning up
all the other bits and pieces.

> +}
> +module_exit(netback_exit);
> +
>  MODULE_LICENSE("Dual BSD/GPL");
>  MODULE_ALIAS("xen-backend:vif");
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 410018c..65d14f2 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
>  {
>  	return xenbus_register_backend(&netback_driver);
>  }
> +
> +void xenvif_xenbus_exit(void)
> +{
> +	return xenbus_unregister_driver(&netback_driver);
> +}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:49:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18: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 1RlmBy-0002m5-Ow; Fri, 13 Jan 2012 18:49:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlmBx-0002lw-Tk
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:49:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326480457!59621221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30703 invoked from network); 13 Jan 2012 18:47:37 -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;
	13 Jan 2012 18:47:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10012972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 18:49:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Jan 2012 18:49:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>, "Jan
	Beulich" <JBeulich@suse.com>
In-Reply-To: <osstest-10680-mainreport@xen.org>
References: <osstest-10680-mainreport@xen.org>
Organization: Citrix Systems, Inc.
Date: Fri, 13 Jan 2012 18:49:32 +0000
Message-ID: <1326480572.29084.114.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] [xen-unstable test] 10680: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 18:14 +0000, xen.org wrote:
> flight 10680 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10680/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 10649

gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/osstest/build.10680.build-amd64/xen-unstable/xen/include -I/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -mno-red-zone -mno-sse -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-optimize-sibling-calls -nostdinc -g -D__XEN__ --include /home/osstest/build.10680.build-amd64/xen-unstable/xen/include/xen/config.h -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .asm-offsets.s.d -S -o asm-offsets.s x86_64/asm-offsets.c
In file included from /home/osstest/build.10680.build-amd64/xen-unstable/xen/include/xen/shared.h:6,
                 from /home/osstest/build.10680.build-amd64/xen-unstable/xen/include/xen/sched.h:7,
                 from x86_64/asm-offsets.c:10:
/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/compat/xen.h:8: error: conflicting types for 'trampoline_phys'
/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/asm/config.h:106: note: previous declaration of 'trampoline_phys' was here
cc1: warnings being treated as errors
/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/compat/xen.h:10: error: redundant redeclaration of 'trampoline_start'
/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/asm/config.h:112: note: previous declaration of 'trampoline_start' was here
etc for many more.

Something to do with the automatic inclusion of config.h I guess?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 18:49:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 18: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 1RlmBy-0002m5-Ow; Fri, 13 Jan 2012 18:49:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RlmBx-0002lw-Tk
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:49:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326480457!59621221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30703 invoked from network); 13 Jan 2012 18:47:37 -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;
	13 Jan 2012 18:47:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10012972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 18:49:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 13 Jan 2012 18:49:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>, "Jan
	Beulich" <JBeulich@suse.com>
In-Reply-To: <osstest-10680-mainreport@xen.org>
References: <osstest-10680-mainreport@xen.org>
Organization: Citrix Systems, Inc.
Date: Fri, 13 Jan 2012 18:49:32 +0000
Message-ID: <1326480572.29084.114.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] [xen-unstable test] 10680: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 18:14 +0000, xen.org wrote:
> flight 10680 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10680/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 10649

gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/osstest/build.10680.build-amd64/xen-unstable/xen/include -I/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -mno-red-zone -mno-sse -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -fno-optimize-sibling-calls -nostdinc -g -D__XEN__ --include /home/osstest/build.10680.build-amd64/xen-unstable/xen/include/xen/config.h -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .asm-offsets.s.d -S -o asm-offsets.s x86_64/asm-offsets.c
In file included from /home/osstest/build.10680.build-amd64/xen-unstable/xen/include/xen/shared.h:6,
                 from /home/osstest/build.10680.build-amd64/xen-unstable/xen/include/xen/sched.h:7,
                 from x86_64/asm-offsets.c:10:
/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/compat/xen.h:8: error: conflicting types for 'trampoline_phys'
/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/asm/config.h:106: note: previous declaration of 'trampoline_phys' was here
cc1: warnings being treated as errors
/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/compat/xen.h:10: error: redundant redeclaration of 'trampoline_start'
/home/osstest/build.10680.build-amd64/xen-unstable/xen/include/asm/config.h:112: note: previous declaration of 'trampoline_start' was here
etc for many more.

Something to do with the automatic inclusion of config.h I guess?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 19:21:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19: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 1Rlmg5-0003Uw-0w; Fri, 13 Jan 2012 19:20:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rlmg2-0003Ur-Gi
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:20:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326482431!7076979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17339 invoked from network); 13 Jan 2012 19:20:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 19:20:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:20:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 19:20: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 1Rlmfu-0005n8-Gt;
	Fri, 13 Jan 2012 19:20:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlmfu-0005kD-GK;
	Fri, 13 Jan 2012 19:20:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10679-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 19:20:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10679: 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 10679 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10679/

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. 10541

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10533

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  22ea8496051d
baseline version:
 xen                  14dbd6be46c8

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Michael Young <m.a.young@durham.ac.uk>
  Paolo Bonzini <pbonzini@redhat.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.

------------------------------------------------------------
changeset:   23213:22ea8496051d
tag:         tip
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:09:26 2012 +0000
    
    pygrub: example grub2 configuration file (fedora-16-with-xen.grub2)
    
    Sample grub2 configuration file (some duplication removed) from Fedora 16
    with a xen hypervisor installed
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24003:c681dd5aecf3
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23212:49d73f014077
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:08:27 2012 +0000
    
    pyrgrub: cope with configurations with set default="${saved_entry}" line
    
    Fedora 16 grub2 configuration file can have lines like
        set default="${saved_entry}"
    and a string containing an integer is expected
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24002:979bc34d0ad0
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23211:c404dbf9b3c6
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:08:22 2012 +0000
    
    pygrub: cope with configurations with submenus
    
    The grub2 configuration file in Fedora 16 can have one or more
    menuentrys in a submenu, with configuration of the form
        submenu "Xen 4.1" {
        menuentry ... {
        ...
        }
        }
    (this example occurs when the xen hypervisor is installed on the
    guest)
    
    Ignore the submenu line and the corresponding }
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    xen-unstable changeset: 24001:152049468175
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23210:feb23d232cd9
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:08:17 2012 +0000
    
    pygrub: Allow GPT partition references
    
    The grub2 configuration file in Fedora 16 can have GPT partition
    references like (hd0,gpt2) so remove the "gpt" string where necessary
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    xen-unstable changeset: 24000:65679fee0177
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23209:d581b9a3c726
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:07:58 2012 +0000
    
    pygrub: look in /boot/grub2 (for eg Fedora 16)
    
    Fedora 16 puts grub configuration files in /boot/grub2/grub.cfg so
    pygrub should look there as well
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    xen-unstable changeset: 23999:138f707fa598
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23208:ee80c2ef9400
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:05:02 2012 +0000
    
    pygrub: check all GPT partitions
    
    On Fedora 16 the first GPT partition is a boot partition for grub2 with
    the grub2 configuration in the second partition.
    Check all GPT partitions for grub configuration, not just the first.
    
    [ Also remove now-inaccurate comment. -iwj ]
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Tested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 23998:85d7b207fabc
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23207:95a0e0b47e95
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Tue Jan 10 16:10:00 2012 +0000
    
    pygrub: fix extlinux parsing
    
    pygrub was unable to parse extlinux config files correctly, exactly
    the ones like:
    
    LABEL grsec
      KERNEL vmlinuz-3.0.10-grsec
      APPEND initrd=initramfs-3.0.10-grsec
    root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
    modules=sd-mod,usb-storage,ext4 xen quiet
    
    This patch fixes it, adding a new case when parsing the "append" line,
    that searches for the initrd image.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    xen-unstable changeset: 24460:ff0685e8419b
    Backport-requested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23206:14dbd6be46c8
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>
    
    
========================================
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 Jan 13 19:21:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19: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 1Rlmg5-0003Uw-0w; Fri, 13 Jan 2012 19:20:41 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rlmg2-0003Ur-Gi
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:20:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326482431!7076979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17339 invoked from network); 13 Jan 2012 19:20:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 19:20:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:20:30 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 19:20: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 1Rlmfu-0005n8-Gt;
	Fri, 13 Jan 2012 19:20:30 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlmfu-0005kD-GK;
	Fri, 13 Jan 2012 19:20:30 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10679-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 19:20:30 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10679: 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 10679 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10679/

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. 10541

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     14 guest-localmigrate/x10    fail REGR. vs. 10533

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-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 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
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  22ea8496051d
baseline version:
 xen                  14dbd6be46c8

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Michael Young <m.a.young@durham.ac.uk>
  Paolo Bonzini <pbonzini@redhat.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.

------------------------------------------------------------
changeset:   23213:22ea8496051d
tag:         tip
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:09:26 2012 +0000
    
    pygrub: example grub2 configuration file (fedora-16-with-xen.grub2)
    
    Sample grub2 configuration file (some duplication removed) from Fedora 16
    with a xen hypervisor installed
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24003:c681dd5aecf3
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23212:49d73f014077
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:08:27 2012 +0000
    
    pyrgrub: cope with configurations with set default="${saved_entry}" line
    
    Fedora 16 grub2 configuration file can have lines like
        set default="${saved_entry}"
    and a string containing an integer is expected
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 24002:979bc34d0ad0
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23211:c404dbf9b3c6
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:08:22 2012 +0000
    
    pygrub: cope with configurations with submenus
    
    The grub2 configuration file in Fedora 16 can have one or more
    menuentrys in a submenu, with configuration of the form
        submenu "Xen 4.1" {
        menuentry ... {
        ...
        }
        }
    (this example occurs when the xen hypervisor is installed on the
    guest)
    
    Ignore the submenu line and the corresponding }
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    xen-unstable changeset: 24001:152049468175
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23210:feb23d232cd9
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:08:17 2012 +0000
    
    pygrub: Allow GPT partition references
    
    The grub2 configuration file in Fedora 16 can have GPT partition
    references like (hd0,gpt2) so remove the "gpt" string where necessary
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    xen-unstable changeset: 24000:65679fee0177
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23209:d581b9a3c726
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:07:58 2012 +0000
    
    pygrub: look in /boot/grub2 (for eg Fedora 16)
    
    Fedora 16 puts grub configuration files in /boot/grub2/grub.cfg so
    pygrub should look there as well
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    xen-unstable changeset: 23999:138f707fa598
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23208:ee80c2ef9400
user:        Michael Young <m.a.young@durham.ac.uk>
date:        Tue Jan 10 17:05:02 2012 +0000
    
    pygrub: check all GPT partitions
    
    On Fedora 16 the first GPT partition is a boot partition for grub2 with
    the grub2 configuration in the second partition.
    Check all GPT partitions for grub configuration, not just the first.
    
    [ Also remove now-inaccurate comment. -iwj ]
    
    Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
    Tested-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    xen-unstable changeset: 23998:85d7b207fabc
    Backport-requested-by: Pasi Karkkainen <pasik@iki.fi>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23207:95a0e0b47e95
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Tue Jan 10 16:10:00 2012 +0000
    
    pygrub: fix extlinux parsing
    
    pygrub was unable to parse extlinux config files correctly, exactly
    the ones like:
    
    LABEL grsec
      KERNEL vmlinuz-3.0.10-grsec
      APPEND initrd=initramfs-3.0.10-grsec
    root=UUID=cfd4a7b4-8c40-4025-b877-8205f1c622ee
    modules=sd-mod,usb-storage,ext4 xen quiet
    
    This patch fixes it, adding a new case when parsing the "append" line,
    that searches for the initrd image.
    
    Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Acked-by: Ian Campbell <ian.campbell.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    xen-unstable changeset: 24460:ff0685e8419b
    Backport-requested-by: Roger Pau Monne <roger.pau@entel.upc.edu>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   23206:14dbd6be46c8
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>
    
    
========================================
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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlmlC-0003ks-DZ; Fri, 13 Jan 2012 19:25:58 +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 1RlmlB-0003iZ-Eu
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8559 invoked from network); 13 Jan 2012 19:25:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 19:25:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlml4-0005pU-Kw; Fri, 13 Jan 2012 19:25:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml4-0002oU-KC;
	Fri, 13 Jan 2012 19:25:50 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:26 +0000
Message-ID: <1326482728-10733-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-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 7/9] libxl: New convenience macro CONTAINER_OF
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a convenient and type-safe wrapper which does the correct
dance to subtract offsetof.  This is very similar to the
"container_of" macro in the Linux kernel, but it has an additional
feature that instead of the type argument you may also pass an
expression of that type; this makes initialising a variable with
CONTAINER_OF easier.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 594b9fb..213b5f9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1238,6 +1238,35 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
  * Convenience macros.
  */
 
+/*
+ * CONTAINER_OF work like this.  Given:
+ *    typedef struct {
+ *      ...
+ *      member_type member_name;
+ *      ...
+ *    } outer_type;
+ *    outer_type outer, *outer_var;
+ *    member_type *inner_ptr = &outer->member_name;
+ *
+ * Then, effectively:
+ *    outer_type *CONTAINER_OF(member_type *inner_ptr,
+ *                             *outer_var, // or type name for outer_type
+ *                             member_name);
+ *
+ * So that:
+ *    CONTAINER_OF(inner_ptr, *outer_var, member_name) == &outer
+ *    CONTAINER_OF(inner_ptr, outer_type, member_name) == &outer
+ */
+#define CONTAINER_OF(inner_ptr, outer, member_name)                     \
+    ({                                                                  \
+        typeof(outer) *container_of_;                                   \
+        container_of_ = (void*)((char*)(inner_ptr) -                    \
+                                offsetof(typeof(outer), member_name));  \
+        (void)(&container_of_->member_name ==                           \
+               (typeof(inner_ptr))0) /* type check */;                  \
+        container_of_;                                                  \
+    })
+
 
 /*
  * All of these assume (or define)
-- 
1.7.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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlmlC-0003ks-DZ; Fri, 13 Jan 2012 19:25:58 +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 1RlmlB-0003iZ-Eu
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8559 invoked from network); 13 Jan 2012 19:25:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 19:25:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013583"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlml4-0005pU-Kw; Fri, 13 Jan 2012 19:25:50 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml4-0002oU-KC;
	Fri, 13 Jan 2012 19:25:50 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:26 +0000
Message-ID: <1326482728-10733-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-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 7/9] libxl: New convenience macro CONTAINER_OF
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a convenient and type-safe wrapper which does the correct
dance to subtract offsetof.  This is very similar to the
"container_of" macro in the Linux kernel, but it has an additional
feature that instead of the type argument you may also pass an
expression of that type; this makes initialising a variable with
CONTAINER_OF easier.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 594b9fb..213b5f9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1238,6 +1238,35 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
  * Convenience macros.
  */
 
+/*
+ * CONTAINER_OF work like this.  Given:
+ *    typedef struct {
+ *      ...
+ *      member_type member_name;
+ *      ...
+ *    } outer_type;
+ *    outer_type outer, *outer_var;
+ *    member_type *inner_ptr = &outer->member_name;
+ *
+ * Then, effectively:
+ *    outer_type *CONTAINER_OF(member_type *inner_ptr,
+ *                             *outer_var, // or type name for outer_type
+ *                             member_name);
+ *
+ * So that:
+ *    CONTAINER_OF(inner_ptr, *outer_var, member_name) == &outer
+ *    CONTAINER_OF(inner_ptr, outer_type, member_name) == &outer
+ */
+#define CONTAINER_OF(inner_ptr, outer, member_name)                     \
+    ({                                                                  \
+        typeof(outer) *container_of_;                                   \
+        container_of_ = (void*)((char*)(inner_ptr) -                    \
+                                offsetof(typeof(outer), member_name));  \
+        (void)(&container_of_->member_name ==                           \
+               (typeof(inner_ptr))0) /* type check */;                  \
+        container_of_;                                                  \
+    })
+
 
 /*
  * All of these assume (or define)
-- 
1.7.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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlmky-0003gO-Tw; Fri, 13 Jan 2012 19:25: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 1Rlmky-0003fc-8x
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8079 invoked from network); 13 Jan 2012 19:25:37 -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 Jan 2012 19:25:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlmkr-0005pC-FT; Fri, 13 Jan 2012 19:25:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmkr-0002o4-Ek;
	Fri, 13 Jan 2012 19:25:37 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Jan 2012 19:25:21 +0000
Message-ID: <1326482728-10733-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/9] ocaml, libxl: support "private" fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The changeset
  24378:b4365e2c2595  libxl: idl: support new "private" type attribute
is not complete.  Actually using this feature does not work because
the ocaml idl generator does not know about it.

So add that support.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/ocaml/libs/xl/genwrap.py |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 5f8639a..61abecf 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -91,6 +91,8 @@ def gen_ocaml_ml(ty, interface, indent=""):
             s += "\t{\n"
             
         for f in ty.fields:
+            if f.type.private:
+                continue
             x = ocaml_instance_of(f.type, f.name)
             x = x.replace("\n", "\n\t\t")
             s += "\t\t" + x + ";\n"
@@ -146,6 +148,8 @@ def c_val(ty, c, o, indent="", parent = None):
     elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
+            if f.type.private:
+                continue
             s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
             n = n + 1
     else:
@@ -210,6 +214,8 @@ def ocaml_Val(ty, o, c, indent="", parent = None):
         
         n = 0
         for f in ty.fields:
+            if f.type.private:
+                continue
             s += "\n"
             s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
             s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
@@ -288,6 +294,8 @@ if __name__ == '__main__':
     cinc.write(autogen_header("/*", "*/"))
 
     for ty in types:
+        if ty.private:
+            continue
         #sys.stdout.write(" TYPE    %-20s " % ty.rawname)
         ml.write(gen_ocaml_ml(ty, False))
         ml.write("\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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlmky-0003gO-Tw; Fri, 13 Jan 2012 19:25: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 1Rlmky-0003fc-8x
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8079 invoked from network); 13 Jan 2012 19:25:37 -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 Jan 2012 19:25:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013575"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlmkr-0005pC-FT; Fri, 13 Jan 2012 19:25:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmkr-0002o4-Ek;
	Fri, 13 Jan 2012 19:25:37 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Jan 2012 19:25:21 +0000
Message-ID: <1326482728-10733-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/9] ocaml, libxl: support "private" fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The changeset
  24378:b4365e2c2595  libxl: idl: support new "private" type attribute
is not complete.  Actually using this feature does not work because
the ocaml idl generator does not know about it.

So add that support.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/ocaml/libs/xl/genwrap.py |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 5f8639a..61abecf 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -91,6 +91,8 @@ def gen_ocaml_ml(ty, interface, indent=""):
             s += "\t{\n"
             
         for f in ty.fields:
+            if f.type.private:
+                continue
             x = ocaml_instance_of(f.type, f.name)
             x = x.replace("\n", "\n\t\t")
             s += "\t\t" + x + ";\n"
@@ -146,6 +148,8 @@ def c_val(ty, c, o, indent="", parent = None):
     elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
+            if f.type.private:
+                continue
             s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
             n = n + 1
     else:
@@ -210,6 +214,8 @@ def ocaml_Val(ty, o, c, indent="", parent = None):
         
         n = 0
         for f in ty.fields:
+            if f.type.private:
+                continue
             s += "\n"
             s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
             s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
@@ -288,6 +294,8 @@ if __name__ == '__main__':
     cinc.write(autogen_header("/*", "*/"))
 
     for ty in types:
+        if ty.private:
+            continue
         #sys.stdout.write(" TYPE    %-20s " % ty.rawname)
         ml.write(gen_ocaml_ml(ty, False))
         ml.write("\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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlml4-0003hk-Bc; Fri, 13 Jan 2012 19:25: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 1Rlml2-0003ft-Om
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8391 invoked from network); 13 Jan 2012 19:25:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 19:25:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013576"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlmkv-0005pF-N5; Fri, 13 Jan 2012 19:25:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmkv-0002oB-It;
	Fri, 13 Jan 2012 19:25:41 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:22 +0000
Message-ID: <1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/9] 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.

The new "libxl_event" structure is blacklisted in the ocaml bindings
for two reasons:
  - It has a field name "type" (which is a keyword in ocaml);
    the ocaml idl generator should massage this field name on
    output, to "type_" perhaps.
  - The ocaml idl generator does not support KeyedUnion.

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      |  236 ++++++++++++++++++++++++++---
 tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
 tools/libxl/libxl_internal.h   |   77 +++++++++-
 tools/libxl/libxl_types.idl    |   34 ++++-
 tools/libxl/xl_cmdimpl.c       |  270 +++++++++++++++++++--------------
 tools/ocaml/libs/xl/genwrap.py |    1 +
 8 files changed, 908 insertions(+), 277 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 413b684..19ff12c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,8 +45,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_rindex = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -55,6 +58,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);
@@ -86,6 +92,20 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return rc;
 }
 
+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;
@@ -95,6 +115,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);
@@ -108,9 +135,12 @@ 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_rindex);
     free(ctx->watch_slots);
 
+    discard_events(&ctx->occurred);
+
     GC_FREE;
     free(ctx);
     return 0;
@@ -646,117 +676,176 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
     return ret;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    EGC_GC;
+    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(egc, "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(egc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(egc, 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(egc, 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(egc, 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;
-}
+    *evgen_out = evg;
+    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__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    EGC_GC;
+    libxl_evgen_disk_eject *evg = (void*)w;
     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(egc, "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(egc, 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")) {
@@ -765,19 +854,83 @@ 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(egc, 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;
+
+    *evgen_out = evg;
+    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)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b067724..4d3391f 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"
@@ -300,51 +308,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 ec66340..621a7cc 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -510,9 +510,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_internal(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -524,9 +524,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_rindex
@@ -593,8 +590,18 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
     }
 
  out:
+    return rc;
+}
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
-    GC_FREE;
+    EGC_FREE;
     return rc;
 }
 
@@ -623,11 +630,11 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now)
+static void afterpoll_internal(libxl__egc *egc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now)
 {
-    EGC_INIT(ctx);
-    CTX_LOCK;
+    EGC_GC;
     libxl__ev_fd *efd;
 
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
@@ -653,12 +660,18 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(egc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_internal(egc, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -723,11 +736,10 @@ void libxl__event_disaster(libxl__egc *egc, 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";
@@ -736,9 +748,197 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
     exit(-1);
 }
 
+static void egc_run_callbacks(libxl__egc *egc)
+{
+    EGC_GC;
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
+}
+
 void libxl__egc_cleanup(libxl__egc *egc)
 {
-    libxl__free_all(&egc->gc);
+    EGC_GC;
+    libxl__free_all(gc);
+
+    egc_run_callbacks(egc);
+}
+
+/*
+ * 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__egc *egc, libxl_event *event)
+{
+    EGC_GC;
+
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__egc_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(&egc->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__egc *egc,
+                              libxl_event_type type, uint32_t domid)
+{
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_internal(libxl__egc *egc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user)
+{
+    EGC_GC;
+    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)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+static int eventloop_iteration(libxl__egc *egc) {
+    EGC_GC;
+    int rc;
+    struct timeval now;
+    
+    CTX_LOCK;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) goto out;
+
+    int timeout;
+
+    for (;;) {
+        int nfds = CTX->fd_polls_allocd;
+        timeout = -1;
+        rc = beforepoll_internal(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)
+            return 0; /* will go round again if caller requires */
+
+        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_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+    CTX_UNLOCK;
+
+    rc = 0;
+ out:
+    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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = eventloop_iteration(egc);
+        if (rc) goto out;
+
+        /* we unlock and cleanup the egc 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__egc_cleanup(egc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
 }
 
 /*
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 63ef65e..0e83800 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,181 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ *
+ * (Callers inside libxl may not call libxl_event_check or _wait.)
+ */
+
+#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.  The event_occurs and disaster callbacks may occur on
+   * any thread in which the application calls libxl.
+   *
+   * 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 +211,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.h b/tools/libxl/libxl_internal.h
index 8c9f7c9..edb73eb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -175,11 +175,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 libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -193,12 +227,16 @@ 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_rindex_allocd;
     int *fd_rindex; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -210,6 +248,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 */
@@ -250,6 +295,7 @@ struct libxl__gc {
 struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
+    struct libxl__event_list occurred_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -394,6 +440,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.
  */
 
 
@@ -437,6 +486,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__egc*, 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__egc*, 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(egc, type, domid)                              \
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
+/*
  * In general, call this via the macro LIBXL__EVENT_DISASTER.
  *
  * Event-generating functions may call this if they might have wanted
@@ -993,12 +1061,15 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 /* egc initialisation and destruction: */
 
-#define LIBXL_INIT_EGC(egc,ctx) do{             \
-        LIBXL_INIT_GC((egc).gc,ctx);            \
-        /* list of occurred events tbd */       \
+#define LIBXL_INIT_EGC(egc,ctx) do{                     \
+        LIBXL_INIT_GC((egc).gc,ctx);                    \
+        LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
+  /* Frees memory allocated within this egc's gc, and and report all
+   * occurred events via callback, if applicable.  May reenter the
+   * application; see restrictions above. */
 
 /* convenience macros: */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 574dec7..a6dac79 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"),
@@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = UInt(64)
+
+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 8c30de1..e292bfc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1225,14 +1225,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;
@@ -1249,11 +1251,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;
@@ -1318,7 +1323,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;
@@ -1431,6 +1436,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;
@@ -1444,10 +1470,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;
@@ -1658,14 +1685,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;
@@ -1702,92 +1729,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:
@@ -2270,6 +2311,7 @@ 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);
@@ -2284,37 +2326,39 @@ static void shutdown_domain(const char *p, int wait)
     }
 
     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);
     }
 }
 
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 61abecf..5a02e8f 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -273,6 +273,7 @@ if __name__ == '__main__':
         "device_model_info",
         "vcpuinfo",
         "topologyinfo",
+        "event",
         ]
 
     for t in blacklist:
-- 
1.7.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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlmku-0003fh-Uj; Fri, 13 Jan 2012 19:25: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 1Rlmkt-0003fW-R5
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8043 invoked from network); 13 Jan 2012 19:25: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;
	13 Jan 2012 19:25:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlmkm-0005p0-2Z; Fri, 13 Jan 2012 19:25:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmkl-0002no-VA;
	Fri, 13 Jan 2012 19:25:32 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:19 +0000
Message-ID: <1326482728-10733-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 v7 0/9] libxl: 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 series has now been tested.  It includes bugfixes and all the
comments which people have made and which I said I would address.

These should be fairly uncontroversial:
 2/9  ocaml, libxl: support "private" fields
 4/9  libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
 7/9  libxl: New convenience macro CONTAINER_OF

These are the meat:
 1/9  libxl: New API for providing OS events to libxl
 3/9  libxl: New event generation API
 5/9  libxl: Permit multithreaded event waiting
 6/9  libxl: Asynchronous/long-running operation infrastructure
 8/9  libxl: Introduce libxl__ev_devstate
 9/9  libxl: Convert to asynchronous: device removal


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlml7-0003ik-14; Fri, 13 Jan 2012 19:25: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 1Rlml4-0003ga-RR
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8422 invoked from network); 13 Jan 2012 19:25:44 -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 Jan 2012 19:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19: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; Fri, 13 Jan 2012 19: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
	1Rlmky-0005pI-2L; Fri, 13 Jan 2012 19:25:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmky-0002oF-02;
	Fri, 13 Jan 2012 19:25:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Jan 2012 19:25:23 +0000
Message-ID: <1326482728-10733-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/9] libxl: introduce libxl_fd_set_nonblock,
	rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 want a function for setting fds to nonblocking, so introduce one.

This is a very similar requirement to that for libxl_fd_set_cloexec,
so make it common with that.

While we're at it, fix a few deficiences that make this latter
function less desirable than it could be:
 * Change the return from 0/-1 (like a syscall) to a libxl error code
 * Take a boolean parameter for turning the flag on and off
 * Log on error (and so, take a ctx for this purpose)

Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
such errors are highly unlikely.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c      |   33 ++++++++++++++++++++++++++-------
 tools/libxl/libxl.h      |    7 ++++++-
 tools/libxl/libxl_qmp.c  |    3 ++-
 tools/libxl/xl_cmdimpl.c |    3 ++-
 4 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 19ff12c..c68c165 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3655,19 +3655,38 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
-int libxl_fd_set_cloexec(int fd)
+static int fd_set_flags(libxl_ctx *ctx, int fd,
+                        int fcntlgetop, int fcntlsetop, const char *fl,
+                        int flagmask, int set_p)
 {
-    int flags = 0;
+    int flags, r;
 
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
+    flags = fcntl(fd, fcntlgetop);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_GET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
+
+    if (set_p)
+        flags |= flagmask;
+    else
+        flags &= ~flagmask;
+
+    r = fcntl(fd, fcntlsetop, flags);
+    if (r == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_SET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+
+    return 0;
 }
 
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
+  { return fd_set_flags(ctx,fd, F_GETFD,F_SETFD,"FD", FD_CLOEXEC, cloexec); }
+
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
+  { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 4d3391f..e32881b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -613,7 +613,12 @@ const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
 /* misc */
-int libxl_fd_set_cloexec(int fd);
+
+/* Each of these sets or clears the flag according to whether the
+ * 2nd parameter is nonzero.  On failure, they log, and
+ * return ERROR_FAIL, but also leave errno valid. */
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
 
 #include <libxl_event.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 61d9769..1ee82ae 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -324,7 +324,8 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl_fd_set_cloexec(qmp->qmp_fd);
+    ret = libxl_fd_set_cloexec(qmp->ctx, qmp->qmp_fd, 1);
+    if (ret) return -1;
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index e292bfc..c2b7a1e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1495,7 +1495,8 @@ static int create_domain(struct domain_create *dom_info)
             restore_fd = migrate_fd;
         } else {
             restore_fd = open(restore_file, O_RDONLY);
-            libxl_fd_set_cloexec(restore_fd);
+            rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
+            if (rc) return rc;
         }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
-- 
1.7.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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlml4-0003hk-Bc; Fri, 13 Jan 2012 19:25: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 1Rlml2-0003ft-Om
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8391 invoked from network); 13 Jan 2012 19:25:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 19:25:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013576"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlmkv-0005pF-N5; Fri, 13 Jan 2012 19:25:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmkv-0002oB-It;
	Fri, 13 Jan 2012 19:25:41 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:22 +0000
Message-ID: <1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/9] 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.

The new "libxl_event" structure is blacklisted in the ocaml bindings
for two reasons:
  - It has a field name "type" (which is a keyword in ocaml);
    the ocaml idl generator should massage this field name on
    output, to "type_" perhaps.
  - The ocaml idl generator does not support KeyedUnion.

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      |  236 ++++++++++++++++++++++++++---
 tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
 tools/libxl/libxl_internal.h   |   77 +++++++++-
 tools/libxl/libxl_types.idl    |   34 ++++-
 tools/libxl/xl_cmdimpl.c       |  270 +++++++++++++++++++--------------
 tools/ocaml/libs/xl/genwrap.py |    1 +
 8 files changed, 908 insertions(+), 277 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 413b684..19ff12c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,8 +45,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_rindex = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -55,6 +58,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);
@@ -86,6 +92,20 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return rc;
 }
 
+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;
@@ -95,6 +115,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);
@@ -108,9 +135,12 @@ 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_rindex);
     free(ctx->watch_slots);
 
+    discard_events(&ctx->occurred);
+
     GC_FREE;
     free(ctx);
     return 0;
@@ -646,117 +676,176 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
     return ret;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    EGC_GC;
+    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(egc, "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(egc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(egc, 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(egc, 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(egc, 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;
-}
+    *evgen_out = evg;
+    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__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    EGC_GC;
+    libxl_evgen_disk_eject *evg = (void*)w;
     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(egc, "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(egc, 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")) {
@@ -765,19 +854,83 @@ 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(egc, 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;
+
+    *evgen_out = evg;
+    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)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b067724..4d3391f 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"
@@ -300,51 +308,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 ec66340..621a7cc 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -510,9 +510,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_internal(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -524,9 +524,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_rindex
@@ -593,8 +590,18 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
     }
 
  out:
+    return rc;
+}
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
-    GC_FREE;
+    EGC_FREE;
     return rc;
 }
 
@@ -623,11 +630,11 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now)
+static void afterpoll_internal(libxl__egc *egc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now)
 {
-    EGC_INIT(ctx);
-    CTX_LOCK;
+    EGC_GC;
     libxl__ev_fd *efd;
 
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
@@ -653,12 +660,18 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(egc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_internal(egc, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -723,11 +736,10 @@ void libxl__event_disaster(libxl__egc *egc, 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";
@@ -736,9 +748,197 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
     exit(-1);
 }
 
+static void egc_run_callbacks(libxl__egc *egc)
+{
+    EGC_GC;
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
+}
+
 void libxl__egc_cleanup(libxl__egc *egc)
 {
-    libxl__free_all(&egc->gc);
+    EGC_GC;
+    libxl__free_all(gc);
+
+    egc_run_callbacks(egc);
+}
+
+/*
+ * 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__egc *egc, libxl_event *event)
+{
+    EGC_GC;
+
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__egc_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(&egc->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__egc *egc,
+                              libxl_event_type type, uint32_t domid)
+{
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_internal(libxl__egc *egc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user)
+{
+    EGC_GC;
+    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)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+static int eventloop_iteration(libxl__egc *egc) {
+    EGC_GC;
+    int rc;
+    struct timeval now;
+    
+    CTX_LOCK;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) goto out;
+
+    int timeout;
+
+    for (;;) {
+        int nfds = CTX->fd_polls_allocd;
+        timeout = -1;
+        rc = beforepoll_internal(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)
+            return 0; /* will go round again if caller requires */
+
+        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_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+    CTX_UNLOCK;
+
+    rc = 0;
+ out:
+    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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = eventloop_iteration(egc);
+        if (rc) goto out;
+
+        /* we unlock and cleanup the egc 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__egc_cleanup(egc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
 }
 
 /*
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 63ef65e..0e83800 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,181 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ *
+ * (Callers inside libxl may not call libxl_event_check or _wait.)
+ */
+
+#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.  The event_occurs and disaster callbacks may occur on
+   * any thread in which the application calls libxl.
+   *
+   * 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 +211,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.h b/tools/libxl/libxl_internal.h
index 8c9f7c9..edb73eb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -175,11 +175,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 libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -193,12 +227,16 @@ 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_rindex_allocd;
     int *fd_rindex; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -210,6 +248,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 */
@@ -250,6 +295,7 @@ struct libxl__gc {
 struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
+    struct libxl__event_list occurred_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -394,6 +440,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.
  */
 
 
@@ -437,6 +486,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__egc*, 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__egc*, 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(egc, type, domid)                              \
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
+/*
  * In general, call this via the macro LIBXL__EVENT_DISASTER.
  *
  * Event-generating functions may call this if they might have wanted
@@ -993,12 +1061,15 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 /* egc initialisation and destruction: */
 
-#define LIBXL_INIT_EGC(egc,ctx) do{             \
-        LIBXL_INIT_GC((egc).gc,ctx);            \
-        /* list of occurred events tbd */       \
+#define LIBXL_INIT_EGC(egc,ctx) do{                     \
+        LIBXL_INIT_GC((egc).gc,ctx);                    \
+        LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
+  /* Frees memory allocated within this egc's gc, and and report all
+   * occurred events via callback, if applicable.  May reenter the
+   * application; see restrictions above. */
 
 /* convenience macros: */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 574dec7..a6dac79 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"),
@@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = UInt(64)
+
+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 8c30de1..e292bfc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1225,14 +1225,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;
@@ -1249,11 +1251,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;
@@ -1318,7 +1323,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;
@@ -1431,6 +1436,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;
@@ -1444,10 +1470,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;
@@ -1658,14 +1685,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;
@@ -1702,92 +1729,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:
@@ -2270,6 +2311,7 @@ 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);
@@ -2284,37 +2326,39 @@ static void shutdown_domain(const char *p, int wait)
     }
 
     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);
     }
 }
 
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 61abecf..5a02e8f 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -273,6 +273,7 @@ if __name__ == '__main__':
         "device_model_info",
         "vcpuinfo",
         "topologyinfo",
+        "event",
         ]
 
     for t in blacklist:
-- 
1.7.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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlml7-0003ik-14; Fri, 13 Jan 2012 19:25: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 1Rlml4-0003ga-RR
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8422 invoked from network); 13 Jan 2012 19:25:44 -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 Jan 2012 19:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19: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; Fri, 13 Jan 2012 19: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
	1Rlmky-0005pI-2L; Fri, 13 Jan 2012 19:25:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmky-0002oF-02;
	Fri, 13 Jan 2012 19:25:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Jan 2012 19:25:23 +0000
Message-ID: <1326482728-10733-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 4/9] libxl: introduce libxl_fd_set_nonblock,
	rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 want a function for setting fds to nonblocking, so introduce one.

This is a very similar requirement to that for libxl_fd_set_cloexec,
so make it common with that.

While we're at it, fix a few deficiences that make this latter
function less desirable than it could be:
 * Change the return from 0/-1 (like a syscall) to a libxl error code
 * Take a boolean parameter for turning the flag on and off
 * Log on error (and so, take a ctx for this purpose)

Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
such errors are highly unlikely.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c      |   33 ++++++++++++++++++++++++++-------
 tools/libxl/libxl.h      |    7 ++++++-
 tools/libxl/libxl_qmp.c  |    3 ++-
 tools/libxl/xl_cmdimpl.c |    3 ++-
 4 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 19ff12c..c68c165 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3655,19 +3655,38 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
-int libxl_fd_set_cloexec(int fd)
+static int fd_set_flags(libxl_ctx *ctx, int fd,
+                        int fcntlgetop, int fcntlsetop, const char *fl,
+                        int flagmask, int set_p)
 {
-    int flags = 0;
+    int flags, r;
 
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
+    flags = fcntl(fd, fcntlgetop);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_GET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
+
+    if (set_p)
+        flags |= flagmask;
+    else
+        flags &= ~flagmask;
+
+    r = fcntl(fd, fcntlsetop, flags);
+    if (r == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_SET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+
+    return 0;
 }
 
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
+  { return fd_set_flags(ctx,fd, F_GETFD,F_SETFD,"FD", FD_CLOEXEC, cloexec); }
+
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
+  { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 4d3391f..e32881b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -613,7 +613,12 @@ const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
 /* misc */
-int libxl_fd_set_cloexec(int fd);
+
+/* Each of these sets or clears the flag according to whether the
+ * 2nd parameter is nonzero.  On failure, they log, and
+ * return ERROR_FAIL, but also leave errno valid. */
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
 
 #include <libxl_event.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 61d9769..1ee82ae 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -324,7 +324,8 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl_fd_set_cloexec(qmp->qmp_fd);
+    ret = libxl_fd_set_cloexec(qmp->ctx, qmp->qmp_fd, 1);
+    if (ret) return -1;
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index e292bfc..c2b7a1e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1495,7 +1495,8 @@ static int create_domain(struct domain_create *dom_info)
             restore_fd = migrate_fd;
         } else {
             restore_fd = open(restore_file, O_RDONLY);
-            libxl_fd_set_cloexec(restore_fd);
+            rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
+            if (rc) return rc;
         }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
-- 
1.7.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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlmku-0003fh-Uj; Fri, 13 Jan 2012 19:25: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 1Rlmkt-0003fW-R5
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8043 invoked from network); 13 Jan 2012 19:25: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;
	13 Jan 2012 19:25:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013571"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlmkm-0005p0-2Z; Fri, 13 Jan 2012 19:25:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmkl-0002no-VA;
	Fri, 13 Jan 2012 19:25:32 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:19 +0000
Message-ID: <1326482728-10733-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 v7 0/9] libxl: 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 series has now been tested.  It includes bugfixes and all the
comments which people have made and which I said I would address.

These should be fairly uncontroversial:
 2/9  ocaml, libxl: support "private" fields
 4/9  libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
 7/9  libxl: New convenience macro CONTAINER_OF

These are the meat:
 1/9  libxl: New API for providing OS events to libxl
 3/9  libxl: New event generation API
 5/9  libxl: Permit multithreaded event waiting
 6/9  libxl: Asynchronous/long-running operation infrastructure
 8/9  libxl: Introduce libxl__ev_devstate
 9/9  libxl: Convert to asynchronous: device removal


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlmky-0003g2-BA; Fri, 13 Jan 2012 19:25: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 1Rlmkw-0003fY-5A
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8062 invoked from network); 13 Jan 2012 19:25:35 -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 Jan 2012 19:25:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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; Fri, 13 Jan 2012 19:25: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
	1Rlmkp-0005p4-4Z; Fri, 13 Jan 2012 19:25:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmkp-0002ny-0g;
	Fri, 13 Jan 2012 19:25:35 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Jan 2012 19:25:20 +0000
Message-ID: <1326482728-10733-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/9] 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    |  750 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  205 ++++++++++++
 tools/libxl/libxl_internal.h |  277 +++++++++++++++-
 6 files changed, 1267 insertions(+), 3 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 3c3661b..b58c43e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -49,7 +49,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 169fc97..413b684 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,6 +45,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_rindex = 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);
@@ -79,9 +89,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_rindex);
+    free(ctx->watch_slots);
+
+    GC_FREE;
     free(ctx);
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 723eac2..b067724 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"
@@ -223,6 +224,9 @@ enum {
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
     ERROR_NOPARAVIRT = -10,
+    ERROR_NOT_READY = -11,
+    ERROR_OSEVENT_REG_FAIL = -12,
+    ERROR_BUFFERFULL = -13,
 };
 
 #define LIBXL_VERSION 0
@@ -648,6 +652,8 @@ const char *libxl_xenpaging_dir_path(void);
 /* misc */
 int libxl_fd_set_cloexec(int fd);
 
+#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..ec66340
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,750 @@
+/*
+ * 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->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;
+
+ 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__egc *egc, libxl__ev_fd *ev,
+                             int fd, short events, short revents)
+{
+    EGC_GC;
+
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "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(egc, 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);
+        w->slotnum = -1;
+    }
+
+    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 rc;
+
+    /*
+     * 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_rindex
+         * 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_rindex.
+         */
+
+        int maxfd = 0;
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+            if (!efd->events)
+                continue;
+            if (efd->fd >= maxfd)
+                maxfd = efd->fd + 1;
+        }
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_rindex_allocd < maxfd) {
+            assert(maxfd < INT_MAX / sizeof(int) / 2);
+            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+            memset(newarray + CTX->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
+            CTX->fd_rindex = newarray;
+            CTX->fd_rindex_allocd = maxfd;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            assert(efd->fd < CTX->fd_rindex_allocd);
+            CTX->fd_rindex[efd->fd] = used;
+        }
+        used++;
+    }
+    rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    *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;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static int afterpoll_check_fd(libxl_ctx *ctx,
+                              const struct pollfd *fds, int nfds,
+                              int fd, int events)
+    /* returns mask of events which were requested and occurred */
+{
+    if (fd >= ctx->fd_rindex_allocd)
+        /* added after we went into poll, have to try again */
+        return 0;
+
+    int slot = ctx->fd_rindex[fd];
+
+    if (slot >= nfds)
+        /* stale slot entry; again, added afterwards */
+        return 0;
+
+    if (fds[slot].fd != fd)
+        /* again, stale slot entry */
+        return 0;
+
+    int revents = fds[slot].revents & events;
+    /* we mask in case requested events have changed */
+
+    return revents;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    libxl__ev_fd *efd;
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+
+        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        if (revents)
+            efd->func(egc, 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(egc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    EGC_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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(egc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+{
+    libxl__ev_time *ev = for_libxl;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(egc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func)
+{
+    EGC_GC;
+
+    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);
+}
+
+void libxl__egc_cleanup(libxl__egc *egc)
+{
+    libxl__free_all(&egc->gc);
+}
+
+/*
+ * 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..63ef65e
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,205 @@
+/*
+ * 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.
+ *
+ * (Callers inside libxl may not call libxl_osevent_... functions.)
+ */
+
+struct pollfd;
+
+/* 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);
+
+/* nfds and fds[0..nfds] must be from the most recent call to
+ * _beforepoll, as modified by poll.  (It is therefore not possible
+ * to have multiple threads simultaneously polling using this
+ * interface.)
+ *
+ * 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.
+ */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+
+
+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;
+
+/* 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.
+ */
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+
+/* 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);
+
+/* 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.
+ */
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+
+#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 39e9e05..8c9f7c9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -35,6 +35,7 @@
 #include <unistd.h>
 
 #include <sys/mman.h>
+#include <sys/poll.h>
 #include <sys/select.h>
 #include <sys/stat.h>
 #include <sys/time.h>
@@ -109,6 +110,71 @@ _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__egc libxl__egc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    int fd;
+    short events;
+    libxl__ev_fd_callback *func;
+    /* remainder is private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    void *for_app_reg;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__egc *egc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    libxl__ev_time_callback *func;
+    /* remainder is 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;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+    /* remainder is private for libxl__ev_xswatch... */
+    int slotnum; /* registered iff slotnum >= 0 */
+    uint32_t counterval;
+};
+
+/*
+ * 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;
@@ -127,6 +193,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_rindex_allocd;
+    int *fd_rindex; /* 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 */
@@ -157,12 +240,17 @@ 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;
+};
+
+struct libxl__egc {
+    /* for event-generating functions only */
+    struct libxl__gc gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -234,6 +322,140 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _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.
+ *      FUNC will be called with the context locked (with CTX_LOCK).
+ *
+ *  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.
+ * The ctx will be locked on entry to each FUNC and FUNC should not
+ * unlock it.
+ *
+ * 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; }
+
+
+/*
+ * 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).
+ */
+_hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line,
+                                   const char *func);
+#define LIBXL__EVENT_DISASTER(egc, msg, errnoval, type) \
+    libxl__event_disaster(egc, 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);
@@ -600,6 +822,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)
 
@@ -737,6 +961,55 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 
 /*
+ * Calling context and GC for event-generating functions:
+ *
+ * These are for use by parts of libxl which directly or indirectly
+ * call libxl__event_occurred.  These contain a gc but also a list of
+ * deferred events.
+ *
+ * You should never need to initialise an egc unless you are part of
+ * the event machinery itself.  Otherwise you will always be given an
+ * egc if you need one.  Even functions which generate specific kinds
+ * of events don't need to - rather, they will be passed an egc into
+ * their own callback function and should just use the one they're
+ * given.
+ *
+ * Functions using LIBXL__INIT_EGC may *not* generally be called from
+ * within libxl, because libxl__egc_cleanup may call back into the
+ * application.  This should be documented near the function
+ * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
+ * should in any case not find it necessary to call egc-creators from
+ * within libxl.
+ *
+ * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
+ * with the ctx *unlocked*.  So the right pattern has the EGC_...
+ * macro calls on the outside of the CTX_... ones.
+ */
+
+/* useful for all functions which take an egc: */
+
+#define EGC_GC                                  \
+    libxl__gc *const gc = &egc->gc
+
+/* egc initialisation and destruction: */
+
+#define LIBXL_INIT_EGC(egc,ctx) do{             \
+        LIBXL_INIT_GC((egc).gc,ctx);            \
+        /* list of occurred events tbd */       \
+    } while(0)
+
+_hidden void libxl__egc_cleanup(libxl__egc *egc);
+
+/* convenience macros: */
+
+#define EGC_INIT(ctx)                       \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
+    EGC_GC
+
+#define EGC_FREE           libxl__egc_cleanup(egc)
+
+
+/*
  * Convenience macros.
  */
 
-- 
1.7.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 Jan 13 19:26:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlmky-0003g2-BA; Fri, 13 Jan 2012 19:25: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 1Rlmkw-0003fY-5A
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8062 invoked from network); 13 Jan 2012 19:25:35 -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 Jan 2012 19:25:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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; Fri, 13 Jan 2012 19:25: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
	1Rlmkp-0005p4-4Z; Fri, 13 Jan 2012 19:25:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlmkp-0002ny-0g;
	Fri, 13 Jan 2012 19:25:35 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Jan 2012 19:25:20 +0000
Message-ID: <1326482728-10733-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/9] 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    |  750 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  205 ++++++++++++
 tools/libxl/libxl_internal.h |  277 +++++++++++++++-
 6 files changed, 1267 insertions(+), 3 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 3c3661b..b58c43e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -49,7 +49,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 169fc97..413b684 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,6 +45,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_rindex = 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);
@@ -79,9 +89,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_rindex);
+    free(ctx->watch_slots);
+
+    GC_FREE;
     free(ctx);
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 723eac2..b067724 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"
@@ -223,6 +224,9 @@ enum {
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
     ERROR_NOPARAVIRT = -10,
+    ERROR_NOT_READY = -11,
+    ERROR_OSEVENT_REG_FAIL = -12,
+    ERROR_BUFFERFULL = -13,
 };
 
 #define LIBXL_VERSION 0
@@ -648,6 +652,8 @@ const char *libxl_xenpaging_dir_path(void);
 /* misc */
 int libxl_fd_set_cloexec(int fd);
 
+#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..ec66340
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,750 @@
+/*
+ * 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->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;
+
+ 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__egc *egc, libxl__ev_fd *ev,
+                             int fd, short events, short revents)
+{
+    EGC_GC;
+
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "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(egc, 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);
+        w->slotnum = -1;
+    }
+
+    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 rc;
+
+    /*
+     * 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_rindex
+         * 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_rindex.
+         */
+
+        int maxfd = 0;
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+            if (!efd->events)
+                continue;
+            if (efd->fd >= maxfd)
+                maxfd = efd->fd + 1;
+        }
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_rindex_allocd < maxfd) {
+            assert(maxfd < INT_MAX / sizeof(int) / 2);
+            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+            memset(newarray + CTX->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
+            CTX->fd_rindex = newarray;
+            CTX->fd_rindex_allocd = maxfd;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            assert(efd->fd < CTX->fd_rindex_allocd);
+            CTX->fd_rindex[efd->fd] = used;
+        }
+        used++;
+    }
+    rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    *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;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static int afterpoll_check_fd(libxl_ctx *ctx,
+                              const struct pollfd *fds, int nfds,
+                              int fd, int events)
+    /* returns mask of events which were requested and occurred */
+{
+    if (fd >= ctx->fd_rindex_allocd)
+        /* added after we went into poll, have to try again */
+        return 0;
+
+    int slot = ctx->fd_rindex[fd];
+
+    if (slot >= nfds)
+        /* stale slot entry; again, added afterwards */
+        return 0;
+
+    if (fds[slot].fd != fd)
+        /* again, stale slot entry */
+        return 0;
+
+    int revents = fds[slot].revents & events;
+    /* we mask in case requested events have changed */
+
+    return revents;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    libxl__ev_fd *efd;
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+
+        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        if (revents)
+            efd->func(egc, 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(egc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    EGC_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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(egc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+{
+    libxl__ev_time *ev = for_libxl;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(egc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func)
+{
+    EGC_GC;
+
+    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);
+}
+
+void libxl__egc_cleanup(libxl__egc *egc)
+{
+    libxl__free_all(&egc->gc);
+}
+
+/*
+ * 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..63ef65e
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,205 @@
+/*
+ * 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.
+ *
+ * (Callers inside libxl may not call libxl_osevent_... functions.)
+ */
+
+struct pollfd;
+
+/* 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);
+
+/* nfds and fds[0..nfds] must be from the most recent call to
+ * _beforepoll, as modified by poll.  (It is therefore not possible
+ * to have multiple threads simultaneously polling using this
+ * interface.)
+ *
+ * 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.
+ */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+
+
+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;
+
+/* 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.
+ */
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+
+/* 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);
+
+/* 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.
+ */
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+
+#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 39e9e05..8c9f7c9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -35,6 +35,7 @@
 #include <unistd.h>
 
 #include <sys/mman.h>
+#include <sys/poll.h>
 #include <sys/select.h>
 #include <sys/stat.h>
 #include <sys/time.h>
@@ -109,6 +110,71 @@ _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__egc libxl__egc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    int fd;
+    short events;
+    libxl__ev_fd_callback *func;
+    /* remainder is private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    void *for_app_reg;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__egc *egc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    libxl__ev_time_callback *func;
+    /* remainder is 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;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+    /* remainder is private for libxl__ev_xswatch... */
+    int slotnum; /* registered iff slotnum >= 0 */
+    uint32_t counterval;
+};
+
+/*
+ * 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;
@@ -127,6 +193,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_rindex_allocd;
+    int *fd_rindex; /* 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 */
@@ -157,12 +240,17 @@ 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;
+};
+
+struct libxl__egc {
+    /* for event-generating functions only */
+    struct libxl__gc gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -234,6 +322,140 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _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.
+ *      FUNC will be called with the context locked (with CTX_LOCK).
+ *
+ *  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.
+ * The ctx will be locked on entry to each FUNC and FUNC should not
+ * unlock it.
+ *
+ * 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; }
+
+
+/*
+ * 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).
+ */
+_hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line,
+                                   const char *func);
+#define LIBXL__EVENT_DISASTER(egc, msg, errnoval, type) \
+    libxl__event_disaster(egc, 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);
@@ -600,6 +822,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)
 
@@ -737,6 +961,55 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 
 /*
+ * Calling context and GC for event-generating functions:
+ *
+ * These are for use by parts of libxl which directly or indirectly
+ * call libxl__event_occurred.  These contain a gc but also a list of
+ * deferred events.
+ *
+ * You should never need to initialise an egc unless you are part of
+ * the event machinery itself.  Otherwise you will always be given an
+ * egc if you need one.  Even functions which generate specific kinds
+ * of events don't need to - rather, they will be passed an egc into
+ * their own callback function and should just use the one they're
+ * given.
+ *
+ * Functions using LIBXL__INIT_EGC may *not* generally be called from
+ * within libxl, because libxl__egc_cleanup may call back into the
+ * application.  This should be documented near the function
+ * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
+ * should in any case not find it necessary to call egc-creators from
+ * within libxl.
+ *
+ * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
+ * with the ctx *unlocked*.  So the right pattern has the EGC_...
+ * macro calls on the outside of the CTX_... ones.
+ */
+
+/* useful for all functions which take an egc: */
+
+#define EGC_GC                                  \
+    libxl__gc *const gc = &egc->gc
+
+/* egc initialisation and destruction: */
+
+#define LIBXL_INIT_EGC(egc,ctx) do{             \
+        LIBXL_INIT_GC((egc).gc,ctx);            \
+        /* list of occurred events tbd */       \
+    } while(0)
+
+_hidden void libxl__egc_cleanup(libxl__egc *egc);
+
+/* convenience macros: */
+
+#define EGC_INIT(ctx)                       \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
+    EGC_GC
+
+#define EGC_FREE           libxl__egc_cleanup(egc)
+
+
+/*
  * Convenience macros.
  */
 
-- 
1.7.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 Jan 13 19:26:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19: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 1Rlml9-0003jS-Hn; Fri, 13 Jan 2012 19:25:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rlml7-0003h5-5S
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8481 invoked from network); 13 Jan 2012 19:25: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;
	13 Jan 2012 19:25:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013578"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlml0-0005pL-5B; Fri, 13 Jan 2012 19:25:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml0-0002oJ-2M;
	Fri, 13 Jan 2012 19:25:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:24 +0000
Message-ID: <1326482728-10733-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/9] libxl: Permit multithreaded event waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, the context would be locked whenever we were waiting in
libxl's own call to poll (waiting for operating system events).

This would mean that multiple simultaneous calls to libxl_event_wait
in different threads with different parameters would not work
properly.

If we simply unlock the context, it would be possible for another
thread to discover the occurrence of the event we were waiting for,
without us even waking up, and we would remain in poll.  So we need a
way to wake up other threads: a pipe, one for each thread in poll.

We also need to move some variables from globals in the ctx to be
per-polling-thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   18 +++-
 tools/libxl/libxl_event.c    |  196 ++++++++++++++++++++++++++++++++++--------
 tools/libxl/libxl_internal.h |   50 ++++++++++-
 3 files changed, 218 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c68c165..9890d79 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -49,8 +49,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->osevent_hooks = 0;
 
-    ctx->fd_polls = 0;
-    ctx->fd_rindex = 0;
+    LIBXL_LIST_INIT(&ctx->pollers_event);
+    LIBXL_LIST_INIT(&ctx->pollers_idle);
+
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
 
@@ -61,6 +62,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    rc = libxl__poller_init(ctx, &ctx->poller_app);
+    if (rc) goto out;
+
     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);
@@ -135,8 +139,14 @@ 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_rindex);
+    libxl__poller_dispose(&ctx->poller_app);
+    assert(LIBXL_LIST_EMPTY(&ctx->pollers_event));
+    libxl__poller *poller, *poller_tmp;
+    LIBXL_LIST_FOREACH_SAFE(poller, &ctx->pollers_idle, entry, poller_tmp) {
+        libxl__poller_dispose(poller);
+        free(poller);
+    }
+
     free(ctx->watch_slots);
 
     discard_events(&ctx->occurred);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 621a7cc..82889f6 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -510,9 +510,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
  * osevent poll
  */
 
-static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
-                               struct pollfd *fds, int *timeout_upd,
-                               struct timeval now)
+static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
+                               int *nfds_io, struct pollfd *fds,
+                               int *timeout_upd, struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -534,7 +534,7 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = 0;
+        int maxfd = poller->wakeup_pipe[0] + 1;
         LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
             if (!efd->events)
                 continue;
@@ -542,30 +542,39 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
                 maxfd = efd->fd + 1;
         }
         /* make sure our array is as big as *nfds_io */
-        if (CTX->fd_rindex_allocd < maxfd) {
+        if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
             if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + CTX->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
-            CTX->fd_rindex = newarray;
-            CTX->fd_rindex_allocd = maxfd;
+            memset(newarray + poller->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
+            poller->fd_rindex = newarray;
+            poller->fd_rindex_allocd = maxfd;
         }
     }
 
     int used = 0;
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-        if (!efd->events)
-            continue;
-        if (used < *nfds_io) {
-            fds[used].fd = efd->fd;
-            fds[used].events = efd->events;
-            fds[used].revents = 0;
-            assert(efd->fd < CTX->fd_rindex_allocd);
-            CTX->fd_rindex[efd->fd] = used;
-        }
-        used++;
-    }
+
+#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
+        if ((req_events)) {                                     \
+            if (used < *nfds_io) {                              \
+                fds[used].fd = (req_fd);                        \
+                fds[used].events = (req_events);                \
+                fds[used].revents = 0;                          \
+                assert((req_fd) < poller->fd_rindex_allocd);    \
+                poller->fd_rindex[(req_fd)] = used;             \
+            }                                                   \
+            used++;                                             \
+        }                                                       \
+    }while(0)
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
+        REQUIRE_FD(efd->fd, efd->events, efd);
+
+    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
+
+#undef REQUIRE_FD
+
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
     *nfds_io = used;
@@ -599,22 +608,23 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
+    int rc = beforepoll_internal(gc, &ctx->poller_app,
+                                 nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
 }
 
-static int afterpoll_check_fd(libxl_ctx *ctx,
+static int afterpoll_check_fd(libxl__poller *poller,
                               const struct pollfd *fds, int nfds,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= ctx->fd_rindex_allocd)
+    if (fd >= poller->fd_rindex_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = ctx->fd_rindex[fd];
+    int slot = poller->fd_rindex[fd];
 
     if (slot >= nfds)
         /* stale slot entry; again, added afterwards */
@@ -630,22 +640,31 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-static void afterpoll_internal(libxl__egc *egc,
+static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
     EGC_GC;
     libxl__ev_fd *efd;
 
+
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
 
-        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        int revents = afterpoll_check_fd(poller,fds,nfds, efd->fd,efd->events);
         if (revents)
             efd->func(egc, efd, efd->fd, efd->events, revents);
     }
 
+    if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
+        char buf[256];
+        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
+        if (r < 0)
+            if (errno != EINTR && errno != EWOULDBLOCK)
+                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+    }
+
     for (;;) {
         libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
         if (!etime)
@@ -667,7 +686,7 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    afterpoll_internal(egc, nfds, fds, now);
+    afterpoll_internal(egc, &ctx->poller_app, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
@@ -790,7 +809,10 @@ void libxl__event_occurred(libxl__egc *egc, libxl_event *event)
         LIBXL_TAILQ_INSERT_TAIL(&egc->occurred_for_callback, event, link);
         return;
     } else {
+        libxl__poller *poller;
         LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+        LIBXL_LIST_FOREACH(poller, &CTX->pollers_event, entry)
+            libxl__poller_wakeup(egc, poller);
     }
 }
 
@@ -858,7 +880,94 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
-static int eventloop_iteration(libxl__egc *egc) {
+/*
+ * Manipulation of pollers
+ */
+
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
+{
+    int r, rc;
+    p->fd_polls = 0;
+    p->fd_rindex = 0;
+
+    r = pipe(p->wakeup_pipe);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
+    if (rc) goto out;
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__poller_dispose(p);
+    return rc;
+}
+
+void libxl__poller_dispose(libxl__poller *p)
+{
+    if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
+    if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
+    free(p->fd_polls);
+    free(p->fd_rindex);
+}
+
+libxl__poller *libxl__poller_get(libxl_ctx *ctx)
+{
+    /* must be called with ctx locked */
+    int rc;
+
+    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
+    if (p)
+        return p;
+
+    p = malloc(sizeof(*p));
+    if (!p) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
+        return 0;
+    }
+    memset(p, 0, sizeof(*p));
+
+    rc = libxl__poller_init(ctx, p);
+    if (rc) return NULL;
+
+    return p;
+}
+
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
+{
+    LIBXL_LIST_INSERT_HEAD(&ctx->pollers_idle, p, entry);
+}
+
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
+{
+    static const char buf[1] = "";
+
+    for (;;) {
+        int r = write(p->wakeup_pipe[1], buf, 1);
+        if (r==1) return;
+        assert(r==-1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return;
+        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
+        return;
+    }
+}
+
+/*
+ * Main event loop iteration
+ */
+
+static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
+    /* The CTX must be locked EXACTLY ONCE so that this function
+     * can unlock it when it polls.
+     */
     EGC_GC;
     int rc;
     struct timeval now;
@@ -871,23 +980,27 @@ static int eventloop_iteration(libxl__egc *egc) {
     int timeout;
 
     for (;;) {
-        int nfds = CTX->fd_polls_allocd;
+        int nfds = poller->fd_polls_allocd;
         timeout = -1;
-        rc = beforepoll_internal(gc, &nfds, CTX->fd_polls, &timeout, now);
+        rc = beforepoll_internal(gc, poller, &nfds, poller->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);
+            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
 
         if (!newarray) { rc = ERROR_NOMEM; goto out; }
 
-        CTX->fd_polls = newarray;
-        CTX->fd_polls_allocd = nfds;
+        poller->fd_polls = newarray;
+        poller->fd_polls_allocd = nfds;
     }
 
-    rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+    CTX_UNLOCK;
+    rc = poll(poller->fd_polls, poller->fd_polls_allocd, timeout);
+    CTX_LOCK;
+
     if (rc < 0) {
         if (errno == EINTR)
             return 0; /* will go round again if caller requires */
@@ -900,7 +1013,8 @@ static int eventloop_iteration(libxl__egc *egc) {
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
-    afterpoll_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+    afterpoll_internal(egc, poller,
+                       poller->fd_polls_allocd, poller->fd_polls, now);
 
     CTX_UNLOCK;
 
@@ -914,15 +1028,19 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      libxl_event_predicate *pred, void *pred_user)
 {
     int rc;
+    libxl__poller *poller = NULL;
 
     EGC_INIT(ctx);
     CTX_LOCK;
 
+    poller = libxl__poller_get(ctx);
+    if (!poller) { rc = ERROR_FAIL; goto out; }
+
     for (;;) {
         rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
         if (rc != ERROR_NOT_READY) goto out;
 
-        rc = eventloop_iteration(egc);
+        rc = eventloop_iteration(egc, poller);
         if (rc) goto out;
 
         /* we unlock and cleanup the egc each time we go through this loop,
@@ -936,6 +1054,8 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     }
 
  out:
+    libxl__poller_put(ctx, poller);
+
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index edb73eb..53d2462 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -205,6 +205,33 @@ struct libxl__evgen_disk_eject {
 _hidden void
 libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
 
+typedef struct libxl__poller libxl__poller;
+struct libxl__poller {
+    /*
+     * These are used to allow other threads to wake up a thread which
+     * may be stuck in poll, because whatever it was waiting for
+     * hadn't happened yet.  Threads which generate events will write
+     * a byte to each pipe.  A thread which is waiting will empty its
+     * own pipe, and put its poller on the pollers_event list, before
+     * releasing the ctx lock and going into poll; when it comes out
+     * of poll it will take the poller off the pollers_event list.
+     *
+     * When a thread is done with a poller it should put it onto
+     * pollers_idle, where it can be reused later.
+     *
+     * The "poller_app" is never idle, but is sometimes on
+     * pollers_event.
+     */
+    LIBXL_LIST_ENTRY(libxl__poller) entry;
+
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
+    int fd_rindex_allocd;
+    int *fd_rindex; /* see libxl_osevent_beforepoll */
+
+    int wakeup_pipe[2]; /* 0 means no fd allocated */
+};
 
 struct libxl__ctx {
     xentoollog_logger *lg;
@@ -235,10 +262,9 @@ struct libxl__ctx {
       /* 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_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    libxl__poller poller_app; /* libxl_osevent_beforepoll and _afterpoll */
+    LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
+
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
     LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
 
@@ -524,6 +550,22 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
     libxl__event_disaster(egc, msg, errnoval, type, __FILE__,__LINE__,__func__)
 
 
+/* Fills in, or disposes of, the resources held by, a poller whose
+ * space the caller has allocated.  ctx must be locked. */
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+void libxl__poller_dispose(libxl__poller *p);
+
+/* Obtain a fresh poller from malloc or the idle list, and put it
+ * away again afterwards.  _get can fail, returning NULL.
+ * ctx must be locked. */
+libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
+
+/* Notifies whoever is polling using p that they should wake up.
+ * ctx must be locked. */
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
+
+
 /* 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);
-- 
1.7.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 Jan 13 19:26:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19: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 1Rlml9-0003jS-Hn; Fri, 13 Jan 2012 19:25:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rlml7-0003h5-5S
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8481 invoked from network); 13 Jan 2012 19:25: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;
	13 Jan 2012 19:25:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013578"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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, 13 Jan 2012 19:25: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
	1Rlml0-0005pL-5B; Fri, 13 Jan 2012 19:25:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml0-0002oJ-2M;
	Fri, 13 Jan 2012 19:25:46 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:24 +0000
Message-ID: <1326482728-10733-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 5/9] libxl: Permit multithreaded event waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, the context would be locked whenever we were waiting in
libxl's own call to poll (waiting for operating system events).

This would mean that multiple simultaneous calls to libxl_event_wait
in different threads with different parameters would not work
properly.

If we simply unlock the context, it would be possible for another
thread to discover the occurrence of the event we were waiting for,
without us even waking up, and we would remain in poll.  So we need a
way to wake up other threads: a pipe, one for each thread in poll.

We also need to move some variables from globals in the ctx to be
per-polling-thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   18 +++-
 tools/libxl/libxl_event.c    |  196 ++++++++++++++++++++++++++++++++++--------
 tools/libxl/libxl_internal.h |   50 ++++++++++-
 3 files changed, 218 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index c68c165..9890d79 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -49,8 +49,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->osevent_hooks = 0;
 
-    ctx->fd_polls = 0;
-    ctx->fd_rindex = 0;
+    LIBXL_LIST_INIT(&ctx->pollers_event);
+    LIBXL_LIST_INIT(&ctx->pollers_idle);
+
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
 
@@ -61,6 +62,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    rc = libxl__poller_init(ctx, &ctx->poller_app);
+    if (rc) goto out;
+
     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);
@@ -135,8 +139,14 @@ 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_rindex);
+    libxl__poller_dispose(&ctx->poller_app);
+    assert(LIBXL_LIST_EMPTY(&ctx->pollers_event));
+    libxl__poller *poller, *poller_tmp;
+    LIBXL_LIST_FOREACH_SAFE(poller, &ctx->pollers_idle, entry, poller_tmp) {
+        libxl__poller_dispose(poller);
+        free(poller);
+    }
+
     free(ctx->watch_slots);
 
     discard_events(&ctx->occurred);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 621a7cc..82889f6 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -510,9 +510,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
  * osevent poll
  */
 
-static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
-                               struct pollfd *fds, int *timeout_upd,
-                               struct timeval now)
+static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
+                               int *nfds_io, struct pollfd *fds,
+                               int *timeout_upd, struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -534,7 +534,7 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = 0;
+        int maxfd = poller->wakeup_pipe[0] + 1;
         LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
             if (!efd->events)
                 continue;
@@ -542,30 +542,39 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
                 maxfd = efd->fd + 1;
         }
         /* make sure our array is as big as *nfds_io */
-        if (CTX->fd_rindex_allocd < maxfd) {
+        if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
             if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + CTX->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
-            CTX->fd_rindex = newarray;
-            CTX->fd_rindex_allocd = maxfd;
+            memset(newarray + poller->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
+            poller->fd_rindex = newarray;
+            poller->fd_rindex_allocd = maxfd;
         }
     }
 
     int used = 0;
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-        if (!efd->events)
-            continue;
-        if (used < *nfds_io) {
-            fds[used].fd = efd->fd;
-            fds[used].events = efd->events;
-            fds[used].revents = 0;
-            assert(efd->fd < CTX->fd_rindex_allocd);
-            CTX->fd_rindex[efd->fd] = used;
-        }
-        used++;
-    }
+
+#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
+        if ((req_events)) {                                     \
+            if (used < *nfds_io) {                              \
+                fds[used].fd = (req_fd);                        \
+                fds[used].events = (req_events);                \
+                fds[used].revents = 0;                          \
+                assert((req_fd) < poller->fd_rindex_allocd);    \
+                poller->fd_rindex[(req_fd)] = used;             \
+            }                                                   \
+            used++;                                             \
+        }                                                       \
+    }while(0)
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
+        REQUIRE_FD(efd->fd, efd->events, efd);
+
+    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
+
+#undef REQUIRE_FD
+
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
     *nfds_io = used;
@@ -599,22 +608,23 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
+    int rc = beforepoll_internal(gc, &ctx->poller_app,
+                                 nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
 }
 
-static int afterpoll_check_fd(libxl_ctx *ctx,
+static int afterpoll_check_fd(libxl__poller *poller,
                               const struct pollfd *fds, int nfds,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= ctx->fd_rindex_allocd)
+    if (fd >= poller->fd_rindex_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = ctx->fd_rindex[fd];
+    int slot = poller->fd_rindex[fd];
 
     if (slot >= nfds)
         /* stale slot entry; again, added afterwards */
@@ -630,22 +640,31 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-static void afterpoll_internal(libxl__egc *egc,
+static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
     EGC_GC;
     libxl__ev_fd *efd;
 
+
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
 
-        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        int revents = afterpoll_check_fd(poller,fds,nfds, efd->fd,efd->events);
         if (revents)
             efd->func(egc, efd, efd->fd, efd->events, revents);
     }
 
+    if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
+        char buf[256];
+        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
+        if (r < 0)
+            if (errno != EINTR && errno != EWOULDBLOCK)
+                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+    }
+
     for (;;) {
         libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
         if (!etime)
@@ -667,7 +686,7 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    afterpoll_internal(egc, nfds, fds, now);
+    afterpoll_internal(egc, &ctx->poller_app, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
@@ -790,7 +809,10 @@ void libxl__event_occurred(libxl__egc *egc, libxl_event *event)
         LIBXL_TAILQ_INSERT_TAIL(&egc->occurred_for_callback, event, link);
         return;
     } else {
+        libxl__poller *poller;
         LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+        LIBXL_LIST_FOREACH(poller, &CTX->pollers_event, entry)
+            libxl__poller_wakeup(egc, poller);
     }
 }
 
@@ -858,7 +880,94 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
-static int eventloop_iteration(libxl__egc *egc) {
+/*
+ * Manipulation of pollers
+ */
+
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
+{
+    int r, rc;
+    p->fd_polls = 0;
+    p->fd_rindex = 0;
+
+    r = pipe(p->wakeup_pipe);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
+    if (rc) goto out;
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__poller_dispose(p);
+    return rc;
+}
+
+void libxl__poller_dispose(libxl__poller *p)
+{
+    if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
+    if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
+    free(p->fd_polls);
+    free(p->fd_rindex);
+}
+
+libxl__poller *libxl__poller_get(libxl_ctx *ctx)
+{
+    /* must be called with ctx locked */
+    int rc;
+
+    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
+    if (p)
+        return p;
+
+    p = malloc(sizeof(*p));
+    if (!p) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
+        return 0;
+    }
+    memset(p, 0, sizeof(*p));
+
+    rc = libxl__poller_init(ctx, p);
+    if (rc) return NULL;
+
+    return p;
+}
+
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
+{
+    LIBXL_LIST_INSERT_HEAD(&ctx->pollers_idle, p, entry);
+}
+
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
+{
+    static const char buf[1] = "";
+
+    for (;;) {
+        int r = write(p->wakeup_pipe[1], buf, 1);
+        if (r==1) return;
+        assert(r==-1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return;
+        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
+        return;
+    }
+}
+
+/*
+ * Main event loop iteration
+ */
+
+static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
+    /* The CTX must be locked EXACTLY ONCE so that this function
+     * can unlock it when it polls.
+     */
     EGC_GC;
     int rc;
     struct timeval now;
@@ -871,23 +980,27 @@ static int eventloop_iteration(libxl__egc *egc) {
     int timeout;
 
     for (;;) {
-        int nfds = CTX->fd_polls_allocd;
+        int nfds = poller->fd_polls_allocd;
         timeout = -1;
-        rc = beforepoll_internal(gc, &nfds, CTX->fd_polls, &timeout, now);
+        rc = beforepoll_internal(gc, poller, &nfds, poller->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);
+            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
 
         if (!newarray) { rc = ERROR_NOMEM; goto out; }
 
-        CTX->fd_polls = newarray;
-        CTX->fd_polls_allocd = nfds;
+        poller->fd_polls = newarray;
+        poller->fd_polls_allocd = nfds;
     }
 
-    rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+    CTX_UNLOCK;
+    rc = poll(poller->fd_polls, poller->fd_polls_allocd, timeout);
+    CTX_LOCK;
+
     if (rc < 0) {
         if (errno == EINTR)
             return 0; /* will go round again if caller requires */
@@ -900,7 +1013,8 @@ static int eventloop_iteration(libxl__egc *egc) {
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
-    afterpoll_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+    afterpoll_internal(egc, poller,
+                       poller->fd_polls_allocd, poller->fd_polls, now);
 
     CTX_UNLOCK;
 
@@ -914,15 +1028,19 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      libxl_event_predicate *pred, void *pred_user)
 {
     int rc;
+    libxl__poller *poller = NULL;
 
     EGC_INIT(ctx);
     CTX_LOCK;
 
+    poller = libxl__poller_get(ctx);
+    if (!poller) { rc = ERROR_FAIL; goto out; }
+
     for (;;) {
         rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
         if (rc != ERROR_NOT_READY) goto out;
 
-        rc = eventloop_iteration(egc);
+        rc = eventloop_iteration(egc, poller);
         if (rc) goto out;
 
         /* we unlock and cleanup the egc each time we go through this loop,
@@ -936,6 +1054,8 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     }
 
  out:
+    libxl__poller_put(ctx, poller);
+
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index edb73eb..53d2462 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -205,6 +205,33 @@ struct libxl__evgen_disk_eject {
 _hidden void
 libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
 
+typedef struct libxl__poller libxl__poller;
+struct libxl__poller {
+    /*
+     * These are used to allow other threads to wake up a thread which
+     * may be stuck in poll, because whatever it was waiting for
+     * hadn't happened yet.  Threads which generate events will write
+     * a byte to each pipe.  A thread which is waiting will empty its
+     * own pipe, and put its poller on the pollers_event list, before
+     * releasing the ctx lock and going into poll; when it comes out
+     * of poll it will take the poller off the pollers_event list.
+     *
+     * When a thread is done with a poller it should put it onto
+     * pollers_idle, where it can be reused later.
+     *
+     * The "poller_app" is never idle, but is sometimes on
+     * pollers_event.
+     */
+    LIBXL_LIST_ENTRY(libxl__poller) entry;
+
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
+    int fd_rindex_allocd;
+    int *fd_rindex; /* see libxl_osevent_beforepoll */
+
+    int wakeup_pipe[2]; /* 0 means no fd allocated */
+};
 
 struct libxl__ctx {
     xentoollog_logger *lg;
@@ -235,10 +262,9 @@ struct libxl__ctx {
       /* 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_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    libxl__poller poller_app; /* libxl_osevent_beforepoll and _afterpoll */
+    LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
+
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
     LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
 
@@ -524,6 +550,22 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
     libxl__event_disaster(egc, msg, errnoval, type, __FILE__,__LINE__,__func__)
 
 
+/* Fills in, or disposes of, the resources held by, a poller whose
+ * space the caller has allocated.  ctx must be locked. */
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+void libxl__poller_dispose(libxl__poller *p);
+
+/* Obtain a fresh poller from malloc or the idle list, and put it
+ * away again afterwards.  _get can fail, returning NULL.
+ * ctx must be locked. */
+libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
+
+/* Notifies whoever is polling using p that they should wake up.
+ * ctx must be locked. */
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
+
+
 /* 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);
-- 
1.7.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 Jan 13 19:26:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19: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 1RlmlC-0003kf-0I; Fri, 13 Jan 2012 19:25:58 +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 1Rlml9-0003hf-K1
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 13 Jan 2012 19:25:49 -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 Jan 2012 19:25:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 19:25:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rlml2-0005pO-FM; Fri, 13 Jan 2012 19:25:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml2-0002oN-EV;
	Fri, 13 Jan 2012 19:25:48 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:25 +0000
Message-ID: <1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide a new set of machinery for writing public libxl functions
which may take a long time.  The application gets to decide whether
they want the function to be synchronous, or whether they'd prefer to
get a callback, or an event, when the operation is complete.

User(s) of this machinery will be introduced in later patch(es).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   50 ++++++++++++
 tools/libxl/libxl_event.c    |  183 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |  112 ++++++++++++++++++++++++++
 tools/libxl/libxl_types.idl  |    4 +
 4 files changed, 349 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e32881b..416d6e8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -235,8 +235,58 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_ASYNC_INPROGRESS = -14,
 };
 
+
+/*
+ * Some libxl operations can take a long time.  These functions take a
+ * parameter to control their concurrency:
+ *     libxl_asyncop_how *ao_how
+ *
+ * If ao_how==NULL, the function will be synchronous.
+ *
+ * If ao_how!=NULL, the function will set the operation going, and
+ * if this is successful will return ERROR_ASYNCH_INPROGRESS.
+ *
+ * If ao_how->callback!=NULL, the callback will be called when the
+ * operation completes.  The same rules as for libxl_event_hooks
+ * apply, including the reentrancy rules and the possibility of
+ * "disaster", except that libxl calls ao_how->callback instead of
+ * libxl_event_hooks.event_occurs.
+ *
+ * If ao_how->callback==NULL, a libxl_event will be generated which
+ * can be obtained from libxl_event_wait or libxl_event_check.  The
+ * event will have type OPERATION_COMPLETE (which is not used
+ * elsewhere).
+ *
+ * Note that it is possible for an asynchronous operation which is to
+ * result in a callback to complete during its initiating function
+ * call.  In this case the initating function will return
+ * ERROR_ASYNCH_INPROGRESS, even though by the time it returns the
+ * operation is complete and the callback has already happened.
+ *
+ * The application must set and use ao_how->for_event (which will be
+ * copied into libxl_event.for_user) or ao_how->for_callback (passed
+ * to the callback) to determine which operation finished, and it must
+ * of course check the rc value for errors.
+ *
+ * *ao_how does not need to remain valid after the initiating function
+ * returns.
+ *
+ * Callbacks may occur on any thread in which the application calls
+ * libxl.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
+    union {
+        libxl_ev_user for_event; /* used if callback==NULL */
+        void *for_callback; /* passed to callback */
+    } u;
+} libxl_asyncop_how;
+
+
 #define LIBXL_VERSION 0
 
 typedef struct {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 82889f6..b99049a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -771,10 +771,21 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
+
+    libxl__ao *ao, *ao_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
+                             entry_for_callback, ao_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
+        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        ao->notified = 1;
+        if (!ao->in_initiator)
+            libxl__ao__destroy(CTX, ao);
+    }
 }
 
 void libxl__egc_cleanup(libxl__egc *egc)
@@ -1061,6 +1072,178 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
+
+
+/*
+ * The two possible state flow of an ao:
+ *
+ * Completion before initiator return:
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_complete:               |
+ *     - if synchronous, run event loop           |
+ *       until the ao completes                   |
+ *                              - ao completes on some thread
+ *                              - completing thread releases the lock
+ *                     <--------------'
+ *     - ao_complete takes the lock
+ *     - destroy the ao
+ *
+ *
+ * Completion after initiator return (asynch. only):
+ *
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_complete:               |
+ *     - observes event not net done,             |
+ *     - returns to caller                        |
+ *                                                |
+ *                              - ao completes on some thread
+ *                              - generate the event or call the callback
+ *                              - destroy the ao
+ */
+
+void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao) {
+    if (!ao) return;
+    if (ao->poller) libxl__poller_put(ctx, ao->poller);
+    ao->magic = LIBXL__AO_MAGIC_DESTROYED;
+    libxl__free_all(&ao->gc);
+    free(ao);
+}
+
+void libxl__ao_abort(libxl__ao *ao) {
+    AO_GC;
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+    assert(!ao->complete);
+    libxl__ao__destroy(CTX, ao);
+}
+
+void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(!ao->complete);
+    ao->complete = 1;
+    ao->rc = rc;
+
+    if (ao->poller) {
+        assert(ao->in_initiator);
+        libxl__poller_wakeup(egc, ao->poller);
+    } else if (ao->how.callback) {
+        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
+    } else {
+        libxl_event *ev;
+        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
+        if (ev) {
+            ev->for_user = ao->how.u.for_event;
+            ev->u.operation_complete.rc = ao->rc;
+            libxl__event_occurred(egc, ev);
+        }
+        ao->notified = 1;
+    }
+    if (!ao->in_initiator && ao->notified)
+        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
+}
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how) {
+    libxl__ao *ao;
+
+    ao = calloc(sizeof(*ao),1);
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+int libxl__ao_inprogress(libxl__ao *ao) {
+    AO_GC;
+    int rc;
+
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+
+    if (ao->poller) {
+        /* Caller wants it done synchronously. */
+        /* We use a fresh gc, so that we can free things
+         * each time round the loop. */
+        libxl__egc egc;
+        LIBXL_INIT_EGC(egc,CTX);
+
+        for (;;) {
+            assert(ao->magic == LIBXL__AO_MAGIC);
+
+            if (ao->complete) {
+                rc = ao->rc;
+                ao->notified = 1;
+                break;
+            }
+
+            rc = eventloop_iteration(&egc,ao->poller);
+            if (rc) {
+                /* Oh dear, this is quite unfortunate. */
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
+                           " event during long-running operation (rc=%d)", rc);
+                sleep(1);
+                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
+                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
+                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
+                 * cancellation ability. */
+            }
+
+            CTX_UNLOCK;
+            libxl__egc_cleanup(&egc);
+            CTX_LOCK;
+        }
+    } else {
+        rc = ERROR_ASYNC_INPROGRESS;
+    }
+
+    ao->in_initiator = 0;
+
+    if (ao->notified) {
+        assert(ao->complete);
+        libxl__ao__destroy(CTX,ao);
+    }
+
+    return rc;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 53d2462..594b9fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -112,6 +112,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
+typedef struct libxl__ao libxl__ao;
 
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
@@ -216,6 +217,10 @@ struct libxl__poller {
      * releasing the ctx lock and going into poll; when it comes out
      * of poll it will take the poller off the pollers_event list.
      *
+     * A thread which is waiting for completion of a synchronous ao
+     * will allocate a poller and record it in the ao, so that other
+     * threads can wake it up.
+     *
      * When a thread is done with a poller it should put it onto
      * pollers_idle, where it can be reused later.
      *
@@ -322,6 +327,21 @@ struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+};
+
+#define LIBXL__AO_MAGIC              0xA0FACE00ul
+#define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
+
+struct libxl__ao {
+    uint32_t magic;
+    unsigned in_initiator:1, complete:1, notified:1;
+    int rc;
+    libxl__gc gc;
+    libxl_asyncop_how how;
+    libxl__poller *poller;
+    uint32_t domid;
+    LIBXL_TAILQ_ENTRY(libxl__ao) entry_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -1106,6 +1126,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define LIBXL_INIT_EGC(egc,ctx) do{                     \
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
+        LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1123,6 +1144,97 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 
 
 /*
+ * Machinery for asynchronous operations ("ao")
+ *
+ * All "slow" functions (includes anything that might block on a
+ * guest or an external script) need to use the asynchronous
+ * operation ("ao") machinery.  The function should take a parameter
+ * const libxl_asyncop_how *ao_how and must start with a call to
+ * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
+ * outside libxl, because they can cause reentrancy callbacks.
+ *
+ * No functions called internally within libxl should ever return
+ * ERROR_ASYNCH_INPROGRESS.
+ *
+ * Lifecycle of an ao:
+ *
+ * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
+ *
+ * - After creation, can be used by code which implements
+ *   the operation as follows:
+ *      - the ao's gc, for allocating memory for the lifetime
+ *        of the operation (possibly with the help of the AO_GC
+ *        macro to introduce the gc into scope)
+ *      - the ao itself may be passed about to sub-functions
+ *        so that they can stash it away etc.
+ *      - in particular, the ao pointer must be stashed in some
+ *        per-operation structure which is also passed as a user
+ *        pointer to the internal event generation request routines
+ *        libxl__evgen_FOO, so that at some point a CALLBACK will be
+ *        made when the operation is complete.
+ *
+ * - If initiation is successful, the initiating function needs
+ *   to run libxl__ao_inprogress right before unlocking and
+ *   returning, and return whatever it returns (AO_INPROGRESS macro).
+ *
+ * - If the initiation is unsuccessful, the initiating function must
+ *   call libxl__ao_abort before unlocking and returning whatever
+ *   error code is appropriate (AO_ABORT macro).
+ *
+ * - Later, some callback function, whose callback has been requested
+ *   directly or indirectly, should call libxl__ao_complete (with the
+ *   ctx locked, as it will generally already be in any event callback
+ *   function).  This must happen exactly once for each ao (and not if
+ *   the ao has been destroyed, obviously), and it may not happen
+ *   until libxl__ao_inprogress has been called on the ao.
+ *
+ * - Note that during callback functions, two gcs are available:
+ *    - The one in egc, whose lifetime is only this callback
+ *    - The one in ao, whose lifetime is the asynchronous operation
+ *   Usually callback function should use GET_CONTAINING_STRUCT
+ *   to obtain its own structure, containing a pointer to the ao,
+ *   and then use the gc from that ao.
+ */
+
+#define AO_CREATE(ctx, domid, ao_how)                           \
+    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
+    if (!ao) return ERROR_NOMEM;                                \
+    AO_GC;                                                      \
+    CTX_LOCK;
+
+#define AO_INPROGRESS do{                                       \
+        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        int ao__rc = libxl__ao_inprogress(ao);                  \
+        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
+        return ao__rc;                                          \
+   }while(0)
+        
+
+#define AO_ABORT(rc) do{                                        \
+        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        assert(rc);                                             \
+        assert(rc != ERROR_ASYNC_INPROGRESS);                   \
+        libxl__ao_abort(ao);                                    \
+        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
+        return (rc);                                            \
+    }while(0)
+
+#define AO_GC                                   \
+    libxl__gc *const gc = &ao->gc
+
+
+/* All of these MUST be called with the ctx locked.
+ * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
+_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
+                                    const libxl_asyncop_how*);
+_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden void libxl__ao_abort(libxl__ao *ao);
+_hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
+
+/* For use by ao machinery ONLY */
+_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+
+/*
  * Convenience macros.
  */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index a6dac79..325bb21 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -395,6 +395,7 @@ libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DESTROY"),
     (3, "DISK_EJECT"),
+    (4, "OPERATION_COMPLETE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -418,4 +419,7 @@ libxl_event = Struct("event",[
                                         ("vdev", string),
                                         ("disk", libxl_device_disk),
                                  ])),
+           ("operation_complete", Struct(None, [
+                                        ("rc", integer),
+                                 ])),
            ]))])
-- 
1.7.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 Jan 13 19:26:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19: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 1RlmlC-0003kf-0I; Fri, 13 Jan 2012 19:25:58 +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 1Rlml9-0003hf-K1
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:25:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8532 invoked from network); 13 Jan 2012 19:25:49 -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 Jan 2012 19:25:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013580"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 19:25:48 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rlml2-0005pO-FM; Fri, 13 Jan 2012 19:25:48 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml2-0002oN-EV;
	Fri, 13 Jan 2012 19:25:48 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:25 +0000
Message-ID: <1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation
	infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide a new set of machinery for writing public libxl functions
which may take a long time.  The application gets to decide whether
they want the function to be synchronous, or whether they'd prefer to
get a callback, or an event, when the operation is complete.

User(s) of this machinery will be introduced in later patch(es).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   50 ++++++++++++
 tools/libxl/libxl_event.c    |  183 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |  112 ++++++++++++++++++++++++++
 tools/libxl/libxl_types.idl  |    4 +
 4 files changed, 349 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e32881b..416d6e8 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -235,8 +235,58 @@ enum {
     ERROR_NOT_READY = -11,
     ERROR_OSEVENT_REG_FAIL = -12,
     ERROR_BUFFERFULL = -13,
+    ERROR_ASYNC_INPROGRESS = -14,
 };
 
+
+/*
+ * Some libxl operations can take a long time.  These functions take a
+ * parameter to control their concurrency:
+ *     libxl_asyncop_how *ao_how
+ *
+ * If ao_how==NULL, the function will be synchronous.
+ *
+ * If ao_how!=NULL, the function will set the operation going, and
+ * if this is successful will return ERROR_ASYNCH_INPROGRESS.
+ *
+ * If ao_how->callback!=NULL, the callback will be called when the
+ * operation completes.  The same rules as for libxl_event_hooks
+ * apply, including the reentrancy rules and the possibility of
+ * "disaster", except that libxl calls ao_how->callback instead of
+ * libxl_event_hooks.event_occurs.
+ *
+ * If ao_how->callback==NULL, a libxl_event will be generated which
+ * can be obtained from libxl_event_wait or libxl_event_check.  The
+ * event will have type OPERATION_COMPLETE (which is not used
+ * elsewhere).
+ *
+ * Note that it is possible for an asynchronous operation which is to
+ * result in a callback to complete during its initiating function
+ * call.  In this case the initating function will return
+ * ERROR_ASYNCH_INPROGRESS, even though by the time it returns the
+ * operation is complete and the callback has already happened.
+ *
+ * The application must set and use ao_how->for_event (which will be
+ * copied into libxl_event.for_user) or ao_how->for_callback (passed
+ * to the callback) to determine which operation finished, and it must
+ * of course check the rc value for errors.
+ *
+ * *ao_how does not need to remain valid after the initiating function
+ * returns.
+ *
+ * Callbacks may occur on any thread in which the application calls
+ * libxl.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
+    union {
+        libxl_ev_user for_event; /* used if callback==NULL */
+        void *for_callback; /* passed to callback */
+    } u;
+} libxl_asyncop_how;
+
+
 #define LIBXL_VERSION 0
 
 typedef struct {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 82889f6..b99049a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -771,10 +771,21 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
+
+    libxl__ao *ao, *ao_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
+                             entry_for_callback, ao_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
+        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        ao->notified = 1;
+        if (!ao->in_initiator)
+            libxl__ao__destroy(CTX, ao);
+    }
 }
 
 void libxl__egc_cleanup(libxl__egc *egc)
@@ -1061,6 +1072,178 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
+
+
+/*
+ * The two possible state flow of an ao:
+ *
+ * Completion before initiator return:
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_complete:               |
+ *     - if synchronous, run event loop           |
+ *       until the ao completes                   |
+ *                              - ao completes on some thread
+ *                              - completing thread releases the lock
+ *                     <--------------'
+ *     - ao_complete takes the lock
+ *     - destroy the ao
+ *
+ *
+ * Completion after initiator return (asynch. only):
+ *
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_complete:               |
+ *     - observes event not net done,             |
+ *     - returns to caller                        |
+ *                                                |
+ *                              - ao completes on some thread
+ *                              - generate the event or call the callback
+ *                              - destroy the ao
+ */
+
+void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao) {
+    if (!ao) return;
+    if (ao->poller) libxl__poller_put(ctx, ao->poller);
+    ao->magic = LIBXL__AO_MAGIC_DESTROYED;
+    libxl__free_all(&ao->gc);
+    free(ao);
+}
+
+void libxl__ao_abort(libxl__ao *ao) {
+    AO_GC;
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+    assert(!ao->complete);
+    libxl__ao__destroy(CTX, ao);
+}
+
+void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(!ao->complete);
+    ao->complete = 1;
+    ao->rc = rc;
+
+    if (ao->poller) {
+        assert(ao->in_initiator);
+        libxl__poller_wakeup(egc, ao->poller);
+    } else if (ao->how.callback) {
+        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
+    } else {
+        libxl_event *ev;
+        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
+        if (ev) {
+            ev->for_user = ao->how.u.for_event;
+            ev->u.operation_complete.rc = ao->rc;
+            libxl__event_occurred(egc, ev);
+        }
+        ao->notified = 1;
+    }
+    if (!ao->in_initiator && ao->notified)
+        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
+}
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how) {
+    libxl__ao *ao;
+
+    ao = calloc(sizeof(*ao),1);
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+int libxl__ao_inprogress(libxl__ao *ao) {
+    AO_GC;
+    int rc;
+
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+
+    if (ao->poller) {
+        /* Caller wants it done synchronously. */
+        /* We use a fresh gc, so that we can free things
+         * each time round the loop. */
+        libxl__egc egc;
+        LIBXL_INIT_EGC(egc,CTX);
+
+        for (;;) {
+            assert(ao->magic == LIBXL__AO_MAGIC);
+
+            if (ao->complete) {
+                rc = ao->rc;
+                ao->notified = 1;
+                break;
+            }
+
+            rc = eventloop_iteration(&egc,ao->poller);
+            if (rc) {
+                /* Oh dear, this is quite unfortunate. */
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
+                           " event during long-running operation (rc=%d)", rc);
+                sleep(1);
+                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
+                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
+                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
+                 * cancellation ability. */
+            }
+
+            CTX_UNLOCK;
+            libxl__egc_cleanup(&egc);
+            CTX_LOCK;
+        }
+    } else {
+        rc = ERROR_ASYNC_INPROGRESS;
+    }
+
+    ao->in_initiator = 0;
+
+    if (ao->notified) {
+        assert(ao->complete);
+        libxl__ao__destroy(CTX,ao);
+    }
+
+    return rc;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 53d2462..594b9fb 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -112,6 +112,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
+typedef struct libxl__ao libxl__ao;
 
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
@@ -216,6 +217,10 @@ struct libxl__poller {
      * releasing the ctx lock and going into poll; when it comes out
      * of poll it will take the poller off the pollers_event list.
      *
+     * A thread which is waiting for completion of a synchronous ao
+     * will allocate a poller and record it in the ao, so that other
+     * threads can wake it up.
+     *
      * When a thread is done with a poller it should put it onto
      * pollers_idle, where it can be reused later.
      *
@@ -322,6 +327,21 @@ struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+};
+
+#define LIBXL__AO_MAGIC              0xA0FACE00ul
+#define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
+
+struct libxl__ao {
+    uint32_t magic;
+    unsigned in_initiator:1, complete:1, notified:1;
+    int rc;
+    libxl__gc gc;
+    libxl_asyncop_how how;
+    libxl__poller *poller;
+    uint32_t domid;
+    LIBXL_TAILQ_ENTRY(libxl__ao) entry_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -1106,6 +1126,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define LIBXL_INIT_EGC(egc,ctx) do{                     \
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
+        LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1123,6 +1144,97 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 
 
 /*
+ * Machinery for asynchronous operations ("ao")
+ *
+ * All "slow" functions (includes anything that might block on a
+ * guest or an external script) need to use the asynchronous
+ * operation ("ao") machinery.  The function should take a parameter
+ * const libxl_asyncop_how *ao_how and must start with a call to
+ * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
+ * outside libxl, because they can cause reentrancy callbacks.
+ *
+ * No functions called internally within libxl should ever return
+ * ERROR_ASYNCH_INPROGRESS.
+ *
+ * Lifecycle of an ao:
+ *
+ * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
+ *
+ * - After creation, can be used by code which implements
+ *   the operation as follows:
+ *      - the ao's gc, for allocating memory for the lifetime
+ *        of the operation (possibly with the help of the AO_GC
+ *        macro to introduce the gc into scope)
+ *      - the ao itself may be passed about to sub-functions
+ *        so that they can stash it away etc.
+ *      - in particular, the ao pointer must be stashed in some
+ *        per-operation structure which is also passed as a user
+ *        pointer to the internal event generation request routines
+ *        libxl__evgen_FOO, so that at some point a CALLBACK will be
+ *        made when the operation is complete.
+ *
+ * - If initiation is successful, the initiating function needs
+ *   to run libxl__ao_inprogress right before unlocking and
+ *   returning, and return whatever it returns (AO_INPROGRESS macro).
+ *
+ * - If the initiation is unsuccessful, the initiating function must
+ *   call libxl__ao_abort before unlocking and returning whatever
+ *   error code is appropriate (AO_ABORT macro).
+ *
+ * - Later, some callback function, whose callback has been requested
+ *   directly or indirectly, should call libxl__ao_complete (with the
+ *   ctx locked, as it will generally already be in any event callback
+ *   function).  This must happen exactly once for each ao (and not if
+ *   the ao has been destroyed, obviously), and it may not happen
+ *   until libxl__ao_inprogress has been called on the ao.
+ *
+ * - Note that during callback functions, two gcs are available:
+ *    - The one in egc, whose lifetime is only this callback
+ *    - The one in ao, whose lifetime is the asynchronous operation
+ *   Usually callback function should use GET_CONTAINING_STRUCT
+ *   to obtain its own structure, containing a pointer to the ao,
+ *   and then use the gc from that ao.
+ */
+
+#define AO_CREATE(ctx, domid, ao_how)                           \
+    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
+    if (!ao) return ERROR_NOMEM;                                \
+    AO_GC;                                                      \
+    CTX_LOCK;
+
+#define AO_INPROGRESS do{                                       \
+        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        int ao__rc = libxl__ao_inprogress(ao);                  \
+        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
+        return ao__rc;                                          \
+   }while(0)
+        
+
+#define AO_ABORT(rc) do{                                        \
+        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        assert(rc);                                             \
+        assert(rc != ERROR_ASYNC_INPROGRESS);                   \
+        libxl__ao_abort(ao);                                    \
+        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
+        return (rc);                                            \
+    }while(0)
+
+#define AO_GC                                   \
+    libxl__gc *const gc = &ao->gc
+
+
+/* All of these MUST be called with the ctx locked.
+ * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
+_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
+                                    const libxl_asyncop_how*);
+_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden void libxl__ao_abort(libxl__ao *ao);
+_hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
+
+/* For use by ao machinery ONLY */
+_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+
+/*
  * Convenience macros.
  */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index a6dac79..325bb21 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -395,6 +395,7 @@ libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DESTROY"),
     (3, "DISK_EJECT"),
+    (4, "OPERATION_COMPLETE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -418,4 +419,7 @@ libxl_event = Struct("event",[
                                         ("vdev", string),
                                         ("disk", libxl_device_disk),
                                  ])),
+           ("operation_complete", Struct(None, [
+                                        ("rc", integer),
+                                 ])),
            ]))])
-- 
1.7.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 Jan 13 19:26:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlmlF-0003mc-13; Fri, 13 Jan 2012 19:26:01 +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 1RlmlD-0003j9-MP
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:26:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8604 invoked from network); 13 Jan 2012 19:25:53 -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 Jan 2012 19:25:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 19:25: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
	1Rlml6-0005pY-VT; Fri, 13 Jan 2012 19:25:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml6-0002oY-Re;
	Fri, 13 Jan 2012 19:25:52 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Jan 2012 19:25:27 +0000
Message-ID: <1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a new-style asynchronous facility for waiting for device
states on xenbus.  This will replace libxl__wait_for_device_state,
after the callers have been updated in later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   75 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   41 +++++++++++++++++++++++
 2 files changed, 116 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index b99049a..1d271b8 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -507,6 +507,81 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
 }
 
 /*
+ * waiting for device state
+ */
+
+static void devstate_watch_callback(libxl__egc *egc, libxl__ev_xswatch *watch,
+                                const char *watch_path, const char *event_path)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(watch, *ds, watch);
+    int rc;
+
+    char *sstate = libxl__xs_read(gc, XBT_NULL, watch_path);
+    if (!sstate) {
+        if (errno == ENOENT) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " but it was removed", watch_path, ds->wanted);
+            rc = ERROR_INVAL;
+        } else {
+            LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "backend %s wanted state"
+                             " %d but read failed", watch_path, ds->wanted);
+            rc = ERROR_FAIL;
+        }
+    } else {
+        int got = atoi(sstate);
+        if (got == ds->wanted) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d ok",
+                       watch_path, ds->wanted);
+            rc = 0;
+        } else {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " still waiting state %d", watch_path, ds->wanted, got);
+            return;
+        }
+    }
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, rc);
+}
+
+static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+               " timed out", ds->watch.path, ds->wanted);
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, ERROR_TIMEDOUT);
+}
+
+int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                            libxl__ev_devstate_callback cb,
+                            const char *state_path, int state, int milliseconds)
+{
+    int rc;
+
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+    ds->wanted = state;
+    ds->callback = cb;
+
+    rc = libxl__ev_time_register_rel(gc, &ds->timeout, devstate_timeout,
+                                     milliseconds);
+    if (rc) goto out;
+
+    rc = libxl__ev_xswatch_register(gc, &ds->watch, devstate_watch_callback,
+                                    state_path);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__ev_devstate_cancel(gc, ds);
+    return rc;
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 213b5f9..b7f0f54 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -684,6 +684,47 @@ _hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
                                          libxl__device_state_handler handler);
 
 /*
+ * libxl__ev_devstate - waits a given time for a device to
+ * reach a given state.  Follows the libxl_ev_* conventions.
+ * Will generate only one event, and after that is automatically
+ * cancelled.
+ */
+typedef struct libxl__ev_devstate libxl__ev_devstate;
+typedef void libxl__ev_devstate_callback(libxl__egc *egc, libxl__ev_devstate*,
+                                         int rc);
+  /* rc will be 0, ERROR_TIMEDOUT, ERROR_INVAL (meaning path was removed),
+   * or ERROR_FAIL if other stuff went wrong (in which latter case, logged) */
+
+struct libxl__ev_devstate {
+    /* read-only for caller, who may read only when waiting: */
+    int wanted;
+    libxl__ev_devstate_callback *callback;
+    /* as for the remainder, read-only public parts may also be
+     * read by the caller (notably, watch.path), but only when waiting: */
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+};
+
+static inline void libxl__ev_devstate_init(libxl__ev_devstate *ds)
+{
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+}
+
+static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
+                                             libxl__ev_devstate *ds)
+{
+    libxl__ev_time_deregister(gc,&ds->timeout);
+    libxl__ev_xswatch_deregister(gc,&ds->watch);
+}
+
+_hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                                    libxl__ev_devstate_callback cb,
+                                    const char *state_path,
+                                    int state, int milliseconds);
+
+
+/*
  * 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
-- 
1.7.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 Jan 13 19:26:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:26:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlmlF-0003mc-13; Fri, 13 Jan 2012 19:26:01 +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 1RlmlD-0003j9-MP
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:26:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8604 invoked from network); 13 Jan 2012 19:25:53 -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 Jan 2012 19:25:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013584"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 19:25: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
	1Rlml6-0005pY-VT; Fri, 13 Jan 2012 19:25:53 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml6-0002oY-Re;
	Fri, 13 Jan 2012 19:25:52 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 13 Jan 2012 19:25:27 +0000
Message-ID: <1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a new-style asynchronous facility for waiting for device
states on xenbus.  This will replace libxl__wait_for_device_state,
after the callers have been updated in later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   75 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   41 +++++++++++++++++++++++
 2 files changed, 116 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index b99049a..1d271b8 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -507,6 +507,81 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
 }
 
 /*
+ * waiting for device state
+ */
+
+static void devstate_watch_callback(libxl__egc *egc, libxl__ev_xswatch *watch,
+                                const char *watch_path, const char *event_path)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(watch, *ds, watch);
+    int rc;
+
+    char *sstate = libxl__xs_read(gc, XBT_NULL, watch_path);
+    if (!sstate) {
+        if (errno == ENOENT) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " but it was removed", watch_path, ds->wanted);
+            rc = ERROR_INVAL;
+        } else {
+            LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "backend %s wanted state"
+                             " %d but read failed", watch_path, ds->wanted);
+            rc = ERROR_FAIL;
+        }
+    } else {
+        int got = atoi(sstate);
+        if (got == ds->wanted) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d ok",
+                       watch_path, ds->wanted);
+            rc = 0;
+        } else {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " still waiting state %d", watch_path, ds->wanted, got);
+            return;
+        }
+    }
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, rc);
+}
+
+static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+               " timed out", ds->watch.path, ds->wanted);
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, ERROR_TIMEDOUT);
+}
+
+int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                            libxl__ev_devstate_callback cb,
+                            const char *state_path, int state, int milliseconds)
+{
+    int rc;
+
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+    ds->wanted = state;
+    ds->callback = cb;
+
+    rc = libxl__ev_time_register_rel(gc, &ds->timeout, devstate_timeout,
+                                     milliseconds);
+    if (rc) goto out;
+
+    rc = libxl__ev_xswatch_register(gc, &ds->watch, devstate_watch_callback,
+                                    state_path);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__ev_devstate_cancel(gc, ds);
+    return rc;
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 213b5f9..b7f0f54 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -684,6 +684,47 @@ _hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
                                          libxl__device_state_handler handler);
 
 /*
+ * libxl__ev_devstate - waits a given time for a device to
+ * reach a given state.  Follows the libxl_ev_* conventions.
+ * Will generate only one event, and after that is automatically
+ * cancelled.
+ */
+typedef struct libxl__ev_devstate libxl__ev_devstate;
+typedef void libxl__ev_devstate_callback(libxl__egc *egc, libxl__ev_devstate*,
+                                         int rc);
+  /* rc will be 0, ERROR_TIMEDOUT, ERROR_INVAL (meaning path was removed),
+   * or ERROR_FAIL if other stuff went wrong (in which latter case, logged) */
+
+struct libxl__ev_devstate {
+    /* read-only for caller, who may read only when waiting: */
+    int wanted;
+    libxl__ev_devstate_callback *callback;
+    /* as for the remainder, read-only public parts may also be
+     * read by the caller (notably, watch.path), but only when waiting: */
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+};
+
+static inline void libxl__ev_devstate_init(libxl__ev_devstate *ds)
+{
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+}
+
+static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
+                                             libxl__ev_devstate *ds)
+{
+    libxl__ev_time_deregister(gc,&ds->timeout);
+    libxl__ev_xswatch_deregister(gc,&ds->watch);
+}
+
+_hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                                    libxl__ev_devstate_callback cb,
+                                    const char *state_path,
+                                    int state, int milliseconds);
+
+
+/*
  * 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
-- 
1.7.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 Jan 13 19:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19: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 1RlmlJ-0003p2-Fn; Fri, 13 Jan 2012 19:26: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 1RlmlG-0003kF-KQ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:26:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8700 invoked from network); 13 Jan 2012 19:25:56 -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 Jan 2012 19:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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; Fri, 13 Jan 2012 19:25: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
	1Rlml9-0005pb-EJ; Fri, 13 Jan 2012 19:25:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml9-0002of-Ac;
	Fri, 13 Jan 2012 19:25:55 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:28 +0000
Message-ID: <1326482728-10733-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-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 9/9] libxl: Convert to asynchronous: device
	removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Convert libxl_FOO_device_remove, and the function which does the bulk
of the work, libxl__device_remove, to the new async ops scheme.

Adjust all callers.

Also remove libxl__wait_for_device_state which is now obsolete.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   60 +++++++++++++--------
 tools/libxl/libxl.h          |   16 ++++--
 tools/libxl/libxl_device.c   |  118 +++++++++++++-----------------------------
 tools/libxl/libxl_internal.h |   30 ++---------
 tools/libxl/xl_cmdimpl.c     |    4 +-
 5 files changed, 93 insertions(+), 135 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9890d79..d63da97 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1310,19 +1310,23 @@ out:
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
-                             libxl_device_disk *disk)
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -1536,11 +1540,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 
     ret = 0;
 
-    libxl_device_disk_remove(ctx, domid, disks + i);
+    libxl_device_disk_remove(ctx, domid, disks + i, 0);
     libxl_device_disk_add(ctx, domid, disk);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
-        libxl_device_disk_remove(ctx, stubdomid, disks + i);
+        libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
         libxl_device_disk_add(ctx, stubdomid, disk);
     }
 out:
@@ -1759,19 +1763,23 @@ out:
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_nic *nic)
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2099,19 +2107,23 @@ out:
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vkb *vkb)
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2216,19 +2228,23 @@ out:
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vfb *vfb)
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 416d6e8..602bd01 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -464,7 +464,9 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
 /* Disks */
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
-int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -488,7 +490,9 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 /* Network Interfaces */
 int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
-int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -498,13 +502,17 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 /* Keyboard */
 int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
-int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
-int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5d05e90..e905133 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -357,85 +357,41 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
-/*
- * Returns 0 if a device is removed, ERROR_* if an error
- * or timeout occurred.
- */
-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;
-    unsigned int n;
-    fd_set rfds;
-    char **l1 = NULL;
-
-start:
-    rc = 1;
-    nfds = xs_fileno(ctx->xsh) + 1;
-    FD_ZERO(&rfds);
-    FD_SET(xs_fileno(ctx->xsh), &rfds);
-    switch (select(nfds, &rfds, NULL, NULL, tv)) {
-        case -1:
-            if (errno == EINTR)
-                goto start;
-            rc = ERROR_FAIL;
-            break;
-        case 0:
-            rc = ERROR_TIMEDOUT;
-            break;
-        default:
-            l1 = xs_read_watch(ctx->xsh, &n);
-            if (l1 != NULL) {
-                char *sstate = libxl__xs_read(gc, XBT_NULL,
-                                             l1[XS_WATCH_PATH]);
-                if (!sstate || atoi(sstate) == state) {
-                    /* Call handler function if present */
-                    if (handler)
-                        rc = handler(gc, l1, sstate);
-                } else {
-                    /* State is different than expected, continue waiting... */
-                    goto start;
-                }
-                free(l1);
-            } else {
-                rc = ERROR_FAIL;
-            }
-            break;
-    }
-    return rc;
-}
 
-/*
- * 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]);
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+} libxl__ao_device_remove;
+
+static void device_remove_cleanup(libxl__gc *gc,
+                                  libxl__ao_device_remove *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
 
-    return 0;
+static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                   int rc) {
+    libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl__ao_complete(egc, aorm->ao, rc);
+    device_remove_cleanup(gc, aorm);
 }
 
-/*
- * Returns 0 (device already destroyed) or 1 (caller must
- * wait_for_dev_destroy) on success, ERROR_* on fail.
- */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
 {
+    /* Arranges that dev will be removed from its guest.  When
+     * this is done, the ao will be completed.  An error
+     * return from libxl__device_remove means that the ao
+     * will _not_ be completed and the caller must do so.
+     */
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state = libxl__xs_read(gc, XBT_NULL, state_path);
     int rc = 0;
+    libxl__ao_device_remove *aorm = 0;
 
     if (!state)
         goto out;
@@ -458,23 +414,21 @@ retry_transaction:
         }
     }
 
-    xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    libxl__ev_devstate_init(&aorm->ds);
 
-out:
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
+                                 state_path, XenbusStateClosed,
+                                 LIBXL_DESTROY_TIMEOUT * 1000);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    device_remove_cleanup(gc, aorm);
     return rc;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b7f0f54..9920fb9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -653,35 +653,15 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
-/* 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);
+/* Arranges that dev will be removed from its guest.  When
+ * this is done, the ao will be completed.  An error
+ * return from libxl__device_remove means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c2b7a1e..659a9e6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4624,7 +4624,7 @@ int main_networkdetach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_remove(ctx, domid, &nic)) {
+    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_del failed.\n");
         return 1;
     }
@@ -4719,7 +4719,7 @@ int main_blockdetach(int argc, char **argv)
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
     }
-    if (libxl_device_disk_remove(ctx, domid, &disk)) {
+    if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     }
     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 Jan 13 19:26:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19: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 1RlmlJ-0003p2-Fn; Fri, 13 Jan 2012 19:26: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 1RlmlG-0003kF-KQ
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:26:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326482733!10836526!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8700 invoked from network); 13 Jan 2012 19:25:56 -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 Jan 2012 19:25:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,505,1320624000"; d="scan'208";a="10013586"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 19:25: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; Fri, 13 Jan 2012 19:25: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
	1Rlml9-0005pb-EJ; Fri, 13 Jan 2012 19:25:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rlml9-0002of-Ac;
	Fri, 13 Jan 2012 19:25:55 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 13 Jan 2012 19:25:28 +0000
Message-ID: <1326482728-10733-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-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 9/9] libxl: Convert to asynchronous: device
	removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Convert libxl_FOO_device_remove, and the function which does the bulk
of the work, libxl__device_remove, to the new async ops scheme.

Adjust all callers.

Also remove libxl__wait_for_device_state which is now obsolete.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   60 +++++++++++++--------
 tools/libxl/libxl.h          |   16 ++++--
 tools/libxl/libxl_device.c   |  118 +++++++++++++-----------------------------
 tools/libxl/libxl_internal.h |   30 ++---------
 tools/libxl/xl_cmdimpl.c     |    4 +-
 5 files changed, 93 insertions(+), 135 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9890d79..d63da97 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1310,19 +1310,23 @@ out:
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
-                             libxl_device_disk *disk)
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -1536,11 +1540,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 
     ret = 0;
 
-    libxl_device_disk_remove(ctx, domid, disks + i);
+    libxl_device_disk_remove(ctx, domid, disks + i, 0);
     libxl_device_disk_add(ctx, domid, disk);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
-        libxl_device_disk_remove(ctx, stubdomid, disks + i);
+        libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
         libxl_device_disk_add(ctx, stubdomid, disk);
     }
 out:
@@ -1759,19 +1763,23 @@ out:
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_nic *nic)
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2099,19 +2107,23 @@ out:
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vkb *vkb)
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2216,19 +2228,23 @@ out:
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vfb *vfb)
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    AO_ABORT(rc);
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 416d6e8..602bd01 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -464,7 +464,9 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
 /* Disks */
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
-int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -488,7 +490,9 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 /* Network Interfaces */
 int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
-int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -498,13 +502,17 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 /* Keyboard */
 int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
-int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
-int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5d05e90..e905133 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -357,85 +357,41 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
-/*
- * Returns 0 if a device is removed, ERROR_* if an error
- * or timeout occurred.
- */
-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;
-    unsigned int n;
-    fd_set rfds;
-    char **l1 = NULL;
-
-start:
-    rc = 1;
-    nfds = xs_fileno(ctx->xsh) + 1;
-    FD_ZERO(&rfds);
-    FD_SET(xs_fileno(ctx->xsh), &rfds);
-    switch (select(nfds, &rfds, NULL, NULL, tv)) {
-        case -1:
-            if (errno == EINTR)
-                goto start;
-            rc = ERROR_FAIL;
-            break;
-        case 0:
-            rc = ERROR_TIMEDOUT;
-            break;
-        default:
-            l1 = xs_read_watch(ctx->xsh, &n);
-            if (l1 != NULL) {
-                char *sstate = libxl__xs_read(gc, XBT_NULL,
-                                             l1[XS_WATCH_PATH]);
-                if (!sstate || atoi(sstate) == state) {
-                    /* Call handler function if present */
-                    if (handler)
-                        rc = handler(gc, l1, sstate);
-                } else {
-                    /* State is different than expected, continue waiting... */
-                    goto start;
-                }
-                free(l1);
-            } else {
-                rc = ERROR_FAIL;
-            }
-            break;
-    }
-    return rc;
-}
 
-/*
- * 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]);
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+} libxl__ao_device_remove;
+
+static void device_remove_cleanup(libxl__gc *gc,
+                                  libxl__ao_device_remove *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
 
-    return 0;
+static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                   int rc) {
+    libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl__ao_complete(egc, aorm->ao, rc);
+    device_remove_cleanup(gc, aorm);
 }
 
-/*
- * Returns 0 (device already destroyed) or 1 (caller must
- * wait_for_dev_destroy) on success, ERROR_* on fail.
- */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
 {
+    /* Arranges that dev will be removed from its guest.  When
+     * this is done, the ao will be completed.  An error
+     * return from libxl__device_remove means that the ao
+     * will _not_ be completed and the caller must do so.
+     */
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state = libxl__xs_read(gc, XBT_NULL, state_path);
     int rc = 0;
+    libxl__ao_device_remove *aorm = 0;
 
     if (!state)
         goto out;
@@ -458,23 +414,21 @@ retry_transaction:
         }
     }
 
-    xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    libxl__ev_devstate_init(&aorm->ds);
 
-out:
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
+                                 state_path, XenbusStateClosed,
+                                 LIBXL_DESTROY_TIMEOUT * 1000);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    device_remove_cleanup(gc, aorm);
     return rc;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b7f0f54..9920fb9 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -653,35 +653,15 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
-/* 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);
+/* Arranges that dev will be removed from its guest.  When
+ * this is done, the ao will be completed.  An error
+ * return from libxl__device_remove means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c2b7a1e..659a9e6 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4624,7 +4624,7 @@ int main_networkdetach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_remove(ctx, domid, &nic)) {
+    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_del failed.\n");
         return 1;
     }
@@ -4719,7 +4719,7 @@ int main_blockdetach(int argc, char **argv)
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
     }
-    if (libxl_device_disk_remove(ctx, domid, &disk)) {
+    if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     }
     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 Jan 13 19:57:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlnFU-0005Np-GY; Fri, 13 Jan 2012 19:57:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RlnFT-0005Nh-Go
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:57:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326484628!2114528!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI2MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI2MTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23137 invoked from network); 13 Jan 2012 19:57:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 19:57:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326484628; l=1003;
	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=+rsrv7teDxJF0OOOaMeUeLDuJUA=;
	b=S+HzMhhz+GdBepih4WLnkKW0EomChHomBKDqqjPsncPhS1cGzmx/QflpTCOWtmbHXYo
	mPkGXg/hr694wpWpbQHjHiODq9gdA4U/DNaHDL2k+DrPNbXKJ2vuOM/SFowgookbRVSzW
	W1tbm9Es+5OcI4ho+5kZLtErZQQ02YROQXQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhi0PFa/V
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-098-169.pools.arcor-ip.net [88.65.98.169])
	by smtp.strato.de (cohen mo7) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 6026b6o0DJscCZ ;
	Fri, 13 Jan 2012 20:57:07 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id EC78118637; Fri, 13 Jan 2012 20:57:06 +0100 (CET)
Date: Fri, 13 Jan 2012 20:57:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120113195706.GA26566@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
	<873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <873a666b95bbe7e50992fb1059bc2220.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Fri, Jan 13, Andres Lagar-Cavilla wrote:

> > p2m_mem_paging_drop_page() should remain void because the caller has
> > already done its work, making it not restartable. Also it is only called
> > when a gfn is in paging state, which I'm sure can not happen without a
> > ring.
> 
> Well, the rationale is that returning an error code can only help, should
> new error conditions arise. Keep in mind that the pager and the ring can
> disappear at any time, so ENOSYS can still happen.

The ring should rather not disappear at all until ->paged_pages drops to
zero. Unless the goal is a restartable pager,
XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when
->pages_pages is not zero. Then the checks in drop_page and populate can
be relaxed.

> I'll refresh and add your signed-off-by to cover the portions of the work
> that originate from your end, is that ok?

I havent finish the review yet, have to check how it may work with wait
queues in gfn_to_mfn*.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 19:57:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 19:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlnFU-0005Np-GY; Fri, 13 Jan 2012 19:57:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RlnFT-0005Nh-Go
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 19:57:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326484628!2114528!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI2MTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI2MTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23137 invoked from network); 13 Jan 2012 19:57:09 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 19:57:09 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326484628; l=1003;
	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=+rsrv7teDxJF0OOOaMeUeLDuJUA=;
	b=S+HzMhhz+GdBepih4WLnkKW0EomChHomBKDqqjPsncPhS1cGzmx/QflpTCOWtmbHXYo
	mPkGXg/hr694wpWpbQHjHiODq9gdA4U/DNaHDL2k+DrPNbXKJ2vuOM/SFowgookbRVSzW
	W1tbm9Es+5OcI4ho+5kZLtErZQQ02YROQXQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhi0PFa/V
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-098-169.pools.arcor-ip.net [88.65.98.169])
	by smtp.strato.de (cohen mo7) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 6026b6o0DJscCZ ;
	Fri, 13 Jan 2012 20:57:07 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id EC78118637; Fri, 13 Jan 2012 20:57:06 +0100 (CET)
Date: Fri, 13 Jan 2012 20:57:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120113195706.GA26566@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
	<873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <873a666b95bbe7e50992fb1059bc2220.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Fri, Jan 13, Andres Lagar-Cavilla wrote:

> > p2m_mem_paging_drop_page() should remain void because the caller has
> > already done its work, making it not restartable. Also it is only called
> > when a gfn is in paging state, which I'm sure can not happen without a
> > ring.
> 
> Well, the rationale is that returning an error code can only help, should
> new error conditions arise. Keep in mind that the pager and the ring can
> disappear at any time, so ENOSYS can still happen.

The ring should rather not disappear at all until ->paged_pages drops to
zero. Unless the goal is a restartable pager,
XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when
->pages_pages is not zero. Then the checks in drop_page and populate can
be relaxed.

> I'll refresh and add your signed-off-by to cover the portions of the work
> that originate from your end, is that ok?

I havent finish the review yet, have to check how it may work with wait
queues in gfn_to_mfn*.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 20:06:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 20:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlnNZ-0005dW-Lt; Fri, 13 Jan 2012 20:05:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RlnNV-0005dQ-WD
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 20:05:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326485127!10945151!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTcyODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12869 invoked from network); 13 Jan 2012 20:05:27 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-12.tower-216.messagelabs.com with SMTP;
	13 Jan 2012 20:05:27 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id CD99A604078;
	Fri, 13 Jan 2012 12:05: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=WffTJVFpxI3prMy7gUL0vBzD52rUBBCcAZzaA8J4ZdOy
	UW31+IN7Z5BlYLQdXSwXW0mUTnM5BVuOxhXYB7iqP+A+jZ28MKTpz5Lin5zy+h1C
	6jgVNNEdxPQTSkN8vn6R6023ij8JZGba+lKxvRkiOun99R6SPUr++6IVGK4qCD0=
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=gSzo5ZxiQnu7KBcni5DJziHq9yQ=; b=DdCEPW9i
	RsO+U+/fxPMO+1E1kNQa0nBTT06wuzr5y3Y1L0KFigGkjMZBPKtJreNupRLNIdO3
	i7S5JwRF/X+u7sK2JdnYULVrobFFjPljDmfhCUFAkIkBhGb/2w9ZLKIHYQpBW1Nx
	lm/Bn3E/jXoDFjk3quaFls7qkhCfCRXAJRE=
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 2EC1A604061; 
	Fri, 13 Jan 2012 12:05:23 -0800 (PST)
Received: from 75.119.234.254 (proxying for 75.119.234.254)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Jan 2012 12:05:23 -0800
Message-ID: <c7c228ea2fa1f07ffbdfbb167bec5152.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120113195706.GA26566@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
	<873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
	<20120113195706.GA26566@aepfle.de>
Date: Fri, 13 Jan 2012 12:05:23 -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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Fri, Jan 13, Andres Lagar-Cavilla wrote:
>
>> > p2m_mem_paging_drop_page() should remain void because the caller has
>> > already done its work, making it not restartable. Also it is only
>> called
>> > when a gfn is in paging state, which I'm sure can not happen without a
>> > ring.
>>
>> Well, the rationale is that returning an error code can only help,
>> should
>> new error conditions arise. Keep in mind that the pager and the ring can
>> disappear at any time, so ENOSYS can still happen.
>
> The ring should rather not disappear at all until ->paged_pages drops to
> zero. Unless the goal is a restartable pager,
> XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when
> ->pages_pages is not zero. Then the checks in drop_page and populate can
> be relaxed.

Well, there are two separate things here. Should drop return an error
code? No harm in that. Then there is your point about the ring not going
away if ->paged_pages is nonzero. Which I like, but is currently not
implemented, afaict. Separate patch I guess.

>
>> I'll refresh and add your signed-off-by to cover the portions of the
>> work
>> that originate from your end, is that ok?
>
> I havent finish the review yet, have to check how it may work with wait
> queues in gfn_to_mfn*.

Another case of "the two separate things" :) We definitely look forward to
wait queue support for gfn_to_mfn*. But that's a separate consumer of the
wait queue feature. Are you worried that this patch might break your
gfn_to_mfn* strategy? We did base it on your work.

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 Fri Jan 13 20:06:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 20:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlnNZ-0005dW-Lt; Fri, 13 Jan 2012 20:05:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RlnNV-0005dQ-WD
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 20:05:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326485127!10945151!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTcyODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12869 invoked from network); 13 Jan 2012 20:05:27 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-12.tower-216.messagelabs.com with SMTP;
	13 Jan 2012 20:05:27 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id CD99A604078;
	Fri, 13 Jan 2012 12:05: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=WffTJVFpxI3prMy7gUL0vBzD52rUBBCcAZzaA8J4ZdOy
	UW31+IN7Z5BlYLQdXSwXW0mUTnM5BVuOxhXYB7iqP+A+jZ28MKTpz5Lin5zy+h1C
	6jgVNNEdxPQTSkN8vn6R6023ij8JZGba+lKxvRkiOun99R6SPUr++6IVGK4qCD0=
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=gSzo5ZxiQnu7KBcni5DJziHq9yQ=; b=DdCEPW9i
	RsO+U+/fxPMO+1E1kNQa0nBTT06wuzr5y3Y1L0KFigGkjMZBPKtJreNupRLNIdO3
	i7S5JwRF/X+u7sK2JdnYULVrobFFjPljDmfhCUFAkIkBhGb/2w9ZLKIHYQpBW1Nx
	lm/Bn3E/jXoDFjk3quaFls7qkhCfCRXAJRE=
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 2EC1A604061; 
	Fri, 13 Jan 2012 12:05:23 -0800 (PST)
Received: from 75.119.234.254 (proxying for 75.119.234.254)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Fri, 13 Jan 2012 12:05:23 -0800
Message-ID: <c7c228ea2fa1f07ffbdfbb167bec5152.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120113195706.GA26566@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
	<873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
	<20120113195706.GA26566@aepfle.de>
Date: Fri, 13 Jan 2012 12:05:23 -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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Fri, Jan 13, Andres Lagar-Cavilla wrote:
>
>> > p2m_mem_paging_drop_page() should remain void because the caller has
>> > already done its work, making it not restartable. Also it is only
>> called
>> > when a gfn is in paging state, which I'm sure can not happen without a
>> > ring.
>>
>> Well, the rationale is that returning an error code can only help,
>> should
>> new error conditions arise. Keep in mind that the pager and the ring can
>> disappear at any time, so ENOSYS can still happen.
>
> The ring should rather not disappear at all until ->paged_pages drops to
> zero. Unless the goal is a restartable pager,
> XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when
> ->pages_pages is not zero. Then the checks in drop_page and populate can
> be relaxed.

Well, there are two separate things here. Should drop return an error
code? No harm in that. Then there is your point about the ring not going
away if ->paged_pages is nonzero. Which I like, but is currently not
implemented, afaict. Separate patch I guess.

>
>> I'll refresh and add your signed-off-by to cover the portions of the
>> work
>> that originate from your end, is that ok?
>
> I havent finish the review yet, have to check how it may work with wait
> queues in gfn_to_mfn*.

Another case of "the two separate things" :) We definitely look forward to
wait queue support for gfn_to_mfn*. But that's a separate consumer of the
wait queue feature. Are you worried that this patch might break your
gfn_to_mfn* strategy? We did base it on your work.

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 Fri Jan 13 21:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 21:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlots-0006XN-NH; Fri, 13 Jan 2012 21:43: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 1Rlotr-0006XI-Bv
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 21:43:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326490915!8769048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTExOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9401 invoked from network); 13 Jan 2012 21:41:55 -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;
	13 Jan 2012 21:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,506,1320624000"; d="scan'208";a="10014865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 21:41: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, 13 Jan 2012 21:41: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 1Rlosk-0006aI-AA;
	Fri, 13 Jan 2012 21:41:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlosk-00063p-68;
	Fri, 13 Jan 2012 21:41:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10681-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 21:41:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10681: 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 10681 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10681/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           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-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-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 13 21:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 21:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlots-0006XN-NH; Fri, 13 Jan 2012 21:43: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 1Rlotr-0006XI-Bv
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 21:43:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326490915!8769048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTExOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9401 invoked from network); 13 Jan 2012 21:41:55 -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;
	13 Jan 2012 21:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,506,1320624000"; d="scan'208";a="10014865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 21:41: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, 13 Jan 2012 21:41: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 1Rlosk-0006aI-AA;
	Fri, 13 Jan 2012 21:41:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlosk-00063p-68;
	Fri, 13 Jan 2012 21:41:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10681-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 21:41:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10681: 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 10681 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10681/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           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-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-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 13 22:28:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 22:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlpbI-00074t-8k; Fri, 13 Jan 2012 22:27:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RlpbG-00074o-OK
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 22:27:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326493626!50178800!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5MzYwNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30387 invoked from network); 13 Jan 2012 22:27:07 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 22:27:07 -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
	q0DMQrom031491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Jan 2012 22:26: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
	q0DMQm3l020451
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2012 22:26:52 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
	q0DMQjmW006573; Fri, 13 Jan 2012 16:26:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Jan 2012 14:26:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 951884030F; Fri, 13 Jan 2012 17:24:51 -0500 (EST)
Date: Fri, 13 Jan 2012 17:24:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>, liang tang <liang.tang@oracle.com>
Message-ID: <20120113222451.GA6922@phenom.dumpdata.com>
References: <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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F10AFAE.00CC,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@citrix.com" <Ian.Campbell@citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"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 Rzeszutek Wilk <konrad@darnok.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

> > > sure. VCPU!=PCPU requirement is orthogonal to the basic part for gearing
> > > ACPI information to Xen.

.. snip..
> > >
> > > >  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).

.. snip..

> yes, this is a big question. First, I'd like to give my sincere thanks to you and
> Liang for help push this part to Linux upstream. You've done a great job. :-)

Thanks!
> Unfortunately I can't afford the time in the short term, due to extremely busy
> tasks in other projects, at least in the whole Q1. Really sorry about that. :/

Bummer.
> 
> I would very appreciate your help if you could continue lending some time here,
> since you've done plenty of works on the cleanup. The majority of the tricky 
> part is related to VCPU/PCPU handling. If putting that part aside, the remaining 
> logic should be much simpler.

I was trying to figure out how difficult it would be to just bring Pxx states to
the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
be enabled in the hypercall to make this work), it demonstrates what I had in mind.


#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
#include <acpi/processor.h>
#include <linux/cpumask.h>

#include <xen/interface/platform.h>
#include <asm/xen/hypercall.h>

#define DRV_NAME	"ACPI_PXX"
#define DRV_CLASS	"ACPI_PXX_CLASS"
MODULE_AUTHOR("Konrad Rzeszutek Wilk");
MODULE_DESCRIPTION("ACPI Processor Driver to send data to Xen hypervisor");
MODULE_LICENSE("GPL");

static int parse_acpi_cxx(struct acpi_processor *_pr)
{
	struct acpi_processor_cx *cx;
	int i;

	for (i = 1; i <= _pr->power.count; i++) {
		cx = &_pr->power.states[i];
		if (!cx->valid)
			continue;
		pr_info("%s: %d %d %d 0x%x\n", __func__,
			cx->type, cx->latency, cx->power, (u32)cx->address);
	}
	/* TODO: Under Xen, the C-states information is not present.
 	 * Figure out why. */
	return 0;
}
static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
{
	int ret = -EINVAL;
	struct xen_platform_op op = {
		.cmd			= XENPF_set_processor_pminfo,
		.interface_version	= XENPF_INTERFACE_VERSION,
		.u.set_pminfo.id	= _pr->acpi_id,
		.u.set_pminfo.type	= XEN_PM_PX,
	};
	struct xen_processor_performance *xen_perf;
	struct xen_processor_px *xen_states, *xen_px = NULL;
	struct acpi_processor_px *px;
	unsigned i;

	xen_perf = &op.u.set_pminfo.perf;
	xen_perf->flags = XEN_PX_PSS;

	xen_perf->state_count = _pr->performance->state_count;
	xen_states = kzalloc(xen_perf->state_count *
			     sizeof(struct xen_processor_px), GFP_KERNEL);
	if (!xen_states)
		return -ENOMEM;

	for (i = 0; i < _pr->performance->state_count; i++) {
		xen_px = &(xen_states[i]);
		px = &(_pr->performance->states[i]);

		xen_px->core_frequency = px->core_frequency;
		xen_px->power = px->power;
		xen_px->transition_latency = px->transition_latency;
		xen_px->bus_master_latency = px->bus_master_latency;
		xen_px->control = px->control;
		xen_px->status = px->status;
	}
	set_xen_guest_handle(xen_perf->states, xen_states);
	ret = HYPERVISOR_dom0_op(&op);
	kfree(xen_states);
	return ret;
}
static int parse_acpi_pxx(struct acpi_processor *_pr)
{
	struct acpi_processor_px *px;
	int i;

	for (i = 0; i < _pr->performance->state_count;i++) {
		px = &(_pr->performance->states[i]);
		pr_info("%s: [%d]: %d, %d, %d, %d, %d, %d\n", __func__,
			i, (u32)px->core_frequency, (u32)px->power,
			(u32)px->transition_latency,
			(u32)px->bus_master_latency,
			(u32)px->control, (u32)px->status);
	}
	if (xen_initial_domain())
		return push_pxx_to_hypervisor(_pr);
	return 0;
}
static int parse_acpi_data(void)
{
	int cpu;
	int err = -ENODEV;
	struct acpi_processor *_pr;
	struct cpuinfo_x86 *c = &cpu_data(0);

	/* TODO: Under AMD, the information is populated
	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
	 * MSR which returns the wrong value so the population of 'processors'
	 * has bogus data. So only run this under Intel for right now. */
	if (!cpu_has(c, X86_FEATURE_EST))
		return -ENODEV;
	for_each_possible_cpu(cpu) {
		_pr = per_cpu(processors, cpu);
		if (!_pr)
			continue;

		if (_pr->flags.power)
			(void)parse_acpi_cxx(_pr);

		if (_pr->performance->states)
			err = parse_acpi_pxx(_pr);
		if (err)
			break;
	}
	return -ENODEV; /* force it to unload */
}
static int __init acpi_pxx_init(void)
{
	return parse_acpi_data();
}
static void __exit acpi_pxx_exit(void)
{
}
module_init(acpi_pxx_init);
module_exit(acpi_pxx_exit);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 13 22:28:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 13 Jan 2012 22:28:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlpbI-00074t-8k; Fri, 13 Jan 2012 22:27:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RlpbG-00074o-OK
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 22:27:55 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326493626!50178800!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5MzYwNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30387 invoked from network); 13 Jan 2012 22:27:07 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 13 Jan 2012 22:27:07 -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
	q0DMQrom031491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 13 Jan 2012 22:26: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
	q0DMQm3l020451
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 13 Jan 2012 22:26:52 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
	q0DMQjmW006573; Fri, 13 Jan 2012 16:26:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 13 Jan 2012 14:26:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 951884030F; Fri, 13 Jan 2012 17:24:51 -0500 (EST)
Date: Fri, 13 Jan 2012 17:24:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>, liang tang <liang.tang@oracle.com>
Message-ID: <20120113222451.GA6922@phenom.dumpdata.com>
References: <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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F10AFAE.00CC,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@citrix.com" <Ian.Campbell@citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>,
	"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 Rzeszutek Wilk <konrad@darnok.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

> > > sure. VCPU!=PCPU requirement is orthogonal to the basic part for gearing
> > > ACPI information to Xen.

.. snip..
> > >
> > > >  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).

.. snip..

> yes, this is a big question. First, I'd like to give my sincere thanks to you and
> Liang for help push this part to Linux upstream. You've done a great job. :-)

Thanks!
> Unfortunately I can't afford the time in the short term, due to extremely busy
> tasks in other projects, at least in the whole Q1. Really sorry about that. :/

Bummer.
> 
> I would very appreciate your help if you could continue lending some time here,
> since you've done plenty of works on the cleanup. The majority of the tricky 
> part is related to VCPU/PCPU handling. If putting that part aside, the remaining 
> logic should be much simpler.

I was trying to figure out how difficult it would be to just bring Pxx states to
the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
be enabled in the hypercall to make this work), it demonstrates what I had in mind.


#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
#include <acpi/processor.h>
#include <linux/cpumask.h>

#include <xen/interface/platform.h>
#include <asm/xen/hypercall.h>

#define DRV_NAME	"ACPI_PXX"
#define DRV_CLASS	"ACPI_PXX_CLASS"
MODULE_AUTHOR("Konrad Rzeszutek Wilk");
MODULE_DESCRIPTION("ACPI Processor Driver to send data to Xen hypervisor");
MODULE_LICENSE("GPL");

static int parse_acpi_cxx(struct acpi_processor *_pr)
{
	struct acpi_processor_cx *cx;
	int i;

	for (i = 1; i <= _pr->power.count; i++) {
		cx = &_pr->power.states[i];
		if (!cx->valid)
			continue;
		pr_info("%s: %d %d %d 0x%x\n", __func__,
			cx->type, cx->latency, cx->power, (u32)cx->address);
	}
	/* TODO: Under Xen, the C-states information is not present.
 	 * Figure out why. */
	return 0;
}
static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
{
	int ret = -EINVAL;
	struct xen_platform_op op = {
		.cmd			= XENPF_set_processor_pminfo,
		.interface_version	= XENPF_INTERFACE_VERSION,
		.u.set_pminfo.id	= _pr->acpi_id,
		.u.set_pminfo.type	= XEN_PM_PX,
	};
	struct xen_processor_performance *xen_perf;
	struct xen_processor_px *xen_states, *xen_px = NULL;
	struct acpi_processor_px *px;
	unsigned i;

	xen_perf = &op.u.set_pminfo.perf;
	xen_perf->flags = XEN_PX_PSS;

	xen_perf->state_count = _pr->performance->state_count;
	xen_states = kzalloc(xen_perf->state_count *
			     sizeof(struct xen_processor_px), GFP_KERNEL);
	if (!xen_states)
		return -ENOMEM;

	for (i = 0; i < _pr->performance->state_count; i++) {
		xen_px = &(xen_states[i]);
		px = &(_pr->performance->states[i]);

		xen_px->core_frequency = px->core_frequency;
		xen_px->power = px->power;
		xen_px->transition_latency = px->transition_latency;
		xen_px->bus_master_latency = px->bus_master_latency;
		xen_px->control = px->control;
		xen_px->status = px->status;
	}
	set_xen_guest_handle(xen_perf->states, xen_states);
	ret = HYPERVISOR_dom0_op(&op);
	kfree(xen_states);
	return ret;
}
static int parse_acpi_pxx(struct acpi_processor *_pr)
{
	struct acpi_processor_px *px;
	int i;

	for (i = 0; i < _pr->performance->state_count;i++) {
		px = &(_pr->performance->states[i]);
		pr_info("%s: [%d]: %d, %d, %d, %d, %d, %d\n", __func__,
			i, (u32)px->core_frequency, (u32)px->power,
			(u32)px->transition_latency,
			(u32)px->bus_master_latency,
			(u32)px->control, (u32)px->status);
	}
	if (xen_initial_domain())
		return push_pxx_to_hypervisor(_pr);
	return 0;
}
static int parse_acpi_data(void)
{
	int cpu;
	int err = -ENODEV;
	struct acpi_processor *_pr;
	struct cpuinfo_x86 *c = &cpu_data(0);

	/* TODO: Under AMD, the information is populated
	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
	 * MSR which returns the wrong value so the population of 'processors'
	 * has bogus data. So only run this under Intel for right now. */
	if (!cpu_has(c, X86_FEATURE_EST))
		return -ENODEV;
	for_each_possible_cpu(cpu) {
		_pr = per_cpu(processors, cpu);
		if (!_pr)
			continue;

		if (_pr->flags.power)
			(void)parse_acpi_cxx(_pr);

		if (_pr->performance->states)
			err = parse_acpi_pxx(_pr);
		if (err)
			break;
	}
	return -ENODEV; /* force it to unload */
}
static int __init acpi_pxx_init(void)
{
	return parse_acpi_data();
}
static void __exit acpi_pxx_exit(void)
{
}
module_init(acpi_pxx_init);
module_exit(acpi_pxx_exit);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 14 00:00:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 00:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlr1m-0007aZ-Bn; Fri, 13 Jan 2012 23:59: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 1Rlr1k-0007aU-Jf
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 23:59:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326499154!10850415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7071 invoked from network); 13 Jan 2012 23:59:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 23:59:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,507,1320624000"; d="scan'208";a="10015728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 23:59:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 23:59: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 1Rlr1d-0007M6-La;
	Fri, 13 Jan 2012 23:59:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlr1d-0007We-KZ;
	Fri, 13 Jan 2012 23:59:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10683-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 23:59:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10683: 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 10683 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10683/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10679
 test-amd64-amd64-xl-winxpsp3  7 windows-install             fail pass in 10679
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10679 pass in 10683

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10679 REGR. vs. 10533

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-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-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-i386-win          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-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   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 in 10679 never pass

version targeted for testing:
 xen                  22ea8496051d
baseline version:
 xen                  14dbd6be46c8

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Michael Young <m.a.young@durham.ac.uk>
  Paolo Bonzini <pbonzini@redhat.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


Pushing revision :

+ branch=xen-4.1-testing
+ revision=22ea8496051d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 22ea8496051d
+ branch=xen-4.1-testing
+ revision=22ea8496051d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 22ea8496051d 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 7 changesets with 8 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 14 00:00:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 00:00:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlr1m-0007aZ-Bn; Fri, 13 Jan 2012 23:59: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 1Rlr1k-0007aU-Jf
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 23:59:20 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326499154!10850415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7071 invoked from network); 13 Jan 2012 23:59:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 23:59:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,507,1320624000"; d="scan'208";a="10015728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	13 Jan 2012 23:59:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 13 Jan 2012 23:59: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 1Rlr1d-0007M6-La;
	Fri, 13 Jan 2012 23:59:13 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlr1d-0007We-KZ;
	Fri, 13 Jan 2012 23:59:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10683-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 13 Jan 2012 23:59:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10683: 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 10683 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10683/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf     10 guest-saverestore           fail pass in 10679
 test-amd64-amd64-xl-winxpsp3  7 windows-install             fail pass in 10679
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10679 pass in 10683

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf 14 guest-localmigrate/x10 fail in 10679 REGR. vs. 10533

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-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-i386-i386-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-i386-win          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-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   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 in 10679 never pass

version targeted for testing:
 xen                  22ea8496051d
baseline version:
 xen                  14dbd6be46c8

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Michael Young <m.a.young@durham.ac.uk>
  Paolo Bonzini <pbonzini@redhat.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


Pushing revision :

+ branch=xen-4.1-testing
+ revision=22ea8496051d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 22ea8496051d
+ branch=xen-4.1-testing
+ revision=22ea8496051d
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 22ea8496051d 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 7 changesets with 8 changes to 5 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 14 00:44:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 00:44:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlriv-0008Vi-Ot; Sat, 14 Jan 2012 00:43:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rlriu-0008Vd-Di
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 00:43:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326501829!9087262!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16176 invoked from network); 14 Jan 2012 00:43:50 -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;
	14 Jan 2012 00:43:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,507,1320624000"; d="scan'208";a="10016003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 00:43:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Jan 2012 00:43: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 1Rlrin-0007bX-3K;
	Sat, 14 Jan 2012 00:43:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlrin-0000zo-2Q;
	Sat, 14 Jan 2012 00:43:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Rlrin-0000zo-2Q@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 00:43:49 +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://xenbits.xen.org/staging/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:  86b8a1e3a419
  Bug not present: c5eadfd5c639


  changeset:   24503:86b8a1e3a419
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Jan 13 08:33:31 2012 +0100
      
      force inclusion of xen/config.h through compiler option
      
      As we expect all source files to include the header as the first thing
      anyway, stop doing this by repeating the inclusion in each and every
      source file (and in many headers), but rather enforce this uniformly
      through the compiler command line.
      
      As a first cleanup step, remove the explicit inclusion from all common
      headers. Further cleanup can be done incrementally.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10681 fail [host=leaf-beetle] / 10649 [host=itch-mite] 10646 [host=itch-mite] 10645 [host=itch-mite] 10644 [host=itch-mite] 10643 [host=lace-bug] 10642 [host=lace-bug] 10641 [host=itch-mite] 10640 [host=itch-mite] 10639 [host=itch-mite] 10636 [host=potato-beetle] 10635 [host=itch-mite] 10632 [host=itch-mite] 10631 [host=itch-mite] 10630 [host=potato-beetle] 10629 [host=itch-mite] 10628 [host=itch-mite] 10623 [host=moss-bug] 10622 [host=itch-mite] 10621 ok.
Failure / basis pass flights: 10681 / 10621
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
Basis pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/staging/qemu-xen-unstable.git#56d7747a3cf811910c4cf865e1ebcb8b82502005-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#a7b2610b8e5c-6d8888519e3a
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-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://xenbits.xen.org/staging/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 1023 nodes in revision graph
Searching for test results:
 10613 [host=moss-bug]
 10620 [host=moss-bug]
 10618 [host=moss-bug]
 10614 pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
 10617 pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
 10619 [host=moss-bug]
 10621 pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
 10622 [host=itch-mite]
 10625 [host=woodlouse]
 10623 [host=moss-bug]
 10628 [host=itch-mite]
 10629 [host=itch-mite]
 10630 [host=potato-beetle]
 10631 [host=itch-mite]
 10632 [host=itch-mite]
 10634 [host=earwig]
 10682 pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
 10635 [host=itch-mite]
 10636 [host=potato-beetle]
 10684 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 6f5fff70668b
 10685 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 7bc8cf556c0c
 10639 [host=itch-mite]
 10640 [host=itch-mite]
 10686 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 8d2fa20dd3f3
 10641 [host=itch-mite]
 10642 [host=lace-bug]
 10687 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 9db6fe19dd04
 10643 [host=lace-bug]
 10644 [host=itch-mite]
 10688 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 80765dec9616
 10681 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10645 [host=itch-mite]
 10648 [host=potato-beetle]
 10646 [host=itch-mite]
 10690 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10649 [host=itch-mite]
 10691 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10680 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 6f5fff70668b
 10692 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10693 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10694 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10695 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10696 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
Searching for interesting versions
 Result found: flight 10614 (pass), for basis pass
 Result found: flight 10681 (fail), for basis failure
 Repro found: flight 10682 (pass), for basis pass
 Repro found: flight 10690 (fail), for basis failure
 0 revisions at bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
No revisions left to test, checking graph state.
 Result found: flight 10691 (pass), for last pass
 Result found: flight 10692 (fail), for first failure
 Repro found: flight 10693 (pass), for last pass
 Repro found: flight 10694 (fail), for first failure
 Repro found: flight 10695 (pass), for last pass
 Repro found: flight 10696 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  86b8a1e3a419
  Bug not present: c5eadfd5c639

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24503:86b8a1e3a419
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Jan 13 08:33:31 2012 +0100
      
      force inclusion of xen/config.h through compiler option
      
      As we expect all source files to include the header as the first thing
      anyway, stop doing this by repeating the inclusion in each and every
      source file (and in many headers), but rather enforce this uniformly
      through the compiler command line.
      
      As a first cleanup step, remove the explicit inclusion from all common
      headers. Further cleanup can be done incrementally.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}.
----------------------------------------
10696: ALL FAIL

flight 10696 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10696/


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 Sat Jan 14 00:44:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 00:44:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rlriv-0008Vi-Ot; Sat, 14 Jan 2012 00:43:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rlriu-0008Vd-Di
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 00:43:56 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326501829!9087262!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTAyMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16176 invoked from network); 14 Jan 2012 00:43:50 -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;
	14 Jan 2012 00:43:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,507,1320624000"; d="scan'208";a="10016003"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 00:43:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Jan 2012 00:43: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 1Rlrin-0007bX-3K;
	Sat, 14 Jan 2012 00:43:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlrin-0000zo-2Q;
	Sat, 14 Jan 2012 00:43:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Rlrin-0000zo-2Q@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 00:43:49 +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://xenbits.xen.org/staging/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:  86b8a1e3a419
  Bug not present: c5eadfd5c639


  changeset:   24503:86b8a1e3a419
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Jan 13 08:33:31 2012 +0100
      
      force inclusion of xen/config.h through compiler option
      
      As we expect all source files to include the header as the first thing
      anyway, stop doing this by repeating the inclusion in each and every
      source file (and in many headers), but rather enforce this uniformly
      through the compiler command line.
      
      As a first cleanup step, remove the explicit inclusion from all common
      headers. Further cleanup can be done incrementally.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10681 fail [host=leaf-beetle] / 10649 [host=itch-mite] 10646 [host=itch-mite] 10645 [host=itch-mite] 10644 [host=itch-mite] 10643 [host=lace-bug] 10642 [host=lace-bug] 10641 [host=itch-mite] 10640 [host=itch-mite] 10639 [host=itch-mite] 10636 [host=potato-beetle] 10635 [host=itch-mite] 10632 [host=itch-mite] 10631 [host=itch-mite] 10630 [host=potato-beetle] 10629 [host=itch-mite] 10628 [host=itch-mite] 10623 [host=moss-bug] 10622 [host=itch-mite] 10621 ok.
Failure / basis pass flights: 10681 / 10621
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
Basis pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/staging/qemu-xen-unstable.git#56d7747a3cf811910c4cf865e1ebcb8b82502005-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#a7b2610b8e5c-6d8888519e3a
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-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://xenbits.xen.org/staging/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 1023 nodes in revision graph
Searching for test results:
 10613 [host=moss-bug]
 10620 [host=moss-bug]
 10618 [host=moss-bug]
 10614 pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
 10617 pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
 10619 [host=moss-bug]
 10621 pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
 10622 [host=itch-mite]
 10625 [host=woodlouse]
 10623 [host=moss-bug]
 10628 [host=itch-mite]
 10629 [host=itch-mite]
 10630 [host=potato-beetle]
 10631 [host=itch-mite]
 10632 [host=itch-mite]
 10634 [host=earwig]
 10682 pass 56d7747a3cf811910c4cf865e1ebcb8b82502005 a7b2610b8e5c
 10635 [host=itch-mite]
 10636 [host=potato-beetle]
 10684 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 6f5fff70668b
 10685 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 7bc8cf556c0c
 10639 [host=itch-mite]
 10640 [host=itch-mite]
 10686 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 8d2fa20dd3f3
 10641 [host=itch-mite]
 10642 [host=lace-bug]
 10687 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 9db6fe19dd04
 10643 [host=lace-bug]
 10644 [host=itch-mite]
 10688 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 80765dec9616
 10681 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10645 [host=itch-mite]
 10648 [host=potato-beetle]
 10646 [host=itch-mite]
 10690 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10649 [host=itch-mite]
 10691 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10680 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 6f5fff70668b
 10692 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10693 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10694 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10695 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10696 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
Searching for interesting versions
 Result found: flight 10614 (pass), for basis pass
 Result found: flight 10681 (fail), for basis failure
 Repro found: flight 10682 (pass), for basis pass
 Repro found: flight 10690 (fail), for basis failure
 0 revisions at bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
No revisions left to test, checking graph state.
 Result found: flight 10691 (pass), for last pass
 Result found: flight 10692 (fail), for first failure
 Repro found: flight 10693 (pass), for last pass
 Repro found: flight 10694 (fail), for first failure
 Repro found: flight 10695 (pass), for last pass
 Repro found: flight 10696 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  86b8a1e3a419
  Bug not present: c5eadfd5c639

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24503:86b8a1e3a419
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Jan 13 08:33:31 2012 +0100
      
      force inclusion of xen/config.h through compiler option
      
      As we expect all source files to include the header as the first thing
      anyway, stop doing this by repeating the inclusion in each and every
      source file (and in many headers), but rather enforce this uniformly
      through the compiler command line.
      
      As a first cleanup step, remove the explicit inclusion from all common
      headers. Further cleanup can be done incrementally.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}.
----------------------------------------
10696: ALL FAIL

flight 10696 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10696/


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 Sat Jan 14 01:36:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 01:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlsXL-00045x-T8; Sat, 14 Jan 2012 01:36: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 1RlsXK-00045s-HO
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 01:36:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326504955!9084633!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTExOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22105 invoked from network); 14 Jan 2012 01:35:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jan 2012 01:35:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,507,1320624000"; d="scan'208";a="10016154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 01:35: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, 14 Jan 2012 01:35: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 1RlsXC-0007tQ-Os;
	Sat, 14 Jan 2012 01:35:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RlsXC-00019v-Ng;
	Sat, 14 Jan 2012 01:35:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10689-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 01:35:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10689: 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 10689 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10689/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           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-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-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 01:36:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 01:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RlsXL-00045x-T8; Sat, 14 Jan 2012 01:36: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 1RlsXK-00045s-HO
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 01:36:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326504955!9084633!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTExOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22105 invoked from network); 14 Jan 2012 01:35:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jan 2012 01:35:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,507,1320624000"; d="scan'208";a="10016154"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 01:35: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, 14 Jan 2012 01:35: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 1RlsXC-0007tQ-Os;
	Sat, 14 Jan 2012 01:35:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RlsXC-00019v-Ng;
	Sat, 14 Jan 2012 01:35:54 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10689-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 01:35:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10689: 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 10689 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10689/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           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-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-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    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-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 04:21:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 04: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 1Rlv6w-00051A-5G; Sat, 14 Jan 2012 04:20: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 1Rlv6u-000515-Um
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 04:20:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326514850!10954078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTExOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27549 invoked from network); 14 Jan 2012 04:20:50 -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;
	14 Jan 2012 04:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,508,1320624000"; d="scan'208";a="10016556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 04:20: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; Sat, 14 Jan 2012 04:20: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 1Rlv6n-0000N2-RT;
	Sat, 14 Jan 2012 04:20:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlv6n-0003jw-QS;
	Sat, 14 Jan 2012 04:20:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10700-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 04:20:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10700: 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 10700 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10700/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 04:21:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 04: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 1Rlv6w-00051A-5G; Sat, 14 Jan 2012 04:20: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 1Rlv6u-000515-Um
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 04:20:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326514850!10954078!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTExOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27549 invoked from network); 14 Jan 2012 04:20:50 -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;
	14 Jan 2012 04:20:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,508,1320624000"; d="scan'208";a="10016556"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 04:20: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; Sat, 14 Jan 2012 04:20: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 1Rlv6n-0000N2-RT;
	Sat, 14 Jan 2012 04:20:49 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rlv6n-0003jw-QS;
	Sat, 14 Jan 2012 04:20:49 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10700-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 04:20:49 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10700: 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 10700 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10700/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 12:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 12:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm2Mj-0007cZ-Vg; Sat, 14 Jan 2012 12:05:45 +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 1Rm2Mi-0007cU-FP
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 12:05:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326542737!10889457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12179 invoked from network); 14 Jan 2012 12:05:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jan 2012 12:05:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,509,1320624000"; d="scan'208";a="10019770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 12:05: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; Sat, 14 Jan 2012 12:05: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 1Rm2Ma-00032e-23;
	Sat, 14 Jan 2012 12:05:36 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rm2Ma-0002v3-0k;
	Sat, 14 Jan 2012 12:05:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 12:05:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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-xl
test guest-localmigrate

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: 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:  3c4c5df2cd0e
  Bug not present: 92630d4b093e


  changeset:   24471:3c4c5df2cd0e
  user:        Paul Durrant <paul.durrant@citrix.com>
  date:        Fri Dec 16 14:54:14 2011 +0000
      
      tools: 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>
      Committed-by: Ian Jackson <ian.jackson.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-xl.guest-localmigrate.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10700 fail [host=woodlouse] / 10649 ok.
Failure / basis pass flights: 10700 / 10649
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
Basis pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#59b1ffe039ce366305d48176b7fccce29ce729d3-59b1ffe039ce366305d48176b7fccce29ce729d3 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bb36d632e4cabf47882adff07a45c6702c4a5b30-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#5b2676ac1321-6d8888519e3a
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 49 nodes in revision graph
Searching for test results:
 10697 [host=potato-beetle]
 10708 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 db22b1aa11d3
 10689 [host=itch-mite]
 10698 [host=potato-beetle]
 10715 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
 10709 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
 10681 [host=potato-beetle]
 10645 [host=potato-beetle]
 10699 [host=itch-mite]
 10646 [host=moss-bug]
 10649 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
 10701 [host=itch-mite]
 10680 [host=lace-bug]
 10710 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 1e3fa01b0c9e
 10702 [host=itch-mite]
 10703 [host=itch-mite]
 10711 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
 10700 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10704 [host=itch-mite]
 10712 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
 10705 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
 10706 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10713 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
 10707 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 32dd444700bd
 10714 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
Searching for interesting versions
 Result found: flight 10649 (pass), for basis pass
 Result found: flight 10700 (fail), for basis failure
 Repro found: flight 10705 (pass), for basis pass
 Repro found: flight 10706 (fail), for basis failure
 0 revisions at 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
No revisions left to test, checking graph state.
 Result found: flight 10709 (pass), for last pass
 Result found: flight 10711 (fail), for first failure
 Repro found: flight 10712 (pass), for last pass
 Repro found: flight 10713 (fail), for first failure
 Repro found: flight 10714 (pass), for last pass
 Repro found: flight 10715 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  3c4c5df2cd0e
  Bug not present: 92630d4b093e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24471:3c4c5df2cd0e
  user:        Paul Durrant <paul.durrant@citrix.com>
  date:        Fri Dec 16 14:54:14 2011 +0000
      
      tools: 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>
      Committed-by: Ian Jackson <ian.jackson.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-xl.guest-localmigrate.{dot,ps,png,html}.
----------------------------------------
10715: ALL FAIL

flight 10715 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10715/


jobs:
 test-i386-i386-xl                                            fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Jan 14 12:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 12:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm2Mj-0007cZ-Vg; Sat, 14 Jan 2012 12:05:45 +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 1Rm2Mi-0007cU-FP
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 12:05:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326542737!10889457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12179 invoked from network); 14 Jan 2012 12:05:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jan 2012 12:05:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,509,1320624000"; d="scan'208";a="10019770"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 12:05: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; Sat, 14 Jan 2012 12:05: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 1Rm2Ma-00032e-23;
	Sat, 14 Jan 2012 12:05:36 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rm2Ma-0002v3-0k;
	Sat, 14 Jan 2012 12:05:36 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 12:05:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com, keir@xen.org, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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-xl
test guest-localmigrate

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: 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:  3c4c5df2cd0e
  Bug not present: 92630d4b093e


  changeset:   24471:3c4c5df2cd0e
  user:        Paul Durrant <paul.durrant@citrix.com>
  date:        Fri Dec 16 14:54:14 2011 +0000
      
      tools: 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>
      Committed-by: Ian Jackson <ian.jackson.citrix.com>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-xl.guest-localmigrate.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10700 fail [host=woodlouse] / 10649 ok.
Failure / basis pass flights: 10700 / 10649
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
Basis pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#59b1ffe039ce366305d48176b7fccce29ce729d3-59b1ffe039ce366305d48176b7fccce29ce729d3 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bb36d632e4cabf47882adff07a45c6702c4a5b30-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#5b2676ac1321-6d8888519e3a
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 49 nodes in revision graph
Searching for test results:
 10697 [host=potato-beetle]
 10708 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 db22b1aa11d3
 10689 [host=itch-mite]
 10698 [host=potato-beetle]
 10715 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
 10709 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
 10681 [host=potato-beetle]
 10645 [host=potato-beetle]
 10699 [host=itch-mite]
 10646 [host=moss-bug]
 10649 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
 10701 [host=itch-mite]
 10680 [host=lace-bug]
 10710 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 1e3fa01b0c9e
 10702 [host=itch-mite]
 10703 [host=itch-mite]
 10711 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
 10700 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10704 [host=itch-mite]
 10712 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
 10705 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
 10706 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10713 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
 10707 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 32dd444700bd
 10714 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
Searching for interesting versions
 Result found: flight 10649 (pass), for basis pass
 Result found: flight 10700 (fail), for basis failure
 Repro found: flight 10705 (pass), for basis pass
 Repro found: flight 10706 (fail), for basis failure
 0 revisions at 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
No revisions left to test, checking graph state.
 Result found: flight 10709 (pass), for last pass
 Result found: flight 10711 (fail), for first failure
 Repro found: flight 10712 (pass), for last pass
 Repro found: flight 10713 (fail), for first failure
 Repro found: flight 10714 (pass), for last pass
 Repro found: flight 10715 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  3c4c5df2cd0e
  Bug not present: 92630d4b093e

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24471:3c4c5df2cd0e
  user:        Paul Durrant <paul.durrant@citrix.com>
  date:        Fri Dec 16 14:54:14 2011 +0000
      
      tools: 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>
      Committed-by: Ian Jackson <ian.jackson.citrix.com>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-xl.guest-localmigrate.{dot,ps,png,html}.
----------------------------------------
10715: ALL FAIL

flight 10715 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10715/


jobs:
 test-i386-i386-xl                                            fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://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 Jan 14 13:42:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 13:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm3rd-00084C-BM; Sat, 14 Jan 2012 13:41: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 1Rm3rb-000847-PJ
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 13:41:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326548373!48532492!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 10767 invoked from network); 14 Jan 2012 13:39:33 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jan 2012 13:39:33 -0000
Received: by wgbed3 with SMTP id ed3so2644302wgb.0
	for <xen-devel@lists.xensource.com>;
	Sat, 14 Jan 2012 05:41: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:user-agent:date:from:to;
	bh=wDPkL1kvQXGNHyOXnHNj7+XpbjXCuX6SGk7GBG4U6UU=;
	b=fXCJE/OZTtkOQybUjQBn1tOXbImdbt4nKEj04YcGVa2GDS6EIu2bb2V22Aj7XdIuC2
	FW6nIRJRHVNs2fxjowQ+YNKy7W23r5JyiY8oxutcGmnRbgoiUymKRv2sv1zMz8HitMcS
	DJ05k2IatR41w3iNvtxFjKUjhiVBjzZa+S9k4=
Received: by 10.180.19.138 with SMTP id f10mr10532249wie.3.1326548502189;
	Sat, 14 Jan 2012 05:41:42 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id fc6sm10465692wbb.16.2012.01.14.05.41.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 14 Jan 2012 05:41:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1b95948228b84c986764488cbb7683d0d109be90
Message-Id: <1b95948228b84c986764.1326548473@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Sat, 14 Jan 2012 14:41:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and set
 it to 5 at device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326548456 -3600
# Node ID 1b95948228b84c986764488cbb7683d0d109be90
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
libxl: Atomicaly check backend state and set it to 5 at device_remove

libxl__device_remove was setting backend state to 5, which could
create a race condition, since the previous check for state != 4 and
setting state to 5 was not done inside the same transaction, so the
kernel could change the state to 6 in the space between the check for
state != 4 and setting it to 5.

The state != 4 check and setting it to 5 should happen in the same
transaction, to assure that nobody is modifying it behind our back.

Changes since v1:

 * Do the check and set in the same transaction, instead of removing
   the set state to 5.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5b2676ac1321 -r 1b95948228b8 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_device.c	Sat Jan 14 14:40:56 2012 +0100
@@ -442,19 +442,23 @@ int libxl__device_remove(libxl__gc *gc, 
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
 
-    if (!state)
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
+    if (!state) {
+        xs_transaction_end(ctx->xsh, t, 0);
         goto out;
+    }
     if (atoi(state) != 4) {
+        xs_transaction_end(ctx->xsh, t, 0);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
     }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 14 13:42:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 13:42:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm3rd-00084C-BM; Sat, 14 Jan 2012 13:41: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 1Rm3rb-000847-PJ
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 13:41:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326548373!48532492!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 10767 invoked from network); 14 Jan 2012 13:39:33 -0000
Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com)
	(74.125.82.41)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jan 2012 13:39:33 -0000
Received: by wgbed3 with SMTP id ed3so2644302wgb.0
	for <xen-devel@lists.xensource.com>;
	Sat, 14 Jan 2012 05:41: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:user-agent:date:from:to;
	bh=wDPkL1kvQXGNHyOXnHNj7+XpbjXCuX6SGk7GBG4U6UU=;
	b=fXCJE/OZTtkOQybUjQBn1tOXbImdbt4nKEj04YcGVa2GDS6EIu2bb2V22Aj7XdIuC2
	FW6nIRJRHVNs2fxjowQ+YNKy7W23r5JyiY8oxutcGmnRbgoiUymKRv2sv1zMz8HitMcS
	DJ05k2IatR41w3iNvtxFjKUjhiVBjzZa+S9k4=
Received: by 10.180.19.138 with SMTP id f10mr10532249wie.3.1326548502189;
	Sat, 14 Jan 2012 05:41:42 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id fc6sm10465692wbb.16.2012.01.14.05.41.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 14 Jan 2012 05:41:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 1b95948228b84c986764488cbb7683d0d109be90
Message-Id: <1b95948228b84c986764.1326548473@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Sat, 14 Jan 2012 14:41:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v2] libxl: Atomicaly check backend state and set
 it to 5 at device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326548456 -3600
# Node ID 1b95948228b84c986764488cbb7683d0d109be90
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
libxl: Atomicaly check backend state and set it to 5 at device_remove

libxl__device_remove was setting backend state to 5, which could
create a race condition, since the previous check for state != 4 and
setting state to 5 was not done inside the same transaction, so the
kernel could change the state to 6 in the space between the check for
state != 4 and setting it to 5.

The state != 4 check and setting it to 5 should happen in the same
transaction, to assure that nobody is modifying it behind our back.

Changes since v1:

 * Do the check and set in the same transaction, instead of removing
   the set state to 5.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5b2676ac1321 -r 1b95948228b8 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_device.c	Sat Jan 14 14:40:56 2012 +0100
@@ -442,19 +442,23 @@ int libxl__device_remove(libxl__gc *gc, 
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
-    char *state = libxl__xs_read(gc, XBT_NULL, state_path);
+    char *state;
     int rc = 0;
 
-    if (!state)
+retry_transaction:
+    t = xs_transaction_start(ctx->xsh);
+    state = libxl__xs_read(gc, t, state_path);
+    if (!state) {
+        xs_transaction_end(ctx->xsh, t, 0);
         goto out;
+    }
     if (atoi(state) != 4) {
+        xs_transaction_end(ctx->xsh, t, 0);
         libxl__device_destroy_tapdisk(gc, be_path);
         xs_rm(ctx->xsh, XBT_NULL, be_path);
         goto out;
     }
 
-retry_transaction:
-    t = xs_transaction_start(ctx->xsh);
     xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/online", be_path), "0", strlen("0"));
     xs_write(ctx->xsh, t, state_path, "5", strlen("5"));
     if (!xs_transaction_end(ctx->xsh, t, 0)) {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 14 14:39:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 14:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm4l4-0008P7-RW; Sat, 14 Jan 2012 14:39:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rm4l2-0008P2-Ba
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 14:39:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326551934!11021121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25300 invoked from network); 14 Jan 2012 14:38:54 -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 Jan 2012 14:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,509,1320624000"; d="scan'208";a="10021623"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 14:38: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; Sat, 14 Jan 2012 14:38: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 1Rm4kv-0003sz-3u;
	Sat, 14 Jan 2012 14:38:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rm4kv-0007hl-2l;
	Sat, 14 Jan 2012 14:38:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10716-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 14:38:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10716: 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 10716 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10716/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 14:39:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 14:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm4l4-0008P7-RW; Sat, 14 Jan 2012 14:39:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rm4l2-0008P2-Ba
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 14:39:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326551934!11021121!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25300 invoked from network); 14 Jan 2012 14:38:54 -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 Jan 2012 14:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,509,1320624000"; d="scan'208";a="10021623"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 14:38: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; Sat, 14 Jan 2012 14:38: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 1Rm4kv-0003sz-3u;
	Sat, 14 Jan 2012 14:38:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rm4kv-0007hl-2l;
	Sat, 14 Jan 2012 14:38:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10716-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 14:38:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10716: 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 10716 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10716/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 17:21:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 17:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm7HQ-0000xd-J6; Sat, 14 Jan 2012 17:20:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rm7HO-0000xY-O8
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 17:20:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326561626!8604681!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24302 invoked from network); 14 Jan 2012 17:20:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jan 2012 17:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,510,1320624000"; d="scan'208";a="10024409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 17:20: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; Sat, 14 Jan 2012 17:20: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 1Rm7HG-0004mE-04;
	Sat, 14 Jan 2012 17:20:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rm7HF-0001Gi-Vi;
	Sat, 14 Jan 2012 17:20:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10722-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 17:20:25 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10722: 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 10722 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10722/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 17:21:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 17:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm7HQ-0000xd-J6; Sat, 14 Jan 2012 17:20:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rm7HO-0000xY-O8
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 17:20:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326561626!8604681!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24302 invoked from network); 14 Jan 2012 17:20:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	14 Jan 2012 17:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,510,1320624000"; d="scan'208";a="10024409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 17:20: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; Sat, 14 Jan 2012 17:20: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 1Rm7HG-0004mE-04;
	Sat, 14 Jan 2012 17:20:26 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rm7HF-0001Gi-Vi;
	Sat, 14 Jan 2012 17:20:25 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10722-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 17:20:25 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10722: 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 10722 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10722/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 20:11:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 20:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm9wI-0003Lr-M4; Sat, 14 Jan 2012 20:10: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 1Rm9wG-0003Lm-P1
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 20:10:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326571814!60216975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23147 invoked from network); 14 Jan 2012 20:10:14 -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;
	14 Jan 2012 20:10:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,511,1320624000"; d="scan'208";a="10026795"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 20:10:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Jan 2012 20:10:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rm9wE-0005iA-Pn;
	Sat, 14 Jan 2012 20:10:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rm9wE-0004nR-PP;
	Sat, 14 Jan 2012 20:10:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Rm9wE-0004nR-PP@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 20:10:54 +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-oldkern
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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-oldkern
test xen-build

Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: 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:  86b8a1e3a419
  Bug not present: c5eadfd5c639


  changeset:   24503:86b8a1e3a419
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Jan 13 08:33:31 2012 +0100
      
      force inclusion of xen/config.h through compiler option
      
      As we expect all source files to include the header as the first thing
      anyway, stop doing this by repeating the inclusion in each and every
      source file (and in many headers), but rather enforce this uniformly
      through the compiler command line.
      
      As a first cleanup step, remove the explicit inclusion from all common
      headers. Further cleanup can be done incrementally.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10722 fail [host=moss-bug] / 10649 [host=itch-mite] 10646 [host=itch-mite] 10645 [host=itch-mite] 10644 [host=itch-mite] 10643 [host=lace-bug] 10642 [host=lace-bug] 10641 [host=itch-mite] 10640 [host=itch-mite] 10639 [host=itch-mite] 10636 [host=potato-beetle] 10635 [host=itch-mite] 10632 [host=itch-mite] 10631 [host=itch-mite] 10630 [host=potato-beetle] 10629 [host=itch-mite] 10628 [host=itch-mite] 10623 ok.
Failure / basis pass flights: 10722 / 10623
Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
Basis pass fe1adb19ffe1 56d7747a3cf811910c4cf865e1ebcb8b82502005 50117a4d1a2c
Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/linux-2.6.18-xen.hg#fe1adb19ffe1-c3d7beacd036 git://xenbits.xen.org/staging/qemu-xen-unstable.git#56d7747a3cf811910c4cf865e1ebcb8b82502005-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#50117a4d1a2c-6d8888519e3a
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-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
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-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 2024 nodes in revision graph
Searching for test results:
 10623 pass fe1adb19ffe1 56d7747a3cf811910c4cf865e1ebcb8b82502005 50117a4d1a2c
 10628 [host=itch-mite]
 10629 [host=itch-mite]
 10630 [host=potato-beetle]
 10631 [host=itch-mite]
 10632 [host=itch-mite]
 10635 [host=itch-mite]
 10636 [host=potato-beetle]
 10689 [host=leaf-beetle]
 10639 [host=itch-mite]
 10640 [host=itch-mite]
 10641 [host=itch-mite]
 10642 [host=lace-bug]
 10643 [host=lace-bug]
 10644 [host=itch-mite]
 10681 [host=leaf-beetle]
 10645 [host=itch-mite]
 10646 [host=itch-mite]
 10649 [host=itch-mite]
 10730 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10680 [host=leaf-beetle]
 10717 [host=leaf-beetle]
 10700 [host=leaf-beetle]
 10721 pass fe1adb19ffe1 56d7747a3cf811910c4cf865e1ebcb8b82502005 50117a4d1a2c
 10718 [host=leaf-beetle]
 10726 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 94b5fb649d94
 10719 [host=leaf-beetle]
 10723 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10729 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10716 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10720 [host=leaf-beetle]
 10724 pass 821a5b2a10c8 bb36d632e4cabf47882adff07a45c6702c4a5b30 ef99b8571a6f
 10727 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 5ac7713e7f5d
 10725 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6c104b46ef89
 10733 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10722 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10728 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10732 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10734 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10735 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
Searching for interesting versions
 Result found: flight 10623 (pass), for basis pass
 Result found: flight 10716 (fail), for basis failure
 Repro found: flight 10721 (pass), for basis pass
 Repro found: flight 10722 (fail), for basis failure
 0 revisions at c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
No revisions left to test, checking graph state.
 Result found: flight 10729 (pass), for last pass
 Result found: flight 10730 (fail), for first failure
 Repro found: flight 10732 (pass), for last pass
 Repro found: flight 10733 (fail), for first failure
 Repro found: flight 10734 (pass), for last pass
 Repro found: flight 10735 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  86b8a1e3a419
  Bug not present: c5eadfd5c639

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24503:86b8a1e3a419
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Jan 13 08:33:31 2012 +0100
      
      force inclusion of xen/config.h through compiler option
      
      As we expect all source files to include the header as the first thing
      anyway, stop doing this by repeating the inclusion in each and every
      source file (and in many headers), but rather enforce this uniformly
      through the compiler command line.
      
      As a first cleanup step, remove the explicit inclusion from all common
      headers. Further cleanup can be done incrementally.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.{dot,ps,png,html}.
----------------------------------------
10735: ALL FAIL

flight 10735 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10735/


jobs:
 build-amd64-oldkern                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 14 20:11:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 20:11:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rm9wI-0003Lr-M4; Sat, 14 Jan 2012 20:10: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 1Rm9wG-0003Lm-P1
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 20:10:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326571814!60216975!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23147 invoked from network); 14 Jan 2012 20:10:14 -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;
	14 Jan 2012 20:10:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,511,1320624000"; d="scan'208";a="10026795"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 20:10:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Jan 2012 20:10:55 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rm9wE-0005iA-Pn;
	Sat, 14 Jan 2012 20:10:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rm9wE-0004nR-PP;
	Sat, 14 Jan 2012 20:10:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1Rm9wE-0004nR-PP@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 20:10:54 +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-oldkern
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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-oldkern
test xen-build

Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: 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:  86b8a1e3a419
  Bug not present: c5eadfd5c639


  changeset:   24503:86b8a1e3a419
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Jan 13 08:33:31 2012 +0100
      
      force inclusion of xen/config.h through compiler option
      
      As we expect all source files to include the header as the first thing
      anyway, stop doing this by repeating the inclusion in each and every
      source file (and in many headers), but rather enforce this uniformly
      through the compiler command line.
      
      As a first cleanup step, remove the explicit inclusion from all common
      headers. Further cleanup can be done incrementally.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      


For bisection revision-tuple graph see:
   http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Searching for failure / basis pass:
 10722 fail [host=moss-bug] / 10649 [host=itch-mite] 10646 [host=itch-mite] 10645 [host=itch-mite] 10644 [host=itch-mite] 10643 [host=lace-bug] 10642 [host=lace-bug] 10641 [host=itch-mite] 10640 [host=itch-mite] 10639 [host=itch-mite] 10636 [host=potato-beetle] 10635 [host=itch-mite] 10632 [host=itch-mite] 10631 [host=itch-mite] 10630 [host=potato-beetle] 10629 [host=itch-mite] 10628 [host=itch-mite] 10623 ok.
Failure / basis pass flights: 10722 / 10623
Tree: linux http://xenbits.xen.org/linux-2.6.18-xen.hg
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
Basis pass fe1adb19ffe1 56d7747a3cf811910c4cf865e1ebcb8b82502005 50117a4d1a2c
Generating revisions with ./adhoc-revtuple-generator  http://xenbits.xen.org/linux-2.6.18-xen.hg#fe1adb19ffe1-c3d7beacd036 git://xenbits.xen.org/staging/qemu-xen-unstable.git#56d7747a3cf811910c4cf865e1ebcb8b82502005-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#50117a4d1a2c-6d8888519e3a
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-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
pulling from ssh://xen@xenbits.xen.org/HG/linux-2.6.18-xen.hg
searching for changes
no changes found
using cache /export/home/osstest/repos/git-cache...
using cache /export/home/osstest/repos/git-cache...
locked cache /export/home/osstest/repos/git-cache...
processing ./cacheing-git clone --bare git://xenbits.xen.org/staging/qemu-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 2024 nodes in revision graph
Searching for test results:
 10623 pass fe1adb19ffe1 56d7747a3cf811910c4cf865e1ebcb8b82502005 50117a4d1a2c
 10628 [host=itch-mite]
 10629 [host=itch-mite]
 10630 [host=potato-beetle]
 10631 [host=itch-mite]
 10632 [host=itch-mite]
 10635 [host=itch-mite]
 10636 [host=potato-beetle]
 10689 [host=leaf-beetle]
 10639 [host=itch-mite]
 10640 [host=itch-mite]
 10641 [host=itch-mite]
 10642 [host=lace-bug]
 10643 [host=lace-bug]
 10644 [host=itch-mite]
 10681 [host=leaf-beetle]
 10645 [host=itch-mite]
 10646 [host=itch-mite]
 10649 [host=itch-mite]
 10730 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10680 [host=leaf-beetle]
 10717 [host=leaf-beetle]
 10700 [host=leaf-beetle]
 10721 pass fe1adb19ffe1 56d7747a3cf811910c4cf865e1ebcb8b82502005 50117a4d1a2c
 10718 [host=leaf-beetle]
 10726 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 94b5fb649d94
 10719 [host=leaf-beetle]
 10723 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10729 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10716 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10720 [host=leaf-beetle]
 10724 pass 821a5b2a10c8 bb36d632e4cabf47882adff07a45c6702c4a5b30 ef99b8571a6f
 10727 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 5ac7713e7f5d
 10725 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6c104b46ef89
 10733 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10722 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
 10728 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
 10732 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10734 pass c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
 10735 fail c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 86b8a1e3a419
Searching for interesting versions
 Result found: flight 10623 (pass), for basis pass
 Result found: flight 10716 (fail), for basis failure
 Repro found: flight 10721 (pass), for basis pass
 Repro found: flight 10722 (fail), for basis failure
 0 revisions at c3d7beacd036 bb36d632e4cabf47882adff07a45c6702c4a5b30 c5eadfd5c639
No revisions left to test, checking graph state.
 Result found: flight 10729 (pass), for last pass
 Result found: flight 10730 (fail), for first failure
 Repro found: flight 10732 (pass), for last pass
 Repro found: flight 10733 (fail), for first failure
 Repro found: flight 10734 (pass), for last pass
 Repro found: flight 10735 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  86b8a1e3a419
  Bug not present: c5eadfd5c639

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24503:86b8a1e3a419
  user:        Jan Beulich <jbeulich@suse.com>
  date:        Fri Jan 13 08:33:31 2012 +0100
      
      force inclusion of xen/config.h through compiler option
      
      As we expect all source files to include the header as the first thing
      anyway, stop doing this by repeating the inclusion in each and every
      source file (and in many headers), but rather enforce this uniformly
      through the compiler command line.
      
      As a first cleanup step, remove the explicit inclusion from all common
      headers. Further cleanup can be done incrementally.
      
      Signed-off-by: Jan Beulich <jbeulich@suse.com>
      Acked-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64-oldkern.xen-build.{dot,ps,png,html}.
----------------------------------------
10735: ALL FAIL

flight 10735 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10735/


jobs:
 build-amd64-oldkern                                          fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 14 20:37:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 20:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmALX-0003ZY-V3; Sat, 14 Jan 2012 20:37: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 1RmALW-0003ZT-QP
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 20:37:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326573375!50246253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29842 invoked from network); 14 Jan 2012 20:36: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;
	14 Jan 2012 20:36:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,511,1320624000"; d="scan'208";a="10026949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 20:36:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Jan 2012 20:36: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 1RmALT-0005r1-6y;
	Sat, 14 Jan 2012 20:36:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmALS-0001Zi-Qq;
	Sat, 14 Jan 2012 20:36:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10731-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 20:36:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10731: 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 10731 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10731/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 20:37:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 20:37:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmALX-0003ZY-V3; Sat, 14 Jan 2012 20:37: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 1RmALW-0003ZT-QP
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 20:37:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326573375!50246253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29842 invoked from network); 14 Jan 2012 20:36: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;
	14 Jan 2012 20:36:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,511,1320624000"; d="scan'208";a="10026949"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 20:36:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Jan 2012 20:36: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 1RmALT-0005r1-6y;
	Sat, 14 Jan 2012 20:36:59 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmALS-0001Zi-Qq;
	Sat, 14 Jan 2012 20:36:59 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10731-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 20:36:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10731: 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 10731 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10731/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 23:33:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 23:33:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmD55-0004ar-Mi; Sat, 14 Jan 2012 23:32: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 1RmD53-0004aj-O3
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 23:32:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326583927!10904322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6266 invoked from network); 14 Jan 2012 23:32:07 -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;
	14 Jan 2012 23:32:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,511,1320624000"; d="scan'208";a="10027515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 23:31:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Jan 2012 23:31: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 1RmD4o-0006o6-LZ;
	Sat, 14 Jan 2012 23:31:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmD4o-0002qS-Ky;
	Sat, 14 Jan 2012 23:31:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10737-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 23:31:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10737: 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 10737 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10737/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 14 23:33:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 14 Jan 2012 23:33:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmD55-0004ar-Mi; Sat, 14 Jan 2012 23:32: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 1RmD53-0004aj-O3
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 23:32:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326583927!10904322!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6266 invoked from network); 14 Jan 2012 23:32:07 -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;
	14 Jan 2012 23:32:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,511,1320624000"; d="scan'208";a="10027515"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	14 Jan 2012 23:31:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 14 Jan 2012 23:31: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 1RmD4o-0006o6-LZ;
	Sat, 14 Jan 2012 23:31:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmD4o-0002qS-Ky;
	Sat, 14 Jan 2012 23:31:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10737-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 14 Jan 2012 23:31:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10737: 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 10737 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10737/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 04:45:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 04: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 1RmHxH-0001ec-Nc; Sun, 15 Jan 2012 04:44: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 1RmHxF-0001eX-G9
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 04:44:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326602662!11041958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22579 invoked from network); 15 Jan 2012 04:44:22 -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 Jan 2012 04:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,512,1320624000"; d="scan'208";a="10028181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 04:44: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; Sun, 15 Jan 2012 04:44: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 1RmHx6-000058-M4;
	Sun, 15 Jan 2012 04:44:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmHx6-000219-LW;
	Sun, 15 Jan 2012 04:44:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10742-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 04:44:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10742: 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 10742 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10742/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 04:45:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 04: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 1RmHxH-0001ec-Nc; Sun, 15 Jan 2012 04:44: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 1RmHxF-0001eX-G9
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 04:44:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326602662!11041958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTI5OA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22579 invoked from network); 15 Jan 2012 04:44:22 -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 Jan 2012 04:44:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,512,1320624000"; d="scan'208";a="10028181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 04:44: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; Sun, 15 Jan 2012 04:44: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 1RmHx6-000058-M4;
	Sun, 15 Jan 2012 04:44:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmHx6-000219-LW;
	Sun, 15 Jan 2012 04:44:20 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10742-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 04:44:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10742: 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 10742 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10742/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 10:50:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 10: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 1RmNeO-0004hg-5D; Sun, 15 Jan 2012 10:49:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RmNeN-0004hb-3q
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 10:49:23 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326624555!8552411!1
X-Originating-IP: [217.72.192.243]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjI0MyA9PiAyMTc1Ng==\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjI0MyA9PiAyMTc1Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29572 invoked from network); 15 Jan 2012 10:49:15 -0000
Received: from fmmailgate05.web.de (HELO fmmailgate05.web.de) (217.72.192.243)
	by server-6.tower-21.messagelabs.com with SMTP;
	15 Jan 2012 10:49:15 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate05.web.de (Postfix) with ESMTP id 33EE06910023
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 11:49:15 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([95.157.56.37]) by smtp.web.de
	(mrweb002) with ESMTPA (Nemesis) id 0M6UmJ-1Sadiv0wnL-00y9Uu;
	Sun, 15 Jan 2012 11:49:11 +0100
Message-ID: <4F12AF25.9050506@web.de>
Date: Sun, 15 Jan 2012 11:49:09 +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: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-14-git-send-email-avi@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:ZRiEQCL2nBKk6bn0z+P1p1eeLf1xACGZ2LrpU5MxPXr
	VUDgM8Q8gThPCIRNPFJTnusNLh6StaZso84hzl1uEtuAPFoLEl
	/U0ig/bfl2OVinS1zVhx98autj0Jw49EbTU7BqqZ6t0dRkyCDp
	lLFM2gDE9I1oi5dl12Ozs3B3JhydkSQw1guIhZIYosrDulSZ6+
	QnpUYHuLqUOK2lHn+ZhEQ==
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] [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>
Content-Type: multipart/mixed; boundary="===============1820195168570156552=="
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)
--===============1820195168570156552==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig9E5B52259BF9B6934B3290E6"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9E5B52259BF9B6934B3290E6
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 2011-12-19 15:13, Avi Kivity wrote:
> 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 expl=
oited
> in this patch.

This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.

Jan

>=20
> Signed-off-by: Avi Kivity <avi@redhat.com>
> ---
>  kvm-all.c |  107 ++++++++++++++++++++++++++++++++++++++++-------------=
--------
>  1 files changed, 70 insertions(+), 37 deletions(-)
>=20
> 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"
> =20
>  /* 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);
>  }
> =20
> -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 =3D kvm_dirty_pages_log_change(section->offset_within_address_sp=
ace,
> +                                   section->size, true);
> +    if (r < 0) {
> +        abort();
> +    }
>  }
> =20
> -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 =3D kvm_dirty_pages_log_change(section->offset_within_address_sp=
ace,
> +                                   section->size, false);
> +    if (r < 0) {
> +        abort();
> +    }
>  }
> =20
>  static int kvm_set_migration_log(int enable)
> @@ -519,13 +532,15 @@ static int kvm_check_many_ioeventfds(void)
>      return NULL;
>  }
> =20
> -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 =3D kvm_state;
> -    ram_addr_t flags =3D phys_offset & ~TARGET_PAGE_MASK;
>      KVMSlot *mem, old;
>      int err;
> +    MemoryRegion *mr =3D section->mr;
> +    bool log_dirty =3D memory_region_is_logging(mr);
> +    target_phys_addr_t start_addr =3D section->offset_within_address_s=
pace;
> +    ram_addr_t size =3D section->size;
>      void *ram =3D NULL;
> =20
>      /* 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 s=
tart_addr, ram_addr_t size,
>      size =3D TARGET_PAGE_ALIGN(size);
>      start_addr =3D TARGET_PAGE_ALIGN(start_addr);
> =20
> -    /* KVM does not support read-only slots */
> -    phys_offset &=3D ~IO_MEM_ROM;
> -
> -    if ((phys_offset & ~TARGET_PAGE_MASK) =3D=3D IO_MEM_RAM) {
> -        ram =3D qemu_safe_ram_ptr(phys_offset);
> +    if (!memory_region_is_ram(mr)) {
> +        return;
>      }
> =20
> +    ram =3D memory_region_get_ram_ptr(mr) + section->offset_within_reg=
ion;
> +
>      while (1) {
>          mem =3D kvm_lookup_overlapping_slot(s, start_addr, start_addr =
+ size);
>          if (!mem) {
>              break;
>          }
> =20
> -        if (flags < IO_MEM_UNASSIGNED && start_addr >=3D mem->start_ad=
dr &&
> +        if (add && start_addr >=3D mem->start_addr &&
>              (start_addr + size <=3D mem->start_addr + mem->memory_size=
) &&
>              (ram - start_addr =3D=3D 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 sta=
rt_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 =3D=3D start_addr && old.memory_size < size=
 &&
> -            flags < IO_MEM_UNASSIGNED) {
> +            old.start_addr =3D=3D start_addr && old.memory_size < size=
 && add) {
>              mem =3D kvm_alloc_slot(s);
>              mem->memory_size =3D old.memory_size;
>              mem->start_addr =3D old.start_addr;
> @@ -591,7 +604,6 @@ static void kvm_set_phys_mem(target_phys_addr_t sta=
rt_addr, ram_addr_t size,
>              }
> =20
>              start_addr +=3D old.memory_size;
> -            phys_offset +=3D old.memory_size;
>              ram +=3D old.memory_size;
>              size -=3D old.memory_size;
>              continue;
> @@ -642,8 +654,7 @@ static void kvm_set_phys_mem(target_phys_addr_t sta=
rt_addr, ram_addr_t size,
>      if (!size) {
>          return;
>      }
> -    /* KVM does not need to know about this memory */
> -    if (flags >=3D IO_MEM_UNASSIGNED) {
> +    if (!add) {
>          return;
>      }
>      mem =3D kvm_alloc_slot(s);
> @@ -660,33 +671,55 @@ static void kvm_set_phys_mem(target_phys_addr_t s=
tart_addr, ram_addr_t size,
>      }
>  }
> =20
> -static void kvm_client_set_memory(struct CPUPhysMemoryClient *client,
> -                                  target_phys_addr_t start_addr,
> -                                  ram_addr_t size, ram_addr_t phys_off=
set,
> -                                  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 =3D section->offset_within_address_space;=

> +    target_phys_addr_t end =3D start + section->size;
> +    int r;
> +
> +    r =3D kvm_physical_sync_dirty_bitmap(start, end);
> +    if (r < 0) {
> +        abort();
> +    }
>  }
> =20
> -static int kvm_client_sync_dirty_bitmap(struct CPUPhysMemoryClient *cl=
ient,
> -                                        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 =3D kvm_set_migration_log(1);
> +    assert(r >=3D 0);
>  }
> =20
> -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 =3D kvm_set_migration_log(0);
> +    assert(r >=3D 0);
>  }
> =20
> -static CPUPhysMemoryClient kvm_cpu_phys_memory_client =3D {
> -    .set_memory =3D kvm_client_set_memory,
> -    .sync_dirty_bitmap =3D kvm_client_sync_dirty_bitmap,
> -    .migration_log =3D kvm_client_migration_log,
> +static MemoryListener kvm_memory_listener =3D {
> +    .region_add =3D kvm_region_add,
> +    .region_del =3D kvm_region_del,
>      .log_start =3D kvm_log_start,
>      .log_stop =3D kvm_log_stop,
> +    .log_sync =3D kvm_log_sync,
> +    .log_global_start =3D kvm_log_global_start,
> +    .log_global_stop =3D kvm_log_global_stop,
>  };
> =20
>  static void kvm_handle_interrupt(CPUState *env, int mask)
> @@ -794,7 +827,7 @@ int kvm_init(void)
>      }
> =20
>      kvm_state =3D s;
> -    cpu_register_phys_memory_client(&kvm_cpu_phys_memory_client);
> +    memory_listener_register(&kvm_memory_listener);
> =20
>      s->many_ioeventfds =3D kvm_check_many_ioeventfds();
> =20



--------------enig9E5B52259BF9B6934B3290E6
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/

iEYEARECAAYFAk8SryUACgkQitSsb3rl5xTmKwCfYW4Lm847iwxApUYsijIFwkGf
ED8AoOPhwyGzWmzHoFkAKKjvcnCHaE1g
=PH0P
-----END PGP SIGNATURE-----

--------------enig9E5B52259BF9B6934B3290E6--


--===============1820195168570156552==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1820195168570156552==--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 10:50:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 10: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 1RmNeO-0004hg-5D; Sun, 15 Jan 2012 10:49:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RmNeN-0004hb-3q
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 10:49:23 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326624555!8552411!1
X-Originating-IP: [217.72.192.243]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjI0MyA9PiAyMTc1Ng==\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjI0MyA9PiAyMTc1Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29572 invoked from network); 15 Jan 2012 10:49:15 -0000
Received: from fmmailgate05.web.de (HELO fmmailgate05.web.de) (217.72.192.243)
	by server-6.tower-21.messagelabs.com with SMTP;
	15 Jan 2012 10:49:15 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate05.web.de (Postfix) with ESMTP id 33EE06910023
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 11:49:15 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([95.157.56.37]) by smtp.web.de
	(mrweb002) with ESMTPA (Nemesis) id 0M6UmJ-1Sadiv0wnL-00y9Uu;
	Sun, 15 Jan 2012 11:49:11 +0100
Message-ID: <4F12AF25.9050506@web.de>
Date: Sun, 15 Jan 2012 11:49:09 +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: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
In-Reply-To: <1324304024-11220-14-git-send-email-avi@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:ZRiEQCL2nBKk6bn0z+P1p1eeLf1xACGZ2LrpU5MxPXr
	VUDgM8Q8gThPCIRNPFJTnusNLh6StaZso84hzl1uEtuAPFoLEl
	/U0ig/bfl2OVinS1zVhx98autj0Jw49EbTU7BqqZ6t0dRkyCDp
	lLFM2gDE9I1oi5dl12Ozs3B3JhydkSQw1guIhZIYosrDulSZ6+
	QnpUYHuLqUOK2lHn+ZhEQ==
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] [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>
Content-Type: multipart/mixed; boundary="===============1820195168570156552=="
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)
--===============1820195168570156552==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig9E5B52259BF9B6934B3290E6"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9E5B52259BF9B6934B3290E6
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 2011-12-19 15:13, Avi Kivity wrote:
> 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 expl=
oited
> in this patch.

This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.

Jan

>=20
> Signed-off-by: Avi Kivity <avi@redhat.com>
> ---
>  kvm-all.c |  107 ++++++++++++++++++++++++++++++++++++++++-------------=
--------
>  1 files changed, 70 insertions(+), 37 deletions(-)
>=20
> 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"
> =20
>  /* 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);
>  }
> =20
> -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 =3D kvm_dirty_pages_log_change(section->offset_within_address_sp=
ace,
> +                                   section->size, true);
> +    if (r < 0) {
> +        abort();
> +    }
>  }
> =20
> -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 =3D kvm_dirty_pages_log_change(section->offset_within_address_sp=
ace,
> +                                   section->size, false);
> +    if (r < 0) {
> +        abort();
> +    }
>  }
> =20
>  static int kvm_set_migration_log(int enable)
> @@ -519,13 +532,15 @@ static int kvm_check_many_ioeventfds(void)
>      return NULL;
>  }
> =20
> -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 =3D kvm_state;
> -    ram_addr_t flags =3D phys_offset & ~TARGET_PAGE_MASK;
>      KVMSlot *mem, old;
>      int err;
> +    MemoryRegion *mr =3D section->mr;
> +    bool log_dirty =3D memory_region_is_logging(mr);
> +    target_phys_addr_t start_addr =3D section->offset_within_address_s=
pace;
> +    ram_addr_t size =3D section->size;
>      void *ram =3D NULL;
> =20
>      /* 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 s=
tart_addr, ram_addr_t size,
>      size =3D TARGET_PAGE_ALIGN(size);
>      start_addr =3D TARGET_PAGE_ALIGN(start_addr);
> =20
> -    /* KVM does not support read-only slots */
> -    phys_offset &=3D ~IO_MEM_ROM;
> -
> -    if ((phys_offset & ~TARGET_PAGE_MASK) =3D=3D IO_MEM_RAM) {
> -        ram =3D qemu_safe_ram_ptr(phys_offset);
> +    if (!memory_region_is_ram(mr)) {
> +        return;
>      }
> =20
> +    ram =3D memory_region_get_ram_ptr(mr) + section->offset_within_reg=
ion;
> +
>      while (1) {
>          mem =3D kvm_lookup_overlapping_slot(s, start_addr, start_addr =
+ size);
>          if (!mem) {
>              break;
>          }
> =20
> -        if (flags < IO_MEM_UNASSIGNED && start_addr >=3D mem->start_ad=
dr &&
> +        if (add && start_addr >=3D mem->start_addr &&
>              (start_addr + size <=3D mem->start_addr + mem->memory_size=
) &&
>              (ram - start_addr =3D=3D 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 sta=
rt_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 =3D=3D start_addr && old.memory_size < size=
 &&
> -            flags < IO_MEM_UNASSIGNED) {
> +            old.start_addr =3D=3D start_addr && old.memory_size < size=
 && add) {
>              mem =3D kvm_alloc_slot(s);
>              mem->memory_size =3D old.memory_size;
>              mem->start_addr =3D old.start_addr;
> @@ -591,7 +604,6 @@ static void kvm_set_phys_mem(target_phys_addr_t sta=
rt_addr, ram_addr_t size,
>              }
> =20
>              start_addr +=3D old.memory_size;
> -            phys_offset +=3D old.memory_size;
>              ram +=3D old.memory_size;
>              size -=3D old.memory_size;
>              continue;
> @@ -642,8 +654,7 @@ static void kvm_set_phys_mem(target_phys_addr_t sta=
rt_addr, ram_addr_t size,
>      if (!size) {
>          return;
>      }
> -    /* KVM does not need to know about this memory */
> -    if (flags >=3D IO_MEM_UNASSIGNED) {
> +    if (!add) {
>          return;
>      }
>      mem =3D kvm_alloc_slot(s);
> @@ -660,33 +671,55 @@ static void kvm_set_phys_mem(target_phys_addr_t s=
tart_addr, ram_addr_t size,
>      }
>  }
> =20
> -static void kvm_client_set_memory(struct CPUPhysMemoryClient *client,
> -                                  target_phys_addr_t start_addr,
> -                                  ram_addr_t size, ram_addr_t phys_off=
set,
> -                                  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 =3D section->offset_within_address_space;=

> +    target_phys_addr_t end =3D start + section->size;
> +    int r;
> +
> +    r =3D kvm_physical_sync_dirty_bitmap(start, end);
> +    if (r < 0) {
> +        abort();
> +    }
>  }
> =20
> -static int kvm_client_sync_dirty_bitmap(struct CPUPhysMemoryClient *cl=
ient,
> -                                        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 =3D kvm_set_migration_log(1);
> +    assert(r >=3D 0);
>  }
> =20
> -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 =3D kvm_set_migration_log(0);
> +    assert(r >=3D 0);
>  }
> =20
> -static CPUPhysMemoryClient kvm_cpu_phys_memory_client =3D {
> -    .set_memory =3D kvm_client_set_memory,
> -    .sync_dirty_bitmap =3D kvm_client_sync_dirty_bitmap,
> -    .migration_log =3D kvm_client_migration_log,
> +static MemoryListener kvm_memory_listener =3D {
> +    .region_add =3D kvm_region_add,
> +    .region_del =3D kvm_region_del,
>      .log_start =3D kvm_log_start,
>      .log_stop =3D kvm_log_stop,
> +    .log_sync =3D kvm_log_sync,
> +    .log_global_start =3D kvm_log_global_start,
> +    .log_global_stop =3D kvm_log_global_stop,
>  };
> =20
>  static void kvm_handle_interrupt(CPUState *env, int mask)
> @@ -794,7 +827,7 @@ int kvm_init(void)
>      }
> =20
>      kvm_state =3D s;
> -    cpu_register_phys_memory_client(&kvm_cpu_phys_memory_client);
> +    memory_listener_register(&kvm_memory_listener);
> =20
>      s->many_ioeventfds =3D kvm_check_many_ioeventfds();
> =20



--------------enig9E5B52259BF9B6934B3290E6
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/

iEYEARECAAYFAk8SryUACgkQitSsb3rl5xTmKwCfYW4Lm847iwxApUYsijIFwkGf
ED8AoOPhwyGzWmzHoFkAKKjvcnCHaE1g
=PH0P
-----END PGP SIGNATURE-----

--------------enig9E5B52259BF9B6934B3290E6--


--===============1820195168570156552==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1820195168570156552==--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 10:53:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 10: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 1RmNho-0004nt-Pp; Sun, 15 Jan 2012 10:52:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RmNhn-0004nh-IH
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 10:52:55 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326624768!2526231!1
X-Originating-IP: [217.72.192.234]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiA1Mzg4\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiA1Mzg4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22075 invoked from network); 15 Jan 2012 10:52:48 -0000
Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234)
	by server-2.tower-21.messagelabs.com with SMTP;
	15 Jan 2012 10:52:48 -0000
Received: from moweb001.kundenserver.de (moweb001.kundenserver.de
	[172.19.20.114])
	by fmmailgate03.web.de (Postfix) with ESMTP id D865A1AFC96FB
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 11:52:47 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([95.157.56.37]) by smtp.web.de
	(mrweb002) with ESMTPA (Nemesis) id 0LZeou-1SXUcE2efk-00lloh;
	Sun, 15 Jan 2012 11:52:46 +0100
Message-ID: <4F12AFFD.9020200@web.de>
Date: Sun, 15 Jan 2012 11:52:45 +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: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de>
In-Reply-To: <4F12AF25.9050506@web.de>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:3iSdZaINPpbZPp+PZI6oW13apm8HEsgdUakXNn0NrUE
	zI9G7FjM63zk/FSH1UyIzwS4Pk8yfHjabayb/mF445h7wk5N+c
	94+nXgJsnT633KoEi2APPR6zvOKPwhkvYrHy+rFjnGKo5NTL7n
	33U8uYHv6ZqDTwyCK6M+vOpOaYH3n3+ab+P5g8ujz7Fivv7EWf
	UC5Hm5GgmkW7OWSHWvfWA==
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] [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>
Content-Type: multipart/mixed; boundary="===============4850272824420905929=="
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)
--===============4850272824420905929==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig2F3D6D69CED02E6185AE1BA6"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2F3D6D69CED02E6185AE1BA6
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 2012-01-15 11:49, Jan Kiszka wrote:
> On 2011-12-19 15:13, Avi Kivity wrote:
>> 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 exp=
loited
>> in this patch.
>=20
> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.=


In fact, it breaks all vga types in that scenario.

Jan


--------------enig2F3D6D69CED02E6185AE1BA6
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/

iEYEARECAAYFAk8Sr/4ACgkQitSsb3rl5xRxFACgioOOEXXRpX9ohZbaoK+VEpmu
zlcAnitGZrv/nc3uwvWmxAaI9ESl4Hfk
=vKoS
-----END PGP SIGNATURE-----

--------------enig2F3D6D69CED02E6185AE1BA6--


--===============4850272824420905929==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4850272824420905929==--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 10:53:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 10: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 1RmNho-0004nt-Pp; Sun, 15 Jan 2012 10:52:56 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RmNhn-0004nh-IH
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 10:52:55 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326624768!2526231!1
X-Originating-IP: [217.72.192.234]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiA1Mzg4\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiA1Mzg4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22075 invoked from network); 15 Jan 2012 10:52:48 -0000
Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234)
	by server-2.tower-21.messagelabs.com with SMTP;
	15 Jan 2012 10:52:48 -0000
Received: from moweb001.kundenserver.de (moweb001.kundenserver.de
	[172.19.20.114])
	by fmmailgate03.web.de (Postfix) with ESMTP id D865A1AFC96FB
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 11:52:47 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([95.157.56.37]) by smtp.web.de
	(mrweb002) with ESMTPA (Nemesis) id 0LZeou-1SXUcE2efk-00lloh;
	Sun, 15 Jan 2012 11:52:46 +0100
Message-ID: <4F12AFFD.9020200@web.de>
Date: Sun, 15 Jan 2012 11:52:45 +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: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de>
In-Reply-To: <4F12AF25.9050506@web.de>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:3iSdZaINPpbZPp+PZI6oW13apm8HEsgdUakXNn0NrUE
	zI9G7FjM63zk/FSH1UyIzwS4Pk8yfHjabayb/mF445h7wk5N+c
	94+nXgJsnT633KoEi2APPR6zvOKPwhkvYrHy+rFjnGKo5NTL7n
	33U8uYHv6ZqDTwyCK6M+vOpOaYH3n3+ab+P5g8ujz7Fivv7EWf
	UC5Hm5GgmkW7OWSHWvfWA==
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] [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>
Content-Type: multipart/mixed; boundary="===============4850272824420905929=="
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)
--===============4850272824420905929==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig2F3D6D69CED02E6185AE1BA6"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2F3D6D69CED02E6185AE1BA6
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 2012-01-15 11:49, Jan Kiszka wrote:
> On 2011-12-19 15:13, Avi Kivity wrote:
>> 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 exp=
loited
>> in this patch.
>=20
> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.=


In fact, it breaks all vga types in that scenario.

Jan


--------------enig2F3D6D69CED02E6185AE1BA6
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/

iEYEARECAAYFAk8Sr/4ACgkQitSsb3rl5xRxFACgioOOEXXRpX9ohZbaoK+VEpmu
zlcAnitGZrv/nc3uwvWmxAaI9ESl4Hfk
=vKoS
-----END PGP SIGNATURE-----

--------------enig2F3D6D69CED02E6185AE1BA6--


--===============4850272824420905929==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4850272824420905929==--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 11:34:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 11: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 1RmOKl-0005CE-0K; Sun, 15 Jan 2012 11:33:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RmOKi-0005C5-H8
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 11:33:08 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326627181!8555287!1
X-Originating-IP: [188.40.164.121]
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 10512 invoked from network); 15 Jan 2012 11:33: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-21.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Jan 2012 11:33:01 -0000
Received: from 25-72-ftth.onsneteindhoven.nl ([88.159.72.25]:50172
	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 1RmOIS-0006Zi-61; Sun, 15 Jan 2012 12:30:48 +0100
Date: Sun, 15 Jan 2012 12:32:59 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1383590207.20120115123259@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120113151307.GC5025@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.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


Friday, January 13, 2012, 4:13:07 PM, you 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.
>> 
>> > Good news is I am able to reproduce this with my 32-bit NIC with 3.2 domU:
>> 
>> > [  771.896140] SWIOTLB is 11% full
>> > [  776.896116] 0 [e1000 0000:00:00.0] bounce: from:222028(slow:0)to:2 map:222037 unmap:227220 sync:0
>> > [  776.896126] 1 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:5188 map:5188 unmap:0 sync:0
>> > [  776.896133] 3 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:1 map:1 unmap:0 sync:0
>> 
>> > but interestingly enough, if I boot the guest as the first one I do not get these bounce
>> > requests. I will shortly bootup a Xen-O-Linux kernel and see if I get these same
>> > numbers.
>> 
>> 
>> I started to expiriment some more with what i encountered.
>> 
>> On dom0 i was seeing that my r8169 ethernet controllers where using bounce buffering with the dump-swiotlb module.
>> It was showing "12% full".
>> Checking in sysfs shows:
>> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
>> 32
>> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
>> 32
>> 
>> If i remember correctly wasn't the allocation for dom0 changed to be to the top of memory instead of low .. somewhere between 2.6.32 and 3.0 ?

> ? We never actually had dom0 support in the upstream kernel until 2.6.37.. The 2.6.32<->2.6.36 you are
> referring to must have been the trees that I spun up - but the implementation of SWIOTLB in them
> had not really changed.

>> Could that change cause the need for all devices to need bounce buffering  and could it therefore explain some people seeing more cpu usage for dom0 ?

> The issue I am seeing is not CPU usage in dom0, but rather the CPU usage in domU with guests.
> And that the older domU's (XenOLinux) do not have this.

> That I can't understand - the implementation in both cases _looks_ to do the same thing.
> There was one issue I found in the upstream one, but even with that fix I still
> get that "bounce" usage in domU.

> Interestingly enough, I get that only if I have launched, destroyed, launched, etc, the guest multiple
> times before I get this. Which leads me to believe this is not a kernel issue but that we
> are simply fragmented the Xen memory so much, so that when it launches the guest all of the
> memory is above 4GB. But that seems counter-intuive as by default Xen starts guests at the far end of
> memory (so on my 16GB box it would stick a 4GB guest at 12GB->16GB roughly). The SWIOTLB
> swizzles some memory under the 4GB , and this is where we get the bounce buffer effect
> (as the memory from 4GB is then copied to the memory 12GB->16GB).

> But it does not explain why on the first couple of starts I did not see this with pvops.
> And it does not seem to happen with the XenOLinux kernel, so there must be something else
> in here.

>> 
>> I have forced my r8169 to use 64bits dma mask (using use_dac=1)

> Ah yes.
>> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
>> 32
>> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
>> 64
>> 
>> This results in dump-swiotlb reporting:
>> 
>> [ 1265.616106] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
>> [ 1265.625043] SWIOTLB is 0% full
>> [ 1270.626085] 0 [r8169 0000:08:00.0] bounce: from:6(slow:0)to:0 map:0 unmap:0 sync:12
>> [ 1270.635024] SWIOTLB is 0% full
>> [ 1275.635091] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
>> [ 1275.644261] SWIOTLB is 0% full
>> [ 1280.654097] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10

> Which is what we expect. No need to bounce since the PCI adapter can reach memory
> above the 4GB mark.

>> 
>> 
>> 
>> So it has changed from 12% to 0%, although it still reports something about bouncing ? or am i mis interpreting stuff ?

> The bouncing can happen due to two cases:
>  - Memory is above 4GB
>  - Memory crosses a page-boundary (rarely happens).
>> 
>> 
>> Another thing i was wondering about, couldn't the hypervisor offer a small window in 32bit addressable mem to all (or only when pci passthrough is used) domU's to be used for DMA ?

> It does. That is what the Xen SWIOTLB does with "swizzling" the pages in its pool.
> But it can't do it for every part of memory. That is why there are DMA pools
> which are used by graphics adapters, video capture devices,storage and network
> drivers. They are used for small packet sizes so that the driver does not have
> to allocate DMA buffers when it gets a 100bytes ping response. But for large
> packets (say that ISO file you are downloading) it allocates memory on the fly
> and "maps" it into the PCI space using the DMA API. That "mapping" sets up
> an "physical memory" -> "guest memory" translation - and if that allocated
> memory is above 4GB, part of this mapping is to copy ("bounce") the memory
> under the 4GB (where XenSWIOTLB has allocated a pool), so that the adapter
> can physically fetch/put the data. Once that is completed it is "sync"-ed
> back, which is bouncing that data to the "allocated memory".


> So having a DMA pool is very good - and most drivers use it. The thing I can't
> figure out is:
>  - why the DVB do not seem to use it, even thought they look to use the videobuf_dma
>    driver.
>  - why the XenOLinux does not seem to have this problem (and this might be false - 
>    perhaps it does have this problem and it just takes a couple of guest launches,
>    destructions, starts, etc to actually see it).
>  - are there any flags in the domain builder to say: "ok, this domain is going to
>    service 32-bit cards, hence build the memory from 0->4GB". This seems like
>    a good know at first, but it probably is a bad idea (imagine using it by mistake
>    on every guest). And also nowadays most cards are PCIe and they can do 64-bit, so
>    it would not be that important in the future.
>> 
>> (oh yes, i haven't got i clue what i'm talking about ... so it probably make no sense at all :-) )

> Nonsense. You were on the correct path . Hopefully the level of details hasn't
> scared you off now :-)

Well it only gives some more questions :-)
The thing is, pci passthrough and especially the DMA part of it, all work behind the scenes without giving much output about the way it is actually working.

The thing i was wondering about is if my AMD IOMMU is actually doing something for PV guests.
When booting with iommu=off machine has 8GB mem, dom0 limited to 1024M and just starting one domU with iommu=soft, with pci-passthrough and the USB pci-cards with USB videograbbers attached to it, i would expect to find some bounce buffering going.

                (HV_START_LOW 18446603336221196288)
                (FEATURES '!writable_page_tables|pae_pgdir_above_4gb')
                (VIRT_BASE 18446744071562067968)
                (GUEST_VERSION 2.6)
                (PADDR_OFFSET 0)
                (GUEST_OS linux)
                (HYPERCALL_PAGE 18446744071578849280)
                (LOADER generic)
                (SUSPEND_CANCEL 1)
                (PAE_MODE yes)
                (ENTRY 18446744071594476032)
                (XEN_VERSION xen-3.0)

Still i only see:

[   47.449072] Starting SWIOTLB debug thread.
[   47.449090] swiotlb_start_thread: Go!
[   47.449262] xen_swiotlb_start_thread: Go!
[   52.449158] 0 [ehci_hcd 0000:0a:00.3] bounce: from:432(slow:0)to:1329 map:1756 unmap:1781 sync:0
[   52.449180] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:16 map:23 unmap:0 sync:0
[   52.449187] 2 [ohci_hcd 0000:0a:00.4] bounce: from:0(slow:0)to:4 map:5 unmap:0 sync:0
[   52.449226] SWIOTLB is 0% full
[   57.449180] 0 ehci_hcd 0000:0a:00.3 alloc coherent: 35, free: 0
[   57.449219] 1 ohci_hcd 0000:0a:00.6 alloc coherent: 1, free: 0
[   57.449265] SWIOTLB is 0% full
[   62.449176] SWIOTLB is 0% full
[   67.449336] SWIOTLB is 0% full
[   72.449279] SWIOTLB is 0% full
[   77.449121] SWIOTLB is 0% full
[   82.449236] SWIOTLB is 0% full
[   87.449242] SWIOTLB is 0% full
[   92.449241] SWIOTLB is 0% full
[  172.449102] 0 [ehci_hcd 0000:0a:00.7] bounce: from:3839(slow:0)to:664 map:4486 unmap:4617 sync:0
[  172.449123] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:82 map:111 unmap:0 sync:0
[  172.449130] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:32 map:36 unmap:0 sync:0
[  172.449170] SWIOTLB is 0% full
[  177.449109] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5348(slow:0)to:524 map:5834 unmap:5952 sync:0
[  177.449131] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:76 map:112 unmap:0 sync:0
[  177.449138] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:4 map:6 unmap:0 sync:0
[  177.449178] SWIOTLB is 0% full
[  182.449143] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5349(slow:0)to:563 map:5899 unmap:5949 sync:0
[  182.449157] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:27 map:35 unmap:0 sync:0
[  182.449164] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:10 map:15 unmap:0 sync:0
[  182.449204] SWIOTLB is 0% full
[  187.449112] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5375(slow:0)to:592 map:5941 unmap:6022 sync:0
[  187.449126] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:46 map:69 unmap:0 sync:0
[  187.449133] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:9 map:12 unmap:0 sync:0
[  187.449173] SWIOTLB is 0% full
[  192.449183] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5360(slow:0)to:556 map:5890 unmap:5978 sync:0
[  192.449226] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:52 map:74 unmap:0 sync:0
[  192.449234] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:10 map:14 unmap:0 sync:0
[  192.449275] SWIOTLB is 0% full

And the devices do work ... so how does that work ...

Thx for your explanation so far !

--
Sander







>> 
>> 
>> --
>> Sander
>> 
>> 



-- 
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 Jan 15 11:34:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 11: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 1RmOKl-0005CE-0K; Sun, 15 Jan 2012 11:33:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <linux@eikelenboom.it>) id 1RmOKi-0005C5-H8
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 11:33:08 +0000
X-Env-Sender: linux@eikelenboom.it
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326627181!8555287!1
X-Originating-IP: [188.40.164.121]
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 10512 invoked from network); 15 Jan 2012 11:33: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-21.messagelabs.com with AES256-SHA encrypted SMTP;
	15 Jan 2012 11:33:01 -0000
Received: from 25-72-ftth.onsneteindhoven.nl ([88.159.72.25]:50172
	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 1RmOIS-0006Zi-61; Sun, 15 Jan 2012 12:30:48 +0100
Date: Sun, 15 Jan 2012 12:32:59 +0100
From: Sander Eikelenboom <linux@eikelenboom.it>
Organization: Eikelenboom IT services
X-Priority: 3 (Normal)
Message-ID: <1383590207.20120115123259@eikelenboom.it>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120113151307.GC5025@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.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


Friday, January 13, 2012, 4:13:07 PM, you 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.
>> 
>> > Good news is I am able to reproduce this with my 32-bit NIC with 3.2 domU:
>> 
>> > [  771.896140] SWIOTLB is 11% full
>> > [  776.896116] 0 [e1000 0000:00:00.0] bounce: from:222028(slow:0)to:2 map:222037 unmap:227220 sync:0
>> > [  776.896126] 1 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:5188 map:5188 unmap:0 sync:0
>> > [  776.896133] 3 [e1000 0000:00:00.0] bounce: from:0(slow:0)to:1 map:1 unmap:0 sync:0
>> 
>> > but interestingly enough, if I boot the guest as the first one I do not get these bounce
>> > requests. I will shortly bootup a Xen-O-Linux kernel and see if I get these same
>> > numbers.
>> 
>> 
>> I started to expiriment some more with what i encountered.
>> 
>> On dom0 i was seeing that my r8169 ethernet controllers where using bounce buffering with the dump-swiotlb module.
>> It was showing "12% full".
>> Checking in sysfs shows:
>> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
>> 32
>> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
>> 32
>> 
>> If i remember correctly wasn't the allocation for dom0 changed to be to the top of memory instead of low .. somewhere between 2.6.32 and 3.0 ?

> ? We never actually had dom0 support in the upstream kernel until 2.6.37.. The 2.6.32<->2.6.36 you are
> referring to must have been the trees that I spun up - but the implementation of SWIOTLB in them
> had not really changed.

>> Could that change cause the need for all devices to need bounce buffering  and could it therefore explain some people seeing more cpu usage for dom0 ?

> The issue I am seeing is not CPU usage in dom0, but rather the CPU usage in domU with guests.
> And that the older domU's (XenOLinux) do not have this.

> That I can't understand - the implementation in both cases _looks_ to do the same thing.
> There was one issue I found in the upstream one, but even with that fix I still
> get that "bounce" usage in domU.

> Interestingly enough, I get that only if I have launched, destroyed, launched, etc, the guest multiple
> times before I get this. Which leads me to believe this is not a kernel issue but that we
> are simply fragmented the Xen memory so much, so that when it launches the guest all of the
> memory is above 4GB. But that seems counter-intuive as by default Xen starts guests at the far end of
> memory (so on my 16GB box it would stick a 4GB guest at 12GB->16GB roughly). The SWIOTLB
> swizzles some memory under the 4GB , and this is where we get the bounce buffer effect
> (as the memory from 4GB is then copied to the memory 12GB->16GB).

> But it does not explain why on the first couple of starts I did not see this with pvops.
> And it does not seem to happen with the XenOLinux kernel, so there must be something else
> in here.

>> 
>> I have forced my r8169 to use 64bits dma mask (using use_dac=1)

> Ah yes.
>> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat consistent_dma_mask_bits
>> 32
>> serveerstertje:/sys/bus/pci/devices/0000:09:00.0# cat dma_mask_bits
>> 64
>> 
>> This results in dump-swiotlb reporting:
>> 
>> [ 1265.616106] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
>> [ 1265.625043] SWIOTLB is 0% full
>> [ 1270.626085] 0 [r8169 0000:08:00.0] bounce: from:6(slow:0)to:0 map:0 unmap:0 sync:12
>> [ 1270.635024] SWIOTLB is 0% full
>> [ 1275.635091] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10
>> [ 1275.644261] SWIOTLB is 0% full
>> [ 1280.654097] 0 [r8169 0000:09:00.0] bounce: from:5(slow:0)to:0 map:0 unmap:0 sync:10

> Which is what we expect. No need to bounce since the PCI adapter can reach memory
> above the 4GB mark.

>> 
>> 
>> 
>> So it has changed from 12% to 0%, although it still reports something about bouncing ? or am i mis interpreting stuff ?

> The bouncing can happen due to two cases:
>  - Memory is above 4GB
>  - Memory crosses a page-boundary (rarely happens).
>> 
>> 
>> Another thing i was wondering about, couldn't the hypervisor offer a small window in 32bit addressable mem to all (or only when pci passthrough is used) domU's to be used for DMA ?

> It does. That is what the Xen SWIOTLB does with "swizzling" the pages in its pool.
> But it can't do it for every part of memory. That is why there are DMA pools
> which are used by graphics adapters, video capture devices,storage and network
> drivers. They are used for small packet sizes so that the driver does not have
> to allocate DMA buffers when it gets a 100bytes ping response. But for large
> packets (say that ISO file you are downloading) it allocates memory on the fly
> and "maps" it into the PCI space using the DMA API. That "mapping" sets up
> an "physical memory" -> "guest memory" translation - and if that allocated
> memory is above 4GB, part of this mapping is to copy ("bounce") the memory
> under the 4GB (where XenSWIOTLB has allocated a pool), so that the adapter
> can physically fetch/put the data. Once that is completed it is "sync"-ed
> back, which is bouncing that data to the "allocated memory".


> So having a DMA pool is very good - and most drivers use it. The thing I can't
> figure out is:
>  - why the DVB do not seem to use it, even thought they look to use the videobuf_dma
>    driver.
>  - why the XenOLinux does not seem to have this problem (and this might be false - 
>    perhaps it does have this problem and it just takes a couple of guest launches,
>    destructions, starts, etc to actually see it).
>  - are there any flags in the domain builder to say: "ok, this domain is going to
>    service 32-bit cards, hence build the memory from 0->4GB". This seems like
>    a good know at first, but it probably is a bad idea (imagine using it by mistake
>    on every guest). And also nowadays most cards are PCIe and they can do 64-bit, so
>    it would not be that important in the future.
>> 
>> (oh yes, i haven't got i clue what i'm talking about ... so it probably make no sense at all :-) )

> Nonsense. You were on the correct path . Hopefully the level of details hasn't
> scared you off now :-)

Well it only gives some more questions :-)
The thing is, pci passthrough and especially the DMA part of it, all work behind the scenes without giving much output about the way it is actually working.

The thing i was wondering about is if my AMD IOMMU is actually doing something for PV guests.
When booting with iommu=off machine has 8GB mem, dom0 limited to 1024M and just starting one domU with iommu=soft, with pci-passthrough and the USB pci-cards with USB videograbbers attached to it, i would expect to find some bounce buffering going.

                (HV_START_LOW 18446603336221196288)
                (FEATURES '!writable_page_tables|pae_pgdir_above_4gb')
                (VIRT_BASE 18446744071562067968)
                (GUEST_VERSION 2.6)
                (PADDR_OFFSET 0)
                (GUEST_OS linux)
                (HYPERCALL_PAGE 18446744071578849280)
                (LOADER generic)
                (SUSPEND_CANCEL 1)
                (PAE_MODE yes)
                (ENTRY 18446744071594476032)
                (XEN_VERSION xen-3.0)

Still i only see:

[   47.449072] Starting SWIOTLB debug thread.
[   47.449090] swiotlb_start_thread: Go!
[   47.449262] xen_swiotlb_start_thread: Go!
[   52.449158] 0 [ehci_hcd 0000:0a:00.3] bounce: from:432(slow:0)to:1329 map:1756 unmap:1781 sync:0
[   52.449180] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:16 map:23 unmap:0 sync:0
[   52.449187] 2 [ohci_hcd 0000:0a:00.4] bounce: from:0(slow:0)to:4 map:5 unmap:0 sync:0
[   52.449226] SWIOTLB is 0% full
[   57.449180] 0 ehci_hcd 0000:0a:00.3 alloc coherent: 35, free: 0
[   57.449219] 1 ohci_hcd 0000:0a:00.6 alloc coherent: 1, free: 0
[   57.449265] SWIOTLB is 0% full
[   62.449176] SWIOTLB is 0% full
[   67.449336] SWIOTLB is 0% full
[   72.449279] SWIOTLB is 0% full
[   77.449121] SWIOTLB is 0% full
[   82.449236] SWIOTLB is 0% full
[   87.449242] SWIOTLB is 0% full
[   92.449241] SWIOTLB is 0% full
[  172.449102] 0 [ehci_hcd 0000:0a:00.7] bounce: from:3839(slow:0)to:664 map:4486 unmap:4617 sync:0
[  172.449123] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:82 map:111 unmap:0 sync:0
[  172.449130] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:32 map:36 unmap:0 sync:0
[  172.449170] SWIOTLB is 0% full
[  177.449109] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5348(slow:0)to:524 map:5834 unmap:5952 sync:0
[  177.449131] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:76 map:112 unmap:0 sync:0
[  177.449138] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:4 map:6 unmap:0 sync:0
[  177.449178] SWIOTLB is 0% full
[  182.449143] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5349(slow:0)to:563 map:5899 unmap:5949 sync:0
[  182.449157] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:27 map:35 unmap:0 sync:0
[  182.449164] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:10 map:15 unmap:0 sync:0
[  182.449204] SWIOTLB is 0% full
[  187.449112] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5375(slow:0)to:592 map:5941 unmap:6022 sync:0
[  187.449126] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:46 map:69 unmap:0 sync:0
[  187.449133] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:9 map:12 unmap:0 sync:0
[  187.449173] SWIOTLB is 0% full
[  192.449183] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5360(slow:0)to:556 map:5890 unmap:5978 sync:0
[  192.449226] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:52 map:74 unmap:0 sync:0
[  192.449234] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:10 map:14 unmap:0 sync:0
[  192.449275] SWIOTLB is 0% full

And the devices do work ... so how does that work ...

Thx for your explanation so far !

--
Sander







>> 
>> 
>> --
>> Sander
>> 
>> 



-- 
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 Jan 15 12:36:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmPJO-000602-C2; Sun, 15 Jan 2012 12:35:50 +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 1RmPJN-0005zx-CC
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:35:49 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326630926!52878854!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9406 invoked from network); 15 Jan 2012 12:35:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	15 Jan 2012 12:35:26 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0FCZhVF014507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 15 Jan 2012 07:35:44 -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 q0FCZdCx003404; Sun, 15 Jan 2012 07:35:41 -0500
Message-ID: <4F12C81B.5090106@redhat.com>
Date: Sun, 15 Jan 2012 14:35:39 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
In-Reply-To: <4F12AFFD.9020200@web.de>
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] [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>
Content-Type: text/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/15/2012 12:52 PM, Jan Kiszka wrote:
> On 2012-01-15 11:49, Jan Kiszka wrote:
> > On 2011-12-19 15:13, Avi Kivity wrote:
> >> 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.
> > 
> > This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.
>
> In fact, it breaks all vga types in that scenario.
>

An F14 guest works here.  More info, please.

-- 
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 Jan 15 12:36:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12:36:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmPJO-000602-C2; Sun, 15 Jan 2012 12:35:50 +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 1RmPJN-0005zx-CC
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:35:49 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326630926!52878854!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9406 invoked from network); 15 Jan 2012 12:35:26 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-27.messagelabs.com with SMTP;
	15 Jan 2012 12:35:26 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0FCZhVF014507
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 15 Jan 2012 07:35:44 -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 q0FCZdCx003404; Sun, 15 Jan 2012 07:35:41 -0500
Message-ID: <4F12C81B.5090106@redhat.com>
Date: Sun, 15 Jan 2012 14:35:39 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
In-Reply-To: <4F12AFFD.9020200@web.de>
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] [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>
Content-Type: text/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/15/2012 12:52 PM, Jan Kiszka wrote:
> On 2012-01-15 11:49, Jan Kiszka wrote:
> > On 2011-12-19 15:13, Avi Kivity wrote:
> >> 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.
> > 
> > This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.
>
> In fact, it breaks all vga types in that scenario.
>

An F14 guest works here.  More info, please.

-- 
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 Jan 15 12:41:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12: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 1RmPOV-000681-3k; Sun, 15 Jan 2012 12:41:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RmPOT-00067s-Lh
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:41:05 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326631259!11036017!1
X-Originating-IP: [217.72.192.234]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiA1NTQw\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiA1NTQw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3532 invoked from network); 15 Jan 2012 12:40:59 -0000
Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234)
	by server-11.tower-216.messagelabs.com with SMTP;
	15 Jan 2012 12:40:59 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate03.web.de (Postfix) with ESMTP id 1F8B51AFC54F8
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 13:40:59 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([95.157.56.37]) by smtp.web.de
	(mrweb002) with ESMTPA (Nemesis) id 0MWRkA-1SA27a0tAo-00XvoS;
	Sun, 15 Jan 2012 13:40:54 +0100
Message-ID: <4F12C953.1030107@web.de>
Date: Sun, 15 Jan 2012 13:40:51 +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: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
	<4F12C81B.5090106@redhat.com>
In-Reply-To: <4F12C81B.5090106@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:oggOPS9JEbkq5yAUJkmsyUYY8CWplnvzp9hfWEKWrW9
	K0seEKQzHGnH/elYjlTirMAQI+ykhV26P+8a3H7jX3MH0EG/8S
	Y9l47CUL9nMkqQ5QY9L/xhlNakSCVZWpXRuST+8KUiYD2b9DID
	10n8DZC4BXLdFDuKwokeSzkD7l9BNvKJ48vSAIx5RwO16I4MgO
	1o1SqJS+3VRNIGF9ZsnvA==
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] [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>
Content-Type: multipart/mixed; boundary="===============6866892096978734838=="
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)
--===============6866892096978734838==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigE464EA0C433772C9B84B1637"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE464EA0C433772C9B84B1637
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 2012-01-15 13:35, Avi Kivity wrote:
> On 01/15/2012 12:52 PM, Jan Kiszka wrote:
>> On 2012-01-15 11:49, Jan Kiszka wrote:
>>> On 2011-12-19 15:13, Avi Kivity wrote:
>>>> Drop the use of cpu_register_phys_memory_client() in favour of the n=
ew
>>>> MemoryListener API.  The new API simplifies the caller, since there =
is no
>>>> need to deal with splitting and merging slots; however this is not e=
xploited
>>>> in this patch.
>>>
>>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why ye=
t.
>>
>> In fact, it breaks all vga types in that scenario.
>>
>=20
> An F14 guest works here.  More info, please.

Just try to boot an openSUSE live image (or installation). Grub output
is corrupted, obviously dirty logging is not properly set up in that
graphic mode.

Jan


--------------enigE464EA0C433772C9B84B1637
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/

iEYEARECAAYFAk8SyVMACgkQitSsb3rl5xQG6wCdF3YdDtEXtol0fTSp/pq1CJ4n
u8oAnjUPxrYJEcw9e7jz204PbHznktMy
=CTU+
-----END PGP SIGNATURE-----

--------------enigE464EA0C433772C9B84B1637--


--===============6866892096978734838==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6866892096978734838==--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 12:41:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12: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 1RmPOV-000681-3k; Sun, 15 Jan 2012 12:41:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RmPOT-00067s-Lh
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:41:05 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326631259!11036017!1
X-Originating-IP: [217.72.192.234]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiA1NTQw\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIzNCA9PiA1NTQw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3532 invoked from network); 15 Jan 2012 12:40:59 -0000
Received: from fmmailgate03.web.de (HELO fmmailgate03.web.de) (217.72.192.234)
	by server-11.tower-216.messagelabs.com with SMTP;
	15 Jan 2012 12:40:59 -0000
Received: from moweb002.kundenserver.de (moweb002.kundenserver.de
	[172.19.20.108])
	by fmmailgate03.web.de (Postfix) with ESMTP id 1F8B51AFC54F8
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 13:40:59 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([95.157.56.37]) by smtp.web.de
	(mrweb002) with ESMTPA (Nemesis) id 0MWRkA-1SA27a0tAo-00XvoS;
	Sun, 15 Jan 2012 13:40:54 +0100
Message-ID: <4F12C953.1030107@web.de>
Date: Sun, 15 Jan 2012 13:40:51 +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: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
	<4F12C81B.5090106@redhat.com>
In-Reply-To: <4F12C81B.5090106@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:oggOPS9JEbkq5yAUJkmsyUYY8CWplnvzp9hfWEKWrW9
	K0seEKQzHGnH/elYjlTirMAQI+ykhV26P+8a3H7jX3MH0EG/8S
	Y9l47CUL9nMkqQ5QY9L/xhlNakSCVZWpXRuST+8KUiYD2b9DID
	10n8DZC4BXLdFDuKwokeSzkD7l9BNvKJ48vSAIx5RwO16I4MgO
	1o1SqJS+3VRNIGF9ZsnvA==
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] [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>
Content-Type: multipart/mixed; boundary="===============6866892096978734838=="
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)
--===============6866892096978734838==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigE464EA0C433772C9B84B1637"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE464EA0C433772C9B84B1637
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 2012-01-15 13:35, Avi Kivity wrote:
> On 01/15/2012 12:52 PM, Jan Kiszka wrote:
>> On 2012-01-15 11:49, Jan Kiszka wrote:
>>> On 2011-12-19 15:13, Avi Kivity wrote:
>>>> Drop the use of cpu_register_phys_memory_client() in favour of the n=
ew
>>>> MemoryListener API.  The new API simplifies the caller, since there =
is no
>>>> need to deal with splitting and merging slots; however this is not e=
xploited
>>>> in this patch.
>>>
>>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why ye=
t.
>>
>> In fact, it breaks all vga types in that scenario.
>>
>=20
> An F14 guest works here.  More info, please.

Just try to boot an openSUSE live image (or installation). Grub output
is corrupted, obviously dirty logging is not properly set up in that
graphic mode.

Jan


--------------enigE464EA0C433772C9B84B1637
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/

iEYEARECAAYFAk8SyVMACgkQitSsb3rl5xQG6wCdF3YdDtEXtol0fTSp/pq1CJ4n
u8oAnjUPxrYJEcw9e7jz204PbHznktMy
=CTU+
-----END PGP SIGNATURE-----

--------------enigE464EA0C433772C9B84B1637--


--===============6866892096978734838==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6866892096978734838==--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 12:50:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12: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 1RmPXA-0006KX-4e; Sun, 15 Jan 2012 12:50:04 +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 1RmPX8-0006KS-5v
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:50:02 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326631789!10900777!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21904 invoked from network); 15 Jan 2012 12:49:55 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	15 Jan 2012 12:49: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 q0FCnktZ021459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 15 Jan 2012 07:49:46 -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 q0FCnhYm026317; Sun, 15 Jan 2012 07:49:44 -0500
Message-ID: <4F12CB67.2010305@redhat.com>
Date: Sun, 15 Jan 2012 14:49:43 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
	<4F12C81B.5090106@redhat.com> <4F12C953.1030107@web.de>
In-Reply-To: <4F12C953.1030107@web.de>
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] [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>
Content-Type: text/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/15/2012 02:40 PM, Jan Kiszka wrote:
> On 2012-01-15 13:35, Avi Kivity wrote:
> > On 01/15/2012 12:52 PM, Jan Kiszka wrote:
> >> On 2012-01-15 11:49, Jan Kiszka wrote:
> >>> On 2011-12-19 15:13, Avi Kivity wrote:
> >>>> 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.
> >>>
> >>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.
> >>
> >> In fact, it breaks all vga types in that scenario.
> >>
> > 
> > An F14 guest works here.  More info, please.
>
> Just try to boot an openSUSE live image (or installation). Grub output
> is corrupted, obviously dirty logging is not properly set up in that
> graphic mode.
>

Downloading now.

-- 
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 Jan 15 12:50:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12: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 1RmPXA-0006KX-4e; Sun, 15 Jan 2012 12:50:04 +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 1RmPX8-0006KS-5v
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:50:02 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326631789!10900777!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21904 invoked from network); 15 Jan 2012 12:49:55 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-216.messagelabs.com with SMTP;
	15 Jan 2012 12:49: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 q0FCnktZ021459
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 15 Jan 2012 07:49:46 -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 q0FCnhYm026317; Sun, 15 Jan 2012 07:49:44 -0500
Message-ID: <4F12CB67.2010305@redhat.com>
Date: Sun, 15 Jan 2012 14:49:43 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
	<4F12C81B.5090106@redhat.com> <4F12C953.1030107@web.de>
In-Reply-To: <4F12C953.1030107@web.de>
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] [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>
Content-Type: text/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/15/2012 02:40 PM, Jan Kiszka wrote:
> On 2012-01-15 13:35, Avi Kivity wrote:
> > On 01/15/2012 12:52 PM, Jan Kiszka wrote:
> >> On 2012-01-15 11:49, Jan Kiszka wrote:
> >>> On 2011-12-19 15:13, Avi Kivity wrote:
> >>>> 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.
> >>>
> >>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.
> >>
> >> In fact, it breaks all vga types in that scenario.
> >>
> > 
> > An F14 guest works here.  More info, please.
>
> Just try to boot an openSUSE live image (or installation). Grub output
> is corrupted, obviously dirty logging is not properly set up in that
> graphic mode.
>

Downloading now.

-- 
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 Jan 15 12:50:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmPXV-0006LY-HT; Sun, 15 Jan 2012 12:50:25 +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 1RmPXU-0006LE-Ax
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:50:24 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326631817!10963105!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6159 invoked from network); 15 Jan 2012 12:50:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	15 Jan 2012 12:50:17 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0FCoFlR017593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 15 Jan 2012 07:50:15 -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 q0FCoBEC005325; Sun, 15 Jan 2012 07:50:12 -0500
Message-ID: <4F12CB82.5050509@redhat.com>
Date: Sun, 15 Jan 2012 14:50:10 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
	<4F12C81B.5090106@redhat.com> <4F12C953.1030107@web.de>
	<4F12CB67.2010305@redhat.com>
In-Reply-To: <4F12CB67.2010305@redhat.com>
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] [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>
Content-Type: text/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/15/2012 02:49 PM, Avi Kivity wrote:
> On 01/15/2012 02:40 PM, Jan Kiszka wrote:
> > On 2012-01-15 13:35, Avi Kivity wrote:
> > > On 01/15/2012 12:52 PM, Jan Kiszka wrote:
> > >> On 2012-01-15 11:49, Jan Kiszka wrote:
> > >>> On 2011-12-19 15:13, Avi Kivity wrote:
> > >>>> 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.
> > >>>
> > >>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.
> > >>
> > >> In fact, it breaks all vga types in that scenario.
> > >>
> > > 
> > > An F14 guest works here.  More info, please.
> >
> > Just try to boot an openSUSE live image (or installation). Grub output
> > is corrupted, obviously dirty logging is not properly set up in that
> > graphic mode.
> >
>
> Downloading now.
>

Wait, isn't opensuse grub2 based?  Which version should I test?

-- 
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 Jan 15 12:50:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12:50:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmPXV-0006LY-HT; Sun, 15 Jan 2012 12:50:25 +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 1RmPXU-0006LE-Ax
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:50:24 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326631817!10963105!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6159 invoked from network); 15 Jan 2012 12:50:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-182.messagelabs.com with SMTP;
	15 Jan 2012 12:50:17 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0FCoFlR017593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Sun, 15 Jan 2012 07:50:15 -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 q0FCoBEC005325; Sun, 15 Jan 2012 07:50:12 -0500
Message-ID: <4F12CB82.5050509@redhat.com>
Date: Sun, 15 Jan 2012 14:50:10 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Kiszka <jan.kiszka@web.de>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
	<4F12C81B.5090106@redhat.com> <4F12C953.1030107@web.de>
	<4F12CB67.2010305@redhat.com>
In-Reply-To: <4F12CB67.2010305@redhat.com>
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] [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>
Content-Type: text/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/15/2012 02:49 PM, Avi Kivity wrote:
> On 01/15/2012 02:40 PM, Jan Kiszka wrote:
> > On 2012-01-15 13:35, Avi Kivity wrote:
> > > On 01/15/2012 12:52 PM, Jan Kiszka wrote:
> > >> On 2012-01-15 11:49, Jan Kiszka wrote:
> > >>> On 2011-12-19 15:13, Avi Kivity wrote:
> > >>>> 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.
> > >>>
> > >>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why yet.
> > >>
> > >> In fact, it breaks all vga types in that scenario.
> > >>
> > > 
> > > An F14 guest works here.  More info, please.
> >
> > Just try to boot an openSUSE live image (or installation). Grub output
> > is corrupted, obviously dirty logging is not properly set up in that
> > graphic mode.
> >
>
> Downloading now.
>

Wait, isn't opensuse grub2 based?  Which version should I test?

-- 
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 Jan 15 12:54:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12:54:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmPap-0006YX-5H; Sun, 15 Jan 2012 12:53:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RmPao-0006Xo-6U
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:53:50 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326632023!11105672!1
X-Originating-IP: [217.72.192.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyNyA9PiA3NzA4\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyNyA9PiA3NzA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15047 invoked from network); 15 Jan 2012 12:53:43 -0000
Received: from fmmailgate02.web.de (HELO fmmailgate02.web.de) (217.72.192.227)
	by server-5.tower-216.messagelabs.com with SMTP;
	15 Jan 2012 12:53:43 -0000
Received: from moweb001.kundenserver.de (moweb001.kundenserver.de
	[172.19.20.114])
	by fmmailgate02.web.de (Postfix) with ESMTP id 3AEB81BFC5FC2
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 13:53:42 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([95.157.56.37]) by smtp.web.de
	(mrweb001) with ESMTPA (Nemesis) id 0LkPW7-1SNON51WbT-00cHdO;
	Sun, 15 Jan 2012 13:53:41 +0100
Message-ID: <4F12CC53.9080005@web.de>
Date: Sun, 15 Jan 2012 13:53:39 +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: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
	<4F12C81B.5090106@redhat.com> <4F12C953.1030107@web.de>
	<4F12CB67.2010305@redhat.com> <4F12CB82.5050509@redhat.com>
In-Reply-To: <4F12CB82.5050509@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:amqbZAxYc5yCoQEhxWiZkJt/YRm6A0IXXqvGyfjSXt8
	n7vN9ZGtiL1Rt/yuw2UqJSGj1hJ8moG5zPZ6cT3O53PefblHkn
	y3J/Z0BlYae03jSwVAWmUaVij4scdRUyYojM4ckwl7bwMPbNuu
	2/1Ky8UY3tGICEW1wj/tqIxyGR0bZo4WjwtvCeGu8GBmaf3KY5
	1+t92odSFGT+YJOB+GqFA==
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] [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>
Content-Type: multipart/mixed; boundary="===============6069475969722612893=="
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)
--===============6069475969722612893==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig1B4E6BC8AA4DC54C923AF41F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1B4E6BC8AA4DC54C923AF41F
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 2012-01-15 13:50, Avi Kivity wrote:
> On 01/15/2012 02:49 PM, Avi Kivity wrote:
>> On 01/15/2012 02:40 PM, Jan Kiszka wrote:
>>> On 2012-01-15 13:35, Avi Kivity wrote:
>>>> On 01/15/2012 12:52 PM, Jan Kiszka wrote:
>>>>> On 2012-01-15 11:49, Jan Kiszka wrote:
>>>>>> On 2011-12-19 15:13, Avi Kivity wrote:
>>>>>>> Drop the use of cpu_register_phys_memory_client() in favour of th=
e new
>>>>>>> MemoryListener API.  The new API simplifies the caller, since the=
re is no
>>>>>>> need to deal with splitting and merging slots; however this is no=
t exploited
>>>>>>> in this patch.
>>>>>>
>>>>>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why=
 yet.
>>>>>
>>>>> In fact, it breaks all vga types in that scenario.
>>>>>
>>>>
>>>> An F14 guest works here.  More info, please.
>>>
>>> Just try to boot an openSUSE live image (or installation). Grub outpu=
t
>>> is corrupted, obviously dirty logging is not properly set up in that
>>> graphic mode.
>>>
>>
>> Downloading now.
>>
>=20
> Wait, isn't opensuse grub2 based?  Which version should I test?
>=20

My test case is 11.4-based, but I think to remember 12.1 is also still
grub1 (luckily...).

Jan


--------------enig1B4E6BC8AA4DC54C923AF41F
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/

iEYEARECAAYFAk8SzFMACgkQitSsb3rl5xRN3ACfdLshWVpvtiqoO/c8vaAdw61q
IZYAnihzVCcrvEtiorMnpa4pXeGz43+8
=TBGN
-----END PGP SIGNATURE-----

--------------enig1B4E6BC8AA4DC54C923AF41F--


--===============6069475969722612893==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6069475969722612893==--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 12:54:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 12:54:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmPap-0006YX-5H; Sun, 15 Jan 2012 12:53:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jan.kiszka@web.de>) id 1RmPao-0006Xo-6U
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 12:53:50 +0000
X-Env-Sender: jan.kiszka@web.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326632023!11105672!1
X-Originating-IP: [217.72.192.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyNyA9PiA3NzA4\n,sa_preprocessor: 
	QmFkIElQOiAyMTcuNzIuMTkyLjIyNyA9PiA3NzA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15047 invoked from network); 15 Jan 2012 12:53:43 -0000
Received: from fmmailgate02.web.de (HELO fmmailgate02.web.de) (217.72.192.227)
	by server-5.tower-216.messagelabs.com with SMTP;
	15 Jan 2012 12:53:43 -0000
Received: from moweb001.kundenserver.de (moweb001.kundenserver.de
	[172.19.20.114])
	by fmmailgate02.web.de (Postfix) with ESMTP id 3AEB81BFC5FC2
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 13:53:42 +0100 (CET)
Received: from mchn199C.mchp.siemens.de ([95.157.56.37]) by smtp.web.de
	(mrweb001) with ESMTPA (Nemesis) id 0LkPW7-1SNON51WbT-00cHdO;
	Sun, 15 Jan 2012 13:53:41 +0100
Message-ID: <4F12CC53.9080005@web.de>
Date: Sun, 15 Jan 2012 13:53:39 +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: Avi Kivity <avi@redhat.com>
References: <1324304024-11220-1-git-send-email-avi@redhat.com>
	<1324304024-11220-14-git-send-email-avi@redhat.com>
	<4F12AF25.9050506@web.de> <4F12AFFD.9020200@web.de>
	<4F12C81B.5090106@redhat.com> <4F12C953.1030107@web.de>
	<4F12CB67.2010305@redhat.com> <4F12CB82.5050509@redhat.com>
In-Reply-To: <4F12CB82.5050509@redhat.com>
X-Enigmail-Version: 1.3.4
X-Provags-ID: V02:K0:amqbZAxYc5yCoQEhxWiZkJt/YRm6A0IXXqvGyfjSXt8
	n7vN9ZGtiL1Rt/yuw2UqJSGj1hJ8moG5zPZ6cT3O53PefblHkn
	y3J/Z0BlYae03jSwVAWmUaVij4scdRUyYojM4ckwl7bwMPbNuu
	2/1Ky8UY3tGICEW1wj/tqIxyGR0bZo4WjwtvCeGu8GBmaf3KY5
	1+t92odSFGT+YJOB+GqFA==
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] [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>
Content-Type: multipart/mixed; boundary="===============6069475969722612893=="
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)
--===============6069475969722612893==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig1B4E6BC8AA4DC54C923AF41F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1B4E6BC8AA4DC54C923AF41F
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On 2012-01-15 13:50, Avi Kivity wrote:
> On 01/15/2012 02:49 PM, Avi Kivity wrote:
>> On 01/15/2012 02:40 PM, Jan Kiszka wrote:
>>> On 2012-01-15 13:35, Avi Kivity wrote:
>>>> On 01/15/2012 12:52 PM, Jan Kiszka wrote:
>>>>> On 2012-01-15 11:49, Jan Kiszka wrote:
>>>>>> On 2011-12-19 15:13, Avi Kivity wrote:
>>>>>>> Drop the use of cpu_register_phys_memory_client() in favour of th=
e new
>>>>>>> MemoryListener API.  The new API simplifies the caller, since the=
re is no
>>>>>>> need to deal with splitting and merging slots; however this is no=
t exploited
>>>>>>> in this patch.
>>>>>>
>>>>>> This breaks graphical grub1 with cirrus-vga in KVM mode. Dunno why=
 yet.
>>>>>
>>>>> In fact, it breaks all vga types in that scenario.
>>>>>
>>>>
>>>> An F14 guest works here.  More info, please.
>>>
>>> Just try to boot an openSUSE live image (or installation). Grub outpu=
t
>>> is corrupted, obviously dirty logging is not properly set up in that
>>> graphic mode.
>>>
>>
>> Downloading now.
>>
>=20
> Wait, isn't opensuse grub2 based?  Which version should I test?
>=20

My test case is 11.4-based, but I think to remember 12.1 is also still
grub1 (luckily...).

Jan


--------------enig1B4E6BC8AA4DC54C923AF41F
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/

iEYEARECAAYFAk8SzFMACgkQitSsb3rl5xRN3ACfdLshWVpvtiqoO/c8vaAdw61q
IZYAnihzVCcrvEtiorMnpa4pXeGz43+8
=TBGN
-----END PGP SIGNATURE-----

--------------enig1B4E6BC8AA4DC54C923AF41F--


--===============6069475969722612893==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6069475969722612893==--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 14:48:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 14:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmRNC-0007EU-Lw; Sun, 15 Jan 2012 14:47: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 1RmRNA-0007EP-9D
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 14:47:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326638865!7888905!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30714 invoked from network); 15 Jan 2012 14:47:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jan 2012 14:47:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,514,1320624000"; d="scan'208";a="10030383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 14:47: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; Sun, 15 Jan 2012 14:47:43 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RmRN1-0003ZF-Jz;
	Sun, 15 Jan 2012 14:47:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmRN1-0001eR-Ix;
	Sun, 15 Jan 2012 14:47:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10749-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 14:47:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10749: 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 10749 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10749/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 14:48:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 14:48:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmRNC-0007EU-Lw; Sun, 15 Jan 2012 14:47: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 1RmRNA-0007EP-9D
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 14:47:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326638865!7888905!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30714 invoked from network); 15 Jan 2012 14:47:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jan 2012 14:47:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,514,1320624000"; d="scan'208";a="10030383"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 14:47: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; Sun, 15 Jan 2012 14:47:43 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RmRN1-0003ZF-Jz;
	Sun, 15 Jan 2012 14:47:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmRN1-0001eR-Ix;
	Sun, 15 Jan 2012 14:47:43 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10749-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 14:47:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10749: 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 10749 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10749/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 17:35:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 17:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmTz1-00007O-23; Sun, 15 Jan 2012 17:35:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmTyz-00007F-8E
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 17:35:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326648899!8359125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31015 invoked from network); 15 Jan 2012 17:34:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jan 2012 17:34:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,514,1320624000"; d="scan'208";a="10031319"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 17:34: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; Sun, 15 Jan 2012 17:34:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RmTys-0004Th-Ft;
	Sun, 15 Jan 2012 17:34:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmTys-00064M-FT;
	Sun, 15 Jan 2012 17:34:58 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10752-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 17:34:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10752: 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 10752 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10752/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 17:35:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 17:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmTz1-00007O-23; Sun, 15 Jan 2012 17:35:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmTyz-00007F-8E
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 17:35:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326648899!8359125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31015 invoked from network); 15 Jan 2012 17:34:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jan 2012 17:34:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,514,1320624000"; d="scan'208";a="10031319"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 17:34: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; Sun, 15 Jan 2012 17:34:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RmTys-0004Th-Ft;
	Sun, 15 Jan 2012 17:34:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmTys-00064M-FT;
	Sun, 15 Jan 2012 17:34:58 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10752-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 17:34:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10752: 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 10752 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10752/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 20:45:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 20:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmWwV-0001W4-6X; Sun, 15 Jan 2012 20:44:43 +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 1RmWwU-0001Vz-4Z
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 20:44:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326660272!10981670!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32302 invoked from network); 15 Jan 2012 20:44:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jan 2012 20:44:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,514,1320624000"; d="scan'208";a="10032196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 20:44: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; Sun, 15 Jan 2012 20:44: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 1RmWwJ-0005XZ-3D;
	Sun, 15 Jan 2012 20:44:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmWwJ-0007ZF-2e;
	Sun, 15 Jan 2012 20:44:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10755-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 20:44:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10755: 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 10755 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10755/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 20:45:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 20:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmWwV-0001W4-6X; Sun, 15 Jan 2012 20:44:43 +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 1RmWwU-0001Vz-4Z
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 20:44:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326660272!10981670!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32302 invoked from network); 15 Jan 2012 20:44:32 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jan 2012 20:44:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,514,1320624000"; d="scan'208";a="10032196"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 20:44: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; Sun, 15 Jan 2012 20:44: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 1RmWwJ-0005XZ-3D;
	Sun, 15 Jan 2012 20:44:31 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmWwJ-0007ZF-2e;
	Sun, 15 Jan 2012 20:44:31 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10755-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 20:44:31 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10755: 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 10755 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10755/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 20:55:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 20: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 1RmX5z-0001iE-8d; Sun, 15 Jan 2012 20:54:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1RmX5x-0001i4-Sf
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 20:54:30 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326660862!9228892!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDMzMTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15250 invoked from network); 15 Jan 2012 20:54:23 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jan 2012 20:54:23 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q0FKs61L011252
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:54:10 GMT
Received: from vega-a.dur.ac.uk (vega-a.dur.ac.uk [129.234.250.133])
	by smtphost1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q0FKrl8v031962
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:53:47 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 q0FKrlTN006865
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:53:47 GMT
Received: from localhost (dcl0may@localhost)
	by vega-a.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q0FKrkep006861
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:53:47 GMT
Date: Sun, 15 Jan 2012 20:53:46 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1201152031420.29311@vega-a.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1070034885-1326660827=:29311"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q0FKs61L011252
Subject: [Xen-devel] [PATCH] compile fixes for xen with gcc-4.7 on Fedora 17
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-1070034885-1326660827=:29311
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

I needed the xen-4.1 equivalent of the attached patch to get xen to 
compile on Fedora 17 with gcc-4.7. It seems that gcc-4.7 doesn't like it 
when you mix definitions of a function as
void function(void);
and
asmlinkage void function(void);
in .c and .h files. The patch (for 4.2) fixes three cases where they are 
inconsistent.

 	Michael Young
--8323329-1070034885-1326660827=:29311
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc47fixes.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc47fixes.patch

Rml4IGNvbXBpbGUgcHJvYmxlbXMgd2l0aCBnY2MtNC43IG9uIEZlZG9yYSAx
NyBieSBhZGRpbmcgYXNtbGlua2FnZQ0KZGVmaW5pdGlvbnMgdG8gbWFrZSB1
c2FnZSBpbiAuYyBhbmQgLmggZmlsZXMgY29uc2lzdGVudC4NCiogdG8gSVJR
X05BTUUgaW4geGVuL2FyY2gveDg2L2k4MjU5LmMgdG8gbWF0Y2ggdGhhdCBp
bg0KICB4ZW4vaW5jbHVkZS9hc20teDg2L3g4Nl8zMi9hc21fZGVmbnMuaCBh
bmQNCiAgeGVuL2luY2x1ZGUvYXNtLXg4Ni94ODZfNjQvYXNtX2RlZm5zLmgN
CiogdG8gc3ZtX2ludHJfYXNzaXN0IGluIHhlbi9pbmNsdWRlL2FzbS14ODYv
aHZtL3N2bS9pbnRyLmggdG8gbWF0Y2ggdGhhdCBpbg0KICB4ZW4vYXJjaC94
ODYvaHZtL3N2bS9pbnRyLmMNCiogdG8geGVuL2luY2x1ZGUvYXNtLXg4Ni9o
dm0vdm14L3ZteC5oIHRvIG1hdGNoIHRoYXQgaW4NCiAgeGVuL2FyY2gveDg2
L2h2bS92bXgvdm14LmMNClNpZ25lZC1vZmYtYnk6IE1pY2hhZWwgWW91bmcg
PG0uYS55b3VuZ0BkdXJoYW0uYWMudWs+DQoNCi0tLSBhL3hlbi9hcmNoL3g4
Ni9pODI1OS5jCTIwMTItMDEtMTUgMTk6NDI6NDMuMDM2MzkyNjU1ICswMDAw
DQorKysgYi94ZW4vYXJjaC94ODYvaTgyNTkuYwkyMDEyLTAxLTE1IDE5OjQ1
OjAyLjA0MDY1NDg2NCArMDAwMA0KQEAgLTY0LDcgKzY0LDcgQEANCiAgICAg
SVJRKHgsOCksIElSUSh4LDkpLCBJUlEoeCxhKSwgSVJRKHgsYiksIFwNCiAg
ICAgSVJRKHgsYyksIElSUSh4LGQpLCBJUlEoeCxlKSwgSVJRKHgsZikNCiAN
Ci0gICAgc3RhdGljIHZvaWQgKCppbnRlcnJ1cHRbXSkodm9pZCkgPSB7DQor
ICAgIHN0YXRpYyB2b2lkIChhc21saW5rYWdlICppbnRlcnJ1cHRbXSkodm9p
ZCkgPSB7DQogICAgICAgICBJUlFMSVNUXzE2KDB4MCksIElSUUxJU1RfMTYo
MHgxKSwgSVJRTElTVF8xNigweDIpLCBJUlFMSVNUXzE2KDB4MyksDQogICAg
ICAgICBJUlFMSVNUXzE2KDB4NCksIElSUUxJU1RfMTYoMHg1KSwgSVJRTElT
VF8xNigweDYpLCBJUlFMSVNUXzE2KDB4NyksDQogICAgICAgICBJUlFMSVNU
XzE2KDB4OCksIElSUUxJU1RfMTYoMHg5KSwgSVJRTElTVF8xNigweGEpLCBJ
UlFMSVNUXzE2KDB4YiksDQotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2h2
bS9zdm0vaW50ci5oCTIwMTItMDEtMTUgMTk6NDY6MjcuODIzNTgyNDMzICsw
MDAwDQorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9zdm0vaW50ci5o
CTIwMTItMDEtMTUgMTk6NTA6MDguMDYyODI5MDYzICswMDAwDQpAQCAtMjEs
NiArMjEsNiBAQA0KICNpZm5kZWYgX19BU01fWDg2X0hWTV9TVk1fSU5UUl9I
X18NCiAjZGVmaW5lIF9fQVNNX1g4Nl9IVk1fU1ZNX0lOVFJfSF9fDQogDQot
dm9pZCBzdm1faW50cl9hc3Npc3Qodm9pZCk7DQorYXNtbGlua2FnZSB2b2lk
IHN2bV9pbnRyX2Fzc2lzdCh2b2lkKTsNCiANCiAjZW5kaWYgLyogX19BU01f
WDg2X0hWTV9TVk1fSU5UUl9IX18gKi8NCi0tLSBhL3hlbi9pbmNsdWRlL2Fz
bS14ODYvaHZtL3ZteC92bXguaAkyMDEyLTAxLTE1IDE5OjUwOjU5LjQ0NDE4
NjcwNiArMDAwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14
L3ZteC5oCTIwMTItMDEtMTUgMTk6NTE6NTguNTczNDQ3NDg5ICswMDAwDQpA
QCAtNjMsNyArNjMsNyBAQA0KIA0KIHZvaWQgdm14X2FzbV92bWV4aXRfaGFu
ZGxlcihzdHJ1Y3QgY3B1X3VzZXJfcmVncyk7DQogdm9pZCB2bXhfYXNtX2Rv
X3ZtZW50cnkodm9pZCk7DQotdm9pZCB2bXhfaW50cl9hc3Npc3Qodm9pZCk7
DQorYXNtbGlua2FnZSB2b2lkIHZteF9pbnRyX2Fzc2lzdCh2b2lkKTsNCiB2
b2lkIHZteF9kb19yZXN1bWUoc3RydWN0IHZjcHUgKik7DQogdm9pZCB2bXhf
dmxhcGljX21zcl9jaGFuZ2VkKHN0cnVjdCB2Y3B1ICp2KTsNCiB2b2lkIHZt
eF9yZWFsbW9kZShzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncyk7DQo=

--8323329-1070034885-1326660827=:29311
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1070034885-1326660827=:29311--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 20:55:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 20: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 1RmX5z-0001iE-8d; Sun, 15 Jan 2012 20:54:31 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <m.a.young@durham.ac.uk>) id 1RmX5x-0001i4-Sf
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 20:54:30 +0000
X-Env-Sender: m.a.young@durham.ac.uk
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326660862!9228892!1
X-Originating-IP: [129.234.248.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTI5LjIzNC4yNDguMSA9PiAxMDMzMTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15250 invoked from network); 15 Jan 2012 20:54:23 -0000
Received: from hermes1.dur.ac.uk (HELO hermes1.dur.ac.uk) (129.234.248.1)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 15 Jan 2012 20:54:23 -0000
Received: from smtphost1.dur.ac.uk (smtphost1.dur.ac.uk [129.234.252.1])
	by hermes1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q0FKs61L011252
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:54:10 GMT
Received: from vega-a.dur.ac.uk (vega-a.dur.ac.uk [129.234.250.133])
	by smtphost1.dur.ac.uk (8.13.8/8.13.7) with ESMTP id q0FKrl8v031962
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:53:47 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 q0FKrlTN006865
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:53:47 GMT
Received: from localhost (dcl0may@localhost)
	by vega-a.dur.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id q0FKrkep006861
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:53:47 GMT
Date: Sun, 15 Jan 2012 20:53:46 +0000 (GMT)
From: M A Young <m.a.young@durham.ac.uk>
To: xen-devel@lists.xensource.com
Message-ID: <alpine.DEB.2.00.1201152031420.29311@vega-a.dur.ac.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1070034885-1326660827=:29311"
X-DurhamAcUk-MailScanner: Found to be clean, Found to be clean
X-DurhamAcUk-MailScanner-ID: q0FKs61L011252
Subject: [Xen-devel] [PATCH] compile fixes for xen with gcc-4.7 on Fedora 17
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-1070034885-1326660827=:29311
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

I needed the xen-4.1 equivalent of the attached patch to get xen to 
compile on Fedora 17 with gcc-4.7. It seems that gcc-4.7 doesn't like it 
when you mix definitions of a function as
void function(void);
and
asmlinkage void function(void);
in .c and .h files. The patch (for 4.2) fixes three cases where they are 
inconsistent.

 	Michael Young
--8323329-1070034885-1326660827=:29311
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=gcc47fixes.patch
Content-Transfer-Encoding: BASE64
Content-Description: 
Content-Disposition: attachment; filename=gcc47fixes.patch

Rml4IGNvbXBpbGUgcHJvYmxlbXMgd2l0aCBnY2MtNC43IG9uIEZlZG9yYSAx
NyBieSBhZGRpbmcgYXNtbGlua2FnZQ0KZGVmaW5pdGlvbnMgdG8gbWFrZSB1
c2FnZSBpbiAuYyBhbmQgLmggZmlsZXMgY29uc2lzdGVudC4NCiogdG8gSVJR
X05BTUUgaW4geGVuL2FyY2gveDg2L2k4MjU5LmMgdG8gbWF0Y2ggdGhhdCBp
bg0KICB4ZW4vaW5jbHVkZS9hc20teDg2L3g4Nl8zMi9hc21fZGVmbnMuaCBh
bmQNCiAgeGVuL2luY2x1ZGUvYXNtLXg4Ni94ODZfNjQvYXNtX2RlZm5zLmgN
CiogdG8gc3ZtX2ludHJfYXNzaXN0IGluIHhlbi9pbmNsdWRlL2FzbS14ODYv
aHZtL3N2bS9pbnRyLmggdG8gbWF0Y2ggdGhhdCBpbg0KICB4ZW4vYXJjaC94
ODYvaHZtL3N2bS9pbnRyLmMNCiogdG8geGVuL2luY2x1ZGUvYXNtLXg4Ni9o
dm0vdm14L3ZteC5oIHRvIG1hdGNoIHRoYXQgaW4NCiAgeGVuL2FyY2gveDg2
L2h2bS92bXgvdm14LmMNClNpZ25lZC1vZmYtYnk6IE1pY2hhZWwgWW91bmcg
PG0uYS55b3VuZ0BkdXJoYW0uYWMudWs+DQoNCi0tLSBhL3hlbi9hcmNoL3g4
Ni9pODI1OS5jCTIwMTItMDEtMTUgMTk6NDI6NDMuMDM2MzkyNjU1ICswMDAw
DQorKysgYi94ZW4vYXJjaC94ODYvaTgyNTkuYwkyMDEyLTAxLTE1IDE5OjQ1
OjAyLjA0MDY1NDg2NCArMDAwMA0KQEAgLTY0LDcgKzY0LDcgQEANCiAgICAg
SVJRKHgsOCksIElSUSh4LDkpLCBJUlEoeCxhKSwgSVJRKHgsYiksIFwNCiAg
ICAgSVJRKHgsYyksIElSUSh4LGQpLCBJUlEoeCxlKSwgSVJRKHgsZikNCiAN
Ci0gICAgc3RhdGljIHZvaWQgKCppbnRlcnJ1cHRbXSkodm9pZCkgPSB7DQor
ICAgIHN0YXRpYyB2b2lkIChhc21saW5rYWdlICppbnRlcnJ1cHRbXSkodm9p
ZCkgPSB7DQogICAgICAgICBJUlFMSVNUXzE2KDB4MCksIElSUUxJU1RfMTYo
MHgxKSwgSVJRTElTVF8xNigweDIpLCBJUlFMSVNUXzE2KDB4MyksDQogICAg
ICAgICBJUlFMSVNUXzE2KDB4NCksIElSUUxJU1RfMTYoMHg1KSwgSVJRTElT
VF8xNigweDYpLCBJUlFMSVNUXzE2KDB4NyksDQogICAgICAgICBJUlFMSVNU
XzE2KDB4OCksIElSUUxJU1RfMTYoMHg5KSwgSVJRTElTVF8xNigweGEpLCBJ
UlFMSVNUXzE2KDB4YiksDQotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L2h2
bS9zdm0vaW50ci5oCTIwMTItMDEtMTUgMTk6NDY6MjcuODIzNTgyNDMzICsw
MDAwDQorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9zdm0vaW50ci5o
CTIwMTItMDEtMTUgMTk6NTA6MDguMDYyODI5MDYzICswMDAwDQpAQCAtMjEs
NiArMjEsNiBAQA0KICNpZm5kZWYgX19BU01fWDg2X0hWTV9TVk1fSU5UUl9I
X18NCiAjZGVmaW5lIF9fQVNNX1g4Nl9IVk1fU1ZNX0lOVFJfSF9fDQogDQot
dm9pZCBzdm1faW50cl9hc3Npc3Qodm9pZCk7DQorYXNtbGlua2FnZSB2b2lk
IHN2bV9pbnRyX2Fzc2lzdCh2b2lkKTsNCiANCiAjZW5kaWYgLyogX19BU01f
WDg2X0hWTV9TVk1fSU5UUl9IX18gKi8NCi0tLSBhL3hlbi9pbmNsdWRlL2Fz
bS14ODYvaHZtL3ZteC92bXguaAkyMDEyLTAxLTE1IDE5OjUwOjU5LjQ0NDE4
NjcwNiArMDAwMA0KKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9odm0vdm14
L3ZteC5oCTIwMTItMDEtMTUgMTk6NTE6NTguNTczNDQ3NDg5ICswMDAwDQpA
QCAtNjMsNyArNjMsNyBAQA0KIA0KIHZvaWQgdm14X2FzbV92bWV4aXRfaGFu
ZGxlcihzdHJ1Y3QgY3B1X3VzZXJfcmVncyk7DQogdm9pZCB2bXhfYXNtX2Rv
X3ZtZW50cnkodm9pZCk7DQotdm9pZCB2bXhfaW50cl9hc3Npc3Qodm9pZCk7
DQorYXNtbGlua2FnZSB2b2lkIHZteF9pbnRyX2Fzc2lzdCh2b2lkKTsNCiB2
b2lkIHZteF9kb19yZXN1bWUoc3RydWN0IHZjcHUgKik7DQogdm9pZCB2bXhf
dmxhcGljX21zcl9jaGFuZ2VkKHN0cnVjdCB2Y3B1ICp2KTsNCiB2b2lkIHZt
eF9yZWFsbW9kZShzdHJ1Y3QgY3B1X3VzZXJfcmVncyAqcmVncyk7DQo=

--8323329-1070034885-1326660827=:29311
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1070034885-1326660827=:29311--


From xen-devel-bounces@lists.xensource.com Sun Jan 15 21:45:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 21: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 1RmXsT-00020u-EI; Sun, 15 Jan 2012 21:44:37 +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 1RmXsS-00020o-0r
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 21:44:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326663869!9217434!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 20388 invoked from network); 15 Jan 2012 21:44:29 -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;
	15 Jan 2012 21:44:29 -0000
Received: by wgbdr11 with SMTP id dr11so901820wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 13:44:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JV+tCBs6BCe0aSbCHm1f9tVcrDSscCSTlnkjoIuRl3U=;
	b=lxcVwXXe+hrNaIJ6Js40lgSxqKslgaaKImU3Fi6SUNj90p5L5qrKQrp8ReibvlWAEw
	NAkvbx2xbtZ8kzrL3iCRfFZdxMtct8RTo6nQu9plhg0276s98DS+hE63lGFhM22aTADw
	c4b/HtUsMOg0sR0smEdgETmLJoYUSZjUDuEVg=
Received: by 10.180.100.200 with SMTP id fa8mr13477415wib.8.1326663868626;
	Sun, 15 Jan 2012 13:44:28 -0800 (PST)
Received: from [192.168.1.70] (host86-129-251-76.range86-129.btcentralplus.com.
	[86.129.251.76])
	by mx.google.com with ESMTPS id fg15sm19802383wbb.7.2012.01.15.13.44.24
	(version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 13:44:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 15 Jan 2012 21:44:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: M A Young <m.a.young@durham.ac.uk>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB38F934.28C04%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] compile fixes for xen with gcc-4.7 on Fedora
	17
Thread-Index: AczTztZcX5rrVxaVoUu9jauYdM/yOg==
In-Reply-To: <alpine.DEB.2.00.1201152031420.29311@vega-a.dur.ac.uk>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] compile fixes for xen with gcc-4.7 on
 Fedora 17
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 20:53, "M A Young" <m.a.young@durham.ac.uk> wrote:

> I needed the xen-4.1 equivalent of the attached patch to get xen to
> compile on Fedora 17 with gcc-4.7. It seems that gcc-4.7 doesn't like it
> when you mix definitions of a function as
> void function(void);
> and
> asmlinkage void function(void);
> in .c and .h files. The patch (for 4.2) fixes three cases where they are
> inconsistent.

I wonder why we're bothering with asmlinkage at all. It's defined to nothin
on x86-64, and regparm((0)) is actually the default for i386 anyway. I think
we can just kill off asmlinkage, so I'll do that instead.

 -- Keir

> Michael Young
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 15 21:45:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 21: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 1RmXsT-00020u-EI; Sun, 15 Jan 2012 21:44:37 +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 1RmXsS-00020o-0r
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 21:44:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326663869!9217434!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 20388 invoked from network); 15 Jan 2012 21:44:29 -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;
	15 Jan 2012 21:44:29 -0000
Received: by wgbdr11 with SMTP id dr11so901820wgb.24
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 13:44:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JV+tCBs6BCe0aSbCHm1f9tVcrDSscCSTlnkjoIuRl3U=;
	b=lxcVwXXe+hrNaIJ6Js40lgSxqKslgaaKImU3Fi6SUNj90p5L5qrKQrp8ReibvlWAEw
	NAkvbx2xbtZ8kzrL3iCRfFZdxMtct8RTo6nQu9plhg0276s98DS+hE63lGFhM22aTADw
	c4b/HtUsMOg0sR0smEdgETmLJoYUSZjUDuEVg=
Received: by 10.180.100.200 with SMTP id fa8mr13477415wib.8.1326663868626;
	Sun, 15 Jan 2012 13:44:28 -0800 (PST)
Received: from [192.168.1.70] (host86-129-251-76.range86-129.btcentralplus.com.
	[86.129.251.76])
	by mx.google.com with ESMTPS id fg15sm19802383wbb.7.2012.01.15.13.44.24
	(version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 13:44:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 15 Jan 2012 21:44:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: M A Young <m.a.young@durham.ac.uk>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB38F934.28C04%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] compile fixes for xen with gcc-4.7 on Fedora
	17
Thread-Index: AczTztZcX5rrVxaVoUu9jauYdM/yOg==
In-Reply-To: <alpine.DEB.2.00.1201152031420.29311@vega-a.dur.ac.uk>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] compile fixes for xen with gcc-4.7 on
 Fedora 17
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 20:53, "M A Young" <m.a.young@durham.ac.uk> wrote:

> I needed the xen-4.1 equivalent of the attached patch to get xen to
> compile on Fedora 17 with gcc-4.7. It seems that gcc-4.7 doesn't like it
> when you mix definitions of a function as
> void function(void);
> and
> asmlinkage void function(void);
> in .c and .h files. The patch (for 4.2) fixes three cases where they are
> inconsistent.

I wonder why we're bothering with asmlinkage at all. It's defined to nothin
on x86-64, and regparm((0)) is actually the default for i386 anyway. I think
we can just kill off asmlinkage, so I'll do that instead.

 -- Keir

> Michael Young
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 15 22:12:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 22:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmYIW-0002IN-TS; Sun, 15 Jan 2012 22:11:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RmYIV-0002II-Ux
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 22:11:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326665424!61060186!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 1295 invoked from network); 15 Jan 2012 22:10:24 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jan 2012 22:10:24 -0000
Received: by wibhj8 with SMTP id hj8so7365014wib.30
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 14:11:30 -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=367wv5XuKujKrD4HFkvCVNH8WKp+Ud+FHLgxdgNFvRM=;
	b=iueOZjfS3vULhi2z0tEEvFIjl6wD6hepfeHwLHGOj776dOUhhj4j+ZohvPf7/8rPz8
	0slNxPwjLvsrXap3s1YHtmXZPzOfH7e/awsQBLneB4gKM209VJdTnuNFymwV1nlzuJ8/
	EZFlS0wBkG+TfbeabMSVHm4xMku300VP1PHA4=
Received: by 10.180.24.105 with SMTP id t9mr15367089wif.19.1326665488827;
	Sun, 15 Jan 2012 14:11:28 -0800 (PST)
Received: from [192.168.1.70] (host86-129-251-76.range86-129.btcentralplus.com.
	[86.129.251.76])
	by mx.google.com with ESMTPS id q34sm19850926wbm.15.2012.01.15.14.11.27
	(version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 14:11:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 15 Jan 2012 22:11:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB38FF8E.28C06%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 10755: regressions - FAIL
Thread-Index: AczT0p+IklR2hKgD8Uace50u/QP6EQ==
In-Reply-To: <osstest-10755-mainreport@xen.org>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable test] 10755: 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 15/01/2012 20:44, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> flight 10755 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10755/
> 
> Regressions :-(

Jan,

The build failure on amd64 is your fault. It's fallout from the config.h
build changes.

 -- Keir


> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs.
> 10649
>  test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs.
> 10649
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs.
> 10649
>  test-i386-i386-xl-win         7 windows-install           fail REGR. vs.
> 10649
>  test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs.
> 10649
>  test-i386-i386-win            7 windows-install           fail REGR. vs.
> 10649
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked
> n/a
>  test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
> 
> version targeted for testing:
>  xen                  6d8888519e3a
> baseline version:
>  xen                  5b2676ac1321
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Adin Scannell <adin@scannell.ca>
>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Christoph Egger <Christoph.Egger@amd.com>
>   Daniel De Graaf <dgdegra@tycho.nsa.gov>
>   Gang Wei <gang.wei@intel.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson.citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Joseph Cihula <joseph.cihula@intel.com>
>   Keir Fraser <keir@xen.org>
>   Olaf Hering <olaf@aepfle.de>
>   Paul Durrant <paul.durrant@citrix.com>
>   Roger Pau Monne <roger.pau@entel.upc.edu>
>   Shane Wang <shane.wang@intel.com>
>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Tim Deegan <tim@xen.org>
>   Wei Wang <wei.wang2@amd.com>
>   Wei, Gang <gang.wei@intel.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  fail
>  build-i386                                                   pass
>  build-amd64-oldkern                                          fail
>  build-i386-oldkern                                           pass
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          blocked
>  test-amd64-i386-xl                                           blocked
>  test-i386-i386-xl                                            fail
>  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 734 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 Sun Jan 15 22:12:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 22:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmYIW-0002IN-TS; Sun, 15 Jan 2012 22:11:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RmYIV-0002II-Ux
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 22:11:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326665424!61060186!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 1295 invoked from network); 15 Jan 2012 22:10:24 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	15 Jan 2012 22:10:24 -0000
Received: by wibhj8 with SMTP id hj8so7365014wib.30
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 14:11:30 -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=367wv5XuKujKrD4HFkvCVNH8WKp+Ud+FHLgxdgNFvRM=;
	b=iueOZjfS3vULhi2z0tEEvFIjl6wD6hepfeHwLHGOj776dOUhhj4j+ZohvPf7/8rPz8
	0slNxPwjLvsrXap3s1YHtmXZPzOfH7e/awsQBLneB4gKM209VJdTnuNFymwV1nlzuJ8/
	EZFlS0wBkG+TfbeabMSVHm4xMku300VP1PHA4=
Received: by 10.180.24.105 with SMTP id t9mr15367089wif.19.1326665488827;
	Sun, 15 Jan 2012 14:11:28 -0800 (PST)
Received: from [192.168.1.70] (host86-129-251-76.range86-129.btcentralplus.com.
	[86.129.251.76])
	by mx.google.com with ESMTPS id q34sm19850926wbm.15.2012.01.15.14.11.27
	(version=SSLv3 cipher=OTHER); Sun, 15 Jan 2012 14:11:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 15 Jan 2012 22:11:26 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB38FF8E.28C06%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [xen-unstable test] 10755: regressions - FAIL
Thread-Index: AczT0p+IklR2hKgD8Uace50u/QP6EQ==
In-Reply-To: <osstest-10755-mainreport@xen.org>
Mime-version: 1.0
Subject: Re: [Xen-devel] [xen-unstable test] 10755: 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 15/01/2012 20:44, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> flight 10755 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10755/
> 
> Regressions :-(

Jan,

The build failure on amd64 is your fault. It's fallout from the config.h
build changes.

 -- Keir


> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs.
> 10649
>  test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs.
> 10649
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs.
> 10649
>  test-i386-i386-xl-win         7 windows-install           fail REGR. vs.
> 10649
>  test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs.
> 10649
>  test-i386-i386-win            7 windows-install           fail REGR. vs.
> 10649
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked
> n/a
>  test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
> 
> version targeted for testing:
>  xen                  6d8888519e3a
> baseline version:
>  xen                  5b2676ac1321
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Adin Scannell <adin@scannell.ca>
>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Christoph Egger <Christoph.Egger@amd.com>
>   Daniel De Graaf <dgdegra@tycho.nsa.gov>
>   Gang Wei <gang.wei@intel.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson.citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Joseph Cihula <joseph.cihula@intel.com>
>   Keir Fraser <keir@xen.org>
>   Olaf Hering <olaf@aepfle.de>
>   Paul Durrant <paul.durrant@citrix.com>
>   Roger Pau Monne <roger.pau@entel.upc.edu>
>   Shane Wang <shane.wang@intel.com>
>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Tim Deegan <tim@xen.org>
>   Wei Wang <wei.wang2@amd.com>
>   Wei, Gang <gang.wei@intel.com>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  fail
>  build-i386                                                   pass
>  build-amd64-oldkern                                          fail
>  build-i386-oldkern                                           pass
>  build-amd64-pvops                                            pass
>  build-i386-pvops                                             pass
>  test-amd64-amd64-xl                                          blocked
>  test-amd64-i386-xl                                           blocked
>  test-i386-i386-xl                                            fail
>  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 734 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 Sun Jan 15 23:37:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 23:37:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmZcn-0002i3-Lm; Sun, 15 Jan 2012 23:36: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 1RmZcl-0002hy-KX
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 23:36:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326670582!11081358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32360 invoked from network); 15 Jan 2012 23:36:23 -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 Jan 2012 23:36:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,515,1320624000"; d="scan'208";a="10032967"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 23: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; Sun, 15 Jan 2012 23: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 1RmZcb-0006TU-DN;
	Sun, 15 Jan 2012 23:36:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmZcb-0002tl-D5;
	Sun, 15 Jan 2012 23:36:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10757-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 23:36:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10757: 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 10757 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10757/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 15 23:37:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 15 Jan 2012 23:37:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmZcn-0002i3-Lm; Sun, 15 Jan 2012 23:36: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 1RmZcl-0002hy-KX
	for xen-devel@lists.xensource.com; Sun, 15 Jan 2012 23:36:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326670582!11081358!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32360 invoked from network); 15 Jan 2012 23:36:23 -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 Jan 2012 23:36:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,515,1320624000"; d="scan'208";a="10032967"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	15 Jan 2012 23: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; Sun, 15 Jan 2012 23: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 1RmZcb-0006TU-DN;
	Sun, 15 Jan 2012 23:36:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmZcb-0002tl-D5;
	Sun, 15 Jan 2012 23:36:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10757-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 15 Jan 2012 23:36:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10757: 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 10757 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10757/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  6d8888519e3a
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Gang Wei <gang.wei@intel.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson.citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 734 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 Jan 16 00:14:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 00: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 1RmaCR-0003Pq-21; Mon, 16 Jan 2012 00:13:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <deshantm@gmail.com>) id 1RmaCP-0003Pl-LS
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 00:13:21 +0000
X-Env-Sender: deshantm@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326672794!11109764!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 15115 invoked from network); 16 Jan 2012 00:13:15 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 00:13:15 -0000
Received: by vcbfo13 with SMTP id fo13so342479vcb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 16:13:13 -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:cc:content-type;
	bh=pkMy1Mh+bJe424kkaIvfqSKDJdxPq/vypl4E4y6G3fQ=;
	b=igXWzPuSWIE6G0yBY8jVPvghxtxcsn0Ev2F8T0g7siPtzs4hsHYTSX8hJnipYTw8qW
	wjsgNKKX4Yhyj9C47DCOiEkgGDNEY74y/96MKueKRAvyV5Sm1VyYaTVXNpPwvu3he8vK
	A0LeF1pjfa+RG6MampICnBDBispIiSwZz73Vs=
Received: by 10.220.156.201 with SMTP id y9mr6451437vcw.22.1326672793111; Sun,
	15 Jan 2012 16:13:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.37.110 with HTTP; Sun, 15 Jan 2012 16:12:52 -0800 (PST)
From: Todd Deshane <todd.deshane@xen.org>
Date: Sun, 15 Jan 2012 19:12:52 -0500
X-Google-Sender-Auth: M_eRh2paEBUkxdkqrlkvKla_ge0
Message-ID: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
To: xen-devel mailing list <xen-devel@lists.xensource.com>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
static on the Dom0 system. (I can PCI passthrough the audio card to a
DomU and that works). Native sound works fine.

Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
UTC 2012 i686 i686 i386 GNU/Linux

Here is the "ubuntu-bug audio" generated report:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/916985

Let me know if there is any other information that I can provide.

Thanks,
Todd

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://www.xen.org/products/cloudxen.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 00:14:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 00: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 1RmaCR-0003Pq-21; Mon, 16 Jan 2012 00:13:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <deshantm@gmail.com>) id 1RmaCP-0003Pl-LS
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 00:13:21 +0000
X-Env-Sender: deshantm@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326672794!11109764!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 15115 invoked from network); 16 Jan 2012 00:13:15 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 00:13:15 -0000
Received: by vcbfo13 with SMTP id fo13so342479vcb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 15 Jan 2012 16:13:13 -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:cc:content-type;
	bh=pkMy1Mh+bJe424kkaIvfqSKDJdxPq/vypl4E4y6G3fQ=;
	b=igXWzPuSWIE6G0yBY8jVPvghxtxcsn0Ev2F8T0g7siPtzs4hsHYTSX8hJnipYTw8qW
	wjsgNKKX4Yhyj9C47DCOiEkgGDNEY74y/96MKueKRAvyV5Sm1VyYaTVXNpPwvu3he8vK
	A0LeF1pjfa+RG6MampICnBDBispIiSwZz73Vs=
Received: by 10.220.156.201 with SMTP id y9mr6451437vcw.22.1326672793111; Sun,
	15 Jan 2012 16:13:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.37.110 with HTTP; Sun, 15 Jan 2012 16:12:52 -0800 (PST)
From: Todd Deshane <todd.deshane@xen.org>
Date: Sun, 15 Jan 2012 19:12:52 -0500
X-Google-Sender-Auth: M_eRh2paEBUkxdkqrlkvKla_ge0
Message-ID: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
To: xen-devel mailing list <xen-devel@lists.xensource.com>
Cc: konrad.wilk@oracle.com
Subject: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
static on the Dom0 system. (I can PCI passthrough the audio card to a
DomU and that works). Native sound works fine.

Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
UTC 2012 i686 i686 i386 GNU/Linux

Here is the "ubuntu-bug audio" generated report:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/916985

Let me know if there is any other information that I can provide.

Thanks,
Todd

-- 
Todd Deshane
http://www.linkedin.com/in/deshantm
http://www.xen.org/products/cloudxen.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg2-00082d-Ah; Mon, 16 Jan 2012 02:52: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 1Rmcg0-00081f-14
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326682317!11117255!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4OTgw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6702 invoked from network); 16 Jan 2012 02:51:57 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-15.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 02:51:57 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id EFCB2604084;
	Sun, 15 Jan 2012 18:51:56 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=NY3dzeiDpBbXxIe3Lq8XuX723d1OPj7Br7y9bYz4BT+M
	+VZOEAUkZEvSBJGaKUbTT3MNssWCslSoA0tVaEwK/2hLQ5+l2Ov/FthnxcMVrlWa
	YWC16nzW3fNGBZz777wUOQLsFKMlbO4k01BIxxRq6uWHcR6CAE2RjLT16bQ0kD4=
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=AfmYgW7q2gS/MwfCUOaI5QvXCFg=; b=USuu8Wcz4EH
	QPHJpCUGeV/QQH5i5zahy+d9R3/zltUWNcKQRkIsirlQsL+KzGCoGOHqzaBsltkL
	5UIRzoyGE1Y1LNSp7SZhwPHuPyqj23mAhWMdaof/aOaTZbgSqbHiumN9i6RlE+Gj
	s6FNHmIXFxRr2iXfj8w3kVEwFk1tf4Go=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id EFBBF60408C; 
	Sun, 15 Jan 2012 18:51:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e0d8333e4725eec0ff4df4b57015f07993c5cc91
Message-Id: <e0d8333e4725eec0ff4d.1326682582@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 02 of 12] 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 provides a grant ref and a version. Update interface to handle this
case.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 2a4112172e44 -r e0d8333e4725 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -733,18 +733,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 2a4112172e44 -r e0d8333e4725 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 Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg4-00083O-AP; Mon, 16 Jan 2012 02:52:08 +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 1Rmcg3-00081m-Hy
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326682320!9255214!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 345 invoked from network); 16 Jan 2012 02:52:00 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.81) by server-9.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 02:52:00 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 02FFB604089;
	Sun, 15 Jan 2012 18:52:00 -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=NpLZsFuEFpoPyoiAgQTPUHYJXiGfdQhwsA4AsAn8k8Ff
	e4z74uAX5LKTLkKTtJ37WyL8qVQiOM66gSp8jLiJ6OeVXwvl4AMX1/3VaO1nVuSz
	ca4agvyZa0y1WW5hSZDCappUL6TytKE1+DmMD1wqeJSsTwug3Vkt1GLOH91QhVk=
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=4FCBMyC/HLMw9th5UfQWOMq56FM=; b=LCIu0wKv/xr
	FAk+JcYa4MwP3KM30p0GZUDwwcwqFOWJaFvc6gT2AWWRhQcEJYlMjYAGL7mSTcbk
	LOBVlCmd81kdrBdgUo3VDGTKtiVU6aioqQNNg3zV5kryuORp+sfv8cfOYF4Gk4aJ
	ljL8B81A4oIp1eJbE+8Ei807fn85hW54=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 3C9F260407C; 
	Sun, 15 Jan 2012 18:51:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b0c70c156920ee20adddd0a4760fe029a30d473c
Message-Id: <b0c70c156920ee20addd.1326682585@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 05 of 12] 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     |  24 ++++++++++++++++++++++++
 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, 39 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>
Acked-by: Tim Deegan <tim@xen.org>

diff -r c906c616d5ac -r b0c70c156920 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
@@ -5024,11 +5023,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 c906c616d5ac -r b0c70c156920 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -141,6 +141,7 @@ static inline shr_handle_t get_next_hand
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
+static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 typedef struct gfn_info
 {
@@ -211,9 +212,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)
     {
@@ -261,6 +265,9 @@ static int mem_sharing_audit(void)
            continue;
         }
 
+        /* We've found a page that is shared */
+        count_found++;
+
         /* Check if all GFNs map to the MFN, and the p2m types */
         list_for_each(le, &pg->shared_info->gfns)
         {
@@ -306,6 +313,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
@@ -347,6 +361,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;
@@ -673,6 +692,9 @@ int mem_sharing_nominate_page(struct dom
         goto out;
     }
 
+    /* Account for this page. */
+    atomic_inc(&nr_shared_mfns);
+
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
@@ -797,6 +819,7 @@ int mem_sharing_share_pages(struct domai
         put_page(cpage);
 
     /* We managed to free a domain page. */
+    atomic_dec(&nr_shared_mfns);
     atomic_inc(&nr_saved_mfns);
     ret = 0;
     
@@ -863,6 +886,7 @@ gfn_found:
         audit_del_list(page);
         xfree(page->shared_info);
         page->shared_info = NULL;
+        atomic_dec(&nr_shared_mfns);
     }
     else
         atomic_dec(&nr_saved_mfns);
diff -r c906c616d5ac -r b0c70c156920 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 c906c616d5ac -r b0c70c156920 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. */
@@ -1093,6 +1094,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 c906c616d5ac -r b0c70c156920 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 c906c616d5ac -r b0c70c156920 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 Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg1-00082W-UD; Mon, 16 Jan 2012 02:52:05 +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 1Rmcfz-00081e-9E
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326682316!2585009!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzcxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15802 invoked from network); 16 Jan 2012 02:51:56 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 02:51:56 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id C1B4E604089;
	Sun, 15 Jan 2012 18:51:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CvNnagnJF8yoYxyTr6aUfp40ME7uT6yWm/hIwxbSO6qW
	EZmOcyIz1lrtI0/S3NvJxsWqTMdbDebYm229UyOO9TJnZnElFLrOkuGhjfWJrT3t
	PYL3dwtOs2/QLkOjA8u5Z1PzRPyNlE0bxmf5zDUwjOazIXISa4WhJ0CulJ99ssE=
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=dikkvmUIuF/qhrvTLZIvou0JVAs=; b=RAu6tSAqjEl
	tJlMiU85TayegQK6EJP5EnPEddLhZD5cXcBDKFIWsplPn8u42YD4x5ErScFtgJI0
	efrvxEIrR0Hq9FlGQJhKoZKaQoRjtjDpiaswJogTtZtPmDSyfsEHxj432k3mETrX
	LQOs+TLBe7skJ5z9immoLFMStY5/IASw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id ADA96604078; 
	Sun, 15 Jan 2012 18:51:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2a4112172e4497f29d031435b4be745763d131eb
Message-Id: <2a4112172e4497f29d03.1326682581@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 01 of 12] 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     |  550 ++++++++++++++++++-------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 4 files changed, 302 insertions(+), 281 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 302a58874eb1 -r 2a4112172e44 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,30 @@
 
 #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)
+{
+    INIT_LIST_HEAD(&page->shared_info->entry);
+    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 +74,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,166 +94,153 @@ 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);
+
+    /* Increment our number of shared pges. */
+    atomic_inc(&d->shr_pages);
+
+    return gfn_info;
 }
 
-static shr_hash_entry_t *mem_sharing_hash_alloc(void)
+static inline void mem_sharing_gfn_destroy(struct domain *d,
+                                           gfn_info_t *gfn_info)
 {
-    return xmalloc(shr_hash_entry_t); 
+    /* Decrement the number of pages. */
+    atomic_dec(&d->shr_pages);
+
+    /* Free the gfn_info structure. */
+    list_del(&gfn_info->list);
+    xfree(gfn_info);
 }
 
-static void mem_sharing_hash_destroy(shr_hash_entry_t *e)
+static struct page_info* mem_sharing_lookup(unsigned long mfn)
 {
-    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)
-{
-    /* Decrement the number of pages, if the gfn was shared before */
-    if ( was_shared )
+    if ( mfn_valid(_mfn(mfn)) )
     {
-        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 )
+        struct page_info* page = mfn_to_page(_mfn(mfn));
+        if ( page_get_owner(page) == dom_cow )
         {
-            atomic_dec(&d->shr_pages);
-            put_domain(d);
+            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
+            return page;
         }
     }
-    xfree(gfn);
-}
-
-static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle)
-{
-    shr_hash_entry_t *e;
-    
-    e = shr_hash[handle % SHR_HASH_LENGTH]; 
-    while(e != NULL)
-    {
-        if(e->handle == handle)
-            return e;
-        e = e->next;
-    }
 
     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
 
@@ -383,36 +375,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)
 {
@@ -450,8 +412,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;
@@ -467,7 +427,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;
     }
@@ -481,16 +441,26 @@ 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);
+
+    /* 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;
     }
 
@@ -501,23 +471,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(d, gfn_info);
+        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:
@@ -526,54 +492,82 @@ 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;
+    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 */
+    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);
         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));
+
+    /* 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);
+
+    /* We managed to free a domain page. */
+    atomic_inc(&nr_saved_mfns);
     ret = 0;
     
 err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
     shr_unlock();
-
     return ret;
 }
 
@@ -585,13 +579,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. 
@@ -607,56 +597,62 @@ 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(d, gfn_info);
+    if ( last_gfn )
+    {
+        /* Clean up shared state */
+        audit_del_list(page);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+    }
+    else
+        atomic_dec(&nr_saved_mfns);
     /* 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 = alloc_domheap_page(d, 0);
-    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);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -669,30 +665,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);
 
@@ -749,9 +733,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;
 
@@ -799,6 +792,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 302a58874eb1 -r 2a4112172e44 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 302a58874eb1 -r 2a4112172e44 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 302a58874eb1 -r 2a4112172e44 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 */
+            domid_t          client_domain; /* IN: the client domain id */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
             uint64_aligned_t client_handle; /* IN: handle to the client page */
         } share; 
         struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg8-00085A-BQ; Mon, 16 Jan 2012 02:52:12 +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 1Rmcg5-000823-0o
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326682322!9070270!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzg5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17168 invoked from network); 16 Jan 2012 02:52:02 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 02:52:02 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id E5D40604084;
	Sun, 15 Jan 2012 18:52:01 -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=pTFzneD0jvlqQt18H0PJ110n9geRTNYKY+/tmtPZytRl
	/wWHxVKRou4Se0zAXaiaUqXK94S/eg8gUK1OklFY2FfKRGQ6CKKILcFzahrTcTaq
	zlFmyzauLgoBGohyDpTGS8uwIPPou5Hb8ykm9zMLnZ4NIqb4ljKcJR7E0TmkpE0=
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=7lMVVWoGZ9GIZiwFhkFJHlHkBV0=; b=pYmadIPjLik
	4n4+iQ6JIpkfn24kh4hSBAcDDa3cNwOolSFHa3VrvNonbFGy1mLH22lB4H2wpQ0X
	G1onbemcTPZEWLhA9bz/lRMf3BZ5u66x8W2g6YiXD2A+1EubyNkxPlJbpGKn5AyS
	uzAW6HhN20qlSWbsUHqZTugHjBMVHDVU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 27E0260407C; 
	Sun, 15 Jan 2012 18:52:01 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 98cc0713476ff072635b34e782787dd8d6dadc61
Message-Id: <98cc0713476ff072635b.1326682587@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 07 of 12] 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  |   5 +++++
 xen/arch/x86/mm.c       |  14 ++++++++++++++
 xen/common/keyhandler.c |   7 +++++--
 xen/include/xen/mm.h    |   3 +++
 4 files changed, 27 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r da6576b82e16 -r 98cc0713476f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3573,6 +3573,11 @@ p2m_pod_decrease_reservation(struct doma
     return 0;
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+}
+
 /*
  * Local variables:
  * mode: C
diff -r da6576b82e16 -r 98cc0713476f xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -113,6 +113,7 @@
 #include <asm/e820.h>
 #include <asm/hypercall.h>
 #include <asm/shared.h>
+#include <asm/mem_sharing.h>
 #include <public/memory.h>
 #include <public/sched.h>
 #include <xsm/xsm.h>
@@ -5832,6 +5833,19 @@ void memguard_unguard_stack(void *p)
     memguard_unguard_range(p, PAGE_SIZE);
 }
 
+#if defined(__x86_64__)
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared frames %u -- Saved frames %u\n",
+            mem_sharing_get_nr_shared_mfns(),
+            mem_sharing_get_nr_saved_mfns());
+}
+#else
+void arch_dump_shared_mem_info(void)
+{
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r da6576b82e16 -r 98cc0713476f 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 da6576b82e16 -r 98cc0713476f 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 Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcfz-00081z-Bh; Mon, 16 Jan 2012 02:52:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rmcfy-00081d-9B
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326682315!12487826!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12765 invoked from network); 16 Jan 2012 02:51:55 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.81) by server-2.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 02:51:55 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 898BA60407C;
	Sun, 15 Jan 2012 18:51:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=q23tcAOUrYA1SLFi/ydUxv
	iwsjfqVcJlvp8GDsANqqoQCcgvHJ5q8ngKskEqlMnS9yaQTKD5V2BQEfg1rIMlw3
	S92D3gShdyu8ADKPyE8edO7T0lCd2xhIgQ93s9B2KbEPXGRNko5zPmiObENsdigi
	FFbeoclg+a7CNSBT+d0gU=
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=TTK2CwD6GX+F
	grvcEYqJgfcCu1o=; b=pB0oDJqxCVhDFr02I4Qtv9zeaOWt6rydYk1nJ3MLAWrF
	4xJca/zhigbZEUy4MiHOWAy2wrOER/e7+XLAQ0FGYdklIhUPwbmMkK7LL4hpmcaS
	8J00M8bTw0eQNuIqd2TMXyVL2l7J/QbQJ/I5QA2l7uGboI8yakyZLJSVM9hFcAw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 66E32604078; 
	Sun, 15 Jan 2012 18:51:53 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 00 of 12] 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 brings about a set of changes to the sharing support
in the hypervisor and tools. Specifically:

- Granular scalable locking: lock mfn's individually when sharing/unsharing
 them. Do not rely on a global lock. Use RCU to maintain a list of all
 shared frames for audit purposes.

- Refreshed stats: they now work (tm), and are accesible via libxc
 and console.

- Basic libxl/xl support for sharing.

- New sharing command "add to physmap", to directly populate a new domain
 with shared frames.

- Toolstack and memshr kept in sync.

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.

Patches 9, 10 11 are tools patches. Patches 1 to 8 are x86/mm. These hypervisor
bits apply on top of patch "x86/mm: Improve ring management for memory events.
Do not lose guest events" currently traversing the chain of reviewing.

Patch 12 is a simple testing tool for showcasing new functionality
and facilitating testing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/mem_sharing.c        |  550 +++++++++++++++++-----------------
 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                    |   74 +----
 xen/arch/x86/mm/mem_sharing.c        |  257 +++++++++++++++-
 xen/arch/x86/mm/mm-locks.h           |   15 +-
 xen/include/asm-x86/mm.h             |   27 +-
 xen/arch/x86/mm/mem_sharing.c        |   91 +++--
 xen/arch/x86/mm/mm-locks.h           |   18 +-
 xen/include/asm-x86/mm.h             |    3 +-
 xen/arch/x86/mm.c                    |    6 -
 xen/arch/x86/mm/mem_sharing.c        |   24 +
 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/mem_sharing.c        |  104 ++++++
 xen/include/public/domctl.h          |    3 +-
 xen/arch/ia64/xen/mm.c               |    5 +
 xen/arch/x86/mm.c                    |   14 +
 xen/common/keyhandler.c              |    7 +-
 xen/include/xen/mm.h                 |    3 +
 xen/arch/x86/mm/mem_sharing.c        |   94 ++---
 xen/arch/x86/mm/mm-locks.h           |   18 -
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 tools/blktap2/drivers/tapdisk-vbd.c  |    6 +-
 tools/blktap2/drivers/tapdisk.h      |    2 +-
 tools/libxc/xc_memshr.c              |   63 +++-
 tools/libxc/xenctrl.h                |   19 +-
 tools/memshr/bidir-daemon.c          |   34 +-
 tools/memshr/bidir-hash.h            |   12 +-
 tools/memshr/interface.c             |   30 +-
 tools/memshr/memshr.h                |   11 +-
 tools/libxc/xc_memshr.c              |   10 +
 tools/libxc/xenctrl.h                |   17 +
 docs/man/xl.pod.1                    |   13 +
 tools/libxl/libxl.c                  |    2 +
 tools/libxl/libxl_types.idl          |    2 +
 tools/libxl/xl.h                     |    1 +
 tools/libxl/xl_cmdimpl.c             |   66 ++++
 tools/libxl/xl_cmdtable.c            |    5 +
 tools/tests/mem-sharing/Makefile     |   26 +
 tools/tests/mem-sharing/memshrtool.c |  165 ++++++++++
 46 files changed, 1371 insertions(+), 543 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcfz-00081z-Bh; Mon, 16 Jan 2012 02:52:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rmcfy-00081d-9B
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326682315!12487826!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12765 invoked from network); 16 Jan 2012 02:51:55 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.81) by server-2.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 02:51:55 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 898BA60407C;
	Sun, 15 Jan 2012 18:51:54 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id:date
	:from:to:cc; q=dns; s=lagarcavilla.org; b=q23tcAOUrYA1SLFi/ydUxv
	iwsjfqVcJlvp8GDsANqqoQCcgvHJ5q8ngKskEqlMnS9yaQTKD5V2BQEfg1rIMlw3
	S92D3gShdyu8ADKPyE8edO7T0lCd2xhIgQ93s9B2KbEPXGRNko5zPmiObENsdigi
	FFbeoclg+a7CNSBT+d0gU=
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=TTK2CwD6GX+F
	grvcEYqJgfcCu1o=; b=pB0oDJqxCVhDFr02I4Qtv9zeaOWt6rydYk1nJ3MLAWrF
	4xJca/zhigbZEUy4MiHOWAy2wrOER/e7+XLAQ0FGYdklIhUPwbmMkK7LL4hpmcaS
	8J00M8bTw0eQNuIqd2TMXyVL2l7J/QbQJ/I5QA2l7uGboI8yakyZLJSVM9hFcAw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 66E32604078; 
	Sun, 15 Jan 2012 18:51:53 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 00 of 12] 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 brings about a set of changes to the sharing support
in the hypervisor and tools. Specifically:

- Granular scalable locking: lock mfn's individually when sharing/unsharing
 them. Do not rely on a global lock. Use RCU to maintain a list of all
 shared frames for audit purposes.

- Refreshed stats: they now work (tm), and are accesible via libxc
 and console.

- Basic libxl/xl support for sharing.

- New sharing command "add to physmap", to directly populate a new domain
 with shared frames.

- Toolstack and memshr kept in sync.

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.

Patches 9, 10 11 are tools patches. Patches 1 to 8 are x86/mm. These hypervisor
bits apply on top of patch "x86/mm: Improve ring management for memory events.
Do not lose guest events" currently traversing the chain of reviewing.

Patch 12 is a simple testing tool for showcasing new functionality
and facilitating testing.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/mem_sharing.c        |  550 +++++++++++++++++-----------------
 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                    |   74 +----
 xen/arch/x86/mm/mem_sharing.c        |  257 +++++++++++++++-
 xen/arch/x86/mm/mm-locks.h           |   15 +-
 xen/include/asm-x86/mm.h             |   27 +-
 xen/arch/x86/mm/mem_sharing.c        |   91 +++--
 xen/arch/x86/mm/mm-locks.h           |   18 +-
 xen/include/asm-x86/mm.h             |    3 +-
 xen/arch/x86/mm.c                    |    6 -
 xen/arch/x86/mm/mem_sharing.c        |   24 +
 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/mem_sharing.c        |  104 ++++++
 xen/include/public/domctl.h          |    3 +-
 xen/arch/ia64/xen/mm.c               |    5 +
 xen/arch/x86/mm.c                    |   14 +
 xen/common/keyhandler.c              |    7 +-
 xen/include/xen/mm.h                 |    3 +
 xen/arch/x86/mm/mem_sharing.c        |   94 ++---
 xen/arch/x86/mm/mm-locks.h           |   18 -
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 tools/blktap2/drivers/tapdisk-vbd.c  |    6 +-
 tools/blktap2/drivers/tapdisk.h      |    2 +-
 tools/libxc/xc_memshr.c              |   63 +++-
 tools/libxc/xenctrl.h                |   19 +-
 tools/memshr/bidir-daemon.c          |   34 +-
 tools/memshr/bidir-hash.h            |   12 +-
 tools/memshr/interface.c             |   30 +-
 tools/memshr/memshr.h                |   11 +-
 tools/libxc/xc_memshr.c              |   10 +
 tools/libxc/xenctrl.h                |   17 +
 docs/man/xl.pod.1                    |   13 +
 tools/libxl/libxl.c                  |    2 +
 tools/libxl/libxl_types.idl          |    2 +
 tools/libxl/xl.h                     |    1 +
 tools/libxl/xl_cmdimpl.c             |   66 ++++
 tools/libxl/xl_cmdtable.c            |    5 +
 tools/tests/mem-sharing/Makefile     |   26 +
 tools/tests/mem-sharing/memshrtool.c |  165 ++++++++++
 46 files changed, 1371 insertions(+), 543 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg2-00082d-Ah; Mon, 16 Jan 2012 02:52: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 1Rmcg0-00081f-14
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326682317!11117255!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4OTgw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6702 invoked from network); 16 Jan 2012 02:51:57 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-15.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 02:51:57 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id EFCB2604084;
	Sun, 15 Jan 2012 18:51:56 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=NY3dzeiDpBbXxIe3Lq8XuX723d1OPj7Br7y9bYz4BT+M
	+VZOEAUkZEvSBJGaKUbTT3MNssWCslSoA0tVaEwK/2hLQ5+l2Ov/FthnxcMVrlWa
	YWC16nzW3fNGBZz777wUOQLsFKMlbO4k01BIxxRq6uWHcR6CAE2RjLT16bQ0kD4=
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=AfmYgW7q2gS/MwfCUOaI5QvXCFg=; b=USuu8Wcz4EH
	QPHJpCUGeV/QQH5i5zahy+d9R3/zltUWNcKQRkIsirlQsL+KzGCoGOHqzaBsltkL
	5UIRzoyGE1Y1LNSp7SZhwPHuPyqj23mAhWMdaof/aOaTZbgSqbHiumN9i6RlE+Gj
	s6FNHmIXFxRr2iXfj8w3kVEwFk1tf4Go=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id EFBBF60408C; 
	Sun, 15 Jan 2012 18:51:55 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e0d8333e4725eec0ff4df4b57015f07993c5cc91
Message-Id: <e0d8333e4725eec0ff4d.1326682582@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 02 of 12] 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 provides a grant ref and a version. Update interface to handle this
case.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 2a4112172e44 -r e0d8333e4725 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -733,18 +733,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 2a4112172e44 -r e0d8333e4725 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 Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg8-00085A-BQ; Mon, 16 Jan 2012 02:52:12 +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 1Rmcg5-000823-0o
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326682322!9070270!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzg5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17168 invoked from network); 16 Jan 2012 02:52:02 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 02:52:02 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id E5D40604084;
	Sun, 15 Jan 2012 18:52:01 -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=pTFzneD0jvlqQt18H0PJ110n9geRTNYKY+/tmtPZytRl
	/wWHxVKRou4Se0zAXaiaUqXK94S/eg8gUK1OklFY2FfKRGQ6CKKILcFzahrTcTaq
	zlFmyzauLgoBGohyDpTGS8uwIPPou5Hb8ykm9zMLnZ4NIqb4ljKcJR7E0TmkpE0=
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=7lMVVWoGZ9GIZiwFhkFJHlHkBV0=; b=pYmadIPjLik
	4n4+iQ6JIpkfn24kh4hSBAcDDa3cNwOolSFHa3VrvNonbFGy1mLH22lB4H2wpQ0X
	G1onbemcTPZEWLhA9bz/lRMf3BZ5u66x8W2g6YiXD2A+1EubyNkxPlJbpGKn5AyS
	uzAW6HhN20qlSWbsUHqZTugHjBMVHDVU=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 27E0260407C; 
	Sun, 15 Jan 2012 18:52:01 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 98cc0713476ff072635b34e782787dd8d6dadc61
Message-Id: <98cc0713476ff072635b.1326682587@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 07 of 12] 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  |   5 +++++
 xen/arch/x86/mm.c       |  14 ++++++++++++++
 xen/common/keyhandler.c |   7 +++++--
 xen/include/xen/mm.h    |   3 +++
 4 files changed, 27 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r da6576b82e16 -r 98cc0713476f xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3573,6 +3573,11 @@ p2m_pod_decrease_reservation(struct doma
     return 0;
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+}
+
 /*
  * Local variables:
  * mode: C
diff -r da6576b82e16 -r 98cc0713476f xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -113,6 +113,7 @@
 #include <asm/e820.h>
 #include <asm/hypercall.h>
 #include <asm/shared.h>
+#include <asm/mem_sharing.h>
 #include <public/memory.h>
 #include <public/sched.h>
 #include <xsm/xsm.h>
@@ -5832,6 +5833,19 @@ void memguard_unguard_stack(void *p)
     memguard_unguard_range(p, PAGE_SIZE);
 }
 
+#if defined(__x86_64__)
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared frames %u -- Saved frames %u\n",
+            mem_sharing_get_nr_shared_mfns(),
+            mem_sharing_get_nr_saved_mfns());
+}
+#else
+void arch_dump_shared_mem_info(void)
+{
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r da6576b82e16 -r 98cc0713476f 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 da6576b82e16 -r 98cc0713476f 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 Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg4-00083O-AP; Mon, 16 Jan 2012 02:52:08 +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 1Rmcg3-00081m-Hy
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326682320!9255214!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 345 invoked from network); 16 Jan 2012 02:52:00 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.81) by server-9.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 02:52:00 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 02FFB604089;
	Sun, 15 Jan 2012 18:52:00 -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=NpLZsFuEFpoPyoiAgQTPUHYJXiGfdQhwsA4AsAn8k8Ff
	e4z74uAX5LKTLkKTtJ37WyL8qVQiOM66gSp8jLiJ6OeVXwvl4AMX1/3VaO1nVuSz
	ca4agvyZa0y1WW5hSZDCappUL6TytKE1+DmMD1wqeJSsTwug3Vkt1GLOH91QhVk=
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=4FCBMyC/HLMw9th5UfQWOMq56FM=; b=LCIu0wKv/xr
	FAk+JcYa4MwP3KM30p0GZUDwwcwqFOWJaFvc6gT2AWWRhQcEJYlMjYAGL7mSTcbk
	LOBVlCmd81kdrBdgUo3VDGTKtiVU6aioqQNNg3zV5kryuORp+sfv8cfOYF4Gk4aJ
	ljL8B81A4oIp1eJbE+8Ei807fn85hW54=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 3C9F260407C; 
	Sun, 15 Jan 2012 18:51:59 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b0c70c156920ee20adddd0a4760fe029a30d473c
Message-Id: <b0c70c156920ee20addd.1326682585@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 05 of 12] 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     |  24 ++++++++++++++++++++++++
 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, 39 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>
Acked-by: Tim Deegan <tim@xen.org>

diff -r c906c616d5ac -r b0c70c156920 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
@@ -5024,11 +5023,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 c906c616d5ac -r b0c70c156920 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -141,6 +141,7 @@ static inline shr_handle_t get_next_hand
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
+static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 typedef struct gfn_info
 {
@@ -211,9 +212,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)
     {
@@ -261,6 +265,9 @@ static int mem_sharing_audit(void)
            continue;
         }
 
+        /* We've found a page that is shared */
+        count_found++;
+
         /* Check if all GFNs map to the MFN, and the p2m types */
         list_for_each(le, &pg->shared_info->gfns)
         {
@@ -306,6 +313,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
@@ -347,6 +361,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;
@@ -673,6 +692,9 @@ int mem_sharing_nominate_page(struct dom
         goto out;
     }
 
+    /* Account for this page. */
+    atomic_inc(&nr_shared_mfns);
+
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
@@ -797,6 +819,7 @@ int mem_sharing_share_pages(struct domai
         put_page(cpage);
 
     /* We managed to free a domain page. */
+    atomic_dec(&nr_shared_mfns);
     atomic_inc(&nr_saved_mfns);
     ret = 0;
     
@@ -863,6 +886,7 @@ gfn_found:
         audit_del_list(page);
         xfree(page->shared_info);
         page->shared_info = NULL;
+        atomic_dec(&nr_shared_mfns);
     }
     else
         atomic_dec(&nr_saved_mfns);
diff -r c906c616d5ac -r b0c70c156920 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 c906c616d5ac -r b0c70c156920 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. */
@@ -1093,6 +1094,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 c906c616d5ac -r b0c70c156920 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 c906c616d5ac -r b0c70c156920 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 Mon Jan 16 02:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg1-00082W-UD; Mon, 16 Jan 2012 02:52:05 +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 1Rmcfz-00081e-9E
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1326682316!2585009!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzcxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15802 invoked from network); 16 Jan 2012 02:51:56 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 02:51:56 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id C1B4E604089;
	Sun, 15 Jan 2012 18:51:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=CvNnagnJF8yoYxyTr6aUfp40ME7uT6yWm/hIwxbSO6qW
	EZmOcyIz1lrtI0/S3NvJxsWqTMdbDebYm229UyOO9TJnZnElFLrOkuGhjfWJrT3t
	PYL3dwtOs2/QLkOjA8u5Z1PzRPyNlE0bxmf5zDUwjOazIXISa4WhJ0CulJ99ssE=
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=dikkvmUIuF/qhrvTLZIvou0JVAs=; b=RAu6tSAqjEl
	tJlMiU85TayegQK6EJP5EnPEddLhZD5cXcBDKFIWsplPn8u42YD4x5ErScFtgJI0
	efrvxEIrR0Hq9FlGQJhKoZKaQoRjtjDpiaswJogTtZtPmDSyfsEHxj432k3mETrX
	LQOs+TLBe7skJ5z9immoLFMStY5/IASw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id ADA96604078; 
	Sun, 15 Jan 2012 18:51:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2a4112172e4497f29d031435b4be745763d131eb
Message-Id: <2a4112172e4497f29d03.1326682581@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 01 of 12] 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     |  550 ++++++++++++++++++-------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 4 files changed, 302 insertions(+), 281 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 302a58874eb1 -r 2a4112172e44 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,30 @@
 
 #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)
+{
+    INIT_LIST_HEAD(&page->shared_info->entry);
+    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 +74,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,166 +94,153 @@ 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);
+
+    /* Increment our number of shared pges. */
+    atomic_inc(&d->shr_pages);
+
+    return gfn_info;
 }
 
-static shr_hash_entry_t *mem_sharing_hash_alloc(void)
+static inline void mem_sharing_gfn_destroy(struct domain *d,
+                                           gfn_info_t *gfn_info)
 {
-    return xmalloc(shr_hash_entry_t); 
+    /* Decrement the number of pages. */
+    atomic_dec(&d->shr_pages);
+
+    /* Free the gfn_info structure. */
+    list_del(&gfn_info->list);
+    xfree(gfn_info);
 }
 
-static void mem_sharing_hash_destroy(shr_hash_entry_t *e)
+static struct page_info* mem_sharing_lookup(unsigned long mfn)
 {
-    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)
-{
-    /* Decrement the number of pages, if the gfn was shared before */
-    if ( was_shared )
+    if ( mfn_valid(_mfn(mfn)) )
     {
-        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 )
+        struct page_info* page = mfn_to_page(_mfn(mfn));
+        if ( page_get_owner(page) == dom_cow )
         {
-            atomic_dec(&d->shr_pages);
-            put_domain(d);
+            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
+            return page;
         }
     }
-    xfree(gfn);
-}
-
-static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle)
-{
-    shr_hash_entry_t *e;
-    
-    e = shr_hash[handle % SHR_HASH_LENGTH]; 
-    while(e != NULL)
-    {
-        if(e->handle == handle)
-            return e;
-        e = e->next;
-    }
 
     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
 
@@ -383,36 +375,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)
 {
@@ -450,8 +412,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;
@@ -467,7 +427,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;
     }
@@ -481,16 +441,26 @@ 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);
+
+    /* 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;
     }
 
@@ -501,23 +471,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(d, gfn_info);
+        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:
@@ -526,54 +492,82 @@ 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;
+    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 */
+    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);
         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));
+
+    /* 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);
+
+    /* We managed to free a domain page. */
+    atomic_inc(&nr_saved_mfns);
     ret = 0;
     
 err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
     shr_unlock();
-
     return ret;
 }
 
@@ -585,13 +579,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. 
@@ -607,56 +597,62 @@ 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(d, gfn_info);
+    if ( last_gfn )
+    {
+        /* Clean up shared state */
+        audit_del_list(page);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+    }
+    else
+        atomic_dec(&nr_saved_mfns);
     /* 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 = alloc_domheap_page(d, 0);
-    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);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -669,30 +665,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);
 
@@ -749,9 +733,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;
 
@@ -799,6 +792,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 302a58874eb1 -r 2a4112172e44 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 302a58874eb1 -r 2a4112172e44 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 302a58874eb1 -r 2a4112172e44 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 */
+            domid_t          client_domain; /* IN: the client domain id */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
             uint64_aligned_t client_handle; /* IN: handle to the client page */
         } share; 
         struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02: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 1Rmcg3-00083C-Sq; Mon, 16 Jan 2012 02:52:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rmcg2-00081h-6A
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326682317!11117255!2
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4OTgw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6726 invoked from network); 16 Jan 2012 02:51:59 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-15.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 02:51:59 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 0DFD2604084;
	Sun, 15 Jan 2012 18:51:59 -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=fsR6NwHT8oI6nXmlxzhnVbWQh6hmA20H4AzV5UaXJhMy
	xXCckrb/oWnqzMpIZnKAk7JIcTBv3PXNRNfDAKC+ra2vCbpdJ6nhWdQyR9eUPeB4
	lOQtxpMUjyUHIbDtzXf2019MTTbchcOvtr9UaGhAsN/JKv/LhJatW1fv0CqWU4I=
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=2QiShOoAOHkn+D3MoR/m3DU6t+I=; b=CF6TPqMi3kL
	USB/LY3Bl3Pj3IT9zsQYWXPv8+Rx3niID1ya3ES/kdxz9RdFhhClg0TZHe3IVUV8
	2jyImU5YA24S1TaOjpCUq9oItbP6PGE0R0IEKnYU3ftbxCutG0DGMccf8N0s1tAP
	VdFa1XalXxoH5djk0RpjWUIPeQnvACQg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 3E28E60407C; 
	Sun, 15 Jan 2012 18:51:58 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c906c616d5ace44de92d1a50db29ffdc5df7ff59
Message-Id: <c906c616d5ace44de92d.1326682584@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 04 of 12] x86/mm: Enforce lock ordering for
	sharing page locks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 |  91 ++++++++++++++++++++++++++----------------
 xen/arch/x86/mm/mm-locks.h    |  18 ++++++++-
 xen/include/asm-x86/mm.h      |   3 +-
 3 files changed, 76 insertions(+), 36 deletions(-)


Use the ordering constructs in mm-locks.h to enforce an order
for the p2m and page locks in the sharing code. Applies to either
the global sharing lock (in audit mode) or the per page locks.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scanneell <adin@scannell.ca>

diff -r 11916fe20dd2 -r c906c616d5ac xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -37,6 +37,14 @@
 
 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;
@@ -63,11 +71,12 @@ static inline void audit_del_list(struct
     list_del(&page->shared_info->entry);
 }
 
-static inline int mem_sharing_page_lock(struct page_info *p)
+static inline int mem_sharing_page_lock(struct page_info *p, 
+                                        pg_lock_data_t *l)
 {
     return 1;
 }
-#define mem_sharing_page_unlock(p)   ((void)0)
+#define mem_sharing_page_unlock(p, l)   ((void)0)
 
 #define get_next_handle()   next_handle++;
 #else
@@ -85,19 +94,26 @@ 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)
+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)
+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);
 }
@@ -492,7 +508,8 @@ static int page_make_sharable(struct dom
     return 0;
 }
 
-static int page_make_private(struct domain *d, struct page_info *page)
+static int page_make_private(struct domain *d, struct page_info *page,
+                             pg_lock_data_t *pld)
 {
     unsigned long expected_type;
 
@@ -520,9 +537,11 @@ static int page_make_private(struct doma
     /* Drop the final typecount */
     put_page_and_type(page);
 
-#ifndef MEM_SHARING_AUDIT
+#if MEM_SHARING_AUDIT
+    (void)pld;
+#else
     /* Now that we've dropped the type, we can unlock */
-    mem_sharing_page_unlock(page);
+    mem_sharing_page_unlock(page, pld);
 #endif
 
     /* Change the owner */
@@ -538,7 +557,8 @@ static int page_make_private(struct doma
     return 0;
 }
 
-static inline struct page_info *__grab_shared_page(mfn_t mfn)
+static inline struct page_info *__grab_shared_page(mfn_t mfn,
+                                                    pg_lock_data_t *pld)
 {
     struct page_info *pg = NULL;
 
@@ -548,12 +568,12 @@ static inline struct page_info *__grab_s
 
     /* 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) )
+    if ( !mem_sharing_page_lock(pg, pld) )
         return NULL;
 
     if ( mem_sharing_lookup(mfn_x(mfn)) == NULL )
     {
-        mem_sharing_page_unlock(pg);
+        mem_sharing_page_unlock(pg, pld);
         return NULL;
     }
 
@@ -570,6 +590,7 @@ int mem_sharing_nominate_page(struct dom
     struct page_info *page = NULL; /* gcc... */
     int ret;
     struct gfn_info *gfn_info;
+    DECLARE_PG_LOCK_DATA(pld);
 
     *phandle = 0UL;
 
@@ -583,7 +604,7 @@ int mem_sharing_nominate_page(struct dom
 
     /* Return the handle if the page is already shared */
     if ( p2m_is_shared(p2mt) ) {
-        struct page_info *pg = __grab_shared_page(mfn);
+        struct page_info *pg = __grab_shared_page(mfn, &pld);
         if ( !pg )
         {
             gdprintk(XENLOG_ERR, "Shared p2m entry gfn %lx, but could not "
@@ -592,7 +613,7 @@ int mem_sharing_nominate_page(struct dom
         }
         *phandle = pg->shared_info->handle;
         ret = 0;
-        mem_sharing_page_unlock(pg);
+        mem_sharing_page_unlock(pg, &pld);
         goto out;
     }
 
@@ -610,7 +631,7 @@ int mem_sharing_nominate_page(struct dom
      * 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) )
+    if ( !mem_sharing_page_lock(page, &pld) )
         goto out;
 
     /* Initialize the shared state */
@@ -619,7 +640,7 @@ int mem_sharing_nominate_page(struct dom
             xmalloc(struct page_sharing_info)) == NULL )
     {
         /* Making a page private atomically unlocks it */
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto out;
     }
     page->shared_info->pg = page;
@@ -633,7 +654,7 @@ int mem_sharing_nominate_page(struct dom
     {
         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;
     }
 
@@ -648,7 +669,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;
     }
 
@@ -657,7 +678,7 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = page->shared_info->handle;
     audit_add_list(page);
-    mem_sharing_page_unlock(page);
+    mem_sharing_page_unlock(page, &pld);
     ret = 0;
 
 out:
@@ -676,6 +697,7 @@ int mem_sharing_share_pages(struct domai
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
+    DECLARE_PG_LOCK_DATA(pld);
 
     shr_lock();
 
@@ -699,28 +721,28 @@ int mem_sharing_share_pages(struct domai
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
         ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-        spage = firstpg = __grab_shared_page(smfn);
+        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);
+        cpage = secondpg = __grab_shared_page(cmfn, &pld);
         if ( cpage == NULL )
         {
-            mem_sharing_page_unlock(spage);
+            mem_sharing_page_unlock(spage, &pld);
             goto err_out;
         }
     } else {
         ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-        cpage = firstpg = __grab_shared_page(cmfn);
+        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);
+        spage = secondpg = __grab_shared_page(smfn, &pld);
         if ( spage == NULL )
         {
-            mem_sharing_page_unlock(cpage);
+            mem_sharing_page_unlock(cpage, &pld);
             goto err_out;
         }
     }
@@ -732,15 +754,15 @@ int mem_sharing_share_pages(struct domai
     if ( spage->shared_info->handle != sh )
     {
         ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-        mem_sharing_page_unlock(secondpg);
-        mem_sharing_page_unlock(firstpg);
+        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);
-        mem_sharing_page_unlock(firstpg);
+        mem_sharing_page_unlock(secondpg, &pld);
+        mem_sharing_page_unlock(firstpg, &pld);
         goto err_out;
     }
 
@@ -767,8 +789,8 @@ 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);
+    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))
@@ -796,6 +818,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. 
@@ -811,7 +834,7 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = __grab_shared_page(mfn);
+    page = __grab_shared_page(mfn, &pld);
     if ( page == NULL )
     {
         gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
@@ -848,7 +871,7 @@ gfn_found:
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         put_page_and_type(page);
-        mem_sharing_page_unlock(page);
+        mem_sharing_page_unlock(page, &pld);
         if ( last_gfn && 
             test_and_clear_bit(_PGC_allocated, &page->count_info) ) 
             put_page(page);
@@ -861,7 +884,7 @@ gfn_found:
     if ( last_gfn )
     {
         /* Making a page private atomically unlocks it */
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto private_page_found;
     }
 
@@ -869,7 +892,7 @@ gfn_found:
     page = alloc_domheap_page(d, 0);
     if ( !page ) 
     {
-        mem_sharing_page_unlock(old_page);
+        mem_sharing_page_unlock(old_page, &pld);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -883,7 +906,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);
+    mem_sharing_page_unlock(old_page, &pld);
     put_page_and_type(old_page);
 
 private_page_found:    
diff -r 11916fe20dd2 -r c906c616d5ac xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -156,7 +156,23 @@ declare_mm_lock(shr)
 
 #else
 
-/* We use an efficient per-page lock when AUDIT is not enabled. */
+/* 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 */
 
diff -r 11916fe20dd2 -r c906c616d5ac xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -351,7 +351,8 @@ void clear_superpage_mark(struct page_in
  * 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. 
+ * 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02: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 1Rmcg3-00083C-Sq; Mon, 16 Jan 2012 02:52:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rmcg2-00081h-6A
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326682317!11117255!2
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4OTgw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6726 invoked from network); 16 Jan 2012 02:51:59 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.5) by server-15.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 02:51:59 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 0DFD2604084;
	Sun, 15 Jan 2012 18:51:59 -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=fsR6NwHT8oI6nXmlxzhnVbWQh6hmA20H4AzV5UaXJhMy
	xXCckrb/oWnqzMpIZnKAk7JIcTBv3PXNRNfDAKC+ra2vCbpdJ6nhWdQyR9eUPeB4
	lOQtxpMUjyUHIbDtzXf2019MTTbchcOvtr9UaGhAsN/JKv/LhJatW1fv0CqWU4I=
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=2QiShOoAOHkn+D3MoR/m3DU6t+I=; b=CF6TPqMi3kL
	USB/LY3Bl3Pj3IT9zsQYWXPv8+Rx3niID1ya3ES/kdxz9RdFhhClg0TZHe3IVUV8
	2jyImU5YA24S1TaOjpCUq9oItbP6PGE0R0IEKnYU3ftbxCutG0DGMccf8N0s1tAP
	VdFa1XalXxoH5djk0RpjWUIPeQnvACQg=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 3E28E60407C; 
	Sun, 15 Jan 2012 18:51:58 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c906c616d5ace44de92d1a50db29ffdc5df7ff59
Message-Id: <c906c616d5ace44de92d.1326682584@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 04 of 12] x86/mm: Enforce lock ordering for
	sharing page locks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 |  91 ++++++++++++++++++++++++++----------------
 xen/arch/x86/mm/mm-locks.h    |  18 ++++++++-
 xen/include/asm-x86/mm.h      |   3 +-
 3 files changed, 76 insertions(+), 36 deletions(-)


Use the ordering constructs in mm-locks.h to enforce an order
for the p2m and page locks in the sharing code. Applies to either
the global sharing lock (in audit mode) or the per page locks.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scanneell <adin@scannell.ca>

diff -r 11916fe20dd2 -r c906c616d5ac xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -37,6 +37,14 @@
 
 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;
@@ -63,11 +71,12 @@ static inline void audit_del_list(struct
     list_del(&page->shared_info->entry);
 }
 
-static inline int mem_sharing_page_lock(struct page_info *p)
+static inline int mem_sharing_page_lock(struct page_info *p, 
+                                        pg_lock_data_t *l)
 {
     return 1;
 }
-#define mem_sharing_page_unlock(p)   ((void)0)
+#define mem_sharing_page_unlock(p, l)   ((void)0)
 
 #define get_next_handle()   next_handle++;
 #else
@@ -85,19 +94,26 @@ 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)
+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)
+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);
 }
@@ -492,7 +508,8 @@ static int page_make_sharable(struct dom
     return 0;
 }
 
-static int page_make_private(struct domain *d, struct page_info *page)
+static int page_make_private(struct domain *d, struct page_info *page,
+                             pg_lock_data_t *pld)
 {
     unsigned long expected_type;
 
@@ -520,9 +537,11 @@ static int page_make_private(struct doma
     /* Drop the final typecount */
     put_page_and_type(page);
 
-#ifndef MEM_SHARING_AUDIT
+#if MEM_SHARING_AUDIT
+    (void)pld;
+#else
     /* Now that we've dropped the type, we can unlock */
-    mem_sharing_page_unlock(page);
+    mem_sharing_page_unlock(page, pld);
 #endif
 
     /* Change the owner */
@@ -538,7 +557,8 @@ static int page_make_private(struct doma
     return 0;
 }
 
-static inline struct page_info *__grab_shared_page(mfn_t mfn)
+static inline struct page_info *__grab_shared_page(mfn_t mfn,
+                                                    pg_lock_data_t *pld)
 {
     struct page_info *pg = NULL;
 
@@ -548,12 +568,12 @@ static inline struct page_info *__grab_s
 
     /* 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) )
+    if ( !mem_sharing_page_lock(pg, pld) )
         return NULL;
 
     if ( mem_sharing_lookup(mfn_x(mfn)) == NULL )
     {
-        mem_sharing_page_unlock(pg);
+        mem_sharing_page_unlock(pg, pld);
         return NULL;
     }
 
@@ -570,6 +590,7 @@ int mem_sharing_nominate_page(struct dom
     struct page_info *page = NULL; /* gcc... */
     int ret;
     struct gfn_info *gfn_info;
+    DECLARE_PG_LOCK_DATA(pld);
 
     *phandle = 0UL;
 
@@ -583,7 +604,7 @@ int mem_sharing_nominate_page(struct dom
 
     /* Return the handle if the page is already shared */
     if ( p2m_is_shared(p2mt) ) {
-        struct page_info *pg = __grab_shared_page(mfn);
+        struct page_info *pg = __grab_shared_page(mfn, &pld);
         if ( !pg )
         {
             gdprintk(XENLOG_ERR, "Shared p2m entry gfn %lx, but could not "
@@ -592,7 +613,7 @@ int mem_sharing_nominate_page(struct dom
         }
         *phandle = pg->shared_info->handle;
         ret = 0;
-        mem_sharing_page_unlock(pg);
+        mem_sharing_page_unlock(pg, &pld);
         goto out;
     }
 
@@ -610,7 +631,7 @@ int mem_sharing_nominate_page(struct dom
      * 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) )
+    if ( !mem_sharing_page_lock(page, &pld) )
         goto out;
 
     /* Initialize the shared state */
@@ -619,7 +640,7 @@ int mem_sharing_nominate_page(struct dom
             xmalloc(struct page_sharing_info)) == NULL )
     {
         /* Making a page private atomically unlocks it */
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto out;
     }
     page->shared_info->pg = page;
@@ -633,7 +654,7 @@ int mem_sharing_nominate_page(struct dom
     {
         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;
     }
 
@@ -648,7 +669,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;
     }
 
@@ -657,7 +678,7 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = page->shared_info->handle;
     audit_add_list(page);
-    mem_sharing_page_unlock(page);
+    mem_sharing_page_unlock(page, &pld);
     ret = 0;
 
 out:
@@ -676,6 +697,7 @@ int mem_sharing_share_pages(struct domai
     int ret = -EINVAL;
     mfn_t smfn, cmfn;
     p2m_type_t smfn_type, cmfn_type;
+    DECLARE_PG_LOCK_DATA(pld);
 
     shr_lock();
 
@@ -699,28 +721,28 @@ int mem_sharing_share_pages(struct domai
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
         ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-        spage = firstpg = __grab_shared_page(smfn);
+        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);
+        cpage = secondpg = __grab_shared_page(cmfn, &pld);
         if ( cpage == NULL )
         {
-            mem_sharing_page_unlock(spage);
+            mem_sharing_page_unlock(spage, &pld);
             goto err_out;
         }
     } else {
         ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
-        cpage = firstpg = __grab_shared_page(cmfn);
+        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);
+        spage = secondpg = __grab_shared_page(smfn, &pld);
         if ( spage == NULL )
         {
-            mem_sharing_page_unlock(cpage);
+            mem_sharing_page_unlock(cpage, &pld);
             goto err_out;
         }
     }
@@ -732,15 +754,15 @@ int mem_sharing_share_pages(struct domai
     if ( spage->shared_info->handle != sh )
     {
         ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
-        mem_sharing_page_unlock(secondpg);
-        mem_sharing_page_unlock(firstpg);
+        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);
-        mem_sharing_page_unlock(firstpg);
+        mem_sharing_page_unlock(secondpg, &pld);
+        mem_sharing_page_unlock(firstpg, &pld);
         goto err_out;
     }
 
@@ -767,8 +789,8 @@ 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);
+    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))
@@ -796,6 +818,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. 
@@ -811,7 +834,7 @@ int mem_sharing_unshare_page(struct doma
         return 0;
     }
 
-    page = __grab_shared_page(mfn);
+    page = __grab_shared_page(mfn, &pld);
     if ( page == NULL )
     {
         gdprintk(XENLOG_ERR, "Domain p2m is shared, but page is not: "
@@ -848,7 +871,7 @@ gfn_found:
     if ( flags & MEM_SHARING_DESTROY_GFN )
     {
         put_page_and_type(page);
-        mem_sharing_page_unlock(page);
+        mem_sharing_page_unlock(page, &pld);
         if ( last_gfn && 
             test_and_clear_bit(_PGC_allocated, &page->count_info) ) 
             put_page(page);
@@ -861,7 +884,7 @@ gfn_found:
     if ( last_gfn )
     {
         /* Making a page private atomically unlocks it */
-        BUG_ON(page_make_private(d, page) != 0);
+        BUG_ON(page_make_private(d, page, &pld) != 0);
         goto private_page_found;
     }
 
@@ -869,7 +892,7 @@ gfn_found:
     page = alloc_domheap_page(d, 0);
     if ( !page ) 
     {
-        mem_sharing_page_unlock(old_page);
+        mem_sharing_page_unlock(old_page, &pld);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -883,7 +906,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);
+    mem_sharing_page_unlock(old_page, &pld);
     put_page_and_type(old_page);
 
 private_page_found:    
diff -r 11916fe20dd2 -r c906c616d5ac xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -156,7 +156,23 @@ declare_mm_lock(shr)
 
 #else
 
-/* We use an efficient per-page lock when AUDIT is not enabled. */
+/* 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 */
 
diff -r 11916fe20dd2 -r c906c616d5ac xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -351,7 +351,8 @@ void clear_superpage_mark(struct page_in
  * 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. 
+ * 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02: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 1Rmcfy-00081r-Us; Mon, 16 Jan 2012 02:52: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 1Rmcfx-00081g-Az
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326682189!48643256!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19689 invoked from network); 16 Jan 2012 02:49:50 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.81) by server-14.tower-27.messagelabs.com with SMTP;
	16 Jan 2012 02:49:50 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 0FF92604078;
	Sun, 15 Jan 2012 18:51:58 -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=RpBKwK1EAYYL+KW/31B2A/2mZy3zYBMu545ZDXpizi/c
	iPEj82dY7bYue/8tqIV3irdTAQrZ0n2EtNyQ5wEz+2n5u1RXJODsazYYN/ZA7odO
	xqGJOPme1t8PZFp0mCcwdS01nCcBHJg+zXWyQiD2HOxSu9aVGulcQ6kE10+mpU8=
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=Pnl4kVJuL328KPZowr7bimU9YFo=; b=G7A8ofQp3Eb
	H22a91ozgJ2B2CVY73tKDR0NqXn1ZCiTnUBnaDcie3Zu9I4dgqx9Ph0nnFOJK9Sh
	ZOKU0rZbQPwV9qzLYNa31ryQYjk41/vMBuWcTBMPrpj1azCF8eR+WLGcMPc7JGqW
	Jbpj2I1alsOV7HvEgBImEvyIMfXgd+NQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 3176F60408C; 
	Sun, 15 Jan 2012 18:51:57 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 11916fe20dd274ff370bd802c0378bd5a16e22d3
Message-Id: <11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 03 of 12] 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 |  257 ++++++++++++++++++++++++++++++++++++++---
 xen/arch/x86/mm/mm-locks.h    |   15 +-
 xen/include/asm-x86/mm.h      |   27 +++-
 4 files changed, 275 insertions(+), 98 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.

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>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r e0d8333e4725 -r 11916fe20dd2 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1719,7 +1719,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;
 
@@ -1736,7 +1736,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;
 
@@ -4295,76 +4295,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 e0d8333e4725 -r 11916fe20dd2 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,21 @@
 
 #include "mm-locks.h"
 
+static shr_handle_t next_handle = 1;
+
 #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)
@@ -51,7 +62,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;
@@ -59,6 +84,34 @@ 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;
+    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) \
@@ -71,7 +124,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); 
 
 typedef struct gfn_info
@@ -81,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)
 {
@@ -403,6 +453,113 @@ 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)
+{
+    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);
+
+#ifndef MEM_SHARING_AUDIT
+    /* Now that we've dropped the type, we can unlock */
+    mem_sharing_page_unlock(page);
+#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)
+{
+    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,
@@ -410,7 +567,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;
 
@@ -425,10 +582,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;
     }
 
@@ -437,15 +601,24 @@ 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) )
+        goto out;
+
     /* Initialize the shared state */
     ret = -ENOMEM;
     if ( (page->shared_info = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
+        /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
@@ -453,7 +626,7 @@ int mem_sharing_nominate_page(struct dom
     INIT_LIST_HEAD(&page->shared_info->gfns);
 
     /* 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 )
@@ -484,6 +657,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:
@@ -495,7 +669,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;
@@ -510,26 +684,63 @@ 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 )
+    /* This tricky business is to avoid two callers deadlocking if 
+     * grabbing pages in opposite client/source order */
+    if( mfn_x(smfn) == mfn_x(cmfn) )
+    {
+        /* The pages are already the same.  We could return some
+         * kind of error here, but no matter how you look at it,
+         * the pages are already 'shared'.  It possibly represents
+         * a big problem somewhere else, but as far as sharing is
+         * concerned: great success! */
+        ret = 0;
         goto err_out;
+    }
+    else 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;
     }
 
@@ -556,6 +767,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);
@@ -597,7 +811,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: "
@@ -633,18 +847,20 @@ 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);
         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 )
     {
+        /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;
     }
@@ -653,6 +869,7 @@ gfn_found:
     page = alloc_domheap_page(d, 0);
     if ( !page ) 
     {
+        mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -666,6 +883,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);
     put_page_and_type(old_page);
 
 private_page_found:    
@@ -683,6 +901,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;
@@ -831,8 +1050,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 e0d8333e4725 -r 11916fe20dd2 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,22 @@ 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
+
+/* We use an efficient per-page lock when AUDIT is not enabled. */
+
+#endif /* MEM_SHARING_AUDIT */
 
 /* Nested P2M lock (per-domain)
  *
diff -r e0d8333e4725 -r 11916fe20dd2 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -337,6 +337,29 @@ 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. 
+ *
+ * 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 +611,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 Mon Jan 16 02:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02: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 1Rmcfy-00081r-Us; Mon, 16 Jan 2012 02:52: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 1Rmcfx-00081g-Az
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:01 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326682189!48643256!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE4OTEy\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19689 invoked from network); 16 Jan 2012 02:49:50 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.81) by server-14.tower-27.messagelabs.com with SMTP;
	16 Jan 2012 02:49:50 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 0FF92604078;
	Sun, 15 Jan 2012 18:51:58 -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=RpBKwK1EAYYL+KW/31B2A/2mZy3zYBMu545ZDXpizi/c
	iPEj82dY7bYue/8tqIV3irdTAQrZ0n2EtNyQ5wEz+2n5u1RXJODsazYYN/ZA7odO
	xqGJOPme1t8PZFp0mCcwdS01nCcBHJg+zXWyQiD2HOxSu9aVGulcQ6kE10+mpU8=
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=Pnl4kVJuL328KPZowr7bimU9YFo=; b=G7A8ofQp3Eb
	H22a91ozgJ2B2CVY73tKDR0NqXn1ZCiTnUBnaDcie3Zu9I4dgqx9Ph0nnFOJK9Sh
	ZOKU0rZbQPwV9qzLYNa31ryQYjk41/vMBuWcTBMPrpj1azCF8eR+WLGcMPc7JGqW
	Jbpj2I1alsOV7HvEgBImEvyIMfXgd+NQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 3176F60408C; 
	Sun, 15 Jan 2012 18:51:57 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 11916fe20dd274ff370bd802c0378bd5a16e22d3
Message-Id: <11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 03 of 12] 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 |  257 ++++++++++++++++++++++++++++++++++++++---
 xen/arch/x86/mm/mm-locks.h    |   15 +-
 xen/include/asm-x86/mm.h      |   27 +++-
 4 files changed, 275 insertions(+), 98 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.

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>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r e0d8333e4725 -r 11916fe20dd2 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1719,7 +1719,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;
 
@@ -1736,7 +1736,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;
 
@@ -4295,76 +4295,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 e0d8333e4725 -r 11916fe20dd2 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,21 @@
 
 #include "mm-locks.h"
 
+static shr_handle_t next_handle = 1;
+
 #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)
@@ -51,7 +62,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;
@@ -59,6 +84,34 @@ 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;
+    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) \
@@ -71,7 +124,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); 
 
 typedef struct gfn_info
@@ -81,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)
 {
@@ -403,6 +453,113 @@ 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)
+{
+    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);
+
+#ifndef MEM_SHARING_AUDIT
+    /* Now that we've dropped the type, we can unlock */
+    mem_sharing_page_unlock(page);
+#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)
+{
+    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,
@@ -410,7 +567,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;
 
@@ -425,10 +582,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;
     }
 
@@ -437,15 +601,24 @@ 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) )
+        goto out;
+
     /* Initialize the shared state */
     ret = -ENOMEM;
     if ( (page->shared_info = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
+        /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
@@ -453,7 +626,7 @@ int mem_sharing_nominate_page(struct dom
     INIT_LIST_HEAD(&page->shared_info->gfns);
 
     /* 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 )
@@ -484,6 +657,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:
@@ -495,7 +669,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;
@@ -510,26 +684,63 @@ 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 )
+    /* This tricky business is to avoid two callers deadlocking if 
+     * grabbing pages in opposite client/source order */
+    if( mfn_x(smfn) == mfn_x(cmfn) )
+    {
+        /* The pages are already the same.  We could return some
+         * kind of error here, but no matter how you look at it,
+         * the pages are already 'shared'.  It possibly represents
+         * a big problem somewhere else, but as far as sharing is
+         * concerned: great success! */
+        ret = 0;
         goto err_out;
+    }
+    else 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;
     }
 
@@ -556,6 +767,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);
@@ -597,7 +811,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: "
@@ -633,18 +847,20 @@ 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);
         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 )
     {
+        /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;
     }
@@ -653,6 +869,7 @@ gfn_found:
     page = alloc_domheap_page(d, 0);
     if ( !page ) 
     {
+        mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -666,6 +883,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);
     put_page_and_type(old_page);
 
 private_page_found:    
@@ -683,6 +901,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;
@@ -831,8 +1050,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 e0d8333e4725 -r 11916fe20dd2 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,22 @@ 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
+
+/* We use an efficient per-page lock when AUDIT is not enabled. */
+
+#endif /* MEM_SHARING_AUDIT */
 
 /* Nested P2M lock (per-domain)
  *
diff -r e0d8333e4725 -r 11916fe20dd2 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -337,6 +337,29 @@ 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. 
+ *
+ * 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 +611,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 Mon Jan 16 02:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02: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 1Rmcg9-00085j-5R; Mon, 16 Jan 2012 02:52:13 +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 1Rmcg7-00082V-9h
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326682322!9070270!2
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzg5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17201 invoked from network); 16 Jan 2012 02:52:04 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 02:52:04 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id EBC50604084;
	Sun, 15 Jan 2012 18:52:03 -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=tgeebk0gqiEOQNA+7K7W7aC1izjspUkocOirVvomUuYa
	H1yxXYAEg8D6rGIjLLADhqsYP/3TDHv9iNLUVtS6JpmMO8pwcnnZlxeGu4Swkvlu
	ZQrLoTpvOrFvSeBZBfMReGplSMGozAPxLWI2RqIgIFDBgsI/ZUG6fEdZkvj58/M=
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=Ir4cDPWBWiknsRNd5MAFI3oqZxg=; b=R2OlHgBJqmj
	5cGusoHQFpEZAPLj12VfTD39GMvFKODTWgJm7IBF3ldKIXMuk7VwlyOp3rcDF9HB
	74PJh6/Usw7U5kBSDqgaXbwM0ZLrGMWltaJDrpDc/5q1shEsPZXQ9ZJVthXU5BOm
	4APzaDxxkshkW2VEjDKkFMhVxfQB2L4U=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 1A5DF60407C; 
	Sun, 15 Jan 2012 18:52:03 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2d6a14ce5b0eda6cc26cc83ec348f106bec6045e
Message-Id: <2d6a14ce5b0eda6cc26c.1326682589@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56:29 -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 12] Update memshr API and tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/blktap2/drivers/tapdisk-vbd.c |   6 +-
 tools/blktap2/drivers/tapdisk.h     |   2 +-
 tools/libxc/xc_memshr.c             |  63 ++++++++++++++++++++++++++++++++++--
 tools/libxc/xenctrl.h               |  19 ++++++++++-
 tools/memshr/bidir-daemon.c         |  34 ++++++++++++++-----
 tools/memshr/bidir-hash.h           |  12 ++++--
 tools/memshr/interface.c            |  30 ++++++++++-------
 tools/memshr/memshr.h               |  11 +++++-
 8 files changed, 139 insertions(+), 38 deletions(-)


This patch is the folded version of API updates, along with the associated tool
changes to ensure that the build is always consistent.

API updates:
- The source domain in the sharing calls is no longer assumed to be dom0.
- Previously, 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 and tools need to be updated to recall the share
  functions with the information needed to fetch the page (which they readily
  have).

Tool updates:
The only (in-tree, that we know of) consumer of the mem sharing API is the
memshr tool. This is updated to use the new API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 288ac8cfea7f -r 2d6a14ce5b0e 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 288ac8cfea7f -r 2d6a14ce5b0e tools/blktap2/drivers/tapdisk.h
--- a/tools/blktap2/drivers/tapdisk.h
+++ b/tools/blktap2/drivers/tapdisk.h
@@ -140,7 +140,7 @@ struct td_request {
 	void                        *private;
     
 #ifdef MEMSHR
-	uint64_t                     memshr_hnd;
+	share_tuple_t                memshr_hnd;
 #endif
 };
 
diff -r 288ac8cfea7f -r 2d6a14ce5b0e tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -86,24 +86,79 @@ int xc_memshr_nominate_gref(xc_interface
     return ret;
 }
 
-int xc_memshr_share(xc_interface *xch,
-                    uint64_t source_handle,
-                    uint64_t client_handle)
+int xc_memshr_share_gfns(xc_interface *xch,
+                         domid_t source_domain,
+                         unsigned long source_gfn,
+                         uint64_t source_handle,
+                         domid_t client_domain,
+                         unsigned long client_gfn,
+                         uint64_t client_handle)
 {
     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 = 0;
+    domctl.domain = source_domain;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
+    op->u.share.source_gfn    = source_gfn;
+    op->u.share.client_domain = client_domain;
+    op->u.share.client_gfn    = client_gfn;
     op->u.share.client_handle = client_handle;
 
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_share_grefs(xc_interface *xch,
+                          domid_t source_domain,
+                          grant_ref_t source_gref,
+                          uint64_t source_handle,
+                          domid_t client_domain,
+                          grant_ref_t client_gref,
+                          uint64_t client_handle)
+{
+    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 = source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
+    op->u.share.source_handle = source_handle;
+    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
+    op->u.share.client_domain = client_domain;
+    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
+    op->u.share.client_handle = client_handle;
+
+    return do_domctl(xch, &domctl);
+}
+
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long 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               = source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
+    op->u.share.source_gfn      = source_gfn;
+    op->u.share.source_handle   = source_handle;
+    op->u.share.client_gfn      = client_gfn;
+    op->u.share.client_domain   = client_domain;
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
diff -r 288ac8cfea7f -r 2d6a14ce5b0e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1894,9 +1894,26 @@ int xc_memshr_nominate_gref(xc_interface
                             domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
-int xc_memshr_share(xc_interface *xch,
+int xc_memshr_share_gfns(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
                     uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long client_gfn,
                     uint64_t client_handle);
+int xc_memshr_share_grefs(xc_interface *xch,
+                    domid_t source_domain,
+                    grant_ref_t source_gref,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    grant_ref_t client_gref,
+                    uint64_t client_handle);
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long client_gfn);
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,
diff -r 288ac8cfea7f -r 2d6a14ce5b0e 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 288ac8cfea7f -r 2d6a14ce5b0e tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -20,6 +20,7 @@
 #define __BIDIR_HASH_H__
 
 #include <stdint.h>
+#include <string.h>
 #include "memshr-priv.h"
 
 typedef struct vbdblk {
@@ -81,15 +82,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 +99,15 @@ 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 ( !memcmp(&h1, &h2, sizeof(share_tuple_t)) );
 }
 #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 288ac8cfea7f -r 2d6a14ce5b0e 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_grefs(vbd_info.xc_handle, source_st.domain, source_st.frame, 
+                                    source_st.handle, vbd_info.domid, gref, c_hnd);
         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 288ac8cfea7f -r 2d6a14ce5b0e 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 Mon Jan 16 02:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02: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 1Rmcg9-00085j-5R; Mon, 16 Jan 2012 02:52:13 +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 1Rmcg7-00082V-9h
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326682322!9070270!2
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNzg5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17201 invoked from network); 16 Jan 2012 02:52:04 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.74) by server-16.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 02:52:04 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id EBC50604084;
	Sun, 15 Jan 2012 18:52:03 -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=tgeebk0gqiEOQNA+7K7W7aC1izjspUkocOirVvomUuYa
	H1yxXYAEg8D6rGIjLLADhqsYP/3TDHv9iNLUVtS6JpmMO8pwcnnZlxeGu4Swkvlu
	ZQrLoTpvOrFvSeBZBfMReGplSMGozAPxLWI2RqIgIFDBgsI/ZUG6fEdZkvj58/M=
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=Ir4cDPWBWiknsRNd5MAFI3oqZxg=; b=R2OlHgBJqmj
	5cGusoHQFpEZAPLj12VfTD39GMvFKODTWgJm7IBF3ldKIXMuk7VwlyOp3rcDF9HB
	74PJh6/Usw7U5kBSDqgaXbwM0ZLrGMWltaJDrpDc/5q1shEsPZXQ9ZJVthXU5BOm
	4APzaDxxkshkW2VEjDKkFMhVxfQB2L4U=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 1A5DF60407C; 
	Sun, 15 Jan 2012 18:52:03 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2d6a14ce5b0eda6cc26cc83ec348f106bec6045e
Message-Id: <2d6a14ce5b0eda6cc26c.1326682589@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56:29 -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 12] Update memshr API and tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/blktap2/drivers/tapdisk-vbd.c |   6 +-
 tools/blktap2/drivers/tapdisk.h     |   2 +-
 tools/libxc/xc_memshr.c             |  63 ++++++++++++++++++++++++++++++++++--
 tools/libxc/xenctrl.h               |  19 ++++++++++-
 tools/memshr/bidir-daemon.c         |  34 ++++++++++++++-----
 tools/memshr/bidir-hash.h           |  12 ++++--
 tools/memshr/interface.c            |  30 ++++++++++-------
 tools/memshr/memshr.h               |  11 +++++-
 8 files changed, 139 insertions(+), 38 deletions(-)


This patch is the folded version of API updates, along with the associated tool
changes to ensure that the build is always consistent.

API updates:
- The source domain in the sharing calls is no longer assumed to be dom0.
- Previously, 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 and tools need to be updated to recall the share
  functions with the information needed to fetch the page (which they readily
  have).

Tool updates:
The only (in-tree, that we know of) consumer of the mem sharing API is the
memshr tool. This is updated to use the new API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 288ac8cfea7f -r 2d6a14ce5b0e 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 288ac8cfea7f -r 2d6a14ce5b0e tools/blktap2/drivers/tapdisk.h
--- a/tools/blktap2/drivers/tapdisk.h
+++ b/tools/blktap2/drivers/tapdisk.h
@@ -140,7 +140,7 @@ struct td_request {
 	void                        *private;
     
 #ifdef MEMSHR
-	uint64_t                     memshr_hnd;
+	share_tuple_t                memshr_hnd;
 #endif
 };
 
diff -r 288ac8cfea7f -r 2d6a14ce5b0e tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -86,24 +86,79 @@ int xc_memshr_nominate_gref(xc_interface
     return ret;
 }
 
-int xc_memshr_share(xc_interface *xch,
-                    uint64_t source_handle,
-                    uint64_t client_handle)
+int xc_memshr_share_gfns(xc_interface *xch,
+                         domid_t source_domain,
+                         unsigned long source_gfn,
+                         uint64_t source_handle,
+                         domid_t client_domain,
+                         unsigned long client_gfn,
+                         uint64_t client_handle)
 {
     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 = 0;
+    domctl.domain = source_domain;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
+    op->u.share.source_gfn    = source_gfn;
+    op->u.share.client_domain = client_domain;
+    op->u.share.client_gfn    = client_gfn;
     op->u.share.client_handle = client_handle;
 
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_share_grefs(xc_interface *xch,
+                          domid_t source_domain,
+                          grant_ref_t source_gref,
+                          uint64_t source_handle,
+                          domid_t client_domain,
+                          grant_ref_t client_gref,
+                          uint64_t client_handle)
+{
+    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 = source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
+    op->u.share.source_handle = source_handle;
+    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
+    op->u.share.client_domain = client_domain;
+    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
+    op->u.share.client_handle = client_handle;
+
+    return do_domctl(xch, &domctl);
+}
+
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long 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               = source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
+    op->u.share.source_gfn      = source_gfn;
+    op->u.share.source_handle   = source_handle;
+    op->u.share.client_gfn      = client_gfn;
+    op->u.share.client_domain   = client_domain;
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
diff -r 288ac8cfea7f -r 2d6a14ce5b0e tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1894,9 +1894,26 @@ int xc_memshr_nominate_gref(xc_interface
                             domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
-int xc_memshr_share(xc_interface *xch,
+int xc_memshr_share_gfns(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
                     uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long client_gfn,
                     uint64_t client_handle);
+int xc_memshr_share_grefs(xc_interface *xch,
+                    domid_t source_domain,
+                    grant_ref_t source_gref,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    grant_ref_t client_gref,
+                    uint64_t client_handle);
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long client_gfn);
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,
diff -r 288ac8cfea7f -r 2d6a14ce5b0e 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 288ac8cfea7f -r 2d6a14ce5b0e tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -20,6 +20,7 @@
 #define __BIDIR_HASH_H__
 
 #include <stdint.h>
+#include <string.h>
 #include "memshr-priv.h"
 
 typedef struct vbdblk {
@@ -81,15 +82,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 +99,15 @@ 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 ( !memcmp(&h1, &h2, sizeof(share_tuple_t)) );
 }
 #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 288ac8cfea7f -r 2d6a14ce5b0e 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_grefs(vbd_info.xc_handle, source_st.domain, source_st.frame, 
+                                    source_st.handle, vbd_info.domid, gref, c_hnd);
         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 288ac8cfea7f -r 2d6a14ce5b0e 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 Mon Jan 16 02:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02: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 1Rmcg8-00085S-OM; Mon, 16 Jan 2012 02:52:12 +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 1Rmcg6-00082Q-4d
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326682323!7932409!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc2NzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15861 invoked from network); 16 Jan 2012 02:52:03 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-7.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 02:52:03 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id E05EF604078;
	Sun, 15 Jan 2012 18:52:02 -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=ueTgwdrrjba9rm/JCqWVkjHhRVZnleRzlqyrGbXQJ8hM
	El3xLgu+1x/19CERPg/LsqJRtSuLNy9A/dK5+Y2Hz1c47LnCuYdE0AK/BOa+5AWF
	vPMs82q6vwG6FERTHZZesCM20YFMCaz1mc2sBLX1qar6vhPKbVLRzKJ7yiu9CBg=
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=x9rDrjAiSgvRqhHhEc+Nym0gsZY=; b=attJjyh/g0n
	tqIufzpwLNHmr3TXmBF5nGNuqWz47LBBr4bVpHRLXxJoNZyICiWAwwgLLRH/OKwB
	ioulqFBf4o2vH5U9rCfwIzrc1azHDkNGNnORwwto+MTvlMvBAx6DyM+/OGrNYO2Y
	6kA9XszmUHrui/iqo+U2H87wTwv5/1QE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 1FDFD60407C; 
	Sun, 15 Jan 2012 18:52:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 288ac8cfea7f190a5822bbc2cf3ccb35553c58e4
Message-Id: <288ac8cfea7f190a5822.1326682588@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56:28 -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 12] 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     |  94 +++++++++++++++++---------------------
 xen/arch/x86/mm/mm-locks.h        |  18 -------
 xen/include/asm-x86/mem_sharing.h |   1 +
 3 files changed, 43 insertions(+), 70 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 98cc0713476f -r 288ac8cfea7f 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,52 +48,52 @@ 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)
 {
     INIT_LIST_HEAD(&page->shared_info->entry);
-    list_add(&page->shared_info->entry, &shr_audit_list);
+    spin_lock(&shr_audit_lock);
+    list_add_rcu(&page->shared_info->entry, &shr_audit_list);
+    spin_unlock(&shr_audit_lock);
 }
 
 static inline void audit_del_list(struct page_info *page)
 {
-    list_del(&page->shared_info->entry);
+    spin_lock(&shr_audit_lock);
+    list_del_rcu(&page->shared_info->entry);
+    spin_unlock(&shr_audit_lock);
+    INIT_RCU_HEAD(&page->shared_info->rcu_head);
+    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;
 }
 
 #define audit_add_list(p)  ((void)0)
-#define audit_del_list(p)  ((void)0)
+static inline void audit_del_list(struct page_info *page)
+{
+    xfree(page->shared_info);
+}
+
+#endif /* MEM_SHARING_AUDIT */
 
 static inline int mem_sharing_page_lock(struct page_info *pg,
                                         pg_lock_data_t *pld)
@@ -128,7 +129,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)
@@ -215,11 +215,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;
@@ -231,6 +233,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) )
         {
@@ -311,8 +322,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.",
@@ -538,14 +553,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);
@@ -556,12 +567,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);
@@ -613,7 +620,6 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = 0UL;
 
-    shr_lock(); 
     mfn = get_gfn(d, gfn, &p2mt);
 
     /* Check if mfn is valid */
@@ -705,7 +711,6 @@ int mem_sharing_nominate_page(struct dom
 
 out:
     put_gfn(d, gfn);
-    shr_unlock();
     return ret;
 }
 
@@ -721,8 +726,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);
@@ -808,7 +811,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);
@@ -826,7 +828,6 @@ int mem_sharing_share_pages(struct domai
 err_out:
     put_gfn(cd, cgfn);
     put_gfn(sd, sgfn);
-    shr_unlock();
     return ret;
 }
 
@@ -911,17 +912,12 @@ 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();
     mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
     if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
-        shr_unlock();
         return 0;
     }
 
@@ -952,7 +948,6 @@ gfn_found:
     {
         /* Clean up shared state */
         audit_del_list(page);
-        xfree(page->shared_info);
         page->shared_info = NULL;
         atomic_dec(&nr_shared_mfns);
     }
@@ -968,7 +963,6 @@ gfn_found:
             test_and_clear_bit(_PGC_allocated, &page->count_info) ) 
             put_page(page);
         put_gfn(d, gfn);
-        shr_unlock();
 
         return 0;
     }
@@ -987,7 +981,6 @@ gfn_found:
         mem_sharing_page_unlock(old_page, &pld);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
-        shr_unlock();
         return -ENOMEM;
     }
 
@@ -1018,7 +1011,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;
 }
 
@@ -1191,9 +1183,7 @@ int mem_sharing_domctl(struct domain *d,
             break;
     }
 
-    shr_lock();
     mem_sharing_audit();
-    shr_unlock();
 
     return rc;
 }
@@ -1202,7 +1192,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 98cc0713476f -r 288ac8cfea7f 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 98cc0713476f -r 288ac8cfea7f xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -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 Mon Jan 16 02:52:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02: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 1Rmcg8-00085S-OM; Mon, 16 Jan 2012 02:52:12 +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 1Rmcg6-00082Q-4d
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326682323!7932409!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc2NzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15861 invoked from network); 16 Jan 2012 02:52:03 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-7.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 02:52:03 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id E05EF604078;
	Sun, 15 Jan 2012 18:52:02 -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=ueTgwdrrjba9rm/JCqWVkjHhRVZnleRzlqyrGbXQJ8hM
	El3xLgu+1x/19CERPg/LsqJRtSuLNy9A/dK5+Y2Hz1c47LnCuYdE0AK/BOa+5AWF
	vPMs82q6vwG6FERTHZZesCM20YFMCaz1mc2sBLX1qar6vhPKbVLRzKJ7yiu9CBg=
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=x9rDrjAiSgvRqhHhEc+Nym0gsZY=; b=attJjyh/g0n
	tqIufzpwLNHmr3TXmBF5nGNuqWz47LBBr4bVpHRLXxJoNZyICiWAwwgLLRH/OKwB
	ioulqFBf4o2vH5U9rCfwIzrc1azHDkNGNnORwwto+MTvlMvBAx6DyM+/OGrNYO2Y
	6kA9XszmUHrui/iqo+U2H87wTwv5/1QE=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 1FDFD60407C; 
	Sun, 15 Jan 2012 18:52:02 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 288ac8cfea7f190a5822bbc2cf3ccb35553c58e4
Message-Id: <288ac8cfea7f190a5822.1326682588@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56:28 -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 12] 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     |  94 +++++++++++++++++---------------------
 xen/arch/x86/mm/mm-locks.h        |  18 -------
 xen/include/asm-x86/mem_sharing.h |   1 +
 3 files changed, 43 insertions(+), 70 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 98cc0713476f -r 288ac8cfea7f 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,52 +48,52 @@ 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)
 {
     INIT_LIST_HEAD(&page->shared_info->entry);
-    list_add(&page->shared_info->entry, &shr_audit_list);
+    spin_lock(&shr_audit_lock);
+    list_add_rcu(&page->shared_info->entry, &shr_audit_list);
+    spin_unlock(&shr_audit_lock);
 }
 
 static inline void audit_del_list(struct page_info *page)
 {
-    list_del(&page->shared_info->entry);
+    spin_lock(&shr_audit_lock);
+    list_del_rcu(&page->shared_info->entry);
+    spin_unlock(&shr_audit_lock);
+    INIT_RCU_HEAD(&page->shared_info->rcu_head);
+    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;
 }
 
 #define audit_add_list(p)  ((void)0)
-#define audit_del_list(p)  ((void)0)
+static inline void audit_del_list(struct page_info *page)
+{
+    xfree(page->shared_info);
+}
+
+#endif /* MEM_SHARING_AUDIT */
 
 static inline int mem_sharing_page_lock(struct page_info *pg,
                                         pg_lock_data_t *pld)
@@ -128,7 +129,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)
@@ -215,11 +215,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;
@@ -231,6 +233,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) )
         {
@@ -311,8 +322,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.",
@@ -538,14 +553,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);
@@ -556,12 +567,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);
@@ -613,7 +620,6 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = 0UL;
 
-    shr_lock(); 
     mfn = get_gfn(d, gfn, &p2mt);
 
     /* Check if mfn is valid */
@@ -705,7 +711,6 @@ int mem_sharing_nominate_page(struct dom
 
 out:
     put_gfn(d, gfn);
-    shr_unlock();
     return ret;
 }
 
@@ -721,8 +726,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);
@@ -808,7 +811,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);
@@ -826,7 +828,6 @@ int mem_sharing_share_pages(struct domai
 err_out:
     put_gfn(cd, cgfn);
     put_gfn(sd, sgfn);
-    shr_unlock();
     return ret;
 }
 
@@ -911,17 +912,12 @@ 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();
     mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
     if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
-        shr_unlock();
         return 0;
     }
 
@@ -952,7 +948,6 @@ gfn_found:
     {
         /* Clean up shared state */
         audit_del_list(page);
-        xfree(page->shared_info);
         page->shared_info = NULL;
         atomic_dec(&nr_shared_mfns);
     }
@@ -968,7 +963,6 @@ gfn_found:
             test_and_clear_bit(_PGC_allocated, &page->count_info) ) 
             put_page(page);
         put_gfn(d, gfn);
-        shr_unlock();
 
         return 0;
     }
@@ -987,7 +981,6 @@ gfn_found:
         mem_sharing_page_unlock(old_page, &pld);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
-        shr_unlock();
         return -ENOMEM;
     }
 
@@ -1018,7 +1011,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;
 }
 
@@ -1191,9 +1183,7 @@ int mem_sharing_domctl(struct domain *d,
             break;
     }
 
-    shr_lock();
     mem_sharing_audit();
-    shr_unlock();
 
     return rc;
 }
@@ -1202,7 +1192,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 98cc0713476f -r 288ac8cfea7f 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 98cc0713476f -r 288ac8cfea7f xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -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 Mon Jan 16 02:52:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg7-00084y-V7; Mon, 16 Jan 2012 02:52: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 1Rmcg4-00081t-CK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326682321!8756998!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTgyNzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32078 invoked from network); 16 Jan 2012 02:52:01 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 02:52:01 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id EBE7C604078;
	Sun, 15 Jan 2012 18:52:00 -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=djDP48H8Pr6AJC5o9j9R6ky5RLtVP9tFiGKpPKkH2dQ/
	sS8RIezNd1s25PRWryE1EkiD1kcyQ2KI5S1m0SuKdCUTs/opO7YAi/6rcfPfGCQk
	Atv/fk+T3wvikuUjsetEJWfQUVTSywzLnKZQCEHRv2JBNI/iW8p1zgdcD5y8gwQ=
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=bJSbzzW3rfVxN0YEiaYtoC7ZkqE=; b=DAPVYiklvaH
	ZtJyKDVFyZSNhH7CVpX39HJEKYEdU7GuxXXC0JZwMDZ+eR6uz1jx5DXZejLaNIFs
	TDjhek8WRFliqzIH1zep0V/98IgwQvgaGRk3QpetkK8rojLTQ94pSB7lOcyMj1wI
	gmcXZwrEUUTHN6eihdjqpRleJkvJtoNw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 30EBD60407C; 
	Sun, 15 Jan 2012 18:52:00 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: da6576b82e1636f264b4acd61e95eb47277fc481
Message-Id: <da6576b82e1636f264b4.1326682586@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 06 of 12] 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>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r b0c70c156920 -r da6576b82e16 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -830,6 +830,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(cd, gfn_info);
+        put_page_and_type(spage);
+    } else
+        ret = 0;
+
+    atomic_inc(&nr_saved_mfns);
+
+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)
@@ -1053,6 +1121,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 b0c70c156920 -r da6576b82e16 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 */
             domid_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 Jan 16 02:52:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmcg7-00084y-V7; Mon, 16 Jan 2012 02:52: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 1Rmcg4-00081t-CK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326682321!8756998!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTgyNzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32078 invoked from network); 16 Jan 2012 02:52:01 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 02:52:01 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id EBE7C604078;
	Sun, 15 Jan 2012 18:52:00 -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=djDP48H8Pr6AJC5o9j9R6ky5RLtVP9tFiGKpPKkH2dQ/
	sS8RIezNd1s25PRWryE1EkiD1kcyQ2KI5S1m0SuKdCUTs/opO7YAi/6rcfPfGCQk
	Atv/fk+T3wvikuUjsetEJWfQUVTSywzLnKZQCEHRv2JBNI/iW8p1zgdcD5y8gwQ=
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=bJSbzzW3rfVxN0YEiaYtoC7ZkqE=; b=DAPVYiklvaH
	ZtJyKDVFyZSNhH7CVpX39HJEKYEdU7GuxXXC0JZwMDZ+eR6uz1jx5DXZejLaNIFs
	TDjhek8WRFliqzIH1zep0V/98IgwQvgaGRk3QpetkK8rojLTQ94pSB7lOcyMj1wI
	gmcXZwrEUUTHN6eihdjqpRleJkvJtoNw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 30EBD60407C; 
	Sun, 15 Jan 2012 18:52:00 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: da6576b82e1636f264b4acd61e95eb47277fc481
Message-Id: <da6576b82e1636f264b4.1326682586@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 06 of 12] 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>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r b0c70c156920 -r da6576b82e16 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -830,6 +830,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(cd, gfn_info);
+        put_page_and_type(spage);
+    } else
+        ret = 0;
+
+    atomic_inc(&nr_saved_mfns);
+
+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)
@@ -1053,6 +1121,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 b0c70c156920 -r da6576b82e16 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 */
             domid_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 Jan 16 02:52:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmcgB-00087O-Jw; Mon, 16 Jan 2012 02:52: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 1RmcgA-00083Z-1Q
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326682327!10479708!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc2NTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12148 invoked from network); 16 Jan 2012 02:52:07 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-182.messagelabs.com with SMTP;
	16 Jan 2012 02:52:07 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id EE1A3604078;
	Sun, 15 Jan 2012 18:52:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ffT+hpiQZk6Lp51BgL7ZEjWno6lLb7prbtotMm0uuh26
	v/6/kgaAY8QtdKiLfps144NGZGlnFC0uh4QGJGCUvVen0ehOsRXnCDfOyci9TP+g
	/1o1rpBA8ZIZkW3VUW+Q5VhkSWx2xhVK3c/MflyFlzYPY+KzI48xLC9T402VFas=
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=Kanv5eE6mCgA1SBjquA/q2nvYc8=; b=RG2piqBE9s1
	zrmkztX8I0jdd6cblCVtQcQ7qZxXoLglB0HILJyRKo1Vhx0JJWUTIxuhdVBS7sQy
	+caYBhjPWr6cI4CIklkdfq10VcVIcyPBLZMH9Zm3UjhactGRLyyKzuoBwpITPPFN
	LwFW+5iGnNwT03qWhLk3fg173ZeOefEw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 31FE760407C; 
	Sun, 15 Jan 2012 18:52:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 82e900cc725549100751f6876d2cf9e12fb2ce6a
Message-Id: <82e900cc725549100751.1326682592@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 12 of 12] Memshrtool: tool to test and exercise
 the sharing subsystem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/tests/mem-sharing/Makefile     |   26 +++++
 tools/tests/mem-sharing/memshrtool.c |  165 +++++++++++++++++++++++++++++++++++
 2 files changed, 191 insertions(+), 0 deletions(-)


This is demo code meant to showcase how to perform sharing
operations. It is useful for testing. We submit it so others in
the list can have unlimited sharing fun, but not necessarily
expecting it be added to the tree.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 6522ae36bc61 -r 82e900cc7255 tools/tests/mem-sharing/Makefile
--- /dev/null
+++ b/tools/tests/mem-sharing/Makefile
@@ -0,0 +1,26 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS += -Werror
+
+CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_xeninclude)
+
+TARGETS-y := 
+TARGETS-$(CONFIG_X86) += memshrtool
+TARGETS := $(TARGETS-y)
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: $(TARGETS)
+
+.PHONY: clean
+clean:
+	$(RM) *.o $(TARGETS) *~ $(DEPS)
+
+memshrtool: memshrtool.o
+	$(CC) -o $@ $< $(LDFLAGS) $(LDLIBS_libxenctrl)
+
+-include $(DEPS)
diff -r 6522ae36bc61 -r 82e900cc7255 tools/tests/mem-sharing/memshrtool.c
--- /dev/null
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -0,0 +1,165 @@
+/*
+ * memshrtool.c
+ *
+ * Copyright 2011 GridCentric Inc. (Adin Scannell, Andres Lagar-Cavilla)
+ */
+
+#include <stdio.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <errno.h>
+#include <string.h>
+#include <sys/mman.h>
+
+#include "xenctrl.h"
+
+static int usage(const char* prog)
+{
+    printf("usage: %s <command> [args...]\n", prog);
+    printf("where <command> may be:\n");
+    printf("  info                    - Display total sharing info.\n");
+    printf("  enable                  - Enable sharing on a domain.\n");
+    printf("  disable                 - Disable sharing on a domain.\n");
+    printf("  nominate <domid> <gfn>  - Nominate a page for sharing.\n");
+    printf("  share <domid> <gfn> <handle> <source> <source-gfn> <source-handle>\n");
+    printf("                          - Share two pages.\n");
+    printf("  unshare <domid> <gfn>   - Unshare a page by grabbing a writable map.\n");
+    printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
+    printf("                          - Populate a page in a domain with a shared page.\n");
+    printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    return 1;
+}
+
+#define R(f) do { \
+    int rc = f; \
+    if ( rc < 0 ) { \
+        printf("error executing %s: %s\n", #f, \
+                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                "problem with client handle" :\
+                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                "problem with source handle" : strerror(errno)); \
+        return rc; \
+    } \
+} while(0)
+
+int main(int argc, const char** argv)
+{
+    const char* cmd = NULL;
+    xc_interface *xch = xc_interface_open(0, 0, 0);
+
+    if( argc < 2 )
+        return usage(argv[0]);
+
+    cmd = argv[1];
+
+    if( !strcasecmp(cmd, "info") )
+    {
+        if( argc != 2 )
+            return usage(argv[0]);
+
+        printf("used = %ld\n", xc_sharing_used_frames(xch));
+        printf("freed = %ld\n", xc_sharing_freed_pages(xch));
+    }
+    else if( !strcasecmp(cmd, "enable") )
+    {
+        domid_t domid;
+
+        if( argc != 3 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        R(xc_memshr_control(xch, domid, 1));
+    }
+    else if( !strcasecmp(cmd, "disable") )
+    {
+        domid_t domid;
+
+        if( argc != 3 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        R(xc_memshr_control(xch, domid, 0));
+    }
+    else if( !strcasecmp(cmd, "nominate") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        uint64_t handle;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        R(xc_memshr_nominate_gfn(xch, domid, gfn, &handle));
+        printf("handle = 0x%08llx\n", (unsigned long long) handle);
+    }
+    else if( !strcasecmp(cmd, "share") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        uint64_t handle;
+        domid_t source_domid;
+        unsigned long source_gfn;
+        uint64_t source_handle;
+
+        if( argc != 8 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        handle = strtol(argv[4], NULL, 0);
+        source_domid = strtol(argv[5], NULL, 0);
+        source_gfn = strtol(argv[6], NULL, 0);
+        source_handle = strtol(argv[7], NULL, 0);
+        R(xc_memshr_share_gfns(xch, source_domid, source_gfn, source_handle, domid, gfn, handle));
+    }
+    else if( !strcasecmp(cmd, "unshare") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        void *map;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        map = xc_map_foreign_range(xch, domid, 4096, PROT_WRITE, gfn);
+        if( map )
+            munmap(map, 4096);
+        R((int)!map);
+    }
+    else if( !strcasecmp(cmd, "add-to-physmap") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        domid_t source_domid;
+        unsigned long source_gfn;
+        uint64_t source_handle;
+
+        if( argc != 7 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        source_domid = strtol(argv[4], NULL, 0);
+        source_gfn = strtol(argv[5], NULL, 0);
+        source_handle = strtol(argv[6], NULL, 0);
+        R(xc_memshr_add_to_physmap(xch, source_domid, source_gfn, source_handle, domid, gfn));
+    }
+    else if( !strcasecmp(cmd, "debug-gfn") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        R(xc_memshr_debug_gfn(xch, domid, gfn));
+    }
+
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmcgB-00087O-Jw; Mon, 16 Jan 2012 02:52: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 1RmcgA-00083Z-1Q
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326682327!10479708!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTc2NTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12148 invoked from network); 16 Jan 2012 02:52:07 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-13.tower-182.messagelabs.com with SMTP;
	16 Jan 2012 02:52:07 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id EE1A3604078;
	Sun, 15 Jan 2012 18:52:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ffT+hpiQZk6Lp51BgL7ZEjWno6lLb7prbtotMm0uuh26
	v/6/kgaAY8QtdKiLfps144NGZGlnFC0uh4QGJGCUvVen0ehOsRXnCDfOyci9TP+g
	/1o1rpBA8ZIZkW3VUW+Q5VhkSWx2xhVK3c/MflyFlzYPY+KzI48xLC9T402VFas=
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=Kanv5eE6mCgA1SBjquA/q2nvYc8=; b=RG2piqBE9s1
	zrmkztX8I0jdd6cblCVtQcQ7qZxXoLglB0HILJyRKo1Vhx0JJWUTIxuhdVBS7sQy
	+caYBhjPWr6cI4CIklkdfq10VcVIcyPBLZMH9Zm3UjhactGRLyyKzuoBwpITPPFN
	LwFW+5iGnNwT03qWhLk3fg173ZeOefEw=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 31FE760407C; 
	Sun, 15 Jan 2012 18:52:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 82e900cc725549100751f6876d2cf9e12fb2ce6a
Message-Id: <82e900cc725549100751.1326682592@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56: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 12 of 12] Memshrtool: tool to test and exercise
 the sharing subsystem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/tests/mem-sharing/Makefile     |   26 +++++
 tools/tests/mem-sharing/memshrtool.c |  165 +++++++++++++++++++++++++++++++++++
 2 files changed, 191 insertions(+), 0 deletions(-)


This is demo code meant to showcase how to perform sharing
operations. It is useful for testing. We submit it so others in
the list can have unlimited sharing fun, but not necessarily
expecting it be added to the tree.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 6522ae36bc61 -r 82e900cc7255 tools/tests/mem-sharing/Makefile
--- /dev/null
+++ b/tools/tests/mem-sharing/Makefile
@@ -0,0 +1,26 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS += -Werror
+
+CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_xeninclude)
+
+TARGETS-y := 
+TARGETS-$(CONFIG_X86) += memshrtool
+TARGETS := $(TARGETS-y)
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: $(TARGETS)
+
+.PHONY: clean
+clean:
+	$(RM) *.o $(TARGETS) *~ $(DEPS)
+
+memshrtool: memshrtool.o
+	$(CC) -o $@ $< $(LDFLAGS) $(LDLIBS_libxenctrl)
+
+-include $(DEPS)
diff -r 6522ae36bc61 -r 82e900cc7255 tools/tests/mem-sharing/memshrtool.c
--- /dev/null
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -0,0 +1,165 @@
+/*
+ * memshrtool.c
+ *
+ * Copyright 2011 GridCentric Inc. (Adin Scannell, Andres Lagar-Cavilla)
+ */
+
+#include <stdio.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <errno.h>
+#include <string.h>
+#include <sys/mman.h>
+
+#include "xenctrl.h"
+
+static int usage(const char* prog)
+{
+    printf("usage: %s <command> [args...]\n", prog);
+    printf("where <command> may be:\n");
+    printf("  info                    - Display total sharing info.\n");
+    printf("  enable                  - Enable sharing on a domain.\n");
+    printf("  disable                 - Disable sharing on a domain.\n");
+    printf("  nominate <domid> <gfn>  - Nominate a page for sharing.\n");
+    printf("  share <domid> <gfn> <handle> <source> <source-gfn> <source-handle>\n");
+    printf("                          - Share two pages.\n");
+    printf("  unshare <domid> <gfn>   - Unshare a page by grabbing a writable map.\n");
+    printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
+    printf("                          - Populate a page in a domain with a shared page.\n");
+    printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    return 1;
+}
+
+#define R(f) do { \
+    int rc = f; \
+    if ( rc < 0 ) { \
+        printf("error executing %s: %s\n", #f, \
+                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                "problem with client handle" :\
+                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                "problem with source handle" : strerror(errno)); \
+        return rc; \
+    } \
+} while(0)
+
+int main(int argc, const char** argv)
+{
+    const char* cmd = NULL;
+    xc_interface *xch = xc_interface_open(0, 0, 0);
+
+    if( argc < 2 )
+        return usage(argv[0]);
+
+    cmd = argv[1];
+
+    if( !strcasecmp(cmd, "info") )
+    {
+        if( argc != 2 )
+            return usage(argv[0]);
+
+        printf("used = %ld\n", xc_sharing_used_frames(xch));
+        printf("freed = %ld\n", xc_sharing_freed_pages(xch));
+    }
+    else if( !strcasecmp(cmd, "enable") )
+    {
+        domid_t domid;
+
+        if( argc != 3 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        R(xc_memshr_control(xch, domid, 1));
+    }
+    else if( !strcasecmp(cmd, "disable") )
+    {
+        domid_t domid;
+
+        if( argc != 3 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        R(xc_memshr_control(xch, domid, 0));
+    }
+    else if( !strcasecmp(cmd, "nominate") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        uint64_t handle;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        R(xc_memshr_nominate_gfn(xch, domid, gfn, &handle));
+        printf("handle = 0x%08llx\n", (unsigned long long) handle);
+    }
+    else if( !strcasecmp(cmd, "share") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        uint64_t handle;
+        domid_t source_domid;
+        unsigned long source_gfn;
+        uint64_t source_handle;
+
+        if( argc != 8 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        handle = strtol(argv[4], NULL, 0);
+        source_domid = strtol(argv[5], NULL, 0);
+        source_gfn = strtol(argv[6], NULL, 0);
+        source_handle = strtol(argv[7], NULL, 0);
+        R(xc_memshr_share_gfns(xch, source_domid, source_gfn, source_handle, domid, gfn, handle));
+    }
+    else if( !strcasecmp(cmd, "unshare") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        void *map;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        map = xc_map_foreign_range(xch, domid, 4096, PROT_WRITE, gfn);
+        if( map )
+            munmap(map, 4096);
+        R((int)!map);
+    }
+    else if( !strcasecmp(cmd, "add-to-physmap") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        domid_t source_domid;
+        unsigned long source_gfn;
+        uint64_t source_handle;
+
+        if( argc != 7 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        source_domid = strtol(argv[4], NULL, 0);
+        source_gfn = strtol(argv[5], NULL, 0);
+        source_handle = strtol(argv[6], NULL, 0);
+        R(xc_memshr_add_to_physmap(xch, source_domid, source_gfn, source_handle, domid, gfn));
+    }
+    else if( !strcasecmp(cmd, "debug-gfn") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        R(xc_memshr_debug_gfn(xch, domid, gfn));
+    }
+
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 02:52:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmcgB-000873-7X; Mon, 16 Jan 2012 02:52:15 +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 1Rmcg9-00083W-Ur
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326682326!9187190!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc2NzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19770 invoked from network); 16 Jan 2012 02:52:07 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-12.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 02:52:07 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 03AD2604084;
	Sun, 15 Jan 2012 18:52:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=UXSQeNUghyEyhmQbfcV0bHox7CZ/84WXLWsIn57DQ680
	D/PeNYVxy2f1w1t+AwvzoNMYERRXXv9giP0TtCZHfwpUvZxIbXeOHS6wqbbAp93a
	KL/aqiIpsew4kTtRFODYiT+ZNssQAaJeB2GmM1Y4Wk93eLAw03zIDyvEtu+jQKM=
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=XzEYTgM90/Dk0ddzNldM98l8HdA=; b=e2cauF7wMh7
	yDhKseRiKl/tZ5YNnoh3yqzShNCfnnDEiejnCF41/cCHdLgDQi9An0krlWV1MlLA
	kPGCEZVGY+rDD7TBl9H1m0n+dco37kEWPKLZzDQkBVn9n9G4r5gn7N03H/iqdLpr
	7MitHIluC47vMNOlUjgNdiQHv4sPJfwQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 2FC7A60407C; 
	Sun, 15 Jan 2012 18:52:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6522ae36bc61cd461754f2d26aae86643717ddaa
Message-Id: <6522ae36bc61cd461754.1326682591@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56:31 -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 12] 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           |  13 ++++++++
 tools/libxl/libxl.c         |   2 +
 tools/libxl/libxl_types.idl |   2 +
 tools/libxl/xl.h            |   1 +
 tools/libxl/xl_cmdimpl.c    |  66 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c   |   5 +++
 6 files changed, 89 insertions(+), 0 deletions(-)


Also add the global sharing statistics to the libxl physinfo.  This is a slight
departure from libxc, but there's no reason libxl physinfo can't include extra
bits of useful and relevant information.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r b596035ff0e2 -r 6522ae36bc61 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -410,6 +410,19 @@ Leave domain running after creating the 
 
 =back
 
+=item B<sharing> [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.
+
+=back
 
 =item B<shutdown> [I<OPTIONS>] I<domain-id>
 
diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2518,6 +2518,8 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->total_pages = xcphysinfo.total_pages;
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
+    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
+    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
     physinfo->phys_cap = xcphysinfo.capabilities;
diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -366,6 +366,8 @@ libxl_physinfo = Struct("physinfo", [
     ("total_pages", uint64),
     ("free_pages", uint64),
     ("scrub_pages", uint64),
+    ("sharing_freed_pages", uint64),
+    ("sharing_used_frames", uint64),
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
diff -r b596035ff0e2 -r 6522ae36bc61 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 b596035ff0e2 -r 6522ae36bc61 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3693,6 +3693,8 @@ static void output_physinfo(void)
         i = (1 << 20) / vinfo->pagesize;
         printf("total_memory           : %"PRIu64"\n", info.total_pages / i);
         printf("free_memory            : %"PRIu64"\n", info.free_pages / i);
+        printf("sharing_freed_memory   : %"PRIu64"\n", info.sharing_freed_pages / i);
+        printf("sharing_used_memory    : %"PRIu64"\n", info.sharing_used_frames / i);
     }
     if (!libxl_get_freecpus(ctx, &cpumap)) {
         libxl_for_each_cpu(i, cpumap)
@@ -3776,6 +3778,70 @@ int main_info(int argc, char **argv)
     return 0;
 }
 
+static void sharing(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);
+    }
+}
+
+int main_sharing(int argc, char **argv)
+{
+    int opt = 0;
+    libxl_dominfo info_buf;
+    libxl_dominfo *info, *info_free = NULL;
+    int nb_domain, rc;
+
+    if ((opt = def_getopt(argc, argv, "", "sharing", 0)) != -1)
+        return opt;
+
+    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(info, nb_domain);
+
+    if (info_free)
+        free(info_free);
+
+    return 0;
+}
+
 static int sched_credit_domain_get(
     int domid, libxl_sched_credit *scinfo)
 {
diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -189,6 +189,11 @@ 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",
+      "[Domain]", 
+    },
     { "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 Mon Jan 16 02:52:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmcgB-000873-7X; Mon, 16 Jan 2012 02:52:15 +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 1Rmcg9-00083W-Ur
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326682326!9187190!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc2NzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19770 invoked from network); 16 Jan 2012 02:52:07 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-12.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 02:52:07 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 03AD2604084;
	Sun, 15 Jan 2012 18:52:06 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=UXSQeNUghyEyhmQbfcV0bHox7CZ/84WXLWsIn57DQ680
	D/PeNYVxy2f1w1t+AwvzoNMYERRXXv9giP0TtCZHfwpUvZxIbXeOHS6wqbbAp93a
	KL/aqiIpsew4kTtRFODYiT+ZNssQAaJeB2GmM1Y4Wk93eLAw03zIDyvEtu+jQKM=
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=XzEYTgM90/Dk0ddzNldM98l8HdA=; b=e2cauF7wMh7
	yDhKseRiKl/tZ5YNnoh3yqzShNCfnnDEiejnCF41/cCHdLgDQi9An0krlWV1MlLA
	kPGCEZVGY+rDD7TBl9H1m0n+dco37kEWPKLZzDQkBVn9n9G4r5gn7N03H/iqdLpr
	7MitHIluC47vMNOlUjgNdiQHv4sPJfwQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 2FC7A60407C; 
	Sun, 15 Jan 2012 18:52:05 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6522ae36bc61cd461754f2d26aae86643717ddaa
Message-Id: <6522ae36bc61cd461754.1326682591@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56:31 -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 12] 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           |  13 ++++++++
 tools/libxl/libxl.c         |   2 +
 tools/libxl/libxl_types.idl |   2 +
 tools/libxl/xl.h            |   1 +
 tools/libxl/xl_cmdimpl.c    |  66 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c   |   5 +++
 6 files changed, 89 insertions(+), 0 deletions(-)


Also add the global sharing statistics to the libxl physinfo.  This is a slight
departure from libxc, but there's no reason libxl physinfo can't include extra
bits of useful and relevant information.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r b596035ff0e2 -r 6522ae36bc61 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -410,6 +410,19 @@ Leave domain running after creating the 
 
 =back
 
+=item B<sharing> [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.
+
+=back
 
 =item B<shutdown> [I<OPTIONS>] I<domain-id>
 
diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2518,6 +2518,8 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->total_pages = xcphysinfo.total_pages;
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
+    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
+    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
     physinfo->phys_cap = xcphysinfo.capabilities;
diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -366,6 +366,8 @@ libxl_physinfo = Struct("physinfo", [
     ("total_pages", uint64),
     ("free_pages", uint64),
     ("scrub_pages", uint64),
+    ("sharing_freed_pages", uint64),
+    ("sharing_used_frames", uint64),
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
diff -r b596035ff0e2 -r 6522ae36bc61 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 b596035ff0e2 -r 6522ae36bc61 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3693,6 +3693,8 @@ static void output_physinfo(void)
         i = (1 << 20) / vinfo->pagesize;
         printf("total_memory           : %"PRIu64"\n", info.total_pages / i);
         printf("free_memory            : %"PRIu64"\n", info.free_pages / i);
+        printf("sharing_freed_memory   : %"PRIu64"\n", info.sharing_freed_pages / i);
+        printf("sharing_used_memory    : %"PRIu64"\n", info.sharing_used_frames / i);
     }
     if (!libxl_get_freecpus(ctx, &cpumap)) {
         libxl_for_each_cpu(i, cpumap)
@@ -3776,6 +3778,70 @@ int main_info(int argc, char **argv)
     return 0;
 }
 
+static void sharing(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);
+    }
+}
+
+int main_sharing(int argc, char **argv)
+{
+    int opt = 0;
+    libxl_dominfo info_buf;
+    libxl_dominfo *info, *info_free = NULL;
+    int nb_domain, rc;
+
+    if ((opt = def_getopt(argc, argv, "", "sharing", 0)) != -1)
+        return opt;
+
+    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(info, nb_domain);
+
+    if (info_free)
+        free(info_free);
+
+    return 0;
+}
+
 static int sched_credit_domain_get(
     int domid, libxl_sched_credit *scinfo)
 {
diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -189,6 +189,11 @@ 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",
+      "[Domain]", 
+    },
     { "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 Mon Jan 16 02:52:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmcgA-00086s-RQ; Mon, 16 Jan 2012 02:52: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 1Rmcg8-000833-DD
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326682325!7932412!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzc4MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16005 invoked from network); 16 Jan 2012 02:52:06 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.66) by server-7.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 02:52:06 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 00968604078;
	Sun, 15 Jan 2012 18:52:05 -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=MZDjVcB96WyKKb4PuR5C40eVkfFKHRqTJ1J5nh+7Ly4D
	0RWqx15DLybhxQNEDykdEMGE9H3GE7PCayqHNgZGky7suRHhSOVY3+oUbFwwIBG2
	wvUYHW3bGVUxz+fqlWlBl6d2dc9Mex4P6aLVXZO8iFTBoYoyJYygPDUUnau2RUM=
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=WqMM4fkgrKJbpLx0Qu2dKp/ArMQ=; b=Dyjqn7eTZkg
	OmO0N/w9Lt8jxImoohZPwt0TGq1mNrMbG5UO0VY0a5qvutdua66Ntjk+v+SAK++k
	0rjBzzhrITPMmrORK2qwq6jQP5bI9KRYLdYNKUDS7OfcqLvxFSbDvRpOtRxNs56e
	56m/daU7bQbe9ft+hfSmSu6eFaDl/7rQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 264F360407C; 
	Sun, 15 Jan 2012 18:52:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b596035ff0e2804281eaea162badcfe4abee78ae
Message-Id: <b596035ff0e2804281ea.1326682590@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56:30 -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 12] 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_memshr.c |  10 ++++++++++
 tools/libxc/xenctrl.h   |  17 +++++++++++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2d6a14ce5b0e -r b596035ff0e2 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -225,3 +225,13 @@ int xc_memshr_debug_gref(xc_interface *x
     return do_domctl(xch, &domctl);
 }
 
+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);
+}
+
diff -r 2d6a14ce5b0e -r b596035ff0e2 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1226,6 +1226,23 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
+/**
+ * This function returns the total number of pages freed by using sharing
+ * on the system.  For example, if two domains contain a single entry in
+ * their p2m map that points to the same shared page (and no other pages
+ * in the system are shared), then this function should return 1.
+ */
+long xc_sharing_freed_pages(xc_interface *xch);
+
+/**
+ * This function returns the total number of frames occupied by shared
+ * pages on the system.  This is independent of the number of domains
+ * pointing at these frames.  For example, in the above scenario this
+ * should return 1. The following should hold:
+ *  memory usage without sharing = freed_pages + used_frames
+ */
+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 Mon Jan 16 02:52:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 02:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmcgA-00086s-RQ; Mon, 16 Jan 2012 02:52: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 1Rmcg8-000833-DD
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 02:52:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326682325!7932412!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzc4MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16005 invoked from network); 16 Jan 2012 02:52:06 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.66) by server-7.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 02:52:06 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 00968604078;
	Sun, 15 Jan 2012 18:52:05 -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=MZDjVcB96WyKKb4PuR5C40eVkfFKHRqTJ1J5nh+7Ly4D
	0RWqx15DLybhxQNEDykdEMGE9H3GE7PCayqHNgZGky7suRHhSOVY3+oUbFwwIBG2
	wvUYHW3bGVUxz+fqlWlBl6d2dc9Mex4P6aLVXZO8iFTBoYoyJYygPDUUnau2RUM=
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=WqMM4fkgrKJbpLx0Qu2dKp/ArMQ=; b=Dyjqn7eTZkg
	OmO0N/w9Lt8jxImoohZPwt0TGq1mNrMbG5UO0VY0a5qvutdua66Ntjk+v+SAK++k
	0rjBzzhrITPMmrORK2qwq6jQP5bI9KRYLdYNKUDS7OfcqLvxFSbDvRpOtRxNs56e
	56m/daU7bQbe9ft+hfSmSu6eFaDl/7rQ=
Received: from xdev.gridcentric.ca (unknown [206.223.182.18])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPSA id 264F360407C; 
	Sun, 15 Jan 2012 18:52:04 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b596035ff0e2804281eaea162badcfe4abee78ae
Message-Id: <b596035ff0e2804281ea.1326682590@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1326682580@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Sun, 15 Jan 2012 21:56:30 -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 12] 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_memshr.c |  10 ++++++++++
 tools/libxc/xenctrl.h   |  17 +++++++++++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2d6a14ce5b0e -r b596035ff0e2 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -225,3 +225,13 @@ int xc_memshr_debug_gref(xc_interface *x
     return do_domctl(xch, &domctl);
 }
 
+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);
+}
+
diff -r 2d6a14ce5b0e -r b596035ff0e2 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1226,6 +1226,23 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
+/**
+ * This function returns the total number of pages freed by using sharing
+ * on the system.  For example, if two domains contain a single entry in
+ * their p2m map that points to the same shared page (and no other pages
+ * in the system are shared), then this function should return 1.
+ */
+long xc_sharing_freed_pages(xc_interface *xch);
+
+/**
+ * This function returns the total number of frames occupied by shared
+ * pages on the system.  This is independent of the number of domains
+ * pointing at these frames.  For example, in the above scenario this
+ * should return 1. The following should hold:
+ *  memory usage without sharing = freed_pages + used_frames
+ */
+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 Mon Jan 16 06:57:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 06: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 1RmgUV-0003E7-HC; Mon, 16 Jan 2012 06:56: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 1RmgUT-0003E1-UG
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 06:56:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326696934!52656269!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1364 invoked from network); 16 Jan 2012 06:55:34 -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 Jan 2012 06:55:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10034973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 06:56:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 06:56: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 1RmgUR-0000es-7N;
	Mon, 16 Jan 2012 06:56:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmgUR-00014p-0a;
	Mon, 16 Jan 2012 06:56:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10761-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 06:56:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10761: 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 10761 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10761/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10539

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10539
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               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-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass

version targeted for testing:
 xen                  d5b26918cd94
baseline version:
 xen                  5d372b8bccef

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.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:   21557:d5b26918cd94
tag:         tip
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:54 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
    
    
changeset:   21556:5d372b8bccef
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
    
    
(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 Jan 16 06:57:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 06: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 1RmgUV-0003E7-HC; Mon, 16 Jan 2012 06:56: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 1RmgUT-0003E1-UG
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 06:56:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326696934!52656269!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1364 invoked from network); 16 Jan 2012 06:55:34 -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 Jan 2012 06:55:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10034973"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 06:56:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 06:56: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 1RmgUR-0000es-7N;
	Mon, 16 Jan 2012 06:56:23 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmgUR-00014p-0a;
	Mon, 16 Jan 2012 06:56:23 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10761-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 06:56:23 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10761: 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 10761 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10761/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10539

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10539
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               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-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass

version targeted for testing:
 xen                  d5b26918cd94
baseline version:
 xen                  5d372b8bccef

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.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:   21557:d5b26918cd94
tag:         tip
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:54 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
    
    
changeset:   21556:5d372b8bccef
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
    
    
(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 Jan 16 08:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 08:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmhmw-0004uZ-EL; Mon, 16 Jan 2012 08:19: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 1Rmhmu-0004uQ-4e
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:19:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326701965!11119151!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 7874 invoked from network); 16 Jan 2012 08:19:26 -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; 16 Jan 2012 08:19:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Jan 2012 08:19:25 +0000
Message-Id: <4F13EB98020000780006CC97@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Jan 2012 08:19:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
	<4F105DD1020000780006C8A5@nat28.tlf.novell.com>
	<4F105144.8070004@tycho.nsa.gov>
	<4F10633D020000780006C8F4@nat28.tlf.novell.com>
	<4F106CFC.1030204@tycho.nsa.gov>
In-Reply-To: <4F106CFC.1030204@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.01.12 at 18:42, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/13/2012 11:00 AM, Jan Beulich wrote:
>>>>> On 13.01.12 at 16:44, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 01/13/2012 10:37 AM, Jan Beulich wrote:
>>>>>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>>>> --- a/include/xen/xenbus_dev.h
>>>>>>> +++ b/include/xen/xenbus_dev.h
>>>>>>> @@ -38,4 +38,18 @@
>>>>>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>>>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>>>>>  
>>>>>>> +#define IOCTL_XENBUS_ALLOC				\
>>>>>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>>>>>> +struct ioctl_xenbus_alloc {
>>>>>>> +	/* IN */
>>>>>>> +	/* The domain ID (must exist) for xenstore */
>>>>>>> +	uint16_t dom;
>>>>>>> +	uint16_t pad;
>>>>>>> +	/* OUT */
>>>>>>> +	/* The port allocated for xenbus communication */
>>>>>>> +	uint32_t port;
>>>>>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>>>>>> +	uint32_t grant_ref;
>>>>>>> +};
>>>>>>
>>>>>> As said in my reply to the previous patch version - if the functionality
>>>>>> differs, the number *and* name should be different from the legacy
>>>>>> implementation's. Otherwise, how should compatible user space code
>>>>>> be written?
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>
>>>>> This implementation has the same functionality as the legacy ioctl,
>>>>
>>>> It doesn't - none of the "OUT" fields above exist there.
>>>
>>> Are you looking at the same legacy ioctl as I am? I found it in 2.6.18.hg
>>> where the structure was defined as:
>>>
>>> typedef struct xenbus_alloc {
>>>     domid_t dom;
>>>     __u32 port;
>>>     __u32 grant_ref;
>>> } xenbus_alloc_t;
>>>
>>> The port and grant_ref fields were outputs. I added padding for clarity
>>> since domid_t is uint16_t.
>> 
>> Ooops, I'm sorry, indeed - I didn't look at the names and types
>> closely enough. They were too different, so I assumed the whole
>> thing is different.
>> 
>> That doesn't eliminate the difference between the two
>> IOCTL_XENBUS_ALLOC definitions, though
>> [_IOC(_IOC_NONE, 'X', 0, sizeof(xenbus_alloc_t)) vs
>> _IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))] - one
>> still can't use both in the same source file.
> 
> Is compatibility with 2.6.18-xen more important than keeping the ioctl
> numbers in a single file consistent? The definition in 2.6.18 is also
> incorrect (as was my definition) - since the argument is used, it needs
> to use _IOWR() or _IOC_READ|_IOC_WRITE instead of _IOC_NONE.

Hmm, that would mean that apart from IOCTL_EVTCHN_RESET *all*
current ioctl number definitions under include/xen/ are wrong. Very
bad, and ugly to deal with. With generic ioctl handling code not
depending on this, I wonder though whether it's worth fixing at all.
Are you aware of any user mode code depending on the correctness
of these bits?

Which of course isn't to say that it shouldn't be done right for new
ones...

> Since this ioctl must already be performed a different file than the
> legacy ioctl, a new name seems to be the best solution.

That's what I was trying to ask you 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 Mon Jan 16 08:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 08:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmhmw-0004uZ-EL; Mon, 16 Jan 2012 08:19: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 1Rmhmu-0004uQ-4e
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:19:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326701965!11119151!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 7874 invoked from network); 16 Jan 2012 08:19:26 -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; 16 Jan 2012 08:19:26 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Jan 2012 08:19:25 +0000
Message-Id: <4F13EB98020000780006CC97@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Jan 2012 08:19:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<4F0FF742020000780006C5CE@nat28.tlf.novell.com>
	<4F103A62.3000403@tycho.nsa.gov>
	<4F105DD1020000780006C8A5@nat28.tlf.novell.com>
	<4F105144.8070004@tycho.nsa.gov>
	<4F10633D020000780006C8F4@nat28.tlf.novell.com>
	<4F106CFC.1030204@tycho.nsa.gov>
In-Reply-To: <4F106CFC.1030204@tycho.nsa.gov>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 13.01.12 at 18:42, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> On 01/13/2012 11:00 AM, Jan Beulich wrote:
>>>>> On 13.01.12 at 16:44, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>> On 01/13/2012 10:37 AM, Jan Beulich wrote:
>>>>>>> On 13.01.12 at 15:06, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>> On 01/13/2012 03:20 AM, Jan Beulich wrote:
>>>>>>>>> On 13.01.12 at 00:36, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>>>>> --- a/include/xen/xenbus_dev.h
>>>>>>> +++ b/include/xen/xenbus_dev.h
>>>>>>> @@ -38,4 +38,18 @@
>>>>>>>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>>>>>>>  	_IOC(_IOC_NONE, 'B', 0, 0)
>>>>>>>  
>>>>>>> +#define IOCTL_XENBUS_ALLOC				\
>>>>>>> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
>>>>>>> +struct ioctl_xenbus_alloc {
>>>>>>> +	/* IN */
>>>>>>> +	/* The domain ID (must exist) for xenstore */
>>>>>>> +	uint16_t dom;
>>>>>>> +	uint16_t pad;
>>>>>>> +	/* OUT */
>>>>>>> +	/* The port allocated for xenbus communication */
>>>>>>> +	uint32_t port;
>>>>>>> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
>>>>>>> +	uint32_t grant_ref;
>>>>>>> +};
>>>>>>
>>>>>> As said in my reply to the previous patch version - if the functionality
>>>>>> differs, the number *and* name should be different from the legacy
>>>>>> implementation's. Otherwise, how should compatible user space code
>>>>>> be written?
>>>>>>
>>>>>> Jan
>>>>>>
>>>>>
>>>>> This implementation has the same functionality as the legacy ioctl,
>>>>
>>>> It doesn't - none of the "OUT" fields above exist there.
>>>
>>> Are you looking at the same legacy ioctl as I am? I found it in 2.6.18.hg
>>> where the structure was defined as:
>>>
>>> typedef struct xenbus_alloc {
>>>     domid_t dom;
>>>     __u32 port;
>>>     __u32 grant_ref;
>>> } xenbus_alloc_t;
>>>
>>> The port and grant_ref fields were outputs. I added padding for clarity
>>> since domid_t is uint16_t.
>> 
>> Ooops, I'm sorry, indeed - I didn't look at the names and types
>> closely enough. They were too different, so I assumed the whole
>> thing is different.
>> 
>> That doesn't eliminate the difference between the two
>> IOCTL_XENBUS_ALLOC definitions, though
>> [_IOC(_IOC_NONE, 'X', 0, sizeof(xenbus_alloc_t)) vs
>> _IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))] - one
>> still can't use both in the same source file.
> 
> Is compatibility with 2.6.18-xen more important than keeping the ioctl
> numbers in a single file consistent? The definition in 2.6.18 is also
> incorrect (as was my definition) - since the argument is used, it needs
> to use _IOWR() or _IOC_READ|_IOC_WRITE instead of _IOC_NONE.

Hmm, that would mean that apart from IOCTL_EVTCHN_RESET *all*
current ioctl number definitions under include/xen/ are wrong. Very
bad, and ugly to deal with. With generic ioctl handling code not
depending on this, I wonder though whether it's worth fixing at all.
Are you aware of any user mode code depending on the correctness
of these bits?

Which of course isn't to say that it shouldn't be done right for new
ones...

> Since this ioctl must already be performed a different file than the
> legacy ioctl, a new name seems to be the best solution.

That's what I was trying to ask you 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 Mon Jan 16 08:57:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 08:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmiNG-0005ak-Gr; Mon, 16 Jan 2012 08:57: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 1RmiNE-0005aV-Nn
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:57:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326704217!8625456!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 18179 invoked from network); 16 Jan 2012 08:56:58 -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 Jan 2012 08:56:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Jan 2012 08:56:56 +0000
Message-Id: <4F13F463020000780006CCB0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Jan 2012 08:56:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <osstest-10755-mainreport@xen.org>
	<CB38FF8E.28C06%keir.xen@gmail.com>
In-Reply-To: <CB38FF8E.28C06%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 10755: 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 15.01.12 at 23:11, Keir Fraser <keir.xen@gmail.com> wrote:
> The build failure on amd64 is your fault. It's fallout from the config.h
> build changes.

Sorry, yes - shouldn't have relied on incremental builds here. Should
be fixed with 24513:0d4a60bf37b9.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 08:57:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 08:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmiNG-0005ak-Gr; Mon, 16 Jan 2012 08:57: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 1RmiNE-0005aV-Nn
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:57:04 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326704217!8625456!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 18179 invoked from network); 16 Jan 2012 08:56:58 -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 Jan 2012 08:56:58 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Jan 2012 08:56:56 +0000
Message-Id: <4F13F463020000780006CCB0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Jan 2012 08:56:51 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <osstest-10755-mainreport@xen.org>
	<CB38FF8E.28C06%keir.xen@gmail.com>
In-Reply-To: <CB38FF8E.28C06%keir.xen@gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 10755: 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 15.01.12 at 23:11, Keir Fraser <keir.xen@gmail.com> wrote:
> The build failure on amd64 is your fault. It's fallout from the config.h
> build changes.

Sorry, yes - shouldn't have relied on incremental builds here. Should
be fixed with 24513:0d4a60bf37b9.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 09:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09: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 1RmiWX-0005ou-Tm; Mon, 16 Jan 2012 09:06: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 1RmiWW-0005op-BC
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:06:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326704733!61107865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 347 invoked from network); 16 Jan 2012 09:05:33 -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;
	16 Jan 2012 09:05:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10036884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:06: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, 16 Jan 2012 09:06: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 1RmiWU-0001cY-Dl;
	Mon, 16 Jan 2012 09:06:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmiWU-00028z-6k;
	Mon, 16 Jan 2012 09:06:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10762-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 09:06:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10762: 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 10762 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10762/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             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-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-winxpsp3   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

version targeted for testing:
 xen                  e29b7691fefc
baseline version:
 xen                  22ea8496051d

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Michael Young <m.a.young@durham.ac.uk>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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=e29b7691fefc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 e29b7691fefc
+ branch=xen-4.1-testing
+ revision=e29b7691fefc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 e29b7691fefc 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 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 Jan 16 09:07:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09: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 1RmiWX-0005ou-Tm; Mon, 16 Jan 2012 09:06: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 1RmiWW-0005op-BC
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:06:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326704733!61107865!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 347 invoked from network); 16 Jan 2012 09:05:33 -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;
	16 Jan 2012 09:05:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10036884"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:06: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, 16 Jan 2012 09:06: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 1RmiWU-0001cY-Dl;
	Mon, 16 Jan 2012 09:06:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmiWU-00028z-6k;
	Mon, 16 Jan 2012 09:06:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10762-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 09:06:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10762: 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 10762 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10762/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-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-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             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-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-winxpsp3   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

version targeted for testing:
 xen                  e29b7691fefc
baseline version:
 xen                  22ea8496051d

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Michael Young <m.a.young@durham.ac.uk>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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=e29b7691fefc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 e29b7691fefc
+ branch=xen-4.1-testing
+ revision=e29b7691fefc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 e29b7691fefc 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 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 Jan 16 09:33:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmivZ-0006Mo-Sy; Mon, 16 Jan 2012 09:32:33 +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 1RmivZ-0006Mf-1z
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:32:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326706347!8650758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19608 invoked from network); 16 Jan 2012 09:32:27 -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;
	16 Jan 2012 09:32:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10038107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:31:58 +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;
	Mon, 16 Jan 2012 09:31:57 +0000
Message-ID: <1326706272.5285.3.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 16 Jan 2012 09:31:12 +0000
In-Reply-To: <20120113173746.GA16182@phenom.dumpdata.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-2-git-send-email-wei.liu2@citrix.com>
	<20120113173746.GA16182@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/6] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 17:37 +0000, Konrad Rzeszutek Wilk wrote:
> > +static idx_t free_head;
> > +static int free_count;
> > +static unsigned long pool_size;
> > +static DEFINE_SPINLOCK(pool_lock);
> > +static struct page_pool_entry *pool;
> > +
> > +static int get_free_entry(void)
> > +{
> > +	unsigned long flag;
> > +	int idx;
> > +
> > +	spin_lock_irqsave(&pool_lock, flag);
> 
> What is the benfit of using the irq version of the spinlock instead
> of the normal one??
> 

This should be vestige of iterations, fixed.

Thanks
Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 09:33:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09:33:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmivZ-0006Mo-Sy; Mon, 16 Jan 2012 09:32:33 +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 1RmivZ-0006Mf-1z
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:32:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326706347!8650758!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19608 invoked from network); 16 Jan 2012 09:32:27 -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;
	16 Jan 2012 09:32:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10038107"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:31:58 +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;
	Mon, 16 Jan 2012 09:31:57 +0000
Message-ID: <1326706272.5285.3.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 16 Jan 2012 09:31:12 +0000
In-Reply-To: <20120113173746.GA16182@phenom.dumpdata.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-2-git-send-email-wei.liu2@citrix.com>
	<20120113173746.GA16182@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH 1/6] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 17:37 +0000, Konrad Rzeszutek Wilk wrote:
> > +static idx_t free_head;
> > +static int free_count;
> > +static unsigned long pool_size;
> > +static DEFINE_SPINLOCK(pool_lock);
> > +static struct page_pool_entry *pool;
> > +
> > +static int get_free_entry(void)
> > +{
> > +	unsigned long flag;
> > +	int idx;
> > +
> > +	spin_lock_irqsave(&pool_lock, flag);
> 
> What is the benfit of using the irq version of the spinlock instead
> of the normal one??
> 

This should be vestige of iterations, fixed.

Thanks
Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 09:33:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09: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 1Rmiw3-0006OC-A5; Mon, 16 Jan 2012 09:33:03 +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 1Rmiw1-0006Nz-74
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:33:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326706368!9295739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10521 invoked from network); 16 Jan 2012 09:32:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 09:32:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10038198"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:32:44 +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;
	Mon, 16 Jan 2012 09:32:44 +0000
Message-ID: <1326706318.5285.4.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Date: Mon, 16 Jan 2012 09:31:58 +0000
In-Reply-To: <4F10709B.8070804@cantab.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
	<4F10709B.8070804@cantab.net>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 2/6] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 17:57 +0000, David Vrabel wrote:
> On 13/01/12 16:59, Wei Liu wrote:
> > Enables users to unload netback module.
> [...]
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 26af7b7..dd10c0d 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -1653,5 +1653,19 @@ failed_init:
> >  
> >  module_init(netback_init);
> >  
> > +static void __exit netback_exit(void)
> > +{
> > +	int i;
> > +	for (i = 0; i < xen_netbk_group_nr; i++) {
> > +		struct xen_netbk *netbk = &xen_netbk[i];
> > +		del_timer(&netbk->net_timer);
> 
> This needs to be del_timer_sync().
> 
> > +		kthread_stop(netbk->task);
> > +	}
> > +	vfree(xen_netbk);
> > +	page_pool_destroy();
> > +	xenvif_xenbus_exit();
> > +}

Both fixed.

Thanks
Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 09:33:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09: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 1Rmiw3-0006OC-A5; Mon, 16 Jan 2012 09:33:03 +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 1Rmiw1-0006Nz-74
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:33:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326706368!9295739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10521 invoked from network); 16 Jan 2012 09:32:48 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 09:32:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10038198"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:32:44 +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;
	Mon, 16 Jan 2012 09:32:44 +0000
Message-ID: <1326706318.5285.4.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Date: Mon, 16 Jan 2012 09:31:58 +0000
In-Reply-To: <4F10709B.8070804@cantab.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-3-git-send-email-wei.liu2@citrix.com>
	<4F10709B.8070804@cantab.net>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 2/6] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 17:57 +0000, David Vrabel wrote:
> On 13/01/12 16:59, Wei Liu wrote:
> > Enables users to unload netback module.
> [...]
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index 26af7b7..dd10c0d 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -1653,5 +1653,19 @@ failed_init:
> >  
> >  module_init(netback_init);
> >  
> > +static void __exit netback_exit(void)
> > +{
> > +	int i;
> > +	for (i = 0; i < xen_netbk_group_nr; i++) {
> > +		struct xen_netbk *netbk = &xen_netbk[i];
> > +		del_timer(&netbk->net_timer);
> 
> This needs to be del_timer_sync().
> 
> > +		kthread_stop(netbk->task);
> > +	}
> > +	vfree(xen_netbk);
> > +	page_pool_destroy();
> > +	xenvif_xenbus_exit();
> > +}

Both fixed.

Thanks
Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 09:34:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmix0-0006Ts-PS; Mon, 16 Jan 2012 09:34:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rmiwz-0006Tg-1n
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:34:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326706382!57037530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15482 invoked from network); 16 Jan 2012 09:33:03 -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;
	16 Jan 2012 09:33:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10038280"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:33: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;
	Mon, 16 Jan 2012 09:33:59 +0000
Message-ID: <1326706394.5285.5.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 16 Jan 2012 09:33:14 +0000
In-Reply-To: <4F107625.7090601@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> On 13/01/12 16:59, Wei Liu wrote:
> > This patch implements 1:1 model netback. We utilizes NAPI and kthread
> > to do the weight-lifting job:
> > 
> >   - NAPI is used for guest side TX (host side RX)
> >   - kthread is used for guest side RX (host side TX)
> > 
> > This model provides better scheduling fairness among vifs. It also
> > lays the foundation for future work.
> > 
> > The major defect for the current implementation is that in the NAPI
> > poll handler we don't actually disable interrupt. Xen stuff is
> > different from real hardware, it requires some other tuning of ring
> > macros.
> 
> RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to me.
> 
> David

I need to stop the other end from generating events, so
RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 09:34:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmix0-0006Ts-PS; Mon, 16 Jan 2012 09:34:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rmiwz-0006Tg-1n
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:34:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326706382!57037530!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15482 invoked from network); 16 Jan 2012 09:33:03 -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;
	16 Jan 2012 09:33:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10038280"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:33: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;
	Mon, 16 Jan 2012 09:33:59 +0000
Message-ID: <1326706394.5285.5.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Mon, 16 Jan 2012 09:33:14 +0000
In-Reply-To: <4F107625.7090601@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> On 13/01/12 16:59, Wei Liu wrote:
> > This patch implements 1:1 model netback. We utilizes NAPI and kthread
> > to do the weight-lifting job:
> > 
> >   - NAPI is used for guest side TX (host side RX)
> >   - kthread is used for guest side RX (host side TX)
> > 
> > This model provides better scheduling fairness among vifs. It also
> > lays the foundation for future work.
> > 
> > The major defect for the current implementation is that in the NAPI
> > poll handler we don't actually disable interrupt. Xen stuff is
> > different from real hardware, it requires some other tuning of ring
> > macros.
> 
> RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to me.
> 
> David

I need to stop the other end from generating events, so
RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 09:44:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmj6v-0006vO-4r; Mon, 16 Jan 2012 09:44:17 +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 1Rmj6u-0006vJ-5z
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:44:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326707050!8435396!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11507 invoked from network); 16 Jan 2012 09:44:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 09:44:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10038599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:44:10 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 09:44:10 +0000
Message-ID: <1326707004.5285.8.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Date: Mon, 16 Jan 2012 09:43:24 +0000
In-Reply-To: <4F107B89.6000004@cantab.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-5-git-send-email-wei.liu2@citrix.com>
	<4F107B89.6000004@cantab.net>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 4/6] netback: add module get/put
 operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 18:44 +0000, David Vrabel wrote:
> On 13/01/12 16:59, Wei Liu wrote:
> > If there is vif running and user unloads netback, it will certainly
> > cause problems.
> 
> Is this necessary?  As part of module unload netback_remove() will be
> called and this will clean everything correctly, yes?
> 

You're right here from the host's perspective of view. Everything gets
cleaned up.

But from the guest's perspective of view, its network interface just
mysteriously stops working.

So my "problems" in the above statements comes from guest, will make
commit message more clear.


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 09:44:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 09:44:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmj6v-0006vO-4r; Mon, 16 Jan 2012 09:44:17 +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 1Rmj6u-0006vJ-5z
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:44:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326707050!8435396!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11507 invoked from network); 16 Jan 2012 09:44:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 09:44:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10038599"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 09:44:10 +0000
Received: from [10.80.2.50] (10.80.2.50) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 09:44:10 +0000
Message-ID: <1326707004.5285.8.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: David Vrabel <dvrabel@cantab.net>
Date: Mon, 16 Jan 2012 09:43:24 +0000
In-Reply-To: <4F107B89.6000004@cantab.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-5-git-send-email-wei.liu2@citrix.com>
	<4F107B89.6000004@cantab.net>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 4/6] netback: add module get/put
 operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 18:44 +0000, David Vrabel wrote:
> On 13/01/12 16:59, Wei Liu wrote:
> > If there is vif running and user unloads netback, it will certainly
> > cause problems.
> 
> Is this necessary?  As part of module unload netback_remove() will be
> called and this will clean everything correctly, yes?
> 

You're right here from the host's perspective of view. Everything gets
cleaned up.

But from the guest's perspective of view, its network interface just
mysteriously stops working.

So my "problems" in the above statements comes from guest, will make
commit message more clear.


Wei.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:15:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:15:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmjaO-0007WQ-D5; Mon, 16 Jan 2012 10:14:44 +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 1RmjaM-0007WI-Ib
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:14:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326708809!61121097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27684 invoked from network); 16 Jan 2012 10:13:30 -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;
	16 Jan 2012 10:13:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10039844"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:14:35 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 16 Jan 2012
	10:14:35 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Date: Mon, 16 Jan 2012 10:14:33 +0000
Thread-Topic: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
	model
Thread-Index: AczSFP2qzjIHDKBnS7KOT3F6OKckhACIUKBA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC49@LONPMAILBOX01.citrite.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-4-git-send-email-wei.liu2@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: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Wei Liu
> Sent: 13 January 2012 16:59
> To: Ian Campbell; konrad.wilk@oracle.com; xen-
> devel@lists.xensource.com; netdev@vger.kernel.org
> Cc: Wei Liu (Intern)
> Subject: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
> model
> 
> This patch implements 1:1 model netback. We utilizes NAPI and kthread to
> do the weight-lifting job:
> 
>   - NAPI is used for guest side TX (host side RX)
>   - kthread is used for guest side RX (host side TX)
> 
> This model provides better scheduling fairness among vifs. It also lays the
> foundation for future work.
> 
> The major defect for the current implementation is that in the NAPI poll
> handler we don't actually disable interrupt. Xen stuff is different from real
> hardware, it requires some other tuning of ring macros.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
[snip]
> 
>  	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
>  	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS]; @@ -100,42
> +91,14 @@ struct xen_netbk {
>  	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];  };
> 

Keeping these big inline arrays might cause scalability issues. pending_tx_info should arguably me more closely tied in and possibly implemented within your page pool code.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:15:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:15:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmjaO-0007WQ-D5; Mon, 16 Jan 2012 10:14:44 +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 1RmjaM-0007WI-Ib
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:14:42 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326708809!61121097!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27684 invoked from network); 16 Jan 2012 10:13:30 -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;
	16 Jan 2012 10:13:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10039844"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:14:35 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 16 Jan 2012
	10:14:35 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>, 
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Date: Mon, 16 Jan 2012 10:14:33 +0000
Thread-Topic: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
	model
Thread-Index: AczSFP2qzjIHDKBnS7KOT3F6OKckhACIUKBA
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC49@LONPMAILBOX01.citrite.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1326473949-22389-4-git-send-email-wei.liu2@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: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Wei Liu
> Sent: 13 January 2012 16:59
> To: Ian Campbell; konrad.wilk@oracle.com; xen-
> devel@lists.xensource.com; netdev@vger.kernel.org
> Cc: Wei Liu (Intern)
> Subject: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
> model
> 
> This patch implements 1:1 model netback. We utilizes NAPI and kthread to
> do the weight-lifting job:
> 
>   - NAPI is used for guest side TX (host side RX)
>   - kthread is used for guest side RX (host side TX)
> 
> This model provides better scheduling fairness among vifs. It also lays the
> foundation for future work.
> 
> The major defect for the current implementation is that in the NAPI poll
> handler we don't actually disable interrupt. Xen stuff is different from real
> hardware, it requires some other tuning of ring macros.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
[snip]
> 
>  	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
>  	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS]; @@ -100,42
> +91,14 @@ struct xen_netbk {
>  	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];  };
> 

Keeping these big inline arrays might cause scalability issues. pending_tx_info should arguably me more closely tied in and possibly implemented within your page pool code.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmjhn-0007mL-IV; Mon, 16 Jan 2012 10:22:23 +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 1Rmjhm-0007mF-15
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:22:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326709335!11065291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1828 invoked from network); 16 Jan 2012 10:22:15 -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;
	16 Jan 2012 10:22:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10040165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:21: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, 16 Jan 2012 10:21:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Paul Durrant <paul.durrant@citrix.com>
Date: Mon, 16 Jan 2012 10:21:41 +0000
In-Reply-To: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326709302.17210.402.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] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-01-14 at 12:05 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-i386-i386-xl
> test guest-localmigrate
> 
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: 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:  3c4c5df2cd0e
>   Bug not present: 92630d4b093e
> 
> 
>   changeset:   24471:3c4c5df2cd0e
>   user:        Paul Durrant <paul.durrant@citrix.com>
>   date:        Fri Dec 16 14:54:14 2011 +0000
>       
>       tools: 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>
>       Committed-by: Ian Jackson <ian.jackson.citrix.com>

The logs show a guest kernel crash but I think this is a second order
effect (which I'll investigate) related to xl not recovering from a
failed migration in a way that guest kernels actually like.

The original failure seems to be a PV migration failure. Paul can you
look into that aspect please. Probably an imbalance for PV save/restore
due to something not correctly gated on HVM on one side or the other.

Thanks,
Ian.

>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-xl.guest-localmigrate.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  10700 fail [host=woodlouse] / 10649 ok.
> Failure / basis pass flights: 10700 / 10649
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> Latest 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
> Basis pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
> Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#59b1ffe039ce366305d48176b7fccce29ce729d3-59b1ffe039ce366305d48176b7fccce29ce729d3 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bb36d632e4cabf47882adff07a45c6702c4a5b30-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#5b2676ac1321-6d8888519e3a
> 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 49 nodes in revision graph
> Searching for test results:
>  10697 [host=potato-beetle]
>  10708 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 db22b1aa11d3
>  10689 [host=itch-mite]
>  10698 [host=potato-beetle]
>  10715 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
>  10709 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
>  10681 [host=potato-beetle]
>  10645 [host=potato-beetle]
>  10699 [host=itch-mite]
>  10646 [host=moss-bug]
>  10649 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
>  10701 [host=itch-mite]
>  10680 [host=lace-bug]
>  10710 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 1e3fa01b0c9e
>  10702 [host=itch-mite]
>  10703 [host=itch-mite]
>  10711 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
>  10700 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
>  10704 [host=itch-mite]
>  10712 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
>  10705 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
>  10706 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
>  10713 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
>  10707 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 32dd444700bd
>  10714 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
> Searching for interesting versions
>  Result found: flight 10649 (pass), for basis pass
>  Result found: flight 10700 (fail), for basis failure
>  Repro found: flight 10705 (pass), for basis pass
>  Repro found: flight 10706 (fail), for basis failure
>  0 revisions at 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
> No revisions left to test, checking graph state.
>  Result found: flight 10709 (pass), for last pass
>  Result found: flight 10711 (fail), for first failure
>  Repro found: flight 10712 (pass), for last pass
>  Repro found: flight 10713 (fail), for first failure
>  Repro found: flight 10714 (pass), for last pass
>  Repro found: flight 10715 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  3c4c5df2cd0e
>   Bug not present: 92630d4b093e
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   24471:3c4c5df2cd0e
>   user:        Paul Durrant <paul.durrant@citrix.com>
>   date:        Fri Dec 16 14:54:14 2011 +0000
>       
>       tools: 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>
>       Committed-by: Ian Jackson <ian.jackson.citrix.com>
>       
>       
> 
> Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-xl.guest-localmigrate.{dot,ps,png,html}.
> ----------------------------------------
> 10715: ALL FAIL
> 
> flight 10715 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10715/
> 
> 
> jobs:
>  test-i386-i386-xl                                            fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmjhn-0007mL-IV; Mon, 16 Jan 2012 10:22:23 +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 1Rmjhm-0007mF-15
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:22:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326709335!11065291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1828 invoked from network); 16 Jan 2012 10:22:15 -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;
	16 Jan 2012 10:22:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10040165"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:21: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, 16 Jan 2012 10:21:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Paul Durrant <paul.durrant@citrix.com>
Date: Mon, 16 Jan 2012 10:21:41 +0000
In-Reply-To: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326709302.17210.402.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] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-01-14 at 12:05 +0000, xen.org wrote:
> branch xen-unstable
> xen branch xen-unstable
> job test-i386-i386-xl
> test guest-localmigrate
> 
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: 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:  3c4c5df2cd0e
>   Bug not present: 92630d4b093e
> 
> 
>   changeset:   24471:3c4c5df2cd0e
>   user:        Paul Durrant <paul.durrant@citrix.com>
>   date:        Fri Dec 16 14:54:14 2011 +0000
>       
>       tools: 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>
>       Committed-by: Ian Jackson <ian.jackson.citrix.com>

The logs show a guest kernel crash but I think this is a second order
effect (which I'll investigate) related to xl not recovering from a
failed migration in a way that guest kernels actually like.

The original failure seems to be a PV migration failure. Paul can you
look into that aspect please. Probably an imbalance for PV save/restore
due to something not correctly gated on HVM on one side or the other.

Thanks,
Ian.

>       
>       
> 
> 
> For bisection revision-tuple graph see:
>    http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-xl.guest-localmigrate.html
> Revision IDs in each graph node refer, respectively, to the Trees above.
> 
> ----------------------------------------
> Searching for failure / basis pass:
>  10700 fail [host=woodlouse] / 10649 ok.
> Failure / basis pass flights: 10700 / 10649
> Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> Latest 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
> Basis pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
> Generating revisions with ./adhoc-revtuple-generator  git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#59b1ffe039ce366305d48176b7fccce29ce729d3-59b1ffe039ce366305d48176b7fccce29ce729d3 git://xenbits.xen.org/staging/qemu-xen-unstable.git#bb36d632e4cabf47882adff07a45c6702c4a5b30-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#5b2676ac1321-6d8888519e3a
> 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 49 nodes in revision graph
> Searching for test results:
>  10697 [host=potato-beetle]
>  10708 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 db22b1aa11d3
>  10689 [host=itch-mite]
>  10698 [host=potato-beetle]
>  10715 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
>  10709 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
>  10681 [host=potato-beetle]
>  10645 [host=potato-beetle]
>  10699 [host=itch-mite]
>  10646 [host=moss-bug]
>  10649 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
>  10701 [host=itch-mite]
>  10680 [host=lace-bug]
>  10710 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 1e3fa01b0c9e
>  10702 [host=itch-mite]
>  10703 [host=itch-mite]
>  10711 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
>  10700 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
>  10704 [host=itch-mite]
>  10712 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
>  10705 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
>  10706 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
>  10713 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
>  10707 fail 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 32dd444700bd
>  10714 pass 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
> Searching for interesting versions
>  Result found: flight 10649 (pass), for basis pass
>  Result found: flight 10700 (fail), for basis failure
>  Repro found: flight 10705 (pass), for basis pass
>  Repro found: flight 10706 (fail), for basis failure
>  0 revisions at 59b1ffe039ce366305d48176b7fccce29ce729d3 bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
> No revisions left to test, checking graph state.
>  Result found: flight 10709 (pass), for last pass
>  Result found: flight 10711 (fail), for first failure
>  Repro found: flight 10712 (pass), for last pass
>  Repro found: flight 10713 (fail), for first failure
>  Repro found: flight 10714 (pass), for last pass
>  Repro found: flight 10715 (fail), for first failure
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  3c4c5df2cd0e
>   Bug not present: 92630d4b093e
> 
> pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> searching for changes
> no changes found
> 
>   changeset:   24471:3c4c5df2cd0e
>   user:        Paul Durrant <paul.durrant@citrix.com>
>   date:        Fri Dec 16 14:54:14 2011 +0000
>       
>       tools: 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>
>       Committed-by: Ian Jackson <ian.jackson.citrix.com>
>       
>       
> 
> Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-xl.guest-localmigrate.{dot,ps,png,html}.
> ----------------------------------------
> 10715: ALL FAIL
> 
> flight 10715 xen-unstable real-bisect [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10715/
> 
> 
> jobs:
>  test-i386-i386-xl                                            fail    
> 
> 
> ------------------------------------------------------------
> sg-report-flight on woking.cam.xci-test.com
> logs: /home/xc_osstest/logs
> images: /home/xc_osstest/images
> 
> Logs, config files, etc. are available at
>     http://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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:27:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmjmI-0007vS-FM; Mon, 16 Jan 2012 10:27:02 +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 1RmjmG-0007v9-UI
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:27:01 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326709614!7979651!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 29658 invoked from network); 16 Jan 2012 10:26:54 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-7.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Jan 2012 10:26:54 -0000
Received: from mail8-am1-R.bigfish.com (10.3.201.249) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 16 Jan 2012 10:26:50 +0000
Received: from mail8-am1 (localhost [127.0.0.1])	by mail8-am1-R.bigfish.com
	(Postfix) with ESMTP id 18A0E4C0726;
	Mon, 16 Jan 2012 10:26:51 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371Ic85dh1432N98dK4015Lzz1202hzz8275bhz2dhc1ahc1bhc1ahc1bh668h839h34h)
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 mail8-am1 (localhost.localdomain [127.0.0.1]) by mail8-am1
	(MessageSwitch) id 1326709610961453_24101;
	Mon, 16 Jan 2012 10:26:50 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.241])	by
	mail8-am1.bigfish.com (Postfix) with ESMTP id E4E8180218;
	Mon, 16 Jan 2012 10:26:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id
	14.1.225.23; Mon, 16 Jan 2012 10:26:50 +0000
X-WSS-ID: 0LXVZON-01-91I-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 2B32C1028062;	Mon, 16 Jan 2012 04:26:46 -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;
	Mon, 16 Jan 2012 04:26:54 -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;
	Mon, 16 Jan 2012 04:26:50 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Jan 2012
	05:26:48 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DBFCC49C2B0; Mon, 16 Jan 2012
	10:26:47 +0000 (GMT)
Message-ID: <4F13FC0F.1020104@amd.com>
Date: Mon, 16 Jan 2012 11:29:35 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1326215226@gran.amd.com>
	<6789e0d335e67e700f97.1326215229@gran.amd.com>
	<4F0ED3BC020000780006C120@nat28.tlf.novell.com>
In-Reply-To: <4F0ED3BC020000780006C120@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------040608060108070807090303"
X-OriginatorOrg: amd.com
Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 03 of 14 V3] 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------040608060108070807090303
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 01/12/2012 12:36 PM, Jan Beulich wrote:
>>>> On 10.01.12 at 18:07, Wei Wang<wei.wang2@amd.com>  wrote:
>> +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);
> I suppose that this isn't really correct - addr_lo shouldn't really
> need any shifting, or else base_raw would be a pretty odd entity.
> I'll convert the function to use reg_to_u64() instead. While I
> won't do this, I then also wonder whether the first two operations
> could be converted to u64_to_reg(), and if so, what the purpose
> of the whole function is (it would then merely shift the input
> value to obtain a frame number)
The names might be confusing but actually iommu mmio regs do not cache 
lower 12 bit of the base addresses, so that addr_lo only contains bit 12 
- bit 31 of the lower 32 bit part. That is why 12 bit left shift is 
needed to form a fully  64 bit address. But anyway this function seems 
redundant, I attached a patch to simplify it.
Thanks,
Wei

> Jan
>
>> +
>> +    ASSERT ( addr64 != 0 );
>> +
>> +    return addr64>>  PAGE_SHIFT;
>> +}
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


--------------040608060108070807090303
Content-Type: text/x-patch; name="1.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="1.patch"
Content-Description: 1.patch

# HG changeset patch
# Parent 0d4a60bf37b95b58bbae7019e0c263c556999131
# User Wei Wang <wei.wang2@amd.com>
cleanup get_gfn_from_base_reg() function.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 0d4a60bf37b9 -r 87ab207e4833 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Mon Jan 16 09:55:05 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Mon Jan 16 10:15:39 2012 +0100
@@ -121,16 +121,9 @@ static unsigned int host_domid(struct do
 
 static unsigned long get_gfn_from_base_reg(uint64_t base_raw)
 {
-    struct mmio_reg reg;
-    uint64_t addr64;
-
-    reg.lo = iommu_get_addr_lo_from_reg(base_raw & DMA_32BIT_MASK);
-    reg.hi = iommu_get_addr_hi_from_reg(base_raw >> 32);
-    addr64 = reg_to_u64(reg);
-
-    ASSERT ( addr64 != 0 );
-
-    return addr64 >> PAGE_SHIFT;
+    base_raw &= ~(0xFFFULL << 52);
+    ASSERT ( base_raw != 0 );
+    return base_raw >> PAGE_SHIFT;
 }
 
 static void guest_iommu_deliver_msi(struct domain *d)
diff -r 0d4a60bf37b9 -r 87ab207e4833 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Mon Jan 16 09:55:05 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Mon Jan 16 10:15:39 2012 +0100
@@ -257,16 +257,4 @@ static inline void iommu_set_addr_hi_to_
                          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_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 */

--------------040608060108070807090303
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040608060108070807090303--


From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:27:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmjmI-0007vS-FM; Mon, 16 Jan 2012 10:27:02 +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 1RmjmG-0007v9-UI
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:27:01 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326709614!7979651!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 29658 invoked from network); 16 Jan 2012 10:26:54 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-7.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Jan 2012 10:26:54 -0000
Received: from mail8-am1-R.bigfish.com (10.3.201.249) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Mon, 16 Jan 2012 10:26:50 +0000
Received: from mail8-am1 (localhost [127.0.0.1])	by mail8-am1-R.bigfish.com
	(Postfix) with ESMTP id 18A0E4C0726;
	Mon, 16 Jan 2012 10:26:51 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371Ic85dh1432N98dK4015Lzz1202hzz8275bhz2dhc1ahc1bhc1ahc1bh668h839h34h)
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 mail8-am1 (localhost.localdomain [127.0.0.1]) by mail8-am1
	(MessageSwitch) id 1326709610961453_24101;
	Mon, 16 Jan 2012 10:26:50 +0000 (UTC)
Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.241])	by
	mail8-am1.bigfish.com (Postfix) with ESMTP id E4E8180218;
	Mon, 16 Jan 2012 10:26:50 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server id
	14.1.225.23; Mon, 16 Jan 2012 10:26:50 +0000
X-WSS-ID: 0LXVZON-01-91I-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 2B32C1028062;	Mon, 16 Jan 2012 04:26:46 -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;
	Mon, 16 Jan 2012 04:26:54 -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;
	Mon, 16 Jan 2012 04:26:50 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Jan 2012
	05:26:48 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DBFCC49C2B0; Mon, 16 Jan 2012
	10:26:47 +0000 (GMT)
Message-ID: <4F13FC0F.1020104@amd.com>
Date: Mon, 16 Jan 2012 11:29:35 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1326215226@gran.amd.com>
	<6789e0d335e67e700f97.1326215229@gran.amd.com>
	<4F0ED3BC020000780006C120@nat28.tlf.novell.com>
In-Reply-To: <4F0ED3BC020000780006C120@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="------------040608060108070807090303"
X-OriginatorOrg: amd.com
Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xensource.com, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 03 of 14 V3] 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------040608060108070807090303
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 01/12/2012 12:36 PM, Jan Beulich wrote:
>>>> On 10.01.12 at 18:07, Wei Wang<wei.wang2@amd.com>  wrote:
>> +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);
> I suppose that this isn't really correct - addr_lo shouldn't really
> need any shifting, or else base_raw would be a pretty odd entity.
> I'll convert the function to use reg_to_u64() instead. While I
> won't do this, I then also wonder whether the first two operations
> could be converted to u64_to_reg(), and if so, what the purpose
> of the whole function is (it would then merely shift the input
> value to obtain a frame number)
The names might be confusing but actually iommu mmio regs do not cache 
lower 12 bit of the base addresses, so that addr_lo only contains bit 12 
- bit 31 of the lower 32 bit part. That is why 12 bit left shift is 
needed to form a fully  64 bit address. But anyway this function seems 
redundant, I attached a patch to simplify it.
Thanks,
Wei

> Jan
>
>> +
>> +    ASSERT ( addr64 != 0 );
>> +
>> +    return addr64>>  PAGE_SHIFT;
>> +}
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


--------------040608060108070807090303
Content-Type: text/x-patch; name="1.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="1.patch"
Content-Description: 1.patch

# HG changeset patch
# Parent 0d4a60bf37b95b58bbae7019e0c263c556999131
# User Wei Wang <wei.wang2@amd.com>
cleanup get_gfn_from_base_reg() function.

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 0d4a60bf37b9 -r 87ab207e4833 xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Mon Jan 16 09:55:05 2012 +0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Mon Jan 16 10:15:39 2012 +0100
@@ -121,16 +121,9 @@ static unsigned int host_domid(struct do
 
 static unsigned long get_gfn_from_base_reg(uint64_t base_raw)
 {
-    struct mmio_reg reg;
-    uint64_t addr64;
-
-    reg.lo = iommu_get_addr_lo_from_reg(base_raw & DMA_32BIT_MASK);
-    reg.hi = iommu_get_addr_hi_from_reg(base_raw >> 32);
-    addr64 = reg_to_u64(reg);
-
-    ASSERT ( addr64 != 0 );
-
-    return addr64 >> PAGE_SHIFT;
+    base_raw &= ~(0xFFFULL << 52);
+    ASSERT ( base_raw != 0 );
+    return base_raw >> PAGE_SHIFT;
 }
 
 static void guest_iommu_deliver_msi(struct domain *d)
diff -r 0d4a60bf37b9 -r 87ab207e4833 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Mon Jan 16 09:55:05 2012 +0100
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h	Mon Jan 16 10:15:39 2012 +0100
@@ -257,16 +257,4 @@ static inline void iommu_set_addr_hi_to_
                          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_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 */

--------------040608060108070807090303
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040608060108070807090303--


From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:32:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmjrU-00085q-KP; Mon, 16 Jan 2012 10:32:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmjrT-00085l-3j
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:32:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326709936!10585106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31384 invoked from network); 16 Jan 2012 10:32:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 10:32:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10040855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:31: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;
	Mon, 16 Jan 2012 10:31:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Mon, 16 Jan 2012 10:31:55 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC49@LONPMAILBOX01.citrite.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC49@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326709915.17210.410.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 10:14 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Wei Liu
> > Sent: 13 January 2012 16:59
> > To: Ian Campbell; konrad.wilk@oracle.com; xen-
> > devel@lists.xensource.com; netdev@vger.kernel.org
> > Cc: Wei Liu (Intern)
> > Subject: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
> > model
> > 
> > This patch implements 1:1 model netback. We utilizes NAPI and kthread to
> > do the weight-lifting job:
> > 
> >   - NAPI is used for guest side TX (host side RX)
> >   - kthread is used for guest side RX (host side TX)
> > 
> > This model provides better scheduling fairness among vifs. It also lays the
> > foundation for future work.
> > 
> > The major defect for the current implementation is that in the NAPI poll
> > handler we don't actually disable interrupt. Xen stuff is different from real
> > hardware, it requires some other tuning of ring macros.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> [snip]
> > 
> >  	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
> >  	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS]; @@ -100,42
> > +91,14 @@ struct xen_netbk {
> >  	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];  };
> > 
> 
> Keeping these big inline arrays might cause scalability issues.
> pending_tx_info should arguably me more closely tied in and possibly
> implemented within your page pool code.

For pending_tx_info that probably makes sense since there is a 1:1
mapping between page pool entries and pending_tx_info.

For some of the others the arrays are the runtime scratch space used by
the netback during each processing pass. Since, regardless of the number
of VIFs, there can only ever be nr_online_cpus netback's active at once
perhaps per-CPU scratch space (with appropriate locking etc) is the way
to go.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:32:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:32:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmjrU-00085q-KP; Mon, 16 Jan 2012 10:32:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmjrT-00085l-3j
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:32:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326709936!10585106!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31384 invoked from network); 16 Jan 2012 10:32:16 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 10:32:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10040855"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:31: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;
	Mon, 16 Jan 2012 10:31:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Mon, 16 Jan 2012 10:31:55 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC49@LONPMAILBOX01.citrite.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC49@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326709915.17210.410.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 10:14 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Wei Liu
> > Sent: 13 January 2012 16:59
> > To: Ian Campbell; konrad.wilk@oracle.com; xen-
> > devel@lists.xensource.com; netdev@vger.kernel.org
> > Cc: Wei Liu (Intern)
> > Subject: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
> > model
> > 
> > This patch implements 1:1 model netback. We utilizes NAPI and kthread to
> > do the weight-lifting job:
> > 
> >   - NAPI is used for guest side TX (host side RX)
> >   - kthread is used for guest side RX (host side TX)
> > 
> > This model provides better scheduling fairness among vifs. It also lays the
> > foundation for future work.
> > 
> > The major defect for the current implementation is that in the NAPI poll
> > handler we don't actually disable interrupt. Xen stuff is different from real
> > hardware, it requires some other tuning of ring macros.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> [snip]
> > 
> >  	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
> >  	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS]; @@ -100,42
> > +91,14 @@ struct xen_netbk {
> >  	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];  };
> > 
> 
> Keeping these big inline arrays might cause scalability issues.
> pending_tx_info should arguably me more closely tied in and possibly
> implemented within your page pool code.

For pending_tx_info that probably makes sense since there is a 1:1
mapping between page pool entries and pending_tx_info.

For some of the others the arrays are the runtime scratch space used by
the netback during each processing pass. Since, regardless of the number
of VIFs, there can only ever be nr_online_cpus netback's active at once
perhaps per-CPU scratch space (with appropriate locking etc) is the way
to go.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:33:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmjrq-00087C-1L; Mon, 16 Jan 2012 10:32:46 +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 1Rmjro-00086j-2U
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:32:44 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326709957!9306877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17160 invoked from network); 16 Jan 2012 10:32:37 -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;
	16 Jan 2012 10:32:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10040879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:32:36 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 16 Jan 2012
	10:32:36 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 10:32:34 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUOKRvTa89B0YmSDWOSN+G0Kcf5wAAWnug
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326709302.17210.402.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 16 January 2012 10:22
> To: Ian Jackson; Paul Durrant
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Stefano Stabellini
> Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> On Sat, 2012-01-14 at 12:05 +0000, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-i386-i386-xl
> > test guest-localmigrate
> >
> > Tree: linux
> > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: 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:  3c4c5df2cd0e
> >   Bug not present: 92630d4b093e
> >
> >
> >   changeset:   24471:3c4c5df2cd0e
> >   user:        Paul Durrant <paul.durrant@citrix.com>
> >   date:        Fri Dec 16 14:54:14 2011 +0000
> >
> >       tools: 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>
> >       Committed-by: Ian Jackson <ian.jackson.citrix.com>
> 
> The logs show a guest kernel crash but I think this is a second order effect
> (which I'll investigate) related to xl not recovering from a failed migration in
> a way that guest kernels actually like.
> 
> The original failure seems to be a PV migration failure. Paul can you look
> into that aspect please. Probably an imbalance for PV save/restore due to
> something not correctly gated on HVM on one side or the other.
> 

Yep, I'll check now.

  Paul

> Thanks,
> Ian.
> 
> >
> >
> >
> >
> > For bisection revision-tuple graph see:
> >
> > http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstabl
> > e.test-i386-i386-xl.guest-localmigrate.html
> > Revision IDs in each graph node refer, respectively, to the Trees above.
> >
> > ----------------------------------------
> > Searching for failure / basis pass:
> >  10700 fail [host=woodlouse] / 10649 ok.
> > Failure / basis pass flights: 10700 / 10649
> > Tree: linux
> > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> > Latest 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a Basis pass
> > 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321 Generating
> > revisions with ./adhoc-revtuple-generator
> > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#59b1ffe03
> > 9ce366305d48176b7fccce29ce729d3-
> 59b1ffe039ce366305d48176b7fccce29ce729
> > d3
> > git://xenbits.xen.org/staging/qemu-xen-
> unstable.git#bb36d632e4cabf4788
> > 2adff07a45c6702c4a5b30-bb36d632e4cabf47882adff07a45c6702c4a5b30
> > http://xenbits.xen.org/staging/xen-unstable.hg#5b2676ac1321-
> 6d8888519e
> > 3a 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 49 nodes in revision graph
> > Searching for test results:
> >  10697 [host=potato-beetle]
> >  10708 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 db22b1aa11d3
> >  10689 [host=itch-mite]
> >  10698 [host=potato-beetle]
> >  10715 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
> >  10709 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
> >  10681 [host=potato-beetle]
> >  10645 [host=potato-beetle]
> >  10699 [host=itch-mite]
> >  10646 [host=moss-bug]
> >  10649 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
> >  10701 [host=itch-mite]
> >  10680 [host=lace-bug]
> >  10710 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 1e3fa01b0c9e
> >  10702 [host=itch-mite]
> >  10703 [host=itch-mite]
> >  10711 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
> >  10700 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
> >  10704 [host=itch-mite]
> >  10712 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
> >  10705 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
> >  10706 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
> >  10713 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
> >  10707 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 32dd444700bd
> >  10714 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e Searching for
> > interesting versions  Result found: flight 10649 (pass), for basis
> > pass  Result found: flight 10700 (fail), for basis failure  Repro
> > found: flight 10705 (pass), for basis pass  Repro found: flight 10706
> > (fail), for basis failure
> >  0 revisions at 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e No revisions
> left to test, checking graph state.
> >  Result found: flight 10709 (pass), for last pass  Result found:
> > flight 10711 (fail), for first failure  Repro found: flight 10712
> > (pass), for last pass  Repro found: flight 10713 (fail), for first
> > failure  Repro found: flight 10714 (pass), for last pass  Repro found:
> > flight 10715 (fail), for first failure
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> >   Bug introduced:  3c4c5df2cd0e
> >   Bug not present: 92630d4b093e
> >
> > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> > searching for changes
> > no changes found
> >
> >   changeset:   24471:3c4c5df2cd0e
> >   user:        Paul Durrant <paul.durrant@citrix.com>
> >   date:        Fri Dec 16 14:54:14 2011 +0000
> >
> >       tools: 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>
> >       Committed-by: Ian Jackson <ian.jackson.citrix.com>
> >
> >
> >
> > Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-
> i386-i386-xl.guest-localmigrate.{dot,ps,png,html}.
> > ----------------------------------------
> > 10715: ALL FAIL
> >
> > flight 10715 xen-unstable real-bisect [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10715/
> >
> >
> > jobs:
> >  test-i386-i386-xl                                            fail
> >
> >
> > ------------------------------------------------------------
> > sg-report-flight on woking.cam.xci-test.com
> > logs: /home/xc_osstest/logs
> > images: /home/xc_osstest/images
> >
> > Logs, config files, etc. are available at
> >     http://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
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:33:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmjrq-00087C-1L; Mon, 16 Jan 2012 10:32:46 +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 1Rmjro-00086j-2U
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:32:44 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326709957!9306877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17160 invoked from network); 16 Jan 2012 10:32:37 -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;
	16 Jan 2012 10:32:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10040879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:32:36 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Mon, 16 Jan 2012
	10:32:36 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 10:32:34 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUOKRvTa89B0YmSDWOSN+G0Kcf5wAAWnug
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326709302.17210.402.camel@zakaz.uk.xensource.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Campbell
> Sent: 16 January 2012 10:22
> To: Ian Jackson; Paul Durrant
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Stefano Stabellini
> Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> On Sat, 2012-01-14 at 12:05 +0000, xen.org wrote:
> > branch xen-unstable
> > xen branch xen-unstable
> > job test-i386-i386-xl
> > test guest-localmigrate
> >
> > Tree: linux
> > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: 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:  3c4c5df2cd0e
> >   Bug not present: 92630d4b093e
> >
> >
> >   changeset:   24471:3c4c5df2cd0e
> >   user:        Paul Durrant <paul.durrant@citrix.com>
> >   date:        Fri Dec 16 14:54:14 2011 +0000
> >
> >       tools: 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>
> >       Committed-by: Ian Jackson <ian.jackson.citrix.com>
> 
> The logs show a guest kernel crash but I think this is a second order effect
> (which I'll investigate) related to xl not recovering from a failed migration in
> a way that guest kernels actually like.
> 
> The original failure seems to be a PV migration failure. Paul can you look
> into that aspect please. Probably an imbalance for PV save/restore due to
> something not correctly gated on HVM on one side or the other.
> 

Yep, I'll check now.

  Paul

> Thanks,
> Ian.
> 
> >
> >
> >
> >
> > For bisection revision-tuple graph see:
> >
> > http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstabl
> > e.test-i386-i386-xl.guest-localmigrate.html
> > Revision IDs in each graph node refer, respectively, to the Trees above.
> >
> > ----------------------------------------
> > Searching for failure / basis pass:
> >  10700 fail [host=woodlouse] / 10649 ok.
> > Failure / basis pass flights: 10700 / 10649
> > Tree: linux
> > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
> > Latest 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a Basis pass
> > 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321 Generating
> > revisions with ./adhoc-revtuple-generator
> > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git#59b1ffe03
> > 9ce366305d48176b7fccce29ce729d3-
> 59b1ffe039ce366305d48176b7fccce29ce729
> > d3
> > git://xenbits.xen.org/staging/qemu-xen-
> unstable.git#bb36d632e4cabf4788
> > 2adff07a45c6702c4a5b30-bb36d632e4cabf47882adff07a45c6702c4a5b30
> > http://xenbits.xen.org/staging/xen-unstable.hg#5b2676ac1321-
> 6d8888519e
> > 3a 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 49 nodes in revision graph
> > Searching for test results:
> >  10697 [host=potato-beetle]
> >  10708 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 db22b1aa11d3
> >  10689 [host=itch-mite]
> >  10698 [host=potato-beetle]
> >  10715 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
> >  10709 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
> >  10681 [host=potato-beetle]
> >  10645 [host=potato-beetle]
> >  10699 [host=itch-mite]
> >  10646 [host=moss-bug]
> >  10649 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
> >  10701 [host=itch-mite]
> >  10680 [host=lace-bug]
> >  10710 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 1e3fa01b0c9e
> >  10702 [host=itch-mite]
> >  10703 [host=itch-mite]
> >  10711 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
> >  10700 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
> >  10704 [host=itch-mite]
> >  10712 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e
> >  10705 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 5b2676ac1321
> >  10706 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 6d8888519e3a
> >  10713 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 3c4c5df2cd0e
> >  10707 fail 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 32dd444700bd
> >  10714 pass 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e Searching for
> > interesting versions  Result found: flight 10649 (pass), for basis
> > pass  Result found: flight 10700 (fail), for basis failure  Repro
> > found: flight 10705 (pass), for basis pass  Repro found: flight 10706
> > (fail), for basis failure
> >  0 revisions at 59b1ffe039ce366305d48176b7fccce29ce729d3
> > bb36d632e4cabf47882adff07a45c6702c4a5b30 92630d4b093e No revisions
> left to test, checking graph state.
> >  Result found: flight 10709 (pass), for last pass  Result found:
> > flight 10711 (fail), for first failure  Repro found: flight 10712
> > (pass), for last pass  Repro found: flight 10713 (fail), for first
> > failure  Repro found: flight 10714 (pass), for last pass  Repro found:
> > flight 10715 (fail), for first failure
> >
> > *** Found and reproduced problem changeset ***
> >
> >   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
> >   Bug introduced:  3c4c5df2cd0e
> >   Bug not present: 92630d4b093e
> >
> > pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
> > searching for changes
> > no changes found
> >
> >   changeset:   24471:3c4c5df2cd0e
> >   user:        Paul Durrant <paul.durrant@citrix.com>
> >   date:        Fri Dec 16 14:54:14 2011 +0000
> >
> >       tools: 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>
> >       Committed-by: Ian Jackson <ian.jackson.citrix.com>
> >
> >
> >
> > Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-
> i386-i386-xl.guest-localmigrate.{dot,ps,png,html}.
> > ----------------------------------------
> > 10715: ALL FAIL
> >
> > flight 10715 xen-unstable real-bisect [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10715/
> >
> >
> > jobs:
> >  test-i386-i386-xl                                            fail
> >
> >
> > ------------------------------------------------------------
> > sg-report-flight on woking.cam.xci-test.com
> > logs: /home/xc_osstest/logs
> > images: /home/xc_osstest/images
> >
> > Logs, config files, etc. are available at
> >     http://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
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:44:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 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 1Rmk3J-0008SO-Vw; Mon, 16 Jan 2012 10:44: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 1Rmk3I-0008SJ-Bs
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:44:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326710654!62593151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21472 invoked from network); 16 Jan 2012 10:44:15 -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;
	16 Jan 2012 10:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10041441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:44:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 10:44:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rmk3G-0002RG-H6;
	Mon, 16 Jan 2012 10:44:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rmk3G-0003jT-BI;
	Mon, 16 Jan 2012 10:44:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10763-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 10:44:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10763: 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 10763 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10763/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  ffe158446c79
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 766 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 Jan 16 10:44:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 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 1Rmk3J-0008SO-Vw; Mon, 16 Jan 2012 10:44: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 1Rmk3I-0008SJ-Bs
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:44:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326710654!62593151!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21472 invoked from network); 16 Jan 2012 10:44:15 -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;
	16 Jan 2012 10:44:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10041441"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:44:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 10:44:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rmk3G-0002RG-H6;
	Mon, 16 Jan 2012 10:44:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rmk3G-0003jT-BI;
	Mon, 16 Jan 2012 10:44:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10763-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 10:44:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10763: 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 10763 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10763/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           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-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  ffe158446c79
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          fail    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            fail    
 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 766 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 Jan 16 10:45:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:45:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmk3z-0008UK-DM; Mon, 16 Jan 2012 10:45:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmk3y-0008Tv-Pe
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:45:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326710712!9240593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13817 invoked from network); 16 Jan 2012 10:45:12 -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;
	16 Jan 2012 10:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10041504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:45: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, 16 Jan 2012 10:45:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>
Date: Mon, 16 Jan 2012 10:45:11 +0000
In-Reply-To: <1326706394.5285.5.camel@liuw-desktop>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com> <1326706394.5285.5.camel@liuw-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326710711.17210.411.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>,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 09:33 +0000, Wei Liu (Intern) wrote:
> On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> > On 13/01/12 16:59, Wei Liu wrote:
> > > This patch implements 1:1 model netback. We utilizes NAPI and kthread
> > > to do the weight-lifting job:
> > > 
> > >   - NAPI is used for guest side TX (host side RX)
> > >   - kthread is used for guest side RX (host side TX)
> > > 
> > > This model provides better scheduling fairness among vifs. It also
> > > lays the foundation for future work.
> > > 
> > > The major defect for the current implementation is that in the NAPI
> > > poll handler we don't actually disable interrupt. Xen stuff is
> > > different from real hardware, it requires some other tuning of ring
> > > macros.
> > 
> > RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to me.
> > 
> > David
> 
> I need to stop the other end from generating events, so
> RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.

What you need is a variant which sets req_event some large distance into
the future instead of to just req_cons + 1. Or possibly it should be set
to just in the past (e.g. req_cons - 1). Call it something like
RING_POLL_FOR_REQUESTS().

Ian.

> 
> 
> Wei.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:45:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:45:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmk3z-0008UK-DM; Mon, 16 Jan 2012 10:45:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmk3y-0008Tv-Pe
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:45:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326710712!9240593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13817 invoked from network); 16 Jan 2012 10:45:12 -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;
	16 Jan 2012 10:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10041504"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:45: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, 16 Jan 2012 10:45:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>
Date: Mon, 16 Jan 2012 10:45:11 +0000
In-Reply-To: <1326706394.5285.5.camel@liuw-desktop>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com> <1326706394.5285.5.camel@liuw-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326710711.17210.411.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>,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 09:33 +0000, Wei Liu (Intern) wrote:
> On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> > On 13/01/12 16:59, Wei Liu wrote:
> > > This patch implements 1:1 model netback. We utilizes NAPI and kthread
> > > to do the weight-lifting job:
> > > 
> > >   - NAPI is used for guest side TX (host side RX)
> > >   - kthread is used for guest side RX (host side TX)
> > > 
> > > This model provides better scheduling fairness among vifs. It also
> > > lays the foundation for future work.
> > > 
> > > The major defect for the current implementation is that in the NAPI
> > > poll handler we don't actually disable interrupt. Xen stuff is
> > > different from real hardware, it requires some other tuning of ring
> > > macros.
> > 
> > RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to me.
> > 
> > David
> 
> I need to stop the other end from generating events, so
> RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.

What you need is a variant which sets req_event some large distance into
the future instead of to just req_cons + 1. Or possibly it should be set
to just in the past (e.g. req_cons - 1). Call it something like
RING_POLL_FOR_REQUESTS().

Ian.

> 
> 
> Wei.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:50:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:50:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmk93-0000In-6Z; Mon, 16 Jan 2012 10:50:33 +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 1Rmk92-0000Ib-3s
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:50:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326711025!9297373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27013 invoked from network); 16 Jan 2012 10:50:25 -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;
	16 Jan 2012 10:50:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10041629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:50:25 +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;
	Mon, 16 Jan 2012 10:50:24 +0000
Message-ID: <1326710978.5285.9.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 16 Jan 2012 10:49:38 +0000
In-Reply-To: <1326710711.17210.411.camel@zakaz.uk.xensource.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com> <1326706394.5285.5.camel@liuw-desktop>
	<1326710711.17210.411.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 10:45 +0000, Ian Campbell wrote:
> On Mon, 2012-01-16 at 09:33 +0000, Wei Liu (Intern) wrote:
> > On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> > > On 13/01/12 16:59, Wei Liu wrote:
> > > > This patch implements 1:1 model netback. We utilizes NAPI and kthread
> > > > to do the weight-lifting job:
> > > > 
> > > >   - NAPI is used for guest side TX (host side RX)
> > > >   - kthread is used for guest side RX (host side TX)
> > > > 
> > > > This model provides better scheduling fairness among vifs. It also
> > > > lays the foundation for future work.
> > > > 
> > > > The major defect for the current implementation is that in the NAPI
> > > > poll handler we don't actually disable interrupt. Xen stuff is
> > > > different from real hardware, it requires some other tuning of ring
> > > > macros.
> > > 
> > > RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to me.
> > > 
> > > David
> > 
> > I need to stop the other end from generating events, so
> > RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.
> 
> What you need is a variant which sets req_event some large distance into
> the future instead of to just req_cons + 1. Or possibly it should be set
> to just in the past (e.g. req_cons - 1). Call it something like
> RING_POLL_FOR_REQUESTS().
> 

Seems like a right direction. Will try this.


Wei.

> Ian.
> 
> > 
> > 
> > Wei.
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:50:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:50:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmk93-0000In-6Z; Mon, 16 Jan 2012 10:50:33 +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 1Rmk92-0000Ib-3s
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:50:32 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326711025!9297373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27013 invoked from network); 16 Jan 2012 10:50:25 -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;
	16 Jan 2012 10:50:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10041629"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:50:25 +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;
	Mon, 16 Jan 2012 10:50:24 +0000
Message-ID: <1326710978.5285.9.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 16 Jan 2012 10:49:38 +0000
In-Reply-To: <1326710711.17210.411.camel@zakaz.uk.xensource.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com> <1326706394.5285.5.camel@liuw-desktop>
	<1326710711.17210.411.camel@zakaz.uk.xensource.com>
X-Mailer: Evolution 3.2.1- 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 10:45 +0000, Ian Campbell wrote:
> On Mon, 2012-01-16 at 09:33 +0000, Wei Liu (Intern) wrote:
> > On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> > > On 13/01/12 16:59, Wei Liu wrote:
> > > > This patch implements 1:1 model netback. We utilizes NAPI and kthread
> > > > to do the weight-lifting job:
> > > > 
> > > >   - NAPI is used for guest side TX (host side RX)
> > > >   - kthread is used for guest side RX (host side TX)
> > > > 
> > > > This model provides better scheduling fairness among vifs. It also
> > > > lays the foundation for future work.
> > > > 
> > > > The major defect for the current implementation is that in the NAPI
> > > > poll handler we don't actually disable interrupt. Xen stuff is
> > > > different from real hardware, it requires some other tuning of ring
> > > > macros.
> > > 
> > > RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to me.
> > > 
> > > David
> > 
> > I need to stop the other end from generating events, so
> > RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.
> 
> What you need is a variant which sets req_event some large distance into
> the future instead of to just req_cons + 1. Or possibly it should be set
> to just in the past (e.g. req_cons - 1). Call it something like
> RING_POLL_FOR_REQUESTS().
> 

Seems like a right direction. Will try this.


Wei.

> Ian.
> 
> > 
> > 
> > Wei.
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:57:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmkFi-0000Wu-2K; Mon, 16 Jan 2012 10:57:26 +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 1RmkFg-0000Wo-OL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:57:24 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326711386!57053451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7608 invoked from network); 16 Jan 2012 10:56:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 10:56:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10041962"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:56:54 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 16 Jan 2012
	10:56:54 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "Wei Liu (Intern)"
	<wei.liu2@citrix.com>
Date: Mon, 16 Jan 2012 10:56:53 +0000
Thread-Topic: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
	model
Thread-Index: AczUPB46FjUYDvsdRdOayBRaF0NPvAAAS7gQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC4D@LONPMAILBOX01.citrite.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com> <1326706394.5285.5.camel@liuw-desktop>
	<1326710711.17210.411.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326710711.17210.411.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: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Ian Campbell
> Sent: 16 January 2012 10:45
> To: Wei Liu (Intern)
> Cc: netdev@vger.kernel.org; xen-devel@lists.xensource.com; David Vrabel;
> konrad.wilk@oracle.com
> Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
> model
> 
> On Mon, 2012-01-16 at 09:33 +0000, Wei Liu (Intern) wrote:
> > On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> > > On 13/01/12 16:59, Wei Liu wrote:
> > > > This patch implements 1:1 model netback. We utilizes NAPI and
> > > > kthread to do the weight-lifting job:
> > > >
> > > >   - NAPI is used for guest side TX (host side RX)
> > > >   - kthread is used for guest side RX (host side TX)
> > > >
> > > > This model provides better scheduling fairness among vifs. It also
> > > > lays the foundation for future work.
> > > >
> > > > The major defect for the current implementation is that in the
> > > > NAPI poll handler we don't actually disable interrupt. Xen stuff
> > > > is different from real hardware, it requires some other tuning of
> > > > ring macros.
> > >
> > > RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to
> me.
> > >
> > > David
> >
> > I need to stop the other end from generating events, so
> > RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.
> 
> What you need is a variant which sets req_event some large distance into
> the future instead of to just req_cons + 1. Or possibly it should be set to just
> in the past (e.g. req_cons - 1). Call it something like
> RING_POLL_FOR_REQUESTS().
> 

Can you just simply avoid calling RING_FINAL_CHECK_FOR_REQUESTS() unless you actually want to re-enable 'interrupts'? All it does is manipulate the event pointer and tell you whether there are still unconsumed requests.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:57:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10:57:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmkFi-0000Wu-2K; Mon, 16 Jan 2012 10:57:26 +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 1RmkFg-0000Wo-OL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:57:24 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326711386!57053451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7608 invoked from network); 16 Jan 2012 10:56:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 10:56:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10041962"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:56:54 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 16 Jan 2012
	10:56:54 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, "Wei Liu (Intern)"
	<wei.liu2@citrix.com>
Date: Mon, 16 Jan 2012 10:56:53 +0000
Thread-Topic: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
	model
Thread-Index: AczUPB46FjUYDvsdRdOayBRaF0NPvAAAS7gQ
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC4D@LONPMAILBOX01.citrite.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com> <1326706394.5285.5.camel@liuw-desktop>
	<1326710711.17210.411.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326710711.17210.411.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: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Ian Campbell
> Sent: 16 January 2012 10:45
> To: Wei Liu (Intern)
> Cc: netdev@vger.kernel.org; xen-devel@lists.xensource.com; David Vrabel;
> konrad.wilk@oracle.com
> Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
> model
> 
> On Mon, 2012-01-16 at 09:33 +0000, Wei Liu (Intern) wrote:
> > On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> > > On 13/01/12 16:59, Wei Liu wrote:
> > > > This patch implements 1:1 model netback. We utilizes NAPI and
> > > > kthread to do the weight-lifting job:
> > > >
> > > >   - NAPI is used for guest side TX (host side RX)
> > > >   - kthread is used for guest side RX (host side TX)
> > > >
> > > > This model provides better scheduling fairness among vifs. It also
> > > > lays the foundation for future work.
> > > >
> > > > The major defect for the current implementation is that in the
> > > > NAPI poll handler we don't actually disable interrupt. Xen stuff
> > > > is different from real hardware, it requires some other tuning of
> > > > ring macros.
> > >
> > > RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to
> me.
> > >
> > > David
> >
> > I need to stop the other end from generating events, so
> > RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.
> 
> What you need is a variant which sets req_event some large distance into
> the future instead of to just req_cons + 1. Or possibly it should be set to just
> in the past (e.g. req_cons - 1). Call it something like
> RING_POLL_FOR_REQUESTS().
> 

Can you just simply avoid calling RING_FINAL_CHECK_FOR_REQUESTS() unless you actually want to re-enable 'interrupts'? All it does is manipulate the event pointer and tell you whether there are still unconsumed requests.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:59:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10: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 1RmkHX-0000bW-JA; Mon, 16 Jan 2012 10:59:19 +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 1RmkHV-0000b7-MK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:59:17 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326711551!9304602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14473 invoked from network); 16 Jan 2012 10:59: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;
	16 Jan 2012 10:59:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10042265"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:59:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 16 Jan 2012
	10:59:10 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 10:59:10 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUOKRvTa89B0YmSDWOSN+G0Kcf5wAAWnugAADmVsA=
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
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-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Paul Durrant
> Sent: 16 January 2012 10:33
> To: Ian Campbell; Ian Jackson
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Stefano Stabellini
> Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 16 January 2012 10:22
> > To: Ian Jackson; Paul Durrant
> > Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Stefano Stabellini
> > Subject: Re: [Xen-devel] [xen-unstable bisection] complete
> > test-i386-i386-xl
> >
> > On Sat, 2012-01-14 at 12:05 +0000, xen.org wrote:
> > > branch xen-unstable
> > > xen branch xen-unstable
> > > job test-i386-i386-xl
> > > test guest-localmigrate
> > >
> > > Tree: linux
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > > Tree: 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:  3c4c5df2cd0e
> > >   Bug not present: 92630d4b093e
> > >
> > >
> > >   changeset:   24471:3c4c5df2cd0e
> > >   user:        Paul Durrant <paul.durrant@citrix.com>
> > >   date:        Fri Dec 16 14:54:14 2011 +0000
> > >
> > >       tools: 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>
> > >       Committed-by: Ian Jackson <ian.jackson.citrix.com>
> >
> > The logs show a guest kernel crash but I think this is a second order
> > effect (which I'll investigate) related to xl not recovering from a
> > failed migration in a way that guest kernels actually like.
> >
> > The original failure seems to be a PV migration failure. Paul can you
> > look into that aspect please. Probably an imbalance for PV
> > save/restore due to something not correctly gated on HVM on one side or
> the other.
> >
> 
> Yep, I'll check now.
> 

It all seems to be gated correctly on the whether the VM is HVM and/or the existence of the appropriate save record.

   Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 10:59:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 10: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 1RmkHX-0000bW-JA; Mon, 16 Jan 2012 10:59:19 +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 1RmkHV-0000b7-MK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:59:17 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326711551!9304602!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14473 invoked from network); 16 Jan 2012 10:59: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;
	16 Jan 2012 10:59:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10042265"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:59:10 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 16 Jan 2012
	10:59:10 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 10:59:10 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUOKRvTa89B0YmSDWOSN+G0Kcf5wAAWnugAADmVsA=
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
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-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Paul Durrant
> Sent: 16 January 2012 10:33
> To: Ian Campbell; Ian Jackson
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Stefano Stabellini
> Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 16 January 2012 10:22
> > To: Ian Jackson; Paul Durrant
> > Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Stefano Stabellini
> > Subject: Re: [Xen-devel] [xen-unstable bisection] complete
> > test-i386-i386-xl
> >
> > On Sat, 2012-01-14 at 12:05 +0000, xen.org wrote:
> > > branch xen-unstable
> > > xen branch xen-unstable
> > > job test-i386-i386-xl
> > > test guest-localmigrate
> > >
> > > Tree: linux
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > > Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
> > > Tree: 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:  3c4c5df2cd0e
> > >   Bug not present: 92630d4b093e
> > >
> > >
> > >   changeset:   24471:3c4c5df2cd0e
> > >   user:        Paul Durrant <paul.durrant@citrix.com>
> > >   date:        Fri Dec 16 14:54:14 2011 +0000
> > >
> > >       tools: 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>
> > >       Committed-by: Ian Jackson <ian.jackson.citrix.com>
> >
> > The logs show a guest kernel crash but I think this is a second order
> > effect (which I'll investigate) related to xl not recovering from a
> > failed migration in a way that guest kernels actually like.
> >
> > The original failure seems to be a PV migration failure. Paul can you
> > look into that aspect please. Probably an imbalance for PV
> > save/restore due to something not correctly gated on HVM on one side or
> the other.
> >
> 
> Yep, I'll check now.
> 

It all seems to be gated correctly on the whether the VM is HVM and/or the existence of the appropriate save record.

   Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:10:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmkRY-0000sX-Sn; Mon, 16 Jan 2012 11:09: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 1RmkRX-0000sS-LB
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 11:09:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326712173!11076705!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2559 invoked from network); 16 Jan 2012 11:09: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;
	16 Jan 2012 11:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10042665"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:09: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, 16 Jan 2012 11:09:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Mon, 16 Jan 2012 11:09:33 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC4D@LONPMAILBOX01.citrite.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com> <1326706394.5285.5.camel@liuw-desktop>
	<1326710711.17210.411.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4D@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326712173.17210.412.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 10:56 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Ian Campbell
> > Sent: 16 January 2012 10:45
> > To: Wei Liu (Intern)
> > Cc: netdev@vger.kernel.org; xen-devel@lists.xensource.com; David Vrabel;
> > konrad.wilk@oracle.com
> > Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
> > model
> > 
> > On Mon, 2012-01-16 at 09:33 +0000, Wei Liu (Intern) wrote:
> > > On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> > > > On 13/01/12 16:59, Wei Liu wrote:
> > > > > This patch implements 1:1 model netback. We utilizes NAPI and
> > > > > kthread to do the weight-lifting job:
> > > > >
> > > > >   - NAPI is used for guest side TX (host side RX)
> > > > >   - kthread is used for guest side RX (host side TX)
> > > > >
> > > > > This model provides better scheduling fairness among vifs. It also
> > > > > lays the foundation for future work.
> > > > >
> > > > > The major defect for the current implementation is that in the
> > > > > NAPI poll handler we don't actually disable interrupt. Xen stuff
> > > > > is different from real hardware, it requires some other tuning of
> > > > > ring macros.
> > > >
> > > > RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to
> > me.
> > > >
> > > > David
> > >
> > > I need to stop the other end from generating events, so
> > > RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.
> > 
> > What you need is a variant which sets req_event some large distance into
> > the future instead of to just req_cons + 1. Or possibly it should be set to just
> > in the past (e.g. req_cons - 1). Call it something like
> > RING_POLL_FOR_REQUESTS().
> > 
> 
> Can you just simply avoid calling RING_FINAL_CHECK_FOR_REQUESTS()
> unless you actually want to re-enable 'interrupts'? All it does is
> manipulate the event pointer and tell you whether there are still
> unconsumed requests.

Perhaps but I think you'd want to keep moving the event pointer to
handle wrap around, i.e. by keeping it always either far enough away or
right behind. (I think "req_cons - 1" is probably the correct option
BTW).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:10:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:10:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmkRY-0000sX-Sn; Mon, 16 Jan 2012 11:09: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 1RmkRX-0000sS-LB
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 11:09:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326712173!11076705!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2559 invoked from network); 16 Jan 2012 11:09: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;
	16 Jan 2012 11:09:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10042665"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:09: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, 16 Jan 2012 11:09:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Mon, 16 Jan 2012 11:09:33 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC4D@LONPMAILBOX01.citrite.net>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>
	<4F107625.7090601@citrix.com> <1326706394.5285.5.camel@liuw-desktop>
	<1326710711.17210.411.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4D@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326712173.17210.412.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 10:56 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Ian Campbell
> > Sent: 16 January 2012 10:45
> > To: Wei Liu (Intern)
> > Cc: netdev@vger.kernel.org; xen-devel@lists.xensource.com; David Vrabel;
> > konrad.wilk@oracle.com
> > Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
> > model
> > 
> > On Mon, 2012-01-16 at 09:33 +0000, Wei Liu (Intern) wrote:
> > > On Fri, 2012-01-13 at 18:21 +0000, David Vrabel wrote:
> > > > On 13/01/12 16:59, Wei Liu wrote:
> > > > > This patch implements 1:1 model netback. We utilizes NAPI and
> > > > > kthread to do the weight-lifting job:
> > > > >
> > > > >   - NAPI is used for guest side TX (host side RX)
> > > > >   - kthread is used for guest side RX (host side TX)
> > > > >
> > > > > This model provides better scheduling fairness among vifs. It also
> > > > > lays the foundation for future work.
> > > > >
> > > > > The major defect for the current implementation is that in the
> > > > > NAPI poll handler we don't actually disable interrupt. Xen stuff
> > > > > is different from real hardware, it requires some other tuning of
> > > > > ring macros.
> > > >
> > > > RING_FINAL_CHECK_FOR_REQUESTS() looks it does the correct thing to
> > me.
> > > >
> > > > David
> > >
> > > I need to stop the other end from generating events, so
> > > RING_FINAL_CHECK_FOR_REQUESTS is not the right answer I think.
> > 
> > What you need is a variant which sets req_event some large distance into
> > the future instead of to just req_cons + 1. Or possibly it should be set to just
> > in the past (e.g. req_cons - 1). Call it something like
> > RING_POLL_FOR_REQUESTS().
> > 
> 
> Can you just simply avoid calling RING_FINAL_CHECK_FOR_REQUESTS()
> unless you actually want to re-enable 'interrupts'? All it does is
> manipulate the event pointer and tell you whether there are still
> unconsumed requests.

Perhaps but I think you'd want to keep moving the event pointer to
handle wrap around, i.e. by keeping it always either far enough away or
right behind. (I think "req_cons - 1" is probably the correct option
BTW).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhi-0001Fx-Ov; Mon, 16 Jan 2012 11:26: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 1Rmjah-0007Xr-TN
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:15:06 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326708896!11085409!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27220 invoked from network); 16 Jan 2012 10:14:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	16 Jan 2012 10:14:57 -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 q0GAEaud020838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 05:14:36 -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 q0GAESTl026060; Mon, 16 Jan 2012 05:14:28 -0500
Message-ID: <4F13F883.5090002@redhat.com>
Date: Mon, 16 Jan 2012 12:14:27 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
In-Reply-To: <20120116094020.GA6019@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/16/2012 11:40 AM, Srivatsa Vaddagiri wrote:
> * Avi Kivity <avi@redhat.com> [2012-01-16 11:00:41]:
>
> > Wait, what happens with yield_on_hlt=0?  Will the hypercall work as
> > advertised?
>
> Hmm ..I don't think it will work when yield_on_hlt=0.
>
> One option is to make the kick hypercall available only when
> yield_on_hlt=1?

It's not a good idea to tie various options together.  Features should
be orthogonal.

Can't we make it work?  Just have different handling for
KVM_REQ_PVLOCK_KICK (let's rename it, and the hypercall, PV_UNHALT,
since we can use it for non-locks too).

-- 
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 Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkha-00018c-Sm; Mon, 16 Jan 2012 11:26:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8JP-0002JO-OW
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:26:43 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326565596!8608474!1
X-Originating-IP: [32.97.182.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NiA9PiA1MjM5MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21981 invoked from network); 14 Jan 2012 18:26:37 -0000
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:26:37 -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>; Sat, 14 Jan 2012 13:26:35 -0500
Received: from d01relay06.pok.ibm.com (9.56.227.116)
	by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:26:33 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIQWvG3522732
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:26:32 -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
	q0EIQUJv020619
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 16:26:32 -0200
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIQHoo020471; Sat, 14 Jan 2012 16:26:19 -0200
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:56:20 +0530
Message-Id: <20120114182619.8604.383.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-1976-0000-0000-00000980BF8F
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 3/5] 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 72e8b64..344a7db 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -565,6 +565,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 Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhf-0001Bl-Am; Mon, 16 Jan 2012 11:26:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmiA2-0005Vg-My
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:43:27 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326703362!56076089!1
X-Originating-IP: [202.81.31.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyMzE3NDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4925 invoked from network); 16 Jan 2012 08:42:45 -0000
Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 08:42:45 -0000
Received: from /spool/local
	by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 08:37:59 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp01.au.ibm.com ([202.81.31.207]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 08:37:52 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G8hAUW5234928
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:43:13 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0G8h8fe005891
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:43:10 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0G8h3Yw005642; Mon, 16 Jan 2012 19:43:03 +1100
Message-ID: <4F13E31A.1080502@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 14:13:06 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
	<5861AA49-E70B-4812-BBE4-A8507B3FCF80@suse.de>
In-Reply-To: <5861AA49-E70B-4812-BBE4-A8507B3FCF80@suse.de>
x-cbid: 12011522-1618-0000-0000-0000008C3F23
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 2/5] 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 01/16/2012 08:54 AM, Alexander Graf wrote:
>
> On 14.01.2012, at 19:25, 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_PVLOCK_KICK/KVM_CAP_PVLOCK_KICK.
>>
>> Qemu needs a corresponding patch to pass up the presence of this feature to
>> guest via cpuid. Patch to qemu will be sent separately.
>>
>> 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..7a94987 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_PVLOCK_KICK		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 4c938da..c7b05fc 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -2099,6 +2099,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_PVLOCK_KICK:
>> 		r = 1;
>> 		break;
>> 	case KVM_CAP_COALESCED_MMIO:
>> @@ -2576,7 +2577,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_PVLOCK_KICK);
>>
>> 		if (sched_info_on())
>> 			entry->eax |= (1<<  KVM_FEATURE_STEAL_TIME);
>> @@ -5304,6 +5306,29 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>> 	return 1;
>> }
>>
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @apicid - apicid of vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>> +{
>> +	struct kvm_vcpu *vcpu = NULL;
>> +	int i;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_apic_present(vcpu))
>> +			continue;
>> +
>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>> +			break;
>> +	}
>> +	if (vcpu) {
>> +		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
>> +		kvm_vcpu_kick(vcpu);
>> +	}
>> +}
>> +
>> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>> {
>> 	unsigned long nr, a0, a1, a2, a3, ret;
>> @@ -5340,6 +5365,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 68e67e5..63fb6b0 100644
>> --- a/include/linux/kvm.h
>> +++ b/include/linux/kvm.h
>> @@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
>> #define KVM_CAP_PPC_PAPR 68
>> #define KVM_CAP_S390_GMAP 71
>> #define KVM_CAP_TSC_DEADLINE_TIMER 72
>> +#define KVM_CAP_PVLOCK_KICK 73
>>
>> #ifdef KVM_CAP_IRQ_ROUTING
>>
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index d526231..3b1ae7b 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -50,6 +50,7 @@
>> #define KVM_REQ_APF_HALT          12
>> #define KVM_REQ_STEAL_UPDATE      13
>> #define KVM_REQ_NMI               14
>> +#define KVM_REQ_PVLOCK_KICK       15
>
> Everything I see in this patch is pvlock agnostic. It's only a vcpu kick hypercall. So it's probably a good idea to also name it accordingly :).
>
>
> Alex
>
>

It was indeed KICK_VCPU in V4. But since we are currently dealing with
only pv locks it is renamed so.  But if we start using the code for
flush_tlb_others_ipi() optimization etc, it is good idea to rename
accordingly. OR even  go back to KICK_VCPU as used earlier..

  - Raghu


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhh-0001En-Vv; Mon, 16 Jan 2012 11:26:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rmj3l-0006tg-Rw
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:41:02 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326706804!52681231!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzMTE2NTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30818 invoked from network); 16 Jan 2012 09:40:04 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 09:40:04 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Mon, 16 Jan 2012 04:40:53 -0500
Received: from d01relay06.pok.ibm.com (9.56.227.116)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 04:40:32 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G9eVFM2707624
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 04:40:31 -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
	q0G9eU0x011992
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 07:40:31 -0200
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.124.46.240])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0G9eMgB011619; Mon, 16 Jan 2012 07:40:23 -0200
Date: Mon, 16 Jan 2012 15:10:20 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120116094020.GA6019@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F13E739.7040300@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
x-cbid: 12011609-5806-0000-0000-000011711D46
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Avi Kivity <avi@redhat.com> [2012-01-16 11:00:41]:

> Wait, what happens with yield_on_hlt=0?  Will the hypercall work as
> advertised?

Hmm ..I don't think it will work when yield_on_hlt=0.

One option is to make the kick hypercall available only when
yield_on_hlt=1?

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhg-0001Cz-FD; Mon, 16 Jan 2012 11:26:20 +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 1RmiMa-0005aD-4I
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:56:24 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326704177!10603404!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14766 invoked from network); 16 Jan 2012 08:56:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 08:56:17 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0G8tvCb020998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 03:55:57 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0G8tlv2028816; Mon, 16 Jan 2012 03:55:48 -0500
Message-ID: <4F13E613.7090602@redhat.com>
Date: Mon, 16 Jan 2012 10:55:47 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
In-Reply-To: <03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 08:40 AM, Jeremy Fitzhardinge wrote:
> > 
> > That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
> > 
> > Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.
>
> I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.

The wakeup path is slower though.  The previous lock holder has to
hypercall, and the new lock holder has to be scheduled, and transition
from halted state to running (a vmentry).  So it's only a clear win if
we can do something with the cpu other than go into the idle loop.

> > 
> > Imagine we have a contended host. Every vcpu gets at most 10% of a real CPU's runtime. So chances are 1:10 that you're currently running while you need to be. In such a setup, it's probably a good idea to be very pessimistic. Try to fetch the lock for 100 cycles and then immediately make room for all the other VMs that have real work going on!
>
> Are you saying the threshold should be dynamic depending on how loaded the system is?  How can a guest know what the overall system contention is?  How should a guest use that to work out a good spin time?
>
> One possibility is to use the ticket lock queue depth to work out how contended the lock is, and therefore how long it might be worth waiting for.  I was thinking of something along the lines of "threshold = (THRESHOLD >> queue_depth)".  But that's pure hand wave, and someone would actually need to experiment before coming up with something reasonable.
>
> But all of this is good to consider for future work, rather than being essential for the first version.

Agree.

> > So what I'm trying to get to is that if we had a hypervisor settable spin threshold, we could adjust it according to the host's load, getting VMs to behave differently on different (guest invisible) circumstances.
> > 
> > Speaking of which - don't we have spin lock counters in the CPUs now? I thought we could set intercepts that notify us when the guest issues too many repz nops or whatever the typical spinlock identifier was. Can't we reuse that and just interrupt the guest if we see this with a special KVM interrupt that kicks off the internal spin lock waiting code? That way we don't slow down all those bare metal boxes.
>
> Yes, that mechanism exists, but it doesn't solve a very interesting problem.
>
> The most important thing to solve is making sure that when *releasing* a ticketlock, the correct next VCPU gets scheduled promptly.  If you don't, you're just relying on the VCPU scheduler getting around to scheduling the correct VCPU, but if it doesn't it just ends up burning a timeslice of PCPU time while the wrong VCPU spins.

kvm does a directed yield to an unscheduled vcpu, selected in a round
robin fashion.  So if your overload factor is N (N runnable vcpus for
every physical cpu), and your spin counter waits for S cycles before
exiting, you will burn N*S cycles (actually more since there is overhead
involved, but lets fold it into S).

> Limiting the spin time with a timeout or the rep/nop interrupt somewhat mitigates this, but it still means you end up spending a lot of time slices spinning the wrong VCPU until it finally schedules the correct one.  And the more contended the machine is, the worse the problem gets.

Right.

>
> > Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.
>
> The whole point of the pv-ticketlock work is to keep the pvops hooks out of the locking fast path, so that the calls are only made on the slow path - that is, when spinning too long on a contended lock, and when releasing a lock that's in a "slow" state.  In the fast path case of no contention, there are no pvops, and the executed code path is almost identical to native.
>
> But as I mentioned above, I'd like to see some benchmarks to prove that's the case.
>

-- 
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 Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhf-0001Bl-Am; Mon, 16 Jan 2012 11:26:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmiA2-0005Vg-My
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:43:27 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326703362!56076089!1
X-Originating-IP: [202.81.31.143]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MyA9PiAyMzE3NDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4925 invoked from network); 16 Jan 2012 08:42:45 -0000
Received: from e23smtp01.au.ibm.com (HELO e23smtp01.au.ibm.com) (202.81.31.143)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 08:42:45 -0000
Received: from /spool/local
	by e23smtp01.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 08:37:59 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp01.au.ibm.com ([202.81.31.207]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 08:37:52 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G8hAUW5234928
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:43:13 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0G8h8fe005891
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:43:10 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0G8h3Yw005642; Mon, 16 Jan 2012 19:43:03 +1100
Message-ID: <4F13E31A.1080502@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 14:13:06 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
	<5861AA49-E70B-4812-BBE4-A8507B3FCF80@suse.de>
In-Reply-To: <5861AA49-E70B-4812-BBE4-A8507B3FCF80@suse.de>
x-cbid: 12011522-1618-0000-0000-0000008C3F23
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 2/5] 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 01/16/2012 08:54 AM, Alexander Graf wrote:
>
> On 14.01.2012, at 19:25, 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_PVLOCK_KICK/KVM_CAP_PVLOCK_KICK.
>>
>> Qemu needs a corresponding patch to pass up the presence of this feature to
>> guest via cpuid. Patch to qemu will be sent separately.
>>
>> 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..7a94987 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_PVLOCK_KICK		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 4c938da..c7b05fc 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -2099,6 +2099,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_PVLOCK_KICK:
>> 		r = 1;
>> 		break;
>> 	case KVM_CAP_COALESCED_MMIO:
>> @@ -2576,7 +2577,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_PVLOCK_KICK);
>>
>> 		if (sched_info_on())
>> 			entry->eax |= (1<<  KVM_FEATURE_STEAL_TIME);
>> @@ -5304,6 +5306,29 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>> 	return 1;
>> }
>>
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @apicid - apicid of vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>> +{
>> +	struct kvm_vcpu *vcpu = NULL;
>> +	int i;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_apic_present(vcpu))
>> +			continue;
>> +
>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>> +			break;
>> +	}
>> +	if (vcpu) {
>> +		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
>> +		kvm_vcpu_kick(vcpu);
>> +	}
>> +}
>> +
>> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>> {
>> 	unsigned long nr, a0, a1, a2, a3, ret;
>> @@ -5340,6 +5365,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 68e67e5..63fb6b0 100644
>> --- a/include/linux/kvm.h
>> +++ b/include/linux/kvm.h
>> @@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
>> #define KVM_CAP_PPC_PAPR 68
>> #define KVM_CAP_S390_GMAP 71
>> #define KVM_CAP_TSC_DEADLINE_TIMER 72
>> +#define KVM_CAP_PVLOCK_KICK 73
>>
>> #ifdef KVM_CAP_IRQ_ROUTING
>>
>> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
>> index d526231..3b1ae7b 100644
>> --- a/include/linux/kvm_host.h
>> +++ b/include/linux/kvm_host.h
>> @@ -50,6 +50,7 @@
>> #define KVM_REQ_APF_HALT          12
>> #define KVM_REQ_STEAL_UPDATE      13
>> #define KVM_REQ_NMI               14
>> +#define KVM_REQ_PVLOCK_KICK       15
>
> Everything I see in this patch is pvlock agnostic. It's only a vcpu kick hypercall. So it's probably a good idea to also name it accordingly :).
>
>
> Alex
>
>

It was indeed KICK_VCPU in V4. But since we are currently dealing with
only pv locks it is renamed so.  But if we start using the code for
flush_tlb_others_ipi() optimization etc, it is good idea to rename
accordingly. OR even  go back to KICK_VCPU as used earlier..

  - Raghu


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhh-0001En-Vv; Mon, 16 Jan 2012 11:26:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rmj3l-0006tg-Rw
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:41:02 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326706804!52681231!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzMTE2NTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30818 invoked from network); 16 Jan 2012 09:40:04 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 09:40:04 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Mon, 16 Jan 2012 04:40:53 -0500
Received: from d01relay06.pok.ibm.com (9.56.227.116)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 04:40:32 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G9eVFM2707624
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 04:40:31 -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
	q0G9eU0x011992
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 07:40:31 -0200
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.124.46.240])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0G9eMgB011619; Mon, 16 Jan 2012 07:40:23 -0200
Date: Mon, 16 Jan 2012 15:10:20 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120116094020.GA6019@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F13E739.7040300@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
x-cbid: 12011609-5806-0000-0000-000011711D46
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Avi Kivity <avi@redhat.com> [2012-01-16 11:00:41]:

> Wait, what happens with yield_on_hlt=0?  Will the hypercall work as
> advertised?

Hmm ..I don't think it will work when yield_on_hlt=0.

One option is to make the kick hypercall available only when
yield_on_hlt=1?

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhi-0001Fx-Ov; Mon, 16 Jan 2012 11:26: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 1Rmjah-0007Xr-TN
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:15:06 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326708896!11085409!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27220 invoked from network); 16 Jan 2012 10:14:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	16 Jan 2012 10:14:57 -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 q0GAEaud020838
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 05:14:36 -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 q0GAESTl026060; Mon, 16 Jan 2012 05:14:28 -0500
Message-ID: <4F13F883.5090002@redhat.com>
Date: Mon, 16 Jan 2012 12:14:27 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
In-Reply-To: <20120116094020.GA6019@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/16/2012 11:40 AM, Srivatsa Vaddagiri wrote:
> * Avi Kivity <avi@redhat.com> [2012-01-16 11:00:41]:
>
> > Wait, what happens with yield_on_hlt=0?  Will the hypercall work as
> > advertised?
>
> Hmm ..I don't think it will work when yield_on_hlt=0.
>
> One option is to make the kick hypercall available only when
> yield_on_hlt=1?

It's not a good idea to tie various options together.  Features should
be orthogonal.

Can't we make it work?  Just have different handling for
KVM_REQ_PVLOCK_KICK (let's rename it, and the hypercall, PV_UNHALT,
since we can use it for non-locks too).

-- 
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 Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhj-0001Hm-MX; Mon, 16 Jan 2012 11:26:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmjmE-0007vA-TF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:26:59 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326709577!56095201!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3218 invoked from network); 16 Jan 2012 10:26:18 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 10:26:18 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 5093992016;
	Mon, 16 Jan 2012 11:26:57 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <4F13E36B.9020408@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 11:26:54 +0100
Message-Id: <A65A7F2B-4C08-4437-87D2-FB978F541DE9@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
	<4F13E36B.9020408@linux.vnet.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 09:44, Raghavendra K T wrote:

> On 01/16/2012 08:53 AM, Alexander Graf wrote:
>> 
>> On 14.01.2012, at 19:27, Raghavendra K T wrote:
>> 
>>> Add Documentation on CPUID, KVM_CAP_PVLOCK_KICK, and Hypercalls supported.
>>> 
>>> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in
>>> paravirtual spinlock enabled guest.
>>> 
>>> KVM_FEATURE_PVLOCK_KICK enables guest to check whether pv spinlock can
>>> be enabled in guest. support in host is queried via
>>> ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
>>> 
>>> A minimal Documentation and template is added for hypercalls.
>>> 
>>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>> ---
> [...]
>>> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
>>> new file mode 100644
>>> index 0000000..7872da5
>>> --- /dev/null
>>> +++ b/Documentation/virtual/kvm/hypercalls.txt
>>> @@ -0,0 +1,54 @@
>>> +KVM Hypercalls Documentation
>>> +===========================
> 
>>> +2. KVM_HC_MMU_OP
>>> +------------------------
>>> +value: 2
>>> +Architecture: x86
>>> +Purpose: Support MMU operations such as writing to PTE,
>>> +flushing TLB, release PT.
>> 
>> This one is deprecated, no? Should probably be mentioned here.
> 
> Ok, then may be adding state = deprecated/obsolete/in use (active) may
> be good idea.
> 
>> 
>>> +
>>> +3. KVM_HC_FEATURES
>>> +------------------------
>>> +value: 3
>>> +Architecture: PPC
>>> +Purpose:
>> 
>> Expose hypercall availability to the guest. On x86 you use cpuid to enumerate which hypercalls are available. The natural fit on ppc would be device tree based lookup (which is also what EPAPR dictates), but we also have a second enumeration mechanism that's KVM specific - which is this hypercall.
>> 
> 
> Thanks, will add this. I hope you are OK if I add Signed-off-by: you.

I don't think you need a signed-off-by from me for this very simple documentation addition :). You should probably also reword it. I didn't quite write it as a paragraph that should go into the file.


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhj-0001Hm-MX; Mon, 16 Jan 2012 11:26:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmjmE-0007vA-TF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:26:59 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326709577!56095201!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3218 invoked from network); 16 Jan 2012 10:26:18 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 10:26:18 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 5093992016;
	Mon, 16 Jan 2012 11:26:57 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <4F13E36B.9020408@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 11:26:54 +0100
Message-Id: <A65A7F2B-4C08-4437-87D2-FB978F541DE9@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
	<4F13E36B.9020408@linux.vnet.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 09:44, Raghavendra K T wrote:

> On 01/16/2012 08:53 AM, Alexander Graf wrote:
>> 
>> On 14.01.2012, at 19:27, Raghavendra K T wrote:
>> 
>>> Add Documentation on CPUID, KVM_CAP_PVLOCK_KICK, and Hypercalls supported.
>>> 
>>> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in
>>> paravirtual spinlock enabled guest.
>>> 
>>> KVM_FEATURE_PVLOCK_KICK enables guest to check whether pv spinlock can
>>> be enabled in guest. support in host is queried via
>>> ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
>>> 
>>> A minimal Documentation and template is added for hypercalls.
>>> 
>>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>>> ---
> [...]
>>> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
>>> new file mode 100644
>>> index 0000000..7872da5
>>> --- /dev/null
>>> +++ b/Documentation/virtual/kvm/hypercalls.txt
>>> @@ -0,0 +1,54 @@
>>> +KVM Hypercalls Documentation
>>> +===========================
> 
>>> +2. KVM_HC_MMU_OP
>>> +------------------------
>>> +value: 2
>>> +Architecture: x86
>>> +Purpose: Support MMU operations such as writing to PTE,
>>> +flushing TLB, release PT.
>> 
>> This one is deprecated, no? Should probably be mentioned here.
> 
> Ok, then may be adding state = deprecated/obsolete/in use (active) may
> be good idea.
> 
>> 
>>> +
>>> +3. KVM_HC_FEATURES
>>> +------------------------
>>> +value: 3
>>> +Architecture: PPC
>>> +Purpose:
>> 
>> Expose hypercall availability to the guest. On x86 you use cpuid to enumerate which hypercalls are available. The natural fit on ppc would be device tree based lookup (which is also what EPAPR dictates), but we also have a second enumeration mechanism that's KVM specific - which is this hypercall.
>> 
> 
> Thanks, will add this. I hope you are OK if I add Signed-off-by: you.

I don't think you need a signed-off-by from me for this very simple documentation addition :). You should probably also reword it. I didn't quite write it as a paragraph that should go into the file.


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkha-00018O-4q; Mon, 16 Jan 2012 11:26:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8IZ-0002Hp-W2
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:25:52 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326565544!8478115!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzMTExMTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7770 invoked from network); 14 Jan 2012 18:25:45 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:25:45 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Sat, 14 Jan 2012 13:25:44 -0500
Received: from d01relay02.pok.ibm.com (9.56.227.234)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:25:43 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIPgp2461150
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:25:42 -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
	q0EIPdWi029434
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:25:42 -0500
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIPPqD028398; Sat, 14 Jan 2012 13:25:27 -0500
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:55:28 +0530
Message-Id: <20120114182527.8604.2705.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-5806-0000-0000-00001168D864
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 1/5] 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>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkha-00018O-4q; Mon, 16 Jan 2012 11:26:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8IZ-0002Hp-W2
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:25:52 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326565544!8478115!1
X-Originating-IP: [32.97.182.137]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzNyA9PiAzMTExMTQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7770 invoked from network); 14 Jan 2012 18:25:45 -0000
Received: from e7.ny.us.ibm.com (HELO e7.ny.us.ibm.com) (32.97.182.137)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:25:45 -0000
Received: from /spool/local
	by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Sat, 14 Jan 2012 13:25:44 -0500
Received: from d01relay02.pok.ibm.com (9.56.227.234)
	by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:25:43 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIPgp2461150
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:25:42 -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
	q0EIPdWi029434
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:25:42 -0500
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIPPqD028398; Sat, 14 Jan 2012 13:25:27 -0500
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:55:28 +0530
Message-Id: <20120114182527.8604.2705.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-5806-0000-0000-00001168D864
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 1/5] 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>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkha-00018c-Sm; Mon, 16 Jan 2012 11:26:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8JP-0002JO-OW
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:26:43 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326565596!8608474!1
X-Originating-IP: [32.97.182.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NiA9PiA1MjM5MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21981 invoked from network); 14 Jan 2012 18:26:37 -0000
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:26:37 -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>; Sat, 14 Jan 2012 13:26:35 -0500
Received: from d01relay06.pok.ibm.com (9.56.227.116)
	by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:26:33 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIQWvG3522732
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:26:32 -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
	q0EIQUJv020619
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 16:26:32 -0200
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIQHoo020471; Sat, 14 Jan 2012 16:26:19 -0200
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:56:20 +0530
Message-Id: <20120114182619.8604.383.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-1976-0000-0000-00000980BF8F
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 3/5] 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 72e8b64..344a7db 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -565,6 +565,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 Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhg-0001Cz-FD; Mon, 16 Jan 2012 11:26:20 +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 1RmiMa-0005aD-4I
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:56:24 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326704177!10603404!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14766 invoked from network); 16 Jan 2012 08:56:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-14.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 08:56:17 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0G8tvCb020998
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 03:55:57 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0G8tlv2028816; Mon, 16 Jan 2012 03:55:48 -0500
Message-ID: <4F13E613.7090602@redhat.com>
Date: Mon, 16 Jan 2012 10:55:47 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
In-Reply-To: <03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 08:40 AM, Jeremy Fitzhardinge wrote:
> > 
> > That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
> > 
> > Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.
>
> I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.

The wakeup path is slower though.  The previous lock holder has to
hypercall, and the new lock holder has to be scheduled, and transition
from halted state to running (a vmentry).  So it's only a clear win if
we can do something with the cpu other than go into the idle loop.

> > 
> > Imagine we have a contended host. Every vcpu gets at most 10% of a real CPU's runtime. So chances are 1:10 that you're currently running while you need to be. In such a setup, it's probably a good idea to be very pessimistic. Try to fetch the lock for 100 cycles and then immediately make room for all the other VMs that have real work going on!
>
> Are you saying the threshold should be dynamic depending on how loaded the system is?  How can a guest know what the overall system contention is?  How should a guest use that to work out a good spin time?
>
> One possibility is to use the ticket lock queue depth to work out how contended the lock is, and therefore how long it might be worth waiting for.  I was thinking of something along the lines of "threshold = (THRESHOLD >> queue_depth)".  But that's pure hand wave, and someone would actually need to experiment before coming up with something reasonable.
>
> But all of this is good to consider for future work, rather than being essential for the first version.

Agree.

> > So what I'm trying to get to is that if we had a hypervisor settable spin threshold, we could adjust it according to the host's load, getting VMs to behave differently on different (guest invisible) circumstances.
> > 
> > Speaking of which - don't we have spin lock counters in the CPUs now? I thought we could set intercepts that notify us when the guest issues too many repz nops or whatever the typical spinlock identifier was. Can't we reuse that and just interrupt the guest if we see this with a special KVM interrupt that kicks off the internal spin lock waiting code? That way we don't slow down all those bare metal boxes.
>
> Yes, that mechanism exists, but it doesn't solve a very interesting problem.
>
> The most important thing to solve is making sure that when *releasing* a ticketlock, the correct next VCPU gets scheduled promptly.  If you don't, you're just relying on the VCPU scheduler getting around to scheduling the correct VCPU, but if it doesn't it just ends up burning a timeslice of PCPU time while the wrong VCPU spins.

kvm does a directed yield to an unscheduled vcpu, selected in a round
robin fashion.  So if your overload factor is N (N runnable vcpus for
every physical cpu), and your spin counter waits for S cycles before
exiting, you will burn N*S cycles (actually more since there is overhead
involved, but lets fold it into S).

> Limiting the spin time with a timeout or the rep/nop interrupt somewhat mitigates this, but it still means you end up spending a lot of time slices spinning the wrong VCPU until it finally schedules the correct one.  And the more contended the machine is, the worse the problem gets.

Right.

>
> > Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.
>
> The whole point of the pv-ticketlock work is to keep the pvops hooks out of the locking fast path, so that the calls are only made on the slow path - that is, when spinning too long on a contended lock, and when releasing a lock that's in a "slow" state.  In the fast path case of no contention, there are no pvops, and the executed code path is almost identical to native.
>
> But as I mentioned above, I'd like to see some benchmarks to prove that's the case.
>

-- 
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 Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhj-0001H5-9H; Mon, 16 Jan 2012 11:26:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmjkD-0007sN-Iw
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:24:53 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326709470!52970672!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22608 invoked from network); 16 Jan 2012 10:24:30 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 10:24:30 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 5A14392004;
	Mon, 16 Jan 2012 11:24:46 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
Date: Mon, 16 Jan 2012 11:24:39 +0100
Message-Id: <0B6BF918-45C7-45C6-AAA4-FB73EFAB9FDB@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 16.01.2012, at 07:40, Jeremy Fitzhardinge wrote:

> On Jan 16, 2012, at 2:57 PM, Alexander Graf wrote:
> 
>> 
>> On 14.01.2012, at 19:25, Raghavendra K T wrote:
>> 
>>> The 5-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.
>> 
>> Is the code for this even upstream? Prerequisite series seem to have been posted by Jeremy, but they didn't appear to have made it in yet.
> 
> No, not yet.  The patches are unchanged since I last posted them, and as far as I know there are no objections to them, but I'd like to get some performance numbers just to make sure they don't cause any surprising regressions, especially in the non-virtual case.

Yup, that's a very good idea :)

> 
>> 
>> Either way, thinking about this I stumbled over the following passage of his patch:
>> 
>>> +               unsigned count = SPIN_THRESHOLD;
>>> +
>>> +               do {
>>> +                       if (inc.head == inc.tail)
>>> +                               goto out;
>>> +                       cpu_relax();
>>> +                       inc.head = ACCESS_ONCE(lock->tickets.head);
>>> +               } while (--count);
>>> +               __ticket_lock_spinning(lock, inc.tail);
>> 
>> 
>> That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
>> 
>> Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.
> 
> I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.
> 
>> 
>> Imagine we have a contended host. Every vcpu gets at most 10% of a real CPU's runtime. So chances are 1:10 that you're currently running while you need to be. In such a setup, it's probably a good idea to be very pessimistic. Try to fetch the lock for 100 cycles and then immediately make room for all the other VMs that have real work going on!
> 
> Are you saying the threshold should be dynamic depending on how loaded the system is?  How can a guest know what the overall system contention is?  How should a guest use that to work out a good spin time?

I'm saying what I'm saying in the next paragraph :). The guest doesn't know, but the host does. So if we had shared memory between guest and host, the host could put its threshold limit in there, which on an idle system could be -1 and on a contended system could be 1.

> One possibility is to use the ticket lock queue depth to work out how contended the lock is, and therefore how long it might be worth waiting for.  I was thinking of something along the lines of "threshold = (THRESHOLD >> queue_depth)".  But that's pure hand wave, and someone would actually need to experiment before coming up with something reasonable.
> 
> But all of this is good to consider for future work, rather than being essential for the first version.

Well, yes, of course! It's by no means an objection to what's there today. I'm just trying to think of ways to make it even better :)

> 
>> So what I'm trying to get to is that if we had a hypervisor settable spin threshold, we could adjust it according to the host's load, getting VMs to behave differently on different (guest invisible) circumstances.
>> 
>> Speaking of which - don't we have spin lock counters in the CPUs now? I thought we could set intercepts that notify us when the guest issues too many repz nops or whatever the typical spinlock identifier was. Can't we reuse that and just interrupt the guest if we see this with a special KVM interrupt that kicks off the internal spin lock waiting code? That way we don't slow down all those bare metal boxes.
> 
> Yes, that mechanism exists, but it doesn't solve a very interesting problem.
> 
> The most important thing to solve is making sure that when *releasing* a ticketlock, the correct next VCPU gets scheduled promptly.  If you don't, you're just relying on the VCPU scheduler getting around to scheduling the correct VCPU, but if it doesn't it just ends up burning a timeslice of PCPU time while the wrong VCPU spins.
> 
> Limiting the spin time with a timeout or the rep/nop interrupt somewhat mitigates this, but it still means you end up spending a lot of time slices spinning the wrong VCPU until it finally schedules the correct one.  And the more contended the machine is, the worse the problem gets.

This is true in case you're spinning. If on overcommit spinlocks would instead of spin just yield(), we wouldn't have any vcpu running that's just waiting for a late ticket.

We still have an issue finding the point in time when a vcpu could run again, which is what this whole series is about. My point above was that instead of doing a count loop, we could just do the normal spin dance and set the threshold to when we enable the magic to have another spin lock notify us in the CPU. That way we

  * don't change the uncontended case
  * can set the threshold on the host, which knows how contended the system is

And since we control what spin locks look like, we can for example always keep the pointer to it in a specific register so that we can handle pv_lock_ops.lock_spinning() inside there and fetch all the information we need from our pt_regs.

> 
>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.
> 
> The whole point of the pv-ticketlock work is to keep the pvops hooks out of the locking fast path, so that the calls are only made on the slow path - that is, when spinning too long on a contended lock, and when releasing a lock that's in a "slow" state.  In the fast path case of no contention, there are no pvops, and the executed code path is almost identical to native.

You're still changing a tight loop that does nothing (CPU detects it and saves power) into something that performs calculations.

> But as I mentioned above, I'd like to see some benchmarks to prove that's the case.

Yes, that would be very good to have :)


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhj-0001H5-9H; Mon, 16 Jan 2012 11:26:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmjkD-0007sN-Iw
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 10:24:53 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326709470!52970672!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22608 invoked from network); 16 Jan 2012 10:24:30 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 10:24:30 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 5A14392004;
	Mon, 16 Jan 2012 11:24:46 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
Date: Mon, 16 Jan 2012 11:24:39 +0100
Message-Id: <0B6BF918-45C7-45C6-AAA4-FB73EFAB9FDB@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 16.01.2012, at 07:40, Jeremy Fitzhardinge wrote:

> On Jan 16, 2012, at 2:57 PM, Alexander Graf wrote:
> 
>> 
>> On 14.01.2012, at 19:25, Raghavendra K T wrote:
>> 
>>> The 5-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.
>> 
>> Is the code for this even upstream? Prerequisite series seem to have been posted by Jeremy, but they didn't appear to have made it in yet.
> 
> No, not yet.  The patches are unchanged since I last posted them, and as far as I know there are no objections to them, but I'd like to get some performance numbers just to make sure they don't cause any surprising regressions, especially in the non-virtual case.

Yup, that's a very good idea :)

> 
>> 
>> Either way, thinking about this I stumbled over the following passage of his patch:
>> 
>>> +               unsigned count = SPIN_THRESHOLD;
>>> +
>>> +               do {
>>> +                       if (inc.head == inc.tail)
>>> +                               goto out;
>>> +                       cpu_relax();
>>> +                       inc.head = ACCESS_ONCE(lock->tickets.head);
>>> +               } while (--count);
>>> +               __ticket_lock_spinning(lock, inc.tail);
>> 
>> 
>> That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
>> 
>> Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.
> 
> I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.
> 
>> 
>> Imagine we have a contended host. Every vcpu gets at most 10% of a real CPU's runtime. So chances are 1:10 that you're currently running while you need to be. In such a setup, it's probably a good idea to be very pessimistic. Try to fetch the lock for 100 cycles and then immediately make room for all the other VMs that have real work going on!
> 
> Are you saying the threshold should be dynamic depending on how loaded the system is?  How can a guest know what the overall system contention is?  How should a guest use that to work out a good spin time?

I'm saying what I'm saying in the next paragraph :). The guest doesn't know, but the host does. So if we had shared memory between guest and host, the host could put its threshold limit in there, which on an idle system could be -1 and on a contended system could be 1.

> One possibility is to use the ticket lock queue depth to work out how contended the lock is, and therefore how long it might be worth waiting for.  I was thinking of something along the lines of "threshold = (THRESHOLD >> queue_depth)".  But that's pure hand wave, and someone would actually need to experiment before coming up with something reasonable.
> 
> But all of this is good to consider for future work, rather than being essential for the first version.

Well, yes, of course! It's by no means an objection to what's there today. I'm just trying to think of ways to make it even better :)

> 
>> So what I'm trying to get to is that if we had a hypervisor settable spin threshold, we could adjust it according to the host's load, getting VMs to behave differently on different (guest invisible) circumstances.
>> 
>> Speaking of which - don't we have spin lock counters in the CPUs now? I thought we could set intercepts that notify us when the guest issues too many repz nops or whatever the typical spinlock identifier was. Can't we reuse that and just interrupt the guest if we see this with a special KVM interrupt that kicks off the internal spin lock waiting code? That way we don't slow down all those bare metal boxes.
> 
> Yes, that mechanism exists, but it doesn't solve a very interesting problem.
> 
> The most important thing to solve is making sure that when *releasing* a ticketlock, the correct next VCPU gets scheduled promptly.  If you don't, you're just relying on the VCPU scheduler getting around to scheduling the correct VCPU, but if it doesn't it just ends up burning a timeslice of PCPU time while the wrong VCPU spins.
> 
> Limiting the spin time with a timeout or the rep/nop interrupt somewhat mitigates this, but it still means you end up spending a lot of time slices spinning the wrong VCPU until it finally schedules the correct one.  And the more contended the machine is, the worse the problem gets.

This is true in case you're spinning. If on overcommit spinlocks would instead of spin just yield(), we wouldn't have any vcpu running that's just waiting for a late ticket.

We still have an issue finding the point in time when a vcpu could run again, which is what this whole series is about. My point above was that instead of doing a count loop, we could just do the normal spin dance and set the threshold to when we enable the magic to have another spin lock notify us in the CPU. That way we

  * don't change the uncontended case
  * can set the threshold on the host, which knows how contended the system is

And since we control what spin locks look like, we can for example always keep the pointer to it in a specific register so that we can handle pv_lock_ops.lock_spinning() inside there and fetch all the information we need from our pt_regs.

> 
>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.
> 
> The whole point of the pv-ticketlock work is to keep the pvops hooks out of the locking fast path, so that the calls are only made on the slow path - that is, when spinning too long on a contended lock, and when releasing a lock that's in a "slow" state.  In the fast path case of no contention, there are no pvops, and the executed code path is almost identical to native.

You're still changing a tight loop that does nothing (CPU detects it and saves power) into something that performs calculations.

> But as I mentioned above, I'd like to see some benchmarks to prove that's the case.

Yes, that would be very good to have :)


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhd-00019j-0H; Mon, 16 Jan 2012 11:26:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmdBa-0002Bo-G4
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:24:42 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326684165!59796089!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10303 invoked from network); 16 Jan 2012 03:22:45 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 03:22:45 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 9A56A8C061;
	Mon, 16 Jan 2012 04:24:40 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
Date: Mon, 16 Jan 2012 04:24:38 +0100
Message-Id: <5861AA49-E70B-4812-BBE4-A8507B3FCF80@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 2/5] 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 14.01.2012, at 19:25, 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_PVLOCK_KICK/KVM_CAP_PVLOCK_KICK.
> 
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.
> 
> 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..7a94987 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_PVLOCK_KICK		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 4c938da..c7b05fc 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2099,6 +2099,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_PVLOCK_KICK:
> 		r = 1;
> 		break;
> 	case KVM_CAP_COALESCED_MMIO:
> @@ -2576,7 +2577,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_PVLOCK_KICK);
> 
> 		if (sched_info_on())
> 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> @@ -5304,6 +5306,29 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> 	return 1;
> }
> 
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
> +
> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> {
> 	unsigned long nr, a0, a1, a2, a3, ret;
> @@ -5340,6 +5365,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 68e67e5..63fb6b0 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
> #define KVM_CAP_PPC_PAPR 68
> #define KVM_CAP_S390_GMAP 71
> #define KVM_CAP_TSC_DEADLINE_TIMER 72
> +#define KVM_CAP_PVLOCK_KICK 73
> 
> #ifdef KVM_CAP_IRQ_ROUTING
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d526231..3b1ae7b 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -50,6 +50,7 @@
> #define KVM_REQ_APF_HALT          12
> #define KVM_REQ_STEAL_UPDATE      13
> #define KVM_REQ_NMI               14
> +#define KVM_REQ_PVLOCK_KICK       15

Everything I see in this patch is pvlock agnostic. It's only a vcpu kick hypercall. So it's probably a good idea to also name it accordingly :).


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhd-00019j-0H; Mon, 16 Jan 2012 11:26:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmdBa-0002Bo-G4
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:24:42 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326684165!59796089!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10303 invoked from network); 16 Jan 2012 03:22:45 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 03:22:45 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 9A56A8C061;
	Mon, 16 Jan 2012 04:24:40 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
Date: Mon, 16 Jan 2012 04:24:38 +0100
Message-Id: <5861AA49-E70B-4812-BBE4-A8507B3FCF80@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 2/5] 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 14.01.2012, at 19:25, 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_PVLOCK_KICK/KVM_CAP_PVLOCK_KICK.
> 
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.
> 
> 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..7a94987 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_PVLOCK_KICK		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 4c938da..c7b05fc 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -2099,6 +2099,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_PVLOCK_KICK:
> 		r = 1;
> 		break;
> 	case KVM_CAP_COALESCED_MMIO:
> @@ -2576,7 +2577,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_PVLOCK_KICK);
> 
> 		if (sched_info_on())
> 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
> @@ -5304,6 +5306,29 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> 	return 1;
> }
> 
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
> +
> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> {
> 	unsigned long nr, a0, a1, a2, a3, ret;
> @@ -5340,6 +5365,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 68e67e5..63fb6b0 100644
> --- a/include/linux/kvm.h
> +++ b/include/linux/kvm.h
> @@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
> #define KVM_CAP_PPC_PAPR 68
> #define KVM_CAP_S390_GMAP 71
> #define KVM_CAP_TSC_DEADLINE_TIMER 72
> +#define KVM_CAP_PVLOCK_KICK 73
> 
> #ifdef KVM_CAP_IRQ_ROUTING
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index d526231..3b1ae7b 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -50,6 +50,7 @@
> #define KVM_REQ_APF_HALT          12
> #define KVM_REQ_STEAL_UPDATE      13
> #define KVM_REQ_NMI               14
> +#define KVM_REQ_PVLOCK_KICK       15

Everything I see in this patch is pvlock agnostic. It's only a vcpu kick hypercall. So it's probably a good idea to also name it accordingly :).


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1RmkhZ-00018H-ON; Mon, 16 Jan 2012 11:26:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8IC-0002H8-6v
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:25:28 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326565519!7819031!1
X-Originating-IP: [32.97.110.150]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MCA9PiAxMDMwODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19666 invoked from network); 14 Jan 2012 18:25:20 -0000
Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:25:20 -0000
Received: from /spool/local
	by e32.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>; Sat, 14 Jan 2012 11:25:18 -0700
Received: from d03relay05.boulder.ibm.com (9.17.195.107)
	by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 11:25:16 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIPFrm037412
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 11:25:15 -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 q0EIPDNs025436
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 11:25:15 -0700
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIOwGk024309; Sat, 14 Jan 2012 11:25:01 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, X86 <x86@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Rob Landley <rlandley@parallels.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:55:02 +0530
Message-Id: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-3270-0000-0000-000003369F91
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 0/5] kvm : Paravirt-spinlock support for
	KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 5-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.

Changes in V4:
- reabsed to 3.2.0 pre.
- use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching. (Avi)
- fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
  changes for UNHALT path to make pv ticket spinlock migration friendly. (Avi, Marcello)
- Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
  and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
- Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
- cumulative variable type changed (int ==> u32) in add_stat (Konrad)
- remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case

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 (5): 
  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
  Add documentation on Hypercalls and features used for PV spinlock
 
Test Set up :
The BASE patch is pre 3.2.0 + Jeremy's following patches.
xadd (https://lkml.org/lkml/2011/10/4/328)
x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
Kernel for host/guest : 3.2.0 + Jeremy's xadd, pv spinlock patches as BASE
(Note:locked add change is not taken yet)

Results:
 The performance gain is mainly because of reduced busy-wait time.
 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 (non PLE).
 On PLE machine we do not see greater performance improvement because of PLE
 complimenting halt()

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

scenario B: unpinned, run kernbench on all the guests no hogs.

Dbench on PLE machine:
dbench run on all the guest simultaneously with
dbench --warmup=30 -t 120 with NRCLIENTS=(8/16/32).

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:	 164.233 (16.5506) 	 163.584 (15.4598 	0.39517
case 2x:	 897.654 (543.993) 	 328.63 (103.771) 	63.3901
case 3x:	 2855.73 (2201.41) 	 315.029 (111.854) 	88.9685

Dbench:
Throughput is in MB/sec
NRCLIENTS	 BASE                    BASE+patch            %improvement
               	 mean (sd)               mean (sd)
8       	1.774307  (0.061361) 	1.725667  (0.034644) 	-2.74135
16      	1.445967  (0.044805) 	1.463173  (0.094399) 	1.18993
32        	2.136667  (0.105717) 	2.193792  (0.129357) 	2.67356

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

Kernbench:
		 BASE                    BASE+patch            %improvement
		 mean (sd)               mean (sd)
Scenario A:	 			
case 1x:	 161.263 (56.518) 	 159.635 (40.5621) 	1.00953
case 2x:	 190.748 (61.2745) 	 190.606 (54.4766) 	0.0744438
case 3x:	 227.378 (100.215) 	 225.442 (92.0809) 	0.851446

Scenario B:
		 446.104 (58.54 )	 433.12733 (54.476)	2.91

Dbench:
Throughput is in MB/sec
NRCLIENTS	 BASE                    BASE+patch            %improvement
               	 mean (sd)               mean (sd)
8       	1.101190  (0.875082) 	1.700395  (0.846809) 	54.4143
16      	1.524312  (0.120354) 	1.477553  (0.058166) 	-3.06755
32        	2.143028  (0.157103) 	2.090307  (0.136778) 	-2.46012

---
 V3 kernel Changes:
 https://lkml.org/lkml/2011/11/30/62
 V2 kernel changes : 
 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
 
 Qemu patch for V3:
 http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html

 Documentation/virtual/kvm/api.txt        |    7 +
 Documentation/virtual/kvm/cpuid.txt      |    4 +
 Documentation/virtual/kvm/hypercalls.txt |   54 +++++++
 arch/x86/Kconfig                         |    9 +
 arch/x86/include/asm/kvm_para.h          |   16 ++-
 arch/x86/kernel/kvm.c                    |  249 ++++++++++++++++++++++++++++++
 arch/x86/kvm/x86.c                       |   37 ++++-
 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                 |    1 +
 include/linux/kvm_para.h                 |    1 +
 15 files changed, 514 insertions(+), 114 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhg-0001DV-Sf; Mon, 16 Jan 2012 11:26:20 +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 1RmiRI-0005kq-NF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:01:16 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326704469!8503375!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30457 invoked from network); 16 Jan 2012 09:01:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 09:01:10 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0G90ofo022089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 04:00:50 -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 q0G90fMn014729; Mon, 16 Jan 2012 04:00:42 -0500
Message-ID: <4F13E739.7040300@redhat.com>
Date: Mon, 16 Jan 2012 11:00:41 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/14/2012 08:27 PM, Raghavendra K T wrote:
> +
> +5. KVM_HC_KICK_CPU
> +------------------------
> +value: 5
> +Architecture: x86
> +Purpose: Hypercall used to wakeup a vcpu from HLT state
> +
> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> +kernel mode for an event to occur (ex: a spinlock to become available)
> +can execute HLT instruction once it has busy-waited for more than a
> +threshold time-interval. Execution of HLT instruction would cause
> +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
> +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
> +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
> +wokenup.

Wait, what happens with yield_on_hlt=0?  Will the hypercall work as
advertised?

> +
> +TODO:
> +1. more information on input and output needed?
> +2. Add more detail to purpose of hypercalls.
>


-- 
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 Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1RmkhZ-00018H-ON; Mon, 16 Jan 2012 11:26:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8IC-0002H8-6v
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:25:28 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326565519!7819031!1
X-Originating-IP: [32.97.110.150]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MCA9PiAxMDMwODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19666 invoked from network); 14 Jan 2012 18:25:20 -0000
Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:25:20 -0000
Received: from /spool/local
	by e32.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>; Sat, 14 Jan 2012 11:25:18 -0700
Received: from d03relay05.boulder.ibm.com (9.17.195.107)
	by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 11:25:16 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIPFrm037412
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 11:25:15 -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 q0EIPDNs025436
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 11:25:15 -0700
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIOwGk024309; Sat, 14 Jan 2012 11:25:01 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, X86 <x86@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Rob Landley <rlandley@parallels.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:55:02 +0530
Message-Id: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-3270-0000-0000-000003369F91
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 0/5] kvm : Paravirt-spinlock support for
	KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 5-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.

Changes in V4:
- reabsed to 3.2.0 pre.
- use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching. (Avi)
- fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
  changes for UNHALT path to make pv ticket spinlock migration friendly. (Avi, Marcello)
- Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
  and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
- Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
- cumulative variable type changed (int ==> u32) in add_stat (Konrad)
- remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case

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 (5): 
  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
  Add documentation on Hypercalls and features used for PV spinlock
 
Test Set up :
The BASE patch is pre 3.2.0 + Jeremy's following patches.
xadd (https://lkml.org/lkml/2011/10/4/328)
x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
Kernel for host/guest : 3.2.0 + Jeremy's xadd, pv spinlock patches as BASE
(Note:locked add change is not taken yet)

Results:
 The performance gain is mainly because of reduced busy-wait time.
 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 (non PLE).
 On PLE machine we do not see greater performance improvement because of PLE
 complimenting halt()

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

scenario B: unpinned, run kernbench on all the guests no hogs.

Dbench on PLE machine:
dbench run on all the guest simultaneously with
dbench --warmup=30 -t 120 with NRCLIENTS=(8/16/32).

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:	 164.233 (16.5506) 	 163.584 (15.4598 	0.39517
case 2x:	 897.654 (543.993) 	 328.63 (103.771) 	63.3901
case 3x:	 2855.73 (2201.41) 	 315.029 (111.854) 	88.9685

Dbench:
Throughput is in MB/sec
NRCLIENTS	 BASE                    BASE+patch            %improvement
               	 mean (sd)               mean (sd)
8       	1.774307  (0.061361) 	1.725667  (0.034644) 	-2.74135
16      	1.445967  (0.044805) 	1.463173  (0.094399) 	1.18993
32        	2.136667  (0.105717) 	2.193792  (0.129357) 	2.67356

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

Kernbench:
		 BASE                    BASE+patch            %improvement
		 mean (sd)               mean (sd)
Scenario A:	 			
case 1x:	 161.263 (56.518) 	 159.635 (40.5621) 	1.00953
case 2x:	 190.748 (61.2745) 	 190.606 (54.4766) 	0.0744438
case 3x:	 227.378 (100.215) 	 225.442 (92.0809) 	0.851446

Scenario B:
		 446.104 (58.54 )	 433.12733 (54.476)	2.91

Dbench:
Throughput is in MB/sec
NRCLIENTS	 BASE                    BASE+patch            %improvement
               	 mean (sd)               mean (sd)
8       	1.101190  (0.875082) 	1.700395  (0.846809) 	54.4143
16      	1.524312  (0.120354) 	1.477553  (0.058166) 	-3.06755
32        	2.143028  (0.157103) 	2.090307  (0.136778) 	-2.46012

---
 V3 kernel Changes:
 https://lkml.org/lkml/2011/11/30/62
 V2 kernel changes : 
 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
 
 Qemu patch for V3:
 http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00397.html

 Documentation/virtual/kvm/api.txt        |    7 +
 Documentation/virtual/kvm/cpuid.txt      |    4 +
 Documentation/virtual/kvm/hypercalls.txt |   54 +++++++
 arch/x86/Kconfig                         |    9 +
 arch/x86/include/asm/kvm_para.h          |   16 ++-
 arch/x86/kernel/kvm.c                    |  249 ++++++++++++++++++++++++++++++
 arch/x86/kvm/x86.c                       |   37 ++++-
 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                 |    1 +
 include/linux/kvm_para.h                 |    1 +
 15 files changed, 514 insertions(+), 114 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhg-0001DV-Sf; Mon, 16 Jan 2012 11:26:20 +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 1RmiRI-0005kq-NF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:01:16 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326704469!8503375!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30457 invoked from network); 16 Jan 2012 09:01:10 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 09:01:10 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0G90ofo022089
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 04:00:50 -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 q0G90fMn014729; Mon, 16 Jan 2012 04:00:42 -0500
Message-ID: <4F13E739.7040300@redhat.com>
Date: Mon, 16 Jan 2012 11:00:41 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/14/2012 08:27 PM, Raghavendra K T wrote:
> +
> +5. KVM_HC_KICK_CPU
> +------------------------
> +value: 5
> +Architecture: x86
> +Purpose: Hypercall used to wakeup a vcpu from HLT state
> +
> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> +kernel mode for an event to occur (ex: a spinlock to become available)
> +can execute HLT instruction once it has busy-waited for more than a
> +threshold time-interval. Execution of HLT instruction would cause
> +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
> +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
> +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
> +wokenup.

Wait, what happens with yield_on_hlt=0?  Will the hypercall work as
advertised?

> +
> +TODO:
> +1. more information on input and output needed?
> +2. Add more detail to purpose of hypercalls.
>


-- 
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 Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhc-00019C-51; Mon, 16 Jan 2012 11:26:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1Rmczs-00024Z-DB
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:12:36 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326683548!10952089!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22494 invoked from network); 16 Jan 2012 03:12:29 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 03:12:29 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id AA5628891E;
	Mon, 16 Jan 2012 04:12:26 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
Date: Mon, 16 Jan 2012 04:12:18 +0100
Message-Id: <62E14C21-4DF1-4C06-9CBB-FF36E4D49F64@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
	linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 14.01.2012, at 19:26, Raghavendra K T wrote:

> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks. 
> 
> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
> support for pv-ticketlocks is registered via pv_lock_ops.
> 
> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
> 
> 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 7a94987..cf5327c 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -195,10 +195,20 @@ 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)
> +
> 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..ec55a0b 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,250 @@ 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, u32 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 by its apicid*/
> +static inline void kvm_kick_cpu(int apicid)
> +{
> +	kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
> +}
> +
> +/* Kick vcpu waiting on @lock->head to reach value @ticket */
> +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
> +{
> +	int cpu;
> +	int apicid;
> +
> +	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);
> +			apicid = per_cpu(x86_cpu_to_apicid, cpu);
> +			kvm_kick_cpu(apicid);
> +			break;
> +		}
> +	}
> +}
> +
> +/*
> + * Setup pv_lock_ops to exploit KVM_FEATURE_PVLOCK_KICK if present.
> + */
> +void __init kvm_spinlock_init(void)
> +{
> +	if (!kvm_para_available())
> +		return;
> +	/* Does host kernel support KVM_FEATURE_PVLOCK_KICK? */
> +	if (!kvm_para_has_feature(KVM_FEATURE_PVLOCK_KICK))
> +		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/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c7b05fc..4d7a950 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c

This patch is mixing host and guest code. Please split those up.


Alex

> @@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> 
> 	local_irq_disable();
> 
> -	if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
> -	    || need_resched() || signal_pending(current)) {
> +	if (vcpu->mode == EXITING_GUEST_MODE
> +		 || (vcpu->requests & ~(1UL<<KVM_REQ_PVLOCK_KICK))
> +		 || need_resched() || signal_pending(current)) {
> 		vcpu->mode = OUTSIDE_GUEST_MODE;
> 		smp_wmb();
> 		local_irq_enable();
> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> 		!vcpu->arch.apf.halted)
> 		|| !list_empty_careful(&vcpu->async_pf.done)
> 		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> +		|| kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
> 		|| atomic_read(&vcpu->arch.nmi_queued) ||
> 		(kvm_arch_interrupt_allowed(vcpu) &&
> 		 kvm_cpu_has_interrupt(vcpu));
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhc-00019C-51; Mon, 16 Jan 2012 11:26:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1Rmczs-00024Z-DB
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:12:36 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326683548!10952089!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22494 invoked from network); 16 Jan 2012 03:12:29 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 03:12:29 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id AA5628891E;
	Mon, 16 Jan 2012 04:12:26 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
Date: Mon, 16 Jan 2012 04:12:18 +0100
Message-Id: <62E14C21-4DF1-4C06-9CBB-FF36E4D49F64@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
	linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 14.01.2012, at 19:26, Raghavendra K T wrote:

> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks. 
> 
> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
> support for pv-ticketlocks is registered via pv_lock_ops.
> 
> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
> 
> 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 7a94987..cf5327c 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -195,10 +195,20 @@ 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)
> +
> 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..ec55a0b 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,250 @@ 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, u32 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 by its apicid*/
> +static inline void kvm_kick_cpu(int apicid)
> +{
> +	kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
> +}
> +
> +/* Kick vcpu waiting on @lock->head to reach value @ticket */
> +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
> +{
> +	int cpu;
> +	int apicid;
> +
> +	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);
> +			apicid = per_cpu(x86_cpu_to_apicid, cpu);
> +			kvm_kick_cpu(apicid);
> +			break;
> +		}
> +	}
> +}
> +
> +/*
> + * Setup pv_lock_ops to exploit KVM_FEATURE_PVLOCK_KICK if present.
> + */
> +void __init kvm_spinlock_init(void)
> +{
> +	if (!kvm_para_available())
> +		return;
> +	/* Does host kernel support KVM_FEATURE_PVLOCK_KICK? */
> +	if (!kvm_para_has_feature(KVM_FEATURE_PVLOCK_KICK))
> +		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/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c7b05fc..4d7a950 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c

This patch is mixing host and guest code. Please split those up.


Alex

> @@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> 
> 	local_irq_disable();
> 
> -	if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
> -	    || need_resched() || signal_pending(current)) {
> +	if (vcpu->mode == EXITING_GUEST_MODE
> +		 || (vcpu->requests & ~(1UL<<KVM_REQ_PVLOCK_KICK))
> +		 || need_resched() || signal_pending(current)) {
> 		vcpu->mode = OUTSIDE_GUEST_MODE;
> 		smp_wmb();
> 		local_irq_enable();
> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
> 		!vcpu->arch.apf.halted)
> 		|| !list_empty_careful(&vcpu->async_pf.done)
> 		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> +		|| kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
> 		|| atomic_read(&vcpu->arch.nmi_queued) ||
> 		(kvm_arch_interrupt_allowed(vcpu) &&
> 		 kvm_cpu_has_interrupt(vcpu));
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhf-0001CA-MR; Mon, 16 Jan 2012 11:26:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmiBI-0005XC-KB
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:44:44 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326703440!48523752!1
X-Originating-IP: [202.81.31.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NyA9PiA1NzMwMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20093 invoked from network); 16 Jan 2012 08:44:03 -0000
Received: from e23smtp05.au.ibm.com (HELO e23smtp05.au.ibm.com) (202.81.31.147)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 08:44:03 -0000
Received: from /spool/local
	by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 08:41:36 +1000
Received: from d23relay05.au.ibm.com ([202.81.31.247])
	by e23smtp05.au.ibm.com ([202.81.31.211]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 08:41:34 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G8e0iZ2023474
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:40:00 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0G8iTXT008525
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:44:31 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0G8iOns008321; Mon, 16 Jan 2012 19:44:24 +1100
Message-ID: <4F13E36B.9020408@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 14:14:27 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
In-Reply-To: <AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
x-cbid: 12011522-1396-0000-0000-00000089D26A
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 08:53 AM, Alexander Graf wrote:
>
> On 14.01.2012, at 19:27, Raghavendra K T wrote:
>
>> Add Documentation on CPUID, KVM_CAP_PVLOCK_KICK, and Hypercalls supported.
>>
>> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in
>> paravirtual spinlock enabled guest.
>>
>> KVM_FEATURE_PVLOCK_KICK enables guest to check whether pv spinlock can
>> be enabled in guest. support in host is queried via
>> ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
>>
>> A minimal Documentation and template is added for hypercalls.
>>
>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>> ---
[...]
>> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
>> new file mode 100644
>> index 0000000..7872da5
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/hypercalls.txt
>> @@ -0,0 +1,54 @@
>> +KVM Hypercalls Documentation
>> +===========================

>> +2. KVM_HC_MMU_OP
>> +------------------------
>> +value: 2
>> +Architecture: x86
>> +Purpose: Support MMU operations such as writing to PTE,
>> +flushing TLB, release PT.
>
> This one is deprecated, no? Should probably be mentioned here.

Ok, then may be adding state = deprecated/obsolete/in use (active) may
be good idea.

>
>> +
>> +3. KVM_HC_FEATURES
>> +------------------------
>> +value: 3
>> +Architecture: PPC
>> +Purpose:
>
> Expose hypercall availability to the guest. On x86 you use cpuid to enumerate which hypercalls are available. The natural fit on ppc would be device tree based lookup (which is also what EPAPR dictates), but we also have a second enumeration mechanism that's KVM specific - which is this hypercall.
>

Thanks, will add this. I hope you are OK if I add Signed-off-by: you.

>> +
>> +4. KVM_HC_PPC_MAP_MAGIC_PAGE
>> +------------------------
>> +value: 4
>> +Architecture: PPC
>> +Purpose: To enable communication between the hypervisor and guest there is a
>> +new
>
> It's not new anymore :)
>
>> shared page that contains parts of supervisor visible register state.
>> +The guest can map this shared page using this hypercall.
>
> ... to access its supervisor register through memory.
>

Will update accordingly.

- Raghu


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhf-0001CA-MR; Mon, 16 Jan 2012 11:26:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmiBI-0005XC-KB
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:44:44 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326703440!48523752!1
X-Originating-IP: [202.81.31.147]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NyA9PiA1NzMwMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20093 invoked from network); 16 Jan 2012 08:44:03 -0000
Received: from e23smtp05.au.ibm.com (HELO e23smtp05.au.ibm.com) (202.81.31.147)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 08:44:03 -0000
Received: from /spool/local
	by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 08:41:36 +1000
Received: from d23relay05.au.ibm.com ([202.81.31.247])
	by e23smtp05.au.ibm.com ([202.81.31.211]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 08:41:34 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G8e0iZ2023474
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:40:00 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0G8iTXT008525
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:44:31 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0G8iOns008321; Mon, 16 Jan 2012 19:44:24 +1100
Message-ID: <4F13E36B.9020408@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 14:14:27 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
In-Reply-To: <AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
x-cbid: 12011522-1396-0000-0000-00000089D26A
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 08:53 AM, Alexander Graf wrote:
>
> On 14.01.2012, at 19:27, Raghavendra K T wrote:
>
>> Add Documentation on CPUID, KVM_CAP_PVLOCK_KICK, and Hypercalls supported.
>>
>> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in
>> paravirtual spinlock enabled guest.
>>
>> KVM_FEATURE_PVLOCK_KICK enables guest to check whether pv spinlock can
>> be enabled in guest. support in host is queried via
>> ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
>>
>> A minimal Documentation and template is added for hypercalls.
>>
>> Signed-off-by: Raghavendra K T<raghavendra.kt@linux.vnet.ibm.com>
>> Signed-off-by: Srivatsa Vaddagiri<vatsa@linux.vnet.ibm.com>
>> ---
[...]
>> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
>> new file mode 100644
>> index 0000000..7872da5
>> --- /dev/null
>> +++ b/Documentation/virtual/kvm/hypercalls.txt
>> @@ -0,0 +1,54 @@
>> +KVM Hypercalls Documentation
>> +===========================

>> +2. KVM_HC_MMU_OP
>> +------------------------
>> +value: 2
>> +Architecture: x86
>> +Purpose: Support MMU operations such as writing to PTE,
>> +flushing TLB, release PT.
>
> This one is deprecated, no? Should probably be mentioned here.

Ok, then may be adding state = deprecated/obsolete/in use (active) may
be good idea.

>
>> +
>> +3. KVM_HC_FEATURES
>> +------------------------
>> +value: 3
>> +Architecture: PPC
>> +Purpose:
>
> Expose hypercall availability to the guest. On x86 you use cpuid to enumerate which hypercalls are available. The natural fit on ppc would be device tree based lookup (which is also what EPAPR dictates), but we also have a second enumeration mechanism that's KVM specific - which is this hypercall.
>

Thanks, will add this. I hope you are OK if I add Signed-off-by: you.

>> +
>> +4. KVM_HC_PPC_MAP_MAGIC_PAGE
>> +------------------------
>> +value: 4
>> +Architecture: PPC
>> +Purpose: To enable communication between the hypervisor and guest there is a
>> +new
>
> It's not new anymore :)
>
>> shared page that contains parts of supervisor visible register state.
>> +The guest can map this shared page using this hypercall.
>
> ... to access its supervisor register through memory.
>

Will update accordingly.

- Raghu


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhh-0001Dx-8O; Mon, 16 Jan 2012 11:26:21 +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 1RmiTf-0005mr-N6
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:03:43 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326704616!8428030!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15182 invoked from network); 16 Jan 2012 09:03:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 09:03:37 -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 q0G93OjA022591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 04:03:24 -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 q0G93FnP003032; Mon, 16 Jan 2012 04:03:16 -0500
Message-ID: <4F13E7D3.1060004@redhat.com>
Date: Mon, 16 Jan 2012 11:03:15 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 2/5] 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 01/14/2012 08:25 PM, 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_PVLOCK_KICK/KVM_CAP_PVLOCK_KICK.
>
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.

No need to discuss qemu in a kernel patch.

>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
> +

The code that handles KVM_REQ_PVLOCK_KICK needs to be in this patch.


-- 
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 Jan 16 11:26:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhh-0001Dx-8O; Mon, 16 Jan 2012 11:26:21 +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 1RmiTf-0005mr-N6
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:03:43 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326704616!8428030!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15182 invoked from network); 16 Jan 2012 09:03:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 09:03:37 -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 q0G93OjA022591
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 04:03:24 -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 q0G93FnP003032; Mon, 16 Jan 2012 04:03:16 -0500
Message-ID: <4F13E7D3.1060004@redhat.com>
Date: Mon, 16 Jan 2012 11:03:15 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 2/5] 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 01/14/2012 08:25 PM, 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_PVLOCK_KICK/KVM_CAP_PVLOCK_KICK.
>
> Qemu needs a corresponding patch to pass up the presence of this feature to 
> guest via cpuid. Patch to qemu will be sent separately.

No need to discuss qemu in a kernel patch.

>  
> +/*
> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
> + *
> + * @apicid - apicid of vcpu to be kicked.
> + */
> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
> +{
> +	struct kvm_vcpu *vcpu = NULL;
> +	int i;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		if (!kvm_apic_present(vcpu))
> +			continue;
> +
> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
> +			break;
> +	}
> +	if (vcpu) {
> +		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
> +		kvm_vcpu_kick(vcpu);
> +	}
> +}
> +

The code that handles KVM_REQ_PVLOCK_KICK needs to be in this patch.


-- 
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 Jan 16 11:26:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhh-0001EP-Ju; Mon, 16 Jan 2012 11:26:21 +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 1RmiVk-0005oM-LQ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:05:52 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326704745!9286620!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25665 invoked from network); 16 Jan 2012 09:05:46 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 09:05:46 -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 q0G95Ppg022922
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 04:05:25 -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 q0G95GUM015815; Mon, 16 Jan 2012 04:05:17 -0500
Message-ID: <4F13E84C.3010808@redhat.com>
Date: Mon, 16 Jan 2012 11:05:16 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/14/2012 08:26 PM, Raghavendra K T wrote:
> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks. 
>
> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
>  support for pv-ticketlocks is registered via pv_lock_ops.
>
> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
> +
> +	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);
> +
>

Please drop all of these and replace with tracepoints in the appropriate
spots.  Everything else (including the historgram) can be reconstructed
the tracepoints in userspace.

-- 
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 Jan 16 11:26:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhh-0001EP-Ju; Mon, 16 Jan 2012 11:26:21 +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 1RmiVk-0005oM-LQ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:05:52 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326704745!9286620!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25665 invoked from network); 16 Jan 2012 09:05:46 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 09:05:46 -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 q0G95Ppg022922
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 04:05:25 -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 q0G95GUM015815; Mon, 16 Jan 2012 04:05:17 -0500
Message-ID: <4F13E84C.3010808@redhat.com>
Date: Mon, 16 Jan 2012 11:05:16 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/14/2012 08:26 PM, Raghavendra K T wrote:
> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks. 
>
> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
>  support for pv-ticketlocks is registered via pv_lock_ops.
>
> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
> +
> +	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);
> +
>

Please drop all of these and replace with tracepoints in the appropriate
spots.  Everything else (including the historgram) can be reconstructed
the tracepoints in userspace.

-- 
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 Jan 16 11:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhd-0001A6-CD; Mon, 16 Jan 2012 11:26:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rmdbx-0002KO-KK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:51:57 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326685869!60310491!1
X-Originating-IP: [32.97.110.158]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1OCA9PiA1MzIzMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31840 invoked from network); 16 Jan 2012 03:51:10 -0000
Received: from e37.co.us.ibm.com (HELO e37.co.us.ibm.com) (32.97.110.158)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 03:51:10 -0000
Received: from /spool/local
	by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Sun, 15 Jan 2012 20:51:49 -0700
Received: from d03relay02.boulder.ibm.com (9.17.195.227)
	by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sun, 15 Jan 2012 20:51:27 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G3pQZH139398
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:51:27 -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 q0G3pPoI004776
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:51:26 -0700
Received: from linux.vnet.ibm.com ([9.77.194.179])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0G3pEom003858; Sun, 15 Jan 2012 20:51:15 -0700
Date: Mon, 16 Jan 2012 09:21:14 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
Message-ID: <20120116035114.GI9129@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
x-cbid: 12011603-7408-0000-0000-000001E775C2
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Alexander Graf <agraf@suse.de> [2012-01-16 04:23:24]:

> > +5. KVM_HC_KICK_CPU
> > +------------------------
> > +value: 5
> > +Architecture: x86
> > +Purpose: Hypercall used to wakeup a vcpu from HLT state
> > +
> > +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> > +kernel mode for an event to occur (ex: a spinlock to become available)
> > +can execute HLT instruction once it has busy-waited for more than a
> > +threshold time-interval. Execution of HLT instruction would cause
> > +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
> > +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
> > +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
> > +wokenup.
> 
> The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu.

Hmm ..the hypercall does not allow a vcpu to yield. It just allows some
target vcpu to be prodded/wokenup, after which vcpu continues execution.

Note that semantics of this hypercall is different from the hypercall on which
PPC pv-spinlock (__spin_yield()) is currently dependent. This is mainly because 
of ticketlocks on x86 (which does not allow us to easily store owning cpu
details in lock word itself).

> The APIC piece is an implementation detail for x86. On PPC we could just use the PIR register contents (processor identifier).

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhe-0001BT-VA; Mon, 16 Jan 2012 11:26:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rmgwz-0003eC-P2
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 07:25:53 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326698703!48676862!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxMTE5MTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5246 invoked from network); 16 Jan 2012 07:25:06 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 07:25:06 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 07:11:13 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp04.au.ibm.com ([202.81.31.210]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 07:11:08 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G7KxDc3563650
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 18:21:01 +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
	q0G7PQV1031405
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 18:25:27 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0G7PLlH031276; Mon, 16 Jan 2012 18:25:21 +1100
Message-ID: <4F13D0E4.3050407@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 12:55:24 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<62E14C21-4DF1-4C06-9CBB-FF36E4D49F64@suse.de>
In-Reply-To: <62E14C21-4DF1-4C06-9CBB-FF36E4D49F64@suse.de>
x-cbid: 12011521-9264-0000-0000-000000A23D9F
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 08:42 AM, Alexander Graf wrote:
>
> On 14.01.2012, at 19:26, Raghavendra K T wrote:
>
>> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks.
>>
>> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
>> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
>> support for pv-ticketlocks is registered via pv_lock_ops.
>>
>> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
>>
>> 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 7a94987..cf5327c 100644
>> --- a/arch/x86/include/asm/kvm_para.h
>> +++ b/arch/x86/include/asm/kvm_para.h
>> @@ -195,10 +195,20 @@ void kvm_async_pf_task_wait(u32 token);
>> void kvm_async_pf_task_wake(u32 token);
[...]
>> +}
>> +#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index c7b05fc..4d7a950 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>
> This patch is mixing host and guest code. Please split those up.
>
>

Agree. The host code should have gone to patch 2.

> Alex
>
>> @@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1RmkhZ-00018A-Br; Mon, 16 Jan 2012 11:26:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <htejun@gmail.com>) id 1Rlldy-00027S-H0
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:14:26 +0000
X-Env-Sender: htejun@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326478458!9048225!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 30952 invoked from network); 13 Jan 2012 18:14:19 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 18:14:19 -0000
Received: by ggnh1 with SMTP id h1so23757769ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 10:14:17 -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=2/YC17p08O0m0ZIS5OwIZsERiIOIrtU8znWfoB2Qd3s=;
	b=bGrDPI9S/KuNG5vYkquL42rkMqV42zNNbNHRUqK8CXieeizp3hy3MVIKEOTLVp3Ymr
	pRY+z9SKDFFwMUOznrA1yQEWi7ezS+O3ACPkLf/5lcU6Netdew1bGxYNEwZZ+WlLAoEa
	YULtjpWbgT17fJJTeS2B40rgCayTIE4f24nn4=
Received: by 10.50.182.199 with SMTP id eg7mr760739igc.22.1326478457769;
	Fri, 13 Jan 2012 10:14:17 -0800 (PST)
Received: from google.com (wtj.mtv.corp.google.com [172.18.96.96])
	by mx.google.com with ESMTPS id l35sm31379097ibj.0.2012.01.13.10.14.15
	(version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 10:14:16 -0800 (PST)
Date: Fri, 13 Jan 2012 10:14:12 -0800
From: Tejun Heo <tj@kernel.org>
To: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120113181412.GA11112@google.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
	<20120110224537.GA6572@phenom.dumpdata.com>
	<20120110231552.GB26832@google.com>
	<20120111200435.GA8680@phenom.dumpdata.com>
	<20120113142703.GA7707@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120113142703.GA7707@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: rjw@sisk.pl, Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3.3-rc] memblock: Fix alloc failure due to dumb
 underflow protection in memblock_find_in_range_node()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

7bd0b0f0da "memblock: Reimplement memblock allocation using reverse
free area iterator" implemented simple top-down allocator using
reverse memblock iterator.  To avoid underflow in the allocator loop,
it simply raised the lower boundary to the requested size under the
assumption that requested size would be far smaller than available
memblocks.

This causes early page table allocation failure under certain
configurations.  Fix it by checking for underflow directly instead of
bumping up lower bound.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
LKML-Reference: <20120110202838.GA10402@phenom.dumpdata.com>
---
Sorry, I wrote the patch description and everything but forgot to
actually send it out. :)

Ingo, the new memblock allocator went too far with simplification and
caused unnecessary allocation failure.  The fix is fairly obvious and
simple.  Can you please route this patch?

Thanks.

 mm/memblock.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 2f55f19..77b5f22 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -106,14 +106,17 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
 	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
 		end = memblock.current_limit;
 
-	/* adjust @start to avoid underflow and allocating the first page */
-	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
+	/* avoid allocating the first page */
+	start = max_t(phys_addr_t, start, PAGE_SIZE);
 	end = max(start, end);
 
 	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
 		this_start = clamp(this_start, start, end);
 		this_end = clamp(this_end, start, end);
 
+		if (this_end < size)
+			continue;
+
 		cand = round_down(this_end - size, align);
 		if (cand >= this_start)
 			return cand;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1RmkhZ-00018A-Br; Mon, 16 Jan 2012 11:26:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <htejun@gmail.com>) id 1Rlldy-00027S-H0
	for xen-devel@lists.xensource.com; Fri, 13 Jan 2012 18:14:26 +0000
X-Env-Sender: htejun@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326478458!9048225!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 30952 invoked from network); 13 Jan 2012 18:14:19 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	13 Jan 2012 18:14:19 -0000
Received: by ggnh1 with SMTP id h1so23757769ggn.30
	for <xen-devel@lists.xensource.com>;
	Fri, 13 Jan 2012 10:14:17 -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=2/YC17p08O0m0ZIS5OwIZsERiIOIrtU8znWfoB2Qd3s=;
	b=bGrDPI9S/KuNG5vYkquL42rkMqV42zNNbNHRUqK8CXieeizp3hy3MVIKEOTLVp3Ymr
	pRY+z9SKDFFwMUOznrA1yQEWi7ezS+O3ACPkLf/5lcU6Netdew1bGxYNEwZZ+WlLAoEa
	YULtjpWbgT17fJJTeS2B40rgCayTIE4f24nn4=
Received: by 10.50.182.199 with SMTP id eg7mr760739igc.22.1326478457769;
	Fri, 13 Jan 2012 10:14:17 -0800 (PST)
Received: from google.com (wtj.mtv.corp.google.com [172.18.96.96])
	by mx.google.com with ESMTPS id l35sm31379097ibj.0.2012.01.13.10.14.15
	(version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 10:14:16 -0800 (PST)
Date: Fri, 13 Jan 2012 10:14:12 -0800
From: Tejun Heo <tj@kernel.org>
To: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Message-ID: <20120113181412.GA11112@google.com>
References: <20120110202838.GA10402@phenom.dumpdata.com>
	<20120110222625.GA26832@google.com>
	<20120110224537.GA6572@phenom.dumpdata.com>
	<20120110231552.GB26832@google.com>
	<20120111200435.GA8680@phenom.dumpdata.com>
	<20120113142703.GA7707@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120113142703.GA7707@phenom.dumpdata.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: rjw@sisk.pl, Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 3.3-rc] memblock: Fix alloc failure due to dumb
 underflow protection in memblock_find_in_range_node()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

7bd0b0f0da "memblock: Reimplement memblock allocation using reverse
free area iterator" implemented simple top-down allocator using
reverse memblock iterator.  To avoid underflow in the allocator loop,
it simply raised the lower boundary to the requested size under the
assumption that requested size would be far smaller than available
memblocks.

This causes early page table allocation failure under certain
configurations.  Fix it by checking for underflow directly instead of
bumping up lower bound.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
LKML-Reference: <20120110202838.GA10402@phenom.dumpdata.com>
---
Sorry, I wrote the patch description and everything but forgot to
actually send it out. :)

Ingo, the new memblock allocator went too far with simplification and
caused unnecessary allocation failure.  The fix is fairly obvious and
simple.  Can you please route this patch?

Thanks.

 mm/memblock.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 2f55f19..77b5f22 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -106,14 +106,17 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t start,
 	if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
 		end = memblock.current_limit;
 
-	/* adjust @start to avoid underflow and allocating the first page */
-	start = max3(start, size, (phys_addr_t)PAGE_SIZE);
+	/* avoid allocating the first page */
+	start = max_t(phys_addr_t, start, PAGE_SIZE);
 	end = max(start, end);
 
 	for_each_free_mem_range_reverse(i, nid, &this_start, &this_end, NULL) {
 		this_start = clamp(this_start, start, end);
 		this_end = clamp(this_end, start, end);
 
+		if (this_end < size)
+			continue;
+
 		cand = round_down(this_end - size, align);
 		if (cand >= this_start)
 			return cand;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhd-0001A6-CD; Mon, 16 Jan 2012 11:26:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rmdbx-0002KO-KK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:51:57 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326685869!60310491!1
X-Originating-IP: [32.97.110.158]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1OCA9PiA1MzIzMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31840 invoked from network); 16 Jan 2012 03:51:10 -0000
Received: from e37.co.us.ibm.com (HELO e37.co.us.ibm.com) (32.97.110.158)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 03:51:10 -0000
Received: from /spool/local
	by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Sun, 15 Jan 2012 20:51:49 -0700
Received: from d03relay02.boulder.ibm.com (9.17.195.227)
	by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sun, 15 Jan 2012 20:51:27 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G3pQZH139398
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:51:27 -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 q0G3pPoI004776
	for <xen-devel@lists.xensource.com>; Sun, 15 Jan 2012 20:51:26 -0700
Received: from linux.vnet.ibm.com ([9.77.194.179])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0G3pEom003858; Sun, 15 Jan 2012 20:51:15 -0700
Date: Mon, 16 Jan 2012 09:21:14 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
Message-ID: <20120116035114.GI9129@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
x-cbid: 12011603-7408-0000-0000-000001E775C2
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Alexander Graf <agraf@suse.de> [2012-01-16 04:23:24]:

> > +5. KVM_HC_KICK_CPU
> > +------------------------
> > +value: 5
> > +Architecture: x86
> > +Purpose: Hypercall used to wakeup a vcpu from HLT state
> > +
> > +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> > +kernel mode for an event to occur (ex: a spinlock to become available)
> > +can execute HLT instruction once it has busy-waited for more than a
> > +threshold time-interval. Execution of HLT instruction would cause
> > +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
> > +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
> > +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
> > +wokenup.
> 
> The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu.

Hmm ..the hypercall does not allow a vcpu to yield. It just allows some
target vcpu to be prodded/wokenup, after which vcpu continues execution.

Note that semantics of this hypercall is different from the hypercall on which
PPC pv-spinlock (__spin_yield()) is currently dependent. This is mainly because 
of ticketlocks on x86 (which does not allow us to easily store owning cpu
details in lock word itself).

> The APIC piece is an implementation detail for x86. On PPC we could just use the PIR register contents (processor identifier).

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhe-0001BT-VA; Mon, 16 Jan 2012 11:26:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rmgwz-0003eC-P2
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 07:25:53 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326698703!48676862!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxMTE5MTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5246 invoked from network); 16 Jan 2012 07:25:06 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 07:25:06 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 07:11:13 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp04.au.ibm.com ([202.81.31.210]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 07:11:08 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G7KxDc3563650
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 18:21:01 +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
	q0G7PQV1031405
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 18:25:27 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0G7PLlH031276; Mon, 16 Jan 2012 18:25:21 +1100
Message-ID: <4F13D0E4.3050407@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 12:55:24 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<62E14C21-4DF1-4C06-9CBB-FF36E4D49F64@suse.de>
In-Reply-To: <62E14C21-4DF1-4C06-9CBB-FF36E4D49F64@suse.de>
x-cbid: 12011521-9264-0000-0000-000000A23D9F
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 08:42 AM, Alexander Graf wrote:
>
> On 14.01.2012, at 19:26, Raghavendra K T wrote:
>
>> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks.
>>
>> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
>> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
>> support for pv-ticketlocks is registered via pv_lock_ops.
>>
>> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
>>
>> 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 7a94987..cf5327c 100644
>> --- a/arch/x86/include/asm/kvm_para.h
>> +++ b/arch/x86/include/asm/kvm_para.h
>> @@ -195,10 +195,20 @@ void kvm_async_pf_task_wait(u32 token);
>> void kvm_async_pf_task_wake(u32 token);
[...]
>> +}
>> +#endif	/* CONFIG_PARAVIRT_SPINLOCKS */
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index c7b05fc..4d7a950 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>
> This patch is mixing host and guest code. Please split those up.
>
>

Agree. The host code should have gone to patch 2.

> Alex
>
>> @@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhc-00019V-IU; Mon, 16 Jan 2012 11:26:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmdAV-0002B7-Oh
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:23:36 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326684208!11088306!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18861 invoked from network); 16 Jan 2012 03:23:29 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Jan 2012 03:23:29 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 7E2B18FA98;
	Mon, 16 Jan 2012 04:23:27 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
Date: Mon, 16 Jan 2012 04:23:24 +0100
Message-Id: <AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 19:27, Raghavendra K T wrote:

> Add Documentation on CPUID, KVM_CAP_PVLOCK_KICK, and Hypercalls supported.
> 
> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in
> paravirtual spinlock enabled guest.
> 
> KVM_FEATURE_PVLOCK_KICK enables guest to check whether pv spinlock can
> be enabled in guest. support in host is queried via
> ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
> 
> A minimal Documentation and template is added for hypercalls.
> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> ---
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index e2a4b52..1583bc7 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1109,6 +1109,13 @@ support.  Instead it is reported via
> if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
> feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
> 
> +Paravirtualized ticket spinlocks can be enabled in guest by checking whether
> +support exists in host via,
> +
> +  ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
> +
> +if this call return true, guest can use the feature.
> +
> 4.47 KVM_PPC_GET_PVINFO
> 
> Capability: KVM_CAP_PPC_GET_PVINFO
> diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
> index 8820685..c7fc0da 100644
> --- a/Documentation/virtual/kvm/cpuid.txt
> +++ b/Documentation/virtual/kvm/cpuid.txt
> @@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
> KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
>                                    ||       || writing to msr 0x4b564d02
> ------------------------------------------------------------------------------
> +KVM_FEATURE_PVLOCK_KICK            ||     6 || guest checks this feature bit
> +                                   ||       || before enabling paravirtualized
> +                                   ||       || spinlock support.
> +------------------------------------------------------------------------------
> KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
>                                    ||       || per-cpu warps are expected in
>                                    ||       || kvmclock.
> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
> new file mode 100644
> index 0000000..7872da5
> --- /dev/null
> +++ b/Documentation/virtual/kvm/hypercalls.txt
> @@ -0,0 +1,54 @@
> +KVM Hypercalls Documentation
> +===========================
> +Template for documentation is
> +The documenenation for hypercalls should inlcude
> +1. Hypercall name, value.
> +2. Architecture(s)
> +3. Purpose
> +
> +
> +1. KVM_HC_VAPIC_POLL_IRQ
> +------------------------
> +value: 1
> +Architecture: x86
> +Purpose:
> +
> +2. KVM_HC_MMU_OP
> +------------------------
> +value: 2
> +Architecture: x86
> +Purpose: Support MMU operations such as writing to PTE,
> +flushing TLB, release PT.

This one is deprecated, no? Should probably be mentioned here.

> +
> +3. KVM_HC_FEATURES
> +------------------------
> +value: 3
> +Architecture: PPC
> +Purpose:

Expose hypercall availability to the guest. On x86 you use cpuid to enumerate which hypercalls are available. The natural fit on ppc would be device tree based lookup (which is also what EPAPR dictates), but we also have a second enumeration mechanism that's KVM specific - which is this hypercall.

> +
> +4. KVM_HC_PPC_MAP_MAGIC_PAGE
> +------------------------
> +value: 4
> +Architecture: PPC
> +Purpose: To enable communication between the hypervisor and guest there is a
> +new

It's not new anymore :)

> shared page that contains parts of supervisor visible register state.
> +The guest can map this shared page using this hypercall.

... to access its supervisor register through memory.

> +
> +5. KVM_HC_KICK_CPU
> +------------------------
> +value: 5
> +Architecture: x86
> +Purpose: Hypercall used to wakeup a vcpu from HLT state
> +
> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> +kernel mode for an event to occur (ex: a spinlock to become available)
> +can execute HLT instruction once it has busy-waited for more than a
> +threshold time-interval. Execution of HLT instruction would cause
> +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
> +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
> +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
> +wokenup.

The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu. The APIC piece is an implementation detail for x86. On PPC we could just use the PIR register contents (processor identifier).

Maybe I didn't fully understand what this really is about though :)


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhc-00019V-IU; Mon, 16 Jan 2012 11:26:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmdAV-0002B7-Oh
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:23:36 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326684208!11088306!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18861 invoked from network); 16 Jan 2012 03:23:29 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Jan 2012 03:23:29 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 7E2B18FA98;
	Mon, 16 Jan 2012 04:23:27 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
Date: Mon, 16 Jan 2012 04:23:24 +0100
Message-Id: <AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 19:27, Raghavendra K T wrote:

> Add Documentation on CPUID, KVM_CAP_PVLOCK_KICK, and Hypercalls supported.
> 
> KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in
> paravirtual spinlock enabled guest.
> 
> KVM_FEATURE_PVLOCK_KICK enables guest to check whether pv spinlock can
> be enabled in guest. support in host is queried via
> ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
> 
> A minimal Documentation and template is added for hypercalls.
> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> ---
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index e2a4b52..1583bc7 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1109,6 +1109,13 @@ support.  Instead it is reported via
> if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
> feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
> 
> +Paravirtualized ticket spinlocks can be enabled in guest by checking whether
> +support exists in host via,
> +
> +  ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
> +
> +if this call return true, guest can use the feature.
> +
> 4.47 KVM_PPC_GET_PVINFO
> 
> Capability: KVM_CAP_PPC_GET_PVINFO
> diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
> index 8820685..c7fc0da 100644
> --- a/Documentation/virtual/kvm/cpuid.txt
> +++ b/Documentation/virtual/kvm/cpuid.txt
> @@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
> KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
>                                    ||       || writing to msr 0x4b564d02
> ------------------------------------------------------------------------------
> +KVM_FEATURE_PVLOCK_KICK            ||     6 || guest checks this feature bit
> +                                   ||       || before enabling paravirtualized
> +                                   ||       || spinlock support.
> +------------------------------------------------------------------------------
> KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
>                                    ||       || per-cpu warps are expected in
>                                    ||       || kvmclock.
> diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
> new file mode 100644
> index 0000000..7872da5
> --- /dev/null
> +++ b/Documentation/virtual/kvm/hypercalls.txt
> @@ -0,0 +1,54 @@
> +KVM Hypercalls Documentation
> +===========================
> +Template for documentation is
> +The documenenation for hypercalls should inlcude
> +1. Hypercall name, value.
> +2. Architecture(s)
> +3. Purpose
> +
> +
> +1. KVM_HC_VAPIC_POLL_IRQ
> +------------------------
> +value: 1
> +Architecture: x86
> +Purpose:
> +
> +2. KVM_HC_MMU_OP
> +------------------------
> +value: 2
> +Architecture: x86
> +Purpose: Support MMU operations such as writing to PTE,
> +flushing TLB, release PT.

This one is deprecated, no? Should probably be mentioned here.

> +
> +3. KVM_HC_FEATURES
> +------------------------
> +value: 3
> +Architecture: PPC
> +Purpose:

Expose hypercall availability to the guest. On x86 you use cpuid to enumerate which hypercalls are available. The natural fit on ppc would be device tree based lookup (which is also what EPAPR dictates), but we also have a second enumeration mechanism that's KVM specific - which is this hypercall.

> +
> +4. KVM_HC_PPC_MAP_MAGIC_PAGE
> +------------------------
> +value: 4
> +Architecture: PPC
> +Purpose: To enable communication between the hypervisor and guest there is a
> +new

It's not new anymore :)

> shared page that contains parts of supervisor visible register state.
> +The guest can map this shared page using this hypercall.

... to access its supervisor register through memory.

> +
> +5. KVM_HC_KICK_CPU
> +------------------------
> +value: 5
> +Architecture: x86
> +Purpose: Hypercall used to wakeup a vcpu from HLT state
> +
> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> +kernel mode for an event to occur (ex: a spinlock to become available)
> +can execute HLT instruction once it has busy-waited for more than a
> +threshold time-interval. Execution of HLT instruction would cause
> +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
> +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
> +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
> +wokenup.

The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu. The APIC piece is an implementation detail for x86. On PPC we could just use the PIR register contents (processor identifier).

Maybe I didn't fully understand what this really is about though :)


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkha-00018V-HH; Mon, 16 Jan 2012 11:26:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8JB-0002Im-Fh
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:26:29 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326565537!50603797!1
X-Originating-IP: [32.97.182.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NiA9PiA1MjM5MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23190 invoked from network); 14 Jan 2012 18:25:38 -0000
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:25:38 -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>; Sat, 14 Jan 2012 13:26:21 -0500
Received: from d01relay04.pok.ibm.com (9.56.227.236)
	by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:26:09 -0500
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIQ8AI292742
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:26:08 -0500
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q0EIQ5bt032245
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 11:26:07 -0700
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIPplt031548; Sat, 14 Jan 2012 11:25:53 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, X86 <x86@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Rob Landley <rlandley@parallels.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:55:54 +0530
Message-Id: <20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-1976-0000-0000-00000980BF57
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 2/5] 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_PVLOCK_KICK/KVM_CAP_PVLOCK_KICK.

Qemu needs a corresponding patch to pass up the presence of this feature to 
guest via cpuid. Patch to qemu will be sent separately.

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..7a94987 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_PVLOCK_KICK		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 4c938da..c7b05fc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2099,6 +2099,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_PVLOCK_KICK:
 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:
@@ -2576,7 +2577,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_PVLOCK_KICK);
 
 		if (sched_info_on())
 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
@@ -5304,6 +5306,29 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+/*
+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
+ *
+ * @apicid - apicid of vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
+{
+	struct kvm_vcpu *vcpu = NULL;
+	int i;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		if (!kvm_apic_present(vcpu))
+			continue;
+
+		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
+			break;
+	}
+	if (vcpu) {
+		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
+		kvm_vcpu_kick(vcpu);
+	}
+}
+
 int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 {
 	unsigned long nr, a0, a1, a2, a3, ret;
@@ -5340,6 +5365,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 68e67e5..63fb6b0 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_PAPR 68
 #define KVM_CAP_S390_GMAP 71
 #define KVM_CAP_TSC_DEADLINE_TIMER 72
+#define KVM_CAP_PVLOCK_KICK 73
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d526231..3b1ae7b 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -50,6 +50,7 @@
 #define KVM_REQ_APF_HALT          12
 #define KVM_REQ_STEAL_UPDATE      13
 #define KVM_REQ_NMI               14
+#define KVM_REQ_PVLOCK_KICK       15
 
 #define KVM_USERSPACE_IRQ_SOURCE_ID	0
 
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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkha-00018V-HH; Mon, 16 Jan 2012 11:26:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8JB-0002Im-Fh
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:26:29 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326565537!50603797!1
X-Originating-IP: [32.97.182.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NiA9PiA1MjM5MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23190 invoked from network); 14 Jan 2012 18:25:38 -0000
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:25:38 -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>; Sat, 14 Jan 2012 13:26:21 -0500
Received: from d01relay04.pok.ibm.com (9.56.227.236)
	by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:26:09 -0500
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIQ8AI292742
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:26:08 -0500
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q0EIQ5bt032245
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 11:26:07 -0700
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIPplt031548; Sat, 14 Jan 2012 11:25:53 -0700
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, X86 <x86@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Rob Landley <rlandley@parallels.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:55:54 +0530
Message-Id: <20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-1976-0000-0000-00000980BF57
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 2/5] 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_PVLOCK_KICK/KVM_CAP_PVLOCK_KICK.

Qemu needs a corresponding patch to pass up the presence of this feature to 
guest via cpuid. Patch to qemu will be sent separately.

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..7a94987 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_PVLOCK_KICK		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 4c938da..c7b05fc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2099,6 +2099,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_PVLOCK_KICK:
 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:
@@ -2576,7 +2577,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_PVLOCK_KICK);
 
 		if (sched_info_on())
 			entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
@@ -5304,6 +5306,29 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+/*
+ * kvm_pv_kick_cpu_op:  Kick a vcpu.
+ *
+ * @apicid - apicid of vcpu to be kicked.
+ */
+static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
+{
+	struct kvm_vcpu *vcpu = NULL;
+	int i;
+
+	kvm_for_each_vcpu(i, vcpu, kvm) {
+		if (!kvm_apic_present(vcpu))
+			continue;
+
+		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
+			break;
+	}
+	if (vcpu) {
+		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
+		kvm_vcpu_kick(vcpu);
+	}
+}
+
 int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
 {
 	unsigned long nr, a0, a1, a2, a3, ret;
@@ -5340,6 +5365,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 68e67e5..63fb6b0 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_PAPR 68
 #define KVM_CAP_S390_GMAP 71
 #define KVM_CAP_TSC_DEADLINE_TIMER 72
+#define KVM_CAP_PVLOCK_KICK 73
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d526231..3b1ae7b 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -50,6 +50,7 @@
 #define KVM_REQ_APF_HALT          12
 #define KVM_REQ_STEAL_UPDATE      13
 #define KVM_REQ_NMI               14
+#define KVM_REQ_PVLOCK_KICK       15
 
 #define KVM_USERSPACE_IRQ_SOURCE_ID	0
 
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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhe-0001Ai-6Z; Mon, 16 Jan 2012 11:26:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmdkP-0002PZ-OL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 04:00:41 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326686434!8473657!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2513 invoked from network); 16 Jan 2012 04:00:35 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 04:00:35 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 0107189471;
	Mon, 16 Jan 2012 05:00:34 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120116035114.GI9129@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 05:00:31 +0100
Message-Id: <5E0038B3-3830-4668-B4BB-781976710ED1@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
	<20120116035114.GI9129@linux.vnet.ibm.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 04:51, Srivatsa Vaddagiri wrote:

> * Alexander Graf <agraf@suse.de> [2012-01-16 04:23:24]:
> 
>>> +5. KVM_HC_KICK_CPU
>>> +------------------------
>>> +value: 5
>>> +Architecture: x86
>>> +Purpose: Hypercall used to wakeup a vcpu from HLT state
>>> +
>>> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
>>> +kernel mode for an event to occur (ex: a spinlock to become available)
>>> +can execute HLT instruction once it has busy-waited for more than a
>>> +threshold time-interval. Execution of HLT instruction would cause
>>> +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
>>> +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
>>> +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
>>> +wokenup.
>> 
>> The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu.
> 
> Hmm ..the hypercall does not allow a vcpu to yield. It just allows some
> target vcpu to be prodded/wokenup, after which vcpu continues execution.
> 
> Note that semantics of this hypercall is different from the hypercall on which
> PPC pv-spinlock (__spin_yield()) is currently dependent. This is mainly because 
> of ticketlocks on x86 (which does not allow us to easily store owning cpu
> details in lock word itself).

Yes, sorry for not being more exact in my wording. It is a directed yield(). Not like the normal old style thing that just says "I'm done, get some work to someone else" but more something like "I'm done, get some work to this specific guy over there" :).


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1RmkhY-000183-NU; Mon, 16 Jan 2012 11:26:12 +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 1RkvGe-0007Zl-VJ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 10:18:54 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326277126!7878092!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8984 invoked from network); 11 Jan 2012 10:18:46 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 10:18:46 -0000
Received: by wibhq7 with SMTP id hq7so659313wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 02:18: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:user-agent:date:from:to:cc;
	bh=8fp/jyGmncNMTx9RfyA6i2VQElLshTHKQ9x/sXrKDxk=;
	b=MEIlfFJ0Wqzw1fdB9EZw9o3OElfLoN2OTkT+J3fVUEagmGDD00kLVPQSeFd/yszPUy
	gV2xnV1OADIXtDqLr/nxV6h3foYx703YzmIwqz+JoWi7XisBBsmRcMyMHoAWYKK5eBwt
	ixulhu22nFLd4S7YVws+qcA1+4Nzj1SEBPRlg=
Received: by 10.180.106.130 with SMTP id gu2mr18229836wib.6.1326277125506;
	Wed, 11 Jan 2012 02:18:45 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id 8sm3933621wiw.4.2012.01.11.02.18.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Jan 2012 02:18:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d665d94dab0f2788fe431ee13343e3b78b323b11
Message-Id: <d665d94dab0f2788fe43.1326219720@build.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 19:22:00 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v3] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI2MjE5MTgxIC0zNjAwCiMgTm9kZSBJRCBkNjY1ZDk0ZGFi
MGYyNzg4ZmU0MzFlZTEzMzQzZTNiNzhiMzIzYjExCiMgUGFyZW50ICA0MDg2ZTQ4MTE1NDdkZGZm
YjlhNTNmYmYyZWZiNmMyZmE0MzZiNzBhCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwKY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5j
bHVkZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25z
IHByZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3Np
bmcKcGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVj
dXRpbmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIHN0aWxsIG5vdCB1c2VkIGFueXdo
ZXJlLCBhbmQgaXMgYXV0b21hdGljYWxseSBjcmVhdGVkIGJ5CmF1dG9oZWFkZXIsIGFsdG91Z2gg
dGhpcyBtaWdoIGNoYW5nZSB3aGVuIHdlIHN0YXJ0IHRvIGluY2x1ZGUgdGhpcwpmaWxlLgoKSnVz
dCBhIGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlw
dCBJIGd1ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxl
YXNlIHJldmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjI6CgogKiBDaGFuZ2VkIG9y
ZGVyIG9mIGNvbmZpZy9Ub29scy5tayBpbmNsdWRlLgoKICogQWRkZWQgIi1lIiB0byBhdXRvZ2Vu
LnNoIHNoZWJhbmcuCgogKiBBZGRlZCBuZWNlc3NhcnkgZmlsZXMgKGNvbmZpZy4qKSBhbmQgb3V0
cHV0IGZyb20gQXV0b2hlYWRlciBhbmQKICAgQXV0b2NvbmYuCgogKiBSZW1vdmVkIEF1dG9jb25m
IGZyb20gYnVpbGQgZGVwZW5kZW5jaWVzIGFuZCB1cGRhdGVkIFJFQURNRS4KCkNoYW5nZXMgc2lu
Y2UgdjE6CgogKiBNb3ZlZCBhdXRvY29uZiBzdHVmZiBpbnNpZGUgdG9vbHMgZm9sZGVyLgoKICog
QWRkIE1ha2VmaWxlIHJ1bGVzIGZvciBjbGVhbmluZy4KCiAqIFJlbW92ZWQgQXV0b21ha2UgZGVw
ZW5kZW5jeS4KCiAqIENyZWF0ZSBhdXRvZ2VuLnNoIHRvIGF1dG9tYXRpY2FsbHkgY3JlYXRlIGNv
bmZpZ3VyZSBzY3JpcHQgd2hlbgogICBidWlsZGluZyBmcm9tIHNvdXJjZSByZXBvc2l0b3J5LgoK
ICogQ2FjaGVkIHZhbHVlcyBvZiBvcHRpb25zIHBhc3NlZCBmcm9tIGNvbW1hbmQgbGluZS4KCiAq
IEFkZCBuZWNlc3NhcnkgaWdub3JlcyB0byAuaGdpZ25vcmUuCgogKiBBZGRlZCBBdXRvY29uZiB0
byB0aGUgbGlzdCBvZiBkZXBlbmRlbmNpZXMuCgogKiBDaGFuZ2VkIGh5cGVuIHRvIHVuZGVyc2Nv
cmUgaW4gWE1MMiBhbmQgQ1VSTCB2YXJpYWJsZSBuYW1lcy4KCiAqIEFkZGVkIHNjcmlwdCB0byBn
ZXQgdmVyc2lvbiBmcm9tIHhlbi9NYWtlZmlsZS4KCiAqIFNldCBPY2FtbCB0b29scyB0byBvcHRp
b25hbC4KCiAqIEFkZGVkIHByb2NlZGVuY2Ugb2YgbTQvb2NhbWwubTQuCgpTaWduZWQtb2ZmLWJ5
OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PgoKZGlmZiAtciA0MDg2
ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIC5oZ2lnbm9yZQotLS0gYS8uaGdpZ25vcmUJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiLy5oZ2lnbm9yZQlUdWUgSmFuIDEwIDE5OjEz
OjAxIDIwMTIgKzAxMDAKQEAgLTMwOCw2ICszMDgsMTIgQEAKIF50b29scy9vY2FtbC9saWJzL3hs
L3hlbmxpZ2h0XC5tbCQKIF50b29scy9vY2FtbC9saWJzL3hsL3hlbmxpZ2h0XC5tbGkkCiBedG9v
bHMvb2NhbWwveGVuc3RvcmVkL294ZW5zdG9yZWQkCitedG9vbHMvYXV0b200dGVcLmNhY2hlJAor
XnRvb2xzL2NvbmZpZ1wuaCQKK150b29scy9jb25maWdcLmxvZyQKK150b29scy9jb25maWdcLnN0
YXR1cyQKK150b29scy9jb25maWdcLmNhY2hlJAorXmNvbmZpZy9Ub29sc1wubWskCiBeeGVuL1wu
YmFubmVyLiokCiBeeGVuL0JMT0ckCiBeeGVuL1N5c3RlbS5tYXAkCmRpZmYgLXIgNDA4NmU0ODEx
NTQ3IC1yIGQ2NjVkOTRkYWIwZiBDb25maWcubWsKLS0tIGEvQ29uZmlnLm1rCVRodSBKYW4gMDUg
MTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi9Db25maWcubWsJVHVlIEphbiAxMCAxOToxMzowMSAy
MDEyICswMTAwCkBAIC03MCw5ICs3MCw2IEBAIEVYVFJBX0lOQ0xVREVTICs9ICQoRVhUUkFfUFJF
RklYKS9pbmNsdWQKIEVYVFJBX0xJQiArPSAkKEVYVFJBX1BSRUZJWCkvJChMSUJMRUFGRElSKQog
ZW5kaWYKIAotQklTT04JPz0gYmlzb24KLUZMRVgJPz0gZmxleAotCiBQWVRIT04gICAgICA/PSBw
eXRob24KIFBZVEhPTl9QUkVGSVhfQVJHID89IC0tcHJlZml4PSIkKFBSRUZJWCkiCiAjIFRoZSBh
Ym92ZSByZXF1aXJlcyB0aGF0IFBSRUZJWCBjb250YWlucyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJp
YWJsZSBpcyBoZXJlCkBAIC0xNzUsMjIgKzE3Miw5IEBAIENGTEFHUyArPSAkKGZvcmVhY2ggaSwg
JChQUkVQRU5EX0lOQ0xVREUKIEFQUEVORF9MREZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVO
RF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRfQ0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9J
TkNMVURFUyksIC1JJChpKSkKIAotQ0hFQ0tfTElCID0gJChFWFRSQV9MSUIpICQoUFJFUEVORF9M
SUIpICQoQVBQRU5EX0xJQikKLUNIRUNLX0lOQ0xVREVTID0gJChFWFRSQV9JTkNMVURFUykgJChQ
UkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVORF9JTkNMVURFUykKLQogRU1CRURERURfRVhUUkFfQ0ZM
QUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLXN0YWNrLXByb3RlY3Rvci1h
bGwKIEVNQkVEREVEX0VYVFJBX0NGTEFHUyArPSAtZm5vLWV4Y2VwdGlvbnMKIAotIyBFbmFibGUg
WFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2spLgotWFNNX0VOQUJMRSA/PSBu
Ci1GTEFTS19FTkFCTEUgPz0gJChYU01fRU5BQkxFKQotCi0jIERvd25sb2FkIEdJVCByZXBvc2l0
b3JpZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3duIHByb3RvY29sPwotIyBHSVQncyBwcm90b2NvbCBp
cyBmYXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxz
Ci0jIG1heSBibG9jayBpdCkuIFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJ
VCByZXBvc2l0b3J5IGRvd25sb2FkcwotIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJ
VF9IVFRQPXkgaW4geW91ciBlbnZpcm9ubWVudC4KLUdJVF9IVFRQID89IG4KLQogWEVOX0VYVEZJ
TEVTX1VSTD1odHRwOi8veGVuYml0cy54ZW5zb3VyY2UuY29tL3hlbi1leHRmaWxlcwogIyBBbGwg
dGhlIGZpbGVzIGF0IHRoYXQgbG9jYXRpb24gd2VyZSBkb3dubG9hZGVkIGZyb20gZWxzZXdoZXJl
IG9uCiAjIHRoZSBpbnRlcm5ldC4gIFRoZSBvcmlnaW5hbCBkb3dubG9hZCBVUkwgaXMgcHJlc2Vy
dmVkIGFzIGEgY29tbWVudApAQCAtMjIyLDE3ICsyMDYsMyBAQCBRRU1VX1RBRyA/PSBiYjM2ZDYz
MmU0Y2FiZjQ3ODgyYWRmZjA3YTQ1CiAjIE5vdGUgdGhhdCB1c2luZyBTZWFCSU9TIHJlcXVpcmVz
IHRoZSB1c2UgdGhlIHVwc3RyZWFtIHFlbXUgYXMgdGhlCiAjIGRldmljZSBtb2RlbC4KIFNFQUJJ
T1NfRElSID89IAotCi0jIE9wdGlvbmFsIGNvbXBvbmVudHMKLVhFTlNUQVRfWEVOVE9QICAgICA/
PSB5Ci1WVFBNX1RPT0xTICAgICAgICAgPz0gbgotTElCWEVOQVBJX0JJTkRJTkdTID89IG4KLVBZ
VEhPTl9UT09MUyAgICAgICA/PSB5Ci1PQ0FNTF9UT09MUyAgICAgICAgPz0geQotQ09ORklHX01J
TklURVJNICAgID89IG4KLUNPTkZJR19MT01PVU5UICAgICA/PSBuCi1DT05GSUdfU1lTVEVNX0xJ
QkFJTyA/PSB5Ci0KLWlmZXEgKCQoT0NBTUxfVE9PTFMpLHkpCi1PQ0FNTF9UT09MUyA6PSAkKHNo
ZWxsIG9jYW1sb3B0IC12ID4gL2Rldi9udWxsIDI+JjEgJiYgZWNobyAieSIgfHwgZWNobyAibiIp
Ci1lbmRpZgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgTWFrZWZpbGUKLS0t
IGEvTWFrZWZpbGUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL01ha2VmaWxl
CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtNDAsMTEgKzQwLDkgQEAgZGlzdDog
REVTVERJUj0kKERJU1RESVIpL2luc3RhbGwKIGRpc3Q6IGRpc3QteGVuIGRpc3Qta2VybmVscyBk
aXN0LXRvb2xzIGRpc3Qtc3R1YmRvbSBkaXN0LWRvY3MgZGlzdC1taXNjCiAKIGRpc3QtbWlzYzoK
LQkkKElOU1RBTExfRElSKSAkKERJU1RESVIpL2NoZWNrCiAJJChJTlNUQUxMX0RBVEEpIC4vQ09Q
WUlORyAkKERJU1RESVIpCiAJJChJTlNUQUxMX0RBVEEpIC4vUkVBRE1FICQoRElTVERJUikKIAkk
KElOU1RBTExfUFJPRykgLi9pbnN0YWxsLnNoICQoRElTVERJUikKLQkkKElOU1RBTExfUFJPRykg
dG9vbHMvY2hlY2svY2hrIHRvb2xzL2NoZWNrL2NoZWNrXyogdG9vbHMvY2hlY2svZnVuY3Muc2gg
JChESVNURElSKS9jaGVjawogZGlzdC0lOiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlz
dC0lOiBpbnN0YWxsLSUKIAlAOiAjIGRvIG5vdGhpbmcKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIg
ZDY2NWQ5NGRhYjBmIFJFQURNRQotLS0gYS9SRUFETUUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEy
ICswMDAwCisrKyBiL1JFQURNRQlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTg3
LDkgKzg3LDEzIEBAIDIuIGNkIHRvIHhlbi11bnN0YWJsZSAob3Igd2hhdGV2ZXIgeW91IHMKIDMu
IEZvciB0aGUgdmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJveSBidWls
ZCB0cmVlcywKICAgIHBlcmZvcm0gdGhlIGZvbGxvd2luZyBzdGVwczoKIAorICAgICMgLi9jb25m
aWd1cmUKICAgICAjIG1ha2Ugd29ybGQKICAgICAjIG1ha2UgaW5zdGFsbAogCisgICBJZiB5b3Ug
d2FudCwgeW91IGNhbiBydW4gLi9jb25maWd1cmUgLS1oZWxwIHRvIHNlZSB0aGUgbGlzdCBvZgor
ICAgb3B0aW9ucyBhdmFpbGFibGUgb3B0aW9ucyB3aGVuIGJ1aWxkaW5nIGFuZCBpbnN0YWxsaW5n
IFhlbi4KKwogICAgVGhpcyB3aWxsIGNyZWF0ZSBhbmQgaW5zdGFsbCBvbnRvIHRoZSBsb2NhbCBt
YWNoaW5lLiBJdCB3aWxsIGJ1aWxkCiAgICB0aGUgeGVuIGJpbmFyeSAoeGVuLmd6KSwgdGhlIHRv
b2xzIGFuZCB0aGUgZG9jdW1lbnRhdGlvbi4KIApkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1
ZDk0ZGFiMGYgYXV0b2dlbi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi9hdXRvZ2VuLnNoCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApA
QCAtMCwwICsxLDkgQEAKKyMhL2Jpbi9zaCAtZQorcm0gLXJmIGNvbmZpZ3VyZQorY2QgdG9vbHMK
K2F1dG9oZWFkZXIKK2F1dG9jb25mCitjZCAuLgorZWNobyAiIyEvYmluL3NoIC1lIiA+PiBjb25m
aWd1cmUKK2VjaG8gImNkIHRvb2xzICYmIC4vY29uZmlndXJlIFwkQCIgPj4gY29uZmlndXJlCitj
aG1vZCAreCBjb25maWd1cmUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIGNv
bmZpZy9Ub29scy5tay5pbgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi9jb25maWcvVG9vbHMubWsuaW4JVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsNTAgQEAKKyMgUHJlZml4IGFuZCBpbnN0YWxsIGZvbGRlcgorUFJFRklY
ICAgICAgICAgICAgICA6PSBAcHJlZml4QAorTElCTEVBRkRJUl94ODZfNjQgICA6PSBATElCX1BB
VEhACisKKyMgQSBkZWJ1ZyBidWlsZCBvZiB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAgOj0g
QGRlYnVnQAorCisjIFRvb2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09OQAor
RkxFWCAgICAgICAgICAgICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0gQFBZ
VEhPTkAKK1BZVEhPTl9QQVRIICAgICAgICAgOj0gQFBZVEhPTlBBVEhACitQRVJMICAgICAgICAg
ICAgICAgIDo9IEBQRVJMQAorQlJDVEwgICAgICAgICAgICAgICA6PSBAQlJDVExACitJUCAgICAg
ICAgICAgICAgICAgIDo9IEBJUEAKK0NVUkxfQ09ORklHICAgICAgICAgOj0gQENVUkxACitYTUwy
X0NPTkZJRyAgICAgICAgIDo9IEBYTUxACitCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAor
WEdFVFRURVhUICAgICAgICAgICA6PSBAWEdFVFRFWFRACisKKyMgRXh0cmEgZm9sZGVyIGZvciBs
aWJzL2luY2x1ZGVzCitQUkVQRU5EX0lOQ0xVREVTICAgIDo9IEBQUkVQRU5EX0lOQ0xVREVTQAor
UFJFUEVORF9MSUIgICAgICAgICA6PSBAUFJFUEVORF9MSUJACitBUFBFTkRfSU5DTFVERVMgICAg
IDo9IEBBUFBFTkRfSU5DTFVERVNACitBUFBFTkRfTElCICAgICAgICAgIDo9IEBBUFBFTkRfTElC
QAorCisjIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCitY
U01fRU5BQkxFICAgICAgICAgIDo9IEB4c21ACitGTEFTS19FTkFCTEUgICAgICAgIDo9IEB4c21A
CisKKyMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJv
dG9jb2w/CisjIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4g
aXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKKyMgbWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0
aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93bmxvYWRzCisjIGZhaWwg
b3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3VyIGVudmlyb25tZW50Lgor
R0lUX0hUVFAgICAgICAgICAgICA6PSBAZ2l0aHR0cEAKKworIyBPcHRpb25hbCBjb21wb25lbnRz
CitYRU5TVEFUX1hFTlRPUCAgICAgIDo9IEBtb25pdG9yc0AKK1ZUUE1fVE9PTFMgICAgICAgICAg
Oj0gQHZ0cG1ACitMSUJYRU5BUElfQklORElOR1MgIDo9IEB4YXBpQAorUFlUSE9OX1RPT0xTICAg
ICAgICA6PSBAcHl0aG9udG9vbHNACitPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRvb2xz
QAorQ09ORklHX01JTklURVJNICAgICA6PSBAbWluaXRlcm1ACitDT05GSUdfTE9NT1VOVCAgICAg
IDo9IEBsb21vdW50QAorCisjU3lzdGVtIG9wdGlvbnMKK0NPTkZJR19TWVNURU1fTElCQUlPOj0g
QHN5c3RlbV9haW9ACitDT05GSUdfTElCSUNPTlYgICAgIDo9IEBsaWJpY29udkAKK0NPTkZJR19H
Q1JZUFQgICAgICAgOj0gQGxpYmdjcnlwdEAKK0NPTkZJR19FWFQyRlMgICAgICAgOj0gQGxpYmV4
dDJmc0AKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIGNvbmZpZ3VyZQotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25maWd1cmUJ
VHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMiBAQAorIyEvYmluL3No
IC1lCitjZCB0b29scyAmJiAuL2NvbmZpZ3VyZSAkQApkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBk
NjY1ZDk0ZGFiMGYgdG9vbHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJVGh1IEphbiAw
NSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL01ha2VmaWxlCVR1ZSBKYW4gMTAgMTk6
MTM6MDEgMjAxMiArMDEwMApAQCAtNiw3ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlv
CiBlbmRpZgogCiBTVUJESVJTLXkgOj0KLVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9
IGluY2x1ZGUKIFNVQkRJUlMteSArPSBsaWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03Niw2
ICs3NSw4IEBAIGNsZWFuOiBzdWJkaXJzLWNsZWFuCiAuUEhPTlk6IGRpc3RjbGVhbgogZGlzdGNs
ZWFuOiBzdWJkaXJzLWRpc3RjbGVhbgogCXJtIC1yZiBpb2VtdS1kaXIgaW9lbXUtcmVtb3RlCisJ
cm0gLXJmIC4uL2NvbmZpZy9Ub29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0
dXMgXAorICAgICAgICAgICAgICAgY29uZmlnLmNhY2hlIGF1dG9tNHRlLmNhY2hlCiAKIGlmbmVx
ICgkKFhFTl9DT01QSUxFX0FSQ0gpLCQoWEVOX1RBUkdFVF9BUkNIKSkKIElPRU1VX0NPTkZJR1VS
RV9DUk9TUyA/PSAtLWNwdT0kKFhFTl9UQVJHRVRfQVJDSCkgXApkaWZmIC1yIDQwODZlNDgxMTU0
NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvUnVsZXMubWsKLS0tIGEvdG9vbHMvUnVsZXMubWsJVGh1
IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL1J1bGVzLm1rCVR1ZSBKYW4g
MTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtNCw2ICs0LDcgQEAKIGFsbDoKIAogaW5jbHVkZSAk
KFhFTl9ST09UKS9Db25maWcubWsKK2luY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xzLm1r
CiAKIGV4cG9ydCBfSU5TVEFMTCA6PSAkKElOU1RBTEwpCiBJTlNUQUxMID0gJChYRU5fUk9PVCkv
dG9vbHMvY3Jvc3MtaW5zdGFsbApAQCAtODAsOCArODEsNiBAQCBjaGVjay0kKENPTkZJR19YODYp
ID0gJChjYWxsIGNjLXZlci1jaGVjCiAgICAgICAgICAgICAgICAgICAgICAgICAiWGVuIHJlcXVp
cmVzIGF0IGxlYXN0IGdjYy0zLjQiKQogJChldmFsICQoY2hlY2steSkpCiAKLV9QWVRIT05fUEFU
SCA6PSAkKHNoZWxsIHdoaWNoICQoUFlUSE9OKSkKLVBZVEhPTl9QQVRIID89ICQoX1BZVEhPTl9Q
QVRIKQogSU5TVEFMTF9QWVRIT05fUFJPRyA9IFwKIAkkKFhFTl9ST09UKS90b29scy9weXRob24v
aW5zdGFsbC13cmFwICIkKFBZVEhPTl9QQVRIKSIgJChJTlNUQUxMX1BST0cpCiAKQEAgLTEwOSwz
ICsxMDgsNyBAQCBzdWJkaXItYWxsLSUgc3ViZGlyLWNsZWFuLSUgc3ViZGlyLWluc3RhCiAKIHN1
YmRpci1kaXN0Y2xlYW4tJTogLnBob255CiAJJChNQUtFKSAtQyAkKiBjbGVhbgorCiskKFhFTl9S
T09UKS9jb25maWcvVG9vbHMubWs6CisJQGVjaG8gIllvdSBoYXZlIHRvIHJ1biAuL2NvbmZpZ3Vy
ZSBiZWZvcmUgYnVpbGRpbmcgb3IgaW5zdGFsbGluZyB0aGUgdG9vbHMiCisJQGV4aXQgMQpkaWZm
IC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFr
ZWZpbGUKLS0tIGEvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJVGh1IEphbiAwNSAxNzoy
NToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVR1ZSBK
YW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMTMsNyArMTMsNyBAQCBDRkxBR1MgICArPSAk
KENGTEFHU19saWJ4ZW5zdG9yZSkKIENGTEFHUyAgICs9IC1JICQoTUVNU0hSX0RJUikKIENGTEFH
UyAgICs9IC1EX0dOVV9TT1VSQ0UKIAotaWZlcSAoJChzaGVsbCAuIC4vY2hlY2tfZ2NyeXB0ICQo
Q0MpKSx5ZXMpCitpZmVxICgkQ09ORklHX0dDUllQVCx5KQogQ0ZMQUdTICs9IC1EVVNFX0dDUllQ
VAogQ1JZUFRfTElCIDo9IC1sZ2NyeXB0CiBlbHNlCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2
NjVkOTRkYWIwZiB0b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQKLS0tIGEvdG9vbHMv
YmxrdGFwL2RyaXZlcnMvY2hlY2tfZ2NyeXB0CVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAw
MAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNCAr
MCwwIEBACi0jIS9iaW4vc2gKLQotY2F0ID4gLmdjcnlwdC5jIDw8IEVPRgotI2luY2x1ZGUgPGdj
cnlwdC5oPgotaW50IG1haW4odm9pZCkgeyByZXR1cm4gMDsgfQotRU9GCi0KLWlmICQxIC1vIC5n
Y3J5cHQgLmdjcnlwdC5jIC1sZ2NyeXB0IDI+L2Rldi9udWxsIDsgdGhlbgotICBlY2hvICJ5ZXMi
Ci1lbHNlCi0gIGVjaG8gIm5vIgotZmkKLQotcm0gLWYgLmdjcnlwdCoKZGlmZiAtciA0MDg2ZTQ4
MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NoZWNrL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2No
ZWNrL01ha2VmaWxlCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyNiArMCwwIEBACi1YRU5fUk9P
VCA9ICQoQ1VSRElSKS8uLi8uLgotaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawot
Ci0jIEV4cG9ydCB0aGUgbmVjZXNzYXJ5IGVudmlyb25tZW50IHZhcmlhYmxlcyBmb3IgdGhlIHRl
c3RzCi1leHBvcnQgUFlUSE9OCi1leHBvcnQgTElCWEVOQVBJX0JJTkRJTkdTCi1leHBvcnQgQ0hF
Q0tfSU5DTFVERVMKLWV4cG9ydCBDSEVDS19MSUIKLWV4cG9ydCBDT05GSUdfU1lTVEVNX0xJQkFJ
TwotCi0uUEhPTlk6IGFsbCBpbnN0YWxsCi1hbGwgaW5zdGFsbDogY2hlY2stYnVpbGQKLQotIyBD
aGVjayB0aGlzIG1hY2hpbmUgaXMgT0sgZm9yIGJ1aWxkaW5nIG9uLgotLlBIT05ZOiBjaGVjay1i
dWlsZAotY2hlY2stYnVpbGQ6Ci0JLi9jaGsgYnVpbGQKLQotIyBDaGVjayB0aGlzIG1hY2hpbmUg
aXMgT0sgZm9yIGluc3RhbGxpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWluc3RhbGwKLWNoZWNrLWlu
c3RhbGw6Ci0JLi9jaGsgaW5zdGFsbAotCi0uUEhPTlk6IGNsZWFuCi1jbGVhbjoKLQkuL2NoayBj
bGVhbgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY2hlY2svUkVB
RE1FCi0tLSBhL3Rvb2xzL2NoZWNrL1JFQURNRQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAw
MDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjAg
KzAsMCBAQAotQ2hlY2tzIGZvciB0aGUgc3VpdGFiaWxpdHkgb2YgYSBtYWNoaW5lIGZvciBYZW4g
YnVpbGQgb3IgaW5zdGFsbC4KLVRvIGNoZWNrIGZvciBidWlsZCBzdWl0YWJpbGl0eSB1c2UKLQot
ICAgICAgICAuL2NoayBidWlsZAotCi1UbyBjaGVjayBmb3IgaW5zdGFsbCBzdWl0YWJpbGl0eSB1
c2UKLQotICAgICAgICAuL2NoayBpbnN0YWxsCi0KLVRoZSBjaGsgc2NyaXB0IHdpbGwgcnVuIGNo
ZWNrcyBpbiB0aGlzIGRpcmVjdG9yeSBhbmQgcHJpbnQKLXRoZSBvbmVzIHRoYXQgZmFpbGVkLiBJ
dCBwcmludHMgbm90aGluZyBpZiBjaGVja3Mgc3VjY2VlZC4KLVRoZSBjaGsgc2NyaXB0IGV4aXRz
IHdpdGggMCBvbiBzdWNjZXNzIGFuZCAxIG9uIGZhaWx1cmUuCi0KLVRoZSBjaGsgc2NyaXB0IHJ1
bnMgZXhlY3V0YWJsZSBmaWxlcyBpbiB0aGlzIGRpcmVjdG9yeSB3aG9zZQotbmFtZXMgYmVnaW4g
d2l0aCAnY2hlY2tfJy4gRmlsZXMgY29udGFpbmluZyBDSEVDSy1CVUlMRAotYXJlIHJ1biBmb3Ig
dGhlIGJ1aWxkIGNoZWNrLCBhbmQgZmlsZXMgY29udGFpbmluZyBDSEVDSy1JTlNUQUxMCi1hcmUg
cnVuIGZvciB0aGUgaW5zdGFsbCBjaGVjay4KLQotRGV0YWlsZWQgb3V0cHV0IGZyb20gdGhlIGNo
ZWNrIHNjcmlwdHMgaXMgaW4gLmNoa2J1aWxkIGZvciBidWlsZAotYW5kIC5jaGtpbnN0YWxsIGZv
ciBpbnN0YWxsLgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NoZWNrL2NoZWNrX2JyY3RsCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX2JyY3RsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9i
aW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLU9w
ZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgYnJjb25maWcgOzsKLUxpbnV4KQot
CWhhc19vcl9mYWlsIGJyY3RsIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2FjCmRp
ZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja19jcnlw
dG9fbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIJVGh1IEphbiAwNSAxNzoy
NToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCkBAIC0xLDExICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNU
QUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJlZUJTRHxOZXRCU0R8T3BlbkJT
RCkKLQlleGl0IDAgOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJjcnlwdG8uc28gfHwgZmFpbCAibWlz
c2luZyBsaWJjcnlwdG8uc28iCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0
b29scy9jaGVjay9jaGVja19jdXJsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2N1cmwJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBD
SEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbICIkTElCWEVOQVBJX0JJTkRJTkdT
IiAhPSAieSIgXTsgdGhlbgotCWVjaG8gLW4gInVudXNlZCwgIgotCWV4aXQgMAotZmkKLQotaGFz
X29yX2ZhaWwgY3VybC1jb25maWcKLWN1cmxfbGlicz1gY3VybC1jb25maWcgLS1saWJzYCB8fCBm
YWlsICJjdXJsLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICRjdXJsX2xpYnMgfHwg
ZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIGN1cmwgYXJlIG1pc3NpbmciCmRpZmYgLXIg
NDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja19pcHJvdXRlCi0t
LSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE1
ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1Q
QVRIPS9zYmluOiRQQVRICi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQot
CWhhc19vcl9mYWlsIGlmY29uZmlnIDs7Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBpcCA7OwotKikK
LQlmYWlsICJ1bmtub3duIE9TIiA7OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1
ZDk0ZGFiMGYgdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNr
L2NoZWNrX2xpYmFpb19kZXZlbAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBAQAot
IyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJ
R19TWVNURU1fTElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaWYgISBo
YXNfaGVhZGVyIGxpYmFpby5oIDsgdGhlbgotICAgIGZhaWwgImNhbid0IGZpbmQgbGliYWlvIGhl
YWRlcnMsIGluc3RhbGwgbGliYWlvIGRldmVsIHBhY2thZ2Ugb3Igc2V0IENPTkZJR19TWVNURU1f
TElCQUlPPW4iCi1maQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMv
Y2hlY2svY2hlY2tfbGliYWlvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19saWJhaW9fbGli
CVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1C
VUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJR19TWVNU
RU1fTElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaGFzX2xpYiBsaWJh
aW8uc28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8iCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1y
IGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX29wZW5zc2xfZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAw
CisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVh
ZGVyIG9wZW5zc2wvbWQ1LmggfHwgZmFpbCAibWlzc2luZyBvcGVuc3NsIGhlYWRlcnMiCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja19weXRob24K
LS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiAr
MDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwx
MyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4v
ZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgot
ZmkKLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBzeXMKLXN5cy5leGl0KHN5cy52ZXJzaW9uX2lu
Zm9bMF0gPCAyIG9yIHN5cy52ZXJzaW9uX2luZm9bMV0gPCAzKQotJyB8fCBmYWlsICJuZWVkIHB5
dGhvbiB2ZXJzaW9uID49IDIuMyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBm
IHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja19w
eXRob25fZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE3ICswLDAgQEAKLSMhL2Jpbi9z
aAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07
IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0ke1BZ
VEhPTn0gLWMgJwotaW1wb3J0IG9zLnBhdGgsIHN5cwotZm9yIHAgaW4gc3lzLnBhdGg6Ci0JaWYg
b3MucGF0aC5leGlzdHMocCArICIvY29uZmlnL01ha2VmaWxlIik6Ci0JCXN5cy5leGl0KDApCi1z
eXMuZXhpdCgxKQotJyB8fCBmYWlsICJjYW4ndCBmaW5kIHB5dGhvbiBkZXZlbCBmaWxlcyIKZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhv
bl94bWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAlUaHUgSmFuIDA1IDE3OjI1
OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1
bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZp
Ci1oYXNfb3JfZmFpbCAke1BZVEhPTn0KLQotJHtQWVRIT059IC1jICdpbXBvcnQgeG1sLmRvbS5t
aW5pZG9tJyAyPi9kZXYvbnVsbCB8fCBcCi1mYWlsICJjYW4ndCBpbXBvcnQgeG1sLmRvbS5taW5p
ZG9tIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY2hlY2svY2hl
Y2tfdWRldgotLS0gYS90b29scy9jaGVjay9jaGVja191ZGV2CVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSwyMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Mu
c2gKLQotY2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwg
dm5jb25maWcKLQk7OwotTGludXgpCi0JaGFzIC9zYmluL3VkZXZhZG0gJiYgXAotCQl1ZGV2dmVy
PWAvc2Jpbi91ZGV2YWRtIGluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlbIC16ICIkdWRl
dnZlciIgXSAmJiBoYXNfb3JfZmFpbCB1ZGV2aW5mbyAmJiBcCi0JCXVkZXZ2ZXI9YHVkZXZpbmZv
IC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCi0JWyAiJHVkZXZ2ZXIiIC1nZSA1OSBdIDI+L2Rldi9u
dWxsIHx8IFwKLQkJaGFzIGhvdHBsdWcgfHwgXAotCQlmYWlsICJ1ZGV2IGlzIHRvbyBvbGQsIHVw
Z3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlciIKLQk7OwotKikKLQlmYWlsICJ1bmtub3duIE9T
IgotCTs7Ci1lc2FjCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9j
aGVjay9jaGVja191dWlkX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2ZWwJ
VGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJV
SUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHV1aWQuaCB8fCBcCi1oYXNfaGVhZGVy
IHV1aWQvdXVpZC5oIHx8IGZhaWwgIm1pc3NpbmcgdXVpZCBoZWFkZXJzIChwYWNrYWdlIHV1aWQt
ZGV2KSIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NoZWNrL2No
ZWNrX3gxMV9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja194MTFfZGV2ZWwJVGh1IEphbiAw
NSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4g
Li9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIFgxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVy
IC91c3IvWDExUjYvaW5jbHVkZS9YMTEva2V5c3ltZGVmLmggfHwgXAotaGFzX2hlYWRlciAvdXNy
L1gxMVI3L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLXdhcm5pbmcgImNhbid0IGZpbmQg
WDExIGhlYWRlcnMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9j
aGVjay9jaGVja194Z2V0dGV4dAotLS0gYS90b29scy9jaGVjay9jaGVja194Z2V0dGV4dAlUaHUg
SmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQK
LQotLiAuL2Z1bmNzLnNoCi0KLWhhc19vcl9mYWlsIHhnZXR0ZXh0CmRpZmYgLXIgNDA4NmU0ODEx
NTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja194bWwyCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX3htbDIJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jp
bi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBb
ICEgIiRMSUJYRU5BUElfQklORElOR1MiID0gInkiIF0KLXRoZW4KLSAgICBlY2hvIC1uICJ1bnVz
ZWQsICIKLSAgICBleGl0IDAKLWZpCi0KLWhhc19vcl9mYWlsIHhtbDItY29uZmlnCi14bWwyX2xp
YnM9YHhtbDItY29uZmlnIC0tbGlic2AgfHwgZmFpbCAieG1sMi1jb25maWcgLS1saWJzIGZhaWxl
ZCIKLXRlc3RfbGluayAkeG1sMl9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZv
ciB4bWwyIGFyZSBtaXNzaW5nIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYg
dG9vbHMvY2hlY2svY2hlY2tfeWFqbF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja195YWps
X2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw4ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBD
SEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB5YWpsL3lhamxfcGFyc2Uu
aCB8fCBmYWlsICJjYW4ndCBmaW5kIHlhamwveWFqbF9wYXJzZS5oIgotaGFzX2hlYWRlciB5YWps
L3lhamxfZ2VuLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfZ2VuLmgiCi1oYXNfbGli
IGxpYnlhamwuc28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJ5YWpsLnNvIgpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY2hlY2svY2hlY2tfeWFqbF9saWIKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfeWFqbF9saWIJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAw
CisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNz
LnNoCi0KLWhhc19saWIgbGlieWFqbC5zby4xIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFqbC5z
by4xIHZlcnNpb24gMSIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xz
L2NoZWNrL2NoZWNrX3psaWJfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfemxpYl9kZXZl
bAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0st
QlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgemxpYi5oIHx8IGZhaWwgImNhbid0
IGZpbmQgemxpYiBoZWFkZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYg
dG9vbHMvY2hlY2svY2hlY2tfemxpYl9saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfemxpYl9s
aWIJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJl
ZUJTRHxOZXRCU0R8T3BlbkJTRCkKLQlleGl0IDAKLQk7OwotZXNhYwotCi1oYXNfbGliIGxpYnou
c28gfHwgZmFpbCAiY2FuJ3QgZmluZCB6bGliIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1
ZDk0ZGFiMGYgdG9vbHMvY2hlY2svY2hrCi0tLSBhL3Rvb2xzL2NoZWNrL2NoawlUaHUgSmFuIDA1
IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsNjMgKzAsMCBAQAotIyEvYmluL3NoCi0KLWZ1bmNfdXNhZ2UgKCkKLXsK
LSAgICBlY2hvICJVc2FnZToiCi0gICAgZWNobyAiCSQwIFtidWlsZHxpbnN0YWxsfGNsZWFuXSIK
LSAgICBlY2hvCi0gICAgZWNobyAiQ2hlY2sgc3VpdGFiaWxpdHkgZm9yIFhlbiBidWlsZCBvciBp
bnN0YWxsLiIKLSAgICBlY2hvICJFeGl0IHdpdGggMCBpZiBPSywgMSBpZiBub3QuIgotICAgIGVj
aG8KLSAgICBlY2hvICJDYWxsaW5nIHdpdGggJ2NsZWFuJyByZW1vdmVzIGdlbmVyYXRlZCBmaWxl
cy4iCi0gICAgZXhpdCAxCi19Ci0KLVBBVEg9JFBBVEg6L3NiaW46L3Vzci9zYmluCi1PUz1gdW5h
bWUgLXNgCi1leHBvcnQgUEFUSCBPUwotCi1pZiBbICIkT1MiID0gIlN1bk9TIiBdOyB0aGVuCi0J
ZXhpdCAwCi1maQotCi1jYXNlICQxIGluCi0gICAgYnVpbGQpCi0gICAgICAgIGNoZWNrPSJDSEVD
Sy1CVUlMRCIKLSAgICAgICAgOzsKLSAgICBpbnN0YWxsKQotICAgICAgICBjaGVjaz0iQ0hFQ0st
SU5TVEFMTCIKLSAgICAgICAgOzsKLSAgICBjbGVhbikKLSAgICAgICAgZXhpdCAwCi0gICAgICAg
IDs7Ci0gICAgKikKLSAgICAgICAgZnVuY191c2FnZQotICAgICAgICA7OwotZXNhYwotCi1mYWls
ZWQ9MAotCi1lY2hvICJYZW4gJHtjaGVja30gIiBgZGF0ZWAKLWZvciBmIGluIGNoZWNrXyogOyBk
bwotICAgIGNhc2UgJGYgaW4KLSAgICAgICAgKn4pCi0gICAgICAgICAgICBjb250aW51ZQotICAg
ICAgICAgICAgOzsKLSAgICAgICAgKikKLSAgICAgICAgICAgIDs7Ci0gICAgZXNhYwotICAgIGlm
ICEgWyAteCAkZiBdIDsgdGhlbgotICAgICAgICBjb250aW51ZQotICAgIGZpCi0gICAgaWYgISBn
cmVwIC1GcSAiJGNoZWNrIiAkZiA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQotICAg
IGVjaG8gLW4gIkNoZWNraW5nICRmOiAiCi0gICAgaWYgLi8kZiAyPiYxIDsgdGhlbgotICAgICAg
ICBlY2hvIE9LCi0gICAgZWxzZQotICAgICAgICBmYWlsZWQ9MQotICAgIGZpCi1kb25lCi0KLWV4
aXQgJHtmYWlsZWR9CmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9j
aGVjay9mdW5jcy5zaAotLS0gYS90b29scy9jaGVjay9mdW5jcy5zaAlUaHUgSmFuIDA1IDE3OjI1
OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTA2ICswLDAgQEAKLSMgaGFzIGlzIHRoZSBzYW1lIGFzIHdoaWNoLCBleGNlcHQg
aXQgaGFuZGxlcyBjcm9zcyBlbnZpcm9ubWVudHMKLWhhcygpIHsKLQlpZiBbIC16ICIkQ1JPU1Nf
Q09NUElMRSIgXTsgdGhlbgotCQljb21tYW5kIHdoaWNoICIkQCIKLQkJcmV0dXJuICQ/Ci0JZmkK
LQotCWNoZWNrX3N5c19yb290IHx8IHJldHVybiAxCi0KLQkjIHN1YnNoZWxsIHRvIHByZXZlbnQg
cG9sbHV0aW9uIG9mIGNhbGxlcidzIElGUwotCSgKLQlJRlM9OgotCWZvciBwIGluICRQQVRIOyBk
bwotCQlpZiBbIC14ICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiIF07IHRoZW4KLQkJCWVjaG8gIiRD
Uk9TU19TWVNfUk9PVC8kcC8kMSIKLQkJCXJldHVybiAwCi0JCWZpCi0JZG9uZQotCXJldHVybiAx
Ci0JKQotfQotCi1oYXNfb3JfZmFpbCgpIHsKLQloYXMgIiQxIiA+L2Rldi9udWxsIHx8IGZhaWwg
ImNhbid0IGZpbmQgJDEiCi19Ci0KLWhhc19oZWFkZXIoKSB7Ci0JY2hlY2tfc3lzX3Jvb3QgfHwg
cmV0dXJuIDEKLQotCWNhc2UgJDEgaW4KLQkJLyopIDs7Ci0JCSopCi0JCWlmIFsgLXIgIiRDUk9T
U19TWVNfUk9PVC91c3IvaW5jbHVkZS8kMSIgXTsgdGhlbgotCQkJcmV0dXJuIDAKLQkJZmkKLQkJ
Zm9yIHBhdGggaW4gJHtDSEVDS19JTkNMVURFU307IGRvCi0JCQlpZiBbIC1yICIkQ1JPU1NfU1lT
X1JPT1Qke3BhdGh9LyQxIiBdOyB0aGVuCi0JCQkJcmV0dXJuIDAKLQkJCWZpCi0JCWRvbmUKLQkJ
OzsKLQllc2FjCi0KLQlyZXR1cm4gMQotfQotCi1oYXNfbGliKCkgewotCWNoZWNrX3N5c19yb290
IHx8IHJldHVybiAxCi0KLQkjIHN1YnNoZWxsIHRvIHByZXZlbnQgcG9sbHV0aW9uIG9mIGNhbGxl
cidzIGVudmlyb25tZW50Ci0JKAotCVBBVEg9L3NiaW46JFBBVEggICAgICAgICMgZm9yIGxkY29u
ZmlnCi0JTElCUkFSSUVTPSIkQ0hFQ0tfTElCIC91c3IvbGliIgotCi0JIyBUaGlzIHJlbGF0aXZl
bHkgY29tbW9uIGluIGEgc3lzLXJvb3Q7IGxpYnMgYXJlIGluc3RhbGxlZCBidXQKLQkjIGxkY29u
ZmlnIGhhc24ndCBydW4gdGhlcmUsIHNvIGxkY29uZmlnIC1wIHdvbid0IHdvcmsuCi0JaWYgWyAi
JE9TIiA9IExpbnV4IC1hICEgLWYgIiRDUk9TU19TWVNfUk9PVC9ldGMvbGQuc28uY2FjaGUiIF07
IHRoZW4KLQkgICAgZWNobyAiUGxlYXNlIHJ1biBsZGNvbmZpZyAtciBcIiRDUk9TU19TWVNfUk9P
VFwiIHRvIGdlbmVyYXRlIGxkLnNvLmNhY2hlIgotCSAgICAjIGZhbGwgdGhyb3VnaDsgbGRjb25m
aWcgdGVzdCBiZWxvdyBzaG91bGQgZmFpbAotCWZpCi0JaWYgWyAiJHtPU30iID0gIkxpbnV4IiBd
OyB0aGVuCi0JCWxkY29uZmlnIC1wICR7Q1JPU1NfU1lTX1JPT1QrLXIgIiRDUk9TU19TWVNfUk9P
VCJ9IHwgZ3JlcCAtRnEgIiQxIgotCQlyZXR1cm4gJD8KLQlmaQotCWlmIFsgIiR7T1N9IiA9ICJO
ZXRCU0QiIF07IHRoZW4KLQkJbHMgLTEgJHtMSUJSQVJJRVN9IHwgZ3JlcCAtRnEgIiQxIgotCQly
ZXR1cm4gJD8KLQlmaQotCXJldHVybiAxCi0JKQotfQotCi10ZXN0X2xpbmsoKSB7Ci0JIyBzdWJz
aGVsbCB0byB0cmFwIHJlbW92YWwgb2YgdG1wZmlsZQotCSgKLQl1bnNldCB0bXBmaWxlCi0JdHJh
cCAncm0gLWYgIiR0bXBmaWxlIjsgZXhpdCcgMCAxIDIgMTUKLQl0bXBmaWxlPWBta3RlbXBgIHx8
IHJldHVybiAxCi0JbGQgIiRAIiAtbyAiJHRtcGZpbGUiID4vZGV2L251bGwgMj4mMQotCXJldHVy
biAkPwotCSkKLX0KLQotIyB0aGlzIGZ1bmN0aW9uIGlzIHVzZWQgY29tbW9ubHkgYWJvdmUKLWNo
ZWNrX3N5c19yb290KCkgewotCVsgLXogIiRDUk9TU19DT01QSUxFIiBdICYmIHJldHVybiAwCi0J
aWYgWyAteiAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gInBsZWFzZSBzZXQgQ1JP
U1NfU1lTX1JPT1QgaW4gdGhlIGVudmlyb25tZW50IgotCQlyZXR1cm4gMQotCWZpCi0JaWYgWyAh
IC1kICIkQ1JPU1NfU1lTX1JPT1QiIF07IHRoZW4KLQkJZWNobyAibm8gc3lzLXJvb3QgZm91bmQg
YXQgJENST1NTX1NZU19ST09UIgotCQlyZXR1cm4gMQotCWZpCi19Ci0KLXdhcm5pbmcoKSB7Ci0J
ZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZBSUxFRCR7Kis6ICQqfSIKLX0KLQot
ZmFpbCgpIHsKLQllY2hvCi0JZWNobyAiICoqKiBgYmFzZW5hbWUgIiQwImAgRkFJTEVEJHsqKzog
JCp9IgotCWV4aXQgMQotfQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9v
bHMvY29uZmlnLmd1ZXNzCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3Rvb2xzL2NvbmZpZy5ndWVzcwlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAx
MDAKQEAgLTAsMCArMSwxNTAxIEBACisjISAvYmluL3NoCisjIEF0dGVtcHQgdG8gZ3Vlc3MgYSBj
YW5vbmljYWwgc3lzdGVtIG5hbWUuCisjICAgQ29weXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0
LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LAorIyAgIDIwMDAsIDIwMDEsIDIwMDIsIDIw
MDMsIDIwMDQsIDIwMDUsIDIwMDYsIDIwMDcsIDIwMDgsIDIwMDkKKyMgICBGcmVlIFNvZnR3YXJl
IEZvdW5kYXRpb24sIEluYy4KKwordGltZXN0YW1wPScyMDA5LTExLTIwJworCisjIFRoaXMgZmls
ZSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5
IGl0CisjIHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug
YXMgcHVibGlzaGVkIGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2
ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVy
IHZlcnNpb24uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0
aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhv
dXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklU
TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNl
aXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdp
dGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZv
dW5kYXRpb24sIEluYy4sIDUxIEZyYW5rbGluIFN0cmVldCAtIEZpZnRoIEZsb29yLCBCb3N0b24s
IE1BCisjIDAyMTEwLTEzMDEsIFVTQS4KKyMKKyMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGlmIHlvdQorIyBkaXN0cmlidXRlIHRoaXMg
ZmlsZSBhcyBwYXJ0IG9mIGEgcHJvZ3JhbSB0aGF0IGNvbnRhaW5zIGEKKyMgY29uZmlndXJhdGlv
biBzY3JpcHQgZ2VuZXJhdGVkIGJ5IEF1dG9jb25mLCB5b3UgbWF5IGluY2x1ZGUgaXQgdW5kZXIK
KyMgdGhlIHNhbWUgZGlzdHJpYnV0aW9uIHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qg
b2YgdGhhdCBwcm9ncmFtLgorCisKKyMgT3JpZ2luYWxseSB3cml0dGVuIGJ5IFBlciBCb3RobmVy
LiAgUGxlYXNlIHNlbmQgcGF0Y2hlcyAoY29udGV4dAorIyBkaWZmIGZvcm1hdCkgdG8gPGNvbmZp
Zy1wYXRjaGVzQGdudS5vcmc+IGFuZCBpbmNsdWRlIGEgQ2hhbmdlTG9nCisjIGVudHJ5LgorIwor
IyBUaGlzIHNjcmlwdCBhdHRlbXB0cyB0byBndWVzcyBhIGNhbm9uaWNhbCBzeXN0ZW0gbmFtZSBz
aW1pbGFyIHRvCisjIGNvbmZpZy5zdWIuICBJZiBpdCBzdWNjZWVkcywgaXQgcHJpbnRzIHRoZSBz
eXN0ZW0gbmFtZSBvbiBzdGRvdXQsIGFuZAorIyBleGl0cyB3aXRoIDAuICBPdGhlcndpc2UsIGl0
IGV4aXRzIHdpdGggMS4KKyMKKyMgWW91IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRo
aXMgc2NyaXB0IGZyb206CisjIGh0dHA6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9
Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47Zj1jb25maWcuZ3Vlc3M7aGI9SEVBRAorCittZT1gZWNo
byAiJDAiIHwgc2VkIC1lICdzLC4qLywsJ2AKKwordXNhZ2U9IlwKK1VzYWdlOiAkMCBbT1BUSU9O
XQorCitPdXRwdXQgdGhlIGNvbmZpZ3VyYXRpb24gbmFtZSBvZiB0aGUgc3lzdGVtIFxgJG1lJyBp
cyBydW4gb24uCisKK09wZXJhdGlvbiBtb2RlczoKKyAgLWgsIC0taGVscCAgICAgICAgIHByaW50
IHRoaXMgaGVscCwgdGhlbiBleGl0CisgIC10LCAtLXRpbWUtc3RhbXAgICBwcmludCBkYXRlIG9m
IGxhc3QgbW9kaWZpY2F0aW9uLCB0aGVuIGV4aXQKKyAgLXYsIC0tdmVyc2lvbiAgICAgIHByaW50
IHZlcnNpb24gbnVtYmVyLCB0aGVuIGV4aXQKKworUmVwb3J0IGJ1Z3MgYW5kIHBhdGNoZXMgdG8g
PGNvbmZpZy1wYXRjaGVzQGdudS5vcmc+LiIKKwordmVyc2lvbj0iXAorR05VIGNvbmZpZy5ndWVz
cyAoJHRpbWVzdGFtcCkKKworT3JpZ2luYWxseSB3cml0dGVuIGJ5IFBlciBCb3RobmVyLgorQ29w
eXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5
LCAyMDAwLCAyMDAxLAorMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAwOCBG
cmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhpcyBpcyBmcmVlIHNvZnR3YXJlOyBz
ZWUgdGhlIHNvdXJjZSBmb3IgY29weWluZyBjb25kaXRpb25zLiAgVGhlcmUgaXMgTk8KK3dhcnJh
bnR5OyBub3QgZXZlbiBmb3IgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFLiIKKworaGVscD0iCitUcnkgXGAkbWUgLS1oZWxwJyBmb3IgbW9yZSBpbmZv
cm1hdGlvbi4iCisKKyMgUGFyc2UgY29tbWFuZCBsaW5lCit3aGlsZSB0ZXN0ICQjIC1ndCAwIDsg
ZG8KKyAgY2FzZSAkMSBpbgorICAgIC0tdGltZS1zdGFtcCB8IC0tdGltZSogfCAtdCApCisgICAg
ICAgZWNobyAiJHRpbWVzdGFtcCIgOyBleGl0IDs7CisgICAgLS12ZXJzaW9uIHwgLXYgKQorICAg
ICAgIGVjaG8gIiR2ZXJzaW9uIiA7IGV4aXQgOzsKKyAgICAtLWhlbHAgfCAtLWgqIHwgLWggKQor
ICAgICAgIGVjaG8gIiR1c2FnZSI7IGV4aXQgOzsKKyAgICAtLSApICAgICAjIFN0b3Agb3B0aW9u
IHByb2Nlc3NpbmcKKyAgICAgICBzaGlmdDsgYnJlYWsgOzsKKyAgICAtICkJIyBVc2Ugc3RkaW4g
YXMgaW5wdXQuCisgICAgICAgYnJlYWsgOzsKKyAgICAtKiApCisgICAgICAgZWNobyAiJG1lOiBp
bnZhbGlkIG9wdGlvbiAkMSRoZWxwIiA+JjIKKyAgICAgICBleGl0IDEgOzsKKyAgICAqICkKKyAg
ICAgICBicmVhayA7OworICBlc2FjCitkb25lCisKK2lmIHRlc3QgJCMgIT0gMDsgdGhlbgorICBl
Y2hvICIkbWU6IHRvbyBtYW55IGFyZ3VtZW50cyRoZWxwIiA+JjIKKyAgZXhpdCAxCitmaQorCit0
cmFwICdleGl0IDEnIDEgMiAxNQorCisjIENDX0ZPUl9CVUlMRCAtLSBjb21waWxlciB1c2VkIGJ5
IHRoaXMgc2NyaXB0LiBOb3RlIHRoYXQgdGhlIHVzZSBvZiBhCisjIGNvbXBpbGVyIHRvIGFpZCBp
biBzeXN0ZW0gZGV0ZWN0aW9uIGlzIGRpc2NvdXJhZ2VkIGFzIGl0IHJlcXVpcmVzCisjIHRlbXBv
cmFyeSBmaWxlcyB0byBiZSBjcmVhdGVkIGFuZCwgYXMgeW91IGNhbiBzZWUgYmVsb3csIGl0IGlz
IGEKKyMgaGVhZGFjaGUgdG8gZGVhbCB3aXRoIGluIGEgcG9ydGFibGUgZmFzaGlvbi4KKworIyBI
aXN0b3JpY2FsbHksIGBDQ19GT1JfQlVJTEQnIHVzZWQgdG8gYmUgbmFtZWQgYEhPU1RfQ0MnLiBX
ZSBzdGlsbAorIyB1c2UgYEhPU1RfQ0MnIGlmIGRlZmluZWQsIGJ1dCBpdCBpcyBkZXByZWNhdGVk
LgorCisjIFBvcnRhYmxlIHRtcCBkaXJlY3RvcnkgY3JlYXRpb24gaW5zcGlyZWQgYnkgdGhlIEF1
dG9jb25mIHRlYW0uCisKK3NldF9jY19mb3JfYnVpbGQ9JwordHJhcCAiZXhpdGNvZGU9XCQ/OyAo
cm0gLWYgXCR0bXBmaWxlcyAyPi9kZXYvbnVsbDsgcm1kaXIgXCR0bXAgMj4vZGV2L251bGwpICYm
IGV4aXQgXCRleGl0Y29kZSIgMCA7Cit0cmFwICJybSAtZiBcJHRtcGZpbGVzIDI+L2Rldi9udWxs
OyBybWRpciBcJHRtcCAyPi9kZXYvbnVsbDsgZXhpdCAxIiAxIDIgMTMgMTUgOworOiAke1RNUERJ
Uj0vdG1wfSA7CisgeyB0bXA9YCh1bWFzayAwNzcgJiYgbWt0ZW1wIC1kICIkVE1QRElSL2NnWFhY
WFhYIikgMj4vZGV2L251bGxgICYmIHRlc3QgLW4gIiR0bXAiICYmIHRlc3QgLWQgIiR0bXAiIDsg
fSB8fAorIHsgdGVzdCAtbiAiJFJBTkRPTSIgJiYgdG1wPSRUTVBESVIvY2ckJC0kUkFORE9NICYm
ICh1bWFzayAwNzcgJiYgbWtkaXIgJHRtcCkgOyB9IHx8CisgeyB0bXA9JFRNUERJUi9jZy0kJCAm
JiAodW1hc2sgMDc3ICYmIG1rZGlyICR0bXApICYmIGVjaG8gIldhcm5pbmc6IGNyZWF0aW5nIGlu
c2VjdXJlIHRlbXAgZGlyZWN0b3J5IiA+JjIgOyB9IHx8CisgeyBlY2hvICIkbWU6IGNhbm5vdCBj
cmVhdGUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5IGluICRUTVBESVIiID4mMiA7IGV4aXQgMSA7IH0g
OworZHVtbXk9JHRtcC9kdW1teSA7Cit0bXBmaWxlcz0iJGR1bW15LmMgJGR1bW15Lm8gJGR1bW15
LnJlbCAkZHVtbXkiIDsKK2Nhc2UgJENDX0ZPUl9CVUlMRCwkSE9TVF9DQywkQ0MgaW4KKyAsLCkg
ICAgZWNobyAiaW50IHg7IiA+ICRkdW1teS5jIDsKKwlmb3IgYyBpbiBjYyBnY2MgYzg5IGM5OSA7
IGRvCisJICBpZiAoJGMgLWMgLW8gJGR1bW15Lm8gJGR1bW15LmMpID4vZGV2L251bGwgMj4mMSA7
IHRoZW4KKwkgICAgIENDX0ZPUl9CVUlMRD0iJGMiOyBicmVhayA7CisJICBmaSA7CisJZG9uZSA7
CisJaWYgdGVzdCB4IiRDQ19GT1JfQlVJTEQiID0geCA7IHRoZW4KKwkgIENDX0ZPUl9CVUlMRD1u
b19jb21waWxlcl9mb3VuZCA7CisJZmkKKwk7OworICwsKikgICBDQ19GT1JfQlVJTEQ9JENDIDs7
CisgLCosKikgIENDX0ZPUl9CVUlMRD0kSE9TVF9DQyA7OworZXNhYyA7IHNldF9jY19mb3JfYnVp
bGQ9IDsnCisKKyMgVGhpcyBpcyBuZWVkZWQgdG8gZmluZCB1bmFtZSBvbiBhIFB5cmFtaWQgT1N4
IHdoZW4gcnVuIGluIHRoZSBCU0QgdW5pdmVyc2UuCisjIChnaGF6aUBub2MucnV0Z2Vycy5lZHUg
MTk5NC0wOC0yNCkKK2lmICh0ZXN0IC1mIC8uYXR0YmluL3VuYW1lKSA+L2Rldi9udWxsIDI+JjEg
OyB0aGVuCisJUEFUSD0kUEFUSDovLmF0dGJpbiA7IGV4cG9ydCBQQVRICitmaQorCitVTkFNRV9N
QUNISU5FPWAodW5hbWUgLW0pIDI+L2Rldi9udWxsYCB8fCBVTkFNRV9NQUNISU5FPXVua25vd24K
K1VOQU1FX1JFTEVBU0U9YCh1bmFtZSAtcikgMj4vZGV2L251bGxgIHx8IFVOQU1FX1JFTEVBU0U9
dW5rbm93bgorVU5BTUVfU1lTVEVNPWAodW5hbWUgLXMpIDI+L2Rldi9udWxsYCAgfHwgVU5BTUVf
U1lTVEVNPXVua25vd24KK1VOQU1FX1ZFUlNJT049YCh1bmFtZSAtdikgMj4vZGV2L251bGxgIHx8
IFVOQU1FX1ZFUlNJT049dW5rbm93bgorCisjIE5vdGU6IG9yZGVyIGlzIHNpZ25pZmljYW50IC0g
dGhlIGNhc2UgYnJhbmNoZXMgYXJlIG5vdCBleGNsdXNpdmUuCisKK2Nhc2UgIiR7VU5BTUVfTUFD
SElORX06JHtVTkFNRV9TWVNURU19OiR7VU5BTUVfUkVMRUFTRX06JHtVTkFNRV9WRVJTSU9OfSIg
aW4KKyAgICAqOk5ldEJTRDoqOiopCisJIyBOZXRCU0QgKG5ic2QpIHRhcmdldHMgc2hvdWxkICh3
aGVyZSBhcHBsaWNhYmxlKSBtYXRjaCBvbmUgb3IKKwkjIG1vcmUgb2YgdGhlIHR1cHBsZXM6ICot
Ki1uZXRic2RlbGYqLCAqLSotbmV0YnNkYW91dCosCisJIyAqLSotbmV0YnNkZWNvZmYqIGFuZCAq
LSotbmV0YnNkKi4gIEZvciB0YXJnZXRzIHRoYXQgcmVjZW50bHkKKwkjIHN3aXRjaGVkIHRvIEVM
RiwgKi0qLW5ldGJzZCogd291bGQgc2VsZWN0IHRoZSBvbGQKKwkjIG9iamVjdCBmaWxlIGZvcm1h
dC4gIFRoaXMgcHJvdmlkZXMgYm90aCBmb3J3YXJkCisJIyBjb21wYXRpYmlsaXR5IGFuZCBhIGNv
bnNpc3RlbnQgbWVjaGFuaXNtIGZvciBzZWxlY3RpbmcgdGhlCisJIyBvYmplY3QgZmlsZSBmb3Jt
YXQuCisJIworCSMgTm90ZTogTmV0QlNEIGRvZXNuJ3QgcGFydGljdWxhcmx5IGNhcmUgYWJvdXQg
dGhlIHZlbmRvcgorCSMgcG9ydGlvbiBvZiB0aGUgbmFtZS4gIFdlIGFsd2F5cyBzZXQgaXQgdG8g
InVua25vd24iLgorCXN5c2N0bD0ic3lzY3RsIC1uIGh3Lm1hY2hpbmVfYXJjaCIKKwlVTkFNRV9N
QUNISU5FX0FSQ0g9YCgvc2Jpbi8kc3lzY3RsIDI+L2Rldi9udWxsIHx8IFwKKwkgICAgL3Vzci9z
YmluLyRzeXNjdGwgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duKWAKKwljYXNlICIke1VOQU1F
X01BQ0hJTkVfQVJDSH0iIGluCisJICAgIGFybWViKSBtYWNoaW5lPWFybWViLXVua25vd24gOzsK
KwkgICAgYXJtKikgbWFjaGluZT1hcm0tdW5rbm93biA7OworCSAgICBzaDNlbCkgbWFjaGluZT1z
aGwtdW5rbm93biA7OworCSAgICBzaDNlYikgbWFjaGluZT1zaC11bmtub3duIDs7CisJICAgIHNo
NWVsKSBtYWNoaW5lPXNoNWxlLXVua25vd24gOzsKKwkgICAgKikgbWFjaGluZT0ke1VOQU1FX01B
Q0hJTkVfQVJDSH0tdW5rbm93biA7OworCWVzYWMKKwkjIFRoZSBPcGVyYXRpbmcgU3lzdGVtIGlu
Y2x1ZGluZyBvYmplY3QgZm9ybWF0LCBpZiBpdCBoYXMgc3dpdGNoZWQKKwkjIHRvIEVMRiByZWNl
bnRseSwgb3Igd2lsbCBpbiB0aGUgZnV0dXJlLgorCWNhc2UgIiR7VU5BTUVfTUFDSElORV9BUkNI
fSIgaW4KKwkgICAgYXJtKnxpMzg2fG02OGt8bnMzMmt8c2gzKnxzcGFyY3x2YXgpCisJCWV2YWwg
JHNldF9jY19mb3JfYnVpbGQKKwkJaWYgZWNobyBfX0VMRl9fIHwgJENDX0ZPUl9CVUlMRCAtRSAt
IDI+L2Rldi9udWxsIFwKKwkJCXwgZ3JlcCAtcSBfX0VMRl9fCisJCXRoZW4KKwkJICAgICMgT25j
ZSBhbGwgdXRpbGl0aWVzIGNhbiBiZSBFQ09GRiAobmV0YnNkZWNvZmYpIG9yIGEub3V0IChuZXRi
c2Rhb3V0KS4KKwkJICAgICMgUmV0dXJuIG5ldGJzZCBmb3IgZWl0aGVyLiAgRklYPworCQkgICAg
b3M9bmV0YnNkCisJCWVsc2UKKwkJICAgIG9zPW5ldGJzZGVsZgorCQlmaQorCQk7OworCSAgICAq
KQorCSAgICAgICAgb3M9bmV0YnNkCisJCTs7CisJZXNhYworCSMgVGhlIE9TIHJlbGVhc2UKKwkj
IERlYmlhbiBHTlUvTmV0QlNEIG1hY2hpbmVzIGhhdmUgYSBkaWZmZXJlbnQgdXNlcmxhbmQsIGFu
ZAorCSMgdGh1cywgbmVlZCBhIGRpc3RpbmN0IHRyaXBsZXQuIEhvd2V2ZXIsIHRoZXkgZG8gbm90
IG5lZWQKKwkjIGtlcm5lbCB2ZXJzaW9uIGluZm9ybWF0aW9uLCBzbyBpdCBjYW4gYmUgcmVwbGFj
ZWQgd2l0aCBhCisJIyBzdWl0YWJsZSB0YWcsIGluIHRoZSBzdHlsZSBvZiBsaW51eC1nbnUuCisJ
Y2FzZSAiJHtVTkFNRV9WRVJTSU9OfSIgaW4KKwkgICAgRGViaWFuKikKKwkJcmVsZWFzZT0nLWdu
dScKKwkJOzsKKwkgICAgKikKKwkJcmVsZWFzZT1gZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAt
ZSAncy9bLV9dLiovXC4vJ2AKKwkJOzsKKwllc2FjCisJIyBTaW5jZSBDUFVfVFlQRS1NQU5VRkFD
VFVSRVItS0VSTkVMLU9QRVJBVElOR19TWVNURU06CisJIyBjb250YWlucyByZWR1bmRhbnQgaW5m
b3JtYXRpb24sIHRoZSBzaG9ydGVyIGZvcm06CisJIyBDUFVfVFlQRS1NQU5VRkFDVFVSRVItT1BF
UkFUSU5HX1NZU1RFTSBpcyB1c2VkLgorCWVjaG8gIiR7bWFjaGluZX0tJHtvc30ke3JlbGVhc2V9
IgorCWV4aXQgOzsKKyAgICAqOk9wZW5CU0Q6KjoqKQorCVVOQU1FX01BQ0hJTkVfQVJDSD1gYXJj
aCB8IHNlZCAncy9PcGVuQlNELi8vJ2AKKwllY2hvICR7VU5BTUVfTUFDSElORV9BUkNIfS11bmtu
b3duLW9wZW5ic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6ZWtrb0JTRDoqOiop
CisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tZWtrb2JzZCR7VU5BTUVfUkVMRUFTRX0K
KwlleGl0IDs7CisgICAgKjpTb2xpZEJTRDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tc29saWRic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG1hY3BwYzpNaXJC
U0Q6KjoqKQorCWVjaG8gcG93ZXJwYy11bmtub3duLW1pcmJzZCR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgKjpNaXJCU0Q6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3du
LW1pcmJzZCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgYWxwaGE6T1NGMToqOiopCisJ
Y2FzZSAkVU5BTUVfUkVMRUFTRSBpbgorCSo0LjApCisJCVVOQU1FX1JFTEVBU0U9YC91c3Ivc2Jp
bi9zaXplciAtdiB8IGF3ayAne3ByaW50ICQzfSdgCisJCTs7CisJKjUuKikKKwkgICAgICAgIFVO
QU1FX1JFTEVBU0U9YC91c3Ivc2Jpbi9zaXplciAtdiB8IGF3ayAne3ByaW50ICQ0fSdgCisJCTs7
CisJZXNhYworCSMgQWNjb3JkaW5nIHRvIENvbXBhcSwgL3Vzci9zYmluL3BzcmluZm8gaGFzIGJl
ZW4gYXZhaWxhYmxlIG9uCisJIyBPU0YvMSBhbmQgVHJ1NjQgc3lzdGVtcyBwcm9kdWNlZCBzaW5j
ZSAxOTk1LiAgSSBob3BlIHRoYXQKKwkjIGNvdmVycyBtb3N0IHN5c3RlbXMgcnVubmluZyB0b2Rh
eS4gIFRoaXMgY29kZSBwaXBlcyB0aGUgQ1BVCisJIyB0eXBlcyB0aHJvdWdoIGhlYWQgLW4gMSwg
c28gd2Ugb25seSBkZXRlY3QgdGhlIHR5cGUgb2YgQ1BVIDAuCisJQUxQSEFfQ1BVX1RZUEU9YC91
c3Ivc2Jpbi9wc3JpbmZvIC12IHwgc2VkIC1uIC1lICdzL14gIFRoZSBhbHBoYSBcKC4qXCkgcHJv
Y2Vzc29yLiokL1wxL3AnIHwgaGVhZCAtbiAxYAorCWNhc2UgIiRBTFBIQV9DUFVfVFlQRSIgaW4K
KwkgICAgIkVWNCAoMjEwNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGEiIDs7CisJICAgICJF
VjQuNSAoMjEwNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGEiIDs7CisJICAgICJMQ0E0ICgy
MTA2Ni8yMTA2OCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIgOzsKKwkgICAgIkVWNSAoMjEx
NjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjUiIDs7CisJICAgICJFVjUuNiAoMjExNjRB
KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY1NiIgOzsKKwkgICAgIkVWNS42ICgyMTE2NFBD
KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhcGNhNTYiIDs7CisJICAgICJFVjUuNyAoMjExNjRQ
QykiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYXBjYTU3IiA7OworCSAgICAiRVY2ICgyMTI2NCki
KQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NiIgOzsKKwkgICAgIkVWNi43ICgyMTI2NEEpIikK
KwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY3IiA7OworCSAgICAiRVY2LjhDQiAoMjEyNjRDKSIp
CisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2OCIgOzsKKwkgICAgIkVWNi44QUwgKDIxMjY0Qiki
KQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjgiIDs7CisJICAgICJFVjYuOENYICgyMTI2NEQp
IikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY4IiA7OworCSAgICAiRVY2LjlBICgyMTI2NC9F
VjY5QSkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjkiIDs7CisJICAgICJFVjcgKDIxMzY0
KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY3IiA7OworCSAgICAiRVY3LjkgKDIxMzY0QSki
KQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NzkiIDs7CisJZXNhYworCSMgQSBQbi5uIHZlcnNp
b24gaXMgYSBwYXRjaGVkIHZlcnNpb24uCisJIyBBIFZuLm4gdmVyc2lvbiBpcyBhIHJlbGVhc2Vk
IHZlcnNpb24uCisJIyBBIFRuLm4gdmVyc2lvbiBpcyBhIHJlbGVhc2VkIGZpZWxkIHRlc3QgdmVy
c2lvbi4KKwkjIEEgWG4ubiB2ZXJzaW9uIGlzIGFuIHVucmVsZWFzZWQgZXhwZXJpbWVudGFsIGJh
c2VsZXZlbC4KKwkjIDEuMiB1c2VzICIxLjIiIGZvciB1bmFtZSAtci4KKwllY2hvICR7VU5BTUVf
TUFDSElORX0tZGVjLW9zZmBlY2hvICR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXltQVlRY
XS8vJyB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3Bx
cnN0dXZ3eHl6J2AKKwlleGl0IDs7CisgICAgQWxwaGFcICo6V2luZG93c19OVCo6KikKKwkjIEhv
dyBkbyB3ZSBrbm93IGl0J3MgSW50ZXJpeCByYXRoZXIgdGhhbiB0aGUgZ2VuZXJpYyBQT1NJWCBz
dWJzeXN0ZW0/CisJIyBTaG91bGQgd2UgY2hhbmdlIFVOQU1FX01BQ0hJTkUgYmFzZWQgb24gdGhl
IG91dHB1dCBvZiB1bmFtZSBpbnN0ZWFkCisJIyBvZiB0aGUgc3BlY2lmaWMgQWxwaGEgbW9kZWw/
CisJZWNobyBhbHBoYS1wYy1pbnRlcml4CisJZXhpdCA7OworICAgIDIxMDY0OldpbmRvd3NfTlQ6
NTA6MykKKwllY2hvIGFscGhhLWRlYy13aW5udDMuNQorCWV4aXQgOzsKKyAgICBBbWlnYSo6VU5J
WF9TeXN0ZW1fVjo0LjA6KikKKwllY2hvIG02OGstdW5rbm93bi1zeXN2NAorCWV4aXQgOzsKKyAg
ICAqOltBYV1taWdhW09vXVtTc106KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3du
LWFtaWdhb3MKKwlleGl0IDs7CisgICAgKjpbTW1db3JwaFtPb11bU3NdOio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0tdW5rbm93bi1tb3JwaG9zCisJZXhpdCA7OworICAgICo6T1MvMzkwOio6
KikKKwllY2hvIGkzNzAtaWJtLW9wZW5lZGl0aW9uCisJZXhpdCA7OworICAgICo6ei9WTToqOiop
CisJZWNobyBzMzkwLWlibS16dm1vZQorCWV4aXQgOzsKKyAgICAqOk9TNDAwOio6KikKKyAgICAg
ICAgZWNobyBwb3dlcnBjLWlibS1vczQwMAorCWV4aXQgOzsKKyAgICBhcm06UklTQyo6MS5bMDEy
XSo6Knxhcm06cmlzY2l4OjEuWzAxMl0qOiopCisJZWNobyBhcm0tYWNvcm4tcmlzY2l4JHtVTkFN
RV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBhcm06cmlzY29zOio6Knxhcm06UklTQ09TOio6KikK
KwllY2hvIGFybS11bmtub3duLXJpc2NvcworCWV4aXQgOzsKKyAgICBTUjI/MDE6SEktVVgvTVBQ
Oio6KiB8IFNSODAwMDpISS1VWC9NUFA6KjoqKQorCWVjaG8gaHBwYTEuMS1oaXRhY2hpLWhpdXht
cHAKKwlleGl0IDs7CisgICAgUHlyYW1pZCo6T1N4KjoqOiogfCBNSVMqOk9TeCo6KjoqIHwgTUlT
KjpTTVBfREMtT1N4KjoqOiopCisJIyBha2VlQHdwZGlzMDMud3BhZmIuYWYubWlsIChFYXJsZSBG
LiBBa2UpIGNvbnRyaWJ1dGVkIE1JUyBhbmQgTklMRS4KKwlpZiB0ZXN0ICJgKC9iaW4vdW5pdmVy
c2UpIDI+L2Rldi9udWxsYCIgPSBhdHQgOyB0aGVuCisJCWVjaG8gcHlyYW1pZC1weXJhbWlkLXN5
c3YzCisJZWxzZQorCQllY2hvIHB5cmFtaWQtcHlyYW1pZC1ic2QKKwlmaQorCWV4aXQgOzsKKyAg
ICBOSUxFKjoqOio6ZGNvc3gpCisJZWNobyBweXJhbWlkLXB5cmFtaWQtc3ZyNAorCWV4aXQgOzsK
KyAgICBEUlM/NjAwMDp1bml4OjQuMDo2KikKKwllY2hvIHNwYXJjLWljbC1ueDYKKwlleGl0IDs7
CisgICAgRFJTPzYwMDA6VU5JWF9TVjo0LjIqOjcqIHwgRFJTPzYwMDA6aXNpczo0LjIqOjcqKQor
CWNhc2UgYC91c3IvYmluL3VuYW1lIC1wYCBpbgorCSAgICBzcGFyYykgZWNobyBzcGFyYy1pY2wt
bng3OyBleGl0IDs7CisJZXNhYyA7OworICAgIHMzOTB4OlN1bk9TOio6KikKKwllY2hvICR7VU5B
TUVfTUFDSElORX0taWJtLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3Mv
W14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjRIOlN1bk9TOjUuKjoqKQorCWVjaG8gc3BhcmMt
aGFsLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvW14uXSovLydgCisJ
ZXhpdCA7OworICAgIHN1bjQqOlN1bk9TOjUuKjoqIHwgdGFkcG9sZSo6U3VuT1M6NS4qOiopCisJ
ZWNobyBzcGFyYy1zdW4tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9b
Xi5dKi8vJ2AKKwlleGl0IDs7CisgICAgaTg2cGM6QXVyb3JhVVg6NS4qOiogfCBpODZ4ZW46QXVy
b3JhVVg6NS4qOiopCisJZWNobyBpMzg2LXBjLWF1cm9yYXV4JHtVTkFNRV9SRUxFQVNFfQorCWV4
aXQgOzsKKyAgICBpODZwYzpTdW5PUzo1Lio6KiB8IGk4NnhlbjpTdW5PUzo1Lio6KikKKwlldmFs
ICRzZXRfY2NfZm9yX2J1aWxkCisJU1VOX0FSQ0g9ImkzODYiCisJIyBJZiB0aGVyZSBpcyBhIGNv
bXBpbGVyLCBzZWUgaWYgaXQgaXMgY29uZmlndXJlZCBmb3IgNjQtYml0IG9iamVjdHMuCisJIyBO
b3RlIHRoYXQgdGhlIFN1biBjYyBkb2VzIG5vdCB0dXJuIF9fTFA2NF9fIGludG8gMSBsaWtlIGdj
YyBkb2VzLgorCSMgVGhpcyB0ZXN0IHdvcmtzIGZvciBib3RoIGNvbXBpbGVycy4KKwlpZiBbICIk
Q0NfRk9SX0JVSUxEIiAhPSAnbm9fY29tcGlsZXJfZm91bmQnIF07IHRoZW4KKwkgICAgaWYgKGVj
aG8gJyNpZmRlZiBfX2FtZDY0JzsgZWNobyBJU182NEJJVF9BUkNIOyBlY2hvICcjZW5kaWYnKSB8
IFwKKwkJKENDT1BUUz0gJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxsKSB8IFwKKwkJZ3Jl
cCBJU182NEJJVF9BUkNIID4vZGV2L251bGwKKwkgICAgdGhlbgorCQlTVU5fQVJDSD0ieDg2XzY0
IgorCSAgICBmaQorCWZpCisJZWNobyAke1NVTl9BUkNIfS1wYy1zb2xhcmlzMmBlY2hvICR7VU5B
TUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLy8nYAorCWV4aXQgOzsKKyAgICBzdW40KjpTdW5P
Uzo2KjoqKQorCSMgQWNjb3JkaW5nIHRvIGNvbmZpZy5zdWIsIHRoaXMgaXMgdGhlIHByb3BlciB3
YXkgdG8gY2Fub25pY2FsaXplCisJIyBTdW5PUzYuICBIYXJkIHRvIGd1ZXNzIGV4YWN0bHkgd2hh
dCBTdW5PUzYgd2lsbCBiZSBsaWtlLCBidXQKKwkjIGl0J3MgbGlrZWx5IHRvIGJlIG1vcmUgbGlr
ZSBTb2xhcmlzIHRoYW4gU3VuT1M0LgorCWVjaG8gc3BhcmMtc3VuLXNvbGFyaXMzYGVjaG8gJHtV
TkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjQqOlN1
bk9TOio6KikKKwljYXNlICJgL3Vzci9iaW4vYXJjaCAta2AiIGluCisJICAgIFNlcmllcyp8UzQq
KQorCQlVTkFNRV9SRUxFQVNFPWB1bmFtZSAtdmAKKwkJOzsKKwllc2FjCisJIyBKYXBhbmVzZSBM
YW5ndWFnZSB2ZXJzaW9ucyBoYXZlIGEgdmVyc2lvbiBudW1iZXIgbGlrZSBgNC4xLjMtSkwnLgor
CWVjaG8gc3BhcmMtc3VuLXN1bm9zYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvLS9f
LydgCisJZXhpdCA7OworICAgIHN1bjMqOlN1bk9TOio6KikKKwllY2hvIG02OGstc3VuLXN1bm9z
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBzdW4qOio6NC4yQlNEOiopCisJVU5BTUVf
UkVMRUFTRT1gKHNlZCAxcSAvZXRjL21vdGQgfCBhd2sgJ3twcmludCBzdWJzdHIoJDUsMSwzKX0n
KSAyPi9kZXYvbnVsbGAKKwl0ZXN0ICJ4JHtVTkFNRV9SRUxFQVNFfSIgPSAieCIgJiYgVU5BTUVf
UkVMRUFTRT0zCisJY2FzZSAiYC9iaW4vYXJjaGAiIGluCisJICAgIHN1bjMpCisJCWVjaG8gbTY4
ay1zdW4tc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJCTs7CisJICAgIHN1bjQpCisJCWVjaG8gc3Bh
cmMtc3VuLXN1bm9zJHtVTkFNRV9SRUxFQVNFfQorCQk7OworCWVzYWMKKwlleGl0IDs7CisgICAg
YXVzaHA6U3VuT1M6KjoqKQorCWVjaG8gc3BhcmMtYXVzcGV4LXN1bm9zJHtVTkFNRV9SRUxFQVNF
fQorCWV4aXQgOzsKKyAgICAjIFRoZSBzaXR1YXRpb24gZm9yIE1pTlQgaXMgYSBsaXR0bGUgY29u
ZnVzaW5nLiAgVGhlIG1hY2hpbmUgbmFtZQorICAgICMgY2FuIGJlIHZpcnR1YWxseSBldmVyeXRo
aW5nIChldmVyeXRoaW5nIHdoaWNoIGlzIG5vdAorICAgICMgImF0YXJpc3QiIG9yICJhdGFyaXN0
ZSIgYXQgbGVhc3Qgc2hvdWxkIGhhdmUgYSBwcm9jZXNzb3IKKyAgICAjID4gbTY4MDAwKS4gIFRo
ZSBzeXN0ZW0gbmFtZSByYW5nZXMgZnJvbSAiTWlOVCIgb3ZlciAiRnJlZU1pTlQiCisgICAgIyB0
byB0aGUgbG93ZXJjYXNlIHZlcnNpb24gIm1pbnQiIChvciAiZnJlZW1pbnQiKS4gIEZpbmFsbHkK
KyAgICAjIHRoZSBzeXN0ZW0gbmFtZSAiVE9TIiBkZW5vdGVzIGEgc3lzdGVtIHdoaWNoIGlzIGFj
dHVhbGx5IG5vdAorICAgICMgTWlOVC4gIEJ1dCBNaU5UIGlzIGRvd253YXJkIGNvbXBhdGlibGUg
dG8gVE9TLCBzbyB0aGlzIHNob3VsZAorICAgICMgYmUgbm8gcHJvYmxlbS4KKyAgICBhdGFyaXN0
W2VdOipNaU5UOio6KiB8IGF0YXJpc3RbZV06Km1pbnQ6KjoqIHwgYXRhcmlzdFtlXToqVE9TOio6
KikKKyAgICAgICAgZWNobyBtNjhrLWF0YXJpLW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIGF0YXJpKjoqTWlOVDoqOiogfCBhdGFyaSo6Km1pbnQ6KjoqIHwgYXRhcmlzdFtlXToq
VE9TOio6KikKKwllY2hvIG02OGstYXRhcmktbWludCR7VU5BTUVfUkVMRUFTRX0KKyAgICAgICAg
ZXhpdCA7OworICAgICpmYWxjb24qOipNaU5UOio6KiB8ICpmYWxjb24qOiptaW50Oio6KiB8ICpm
YWxjb24qOipUT1M6KjoqKQorICAgICAgICBlY2hvIG02OGstYXRhcmktbWludCR7VU5BTUVfUkVM
RUFTRX0KKwlleGl0IDs7CisgICAgbWlsYW4qOipNaU5UOio6KiB8IG1pbGFuKjoqbWludDoqOiog
fCAqbWlsYW4qOipUT1M6KjoqKQorICAgICAgICBlY2hvIG02OGstbWlsYW4tbWludCR7VU5BTUVf
UkVMRUFTRX0KKyAgICAgICAgZXhpdCA7OworICAgIGhhZGVzKjoqTWlOVDoqOiogfCBoYWRlcyo6
Km1pbnQ6KjoqIHwgKmhhZGVzKjoqVE9TOio6KikKKyAgICAgICAgZWNobyBtNjhrLWhhZGVzLW1p
bnQke1VOQU1FX1JFTEVBU0V9CisgICAgICAgIGV4aXQgOzsKKyAgICAqOipNaU5UOio6KiB8ICo6
Km1pbnQ6KjoqIHwgKjoqVE9TOio6KikKKyAgICAgICAgZWNobyBtNjhrLXVua25vd24tbWludCR7
VU5BTUVfUkVMRUFTRX0KKyAgICAgICAgZXhpdCA7OworICAgIG02OGs6bWFjaHRlbjoqOiopCisJ
ZWNobyBtNjhrLWFwcGxlLW1hY2h0ZW4ke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIHBv
d2VycGM6bWFjaHRlbjoqOiopCisJZWNobyBwb3dlcnBjLWFwcGxlLW1hY2h0ZW4ke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIFJJU0MqOk1hY2g6KjoqKQorCWVjaG8gbWlwcy1kZWMtbWFj
aF9ic2Q0LjMKKwlleGl0IDs7CisgICAgUklTQyo6VUxUUklYOio6KikKKwllY2hvIG1pcHMtZGVj
LXVsdHJpeCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgVkFYKjpVTFRSSVgqOio6KikK
KwllY2hvIHZheC1kZWMtdWx0cml4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAyMDIw
OkNMSVg6KjoqIHwgMjQzMDpDTElYOio6KikKKwllY2hvIGNsaXBwZXItaW50ZXJncmFwaC1jbGl4
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBtaXBzOio6KjpVTUlQUyB8IG1pcHM6Kjoq
OlJJU0NvcykKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14JLy8nIDw8IEVPRiA+
JGR1bW15LmMKKyNpZmRlZiBfX2NwbHVzcGx1cworI2luY2x1ZGUgPHN0ZGlvLmg+ICAvKiBmb3Ig
cHJpbnRmKCkgcHJvdG90eXBlICovCisJaW50IG1haW4gKGludCBhcmdjLCBjaGFyICphcmd2W10p
IHsKKyNlbHNlCisJaW50IG1haW4gKGFyZ2MsIGFyZ3YpIGludCBhcmdjOyBjaGFyICphcmd2W107
IHsKKyNlbmRpZgorCSNpZiBkZWZpbmVkIChob3N0X21pcHMpICYmIGRlZmluZWQgKE1JUFNFQikK
KwkjaWYgZGVmaW5lZCAoU1lTVFlQRV9TWVNWKQorCSAgcHJpbnRmICgibWlwcy1taXBzLXJpc2Nv
cyVzc3lzdlxuIiwgYXJndlsxXSk7IGV4aXQgKDApOworCSNlbmRpZgorCSNpZiBkZWZpbmVkIChT
WVNUWVBFX1NWUjQpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNzdnI0XG4iLCBhcmd2
WzFdKTsgZXhpdCAoMCk7CisJI2VuZGlmCisJI2lmIGRlZmluZWQgKFNZU1RZUEVfQlNENDMpIHx8
IGRlZmluZWQoU1lTVFlQRV9CU0QpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNic2Rc
biIsIGFyZ3ZbMV0pOyBleGl0ICgwKTsKKwkjZW5kaWYKKwkjZW5kaWYKKwkgIGV4aXQgKC0xKTsK
Kwl9CitFT0YKKwkkQ0NfRk9SX0JVSUxEIC1vICRkdW1teSAkZHVtbXkuYyAmJgorCSAgZHVtbXlh
cmc9YGVjaG8gIiR7VU5BTUVfUkVMRUFTRX0iIHwgc2VkIC1uICdzL1woWzAtOV0qXCkuKi9cMS9w
J2AgJiYKKwkgIFNZU1RFTV9OQU1FPWAkZHVtbXkgJGR1bW15YXJnYCAmJgorCSAgICB7IGVjaG8g
IiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKwllY2hvIG1pcHMtbWlwcy1yaXNjb3Mke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIE1vdG9yb2xhOlBvd2VyTUFYX09TOio6KikKKwllY2hvIHBv
d2VycGMtbW90b3JvbGEtcG93ZXJtYXgKKwlleGl0IDs7CisgICAgTW90b3JvbGE6Kjo0LjM6UEw4
LSopCisJZWNobyBwb3dlcnBjLWhhcnJpcy1wb3dlcm1heAorCWV4aXQgOzsKKyAgICBOaWdodF9I
YXdrOio6KjpQb3dlck1BWF9PUyB8IFN5bmVyZ3k6UG93ZXJNQVhfT1M6KjoqKQorCWVjaG8gcG93
ZXJwYy1oYXJyaXMtcG93ZXJtYXgKKwlleGl0IDs7CisgICAgTmlnaHRfSGF3azpQb3dlcl9VTklY
Oio6KikKKwllY2hvIHBvd2VycGMtaGFycmlzLXBvd2VydW5peAorCWV4aXQgOzsKKyAgICBtODhr
OkNYL1VYOjcqOiopCisJZWNobyBtODhrLWhhcnJpcy1jeHV4NworCWV4aXQgOzsKKyAgICBtODhr
Oio6NCo6UjQqKQorCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2NAorCWV4aXQgOzsKKyAgICBtODhr
Oio6Myo6UjMqKQorCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2MworCWV4aXQgOzsKKyAgICBBVmlp
T046ZGd1eDoqOiopCisgICAgICAgICMgREcvVVggcmV0dXJucyBBVmlpT04gZm9yIGFsbCBhcmNo
aXRlY3R1cmVzCisgICAgICAgIFVOQU1FX1BST0NFU1NPUj1gL3Vzci9iaW4vdW5hbWUgLXBgCisJ
aWYgWyAkVU5BTUVfUFJPQ0VTU09SID0gbWM4ODEwMCBdIHx8IFsgJFVOQU1FX1BST0NFU1NPUiA9
IG1jODgxMTAgXQorCXRoZW4KKwkgICAgaWYgWyAke1RBUkdFVF9CSU5BUllfSU5URVJGQUNFfXgg
PSBtODhrZGd1eGVsZnggXSB8fCBcCisJICAgICAgIFsgJHtUQVJHRVRfQklOQVJZX0lOVEVSRkFD
RX14ID0geCBdCisJICAgIHRoZW4KKwkJZWNobyBtODhrLWRnLWRndXgke1VOQU1FX1JFTEVBU0V9
CisJICAgIGVsc2UKKwkJZWNobyBtODhrLWRnLWRndXhiY3Mke1VOQU1FX1JFTEVBU0V9CisJICAg
IGZpCisJZWxzZQorCSAgICBlY2hvIGk1ODYtZGctZGd1eCR7VU5BTUVfUkVMRUFTRX0KKwlmaQor
IAlleGl0IDs7CisgICAgTTg4KjpEb2xwaGluT1M6KjoqKQkjIERvbHBoaW5PUyAoU1ZSMykKKwll
Y2hvIG04OGstZG9scGhpbi1zeXN2MworCWV4aXQgOzsKKyAgICBNODgqOio6UjMqOiopCisJIyBE
ZWx0YSA4OGsgc3lzdGVtIHJ1bm5pbmcgU1ZSMworCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2Mwor
CWV4aXQgOzsKKyAgICBYRDg4KjoqOio6KikgIyBUZWt0cm9uaXggWEQ4OCBzeXN0ZW0gcnVubmlu
ZyBVVGVrViAoU1ZSMykKKwllY2hvIG04OGstdGVrdHJvbml4LXN5c3YzCisJZXhpdCA7OworICAg
IFRlazQzWzAtOV1bMC05XTpVVGVrOio6KikgIyBUZWt0cm9uaXggNDMwMCBzeXN0ZW0gcnVubmlu
ZyBVVGVrIChCU0QpCisJZWNobyBtNjhrLXRla3Ryb25peC1ic2QKKwlleGl0IDs7CisgICAgKjpJ
UklYKjoqOiopCisJZWNobyBtaXBzLXNnaS1pcml4YGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQg
LWUgJ3MvLS9fL2cnYAorCWV4aXQgOzsKKyAgICA/Pz8/Pz8/PzpBSVg/OlsxMl0uMToyKSAgICMg
QUlYIDIuMi4xIG9yIEFJWCAyLjEuMSBpcyBSVC9QQyBBSVguCisJZWNobyByb21wLWlibS1haXgg
ICAgICMgdW5hbWUgLW0gZ2l2ZXMgYW4gOCBoZXgtY29kZSBDUFUgaWQKKwlleGl0IDs7ICAgICAg
ICAgICAgICAgIyBOb3RlIHRoYXQ6IGVjaG8gIidgdW5hbWUgLXNgJyIgZ2l2ZXMgJ0FJWCAnCisg
ICAgaSo4NjpBSVg6KjoqKQorCWVjaG8gaTM4Ni1pYm0tYWl4CisJZXhpdCA7OworICAgIGlhNjQ6
QUlYOio6KikKKwlpZiBbIC14IC91c3IvYmluL29zbGV2ZWwgXSA7IHRoZW4KKwkJSUJNX1JFVj1g
L3Vzci9iaW4vb3NsZXZlbGAKKwllbHNlCisJCUlCTV9SRVY9JHtVTkFNRV9WRVJTSU9OfS4ke1VO
QU1FX1JFTEVBU0V9CisJZmkKKwllY2hvICR7VU5BTUVfTUFDSElORX0taWJtLWFpeCR7SUJNX1JF
Vn0KKwlleGl0IDs7CisgICAgKjpBSVg6MjozKQorCWlmIGdyZXAgYm9zMzI1IC91c3IvaW5jbHVk
ZS9zdGRpby5oID4vZGV2L251bGwgMj4mMTsgdGhlbgorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxk
CisJCXNlZCAncy9eCQkvLycgPDwgRU9GID4kZHVtbXkuYworCQkjaW5jbHVkZSA8c3lzL3N5c3Rl
bWNmZy5oPgorCisJCW1haW4oKQorCQkJeworCQkJaWYgKCFfX3Bvd2VyX3BjKCkpCisJCQkJZXhp
dCgxKTsKKwkJCXB1dHMoInBvd2VycGMtaWJtLWFpeDMuMi41Iik7CisJCQlleGl0KDApOworCQkJ
fQorRU9GCisJCWlmICRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmIFNZU1RFTV9O
QU1FPWAkZHVtbXlgCisJCXRoZW4KKwkJCWVjaG8gIiRTWVNURU1fTkFNRSIKKwkJZWxzZQorCQkJ
ZWNobyByczYwMDAtaWJtLWFpeDMuMi41CisJCWZpCisJZWxpZiBncmVwIGJvczMyNCAvdXNyL2lu
Y2x1ZGUvc3RkaW8uaCA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKwkJZWNobyByczYwMDAtaWJtLWFp
eDMuMi40CisJZWxzZQorCQllY2hvIHJzNjAwMC1pYm0tYWl4My4yCisJZmkKKwlleGl0IDs7Cisg
ICAgKjpBSVg6KjpbNDU2XSkKKwlJQk1fQ1BVX0lEPWAvdXNyL3NiaW4vbHNkZXYgLUMgLWMgcHJv
Y2Vzc29yIC1TIGF2YWlsYWJsZSB8IHNlZCAxcSB8IGF3ayAneyBwcmludCAkMSB9J2AKKwlpZiAv
dXNyL3NiaW4vbHNhdHRyIC1FbCAke0lCTV9DUFVfSUR9IHwgZ3JlcCAnIFBPV0VSJyA+L2Rldi9u
dWxsIDI+JjE7IHRoZW4KKwkJSUJNX0FSQ0g9cnM2MDAwCisJZWxzZQorCQlJQk1fQVJDSD1wb3dl
cnBjCisJZmkKKwlpZiBbIC14IC91c3IvYmluL29zbGV2ZWwgXSA7IHRoZW4KKwkJSUJNX1JFVj1g
L3Vzci9iaW4vb3NsZXZlbGAKKwllbHNlCisJCUlCTV9SRVY9JHtVTkFNRV9WRVJTSU9OfS4ke1VO
QU1FX1JFTEVBU0V9CisJZmkKKwllY2hvICR7SUJNX0FSQ0h9LWlibS1haXgke0lCTV9SRVZ9CisJ
ZXhpdCA7OworICAgICo6QUlYOio6KikKKwllY2hvIHJzNjAwMC1pYm0tYWl4CisJZXhpdCA7Owor
ICAgIGlibXJ0OjQuNEJTRDoqfHJvbXAtaWJtOkJTRDoqKQorCWVjaG8gcm9tcC1pYm0tYnNkNC40
CisJZXhpdCA7OworICAgIGlibXJ0OipCU0Q6Knxyb21wLWlibTpCU0Q6KikgICAgICAgICAgICAj
IGNvdmVycyBSVC9QQyBCU0QgYW5kCisJZWNobyByb21wLWlibS1ic2Qke1VOQU1FX1JFTEVBU0V9
ICAgIyA0LjMgd2l0aCB1bmFtZSBhZGRlZCB0bworCWV4aXQgOzsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICMgcmVwb3J0OiByb21wLWlibSBCU0QgNC4zCisgICAgKjpCT1NYOio6KikKKwll
Y2hvIHJzNjAwMC1idWxsLWJvc3gKKwlleGl0IDs7CisgICAgRFBYLzI/MDA6Qi5PLlMuOio6KikK
KwllY2hvIG02OGstYnVsbC1zeXN2MworCWV4aXQgOzsKKyAgICA5MDAwL1szNF0/Pzo0LjNic2Q6
MS4qOiopCisJZWNobyBtNjhrLWhwLWJzZAorCWV4aXQgOzsKKyAgICBocDMwMDo0LjRCU0Q6Kjoq
IHwgOTAwMC9bMzRdPz86NC4zYnNkOjIuKjoqKQorCWVjaG8gbTY4ay1ocC1ic2Q0LjQKKwlleGl0
IDs7CisgICAgOTAwMC9bMzQ2NzhdPz86SFAtVVg6KjoqKQorCUhQVVhfUkVWPWBlY2hvICR7VU5B
TUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLlswQl0qLy8nYAorCWNhc2UgIiR7VU5BTUVfTUFD
SElORX0iIGluCisJICAgIDkwMDAvMzE/ICkgICAgICAgICAgICBIUF9BUkNIPW02ODAwMCA7Owor
CSAgICA5MDAwL1szNF0/PyApICAgICAgICAgSFBfQVJDSD1tNjhrIDs7CisJICAgIDkwMDAvWzY3
OF1bMC05XVswLTldKQorCQlpZiBbIC14IC91c3IvYmluL2dldGNvbmYgXTsgdGhlbgorCQkgICAg
c2NfY3B1X3ZlcnNpb249YC91c3IvYmluL2dldGNvbmYgU0NfQ1BVX1ZFUlNJT04gMj4vZGV2L251
bGxgCisgICAgICAgICAgICAgICAgICAgIHNjX2tlcm5lbF9iaXRzPWAvdXNyL2Jpbi9nZXRjb25m
IFNDX0tFUk5FTF9CSVRTIDI+L2Rldi9udWxsYAorICAgICAgICAgICAgICAgICAgICBjYXNlICIk
e3NjX2NwdV92ZXJzaW9ufSIgaW4KKyAgICAgICAgICAgICAgICAgICAgICA1MjMpIEhQX0FSQ0g9
ImhwcGExLjAiIDs7ICMgQ1BVX1BBX1JJU0MxXzAKKyAgICAgICAgICAgICAgICAgICAgICA1Mjgp
IEhQX0FSQ0g9ImhwcGExLjEiIDs7ICMgQ1BVX1BBX1JJU0MxXzEKKyAgICAgICAgICAgICAgICAg
ICAgICA1MzIpICAgICAgICAgICAgICAgICAgICAgICMgQ1BVX1BBX1JJU0MyXzAKKyAgICAgICAg
ICAgICAgICAgICAgICAgIGNhc2UgIiR7c2Nfa2VybmVsX2JpdHN9IiBpbgorICAgICAgICAgICAg
ICAgICAgICAgICAgICAzMikgSFBfQVJDSD0iaHBwYTIuMG4iIDs7CisgICAgICAgICAgICAgICAg
ICAgICAgICAgIDY0KSBIUF9BUkNIPSJocHBhMi4wdyIgOzsKKwkJCSAgJycpIEhQX0FSQ0g9Imhw
cGEyLjAiIDs7ICAgIyBIUC1VWCAxMC4yMAorICAgICAgICAgICAgICAgICAgICAgICAgZXNhYyA7
OworICAgICAgICAgICAgICAgICAgICBlc2FjCisJCWZpCisJCWlmIFsgIiR7SFBfQVJDSH0iID0g
IiIgXTsgdGhlbgorCQkgICAgZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAorCQkgICAgc2VkICdzL14g
ICAgICAgICAgICAgIC8vJyA8PCBFT0YgPiRkdW1teS5jCisKKyAgICAgICAgICAgICAgI2RlZmlu
ZSBfSFBVWF9TT1VSQ0UKKyAgICAgICAgICAgICAgI2luY2x1ZGUgPHN0ZGxpYi5oPgorICAgICAg
ICAgICAgICAjaW5jbHVkZSA8dW5pc3RkLmg+CisKKyAgICAgICAgICAgICAgaW50IG1haW4gKCkK
KyAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAjaWYgZGVmaW5lZChfU0NfS0VSTkVMX0JJ
VFMpCisgICAgICAgICAgICAgICAgICBsb25nIGJpdHMgPSBzeXNjb25mKF9TQ19LRVJORUxfQklU
Uyk7CisgICAgICAgICAgICAgICNlbmRpZgorICAgICAgICAgICAgICAgICAgbG9uZyBjcHUgID0g
c3lzY29uZiAoX1NDX0NQVV9WRVJTSU9OKTsKKworICAgICAgICAgICAgICAgICAgc3dpdGNoIChj
cHUpCisgICAgICAgICAgICAgIAl7CisgICAgICAgICAgICAgIAljYXNlIENQVV9QQV9SSVNDMV8w
OiBwdXRzICgiaHBwYTEuMCIpOyBicmVhazsKKyAgICAgICAgICAgICAgCWNhc2UgQ1BVX1BBX1JJ
U0MxXzE6IHB1dHMgKCJocHBhMS4xIik7IGJyZWFrOworICAgICAgICAgICAgICAJY2FzZSBDUFVf
UEFfUklTQzJfMDoKKyAgICAgICAgICAgICAgI2lmIGRlZmluZWQoX1NDX0tFUk5FTF9CSVRTKQor
ICAgICAgICAgICAgICAJICAgIHN3aXRjaCAoYml0cykKKyAgICAgICAgICAgICAgCQl7CisgICAg
ICAgICAgICAgIAkJY2FzZSA2NDogcHV0cyAoImhwcGEyLjB3Iik7IGJyZWFrOworICAgICAgICAg
ICAgICAJCWNhc2UgMzI6IHB1dHMgKCJocHBhMi4wbiIpOyBicmVhazsKKyAgICAgICAgICAgICAg
CQlkZWZhdWx0OiBwdXRzICgiaHBwYTIuMCIpOyBicmVhazsKKyAgICAgICAgICAgICAgCQl9IGJy
ZWFrOworICAgICAgICAgICAgICAjZWxzZSAgLyogIWRlZmluZWQoX1NDX0tFUk5FTF9CSVRTKSAq
LworICAgICAgICAgICAgICAJICAgIHB1dHMgKCJocHBhMi4wIik7IGJyZWFrOworICAgICAgICAg
ICAgICAjZW5kaWYKKyAgICAgICAgICAgICAgCWRlZmF1bHQ6IHB1dHMgKCJocHBhMS4wIik7IGJy
ZWFrOworICAgICAgICAgICAgICAJfQorICAgICAgICAgICAgICAgICAgZXhpdCAoMCk7CisgICAg
ICAgICAgICAgIH0KK0VPRgorCQkgICAgKENDT1BUUz0gJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkg
JGR1bW15LmMgMj4vZGV2L251bGwpICYmIEhQX0FSQ0g9YCRkdW1teWAKKwkJICAgIHRlc3QgLXog
IiRIUF9BUkNIIiAmJiBIUF9BUkNIPWhwcGEKKwkJZmkgOzsKKwllc2FjCisJaWYgWyAke0hQX0FS
Q0h9ID0gImhwcGEyLjB3IiBdCisJdGhlbgorCSAgICBldmFsICRzZXRfY2NfZm9yX2J1aWxkCisK
KwkgICAgIyBocHBhMi4wdy1ocC1ocHV4KiBoYXMgYSA2NC1iaXQga2VybmVsIGFuZCBhIGNvbXBp
bGVyIGdlbmVyYXRpbmcKKwkgICAgIyAzMi1iaXQgY29kZS4gIGhwcGE2NC1ocC1ocHV4KiBoYXMg
dGhlIHNhbWUga2VybmVsIGFuZCBhIGNvbXBpbGVyCisJICAgICMgZ2VuZXJhdGluZyA2NC1iaXQg
Y29kZS4gIEdOVSBhbmQgSFAgdXNlIGRpZmZlcmVudCBub21lbmNsYXR1cmU6CisJICAgICMKKwkg
ICAgIyAkIENDX0ZPUl9CVUlMRD1jYyAuL2NvbmZpZy5ndWVzcworCSAgICAjID0+IGhwcGEyLjB3
LWhwLWhwdXgxMS4yMworCSAgICAjICQgQ0NfRk9SX0JVSUxEPSJjYyArREEyLjB3IiAuL2NvbmZp
Zy5ndWVzcworCSAgICAjID0+IGhwcGE2NC1ocC1ocHV4MTEuMjMKKworCSAgICBpZiBlY2hvIF9f
TFA2NF9fIHwgKENDT1BUUz0gJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxsKSB8CisJCWdy
ZXAgLXEgX19MUDY0X18KKwkgICAgdGhlbgorCQlIUF9BUkNIPSJocHBhMi4wdyIKKwkgICAgZWxz
ZQorCQlIUF9BUkNIPSJocHBhNjQiCisJICAgIGZpCisJZmkKKwllY2hvICR7SFBfQVJDSH0taHAt
aHB1eCR7SFBVWF9SRVZ9CisJZXhpdCA7OworICAgIGlhNjQ6SFAtVVg6KjoqKQorCUhQVVhfUkVW
PWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLlswQl0qLy8nYAorCWVjaG8g
aWE2NC1ocC1ocHV4JHtIUFVYX1JFVn0KKwlleGl0IDs7CisgICAgMzA1MCo6SEktVVg6KjoqKQor
CWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYwor
CSNpbmNsdWRlIDx1bmlzdGQuaD4KKwlpbnQKKwltYWluICgpCisJeworCSAgbG9uZyBjcHUgPSBz
eXNjb25mIChfU0NfQ1BVX1ZFUlNJT04pOworCSAgLyogVGhlIG9yZGVyIG1hdHRlcnMsIGJlY2F1
c2UgQ1BVX0lTX0hQX01DNjhLIGVycm9uZW91c2x5IHJldHVybnMKKwkgICAgIHRydWUgZm9yIENQ
VV9QQV9SSVNDMV8wLiAgQ1BVX0lTX1BBX1JJU0MgcmV0dXJucyBjb3JyZWN0CisJICAgICByZXN1
bHRzLCBob3dldmVyLiAgKi8KKwkgIGlmIChDUFVfSVNfUEFfUklTQyAoY3B1KSkKKwkgICAgewor
CSAgICAgIHN3aXRjaCAoY3B1KQorCQl7CisJCSAgY2FzZSBDUFVfUEFfUklTQzFfMDogcHV0cyAo
ImhwcGExLjAtaGl0YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQkgIGNhc2UgQ1BVX1BBX1JJU0Mx
XzE6IHB1dHMgKCJocHBhMS4xLWhpdGFjaGktaGl1eHdlMiIpOyBicmVhazsKKwkJICBjYXNlIENQ
VV9QQV9SSVNDMl8wOiBwdXRzICgiaHBwYTIuMC1oaXRhY2hpLWhpdXh3ZTIiKTsgYnJlYWs7CisJ
CSAgZGVmYXVsdDogcHV0cyAoImhwcGEtaGl0YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQl9CisJ
ICAgIH0KKwkgIGVsc2UgaWYgKENQVV9JU19IUF9NQzY4SyAoY3B1KSkKKwkgICAgcHV0cyAoIm02
OGstaGl0YWNoaS1oaXV4d2UyIik7CisJICBlbHNlIHB1dHMgKCJ1bmtub3duLWhpdGFjaGktaGl1
eHdlMiIpOworCSAgZXhpdCAoMCk7CisJfQorRU9GCisJJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkg
JGR1bW15LmMgJiYgU1lTVEVNX05BTUU9YCRkdW1teWAgJiYKKwkJeyBlY2hvICIkU1lTVEVNX05B
TUUiOyBleGl0OyB9CisJZWNobyB1bmtub3duLWhpdGFjaGktaGl1eHdlMgorCWV4aXQgOzsKKyAg
ICA5MDAwLzc/Pzo0LjNic2Q6KjoqIHwgOTAwMC84P1s3OV06NC4zYnNkOio6KiApCisJZWNobyBo
cHBhMS4xLWhwLWJzZAorCWV4aXQgOzsKKyAgICA5MDAwLzg/Pzo0LjNic2Q6KjoqKQorCWVjaG8g
aHBwYTEuMC1ocC1ic2QKKwlleGl0IDs7CisgICAgKjk/Pyo6TVBFL2lYOio6KiB8ICozMDAwKjpN
UEUvaVg6KjoqKQorCWVjaG8gaHBwYTEuMC1ocC1tcGVpeAorCWV4aXQgOzsKKyAgICBocDc/PzpP
U0YxOio6KiB8IGhwOD9bNzldOk9TRjE6KjoqICkKKwllY2hvIGhwcGExLjEtaHAtb3NmCisJZXhp
dCA7OworICAgIGhwOD8/Ok9TRjE6KjoqKQorCWVjaG8gaHBwYTEuMC1ocC1vc2YKKwlleGl0IDs7
CisgICAgaSo4NjpPU0YxOio6KikKKwlpZiBbIC14IC91c3Ivc2Jpbi9zeXN2ZXJzaW9uIF0gOyB0
aGVuCisJICAgIGVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLW9zZjFtaworCWVsc2UKKwkg
ICAgZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tb3NmMQorCWZpCisJZXhpdCA7OworICAg
IHBhcmlzYyo6TGl0ZXMqOio6KikKKwllY2hvIGhwcGExLjEtaHAtbGl0ZXMKKwlleGl0IDs7Cisg
ICAgQzEqOkNvbnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMSo6KikKKwllY2hvIGMxLWNv
bnZleC1ic2QKKyAgICAgICAgZXhpdCA7OworICAgIEMyKjpDb252ZXhPUzoqOiogfCBjb252ZXg6
Q29udmV4T1M6QzIqOiopCisJaWYgZ2V0c3lzaW5mbyAtZiBzY2FsYXJfYWNjCisJdGhlbiBlY2hv
IGMzMi1jb252ZXgtYnNkCisJZWxzZSBlY2hvIGMyLWNvbnZleC1ic2QKKwlmaQorICAgICAgICBl
eGl0IDs7CisgICAgQzM0KjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4T1M6QzM0KjoqKQor
CWVjaG8gYzM0LWNvbnZleC1ic2QKKyAgICAgICAgZXhpdCA7OworICAgIEMzOCo6Q29udmV4T1M6
KjoqIHwgY29udmV4OkNvbnZleE9TOkMzOCo6KikKKwllY2hvIGMzOC1jb252ZXgtYnNkCisgICAg
ICAgIGV4aXQgOzsKKyAgICBDNCo6Q29udmV4T1M6KjoqIHwgY29udmV4OkNvbnZleE9TOkM0Kjoq
KQorCWVjaG8gYzQtY29udmV4LWJzZAorICAgICAgICBleGl0IDs7CisgICAgQ1JBWSpZLU1QOio6
KjoqKQorCWVjaG8geW1wLWNyYXktdW5pY29zJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9c
LlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgIENSQVkqW0EtWl05MDoqOio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0tY3JheS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IFwKKwl8IHNlZCAtZSAn
cy9DUkFZLipcKFtBLVpdOTBcKS9cMS8nIFwKKwkgICAgICAtZSB5L0FCQ0RFRkdISUpLTE1OT1BR
UlNUVVZXWFlaL2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6LyBcCisJICAgICAgLWUgJ3MvXC5b
Xi5dKiQvLlgvJworCWV4aXQgOzsKKyAgICBDUkFZKlRTOio6KjoqKQorCWVjaG8gdDkwLWNyYXkt
dW5pY29zJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7
OworICAgIENSQVkqVDNFOio6KjoqKQorCWVjaG8gYWxwaGFldjUtY3JheS11bmljb3NtayR7VU5B
TUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXC5bXi5dKiQvLlgvJworCWV4aXQgOzsKKyAgICBDUkFZ
KlNWMToqOio6KikKKwllY2hvIHN2MS1jcmF5LXVuaWNvcyR7VU5BTUVfUkVMRUFTRX0gfCBzZWQg
LWUgJ3MvXC5bXi5dKiQvLlgvJworCWV4aXQgOzsKKyAgICAqOlVOSUNPUy9tcDoqOiopCisJZWNo
byBjcmF5bnYtY3JheS11bmljb3NtcCR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXC5bXi5d
KiQvLlgvJworCWV4aXQgOzsKKyAgICBGMzBbMDFdOlVOSVhfU3lzdGVtX1Y6KjoqIHwgRjcwMDpV
TklYX1N5c3RlbV9WOio6KikKKwlGVUpJVFNVX1BST0M9YHVuYW1lIC1tIHwgdHIgJ0FCQ0RFRkdI
SUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonYAorICAgICAg
ICBGVUpJVFNVX1NZUz1gdW5hbWUgLXAgfCB0ciAnQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVon
ICdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eicgfCBzZWQgLWUgJ3MvXC8vLydgCisgICAgICAg
IEZVSklUU1VfUkVMPWBlY2hvICR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvIC9fLydgCisg
ICAgICAgIGVjaG8gIiR7RlVKSVRTVV9QUk9DfS1mdWppdHN1LSR7RlVKSVRTVV9TWVN9JHtGVUpJ
VFNVX1JFTH0iCisgICAgICAgIGV4aXQgOzsKKyAgICA1MDAwOlVOSVhfU3lzdGVtX1Y6NC4qOiop
CisgICAgICAgIEZVSklUU1VfU1lTPWB1bmFtZSAtcCB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJT
VFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6JyB8IHNlZCAtZSAncy9cLy8vJ2AK
KyAgICAgICAgRlVKSVRTVV9SRUw9YGVjaG8gJHtVTkFNRV9SRUxFQVNFfSB8IHRyICdBQkNERUZH
SElKS0xNTk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6JyB8IHNlZCAt
ZSAncy8gL18vJ2AKKyAgICAgICAgZWNobyAic3BhcmMtZnVqaXRzdS0ke0ZVSklUU1VfU1lTfSR7
RlVKSVRTVV9SRUx9IgorCWV4aXQgOzsKKyAgICBpKjg2OkJTRC8zODY6KjoqIHwgaSo4NjpCU0Qv
T1M6KjoqIHwgKjpBc2NlbmRcIEVtYmVkZGVkL09TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElO
RX0tcGMtYnNkaSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgc3BhcmMqOkJTRC9PUzoq
OiopCisJZWNobyBzcGFyYy11bmtub3duLWJzZGkke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7Owor
ICAgICo6QlNEL09TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1ic2RpJHtV
TkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOkZyZWVCU0Q6KjoqKQorCWNhc2UgJHtVTkFN
RV9NQUNISU5FfSBpbgorCSAgICBwYzk4KQorCQllY2hvIGkzODYtdW5rbm93bi1mcmVlYnNkYGVj
aG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvWy0oXS4qLy8nYCA7OworCSAgICBhbWQ2NCkK
KwkJZWNobyB4ODZfNjQtdW5rbm93bi1mcmVlYnNkYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQg
LWUgJ3MvWy0oXS4qLy8nYCA7OworCSAgICAqKQorCQllY2hvICR7VU5BTUVfTUFDSElORX0tdW5r
bm93bi1mcmVlYnNkYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvWy0oXS4qLy8nYCA7
OworCWVzYWMKKwlleGl0IDs7CisgICAgaSo6Q1lHV0lOKjoqKQorCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS1wYy1jeWd3aW4KKwlleGl0IDs7CisgICAgKjpNSU5HVyo6KikKKwllY2hvICR7VU5BTUVf
TUFDSElORX0tcGMtbWluZ3czMgorCWV4aXQgOzsKKyAgICBpKjp3aW5kb3dzMzIqOiopCisgICAg
CSMgdW5hbWUgLW0gaW5jbHVkZXMgIi1wYyIgb24gdGhpcyBzeXN0ZW0uCisgICAgCWVjaG8gJHtV
TkFNRV9NQUNISU5FfS1taW5ndzMyCisJZXhpdCA7OworICAgIGkqOlBXKjoqKQorCWVjaG8gJHtV
TkFNRV9NQUNISU5FfS1wYy1wdzMyCisJZXhpdCA7OworICAgICo6SW50ZXJpeCo6KikKKyAgICAJ
Y2FzZSAke1VOQU1FX01BQ0hJTkV9IGluCisJICAgIHg4NikKKwkJZWNobyBpNTg2LXBjLWludGVy
aXgke1VOQU1FX1JFTEVBU0V9CisJCWV4aXQgOzsKKwkgICAgYXV0aGVudGljYW1kIHwgZ2VudWlu
ZWludGVsIHwgRU02NFQpCisJCWVjaG8geDg2XzY0LXVua25vd24taW50ZXJpeCR7VU5BTUVfUkVM
RUFTRX0KKwkJZXhpdCA7OworCSAgICBJQTY0KQorCQllY2hvIGlhNjQtdW5rbm93bi1pbnRlcml4
JHtVTkFNRV9SRUxFQVNFfQorCQlleGl0IDs7CisJZXNhYyA7OworICAgIFszNDVdODY6V2luZG93
c185NToqIHwgWzM0NV04NjpXaW5kb3dzXzk4OiogfCBbMzQ1XTg2OldpbmRvd3NfTlQ6KikKKwll
Y2hvIGkke1VOQU1FX01BQ0hJTkV9LXBjLW1rcworCWV4aXQgOzsKKyAgICA4NjY0OldpbmRvd3Nf
TlQ6KikKKwllY2hvIHg4Nl82NC1wYy1ta3MKKwlleGl0IDs7CisgICAgaSo6V2luZG93c19OVCo6
KiB8IFBlbnRpdW0qOldpbmRvd3NfTlQqOiopCisJIyBIb3cgZG8gd2Uga25vdyBpdCdzIEludGVy
aXggcmF0aGVyIHRoYW4gdGhlIGdlbmVyaWMgUE9TSVggc3Vic3lzdGVtPworCSMgSXQgYWxzbyBj
b25mbGljdHMgd2l0aCBwcmUtMi4wIHZlcnNpb25zIG9mIEFUJlQgVVdJTi4gU2hvdWxkIHdlCisJ
IyBVTkFNRV9NQUNISU5FIGJhc2VkIG9uIHRoZSBvdXRwdXQgb2YgdW5hbWUgaW5zdGVhZCBvZiBp
Mzg2PworCWVjaG8gaTU4Ni1wYy1pbnRlcml4CisJZXhpdCA7OworICAgIGkqOlVXSU4qOiopCisJ
ZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXV3aW4KKwlleGl0IDs7CisgICAgYW1kNjQ6Q1lHV0lO
KjoqOiogfCB4ODZfNjQ6Q1lHV0lOKjoqOiopCisJZWNobyB4ODZfNjQtdW5rbm93bi1jeWd3aW4K
KwlleGl0IDs7CisgICAgcCo6Q1lHV0lOKjoqKQorCWVjaG8gcG93ZXJwY2xlLXVua25vd24tY3ln
d2luCisJZXhpdCA7OworICAgIHByZXAqOlN1bk9TOjUuKjoqKQorCWVjaG8gcG93ZXJwY2xlLXVu
a25vd24tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AK
KwlleGl0IDs7CisgICAgKjpHTlU6KjoqKQorCSMgdGhlIEdOVSBzeXN0ZW0KKwllY2hvIGBlY2hv
ICR7VU5BTUVfTUFDSElORX18c2VkIC1lICdzLFstL10uKiQsLCdgLXVua25vd24tZ251YGVjaG8g
JHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MsLy4qJCwsJ2AKKwlleGl0IDs7CisgICAgKjpHTlUv
KjoqOiopCisJIyBvdGhlciBzeXN0ZW1zIHdpdGggR05VIGxpYmMgYW5kIHVzZXJsYW5kCisJZWNo
byAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tYGVjaG8gJHtVTkFNRV9TWVNURU19IHwgc2VkICdz
LF5bXi9dKi8sLCcgfCB0ciAnW0EtWl0nICdbYS16XSdgYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxz
ZWQgLWUgJ3MvWy0oXS4qLy8nYC1nbnUKKwlleGl0IDs7CisgICAgaSo4NjpNaW5peDoqOiopCisJ
ZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW1pbml4CisJZXhpdCA7OworICAgIGFscGhhOkxpbnV4
Oio6KikKKwljYXNlIGBzZWQgLW4gJy9eY3B1IG1vZGVsL3MvXi4qOiBcKC4qXCkvXDEvcCcgPCAv
cHJvYy9jcHVpbmZvYCBpbgorCSAgRVY1KSAgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjUgOzsKKwkg
IEVWNTYpICBVTkFNRV9NQUNISU5FPWFscGhhZXY1NiA7OworCSAgUENBNTYpIFVOQU1FX01BQ0hJ
TkU9YWxwaGFwY2E1NiA7OworCSAgUENBNTcpIFVOQU1FX01BQ0hJTkU9YWxwaGFwY2E1NiA7Owor
CSAgRVY2KSAgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjYgOzsKKwkgIEVWNjcpICBVTkFNRV9NQUNI
SU5FPWFscGhhZXY2NyA7OworCSAgRVY2OCopIFVOQU1FX01BQ0hJTkU9YWxwaGFldjY4IDs7Cisg
ICAgICAgIGVzYWMKKwlvYmpkdW1wIC0tcHJpdmF0ZS1oZWFkZXJzIC9iaW4vc2ggfCBncmVwIC1x
IGxkLnNvLjEKKwlpZiB0ZXN0ICIkPyIgPSAwIDsgdGhlbiBMSUJDPSJsaWJjMSIgOyBlbHNlIExJ
QkM9IiIgOyBmaQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudSR7TElC
Q30KKwlleGl0IDs7CisgICAgYXJtKjpMaW51eDoqOiopCisJZXZhbCAkc2V0X2NjX2Zvcl9idWls
ZAorCWlmIGVjaG8gX19BUk1fRUFCSV9fIHwgJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxs
IFwKKwkgICAgfCBncmVwIC1xIF9fQVJNX0VBQklfXworCXRoZW4KKwkgICAgZWNobyAke1VOQU1F
X01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZWxzZQorCSAgICBlY2hvICR7VU5BTUVfTUFD
SElORX0tdW5rbm93bi1saW51eC1nbnVlYWJpCisJZmkKKwlleGl0IDs7CisgICAgYXZyMzIqOkxp
bnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwlleGl0
IDs7CisgICAgY3JpczpMaW51eDoqOiopCisJZWNobyBjcmlzLWF4aXMtbGludXgtZ251CisJZXhp
dCA7OworICAgIGNyaXN2MzI6TGludXg6KjoqKQorCWVjaG8gY3Jpc3YzMi1heGlzLWxpbnV4LWdu
dQorCWV4aXQgOzsKKyAgICBmcnY6TGludXg6KjoqKQorICAgIAllY2hvIGZydi11bmtub3duLWxp
bnV4LWdudQorCWV4aXQgOzsKKyAgICBpKjg2OkxpbnV4Oio6KikKKwlMSUJDPWdudQorCWV2YWwg
JHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYworCSNpZmRl
ZiBfX2RpZXRsaWJjX18KKwlMSUJDPWRpZXRsaWJjCisJI2VuZGlmCitFT0YKKwlldmFsIGAkQ0Nf
Rk9SX0JVSUxEIC1FICRkdW1teS5jIDI+L2Rldi9udWxsIHwgZ3JlcCAnXkxJQkMnYAorCWVjaG8g
IiR7VU5BTUVfTUFDSElORX0tcGMtbGludXgtJHtMSUJDfSIKKwlleGl0IDs7CisgICAgaWE2NDpM
aW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhp
dCA7OworICAgIG0zMnIqOkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93
bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgbTY4KjpMaW51eDoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIG1pcHM6TGludXg6Kjoq
IHwgbWlwczY0OkxpbnV4Oio6KikKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14J
Ly8nIDw8IEVPRiA+JGR1bW15LmMKKwkjdW5kZWYgQ1BVCisJI3VuZGVmICR7VU5BTUVfTUFDSElO
RX0KKwkjdW5kZWYgJHtVTkFNRV9NQUNISU5FfWVsCisJI2lmIGRlZmluZWQoX19NSVBTRUxfXykg
fHwgZGVmaW5lZChfX01JUFNFTCkgfHwgZGVmaW5lZChfTUlQU0VMKSB8fCBkZWZpbmVkKE1JUFNF
TCkKKwlDUFU9JHtVTkFNRV9NQUNISU5FfWVsCisJI2Vsc2UKKwkjaWYgZGVmaW5lZChfX01JUFNF
Ql9fKSB8fCBkZWZpbmVkKF9fTUlQU0VCKSB8fCBkZWZpbmVkKF9NSVBTRUIpIHx8IGRlZmluZWQo
TUlQU0VCKQorCUNQVT0ke1VOQU1FX01BQ0hJTkV9CisJI2Vsc2UKKwlDUFU9CisJI2VuZGlmCisJ
I2VuZGlmCitFT0YKKwlldmFsIGAkQ0NfRk9SX0JVSUxEIC1FICRkdW1teS5jIDI+L2Rldi9udWxs
IHwgZ3JlcCAnXkNQVSdgCisJdGVzdCB4IiR7Q1BVfSIgIT0geCAmJiB7IGVjaG8gIiR7Q1BVfS11
bmtub3duLWxpbnV4LWdudSI7IGV4aXQ7IH0KKwk7OworICAgIG9yMzI6TGludXg6KjoqKQorCWVj
aG8gb3IzMi11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYWRyZTpMaW51eDoqOiop
CisJZWNobyBzcGFyYy11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYXJpc2M2NDpM
aW51eDoqOiogfCBocHBhNjQ6TGludXg6KjoqKQorCWVjaG8gaHBwYTY0LXVua25vd24tbGludXgt
Z251CisJZXhpdCA7OworICAgIHBhcmlzYzpMaW51eDoqOiogfCBocHBhOkxpbnV4Oio6KikKKwkj
IExvb2sgZm9yIENQVSBsZXZlbAorCWNhc2UgYGdyZXAgJ15jcHVbXmEtel0qOicgL3Byb2MvY3B1
aW5mbyAyPi9kZXYvbnVsbCB8IGN1dCAtZCcgJyAtZjJgIGluCisJICBQQTcqKSBlY2hvIGhwcGEx
LjEtdW5rbm93bi1saW51eC1nbnUgOzsKKwkgIFBBOCopIGVjaG8gaHBwYTIuMC11bmtub3duLWxp
bnV4LWdudSA7OworCSAgKikgICAgZWNobyBocHBhLXVua25vd24tbGludXgtZ251IDs7CisJZXNh
YworCWV4aXQgOzsKKyAgICBwcGM2NDpMaW51eDoqOiopCisJZWNobyBwb3dlcnBjNjQtdW5rbm93
bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgcHBjOkxpbnV4Oio6KikKKwllY2hvIHBvd2VycGMt
dW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgczM5MDpMaW51eDoqOiogfCBzMzkweDpM
aW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LWlibS1saW51eAorCWV4aXQgOzsKKyAg
ICBzaDY0KjpMaW51eDoqOiopCisgICAgCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxp
bnV4LWdudQorCWV4aXQgOzsKKyAgICBzaCo6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBzcGFyYzpMaW51eDoqOiogfCBz
cGFyYzY0OkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1n
bnUKKwlleGl0IDs7CisgICAgdmF4OkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0t
ZGVjLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICB4ODZfNjQ6TGludXg6KjoqKQorCWVjaG8geDg2
XzY0LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHh0ZW5zYSo6TGludXg6KjoqKQor
ICAgIAllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7Cisg
ICAgaSo4NjpEWU5JWC9wdHg6NCo6KikKKwkjIHB0eCA0LjAgZG9lcyB1bmFtZSAtcyBjb3JyZWN0
bHksIHdpdGggRFlOSVgvcHR4IGluIHRoZXJlLgorCSMgZWFybGllciB2ZXJzaW9ucyBhcmUgbWVz
c2VkIHVwIGFuZCBwdXQgdGhlIG5vZGVuYW1lIGluIGJvdGgKKwkjIHN5c25hbWUgYW5kIG5vZGVu
YW1lLgorCWVjaG8gaTM4Ni1zZXF1ZW50LXN5c3Y0CisJZXhpdCA7OworICAgIGkqODY6VU5JWF9T
Vjo0LjJNUDoyLiopCisgICAgICAgICMgVW5peHdhcmUgaXMgYW4gb2Zmc2hvb3Qgb2YgU1ZSNCwg
YnV0IGl0IGhhcyBpdHMgb3duIHZlcnNpb24KKyAgICAgICAgIyBudW1iZXIgc2VyaWVzIHN0YXJ0
aW5nIHdpdGggMi4uLgorICAgICAgICAjIEkgYW0gbm90IHBvc2l0aXZlIHRoYXQgb3RoZXIgU1ZS
NCBzeXN0ZW1zIHdvbid0IG1hdGNoIHRoaXMsCisJIyBJIGp1c3QgaGF2ZSB0byBob3BlLiAgLS0g
cm1zLgorICAgICAgICAjIFVzZSBzeXN2NC4ydXcuLi4gc28gdGhhdCBzeXN2NCogbWF0Y2hlcyBp
dC4KKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtc3lzdjQuMnV3JHtVTkFNRV9WRVJTSU9OfQor
CWV4aXQgOzsKKyAgICBpKjg2Ok9TLzI6KjoqKQorCSMgSWYgd2Ugd2VyZSBhYmxlIHRvIGZpbmQg
YHVuYW1lJywgdGhlbiBFTVggVW5peCBjb21wYXRpYmlsaXR5CisJIyBpcyBwcm9iYWJseSBpbnN0
YWxsZWQuCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW9zMi1lbXgKKwlleGl0IDs7CisgICAg
aSo4NjpYVFMtMzAwOio6U1RPUCkKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1zdG9w
CisJZXhpdCA7OworICAgIGkqODY6YXRoZW9zOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0t
dW5rbm93bi1hdGhlb3MKKwlleGl0IDs7CisgICAgaSo4NjpzeWxsYWJsZToqOiopCisJZWNobyAk
e1VOQU1FX01BQ0hJTkV9LXBjLXN5bGxhYmxlCisJZXhpdCA7OworICAgIGkqODY6THlueE9TOjIu
KjoqIHwgaSo4NjpMeW54T1M6My5bMDFdKjoqIHwgaSo4NjpMeW54T1M6NC5bMDJdKjoqKQorCWVj
aG8gaTM4Ni11bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgaSo4
NjoqRE9TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbXNkb3NkamdwcAorCWV4aXQg
OzsKKyAgICBpKjg2Oio6NC4qOiogfCBpKjg2OlNZU1RFTV9WOjQuKjoqKQorCVVOQU1FX1JFTD1g
ZWNobyAke1VOQU1FX1JFTEVBU0V9IHwgc2VkICdzL1wvTVAkLy8nYAorCWlmIGdyZXAgTm92ZWxs
IC91c3IvaW5jbHVkZS9saW5rLmggPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbgorCQllY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5pdmVsLXN5c3Yke1VOQU1FX1JFTH0KKwllbHNlCisJCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1wYy1zeXN2JHtVTkFNRV9SRUx9CisJZmkKKwlleGl0IDs7CisgICAg
aSo4NjoqOjU6WzY3OF0qKQorICAgIAkjIFVuaXhXYXJlIDcueCwgT3BlblVOSVggYW5kIE9wZW5T
ZXJ2ZXIgNi4KKwljYXNlIGAvYmluL3VuYW1lIC1YIHwgZ3JlcCAiXk1hY2hpbmUiYCBpbgorCSAg
ICAqNDg2KikJICAgICBVTkFNRV9NQUNISU5FPWk0ODYgOzsKKwkgICAgKlBlbnRpdW0pCSAgICAg
VU5BTUVfTUFDSElORT1pNTg2IDs7CisJICAgICpQZW50KnwqQ2VsZXJvbikgVU5BTUVfTUFDSElO
RT1pNjg2IDs7CisJZXNhYworCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXN5c3Yke1VO
QU1FX1JFTEVBU0V9JHtVTkFNRV9TWVNURU19JHtVTkFNRV9WRVJTSU9OfQorCWV4aXQgOzsKKyAg
ICBpKjg2Oio6My4yOiopCisJaWYgdGVzdCAtZiAvdXNyL29wdGlvbnMvY2IubmFtZTsgdGhlbgor
CQlVTkFNRV9SRUw9YHNlZCAtbiAncy8uKlZlcnNpb24gLy9wJyA8L3Vzci9vcHRpb25zL2NiLm5h
bWVgCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1pc2MkVU5BTUVfUkVMCisJZWxpZiAvYmlu
L3VuYW1lIC1YIDI+L2Rldi9udWxsID4vZGV2L251bGwgOyB0aGVuCisJCVVOQU1FX1JFTD1gKC9i
aW4vdW5hbWUgLVh8Z3JlcCBSZWxlYXNlfHNlZCAtZSAncy8uKj0gLy8nKWAKKwkJKC9iaW4vdW5h
bWUgLVh8Z3JlcCBpODA0ODYgPi9kZXYvbnVsbCkgJiYgVU5BTUVfTUFDSElORT1pNDg2CisJCSgv
YmluL3VuYW1lIC1YfGdyZXAgJ15NYWNoaW5lLipQZW50aXVtJyA+L2Rldi9udWxsKSBcCisJCQkm
JiBVTkFNRV9NQUNISU5FPWk1ODYKKwkJKC9iaW4vdW5hbWUgLVh8Z3JlcCAnXk1hY2hpbmUuKlBl
bnQgKklJJyA+L2Rldi9udWxsKSBcCisJCQkmJiBVTkFNRV9NQUNISU5FPWk2ODYKKwkJKC9iaW4v
dW5hbWUgLVh8Z3JlcCAnXk1hY2hpbmUuKlBlbnRpdW0gUHJvJyA+L2Rldi9udWxsKSBcCisJCQkm
JiBVTkFNRV9NQUNISU5FPWk2ODYKKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXNjbyRVTkFN
RV9SRUwKKwllbHNlCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1zeXN2MzIKKwlmaQorCWV4
aXQgOzsKKyAgICBwYzoqOio6KikKKwkjIExlZnQgaGVyZSBmb3IgY29tcGF0aWJpbGl0eToKKyAg
ICAgICAgIyB1bmFtZSAtbSBwcmludHMgZm9yIERKR1BQIGFsd2F5cyAncGMnLCBidXQgaXQgcHJp
bnRzIG5vdGhpbmcgYWJvdXQKKyAgICAgICAgIyB0aGUgcHJvY2Vzc29yLCBzbyB3ZSBwbGF5IHNh
ZmUgYnkgYXNzdW1pbmcgaTU4Ni4KKwkjIE5vdGU6IHdoYXRldmVyIHRoaXMgaXMsIGl0IE1VU1Qg
YmUgdGhlIHNhbWUgYXMgd2hhdCBjb25maWcuc3ViCisJIyBwcmludHMgZm9yIHRoZSAiZGpncHAi
IGhvc3QsIG9yIGVsc2UgR0RCIGNvbmZpZ3VyeSB3aWxsIGRlY2lkZSB0aGF0CisJIyB0aGlzIGlz
IGEgY3Jvc3MtYnVpbGQuCisJZWNobyBpNTg2LXBjLW1zZG9zZGpncHAKKyAgICAgICAgZXhpdCA7
OworICAgIEludGVsOk1hY2g6Myo6KikKKwllY2hvIGkzODYtcGMtbWFjaDMKKwlleGl0IDs7Cisg
ICAgcGFyYWdvbjoqOio6KikKKwllY2hvIGk4NjAtaW50ZWwtb3NmMQorCWV4aXQgOzsKKyAgICBp
ODYwOio6NC4qOiopICMgaTg2MC1TVlI0CisJaWYgZ3JlcCBTdGFyZGVudCAvdXNyL2luY2x1ZGUv
c3lzL3VhZG1pbi5oID4vZGV2L251bGwgMj4mMSA7IHRoZW4KKwkgIGVjaG8gaTg2MC1zdGFyZGVu
dC1zeXN2JHtVTkFNRV9SRUxFQVNFfSAjIFN0YXJkZW50IFZpc3RyYSBpODYwLVNWUjQKKwllbHNl
ICMgQWRkIG90aGVyIGk4NjAtU1ZSNCB2ZW5kb3JzIGJlbG93IGFzIHRoZXkgYXJlIGRpc2NvdmVy
ZWQuCisJICBlY2hvIGk4NjAtdW5rbm93bi1zeXN2JHtVTkFNRV9SRUxFQVNFfSAgIyBVbmtub3du
IGk4NjAtU1ZSNAorCWZpCisJZXhpdCA7OworICAgIG1pbmkqOkNUSVg6U1lTKjU6KikKKwkjICJt
aW5pZnJhbWUiCisJZWNobyBtNjgwMTAtY29udmVyZ2VudC1zeXN2CisJZXhpdCA7OworICAgIG1j
NjhrOlVOSVg6U1lTVEVNNTozLjUxbSkKKwllY2hvIG02OGstY29udmVyZ2VudC1zeXN2CisJZXhp
dCA7OworICAgIE02ODA/MDpELU5JWDo1LjM6KikKKwllY2hvIG02OGstZGlhYi1kbml4CisJZXhp
dCA7OworICAgIE02OCo6KjpSM1ZbNTY3OF0qOiopCisJdGVzdCAtciAvc3lzVjY4ICYmIHsgZWNo
byAnbTY4ay1tb3Rvcm9sYS1zeXN2JzsgZXhpdDsgfSA7OworICAgIDNbMzQ1XT8/Oio6NC4wOjMu
MCB8IDNbMzRdPz9BOio6NC4wOjMuMCB8IDNbMzRdPz8sKjoqOjQuMDozLjAgfCAzWzM0XT8/Lyo6
Kjo0LjA6My4wIHwgNDQwMDoqOjQuMDozLjAgfCA0ODUwOio6NC4wOjMuMCB8IFNLQTQwOio6NC4w
OjMuMCB8IFNEUzI6Kjo0LjA6My4wIHwgU0hHMjoqOjQuMDozLjAgfCBTNzUwMSo6Kjo0LjA6My4w
KQorCU9TX1JFTD0nJworCXRlc3QgLXIgL2V0Yy8ucmVsaWQgXAorCSYmIE9TX1JFTD0uYHNlZCAt
biAncy9bXiBdKiBbXiBdKiBcKFswLTldWzAtOV1cKS4qL1wxL3AnIDwgL2V0Yy8ucmVsaWRgCisJ
L2Jpbi91bmFtZSAtcCAyPi9kZXYvbnVsbCB8IGdyZXAgODYgPi9kZXYvbnVsbCBcCisJICAmJiB7
IGVjaG8gaTQ4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAg
Mj4vZGV2L251bGwgfCAvYmluL2dyZXAgZW50aXVtID4vZGV2L251bGwgXAorCSAgJiYgeyBlY2hv
IGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0gOzsKKyAgICAzWzM0XT8/Oio6NC4w
OiogfCAzWzM0XT8/LCo6Kjo0LjA6KikKKyAgICAgICAgL2Jpbi91bmFtZSAtcCAyPi9kZXYvbnVs
bCB8IGdyZXAgODYgPi9kZXYvbnVsbCBcCisgICAgICAgICAgJiYgeyBlY2hvIGk0ODYtbmNyLXN5
c3Y0OyBleGl0OyB9IDs7CisgICAgTkNSKjoqOjQuMjoqIHwgTVBSQVMqOio6NC4yOiopCisJT1Nf
UkVMPScuMycKKwl0ZXN0IC1yIC9ldGMvLnJlbGlkIFwKKwkgICAgJiYgT1NfUkVMPS5gc2VkIC1u
ICdzL1teIF0qIFteIF0qIFwoWzAtOV1bMC05XVwpLiovXDEvcCcgPCAvZXRjLy5yZWxpZGAKKwkv
YmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgZ3JlcCA4NiA+L2Rldi9udWxsIFwKKwkgICAgJiYg
eyBlY2hvIGk0ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkvYmluL3VuYW1lIC1w
IDI+L2Rldi9udWxsIHwgL2Jpbi9ncmVwIGVudGl1bSA+L2Rldi9udWxsIFwKKwkgICAgJiYgeyBl
Y2hvIGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkvYmluL3VuYW1lIC1wIDI+
L2Rldi9udWxsIHwgL2Jpbi9ncmVwIHB0ZXJvbiA+L2Rldi9udWxsIFwKKwkgICAgJiYgeyBlY2hv
IGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0gOzsKKyAgICBtNjgqOkx5bnhPUzoy
Lio6KiB8IG02OCo6THlueE9TOjMuMCo6KikKKwllY2hvIG02OGstdW5rbm93bi1seW54b3Mke1VO
QU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG1jNjgwMzA6VU5JWF9TeXN0ZW1fVjo0Lio6KikK
KwllY2hvIG02OGstYXRhcmktc3lzdjQKKwlleGl0IDs7CisgICAgVFNVTkFNSTpMeW54T1M6Mi4q
OiopCisJZWNobyBzcGFyYy11bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgcnM2MDAwOkx5bnhPUzoyLio6KikKKwllY2hvIHJzNjAwMC11bmtub3duLWx5bnhvcyR7
VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgUG93ZXJQQzpMeW54T1M6Mi4qOiogfCBQb3dl
clBDOkx5bnhPUzozLlswMV0qOiogfCBQb3dlclBDOkx5bnhPUzo0LlswMl0qOiopCisJZWNobyBw
b3dlcnBjLXVua25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTTVtC
RV1TOlVOSVhfU1Y6KjoqKQorCWVjaG8gbWlwcy1kZGUtc3lzdiR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgUk0qOlJlbGlhbnRVTklYLSo6KjoqKQorCWVjaG8gbWlwcy1zbmktc3lzdjQK
KwlleGl0IDs7CisgICAgUk0qOlNJTklYLSo6KjoqKQorCWVjaG8gbWlwcy1zbmktc3lzdjQKKwll
eGl0IDs7CisgICAgKjpTSU5JWC0qOio6KikKKwlpZiB1bmFtZSAtcCAyPi9kZXYvbnVsbCA+L2Rl
di9udWxsIDsgdGhlbgorCQlVTkFNRV9NQUNISU5FPWAodW5hbWUgLXApIDI+L2Rldi9udWxsYAor
CQllY2hvICR7VU5BTUVfTUFDSElORX0tc25pLXN5c3Y0CisJZWxzZQorCQllY2hvIG5zMzJrLXNu
aS1zeXN2CisJZmkKKwlleGl0IDs7CisgICAgUEVOVElVTToqOjQuMCo6KikgIyBVbmlzeXMgYENs
ZWFyUGF0aCBITVAgSVggNDAwMCcgU1ZSNC9NUCBlZmZvcnQKKyAgICAgICAgICAgICAgICAgICAg
ICAjIHNheXMgPFJpY2hhcmQuTS5CYXJ0ZWxAY2NNYWlsLkNlbnN1cy5HT1Y+CisgICAgICAgIGVj
aG8gaTU4Ni11bmlzeXMtc3lzdjQKKyAgICAgICAgZXhpdCA7OworICAgICo6VU5JWF9TeXN0ZW1f
Vjo0KjpGVFgqKQorCSMgRnJvbSBHZXJhbGQgSGV3ZXMgPGhld2VzQG9wZW5tYXJrZXQuY29tPi4K
KwkjIEhvdyBhYm91dCBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBzdHJhdHVzIGFyY2hpdGVjdHVy
ZXM/IC1kam0KKwllY2hvIGhwcGExLjEtc3RyYXR1cy1zeXN2NAorCWV4aXQgOzsKKyAgICAqOio6
KjpGVFgqKQorCSMgRnJvbSBzZWFuZkBzd2RjLnN0cmF0dXMuY29tLgorCWVjaG8gaTg2MC1zdHJh
dHVzLXN5c3Y0CisJZXhpdCA7OworICAgIGkqODY6Vk9TOio6KikKKwkjIEZyb20gUGF1bC5HcmVl
bkBzdHJhdHVzLmNvbS4KKwllY2hvICR7VU5BTUVfTUFDSElORX0tc3RyYXR1cy12b3MKKwlleGl0
IDs7CisgICAgKjpWT1M6KjoqKQorCSMgRnJvbSBQYXVsLkdyZWVuQHN0cmF0dXMuY29tLgorCWVj
aG8gaHBwYTEuMS1zdHJhdHVzLXZvcworCWV4aXQgOzsKKyAgICBtYzY4KjpBL1VYOio6KikKKwll
Y2hvIG02OGstYXBwbGUtYXV4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBuZXdzKjpO
RVdTLU9TOjYqOiopCisJZWNobyBtaXBzLXNvbnktbmV3c29zNgorCWV4aXQgOzsKKyAgICBSWzM0
XTAwMDoqU3lzdGVtX1YqOio6KiB8IFI0MDAwOlVOSVhfU1lTVjoqOiogfCBSKjAwMDpVTklYX1NW
Oio6KikKKwlpZiBbIC1kIC91c3IvbmVjIF07IHRoZW4KKwkgICAgICAgIGVjaG8gbWlwcy1uZWMt
c3lzdiR7VU5BTUVfUkVMRUFTRX0KKwllbHNlCisJICAgICAgICBlY2hvIG1pcHMtdW5rbm93bi1z
eXN2JHtVTkFNRV9SRUxFQVNFfQorCWZpCisgICAgICAgIGV4aXQgOzsKKyAgICBCZUJveDpCZU9T
Oio6KikJIyBCZU9TIHJ1bm5pbmcgb24gaGFyZHdhcmUgbWFkZSBieSBCZSwgUFBDIG9ubHkuCisJ
ZWNobyBwb3dlcnBjLWJlLWJlb3MKKwlleGl0IDs7CisgICAgQmVNYWM6QmVPUzoqOiopCSMgQmVP
UyBydW5uaW5nIG9uIE1hYyBvciBNYWMgY2xvbmUsIFBQQyBvbmx5LgorCWVjaG8gcG93ZXJwYy1h
cHBsZS1iZW9zCisJZXhpdCA7OworICAgIEJlUEM6QmVPUzoqOiopCSMgQmVPUyBydW5uaW5nIG9u
IEludGVsIFBDIGNvbXBhdGlibGUuCisJZWNobyBpNTg2LXBjLWJlb3MKKwlleGl0IDs7CisgICAg
QmVQQzpIYWlrdToqOiopCSMgSGFpa3UgcnVubmluZyBvbiBJbnRlbCBQQyBjb21wYXRpYmxlLgor
CWVjaG8gaTU4Ni1wYy1oYWlrdQorCWV4aXQgOzsKKyAgICBTWC00OlNVUEVSLVVYOio6KikKKwll
Y2hvIHN4NC1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gtNTpT
VVBFUi1VWDoqOiopCisJZWNobyBzeDUtbmVjLXN1cGVydXgke1VOQU1FX1JFTEVBU0V9CisJZXhp
dCA7OworICAgIFNYLTY6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g2LW5lYy1zdXBlcnV4JHtVTkFN
RV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC03OlNVUEVSLVVYOio6KikKKwllY2hvIHN4Ny1u
ZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gtODpTVVBFUi1VWDoq
OiopCisJZWNobyBzeDgtbmVjLXN1cGVydXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAg
IFNYLThSOlNVUEVSLVVYOio6KikKKwllY2hvIHN4OHItbmVjLXN1cGVydXgke1VOQU1FX1JFTEVB
U0V9CisJZXhpdCA7OworICAgIFBvd2VyKjpSaGFwc29keToqOiopCisJZWNobyBwb3dlcnBjLWFw
cGxlLXJoYXBzb2R5JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOlJoYXBzb2R5Oio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tYXBwbGUtcmhhcHNvZHkke1VOQU1FX1JFTEVBU0V9
CisJZXhpdCA7OworICAgICo6RGFyd2luOio6KikKKwlVTkFNRV9QUk9DRVNTT1I9YHVuYW1lIC1w
YCB8fCBVTkFNRV9QUk9DRVNTT1I9dW5rbm93bgorCWNhc2UgJFVOQU1FX1BST0NFU1NPUiBpbgor
CSAgICBpMzg2KQorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCWlmIFsgIiRDQ19GT1JfQlVJ
TEQiICE9ICdub19jb21waWxlcl9mb3VuZCcgXTsgdGhlbgorCQkgIGlmIChlY2hvICcjaWZkZWYg
X19MUDY0X18nOyBlY2hvIElTXzY0QklUX0FSQ0g7IGVjaG8gJyNlbmRpZicpIHwgXAorCQkgICAg
ICAoQ0NPUFRTPSAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwgXAorCQkgICAgICBn
cmVwIElTXzY0QklUX0FSQ0ggPi9kZXYvbnVsbAorCQkgIHRoZW4KKwkJICAgICAgVU5BTUVfUFJP
Q0VTU09SPSJ4ODZfNjQiCisJCSAgZmkKKwkJZmkgOzsKKwkgICAgdW5rbm93bikgVU5BTUVfUFJP
Q0VTU09SPXBvd2VycGMgOzsKKwllc2FjCisJZWNobyAke1VOQU1FX1BST0NFU1NPUn0tYXBwbGUt
ZGFyd2luJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOnByb2NudG8qOio6KiB8ICo6
UU5YOlswMTIzNDU2Nzg5XSo6KikKKwlVTkFNRV9QUk9DRVNTT1I9YHVuYW1lIC1wYAorCWlmIHRl
c3QgIiRVTkFNRV9QUk9DRVNTT1IiID0gIng4NiI7IHRoZW4KKwkJVU5BTUVfUFJPQ0VTU09SPWkz
ODYKKwkJVU5BTUVfTUFDSElORT1wYworCWZpCisJZWNobyAke1VOQU1FX1BST0NFU1NPUn0tJHtV
TkFNRV9NQUNISU5FfS1udG8tcW54JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOlFO
WDoqOjQqKQorCWVjaG8gaTM4Ni1wYy1xbngKKwlleGl0IDs7CisgICAgTlNFLT86Tk9OU1RPUF9L
RVJORUw6KjoqKQorCWVjaG8gbnNlLXRhbmRlbS1uc2ske1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIE5TUi0/Ok5PTlNUT1BfS0VSTkVMOio6KikKKwllY2hvIG5zci10YW5kZW0tbnNrJHtV
TkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOk5vblN0b3AtVVg6KjoqKQorCWVjaG8gbWlw
cy1jb21wYXEtbm9uc3RvcHV4CisJZXhpdCA7OworICAgIEJTMjAwMDpQT1NJWCo6KjoqKQorCWVj
aG8gYnMyMDAwLXNpZW1lbnMtc3lzdgorCWV4aXQgOzsKKyAgICBEUy8qOlVOSVhfU3lzdGVtX1Y6
KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS0ke1VOQU1FX1NZU1RFTX0tJHtVTkFNRV9SRUxF
QVNFfQorCWV4aXQgOzsKKyAgICAqOlBsYW45Oio6KikKKwkjICJ1bmFtZSAtbSIgaXMgbm90IGNv
bnNpc3RlbnQsIHNvIHVzZSAkY3B1dHlwZSBpbnN0ZWFkLiAzODYKKwkjIGlzIGNvbnZlcnRlZCB0
byBpMzg2IGZvciBjb25zaXN0ZW5jeSB3aXRoIG90aGVyIHg4NgorCSMgb3BlcmF0aW5nIHN5c3Rl
bXMuCisJaWYgdGVzdCAiJGNwdXR5cGUiID0gIjM4NiI7IHRoZW4KKwkgICAgVU5BTUVfTUFDSElO
RT1pMzg2CisJZWxzZQorCSAgICBVTkFNRV9NQUNISU5FPSIkY3B1dHlwZSIKKwlmaQorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS11bmtub3duLXBsYW45CisJZXhpdCA7OworICAgICo6VE9QUy0xMDoq
OiopCisJZWNobyBwZHAxMC11bmtub3duLXRvcHMxMAorCWV4aXQgOzsKKyAgICAqOlRFTkVYOio6
KikKKwllY2hvIHBkcDEwLXVua25vd24tdGVuZXgKKwlleGl0IDs7CisgICAgS1MxMDpUT1BTLTIw
Oio6KiB8IEtMMTA6VE9QUy0yMDoqOiogfCBUWVBFNDpUT1BTLTIwOio6KikKKwllY2hvIHBkcDEw
LWRlYy10b3BzMjAKKwlleGl0IDs7CisgICAgWEtMLTE6VE9QUy0yMDoqOiogfCBUWVBFNTpUT1BT
LTIwOio6KikKKwllY2hvIHBkcDEwLXhrbC10b3BzMjAKKwlleGl0IDs7CisgICAgKjpUT1BTLTIw
Oio6KikKKwllY2hvIHBkcDEwLXVua25vd24tdG9wczIwCisJZXhpdCA7OworICAgICo6SVRTOio6
KikKKwllY2hvIHBkcDEwLXVua25vd24taXRzCisJZXhpdCA7OworICAgIFNFSToqOio6U0VJVVgp
CisgICAgICAgIGVjaG8gbWlwcy1zZWktc2VpdXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7Owor
ICAgICo6RHJhZ29uRmx5Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1kcmFn
b25mbHlgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydgCisJZXhpdCA7
OworICAgICo6KlZNUzoqOiopCisgICAgCVVOQU1FX01BQ0hJTkU9YCh1bmFtZSAtcCkgMj4vZGV2
L251bGxgCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FfSIgaW4KKwkgICAgQSopIGVjaG8gYWxwaGEt
ZGVjLXZtcyA7IGV4aXQgOzsKKwkgICAgSSopIGVjaG8gaWE2NC1kZWMtdm1zIDsgZXhpdCA7Owor
CSAgICBWKikgZWNobyB2YXgtZGVjLXZtcyA7IGV4aXQgOzsKKwllc2FjIDs7CisgICAgKjpYRU5J
WDoqOlN5c1YpCisJZWNobyBpMzg2LXBjLXhlbml4CisJZXhpdCA7OworICAgIGkqODY6c2t5b3M6
KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1za3lvc2BlY2hvICR7VU5BTUVfUkVMRUFT
RX1gIHwgc2VkIC1lICdzLyAuKiQvLycKKwlleGl0IDs7CisgICAgaSo4NjpyZG9zOio6KikKKwll
Y2hvICR7VU5BTUVfTUFDSElORX0tcGMtcmRvcworCWV4aXQgOzsKKyAgICBpKjg2OkFST1M6Kjoq
KQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1hcm9zCisJZXhpdCA7OworZXNhYworCisjZWNo
byAnKE5vIHVuYW1lIGNvbW1hbmQgb3IgdW5hbWUgb3V0cHV0IG5vdCByZWNvZ25pemVkLiknIDE+
JjIKKyNlY2hvICIke1VOQU1FX01BQ0hJTkV9OiR7VU5BTUVfU1lTVEVNfToke1VOQU1FX1JFTEVB
U0V9OiR7VU5BTUVfVkVSU0lPTn0iIDE+JjIKKworZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAorY2F0
ID4kZHVtbXkuYyA8PEVPRgorI2lmZGVmIF9TRVFVRU5UXworIyBpbmNsdWRlIDxzeXMvdHlwZXMu
aD4KKyMgaW5jbHVkZSA8c3lzL3V0c25hbWUuaD4KKyNlbmRpZgorbWFpbiAoKQoreworI2lmIGRl
ZmluZWQgKHNvbnkpCisjaWYgZGVmaW5lZCAoTUlQU0VCKQorICAvKiBCRkQgd2FudHMgImJzZCIg
aW5zdGVhZCBvZiAibmV3c29zIi4gIFBlcmhhcHMgQkZEIHNob3VsZCBiZSBjaGFuZ2VkLAorICAg
ICBJIGRvbid0IGtub3cuLi4uICAqLworICBwcmludGYgKCJtaXBzLXNvbnktYnNkXG4iKTsgZXhp
dCAoMCk7CisjZWxzZQorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorICBwcmludGYgKCJtNjhrLXNv
bnktbmV3c29zJXNcbiIsCisjaWZkZWYgTkVXU09TNAorICAgICAgICAgICI0IgorI2Vsc2UKKwkg
ICIiCisjZW5kaWYKKyAgICAgICAgICk7IGV4aXQgKDApOworI2VuZGlmCisjZW5kaWYKKworI2lm
IGRlZmluZWQgKF9fYXJtKSAmJiBkZWZpbmVkIChfX2Fjb3JuKSAmJiBkZWZpbmVkIChfX3VuaXgp
CisgIHByaW50ZiAoImFybS1hY29ybi1yaXNjaXhcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisj
aWYgZGVmaW5lZCAoaHAzMDApICYmICFkZWZpbmVkIChocHV4KQorICBwcmludGYgKCJtNjhrLWhw
LWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyNpZiBkZWZpbmVkIChOZVhUKQorI2lmICFk
ZWZpbmVkIChfX0FSQ0hJVEVDVFVSRV9fKQorI2RlZmluZSBfX0FSQ0hJVEVDVFVSRV9fICJtNjhr
IgorI2VuZGlmCisgIGludCB2ZXJzaW9uOworICB2ZXJzaW9uPWAoaG9zdGluZm8gfCBzZWQgLW4g
J3MvLipOZVhUIE1hY2ggXChbMC05XSpcKS4qL1wxL3AnKSAyPi9kZXYvbnVsbGA7CisgIGlmICh2
ZXJzaW9uIDwgNCkKKyAgICBwcmludGYgKCIlcy1uZXh0LW5leHRzdGVwJWRcbiIsIF9fQVJDSElU
RUNUVVJFX18sIHZlcnNpb24pOworICBlbHNlCisgICAgcHJpbnRmICgiJXMtbmV4dC1vcGVuc3Rl
cCVkXG4iLCBfX0FSQ0hJVEVDVFVSRV9fLCB2ZXJzaW9uKTsKKyAgZXhpdCAoMCk7CisjZW5kaWYK
KworI2lmIGRlZmluZWQgKE1VTFRJTUFYKSB8fCBkZWZpbmVkIChuMTYpCisjaWYgZGVmaW5lZCAo
VU1BWFYpCisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1zeXN2XG4iKTsgZXhpdCAoMCk7CisjZWxz
ZQorI2lmIGRlZmluZWQgKENNVSkKKyAgcHJpbnRmICgibnMzMmstZW5jb3JlLW1hY2hcbiIpOyBl
eGl0ICgwKTsKKyNlbHNlCisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1ic2RcbiIpOyBleGl0ICgw
KTsKKyNlbmRpZgorI2VuZGlmCisjZW5kaWYKKworI2lmIGRlZmluZWQgKF9fMzg2QlNEX18pCisg
IHByaW50ZiAoImkzODYtcGMtYnNkXG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKworI2lmIGRlZmlu
ZWQgKHNlcXVlbnQpCisjaWYgZGVmaW5lZCAoaTM4NikKKyAgcHJpbnRmICgiaTM4Ni1zZXF1ZW50
LWR5bml4XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNpZiBkZWZpbmVkIChuczMyMDAwKQorICBw
cmludGYgKCJuczMyay1zZXF1ZW50LWR5bml4XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNlbmRp
ZgorCisjaWYgZGVmaW5lZCAoX1NFUVVFTlRfKQorICAgIHN0cnVjdCB1dHNuYW1lIHVuOworCisg
ICAgdW5hbWUoJnVuKTsKKworICAgIGlmIChzdHJuY21wKHVuLnZlcnNpb24sICJWMiIsIDIpID09
IDApIHsKKwlwcmludGYgKCJpMzg2LXNlcXVlbnQtcHR4MlxuIik7IGV4aXQgKDApOworICAgIH0K
KyAgICBpZiAoc3RybmNtcCh1bi52ZXJzaW9uLCAiVjEiLCAyKSA9PSAwKSB7IC8qIFhYWCBpcyBW
MSBjb3JyZWN0PyAqLworCXByaW50ZiAoImkzODYtc2VxdWVudC1wdHgxXG4iKTsgZXhpdCAoMCk7
CisgICAgfQorICAgIHByaW50ZiAoImkzODYtc2VxdWVudC1wdHhcbiIpOyBleGl0ICgwKTsKKwor
I2VuZGlmCisKKyNpZiBkZWZpbmVkICh2YXgpCisjIGlmICFkZWZpbmVkICh1bHRyaXgpCisjICBp
bmNsdWRlIDxzeXMvcGFyYW0uaD4KKyMgIGlmIGRlZmluZWQgKEJTRCkKKyMgICBpZiBCU0QgPT0g
NDMKKyAgICAgIHByaW50ZiAoInZheC1kZWMtYnNkNC4zXG4iKTsgZXhpdCAoMCk7CisjICAgZWxz
ZQorIyAgICBpZiBCU0QgPT0gMTk5MDA2CisgICAgICBwcmludGYgKCJ2YXgtZGVjLWJzZDQuM3Jl
bm9cbiIpOyBleGl0ICgwKTsKKyMgICAgZWxzZQorICAgICAgcHJpbnRmICgidmF4LWRlYy1ic2Rc
biIpOyBleGl0ICgwKTsKKyMgICAgZW5kaWYKKyMgICBlbmRpZgorIyAgZWxzZQorICAgIHByaW50
ZiAoInZheC1kZWMtYnNkXG4iKTsgZXhpdCAoMCk7CisjICBlbmRpZgorIyBlbHNlCisgICAgcHJp
bnRmICgidmF4LWRlYy11bHRyaXhcbiIpOyBleGl0ICgwKTsKKyMgZW5kaWYKKyNlbmRpZgorCisj
aWYgZGVmaW5lZCAoYWxsaWFudCkgJiYgZGVmaW5lZCAoaTg2MCkKKyAgcHJpbnRmICgiaTg2MC1h
bGxpYW50LWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyAgZXhpdCAoMSk7Cit9CitFT0YK
KworJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgMj4vZGV2L251bGwgJiYgU1lTVEVN
X05BTUU9YCRkdW1teWAgJiYKKwl7IGVjaG8gIiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKworIyBB
cG9sbG9zIHB1dCB0aGUgc3lzdGVtIHR5cGUgaW4gdGhlIGVudmlyb25tZW50LgorCit0ZXN0IC1k
IC91c3IvYXBvbGxvICYmIHsgZWNobyAke0lTUH0tYXBvbGxvLSR7U1lTVFlQRX07IGV4aXQ7IH0K
KworIyBDb252ZXggdmVyc2lvbnMgdGhhdCBwcmVkYXRlIHVuYW1lIGNhbiB1c2UgZ2V0c3lzaW5m
bygxKQorCitpZiBbIC14IC91c3IvY29udmV4L2dldHN5c2luZm8gXQordGhlbgorICAgIGNhc2Ug
YGdldHN5c2luZm8gLWYgY3B1X3R5cGVgIGluCisgICAgYzEqKQorCWVjaG8gYzEtY29udmV4LWJz
ZAorCWV4aXQgOzsKKyAgICBjMiopCisJaWYgZ2V0c3lzaW5mbyAtZiBzY2FsYXJfYWNjCisJdGhl
biBlY2hvIGMzMi1jb252ZXgtYnNkCisJZWxzZSBlY2hvIGMyLWNvbnZleC1ic2QKKwlmaQorCWV4
aXQgOzsKKyAgICBjMzQqKQorCWVjaG8gYzM0LWNvbnZleC1ic2QKKwlleGl0IDs7CisgICAgYzM4
KikKKwllY2hvIGMzOC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIGM0KikKKwllY2hvIGM0LWNv
bnZleC1ic2QKKwlleGl0IDs7CisgICAgZXNhYworZmkKKworY2F0ID4mMiA8PEVPRgorJDA6IHVu
YWJsZSB0byBndWVzcyBzeXN0ZW0gdHlwZQorCitUaGlzIHNjcmlwdCwgbGFzdCBtb2RpZmllZCAk
dGltZXN0YW1wLCBoYXMgZmFpbGVkIHRvIHJlY29nbml6ZQordGhlIG9wZXJhdGluZyBzeXN0ZW0g
eW91IGFyZSB1c2luZy4gSXQgaXMgYWR2aXNlZCB0aGF0IHlvdQorZG93bmxvYWQgdGhlIG1vc3Qg
dXAgdG8gZGF0ZSB2ZXJzaW9uIG9mIHRoZSBjb25maWcgc2NyaXB0cyBmcm9tCisKKyAgaHR0cDov
L2dpdC5zYXZhbm5haC5nbnUub3JnL2dpdHdlYi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtm
PWNvbmZpZy5ndWVzcztoYj1IRUFECithbmQKKyAgaHR0cDovL2dpdC5zYXZhbm5haC5nbnUub3Jn
L2dpdHdlYi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtmPWNvbmZpZy5zdWI7aGI9SEVBRAor
CitJZiB0aGUgdmVyc2lvbiB5b3UgcnVuICgkMCkgaXMgYWxyZWFkeSB1cCB0byBkYXRlLCBwbGVh
c2UKK3NlbmQgdGhlIGZvbGxvd2luZyBkYXRhIGFuZCBhbnkgaW5mb3JtYXRpb24geW91IHRoaW5r
IG1pZ2h0IGJlCitwZXJ0aW5lbnQgdG8gPGNvbmZpZy1wYXRjaGVzQGdudS5vcmc+IGluIG9yZGVy
IHRvIHByb3ZpZGUgdGhlIG5lZWRlZAoraW5mb3JtYXRpb24gdG8gaGFuZGxlIHlvdXIgc3lzdGVt
LgorCitjb25maWcuZ3Vlc3MgdGltZXN0YW1wID0gJHRpbWVzdGFtcAorCit1bmFtZSAtbSA9IGAo
dW5hbWUgLW0pIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1yID0gYCh1bmFt
ZSAtcikgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXMgPSBgKHVuYW1lIC1z
KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtdiA9IGAodW5hbWUgLXYpIDI+
L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKKworL3Vzci9iaW4vdW5hbWUgLXAgPSBgKC91c3Iv
YmluL3VuYW1lIC1wKSAyPi9kZXYvbnVsbGAKKy9iaW4vdW5hbWUgLVggICAgID0gYCgvYmluL3Vu
YW1lIC1YKSAyPi9kZXYvbnVsbGAKKworaG9zdGluZm8gICAgICAgICAgICAgICA9IGAoaG9zdGlu
Zm8pIDI+L2Rldi9udWxsYAorL2Jpbi91bml2ZXJzZSAgICAgICAgICA9IGAoL2Jpbi91bml2ZXJz
ZSkgMj4vZGV2L251bGxgCisvdXNyL2Jpbi9hcmNoIC1rICAgICAgID0gYCgvdXNyL2Jpbi9hcmNo
IC1rKSAyPi9kZXYvbnVsbGAKKy9iaW4vYXJjaCAgICAgICAgICAgICAgPSBgKC9iaW4vYXJjaCkg
Mj4vZGV2L251bGxgCisvdXNyL2Jpbi9vc2xldmVsICAgICAgID0gYCgvdXNyL2Jpbi9vc2xldmVs
KSAyPi9kZXYvbnVsbGAKKy91c3IvY29udmV4L2dldHN5c2luZm8gPSBgKC91c3IvY29udmV4L2dl
dHN5c2luZm8pIDI+L2Rldi9udWxsYAorCitVTkFNRV9NQUNISU5FID0gJHtVTkFNRV9NQUNISU5F
fQorVU5BTUVfUkVMRUFTRSA9ICR7VU5BTUVfUkVMRUFTRX0KK1VOQU1FX1NZU1RFTSAgPSAke1VO
QU1FX1NZU1RFTX0KK1VOQU1FX1ZFUlNJT04gPSAke1VOQU1FX1ZFUlNJT059CitFT0YKKworZXhp
dCAxCisKKyMgTG9jYWwgdmFyaWFibGVzOgorIyBldmFsOiAoYWRkLWhvb2sgJ3dyaXRlLWZpbGUt
aG9va3MgJ3RpbWUtc3RhbXApCisjIHRpbWUtc3RhbXAtc3RhcnQ6ICJ0aW1lc3RhbXA9JyIKKyMg
dGltZS1zdGFtcC1mb3JtYXQ6ICIlOnktJTAybS0lMDJkIgorIyB0aW1lLXN0YW1wLWVuZDogIici
CisjIEVuZDoKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NvbmZp
Zy5oLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL2NvbmZpZy5oLmluCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCww
ICsxLDQ2OCBAQAorLyogY29uZmlnLmguaW4uICBHZW5lcmF0ZWQgZnJvbSBjb25maWd1cmUuYWMg
YnkgYXV0b2hlYWRlci4gICovCisKKy8qIERlZmluZSB0byBvbmUgb2YgYF9nZXRiNjcnLCBgR0VU
QjY3JywgYGdldGI2NycgZm9yIENyYXktMiBhbmQgQ3JheS1ZTVAKKyAgIHN5c3RlbXMuIFRoaXMg
ZnVuY3Rpb24gaXMgcmVxdWlyZWQgZm9yIGBhbGxvY2EuYycgc3VwcG9ydCBvbiB0aG9zZSBzeXN0
ZW1zLgorICAgKi8KKyN1bmRlZiBDUkFZX1NUQUNLU0VHX0VORAorCisvKiBEZWZpbmUgdG8gMSBp
ZiB1c2luZyBgYWxsb2NhLmMnLiAqLworI3VuZGVmIENfQUxMT0NBCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgYWxhcm0nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQUxBUk0K
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgYGFsbG9jYScsIGFzIGEgZnVuY3Rpb24gb3Ig
bWFjcm8uICovCisjdW5kZWYgSEFWRV9BTExPQ0EKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgPGFsbG9jYS5oPiBhbmQgaXQgc2hvdWxkIGJlIHVzZWQgKG5vdCBvbiBVbHRyaXgpLgorICAg
Ki8KKyN1bmRlZiBIQVZFX0FMTE9DQV9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSA8YXJwYS9pbmV0Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfQVJQQV9JTkVUX0gK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBhdGV4aXQnIGZ1bmN0aW9uLiAqLwor
I3VuZGVmIEhBVkVfQVRFWElUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgYnpl
cm8nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQlpFUk8KKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIGBjbG9ja19nZXR0aW1lJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0NM
T0NLX0dFVFRJTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBkdXAyJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX0RVUDIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIDxmY250bC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0ZDTlRMX0gKKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBmZGF0YXN5bmMnIGZ1bmN0aW9uLiAqLworI3Vu
ZGVmIEhBVkVfRkRBVEFTWU5DCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZm9y
aycgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9GT1JLCisKKy8qIERlZmluZSB0byAxIGlmIGZz
ZWVrbyAoYW5kIHByZXN1bWFibHkgZnRlbGxvKSBleGlzdHMgYW5kIGlzIGRlY2xhcmVkLiAqLwor
I3VuZGVmIEhBVkVfRlNFRUtPCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZnRy
dW5jYXRlJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0ZUUlVOQ0FURQorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldGN3ZCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9H
RVRDV0QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBnZXRob3N0YnluYW1lJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVEhPU1RCWU5BTUUKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIGBnZXRob3N0bmFtZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9H
RVRIT1NUTkFNRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldHBhZ2VzaXpl
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVFBBR0VTSVpFCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgZ2V0dGltZW9mZGF5JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X0dFVFRJTUVPRkRBWQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGluZXRfbnRv
YScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9JTkVUX05UT0EKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIDxpbnR0eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZF
X0lOVFRZUEVTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBpc2FzY2lpJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0lTQVNDSUkKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBjcnlwdG8nIGxpYnJhcnkgKC1sY3J5cHRvKS4gKi8KKyN1bmRlZiBIQVZFX0xJ
QkNSWVBUTworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGxpYmludGwuaD4gaGVh
ZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9MSUJJTlRMX0gKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIGBydCcgbGlicmFyeSAoLWxydCkuICovCisjdW5kZWYgSEFWRV9MSUJSVAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHV1aWQnIGxpYnJhcnkgKC1sdXVpZCku
ICovCisjdW5kZWYgSEFWRV9MSUJVVUlECisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgeWFqbCcgbGlicmFyeSAoLWx5YWpsKS4gKi8KKyN1bmRlZiBIQVZFX0xJQllBSkwKKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB6JyBsaWJyYXJ5ICgtbHopLiAqLworI3VuZGVm
IEhBVkVfTElCWgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGxpbWl0cy5oPiBo
ZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0xJTUlUU19ICisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSBgbG9jYWx0aW1lX3InIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTE9D
QUxUSU1FX1IKKworLyogRGVmaW5lIHRvIDEgaWYgeW91ciBzeXN0ZW0gaGFzIGEgR05VIGxpYmMg
Y29tcGF0aWJsZSBgbWFsbG9jJyBmdW5jdGlvbiwgYW5kCisgICB0byAwIG90aGVyd2lzZS4gKi8K
KyN1bmRlZiBIQVZFX01BTExPQworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPG1h
bGxvYy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01BTExPQ19ICisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWVtY2hyJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X01FTUNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1lbW1vdmUnIGZ1bmN0
aW9uLiAqLworI3VuZGVmIEhBVkVfTUVNTU9WRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgPG1lbW9yeS5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01FTU9SWV9ICisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWVtc2V0JyBmdW5jdGlvbi4gKi8KKyN1
bmRlZiBIQVZFX01FTVNFVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1rZGly
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01LRElSCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBgbWtmaWZvJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01LRklGTworCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSBhIHdvcmtpbmcgYG1tYXAnIHN5c3RlbSBjYWxsLiAq
LworI3VuZGVmIEhBVkVfTU1BUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG11
bm1hcCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9NVU5NQVAKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIDxuZXRkYi5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX05F
VERCX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxuZXRpbmV0L2luLmg+IGhl
YWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfTkVUSU5FVF9JTl9ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgcGF0aGNvbmYnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfUEFU
SENPTkYKKworLyogRGVmaW5lIHRvIDEgaWYgdGhlIHN5c3RlbSBoYXMgdGhlIHR5cGUgYHB0cmRp
ZmZfdCcuICovCisjdW5kZWYgSEFWRV9QVFJESUZGX1QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
ciBzeXN0ZW0gaGFzIGEgR05VIGxpYmMgY29tcGF0aWJsZSBgcmVhbGxvYycgZnVuY3Rpb24sCisg
ICBhbmQgdG8gMCBvdGhlcndpc2UuICovCisjdW5kZWYgSEFWRV9SRUFMTE9DCisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgcmVhbHBhdGgnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfUkVBTFBBVEgKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGByZWdjb21wJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1JFR0NPTVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBybWRpcicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9STURJUgorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHNlbGVjdCcgZnVuY3Rpb24uICovCisjdW5kZWYg
SEFWRV9TRUxFQ1QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzZXRlbnYnIGZ1
bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU0VURU5WCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgc29ja2V0JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NPQ0tFVAorCisvKiBE
ZWZpbmUgdG8gMSBpZiBzdGRib29sLmggY29uZm9ybXMgdG8gQzk5LiAqLworI3VuZGVmIEhBVkVf
U1REQk9PTF9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkZGVmLmg+IGhl
YWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1REREVGX0gKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIDxzdGRpbnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERJ
TlRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGxpYi5oPiBoZWFkZXIg
ZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NURExJQl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgc3RyY2FzZWNtcCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJDQVNFQ01Q
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RyY2hyJyBmdW5jdGlvbi4gKi8K
KyN1bmRlZiBIQVZFX1NUUkNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0
cmNzcG4nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSQ1NQTgorCisvKiBEZWZpbmUgdG8g
MSBpZiB5b3UgaGF2ZSB0aGUgYHN0cmR1cCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJE
VVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJlcnJvcicgZnVuY3Rpb24u
ICovCisjdW5kZWYgSEFWRV9TVFJFUlJPUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHN0cmluZ3MuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVFJJTkdTX0gKKwor
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdHJpbmcuaD4gaGVhZGVyIGZpbGUuICov
CisjdW5kZWYgSEFWRV9TVFJJTkdfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YHN0cm5kdXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSTkRVUAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnBicmsnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVf
U1RSUEJSSworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnJjaHInIGZ1bmN0
aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSUkNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgYHN0cnNwbicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJTUE4KKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJzdHInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfU1RSU1RSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RydG9sJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUlRPTAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgYHN0cnRvdWwnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSVE9VTAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnRvdWxsJyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1NUUlRPVUxMCisKKy8qIERlZmluZSB0byAxIGlmIGBzdF9ibGtzaXplJyBpcyBhIG1l
bWJlciBvZiBgc3RydWN0IHN0YXQnLiAqLworI3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxL
U0laRQorCisvKiBEZWZpbmUgdG8gMSBpZiBgc3RfYmxvY2tzJyBpcyBhIG1lbWJlciBvZiBgc3Ry
dWN0IHN0YXQnLiAqLworI3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTCisKKy8qIERl
ZmluZSB0byAxIGlmIGBzdF9yZGV2JyBpcyBhIG1lbWJlciBvZiBgc3RydWN0IHN0YXQnLiAqLwor
I3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfUkRFVgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Vy
IGBzdHJ1Y3Qgc3RhdCcgaGFzIGBzdF9ibG9ja3MnLiBEZXByZWNhdGVkLCB1c2UKKyAgIGBIQVZF
X1NUUlVDVF9TVEFUX1NUX0JMT0NLUycgaW5zdGVhZC4gKi8KKyN1bmRlZiBIQVZFX1NUX0JMT0NL
UworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5c2xvZy5oPiBoZWFkZXIgZmls
ZS4gKi8KKyN1bmRlZiBIQVZFX1NZU0xPR19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZl
IHRoZSA8c3lzL2ZpbGUuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfRklMRV9I
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL2lvY3RsLmg+IGhlYWRlciBm
aWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX0lPQ1RMX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIDxzeXMvbW91bnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNf
TU9VTlRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9wYXJhbS5oPiBo
ZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19QQVJBTV9ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSA8c3lzL3NvY2tldC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBI
QVZFX1NZU19TT0NLRVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9z
dGF0dmZzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1NUQVRWRlNfSAorCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zdGF0Lmg+IGhlYWRlciBmaWxlLiAq
LworI3VuZGVmIEhBVkVfU1lTX1NUQVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHN5cy90aW1lLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1RJTUVfSAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy90eXBlcy5oPiBoZWFkZXIgZmls
ZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19UWVBFU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSA8dGVybWlvcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1RFUk1JT1Nf
SAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHR6c2V0JyBmdW5jdGlvbi4gKi8K
KyN1bmRlZiBIQVZFX1RaU0VUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgdW5h
bWUnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfVU5BTUUKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIDx1bmlzdGQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9VTklT
VERfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHZmb3JrJyBmdW5jdGlvbi4g
Ki8KKyN1bmRlZiBIQVZFX1ZGT1JLCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8
dmZvcmsuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9WRk9SS19ICisKKy8qIERlZmlu
ZSB0byAxIGlmIGBmb3JrJyB3b3Jrcy4gKi8KKyN1bmRlZiBIQVZFX1dPUktJTkdfRk9SSworCisv
KiBEZWZpbmUgdG8gMSBpZiBgdmZvcmsnIHdvcmtzLiAqLworI3VuZGVmIEhBVkVfV09SS0lOR19W
Rk9SSworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9u
Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAorCisv
KiBEZWZpbmUgdG8gMSBpZiB0aGUgc3lzdGVtIGhhcyB0aGUgdHlwZSBgX0Jvb2wnLiAqLworI3Vu
ZGVmIEhBVkVfX0JPT0wKKworLyogRGVmaW5lIHRvIDEgaWYgYGxzdGF0JyBkZXJlZmVyZW5jZXMg
YSBzeW1saW5rIHNwZWNpZmllZCB3aXRoIGEgdHJhaWxpbmcKKyAgIHNsYXNoLiAqLworI3VuZGVm
IExTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCisKKy8qIERlZmluZSB0byAxIGlmIGBtYWpv
cicsIGBtaW5vcicsIGFuZCBgbWFrZWRldicgYXJlIGRlY2xhcmVkIGluIDxta2Rldi5oPi4KKyAg
ICovCisjdW5kZWYgTUFKT1JfSU5fTUtERVYKKworLyogRGVmaW5lIHRvIDEgaWYgYG1ham9yJywg
YG1pbm9yJywgYW5kIGBtYWtlZGV2JyBhcmUgZGVjbGFyZWQgaW4KKyAgIDxzeXNtYWNyb3MuaD4u
ICovCisjdW5kZWYgTUFKT1JfSU5fU1lTTUFDUk9TCisKKy8qIERlZmluZSB0byB0aGUgYWRkcmVz
cyB3aGVyZSBidWcgcmVwb3J0cyBmb3IgdGhpcyBwYWNrYWdlIHNob3VsZCBiZSBzZW50LiAqLwor
I3VuZGVmIFBBQ0tBR0VfQlVHUkVQT1JUCisKKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1lIG9m
IHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX05BTUUKKworLyogRGVmaW5lIHRvIHRo
ZSBmdWxsIG5hbWUgYW5kIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tB
R0VfU1RSSU5HCisKKy8qIERlZmluZSB0byB0aGUgb25lIHN5bWJvbCBzaG9ydCBuYW1lIG9mIHRo
aXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1RBUk5BTUUKKworLyogRGVmaW5lIHRvIHRo
ZSBob21lIHBhZ2UgZm9yIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1VSTAorCisv
KiBEZWZpbmUgdG8gdGhlIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tB
R0VfVkVSU0lPTgorCisvKiBJZiB1c2luZyB0aGUgQyBpbXBsZW1lbnRhdGlvbiBvZiBhbGxvY2Es
IGRlZmluZSBpZiB5b3Uga25vdyB0aGUKKyAgIGRpcmVjdGlvbiBvZiBzdGFjayBncm93dGggZm9y
IHlvdXIgc3lzdGVtOyBvdGhlcndpc2UgaXQgd2lsbCBiZQorICAgYXV0b21hdGljYWxseSBkZWR1
Y2VkIGF0IHJ1bnRpbWUuCisJU1RBQ0tfRElSRUNUSU9OID4gMCA9PiBncm93cyB0b3dhcmQgaGln
aGVyIGFkZHJlc3NlcworCVNUQUNLX0RJUkVDVElPTiA8IDAgPT4gZ3Jvd3MgdG93YXJkIGxvd2Vy
IGFkZHJlc3NlcworCVNUQUNLX0RJUkVDVElPTiA9IDAgPT4gZGlyZWN0aW9uIG9mIGdyb3d0aCB1
bmtub3duICovCisjdW5kZWYgU1RBQ0tfRElSRUNUSU9OCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBBTlNJIEMgaGVhZGVyIGZpbGVzLiAqLworI3VuZGVmIFNURENfSEVBREVSUwor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgY2FuIHNhZmVseSBpbmNsdWRlIGJvdGggPHN5cy90aW1l
Lmg+IGFuZCA8dGltZS5oPi4gKi8KKyN1bmRlZiBUSU1FX1dJVEhfU1lTX1RJTUUKKworLyogRW5h
YmxlIGV4dGVuc2lvbnMgb24gQUlYIDMsIEludGVyaXguICAqLworI2lmbmRlZiBfQUxMX1NPVVJD
RQorIyB1bmRlZiBfQUxMX1NPVVJDRQorI2VuZGlmCisvKiBFbmFibGUgR05VIGV4dGVuc2lvbnMg
b24gc3lzdGVtcyB0aGF0IGhhdmUgdGhlbS4gICovCisjaWZuZGVmIF9HTlVfU09VUkNFCisjIHVu
ZGVmIF9HTlVfU09VUkNFCisjZW5kaWYKKy8qIEVuYWJsZSB0aHJlYWRpbmcgZXh0ZW5zaW9ucyBv
biBTb2xhcmlzLiAgKi8KKyNpZm5kZWYgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTCisjIHVuZGVm
IF9QT1NJWF9QVEhSRUFEX1NFTUFOVElDUworI2VuZGlmCisvKiBFbmFibGUgZXh0ZW5zaW9ucyBv
biBIUCBOb25TdG9wLiAgKi8KKyNpZm5kZWYgX1RBTkRFTV9TT1VSQ0UKKyMgdW5kZWYgX1RBTkRF
TV9TT1VSQ0UKKyNlbmRpZgorLyogRW5hYmxlIGdlbmVyYWwgZXh0ZW5zaW9ucyBvbiBTb2xhcmlz
LiAgKi8KKyNpZm5kZWYgX19FWFRFTlNJT05TX18KKyMgdW5kZWYgX19FWFRFTlNJT05TX18KKyNl
bmRpZgorCisKKy8qIERlZmluZSB0byAxIHRvIG1ha2UgZnNlZWtvIHZpc2libGUgb24gc29tZSBo
b3N0cyAoZS5nLiBnbGliYyAyLjIpLiAqLworI3VuZGVmIF9MQVJHRUZJTEVfU09VUkNFCisKKy8q
IERlZmluZSB0byAxIGlmIG9uIE1JTklYLiAqLworI3VuZGVmIF9NSU5JWAorCisvKiBEZWZpbmUg
dG8gMiBpZiB0aGUgc3lzdGVtIGRvZXMgbm90IHByb3ZpZGUgUE9TSVguMSBmZWF0dXJlcyBleGNl
cHQgd2l0aAorICAgdGhpcyBkZWZpbmVkLiAqLworI3VuZGVmIF9QT1NJWF8xX1NPVVJDRQorCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgbmVlZCB0byBpbiBvcmRlciBmb3IgYHN0YXQnIGFuZCBvdGhl
ciB0aGluZ3MgdG8gd29yay4gKi8KKyN1bmRlZiBfUE9TSVhfU09VUkNFCisKKy8qIERlZmluZSBm
b3IgU29sYXJpcyAyLjUuMSBzbyB0aGUgdWludDMyX3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2gu
aD4sCisgICA8cHRocmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhl
IHR5cGVkZWYgd2VyZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2Ug
YSBzeW50YXggZXJyb3IuICovCisjdW5kZWYgX1VJTlQzMl9UCisKKy8qIERlZmluZSBmb3IgU29s
YXJpcyAyLjUuMSBzbyB0aGUgdWludDY0X3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisg
ICA8cHRocmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVk
ZWYgd2VyZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50
YXggZXJyb3IuICovCisjdW5kZWYgX1VJTlQ2NF9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAy
LjUuMSBzbyB0aGUgdWludDhfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhy
ZWFkLmg+LCBvciA8c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJl
IGFsbG93ZWQsIHRoZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJv
ci4gKi8KKyN1bmRlZiBfVUlOVDhfVAorCisvKiBEZWZpbmUgdG8gYGludCcgaWYgPHN5cy90eXBl
cy5oPiBkb2Vzbid0IGRlZmluZS4gKi8KKyN1bmRlZiBnaWRfdAorCisvKiBEZWZpbmUgdG8gYF9f
aW5saW5lX18nIG9yIGBfX2lubGluZScgaWYgdGhhdCdzIHdoYXQgdGhlIEMgY29tcGlsZXIKKyAg
IGNhbGxzIGl0LCBvciB0byBub3RoaW5nIGlmICdpbmxpbmUnIGlzIG5vdCBzdXBwb3J0ZWQgdW5k
ZXIgYW55IG5hbWUuICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cworI3VuZGVmIGlubGluZQorI2Vu
ZGlmCisKKy8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Yg
d2lkdGggZXhhY3RseSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBz
dGFuZGFyZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIGludDE2X3QKKwor
LyogRGVmaW5lIHRvIHRoZSB0eXBlIG9mIGEgc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBl
eGFjdGx5IDMyIGJpdHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJk
IGluY2x1ZGVzIGRvIG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50MzJfdAorCisvKiBEZWZp
bmUgdG8gdGhlIHR5cGUgb2YgYSBzaWduZWQgaW50ZWdlciB0eXBlIG9mIHdpZHRoIGV4YWN0bHkg
NjQgYml0cyBpZgorICAgc3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVk
ZXMgZG8gbm90IGRlZmluZSBpdC4gKi8KKyN1bmRlZiBpbnQ2NF90CisKKy8qIERlZmluZSB0byB0
aGUgdHlwZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4IGJpdHMg
aWYgc3VjaAorICAgYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5v
dCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50OF90CisKKy8qIERlZmluZSB0byBycGxfbWFsbG9j
IGlmIHRoZSByZXBsYWNlbWVudCBmdW5jdGlvbiBzaG91bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiBt
YWxsb2MKKworLyogRGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3QgZGVm
aW5lLiAqLworI3VuZGVmIG1vZGVfdAorCisvKiBEZWZpbmUgdG8gYGxvbmcgaW50JyBpZiA8c3lz
L3R5cGVzLmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBvZmZfdAorCisvKiBEZWZpbmUg
dG8gYGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisjdW5kZWYgcGlk
X3QKKworLyogRGVmaW5lIHRvIHJwbF9yZWFsbG9jIGlmIHRoZSByZXBsYWNlbWVudCBmdW5jdGlv
biBzaG91bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiByZWFsbG9jCisKKy8qIERlZmluZSB0byB0aGUg
ZXF1aXZhbGVudCBvZiB0aGUgQzk5ICdyZXN0cmljdCcga2V5d29yZCwgb3IgdG8KKyAgIG5vdGhp
bmcgaWYgdGhpcyBpcyBub3Qgc3VwcG9ydGVkLiAgRG8gbm90IGRlZmluZSBpZiByZXN0cmljdCBp
cworICAgc3VwcG9ydGVkIGRpcmVjdGx5LiAgKi8KKyN1bmRlZiByZXN0cmljdAorLyogV29yayBh
cm91bmQgYSBidWcgaW4gU3VuIEMrKzogaXQgZG9lcyBub3Qgc3VwcG9ydCBfUmVzdHJpY3Qgb3IK
KyAgIF9fcmVzdHJpY3RfXywgZXZlbiB0aG91Z2ggdGhlIGNvcnJlc3BvbmRpbmcgU3VuIEMgY29t
cGlsZXIgZW5kcyB1cCB3aXRoCisgICAiI2RlZmluZSByZXN0cmljdCBfUmVzdHJpY3QiIG9yICIj
ZGVmaW5lIHJlc3RyaWN0IF9fcmVzdHJpY3RfXyIgaW4gdGhlCisgICBwcmV2aW91cyBsaW5lLiAg
UGVyaGFwcyBzb21lIGZ1dHVyZSB2ZXJzaW9uIG9mIFN1biBDKysgd2lsbCB3b3JrIHdpdGgKKyAg
IHJlc3RyaWN0OyBpZiBzbywgaG9wZWZ1bGx5IGl0IGRlZmluZXMgX19SRVNUUklDVCBsaWtlIFN1
biBDIGRvZXMuICAqLworI2lmIGRlZmluZWQgX19TVU5QUk9fQ0MgJiYgIWRlZmluZWQgX19SRVNU
UklDVAorIyBkZWZpbmUgX1Jlc3RyaWN0CisjIGRlZmluZSBfX3Jlc3RyaWN0X18KKyNlbmRpZgor
CisvKiBEZWZpbmUgdG8gYHVuc2lnbmVkIGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBk
ZWZpbmUuICovCisjdW5kZWYgc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5
cGVzLmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBzc2l6ZV90CisKKy8qIERlZmluZSB0
byBgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXNuJ3QgZGVmaW5lLiAqLworI3VuZGVmIHVpZF90
CisKKy8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Yg
d2lkdGggZXhhY3RseSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBz
dGFuZGFyZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQxNl90CisK
Ky8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lk
dGggZXhhY3RseSAzMiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFu
ZGFyZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQzMl90CisKKy8q
IERlZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGgg
ZXhhY3RseSA2NCBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFy
ZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQ2NF90CisKKy8qIERl
ZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhh
Y3RseSA4IGJpdHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGlu
Y2x1ZGVzIGRvIG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDhfdAorCisvKiBEZWZpbmUg
YXMgYGZvcmsnIGlmIGB2Zm9yaycgZG9lcyBub3Qgd29yay4gKi8KKyN1bmRlZiB2Zm9yawpkaWZm
IC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY29uZmlnLnN1YgotLS0gL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcu
c3ViCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDE3MDUgQEAKKyMh
IC9iaW4vc2gKKyMgQ29uZmlndXJhdGlvbiB2YWxpZGF0aW9uIHN1YnJvdXRpbmUgc2NyaXB0Lgor
IyAgIENvcHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5
OCwgMTk5OSwKKyMgICAyMDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAy
MDA3LCAyMDA4LCAyMDA5CisjICAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK3Rp
bWVzdGFtcD0nMjAwOS0xMS0yMCcKKworIyBUaGlzIGZpbGUgaXMgKGluIHByaW5jaXBsZSkgY29t
bW9uIHRvIEFMTCBHTlUgc29mdHdhcmUuCisjIFRoZSBwcmVzZW5jZSBvZiBhIG1hY2hpbmUgaW4g
dGhpcyBmaWxlIHN1Z2dlc3RzIHRoYXQgU09NRSBHTlUgc29mdHdhcmUKKyMgY2FuIGhhbmRsZSB0
aGF0IG1hY2hpbmUuICBJdCBkb2VzIG5vdCBpbXBseSBBTEwgR05VIHNvZnR3YXJlIGNhbi4KKyMK
KyMgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFu
ZC9vciBtb2RpZnkKKyMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyMgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlv
bjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKKyMgKGF0IHlvdXIgb3B0aW9u
KSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyMKKyMgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu
IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisjIGJ1dCBXSVRIT1VUIEFOWSBXQVJS
QU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisjIE1FUkNIQU5UQUJJ
TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyMgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyMKKyMgWW91IHNob3Vs
ZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UK
KyMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29m
dHdhcmUKKyMgRm91bmRhdGlvbiwgSW5jLiwgNTEgRnJhbmtsaW4gU3RyZWV0IC0gRmlmdGggRmxv
b3IsIEJvc3RvbiwgTUEKKyMgMDIxMTAtMTMwMSwgVVNBLgorIworIyBBcyBhIHNwZWNpYWwgZXhj
ZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91CisjIGRpc3Ry
aWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQorIyBj
b25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVk
ZSBpdCB1bmRlcgorIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZv
ciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCisKKworIyBQbGVhc2Ugc2VuZCBwYXRjaGVzIHRv
IDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4gIFN1Ym1pdCBhIGNvbnRleHQKKyMgZGlmZiBhbmQg
YSBwcm9wZXJseSBmb3JtYXR0ZWQgR05VIENoYW5nZUxvZyBlbnRyeS4KKyMKKyMgQ29uZmlndXJh
dGlvbiBzdWJyb3V0aW5lIHRvIHZhbGlkYXRlIGFuZCBjYW5vbmljYWxpemUgYSBjb25maWd1cmF0
aW9uIHR5cGUuCisjIFN1cHBseSB0aGUgc3BlY2lmaWVkIGNvbmZpZ3VyYXRpb24gdHlwZSBhcyBh
biBhcmd1bWVudC4KKyMgSWYgaXQgaXMgaW52YWxpZCwgd2UgcHJpbnQgYW4gZXJyb3IgbWVzc2Fn
ZSBvbiBzdGRlcnIgYW5kIGV4aXQgd2l0aCBjb2RlIDEuCisjIE90aGVyd2lzZSwgd2UgcHJpbnQg
dGhlIGNhbm9uaWNhbCBjb25maWcgdHlwZSBvbiBzdGRvdXQgYW5kIHN1Y2NlZWQuCisKKyMgWW91
IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoaXMgc2NyaXB0IGZyb206CisjIGh0dHA6
Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47
Zj1jb25maWcuc3ViO2hiPUhFQUQKKworIyBUaGlzIGZpbGUgaXMgc3VwcG9zZWQgdG8gYmUgdGhl
IHNhbWUgZm9yIGFsbCBHTlUgcGFja2FnZXMKKyMgYW5kIHJlY29nbml6ZSBhbGwgdGhlIENQVSB0
eXBlcywgc3lzdGVtIHR5cGVzIGFuZCBhbGlhc2VzCisjIHRoYXQgYXJlIG1lYW5pbmdmdWwgd2l0
aCAqYW55KiBHTlUgc29mdHdhcmUuCisjIEVhY2ggcGFja2FnZSBpcyByZXNwb25zaWJsZSBmb3Ig
cmVwb3J0aW5nIHdoaWNoIHZhbGlkIGNvbmZpZ3VyYXRpb25zCisjIGl0IGRvZXMgbm90IHN1cHBv
cnQuICBUaGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byBkaXN0aW5ndWlzaAorIyBhIGZhaWx1cmUg
dG8gc3VwcG9ydCBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZnJvbSBhIG1lYW5pbmdsZXNzCisjIGNv
bmZpZ3VyYXRpb24uCisKKyMgVGhlIGdvYWwgb2YgdGhpcyBmaWxlIGlzIHRvIG1hcCBhbGwgdGhl
IHZhcmlvdXMgdmFyaWF0aW9ucyBvZiBhIGdpdmVuCisjIG1hY2hpbmUgc3BlY2lmaWNhdGlvbiBp
bnRvIGEgc2luZ2xlIHNwZWNpZmljYXRpb24gaW4gdGhlIGZvcm06CisjCUNQVV9UWVBFLU1BTlVG
QUNUVVJFUi1PUEVSQVRJTkdfU1lTVEVNCisjIG9yIGluIHNvbWUgY2FzZXMsIHRoZSBuZXdlciBm
b3VyLXBhcnQgZm9ybToKKyMJQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLUtFUk5FTC1PUEVSQVRJTkdf
U1lTVEVNCisjIEl0IGlzIHdyb25nIHRvIGVjaG8gYW55IG90aGVyIHR5cGUgb2Ygc3BlY2lmaWNh
dGlvbi4KKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3VzYWdlPSJcCitV
c2FnZTogJDAgW09QVElPTl0gQ1BVLU1GUi1PUFNZUworICAgICAgICQwIFtPUFRJT05dIEFMSUFT
CisKK0Nhbm9uaWNhbGl6ZSBhIGNvbmZpZ3VyYXRpb24gbmFtZS4KKworT3BlcmF0aW9uIG1vZGVz
OgorICAtaCwgLS1oZWxwICAgICAgICAgcHJpbnQgdGhpcyBoZWxwLCB0aGVuIGV4aXQKKyAgLXQs
IC0tdGltZS1zdGFtcCAgIHByaW50IGRhdGUgb2YgbGFzdCBtb2RpZmljYXRpb24sIHRoZW4gZXhp
dAorICAtdiwgLS12ZXJzaW9uICAgICAgcHJpbnQgdmVyc2lvbiBudW1iZXIsIHRoZW4gZXhpdAor
CitSZXBvcnQgYnVncyBhbmQgcGF0Y2hlcyB0byA8Y29uZmlnLXBhdGNoZXNAZ251Lm9yZz4uIgor
Cit2ZXJzaW9uPSJcCitHTlUgY29uZmlnLnN1YiAoJHRpbWVzdGFtcCkKKworQ29weXJpZ2h0IChD
KSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LCAyMDAwLCAy
MDAxLAorMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAwOCBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhpcyBpcyBmcmVlIHNvZnR3YXJlOyBzZWUgdGhlIHNv
dXJjZSBmb3IgY29weWluZyBjb25kaXRpb25zLiAgVGhlcmUgaXMgTk8KK3dhcnJhbnR5OyBub3Qg
ZXZlbiBmb3IgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiIKKworaGVscD0iCitUcnkgXGAkbWUgLS1oZWxwJyBmb3IgbW9yZSBpbmZvcm1hdGlvbi4i
CisKKyMgUGFyc2UgY29tbWFuZCBsaW5lCit3aGlsZSB0ZXN0ICQjIC1ndCAwIDsgZG8KKyAgY2Fz
ZSAkMSBpbgorICAgIC0tdGltZS1zdGFtcCB8IC0tdGltZSogfCAtdCApCisgICAgICAgZWNobyAi
JHRpbWVzdGFtcCIgOyBleGl0IDs7CisgICAgLS12ZXJzaW9uIHwgLXYgKQorICAgICAgIGVjaG8g
IiR2ZXJzaW9uIiA7IGV4aXQgOzsKKyAgICAtLWhlbHAgfCAtLWgqIHwgLWggKQorICAgICAgIGVj
aG8gIiR1c2FnZSI7IGV4aXQgOzsKKyAgICAtLSApICAgICAjIFN0b3Agb3B0aW9uIHByb2Nlc3Np
bmcKKyAgICAgICBzaGlmdDsgYnJlYWsgOzsKKyAgICAtICkJIyBVc2Ugc3RkaW4gYXMgaW5wdXQu
CisgICAgICAgYnJlYWsgOzsKKyAgICAtKiApCisgICAgICAgZWNobyAiJG1lOiBpbnZhbGlkIG9w
dGlvbiAkMSRoZWxwIgorICAgICAgIGV4aXQgMSA7OworCisgICAgKmxvY2FsKikKKyAgICAgICAj
IEZpcnN0IHBhc3MgdGhyb3VnaCBhbnkgbG9jYWwgbWFjaGluZSB0eXBlcy4KKyAgICAgICBlY2hv
ICQxCisgICAgICAgZXhpdCA7OworCisgICAgKiApCisgICAgICAgYnJlYWsgOzsKKyAgZXNhYwor
ZG9uZQorCitjYXNlICQjIGluCisgMCkgZWNobyAiJG1lOiBtaXNzaW5nIGFyZ3VtZW50JGhlbHAi
ID4mMgorICAgIGV4aXQgMTs7CisgMSkgOzsKKyAqKSBlY2hvICIkbWU6IHRvbyBtYW55IGFyZ3Vt
ZW50cyRoZWxwIiA+JjIKKyAgICBleGl0IDE7OworZXNhYworCisjIFNlcGFyYXRlIHdoYXQgdGhl
IHVzZXIgZ2F2ZSBpbnRvIENQVS1DT01QQU5ZIGFuZCBPUyBvciBLRVJORUwtT1MgKGlmIGFueSku
CisjIEhlcmUgd2UgbXVzdCByZWNvZ25pemUgYWxsIHRoZSB2YWxpZCBLRVJORUwtT1MgY29tYmlu
YXRpb25zLgorbWF5YmVfb3M9YGVjaG8gJDEgfCBzZWQgJ3MvXlwoLipcKS1cKFteLV0qLVteLV0q
XCkkL1wyLydgCitjYXNlICRtYXliZV9vcyBpbgorICBudG8tcW54KiB8IGxpbnV4LWdudSogfCBs
aW51eC1kaWV0bGliYyB8IGxpbnV4LW5ld2xpYiogfCBsaW51eC11Y2xpYmMqIHwgXAorICB1Y2xp
bnV4LXVjbGliYyogfCB1Y2xpbnV4LWdudSogfCBrZnJlZWJzZCotZ251KiB8IGtuZXRic2QqLWdu
dSogfCBuZXRic2QqLWdudSogfCBcCisgIGtvcGVuc29sYXJpcyotZ251KiB8IFwKKyAgc3Rvcm0t
Y2hhb3MqIHwgb3MyLWVteCogfCBydG1rLW5vdmEqKQorICAgIG9zPS0kbWF5YmVfb3MKKyAgICBi
YXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkICdzL15cKC4qXCktXChbXi1dKi1bXi1dKlwpJC9c
MS8nYAorICAgIDs7CisgICopCisgICAgYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAncy8t
W14tXSokLy8nYAorICAgIGlmIFsgJGJhc2ljX21hY2hpbmUgIT0gJDEgXQorICAgIHRoZW4gb3M9
YGVjaG8gJDEgfCBzZWQgJ3MvLiotLy0vJ2AKKyAgICBlbHNlIG9zPTsgZmkKKyAgICA7OworZXNh
YworCisjIyMgTGV0J3MgcmVjb2duaXplIGNvbW1vbiBtYWNoaW5lcyBhcyBub3QgYmVpbmcgb3Bl
cmF0aW5nIHN5c3RlbXMgc28KKyMjIyB0aGF0IHRoaW5ncyBsaWtlIGNvbmZpZy5zdWIgZGVjc3Rh
dGlvbi0zMTAwIHdvcmsuICBXZSBhbHNvCisjIyMgcmVjb2duaXplIHNvbWUgbWFudWZhY3R1cmVy
cyBhcyBub3QgYmVpbmcgb3BlcmF0aW5nIHN5c3RlbXMsIHNvIHdlCisjIyMgY2FuIHByb3ZpZGUg
ZGVmYXVsdCBvcGVyYXRpbmcgc3lzdGVtcyBiZWxvdy4KK2Nhc2UgJG9zIGluCisJLXN1bipvcyop
CisJCSMgUHJldmVudCBmb2xsb3dpbmcgY2xhdXNlIGZyb20gaGFuZGxpbmcgdGhpcyBpbnZhbGlk
IGlucHV0LgorCQk7OworCS1kZWMqIHwgLW1pcHMqIHwgLXNlcXVlbnQqIHwgLWVuY29yZSogfCAt
cGM1MzIqIHwgLXNnaSogfCAtc29ueSogfCBcCisJLWF0dCogfCAtNzMwMCogfCAtMzMwMCogfCAt
ZGVsdGEqIHwgLW1vdG9yb2xhKiB8IC1zdW5bMjM0XSogfCBcCisJLXVuaWNvbSogfCAtaWJtKiB8
IC1uZXh0IHwgLWhwIHwgLWlzaSogfCAtYXBvbGxvIHwgLWFsdG9zKiB8IFwKKwktY29udmVyZ2Vu
dCogfCAtbmNyKiB8IC1uZXdzIHwgLTMyKiB8IC0zNjAwKiB8IC0zMTAwKiB8IC1oaXRhY2hpKiB8
XAorCS1jWzEyM10qIHwgLWNvbnZleCogfCAtc3VuIHwgLWNyZHMgfCAtb21yb24qIHwgLWRnIHwg
LXVsdHJhIHwgLXR0aSogfCBcCisJLWhhcnJpcyB8IC1kb2xwaGluIHwgLWhpZ2hsZXZlbCB8IC1n
b3VsZCB8IC1jYm0gfCAtbnMgfCAtbWFzc2NvbXAgfCBcCisJLWFwcGxlIHwgLWF4aXMgfCAta251
dGggfCAtY3JheSB8IC1taWNyb2JsYXplKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0kMQorCQk7
OworICAgICAgICAtYmx1ZWdlbmUqKQorCSAgICAgICAgb3M9LWNuaworCQk7OworCS1zaW0gfCAt
Y2lzY28gfCAtb2tpIHwgLXdlYyB8IC13aW5ib25kKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0k
MQorCQk7OworCS1zY291dCkKKwkJOzsKKwktd3JzKQorCQlvcz0tdnh3b3JrcworCQliYXNpY19t
YWNoaW5lPSQxCisJCTs7CisJLWNob3J1c29zKikKKwkJb3M9LWNob3J1c29zCisJCWJhc2ljX21h
Y2hpbmU9JDEKKwkJOzsKKyAJLWNob3J1c3JkYikKKyAJCW9zPS1jaG9ydXNyZGIKKwkJYmFzaWNf
bWFjaGluZT0kMQorIAkJOzsKKwktaGl1eCopCisJCW9zPS1oaXV4d2UyCisJCTs7CisJLXNjbzYp
CisJCW9zPS1zY281djYKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0u
Ki84Ni1wYy8nYAorCQk7OworCS1zY281KQorCQlvcz0tc2NvMy4ydjUKKwkJYmFzaWNfbWFjaGlu
ZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY280KQorCQlv
cz0tc2NvMy4ydjQKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84
Ni1wYy8nYAorCQk7OworCS1zY28zLjIuWzQtOV0qKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUg
J3Mvc2NvMy4yLi9zY28zLjJ2LydgCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUg
J3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktc2NvMy4ydls0LTldKikKKwkJIyBEb24ndCBmb3Jn
ZXQgdmVyc2lvbiBpZiBpdCBpcyAzLjJ2NCBvciBuZXdlci4KKwkJYmFzaWNfbWFjaGluZT1gZWNo
byAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY281djYqKQorCQkjIERv
bid0IGZvcmdldCB2ZXJzaW9uIGlmIGl0IGlzIDMuMnY0IG9yIG5ld2VyLgorCQliYXNpY19tYWNo
aW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2LXBjLydgCisJCTs7CisJLXNjbyopCisJ
CW9zPS1zY28zLjJ2MgorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4q
Lzg2LXBjLydgCisJCTs7CisJLXVkayopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQg
LWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktaXNjKQorCQlvcz0taXNjMi4yCisJCWJhc2lj
X21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktY2xp
eCopCisJCWJhc2ljX21hY2hpbmU9Y2xpcHBlci1pbnRlcmdyYXBoCisJCTs7CisJLWlzYyopCisJ
CWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsK
KwktbHlueCopCisJCW9zPS1seW54b3MKKwkJOzsKKwktcHR4KikKKwkJYmFzaWNfbWFjaGluZT1g
ZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1zZXF1ZW50LydgCisJCTs7CisJLXdpbmRvd3Nu
dCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAncy93aW5kb3dzbnQvd2lubnQvJ2AKKwkJOzsK
KwktcHNvcyopCisJCW9zPS1wc29zCisJCTs7CisJLW1pbnQgfCAtbWludFswLTldKikKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLWF0YXJpCisJCW9zPS1taW50CisJCTs7Citlc2FjCisKKyMgRGVjb2Rl
IGFsaWFzZXMgZm9yIGNlcnRhaW4gQ1BVLUNPTVBBTlkgY29tYmluYXRpb25zLgorY2FzZSAkYmFz
aWNfbWFjaGluZSBpbgorCSMgUmVjb2duaXplIHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aG91dCBj
b21wYW55IG5hbWUuCisJIyBTb21lIGFyZSBvbWl0dGVkIGhlcmUgYmVjYXVzZSB0aGV5IGhhdmUg
c3BlY2lhbCBtZWFuaW5ncyBiZWxvdy4KKwkxNzUwYSB8IDU4MCBcCisJfCBhMjlrIFwKKwl8IGFs
cGhhIHwgYWxwaGFldls0LThdIHwgYWxwaGFldjU2IHwgYWxwaGFldjZbNzhdIHwgYWxwaGFwY2E1
WzY3XSBcCisJfCBhbHBoYTY0IHwgYWxwaGE2NGV2WzQtOF0gfCBhbHBoYTY0ZXY1NiB8IGFscGhh
NjRldjZbNzhdIHwgYWxwaGE2NHBjYTVbNjddIFwKKwl8IGFtMzNfMi4wIFwKKwl8IGFyYyB8IGFy
bSB8IGFybVtibF1lIHwgYXJtZVtsYl0gfCBhcm12WzIzNDVdIHwgYXJtdlszNDVdW2xiXSB8IGF2
ciB8IGF2cjMyIFwKKwl8IGJmaW4gXAorCXwgYzR4IHwgY2xpcHBlciBcCisJfCBkMTB2IHwgZDMw
diB8IGRseCB8IGRzcDE2eHggXAorCXwgZmlkbyB8IGZyMzAgfCBmcnYgXAorCXwgaDgzMDAgfCBo
ODUwMCB8IGhwcGEgfCBocHBhMS5bMDFdIHwgaHBwYTIuMCB8IGhwcGEyLjBbbnddIHwgaHBwYTY0
IFwKKwl8IGkzNzAgfCBpODYwIHwgaTk2MCB8IGlhNjQgXAorCXwgaXAyayB8IGlxMjAwMCBcCisJ
fCBsbTMyIFwKKwl8IG0zMmMgfCBtMzJyIHwgbTMycmxlIHwgbTY4MDAwIHwgbTY4ayB8IG04OGsg
XAorCXwgbWF4cSB8IG1iIHwgbWljcm9ibGF6ZSB8IG1jb3JlIHwgbWVwIHwgbWV0YWcgXAorCXwg
bWlwcyB8IG1pcHNiZSB8IG1pcHNlYiB8IG1pcHNlbCB8IG1pcHNsZSBcCisJfCBtaXBzMTYgXAor
CXwgbWlwczY0IHwgbWlwczY0ZWwgXAorCXwgbWlwczY0b2N0ZW9uIHwgbWlwczY0b2N0ZW9uZWwg
XAorCXwgbWlwczY0b3Jpb24gfCBtaXBzNjRvcmlvbmVsIFwKKwl8IG1pcHM2NHI1OTAwIHwgbWlw
czY0cjU5MDBlbCBcCisJfCBtaXBzNjR2ciB8IG1pcHM2NHZyZWwgXAorCXwgbWlwczY0dnI0MTAw
IHwgbWlwczY0dnI0MTAwZWwgXAorCXwgbWlwczY0dnI0MzAwIHwgbWlwczY0dnI0MzAwZWwgXAor
CXwgbWlwczY0dnI1MDAwIHwgbWlwczY0dnI1MDAwZWwgXAorCXwgbWlwczY0dnI1OTAwIHwgbWlw
czY0dnI1OTAwZWwgXAorCXwgbWlwc2lzYTMyIHwgbWlwc2lzYTMyZWwgXAorCXwgbWlwc2lzYTMy
cjIgfCBtaXBzaXNhMzJyMmVsIFwKKwl8IG1pcHNpc2E2NCB8IG1pcHNpc2E2NGVsIFwKKwl8IG1p
cHNpc2E2NHIyIHwgbWlwc2lzYTY0cjJlbCBcCisJfCBtaXBzaXNhNjRzYjEgfCBtaXBzaXNhNjRz
YjFlbCBcCisJfCBtaXBzaXNhNjRzcjcxayB8IG1pcHNpc2E2NHNyNzFrZWwgXAorCXwgbWlwc3R4
MzkgfCBtaXBzdHgzOWVsIFwKKwl8IG1uMTAyMDAgfCBtbjEwMzAwIFwKKwl8IG1veGllIFwKKwl8
IG10IFwKKwl8IG1zcDQzMCBcCisJfCBuaW9zIHwgbmlvczIgXAorCXwgbnMxNmsgfCBuczMyayBc
CisJfCBvcjMyIFwKKwl8IHBkcDEwIHwgcGRwMTEgfCBwaiB8IHBqbCBcCisJfCBwb3dlcnBjIHwg
cG93ZXJwYzY0IHwgcG93ZXJwYzY0bGUgfCBwb3dlcnBjbGUgfCBwcGNiZSBcCisJfCBweXJhbWlk
IFwKKwl8IHJ4IFwKKwl8IHNjb3JlIFwKKwl8IHNoIHwgc2hbMTIzNF0gfCBzaFsyNF1hIHwgc2hb
MjRdYWViIHwgc2hbMjNdZSB8IHNoWzM0XWViIHwgc2hlYiB8IHNoYmUgfCBzaGxlIHwgc2hbMTIz
NF1sZSB8IHNoM2VsZSBcCisJfCBzaDY0IHwgc2g2NGxlIFwKKwl8IHNwYXJjIHwgc3BhcmM2NCB8
IHNwYXJjNjRiIHwgc3BhcmM2NHYgfCBzcGFyYzg2eCB8IHNwYXJjbGV0IHwgc3BhcmNsaXRlIFwK
Kwl8IHNwYXJjdjggfCBzcGFyY3Y5IHwgc3BhcmN2OWIgfCBzcGFyY3Y5diBcCisJfCBzcHUgfCBz
dHJvbmdhcm0gXAorCXwgdGFob2UgfCB0aHVtYiB8IHRpYzR4IHwgdGljODAgfCB0cm9uIFwKKwl8
IHViaWNvbTMyIFwKKwl8IHY4NTAgfCB2ODUwZSBcCisJfCB3ZTMyayBcCisJfCB4ODYgfCB4YzE2
eCB8IHhzY2FsZSB8IHhzY2FsZWVbYmxdIHwgeHN0b3JteTE2IHwgeHRlbnNhIFwKKwl8IHo4ayB8
IHo4MCkKKwkJYmFzaWNfbWFjaGluZT0kYmFzaWNfbWFjaGluZS11bmtub3duCisJCTs7CisJbTY4
MTEgfCBtNjhoYzExIHwgbTY4MTIgfCBtNjhoYzEyIHwgcGljb2NoaXApCisJCSMgTW90b3JvbGEg
NjhIQzExLzEyLgorCQliYXNpY19tYWNoaW5lPSRiYXNpY19tYWNoaW5lLXVua25vd24KKwkJb3M9
LW5vbmUKKwkJOzsKKwltODgxMTAgfCBtNjgwWzEyMzQ2XTAgfCBtNjgzPzIgfCBtNjgzNjAgfCBt
NTIwMCB8IHY3MCB8IHc2NSB8IHo4aykKKwkJOzsKKwltczEpCisJCWJhc2ljX21hY2hpbmU9bXQt
dW5rbm93bgorCQk7OworCisJIyBXZSB1c2UgYHBjJyByYXRoZXIgdGhhbiBgdW5rbm93bicKKwkj
IGJlY2F1c2UgKDEpIHRoYXQncyB3aGF0IHRoZXkgbm9ybWFsbHkgYXJlLCBhbmQKKwkjICgyKSB0
aGUgd29yZCAidW5rbm93biIgdGVuZHMgdG8gY29uZnVzZSBiZWdpbm5pbmcgdXNlcnMuCisJaSo4
NiB8IHg4Nl82NCkKKwkgIGJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtcGMKKwkgIDs7CisJ
IyBPYmplY3QgaWYgbW9yZSB0aGFuIG9uZSBjb21wYW55IG5hbWUgd29yZC4KKwkqLSotKikKKwkJ
ZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBtYWNoaW5lIFxgJGJhc2ljX21hY2hp
bmVcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7OworCSMgUmVjb2duaXplIHRo
ZSBiYXNpYyBDUFUgdHlwZXMgd2l0aCBjb21wYW55IG5hbWUuCisJNTgwLSogXAorCXwgYTI5ay0q
IFwKKwl8IGFscGhhLSogfCBhbHBoYWV2WzQtOF0tKiB8IGFscGhhZXY1Ni0qIHwgYWxwaGFldjZb
NzhdLSogXAorCXwgYWxwaGE2NC0qIHwgYWxwaGE2NGV2WzQtOF0tKiB8IGFscGhhNjRldjU2LSog
fCBhbHBoYTY0ZXY2Wzc4XS0qIFwKKwl8IGFscGhhcGNhNVs2N10tKiB8IGFscGhhNjRwY2E1WzY3
XS0qIHwgYXJjLSogXAorCXwgYXJtLSogIHwgYXJtYmUtKiB8IGFybWxlLSogfCBhcm1lYi0qIHwg
YXJtdiotKiBcCisJfCBhdnItKiB8IGF2cjMyLSogXAorCXwgYmZpbi0qIHwgYnMyMDAwLSogXAor
CXwgY1sxMjNdKiB8IGMzMC0qIHwgW2NqdF05MC0qIHwgYzR4LSogfCBjNTR4LSogfCBjNTV4LSog
fCBjNngtKiBcCisJfCBjbGlwcGVyLSogfCBjcmF5bnYtKiB8IGN5ZHJhLSogXAorCXwgZDEwdi0q
IHwgZDMwdi0qIHwgZGx4LSogXAorCXwgZWx4c2ktKiBcCisJfCBmMzBbMDFdLSogfCBmNzAwLSog
fCBmaWRvLSogfCBmcjMwLSogfCBmcnYtKiB8IGZ4ODAtKiBcCisJfCBoODMwMC0qIHwgaDg1MDAt
KiBcCisJfCBocHBhLSogfCBocHBhMS5bMDFdLSogfCBocHBhMi4wLSogfCBocHBhMi4wW253XS0q
IHwgaHBwYTY0LSogXAorCXwgaSo4Ni0qIHwgaTg2MC0qIHwgaTk2MC0qIHwgaWE2NC0qIFwKKwl8
IGlwMmstKiB8IGlxMjAwMC0qIFwKKwl8IGxtMzItKiBcCisJfCBtMzJjLSogfCBtMzJyLSogfCBt
MzJybGUtKiBcCisJfCBtNjgwMDAtKiB8IG02ODBbMDEyMzQ2XTAtKiB8IG02ODM2MC0qIHwgbTY4
Mz8yLSogfCBtNjhrLSogXAorCXwgbTg4MTEwLSogfCBtODhrLSogfCBtYXhxLSogfCBtY29yZS0q
IHwgbWV0YWctKiB8IG1pY3JvYmxhemUtKiBcCisJfCBtaXBzLSogfCBtaXBzYmUtKiB8IG1pcHNl
Yi0qIHwgbWlwc2VsLSogfCBtaXBzbGUtKiBcCisJfCBtaXBzMTYtKiBcCisJfCBtaXBzNjQtKiB8
IG1pcHM2NGVsLSogXAorCXwgbWlwczY0b2N0ZW9uLSogfCBtaXBzNjRvY3Rlb25lbC0qIFwKKwl8
IG1pcHM2NG9yaW9uLSogfCBtaXBzNjRvcmlvbmVsLSogXAorCXwgbWlwczY0cjU5MDAtKiB8IG1p
cHM2NHI1OTAwZWwtKiBcCisJfCBtaXBzNjR2ci0qIHwgbWlwczY0dnJlbC0qIFwKKwl8IG1pcHM2
NHZyNDEwMC0qIHwgbWlwczY0dnI0MTAwZWwtKiBcCisJfCBtaXBzNjR2cjQzMDAtKiB8IG1pcHM2
NHZyNDMwMGVsLSogXAorCXwgbWlwczY0dnI1MDAwLSogfCBtaXBzNjR2cjUwMDBlbC0qIFwKKwl8
IG1pcHM2NHZyNTkwMC0qIHwgbWlwczY0dnI1OTAwZWwtKiBcCisJfCBtaXBzaXNhMzItKiB8IG1p
cHNpc2EzMmVsLSogXAorCXwgbWlwc2lzYTMycjItKiB8IG1pcHNpc2EzMnIyZWwtKiBcCisJfCBt
aXBzaXNhNjQtKiB8IG1pcHNpc2E2NGVsLSogXAorCXwgbWlwc2lzYTY0cjItKiB8IG1pcHNpc2E2
NHIyZWwtKiBcCisJfCBtaXBzaXNhNjRzYjEtKiB8IG1pcHNpc2E2NHNiMWVsLSogXAorCXwgbWlw
c2lzYTY0c3I3MWstKiB8IG1pcHNpc2E2NHNyNzFrZWwtKiBcCisJfCBtaXBzdHgzOS0qIHwgbWlw
c3R4MzllbC0qIFwKKwl8IG1taXgtKiBcCisJfCBtdC0qIFwKKwl8IG1zcDQzMC0qIFwKKwl8IG5p
b3MtKiB8IG5pb3MyLSogXAorCXwgbm9uZS0qIHwgbnAxLSogfCBuczE2ay0qIHwgbnMzMmstKiBc
CisJfCBvcmlvbi0qIFwKKwl8IHBkcDEwLSogfCBwZHAxMS0qIHwgcGotKiB8IHBqbC0qIHwgcG4t
KiB8IHBvd2VyLSogXAorCXwgcG93ZXJwYy0qIHwgcG93ZXJwYzY0LSogfCBwb3dlcnBjNjRsZS0q
IHwgcG93ZXJwY2xlLSogfCBwcGNiZS0qIFwKKwl8IHB5cmFtaWQtKiBcCisJfCByb21wLSogfCBy
czYwMDAtKiB8IHJ4LSogXAorCXwgc2gtKiB8IHNoWzEyMzRdLSogfCBzaFsyNF1hLSogfCBzaFsy
NF1hZWItKiB8IHNoWzIzXWUtKiB8IHNoWzM0XWViLSogfCBzaGViLSogfCBzaGJlLSogXAorCXwg
c2hsZS0qIHwgc2hbMTIzNF1sZS0qIHwgc2gzZWxlLSogfCBzaDY0LSogfCBzaDY0bGUtKiBcCisJ
fCBzcGFyYy0qIHwgc3BhcmM2NC0qIHwgc3BhcmM2NGItKiB8IHNwYXJjNjR2LSogfCBzcGFyYzg2
eC0qIHwgc3BhcmNsZXQtKiBcCisJfCBzcGFyY2xpdGUtKiBcCisJfCBzcGFyY3Y4LSogfCBzcGFy
Y3Y5LSogfCBzcGFyY3Y5Yi0qIHwgc3BhcmN2OXYtKiB8IHN0cm9uZ2FybS0qIHwgc3YxLSogfCBz
eD8tKiBcCisJfCB0YWhvZS0qIHwgdGh1bWItKiBcCisJfCB0aWMzMC0qIHwgdGljNHgtKiB8IHRp
YzU0eC0qIHwgdGljNTV4LSogfCB0aWM2eC0qIHwgdGljODAtKiB8IHRpbGUtKiBcCisJfCB0cm9u
LSogXAorCXwgdWJpY29tMzItKiBcCisJfCB2ODUwLSogfCB2ODUwZS0qIHwgdmF4LSogXAorCXwg
d2UzMmstKiBcCisJfCB4ODYtKiB8IHg4Nl82NC0qIHwgeGMxNngtKiB8IHhwczEwMC0qIHwgeHNj
YWxlLSogfCB4c2NhbGVlW2JsXS0qIFwKKwl8IHhzdG9ybXkxNi0qIHwgeHRlbnNhKi0qIFwKKwl8
IHltcC0qIFwKKwl8IHo4ay0qIHwgejgwLSopCisJCTs7CisJIyBSZWNvZ25pemUgdGhlIGJhc2lj
IENQVSB0eXBlcyB3aXRob3V0IGNvbXBhbnkgbmFtZSwgd2l0aCBnbG9iIG1hdGNoLgorCXh0ZW5z
YSopCisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5rbm93bgorCQk7OworCSMgUmVj
b2duaXplIHRoZSB2YXJpb3VzIG1hY2hpbmUgbmFtZXMgYW5kIGFsaWFzZXMgd2hpY2ggc3RhbmQK
KwkjIGZvciBhIENQVSB0eXBlIGFuZCBhIGNvbXBhbnkgYW5kIHNvbWV0aW1lcyBldmVuIGFuIE9T
LgorCTM4NmJzZCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24KKwkJb3M9LWJzZAorCQk7
OworCTNiMSB8IDczMDAgfCA3MzAwLWF0dCB8IGF0dC03MzAwIHwgcGM3MzAwIHwgc2FmYXJpIHwg
dW5peHBjKQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1hdHQKKwkJOzsKKwkzYiopCisJCWJhc2lj
X21hY2hpbmU9d2UzMmstYXR0CisJCTs7CisJYTI5a2hpZikKKwkJYmFzaWNfbWFjaGluZT1hMjlr
LWFtZAorCQlvcz0tdWRpCisJCTs7CisgICAgCWFiYWN1cykKKwkJYmFzaWNfbWFjaGluZT1hYmFj
dXMtdW5rbm93bgorCQk7OworCWFkb2JlNjhrKQorCQliYXNpY19tYWNoaW5lPW02ODAxMC1hZG9i
ZQorCQlvcz0tc2NvdXQKKwkJOzsKKwlhbGxpYW50IHwgZng4MCkKKwkJYmFzaWNfbWFjaGluZT1m
eDgwLWFsbGlhbnQKKwkJOzsKKwlhbHRvcyB8IGFsdG9zMzA2OCkKKwkJYmFzaWNfbWFjaGluZT1t
NjhrLWFsdG9zCisJCTs7CisJYW0yOWspCisJCWJhc2ljX21hY2hpbmU9YTI5ay1ub25lCisJCW9z
PS1ic2QKKwkJOzsKKwlhbWQ2NCkKKwkJYmFzaWNfbWFjaGluZT14ODZfNjQtcGMKKwkJOzsKKwlh
bWQ2NC0qKQorCQliYXNpY19tYWNoaW5lPXg4Nl82NC1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNl
ZCAncy9eW14tXSotLy8nYAorCQk7OworCWFtZGFobCkKKwkJYmFzaWNfbWFjaGluZT01ODAtYW1k
YWhsCisJCW9zPS1zeXN2CisJCTs7CisJYW1pZ2EgfCBhbWlnYS0qKQorCQliYXNpY19tYWNoaW5l
PW02OGstdW5rbm93bgorCQk7OworCWFtaWdhb3MgfCBhbWlnYWRvcykKKwkJYmFzaWNfbWFjaGlu
ZT1tNjhrLXVua25vd24KKwkJb3M9LWFtaWdhb3MKKwkJOzsKKwlhbWlnYXVuaXggfCBhbWl4KQor
CQliYXNpY19tYWNoaW5lPW02OGstdW5rbm93bgorCQlvcz0tc3lzdjQKKwkJOzsKKwlhcG9sbG82
OCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWFwb2xsbworCQlvcz0tc3lzdgorCQk7OworCWFwb2xs
bzY4YnNkKQorCQliYXNpY19tYWNoaW5lPW02OGstYXBvbGxvCisJCW9zPS1ic2QKKwkJOzsKKwlh
cm9zKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LWFyb3MKKwkJOzsKKwlhdXgpCisJ
CWJhc2ljX21hY2hpbmU9bTY4ay1hcHBsZQorCQlvcz0tYXV4CisJCTs7CisJYmFsYW5jZSkKKwkJ
YmFzaWNfbWFjaGluZT1uczMyay1zZXF1ZW50CisJCW9zPS1keW5peAorCQk7OworCWJsYWNrZmlu
KQorCQliYXNpY19tYWNoaW5lPWJmaW4tdW5rbm93bgorCQlvcz0tbGludXgKKwkJOzsKKwlibGFj
a2Zpbi0qKQorCQliYXNpY19tYWNoaW5lPWJmaW4tYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQg
J3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4CisJCTs7CisJYmx1ZWdlbmUqKQorCQliYXNpY19t
YWNoaW5lPXBvd2VycGMtaWJtCisJCW9zPS1jbmsKKwkJOzsKKwljOTApCisJCWJhc2ljX21hY2hp
bmU9YzkwLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworICAgICAgICBjZWdjYykKKwkJYmFzaWNf
bWFjaGluZT1hcm0tdW5rbm93bgorCQlvcz0tY2VnY2MKKwkJOzsKKwljb252ZXgtYzEpCisJCWJh
c2ljX21hY2hpbmU9YzEtY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljb252ZXgtYzIpCisJCWJh
c2ljX21hY2hpbmU9YzItY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljb252ZXgtYzMyKQorCQli
YXNpY19tYWNoaW5lPWMzMi1jb252ZXgKKwkJb3M9LWJzZAorCQk7OworCWNvbnZleC1jMzQpCisJ
CWJhc2ljX21hY2hpbmU9YzM0LWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMzOCkK
KwkJYmFzaWNfbWFjaGluZT1jMzgtY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljcmF5IHwgajkw
KQorCQliYXNpY19tYWNoaW5lPWo5MC1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwljcmF5bnYp
CisJCWJhc2ljX21hY2hpbmU9Y3JheW52LWNyYXkKKwkJb3M9LXVuaWNvc21wCisJCTs7CisJY3Ix
NikKKwkJYmFzaWNfbWFjaGluZT1jcjE2LXVua25vd24KKwkJb3M9LWVsZgorCQk7OworCWNyZHMg
fCB1bm9zKQorCQliYXNpY19tYWNoaW5lPW02OGstY3JkcworCQk7OworCWNyaXN2MzIgfCBjcmlz
djMyLSogfCBldHJheGZzKikKKwkJYmFzaWNfbWFjaGluZT1jcmlzdjMyLWF4aXMKKwkJOzsKKwlj
cmlzIHwgY3Jpcy0qIHwgZXRyYXgqKQorCQliYXNpY19tYWNoaW5lPWNyaXMtYXhpcworCQk7Owor
CWNyeCkKKwkJYmFzaWNfbWFjaGluZT1jcngtdW5rbm93bgorCQlvcz0tZWxmCisJCTs7CisJZGEz
MCB8IGRhMzAtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWRhMzAKKwkJOzsKKwlkZWNzdGF0aW9u
IHwgZGVjc3RhdGlvbi0zMTAwIHwgcG1heCB8IHBtYXgtKiB8IHBtaW4gfCBkZWMzMTAwIHwgZGVj
c3RhdG4pCisJCWJhc2ljX21hY2hpbmU9bWlwcy1kZWMKKwkJOzsKKwlkZWNzeXN0ZW0xMCogfCBk
ZWMxMCopCisJCWJhc2ljX21hY2hpbmU9cGRwMTAtZGVjCisJCW9zPS10b3BzMTAKKwkJOzsKKwlk
ZWNzeXN0ZW0yMCogfCBkZWMyMCopCisJCWJhc2ljX21hY2hpbmU9cGRwMTAtZGVjCisJCW9zPS10
b3BzMjAKKwkJOzsKKwlkZWx0YSB8IDMzMDAgfCBtb3Rvcm9sYS0zMzAwIHwgbW90b3JvbGEtZGVs
dGEgXAorCSAgICAgIHwgMzMwMC1tb3Rvcm9sYSB8IGRlbHRhLW1vdG9yb2xhKQorCQliYXNpY19t
YWNoaW5lPW02OGstbW90b3JvbGEKKwkJOzsKKwlkZWx0YTg4KQorCQliYXNpY19tYWNoaW5lPW04
OGstbW90b3JvbGEKKwkJb3M9LXN5c3YzCisJCTs7CisJZGljb3MpCisJCWJhc2ljX21hY2hpbmU9
aTY4Ni1wYworCQlvcz0tZGljb3MKKwkJOzsKKwlkamdwcCkKKwkJYmFzaWNfbWFjaGluZT1pNTg2
LXBjCisJCW9zPS1tc2Rvc2RqZ3BwCisJCTs7CisJZHB4MjAgfCBkcHgyMC0qKQorCQliYXNpY19t
YWNoaW5lPXJzNjAwMC1idWxsCisJCW9zPS1ib3N4CisJCTs7CisJZHB4MiogfCBkcHgyKi1idWxs
KQorCQliYXNpY19tYWNoaW5lPW02OGstYnVsbAorCQlvcz0tc3lzdjMKKwkJOzsKKwllYm1vbjI5
aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLWFtZAorCQlvcz0tZWJtb24KKwkJOzsKKwllbHhzaSkK
KwkJYmFzaWNfbWFjaGluZT1lbHhzaS1lbHhzaQorCQlvcz0tYnNkCisJCTs7CisJZW5jb3JlIHwg
dW1heCB8IG1tYXgpCisJCWJhc2ljX21hY2hpbmU9bnMzMmstZW5jb3JlCisJCTs7CisJZXMxODAw
IHwgT1NFNjhrIHwgb3NlNjhrIHwgb3NlIHwgT1NFKQorCQliYXNpY19tYWNoaW5lPW02OGstZXJp
Y3Nzb24KKwkJb3M9LW9zZQorCQk7OworCWZ4MjgwMCkKKwkJYmFzaWNfbWFjaGluZT1pODYwLWFs
bGlhbnQKKwkJOzsKKwlnZW5peCkKKwkJYmFzaWNfbWFjaGluZT1uczMyay1ucworCQk7OworCWdt
aWNybykKKwkJYmFzaWNfbWFjaGluZT10cm9uLWdtaWNybworCQlvcz0tc3lzdgorCQk7OworCWdv
MzIpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1wYworCQlvcz0tZ28zMgorCQk7OworCWgzMDUwciog
fCBoaXV4KikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhpdGFjaGkKKwkJb3M9LWhpdXh3ZTIK
KwkJOzsKKwloODMwMGhtcykKKwkJYmFzaWNfbWFjaGluZT1oODMwMC1oaXRhY2hpCisJCW9zPS1o
bXMKKwkJOzsKKwloODMwMHhyYXkpCisJCWJhc2ljX21hY2hpbmU9aDgzMDAtaGl0YWNoaQorCQlv
cz0teHJheQorCQk7OworCWg4NTAwaG1zKQorCQliYXNpY19tYWNoaW5lPWg4NTAwLWhpdGFjaGkK
KwkJb3M9LWhtcworCQk7OworCWhhcnJpcykKKwkJYmFzaWNfbWFjaGluZT1tODhrLWhhcnJpcwor
CQlvcz0tc3lzdjMKKwkJOzsKKwlocDMwMC0qKQorCQliYXNpY19tYWNoaW5lPW02OGstaHAKKwkJ
OzsKKwlocDMwMGJzZCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhwCisJCW9zPS1ic2QKKwkJOzsK
KwlocDMwMGhwdXgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ocAorCQlvcz0taHB1eAorCQk7Owor
CWhwM2s5WzAtOV1bMC05XSB8IGhwOVswLTldWzAtOV0pCisJCWJhc2ljX21hY2hpbmU9aHBwYTEu
MC1ocAorCQk7OworCWhwOWsyWzAtOV1bMC05XSB8IGhwOWszMVswLTldKQorCQliYXNpY19tYWNo
aW5lPW02ODAwMC1ocAorCQk7OworCWhwOWszWzItOV1bMC05XSkKKwkJYmFzaWNfbWFjaGluZT1t
NjhrLWhwCisJCTs7CisJaHA5azZbMC05XVswLTldIHwgaHA2WzAtOV1bMC05XSkKKwkJYmFzaWNf
bWFjaGluZT1ocHBhMS4wLWhwCisJCTs7CisJaHA5azdbMC03OV1bMC05XSB8IGhwN1swLTc5XVsw
LTldKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtaHAKKwkJOzsKKwlocDlrNzhbMC05XSB8IGhw
NzhbMC05XSkKKwkJIyBGSVhNRTogcmVhbGx5IGhwcGEyLjAtaHAKKwkJYmFzaWNfbWFjaGluZT1o
cHBhMS4xLWhwCisJCTs7CisJaHA5azhbNjddMSB8IGhwOFs2N10xIHwgaHA5azgwWzI0XSB8IGhw
ODBbMjRdIHwgaHA5azhbNzhdOSB8IGhwOFs3OF05IHwgaHA5azg5MyB8IGhwODkzKQorCQkjIEZJ
WE1FOiByZWFsbHkgaHBwYTIuMC1ocAorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtaHAKKwkJOzsK
KwlocDlrOFswLTldWzEzNjc5XSB8IGhwOFswLTldWzEzNjc5XSkKKwkJYmFzaWNfbWFjaGluZT1o
cHBhMS4xLWhwCisJCTs7CisJaHA5azhbMC05XVswLTldIHwgaHA4WzAtOV1bMC05XSkKKwkJYmFz
aWNfbWFjaGluZT1ocHBhMS4wLWhwCisJCTs7CisJaHBwYS1uZXh0KQorCQlvcz0tbmV4dHN0ZXAz
CisJCTs7CisJaHBwYW9zZikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCW9zPS1vc2YK
KwkJOzsKKwlocHBybykKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCW9zPS1wcm9lbGYK
KwkJOzsKKwlpMzcwLWlibSogfCBpYm0qKQorCQliYXNpY19tYWNoaW5lPWkzNzAtaWJtCisJCTs7
CisjIEknbSBub3Qgc3VyZSB3aGF0ICJTeXN2MzIiIG1lYW5zLiAgU2hvdWxkIHRoaXMgYmUgc3lz
djMuMj8KKwlpKjg2djMyKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2
LiovODYtcGMvJ2AKKwkJb3M9LXN5c3YzMgorCQk7OworCWkqODZ2NCopCisJCWJhc2ljX21hY2hp
bmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8nYAorCQlvcz0tc3lzdjQKKwkJOzsK
KwlpKjg2dikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni4qLzg2LXBj
LydgCisJCW9zPS1zeXN2CisJCTs7CisJaSo4NnNvbDIpCisJCWJhc2ljX21hY2hpbmU9YGVjaG8g
JDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8nYAorCQlvcz0tc29sYXJpczIKKwkJOzsKKwlpMzg2
bWFjaCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LW1hY2gKKwkJb3M9LW1hY2gKKwkJOzsKKwlpMzg2
LXZzdGEgfCB2c3RhKQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tdnN0YQor
CQk7OworCWlyaXMgfCBpcmlzNGQpCisJCWJhc2ljX21hY2hpbmU9bWlwcy1zZ2kKKwkJY2FzZSAk
b3MgaW4KKwkJICAgIC1pcml4KikKKwkJCTs7CisJCSAgICAqKQorCQkJb3M9LWlyaXg0CisJCQk7
OworCQllc2FjCisJCTs7CisJaXNpNjggfCBpc2kpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1pc2kK
KwkJb3M9LXN5c3YKKwkJOzsKKwltNjhrbm9tbXUpCisJCWJhc2ljX21hY2hpbmU9bTY4ay11bmtu
b3duCisJCW9zPS1saW51eAorCQk7OworCW02OGtub21tdS0qKQorCQliYXNpY19tYWNoaW5lPW02
OGstYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4
CisJCTs7CisJbTg4ay1vbXJvbiopCisJCWJhc2ljX21hY2hpbmU9bTg4ay1vbXJvbgorCQk7Owor
CW1hZ251bSB8IG0zMjMwKQorCQliYXNpY19tYWNoaW5lPW1pcHMtbWlwcworCQlvcz0tc3lzdgor
CQk7OworCW1lcmxpbikKKwkJYmFzaWNfbWFjaGluZT1uczMyay11dGVrCisJCW9zPS1zeXN2CisJ
CTs7CisgICAgICAgIG1pY3JvYmxhemUpCisJCWJhc2ljX21hY2hpbmU9bWljcm9ibGF6ZS14aWxp
bngKKwkJOzsKKwltaW5ndzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LW1pbmd3
MzIKKwkJOzsKKwltaW5ndzMyY2UpCisJCWJhc2ljX21hY2hpbmU9YXJtLXVua25vd24KKwkJb3M9
LW1pbmd3MzJjZQorCQk7OworCW1pbmlmcmFtZSkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtY29u
dmVyZ2VudAorCQk7OworCSptaW50IHwgLW1pbnRbMC05XSogfCAqTWlOVCB8ICpNaU5UWzAtOV0q
KQorCQliYXNpY19tYWNoaW5lPW02OGstYXRhcmkKKwkJb3M9LW1pbnQKKwkJOzsKKwltaXBzMyot
KikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAtZSAncy9taXBz
My9taXBzNjQvJ2AKKwkJOzsKKwltaXBzMyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJGJhc2lj
X21hY2hpbmUgfCBzZWQgLWUgJ3MvbWlwczMvbWlwczY0LydgLXVua25vd24KKwkJOzsKKwltb25p
dG9yKQorCQliYXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1jb2ZmCisJCTs7CisJbW9y
cGhvcykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJb3M9LW1vcnBob3MKKwkJ
OzsKKwltc2RvcykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1tc2RvcworCQk7Owor
CW1zMS0qKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkIC1lICdz
L21zMS0vbXQtLydgCisJCTs7CisJbXZzKQorCQliYXNpY19tYWNoaW5lPWkzNzAtaWJtCisJCW9z
PS1tdnMKKwkJOzsKKwluY3IzMDAwKQorCQliYXNpY19tYWNoaW5lPWk0ODYtbmNyCisJCW9zPS1z
eXN2NAorCQk7OworCW5ldGJzZDM4NikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24KKwkJ
b3M9LW5ldGJzZAorCQk7OworCW5ldHdpbmRlcikKKwkJYmFzaWNfbWFjaGluZT1hcm12NGwtcmVi
ZWwKKwkJb3M9LWxpbnV4CisJCTs7CisJbmV3cyB8IG5ld3M3MDAgfCBuZXdzODAwIHwgbmV3czkw
MCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7OworCW5ld3Mx
MDAwKQorCQliYXNpY19tYWNoaW5lPW02ODAzMC1zb255CisJCW9zPS1uZXdzb3MKKwkJOzsKKwlu
ZXdzLTM2MDAgfCByaXNjLW5ld3MpCisJCWJhc2ljX21hY2hpbmU9bWlwcy1zb255CisJCW9zPS1u
ZXdzb3MKKwkJOzsKKwluZWN2NzApCisJCWJhc2ljX21hY2hpbmU9djcwLW5lYworCQlvcz0tc3lz
dgorCQk7OworCW5leHQgfCBtKi1uZXh0ICkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLW5leHQKKwkJ
Y2FzZSAkb3MgaW4KKwkJICAgIC1uZXh0c3RlcCogKQorCQkJOzsKKwkJICAgIC1uczIqKQorCQkg
ICAgICBvcz0tbmV4dHN0ZXAyCisJCQk7OworCQkgICAgKikKKwkJICAgICAgb3M9LW5leHRzdGVw
MworCQkJOzsKKwkJZXNhYworCQk7OworCW5oMzAwMCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhh
cnJpcworCQlvcz0tY3h1eAorCQk7OworCW5oWzQ1XTAwMCkKKwkJYmFzaWNfbWFjaGluZT1tODhr
LWhhcnJpcworCQlvcz0tY3h1eAorCQk7OworCW5pbmR5OTYwKQorCQliYXNpY19tYWNoaW5lPWk5
NjAtaW50ZWwKKwkJb3M9LW5pbmR5CisJCTs7CisJbW9uOTYwKQorCQliYXNpY19tYWNoaW5lPWk5
NjAtaW50ZWwKKwkJb3M9LW1vbjk2MAorCQk7OworCW5vbnN0b3B1eCkKKwkJYmFzaWNfbWFjaGlu
ZT1taXBzLWNvbXBhcQorCQlvcz0tbm9uc3RvcHV4CisJCTs7CisJbnAxKQorCQliYXNpY19tYWNo
aW5lPW5wMS1nb3VsZAorCQk7OworCW5zci10YW5kZW0pCisJCWJhc2ljX21hY2hpbmU9bnNyLXRh
bmRlbQorCQk7OworCW9wNTBuLSogfCBvcDYwYy0qKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEt
b2tpCisJCW9zPS1wcm9lbGYKKwkJOzsKKwlvcGVucmlzYyB8IG9wZW5yaXNjLSopCisJCWJhc2lj
X21hY2hpbmU9b3IzMi11bmtub3duCisJCTs7CisJb3M0MDApCisJCWJhc2ljX21hY2hpbmU9cG93
ZXJwYy1pYm0KKwkJb3M9LW9zNDAwCisJCTs7CisJT1NFNjgwMDAgfCBvc2U2ODAwMCkKKwkJYmFz
aWNfbWFjaGluZT1tNjgwMDAtZXJpY3Nzb24KKwkJb3M9LW9zZQorCQk7OworCW9zNjhrKQorCQli
YXNpY19tYWNoaW5lPW02OGstbm9uZQorCQlvcz0tb3M2OGsKKwkJOzsKKwlwYS1oaXRhY2hpKQor
CQliYXNpY19tYWNoaW5lPWhwcGExLjEtaGl0YWNoaQorCQlvcz0taGl1eHdlMgorCQk7OworCXBh
cmFnb24pCisJCWJhc2ljX21hY2hpbmU9aTg2MC1pbnRlbAorCQlvcz0tb3NmCisJCTs7CisJcGFy
aXNjKQorCQliYXNpY19tYWNoaW5lPWhwcGEtdW5rbm93bgorCQlvcz0tbGludXgKKwkJOzsKKwlw
YXJpc2MtKikKKwkJYmFzaWNfbWFjaGluZT1ocHBhLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2Vk
ICdzL15bXi1dKi0vLydgCisJCW9zPS1saW51eAorCQk7OworCXBiZCkKKwkJYmFzaWNfbWFjaGlu
ZT1zcGFyYy10dGkKKwkJOzsKKwlwYmIpCisJCWJhc2ljX21hY2hpbmU9bTY4ay10dGkKKwkJOzsK
KwlwYzUzMiB8IHBjNTMyLSopCisJCWJhc2ljX21hY2hpbmU9bnMzMmstcGM1MzIKKwkJOzsKKwlw
Yzk4KQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJOzsKKwlwYzk4LSopCisJCWJhc2ljX21h
Y2hpbmU9aTM4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7
OworCXBlbnRpdW0gfCBwNSB8IGs1IHwgazYgfCBuZXhnZW4gfCB2aWFjMykKKwkJYmFzaWNfbWFj
aGluZT1pNTg2LXBjCisJCTs7CisJcGVudGl1bXBybyB8IHA2IHwgNng4NiB8IGF0aGxvbiB8IGF0
aGxvbl8qKQorCQliYXNpY19tYWNoaW5lPWk2ODYtcGMKKwkJOzsKKwlwZW50aXVtaWkgfCBwZW50
aXVtMiB8IHBlbnRpdW1paWkgfCBwZW50aXVtMykKKwkJYmFzaWNfbWFjaGluZT1pNjg2LXBjCisJ
CTs7CisJcGVudGl1bTQpCisJCWJhc2ljX21hY2hpbmU9aTc4Ni1wYworCQk7OworCXBlbnRpdW0t
KiB8IHA1LSogfCBrNS0qIHwgazYtKiB8IG5leGdlbi0qIHwgdmlhYzMtKikKKwkJYmFzaWNfbWFj
aGluZT1pNTg2LWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCTs7
CisJcGVudGl1bXByby0qIHwgcDYtKiB8IDZ4ODYtKiB8IGF0aGxvbi0qKQorCQliYXNpY19tYWNo
aW5lPWk2ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsK
KwlwZW50aXVtaWktKiB8IHBlbnRpdW0yLSogfCBwZW50aXVtaWlpLSogfCBwZW50aXVtMy0qKQor
CQliYXNpY19tYWNoaW5lPWk2ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0q
LS8vJ2AKKwkJOzsKKwlwZW50aXVtNC0qKQorCQliYXNpY19tYWNoaW5lPWk3ODYtYGVjaG8gJGJh
c2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwbikKKwkJYmFzaWNfbWFj
aGluZT1wbi1nb3VsZAorCQk7OworCXBvd2VyKQliYXNpY19tYWNoaW5lPXBvd2VyLWlibQorCQk7
OworCXBwYykJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJOzsKKwlwcGMtKikJYmFz
aWNfbWFjaGluZT1wb3dlcnBjLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0v
LydgCisJCTs7CisJcHBjbGUgfCBwb3dlcnBjbGl0dGxlIHwgcHBjLWxlIHwgcG93ZXJwYy1saXR0
bGUpCisJCWJhc2ljX21hY2hpbmU9cG93ZXJwY2xlLXVua25vd24KKwkJOzsKKwlwcGNsZS0qIHwg
cG93ZXJwY2xpdHRsZS0qKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGNsZS1gZWNobyAkYmFzaWNf
bWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBwYzY0KQliYXNpY19tYWNoaW5l
PXBvd2VycGM2NC11bmtub3duCisJCTs7CisJcHBjNjQtKikgYmFzaWNfbWFjaGluZT1wb3dlcnBj
NjQtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwcGM2
NGxlIHwgcG93ZXJwYzY0bGl0dGxlIHwgcHBjNjQtbGUgfCBwb3dlcnBjNjQtbGl0dGxlKQorCQli
YXNpY19tYWNoaW5lPXBvd2VycGM2NGxlLXVua25vd24KKwkJOzsKKwlwcGM2NGxlLSogfCBwb3dl
cnBjNjRsaXR0bGUtKikKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjNjRsZS1gZWNobyAkYmFzaWNf
bWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBzMikKKwkJYmFzaWNfbWFjaGlu
ZT1pMzg2LWlibQorCQk7OworCXB3MzIpCisJCWJhc2ljX21hY2hpbmU9aTU4Ni11bmtub3duCisJ
CW9zPS1wdzMyCisJCTs7CisJcmRvcykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1y
ZG9zCisJCTs7CisJcm9tNjhrKQorCQliYXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1j
b2ZmCisJCTs7CisJcm1bNDZdMDApCisJCWJhc2ljX21hY2hpbmU9bWlwcy1zaWVtZW5zCisJCTs7
CisJcnRwYyB8IHJ0cGMtKikKKwkJYmFzaWNfbWFjaGluZT1yb21wLWlibQorCQk7OworCXMzOTAg
fCBzMzkwLSopCisJCWJhc2ljX21hY2hpbmU9czM5MC1pYm0KKwkJOzsKKwlzMzkweCB8IHMzOTB4
LSopCisJCWJhc2ljX21hY2hpbmU9czM5MHgtaWJtCisJCTs7CisJc2EyOTIwMCkKKwkJYmFzaWNf
bWFjaGluZT1hMjlrLWFtZAorCQlvcz0tdWRpCisJCTs7CisJc2IxKQorCQliYXNpY19tYWNoaW5l
PW1pcHNpc2E2NHNiMS11bmtub3duCisJCTs7CisJc2IxZWwpCisJCWJhc2ljX21hY2hpbmU9bWlw
c2lzYTY0c2IxZWwtdW5rbm93bgorCQk7OworCXNkZSkKKwkJYmFzaWNfbWFjaGluZT1taXBzaXNh
MzItc2RlCisJCW9zPS1lbGYKKwkJOzsKKwlzZWkpCisJCWJhc2ljX21hY2hpbmU9bWlwcy1zZWkK
KwkJb3M9LXNlaXV4CisJCTs7CisJc2VxdWVudCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXNlcXVl
bnQKKwkJOzsKKwlzaCkKKwkJYmFzaWNfbWFjaGluZT1zaC1oaXRhY2hpCisJCW9zPS1obXMKKwkJ
OzsKKwlzaDVlbCkKKwkJYmFzaWNfbWFjaGluZT1zaDVsZS11bmtub3duCisJCTs7CisJc2g2NCkK
KwkJYmFzaWNfbWFjaGluZT1zaDY0LXVua25vd24KKwkJOzsKKwlzcGFyY2xpdGUtd3JzIHwgc2lt
c28td3JzKQorCQliYXNpY19tYWNoaW5lPXNwYXJjbGl0ZS13cnMKKwkJb3M9LXZ4d29ya3MKKwkJ
OzsKKwlzcHM3KQorCQliYXNpY19tYWNoaW5lPW02OGstYnVsbAorCQlvcz0tc3lzdjIKKwkJOzsK
KwlzcHVyKQorCQliYXNpY19tYWNoaW5lPXNwdXItdW5rbm93bgorCQk7OworCXN0MjAwMCkKKwkJ
YmFzaWNfbWFjaGluZT1tNjhrLXRhbmRlbQorCQk7OworCXN0cmF0dXMpCisJCWJhc2ljX21hY2hp
bmU9aTg2MC1zdHJhdHVzCisJCW9zPS1zeXN2NAorCQk7OworCXN1bjIpCisJCWJhc2ljX21hY2hp
bmU9bTY4MDAwLXN1bgorCQk7OworCXN1bjJvczMpCisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1
bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuMm9zNCkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAt
c3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW4zb3MzKQorCQliYXNpY19tYWNoaW5lPW02OGst
c3VuCisJCW9zPS1zdW5vczMKKwkJOzsKKwlzdW4zb3M0KQorCQliYXNpY19tYWNoaW5lPW02OGst
c3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW40b3MzKQorCQliYXNpY19tYWNoaW5lPXNwYXJj
LXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuNG9zNCkKKwkJYmFzaWNfbWFjaGluZT1zcGFy
Yy1zdW4KKwkJb3M9LXN1bm9zNAorCQk7OworCXN1bjRzb2wyKQorCQliYXNpY19tYWNoaW5lPXNw
YXJjLXN1bgorCQlvcz0tc29sYXJpczIKKwkJOzsKKwlzdW4zIHwgc3VuMy0qKQorCQliYXNpY19t
YWNoaW5lPW02OGstc3VuCisJCTs7CisJc3VuNCkKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4K
KwkJOzsKKwlzdW4zODYgfCBzdW4zODZpIHwgcm9hZHJ1bm5lcikKKwkJYmFzaWNfbWFjaGluZT1p
Mzg2LXN1bgorCQk7OworCXN2MSkKKwkJYmFzaWNfbWFjaGluZT1zdjEtY3JheQorCQlvcz0tdW5p
Y29zCisJCTs7CisJc3ltbWV0cnkpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1zZXF1ZW50CisJCW9z
PS1keW5peAorCQk7OworCXQzZSkKKwkJYmFzaWNfbWFjaGluZT1hbHBoYWV2NS1jcmF5CisJCW9z
PS11bmljb3MKKwkJOzsKKwl0OTApCisJCWJhc2ljX21hY2hpbmU9dDkwLWNyYXkKKwkJb3M9LXVu
aWNvcworCQk7OworCXRpYzU0eCB8IGM1NHgqKQorCQliYXNpY19tYWNoaW5lPXRpYzU0eC11bmtu
b3duCisJCW9zPS1jb2ZmCisJCTs7CisJdGljNTV4IHwgYzU1eCopCisJCWJhc2ljX21hY2hpbmU9
dGljNTV4LXVua25vd24KKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM2eCB8IGM2eCopCisJCWJhc2lj
X21hY2hpbmU9dGljNngtdW5rbm93bgorCQlvcz0tY29mZgorCQk7OworCXRpbGUqKQorCQliYXNp
Y19tYWNoaW5lPXRpbGUtdW5rbm93bgorCQlvcz0tbGludXgtZ251CisJCTs7CisJdHgzOSkKKwkJ
YmFzaWNfbWFjaGluZT1taXBzdHgzOS11bmtub3duCisJCTs7CisJdHgzOWVsKQorCQliYXNpY19t
YWNoaW5lPW1pcHN0eDM5ZWwtdW5rbm93bgorCQk7OworCXRvYWQxKQorCQliYXNpY19tYWNoaW5l
PXBkcDEwLXhrbAorCQlvcz0tdG9wczIwCisJCTs7CisJdG93ZXIgfCB0b3dlci0zMikKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLW5jcgorCQk7OworCXRwZikKKwkJYmFzaWNfbWFjaGluZT1zMzkweC1p
Ym0KKwkJb3M9LXRwZgorCQk7OworCXVkaTI5aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLWFtZAor
CQlvcz0tdWRpCisJCTs7CisJdWx0cmEzKQorCQliYXNpY19tYWNoaW5lPWEyOWstbnl1CisJCW9z
PS1zeW0xCisJCTs7CisJdjgxMCB8IG5lY3Y4MTApCisJCWJhc2ljX21hY2hpbmU9djgxMC1uZWMK
KwkJb3M9LW5vbmUKKwkJOzsKKwl2YXh2KQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJb3M9
LXN5c3YKKwkJOzsKKwl2bXMpCisJCWJhc2ljX21hY2hpbmU9dmF4LWRlYworCQlvcz0tdm1zCisJ
CTs7CisJdnBwKnx2eHx2eC0qKQorCQliYXNpY19tYWNoaW5lPWYzMDEtZnVqaXRzdQorCQk7Owor
CXZ4d29ya3M5NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC13cnMKKwkJb3M9LXZ4d29ya3MKKwkJ
OzsKKwl2eHdvcmtzNjgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay13cnMKKwkJb3M9LXZ4d29ya3MK
KwkJOzsKKwl2eHdvcmtzMjlrKQorCQliYXNpY19tYWNoaW5lPWEyOWstd3JzCisJCW9zPS12eHdv
cmtzCisJCTs7CisJdzY1KikKKwkJYmFzaWNfbWFjaGluZT13NjUtd2RjCisJCW9zPS1ub25lCisJ
CTs7CisJdzg5ay0qKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtd2luYm9uZAorCQlvcz0tcHJv
ZWxmCisJCTs7CisJeGJveCkKKwkJYmFzaWNfbWFjaGluZT1pNjg2LXBjCisJCW9zPS1taW5ndzMy
CisJCTs7CisJeHBzIHwgeHBzMTAwKQorCQliYXNpY19tYWNoaW5lPXhwczEwMC1ob25leXdlbGwK
KwkJOzsKKwl5bXApCisJCWJhc2ljX21hY2hpbmU9eW1wLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7
OworCXo4ay0qLWNvZmYpCisJCWJhc2ljX21hY2hpbmU9ejhrLXVua25vd24KKwkJb3M9LXNpbQor
CQk7OworCXo4MC0qLWNvZmYpCisJCWJhc2ljX21hY2hpbmU9ejgwLXVua25vd24KKwkJb3M9LXNp
bQorCQk7OworCW5vbmUpCisJCWJhc2ljX21hY2hpbmU9bm9uZS1ub25lCisJCW9zPS1ub25lCisJ
CTs7CisKKyMgSGVyZSB3ZSBoYW5kbGUgdGhlIGRlZmF1bHQgbWFudWZhY3R1cmVyIG9mIGNlcnRh
aW4gQ1BVIHR5cGVzLiAgSXQgaXMgaW4KKyMgc29tZSBjYXNlcyB0aGUgb25seSBtYW51ZmFjdHVy
ZXIsIGluIG90aGVycywgaXQgaXMgdGhlIG1vc3QgcG9wdWxhci4KKwl3ODlrKQorCQliYXNpY19t
YWNoaW5lPWhwcGExLjEtd2luYm9uZAorCQk7OworCW9wNTBuKQorCQliYXNpY19tYWNoaW5lPWhw
cGExLjEtb2tpCisJCTs7CisJb3A2MGMpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1va2kKKwkJ
OzsKKwlyb21wKQorCQliYXNpY19tYWNoaW5lPXJvbXAtaWJtCisJCTs7CisJbW1peCkKKwkJYmFz
aWNfbWFjaGluZT1tbWl4LWtudXRoCisJCTs7CisJcnM2MDAwKQorCQliYXNpY19tYWNoaW5lPXJz
NjAwMC1pYm0KKwkJOzsKKwl2YXgpCisJCWJhc2ljX21hY2hpbmU9dmF4LWRlYworCQk7OworCXBk
cDEwKQorCQkjIHRoZXJlIGFyZSBtYW55IGNsb25lcywgc28gREVDIGlzIG5vdCBhIHNhZmUgYmV0
CisJCWJhc2ljX21hY2hpbmU9cGRwMTAtdW5rbm93bgorCQk7OworCXBkcDExKQorCQliYXNpY19t
YWNoaW5lPXBkcDExLWRlYworCQk7OworCXdlMzJrKQorCQliYXNpY19tYWNoaW5lPXdlMzJrLWF0
dAorCQk7OworCXNoWzEyMzRdIHwgc2hbMjRdYSB8IHNoWzI0XWFlYiB8IHNoWzM0XWViIHwgc2hb
MTIzNF1sZSB8IHNoWzIzXWVsZSkKKwkJYmFzaWNfbWFjaGluZT1zaC11bmtub3duCisJCTs7CisJ
c3BhcmMgfCBzcGFyY3Y4IHwgc3BhcmN2OSB8IHNwYXJjdjliIHwgc3BhcmN2OXYpCisJCWJhc2lj
X21hY2hpbmU9c3BhcmMtc3VuCisJCTs7CisJY3lkcmEpCisJCWJhc2ljX21hY2hpbmU9Y3lkcmEt
Y3lkcm9tZQorCQk7OworCW9yaW9uKQorCQliYXNpY19tYWNoaW5lPW9yaW9uLWhpZ2hsZXZlbAor
CQk7OworCW9yaW9uMTA1KQorCQliYXNpY19tYWNoaW5lPWNsaXBwZXItaGlnaGxldmVsCisJCTs7
CisJbWFjIHwgbXB3IHwgbWFjLW1wdykKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWFwcGxlCisJCTs7
CisJcG1hYyB8IHBtYWMtbXB3KQorCQliYXNpY19tYWNoaW5lPXBvd2VycGMtYXBwbGUKKwkJOzsK
KwkqLXVua25vd24pCisJCSMgTWFrZSBzdXJlIHRvIG1hdGNoIGFuIGFscmVhZHktY2Fub25pY2Fs
aXplZCBtYWNoaW5lIG5hbWUuCisJCTs7CisJKikKKwkJZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRp
b24gXGAkMVwnOiBtYWNoaW5lIFxgJGJhc2ljX21hY2hpbmVcJyBub3QgcmVjb2duaXplZCAxPiYy
CisJCWV4aXQgMQorCQk7OworZXNhYworCisjIEhlcmUgd2UgY2Fub25pY2FsaXplIGNlcnRhaW4g
YWxpYXNlcyBmb3IgbWFudWZhY3R1cmVycy4KK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwkqLWRp
Z2l0YWwqKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL2Rp
Z2l0YWwuKi9kZWMvJ2AKKwkJOzsKKwkqLWNvbW1vZG9yZSopCisJCWJhc2ljX21hY2hpbmU9YGVj
aG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvY29tbW9kb3JlLiovY2JtLydgCisJCTs7CisJKikK
KwkJOzsKK2VzYWMKKworIyBEZWNvZGUgbWFudWZhY3R1cmVyLXNwZWNpZmljIGFsaWFzZXMgZm9y
IGNlcnRhaW4gb3BlcmF0aW5nIHN5c3RlbXMuCisKK2lmIFsgeCIkb3MiICE9IHgiIiBdCit0aGVu
CitjYXNlICRvcyBpbgorICAgICAgICAjIEZpcnN0IG1hdGNoIHNvbWUgc3lzdGVtIHR5cGUgYWxp
YXNlcworICAgICAgICAjIHRoYXQgbWlnaHQgZ2V0IGNvbmZ1c2VkIHdpdGggdmFsaWQgc3lzdGVt
IHR5cGVzLgorCSMgLXNvbGFyaXMqIGlzIGEgYmFzaWMgc3lzdGVtIHR5cGUsIHdpdGggdGhpcyBv
bmUgZXhjZXB0aW9uLgorICAgICAgICAtYXVyb3JhdXgpCisJICAgICAgICBvcz0tYXVyb3JhdXgK
KwkJOzsKKwktc29sYXJpczEgfCAtc29sYXJpczEuKikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1l
ICdzfHNvbGFyaXMxfHN1bm9zNHwnYAorCQk7OworCS1zb2xhcmlzKQorCQlvcz0tc29sYXJpczIK
KwkJOzsKKwktc3ZyNCopCisJCW9zPS1zeXN2NAorCQk7OworCS11bml4d2FyZSopCisJCW9zPS1z
eXN2NC4ydXcKKwkJOzsKKwktZ251L2xpbnV4KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdz
fGdudS9saW51eHxsaW51eC1nbnV8J2AKKwkJOzsKKwkjIEZpcnN0IGFjY2VwdCB0aGUgYmFzaWMg
c3lzdGVtIHR5cGVzLgorCSMgVGhlIHBvcnRhYmxlIHN5c3RlbXMgY29tZXMgZmlyc3QuCisJIyBF
YWNoIGFsdGVybmF0aXZlIE1VU1QgRU5EIElOIEEgKiwgdG8gbWF0Y2ggYSB2ZXJzaW9uIG51bWJl
ci4KKwkjIC1zeXN2KiBpcyBub3QgaGVyZSBiZWNhdXNlIGl0IGNvbWVzIGxhdGVyLCBhZnRlciBz
eXN2cjQuCisJLWdudSogfCAtYnNkKiB8IC1tYWNoKiB8IC1taW5peCogfCAtZ2VuaXgqIHwgLXVs
dHJpeCogfCAtaXJpeCogXAorCSAgICAgIHwgLSp2bXMqIHwgLXNjbyogfCAtZXNpeCogfCAtaXNj
KiB8IC1haXgqIHwgLWNuayogfCAtc3Vub3MgfCAtc3Vub3NbMzRdKlwKKwkgICAgICB8IC1ocHV4
KiB8IC11bm9zKiB8IC1vc2YqIHwgLWx1bmEqIHwgLWRndXgqIHwgLWF1cm9yYXV4KiB8IC1zb2xh
cmlzKiBcCisJICAgICAgfCAtc3ltKiB8IC1rb3BlbnNvbGFyaXMqIFwKKwkgICAgICB8IC1hbWln
YW9zKiB8IC1hbWlnYWRvcyogfCAtbXNkb3MqIHwgLW5ld3NvcyogfCAtdW5pY29zKiB8IC1hb2Yq
IFwKKwkgICAgICB8IC1hb3MqIHwgLWFyb3MqIFwKKwkgICAgICB8IC1uaW5keSogfCAtdnhzaW0q
IHwgLXZ4d29ya3MqIHwgLWVibW9uKiB8IC1obXMqIHwgLW12cyogXAorCSAgICAgIHwgLWNsaXgq
IHwgLXJpc2NvcyogfCAtdW5pcGx1cyogfCAtaXJpcyogfCAtcnR1KiB8IC14ZW5peCogXAorCSAg
ICAgIHwgLWhpdXgqIHwgLTM4NmJzZCogfCAta25ldGJzZCogfCAtbWlyYnNkKiB8IC1uZXRic2Qq
IFwKKwkgICAgICB8IC1vcGVuYnNkKiB8IC1zb2xpZGJzZCogXAorCSAgICAgIHwgLWVra29ic2Qq
IHwgLWtmcmVlYnNkKiB8IC1mcmVlYnNkKiB8IC1yaXNjaXgqIHwgLWx5bnhvcyogXAorCSAgICAg
IHwgLWJvc3gqIHwgLW5leHRzdGVwKiB8IC1jeHV4KiB8IC1hb3V0KiB8IC1lbGYqIHwgLW9hYmkq
IFwKKwkgICAgICB8IC1wdHgqIHwgLWNvZmYqIHwgLWVjb2ZmKiB8IC13aW5udCogfCAtZG9tYWlu
KiB8IC12c3RhKiBcCisJICAgICAgfCAtdWRpKiB8IC1lYWJpKiB8IC1saXRlcyogfCAtaWVlZSog
fCAtZ28zMiogfCAtYXV4KiBcCisJICAgICAgfCAtY2hvcnVzb3MqIHwgLWNob3J1c3JkYiogfCAt
Y2VnY2MqIFwKKwkgICAgICB8IC1jeWd3aW4qIHwgLXBlKiB8IC1wc29zKiB8IC1tb3NzKiB8IC1w
cm9lbGYqIHwgLXJ0ZW1zKiBcCisJICAgICAgfCAtbWluZ3czMiogfCAtbGludXgtZ251KiB8IC1s
aW51eC1uZXdsaWIqIHwgLWxpbnV4LXVjbGliYyogXAorCSAgICAgIHwgLXV4cHYqIHwgLWJlb3Mq
IHwgLW1wZWl4KiB8IC11ZGsqIFwKKwkgICAgICB8IC1pbnRlcml4KiB8IC11d2luKiB8IC1ta3Mq
IHwgLXJoYXBzb2R5KiB8IC1kYXJ3aW4qIHwgLW9wZW5lZCogXAorCSAgICAgIHwgLW9wZW5zdGVw
KiB8IC1vc2tpdCogfCAtY29uaXgqIHwgLXB3MzIqIHwgLW5vbnN0b3B1eCogXAorCSAgICAgIHwg
LXN0b3JtLWNoYW9zKiB8IC10b3BzMTAqIHwgLXRlbmV4KiB8IC10b3BzMjAqIHwgLWl0cyogXAor
CSAgICAgIHwgLW9zMiogfCAtdm9zKiB8IC1wYWxtb3MqIHwgLXVjbGludXgqIHwgLW51Y2xldXMq
IFwKKwkgICAgICB8IC1tb3JwaG9zKiB8IC1zdXBlcnV4KiB8IC1ydG1rKiB8IC1ydG1rLW5vdmEq
IHwgLXdpbmRpc3MqIFwKKwkgICAgICB8IC1wb3dlcm1heCogfCAtZG5peCogfCAtbng2IHwgLW54
NyB8IC1zZWkqIHwgLWRyYWdvbmZseSogXAorCSAgICAgIHwgLXNreW9zKiB8IC1oYWlrdSogfCAt
cmRvcyogfCAtdG9wcGVycyogfCAtZHJvcHMqIHwgLWVzKikKKwkjIFJlbWVtYmVyLCBlYWNoIGFs
dGVybmF0aXZlIE1VU1QgRU5EIElOICosIHRvIG1hdGNoIGEgdmVyc2lvbiBudW1iZXIuCisJCTs7
CisJLXFueCopCisJCWNhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwkJICAgIHg4Ni0qIHwgaSo4Ni0q
KQorCQkJOzsKKwkJICAgICopCisJCQlvcz0tbnRvJG9zCisJCQk7OworCQllc2FjCisJCTs7CisJ
LW50by1xbngqKQorCQk7OworCS1udG8qKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bnRv
fG50by1xbnh8J2AKKwkJOzsKKwktc2ltIHwgLWVzMTgwMCogfCAtaG1zKiB8IC14cmF5IHwgLW9z
NjhrKiB8IC1ub25lKiB8IC12ODhyKiBcCisJICAgICAgfCAtd2luZG93cyogfCAtb3N4IHwgLWFi
dWcgfCAtbmV0d2FyZSogfCAtb3M5KiB8IC1iZW9zKiB8IC1oYWlrdSogXAorCSAgICAgIHwgLW1h
Y29zKiB8IC1tcHcqIHwgLW1hZ2ljKiB8IC1tbWl4d2FyZSogfCAtbW9uOTYwKiB8IC1sbmV3cyop
CisJCTs7CisJLW1hYyopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xtYWN8bWFjb3N8J2AK
KwkJOzsKKwktbGludXgtZGlldGxpYmMpCisJCW9zPS1saW51eC1kaWV0bGliYworCQk7OworCS1s
aW51eCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xsaW51eHxsaW51eC1nbnV8J2AKKwkJ
OzsKKwktc3Vub3M1KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfHN1bm9zNXxzb2xhcmlz
MnwnYAorCQk7OworCS1zdW5vczYqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8c3Vub3M2
fHNvbGFyaXMzfCdgCisJCTs7CisJLW9wZW5lZCopCisJCW9zPS1vcGVuZWRpdGlvbgorCQk7Owor
ICAgICAgICAtb3M0MDAqKQorCQlvcz0tb3M0MDAKKwkJOzsKKwktd2luY2UqKQorCQlvcz0td2lu
Y2UKKwkJOzsKKwktb3Nmcm9zZSopCisJCW9zPS1vc2Zyb3NlCisJCTs7CisJLW9zZiopCisJCW9z
PS1vc2YKKwkJOzsKKwktdXRlayopCisJCW9zPS1ic2QKKwkJOzsKKwktZHluaXgqKQorCQlvcz0t
YnNkCisJCTs7CisJLWFjaXMqKQorCQlvcz0tYW9zCisJCTs7CisJLWF0aGVvcyopCisJCW9zPS1h
dGhlb3MKKwkJOzsKKwktc3lsbGFibGUqKQorCQlvcz0tc3lsbGFibGUKKwkJOzsKKwktMzg2YnNk
KQorCQlvcz0tYnNkCisJCTs7CisJLWN0aXgqIHwgLXV0cyopCisJCW9zPS1zeXN2CisJCTs7CisJ
LW5vdmEqKQorCQlvcz0tcnRtay1ub3ZhCisJCTs7CisJLW5zMiApCisJCW9zPS1uZXh0c3RlcDIK
KwkJOzsKKwktbnNrKikKKwkJb3M9LW5zaworCQk7OworCSMgUHJlc2VydmUgdGhlIHZlcnNpb24g
bnVtYmVyIG9mIHNpbml4NS4KKwktc2luaXg1LiopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAn
c3xzaW5peHxzeXN2fCdgCisJCTs7CisJLXNpbml4KikKKwkJb3M9LXN5c3Y0CisJCTs7CisgICAg
ICAgIC10cGYqKQorCQlvcz0tdHBmCisJCTs7CisJLXRyaXRvbiopCisJCW9zPS1zeXN2MworCQk7
OworCS1vc3MqKQorCQlvcz0tc3lzdjMKKwkJOzsKKwktc3ZyNCkKKwkJb3M9LXN5c3Y0CisJCTs7
CisJLXN2cjMpCisJCW9zPS1zeXN2MworCQk7OworCS1zeXN2cjQpCisJCW9zPS1zeXN2NAorCQk7
OworCSMgVGhpcyBtdXN0IGNvbWUgYWZ0ZXIgLXN5c3ZyNC4KKwktc3lzdiopCisJCTs7CisJLW9z
ZSopCisJCW9zPS1vc2UKKwkJOzsKKwktZXMxODAwKikKKwkJb3M9LW9zZQorCQk7OworCS14ZW5p
eCkKKwkJb3M9LXhlbml4CisJCTs7CisJLSptaW50IHwgLW1pbnRbMC05XSogfCAtKk1pTlQgfCAt
TWlOVFswLTldKikKKwkJb3M9LW1pbnQKKwkJOzsKKwktYXJvcyopCisJCW9zPS1hcm9zCisJCTs7
CisJLWthb3MqKQorCQlvcz0ta2FvcworCQk7OworCS16dm1vZSkKKwkJb3M9LXp2bW9lCisJCTs7
CisJLWRpY29zKikKKwkJb3M9LWRpY29zCisJCTs7CisJLW5vbmUpCisJCTs7CisJKikKKwkJIyBH
ZXQgcmlkIG9mIHRoZSBgLScgYXQgdGhlIGJlZ2lubmluZyBvZiAkb3MuCisJCW9zPWBlY2hvICRv
cyB8IHNlZCAncy9bXi1dKi0vLydgCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxgJDFc
Jzogc3lzdGVtIFxgJG9zXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0IDEKKwkJOzsKK2Vz
YWMKK2Vsc2UKKworIyBIZXJlIHdlIGhhbmRsZSB0aGUgZGVmYXVsdCBvcGVyYXRpbmcgc3lzdGVt
cyB0aGF0IGNvbWUgd2l0aCB2YXJpb3VzIG1hY2hpbmVzLgorIyBUaGUgdmFsdWUgc2hvdWxkIGJl
IHdoYXQgdGhlIHZlbmRvciBjdXJyZW50bHkgc2hpcHMgb3V0IHRoZSBkb29yIHdpdGggdGhlaXIK
KyMgbWFjaGluZSBvciBwdXQgYW5vdGhlciB3YXksIHRoZSBtb3N0IHBvcHVsYXIgb3MgcHJvdmlk
ZWQgd2l0aCB0aGUgbWFjaGluZS4KKworIyBOb3RlIHRoYXQgaWYgeW91J3JlIGdvaW5nIHRvIHRy
eSB0byBtYXRjaCAiLU1BTlVGQUNUVVJFUiIgaGVyZSAoc2F5LAorIyAiLXN1biIpLCB0aGVuIHlv
dSBoYXZlIHRvIHRlbGwgdGhlIGNhc2Ugc3RhdGVtZW50IHVwIHRvd2FyZHMgdGhlIHRvcAorIyB0
aGF0IE1BTlVGQUNUVVJFUiBpc24ndCBhbiBvcGVyYXRpbmcgc3lzdGVtLiAgT3RoZXJ3aXNlLCBj
b2RlIGFib3ZlCisjIHdpbGwgc2lnbmFsIGFuIGVycm9yIHNheWluZyB0aGF0IE1BTlVGQUNUVVJF
UiBpc24ndCBhbiBvcGVyYXRpbmcKKyMgc3lzdGVtLCBhbmQgd2UnbGwgbmV2ZXIgZ2V0IHRvIHRo
aXMgcG9pbnQuCisKK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKyAgICAgICAgc2NvcmUtKikKKwkJ
b3M9LWVsZgorCQk7OworICAgICAgICBzcHUtKikKKwkJb3M9LWVsZgorCQk7OworCSotYWNvcm4p
CisJCW9zPS1yaXNjaXgxLjIKKwkJOzsKKwlhcm0qLXJlYmVsKQorCQlvcz0tbGludXgKKwkJOzsK
Kwlhcm0qLXNlbWkpCisJCW9zPS1hb3V0CisJCTs7CisgICAgICAgIGM0eC0qIHwgdGljNHgtKikK
KyAgICAgICAgCW9zPS1jb2ZmCisJCTs7CisJIyBUaGlzIG11c3QgY29tZSBiZWZvcmUgdGhlICot
ZGVjIGVudHJ5LgorCXBkcDEwLSopCisJCW9zPS10b3BzMjAKKwkJOzsKKwlwZHAxMS0qKQorCQlv
cz0tbm9uZQorCQk7OworCSotZGVjIHwgdmF4LSopCisJCW9zPS11bHRyaXg0LjIKKwkJOzsKKwlt
NjgqLWFwb2xsbykKKwkJb3M9LWRvbWFpbgorCQk7OworCWkzODYtc3VuKQorCQlvcz0tc3Vub3M0
LjAuMgorCQk7OworCW02ODAwMC1zdW4pCisJCW9zPS1zdW5vczMKKwkJIyBUaGlzIGFsc28gZXhp
c3RzIGluIHRoZSBjb25maWd1cmUgcHJvZ3JhbSwgYnV0IHdhcyBub3QgdGhlCisJCSMgZGVmYXVs
dC4KKwkJIyBvcz0tc3Vub3M0CisJCTs7CisJbTY4Ki1jaXNjbykKKwkJb3M9LWFvdXQKKwkJOzsK
KyAgICAgICAgbWVwLSopCisJCW9zPS1lbGYKKwkJOzsKKwltaXBzKi1jaXNjbykKKwkJb3M9LWVs
ZgorCQk7OworCW1pcHMqLSopCisJCW9zPS1lbGYKKwkJOzsKKwlvcjMyLSopCisJCW9zPS1jb2Zm
CisJCTs7CisJKi10dGkpCSMgbXVzdCBiZSBiZWZvcmUgc3BhcmMgZW50cnkgb3Igd2UgZ2V0IHRo
ZSB3cm9uZyBvcy4KKwkJb3M9LXN5c3YzCisJCTs7CisJc3BhcmMtKiB8ICotc3VuKQorCQlvcz0t
c3Vub3M0LjEuMQorCQk7OworCSotYmUpCisJCW9zPS1iZW9zCisJCTs7CisJKi1oYWlrdSkKKwkJ
b3M9LWhhaWt1CisJCTs7CisJKi1pYm0pCisJCW9zPS1haXgKKwkJOzsKKyAgICAJKi1rbnV0aCkK
KwkJb3M9LW1taXh3YXJlCisJCTs7CisJKi13ZWMpCisJCW9zPS1wcm9lbGYKKwkJOzsKKwkqLXdp
bmJvbmQpCisJCW9zPS1wcm9lbGYKKwkJOzsKKwkqLW9raSkKKwkJb3M9LXByb2VsZgorCQk7Owor
CSotaHApCisJCW9zPS1ocHV4CisJCTs7CisJKi1oaXRhY2hpKQorCQlvcz0taGl1eAorCQk7Owor
CWk4NjAtKiB8ICotYXR0IHwgKi1uY3IgfCAqLWFsdG9zIHwgKi1tb3Rvcm9sYSB8ICotY29udmVy
Z2VudCkKKwkJb3M9LXN5c3YKKwkJOzsKKwkqLWNibSkKKwkJb3M9LWFtaWdhb3MKKwkJOzsKKwkq
LWRnKQorCQlvcz0tZGd1eAorCQk7OworCSotZG9scGhpbikKKwkJb3M9LXN5c3YzCisJCTs7CisJ
bTY4ay1jY3VyKQorCQlvcz0tcnR1CisJCTs7CisJbTg4ay1vbXJvbiopCisJCW9zPS1sdW5hCisJ
CTs7CisJKi1uZXh0ICkKKwkJb3M9LW5leHRzdGVwCisJCTs7CisJKi1zZXF1ZW50KQorCQlvcz0t
cHR4CisJCTs7CisJKi1jcmRzKQorCQlvcz0tdW5vcworCQk7OworCSotbnMpCisJCW9zPS1nZW5p
eAorCQk7OworCWkzNzAtKikKKwkJb3M9LW12cworCQk7OworCSotbmV4dCkKKwkJb3M9LW5leHRz
dGVwMworCQk7OworCSotZ291bGQpCisJCW9zPS1zeXN2CisJCTs7CisJKi1oaWdobGV2ZWwpCisJ
CW9zPS1ic2QKKwkJOzsKKwkqLWVuY29yZSkKKwkJb3M9LWJzZAorCQk7OworCSotc2dpKQorCQlv
cz0taXJpeAorCQk7OworCSotc2llbWVucykKKwkJb3M9LXN5c3Y0CisJCTs7CisJKi1tYXNzY29t
cCkKKwkJb3M9LXJ0dQorCQk7OworCWYzMFswMV0tZnVqaXRzdSB8IGY3MDAtZnVqaXRzdSkKKwkJ
b3M9LXV4cHYKKwkJOzsKKwkqLXJvbTY4aykKKwkJb3M9LWNvZmYKKwkJOzsKKwkqLSpidWcpCisJ
CW9zPS1jb2ZmCisJCTs7CisJKi1hcHBsZSkKKwkJb3M9LW1hY29zCisJCTs7CisJKi1hdGFyaSop
CisJCW9zPS1taW50CisJCTs7CisJKikKKwkJb3M9LW5vbmUKKwkJOzsKK2VzYWMKK2ZpCisKKyMg
SGVyZSB3ZSBoYW5kbGUgdGhlIGNhc2Ugd2hlcmUgd2Uga25vdyB0aGUgb3MsIGFuZCB0aGUgQ1BV
IHR5cGUsIGJ1dCBub3QgdGhlCisjIG1hbnVmYWN0dXJlci4gIFdlIHBpY2sgdGhlIGxvZ2ljYWwg
bWFudWZhY3R1cmVyLgordmVuZG9yPXVua25vd24KK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwkq
LXVua25vd24pCisJCWNhc2UgJG9zIGluCisJCQktcmlzY2l4KikKKwkJCQl2ZW5kb3I9YWNvcm4K
KwkJCQk7OworCQkJLXN1bm9zKikKKwkJCQl2ZW5kb3I9c3VuCisJCQkJOzsKKwkJCS1jbmsqfC1h
aXgqKQorCQkJCXZlbmRvcj1pYm0KKwkJCQk7OworCQkJLWJlb3MqKQorCQkJCXZlbmRvcj1iZQor
CQkJCTs7CisJCQktaHB1eCopCisJCQkJdmVuZG9yPWhwCisJCQkJOzsKKwkJCS1tcGVpeCopCisJ
CQkJdmVuZG9yPWhwCisJCQkJOzsKKwkJCS1oaXV4KikKKwkJCQl2ZW5kb3I9aGl0YWNoaQorCQkJ
CTs7CisJCQktdW5vcyopCisJCQkJdmVuZG9yPWNyZHMKKwkJCQk7OworCQkJLWRndXgqKQorCQkJ
CXZlbmRvcj1kZworCQkJCTs7CisJCQktbHVuYSopCisJCQkJdmVuZG9yPW9tcm9uCisJCQkJOzsK
KwkJCS1nZW5peCopCisJCQkJdmVuZG9yPW5zCisJCQkJOzsKKwkJCS1tdnMqIHwgLW9wZW5lZCop
CisJCQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQktb3M0MDAqKQorCQkJCXZlbmRvcj1pYm0KKwkJ
CQk7OworCQkJLXB0eCopCisJCQkJdmVuZG9yPXNlcXVlbnQKKwkJCQk7OworCQkJLXRwZiopCisJ
CQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQktdnhzaW0qIHwgLXZ4d29ya3MqIHwgLXdpbmRpc3Mq
KQorCQkJCXZlbmRvcj13cnMKKwkJCQk7OworCQkJLWF1eCopCisJCQkJdmVuZG9yPWFwcGxlCisJ
CQkJOzsKKwkJCS1obXMqKQorCQkJCXZlbmRvcj1oaXRhY2hpCisJCQkJOzsKKwkJCS1tcHcqIHwg
LW1hY29zKikKKwkJCQl2ZW5kb3I9YXBwbGUKKwkJCQk7OworCQkJLSptaW50IHwgLW1pbnRbMC05
XSogfCAtKk1pTlQgfCAtTWlOVFswLTldKikKKwkJCQl2ZW5kb3I9YXRhcmkKKwkJCQk7OworCQkJ
LXZvcyopCisJCQkJdmVuZG9yPXN0cmF0dXMKKwkJCQk7OworCQllc2FjCisJCWJhc2ljX21hY2hp
bmU9YGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgInMvdW5rbm93bi8kdmVuZG9yLyJgCisJCTs7
Citlc2FjCisKK2VjaG8gJGJhc2ljX21hY2hpbmUkb3MKK2V4aXQKKworIyBMb2NhbCB2YXJpYWJs
ZXM6CisjIGV2YWw6IChhZGQtaG9vayAnd3JpdGUtZmlsZS1ob29rcyAndGltZS1zdGFtcCkKKyMg
dGltZS1zdGFtcC1zdGFydDogInRpbWVzdGFtcD0nIgorIyB0aW1lLXN0YW1wLWZvcm1hdDogIiU6
eS0lMDJtLSUwMmQiCisjIHRpbWUtc3RhbXAtZW5kOiAiJyIKKyMgRW5kOgpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY29uZmlndXJlCi0tLSAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZQlUdWUgSmFu
IDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMDE4MSBAQAorIyEgL2Jpbi9zaAor
IyBHdWVzcyB2YWx1ZXMgZm9yIHN5c3RlbS1kZXBlbmRlbnQgdmFyaWFibGVzIGFuZCBjcmVhdGUg
TWFrZWZpbGVzLgorIyBHZW5lcmF0ZWQgYnkgR05VIEF1dG9jb25mIDIuNjggZm9yIFhlbiBIeXBl
cnZpc29yIDQuMi4KKyMKKyMgUmVwb3J0IGJ1Z3MgdG8gPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tPi4KKyMKKyMKKyMgQ29weXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAx
OTk2LCAxOTk4LCAxOTk5LCAyMDAwLCAyMDAxLAorIyAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAy
MDA2LCAyMDA3LCAyMDA4LCAyMDA5LCAyMDEwIEZyZWUgU29mdHdhcmUKKyMgRm91bmRhdGlvbiwg
SW5jLgorIworIworIyBUaGlzIGNvbmZpZ3VyZSBzY3JpcHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhl
IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbgorIyBnaXZlcyB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0
byBjb3B5LCBkaXN0cmlidXRlIGFuZCBtb2RpZnkgaXQuCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LSAjIworIyMgTTRzaCBJbml0aWFsaXphdGlvbi4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0t
ICMjCisKKyMgQmUgbW9yZSBCb3VybmUgY29tcGF0aWJsZQorRFVBTENBU0U9MTsgZXhwb3J0IERV
QUxDQVNFICMgZm9yIE1LUyBzaAoraWYgdGVzdCAtbiAiJHtaU0hfVkVSU0lPTitzZXR9IiAmJiAo
ZW11bGF0ZSBzaCkgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxM
Q01EPToKKyAgIyBQcmUtNC4yIHZlcnNpb25zIG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiAk
ezErIiRAIn0sIHdoaWNoCisgICMgaXMgY29udHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0
aGlzIGZlYXR1cmUuCisgIGFsaWFzIC1nICckezErIiRAIn0nPSciJEAiJworICBzZXRvcHQgTk9f
R0xPQl9TVUJTVAorZWxzZQorICBjYXNlIGAoc2V0IC1vKSAyPi9kZXYvbnVsbGAgaW4gIygKKyAg
KnBvc2l4KikgOgorICAgIHNldCAtbyBwb3NpeCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2Fj
CitmaQorCisKK2FzX25sPScKKycKK2V4cG9ydCBhc19ubAorIyBQcmludGluZyBhIGxvbmcgc3Ry
aW5nIGNyYXNoZXMgU29sYXJpcyA3IC91c3IvYmluL3ByaW50Zi4KK2FzX2VjaG89J1xcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFwnCithc19lY2hvPSRhc19lY2hv
JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8KK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNo
byRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvCisjIFByZWZlciBhIGtzaCBzaGVsbCBi
dWlsdGluIG92ZXIgYW4gZXh0ZXJuYWwgcHJpbnRmIHByb2dyYW0gb24gU29sYXJpcywKKyMgYnV0
IHdpdGhvdXQgd2FzdGluZyBmb3JrcyBmb3IgYmFzaCBvciB6c2guCitpZiB0ZXN0IC16ICIkQkFT
SF9WRVJTSU9OJFpTSF9WRVJTSU9OIiBcCisgICAgJiYgKHRlc3QgIlhgcHJpbnQgLXIgLS0gJGFz
X2VjaG9gIiA9ICJYJGFzX2VjaG8iKSAyPi9kZXYvbnVsbDsgdGhlbgorICBhc19lY2hvPSdwcmlu
dCAtciAtLScKKyAgYXNfZWNob19uPSdwcmludCAtcm4gLS0nCitlbGlmICh0ZXN0ICJYYHByaW50
ZiAlcyAkYXNfZWNob2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2Vj
aG89J3ByaW50ZiAlc1xuJworICBhc19lY2hvX249J3ByaW50ZiAlcycKK2Vsc2UKKyAgaWYgdGVz
dCAiWGAoL3Vzci91Y2IvZWNobyAtbiAtbiAkYXNfZWNobykgMj4vZGV2L251bGxgIiA9ICJYLW4g
JGFzX2VjaG8iOyB0aGVuCisgICAgYXNfZWNob19ib2R5PSdldmFsIC91c3IvdWNiL2VjaG8gLW4g
IiQxJGFzX25sIicKKyAgICBhc19lY2hvX249Jy91c3IvdWNiL2VjaG8gLW4nCisgIGVsc2UKKyAg
ICBhc19lY2hvX2JvZHk9J2V2YWwgZXhwciAiWCQxIiA6ICJYXFwoLipcXCkiJworICAgIGFzX2Vj
aG9fbl9ib2R5PSdldmFsCisgICAgICBhcmc9JDE7CisgICAgICBjYXNlICRhcmcgaW4gIygKKyAg
ICAgICoiJGFzX25sIiopCisJZXhwciAiWCRhcmciIDogIlhcXCguKlxcKSRhc19ubCI7CisJYXJn
PWBleHByICJYJGFyZyIgOiAiLiokYXNfbmxcXCguKlxcKSJgOzsKKyAgICAgIGVzYWM7CisgICAg
ICBleHByICJYJGFyZyIgOiAiWFxcKC4qXFwpIiB8IHRyIC1kICIkYXNfbmwiCisgICAgJworICAg
IGV4cG9ydCBhc19lY2hvX25fYm9keQorICAgIGFzX2VjaG9fbj0nc2ggLWMgJGFzX2VjaG9fbl9i
b2R5IGFzX2VjaG8nCisgIGZpCisgIGV4cG9ydCBhc19lY2hvX2JvZHkKKyAgYXNfZWNobz0nc2gg
LWMgJGFzX2VjaG9fYm9keSBhc19lY2hvJworZmkKKworIyBUaGUgdXNlciBpcyBhbHdheXMgcmln
aHQuCitpZiB0ZXN0ICIke1BBVEhfU0VQQVJBVE9SK3NldH0iICE9IHNldDsgdGhlbgorICBQQVRI
X1NFUEFSQVRPUj06CisgIChQQVRIPScvYmluOy9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikg
Pi9kZXYvbnVsbCAyPiYxICYmIHsKKyAgICAoUEFUSD0nL2JpbjovYmluJzsgRlBBVEg9JFBBVEg7
IHNoIC1jIDopID4vZGV2L251bGwgMj4mMSB8fAorICAgICAgUEFUSF9TRVBBUkFUT1I9JzsnCisg
IH0KK2ZpCisKKworIyBJRlMKKyMgV2UgbmVlZCBzcGFjZSwgdGFiIGFuZCBuZXcgbGluZSwgaW4g
cHJlY2lzZWx5IHRoYXQgb3JkZXIuICBRdW90aW5nIGlzCisjIHRoZXJlIHRvIHByZXZlbnQgZWRp
dG9ycyBmcm9tIGNvbXBsYWluaW5nIGFib3V0IHNwYWNlLXRhYi4KKyMgKElmIF9BU19QQVRIX1dB
TEsgd2VyZSBjYWxsZWQgd2l0aCBJRlMgdW5zZXQsIGl0IHdvdWxkIGRpc2FibGUgd29yZAorIyBz
cGxpdHRpbmcgYnkgc2V0dGluZyBJRlMgdG8gZW1wdHkgdmFsdWUuKQorSUZTPSIgIiIJJGFzX25s
IgorCisjIEZpbmQgd2hvIHdlIGFyZS4gIExvb2sgaW4gdGhlIHBhdGggaWYgd2UgY29udGFpbiBu
byBkaXJlY3Rvcnkgc2VwYXJhdG9yLgorYXNfbXlzZWxmPQorY2FzZSAkMCBpbiAjKCgKKyAgKltc
XC9dKiApIGFzX215c2VsZj0kMCA7OworICAqKSBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgdGVzdCAtciAiJGFzX2Rpci8kMCIg
JiYgYXNfbXlzZWxmPSRhc19kaXIvJDAgJiYgYnJlYWsKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCisgICAgIDs7Citlc2FjCisjIFdlIGRpZCBub3QgZmluZCBvdXJzZWx2ZXMsIG1vc3QgcHJv
YmFibHkgd2Ugd2VyZSBydW4gYXMgYHNoIENPTU1BTkQnCisjIGluIHdoaWNoIGNhc2Ugd2UgYXJl
IG5vdCB0byBiZSBmb3VuZCBpbiB0aGUgcGF0aC4KK2lmIHRlc3QgIngkYXNfbXlzZWxmIiA9IHg7
IHRoZW4KKyAgYXNfbXlzZWxmPSQwCitmaQoraWYgdGVzdCAhIC1mICIkYXNfbXlzZWxmIjsgdGhl
bgorICAkYXNfZWNobyAiJGFzX215c2VsZjogZXJyb3I6IGNhbm5vdCBmaW5kIG15c2VsZjsgcmVy
dW4gd2l0aCBhbiBhYnNvbHV0ZSBmaWxlIG5hbWUiID4mMgorICBleGl0IDEKK2ZpCisKKyMgVW5z
ZXQgdmFyaWFibGVzIHRoYXQgd2UgZG8gbm90IG5lZWQgYW5kIHdoaWNoIGNhdXNlIGJ1Z3MgKGUu
Zy4gaW4KKyMgcHJlLTMuMCBVV0lOIGtzaCkuICBCdXQgZG8gbm90IGNhdXNlIGJ1Z3MgaW4gYmFz
aCAyLjAxOyB0aGUgInx8IGV4aXQgMSIKKyMgc3VwcHJlc3NlcyBhbnkgIlNlZ21lbnRhdGlvbiBm
YXVsdCIgbWVzc2FnZSB0aGVyZS4gICcoKCcgY291bGQKKyMgdHJpZ2dlciBhIGJ1ZyBpbiBwZGtz
aCA1LjIuMTQuCitmb3IgYXNfdmFyIGluIEJBU0hfRU5WIEVOViBNQUlMIE1BSUxQQVRICitkbyBl
dmFsIHRlc3QgeFwkeyRhc192YXIrc2V0fSA9IHhzZXQgXAorICAmJiAoICh1bnNldCAkYXNfdmFy
KSB8fCBleGl0IDEpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCAkYXNfdmFyIHx8IDoKK2RvbmUK
K1BTMT0nJCAnCitQUzI9Jz4gJworUFM0PScrICcKKworIyBOTFMgbnVpc2FuY2VzLgorTENfQUxM
PUMKK2V4cG9ydCBMQ19BTEwKK0xBTkdVQUdFPUMKK2V4cG9ydCBMQU5HVUFHRQorCisjIENEUEFU
SC4KKyh1bnNldCBDRFBBVEgpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCBDRFBBVEgKKworaWYg
dGVzdCAieCRDT05GSUdfU0hFTEwiID0geDsgdGhlbgorICBhc19ib3VybmVfY29tcGF0aWJsZT0i
aWYgdGVzdCAtbiBcIlwke1pTSF9WRVJTSU9OK3NldH1cIiAmJiAoZW11bGF0ZSBzaCkgPi9kZXYv
bnVsbCAyPiYxOyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxMQ01EPToKKyAgIyBQcmUtNC4y
IHZlcnNpb25zIG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiBcJHsxK1wiXCRAXCJ9LCB3aGlj
aAorICAjIGlzIGNvbnRyYXJ5IHRvIG91ciB1c2FnZS4gIERpc2FibGUgdGhpcyBmZWF0dXJlLgor
ICBhbGlhcyAtZyAnXCR7MStcIlwkQFwifSc9J1wiXCRAXCInCisgIHNldG9wdCBOT19HTE9CX1NV
QlNUCitlbHNlCisgIGNhc2UgXGAoc2V0IC1vKSAyPi9kZXYvbnVsbFxgIGluICMoCisgICpwb3Np
eCopIDoKKyAgICBzZXQgLW8gcG9zaXggOzsgIygKKyAgKikgOgorICAgICA7OworZXNhYworZmkK
KyIKKyAgYXNfcmVxdWlyZWQ9ImFzX2ZuX3JldHVybiAoKSB7IChleGl0IFwkMSk7IH0KK2FzX2Zu
X3N1Y2Nlc3MgKCkgeyBhc19mbl9yZXR1cm4gMDsgfQorYXNfZm5fZmFpbHVyZSAoKSB7IGFzX2Zu
X3JldHVybiAxOyB9Cithc19mbl9yZXRfc3VjY2VzcyAoKSB7IHJldHVybiAwOyB9Cithc19mbl9y
ZXRfZmFpbHVyZSAoKSB7IHJldHVybiAxOyB9CisKK2V4aXRjb2RlPTAKK2FzX2ZuX3N1Y2Nlc3Mg
fHwgeyBleGl0Y29kZT0xOyBlY2hvIGFzX2ZuX3N1Y2Nlc3MgZmFpbGVkLjsgfQorYXNfZm5fZmFp
bHVyZSAmJiB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fZmFpbHVyZSBzdWNjZWVkZWQuOyB9Cith
c19mbl9yZXRfc3VjY2VzcyB8fCB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fcmV0X3N1Y2Nlc3Mg
ZmFpbGVkLjsgfQorYXNfZm5fcmV0X2ZhaWx1cmUgJiYgeyBleGl0Y29kZT0xOyBlY2hvIGFzX2Zu
X3JldF9mYWlsdXJlIHN1Y2NlZWRlZC47IH0KK2lmICggc2V0IHg7IGFzX2ZuX3JldF9zdWNjZXNz
IHkgJiYgdGVzdCB4ID0gXCJcJDFcIiApOyB0aGVuIDoKKworZWxzZQorICBleGl0Y29kZT0xOyBl
Y2hvIHBvc2l0aW9uYWwgcGFyYW1ldGVycyB3ZXJlIG5vdCBzYXZlZC4KK2ZpCit0ZXN0IHhcJGV4
aXRjb2RlID0geDAgfHwgZXhpdCAxIgorICBhc19zdWdnZXN0ZWQ9IiAgYXNfbGluZW5vXzE9Ijth
c19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCRMSU5FTk87YXNfc3VnZ2VzdGVkPSRhc19zdWdnZXN0
ZWQiIGFzX2xpbmVub18xYT1cJExJTkVOTworICBhc19saW5lbm9fMj0iO2FzX3N1Z2dlc3RlZD0k
YXNfc3VnZ2VzdGVkJExJTkVOTzthc19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCIgYXNfbGluZW5v
XzJhPVwkTElORU5PCisgIGV2YWwgJ3Rlc3QgXCJ4XCRhc19saW5lbm9fMSdcJGFzX3J1bidcIiAh
PSBcInhcJGFzX2xpbmVub18yJ1wkYXNfcnVuJ1wiICYmCisgIHRlc3QgXCJ4XGBleHByIFwkYXNf
bGluZW5vXzEnXCRhc19ydW4nICsgMVxgXCIgPSBcInhcJGFzX2xpbmVub18yJ1wkYXNfcnVuJ1wi
JyB8fCBleGl0IDEKK3Rlc3QgXCQoKCAxICsgMSApKSA9IDIgfHwgZXhpdCAxIgorICBpZiAoZXZh
bCAiJGFzX3JlcXVpcmVkIikgMj4vZGV2L251bGw7IHRoZW4gOgorICBhc19oYXZlX3JlcXVpcmVk
PXllcworZWxzZQorICBhc19oYXZlX3JlcXVpcmVkPW5vCitmaQorICBpZiB0ZXN0IHgkYXNfaGF2
ZV9yZXF1aXJlZCA9IHh5ZXMgJiYgKGV2YWwgIiRhc19zdWdnZXN0ZWQiKSAyPi9kZXYvbnVsbDsg
dGhlbiA6CisKK2Vsc2UKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgor
YXNfZm91bmQ9ZmFsc2UKK2ZvciBhc19kaXIgaW4gL2JpbiRQQVRIX1NFUEFSQVRPUi91c3IvYmlu
JFBBVEhfU0VQQVJBVE9SJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgYXNfZm91bmQ9OgorICBjYXNlICRhc19kaXIgaW4gIygK
KwkgLyopCisJICAgZm9yIGFzX2Jhc2UgaW4gc2ggYmFzaCBrc2ggc2g1OyBkbworCSAgICAgIyBU
cnkgb25seSBzaGVsbHMgdGhhdCBleGlzdCwgdG8gc2F2ZSBzZXZlcmFsIGZvcmtzLgorCSAgICAg
YXNfc2hlbGw9JGFzX2Rpci8kYXNfYmFzZQorCSAgICAgaWYgeyB0ZXN0IC1mICIkYXNfc2hlbGwi
IHx8IHRlc3QgLWYgIiRhc19zaGVsbC5leGUiOyB9ICYmCisJCSAgICB7ICRhc19lY2hvICIkYXNf
Ym91cm5lX2NvbXBhdGlibGUiIiRhc19yZXF1aXJlZCIgfCBhc19ydW49YSAiJGFzX3NoZWxsIjsg
fSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIENPTkZJR19TSEVMTD0kYXNfc2hlbGwgYXNfaGF2ZV9y
ZXF1aXJlZD15ZXMKKwkJICAgaWYgeyAkYXNfZWNobyAiJGFzX2JvdXJuZV9jb21wYXRpYmxlIiIk
YXNfc3VnZ2VzdGVkIiB8IGFzX3J1bj1hICIkYXNfc2hlbGwiOyB9IDI+L2Rldi9udWxsOyB0aGVu
IDoKKyAgYnJlYWsgMgorZmkKK2ZpCisJICAgZG9uZTs7CisgICAgICAgZXNhYworICBhc19mb3Vu
ZD1mYWxzZQorZG9uZQorJGFzX2ZvdW5kIHx8IHsgaWYgeyB0ZXN0IC1mICIkU0hFTEwiIHx8IHRl
c3QgLWYgIiRTSEVMTC5leGUiOyB9ICYmCisJICAgICAgeyAkYXNfZWNobyAiJGFzX2JvdXJuZV9j
b21wYXRpYmxlIiIkYXNfcmVxdWlyZWQiIHwgYXNfcnVuPWEgIiRTSEVMTCI7IH0gMj4vZGV2L251
bGw7IHRoZW4gOgorICBDT05GSUdfU0hFTEw9JFNIRUxMIGFzX2hhdmVfcmVxdWlyZWQ9eWVzCitm
aTsgfQorSUZTPSRhc19zYXZlX0lGUworCisKKyAgICAgIGlmIHRlc3QgIngkQ09ORklHX1NIRUxM
IiAhPSB4OyB0aGVuIDoKKyAgIyBXZSBjYW5ub3QgeWV0IGFzc3VtZSBhIGRlY2VudCBzaGVsbCwg
c28gd2UgaGF2ZSB0byBwcm92aWRlIGEKKwkjIG5ldXRyYWxpemF0aW9uIHZhbHVlIGZvciBzaGVs
bHMgd2l0aG91dCB1bnNldDsgYW5kIHRoaXMgYWxzbworCSMgd29ya3MgYXJvdW5kIHNoZWxscyB0
aGF0IGNhbm5vdCB1bnNldCBub25leGlzdGVudCB2YXJpYWJsZXMuCisJIyBQcmVzZXJ2ZSAtdiBh
bmQgLXggdG8gdGhlIHJlcGxhY2VtZW50IHNoZWxsLgorCUJBU0hfRU5WPS9kZXYvbnVsbAorCUVO
Vj0vZGV2L251bGwKKwkodW5zZXQgQkFTSF9FTlYpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCBC
QVNIX0VOViBFTlYKKwlleHBvcnQgQ09ORklHX1NIRUxMCisJY2FzZSAkLSBpbiAjICgoKCgKKwkg
ICp2KngqIHwgKngqdiogKSBhc19vcHRzPS12eCA7OworCSAgKnYqICkgYXNfb3B0cz0tdiA7Owor
CSAgKngqICkgYXNfb3B0cz0teCA7OworCSAgKiApIGFzX29wdHM9IDs7CisJZXNhYworCWV4ZWMg
IiRDT05GSUdfU0hFTEwiICRhc19vcHRzICIkYXNfbXlzZWxmIiAkezErIiRAIn0KK2ZpCisKKyAg
ICBpZiB0ZXN0IHgkYXNfaGF2ZV9yZXF1aXJlZCA9IHhubzsgdGhlbiA6CisgICRhc19lY2hvICIk
MDogVGhpcyBzY3JpcHQgcmVxdWlyZXMgYSBzaGVsbCBtb3JlIG1vZGVybiB0aGFuIGFsbCIKKyAg
JGFzX2VjaG8gIiQwOiB0aGUgc2hlbGxzIHRoYXQgSSBmb3VuZCBvbiB5b3VyIHN5c3RlbS4iCisg
IGlmIHRlc3QgeCR7WlNIX1ZFUlNJT04rc2V0fSA9IHhzZXQgOyB0aGVuCisgICAgJGFzX2VjaG8g
IiQwOiBJbiBwYXJ0aWN1bGFyLCB6c2ggJFpTSF9WRVJTSU9OIGhhcyBidWdzIGFuZCBzaG91bGQi
CisgICAgJGFzX2VjaG8gIiQwOiBiZSB1cGdyYWRlZCB0byB6c2ggNC4zLjQgb3IgbGF0ZXIuIgor
ICBlbHNlCisgICAgJGFzX2VjaG8gIiQwOiBQbGVhc2UgdGVsbCBidWctYXV0b2NvbmZAZ251Lm9y
ZyBhbmQKKyQwOiB4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbSBhYm91dCB5b3VyIHN5c3Rl
bSwKKyQwOiBpbmNsdWRpbmcgYW55IGVycm9yIHBvc3NpYmx5IG91dHB1dCBiZWZvcmUgdGhpcwor
JDA6IG1lc3NhZ2UuIFRoZW4gaW5zdGFsbCBhIG1vZGVybiBzaGVsbCwgb3IgbWFudWFsbHkgcnVu
CiskMDogdGhlIHNjcmlwdCB1bmRlciBzdWNoIGEgc2hlbGwgaWYgeW91IGRvIGhhdmUgb25lLiIK
KyAgZmkKKyAgZXhpdCAxCitmaQorZmkKK2ZpCitTSEVMTD0ke0NPTkZJR19TSEVMTC0vYmluL3No
fQorZXhwb3J0IFNIRUxMCisjIFVuc2V0IG1vcmUgdmFyaWFibGVzIGtub3duIHRvIGludGVyZmVy
ZSB3aXRoIGJlaGF2aW9yIG9mIGNvbW1vbiB0b29scy4KK0NMSUNPTE9SX0ZPUkNFPSBHUkVQX09Q
VElPTlM9Cit1bnNldCBDTElDT0xPUl9GT1JDRSBHUkVQX09QVElPTlMKKworIyMgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tICMjCisjIyBNNHNoIFNoZWxsIEZ1bmN0aW9ucy4gIyMKKyMjIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAjIworIyBhc19mbl91bnNldCBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tCisj
IFBvcnRhYmx5IHVuc2V0IFZBUi4KK2FzX2ZuX3Vuc2V0ICgpCit7CisgIHsgZXZhbCAkMT07IHVu
c2V0ICQxO30KK30KK2FzX3Vuc2V0PWFzX2ZuX3Vuc2V0CisKKyMgYXNfZm5fc2V0X3N0YXR1cyBT
VEFUVVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgU2V0ICQ/IHRvIFNUQVRVUywgd2l0
aG91dCBmb3JraW5nLgorYXNfZm5fc2V0X3N0YXR1cyAoKQoreworICByZXR1cm4gJDEKK30gIyBh
c19mbl9zZXRfc3RhdHVzCisKKyMgYXNfZm5fZXhpdCBTVEFUVVMKKyMgLS0tLS0tLS0tLS0tLS0t
LS0KKyMgRXhpdCB0aGUgc2hlbGwgd2l0aCBTVEFUVVMsIGV2ZW4gaW4gYSAidHJhcCAwIiBvciAi
c2V0IC1lIiBjb250ZXh0LgorYXNfZm5fZXhpdCAoKQoreworICBzZXQgK2UKKyAgYXNfZm5fc2V0
X3N0YXR1cyAkMQorICBleGl0ICQxCit9ICMgYXNfZm5fZXhpdAorCisjIGFzX2ZuX21rZGlyX3AK
KyMgLS0tLS0tLS0tLS0tLQorIyBDcmVhdGUgIiRhc19kaXIiIGFzIGEgZGlyZWN0b3J5LCBpbmNs
dWRpbmcgcGFyZW50cyBpZiBuZWNlc3NhcnkuCithc19mbl9ta2Rpcl9wICgpCit7CisKKyAgY2Fz
ZSAkYXNfZGlyIGluICMoCisgIC0qKSBhc19kaXI9Li8kYXNfZGlyOzsKKyAgZXNhYworICB0ZXN0
IC1kICIkYXNfZGlyIiB8fCBldmFsICRhc19ta2Rpcl9wIHx8IHsKKyAgICBhc19kaXJzPQorICAg
IHdoaWxlIDo7IGRvCisgICAgICBjYXNlICRhc19kaXIgaW4gIygKKyAgICAgICpcJyopIGFzX3Fk
aXI9YCRhc19lY2hvICIkYXNfZGlyIiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYDs7ICMnKAor
ICAgICAgKikgYXNfcWRpcj0kYXNfZGlyOzsKKyAgICAgIGVzYWMKKyAgICAgIGFzX2RpcnM9Iick
YXNfcWRpcicgJGFzX2RpcnMiCisgICAgICBhc19kaXI9YCRhc19kaXJuYW1lIC0tICIkYXNfZGly
IiB8fAorJGFzX2V4cHIgWCIkYXNfZGlyIiA6ICdYXCguKlteL11cKS8vKlteL11bXi9dKi8qJCcg
XHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC8vXClbXi9dJyBcfCBcCisJIFgiJGFzX2RpciIgOiAn
WFwoLy9cKSQnIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvXCknIFx8IC4gMj4vZGV2L251bGwg
fHwKKyRhc19lY2hvIFgiJGFzX2RpciIgfAorICAgIHNlZCAnL15YXCguKlteL11cKVwvXC8qW14v
XVteL10qXC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXC9cKVte
L10uKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXC9cKSQveworCSAg
ICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wpLioveworCSAgICBzLy9cMS8KKwkg
ICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisgICAgICB0ZXN0IC1kICIkYXNfZGlyIiAmJiBi
cmVhaworICAgIGRvbmUKKyAgICB0ZXN0IC16ICIkYXNfZGlycyIgfHwgZXZhbCAibWtkaXIgJGFz
X2RpcnMiCisgIH0gfHwgdGVzdCAtZCAiJGFzX2RpciIgfHwgYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBjcmVhdGUgZGlyZWN0b3J5ICRhc19kaXIiCisKKworfSAjIGFzX2ZuX21rZGlyX3AKKyMgYXNf
Zm5fYXBwZW5kIFZBUiBWQUxVRQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIEFwcGVuZCB0
aGUgdGV4dCBpbiBWQUxVRSB0byB0aGUgZW5kIG9mIHRoZSBkZWZpbml0aW9uIGNvbnRhaW5lZCBp
biBWQVIuIFRha2UKKyMgYWR2YW50YWdlIG9mIGFueSBzaGVsbCBvcHRpbWl6YXRpb25zIHRoYXQg
YWxsb3cgYW1vcnRpemVkIGxpbmVhciBncm93dGggb3ZlcgorIyByZXBlYXRlZCBhcHBlbmRzLCBp
bnN0ZWFkIG9mIHRoZSB0eXBpY2FsIHF1YWRyYXRpYyBncm93dGggcHJlc2VudCBpbiBuYWl2ZQor
IyBpbXBsZW1lbnRhdGlvbnMuCitpZiAoZXZhbCAiYXNfdmFyPTE7IGFzX3Zhcis9MjsgdGVzdCB4
XCRhc192YXIgPSB4MTIiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGV2YWwgJ2FzX2ZuX2FwcGVu
ZCAoKQorICB7CisgICAgZXZhbCAkMSs9XCQyCisgIH0nCitlbHNlCisgIGFzX2ZuX2FwcGVuZCAo
KQorICB7CisgICAgZXZhbCAkMT1cJCQxXCQyCisgIH0KK2ZpICMgYXNfZm5fYXBwZW5kCisKKyMg
YXNfZm5fYXJpdGggQVJHLi4uCisjIC0tLS0tLS0tLS0tLS0tLS0tLQorIyBQZXJmb3JtIGFyaXRo
bWV0aWMgZXZhbHVhdGlvbiBvbiB0aGUgQVJHcywgYW5kIHN0b3JlIHRoZSByZXN1bHQgaW4gdGhl
CisjIGdsb2JhbCAkYXNfdmFsLiBUYWtlIGFkdmFudGFnZSBvZiBzaGVsbHMgdGhhdCBjYW4gYXZv
aWQgZm9ya3MuIFRoZSBhcmd1bWVudHMKKyMgbXVzdCBiZSBwb3J0YWJsZSBhY3Jvc3MgJCgoKSkg
YW5kIGV4cHIuCitpZiAoZXZhbCAidGVzdCBcJCgoIDEgKyAxICkpID0gMiIpIDI+L2Rldi9udWxs
OyB0aGVuIDoKKyAgZXZhbCAnYXNfZm5fYXJpdGggKCkKKyAgeworICAgIGFzX3ZhbD0kKCggJCog
KSkKKyAgfScKK2Vsc2UKKyAgYXNfZm5fYXJpdGggKCkKKyAgeworICAgIGFzX3ZhbD1gZXhwciAi
JEAiIHx8IHRlc3QgJD8gLWVxIDFgCisgIH0KK2ZpICMgYXNfZm5fYXJpdGgKKworCisjIGFzX2Zu
X2Vycm9yIFNUQVRVUyBFUlJPUiBbTElORU5PIExPR19GRF0KKyMgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBPdXRwdXQgImBiYXNlbmFtZSAkMGA6IGVycm9yOiBF
UlJPUiIgdG8gc3RkZXJyLiBJZiBMSU5FTk8gYW5kIExPR19GRCBhcmUKKyMgcHJvdmlkZWQsIGFs
c28gb3V0cHV0IHRoZSBlcnJvciB0byBMT0dfRkQsIHJlZmVyZW5jaW5nIExJTkVOTy4gVGhlbiBl
eGl0IHRoZQorIyBzY3JpcHQgd2l0aCBTVEFUVVMsIHVzaW5nIDEgaWYgdGhhdCB3YXMgMC4KK2Fz
X2ZuX2Vycm9yICgpCit7CisgIGFzX3N0YXR1cz0kMTsgdGVzdCAkYXNfc3RhdHVzIC1lcSAwICYm
IGFzX3N0YXR1cz0xCisgIGlmIHRlc3QgIiQ0IjsgdGhlbgorICAgIGFzX2xpbmVubz0ke2FzX2xp
bmVuby0iJDMifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3Rh
Y2sKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogJDIi
ID4mJDQKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6ICQyIiA+JjIKKyAgYXNfZm5f
ZXhpdCAkYXNfc3RhdHVzCit9ICMgYXNfZm5fZXJyb3IKKworaWYgZXhwciBhIDogJ1woYVwpJyA+
L2Rldi9udWxsIDI+JjEgJiYKKyAgIHRlc3QgIlhgZXhwciAwMDAwMSA6ICcuKlwoLi4uXCknYCIg
PSBYMDAxOyB0aGVuCisgIGFzX2V4cHI9ZXhwcgorZWxzZQorICBhc19leHByPWZhbHNlCitmaQor
CitpZiAoYmFzZW5hbWUgLS0gLykgPi9kZXYvbnVsbCAyPiYxICYmIHRlc3QgIlhgYmFzZW5hbWUg
LS0gLyAyPiYxYCIgPSAiWC8iOyB0aGVuCisgIGFzX2Jhc2VuYW1lPWJhc2VuYW1lCitlbHNlCisg
IGFzX2Jhc2VuYW1lPWZhbHNlCitmaQorCitpZiAoYXNfZGlyPWBkaXJuYW1lIC0tIC9gICYmIHRl
c3QgIlgkYXNfZGlyIiA9IFgvKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfZGlybmFtZT1k
aXJuYW1lCitlbHNlCisgIGFzX2Rpcm5hbWU9ZmFsc2UKK2ZpCisKK2FzX21lPWAkYXNfYmFzZW5h
bWUgLS0gIiQwIiB8fAorJGFzX2V4cHIgWC8iJDAiIDogJy4qL1woW14vXVteL10qXCkvKiQnIFx8
IFwKKwkgWCIkMCIgOiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkMCIgOiAnWFwoL1wpJyBcfCAuIDI+
L2Rldi9udWxsIHx8CiskYXNfZWNobyBYLyIkMCIgfAorICAgIHNlZCAnL14uKlwvXChbXi9dW14v
XSpcKVwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXC9cKSQv
eworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXCkuKi97CisJICAgIHMv
L1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4vOyBxJ2AKKworIyBBdm9pZCBkZXBlbmRpbmcg
dXBvbiBDaGFyYWN0ZXIgUmFuZ2VzLgorYXNfY3JfbGV0dGVycz0nYWJjZGVmZ2hpamtsbW5vcHFy
c3R1dnd4eXonCithc19jcl9MRVRURVJTPSdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicKK2Fz
X2NyX0xldHRlcnM9JGFzX2NyX2xldHRlcnMkYXNfY3JfTEVUVEVSUworYXNfY3JfZGlnaXRzPScw
MTIzNDU2Nzg5JworYXNfY3JfYWxudW09JGFzX2NyX0xldHRlcnMkYXNfY3JfZGlnaXRzCisKKwor
ICBhc19saW5lbm9fMT0kTElORU5PIGFzX2xpbmVub18xYT0kTElORU5PCisgIGFzX2xpbmVub18y
PSRMSU5FTk8gYXNfbGluZW5vXzJhPSRMSU5FTk8KKyAgZXZhbCAndGVzdCAieCRhc19saW5lbm9f
MSckYXNfcnVuJyIgIT0gIngkYXNfbGluZW5vXzInJGFzX3J1biciICYmCisgIHRlc3QgInhgZXhw
ciAkYXNfbGluZW5vXzEnJGFzX3J1bicgKyAxYCIgPSAieCRhc19saW5lbm9fMickYXNfcnVuJyIn
IHx8IHsKKyAgIyBCbGFtZSBMZWUgRS4gTWNNYWhvbiAoMTkzMS0xOTg5KSBmb3Igc2VkJ3Mgc3lu
dGF4LiAgOi0pCisgIHNlZCAtbiAnCisgICAgcAorICAgIC9bJF1MSU5FTk8vPQorICAnIDwkYXNf
bXlzZWxmIHwKKyAgICBzZWQgJworICAgICAgcy9bJF1MSU5FTk8uKi8mLS8KKyAgICAgIHQgbGlu
ZW5vCisgICAgICBiCisgICAgICA6bGluZW5vCisgICAgICBOCisgICAgICA6bG9vcAorICAgICAg
cy9bJF1MSU5FTk9cKFteJyRhc19jcl9hbG51bSdfXS4qXG5cKVwoLipcKS9cMlwxXDIvCisgICAg
ICB0IGxvb3AKKyAgICAgIHMvLVxuLiovLworICAgICcgPiRhc19tZS5saW5lbm8gJiYKKyAgY2ht
b2QgK3ggIiRhc19tZS5saW5lbm8iIHx8CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiBlcnJvcjog
Y2Fubm90IGNyZWF0ZSAkYXNfbWUubGluZW5vOyByZXJ1biB3aXRoIGEgUE9TSVggc2hlbGwiID4m
MjsgYXNfZm5fZXhpdCAxOyB9CisKKyAgIyBEb24ndCB0cnkgdG8gZXhlYyBhcyBpdCBjaGFuZ2Vz
ICRbMF0sIGNhdXNpbmcgYWxsIHNvcnQgb2YgcHJvYmxlbXMKKyAgIyAodGhlIGRpcm5hbWUgb2Yg
JFswXSBpcyBub3QgdGhlIHBsYWNlIHdoZXJlIHdlIG1pZ2h0IGZpbmQgdGhlCisgICMgb3JpZ2lu
YWwgYW5kIHNvIG9uLiAgQXV0b2NvbmYgaXMgZXNwZWNpYWxseSBzZW5zaXRpdmUgdG8gdGhpcyku
CisgIC4gIi4vJGFzX21lLmxpbmVubyIKKyAgIyBFeGl0IHN0YXR1cyBpcyB0aGF0IG9mIHRoZSBs
YXN0IGNvbW1hbmQuCisgIGV4aXQKK30KKworRUNIT19DPSBFQ0hPX049IEVDSE9fVD0KK2Nhc2Ug
YGVjaG8gLW4geGAgaW4gIygoKCgoCistbiopCisgIGNhc2UgYGVjaG8gJ3h5XGMnYCBpbgorICAq
YyopIEVDSE9fVD0nCSc7OwkjIEVDSE9fVCBpcyBzaW5nbGUgdGFiIGNoYXJhY3Rlci4KKyAgeHkp
ICBFQ0hPX0M9J1xjJzs7CisgICopICAgZWNobyBgZWNobyBrc2g4OCBidWcgb24gQUlYIDYuMWAg
PiAvZGV2L251bGwKKyAgICAgICBFQ0hPX1Q9JwknOzsKKyAgZXNhYzs7CisqKQorICBFQ0hPX049
Jy1uJzs7Citlc2FjCisKK3JtIC1mIGNvbmYkJCBjb25mJCQuZXhlIGNvbmYkJC5maWxlCitpZiB0
ZXN0IC1kIGNvbmYkJC5kaXI7IHRoZW4KKyAgcm0gLWYgY29uZiQkLmRpci9jb25mJCQuZmlsZQor
ZWxzZQorICBybSAtZiBjb25mJCQuZGlyCisgIG1rZGlyIGNvbmYkJC5kaXIgMj4vZGV2L251bGwK
K2ZpCitpZiAoZWNobyA+Y29uZiQkLmZpbGUpIDI+L2Rldi9udWxsOyB0aGVuCisgIGlmIGxuIC1z
IGNvbmYkJC5maWxlIGNvbmYkJCAyPi9kZXYvbnVsbDsgdGhlbgorICAgIGFzX2xuX3M9J2xuIC1z
JworICAgICMgLi4uIGJ1dCB0aGVyZSBhcmUgdHdvIGdvdGNoYXM6CisgICAgIyAxKSBPbiBNU1lT
LCBib3RoIGBsbiAtcyBmaWxlIGRpcicgYW5kIGBsbiBmaWxlIGRpcicgZmFpbC4KKyAgICAjIDIp
IERKR1BQIDwgMi4wNCBoYXMgbm8gc3ltbGlua3M7IGBsbiAtcycgY3JlYXRlcyBhIHdyYXBwZXIg
ZXhlY3V0YWJsZS4KKyAgICAjIEluIGJvdGggY2FzZXMsIHdlIGhhdmUgdG8gZGVmYXVsdCB0byBg
Y3AgLXAnLgorICAgIGxuIC1zIGNvbmYkJC5maWxlIGNvbmYkJC5kaXIgMj4vZGV2L251bGwgJiYg
dGVzdCAhIC1mIGNvbmYkJC5leGUgfHwKKyAgICAgIGFzX2xuX3M9J2NwIC1wJworICBlbGlmIGxu
IGNvbmYkJC5maWxlIGNvbmYkJCAyPi9kZXYvbnVsbDsgdGhlbgorICAgIGFzX2xuX3M9bG4KKyAg
ZWxzZQorICAgIGFzX2xuX3M9J2NwIC1wJworICBmaQorZWxzZQorICBhc19sbl9zPSdjcCAtcCcK
K2ZpCitybSAtZiBjb25mJCQgY29uZiQkLmV4ZSBjb25mJCQuZGlyL2NvbmYkJC5maWxlIGNvbmYk
JC5maWxlCitybWRpciBjb25mJCQuZGlyIDI+L2Rldi9udWxsCisKK2lmIG1rZGlyIC1wIC4gMj4v
ZGV2L251bGw7IHRoZW4KKyAgYXNfbWtkaXJfcD0nbWtkaXIgLXAgIiRhc19kaXIiJworZWxzZQor
ICB0ZXN0IC1kIC4vLXAgJiYgcm1kaXIgLi8tcAorICBhc19ta2Rpcl9wPWZhbHNlCitmaQorCitp
ZiB0ZXN0IC14IC8gPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgIGFzX3Rlc3RfeD0ndGVzdCAteCcK
K2Vsc2UKKyAgaWYgbHMgLWRMIC8gPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgICAgYXNfbHNfTF9v
cHRpb249TAorICBlbHNlCisgICAgYXNfbHNfTF9vcHRpb249CisgIGZpCisgIGFzX3Rlc3RfeD0n
CisgICAgZXZhbCBzaCAtYyAnXCcnCisgICAgICBpZiB0ZXN0IC1kICIkMSI7IHRoZW4KKwl0ZXN0
IC1kICIkMS8uIjsKKyAgICAgIGVsc2UKKwljYXNlICQxIGluICMoCisJLSopc2V0ICIuLyQxIjs7
CisJZXNhYzsKKwljYXNlIGBscyAtbGQnJGFzX2xzX0xfb3B0aW9uJyAiJDEiIDI+L2Rldi9udWxs
YCBpbiAjKCgKKwk/Pz9bc3hdKik6OzsqKWZhbHNlOztlc2FjO2ZpCisgICAgJ1wnJyBzaAorICAn
CitmaQorYXNfZXhlY3V0YWJsZV9wPSRhc190ZXN0X3gKKworIyBTZWQgZXhwcmVzc2lvbiB0byBt
YXAgYSBzdHJpbmcgb250byBhIHZhbGlkIENQUCBuYW1lLgorYXNfdHJfY3BwPSJldmFsIHNlZCAn
eSUqJGFzX2NyX2xldHRlcnMlUCRhc19jcl9MRVRURVJTJTtzJVteXyRhc19jcl9hbG51bV0lXyVn
JyIKKworIyBTZWQgZXhwcmVzc2lvbiB0byBtYXAgYSBzdHJpbmcgb250byBhIHZhbGlkIHZhcmlh
YmxlIG5hbWUuCithc190cl9zaD0iZXZhbCBzZWQgJ3klKislcHAlO3MlW15fJGFzX2NyX2FsbnVt
XSVfJWcnIgorCisKK3Rlc3QgLW4gIiRESkRJUiIgfHwgZXhlYyA3PCYwIDwvZGV2L251bGwKK2V4
ZWMgNj4mMQorCisjIE5hbWUgb2YgdGhlIGhvc3QuCisjIGhvc3RuYW1lIG9uIHNvbWUgc3lzdGVt
cyAoU1ZSMy4yLCBvbGQgR05VL0xpbnV4KSByZXR1cm5zIGEgYm9ndXMgZXhpdCBzdGF0dXMsCisj
IHNvIHVuYW1lIGdldHMgcnVuIHRvby4KK2FjX2hvc3RuYW1lPWAoaG9zdG5hbWUgfHwgdW5hbWUg
LW4pIDI+L2Rldi9udWxsIHwgc2VkIDFxYAorCisjCisjIEluaXRpYWxpemF0aW9ucy4KKyMKK2Fj
X2RlZmF1bHRfcHJlZml4PS91c3IvbG9jYWwKK2FjX2NsZWFuX2ZpbGVzPQorYWNfY29uZmlnX2xp
Ym9ial9kaXI9LgorTElCT0JKUz0KK2Nyb3NzX2NvbXBpbGluZz1ubworc3ViZGlycz0KK01GTEFH
Uz0KK01BS0VGTEFHUz0KKworIyBJZGVudGl0eSBvZiB0aGlzIHBhY2thZ2UuCitQQUNLQUdFX05B
TUU9J1hlbiBIeXBlcnZpc29yJworUEFDS0FHRV9UQVJOQU1FPSd4ZW4taHlwZXJ2aXNvcicKK1BB
Q0tBR0VfVkVSU0lPTj0nNC4yJworUEFDS0FHRV9TVFJJTkc9J1hlbiBIeXBlcnZpc29yIDQuMicK
K1BBQ0tBR0VfQlVHUkVQT1JUPSd4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbScKK1BBQ0tB
R0VfVVJMPScnCisKK2FjX3VuaXF1ZV9maWxlPSJsaWJ4bC9saWJ4bC5jIgorYWNfZGVmYXVsdF9w
cmVmaXg9L3VzcgorIyBGYWN0b3JpbmcgZGVmYXVsdCBoZWFkZXJzIGZvciBtb3N0IHRlc3RzLgor
YWNfaW5jbHVkZXNfZGVmYXVsdD0iXAorI2luY2x1ZGUgPHN0ZGlvLmg+CisjaWZkZWYgSEFWRV9T
WVNfVFlQRVNfSAorIyBpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVf
U1lTX1NUQVRfSAorIyBpbmNsdWRlIDxzeXMvc3RhdC5oPgorI2VuZGlmCisjaWZkZWYgU1REQ19I
RUFERVJTCisjIGluY2x1ZGUgPHN0ZGxpYi5oPgorIyBpbmNsdWRlIDxzdGRkZWYuaD4KKyNlbHNl
CisjIGlmZGVmIEhBVkVfU1RETElCX0gKKyMgIGluY2x1ZGUgPHN0ZGxpYi5oPgorIyBlbmRpZgor
I2VuZGlmCisjaWZkZWYgSEFWRV9TVFJJTkdfSAorIyBpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMg
JiYgZGVmaW5lZCBIQVZFX01FTU9SWV9ICisjICBpbmNsdWRlIDxtZW1vcnkuaD4KKyMgZW5kaWYK
KyMgaW5jbHVkZSA8c3RyaW5nLmg+CisjZW5kaWYKKyNpZmRlZiBIQVZFX1NUUklOR1NfSAorIyBp
bmNsdWRlIDxzdHJpbmdzLmg+CisjZW5kaWYKKyNpZmRlZiBIQVZFX0lOVFRZUEVTX0gKKyMgaW5j
bHVkZSA8aW50dHlwZXMuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfU1RESU5UX0gKKyMgaW5jbHVk
ZSA8c3RkaW50Lmg+CisjZW5kaWYKKyNpZmRlZiBIQVZFX1VOSVNURF9ICisjIGluY2x1ZGUgPHVu
aXN0ZC5oPgorI2VuZGlmIgorCithY19oZWFkZXJfbGlzdD0KK2FjX2Z1bmNfbGlzdD0KK2FjX3N1
YnN0X3ZhcnM9J0xUTElCT0JKUworUE9XX0xJQgorTElCT0JKUworQUxMT0NBCitsaWJpY29udgor
bGliZ2NyeXB0CitsaWJleHQyZnMKK3N5c3RlbV9haW8KK0xJQl9QQVRICitWTkNPTkZJRworSE9U
UExVRworVURFVklORk8KK1VERVZBRE0KK1BZVEhPTlBBVEgKK09DQU1MQlVJTEQKK09DQU1MRE9D
CitPQ0FNTE1LTElCCitPQ0FNTE1LVE9QCitPQ0FNTERFUAorT0NBTUwKK09DQU1MT1BURE9UT1BU
CitPQ0FNTENET1RPUFQKK09DQU1MQkVTVAorT0NBTUxPUFQKK09DQU1MTElCCitPQ0FNTFZFUlNJ
T04KK09DQU1MQworSU5TVEFMTF9EQVRBCitJTlNUQUxMX1NDUklQVAorSU5TVEFMTF9QUk9HUkFN
CitTRVRfTUFLRQorTE5fUworU0VECitYR0VUVEVYVAorQkFTSAorWE1MCitDVVJMCitGTEVYCitC
SVNPTgorSVAKK0JSQ1RMCitQRVJMCitQWVRIT04KK0FQUEVORF9MSUIKK0FQUEVORF9JTkNMVURF
UworUFJFUEVORF9MSUIKK1BSRVBFTkRfSU5DTFVERVMKK2RlYnVnCitsb21vdW50CittaW5pdGVy
bQorb2NhbWx0b29scworcHl0aG9udG9vbHMKK3hhcGkKK3Z0cG0KK21vbml0b3JzCitnaXRodHRw
Cit4c20KK2hvc3Rfb3MKK2hvc3RfdmVuZG9yCitob3N0X2NwdQoraG9zdAorYnVpbGRfb3MKK2J1
aWxkX3ZlbmRvcgorYnVpbGRfY3B1CitidWlsZAorRUdSRVAKK0dSRVAKK0NQUAorT0JKRVhUCitF
WEVFWFQKK2FjX2N0X0NDCitDUFBGTEFHUworTERGTEFHUworQ0ZMQUdTCitDQwordGFyZ2V0X2Fs
aWFzCitob3N0X2FsaWFzCitidWlsZF9hbGlhcworTElCUworRUNIT19UCitFQ0hPX04KK0VDSE9f
QworREVGUworbWFuZGlyCitsb2NhbGVkaXIKK2xpYmRpcgorcHNkaXIKK3BkZmRpcgorZHZpZGly
CitodG1sZGlyCitpbmZvZGlyCitkb2NkaXIKK29sZGluY2x1ZGVkaXIKK2luY2x1ZGVkaXIKK2xv
Y2Fsc3RhdGVkaXIKK3NoYXJlZHN0YXRlZGlyCitzeXNjb25mZGlyCitkYXRhZGlyCitkYXRhcm9v
dGRpcgorbGliZXhlY2Rpcgorc2JpbmRpcgorYmluZGlyCitwcm9ncmFtX3RyYW5zZm9ybV9uYW1l
CitwcmVmaXgKK2V4ZWNfcHJlZml4CitQQUNLQUdFX1VSTAorUEFDS0FHRV9CVUdSRVBPUlQKK1BB
Q0tBR0VfU1RSSU5HCitQQUNLQUdFX1ZFUlNJT04KK1BBQ0tBR0VfVEFSTkFNRQorUEFDS0FHRV9O
QU1FCitQQVRIX1NFUEFSQVRPUgorU0hFTEwnCithY19zdWJzdF9maWxlcz0nJworYWNfdXNlcl9v
cHRzPScKK2VuYWJsZV9vcHRpb25fY2hlY2tpbmcKK2VuYWJsZV94c20KK2VuYWJsZV9naXRodHRw
CitlbmFibGVfbW9uaXRvcnMKK2VuYWJsZV92dHBtCitlbmFibGVfeGFwaQorZW5hYmxlX3B5dGhv
bnRvb2xzCitlbmFibGVfb2NhbWx0b29scworZW5hYmxlX21pbml0ZXJtCitlbmFibGVfbG9tb3Vu
dAorZW5hYmxlX2RlYnVnCisnCisgICAgICBhY19wcmVjaW91c192YXJzPSdidWlsZF9hbGlhcwor
aG9zdF9hbGlhcwordGFyZ2V0X2FsaWFzCitDQworQ0ZMQUdTCitMREZMQUdTCitMSUJTCitDUFBG
TEFHUworQ1BQCitQUkVQRU5EX0lOQ0xVREVTCitQUkVQRU5EX0xJQgorQVBQRU5EX0lOQ0xVREVT
CitBUFBFTkRfTElCCitQWVRIT04KK1BFUkwKK0JSQ1RMCitJUAorQklTT04KK0ZMRVgKK0NVUkwK
K1hNTAorQkFTSAorWEdFVFRFWFQnCisKKworIyBJbml0aWFsaXplIHNvbWUgdmFyaWFibGVzIHNl
dCBieSBvcHRpb25zLgorYWNfaW5pdF9oZWxwPQorYWNfaW5pdF92ZXJzaW9uPWZhbHNlCithY191
bnJlY29nbml6ZWRfb3B0cz0KK2FjX3VucmVjb2duaXplZF9zZXA9CisjIFRoZSB2YXJpYWJsZXMg
aGF2ZSB0aGUgc2FtZSBuYW1lcyBhcyB0aGUgb3B0aW9ucywgd2l0aAorIyBkYXNoZXMgY2hhbmdl
ZCB0byB1bmRlcmxpbmVzLgorY2FjaGVfZmlsZT0vZGV2L251bGwKK2V4ZWNfcHJlZml4PU5PTkUK
K25vX2NyZWF0ZT0KK25vX3JlY3Vyc2lvbj0KK3ByZWZpeD1OT05FCitwcm9ncmFtX3ByZWZpeD1O
T05FCitwcm9ncmFtX3N1ZmZpeD1OT05FCitwcm9ncmFtX3RyYW5zZm9ybV9uYW1lPXMseCx4LAor
c2lsZW50PQorc2l0ZT0KK3NyY2Rpcj0KK3ZlcmJvc2U9Cit4X2luY2x1ZGVzPU5PTkUKK3hfbGli
cmFyaWVzPU5PTkUKKworIyBJbnN0YWxsYXRpb24gZGlyZWN0b3J5IG9wdGlvbnMuCisjIFRoZXNl
IGFyZSBsZWZ0IHVuZXhwYW5kZWQgc28gdXNlcnMgY2FuICJtYWtlIGluc3RhbGwgZXhlY19wcmVm
aXg9L2ZvbyIKKyMgYW5kIGFsbCB0aGUgdmFyaWFibGVzIHRoYXQgYXJlIHN1cHBvc2VkIHRvIGJl
IGJhc2VkIG9uIGV4ZWNfcHJlZml4CisjIGJ5IGRlZmF1bHQgd2lsbCBhY3R1YWxseSBjaGFuZ2Uu
CisjIFVzZSBicmFjZXMgaW5zdGVhZCBvZiBwYXJlbnMgYmVjYXVzZSBzaCwgcGVybCwgZXRjLiBh
bHNvIGFjY2VwdCB0aGVtLgorIyAoVGhlIGxpc3QgZm9sbG93cyB0aGUgc2FtZSBvcmRlciBhcyB0
aGUgR05VIENvZGluZyBTdGFuZGFyZHMuKQorYmluZGlyPScke2V4ZWNfcHJlZml4fS9iaW4nCitz
YmluZGlyPScke2V4ZWNfcHJlZml4fS9zYmluJworbGliZXhlY2Rpcj0nJHtleGVjX3ByZWZpeH0v
bGliZXhlYycKK2RhdGFyb290ZGlyPScke3ByZWZpeH0vc2hhcmUnCitkYXRhZGlyPScke2RhdGFy
b290ZGlyfScKK3N5c2NvbmZkaXI9JyR7cHJlZml4fS9ldGMnCitzaGFyZWRzdGF0ZWRpcj0nJHtw
cmVmaXh9L2NvbScKK2xvY2Fsc3RhdGVkaXI9JyR7cHJlZml4fS92YXInCitpbmNsdWRlZGlyPSck
e3ByZWZpeH0vaW5jbHVkZScKK29sZGluY2x1ZGVkaXI9Jy91c3IvaW5jbHVkZScKK2RvY2Rpcj0n
JHtkYXRhcm9vdGRpcn0vZG9jLyR7UEFDS0FHRV9UQVJOQU1FfScKK2luZm9kaXI9JyR7ZGF0YXJv
b3RkaXJ9L2luZm8nCitodG1sZGlyPScke2RvY2Rpcn0nCitkdmlkaXI9JyR7ZG9jZGlyfScKK3Bk
ZmRpcj0nJHtkb2NkaXJ9JworcHNkaXI9JyR7ZG9jZGlyfScKK2xpYmRpcj0nJHtleGVjX3ByZWZp
eH0vbGliJworbG9jYWxlZGlyPScke2RhdGFyb290ZGlyfS9sb2NhbGUnCittYW5kaXI9JyR7ZGF0
YXJvb3RkaXJ9L21hbicKKworYWNfcHJldj0KK2FjX2Rhc2hkYXNoPQorZm9yIGFjX29wdGlvbgor
ZG8KKyAgIyBJZiB0aGUgcHJldmlvdXMgb3B0aW9uIG5lZWRzIGFuIGFyZ3VtZW50LCBhc3NpZ24g
aXQuCisgIGlmIHRlc3QgLW4gIiRhY19wcmV2IjsgdGhlbgorICAgIGV2YWwgJGFjX3ByZXY9XCRh
Y19vcHRpb24KKyAgICBhY19wcmV2PQorICAgIGNvbnRpbnVlCisgIGZpCisKKyAgY2FzZSAkYWNf
b3B0aW9uIGluCisgICo9PyopIGFjX29wdGFyZz1gZXhwciAiWCRhY19vcHRpb24iIDogJ1tePV0q
PVwoLipcKSdgIDs7CisgICo9KSAgIGFjX29wdGFyZz0gOzsKKyAgKikgICAgYWNfb3B0YXJnPXll
cyA7OworICBlc2FjCisKKyAgIyBBY2NlcHQgdGhlIGltcG9ydGFudCBDeWdudXMgY29uZmlndXJl
IG9wdGlvbnMsIHNvIHdlIGNhbiBkaWFnbm9zZSB0eXBvcy4KKworICBjYXNlICRhY19kYXNoZGFz
aCRhY19vcHRpb24gaW4KKyAgLS0pCisgICAgYWNfZGFzaGRhc2g9eWVzIDs7CisKKyAgLWJpbmRp
ciB8IC0tYmluZGlyIHwgLS1iaW5kaSB8IC0tYmluZCB8IC0tYmluIHwgLS1iaSkKKyAgICBhY19w
cmV2PWJpbmRpciA7OworICAtYmluZGlyPSogfCAtLWJpbmRpcj0qIHwgLS1iaW5kaT0qIHwgLS1i
aW5kPSogfCAtLWJpbj0qIHwgLS1iaT0qKQorICAgIGJpbmRpcj0kYWNfb3B0YXJnIDs7CisKKyAg
LWJ1aWxkIHwgLS1idWlsZCB8IC0tYnVpbCB8IC0tYnVpIHwgLS1idSkKKyAgICBhY19wcmV2PWJ1
aWxkX2FsaWFzIDs7CisgIC1idWlsZD0qIHwgLS1idWlsZD0qIHwgLS1idWlsPSogfCAtLWJ1aT0q
IHwgLS1idT0qKQorICAgIGJ1aWxkX2FsaWFzPSRhY19vcHRhcmcgOzsKKworICAtY2FjaGUtZmls
ZSB8IC0tY2FjaGUtZmlsZSB8IC0tY2FjaGUtZmlsIHwgLS1jYWNoZS1maSBcCisgIHwgLS1jYWNo
ZS1mIHwgLS1jYWNoZS0gfCAtLWNhY2hlIHwgLS1jYWNoIHwgLS1jYWMgfCAtLWNhIHwgLS1jKQor
ICAgIGFjX3ByZXY9Y2FjaGVfZmlsZSA7OworICAtY2FjaGUtZmlsZT0qIHwgLS1jYWNoZS1maWxl
PSogfCAtLWNhY2hlLWZpbD0qIHwgLS1jYWNoZS1maT0qIFwKKyAgfCAtLWNhY2hlLWY9KiB8IC0t
Y2FjaGUtPSogfCAtLWNhY2hlPSogfCAtLWNhY2g9KiB8IC0tY2FjPSogfCAtLWNhPSogfCAtLWM9
KikKKyAgICBjYWNoZV9maWxlPSRhY19vcHRhcmcgOzsKKworICAtLWNvbmZpZy1jYWNoZSB8IC1D
KQorICAgIGNhY2hlX2ZpbGU9Y29uZmlnLmNhY2hlIDs7CisKKyAgLWRhdGFkaXIgfCAtLWRhdGFk
aXIgfCAtLWRhdGFkaSB8IC0tZGF0YWQpCisgICAgYWNfcHJldj1kYXRhZGlyIDs7CisgIC1kYXRh
ZGlyPSogfCAtLWRhdGFkaXI9KiB8IC0tZGF0YWRpPSogfCAtLWRhdGFkPSopCisgICAgZGF0YWRp
cj0kYWNfb3B0YXJnIDs7CisKKyAgLWRhdGFyb290ZGlyIHwgLS1kYXRhcm9vdGRpciB8IC0tZGF0
YXJvb3RkaSB8IC0tZGF0YXJvb3RkIHwgLS1kYXRhcm9vdCBcCisgIHwgLS1kYXRhcm9vIHwgLS1k
YXRhcm8gfCAtLWRhdGFyKQorICAgIGFjX3ByZXY9ZGF0YXJvb3RkaXIgOzsKKyAgLWRhdGFyb290
ZGlyPSogfCAtLWRhdGFyb290ZGlyPSogfCAtLWRhdGFyb290ZGk9KiB8IC0tZGF0YXJvb3RkPSog
XAorICB8IC0tZGF0YXJvb3Q9KiB8IC0tZGF0YXJvbz0qIHwgLS1kYXRhcm89KiB8IC0tZGF0YXI9
KikKKyAgICBkYXRhcm9vdGRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWRpc2FibGUtKiB8IC0tZGlz
YWJsZS0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4LSpkaXNhYmxl
LVwoLipcKSdgCisgICAgIyBSZWplY3QgbmFtZXMgdGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZh
cmlhYmxlIG5hbWVzLgorICAgIGV4cHIgIngkYWNfdXNlcm9wdCIgOiAiLipbXi0rLl8kYXNfY3Jf
YWxudW1dIiA+L2Rldi9udWxsICYmCisgICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCBmZWF0
dXJlIG5hbWU6ICRhY191c2Vyb3B0IgorICAgIGFjX3VzZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAor
ICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hvICIkYWNfdXNlcm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9n
J2AKKyAgICBjYXNlICRhY191c2VyX29wdHMgaW4KKyAgICAgICoiCisiZW5hYmxlXyRhY191c2Vy
b3B0IgorIiopIDs7CisgICAgICAqKSBhY191bnJlY29nbml6ZWRfb3B0cz0iJGFjX3VucmVjb2du
aXplZF9vcHRzJGFjX3VucmVjb2duaXplZF9zZXAtLWRpc2FibGUtJGFjX3VzZXJvcHRfb3JpZyIK
KwkgYWNfdW5yZWNvZ25pemVkX3NlcD0nLCAnOzsKKyAgICBlc2FjCisgICAgZXZhbCBlbmFibGVf
JGFjX3VzZXJvcHQ9bm8gOzsKKworICAtZG9jZGlyIHwgLS1kb2NkaXIgfCAtLWRvY2RpIHwgLS1k
b2MgfCAtLWRvKQorICAgIGFjX3ByZXY9ZG9jZGlyIDs7CisgIC1kb2NkaXI9KiB8IC0tZG9jZGly
PSogfCAtLWRvY2RpPSogfCAtLWRvYz0qIHwgLS1kbz0qKQorICAgIGRvY2Rpcj0kYWNfb3B0YXJn
IDs7CisKKyAgLWR2aWRpciB8IC0tZHZpZGlyIHwgLS1kdmlkaSB8IC0tZHZpZCB8IC0tZHZpIHwg
LS1kdikKKyAgICBhY19wcmV2PWR2aWRpciA7OworICAtZHZpZGlyPSogfCAtLWR2aWRpcj0qIHwg
LS1kdmlkaT0qIHwgLS1kdmlkPSogfCAtLWR2aT0qIHwgLS1kdj0qKQorICAgIGR2aWRpcj0kYWNf
b3B0YXJnIDs7CisKKyAgLWVuYWJsZS0qIHwgLS1lbmFibGUtKikKKyAgICBhY191c2Vyb3B0PWBl
eHByICJ4JGFjX29wdGlvbiIgOiAneC0qZW5hYmxlLVwoW149XSpcKSdgCisgICAgIyBSZWplY3Qg
bmFtZXMgdGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIg
IngkYWNfdXNlcm9wdCIgOiAiLipbXi0rLl8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisg
ICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCBmZWF0dXJlIG5hbWU6ICRhY191c2Vyb3B0Igor
ICAgIGFjX3VzZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hv
ICIkYWNfdXNlcm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29w
dHMgaW4KKyAgICAgICoiCisiZW5hYmxlXyRhY191c2Vyb3B0IgorIiopIDs7CisgICAgICAqKSBh
Y191bnJlY29nbml6ZWRfb3B0cz0iJGFjX3VucmVjb2duaXplZF9vcHRzJGFjX3VucmVjb2duaXpl
ZF9zZXAtLWVuYWJsZS0kYWNfdXNlcm9wdF9vcmlnIgorCSBhY191bnJlY29nbml6ZWRfc2VwPScs
ICc7OworICAgIGVzYWMKKyAgICBldmFsIGVuYWJsZV8kYWNfdXNlcm9wdD1cJGFjX29wdGFyZyA7
OworCisgIC1leGVjLXByZWZpeCB8IC0tZXhlY19wcmVmaXggfCAtLWV4ZWMtcHJlZml4IHwgLS1l
eGVjLXByZWZpIFwKKyAgfCAtLWV4ZWMtcHJlZiB8IC0tZXhlYy1wcmUgfCAtLWV4ZWMtcHIgfCAt
LWV4ZWMtcCB8IC0tZXhlYy0gXAorICB8IC0tZXhlYyB8IC0tZXhlIHwgLS1leCkKKyAgICBhY19w
cmV2PWV4ZWNfcHJlZml4IDs7CisgIC1leGVjLXByZWZpeD0qIHwgLS1leGVjX3ByZWZpeD0qIHwg
LS1leGVjLXByZWZpeD0qIHwgLS1leGVjLXByZWZpPSogXAorICB8IC0tZXhlYy1wcmVmPSogfCAt
LWV4ZWMtcHJlPSogfCAtLWV4ZWMtcHI9KiB8IC0tZXhlYy1wPSogfCAtLWV4ZWMtPSogXAorICB8
IC0tZXhlYz0qIHwgLS1leGU9KiB8IC0tZXg9KikKKyAgICBleGVjX3ByZWZpeD0kYWNfb3B0YXJn
IDs7CisKKyAgLWdhcyB8IC0tZ2FzIHwgLS1nYSB8IC0tZykKKyAgICAjIE9ic29sZXRlOyB1c2Ug
LS13aXRoLWdhcy4KKyAgICB3aXRoX2dhcz15ZXMgOzsKKworICAtaGVscCB8IC0taGVscCB8IC0t
aGVsIHwgLS1oZSB8IC1oKQorICAgIGFjX2luaXRfaGVscD1sb25nIDs7CisgIC1oZWxwPXIqIHwg
LS1oZWxwPXIqIHwgLS1oZWw9ciogfCAtLWhlPXIqIHwgLWhyKikKKyAgICBhY19pbml0X2hlbHA9
cmVjdXJzaXZlIDs7CisgIC1oZWxwPXMqIHwgLS1oZWxwPXMqIHwgLS1oZWw9cyogfCAtLWhlPXMq
IHwgLWhzKikKKyAgICBhY19pbml0X2hlbHA9c2hvcnQgOzsKKworICAtaG9zdCB8IC0taG9zdCB8
IC0taG9zIHwgLS1obykKKyAgICBhY19wcmV2PWhvc3RfYWxpYXMgOzsKKyAgLWhvc3Q9KiB8IC0t
aG9zdD0qIHwgLS1ob3M9KiB8IC0taG89KikKKyAgICBob3N0X2FsaWFzPSRhY19vcHRhcmcgOzsK
KworICAtaHRtbGRpciB8IC0taHRtbGRpciB8IC0taHRtbGRpIHwgLS1odG1sZCB8IC0taHRtbCB8
IC0taHRtIHwgLS1odCkKKyAgICBhY19wcmV2PWh0bWxkaXIgOzsKKyAgLWh0bWxkaXI9KiB8IC0t
aHRtbGRpcj0qIHwgLS1odG1sZGk9KiB8IC0taHRtbGQ9KiB8IC0taHRtbD0qIHwgLS1odG09KiBc
CisgIHwgLS1odD0qKQorICAgIGh0bWxkaXI9JGFjX29wdGFyZyA7OworCisgIC1pbmNsdWRlZGly
IHwgLS1pbmNsdWRlZGlyIHwgLS1pbmNsdWRlZGkgfCAtLWluY2x1ZGVkIHwgLS1pbmNsdWRlIFwK
KyAgfCAtLWluY2x1ZCB8IC0taW5jbHUgfCAtLWluY2wgfCAtLWluYykKKyAgICBhY19wcmV2PWlu
Y2x1ZGVkaXIgOzsKKyAgLWluY2x1ZGVkaXI9KiB8IC0taW5jbHVkZWRpcj0qIHwgLS1pbmNsdWRl
ZGk9KiB8IC0taW5jbHVkZWQ9KiB8IC0taW5jbHVkZT0qIFwKKyAgfCAtLWluY2x1ZD0qIHwgLS1p
bmNsdT0qIHwgLS1pbmNsPSogfCAtLWluYz0qKQorICAgIGluY2x1ZGVkaXI9JGFjX29wdGFyZyA7
OworCisgIC1pbmZvZGlyIHwgLS1pbmZvZGlyIHwgLS1pbmZvZGkgfCAtLWluZm9kIHwgLS1pbmZv
IHwgLS1pbmYpCisgICAgYWNfcHJldj1pbmZvZGlyIDs7CisgIC1pbmZvZGlyPSogfCAtLWluZm9k
aXI9KiB8IC0taW5mb2RpPSogfCAtLWluZm9kPSogfCAtLWluZm89KiB8IC0taW5mPSopCisgICAg
aW5mb2Rpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWxpYmRpciB8IC0tbGliZGlyIHwgLS1saWJkaSB8
IC0tbGliZCkKKyAgICBhY19wcmV2PWxpYmRpciA7OworICAtbGliZGlyPSogfCAtLWxpYmRpcj0q
IHwgLS1saWJkaT0qIHwgLS1saWJkPSopCisgICAgbGliZGlyPSRhY19vcHRhcmcgOzsKKworICAt
bGliZXhlY2RpciB8IC0tbGliZXhlY2RpciB8IC0tbGliZXhlY2RpIHwgLS1saWJleGVjZCB8IC0t
bGliZXhlYyBcCisgIHwgLS1saWJleGUgfCAtLWxpYmV4IHwgLS1saWJlKQorICAgIGFjX3ByZXY9
bGliZXhlY2RpciA7OworICAtbGliZXhlY2Rpcj0qIHwgLS1saWJleGVjZGlyPSogfCAtLWxpYmV4
ZWNkaT0qIHwgLS1saWJleGVjZD0qIHwgLS1saWJleGVjPSogXAorICB8IC0tbGliZXhlPSogfCAt
LWxpYmV4PSogfCAtLWxpYmU9KikKKyAgICBsaWJleGVjZGlyPSRhY19vcHRhcmcgOzsKKworICAt
bG9jYWxlZGlyIHwgLS1sb2NhbGVkaXIgfCAtLWxvY2FsZWRpIHwgLS1sb2NhbGVkIHwgLS1sb2Nh
bGUpCisgICAgYWNfcHJldj1sb2NhbGVkaXIgOzsKKyAgLWxvY2FsZWRpcj0qIHwgLS1sb2NhbGVk
aXI9KiB8IC0tbG9jYWxlZGk9KiB8IC0tbG9jYWxlZD0qIHwgLS1sb2NhbGU9KikKKyAgICBsb2Nh
bGVkaXI9JGFjX29wdGFyZyA7OworCisgIC1sb2NhbHN0YXRlZGlyIHwgLS1sb2NhbHN0YXRlZGly
IHwgLS1sb2NhbHN0YXRlZGkgfCAtLWxvY2Fsc3RhdGVkIFwKKyAgfCAtLWxvY2Fsc3RhdGUgfCAt
LWxvY2Fsc3RhdCB8IC0tbG9jYWxzdGEgfCAtLWxvY2Fsc3QgfCAtLWxvY2FscykKKyAgICBhY19w
cmV2PWxvY2Fsc3RhdGVkaXIgOzsKKyAgLWxvY2Fsc3RhdGVkaXI9KiB8IC0tbG9jYWxzdGF0ZWRp
cj0qIHwgLS1sb2NhbHN0YXRlZGk9KiB8IC0tbG9jYWxzdGF0ZWQ9KiBcCisgIHwgLS1sb2NhbHN0
YXRlPSogfCAtLWxvY2Fsc3RhdD0qIHwgLS1sb2NhbHN0YT0qIHwgLS1sb2NhbHN0PSogfCAtLWxv
Y2Fscz0qKQorICAgIGxvY2Fsc3RhdGVkaXI9JGFjX29wdGFyZyA7OworCisgIC1tYW5kaXIgfCAt
LW1hbmRpciB8IC0tbWFuZGkgfCAtLW1hbmQgfCAtLW1hbiB8IC0tbWEgfCAtLW0pCisgICAgYWNf
cHJldj1tYW5kaXIgOzsKKyAgLW1hbmRpcj0qIHwgLS1tYW5kaXI9KiB8IC0tbWFuZGk9KiB8IC0t
bWFuZD0qIHwgLS1tYW49KiB8IC0tbWE9KiB8IC0tbT0qKQorICAgIG1hbmRpcj0kYWNfb3B0YXJn
IDs7CisKKyAgLW5mcCB8IC0tbmZwIHwgLS1uZikKKyAgICAjIE9ic29sZXRlOyB1c2UgLS13aXRo
b3V0LWZwLgorICAgIHdpdGhfZnA9bm8gOzsKKworICAtbm8tY3JlYXRlIHwgLS1uby1jcmVhdGUg
fCAtLW5vLWNyZWF0IHwgLS1uby1jcmVhIHwgLS1uby1jcmUgXAorICB8IC0tbm8tY3IgfCAtLW5v
LWMgfCAtbikKKyAgICBub19jcmVhdGU9eWVzIDs7CisKKyAgLW5vLXJlY3Vyc2lvbiB8IC0tbm8t
cmVjdXJzaW9uIHwgLS1uby1yZWN1cnNpbyB8IC0tbm8tcmVjdXJzaSBcCisgIHwgLS1uby1yZWN1
cnMgfCAtLW5vLXJlY3VyIHwgLS1uby1yZWN1IHwgLS1uby1yZWMgfCAtLW5vLXJlIHwgLS1uby1y
KQorICAgIG5vX3JlY3Vyc2lvbj15ZXMgOzsKKworICAtb2xkaW5jbHVkZWRpciB8IC0tb2xkaW5j
bHVkZWRpciB8IC0tb2xkaW5jbHVkZWRpIHwgLS1vbGRpbmNsdWRlZCBcCisgIHwgLS1vbGRpbmNs
dWRlIHwgLS1vbGRpbmNsdWQgfCAtLW9sZGluY2x1IHwgLS1vbGRpbmNsIHwgLS1vbGRpbmMgXAor
ICB8IC0tb2xkaW4gfCAtLW9sZGkgfCAtLW9sZCB8IC0tb2wgfCAtLW8pCisgICAgYWNfcHJldj1v
bGRpbmNsdWRlZGlyIDs7CisgIC1vbGRpbmNsdWRlZGlyPSogfCAtLW9sZGluY2x1ZGVkaXI9KiB8
IC0tb2xkaW5jbHVkZWRpPSogfCAtLW9sZGluY2x1ZGVkPSogXAorICB8IC0tb2xkaW5jbHVkZT0q
IHwgLS1vbGRpbmNsdWQ9KiB8IC0tb2xkaW5jbHU9KiB8IC0tb2xkaW5jbD0qIHwgLS1vbGRpbmM9
KiBcCisgIHwgLS1vbGRpbj0qIHwgLS1vbGRpPSogfCAtLW9sZD0qIHwgLS1vbD0qIHwgLS1vPSop
CisgICAgb2xkaW5jbHVkZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLXByZWZpeCB8IC0tcHJlZml4
IHwgLS1wcmVmaSB8IC0tcHJlZiB8IC0tcHJlIHwgLS1wciB8IC0tcCkKKyAgICBhY19wcmV2PXBy
ZWZpeCA7OworICAtcHJlZml4PSogfCAtLXByZWZpeD0qIHwgLS1wcmVmaT0qIHwgLS1wcmVmPSog
fCAtLXByZT0qIHwgLS1wcj0qIHwgLS1wPSopCisgICAgcHJlZml4PSRhY19vcHRhcmcgOzsKKwor
ICAtcHJvZ3JhbS1wcmVmaXggfCAtLXByb2dyYW0tcHJlZml4IHwgLS1wcm9ncmFtLXByZWZpIHwg
LS1wcm9ncmFtLXByZWYgXAorICB8IC0tcHJvZ3JhbS1wcmUgfCAtLXByb2dyYW0tcHIgfCAtLXBy
b2dyYW0tcCkKKyAgICBhY19wcmV2PXByb2dyYW1fcHJlZml4IDs7CisgIC1wcm9ncmFtLXByZWZp
eD0qIHwgLS1wcm9ncmFtLXByZWZpeD0qIHwgLS1wcm9ncmFtLXByZWZpPSogXAorICB8IC0tcHJv
Z3JhbS1wcmVmPSogfCAtLXByb2dyYW0tcHJlPSogfCAtLXByb2dyYW0tcHI9KiB8IC0tcHJvZ3Jh
bS1wPSopCisgICAgcHJvZ3JhbV9wcmVmaXg9JGFjX29wdGFyZyA7OworCisgIC1wcm9ncmFtLXN1
ZmZpeCB8IC0tcHJvZ3JhbS1zdWZmaXggfCAtLXByb2dyYW0tc3VmZmkgfCAtLXByb2dyYW0tc3Vm
ZiBcCisgIHwgLS1wcm9ncmFtLXN1ZiB8IC0tcHJvZ3JhbS1zdSB8IC0tcHJvZ3JhbS1zKQorICAg
IGFjX3ByZXY9cHJvZ3JhbV9zdWZmaXggOzsKKyAgLXByb2dyYW0tc3VmZml4PSogfCAtLXByb2dy
YW0tc3VmZml4PSogfCAtLXByb2dyYW0tc3VmZmk9KiBcCisgIHwgLS1wcm9ncmFtLXN1ZmY9KiB8
IC0tcHJvZ3JhbS1zdWY9KiB8IC0tcHJvZ3JhbS1zdT0qIHwgLS1wcm9ncmFtLXM9KikKKyAgICBw
cm9ncmFtX3N1ZmZpeD0kYWNfb3B0YXJnIDs7CisKKyAgLXByb2dyYW0tdHJhbnNmb3JtLW5hbWUg
fCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hbWUgXAorICB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tbmFt
IHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYSBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uIHwg
LS1wcm9ncmFtLXRyYW5zZm9ybS0gXAorICB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0gfCAtLXByb2dy
YW0tdHJhbnNmb3IgXAorICB8IC0tcHJvZ3JhbS10cmFuc2ZvIHwgLS1wcm9ncmFtLXRyYW5zZiBc
CisgIHwgLS1wcm9ncmFtLXRyYW5zIHwgLS1wcm9ncmFtLXRyYW4gXAorICB8IC0tcHJvZ3ItdHJh
IHwgLS1wcm9ncmFtLXRyIHwgLS1wcm9ncmFtLXQpCisgICAgYWNfcHJldj1wcm9ncmFtX3RyYW5z
Zm9ybV9uYW1lIDs7CisgIC1wcm9ncmFtLXRyYW5zZm9ybS1uYW1lPSogfCAtLXByb2dyYW0tdHJh
bnNmb3JtLW5hbWU9KiBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYW09KiB8IC0tcHJvZ3Jh
bS10cmFuc2Zvcm0tbmE9KiBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uPSogfCAtLXByb2dy
YW0tdHJhbnNmb3JtLT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtPSogfCAtLXByb2dyYW0t
dHJhbnNmb3I9KiBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm89KiB8IC0tcHJvZ3JhbS10cmFuc2Y9
KiBcCisgIHwgLS1wcm9ncmFtLXRyYW5zPSogfCAtLXByb2dyYW0tdHJhbj0qIFwKKyAgfCAtLXBy
b2dyLXRyYT0qIHwgLS1wcm9ncmFtLXRyPSogfCAtLXByb2dyYW0tdD0qKQorICAgIHByb2dyYW1f
dHJhbnNmb3JtX25hbWU9JGFjX29wdGFyZyA7OworCisgIC1wZGZkaXIgfCAtLXBkZmRpciB8IC0t
cGRmZGkgfCAtLXBkZmQgfCAtLXBkZiB8IC0tcGQpCisgICAgYWNfcHJldj1wZGZkaXIgOzsKKyAg
LXBkZmRpcj0qIHwgLS1wZGZkaXI9KiB8IC0tcGRmZGk9KiB8IC0tcGRmZD0qIHwgLS1wZGY9KiB8
IC0tcGQ9KikKKyAgICBwZGZkaXI9JGFjX29wdGFyZyA7OworCisgIC1wc2RpciB8IC0tcHNkaXIg
fCAtLXBzZGkgfCAtLXBzZCB8IC0tcHMpCisgICAgYWNfcHJldj1wc2RpciA7OworICAtcHNkaXI9
KiB8IC0tcHNkaXI9KiB8IC0tcHNkaT0qIHwgLS1wc2Q9KiB8IC0tcHM9KikKKyAgICBwc2Rpcj0k
YWNfb3B0YXJnIDs7CisKKyAgLXEgfCAtcXVpZXQgfCAtLXF1aWV0IHwgLS1xdWllIHwgLS1xdWkg
fCAtLXF1IHwgLS1xIFwKKyAgfCAtc2lsZW50IHwgLS1zaWxlbnQgfCAtLXNpbGVuIHwgLS1zaWxl
IHwgLS1zaWwpCisgICAgc2lsZW50PXllcyA7OworCisgIC1zYmluZGlyIHwgLS1zYmluZGlyIHwg
LS1zYmluZGkgfCAtLXNiaW5kIHwgLS1zYmluIHwgLS1zYmkgfCAtLXNiKQorICAgIGFjX3ByZXY9
c2JpbmRpciA7OworICAtc2JpbmRpcj0qIHwgLS1zYmluZGlyPSogfCAtLXNiaW5kaT0qIHwgLS1z
YmluZD0qIHwgLS1zYmluPSogXAorICB8IC0tc2JpPSogfCAtLXNiPSopCisgICAgc2JpbmRpcj0k
YWNfb3B0YXJnIDs7CisKKyAgLXNoYXJlZHN0YXRlZGlyIHwgLS1zaGFyZWRzdGF0ZWRpciB8IC0t
c2hhcmVkc3RhdGVkaSBcCisgIHwgLS1zaGFyZWRzdGF0ZWQgfCAtLXNoYXJlZHN0YXRlIHwgLS1z
aGFyZWRzdGF0IHwgLS1zaGFyZWRzdGEgXAorICB8IC0tc2hhcmVkc3QgfCAtLXNoYXJlZHMgfCAt
LXNoYXJlZCB8IC0tc2hhcmUgfCAtLXNoYXIgXAorICB8IC0tc2hhIHwgLS1zaCkKKyAgICBhY19w
cmV2PXNoYXJlZHN0YXRlZGlyIDs7CisgIC1zaGFyZWRzdGF0ZWRpcj0qIHwgLS1zaGFyZWRzdGF0
ZWRpcj0qIHwgLS1zaGFyZWRzdGF0ZWRpPSogXAorICB8IC0tc2hhcmVkc3RhdGVkPSogfCAtLXNo
YXJlZHN0YXRlPSogfCAtLXNoYXJlZHN0YXQ9KiB8IC0tc2hhcmVkc3RhPSogXAorICB8IC0tc2hh
cmVkc3Q9KiB8IC0tc2hhcmVkcz0qIHwgLS1zaGFyZWQ9KiB8IC0tc2hhcmU9KiB8IC0tc2hhcj0q
IFwKKyAgfCAtLXNoYT0qIHwgLS1zaD0qKQorICAgIHNoYXJlZHN0YXRlZGlyPSRhY19vcHRhcmcg
OzsKKworICAtc2l0ZSB8IC0tc2l0ZSB8IC0tc2l0KQorICAgIGFjX3ByZXY9c2l0ZSA7OworICAt
c2l0ZT0qIHwgLS1zaXRlPSogfCAtLXNpdD0qKQorICAgIHNpdGU9JGFjX29wdGFyZyA7OworCisg
IC1zcmNkaXIgfCAtLXNyY2RpciB8IC0tc3JjZGkgfCAtLXNyY2QgfCAtLXNyYyB8IC0tc3IpCisg
ICAgYWNfcHJldj1zcmNkaXIgOzsKKyAgLXNyY2Rpcj0qIHwgLS1zcmNkaXI9KiB8IC0tc3JjZGk9
KiB8IC0tc3JjZD0qIHwgLS1zcmM9KiB8IC0tc3I9KikKKyAgICBzcmNkaXI9JGFjX29wdGFyZyA7
OworCisgIC1zeXNjb25mZGlyIHwgLS1zeXNjb25mZGlyIHwgLS1zeXNjb25mZGkgfCAtLXN5c2Nv
bmZkIHwgLS1zeXNjb25mIFwKKyAgfCAtLXN5c2NvbiB8IC0tc3lzY28gfCAtLXN5c2MgfCAtLXN5
cyB8IC0tc3kpCisgICAgYWNfcHJldj1zeXNjb25mZGlyIDs7CisgIC1zeXNjb25mZGlyPSogfCAt
LXN5c2NvbmZkaXI9KiB8IC0tc3lzY29uZmRpPSogfCAtLXN5c2NvbmZkPSogfCAtLXN5c2NvbmY9
KiBcCisgIHwgLS1zeXNjb249KiB8IC0tc3lzY289KiB8IC0tc3lzYz0qIHwgLS1zeXM9KiB8IC0t
c3k9KikKKyAgICBzeXNjb25mZGlyPSRhY19vcHRhcmcgOzsKKworICAtdGFyZ2V0IHwgLS10YXJn
ZXQgfCAtLXRhcmdlIHwgLS10YXJnIHwgLS10YXIgfCAtLXRhIHwgLS10KQorICAgIGFjX3ByZXY9
dGFyZ2V0X2FsaWFzIDs7CisgIC10YXJnZXQ9KiB8IC0tdGFyZ2V0PSogfCAtLXRhcmdlPSogfCAt
LXRhcmc9KiB8IC0tdGFyPSogfCAtLXRhPSogfCAtLXQ9KikKKyAgICB0YXJnZXRfYWxpYXM9JGFj
X29wdGFyZyA7OworCisgIC12IHwgLXZlcmJvc2UgfCAtLXZlcmJvc2UgfCAtLXZlcmJvcyB8IC0t
dmVyYm8gfCAtLXZlcmIpCisgICAgdmVyYm9zZT15ZXMgOzsKKworICAtdmVyc2lvbiB8IC0tdmVy
c2lvbiB8IC0tdmVyc2lvIHwgLS12ZXJzaSB8IC0tdmVycyB8IC1WKQorICAgIGFjX2luaXRfdmVy
c2lvbj06IDs7CisKKyAgLXdpdGgtKiB8IC0td2l0aC0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIg
IngkYWNfb3B0aW9uIiA6ICd4LSp3aXRoLVwoW149XSpcKSdgCisgICAgIyBSZWplY3QgbmFtZXMg
dGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIgIngkYWNf
dXNlcm9wdCIgOiAiLipbXi0rLl8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisgICAgICBh
c19mbl9lcnJvciAkPyAiaW52YWxpZCBwYWNrYWdlIG5hbWU6ICRhY191c2Vyb3B0IgorICAgIGFj
X3VzZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hvICIkYWNf
dXNlcm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29wdHMgaW4K
KyAgICAgICoiCisid2l0aF8kYWNfdXNlcm9wdCIKKyIqKSA7OworICAgICAgKikgYWNfdW5yZWNv
Z25pemVkX29wdHM9IiRhY191bnJlY29nbml6ZWRfb3B0cyRhY191bnJlY29nbml6ZWRfc2VwLS13
aXRoLSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9JywgJzs7CisgICAg
ZXNhYworICAgIGV2YWwgd2l0aF8kYWNfdXNlcm9wdD1cJGFjX29wdGFyZyA7OworCisgIC13aXRo
b3V0LSogfCAtLXdpdGhvdXQtKikKKyAgICBhY191c2Vyb3B0PWBleHByICJ4JGFjX29wdGlvbiIg
OiAneC0qd2l0aG91dC1cKC4qXCknYAorICAgICMgUmVqZWN0IG5hbWVzIHRoYXQgYXJlIG5vdCB2
YWxpZCBzaGVsbCB2YXJpYWJsZSBuYW1lcy4KKyAgICBleHByICJ4JGFjX3VzZXJvcHQiIDogIi4q
W14tKy5fJGFzX2NyX2FsbnVtXSIgPi9kZXYvbnVsbCAmJgorICAgICAgYXNfZm5fZXJyb3IgJD8g
ImludmFsaWQgcGFja2FnZSBuYW1lOiAkYWNfdXNlcm9wdCIKKyAgICBhY191c2Vyb3B0X29yaWc9
JGFjX3VzZXJvcHQKKyAgICBhY191c2Vyb3B0PWAkYXNfZWNobyAiJGFjX3VzZXJvcHQiIHwgc2Vk
ICdzL1stKy5dL18vZydgCisgICAgY2FzZSAkYWNfdXNlcl9vcHRzIGluCisgICAgICAqIgorIndp
dGhfJGFjX3VzZXJvcHQiCisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIk
YWNfdW5yZWNvZ25pemVkX29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0td2l0aG91dC0kYWNfdXNl
cm9wdF9vcmlnIgorCSBhY191bnJlY29nbml6ZWRfc2VwPScsICc7OworICAgIGVzYWMKKyAgICBl
dmFsIHdpdGhfJGFjX3VzZXJvcHQ9bm8gOzsKKworICAtLXgpCisgICAgIyBPYnNvbGV0ZTsgdXNl
IC0td2l0aC14LgorICAgIHdpdGhfeD15ZXMgOzsKKworICAteC1pbmNsdWRlcyB8IC0teC1pbmNs
dWRlcyB8IC0teC1pbmNsdWRlIHwgLS14LWluY2x1ZCB8IC0teC1pbmNsdSBcCisgIHwgLS14LWlu
Y2wgfCAtLXgtaW5jIHwgLS14LWluIHwgLS14LWkpCisgICAgYWNfcHJldj14X2luY2x1ZGVzIDs7
CisgIC14LWluY2x1ZGVzPSogfCAtLXgtaW5jbHVkZXM9KiB8IC0teC1pbmNsdWRlPSogfCAtLXgt
aW5jbHVkPSogfCAtLXgtaW5jbHU9KiBcCisgIHwgLS14LWluY2w9KiB8IC0teC1pbmM9KiB8IC0t
eC1pbj0qIHwgLS14LWk9KikKKyAgICB4X2luY2x1ZGVzPSRhY19vcHRhcmcgOzsKKworICAteC1s
aWJyYXJpZXMgfCAtLXgtbGlicmFyaWVzIHwgLS14LWxpYnJhcmllIHwgLS14LWxpYnJhcmkgXAor
ICB8IC0teC1saWJyYXIgfCAtLXgtbGlicmEgfCAtLXgtbGliciB8IC0teC1saWIgfCAtLXgtbGkg
fCAtLXgtbCkKKyAgICBhY19wcmV2PXhfbGlicmFyaWVzIDs7CisgIC14LWxpYnJhcmllcz0qIHwg
LS14LWxpYnJhcmllcz0qIHwgLS14LWxpYnJhcmllPSogfCAtLXgtbGlicmFyaT0qIFwKKyAgfCAt
LXgtbGlicmFyPSogfCAtLXgtbGlicmE9KiB8IC0teC1saWJyPSogfCAtLXgtbGliPSogfCAtLXgt
bGk9KiB8IC0teC1sPSopCisgICAgeF9saWJyYXJpZXM9JGFjX29wdGFyZyA7OworCisgIC0qKSBh
c19mbl9lcnJvciAkPyAidW5yZWNvZ25pemVkIG9wdGlvbjogXGAkYWNfb3B0aW9uJworVHJ5IFxg
JDAgLS1oZWxwJyBmb3IgbW9yZSBpbmZvcm1hdGlvbiIKKyAgICA7OworCisgICo9KikKKyAgICBh
Y19lbnZ2YXI9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4XChbXj1dKlwpPSdgCisgICAgIyBSZWpl
Y3QgbmFtZXMgdGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGNh
c2UgJGFjX2VudnZhciBpbiAjKAorICAgICAgJycgfCBbMC05XSogfCAqWyFfJGFzX2NyX2FsbnVt
XSogKQorICAgICAgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFyaWFibGUgbmFtZTogXGAkYWNf
ZW52dmFyJyIgOzsKKyAgICBlc2FjCisgICAgZXZhbCAkYWNfZW52dmFyPVwkYWNfb3B0YXJnCisg
ICAgZXhwb3J0ICRhY19lbnZ2YXIgOzsKKworICAqKQorICAgICMgRklYTUU6IHNob3VsZCBiZSBy
ZW1vdmVkIGluIGF1dG9jb25mIDMuMC4KKyAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB5
b3Ugc2hvdWxkIHVzZSAtLWJ1aWxkLCAtLWhvc3QsIC0tdGFyZ2V0IiA+JjIKKyAgICBleHByICJ4
JGFjX29wdGlvbiIgOiAiLipbXi0uXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAg
ICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IGludmFsaWQgaG9zdCB0eXBlOiAkYWNfb3B0aW9u
IiA+JjIKKyAgICA6ICIke2J1aWxkX2FsaWFzPSRhY19vcHRpb259ICR7aG9zdF9hbGlhcz0kYWNf
b3B0aW9ufSAke3RhcmdldF9hbGlhcz0kYWNfb3B0aW9ufSIKKyAgICA7OworCisgIGVzYWMKK2Rv
bmUKKworaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisgIGFjX29wdGlvbj0tLWBlY2hvICRh
Y19wcmV2IHwgc2VkICdzL18vLS9nJ2AKKyAgYXNfZm5fZXJyb3IgJD8gIm1pc3NpbmcgYXJndW1l
bnQgdG8gJGFjX29wdGlvbiIKK2ZpCisKK2lmIHRlc3QgLW4gIiRhY191bnJlY29nbml6ZWRfb3B0
cyI7IHRoZW4KKyAgY2FzZSAkZW5hYmxlX29wdGlvbl9jaGVja2luZyBpbgorICAgIG5vKSA7Owor
ICAgIGZhdGFsKSBhc19mbl9lcnJvciAkPyAidW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJl
Y29nbml6ZWRfb3B0cyIgOzsKKyAgICAqKSAgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzog
dW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiYyIDs7CisgIGVz
YWMKK2ZpCisKKyMgQ2hlY2sgYWxsIGRpcmVjdG9yeSBhcmd1bWVudHMgZm9yIGNvbnNpc3RlbmN5
LgorZm9yIGFjX3ZhciBpbglleGVjX3ByZWZpeCBwcmVmaXggYmluZGlyIHNiaW5kaXIgbGliZXhl
Y2RpciBkYXRhcm9vdGRpciBcCisJCWRhdGFkaXIgc3lzY29uZmRpciBzaGFyZWRzdGF0ZWRpciBs
b2NhbHN0YXRlZGlyIGluY2x1ZGVkaXIgXAorCQlvbGRpbmNsdWRlZGlyIGRvY2RpciBpbmZvZGly
IGh0bWxkaXIgZHZpZGlyIHBkZmRpciBwc2RpciBcCisJCWxpYmRpciBsb2NhbGVkaXIgbWFuZGly
CitkbworICBldmFsIGFjX3ZhbD1cJCRhY192YXIKKyAgIyBSZW1vdmUgdHJhaWxpbmcgc2xhc2hl
cy4KKyAgY2FzZSAkYWNfdmFsIGluCisgICAgKi8gKQorICAgICAgYWNfdmFsPWBleHByICJYJGFj
X3ZhbCIgOiAnWFwoLipbXi9dXCknIFx8ICJYJGFjX3ZhbCIgOiAnWFwoLipcKSdgCisgICAgICBl
dmFsICRhY192YXI9XCRhY192YWw7OworICBlc2FjCisgICMgQmUgc3VyZSB0byBoYXZlIGFic29s
dXRlIGRpcmVjdG9yeSBuYW1lcy4KKyAgY2FzZSAkYWNfdmFsIGluCisgICAgW1xcLyRdKiB8ID86
W1xcL10qICkgIGNvbnRpbnVlOzsKKyAgICBOT05FIHwgJycgKSBjYXNlICRhY192YXIgaW4gKnBy
ZWZpeCApIGNvbnRpbnVlOzsgZXNhYzs7CisgIGVzYWMKKyAgYXNfZm5fZXJyb3IgJD8gImV4cGVj
dGVkIGFuIGFic29sdXRlIGRpcmVjdG9yeSBuYW1lIGZvciAtLSRhY192YXI6ICRhY192YWwiCitk
b25lCisKKyMgVGhlcmUgbWlnaHQgYmUgcGVvcGxlIHdobyBkZXBlbmQgb24gdGhlIG9sZCBicm9r
ZW4gYmVoYXZpb3I6IGAkaG9zdCcKKyMgdXNlZCB0byBob2xkIHRoZSBhcmd1bWVudCBvZiAtLWhv
c3QgZXRjLgorIyBGSVhNRTogVG8gcmVtb3ZlIHNvbWUgZGF5LgorYnVpbGQ9JGJ1aWxkX2FsaWFz
Citob3N0PSRob3N0X2FsaWFzCit0YXJnZXQ9JHRhcmdldF9hbGlhcworCisjIEZJWE1FOiBUbyBy
ZW1vdmUgc29tZSBkYXkuCitpZiB0ZXN0ICJ4JGhvc3RfYWxpYXMiICE9IHg7IHRoZW4KKyAgaWYg
dGVzdCAieCRidWlsZF9hbGlhcyIgPSB4OyB0aGVuCisgICAgY3Jvc3NfY29tcGlsaW5nPW1heWJl
CisgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogaWYgeW91IHdhbnRlZCB0byBzZXQgdGhl
IC0tYnVpbGQgdHlwZSwgZG9uJ3QgdXNlIC0taG9zdC4KKyAgICBJZiBhIGNyb3NzIGNvbXBpbGVy
IGlzIGRldGVjdGVkIHRoZW4gY3Jvc3MgY29tcGlsZSBtb2RlIHdpbGwgYmUgdXNlZCIgPiYyCisg
IGVsaWYgdGVzdCAieCRidWlsZF9hbGlhcyIgIT0gIngkaG9zdF9hbGlhcyI7IHRoZW4KKyAgICBj
cm9zc19jb21waWxpbmc9eWVzCisgIGZpCitmaQorCithY190b29sX3ByZWZpeD0KK3Rlc3QgLW4g
IiRob3N0X2FsaWFzIiAmJiBhY190b29sX3ByZWZpeD0kaG9zdF9hbGlhcy0KKwordGVzdCAiJHNp
bGVudCIgPSB5ZXMgJiYgZXhlYyA2Pi9kZXYvbnVsbAorCisKK2FjX3B3ZD1gcHdkYCAmJiB0ZXN0
IC1uICIkYWNfcHdkIiAmJgorYWNfbHNfZGk9YGxzIC1kaSAuYCAmJgorYWNfcHdkX2xzX2RpPWBj
ZCAiJGFjX3B3ZCIgJiYgbHMgLWRpIC5gIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJ3b3JraW5nIGRp
cmVjdG9yeSBjYW5ub3QgYmUgZGV0ZXJtaW5lZCIKK3Rlc3QgIlgkYWNfbHNfZGkiID0gIlgkYWNf
cHdkX2xzX2RpIiB8fAorICBhc19mbl9lcnJvciAkPyAicHdkIGRvZXMgbm90IHJlcG9ydCBuYW1l
IG9mIHdvcmtpbmcgZGlyZWN0b3J5IgorCisKKyMgRmluZCB0aGUgc291cmNlIGZpbGVzLCBpZiBs
b2NhdGlvbiB3YXMgbm90IHNwZWNpZmllZC4KK2lmIHRlc3QgLXogIiRzcmNkaXIiOyB0aGVuCisg
IGFjX3NyY2Rpcl9kZWZhdWx0ZWQ9eWVzCisgICMgVHJ5IHRoZSBkaXJlY3RvcnkgY29udGFpbmlu
ZyB0aGlzIHNjcmlwdCwgdGhlbiB0aGUgcGFyZW50IGRpcmVjdG9yeS4KKyAgYWNfY29uZmRpcj1g
JGFzX2Rpcm5hbWUgLS0gIiRhc19teXNlbGYiIHx8CiskYXNfZXhwciBYIiRhc19teXNlbGYiIDog
J1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBcCisJIFgiJGFzX215c2VsZiIgOiAnWFwo
Ly9cKVteL10nIFx8IFwKKwkgWCIkYXNfbXlzZWxmIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiRh
c19teXNlbGYiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWCIkYXNf
bXlzZWxmIiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14vXSpcLyokL3sKKwkg
ICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4qL3sKKwkgICAgcy8v
XDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMvL1wxLworCSAgICBx
CisJICB9CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBz
Ly4qLy4vOyBxJ2AKKyAgc3JjZGlyPSRhY19jb25mZGlyCisgIGlmIHRlc3QgISAtciAiJHNyY2Rp
ci8kYWNfdW5pcXVlX2ZpbGUiOyB0aGVuCisgICAgc3JjZGlyPS4uCisgIGZpCitlbHNlCisgIGFj
X3NyY2Rpcl9kZWZhdWx0ZWQ9bm8KK2ZpCitpZiB0ZXN0ICEgLXIgIiRzcmNkaXIvJGFjX3VuaXF1
ZV9maWxlIjsgdGhlbgorICB0ZXN0ICIkYWNfc3JjZGlyX2RlZmF1bHRlZCIgPSB5ZXMgJiYgc3Jj
ZGlyPSIkYWNfY29uZmRpciBvciAuLiIKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIHNv
dXJjZXMgKCRhY191bmlxdWVfZmlsZSkgaW4gJHNyY2RpciIKK2ZpCithY19tc2c9InNvdXJjZXMg
YXJlIGluICRzcmNkaXIsIGJ1dCBcYGNkICRzcmNkaXInIGRvZXMgbm90IHdvcmsiCithY19hYnNf
Y29uZmRpcj1gKAorCWNkICIkc3JjZGlyIiAmJiB0ZXN0IC1yICIuLyRhY191bmlxdWVfZmlsZSIg
fHwgYXNfZm5fZXJyb3IgJD8gIiRhY19tc2ciCisJcHdkKWAKKyMgV2hlbiBidWlsZGluZyBpbiBw
bGFjZSwgc2V0IHNyY2Rpcj0uCitpZiB0ZXN0ICIkYWNfYWJzX2NvbmZkaXIiID0gIiRhY19wd2Qi
OyB0aGVuCisgIHNyY2Rpcj0uCitmaQorIyBSZW1vdmUgdW5uZWNlc3NhcnkgdHJhaWxpbmcgc2xh
c2hlcyBmcm9tIHNyY2Rpci4KKyMgRG91YmxlIHNsYXNoZXMgaW4gZmlsZSBuYW1lcyBpbiBvYmpl
Y3QgZmlsZSBkZWJ1Z2dpbmcgaW5mbworIyBtZXNzIHVwIE0teCBnZGIgaW4gRW1hY3MuCitjYXNl
ICRzcmNkaXIgaW4KKyovKSBzcmNkaXI9YGV4cHIgIlgkc3JjZGlyIiA6ICdYXCguKlteL11cKScg
XHwgIlgkc3JjZGlyIiA6ICdYXCguKlwpJ2A7OworZXNhYworZm9yIGFjX3ZhciBpbiAkYWNfcHJl
Y2lvdXNfdmFyczsgZG8KKyAgZXZhbCBhY19lbnZfJHthY192YXJ9X3NldD1cJHske2FjX3Zhcn0r
c2V0fQorICBldmFsIGFjX2Vudl8ke2FjX3Zhcn1fdmFsdWU9XCQke2FjX3Zhcn0KKyAgZXZhbCBh
Y19jdl9lbnZfJHthY192YXJ9X3NldD1cJHske2FjX3Zhcn0rc2V0fQorICBldmFsIGFjX2N2X2Vu
dl8ke2FjX3Zhcn1fdmFsdWU9XCQke2FjX3Zhcn0KK2RvbmUKKworIworIyBSZXBvcnQgdGhlIC0t
aGVscCBtZXNzYWdlLgorIworaWYgdGVzdCAiJGFjX2luaXRfaGVscCIgPSAibG9uZyI7IHRoZW4K
KyAgIyBPbWl0IHNvbWUgaW50ZXJuYWwgb3Igb2Jzb2xldGUgb3B0aW9ucyB0byBtYWtlIHRoZSBs
aXN0IGxlc3MgaW1wb3NpbmcuCisgICMgVGhpcyBtZXNzYWdlIGlzIHRvbyBsb25nIHRvIGJlIGEg
c3RyaW5nIGluIHRoZSBBL1VYIDMuMSBzaC4KKyAgY2F0IDw8X0FDRU9GCitcYGNvbmZpZ3VyZScg
Y29uZmlndXJlcyBYZW4gSHlwZXJ2aXNvciA0LjIgdG8gYWRhcHQgdG8gbWFueSBraW5kcyBvZiBz
eXN0ZW1zLgorCitVc2FnZTogJDAgW09QVElPTl0uLi4gW1ZBUj1WQUxVRV0uLi4KKworVG8gYXNz
aWduIGVudmlyb25tZW50IHZhcmlhYmxlcyAoZS5nLiwgQ0MsIENGTEFHUy4uLiksIHNwZWNpZnkg
dGhlbSBhcworVkFSPVZBTFVFLiAgU2VlIGJlbG93IGZvciBkZXNjcmlwdGlvbnMgb2Ygc29tZSBv
ZiB0aGUgdXNlZnVsIHZhcmlhYmxlcy4KKworRGVmYXVsdHMgZm9yIHRoZSBvcHRpb25zIGFyZSBz
cGVjaWZpZWQgaW4gYnJhY2tldHMuCisKK0NvbmZpZ3VyYXRpb246CisgIC1oLCAtLWhlbHAgICAg
ICAgICAgICAgIGRpc3BsYXkgdGhpcyBoZWxwIGFuZCBleGl0CisgICAgICAtLWhlbHA9c2hvcnQg
ICAgICAgIGRpc3BsYXkgb3B0aW9ucyBzcGVjaWZpYyB0byB0aGlzIHBhY2thZ2UKKyAgICAgIC0t
aGVscD1yZWN1cnNpdmUgICAgZGlzcGxheSB0aGUgc2hvcnQgaGVscCBvZiBhbGwgdGhlIGluY2x1
ZGVkIHBhY2thZ2VzCisgIC1WLCAtLXZlcnNpb24gICAgICAgICAgIGRpc3BsYXkgdmVyc2lvbiBp
bmZvcm1hdGlvbiBhbmQgZXhpdAorICAtcSwgLS1xdWlldCwgLS1zaWxlbnQgICBkbyBub3QgcHJp
bnQgXGBjaGVja2luZyAuLi4nIG1lc3NhZ2VzCisgICAgICAtLWNhY2hlLWZpbGU9RklMRSAgIGNh
Y2hlIHRlc3QgcmVzdWx0cyBpbiBGSUxFIFtkaXNhYmxlZF0KKyAgLUMsIC0tY29uZmlnLWNhY2hl
ICAgICAgYWxpYXMgZm9yIFxgLS1jYWNoZS1maWxlPWNvbmZpZy5jYWNoZScKKyAgLW4sIC0tbm8t
Y3JlYXRlICAgICAgICAgZG8gbm90IGNyZWF0ZSBvdXRwdXQgZmlsZXMKKyAgICAgIC0tc3JjZGly
PURJUiAgICAgICAgZmluZCB0aGUgc291cmNlcyBpbiBESVIgW2NvbmZpZ3VyZSBkaXIgb3IgXGAu
LiddCisKK0luc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKKyAgLS1wcmVmaXg9UFJFRklYICAgICAg
ICAgaW5zdGFsbCBhcmNoaXRlY3R1cmUtaW5kZXBlbmRlbnQgZmlsZXMgaW4gUFJFRklYCisgICAg
ICAgICAgICAgICAgICAgICAgICAgIFskYWNfZGVmYXVsdF9wcmVmaXhdCisgIC0tZXhlYy1wcmVm
aXg9RVBSRUZJWCAgIGluc3RhbGwgYXJjaGl0ZWN0dXJlLWRlcGVuZGVudCBmaWxlcyBpbiBFUFJF
RklYCisgICAgICAgICAgICAgICAgICAgICAgICAgIFtQUkVGSVhdCisKK0J5IGRlZmF1bHQsIFxg
bWFrZSBpbnN0YWxsJyB3aWxsIGluc3RhbGwgYWxsIHRoZSBmaWxlcyBpbgorXGAkYWNfZGVmYXVs
dF9wcmVmaXgvYmluJywgXGAkYWNfZGVmYXVsdF9wcmVmaXgvbGliJyBldGMuICBZb3UgY2FuIHNw
ZWNpZnkKK2FuIGluc3RhbGxhdGlvbiBwcmVmaXggb3RoZXIgdGhhbiBcYCRhY19kZWZhdWx0X3By
ZWZpeCcgdXNpbmcgXGAtLXByZWZpeCcsCitmb3IgaW5zdGFuY2UgXGAtLXByZWZpeD1cJEhPTUUn
LgorCitGb3IgYmV0dGVyIGNvbnRyb2wsIHVzZSB0aGUgb3B0aW9ucyBiZWxvdy4KKworRmluZSB0
dW5pbmcgb2YgdGhlIGluc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKKyAgLS1iaW5kaXI9RElSICAg
ICAgICAgICAgdXNlciBleGVjdXRhYmxlcyBbRVBSRUZJWC9iaW5dCisgIC0tc2JpbmRpcj1ESVIg
ICAgICAgICAgIHN5c3RlbSBhZG1pbiBleGVjdXRhYmxlcyBbRVBSRUZJWC9zYmluXQorICAtLWxp
YmV4ZWNkaXI9RElSICAgICAgICBwcm9ncmFtIGV4ZWN1dGFibGVzIFtFUFJFRklYL2xpYmV4ZWNd
CisgIC0tc3lzY29uZmRpcj1ESVIgICAgICAgIHJlYWQtb25seSBzaW5nbGUtbWFjaGluZSBkYXRh
IFtQUkVGSVgvZXRjXQorICAtLXNoYXJlZHN0YXRlZGlyPURJUiAgICBtb2RpZmlhYmxlIGFyY2hp
dGVjdHVyZS1pbmRlcGVuZGVudCBkYXRhIFtQUkVGSVgvY29tXQorICAtLWxvY2Fsc3RhdGVkaXI9
RElSICAgICBtb2RpZmlhYmxlIHNpbmdsZS1tYWNoaW5lIGRhdGEgW1BSRUZJWC92YXJdCisgIC0t
bGliZGlyPURJUiAgICAgICAgICAgIG9iamVjdCBjb2RlIGxpYnJhcmllcyBbRVBSRUZJWC9saWJd
CisgIC0taW5jbHVkZWRpcj1ESVIgICAgICAgIEMgaGVhZGVyIGZpbGVzIFtQUkVGSVgvaW5jbHVk
ZV0KKyAgLS1vbGRpbmNsdWRlZGlyPURJUiAgICAgQyBoZWFkZXIgZmlsZXMgZm9yIG5vbi1nY2Mg
Wy91c3IvaW5jbHVkZV0KKyAgLS1kYXRhcm9vdGRpcj1ESVIgICAgICAgcmVhZC1vbmx5IGFyY2gu
LWluZGVwZW5kZW50IGRhdGEgcm9vdCBbUFJFRklYL3NoYXJlXQorICAtLWRhdGFkaXI9RElSICAg
ICAgICAgICByZWFkLW9ubHkgYXJjaGl0ZWN0dXJlLWluZGVwZW5kZW50IGRhdGEgW0RBVEFST09U
RElSXQorICAtLWluZm9kaXI9RElSICAgICAgICAgICBpbmZvIGRvY3VtZW50YXRpb24gW0RBVEFS
T09URElSL2luZm9dCisgIC0tbG9jYWxlZGlyPURJUiAgICAgICAgIGxvY2FsZS1kZXBlbmRlbnQg
ZGF0YSBbREFUQVJPT1RESVIvbG9jYWxlXQorICAtLW1hbmRpcj1ESVIgICAgICAgICAgICBtYW4g
ZG9jdW1lbnRhdGlvbiBbREFUQVJPT1RESVIvbWFuXQorICAtLWRvY2Rpcj1ESVIgICAgICAgICAg
ICBkb2N1bWVudGF0aW9uIHJvb3QgW0RBVEFST09URElSL2RvYy94ZW4taHlwZXJ2aXNvcl0KKyAg
LS1odG1sZGlyPURJUiAgICAgICAgICAgaHRtbCBkb2N1bWVudGF0aW9uIFtET0NESVJdCisgIC0t
ZHZpZGlyPURJUiAgICAgICAgICAgIGR2aSBkb2N1bWVudGF0aW9uIFtET0NESVJdCisgIC0tcGRm
ZGlyPURJUiAgICAgICAgICAgIHBkZiBkb2N1bWVudGF0aW9uIFtET0NESVJdCisgIC0tcHNkaXI9
RElSICAgICAgICAgICAgIHBzIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KK19BQ0VPRgorCisgIGNh
dCA8PFxfQUNFT0YKKworU3lzdGVtIHR5cGVzOgorICAtLWJ1aWxkPUJVSUxEICAgICBjb25maWd1
cmUgZm9yIGJ1aWxkaW5nIG9uIEJVSUxEIFtndWVzc2VkXQorICAtLWhvc3Q9SE9TVCAgICAgICBj
cm9zcy1jb21waWxlIHRvIGJ1aWxkIHByb2dyYW1zIHRvIHJ1biBvbiBIT1NUIFtCVUlMRF0KK19B
Q0VPRgorZmkKKworaWYgdGVzdCAtbiAiJGFjX2luaXRfaGVscCI7IHRoZW4KKyAgY2FzZSAkYWNf
aW5pdF9oZWxwIGluCisgICAgIHNob3J0IHwgcmVjdXJzaXZlICkgZWNobyAiQ29uZmlndXJhdGlv
biBvZiBYZW4gSHlwZXJ2aXNvciA0LjI6Ijs7CisgICBlc2FjCisgIGNhdCA8PFxfQUNFT0YKKwor
T3B0aW9uYWwgRmVhdHVyZXM6CisgIC0tZGlzYWJsZS1vcHRpb24tY2hlY2tpbmcgIGlnbm9yZSB1
bnJlY29nbml6ZWQgLS1lbmFibGUvLS13aXRoIG9wdGlvbnMKKyAgLS1kaXNhYmxlLUZFQVRVUkUg
ICAgICAgZG8gbm90IGluY2x1ZGUgRkVBVFVSRSAoc2FtZSBhcyAtLWVuYWJsZS1GRUFUVVJFPW5v
KQorICAtLWVuYWJsZS1GRUFUVVJFWz1BUkddICBpbmNsdWRlIEZFQVRVUkUgW0FSRz15ZXNdCisg
IC0tZW5hYmxlLXhzbSAgICAgICAgICAgIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBk
ZWZhdWx0LCBGbGFzaykKKyAgLS1lbmFibGUtZ2l0aHR0cCAgICAgICAgRG93bmxvYWQgR0lUIHJl
cG9zaXRvcmllcyB2aWEgSFRUUAorICAtLWRpc2FibGUtbW9uaXRvcnMgICAgICBEaXNhYmxlIHhl
bnN0YXQgYW5kIHhlbnRvcCBtb25pdG9yaW5nIHRvb2xzCisgIC0tZW5hYmxlLXZ0cG0gICAgICAg
ICAgIEVuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlCisgIC0tZW5hYmxlLXhh
cGkgICAgICAgICAgIEVuYWJsZSBYZW4gQVBJIEJpbmRpbmdzCisgIC0tZGlzYWJsZS1weXRob250
b29scyAgIERpc2FibGUgUHl0aG9uIHRvb2xzCisgIC0tZGlzYWJsZS1vY2FtbHRvb2xzICAgIERp
c2FibGUgT2NhbWwgdG9vbHMKKyAgLS1lbmFibGUtbWluaXRlcm0gICAgICAgRW5hYmxlIG1pbml0
ZXJtCisgIC0tZW5hYmxlLWxvbW91bnQgICAgICAgIEVuYWJsZSBsb21vdW50CisgIC0tZGlzYWJs
ZS1kZWJ1ZyAgICAgICAgIERpc2FibGUgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29scworCitT
b21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50IHZhcmlhYmxlczoKKyAgQ0MgICAgICAgICAgQyBj
b21waWxlciBjb21tYW5kCisgIENGTEFHUyAgICAgIEMgY29tcGlsZXIgZmxhZ3MKKyAgTERGTEFH
UyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxpYiBkaXI+IGlmIHlvdSBoYXZlIGxpYnJhcmll
cyBpbiBhCisgICAgICAgICAgICAgIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8bGliIGRpcj4KKyAg
TElCUyAgICAgICAgbGlicmFyaWVzIHRvIHBhc3MgdG8gdGhlIGxpbmtlciwgZS5nLiAtbDxsaWJy
YXJ5PgorICBDUFBGTEFHUyAgICAoT2JqZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3IgZmxhZ3Ms
IGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlmCisgICAgICAgICAgICAgIHlvdSBoYXZlIGhlYWRlcnMg
aW4gYSBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGluY2x1ZGUgZGlyPgorICBDUFAgICAgICAgICBD
IHByZXByb2Nlc3NvcgorICBQUkVQRU5EX0lOQ0xVREVTCisgICAgICAgICAgICAgIExpc3Qgb2Yg
aW5jbHVkZSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQorICBQUkVQ
RU5EX0xJQiBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxBR1MgKHdp
dGhvdXQgLUwpCisgIEFQUEVORF9JTkNMVURFUworICAgICAgICAgICAgICBMaXN0IG9mIGluY2x1
ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQorICBBUFBFTkRfTElC
ICBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAt
TCkKKyAgUFlUSE9OICAgICAgUGF0aCB0byB0aGUgUHl0aG9uIHBhcnNlcgorICBQRVJMICAgICAg
ICBQYXRoIHRvIFBlcmwgcGFyc2VyCisgIEJSQ1RMICAgICAgIFBhdGggdG8gYnJjdGwgdG9vbAor
ICBJUCAgICAgICAgICBQYXRoIHRvIGlwIHRvb2wKKyAgQklTT04gICAgICAgUGF0aCB0byBCaXNv
biBwYXJzZXIgZ2VuZXJhdG9yCisgIEZMRVggICAgICAgIFBhdGggdG8gRmxleCBsZXhpY2FsIGFu
YWx5c2VyIGdlbmVyYXRvcgorICBDVVJMICAgICAgICBQYXRoIHRvIGN1cmwtY29uZmlnIHRvb2wK
KyAgWE1MICAgICAgICAgUGF0aCB0byB4bWwyLWNvbmZpZyB0b29sCisgIEJBU0ggICAgICAgIFBh
dGggdG8gYmFzaCBzaGVsbAorICBYR0VUVEVYVCAgICBQYXRoIHRvIHhnZXR0dGV4dCB0b29sCisK
K1VzZSB0aGVzZSB2YXJpYWJsZXMgdG8gb3ZlcnJpZGUgdGhlIGNob2ljZXMgbWFkZSBieSBgY29u
ZmlndXJlJyBvciB0byBoZWxwCitpdCB0byBmaW5kIGxpYnJhcmllcyBhbmQgcHJvZ3JhbXMgd2l0
aCBub25zdGFuZGFyZCBuYW1lcy9sb2NhdGlvbnMuCisKK1JlcG9ydCBidWdzIHRvIDx4ZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbT4uCitfQUNFT0YKK2FjX3N0YXR1cz0kPworZmkKKworaWYg
dGVzdCAiJGFjX2luaXRfaGVscCIgPSAicmVjdXJzaXZlIjsgdGhlbgorICAjIElmIHRoZXJlIGFy
ZSBzdWJkaXJzLCByZXBvcnQgdGhlaXIgc3BlY2lmaWMgLS1oZWxwLgorICBmb3IgYWNfZGlyIGlu
IDogJGFjX3N1YmRpcnNfYWxsOyBkbyB0ZXN0ICJ4JGFjX2RpciIgPSB4OiAmJiBjb250aW51ZQor
ICAgIHRlc3QgLWQgIiRhY19kaXIiIHx8CisgICAgICB7IGNkICIkc3JjZGlyIiAmJiBhY19wd2Q9
YHB3ZGAgJiYgc3JjZGlyPS4gJiYgdGVzdCAtZCAiJGFjX2RpciI7IH0gfHwKKyAgICAgIGNvbnRp
bnVlCisgICAgYWNfYnVpbGRkaXI9LgorCitjYXNlICIkYWNfZGlyIiBpbgorLikgYWNfZGlyX3N1
ZmZpeD0gYWNfdG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9wcmVmaXg9IDs7CisqKQor
ICBhY19kaXJfc3VmZml4PS9gJGFzX2VjaG8gIiRhY19kaXIiIHwgc2VkICdzfF5cLltcXC9dfHwn
YAorICAjIEEgIi4uIiBmb3IgZWFjaCBkaXJlY3RvcnkgaW4gJGFjX2Rpcl9zdWZmaXguCisgIGFj
X3RvcF9idWlsZGRpcl9zdWI9YCRhc19lY2hvICIkYWNfZGlyX3N1ZmZpeCIgfCBzZWQgJ3N8L1te
XFwvXSp8Ly4ufGc7c3wvfHwnYAorICBjYXNlICRhY190b3BfYnVpbGRkaXJfc3ViIGluCisgICIi
KSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZpeD0gOzsKKyAgKikgIGFj
X3RvcF9idWlsZF9wcmVmaXg9JGFjX3RvcF9idWlsZGRpcl9zdWIvIDs7CisgIGVzYWMgOzsKK2Vz
YWMKK2FjX2Fic190b3BfYnVpbGRkaXI9JGFjX3B3ZAorYWNfYWJzX2J1aWxkZGlyPSRhY19wd2Qk
YWNfZGlyX3N1ZmZpeAorIyBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eToKK2FjX3RvcF9idWls
ZGRpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeAorCitjYXNlICRzcmNkaXIgaW4KKyAgLikgICMgV2Ug
YXJlIGJ1aWxkaW5nIGluIHBsYWNlLgorICAgIGFjX3NyY2Rpcj0uCisgICAgYWNfdG9wX3NyY2Rp
cj0kYWNfdG9wX2J1aWxkZGlyX3N1YgorICAgIGFjX2Fic190b3Bfc3JjZGlyPSRhY19wd2QgOzsK
KyAgW1xcL10qIHwgPzpbXFwvXSogKSAgIyBBYnNvbHV0ZSBuYW1lLgorICAgIGFjX3NyY2Rpcj0k
c3JjZGlyJGFjX2Rpcl9zdWZmaXg7CisgICAgYWNfdG9wX3NyY2Rpcj0kc3JjZGlyCisgICAgYWNf
YWJzX3RvcF9zcmNkaXI9JHNyY2RpciA7OworICAqKSAjIFJlbGF0aXZlIG5hbWUuCisgICAgYWNf
c3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpciRhY19kaXJfc3VmZml4CisgICAgYWNf
dG9wX3NyY2Rpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIKKyAgICBhY19hYnNfdG9wX3Ny
Y2Rpcj0kYWNfcHdkLyRzcmNkaXIgOzsKK2VzYWMKK2FjX2Fic19zcmNkaXI9JGFjX2Fic190b3Bf
c3JjZGlyJGFjX2Rpcl9zdWZmaXgKKworICAgIGNkICIkYWNfZGlyIiB8fCB7IGFjX3N0YXR1cz0k
PzsgY29udGludWU7IH0KKyAgICAjIENoZWNrIGZvciBndWVzdGVkIGNvbmZpZ3VyZS4KKyAgICBp
ZiB0ZXN0IC1mICIkYWNfc3JjZGlyL2NvbmZpZ3VyZS5nbnUiOyB0aGVuCisgICAgICBlY2hvICYm
CisgICAgICAkU0hFTEwgIiRhY19zcmNkaXIvY29uZmlndXJlLmdudSIgLS1oZWxwPXJlY3Vyc2l2
ZQorICAgIGVsaWYgdGVzdCAtZiAiJGFjX3NyY2Rpci9jb25maWd1cmUiOyB0aGVuCisgICAgICBl
Y2hvICYmCisgICAgICAkU0hFTEwgIiRhY19zcmNkaXIvY29uZmlndXJlIiAtLWhlbHA9cmVjdXJz
aXZlCisgICAgZWxzZQorICAgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogbm8gY29uZmln
dXJhdGlvbiBpbmZvcm1hdGlvbiBpcyBpbiAkYWNfZGlyIiA+JjIKKyAgICBmaSB8fCBhY19zdGF0
dXM9JD8KKyAgICBjZCAiJGFjX3B3ZCIgfHwgeyBhY19zdGF0dXM9JD87IGJyZWFrOyB9CisgIGRv
bmUKK2ZpCisKK3Rlc3QgLW4gIiRhY19pbml0X2hlbHAiICYmIGV4aXQgJGFjX3N0YXR1cworaWYg
JGFjX2luaXRfdmVyc2lvbjsgdGhlbgorICBjYXQgPDxcX0FDRU9GCitYZW4gSHlwZXJ2aXNvciBj
b25maWd1cmUgNC4yCitnZW5lcmF0ZWQgYnkgR05VIEF1dG9jb25mIDIuNjgKKworQ29weXJpZ2h0
IChDKSAyMDEwIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgorVGhpcyBjb25maWd1cmUg
c2NyaXB0IGlzIGZyZWUgc29mdHdhcmU7IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24KK2dp
dmVzIHVubGltaXRlZCBwZXJtaXNzaW9uIHRvIGNvcHksIGRpc3RyaWJ1dGUgYW5kIG1vZGlmeSBp
dC4KK19BQ0VPRgorICBleGl0CitmaQorCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMK
KyMjIEF1dG9jb25mIGluaXRpYWxpemF0aW9uLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tICMjCisKKyMgYWNfZm5fY190cnlfY29tcGlsZSBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGNvbXBpbGUgY29uZnRlc3QuJGFjX2V4dCwgYW5kIHJldHVy
biB3aGV0aGVyIHRoaXMgc3VjY2VlZGVkLgorYWNfZm5fY190cnlfY29tcGlsZSAoKQoreworICBh
c19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFj
az0kYXNfbGluZW5vX3N0YWNrCisgIHJtIC1mIGNvbmZ0ZXN0LiRhY19vYmpleHQKKyAgaWYgeyB7
IGFjX3RyeT0iJGFjX2NvbXBpbGUiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAq
IHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5
OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2
YWwgIiRhY19jb21waWxlIikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRl
c3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJy
ID5jb25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0
ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7
IH0gJiYgeworCSB0ZXN0IC16ICIkYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNv
bmZ0ZXN0LmVycgorICAgICAgIH0gJiYgdGVzdCAtcyBjb25mdGVzdC4kYWNfb2JqZXh0OyB0aGVu
IDoKKyAgYWNfcmV0dmFsPTAKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dy
YW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKKwlhY19y
ZXR2YWw9MQorZmkKKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazor
On0gdW5zZXQgYXNfbGluZW5vCisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAorCit9ICMg
YWNfZm5fY190cnlfY29tcGlsZQorCisjIGFjX2ZuX2NfdHJ5X2NwcCBMSU5FTk8KKyMgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gcHJlcHJvY2VzcyBjb25mdGVzdC4kYWNfZXh0LCBh
bmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuCithY19mbl9jX3RyeV9jcHAgKCkKK3sK
KyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9f
c3RhY2s9JGFzX2xpbmVub19zdGFjaworICBpZiB7IHsgYWNfdHJ5PSIkYWNfY3BwIGNvbmZ0ZXN0
LiRhY19leHQiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNf
dHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2
YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9l
Y2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19jcHAg
Y29uZnRlc3QuJGFjX2V4dCIpIDI+Y29uZnRlc3QuZXJyCisgIGFjX3N0YXR1cz0kPworICBpZiB0
ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgorICAgIGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0LmVy
ciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgICBtdiAtZiBjb25m
dGVzdC5lcjEgY29uZnRlc3QuZXJyCisgIGZpCisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAw
OyB9ID4gY29uZnRlc3QuaSAmJiB7CisJIHRlc3QgLXogIiRhY19jX3ByZXByb2Nfd2Fybl9mbGFn
JGFjX2Nfd2Vycm9yX2ZsYWciIHx8CisJIHRlc3QgISAtcyBjb25mdGVzdC5lcnIKKyAgICAgICB9
OyB0aGVuIDoKKyAgYWNfcmV0dmFsPTAKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVk
IHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisK
KyAgICBhY19yZXR2YWw9MQorZmkKKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVu
b19zdGFjazorOn0gdW5zZXQgYXNfbGluZW5vCisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZh
bAorCit9ICMgYWNfZm5fY190cnlfY3BwCisKKyMgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCBMSU5FTk8gSEVBREVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgSEVBREVSIGV4
aXN0cywgZ2l2aW5nIGEgd2FybmluZyBpZiBpdCBjYW5ub3QgYmUgY29tcGlsZWQgdXNpbmcKKyMg
dGhlIGluY2x1ZGUgZmlsZXMgaW4gSU5DTFVERVMgYW5kIHNldHRpbmcgdGhlIGNhY2hlIHZhcmlh
YmxlIFZBUgorIyBhY2NvcmRpbmdseS4KK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgKCkK
K3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5l
bm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICBpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVu
IDoKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBl
dmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+
JjY7IH0KK2Vsc2UKKyAgIyBJcyB0aGUgaGVhZGVyIGNvbXBpbGFibGU/Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nICQyIHVzYWJpbGl0eSIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyAkMiB1c2FiaWxpdHkuLi4gIiA+JjY7IH0KK2NhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KyQ0CisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfaGVhZGVyX2NvbXBpbGVyPXllcworZWxzZQorICBhY19oZWFkZXJf
Y29tcGlsZXI9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfaGVhZGVyX2NvbXBpbGVyIiA+JjUKKyRhc19lY2hvICIkYWNfaGVh
ZGVyX2NvbXBpbGVyIiA+JjY7IH0KKworIyBJcyB0aGUgaGVhZGVyIHByZXNlbnQ/Cit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nICQyIHByZXNlbmNlIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nICQyIHByZXNlbmNlLi4uICIgPiY2OyB9CitjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19oZWFkZXJfcHJlcHJvYz15ZXMKK2Vsc2UKKyAgYWNfaGVhZGVyX3ByZXBy
b2M9bm8KK2ZpCitybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2hl
YWRlcl9wcmVwcm9jIiA+JjUKKyRhc19lY2hvICIkYWNfaGVhZGVyX3ByZXByb2MiID4mNjsgfQor
CisjIFNvPyAgV2hhdCBhYm91dCB0aGlzIGhlYWRlcj8KK2Nhc2UgJGFjX2hlYWRlcl9jb21waWxl
cjokYWNfaGVhZGVyX3ByZXByb2M6JGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gIygoCisgIHll
czpubzogKQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogJDI6IGFjY2VwdGVkIGJ5IHRoZSBjb21waWxlciwgcmVqZWN0ZWQgYnkgdGhlIHByZXBy
b2Nlc3NvciEiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IGFjY2VwdGVkIGJ5
IHRoZSBjb21waWxlciwgcmVqZWN0ZWQgYnkgdGhlIHByZXByb2Nlc3NvciEiID4mMjt9CisgICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkMjogcHJv
Y2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBXQVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiYy
O30KKyAgICA7OworICBubzp5ZXM6KiApCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkMjogcHJlc2VudCBidXQgY2Fubm90IGJlIGNvbXBpbGVk
IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiBwcmVzZW50IGJ1dCBjYW5ub3Qg
YmUgY29tcGlsZWQiID4mMjt9CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiAkMjogICAgIGNoZWNrIGZvciBtaXNzaW5nIHByZXJlcXVpc2l0ZSBo
ZWFkZXJzPyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogICAgIGNoZWNrIGZv
ciBtaXNzaW5nIHByZXJlcXVpc2l0ZSBoZWFkZXJzPyIgPiYyO30KKyAgICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiBzZWUgdGhlIEF1dG9jb25m
IGRvY3VtZW50YXRpb24iID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IHNlZSB0
aGUgQXV0b2NvbmYgZG9jdW1lbnRhdGlvbiIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiAgICAgc2VjdGlvbiBcIlByZXNlbnQg
QnV0IENhbm5vdCBCZSBDb21waWxlZFwiIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
ICQyOiAgICAgc2VjdGlvbiBcIlByZXNlbnQgQnV0IENhbm5vdCBCZSBDb21waWxlZFwiIiA+JjI7
fQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzog
JDI6IHByb2NlZWRpbmcgd2l0aCB0aGUgY29tcGlsZXIncyByZXN1bHQiID4mNQorJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogJDI6IHByb2NlZWRpbmcgd2l0aCB0aGUgY29tcGlsZXIncyByZXN1
bHQiID4mMjt9CisoICRhc19lY2hvICIjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAjIworIyMgUmVwb3J0IHRoaXMgdG8geGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tICMjIgorICAgICApIHwgc2VkICJzL14vJGFzX21lOiBXQVJOSU5HOiAgICAgLyIgPiYyCisg
ICAgOzsKK2VzYWMKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2
OyB9CitpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgZXZhbCAiJDM9XCRhY19oZWFkZXJfY29tcGlsZXIiCitmaQorZXZh
bCBhY19yZXM9XCQkMworCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9Citm
aQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBh
c19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwKKworIyBhY19mbl9j
X3RyeV9ydW4gTElORU5PCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGxpbmsg
Y29uZnRlc3QuJGFjX2V4dCwgYW5kIHJldHVybiB3aGV0aGVyIHRoaXMgc3VjY2VlZGVkLiBBc3N1
bWVzCisjIHRoYXQgZXhlY3V0YWJsZXMgKmNhbiogYmUgcnVuLgorYWNfZm5fY190cnlfcnVuICgp
Cit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGlu
ZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCitj
YXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRh
Y190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2Vj
aG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNf
ZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQorICBh
Y19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/
ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeyBhY190cnk9
Jy4vY29uZnRlc3QkYWNfZXhlZXh0JworICB7IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIq
IHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89
JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1
CisgIChldmFsICIkYWNfdHJ5IikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3Qg
JGFjX3N0YXR1cyA9IDA7IH07IH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNf
ZWNobyAiJGFzX21lOiBwcm9ncmFtIGV4aXRlZCB3aXRoIHN0YXR1cyAkYWNfc3RhdHVzIiA+JjUK
KyAgICAgICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAn
cy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKworICAgICAgIGFjX3JldHZhbD0kYWNfc3Rh
dHVzCitmaQorICBybSAtcmYgY29uZnRlc3QuZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9v
CisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFz
X2xpbmVubworICBhc19mbl9zZXRfc3RhdHVzICRhY19yZXR2YWwKKworfSAjIGFjX2ZuX2NfdHJ5
X3J1bgorCisjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgTElORU5PIEhFQURFUiBWQVIg
SU5DTFVERVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQorIyBUZXN0cyB3aGV0aGVyIEhFQURFUiBleGlzdHMgYW5kIGNhbiBiZSBjb21w
aWxlZCB1c2luZyB0aGUgaW5jbHVkZSBmaWxlcyBpbgorIyBJTkNMVURFUywgc2V0dGluZyB0aGUg
Y2FjaGUgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja19oZWFkZXJfY29t
cGlsZSAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNr
PWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGZvciAkMi4uLiAiID4mNjsgfQoraWYgZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0Cisj
aW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgZXZhbCAiJDM9eWVzIgorZWxzZQorICBldmFsICIkMz1ubyIKK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2Zp
CitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7
IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0gdW5zZXQg
YXNfbGluZW5vCisKK30gIyBhY19mbl9jX2NoZWNrX2hlYWRlcl9jb21waWxlCisKKyMgYWNfZm5f
Y190cnlfbGluayBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGxp
bmsgY29uZnRlc3QuJGFjX2V4dCwgYW5kIHJldHVybiB3aGV0aGVyIHRoaXMgc3VjY2VlZGVkLgor
YWNfZm5fY190cnlfbGluayAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNf
bGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHJtIC1mIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QkYWNfZXhlZXh0CisgIGlmIHsgeyBhY190cnk9IiRh
Y19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3Ry
eV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFs
IGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNo
b1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfbGluayIp
IDI+Y29uZnRlc3QuZXJyCisgIGFjX3N0YXR1cz0kPworICBpZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVy
cjsgdGhlbgorICAgIGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisg
ICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgICBtdiAtZiBjb25mdGVzdC5lcjEgY29uZnRlc3Qu
ZXJyCisgIGZpCisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9
ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9ICYmIHsKKwkgdGVzdCAt
eiAiJGFjX2Nfd2Vycm9yX2ZsYWciIHx8CisJIHRlc3QgISAtcyBjb25mdGVzdC5lcnIKKyAgICAg
ICB9ICYmIHRlc3QgLXMgY29uZnRlc3QkYWNfZXhlZXh0ICYmIHsKKwkgdGVzdCAiJGNyb3NzX2Nv
bXBpbGluZyIgPSB5ZXMgfHwKKwkgJGFzX3Rlc3RfeCBjb25mdGVzdCRhY19leGVleHQKKyAgICAg
ICB9OyB0aGVuIDoKKyAgYWNfcmV0dmFsPTAKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFp
bGVkIHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1
CisKKwlhY19yZXR2YWw9MQorZmkKKyAgIyBEZWxldGUgdGhlIElQQS9JUE8gKEludGVyIFByb2Nl
ZHVyYWwgQW5hbHlzaXMvT3B0aW1pemF0aW9uKSBpbmZvcm1hdGlvbgorICAjIGNyZWF0ZWQgYnkg
dGhlIFBHSSBjb21waWxlciAoY29uZnRlc3RfaXBhOF9jb25mdGVzdC5vbyksIGFzIGl0IHdvdWxk
CisgICMgaW50ZXJmZXJlIHdpdGggdGhlIG5leHQgbGluayBjb21tYW5kOyBhbHNvIGRlbGV0ZSBh
IGRpcmVjdG9yeSB0aGF0IGlzCisgICMgbGVmdCBiZWhpbmQgYnkgQXBwbGUncyBjb21waWxlci4g
IFdlIGRvIHRoaXMgYmVmb3JlIGV4ZWN1dGluZyB0aGUgYWN0aW9ucy4KKyAgcm0gLXJmIGNvbmZ0
ZXN0LmRTWU0gY29uZnRlc3RfaXBhOF9jb25mdGVzdC5vbworICBldmFsICRhc19saW5lbm9fc3Rh
Y2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0
YXR1cyAkYWNfcmV0dmFsCisKK30gIyBhY19mbl9jX3RyeV9saW5rCisKKyMgYWNfZm5fY19jaGVj
a190eXBlIExJTkVOTyBUWVBFIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgVFlQRSBleGlzdHMgYWZ0ZXIg
aGF2aW5nIGluY2x1ZGVkIElOQ0xVREVTLCBzZXR0aW5nIGNhY2hlCisjIHZhcmlhYmxlIFZBUiBh
Y2NvcmRpbmdseS4KK2FjX2ZuX2NfY2hlY2tfdHlwZSAoKQoreworICBhc19saW5lbm89JHthc19s
aW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0
YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4uLiAiID4mNjsgfQoraWYg
ZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGV2YWwgIiQzPW5vIgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNAoraW50CittYWluICgpCit7
CitpZiAoc2l6ZW9mICgkMikpCisJIHJldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FD
RU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAg
Ki8KKyQ0CitpbnQKK21haW4gKCkKK3sKK2lmIChzaXplb2YgKCgkMikpKQorCSAgICByZXR1cm4g
MDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAi
JExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGV2YWwgIiQzPXllcyIKK2ZpCitybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCity
bSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVz
IiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0g
dW5zZXQgYXNfbGluZW5vCisKK30gIyBhY19mbl9jX2NoZWNrX3R5cGUKKworIyBhY19mbl9jX2No
ZWNrX2Z1bmMgTElORU5PIEZVTkMgVkFSCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KKyMgVGVzdHMgd2hldGhlciBGVU5DIGV4aXN0cywgc2V0dGluZyB0aGUgY2FjaGUgdmFy
aWFibGUgVkFSIGFjY29yZGluZ2x5CithY19mbl9jX2NoZWNrX2Z1bmMgKCkKK3sKKyAgYXNfbGlu
ZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFz
X2xpbmVub19zdGFjaworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+
JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisvKiBEZWZpbmUgJDIgdG8gYW4gaW5ub2N1
b3VzIHZhcmlhbnQsIGluIGNhc2UgPGxpbWl0cy5oPiBkZWNsYXJlcyAkMi4KKyAgIEZvciBleGFt
cGxlLCBIUC1VWCAxMWkgPGxpbWl0cy5oPiBkZWNsYXJlcyBnZXR0aW1lb2ZkYXkuICAqLworI2Rl
ZmluZSAkMiBpbm5vY3VvdXNfJDIKKworLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHVi
IG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLAorICAgIHdoaWNoIGNhbiBjb25m
bGljdCB3aXRoIGNoYXIgJDIgKCk7IGJlbG93LgorICAgIFByZWZlciA8bGltaXRzLmg+IHRvIDxh
c3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgICA8bGltaXRzLmg+IGV4
aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuICAqLworCisjaWZkZWYgX19TVERD
X18KKyMgaW5jbHVkZSA8bGltaXRzLmg+CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNl
bmRpZgorCisjdW5kZWYgJDIKKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5
cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRj
aCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt
ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMK
K2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciAkMiAoKTsKKy8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRl
ZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMKKyAgICB0byBhbHdh
eXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZAor
ICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4g
YWxpYXMuICAqLworI2lmIGRlZmluZWQgX19zdHViXyQyIHx8IGRlZmluZWQgX19zdHViX19fJDIK
K2Nob2tlIG1lCisjZW5kaWYKKworaW50CittYWluICgpCit7CityZXR1cm4gJDIgKCk7CisgIDsK
KyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgZXZhbCAiJDM9eWVzIgorZWxzZQorICBldmFsICIkMz1ubyIKK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4m
NQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7
YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tf
ZnVuYworCisjIGFjX2ZuX2NfZmluZF9pbnRYX3QgTElORU5PIEJJVFMgVkFSCisjIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIEZpbmRzIGEgc2lnbmVkIGludGVnZXIgdHlw
ZSB3aXRoIHdpZHRoIEJJVFMsIHNldHRpbmcgY2FjaGUgdmFyaWFibGUgVkFSCisjIGFjY29yZGlu
Z2x5LgorYWNfZm5fY19maW5kX2ludFhfdCAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8t
IiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlu
dCQyX3QiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGludCQyX3QuLi4gIiA+JjY7IH0K
K2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBldmFsICIkMz1ubyIKKyAgICAgIyBPcmRlciBpcyBpbXBvcnRhbnQgLSBu
ZXZlciBjaGVjayBhIHR5cGUgdGhhdCBpcyBwb3RlbnRpYWxseSBzbWFsbGVyCisgICAgICMgdGhh
biBoYWxmIG9mIHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCisgICAgIGZvciBhY190eXBlIGlu
IGludCQyX3QgJ2ludCcgJ2xvbmcgaW50JyBcCisJICdsb25nIGxvbmcgaW50JyAnc2hvcnQgaW50
JyAnc2lnbmVkIGNoYXInOyBkbworICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZh
dWx0CisJICAgICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKK2ludAorbWFpbiAoKQoreworc3Rh
dGljIGludCB0ZXN0X2FycmF5IFsxIC0gMiAqICEoMCA8ICgkYWNfdHlwZSkgKCgoKCgkYWNfdHlw
ZSkgMSA8PCBOKSA8PCBOKSAtIDEpICogMiArIDEpKV07Cit0ZXN0X2FycmF5IFswXSA9IDAKKwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisJICAgICAg
ICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKK2ludAorbWFpbiAoKQoreworc3RhdGljIGludCB0
ZXN0X2FycmF5IFsxIC0gMiAqICEoKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAxIDw8IE4pIDw8
IE4pIC0gMSkgKiAyICsgMSkKKwkJIDwgKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAxIDw8IE4p
IDw8IE4pIC0gMSkgKiAyICsgMikpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsKKyAgcmV0
dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVu
IDoKKworZWxzZQorICBjYXNlICRhY190eXBlIGluICMoCisgIGludCQyX3QpIDoKKyAgICBldmFs
ICIkMz15ZXMiIDs7ICMoCisgICopIDoKKyAgICBldmFsICIkMz1cJGFjX3R5cGUiIDs7Citlc2Fj
CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVz
dC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CisgICAgICAgaWYgZXZhbCB0ZXN0IFwieFwkIiQzIlwiID0geCJu
byI7IHRoZW4gOgorCitlbHNlCisgIGJyZWFrCitmaQorICAgICBkb25lCitmaQorZXZhbCBhY19y
ZXM9XCQkMworCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwg
JGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubwor
Cit9ICMgYWNfZm5fY19maW5kX2ludFhfdAorCisjIGFjX2ZuX2NfY2hlY2tfbWVtYmVyIExJTkVO
TyBBR0dSIE1FTUJFUiBWQVIgSU5DTFVERVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcmllcyB0byBmaW5kIGlmIHRoZSBmaWVsZCBN
RU1CRVIgZXhpc3RzIGluIHR5cGUgQUdHUiwgYWZ0ZXIgaW5jbHVkaW5nCisjIElOQ0xVREVTLCBz
ZXR0aW5nIGNhY2hlIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KK2FjX2ZuX2NfY2hlY2tfbWVt
YmVyICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9
YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIuJDMiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICQyLiQzLi4uICIgPiY2OyB9CitpZiBldmFsIFwkeyQ0Kzp9IGZhbHNlOyB0
aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
JDUKK2ludAorbWFpbiAoKQoreworc3RhdGljICQyIGFjX2FnZ3I7CitpZiAoYWNfYWdnci4kMykK
K3JldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9j
b21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGV2YWwgIiQ0PXllcyIKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworJDUKK2ludAorbWFpbiAoKQoreworc3RhdGljICQyIGFjX2FnZ3I7CitpZiAoc2l6ZW9m
IGFjX2FnZ3IuJDMpCityZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYg
YWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBldmFsICIkND15ZXMiCitl
bHNlCisgIGV2YWwgIiQ0PW5vIgorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK2V2YWwgYWNfcmVzPVwk
JDQKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQorICBldmFsICRhc19s
aW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKworfSAj
IGFjX2ZuX2NfY2hlY2tfbWVtYmVyCisKKyMgYWNfZm5fY19maW5kX3VpbnRYX3QgTElORU5PIEJJ
VFMgVkFSCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBGaW5kcyBh
biB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgd2l0aCB3aWR0aCBCSVRTLCBzZXR0aW5nIGNhY2hlIHZh
cmlhYmxlIFZBUgorIyBhY2NvcmRpbmdseS4KK2FjX2ZuX2NfZmluZF91aW50WF90ICgpCit7Cisg
IGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0
YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgdWludCQyX3QiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHVpbnQkMl90Li4uICIgPiY2OyB9CitpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgZXZhbCAiJDM9bm8iCisgICAg
ICMgT3JkZXIgaXMgaW1wb3J0YW50IC0gbmV2ZXIgY2hlY2sgYSB0eXBlIHRoYXQgaXMgcG90ZW50
aWFsbHkgc21hbGxlcgorICAgICAjIHRoYW4gaGFsZiBvZiB0aGUgZXhwZWN0ZWQgdGFyZ2V0IHdp
ZHRoLgorICAgICBmb3IgYWNfdHlwZSBpbiB1aW50JDJfdCAndW5zaWduZWQgaW50JyAndW5zaWdu
ZWQgbG9uZyBpbnQnIFwKKwkgJ3Vuc2lnbmVkIGxvbmcgbG9uZyBpbnQnICd1bnNpZ25lZCBzaG9y
dCBpbnQnICd1bnNpZ25lZCBjaGFyJzsgZG8KKyAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVk
ZXNfZGVmYXVsdAoraW50CittYWluICgpCit7CitzdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAy
ICogISgoKCRhY190eXBlKSAtMSA+PiAoJDIgLyAyIC0gMSkpID4+ICgkMiAvIDIgLSAxKSA9PSAz
KV07Cit0ZXN0X2FycmF5IFswXSA9IDAKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGNhc2UgJGFjX3R5cGUg
aW4gIygKKyAgdWludCQyX3QpIDoKKyAgICBldmFsICIkMz15ZXMiIDs7ICMoCisgICopIDoKKyAg
ICBldmFsICIkMz1cJGFjX3R5cGUiIDs7Citlc2FjCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICAgICAgaWYgZXZhbCB0
ZXN0IFwieFwkIiQzIlwiID0geCJubyI7IHRoZW4gOgorCitlbHNlCisgIGJyZWFrCitmaQorICAg
ICBkb25lCitmaQorZXZhbCBhY19yZXM9XCQkMworCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFj
X3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6
Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNfZm5fY19maW5kX3VpbnRYX3QKK2NhdCA+Y29u
ZmlnLmxvZyA8PF9BQ0VPRgorVGhpcyBmaWxlIGNvbnRhaW5zIGFueSBtZXNzYWdlcyBwcm9kdWNl
ZCBieSBjb21waWxlcnMgd2hpbGUKK3J1bm5pbmcgY29uZmlndXJlLCB0byBhaWQgZGVidWdnaW5n
IGlmIGNvbmZpZ3VyZSBtYWtlcyBhIG1pc3Rha2UuCisKK0l0IHdhcyBjcmVhdGVkIGJ5IFhlbiBI
eXBlcnZpc29yICRhc19tZSA0LjIsIHdoaWNoIHdhcworZ2VuZXJhdGVkIGJ5IEdOVSBBdXRvY29u
ZiAyLjY4LiAgSW52b2NhdGlvbiBjb21tYW5kIGxpbmUgd2FzCisKKyAgJCAkMCAkQAorCitfQUNF
T0YKK2V4ZWMgNT4+Y29uZmlnLmxvZworeworY2F0IDw8X0FTVU5BTUUKKyMjIC0tLS0tLS0tLSAj
IworIyMgUGxhdGZvcm0uICMjCisjIyAtLS0tLS0tLS0gIyMKKworaG9zdG5hbWUgPSBgKGhvc3Ru
YW1lIHx8IHVuYW1lIC1uKSAyPi9kZXYvbnVsbCB8IHNlZCAxcWAKK3VuYW1lIC1tID0gYCh1bmFt
ZSAtbSkgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXIgPSBgKHVuYW1lIC1y
KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtcyA9IGAodW5hbWUgLXMpIDI+
L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC12ID0gYCh1bmFtZSAtdikgMj4vZGV2
L251bGwgfHwgZWNobyB1bmtub3duYAorCisvdXNyL2Jpbi91bmFtZSAtcCA9IGAoL3Vzci9iaW4v
dW5hbWUgLXApIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vdW5hbWUgLVggICAg
ID0gYCgvYmluL3VuYW1lIC1YKSAyPi9kZXYvbnVsbCAgICAgfHwgZWNobyB1bmtub3duYAorCisv
YmluL2FyY2ggICAgICAgICAgICAgID0gYCgvYmluL2FyY2gpIDI+L2Rldi9udWxsICAgICAgICAg
ICAgICB8fCBlY2hvIHVua25vd25gCisvdXNyL2Jpbi9hcmNoIC1rICAgICAgID0gYCgvdXNyL2Jp
bi9hcmNoIC1rKSAyPi9kZXYvbnVsbCAgICAgICB8fCBlY2hvIHVua25vd25gCisvdXNyL2NvbnZl
eC9nZXRzeXNpbmZvID0gYCgvdXNyL2NvbnZleC9nZXRzeXNpbmZvKSAyPi9kZXYvbnVsbCB8fCBl
Y2hvIHVua25vd25gCisvdXNyL2Jpbi9ob3N0aW5mbyAgICAgID0gYCgvdXNyL2Jpbi9ob3N0aW5m
bykgMj4vZGV2L251bGwgICAgICB8fCBlY2hvIHVua25vd25gCisvYmluL21hY2hpbmUgICAgICAg
ICAgID0gYCgvYmluL21hY2hpbmUpIDI+L2Rldi9udWxsICAgICAgICAgICB8fCBlY2hvIHVua25v
d25gCisvdXNyL2Jpbi9vc2xldmVsICAgICAgID0gYCgvdXNyL2Jpbi9vc2xldmVsKSAyPi9kZXYv
bnVsbCAgICAgICB8fCBlY2hvIHVua25vd25gCisvYmluL3VuaXZlcnNlICAgICAgICAgID0gYCgv
YmluL3VuaXZlcnNlKSAyPi9kZXYvbnVsbCAgICAgICAgICB8fCBlY2hvIHVua25vd25gCisKK19B
U1VOQU1FCisKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICAkYXNfZWNobyAiUEFUSDogJGFzX2RpciIKKyAgZG9uZQorSUZTPSRh
c19zYXZlX0lGUworCit9ID4mNQorCitjYXQgPiY1IDw8X0FDRU9GCisKKworIyMgLS0tLS0tLS0t
LS0gIyMKKyMjIENvcmUgdGVzdHMuICMjCisjIyAtLS0tLS0tLS0tLSAjIworCitfQUNFT0YKKwor
CisjIEtlZXAgYSB0cmFjZSBvZiB0aGUgY29tbWFuZCBsaW5lLgorIyBTdHJpcCBvdXQgLS1uby1j
cmVhdGUgYW5kIC0tbm8tcmVjdXJzaW9uIHNvIHRoZXkgZG8gbm90IHBpbGUgdXAuCisjIFN0cmlw
IG91dCAtLXNpbGVudCBiZWNhdXNlIHdlIGRvbid0IHdhbnQgdG8gcmVjb3JkIGl0IGZvciBmdXR1
cmUgcnVucy4KKyMgQWxzbyBxdW90ZSBhbnkgYXJncyBjb250YWluaW5nIHNoZWxsIG1ldGEtY2hh
cmFjdGVycy4KKyMgTWFrZSB0d28gcGFzc2VzIHRvIGFsbG93IGZvciBwcm9wZXIgZHVwbGljYXRl
LWFyZ3VtZW50IHN1cHByZXNzaW9uLgorYWNfY29uZmlndXJlX2FyZ3M9CithY19jb25maWd1cmVf
YXJnczA9CithY19jb25maWd1cmVfYXJnczE9CithY19tdXN0X2tlZXBfbmV4dD1mYWxzZQorZm9y
IGFjX3Bhc3MgaW4gMSAyCitkbworICBmb3IgYWNfYXJnCisgIGRvCisgICAgY2FzZSAkYWNfYXJn
IGluCisgICAgLW5vLWNyZWF0ZSB8IC0tbm8tYyogfCAtbiB8IC1uby1yZWN1cnNpb24gfCAtLW5v
LXIqKSBjb250aW51ZSA7OworICAgIC1xIHwgLXF1aWV0IHwgLS1xdWlldCB8IC0tcXVpZSB8IC0t
cXVpIHwgLS1xdSB8IC0tcSBcCisgICAgfCAtc2lsZW50IHwgLS1zaWxlbnQgfCAtLXNpbGVuIHwg
LS1zaWxlIHwgLS1zaWwpCisgICAgICBjb250aW51ZSA7OworICAgICpcJyopCisgICAgICBhY19h
cmc9YCRhc19lY2hvICIkYWNfYXJnIiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYCA7OworICAg
IGVzYWMKKyAgICBjYXNlICRhY19wYXNzIGluCisgICAgMSkgYXNfZm5fYXBwZW5kIGFjX2NvbmZp
Z3VyZV9hcmdzMCAiICckYWNfYXJnJyIgOzsKKyAgICAyKQorICAgICAgYXNfZm5fYXBwZW5kIGFj
X2NvbmZpZ3VyZV9hcmdzMSAiICckYWNfYXJnJyIKKyAgICAgIGlmIHRlc3QgJGFjX211c3Rfa2Vl
cF9uZXh0ID0gdHJ1ZTsgdGhlbgorCWFjX211c3Rfa2VlcF9uZXh0PWZhbHNlICMgR290IHZhbHVl
LCBiYWNrIHRvIG5vcm1hbC4KKyAgICAgIGVsc2UKKwljYXNlICRhY19hcmcgaW4KKwkgICo9KiB8
IC0tY29uZmlnLWNhY2hlIHwgLUMgfCAtZGlzYWJsZS0qIHwgLS1kaXNhYmxlLSogXAorCSAgfCAt
ZW5hYmxlLSogfCAtLWVuYWJsZS0qIHwgLWdhcyB8IC0tZyogfCAtbmZwIHwgLS1uZiogXAorCSAg
fCAtcSB8IC1xdWlldCB8IC0tcSogfCAtc2lsZW50IHwgLS1zaWwqIHwgLXYgfCAtdmVyYiogXAor
CSAgfCAtd2l0aC0qIHwgLS13aXRoLSogfCAtd2l0aG91dC0qIHwgLS13aXRob3V0LSogfCAtLXgp
CisJICAgIGNhc2UgIiRhY19jb25maWd1cmVfYXJnczAgIiBpbgorCSAgICAgICIkYWNfY29uZmln
dXJlX2FyZ3MxIioiICckYWNfYXJnJyAiKiApIGNvbnRpbnVlIDs7CisJICAgIGVzYWMKKwkgICAg
OzsKKwkgIC0qICkgYWNfbXVzdF9rZWVwX25leHQ9dHJ1ZSA7OworCWVzYWMKKyAgICAgIGZpCisg
ICAgICBhc19mbl9hcHBlbmQgYWNfY29uZmlndXJlX2FyZ3MgIiAnJGFjX2FyZyciCisgICAgICA7
OworICAgIGVzYWMKKyAgZG9uZQorZG9uZQoreyBhY19jb25maWd1cmVfYXJnczA9OyB1bnNldCBh
Y19jb25maWd1cmVfYXJnczA7fQoreyBhY19jb25maWd1cmVfYXJnczE9OyB1bnNldCBhY19jb25m
aWd1cmVfYXJnczE7fQorCisjIFdoZW4gaW50ZXJydXB0ZWQgb3IgZXhpdCdkLCBjbGVhbnVwIHRl
bXBvcmFyeSBmaWxlcywgYW5kIGNvbXBsZXRlCisjIGNvbmZpZy5sb2cuICBXZSByZW1vdmUgY29t
bWVudHMgYmVjYXVzZSBhbnl3YXkgdGhlIHF1b3RlcyBpbiB0aGVyZQorIyB3b3VsZCBjYXVzZSBw
cm9ibGVtcyBvciBsb29rIHVnbHkuCisjIFdBUk5JTkc6IFVzZSAnXCcnIHRvIHJlcHJlc2VudCBh
biBhcG9zdHJvcGhlIHdpdGhpbiB0aGUgdHJhcC4KKyMgV0FSTklORzogRG8gbm90IHN0YXJ0IHRo
ZSB0cmFwIGNvZGUgd2l0aCBhIG5ld2xpbmUsIGR1ZSB0byBhIEZyZWVCU0QgNC4wIGJ1Zy4KK3Ry
YXAgJ2V4aXRfc3RhdHVzPSQ/CisgICMgU2F2ZSBpbnRvIGNvbmZpZy5sb2cgc29tZSBpbmZvcm1h
dGlvbiB0aGF0IG1pZ2h0IGhlbHAgaW4gZGVidWdnaW5nLgorICB7CisgICAgZWNobworCisgICAg
JGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIENhY2hlIHZhcmlhYmxlcy4gIyMK
KyMjIC0tLS0tLS0tLS0tLS0tLS0gIyMiCisgICAgZWNobworICAgICMgVGhlIGZvbGxvd2luZyB3
YXkgb2Ygd3JpdGluZyB0aGUgY2FjaGUgbWlzaGFuZGxlcyBuZXdsaW5lcyBpbiB2YWx1ZXMsCiso
CisgIGZvciBhY192YXIgaW4gYChzZXQpIDI+JjEgfCBzZWQgLW4gJ1wnJ3MvXlwoW2EtekEtWl9d
W2EtekEtWjAtOV9dKlwpPS4qL1wxL3AnXCcnYDsgZG8KKyAgICBldmFsIGFjX3ZhbD1cJCRhY192
YXIKKyAgICBjYXNlICRhY192YWwgaW4gIygKKyAgICAqJHthc19ubH0qKQorICAgICAgY2FzZSAk
YWNfdmFyIGluICMoCisgICAgICAqX2N2XyopIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogV0FSTklORzogY2FjaGUgdmFyaWFibGUgJGFjX3ZhciBjb250YWlucyBhIG5l
d2xpbmUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogY2FjaGUgdmFyaWFibGUgJGFj
X3ZhciBjb250YWlucyBhIG5ld2xpbmUiID4mMjt9IDs7CisgICAgICBlc2FjCisgICAgICBjYXNl
ICRhY192YXIgaW4gIygKKyAgICAgIF8gfCBJRlMgfCBhc19ubCkgOzsgIygKKyAgICAgIEJBU0hf
QVJHViB8IEJBU0hfU09VUkNFKSBldmFsICRhY192YXI9IDs7ICMoCisgICAgICAqKSB7IGV2YWwg
JGFjX3Zhcj07IHVuc2V0ICRhY192YXI7fSA7OworICAgICAgZXNhYyA7OworICAgIGVzYWMKKyAg
ZG9uZQorICAoc2V0KSAyPiYxIHwKKyAgICBjYXNlICRhc19ubGAoYWNfc3BhY2U9J1wnJyAnXCcn
OyBzZXQpIDI+JjFgIGluICMoCisgICAgKiR7YXNfbmx9YWNfc3BhY2U9XCAqKQorICAgICAgc2Vk
IC1uIFwKKwkicy8nXCcnLydcJydcXFxcJ1wnJydcJycvZzsKKwkgIHMvXlxcKFtfJGFzX2NyX2Fs
bnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKlxcKT1cXCguKlxcKS9cXDE9J1wnJ1xcMidcJycvcCIK
KyAgICAgIDs7ICMoCisgICAgKikKKyAgICAgIHNlZCAtbiAiL15bXyRhc19jcl9hbG51bV0qX2N2
X1tfJGFzX2NyX2FsbnVtXSo9L3AiCisgICAgICA7OworICAgIGVzYWMgfAorICAgIHNvcnQKKykK
KyAgICBlY2hvCisKKyAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE91
dHB1dCB2YXJpYWJsZXMuICMjCisjIyAtLS0tLS0tLS0tLS0tLS0tLSAjIyIKKyAgICBlY2hvCisg
ICAgZm9yIGFjX3ZhciBpbiAkYWNfc3Vic3RfdmFycworICAgIGRvCisgICAgICBldmFsIGFjX3Zh
bD1cJCRhY192YXIKKyAgICAgIGNhc2UgJGFjX3ZhbCBpbgorICAgICAgKlwnXCcnKikgYWNfdmFs
PWAkYXNfZWNobyAiJGFjX3ZhbCIgfCBzZWQgInMvJ1wnJy8nXCcnXFxcXFxcXFwnXCcnJ1wnJy9n
ImA7OworICAgICAgZXNhYworICAgICAgJGFzX2VjaG8gIiRhY192YXI9J1wnJyRhY192YWwnXCcn
IgorICAgIGRvbmUgfCBzb3J0CisgICAgZWNobworCisgICAgaWYgdGVzdCAtbiAiJGFjX3N1YnN0
X2ZpbGVzIjsgdGhlbgorICAgICAgJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0tLS0gIyMK
KyMjIEZpbGUgc3Vic3RpdHV0aW9ucy4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0gIyMiCisg
ICAgICBlY2hvCisgICAgICBmb3IgYWNfdmFyIGluICRhY19zdWJzdF9maWxlcworICAgICAgZG8K
KwlldmFsIGFjX3ZhbD1cJCRhY192YXIKKwljYXNlICRhY192YWwgaW4KKwkqXCdcJycqKSBhY192
YWw9YCRhc19lY2hvICIkYWNfdmFsIiB8IHNlZCAicy8nXCcnLydcJydcXFxcXFxcXCdcJycnXCcn
L2ciYDs7CisJZXNhYworCSRhc19lY2hvICIkYWNfdmFyPSdcJyckYWNfdmFsJ1wnJyIKKyAgICAg
IGRvbmUgfCBzb3J0CisgICAgICBlY2hvCisgICAgZmkKKworICAgIGlmIHRlc3QgLXMgY29uZmRl
ZnMuaDsgdGhlbgorICAgICAgJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tICMjCisjIyBjb25mZGVm
cy5oLiAjIworIyMgLS0tLS0tLS0tLS0gIyMiCisgICAgICBlY2hvCisgICAgICBjYXQgY29uZmRl
ZnMuaAorICAgICAgZWNobworICAgIGZpCisgICAgdGVzdCAiJGFjX3NpZ25hbCIgIT0gMCAmJgor
ICAgICAgJGFzX2VjaG8gIiRhc19tZTogY2F1Z2h0IHNpZ25hbCAkYWNfc2lnbmFsIgorICAgICRh
c19lY2hvICIkYXNfbWU6IGV4aXQgJGV4aXRfc3RhdHVzIgorICB9ID4mNQorICBybSAtZiBjb3Jl
ICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogJiYKKyAgICBybSAtZiAtciBjb25mdGVzdCogY29uZmRl
ZnMqIGNvbmYkJCogJGFjX2NsZWFuX2ZpbGVzICYmCisgICAgZXhpdCAkZXhpdF9zdGF0dXMKKycg
MAorZm9yIGFjX3NpZ25hbCBpbiAxIDIgMTMgMTU7IGRvCisgIHRyYXAgJ2FjX3NpZ25hbD0nJGFj
X3NpZ25hbCc7IGFzX2ZuX2V4aXQgMScgJGFjX3NpZ25hbAorZG9uZQorYWNfc2lnbmFsPTAKKwor
IyBjb25mZGVmcy5oIGF2b2lkcyBPUyBjb21tYW5kIGxpbmUgbGVuZ3RoIGxpbWl0cyB0aGF0IERF
RlMgY2FuIGV4Y2VlZC4KK3JtIC1mIC1yIGNvbmZ0ZXN0KiBjb25mZGVmcy5oCisKKyRhc19lY2hv
ICIvKiBjb25mZGVmcy5oICovIiA+IGNvbmZkZWZzLmgKKworIyBQcmVkZWZpbmVkIHByZXByb2Nl
c3NvciB2YXJpYWJsZXMuCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFD
S0FHRV9OQU1FICIkUEFDS0FHRV9OQU1FIgorX0FDRU9GCisKK2NhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9UQVJOQU1FICIkUEFDS0FHRV9UQVJOQU1FIgorX0FDRU9G
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9WRVJTSU9OICIk
UEFDS0FHRV9WRVJTSU9OIgorX0FDRU9GCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgUEFDS0FHRV9TVFJJTkcgIiRQQUNLQUdFX1NUUklORyIKK19BQ0VPRgorCitjYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICIkUEFDS0FHRV9C
VUdSRVBPUlQiCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQ
QUNLQUdFX1VSTCAiJFBBQ0tBR0VfVVJMIgorX0FDRU9GCisKKworIyBMZXQgdGhlIHNpdGUgZmls
ZSBzZWxlY3QgYW4gYWx0ZXJuYXRlIGNhY2hlIGZpbGUgaWYgaXQgd2FudHMgdG8uCisjIFByZWZl
ciBhbiBleHBsaWNpdGx5IHNlbGVjdGVkIGZpbGUgdG8gYXV0b21hdGljYWxseSBzZWxlY3RlZCBv
bmVzLgorYWNfc2l0ZV9maWxlMT1OT05FCithY19zaXRlX2ZpbGUyPU5PTkUKK2lmIHRlc3QgLW4g
IiRDT05GSUdfU0lURSI7IHRoZW4KKyAgIyBXZSBkbyBub3Qgd2FudCBhIFBBVEggc2VhcmNoIGZv
ciBjb25maWcuc2l0ZS4KKyAgY2FzZSAkQ09ORklHX1NJVEUgaW4gIygoCisgICAgLSopICBhY19z
aXRlX2ZpbGUxPS4vJENPTkZJR19TSVRFOzsKKyAgICAqLyopIGFjX3NpdGVfZmlsZTE9JENPTkZJ
R19TSVRFOzsKKyAgICAqKSAgIGFjX3NpdGVfZmlsZTE9Li8kQ09ORklHX1NJVEU7OworICBlc2Fj
CitlbGlmIHRlc3QgIngkcHJlZml4IiAhPSB4Tk9ORTsgdGhlbgorICBhY19zaXRlX2ZpbGUxPSRw
cmVmaXgvc2hhcmUvY29uZmlnLnNpdGUKKyAgYWNfc2l0ZV9maWxlMj0kcHJlZml4L2V0Yy9jb25m
aWcuc2l0ZQorZWxzZQorICBhY19zaXRlX2ZpbGUxPSRhY19kZWZhdWx0X3ByZWZpeC9zaGFyZS9j
b25maWcuc2l0ZQorICBhY19zaXRlX2ZpbGUyPSRhY19kZWZhdWx0X3ByZWZpeC9ldGMvY29uZmln
LnNpdGUKK2ZpCitmb3IgYWNfc2l0ZV9maWxlIGluICIkYWNfc2l0ZV9maWxlMSIgIiRhY19zaXRl
X2ZpbGUyIgorZG8KKyAgdGVzdCAieCRhY19zaXRlX2ZpbGUiID0geE5PTkUgJiYgY29udGludWUK
KyAgaWYgdGVzdCAvZGV2L251bGwgIT0gIiRhY19zaXRlX2ZpbGUiICYmIHRlc3QgLXIgIiRhY19z
aXRlX2ZpbGUiOyB0aGVuCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBsb2FkaW5nIHNpdGUgc2NyaXB0ICRhY19zaXRlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRh
c19tZTogbG9hZGluZyBzaXRlIHNjcmlwdCAkYWNfc2l0ZV9maWxlIiA+JjY7fQorICAgIHNlZCAn
cy9eL3wgLycgIiRhY19zaXRlX2ZpbGUiID4mNQorICAgIC4gIiRhY19zaXRlX2ZpbGUiIFwKKyAg
ICAgIHx8IHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjog
aW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3
ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gImZhaWxlZCB0byBsb2FkIHNpdGUgc2NyaXB0ICRh
Y19zaXRlX2ZpbGUKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5P
IiA1OyB9CisgIGZpCitkb25lCisKK2lmIHRlc3QgLXIgIiRjYWNoZV9maWxlIjsgdGhlbgorICAj
IFNvbWUgdmVyc2lvbnMgb2YgYmFzaCB3aWxsIGZhaWwgdG8gc291cmNlIC9kZXYvbnVsbCAoc3Bl
Y2lhbCBmaWxlcworICAjIGFjdHVhbGx5KSwgc28gd2UgYXZvaWQgZG9pbmcgdGhhdC4gIERKR1BQ
IGVtdWxhdGVzIGl0IGFzIGEgcmVndWxhciBmaWxlLgorICBpZiB0ZXN0IC9kZXYvbnVsbCAhPSAi
JGNhY2hlX2ZpbGUiICYmIHRlc3QgLWYgIiRjYWNoZV9maWxlIjsgdGhlbgorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogbG9hZGluZyBjYWNoZSAkY2FjaGVfZmls
ZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBsb2FkaW5nIGNhY2hlICRjYWNoZV9maWxlIiA+JjY7
fQorICAgIGNhc2UgJGNhY2hlX2ZpbGUgaW4KKyAgICAgIFtcXC9dKiB8ID86W1xcL10qICkgLiAi
JGNhY2hlX2ZpbGUiOzsKKyAgICAgICopICAgICAgICAgICAgICAgICAgICAgIC4gIi4vJGNhY2hl
X2ZpbGUiOzsKKyAgICBlc2FjCisgIGZpCitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY3JlYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogY3JlYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9CisgID4kY2FjaGVf
ZmlsZQorZmkKKworYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3lzL3RpbWUuaCIKK2Fz
X2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHVuaXN0ZC5oIgorYXNfZm5fYXBwZW5kIGFjX2Z1
bmNfbGlzdCAiIGFsYXJtIgorYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3RkbGliLmgi
Cithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMvcGFyYW0uaCIKKyMgQ2hlY2sgdGhh
dCB0aGUgcHJlY2lvdXMgdmFyaWFibGVzIHNhdmVkIGluIHRoZSBjYWNoZSBoYXZlIGtlcHQgdGhl
IHNhbWUKKyMgdmFsdWUuCithY19jYWNoZV9jb3JydXB0ZWQ9ZmFsc2UKK2ZvciBhY192YXIgaW4g
JGFjX3ByZWNpb3VzX3ZhcnM7IGRvCisgIGV2YWwgYWNfb2xkX3NldD1cJGFjX2N2X2Vudl8ke2Fj
X3Zhcn1fc2V0CisgIGV2YWwgYWNfbmV3X3NldD1cJGFjX2Vudl8ke2FjX3Zhcn1fc2V0CisgIGV2
YWwgYWNfb2xkX3ZhbD1cJGFjX2N2X2Vudl8ke2FjX3Zhcn1fdmFsdWUKKyAgZXZhbCBhY19uZXdf
dmFsPVwkYWNfZW52XyR7YWNfdmFyfV92YWx1ZQorICBjYXNlICRhY19vbGRfc2V0LCRhY19uZXdf
c2V0IGluCisgICAgc2V0LCkKKyAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZXJyb3I6IFxgJGFjX3Zhcicgd2FzIHNldCB0byBcYCRhY19vbGRfdmFsJyBpbiB0
aGUgcHJldmlvdXMgcnVuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBcYCRhY192YXIn
IHdhcyBzZXQgdG8gXGAkYWNfb2xkX3ZhbCcgaW4gdGhlIHByZXZpb3VzIHJ1biIgPiYyO30KKyAg
ICAgIGFjX2NhY2hlX2NvcnJ1cHRlZD06IDs7CisgICAgLHNldCkKKyAgICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IFxgJGFjX3Zhcicgd2FzIG5vdCBz
ZXQgaW4gdGhlIHByZXZpb3VzIHJ1biIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogXGAk
YWNfdmFyJyB3YXMgbm90IHNldCBpbiB0aGUgcHJldmlvdXMgcnVuIiA+JjI7fQorICAgICAgYWNf
Y2FjaGVfY29ycnVwdGVkPTogOzsKKyAgICAsKTs7CisgICAgKikKKyAgICAgIGlmIHRlc3QgIngk
YWNfb2xkX3ZhbCIgIT0gIngkYWNfbmV3X3ZhbCI7IHRoZW4KKwkjIGRpZmZlcmVuY2VzIGluIHdo
aXRlc3BhY2UgZG8gbm90IGxlYWQgdG8gZmFpbHVyZS4KKwlhY19vbGRfdmFsX3c9YGVjaG8geCAk
YWNfb2xkX3ZhbGAKKwlhY19uZXdfdmFsX3c9YGVjaG8geCAkYWNfbmV3X3ZhbGAKKwlpZiB0ZXN0
ICIkYWNfb2xkX3ZhbF93IiAhPSAiJGFjX25ld192YWxfdyI7IHRoZW4KKwkgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IFxgJGFjX3ZhcicgaGFzIGNoYW5n
ZWQgc2luY2UgdGhlIHByZXZpb3VzIHJ1bjoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6
IFxgJGFjX3ZhcicgaGFzIGNoYW5nZWQgc2luY2UgdGhlIHByZXZpb3VzIHJ1bjoiID4mMjt9CisJ
ICBhY19jYWNoZV9jb3JydXB0ZWQ9OgorCWVsc2UKKwkgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogd2FybmluZzogaWdub3Jpbmcgd2hpdGVzcGFjZSBjaGFuZ2VzIGlu
IFxgJGFjX3Zhcicgc2luY2UgdGhlIHByZXZpb3VzIHJ1bjoiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogd2FybmluZzogaWdub3Jpbmcgd2hpdGVzcGFjZSBjaGFuZ2VzIGluIFxgJGFjX3Zhcicgc2lu
Y2UgdGhlIHByZXZpb3VzIHJ1bjoiID4mMjt9CisJICBldmFsICRhY192YXI9XCRhY19vbGRfdmFs
CisJZmkKKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICAgZm9ybWVy
IHZhbHVlOiAgXGAkYWNfb2xkX3ZhbCciID4mNQorJGFzX2VjaG8gIiRhc19tZTogICBmb3JtZXIg
dmFsdWU6ICBcYCRhY19vbGRfdmFsJyIgPiYyO30KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306ICAgY3VycmVudCB2YWx1ZTogXGAkYWNfbmV3X3ZhbCciID4mNQorJGFz
X2VjaG8gIiRhc19tZTogICBjdXJyZW50IHZhbHVlOiBcYCRhY19uZXdfdmFsJyIgPiYyO30KKyAg
ICAgIGZpOzsKKyAgZXNhYworICAjIFBhc3MgcHJlY2lvdXMgdmFyaWFibGVzIHRvIGNvbmZpZy5z
dGF0dXMuCisgIGlmIHRlc3QgIiRhY19uZXdfc2V0IiA9IHNldDsgdGhlbgorICAgIGNhc2UgJGFj
X25ld192YWwgaW4KKyAgICAqXCcqKSBhY19hcmc9JGFjX3Zhcj1gJGFzX2VjaG8gIiRhY19uZXdf
dmFsIiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYCA7OworICAgICopIGFjX2FyZz0kYWNfdmFy
PSRhY19uZXdfdmFsIDs7CisgICAgZXNhYworICAgIGNhc2UgIiAkYWNfY29uZmlndXJlX2FyZ3Mg
IiBpbgorICAgICAgKiIgJyRhY19hcmcnICIqKSA7OyAjIEF2b2lkIGR1cHMuICBVc2Ugb2YgcXVv
dGVzIGVuc3VyZXMgYWNjdXJhY3kuCisgICAgICAqKSBhc19mbl9hcHBlbmQgYWNfY29uZmlndXJl
X2FyZ3MgIiAnJGFjX2FyZyciIDs7CisgICAgZXNhYworICBmaQorZG9uZQoraWYgJGFjX2NhY2hl
X2NvcnJ1cHRlZDsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjog
aW4gXGAkYWNfcHdkJzoiID4mMjt9CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZXJyb3I6IGNoYW5nZXMgaW4gdGhlIGVudmlyb25tZW50IGNhbiBjb21wcm9taXNl
IHRoZSBidWlsZCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogY2hhbmdlcyBpbiB0aGUg
ZW52aXJvbm1lbnQgY2FuIGNvbXByb21pc2UgdGhlIGJ1aWxkIiA+JjI7fQorICBhc19mbl9lcnJv
ciAkPyAicnVuIFxgbWFrZSBkaXN0Y2xlYW4nIGFuZC9vciBcYHJtICRjYWNoZV9maWxlJyBhbmQg
c3RhcnQgb3ZlciIgIiRMSU5FTk8iIDUKK2ZpCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIwor
IyMgTWFpbiBib2R5IG9mIHNjcmlwdC4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisK
K2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRD
RkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNf
ZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKKwor
CisKK2FjX2NvbmZpZ19maWxlcz0iJGFjX2NvbmZpZ19maWxlcyAuLi9jb25maWcvVG9vbHMubWsi
CisKK2FjX2NvbmZpZ19oZWFkZXJzPSIkYWNfY29uZmlnX2hlYWRlcnMgY29uZmlnLmgiCisKKwor
YWNfYXV4X2Rpcj0KK2ZvciBhY19kaXIgaW4gLiAiJHNyY2RpciIvLjsgZG8KKyAgaWYgdGVzdCAt
ZiAiJGFjX2Rpci9pbnN0YWxsLXNoIjsgdGhlbgorICAgIGFjX2F1eF9kaXI9JGFjX2RpcgorICAg
IGFjX2luc3RhbGxfc2g9IiRhY19hdXhfZGlyL2luc3RhbGwtc2ggLWMiCisgICAgYnJlYWsKKyAg
ZWxpZiB0ZXN0IC1mICIkYWNfZGlyL2luc3RhbGwuc2giOyB0aGVuCisgICAgYWNfYXV4X2Rpcj0k
YWNfZGlyCisgICAgYWNfaW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIvaW5zdGFsbC5zaCAtYyIKKyAg
ICBicmVhaworICBlbGlmIHRlc3QgLWYgIiRhY19kaXIvc2h0b29sIjsgdGhlbgorICAgIGFjX2F1
eF9kaXI9JGFjX2RpcgorICAgIGFjX2luc3RhbGxfc2g9IiRhY19hdXhfZGlyL3NodG9vbCBpbnN0
YWxsIC1jIgorICAgIGJyZWFrCisgIGZpCitkb25lCitpZiB0ZXN0IC16ICIkYWNfYXV4X2RpciI7
IHRoZW4KKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIGluc3RhbGwtc2gsIGluc3RhbGwu
c2gsIG9yIHNodG9vbCBpbiAuIFwiJHNyY2RpclwiLy4iICIkTElORU5PIiA1CitmaQorCisjIFRo
ZXNlIHRocmVlIHZhcmlhYmxlcyBhcmUgdW5kb2N1bWVudGVkIGFuZCB1bnN1cHBvcnRlZCwKKyMg
YW5kIGFyZSBpbnRlbmRlZCB0byBiZSB3aXRoZHJhd24gaW4gYSBmdXR1cmUgQXV0b2NvbmYgcmVs
ZWFzZS4KKyMgVGhleSBjYW4gY2F1c2Ugc2VyaW91cyBwcm9ibGVtcyBpZiBhIGJ1aWxkZXIncyBz
b3VyY2UgdHJlZSBpcyBpbiBhIGRpcmVjdG9yeQorIyB3aG9zZSBmdWxsIG5hbWUgY29udGFpbnMg
dW51c3VhbCBjaGFyYWN0ZXJzLgorYWNfY29uZmlnX2d1ZXNzPSIkU0hFTEwgJGFjX2F1eF9kaXIv
Y29uZmlnLmd1ZXNzIiAgIyBQbGVhc2UgZG9uJ3QgdXNlIHRoaXMgdmFyLgorYWNfY29uZmlnX3N1
Yj0iJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICAjIFBsZWFzZSBkb24ndCB1c2UgdGhp
cyB2YXIuCithY19jb25maWd1cmU9IiRTSEVMTCAkYWNfYXV4X2Rpci9jb25maWd1cmUiICAjIFBs
ZWFzZSBkb24ndCB1c2UgdGhpcyB2YXIuCisKKworCisjIENoZWNrIGlmIENGTEFHUywgTERGTEFH
UywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQgYSB3YXJuaW5nCisKK2lm
IHRlc3QgLW4gIiRDQyRDRkxBR1MkTERGTEFHUyRMSUJTJENQUEZMQUdTJENQUCI7IHRoZW4gOgor
CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBT
ZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBpcyBub3Qg
XAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5EX0xJQiwgXAorQVBQ
RU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJsZS4iID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogU2V0dGluZyBDQywgQ0ZMQUdTLCBMREZMQUdTLCBM
SUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgbm90IFwKK3JlY29tbWVuZGVkLCB1c2UgUFJFUEVORF9J
TkNMVURFUywgUFJFUEVORF9MSUIsIFwKK0FQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBp
bnN0ZWFkIHdoZW4gcG9zc2libGUuIiA+JjI7fQorCitmaQorCithY19leHQ9YworYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG
TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j
b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CitpZiB0ZXN0IC1uICIkYWNfdG9vbF9w
cmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3By
ZWZpeH1nY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15ICR7YWNfdG9vbF9wcmVmaXh9Z2NjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19D
Qys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMK
KyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9
Z2NjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUK
KyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitp
ZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1
CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3By
b2dfQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQg
b2YgImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgZ2NjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9DQys6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4g
IiRhY19jdF9DQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9ImdjYyIK
KyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRv
bmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19j
dF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKKyRhc19lY2hvICIk
YWNfY3RfQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAg
aWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCisgICAgQ0M9IiIKKyAgZWxzZQorICAgIGNh
c2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xz
IG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBX
QVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQi
ID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBDQz0kYWNfY3RfQ0MKKyAg
ZmkKK2Vsc2UKKyAgQ0M9IiRhY19jdl9wcm9nX0NDIgorZmkKKworaWYgdGVzdCAteiAiJENDIjsg
dGhlbgorICAgICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Y2MiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVm
aXh9Y2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsg
dGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFz
X2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
CisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhl
bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEND
IiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKworICBmaQorZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICJjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCitzZXQgZHVtbXkgY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9
IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorICBhY19wcm9nX3JlamVjdGVkPW5vCithc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbwor
ICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBpZiB0ZXN0ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA9ICIvdXNyL3VjYi9jYyI7IHRoZW4KKyAgICAgICBh
Y19wcm9nX3JlamVjdGVkPXllcworICAgICAgIGNvbnRpbnVlCisgICAgIGZpCisgICAgYWNfY3Zf
cHJvZ19DQz0iY2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2lmIHRlc3QgJGFjX3Byb2dfcmVq
ZWN0ZWQgPSB5ZXM7IHRoZW4KKyAgIyBXZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBt
YWtlIHN1cmUgd2UgbmV2ZXIgdXNlIGl0LgorICBzZXQgZHVtbXkgJGFjX2N2X3Byb2dfQ0MKKyAg
c2hpZnQKKyAgaWYgdGVzdCAkIyAhPSAwOyB0aGVuCisgICAgIyBXZSBjaG9zZSBhIGRpZmZlcmVu
dCBjb21waWxlciBmcm9tIHRoZSBib2d1cyBvbmUuCisgICAgIyBIb3dldmVyLCBpdCBoYXMgdGhl
IHNhbWUgYmFzZW5hbWUsIHNvIHRoZSBib2dvbiB3aWxsIGJlIGNob3NlbgorICAgICMgZmlyc3Qg
aWYgd2Ugc2V0IENDIHRvIGp1c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1l
LgorICAgIHNoaWZ0CisgICAgYWNfY3ZfcHJvZ19DQz0iJGFzX2Rpci8kYWNfd29yZCR7MSsnICd9
JEAiCisgIGZpCitmaQorZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJEND
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgaWYgdGVzdCAt
biAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKKyAgZG8K
KyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRhY190b29sX3ByZWZpeCRhY19wcm9n
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkYWNf
dG9vbF9wcmVmaXgkYWNfcHJvZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0
ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQ
QVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRl
c3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRh
Y19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVmaXgkYWNfcHJv
ZyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQor
JGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsK
KyAgZG9uZQorZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgIGZv
ciBhY19wcm9nIGluIGNsLmV4ZQorZG8KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
YWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgJGFjX3Byb2c7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X0NDKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0Mi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0i
JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91
bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQor
ZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2
X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Cisk
YXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9
CitmaQorCisKKyAgdGVzdCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhaworZG9uZQorCisgIGlmIHRl
c3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitm
aQorCitmaQorCisKK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAibm8gYWNj
ZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAorU2VlIFxgY29uZmlnLmxvZycgZm9y
IG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDU7IH0KKworIyBQcm92aWRlIHNvbWUgaW5mb3JtYXRp
b24gYWJvdXQgdGhlIGNvbXBpbGVyLgorJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgdmVyc2lvbiIgPiY1CitzZXQgWCAkYWNfY29t
cGlsZQorYWNfY29tcGlsZXI9JDIKK2ZvciBhY19vcHRpb24gaW4gLS12ZXJzaW9uIC12IC1WIC1x
dmVyc2lvbjsgZG8KKyAgeyB7IGFjX3RyeT0iJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1Igor
Y2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwk
YWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9l
Y2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFz
X2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29tcGlsZXIgJGFjX29w
dGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgorICBhY19zdGF0dXM9JD8KKyAgaWYgdGVzdCAtcyBj
b25mdGVzdC5lcnI7IHRoZW4KKyAgICBzZWQgJzEwYVwKKy4uLiByZXN0IG9mIHN0ZGVyciBvdXRw
dXQgZGVsZXRlZCAuLi4KKyAgICAgICAgIDEwcScgY29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEK
KyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICBmaQorICBybSAtZiBjb25mdGVzdC5lcjEgY29u
ZnRlc3QuZXJyCisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9
ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9Citkb25lCisKK2NhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgor
YWNfY2xlYW5fZmlsZXNfc2F2ZT0kYWNfY2xlYW5fZmlsZXMKK2FjX2NsZWFuX2ZpbGVzPSIkYWNf
Y2xlYW5fZmlsZXMgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBiLm91dCIKKyMgVHJ5IHRvIGNyZWF0
ZSBhbiBleGVjdXRhYmxlIHdpdGhvdXQgLW8gZmlyc3QsIGRpc3JlZ2FyZCBhLm91dC4KKyMgSXQg
d2lsbCBoZWxwIHVzIGRpYWdub3NlIGJyb2tlbiBjb21waWxlcnMsIGFuZCBmaW5kaW5nIG91dCBh
biBpbnR1aXRpb24KKyMgb2YgZXhlZXh0LgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIHdvcmtzIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MuLi4gIiA+JjY7
IH0KK2FjX2xpbmtfZGVmYXVsdD1gJGFzX2VjaG8gIiRhY19saW5rIiB8IHNlZCAncy8gLW8gKmNv
bmZ0ZXN0W14gXSovLydgCisKKyMgVGhlIHBvc3NpYmxlIG91dHB1dCBmaWxlczoKK2FjX2ZpbGVz
PSJhLm91dCBjb25mdGVzdC5leGUgY29uZnRlc3QgYS5leGUgYV9vdXQuZXhlIGIub3V0IGNvbmZ0
ZXN0LioiCisKK2FjX3JtZmlsZXM9Citmb3IgYWNfZmlsZSBpbiAkYWNfZmlsZXMKK2RvCisgIGNh
c2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAq
LnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAq
Lm8gfCAqLm9iaiApIDs7CisgICAgKiApIGFjX3JtZmlsZXM9IiRhY19ybWZpbGVzICRhY19maWxl
Ijs7CisgIGVzYWMKK2RvbmUKK3JtIC1mICRhY19ybWZpbGVzCisKK2lmIHsgeyBhY190cnk9IiRh
Y19saW5rX2RlZmF1bHQiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxc
KikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2Vz
YWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFj
X3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRh
Y19saW5rX2RlZmF1bHQiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfTsgdGhlbiA6CisgICMgQXV0b2NvbmYtMi4xMyBjb3VsZCBzZXQgdGhlIGFj
X2N2X2V4ZWV4dCB2YXJpYWJsZSB0byBgbm8nLgorIyBTbyBpZ25vcmUgYSB2YWx1ZSBvZiBgbm8n
LCBvdGhlcndpc2UgdGhpcyB3b3VsZCBsZWFkIHRvIGBFWEVFWFQgPSBubycKKyMgaW4gYSBNYWtl
ZmlsZS4gIFdlIHNob3VsZCBub3Qgb3ZlcnJpZGUgYWNfY3ZfZXhlZXh0IGlmIGl0IHdhcyBjYWNo
ZWQsCisjIHNvIHRoYXQgdGhlIHVzZXIgY2FuIHNob3J0LWNpcmN1aXQgdGhpcyB0ZXN0IGZvciBj
b21waWxlcnMgdW5rbm93biB0bworIyBBdXRvY29uZi4KK2ZvciBhY19maWxlIGluICRhY19maWxl
cyAnJworZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlCisgIGNhc2UgJGFjX2Zp
bGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICou
eFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9i
aiApCisJOzsKKyAgICBbYWJdLm91dCApCisJIyBXZSBmb3VuZCB0aGUgZGVmYXVsdCBleGVjdXRh
YmxlLCBidXQgZXhlZXh0PScnIGlzIG1vc3QKKwkjIGNlcnRhaW5seSByaWdodC4KKwlicmVhazs7
CisgICAgKi4qICkKKwlpZiB0ZXN0ICIke2FjX2N2X2V4ZWV4dCtzZXR9IiA9IHNldCAmJiB0ZXN0
ICIkYWNfY3ZfZXhlZXh0IiAhPSBubzsKKwl0aGVuIDo7IGVsc2UKKwkgICBhY19jdl9leGVleHQ9
YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AKKwlmaQorCSMgV2Ugc2V0IGFjX2N2
X2V4ZWV4dCBoZXJlIGJlY2F1c2UgdGhlIGxhdGVyIHRlc3QgZm9yIGl0IGlzIG5vdAorCSMgc2Fm
ZTogY3Jvc3MgY29tcGlsZXJzIG1heSBub3QgYWRkIHRoZSBzdWZmaXggaWYgZ2l2ZW4gYW4gYC1v
JworCSMgYXJndW1lbnQsIHNvIHdlIG1heSBuZWVkIHRvIGtub3cgaXQgYXQgdGhhdCBwb2ludCBh
bHJlYWR5LgorCSMgRXZlbiBpZiB0aGlzIHNlY3Rpb24gbG9va3MgY3J1ZnR5OiBpdCBoYXMgdGhl
IGFkdmFudGFnZSBvZgorCSMgYWN0dWFsbHkgd29ya2luZy4KKwlicmVhazs7CisgICAgKiApCisJ
YnJlYWs7OworICBlc2FjCitkb25lCit0ZXN0ICIkYWNfY3ZfZXhlZXh0IiA9IG5vICYmIGFjX2N2
X2V4ZWV4dD0KKworZWxzZQorICBhY19maWxlPScnCitmaQoraWYgdGVzdCAteiAiJGFjX2ZpbGUi
OyB0aGVuIDoKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiskYXNfZWNobyAiJGFzX21lOiBmYWls
ZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUK
KworeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mMjt9Cithc19mbl9lcnJvciA3NyAiQyBjb21waWxlciBjYW5ub3QgY3JlYXRlIGV4ZWN1dGFi
bGVzCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQor
ZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
eWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRw
dXQgZmlsZSBuYW1lIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRl
ZmF1bHQgb3V0cHV0IGZpbGUgbmFtZS4uLiAiID4mNjsgfQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19maWxlIiA+JjUKKyRhc19lY2hvICIkYWNf
ZmlsZSIgPiY2OyB9CithY19leGVleHQ9JGFjX2N2X2V4ZWV4dAorCitybSAtZiAtciBhLm91dCBh
Lm91dC5kU1lNIGEuZXhlIGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCBiLm91dAorYWNfY2xlYW5fZmls
ZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBleGVjdXRhYmxlcyIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzLi4uICIgPiY2OyB9CitpZiB7
IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCog
fCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7
OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZh
bCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3Rh
dHVzID0gMDsgfTsgdGhlbiA6CisgICMgSWYgYm90aCBgY29uZnRlc3QuZXhlJyBhbmQgYGNvbmZ0
ZXN0JyBhcmUgYHByZXNlbnQnICh3ZWxsLCBvYnNlcnZhYmxlKQorIyBjYXRjaCBgY29uZnRlc3Qu
ZXhlJy4gIEZvciBpbnN0YW5jZSB3aXRoIEN5Z3dpbiwgYGxzIGNvbmZ0ZXN0JyB3aWxsCisjIHdv
cmsgcHJvcGVybHkgKGkuZS4sIHJlZmVyIHRvIGBjb25mdGVzdC5leGUnKSwgd2hpbGUgaXQgd29u
J3Qgd2l0aAorIyBgcm0nLgorZm9yIGFjX2ZpbGUgaW4gY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGNv
bmZ0ZXN0Lio7IGRvCisgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZQorICBjYXNlICRh
Y19maWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIg
fCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwg
Ki5vYmogKSA7OworICAgICouKiApIGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1te
Ll0qXChcLi4qXCknYAorCSAgYnJlYWs7OworICAgICogKSBicmVhazs7CisgIGVzYWMKK2RvbmUK
K2Vsc2UKKyAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9y
OiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNf
cHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4
ZWN1dGFibGVzOiBjYW5ub3QgY29tcGlsZSBhbmQgbGluaworU2VlIFxgY29uZmlnLmxvZycgZm9y
IG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDU7IH0KK2ZpCitybSAtZiBjb25mdGVzdCBjb25mdGVz
dCRhY19jdl9leGVleHQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfZXhlZXh0IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZXhlZXh0IiA+JjY7
IH0KKworcm0gLWYgY29uZnRlc3QuJGFjX2V4dAorRVhFRVhUPSRhY19jdl9leGVleHQKK2FjX2V4
ZWV4dD0kRVhFRVhUCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFpbiAo
KQoreworRklMRSAqZiA9IGZvcGVuICgiY29uZnRlc3Qub3V0IiwgInciKTsKKyByZXR1cm4gZmVy
cm9yIChmKSB8fCBmY2xvc2UgKGYpICE9IDA7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VP
RgorYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9maWxlcyBjb25mdGVzdC5vdXQiCisjIENoZWNr
IHRoYXQgdGhlIGNvbXBpbGVyIHByb2R1Y2VzIGV4ZWN1dGFibGVzIHdlIGNhbiBydW4uICBJZiBu
b3QsIGVpdGhlcgorIyB0aGUgY29tcGlsZXIgaXMgYnJva2VuLCBvciB3ZSBjcm9zcyBjb21waWxl
LgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0
aGVyIHdlIGFyZSBjcm9zcyBjb21waWxpbmciID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hl
dGhlciB3ZSBhcmUgY3Jvc3MgY29tcGlsaW5nLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIkY3Jvc3Nf
Y29tcGlsaW5nIiAhPSB5ZXM7IHRoZW4KKyAgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIo
KCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7
OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89Ilwi
XCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAi
JGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQorICBhY19zdGF0
dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFj
X3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KKyAgaWYgeyBhY190cnk9Jy4v
Y29uZnRlc3QkYWNfY3ZfZXhlZXh0JworICB7IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIq
IHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89
JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1
CisgIChldmFsICIkYWNfdHJ5IikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3Qg
JGFjX3N0YXR1cyA9IDA7IH07IH07IHRoZW4KKyAgICBjcm9zc19jb21waWxpbmc9bm8KKyAgZWxz
ZQorICAgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0gbWF5YmU7IHRoZW4KKwljcm9zc19j
b21waWxpbmc9eWVzCisgICAgZWxzZQorCXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBydW4g
QyBjb21waWxlZCBwcm9ncmFtcy4KK0lmIHlvdSBtZWFudCB0byBjcm9zcyBjb21waWxlLCB1c2Ug
XGAtLWhvc3QnLgorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8i
IDU7IH0KKyAgICBmaQorICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkY3Jvc3NfY29tcGlsaW5nIiA+JjUKKyRhc19lY2hvICIkY3Jvc3Nf
Y29tcGlsaW5nIiA+JjY7IH0KKworcm0gLWYgY29uZnRlc3QuJGFjX2V4dCBjb25mdGVzdCRhY19j
dl9leGVleHQgY29uZnRlc3Qub3V0CithY19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2
ZQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
c3VmZml4IG9mIG9iamVjdCBmaWxlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igc3Vm
Zml4IG9mIG9iamVjdCBmaWxlcy4uLiAiID4mNjsgfQoraWYgJHthY19jdl9vYmpleHQrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK3Jt
IC1mIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqCitpZiB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZSIK
K2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1c
JGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlf
ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRh
c19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGUiKSAyPiY1
CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6
CisgIGZvciBhY19maWxlIGluIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRv
CisgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZTsKKyAgY2FzZSAkYWNfZmlsZSBpbgor
ICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwg
Ki5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSApIDs7CisgICAgKikgYWNfY3Zf
b2JqZXh0PWBleHByICIkYWNfZmlsZSIgOiAnLipcLlwoLipcKSdgCisgICAgICAgYnJlYWs7Owor
ICBlc2FjCitkb25lCitlbHNlCisgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdh
czoiID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCit7IHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2Zu
X2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzOiBjYW5ub3Qg
Y29tcGlsZQorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDU7
IH0KK2ZpCitybSAtZiBjb25mdGVzdC4kYWNfY3Zfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X29iamV4dCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X29iamV4dCIgPiY2OyB9CitPQkpFWFQ9JGFj
X2N2X29iamV4dAorYWNfb2JqZXh0PSRPQkpFWFQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNv
bXBpbGVyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRo
ZSBHTlUgQyBjb21waWxlci4uLiAiID4mNjsgfQoraWYgJHthY19jdl9jX2NvbXBpbGVyX2dudSs6
fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KKworaW50CittYWluICgpCit7CisjaWZuZGVmIF9fR05VQ19fCisgICAgICAgY2hv
a2UgbWUKKyNlbmRpZgorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY29tcGlsZXJfZ251PXllcworZWxz
ZQorICBhY19jb21waWxlcl9nbnU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2FjX2N2X2NfY29tcGlsZXJfZ251PSRh
Y19jb21waWxlcl9nbnUKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7
IHRoZW4KKyAgR0NDPXllcworZWxzZQorICBHQ0M9CitmaQorYWNfdGVzdF9DRkxBR1M9JHtDRkxB
R1Mrc2V0fQorYWNfc2F2ZV9DRkxBR1M9JENGTEFHUworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19jY19nKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJvcl9mbGFn
CisgICBhY19jX3dlcnJvcl9mbGFnPXllcworICAgYWNfY3ZfcHJvZ19jY19nPW5vCisgICBDRkxB
R1M9Ii1nIgorICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAor
LyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X3Byb2dfY2NfZz15ZXMKK2Vsc2UKKyAgQ0ZMQUdTPSIiCisgICAgICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQorICBhY19jX3dl
cnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKKwkgQ0ZMQUdTPSItZyIKKwkgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2dfY2Nf
Zz15ZXMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFj
X3NhdmVfY193ZXJyb3JfZmxhZworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
cHJvZ19jY19nIiA+JjY7IH0KK2lmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRoZW4K
KyAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUworZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cgPSB5
ZXM7IHRoZW4KKyAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1nIC1P
MiIKKyAgZWxzZQorICAgIENGTEFHUz0iLWciCisgIGZpCitlbHNlCisgIGlmIHRlc3QgIiRHQ0Mi
ID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItTzIiCisgIGVsc2UKKyAgICBDRkxBR1M9CisgIGZp
CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OSIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OS4uLiAiID4mNjsgfQoraWYgJHthY19j
dl9wcm9nX2NjX2M4OSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGFjX2N2X3Byb2dfY2NfYzg5PW5vCithY19zYXZlX0NDPSRDQworY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVkZSA8
c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKy8qIE1vc3Qgb2YgdGhlIGZvbGxv
d2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZyb20gUkNTIDUuNydzIHNyYy9jb25mLnNoLiAgKi8KK3N0
cnVjdCBidWYgeyBpbnQgeDsgfTsKK0ZJTEUgKiAoKnJjc29wZW4pIChzdHJ1Y3QgYnVmICosIHN0
cnVjdCBzdGF0ICosIGludCk7CitzdGF0aWMgY2hhciAqZSAocCwgaSkKKyAgICAgY2hhciAqKnA7
CisgICAgIGludCBpOworeworICByZXR1cm4gcFtpXTsKK30KK3N0YXRpYyBjaGFyICpmIChjaGFy
ICogKCpnKSAoY2hhciAqKiwgaW50KSwgY2hhciAqKnAsIC4uLikKK3sKKyAgY2hhciAqczsKKyAg
dmFfbGlzdCB2OworICB2YV9zdGFydCAodixwKTsKKyAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQp
KTsKKyAgdmFfZW5kICh2KTsKKyAgcmV0dXJuIHM7Cit9CisKKy8qIE9TRiA0LjAgQ29tcGFxIGNj
IGlzIHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LiAgSXQgaGFzCisgICBmdW5j
dGlvbiBwcm90b3R5cGVzIGFuZCBzdHVmZiwgYnV0IG5vdCAnXHhISCcgaGV4IGNoYXJhY3RlciBj
b25zdGFudHMuCisgICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9yIHVuZm9ydHVuYXRlbHks
IGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKKyAgIGFzICd4Jy4gIFRoZSBmb2xsb3dpbmcg
aW5kdWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0byBnZXQKKyAgIHByb3BlciBB
TlNJIG1vZGUuICBDdXJpb3VzbHkgJ1x4MDAnIT0neCcgYWx3YXlzIGNvbWVzIG91dCB0cnVlLCBm
b3IgYW4KKyAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5lY2Vzc2FyeSB0byB3cml0ZSAn
XHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZworICAgdGhhdCdzIHRydWUgb25seSB3aXRoIC1zdGQu
ICAqLworaW50IG9zZjRfY2NfYXJyYXkgWydceDAwJyA9PSAwID8gMSA6IC0xXTsKKworLyogSUJN
IEMgNiBmb3IgQUlYIGlzIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQsIGJ1dCBpdCByZXBsYWNlcyBt
YWNybyBwYXJhbWV0ZXJzCisgICBpbnNpZGUgc3RyaW5ncyBhbmQgY2hhcmFjdGVyIGNvbnN0YW50
cy4gICovCisjZGVmaW5lIEZPTyh4KSAneCcKK2ludCB4bGM2X2NjX2FycmF5W0ZPTyhhKSA9PSAn
eCcgPyAxIDogLTFdOworCitpbnQgdGVzdCAoaW50IGksIGRvdWJsZSB4KTsKK3N0cnVjdCBzMSB7
aW50ICgqZikgKGludCBhKTt9Oworc3RydWN0IHMyIHtpbnQgKCpmKSAoZG91YmxlIGEpO307Citp
bnQgcGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShzdHJ1Y3QgYnVmICosIHN0cnVj
dCBzdGF0ICosIGludCksIGludCwgaW50KTsKK2ludCBhcmdjOworY2hhciAqKmFyZ3Y7CitpbnQK
K21haW4gKCkKK3sKK3JldHVybiBmIChlLCBhcmd2LCAwKSAhPSBhcmd2WzBdICB8fCAgZiAoZSwg
YXJndiwgMSkgIT0gYXJndlsxXTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorZm9yIGFj
X2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1xbGFuZ2x2bD1hbnNpIC1zdGQgXAorCS1BZSAi
LUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05TX18iCitkbworICBDQz0iJGFj
X3NhdmVfQ0MgJGFjX2FyZyIKKyAgaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRo
ZW4gOgorICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCitmaQorcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dAorICB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAh
PSAieG5vIiAmJiBicmVhaworZG9uZQorcm0gLWYgY29uZnRlc3QuJGFjX2V4dAorQ0M9JGFjX3Nh
dmVfQ0MKKworZmkKKyMgQUNfQ0FDSEVfVkFMCitjYXNlICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiBp
bgorICB4KQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiBub25lIG5lZWRlZCIgPiY1CiskYXNfZWNobyAibm9uZSBuZWVkZWQiID4mNjsgfSA7Owor
ICB4bm8pCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IHVuc3VwcG9ydGVkIiA+JjUKKyRhc19lY2hvICJ1bnN1cHBvcnRlZCIgPiY2OyB9IDs7Cisg
ICopCisgICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODkiCisgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2M4OSIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7IH0gOzsKK2VzYWMKK2lmIHRlc3Qg
IngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6CisKK2ZpCisKK2FjX2V4dD1jCith
Y19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZM
QUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4
ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4m
NScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKKworCithY19leHQ9Ywor
YWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBG
TEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19l
eGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+
JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJl
cHJvY2Vzc29yIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJl
cHJvY2Vzc29yLi4uICIgPiY2OyB9CisjIE9uIFN1bnMsIHNvbWV0aW1lcyAkQ1BQIG5hbWVzIGEg
ZGlyZWN0b3J5LgoraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQUCI7IHRoZW4KKyAg
Q1BQPQorZmkKK2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCisgIGlmICR7YWNfY3ZfcHJvZ19DUFAr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICAg
ICAgIyBEb3VibGUgcXVvdGVzIGJlY2F1c2UgQ1BQIG5lZWRzIHRvIGJlIGV4cGFuZGVkCisgICAg
Zm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10cmFkaXRpb25hbC1jcHAiICIvbGliL2NwcCIK
KyAgICBkbworICAgICAgYWNfcHJlcHJvY19vaz1mYWxzZQorZm9yIGFjX2NfcHJlcHJvY193YXJu
X2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRlciBmaWxlIHRoYXQgY29tZXMgd2l0
aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0aCBhIGZyZXNoIGNyb3NzLWNvbXBp
bGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERD
X18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVz
dGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUg
dGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMgbm90IGp1c3QgdGhyb3VnaCBjcHAu
ICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRzLmg+CisjZWxzZQorIyBpbmNsdWRl
IDxhc3NlcnQuaD4KKyNlbmRpZgorCQkgICAgIFN5bnRheCBlcnJvcgorX0FDRU9GCitpZiBhY19m
bl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQorICAjIEJyb2tlbjogZmFpbHMg
b24gdmFsaWQgaW5wdXQuCitjb250aW51ZQorZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNhc2VzLiAgTm93
IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycworICAjIGNhbiBiZSBkZXRlY3RlZCBh
bmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KK19BQ0VP
RgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6CisgICMgQnJva2VuOiBzdWNj
ZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxzZQorICAjIFBhc3NlcyBib3RoIHRl
c3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhaworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworZG9uZQorIyBCZWNhdXNlIG9mIGBicmVhaycsIF9B
Q19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCitybSAtZiBjb25m
dGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0CitpZiAkYWNfcHJlcHJvY19vazsg
dGhlbiA6CisgIGJyZWFrCitmaQorCisgICAgZG9uZQorICAgIGFjX2N2X3Byb2dfQ1BQPSRDUFAK
KworZmkKKyAgQ1BQPSRhY19jdl9wcm9nX0NQUAorZWxzZQorICBhY19jdl9wcm9nX0NQUD0kQ1BQ
CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRD
UFAiID4mNQorJGFzX2VjaG8gIiRDUFAiID4mNjsgfQorYWNfcHJlcHJvY19vaz1mYWxzZQorZm9y
IGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRlciBm
aWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0aCBh
IGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRvIDxh
c3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+IGV4
aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQsIGNj
IC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMgbm90
IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhpcyBj
YXNlLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBl
bmQgY29uZmRlZnMuaC4gICovCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRzLmg+
CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNlbmRpZgorCQkgICAgIFN5bnRheCBlcnJv
cgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQor
ICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCitjb250aW51ZQorZmkKK3JtIC1mIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3JrcyBv
biBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycworICAj
IGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNfbm9u
ZXhpc3RlbnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6
CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxzZQor
ICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhaworZmkKK3JtIC1m
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworZG9uZQorIyBCZWNh
dXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNr
aXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0Citp
ZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisKK2Vsc2UKKyAgeyB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNo
byAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAi
QyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFpbHMgc2FuaXR5IGNoZWNrCitTZWUgXGBjb25maWcu
bG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorZmkKKworYWNfZXh0PWMKK2Fj
X2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxB
R1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhl
ZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1
JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5k
bGVzIGxvbmcgbGluZXMgYW5kIC1lIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBncmVw
IHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9w
YXRoX0dSRVArOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBpZiB0ZXN0IC16ICIkR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9HUkVQX2ZvdW5kPWZh
bHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBv
ZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9y
IGFjX3Byb2cgaW4gZ3JlcCBnZ3JlcDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfR1JFUD0iJGFzX2Rpci8k
YWNfcHJvZyRhY19leGVjX2V4dCIKKyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfR1JFUCIgJiYg
JGFzX3Rlc3RfeCAiJGFjX3BhdGhfR1JFUCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sgZm9yIEdO
VSBhY19wYXRoX0dSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KKyAgIyBDaGVjayBm
b3IgR05VICRhY19wYXRoX0dSRVAKK2Nhc2UgYCIkYWNfcGF0aF9HUkVQIiAtLXZlcnNpb24gMj4m
MWAgaW4KKypHTlUqKQorICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiIGFjX3BhdGhf
R1JFUF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5
ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0LmluIiAi
Y29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJjb25m
dGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNfZWNo
byAnR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0aF9HUkVQIiAtZSAnR1JFUCQn
IC1lICctKGNhbm5vdCBtYXRjaCktJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+
L2Rldi9udWxsIHx8IGJyZWFrCisgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3Qubmwi
ID4vZGV2L251bGwgMj4mMSB8fCBicmVhaworICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCArIDEg
JiYgYWNfY291bnQ9JGFzX3ZhbAorICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhf
R1JFUF9tYXgtMH07IHRoZW4KKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBr
ZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9HUkVQPSIkYWNf
cGF0aF9HUkVQIgorICAgICAgYWNfcGF0aF9HUkVQX21heD0kYWNfY291bnQKKyAgICBmaQorICAg
ICMgMTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKKyAgICB0
ZXN0ICRhY19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25mdGVzdC5p
biBjb25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKKworICAgICAg
JGFjX3BhdGhfR1JFUF9mb3VuZCAmJiBicmVhayAzCisgICAgZG9uZQorICBkb25lCisgIGRvbmUK
K0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfR1JFUCI7IHRoZW4K
KyAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBncmVwIGNvdWxkIGJlIGZvdW5kIGlu
ICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbiIgIiRMSU5FTk8iIDUKKyAgZmkKK2Vs
c2UKKyAgYWNfY3ZfcGF0aF9HUkVQPSRHUkVQCitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX0dSRVAiID4mNQorJGFz
X2VjaG8gIiRhY19jdl9wYXRoX0dSRVAiID4mNjsgfQorIEdSRVA9IiRhY19jdl9wYXRoX0dSRVAi
CisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgZWdyZXAiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGVncmVwLi4uICIgPiY2OyB9
CitpZiAke2FjX2N2X3BhdGhfRUdSRVArOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBpZiBlY2hvIGEgfCAkR1JFUCAtRSAnKGF8YiknID4vZGV2
L251bGwgMj4mMQorICAgdGhlbiBhY19jdl9wYXRoX0VHUkVQPSIkR1JFUCAtRSIKKyAgIGVsc2UK
KyAgICAgaWYgdGVzdCAteiAiJEVHUkVQIjsgdGhlbgorICBhY19wYXRoX0VHUkVQX2ZvdW5kPWZh
bHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBv
ZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9y
IGFjX3Byb2cgaW4gZWdyZXA7IGRvCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj
dXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgICAgICBhY19wYXRoX0VHUkVQPSIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9FR1JFUCIgJiYgJGFz
X3Rlc3RfeCAiJGFjX3BhdGhfRUdSRVAiOyB9IHx8IGNvbnRpbnVlCisjIENoZWNrIGZvciBHTlUg
YWNfcGF0aF9FR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAjIENoZWNrIGZv
ciBHTlUgJGFjX3BhdGhfRUdSRVAKK2Nhc2UgYCIkYWNfcGF0aF9FR1JFUCIgLS12ZXJzaW9uIDI+
JjFgIGluCisqR05VKikKKyAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiIGFjX3Bh
dGhfRUdSRVBfZm91bmQ9Ojs7CisqKQorICBhY19jb3VudD0wCisgICRhc19lY2hvX24gMDEyMzQ1
Njc4OSA+ImNvbmZ0ZXN0LmluIgorICB3aGlsZSA6CisgIGRvCisgICAgY2F0ICJjb25mdGVzdC5p
biIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRtcCIKKyAgICBtdiAiY29uZnRlc3QudG1wIiAi
Y29uZnRlc3QuaW4iCisgICAgY3AgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCisgICAgJGFz
X2VjaG8gJ0VHUkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19wYXRoX0VHUkVQIiAnRUdS
RVAkJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8IGJyZWFr
CisgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8
fCBicmVhaworICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCArIDEgJiYgYWNfY291bnQ9JGFzX3Zh
bAorICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfRUdSRVBfbWF4LTB9OyB0aGVu
CisgICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBh
IGJldHRlciBvbmUKKyAgICAgIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIgorICAg
ICAgYWNfcGF0aF9FR1JFUF9tYXg9JGFjX2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBj
aGFycyBhcyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQg
LWd0IDEwICYmIGJyZWFrCisgIGRvbmUKKyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1w
IGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX0VHUkVQ
X2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9FR1JFUCI7IHRoZW4KKyAgICBhc19mbl9l
cnJvciAkPyAibm8gYWNjZXB0YWJsZSBlZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRI
X1NFUEFSQVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1CisgIGZpCitlbHNlCisgIGFjX2N2
X3BhdGhfRUdSRVA9JEVHUkVQCitmaQorCisgICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9FR1JFUCIgPiY1CiskYXNf
ZWNobyAiJGFjX2N2X3BhdGhfRUdSRVAiID4mNjsgfQorIEVHUkVQPSIkYWNfY3ZfcGF0aF9FR1JF
UCIKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBB
TlNJIEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2hlYWRlcl9zdGRjKzp9
IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1
ZGUgPHN0cmluZy5oPgorI2luY2x1ZGUgPGZsb2F0Lmg+CisKK2ludAorbWFpbiAoKQoreworCisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9eWVzCitlbHNlCisgIGFjX2N2X2hlYWRl
cl9zdGRjPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CisKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0
aGVuCisgICMgU3VuT1MgNC54IHN0cmluZy5oIGRvZXMgbm90IGRlY2xhcmUgbWVtKiwgY29udHJh
cnkgdG8gQU5TSS4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0cmluZy5oPgorCitfQUNFT0YK
K2lmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKKyAgJEVHUkVQICJt
ZW1jaHIiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0
ZGM9bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKKworZmkKKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVy
X3N0ZGMgPSB5ZXM7IHRoZW4KKyAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBub3QgZGVjbGFy
ZSBmcmVlLCBjb250cmFyeSB0byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkbGli
Lmg+CisKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUg
fAorICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisKK2Vsc2UKKyAgYWNf
Y3ZfaGVhZGVyX3N0ZGM9bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKKworZmkKKworaWYgdGVzdCAk
YWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KKyAgIyAvYmluL2NjIGluIElyaXgtNC4wLjUg
Z2V0cyBub24tQU5TSSBjdHlwZSBtYWNyb3MgdW5sZXNzIHVzaW5nIC1hbnNpLgorICBpZiB0ZXN0
ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIDoKK2Vsc2UKKyAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworI2luY2x1ZGUgPGN0eXBlLmg+CisjaW5jbHVkZSA8c3RkbGliLmg+CisjaWYgKCgnICcgJiAw
eDBGRikgPT0gMHgwMjApCisjIGRlZmluZSBJU0xPV0VSKGMpICgnYScgPD0gKGMpICYmIChjKSA8
PSAneicpCisjIGRlZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMpID8gJ0EnICsgKChjKSAtICdh
JykgOiAoYykpCisjZWxzZQorIyBkZWZpbmUgSVNMT1dFUihjKSBcCisJCSAgICgoJ2EnIDw9IChj
KSAmJiAoYykgPD0gJ2knKSBcCisJCSAgICAgfHwgKCdqJyA8PSAoYykgJiYgKGMpIDw9ICdyJykg
XAorCQkgICAgIHx8ICgncycgPD0gKGMpICYmIChjKSA8PSAneicpKQorIyBkZWZpbmUgVE9VUFBF
UihjKSAoSVNMT1dFUihjKSA/ICgoYykgfCAweDQwKSA6IChjKSkKKyNlbmRpZgorCisjZGVmaW5l
IFhPUihlLCBmKSAoKChlKSAmJiAhKGYpKSB8fCAoIShlKSAmJiAoZikpKQoraW50CittYWluICgp
Cit7CisgIGludCBpOworICBmb3IgKGkgPSAwOyBpIDwgMjU2OyBpKyspCisgICAgaWYgKFhPUiAo
aXNsb3dlciAoaSksIElTTE9XRVIgKGkpKQorCXx8IHRvdXBwZXIgKGkpICE9IFRPVVBQRVIgKGkp
KQorICAgICAgcmV0dXJuIDI7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1ubwor
ZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29u
ZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNv
bmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3RkYyIgPiY1CiskYXNfZWNobyAi
JGFjX2N2X2hlYWRlcl9zdGRjIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0g
eWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIFNURENfSEVBREVSUyAxIiA+PmNvbmZkZWZz
LmgKKworZmkKKworIyBPbiBJUklYIDUuMywgc3lzL3R5cGVzIGFuZCBpbnR0eXBlcy5oIGFyZSBj
b25mbGljdGluZy4KK2ZvciBhY19oZWFkZXIgaW4gc3lzL3R5cGVzLmggc3lzL3N0YXQuaCBzdGRs
aWIuaCBzdHJpbmcuaCBtZW1vcnkuaCBzdHJpbmdzLmggXAorCQkgIGludHR5cGVzLmggc3RkaW50
LmggdW5pc3RkLmgKK2RvIDoKKyAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVy
XyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSAi
JExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQKKyIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVhZGVyIlwiID0geCJ5ZXMiOyB0aGVu
IDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVf
JGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCisKKwor
ICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibWluaXgvY29uZmlnLmgi
ICJhY19jdl9oZWFkZXJfbWluaXhfY29uZmlnX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lm
IHRlc3QgIngkYWNfY3ZfaGVhZGVyX21pbml4X2NvbmZpZ19oIiA9IHh5ZXM7IHRoZW4gOgorICBN
SU5JWD15ZXMKK2Vsc2UKKyAgTUlOSVg9CitmaQorCisKKyAgaWYgdGVzdCAiJE1JTklYIiA9IHll
czsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfU09VUkNFIDEiID4+Y29uZmRlZnMu
aAorCisKKyRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF8xX1NPVVJDRSAyIiA+PmNvbmZkZWZzLmgK
KworCiskYXNfZWNobyAiI2RlZmluZSBfTUlOSVggMSIgPj5jb25mZGVmcy5oCisKKyAgZmkKKwor
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hl
dGhlciBpdCBpcyBzYWZlIHRvIGRlZmluZSBfX0VYVEVOU0lPTlNfXyIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworCisjCSAgZGVmaW5lIF9fRVhURU5TSU9OU19fIDEKKwkgICRhY19pbmNsdWRlc19kZWZh
dWx0CitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3NhZmVfdG9fZGVm
aW5lX19fZXh0ZW5zaW9uc19fPXllcworZWxzZQorICBhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4
dGVuc2lvbnNfXz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18i
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyIgPiY2
OyB9CisgIHRlc3QgJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fID0geWVzICYm
CisgICAgJGFzX2VjaG8gIiNkZWZpbmUgX19FWFRFTlNJT05TX18gMSIgPj5jb25mZGVmcy5oCisK
KyAgJGFzX2VjaG8gIiNkZWZpbmUgX0FMTF9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKyAgJGFz
X2VjaG8gIiNkZWZpbmUgX0dOVV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKyAgJGFzX2VjaG8g
IiNkZWZpbmUgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTIDEiID4+Y29uZmRlZnMuaAorCisgICRh
c19lY2hvICIjZGVmaW5lIF9UQU5ERU1fU09VUkNFIDEiID4+Y29uZmRlZnMuaAorCisKKyMgTWFr
ZSBzdXJlIHdlIGNhbiBydW4gY29uZmlnLnN1Yi4KKyRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmln
LnN1YiIgc3VuNCA+L2Rldi9udWxsIDI+JjEgfHwKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBy
dW4gJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICIkTElORU5PIiA1CisKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5
cGUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5cGUuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfYnVpbGQrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICBhY19idWlsZF9hbGlhcz0kYnVpbGRfYWxpYXMKK3Rlc3QgIngk
YWNfYnVpbGRfYWxpYXMiID0geCAmJgorICBhY19idWlsZF9hbGlhcz1gJFNIRUxMICIkYWNfYXV4
X2Rpci9jb25maWcuZ3Vlc3MiYAordGVzdCAieCRhY19idWlsZF9hbGlhcyIgPSB4ICYmCisgIGFz
X2ZuX2Vycm9yICQ/ICJjYW5ub3QgZ3Vlc3MgYnVpbGQgdHlwZTsgeW91IG11c3Qgc3BlY2lmeSBv
bmUiICIkTElORU5PIiA1CithY19jdl9idWlsZD1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcu
c3ViIiAkYWNfYnVpbGRfYWxpYXNgIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICIkU0hFTEwgJGFjX2F1
eF9kaXIvY29uZmlnLnN1YiAkYWNfYnVpbGRfYWxpYXMgZmFpbGVkIiAiJExJTkVOTyIgNQorCitm
aQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9idWlsZCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2J1aWxkIiA+JjY7IH0KK2Nhc2UgJGFjX2N2
X2J1aWxkIGluCisqLSotKikgOzsKKyopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHZhbHVlIG9m
IGNhbm9uaWNhbCBidWlsZCIgIiRMSU5FTk8iIDU7OworZXNhYworYnVpbGQ9JGFjX2N2X2J1aWxk
CithY19zYXZlX0lGUz0kSUZTOyBJRlM9Jy0nCitzZXQgeCAkYWNfY3ZfYnVpbGQKK3NoaWZ0Citi
dWlsZF9jcHU9JDEKK2J1aWxkX3ZlbmRvcj0kMgorc2hpZnQ7IHNoaWZ0CisjIFJlbWVtYmVyLCB0
aGUgZmlyc3QgY2hhcmFjdGVyIG9mIElGUyBpcyB1c2VkIHRvIGNyZWF0ZSAkKiwKKyMgZXhjZXB0
IHdpdGggb2xkIHNoZWxsczoKK2J1aWxkX29zPSQqCitJRlM9JGFjX3NhdmVfSUZTCitjYXNlICRi
dWlsZF9vcyBpbiAqXCAqKSBidWlsZF9vcz1gZWNobyAiJGJ1aWxkX29zIiB8IHNlZCAncy8gLy0v
ZydgOzsgZXNhYworCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBob3N0
IHN5c3RlbSB0eXBlLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2hvc3QrOn0gZmFsc2U7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICJ4JGhvc3Rf
YWxpYXMiID0geDsgdGhlbgorICBhY19jdl9ob3N0PSRhY19jdl9idWlsZAorZWxzZQorICBhY19j
dl9ob3N0PWAkU0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICRob3N0X2FsaWFzYCB8fAor
ICAgIGFzX2ZuX2Vycm9yICQ/ICIkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiAkaG9zdF9h
bGlhcyBmYWlsZWQiICIkTElORU5PIiA1CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9ob3N0IiA+JjUKKyRhc19lY2hvICIk
YWNfY3ZfaG9zdCIgPiY2OyB9CitjYXNlICRhY19jdl9ob3N0IGluCisqLSotKikgOzsKKyopIGFz
X2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHZhbHVlIG9mIGNhbm9uaWNhbCBob3N0IiAiJExJTkVOTyIg
NTs7Citlc2FjCitob3N0PSRhY19jdl9ob3N0CithY19zYXZlX0lGUz0kSUZTOyBJRlM9Jy0nCitz
ZXQgeCAkYWNfY3ZfaG9zdAorc2hpZnQKK2hvc3RfY3B1PSQxCitob3N0X3ZlbmRvcj0kMgorc2hp
ZnQ7IHNoaWZ0CisjIFJlbWVtYmVyLCB0aGUgZmlyc3QgY2hhcmFjdGVyIG9mIElGUyBpcyB1c2Vk
IHRvIGNyZWF0ZSAkKiwKKyMgZXhjZXB0IHdpdGggb2xkIHNoZWxsczoKK2hvc3Rfb3M9JCoKK0lG
Uz0kYWNfc2F2ZV9JRlMKK2Nhc2UgJGhvc3Rfb3MgaW4gKlwgKikgaG9zdF9vcz1gZWNobyAiJGhv
c3Rfb3MiIHwgc2VkICdzLyAvLS9nJ2A7OyBlc2FjCisKKworCisjIE00IE1hY3JvIGluY2x1ZGVz
CisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisK
KworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKyMgRW5hYmxlL2Rpc2FibGUgb3B0
aW9ucworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhzbSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV94c20rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV94c207
CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieHllcyI7IHRoZW4gOgorCisgICAg
YXhfY3ZfeHNtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieG5vIjsgdGhlbiA6
CisKKyAgICBheF9jdl94c209Im4iCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfeHNtOyB0aGVuIDoK
KworICAgIGF4X2N2X3hzbT0ibiIKKworZmkKK3hzbT0kYXhfY3ZfeHNtCisKKyMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2dpdGh0
dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9naXRodHRwOworZmkK
KworCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBh
eF9jdl9naXRodHRwPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAiID0gInhubyI7
IHRoZW4gOgorCisgICAgYXhfY3ZfZ2l0aHR0cD0ibiIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9n
aXRodHRwOyB0aGVuIDoKKworICAgIGF4X2N2X2dpdGh0dHA9Im4iCisKK2ZpCitnaXRodHRwPSRh
eF9jdl9naXRodHRwCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1tb25pdG9ycyB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVu
YWJsZXZhbD0kZW5hYmxlX21vbml0b3JzOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9tb25p
dG9ycyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9ycz0ibiIKKworZWxpZiB0
ZXN0ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbW9u
aXRvcnM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7IHRoZW4gOgorCisgICAg
YXhfY3ZfbW9uaXRvcnM9InkiCisKK2ZpCittb25pdG9ycz0kYXhfY3ZfbW9uaXRvcnMKKworIyBD
aGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVf
dnRwbStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3Z0cG07CitmaQor
CisKK2lmIHRlc3QgIngkZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2
X3Z0cG09InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieG5vIjsgdGhlbiA6CisK
KyAgICBheF9jdl92dHBtPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3Z0cG07IHRoZW4gOgor
CisgICAgYXhfY3ZfdnRwbT0ibiIKKworZmkKK3Z0cG09JGF4X2N2X3Z0cG0KKworIyBDaGVjayB3
aGV0aGVyIC0tZW5hYmxlLXhhcGkgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfeGFwaStz
ZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hhcGk7CitmaQorCisKK2lm
IHRlc3QgIngkZW5hYmxlX3hhcGkiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X3hhcGk9
InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfeGFwaSIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBh
eF9jdl94YXBpPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3hhcGk7IHRoZW4gOgorCisgICAg
YXhfY3ZfeGFwaT0ibiIKKworZmkKK3hhcGk9JGF4X2N2X3hhcGkKKworIyBDaGVjayB3aGV0aGVy
IC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3B5dGhv
bnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfcHl0aG9udG9v
bHM7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4bm8iOyB0aGVu
IDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3B5
dGhvbnRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9weXRob250b29scz0ieSIK
KworZWxpZiB0ZXN0IC16ICRheF9jdl9weXRob250b29sczsgdGhlbiA6CisKKyAgICBheF9jdl9w
eXRob250b29scz0ieSIKKworZmkKK3B5dGhvbnRvb2xzPSRheF9jdl9weXRob250b29scworCisj
IENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFi
bGVfb2NhbWx0b29sczsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgorCitlbGlmIHRlc3QgIngk
ZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9v
bHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6CisKKyAgICBh
eF9jdl9vY2FtbHRvb2xzPSJ5IgorCitmaQorb2NhbWx0b29scz0kYXhfY3Zfb2NhbWx0b29scwor
CisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdpdmVuLgoraWYgdGVzdCAi
JHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJs
ZV9taW5pdGVybTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInh5ZXMi
OyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxl
X21pbml0ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJuIgorCitl
bGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJt
PSJuIgorCitmaQorbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCisKKyMgQ2hlY2sgd2hldGhlciAt
LWVuYWJsZS1sb21vdW50IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2xvbW91bnQrc2V0
fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9sb21vdW50OworZmkKKworCitp
ZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9s
b21vdW50PSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInhubyI7IHRoZW4g
OgorCisgICAgYXhfY3ZfbG9tb3VudD0ibiIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9sb21vdW50
OyB0aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9Im4iCisKK2ZpCitsb21vdW50PSRheF9jdl9s
b21vdW50CisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCitpZiB0
ZXN0ICIke2VuYWJsZV9kZWJ1ZytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h
YmxlX2RlYnVnOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhl
biA6CisKKyAgICBheF9jdl9kZWJ1Zz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIg
PSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2VsaWYgdGVzdCAteiAk
YXhfY3ZfZGVidWc7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2ZpCitkZWJ1Zz0k
YXhfY3ZfZGVidWcKKworCisKKworCisKKworZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVT
CitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBp
biAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2Rv
bmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1Mr
PSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQ
UEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdT
ICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZM
QUdTICRBUFBFTkRfTERGTEFHUyIKKworCisKKworCisKKworCisKKworCisKKyMgQ2hlY2tzIGZv
ciBwcm9ncmFtcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNhdGUgb3V0cHV0IiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRlIG91dHB1dC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1NFRCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgICAgICAgICAgICBhY19zY3JpcHQ9cy9hYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJi
YmJiYmJiYmIvCisgICAgIGZvciBhY19pIGluIDEgMiAzIDQgNSA2IDc7IGRvCisgICAgICAgYWNf
c2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFjX3NjcmlwdCIKKyAgICAgZG9uZQorICAgICBlY2hv
ICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8IHNlZCA5OXEgPmNvbmZ0ZXN0LnNlZAorICAgICB7
IGFjX3NjcmlwdD07IHVuc2V0IGFjX3NjcmlwdDt9CisgICAgIGlmIHRlc3QgLXogIiRTRUQiOyB0
aGVuCisgIGFjX3BhdGhfU0VEX2ZvdW5kPWZhbHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2Vy
J3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfU0VEPSIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9TRUQiICYmICRhc190
ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sgZm9yIEdOVSBhY19w
YXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAjIENoZWNrIGZvciBHTlUg
JGFjX3BhdGhfU0VECitjYXNlIGAiJGFjX3BhdGhfU0VEIiAtLXZlcnNpb24gMj4mMWAgaW4KKypH
TlUqKQorICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIiBhY19wYXRoX1NFRF9mb3VuZD06
OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3Qu
aW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4i
ID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKKyAg
ICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNfZWNobyAnJyA+PiAiY29u
ZnRlc3QubmwiCisgICAgIiRhY19wYXRoX1NFRCIgLWYgY29uZnRlc3Quc2VkIDwgImNvbmZ0ZXN0
Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25m
dGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNf
Zm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAk
YWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURfbWF4LTB9OyB0aGVuCisgICAgICAjIEJlc3Qgb25l
IHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBvbmUKKyAgICAg
IGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiCisgICAgICBhY19wYXRoX1NFRF9tYXg9JGFj
X2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBzZWVtcyBtb3Jl
IHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCisgIGRvbmUK
KyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91
dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX1NFRF9mb3VuZCAmJiBicmVhayAzCisgICAgZG9u
ZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAteiAiJGFjX2N2
X3BhdGhfU0VEIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIHNlZCBj
b3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIkTElORU5PIiA1CisgIGZpCitlbHNlCisgIGFjX2N2
X3BhdGhfU0VEPSRTRUQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfU0VEIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
cGF0aF9TRUQiID4mNjsgfQorIFNFRD0iJGFjX2N2X3BhdGhfU0VEIgorICBybSAtZiBjb25mdGVz
dC5zZWQKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSck
Q0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSck
Q0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0
ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVy
X2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsgYWNf
d29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFj
X2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNl
Cithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwor
ZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRh
c19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisK
KworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhlbgorICBhY19jdF9DQz0kQ0MK
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGdjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3Byb2dfYWNfY3RfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitm
aQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhl
bgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf
d2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7
Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitlbHNlCisgIENDPSIkYWNfY3ZfcHJvZ19D
QyIKK2ZpCisKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgICAgICAgICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
e2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNf
c2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9v
bF9wcmVmaXh9Y2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3By
b2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgZmkKK2ZpCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGNjOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKKyAg
YWNfcHJvZ19yZWplY3RlZD1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCisgICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAi
L3Vzci91Y2IvY2MiOyB0aGVuCisgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKKyAgICAgICBj
b250aW51ZQorICAgICBmaQorICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCisgICMgV2UgZm91
bmQgYSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KKyAg
c2V0IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0CisgIGlmIHRlc3QgJCMgIT0gMDsgdGhl
bgorICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25l
LgorICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24g
d2lsbCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNl
bmFtZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBzaGlmdAorICAgIGFjX2N2X3Byb2df
Q0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBmaQorZmkKK2ZpCitmaQorQ0M9JGFj
X2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+
JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
Zm9yIGFjX3Byb2cgaW4gY2wuZXhlCisgIGRvCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9w
cm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19DQz0iJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2Zp
CitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNf
ZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisK
KyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKK2ZpCitpZiB0ZXN0IC16ICIkQ0Mi
OyB0aGVuCisgIGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKK2RvCisgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19hY19jdF9DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgIHRlc3QgLW4gIiRhY19jdF9D
QyIgJiYgYnJlYWsKK2RvbmUKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAg
ICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNh
YworICAgIENDPSRhY19jdF9DQworICBmaQorZmkKKworZmkKKworCit0ZXN0IC16ICIkQ0MiICYm
IHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBc
JFBBVEgKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9
CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21waWxlci4KKyRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVy
IHZlcnNpb24iID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2FjX2NvbXBpbGVyPSQyCitmb3IgYWNf
b3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCisgIHsgeyBhY190cnk9IiRh
Y19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8
ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRh
Y190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQor
ICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKKyAg
YWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgc2VkICcx
MGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4uCisgICAgICAgICAxMHEn
IGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAg
ZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfQorZG9uZQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMg
Y29tcGlsZXIuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19jb21waWxlcl9nbnUrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKK2ludAorbWFpbiAoKQoreworI2lmbmRlZiBfX0dOVUNfXworICAgICAgIGNob2tlIG1lCisj
ZW5kaWYKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2NvbXBpbGVyX2dudT15ZXMKK2Vsc2UKKyAgYWNf
Y29tcGlsZXJfZ251PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CithY19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGls
ZXJfZ251CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19jb21w
aWxlcl9nbnUiID4mNjsgfQoraWYgdGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCisg
IEdDQz15ZXMKK2Vsc2UKKyAgR0NDPQorZmkKK2FjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0K
K2FjX3NhdmVfQ0ZMQUdTPSRDRkxBR1MKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3Byb2dfY2NfZys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZworICAgYWNf
Y193ZXJyb3JfZmxhZz15ZXMKKyAgIGFjX2N2X3Byb2dfY2NfZz1ubworICAgQ0ZMQUdTPSItZyIK
KyAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9wcm9nX2NjX2c9eWVzCitlbHNlCisgIENGTEFHUz0iIgorICAgICAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitp
bnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9j
X3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY193ZXJyb3JfZmxh
Zz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCisJIENGTEFHUz0iLWciCisJIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKwor
aW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2c9eWVzCitm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBj
b25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nf
d2Vycm9yX2ZsYWcKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2Nf
ZyIgPiY2OyB9CitpZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0OyB0aGVuCisgIENGTEFH
Uz0kYWNfc2F2ZV9DRkxBR1MKK2VsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0geWVzOyB0aGVu
CisgIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItZyAtTzIiCisgIGVs
c2UKKyAgICBDRkxBR1M9Ii1nIgorICBmaQorZWxzZQorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsg
dGhlbgorICAgIENGTEFHUz0iLU8yIgorICBlbHNlCisgICAgQ0ZMQUdTPQorICBmaQorZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRDQyBv
cHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRD
QyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19j
Y19jODkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBhY19jdl9wcm9nX2NjX2M4OT1ubworYWNfc2F2ZV9DQz0kQ0MKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
bmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN5cy90eXBl
cy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisvKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVz
dHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4gICovCitzdHJ1Y3QgYnVm
IHsgaW50IHg7IH07CitGSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3Rh
dCAqLCBpbnQpOworc3RhdGljIGNoYXIgKmUgKHAsIGkpCisgICAgIGNoYXIgKipwOworICAgICBp
bnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07Cit9CitzdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykg
KGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCit7CisgIGNoYXIgKnM7CisgIHZhX2xpc3Qg
djsKKyAgdmFfc3RhcnQgKHYscCk7CisgIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7CisgIHZh
X2VuZCAodik7CisgIHJldHVybiBzOworfQorCisvKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21l
IHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcworICAgZnVuY3Rpb24gcHJv
dG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRz
LgorICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFk
IGFyZSBzaWxlbnRseSB0cmVhdGVkCisgICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMg
YW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0CisgICBwcm9wZXIgQU5TSSBtb2Rl
LiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCisg
ICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0w
IHRvIGdldCBzb21ldGhpbmcKKyAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KK2lu
dCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CisKKy8qIElCTSBDIDYgZm9y
IEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFy
YW1ldGVycworICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwor
I2RlZmluZSBGT08oeCkgJ3gnCitpbnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6
IC0xXTsKKworaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7CitzdHJ1Y3QgczEge2ludCAoKmYp
IChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9OworaW50IHBhaXJu
YW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAq
LCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsKK2NoYXIgKiphcmd2OworaW50CittYWluICgp
Cit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEp
ICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2ZvciBhY19hcmcgaW4g
JycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKKwktQWUgIi1BYSAtRF9I
UFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgorZG8KKyAgQ0M9IiRhY19zYXZlX0ND
ICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIg
JiYgYnJlYWsKK2RvbmUKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0NDPSRhY19zYXZlX0NDCisK
K2ZpCisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KKyAgeCkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm9u
ZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKKyAgeG5vKQor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB1bnN1
cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7OworICAqKQorICAg
IENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19jODkiID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citlc2FjCitpZiB0ZXN0ICJ4JGFjX2N2
X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCitmaQorCithY19leHQ9YworYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG
TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j
b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3JrcyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzLi4uICIgPiY2OyB9CitMTl9T
PSRhc19sbl9zCitpZiB0ZXN0ICIkTE5fUyIgPSAibG4gLXMiOyB0aGVuCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8g
InllcyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubywgdXNpbmcgJExOX1MiID4mNQorJGFzX2VjaG8gIm5vLCB1c2luZyAk
TE5fUyIgPiY2OyB9CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQoTUFLRSkiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKS4uLiAi
ID4mNjsgfQorc2V0IHggJHtNQUtFLW1ha2V9CithY19tYWtlPWAkYXNfZWNobyAiJDIiIHwgc2Vk
ICdzLysvcC9nOyBzL1teYS16QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwgXCR7YWNfY3ZfcHJvZ19t
YWtlXyR7YWNfbWFrZX1fc2V0Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2F0ID5jb25mdGVzdC5tYWtlIDw8XF9BQ0VPRgorU0hFTEwgPSAv
YmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBAQCUlJScKK19BQ0VPRgorIyBH
TlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmluZyAuLi4iLCB3aGljaCB3
b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtFLW1ha2V9IC1mIGNvbmZ0ZXN0Lm1ha2UgMj4v
ZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBAJSUlKikKKyAgICBldmFsIGFjX2N2X3Byb2df
bWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAqKQorICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtl
XyR7YWNfbWFrZX1fc2V0PW5vOzsKK2VzYWMKK3JtIC1mIGNvbmZ0ZXN0Lm1ha2UKK2ZpCitpZiBl
dmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1
CiskYXNfZWNobyAieWVzIiA+JjY7IH0KKyAgU0VUX01BS0U9CitlbHNlCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAi
bm8iID4mNjsgfQorICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFrZX0iCitmaQorCisjIEZpbmQg
YSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZlciBhIEMgcHJvZ3JhbSAoZmFzdGVyKSwK
KyMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFub3RoZXIuICBCdXQgYXZvaWQgdGhlIGJy
b2tlbiBvcgorIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6CisjIFN5c1YgL2V0Yy9pbnN0YWxsLCAv
dXNyL3NiaW4vaW5zdGFsbAorIyBTdW5PUyAvdXNyL2V0Yy9pbnN0YWxsCisjIElSSVggL3NiaW4v
aW5zdGFsbAorIyBBSVggL2Jpbi9pbnN0YWxsCisjIEFtaWdhT1MgL0MvaW5zdGFsbCwgd2hpY2gg
aW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlzY3MKKyMgQUlYIDQgL3Vzci9iaW4vaW5z
dGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhvdXQgYSAtZyBmbGFnCisjIEFGUyAvdXNy
L2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5kbGVzIG5vbmV4aXN0ZW50IGFyZ3MKKyMg
U1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1c2UgdGhlIG5vbmV4aXN0ZW50
IGdyb3VwICJzdGFmZiIKKyMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3aGljaCBoYXMgYSBjb21w
bGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYworIyAuL2luc3RhbGwsIHdoaWNoIGNhbiBiZSBlcnJv
bmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2luc3RhbGwuc2guCisjIFJlamVjdCBpbnN0
YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwgbXVsdGlwbGUgZmlsZXMuCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhIEJTRC1jb21w
YXRpYmxlIGluc3RhbGwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGEgQlNELWNvbXBh
dGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQoraWYgdGVzdCAteiAiJElOU1RBTEwiOyB0aGVuCitp
ZiAke2FjX2N2X3BhdGhfaW5zdGFsbCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICAjIEFjY291bnQgZm9yIHBlb3BsZSB3aG8gcHV0
IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50cy4KK2Nhc2UgJGFzX2Rpci8gaW4gIygo
CisgIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKKyAgL2V0Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNy
L2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmluLyogfCBcCisgID86W1xcL11vczJbXFwv
XWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11JTlNUQUxMW1xcL10qIHwgXAorICAvdXNy
L3VjYi8qICkgOzsKKyAgKikKKyAgICAjIE9TRjEgYW5kIFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIg
b3duIG5hbWVzIGZvciBpbnN0YWxsLgorICAgICMgRG9uJ3QgdXNlIGluc3RhbGxic2QgZnJvbSBP
U0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9vdAorICAgICMgYnkgZGVmYXVsdC4KKyAg
ICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0IGluc3RhbGw7IGRvCisgICAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKwlpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVuCisJICBpZiB0ZXN0ICRhY19wcm9nID0g
aW5zdGFsbCAmJgorCSAgICBncmVwIGRzcG1zZyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4
dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgQUlYIGluc3RhbGwuICBJdCBoYXMgYW4g
aW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4KKwkgICAgOgorCSAgZWxpZiB0ZXN0ICRh
Y19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIHB3cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgcHJvZ3JhbS1zcGVjaWZp
YyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1cy0tZG9uJ3QgdXNlLgorCSAgICA6CisJ
ICBlbHNlCisJICAgIHJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRp
cgorCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQorCSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0
LnR3bworCSAgICBta2RpciBjb25mdGVzdC5kaXIKKwkgICAgaWYgIiRhc19kaXIvJGFjX3Byb2ck
YWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0
LmRpciIgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0
LnR3byAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0Lm9uZSAmJgorCSAg
ICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0LnR3bworCSAgICB0aGVuCisJICAgICAg
YWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IC1jIgorCSAg
ICAgIGJyZWFrIDMKKwkgICAgZmkKKwkgIGZpCisJZmkKKyAgICAgIGRvbmUKKyAgICBkb25lCisg
ICAgOzsKK2VzYWMKKworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK3JtIC1yZiBjb25mdGVz
dC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgorCitmaQorICBpZiB0ZXN0ICIke2FjX2N2
X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgorICAgIElOU1RBTEw9JGFjX2N2X3BhdGhf
aW5zdGFsbAorICBlbHNlCisgICAgIyBBcyBhIGxhc3QgcmVzb3J0LCB1c2UgdGhlIHNsb3cgc2hl
bGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQorICAgICMgdmFsdWUgZm9yIElOU1RBTEwgd2l0aGlu
IGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0IHdpbGwKKyAgICAjIGJyZWFrIG90aGVy
IHBhY2thZ2VzIHVzaW5nIHRoZSBjYWNoZSBpZiB0aGF0IGRpcmVjdG9yeSBpcworICAgICMgcmVt
b3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRpdmUgbmFtZS4KKyAgICBJTlNUQUxMPSRh
Y19pbnN0YWxsX3NoCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKKyRhc19lY2hvICIkSU5TVEFMTCIgPiY2OyB9
CisKKyMgVXNlIHRlc3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlzaGFuZGxlcyBicmFjZXMgaW4g
JHt2YXItdmFsfS4KKyMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9zZSBicmFjZSBlbmRzIHRoZSB2
YXJpYWJsZSBzdWJzdGl0dXRpb24uCit0ZXN0IC16ICIkSU5TVEFMTF9QUk9HUkFNIiAmJiBJTlNU
QUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNUQUxMX1NDUklQVCIgJiYg
SU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNUQUxMX0RBVEEiICYm
IElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisKKyMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfUEVSTCs6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFBF
UkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfUEVSTD0iJFBFUkwiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQor
ICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJM
PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitQRVJMPSRhY19jdl9wYXRoX1BFUkwKK2lmIHRlc3QgLW4g
IiRQRVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJFBFUkwiID4mNQorJGFzX2VjaG8gIiRQRVJMIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke1BFUkx9IiA9PSB4Im5vIgor
dGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBwZXJsLCBwbGVhc2UgaW5z
dGFsbCBwZXJsIiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
YnJjdGwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
IGJyY3RsOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9CUkNUTCs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEJSQ1RMIGlu
CisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JSQ1RMPSIkQlJDVEwiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBh
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRI
CitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u
CisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9w
YXRoX0JSQ1RMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0JSQ1RMIiAmJiBhY19jdl9wYXRoX0JSQ1RM
PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitCUkNUTD0kYWNfY3ZfcGF0aF9CUkNUTAoraWYgdGVzdCAt
biAiJEJSQ1RMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJEJSQ1RMIiA+JjUKKyRhc19lY2hvICIkQlJDVEwiID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7QlJDVEx9IiA9PSB4
Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBicmN0bCwgcGxl
YXNlIGluc3RhbGwgYnJjdGwiICIkTElORU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJpcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgaXA7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0lQKzp9IGZhbHNlOyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkSVAgaW4KKyAg
W1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfSVA9IiRJUCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfSVA9IiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVz
dCAteiAiJGFjX2N2X3BhdGhfSVAiICYmIGFjX2N2X3BhdGhfSVA9Im5vIgorICA7OworZXNhYwor
ZmkKK0lQPSRhY19jdl9wYXRoX0lQCitpZiB0ZXN0IC1uICIkSVAiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSVAiID4mNQorJGFzX2Vj
aG8gIiRJUCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitp
ZiB0ZXN0IHgiJHtJUH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kIGlwLCBwbGVhc2UgaW5zdGFsbCBpcCIgIiRMSU5FTk8iIDUKK2ZpCisjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KK3NldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Bh
dGhfQklTT04rOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBjYXNlICRCSVNPTiBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0
aF9CSVNPTj0iJEJJU09OIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEg
cGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CSVNPTj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25l
CisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CSVNP
TiIgJiYgYWNfY3ZfcGF0aF9CSVNPTj0ibm8iCisgIDs7Citlc2FjCitmaQorQklTT049JGFjX2N2
X3BhdGhfQklTT04KK2lmIHRlc3QgLW4gIiRCSVNPTiI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIgPiY1CiskYXNfZWNobyAi
JEJJU09OIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lm
IHRlc3QgeCIke0JJU09OfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5h
YmxlIHRvIGZpbmQgYmlzb24sIHBsZWFzZSBpbnN0YWxsIGJpc29uIiAiJExJTkVOTyIgNQorZmkK
KyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZmxleCIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgZmxleDsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3BhdGhfRkxFWCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhc2UgJEZMRVggaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2
X3BhdGhfRkxFWD0iJEZMRVgiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0ZMRVg9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9u
ZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfRkxF
WCIgJiYgYWNfY3ZfcGF0aF9GTEVYPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitGTEVYPSRhY19jdl9w
YXRoX0ZMRVgKK2lmIHRlc3QgLW4gIiRGTEVYIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEZMRVgiID4mNQorJGFzX2VjaG8gIiRGTEVY
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3Qg
eCIke0ZMRVh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8g
ZmluZCBmbGV4LCBwbGVhc2UgaW5zdGFsbCBmbGV4IiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3Qg
IngkeGFwaSIgPSAieHkiOyB0aGVuIDoKKworICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiY3VybC1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15IGN1cmwtY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9DVVJM
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2FzZSAkQ1VSTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9DVVJMPSIk
Q1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7
CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lG
Uz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAmJiBhY19jdl9w
YXRoX0NVUkw9Im5vIgorICA7OworZXNhYworZmkKK0NVUkw9JGFjX2N2X3BhdGhfQ1VSTAoraWYg
dGVzdCAtbiAiJENVUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1CiskYXNfZWNobyAiJENVUkwiID4mNjsgfQorZWxz
ZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7Q1VSTH0iID09
IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwtY29u
ZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9wYXRoX1hNTCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFhNTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0
aF9YTUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitYTUw9JGFjX2N2
X3BhdGhfWE1MCitpZiB0ZXN0IC1uICIkWE1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1CiskYXNfZWNobyAiJFhNTCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitpZiB0ZXN0IHgi
JHtYTUx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu
ZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWciICIkTElORU5PIiA1Citm
aQorCitmaQoraWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7IHRoZW4gOgorCisgICAgICAj
IGNoZWNraW5nIGZvciBvY2FtbGMKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxj
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfT0NBTUxD
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiRPQ0FNTEMi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09D
QU1MQz0kYWNfY3ZfcHJvZ19PQ0FNTEMKK2lmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+
JjUKKyRhc19lY2hvICIkT0NBTUxDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEMiOyB0aGVuCisg
IGFjX2N0X09DQU1MQz0kT0NBTUxDCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2Nh
bWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBv
Y2FtbGM7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQys6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSIkYWNf
Y3RfT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxDPSJvY2FtbGMiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNf
Y3RfT0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQworaWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTEMiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTEMiID0geDsgdGhlbgorICAgIE9DQU1MQz0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxDPSRhY19jdF9PQ0FNTEMK
KyAgZmkKK2Vsc2UKKyAgT0NBTUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMiCitmaQorCisKKyAgaWYg
dGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FNTFZFUlNJT049YCRPQ0FNTEMg
LXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJ2AKKyAgICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIHZlcnNpb24g
aXMgJE9DQU1MVkVSU0lPTiIgPiY1CiskYXNfZWNobyAiT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxW
RVJTSU9OIiA+JjY7IH0KKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAorICAgICBp
ZiB0ZXN0ICIkT0NBTUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMg
LXdoZXJlIDI+L2Rldi9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRg
CisgICAgIGVsc2UKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IE9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY1
CiskYXNfZWNobyAiT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjY7
IH0KKyAgICAgZmkKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IE9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNQorJGFzX2VjaG8g
Ik9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQorCisKKworCisgICAgICMg
Y2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJv
Z19PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FN
TE9QVD0iJE9DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UK
K2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBB
VEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2
X3Byb2dfT0NBTUxPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK2ZpCitmaQorT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKK2lmIHRlc3Qg
LW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAiJE9DQU1MT1BUIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxPUFQ9JE9DQU1MT1BU
CisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0OyBhY193b3JkPSQy
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN
TE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0iJGFjX2N0X09DQU1MT1BU
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxPUFQ9Im9jYW1sb3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09D
QU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3RfT0NBTUxPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4
JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE9QVD0ibm8iCisgIGVsc2UKKyAg
ICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw
bGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxPUFQ9JGFj
X2N0X09DQU1MT1BUCisgIGZpCitlbHNlCisgIE9DQU1MT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTE9Q
VCIKK2ZpCisKKyAgICAgT0NBTUxCRVNUPWJ5dGUKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9
ICJubyI7IHRoZW4KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdB
Uk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0
ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mMjt9CisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAk
T0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJ
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZl
cnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNjsgfQor
CSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZp
CisKKworCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAgICAgaWYgdGVzdCAtbiAi
JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0OyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxDRE9U
T1BUIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJE9DQU1MQ0RPVE9QVCIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0i
JHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQor
ZmkKK09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQKK2lmIHRlc3QgLW4gIiRP
Q0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxDRE9UT1BU
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0
ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MQ0RP
VE9QVD0kT0NBTUxDRE9UT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxj
Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
b2NhbWxjLm9wdDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9U
T1BUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTENET1RPUFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9Im9jYW1sYy5v
cHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQor
ICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NBTUxDRE9UT1BUPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RP
VE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTENE
T1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsgdGhlbgorICAgIE9DQU1MQ0RPVE9QVD0i
bm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGlu
Cit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVk
IHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisg
ICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RPUFQKKyAgZmkKK2Vsc2UKKyAgT0NBTUxD
RE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCitmaQorCisgICAgIGlmIHRlc3QgIiRP
Q0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12
IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRU
TVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZyb20g
b2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb25zIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9CisJZWxzZQor
CSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgIT0gIm5vIiA7IHRo
ZW4KKwlpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxvcHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9Q
VCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE9Q
VERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQu
b3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUK
KyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MT1BURE9UT1BUPSRhY19j
dl9wcm9nX09DQU1MT1BURE9UT1BUCitpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NB
TUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVERPVE9QVCIgPiY2OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MT1BURE9UT1BUPSRPQ0FN
TE9QVERPVE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0Lm9wdCIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxv
cHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9Q
VCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9Im9j
YW1sb3B0Lm9wdCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTE9Q
VERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19lY2hv
ICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPSB4OyB0aGVu
CisgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xf
d2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MT1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERP
VE9QVAorICBmaQorZWxzZQorICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRE
T1RPUFQiCitmaQorCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCisJ
ICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1M
VkVSU0lPTiIgOyB0aGVuCisJICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0
IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsg
b2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCSAgIGVsc2UKKwkgICAgICBPQ0FNTE9Q
VD0kT0NBTUxPUFRET1RPUFQKKwkgICBmaQorICAgICAgICBmaQorICAgICBmaQorCisKKyAgZmkK
KworCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAgaWYgdGVzdCAtbiAiJGFj
X3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHth
Y19jdl9wcm9nX09DQU1MKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX09D
QU1MPSIkT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19PQ0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwor
ZmkKK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhl
bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9D
QU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MIjsgdGhl
bgorICBhY19jdF9PQ0FNTD0kT0NBTUwKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
b2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X09DQU1MKzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAt
biAiJGFjX2N0X09DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MPSIkYWNfY3Rf
T0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAg
SUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTD0ib2NhbWwiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NB
TUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRo
ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KK2Vsc2UKKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
KyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUwiID0g
eDsgdGhlbgorICAgIE9DQU1MPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGlu
ZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRo
IGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9z
cyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dh
cm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTD0kYWNfY3RfT0NBTUwKKyAgZmkKK2Vsc2UKKyAg
T0NBTUw9IiRhY19jdl9wcm9nX09DQU1MIgorZmkKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1s
ZGVwCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9j
YW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTERFUCs6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4g
IiRPQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0iJE9DQU1MREVQIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxkZXAiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NB
TUxERVA9JGFjX2N2X3Byb2dfT0NBTUxERVAKK2lmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TERFUCIgPiY1CiskYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERF
UCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxERVA9JE9DQU1MREVQCisgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTERFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MREVQPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MREVQCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxE
RVAiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7
IHRoZW4KKyAgICBPQ0FNTERFUD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxp
bmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93
YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCisgIGZpCitl
bHNlCisgIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKK2ZpCisKKworICAjIGNoZWNr
aW5nIGZvciBvY2FtbG1rdG9wCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0
b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2df
T0NBTUxNS1RPUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9nX09D
QU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
K2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIg
aW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAg
IGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MTUtUT1A9JGFjX2N2X3Byb2dfT0NBTUxN
S1RPUAoraWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNo
byAiJE9DQU1MTUtUT1AiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2Zp
CisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCisgIGFj
X2N0X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICJvY2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTE1LVE9QKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxNS1RPUD0iJGFjX2N0X09DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9w
IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAg
ZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MTUtUT1A9JGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3RfT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MTUtUT1AiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LVE9QPSJubyIKKyAgZWxzZQorICAg
IGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv
b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE1LVE9QPSRh
Y19jdF9PQ0FNTE1LVE9QCisgIGZpCitlbHNlCisgIE9DQU1MTUtUT1A9IiRhY19jdl9wcm9nX09D
QU1MTUtUT1AiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta2xpYgorICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWI7IGFj
X3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX09DQU1MTUtMSUIrOn0gZmFsc2U7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxN
S0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIkT0NBTUxNS0xJQiIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVf
SUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0
IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitP
Q0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIKK2lmIHRlc3QgLW4gIiRPQ0FNTE1LTElC
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJE9DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdF9PQ0FNTE1LTElCPSRPQ0FNTE1LTElCCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta2xpYiIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxta2xpYjsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQis6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTE1LTElCIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9P
Q0FNTE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxNS0xJQj0ib2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
KyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkK
K2ZpCithY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIKK2lmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQorJGFzX2Vj
aG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS0xJQiIgPSB4OyB0aGVuCisgICAg
T0NBTUxNS0xJQj0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rv
b2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVz
IDs7Citlc2FjCisgICAgT0NBTUxNS0xJQj0kYWNfY3RfT0NBTUxNS0xJQgorICBmaQorZWxzZQor
ICBPQ0FNTE1LTElCPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIgorZmkKKworCisgICMgY2hlY2tp
bmcgZm9yIG9jYW1sZG9jCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rv
b2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTERP
Qys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERPQz0iJE9D
QU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NB
TUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
K2ZpCitmaQorT0NBTUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKK2lmIHRlc3QgLW4gIiRPQ0FN
TERPQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRPQ0FNTERPQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3RfT0NBTUxET0M9JE9DQU1MRE9DCisgICMgRXh0
cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkb2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRo
ZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0iJGFjX2N0X09DQU1MRE9DIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9Im9j
YW1sZG9jIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MRE9DPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MRE9DCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3RfT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERPQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09D
QU1MRE9DIiA9IHg7IHRoZW4KKyAgICBPQ0FNTERPQz0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxET0M9JGFjX2N0X09DQU1M
RE9DCisgIGZpCitlbHNlCisgIE9DQU1MRE9DPSIkYWNfY3ZfcHJvZ19PQ0FNTERPQyIKK2ZpCisK
KworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X3Byb2dfT0NBTUxCVUlMRCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgorICBh
Y19jdl9wcm9nX09DQU1MQlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190b29sX3ByZWZpeH1vY2Ft
bGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MQlVJTEQ9JGFjX2N2
X3Byb2dfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIg
PiY1CiskYXNfZWNobyAiJE9DQU1MQlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQlVJTEQi
OyB0aGVuCisgIGFjX2N0X09DQU1MQlVJTEQ9JE9DQU1MQlVJTEQKKyAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KK3NldCBkdW1teSBvY2FtbGJ1aWxkOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTEJVSUxEKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVu
CisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0iJGFjX2N0X09DQU1MQlVJTEQiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxE
PSJvY2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAg
ZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1M
QlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1M
QlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KKyAgICBPQ0FNTEJVSUxEPSJubyIK
KyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3ll
czopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVz
aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBP
Q0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgIGZpCitlbHNlCisgIE9DQU1MQlVJTEQ9IiRh
Y19jdl9wcm9nX09DQU1MQlVJTEQiCitmaQorCisKKyAgICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICAgICAgaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAi
eHllcyI7IHRoZW4gOgorCisgICAgICAgICAgICBhc19mbl9lcnJvciAkPyAiT2NhbWwgdG9vbHMg
ZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1sIiAiJExJTkVOTyIgNQorZmkKKyAgICAg
ICAgb2NhbWx0b29scz0ibiIKKworZmkKKworZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiYmFzaCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgYmFzaDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfQkFTSCs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEJBU0ggaW4K
KyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQkFTSD0iJEJBU0giICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRo
X0JBU0g9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQkFTSCIgJiYgYWNfY3ZfcGF0aF9CQVNIPSJubyIK
KyAgOzsKK2VzYWMKK2ZpCitCQVNIPSRhY19jdl9wYXRoX0JBU0gKK2lmIHRlc3QgLW4gIiRCQVNI
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJEJBU0giID4mNQorJGFzX2VjaG8gIiRCQVNIIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JBU0h9IiA9PSB4Im5vIgordGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBiYXNoLCBwbGVhc2UgaW5zdGFsbCBi
YXNoIiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhl
biA6CisKKyAgICBpZiBlY2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4vIjsgdGhlbiA6CisKKyAg
ICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhP
TlBBVEhgCisKK2VsaWYgdGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgorICBQWVRIT049InB5dGhv
biIKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3Qg
YW4gYWJzb2x1dGUgcGF0aCIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9QWVRI
T05QQVRIKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf
cGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUFlUSE9OUEFUSD0iJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBBVEg9Im5vIgor
ICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAoraWYgdGVz
dCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNfZWNobyAiJFBZVEhPTlBB
VEgiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVz
dCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElORU5PIiA1
CitmaQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBv
cnQgc3lzOyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAoraWYgdGVz
dCAiJD8iICE9ICIwIgordGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFg
CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CisgICAgYXNfZm5fZXJyb3IgJD8gIiRweXRob25f
dmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgMi4zIiAiJExJ
TkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQorICAgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhvbiB4
bWwuZG9tLm1pbmlkb20iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB4bWwu
ZG9tLm1pbmlkb20uLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBvcnQgeG1sLmRvbS5taW5p
ZG9tJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1v
ZHVsZSIgIiRMSU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBweXRob24gZGV2ZWwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiBkZXZl
bC4uLiAiID4mNjsgfQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQgb3MucGF0aCwgc3lzCitmb3Ig
cCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcvTWFrZWZp
bGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEpCisnID4gL2Rldi9udWxsIDI+
JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KKyAgICBhc19mbl9lcnJvciAkPyAiUHl0aG9uIGRldmVsIHBhY2thZ2Ugbm90IGZvdW5kIiAi
JExJTkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQorCitmaQor
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeGdldHRleHQ7IGFjX3dvcmQ9JDIKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193
b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9wYXRoX1hHRVRURVhUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkWEdFVFRFWFQgaW4KKyAgW1xcL10qIHwgPzpb
XFwvXSopCisgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfWEdFVFRF
WFQ9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
KyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWEdFVFRFWFQiICYmIGFjX2N2X3BhdGhfWEdFVFRFWFQ9
Im5vIgorICA7OworZXNhYworZmkKK1hHRVRURVhUPSRhY19jdl9wYXRoX1hHRVRURVhUCitpZiB0
ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkWEdFVFRFWFQiID4mNQorJGFzX2VjaG8gIiRYR0VUVEVYVCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitpZiB0ZXN0IHgi
JHtYR0VUVEVYVH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIHhnZXR0ZXh0LCBwbGVhc2UgaW5zdGFsbCB4Z2V0dGV4dCIgIiRMSU5FTk8iIDUKK2Zp
CitpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgICMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmFkbSIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgdWRldmFkbTsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3BhdGhfVURFVkFETSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhc2UgJFVERVZBRE0gaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFj
X2N2X3BhdGhfVURFVkFETT0iJFVERVZBRE0iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT
CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1VERVZBRE09IiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsg
MgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFj
X2N2X3BhdGhfVURFVkFETSIgJiYgYWNfY3ZfcGF0aF9VREVWQURNPSJubyIKKyAgOzsKK2VzYWMK
K2ZpCitVREVWQURNPSRhY19jdl9wYXRoX1VERVZBRE0KK2lmIHRlc3QgLW4gIiRVREVWQURNIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JFVERVZBRE0iID4mNQorJGFzX2VjaG8gIiRVREVWQURNIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19l
Y2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0geCJu
byIKKyAgICB0aGVuCisgICAgICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmlu
Zm8iLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHVk
ZXZpbmZvOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9VREVWSU5GTys6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFVERVZJ
TkZPIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1VERVZJTkZPPSIkVURF
VklORk8iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7
OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNf
ZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K
KyAgICBhY19jdl9wYXRoX1VERVZJTkZPPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1VERVZJTkZPIiAm
JiBhY19jdl9wYXRoX1VERVZJTkZPPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitVREVWSU5GTz0kYWNf
Y3ZfcGF0aF9VREVWSU5GTworaWYgdGVzdCAtbiAiJFVERVZJTkZPIjsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFVERVZJTkZPIiA+JjUK
KyRhc19lY2hvICIkVURFVklORk8iID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKworICAgICAgICBpZiB0ZXN0IHgiJHtVREVWSU5GT30iID09IHgibm8iCisgICAg
ICAgIHRoZW4KKyAgICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB1ZGV2
YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2IiAiJExJTkVOTyIgNQorICAgICAg
ICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50ICRORn0n
YAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwgYXdrICd7
cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5CisgICAg
dGhlbgorICAgICAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImhvdHBsdWciLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGhvdHBsdWc7IGFj
X3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0hPVFBMVUcrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRIT1RQTFVHIGluCisgIFtc
XC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0hPVFBMVUc9IiRIT1RQTFVHIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0
aF9IT1RQTFVHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0hPVFBMVUciICYmIGFjX2N2X3BhdGhfSE9U
UExVRz0ibm8iCisgIDs7Citlc2FjCitmaQorSE9UUExVRz0kYWNfY3ZfcGF0aF9IT1RQTFVHCitp
ZiB0ZXN0IC1uICIkSE9UUExVRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRIT1RQTFVHIiA+JjUKKyRhc19lY2hvICIkSE9UUExVRyIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgICAgIGlm
IHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBh
c19mbl9lcnJvciAkPyAidWRldiBpcyB0b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3Ig
bGF0ZXIiICIkTElORU5PIiA1CisgICAgICAgIGZpCisgICAgZmkKK2Vsc2UKKyAgICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgInZuY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSB2bmNvbmZpZzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3BhdGhfVk5DT05GSUcrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBjYXNlICRWTkNPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJFZOQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9WTkNPTkZJRyIgJiYgYWNfY3ZfcGF0aF9WTkNPTkZJRz0ibm8iCisg
IDs7Citlc2FjCitmaQorVk5DT05GSUc9JGFjX2N2X3BhdGhfVk5DT05GSUcKK2lmIHRlc3QgLW4g
IiRWTkNPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRWTkNPTkZJRyIgPiY1CiskYXNfZWNobyAiJFZOQ09ORklHIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtW
TkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBhc19mbl9lcnJvciAkPyAiTm90
IGEgTGludXggc3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmQiICIkTElORU5PIiA1CisgICAg
ZmkKK2ZpCisKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK2lmIHRlc3QgLWQgIiRwcmVmaXgvbGli
NjQiOyB0aGVuIDoKKworICAgIExJQl9QQVRIPSJsaWI2NCIKKworZWxzZQorCisgICAgTElCX1BB
VEg9ImxpYiIKKworZmkKKworCisjIENoZWNrcyBmb3IgbGlicmFyaWVzLgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW9fc2V0dXAgaW4gLWxh
aW8iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X2xpYl9haW9faW9fc2V0dXArOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJT
PSRMSUJTCitMSUJTPSItbGFpbyAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFu
eSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIg
YmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWls
dGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAq
LworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgaW9fc2V0dXAg
KCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBpb19zZXR1cCAoKTsKKyAgOworICByZXR1cm4g
MDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9saWJfYWlvX2lvX3NldHVwPXllcworZWxzZQorICBhY19jdl9saWJfYWlvX2lvX3NldHVw
PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisg
ICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xp
Yl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID4mNQorJGFzX2VjaG8gIiRhY19jdl9s
aWJfYWlvX2lvX3NldHVwIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2Fpb19pb19zZXR1
cCIgPSB4eWVzOyB0aGVuIDoKKyAgc3lzdGVtX2Fpbz0ieSIKK2Vsc2UKKyAgc3lzdGVtX2Fpbz0i
biIKK2ZpCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgTUQ1IGluIC1sY3J5cHRvIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBN
RDUgaW4gLWxjcnlwdG8uLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX2NyeXB0b19NRDUrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19j
aGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGNyeXB0byAgJExJQlMiCitjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu
IGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0
eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUg
d291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisj
ZW5kaWYKK2NoYXIgTUQ1ICgpOworaW50CittYWluICgpCit7CityZXR1cm4gTUQ1ICgpOworICA7
CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6CisgIGFjX2N2X2xpYl9jcnlwdG9fTUQ1PXllcworZWxzZQorICBhY19jdl9saWJfY3J5
cHRvX01ENT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19j
aGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY1CiskYXNfZWNobyAiJGFj
X2N2X2xpYl9jcnlwdG9fTUQ1IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2NyeXB0b19N
RDUiID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUg
SEFWRV9MSUJDUllQVE8gMQorX0FDRU9GCisKKyAgTElCUz0iLWxjcnlwdG8gJExJQlMiCisKK2Vs
c2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIGxpYmNyeXB0byIgIiRMSU5FTk8i
IDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcyIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xp
Yl9leHQyZnNfZXh0MmZzX29wZW4yKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0i
LWxleHQyZnMgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBf
X2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGV4dDJmc19vcGVuMiAoKTsKK2lu
dAorbWFpbiAoKQoreworcmV0dXJuIGV4dDJmc19vcGVuMiAoKTsKKyAgOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2V4dDJmc19l
eHQyZnNfb3BlbjI9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0k
YWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID4mNQor
JGFzX2VjaG8gIiRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPiY2OyB9CitpZiB0ZXN0
ICJ4JGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA9IHh5ZXM7IHRoZW4gOgorICBsaWJl
eHQyZnM9InkiCitlbHNlCisgIGxpYmV4dDJmcz0ibiIKK2ZpCisKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZl
ciBpbiAtbGdjcnlwdCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNo
X2J1ZmZlciBpbiAtbGdjcnlwdC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfZ2NyeXB0X2dj
cnlfbWRfaGFzaF9idWZmZXIrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGdj
cnlwdCAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwg
cHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWln
aHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0
cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3Bs
dXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZ2NyeV9tZF9oYXNoX2J1ZmZlciAoKTsK
K2ludAorbWFpbiAoKQoreworcmV0dXJuIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7CisgIDsKKyAg
cmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVu
IDoKKyAgYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyPXllcworZWxzZQorICBh
Y19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXI9bm8KK2ZpCitybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQg
Y29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2dj
cnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2djcnlw
dF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2djcnlw
dF9nY3J5X21kX2hhc2hfYnVmZmVyIiA9IHh5ZXM7IHRoZW4gOgorICBsaWJnY3J5cHQ9InkiCitl
bHNlCisgIGxpYmdjcnlwdD0ibiIKK2ZpCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgcHRocmVhZF9jcmVhdGUgaW4gLWxwdGhyZWFkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBwdGhyZWFkX2NyZWF0ZSBpbiAtbHB0aHJlYWQu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGUrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVj
a19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHB0aHJlYWQgICRMSUJTIgorY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBl
cnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlw
ZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv
dWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2Vu
ZGlmCitjaGFyIHB0aHJlYWRfY3JlYXRlICgpOworaW50CittYWluICgpCit7CityZXR1cm4gcHRo
cmVhZF9jcmVhdGUgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9j
cmVhdGU9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlPW5vCitm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29u
ZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZl
X0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGUiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9s
aWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZSIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorICBhc19m
bl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGlicHRocmVhZCIgIiRMSU5FTk8iIDUKK2ZpCisK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNs
b2NrX2dldHRpbWUgaW4gLWxydCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgY2xvY2tf
Z2V0dGltZSBpbiAtbHJ0Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9ydF9jbG9ja19nZXR0
aW1lKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxydCAgJExJQlMiCitjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMu
aC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lk
IGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVy
biB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5
cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMi
CisjZW5kaWYKK2NoYXIgY2xvY2tfZ2V0dGltZSAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJu
IGNsb2NrX2dldHRpbWUgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRp
bWU9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lPW5vCitmaQorcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3J0X2Nsb2Nr
X2dldHRpbWUiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZSIg
PSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZF
X0xJQlJUIDEKK19BQ0VPRgorCisgIExJQlM9Ii1scnQgJExJQlMiCisKK2ZpCisKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHV1aWRfY2xlYXIg
aW4gLWx1dWlkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1s
dXVpZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfdXVpZF91dWlkX2NsZWFyKzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tf
bGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx1dWlkICAkTElCUyIKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKwor
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
CisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgor
Y2hhciB1dWlkX2NsZWFyICgpOworaW50CittYWluICgpCit7CityZXR1cm4gdXVpZF9jbGVhciAo
KTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJ
TkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyPXllcworZWxzZQorICBh
Y19jdl9saWJfdXVpZF91dWlkX2NsZWFyPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xl
YXIiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjY7IH0KK2lm
IHRlc3QgIngkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0
ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX0xJQlVVSUQgMQorX0FDRU9GCisK
KyAgTElCUz0iLWx1dWlkICRMSUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBu
b3QgZmluZCBsaWJ1dWlkIiAiJExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJT
PSRMSUJTCitMSUJTPSItbHlhamwgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFy
IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIHlhamxfYWxs
b2MgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiB5YWpsX2FsbG9jICgpOworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9eWVzCitlbHNlCisgIGFjX2N2X2xpYl95YWps
X3lhamxfYWxsb2M9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0k
YWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYyIgPiY1CiskYXNf
ZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQoraWYgdGVzdCAieCRhY19j
dl9saWJfeWFqbF95YWpsX2FsbG9jIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5o
IDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfTElCWUFKTCAxCitfQUNFT0YKKworICBMSUJTPSItbHlh
amwgJExJQlMiCisKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHlhamwi
ICIkTElORU5PIiA1CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBkZWZsYXRlQ29weSBpbiAtbHoiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIGRlZmxhdGVDb3B5IGluIC1sei4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJf
el9kZWZsYXRlQ29weSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1seiAgJExJ
QlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl
IHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg
dGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu
dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitl
eHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZGVmbGF0ZUNvcHkgKCk7CitpbnQKK21haW4gKCkKK3sK
K3JldHVybiBkZWZsYXRlQ29weSAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYg
YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfel9kZWZsYXRl
Q29weT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHk9bm8KK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX3pfZGVmbGF0ZUNvcHkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfel9kZWZsYXRlQ29w
eSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA9IHh5ZXM7IHRo
ZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfTElCWiAxCitf
QUNFT0YKKworICBMSUJTPSItbHogJExJQlMiCisKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNv
dWxkIG5vdCBmaW5kIHpsaWIiICIkTElORU5PIiA1CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsaWJpY29udl9vcGVuIGluIC1saWNv
bnYiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29u
di4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbis6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNr
X2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1saWNvbnYgICRMSUJTIgorY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv
ci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlm
CitjaGFyIGxpYmljb252X29wZW4gKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBsaWJpY29u
dl9vcGVuICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9s
aW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXll
cworZWxzZQorICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbj1ubworZmkKK3JtIC1mIGNv
cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4
ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9s
aWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9pY29udl9s
aWJpY29udl9vcGVuIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2ljb252X2xpYmljb252
X29wZW4iID0geHllczsgdGhlbiA6CisgIGxpYmljb252PSJ5IgorZWxzZQorICBsaWJpY29udj0i
biIKK2ZpCisKKworCisjIEF1dG9zY2FuIHN0dWZmIChleGNlcHQgZm9yIHlhamwveWFqbF92ZXJz
aW9uLmggY2hlY2spCisjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgorYWNfZm5fY19jaGVja190
eXBlICIkTElORU5PIiAic2l6ZV90IiAiYWNfY3ZfdHlwZV9zaXplX3QiICIkYWNfaW5jbHVkZXNf
ZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9zaXplX3QiID0geHllczsgdGhlbiA6CisK
K2Vsc2UKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBzaXplX3QgdW5zaWdu
ZWQgaW50CitfQUNFT0YKKworZmkKKworIyBUaGUgVWx0cml4IDQuMiBtaXBzIGJ1aWx0aW4gYWxs
b2NhIGRlY2xhcmVkIGJ5IGFsbG9jYS5oIG9ubHkgd29ya3MKKyMgZm9yIGNvbnN0YW50IGFyZ3Vt
ZW50cy4gIFVzZWxlc3MhCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciB3b3JraW5nIGFsbG9jYS5oIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciB3b3JraW5nIGFsbG9jYS5oLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3dvcmtpbmdfYWxs
b2NhX2grOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWxsb2NhLmg+CitpbnQKK21haW4gKCkKK3sKK2No
YXIgKnAgPSAoY2hhciAqKSBhbGxvY2EgKDIgKiBzaXplb2YgKGludCkpOworCQkJICBpZiAocCkg
cmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xp
bmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfd29ya2luZ19hbGxvY2FfaD15ZXMKK2Vsc2UK
KyAgYWNfY3Zfd29ya2luZ19hbGxvY2FfaD1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4k
YWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfd29ya2lu
Z19hbGxvY2FfaCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl93b3JraW5nX2FsbG9jYV9oID0geWVz
OyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBX0ggMSIgPj5jb25mZGVmcy5o
CisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIGFsbG9jYSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgYWxsb2NhLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzKzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lmZGVmIF9f
R05VQ19fCisjIGRlZmluZSBhbGxvY2EgX19idWlsdGluX2FsbG9jYQorI2Vsc2UKKyMgaWZkZWYg
X01TQ19WRVIKKyMgIGluY2x1ZGUgPG1hbGxvYy5oPgorIyAgZGVmaW5lIGFsbG9jYSBfYWxsb2Nh
CisjIGVsc2UKKyMgIGlmZGVmIEhBVkVfQUxMT0NBX0gKKyMgICBpbmNsdWRlIDxhbGxvY2EuaD4K
KyMgIGVsc2UKKyMgICBpZmRlZiBfQUlYCisgI3ByYWdtYSBhbGxvY2EKKyMgICBlbHNlCisjICAg
IGlmbmRlZiBhbGxvY2EgLyogcHJlZGVmaW5lZCBieSBIUCBjYyArT2xpYmNhbGxzICovCit2b2lk
ICphbGxvY2EgKHNpemVfdCk7CisjICAgIGVuZGlmCisjICAgZW5kaWYKKyMgIGVuZGlmCisjIGVu
ZGlmCisjZW5kaWYKKworaW50CittYWluICgpCit7CitjaGFyICpwID0gKGNoYXIgKikgYWxsb2Nh
ICgxKTsKKwkJCQkgICAgaWYgKHApIHJldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FD
RU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNf
YWxsb2NhX3dvcmtzPXllcworZWxzZQorICBhY19jdl9mdW5jX2FsbG9jYV93b3Jrcz1ubworZmkK
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0
ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX2FsbG9jYV93b3JrcyIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzIiA+JjY7IH0KKworaWYgdGVzdCAk
YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUg
SEFWRV9BTExPQ0EgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgIyBUaGUgU1ZSMyBsaWJQVyBh
bmQgU1ZSNCBsaWJ1Y2IgYm90aCBjb250YWluIGluY29tcGF0aWJsZSBmdW5jdGlvbnMKKyMgdGhh
dCBjYXVzZSB0cm91YmxlLiAgU29tZSB2ZXJzaW9ucyBkbyBub3QgZXZlbiBjb250YWluIGFsbG9j
YSBvcgorIyBjb250YWluIGEgYnVnZ3kgdmVyc2lvbi4gIElmIHlvdSBzdGlsbCB3YW50IHRvIHVz
ZSB0aGVpciBhbGxvY2EsCisjIHVzZSBhciB0byBleHRyYWN0IGFsbG9jYS5vIGZyb20gdGhlbSBp
bnN0ZWFkIG9mIGNvbXBpbGluZyBhbGxvY2EuYy4KKworQUxMT0NBPVwke0xJQk9CSkRJUn1hbGxv
Y2EuJGFjX29iamV4dAorCiskYXNfZWNobyAiI2RlZmluZSBDX0FMTE9DQSAxIiA+PmNvbmZkZWZz
LmgKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IHdoZXRoZXIgXGBhbGxvY2EuYycgbmVlZHMgQ3JheSBob29rcyIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyB3aGV0aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENyYXkgaG9va3MuLi4gIiA+JjY7IH0K
K2lmICR7YWNfY3Zfb3NfY3JheSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZiBkZWZpbmVkIENSQVkgJiYgISBkZWZp
bmVkIENSQVkyCit3ZWJlY3JheQorI2Vsc2UKK3dlbm90YmVjcmF5CisjZW5kaWYKKworX0FDRU9G
CitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8CisgICRFR1JFUCAi
d2ViZWNyYXkiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisgIGFjX2N2X29zX2NyYXk9eWVzCitl
bHNlCisgIGFjX2N2X29zX2NyYXk9bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKKworZmkKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfb3NfY3Jh
eSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X29zX2NyYXkiID4mNjsgfQoraWYgdGVzdCAkYWNfY3Zf
b3NfY3JheSA9IHllczsgdGhlbgorICBmb3IgYWNfZnVuYyBpbiBfZ2V0YjY3IEdFVEI2NyBnZXRi
Njc7IGRvCisgICAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAk
YXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19h
Y192YXIiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgQ1JBWV9TVEFDS1NFR19FTkQg
JGFjX2Z1bmMKK19BQ0VPRgorCisgICAgYnJlYWsKK2ZpCisKKyAgZG9uZQorZmkKKworeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBzdGFjayBkaXJlY3Rp
b24gZm9yIEMgYWxsb2NhIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHN0YWNrIGRpcmVjdGlv
biBmb3IgQyBhbGxvY2EuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19zdGFja19kaXJlY3Rpb24r
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBp
ZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Nfc3RhY2tf
ZGlyZWN0aW9uPTAKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKK2lu
dAorZmluZF9zdGFja19kaXJlY3Rpb24gKCkKK3sKKyAgc3RhdGljIGNoYXIgKmFkZHIgPSAwOwor
ICBhdXRvIGNoYXIgZHVtbXk7CisgIGlmIChhZGRyID09IDApCisgICAgeworICAgICAgYWRkciA9
ICZkdW1teTsKKyAgICAgIHJldHVybiBmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKTsKKyAgICB9Cisg
IGVsc2UKKyAgICByZXR1cm4gKCZkdW1teSA+IGFkZHIpID8gMSA6IC0xOworfQorCitpbnQKK21h
aW4gKCkKK3sKKyAgcmV0dXJuIGZpbmRfc3RhY2tfZGlyZWN0aW9uICgpIDwgMDsKK30KK19BQ0VP
RgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Nfc3RhY2tf
ZGlyZWN0aW9uPTEKK2Vsc2UKKyAgYWNfY3ZfY19zdGFja19kaXJlY3Rpb249LTEKK2ZpCitybSAt
ZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFj
X2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4k
YWNfZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbiIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X2Nfc3RhY2tfZGlyZWN0aW9uIiA+JjY7IH0KK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgU1RBQ0tfRElSRUNUSU9OICRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbgorX0FDRU9GCisK
KworZmkKKworZm9yIGFjX2hlYWRlciBpbiAgXAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5o
IGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAg
ICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5o
IHN0cmluZy5oIFwKKyAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9j
dGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tl
dC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAg
ICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorCitkbyA6CisgIGFzX2Fj
X0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAK
K2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFz
X2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRh
c19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEK
K19BQ0VPRgorCitmaQorCitkb25lCisKKworIyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1
cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igc3RkYm9vbC5oIHRoYXQgY29uZm9ybXMg
dG8gQzk5IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdGRib29sLmggdGhhdCBjb25m
b3JtcyB0byBDOTkuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKworI2luY2x1ZGUgPHN0ZGJvb2wuaD4KKyNpZm5kZWYgYm9vbAorICJlcnJvcjogYm9v
bCBpcyBub3QgZGVmaW5lZCIKKyNlbmRpZgorI2lmbmRlZiBmYWxzZQorICJlcnJvcjogZmFsc2Ug
aXMgbm90IGRlZmluZWQiCisjZW5kaWYKKyNpZiBmYWxzZQorICJlcnJvcjogZmFsc2UgaXMgbm90
IDAiCisjZW5kaWYKKyNpZm5kZWYgdHJ1ZQorICJlcnJvcjogdHJ1ZSBpcyBub3QgZGVmaW5lZCIK
KyNlbmRpZgorI2lmIHRydWUgIT0gMQorICJlcnJvcjogdHJ1ZSBpcyBub3QgMSIKKyNlbmRpZgor
I2lmbmRlZiBfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZAorICJlcnJvcjogX19ib29sX3Ry
dWVfZmFsc2VfYXJlX2RlZmluZWQgaXMgbm90IGRlZmluZWQiCisjZW5kaWYKKworCXN0cnVjdCBz
IHsgX0Jvb2wgczogMTsgX0Jvb2wgdDsgfSBzOworCisJY2hhciBhW3RydWUgPT0gMSA/IDEgOiAt
MV07CisJY2hhciBiW2ZhbHNlID09IDAgPyAxIDogLTFdOworCWNoYXIgY1tfX2Jvb2xfdHJ1ZV9m
YWxzZV9hcmVfZGVmaW5lZCA9PSAxID8gMSA6IC0xXTsKKwljaGFyIGRbKGJvb2wpIDAuNSA9PSB0
cnVlID8gMSA6IC0xXTsKKwkvKiBTZWUgYm9keSBvZiBtYWluIHByb2dyYW0gZm9yICdlJy4gICov
CisJY2hhciBmWyhfQm9vbCkgMC4wID09IGZhbHNlID8gMSA6IC0xXTsKKwljaGFyIGdbdHJ1ZV07
CisJY2hhciBoW3NpemVvZiAoX0Jvb2wpXTsKKwljaGFyIGlbc2l6ZW9mIHMudF07CisJZW51bSB7
IGogPSBmYWxzZSwgayA9IHRydWUsIGwgPSBmYWxzZSAqIHRydWUsIG0gPSB0cnVlICogMjU2IH07
CisJLyogVGhlIGZvbGxvd2luZyBmYWlscyBmb3IKKwkgICBIUCBhQysrL0FOU0kgQyBCMzkxMEIg
QS4wNS41NSBbRGVjIDA0IDIwMDNdLiAqLworCV9Cb29sIG5bbV07CisJY2hhciBvW3NpemVvZiBu
ID09IG0gKiBzaXplb2YgblswXSA/IDEgOiAtMV07CisJY2hhciBwWy0xIC0gKF9Cb29sKSAwIDwg
MCAmJiAtMSAtIChib29sKSAwIDwgMCA/IDEgOiAtMV07CisJLyogQ2F0Y2ggYSBidWcgaW4gYW4g
SFAtVVggQyBjb21waWxlci4gIFNlZQorCSAgIGh0dHA6Ly9nY2MuZ251Lm9yZy9tbC9nY2MtcGF0
Y2hlcy8yMDAzLTEyL21zZzAyMzAzLmh0bWwKKwkgICBodHRwOi8vbGlzdHMuZ251Lm9yZy9hcmNo
aXZlL2h0bWwvYnVnLWNvcmV1dGlscy8yMDA1LTExL21zZzAwMTYxLmh0bWwKKwkgKi8KKwlfQm9v
bCBxID0gdHJ1ZTsKKwlfQm9vbCAqcHEgPSAmcTsKKworaW50CittYWluICgpCit7CisKKwlib29s
IGUgPSAmczsKKwkqcHEgfD0gcTsKKwkqcHEgfD0gISBxOworCS8qIFJlZmVyIHRvIGV2ZXJ5IGRl
Y2xhcmVkIHZhbHVlLCB0byBhdm9pZCBjb21waWxlciBvcHRpbWl6YXRpb25zLiAgKi8KKwlyZXR1
cm4gKCFhICsgIWIgKyAhYyArICFkICsgIWUgKyAhZiArICFnICsgIWggKyAhaSArICEhaiArICFr
ICsgISFsCisJCSsgIW0gKyAhbiArICFvICsgIXAgKyAhcSArICFwcSk7CisKKyAgOworICByZXR1
cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9oZWFkZXJfc3RkYm9vbF9oPXllcworZWxzZQorICBhY19jdl9oZWFkZXJfc3Rk
Ym9vbF9oPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjUKKyRhc19lY2hvICIk
YWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCIgPiY2OyB9CithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5F
Tk8iICJfQm9vbCIgImFjX2N2X3R5cGVfX0Jvb2wiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lm
IHRlc3QgIngkYWNfY3ZfdHlwZV9fQm9vbCIgPSB4eWVzOyB0aGVuIDoKKworY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX19CT09MIDEKK19BQ0VPRgorCisKK2ZpCisKK2lm
IHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRib29sX2ggPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNk
ZWZpbmUgSEFWRV9TVERCT09MX0ggMSIgPj5jb25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90
eXBlcy5oIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB1aWRfdCBpbiBzeXMvdHlwZXMu
aC4uLiAiID4mNjsgfQoraWYgJHthY19jdl90eXBlX3VpZF90Kzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUg
PHN5cy90eXBlcy5oPgorCitfQUNFT0YKK2lmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19l
eHQiKSAyPiY1IHwKKyAgJEVHUkVQICJ1aWRfdCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAg
YWNfY3ZfdHlwZV91aWRfdD15ZXMKK2Vsc2UKKyAgYWNfY3ZfdHlwZV91aWRfdD1ubworZmkKK3Jt
IC1mIGNvbmZ0ZXN0KgorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl90eXBlX3VpZF90IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfdHlw
ZV91aWRfdCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl90eXBlX3VpZF90ID0gbm87IHRoZW4KKwor
JGFzX2VjaG8gIiNkZWZpbmUgdWlkX3QgaW50IiA+PmNvbmZkZWZzLmgKKworCiskYXNfZWNobyAi
I2RlZmluZSBnaWRfdCBpbnQiID4+Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBpbmxpbmUiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIGlubGluZS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9jX2lubGlu
ZSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGFjX2N2X2NfaW5saW5lPW5vCitmb3IgYWNfa3cgaW4gaW5saW5lIF9faW5saW5lX18gX19pbmxp
bmU7IGRvCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZm5kZWYgX19jcGx1c3BsdXMKK3R5cGVkZWYgaW50IGZv
b190Oworc3RhdGljICRhY19rdyBmb29fdCBzdGF0aWNfZm9vICgpIHtyZXR1cm4gMDsgfQorJGFj
X2t3IGZvb190IGZvbyAoKSB7cmV0dXJuIDA7IH0KKyNlbmRpZgorCitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfY19pbmxpbmU9JGFjX2t3
CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVz
dC4kYWNfZXh0CisgIHRlc3QgIiRhY19jdl9jX2lubGluZSIgIT0gbm8gJiYgYnJlYWsKK2RvbmUK
KworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfY19pbmxpbmUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX2lubGluZSIgPiY2OyB9CisK
K2Nhc2UgJGFjX2N2X2NfaW5saW5lIGluCisgIGlubGluZSB8IHllcykgOzsKKyAgKikKKyAgICBj
YXNlICRhY19jdl9jX2lubGluZSBpbgorICAgICAgbm8pIGFjX3ZhbD07OworICAgICAgKikgYWNf
dmFsPSRhY19jdl9jX2lubGluZTs7CisgICAgZXNhYworICAgIGNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKKyNpZm5kZWYgX19jcGx1c3BsdXMKKyNkZWZpbmUgaW5saW5lICRhY192YWwKKyNlbmRp
ZgorX0FDRU9GCisgICAgOzsKK2VzYWMKKworYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIg
IjE2IiAiYWNfY3ZfY19pbnQxNl90IgorY2FzZSAkYWNfY3ZfY19pbnQxNl90IGluICMoCisgIG5v
fHllcykgOzsgIygKKyAgKikKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBp
bnQxNl90ICRhY19jdl9jX2ludDE2X3QKK19BQ0VPRgorOzsKK2VzYWMKKworYWNfZm5fY19maW5k
X2ludFhfdCAiJExJTkVOTyIgIjMyIiAiYWNfY3ZfY19pbnQzMl90IgorY2FzZSAkYWNfY3ZfY19p
bnQzMl90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikKKworY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgorI2RlZmluZSBpbnQzMl90ICRhY19jdl9jX2ludDMyX3QKK19BQ0VPRgorOzsKK2Vz
YWMKKworYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIgIjY0IiAiYWNfY3ZfY19pbnQ2NF90
IgorY2FzZSAkYWNfY3ZfY19pbnQ2NF90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBpbnQ2NF90ICRhY19jdl9jX2ludDY0
X3QKK19BQ0VPRgorOzsKK2VzYWMKKworYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIgIjgi
ICJhY19jdl9jX2ludDhfdCIKK2Nhc2UgJGFjX2N2X2NfaW50OF90IGluICMoCisgIG5vfHllcykg
OzsgIygKKyAgKikKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBpbnQ4X3Qg
JGFjX2N2X2NfaW50OF90CitfQUNFT0YKKzs7Citlc2FjCisKK2FjX2ZuX2NfY2hlY2tfdHlwZSAi
JExJTkVOTyIgIm1vZGVfdCIgImFjX2N2X3R5cGVfbW9kZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfbW9kZV90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNl
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgbW9kZV90IGludAorX0FDRU9G
CisKK2ZpCisKK2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgIm9mZl90IiAiYWNfY3ZfdHlw
ZV9vZmZfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX29m
Zl90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNlCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
KyNkZWZpbmUgb2ZmX3QgbG9uZyBpbnQKK19BQ0VPRgorCitmaQorCithY19mbl9jX2NoZWNrX3R5
cGUgIiRMSU5FTk8iICJwaWRfdCIgImFjX2N2X3R5cGVfcGlkX3QiICIkYWNfaW5jbHVkZXNfZGVm
YXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9waWRfdCIgPSB4eWVzOyB0aGVuIDoKKworZWxz
ZQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIHBpZF90IGludAorX0FDRU9G
CisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19yZXN0
cmljdCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGFjX2N2X2NfcmVzdHJpY3Q9bm8KKyAgICMgVGhlIG9yZGVyIGhlcmUgY2F0ZXJzIHRvIHRo
ZSBmYWN0IHRoYXQgQysrIGRvZXMgbm90IHJlcXVpcmUgcmVzdHJpY3QuCisgICBmb3IgYWNfa3cg
aW4gX19yZXN0cmljdCBfX3Jlc3RyaWN0X18gX1Jlc3RyaWN0IHJlc3RyaWN0OyBkbworICAgICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCit0eXBlZGVmIGludCAqIGludF9wdHI7CisJaW50IGZvbyAoaW50X3B0ciAkYWNf
a3cgaXApIHsKKwlyZXR1cm4gaXBbMF07CisgICAgICAgfQoraW50CittYWluICgpCit7CitpbnQg
c1sxXTsKKwlpbnQgKiAkYWNfa3cgdCA9IHM7CisJdFswXSA9IDA7CisJcmV0dXJuIGZvbyh0KQor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2NfcmVzdHJpY3Q9JGFjX2t3CitmaQorcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICAgIHRl
c3QgIiRhY19jdl9jX3Jlc3RyaWN0IiAhPSBubyAmJiBicmVhaworICAgZG9uZQorCitmaQoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX3Jl
c3RyaWN0IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19yZXN0cmljdCIgPiY2OyB9CisKKyBjYXNl
ICRhY19jdl9jX3Jlc3RyaWN0IGluCisgICByZXN0cmljdCkgOzsKKyAgIG5vKSAkYXNfZWNobyAi
I2RlZmluZSByZXN0cmljdCAvKiovIiA+PmNvbmZkZWZzLmgKKyA7OworICAgKikgIGNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgcmVzdHJpY3QgJGFjX2N2X2NfcmVzdHJpY3QKK19B
Q0VPRgorIDs7CisgZXNhYworCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJzaXplX3Qi
ICJhY19jdl90eXBlX3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRh
Y19jdl90eXBlX3NpemVfdCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorCitjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCisjZGVmaW5lIHNpemVfdCB1bnNpZ25lZCBpbnQKK19BQ0VPRgorCitmaQor
CithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJzc2l6ZV90IiAiYWNfY3ZfdHlwZV9zc2l6
ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfc3NpemVf
dCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIHNzaXplX3QgaW50CitfQUNFT0YKKworZmkKKworYWNfZm5fY19jaGVja19tZW1iZXIg
IiRMSU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0X2Jsa3NpemUiICJhY19jdl9tZW1iZXJfc3RydWN0
X3N0YXRfc3RfYmxrc2l6ZSIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j
dl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxrc2l6ZSIgPSB4eWVzOyB0aGVuIDoKKworY2F0ID4+
Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1NUUlVDVF9TVEFUX1NUX0JMS1NJWkUg
MQorX0FDRU9GCisKKworZmkKKworYWNfZm5fY19jaGVja19tZW1iZXIgIiRMSU5FTk8iICJzdHJ1
Y3Qgc3RhdCIgInN0X2Jsb2NrcyIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibG9ja3Mi
ICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVjdF9z
dGF0X3N0X2Jsb2NrcyIgPSB4eWVzOyB0aGVuIDoKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VP
RgorI2RlZmluZSBIQVZFX1NUUlVDVF9TVEFUX1NUX0JMT0NLUyAxCitfQUNFT0YKKworCiskYXNf
ZWNobyAiI2RlZmluZSBIQVZFX1NUX0JMT0NLUyAxIiA+PmNvbmZkZWZzLmgKKworZWxzZQorICBj
YXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBmaWxlYmxvY2tzLiRhY19vYmpleHQgIiogKSA7Owor
ICAqKSBMSUJPQkpTPSIkTElCT0JKUyBmaWxlYmxvY2tzLiRhY19vYmpleHQiCisgOzsKK2VzYWMK
KworZmkKKworCithY19mbl9jX2NoZWNrX21lbWJlciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAi
c3RfcmRldiIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9yZGV2IiAiJGFjX2luY2x1ZGVz
X2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9yZGV2IiA9
IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVf
U1RSVUNUX1NUQVRfU1RfUkRFViAxCitfQUNFT0YKKworCitmaQorCithY19mbl9jX2ZpbmRfdWlu
dFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3ZfY191aW50MTZfdCIKK2Nhc2UgJGFjX2N2X2NfdWlu
dDE2X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCisKK2NhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKKyNkZWZpbmUgdWludDE2X3QgJGFjX2N2X2NfdWludDE2X3QKK19BQ0VPRgorOzsK
KyAgZXNhYworCithY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjMyIiAiYWNfY3ZfY191
aW50MzJfdCIKK2Nhc2UgJGFjX2N2X2NfdWludDMyX3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAor
ICAqKQorCiskYXNfZWNobyAiI2RlZmluZSBfVUlOVDMyX1QgMSIgPj5jb25mZGVmcy5oCisKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSB1aW50MzJfdCAkYWNfY3ZfY191aW50
MzJfdAorX0FDRU9GCis7OworICBlc2FjCisKK2FjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5P
IiAiNjQiICJhY19jdl9jX3VpbnQ2NF90IgorY2FzZSAkYWNfY3ZfY191aW50NjRfdCBpbiAjKAor
ICBub3x5ZXMpIDs7ICMoCisgICopCisKKyRhc19lY2hvICIjZGVmaW5lIF9VSU5UNjRfVCAxIiA+
PmNvbmZkZWZzLmgKKworCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIHVpbnQ2
NF90ICRhY19jdl9jX3VpbnQ2NF90CitfQUNFT0YKKzs7CisgIGVzYWMKKworYWNfZm5fY19maW5k
X3VpbnRYX3QgIiRMSU5FTk8iICI4IiAiYWNfY3ZfY191aW50OF90IgorY2FzZSAkYWNfY3ZfY191
aW50OF90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikKKworJGFzX2VjaG8gIiNkZWZpbmUg
X1VJTlQ4X1QgMSIgPj5jb25mZGVmcy5oCisKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSB1aW50OF90ICRhY19jdl9jX3VpbnQ4X3QKK19BQ0VPRgorOzsKKyAgZXNhYworCith
Y19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJwdHJkaWZmX3QiICJhY19jdl90eXBlX3B0cmRp
ZmZfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX3B0cmRp
ZmZfdCIgPSB4eWVzOyB0aGVuIDoKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBIQVZFX1BUUkRJRkZfVCAxCitfQUNFT0YKKworCitmaQorCisKKyMgQ2hlY2tzIGZvciBsaWJy
YXJ5IGZ1bmN0aW9ucy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIGVycm9yX2F0X2xpbmUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IGVycm9yX2F0X2xpbmUuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCisjaW5jbHVkZSA8ZXJyb3IuaD4KK2ludAorbWFpbiAoKQoreworZXJyb3JfYXRf
bGluZSAoMCwgMCwgIiIsIDAsICJhbiBlcnJvciBvY2N1cnJlZCIpOworICA7CisgIHJldHVybiAw
OworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFj
X2N2X2xpYl9lcnJvcl9hdF9saW5lPXllcworZWxzZQorICBhY19jdl9saWJfZXJyb3JfYXRfbGlu
ZT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAor
ICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXJyb3JfYXRf
bGluZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lIiA+JjY7IH0KK2lm
IHRlc3QgJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lID0gbm87IHRoZW4KKyAgY2FzZSAiICRMSUJP
QkpTICIgaW4KKyAgKiIgZXJyb3IuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRM
SUJPQkpTIGVycm9yLiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworZmkKKworZm9yIGFjX2hlYWRl
ciBpbiB2Zm9yay5oCitkbyA6CisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5F
Tk8iICJ2Zm9yay5oIiAiYWNfY3ZfaGVhZGVyX3Zmb3JrX2giICIkYWNfaW5jbHVkZXNfZGVmYXVs
dCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3Zmb3JrX2giID0geHllczsgdGhlbiA6CisgIGNh
dCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9WRk9SS19IIDEKK19BQ0VPRgor
CitmaQorCitkb25lCisKK2ZvciBhY19mdW5jIGluIGZvcmsgdmZvcmsKK2RvIDoKKyAgYXNfYWNf
dmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCithY19mbl9j
X2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitpZiBldmFsIHRl
c3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9j
cHBgIDEKK19BQ0VPRgorCitmaQorZG9uZQorCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9yayIg
PSB4eWVzOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIHdvcmtpbmcgZm9yayIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
d29ya2luZyBmb3JrLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfZm9ya193b3Jrcys6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19mb3JrX3dv
cmtzPWNyb3NzCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQK
K21haW4gKCkKK3sKKworCSAgLyogQnkgUnVlZGlnZXIgS3VobG1hbm4uICovCisJICByZXR1cm4g
Zm9yayAoKSA8IDA7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz15ZXMKK2Vs
c2UKKyAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUgY29y
ZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBjb25m
dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
ZnVuY19mb3JrX3dvcmtzIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA+
JjY7IH0KKworZWxzZQorICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9JGFjX2N2X2Z1bmNfZm9yawor
ZmkKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsgdGhlbgorICBj
YXNlICRob3N0IGluCisgICAgKi0qLWFtaWdhb3MqIHwgKi0qLW1zZG9zZGpncHAqKQorICAgICAg
IyBPdmVycmlkZSwgYXMgdGhlc2Ugc3lzdGVtcyBoYXZlIG9ubHkgYSBkdW1teSBmb3JrKCkgc3R1
YgorICAgICAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5vCisgICAgICA7OworICAgICopCisgICAg
ICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCisgICAgICA7OworICBlc2FjCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVzdWx0ICRhY19jdl9m
dW5jX2Zvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUK
KyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19mb3JrX3dvcmtz
IGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiYyO30KK2ZpCithY19jdl9m
dW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3JrCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNf
dmZvcmsiID0geHllczsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHZmb3JrIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciB3b3JraW5nIHZmb3JrLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfdmZvcmtf
d29ya3MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3M9Y3Jvc3MKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworLyogVGhhbmtzIHRvIFBh
dWwgRWdnZXJ0IGZvciB0aGlzIHRlc3QuICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKKyNpbmNs
dWRlIDxzeXMvd2FpdC5oPgorI2lmZGVmIEhBVkVfVkZPUktfSAorIyBpbmNsdWRlIDx2Zm9yay5o
PgorI2VuZGlmCisvKiBPbiBzb21lIHNwYXJjIHN5c3RlbXMsIGNoYW5nZXMgYnkgdGhlIGNoaWxk
IHRvIGxvY2FsIGFuZCBpbmNvbWluZworICAgYXJndW1lbnQgcmVnaXN0ZXJzIGFyZSBwcm9wYWdh
dGVkIGJhY2sgdG8gdGhlIHBhcmVudC4gIFRoZSBjb21waWxlcgorICAgaXMgdG9sZCBhYm91dCB0
aGlzIHdpdGggI2luY2x1ZGUgPHZmb3JrLmg+LCBidXQgc29tZSBjb21waWxlcnMKKyAgIChlLmcu
IGdjYyAtTykgZG9uJ3QgZ3JvayA8dmZvcmsuaD4uICBUZXN0IGZvciB0aGlzIGJ5IHVzaW5nIGEK
KyAgIHN0YXRpYyB2YXJpYWJsZSB3aG9zZSBhZGRyZXNzIGlzIHB1dCBpbnRvIGEgcmVnaXN0ZXIg
dGhhdCBpcworICAgY2xvYmJlcmVkIGJ5IHRoZSB2Zm9yay4gICovCitzdGF0aWMgdm9pZAorI2lm
ZGVmIF9fY3BsdXNwbHVzCitzcGFyY19hZGRyZXNzX3Rlc3QgKGludCBhcmcpCisjIGVsc2UKK3Nw
YXJjX2FkZHJlc3NfdGVzdCAoYXJnKSBpbnQgYXJnOworI2VuZGlmCit7CisgIHN0YXRpYyBwaWRf
dCBjaGlsZDsKKyAgaWYgKCFjaGlsZCkgeworICAgIGNoaWxkID0gdmZvcmsgKCk7CisgICAgaWYg
KGNoaWxkIDwgMCkgeworICAgICAgcGVycm9yICgidmZvcmsiKTsKKyAgICAgIF9leGl0KDIpOwor
ICAgIH0KKyAgICBpZiAoIWNoaWxkKSB7CisgICAgICBhcmcgPSBnZXRwaWQoKTsKKyAgICAgIHdy
aXRlKC0xLCAiIiwgMCk7CisgICAgICBfZXhpdCAoYXJnKTsKKyAgICB9CisgIH0KK30KKworaW50
CittYWluICgpCit7CisgIHBpZF90IHBhcmVudCA9IGdldHBpZCAoKTsKKyAgcGlkX3QgY2hpbGQ7
CisKKyAgc3BhcmNfYWRkcmVzc190ZXN0ICgwKTsKKworICBjaGlsZCA9IHZmb3JrICgpOworCisg
IGlmIChjaGlsZCA9PSAwKSB7CisgICAgLyogSGVyZSBpcyBhbm90aGVyIHRlc3QgZm9yIHNwYXJj
IHZmb3JrIHJlZ2lzdGVyIHByb2JsZW1zLiAgVGhpcworICAgICAgIHRlc3QgdXNlcyBsb3RzIG9m
IGxvY2FsIHZhcmlhYmxlcywgYXQgbGVhc3QgYXMgbWFueSBsb2NhbAorICAgICAgIHZhcmlhYmxl
cyBhcyBtYWluIGhhcyBhbGxvY2F0ZWQgc28gZmFyIGluY2x1ZGluZyBjb21waWxlcgorICAgICAg
IHRlbXBvcmFyaWVzLiAgNCBsb2NhbHMgYXJlIGVub3VnaCBmb3IgZ2NjIDEuNDAuMyBvbiBhIFNv
bGFyaXMKKyAgICAgICA0LjEuMyBzcGFyYywgYnV0IHdlIHVzZSA4IHRvIGJlIHNhZmUuICBBIGJ1
Z2d5IGNvbXBpbGVyIHNob3VsZAorICAgICAgIHJldXNlIHRoZSByZWdpc3RlciBvZiBwYXJlbnQg
Zm9yIG9uZSBvZiB0aGUgbG9jYWwgdmFyaWFibGVzLAorICAgICAgIHNpbmNlIGl0IHdpbGwgdGhp
bmsgdGhhdCBwYXJlbnQgY2FuJ3QgcG9zc2libHkgYmUgdXNlZCBhbnkgbW9yZQorICAgICAgIGlu
IHRoaXMgcm91dGluZS4gIEFzc2lnbmluZyB0byB0aGUgbG9jYWwgdmFyaWFibGUgd2lsbCB0aHVz
CisgICAgICAgbXVuZ2UgcGFyZW50IGluIHRoZSBwYXJlbnQgcHJvY2Vzcy4gICovCisgICAgcGlk
X3QKKyAgICAgIHAgPSBnZXRwaWQoKSwgcDEgPSBnZXRwaWQoKSwgcDIgPSBnZXRwaWQoKSwgcDMg
PSBnZXRwaWQoKSwKKyAgICAgIHA0ID0gZ2V0cGlkKCksIHA1ID0gZ2V0cGlkKCksIHA2ID0gZ2V0
cGlkKCksIHA3ID0gZ2V0cGlkKCk7CisgICAgLyogQ29udmluY2UgdGhlIGNvbXBpbGVyIHRoYXQg
cC4ucDcgYXJlIGxpdmU7IG90aGVyd2lzZSwgaXQgbWlnaHQKKyAgICAgICB1c2UgdGhlIHNhbWUg
aGFyZHdhcmUgcmVnaXN0ZXIgZm9yIGFsbCA4IGxvY2FsIHZhcmlhYmxlcy4gICovCisgICAgaWYg
KHAgIT0gcDEgfHwgcCAhPSBwMiB8fCBwICE9IHAzIHx8IHAgIT0gcDQKKwl8fCBwICE9IHA1IHx8
IHAgIT0gcDYgfHwgcCAhPSBwNykKKyAgICAgIF9leGl0KDEpOworCisgICAgLyogT24gc29tZSBz
eXN0ZW1zIChlLmcuIElSSVggMy4zKSwgdmZvcmsgZG9lc24ndCBzZXBhcmF0ZSBwYXJlbnQKKyAg
ICAgICBmcm9tIGNoaWxkIGZpbGUgZGVzY3JpcHRvcnMuICBJZiB0aGUgY2hpbGQgY2xvc2VzIGEg
ZGVzY3JpcHRvcgorICAgICAgIGJlZm9yZSBpdCBleGVjcyBvciBleGl0cywgdGhpcyBtdW5nZXMg
dGhlIHBhcmVudCdzIGRlc2NyaXB0b3IKKyAgICAgICBhcyB3ZWxsLiAgVGVzdCBmb3IgdGhpcyBi
eSBjbG9zaW5nIHN0ZG91dCBpbiB0aGUgY2hpbGQuICAqLworICAgIF9leGl0KGNsb3NlKGZpbGVu
byhzdGRvdXQpKSAhPSAwKTsKKyAgfSBlbHNlIHsKKyAgICBpbnQgc3RhdHVzOworICAgIHN0cnVj
dCBzdGF0IHN0OworCisgICAgd2hpbGUgKHdhaXQoJnN0YXR1cykgIT0gY2hpbGQpCisgICAgICA7
CisgICAgcmV0dXJuICgKKwkgLyogV2FzIHRoZXJlIHNvbWUgcHJvYmxlbSB3aXRoIHZmb3JraW5n
PyAgKi8KKwkgY2hpbGQgPCAwCisKKwkgLyogRGlkIHRoZSBjaGlsZCBmYWlsPyAgKFRoaXMgc2hv
dWxkbid0IGhhcHBlbi4pICAqLworCSB8fCBzdGF0dXMKKworCSAvKiBEaWQgdGhlIHZmb3JrL2Nv
bXBpbGVyIGJ1ZyBvY2N1cj8gICovCisJIHx8IHBhcmVudCAhPSBnZXRwaWQoKQorCisJIC8qIERp
ZCB0aGUgZmlsZSBkZXNjcmlwdG9yIGJ1ZyBvY2N1cj8gICovCisJIHx8IGZzdGF0KGZpbGVubyhz
dGRvdXQpLCAmc3QpICE9IDAKKwkgKTsKKyAgfQorfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9y
dW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY192Zm9ya193b3Jrcz15ZXMKK2Vsc2UK
KyAgYWNfY3ZfZnVuY192Zm9ya193b3Jrcz1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUu
Y29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3MiID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA+
JjY7IH0KKworZmk7CitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7
IHRoZW4KKyAgYWNfY3ZfZnVuY192Zm9ya193b3Jrcz0kYWNfY3ZfZnVuY192Zm9yaworICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNf
Y3ZfZnVuY192Zm9ya193b3JrcyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24i
ID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX3Zmb3Jr
X3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiYyO30KK2ZpCisK
K2lmIHRlc3QgIngkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCisKKyRhc19l
Y2hvICIjZGVmaW5lIEhBVkVfV09SS0lOR19WRk9SSyAxIiA+PmNvbmZkZWZzLmgKKworZWxzZQor
CiskYXNfZWNobyAiI2RlZmluZSB2Zm9yayBmb3JrIiA+PmNvbmZkZWZzLmgKKworZmkKK2lmIHRl
c3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHh5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNk
ZWZpbmUgSEFWRV9XT1JLSU5HX0ZPUksgMSIgPj5jb25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIF9MQVJHRUZJTEVf
U09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UrOn0gZmFsc2U7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICB3aGlsZSA6OyBkbwor
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29u
ZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+IC8qIGZvciBvZmZfdCAqLworICAg
ICAjaW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFpbiAoKQoreworaW50ICgqZnApIChGSUxFICos
IG9mZl90LCBpbnQpID0gZnNlZWtvOworICAgICByZXR1cm4gZnNlZWtvIChzdGRpbiwgMCwgMCkg
JiYgZnAgKHN0ZGluLCAwLCAwKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNf
Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9zeXNfbGFyZ2VmaWxlX3Nv
dXJjZT1ubzsgYnJlYWsKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorICBjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMu
aC4gICovCisjZGVmaW5lIF9MQVJHRUZJTEVfU09VUkNFIDEKKyNpbmNsdWRlIDxzeXMvdHlwZXMu
aD4gLyogZm9yIG9mZl90ICovCisgICAgICNpbmNsdWRlIDxzdGRpby5oPgoraW50CittYWluICgp
Cit7CitpbnQgKCpmcCkgKEZJTEUgKiwgb2ZmX3QsIGludCkgPSBmc2Vla287CisgICAgIHJldHVy
biBmc2Vla28gKHN0ZGluLCAwLCAwKSAmJiBmcCAoc3RkaW4sIDAsIDApOworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cisg
IGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPTE7IGJyZWFrCitmaQorcm0gLWYgY29yZSBjb25m
dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNv
bmZ0ZXN0LiRhY19leHQKKyAgYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9dW5rbm93bgorICBi
cmVhaworZG9uZQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY2OyB9CitjYXNlICRhY19jdl9zeXNfbGFyZ2VmaWxl
X3NvdXJjZSBpbiAjKAorICBubyB8IHVua25vd24pIDs7CisgICopCitjYXQgPj5jb25mZGVmcy5o
IDw8X0FDRU9GCisjZGVmaW5lIF9MQVJHRUZJTEVfU09VUkNFICRhY19jdl9zeXNfbGFyZ2VmaWxl
X3NvdXJjZQorX0FDRU9GCis7OworZXNhYworcm0gLXJmIGNvbmZ0ZXN0KgorCisjIFdlIHVzZWQg
dG8gdHJ5IGRlZmluaW5nIF9YT1BFTl9TT1VSQ0U9NTAwIHRvbywgdG8gd29yayBhcm91bmQgYSBi
dWcKKyMgaW4gZ2xpYmMgMi4xLjMsIGJ1dCB0aGF0IGJyZWFrcyB0b28gbWFueSBvdGhlciB0aGlu
Z3MuCisjIElmIHlvdSB3YW50IGZzZWVrbyBhbmQgZnRlbGxvIHdpdGggZ2xpYmMsIHVwZ3JhZGUg
dG8gYSBmaXhlZCBnbGliYy4KK2lmIHRlc3QgJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlICE9
IHVua25vd247IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9GU0VFS08gMSIgPj5jb25m
ZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0bHkgaGFuZGxlcyB0cmFpbGluZyBzbGFzaCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxzdGF0IGNvcnJlY3RseSBoYW5kbGVz
IHRyYWlsaW5nIHNsYXNoLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfbHN0YXRfZGVyZWZl
cmVuY2VzX3NsYXNoZWRfc3ltbGluays6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIHJtIC1mIGNvbmZ0ZXN0LnN5bSBjb25mdGVzdC5maWxlCitl
Y2hvID5jb25mdGVzdC5maWxlCitpZiB0ZXN0ICIkYXNfbG5fcyIgPSAibG4gLXMiICYmIGxuIC1z
IGNvbmZ0ZXN0LmZpbGUgY29uZnRlc3Quc3ltOyB0aGVuCisgIGlmIHRlc3QgIiRjcm9zc19jb21w
aWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xh
c2hlZF9zeW1saW5rPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0
CitpbnQKK21haW4gKCkKK3sKK3N0cnVjdCBzdGF0IHNidWY7CisgICAgIC8qIExpbnV4IHdpbGwg
ZGVyZWZlcmVuY2UgdGhlIHN5bWxpbmsgYW5kIGZhaWwsIGFzIHJlcXVpcmVkIGJ5IFBPU0lYLgor
CVRoYXQgaXMgYmV0dGVyIGluIHRoZSBzZW5zZSB0aGF0IGl0IG1lYW5zIHdlIHdpbGwgbm90CisJ
aGF2ZSB0byBjb21waWxlIGFuZCB1c2UgdGhlIGxzdGF0IHdyYXBwZXIuICAqLworICAgICByZXR1
cm4gbHN0YXQgKCJjb25mdGVzdC5zeW0vIiwgJnNidWYpID09IDA7CisgIDsKKyAgcmV0dXJuIDA7
Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9eWVzCitlbHNlCisgIGFj
X2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubworZmkKK3JtIC1m
IGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNf
ZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCisKK2Vsc2UKKyAgIyBJZiB0aGUgYGxuIC1zJyBjb21tYW5kIGZhaWxlZCwgdGhl
biB3ZSBwcm9iYWJseSBkb24ndCBldmVuCisgICMgaGF2ZSBhbiBsc3RhdCBmdW5jdGlvbi4KKyAg
YWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCitmaQorcm0g
LWYgY29uZnRlc3Quc3ltIGNvbmZ0ZXN0LmZpbGUKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5j
ZXNfc2xhc2hlZF9zeW1saW5rIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY19sc3RhdF9kZXJl
ZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rIiA+JjY7IH0KKwordGVzdCAkYWNfY3ZfZnVuY19sc3Rh
dF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rID0geWVzICYmCisKK2NhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKKyNkZWZpbmUgTFNUQVRfRk9MTE9XU19TTEFTSEVEX1NZTUxJTksgMQorX0FD
RU9GCisKKworaWYgdGVzdCAieCRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVk
X3N5bWxpbmsiID0geG5vOyB0aGVuCisgIGNhc2UgIiAkTElCT0JKUyAiIGluCisgICoiIGxzdGF0
LiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyBsc3RhdC4kYWNfb2Jq
ZXh0IgorIDs7Citlc2FjCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgd2hldGhlciBzeXMvdHlwZXMuaCBkZWZpbmVzIG1ha2VkZXYiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBzeXMvdHlwZXMuaCBkZWZpbmVzIG1ha2Vk
ZXYuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMu
aC4gICovCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBt
YWtlZGV2KDAsIDApOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtl
ZGV2PXllcworZWxzZQorICBhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldj1ubworZmkK
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0
ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9t
YWtlZGV2IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYi
ID4mNjsgfQorCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiA9IG5v
OyB0aGVuCithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3lzL21rZGV2
LmgiICJhY19jdl9oZWFkZXJfc3lzX21rZGV2X2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lm
IHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N5c19ta2Rldl9oIiA9IHh5ZXM7IHRoZW4gOgorCiskYXNf
ZWNobyAiI2RlZmluZSBNQUpPUl9JTl9NS0RFViAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworCisK
KyAgaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N5c19ta2Rldl9oID0gbm87IHRoZW4KKyAgICBhY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3lzL3N5c21hY3Jvcy5oIiAiYWNf
Y3ZfaGVhZGVyX3N5c19zeXNtYWNyb3NfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVz
dCAieCRhY19jdl9oZWFkZXJfc3lzX3N5c21hY3Jvc19oIiA9IHh5ZXM7IHRoZW4gOgorCiskYXNf
ZWNobyAiI2RlZmluZSBNQUpPUl9JTl9TWVNNQUNST1MgMSIgPj5jb25mZGVmcy5oCisKK2ZpCisK
KworICBmaQorZmkKKworZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAorZG8gOgorICBhY19mbl9j
X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJf
c3RkbGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVy
X3N0ZGxpYl9oIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIEhBVkVfU1RETElCX0ggMQorX0FDRU9GCisKK2ZpCisKK2RvbmUKKworeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgR05VIGxpYmMgY29t
cGF0aWJsZSBtYWxsb2MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNv
bXBhdGlibGUgbWFsbG9jLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfbWFsbG9jXzBfbm9u
bnVsbCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVu
Y19tYWxsb2NfMF9ub25udWxsPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZiBkZWZpbmVkIFNU
RENfSEVBREVSUyB8fCBkZWZpbmVkIEhBVkVfU1RETElCX0gKKyMgaW5jbHVkZSA8c3RkbGliLmg+
CisjZWxzZQorY2hhciAqbWFsbG9jICgpOworI2VuZGlmCisKK2ludAorbWFpbiAoKQoreworcmV0
dXJuICEgbWFsbG9jICgwKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVs
bD15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsPW5vCitmaQorcm0gLWYg
Y29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19l
eGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFj
X2V4dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfZnVuY19tYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfbWFs
bG9jXzBfbm9ubnVsbCA9IHllczsgdGhlbiA6CisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfTUFM
TE9DIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisgICRhc19lY2hvICIjZGVmaW5lIEhBVkVfTUFM
TE9DIDAiID4+Y29uZmRlZnMuaAorCisgICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBtYWxs
b2MuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIG1hbGxvYy4kYWNf
b2JqZXh0IgorIDs7Citlc2FjCisKKworJGFzX2VjaG8gIiNkZWZpbmUgbWFsbG9jIHJwbF9tYWxs
b2MiID4+Y29uZmRlZnMuaAorCitmaQorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB0aW1lLmggYW5kIHN5cy90aW1lLmggbWF5IGJv
dGggYmUgaW5jbHVkZWQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB0aW1lLmgg
YW5kIHN5cy90aW1lLmggbWF5IGJvdGggYmUgaW5jbHVkZWQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfaGVhZGVyX3RpbWUrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVk
ZSA8c3lzL3RpbWUuaD4KKyNpbmNsdWRlIDx0aW1lLmg+CisKK2ludAorbWFpbiAoKQoreworaWYg
KChzdHJ1Y3QgdG0gKikgMCkKK3JldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9G
CitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2hlYWRl
cl90aW1lPXllcworZWxzZQorICBhY19jdl9oZWFkZXJfdGltZT1ubworZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVh
ZGVyX3RpbWUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfdGltZSIgPiY2OyB9CitpZiB0
ZXN0ICRhY19jdl9oZWFkZXJfdGltZSA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBU
SU1FX1dJVEhfU1lTX1RJTUUgMSIgPj5jb25mZGVmcy5oCisKK2ZpCisKKworCisKKyAgZm9yIGFj
X2hlYWRlciBpbiAkYWNfaGVhZGVyX2xpc3QKK2RvIDoKKyAgYXNfYWNfSGVhZGVyPWAkYXNfZWNo
byAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19o
ZWFkZXJfY29tcGlsZSAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQKKyIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVhZGVyIlwi
ID0geCJ5ZXMiOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBg
JGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkK
KworZG9uZQorCisKKworCisKKworCisKKyAgZm9yIGFjX2Z1bmMgaW4gJGFjX2Z1bmNfbGlzdAor
ZG8gOgorICBhc19hY192YXI9YCRhc19lY2hvICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190
cl9zaGAKK2FjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3Zh
ciIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKKyAg
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2Z1
bmMiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCisKK2ZpCitkb25lCisKKworCisKKworeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBt
a3RpbWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWt0aW1lLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUrOn0gZmFsc2U7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWU9bm8KK2Vs
c2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworLyogVGVzdCBwcm9ncmFtIGZyb20gUGF1bCBFZ2dlcnQgYW5kIFRv
bnkgTGVuZWlzLiAgKi8KKyNpZmRlZiBUSU1FX1dJVEhfU1lTX1RJTUUKKyMgaW5jbHVkZSA8c3lz
L3RpbWUuaD4KKyMgaW5jbHVkZSA8dGltZS5oPgorI2Vsc2UKKyMgaWZkZWYgSEFWRV9TWVNfVElN
RV9ICisjICBpbmNsdWRlIDxzeXMvdGltZS5oPgorIyBlbHNlCisjICBpbmNsdWRlIDx0aW1lLmg+
CisjIGVuZGlmCisjZW5kaWYKKworI2luY2x1ZGUgPGxpbWl0cy5oPgorI2luY2x1ZGUgPHN0ZGxp
Yi5oPgorCisjaWZkZWYgSEFWRV9VTklTVERfSAorIyBpbmNsdWRlIDx1bmlzdGQuaD4KKyNlbmRp
ZgorCisjaWZuZGVmIEhBVkVfQUxBUk0KKyMgZGVmaW5lIGFsYXJtKFgpIC8qIGVtcHR5ICovCisj
ZW5kaWYKKworLyogV29yayBhcm91bmQgcmVkZWZpbml0aW9uIHRvIHJwbF9wdXRlbnYgYnkgb3Ro
ZXIgY29uZmlnIHRlc3RzLiAgKi8KKyN1bmRlZiBwdXRlbnYKKworc3RhdGljIHRpbWVfdCB0aW1l
X3RfbWF4Oworc3RhdGljIHRpbWVfdCB0aW1lX3RfbWluOworCisvKiBWYWx1ZXMgd2UnbGwgdXNl
IHRvIHNldCB0aGUgVFogZW52aXJvbm1lbnQgdmFyaWFibGUuICAqLworc3RhdGljIGNvbnN0IGNo
YXIgKnR6X3N0cmluZ3NbXSA9IHsKKyAgKGNvbnN0IGNoYXIgKikgMCwgIlRaPUdNVDAiLCAiVFo9
SlNULTkiLAorICAiVFo9RVNUKzNFRFQrMixNMTAuMS4wLzAwOjAwOjAwLE0yLjMuMC8wMDowMDow
MCIKK307CisjZGVmaW5lIE5fU1RSSU5HUyAoc2l6ZW9mICh0el9zdHJpbmdzKSAvIHNpemVvZiAo
dHpfc3RyaW5nc1swXSkpCisKKy8qIFJldHVybiAwIGlmIG1rdGltZSBmYWlscyB0byBjb252ZXJ0
IGEgZGF0ZSBpbiB0aGUgc3ByaW5nLWZvcndhcmQgZ2FwLgorICAgQmFzZWQgb24gYSBwcm9ibGVt
IHJlcG9ydCBmcm9tIEFuZHJlYXMgSmFlZ2VyLiAgKi8KK3N0YXRpYyBpbnQKK3NwcmluZ19mb3J3
YXJkX2dhcCAoKQoreworICAvKiBnbGliYyAodXAgdG8gYWJvdXQgMTk5OC0xMC0wNykgZmFpbGVk
IHRoaXMgdGVzdC4gKi8KKyAgc3RydWN0IHRtIHRtOworCisgIC8qIFVzZSB0aGUgcG9ydGFibGUg
UE9TSVguMSBzcGVjaWZpY2F0aW9uICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIgorICAgICBp
bnN0ZWFkIG9mICJUWj1BbWVyaWNhL1ZhbmNvdXZlciIgaW4gb3JkZXIgdG8gZGV0ZWN0IHRoZSBi
dWcgZXZlbgorICAgICBvbiBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgT2xzb24gZXh0
ZW5zaW9uLCBvciBkb24ndCBoYXZlIHRoZQorICAgICBmdWxsIHpvbmVpbmZvIHRhYmxlcyBpbnN0
YWxsZWQuICAqLworICBwdXRlbnYgKChjaGFyKikgIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAi
KTsKKworICB0bS50bV95ZWFyID0gOTg7CisgIHRtLnRtX21vbiA9IDM7CisgIHRtLnRtX21kYXkg
PSA1OworICB0bS50bV9ob3VyID0gMjsKKyAgdG0udG1fbWluID0gMDsKKyAgdG0udG1fc2VjID0g
MDsKKyAgdG0udG1faXNkc3QgPSAtMTsKKyAgcmV0dXJuIG1rdGltZSAoJnRtKSAhPSAodGltZV90
KSAtMTsKK30KKworc3RhdGljIGludAorbWt0aW1lX3Rlc3QxICh0aW1lX3Qgbm93KQoreworICBz
dHJ1Y3QgdG0gKmx0OworICByZXR1cm4gISAobHQgPSBsb2NhbHRpbWUgKCZub3cpKSB8fCBta3Rp
bWUgKGx0KSA9PSBub3c7Cit9CisKK3N0YXRpYyBpbnQKK21rdGltZV90ZXN0ICh0aW1lX3Qgbm93
KQoreworICByZXR1cm4gKG1rdGltZV90ZXN0MSAobm93KQorCSAgJiYgbWt0aW1lX3Rlc3QxICgo
dGltZV90KSAodGltZV90X21heCAtIG5vdykpCisJICAmJiBta3RpbWVfdGVzdDEgKCh0aW1lX3Qp
ICh0aW1lX3RfbWluICsgbm93KSkpOworfQorCitzdGF0aWMgaW50Citpcml4XzZfNF9idWcgKCkK
K3sKKyAgLyogQmFzZWQgb24gY29kZSBmcm9tIEFyaWVsIEZhaWdvbi4gICovCisgIHN0cnVjdCB0
bSB0bTsKKyAgdG0udG1feWVhciA9IDk2OworICB0bS50bV9tb24gPSAzOworICB0bS50bV9tZGF5
ID0gMDsKKyAgdG0udG1faG91ciA9IDA7CisgIHRtLnRtX21pbiA9IDA7CisgIHRtLnRtX3NlYyA9
IDA7CisgIHRtLnRtX2lzZHN0ID0gLTE7CisgIG1rdGltZSAoJnRtKTsKKyAgcmV0dXJuIHRtLnRt
X21vbiA9PSAyICYmIHRtLnRtX21kYXkgPT0gMzE7Cit9CisKK3N0YXRpYyBpbnQKK2JpZ3RpbWVf
dGVzdCAoaW50IGopCit7CisgIHN0cnVjdCB0bSB0bTsKKyAgdGltZV90IG5vdzsKKyAgdG0udG1f
eWVhciA9IHRtLnRtX21vbiA9IHRtLnRtX21kYXkgPSB0bS50bV9ob3VyID0gdG0udG1fbWluID0g
dG0udG1fc2VjID0gajsKKyAgbm93ID0gbWt0aW1lICgmdG0pOworICBpZiAobm93ICE9ICh0aW1l
X3QpIC0xKQorICAgIHsKKyAgICAgIHN0cnVjdCB0bSAqbHQgPSBsb2NhbHRpbWUgKCZub3cpOwor
ICAgICAgaWYgKCEgKGx0CisJICAgICAmJiBsdC0+dG1feWVhciA9PSB0bS50bV95ZWFyCisJICAg
ICAmJiBsdC0+dG1fbW9uID09IHRtLnRtX21vbgorCSAgICAgJiYgbHQtPnRtX21kYXkgPT0gdG0u
dG1fbWRheQorCSAgICAgJiYgbHQtPnRtX2hvdXIgPT0gdG0udG1faG91cgorCSAgICAgJiYgbHQt
PnRtX21pbiA9PSB0bS50bV9taW4KKwkgICAgICYmIGx0LT50bV9zZWMgPT0gdG0udG1fc2VjCisJ
ICAgICAmJiBsdC0+dG1feWRheSA9PSB0bS50bV95ZGF5CisJICAgICAmJiBsdC0+dG1fd2RheSA9
PSB0bS50bV93ZGF5CisJICAgICAmJiAoKGx0LT50bV9pc2RzdCA8IDAgPyAtMSA6IDAgPCBsdC0+
dG1faXNkc3QpCisJCSAgPT0gKHRtLnRtX2lzZHN0IDwgMCA/IC0xIDogMCA8IHRtLnRtX2lzZHN0
KSkpKQorCXJldHVybiAwOworICAgIH0KKyAgcmV0dXJuIDE7Cit9CisKK3N0YXRpYyBpbnQKK3ll
YXJfMjA1MF90ZXN0ICgpCit7CisgIC8qIFRoZSBjb3JyZWN0IGFuc3dlciBmb3IgMjA1MC0wMi0w
MSAwMDowMDowMCBpbiBQYWNpZmljIHRpbWUsCisgICAgIGlnbm9yaW5nIGxlYXAgc2Vjb25kcy4g
ICovCisgIHVuc2lnbmVkIGxvbmcgaW50IGFuc3dlciA9IDI1MjczMTUyMDBVTDsKKworICBzdHJ1
Y3QgdG0gdG07CisgIHRpbWVfdCB0OworICB0bS50bV95ZWFyID0gMjA1MCAtIDE5MDA7CisgIHRt
LnRtX21vbiA9IDIgLSAxOworICB0bS50bV9tZGF5ID0gMTsKKyAgdG0udG1faG91ciA9IHRtLnRt
X21pbiA9IHRtLnRtX3NlYyA9IDA7CisgIHRtLnRtX2lzZHN0ID0gLTE7CisKKyAgLyogVXNlIHRo
ZSBwb3J0YWJsZSBQT1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41
LjAiCisgICAgIGluc3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBvcmRlciB0byBk
ZXRlY3QgdGhlIGJ1ZyBldmVuCisgICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBzdXBwb3J0IHRo
ZSBPbHNvbiBleHRlbnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCisgICAgIGZ1bGwgem9uZWluZm8g
dGFibGVzIGluc3RhbGxlZC4gICovCisgIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNUOFBEVCxNNC4x
LjAsTTEwLjUuMCIpOworCisgIHQgPSBta3RpbWUgKCZ0bSk7CisKKyAgLyogQ2hlY2sgdGhhdCB0
aGUgcmVzdWx0IGlzIGVpdGhlciBhIGZhaWx1cmUsIG9yIGNsb3NlIGVub3VnaAorICAgICB0byB0
aGUgY29ycmVjdCBhbnN3ZXIgdGhhdCB3ZSBjYW4gYXNzdW1lIHRoZSBkaXNjcmVwYW5jeSBpcwor
ICAgICBkdWUgdG8gbGVhcCBzZWNvbmRzLiAgKi8KKyAgcmV0dXJuICh0ID09ICh0aW1lX3QpIC0x
CisJICB8fCAoMCA8IHQgJiYgYW5zd2VyIC0gMTIwIDw9IHQgJiYgdCA8PSBhbnN3ZXIgKyAxMjAp
KTsKK30KKworaW50CittYWluICgpCit7CisgIHRpbWVfdCB0LCBkZWx0YTsKKyAgaW50IGksIGo7
CisKKyAgLyogVGhpcyB0ZXN0IG1ha2VzIHNvbWUgYnVnZ3kgbWt0aW1lIGltcGxlbWVudGF0aW9u
cyBsb29wLgorICAgICBHaXZlIHVwIGFmdGVyIDYwIHNlY29uZHM7IGEgbWt0aW1lIHNsb3dlciB0
aGFuIHRoYXQKKyAgICAgaXNuJ3Qgd29ydGggdXNpbmcgYW55d2F5LiAgKi8KKyAgYWxhcm0gKDYw
KTsKKworICBmb3IgKDs7KQorICAgIHsKKyAgICAgIHQgPSAodGltZV90X21heCA8PCAxKSArIDE7
CisgICAgICBpZiAodCA8PSB0aW1lX3RfbWF4KQorCWJyZWFrOworICAgICAgdGltZV90X21heCA9
IHQ7CisgICAgfQorICB0aW1lX3RfbWluID0gLSAoKHRpbWVfdCkgfiAodGltZV90KSAwID09ICh0
aW1lX3QpIC0xKSAtIHRpbWVfdF9tYXg7CisKKyAgZGVsdGEgPSB0aW1lX3RfbWF4IC8gOTk3OyAv
KiBhIHN1aXRhYmxlIHByaW1lIG51bWJlciAqLworICBmb3IgKGkgPSAwOyBpIDwgTl9TVFJJTkdT
OyBpKyspCisgICAgeworICAgICAgaWYgKHR6X3N0cmluZ3NbaV0pCisJcHV0ZW52ICgoY2hhciop
IHR6X3N0cmluZ3NbaV0pOworCisgICAgICBmb3IgKHQgPSAwOyB0IDw9IHRpbWVfdF9tYXggLSBk
ZWx0YTsgdCArPSBkZWx0YSkKKwlpZiAoISBta3RpbWVfdGVzdCAodCkpCisJICByZXR1cm4gMTsK
KyAgICAgIGlmICghIChta3RpbWVfdGVzdCAoKHRpbWVfdCkgMSkKKwkgICAgICYmIG1rdGltZV90
ZXN0ICgodGltZV90KSAoNjAgKiA2MCkpCisJICAgICAmJiBta3RpbWVfdGVzdCAoKHRpbWVfdCkg
KDYwICogNjAgKiAyNCkpKSkKKwlyZXR1cm4gMTsKKworICAgICAgZm9yIChqID0gMTsgOyBqIDw8
PSAxKQorCWlmICghIGJpZ3RpbWVfdGVzdCAoaikpCisJICByZXR1cm4gMTsKKwllbHNlIGlmIChJ
TlRfTUFYIC8gMiA8IGopCisJICBicmVhazsKKyAgICAgIGlmICghIGJpZ3RpbWVfdGVzdCAoSU5U
X01BWCkpCisJcmV0dXJuIDE7CisgICAgfQorICByZXR1cm4gISAoaXJpeF82XzRfYnVnICgpICYm
IHNwcmluZ19mb3J3YXJkX2dhcCAoKSAmJiB5ZWFyXzIwNTBfdGVzdCAoKSk7Cit9CitfQUNFT0YK
K2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3dvcmtp
bmdfbWt0aW1lPXllcworZWxzZQorICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCitmaQor
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY193b3JraW5nX21rdGltZSIgPiY1CiskYXNfZWNobyAi
JGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY193
b3JraW5nX21rdGltZSA9IG5vOyB0aGVuCisgIGNhc2UgIiAkTElCT0JKUyAiIGluCisgICoiIG1r
dGltZS4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgbWt0aW1lLiRh
Y19vYmpleHQiCisgOzsKK2VzYWMKKworZmkKKworCisKKworCisKK2ZvciBhY19mdW5jIGluIGdl
dHBhZ2VzaXplCitkbyA6CisgIGFjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgImdldHBhZ2Vz
aXplIiAiYWNfY3ZfZnVuY19nZXRwYWdlc2l6ZSIKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19nZXRw
YWdlc2l6ZSIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2Rl
ZmluZSBIQVZFX0dFVFBBR0VTSVpFIDEKK19BQ0VPRgorCitmaQorZG9uZQorCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGlu
ZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPW5vCitlbHNl
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisvKiBtYWxsb2MgbWlnaHQgaGF2
ZSBiZWVuIHJlbmFtZWQgYXMgcnBsX21hbGxvYy4gKi8KKyN1bmRlZiBtYWxsb2MKKworLyogVGhh
bmtzIHRvIE1pa2UgSGFlcnRlbCBhbmQgSmltIEF2ZXJhIGZvciB0aGlzIHRlc3QuCisgICBIZXJl
IGlzIGEgbWF0cml4IG9mIG1tYXAgcG9zc2liaWxpdGllczoKKwltbWFwIHByaXZhdGUgbm90IGZp
eGVkCisJbW1hcCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkgdW5tYXBwZWQK
KwltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVkCisJbW1hcCBz
aGFyZWQgbm90IGZpeGVkCisJbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJlIGN1cnJlbnRs
eSB1bm1hcHBlZAorCW1tYXAgc2hhcmVkIGZpeGVkIGF0IHNvbWV3aGVyZSBhbHJlYWR5IG1hcHBl
ZAorICAgRm9yIHByaXZhdGUgbWFwcGluZ3MsIHdlIHNob3VsZCB2ZXJpZnkgdGhhdCBjaGFuZ2Vz
IGNhbm5vdCBiZSByZWFkKCkKKyAgIGJhY2sgZnJvbSB0aGUgZmlsZSwgbm9yIG1tYXAncyBiYWNr
IGZyb20gdGhlIGZpbGUgYXQgYSBkaWZmZXJlbnQKKyAgIGFkZHJlc3MuICAoVGhlcmUgaGF2ZSBi
ZWVuIHN5c3RlbXMgd2hlcmUgcHJpdmF0ZSB3YXMgbm90IGNvcnJlY3RseQorICAgaW1wbGVtZW50
ZWQgbGlrZSB0aGUgaW5mYW1vdXMgaTM4NiBzdnI0LjAsIGFuZCBzeXN0ZW1zIHdoZXJlIHRoZQor
ICAgVk0gcGFnZSBjYWNoZSB3YXMgbm90IGNvaGVyZW50IHdpdGggdGhlIGZpbGUgc3lzdGVtIGJ1
ZmZlciBjYWNoZQorICAgbGlrZSBlYXJseSB2ZXJzaW9ucyBvZiBGcmVlQlNEIGFuZCBwb3NzaWJs
eSBjb250ZW1wb3JhcnkgTmV0QlNELikKKyAgIEZvciBzaGFyZWQgbWFwcGluZ3MsIHdlIHNob3Vs
ZCBjb252ZXJzZWx5IHZlcmlmeSB0aGF0IGNoYW5nZXMgZ2V0CisgICBwcm9wYWdhdGVkIGJhY2sg
dG8gYWxsIHRoZSBwbGFjZXMgdGhleSdyZSBzdXBwb3NlZCB0byBiZS4KKworICAgR3JlcCB3YW50
cyBwcml2YXRlIGZpeGVkIGFscmVhZHkgbWFwcGVkLgorICAgVGhlIG1haW4gdGhpbmdzIGdyZXAg
bmVlZHMgdG8ga25vdyBhYm91dCBtbWFwIGFyZToKKyAgICogZG9lcyBpdCBleGlzdCBhbmQgaXMg
aXQgc2FmZSB0byB3cml0ZSBpbnRvIHRoZSBtbWFwJ2QgYXJlYQorICAgKiBob3cgdG8gdXNlIGl0
IChCU0QgdmFyaWFudHMpICAqLworCisjaW5jbHVkZSA8ZmNudGwuaD4KKyNpbmNsdWRlIDxzeXMv
bW1hbi5oPgorCisjaWYgIWRlZmluZWQgU1REQ19IRUFERVJTICYmICFkZWZpbmVkIEhBVkVfU1RE
TElCX0gKK2NoYXIgKm1hbGxvYyAoKTsKKyNlbmRpZgorCisvKiBUaGlzIG1lc3Mgd2FzIGNvcGll
ZCBmcm9tIHRoZSBHTlUgZ2V0cGFnZXNpemUuaC4gICovCisjaWZuZGVmIEhBVkVfR0VUUEFHRVNJ
WkUKKyMgaWZkZWYgX1NDX1BBR0VTSVpFCisjICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBzeXNjb25m
KF9TQ19QQUdFU0laRSkKKyMgZWxzZSAvKiBubyBfU0NfUEFHRVNJWkUgKi8KKyMgIGlmZGVmIEhB
VkVfU1lTX1BBUkFNX0gKKyMgICBpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyMgICBpZmRlZiBFWEVD
X1BBR0VTSVpFCisjICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIEVYRUNfUEFHRVNJWkUKKyMgICBl
bHNlIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KKyMgICAgaWZkZWYgTkJQRworIyAgICAgZGVmaW5l
IGdldHBhZ2VzaXplKCkgTkJQRyAqIENMU0laRQorIyAgICAgaWZuZGVmIENMU0laRQorIyAgICAg
IGRlZmluZSBDTFNJWkUgMQorIyAgICAgZW5kaWYgLyogbm8gQ0xTSVpFICovCisjICAgIGVsc2Ug
Lyogbm8gTkJQRyAqLworIyAgICAgaWZkZWYgTkJQQworIyAgICAgIGRlZmluZSBnZXRwYWdlc2l6
ZSgpIE5CUEMKKyMgICAgIGVsc2UgLyogbm8gTkJQQyAqLworIyAgICAgIGlmZGVmIFBBR0VTSVpF
CisjICAgICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIFBBR0VTSVpFCisjICAgICAgZW5kaWYgLyog
UEFHRVNJWkUgKi8KKyMgICAgIGVuZGlmIC8qIG5vIE5CUEMgKi8KKyMgICAgZW5kaWYgLyogbm8g
TkJQRyAqLworIyAgIGVuZGlmIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KKyMgIGVsc2UgLyogbm8g
SEFWRV9TWVNfUEFSQU1fSCAqLworIyAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIDgxOTIJLyogcHVu
dCB0b3RhbGx5ICovCisjICBlbmRpZiAvKiBubyBIQVZFX1NZU19QQVJBTV9IICovCisjIGVuZGlm
IC8qIG5vIF9TQ19QQUdFU0laRSAqLworCisjZW5kaWYgLyogbm8gSEFWRV9HRVRQQUdFU0laRSAq
LworCitpbnQKK21haW4gKCkKK3sKKyAgY2hhciAqZGF0YSwgKmRhdGEyLCAqZGF0YTM7CisgIGNv
bnN0IGNoYXIgKmNkYXRhMjsKKyAgaW50IGksIHBhZ2VzaXplOworICBpbnQgZmQsIGZkMjsKKwor
ICBwYWdlc2l6ZSA9IGdldHBhZ2VzaXplICgpOworCisgIC8qIEZpcnN0LCBtYWtlIGEgZmlsZSB3
aXRoIHNvbWUga25vd24gZ2FyYmFnZSBpbiBpdC4gKi8KKyAgZGF0YSA9IChjaGFyICopIG1hbGxv
YyAocGFnZXNpemUpOworICBpZiAoIWRhdGEpCisgICAgcmV0dXJuIDE7CisgIGZvciAoaSA9IDA7
IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgICooZGF0YSArIGkpID0gcmFuZCAoKTsKKyAgdW1hc2sg
KDApOworICBmZCA9IGNyZWF0ICgiY29uZnRlc3QubW1hcCIsIDA2MDApOworICBpZiAoZmQgPCAw
KQorICAgIHJldHVybiAyOworICBpZiAod3JpdGUgKGZkLCBkYXRhLCBwYWdlc2l6ZSkgIT0gcGFn
ZXNpemUpCisgICAgcmV0dXJuIDM7CisgIGNsb3NlIChmZCk7CisKKyAgLyogTmV4dCwgY2hlY2sg
dGhhdCB0aGUgdGFpbCBvZiBhIHBhZ2UgaXMgemVyby1maWxsZWQuICBGaWxlIG11c3QgaGF2ZQor
ICAgICBub24temVybyBsZW5ndGgsIG90aGVyd2lzZSB3ZSByaXNrIFNJR0JVUyBmb3IgZW50aXJl
IHBhZ2UuICAqLworICBmZDIgPSBvcGVuICgiY29uZnRlc3QudHh0IiwgT19SRFdSIHwgT19DUkVB
VCB8IE9fVFJVTkMsIDA2MDApOworICBpZiAoZmQyIDwgMCkKKyAgICByZXR1cm4gNDsKKyAgY2Rh
dGEyID0gIiI7CisgIGlmICh3cml0ZSAoZmQyLCBjZGF0YTIsIDEpICE9IDEpCisgICAgcmV0dXJu
IDU7CisgIGRhdGEyID0gKGNoYXIgKikgbW1hcCAoMCwgcGFnZXNpemUsIFBST1RfUkVBRCB8IFBS
T1RfV1JJVEUsIE1BUF9TSEFSRUQsIGZkMiwgMEwpOworICBpZiAoZGF0YTIgPT0gTUFQX0ZBSUxF
RCkKKyAgICByZXR1cm4gNjsKKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCisgICAg
aWYgKCooZGF0YTIgKyBpKSkKKyAgICAgIHJldHVybiA3OworICBjbG9zZSAoZmQyKTsKKyAgaWYg
KG11bm1hcCAoZGF0YTIsIHBhZ2VzaXplKSkKKyAgICByZXR1cm4gODsKKworICAvKiBOZXh0LCB0
cnkgdG8gbW1hcCB0aGUgZmlsZSBhdCBhIGZpeGVkIGFkZHJlc3Mgd2hpY2ggYWxyZWFkeSBoYXMK
KyAgICAgc29tZXRoaW5nIGVsc2UgYWxsb2NhdGVkIGF0IGl0LiAgSWYgd2UgY2FuLCBhbHNvIG1h
a2Ugc3VyZSB0aGF0CisgICAgIHdlIHNlZSB0aGUgc2FtZSBnYXJiYWdlLiAgKi8KKyAgZmQgPSBv
cGVuICgiY29uZnRlc3QubW1hcCIsIE9fUkRXUik7CisgIGlmIChmZCA8IDApCisgICAgcmV0dXJu
IDk7CisgIGlmIChkYXRhMiAhPSBtbWFwIChkYXRhMiwgcGFnZXNpemUsIFBST1RfUkVBRCB8IFBS
T1RfV1JJVEUsCisJCSAgICAgTUFQX1BSSVZBVEUgfCBNQVBfRklYRUQsIGZkLCAwTCkpCisgICAg
cmV0dXJuIDEwOworICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKKyAgICBpZiAoKihk
YXRhICsgaSkgIT0gKihkYXRhMiArIGkpKQorICAgICAgcmV0dXJuIDExOworCisgIC8qIEZpbmFs
bHksIG1ha2Ugc3VyZSB0aGF0IGNoYW5nZXMgdG8gdGhlIG1hcHBlZCBhcmVhIGRvIG5vdAorICAg
ICBwZXJjb2xhdGUgYmFjayB0byB0aGUgZmlsZSBhcyBzZWVuIGJ5IHJlYWQoKS4gIChUaGlzIGlz
IGEgYnVnIG9uCisgICAgIHNvbWUgdmFyaWFudHMgb2YgaTM4NiBzdnI0LjAuKSAgKi8KKyAgZm9y
IChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCisgICAgKihkYXRhMiArIGkpID0gKihkYXRhMiAr
IGkpICsgMTsKKyAgZGF0YTMgPSAoY2hhciAqKSBtYWxsb2MgKHBhZ2VzaXplKTsKKyAgaWYgKCFk
YXRhMykKKyAgICByZXR1cm4gMTI7CisgIGlmIChyZWFkIChmZCwgZGF0YTMsIHBhZ2VzaXplKSAh
PSBwYWdlc2l6ZSkKKyAgICByZXR1cm4gMTM7CisgIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsg
KytpKQorICAgIGlmICgqKGRhdGEgKyBpKSAhPSAqKGRhdGEzICsgaSkpCisgICAgICByZXR1cm4g
MTQ7CisgIGNsb3NlIChmZCk7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZD15
ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZD1ubworZmkKK3JtIC1mIGNv
cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl
ZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l
eHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfbW1h
cF9maXhlZF9tYXBwZWQgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NTUFQ
IDEiID4+Y29uZmRlZnMuaAorCitmaQorcm0gLWYgY29uZnRlc3QubW1hcCBjb25mdGVzdC50eHQK
KworZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAorZG8gOgorICBhY19mbl9jX2NoZWNrX2hlYWRl
cl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJfc3RkbGliX2giICIk
YWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiA9
IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVf
U1RETElCX0ggMQorX0FDRU9GCisKK2ZpCisKK2RvbmUKKworeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSByZWFs
bG9jIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIHJl
YWxsb2MuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbCs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19yZWFsbG9j
XzBfbm9ubnVsbD1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWYgZGVmaW5lZCBTVERDX0hFQURF
UlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9ICisjIGluY2x1ZGUgPHN0ZGxpYi5oPgorI2Vsc2UK
K2NoYXIgKnJlYWxsb2MgKCk7CisjZW5kaWYKKworaW50CittYWluICgpCit7CityZXR1cm4gISBy
ZWFsbG9jICgwLCAwKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGw9
eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGw9bm8KK2ZpCitybSAtZiBj
b3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4
ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNf
ZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX3Jl
YWxsb2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9S
RUFMTE9DIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisgICRhc19lY2hvICIjZGVmaW5lIEhBVkVf
UkVBTExPQyAwIiA+PmNvbmZkZWZzLmgKKworICAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIg
cmVhbGxvYy4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgcmVhbGxv
Yy4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKKworJGFzX2VjaG8gIiNkZWZpbmUgcmVhbGxvYyBy
cGxfcmVhbGxvYyIgPj5jb25mZGVmcy5oCisKK2ZpCisKKworIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RybmxlbiIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBzdHJubGVuLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5
ZXM7IHRoZW4gOgorICAjIEd1ZXNzIG5vIG9uIEFJWCBzeXN0ZW1zLCB5ZXMgb3RoZXJ3aXNlLgor
CQljYXNlICIkaG9zdF9vcyIgaW4KKwkJICBhaXgqKSBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2lu
Zz1ubzs7CisJCSAgKikgICAgYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9eWVzOzsKKwkJZXNh
YworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50CittYWluICgp
Cit7CisKKyNkZWZpbmUgUyAiZm9vYmFyIgorI2RlZmluZSBTX0xFTiAoc2l6ZW9mIFMgLSAxKQor
CisgIC8qIEF0IGxlYXN0IG9uZSBpbXBsZW1lbnRhdGlvbiBpcyBidWdneTogdGhhdCBvZiBBSVgg
NC4zIHdvdWxkCisgICAgIGdpdmUgc3RybmxlbiAoUywgMSkgPT0gMy4gICovCisKKyAgaW50IGk7
CisgIGZvciAoaSA9IDA7IGkgPCBTX0xFTiArIDE7ICsraSkKKyAgICB7CisgICAgICBpbnQgZXhw
ZWN0ZWQgPSBpIDw9IFNfTEVOID8gaSA6IFNfTEVOOworICAgICAgaWYgKHN0cm5sZW4gKFMsIGkp
ICE9IGV4cGVjdGVkKQorCXJldHVybiAxOworICAgIH0KKyAgcmV0dXJuIDA7CisKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nPXllcworZWxzZQorICBhY19jdl9mdW5jX3N0
cm5sZW5fd29ya2luZz1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBn
bW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfc3Rybmxlbl93
b3JraW5nIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmciID4mNjsg
fQordGVzdCAkYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmcgPSBubyAmJiBjYXNlICIgJExJQk9C
SlMgIiBpbgorICAqIiBzdHJubGVuLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIk
TElCT0JKUyBzdHJubGVuLiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBzdHJ0b2QuLi4gIiA+JjY7IH0K
K2lmICR7YWNfY3ZfZnVuY19zdHJ0b2QrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsg
dGhlbiA6CisgIGFjX2N2X2Z1bmNfc3RydG9kPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworJGFj
X2luY2x1ZGVzX2RlZmF1bHQKKyNpZm5kZWYgc3RydG9kCitkb3VibGUgc3RydG9kICgpOworI2Vu
ZGlmCitpbnQKK21haW4oKQoreworICB7CisgICAgLyogU29tZSB2ZXJzaW9ucyBvZiBMaW51eCBz
dHJ0b2QgbWlzLXBhcnNlIHN0cmluZ3Mgd2l0aCBsZWFkaW5nICcrJy4gICovCisgICAgY2hhciAq
c3RyaW5nID0gIiArNjkiOworICAgIGNoYXIgKnRlcm07CisgICAgZG91YmxlIHZhbHVlOworICAg
IHZhbHVlID0gc3RydG9kIChzdHJpbmcsICZ0ZXJtKTsKKyAgICBpZiAodmFsdWUgIT0gNjkgfHwg
dGVybSAhPSAoc3RyaW5nICsgNCkpCisgICAgICByZXR1cm4gMTsKKyAgfQorCisgIHsKKyAgICAv
KiBVbmRlciBTb2xhcmlzIDIuNCwgc3RydG9kIHJldHVybnMgdGhlIHdyb25nIHZhbHVlIGZvciB0
aGUKKyAgICAgICB0ZXJtaW5hdGluZyBjaGFyYWN0ZXIgdW5kZXIgc29tZSBjb25kaXRpb25zLiAg
Ki8KKyAgICBjaGFyICpzdHJpbmcgPSAiTmFOIjsKKyAgICBjaGFyICp0ZXJtOworICAgIHN0cnRv
ZCAoc3RyaW5nLCAmdGVybSk7CisgICAgaWYgKHRlcm0gIT0gc3RyaW5nICYmICoodGVybSAtIDEp
ID09IDApCisgICAgICByZXR1cm4gMTsKKyAgfQorICByZXR1cm4gMDsKK30KKworX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19zdHJ0b2Q9
eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfc3RydG9kPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUg
Y29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKwor
ZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3ZfZnVuY19zdHJ0b2QiID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX3N0cnRvZCIgPiY2OyB9
CitpZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRvZCA9IG5vOyB0aGVuCisgIGNhc2UgIiAkTElCT0JK
UyAiIGluCisgICoiIHN0cnRvZC4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJ
Qk9CSlMgc3RydG9kLiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworYWNfZm5fY19jaGVja19mdW5j
ICIkTElORU5PIiAicG93IiAiYWNfY3ZfZnVuY19wb3ciCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNf
cG93IiA9IHh5ZXM7IHRoZW4gOgorCitmaQorCitpZiB0ZXN0ICRhY19jdl9mdW5jX3BvdyA9IG5v
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIHBvdyBpbiAtbG0iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHBvdyBpbiAt
bG0uLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX21fcG93Kzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElC
Uz0kTElCUworTElCUz0iLWxtICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55
IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0
aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov
CisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBwb3cgKCk7Citp
bnQKK21haW4gKCkKK3sKK3JldHVybiBwb3cgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNF
T0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX21f
cG93PXllcworZWxzZQorICBhY19jdl9saWJfbV9wb3c9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29u
ZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX21fcG93
IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX21fcG93IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNf
Y3ZfbGliX21fcG93IiA9IHh5ZXM7IHRoZW4gOgorICBQT1dfTElCPS1sbQorZWxzZQorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IGNhbm5vdCBmaW5k
IGxpYnJhcnkgY29udGFpbmluZyBkZWZpbml0aW9uIG9mIHBvdyIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJyYXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBv
ZiBwb3ciID4mMjt9CitmaQorCitmaQorCitmaQorCitmb3IgYWNfZnVuYyBpbiAgXAorICAgICAg
ICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5j
IGZ0cnVuY2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9z
dG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250
b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAg
ICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRp
ciBzZWxlY3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJj
aHIgc3RyY3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3Ry
cGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQg
XAorICAgICAgICAgICAgICAgIHVuYW1lIFwKKworZG8gOgorICBhc19hY192YXI9YCRhc19lY2hv
ICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfZnVuYyAi
JExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3ZhciIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNf
YWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2Z1bmMiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9G
CisKK2ZpCitkb25lCisKKworY2F0ID5jb25mY2FjaGUgPDxcX0FDRU9GCisjIFRoaXMgZmlsZSBp
cyBhIHNoZWxsIHNjcmlwdCB0aGF0IGNhY2hlcyB0aGUgcmVzdWx0cyBvZiBjb25maWd1cmUKKyMg
dGVzdHMgcnVuIG9uIHRoaXMgc3lzdGVtIHNvIHRoZXkgY2FuIGJlIHNoYXJlZCBiZXR3ZWVuIGNv
bmZpZ3VyZQorIyBzY3JpcHRzIGFuZCBjb25maWd1cmUgcnVucywgc2VlIGNvbmZpZ3VyZSdzIG9w
dGlvbiAtLWNvbmZpZy1jYWNoZS4KKyMgSXQgaXMgbm90IHVzZWZ1bCBvbiBvdGhlciBzeXN0ZW1z
LiAgSWYgaXQgY29udGFpbnMgcmVzdWx0cyB5b3UgZG9uJ3QKKyMgd2FudCB0byBrZWVwLCB5b3Ug
bWF5IHJlbW92ZSBvciBlZGl0IGl0LgorIworIyBjb25maWcuc3RhdHVzIG9ubHkgcGF5cyBhdHRl
bnRpb24gdG8gdGhlIGNhY2hlIGZpbGUgaWYgeW91IGdpdmUgaXQKKyMgdGhlIC0tcmVjaGVjayBv
cHRpb24gdG8gcmVydW4gY29uZmlndXJlLgorIworIyBgYWNfY3ZfZW52X2ZvbycgdmFyaWFibGVz
IChzZXQgb3IgdW5zZXQpIHdpbGwgYmUgb3ZlcnJpZGRlbiB3aGVuCisjIGxvYWRpbmcgdGhpcyBm
aWxlLCBvdGhlciAqdW5zZXQqIGBhY19jdl9mb28nIHdpbGwgYmUgYXNzaWduZWQgdGhlCisjIGZv
bGxvd2luZyB2YWx1ZXMuCisKK19BQ0VPRgorCisjIFRoZSBmb2xsb3dpbmcgd2F5IG9mIHdyaXRp
bmcgdGhlIGNhY2hlIG1pc2hhbmRsZXMgbmV3bGluZXMgaW4gdmFsdWVzLAorIyBidXQgd2Uga25v
dyBvZiBubyB3b3JrYXJvdW5kIHRoYXQgaXMgc2ltcGxlLCBwb3J0YWJsZSwgYW5kIGVmZmljaWVu
dC4KKyMgU28sIHdlIGtpbGwgdmFyaWFibGVzIGNvbnRhaW5pbmcgbmV3bGluZXMuCisjIFVsdHJp
eCBzaCBzZXQgd3JpdGVzIHRvIHN0ZGVyciBhbmQgY2FuJ3QgYmUgcmVkaXJlY3RlZCBkaXJlY3Rs
eSwKKyMgYW5kIHNldHMgdGhlIGhpZ2ggYml0IGluIHRoZSBjYWNoZSBmaWxlIHVubGVzcyB3ZSBh
c3NpZ24gdG8gdGhlIHZhcnMuCisoCisgIGZvciBhY192YXIgaW4gYChzZXQpIDI+JjEgfCBzZWQg
LW4gJ3MvXlwoW2EtekEtWl9dW2EtekEtWjAtOV9dKlwpPS4qL1wxL3AnYDsgZG8KKyAgICBldmFs
IGFjX3ZhbD1cJCRhY192YXIKKyAgICBjYXNlICRhY192YWwgaW4gIygKKyAgICAqJHthc19ubH0q
KQorICAgICAgY2FzZSAkYWNfdmFyIGluICMoCisgICAgICAqX2N2XyopIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogY2FjaGUgdmFyaWFibGUgJGFjX3Zh
ciBjb250YWlucyBhIG5ld2xpbmUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogY2Fj
aGUgdmFyaWFibGUgJGFjX3ZhciBjb250YWlucyBhIG5ld2xpbmUiID4mMjt9IDs7CisgICAgICBl
c2FjCisgICAgICBjYXNlICRhY192YXIgaW4gIygKKyAgICAgIF8gfCBJRlMgfCBhc19ubCkgOzsg
IygKKyAgICAgIEJBU0hfQVJHViB8IEJBU0hfU09VUkNFKSBldmFsICRhY192YXI9IDs7ICMoCisg
ICAgICAqKSB7IGV2YWwgJGFjX3Zhcj07IHVuc2V0ICRhY192YXI7fSA7OworICAgICAgZXNhYyA7
OworICAgIGVzYWMKKyAgZG9uZQorCisgIChzZXQpIDI+JjEgfAorICAgIGNhc2UgJGFzX25sYChh
Y19zcGFjZT0nICc7IHNldCkgMj4mMWAgaW4gIygKKyAgICAqJHthc19ubH1hY19zcGFjZT1cICop
CisgICAgICAjIGBzZXQnIGRvZXMgbm90IHF1b3RlIGNvcnJlY3RseSwgc28gYWRkIHF1b3Rlczog
ZG91YmxlLXF1b3RlCisgICAgICAjIHN1YnN0aXR1dGlvbiB0dXJucyBcXFxcIGludG8gXFwsIGFu
ZCBzZWQgdHVybnMgXFwgaW50byBcLgorICAgICAgc2VkIC1uIFwKKwkicy8nLydcXFxcJycvZzsK
KwkgIHMvXlxcKFtfJGFzX2NyX2FsbnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKlxcKT1cXCguKlxc
KS9cXDE9J1xcMicvcCIKKyAgICAgIDs7ICMoCisgICAgKikKKyAgICAgICMgYHNldCcgcXVvdGVz
IGNvcnJlY3RseSBhcyByZXF1aXJlZCBieSBQT1NJWCwgc28gZG8gbm90IGFkZCBxdW90ZXMuCisg
ICAgICBzZWQgLW4gIi9eW18kYXNfY3JfYWxudW1dKl9jdl9bXyRhc19jcl9hbG51bV0qPS9wIgor
ICAgICAgOzsKKyAgICBlc2FjIHwKKyAgICBzb3J0CispIHwKKyAgc2VkICcKKyAgICAgL15hY19j
dl9lbnZfL2IgZW5kCisgICAgIHQgY2xlYXIKKyAgICAgOmNsZWFyCisgICAgIHMvXlwoW149XSpc
KT1cKC4qW3t9XS4qXCkkL3Rlc3QgIiR7XDErc2V0fSIgPSBzZXQgfHwgJi8KKyAgICAgdCBlbmQK
KyAgICAgcy9eXChbXj1dKlwpPVwoLipcKSQvXDE9JHtcMT1cMn0vCisgICAgIDplbmQnID4+Y29u
ZmNhY2hlCitpZiBkaWZmICIkY2FjaGVfZmlsZSIgY29uZmNhY2hlID4vZGV2L251bGwgMj4mMTsg
dGhlbiA6OyBlbHNlCisgIGlmIHRlc3QgLXcgIiRjYWNoZV9maWxlIjsgdGhlbgorICAgIGlmIHRl
c3QgIngkY2FjaGVfZmlsZSIgIT0gIngvZGV2L251bGwiOyB0aGVuCisgICAgICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHVwZGF0aW5nIGNhY2hlICRjYWNoZV9maWxl
IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IHVwZGF0aW5nIGNhY2hlICRjYWNoZV9maWxlIiA+JjY7
fQorICAgICAgaWYgdGVzdCAhIC1mICIkY2FjaGVfZmlsZSIgfHwgdGVzdCAtaCAiJGNhY2hlX2Zp
bGUiOyB0aGVuCisJY2F0IGNvbmZjYWNoZSA+IiRjYWNoZV9maWxlIgorICAgICAgZWxzZQorICAg
ICAgICBjYXNlICRjYWNoZV9maWxlIGluICMoCisgICAgICAgICovKiB8ID86KikKKwkgIG12IC1m
IGNvbmZjYWNoZSAiJGNhY2hlX2ZpbGUiJCQgJiYKKwkgIG12IC1mICIkY2FjaGVfZmlsZSIkJCAi
JGNhY2hlX2ZpbGUiIDs7ICMoCisgICAgICAgICopCisJICBtdiAtZiBjb25mY2FjaGUgIiRjYWNo
ZV9maWxlIiA7OworCWVzYWMKKyAgICAgIGZpCisgICAgZmkKKyAgZWxzZQorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogbm90IHVwZGF0aW5nIHVud3JpdGFibGUg
Y2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogbm90IHVwZGF0aW5nIHVu
d3JpdGFibGUgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9CisgIGZpCitmaQorcm0gLWYgY29uZmNh
Y2hlCisKK3Rlc3QgIngkcHJlZml4IiA9IHhOT05FICYmIHByZWZpeD0kYWNfZGVmYXVsdF9wcmVm
aXgKKyMgTGV0IG1ha2UgZXhwYW5kIGV4ZWNfcHJlZml4LgordGVzdCAieCRleGVjX3ByZWZpeCIg
PSB4Tk9ORSAmJiBleGVjX3ByZWZpeD0nJHtwcmVmaXh9JworCitERUZTPS1ESEFWRV9DT05GSUdf
SAorCithY19saWJvYmpzPQorYWNfbHRsaWJvYmpzPQorVT0KK2ZvciBhY19pIGluIDogJExJQk9C
SlM7IGRvIHRlc3QgIngkYWNfaSIgPSB4OiAmJiBjb250aW51ZQorICAjIDEuIFJlbW92ZSB0aGUg
ZXh0ZW5zaW9uLCBhbmQgJFUgaWYgYWxyZWFkeSBpbnN0YWxsZWQuCisgIGFjX3NjcmlwdD0ncy9c
JFVcLi8uLztzL1wubyQvLztzL1wub2JqJC8vJworICBhY19pPWAkYXNfZWNobyAiJGFjX2kiIHwg
c2VkICIkYWNfc2NyaXB0ImAKKyAgIyAyLiBQcmVwZW5kIExJQk9CSkRJUi4gIFdoZW4gdXNlZCB3
aXRoIGF1dG9tYWtlPj0xLjEwIExJQk9CSkRJUgorICAjICAgIHdpbGwgYmUgc2V0IHRvIHRoZSBk
aXJlY3Rvcnkgd2hlcmUgTElCT0JKUyBvYmplY3RzIGFyZSBidWlsdC4KKyAgYXNfZm5fYXBwZW5k
IGFjX2xpYm9ianMgIiBcJHtMSUJPQkpESVJ9JGFjX2lcJFUuJGFjX29iamV4dCIKKyAgYXNfZm5f
YXBwZW5kIGFjX2x0bGlib2JqcyAiIFwke0xJQk9CSkRJUn0kYWNfaSInJFUubG8nCitkb25lCitM
SUJPQkpTPSRhY19saWJvYmpzCisKK0xUTElCT0JKUz0kYWNfbHRsaWJvYmpzCisKKworCis6ICIk
e0NPTkZJR19TVEFUVVM9Li9jb25maWcuc3RhdHVzfSIKK2FjX3dyaXRlX2ZhaWw9MAorYWNfY2xl
YW5fZmlsZXNfc2F2ZT0kYWNfY2xlYW5fZmlsZXMKK2FjX2NsZWFuX2ZpbGVzPSIkYWNfY2xlYW5f
ZmlsZXMgJENPTkZJR19TVEFUVVMiCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNyZWF0aW5nICRDT05GSUdfU1RBVFVTIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGNy
ZWF0aW5nICRDT05GSUdfU1RBVFVTIiA+JjY7fQorYXNfd3JpdGVfZmFpbD0wCitjYXQgPiRDT05G
SUdfU1RBVFVTIDw8X0FTRU9GIHx8IGFzX3dyaXRlX2ZhaWw9MQorIyEgJFNIRUxMCisjIEdlbmVy
YXRlZCBieSAkYXNfbWUuCisjIFJ1biB0aGlzIGZpbGUgdG8gcmVjcmVhdGUgdGhlIGN1cnJlbnQg
Y29uZmlndXJhdGlvbi4KKyMgQ29tcGlsZXIgb3V0cHV0IHByb2R1Y2VkIGJ5IGNvbmZpZ3VyZSwg
dXNlZnVsIGZvciBkZWJ1Z2dpbmcKKyMgY29uZmlndXJlLCBpcyBpbiBjb25maWcubG9nIGlmIGl0
IGV4aXN0cy4KKworZGVidWc9ZmFsc2UKK2FjX2NzX3JlY2hlY2s9ZmFsc2UKK2FjX2NzX3NpbGVu
dD1mYWxzZQorCitTSEVMTD1cJHtDT05GSUdfU0hFTEwtJFNIRUxMfQorZXhwb3J0IFNIRUxMCitf
QVNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BU0VPRiB8fCBhc193cml0ZV9mYWlsPTEK
KyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBNNHNoIEluaXRpYWxpemF0aW9uLiAjIwor
IyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKworIyBCZSBtb3JlIEJvdXJuZSBjb21wYXRpYmxl
CitEVUFMQ0FTRT0xOyBleHBvcnQgRFVBTENBU0UgIyBmb3IgTUtTIHNoCitpZiB0ZXN0IC1uICIk
e1pTSF9WRVJTSU9OK3NldH0iICYmIChlbXVsYXRlIHNoKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4g
OgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9OgorICAjIFByZS00LjIgdmVyc2lvbnMgb2YgWnNo
IGRvIHdvcmQgc3BsaXR0aW5nIG9uICR7MSsiJEAifSwgd2hpY2gKKyAgIyBpcyBjb250cmFyeSB0
byBvdXIgdXNhZ2UuICBEaXNhYmxlIHRoaXMgZmVhdHVyZS4KKyAgYWxpYXMgLWcgJyR7MSsiJEAi
fSc9JyIkQCInCisgIHNldG9wdCBOT19HTE9CX1NVQlNUCitlbHNlCisgIGNhc2UgYChzZXQgLW8p
IDI+L2Rldi9udWxsYCBpbiAjKAorICAqcG9zaXgqKSA6CisgICAgc2V0IC1vIHBvc2l4IDs7ICMo
CisgICopIDoKKyAgICAgOzsKK2VzYWMKK2ZpCisKKworYXNfbmw9JworJworZXhwb3J0IGFzX25s
CisjIFByaW50aW5nIGEgbG9uZyBzdHJpbmcgY3Jhc2hlcyBTb2xhcmlzIDcgL3Vzci9iaW4vcHJp
bnRmLgorYXNfZWNobz0nXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXCcKK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobwor
YXNfZWNobz0kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8K
KyMgUHJlZmVyIGEga3NoIHNoZWxsIGJ1aWx0aW4gb3ZlciBhbiBleHRlcm5hbCBwcmludGYgcHJv
Z3JhbSBvbiBTb2xhcmlzLAorIyBidXQgd2l0aG91dCB3YXN0aW5nIGZvcmtzIGZvciBiYXNoIG9y
IHpzaC4KK2lmIHRlc3QgLXogIiRCQVNIX1ZFUlNJT04kWlNIX1ZFUlNJT04iIFwKKyAgICAmJiAo
dGVzdCAiWGBwcmludCAtciAtLSAkYXNfZWNob2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9udWxs
OyB0aGVuCisgIGFzX2VjaG89J3ByaW50IC1yIC0tJworICBhc19lY2hvX249J3ByaW50IC1ybiAt
LScKK2VsaWYgKHRlc3QgIlhgcHJpbnRmICVzICRhc19lY2hvYCIgPSAiWCRhc19lY2hvIikgMj4v
ZGV2L251bGw7IHRoZW4KKyAgYXNfZWNobz0ncHJpbnRmICVzXG4nCisgIGFzX2VjaG9fbj0ncHJp
bnRmICVzJworZWxzZQorICBpZiB0ZXN0ICJYYCgvdXNyL3VjYi9lY2hvIC1uIC1uICRhc19lY2hv
KSAyPi9kZXYvbnVsbGAiID0gIlgtbiAkYXNfZWNobyI7IHRoZW4KKyAgICBhc19lY2hvX2JvZHk9
J2V2YWwgL3Vzci91Y2IvZWNobyAtbiAiJDEkYXNfbmwiJworICAgIGFzX2VjaG9fbj0nL3Vzci91
Y2IvZWNobyAtbicKKyAgZWxzZQorICAgIGFzX2VjaG9fYm9keT0nZXZhbCBleHByICJYJDEiIDog
IlhcXCguKlxcKSInCisgICAgYXNfZWNob19uX2JvZHk9J2V2YWwKKyAgICAgIGFyZz0kMTsKKyAg
ICAgIGNhc2UgJGFyZyBpbiAjKAorICAgICAgKiIkYXNfbmwiKikKKwlleHByICJYJGFyZyIgOiAi
WFxcKC4qXFwpJGFzX25sIjsKKwlhcmc9YGV4cHIgIlgkYXJnIiA6ICIuKiRhc19ubFxcKC4qXFwp
ImA7OworICAgICAgZXNhYzsKKyAgICAgIGV4cHIgIlgkYXJnIiA6ICJYXFwoLipcXCkiIHwgdHIg
LWQgIiRhc19ubCIKKyAgICAnCisgICAgZXhwb3J0IGFzX2VjaG9fbl9ib2R5CisgICAgYXNfZWNo
b19uPSdzaCAtYyAkYXNfZWNob19uX2JvZHkgYXNfZWNobycKKyAgZmkKKyAgZXhwb3J0IGFzX2Vj
aG9fYm9keQorICBhc19lY2hvPSdzaCAtYyAkYXNfZWNob19ib2R5IGFzX2VjaG8nCitmaQorCisj
IFRoZSB1c2VyIGlzIGFsd2F5cyByaWdodC4KK2lmIHRlc3QgIiR7UEFUSF9TRVBBUkFUT1Irc2V0
fSIgIT0gc2V0OyB0aGVuCisgIFBBVEhfU0VQQVJBVE9SPToKKyAgKFBBVEg9Jy9iaW47L2Jpbic7
IEZQQVRIPSRQQVRIOyBzaCAtYyA6KSA+L2Rldi9udWxsIDI+JjEgJiYgeworICAgIChQQVRIPScv
YmluOi9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikgPi9kZXYvbnVsbCAyPiYxIHx8CisgICAg
ICBQQVRIX1NFUEFSQVRPUj0nOycKKyAgfQorZmkKKworCisjIElGUworIyBXZSBuZWVkIHNwYWNl
LCB0YWIgYW5kIG5ldyBsaW5lLCBpbiBwcmVjaXNlbHkgdGhhdCBvcmRlci4gIFF1b3RpbmcgaXMK
KyMgdGhlcmUgdG8gcHJldmVudCBlZGl0b3JzIGZyb20gY29tcGxhaW5pbmcgYWJvdXQgc3BhY2Ut
dGFiLgorIyAoSWYgX0FTX1BBVEhfV0FMSyB3ZXJlIGNhbGxlZCB3aXRoIElGUyB1bnNldCwgaXQg
d291bGQgZGlzYWJsZSB3b3JkCisjIHNwbGl0dGluZyBieSBzZXR0aW5nIElGUyB0byBlbXB0eSB2
YWx1ZS4pCitJRlM9IiAiIgkkYXNfbmwiCisKKyMgRmluZCB3aG8gd2UgYXJlLiAgTG9vayBpbiB0
aGUgcGF0aCBpZiB3ZSBjb250YWluIG5vIGRpcmVjdG9yeSBzZXBhcmF0b3IuCithc19teXNlbGY9
CitjYXNlICQwIGluICMoKAorICAqW1xcL10qICkgYXNfbXlzZWxmPSQwIDs7CisgICopIGFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICB0ZXN0IC1yICIkYXNfZGlyLyQwIiAmJiBhc19teXNlbGY9JGFzX2Rpci8kMCAmJiBicmVhawor
ICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgICAgOzsKK2VzYWMKKyMgV2UgZGlkIG5vdCBm
aW5kIG91cnNlbHZlcywgbW9zdCBwcm9iYWJseSB3ZSB3ZXJlIHJ1biBhcyBgc2ggQ09NTUFORCcK
KyMgaW4gd2hpY2ggY2FzZSB3ZSBhcmUgbm90IHRvIGJlIGZvdW5kIGluIHRoZSBwYXRoLgoraWYg
dGVzdCAieCRhc19teXNlbGYiID0geDsgdGhlbgorICBhc19teXNlbGY9JDAKK2ZpCitpZiB0ZXN0
ICEgLWYgIiRhc19teXNlbGYiOyB0aGVuCisgICRhc19lY2hvICIkYXNfbXlzZWxmOiBlcnJvcjog
Y2Fubm90IGZpbmQgbXlzZWxmOyByZXJ1biB3aXRoIGFuIGFic29sdXRlIGZpbGUgbmFtZSIgPiYy
CisgIGV4aXQgMQorZmkKKworIyBVbnNldCB2YXJpYWJsZXMgdGhhdCB3ZSBkbyBub3QgbmVlZCBh
bmQgd2hpY2ggY2F1c2UgYnVncyAoZS5nLiBpbgorIyBwcmUtMy4wIFVXSU4ga3NoKS4gIEJ1dCBk
byBub3QgY2F1c2UgYnVncyBpbiBiYXNoIDIuMDE7IHRoZSAifHwgZXhpdCAxIgorIyBzdXBwcmVz
c2VzIGFueSAiU2VnbWVudGF0aW9uIGZhdWx0IiBtZXNzYWdlIHRoZXJlLiAgJygoJyBjb3VsZAor
IyB0cmlnZ2VyIGEgYnVnIGluIHBka3NoIDUuMi4xNC4KK2ZvciBhc192YXIgaW4gQkFTSF9FTlYg
RU5WIE1BSUwgTUFJTFBBVEgKK2RvIGV2YWwgdGVzdCB4XCR7JGFzX3ZhcitzZXR9ID0geHNldCBc
CisgICYmICggKHVuc2V0ICRhc192YXIpIHx8IGV4aXQgMSkgPi9kZXYvbnVsbCAyPiYxICYmIHVu
c2V0ICRhc192YXIgfHwgOgorZG9uZQorUFMxPSckICcKK1BTMj0nPiAnCitQUzQ9JysgJworCisj
IE5MUyBudWlzYW5jZXMuCitMQ19BTEw9QworZXhwb3J0IExDX0FMTAorTEFOR1VBR0U9QworZXhw
b3J0IExBTkdVQUdFCisKKyMgQ0RQQVRILgorKHVuc2V0IENEUEFUSCkgPi9kZXYvbnVsbCAyPiYx
ICYmIHVuc2V0IENEUEFUSAorCisKKyMgYXNfZm5fZXJyb3IgU1RBVFVTIEVSUk9SIFtMSU5FTk8g
TE9HX0ZEXQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIE91
dHB1dCAiYGJhc2VuYW1lICQwYDogZXJyb3I6IEVSUk9SIiB0byBzdGRlcnIuIElmIExJTkVOTyBh
bmQgTE9HX0ZEIGFyZQorIyBwcm92aWRlZCwgYWxzbyBvdXRwdXQgdGhlIGVycm9yIHRvIExPR19G
RCwgcmVmZXJlbmNpbmcgTElORU5PLiBUaGVuIGV4aXQgdGhlCisjIHNjcmlwdCB3aXRoIFNUQVRV
UywgdXNpbmcgMSBpZiB0aGF0IHdhcyAwLgorYXNfZm5fZXJyb3IgKCkKK3sKKyAgYXNfc3RhdHVz
PSQxOyB0ZXN0ICRhc19zdGF0dXMgLWVxIDAgJiYgYXNfc3RhdHVzPTEKKyAgaWYgdGVzdCAiJDQi
OyB0aGVuCisgICAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMyJ9IGFzX2xpbmVub19zdGFjaz1h
c19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICAgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGVycm9yOiAkMiIgPiYkNAorICBmaQorICAkYXNfZWNobyAiJGFz
X21lOiBlcnJvcjogJDIiID4mMgorICBhc19mbl9leGl0ICRhc19zdGF0dXMKK30gIyBhc19mbl9l
cnJvcgorCisKKyMgYXNfZm5fc2V0X3N0YXR1cyBTVEFUVVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KKyMgU2V0ICQ/IHRvIFNUQVRVUywgd2l0aG91dCBmb3JraW5nLgorYXNfZm5fc2V0X3N0
YXR1cyAoKQoreworICByZXR1cm4gJDEKK30gIyBhc19mbl9zZXRfc3RhdHVzCisKKyMgYXNfZm5f
ZXhpdCBTVEFUVVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0KKyMgRXhpdCB0aGUgc2hlbGwgd2l0aCBT
VEFUVVMsIGV2ZW4gaW4gYSAidHJhcCAwIiBvciAic2V0IC1lIiBjb250ZXh0LgorYXNfZm5fZXhp
dCAoKQoreworICBzZXQgK2UKKyAgYXNfZm5fc2V0X3N0YXR1cyAkMQorICBleGl0ICQxCit9ICMg
YXNfZm5fZXhpdAorCisjIGFzX2ZuX3Vuc2V0IFZBUgorIyAtLS0tLS0tLS0tLS0tLS0KKyMgUG9y
dGFibHkgdW5zZXQgVkFSLgorYXNfZm5fdW5zZXQgKCkKK3sKKyAgeyBldmFsICQxPTsgdW5zZXQg
JDE7fQorfQorYXNfdW5zZXQ9YXNfZm5fdW5zZXQKKyMgYXNfZm5fYXBwZW5kIFZBUiBWQUxVRQor
IyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIEFwcGVuZCB0aGUgdGV4dCBpbiBWQUxVRSB0byB0
aGUgZW5kIG9mIHRoZSBkZWZpbml0aW9uIGNvbnRhaW5lZCBpbiBWQVIuIFRha2UKKyMgYWR2YW50
YWdlIG9mIGFueSBzaGVsbCBvcHRpbWl6YXRpb25zIHRoYXQgYWxsb3cgYW1vcnRpemVkIGxpbmVh
ciBncm93dGggb3ZlcgorIyByZXBlYXRlZCBhcHBlbmRzLCBpbnN0ZWFkIG9mIHRoZSB0eXBpY2Fs
IHF1YWRyYXRpYyBncm93dGggcHJlc2VudCBpbiBuYWl2ZQorIyBpbXBsZW1lbnRhdGlvbnMuCitp
ZiAoZXZhbCAiYXNfdmFyPTE7IGFzX3Zhcis9MjsgdGVzdCB4XCRhc192YXIgPSB4MTIiKSAyPi9k
ZXYvbnVsbDsgdGhlbiA6CisgIGV2YWwgJ2FzX2ZuX2FwcGVuZCAoKQorICB7CisgICAgZXZhbCAk
MSs9XCQyCisgIH0nCitlbHNlCisgIGFzX2ZuX2FwcGVuZCAoKQorICB7CisgICAgZXZhbCAkMT1c
JCQxXCQyCisgIH0KK2ZpICMgYXNfZm5fYXBwZW5kCisKKyMgYXNfZm5fYXJpdGggQVJHLi4uCisj
IC0tLS0tLS0tLS0tLS0tLS0tLQorIyBQZXJmb3JtIGFyaXRobWV0aWMgZXZhbHVhdGlvbiBvbiB0
aGUgQVJHcywgYW5kIHN0b3JlIHRoZSByZXN1bHQgaW4gdGhlCisjIGdsb2JhbCAkYXNfdmFsLiBU
YWtlIGFkdmFudGFnZSBvZiBzaGVsbHMgdGhhdCBjYW4gYXZvaWQgZm9ya3MuIFRoZSBhcmd1bWVu
dHMKKyMgbXVzdCBiZSBwb3J0YWJsZSBhY3Jvc3MgJCgoKSkgYW5kIGV4cHIuCitpZiAoZXZhbCAi
dGVzdCBcJCgoIDEgKyAxICkpID0gMiIpIDI+L2Rldi9udWxsOyB0aGVuIDoKKyAgZXZhbCAnYXNf
Zm5fYXJpdGggKCkKKyAgeworICAgIGFzX3ZhbD0kKCggJCogKSkKKyAgfScKK2Vsc2UKKyAgYXNf
Zm5fYXJpdGggKCkKKyAgeworICAgIGFzX3ZhbD1gZXhwciAiJEAiIHx8IHRlc3QgJD8gLWVxIDFg
CisgIH0KK2ZpICMgYXNfZm5fYXJpdGgKKworCitpZiBleHByIGEgOiAnXChhXCknID4vZGV2L251
bGwgMj4mMSAmJgorICAgdGVzdCAiWGBleHByIDAwMDAxIDogJy4qXCguLi5cKSdgIiA9IFgwMDE7
IHRoZW4KKyAgYXNfZXhwcj1leHByCitlbHNlCisgIGFzX2V4cHI9ZmFsc2UKK2ZpCisKK2lmIChi
YXNlbmFtZSAtLSAvKSA+L2Rldi9udWxsIDI+JjEgJiYgdGVzdCAiWGBiYXNlbmFtZSAtLSAvIDI+
JjFgIiA9ICJYLyI7IHRoZW4KKyAgYXNfYmFzZW5hbWU9YmFzZW5hbWUKK2Vsc2UKKyAgYXNfYmFz
ZW5hbWU9ZmFsc2UKK2ZpCisKK2lmIChhc19kaXI9YGRpcm5hbWUgLS0gL2AgJiYgdGVzdCAiWCRh
c19kaXIiID0gWC8pID4vZGV2L251bGwgMj4mMTsgdGhlbgorICBhc19kaXJuYW1lPWRpcm5hbWUK
K2Vsc2UKKyAgYXNfZGlybmFtZT1mYWxzZQorZmkKKworYXNfbWU9YCRhc19iYXNlbmFtZSAtLSAi
JDAiIHx8CiskYXNfZXhwciBYLyIkMCIgOiAnLiovXChbXi9dW14vXSpcKS8qJCcgXHwgXAorCSBY
IiQwIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiQwIiA6ICdYXCgvXCknIFx8IC4gMj4vZGV2L251
bGwgfHwKKyRhc19lY2hvIFgvIiQwIiB8CisgICAgc2VkICcvXi4qXC9cKFteL11bXi9dKlwpXC8q
JC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cL1wpJC97CisJICAg
IHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cKS4qL3sKKwkgICAgcy8vXDEvCisJ
ICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorCisjIEF2b2lkIGRlcGVuZGluZyB1cG9uIENo
YXJhY3RlciBSYW5nZXMuCithc19jcl9sZXR0ZXJzPSdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5
eicKK2FzX2NyX0xFVFRFUlM9J0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJworYXNfY3JfTGV0
dGVycz0kYXNfY3JfbGV0dGVycyRhc19jcl9MRVRURVJTCithc19jcl9kaWdpdHM9JzAxMjM0NTY3
ODknCithc19jcl9hbG51bT0kYXNfY3JfTGV0dGVycyRhc19jcl9kaWdpdHMKKworRUNIT19DPSBF
Q0hPX049IEVDSE9fVD0KK2Nhc2UgYGVjaG8gLW4geGAgaW4gIygoKCgoCistbiopCisgIGNhc2Ug
YGVjaG8gJ3h5XGMnYCBpbgorICAqYyopIEVDSE9fVD0nCSc7OwkjIEVDSE9fVCBpcyBzaW5nbGUg
dGFiIGNoYXJhY3Rlci4KKyAgeHkpICBFQ0hPX0M9J1xjJzs7CisgICopICAgZWNobyBgZWNobyBr
c2g4OCBidWcgb24gQUlYIDYuMWAgPiAvZGV2L251bGwKKyAgICAgICBFQ0hPX1Q9JwknOzsKKyAg
ZXNhYzs7CisqKQorICBFQ0hPX049Jy1uJzs7Citlc2FjCisKK3JtIC1mIGNvbmYkJCBjb25mJCQu
ZXhlIGNvbmYkJC5maWxlCitpZiB0ZXN0IC1kIGNvbmYkJC5kaXI7IHRoZW4KKyAgcm0gLWYgY29u
ZiQkLmRpci9jb25mJCQuZmlsZQorZWxzZQorICBybSAtZiBjb25mJCQuZGlyCisgIG1rZGlyIGNv
bmYkJC5kaXIgMj4vZGV2L251bGwKK2ZpCitpZiAoZWNobyA+Y29uZiQkLmZpbGUpIDI+L2Rldi9u
dWxsOyB0aGVuCisgIGlmIGxuIC1zIGNvbmYkJC5maWxlIGNvbmYkJCAyPi9kZXYvbnVsbDsgdGhl
bgorICAgIGFzX2xuX3M9J2xuIC1zJworICAgICMgLi4uIGJ1dCB0aGVyZSBhcmUgdHdvIGdvdGNo
YXM6CisgICAgIyAxKSBPbiBNU1lTLCBib3RoIGBsbiAtcyBmaWxlIGRpcicgYW5kIGBsbiBmaWxl
IGRpcicgZmFpbC4KKyAgICAjIDIpIERKR1BQIDwgMi4wNCBoYXMgbm8gc3ltbGlua3M7IGBsbiAt
cycgY3JlYXRlcyBhIHdyYXBwZXIgZXhlY3V0YWJsZS4KKyAgICAjIEluIGJvdGggY2FzZXMsIHdl
IGhhdmUgdG8gZGVmYXVsdCB0byBgY3AgLXAnLgorICAgIGxuIC1zIGNvbmYkJC5maWxlIGNvbmYk
JC5kaXIgMj4vZGV2L251bGwgJiYgdGVzdCAhIC1mIGNvbmYkJC5leGUgfHwKKyAgICAgIGFzX2xu
X3M9J2NwIC1wJworICBlbGlmIGxuIGNvbmYkJC5maWxlIGNvbmYkJCAyPi9kZXYvbnVsbDsgdGhl
bgorICAgIGFzX2xuX3M9bG4KKyAgZWxzZQorICAgIGFzX2xuX3M9J2NwIC1wJworICBmaQorZWxz
ZQorICBhc19sbl9zPSdjcCAtcCcKK2ZpCitybSAtZiBjb25mJCQgY29uZiQkLmV4ZSBjb25mJCQu
ZGlyL2NvbmYkJC5maWxlIGNvbmYkJC5maWxlCitybWRpciBjb25mJCQuZGlyIDI+L2Rldi9udWxs
CisKKworIyBhc19mbl9ta2Rpcl9wCisjIC0tLS0tLS0tLS0tLS0KKyMgQ3JlYXRlICIkYXNfZGly
IiBhcyBhIGRpcmVjdG9yeSwgaW5jbHVkaW5nIHBhcmVudHMgaWYgbmVjZXNzYXJ5LgorYXNfZm5f
bWtkaXJfcCAoKQoreworCisgIGNhc2UgJGFzX2RpciBpbiAjKAorICAtKikgYXNfZGlyPS4vJGFz
X2Rpcjs7CisgIGVzYWMKKyAgdGVzdCAtZCAiJGFzX2RpciIgfHwgZXZhbCAkYXNfbWtkaXJfcCB8
fCB7CisgICAgYXNfZGlycz0KKyAgICB3aGlsZSA6OyBkbworICAgICAgY2FzZSAkYXNfZGlyIGlu
ICMoCisgICAgICAqXCcqKSBhc19xZGlyPWAkYXNfZWNobyAiJGFzX2RpciIgfCBzZWQgInMvJy8n
XFxcXFxcXFwnJy9nImA7OyAjJygKKyAgICAgICopIGFzX3FkaXI9JGFzX2Rpcjs7CisgICAgICBl
c2FjCisgICAgICBhc19kaXJzPSInJGFzX3FkaXInICRhc19kaXJzIgorICAgICAgYXNfZGlyPWAk
YXNfZGlybmFtZSAtLSAiJGFzX2RpciIgfHwKKyRhc19leHByIFgiJGFzX2RpciIgOiAnWFwoLipb
Xi9dXCkvLypbXi9dW14vXSovKiQnIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpW14vXScg
XHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJGFzX2RpciIgOiAnWFwo
L1wpJyBcfCAuIDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYIiRhc19kaXIiIHwKKyAgICBzZWQg
Jy9eWFwoLipbXi9dXClcL1wvKlteL11bXi9dKlwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQor
CSAgfQorCSAgL15YXChcL1wvXClbXi9dLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQor
CSAgL15YXChcL1wvXCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9c
KS4qL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorICAgICAg
dGVzdCAtZCAiJGFzX2RpciIgJiYgYnJlYWsKKyAgICBkb25lCisgICAgdGVzdCAteiAiJGFzX2Rp
cnMiIHx8IGV2YWwgIm1rZGlyICRhc19kaXJzIgorICB9IHx8IHRlc3QgLWQgIiRhc19kaXIiIHx8
IGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY3JlYXRlIGRpcmVjdG9yeSAkYXNfZGlyIgorCisKK30g
IyBhc19mbl9ta2Rpcl9wCitpZiBta2RpciAtcCAuIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX21r
ZGlyX3A9J21rZGlyIC1wICIkYXNfZGlyIicKK2Vsc2UKKyAgdGVzdCAtZCAuLy1wICYmIHJtZGly
IC4vLXAKKyAgYXNfbWtkaXJfcD1mYWxzZQorZmkKKworaWYgdGVzdCAteCAvID4vZGV2L251bGwg
Mj4mMTsgdGhlbgorICBhc190ZXN0X3g9J3Rlc3QgLXgnCitlbHNlCisgIGlmIGxzIC1kTCAvID4v
ZGV2L251bGwgMj4mMTsgdGhlbgorICAgIGFzX2xzX0xfb3B0aW9uPUwKKyAgZWxzZQorICAgIGFz
X2xzX0xfb3B0aW9uPQorICBmaQorICBhc190ZXN0X3g9JworICAgIGV2YWwgc2ggLWMgJ1wnJwor
ICAgICAgaWYgdGVzdCAtZCAiJDEiOyB0aGVuCisJdGVzdCAtZCAiJDEvLiI7CisgICAgICBlbHNl
CisJY2FzZSAkMSBpbiAjKAorCS0qKXNldCAiLi8kMSI7OworCWVzYWM7CisJY2FzZSBgbHMgLWxk
JyRhc19sc19MX29wdGlvbicgIiQxIiAyPi9kZXYvbnVsbGAgaW4gIygoCisJPz8/W3N4XSopOjs7
KilmYWxzZTs7ZXNhYztmaQorICAgICdcJycgc2gKKyAgJworZmkKK2FzX2V4ZWN1dGFibGVfcD0k
YXNfdGVzdF94CisKKyMgU2VkIGV4cHJlc3Npb24gdG8gbWFwIGEgc3RyaW5nIG9udG8gYSB2YWxp
ZCBDUFAgbmFtZS4KK2FzX3RyX2NwcD0iZXZhbCBzZWQgJ3klKiRhc19jcl9sZXR0ZXJzJVAkYXNf
Y3JfTEVUVEVSUyU7cyVbXl8kYXNfY3JfYWxudW1dJV8lZyciCisKKyMgU2VkIGV4cHJlc3Npb24g
dG8gbWFwIGEgc3RyaW5nIG9udG8gYSB2YWxpZCB2YXJpYWJsZSBuYW1lLgorYXNfdHJfc2g9ImV2
YWwgc2VkICd5JSorJXBwJTtzJVteXyRhc19jcl9hbG51bV0lXyVnJyIKKworCitleGVjIDY+JjEK
KyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBNYWluIGJvZHkg
b2YgJENPTkZJR19TVEFUVVMgc2NyaXB0LiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gIyMKK19BU0VPRgordGVzdCAkYXNfd3JpdGVfZmFpbCA9IDAgJiYgY2htb2Qg
K3ggJENPTkZJR19TVEFUVVMgfHwgYWNfd3JpdGVfZmFpbD0xCisKK2NhdCA+PiRDT05GSUdfU1RB
VFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyMgU2F2ZSB0aGUgbG9nIG1lc3NhZ2Us
IHRvIGtlZXAgJDAgYW5kIHNvIG9uIG1lYW5pbmdmdWwsIGFuZCB0bworIyByZXBvcnQgYWN0dWFs
IGlucHV0IHZhbHVlcyBvZiBDT05GSUdfRklMRVMgZXRjLiBpbnN0ZWFkIG9mIHRoZWlyCisjIHZh
bHVlcyBhZnRlciBvcHRpb25zIGhhbmRsaW5nLgorYWNfbG9nPSIKK1RoaXMgZmlsZSB3YXMgZXh0
ZW5kZWQgYnkgWGVuIEh5cGVydmlzb3IgJGFzX21lIDQuMiwgd2hpY2ggd2FzCitnZW5lcmF0ZWQg
YnkgR05VIEF1dG9jb25mIDIuNjguICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKKworICBD
T05GSUdfRklMRVMgICAgPSAkQ09ORklHX0ZJTEVTCisgIENPTkZJR19IRUFERVJTICA9ICRDT05G
SUdfSEVBREVSUworICBDT05GSUdfTElOS1MgICAgPSAkQ09ORklHX0xJTktTCisgIENPTkZJR19D
T01NQU5EUyA9ICRDT05GSUdfQ09NTUFORFMKKyAgJCAkMCAkQAorCitvbiBgKGhvc3RuYW1lIHx8
IHVuYW1lIC1uKSAyPi9kZXYvbnVsbCB8IHNlZCAxcWAKKyIKKworX0FDRU9GCisKK2Nhc2UgJGFj
X2NvbmZpZ19maWxlcyBpbiAqIgorIiopIHNldCB4ICRhY19jb25maWdfZmlsZXM7IHNoaWZ0OyBh
Y19jb25maWdfZmlsZXM9JCo7OworZXNhYworCitjYXNlICRhY19jb25maWdfaGVhZGVycyBpbiAq
IgorIiopIHNldCB4ICRhY19jb25maWdfaGVhZGVyczsgc2hpZnQ7IGFjX2NvbmZpZ19oZWFkZXJz
PSQqOzsKK2VzYWMKKworCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0
ZV9mYWlsPTEKKyMgRmlsZXMgdGhhdCBjb25maWcuc3RhdHVzIHdhcyBtYWRlIGZvci4KK2NvbmZp
Z19maWxlcz0iJGFjX2NvbmZpZ19maWxlcyIKK2NvbmZpZ19oZWFkZXJzPSIkYWNfY29uZmlnX2hl
YWRlcnMiCisKK19BQ0VPRgorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNf
d3JpdGVfZmFpbD0xCithY19jc191c2FnZT0iXAorXGAkYXNfbWUnIGluc3RhbnRpYXRlcyBmaWxl
cyBhbmQgb3RoZXIgY29uZmlndXJhdGlvbiBhY3Rpb25zCitmcm9tIHRlbXBsYXRlcyBhY2NvcmRp
bmcgdG8gdGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbi4gIFVubGVzcyB0aGUgZmlsZXMKK2FuZCBh
Y3Rpb25zIGFyZSBzcGVjaWZpZWQgYXMgVEFHcywgYWxsIGFyZSBpbnN0YW50aWF0ZWQgYnkgZGVm
YXVsdC4KKworVXNhZ2U6ICQwIFtPUFRJT05dLi4uIFtUQUddLi4uCisKKyAgLWgsIC0taGVscCAg
ICAgICBwcmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtViwgLS12ZXJzaW9uICAgIHByaW50
IHZlcnNpb24gbnVtYmVyIGFuZCBjb25maWd1cmF0aW9uIHNldHRpbmdzLCB0aGVuIGV4aXQKKyAg
ICAgIC0tY29uZmlnICAgICBwcmludCBjb25maWd1cmF0aW9uLCB0aGVuIGV4aXQKKyAgLXEsIC0t
cXVpZXQsIC0tc2lsZW50CisgICAgICAgICAgICAgICAgICAgZG8gbm90IHByaW50IHByb2dyZXNz
IG1lc3NhZ2VzCisgIC1kLCAtLWRlYnVnICAgICAgZG9uJ3QgcmVtb3ZlIHRlbXBvcmFyeSBmaWxl
cworICAgICAgLS1yZWNoZWNrICAgIHVwZGF0ZSAkYXNfbWUgYnkgcmVjb25maWd1cmluZyBpbiB0
aGUgc2FtZSBjb25kaXRpb25zCisgICAgICAtLWZpbGU9RklMRVs6VEVNUExBVEVdCisgICAgICAg
ICAgICAgICAgICAgaW5zdGFudGlhdGUgdGhlIGNvbmZpZ3VyYXRpb24gZmlsZSBGSUxFCisgICAg
ICAtLWhlYWRlcj1GSUxFWzpURU1QTEFURV0KKyAgICAgICAgICAgICAgICAgICBpbnN0YW50aWF0
ZSB0aGUgY29uZmlndXJhdGlvbiBoZWFkZXIgRklMRQorCitDb25maWd1cmF0aW9uIGZpbGVzOgor
JGNvbmZpZ19maWxlcworCitDb25maWd1cmF0aW9uIGhlYWRlcnM6CiskY29uZmlnX2hlYWRlcnMK
KworUmVwb3J0IGJ1Z3MgdG8gPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tPi4iCisKK19B
Q0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCith
Y19jc19jb25maWc9ImAkYXNfZWNobyAiJGFjX2NvbmZpZ3VyZV9hcmdzIiB8IHNlZCAncy9eIC8v
OyBzL1tcXCIiXGBcJF0vXFxcXCYvZydgIgorYWNfY3NfdmVyc2lvbj0iXFwKK1hlbiBIeXBlcnZp
c29yIGNvbmZpZy5zdGF0dXMgNC4yCitjb25maWd1cmVkIGJ5ICQwLCBnZW5lcmF0ZWQgYnkgR05V
IEF1dG9jb25mIDIuNjgsCisgIHdpdGggb3B0aW9ucyBcXCJcJGFjX2NzX2NvbmZpZ1xcIgorCitD
b3B5cmlnaHQgKEMpIDIwMTAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCitUaGlzIGNv
bmZpZy5zdGF0dXMgc2NyaXB0IGlzIGZyZWUgc29mdHdhcmU7IHRoZSBGcmVlIFNvZnR3YXJlIEZv
dW5kYXRpb24KK2dpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9uIHRvIGNvcHksIGRpc3RyaWJ1dGUg
YW5kIG1vZGlmeSBpdC4iCisKK2FjX3B3ZD0nJGFjX3B3ZCcKK3NyY2Rpcj0nJHNyY2RpcicKK0lO
U1RBTEw9JyRJTlNUQUxMJwordGVzdCAtbiAiXCRBV0siIHx8IEFXSz1hd2sKK19BQ0VPRgorCitj
YXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisjIFRoZSBk
ZWZhdWx0IGxpc3RzIGFwcGx5IGlmIHRoZSB1c2VyIGRvZXMgbm90IHNwZWNpZnkgYW55IGZpbGUu
CithY19uZWVkX2RlZmF1bHRzPToKK3doaWxlIHRlc3QgJCMgIT0gMAorZG8KKyAgY2FzZSAkMSBp
bgorICAtLSo9PyopCisgICAgYWNfb3B0aW9uPWBleHByICJYJDEiIDogJ1hcKFtePV0qXCk9J2AK
KyAgICBhY19vcHRhcmc9YGV4cHIgIlgkMSIgOiAnWFtePV0qPVwoLipcKSdgCisgICAgYWNfc2hp
ZnQ9OgorICAgIDs7CisgIC0tKj0pCisgICAgYWNfb3B0aW9uPWBleHByICJYJDEiIDogJ1hcKFte
PV0qXCk9J2AKKyAgICBhY19vcHRhcmc9CisgICAgYWNfc2hpZnQ9OgorICAgIDs7CisgICopCisg
ICAgYWNfb3B0aW9uPSQxCisgICAgYWNfb3B0YXJnPSQyCisgICAgYWNfc2hpZnQ9c2hpZnQKKyAg
ICA7OworICBlc2FjCisKKyAgY2FzZSAkYWNfb3B0aW9uIGluCisgICMgSGFuZGxpbmcgb2YgdGhl
IG9wdGlvbnMuCisgIC1yZWNoZWNrIHwgLS1yZWNoZWNrIHwgLS1yZWNoZWMgfCAtLXJlY2hlIHwg
LS1yZWNoIHwgLS1yZWMgfCAtLXJlIHwgLS1yKQorICAgIGFjX2NzX3JlY2hlY2s9OiA7OworICAt
LXZlcnNpb24gfCAtLXZlcnNpbyB8IC0tdmVyc2kgfCAtLXZlcnMgfCAtLXZlciB8IC0tdmUgfCAt
LXYgfCAtViApCisgICAgJGFzX2VjaG8gIiRhY19jc192ZXJzaW9uIjsgZXhpdCA7OworICAtLWNv
bmZpZyB8IC0tY29uZmkgfCAtLWNvbmYgfCAtLWNvbiB8IC0tY28gfCAtLWMgKQorICAgICRhc19l
Y2hvICIkYWNfY3NfY29uZmlnIjsgZXhpdCA7OworICAtLWRlYnVnIHwgLS1kZWJ1IHwgLS1kZWIg
fCAtLWRlIHwgLS1kIHwgLWQgKQorICAgIGRlYnVnPTogOzsKKyAgLS1maWxlIHwgLS1maWwgfCAt
LWZpIHwgLS1mICkKKyAgICAkYWNfc2hpZnQKKyAgICBjYXNlICRhY19vcHRhcmcgaW4KKyAgICAq
XCcqKSBhY19vcHRhcmc9YCRhc19lY2hvICIkYWNfb3B0YXJnIiB8IHNlZCAicy8nLydcXFxcXFxc
XCcnL2ciYCA7OworICAgICcnKSBhc19mbl9lcnJvciAkPyAibWlzc2luZyBmaWxlIGFyZ3VtZW50
IiA7OworICAgIGVzYWMKKyAgICBhc19mbl9hcHBlbmQgQ09ORklHX0ZJTEVTICIgJyRhY19vcHRh
cmcnIgorICAgIGFjX25lZWRfZGVmYXVsdHM9ZmFsc2U7OworICAtLWhlYWRlciB8IC0taGVhZGUg
fCAtLWhlYWQgfCAtLWhlYSApCisgICAgJGFjX3NoaWZ0CisgICAgY2FzZSAkYWNfb3B0YXJnIGlu
CisgICAgKlwnKikgYWNfb3B0YXJnPWAkYXNfZWNobyAiJGFjX29wdGFyZyIgfCBzZWQgInMvJy8n
XFxcXFxcXFwnJy9nImAgOzsKKyAgICBlc2FjCisgICAgYXNfZm5fYXBwZW5kIENPTkZJR19IRUFE
RVJTICIgJyRhY19vcHRhcmcnIgorICAgIGFjX25lZWRfZGVmYXVsdHM9ZmFsc2U7OworICAtLWhl
IHwgLS1oKQorICAgICMgQ29uZmxpY3QgYmV0d2VlbiAtLWhlbHAgYW5kIC0taGVhZGVyCisgICAg
YXNfZm5fZXJyb3IgJD8gImFtYmlndW91cyBvcHRpb246IFxgJDEnCitUcnkgXGAkMCAtLWhlbHAn
IGZvciBtb3JlIGluZm9ybWF0aW9uLiI7OworICAtLWhlbHAgfCAtLWhlbCB8IC1oICkKKyAgICAk
YXNfZWNobyAiJGFjX2NzX3VzYWdlIjsgZXhpdCA7OworICAtcSB8IC1xdWlldCB8IC0tcXVpZXQg
fCAtLXF1aWUgfCAtLXF1aSB8IC0tcXUgfCAtLXEgXAorICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8
IC0tc2lsZW4gfCAtLXNpbGUgfCAtLXNpbCB8IC0tc2kgfCAtLXMpCisgICAgYWNfY3Nfc2lsZW50
PTogOzsKKworICAjIFRoaXMgaXMgYW4gZXJyb3IuCisgIC0qKSBhc19mbl9lcnJvciAkPyAidW5y
ZWNvZ25pemVkIG9wdGlvbjogXGAkMScKK1RyeSBcYCQwIC0taGVscCcgZm9yIG1vcmUgaW5mb3Jt
YXRpb24uIiA7OworCisgICopIGFzX2ZuX2FwcGVuZCBhY19jb25maWdfdGFyZ2V0cyAiICQxIgor
ICAgICBhY19uZWVkX2RlZmF1bHRzPWZhbHNlIDs7CisKKyAgZXNhYworICBzaGlmdAorZG9uZQor
CithY19jb25maWd1cmVfZXh0cmFfYXJncz0KKworaWYgJGFjX2NzX3NpbGVudDsgdGhlbgorICBl
eGVjIDY+L2Rldi9udWxsCisgIGFjX2NvbmZpZ3VyZV9leHRyYV9hcmdzPSIkYWNfY29uZmlndXJl
X2V4dHJhX2FyZ3MgLS1zaWxlbnQiCitmaQorCitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVT
IDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQoraWYgXCRhY19jc19yZWNoZWNrOyB0aGVuCisg
IHNldCBYICckU0hFTEwnICckMCcgJGFjX2NvbmZpZ3VyZV9hcmdzIFwkYWNfY29uZmlndXJlX2V4
dHJhX2FyZ3MgLS1uby1jcmVhdGUgLS1uby1yZWN1cnNpb24KKyAgc2hpZnQKKyAgXCRhc19lY2hv
ICJydW5uaW5nIENPTkZJR19TSEVMTD0kU0hFTEwgXCQqIiA+JjYKKyAgQ09ORklHX1NIRUxMPSck
U0hFTEwnCisgIGV4cG9ydCBDT05GSUdfU0hFTEwKKyAgZXhlYyAiXCRAIgorZmkKKworX0FDRU9G
CitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitleGVj
IDU+PmNvbmZpZy5sb2cKK3sKKyAgZWNobworICBzZWQgJ2g7cy8uLy0vZztzL14uLi4vIyMgLztz
Ly4uLiQvICMjLztwO3g7cDt4JyA8PF9BU0JPWAorIyMgUnVubmluZyAkYXNfbWUuICMjCitfQVNC
T1gKKyAgJGFzX2VjaG8gIiRhY19sb2ciCit9ID4mNQorCitfQUNFT0YKK2NhdCA+PiRDT05GSUdf
U1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorX0FDRU9GCisKK2NhdCA+PiRDT05G
SUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKworIyBIYW5kbGluZyBvZiBh
cmd1bWVudHMuCitmb3IgYWNfY29uZmlnX3RhcmdldCBpbiAkYWNfY29uZmlnX3RhcmdldHMKK2Rv
CisgIGNhc2UgJGFjX2NvbmZpZ190YXJnZXQgaW4KKyAgICAiLi4vY29uZmlnL1Rvb2xzLm1rIikg
Q09ORklHX0ZJTEVTPSIkQ09ORklHX0ZJTEVTIC4uL2NvbmZpZy9Ub29scy5tayIgOzsKKyAgICAi
Y29uZmlnLmgiKSBDT05GSUdfSEVBREVSUz0iJENPTkZJR19IRUFERVJTIGNvbmZpZy5oIiA7Owor
CisgICopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGFyZ3VtZW50OiBcYCRhY19jb25maWdfdGFy
Z2V0JyIgIiRMSU5FTk8iIDU7OworICBlc2FjCitkb25lCisKKworIyBJZiB0aGUgdXNlciBkaWQg
bm90IHVzZSB0aGUgYXJndW1lbnRzIHRvIHNwZWNpZnkgdGhlIGl0ZW1zIHRvIGluc3RhbnRpYXRl
LAorIyB0aGVuIHRoZSBlbnZ2YXIgaW50ZXJmYWNlIGlzIHVzZWQuICBTZXQgb25seSB0aG9zZSB0
aGF0IGFyZSBub3QuCisjIFdlIHVzZSB0aGUgbG9uZyBmb3JtIGZvciB0aGUgZGVmYXVsdCBhc3Np
Z25tZW50IGJlY2F1c2Ugb2YgYW4gZXh0cmVtZWx5CisjIGJpemFycmUgYnVnIG9uIFN1bk9TIDQu
MS4zLgoraWYgJGFjX25lZWRfZGVmYXVsdHM7IHRoZW4KKyAgdGVzdCAiJHtDT05GSUdfRklMRVMr
c2V0fSIgPSBzZXQgfHwgQ09ORklHX0ZJTEVTPSRjb25maWdfZmlsZXMKKyAgdGVzdCAiJHtDT05G
SUdfSEVBREVSUytzZXR9IiA9IHNldCB8fCBDT05GSUdfSEVBREVSUz0kY29uZmlnX2hlYWRlcnMK
K2ZpCisKKyMgSGF2ZSBhIHRlbXBvcmFyeSBkaXJlY3RvcnkgZm9yIGNvbnZlbmllbmNlLiAgTWFr
ZSBpdCBpbiB0aGUgYnVpbGQgdHJlZQorIyBzaW1wbHkgYmVjYXVzZSB0aGVyZSBpcyBubyByZWFz
b24gYWdhaW5zdCBoYXZpbmcgaXQgaGVyZSwgYW5kIGluIGFkZGl0aW9uLAorIyBjcmVhdGluZyBh
bmQgbW92aW5nIGZpbGVzIGZyb20gL3RtcCBjYW4gc29tZXRpbWVzIGNhdXNlIHByb2JsZW1zLgor
IyBIb29rIGZvciBpdHMgcmVtb3ZhbCB1bmxlc3MgZGVidWdnaW5nLgorIyBOb3RlIHRoYXQgdGhl
cmUgaXMgYSBzbWFsbCB3aW5kb3cgaW4gd2hpY2ggdGhlIGRpcmVjdG9yeSB3aWxsIG5vdCBiZSBj
bGVhbmVkOgorIyBhZnRlciBpdHMgY3JlYXRpb24gYnV0IGJlZm9yZSBpdHMgbmFtZSBoYXMgYmVl
biBhc3NpZ25lZCB0byBgJHRtcCcuCiskZGVidWcgfHwKK3sKKyAgdG1wPSBhY190bXA9CisgIHRy
YXAgJ2V4aXRfc3RhdHVzPSQ/CisgIDogIiR7YWNfdG1wOj0kdG1wfSIKKyAgeyB0ZXN0ICEgLWQg
IiRhY190bXAiIHx8IHJtIC1mciAiJGFjX3RtcCI7IH0gJiYgZXhpdCAkZXhpdF9zdGF0dXMKKycg
MAorICB0cmFwICdhc19mbl9leGl0IDEnIDEgMiAxMyAxNQorfQorIyBDcmVhdGUgYSAoc2VjdXJl
KSB0bXAgZGlyZWN0b3J5IGZvciB0bXAgZmlsZXMuCisKK3sKKyAgdG1wPWAodW1hc2sgMDc3ICYm
IG1rdGVtcCAtZCAiLi9jb25mWFhYWFhYIikgMj4vZGV2L251bGxgICYmCisgIHRlc3QgLWQgIiR0
bXAiCit9ICB8fAoreworICB0bXA9Li9jb25mJCQtJFJBTkRPTQorICAodW1hc2sgMDc3ICYmIG1r
ZGlyICIkdG1wIikKK30gfHwgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBjcmVhdGUgYSB0ZW1wb3Jh
cnkgZGlyZWN0b3J5IGluIC4iICIkTElORU5PIiA1CithY190bXA9JHRtcAorCisjIFNldCB1cCB0
aGUgc2NyaXB0cyBmb3IgQ09ORklHX0ZJTEVTIHNlY3Rpb24uCisjIE5vIG5lZWQgdG8gZ2VuZXJh
dGUgdGhlbSBpZiB0aGVyZSBhcmUgbm8gQ09ORklHX0ZJTEVTLgorIyBUaGlzIGhhcHBlbnMgZm9y
IGluc3RhbmNlIHdpdGggYC4vY29uZmlnLnN0YXR1cyBjb25maWcuaCcuCitpZiB0ZXN0IC1uICIk
Q09ORklHX0ZJTEVTIjsgdGhlbgorCisKK2FjX2NyPWBlY2hvIFggfCB0ciBYICdcMDE1J2AKKyMg
T24gY3lnd2luLCBiYXNoIGNhbiBlYXQgXHIgaW5zaWRlIGBgIGlmIHRoZSB1c2VyIHJlcXVlc3Rl
ZCBpZ25jci4KKyMgQnV0IHdlIGtub3cgb2Ygbm8gb3RoZXIgc2hlbGwgd2hlcmUgYWNfY3Igd291
bGQgYmUgZW1wdHkgYXQgdGhpcworIyBwb2ludCwgc28gd2UgY2FuIHVzZSBhIGJhc2hpc20gYXMg
YSBmYWxsYmFjay4KK2lmIHRlc3QgIngkYWNfY3IiID0geDsgdGhlbgorICBldmFsIGFjX2NyPVwk
XCdcXHJcJworZmkKK2FjX2NzX2F3a19jcj1gJEFXSyAnQkVHSU4geyBwcmludCAiYVxyYiIgfScg
PC9kZXYvbnVsbCAyPi9kZXYvbnVsbGAKK2lmIHRlc3QgIiRhY19jc19hd2tfY3IiID0gImEke2Fj
X2NyfWIiOyB0aGVuCisgIGFjX2NzX2F3a19jcj0nXFxyJworZWxzZQorICBhY19jc19hd2tfY3I9
JGFjX2NyCitmaQorCitlY2hvICdCRUdJTiB7JyA+IiRhY190bXAvc3ViczEuYXdrIiAmJgorX0FD
RU9GCisKKworeworICBlY2hvICJjYXQgPmNvbmYkJHN1YnMuYXdrIDw8X0FDRU9GIiAmJgorICBl
Y2hvICIkYWNfc3Vic3RfdmFycyIgfCBzZWQgJ3MvLiovJiEkJiRhY19kZWxpbS8nICYmCisgIGVj
aG8gIl9BQ0VPRiIKK30gPmNvbmYkJHN1YnMuc2ggfHwKKyAgYXNfZm5fZXJyb3IgJD8gImNvdWxk
IG5vdCBtYWtlICRDT05GSUdfU1RBVFVTIiAiJExJTkVOTyIgNQorYWNfZGVsaW1fbnVtPWBlY2hv
ICIkYWNfc3Vic3RfdmFycyIgfCBncmVwIC1jICdeJ2AKK2FjX2RlbGltPSclIV8hIyAnCitmb3Ig
YWNfbGFzdF90cnkgaW4gZmFsc2UgZmFsc2UgZmFsc2UgZmFsc2UgZmFsc2UgOjsgZG8KKyAgLiAu
L2NvbmYkJHN1YnMuc2ggfHwKKyAgICBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IG1ha2UgJENP
TkZJR19TVEFUVVMiICIkTElORU5PIiA1CisKKyAgYWNfZGVsaW1fbj1gc2VkIC1uICJzLy4qJGFj
X2RlbGltXCQvWC9wIiBjb25mJCRzdWJzLmF3ayB8IGdyZXAgLWMgWGAKKyAgaWYgdGVzdCAkYWNf
ZGVsaW1fbiA9ICRhY19kZWxpbV9udW07IHRoZW4KKyAgICBicmVhaworICBlbGlmICRhY19sYXN0
X3RyeTsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgbWFrZSAkQ09ORklHX1NU
QVRVUyIgIiRMSU5FTk8iIDUKKyAgZWxzZQorICAgIGFjX2RlbGltPSIkYWNfZGVsaW0hJGFjX2Rl
bGltIF8kYWNfZGVsaW0hISAiCisgIGZpCitkb25lCitybSAtZiBjb25mJCRzdWJzLnNoCisKK2Nh
dCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorY2F0ID4+Ilwk
YWNfdG1wL3N1YnMxLmF3ayIgPDxcXF9BQ0FXSyAmJgorX0FDRU9GCitzZWQgLW4gJworaAorcy9e
L1NbIi87IHMvIS4qLyJdPS8KK3AKK2cKK3MvXlteIV0qIS8vCis6cmVwbAordCByZXBsCitzLyci
JGFjX2RlbGltIickLy8KK3QgZGVsaW0KKzpubAoraAorcy9cKC5cezE0OFx9XCkuLiovXDEvCit0
IG1vcmUxCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC9cXG4iXFwvCitwCituCitiIHJlcGwK
Kzptb3JlMQorcy9bIlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvIlxcLworcAorZworcy8uXHsxNDhc
fS8vCit0IG5sCis6ZGVsaW0KK2gKK3MvXCguXHsxNDhcfVwpLi4qL1wxLwordCBtb3JlMgorcy9b
IlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvIi8KK3AKK2IKKzptb3JlMgorcy9bIlxcXS9cXCYvZzsg
cy9eLyIvOyBzLyQvIlxcLworcAorZworcy8uXHsxNDhcfS8vCit0IGRlbGltCisnIDxjb25mJCRz
dWJzLmF3ayB8IHNlZCAnCisvXlteIiJdL3sKKyAgTgorICBzL1xuLy8KK30KKycgPj4kQ09ORklH
X1NUQVRVUyB8fCBhY193cml0ZV9mYWlsPTEKK3JtIC1mIGNvbmYkJHN1YnMuYXdrCitjYXQgPj4k
Q09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK19BQ0FXSworY2F0ID4+
IlwkYWNfdG1wL3N1YnMxLmF3ayIgPDxfQUNBV0sgJiYKKyAgZm9yIChrZXkgaW4gUykgU19pc19z
ZXRba2V5XSA9IDEKKyAgRlMgPSAiByIKKworfQoreworICBsaW5lID0gJCAwCisgIG5maWVsZHMg
PSBzcGxpdChsaW5lLCBmaWVsZCwgIkAiKQorICBzdWJzdGVkID0gMAorICBsZW4gPSBsZW5ndGgo
ZmllbGRbMV0pCisgIGZvciAoaSA9IDI7IGkgPCBuZmllbGRzOyBpKyspIHsKKyAgICBrZXkgPSBm
aWVsZFtpXQorICAgIGtleWxlbiA9IGxlbmd0aChrZXkpCisgICAgaWYgKFNfaXNfc2V0W2tleV0p
IHsKKyAgICAgIHZhbHVlID0gU1trZXldCisgICAgICBsaW5lID0gc3Vic3RyKGxpbmUsIDEsIGxl
bikgIiIgdmFsdWUgIiIgc3Vic3RyKGxpbmUsIGxlbiArIGtleWxlbiArIDMpCisgICAgICBsZW4g
Kz0gbGVuZ3RoKHZhbHVlKSArIGxlbmd0aChmaWVsZFsrK2ldKQorICAgICAgc3Vic3RlZCA9IDEK
KyAgICB9IGVsc2UKKyAgICAgIGxlbiArPSAxICsga2V5bGVuCisgIH0KKworICBwcmludCBsaW5l
Cit9CisKK19BQ0FXSworX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwg
YWNfd3JpdGVfZmFpbD0xCitpZiBzZWQgInMvJGFjX2NyLy8iIDwgL2Rldi9udWxsID4gL2Rldi9u
dWxsIDI+JjE7IHRoZW4KKyAgc2VkICJzLyRhY19jclwkLy87IHMvJGFjX2NyLyRhY19jc19hd2tf
Y3IvZyIKK2Vsc2UKKyAgY2F0CitmaSA8ICIkYWNfdG1wL3N1YnMxLmF3ayIgPiAiJGFjX3RtcC9z
dWJzLmF3ayIgXAorICB8fCBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IHNldHVwIGNvbmZpZyBm
aWxlcyBtYWNoaW5lcnkiICIkTElORU5PIiA1CitfQUNFT0YKKworIyBWUEFUSCBtYXkgY2F1c2Ug
dHJvdWJsZSB3aXRoIHNvbWUgbWFrZXMsIHNvIHdlIHJlbW92ZSBzb2xlICQoc3JjZGlyKSwKKyMg
JHtzcmNkaXJ9IGFuZCBAc3JjZGlyQCBlbnRyaWVzIGZyb20gVlBBVEggaWYgc3JjZGlyIGlzICIu
Iiwgc3RyaXAgbGVhZGluZyBhbmQKKyMgdHJhaWxpbmcgY29sb25zIGFuZCB0aGVuIHJlbW92ZSB0
aGUgd2hvbGUgbGluZSBpZiBWUEFUSCBiZWNvbWVzIGVtcHR5CisjIChhY3R1YWxseSB3ZSBsZWF2
ZSBhbiBlbXB0eSBsaW5lIHRvIHByZXNlcnZlIGxpbmUgbnVtYmVycykuCitpZiB0ZXN0ICJ4JHNy
Y2RpciIgPSB4LjsgdGhlbgorICBhY192cHN1Yj0nL15bCSBdKlZQQVRIWwkgXSo9WwkgXSovewor
aAorcy8vLworcy9eLzovCitzL1sJIF0qJC86Lworcy86XCQoc3JjZGlyKTovOi9nCitzLzpcJHtz
cmNkaXJ9Oi86L2cKK3MvOkBzcmNkaXJAOi86L2cKK3MvXjoqLy8KK3MvOiokLy8KK3gKK3MvXCg9
WwkgXSpcKS4qL1wxLworRworcy9cbi8vCitzL15bXj1dKj1bCSBdKiQvLworfScKK2ZpCisKK2Nh
dCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2ZpICMgdGVz
dCAtbiAiJENPTkZJR19GSUxFUyIKKworIyBTZXQgdXAgdGhlIHNjcmlwdHMgZm9yIENPTkZJR19I
RUFERVJTIHNlY3Rpb24uCisjIE5vIG5lZWQgdG8gZ2VuZXJhdGUgdGhlbSBpZiB0aGVyZSBhcmUg
bm8gQ09ORklHX0hFQURFUlMuCisjIFRoaXMgaGFwcGVucyBmb3IgaW5zdGFuY2Ugd2l0aCBgLi9j
b25maWcuc3RhdHVzIE1ha2VmaWxlJy4KK2lmIHRlc3QgLW4gIiRDT05GSUdfSEVBREVSUyI7IHRo
ZW4KK2NhdCA+IiRhY190bXAvZGVmaW5lcy5hd2siIDw8XF9BQ0FXSyB8fAorQkVHSU4geworX0FD
RU9GCisKKyMgVHJhbnNmb3JtIGNvbmZkZWZzLmggaW50byBhbiBhd2sgc2NyaXB0IGBkZWZpbmVz
LmF3aycsIGVtYmVkZGVkIGFzCisjIGhlcmUtZG9jdW1lbnQgaW4gY29uZmlnLnN0YXR1cywgdGhh
dCBzdWJzdGl0dXRlcyB0aGUgcHJvcGVyIHZhbHVlcyBpbnRvCisjIGNvbmZpZy5oLmluIHRvIHBy
b2R1Y2UgY29uZmlnLmguCisKKyMgQ3JlYXRlIGEgZGVsaW1pdGVyIHN0cmluZyB0aGF0IGRvZXMg
bm90IGV4aXN0IGluIGNvbmZkZWZzLmgsIHRvIGVhc2UKKyMgaGFuZGxpbmcgb2YgbG9uZyBsaW5l
cy4KK2FjX2RlbGltPSclIV8hIyAnCitmb3IgYWNfbGFzdF90cnkgaW4gZmFsc2UgZmFsc2UgOjsg
ZG8KKyAgYWNfdHQ9YHNlZCAtbiAiLyRhY19kZWxpbS9wIiBjb25mZGVmcy5oYAorICBpZiB0ZXN0
IC16ICIkYWNfdHQiOyB0aGVuCisgICAgYnJlYWsKKyAgZWxpZiAkYWNfbGFzdF90cnk7IHRoZW4K
KyAgICBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IG1ha2UgJENPTkZJR19IRUFERVJTIiAiJExJ
TkVOTyIgNQorICBlbHNlCisgICAgYWNfZGVsaW09IiRhY19kZWxpbSEkYWNfZGVsaW0gXyRhY19k
ZWxpbSEhICIKKyAgZmkKK2RvbmUKKworIyBGb3IgdGhlIGF3ayBzY3JpcHQsIEQgaXMgYW4gYXJy
YXkgb2YgbWFjcm8gdmFsdWVzIGtleWVkIGJ5IG5hbWUsCisjIGxpa2V3aXNlIFAgY29udGFpbnMg
bWFjcm8gcGFyYW1ldGVycyBpZiBhbnkuICBQcmVzZXJ2ZSBiYWNrc2xhc2gKKyMgbmV3bGluZSBz
ZXF1ZW5jZXMuCisKK2FjX3dvcmRfcmU9W18kYXNfY3JfTGV0dGVyc11bXyRhc19jcl9hbG51bV0q
CitzZWQgLW4gJworcy8uXHsxNDhcfS8mJyIkYWNfZGVsaW0iJy9nCit0IHJzZXQKKzpyc2V0Citz
L15bCSBdKiNbCSBdKmRlZmluZVsJIF1bCSBdKi8gLwordCBkZWYKK2QKKzpkZWYKK3MvXFwkLy8K
K3QgYnNubAorcy9bIlxcXS9cXCYvZworcy9eIFwoJyIkYWNfd29yZF9yZSInXClcKChbXigpXSop
XClbCSBdKlwoLipcKS9QWyJcMSJdPSJcMiJcCitEWyJcMSJdPSIgXDMiL3AKK3MvXiBcKCciJGFj
X3dvcmRfcmUiJ1wpWwkgXSpcKC4qXCkvRFsiXDEiXT0iIFwyIi9wCitkCis6YnNubAorcy9bIlxc
XS9cXCYvZworcy9eIFwoJyIkYWNfd29yZF9yZSInXClcKChbXigpXSopXClbCSBdKlwoLipcKS9Q
WyJcMSJdPSJcMiJcCitEWyJcMSJdPSIgXDNcXFxcXFxuIlxcL3AKK3QgY29udAorcy9eIFwoJyIk
YWNfd29yZF9yZSInXClbCSBdKlwoLipcKS9EWyJcMSJdPSIgXDJcXFxcXFxuIlxcL3AKK3QgY29u
dAorZAorOmNvbnQKK24KK3MvLlx7MTQ4XH0vJiciJGFjX2RlbGltIicvZwordCBjbGVhcgorOmNs
ZWFyCitzL1xcJC8vCit0IGJzbmxjCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iL3AKK2QK
Kzpic25sYworcy9bIlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvXFxcXFxcbiJcXC9wCitiIGNvbnQK
KycgPGNvbmZkZWZzLmggfCBzZWQgJworcy8nIiRhY19kZWxpbSInLyJcXFwKKyIvZycgPj4kQ09O
RklHX1NUQVRVUyB8fCBhY193cml0ZV9mYWlsPTEKKworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxf
QUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisgIGZvciAoa2V5IGluIEQpIERfaXNfc2V0W2tleV0g
PSAxCisgIEZTID0gIgciCit9CisvXltcdCBdKiNbXHQgXSooZGVmaW5lfHVuZGVmKVtcdCBdKyRh
Y193b3JkX3JlKFtcdCAoXXxcJCkvIHsKKyAgbGluZSA9IFwkIDAKKyAgc3BsaXQobGluZSwgYXJn
LCAiICIpCisgIGlmIChhcmdbMV0gPT0gIiMiKSB7CisgICAgZGVmdW5kZWYgPSBhcmdbMl0KKyAg
ICBtYWMxID0gYXJnWzNdCisgIH0gZWxzZSB7CisgICAgZGVmdW5kZWYgPSBzdWJzdHIoYXJnWzFd
LCAyKQorICAgIG1hYzEgPSBhcmdbMl0KKyAgfQorICBzcGxpdChtYWMxLCBtYWMyLCAiKCIpICMp
CisgIG1hY3JvID0gbWFjMlsxXQorICBwcmVmaXggPSBzdWJzdHIobGluZSwgMSwgaW5kZXgobGlu
ZSwgZGVmdW5kZWYpIC0gMSkKKyAgaWYgKERfaXNfc2V0W21hY3JvXSkgeworICAgICMgUHJlc2Vy
dmUgdGhlIHdoaXRlIHNwYWNlIHN1cnJvdW5kaW5nIHRoZSAiIyIuCisgICAgcHJpbnQgcHJlZml4
ICJkZWZpbmUiLCBtYWNybyBQW21hY3JvXSBEW21hY3JvXQorICAgIG5leHQKKyAgfSBlbHNlIHsK
KyAgICAjIFJlcGxhY2UgI3VuZGVmIHdpdGggY29tbWVudHMuICBUaGlzIGlzIG5lY2Vzc2FyeSwg
Zm9yIGV4YW1wbGUsCisgICAgIyBpbiB0aGUgY2FzZSBvZiBfUE9TSVhfU09VUkNFLCB3aGljaCBp
cyBwcmVkZWZpbmVkIGFuZCByZXF1aXJlZAorICAgICMgb24gc29tZSBzeXN0ZW1zIHdoZXJlIGNv
bmZpZ3VyZSB3aWxsIG5vdCBkZWNpZGUgdG8gZGVmaW5lIGl0LgorICAgIGlmIChkZWZ1bmRlZiA9
PSAidW5kZWYiKSB7CisgICAgICBwcmludCAiLyoiLCBwcmVmaXggZGVmdW5kZWYsIG1hY3JvLCAi
Ki8iCisgICAgICBuZXh0CisgICAgfQorICB9Cit9Cit7IHByaW50IH0KK19BQ0FXSworX0FDRU9G
CitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisgIGFz
X2ZuX2Vycm9yICQ/ICJjb3VsZCBub3Qgc2V0dXAgY29uZmlnIGhlYWRlcnMgbWFjaGluZXJ5IiAi
JExJTkVOTyIgNQorZmkgIyB0ZXN0IC1uICIkQ09ORklHX0hFQURFUlMiCisKKworZXZhbCBzZXQg
WCAiICA6RiAkQ09ORklHX0ZJTEVTICA6SCAkQ09ORklHX0hFQURFUlMgICAgIgorc2hpZnQKK2Zv
ciBhY190YWcKK2RvCisgIGNhc2UgJGFjX3RhZyBpbgorICA6W0ZITENdKSBhY19tb2RlPSRhY190
YWc7IGNvbnRpbnVlOzsKKyAgZXNhYworICBjYXNlICRhY19tb2RlJGFjX3RhZyBpbgorICA6W0ZI
TF0qOiopOzsKKyAgOkwqIHwgOkMqOiopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHRhZyBcYCRh
Y190YWcnIiAiJExJTkVOTyIgNTs7CisgIDpbRkhdLSkgYWNfdGFnPS06LTs7CisgIDpbRkhdKikg
YWNfdGFnPSRhY190YWc6JGFjX3RhZy5pbjs7CisgIGVzYWMKKyAgYWNfc2F2ZV9JRlM9JElGUwor
ICBJRlM9OgorICBzZXQgeCAkYWNfdGFnCisgIElGUz0kYWNfc2F2ZV9JRlMKKyAgc2hpZnQKKyAg
YWNfZmlsZT0kMQorICBzaGlmdAorCisgIGNhc2UgJGFjX21vZGUgaW4KKyAgOkwpIGFjX3NvdXJj
ZT0kMTs7CisgIDpbRkhdKQorICAgIGFjX2ZpbGVfaW5wdXRzPQorICAgIGZvciBhY19mCisgICAg
ZG8KKyAgICAgIGNhc2UgJGFjX2YgaW4KKyAgICAgIC0pIGFjX2Y9IiRhY190bXAvc3RkaW4iOzsK
KyAgICAgICopICMgTG9vayBmb3IgdGhlIGZpbGUgZmlyc3QgaW4gdGhlIGJ1aWxkIHRyZWUsIHRo
ZW4gaW4gdGhlIHNvdXJjZSB0cmVlCisJICMgKGlmIHRoZSBwYXRoIGlzIG5vdCBhYnNvbHV0ZSku
ICBUaGUgYWJzb2x1dGUgcGF0aCBjYW5ub3QgYmUgRE9TLXN0eWxlLAorCSAjIGJlY2F1c2UgJGFj
X2YgY2Fubm90IGNvbnRhaW4gYDonLgorCSB0ZXN0IC1mICIkYWNfZiIgfHwKKwkgICBjYXNlICRh
Y19mIGluCisJICAgW1xcLyRdKikgZmFsc2U7OworCSAgICopIHRlc3QgLWYgIiRzcmNkaXIvJGFj
X2YiICYmIGFjX2Y9IiRzcmNkaXIvJGFjX2YiOzsKKwkgICBlc2FjIHx8CisJICAgYXNfZm5fZXJy
b3IgMSAiY2Fubm90IGZpbmQgaW5wdXQgZmlsZTogXGAkYWNfZiciICIkTElORU5PIiA1OzsKKyAg
ICAgIGVzYWMKKyAgICAgIGNhc2UgJGFjX2YgaW4gKlwnKikgYWNfZj1gJGFzX2VjaG8gIiRhY19m
IiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYDs7IGVzYWMKKyAgICAgIGFzX2ZuX2FwcGVuZCBh
Y19maWxlX2lucHV0cyAiICckYWNfZiciCisgICAgZG9uZQorCisgICAgIyBMZXQncyBzdGlsbCBw
cmV0ZW5kIGl0IGlzIGBjb25maWd1cmUnIHdoaWNoIGluc3RhbnRpYXRlcyAoaS5lLiwgZG9uJ3QK
KyAgICAjIHVzZSAkYXNfbWUpLCBwZW9wbGUgd291bGQgYmUgc3VycHJpc2VkIHRvIHJlYWQ6Cisg
ICAgIyAgICAvKiBjb25maWcuaC4gIEdlbmVyYXRlZCBieSBjb25maWcuc3RhdHVzLiAgKi8KKyAg
ICBjb25maWd1cmVfaW5wdXQ9J0dlbmVyYXRlZCBmcm9tICdgCisJICAkYXNfZWNobyAiJCoiIHwg
c2VkICdzfF5bXjpdKi98fDtzfDpbXjpdKi98LCB8ZycKKwlgJyBieSBjb25maWd1cmUuJworICAg
IGlmIHRlc3QgeCIkYWNfZmlsZSIgIT0geC07IHRoZW4KKyAgICAgIGNvbmZpZ3VyZV9pbnB1dD0i
JGFjX2ZpbGUuICAkY29uZmlndXJlX2lucHV0IgorICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjcmVhdGluZyAkYWNfZmlsZSIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBjcmVhdGluZyAkYWNfZmlsZSIgPiY2O30KKyAgICBmaQorICAgICMgTmV1dHJhbGl6ZSBz
cGVjaWFsIGNoYXJhY3RlcnMgaW50ZXJwcmV0ZWQgYnkgc2VkIGluIHJlcGxhY2VtZW50IHN0cmlu
Z3MuCisgICAgY2FzZSAkY29uZmlndXJlX2lucHV0IGluICMoCisgICAgKlwmKiB8ICpcfCogfCAq
XFwqICkKKyAgICAgICBhY19zZWRfY29uZl9pbnB1dD1gJGFzX2VjaG8gIiRjb25maWd1cmVfaW5w
dXQiIHwKKyAgICAgICBzZWQgJ3MvW1xcXFwmfF0vXFxcXCYvZydgOzsgIygKKyAgICAqKSBhY19z
ZWRfY29uZl9pbnB1dD0kY29uZmlndXJlX2lucHV0OzsKKyAgICBlc2FjCisKKyAgICBjYXNlICRh
Y190YWcgaW4KKyAgICAqOi06KiB8ICo6LSkgY2F0ID4iJGFjX3RtcC9zdGRpbiIgXAorICAgICAg
fHwgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1
IDs7CisgICAgZXNhYworICAgIDs7CisgIGVzYWMKKworICBhY19kaXI9YCRhc19kaXJuYW1lIC0t
ICIkYWNfZmlsZSIgfHwKKyRhc19leHByIFgiJGFjX2ZpbGUiIDogJ1hcKC4qW14vXVwpLy8qW14v
XVteL10qLyokJyBcfCBcCisJIFgiJGFjX2ZpbGUiIDogJ1hcKC8vXClbXi9dJyBcfCBcCisJIFgi
JGFjX2ZpbGUiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJGFjX2ZpbGUiIDogJ1hcKC9cKScgXHwg
LiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWCIkYWNfZmlsZSIgfAorICAgIHNlZCAnL15YXCgu
KlteL11cKVwvXC8qW14vXVteL10qXC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJ
ICAvXlhcKFwvXC9cKVteL10uKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhc
KFwvXC9cKSQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wpLiovewor
CSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisgIGFzX2Rpcj0iJGFj
X2RpciI7IGFzX2ZuX21rZGlyX3AKKyAgYWNfYnVpbGRkaXI9LgorCitjYXNlICIkYWNfZGlyIiBp
bgorLikgYWNfZGlyX3N1ZmZpeD0gYWNfdG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9w
cmVmaXg9IDs7CisqKQorICBhY19kaXJfc3VmZml4PS9gJGFzX2VjaG8gIiRhY19kaXIiIHwgc2Vk
ICdzfF5cLltcXC9dfHwnYAorICAjIEEgIi4uIiBmb3IgZWFjaCBkaXJlY3RvcnkgaW4gJGFjX2Rp
cl9zdWZmaXguCisgIGFjX3RvcF9idWlsZGRpcl9zdWI9YCRhc19lY2hvICIkYWNfZGlyX3N1ZmZp
eCIgfCBzZWQgJ3N8L1teXFwvXSp8Ly4ufGc7c3wvfHwnYAorICBjYXNlICRhY190b3BfYnVpbGRk
aXJfc3ViIGluCisgICIiKSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZp
eD0gOzsKKyAgKikgIGFjX3RvcF9idWlsZF9wcmVmaXg9JGFjX3RvcF9idWlsZGRpcl9zdWIvIDs7
CisgIGVzYWMgOzsKK2VzYWMKK2FjX2Fic190b3BfYnVpbGRkaXI9JGFjX3B3ZAorYWNfYWJzX2J1
aWxkZGlyPSRhY19wd2QkYWNfZGlyX3N1ZmZpeAorIyBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0
eToKK2FjX3RvcF9idWlsZGRpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeAorCitjYXNlICRzcmNkaXIg
aW4KKyAgLikgICMgV2UgYXJlIGJ1aWxkaW5nIGluIHBsYWNlLgorICAgIGFjX3NyY2Rpcj0uCisg
ICAgYWNfdG9wX3NyY2Rpcj0kYWNfdG9wX2J1aWxkZGlyX3N1YgorICAgIGFjX2Fic190b3Bfc3Jj
ZGlyPSRhY19wd2QgOzsKKyAgW1xcL10qIHwgPzpbXFwvXSogKSAgIyBBYnNvbHV0ZSBuYW1lLgor
ICAgIGFjX3NyY2Rpcj0kc3JjZGlyJGFjX2Rpcl9zdWZmaXg7CisgICAgYWNfdG9wX3NyY2Rpcj0k
c3JjZGlyCisgICAgYWNfYWJzX3RvcF9zcmNkaXI9JHNyY2RpciA7OworICAqKSAjIFJlbGF0aXZl
IG5hbWUuCisgICAgYWNfc3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpciRhY19kaXJf
c3VmZml4CisgICAgYWNfdG9wX3NyY2Rpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIKKyAg
ICBhY19hYnNfdG9wX3NyY2Rpcj0kYWNfcHdkLyRzcmNkaXIgOzsKK2VzYWMKK2FjX2Fic19zcmNk
aXI9JGFjX2Fic190b3Bfc3JjZGlyJGFjX2Rpcl9zdWZmaXgKKworCisgIGNhc2UgJGFjX21vZGUg
aW4KKyAgOkYpCisgICMKKyAgIyBDT05GSUdfRklMRQorICAjCisKKyAgY2FzZSAkSU5TVEFMTCBp
bgorICBbXFwvJF0qIHwgPzpbXFwvXSogKSBhY19JTlNUQUxMPSRJTlNUQUxMIDs7CisgICopIGFj
X0lOU1RBTEw9JGFjX3RvcF9idWlsZF9wcmVmaXgkSU5TVEFMTCA7OworICBlc2FjCitfQUNFT0YK
KworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorIyBJ
ZiB0aGUgdGVtcGxhdGUgZG9lcyBub3Qga25vdyBhYm91dCBkYXRhcm9vdGRpciwgZXhwYW5kIGl0
LgorIyBGSVhNRTogVGhpcyBoYWNrIHNob3VsZCBiZSByZW1vdmVkIGEgZmV3IHllYXJzIGFmdGVy
IDIuNjAuCithY19kYXRhcm9vdGRpcl9oYWNrPTsgYWNfZGF0YXJvb3RkaXJfc2Vlbj0KK2FjX3Nl
ZF9kYXRhcm9vdD0nCisvZGF0YXJvb3RkaXIvIHsKKyAgcAorICBxCit9CisvQGRhdGFkaXJAL3AK
Ky9AZG9jZGlyQC9wCisvQGluZm9kaXJAL3AKKy9AbG9jYWxlZGlyQC9wCisvQG1hbmRpckAvcCcK
K2Nhc2UgYGV2YWwgInNlZCAtbiBcIlwkYWNfc2VkX2RhdGFyb290XCIgJGFjX2ZpbGVfaW5wdXRz
ImAgaW4KKypkYXRhcm9vdGRpciopIGFjX2RhdGFyb290ZGlyX3NlZW49eWVzOzsKKypAZGF0YWRp
ckAqfCpAZG9jZGlyQCp8KkBpbmZvZGlyQCp8KkBsb2NhbGVkaXJAKnwqQG1hbmRpckAqKQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICRhY19maWxl
X2lucHV0cyBzZWVtcyB0byBpZ25vcmUgdGhlIC0tZGF0YXJvb3RkaXIgc2V0dGluZyIgPiY1Cisk
YXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkYWNfZmlsZV9pbnB1dHMgc2VlbXMgdG8gaWdub3Jl
IHRoZSAtLWRhdGFyb290ZGlyIHNldHRpbmciID4mMjt9CitfQUNFT0YKK2NhdCA+PiRDT05GSUdf
U1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorICBhY19kYXRhcm9vdGRpcl9oYWNr
PScKKyAgcyZAZGF0YWRpckAmJGRhdGFkaXImZworICBzJkBkb2NkaXJAJiRkb2NkaXImZworICBz
JkBpbmZvZGlyQCYkaW5mb2RpciZnCisgIHMmQGxvY2FsZWRpckAmJGxvY2FsZWRpciZnCisgIHMm
QG1hbmRpckAmJG1hbmRpciZnCisgIHMmXFxcJHtkYXRhcm9vdGRpcn0mJGRhdGFyb290ZGlyJmcn
IDs7Citlc2FjCitfQUNFT0YKKworIyBOZXV0cmFsaXplIFZQQVRIIHdoZW4gYCRzcmNkaXInID0g
YC4nLgorIyBTaGVsbCBjb2RlIGluIGNvbmZpZ3VyZS5hYyBtaWdodCBzZXQgZXh0cmFzdWIuCisj
IEZJWE1FOiBkbyB3ZSByZWFsbHkgd2FudCB0byBtYWludGFpbiB0aGlzIGZlYXR1cmU/CitjYXQg
Pj4kQ09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2FjX3NlZF9leHRy
YT0iJGFjX3Zwc3ViCiskZXh0cmFzdWIKK19BQ0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxc
X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorOnQKKy9AW2EtekEtWl9dW2EtekEtWl8wLTldKkAv
IWIKK3N8QGNvbmZpZ3VyZV9pbnB1dEB8JGFjX3NlZF9jb25mX2lucHV0fDt0IHQKK3MmQHRvcF9i
dWlsZGRpckAmJGFjX3RvcF9idWlsZGRpcl9zdWImO3QgdAorcyZAdG9wX2J1aWxkX3ByZWZpeEAm
JGFjX3RvcF9idWlsZF9wcmVmaXgmO3QgdAorcyZAc3JjZGlyQCYkYWNfc3JjZGlyJjt0IHQKK3Mm
QGFic19zcmNkaXJAJiRhY19hYnNfc3JjZGlyJjt0IHQKK3MmQHRvcF9zcmNkaXJAJiRhY190b3Bf
c3JjZGlyJjt0IHQKK3MmQGFic190b3Bfc3JjZGlyQCYkYWNfYWJzX3RvcF9zcmNkaXImO3QgdAor
cyZAYnVpbGRkaXJAJiRhY19idWlsZGRpciY7dCB0CitzJkBhYnNfYnVpbGRkaXJAJiRhY19hYnNf
YnVpbGRkaXImO3QgdAorcyZAYWJzX3RvcF9idWlsZGRpckAmJGFjX2Fic190b3BfYnVpbGRkaXIm
O3QgdAorcyZASU5TVEFMTEAmJGFjX0lOU1RBTEwmO3QgdAorJGFjX2RhdGFyb290ZGlyX2hhY2sK
KyIKK2V2YWwgc2VkIFwiXCRhY19zZWRfZXh0cmFcIiAiJGFjX2ZpbGVfaW5wdXRzIiB8ICRBV0sg
LWYgIiRhY190bXAvc3Vicy5hd2siIFwKKyAgPiRhY190bXAvb3V0IHx8IGFzX2ZuX2Vycm9yICQ/
ICJjb3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorCit0ZXN0IC16ICIkYWNf
ZGF0YXJvb3RkaXJfaGFjayRhY19kYXRhcm9vdGRpcl9zZWVuIiAmJgorICB7IGFjX291dD1gc2Vk
IC1uICcvXCR7ZGF0YXJvb3RkaXJ9L3AnICIkYWNfdG1wL291dCJgOyB0ZXN0IC1uICIkYWNfb3V0
IjsgfSAmJgorICB7IGFjX291dD1gc2VkIC1uICcvXlsJIF0qZGF0YXJvb3RkaXJbCSBdKjoqPS9w
JyBcCisgICAgICAiJGFjX3RtcC9vdXQiYDsgdGVzdCAteiAiJGFjX291dCI7IH0gJiYKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkYWNfZmlsZSBj
b250YWlucyBhIHJlZmVyZW5jZSB0byB0aGUgdmFyaWFibGUgXGBkYXRhcm9vdGRpcicKK3doaWNo
IHNlZW1zIHRvIGJlIHVuZGVmaW5lZC4gIFBsZWFzZSBtYWtlIHN1cmUgaXQgaXMgZGVmaW5lZCIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkYWNfZmlsZSBjb250YWlucyBhIHJlZmVy
ZW5jZSB0byB0aGUgdmFyaWFibGUgXGBkYXRhcm9vdGRpcicKK3doaWNoIHNlZW1zIHRvIGJlIHVu
ZGVmaW5lZC4gIFBsZWFzZSBtYWtlIHN1cmUgaXQgaXMgZGVmaW5lZCIgPiYyO30KKworICBybSAt
ZiAiJGFjX3RtcC9zdGRpbiIKKyAgY2FzZSAkYWNfZmlsZSBpbgorICAtKSBjYXQgIiRhY190bXAv
b3V0IiAmJiBybSAtZiAiJGFjX3RtcC9vdXQiOzsKKyAgKikgcm0gLWYgIiRhY19maWxlIiAmJiBt
diAiJGFjX3RtcC9vdXQiICIkYWNfZmlsZSI7OworICBlc2FjIFwKKyAgfHwgYXNfZm5fZXJyb3Ig
JD8gImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisgOzsKKyAgOkgpCisg
ICMKKyAgIyBDT05GSUdfSEVBREVSCisgICMKKyAgaWYgdGVzdCB4IiRhY19maWxlIiAhPSB4LTsg
dGhlbgorICAgIHsKKyAgICAgICRhc19lY2hvICIvKiAkY29uZmlndXJlX2lucHV0ICAqLyIgXAor
ICAgICAgJiYgZXZhbCAnJEFXSyAtZiAiJGFjX3RtcC9kZWZpbmVzLmF3ayInICIkYWNfZmlsZV9p
bnB1dHMiCisgICAgfSA+IiRhY190bXAvY29uZmlnLmgiIFwKKyAgICAgIHx8IGFzX2ZuX2Vycm9y
ICQ/ICJjb3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorICAgIGlmIGRpZmYg
IiRhY19maWxlIiAiJGFjX3RtcC9jb25maWcuaCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgICAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY19maWxlIGlzIHVu
Y2hhbmdlZCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiAkYWNfZmlsZSBpcyB1bmNoYW5nZWQiID4m
Njt9CisgICAgZWxzZQorICAgICAgcm0gLWYgIiRhY19maWxlIgorICAgICAgbXYgIiRhY190bXAv
Y29uZmlnLmgiICIkYWNfZmlsZSIgXAorCXx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgY3Jl
YXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorICAgIGZpCisgIGVsc2UKKyAgICAkYXNfZWNobyAi
LyogJGNvbmZpZ3VyZV9pbnB1dCAgKi8iIFwKKyAgICAgICYmIGV2YWwgJyRBV0sgLWYgIiRhY190
bXAvZGVmaW5lcy5hd2siJyAiJGFjX2ZpbGVfaW5wdXRzIiBcCisgICAgICB8fCBhc19mbl9lcnJv
ciAkPyAiY291bGQgbm90IGNyZWF0ZSAtIiAiJExJTkVOTyIgNQorICBmaQorIDs7CisKKworICBl
c2FjCisKK2RvbmUgIyBmb3IgYWNfdGFnCisKKworYXNfZm5fZXhpdCAwCitfQUNFT0YKK2FjX2Ns
ZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCisKK3Rlc3QgJGFjX3dyaXRlX2ZhaWwgPSAw
IHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJ3cml0ZSBmYWlsdXJlIGNyZWF0aW5nICRDT05GSUdfU1RB
VFVTIiAiJExJTkVOTyIgNQorCisKKyMgY29uZmlndXJlIGlzIHdyaXRpbmcgdG8gY29uZmlnLmxv
ZywgYW5kIHRoZW4gY2FsbHMgY29uZmlnLnN0YXR1cy4KKyMgY29uZmlnLnN0YXR1cyBkb2VzIGl0
cyBvd24gcmVkaXJlY3Rpb24sIGFwcGVuZGluZyB0byBjb25maWcubG9nLgorIyBVbmZvcnR1bmF0
ZWx5LCBvbiBET1MgdGhpcyBmYWlscywgYXMgY29uZmlnLmxvZyBpcyBzdGlsbCBrZXB0IG9wZW4K
KyMgYnkgY29uZmlndXJlLCBzbyBjb25maWcuc3RhdHVzIHdvbid0IGJlIGFibGUgdG8gd3JpdGUg
dG8gaXQ7IGl0cworIyBvdXRwdXQgaXMgc2ltcGx5IGRpc2NhcmRlZC4gIFNvIHdlIGV4ZWMgdGhl
IEZEIHRvIC9kZXYvbnVsbCwKKyMgZWZmZWN0aXZlbHkgY2xvc2luZyBjb25maWcubG9nLCBzbyBp
dCBjYW4gYmUgcHJvcGVybHkgKHJlKW9wZW5lZCBhbmQKKyMgYXBwZW5kZWQgdG8gYnkgY29uZmln
LnN0YXR1cy4gIFdoZW4gY29taW5nIGJhY2sgdG8gY29uZmlndXJlLCB3ZQorIyBuZWVkIHRvIG1h
a2UgdGhlIEZEIGF2YWlsYWJsZSBhZ2Fpbi4KK2lmIHRlc3QgIiRub19jcmVhdGUiICE9IHllczsg
dGhlbgorICBhY19jc19zdWNjZXNzPToKKyAgYWNfY29uZmlnX3N0YXR1c19hcmdzPQorICB0ZXN0
ICIkc2lsZW50IiA9IHllcyAmJgorICAgIGFjX2NvbmZpZ19zdGF0dXNfYXJncz0iJGFjX2NvbmZp
Z19zdGF0dXNfYXJncyAtLXF1aWV0IgorICBleGVjIDU+L2Rldi9udWxsCisgICRTSEVMTCAkQ09O
RklHX1NUQVRVUyAkYWNfY29uZmlnX3N0YXR1c19hcmdzIHx8IGFjX2NzX3N1Y2Nlc3M9ZmFsc2UK
KyAgZXhlYyA1Pj5jb25maWcubG9nCisgICMgVXNlIHx8LCBub3QgJiYsIHRvIGF2b2lkIGV4aXRp
bmcgZnJvbSB0aGUgaWYgd2l0aCAkPyA9IDEsIHdoaWNoCisgICMgd291bGQgbWFrZSBjb25maWd1
cmUgZmFpbCBpZiB0aGlzIGlzIHRoZSBsYXN0IGluc3RydWN0aW9uLgorICAkYWNfY3Nfc3VjY2Vz
cyB8fCBhc19mbl9leGl0IDEKK2ZpCitpZiB0ZXN0IC1uICIkYWNfdW5yZWNvZ25pemVkX29wdHMi
ICYmIHRlc3QgIiRlbmFibGVfb3B0aW9uX2NoZWNraW5nIiAhPSBubzsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVucmVjb2duaXplZCBv
cHRpb25zOiAkYWNfdW5yZWNvZ25pemVkX29wdHMiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FS
TklORzogdW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiYyO30K
K2ZpCisKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NvbmZpZ3Vy
ZS5hYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9jb25maWd1cmUuYWMJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAg
KzEsMTg5IEBACisjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAtKi0gQXV0b2NvbmYgLSotCisjIFByb2Nlc3MgdGhpcyBmaWxlIHdpdGggYXV0b2NvbmYgdG8g
cHJvZHVjZSBhIGNvbmZpZ3VyZSBzY3JpcHQuCisKK0FDX1BSRVJFUShbMi42N10pCitBQ19JTklU
KFtYZW4gSHlwZXJ2aXNvcl0sIG00X2VzeXNjbWQoWy4uL3ZlcnNpb24uc2ggLi4veGVuL01ha2Vm
aWxlXSksCisgICAgW3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tXSkKK0FDX0NPTkZJR19T
UkNESVIoW2xpYnhsL2xpYnhsLmNdKQorQUNfQ09ORklHX0ZJTEVTKFsuLi9jb25maWcvVG9vbHMu
bWtdKQorQUNfQ09ORklHX0hFQURFUlMoW2NvbmZpZy5oXSkKK0FDX1BSRUZJWF9ERUZBVUxUKFsv
dXNyXSkKK0FDX0NPTkZJR19BVVhfRElSKFsuXSkKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxB
R1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBpcyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitB
U19JRihbdGVzdCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIl0sIFsK
KyAgICBBQ19NU0dfV0FSTigKK1tTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQ
UEZMQUdTIG9yIENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVT
LCBQUkVQRU5EX0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQg
d2hlbiBwb3NzaWJsZS5dKQorXSkKKworQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCitBQ19DQU5P
TklDQUxfSE9TVAorCisjIE00IE1hY3JvIGluY2x1ZGVzCittNF9pbmNsdWRlKFttNC9lbmFibGVf
ZmVhdHVyZS5tNF0pCittNF9pbmNsdWRlKFttNC9kaXNhYmxlX2ZlYXR1cmUubTRdKQorbTRfaW5j
bHVkZShbbTQvcGF0aF9vcl9mYWlsLm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl94bWwubTRd
KQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX3ZlcnNpb24ubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0
aG9uX2RldmVsLm00XSkKK200X2luY2x1ZGUoW200L3VkZXYubTRdKQorbTRfaW5jbHVkZShbbTQv
b2NhbWwubTRdKQorbTRfaW5jbHVkZShbbTQvZGVmYXVsdF9saWIubTRdKQorbTRfaW5jbHVkZShb
bTQvc2V0X2NmbGFnc19sZGZsYWdzLm00XSkKKworIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCitB
WF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hzbV0sCisgICAgW0VuYWJsZSBYU00gc2VjdXJpdHkg
bW9kdWxlIChieSBkZWZhdWx0LCBGbGFzayldKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtn
aXRodHRwXSwgW0Rvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFBdKQorQVhfQVJHX0RJ
U0FCTEVfQU5EX0VYUE9SVChbbW9uaXRvcnNdLAorICAgIFtEaXNhYmxlIHhlbnN0YXQgYW5kIHhl
bnRvcCBtb25pdG9yaW5nIHRvb2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbdnRwbV0s
IFtFbmFibGUgVmlydHVhbCBUcnVzdGVkIFBsYXRmb3JtIE1vZHVsZV0pCitBWF9BUkdfRU5BQkxF
X0FORF9FWFBPUlQoW3hhcGldLCBbRW5hYmxlIFhlbiBBUEkgQmluZGluZ3NdKQorQVhfQVJHX0RJ
U0FCTEVfQU5EX0VYUE9SVChbcHl0aG9udG9vbHNdLCBbRGlzYWJsZSBQeXRob24gdG9vbHNdKQor
QVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbb2NhbWx0b29sc10sIFtEaXNhYmxlIE9jYW1sIHRv
b2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbWluaXRlcm1dLCBbRW5hYmxlIG1pbml0
ZXJtXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbG9tb3VudF0sIFtFbmFibGUgbG9tb3Vu
dF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtkZWJ1Z10sIFtEaXNhYmxlIGRlYnVnIGJ1
aWxkIG9mIFhlbiBhbmQgdG9vbHNdKQorCitBQ19BUkdfVkFSKFtQUkVQRU5EX0lOQ0xVREVTXSwK
KyAgICBbTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhv
dXQgLUkpXSkKK0FDX0FSR19WQVIoW1BSRVBFTkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5
IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRob3V0IC1MKV0pCitBQ19BUkdfVkFS
KFtBUFBFTkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBhcHBl
bmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKV0pCitBQ19BUkdfVkFSKFtBUFBFTkRfTElCXSwKKyAg
ICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gYXBwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQg
LUwpXSkKKworQVhfU0VUX0ZMQUdTCisKK0FDX0FSR19WQVIoW1BZVEhPTl0sIFtQYXRoIHRvIHRo
ZSBQeXRob24gcGFyc2VyXSkKK0FDX0FSR19WQVIoW1BFUkxdLCBbUGF0aCB0byBQZXJsIHBhcnNl
cl0pCitBQ19BUkdfVkFSKFtCUkNUTF0sIFtQYXRoIHRvIGJyY3RsIHRvb2xdKQorQUNfQVJHX1ZB
UihbSVBdLCBbUGF0aCB0byBpcCB0b29sXSkKK0FDX0FSR19WQVIoW0JJU09OXSwgW1BhdGggdG8g
Qmlzb24gcGFyc2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtGTEVYXSwgW1BhdGggdG8gRmxl
eCBsZXhpY2FsIGFuYWx5c2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtDVVJMXSwgW1BhdGgg
dG8gY3VybC1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtYTUxdLCBbUGF0aCB0byB4bWwyLWNv
bmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW0JBU0hdLCBbUGF0aCB0byBiYXNoIHNoZWxsXSkKK0FD
X0FSR19WQVIoW1hHRVRURVhUXSwgW1BhdGggdG8geGdldHR0ZXh0IHRvb2xdKQorCisjIENoZWNr
cyBmb3IgcHJvZ3JhbXMuCitBQ19QUk9HX1NFRAorQUNfUFJPR19DQworQUNfUFJPR19MTl9TCitB
Q19QUk9HX01BS0VfU0VUCitBQ19QUk9HX0lOU1RBTEwKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtQ
RVJMXSwgW3BlcmxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JSQ1RMXSwgW2JyY3RsXSkKK0FY
X1BBVEhfUFJPR19PUl9GQUlMKFtJUF0sIFtpcF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQklT
T05dLCBbYmlzb25dKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0ZMRVhdLCBbZmxleF0pCitBU19J
RihbdGVzdCAieCR4YXBpIiA9ICJ4eSJdLCBbCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0NV
UkxdLCBbY3VybC1jb25maWddKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtYTUxdLCBbeG1s
Mi1jb25maWddKQorXSkKK0FTX0lGKFt0ZXN0ICJ4JG9jYW1sdG9vbHMiID0gInh5Il0sIFsKKyAg
ICBBQ19QUk9HX09DQU1MCisgICAgQVNfSUYoW3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwgWwor
ICAgICAgICBBU19JRihbdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyJdLCBbCisg
ICAgICAgICAgICBBQ19NU0dfRVJST1IoW09jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUg
dG8gZmluZCBPY2FtbF0pXSkKKyAgICAgICAgb2NhbWx0b29scz0ibiIKKyAgICBdKQorXSkKK0FY
X1BBVEhfUFJPR19PUl9GQUlMKFtCQVNIXSwgW2Jhc2hdKQorQVNfSUYoW3Rlc3QgIngkcHl0aG9u
dG9vbHMiID0gInh5Il0sIFsKKyAgICBBU19JRihbZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJe
LyJdLCBbCisgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgorICAgICAgICBQWVRIT049YGJhc2Vu
YW1lICRQWVRIT05QQVRIYAorICAgIF0sW3Rlc3QgLXogIiRQWVRIT04iXSwgW1BZVEhPTj0icHl0
aG9uIl0sCisgICAgW0FDX01TR19FUlJPUihbUFlUSE9OIHNwZWNpZmllZCwgYnV0IGlzIG5vdCBh
biBhYnNvbHV0ZSBwYXRoXSldKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtQWVRIT05QQVRI
XSwgWyRQWVRIT05dKQorICAgIEFYX0NIRUNLX1BZVEhPTl9WRVJTSU9OKFsyXSwgWzNdKQorICAg
IEFYX0NIRUNLX1BZVEhPTl9YTUwoKQorICAgIEFYX0NIRUNLX1BZVEhPTl9ERVZFTCgpCitdKQor
QVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hHRVRURVhUXSwgW3hnZXR0ZXh0XSkKK0FYX0NIRUNLX1VE
RVYoWzU5XSkKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK0FYX0RFRkFVTFRfTElCCisKKyMgQ2hl
Y2tzIGZvciBsaWJyYXJpZXMuCitBQ19DSEVDS19MSUIoW2Fpb10sIFtpb19zZXR1cF0sIFtzeXN0
ZW1fYWlvPSJ5Il0sIFtzeXN0ZW1fYWlvPSJuIl0pCitBQ19TVUJTVChzeXN0ZW1fYWlvKQorQUNf
Q0hFQ0tfTElCKFtjcnlwdG9dLCBbTUQ1XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBm
aW5kIGxpYmNyeXB0b10pXSkKK0FDX0NIRUNLX0xJQihbZXh0MmZzXSwgW2V4dDJmc19vcGVuMl0s
IFtsaWJleHQyZnM9InkiXSwgW2xpYmV4dDJmcz0ibiJdKQorQUNfU1VCU1QobGliZXh0MmZzKQor
QUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0sIFtsaWJnY3J5cHQ9
InkiXSwgW2xpYmdjcnlwdD0ibiJdKQorQUNfU1VCU1QobGliZ2NyeXB0KQorQUNfQ0hFQ0tfTElC
KFtwdGhyZWFkXSwgW3B0aHJlYWRfY3JlYXRlXSwgW10gLAorICAgIFtBQ19NU0dfRVJST1IoW0Nv
dWxkIG5vdCBmaW5kIGxpYnB0aHJlYWRdKV0pCitBQ19DSEVDS19MSUIoW3J0XSwgW2Nsb2NrX2dl
dHRpbWVdKQorQUNfQ0hFQ0tfTElCKFt1dWlkXSwgW3V1aWRfY2xlYXJdLCBbXSwKKyAgICBbQUNf
TVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJ1dWlkXSldKQorQUNfQ0hFQ0tfTElCKFt5YWps
XSwgW3lhamxfYWxsb2NdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB5
YWpsXSldKQorQUNfQ0hFQ0tfTElCKFt6XSwgW2RlZmxhdGVDb3B5XSwgW10sIFtBQ19NU0dfRVJS
T1IoW0NvdWxkIG5vdCBmaW5kIHpsaWJdKV0pCitBQ19DSEVDS19MSUIoW2ljb252XSwgW2xpYmlj
b252X29wZW5dLCBbbGliaWNvbnY9InkiXSwgW2xpYmljb252PSJuIl0pCitBQ19TVUJTVChsaWJp
Y29udikKKworIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5o
IGNoZWNrKQorIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK0FDX0ZVTkNfQUxMT0NBCitBQ19D
SEVDS19IRUFERVJTKFsgXAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50
dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAgICAgICAgICAgIG5l
dGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwK
KyAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91
bnQuaCBzeXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0
dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAgICAgICAgICAgIHVu
aXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorICAgICAgICAgICAgICAgIF0pCisKKyMgQ2hl
Y2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGlj
cy4KK0FDX0hFQURFUl9TVERCT09MCitBQ19UWVBFX1VJRF9UCitBQ19DX0lOTElORQorQUNfVFlQ
RV9JTlQxNl9UCitBQ19UWVBFX0lOVDMyX1QKK0FDX1RZUEVfSU5UNjRfVAorQUNfVFlQRV9JTlQ4
X1QKK0FDX1RZUEVfTU9ERV9UCitBQ19UWVBFX09GRl9UCitBQ19UWVBFX1BJRF9UCitBQ19DX1JF
U1RSSUNUCitBQ19UWVBFX1NJWkVfVAorQUNfVFlQRV9TU0laRV9UCitBQ19DSEVDS19NRU1CRVJT
KFtzdHJ1Y3Qgc3RhdC5zdF9ibGtzaXplXSkKK0FDX1NUUlVDVF9TVF9CTE9DS1MKK0FDX0NIRUNL
X01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X3JkZXZdKQorQUNfVFlQRV9VSU5UMTZfVAorQUNfVFlQ
RV9VSU5UMzJfVAorQUNfVFlQRV9VSU5UNjRfVAorQUNfVFlQRV9VSU5UOF9UCitBQ19DSEVDS19U
WVBFUyhbcHRyZGlmZl90XSkKKworIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgorQUNf
RlVOQ19FUlJPUl9BVF9MSU5FCitBQ19GVU5DX0ZPUksKK0FDX0ZVTkNfRlNFRUtPCitBQ19GVU5D
X0xTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCitBQ19IRUFERVJfTUFKT1IKK0FDX0ZVTkNf
TUFMTE9DCitBQ19GVU5DX01LVElNRQorQUNfRlVOQ19NTUFQCitBQ19GVU5DX1JFQUxMT0MKK0FD
X0ZVTkNfU1RSTkxFTgorQUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNTKFsgXAorICAgICAg
ICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5j
IGZ0cnVuY2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9z
dG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250
b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAg
ICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRp
ciBzZWxlY3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJj
aHIgc3RyY3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3Ry
cGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQg
XAorICAgICAgICAgICAgICAgIHVuYW1lIFwKKyAgICAgICAgICAgICAgICBdKQorCitBQ19PVVRQ
VVQoKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvZGVidWdnZXIv
Z2Ric3gveGcvTWFrZWZpbGUKLS0tIGEvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJ
VGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4
L3hnL01ha2VmaWxlCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMjEsNyArMjEs
NiBAQCB4Z19hbGwuYTogJChYR19PQkpTKSBNYWtlZmlsZSAkKFhHX0hEUlMpCiAjCSQoQ0MpIC1t
MzIgLWMgLW8gJEAgJF4KIAogeGVuLWhlYWRlcnM6Ci0JJChNQUtFKSAtQyAuLi8uLi8uLi9jaGVj
ayAKIAkkKE1BS0UpIC1DIC4uLy4uLy4uL2luY2x1ZGUKIAogIyB4Z19tYWluLm86IHhnX21haW4u
YyBNYWtlZmlsZSAkKFhHX0hEUlMpCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIw
ZiB0b29scy9pbnN0YWxsLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3Rvb2xzL2luc3RhbGwuc2gJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMSBAQAorLi4vaW5zdGFsbC5zaApcIE5vIG5ld2xpbmUgYXQgZW5kIG9m
IGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2xpYmZzaW1h
Z2UvTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlUaHUgSmFuIDA1IDE3
OjI1OjIzIDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlUdWUgSmFu
IDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTIsNyArMiwxMSBAQCBYRU5fUk9PVCA9ICQoQ1VS
RElSKS8uLi8uLgogaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJT
LXkgPSBjb21tb24gdWZzIHJlaXNlcmZzIGlzbzk2NjAgZmF0IHpmcyB4ZnMKLVNVQkRJUlMteSAr
PSAkKHNoZWxsIGVudiBDQz0iJChDQykiIC4vY2hlY2stbGliZXh0MmZzKQoraWZlcSAoJChDT05G
SUdfRVhUMkZTKSwgeSkKKyAgICBTVUJESVJTLXkgKz0gZXh0MmZzLWxpYgorZWxzZQorICAgIFNV
QkRJUlMteSArPSBleHQyZnMKK2VuZGlmCiAKIC5QSE9OWTogYWxsIGNsZWFuIGluc3RhbGwKIGFs
bCBjbGVhbiBpbnN0YWxsOiAlOiBzdWJkaXJzLSUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2
NWQ5NGRhYjBmIHRvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGliZXh0MmZzCi0tLSBhL3Rvb2xzL2xp
YmZzaW1hZ2UvY2hlY2stbGliZXh0MmZzCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAor
KysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMSArMCww
IEBACi0jIS9iaW4vc2gKLQotY2F0ID5leHQyLXRlc3QuYyA8PEVPRgotI2luY2x1ZGUgPGV4dDJm
cy9leHQyZnMuaD4KLQotaW50IG1haW4oKQotewotCWV4dDJmc19vcGVuMjsKLX0KLUVPRgotCi0k
e0NDLWdjY30gLW8gZXh0Mi10ZXN0IGV4dDItdGVzdC5jIC1sZXh0MmZzID4vZGV2L251bGwgMj4m
MQotaWYgWyAkPyA9IDAgXTsgdGhlbgotCWVjaG8gZXh0MmZzLWxpYgotZWxzZQotCWVjaG8gZXh0
MmZzCi1maQotCi1ybSAtZiBleHQyLXRlc3QgZXh0Mi10ZXN0LmMKLQotZXhpdCAwCmRpZmYgLXIg
NDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9saWJ4ZW4vTWFrZWZpbGUKLS0tIGEv
dG9vbHMvbGlieGVuL01ha2VmaWxlCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysg
Yi90b29scy9saWJ4ZW4vTWFrZWZpbGUJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBA
IC0yMiwxMiArMjIsMTIgQEAgTUFKT1IgPSAxLjAKIE1JTk9SID0gMAogCiBDRkxBR1MgKz0gLUlp
bmNsdWRlICAgICAgICAgICAgICAgICAgICAgXAotICAgICAgICAgICQoc2hlbGwgeG1sMi1jb25m
aWcgLS1jZmxhZ3MpIFwKLSAgICAgICAgICAkKHNoZWxsIGN1cmwtY29uZmlnIC0tY2ZsYWdzKSBc
CisgICAgICAgICAgJChzaGVsbCAkKFhNTDJfQ09ORklHKSAtLWNmbGFncykgXAorICAgICAgICAg
ICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1jZmxhZ3MpIFwKICAgICAgICAgICAtZlBJQwogCi1M
REZMQUdTICs9ICQoc2hlbGwgeG1sMi1jb25maWcgLS1saWJzKSBcCi0gICAgICAgICAgICQoc2hl
bGwgY3VybC1jb25maWcgLS1saWJzKQorTERGTEFHUyArPSAkKHNoZWxsICQoWE1MMl9DT05GSUcp
IC0tbGlicykgXAorICAgICAgICAgICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tbGlicykKIAog
TElCWEVOQVBJX0hEUlMgPSAkKHdpbGRjYXJkIGluY2x1ZGUveGVuL2FwaS8qLmgpIGluY2x1ZGUv
eGVuL2FwaS94ZW5fYWxsLmgKIExJQlhFTkFQSV9PQkpTID0gJChwYXRzdWJzdCAlLmMsICUubywg
JCh3aWxkY2FyZCBzcmMvKi5jKSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBm
IHRvb2xzL200L2RlZmF1bHRfbGliLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L2RlZmF1bHRfbGliLm00CVR1ZSBKYW4gMTAgMTk6
MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDggQEAKK0FDX0RFRlVOKFtBWF9ERUZBVUxUX0xJ
Ql0sCitbQVNfSUYoW3Rlc3QgLWQgIiRwcmVmaXgvbGliNjQiXSwgWworICAgIExJQl9QQVRIPSJs
aWI2NCIKK10sWworICAgIExJQl9QQVRIPSJsaWIiCitdKQorQUNfU1VCU1QoTElCX1BBVEgpXSkK
KwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvZGlzYWJsZV9m
ZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisr
KyBiL3Rvb2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIg
KzAxMDAKQEAgLTAsMCArMSwxMyBAQAorQUNfREVGVU4oW0FYX0FSR19ESVNBQkxFX0FORF9FWFBP
UlRdLAorW0FDX0FSR19FTkFCTEUoWyQxXSwKKyAgICBBU19IRUxQX1NUUklORyhbLS1kaXNhYmxl
LSQxXSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieG5vIl0sIFsKKyAg
ICBheF9jdl8kMT0ibiIKK10sIFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAg
YXhfY3ZfJDE9InkiCitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Inki
CitdKQorJDE9JGF4X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAt
ciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvZW5hYmxlX2ZlYXR1cmUubTQKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvZW5hYmxlX2ZlYXR1
cmUubTQJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FD
X0RFRlVOKFtBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlRdLAorW0FDX0FSR19FTkFCTEUoWyQxXSwK
KyAgICBBU19IRUxQX1NUUklORyhbLS1lbmFibGUtJDFdLCBbJDJdKSkKKworQVNfSUYoW3Rlc3Qg
IngkZW5hYmxlXyQxIiA9ICJ4eWVzIl0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10sIFt0ZXN0ICJ4
JGVuYWJsZV8kMSIgPSAieG5vIl0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10sIFt0ZXN0IC16ICRh
eF9jdl8kMV0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10pCiskMT0kYXhfY3ZfJDEKK0FDX1NVQlNU
KCQxKV0pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9tNC9vY2Ft
bC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9vY2FtbC5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAsMCAr
MSwyNDEgQEAKK2RubCBhdXRvY29uZiBtYWNyb3MgZm9yIE9DYW1sCitkbmwgZnJvbSBodHRwOi8v
Zm9yZ2Uub2NhbWxjb3JlLm9yZy8KK2RubAorZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgUmlj
aGFyZCBXLk0uIEpvbmVzCitkbmwgQ29weXJpZ2h0IMKpIDIwMDkgICAgICBTdGVmYW5vIFphY2No
aXJvbGkKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IE9saXZpZXIgQW5kcmlldQorZG5sIENv
cHlyaWdodCDCqSAyMDAwLTIwMDUgSmVhbi1DaHJpc3RvcGhlIEZpbGxpw6J0cmUKK2RubCBDb3B5
cmlnaHQgwqkgMjAwMC0yMDA1IEdlb3JnZXMgTWFyaWFubworZG5sCitkbmwgRm9yIGRvY3VtZW50
YXRpb24sIHBsZWFzZSByZWFkIHRoZSBvY2FtbC5tNCBtYW4gcGFnZS4KKworQUNfREVGVU4oW0FD
X1BST0dfT0NBTUxdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2FtbGMKKyAgQUNfQ0hFQ0tf
VE9PTChbT0NBTUxDXSxbb2NhbWxjXSxbbm9dKQorCisgIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJu
byI7IHRoZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1uIC1lICdzfC4q
dmVyc2lvbiogKlwoLipcKSR8XDF8cCdgCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1sIHZlcnNp
b24gaXMgJE9DQU1MVkVSU0lPTl0pCisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQK
KyAgICAgaWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAk
T0NBTUxDIC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcg
JyAtZiA0YAorICAgICBlbHNlCisgICAgICAgIEFDX01TR19SRVNVTFQoW09DQU1MTElCIHByZXZp
b3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0Ll0pCisgICAgIGZpCisgICAgIEFDX01TR19SRVNVTFQo
W09DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUJdKQorCisgICAgIEFDX1NVQlNUKFtPQ0FN
TFZFUlNJT05dKQorICAgICBBQ19TVUJTVChbT0NBTUxMSUJdKQorCisgICAgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sb3B0CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MT1BUXSxbb2NhbWxvcHRdLFtu
b10pCisgICAgIE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8i
OyB0aGVuCisJQUNfTVNHX1dBUk4oW0Nhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21w
aWxhdGlvbiBvbmx5Ll0pCisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBz
ZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZF
UlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgQUNfTVNHX1JFU1VMVChbdmVy
c2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLl0pCisJICAgIE9D
QU1MT1BUPW5vCisJZWxzZQorCSAgICBPQ0FNTEJFU1Q9b3B0CisJZmkKKyAgICAgZmkKKworICAg
ICBBQ19TVUJTVChbT0NBTUxCRVNUXSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0
CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MQ0RPVE9QVF0sW29jYW1sYy5vcHRdLFtub10pCisg
ICAgIGlmIHRlc3QgIiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAk
T0NBTUxDRE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcg
YAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAg
IEFDX01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQg
ZGlzY2FyZGVkLl0pCisJZWxzZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAg
IGZpCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRP
Q0FNTE9QVCIgIT0gIm5vIiA7IHRoZW4KKwlBQ19DSEVDS19UT09MKFtPQ0FNTE9QVERPVE9QVF0s
W29jYW1sb3B0Lm9wdF0sW25vXSkKKwlpZiB0ZXN0ICIkT0NBTUxPUFRET1RPUFQiICE9ICJubyI7
IHRoZW4KKwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRET1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8
Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9
ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9uIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQuXSkKKwkgICBlbHNlCisJ
ICAgICAgT0NBTUxPUFQ9JE9DQU1MT1BURE9UT1BUCisJICAgZmkKKyAgICAgICAgZmkKKyAgICAg
ZmkKKworICAgICBBQ19TVUJTVChbT0NBTUxPUFRdKQorICBmaQorCisgIEFDX1NVQlNUKFtPQ0FN
TENdKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sIHRvcGxldmVsCisgIEFDX0NIRUNLX1RPT0wo
W09DQU1MXSxbb2NhbWxdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAKKyAgQUNf
Q0hFQ0tfVE9PTChbT0NBTUxERVBdLFtvY2FtbGRlcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZv
ciBvY2FtbG1rdG9wCisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtUT1BdLFtvY2FtbG1rdG9wXSxb
bm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgQUNfQ0hFQ0tfVE9PTChbT0NB
TUxNS0xJQl0sW29jYW1sbWtsaWJdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkb2MK
KyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxET0NdLFtvY2FtbGRvY10sW25vXSkKKworICAjIGNoZWNr
aW5nIGZvciBvY2FtbGJ1aWxkCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQlVJTERdLFtvY2FtbGJ1
aWxkXSxbbm9dKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTExFWF0sCitbZG5sCisg
ICMgY2hlY2tpbmcgZm9yIG9jYW1sbGV4CisgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVYXSxbb2Nh
bWxsZXhdLFtub10pCisgIGlmIHRlc3QgIiRPQ0FNTExFWCIgIT0gIm5vIjsgdGhlbgorICAgIEFD
X0NIRUNLX1RPT0woW09DQU1MTEVYRE9UT1BUXSxbb2NhbWxsZXgub3B0XSxbbm9dKQorICAgIGlm
IHRlc3QgIiRPQ0FNTExFWERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCU9DQU1MTEVYPSRPQ0FNTExF
WERPVE9QVAorICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtPQ0FNTExFWF0pCitdKQorCitBQ19E
RUZVTihbQUNfUFJPR19PQ0FNTFlBQ0NdLAorW2RubAorICBBQ19DSEVDS19UT09MKFtPQ0FNTFlB
Q0NdLFtvY2FtbHlhY2NdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTFlBQ0NdKQorXSkKKworCitB
Q19ERUZVTihbQUNfUFJPR19DQU1MUDRdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09D
QU1MXSlkbmwKKworICAjIGNoZWNraW5nIGZvciBjYW1scDQKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FN
TFA0XSxbY2FtbHA0XSxbbm9dKQorICBpZiB0ZXN0ICIkQ0FNTFA0IiAhPSAibm8iOyB0aGVuCisg
ICAgIFRNUFZFUlNJT049YCRDQU1MUDQgLXYgMj4mMXwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiAq
XCguKlwpJHxcMXxwJ2AKKyAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJT
SU9OIiA7IHRoZW4KKwlBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxj
XSkKKyAgICAgICAgQ0FNTFA0PW5vCisgICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtDQU1MUDRd
KQorCisgICMgY2hlY2tpbmcgZm9yIGNvbXBhbmlvbiB0b29scworICBBQ19DSEVDS19UT09MKFtD
QU1MUDRCT09UXSxbY2FtbHA0Ym9vdF0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T10s
W2NhbWxwNG9dLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9GXSxbY2FtbHA0b2ZdLFtu
b10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9PRl0sW2NhbWxwNG9vZl0sW25vXSkKKyAgQUNf
Q0hFQ0tfVE9PTChbQ0FNTFA0T1JGXSxbY2FtbHA0b3JmXSxbbm9dKQorICBBQ19DSEVDS19UT09M
KFtDQU1MUDRQUk9GXSxbY2FtbHA0cHJvZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0
Ul0sW2NhbWxwNHJdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFJGXSxbY2FtbHA0cmZd
LFtub10pCisgIEFDX1NVQlNUKFtDQU1MUDRCT09UXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9dKQor
ICBBQ19TVUJTVChbQ0FNTFA0T0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0T09GXSkKKyAgQUNfU1VC
U1QoW0NBTUxQNE9SRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRQUk9GXSkKKyAgQUNfU1VCU1QoW0NB
TUxQNFJdKQorICBBQ19TVUJTVChbQ0FNTFA0UkZdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJP
R19GSU5ETElCXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAg
IyBjaGVja2luZyBmb3Igb2NhbWxmaW5kCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRklORF0sW29j
YW1sZmluZF0sW25vXSkKKyAgQUNfU1VCU1QoW09DQU1MRklORF0pCitdKQorCisKK2RubCBUaGFu
a3MgdG8gSmltIE1leWVyaW5nIGZvciB3b3JraW5nIHRoaXMgbmV4dCBiaXQgb3V0IGZvciB1cy4K
K2RubCBYWFggV2Ugc2hvdWxkIGRlZmluZSBBU19UUl9TSCBpZiBpdCdzIG5vdCBkZWZpbmVkIGFs
cmVhZHkKK2RubCAoZWcuIGZvciBvbGQgYXV0b2NvbmYpLgorQUNfREVGVU4oW0FDX0NIRUNLX09D
QU1MX1BLR10sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfRklORExJQl0pZG5sCisKKyAg
QUNfTVNHX0NIRUNLSU5HKFtmb3IgT0NhbWwgZmluZGxpYiBwYWNrYWdlICQxXSkKKworICB1bnNl
dCBmb3VuZAorICB1bnNldCBwa2cKKyAgZm91bmQ9bm8KKyAgZm9yIHBrZyBpbiAkMSAkMiA7IGRv
CisgICAgaWYgJE9DQU1MRklORCBxdWVyeSAkcGtnID4vZGV2L251bGwgMj4vZGV2L251bGw7IHRo
ZW4KKyAgICAgIEFDX01TR19SRVNVTFQoW2ZvdW5kXSkKKyAgICAgIEFTX1RSX1NIKFtPQ0FNTF9Q
S0dfJDFdKT0kcGtnCisgICAgICBmb3VuZD15ZXMKKyAgICAgIGJyZWFrCisgICAgZmkKKyAgZG9u
ZQorICBpZiB0ZXN0ICIkZm91bmQiID0gIm5vIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtu
b3QgZm91bmRdKQorICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT1ubworICBmaQorCisgIEFD
X1NVQlNUKEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKSkKK10pCisKKworQUNfREVGVU4oW0FDX0NI
RUNLX09DQU1MX01PRFVMRV0sCitbZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIG1v
ZHVsZSAkMl0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKK29wZW4gJDMKK0VPRgorICB1
bnNldCBmb3VuZAorICBmb3IgJDEgaW4gJCQxICQ0IDsgZG8KKyAgICBpZiAkT0NBTUxDIC1jIC1J
ICIkJDEiIGNvbmZ0ZXN0Lm1sID4mNSAyPiY1IDsgdGhlbgorICAgICAgZm91bmQ9eWVzCisgICAg
ICBicmVhaworICAgIGZpCisgIGRvbmUKKworICBpZiB0ZXN0ICIkZm91bmQiIDsgdGhlbgorICAg
IEFDX01TR19SRVNVTFQoWyQkMV0pCisgIGVsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91
bmRdKQorICAgICQxPW5vCisgIGZpCisgIEFDX1NVQlNUKFskMV0pCitdKQorCisKK2RubCBYWFgg
Q3Jvc3MtY29tcGlsaW5nCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfV09SRF9TSVpFXSwKK1tk
bmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisgIEFDX01TR19DSEVDS0lORyhb
Zm9yIE9DYW1sIGNvbXBpbGVyIHdvcmQgc2l6ZV0pCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9G
CisgIHByaW50X2VuZGxpbmUgKHN0cmluZ19vZl9pbnQgU3lzLndvcmRfc2l6ZSkKKyAgRU9GCisg
IE9DQU1MX1dPUkRfU0laRT1gJE9DQU1MIGNvbmZ0ZXN0Lm1sYAorICBBQ19NU0dfUkVTVUxUKFsk
T0NBTUxfV09SRF9TSVpFXSkKKyAgQUNfU1VCU1QoW09DQU1MX1dPUkRfU0laRV0pCitdKQorCitB
Q19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfT1NfVFlQRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FD
X1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW09DYW1sIFN5cy5vc190eXBlXSkK
KworICBjYXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9zdHJpbmcoU3lzLm9zX3R5cGUp
OzsKK0VPRgorCisgIE9DQU1MX09TX1RZUEU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNH
X1JFU1VMVChbJE9DQU1MX09TX1RZUEVdKQorICBBQ19TVUJTVChbT0NBTUxfT1NfVFlQRV0pCitd
KQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvcGF0aF9vcl9m
YWlsLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL200L3BhdGhfb3JfZmFpbC5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAK
QEAgLTAsMCArMSw2IEBACitBQ19ERUZVTihbQVhfUEFUSF9QUk9HX09SX0ZBSUxdLAorW0FDX1BB
VEhfUFJPRyhbJDFdLCBbJDJdLCBbbm9dKQoraWYgdGVzdCB4IiR7JDF9IiA9PSB4Im5vIiAKK3Ro
ZW4KKyAgICBBQ19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kICQyLCBwbGVhc2UgaW5zdGFsbCAk
Ml0pCitmaV0pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9tNC9w
eXRob25fZGV2ZWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIvdG9vbHMvbTQvcHl0aG9uX2RldmVsLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAx
MiArMDEwMApAQCAtMCwwICsxLDE4IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVM
XSwKK1tBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAn
CitpbXBvcnQgb3MucGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRo
LmV4aXN0cyhwICsgIi9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5
cy5leGl0KDEpCisnID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3Ro
ZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2
ZWwgcGFja2FnZSBub3QgZm91bmRdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitm
aV0pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9tNC9weXRob25f
dmVyc2lvbi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi90b29scy9tNC9weXRob25fdmVyc2lvbi5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIg
KzAxMDAKQEAgLTAsMCArMSwxMiBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9O
XSwKK1tBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQ
WVRIT04gLWMgJ2ltcG9ydCBzeXM7IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwg
JDIpIikpJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1g
JFBZVEhPTiAtViAyPiYxYAorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJS
T1IoCisgICAgICAgIFskcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJl
ZCB2ZXJzaW9uIGlzICQxLiQyXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmld
KQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvcHl0aG9uX3ht
bC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9weXRob25feG1sLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAt
MCwwICsxLDEwIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX1hNTF0sCitbQUNfTVNHX0NI
RUNLSU5HKFtmb3IgcHl0aG9uIHhtbC5kb20ubWluaWRvbV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0
IHhtbC5kb20ubWluaWRvbSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNH
X1JFU1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUihbVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5t
aW5pZG9tIG1vZHVsZV0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL200L3NldF9jZmxhZ3NfbGRm
bGFncy5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysg
Yi90b29scy9tNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQJVHVlIEphbiAxMCAxOToxMzowMSAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMjAgQEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxBR1NdLAorW2ZvciBj
ZmxhZyBpbiAkUFJFUEVORF9JTkNMVURFUworZG8KKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRj
ZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCitkbworICAgIFBSRVBFTkRf
TERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitmb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURF
UworZG8KKyAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBp
biAkQVBQRU5EX0xJQgorZG8KKyAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25l
CitDRkxBR1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgorTERGTEFH
Uz0iJFBSRVBFTkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1MiXSkKKwpkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvdWRldi5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC91ZGV2Lm00
CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDMyIEBACitBQ19ERUZV
TihbQVhfQ0hFQ0tfVURFVl0sCitbaWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIK
K3RoZW4KKyAgICBBQ19QQVRIX1BST0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAg
aWYgdGVzdCB4IiR7VURFVkFETX0iID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFU
SF9QUk9HKFtVREVWSU5GT10sIFt1ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIk
e1VERVZJTkZPfSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VS
Uk9SKAorICAgICAgICAgICAgICAgIFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZv
LCBwbGVhc2UgaW5zdGFsbCB1ZGV2XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtV
REVWSU5GT30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2
ZXI9YCR7VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAg
aWYgdGVzdCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9H
KFtIT1RQTFVHXSwgW2hvdHBsdWddLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVH
fSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2
IGlzIHRvbyBvbGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZp
CisgICAgZmkKK2Vsc2UKKyAgICBBQ19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwg
W25vXSkKKyAgICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAg
ICAgICBBQ19NU0dfRVJST1IoW05vdCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQg
dm5kXSkKKyAgICBmaQorZmkKK10pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIw
ZiB2ZXJzaW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3ZlcnNpb24uc2gJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAg
KzEsNCBAQAorIyEvYmluL3NoCitNQUpPUj1gZ3JlcCAiZXhwb3J0IFhFTl9WRVJTSU9OIiAkMSB8
IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdyZXAgImV4cG9ydCBYRU5fU1VC
VkVSU0lPTiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK3ByaW50ZiAiJWQuJWQi
ICRNQUpPUiAkTUlOT1IKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhb-00018l-8r; Mon, 16 Jan 2012 11:26:15 +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 1Rm8Jn-0002K6-OU
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:27:08 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326565620!9140454!1
X-Originating-IP: [32.97.182.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NiA9PiA1MjM5MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12406 invoked from network); 14 Jan 2012 18:27:01 -0000
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:27:01 -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>; Sat, 14 Jan 2012 13:27:00 -0500
Received: from d01relay05.pok.ibm.com (9.56.227.237)
	by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:26:58 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIQw9i255554
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:26:58 -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
	q0EIQuwI021888
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 16:26:58 -0200
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIQg72021192; Sat, 14 Jan 2012 16:26:44 -0200
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, X86 <x86@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Rob Landley <rlandley@parallels.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:56:46 +0530
Message-Id: <20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-1976-0000-0000-00000980BFF1
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 4/5] kvm : pv-ticketlocks support for
	linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Extends Linux guest running on KVM hypervisor to support pv-ticketlocks. 

During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
 support for pv-ticketlocks is registered via pv_lock_ops.

Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.

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 7a94987..cf5327c 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -195,10 +195,20 @@ 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)
+
 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..ec55a0b 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,250 @@ 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, u32 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 by its apicid*/
+static inline void kvm_kick_cpu(int apicid)
+{
+	kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
+}
+
+/* Kick vcpu waiting on @lock->head to reach value @ticket */
+static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
+{
+	int cpu;
+	int apicid;
+
+	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);
+			apicid = per_cpu(x86_cpu_to_apicid, cpu);
+			kvm_kick_cpu(apicid);
+			break;
+		}
+	}
+}
+
+/*
+ * Setup pv_lock_ops to exploit KVM_FEATURE_PVLOCK_KICK if present.
+ */
+void __init kvm_spinlock_init(void)
+{
+	if (!kvm_para_available())
+		return;
+	/* Does host kernel support KVM_FEATURE_PVLOCK_KICK? */
+	if (!kvm_para_has_feature(KVM_FEATURE_PVLOCK_KICK))
+		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/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c7b05fc..4d7a950 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
 
 	local_irq_disable();
 
-	if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
-	    || need_resched() || signal_pending(current)) {
+	if (vcpu->mode == EXITING_GUEST_MODE
+		 || (vcpu->requests & ~(1UL<<KVM_REQ_PVLOCK_KICK))
+		 || need_resched() || signal_pending(current)) {
 		vcpu->mode = OUTSIDE_GUEST_MODE;
 		smp_wmb();
 		local_irq_enable();
@@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
 		!vcpu->arch.apf.halted)
 		|| !list_empty_careful(&vcpu->async_pf.done)
 		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
+		|| kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
 		|| atomic_read(&vcpu->arch.nmi_queued) ||
 		(kvm_arch_interrupt_allowed(vcpu) &&
 		 kvm_cpu_has_interrupt(vcpu));


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhe-0001Ai-6Z; Mon, 16 Jan 2012 11:26:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmdkP-0002PZ-OL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 04:00:41 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326686434!8473657!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2513 invoked from network); 16 Jan 2012 04:00:35 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 04:00:35 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 0107189471;
	Mon, 16 Jan 2012 05:00:34 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120116035114.GI9129@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 05:00:31 +0100
Message-Id: <5E0038B3-3830-4668-B4BB-781976710ED1@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
	<20120116035114.GI9129@linux.vnet.ibm.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 04:51, Srivatsa Vaddagiri wrote:

> * Alexander Graf <agraf@suse.de> [2012-01-16 04:23:24]:
> 
>>> +5. KVM_HC_KICK_CPU
>>> +------------------------
>>> +value: 5
>>> +Architecture: x86
>>> +Purpose: Hypercall used to wakeup a vcpu from HLT state
>>> +
>>> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
>>> +kernel mode for an event to occur (ex: a spinlock to become available)
>>> +can execute HLT instruction once it has busy-waited for more than a
>>> +threshold time-interval. Execution of HLT instruction would cause
>>> +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
>>> +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
>>> +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
>>> +wokenup.
>> 
>> The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu.
> 
> Hmm ..the hypercall does not allow a vcpu to yield. It just allows some
> target vcpu to be prodded/wokenup, after which vcpu continues execution.
> 
> Note that semantics of this hypercall is different from the hypercall on which
> PPC pv-spinlock (__spin_yield()) is currently dependent. This is mainly because 
> of ticketlocks on x86 (which does not allow us to easily store owning cpu
> details in lock word itself).

Yes, sorry for not being more exact in my wording. It is a directed yield(). Not like the normal old style thing that just says "I'm done, get some work to someone else" but more something like "I'm done, get some work to this specific guy over there" :).


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1RmkhY-000183-NU; Mon, 16 Jan 2012 11:26:12 +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 1RkvGe-0007Zl-VJ
	for xen-devel@lists.xensource.com; Wed, 11 Jan 2012 10:18:54 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326277126!7878092!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam size
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8984 invoked from network); 11 Jan 2012 10:18:46 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	11 Jan 2012 10:18:46 -0000
Received: by wibhq7 with SMTP id hq7so659313wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 11 Jan 2012 02:18: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:user-agent:date:from:to:cc;
	bh=8fp/jyGmncNMTx9RfyA6i2VQElLshTHKQ9x/sXrKDxk=;
	b=MEIlfFJ0Wqzw1fdB9EZw9o3OElfLoN2OTkT+J3fVUEagmGDD00kLVPQSeFd/yszPUy
	gV2xnV1OADIXtDqLr/nxV6h3foYx703YzmIwqz+JoWi7XisBBsmRcMyMHoAWYKK5eBwt
	ixulhu22nFLd4S7YVws+qcA1+4Nzj1SEBPRlg=
Received: by 10.180.106.130 with SMTP id gu2mr18229836wib.6.1326277125506;
	Wed, 11 Jan 2012 02:18:45 -0800 (PST)
Received: from build.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id 8sm3933621wiw.4.2012.01.11.02.18.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 11 Jan 2012 02:18:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d665d94dab0f2788fe431ee13343e3b78b323b11
Message-Id: <d665d94dab0f2788fe43.1326219720@build.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 10 Jan 2012 19:22:00 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com, JBeulich@suse.com
Subject: [Xen-devel] [PATCH v3] build: add autoconf to replace custom checks
	in tools/check
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1QGVu
dGVsLnVwYy5lZHU+CiMgRGF0ZSAxMzI2MjE5MTgxIC0zNjAwCiMgTm9kZSBJRCBkNjY1ZDk0ZGFi
MGYyNzg4ZmU0MzFlZTEzMzQzZTNiNzhiMzIzYjExCiMgUGFyZW50ICA0MDg2ZTQ4MTE1NDdkZGZm
YjlhNTNmYmYyZWZiNmMyZmE0MzZiNzBhCmJ1aWxkOiBhZGQgYXV0b2NvbmYgdG8gcmVwbGFjZSBj
dXN0b20gY2hlY2tzIGluIHRvb2xzL2NoZWNrCgpBZGRlZCBhdXRvdG9vbHMgbWFnaWMgdG8gcmVw
bGFjZSBjdXN0b20gY2hlY2sgc2NyaXB0cy4gVGhlIHByZXZpb3VzCmNoZWNrcyBoYXZlIGJlZW4g
cG9ydGVkIHRvIGF1dG9jb25mLCBhbmQgc29tZSBhZGRpdGlvbmFsIG9uZXMgaGF2ZQpiZWVuIGFk
ZGVkIChwbHVzIHRoZSBzdWdnZXN0aW9ucyBmcm9tIHJ1bm5pbmcgYXV0b3NjYW4pLiBUd28gZmls
ZXMgYXJlCmNyZWF0ZWQgYXMgYSByZXN1bHQgZnJvbSBleGVjdXRpbmcgY29uZmlndXJlIHNjcmlw
dCwKY29uZmlnL0F1dG9jb25mLm1rIGFuZCBjb25maWcuaC4KCmNvbmYvVG9vbHMubWsgaXMgaW5j
bHVkZWQgYnkgdG9vbHMvUnVsZXMubWssIGFuZCBjb250YWlucyBtb3N0IG9mIHRoZQpvcHRpb25z
IHByZXZpb3VzbHkgZGVmaW5lZCBpbiAuY29uZmlnLCB0aGF0IGNhbiBub3cgYmUgc2V0IHBhc3Np
bmcKcGFyYW1ldGVycyBvciBkZWZpbmluZyBlbnZpcm9ubWVudCB2YXJpYWJsZXMgd2hlbiBleGVj
dXRpbmcgY29uZmlndXJlCnNjcmlwdC4KCmNvbmZpZy5oIGlzIHN0aWxsIG5vdCB1c2VkIGFueXdo
ZXJlLCBhbmQgaXMgYXV0b21hdGljYWxseSBjcmVhdGVkIGJ5CmF1dG9oZWFkZXIsIGFsdG91Z2gg
dGhpcyBtaWdoIGNoYW5nZSB3aGVuIHdlIHN0YXJ0IHRvIGluY2x1ZGUgdGhpcwpmaWxlLgoKSnVz
dCBhIGZpcnN0IHJlbGVhc2UsIGFuZCBzaW5jZSBpdCdzIG15IGZpcnN0IGF1dG9jb25mIHNjcmlw
dCBJIGd1ZXNzCnRoZXJlIHdpbGwgYmUgbWFueSB0aGluZ3MgdG8gcG9saXNoIGhlcmUuLi4gUGxl
YXNlIHJldmlldyBhbmQgY29tbWVudC4KCkNoYW5nZXMgc2luY2UgdjI6CgogKiBDaGFuZ2VkIG9y
ZGVyIG9mIGNvbmZpZy9Ub29scy5tayBpbmNsdWRlLgoKICogQWRkZWQgIi1lIiB0byBhdXRvZ2Vu
LnNoIHNoZWJhbmcuCgogKiBBZGRlZCBuZWNlc3NhcnkgZmlsZXMgKGNvbmZpZy4qKSBhbmQgb3V0
cHV0IGZyb20gQXV0b2hlYWRlciBhbmQKICAgQXV0b2NvbmYuCgogKiBSZW1vdmVkIEF1dG9jb25m
IGZyb20gYnVpbGQgZGVwZW5kZW5jaWVzIGFuZCB1cGRhdGVkIFJFQURNRS4KCkNoYW5nZXMgc2lu
Y2UgdjE6CgogKiBNb3ZlZCBhdXRvY29uZiBzdHVmZiBpbnNpZGUgdG9vbHMgZm9sZGVyLgoKICog
QWRkIE1ha2VmaWxlIHJ1bGVzIGZvciBjbGVhbmluZy4KCiAqIFJlbW92ZWQgQXV0b21ha2UgZGVw
ZW5kZW5jeS4KCiAqIENyZWF0ZSBhdXRvZ2VuLnNoIHRvIGF1dG9tYXRpY2FsbHkgY3JlYXRlIGNv
bmZpZ3VyZSBzY3JpcHQgd2hlbgogICBidWlsZGluZyBmcm9tIHNvdXJjZSByZXBvc2l0b3J5LgoK
ICogQ2FjaGVkIHZhbHVlcyBvZiBvcHRpb25zIHBhc3NlZCBmcm9tIGNvbW1hbmQgbGluZS4KCiAq
IEFkZCBuZWNlc3NhcnkgaWdub3JlcyB0byAuaGdpZ25vcmUuCgogKiBBZGRlZCBBdXRvY29uZiB0
byB0aGUgbGlzdCBvZiBkZXBlbmRlbmNpZXMuCgogKiBDaGFuZ2VkIGh5cGVuIHRvIHVuZGVyc2Nv
cmUgaW4gWE1MMiBhbmQgQ1VSTCB2YXJpYWJsZSBuYW1lcy4KCiAqIEFkZGVkIHNjcmlwdCB0byBn
ZXQgdmVyc2lvbiBmcm9tIHhlbi9NYWtlZmlsZS4KCiAqIFNldCBPY2FtbCB0b29scyB0byBvcHRp
b25hbC4KCiAqIEFkZGVkIHByb2NlZGVuY2Ugb2YgbTQvb2NhbWwubTQuCgpTaWduZWQtb2ZmLWJ5
OiBSb2dlciBQYXUgTW9ubmUgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PgoKZGlmZiAtciA0MDg2
ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIC5oZ2lnbm9yZQotLS0gYS8uaGdpZ25vcmUJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiLy5oZ2lnbm9yZQlUdWUgSmFuIDEwIDE5OjEz
OjAxIDIwMTIgKzAxMDAKQEAgLTMwOCw2ICszMDgsMTIgQEAKIF50b29scy9vY2FtbC9saWJzL3hs
L3hlbmxpZ2h0XC5tbCQKIF50b29scy9vY2FtbC9saWJzL3hsL3hlbmxpZ2h0XC5tbGkkCiBedG9v
bHMvb2NhbWwveGVuc3RvcmVkL294ZW5zdG9yZWQkCitedG9vbHMvYXV0b200dGVcLmNhY2hlJAor
XnRvb2xzL2NvbmZpZ1wuaCQKK150b29scy9jb25maWdcLmxvZyQKK150b29scy9jb25maWdcLnN0
YXR1cyQKK150b29scy9jb25maWdcLmNhY2hlJAorXmNvbmZpZy9Ub29sc1wubWskCiBeeGVuL1wu
YmFubmVyLiokCiBeeGVuL0JMT0ckCiBeeGVuL1N5c3RlbS5tYXAkCmRpZmYgLXIgNDA4NmU0ODEx
NTQ3IC1yIGQ2NjVkOTRkYWIwZiBDb25maWcubWsKLS0tIGEvQ29uZmlnLm1rCVRodSBKYW4gMDUg
MTc6MjU6MjMgMjAxMiArMDAwMAorKysgYi9Db25maWcubWsJVHVlIEphbiAxMCAxOToxMzowMSAy
MDEyICswMTAwCkBAIC03MCw5ICs3MCw2IEBAIEVYVFJBX0lOQ0xVREVTICs9ICQoRVhUUkFfUFJF
RklYKS9pbmNsdWQKIEVYVFJBX0xJQiArPSAkKEVYVFJBX1BSRUZJWCkvJChMSUJMRUFGRElSKQog
ZW5kaWYKIAotQklTT04JPz0gYmlzb24KLUZMRVgJPz0gZmxleAotCiBQWVRIT04gICAgICA/PSBw
eXRob24KIFBZVEhPTl9QUkVGSVhfQVJHID89IC0tcHJlZml4PSIkKFBSRUZJWCkiCiAjIFRoZSBh
Ym92ZSByZXF1aXJlcyB0aGF0IFBSRUZJWCBjb250YWlucyAqbm8gc3BhY2VzKi4gVGhpcyB2YXJp
YWJsZSBpcyBoZXJlCkBAIC0xNzUsMjIgKzE3Miw5IEBAIENGTEFHUyArPSAkKGZvcmVhY2ggaSwg
JChQUkVQRU5EX0lOQ0xVREUKIEFQUEVORF9MREZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVO
RF9MSUIpLCAtTCQoaSkpCiBBUFBFTkRfQ0ZMQUdTICs9ICQoZm9yZWFjaCBpLCAkKEFQUEVORF9J
TkNMVURFUyksIC1JJChpKSkKIAotQ0hFQ0tfTElCID0gJChFWFRSQV9MSUIpICQoUFJFUEVORF9M
SUIpICQoQVBQRU5EX0xJQikKLUNIRUNLX0lOQ0xVREVTID0gJChFWFRSQV9JTkNMVURFUykgJChQ
UkVQRU5EX0lOQ0xVREVTKSAkKEFQUEVORF9JTkNMVURFUykKLQogRU1CRURERURfRVhUUkFfQ0ZM
QUdTIDo9IC1ub3BpZSAtZm5vLXN0YWNrLXByb3RlY3RvciAtZm5vLXN0YWNrLXByb3RlY3Rvci1h
bGwKIEVNQkVEREVEX0VYVFJBX0NGTEFHUyArPSAtZm5vLWV4Y2VwdGlvbnMKIAotIyBFbmFibGUg
WFNNIHNlY3VyaXR5IG1vZHVsZSAoYnkgZGVmYXVsdCwgRmxhc2spLgotWFNNX0VOQUJMRSA/PSBu
Ci1GTEFTS19FTkFCTEUgPz0gJChYU01fRU5BQkxFKQotCi0jIERvd25sb2FkIEdJVCByZXBvc2l0
b3JpZXMgdmlhIEhUVFAgb3IgR0lUJ3Mgb3duIHByb3RvY29sPwotIyBHSVQncyBwcm90b2NvbCBp
cyBmYXN0ZXIgYW5kIG1vcmUgcm9idXN0LCB3aGVuIGl0IHdvcmtzIGF0IGFsbCAoZmlyZXdhbGxz
Ci0jIG1heSBibG9jayBpdCkuIFdlIG1ha2UgaXQgdGhlIGRlZmF1bHQsIGJ1dCBpZiB5b3VyIEdJ
VCByZXBvc2l0b3J5IGRvd25sb2FkcwotIyBmYWlsIG9yIGhhbmcsIHBsZWFzZSBzcGVjaWZ5IEdJ
VF9IVFRQPXkgaW4geW91ciBlbnZpcm9ubWVudC4KLUdJVF9IVFRQID89IG4KLQogWEVOX0VYVEZJ
TEVTX1VSTD1odHRwOi8veGVuYml0cy54ZW5zb3VyY2UuY29tL3hlbi1leHRmaWxlcwogIyBBbGwg
dGhlIGZpbGVzIGF0IHRoYXQgbG9jYXRpb24gd2VyZSBkb3dubG9hZGVkIGZyb20gZWxzZXdoZXJl
IG9uCiAjIHRoZSBpbnRlcm5ldC4gIFRoZSBvcmlnaW5hbCBkb3dubG9hZCBVUkwgaXMgcHJlc2Vy
dmVkIGFzIGEgY29tbWVudApAQCAtMjIyLDE3ICsyMDYsMyBAQCBRRU1VX1RBRyA/PSBiYjM2ZDYz
MmU0Y2FiZjQ3ODgyYWRmZjA3YTQ1CiAjIE5vdGUgdGhhdCB1c2luZyBTZWFCSU9TIHJlcXVpcmVz
IHRoZSB1c2UgdGhlIHVwc3RyZWFtIHFlbXUgYXMgdGhlCiAjIGRldmljZSBtb2RlbC4KIFNFQUJJ
T1NfRElSID89IAotCi0jIE9wdGlvbmFsIGNvbXBvbmVudHMKLVhFTlNUQVRfWEVOVE9QICAgICA/
PSB5Ci1WVFBNX1RPT0xTICAgICAgICAgPz0gbgotTElCWEVOQVBJX0JJTkRJTkdTID89IG4KLVBZ
VEhPTl9UT09MUyAgICAgICA/PSB5Ci1PQ0FNTF9UT09MUyAgICAgICAgPz0geQotQ09ORklHX01J
TklURVJNICAgID89IG4KLUNPTkZJR19MT01PVU5UICAgICA/PSBuCi1DT05GSUdfU1lTVEVNX0xJ
QkFJTyA/PSB5Ci0KLWlmZXEgKCQoT0NBTUxfVE9PTFMpLHkpCi1PQ0FNTF9UT09MUyA6PSAkKHNo
ZWxsIG9jYW1sb3B0IC12ID4gL2Rldi9udWxsIDI+JjEgJiYgZWNobyAieSIgfHwgZWNobyAibiIp
Ci1lbmRpZgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgTWFrZWZpbGUKLS0t
IGEvTWFrZWZpbGUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL01ha2VmaWxl
CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtNDAsMTEgKzQwLDkgQEAgZGlzdDog
REVTVERJUj0kKERJU1RESVIpL2luc3RhbGwKIGRpc3Q6IGRpc3QteGVuIGRpc3Qta2VybmVscyBk
aXN0LXRvb2xzIGRpc3Qtc3R1YmRvbSBkaXN0LWRvY3MgZGlzdC1taXNjCiAKIGRpc3QtbWlzYzoK
LQkkKElOU1RBTExfRElSKSAkKERJU1RESVIpL2NoZWNrCiAJJChJTlNUQUxMX0RBVEEpIC4vQ09Q
WUlORyAkKERJU1RESVIpCiAJJChJTlNUQUxMX0RBVEEpIC4vUkVBRE1FICQoRElTVERJUikKIAkk
KElOU1RBTExfUFJPRykgLi9pbnN0YWxsLnNoICQoRElTVERJUikKLQkkKElOU1RBTExfUFJPRykg
dG9vbHMvY2hlY2svY2hrIHRvb2xzL2NoZWNrL2NoZWNrXyogdG9vbHMvY2hlY2svZnVuY3Muc2gg
JChESVNURElSKS9jaGVjawogZGlzdC0lOiBERVNURElSPSQoRElTVERJUikvaW5zdGFsbAogZGlz
dC0lOiBpbnN0YWxsLSUKIAlAOiAjIGRvIG5vdGhpbmcKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIg
ZDY2NWQ5NGRhYjBmIFJFQURNRQotLS0gYS9SRUFETUUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEy
ICswMDAwCisrKyBiL1JFQURNRQlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTg3
LDkgKzg3LDEzIEBAIDIuIGNkIHRvIHhlbi11bnN0YWJsZSAob3Igd2hhdGV2ZXIgeW91IHMKIDMu
IEZvciB0aGUgdmVyeSBmaXJzdCBidWlsZCwgb3IgaWYgeW91IHdhbnQgdG8gZGVzdHJveSBidWls
ZCB0cmVlcywKICAgIHBlcmZvcm0gdGhlIGZvbGxvd2luZyBzdGVwczoKIAorICAgICMgLi9jb25m
aWd1cmUKICAgICAjIG1ha2Ugd29ybGQKICAgICAjIG1ha2UgaW5zdGFsbAogCisgICBJZiB5b3Ug
d2FudCwgeW91IGNhbiBydW4gLi9jb25maWd1cmUgLS1oZWxwIHRvIHNlZSB0aGUgbGlzdCBvZgor
ICAgb3B0aW9ucyBhdmFpbGFibGUgb3B0aW9ucyB3aGVuIGJ1aWxkaW5nIGFuZCBpbnN0YWxsaW5n
IFhlbi4KKwogICAgVGhpcyB3aWxsIGNyZWF0ZSBhbmQgaW5zdGFsbCBvbnRvIHRoZSBsb2NhbCBt
YWNoaW5lLiBJdCB3aWxsIGJ1aWxkCiAgICB0aGUgeGVuIGJpbmFyeSAoeGVuLmd6KSwgdGhlIHRv
b2xzIGFuZCB0aGUgZG9jdW1lbnRhdGlvbi4KIApkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1
ZDk0ZGFiMGYgYXV0b2dlbi5zaAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3
MCArMDAwMAorKysgYi9hdXRvZ2VuLnNoCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApA
QCAtMCwwICsxLDkgQEAKKyMhL2Jpbi9zaCAtZQorcm0gLXJmIGNvbmZpZ3VyZQorY2QgdG9vbHMK
K2F1dG9oZWFkZXIKK2F1dG9jb25mCitjZCAuLgorZWNobyAiIyEvYmluL3NoIC1lIiA+PiBjb25m
aWd1cmUKK2VjaG8gImNkIHRvb2xzICYmIC4vY29uZmlndXJlIFwkQCIgPj4gY29uZmlndXJlCitj
aG1vZCAreCBjb25maWd1cmUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIGNv
bmZpZy9Ub29scy5tay5pbgotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCAr
MDAwMAorKysgYi9jb25maWcvVG9vbHMubWsuaW4JVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsNTAgQEAKKyMgUHJlZml4IGFuZCBpbnN0YWxsIGZvbGRlcgorUFJFRklY
ICAgICAgICAgICAgICA6PSBAcHJlZml4QAorTElCTEVBRkRJUl94ODZfNjQgICA6PSBATElCX1BB
VEhACisKKyMgQSBkZWJ1ZyBidWlsZCBvZiB0b29scz8KK2RlYnVnICAgICAgICAgICAgICAgOj0g
QGRlYnVnQAorCisjIFRvb2xzIHBhdGgKK0JJU09OICAgICAgICAgICAgICAgOj0gQEJJU09OQAor
RkxFWCAgICAgICAgICAgICAgICA6PSBARkxFWEAKK1BZVEhPTiAgICAgICAgICAgICAgOj0gQFBZ
VEhPTkAKK1BZVEhPTl9QQVRIICAgICAgICAgOj0gQFBZVEhPTlBBVEhACitQRVJMICAgICAgICAg
ICAgICAgIDo9IEBQRVJMQAorQlJDVEwgICAgICAgICAgICAgICA6PSBAQlJDVExACitJUCAgICAg
ICAgICAgICAgICAgIDo9IEBJUEAKK0NVUkxfQ09ORklHICAgICAgICAgOj0gQENVUkxACitYTUwy
X0NPTkZJRyAgICAgICAgIDo9IEBYTUxACitCQVNIICAgICAgICAgICAgICAgIDo9IEBCQVNIQAor
WEdFVFRURVhUICAgICAgICAgICA6PSBAWEdFVFRFWFRACisKKyMgRXh0cmEgZm9sZGVyIGZvciBs
aWJzL2luY2x1ZGVzCitQUkVQRU5EX0lOQ0xVREVTICAgIDo9IEBQUkVQRU5EX0lOQ0xVREVTQAor
UFJFUEVORF9MSUIgICAgICAgICA6PSBAUFJFUEVORF9MSUJACitBUFBFTkRfSU5DTFVERVMgICAg
IDo9IEBBUFBFTkRfSU5DTFVERVNACitBUFBFTkRfTElCICAgICAgICAgIDo9IEBBUFBFTkRfTElC
QAorCisjIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBkZWZhdWx0LCBGbGFzaykuCitY
U01fRU5BQkxFICAgICAgICAgIDo9IEB4c21ACitGTEFTS19FTkFCTEUgICAgICAgIDo9IEB4c21A
CisKKyMgRG93bmxvYWQgR0lUIHJlcG9zaXRvcmllcyB2aWEgSFRUUCBvciBHSVQncyBvd24gcHJv
dG9jb2w/CisjIEdJVCdzIHByb3RvY29sIGlzIGZhc3RlciBhbmQgbW9yZSByb2J1c3QsIHdoZW4g
aXQgd29ya3MgYXQgYWxsIChmaXJld2FsbHMKKyMgbWF5IGJsb2NrIGl0KS4gV2UgbWFrZSBpdCB0
aGUgZGVmYXVsdCwgYnV0IGlmIHlvdXIgR0lUIHJlcG9zaXRvcnkgZG93bmxvYWRzCisjIGZhaWwg
b3IgaGFuZywgcGxlYXNlIHNwZWNpZnkgR0lUX0hUVFA9eSBpbiB5b3VyIGVudmlyb25tZW50Lgor
R0lUX0hUVFAgICAgICAgICAgICA6PSBAZ2l0aHR0cEAKKworIyBPcHRpb25hbCBjb21wb25lbnRz
CitYRU5TVEFUX1hFTlRPUCAgICAgIDo9IEBtb25pdG9yc0AKK1ZUUE1fVE9PTFMgICAgICAgICAg
Oj0gQHZ0cG1ACitMSUJYRU5BUElfQklORElOR1MgIDo9IEB4YXBpQAorUFlUSE9OX1RPT0xTICAg
ICAgICA6PSBAcHl0aG9udG9vbHNACitPQ0FNTF9UT09MUyAgICAgICAgIDo9IEBvY2FtbHRvb2xz
QAorQ09ORklHX01JTklURVJNICAgICA6PSBAbWluaXRlcm1ACitDT05GSUdfTE9NT1VOVCAgICAg
IDo9IEBsb21vdW50QAorCisjU3lzdGVtIG9wdGlvbnMKK0NPTkZJR19TWVNURU1fTElCQUlPOj0g
QHN5c3RlbV9haW9ACitDT05GSUdfTElCSUNPTlYgICAgIDo9IEBsaWJpY29udkAKK0NPTkZJR19H
Q1JZUFQgICAgICAgOj0gQGxpYmdjcnlwdEAKK0NPTkZJR19FWFQyRlMgICAgICAgOj0gQGxpYmV4
dDJmc0AKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIGNvbmZpZ3VyZQotLS0g
L2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi9jb25maWd1cmUJ
VHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMiBAQAorIyEvYmluL3No
IC1lCitjZCB0b29scyAmJiAuL2NvbmZpZ3VyZSAkQApkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBk
NjY1ZDk0ZGFiMGYgdG9vbHMvTWFrZWZpbGUKLS0tIGEvdG9vbHMvTWFrZWZpbGUJVGh1IEphbiAw
NSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL01ha2VmaWxlCVR1ZSBKYW4gMTAgMTk6
MTM6MDEgMjAxMiArMDEwMApAQCAtNiw3ICs2LDYgQEAgU1VCRElSUy1saWJhaW8gOj0gbGliYWlv
CiBlbmRpZgogCiBTVUJESVJTLXkgOj0KLVNVQkRJUlMteSArPSBjaGVjawogU1VCRElSUy15ICs9
IGluY2x1ZGUKIFNVQkRJUlMteSArPSBsaWJ4YwogU1VCRElSUy15ICs9IGZsYXNrCkBAIC03Niw2
ICs3NSw4IEBAIGNsZWFuOiBzdWJkaXJzLWNsZWFuCiAuUEhPTlk6IGRpc3RjbGVhbgogZGlzdGNs
ZWFuOiBzdWJkaXJzLWRpc3RjbGVhbgogCXJtIC1yZiBpb2VtdS1kaXIgaW9lbXUtcmVtb3RlCisJ
cm0gLXJmIC4uL2NvbmZpZy9Ub29scy5tayBjb25maWcuaCBjb25maWcubG9nIGNvbmZpZy5zdGF0
dXMgXAorICAgICAgICAgICAgICAgY29uZmlnLmNhY2hlIGF1dG9tNHRlLmNhY2hlCiAKIGlmbmVx
ICgkKFhFTl9DT01QSUxFX0FSQ0gpLCQoWEVOX1RBUkdFVF9BUkNIKSkKIElPRU1VX0NPTkZJR1VS
RV9DUk9TUyA/PSAtLWNwdT0kKFhFTl9UQVJHRVRfQVJDSCkgXApkaWZmIC1yIDQwODZlNDgxMTU0
NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvUnVsZXMubWsKLS0tIGEvdG9vbHMvUnVsZXMubWsJVGh1
IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL1J1bGVzLm1rCVR1ZSBKYW4g
MTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtNCw2ICs0LDcgQEAKIGFsbDoKIAogaW5jbHVkZSAk
KFhFTl9ST09UKS9Db25maWcubWsKK2luY2x1ZGUgJChYRU5fUk9PVCkvY29uZmlnL1Rvb2xzLm1r
CiAKIGV4cG9ydCBfSU5TVEFMTCA6PSAkKElOU1RBTEwpCiBJTlNUQUxMID0gJChYRU5fUk9PVCkv
dG9vbHMvY3Jvc3MtaW5zdGFsbApAQCAtODAsOCArODEsNiBAQCBjaGVjay0kKENPTkZJR19YODYp
ID0gJChjYWxsIGNjLXZlci1jaGVjCiAgICAgICAgICAgICAgICAgICAgICAgICAiWGVuIHJlcXVp
cmVzIGF0IGxlYXN0IGdjYy0zLjQiKQogJChldmFsICQoY2hlY2steSkpCiAKLV9QWVRIT05fUEFU
SCA6PSAkKHNoZWxsIHdoaWNoICQoUFlUSE9OKSkKLVBZVEhPTl9QQVRIID89ICQoX1BZVEhPTl9Q
QVRIKQogSU5TVEFMTF9QWVRIT05fUFJPRyA9IFwKIAkkKFhFTl9ST09UKS90b29scy9weXRob24v
aW5zdGFsbC13cmFwICIkKFBZVEhPTl9QQVRIKSIgJChJTlNUQUxMX1BST0cpCiAKQEAgLTEwOSwz
ICsxMDgsNyBAQCBzdWJkaXItYWxsLSUgc3ViZGlyLWNsZWFuLSUgc3ViZGlyLWluc3RhCiAKIHN1
YmRpci1kaXN0Y2xlYW4tJTogLnBob255CiAJJChNQUtFKSAtQyAkKiBjbGVhbgorCiskKFhFTl9S
T09UKS9jb25maWcvVG9vbHMubWs6CisJQGVjaG8gIllvdSBoYXZlIHRvIHJ1biAuL2NvbmZpZ3Vy
ZSBiZWZvcmUgYnVpbGRpbmcgb3IgaW5zdGFsbGluZyB0aGUgdG9vbHMiCisJQGV4aXQgMQpkaWZm
IC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFr
ZWZpbGUKLS0tIGEvdG9vbHMvYmxrdGFwL2RyaXZlcnMvTWFrZWZpbGUJVGh1IEphbiAwNSAxNzoy
NToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2Jsa3RhcC9kcml2ZXJzL01ha2VmaWxlCVR1ZSBK
YW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMTMsNyArMTMsNyBAQCBDRkxBR1MgICArPSAk
KENGTEFHU19saWJ4ZW5zdG9yZSkKIENGTEFHUyAgICs9IC1JICQoTUVNU0hSX0RJUikKIENGTEFH
UyAgICs9IC1EX0dOVV9TT1VSQ0UKIAotaWZlcSAoJChzaGVsbCAuIC4vY2hlY2tfZ2NyeXB0ICQo
Q0MpKSx5ZXMpCitpZmVxICgkQ09ORklHX0dDUllQVCx5KQogQ0ZMQUdTICs9IC1EVVNFX0dDUllQ
VAogQ1JZUFRfTElCIDo9IC1sZ2NyeXB0CiBlbHNlCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2
NjVkOTRkYWIwZiB0b29scy9ibGt0YXAvZHJpdmVycy9jaGVja19nY3J5cHQKLS0tIGEvdG9vbHMv
YmxrdGFwL2RyaXZlcnMvY2hlY2tfZ2NyeXB0CVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAw
MAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxNCAr
MCwwIEBACi0jIS9iaW4vc2gKLQotY2F0ID4gLmdjcnlwdC5jIDw8IEVPRgotI2luY2x1ZGUgPGdj
cnlwdC5oPgotaW50IG1haW4odm9pZCkgeyByZXR1cm4gMDsgfQotRU9GCi0KLWlmICQxIC1vIC5n
Y3J5cHQgLmdjcnlwdC5jIC1sZ2NyeXB0IDI+L2Rldi9udWxsIDsgdGhlbgotICBlY2hvICJ5ZXMi
Ci1lbHNlCi0gIGVjaG8gIm5vIgotZmkKLQotcm0gLWYgLmdjcnlwdCoKZGlmZiAtciA0MDg2ZTQ4
MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NoZWNrL01ha2VmaWxlCi0tLSBhL3Rvb2xzL2No
ZWNrL01ha2VmaWxlCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxs
CVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyNiArMCwwIEBACi1YRU5fUk9P
VCA9ICQoQ1VSRElSKS8uLi8uLgotaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawot
Ci0jIEV4cG9ydCB0aGUgbmVjZXNzYXJ5IGVudmlyb25tZW50IHZhcmlhYmxlcyBmb3IgdGhlIHRl
c3RzCi1leHBvcnQgUFlUSE9OCi1leHBvcnQgTElCWEVOQVBJX0JJTkRJTkdTCi1leHBvcnQgQ0hF
Q0tfSU5DTFVERVMKLWV4cG9ydCBDSEVDS19MSUIKLWV4cG9ydCBDT05GSUdfU1lTVEVNX0xJQkFJ
TwotCi0uUEhPTlk6IGFsbCBpbnN0YWxsCi1hbGwgaW5zdGFsbDogY2hlY2stYnVpbGQKLQotIyBD
aGVjayB0aGlzIG1hY2hpbmUgaXMgT0sgZm9yIGJ1aWxkaW5nIG9uLgotLlBIT05ZOiBjaGVjay1i
dWlsZAotY2hlY2stYnVpbGQ6Ci0JLi9jaGsgYnVpbGQKLQotIyBDaGVjayB0aGlzIG1hY2hpbmUg
aXMgT0sgZm9yIGluc3RhbGxpbmcgb24uCi0uUEhPTlk6IGNoZWNrLWluc3RhbGwKLWNoZWNrLWlu
c3RhbGw6Ci0JLi9jaGsgaW5zdGFsbAotCi0uUEhPTlk6IGNsZWFuCi1jbGVhbjoKLQkuL2NoayBj
bGVhbgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY2hlY2svUkVB
RE1FCi0tLSBhL3Rvb2xzL2NoZWNrL1JFQURNRQlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAw
MDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMjAg
KzAsMCBAQAotQ2hlY2tzIGZvciB0aGUgc3VpdGFiaWxpdHkgb2YgYSBtYWNoaW5lIGZvciBYZW4g
YnVpbGQgb3IgaW5zdGFsbC4KLVRvIGNoZWNrIGZvciBidWlsZCBzdWl0YWJpbGl0eSB1c2UKLQot
ICAgICAgICAuL2NoayBidWlsZAotCi1UbyBjaGVjayBmb3IgaW5zdGFsbCBzdWl0YWJpbGl0eSB1
c2UKLQotICAgICAgICAuL2NoayBpbnN0YWxsCi0KLVRoZSBjaGsgc2NyaXB0IHdpbGwgcnVuIGNo
ZWNrcyBpbiB0aGlzIGRpcmVjdG9yeSBhbmQgcHJpbnQKLXRoZSBvbmVzIHRoYXQgZmFpbGVkLiBJ
dCBwcmludHMgbm90aGluZyBpZiBjaGVja3Mgc3VjY2VlZC4KLVRoZSBjaGsgc2NyaXB0IGV4aXRz
IHdpdGggMCBvbiBzdWNjZXNzIGFuZCAxIG9uIGZhaWx1cmUuCi0KLVRoZSBjaGsgc2NyaXB0IHJ1
bnMgZXhlY3V0YWJsZSBmaWxlcyBpbiB0aGlzIGRpcmVjdG9yeSB3aG9zZQotbmFtZXMgYmVnaW4g
d2l0aCAnY2hlY2tfJy4gRmlsZXMgY29udGFpbmluZyBDSEVDSy1CVUlMRAotYXJlIHJ1biBmb3Ig
dGhlIGJ1aWxkIGNoZWNrLCBhbmQgZmlsZXMgY29udGFpbmluZyBDSEVDSy1JTlNUQUxMCi1hcmUg
cnVuIGZvciB0aGUgaW5zdGFsbCBjaGVjay4KLQotRGV0YWlsZWQgb3V0cHV0IGZyb20gdGhlIGNo
ZWNrIHNjcmlwdHMgaXMgaW4gLmNoa2J1aWxkIGZvciBidWlsZAotYW5kIC5jaGtpbnN0YWxsIGZv
ciBpbnN0YWxsLgpcIE5vIG5ld2xpbmUgYXQgZW5kIG9mIGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1
NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NoZWNrL2NoZWNrX2JyY3RsCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX2JyY3RsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwxMyArMCwwIEBACi0jIS9i
aW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Muc2gKLQotY2FzZSAkT1MgaW4KLU9w
ZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwgYnJjb25maWcgOzsKLUxpbnV4KQot
CWhhc19vcl9mYWlsIGJyY3RsIDs7Ci0qKQotCWZhaWwgInVua25vd24gT1MiIDs7Ci1lc2FjCmRp
ZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja19jcnlw
dG9fbGliCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2NyeXB0b19saWIJVGh1IEphbiAwNSAxNzoy
NToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCkBAIC0xLDExICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNU
QUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJlZUJTRHxOZXRCU0R8T3BlbkJT
RCkKLQlleGl0IDAgOzsKLWVzYWMKLQotaGFzX2xpYiBsaWJjcnlwdG8uc28gfHwgZmFpbCAibWlz
c2luZyBsaWJjcnlwdG8uc28iCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0
b29scy9jaGVjay9jaGVja19jdXJsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2N1cmwJVGh1IEph
biAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCkBAIC0xLDEzICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1CVUlMRCBD
SEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbICIkTElCWEVOQVBJX0JJTkRJTkdT
IiAhPSAieSIgXTsgdGhlbgotCWVjaG8gLW4gInVudXNlZCwgIgotCWV4aXQgMAotZmkKLQotaGFz
X29yX2ZhaWwgY3VybC1jb25maWcKLWN1cmxfbGlicz1gY3VybC1jb25maWcgLS1saWJzYCB8fCBm
YWlsICJjdXJsLWNvbmZpZyAtLWxpYnMgZmFpbGVkIgotdGVzdF9saW5rICRjdXJsX2xpYnMgfHwg
ZmFpbCAiZGVwZW5kZW5jeSBsaWJyYXJpZXMgZm9yIGN1cmwgYXJlIG1pc3NpbmciCmRpZmYgLXIg
NDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja19pcHJvdXRlCi0t
LSBhL3Rvb2xzL2NoZWNrL2NoZWNrX2lwcm91dGUJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICsw
MDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE1
ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1Q
QVRIPS9zYmluOiRQQVRICi0KLWNhc2UgJE9TIGluCi1PcGVuQlNEfE5ldEJTRHxGcmVlQlNEKQot
CWhhc19vcl9mYWlsIGlmY29uZmlnIDs7Ci1MaW51eCkKLQloYXNfb3JfZmFpbCBpcCA7OwotKikK
LQlmYWlsICJ1bmtub3duIE9TIiA7OwotZXNhYwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1
ZDk0ZGFiMGYgdG9vbHMvY2hlY2svY2hlY2tfbGliYWlvX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNr
L2NoZWNrX2xpYmFpb19kZXZlbAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9k
ZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsMTEgKzAsMCBAQAot
IyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJ
R19TWVNURU1fTElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaWYgISBo
YXNfaGVhZGVyIGxpYmFpby5oIDsgdGhlbgotICAgIGZhaWwgImNhbid0IGZpbmQgbGliYWlvIGhl
YWRlcnMsIGluc3RhbGwgbGliYWlvIGRldmVsIHBhY2thZ2Ugb3Igc2V0IENPTkZJR19TWVNURU1f
TElCQUlPPW4iCi1maQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMv
Y2hlY2svY2hlY2tfbGliYWlvX2xpYgotLS0gYS90b29scy9jaGVjay9jaGVja19saWJhaW9fbGli
CVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEg
MDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw5ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVDSy1C
VUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBbIFgke0NPTkZJR19TWVNU
RU1fTElCQUlPfSAhPSBYInkiIF0gOyB0aGVuCi0gICAgZXhpdCAwCi1maQotaGFzX2xpYiBsaWJh
aW8uc28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJhaW8iCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1y
IGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja19vcGVuc3NsX2RldmVsCi0tLSBhL3Rvb2xz
L2NoZWNrL2NoZWNrX29wZW5zc2xfZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAw
CisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVh
ZGVyIG9wZW5zc2wvbWQ1LmggfHwgZmFpbCAibWlzc2luZyBvcGVuc3NsIGhlYWRlcnMiCmRpZmYg
LXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja19weXRob24K
LS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiAr
MDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwx
MyArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQgQ0hFQ0stSU5TVEFMTAotCi0uIC4v
ZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgot
ZmkKLQotJHtQWVRIT059IC1jICcKLWltcG9ydCBzeXMKLXN5cy5leGl0KHN5cy52ZXJzaW9uX2lu
Zm9bMF0gPCAyIG9yIHN5cy52ZXJzaW9uX2luZm9bMV0gPCAzKQotJyB8fCBmYWlsICJuZWVkIHB5
dGhvbiB2ZXJzaW9uID49IDIuMyIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBm
IHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhvbl9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja19w
eXRob25fZGV2ZWwJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJ
VGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE3ICswLDAgQEAKLSMhL2Jpbi9z
aAotIyBDSEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaWYgdGVzdCAteiAke1BZVEhPTn07
IHRoZW4KLSAgUFlUSE9OPXB5dGhvbgotZmkKLWhhc19vcl9mYWlsICR7UFlUSE9OfQotCi0ke1BZ
VEhPTn0gLWMgJwotaW1wb3J0IG9zLnBhdGgsIHN5cwotZm9yIHAgaW4gc3lzLnBhdGg6Ci0JaWYg
b3MucGF0aC5leGlzdHMocCArICIvY29uZmlnL01ha2VmaWxlIik6Ci0JCXN5cy5leGl0KDApCi1z
eXMuZXhpdCgxKQotJyB8fCBmYWlsICJjYW4ndCBmaW5kIHB5dGhvbiBkZXZlbCBmaWxlcyIKZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NoZWNrL2NoZWNrX3B5dGhv
bl94bWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfcHl0aG9uX3htbAlUaHUgSmFuIDA1IDE3OjI1
OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTIgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1
bmNzLnNoCi0KLWlmIHRlc3QgLXogJHtQWVRIT059OyB0aGVuCi0gIFBZVEhPTj1weXRob24KLWZp
Ci1oYXNfb3JfZmFpbCAke1BZVEhPTn0KLQotJHtQWVRIT059IC1jICdpbXBvcnQgeG1sLmRvbS5t
aW5pZG9tJyAyPi9kZXYvbnVsbCB8fCBcCi1mYWlsICJjYW4ndCBpbXBvcnQgeG1sLmRvbS5taW5p
ZG9tIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY2hlY2svY2hl
Y2tfdWRldgotLS0gYS90b29scy9jaGVjay9jaGVja191ZGV2CVRodSBKYW4gMDUgMTc6MjU6MjMg
MjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApA
QCAtMSwyMiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stSU5TVEFMTAotCi0uIC4vZnVuY3Mu
c2gKLQotY2FzZSAkT1MgaW4KLU9wZW5CU0R8TmV0QlNEfEZyZWVCU0QpCi0JaGFzX29yX2ZhaWwg
dm5jb25maWcKLQk7OwotTGludXgpCi0JaGFzIC9zYmluL3VkZXZhZG0gJiYgXAotCQl1ZGV2dmVy
PWAvc2Jpbi91ZGV2YWRtIGluZm8gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKLQlbIC16ICIkdWRl
dnZlciIgXSAmJiBoYXNfb3JfZmFpbCB1ZGV2aW5mbyAmJiBcCi0JCXVkZXZ2ZXI9YHVkZXZpbmZv
IC1WIHwgYXdrICd7cHJpbnQgJE5GfSdgCi0JWyAiJHVkZXZ2ZXIiIC1nZSA1OSBdIDI+L2Rldi9u
dWxsIHx8IFwKLQkJaGFzIGhvdHBsdWcgfHwgXAotCQlmYWlsICJ1ZGV2IGlzIHRvbyBvbGQsIHVw
Z3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlciIKLQk7OwotKikKLQlmYWlsICJ1bmtub3duIE9T
IgotCTs7Ci1lc2FjCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9j
aGVjay9jaGVja191dWlkX2RldmVsCi0tLSBhL3Rvb2xzL2NoZWNrL2NoZWNrX3V1aWRfZGV2ZWwJ
VGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAw
MDowMDowMCAxOTcwICswMDAwCkBAIC0xLDcgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJV
SUxECi0KLS4gLi9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIHV1aWQuaCB8fCBcCi1oYXNfaGVhZGVy
IHV1aWQvdXVpZC5oIHx8IGZhaWwgIm1pc3NpbmcgdXVpZCBoZWFkZXJzIChwYWNrYWdlIHV1aWQt
ZGV2KSIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NoZWNrL2No
ZWNrX3gxMV9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja194MTFfZGV2ZWwJVGh1IEphbiAw
NSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAx
OTcwICswMDAwCkBAIC0xLDkgKzAsMCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxECi0KLS4g
Li9mdW5jcy5zaAotCi1oYXNfaGVhZGVyIFgxMS9rZXlzeW1kZWYuaCB8fCBcCi1oYXNfaGVhZGVy
IC91c3IvWDExUjYvaW5jbHVkZS9YMTEva2V5c3ltZGVmLmggfHwgXAotaGFzX2hlYWRlciAvdXNy
L1gxMVI3L2luY2x1ZGUvWDExL2tleXN5bWRlZi5oIHx8IFwKLXdhcm5pbmcgImNhbid0IGZpbmQg
WDExIGhlYWRlcnMiCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9j
aGVjay9jaGVja194Z2V0dGV4dAotLS0gYS90b29scy9jaGVjay9jaGVja194Z2V0dGV4dAlUaHUg
SmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAw
OjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0stQlVJTEQK
LQotLiAuL2Z1bmNzLnNoCi0KLWhhc19vcl9mYWlsIHhnZXR0ZXh0CmRpZmYgLXIgNDA4NmU0ODEx
NTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9jaGVjay9jaGVja194bWwyCi0tLSBhL3Rvb2xzL2No
ZWNrL2NoZWNrX3htbDIJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251
bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDE0ICswLDAgQEAKLSMhL2Jp
bi9zaAotIyBDSEVDSy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1pZiBb
ICEgIiRMSUJYRU5BUElfQklORElOR1MiID0gInkiIF0KLXRoZW4KLSAgICBlY2hvIC1uICJ1bnVz
ZWQsICIKLSAgICBleGl0IDAKLWZpCi0KLWhhc19vcl9mYWlsIHhtbDItY29uZmlnCi14bWwyX2xp
YnM9YHhtbDItY29uZmlnIC0tbGlic2AgfHwgZmFpbCAieG1sMi1jb25maWcgLS1saWJzIGZhaWxl
ZCIKLXRlc3RfbGluayAkeG1sMl9saWJzIHx8IGZhaWwgImRlcGVuZGVuY3kgbGlicmFyaWVzIGZv
ciB4bWwyIGFyZSBtaXNzaW5nIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYg
dG9vbHMvY2hlY2svY2hlY2tfeWFqbF9kZXZlbAotLS0gYS90b29scy9jaGVjay9jaGVja195YWps
X2RldmVsCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysgL2Rldi9udWxsCVRodSBK
YW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSw4ICswLDAgQEAKLSMhL2Jpbi9zaAotIyBD
SEVDSy1CVUlMRAotCi0uIC4vZnVuY3Muc2gKLQotaGFzX2hlYWRlciB5YWpsL3lhamxfcGFyc2Uu
aCB8fCBmYWlsICJjYW4ndCBmaW5kIHlhamwveWFqbF9wYXJzZS5oIgotaGFzX2hlYWRlciB5YWps
L3lhamxfZ2VuLmggfHwgZmFpbCAiY2FuJ3QgZmluZCB5YWpsL3lhamxfZ2VuLmgiCi1oYXNfbGli
IGxpYnlhamwuc28gfHwgZmFpbCAiY2FuJ3QgZmluZCBsaWJ5YWpsLnNvIgpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY2hlY2svY2hlY2tfeWFqbF9saWIKLS0tIGEv
dG9vbHMvY2hlY2svY2hlY2tfeWFqbF9saWIJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAw
CisrKyAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDYgKzAs
MCBAQAotIyEvYmluL3NoCi0jIENIRUNLLUJVSUxEIENIRUNLLUlOU1RBTEwKLQotLiAuL2Z1bmNz
LnNoCi0KLWhhc19saWIgbGlieWFqbC5zby4xIHx8IGZhaWwgImNhbid0IGZpbmQgbGlieWFqbC5z
by4xIHZlcnNpb24gMSIKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xz
L2NoZWNrL2NoZWNrX3psaWJfZGV2ZWwKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfemxpYl9kZXZl
bAlUaHUgSmFuIDA1IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAx
IDAwOjAwOjAwIDE5NzAgKzAwMDAKQEAgLTEsNiArMCwwIEBACi0jIS9iaW4vc2gKLSMgQ0hFQ0st
QlVJTEQKLQotLiAuL2Z1bmNzLnNoCi0KLWhhc19oZWFkZXIgemxpYi5oIHx8IGZhaWwgImNhbid0
IGZpbmQgemxpYiBoZWFkZXJzIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYg
dG9vbHMvY2hlY2svY2hlY2tfemxpYl9saWIKLS0tIGEvdG9vbHMvY2hlY2svY2hlY2tfemxpYl9s
aWIJVGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyAvZGV2L251bGwJVGh1IEphbiAw
MSAwMDowMDowMCAxOTcwICswMDAwCkBAIC0xLDEyICswLDAgQEAKLSMhL2Jpbi9zaAotIyBDSEVD
Sy1CVUlMRCBDSEVDSy1JTlNUQUxMCi0KLS4gLi9mdW5jcy5zaAotCi1jYXNlICRPUyBpbgotRnJl
ZUJTRHxOZXRCU0R8T3BlbkJTRCkKLQlleGl0IDAKLQk7OwotZXNhYwotCi1oYXNfbGliIGxpYnou
c28gfHwgZmFpbCAiY2FuJ3QgZmluZCB6bGliIgpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1
ZDk0ZGFiMGYgdG9vbHMvY2hlY2svY2hrCi0tLSBhL3Rvb2xzL2NoZWNrL2NoawlUaHUgSmFuIDA1
IDE3OjI1OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5
NzAgKzAwMDAKQEAgLTEsNjMgKzAsMCBAQAotIyEvYmluL3NoCi0KLWZ1bmNfdXNhZ2UgKCkKLXsK
LSAgICBlY2hvICJVc2FnZToiCi0gICAgZWNobyAiCSQwIFtidWlsZHxpbnN0YWxsfGNsZWFuXSIK
LSAgICBlY2hvCi0gICAgZWNobyAiQ2hlY2sgc3VpdGFiaWxpdHkgZm9yIFhlbiBidWlsZCBvciBp
bnN0YWxsLiIKLSAgICBlY2hvICJFeGl0IHdpdGggMCBpZiBPSywgMSBpZiBub3QuIgotICAgIGVj
aG8KLSAgICBlY2hvICJDYWxsaW5nIHdpdGggJ2NsZWFuJyByZW1vdmVzIGdlbmVyYXRlZCBmaWxl
cy4iCi0gICAgZXhpdCAxCi19Ci0KLVBBVEg9JFBBVEg6L3NiaW46L3Vzci9zYmluCi1PUz1gdW5h
bWUgLXNgCi1leHBvcnQgUEFUSCBPUwotCi1pZiBbICIkT1MiID0gIlN1bk9TIiBdOyB0aGVuCi0J
ZXhpdCAwCi1maQotCi1jYXNlICQxIGluCi0gICAgYnVpbGQpCi0gICAgICAgIGNoZWNrPSJDSEVD
Sy1CVUlMRCIKLSAgICAgICAgOzsKLSAgICBpbnN0YWxsKQotICAgICAgICBjaGVjaz0iQ0hFQ0st
SU5TVEFMTCIKLSAgICAgICAgOzsKLSAgICBjbGVhbikKLSAgICAgICAgZXhpdCAwCi0gICAgICAg
IDs7Ci0gICAgKikKLSAgICAgICAgZnVuY191c2FnZQotICAgICAgICA7OwotZXNhYwotCi1mYWls
ZWQ9MAotCi1lY2hvICJYZW4gJHtjaGVja30gIiBgZGF0ZWAKLWZvciBmIGluIGNoZWNrXyogOyBk
bwotICAgIGNhc2UgJGYgaW4KLSAgICAgICAgKn4pCi0gICAgICAgICAgICBjb250aW51ZQotICAg
ICAgICAgICAgOzsKLSAgICAgICAgKikKLSAgICAgICAgICAgIDs7Ci0gICAgZXNhYwotICAgIGlm
ICEgWyAteCAkZiBdIDsgdGhlbgotICAgICAgICBjb250aW51ZQotICAgIGZpCi0gICAgaWYgISBn
cmVwIC1GcSAiJGNoZWNrIiAkZiA7IHRoZW4KLSAgICAgICAgY29udGludWUKLSAgICBmaQotICAg
IGVjaG8gLW4gIkNoZWNraW5nICRmOiAiCi0gICAgaWYgLi8kZiAyPiYxIDsgdGhlbgotICAgICAg
ICBlY2hvIE9LCi0gICAgZWxzZQotICAgICAgICBmYWlsZWQ9MQotICAgIGZpCi1kb25lCi0KLWV4
aXQgJHtmYWlsZWR9CmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9j
aGVjay9mdW5jcy5zaAotLS0gYS90b29scy9jaGVjay9mdW5jcy5zaAlUaHUgSmFuIDA1IDE3OjI1
OjIzIDIwMTIgKzAwMDAKKysrIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKQEAgLTEsMTA2ICswLDAgQEAKLSMgaGFzIGlzIHRoZSBzYW1lIGFzIHdoaWNoLCBleGNlcHQg
aXQgaGFuZGxlcyBjcm9zcyBlbnZpcm9ubWVudHMKLWhhcygpIHsKLQlpZiBbIC16ICIkQ1JPU1Nf
Q09NUElMRSIgXTsgdGhlbgotCQljb21tYW5kIHdoaWNoICIkQCIKLQkJcmV0dXJuICQ/Ci0JZmkK
LQotCWNoZWNrX3N5c19yb290IHx8IHJldHVybiAxCi0KLQkjIHN1YnNoZWxsIHRvIHByZXZlbnQg
cG9sbHV0aW9uIG9mIGNhbGxlcidzIElGUwotCSgKLQlJRlM9OgotCWZvciBwIGluICRQQVRIOyBk
bwotCQlpZiBbIC14ICIkQ1JPU1NfU1lTX1JPT1QvJHAvJDEiIF07IHRoZW4KLQkJCWVjaG8gIiRD
Uk9TU19TWVNfUk9PVC8kcC8kMSIKLQkJCXJldHVybiAwCi0JCWZpCi0JZG9uZQotCXJldHVybiAx
Ci0JKQotfQotCi1oYXNfb3JfZmFpbCgpIHsKLQloYXMgIiQxIiA+L2Rldi9udWxsIHx8IGZhaWwg
ImNhbid0IGZpbmQgJDEiCi19Ci0KLWhhc19oZWFkZXIoKSB7Ci0JY2hlY2tfc3lzX3Jvb3QgfHwg
cmV0dXJuIDEKLQotCWNhc2UgJDEgaW4KLQkJLyopIDs7Ci0JCSopCi0JCWlmIFsgLXIgIiRDUk9T
U19TWVNfUk9PVC91c3IvaW5jbHVkZS8kMSIgXTsgdGhlbgotCQkJcmV0dXJuIDAKLQkJZmkKLQkJ
Zm9yIHBhdGggaW4gJHtDSEVDS19JTkNMVURFU307IGRvCi0JCQlpZiBbIC1yICIkQ1JPU1NfU1lT
X1JPT1Qke3BhdGh9LyQxIiBdOyB0aGVuCi0JCQkJcmV0dXJuIDAKLQkJCWZpCi0JCWRvbmUKLQkJ
OzsKLQllc2FjCi0KLQlyZXR1cm4gMQotfQotCi1oYXNfbGliKCkgewotCWNoZWNrX3N5c19yb290
IHx8IHJldHVybiAxCi0KLQkjIHN1YnNoZWxsIHRvIHByZXZlbnQgcG9sbHV0aW9uIG9mIGNhbGxl
cidzIGVudmlyb25tZW50Ci0JKAotCVBBVEg9L3NiaW46JFBBVEggICAgICAgICMgZm9yIGxkY29u
ZmlnCi0JTElCUkFSSUVTPSIkQ0hFQ0tfTElCIC91c3IvbGliIgotCi0JIyBUaGlzIHJlbGF0aXZl
bHkgY29tbW9uIGluIGEgc3lzLXJvb3Q7IGxpYnMgYXJlIGluc3RhbGxlZCBidXQKLQkjIGxkY29u
ZmlnIGhhc24ndCBydW4gdGhlcmUsIHNvIGxkY29uZmlnIC1wIHdvbid0IHdvcmsuCi0JaWYgWyAi
JE9TIiA9IExpbnV4IC1hICEgLWYgIiRDUk9TU19TWVNfUk9PVC9ldGMvbGQuc28uY2FjaGUiIF07
IHRoZW4KLQkgICAgZWNobyAiUGxlYXNlIHJ1biBsZGNvbmZpZyAtciBcIiRDUk9TU19TWVNfUk9P
VFwiIHRvIGdlbmVyYXRlIGxkLnNvLmNhY2hlIgotCSAgICAjIGZhbGwgdGhyb3VnaDsgbGRjb25m
aWcgdGVzdCBiZWxvdyBzaG91bGQgZmFpbAotCWZpCi0JaWYgWyAiJHtPU30iID0gIkxpbnV4IiBd
OyB0aGVuCi0JCWxkY29uZmlnIC1wICR7Q1JPU1NfU1lTX1JPT1QrLXIgIiRDUk9TU19TWVNfUk9P
VCJ9IHwgZ3JlcCAtRnEgIiQxIgotCQlyZXR1cm4gJD8KLQlmaQotCWlmIFsgIiR7T1N9IiA9ICJO
ZXRCU0QiIF07IHRoZW4KLQkJbHMgLTEgJHtMSUJSQVJJRVN9IHwgZ3JlcCAtRnEgIiQxIgotCQly
ZXR1cm4gJD8KLQlmaQotCXJldHVybiAxCi0JKQotfQotCi10ZXN0X2xpbmsoKSB7Ci0JIyBzdWJz
aGVsbCB0byB0cmFwIHJlbW92YWwgb2YgdG1wZmlsZQotCSgKLQl1bnNldCB0bXBmaWxlCi0JdHJh
cCAncm0gLWYgIiR0bXBmaWxlIjsgZXhpdCcgMCAxIDIgMTUKLQl0bXBmaWxlPWBta3RlbXBgIHx8
IHJldHVybiAxCi0JbGQgIiRAIiAtbyAiJHRtcGZpbGUiID4vZGV2L251bGwgMj4mMQotCXJldHVy
biAkPwotCSkKLX0KLQotIyB0aGlzIGZ1bmN0aW9uIGlzIHVzZWQgY29tbW9ubHkgYWJvdmUKLWNo
ZWNrX3N5c19yb290KCkgewotCVsgLXogIiRDUk9TU19DT01QSUxFIiBdICYmIHJldHVybiAwCi0J
aWYgWyAteiAiJENST1NTX1NZU19ST09UIiBdOyB0aGVuCi0JCWVjaG8gInBsZWFzZSBzZXQgQ1JP
U1NfU1lTX1JPT1QgaW4gdGhlIGVudmlyb25tZW50IgotCQlyZXR1cm4gMQotCWZpCi0JaWYgWyAh
IC1kICIkQ1JPU1NfU1lTX1JPT1QiIF07IHRoZW4KLQkJZWNobyAibm8gc3lzLXJvb3QgZm91bmQg
YXQgJENST1NTX1NZU19ST09UIgotCQlyZXR1cm4gMQotCWZpCi19Ci0KLXdhcm5pbmcoKSB7Ci0J
ZWNobwotCWVjaG8gIiAqKiogYGJhc2VuYW1lICIkMCJgIEZBSUxFRCR7Kis6ICQqfSIKLX0KLQot
ZmFpbCgpIHsKLQllY2hvCi0JZWNobyAiICoqKiBgYmFzZW5hbWUgIiQwImAgRkFJTEVEJHsqKzog
JCp9IgotCWV4aXQgMQotfQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9v
bHMvY29uZmlnLmd1ZXNzCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICsw
MDAwCisrKyBiL3Rvb2xzL2NvbmZpZy5ndWVzcwlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAx
MDAKQEAgLTAsMCArMSwxNTAxIEBACisjISAvYmluL3NoCisjIEF0dGVtcHQgdG8gZ3Vlc3MgYSBj
YW5vbmljYWwgc3lzdGVtIG5hbWUuCisjICAgQ29weXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0
LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LAorIyAgIDIwMDAsIDIwMDEsIDIwMDIsIDIw
MDMsIDIwMDQsIDIwMDUsIDIwMDYsIDIwMDcsIDIwMDgsIDIwMDkKKyMgICBGcmVlIFNvZnR3YXJl
IEZvdW5kYXRpb24sIEluYy4KKwordGltZXN0YW1wPScyMDA5LTExLTIwJworCisjIFRoaXMgZmls
ZSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5
IGl0CisjIHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2Ug
YXMgcHVibGlzaGVkIGJ5CisjIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2
ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yCisjIChhdCB5b3VyIG9wdGlvbikgYW55IGxhdGVy
IHZlcnNpb24uCisjCisjIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0
aGF0IGl0IHdpbGwgYmUgdXNlZnVsLCBidXQKKyMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdpdGhv
dXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZgorIyBNRVJDSEFOVEFCSUxJVFkgb3IgRklU
TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlIEdOVQorIyBHZW5lcmFsIFB1
YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisjCisjIFlvdSBzaG91bGQgaGF2ZSByZWNl
aXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlCisjIGFsb25nIHdp
dGggdGhpcyBwcm9ncmFtOyBpZiBub3QsIHdyaXRlIHRvIHRoZSBGcmVlIFNvZnR3YXJlCisjIEZv
dW5kYXRpb24sIEluYy4sIDUxIEZyYW5rbGluIFN0cmVldCAtIEZpZnRoIEZsb29yLCBCb3N0b24s
IE1BCisjIDAyMTEwLTEzMDEsIFVTQS4KKyMKKyMgQXMgYSBzcGVjaWFsIGV4Y2VwdGlvbiB0byB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UsIGlmIHlvdQorIyBkaXN0cmlidXRlIHRoaXMg
ZmlsZSBhcyBwYXJ0IG9mIGEgcHJvZ3JhbSB0aGF0IGNvbnRhaW5zIGEKKyMgY29uZmlndXJhdGlv
biBzY3JpcHQgZ2VuZXJhdGVkIGJ5IEF1dG9jb25mLCB5b3UgbWF5IGluY2x1ZGUgaXQgdW5kZXIK
KyMgdGhlIHNhbWUgZGlzdHJpYnV0aW9uIHRlcm1zIHRoYXQgeW91IHVzZSBmb3IgdGhlIHJlc3Qg
b2YgdGhhdCBwcm9ncmFtLgorCisKKyMgT3JpZ2luYWxseSB3cml0dGVuIGJ5IFBlciBCb3RobmVy
LiAgUGxlYXNlIHNlbmQgcGF0Y2hlcyAoY29udGV4dAorIyBkaWZmIGZvcm1hdCkgdG8gPGNvbmZp
Zy1wYXRjaGVzQGdudS5vcmc+IGFuZCBpbmNsdWRlIGEgQ2hhbmdlTG9nCisjIGVudHJ5LgorIwor
IyBUaGlzIHNjcmlwdCBhdHRlbXB0cyB0byBndWVzcyBhIGNhbm9uaWNhbCBzeXN0ZW0gbmFtZSBz
aW1pbGFyIHRvCisjIGNvbmZpZy5zdWIuICBJZiBpdCBzdWNjZWVkcywgaXQgcHJpbnRzIHRoZSBz
eXN0ZW0gbmFtZSBvbiBzdGRvdXQsIGFuZAorIyBleGl0cyB3aXRoIDAuICBPdGhlcndpc2UsIGl0
IGV4aXRzIHdpdGggMS4KKyMKKyMgWW91IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRo
aXMgc2NyaXB0IGZyb206CisjIGh0dHA6Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9
Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47Zj1jb25maWcuZ3Vlc3M7aGI9SEVBRAorCittZT1gZWNo
byAiJDAiIHwgc2VkIC1lICdzLC4qLywsJ2AKKwordXNhZ2U9IlwKK1VzYWdlOiAkMCBbT1BUSU9O
XQorCitPdXRwdXQgdGhlIGNvbmZpZ3VyYXRpb24gbmFtZSBvZiB0aGUgc3lzdGVtIFxgJG1lJyBp
cyBydW4gb24uCisKK09wZXJhdGlvbiBtb2RlczoKKyAgLWgsIC0taGVscCAgICAgICAgIHByaW50
IHRoaXMgaGVscCwgdGhlbiBleGl0CisgIC10LCAtLXRpbWUtc3RhbXAgICBwcmludCBkYXRlIG9m
IGxhc3QgbW9kaWZpY2F0aW9uLCB0aGVuIGV4aXQKKyAgLXYsIC0tdmVyc2lvbiAgICAgIHByaW50
IHZlcnNpb24gbnVtYmVyLCB0aGVuIGV4aXQKKworUmVwb3J0IGJ1Z3MgYW5kIHBhdGNoZXMgdG8g
PGNvbmZpZy1wYXRjaGVzQGdudS5vcmc+LiIKKwordmVyc2lvbj0iXAorR05VIGNvbmZpZy5ndWVz
cyAoJHRpbWVzdGFtcCkKKworT3JpZ2luYWxseSB3cml0dGVuIGJ5IFBlciBCb3RobmVyLgorQ29w
eXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5
LCAyMDAwLCAyMDAxLAorMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAwOCBG
cmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhpcyBpcyBmcmVlIHNvZnR3YXJlOyBz
ZWUgdGhlIHNvdXJjZSBmb3IgY29weWluZyBjb25kaXRpb25zLiAgVGhlcmUgaXMgTk8KK3dhcnJh
bnR5OyBub3QgZXZlbiBmb3IgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElD
VUxBUiBQVVJQT1NFLiIKKworaGVscD0iCitUcnkgXGAkbWUgLS1oZWxwJyBmb3IgbW9yZSBpbmZv
cm1hdGlvbi4iCisKKyMgUGFyc2UgY29tbWFuZCBsaW5lCit3aGlsZSB0ZXN0ICQjIC1ndCAwIDsg
ZG8KKyAgY2FzZSAkMSBpbgorICAgIC0tdGltZS1zdGFtcCB8IC0tdGltZSogfCAtdCApCisgICAg
ICAgZWNobyAiJHRpbWVzdGFtcCIgOyBleGl0IDs7CisgICAgLS12ZXJzaW9uIHwgLXYgKQorICAg
ICAgIGVjaG8gIiR2ZXJzaW9uIiA7IGV4aXQgOzsKKyAgICAtLWhlbHAgfCAtLWgqIHwgLWggKQor
ICAgICAgIGVjaG8gIiR1c2FnZSI7IGV4aXQgOzsKKyAgICAtLSApICAgICAjIFN0b3Agb3B0aW9u
IHByb2Nlc3NpbmcKKyAgICAgICBzaGlmdDsgYnJlYWsgOzsKKyAgICAtICkJIyBVc2Ugc3RkaW4g
YXMgaW5wdXQuCisgICAgICAgYnJlYWsgOzsKKyAgICAtKiApCisgICAgICAgZWNobyAiJG1lOiBp
bnZhbGlkIG9wdGlvbiAkMSRoZWxwIiA+JjIKKyAgICAgICBleGl0IDEgOzsKKyAgICAqICkKKyAg
ICAgICBicmVhayA7OworICBlc2FjCitkb25lCisKK2lmIHRlc3QgJCMgIT0gMDsgdGhlbgorICBl
Y2hvICIkbWU6IHRvbyBtYW55IGFyZ3VtZW50cyRoZWxwIiA+JjIKKyAgZXhpdCAxCitmaQorCit0
cmFwICdleGl0IDEnIDEgMiAxNQorCisjIENDX0ZPUl9CVUlMRCAtLSBjb21waWxlciB1c2VkIGJ5
IHRoaXMgc2NyaXB0LiBOb3RlIHRoYXQgdGhlIHVzZSBvZiBhCisjIGNvbXBpbGVyIHRvIGFpZCBp
biBzeXN0ZW0gZGV0ZWN0aW9uIGlzIGRpc2NvdXJhZ2VkIGFzIGl0IHJlcXVpcmVzCisjIHRlbXBv
cmFyeSBmaWxlcyB0byBiZSBjcmVhdGVkIGFuZCwgYXMgeW91IGNhbiBzZWUgYmVsb3csIGl0IGlz
IGEKKyMgaGVhZGFjaGUgdG8gZGVhbCB3aXRoIGluIGEgcG9ydGFibGUgZmFzaGlvbi4KKworIyBI
aXN0b3JpY2FsbHksIGBDQ19GT1JfQlVJTEQnIHVzZWQgdG8gYmUgbmFtZWQgYEhPU1RfQ0MnLiBX
ZSBzdGlsbAorIyB1c2UgYEhPU1RfQ0MnIGlmIGRlZmluZWQsIGJ1dCBpdCBpcyBkZXByZWNhdGVk
LgorCisjIFBvcnRhYmxlIHRtcCBkaXJlY3RvcnkgY3JlYXRpb24gaW5zcGlyZWQgYnkgdGhlIEF1
dG9jb25mIHRlYW0uCisKK3NldF9jY19mb3JfYnVpbGQ9JwordHJhcCAiZXhpdGNvZGU9XCQ/OyAo
cm0gLWYgXCR0bXBmaWxlcyAyPi9kZXYvbnVsbDsgcm1kaXIgXCR0bXAgMj4vZGV2L251bGwpICYm
IGV4aXQgXCRleGl0Y29kZSIgMCA7Cit0cmFwICJybSAtZiBcJHRtcGZpbGVzIDI+L2Rldi9udWxs
OyBybWRpciBcJHRtcCAyPi9kZXYvbnVsbDsgZXhpdCAxIiAxIDIgMTMgMTUgOworOiAke1RNUERJ
Uj0vdG1wfSA7CisgeyB0bXA9YCh1bWFzayAwNzcgJiYgbWt0ZW1wIC1kICIkVE1QRElSL2NnWFhY
WFhYIikgMj4vZGV2L251bGxgICYmIHRlc3QgLW4gIiR0bXAiICYmIHRlc3QgLWQgIiR0bXAiIDsg
fSB8fAorIHsgdGVzdCAtbiAiJFJBTkRPTSIgJiYgdG1wPSRUTVBESVIvY2ckJC0kUkFORE9NICYm
ICh1bWFzayAwNzcgJiYgbWtkaXIgJHRtcCkgOyB9IHx8CisgeyB0bXA9JFRNUERJUi9jZy0kJCAm
JiAodW1hc2sgMDc3ICYmIG1rZGlyICR0bXApICYmIGVjaG8gIldhcm5pbmc6IGNyZWF0aW5nIGlu
c2VjdXJlIHRlbXAgZGlyZWN0b3J5IiA+JjIgOyB9IHx8CisgeyBlY2hvICIkbWU6IGNhbm5vdCBj
cmVhdGUgYSB0ZW1wb3JhcnkgZGlyZWN0b3J5IGluICRUTVBESVIiID4mMiA7IGV4aXQgMSA7IH0g
OworZHVtbXk9JHRtcC9kdW1teSA7Cit0bXBmaWxlcz0iJGR1bW15LmMgJGR1bW15Lm8gJGR1bW15
LnJlbCAkZHVtbXkiIDsKK2Nhc2UgJENDX0ZPUl9CVUlMRCwkSE9TVF9DQywkQ0MgaW4KKyAsLCkg
ICAgZWNobyAiaW50IHg7IiA+ICRkdW1teS5jIDsKKwlmb3IgYyBpbiBjYyBnY2MgYzg5IGM5OSA7
IGRvCisJICBpZiAoJGMgLWMgLW8gJGR1bW15Lm8gJGR1bW15LmMpID4vZGV2L251bGwgMj4mMSA7
IHRoZW4KKwkgICAgIENDX0ZPUl9CVUlMRD0iJGMiOyBicmVhayA7CisJICBmaSA7CisJZG9uZSA7
CisJaWYgdGVzdCB4IiRDQ19GT1JfQlVJTEQiID0geCA7IHRoZW4KKwkgIENDX0ZPUl9CVUlMRD1u
b19jb21waWxlcl9mb3VuZCA7CisJZmkKKwk7OworICwsKikgICBDQ19GT1JfQlVJTEQ9JENDIDs7
CisgLCosKikgIENDX0ZPUl9CVUlMRD0kSE9TVF9DQyA7OworZXNhYyA7IHNldF9jY19mb3JfYnVp
bGQ9IDsnCisKKyMgVGhpcyBpcyBuZWVkZWQgdG8gZmluZCB1bmFtZSBvbiBhIFB5cmFtaWQgT1N4
IHdoZW4gcnVuIGluIHRoZSBCU0QgdW5pdmVyc2UuCisjIChnaGF6aUBub2MucnV0Z2Vycy5lZHUg
MTk5NC0wOC0yNCkKK2lmICh0ZXN0IC1mIC8uYXR0YmluL3VuYW1lKSA+L2Rldi9udWxsIDI+JjEg
OyB0aGVuCisJUEFUSD0kUEFUSDovLmF0dGJpbiA7IGV4cG9ydCBQQVRICitmaQorCitVTkFNRV9N
QUNISU5FPWAodW5hbWUgLW0pIDI+L2Rldi9udWxsYCB8fCBVTkFNRV9NQUNISU5FPXVua25vd24K
K1VOQU1FX1JFTEVBU0U9YCh1bmFtZSAtcikgMj4vZGV2L251bGxgIHx8IFVOQU1FX1JFTEVBU0U9
dW5rbm93bgorVU5BTUVfU1lTVEVNPWAodW5hbWUgLXMpIDI+L2Rldi9udWxsYCAgfHwgVU5BTUVf
U1lTVEVNPXVua25vd24KK1VOQU1FX1ZFUlNJT049YCh1bmFtZSAtdikgMj4vZGV2L251bGxgIHx8
IFVOQU1FX1ZFUlNJT049dW5rbm93bgorCisjIE5vdGU6IG9yZGVyIGlzIHNpZ25pZmljYW50IC0g
dGhlIGNhc2UgYnJhbmNoZXMgYXJlIG5vdCBleGNsdXNpdmUuCisKK2Nhc2UgIiR7VU5BTUVfTUFD
SElORX06JHtVTkFNRV9TWVNURU19OiR7VU5BTUVfUkVMRUFTRX06JHtVTkFNRV9WRVJTSU9OfSIg
aW4KKyAgICAqOk5ldEJTRDoqOiopCisJIyBOZXRCU0QgKG5ic2QpIHRhcmdldHMgc2hvdWxkICh3
aGVyZSBhcHBsaWNhYmxlKSBtYXRjaCBvbmUgb3IKKwkjIG1vcmUgb2YgdGhlIHR1cHBsZXM6ICot
Ki1uZXRic2RlbGYqLCAqLSotbmV0YnNkYW91dCosCisJIyAqLSotbmV0YnNkZWNvZmYqIGFuZCAq
LSotbmV0YnNkKi4gIEZvciB0YXJnZXRzIHRoYXQgcmVjZW50bHkKKwkjIHN3aXRjaGVkIHRvIEVM
RiwgKi0qLW5ldGJzZCogd291bGQgc2VsZWN0IHRoZSBvbGQKKwkjIG9iamVjdCBmaWxlIGZvcm1h
dC4gIFRoaXMgcHJvdmlkZXMgYm90aCBmb3J3YXJkCisJIyBjb21wYXRpYmlsaXR5IGFuZCBhIGNv
bnNpc3RlbnQgbWVjaGFuaXNtIGZvciBzZWxlY3RpbmcgdGhlCisJIyBvYmplY3QgZmlsZSBmb3Jt
YXQuCisJIworCSMgTm90ZTogTmV0QlNEIGRvZXNuJ3QgcGFydGljdWxhcmx5IGNhcmUgYWJvdXQg
dGhlIHZlbmRvcgorCSMgcG9ydGlvbiBvZiB0aGUgbmFtZS4gIFdlIGFsd2F5cyBzZXQgaXQgdG8g
InVua25vd24iLgorCXN5c2N0bD0ic3lzY3RsIC1uIGh3Lm1hY2hpbmVfYXJjaCIKKwlVTkFNRV9N
QUNISU5FX0FSQ0g9YCgvc2Jpbi8kc3lzY3RsIDI+L2Rldi9udWxsIHx8IFwKKwkgICAgL3Vzci9z
YmluLyRzeXNjdGwgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duKWAKKwljYXNlICIke1VOQU1F
X01BQ0hJTkVfQVJDSH0iIGluCisJICAgIGFybWViKSBtYWNoaW5lPWFybWViLXVua25vd24gOzsK
KwkgICAgYXJtKikgbWFjaGluZT1hcm0tdW5rbm93biA7OworCSAgICBzaDNlbCkgbWFjaGluZT1z
aGwtdW5rbm93biA7OworCSAgICBzaDNlYikgbWFjaGluZT1zaC11bmtub3duIDs7CisJICAgIHNo
NWVsKSBtYWNoaW5lPXNoNWxlLXVua25vd24gOzsKKwkgICAgKikgbWFjaGluZT0ke1VOQU1FX01B
Q0hJTkVfQVJDSH0tdW5rbm93biA7OworCWVzYWMKKwkjIFRoZSBPcGVyYXRpbmcgU3lzdGVtIGlu
Y2x1ZGluZyBvYmplY3QgZm9ybWF0LCBpZiBpdCBoYXMgc3dpdGNoZWQKKwkjIHRvIEVMRiByZWNl
bnRseSwgb3Igd2lsbCBpbiB0aGUgZnV0dXJlLgorCWNhc2UgIiR7VU5BTUVfTUFDSElORV9BUkNI
fSIgaW4KKwkgICAgYXJtKnxpMzg2fG02OGt8bnMzMmt8c2gzKnxzcGFyY3x2YXgpCisJCWV2YWwg
JHNldF9jY19mb3JfYnVpbGQKKwkJaWYgZWNobyBfX0VMRl9fIHwgJENDX0ZPUl9CVUlMRCAtRSAt
IDI+L2Rldi9udWxsIFwKKwkJCXwgZ3JlcCAtcSBfX0VMRl9fCisJCXRoZW4KKwkJICAgICMgT25j
ZSBhbGwgdXRpbGl0aWVzIGNhbiBiZSBFQ09GRiAobmV0YnNkZWNvZmYpIG9yIGEub3V0IChuZXRi
c2Rhb3V0KS4KKwkJICAgICMgUmV0dXJuIG5ldGJzZCBmb3IgZWl0aGVyLiAgRklYPworCQkgICAg
b3M9bmV0YnNkCisJCWVsc2UKKwkJICAgIG9zPW5ldGJzZGVsZgorCQlmaQorCQk7OworCSAgICAq
KQorCSAgICAgICAgb3M9bmV0YnNkCisJCTs7CisJZXNhYworCSMgVGhlIE9TIHJlbGVhc2UKKwkj
IERlYmlhbiBHTlUvTmV0QlNEIG1hY2hpbmVzIGhhdmUgYSBkaWZmZXJlbnQgdXNlcmxhbmQsIGFu
ZAorCSMgdGh1cywgbmVlZCBhIGRpc3RpbmN0IHRyaXBsZXQuIEhvd2V2ZXIsIHRoZXkgZG8gbm90
IG5lZWQKKwkjIGtlcm5lbCB2ZXJzaW9uIGluZm9ybWF0aW9uLCBzbyBpdCBjYW4gYmUgcmVwbGFj
ZWQgd2l0aCBhCisJIyBzdWl0YWJsZSB0YWcsIGluIHRoZSBzdHlsZSBvZiBsaW51eC1nbnUuCisJ
Y2FzZSAiJHtVTkFNRV9WRVJTSU9OfSIgaW4KKwkgICAgRGViaWFuKikKKwkJcmVsZWFzZT0nLWdu
dScKKwkJOzsKKwkgICAgKikKKwkJcmVsZWFzZT1gZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAt
ZSAncy9bLV9dLiovXC4vJ2AKKwkJOzsKKwllc2FjCisJIyBTaW5jZSBDUFVfVFlQRS1NQU5VRkFD
VFVSRVItS0VSTkVMLU9QRVJBVElOR19TWVNURU06CisJIyBjb250YWlucyByZWR1bmRhbnQgaW5m
b3JtYXRpb24sIHRoZSBzaG9ydGVyIGZvcm06CisJIyBDUFVfVFlQRS1NQU5VRkFDVFVSRVItT1BF
UkFUSU5HX1NZU1RFTSBpcyB1c2VkLgorCWVjaG8gIiR7bWFjaGluZX0tJHtvc30ke3JlbGVhc2V9
IgorCWV4aXQgOzsKKyAgICAqOk9wZW5CU0Q6KjoqKQorCVVOQU1FX01BQ0hJTkVfQVJDSD1gYXJj
aCB8IHNlZCAncy9PcGVuQlNELi8vJ2AKKwllY2hvICR7VU5BTUVfTUFDSElORV9BUkNIfS11bmtu
b3duLW9wZW5ic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgICo6ZWtrb0JTRDoqOiop
CisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tZWtrb2JzZCR7VU5BTUVfUkVMRUFTRX0K
KwlleGl0IDs7CisgICAgKjpTb2xpZEJTRDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVu
a25vd24tc29saWRic2Qke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG1hY3BwYzpNaXJC
U0Q6KjoqKQorCWVjaG8gcG93ZXJwYy11bmtub3duLW1pcmJzZCR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgKjpNaXJCU0Q6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3du
LW1pcmJzZCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgYWxwaGE6T1NGMToqOiopCisJ
Y2FzZSAkVU5BTUVfUkVMRUFTRSBpbgorCSo0LjApCisJCVVOQU1FX1JFTEVBU0U9YC91c3Ivc2Jp
bi9zaXplciAtdiB8IGF3ayAne3ByaW50ICQzfSdgCisJCTs7CisJKjUuKikKKwkgICAgICAgIFVO
QU1FX1JFTEVBU0U9YC91c3Ivc2Jpbi9zaXplciAtdiB8IGF3ayAne3ByaW50ICQ0fSdgCisJCTs7
CisJZXNhYworCSMgQWNjb3JkaW5nIHRvIENvbXBhcSwgL3Vzci9zYmluL3BzcmluZm8gaGFzIGJl
ZW4gYXZhaWxhYmxlIG9uCisJIyBPU0YvMSBhbmQgVHJ1NjQgc3lzdGVtcyBwcm9kdWNlZCBzaW5j
ZSAxOTk1LiAgSSBob3BlIHRoYXQKKwkjIGNvdmVycyBtb3N0IHN5c3RlbXMgcnVubmluZyB0b2Rh
eS4gIFRoaXMgY29kZSBwaXBlcyB0aGUgQ1BVCisJIyB0eXBlcyB0aHJvdWdoIGhlYWQgLW4gMSwg
c28gd2Ugb25seSBkZXRlY3QgdGhlIHR5cGUgb2YgQ1BVIDAuCisJQUxQSEFfQ1BVX1RZUEU9YC91
c3Ivc2Jpbi9wc3JpbmZvIC12IHwgc2VkIC1uIC1lICdzL14gIFRoZSBhbHBoYSBcKC4qXCkgcHJv
Y2Vzc29yLiokL1wxL3AnIHwgaGVhZCAtbiAxYAorCWNhc2UgIiRBTFBIQV9DUFVfVFlQRSIgaW4K
KwkgICAgIkVWNCAoMjEwNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGEiIDs7CisJICAgICJF
VjQuNSAoMjEwNjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGEiIDs7CisJICAgICJMQ0E0ICgy
MTA2Ni8yMTA2OCkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYSIgOzsKKwkgICAgIkVWNSAoMjEx
NjQpIikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjUiIDs7CisJICAgICJFVjUuNiAoMjExNjRB
KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY1NiIgOzsKKwkgICAgIkVWNS42ICgyMTE2NFBD
KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhcGNhNTYiIDs7CisJICAgICJFVjUuNyAoMjExNjRQ
QykiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYXBjYTU3IiA7OworCSAgICAiRVY2ICgyMTI2NCki
KQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NiIgOzsKKwkgICAgIkVWNi43ICgyMTI2NEEpIikK
KwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY3IiA7OworCSAgICAiRVY2LjhDQiAoMjEyNjRDKSIp
CisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY2OCIgOzsKKwkgICAgIkVWNi44QUwgKDIxMjY0Qiki
KQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjgiIDs7CisJICAgICJFVjYuOENYICgyMTI2NEQp
IikKKwkJVU5BTUVfTUFDSElORT0iYWxwaGFldjY4IiA7OworCSAgICAiRVY2LjlBICgyMTI2NC9F
VjY5QSkiKQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NjkiIDs7CisJICAgICJFVjcgKDIxMzY0
KSIpCisJCVVOQU1FX01BQ0hJTkU9ImFscGhhZXY3IiA7OworCSAgICAiRVY3LjkgKDIxMzY0QSki
KQorCQlVTkFNRV9NQUNISU5FPSJhbHBoYWV2NzkiIDs7CisJZXNhYworCSMgQSBQbi5uIHZlcnNp
b24gaXMgYSBwYXRjaGVkIHZlcnNpb24uCisJIyBBIFZuLm4gdmVyc2lvbiBpcyBhIHJlbGVhc2Vk
IHZlcnNpb24uCisJIyBBIFRuLm4gdmVyc2lvbiBpcyBhIHJlbGVhc2VkIGZpZWxkIHRlc3QgdmVy
c2lvbi4KKwkjIEEgWG4ubiB2ZXJzaW9uIGlzIGFuIHVucmVsZWFzZWQgZXhwZXJpbWVudGFsIGJh
c2VsZXZlbC4KKwkjIDEuMiB1c2VzICIxLjIiIGZvciB1bmFtZSAtci4KKwllY2hvICR7VU5BTUVf
TUFDSElORX0tZGVjLW9zZmBlY2hvICR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXltQVlRY
XS8vJyB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3Bx
cnN0dXZ3eHl6J2AKKwlleGl0IDs7CisgICAgQWxwaGFcICo6V2luZG93c19OVCo6KikKKwkjIEhv
dyBkbyB3ZSBrbm93IGl0J3MgSW50ZXJpeCByYXRoZXIgdGhhbiB0aGUgZ2VuZXJpYyBQT1NJWCBz
dWJzeXN0ZW0/CisJIyBTaG91bGQgd2UgY2hhbmdlIFVOQU1FX01BQ0hJTkUgYmFzZWQgb24gdGhl
IG91dHB1dCBvZiB1bmFtZSBpbnN0ZWFkCisJIyBvZiB0aGUgc3BlY2lmaWMgQWxwaGEgbW9kZWw/
CisJZWNobyBhbHBoYS1wYy1pbnRlcml4CisJZXhpdCA7OworICAgIDIxMDY0OldpbmRvd3NfTlQ6
NTA6MykKKwllY2hvIGFscGhhLWRlYy13aW5udDMuNQorCWV4aXQgOzsKKyAgICBBbWlnYSo6VU5J
WF9TeXN0ZW1fVjo0LjA6KikKKwllY2hvIG02OGstdW5rbm93bi1zeXN2NAorCWV4aXQgOzsKKyAg
ICAqOltBYV1taWdhW09vXVtTc106KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3du
LWFtaWdhb3MKKwlleGl0IDs7CisgICAgKjpbTW1db3JwaFtPb11bU3NdOio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0tdW5rbm93bi1tb3JwaG9zCisJZXhpdCA7OworICAgICo6T1MvMzkwOio6
KikKKwllY2hvIGkzNzAtaWJtLW9wZW5lZGl0aW9uCisJZXhpdCA7OworICAgICo6ei9WTToqOiop
CisJZWNobyBzMzkwLWlibS16dm1vZQorCWV4aXQgOzsKKyAgICAqOk9TNDAwOio6KikKKyAgICAg
ICAgZWNobyBwb3dlcnBjLWlibS1vczQwMAorCWV4aXQgOzsKKyAgICBhcm06UklTQyo6MS5bMDEy
XSo6Knxhcm06cmlzY2l4OjEuWzAxMl0qOiopCisJZWNobyBhcm0tYWNvcm4tcmlzY2l4JHtVTkFN
RV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBhcm06cmlzY29zOio6Knxhcm06UklTQ09TOio6KikK
KwllY2hvIGFybS11bmtub3duLXJpc2NvcworCWV4aXQgOzsKKyAgICBTUjI/MDE6SEktVVgvTVBQ
Oio6KiB8IFNSODAwMDpISS1VWC9NUFA6KjoqKQorCWVjaG8gaHBwYTEuMS1oaXRhY2hpLWhpdXht
cHAKKwlleGl0IDs7CisgICAgUHlyYW1pZCo6T1N4KjoqOiogfCBNSVMqOk9TeCo6KjoqIHwgTUlT
KjpTTVBfREMtT1N4KjoqOiopCisJIyBha2VlQHdwZGlzMDMud3BhZmIuYWYubWlsIChFYXJsZSBG
LiBBa2UpIGNvbnRyaWJ1dGVkIE1JUyBhbmQgTklMRS4KKwlpZiB0ZXN0ICJgKC9iaW4vdW5pdmVy
c2UpIDI+L2Rldi9udWxsYCIgPSBhdHQgOyB0aGVuCisJCWVjaG8gcHlyYW1pZC1weXJhbWlkLXN5
c3YzCisJZWxzZQorCQllY2hvIHB5cmFtaWQtcHlyYW1pZC1ic2QKKwlmaQorCWV4aXQgOzsKKyAg
ICBOSUxFKjoqOio6ZGNvc3gpCisJZWNobyBweXJhbWlkLXB5cmFtaWQtc3ZyNAorCWV4aXQgOzsK
KyAgICBEUlM/NjAwMDp1bml4OjQuMDo2KikKKwllY2hvIHNwYXJjLWljbC1ueDYKKwlleGl0IDs7
CisgICAgRFJTPzYwMDA6VU5JWF9TVjo0LjIqOjcqIHwgRFJTPzYwMDA6aXNpczo0LjIqOjcqKQor
CWNhc2UgYC91c3IvYmluL3VuYW1lIC1wYCBpbgorCSAgICBzcGFyYykgZWNobyBzcGFyYy1pY2wt
bng3OyBleGl0IDs7CisJZXNhYyA7OworICAgIHMzOTB4OlN1bk9TOio6KikKKwllY2hvICR7VU5B
TUVfTUFDSElORX0taWJtLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3Mv
W14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjRIOlN1bk9TOjUuKjoqKQorCWVjaG8gc3BhcmMt
aGFsLXNvbGFyaXMyYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvW14uXSovLydgCisJ
ZXhpdCA7OworICAgIHN1bjQqOlN1bk9TOjUuKjoqIHwgdGFkcG9sZSo6U3VuT1M6NS4qOiopCisJ
ZWNobyBzcGFyYy1zdW4tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9b
Xi5dKi8vJ2AKKwlleGl0IDs7CisgICAgaTg2cGM6QXVyb3JhVVg6NS4qOiogfCBpODZ4ZW46QXVy
b3JhVVg6NS4qOiopCisJZWNobyBpMzg2LXBjLWF1cm9yYXV4JHtVTkFNRV9SRUxFQVNFfQorCWV4
aXQgOzsKKyAgICBpODZwYzpTdW5PUzo1Lio6KiB8IGk4NnhlbjpTdW5PUzo1Lio6KikKKwlldmFs
ICRzZXRfY2NfZm9yX2J1aWxkCisJU1VOX0FSQ0g9ImkzODYiCisJIyBJZiB0aGVyZSBpcyBhIGNv
bXBpbGVyLCBzZWUgaWYgaXQgaXMgY29uZmlndXJlZCBmb3IgNjQtYml0IG9iamVjdHMuCisJIyBO
b3RlIHRoYXQgdGhlIFN1biBjYyBkb2VzIG5vdCB0dXJuIF9fTFA2NF9fIGludG8gMSBsaWtlIGdj
YyBkb2VzLgorCSMgVGhpcyB0ZXN0IHdvcmtzIGZvciBib3RoIGNvbXBpbGVycy4KKwlpZiBbICIk
Q0NfRk9SX0JVSUxEIiAhPSAnbm9fY29tcGlsZXJfZm91bmQnIF07IHRoZW4KKwkgICAgaWYgKGVj
aG8gJyNpZmRlZiBfX2FtZDY0JzsgZWNobyBJU182NEJJVF9BUkNIOyBlY2hvICcjZW5kaWYnKSB8
IFwKKwkJKENDT1BUUz0gJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxsKSB8IFwKKwkJZ3Jl
cCBJU182NEJJVF9BUkNIID4vZGV2L251bGwKKwkgICAgdGhlbgorCQlTVU5fQVJDSD0ieDg2XzY0
IgorCSAgICBmaQorCWZpCisJZWNobyAke1NVTl9BUkNIfS1wYy1zb2xhcmlzMmBlY2hvICR7VU5B
TUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLy8nYAorCWV4aXQgOzsKKyAgICBzdW40KjpTdW5P
Uzo2KjoqKQorCSMgQWNjb3JkaW5nIHRvIGNvbmZpZy5zdWIsIHRoaXMgaXMgdGhlIHByb3BlciB3
YXkgdG8gY2Fub25pY2FsaXplCisJIyBTdW5PUzYuICBIYXJkIHRvIGd1ZXNzIGV4YWN0bHkgd2hh
dCBTdW5PUzYgd2lsbCBiZSBsaWtlLCBidXQKKwkjIGl0J3MgbGlrZWx5IHRvIGJlIG1vcmUgbGlr
ZSBTb2xhcmlzIHRoYW4gU3VuT1M0LgorCWVjaG8gc3BhcmMtc3VuLXNvbGFyaXMzYGVjaG8gJHtV
TkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvW14uXSovLydgCisJZXhpdCA7OworICAgIHN1bjQqOlN1
bk9TOio6KikKKwljYXNlICJgL3Vzci9iaW4vYXJjaCAta2AiIGluCisJICAgIFNlcmllcyp8UzQq
KQorCQlVTkFNRV9SRUxFQVNFPWB1bmFtZSAtdmAKKwkJOzsKKwllc2FjCisJIyBKYXBhbmVzZSBM
YW5ndWFnZSB2ZXJzaW9ucyBoYXZlIGEgdmVyc2lvbiBudW1iZXIgbGlrZSBgNC4xLjMtSkwnLgor
CWVjaG8gc3BhcmMtc3VuLXN1bm9zYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvLS9f
LydgCisJZXhpdCA7OworICAgIHN1bjMqOlN1bk9TOio6KikKKwllY2hvIG02OGstc3VuLXN1bm9z
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBzdW4qOio6NC4yQlNEOiopCisJVU5BTUVf
UkVMRUFTRT1gKHNlZCAxcSAvZXRjL21vdGQgfCBhd2sgJ3twcmludCBzdWJzdHIoJDUsMSwzKX0n
KSAyPi9kZXYvbnVsbGAKKwl0ZXN0ICJ4JHtVTkFNRV9SRUxFQVNFfSIgPSAieCIgJiYgVU5BTUVf
UkVMRUFTRT0zCisJY2FzZSAiYC9iaW4vYXJjaGAiIGluCisJICAgIHN1bjMpCisJCWVjaG8gbTY4
ay1zdW4tc3Vub3Mke1VOQU1FX1JFTEVBU0V9CisJCTs7CisJICAgIHN1bjQpCisJCWVjaG8gc3Bh
cmMtc3VuLXN1bm9zJHtVTkFNRV9SRUxFQVNFfQorCQk7OworCWVzYWMKKwlleGl0IDs7CisgICAg
YXVzaHA6U3VuT1M6KjoqKQorCWVjaG8gc3BhcmMtYXVzcGV4LXN1bm9zJHtVTkFNRV9SRUxFQVNF
fQorCWV4aXQgOzsKKyAgICAjIFRoZSBzaXR1YXRpb24gZm9yIE1pTlQgaXMgYSBsaXR0bGUgY29u
ZnVzaW5nLiAgVGhlIG1hY2hpbmUgbmFtZQorICAgICMgY2FuIGJlIHZpcnR1YWxseSBldmVyeXRo
aW5nIChldmVyeXRoaW5nIHdoaWNoIGlzIG5vdAorICAgICMgImF0YXJpc3QiIG9yICJhdGFyaXN0
ZSIgYXQgbGVhc3Qgc2hvdWxkIGhhdmUgYSBwcm9jZXNzb3IKKyAgICAjID4gbTY4MDAwKS4gIFRo
ZSBzeXN0ZW0gbmFtZSByYW5nZXMgZnJvbSAiTWlOVCIgb3ZlciAiRnJlZU1pTlQiCisgICAgIyB0
byB0aGUgbG93ZXJjYXNlIHZlcnNpb24gIm1pbnQiIChvciAiZnJlZW1pbnQiKS4gIEZpbmFsbHkK
KyAgICAjIHRoZSBzeXN0ZW0gbmFtZSAiVE9TIiBkZW5vdGVzIGEgc3lzdGVtIHdoaWNoIGlzIGFj
dHVhbGx5IG5vdAorICAgICMgTWlOVC4gIEJ1dCBNaU5UIGlzIGRvd253YXJkIGNvbXBhdGlibGUg
dG8gVE9TLCBzbyB0aGlzIHNob3VsZAorICAgICMgYmUgbm8gcHJvYmxlbS4KKyAgICBhdGFyaXN0
W2VdOipNaU5UOio6KiB8IGF0YXJpc3RbZV06Km1pbnQ6KjoqIHwgYXRhcmlzdFtlXToqVE9TOio6
KikKKyAgICAgICAgZWNobyBtNjhrLWF0YXJpLW1pbnQke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIGF0YXJpKjoqTWlOVDoqOiogfCBhdGFyaSo6Km1pbnQ6KjoqIHwgYXRhcmlzdFtlXToq
VE9TOio6KikKKwllY2hvIG02OGstYXRhcmktbWludCR7VU5BTUVfUkVMRUFTRX0KKyAgICAgICAg
ZXhpdCA7OworICAgICpmYWxjb24qOipNaU5UOio6KiB8ICpmYWxjb24qOiptaW50Oio6KiB8ICpm
YWxjb24qOipUT1M6KjoqKQorICAgICAgICBlY2hvIG02OGstYXRhcmktbWludCR7VU5BTUVfUkVM
RUFTRX0KKwlleGl0IDs7CisgICAgbWlsYW4qOipNaU5UOio6KiB8IG1pbGFuKjoqbWludDoqOiog
fCAqbWlsYW4qOipUT1M6KjoqKQorICAgICAgICBlY2hvIG02OGstbWlsYW4tbWludCR7VU5BTUVf
UkVMRUFTRX0KKyAgICAgICAgZXhpdCA7OworICAgIGhhZGVzKjoqTWlOVDoqOiogfCBoYWRlcyo6
Km1pbnQ6KjoqIHwgKmhhZGVzKjoqVE9TOio6KikKKyAgICAgICAgZWNobyBtNjhrLWhhZGVzLW1p
bnQke1VOQU1FX1JFTEVBU0V9CisgICAgICAgIGV4aXQgOzsKKyAgICAqOipNaU5UOio6KiB8ICo6
Km1pbnQ6KjoqIHwgKjoqVE9TOio6KikKKyAgICAgICAgZWNobyBtNjhrLXVua25vd24tbWludCR7
VU5BTUVfUkVMRUFTRX0KKyAgICAgICAgZXhpdCA7OworICAgIG02OGs6bWFjaHRlbjoqOiopCisJ
ZWNobyBtNjhrLWFwcGxlLW1hY2h0ZW4ke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIHBv
d2VycGM6bWFjaHRlbjoqOiopCisJZWNobyBwb3dlcnBjLWFwcGxlLW1hY2h0ZW4ke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIFJJU0MqOk1hY2g6KjoqKQorCWVjaG8gbWlwcy1kZWMtbWFj
aF9ic2Q0LjMKKwlleGl0IDs7CisgICAgUklTQyo6VUxUUklYOio6KikKKwllY2hvIG1pcHMtZGVj
LXVsdHJpeCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgVkFYKjpVTFRSSVgqOio6KikK
KwllY2hvIHZheC1kZWMtdWx0cml4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAyMDIw
OkNMSVg6KjoqIHwgMjQzMDpDTElYOio6KikKKwllY2hvIGNsaXBwZXItaW50ZXJncmFwaC1jbGl4
JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBtaXBzOio6KjpVTUlQUyB8IG1pcHM6Kjoq
OlJJU0NvcykKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14JLy8nIDw8IEVPRiA+
JGR1bW15LmMKKyNpZmRlZiBfX2NwbHVzcGx1cworI2luY2x1ZGUgPHN0ZGlvLmg+ICAvKiBmb3Ig
cHJpbnRmKCkgcHJvdG90eXBlICovCisJaW50IG1haW4gKGludCBhcmdjLCBjaGFyICphcmd2W10p
IHsKKyNlbHNlCisJaW50IG1haW4gKGFyZ2MsIGFyZ3YpIGludCBhcmdjOyBjaGFyICphcmd2W107
IHsKKyNlbmRpZgorCSNpZiBkZWZpbmVkIChob3N0X21pcHMpICYmIGRlZmluZWQgKE1JUFNFQikK
KwkjaWYgZGVmaW5lZCAoU1lTVFlQRV9TWVNWKQorCSAgcHJpbnRmICgibWlwcy1taXBzLXJpc2Nv
cyVzc3lzdlxuIiwgYXJndlsxXSk7IGV4aXQgKDApOworCSNlbmRpZgorCSNpZiBkZWZpbmVkIChT
WVNUWVBFX1NWUjQpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNzdnI0XG4iLCBhcmd2
WzFdKTsgZXhpdCAoMCk7CisJI2VuZGlmCisJI2lmIGRlZmluZWQgKFNZU1RZUEVfQlNENDMpIHx8
IGRlZmluZWQoU1lTVFlQRV9CU0QpCisJICBwcmludGYgKCJtaXBzLW1pcHMtcmlzY29zJXNic2Rc
biIsIGFyZ3ZbMV0pOyBleGl0ICgwKTsKKwkjZW5kaWYKKwkjZW5kaWYKKwkgIGV4aXQgKC0xKTsK
Kwl9CitFT0YKKwkkQ0NfRk9SX0JVSUxEIC1vICRkdW1teSAkZHVtbXkuYyAmJgorCSAgZHVtbXlh
cmc9YGVjaG8gIiR7VU5BTUVfUkVMRUFTRX0iIHwgc2VkIC1uICdzL1woWzAtOV0qXCkuKi9cMS9w
J2AgJiYKKwkgIFNZU1RFTV9OQU1FPWAkZHVtbXkgJGR1bW15YXJnYCAmJgorCSAgICB7IGVjaG8g
IiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKwllY2hvIG1pcHMtbWlwcy1yaXNjb3Mke1VOQU1FX1JF
TEVBU0V9CisJZXhpdCA7OworICAgIE1vdG9yb2xhOlBvd2VyTUFYX09TOio6KikKKwllY2hvIHBv
d2VycGMtbW90b3JvbGEtcG93ZXJtYXgKKwlleGl0IDs7CisgICAgTW90b3JvbGE6Kjo0LjM6UEw4
LSopCisJZWNobyBwb3dlcnBjLWhhcnJpcy1wb3dlcm1heAorCWV4aXQgOzsKKyAgICBOaWdodF9I
YXdrOio6KjpQb3dlck1BWF9PUyB8IFN5bmVyZ3k6UG93ZXJNQVhfT1M6KjoqKQorCWVjaG8gcG93
ZXJwYy1oYXJyaXMtcG93ZXJtYXgKKwlleGl0IDs7CisgICAgTmlnaHRfSGF3azpQb3dlcl9VTklY
Oio6KikKKwllY2hvIHBvd2VycGMtaGFycmlzLXBvd2VydW5peAorCWV4aXQgOzsKKyAgICBtODhr
OkNYL1VYOjcqOiopCisJZWNobyBtODhrLWhhcnJpcy1jeHV4NworCWV4aXQgOzsKKyAgICBtODhr
Oio6NCo6UjQqKQorCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2NAorCWV4aXQgOzsKKyAgICBtODhr
Oio6Myo6UjMqKQorCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2MworCWV4aXQgOzsKKyAgICBBVmlp
T046ZGd1eDoqOiopCisgICAgICAgICMgREcvVVggcmV0dXJucyBBVmlpT04gZm9yIGFsbCBhcmNo
aXRlY3R1cmVzCisgICAgICAgIFVOQU1FX1BST0NFU1NPUj1gL3Vzci9iaW4vdW5hbWUgLXBgCisJ
aWYgWyAkVU5BTUVfUFJPQ0VTU09SID0gbWM4ODEwMCBdIHx8IFsgJFVOQU1FX1BST0NFU1NPUiA9
IG1jODgxMTAgXQorCXRoZW4KKwkgICAgaWYgWyAke1RBUkdFVF9CSU5BUllfSU5URVJGQUNFfXgg
PSBtODhrZGd1eGVsZnggXSB8fCBcCisJICAgICAgIFsgJHtUQVJHRVRfQklOQVJZX0lOVEVSRkFD
RX14ID0geCBdCisJICAgIHRoZW4KKwkJZWNobyBtODhrLWRnLWRndXgke1VOQU1FX1JFTEVBU0V9
CisJICAgIGVsc2UKKwkJZWNobyBtODhrLWRnLWRndXhiY3Mke1VOQU1FX1JFTEVBU0V9CisJICAg
IGZpCisJZWxzZQorCSAgICBlY2hvIGk1ODYtZGctZGd1eCR7VU5BTUVfUkVMRUFTRX0KKwlmaQor
IAlleGl0IDs7CisgICAgTTg4KjpEb2xwaGluT1M6KjoqKQkjIERvbHBoaW5PUyAoU1ZSMykKKwll
Y2hvIG04OGstZG9scGhpbi1zeXN2MworCWV4aXQgOzsKKyAgICBNODgqOio6UjMqOiopCisJIyBE
ZWx0YSA4OGsgc3lzdGVtIHJ1bm5pbmcgU1ZSMworCWVjaG8gbTg4ay1tb3Rvcm9sYS1zeXN2Mwor
CWV4aXQgOzsKKyAgICBYRDg4KjoqOio6KikgIyBUZWt0cm9uaXggWEQ4OCBzeXN0ZW0gcnVubmlu
ZyBVVGVrViAoU1ZSMykKKwllY2hvIG04OGstdGVrdHJvbml4LXN5c3YzCisJZXhpdCA7OworICAg
IFRlazQzWzAtOV1bMC05XTpVVGVrOio6KikgIyBUZWt0cm9uaXggNDMwMCBzeXN0ZW0gcnVubmlu
ZyBVVGVrIChCU0QpCisJZWNobyBtNjhrLXRla3Ryb25peC1ic2QKKwlleGl0IDs7CisgICAgKjpJ
UklYKjoqOiopCisJZWNobyBtaXBzLXNnaS1pcml4YGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQg
LWUgJ3MvLS9fL2cnYAorCWV4aXQgOzsKKyAgICA/Pz8/Pz8/PzpBSVg/OlsxMl0uMToyKSAgICMg
QUlYIDIuMi4xIG9yIEFJWCAyLjEuMSBpcyBSVC9QQyBBSVguCisJZWNobyByb21wLWlibS1haXgg
ICAgICMgdW5hbWUgLW0gZ2l2ZXMgYW4gOCBoZXgtY29kZSBDUFUgaWQKKwlleGl0IDs7ICAgICAg
ICAgICAgICAgIyBOb3RlIHRoYXQ6IGVjaG8gIidgdW5hbWUgLXNgJyIgZ2l2ZXMgJ0FJWCAnCisg
ICAgaSo4NjpBSVg6KjoqKQorCWVjaG8gaTM4Ni1pYm0tYWl4CisJZXhpdCA7OworICAgIGlhNjQ6
QUlYOio6KikKKwlpZiBbIC14IC91c3IvYmluL29zbGV2ZWwgXSA7IHRoZW4KKwkJSUJNX1JFVj1g
L3Vzci9iaW4vb3NsZXZlbGAKKwllbHNlCisJCUlCTV9SRVY9JHtVTkFNRV9WRVJTSU9OfS4ke1VO
QU1FX1JFTEVBU0V9CisJZmkKKwllY2hvICR7VU5BTUVfTUFDSElORX0taWJtLWFpeCR7SUJNX1JF
Vn0KKwlleGl0IDs7CisgICAgKjpBSVg6MjozKQorCWlmIGdyZXAgYm9zMzI1IC91c3IvaW5jbHVk
ZS9zdGRpby5oID4vZGV2L251bGwgMj4mMTsgdGhlbgorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxk
CisJCXNlZCAncy9eCQkvLycgPDwgRU9GID4kZHVtbXkuYworCQkjaW5jbHVkZSA8c3lzL3N5c3Rl
bWNmZy5oPgorCisJCW1haW4oKQorCQkJeworCQkJaWYgKCFfX3Bvd2VyX3BjKCkpCisJCQkJZXhp
dCgxKTsKKwkJCXB1dHMoInBvd2VycGMtaWJtLWFpeDMuMi41Iik7CisJCQlleGl0KDApOworCQkJ
fQorRU9GCisJCWlmICRDQ19GT1JfQlVJTEQgLW8gJGR1bW15ICRkdW1teS5jICYmIFNZU1RFTV9O
QU1FPWAkZHVtbXlgCisJCXRoZW4KKwkJCWVjaG8gIiRTWVNURU1fTkFNRSIKKwkJZWxzZQorCQkJ
ZWNobyByczYwMDAtaWJtLWFpeDMuMi41CisJCWZpCisJZWxpZiBncmVwIGJvczMyNCAvdXNyL2lu
Y2x1ZGUvc3RkaW8uaCA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKwkJZWNobyByczYwMDAtaWJtLWFp
eDMuMi40CisJZWxzZQorCQllY2hvIHJzNjAwMC1pYm0tYWl4My4yCisJZmkKKwlleGl0IDs7Cisg
ICAgKjpBSVg6KjpbNDU2XSkKKwlJQk1fQ1BVX0lEPWAvdXNyL3NiaW4vbHNkZXYgLUMgLWMgcHJv
Y2Vzc29yIC1TIGF2YWlsYWJsZSB8IHNlZCAxcSB8IGF3ayAneyBwcmludCAkMSB9J2AKKwlpZiAv
dXNyL3NiaW4vbHNhdHRyIC1FbCAke0lCTV9DUFVfSUR9IHwgZ3JlcCAnIFBPV0VSJyA+L2Rldi9u
dWxsIDI+JjE7IHRoZW4KKwkJSUJNX0FSQ0g9cnM2MDAwCisJZWxzZQorCQlJQk1fQVJDSD1wb3dl
cnBjCisJZmkKKwlpZiBbIC14IC91c3IvYmluL29zbGV2ZWwgXSA7IHRoZW4KKwkJSUJNX1JFVj1g
L3Vzci9iaW4vb3NsZXZlbGAKKwllbHNlCisJCUlCTV9SRVY9JHtVTkFNRV9WRVJTSU9OfS4ke1VO
QU1FX1JFTEVBU0V9CisJZmkKKwllY2hvICR7SUJNX0FSQ0h9LWlibS1haXgke0lCTV9SRVZ9CisJ
ZXhpdCA7OworICAgICo6QUlYOio6KikKKwllY2hvIHJzNjAwMC1pYm0tYWl4CisJZXhpdCA7Owor
ICAgIGlibXJ0OjQuNEJTRDoqfHJvbXAtaWJtOkJTRDoqKQorCWVjaG8gcm9tcC1pYm0tYnNkNC40
CisJZXhpdCA7OworICAgIGlibXJ0OipCU0Q6Knxyb21wLWlibTpCU0Q6KikgICAgICAgICAgICAj
IGNvdmVycyBSVC9QQyBCU0QgYW5kCisJZWNobyByb21wLWlibS1ic2Qke1VOQU1FX1JFTEVBU0V9
ICAgIyA0LjMgd2l0aCB1bmFtZSBhZGRlZCB0bworCWV4aXQgOzsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICMgcmVwb3J0OiByb21wLWlibSBCU0QgNC4zCisgICAgKjpCT1NYOio6KikKKwll
Y2hvIHJzNjAwMC1idWxsLWJvc3gKKwlleGl0IDs7CisgICAgRFBYLzI/MDA6Qi5PLlMuOio6KikK
KwllY2hvIG02OGstYnVsbC1zeXN2MworCWV4aXQgOzsKKyAgICA5MDAwL1szNF0/Pzo0LjNic2Q6
MS4qOiopCisJZWNobyBtNjhrLWhwLWJzZAorCWV4aXQgOzsKKyAgICBocDMwMDo0LjRCU0Q6Kjoq
IHwgOTAwMC9bMzRdPz86NC4zYnNkOjIuKjoqKQorCWVjaG8gbTY4ay1ocC1ic2Q0LjQKKwlleGl0
IDs7CisgICAgOTAwMC9bMzQ2NzhdPz86SFAtVVg6KjoqKQorCUhQVVhfUkVWPWBlY2hvICR7VU5B
TUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLlswQl0qLy8nYAorCWNhc2UgIiR7VU5BTUVfTUFD
SElORX0iIGluCisJICAgIDkwMDAvMzE/ICkgICAgICAgICAgICBIUF9BUkNIPW02ODAwMCA7Owor
CSAgICA5MDAwL1szNF0/PyApICAgICAgICAgSFBfQVJDSD1tNjhrIDs7CisJICAgIDkwMDAvWzY3
OF1bMC05XVswLTldKQorCQlpZiBbIC14IC91c3IvYmluL2dldGNvbmYgXTsgdGhlbgorCQkgICAg
c2NfY3B1X3ZlcnNpb249YC91c3IvYmluL2dldGNvbmYgU0NfQ1BVX1ZFUlNJT04gMj4vZGV2L251
bGxgCisgICAgICAgICAgICAgICAgICAgIHNjX2tlcm5lbF9iaXRzPWAvdXNyL2Jpbi9nZXRjb25m
IFNDX0tFUk5FTF9CSVRTIDI+L2Rldi9udWxsYAorICAgICAgICAgICAgICAgICAgICBjYXNlICIk
e3NjX2NwdV92ZXJzaW9ufSIgaW4KKyAgICAgICAgICAgICAgICAgICAgICA1MjMpIEhQX0FSQ0g9
ImhwcGExLjAiIDs7ICMgQ1BVX1BBX1JJU0MxXzAKKyAgICAgICAgICAgICAgICAgICAgICA1Mjgp
IEhQX0FSQ0g9ImhwcGExLjEiIDs7ICMgQ1BVX1BBX1JJU0MxXzEKKyAgICAgICAgICAgICAgICAg
ICAgICA1MzIpICAgICAgICAgICAgICAgICAgICAgICMgQ1BVX1BBX1JJU0MyXzAKKyAgICAgICAg
ICAgICAgICAgICAgICAgIGNhc2UgIiR7c2Nfa2VybmVsX2JpdHN9IiBpbgorICAgICAgICAgICAg
ICAgICAgICAgICAgICAzMikgSFBfQVJDSD0iaHBwYTIuMG4iIDs7CisgICAgICAgICAgICAgICAg
ICAgICAgICAgIDY0KSBIUF9BUkNIPSJocHBhMi4wdyIgOzsKKwkJCSAgJycpIEhQX0FSQ0g9Imhw
cGEyLjAiIDs7ICAgIyBIUC1VWCAxMC4yMAorICAgICAgICAgICAgICAgICAgICAgICAgZXNhYyA7
OworICAgICAgICAgICAgICAgICAgICBlc2FjCisJCWZpCisJCWlmIFsgIiR7SFBfQVJDSH0iID0g
IiIgXTsgdGhlbgorCQkgICAgZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAorCQkgICAgc2VkICdzL14g
ICAgICAgICAgICAgIC8vJyA8PCBFT0YgPiRkdW1teS5jCisKKyAgICAgICAgICAgICAgI2RlZmlu
ZSBfSFBVWF9TT1VSQ0UKKyAgICAgICAgICAgICAgI2luY2x1ZGUgPHN0ZGxpYi5oPgorICAgICAg
ICAgICAgICAjaW5jbHVkZSA8dW5pc3RkLmg+CisKKyAgICAgICAgICAgICAgaW50IG1haW4gKCkK
KyAgICAgICAgICAgICAgeworICAgICAgICAgICAgICAjaWYgZGVmaW5lZChfU0NfS0VSTkVMX0JJ
VFMpCisgICAgICAgICAgICAgICAgICBsb25nIGJpdHMgPSBzeXNjb25mKF9TQ19LRVJORUxfQklU
Uyk7CisgICAgICAgICAgICAgICNlbmRpZgorICAgICAgICAgICAgICAgICAgbG9uZyBjcHUgID0g
c3lzY29uZiAoX1NDX0NQVV9WRVJTSU9OKTsKKworICAgICAgICAgICAgICAgICAgc3dpdGNoIChj
cHUpCisgICAgICAgICAgICAgIAl7CisgICAgICAgICAgICAgIAljYXNlIENQVV9QQV9SSVNDMV8w
OiBwdXRzICgiaHBwYTEuMCIpOyBicmVhazsKKyAgICAgICAgICAgICAgCWNhc2UgQ1BVX1BBX1JJ
U0MxXzE6IHB1dHMgKCJocHBhMS4xIik7IGJyZWFrOworICAgICAgICAgICAgICAJY2FzZSBDUFVf
UEFfUklTQzJfMDoKKyAgICAgICAgICAgICAgI2lmIGRlZmluZWQoX1NDX0tFUk5FTF9CSVRTKQor
ICAgICAgICAgICAgICAJICAgIHN3aXRjaCAoYml0cykKKyAgICAgICAgICAgICAgCQl7CisgICAg
ICAgICAgICAgIAkJY2FzZSA2NDogcHV0cyAoImhwcGEyLjB3Iik7IGJyZWFrOworICAgICAgICAg
ICAgICAJCWNhc2UgMzI6IHB1dHMgKCJocHBhMi4wbiIpOyBicmVhazsKKyAgICAgICAgICAgICAg
CQlkZWZhdWx0OiBwdXRzICgiaHBwYTIuMCIpOyBicmVhazsKKyAgICAgICAgICAgICAgCQl9IGJy
ZWFrOworICAgICAgICAgICAgICAjZWxzZSAgLyogIWRlZmluZWQoX1NDX0tFUk5FTF9CSVRTKSAq
LworICAgICAgICAgICAgICAJICAgIHB1dHMgKCJocHBhMi4wIik7IGJyZWFrOworICAgICAgICAg
ICAgICAjZW5kaWYKKyAgICAgICAgICAgICAgCWRlZmF1bHQ6IHB1dHMgKCJocHBhMS4wIik7IGJy
ZWFrOworICAgICAgICAgICAgICAJfQorICAgICAgICAgICAgICAgICAgZXhpdCAoMCk7CisgICAg
ICAgICAgICAgIH0KK0VPRgorCQkgICAgKENDT1BUUz0gJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkg
JGR1bW15LmMgMj4vZGV2L251bGwpICYmIEhQX0FSQ0g9YCRkdW1teWAKKwkJICAgIHRlc3QgLXog
IiRIUF9BUkNIIiAmJiBIUF9BUkNIPWhwcGEKKwkJZmkgOzsKKwllc2FjCisJaWYgWyAke0hQX0FS
Q0h9ID0gImhwcGEyLjB3IiBdCisJdGhlbgorCSAgICBldmFsICRzZXRfY2NfZm9yX2J1aWxkCisK
KwkgICAgIyBocHBhMi4wdy1ocC1ocHV4KiBoYXMgYSA2NC1iaXQga2VybmVsIGFuZCBhIGNvbXBp
bGVyIGdlbmVyYXRpbmcKKwkgICAgIyAzMi1iaXQgY29kZS4gIGhwcGE2NC1ocC1ocHV4KiBoYXMg
dGhlIHNhbWUga2VybmVsIGFuZCBhIGNvbXBpbGVyCisJICAgICMgZ2VuZXJhdGluZyA2NC1iaXQg
Y29kZS4gIEdOVSBhbmQgSFAgdXNlIGRpZmZlcmVudCBub21lbmNsYXR1cmU6CisJICAgICMKKwkg
ICAgIyAkIENDX0ZPUl9CVUlMRD1jYyAuL2NvbmZpZy5ndWVzcworCSAgICAjID0+IGhwcGEyLjB3
LWhwLWhwdXgxMS4yMworCSAgICAjICQgQ0NfRk9SX0JVSUxEPSJjYyArREEyLjB3IiAuL2NvbmZp
Zy5ndWVzcworCSAgICAjID0+IGhwcGE2NC1ocC1ocHV4MTEuMjMKKworCSAgICBpZiBlY2hvIF9f
TFA2NF9fIHwgKENDT1BUUz0gJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxsKSB8CisJCWdy
ZXAgLXEgX19MUDY0X18KKwkgICAgdGhlbgorCQlIUF9BUkNIPSJocHBhMi4wdyIKKwkgICAgZWxz
ZQorCQlIUF9BUkNIPSJocHBhNjQiCisJICAgIGZpCisJZmkKKwllY2hvICR7SFBfQVJDSH0taHAt
aHB1eCR7SFBVWF9SRVZ9CisJZXhpdCA7OworICAgIGlhNjQ6SFAtVVg6KjoqKQorCUhQVVhfUkVW
PWBlY2hvICR7VU5BTUVfUkVMRUFTRX18c2VkIC1lICdzL1teLl0qLlswQl0qLy8nYAorCWVjaG8g
aWE2NC1ocC1ocHV4JHtIUFVYX1JFVn0KKwlleGl0IDs7CisgICAgMzA1MCo6SEktVVg6KjoqKQor
CWV2YWwgJHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYwor
CSNpbmNsdWRlIDx1bmlzdGQuaD4KKwlpbnQKKwltYWluICgpCisJeworCSAgbG9uZyBjcHUgPSBz
eXNjb25mIChfU0NfQ1BVX1ZFUlNJT04pOworCSAgLyogVGhlIG9yZGVyIG1hdHRlcnMsIGJlY2F1
c2UgQ1BVX0lTX0hQX01DNjhLIGVycm9uZW91c2x5IHJldHVybnMKKwkgICAgIHRydWUgZm9yIENQ
VV9QQV9SSVNDMV8wLiAgQ1BVX0lTX1BBX1JJU0MgcmV0dXJucyBjb3JyZWN0CisJICAgICByZXN1
bHRzLCBob3dldmVyLiAgKi8KKwkgIGlmIChDUFVfSVNfUEFfUklTQyAoY3B1KSkKKwkgICAgewor
CSAgICAgIHN3aXRjaCAoY3B1KQorCQl7CisJCSAgY2FzZSBDUFVfUEFfUklTQzFfMDogcHV0cyAo
ImhwcGExLjAtaGl0YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQkgIGNhc2UgQ1BVX1BBX1JJU0Mx
XzE6IHB1dHMgKCJocHBhMS4xLWhpdGFjaGktaGl1eHdlMiIpOyBicmVhazsKKwkJICBjYXNlIENQ
VV9QQV9SSVNDMl8wOiBwdXRzICgiaHBwYTIuMC1oaXRhY2hpLWhpdXh3ZTIiKTsgYnJlYWs7CisJ
CSAgZGVmYXVsdDogcHV0cyAoImhwcGEtaGl0YWNoaS1oaXV4d2UyIik7IGJyZWFrOworCQl9CisJ
ICAgIH0KKwkgIGVsc2UgaWYgKENQVV9JU19IUF9NQzY4SyAoY3B1KSkKKwkgICAgcHV0cyAoIm02
OGstaGl0YWNoaS1oaXV4d2UyIik7CisJICBlbHNlIHB1dHMgKCJ1bmtub3duLWhpdGFjaGktaGl1
eHdlMiIpOworCSAgZXhpdCAoMCk7CisJfQorRU9GCisJJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkg
JGR1bW15LmMgJiYgU1lTVEVNX05BTUU9YCRkdW1teWAgJiYKKwkJeyBlY2hvICIkU1lTVEVNX05B
TUUiOyBleGl0OyB9CisJZWNobyB1bmtub3duLWhpdGFjaGktaGl1eHdlMgorCWV4aXQgOzsKKyAg
ICA5MDAwLzc/Pzo0LjNic2Q6KjoqIHwgOTAwMC84P1s3OV06NC4zYnNkOio6KiApCisJZWNobyBo
cHBhMS4xLWhwLWJzZAorCWV4aXQgOzsKKyAgICA5MDAwLzg/Pzo0LjNic2Q6KjoqKQorCWVjaG8g
aHBwYTEuMC1ocC1ic2QKKwlleGl0IDs7CisgICAgKjk/Pyo6TVBFL2lYOio6KiB8ICozMDAwKjpN
UEUvaVg6KjoqKQorCWVjaG8gaHBwYTEuMC1ocC1tcGVpeAorCWV4aXQgOzsKKyAgICBocDc/PzpP
U0YxOio6KiB8IGhwOD9bNzldOk9TRjE6KjoqICkKKwllY2hvIGhwcGExLjEtaHAtb3NmCisJZXhp
dCA7OworICAgIGhwOD8/Ok9TRjE6KjoqKQorCWVjaG8gaHBwYTEuMC1ocC1vc2YKKwlleGl0IDs7
CisgICAgaSo4NjpPU0YxOio6KikKKwlpZiBbIC14IC91c3Ivc2Jpbi9zeXN2ZXJzaW9uIF0gOyB0
aGVuCisJICAgIGVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLW9zZjFtaworCWVsc2UKKwkg
ICAgZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tb3NmMQorCWZpCisJZXhpdCA7OworICAg
IHBhcmlzYyo6TGl0ZXMqOio6KikKKwllY2hvIGhwcGExLjEtaHAtbGl0ZXMKKwlleGl0IDs7Cisg
ICAgQzEqOkNvbnZleE9TOio6KiB8IGNvbnZleDpDb252ZXhPUzpDMSo6KikKKwllY2hvIGMxLWNv
bnZleC1ic2QKKyAgICAgICAgZXhpdCA7OworICAgIEMyKjpDb252ZXhPUzoqOiogfCBjb252ZXg6
Q29udmV4T1M6QzIqOiopCisJaWYgZ2V0c3lzaW5mbyAtZiBzY2FsYXJfYWNjCisJdGhlbiBlY2hv
IGMzMi1jb252ZXgtYnNkCisJZWxzZSBlY2hvIGMyLWNvbnZleC1ic2QKKwlmaQorICAgICAgICBl
eGl0IDs7CisgICAgQzM0KjpDb252ZXhPUzoqOiogfCBjb252ZXg6Q29udmV4T1M6QzM0KjoqKQor
CWVjaG8gYzM0LWNvbnZleC1ic2QKKyAgICAgICAgZXhpdCA7OworICAgIEMzOCo6Q29udmV4T1M6
KjoqIHwgY29udmV4OkNvbnZleE9TOkMzOCo6KikKKwllY2hvIGMzOC1jb252ZXgtYnNkCisgICAg
ICAgIGV4aXQgOzsKKyAgICBDNCo6Q29udmV4T1M6KjoqIHwgY29udmV4OkNvbnZleE9TOkM0Kjoq
KQorCWVjaG8gYzQtY29udmV4LWJzZAorICAgICAgICBleGl0IDs7CisgICAgQ1JBWSpZLU1QOio6
KjoqKQorCWVjaG8geW1wLWNyYXktdW5pY29zJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9c
LlteLl0qJC8uWC8nCisJZXhpdCA7OworICAgIENSQVkqW0EtWl05MDoqOio6KikKKwllY2hvICR7
VU5BTUVfTUFDSElORX0tY3JheS11bmljb3Mke1VOQU1FX1JFTEVBU0V9IFwKKwl8IHNlZCAtZSAn
cy9DUkFZLipcKFtBLVpdOTBcKS9cMS8nIFwKKwkgICAgICAtZSB5L0FCQ0RFRkdISUpLTE1OT1BR
UlNUVVZXWFlaL2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6LyBcCisJICAgICAgLWUgJ3MvXC5b
Xi5dKiQvLlgvJworCWV4aXQgOzsKKyAgICBDUkFZKlRTOio6KjoqKQorCWVjaG8gdDkwLWNyYXkt
dW5pY29zJHtVTkFNRV9SRUxFQVNFfSB8IHNlZCAtZSAncy9cLlteLl0qJC8uWC8nCisJZXhpdCA7
OworICAgIENSQVkqVDNFOio6KjoqKQorCWVjaG8gYWxwaGFldjUtY3JheS11bmljb3NtayR7VU5B
TUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXC5bXi5dKiQvLlgvJworCWV4aXQgOzsKKyAgICBDUkFZ
KlNWMToqOio6KikKKwllY2hvIHN2MS1jcmF5LXVuaWNvcyR7VU5BTUVfUkVMRUFTRX0gfCBzZWQg
LWUgJ3MvXC5bXi5dKiQvLlgvJworCWV4aXQgOzsKKyAgICAqOlVOSUNPUy9tcDoqOiopCisJZWNo
byBjcmF5bnYtY3JheS11bmljb3NtcCR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvXC5bXi5d
KiQvLlgvJworCWV4aXQgOzsKKyAgICBGMzBbMDFdOlVOSVhfU3lzdGVtX1Y6KjoqIHwgRjcwMDpV
TklYX1N5c3RlbV9WOio6KikKKwlGVUpJVFNVX1BST0M9YHVuYW1lIC1tIHwgdHIgJ0FCQ0RFRkdI
SUpLTE1OT1BRUlNUVVZXWFlaJyAnYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXonYAorICAgICAg
ICBGVUpJVFNVX1NZUz1gdW5hbWUgLXAgfCB0ciAnQUJDREVGR0hJSktMTU5PUFFSU1RVVldYWVon
ICdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5eicgfCBzZWQgLWUgJ3MvXC8vLydgCisgICAgICAg
IEZVSklUU1VfUkVMPWBlY2hvICR7VU5BTUVfUkVMRUFTRX0gfCBzZWQgLWUgJ3MvIC9fLydgCisg
ICAgICAgIGVjaG8gIiR7RlVKSVRTVV9QUk9DfS1mdWppdHN1LSR7RlVKSVRTVV9TWVN9JHtGVUpJ
VFNVX1JFTH0iCisgICAgICAgIGV4aXQgOzsKKyAgICA1MDAwOlVOSVhfU3lzdGVtX1Y6NC4qOiop
CisgICAgICAgIEZVSklUU1VfU1lTPWB1bmFtZSAtcCB8IHRyICdBQkNERUZHSElKS0xNTk9QUVJT
VFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6JyB8IHNlZCAtZSAncy9cLy8vJ2AK
KyAgICAgICAgRlVKSVRTVV9SRUw9YGVjaG8gJHtVTkFNRV9SRUxFQVNFfSB8IHRyICdBQkNERUZH
SElKS0xNTk9QUVJTVFVWV1hZWicgJ2FiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6JyB8IHNlZCAt
ZSAncy8gL18vJ2AKKyAgICAgICAgZWNobyAic3BhcmMtZnVqaXRzdS0ke0ZVSklUU1VfU1lTfSR7
RlVKSVRTVV9SRUx9IgorCWV4aXQgOzsKKyAgICBpKjg2OkJTRC8zODY6KjoqIHwgaSo4NjpCU0Qv
T1M6KjoqIHwgKjpBc2NlbmRcIEVtYmVkZGVkL09TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElO
RX0tcGMtYnNkaSR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgc3BhcmMqOkJTRC9PUzoq
OiopCisJZWNobyBzcGFyYy11bmtub3duLWJzZGkke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7Owor
ICAgICo6QlNEL09TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1ic2RpJHtV
TkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOkZyZWVCU0Q6KjoqKQorCWNhc2UgJHtVTkFN
RV9NQUNISU5FfSBpbgorCSAgICBwYzk4KQorCQllY2hvIGkzODYtdW5rbm93bi1mcmVlYnNkYGVj
aG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvWy0oXS4qLy8nYCA7OworCSAgICBhbWQ2NCkK
KwkJZWNobyB4ODZfNjQtdW5rbm93bi1mcmVlYnNkYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQg
LWUgJ3MvWy0oXS4qLy8nYCA7OworCSAgICAqKQorCQllY2hvICR7VU5BTUVfTUFDSElORX0tdW5r
bm93bi1mcmVlYnNkYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MvWy0oXS4qLy8nYCA7
OworCWVzYWMKKwlleGl0IDs7CisgICAgaSo6Q1lHV0lOKjoqKQorCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS1wYy1jeWd3aW4KKwlleGl0IDs7CisgICAgKjpNSU5HVyo6KikKKwllY2hvICR7VU5BTUVf
TUFDSElORX0tcGMtbWluZ3czMgorCWV4aXQgOzsKKyAgICBpKjp3aW5kb3dzMzIqOiopCisgICAg
CSMgdW5hbWUgLW0gaW5jbHVkZXMgIi1wYyIgb24gdGhpcyBzeXN0ZW0uCisgICAgCWVjaG8gJHtV
TkFNRV9NQUNISU5FfS1taW5ndzMyCisJZXhpdCA7OworICAgIGkqOlBXKjoqKQorCWVjaG8gJHtV
TkFNRV9NQUNISU5FfS1wYy1wdzMyCisJZXhpdCA7OworICAgICo6SW50ZXJpeCo6KikKKyAgICAJ
Y2FzZSAke1VOQU1FX01BQ0hJTkV9IGluCisJICAgIHg4NikKKwkJZWNobyBpNTg2LXBjLWludGVy
aXgke1VOQU1FX1JFTEVBU0V9CisJCWV4aXQgOzsKKwkgICAgYXV0aGVudGljYW1kIHwgZ2VudWlu
ZWludGVsIHwgRU02NFQpCisJCWVjaG8geDg2XzY0LXVua25vd24taW50ZXJpeCR7VU5BTUVfUkVM
RUFTRX0KKwkJZXhpdCA7OworCSAgICBJQTY0KQorCQllY2hvIGlhNjQtdW5rbm93bi1pbnRlcml4
JHtVTkFNRV9SRUxFQVNFfQorCQlleGl0IDs7CisJZXNhYyA7OworICAgIFszNDVdODY6V2luZG93
c185NToqIHwgWzM0NV04NjpXaW5kb3dzXzk4OiogfCBbMzQ1XTg2OldpbmRvd3NfTlQ6KikKKwll
Y2hvIGkke1VOQU1FX01BQ0hJTkV9LXBjLW1rcworCWV4aXQgOzsKKyAgICA4NjY0OldpbmRvd3Nf
TlQ6KikKKwllY2hvIHg4Nl82NC1wYy1ta3MKKwlleGl0IDs7CisgICAgaSo6V2luZG93c19OVCo6
KiB8IFBlbnRpdW0qOldpbmRvd3NfTlQqOiopCisJIyBIb3cgZG8gd2Uga25vdyBpdCdzIEludGVy
aXggcmF0aGVyIHRoYW4gdGhlIGdlbmVyaWMgUE9TSVggc3Vic3lzdGVtPworCSMgSXQgYWxzbyBj
b25mbGljdHMgd2l0aCBwcmUtMi4wIHZlcnNpb25zIG9mIEFUJlQgVVdJTi4gU2hvdWxkIHdlCisJ
IyBVTkFNRV9NQUNISU5FIGJhc2VkIG9uIHRoZSBvdXRwdXQgb2YgdW5hbWUgaW5zdGVhZCBvZiBp
Mzg2PworCWVjaG8gaTU4Ni1wYy1pbnRlcml4CisJZXhpdCA7OworICAgIGkqOlVXSU4qOiopCisJ
ZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXV3aW4KKwlleGl0IDs7CisgICAgYW1kNjQ6Q1lHV0lO
KjoqOiogfCB4ODZfNjQ6Q1lHV0lOKjoqOiopCisJZWNobyB4ODZfNjQtdW5rbm93bi1jeWd3aW4K
KwlleGl0IDs7CisgICAgcCo6Q1lHV0lOKjoqKQorCWVjaG8gcG93ZXJwY2xlLXVua25vd24tY3ln
d2luCisJZXhpdCA7OworICAgIHByZXAqOlN1bk9TOjUuKjoqKQorCWVjaG8gcG93ZXJwY2xlLXVu
a25vd24tc29sYXJpczJgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bXi5dKi8vJ2AK
KwlleGl0IDs7CisgICAgKjpHTlU6KjoqKQorCSMgdGhlIEdOVSBzeXN0ZW0KKwllY2hvIGBlY2hv
ICR7VU5BTUVfTUFDSElORX18c2VkIC1lICdzLFstL10uKiQsLCdgLXVua25vd24tZ251YGVjaG8g
JHtVTkFNRV9SRUxFQVNFfXxzZWQgLWUgJ3MsLy4qJCwsJ2AKKwlleGl0IDs7CisgICAgKjpHTlUv
KjoqOiopCisJIyBvdGhlciBzeXN0ZW1zIHdpdGggR05VIGxpYmMgYW5kIHVzZXJsYW5kCisJZWNo
byAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tYGVjaG8gJHtVTkFNRV9TWVNURU19IHwgc2VkICdz
LF5bXi9dKi8sLCcgfCB0ciAnW0EtWl0nICdbYS16XSdgYGVjaG8gJHtVTkFNRV9SRUxFQVNFfXxz
ZWQgLWUgJ3MvWy0oXS4qLy8nYC1nbnUKKwlleGl0IDs7CisgICAgaSo4NjpNaW5peDoqOiopCisJ
ZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW1pbml4CisJZXhpdCA7OworICAgIGFscGhhOkxpbnV4
Oio6KikKKwljYXNlIGBzZWQgLW4gJy9eY3B1IG1vZGVsL3MvXi4qOiBcKC4qXCkvXDEvcCcgPCAv
cHJvYy9jcHVpbmZvYCBpbgorCSAgRVY1KSAgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjUgOzsKKwkg
IEVWNTYpICBVTkFNRV9NQUNISU5FPWFscGhhZXY1NiA7OworCSAgUENBNTYpIFVOQU1FX01BQ0hJ
TkU9YWxwaGFwY2E1NiA7OworCSAgUENBNTcpIFVOQU1FX01BQ0hJTkU9YWxwaGFwY2E1NiA7Owor
CSAgRVY2KSAgIFVOQU1FX01BQ0hJTkU9YWxwaGFldjYgOzsKKwkgIEVWNjcpICBVTkFNRV9NQUNI
SU5FPWFscGhhZXY2NyA7OworCSAgRVY2OCopIFVOQU1FX01BQ0hJTkU9YWxwaGFldjY4IDs7Cisg
ICAgICAgIGVzYWMKKwlvYmpkdW1wIC0tcHJpdmF0ZS1oZWFkZXJzIC9iaW4vc2ggfCBncmVwIC1x
IGxkLnNvLjEKKwlpZiB0ZXN0ICIkPyIgPSAwIDsgdGhlbiBMSUJDPSJsaWJjMSIgOyBlbHNlIExJ
QkM9IiIgOyBmaQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxpbnV4LWdudSR7TElC
Q30KKwlleGl0IDs7CisgICAgYXJtKjpMaW51eDoqOiopCisJZXZhbCAkc2V0X2NjX2Zvcl9idWls
ZAorCWlmIGVjaG8gX19BUk1fRUFCSV9fIHwgJENDX0ZPUl9CVUlMRCAtRSAtIDI+L2Rldi9udWxs
IFwKKwkgICAgfCBncmVwIC1xIF9fQVJNX0VBQklfXworCXRoZW4KKwkgICAgZWNobyAke1VOQU1F
X01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZWxzZQorCSAgICBlY2hvICR7VU5BTUVfTUFD
SElORX0tdW5rbm93bi1saW51eC1nbnVlYWJpCisJZmkKKwlleGl0IDs7CisgICAgYXZyMzIqOkxp
bnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwlleGl0
IDs7CisgICAgY3JpczpMaW51eDoqOiopCisJZWNobyBjcmlzLWF4aXMtbGludXgtZ251CisJZXhp
dCA7OworICAgIGNyaXN2MzI6TGludXg6KjoqKQorCWVjaG8gY3Jpc3YzMi1heGlzLWxpbnV4LWdu
dQorCWV4aXQgOzsKKyAgICBmcnY6TGludXg6KjoqKQorICAgIAllY2hvIGZydi11bmtub3duLWxp
bnV4LWdudQorCWV4aXQgOzsKKyAgICBpKjg2OkxpbnV4Oio6KikKKwlMSUJDPWdudQorCWV2YWwg
JHNldF9jY19mb3JfYnVpbGQKKwlzZWQgJ3MvXgkvLycgPDwgRU9GID4kZHVtbXkuYworCSNpZmRl
ZiBfX2RpZXRsaWJjX18KKwlMSUJDPWRpZXRsaWJjCisJI2VuZGlmCitFT0YKKwlldmFsIGAkQ0Nf
Rk9SX0JVSUxEIC1FICRkdW1teS5jIDI+L2Rldi9udWxsIHwgZ3JlcCAnXkxJQkMnYAorCWVjaG8g
IiR7VU5BTUVfTUFDSElORX0tcGMtbGludXgtJHtMSUJDfSIKKwlleGl0IDs7CisgICAgaWE2NDpM
aW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhp
dCA7OworICAgIG0zMnIqOkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93
bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgbTY4KjpMaW51eDoqOiopCisJZWNobyAke1VOQU1F
X01BQ0hJTkV9LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIG1pcHM6TGludXg6Kjoq
IHwgbWlwczY0OkxpbnV4Oio6KikKKwlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJc2VkICdzL14J
Ly8nIDw8IEVPRiA+JGR1bW15LmMKKwkjdW5kZWYgQ1BVCisJI3VuZGVmICR7VU5BTUVfTUFDSElO
RX0KKwkjdW5kZWYgJHtVTkFNRV9NQUNISU5FfWVsCisJI2lmIGRlZmluZWQoX19NSVBTRUxfXykg
fHwgZGVmaW5lZChfX01JUFNFTCkgfHwgZGVmaW5lZChfTUlQU0VMKSB8fCBkZWZpbmVkKE1JUFNF
TCkKKwlDUFU9JHtVTkFNRV9NQUNISU5FfWVsCisJI2Vsc2UKKwkjaWYgZGVmaW5lZChfX01JUFNF
Ql9fKSB8fCBkZWZpbmVkKF9fTUlQU0VCKSB8fCBkZWZpbmVkKF9NSVBTRUIpIHx8IGRlZmluZWQo
TUlQU0VCKQorCUNQVT0ke1VOQU1FX01BQ0hJTkV9CisJI2Vsc2UKKwlDUFU9CisJI2VuZGlmCisJ
I2VuZGlmCitFT0YKKwlldmFsIGAkQ0NfRk9SX0JVSUxEIC1FICRkdW1teS5jIDI+L2Rldi9udWxs
IHwgZ3JlcCAnXkNQVSdgCisJdGVzdCB4IiR7Q1BVfSIgIT0geCAmJiB7IGVjaG8gIiR7Q1BVfS11
bmtub3duLWxpbnV4LWdudSI7IGV4aXQ7IH0KKwk7OworICAgIG9yMzI6TGludXg6KjoqKQorCWVj
aG8gb3IzMi11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYWRyZTpMaW51eDoqOiop
CisJZWNobyBzcGFyYy11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBwYXJpc2M2NDpM
aW51eDoqOiogfCBocHBhNjQ6TGludXg6KjoqKQorCWVjaG8gaHBwYTY0LXVua25vd24tbGludXgt
Z251CisJZXhpdCA7OworICAgIHBhcmlzYzpMaW51eDoqOiogfCBocHBhOkxpbnV4Oio6KikKKwkj
IExvb2sgZm9yIENQVSBsZXZlbAorCWNhc2UgYGdyZXAgJ15jcHVbXmEtel0qOicgL3Byb2MvY3B1
aW5mbyAyPi9kZXYvbnVsbCB8IGN1dCAtZCcgJyAtZjJgIGluCisJICBQQTcqKSBlY2hvIGhwcGEx
LjEtdW5rbm93bi1saW51eC1nbnUgOzsKKwkgIFBBOCopIGVjaG8gaHBwYTIuMC11bmtub3duLWxp
bnV4LWdudSA7OworCSAgKikgICAgZWNobyBocHBhLXVua25vd24tbGludXgtZ251IDs7CisJZXNh
YworCWV4aXQgOzsKKyAgICBwcGM2NDpMaW51eDoqOiopCisJZWNobyBwb3dlcnBjNjQtdW5rbm93
bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgcHBjOkxpbnV4Oio6KikKKwllY2hvIHBvd2VycGMt
dW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7CisgICAgczM5MDpMaW51eDoqOiogfCBzMzkweDpM
aW51eDoqOiopCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LWlibS1saW51eAorCWV4aXQgOzsKKyAg
ICBzaDY0KjpMaW51eDoqOiopCisgICAgCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLWxp
bnV4LWdudQorCWV4aXQgOzsKKyAgICBzaCo6TGludXg6KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNI
SU5FfS11bmtub3duLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICBzcGFyYzpMaW51eDoqOiogfCBz
cGFyYzY0OkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1n
bnUKKwlleGl0IDs7CisgICAgdmF4OkxpbnV4Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0t
ZGVjLWxpbnV4LWdudQorCWV4aXQgOzsKKyAgICB4ODZfNjQ6TGludXg6KjoqKQorCWVjaG8geDg2
XzY0LXVua25vd24tbGludXgtZ251CisJZXhpdCA7OworICAgIHh0ZW5zYSo6TGludXg6KjoqKQor
ICAgIAllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1saW51eC1nbnUKKwlleGl0IDs7Cisg
ICAgaSo4NjpEWU5JWC9wdHg6NCo6KikKKwkjIHB0eCA0LjAgZG9lcyB1bmFtZSAtcyBjb3JyZWN0
bHksIHdpdGggRFlOSVgvcHR4IGluIHRoZXJlLgorCSMgZWFybGllciB2ZXJzaW9ucyBhcmUgbWVz
c2VkIHVwIGFuZCBwdXQgdGhlIG5vZGVuYW1lIGluIGJvdGgKKwkjIHN5c25hbWUgYW5kIG5vZGVu
YW1lLgorCWVjaG8gaTM4Ni1zZXF1ZW50LXN5c3Y0CisJZXhpdCA7OworICAgIGkqODY6VU5JWF9T
Vjo0LjJNUDoyLiopCisgICAgICAgICMgVW5peHdhcmUgaXMgYW4gb2Zmc2hvb3Qgb2YgU1ZSNCwg
YnV0IGl0IGhhcyBpdHMgb3duIHZlcnNpb24KKyAgICAgICAgIyBudW1iZXIgc2VyaWVzIHN0YXJ0
aW5nIHdpdGggMi4uLgorICAgICAgICAjIEkgYW0gbm90IHBvc2l0aXZlIHRoYXQgb3RoZXIgU1ZS
NCBzeXN0ZW1zIHdvbid0IG1hdGNoIHRoaXMsCisJIyBJIGp1c3QgaGF2ZSB0byBob3BlLiAgLS0g
cm1zLgorICAgICAgICAjIFVzZSBzeXN2NC4ydXcuLi4gc28gdGhhdCBzeXN2NCogbWF0Y2hlcyBp
dC4KKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtc3lzdjQuMnV3JHtVTkFNRV9WRVJTSU9OfQor
CWV4aXQgOzsKKyAgICBpKjg2Ok9TLzI6KjoqKQorCSMgSWYgd2Ugd2VyZSBhYmxlIHRvIGZpbmQg
YHVuYW1lJywgdGhlbiBFTVggVW5peCBjb21wYXRpYmlsaXR5CisJIyBpcyBwcm9iYWJseSBpbnN0
YWxsZWQuCisJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLW9zMi1lbXgKKwlleGl0IDs7CisgICAg
aSo4NjpYVFMtMzAwOio6U1RPUCkKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1zdG9w
CisJZXhpdCA7OworICAgIGkqODY6YXRoZW9zOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0t
dW5rbm93bi1hdGhlb3MKKwlleGl0IDs7CisgICAgaSo4NjpzeWxsYWJsZToqOiopCisJZWNobyAk
e1VOQU1FX01BQ0hJTkV9LXBjLXN5bGxhYmxlCisJZXhpdCA7OworICAgIGkqODY6THlueE9TOjIu
KjoqIHwgaSo4NjpMeW54T1M6My5bMDFdKjoqIHwgaSo4NjpMeW54T1M6NC5bMDJdKjoqKQorCWVj
aG8gaTM4Ni11bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgaSo4
NjoqRE9TOio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tcGMtbXNkb3NkamdwcAorCWV4aXQg
OzsKKyAgICBpKjg2Oio6NC4qOiogfCBpKjg2OlNZU1RFTV9WOjQuKjoqKQorCVVOQU1FX1JFTD1g
ZWNobyAke1VOQU1FX1JFTEVBU0V9IHwgc2VkICdzL1wvTVAkLy8nYAorCWlmIGdyZXAgTm92ZWxs
IC91c3IvaW5jbHVkZS9saW5rLmggPi9kZXYvbnVsbCAyPi9kZXYvbnVsbDsgdGhlbgorCQllY2hv
ICR7VU5BTUVfTUFDSElORX0tdW5pdmVsLXN5c3Yke1VOQU1FX1JFTH0KKwllbHNlCisJCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS1wYy1zeXN2JHtVTkFNRV9SRUx9CisJZmkKKwlleGl0IDs7CisgICAg
aSo4NjoqOjU6WzY3OF0qKQorICAgIAkjIFVuaXhXYXJlIDcueCwgT3BlblVOSVggYW5kIE9wZW5T
ZXJ2ZXIgNi4KKwljYXNlIGAvYmluL3VuYW1lIC1YIHwgZ3JlcCAiXk1hY2hpbmUiYCBpbgorCSAg
ICAqNDg2KikJICAgICBVTkFNRV9NQUNISU5FPWk0ODYgOzsKKwkgICAgKlBlbnRpdW0pCSAgICAg
VU5BTUVfTUFDSElORT1pNTg2IDs7CisJICAgICpQZW50KnwqQ2VsZXJvbikgVU5BTUVfTUFDSElO
RT1pNjg2IDs7CisJZXNhYworCWVjaG8gJHtVTkFNRV9NQUNISU5FfS11bmtub3duLXN5c3Yke1VO
QU1FX1JFTEVBU0V9JHtVTkFNRV9TWVNURU19JHtVTkFNRV9WRVJTSU9OfQorCWV4aXQgOzsKKyAg
ICBpKjg2Oio6My4yOiopCisJaWYgdGVzdCAtZiAvdXNyL29wdGlvbnMvY2IubmFtZTsgdGhlbgor
CQlVTkFNRV9SRUw9YHNlZCAtbiAncy8uKlZlcnNpb24gLy9wJyA8L3Vzci9vcHRpb25zL2NiLm5h
bWVgCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1pc2MkVU5BTUVfUkVMCisJZWxpZiAvYmlu
L3VuYW1lIC1YIDI+L2Rldi9udWxsID4vZGV2L251bGwgOyB0aGVuCisJCVVOQU1FX1JFTD1gKC9i
aW4vdW5hbWUgLVh8Z3JlcCBSZWxlYXNlfHNlZCAtZSAncy8uKj0gLy8nKWAKKwkJKC9iaW4vdW5h
bWUgLVh8Z3JlcCBpODA0ODYgPi9kZXYvbnVsbCkgJiYgVU5BTUVfTUFDSElORT1pNDg2CisJCSgv
YmluL3VuYW1lIC1YfGdyZXAgJ15NYWNoaW5lLipQZW50aXVtJyA+L2Rldi9udWxsKSBcCisJCQkm
JiBVTkFNRV9NQUNISU5FPWk1ODYKKwkJKC9iaW4vdW5hbWUgLVh8Z3JlcCAnXk1hY2hpbmUuKlBl
bnQgKklJJyA+L2Rldi9udWxsKSBcCisJCQkmJiBVTkFNRV9NQUNISU5FPWk2ODYKKwkJKC9iaW4v
dW5hbWUgLVh8Z3JlcCAnXk1hY2hpbmUuKlBlbnRpdW0gUHJvJyA+L2Rldi9udWxsKSBcCisJCQkm
JiBVTkFNRV9NQUNISU5FPWk2ODYKKwkJZWNobyAke1VOQU1FX01BQ0hJTkV9LXBjLXNjbyRVTkFN
RV9SRUwKKwllbHNlCisJCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1zeXN2MzIKKwlmaQorCWV4
aXQgOzsKKyAgICBwYzoqOio6KikKKwkjIExlZnQgaGVyZSBmb3IgY29tcGF0aWJpbGl0eToKKyAg
ICAgICAgIyB1bmFtZSAtbSBwcmludHMgZm9yIERKR1BQIGFsd2F5cyAncGMnLCBidXQgaXQgcHJp
bnRzIG5vdGhpbmcgYWJvdXQKKyAgICAgICAgIyB0aGUgcHJvY2Vzc29yLCBzbyB3ZSBwbGF5IHNh
ZmUgYnkgYXNzdW1pbmcgaTU4Ni4KKwkjIE5vdGU6IHdoYXRldmVyIHRoaXMgaXMsIGl0IE1VU1Qg
YmUgdGhlIHNhbWUgYXMgd2hhdCBjb25maWcuc3ViCisJIyBwcmludHMgZm9yIHRoZSAiZGpncHAi
IGhvc3QsIG9yIGVsc2UgR0RCIGNvbmZpZ3VyeSB3aWxsIGRlY2lkZSB0aGF0CisJIyB0aGlzIGlz
IGEgY3Jvc3MtYnVpbGQuCisJZWNobyBpNTg2LXBjLW1zZG9zZGpncHAKKyAgICAgICAgZXhpdCA7
OworICAgIEludGVsOk1hY2g6Myo6KikKKwllY2hvIGkzODYtcGMtbWFjaDMKKwlleGl0IDs7Cisg
ICAgcGFyYWdvbjoqOio6KikKKwllY2hvIGk4NjAtaW50ZWwtb3NmMQorCWV4aXQgOzsKKyAgICBp
ODYwOio6NC4qOiopICMgaTg2MC1TVlI0CisJaWYgZ3JlcCBTdGFyZGVudCAvdXNyL2luY2x1ZGUv
c3lzL3VhZG1pbi5oID4vZGV2L251bGwgMj4mMSA7IHRoZW4KKwkgIGVjaG8gaTg2MC1zdGFyZGVu
dC1zeXN2JHtVTkFNRV9SRUxFQVNFfSAjIFN0YXJkZW50IFZpc3RyYSBpODYwLVNWUjQKKwllbHNl
ICMgQWRkIG90aGVyIGk4NjAtU1ZSNCB2ZW5kb3JzIGJlbG93IGFzIHRoZXkgYXJlIGRpc2NvdmVy
ZWQuCisJICBlY2hvIGk4NjAtdW5rbm93bi1zeXN2JHtVTkFNRV9SRUxFQVNFfSAgIyBVbmtub3du
IGk4NjAtU1ZSNAorCWZpCisJZXhpdCA7OworICAgIG1pbmkqOkNUSVg6U1lTKjU6KikKKwkjICJt
aW5pZnJhbWUiCisJZWNobyBtNjgwMTAtY29udmVyZ2VudC1zeXN2CisJZXhpdCA7OworICAgIG1j
NjhrOlVOSVg6U1lTVEVNNTozLjUxbSkKKwllY2hvIG02OGstY29udmVyZ2VudC1zeXN2CisJZXhp
dCA7OworICAgIE02ODA/MDpELU5JWDo1LjM6KikKKwllY2hvIG02OGstZGlhYi1kbml4CisJZXhp
dCA7OworICAgIE02OCo6KjpSM1ZbNTY3OF0qOiopCisJdGVzdCAtciAvc3lzVjY4ICYmIHsgZWNo
byAnbTY4ay1tb3Rvcm9sYS1zeXN2JzsgZXhpdDsgfSA7OworICAgIDNbMzQ1XT8/Oio6NC4wOjMu
MCB8IDNbMzRdPz9BOio6NC4wOjMuMCB8IDNbMzRdPz8sKjoqOjQuMDozLjAgfCAzWzM0XT8/Lyo6
Kjo0LjA6My4wIHwgNDQwMDoqOjQuMDozLjAgfCA0ODUwOio6NC4wOjMuMCB8IFNLQTQwOio6NC4w
OjMuMCB8IFNEUzI6Kjo0LjA6My4wIHwgU0hHMjoqOjQuMDozLjAgfCBTNzUwMSo6Kjo0LjA6My4w
KQorCU9TX1JFTD0nJworCXRlc3QgLXIgL2V0Yy8ucmVsaWQgXAorCSYmIE9TX1JFTD0uYHNlZCAt
biAncy9bXiBdKiBbXiBdKiBcKFswLTldWzAtOV1cKS4qL1wxL3AnIDwgL2V0Yy8ucmVsaWRgCisJ
L2Jpbi91bmFtZSAtcCAyPi9kZXYvbnVsbCB8IGdyZXAgODYgPi9kZXYvbnVsbCBcCisJICAmJiB7
IGVjaG8gaTQ4Ni1uY3Itc3lzdjQuMyR7T1NfUkVMfTsgZXhpdDsgfQorCS9iaW4vdW5hbWUgLXAg
Mj4vZGV2L251bGwgfCAvYmluL2dyZXAgZW50aXVtID4vZGV2L251bGwgXAorCSAgJiYgeyBlY2hv
IGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0gOzsKKyAgICAzWzM0XT8/Oio6NC4w
OiogfCAzWzM0XT8/LCo6Kjo0LjA6KikKKyAgICAgICAgL2Jpbi91bmFtZSAtcCAyPi9kZXYvbnVs
bCB8IGdyZXAgODYgPi9kZXYvbnVsbCBcCisgICAgICAgICAgJiYgeyBlY2hvIGk0ODYtbmNyLXN5
c3Y0OyBleGl0OyB9IDs7CisgICAgTkNSKjoqOjQuMjoqIHwgTVBSQVMqOio6NC4yOiopCisJT1Nf
UkVMPScuMycKKwl0ZXN0IC1yIC9ldGMvLnJlbGlkIFwKKwkgICAgJiYgT1NfUkVMPS5gc2VkIC1u
ICdzL1teIF0qIFteIF0qIFwoWzAtOV1bMC05XVwpLiovXDEvcCcgPCAvZXRjLy5yZWxpZGAKKwkv
YmluL3VuYW1lIC1wIDI+L2Rldi9udWxsIHwgZ3JlcCA4NiA+L2Rldi9udWxsIFwKKwkgICAgJiYg
eyBlY2hvIGk0ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkvYmluL3VuYW1lIC1w
IDI+L2Rldi9udWxsIHwgL2Jpbi9ncmVwIGVudGl1bSA+L2Rldi9udWxsIFwKKwkgICAgJiYgeyBl
Y2hvIGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0KKwkvYmluL3VuYW1lIC1wIDI+
L2Rldi9udWxsIHwgL2Jpbi9ncmVwIHB0ZXJvbiA+L2Rldi9udWxsIFwKKwkgICAgJiYgeyBlY2hv
IGk1ODYtbmNyLXN5c3Y0LjMke09TX1JFTH07IGV4aXQ7IH0gOzsKKyAgICBtNjgqOkx5bnhPUzoy
Lio6KiB8IG02OCo6THlueE9TOjMuMCo6KikKKwllY2hvIG02OGstdW5rbm93bi1seW54b3Mke1VO
QU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAgIG1jNjgwMzA6VU5JWF9TeXN0ZW1fVjo0Lio6KikK
KwllY2hvIG02OGstYXRhcmktc3lzdjQKKwlleGl0IDs7CisgICAgVFNVTkFNSTpMeW54T1M6Mi4q
OiopCisJZWNobyBzcGFyYy11bmtub3duLWx5bnhvcyR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7
CisgICAgcnM2MDAwOkx5bnhPUzoyLio6KikKKwllY2hvIHJzNjAwMC11bmtub3duLWx5bnhvcyR7
VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgUG93ZXJQQzpMeW54T1M6Mi4qOiogfCBQb3dl
clBDOkx5bnhPUzozLlswMV0qOiogfCBQb3dlclBDOkx5bnhPUzo0LlswMl0qOiopCisJZWNobyBw
b3dlcnBjLXVua25vd24tbHlueG9zJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTTVtC
RV1TOlVOSVhfU1Y6KjoqKQorCWVjaG8gbWlwcy1kZGUtc3lzdiR7VU5BTUVfUkVMRUFTRX0KKwll
eGl0IDs7CisgICAgUk0qOlJlbGlhbnRVTklYLSo6KjoqKQorCWVjaG8gbWlwcy1zbmktc3lzdjQK
KwlleGl0IDs7CisgICAgUk0qOlNJTklYLSo6KjoqKQorCWVjaG8gbWlwcy1zbmktc3lzdjQKKwll
eGl0IDs7CisgICAgKjpTSU5JWC0qOio6KikKKwlpZiB1bmFtZSAtcCAyPi9kZXYvbnVsbCA+L2Rl
di9udWxsIDsgdGhlbgorCQlVTkFNRV9NQUNISU5FPWAodW5hbWUgLXApIDI+L2Rldi9udWxsYAor
CQllY2hvICR7VU5BTUVfTUFDSElORX0tc25pLXN5c3Y0CisJZWxzZQorCQllY2hvIG5zMzJrLXNu
aS1zeXN2CisJZmkKKwlleGl0IDs7CisgICAgUEVOVElVTToqOjQuMCo6KikgIyBVbmlzeXMgYENs
ZWFyUGF0aCBITVAgSVggNDAwMCcgU1ZSNC9NUCBlZmZvcnQKKyAgICAgICAgICAgICAgICAgICAg
ICAjIHNheXMgPFJpY2hhcmQuTS5CYXJ0ZWxAY2NNYWlsLkNlbnN1cy5HT1Y+CisgICAgICAgIGVj
aG8gaTU4Ni11bmlzeXMtc3lzdjQKKyAgICAgICAgZXhpdCA7OworICAgICo6VU5JWF9TeXN0ZW1f
Vjo0KjpGVFgqKQorCSMgRnJvbSBHZXJhbGQgSGV3ZXMgPGhld2VzQG9wZW5tYXJrZXQuY29tPi4K
KwkjIEhvdyBhYm91dCBkaWZmZXJlbnRpYXRpbmcgYmV0d2VlbiBzdHJhdHVzIGFyY2hpdGVjdHVy
ZXM/IC1kam0KKwllY2hvIGhwcGExLjEtc3RyYXR1cy1zeXN2NAorCWV4aXQgOzsKKyAgICAqOio6
KjpGVFgqKQorCSMgRnJvbSBzZWFuZkBzd2RjLnN0cmF0dXMuY29tLgorCWVjaG8gaTg2MC1zdHJh
dHVzLXN5c3Y0CisJZXhpdCA7OworICAgIGkqODY6Vk9TOio6KikKKwkjIEZyb20gUGF1bC5HcmVl
bkBzdHJhdHVzLmNvbS4KKwllY2hvICR7VU5BTUVfTUFDSElORX0tc3RyYXR1cy12b3MKKwlleGl0
IDs7CisgICAgKjpWT1M6KjoqKQorCSMgRnJvbSBQYXVsLkdyZWVuQHN0cmF0dXMuY29tLgorCWVj
aG8gaHBwYTEuMS1zdHJhdHVzLXZvcworCWV4aXQgOzsKKyAgICBtYzY4KjpBL1VYOio6KikKKwll
Y2hvIG02OGstYXBwbGUtYXV4JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBuZXdzKjpO
RVdTLU9TOjYqOiopCisJZWNobyBtaXBzLXNvbnktbmV3c29zNgorCWV4aXQgOzsKKyAgICBSWzM0
XTAwMDoqU3lzdGVtX1YqOio6KiB8IFI0MDAwOlVOSVhfU1lTVjoqOiogfCBSKjAwMDpVTklYX1NW
Oio6KikKKwlpZiBbIC1kIC91c3IvbmVjIF07IHRoZW4KKwkgICAgICAgIGVjaG8gbWlwcy1uZWMt
c3lzdiR7VU5BTUVfUkVMRUFTRX0KKwllbHNlCisJICAgICAgICBlY2hvIG1pcHMtdW5rbm93bi1z
eXN2JHtVTkFNRV9SRUxFQVNFfQorCWZpCisgICAgICAgIGV4aXQgOzsKKyAgICBCZUJveDpCZU9T
Oio6KikJIyBCZU9TIHJ1bm5pbmcgb24gaGFyZHdhcmUgbWFkZSBieSBCZSwgUFBDIG9ubHkuCisJ
ZWNobyBwb3dlcnBjLWJlLWJlb3MKKwlleGl0IDs7CisgICAgQmVNYWM6QmVPUzoqOiopCSMgQmVP
UyBydW5uaW5nIG9uIE1hYyBvciBNYWMgY2xvbmUsIFBQQyBvbmx5LgorCWVjaG8gcG93ZXJwYy1h
cHBsZS1iZW9zCisJZXhpdCA7OworICAgIEJlUEM6QmVPUzoqOiopCSMgQmVPUyBydW5uaW5nIG9u
IEludGVsIFBDIGNvbXBhdGlibGUuCisJZWNobyBpNTg2LXBjLWJlb3MKKwlleGl0IDs7CisgICAg
QmVQQzpIYWlrdToqOiopCSMgSGFpa3UgcnVubmluZyBvbiBJbnRlbCBQQyBjb21wYXRpYmxlLgor
CWVjaG8gaTU4Ni1wYy1oYWlrdQorCWV4aXQgOzsKKyAgICBTWC00OlNVUEVSLVVYOio6KikKKwll
Y2hvIHN4NC1uZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gtNTpT
VVBFUi1VWDoqOiopCisJZWNobyBzeDUtbmVjLXN1cGVydXgke1VOQU1FX1JFTEVBU0V9CisJZXhp
dCA7OworICAgIFNYLTY6U1VQRVItVVg6KjoqKQorCWVjaG8gc3g2LW5lYy1zdXBlcnV4JHtVTkFN
RV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICBTWC03OlNVUEVSLVVYOio6KikKKwllY2hvIHN4Ny1u
ZWMtc3VwZXJ1eCR7VU5BTUVfUkVMRUFTRX0KKwlleGl0IDs7CisgICAgU1gtODpTVVBFUi1VWDoq
OiopCisJZWNobyBzeDgtbmVjLXN1cGVydXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7OworICAg
IFNYLThSOlNVUEVSLVVYOio6KikKKwllY2hvIHN4OHItbmVjLXN1cGVydXgke1VOQU1FX1JFTEVB
U0V9CisJZXhpdCA7OworICAgIFBvd2VyKjpSaGFwc29keToqOiopCisJZWNobyBwb3dlcnBjLWFw
cGxlLXJoYXBzb2R5JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOlJoYXBzb2R5Oio6
KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tYXBwbGUtcmhhcHNvZHkke1VOQU1FX1JFTEVBU0V9
CisJZXhpdCA7OworICAgICo6RGFyd2luOio6KikKKwlVTkFNRV9QUk9DRVNTT1I9YHVuYW1lIC1w
YCB8fCBVTkFNRV9QUk9DRVNTT1I9dW5rbm93bgorCWNhc2UgJFVOQU1FX1BST0NFU1NPUiBpbgor
CSAgICBpMzg2KQorCQlldmFsICRzZXRfY2NfZm9yX2J1aWxkCisJCWlmIFsgIiRDQ19GT1JfQlVJ
TEQiICE9ICdub19jb21waWxlcl9mb3VuZCcgXTsgdGhlbgorCQkgIGlmIChlY2hvICcjaWZkZWYg
X19MUDY0X18nOyBlY2hvIElTXzY0QklUX0FSQ0g7IGVjaG8gJyNlbmRpZicpIHwgXAorCQkgICAg
ICAoQ0NPUFRTPSAkQ0NfRk9SX0JVSUxEIC1FIC0gMj4vZGV2L251bGwpIHwgXAorCQkgICAgICBn
cmVwIElTXzY0QklUX0FSQ0ggPi9kZXYvbnVsbAorCQkgIHRoZW4KKwkJICAgICAgVU5BTUVfUFJP
Q0VTU09SPSJ4ODZfNjQiCisJCSAgZmkKKwkJZmkgOzsKKwkgICAgdW5rbm93bikgVU5BTUVfUFJP
Q0VTU09SPXBvd2VycGMgOzsKKwllc2FjCisJZWNobyAke1VOQU1FX1BST0NFU1NPUn0tYXBwbGUt
ZGFyd2luJHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOnByb2NudG8qOio6KiB8ICo6
UU5YOlswMTIzNDU2Nzg5XSo6KikKKwlVTkFNRV9QUk9DRVNTT1I9YHVuYW1lIC1wYAorCWlmIHRl
c3QgIiRVTkFNRV9QUk9DRVNTT1IiID0gIng4NiI7IHRoZW4KKwkJVU5BTUVfUFJPQ0VTU09SPWkz
ODYKKwkJVU5BTUVfTUFDSElORT1wYworCWZpCisJZWNobyAke1VOQU1FX1BST0NFU1NPUn0tJHtV
TkFNRV9NQUNISU5FfS1udG8tcW54JHtVTkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOlFO
WDoqOjQqKQorCWVjaG8gaTM4Ni1wYy1xbngKKwlleGl0IDs7CisgICAgTlNFLT86Tk9OU1RPUF9L
RVJORUw6KjoqKQorCWVjaG8gbnNlLXRhbmRlbS1uc2ske1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7
OworICAgIE5TUi0/Ok5PTlNUT1BfS0VSTkVMOio6KikKKwllY2hvIG5zci10YW5kZW0tbnNrJHtV
TkFNRV9SRUxFQVNFfQorCWV4aXQgOzsKKyAgICAqOk5vblN0b3AtVVg6KjoqKQorCWVjaG8gbWlw
cy1jb21wYXEtbm9uc3RvcHV4CisJZXhpdCA7OworICAgIEJTMjAwMDpQT1NJWCo6KjoqKQorCWVj
aG8gYnMyMDAwLXNpZW1lbnMtc3lzdgorCWV4aXQgOzsKKyAgICBEUy8qOlVOSVhfU3lzdGVtX1Y6
KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS0ke1VOQU1FX1NZU1RFTX0tJHtVTkFNRV9SRUxF
QVNFfQorCWV4aXQgOzsKKyAgICAqOlBsYW45Oio6KikKKwkjICJ1bmFtZSAtbSIgaXMgbm90IGNv
bnNpc3RlbnQsIHNvIHVzZSAkY3B1dHlwZSBpbnN0ZWFkLiAzODYKKwkjIGlzIGNvbnZlcnRlZCB0
byBpMzg2IGZvciBjb25zaXN0ZW5jeSB3aXRoIG90aGVyIHg4NgorCSMgb3BlcmF0aW5nIHN5c3Rl
bXMuCisJaWYgdGVzdCAiJGNwdXR5cGUiID0gIjM4NiI7IHRoZW4KKwkgICAgVU5BTUVfTUFDSElO
RT1pMzg2CisJZWxzZQorCSAgICBVTkFNRV9NQUNISU5FPSIkY3B1dHlwZSIKKwlmaQorCWVjaG8g
JHtVTkFNRV9NQUNISU5FfS11bmtub3duLXBsYW45CisJZXhpdCA7OworICAgICo6VE9QUy0xMDoq
OiopCisJZWNobyBwZHAxMC11bmtub3duLXRvcHMxMAorCWV4aXQgOzsKKyAgICAqOlRFTkVYOio6
KikKKwllY2hvIHBkcDEwLXVua25vd24tdGVuZXgKKwlleGl0IDs7CisgICAgS1MxMDpUT1BTLTIw
Oio6KiB8IEtMMTA6VE9QUy0yMDoqOiogfCBUWVBFNDpUT1BTLTIwOio6KikKKwllY2hvIHBkcDEw
LWRlYy10b3BzMjAKKwlleGl0IDs7CisgICAgWEtMLTE6VE9QUy0yMDoqOiogfCBUWVBFNTpUT1BT
LTIwOio6KikKKwllY2hvIHBkcDEwLXhrbC10b3BzMjAKKwlleGl0IDs7CisgICAgKjpUT1BTLTIw
Oio6KikKKwllY2hvIHBkcDEwLXVua25vd24tdG9wczIwCisJZXhpdCA7OworICAgICo6SVRTOio6
KikKKwllY2hvIHBkcDEwLXVua25vd24taXRzCisJZXhpdCA7OworICAgIFNFSToqOio6U0VJVVgp
CisgICAgICAgIGVjaG8gbWlwcy1zZWktc2VpdXgke1VOQU1FX1JFTEVBU0V9CisJZXhpdCA7Owor
ICAgICo6RHJhZ29uRmx5Oio6KikKKwllY2hvICR7VU5BTUVfTUFDSElORX0tdW5rbm93bi1kcmFn
b25mbHlgZWNobyAke1VOQU1FX1JFTEVBU0V9fHNlZCAtZSAncy9bLShdLiovLydgCisJZXhpdCA7
OworICAgICo6KlZNUzoqOiopCisgICAgCVVOQU1FX01BQ0hJTkU9YCh1bmFtZSAtcCkgMj4vZGV2
L251bGxgCisJY2FzZSAiJHtVTkFNRV9NQUNISU5FfSIgaW4KKwkgICAgQSopIGVjaG8gYWxwaGEt
ZGVjLXZtcyA7IGV4aXQgOzsKKwkgICAgSSopIGVjaG8gaWE2NC1kZWMtdm1zIDsgZXhpdCA7Owor
CSAgICBWKikgZWNobyB2YXgtZGVjLXZtcyA7IGV4aXQgOzsKKwllc2FjIDs7CisgICAgKjpYRU5J
WDoqOlN5c1YpCisJZWNobyBpMzg2LXBjLXhlbml4CisJZXhpdCA7OworICAgIGkqODY6c2t5b3M6
KjoqKQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1za3lvc2BlY2hvICR7VU5BTUVfUkVMRUFT
RX1gIHwgc2VkIC1lICdzLyAuKiQvLycKKwlleGl0IDs7CisgICAgaSo4NjpyZG9zOio6KikKKwll
Y2hvICR7VU5BTUVfTUFDSElORX0tcGMtcmRvcworCWV4aXQgOzsKKyAgICBpKjg2OkFST1M6Kjoq
KQorCWVjaG8gJHtVTkFNRV9NQUNISU5FfS1wYy1hcm9zCisJZXhpdCA7OworZXNhYworCisjZWNo
byAnKE5vIHVuYW1lIGNvbW1hbmQgb3IgdW5hbWUgb3V0cHV0IG5vdCByZWNvZ25pemVkLiknIDE+
JjIKKyNlY2hvICIke1VOQU1FX01BQ0hJTkV9OiR7VU5BTUVfU1lTVEVNfToke1VOQU1FX1JFTEVB
U0V9OiR7VU5BTUVfVkVSU0lPTn0iIDE+JjIKKworZXZhbCAkc2V0X2NjX2Zvcl9idWlsZAorY2F0
ID4kZHVtbXkuYyA8PEVPRgorI2lmZGVmIF9TRVFVRU5UXworIyBpbmNsdWRlIDxzeXMvdHlwZXMu
aD4KKyMgaW5jbHVkZSA8c3lzL3V0c25hbWUuaD4KKyNlbmRpZgorbWFpbiAoKQoreworI2lmIGRl
ZmluZWQgKHNvbnkpCisjaWYgZGVmaW5lZCAoTUlQU0VCKQorICAvKiBCRkQgd2FudHMgImJzZCIg
aW5zdGVhZCBvZiAibmV3c29zIi4gIFBlcmhhcHMgQkZEIHNob3VsZCBiZSBjaGFuZ2VkLAorICAg
ICBJIGRvbid0IGtub3cuLi4uICAqLworICBwcmludGYgKCJtaXBzLXNvbnktYnNkXG4iKTsgZXhp
dCAoMCk7CisjZWxzZQorI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorICBwcmludGYgKCJtNjhrLXNv
bnktbmV3c29zJXNcbiIsCisjaWZkZWYgTkVXU09TNAorICAgICAgICAgICI0IgorI2Vsc2UKKwkg
ICIiCisjZW5kaWYKKyAgICAgICAgICk7IGV4aXQgKDApOworI2VuZGlmCisjZW5kaWYKKworI2lm
IGRlZmluZWQgKF9fYXJtKSAmJiBkZWZpbmVkIChfX2Fjb3JuKSAmJiBkZWZpbmVkIChfX3VuaXgp
CisgIHByaW50ZiAoImFybS1hY29ybi1yaXNjaXhcbiIpOyBleGl0ICgwKTsKKyNlbmRpZgorCisj
aWYgZGVmaW5lZCAoaHAzMDApICYmICFkZWZpbmVkIChocHV4KQorICBwcmludGYgKCJtNjhrLWhw
LWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyNpZiBkZWZpbmVkIChOZVhUKQorI2lmICFk
ZWZpbmVkIChfX0FSQ0hJVEVDVFVSRV9fKQorI2RlZmluZSBfX0FSQ0hJVEVDVFVSRV9fICJtNjhr
IgorI2VuZGlmCisgIGludCB2ZXJzaW9uOworICB2ZXJzaW9uPWAoaG9zdGluZm8gfCBzZWQgLW4g
J3MvLipOZVhUIE1hY2ggXChbMC05XSpcKS4qL1wxL3AnKSAyPi9kZXYvbnVsbGA7CisgIGlmICh2
ZXJzaW9uIDwgNCkKKyAgICBwcmludGYgKCIlcy1uZXh0LW5leHRzdGVwJWRcbiIsIF9fQVJDSElU
RUNUVVJFX18sIHZlcnNpb24pOworICBlbHNlCisgICAgcHJpbnRmICgiJXMtbmV4dC1vcGVuc3Rl
cCVkXG4iLCBfX0FSQ0hJVEVDVFVSRV9fLCB2ZXJzaW9uKTsKKyAgZXhpdCAoMCk7CisjZW5kaWYK
KworI2lmIGRlZmluZWQgKE1VTFRJTUFYKSB8fCBkZWZpbmVkIChuMTYpCisjaWYgZGVmaW5lZCAo
VU1BWFYpCisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1zeXN2XG4iKTsgZXhpdCAoMCk7CisjZWxz
ZQorI2lmIGRlZmluZWQgKENNVSkKKyAgcHJpbnRmICgibnMzMmstZW5jb3JlLW1hY2hcbiIpOyBl
eGl0ICgwKTsKKyNlbHNlCisgIHByaW50ZiAoIm5zMzJrLWVuY29yZS1ic2RcbiIpOyBleGl0ICgw
KTsKKyNlbmRpZgorI2VuZGlmCisjZW5kaWYKKworI2lmIGRlZmluZWQgKF9fMzg2QlNEX18pCisg
IHByaW50ZiAoImkzODYtcGMtYnNkXG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKworI2lmIGRlZmlu
ZWQgKHNlcXVlbnQpCisjaWYgZGVmaW5lZCAoaTM4NikKKyAgcHJpbnRmICgiaTM4Ni1zZXF1ZW50
LWR5bml4XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNpZiBkZWZpbmVkIChuczMyMDAwKQorICBw
cmludGYgKCJuczMyay1zZXF1ZW50LWR5bml4XG4iKTsgZXhpdCAoMCk7CisjZW5kaWYKKyNlbmRp
ZgorCisjaWYgZGVmaW5lZCAoX1NFUVVFTlRfKQorICAgIHN0cnVjdCB1dHNuYW1lIHVuOworCisg
ICAgdW5hbWUoJnVuKTsKKworICAgIGlmIChzdHJuY21wKHVuLnZlcnNpb24sICJWMiIsIDIpID09
IDApIHsKKwlwcmludGYgKCJpMzg2LXNlcXVlbnQtcHR4MlxuIik7IGV4aXQgKDApOworICAgIH0K
KyAgICBpZiAoc3RybmNtcCh1bi52ZXJzaW9uLCAiVjEiLCAyKSA9PSAwKSB7IC8qIFhYWCBpcyBW
MSBjb3JyZWN0PyAqLworCXByaW50ZiAoImkzODYtc2VxdWVudC1wdHgxXG4iKTsgZXhpdCAoMCk7
CisgICAgfQorICAgIHByaW50ZiAoImkzODYtc2VxdWVudC1wdHhcbiIpOyBleGl0ICgwKTsKKwor
I2VuZGlmCisKKyNpZiBkZWZpbmVkICh2YXgpCisjIGlmICFkZWZpbmVkICh1bHRyaXgpCisjICBp
bmNsdWRlIDxzeXMvcGFyYW0uaD4KKyMgIGlmIGRlZmluZWQgKEJTRCkKKyMgICBpZiBCU0QgPT0g
NDMKKyAgICAgIHByaW50ZiAoInZheC1kZWMtYnNkNC4zXG4iKTsgZXhpdCAoMCk7CisjICAgZWxz
ZQorIyAgICBpZiBCU0QgPT0gMTk5MDA2CisgICAgICBwcmludGYgKCJ2YXgtZGVjLWJzZDQuM3Jl
bm9cbiIpOyBleGl0ICgwKTsKKyMgICAgZWxzZQorICAgICAgcHJpbnRmICgidmF4LWRlYy1ic2Rc
biIpOyBleGl0ICgwKTsKKyMgICAgZW5kaWYKKyMgICBlbmRpZgorIyAgZWxzZQorICAgIHByaW50
ZiAoInZheC1kZWMtYnNkXG4iKTsgZXhpdCAoMCk7CisjICBlbmRpZgorIyBlbHNlCisgICAgcHJp
bnRmICgidmF4LWRlYy11bHRyaXhcbiIpOyBleGl0ICgwKTsKKyMgZW5kaWYKKyNlbmRpZgorCisj
aWYgZGVmaW5lZCAoYWxsaWFudCkgJiYgZGVmaW5lZCAoaTg2MCkKKyAgcHJpbnRmICgiaTg2MC1h
bGxpYW50LWJzZFxuIik7IGV4aXQgKDApOworI2VuZGlmCisKKyAgZXhpdCAoMSk7Cit9CitFT0YK
KworJENDX0ZPUl9CVUlMRCAtbyAkZHVtbXkgJGR1bW15LmMgMj4vZGV2L251bGwgJiYgU1lTVEVN
X05BTUU9YCRkdW1teWAgJiYKKwl7IGVjaG8gIiRTWVNURU1fTkFNRSI7IGV4aXQ7IH0KKworIyBB
cG9sbG9zIHB1dCB0aGUgc3lzdGVtIHR5cGUgaW4gdGhlIGVudmlyb25tZW50LgorCit0ZXN0IC1k
IC91c3IvYXBvbGxvICYmIHsgZWNobyAke0lTUH0tYXBvbGxvLSR7U1lTVFlQRX07IGV4aXQ7IH0K
KworIyBDb252ZXggdmVyc2lvbnMgdGhhdCBwcmVkYXRlIHVuYW1lIGNhbiB1c2UgZ2V0c3lzaW5m
bygxKQorCitpZiBbIC14IC91c3IvY29udmV4L2dldHN5c2luZm8gXQordGhlbgorICAgIGNhc2Ug
YGdldHN5c2luZm8gLWYgY3B1X3R5cGVgIGluCisgICAgYzEqKQorCWVjaG8gYzEtY29udmV4LWJz
ZAorCWV4aXQgOzsKKyAgICBjMiopCisJaWYgZ2V0c3lzaW5mbyAtZiBzY2FsYXJfYWNjCisJdGhl
biBlY2hvIGMzMi1jb252ZXgtYnNkCisJZWxzZSBlY2hvIGMyLWNvbnZleC1ic2QKKwlmaQorCWV4
aXQgOzsKKyAgICBjMzQqKQorCWVjaG8gYzM0LWNvbnZleC1ic2QKKwlleGl0IDs7CisgICAgYzM4
KikKKwllY2hvIGMzOC1jb252ZXgtYnNkCisJZXhpdCA7OworICAgIGM0KikKKwllY2hvIGM0LWNv
bnZleC1ic2QKKwlleGl0IDs7CisgICAgZXNhYworZmkKKworY2F0ID4mMiA8PEVPRgorJDA6IHVu
YWJsZSB0byBndWVzcyBzeXN0ZW0gdHlwZQorCitUaGlzIHNjcmlwdCwgbGFzdCBtb2RpZmllZCAk
dGltZXN0YW1wLCBoYXMgZmFpbGVkIHRvIHJlY29nbml6ZQordGhlIG9wZXJhdGluZyBzeXN0ZW0g
eW91IGFyZSB1c2luZy4gSXQgaXMgYWR2aXNlZCB0aGF0IHlvdQorZG93bmxvYWQgdGhlIG1vc3Qg
dXAgdG8gZGF0ZSB2ZXJzaW9uIG9mIHRoZSBjb25maWcgc2NyaXB0cyBmcm9tCisKKyAgaHR0cDov
L2dpdC5zYXZhbm5haC5nbnUub3JnL2dpdHdlYi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtm
PWNvbmZpZy5ndWVzcztoYj1IRUFECithbmQKKyAgaHR0cDovL2dpdC5zYXZhbm5haC5nbnUub3Jn
L2dpdHdlYi8/cD1jb25maWcuZ2l0O2E9YmxvYl9wbGFpbjtmPWNvbmZpZy5zdWI7aGI9SEVBRAor
CitJZiB0aGUgdmVyc2lvbiB5b3UgcnVuICgkMCkgaXMgYWxyZWFkeSB1cCB0byBkYXRlLCBwbGVh
c2UKK3NlbmQgdGhlIGZvbGxvd2luZyBkYXRhIGFuZCBhbnkgaW5mb3JtYXRpb24geW91IHRoaW5r
IG1pZ2h0IGJlCitwZXJ0aW5lbnQgdG8gPGNvbmZpZy1wYXRjaGVzQGdudS5vcmc+IGluIG9yZGVy
IHRvIHByb3ZpZGUgdGhlIG5lZWRlZAoraW5mb3JtYXRpb24gdG8gaGFuZGxlIHlvdXIgc3lzdGVt
LgorCitjb25maWcuZ3Vlc3MgdGltZXN0YW1wID0gJHRpbWVzdGFtcAorCit1bmFtZSAtbSA9IGAo
dW5hbWUgLW0pIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC1yID0gYCh1bmFt
ZSAtcikgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXMgPSBgKHVuYW1lIC1z
KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtdiA9IGAodW5hbWUgLXYpIDI+
L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKKworL3Vzci9iaW4vdW5hbWUgLXAgPSBgKC91c3Iv
YmluL3VuYW1lIC1wKSAyPi9kZXYvbnVsbGAKKy9iaW4vdW5hbWUgLVggICAgID0gYCgvYmluL3Vu
YW1lIC1YKSAyPi9kZXYvbnVsbGAKKworaG9zdGluZm8gICAgICAgICAgICAgICA9IGAoaG9zdGlu
Zm8pIDI+L2Rldi9udWxsYAorL2Jpbi91bml2ZXJzZSAgICAgICAgICA9IGAoL2Jpbi91bml2ZXJz
ZSkgMj4vZGV2L251bGxgCisvdXNyL2Jpbi9hcmNoIC1rICAgICAgID0gYCgvdXNyL2Jpbi9hcmNo
IC1rKSAyPi9kZXYvbnVsbGAKKy9iaW4vYXJjaCAgICAgICAgICAgICAgPSBgKC9iaW4vYXJjaCkg
Mj4vZGV2L251bGxgCisvdXNyL2Jpbi9vc2xldmVsICAgICAgID0gYCgvdXNyL2Jpbi9vc2xldmVs
KSAyPi9kZXYvbnVsbGAKKy91c3IvY29udmV4L2dldHN5c2luZm8gPSBgKC91c3IvY29udmV4L2dl
dHN5c2luZm8pIDI+L2Rldi9udWxsYAorCitVTkFNRV9NQUNISU5FID0gJHtVTkFNRV9NQUNISU5F
fQorVU5BTUVfUkVMRUFTRSA9ICR7VU5BTUVfUkVMRUFTRX0KK1VOQU1FX1NZU1RFTSAgPSAke1VO
QU1FX1NZU1RFTX0KK1VOQU1FX1ZFUlNJT04gPSAke1VOQU1FX1ZFUlNJT059CitFT0YKKworZXhp
dCAxCisKKyMgTG9jYWwgdmFyaWFibGVzOgorIyBldmFsOiAoYWRkLWhvb2sgJ3dyaXRlLWZpbGUt
aG9va3MgJ3RpbWUtc3RhbXApCisjIHRpbWUtc3RhbXAtc3RhcnQ6ICJ0aW1lc3RhbXA9JyIKKyMg
dGltZS1zdGFtcC1mb3JtYXQ6ICIlOnktJTAybS0lMDJkIgorIyB0aW1lLXN0YW1wLWVuZDogIici
CisjIEVuZDoKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NvbmZp
Zy5oLmluCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL2NvbmZpZy5oLmluCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCww
ICsxLDQ2OCBAQAorLyogY29uZmlnLmguaW4uICBHZW5lcmF0ZWQgZnJvbSBjb25maWd1cmUuYWMg
YnkgYXV0b2hlYWRlci4gICovCisKKy8qIERlZmluZSB0byBvbmUgb2YgYF9nZXRiNjcnLCBgR0VU
QjY3JywgYGdldGI2NycgZm9yIENyYXktMiBhbmQgQ3JheS1ZTVAKKyAgIHN5c3RlbXMuIFRoaXMg
ZnVuY3Rpb24gaXMgcmVxdWlyZWQgZm9yIGBhbGxvY2EuYycgc3VwcG9ydCBvbiB0aG9zZSBzeXN0
ZW1zLgorICAgKi8KKyN1bmRlZiBDUkFZX1NUQUNLU0VHX0VORAorCisvKiBEZWZpbmUgdG8gMSBp
ZiB1c2luZyBgYWxsb2NhLmMnLiAqLworI3VuZGVmIENfQUxMT0NBCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgYWxhcm0nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQUxBUk0K
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgYGFsbG9jYScsIGFzIGEgZnVuY3Rpb24gb3Ig
bWFjcm8uICovCisjdW5kZWYgSEFWRV9BTExPQ0EKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhh
dmUgPGFsbG9jYS5oPiBhbmQgaXQgc2hvdWxkIGJlIHVzZWQgKG5vdCBvbiBVbHRyaXgpLgorICAg
Ki8KKyN1bmRlZiBIQVZFX0FMTE9DQV9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSA8YXJwYS9pbmV0Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfQVJQQV9JTkVUX0gK
KworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBhdGV4aXQnIGZ1bmN0aW9uLiAqLwor
I3VuZGVmIEhBVkVfQVRFWElUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgYnpl
cm8nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfQlpFUk8KKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIGBjbG9ja19nZXR0aW1lJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0NM
T0NLX0dFVFRJTUUKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBkdXAyJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX0RVUDIKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUg
dGhlIDxmY250bC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0ZDTlRMX0gKKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBmZGF0YXN5bmMnIGZ1bmN0aW9uLiAqLworI3Vu
ZGVmIEhBVkVfRkRBVEFTWU5DCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZm9y
aycgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9GT1JLCisKKy8qIERlZmluZSB0byAxIGlmIGZz
ZWVrbyAoYW5kIHByZXN1bWFibHkgZnRlbGxvKSBleGlzdHMgYW5kIGlzIGRlY2xhcmVkLiAqLwor
I3VuZGVmIEhBVkVfRlNFRUtPCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgZnRy
dW5jYXRlJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0ZUUlVOQ0FURQorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldGN3ZCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9H
RVRDV0QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBnZXRob3N0YnluYW1lJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVEhPU1RCWU5BTUUKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIGBnZXRob3N0bmFtZScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9H
RVRIT1NUTkFNRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGdldHBhZ2VzaXpl
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0dFVFBBR0VTSVpFCisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgZ2V0dGltZW9mZGF5JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X0dFVFRJTUVPRkRBWQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYGluZXRfbnRv
YScgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9JTkVUX05UT0EKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIDxpbnR0eXBlcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZF
X0lOVFRZUEVTX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBpc2FzY2lpJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX0lTQVNDSUkKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBjcnlwdG8nIGxpYnJhcnkgKC1sY3J5cHRvKS4gKi8KKyN1bmRlZiBIQVZFX0xJ
QkNSWVBUTworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGxpYmludGwuaD4gaGVh
ZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9MSUJJTlRMX0gKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIGBydCcgbGlicmFyeSAoLWxydCkuICovCisjdW5kZWYgSEFWRV9MSUJSVAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHV1aWQnIGxpYnJhcnkgKC1sdXVpZCku
ICovCisjdW5kZWYgSEFWRV9MSUJVVUlECisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRo
ZSBgeWFqbCcgbGlicmFyeSAoLWx5YWpsKS4gKi8KKyN1bmRlZiBIQVZFX0xJQllBSkwKKworLyog
RGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGB6JyBsaWJyYXJ5ICgtbHopLiAqLworI3VuZGVm
IEhBVkVfTElCWgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPGxpbWl0cy5oPiBo
ZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX0xJTUlUU19ICisKKy8qIERlZmluZSB0byAxIGlm
IHlvdSBoYXZlIHRoZSBgbG9jYWx0aW1lX3InIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfTE9D
QUxUSU1FX1IKKworLyogRGVmaW5lIHRvIDEgaWYgeW91ciBzeXN0ZW0gaGFzIGEgR05VIGxpYmMg
Y29tcGF0aWJsZSBgbWFsbG9jJyBmdW5jdGlvbiwgYW5kCisgICB0byAwIG90aGVyd2lzZS4gKi8K
KyN1bmRlZiBIQVZFX01BTExPQworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPG1h
bGxvYy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01BTExPQ19ICisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWVtY2hyJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZF
X01FTUNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1lbW1vdmUnIGZ1bmN0
aW9uLiAqLworI3VuZGVmIEhBVkVfTUVNTU9WRQorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgPG1lbW9yeS5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX01FTU9SWV9ICisK
Ky8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgbWVtc2V0JyBmdW5jdGlvbi4gKi8KKyN1
bmRlZiBIQVZFX01FTVNFVAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG1rZGly
JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01LRElSCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBgbWtmaWZvJyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX01LRklGTworCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSBhIHdvcmtpbmcgYG1tYXAnIHN5c3RlbSBjYWxsLiAq
LworI3VuZGVmIEhBVkVfTU1BUAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYG11
bm1hcCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9NVU5NQVAKKworLyogRGVmaW5lIHRvIDEg
aWYgeW91IGhhdmUgdGhlIDxuZXRkYi5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX05F
VERCX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxuZXRpbmV0L2luLmg+IGhl
YWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfTkVUSU5FVF9JTl9ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSBgcGF0aGNvbmYnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfUEFU
SENPTkYKKworLyogRGVmaW5lIHRvIDEgaWYgdGhlIHN5c3RlbSBoYXMgdGhlIHR5cGUgYHB0cmRp
ZmZfdCcuICovCisjdW5kZWYgSEFWRV9QVFJESUZGX1QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
ciBzeXN0ZW0gaGFzIGEgR05VIGxpYmMgY29tcGF0aWJsZSBgcmVhbGxvYycgZnVuY3Rpb24sCisg
ICBhbmQgdG8gMCBvdGhlcndpc2UuICovCisjdW5kZWYgSEFWRV9SRUFMTE9DCisKKy8qIERlZmlu
ZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgcmVhbHBhdGgnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfUkVBTFBBVEgKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGByZWdjb21wJyBm
dW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1JFR0NPTVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIGBybWRpcicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9STURJUgorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHNlbGVjdCcgZnVuY3Rpb24uICovCisjdW5kZWYg
SEFWRV9TRUxFQ1QKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzZXRlbnYnIGZ1
bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU0VURU5WCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgc29ja2V0JyBmdW5jdGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NPQ0tFVAorCisvKiBE
ZWZpbmUgdG8gMSBpZiBzdGRib29sLmggY29uZm9ybXMgdG8gQzk5LiAqLworI3VuZGVmIEhBVkVf
U1REQk9PTF9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3RkZGVmLmg+IGhl
YWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1REREVGX0gKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIDxzdGRpbnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVERJ
TlRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN0ZGxpYi5oPiBoZWFkZXIg
ZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NURExJQl9ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSBgc3RyY2FzZWNtcCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJDQVNFQ01Q
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RyY2hyJyBmdW5jdGlvbi4gKi8K
KyN1bmRlZiBIQVZFX1NUUkNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0
cmNzcG4nIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSQ1NQTgorCisvKiBEZWZpbmUgdG8g
MSBpZiB5b3UgaGF2ZSB0aGUgYHN0cmR1cCcgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJE
VVAKKworLyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJlcnJvcicgZnVuY3Rpb24u
ICovCisjdW5kZWYgSEFWRV9TVFJFUlJPUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHN0cmluZ3MuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TVFJJTkdTX0gKKwor
LyogRGVmaW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIDxzdHJpbmcuaD4gaGVhZGVyIGZpbGUuICov
CisjdW5kZWYgSEFWRV9TVFJJTkdfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUg
YHN0cm5kdXAnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSTkRVUAorCisvKiBEZWZpbmUg
dG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnBicmsnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVf
U1RSUEJSSworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnJjaHInIGZ1bmN0
aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSUkNIUgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgYHN0cnNwbicgZnVuY3Rpb24uICovCisjdW5kZWYgSEFWRV9TVFJTUE4KKworLyogRGVm
aW5lIHRvIDEgaWYgeW91IGhhdmUgdGhlIGBzdHJzdHInIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhB
VkVfU1RSU1RSCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgc3RydG9sJyBmdW5j
dGlvbi4gKi8KKyN1bmRlZiBIQVZFX1NUUlRPTAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2
ZSB0aGUgYHN0cnRvdWwnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfU1RSVE9VTAorCisvKiBE
ZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHN0cnRvdWxsJyBmdW5jdGlvbi4gKi8KKyN1bmRl
ZiBIQVZFX1NUUlRPVUxMCisKKy8qIERlZmluZSB0byAxIGlmIGBzdF9ibGtzaXplJyBpcyBhIG1l
bWJlciBvZiBgc3RydWN0IHN0YXQnLiAqLworI3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxL
U0laRQorCisvKiBEZWZpbmUgdG8gMSBpZiBgc3RfYmxvY2tzJyBpcyBhIG1lbWJlciBvZiBgc3Ry
dWN0IHN0YXQnLiAqLworI3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfQkxPQ0tTCisKKy8qIERl
ZmluZSB0byAxIGlmIGBzdF9yZGV2JyBpcyBhIG1lbWJlciBvZiBgc3RydWN0IHN0YXQnLiAqLwor
I3VuZGVmIEhBVkVfU1RSVUNUX1NUQVRfU1RfUkRFVgorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3Vy
IGBzdHJ1Y3Qgc3RhdCcgaGFzIGBzdF9ibG9ja3MnLiBEZXByZWNhdGVkLCB1c2UKKyAgIGBIQVZF
X1NUUlVDVF9TVEFUX1NUX0JMT0NLUycgaW5zdGVhZC4gKi8KKyN1bmRlZiBIQVZFX1NUX0JMT0NL
UworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5c2xvZy5oPiBoZWFkZXIgZmls
ZS4gKi8KKyN1bmRlZiBIQVZFX1NZU0xPR19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZl
IHRoZSA8c3lzL2ZpbGUuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNfRklMRV9I
CisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8c3lzL2lvY3RsLmg+IGhlYWRlciBm
aWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX0lPQ1RMX0gKKworLyogRGVmaW5lIHRvIDEgaWYgeW91
IGhhdmUgdGhlIDxzeXMvbW91bnQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9TWVNf
TU9VTlRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9wYXJhbS5oPiBo
ZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19QQVJBTV9ICisKKy8qIERlZmluZSB0byAx
IGlmIHlvdSBoYXZlIHRoZSA8c3lzL3NvY2tldC5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBI
QVZFX1NZU19TT0NLRVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9z
dGF0dmZzLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1NUQVRWRlNfSAorCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy9zdGF0Lmg+IGhlYWRlciBmaWxlLiAq
LworI3VuZGVmIEhBVkVfU1lTX1NUQVRfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0
aGUgPHN5cy90aW1lLmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfU1lTX1RJTUVfSAor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHN5cy90eXBlcy5oPiBoZWFkZXIgZmls
ZS4gKi8KKyN1bmRlZiBIQVZFX1NZU19UWVBFU19ICisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBo
YXZlIHRoZSA8dGVybWlvcy5oPiBoZWFkZXIgZmlsZS4gKi8KKyN1bmRlZiBIQVZFX1RFUk1JT1Nf
SAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHR6c2V0JyBmdW5jdGlvbi4gKi8K
KyN1bmRlZiBIQVZFX1RaU0VUCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSBgdW5h
bWUnIGZ1bmN0aW9uLiAqLworI3VuZGVmIEhBVkVfVU5BTUUKKworLyogRGVmaW5lIHRvIDEgaWYg
eW91IGhhdmUgdGhlIDx1bmlzdGQuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9VTklT
VERfSAorCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgYHZmb3JrJyBmdW5jdGlvbi4g
Ki8KKyN1bmRlZiBIQVZFX1ZGT1JLCisKKy8qIERlZmluZSB0byAxIGlmIHlvdSBoYXZlIHRoZSA8
dmZvcmsuaD4gaGVhZGVyIGZpbGUuICovCisjdW5kZWYgSEFWRV9WRk9SS19ICisKKy8qIERlZmlu
ZSB0byAxIGlmIGBmb3JrJyB3b3Jrcy4gKi8KKyN1bmRlZiBIQVZFX1dPUktJTkdfRk9SSworCisv
KiBEZWZpbmUgdG8gMSBpZiBgdmZvcmsnIHdvcmtzLiAqLworI3VuZGVmIEhBVkVfV09SS0lOR19W
Rk9SSworCisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgaGF2ZSB0aGUgPHlhamwveWFqbF92ZXJzaW9u
Lmg+IGhlYWRlciBmaWxlLiAqLworI3VuZGVmIEhBVkVfWUFKTF9ZQUpMX1ZFUlNJT05fSAorCisv
KiBEZWZpbmUgdG8gMSBpZiB0aGUgc3lzdGVtIGhhcyB0aGUgdHlwZSBgX0Jvb2wnLiAqLworI3Vu
ZGVmIEhBVkVfX0JPT0wKKworLyogRGVmaW5lIHRvIDEgaWYgYGxzdGF0JyBkZXJlZmVyZW5jZXMg
YSBzeW1saW5rIHNwZWNpZmllZCB3aXRoIGEgdHJhaWxpbmcKKyAgIHNsYXNoLiAqLworI3VuZGVm
IExTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCisKKy8qIERlZmluZSB0byAxIGlmIGBtYWpv
cicsIGBtaW5vcicsIGFuZCBgbWFrZWRldicgYXJlIGRlY2xhcmVkIGluIDxta2Rldi5oPi4KKyAg
ICovCisjdW5kZWYgTUFKT1JfSU5fTUtERVYKKworLyogRGVmaW5lIHRvIDEgaWYgYG1ham9yJywg
YG1pbm9yJywgYW5kIGBtYWtlZGV2JyBhcmUgZGVjbGFyZWQgaW4KKyAgIDxzeXNtYWNyb3MuaD4u
ICovCisjdW5kZWYgTUFKT1JfSU5fU1lTTUFDUk9TCisKKy8qIERlZmluZSB0byB0aGUgYWRkcmVz
cyB3aGVyZSBidWcgcmVwb3J0cyBmb3IgdGhpcyBwYWNrYWdlIHNob3VsZCBiZSBzZW50LiAqLwor
I3VuZGVmIFBBQ0tBR0VfQlVHUkVQT1JUCisKKy8qIERlZmluZSB0byB0aGUgZnVsbCBuYW1lIG9m
IHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX05BTUUKKworLyogRGVmaW5lIHRvIHRo
ZSBmdWxsIG5hbWUgYW5kIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tB
R0VfU1RSSU5HCisKKy8qIERlZmluZSB0byB0aGUgb25lIHN5bWJvbCBzaG9ydCBuYW1lIG9mIHRo
aXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1RBUk5BTUUKKworLyogRGVmaW5lIHRvIHRo
ZSBob21lIHBhZ2UgZm9yIHRoaXMgcGFja2FnZS4gKi8KKyN1bmRlZiBQQUNLQUdFX1VSTAorCisv
KiBEZWZpbmUgdG8gdGhlIHZlcnNpb24gb2YgdGhpcyBwYWNrYWdlLiAqLworI3VuZGVmIFBBQ0tB
R0VfVkVSU0lPTgorCisvKiBJZiB1c2luZyB0aGUgQyBpbXBsZW1lbnRhdGlvbiBvZiBhbGxvY2Es
IGRlZmluZSBpZiB5b3Uga25vdyB0aGUKKyAgIGRpcmVjdGlvbiBvZiBzdGFjayBncm93dGggZm9y
IHlvdXIgc3lzdGVtOyBvdGhlcndpc2UgaXQgd2lsbCBiZQorICAgYXV0b21hdGljYWxseSBkZWR1
Y2VkIGF0IHJ1bnRpbWUuCisJU1RBQ0tfRElSRUNUSU9OID4gMCA9PiBncm93cyB0b3dhcmQgaGln
aGVyIGFkZHJlc3NlcworCVNUQUNLX0RJUkVDVElPTiA8IDAgPT4gZ3Jvd3MgdG93YXJkIGxvd2Vy
IGFkZHJlc3NlcworCVNUQUNLX0RJUkVDVElPTiA9IDAgPT4gZGlyZWN0aW9uIG9mIGdyb3d0aCB1
bmtub3duICovCisjdW5kZWYgU1RBQ0tfRElSRUNUSU9OCisKKy8qIERlZmluZSB0byAxIGlmIHlv
dSBoYXZlIHRoZSBBTlNJIEMgaGVhZGVyIGZpbGVzLiAqLworI3VuZGVmIFNURENfSEVBREVSUwor
CisvKiBEZWZpbmUgdG8gMSBpZiB5b3UgY2FuIHNhZmVseSBpbmNsdWRlIGJvdGggPHN5cy90aW1l
Lmg+IGFuZCA8dGltZS5oPi4gKi8KKyN1bmRlZiBUSU1FX1dJVEhfU1lTX1RJTUUKKworLyogRW5h
YmxlIGV4dGVuc2lvbnMgb24gQUlYIDMsIEludGVyaXguICAqLworI2lmbmRlZiBfQUxMX1NPVVJD
RQorIyB1bmRlZiBfQUxMX1NPVVJDRQorI2VuZGlmCisvKiBFbmFibGUgR05VIGV4dGVuc2lvbnMg
b24gc3lzdGVtcyB0aGF0IGhhdmUgdGhlbS4gICovCisjaWZuZGVmIF9HTlVfU09VUkNFCisjIHVu
ZGVmIF9HTlVfU09VUkNFCisjZW5kaWYKKy8qIEVuYWJsZSB0aHJlYWRpbmcgZXh0ZW5zaW9ucyBv
biBTb2xhcmlzLiAgKi8KKyNpZm5kZWYgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTCisjIHVuZGVm
IF9QT1NJWF9QVEhSRUFEX1NFTUFOVElDUworI2VuZGlmCisvKiBFbmFibGUgZXh0ZW5zaW9ucyBv
biBIUCBOb25TdG9wLiAgKi8KKyNpZm5kZWYgX1RBTkRFTV9TT1VSQ0UKKyMgdW5kZWYgX1RBTkRF
TV9TT1VSQ0UKKyNlbmRpZgorLyogRW5hYmxlIGdlbmVyYWwgZXh0ZW5zaW9ucyBvbiBTb2xhcmlz
LiAgKi8KKyNpZm5kZWYgX19FWFRFTlNJT05TX18KKyMgdW5kZWYgX19FWFRFTlNJT05TX18KKyNl
bmRpZgorCisKKy8qIERlZmluZSB0byAxIHRvIG1ha2UgZnNlZWtvIHZpc2libGUgb24gc29tZSBo
b3N0cyAoZS5nLiBnbGliYyAyLjIpLiAqLworI3VuZGVmIF9MQVJHRUZJTEVfU09VUkNFCisKKy8q
IERlZmluZSB0byAxIGlmIG9uIE1JTklYLiAqLworI3VuZGVmIF9NSU5JWAorCisvKiBEZWZpbmUg
dG8gMiBpZiB0aGUgc3lzdGVtIGRvZXMgbm90IHByb3ZpZGUgUE9TSVguMSBmZWF0dXJlcyBleGNl
cHQgd2l0aAorICAgdGhpcyBkZWZpbmVkLiAqLworI3VuZGVmIF9QT1NJWF8xX1NPVVJDRQorCisv
KiBEZWZpbmUgdG8gMSBpZiB5b3UgbmVlZCB0byBpbiBvcmRlciBmb3IgYHN0YXQnIGFuZCBvdGhl
ciB0aGluZ3MgdG8gd29yay4gKi8KKyN1bmRlZiBfUE9TSVhfU09VUkNFCisKKy8qIERlZmluZSBm
b3IgU29sYXJpcyAyLjUuMSBzbyB0aGUgdWludDMyX3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2gu
aD4sCisgICA8cHRocmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhl
IHR5cGVkZWYgd2VyZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2Ug
YSBzeW50YXggZXJyb3IuICovCisjdW5kZWYgX1VJTlQzMl9UCisKKy8qIERlZmluZSBmb3IgU29s
YXJpcyAyLjUuMSBzbyB0aGUgdWludDY0X3QgdHlwZWRlZiBmcm9tIDxzeXMvc3luY2guaD4sCisg
ICA8cHRocmVhZC5oPiwgb3IgPHNlbWFwaG9yZS5oPiBpcyBub3QgdXNlZC4gSWYgdGhlIHR5cGVk
ZWYgd2VyZSBhbGxvd2VkLCB0aGUKKyAgICNkZWZpbmUgYmVsb3cgd291bGQgY2F1c2UgYSBzeW50
YXggZXJyb3IuICovCisjdW5kZWYgX1VJTlQ2NF9UCisKKy8qIERlZmluZSBmb3IgU29sYXJpcyAy
LjUuMSBzbyB0aGUgdWludDhfdCB0eXBlZGVmIGZyb20gPHN5cy9zeW5jaC5oPiwKKyAgIDxwdGhy
ZWFkLmg+LCBvciA8c2VtYXBob3JlLmg+IGlzIG5vdCB1c2VkLiBJZiB0aGUgdHlwZWRlZiB3ZXJl
IGFsbG93ZWQsIHRoZQorICAgI2RlZmluZSBiZWxvdyB3b3VsZCBjYXVzZSBhIHN5bnRheCBlcnJv
ci4gKi8KKyN1bmRlZiBfVUlOVDhfVAorCisvKiBEZWZpbmUgdG8gYGludCcgaWYgPHN5cy90eXBl
cy5oPiBkb2Vzbid0IGRlZmluZS4gKi8KKyN1bmRlZiBnaWRfdAorCisvKiBEZWZpbmUgdG8gYF9f
aW5saW5lX18nIG9yIGBfX2lubGluZScgaWYgdGhhdCdzIHdoYXQgdGhlIEMgY29tcGlsZXIKKyAg
IGNhbGxzIGl0LCBvciB0byBub3RoaW5nIGlmICdpbmxpbmUnIGlzIG5vdCBzdXBwb3J0ZWQgdW5k
ZXIgYW55IG5hbWUuICAqLworI2lmbmRlZiBfX2NwbHVzcGx1cworI3VuZGVmIGlubGluZQorI2Vu
ZGlmCisKKy8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Yg
d2lkdGggZXhhY3RseSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBz
dGFuZGFyZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIGludDE2X3QKKwor
LyogRGVmaW5lIHRvIHRoZSB0eXBlIG9mIGEgc2lnbmVkIGludGVnZXIgdHlwZSBvZiB3aWR0aCBl
eGFjdGx5IDMyIGJpdHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJk
IGluY2x1ZGVzIGRvIG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50MzJfdAorCisvKiBEZWZp
bmUgdG8gdGhlIHR5cGUgb2YgYSBzaWduZWQgaW50ZWdlciB0eXBlIG9mIHdpZHRoIGV4YWN0bHkg
NjQgYml0cyBpZgorICAgc3VjaCBhIHR5cGUgZXhpc3RzIGFuZCB0aGUgc3RhbmRhcmQgaW5jbHVk
ZXMgZG8gbm90IGRlZmluZSBpdC4gKi8KKyN1bmRlZiBpbnQ2NF90CisKKy8qIERlZmluZSB0byB0
aGUgdHlwZSBvZiBhIHNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhhY3RseSA4IGJpdHMg
aWYgc3VjaAorICAgYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGluY2x1ZGVzIGRvIG5v
dCBkZWZpbmUgaXQuICovCisjdW5kZWYgaW50OF90CisKKy8qIERlZmluZSB0byBycGxfbWFsbG9j
IGlmIHRoZSByZXBsYWNlbWVudCBmdW5jdGlvbiBzaG91bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiBt
YWxsb2MKKworLyogRGVmaW5lIHRvIGBpbnQnIGlmIDxzeXMvdHlwZXMuaD4gZG9lcyBub3QgZGVm
aW5lLiAqLworI3VuZGVmIG1vZGVfdAorCisvKiBEZWZpbmUgdG8gYGxvbmcgaW50JyBpZiA8c3lz
L3R5cGVzLmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBvZmZfdAorCisvKiBEZWZpbmUg
dG8gYGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBkZWZpbmUuICovCisjdW5kZWYgcGlk
X3QKKworLyogRGVmaW5lIHRvIHJwbF9yZWFsbG9jIGlmIHRoZSByZXBsYWNlbWVudCBmdW5jdGlv
biBzaG91bGQgYmUgdXNlZC4gKi8KKyN1bmRlZiByZWFsbG9jCisKKy8qIERlZmluZSB0byB0aGUg
ZXF1aXZhbGVudCBvZiB0aGUgQzk5ICdyZXN0cmljdCcga2V5d29yZCwgb3IgdG8KKyAgIG5vdGhp
bmcgaWYgdGhpcyBpcyBub3Qgc3VwcG9ydGVkLiAgRG8gbm90IGRlZmluZSBpZiByZXN0cmljdCBp
cworICAgc3VwcG9ydGVkIGRpcmVjdGx5LiAgKi8KKyN1bmRlZiByZXN0cmljdAorLyogV29yayBh
cm91bmQgYSBidWcgaW4gU3VuIEMrKzogaXQgZG9lcyBub3Qgc3VwcG9ydCBfUmVzdHJpY3Qgb3IK
KyAgIF9fcmVzdHJpY3RfXywgZXZlbiB0aG91Z2ggdGhlIGNvcnJlc3BvbmRpbmcgU3VuIEMgY29t
cGlsZXIgZW5kcyB1cCB3aXRoCisgICAiI2RlZmluZSByZXN0cmljdCBfUmVzdHJpY3QiIG9yICIj
ZGVmaW5lIHJlc3RyaWN0IF9fcmVzdHJpY3RfXyIgaW4gdGhlCisgICBwcmV2aW91cyBsaW5lLiAg
UGVyaGFwcyBzb21lIGZ1dHVyZSB2ZXJzaW9uIG9mIFN1biBDKysgd2lsbCB3b3JrIHdpdGgKKyAg
IHJlc3RyaWN0OyBpZiBzbywgaG9wZWZ1bGx5IGl0IGRlZmluZXMgX19SRVNUUklDVCBsaWtlIFN1
biBDIGRvZXMuICAqLworI2lmIGRlZmluZWQgX19TVU5QUk9fQ0MgJiYgIWRlZmluZWQgX19SRVNU
UklDVAorIyBkZWZpbmUgX1Jlc3RyaWN0CisjIGRlZmluZSBfX3Jlc3RyaWN0X18KKyNlbmRpZgor
CisvKiBEZWZpbmUgdG8gYHVuc2lnbmVkIGludCcgaWYgPHN5cy90eXBlcy5oPiBkb2VzIG5vdCBk
ZWZpbmUuICovCisjdW5kZWYgc2l6ZV90CisKKy8qIERlZmluZSB0byBgaW50JyBpZiA8c3lzL3R5
cGVzLmg+IGRvZXMgbm90IGRlZmluZS4gKi8KKyN1bmRlZiBzc2l6ZV90CisKKy8qIERlZmluZSB0
byBgaW50JyBpZiA8c3lzL3R5cGVzLmg+IGRvZXNuJ3QgZGVmaW5lLiAqLworI3VuZGVmIHVpZF90
CisKKy8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Yg
d2lkdGggZXhhY3RseSAxNiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBz
dGFuZGFyZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQxNl90CisK
Ky8qIERlZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lk
dGggZXhhY3RseSAzMiBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFu
ZGFyZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQzMl90CisKKy8q
IERlZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGgg
ZXhhY3RseSA2NCBiaXRzIGlmCisgICBzdWNoIGEgdHlwZSBleGlzdHMgYW5kIHRoZSBzdGFuZGFy
ZCBpbmNsdWRlcyBkbyBub3QgZGVmaW5lIGl0LiAqLworI3VuZGVmIHVpbnQ2NF90CisKKy8qIERl
ZmluZSB0byB0aGUgdHlwZSBvZiBhbiB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgb2Ygd2lkdGggZXhh
Y3RseSA4IGJpdHMgaWYKKyAgIHN1Y2ggYSB0eXBlIGV4aXN0cyBhbmQgdGhlIHN0YW5kYXJkIGlu
Y2x1ZGVzIGRvIG5vdCBkZWZpbmUgaXQuICovCisjdW5kZWYgdWludDhfdAorCisvKiBEZWZpbmUg
YXMgYGZvcmsnIGlmIGB2Zm9yaycgZG9lcyBub3Qgd29yay4gKi8KKyN1bmRlZiB2Zm9yawpkaWZm
IC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY29uZmlnLnN1YgotLS0gL2Rl
di9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9jb25maWcu
c3ViCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDE3MDUgQEAKKyMh
IC9iaW4vc2gKKyMgQ29uZmlndXJhdGlvbiB2YWxpZGF0aW9uIHN1YnJvdXRpbmUgc2NyaXB0Lgor
IyAgIENvcHlyaWdodCAoQykgMTk5MiwgMTk5MywgMTk5NCwgMTk5NSwgMTk5NiwgMTk5NywgMTk5
OCwgMTk5OSwKKyMgICAyMDAwLCAyMDAxLCAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAyMDA2LCAy
MDA3LCAyMDA4LCAyMDA5CisjICAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCisKK3Rp
bWVzdGFtcD0nMjAwOS0xMS0yMCcKKworIyBUaGlzIGZpbGUgaXMgKGluIHByaW5jaXBsZSkgY29t
bW9uIHRvIEFMTCBHTlUgc29mdHdhcmUuCisjIFRoZSBwcmVzZW5jZSBvZiBhIG1hY2hpbmUgaW4g
dGhpcyBmaWxlIHN1Z2dlc3RzIHRoYXQgU09NRSBHTlUgc29mdHdhcmUKKyMgY2FuIGhhbmRsZSB0
aGF0IG1hY2hpbmUuICBJdCBkb2VzIG5vdCBpbXBseSBBTEwgR05VIHNvZnR3YXJlIGNhbi4KKyMK
KyMgVGhpcyBmaWxlIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFu
ZC9vciBtb2RpZnkKKyMgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJs
aWMgTGljZW5zZSBhcyBwdWJsaXNoZWQgYnkKKyMgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlv
bjsgZWl0aGVyIHZlcnNpb24gMiBvZiB0aGUgTGljZW5zZSwgb3IKKyMgKGF0IHlvdXIgb3B0aW9u
KSBhbnkgbGF0ZXIgdmVyc2lvbi4KKyMKKyMgVGhpcyBwcm9ncmFtIGlzIGRpc3RyaWJ1dGVkIGlu
IHRoZSBob3BlIHRoYXQgaXQgd2lsbCBiZSB1c2VmdWwsCisjIGJ1dCBXSVRIT1VUIEFOWSBXQVJS
QU5UWTsgd2l0aG91dCBldmVuIHRoZSBpbXBsaWVkIHdhcnJhbnR5IG9mCisjIE1FUkNIQU5UQUJJ
TElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKyMgR05V
IEdlbmVyYWwgUHVibGljIExpY2Vuc2UgZm9yIG1vcmUgZGV0YWlscy4KKyMKKyMgWW91IHNob3Vs
ZCBoYXZlIHJlY2VpdmVkIGEgY29weSBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UK
KyMgYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29m
dHdhcmUKKyMgRm91bmRhdGlvbiwgSW5jLiwgNTEgRnJhbmtsaW4gU3RyZWV0IC0gRmlmdGggRmxv
b3IsIEJvc3RvbiwgTUEKKyMgMDIxMTAtMTMwMSwgVVNBLgorIworIyBBcyBhIHNwZWNpYWwgZXhj
ZXB0aW9uIHRvIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSwgaWYgeW91CisjIGRpc3Ry
aWJ1dGUgdGhpcyBmaWxlIGFzIHBhcnQgb2YgYSBwcm9ncmFtIHRoYXQgY29udGFpbnMgYQorIyBj
b25maWd1cmF0aW9uIHNjcmlwdCBnZW5lcmF0ZWQgYnkgQXV0b2NvbmYsIHlvdSBtYXkgaW5jbHVk
ZSBpdCB1bmRlcgorIyB0aGUgc2FtZSBkaXN0cmlidXRpb24gdGVybXMgdGhhdCB5b3UgdXNlIGZv
ciB0aGUgcmVzdCBvZiB0aGF0IHByb2dyYW0uCisKKworIyBQbGVhc2Ugc2VuZCBwYXRjaGVzIHRv
IDxjb25maWctcGF0Y2hlc0BnbnUub3JnPi4gIFN1Ym1pdCBhIGNvbnRleHQKKyMgZGlmZiBhbmQg
YSBwcm9wZXJseSBmb3JtYXR0ZWQgR05VIENoYW5nZUxvZyBlbnRyeS4KKyMKKyMgQ29uZmlndXJh
dGlvbiBzdWJyb3V0aW5lIHRvIHZhbGlkYXRlIGFuZCBjYW5vbmljYWxpemUgYSBjb25maWd1cmF0
aW9uIHR5cGUuCisjIFN1cHBseSB0aGUgc3BlY2lmaWVkIGNvbmZpZ3VyYXRpb24gdHlwZSBhcyBh
biBhcmd1bWVudC4KKyMgSWYgaXQgaXMgaW52YWxpZCwgd2UgcHJpbnQgYW4gZXJyb3IgbWVzc2Fn
ZSBvbiBzdGRlcnIgYW5kIGV4aXQgd2l0aCBjb2RlIDEuCisjIE90aGVyd2lzZSwgd2UgcHJpbnQg
dGhlIGNhbm9uaWNhbCBjb25maWcgdHlwZSBvbiBzdGRvdXQgYW5kIHN1Y2NlZWQuCisKKyMgWW91
IGNhbiBnZXQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoaXMgc2NyaXB0IGZyb206CisjIGh0dHA6
Ly9naXQuc2F2YW5uYWguZ251Lm9yZy9naXR3ZWIvP3A9Y29uZmlnLmdpdDthPWJsb2JfcGxhaW47
Zj1jb25maWcuc3ViO2hiPUhFQUQKKworIyBUaGlzIGZpbGUgaXMgc3VwcG9zZWQgdG8gYmUgdGhl
IHNhbWUgZm9yIGFsbCBHTlUgcGFja2FnZXMKKyMgYW5kIHJlY29nbml6ZSBhbGwgdGhlIENQVSB0
eXBlcywgc3lzdGVtIHR5cGVzIGFuZCBhbGlhc2VzCisjIHRoYXQgYXJlIG1lYW5pbmdmdWwgd2l0
aCAqYW55KiBHTlUgc29mdHdhcmUuCisjIEVhY2ggcGFja2FnZSBpcyByZXNwb25zaWJsZSBmb3Ig
cmVwb3J0aW5nIHdoaWNoIHZhbGlkIGNvbmZpZ3VyYXRpb25zCisjIGl0IGRvZXMgbm90IHN1cHBv
cnQuICBUaGUgdXNlciBzaG91bGQgYmUgYWJsZSB0byBkaXN0aW5ndWlzaAorIyBhIGZhaWx1cmUg
dG8gc3VwcG9ydCBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZnJvbSBhIG1lYW5pbmdsZXNzCisjIGNv
bmZpZ3VyYXRpb24uCisKKyMgVGhlIGdvYWwgb2YgdGhpcyBmaWxlIGlzIHRvIG1hcCBhbGwgdGhl
IHZhcmlvdXMgdmFyaWF0aW9ucyBvZiBhIGdpdmVuCisjIG1hY2hpbmUgc3BlY2lmaWNhdGlvbiBp
bnRvIGEgc2luZ2xlIHNwZWNpZmljYXRpb24gaW4gdGhlIGZvcm06CisjCUNQVV9UWVBFLU1BTlVG
QUNUVVJFUi1PUEVSQVRJTkdfU1lTVEVNCisjIG9yIGluIHNvbWUgY2FzZXMsIHRoZSBuZXdlciBm
b3VyLXBhcnQgZm9ybToKKyMJQ1BVX1RZUEUtTUFOVUZBQ1RVUkVSLUtFUk5FTC1PUEVSQVRJTkdf
U1lTVEVNCisjIEl0IGlzIHdyb25nIHRvIGVjaG8gYW55IG90aGVyIHR5cGUgb2Ygc3BlY2lmaWNh
dGlvbi4KKworbWU9YGVjaG8gIiQwIiB8IHNlZCAtZSAncywuKi8sLCdgCisKK3VzYWdlPSJcCitV
c2FnZTogJDAgW09QVElPTl0gQ1BVLU1GUi1PUFNZUworICAgICAgICQwIFtPUFRJT05dIEFMSUFT
CisKK0Nhbm9uaWNhbGl6ZSBhIGNvbmZpZ3VyYXRpb24gbmFtZS4KKworT3BlcmF0aW9uIG1vZGVz
OgorICAtaCwgLS1oZWxwICAgICAgICAgcHJpbnQgdGhpcyBoZWxwLCB0aGVuIGV4aXQKKyAgLXQs
IC0tdGltZS1zdGFtcCAgIHByaW50IGRhdGUgb2YgbGFzdCBtb2RpZmljYXRpb24sIHRoZW4gZXhp
dAorICAtdiwgLS12ZXJzaW9uICAgICAgcHJpbnQgdmVyc2lvbiBudW1iZXIsIHRoZW4gZXhpdAor
CitSZXBvcnQgYnVncyBhbmQgcGF0Y2hlcyB0byA8Y29uZmlnLXBhdGNoZXNAZ251Lm9yZz4uIgor
Cit2ZXJzaW9uPSJcCitHTlUgY29uZmlnLnN1YiAoJHRpbWVzdGFtcCkKKworQ29weXJpZ2h0IChD
KSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAxOTk2LCAxOTk3LCAxOTk4LCAxOTk5LCAyMDAwLCAy
MDAxLAorMjAwMiwgMjAwMywgMjAwNCwgMjAwNSwgMjAwNiwgMjAwNywgMjAwOCBGcmVlIFNvZnR3
YXJlIEZvdW5kYXRpb24sIEluYy4KKworVGhpcyBpcyBmcmVlIHNvZnR3YXJlOyBzZWUgdGhlIHNv
dXJjZSBmb3IgY29weWluZyBjb25kaXRpb25zLiAgVGhlcmUgaXMgTk8KK3dhcnJhbnR5OyBub3Qg
ZXZlbiBmb3IgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ
T1NFLiIKKworaGVscD0iCitUcnkgXGAkbWUgLS1oZWxwJyBmb3IgbW9yZSBpbmZvcm1hdGlvbi4i
CisKKyMgUGFyc2UgY29tbWFuZCBsaW5lCit3aGlsZSB0ZXN0ICQjIC1ndCAwIDsgZG8KKyAgY2Fz
ZSAkMSBpbgorICAgIC0tdGltZS1zdGFtcCB8IC0tdGltZSogfCAtdCApCisgICAgICAgZWNobyAi
JHRpbWVzdGFtcCIgOyBleGl0IDs7CisgICAgLS12ZXJzaW9uIHwgLXYgKQorICAgICAgIGVjaG8g
IiR2ZXJzaW9uIiA7IGV4aXQgOzsKKyAgICAtLWhlbHAgfCAtLWgqIHwgLWggKQorICAgICAgIGVj
aG8gIiR1c2FnZSI7IGV4aXQgOzsKKyAgICAtLSApICAgICAjIFN0b3Agb3B0aW9uIHByb2Nlc3Np
bmcKKyAgICAgICBzaGlmdDsgYnJlYWsgOzsKKyAgICAtICkJIyBVc2Ugc3RkaW4gYXMgaW5wdXQu
CisgICAgICAgYnJlYWsgOzsKKyAgICAtKiApCisgICAgICAgZWNobyAiJG1lOiBpbnZhbGlkIG9w
dGlvbiAkMSRoZWxwIgorICAgICAgIGV4aXQgMSA7OworCisgICAgKmxvY2FsKikKKyAgICAgICAj
IEZpcnN0IHBhc3MgdGhyb3VnaCBhbnkgbG9jYWwgbWFjaGluZSB0eXBlcy4KKyAgICAgICBlY2hv
ICQxCisgICAgICAgZXhpdCA7OworCisgICAgKiApCisgICAgICAgYnJlYWsgOzsKKyAgZXNhYwor
ZG9uZQorCitjYXNlICQjIGluCisgMCkgZWNobyAiJG1lOiBtaXNzaW5nIGFyZ3VtZW50JGhlbHAi
ID4mMgorICAgIGV4aXQgMTs7CisgMSkgOzsKKyAqKSBlY2hvICIkbWU6IHRvbyBtYW55IGFyZ3Vt
ZW50cyRoZWxwIiA+JjIKKyAgICBleGl0IDE7OworZXNhYworCisjIFNlcGFyYXRlIHdoYXQgdGhl
IHVzZXIgZ2F2ZSBpbnRvIENQVS1DT01QQU5ZIGFuZCBPUyBvciBLRVJORUwtT1MgKGlmIGFueSku
CisjIEhlcmUgd2UgbXVzdCByZWNvZ25pemUgYWxsIHRoZSB2YWxpZCBLRVJORUwtT1MgY29tYmlu
YXRpb25zLgorbWF5YmVfb3M9YGVjaG8gJDEgfCBzZWQgJ3MvXlwoLipcKS1cKFteLV0qLVteLV0q
XCkkL1wyLydgCitjYXNlICRtYXliZV9vcyBpbgorICBudG8tcW54KiB8IGxpbnV4LWdudSogfCBs
aW51eC1kaWV0bGliYyB8IGxpbnV4LW5ld2xpYiogfCBsaW51eC11Y2xpYmMqIHwgXAorICB1Y2xp
bnV4LXVjbGliYyogfCB1Y2xpbnV4LWdudSogfCBrZnJlZWJzZCotZ251KiB8IGtuZXRic2QqLWdu
dSogfCBuZXRic2QqLWdudSogfCBcCisgIGtvcGVuc29sYXJpcyotZ251KiB8IFwKKyAgc3Rvcm0t
Y2hhb3MqIHwgb3MyLWVteCogfCBydG1rLW5vdmEqKQorICAgIG9zPS0kbWF5YmVfb3MKKyAgICBi
YXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkICdzL15cKC4qXCktXChbXi1dKi1bXi1dKlwpJC9c
MS8nYAorICAgIDs7CisgICopCisgICAgYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAncy8t
W14tXSokLy8nYAorICAgIGlmIFsgJGJhc2ljX21hY2hpbmUgIT0gJDEgXQorICAgIHRoZW4gb3M9
YGVjaG8gJDEgfCBzZWQgJ3MvLiotLy0vJ2AKKyAgICBlbHNlIG9zPTsgZmkKKyAgICA7OworZXNh
YworCisjIyMgTGV0J3MgcmVjb2duaXplIGNvbW1vbiBtYWNoaW5lcyBhcyBub3QgYmVpbmcgb3Bl
cmF0aW5nIHN5c3RlbXMgc28KKyMjIyB0aGF0IHRoaW5ncyBsaWtlIGNvbmZpZy5zdWIgZGVjc3Rh
dGlvbi0zMTAwIHdvcmsuICBXZSBhbHNvCisjIyMgcmVjb2duaXplIHNvbWUgbWFudWZhY3R1cmVy
cyBhcyBub3QgYmVpbmcgb3BlcmF0aW5nIHN5c3RlbXMsIHNvIHdlCisjIyMgY2FuIHByb3ZpZGUg
ZGVmYXVsdCBvcGVyYXRpbmcgc3lzdGVtcyBiZWxvdy4KK2Nhc2UgJG9zIGluCisJLXN1bipvcyop
CisJCSMgUHJldmVudCBmb2xsb3dpbmcgY2xhdXNlIGZyb20gaGFuZGxpbmcgdGhpcyBpbnZhbGlk
IGlucHV0LgorCQk7OworCS1kZWMqIHwgLW1pcHMqIHwgLXNlcXVlbnQqIHwgLWVuY29yZSogfCAt
cGM1MzIqIHwgLXNnaSogfCAtc29ueSogfCBcCisJLWF0dCogfCAtNzMwMCogfCAtMzMwMCogfCAt
ZGVsdGEqIHwgLW1vdG9yb2xhKiB8IC1zdW5bMjM0XSogfCBcCisJLXVuaWNvbSogfCAtaWJtKiB8
IC1uZXh0IHwgLWhwIHwgLWlzaSogfCAtYXBvbGxvIHwgLWFsdG9zKiB8IFwKKwktY29udmVyZ2Vu
dCogfCAtbmNyKiB8IC1uZXdzIHwgLTMyKiB8IC0zNjAwKiB8IC0zMTAwKiB8IC1oaXRhY2hpKiB8
XAorCS1jWzEyM10qIHwgLWNvbnZleCogfCAtc3VuIHwgLWNyZHMgfCAtb21yb24qIHwgLWRnIHwg
LXVsdHJhIHwgLXR0aSogfCBcCisJLWhhcnJpcyB8IC1kb2xwaGluIHwgLWhpZ2hsZXZlbCB8IC1n
b3VsZCB8IC1jYm0gfCAtbnMgfCAtbWFzc2NvbXAgfCBcCisJLWFwcGxlIHwgLWF4aXMgfCAta251
dGggfCAtY3JheSB8IC1taWNyb2JsYXplKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0kMQorCQk7
OworICAgICAgICAtYmx1ZWdlbmUqKQorCSAgICAgICAgb3M9LWNuaworCQk7OworCS1zaW0gfCAt
Y2lzY28gfCAtb2tpIHwgLXdlYyB8IC13aW5ib25kKQorCQlvcz0KKwkJYmFzaWNfbWFjaGluZT0k
MQorCQk7OworCS1zY291dCkKKwkJOzsKKwktd3JzKQorCQlvcz0tdnh3b3JrcworCQliYXNpY19t
YWNoaW5lPSQxCisJCTs7CisJLWNob3J1c29zKikKKwkJb3M9LWNob3J1c29zCisJCWJhc2ljX21h
Y2hpbmU9JDEKKwkJOzsKKyAJLWNob3J1c3JkYikKKyAJCW9zPS1jaG9ydXNyZGIKKwkJYmFzaWNf
bWFjaGluZT0kMQorIAkJOzsKKwktaGl1eCopCisJCW9zPS1oaXV4d2UyCisJCTs7CisJLXNjbzYp
CisJCW9zPS1zY281djYKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0u
Ki84Ni1wYy8nYAorCQk7OworCS1zY281KQorCQlvcz0tc2NvMy4ydjUKKwkJYmFzaWNfbWFjaGlu
ZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY280KQorCQlv
cz0tc2NvMy4ydjQKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84
Ni1wYy8nYAorCQk7OworCS1zY28zLjIuWzQtOV0qKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUg
J3Mvc2NvMy4yLi9zY28zLjJ2LydgCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUg
J3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktc2NvMy4ydls0LTldKikKKwkJIyBEb24ndCBmb3Jn
ZXQgdmVyc2lvbiBpZiBpdCBpcyAzLjJ2NCBvciBuZXdlci4KKwkJYmFzaWNfbWFjaGluZT1gZWNo
byAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1wYy8nYAorCQk7OworCS1zY281djYqKQorCQkjIERv
bid0IGZvcmdldCB2ZXJzaW9uIGlmIGl0IGlzIDMuMnY0IG9yIG5ld2VyLgorCQliYXNpY19tYWNo
aW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4qLzg2LXBjLydgCisJCTs7CisJLXNjbyopCisJ
CW9zPS1zY28zLjJ2MgorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2LS4q
Lzg2LXBjLydgCisJCTs7CisJLXVkayopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQg
LWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktaXNjKQorCQlvcz0taXNjMi4yCisJCWJhc2lj
X21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsKKwktY2xp
eCopCisJCWJhc2ljX21hY2hpbmU9Y2xpcHBlci1pbnRlcmdyYXBoCisJCTs7CisJLWlzYyopCisJ
CWJhc2ljX21hY2hpbmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYtLiovODYtcGMvJ2AKKwkJOzsK
KwktbHlueCopCisJCW9zPS1seW54b3MKKwkJOzsKKwktcHR4KikKKwkJYmFzaWNfbWFjaGluZT1g
ZWNobyAkMSB8IHNlZCAtZSAncy84Ni0uKi84Ni1zZXF1ZW50LydgCisJCTs7CisJLXdpbmRvd3Nu
dCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAncy93aW5kb3dzbnQvd2lubnQvJ2AKKwkJOzsK
KwktcHNvcyopCisJCW9zPS1wc29zCisJCTs7CisJLW1pbnQgfCAtbWludFswLTldKikKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLWF0YXJpCisJCW9zPS1taW50CisJCTs7Citlc2FjCisKKyMgRGVjb2Rl
IGFsaWFzZXMgZm9yIGNlcnRhaW4gQ1BVLUNPTVBBTlkgY29tYmluYXRpb25zLgorY2FzZSAkYmFz
aWNfbWFjaGluZSBpbgorCSMgUmVjb2duaXplIHRoZSBiYXNpYyBDUFUgdHlwZXMgd2l0aG91dCBj
b21wYW55IG5hbWUuCisJIyBTb21lIGFyZSBvbWl0dGVkIGhlcmUgYmVjYXVzZSB0aGV5IGhhdmUg
c3BlY2lhbCBtZWFuaW5ncyBiZWxvdy4KKwkxNzUwYSB8IDU4MCBcCisJfCBhMjlrIFwKKwl8IGFs
cGhhIHwgYWxwaGFldls0LThdIHwgYWxwaGFldjU2IHwgYWxwaGFldjZbNzhdIHwgYWxwaGFwY2E1
WzY3XSBcCisJfCBhbHBoYTY0IHwgYWxwaGE2NGV2WzQtOF0gfCBhbHBoYTY0ZXY1NiB8IGFscGhh
NjRldjZbNzhdIHwgYWxwaGE2NHBjYTVbNjddIFwKKwl8IGFtMzNfMi4wIFwKKwl8IGFyYyB8IGFy
bSB8IGFybVtibF1lIHwgYXJtZVtsYl0gfCBhcm12WzIzNDVdIHwgYXJtdlszNDVdW2xiXSB8IGF2
ciB8IGF2cjMyIFwKKwl8IGJmaW4gXAorCXwgYzR4IHwgY2xpcHBlciBcCisJfCBkMTB2IHwgZDMw
diB8IGRseCB8IGRzcDE2eHggXAorCXwgZmlkbyB8IGZyMzAgfCBmcnYgXAorCXwgaDgzMDAgfCBo
ODUwMCB8IGhwcGEgfCBocHBhMS5bMDFdIHwgaHBwYTIuMCB8IGhwcGEyLjBbbnddIHwgaHBwYTY0
IFwKKwl8IGkzNzAgfCBpODYwIHwgaTk2MCB8IGlhNjQgXAorCXwgaXAyayB8IGlxMjAwMCBcCisJ
fCBsbTMyIFwKKwl8IG0zMmMgfCBtMzJyIHwgbTMycmxlIHwgbTY4MDAwIHwgbTY4ayB8IG04OGsg
XAorCXwgbWF4cSB8IG1iIHwgbWljcm9ibGF6ZSB8IG1jb3JlIHwgbWVwIHwgbWV0YWcgXAorCXwg
bWlwcyB8IG1pcHNiZSB8IG1pcHNlYiB8IG1pcHNlbCB8IG1pcHNsZSBcCisJfCBtaXBzMTYgXAor
CXwgbWlwczY0IHwgbWlwczY0ZWwgXAorCXwgbWlwczY0b2N0ZW9uIHwgbWlwczY0b2N0ZW9uZWwg
XAorCXwgbWlwczY0b3Jpb24gfCBtaXBzNjRvcmlvbmVsIFwKKwl8IG1pcHM2NHI1OTAwIHwgbWlw
czY0cjU5MDBlbCBcCisJfCBtaXBzNjR2ciB8IG1pcHM2NHZyZWwgXAorCXwgbWlwczY0dnI0MTAw
IHwgbWlwczY0dnI0MTAwZWwgXAorCXwgbWlwczY0dnI0MzAwIHwgbWlwczY0dnI0MzAwZWwgXAor
CXwgbWlwczY0dnI1MDAwIHwgbWlwczY0dnI1MDAwZWwgXAorCXwgbWlwczY0dnI1OTAwIHwgbWlw
czY0dnI1OTAwZWwgXAorCXwgbWlwc2lzYTMyIHwgbWlwc2lzYTMyZWwgXAorCXwgbWlwc2lzYTMy
cjIgfCBtaXBzaXNhMzJyMmVsIFwKKwl8IG1pcHNpc2E2NCB8IG1pcHNpc2E2NGVsIFwKKwl8IG1p
cHNpc2E2NHIyIHwgbWlwc2lzYTY0cjJlbCBcCisJfCBtaXBzaXNhNjRzYjEgfCBtaXBzaXNhNjRz
YjFlbCBcCisJfCBtaXBzaXNhNjRzcjcxayB8IG1pcHNpc2E2NHNyNzFrZWwgXAorCXwgbWlwc3R4
MzkgfCBtaXBzdHgzOWVsIFwKKwl8IG1uMTAyMDAgfCBtbjEwMzAwIFwKKwl8IG1veGllIFwKKwl8
IG10IFwKKwl8IG1zcDQzMCBcCisJfCBuaW9zIHwgbmlvczIgXAorCXwgbnMxNmsgfCBuczMyayBc
CisJfCBvcjMyIFwKKwl8IHBkcDEwIHwgcGRwMTEgfCBwaiB8IHBqbCBcCisJfCBwb3dlcnBjIHwg
cG93ZXJwYzY0IHwgcG93ZXJwYzY0bGUgfCBwb3dlcnBjbGUgfCBwcGNiZSBcCisJfCBweXJhbWlk
IFwKKwl8IHJ4IFwKKwl8IHNjb3JlIFwKKwl8IHNoIHwgc2hbMTIzNF0gfCBzaFsyNF1hIHwgc2hb
MjRdYWViIHwgc2hbMjNdZSB8IHNoWzM0XWViIHwgc2hlYiB8IHNoYmUgfCBzaGxlIHwgc2hbMTIz
NF1sZSB8IHNoM2VsZSBcCisJfCBzaDY0IHwgc2g2NGxlIFwKKwl8IHNwYXJjIHwgc3BhcmM2NCB8
IHNwYXJjNjRiIHwgc3BhcmM2NHYgfCBzcGFyYzg2eCB8IHNwYXJjbGV0IHwgc3BhcmNsaXRlIFwK
Kwl8IHNwYXJjdjggfCBzcGFyY3Y5IHwgc3BhcmN2OWIgfCBzcGFyY3Y5diBcCisJfCBzcHUgfCBz
dHJvbmdhcm0gXAorCXwgdGFob2UgfCB0aHVtYiB8IHRpYzR4IHwgdGljODAgfCB0cm9uIFwKKwl8
IHViaWNvbTMyIFwKKwl8IHY4NTAgfCB2ODUwZSBcCisJfCB3ZTMyayBcCisJfCB4ODYgfCB4YzE2
eCB8IHhzY2FsZSB8IHhzY2FsZWVbYmxdIHwgeHN0b3JteTE2IHwgeHRlbnNhIFwKKwl8IHo4ayB8
IHo4MCkKKwkJYmFzaWNfbWFjaGluZT0kYmFzaWNfbWFjaGluZS11bmtub3duCisJCTs7CisJbTY4
MTEgfCBtNjhoYzExIHwgbTY4MTIgfCBtNjhoYzEyIHwgcGljb2NoaXApCisJCSMgTW90b3JvbGEg
NjhIQzExLzEyLgorCQliYXNpY19tYWNoaW5lPSRiYXNpY19tYWNoaW5lLXVua25vd24KKwkJb3M9
LW5vbmUKKwkJOzsKKwltODgxMTAgfCBtNjgwWzEyMzQ2XTAgfCBtNjgzPzIgfCBtNjgzNjAgfCBt
NTIwMCB8IHY3MCB8IHc2NSB8IHo4aykKKwkJOzsKKwltczEpCisJCWJhc2ljX21hY2hpbmU9bXQt
dW5rbm93bgorCQk7OworCisJIyBXZSB1c2UgYHBjJyByYXRoZXIgdGhhbiBgdW5rbm93bicKKwkj
IGJlY2F1c2UgKDEpIHRoYXQncyB3aGF0IHRoZXkgbm9ybWFsbHkgYXJlLCBhbmQKKwkjICgyKSB0
aGUgd29yZCAidW5rbm93biIgdGVuZHMgdG8gY29uZnVzZSBiZWdpbm5pbmcgdXNlcnMuCisJaSo4
NiB8IHg4Nl82NCkKKwkgIGJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtcGMKKwkgIDs7CisJ
IyBPYmplY3QgaWYgbW9yZSB0aGFuIG9uZSBjb21wYW55IG5hbWUgd29yZC4KKwkqLSotKikKKwkJ
ZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRpb24gXGAkMVwnOiBtYWNoaW5lIFxgJGJhc2ljX21hY2hp
bmVcJyBub3QgcmVjb2duaXplZCAxPiYyCisJCWV4aXQgMQorCQk7OworCSMgUmVjb2duaXplIHRo
ZSBiYXNpYyBDUFUgdHlwZXMgd2l0aCBjb21wYW55IG5hbWUuCisJNTgwLSogXAorCXwgYTI5ay0q
IFwKKwl8IGFscGhhLSogfCBhbHBoYWV2WzQtOF0tKiB8IGFscGhhZXY1Ni0qIHwgYWxwaGFldjZb
NzhdLSogXAorCXwgYWxwaGE2NC0qIHwgYWxwaGE2NGV2WzQtOF0tKiB8IGFscGhhNjRldjU2LSog
fCBhbHBoYTY0ZXY2Wzc4XS0qIFwKKwl8IGFscGhhcGNhNVs2N10tKiB8IGFscGhhNjRwY2E1WzY3
XS0qIHwgYXJjLSogXAorCXwgYXJtLSogIHwgYXJtYmUtKiB8IGFybWxlLSogfCBhcm1lYi0qIHwg
YXJtdiotKiBcCisJfCBhdnItKiB8IGF2cjMyLSogXAorCXwgYmZpbi0qIHwgYnMyMDAwLSogXAor
CXwgY1sxMjNdKiB8IGMzMC0qIHwgW2NqdF05MC0qIHwgYzR4LSogfCBjNTR4LSogfCBjNTV4LSog
fCBjNngtKiBcCisJfCBjbGlwcGVyLSogfCBjcmF5bnYtKiB8IGN5ZHJhLSogXAorCXwgZDEwdi0q
IHwgZDMwdi0qIHwgZGx4LSogXAorCXwgZWx4c2ktKiBcCisJfCBmMzBbMDFdLSogfCBmNzAwLSog
fCBmaWRvLSogfCBmcjMwLSogfCBmcnYtKiB8IGZ4ODAtKiBcCisJfCBoODMwMC0qIHwgaDg1MDAt
KiBcCisJfCBocHBhLSogfCBocHBhMS5bMDFdLSogfCBocHBhMi4wLSogfCBocHBhMi4wW253XS0q
IHwgaHBwYTY0LSogXAorCXwgaSo4Ni0qIHwgaTg2MC0qIHwgaTk2MC0qIHwgaWE2NC0qIFwKKwl8
IGlwMmstKiB8IGlxMjAwMC0qIFwKKwl8IGxtMzItKiBcCisJfCBtMzJjLSogfCBtMzJyLSogfCBt
MzJybGUtKiBcCisJfCBtNjgwMDAtKiB8IG02ODBbMDEyMzQ2XTAtKiB8IG02ODM2MC0qIHwgbTY4
Mz8yLSogfCBtNjhrLSogXAorCXwgbTg4MTEwLSogfCBtODhrLSogfCBtYXhxLSogfCBtY29yZS0q
IHwgbWV0YWctKiB8IG1pY3JvYmxhemUtKiBcCisJfCBtaXBzLSogfCBtaXBzYmUtKiB8IG1pcHNl
Yi0qIHwgbWlwc2VsLSogfCBtaXBzbGUtKiBcCisJfCBtaXBzMTYtKiBcCisJfCBtaXBzNjQtKiB8
IG1pcHM2NGVsLSogXAorCXwgbWlwczY0b2N0ZW9uLSogfCBtaXBzNjRvY3Rlb25lbC0qIFwKKwl8
IG1pcHM2NG9yaW9uLSogfCBtaXBzNjRvcmlvbmVsLSogXAorCXwgbWlwczY0cjU5MDAtKiB8IG1p
cHM2NHI1OTAwZWwtKiBcCisJfCBtaXBzNjR2ci0qIHwgbWlwczY0dnJlbC0qIFwKKwl8IG1pcHM2
NHZyNDEwMC0qIHwgbWlwczY0dnI0MTAwZWwtKiBcCisJfCBtaXBzNjR2cjQzMDAtKiB8IG1pcHM2
NHZyNDMwMGVsLSogXAorCXwgbWlwczY0dnI1MDAwLSogfCBtaXBzNjR2cjUwMDBlbC0qIFwKKwl8
IG1pcHM2NHZyNTkwMC0qIHwgbWlwczY0dnI1OTAwZWwtKiBcCisJfCBtaXBzaXNhMzItKiB8IG1p
cHNpc2EzMmVsLSogXAorCXwgbWlwc2lzYTMycjItKiB8IG1pcHNpc2EzMnIyZWwtKiBcCisJfCBt
aXBzaXNhNjQtKiB8IG1pcHNpc2E2NGVsLSogXAorCXwgbWlwc2lzYTY0cjItKiB8IG1pcHNpc2E2
NHIyZWwtKiBcCisJfCBtaXBzaXNhNjRzYjEtKiB8IG1pcHNpc2E2NHNiMWVsLSogXAorCXwgbWlw
c2lzYTY0c3I3MWstKiB8IG1pcHNpc2E2NHNyNzFrZWwtKiBcCisJfCBtaXBzdHgzOS0qIHwgbWlw
c3R4MzllbC0qIFwKKwl8IG1taXgtKiBcCisJfCBtdC0qIFwKKwl8IG1zcDQzMC0qIFwKKwl8IG5p
b3MtKiB8IG5pb3MyLSogXAorCXwgbm9uZS0qIHwgbnAxLSogfCBuczE2ay0qIHwgbnMzMmstKiBc
CisJfCBvcmlvbi0qIFwKKwl8IHBkcDEwLSogfCBwZHAxMS0qIHwgcGotKiB8IHBqbC0qIHwgcG4t
KiB8IHBvd2VyLSogXAorCXwgcG93ZXJwYy0qIHwgcG93ZXJwYzY0LSogfCBwb3dlcnBjNjRsZS0q
IHwgcG93ZXJwY2xlLSogfCBwcGNiZS0qIFwKKwl8IHB5cmFtaWQtKiBcCisJfCByb21wLSogfCBy
czYwMDAtKiB8IHJ4LSogXAorCXwgc2gtKiB8IHNoWzEyMzRdLSogfCBzaFsyNF1hLSogfCBzaFsy
NF1hZWItKiB8IHNoWzIzXWUtKiB8IHNoWzM0XWViLSogfCBzaGViLSogfCBzaGJlLSogXAorCXwg
c2hsZS0qIHwgc2hbMTIzNF1sZS0qIHwgc2gzZWxlLSogfCBzaDY0LSogfCBzaDY0bGUtKiBcCisJ
fCBzcGFyYy0qIHwgc3BhcmM2NC0qIHwgc3BhcmM2NGItKiB8IHNwYXJjNjR2LSogfCBzcGFyYzg2
eC0qIHwgc3BhcmNsZXQtKiBcCisJfCBzcGFyY2xpdGUtKiBcCisJfCBzcGFyY3Y4LSogfCBzcGFy
Y3Y5LSogfCBzcGFyY3Y5Yi0qIHwgc3BhcmN2OXYtKiB8IHN0cm9uZ2FybS0qIHwgc3YxLSogfCBz
eD8tKiBcCisJfCB0YWhvZS0qIHwgdGh1bWItKiBcCisJfCB0aWMzMC0qIHwgdGljNHgtKiB8IHRp
YzU0eC0qIHwgdGljNTV4LSogfCB0aWM2eC0qIHwgdGljODAtKiB8IHRpbGUtKiBcCisJfCB0cm9u
LSogXAorCXwgdWJpY29tMzItKiBcCisJfCB2ODUwLSogfCB2ODUwZS0qIHwgdmF4LSogXAorCXwg
d2UzMmstKiBcCisJfCB4ODYtKiB8IHg4Nl82NC0qIHwgeGMxNngtKiB8IHhwczEwMC0qIHwgeHNj
YWxlLSogfCB4c2NhbGVlW2JsXS0qIFwKKwl8IHhzdG9ybXkxNi0qIHwgeHRlbnNhKi0qIFwKKwl8
IHltcC0qIFwKKwl8IHo4ay0qIHwgejgwLSopCisJCTs7CisJIyBSZWNvZ25pemUgdGhlIGJhc2lj
IENQVSB0eXBlcyB3aXRob3V0IGNvbXBhbnkgbmFtZSwgd2l0aCBnbG9iIG1hdGNoLgorCXh0ZW5z
YSopCisJCWJhc2ljX21hY2hpbmU9JGJhc2ljX21hY2hpbmUtdW5rbm93bgorCQk7OworCSMgUmVj
b2duaXplIHRoZSB2YXJpb3VzIG1hY2hpbmUgbmFtZXMgYW5kIGFsaWFzZXMgd2hpY2ggc3RhbmQK
KwkjIGZvciBhIENQVSB0eXBlIGFuZCBhIGNvbXBhbnkgYW5kIHNvbWV0aW1lcyBldmVuIGFuIE9T
LgorCTM4NmJzZCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24KKwkJb3M9LWJzZAorCQk7
OworCTNiMSB8IDczMDAgfCA3MzAwLWF0dCB8IGF0dC03MzAwIHwgcGM3MzAwIHwgc2FmYXJpIHwg
dW5peHBjKQorCQliYXNpY19tYWNoaW5lPW02ODAwMC1hdHQKKwkJOzsKKwkzYiopCisJCWJhc2lj
X21hY2hpbmU9d2UzMmstYXR0CisJCTs7CisJYTI5a2hpZikKKwkJYmFzaWNfbWFjaGluZT1hMjlr
LWFtZAorCQlvcz0tdWRpCisJCTs7CisgICAgCWFiYWN1cykKKwkJYmFzaWNfbWFjaGluZT1hYmFj
dXMtdW5rbm93bgorCQk7OworCWFkb2JlNjhrKQorCQliYXNpY19tYWNoaW5lPW02ODAxMC1hZG9i
ZQorCQlvcz0tc2NvdXQKKwkJOzsKKwlhbGxpYW50IHwgZng4MCkKKwkJYmFzaWNfbWFjaGluZT1m
eDgwLWFsbGlhbnQKKwkJOzsKKwlhbHRvcyB8IGFsdG9zMzA2OCkKKwkJYmFzaWNfbWFjaGluZT1t
NjhrLWFsdG9zCisJCTs7CisJYW0yOWspCisJCWJhc2ljX21hY2hpbmU9YTI5ay1ub25lCisJCW9z
PS1ic2QKKwkJOzsKKwlhbWQ2NCkKKwkJYmFzaWNfbWFjaGluZT14ODZfNjQtcGMKKwkJOzsKKwlh
bWQ2NC0qKQorCQliYXNpY19tYWNoaW5lPXg4Nl82NC1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNl
ZCAncy9eW14tXSotLy8nYAorCQk7OworCWFtZGFobCkKKwkJYmFzaWNfbWFjaGluZT01ODAtYW1k
YWhsCisJCW9zPS1zeXN2CisJCTs7CisJYW1pZ2EgfCBhbWlnYS0qKQorCQliYXNpY19tYWNoaW5l
PW02OGstdW5rbm93bgorCQk7OworCWFtaWdhb3MgfCBhbWlnYWRvcykKKwkJYmFzaWNfbWFjaGlu
ZT1tNjhrLXVua25vd24KKwkJb3M9LWFtaWdhb3MKKwkJOzsKKwlhbWlnYXVuaXggfCBhbWl4KQor
CQliYXNpY19tYWNoaW5lPW02OGstdW5rbm93bgorCQlvcz0tc3lzdjQKKwkJOzsKKwlhcG9sbG82
OCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWFwb2xsbworCQlvcz0tc3lzdgorCQk7OworCWFwb2xs
bzY4YnNkKQorCQliYXNpY19tYWNoaW5lPW02OGstYXBvbGxvCisJCW9zPS1ic2QKKwkJOzsKKwlh
cm9zKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LWFyb3MKKwkJOzsKKwlhdXgpCisJ
CWJhc2ljX21hY2hpbmU9bTY4ay1hcHBsZQorCQlvcz0tYXV4CisJCTs7CisJYmFsYW5jZSkKKwkJ
YmFzaWNfbWFjaGluZT1uczMyay1zZXF1ZW50CisJCW9zPS1keW5peAorCQk7OworCWJsYWNrZmlu
KQorCQliYXNpY19tYWNoaW5lPWJmaW4tdW5rbm93bgorCQlvcz0tbGludXgKKwkJOzsKKwlibGFj
a2Zpbi0qKQorCQliYXNpY19tYWNoaW5lPWJmaW4tYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQg
J3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4CisJCTs7CisJYmx1ZWdlbmUqKQorCQliYXNpY19t
YWNoaW5lPXBvd2VycGMtaWJtCisJCW9zPS1jbmsKKwkJOzsKKwljOTApCisJCWJhc2ljX21hY2hp
bmU9YzkwLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7OworICAgICAgICBjZWdjYykKKwkJYmFzaWNf
bWFjaGluZT1hcm0tdW5rbm93bgorCQlvcz0tY2VnY2MKKwkJOzsKKwljb252ZXgtYzEpCisJCWJh
c2ljX21hY2hpbmU9YzEtY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljb252ZXgtYzIpCisJCWJh
c2ljX21hY2hpbmU9YzItY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljb252ZXgtYzMyKQorCQli
YXNpY19tYWNoaW5lPWMzMi1jb252ZXgKKwkJb3M9LWJzZAorCQk7OworCWNvbnZleC1jMzQpCisJ
CWJhc2ljX21hY2hpbmU9YzM0LWNvbnZleAorCQlvcz0tYnNkCisJCTs7CisJY29udmV4LWMzOCkK
KwkJYmFzaWNfbWFjaGluZT1jMzgtY29udmV4CisJCW9zPS1ic2QKKwkJOzsKKwljcmF5IHwgajkw
KQorCQliYXNpY19tYWNoaW5lPWo5MC1jcmF5CisJCW9zPS11bmljb3MKKwkJOzsKKwljcmF5bnYp
CisJCWJhc2ljX21hY2hpbmU9Y3JheW52LWNyYXkKKwkJb3M9LXVuaWNvc21wCisJCTs7CisJY3Ix
NikKKwkJYmFzaWNfbWFjaGluZT1jcjE2LXVua25vd24KKwkJb3M9LWVsZgorCQk7OworCWNyZHMg
fCB1bm9zKQorCQliYXNpY19tYWNoaW5lPW02OGstY3JkcworCQk7OworCWNyaXN2MzIgfCBjcmlz
djMyLSogfCBldHJheGZzKikKKwkJYmFzaWNfbWFjaGluZT1jcmlzdjMyLWF4aXMKKwkJOzsKKwlj
cmlzIHwgY3Jpcy0qIHwgZXRyYXgqKQorCQliYXNpY19tYWNoaW5lPWNyaXMtYXhpcworCQk7Owor
CWNyeCkKKwkJYmFzaWNfbWFjaGluZT1jcngtdW5rbm93bgorCQlvcz0tZWxmCisJCTs7CisJZGEz
MCB8IGRhMzAtKikKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWRhMzAKKwkJOzsKKwlkZWNzdGF0aW9u
IHwgZGVjc3RhdGlvbi0zMTAwIHwgcG1heCB8IHBtYXgtKiB8IHBtaW4gfCBkZWMzMTAwIHwgZGVj
c3RhdG4pCisJCWJhc2ljX21hY2hpbmU9bWlwcy1kZWMKKwkJOzsKKwlkZWNzeXN0ZW0xMCogfCBk
ZWMxMCopCisJCWJhc2ljX21hY2hpbmU9cGRwMTAtZGVjCisJCW9zPS10b3BzMTAKKwkJOzsKKwlk
ZWNzeXN0ZW0yMCogfCBkZWMyMCopCisJCWJhc2ljX21hY2hpbmU9cGRwMTAtZGVjCisJCW9zPS10
b3BzMjAKKwkJOzsKKwlkZWx0YSB8IDMzMDAgfCBtb3Rvcm9sYS0zMzAwIHwgbW90b3JvbGEtZGVs
dGEgXAorCSAgICAgIHwgMzMwMC1tb3Rvcm9sYSB8IGRlbHRhLW1vdG9yb2xhKQorCQliYXNpY19t
YWNoaW5lPW02OGstbW90b3JvbGEKKwkJOzsKKwlkZWx0YTg4KQorCQliYXNpY19tYWNoaW5lPW04
OGstbW90b3JvbGEKKwkJb3M9LXN5c3YzCisJCTs7CisJZGljb3MpCisJCWJhc2ljX21hY2hpbmU9
aTY4Ni1wYworCQlvcz0tZGljb3MKKwkJOzsKKwlkamdwcCkKKwkJYmFzaWNfbWFjaGluZT1pNTg2
LXBjCisJCW9zPS1tc2Rvc2RqZ3BwCisJCTs7CisJZHB4MjAgfCBkcHgyMC0qKQorCQliYXNpY19t
YWNoaW5lPXJzNjAwMC1idWxsCisJCW9zPS1ib3N4CisJCTs7CisJZHB4MiogfCBkcHgyKi1idWxs
KQorCQliYXNpY19tYWNoaW5lPW02OGstYnVsbAorCQlvcz0tc3lzdjMKKwkJOzsKKwllYm1vbjI5
aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLWFtZAorCQlvcz0tZWJtb24KKwkJOzsKKwllbHhzaSkK
KwkJYmFzaWNfbWFjaGluZT1lbHhzaS1lbHhzaQorCQlvcz0tYnNkCisJCTs7CisJZW5jb3JlIHwg
dW1heCB8IG1tYXgpCisJCWJhc2ljX21hY2hpbmU9bnMzMmstZW5jb3JlCisJCTs7CisJZXMxODAw
IHwgT1NFNjhrIHwgb3NlNjhrIHwgb3NlIHwgT1NFKQorCQliYXNpY19tYWNoaW5lPW02OGstZXJp
Y3Nzb24KKwkJb3M9LW9zZQorCQk7OworCWZ4MjgwMCkKKwkJYmFzaWNfbWFjaGluZT1pODYwLWFs
bGlhbnQKKwkJOzsKKwlnZW5peCkKKwkJYmFzaWNfbWFjaGluZT1uczMyay1ucworCQk7OworCWdt
aWNybykKKwkJYmFzaWNfbWFjaGluZT10cm9uLWdtaWNybworCQlvcz0tc3lzdgorCQk7OworCWdv
MzIpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1wYworCQlvcz0tZ28zMgorCQk7OworCWgzMDUwciog
fCBoaXV4KikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhpdGFjaGkKKwkJb3M9LWhpdXh3ZTIK
KwkJOzsKKwloODMwMGhtcykKKwkJYmFzaWNfbWFjaGluZT1oODMwMC1oaXRhY2hpCisJCW9zPS1o
bXMKKwkJOzsKKwloODMwMHhyYXkpCisJCWJhc2ljX21hY2hpbmU9aDgzMDAtaGl0YWNoaQorCQlv
cz0teHJheQorCQk7OworCWg4NTAwaG1zKQorCQliYXNpY19tYWNoaW5lPWg4NTAwLWhpdGFjaGkK
KwkJb3M9LWhtcworCQk7OworCWhhcnJpcykKKwkJYmFzaWNfbWFjaGluZT1tODhrLWhhcnJpcwor
CQlvcz0tc3lzdjMKKwkJOzsKKwlocDMwMC0qKQorCQliYXNpY19tYWNoaW5lPW02OGstaHAKKwkJ
OzsKKwlocDMwMGJzZCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhwCisJCW9zPS1ic2QKKwkJOzsK
KwlocDMwMGhwdXgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1ocAorCQlvcz0taHB1eAorCQk7Owor
CWhwM2s5WzAtOV1bMC05XSB8IGhwOVswLTldWzAtOV0pCisJCWJhc2ljX21hY2hpbmU9aHBwYTEu
MC1ocAorCQk7OworCWhwOWsyWzAtOV1bMC05XSB8IGhwOWszMVswLTldKQorCQliYXNpY19tYWNo
aW5lPW02ODAwMC1ocAorCQk7OworCWhwOWszWzItOV1bMC05XSkKKwkJYmFzaWNfbWFjaGluZT1t
NjhrLWhwCisJCTs7CisJaHA5azZbMC05XVswLTldIHwgaHA2WzAtOV1bMC05XSkKKwkJYmFzaWNf
bWFjaGluZT1ocHBhMS4wLWhwCisJCTs7CisJaHA5azdbMC03OV1bMC05XSB8IGhwN1swLTc5XVsw
LTldKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtaHAKKwkJOzsKKwlocDlrNzhbMC05XSB8IGhw
NzhbMC05XSkKKwkJIyBGSVhNRTogcmVhbGx5IGhwcGEyLjAtaHAKKwkJYmFzaWNfbWFjaGluZT1o
cHBhMS4xLWhwCisJCTs7CisJaHA5azhbNjddMSB8IGhwOFs2N10xIHwgaHA5azgwWzI0XSB8IGhw
ODBbMjRdIHwgaHA5azhbNzhdOSB8IGhwOFs3OF05IHwgaHA5azg5MyB8IGhwODkzKQorCQkjIEZJ
WE1FOiByZWFsbHkgaHBwYTIuMC1ocAorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtaHAKKwkJOzsK
KwlocDlrOFswLTldWzEzNjc5XSB8IGhwOFswLTldWzEzNjc5XSkKKwkJYmFzaWNfbWFjaGluZT1o
cHBhMS4xLWhwCisJCTs7CisJaHA5azhbMC05XVswLTldIHwgaHA4WzAtOV1bMC05XSkKKwkJYmFz
aWNfbWFjaGluZT1ocHBhMS4wLWhwCisJCTs7CisJaHBwYS1uZXh0KQorCQlvcz0tbmV4dHN0ZXAz
CisJCTs7CisJaHBwYW9zZikKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCW9zPS1vc2YK
KwkJOzsKKwlocHBybykKKwkJYmFzaWNfbWFjaGluZT1ocHBhMS4xLWhwCisJCW9zPS1wcm9lbGYK
KwkJOzsKKwlpMzcwLWlibSogfCBpYm0qKQorCQliYXNpY19tYWNoaW5lPWkzNzAtaWJtCisJCTs7
CisjIEknbSBub3Qgc3VyZSB3aGF0ICJTeXN2MzIiIG1lYW5zLiAgU2hvdWxkIHRoaXMgYmUgc3lz
djMuMj8KKwlpKjg2djMyKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICQxIHwgc2VkIC1lICdzLzg2
LiovODYtcGMvJ2AKKwkJb3M9LXN5c3YzMgorCQk7OworCWkqODZ2NCopCisJCWJhc2ljX21hY2hp
bmU9YGVjaG8gJDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8nYAorCQlvcz0tc3lzdjQKKwkJOzsK
KwlpKjg2dikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkMSB8IHNlZCAtZSAncy84Ni4qLzg2LXBj
LydgCisJCW9zPS1zeXN2CisJCTs7CisJaSo4NnNvbDIpCisJCWJhc2ljX21hY2hpbmU9YGVjaG8g
JDEgfCBzZWQgLWUgJ3MvODYuKi84Ni1wYy8nYAorCQlvcz0tc29sYXJpczIKKwkJOzsKKwlpMzg2
bWFjaCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LW1hY2gKKwkJb3M9LW1hY2gKKwkJOzsKKwlpMzg2
LXZzdGEgfCB2c3RhKQorCQliYXNpY19tYWNoaW5lPWkzODYtdW5rbm93bgorCQlvcz0tdnN0YQor
CQk7OworCWlyaXMgfCBpcmlzNGQpCisJCWJhc2ljX21hY2hpbmU9bWlwcy1zZ2kKKwkJY2FzZSAk
b3MgaW4KKwkJICAgIC1pcml4KikKKwkJCTs7CisJCSAgICAqKQorCQkJb3M9LWlyaXg0CisJCQk7
OworCQllc2FjCisJCTs7CisJaXNpNjggfCBpc2kpCisJCWJhc2ljX21hY2hpbmU9bTY4ay1pc2kK
KwkJb3M9LXN5c3YKKwkJOzsKKwltNjhrbm9tbXUpCisJCWJhc2ljX21hY2hpbmU9bTY4ay11bmtu
b3duCisJCW9zPS1saW51eAorCQk7OworCW02OGtub21tdS0qKQorCQliYXNpY19tYWNoaW5lPW02
OGstYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJb3M9LWxpbnV4
CisJCTs7CisJbTg4ay1vbXJvbiopCisJCWJhc2ljX21hY2hpbmU9bTg4ay1vbXJvbgorCQk7Owor
CW1hZ251bSB8IG0zMjMwKQorCQliYXNpY19tYWNoaW5lPW1pcHMtbWlwcworCQlvcz0tc3lzdgor
CQk7OworCW1lcmxpbikKKwkJYmFzaWNfbWFjaGluZT1uczMyay11dGVrCisJCW9zPS1zeXN2CisJ
CTs7CisgICAgICAgIG1pY3JvYmxhemUpCisJCWJhc2ljX21hY2hpbmU9bWljcm9ibGF6ZS14aWxp
bngKKwkJOzsKKwltaW5ndzMyKQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJb3M9LW1pbmd3
MzIKKwkJOzsKKwltaW5ndzMyY2UpCisJCWJhc2ljX21hY2hpbmU9YXJtLXVua25vd24KKwkJb3M9
LW1pbmd3MzJjZQorCQk7OworCW1pbmlmcmFtZSkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAtY29u
dmVyZ2VudAorCQk7OworCSptaW50IHwgLW1pbnRbMC05XSogfCAqTWlOVCB8ICpNaU5UWzAtOV0q
KQorCQliYXNpY19tYWNoaW5lPW02OGstYXRhcmkKKwkJb3M9LW1pbnQKKwkJOzsKKwltaXBzMyot
KikKKwkJYmFzaWNfbWFjaGluZT1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAtZSAncy9taXBz
My9taXBzNjQvJ2AKKwkJOzsKKwltaXBzMyopCisJCWJhc2ljX21hY2hpbmU9YGVjaG8gJGJhc2lj
X21hY2hpbmUgfCBzZWQgLWUgJ3MvbWlwczMvbWlwczY0LydgLXVua25vd24KKwkJOzsKKwltb25p
dG9yKQorCQliYXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1jb2ZmCisJCTs7CisJbW9y
cGhvcykKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJb3M9LW1vcnBob3MKKwkJ
OzsKKwltc2RvcykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1tc2RvcworCQk7Owor
CW1zMS0qKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkIC1lICdz
L21zMS0vbXQtLydgCisJCTs7CisJbXZzKQorCQliYXNpY19tYWNoaW5lPWkzNzAtaWJtCisJCW9z
PS1tdnMKKwkJOzsKKwluY3IzMDAwKQorCQliYXNpY19tYWNoaW5lPWk0ODYtbmNyCisJCW9zPS1z
eXN2NAorCQk7OworCW5ldGJzZDM4NikKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXVua25vd24KKwkJ
b3M9LW5ldGJzZAorCQk7OworCW5ldHdpbmRlcikKKwkJYmFzaWNfbWFjaGluZT1hcm12NGwtcmVi
ZWwKKwkJb3M9LWxpbnV4CisJCTs7CisJbmV3cyB8IG5ld3M3MDAgfCBuZXdzODAwIHwgbmV3czkw
MCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLXNvbnkKKwkJb3M9LW5ld3NvcworCQk7OworCW5ld3Mx
MDAwKQorCQliYXNpY19tYWNoaW5lPW02ODAzMC1zb255CisJCW9zPS1uZXdzb3MKKwkJOzsKKwlu
ZXdzLTM2MDAgfCByaXNjLW5ld3MpCisJCWJhc2ljX21hY2hpbmU9bWlwcy1zb255CisJCW9zPS1u
ZXdzb3MKKwkJOzsKKwluZWN2NzApCisJCWJhc2ljX21hY2hpbmU9djcwLW5lYworCQlvcz0tc3lz
dgorCQk7OworCW5leHQgfCBtKi1uZXh0ICkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLW5leHQKKwkJ
Y2FzZSAkb3MgaW4KKwkJICAgIC1uZXh0c3RlcCogKQorCQkJOzsKKwkJICAgIC1uczIqKQorCQkg
ICAgICBvcz0tbmV4dHN0ZXAyCisJCQk7OworCQkgICAgKikKKwkJICAgICAgb3M9LW5leHRzdGVw
MworCQkJOzsKKwkJZXNhYworCQk7OworCW5oMzAwMCkKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWhh
cnJpcworCQlvcz0tY3h1eAorCQk7OworCW5oWzQ1XTAwMCkKKwkJYmFzaWNfbWFjaGluZT1tODhr
LWhhcnJpcworCQlvcz0tY3h1eAorCQk7OworCW5pbmR5OTYwKQorCQliYXNpY19tYWNoaW5lPWk5
NjAtaW50ZWwKKwkJb3M9LW5pbmR5CisJCTs7CisJbW9uOTYwKQorCQliYXNpY19tYWNoaW5lPWk5
NjAtaW50ZWwKKwkJb3M9LW1vbjk2MAorCQk7OworCW5vbnN0b3B1eCkKKwkJYmFzaWNfbWFjaGlu
ZT1taXBzLWNvbXBhcQorCQlvcz0tbm9uc3RvcHV4CisJCTs7CisJbnAxKQorCQliYXNpY19tYWNo
aW5lPW5wMS1nb3VsZAorCQk7OworCW5zci10YW5kZW0pCisJCWJhc2ljX21hY2hpbmU9bnNyLXRh
bmRlbQorCQk7OworCW9wNTBuLSogfCBvcDYwYy0qKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEt
b2tpCisJCW9zPS1wcm9lbGYKKwkJOzsKKwlvcGVucmlzYyB8IG9wZW5yaXNjLSopCisJCWJhc2lj
X21hY2hpbmU9b3IzMi11bmtub3duCisJCTs7CisJb3M0MDApCisJCWJhc2ljX21hY2hpbmU9cG93
ZXJwYy1pYm0KKwkJb3M9LW9zNDAwCisJCTs7CisJT1NFNjgwMDAgfCBvc2U2ODAwMCkKKwkJYmFz
aWNfbWFjaGluZT1tNjgwMDAtZXJpY3Nzb24KKwkJb3M9LW9zZQorCQk7OworCW9zNjhrKQorCQli
YXNpY19tYWNoaW5lPW02OGstbm9uZQorCQlvcz0tb3M2OGsKKwkJOzsKKwlwYS1oaXRhY2hpKQor
CQliYXNpY19tYWNoaW5lPWhwcGExLjEtaGl0YWNoaQorCQlvcz0taGl1eHdlMgorCQk7OworCXBh
cmFnb24pCisJCWJhc2ljX21hY2hpbmU9aTg2MC1pbnRlbAorCQlvcz0tb3NmCisJCTs7CisJcGFy
aXNjKQorCQliYXNpY19tYWNoaW5lPWhwcGEtdW5rbm93bgorCQlvcz0tbGludXgKKwkJOzsKKwlw
YXJpc2MtKikKKwkJYmFzaWNfbWFjaGluZT1ocHBhLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2Vk
ICdzL15bXi1dKi0vLydgCisJCW9zPS1saW51eAorCQk7OworCXBiZCkKKwkJYmFzaWNfbWFjaGlu
ZT1zcGFyYy10dGkKKwkJOzsKKwlwYmIpCisJCWJhc2ljX21hY2hpbmU9bTY4ay10dGkKKwkJOzsK
KwlwYzUzMiB8IHBjNTMyLSopCisJCWJhc2ljX21hY2hpbmU9bnMzMmstcGM1MzIKKwkJOzsKKwlw
Yzk4KQorCQliYXNpY19tYWNoaW5lPWkzODYtcGMKKwkJOzsKKwlwYzk4LSopCisJCWJhc2ljX21h
Y2hpbmU9aTM4Ni1gZWNobyAkYmFzaWNfbWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7
OworCXBlbnRpdW0gfCBwNSB8IGs1IHwgazYgfCBuZXhnZW4gfCB2aWFjMykKKwkJYmFzaWNfbWFj
aGluZT1pNTg2LXBjCisJCTs7CisJcGVudGl1bXBybyB8IHA2IHwgNng4NiB8IGF0aGxvbiB8IGF0
aGxvbl8qKQorCQliYXNpY19tYWNoaW5lPWk2ODYtcGMKKwkJOzsKKwlwZW50aXVtaWkgfCBwZW50
aXVtMiB8IHBlbnRpdW1paWkgfCBwZW50aXVtMykKKwkJYmFzaWNfbWFjaGluZT1pNjg2LXBjCisJ
CTs7CisJcGVudGl1bTQpCisJCWJhc2ljX21hY2hpbmU9aTc4Ni1wYworCQk7OworCXBlbnRpdW0t
KiB8IHA1LSogfCBrNS0qIHwgazYtKiB8IG5leGdlbi0qIHwgdmlhYzMtKikKKwkJYmFzaWNfbWFj
aGluZT1pNTg2LWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0vLydgCisJCTs7
CisJcGVudGl1bXByby0qIHwgcDYtKiB8IDZ4ODYtKiB8IGF0aGxvbi0qKQorCQliYXNpY19tYWNo
aW5lPWk2ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsK
KwlwZW50aXVtaWktKiB8IHBlbnRpdW0yLSogfCBwZW50aXVtaWlpLSogfCBwZW50aXVtMy0qKQor
CQliYXNpY19tYWNoaW5lPWk2ODYtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0q
LS8vJ2AKKwkJOzsKKwlwZW50aXVtNC0qKQorCQliYXNpY19tYWNoaW5lPWk3ODYtYGVjaG8gJGJh
c2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwbikKKwkJYmFzaWNfbWFj
aGluZT1wbi1nb3VsZAorCQk7OworCXBvd2VyKQliYXNpY19tYWNoaW5lPXBvd2VyLWlibQorCQk7
OworCXBwYykJYmFzaWNfbWFjaGluZT1wb3dlcnBjLXVua25vd24KKwkJOzsKKwlwcGMtKikJYmFz
aWNfbWFjaGluZT1wb3dlcnBjLWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL15bXi1dKi0v
LydgCisJCTs7CisJcHBjbGUgfCBwb3dlcnBjbGl0dGxlIHwgcHBjLWxlIHwgcG93ZXJwYy1saXR0
bGUpCisJCWJhc2ljX21hY2hpbmU9cG93ZXJwY2xlLXVua25vd24KKwkJOzsKKwlwcGNsZS0qIHwg
cG93ZXJwY2xpdHRsZS0qKQorCQliYXNpY19tYWNoaW5lPXBvd2VycGNsZS1gZWNobyAkYmFzaWNf
bWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBwYzY0KQliYXNpY19tYWNoaW5l
PXBvd2VycGM2NC11bmtub3duCisJCTs7CisJcHBjNjQtKikgYmFzaWNfbWFjaGluZT1wb3dlcnBj
NjQtYGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvXlteLV0qLS8vJ2AKKwkJOzsKKwlwcGM2
NGxlIHwgcG93ZXJwYzY0bGl0dGxlIHwgcHBjNjQtbGUgfCBwb3dlcnBjNjQtbGl0dGxlKQorCQli
YXNpY19tYWNoaW5lPXBvd2VycGM2NGxlLXVua25vd24KKwkJOzsKKwlwcGM2NGxlLSogfCBwb3dl
cnBjNjRsaXR0bGUtKikKKwkJYmFzaWNfbWFjaGluZT1wb3dlcnBjNjRsZS1gZWNobyAkYmFzaWNf
bWFjaGluZSB8IHNlZCAncy9eW14tXSotLy8nYAorCQk7OworCXBzMikKKwkJYmFzaWNfbWFjaGlu
ZT1pMzg2LWlibQorCQk7OworCXB3MzIpCisJCWJhc2ljX21hY2hpbmU9aTU4Ni11bmtub3duCisJ
CW9zPS1wdzMyCisJCTs7CisJcmRvcykKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXBjCisJCW9zPS1y
ZG9zCisJCTs7CisJcm9tNjhrKQorCQliYXNpY19tYWNoaW5lPW02OGstcm9tNjhrCisJCW9zPS1j
b2ZmCisJCTs7CisJcm1bNDZdMDApCisJCWJhc2ljX21hY2hpbmU9bWlwcy1zaWVtZW5zCisJCTs7
CisJcnRwYyB8IHJ0cGMtKikKKwkJYmFzaWNfbWFjaGluZT1yb21wLWlibQorCQk7OworCXMzOTAg
fCBzMzkwLSopCisJCWJhc2ljX21hY2hpbmU9czM5MC1pYm0KKwkJOzsKKwlzMzkweCB8IHMzOTB4
LSopCisJCWJhc2ljX21hY2hpbmU9czM5MHgtaWJtCisJCTs7CisJc2EyOTIwMCkKKwkJYmFzaWNf
bWFjaGluZT1hMjlrLWFtZAorCQlvcz0tdWRpCisJCTs7CisJc2IxKQorCQliYXNpY19tYWNoaW5l
PW1pcHNpc2E2NHNiMS11bmtub3duCisJCTs7CisJc2IxZWwpCisJCWJhc2ljX21hY2hpbmU9bWlw
c2lzYTY0c2IxZWwtdW5rbm93bgorCQk7OworCXNkZSkKKwkJYmFzaWNfbWFjaGluZT1taXBzaXNh
MzItc2RlCisJCW9zPS1lbGYKKwkJOzsKKwlzZWkpCisJCWJhc2ljX21hY2hpbmU9bWlwcy1zZWkK
KwkJb3M9LXNlaXV4CisJCTs7CisJc2VxdWVudCkKKwkJYmFzaWNfbWFjaGluZT1pMzg2LXNlcXVl
bnQKKwkJOzsKKwlzaCkKKwkJYmFzaWNfbWFjaGluZT1zaC1oaXRhY2hpCisJCW9zPS1obXMKKwkJ
OzsKKwlzaDVlbCkKKwkJYmFzaWNfbWFjaGluZT1zaDVsZS11bmtub3duCisJCTs7CisJc2g2NCkK
KwkJYmFzaWNfbWFjaGluZT1zaDY0LXVua25vd24KKwkJOzsKKwlzcGFyY2xpdGUtd3JzIHwgc2lt
c28td3JzKQorCQliYXNpY19tYWNoaW5lPXNwYXJjbGl0ZS13cnMKKwkJb3M9LXZ4d29ya3MKKwkJ
OzsKKwlzcHM3KQorCQliYXNpY19tYWNoaW5lPW02OGstYnVsbAorCQlvcz0tc3lzdjIKKwkJOzsK
KwlzcHVyKQorCQliYXNpY19tYWNoaW5lPXNwdXItdW5rbm93bgorCQk7OworCXN0MjAwMCkKKwkJ
YmFzaWNfbWFjaGluZT1tNjhrLXRhbmRlbQorCQk7OworCXN0cmF0dXMpCisJCWJhc2ljX21hY2hp
bmU9aTg2MC1zdHJhdHVzCisJCW9zPS1zeXN2NAorCQk7OworCXN1bjIpCisJCWJhc2ljX21hY2hp
bmU9bTY4MDAwLXN1bgorCQk7OworCXN1bjJvczMpCisJCWJhc2ljX21hY2hpbmU9bTY4MDAwLXN1
bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuMm9zNCkKKwkJYmFzaWNfbWFjaGluZT1tNjgwMDAt
c3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW4zb3MzKQorCQliYXNpY19tYWNoaW5lPW02OGst
c3VuCisJCW9zPS1zdW5vczMKKwkJOzsKKwlzdW4zb3M0KQorCQliYXNpY19tYWNoaW5lPW02OGst
c3VuCisJCW9zPS1zdW5vczQKKwkJOzsKKwlzdW40b3MzKQorCQliYXNpY19tYWNoaW5lPXNwYXJj
LXN1bgorCQlvcz0tc3Vub3MzCisJCTs7CisJc3VuNG9zNCkKKwkJYmFzaWNfbWFjaGluZT1zcGFy
Yy1zdW4KKwkJb3M9LXN1bm9zNAorCQk7OworCXN1bjRzb2wyKQorCQliYXNpY19tYWNoaW5lPXNw
YXJjLXN1bgorCQlvcz0tc29sYXJpczIKKwkJOzsKKwlzdW4zIHwgc3VuMy0qKQorCQliYXNpY19t
YWNoaW5lPW02OGstc3VuCisJCTs7CisJc3VuNCkKKwkJYmFzaWNfbWFjaGluZT1zcGFyYy1zdW4K
KwkJOzsKKwlzdW4zODYgfCBzdW4zODZpIHwgcm9hZHJ1bm5lcikKKwkJYmFzaWNfbWFjaGluZT1p
Mzg2LXN1bgorCQk7OworCXN2MSkKKwkJYmFzaWNfbWFjaGluZT1zdjEtY3JheQorCQlvcz0tdW5p
Y29zCisJCTs7CisJc3ltbWV0cnkpCisJCWJhc2ljX21hY2hpbmU9aTM4Ni1zZXF1ZW50CisJCW9z
PS1keW5peAorCQk7OworCXQzZSkKKwkJYmFzaWNfbWFjaGluZT1hbHBoYWV2NS1jcmF5CisJCW9z
PS11bmljb3MKKwkJOzsKKwl0OTApCisJCWJhc2ljX21hY2hpbmU9dDkwLWNyYXkKKwkJb3M9LXVu
aWNvcworCQk7OworCXRpYzU0eCB8IGM1NHgqKQorCQliYXNpY19tYWNoaW5lPXRpYzU0eC11bmtu
b3duCisJCW9zPS1jb2ZmCisJCTs7CisJdGljNTV4IHwgYzU1eCopCisJCWJhc2ljX21hY2hpbmU9
dGljNTV4LXVua25vd24KKwkJb3M9LWNvZmYKKwkJOzsKKwl0aWM2eCB8IGM2eCopCisJCWJhc2lj
X21hY2hpbmU9dGljNngtdW5rbm93bgorCQlvcz0tY29mZgorCQk7OworCXRpbGUqKQorCQliYXNp
Y19tYWNoaW5lPXRpbGUtdW5rbm93bgorCQlvcz0tbGludXgtZ251CisJCTs7CisJdHgzOSkKKwkJ
YmFzaWNfbWFjaGluZT1taXBzdHgzOS11bmtub3duCisJCTs7CisJdHgzOWVsKQorCQliYXNpY19t
YWNoaW5lPW1pcHN0eDM5ZWwtdW5rbm93bgorCQk7OworCXRvYWQxKQorCQliYXNpY19tYWNoaW5l
PXBkcDEwLXhrbAorCQlvcz0tdG9wczIwCisJCTs7CisJdG93ZXIgfCB0b3dlci0zMikKKwkJYmFz
aWNfbWFjaGluZT1tNjhrLW5jcgorCQk7OworCXRwZikKKwkJYmFzaWNfbWFjaGluZT1zMzkweC1p
Ym0KKwkJb3M9LXRwZgorCQk7OworCXVkaTI5aykKKwkJYmFzaWNfbWFjaGluZT1hMjlrLWFtZAor
CQlvcz0tdWRpCisJCTs7CisJdWx0cmEzKQorCQliYXNpY19tYWNoaW5lPWEyOWstbnl1CisJCW9z
PS1zeW0xCisJCTs7CisJdjgxMCB8IG5lY3Y4MTApCisJCWJhc2ljX21hY2hpbmU9djgxMC1uZWMK
KwkJb3M9LW5vbmUKKwkJOzsKKwl2YXh2KQorCQliYXNpY19tYWNoaW5lPXZheC1kZWMKKwkJb3M9
LXN5c3YKKwkJOzsKKwl2bXMpCisJCWJhc2ljX21hY2hpbmU9dmF4LWRlYworCQlvcz0tdm1zCisJ
CTs7CisJdnBwKnx2eHx2eC0qKQorCQliYXNpY19tYWNoaW5lPWYzMDEtZnVqaXRzdQorCQk7Owor
CXZ4d29ya3M5NjApCisJCWJhc2ljX21hY2hpbmU9aTk2MC13cnMKKwkJb3M9LXZ4d29ya3MKKwkJ
OzsKKwl2eHdvcmtzNjgpCisJCWJhc2ljX21hY2hpbmU9bTY4ay13cnMKKwkJb3M9LXZ4d29ya3MK
KwkJOzsKKwl2eHdvcmtzMjlrKQorCQliYXNpY19tYWNoaW5lPWEyOWstd3JzCisJCW9zPS12eHdv
cmtzCisJCTs7CisJdzY1KikKKwkJYmFzaWNfbWFjaGluZT13NjUtd2RjCisJCW9zPS1ub25lCisJ
CTs7CisJdzg5ay0qKQorCQliYXNpY19tYWNoaW5lPWhwcGExLjEtd2luYm9uZAorCQlvcz0tcHJv
ZWxmCisJCTs7CisJeGJveCkKKwkJYmFzaWNfbWFjaGluZT1pNjg2LXBjCisJCW9zPS1taW5ndzMy
CisJCTs7CisJeHBzIHwgeHBzMTAwKQorCQliYXNpY19tYWNoaW5lPXhwczEwMC1ob25leXdlbGwK
KwkJOzsKKwl5bXApCisJCWJhc2ljX21hY2hpbmU9eW1wLWNyYXkKKwkJb3M9LXVuaWNvcworCQk7
OworCXo4ay0qLWNvZmYpCisJCWJhc2ljX21hY2hpbmU9ejhrLXVua25vd24KKwkJb3M9LXNpbQor
CQk7OworCXo4MC0qLWNvZmYpCisJCWJhc2ljX21hY2hpbmU9ejgwLXVua25vd24KKwkJb3M9LXNp
bQorCQk7OworCW5vbmUpCisJCWJhc2ljX21hY2hpbmU9bm9uZS1ub25lCisJCW9zPS1ub25lCisJ
CTs7CisKKyMgSGVyZSB3ZSBoYW5kbGUgdGhlIGRlZmF1bHQgbWFudWZhY3R1cmVyIG9mIGNlcnRh
aW4gQ1BVIHR5cGVzLiAgSXQgaXMgaW4KKyMgc29tZSBjYXNlcyB0aGUgb25seSBtYW51ZmFjdHVy
ZXIsIGluIG90aGVycywgaXQgaXMgdGhlIG1vc3QgcG9wdWxhci4KKwl3ODlrKQorCQliYXNpY19t
YWNoaW5lPWhwcGExLjEtd2luYm9uZAorCQk7OworCW9wNTBuKQorCQliYXNpY19tYWNoaW5lPWhw
cGExLjEtb2tpCisJCTs7CisJb3A2MGMpCisJCWJhc2ljX21hY2hpbmU9aHBwYTEuMS1va2kKKwkJ
OzsKKwlyb21wKQorCQliYXNpY19tYWNoaW5lPXJvbXAtaWJtCisJCTs7CisJbW1peCkKKwkJYmFz
aWNfbWFjaGluZT1tbWl4LWtudXRoCisJCTs7CisJcnM2MDAwKQorCQliYXNpY19tYWNoaW5lPXJz
NjAwMC1pYm0KKwkJOzsKKwl2YXgpCisJCWJhc2ljX21hY2hpbmU9dmF4LWRlYworCQk7OworCXBk
cDEwKQorCQkjIHRoZXJlIGFyZSBtYW55IGNsb25lcywgc28gREVDIGlzIG5vdCBhIHNhZmUgYmV0
CisJCWJhc2ljX21hY2hpbmU9cGRwMTAtdW5rbm93bgorCQk7OworCXBkcDExKQorCQliYXNpY19t
YWNoaW5lPXBkcDExLWRlYworCQk7OworCXdlMzJrKQorCQliYXNpY19tYWNoaW5lPXdlMzJrLWF0
dAorCQk7OworCXNoWzEyMzRdIHwgc2hbMjRdYSB8IHNoWzI0XWFlYiB8IHNoWzM0XWViIHwgc2hb
MTIzNF1sZSB8IHNoWzIzXWVsZSkKKwkJYmFzaWNfbWFjaGluZT1zaC11bmtub3duCisJCTs7CisJ
c3BhcmMgfCBzcGFyY3Y4IHwgc3BhcmN2OSB8IHNwYXJjdjliIHwgc3BhcmN2OXYpCisJCWJhc2lj
X21hY2hpbmU9c3BhcmMtc3VuCisJCTs7CisJY3lkcmEpCisJCWJhc2ljX21hY2hpbmU9Y3lkcmEt
Y3lkcm9tZQorCQk7OworCW9yaW9uKQorCQliYXNpY19tYWNoaW5lPW9yaW9uLWhpZ2hsZXZlbAor
CQk7OworCW9yaW9uMTA1KQorCQliYXNpY19tYWNoaW5lPWNsaXBwZXItaGlnaGxldmVsCisJCTs7
CisJbWFjIHwgbXB3IHwgbWFjLW1wdykKKwkJYmFzaWNfbWFjaGluZT1tNjhrLWFwcGxlCisJCTs7
CisJcG1hYyB8IHBtYWMtbXB3KQorCQliYXNpY19tYWNoaW5lPXBvd2VycGMtYXBwbGUKKwkJOzsK
KwkqLXVua25vd24pCisJCSMgTWFrZSBzdXJlIHRvIG1hdGNoIGFuIGFscmVhZHktY2Fub25pY2Fs
aXplZCBtYWNoaW5lIG5hbWUuCisJCTs7CisJKikKKwkJZWNobyBJbnZhbGlkIGNvbmZpZ3VyYXRp
b24gXGAkMVwnOiBtYWNoaW5lIFxgJGJhc2ljX21hY2hpbmVcJyBub3QgcmVjb2duaXplZCAxPiYy
CisJCWV4aXQgMQorCQk7OworZXNhYworCisjIEhlcmUgd2UgY2Fub25pY2FsaXplIGNlcnRhaW4g
YWxpYXNlcyBmb3IgbWFudWZhY3R1cmVycy4KK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwkqLWRp
Z2l0YWwqKQorCQliYXNpY19tYWNoaW5lPWBlY2hvICRiYXNpY19tYWNoaW5lIHwgc2VkICdzL2Rp
Z2l0YWwuKi9kZWMvJ2AKKwkJOzsKKwkqLWNvbW1vZG9yZSopCisJCWJhc2ljX21hY2hpbmU9YGVj
aG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgJ3MvY29tbW9kb3JlLiovY2JtLydgCisJCTs7CisJKikK
KwkJOzsKK2VzYWMKKworIyBEZWNvZGUgbWFudWZhY3R1cmVyLXNwZWNpZmljIGFsaWFzZXMgZm9y
IGNlcnRhaW4gb3BlcmF0aW5nIHN5c3RlbXMuCisKK2lmIFsgeCIkb3MiICE9IHgiIiBdCit0aGVu
CitjYXNlICRvcyBpbgorICAgICAgICAjIEZpcnN0IG1hdGNoIHNvbWUgc3lzdGVtIHR5cGUgYWxp
YXNlcworICAgICAgICAjIHRoYXQgbWlnaHQgZ2V0IGNvbmZ1c2VkIHdpdGggdmFsaWQgc3lzdGVt
IHR5cGVzLgorCSMgLXNvbGFyaXMqIGlzIGEgYmFzaWMgc3lzdGVtIHR5cGUsIHdpdGggdGhpcyBv
bmUgZXhjZXB0aW9uLgorICAgICAgICAtYXVyb3JhdXgpCisJICAgICAgICBvcz0tYXVyb3JhdXgK
KwkJOzsKKwktc29sYXJpczEgfCAtc29sYXJpczEuKikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1l
ICdzfHNvbGFyaXMxfHN1bm9zNHwnYAorCQk7OworCS1zb2xhcmlzKQorCQlvcz0tc29sYXJpczIK
KwkJOzsKKwktc3ZyNCopCisJCW9zPS1zeXN2NAorCQk7OworCS11bml4d2FyZSopCisJCW9zPS1z
eXN2NC4ydXcKKwkJOzsKKwktZ251L2xpbnV4KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdz
fGdudS9saW51eHxsaW51eC1nbnV8J2AKKwkJOzsKKwkjIEZpcnN0IGFjY2VwdCB0aGUgYmFzaWMg
c3lzdGVtIHR5cGVzLgorCSMgVGhlIHBvcnRhYmxlIHN5c3RlbXMgY29tZXMgZmlyc3QuCisJIyBF
YWNoIGFsdGVybmF0aXZlIE1VU1QgRU5EIElOIEEgKiwgdG8gbWF0Y2ggYSB2ZXJzaW9uIG51bWJl
ci4KKwkjIC1zeXN2KiBpcyBub3QgaGVyZSBiZWNhdXNlIGl0IGNvbWVzIGxhdGVyLCBhZnRlciBz
eXN2cjQuCisJLWdudSogfCAtYnNkKiB8IC1tYWNoKiB8IC1taW5peCogfCAtZ2VuaXgqIHwgLXVs
dHJpeCogfCAtaXJpeCogXAorCSAgICAgIHwgLSp2bXMqIHwgLXNjbyogfCAtZXNpeCogfCAtaXNj
KiB8IC1haXgqIHwgLWNuayogfCAtc3Vub3MgfCAtc3Vub3NbMzRdKlwKKwkgICAgICB8IC1ocHV4
KiB8IC11bm9zKiB8IC1vc2YqIHwgLWx1bmEqIHwgLWRndXgqIHwgLWF1cm9yYXV4KiB8IC1zb2xh
cmlzKiBcCisJICAgICAgfCAtc3ltKiB8IC1rb3BlbnNvbGFyaXMqIFwKKwkgICAgICB8IC1hbWln
YW9zKiB8IC1hbWlnYWRvcyogfCAtbXNkb3MqIHwgLW5ld3NvcyogfCAtdW5pY29zKiB8IC1hb2Yq
IFwKKwkgICAgICB8IC1hb3MqIHwgLWFyb3MqIFwKKwkgICAgICB8IC1uaW5keSogfCAtdnhzaW0q
IHwgLXZ4d29ya3MqIHwgLWVibW9uKiB8IC1obXMqIHwgLW12cyogXAorCSAgICAgIHwgLWNsaXgq
IHwgLXJpc2NvcyogfCAtdW5pcGx1cyogfCAtaXJpcyogfCAtcnR1KiB8IC14ZW5peCogXAorCSAg
ICAgIHwgLWhpdXgqIHwgLTM4NmJzZCogfCAta25ldGJzZCogfCAtbWlyYnNkKiB8IC1uZXRic2Qq
IFwKKwkgICAgICB8IC1vcGVuYnNkKiB8IC1zb2xpZGJzZCogXAorCSAgICAgIHwgLWVra29ic2Qq
IHwgLWtmcmVlYnNkKiB8IC1mcmVlYnNkKiB8IC1yaXNjaXgqIHwgLWx5bnhvcyogXAorCSAgICAg
IHwgLWJvc3gqIHwgLW5leHRzdGVwKiB8IC1jeHV4KiB8IC1hb3V0KiB8IC1lbGYqIHwgLW9hYmkq
IFwKKwkgICAgICB8IC1wdHgqIHwgLWNvZmYqIHwgLWVjb2ZmKiB8IC13aW5udCogfCAtZG9tYWlu
KiB8IC12c3RhKiBcCisJICAgICAgfCAtdWRpKiB8IC1lYWJpKiB8IC1saXRlcyogfCAtaWVlZSog
fCAtZ28zMiogfCAtYXV4KiBcCisJICAgICAgfCAtY2hvcnVzb3MqIHwgLWNob3J1c3JkYiogfCAt
Y2VnY2MqIFwKKwkgICAgICB8IC1jeWd3aW4qIHwgLXBlKiB8IC1wc29zKiB8IC1tb3NzKiB8IC1w
cm9lbGYqIHwgLXJ0ZW1zKiBcCisJICAgICAgfCAtbWluZ3czMiogfCAtbGludXgtZ251KiB8IC1s
aW51eC1uZXdsaWIqIHwgLWxpbnV4LXVjbGliYyogXAorCSAgICAgIHwgLXV4cHYqIHwgLWJlb3Mq
IHwgLW1wZWl4KiB8IC11ZGsqIFwKKwkgICAgICB8IC1pbnRlcml4KiB8IC11d2luKiB8IC1ta3Mq
IHwgLXJoYXBzb2R5KiB8IC1kYXJ3aW4qIHwgLW9wZW5lZCogXAorCSAgICAgIHwgLW9wZW5zdGVw
KiB8IC1vc2tpdCogfCAtY29uaXgqIHwgLXB3MzIqIHwgLW5vbnN0b3B1eCogXAorCSAgICAgIHwg
LXN0b3JtLWNoYW9zKiB8IC10b3BzMTAqIHwgLXRlbmV4KiB8IC10b3BzMjAqIHwgLWl0cyogXAor
CSAgICAgIHwgLW9zMiogfCAtdm9zKiB8IC1wYWxtb3MqIHwgLXVjbGludXgqIHwgLW51Y2xldXMq
IFwKKwkgICAgICB8IC1tb3JwaG9zKiB8IC1zdXBlcnV4KiB8IC1ydG1rKiB8IC1ydG1rLW5vdmEq
IHwgLXdpbmRpc3MqIFwKKwkgICAgICB8IC1wb3dlcm1heCogfCAtZG5peCogfCAtbng2IHwgLW54
NyB8IC1zZWkqIHwgLWRyYWdvbmZseSogXAorCSAgICAgIHwgLXNreW9zKiB8IC1oYWlrdSogfCAt
cmRvcyogfCAtdG9wcGVycyogfCAtZHJvcHMqIHwgLWVzKikKKwkjIFJlbWVtYmVyLCBlYWNoIGFs
dGVybmF0aXZlIE1VU1QgRU5EIElOICosIHRvIG1hdGNoIGEgdmVyc2lvbiBudW1iZXIuCisJCTs7
CisJLXFueCopCisJCWNhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwkJICAgIHg4Ni0qIHwgaSo4Ni0q
KQorCQkJOzsKKwkJICAgICopCisJCQlvcz0tbnRvJG9zCisJCQk7OworCQllc2FjCisJCTs7CisJ
LW50by1xbngqKQorCQk7OworCS1udG8qKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8bnRv
fG50by1xbnh8J2AKKwkJOzsKKwktc2ltIHwgLWVzMTgwMCogfCAtaG1zKiB8IC14cmF5IHwgLW9z
NjhrKiB8IC1ub25lKiB8IC12ODhyKiBcCisJICAgICAgfCAtd2luZG93cyogfCAtb3N4IHwgLWFi
dWcgfCAtbmV0d2FyZSogfCAtb3M5KiB8IC1iZW9zKiB8IC1oYWlrdSogXAorCSAgICAgIHwgLW1h
Y29zKiB8IC1tcHcqIHwgLW1hZ2ljKiB8IC1tbWl4d2FyZSogfCAtbW9uOTYwKiB8IC1sbmV3cyop
CisJCTs7CisJLW1hYyopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xtYWN8bWFjb3N8J2AK
KwkJOzsKKwktbGludXgtZGlldGxpYmMpCisJCW9zPS1saW51eC1kaWV0bGliYworCQk7OworCS1s
aW51eCopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAnc3xsaW51eHxsaW51eC1nbnV8J2AKKwkJ
OzsKKwktc3Vub3M1KikKKwkJb3M9YGVjaG8gJG9zIHwgc2VkIC1lICdzfHN1bm9zNXxzb2xhcmlz
MnwnYAorCQk7OworCS1zdW5vczYqKQorCQlvcz1gZWNobyAkb3MgfCBzZWQgLWUgJ3N8c3Vub3M2
fHNvbGFyaXMzfCdgCisJCTs7CisJLW9wZW5lZCopCisJCW9zPS1vcGVuZWRpdGlvbgorCQk7Owor
ICAgICAgICAtb3M0MDAqKQorCQlvcz0tb3M0MDAKKwkJOzsKKwktd2luY2UqKQorCQlvcz0td2lu
Y2UKKwkJOzsKKwktb3Nmcm9zZSopCisJCW9zPS1vc2Zyb3NlCisJCTs7CisJLW9zZiopCisJCW9z
PS1vc2YKKwkJOzsKKwktdXRlayopCisJCW9zPS1ic2QKKwkJOzsKKwktZHluaXgqKQorCQlvcz0t
YnNkCisJCTs7CisJLWFjaXMqKQorCQlvcz0tYW9zCisJCTs7CisJLWF0aGVvcyopCisJCW9zPS1h
dGhlb3MKKwkJOzsKKwktc3lsbGFibGUqKQorCQlvcz0tc3lsbGFibGUKKwkJOzsKKwktMzg2YnNk
KQorCQlvcz0tYnNkCisJCTs7CisJLWN0aXgqIHwgLXV0cyopCisJCW9zPS1zeXN2CisJCTs7CisJ
LW5vdmEqKQorCQlvcz0tcnRtay1ub3ZhCisJCTs7CisJLW5zMiApCisJCW9zPS1uZXh0c3RlcDIK
KwkJOzsKKwktbnNrKikKKwkJb3M9LW5zaworCQk7OworCSMgUHJlc2VydmUgdGhlIHZlcnNpb24g
bnVtYmVyIG9mIHNpbml4NS4KKwktc2luaXg1LiopCisJCW9zPWBlY2hvICRvcyB8IHNlZCAtZSAn
c3xzaW5peHxzeXN2fCdgCisJCTs7CisJLXNpbml4KikKKwkJb3M9LXN5c3Y0CisJCTs7CisgICAg
ICAgIC10cGYqKQorCQlvcz0tdHBmCisJCTs7CisJLXRyaXRvbiopCisJCW9zPS1zeXN2MworCQk7
OworCS1vc3MqKQorCQlvcz0tc3lzdjMKKwkJOzsKKwktc3ZyNCkKKwkJb3M9LXN5c3Y0CisJCTs7
CisJLXN2cjMpCisJCW9zPS1zeXN2MworCQk7OworCS1zeXN2cjQpCisJCW9zPS1zeXN2NAorCQk7
OworCSMgVGhpcyBtdXN0IGNvbWUgYWZ0ZXIgLXN5c3ZyNC4KKwktc3lzdiopCisJCTs7CisJLW9z
ZSopCisJCW9zPS1vc2UKKwkJOzsKKwktZXMxODAwKikKKwkJb3M9LW9zZQorCQk7OworCS14ZW5p
eCkKKwkJb3M9LXhlbml4CisJCTs7CisJLSptaW50IHwgLW1pbnRbMC05XSogfCAtKk1pTlQgfCAt
TWlOVFswLTldKikKKwkJb3M9LW1pbnQKKwkJOzsKKwktYXJvcyopCisJCW9zPS1hcm9zCisJCTs7
CisJLWthb3MqKQorCQlvcz0ta2FvcworCQk7OworCS16dm1vZSkKKwkJb3M9LXp2bW9lCisJCTs7
CisJLWRpY29zKikKKwkJb3M9LWRpY29zCisJCTs7CisJLW5vbmUpCisJCTs7CisJKikKKwkJIyBH
ZXQgcmlkIG9mIHRoZSBgLScgYXQgdGhlIGJlZ2lubmluZyBvZiAkb3MuCisJCW9zPWBlY2hvICRv
cyB8IHNlZCAncy9bXi1dKi0vLydgCisJCWVjaG8gSW52YWxpZCBjb25maWd1cmF0aW9uIFxgJDFc
Jzogc3lzdGVtIFxgJG9zXCcgbm90IHJlY29nbml6ZWQgMT4mMgorCQlleGl0IDEKKwkJOzsKK2Vz
YWMKK2Vsc2UKKworIyBIZXJlIHdlIGhhbmRsZSB0aGUgZGVmYXVsdCBvcGVyYXRpbmcgc3lzdGVt
cyB0aGF0IGNvbWUgd2l0aCB2YXJpb3VzIG1hY2hpbmVzLgorIyBUaGUgdmFsdWUgc2hvdWxkIGJl
IHdoYXQgdGhlIHZlbmRvciBjdXJyZW50bHkgc2hpcHMgb3V0IHRoZSBkb29yIHdpdGggdGhlaXIK
KyMgbWFjaGluZSBvciBwdXQgYW5vdGhlciB3YXksIHRoZSBtb3N0IHBvcHVsYXIgb3MgcHJvdmlk
ZWQgd2l0aCB0aGUgbWFjaGluZS4KKworIyBOb3RlIHRoYXQgaWYgeW91J3JlIGdvaW5nIHRvIHRy
eSB0byBtYXRjaCAiLU1BTlVGQUNUVVJFUiIgaGVyZSAoc2F5LAorIyAiLXN1biIpLCB0aGVuIHlv
dSBoYXZlIHRvIHRlbGwgdGhlIGNhc2Ugc3RhdGVtZW50IHVwIHRvd2FyZHMgdGhlIHRvcAorIyB0
aGF0IE1BTlVGQUNUVVJFUiBpc24ndCBhbiBvcGVyYXRpbmcgc3lzdGVtLiAgT3RoZXJ3aXNlLCBj
b2RlIGFib3ZlCisjIHdpbGwgc2lnbmFsIGFuIGVycm9yIHNheWluZyB0aGF0IE1BTlVGQUNUVVJF
UiBpc24ndCBhbiBvcGVyYXRpbmcKKyMgc3lzdGVtLCBhbmQgd2UnbGwgbmV2ZXIgZ2V0IHRvIHRo
aXMgcG9pbnQuCisKK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKyAgICAgICAgc2NvcmUtKikKKwkJ
b3M9LWVsZgorCQk7OworICAgICAgICBzcHUtKikKKwkJb3M9LWVsZgorCQk7OworCSotYWNvcm4p
CisJCW9zPS1yaXNjaXgxLjIKKwkJOzsKKwlhcm0qLXJlYmVsKQorCQlvcz0tbGludXgKKwkJOzsK
Kwlhcm0qLXNlbWkpCisJCW9zPS1hb3V0CisJCTs7CisgICAgICAgIGM0eC0qIHwgdGljNHgtKikK
KyAgICAgICAgCW9zPS1jb2ZmCisJCTs7CisJIyBUaGlzIG11c3QgY29tZSBiZWZvcmUgdGhlICot
ZGVjIGVudHJ5LgorCXBkcDEwLSopCisJCW9zPS10b3BzMjAKKwkJOzsKKwlwZHAxMS0qKQorCQlv
cz0tbm9uZQorCQk7OworCSotZGVjIHwgdmF4LSopCisJCW9zPS11bHRyaXg0LjIKKwkJOzsKKwlt
NjgqLWFwb2xsbykKKwkJb3M9LWRvbWFpbgorCQk7OworCWkzODYtc3VuKQorCQlvcz0tc3Vub3M0
LjAuMgorCQk7OworCW02ODAwMC1zdW4pCisJCW9zPS1zdW5vczMKKwkJIyBUaGlzIGFsc28gZXhp
c3RzIGluIHRoZSBjb25maWd1cmUgcHJvZ3JhbSwgYnV0IHdhcyBub3QgdGhlCisJCSMgZGVmYXVs
dC4KKwkJIyBvcz0tc3Vub3M0CisJCTs7CisJbTY4Ki1jaXNjbykKKwkJb3M9LWFvdXQKKwkJOzsK
KyAgICAgICAgbWVwLSopCisJCW9zPS1lbGYKKwkJOzsKKwltaXBzKi1jaXNjbykKKwkJb3M9LWVs
ZgorCQk7OworCW1pcHMqLSopCisJCW9zPS1lbGYKKwkJOzsKKwlvcjMyLSopCisJCW9zPS1jb2Zm
CisJCTs7CisJKi10dGkpCSMgbXVzdCBiZSBiZWZvcmUgc3BhcmMgZW50cnkgb3Igd2UgZ2V0IHRo
ZSB3cm9uZyBvcy4KKwkJb3M9LXN5c3YzCisJCTs7CisJc3BhcmMtKiB8ICotc3VuKQorCQlvcz0t
c3Vub3M0LjEuMQorCQk7OworCSotYmUpCisJCW9zPS1iZW9zCisJCTs7CisJKi1oYWlrdSkKKwkJ
b3M9LWhhaWt1CisJCTs7CisJKi1pYm0pCisJCW9zPS1haXgKKwkJOzsKKyAgICAJKi1rbnV0aCkK
KwkJb3M9LW1taXh3YXJlCisJCTs7CisJKi13ZWMpCisJCW9zPS1wcm9lbGYKKwkJOzsKKwkqLXdp
bmJvbmQpCisJCW9zPS1wcm9lbGYKKwkJOzsKKwkqLW9raSkKKwkJb3M9LXByb2VsZgorCQk7Owor
CSotaHApCisJCW9zPS1ocHV4CisJCTs7CisJKi1oaXRhY2hpKQorCQlvcz0taGl1eAorCQk7Owor
CWk4NjAtKiB8ICotYXR0IHwgKi1uY3IgfCAqLWFsdG9zIHwgKi1tb3Rvcm9sYSB8ICotY29udmVy
Z2VudCkKKwkJb3M9LXN5c3YKKwkJOzsKKwkqLWNibSkKKwkJb3M9LWFtaWdhb3MKKwkJOzsKKwkq
LWRnKQorCQlvcz0tZGd1eAorCQk7OworCSotZG9scGhpbikKKwkJb3M9LXN5c3YzCisJCTs7CisJ
bTY4ay1jY3VyKQorCQlvcz0tcnR1CisJCTs7CisJbTg4ay1vbXJvbiopCisJCW9zPS1sdW5hCisJ
CTs7CisJKi1uZXh0ICkKKwkJb3M9LW5leHRzdGVwCisJCTs7CisJKi1zZXF1ZW50KQorCQlvcz0t
cHR4CisJCTs7CisJKi1jcmRzKQorCQlvcz0tdW5vcworCQk7OworCSotbnMpCisJCW9zPS1nZW5p
eAorCQk7OworCWkzNzAtKikKKwkJb3M9LW12cworCQk7OworCSotbmV4dCkKKwkJb3M9LW5leHRz
dGVwMworCQk7OworCSotZ291bGQpCisJCW9zPS1zeXN2CisJCTs7CisJKi1oaWdobGV2ZWwpCisJ
CW9zPS1ic2QKKwkJOzsKKwkqLWVuY29yZSkKKwkJb3M9LWJzZAorCQk7OworCSotc2dpKQorCQlv
cz0taXJpeAorCQk7OworCSotc2llbWVucykKKwkJb3M9LXN5c3Y0CisJCTs7CisJKi1tYXNzY29t
cCkKKwkJb3M9LXJ0dQorCQk7OworCWYzMFswMV0tZnVqaXRzdSB8IGY3MDAtZnVqaXRzdSkKKwkJ
b3M9LXV4cHYKKwkJOzsKKwkqLXJvbTY4aykKKwkJb3M9LWNvZmYKKwkJOzsKKwkqLSpidWcpCisJ
CW9zPS1jb2ZmCisJCTs7CisJKi1hcHBsZSkKKwkJb3M9LW1hY29zCisJCTs7CisJKi1hdGFyaSop
CisJCW9zPS1taW50CisJCTs7CisJKikKKwkJb3M9LW5vbmUKKwkJOzsKK2VzYWMKK2ZpCisKKyMg
SGVyZSB3ZSBoYW5kbGUgdGhlIGNhc2Ugd2hlcmUgd2Uga25vdyB0aGUgb3MsIGFuZCB0aGUgQ1BV
IHR5cGUsIGJ1dCBub3QgdGhlCisjIG1hbnVmYWN0dXJlci4gIFdlIHBpY2sgdGhlIGxvZ2ljYWwg
bWFudWZhY3R1cmVyLgordmVuZG9yPXVua25vd24KK2Nhc2UgJGJhc2ljX21hY2hpbmUgaW4KKwkq
LXVua25vd24pCisJCWNhc2UgJG9zIGluCisJCQktcmlzY2l4KikKKwkJCQl2ZW5kb3I9YWNvcm4K
KwkJCQk7OworCQkJLXN1bm9zKikKKwkJCQl2ZW5kb3I9c3VuCisJCQkJOzsKKwkJCS1jbmsqfC1h
aXgqKQorCQkJCXZlbmRvcj1pYm0KKwkJCQk7OworCQkJLWJlb3MqKQorCQkJCXZlbmRvcj1iZQor
CQkJCTs7CisJCQktaHB1eCopCisJCQkJdmVuZG9yPWhwCisJCQkJOzsKKwkJCS1tcGVpeCopCisJ
CQkJdmVuZG9yPWhwCisJCQkJOzsKKwkJCS1oaXV4KikKKwkJCQl2ZW5kb3I9aGl0YWNoaQorCQkJ
CTs7CisJCQktdW5vcyopCisJCQkJdmVuZG9yPWNyZHMKKwkJCQk7OworCQkJLWRndXgqKQorCQkJ
CXZlbmRvcj1kZworCQkJCTs7CisJCQktbHVuYSopCisJCQkJdmVuZG9yPW9tcm9uCisJCQkJOzsK
KwkJCS1nZW5peCopCisJCQkJdmVuZG9yPW5zCisJCQkJOzsKKwkJCS1tdnMqIHwgLW9wZW5lZCop
CisJCQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQktb3M0MDAqKQorCQkJCXZlbmRvcj1pYm0KKwkJ
CQk7OworCQkJLXB0eCopCisJCQkJdmVuZG9yPXNlcXVlbnQKKwkJCQk7OworCQkJLXRwZiopCisJ
CQkJdmVuZG9yPWlibQorCQkJCTs7CisJCQktdnhzaW0qIHwgLXZ4d29ya3MqIHwgLXdpbmRpc3Mq
KQorCQkJCXZlbmRvcj13cnMKKwkJCQk7OworCQkJLWF1eCopCisJCQkJdmVuZG9yPWFwcGxlCisJ
CQkJOzsKKwkJCS1obXMqKQorCQkJCXZlbmRvcj1oaXRhY2hpCisJCQkJOzsKKwkJCS1tcHcqIHwg
LW1hY29zKikKKwkJCQl2ZW5kb3I9YXBwbGUKKwkJCQk7OworCQkJLSptaW50IHwgLW1pbnRbMC05
XSogfCAtKk1pTlQgfCAtTWlOVFswLTldKikKKwkJCQl2ZW5kb3I9YXRhcmkKKwkJCQk7OworCQkJ
LXZvcyopCisJCQkJdmVuZG9yPXN0cmF0dXMKKwkJCQk7OworCQllc2FjCisJCWJhc2ljX21hY2hp
bmU9YGVjaG8gJGJhc2ljX21hY2hpbmUgfCBzZWQgInMvdW5rbm93bi8kdmVuZG9yLyJgCisJCTs7
Citlc2FjCisKK2VjaG8gJGJhc2ljX21hY2hpbmUkb3MKK2V4aXQKKworIyBMb2NhbCB2YXJpYWJs
ZXM6CisjIGV2YWw6IChhZGQtaG9vayAnd3JpdGUtZmlsZS1ob29rcyAndGltZS1zdGFtcCkKKyMg
dGltZS1zdGFtcC1zdGFydDogInRpbWVzdGFtcD0nIgorIyB0aW1lLXN0YW1wLWZvcm1hdDogIiU6
eS0lMDJtLSUwMmQiCisjIHRpbWUtc3RhbXAtZW5kOiAiJyIKKyMgRW5kOgpkaWZmIC1yIDQwODZl
NDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvY29uZmlndXJlCi0tLSAvZGV2L251bGwJVGh1
IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL2NvbmZpZ3VyZQlUdWUgSmFu
IDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAsMCArMSwxMDE4MSBAQAorIyEgL2Jpbi9zaAor
IyBHdWVzcyB2YWx1ZXMgZm9yIHN5c3RlbS1kZXBlbmRlbnQgdmFyaWFibGVzIGFuZCBjcmVhdGUg
TWFrZWZpbGVzLgorIyBHZW5lcmF0ZWQgYnkgR05VIEF1dG9jb25mIDIuNjggZm9yIFhlbiBIeXBl
cnZpc29yIDQuMi4KKyMKKyMgUmVwb3J0IGJ1Z3MgdG8gPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tPi4KKyMKKyMKKyMgQ29weXJpZ2h0IChDKSAxOTkyLCAxOTkzLCAxOTk0LCAxOTk1LCAx
OTk2LCAxOTk4LCAxOTk5LCAyMDAwLCAyMDAxLAorIyAyMDAyLCAyMDAzLCAyMDA0LCAyMDA1LCAy
MDA2LCAyMDA3LCAyMDA4LCAyMDA5LCAyMDEwIEZyZWUgU29mdHdhcmUKKyMgRm91bmRhdGlvbiwg
SW5jLgorIworIworIyBUaGlzIGNvbmZpZ3VyZSBzY3JpcHQgaXMgZnJlZSBzb2Z0d2FyZTsgdGhl
IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbgorIyBnaXZlcyB1bmxpbWl0ZWQgcGVybWlzc2lvbiB0
byBjb3B5LCBkaXN0cmlidXRlIGFuZCBtb2RpZnkgaXQuCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0t
LSAjIworIyMgTTRzaCBJbml0aWFsaXphdGlvbi4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0t
ICMjCisKKyMgQmUgbW9yZSBCb3VybmUgY29tcGF0aWJsZQorRFVBTENBU0U9MTsgZXhwb3J0IERV
QUxDQVNFICMgZm9yIE1LUyBzaAoraWYgdGVzdCAtbiAiJHtaU0hfVkVSU0lPTitzZXR9IiAmJiAo
ZW11bGF0ZSBzaCkgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxM
Q01EPToKKyAgIyBQcmUtNC4yIHZlcnNpb25zIG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiAk
ezErIiRAIn0sIHdoaWNoCisgICMgaXMgY29udHJhcnkgdG8gb3VyIHVzYWdlLiAgRGlzYWJsZSB0
aGlzIGZlYXR1cmUuCisgIGFsaWFzIC1nICckezErIiRAIn0nPSciJEAiJworICBzZXRvcHQgTk9f
R0xPQl9TVUJTVAorZWxzZQorICBjYXNlIGAoc2V0IC1vKSAyPi9kZXYvbnVsbGAgaW4gIygKKyAg
KnBvc2l4KikgOgorICAgIHNldCAtbyBwb3NpeCA7OyAjKAorICAqKSA6CisgICAgIDs7Citlc2Fj
CitmaQorCisKK2FzX25sPScKKycKK2V4cG9ydCBhc19ubAorIyBQcmludGluZyBhIGxvbmcgc3Ry
aW5nIGNyYXNoZXMgU29sYXJpcyA3IC91c3IvYmluL3ByaW50Zi4KK2FzX2VjaG89J1xcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFwnCithc19lY2hvPSRhc19lY2hv
JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8KK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNo
byRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvCisjIFByZWZlciBhIGtzaCBzaGVsbCBi
dWlsdGluIG92ZXIgYW4gZXh0ZXJuYWwgcHJpbnRmIHByb2dyYW0gb24gU29sYXJpcywKKyMgYnV0
IHdpdGhvdXQgd2FzdGluZyBmb3JrcyBmb3IgYmFzaCBvciB6c2guCitpZiB0ZXN0IC16ICIkQkFT
SF9WRVJTSU9OJFpTSF9WRVJTSU9OIiBcCisgICAgJiYgKHRlc3QgIlhgcHJpbnQgLXIgLS0gJGFz
X2VjaG9gIiA9ICJYJGFzX2VjaG8iKSAyPi9kZXYvbnVsbDsgdGhlbgorICBhc19lY2hvPSdwcmlu
dCAtciAtLScKKyAgYXNfZWNob19uPSdwcmludCAtcm4gLS0nCitlbGlmICh0ZXN0ICJYYHByaW50
ZiAlcyAkYXNfZWNob2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX2Vj
aG89J3ByaW50ZiAlc1xuJworICBhc19lY2hvX249J3ByaW50ZiAlcycKK2Vsc2UKKyAgaWYgdGVz
dCAiWGAoL3Vzci91Y2IvZWNobyAtbiAtbiAkYXNfZWNobykgMj4vZGV2L251bGxgIiA9ICJYLW4g
JGFzX2VjaG8iOyB0aGVuCisgICAgYXNfZWNob19ib2R5PSdldmFsIC91c3IvdWNiL2VjaG8gLW4g
IiQxJGFzX25sIicKKyAgICBhc19lY2hvX249Jy91c3IvdWNiL2VjaG8gLW4nCisgIGVsc2UKKyAg
ICBhc19lY2hvX2JvZHk9J2V2YWwgZXhwciAiWCQxIiA6ICJYXFwoLipcXCkiJworICAgIGFzX2Vj
aG9fbl9ib2R5PSdldmFsCisgICAgICBhcmc9JDE7CisgICAgICBjYXNlICRhcmcgaW4gIygKKyAg
ICAgICoiJGFzX25sIiopCisJZXhwciAiWCRhcmciIDogIlhcXCguKlxcKSRhc19ubCI7CisJYXJn
PWBleHByICJYJGFyZyIgOiAiLiokYXNfbmxcXCguKlxcKSJgOzsKKyAgICAgIGVzYWM7CisgICAg
ICBleHByICJYJGFyZyIgOiAiWFxcKC4qXFwpIiB8IHRyIC1kICIkYXNfbmwiCisgICAgJworICAg
IGV4cG9ydCBhc19lY2hvX25fYm9keQorICAgIGFzX2VjaG9fbj0nc2ggLWMgJGFzX2VjaG9fbl9i
b2R5IGFzX2VjaG8nCisgIGZpCisgIGV4cG9ydCBhc19lY2hvX2JvZHkKKyAgYXNfZWNobz0nc2gg
LWMgJGFzX2VjaG9fYm9keSBhc19lY2hvJworZmkKKworIyBUaGUgdXNlciBpcyBhbHdheXMgcmln
aHQuCitpZiB0ZXN0ICIke1BBVEhfU0VQQVJBVE9SK3NldH0iICE9IHNldDsgdGhlbgorICBQQVRI
X1NFUEFSQVRPUj06CisgIChQQVRIPScvYmluOy9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikg
Pi9kZXYvbnVsbCAyPiYxICYmIHsKKyAgICAoUEFUSD0nL2JpbjovYmluJzsgRlBBVEg9JFBBVEg7
IHNoIC1jIDopID4vZGV2L251bGwgMj4mMSB8fAorICAgICAgUEFUSF9TRVBBUkFUT1I9JzsnCisg
IH0KK2ZpCisKKworIyBJRlMKKyMgV2UgbmVlZCBzcGFjZSwgdGFiIGFuZCBuZXcgbGluZSwgaW4g
cHJlY2lzZWx5IHRoYXQgb3JkZXIuICBRdW90aW5nIGlzCisjIHRoZXJlIHRvIHByZXZlbnQgZWRp
dG9ycyBmcm9tIGNvbXBsYWluaW5nIGFib3V0IHNwYWNlLXRhYi4KKyMgKElmIF9BU19QQVRIX1dB
TEsgd2VyZSBjYWxsZWQgd2l0aCBJRlMgdW5zZXQsIGl0IHdvdWxkIGRpc2FibGUgd29yZAorIyBz
cGxpdHRpbmcgYnkgc2V0dGluZyBJRlMgdG8gZW1wdHkgdmFsdWUuKQorSUZTPSIgIiIJJGFzX25s
IgorCisjIEZpbmQgd2hvIHdlIGFyZS4gIExvb2sgaW4gdGhlIHBhdGggaWYgd2UgY29udGFpbiBu
byBkaXJlY3Rvcnkgc2VwYXJhdG9yLgorYXNfbXlzZWxmPQorY2FzZSAkMCBpbiAjKCgKKyAgKltc
XC9dKiApIGFzX215c2VsZj0kMCA7OworICAqKSBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgdGVzdCAtciAiJGFzX2Rpci8kMCIg
JiYgYXNfbXlzZWxmPSRhc19kaXIvJDAgJiYgYnJlYWsKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCisgICAgIDs7Citlc2FjCisjIFdlIGRpZCBub3QgZmluZCBvdXJzZWx2ZXMsIG1vc3QgcHJv
YmFibHkgd2Ugd2VyZSBydW4gYXMgYHNoIENPTU1BTkQnCisjIGluIHdoaWNoIGNhc2Ugd2UgYXJl
IG5vdCB0byBiZSBmb3VuZCBpbiB0aGUgcGF0aC4KK2lmIHRlc3QgIngkYXNfbXlzZWxmIiA9IHg7
IHRoZW4KKyAgYXNfbXlzZWxmPSQwCitmaQoraWYgdGVzdCAhIC1mICIkYXNfbXlzZWxmIjsgdGhl
bgorICAkYXNfZWNobyAiJGFzX215c2VsZjogZXJyb3I6IGNhbm5vdCBmaW5kIG15c2VsZjsgcmVy
dW4gd2l0aCBhbiBhYnNvbHV0ZSBmaWxlIG5hbWUiID4mMgorICBleGl0IDEKK2ZpCisKKyMgVW5z
ZXQgdmFyaWFibGVzIHRoYXQgd2UgZG8gbm90IG5lZWQgYW5kIHdoaWNoIGNhdXNlIGJ1Z3MgKGUu
Zy4gaW4KKyMgcHJlLTMuMCBVV0lOIGtzaCkuICBCdXQgZG8gbm90IGNhdXNlIGJ1Z3MgaW4gYmFz
aCAyLjAxOyB0aGUgInx8IGV4aXQgMSIKKyMgc3VwcHJlc3NlcyBhbnkgIlNlZ21lbnRhdGlvbiBm
YXVsdCIgbWVzc2FnZSB0aGVyZS4gICcoKCcgY291bGQKKyMgdHJpZ2dlciBhIGJ1ZyBpbiBwZGtz
aCA1LjIuMTQuCitmb3IgYXNfdmFyIGluIEJBU0hfRU5WIEVOViBNQUlMIE1BSUxQQVRICitkbyBl
dmFsIHRlc3QgeFwkeyRhc192YXIrc2V0fSA9IHhzZXQgXAorICAmJiAoICh1bnNldCAkYXNfdmFy
KSB8fCBleGl0IDEpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCAkYXNfdmFyIHx8IDoKK2RvbmUK
K1BTMT0nJCAnCitQUzI9Jz4gJworUFM0PScrICcKKworIyBOTFMgbnVpc2FuY2VzLgorTENfQUxM
PUMKK2V4cG9ydCBMQ19BTEwKK0xBTkdVQUdFPUMKK2V4cG9ydCBMQU5HVUFHRQorCisjIENEUEFU
SC4KKyh1bnNldCBDRFBBVEgpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCBDRFBBVEgKKworaWYg
dGVzdCAieCRDT05GSUdfU0hFTEwiID0geDsgdGhlbgorICBhc19ib3VybmVfY29tcGF0aWJsZT0i
aWYgdGVzdCAtbiBcIlwke1pTSF9WRVJTSU9OK3NldH1cIiAmJiAoZW11bGF0ZSBzaCkgPi9kZXYv
bnVsbCAyPiYxOyB0aGVuIDoKKyAgZW11bGF0ZSBzaAorICBOVUxMQ01EPToKKyAgIyBQcmUtNC4y
IHZlcnNpb25zIG9mIFpzaCBkbyB3b3JkIHNwbGl0dGluZyBvbiBcJHsxK1wiXCRAXCJ9LCB3aGlj
aAorICAjIGlzIGNvbnRyYXJ5IHRvIG91ciB1c2FnZS4gIERpc2FibGUgdGhpcyBmZWF0dXJlLgor
ICBhbGlhcyAtZyAnXCR7MStcIlwkQFwifSc9J1wiXCRAXCInCisgIHNldG9wdCBOT19HTE9CX1NV
QlNUCitlbHNlCisgIGNhc2UgXGAoc2V0IC1vKSAyPi9kZXYvbnVsbFxgIGluICMoCisgICpwb3Np
eCopIDoKKyAgICBzZXQgLW8gcG9zaXggOzsgIygKKyAgKikgOgorICAgICA7OworZXNhYworZmkK
KyIKKyAgYXNfcmVxdWlyZWQ9ImFzX2ZuX3JldHVybiAoKSB7IChleGl0IFwkMSk7IH0KK2FzX2Zu
X3N1Y2Nlc3MgKCkgeyBhc19mbl9yZXR1cm4gMDsgfQorYXNfZm5fZmFpbHVyZSAoKSB7IGFzX2Zu
X3JldHVybiAxOyB9Cithc19mbl9yZXRfc3VjY2VzcyAoKSB7IHJldHVybiAwOyB9Cithc19mbl9y
ZXRfZmFpbHVyZSAoKSB7IHJldHVybiAxOyB9CisKK2V4aXRjb2RlPTAKK2FzX2ZuX3N1Y2Nlc3Mg
fHwgeyBleGl0Y29kZT0xOyBlY2hvIGFzX2ZuX3N1Y2Nlc3MgZmFpbGVkLjsgfQorYXNfZm5fZmFp
bHVyZSAmJiB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fZmFpbHVyZSBzdWNjZWVkZWQuOyB9Cith
c19mbl9yZXRfc3VjY2VzcyB8fCB7IGV4aXRjb2RlPTE7IGVjaG8gYXNfZm5fcmV0X3N1Y2Nlc3Mg
ZmFpbGVkLjsgfQorYXNfZm5fcmV0X2ZhaWx1cmUgJiYgeyBleGl0Y29kZT0xOyBlY2hvIGFzX2Zu
X3JldF9mYWlsdXJlIHN1Y2NlZWRlZC47IH0KK2lmICggc2V0IHg7IGFzX2ZuX3JldF9zdWNjZXNz
IHkgJiYgdGVzdCB4ID0gXCJcJDFcIiApOyB0aGVuIDoKKworZWxzZQorICBleGl0Y29kZT0xOyBl
Y2hvIHBvc2l0aW9uYWwgcGFyYW1ldGVycyB3ZXJlIG5vdCBzYXZlZC4KK2ZpCit0ZXN0IHhcJGV4
aXRjb2RlID0geDAgfHwgZXhpdCAxIgorICBhc19zdWdnZXN0ZWQ9IiAgYXNfbGluZW5vXzE9Ijth
c19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCRMSU5FTk87YXNfc3VnZ2VzdGVkPSRhc19zdWdnZXN0
ZWQiIGFzX2xpbmVub18xYT1cJExJTkVOTworICBhc19saW5lbm9fMj0iO2FzX3N1Z2dlc3RlZD0k
YXNfc3VnZ2VzdGVkJExJTkVOTzthc19zdWdnZXN0ZWQ9JGFzX3N1Z2dlc3RlZCIgYXNfbGluZW5v
XzJhPVwkTElORU5PCisgIGV2YWwgJ3Rlc3QgXCJ4XCRhc19saW5lbm9fMSdcJGFzX3J1bidcIiAh
PSBcInhcJGFzX2xpbmVub18yJ1wkYXNfcnVuJ1wiICYmCisgIHRlc3QgXCJ4XGBleHByIFwkYXNf
bGluZW5vXzEnXCRhc19ydW4nICsgMVxgXCIgPSBcInhcJGFzX2xpbmVub18yJ1wkYXNfcnVuJ1wi
JyB8fCBleGl0IDEKK3Rlc3QgXCQoKCAxICsgMSApKSA9IDIgfHwgZXhpdCAxIgorICBpZiAoZXZh
bCAiJGFzX3JlcXVpcmVkIikgMj4vZGV2L251bGw7IHRoZW4gOgorICBhc19oYXZlX3JlcXVpcmVk
PXllcworZWxzZQorICBhc19oYXZlX3JlcXVpcmVkPW5vCitmaQorICBpZiB0ZXN0IHgkYXNfaGF2
ZV9yZXF1aXJlZCA9IHh5ZXMgJiYgKGV2YWwgIiRhc19zdWdnZXN0ZWQiKSAyPi9kZXYvbnVsbDsg
dGhlbiA6CisKK2Vsc2UKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgor
YXNfZm91bmQ9ZmFsc2UKK2ZvciBhc19kaXIgaW4gL2JpbiRQQVRIX1NFUEFSQVRPUi91c3IvYmlu
JFBBVEhfU0VQQVJBVE9SJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgYXNfZm91bmQ9OgorICBjYXNlICRhc19kaXIgaW4gIygK
KwkgLyopCisJICAgZm9yIGFzX2Jhc2UgaW4gc2ggYmFzaCBrc2ggc2g1OyBkbworCSAgICAgIyBU
cnkgb25seSBzaGVsbHMgdGhhdCBleGlzdCwgdG8gc2F2ZSBzZXZlcmFsIGZvcmtzLgorCSAgICAg
YXNfc2hlbGw9JGFzX2Rpci8kYXNfYmFzZQorCSAgICAgaWYgeyB0ZXN0IC1mICIkYXNfc2hlbGwi
IHx8IHRlc3QgLWYgIiRhc19zaGVsbC5leGUiOyB9ICYmCisJCSAgICB7ICRhc19lY2hvICIkYXNf
Ym91cm5lX2NvbXBhdGlibGUiIiRhc19yZXF1aXJlZCIgfCBhc19ydW49YSAiJGFzX3NoZWxsIjsg
fSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIENPTkZJR19TSEVMTD0kYXNfc2hlbGwgYXNfaGF2ZV9y
ZXF1aXJlZD15ZXMKKwkJICAgaWYgeyAkYXNfZWNobyAiJGFzX2JvdXJuZV9jb21wYXRpYmxlIiIk
YXNfc3VnZ2VzdGVkIiB8IGFzX3J1bj1hICIkYXNfc2hlbGwiOyB9IDI+L2Rldi9udWxsOyB0aGVu
IDoKKyAgYnJlYWsgMgorZmkKK2ZpCisJICAgZG9uZTs7CisgICAgICAgZXNhYworICBhc19mb3Vu
ZD1mYWxzZQorZG9uZQorJGFzX2ZvdW5kIHx8IHsgaWYgeyB0ZXN0IC1mICIkU0hFTEwiIHx8IHRl
c3QgLWYgIiRTSEVMTC5leGUiOyB9ICYmCisJICAgICAgeyAkYXNfZWNobyAiJGFzX2JvdXJuZV9j
b21wYXRpYmxlIiIkYXNfcmVxdWlyZWQiIHwgYXNfcnVuPWEgIiRTSEVMTCI7IH0gMj4vZGV2L251
bGw7IHRoZW4gOgorICBDT05GSUdfU0hFTEw9JFNIRUxMIGFzX2hhdmVfcmVxdWlyZWQ9eWVzCitm
aTsgfQorSUZTPSRhc19zYXZlX0lGUworCisKKyAgICAgIGlmIHRlc3QgIngkQ09ORklHX1NIRUxM
IiAhPSB4OyB0aGVuIDoKKyAgIyBXZSBjYW5ub3QgeWV0IGFzc3VtZSBhIGRlY2VudCBzaGVsbCwg
c28gd2UgaGF2ZSB0byBwcm92aWRlIGEKKwkjIG5ldXRyYWxpemF0aW9uIHZhbHVlIGZvciBzaGVs
bHMgd2l0aG91dCB1bnNldDsgYW5kIHRoaXMgYWxzbworCSMgd29ya3MgYXJvdW5kIHNoZWxscyB0
aGF0IGNhbm5vdCB1bnNldCBub25leGlzdGVudCB2YXJpYWJsZXMuCisJIyBQcmVzZXJ2ZSAtdiBh
bmQgLXggdG8gdGhlIHJlcGxhY2VtZW50IHNoZWxsLgorCUJBU0hfRU5WPS9kZXYvbnVsbAorCUVO
Vj0vZGV2L251bGwKKwkodW5zZXQgQkFTSF9FTlYpID4vZGV2L251bGwgMj4mMSAmJiB1bnNldCBC
QVNIX0VOViBFTlYKKwlleHBvcnQgQ09ORklHX1NIRUxMCisJY2FzZSAkLSBpbiAjICgoKCgKKwkg
ICp2KngqIHwgKngqdiogKSBhc19vcHRzPS12eCA7OworCSAgKnYqICkgYXNfb3B0cz0tdiA7Owor
CSAgKngqICkgYXNfb3B0cz0teCA7OworCSAgKiApIGFzX29wdHM9IDs7CisJZXNhYworCWV4ZWMg
IiRDT05GSUdfU0hFTEwiICRhc19vcHRzICIkYXNfbXlzZWxmIiAkezErIiRAIn0KK2ZpCisKKyAg
ICBpZiB0ZXN0IHgkYXNfaGF2ZV9yZXF1aXJlZCA9IHhubzsgdGhlbiA6CisgICRhc19lY2hvICIk
MDogVGhpcyBzY3JpcHQgcmVxdWlyZXMgYSBzaGVsbCBtb3JlIG1vZGVybiB0aGFuIGFsbCIKKyAg
JGFzX2VjaG8gIiQwOiB0aGUgc2hlbGxzIHRoYXQgSSBmb3VuZCBvbiB5b3VyIHN5c3RlbS4iCisg
IGlmIHRlc3QgeCR7WlNIX1ZFUlNJT04rc2V0fSA9IHhzZXQgOyB0aGVuCisgICAgJGFzX2VjaG8g
IiQwOiBJbiBwYXJ0aWN1bGFyLCB6c2ggJFpTSF9WRVJTSU9OIGhhcyBidWdzIGFuZCBzaG91bGQi
CisgICAgJGFzX2VjaG8gIiQwOiBiZSB1cGdyYWRlZCB0byB6c2ggNC4zLjQgb3IgbGF0ZXIuIgor
ICBlbHNlCisgICAgJGFzX2VjaG8gIiQwOiBQbGVhc2UgdGVsbCBidWctYXV0b2NvbmZAZ251Lm9y
ZyBhbmQKKyQwOiB4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbSBhYm91dCB5b3VyIHN5c3Rl
bSwKKyQwOiBpbmNsdWRpbmcgYW55IGVycm9yIHBvc3NpYmx5IG91dHB1dCBiZWZvcmUgdGhpcwor
JDA6IG1lc3NhZ2UuIFRoZW4gaW5zdGFsbCBhIG1vZGVybiBzaGVsbCwgb3IgbWFudWFsbHkgcnVu
CiskMDogdGhlIHNjcmlwdCB1bmRlciBzdWNoIGEgc2hlbGwgaWYgeW91IGRvIGhhdmUgb25lLiIK
KyAgZmkKKyAgZXhpdCAxCitmaQorZmkKK2ZpCitTSEVMTD0ke0NPTkZJR19TSEVMTC0vYmluL3No
fQorZXhwb3J0IFNIRUxMCisjIFVuc2V0IG1vcmUgdmFyaWFibGVzIGtub3duIHRvIGludGVyZmVy
ZSB3aXRoIGJlaGF2aW9yIG9mIGNvbW1vbiB0b29scy4KK0NMSUNPTE9SX0ZPUkNFPSBHUkVQX09Q
VElPTlM9Cit1bnNldCBDTElDT0xPUl9GT1JDRSBHUkVQX09QVElPTlMKKworIyMgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tICMjCisjIyBNNHNoIFNoZWxsIEZ1bmN0aW9ucy4gIyMKKyMjIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAjIworIyBhc19mbl91bnNldCBWQVIKKyMgLS0tLS0tLS0tLS0tLS0tCisj
IFBvcnRhYmx5IHVuc2V0IFZBUi4KK2FzX2ZuX3Vuc2V0ICgpCit7CisgIHsgZXZhbCAkMT07IHVu
c2V0ICQxO30KK30KK2FzX3Vuc2V0PWFzX2ZuX3Vuc2V0CisKKyMgYXNfZm5fc2V0X3N0YXR1cyBT
VEFUVVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgU2V0ICQ/IHRvIFNUQVRVUywgd2l0
aG91dCBmb3JraW5nLgorYXNfZm5fc2V0X3N0YXR1cyAoKQoreworICByZXR1cm4gJDEKK30gIyBh
c19mbl9zZXRfc3RhdHVzCisKKyMgYXNfZm5fZXhpdCBTVEFUVVMKKyMgLS0tLS0tLS0tLS0tLS0t
LS0KKyMgRXhpdCB0aGUgc2hlbGwgd2l0aCBTVEFUVVMsIGV2ZW4gaW4gYSAidHJhcCAwIiBvciAi
c2V0IC1lIiBjb250ZXh0LgorYXNfZm5fZXhpdCAoKQoreworICBzZXQgK2UKKyAgYXNfZm5fc2V0
X3N0YXR1cyAkMQorICBleGl0ICQxCit9ICMgYXNfZm5fZXhpdAorCisjIGFzX2ZuX21rZGlyX3AK
KyMgLS0tLS0tLS0tLS0tLQorIyBDcmVhdGUgIiRhc19kaXIiIGFzIGEgZGlyZWN0b3J5LCBpbmNs
dWRpbmcgcGFyZW50cyBpZiBuZWNlc3NhcnkuCithc19mbl9ta2Rpcl9wICgpCit7CisKKyAgY2Fz
ZSAkYXNfZGlyIGluICMoCisgIC0qKSBhc19kaXI9Li8kYXNfZGlyOzsKKyAgZXNhYworICB0ZXN0
IC1kICIkYXNfZGlyIiB8fCBldmFsICRhc19ta2Rpcl9wIHx8IHsKKyAgICBhc19kaXJzPQorICAg
IHdoaWxlIDo7IGRvCisgICAgICBjYXNlICRhc19kaXIgaW4gIygKKyAgICAgICpcJyopIGFzX3Fk
aXI9YCRhc19lY2hvICIkYXNfZGlyIiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYDs7ICMnKAor
ICAgICAgKikgYXNfcWRpcj0kYXNfZGlyOzsKKyAgICAgIGVzYWMKKyAgICAgIGFzX2RpcnM9Iick
YXNfcWRpcicgJGFzX2RpcnMiCisgICAgICBhc19kaXI9YCRhc19kaXJuYW1lIC0tICIkYXNfZGly
IiB8fAorJGFzX2V4cHIgWCIkYXNfZGlyIiA6ICdYXCguKlteL11cKS8vKlteL11bXi9dKi8qJCcg
XHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC8vXClbXi9dJyBcfCBcCisJIFgiJGFzX2RpciIgOiAn
WFwoLy9cKSQnIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvXCknIFx8IC4gMj4vZGV2L251bGwg
fHwKKyRhc19lY2hvIFgiJGFzX2RpciIgfAorICAgIHNlZCAnL15YXCguKlteL11cKVwvXC8qW14v
XVteL10qXC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXC9cKVte
L10uKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcKFwvXC9cKSQveworCSAg
ICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wpLioveworCSAgICBzLy9cMS8KKwkg
ICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisgICAgICB0ZXN0IC1kICIkYXNfZGlyIiAmJiBi
cmVhaworICAgIGRvbmUKKyAgICB0ZXN0IC16ICIkYXNfZGlycyIgfHwgZXZhbCAibWtkaXIgJGFz
X2RpcnMiCisgIH0gfHwgdGVzdCAtZCAiJGFzX2RpciIgfHwgYXNfZm5fZXJyb3IgJD8gImNhbm5v
dCBjcmVhdGUgZGlyZWN0b3J5ICRhc19kaXIiCisKKworfSAjIGFzX2ZuX21rZGlyX3AKKyMgYXNf
Zm5fYXBwZW5kIFZBUiBWQUxVRQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIEFwcGVuZCB0
aGUgdGV4dCBpbiBWQUxVRSB0byB0aGUgZW5kIG9mIHRoZSBkZWZpbml0aW9uIGNvbnRhaW5lZCBp
biBWQVIuIFRha2UKKyMgYWR2YW50YWdlIG9mIGFueSBzaGVsbCBvcHRpbWl6YXRpb25zIHRoYXQg
YWxsb3cgYW1vcnRpemVkIGxpbmVhciBncm93dGggb3ZlcgorIyByZXBlYXRlZCBhcHBlbmRzLCBp
bnN0ZWFkIG9mIHRoZSB0eXBpY2FsIHF1YWRyYXRpYyBncm93dGggcHJlc2VudCBpbiBuYWl2ZQor
IyBpbXBsZW1lbnRhdGlvbnMuCitpZiAoZXZhbCAiYXNfdmFyPTE7IGFzX3Zhcis9MjsgdGVzdCB4
XCRhc192YXIgPSB4MTIiKSAyPi9kZXYvbnVsbDsgdGhlbiA6CisgIGV2YWwgJ2FzX2ZuX2FwcGVu
ZCAoKQorICB7CisgICAgZXZhbCAkMSs9XCQyCisgIH0nCitlbHNlCisgIGFzX2ZuX2FwcGVuZCAo
KQorICB7CisgICAgZXZhbCAkMT1cJCQxXCQyCisgIH0KK2ZpICMgYXNfZm5fYXBwZW5kCisKKyMg
YXNfZm5fYXJpdGggQVJHLi4uCisjIC0tLS0tLS0tLS0tLS0tLS0tLQorIyBQZXJmb3JtIGFyaXRo
bWV0aWMgZXZhbHVhdGlvbiBvbiB0aGUgQVJHcywgYW5kIHN0b3JlIHRoZSByZXN1bHQgaW4gdGhl
CisjIGdsb2JhbCAkYXNfdmFsLiBUYWtlIGFkdmFudGFnZSBvZiBzaGVsbHMgdGhhdCBjYW4gYXZv
aWQgZm9ya3MuIFRoZSBhcmd1bWVudHMKKyMgbXVzdCBiZSBwb3J0YWJsZSBhY3Jvc3MgJCgoKSkg
YW5kIGV4cHIuCitpZiAoZXZhbCAidGVzdCBcJCgoIDEgKyAxICkpID0gMiIpIDI+L2Rldi9udWxs
OyB0aGVuIDoKKyAgZXZhbCAnYXNfZm5fYXJpdGggKCkKKyAgeworICAgIGFzX3ZhbD0kKCggJCog
KSkKKyAgfScKK2Vsc2UKKyAgYXNfZm5fYXJpdGggKCkKKyAgeworICAgIGFzX3ZhbD1gZXhwciAi
JEAiIHx8IHRlc3QgJD8gLWVxIDFgCisgIH0KK2ZpICMgYXNfZm5fYXJpdGgKKworCisjIGFzX2Zu
X2Vycm9yIFNUQVRVUyBFUlJPUiBbTElORU5PIExPR19GRF0KKyMgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBPdXRwdXQgImBiYXNlbmFtZSAkMGA6IGVycm9yOiBF
UlJPUiIgdG8gc3RkZXJyLiBJZiBMSU5FTk8gYW5kIExPR19GRCBhcmUKKyMgcHJvdmlkZWQsIGFs
c28gb3V0cHV0IHRoZSBlcnJvciB0byBMT0dfRkQsIHJlZmVyZW5jaW5nIExJTkVOTy4gVGhlbiBl
eGl0IHRoZQorIyBzY3JpcHQgd2l0aCBTVEFUVVMsIHVzaW5nIDEgaWYgdGhhdCB3YXMgMC4KK2Fz
X2ZuX2Vycm9yICgpCit7CisgIGFzX3N0YXR1cz0kMTsgdGVzdCAkYXNfc3RhdHVzIC1lcSAwICYm
IGFzX3N0YXR1cz0xCisgIGlmIHRlc3QgIiQ0IjsgdGhlbgorICAgIGFzX2xpbmVubz0ke2FzX2xp
bmVuby0iJDMifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3Rh
Y2sKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogJDIi
ID4mJDQKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6ICQyIiA+JjIKKyAgYXNfZm5f
ZXhpdCAkYXNfc3RhdHVzCit9ICMgYXNfZm5fZXJyb3IKKworaWYgZXhwciBhIDogJ1woYVwpJyA+
L2Rldi9udWxsIDI+JjEgJiYKKyAgIHRlc3QgIlhgZXhwciAwMDAwMSA6ICcuKlwoLi4uXCknYCIg
PSBYMDAxOyB0aGVuCisgIGFzX2V4cHI9ZXhwcgorZWxzZQorICBhc19leHByPWZhbHNlCitmaQor
CitpZiAoYmFzZW5hbWUgLS0gLykgPi9kZXYvbnVsbCAyPiYxICYmIHRlc3QgIlhgYmFzZW5hbWUg
LS0gLyAyPiYxYCIgPSAiWC8iOyB0aGVuCisgIGFzX2Jhc2VuYW1lPWJhc2VuYW1lCitlbHNlCisg
IGFzX2Jhc2VuYW1lPWZhbHNlCitmaQorCitpZiAoYXNfZGlyPWBkaXJuYW1lIC0tIC9gICYmIHRl
c3QgIlgkYXNfZGlyIiA9IFgvKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4KKyAgYXNfZGlybmFtZT1k
aXJuYW1lCitlbHNlCisgIGFzX2Rpcm5hbWU9ZmFsc2UKK2ZpCisKK2FzX21lPWAkYXNfYmFzZW5h
bWUgLS0gIiQwIiB8fAorJGFzX2V4cHIgWC8iJDAiIDogJy4qL1woW14vXVteL10qXCkvKiQnIFx8
IFwKKwkgWCIkMCIgOiAnWFwoLy9cKSQnIFx8IFwKKwkgWCIkMCIgOiAnWFwoL1wpJyBcfCAuIDI+
L2Rldi9udWxsIHx8CiskYXNfZWNobyBYLyIkMCIgfAorICAgIHNlZCAnL14uKlwvXChbXi9dW14v
XSpcKVwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXC9cKSQv
eworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXC9cKFwvXCkuKi97CisJICAgIHMv
L1wxLworCSAgICBxCisJICB9CisJICBzLy4qLy4vOyBxJ2AKKworIyBBdm9pZCBkZXBlbmRpbmcg
dXBvbiBDaGFyYWN0ZXIgUmFuZ2VzLgorYXNfY3JfbGV0dGVycz0nYWJjZGVmZ2hpamtsbW5vcHFy
c3R1dnd4eXonCithc19jcl9MRVRURVJTPSdBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWicKK2Fz
X2NyX0xldHRlcnM9JGFzX2NyX2xldHRlcnMkYXNfY3JfTEVUVEVSUworYXNfY3JfZGlnaXRzPScw
MTIzNDU2Nzg5JworYXNfY3JfYWxudW09JGFzX2NyX0xldHRlcnMkYXNfY3JfZGlnaXRzCisKKwor
ICBhc19saW5lbm9fMT0kTElORU5PIGFzX2xpbmVub18xYT0kTElORU5PCisgIGFzX2xpbmVub18y
PSRMSU5FTk8gYXNfbGluZW5vXzJhPSRMSU5FTk8KKyAgZXZhbCAndGVzdCAieCRhc19saW5lbm9f
MSckYXNfcnVuJyIgIT0gIngkYXNfbGluZW5vXzInJGFzX3J1biciICYmCisgIHRlc3QgInhgZXhw
ciAkYXNfbGluZW5vXzEnJGFzX3J1bicgKyAxYCIgPSAieCRhc19saW5lbm9fMickYXNfcnVuJyIn
IHx8IHsKKyAgIyBCbGFtZSBMZWUgRS4gTWNNYWhvbiAoMTkzMS0xOTg5KSBmb3Igc2VkJ3Mgc3lu
dGF4LiAgOi0pCisgIHNlZCAtbiAnCisgICAgcAorICAgIC9bJF1MSU5FTk8vPQorICAnIDwkYXNf
bXlzZWxmIHwKKyAgICBzZWQgJworICAgICAgcy9bJF1MSU5FTk8uKi8mLS8KKyAgICAgIHQgbGlu
ZW5vCisgICAgICBiCisgICAgICA6bGluZW5vCisgICAgICBOCisgICAgICA6bG9vcAorICAgICAg
cy9bJF1MSU5FTk9cKFteJyRhc19jcl9hbG51bSdfXS4qXG5cKVwoLipcKS9cMlwxXDIvCisgICAg
ICB0IGxvb3AKKyAgICAgIHMvLVxuLiovLworICAgICcgPiRhc19tZS5saW5lbm8gJiYKKyAgY2ht
b2QgK3ggIiRhc19tZS5saW5lbm8iIHx8CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiBlcnJvcjog
Y2Fubm90IGNyZWF0ZSAkYXNfbWUubGluZW5vOyByZXJ1biB3aXRoIGEgUE9TSVggc2hlbGwiID4m
MjsgYXNfZm5fZXhpdCAxOyB9CisKKyAgIyBEb24ndCB0cnkgdG8gZXhlYyBhcyBpdCBjaGFuZ2Vz
ICRbMF0sIGNhdXNpbmcgYWxsIHNvcnQgb2YgcHJvYmxlbXMKKyAgIyAodGhlIGRpcm5hbWUgb2Yg
JFswXSBpcyBub3QgdGhlIHBsYWNlIHdoZXJlIHdlIG1pZ2h0IGZpbmQgdGhlCisgICMgb3JpZ2lu
YWwgYW5kIHNvIG9uLiAgQXV0b2NvbmYgaXMgZXNwZWNpYWxseSBzZW5zaXRpdmUgdG8gdGhpcyku
CisgIC4gIi4vJGFzX21lLmxpbmVubyIKKyAgIyBFeGl0IHN0YXR1cyBpcyB0aGF0IG9mIHRoZSBs
YXN0IGNvbW1hbmQuCisgIGV4aXQKK30KKworRUNIT19DPSBFQ0hPX049IEVDSE9fVD0KK2Nhc2Ug
YGVjaG8gLW4geGAgaW4gIygoKCgoCistbiopCisgIGNhc2UgYGVjaG8gJ3h5XGMnYCBpbgorICAq
YyopIEVDSE9fVD0nCSc7OwkjIEVDSE9fVCBpcyBzaW5nbGUgdGFiIGNoYXJhY3Rlci4KKyAgeHkp
ICBFQ0hPX0M9J1xjJzs7CisgICopICAgZWNobyBgZWNobyBrc2g4OCBidWcgb24gQUlYIDYuMWAg
PiAvZGV2L251bGwKKyAgICAgICBFQ0hPX1Q9JwknOzsKKyAgZXNhYzs7CisqKQorICBFQ0hPX049
Jy1uJzs7Citlc2FjCisKK3JtIC1mIGNvbmYkJCBjb25mJCQuZXhlIGNvbmYkJC5maWxlCitpZiB0
ZXN0IC1kIGNvbmYkJC5kaXI7IHRoZW4KKyAgcm0gLWYgY29uZiQkLmRpci9jb25mJCQuZmlsZQor
ZWxzZQorICBybSAtZiBjb25mJCQuZGlyCisgIG1rZGlyIGNvbmYkJC5kaXIgMj4vZGV2L251bGwK
K2ZpCitpZiAoZWNobyA+Y29uZiQkLmZpbGUpIDI+L2Rldi9udWxsOyB0aGVuCisgIGlmIGxuIC1z
IGNvbmYkJC5maWxlIGNvbmYkJCAyPi9kZXYvbnVsbDsgdGhlbgorICAgIGFzX2xuX3M9J2xuIC1z
JworICAgICMgLi4uIGJ1dCB0aGVyZSBhcmUgdHdvIGdvdGNoYXM6CisgICAgIyAxKSBPbiBNU1lT
LCBib3RoIGBsbiAtcyBmaWxlIGRpcicgYW5kIGBsbiBmaWxlIGRpcicgZmFpbC4KKyAgICAjIDIp
IERKR1BQIDwgMi4wNCBoYXMgbm8gc3ltbGlua3M7IGBsbiAtcycgY3JlYXRlcyBhIHdyYXBwZXIg
ZXhlY3V0YWJsZS4KKyAgICAjIEluIGJvdGggY2FzZXMsIHdlIGhhdmUgdG8gZGVmYXVsdCB0byBg
Y3AgLXAnLgorICAgIGxuIC1zIGNvbmYkJC5maWxlIGNvbmYkJC5kaXIgMj4vZGV2L251bGwgJiYg
dGVzdCAhIC1mIGNvbmYkJC5leGUgfHwKKyAgICAgIGFzX2xuX3M9J2NwIC1wJworICBlbGlmIGxu
IGNvbmYkJC5maWxlIGNvbmYkJCAyPi9kZXYvbnVsbDsgdGhlbgorICAgIGFzX2xuX3M9bG4KKyAg
ZWxzZQorICAgIGFzX2xuX3M9J2NwIC1wJworICBmaQorZWxzZQorICBhc19sbl9zPSdjcCAtcCcK
K2ZpCitybSAtZiBjb25mJCQgY29uZiQkLmV4ZSBjb25mJCQuZGlyL2NvbmYkJC5maWxlIGNvbmYk
JC5maWxlCitybWRpciBjb25mJCQuZGlyIDI+L2Rldi9udWxsCisKK2lmIG1rZGlyIC1wIC4gMj4v
ZGV2L251bGw7IHRoZW4KKyAgYXNfbWtkaXJfcD0nbWtkaXIgLXAgIiRhc19kaXIiJworZWxzZQor
ICB0ZXN0IC1kIC4vLXAgJiYgcm1kaXIgLi8tcAorICBhc19ta2Rpcl9wPWZhbHNlCitmaQorCitp
ZiB0ZXN0IC14IC8gPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgIGFzX3Rlc3RfeD0ndGVzdCAteCcK
K2Vsc2UKKyAgaWYgbHMgLWRMIC8gPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgICAgYXNfbHNfTF9v
cHRpb249TAorICBlbHNlCisgICAgYXNfbHNfTF9vcHRpb249CisgIGZpCisgIGFzX3Rlc3RfeD0n
CisgICAgZXZhbCBzaCAtYyAnXCcnCisgICAgICBpZiB0ZXN0IC1kICIkMSI7IHRoZW4KKwl0ZXN0
IC1kICIkMS8uIjsKKyAgICAgIGVsc2UKKwljYXNlICQxIGluICMoCisJLSopc2V0ICIuLyQxIjs7
CisJZXNhYzsKKwljYXNlIGBscyAtbGQnJGFzX2xzX0xfb3B0aW9uJyAiJDEiIDI+L2Rldi9udWxs
YCBpbiAjKCgKKwk/Pz9bc3hdKik6OzsqKWZhbHNlOztlc2FjO2ZpCisgICAgJ1wnJyBzaAorICAn
CitmaQorYXNfZXhlY3V0YWJsZV9wPSRhc190ZXN0X3gKKworIyBTZWQgZXhwcmVzc2lvbiB0byBt
YXAgYSBzdHJpbmcgb250byBhIHZhbGlkIENQUCBuYW1lLgorYXNfdHJfY3BwPSJldmFsIHNlZCAn
eSUqJGFzX2NyX2xldHRlcnMlUCRhc19jcl9MRVRURVJTJTtzJVteXyRhc19jcl9hbG51bV0lXyVn
JyIKKworIyBTZWQgZXhwcmVzc2lvbiB0byBtYXAgYSBzdHJpbmcgb250byBhIHZhbGlkIHZhcmlh
YmxlIG5hbWUuCithc190cl9zaD0iZXZhbCBzZWQgJ3klKislcHAlO3MlW15fJGFzX2NyX2FsbnVt
XSVfJWcnIgorCisKK3Rlc3QgLW4gIiRESkRJUiIgfHwgZXhlYyA3PCYwIDwvZGV2L251bGwKK2V4
ZWMgNj4mMQorCisjIE5hbWUgb2YgdGhlIGhvc3QuCisjIGhvc3RuYW1lIG9uIHNvbWUgc3lzdGVt
cyAoU1ZSMy4yLCBvbGQgR05VL0xpbnV4KSByZXR1cm5zIGEgYm9ndXMgZXhpdCBzdGF0dXMsCisj
IHNvIHVuYW1lIGdldHMgcnVuIHRvby4KK2FjX2hvc3RuYW1lPWAoaG9zdG5hbWUgfHwgdW5hbWUg
LW4pIDI+L2Rldi9udWxsIHwgc2VkIDFxYAorCisjCisjIEluaXRpYWxpemF0aW9ucy4KKyMKK2Fj
X2RlZmF1bHRfcHJlZml4PS91c3IvbG9jYWwKK2FjX2NsZWFuX2ZpbGVzPQorYWNfY29uZmlnX2xp
Ym9ial9kaXI9LgorTElCT0JKUz0KK2Nyb3NzX2NvbXBpbGluZz1ubworc3ViZGlycz0KK01GTEFH
Uz0KK01BS0VGTEFHUz0KKworIyBJZGVudGl0eSBvZiB0aGlzIHBhY2thZ2UuCitQQUNLQUdFX05B
TUU9J1hlbiBIeXBlcnZpc29yJworUEFDS0FHRV9UQVJOQU1FPSd4ZW4taHlwZXJ2aXNvcicKK1BB
Q0tBR0VfVkVSU0lPTj0nNC4yJworUEFDS0FHRV9TVFJJTkc9J1hlbiBIeXBlcnZpc29yIDQuMicK
K1BBQ0tBR0VfQlVHUkVQT1JUPSd4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbScKK1BBQ0tB
R0VfVVJMPScnCisKK2FjX3VuaXF1ZV9maWxlPSJsaWJ4bC9saWJ4bC5jIgorYWNfZGVmYXVsdF9w
cmVmaXg9L3VzcgorIyBGYWN0b3JpbmcgZGVmYXVsdCBoZWFkZXJzIGZvciBtb3N0IHRlc3RzLgor
YWNfaW5jbHVkZXNfZGVmYXVsdD0iXAorI2luY2x1ZGUgPHN0ZGlvLmg+CisjaWZkZWYgSEFWRV9T
WVNfVFlQRVNfSAorIyBpbmNsdWRlIDxzeXMvdHlwZXMuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVf
U1lTX1NUQVRfSAorIyBpbmNsdWRlIDxzeXMvc3RhdC5oPgorI2VuZGlmCisjaWZkZWYgU1REQ19I
RUFERVJTCisjIGluY2x1ZGUgPHN0ZGxpYi5oPgorIyBpbmNsdWRlIDxzdGRkZWYuaD4KKyNlbHNl
CisjIGlmZGVmIEhBVkVfU1RETElCX0gKKyMgIGluY2x1ZGUgPHN0ZGxpYi5oPgorIyBlbmRpZgor
I2VuZGlmCisjaWZkZWYgSEFWRV9TVFJJTkdfSAorIyBpZiAhZGVmaW5lZCBTVERDX0hFQURFUlMg
JiYgZGVmaW5lZCBIQVZFX01FTU9SWV9ICisjICBpbmNsdWRlIDxtZW1vcnkuaD4KKyMgZW5kaWYK
KyMgaW5jbHVkZSA8c3RyaW5nLmg+CisjZW5kaWYKKyNpZmRlZiBIQVZFX1NUUklOR1NfSAorIyBp
bmNsdWRlIDxzdHJpbmdzLmg+CisjZW5kaWYKKyNpZmRlZiBIQVZFX0lOVFRZUEVTX0gKKyMgaW5j
bHVkZSA8aW50dHlwZXMuaD4KKyNlbmRpZgorI2lmZGVmIEhBVkVfU1RESU5UX0gKKyMgaW5jbHVk
ZSA8c3RkaW50Lmg+CisjZW5kaWYKKyNpZmRlZiBIQVZFX1VOSVNURF9ICisjIGluY2x1ZGUgPHVu
aXN0ZC5oPgorI2VuZGlmIgorCithY19oZWFkZXJfbGlzdD0KK2FjX2Z1bmNfbGlzdD0KK2FjX3N1
YnN0X3ZhcnM9J0xUTElCT0JKUworUE9XX0xJQgorTElCT0JKUworQUxMT0NBCitsaWJpY29udgor
bGliZ2NyeXB0CitsaWJleHQyZnMKK3N5c3RlbV9haW8KK0xJQl9QQVRICitWTkNPTkZJRworSE9U
UExVRworVURFVklORk8KK1VERVZBRE0KK1BZVEhPTlBBVEgKK09DQU1MQlVJTEQKK09DQU1MRE9D
CitPQ0FNTE1LTElCCitPQ0FNTE1LVE9QCitPQ0FNTERFUAorT0NBTUwKK09DQU1MT1BURE9UT1BU
CitPQ0FNTENET1RPUFQKK09DQU1MQkVTVAorT0NBTUxPUFQKK09DQU1MTElCCitPQ0FNTFZFUlNJ
T04KK09DQU1MQworSU5TVEFMTF9EQVRBCitJTlNUQUxMX1NDUklQVAorSU5TVEFMTF9QUk9HUkFN
CitTRVRfTUFLRQorTE5fUworU0VECitYR0VUVEVYVAorQkFTSAorWE1MCitDVVJMCitGTEVYCitC
SVNPTgorSVAKK0JSQ1RMCitQRVJMCitQWVRIT04KK0FQUEVORF9MSUIKK0FQUEVORF9JTkNMVURF
UworUFJFUEVORF9MSUIKK1BSRVBFTkRfSU5DTFVERVMKK2RlYnVnCitsb21vdW50CittaW5pdGVy
bQorb2NhbWx0b29scworcHl0aG9udG9vbHMKK3hhcGkKK3Z0cG0KK21vbml0b3JzCitnaXRodHRw
Cit4c20KK2hvc3Rfb3MKK2hvc3RfdmVuZG9yCitob3N0X2NwdQoraG9zdAorYnVpbGRfb3MKK2J1
aWxkX3ZlbmRvcgorYnVpbGRfY3B1CitidWlsZAorRUdSRVAKK0dSRVAKK0NQUAorT0JKRVhUCitF
WEVFWFQKK2FjX2N0X0NDCitDUFBGTEFHUworTERGTEFHUworQ0ZMQUdTCitDQwordGFyZ2V0X2Fs
aWFzCitob3N0X2FsaWFzCitidWlsZF9hbGlhcworTElCUworRUNIT19UCitFQ0hPX04KK0VDSE9f
QworREVGUworbWFuZGlyCitsb2NhbGVkaXIKK2xpYmRpcgorcHNkaXIKK3BkZmRpcgorZHZpZGly
CitodG1sZGlyCitpbmZvZGlyCitkb2NkaXIKK29sZGluY2x1ZGVkaXIKK2luY2x1ZGVkaXIKK2xv
Y2Fsc3RhdGVkaXIKK3NoYXJlZHN0YXRlZGlyCitzeXNjb25mZGlyCitkYXRhZGlyCitkYXRhcm9v
dGRpcgorbGliZXhlY2Rpcgorc2JpbmRpcgorYmluZGlyCitwcm9ncmFtX3RyYW5zZm9ybV9uYW1l
CitwcmVmaXgKK2V4ZWNfcHJlZml4CitQQUNLQUdFX1VSTAorUEFDS0FHRV9CVUdSRVBPUlQKK1BB
Q0tBR0VfU1RSSU5HCitQQUNLQUdFX1ZFUlNJT04KK1BBQ0tBR0VfVEFSTkFNRQorUEFDS0FHRV9O
QU1FCitQQVRIX1NFUEFSQVRPUgorU0hFTEwnCithY19zdWJzdF9maWxlcz0nJworYWNfdXNlcl9v
cHRzPScKK2VuYWJsZV9vcHRpb25fY2hlY2tpbmcKK2VuYWJsZV94c20KK2VuYWJsZV9naXRodHRw
CitlbmFibGVfbW9uaXRvcnMKK2VuYWJsZV92dHBtCitlbmFibGVfeGFwaQorZW5hYmxlX3B5dGhv
bnRvb2xzCitlbmFibGVfb2NhbWx0b29scworZW5hYmxlX21pbml0ZXJtCitlbmFibGVfbG9tb3Vu
dAorZW5hYmxlX2RlYnVnCisnCisgICAgICBhY19wcmVjaW91c192YXJzPSdidWlsZF9hbGlhcwor
aG9zdF9hbGlhcwordGFyZ2V0X2FsaWFzCitDQworQ0ZMQUdTCitMREZMQUdTCitMSUJTCitDUFBG
TEFHUworQ1BQCitQUkVQRU5EX0lOQ0xVREVTCitQUkVQRU5EX0xJQgorQVBQRU5EX0lOQ0xVREVT
CitBUFBFTkRfTElCCitQWVRIT04KK1BFUkwKK0JSQ1RMCitJUAorQklTT04KK0ZMRVgKK0NVUkwK
K1hNTAorQkFTSAorWEdFVFRFWFQnCisKKworIyBJbml0aWFsaXplIHNvbWUgdmFyaWFibGVzIHNl
dCBieSBvcHRpb25zLgorYWNfaW5pdF9oZWxwPQorYWNfaW5pdF92ZXJzaW9uPWZhbHNlCithY191
bnJlY29nbml6ZWRfb3B0cz0KK2FjX3VucmVjb2duaXplZF9zZXA9CisjIFRoZSB2YXJpYWJsZXMg
aGF2ZSB0aGUgc2FtZSBuYW1lcyBhcyB0aGUgb3B0aW9ucywgd2l0aAorIyBkYXNoZXMgY2hhbmdl
ZCB0byB1bmRlcmxpbmVzLgorY2FjaGVfZmlsZT0vZGV2L251bGwKK2V4ZWNfcHJlZml4PU5PTkUK
K25vX2NyZWF0ZT0KK25vX3JlY3Vyc2lvbj0KK3ByZWZpeD1OT05FCitwcm9ncmFtX3ByZWZpeD1O
T05FCitwcm9ncmFtX3N1ZmZpeD1OT05FCitwcm9ncmFtX3RyYW5zZm9ybV9uYW1lPXMseCx4LAor
c2lsZW50PQorc2l0ZT0KK3NyY2Rpcj0KK3ZlcmJvc2U9Cit4X2luY2x1ZGVzPU5PTkUKK3hfbGli
cmFyaWVzPU5PTkUKKworIyBJbnN0YWxsYXRpb24gZGlyZWN0b3J5IG9wdGlvbnMuCisjIFRoZXNl
IGFyZSBsZWZ0IHVuZXhwYW5kZWQgc28gdXNlcnMgY2FuICJtYWtlIGluc3RhbGwgZXhlY19wcmVm
aXg9L2ZvbyIKKyMgYW5kIGFsbCB0aGUgdmFyaWFibGVzIHRoYXQgYXJlIHN1cHBvc2VkIHRvIGJl
IGJhc2VkIG9uIGV4ZWNfcHJlZml4CisjIGJ5IGRlZmF1bHQgd2lsbCBhY3R1YWxseSBjaGFuZ2Uu
CisjIFVzZSBicmFjZXMgaW5zdGVhZCBvZiBwYXJlbnMgYmVjYXVzZSBzaCwgcGVybCwgZXRjLiBh
bHNvIGFjY2VwdCB0aGVtLgorIyAoVGhlIGxpc3QgZm9sbG93cyB0aGUgc2FtZSBvcmRlciBhcyB0
aGUgR05VIENvZGluZyBTdGFuZGFyZHMuKQorYmluZGlyPScke2V4ZWNfcHJlZml4fS9iaW4nCitz
YmluZGlyPScke2V4ZWNfcHJlZml4fS9zYmluJworbGliZXhlY2Rpcj0nJHtleGVjX3ByZWZpeH0v
bGliZXhlYycKK2RhdGFyb290ZGlyPScke3ByZWZpeH0vc2hhcmUnCitkYXRhZGlyPScke2RhdGFy
b290ZGlyfScKK3N5c2NvbmZkaXI9JyR7cHJlZml4fS9ldGMnCitzaGFyZWRzdGF0ZWRpcj0nJHtw
cmVmaXh9L2NvbScKK2xvY2Fsc3RhdGVkaXI9JyR7cHJlZml4fS92YXInCitpbmNsdWRlZGlyPSck
e3ByZWZpeH0vaW5jbHVkZScKK29sZGluY2x1ZGVkaXI9Jy91c3IvaW5jbHVkZScKK2RvY2Rpcj0n
JHtkYXRhcm9vdGRpcn0vZG9jLyR7UEFDS0FHRV9UQVJOQU1FfScKK2luZm9kaXI9JyR7ZGF0YXJv
b3RkaXJ9L2luZm8nCitodG1sZGlyPScke2RvY2Rpcn0nCitkdmlkaXI9JyR7ZG9jZGlyfScKK3Bk
ZmRpcj0nJHtkb2NkaXJ9JworcHNkaXI9JyR7ZG9jZGlyfScKK2xpYmRpcj0nJHtleGVjX3ByZWZp
eH0vbGliJworbG9jYWxlZGlyPScke2RhdGFyb290ZGlyfS9sb2NhbGUnCittYW5kaXI9JyR7ZGF0
YXJvb3RkaXJ9L21hbicKKworYWNfcHJldj0KK2FjX2Rhc2hkYXNoPQorZm9yIGFjX29wdGlvbgor
ZG8KKyAgIyBJZiB0aGUgcHJldmlvdXMgb3B0aW9uIG5lZWRzIGFuIGFyZ3VtZW50LCBhc3NpZ24g
aXQuCisgIGlmIHRlc3QgLW4gIiRhY19wcmV2IjsgdGhlbgorICAgIGV2YWwgJGFjX3ByZXY9XCRh
Y19vcHRpb24KKyAgICBhY19wcmV2PQorICAgIGNvbnRpbnVlCisgIGZpCisKKyAgY2FzZSAkYWNf
b3B0aW9uIGluCisgICo9PyopIGFjX29wdGFyZz1gZXhwciAiWCRhY19vcHRpb24iIDogJ1tePV0q
PVwoLipcKSdgIDs7CisgICo9KSAgIGFjX29wdGFyZz0gOzsKKyAgKikgICAgYWNfb3B0YXJnPXll
cyA7OworICBlc2FjCisKKyAgIyBBY2NlcHQgdGhlIGltcG9ydGFudCBDeWdudXMgY29uZmlndXJl
IG9wdGlvbnMsIHNvIHdlIGNhbiBkaWFnbm9zZSB0eXBvcy4KKworICBjYXNlICRhY19kYXNoZGFz
aCRhY19vcHRpb24gaW4KKyAgLS0pCisgICAgYWNfZGFzaGRhc2g9eWVzIDs7CisKKyAgLWJpbmRp
ciB8IC0tYmluZGlyIHwgLS1iaW5kaSB8IC0tYmluZCB8IC0tYmluIHwgLS1iaSkKKyAgICBhY19w
cmV2PWJpbmRpciA7OworICAtYmluZGlyPSogfCAtLWJpbmRpcj0qIHwgLS1iaW5kaT0qIHwgLS1i
aW5kPSogfCAtLWJpbj0qIHwgLS1iaT0qKQorICAgIGJpbmRpcj0kYWNfb3B0YXJnIDs7CisKKyAg
LWJ1aWxkIHwgLS1idWlsZCB8IC0tYnVpbCB8IC0tYnVpIHwgLS1idSkKKyAgICBhY19wcmV2PWJ1
aWxkX2FsaWFzIDs7CisgIC1idWlsZD0qIHwgLS1idWlsZD0qIHwgLS1idWlsPSogfCAtLWJ1aT0q
IHwgLS1idT0qKQorICAgIGJ1aWxkX2FsaWFzPSRhY19vcHRhcmcgOzsKKworICAtY2FjaGUtZmls
ZSB8IC0tY2FjaGUtZmlsZSB8IC0tY2FjaGUtZmlsIHwgLS1jYWNoZS1maSBcCisgIHwgLS1jYWNo
ZS1mIHwgLS1jYWNoZS0gfCAtLWNhY2hlIHwgLS1jYWNoIHwgLS1jYWMgfCAtLWNhIHwgLS1jKQor
ICAgIGFjX3ByZXY9Y2FjaGVfZmlsZSA7OworICAtY2FjaGUtZmlsZT0qIHwgLS1jYWNoZS1maWxl
PSogfCAtLWNhY2hlLWZpbD0qIHwgLS1jYWNoZS1maT0qIFwKKyAgfCAtLWNhY2hlLWY9KiB8IC0t
Y2FjaGUtPSogfCAtLWNhY2hlPSogfCAtLWNhY2g9KiB8IC0tY2FjPSogfCAtLWNhPSogfCAtLWM9
KikKKyAgICBjYWNoZV9maWxlPSRhY19vcHRhcmcgOzsKKworICAtLWNvbmZpZy1jYWNoZSB8IC1D
KQorICAgIGNhY2hlX2ZpbGU9Y29uZmlnLmNhY2hlIDs7CisKKyAgLWRhdGFkaXIgfCAtLWRhdGFk
aXIgfCAtLWRhdGFkaSB8IC0tZGF0YWQpCisgICAgYWNfcHJldj1kYXRhZGlyIDs7CisgIC1kYXRh
ZGlyPSogfCAtLWRhdGFkaXI9KiB8IC0tZGF0YWRpPSogfCAtLWRhdGFkPSopCisgICAgZGF0YWRp
cj0kYWNfb3B0YXJnIDs7CisKKyAgLWRhdGFyb290ZGlyIHwgLS1kYXRhcm9vdGRpciB8IC0tZGF0
YXJvb3RkaSB8IC0tZGF0YXJvb3RkIHwgLS1kYXRhcm9vdCBcCisgIHwgLS1kYXRhcm9vIHwgLS1k
YXRhcm8gfCAtLWRhdGFyKQorICAgIGFjX3ByZXY9ZGF0YXJvb3RkaXIgOzsKKyAgLWRhdGFyb290
ZGlyPSogfCAtLWRhdGFyb290ZGlyPSogfCAtLWRhdGFyb290ZGk9KiB8IC0tZGF0YXJvb3RkPSog
XAorICB8IC0tZGF0YXJvb3Q9KiB8IC0tZGF0YXJvbz0qIHwgLS1kYXRhcm89KiB8IC0tZGF0YXI9
KikKKyAgICBkYXRhcm9vdGRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWRpc2FibGUtKiB8IC0tZGlz
YWJsZS0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4LSpkaXNhYmxl
LVwoLipcKSdgCisgICAgIyBSZWplY3QgbmFtZXMgdGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZh
cmlhYmxlIG5hbWVzLgorICAgIGV4cHIgIngkYWNfdXNlcm9wdCIgOiAiLipbXi0rLl8kYXNfY3Jf
YWxudW1dIiA+L2Rldi9udWxsICYmCisgICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCBmZWF0
dXJlIG5hbWU6ICRhY191c2Vyb3B0IgorICAgIGFjX3VzZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAor
ICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hvICIkYWNfdXNlcm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9n
J2AKKyAgICBjYXNlICRhY191c2VyX29wdHMgaW4KKyAgICAgICoiCisiZW5hYmxlXyRhY191c2Vy
b3B0IgorIiopIDs7CisgICAgICAqKSBhY191bnJlY29nbml6ZWRfb3B0cz0iJGFjX3VucmVjb2du
aXplZF9vcHRzJGFjX3VucmVjb2duaXplZF9zZXAtLWRpc2FibGUtJGFjX3VzZXJvcHRfb3JpZyIK
KwkgYWNfdW5yZWNvZ25pemVkX3NlcD0nLCAnOzsKKyAgICBlc2FjCisgICAgZXZhbCBlbmFibGVf
JGFjX3VzZXJvcHQ9bm8gOzsKKworICAtZG9jZGlyIHwgLS1kb2NkaXIgfCAtLWRvY2RpIHwgLS1k
b2MgfCAtLWRvKQorICAgIGFjX3ByZXY9ZG9jZGlyIDs7CisgIC1kb2NkaXI9KiB8IC0tZG9jZGly
PSogfCAtLWRvY2RpPSogfCAtLWRvYz0qIHwgLS1kbz0qKQorICAgIGRvY2Rpcj0kYWNfb3B0YXJn
IDs7CisKKyAgLWR2aWRpciB8IC0tZHZpZGlyIHwgLS1kdmlkaSB8IC0tZHZpZCB8IC0tZHZpIHwg
LS1kdikKKyAgICBhY19wcmV2PWR2aWRpciA7OworICAtZHZpZGlyPSogfCAtLWR2aWRpcj0qIHwg
LS1kdmlkaT0qIHwgLS1kdmlkPSogfCAtLWR2aT0qIHwgLS1kdj0qKQorICAgIGR2aWRpcj0kYWNf
b3B0YXJnIDs7CisKKyAgLWVuYWJsZS0qIHwgLS1lbmFibGUtKikKKyAgICBhY191c2Vyb3B0PWBl
eHByICJ4JGFjX29wdGlvbiIgOiAneC0qZW5hYmxlLVwoW149XSpcKSdgCisgICAgIyBSZWplY3Qg
bmFtZXMgdGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIg
IngkYWNfdXNlcm9wdCIgOiAiLipbXi0rLl8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisg
ICAgICBhc19mbl9lcnJvciAkPyAiaW52YWxpZCBmZWF0dXJlIG5hbWU6ICRhY191c2Vyb3B0Igor
ICAgIGFjX3VzZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hv
ICIkYWNfdXNlcm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29w
dHMgaW4KKyAgICAgICoiCisiZW5hYmxlXyRhY191c2Vyb3B0IgorIiopIDs7CisgICAgICAqKSBh
Y191bnJlY29nbml6ZWRfb3B0cz0iJGFjX3VucmVjb2duaXplZF9vcHRzJGFjX3VucmVjb2duaXpl
ZF9zZXAtLWVuYWJsZS0kYWNfdXNlcm9wdF9vcmlnIgorCSBhY191bnJlY29nbml6ZWRfc2VwPScs
ICc7OworICAgIGVzYWMKKyAgICBldmFsIGVuYWJsZV8kYWNfdXNlcm9wdD1cJGFjX29wdGFyZyA7
OworCisgIC1leGVjLXByZWZpeCB8IC0tZXhlY19wcmVmaXggfCAtLWV4ZWMtcHJlZml4IHwgLS1l
eGVjLXByZWZpIFwKKyAgfCAtLWV4ZWMtcHJlZiB8IC0tZXhlYy1wcmUgfCAtLWV4ZWMtcHIgfCAt
LWV4ZWMtcCB8IC0tZXhlYy0gXAorICB8IC0tZXhlYyB8IC0tZXhlIHwgLS1leCkKKyAgICBhY19w
cmV2PWV4ZWNfcHJlZml4IDs7CisgIC1leGVjLXByZWZpeD0qIHwgLS1leGVjX3ByZWZpeD0qIHwg
LS1leGVjLXByZWZpeD0qIHwgLS1leGVjLXByZWZpPSogXAorICB8IC0tZXhlYy1wcmVmPSogfCAt
LWV4ZWMtcHJlPSogfCAtLWV4ZWMtcHI9KiB8IC0tZXhlYy1wPSogfCAtLWV4ZWMtPSogXAorICB8
IC0tZXhlYz0qIHwgLS1leGU9KiB8IC0tZXg9KikKKyAgICBleGVjX3ByZWZpeD0kYWNfb3B0YXJn
IDs7CisKKyAgLWdhcyB8IC0tZ2FzIHwgLS1nYSB8IC0tZykKKyAgICAjIE9ic29sZXRlOyB1c2Ug
LS13aXRoLWdhcy4KKyAgICB3aXRoX2dhcz15ZXMgOzsKKworICAtaGVscCB8IC0taGVscCB8IC0t
aGVsIHwgLS1oZSB8IC1oKQorICAgIGFjX2luaXRfaGVscD1sb25nIDs7CisgIC1oZWxwPXIqIHwg
LS1oZWxwPXIqIHwgLS1oZWw9ciogfCAtLWhlPXIqIHwgLWhyKikKKyAgICBhY19pbml0X2hlbHA9
cmVjdXJzaXZlIDs7CisgIC1oZWxwPXMqIHwgLS1oZWxwPXMqIHwgLS1oZWw9cyogfCAtLWhlPXMq
IHwgLWhzKikKKyAgICBhY19pbml0X2hlbHA9c2hvcnQgOzsKKworICAtaG9zdCB8IC0taG9zdCB8
IC0taG9zIHwgLS1obykKKyAgICBhY19wcmV2PWhvc3RfYWxpYXMgOzsKKyAgLWhvc3Q9KiB8IC0t
aG9zdD0qIHwgLS1ob3M9KiB8IC0taG89KikKKyAgICBob3N0X2FsaWFzPSRhY19vcHRhcmcgOzsK
KworICAtaHRtbGRpciB8IC0taHRtbGRpciB8IC0taHRtbGRpIHwgLS1odG1sZCB8IC0taHRtbCB8
IC0taHRtIHwgLS1odCkKKyAgICBhY19wcmV2PWh0bWxkaXIgOzsKKyAgLWh0bWxkaXI9KiB8IC0t
aHRtbGRpcj0qIHwgLS1odG1sZGk9KiB8IC0taHRtbGQ9KiB8IC0taHRtbD0qIHwgLS1odG09KiBc
CisgIHwgLS1odD0qKQorICAgIGh0bWxkaXI9JGFjX29wdGFyZyA7OworCisgIC1pbmNsdWRlZGly
IHwgLS1pbmNsdWRlZGlyIHwgLS1pbmNsdWRlZGkgfCAtLWluY2x1ZGVkIHwgLS1pbmNsdWRlIFwK
KyAgfCAtLWluY2x1ZCB8IC0taW5jbHUgfCAtLWluY2wgfCAtLWluYykKKyAgICBhY19wcmV2PWlu
Y2x1ZGVkaXIgOzsKKyAgLWluY2x1ZGVkaXI9KiB8IC0taW5jbHVkZWRpcj0qIHwgLS1pbmNsdWRl
ZGk9KiB8IC0taW5jbHVkZWQ9KiB8IC0taW5jbHVkZT0qIFwKKyAgfCAtLWluY2x1ZD0qIHwgLS1p
bmNsdT0qIHwgLS1pbmNsPSogfCAtLWluYz0qKQorICAgIGluY2x1ZGVkaXI9JGFjX29wdGFyZyA7
OworCisgIC1pbmZvZGlyIHwgLS1pbmZvZGlyIHwgLS1pbmZvZGkgfCAtLWluZm9kIHwgLS1pbmZv
IHwgLS1pbmYpCisgICAgYWNfcHJldj1pbmZvZGlyIDs7CisgIC1pbmZvZGlyPSogfCAtLWluZm9k
aXI9KiB8IC0taW5mb2RpPSogfCAtLWluZm9kPSogfCAtLWluZm89KiB8IC0taW5mPSopCisgICAg
aW5mb2Rpcj0kYWNfb3B0YXJnIDs7CisKKyAgLWxpYmRpciB8IC0tbGliZGlyIHwgLS1saWJkaSB8
IC0tbGliZCkKKyAgICBhY19wcmV2PWxpYmRpciA7OworICAtbGliZGlyPSogfCAtLWxpYmRpcj0q
IHwgLS1saWJkaT0qIHwgLS1saWJkPSopCisgICAgbGliZGlyPSRhY19vcHRhcmcgOzsKKworICAt
bGliZXhlY2RpciB8IC0tbGliZXhlY2RpciB8IC0tbGliZXhlY2RpIHwgLS1saWJleGVjZCB8IC0t
bGliZXhlYyBcCisgIHwgLS1saWJleGUgfCAtLWxpYmV4IHwgLS1saWJlKQorICAgIGFjX3ByZXY9
bGliZXhlY2RpciA7OworICAtbGliZXhlY2Rpcj0qIHwgLS1saWJleGVjZGlyPSogfCAtLWxpYmV4
ZWNkaT0qIHwgLS1saWJleGVjZD0qIHwgLS1saWJleGVjPSogXAorICB8IC0tbGliZXhlPSogfCAt
LWxpYmV4PSogfCAtLWxpYmU9KikKKyAgICBsaWJleGVjZGlyPSRhY19vcHRhcmcgOzsKKworICAt
bG9jYWxlZGlyIHwgLS1sb2NhbGVkaXIgfCAtLWxvY2FsZWRpIHwgLS1sb2NhbGVkIHwgLS1sb2Nh
bGUpCisgICAgYWNfcHJldj1sb2NhbGVkaXIgOzsKKyAgLWxvY2FsZWRpcj0qIHwgLS1sb2NhbGVk
aXI9KiB8IC0tbG9jYWxlZGk9KiB8IC0tbG9jYWxlZD0qIHwgLS1sb2NhbGU9KikKKyAgICBsb2Nh
bGVkaXI9JGFjX29wdGFyZyA7OworCisgIC1sb2NhbHN0YXRlZGlyIHwgLS1sb2NhbHN0YXRlZGly
IHwgLS1sb2NhbHN0YXRlZGkgfCAtLWxvY2Fsc3RhdGVkIFwKKyAgfCAtLWxvY2Fsc3RhdGUgfCAt
LWxvY2Fsc3RhdCB8IC0tbG9jYWxzdGEgfCAtLWxvY2Fsc3QgfCAtLWxvY2FscykKKyAgICBhY19w
cmV2PWxvY2Fsc3RhdGVkaXIgOzsKKyAgLWxvY2Fsc3RhdGVkaXI9KiB8IC0tbG9jYWxzdGF0ZWRp
cj0qIHwgLS1sb2NhbHN0YXRlZGk9KiB8IC0tbG9jYWxzdGF0ZWQ9KiBcCisgIHwgLS1sb2NhbHN0
YXRlPSogfCAtLWxvY2Fsc3RhdD0qIHwgLS1sb2NhbHN0YT0qIHwgLS1sb2NhbHN0PSogfCAtLWxv
Y2Fscz0qKQorICAgIGxvY2Fsc3RhdGVkaXI9JGFjX29wdGFyZyA7OworCisgIC1tYW5kaXIgfCAt
LW1hbmRpciB8IC0tbWFuZGkgfCAtLW1hbmQgfCAtLW1hbiB8IC0tbWEgfCAtLW0pCisgICAgYWNf
cHJldj1tYW5kaXIgOzsKKyAgLW1hbmRpcj0qIHwgLS1tYW5kaXI9KiB8IC0tbWFuZGk9KiB8IC0t
bWFuZD0qIHwgLS1tYW49KiB8IC0tbWE9KiB8IC0tbT0qKQorICAgIG1hbmRpcj0kYWNfb3B0YXJn
IDs7CisKKyAgLW5mcCB8IC0tbmZwIHwgLS1uZikKKyAgICAjIE9ic29sZXRlOyB1c2UgLS13aXRo
b3V0LWZwLgorICAgIHdpdGhfZnA9bm8gOzsKKworICAtbm8tY3JlYXRlIHwgLS1uby1jcmVhdGUg
fCAtLW5vLWNyZWF0IHwgLS1uby1jcmVhIHwgLS1uby1jcmUgXAorICB8IC0tbm8tY3IgfCAtLW5v
LWMgfCAtbikKKyAgICBub19jcmVhdGU9eWVzIDs7CisKKyAgLW5vLXJlY3Vyc2lvbiB8IC0tbm8t
cmVjdXJzaW9uIHwgLS1uby1yZWN1cnNpbyB8IC0tbm8tcmVjdXJzaSBcCisgIHwgLS1uby1yZWN1
cnMgfCAtLW5vLXJlY3VyIHwgLS1uby1yZWN1IHwgLS1uby1yZWMgfCAtLW5vLXJlIHwgLS1uby1y
KQorICAgIG5vX3JlY3Vyc2lvbj15ZXMgOzsKKworICAtb2xkaW5jbHVkZWRpciB8IC0tb2xkaW5j
bHVkZWRpciB8IC0tb2xkaW5jbHVkZWRpIHwgLS1vbGRpbmNsdWRlZCBcCisgIHwgLS1vbGRpbmNs
dWRlIHwgLS1vbGRpbmNsdWQgfCAtLW9sZGluY2x1IHwgLS1vbGRpbmNsIHwgLS1vbGRpbmMgXAor
ICB8IC0tb2xkaW4gfCAtLW9sZGkgfCAtLW9sZCB8IC0tb2wgfCAtLW8pCisgICAgYWNfcHJldj1v
bGRpbmNsdWRlZGlyIDs7CisgIC1vbGRpbmNsdWRlZGlyPSogfCAtLW9sZGluY2x1ZGVkaXI9KiB8
IC0tb2xkaW5jbHVkZWRpPSogfCAtLW9sZGluY2x1ZGVkPSogXAorICB8IC0tb2xkaW5jbHVkZT0q
IHwgLS1vbGRpbmNsdWQ9KiB8IC0tb2xkaW5jbHU9KiB8IC0tb2xkaW5jbD0qIHwgLS1vbGRpbmM9
KiBcCisgIHwgLS1vbGRpbj0qIHwgLS1vbGRpPSogfCAtLW9sZD0qIHwgLS1vbD0qIHwgLS1vPSop
CisgICAgb2xkaW5jbHVkZWRpcj0kYWNfb3B0YXJnIDs7CisKKyAgLXByZWZpeCB8IC0tcHJlZml4
IHwgLS1wcmVmaSB8IC0tcHJlZiB8IC0tcHJlIHwgLS1wciB8IC0tcCkKKyAgICBhY19wcmV2PXBy
ZWZpeCA7OworICAtcHJlZml4PSogfCAtLXByZWZpeD0qIHwgLS1wcmVmaT0qIHwgLS1wcmVmPSog
fCAtLXByZT0qIHwgLS1wcj0qIHwgLS1wPSopCisgICAgcHJlZml4PSRhY19vcHRhcmcgOzsKKwor
ICAtcHJvZ3JhbS1wcmVmaXggfCAtLXByb2dyYW0tcHJlZml4IHwgLS1wcm9ncmFtLXByZWZpIHwg
LS1wcm9ncmFtLXByZWYgXAorICB8IC0tcHJvZ3JhbS1wcmUgfCAtLXByb2dyYW0tcHIgfCAtLXBy
b2dyYW0tcCkKKyAgICBhY19wcmV2PXByb2dyYW1fcHJlZml4IDs7CisgIC1wcm9ncmFtLXByZWZp
eD0qIHwgLS1wcm9ncmFtLXByZWZpeD0qIHwgLS1wcm9ncmFtLXByZWZpPSogXAorICB8IC0tcHJv
Z3JhbS1wcmVmPSogfCAtLXByb2dyYW0tcHJlPSogfCAtLXByb2dyYW0tcHI9KiB8IC0tcHJvZ3Jh
bS1wPSopCisgICAgcHJvZ3JhbV9wcmVmaXg9JGFjX29wdGFyZyA7OworCisgIC1wcm9ncmFtLXN1
ZmZpeCB8IC0tcHJvZ3JhbS1zdWZmaXggfCAtLXByb2dyYW0tc3VmZmkgfCAtLXByb2dyYW0tc3Vm
ZiBcCisgIHwgLS1wcm9ncmFtLXN1ZiB8IC0tcHJvZ3JhbS1zdSB8IC0tcHJvZ3JhbS1zKQorICAg
IGFjX3ByZXY9cHJvZ3JhbV9zdWZmaXggOzsKKyAgLXByb2dyYW0tc3VmZml4PSogfCAtLXByb2dy
YW0tc3VmZml4PSogfCAtLXByb2dyYW0tc3VmZmk9KiBcCisgIHwgLS1wcm9ncmFtLXN1ZmY9KiB8
IC0tcHJvZ3JhbS1zdWY9KiB8IC0tcHJvZ3JhbS1zdT0qIHwgLS1wcm9ncmFtLXM9KikKKyAgICBw
cm9ncmFtX3N1ZmZpeD0kYWNfb3B0YXJnIDs7CisKKyAgLXByb2dyYW0tdHJhbnNmb3JtLW5hbWUg
fCAtLXByb2dyYW0tdHJhbnNmb3JtLW5hbWUgXAorICB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0tbmFt
IHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYSBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uIHwg
LS1wcm9ncmFtLXRyYW5zZm9ybS0gXAorICB8IC0tcHJvZ3JhbS10cmFuc2Zvcm0gfCAtLXByb2dy
YW0tdHJhbnNmb3IgXAorICB8IC0tcHJvZ3JhbS10cmFuc2ZvIHwgLS1wcm9ncmFtLXRyYW5zZiBc
CisgIHwgLS1wcm9ncmFtLXRyYW5zIHwgLS1wcm9ncmFtLXRyYW4gXAorICB8IC0tcHJvZ3ItdHJh
IHwgLS1wcm9ncmFtLXRyIHwgLS1wcm9ncmFtLXQpCisgICAgYWNfcHJldj1wcm9ncmFtX3RyYW5z
Zm9ybV9uYW1lIDs7CisgIC1wcm9ncmFtLXRyYW5zZm9ybS1uYW1lPSogfCAtLXByb2dyYW0tdHJh
bnNmb3JtLW5hbWU9KiBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uYW09KiB8IC0tcHJvZ3Jh
bS10cmFuc2Zvcm0tbmE9KiBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm9ybS1uPSogfCAtLXByb2dy
YW0tdHJhbnNmb3JtLT0qIFwKKyAgfCAtLXByb2dyYW0tdHJhbnNmb3JtPSogfCAtLXByb2dyYW0t
dHJhbnNmb3I9KiBcCisgIHwgLS1wcm9ncmFtLXRyYW5zZm89KiB8IC0tcHJvZ3JhbS10cmFuc2Y9
KiBcCisgIHwgLS1wcm9ncmFtLXRyYW5zPSogfCAtLXByb2dyYW0tdHJhbj0qIFwKKyAgfCAtLXBy
b2dyLXRyYT0qIHwgLS1wcm9ncmFtLXRyPSogfCAtLXByb2dyYW0tdD0qKQorICAgIHByb2dyYW1f
dHJhbnNmb3JtX25hbWU9JGFjX29wdGFyZyA7OworCisgIC1wZGZkaXIgfCAtLXBkZmRpciB8IC0t
cGRmZGkgfCAtLXBkZmQgfCAtLXBkZiB8IC0tcGQpCisgICAgYWNfcHJldj1wZGZkaXIgOzsKKyAg
LXBkZmRpcj0qIHwgLS1wZGZkaXI9KiB8IC0tcGRmZGk9KiB8IC0tcGRmZD0qIHwgLS1wZGY9KiB8
IC0tcGQ9KikKKyAgICBwZGZkaXI9JGFjX29wdGFyZyA7OworCisgIC1wc2RpciB8IC0tcHNkaXIg
fCAtLXBzZGkgfCAtLXBzZCB8IC0tcHMpCisgICAgYWNfcHJldj1wc2RpciA7OworICAtcHNkaXI9
KiB8IC0tcHNkaXI9KiB8IC0tcHNkaT0qIHwgLS1wc2Q9KiB8IC0tcHM9KikKKyAgICBwc2Rpcj0k
YWNfb3B0YXJnIDs7CisKKyAgLXEgfCAtcXVpZXQgfCAtLXF1aWV0IHwgLS1xdWllIHwgLS1xdWkg
fCAtLXF1IHwgLS1xIFwKKyAgfCAtc2lsZW50IHwgLS1zaWxlbnQgfCAtLXNpbGVuIHwgLS1zaWxl
IHwgLS1zaWwpCisgICAgc2lsZW50PXllcyA7OworCisgIC1zYmluZGlyIHwgLS1zYmluZGlyIHwg
LS1zYmluZGkgfCAtLXNiaW5kIHwgLS1zYmluIHwgLS1zYmkgfCAtLXNiKQorICAgIGFjX3ByZXY9
c2JpbmRpciA7OworICAtc2JpbmRpcj0qIHwgLS1zYmluZGlyPSogfCAtLXNiaW5kaT0qIHwgLS1z
YmluZD0qIHwgLS1zYmluPSogXAorICB8IC0tc2JpPSogfCAtLXNiPSopCisgICAgc2JpbmRpcj0k
YWNfb3B0YXJnIDs7CisKKyAgLXNoYXJlZHN0YXRlZGlyIHwgLS1zaGFyZWRzdGF0ZWRpciB8IC0t
c2hhcmVkc3RhdGVkaSBcCisgIHwgLS1zaGFyZWRzdGF0ZWQgfCAtLXNoYXJlZHN0YXRlIHwgLS1z
aGFyZWRzdGF0IHwgLS1zaGFyZWRzdGEgXAorICB8IC0tc2hhcmVkc3QgfCAtLXNoYXJlZHMgfCAt
LXNoYXJlZCB8IC0tc2hhcmUgfCAtLXNoYXIgXAorICB8IC0tc2hhIHwgLS1zaCkKKyAgICBhY19w
cmV2PXNoYXJlZHN0YXRlZGlyIDs7CisgIC1zaGFyZWRzdGF0ZWRpcj0qIHwgLS1zaGFyZWRzdGF0
ZWRpcj0qIHwgLS1zaGFyZWRzdGF0ZWRpPSogXAorICB8IC0tc2hhcmVkc3RhdGVkPSogfCAtLXNo
YXJlZHN0YXRlPSogfCAtLXNoYXJlZHN0YXQ9KiB8IC0tc2hhcmVkc3RhPSogXAorICB8IC0tc2hh
cmVkc3Q9KiB8IC0tc2hhcmVkcz0qIHwgLS1zaGFyZWQ9KiB8IC0tc2hhcmU9KiB8IC0tc2hhcj0q
IFwKKyAgfCAtLXNoYT0qIHwgLS1zaD0qKQorICAgIHNoYXJlZHN0YXRlZGlyPSRhY19vcHRhcmcg
OzsKKworICAtc2l0ZSB8IC0tc2l0ZSB8IC0tc2l0KQorICAgIGFjX3ByZXY9c2l0ZSA7OworICAt
c2l0ZT0qIHwgLS1zaXRlPSogfCAtLXNpdD0qKQorICAgIHNpdGU9JGFjX29wdGFyZyA7OworCisg
IC1zcmNkaXIgfCAtLXNyY2RpciB8IC0tc3JjZGkgfCAtLXNyY2QgfCAtLXNyYyB8IC0tc3IpCisg
ICAgYWNfcHJldj1zcmNkaXIgOzsKKyAgLXNyY2Rpcj0qIHwgLS1zcmNkaXI9KiB8IC0tc3JjZGk9
KiB8IC0tc3JjZD0qIHwgLS1zcmM9KiB8IC0tc3I9KikKKyAgICBzcmNkaXI9JGFjX29wdGFyZyA7
OworCisgIC1zeXNjb25mZGlyIHwgLS1zeXNjb25mZGlyIHwgLS1zeXNjb25mZGkgfCAtLXN5c2Nv
bmZkIHwgLS1zeXNjb25mIFwKKyAgfCAtLXN5c2NvbiB8IC0tc3lzY28gfCAtLXN5c2MgfCAtLXN5
cyB8IC0tc3kpCisgICAgYWNfcHJldj1zeXNjb25mZGlyIDs7CisgIC1zeXNjb25mZGlyPSogfCAt
LXN5c2NvbmZkaXI9KiB8IC0tc3lzY29uZmRpPSogfCAtLXN5c2NvbmZkPSogfCAtLXN5c2NvbmY9
KiBcCisgIHwgLS1zeXNjb249KiB8IC0tc3lzY289KiB8IC0tc3lzYz0qIHwgLS1zeXM9KiB8IC0t
c3k9KikKKyAgICBzeXNjb25mZGlyPSRhY19vcHRhcmcgOzsKKworICAtdGFyZ2V0IHwgLS10YXJn
ZXQgfCAtLXRhcmdlIHwgLS10YXJnIHwgLS10YXIgfCAtLXRhIHwgLS10KQorICAgIGFjX3ByZXY9
dGFyZ2V0X2FsaWFzIDs7CisgIC10YXJnZXQ9KiB8IC0tdGFyZ2V0PSogfCAtLXRhcmdlPSogfCAt
LXRhcmc9KiB8IC0tdGFyPSogfCAtLXRhPSogfCAtLXQ9KikKKyAgICB0YXJnZXRfYWxpYXM9JGFj
X29wdGFyZyA7OworCisgIC12IHwgLXZlcmJvc2UgfCAtLXZlcmJvc2UgfCAtLXZlcmJvcyB8IC0t
dmVyYm8gfCAtLXZlcmIpCisgICAgdmVyYm9zZT15ZXMgOzsKKworICAtdmVyc2lvbiB8IC0tdmVy
c2lvbiB8IC0tdmVyc2lvIHwgLS12ZXJzaSB8IC0tdmVycyB8IC1WKQorICAgIGFjX2luaXRfdmVy
c2lvbj06IDs7CisKKyAgLXdpdGgtKiB8IC0td2l0aC0qKQorICAgIGFjX3VzZXJvcHQ9YGV4cHIg
IngkYWNfb3B0aW9uIiA6ICd4LSp3aXRoLVwoW149XSpcKSdgCisgICAgIyBSZWplY3QgbmFtZXMg
dGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGV4cHIgIngkYWNf
dXNlcm9wdCIgOiAiLipbXi0rLl8kYXNfY3JfYWxudW1dIiA+L2Rldi9udWxsICYmCisgICAgICBh
c19mbl9lcnJvciAkPyAiaW52YWxpZCBwYWNrYWdlIG5hbWU6ICRhY191c2Vyb3B0IgorICAgIGFj
X3VzZXJvcHRfb3JpZz0kYWNfdXNlcm9wdAorICAgIGFjX3VzZXJvcHQ9YCRhc19lY2hvICIkYWNf
dXNlcm9wdCIgfCBzZWQgJ3MvWy0rLl0vXy9nJ2AKKyAgICBjYXNlICRhY191c2VyX29wdHMgaW4K
KyAgICAgICoiCisid2l0aF8kYWNfdXNlcm9wdCIKKyIqKSA7OworICAgICAgKikgYWNfdW5yZWNv
Z25pemVkX29wdHM9IiRhY191bnJlY29nbml6ZWRfb3B0cyRhY191bnJlY29nbml6ZWRfc2VwLS13
aXRoLSRhY191c2Vyb3B0X29yaWciCisJIGFjX3VucmVjb2duaXplZF9zZXA9JywgJzs7CisgICAg
ZXNhYworICAgIGV2YWwgd2l0aF8kYWNfdXNlcm9wdD1cJGFjX29wdGFyZyA7OworCisgIC13aXRo
b3V0LSogfCAtLXdpdGhvdXQtKikKKyAgICBhY191c2Vyb3B0PWBleHByICJ4JGFjX29wdGlvbiIg
OiAneC0qd2l0aG91dC1cKC4qXCknYAorICAgICMgUmVqZWN0IG5hbWVzIHRoYXQgYXJlIG5vdCB2
YWxpZCBzaGVsbCB2YXJpYWJsZSBuYW1lcy4KKyAgICBleHByICJ4JGFjX3VzZXJvcHQiIDogIi4q
W14tKy5fJGFzX2NyX2FsbnVtXSIgPi9kZXYvbnVsbCAmJgorICAgICAgYXNfZm5fZXJyb3IgJD8g
ImludmFsaWQgcGFja2FnZSBuYW1lOiAkYWNfdXNlcm9wdCIKKyAgICBhY191c2Vyb3B0X29yaWc9
JGFjX3VzZXJvcHQKKyAgICBhY191c2Vyb3B0PWAkYXNfZWNobyAiJGFjX3VzZXJvcHQiIHwgc2Vk
ICdzL1stKy5dL18vZydgCisgICAgY2FzZSAkYWNfdXNlcl9vcHRzIGluCisgICAgICAqIgorIndp
dGhfJGFjX3VzZXJvcHQiCisiKikgOzsKKyAgICAgICopIGFjX3VucmVjb2duaXplZF9vcHRzPSIk
YWNfdW5yZWNvZ25pemVkX29wdHMkYWNfdW5yZWNvZ25pemVkX3NlcC0td2l0aG91dC0kYWNfdXNl
cm9wdF9vcmlnIgorCSBhY191bnJlY29nbml6ZWRfc2VwPScsICc7OworICAgIGVzYWMKKyAgICBl
dmFsIHdpdGhfJGFjX3VzZXJvcHQ9bm8gOzsKKworICAtLXgpCisgICAgIyBPYnNvbGV0ZTsgdXNl
IC0td2l0aC14LgorICAgIHdpdGhfeD15ZXMgOzsKKworICAteC1pbmNsdWRlcyB8IC0teC1pbmNs
dWRlcyB8IC0teC1pbmNsdWRlIHwgLS14LWluY2x1ZCB8IC0teC1pbmNsdSBcCisgIHwgLS14LWlu
Y2wgfCAtLXgtaW5jIHwgLS14LWluIHwgLS14LWkpCisgICAgYWNfcHJldj14X2luY2x1ZGVzIDs7
CisgIC14LWluY2x1ZGVzPSogfCAtLXgtaW5jbHVkZXM9KiB8IC0teC1pbmNsdWRlPSogfCAtLXgt
aW5jbHVkPSogfCAtLXgtaW5jbHU9KiBcCisgIHwgLS14LWluY2w9KiB8IC0teC1pbmM9KiB8IC0t
eC1pbj0qIHwgLS14LWk9KikKKyAgICB4X2luY2x1ZGVzPSRhY19vcHRhcmcgOzsKKworICAteC1s
aWJyYXJpZXMgfCAtLXgtbGlicmFyaWVzIHwgLS14LWxpYnJhcmllIHwgLS14LWxpYnJhcmkgXAor
ICB8IC0teC1saWJyYXIgfCAtLXgtbGlicmEgfCAtLXgtbGliciB8IC0teC1saWIgfCAtLXgtbGkg
fCAtLXgtbCkKKyAgICBhY19wcmV2PXhfbGlicmFyaWVzIDs7CisgIC14LWxpYnJhcmllcz0qIHwg
LS14LWxpYnJhcmllcz0qIHwgLS14LWxpYnJhcmllPSogfCAtLXgtbGlicmFyaT0qIFwKKyAgfCAt
LXgtbGlicmFyPSogfCAtLXgtbGlicmE9KiB8IC0teC1saWJyPSogfCAtLXgtbGliPSogfCAtLXgt
bGk9KiB8IC0teC1sPSopCisgICAgeF9saWJyYXJpZXM9JGFjX29wdGFyZyA7OworCisgIC0qKSBh
c19mbl9lcnJvciAkPyAidW5yZWNvZ25pemVkIG9wdGlvbjogXGAkYWNfb3B0aW9uJworVHJ5IFxg
JDAgLS1oZWxwJyBmb3IgbW9yZSBpbmZvcm1hdGlvbiIKKyAgICA7OworCisgICo9KikKKyAgICBh
Y19lbnZ2YXI9YGV4cHIgIngkYWNfb3B0aW9uIiA6ICd4XChbXj1dKlwpPSdgCisgICAgIyBSZWpl
Y3QgbmFtZXMgdGhhdCBhcmUgbm90IHZhbGlkIHNoZWxsIHZhcmlhYmxlIG5hbWVzLgorICAgIGNh
c2UgJGFjX2VudnZhciBpbiAjKAorICAgICAgJycgfCBbMC05XSogfCAqWyFfJGFzX2NyX2FsbnVt
XSogKQorICAgICAgYXNfZm5fZXJyb3IgJD8gImludmFsaWQgdmFyaWFibGUgbmFtZTogXGAkYWNf
ZW52dmFyJyIgOzsKKyAgICBlc2FjCisgICAgZXZhbCAkYWNfZW52dmFyPVwkYWNfb3B0YXJnCisg
ICAgZXhwb3J0ICRhY19lbnZ2YXIgOzsKKworICAqKQorICAgICMgRklYTUU6IHNob3VsZCBiZSBy
ZW1vdmVkIGluIGF1dG9jb25mIDMuMC4KKyAgICAkYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB5
b3Ugc2hvdWxkIHVzZSAtLWJ1aWxkLCAtLWhvc3QsIC0tdGFyZ2V0IiA+JjIKKyAgICBleHByICJ4
JGFjX29wdGlvbiIgOiAiLipbXi0uXyRhc19jcl9hbG51bV0iID4vZGV2L251bGwgJiYKKyAgICAg
ICRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IGludmFsaWQgaG9zdCB0eXBlOiAkYWNfb3B0aW9u
IiA+JjIKKyAgICA6ICIke2J1aWxkX2FsaWFzPSRhY19vcHRpb259ICR7aG9zdF9hbGlhcz0kYWNf
b3B0aW9ufSAke3RhcmdldF9hbGlhcz0kYWNfb3B0aW9ufSIKKyAgICA7OworCisgIGVzYWMKK2Rv
bmUKKworaWYgdGVzdCAtbiAiJGFjX3ByZXYiOyB0aGVuCisgIGFjX29wdGlvbj0tLWBlY2hvICRh
Y19wcmV2IHwgc2VkICdzL18vLS9nJ2AKKyAgYXNfZm5fZXJyb3IgJD8gIm1pc3NpbmcgYXJndW1l
bnQgdG8gJGFjX29wdGlvbiIKK2ZpCisKK2lmIHRlc3QgLW4gIiRhY191bnJlY29nbml6ZWRfb3B0
cyI7IHRoZW4KKyAgY2FzZSAkZW5hYmxlX29wdGlvbl9jaGVja2luZyBpbgorICAgIG5vKSA7Owor
ICAgIGZhdGFsKSBhc19mbl9lcnJvciAkPyAidW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJl
Y29nbml6ZWRfb3B0cyIgOzsKKyAgICAqKSAgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzog
dW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiYyIDs7CisgIGVz
YWMKK2ZpCisKKyMgQ2hlY2sgYWxsIGRpcmVjdG9yeSBhcmd1bWVudHMgZm9yIGNvbnNpc3RlbmN5
LgorZm9yIGFjX3ZhciBpbglleGVjX3ByZWZpeCBwcmVmaXggYmluZGlyIHNiaW5kaXIgbGliZXhl
Y2RpciBkYXRhcm9vdGRpciBcCisJCWRhdGFkaXIgc3lzY29uZmRpciBzaGFyZWRzdGF0ZWRpciBs
b2NhbHN0YXRlZGlyIGluY2x1ZGVkaXIgXAorCQlvbGRpbmNsdWRlZGlyIGRvY2RpciBpbmZvZGly
IGh0bWxkaXIgZHZpZGlyIHBkZmRpciBwc2RpciBcCisJCWxpYmRpciBsb2NhbGVkaXIgbWFuZGly
CitkbworICBldmFsIGFjX3ZhbD1cJCRhY192YXIKKyAgIyBSZW1vdmUgdHJhaWxpbmcgc2xhc2hl
cy4KKyAgY2FzZSAkYWNfdmFsIGluCisgICAgKi8gKQorICAgICAgYWNfdmFsPWBleHByICJYJGFj
X3ZhbCIgOiAnWFwoLipbXi9dXCknIFx8ICJYJGFjX3ZhbCIgOiAnWFwoLipcKSdgCisgICAgICBl
dmFsICRhY192YXI9XCRhY192YWw7OworICBlc2FjCisgICMgQmUgc3VyZSB0byBoYXZlIGFic29s
dXRlIGRpcmVjdG9yeSBuYW1lcy4KKyAgY2FzZSAkYWNfdmFsIGluCisgICAgW1xcLyRdKiB8ID86
W1xcL10qICkgIGNvbnRpbnVlOzsKKyAgICBOT05FIHwgJycgKSBjYXNlICRhY192YXIgaW4gKnBy
ZWZpeCApIGNvbnRpbnVlOzsgZXNhYzs7CisgIGVzYWMKKyAgYXNfZm5fZXJyb3IgJD8gImV4cGVj
dGVkIGFuIGFic29sdXRlIGRpcmVjdG9yeSBuYW1lIGZvciAtLSRhY192YXI6ICRhY192YWwiCitk
b25lCisKKyMgVGhlcmUgbWlnaHQgYmUgcGVvcGxlIHdobyBkZXBlbmQgb24gdGhlIG9sZCBicm9r
ZW4gYmVoYXZpb3I6IGAkaG9zdCcKKyMgdXNlZCB0byBob2xkIHRoZSBhcmd1bWVudCBvZiAtLWhv
c3QgZXRjLgorIyBGSVhNRTogVG8gcmVtb3ZlIHNvbWUgZGF5LgorYnVpbGQ9JGJ1aWxkX2FsaWFz
Citob3N0PSRob3N0X2FsaWFzCit0YXJnZXQ9JHRhcmdldF9hbGlhcworCisjIEZJWE1FOiBUbyBy
ZW1vdmUgc29tZSBkYXkuCitpZiB0ZXN0ICJ4JGhvc3RfYWxpYXMiICE9IHg7IHRoZW4KKyAgaWYg
dGVzdCAieCRidWlsZF9hbGlhcyIgPSB4OyB0aGVuCisgICAgY3Jvc3NfY29tcGlsaW5nPW1heWJl
CisgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogaWYgeW91IHdhbnRlZCB0byBzZXQgdGhl
IC0tYnVpbGQgdHlwZSwgZG9uJ3QgdXNlIC0taG9zdC4KKyAgICBJZiBhIGNyb3NzIGNvbXBpbGVy
IGlzIGRldGVjdGVkIHRoZW4gY3Jvc3MgY29tcGlsZSBtb2RlIHdpbGwgYmUgdXNlZCIgPiYyCisg
IGVsaWYgdGVzdCAieCRidWlsZF9hbGlhcyIgIT0gIngkaG9zdF9hbGlhcyI7IHRoZW4KKyAgICBj
cm9zc19jb21waWxpbmc9eWVzCisgIGZpCitmaQorCithY190b29sX3ByZWZpeD0KK3Rlc3QgLW4g
IiRob3N0X2FsaWFzIiAmJiBhY190b29sX3ByZWZpeD0kaG9zdF9hbGlhcy0KKwordGVzdCAiJHNp
bGVudCIgPSB5ZXMgJiYgZXhlYyA2Pi9kZXYvbnVsbAorCisKK2FjX3B3ZD1gcHdkYCAmJiB0ZXN0
IC1uICIkYWNfcHdkIiAmJgorYWNfbHNfZGk9YGxzIC1kaSAuYCAmJgorYWNfcHdkX2xzX2RpPWBj
ZCAiJGFjX3B3ZCIgJiYgbHMgLWRpIC5gIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJ3b3JraW5nIGRp
cmVjdG9yeSBjYW5ub3QgYmUgZGV0ZXJtaW5lZCIKK3Rlc3QgIlgkYWNfbHNfZGkiID0gIlgkYWNf
cHdkX2xzX2RpIiB8fAorICBhc19mbl9lcnJvciAkPyAicHdkIGRvZXMgbm90IHJlcG9ydCBuYW1l
IG9mIHdvcmtpbmcgZGlyZWN0b3J5IgorCisKKyMgRmluZCB0aGUgc291cmNlIGZpbGVzLCBpZiBs
b2NhdGlvbiB3YXMgbm90IHNwZWNpZmllZC4KK2lmIHRlc3QgLXogIiRzcmNkaXIiOyB0aGVuCisg
IGFjX3NyY2Rpcl9kZWZhdWx0ZWQ9eWVzCisgICMgVHJ5IHRoZSBkaXJlY3RvcnkgY29udGFpbmlu
ZyB0aGlzIHNjcmlwdCwgdGhlbiB0aGUgcGFyZW50IGRpcmVjdG9yeS4KKyAgYWNfY29uZmRpcj1g
JGFzX2Rpcm5hbWUgLS0gIiRhc19teXNlbGYiIHx8CiskYXNfZXhwciBYIiRhc19teXNlbGYiIDog
J1hcKC4qW14vXVwpLy8qW14vXVteL10qLyokJyBcfCBcCisJIFgiJGFzX215c2VsZiIgOiAnWFwo
Ly9cKVteL10nIFx8IFwKKwkgWCIkYXNfbXlzZWxmIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiRh
c19teXNlbGYiIDogJ1hcKC9cKScgXHwgLiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWCIkYXNf
bXlzZWxmIiB8CisgICAgc2VkICcvXlhcKC4qW14vXVwpXC9cLypbXi9dW14vXSpcLyokL3sKKwkg
ICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpW14vXS4qL3sKKwkgICAgcy8v
XDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9cL1wpJC97CisJICAgIHMvL1wxLworCSAgICBx
CisJICB9CisJICAvXlhcKFwvXCkuKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICBz
Ly4qLy4vOyBxJ2AKKyAgc3JjZGlyPSRhY19jb25mZGlyCisgIGlmIHRlc3QgISAtciAiJHNyY2Rp
ci8kYWNfdW5pcXVlX2ZpbGUiOyB0aGVuCisgICAgc3JjZGlyPS4uCisgIGZpCitlbHNlCisgIGFj
X3NyY2Rpcl9kZWZhdWx0ZWQ9bm8KK2ZpCitpZiB0ZXN0ICEgLXIgIiRzcmNkaXIvJGFjX3VuaXF1
ZV9maWxlIjsgdGhlbgorICB0ZXN0ICIkYWNfc3JjZGlyX2RlZmF1bHRlZCIgPSB5ZXMgJiYgc3Jj
ZGlyPSIkYWNfY29uZmRpciBvciAuLiIKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIHNv
dXJjZXMgKCRhY191bmlxdWVfZmlsZSkgaW4gJHNyY2RpciIKK2ZpCithY19tc2c9InNvdXJjZXMg
YXJlIGluICRzcmNkaXIsIGJ1dCBcYGNkICRzcmNkaXInIGRvZXMgbm90IHdvcmsiCithY19hYnNf
Y29uZmRpcj1gKAorCWNkICIkc3JjZGlyIiAmJiB0ZXN0IC1yICIuLyRhY191bmlxdWVfZmlsZSIg
fHwgYXNfZm5fZXJyb3IgJD8gIiRhY19tc2ciCisJcHdkKWAKKyMgV2hlbiBidWlsZGluZyBpbiBw
bGFjZSwgc2V0IHNyY2Rpcj0uCitpZiB0ZXN0ICIkYWNfYWJzX2NvbmZkaXIiID0gIiRhY19wd2Qi
OyB0aGVuCisgIHNyY2Rpcj0uCitmaQorIyBSZW1vdmUgdW5uZWNlc3NhcnkgdHJhaWxpbmcgc2xh
c2hlcyBmcm9tIHNyY2Rpci4KKyMgRG91YmxlIHNsYXNoZXMgaW4gZmlsZSBuYW1lcyBpbiBvYmpl
Y3QgZmlsZSBkZWJ1Z2dpbmcgaW5mbworIyBtZXNzIHVwIE0teCBnZGIgaW4gRW1hY3MuCitjYXNl
ICRzcmNkaXIgaW4KKyovKSBzcmNkaXI9YGV4cHIgIlgkc3JjZGlyIiA6ICdYXCguKlteL11cKScg
XHwgIlgkc3JjZGlyIiA6ICdYXCguKlwpJ2A7OworZXNhYworZm9yIGFjX3ZhciBpbiAkYWNfcHJl
Y2lvdXNfdmFyczsgZG8KKyAgZXZhbCBhY19lbnZfJHthY192YXJ9X3NldD1cJHske2FjX3Zhcn0r
c2V0fQorICBldmFsIGFjX2Vudl8ke2FjX3Zhcn1fdmFsdWU9XCQke2FjX3Zhcn0KKyAgZXZhbCBh
Y19jdl9lbnZfJHthY192YXJ9X3NldD1cJHske2FjX3Zhcn0rc2V0fQorICBldmFsIGFjX2N2X2Vu
dl8ke2FjX3Zhcn1fdmFsdWU9XCQke2FjX3Zhcn0KK2RvbmUKKworIworIyBSZXBvcnQgdGhlIC0t
aGVscCBtZXNzYWdlLgorIworaWYgdGVzdCAiJGFjX2luaXRfaGVscCIgPSAibG9uZyI7IHRoZW4K
KyAgIyBPbWl0IHNvbWUgaW50ZXJuYWwgb3Igb2Jzb2xldGUgb3B0aW9ucyB0byBtYWtlIHRoZSBs
aXN0IGxlc3MgaW1wb3NpbmcuCisgICMgVGhpcyBtZXNzYWdlIGlzIHRvbyBsb25nIHRvIGJlIGEg
c3RyaW5nIGluIHRoZSBBL1VYIDMuMSBzaC4KKyAgY2F0IDw8X0FDRU9GCitcYGNvbmZpZ3VyZScg
Y29uZmlndXJlcyBYZW4gSHlwZXJ2aXNvciA0LjIgdG8gYWRhcHQgdG8gbWFueSBraW5kcyBvZiBz
eXN0ZW1zLgorCitVc2FnZTogJDAgW09QVElPTl0uLi4gW1ZBUj1WQUxVRV0uLi4KKworVG8gYXNz
aWduIGVudmlyb25tZW50IHZhcmlhYmxlcyAoZS5nLiwgQ0MsIENGTEFHUy4uLiksIHNwZWNpZnkg
dGhlbSBhcworVkFSPVZBTFVFLiAgU2VlIGJlbG93IGZvciBkZXNjcmlwdGlvbnMgb2Ygc29tZSBv
ZiB0aGUgdXNlZnVsIHZhcmlhYmxlcy4KKworRGVmYXVsdHMgZm9yIHRoZSBvcHRpb25zIGFyZSBz
cGVjaWZpZWQgaW4gYnJhY2tldHMuCisKK0NvbmZpZ3VyYXRpb246CisgIC1oLCAtLWhlbHAgICAg
ICAgICAgICAgIGRpc3BsYXkgdGhpcyBoZWxwIGFuZCBleGl0CisgICAgICAtLWhlbHA9c2hvcnQg
ICAgICAgIGRpc3BsYXkgb3B0aW9ucyBzcGVjaWZpYyB0byB0aGlzIHBhY2thZ2UKKyAgICAgIC0t
aGVscD1yZWN1cnNpdmUgICAgZGlzcGxheSB0aGUgc2hvcnQgaGVscCBvZiBhbGwgdGhlIGluY2x1
ZGVkIHBhY2thZ2VzCisgIC1WLCAtLXZlcnNpb24gICAgICAgICAgIGRpc3BsYXkgdmVyc2lvbiBp
bmZvcm1hdGlvbiBhbmQgZXhpdAorICAtcSwgLS1xdWlldCwgLS1zaWxlbnQgICBkbyBub3QgcHJp
bnQgXGBjaGVja2luZyAuLi4nIG1lc3NhZ2VzCisgICAgICAtLWNhY2hlLWZpbGU9RklMRSAgIGNh
Y2hlIHRlc3QgcmVzdWx0cyBpbiBGSUxFIFtkaXNhYmxlZF0KKyAgLUMsIC0tY29uZmlnLWNhY2hl
ICAgICAgYWxpYXMgZm9yIFxgLS1jYWNoZS1maWxlPWNvbmZpZy5jYWNoZScKKyAgLW4sIC0tbm8t
Y3JlYXRlICAgICAgICAgZG8gbm90IGNyZWF0ZSBvdXRwdXQgZmlsZXMKKyAgICAgIC0tc3JjZGly
PURJUiAgICAgICAgZmluZCB0aGUgc291cmNlcyBpbiBESVIgW2NvbmZpZ3VyZSBkaXIgb3IgXGAu
LiddCisKK0luc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKKyAgLS1wcmVmaXg9UFJFRklYICAgICAg
ICAgaW5zdGFsbCBhcmNoaXRlY3R1cmUtaW5kZXBlbmRlbnQgZmlsZXMgaW4gUFJFRklYCisgICAg
ICAgICAgICAgICAgICAgICAgICAgIFskYWNfZGVmYXVsdF9wcmVmaXhdCisgIC0tZXhlYy1wcmVm
aXg9RVBSRUZJWCAgIGluc3RhbGwgYXJjaGl0ZWN0dXJlLWRlcGVuZGVudCBmaWxlcyBpbiBFUFJF
RklYCisgICAgICAgICAgICAgICAgICAgICAgICAgIFtQUkVGSVhdCisKK0J5IGRlZmF1bHQsIFxg
bWFrZSBpbnN0YWxsJyB3aWxsIGluc3RhbGwgYWxsIHRoZSBmaWxlcyBpbgorXGAkYWNfZGVmYXVs
dF9wcmVmaXgvYmluJywgXGAkYWNfZGVmYXVsdF9wcmVmaXgvbGliJyBldGMuICBZb3UgY2FuIHNw
ZWNpZnkKK2FuIGluc3RhbGxhdGlvbiBwcmVmaXggb3RoZXIgdGhhbiBcYCRhY19kZWZhdWx0X3By
ZWZpeCcgdXNpbmcgXGAtLXByZWZpeCcsCitmb3IgaW5zdGFuY2UgXGAtLXByZWZpeD1cJEhPTUUn
LgorCitGb3IgYmV0dGVyIGNvbnRyb2wsIHVzZSB0aGUgb3B0aW9ucyBiZWxvdy4KKworRmluZSB0
dW5pbmcgb2YgdGhlIGluc3RhbGxhdGlvbiBkaXJlY3RvcmllczoKKyAgLS1iaW5kaXI9RElSICAg
ICAgICAgICAgdXNlciBleGVjdXRhYmxlcyBbRVBSRUZJWC9iaW5dCisgIC0tc2JpbmRpcj1ESVIg
ICAgICAgICAgIHN5c3RlbSBhZG1pbiBleGVjdXRhYmxlcyBbRVBSRUZJWC9zYmluXQorICAtLWxp
YmV4ZWNkaXI9RElSICAgICAgICBwcm9ncmFtIGV4ZWN1dGFibGVzIFtFUFJFRklYL2xpYmV4ZWNd
CisgIC0tc3lzY29uZmRpcj1ESVIgICAgICAgIHJlYWQtb25seSBzaW5nbGUtbWFjaGluZSBkYXRh
IFtQUkVGSVgvZXRjXQorICAtLXNoYXJlZHN0YXRlZGlyPURJUiAgICBtb2RpZmlhYmxlIGFyY2hp
dGVjdHVyZS1pbmRlcGVuZGVudCBkYXRhIFtQUkVGSVgvY29tXQorICAtLWxvY2Fsc3RhdGVkaXI9
RElSICAgICBtb2RpZmlhYmxlIHNpbmdsZS1tYWNoaW5lIGRhdGEgW1BSRUZJWC92YXJdCisgIC0t
bGliZGlyPURJUiAgICAgICAgICAgIG9iamVjdCBjb2RlIGxpYnJhcmllcyBbRVBSRUZJWC9saWJd
CisgIC0taW5jbHVkZWRpcj1ESVIgICAgICAgIEMgaGVhZGVyIGZpbGVzIFtQUkVGSVgvaW5jbHVk
ZV0KKyAgLS1vbGRpbmNsdWRlZGlyPURJUiAgICAgQyBoZWFkZXIgZmlsZXMgZm9yIG5vbi1nY2Mg
Wy91c3IvaW5jbHVkZV0KKyAgLS1kYXRhcm9vdGRpcj1ESVIgICAgICAgcmVhZC1vbmx5IGFyY2gu
LWluZGVwZW5kZW50IGRhdGEgcm9vdCBbUFJFRklYL3NoYXJlXQorICAtLWRhdGFkaXI9RElSICAg
ICAgICAgICByZWFkLW9ubHkgYXJjaGl0ZWN0dXJlLWluZGVwZW5kZW50IGRhdGEgW0RBVEFST09U
RElSXQorICAtLWluZm9kaXI9RElSICAgICAgICAgICBpbmZvIGRvY3VtZW50YXRpb24gW0RBVEFS
T09URElSL2luZm9dCisgIC0tbG9jYWxlZGlyPURJUiAgICAgICAgIGxvY2FsZS1kZXBlbmRlbnQg
ZGF0YSBbREFUQVJPT1RESVIvbG9jYWxlXQorICAtLW1hbmRpcj1ESVIgICAgICAgICAgICBtYW4g
ZG9jdW1lbnRhdGlvbiBbREFUQVJPT1RESVIvbWFuXQorICAtLWRvY2Rpcj1ESVIgICAgICAgICAg
ICBkb2N1bWVudGF0aW9uIHJvb3QgW0RBVEFST09URElSL2RvYy94ZW4taHlwZXJ2aXNvcl0KKyAg
LS1odG1sZGlyPURJUiAgICAgICAgICAgaHRtbCBkb2N1bWVudGF0aW9uIFtET0NESVJdCisgIC0t
ZHZpZGlyPURJUiAgICAgICAgICAgIGR2aSBkb2N1bWVudGF0aW9uIFtET0NESVJdCisgIC0tcGRm
ZGlyPURJUiAgICAgICAgICAgIHBkZiBkb2N1bWVudGF0aW9uIFtET0NESVJdCisgIC0tcHNkaXI9
RElSICAgICAgICAgICAgIHBzIGRvY3VtZW50YXRpb24gW0RPQ0RJUl0KK19BQ0VPRgorCisgIGNh
dCA8PFxfQUNFT0YKKworU3lzdGVtIHR5cGVzOgorICAtLWJ1aWxkPUJVSUxEICAgICBjb25maWd1
cmUgZm9yIGJ1aWxkaW5nIG9uIEJVSUxEIFtndWVzc2VkXQorICAtLWhvc3Q9SE9TVCAgICAgICBj
cm9zcy1jb21waWxlIHRvIGJ1aWxkIHByb2dyYW1zIHRvIHJ1biBvbiBIT1NUIFtCVUlMRF0KK19B
Q0VPRgorZmkKKworaWYgdGVzdCAtbiAiJGFjX2luaXRfaGVscCI7IHRoZW4KKyAgY2FzZSAkYWNf
aW5pdF9oZWxwIGluCisgICAgIHNob3J0IHwgcmVjdXJzaXZlICkgZWNobyAiQ29uZmlndXJhdGlv
biBvZiBYZW4gSHlwZXJ2aXNvciA0LjI6Ijs7CisgICBlc2FjCisgIGNhdCA8PFxfQUNFT0YKKwor
T3B0aW9uYWwgRmVhdHVyZXM6CisgIC0tZGlzYWJsZS1vcHRpb24tY2hlY2tpbmcgIGlnbm9yZSB1
bnJlY29nbml6ZWQgLS1lbmFibGUvLS13aXRoIG9wdGlvbnMKKyAgLS1kaXNhYmxlLUZFQVRVUkUg
ICAgICAgZG8gbm90IGluY2x1ZGUgRkVBVFVSRSAoc2FtZSBhcyAtLWVuYWJsZS1GRUFUVVJFPW5v
KQorICAtLWVuYWJsZS1GRUFUVVJFWz1BUkddICBpbmNsdWRlIEZFQVRVUkUgW0FSRz15ZXNdCisg
IC0tZW5hYmxlLXhzbSAgICAgICAgICAgIEVuYWJsZSBYU00gc2VjdXJpdHkgbW9kdWxlIChieSBk
ZWZhdWx0LCBGbGFzaykKKyAgLS1lbmFibGUtZ2l0aHR0cCAgICAgICAgRG93bmxvYWQgR0lUIHJl
cG9zaXRvcmllcyB2aWEgSFRUUAorICAtLWRpc2FibGUtbW9uaXRvcnMgICAgICBEaXNhYmxlIHhl
bnN0YXQgYW5kIHhlbnRvcCBtb25pdG9yaW5nIHRvb2xzCisgIC0tZW5hYmxlLXZ0cG0gICAgICAg
ICAgIEVuYWJsZSBWaXJ0dWFsIFRydXN0ZWQgUGxhdGZvcm0gTW9kdWxlCisgIC0tZW5hYmxlLXhh
cGkgICAgICAgICAgIEVuYWJsZSBYZW4gQVBJIEJpbmRpbmdzCisgIC0tZGlzYWJsZS1weXRob250
b29scyAgIERpc2FibGUgUHl0aG9uIHRvb2xzCisgIC0tZGlzYWJsZS1vY2FtbHRvb2xzICAgIERp
c2FibGUgT2NhbWwgdG9vbHMKKyAgLS1lbmFibGUtbWluaXRlcm0gICAgICAgRW5hYmxlIG1pbml0
ZXJtCisgIC0tZW5hYmxlLWxvbW91bnQgICAgICAgIEVuYWJsZSBsb21vdW50CisgIC0tZGlzYWJs
ZS1kZWJ1ZyAgICAgICAgIERpc2FibGUgZGVidWcgYnVpbGQgb2YgWGVuIGFuZCB0b29scworCitT
b21lIGluZmx1ZW50aWFsIGVudmlyb25tZW50IHZhcmlhYmxlczoKKyAgQ0MgICAgICAgICAgQyBj
b21waWxlciBjb21tYW5kCisgIENGTEFHUyAgICAgIEMgY29tcGlsZXIgZmxhZ3MKKyAgTERGTEFH
UyAgICAgbGlua2VyIGZsYWdzLCBlLmcuIC1MPGxpYiBkaXI+IGlmIHlvdSBoYXZlIGxpYnJhcmll
cyBpbiBhCisgICAgICAgICAgICAgIG5vbnN0YW5kYXJkIGRpcmVjdG9yeSA8bGliIGRpcj4KKyAg
TElCUyAgICAgICAgbGlicmFyaWVzIHRvIHBhc3MgdG8gdGhlIGxpbmtlciwgZS5nLiAtbDxsaWJy
YXJ5PgorICBDUFBGTEFHUyAgICAoT2JqZWN0aXZlKSBDL0MrKyBwcmVwcm9jZXNzb3IgZmxhZ3Ms
IGUuZy4gLUk8aW5jbHVkZSBkaXI+IGlmCisgICAgICAgICAgICAgIHlvdSBoYXZlIGhlYWRlcnMg
aW4gYSBub25zdGFuZGFyZCBkaXJlY3RvcnkgPGluY2x1ZGUgZGlyPgorICBDUFAgICAgICAgICBD
IHByZXByb2Nlc3NvcgorICBQUkVQRU5EX0lOQ0xVREVTCisgICAgICAgICAgICAgIExpc3Qgb2Yg
aW5jbHVkZSBmb2xkZXJzIHRvIHByZXBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQorICBQUkVQ
RU5EX0xJQiBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBwcmVwZW5kIHRvIExERkxBR1MgKHdp
dGhvdXQgLUwpCisgIEFQUEVORF9JTkNMVURFUworICAgICAgICAgICAgICBMaXN0IG9mIGluY2x1
ZGUgZm9sZGVycyB0byBhcHBlbmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKQorICBBUFBFTkRfTElC
ICBMaXN0IG9mIGxpYnJhcnkgZm9sZGVycyB0byBhcHBlbmQgdG8gTERGTEFHUyAod2l0aG91dCAt
TCkKKyAgUFlUSE9OICAgICAgUGF0aCB0byB0aGUgUHl0aG9uIHBhcnNlcgorICBQRVJMICAgICAg
ICBQYXRoIHRvIFBlcmwgcGFyc2VyCisgIEJSQ1RMICAgICAgIFBhdGggdG8gYnJjdGwgdG9vbAor
ICBJUCAgICAgICAgICBQYXRoIHRvIGlwIHRvb2wKKyAgQklTT04gICAgICAgUGF0aCB0byBCaXNv
biBwYXJzZXIgZ2VuZXJhdG9yCisgIEZMRVggICAgICAgIFBhdGggdG8gRmxleCBsZXhpY2FsIGFu
YWx5c2VyIGdlbmVyYXRvcgorICBDVVJMICAgICAgICBQYXRoIHRvIGN1cmwtY29uZmlnIHRvb2wK
KyAgWE1MICAgICAgICAgUGF0aCB0byB4bWwyLWNvbmZpZyB0b29sCisgIEJBU0ggICAgICAgIFBh
dGggdG8gYmFzaCBzaGVsbAorICBYR0VUVEVYVCAgICBQYXRoIHRvIHhnZXR0dGV4dCB0b29sCisK
K1VzZSB0aGVzZSB2YXJpYWJsZXMgdG8gb3ZlcnJpZGUgdGhlIGNob2ljZXMgbWFkZSBieSBgY29u
ZmlndXJlJyBvciB0byBoZWxwCitpdCB0byBmaW5kIGxpYnJhcmllcyBhbmQgcHJvZ3JhbXMgd2l0
aCBub25zdGFuZGFyZCBuYW1lcy9sb2NhdGlvbnMuCisKK1JlcG9ydCBidWdzIHRvIDx4ZW4tZGV2
ZWxAbGlzdHMueGVuc291cmNlLmNvbT4uCitfQUNFT0YKK2FjX3N0YXR1cz0kPworZmkKKworaWYg
dGVzdCAiJGFjX2luaXRfaGVscCIgPSAicmVjdXJzaXZlIjsgdGhlbgorICAjIElmIHRoZXJlIGFy
ZSBzdWJkaXJzLCByZXBvcnQgdGhlaXIgc3BlY2lmaWMgLS1oZWxwLgorICBmb3IgYWNfZGlyIGlu
IDogJGFjX3N1YmRpcnNfYWxsOyBkbyB0ZXN0ICJ4JGFjX2RpciIgPSB4OiAmJiBjb250aW51ZQor
ICAgIHRlc3QgLWQgIiRhY19kaXIiIHx8CisgICAgICB7IGNkICIkc3JjZGlyIiAmJiBhY19wd2Q9
YHB3ZGAgJiYgc3JjZGlyPS4gJiYgdGVzdCAtZCAiJGFjX2RpciI7IH0gfHwKKyAgICAgIGNvbnRp
bnVlCisgICAgYWNfYnVpbGRkaXI9LgorCitjYXNlICIkYWNfZGlyIiBpbgorLikgYWNfZGlyX3N1
ZmZpeD0gYWNfdG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9wcmVmaXg9IDs7CisqKQor
ICBhY19kaXJfc3VmZml4PS9gJGFzX2VjaG8gIiRhY19kaXIiIHwgc2VkICdzfF5cLltcXC9dfHwn
YAorICAjIEEgIi4uIiBmb3IgZWFjaCBkaXJlY3RvcnkgaW4gJGFjX2Rpcl9zdWZmaXguCisgIGFj
X3RvcF9idWlsZGRpcl9zdWI9YCRhc19lY2hvICIkYWNfZGlyX3N1ZmZpeCIgfCBzZWQgJ3N8L1te
XFwvXSp8Ly4ufGc7c3wvfHwnYAorICBjYXNlICRhY190b3BfYnVpbGRkaXJfc3ViIGluCisgICIi
KSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZpeD0gOzsKKyAgKikgIGFj
X3RvcF9idWlsZF9wcmVmaXg9JGFjX3RvcF9idWlsZGRpcl9zdWIvIDs7CisgIGVzYWMgOzsKK2Vz
YWMKK2FjX2Fic190b3BfYnVpbGRkaXI9JGFjX3B3ZAorYWNfYWJzX2J1aWxkZGlyPSRhY19wd2Qk
YWNfZGlyX3N1ZmZpeAorIyBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eToKK2FjX3RvcF9idWls
ZGRpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeAorCitjYXNlICRzcmNkaXIgaW4KKyAgLikgICMgV2Ug
YXJlIGJ1aWxkaW5nIGluIHBsYWNlLgorICAgIGFjX3NyY2Rpcj0uCisgICAgYWNfdG9wX3NyY2Rp
cj0kYWNfdG9wX2J1aWxkZGlyX3N1YgorICAgIGFjX2Fic190b3Bfc3JjZGlyPSRhY19wd2QgOzsK
KyAgW1xcL10qIHwgPzpbXFwvXSogKSAgIyBBYnNvbHV0ZSBuYW1lLgorICAgIGFjX3NyY2Rpcj0k
c3JjZGlyJGFjX2Rpcl9zdWZmaXg7CisgICAgYWNfdG9wX3NyY2Rpcj0kc3JjZGlyCisgICAgYWNf
YWJzX3RvcF9zcmNkaXI9JHNyY2RpciA7OworICAqKSAjIFJlbGF0aXZlIG5hbWUuCisgICAgYWNf
c3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpciRhY19kaXJfc3VmZml4CisgICAgYWNf
dG9wX3NyY2Rpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIKKyAgICBhY19hYnNfdG9wX3Ny
Y2Rpcj0kYWNfcHdkLyRzcmNkaXIgOzsKK2VzYWMKK2FjX2Fic19zcmNkaXI9JGFjX2Fic190b3Bf
c3JjZGlyJGFjX2Rpcl9zdWZmaXgKKworICAgIGNkICIkYWNfZGlyIiB8fCB7IGFjX3N0YXR1cz0k
PzsgY29udGludWU7IH0KKyAgICAjIENoZWNrIGZvciBndWVzdGVkIGNvbmZpZ3VyZS4KKyAgICBp
ZiB0ZXN0IC1mICIkYWNfc3JjZGlyL2NvbmZpZ3VyZS5nbnUiOyB0aGVuCisgICAgICBlY2hvICYm
CisgICAgICAkU0hFTEwgIiRhY19zcmNkaXIvY29uZmlndXJlLmdudSIgLS1oZWxwPXJlY3Vyc2l2
ZQorICAgIGVsaWYgdGVzdCAtZiAiJGFjX3NyY2Rpci9jb25maWd1cmUiOyB0aGVuCisgICAgICBl
Y2hvICYmCisgICAgICAkU0hFTEwgIiRhY19zcmNkaXIvY29uZmlndXJlIiAtLWhlbHA9cmVjdXJz
aXZlCisgICAgZWxzZQorICAgICAgJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogbm8gY29uZmln
dXJhdGlvbiBpbmZvcm1hdGlvbiBpcyBpbiAkYWNfZGlyIiA+JjIKKyAgICBmaSB8fCBhY19zdGF0
dXM9JD8KKyAgICBjZCAiJGFjX3B3ZCIgfHwgeyBhY19zdGF0dXM9JD87IGJyZWFrOyB9CisgIGRv
bmUKK2ZpCisKK3Rlc3QgLW4gIiRhY19pbml0X2hlbHAiICYmIGV4aXQgJGFjX3N0YXR1cworaWYg
JGFjX2luaXRfdmVyc2lvbjsgdGhlbgorICBjYXQgPDxcX0FDRU9GCitYZW4gSHlwZXJ2aXNvciBj
b25maWd1cmUgNC4yCitnZW5lcmF0ZWQgYnkgR05VIEF1dG9jb25mIDIuNjgKKworQ29weXJpZ2h0
IChDKSAyMDEwIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLgorVGhpcyBjb25maWd1cmUg
c2NyaXB0IGlzIGZyZWUgc29mdHdhcmU7IHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24KK2dp
dmVzIHVubGltaXRlZCBwZXJtaXNzaW9uIHRvIGNvcHksIGRpc3RyaWJ1dGUgYW5kIG1vZGlmeSBp
dC4KK19BQ0VPRgorICBleGl0CitmaQorCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMK
KyMjIEF1dG9jb25mIGluaXRpYWxpemF0aW9uLiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tICMjCisKKyMgYWNfZm5fY190cnlfY29tcGlsZSBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGNvbXBpbGUgY29uZnRlc3QuJGFjX2V4dCwgYW5kIHJldHVy
biB3aGV0aGVyIHRoaXMgc3VjY2VlZGVkLgorYWNfZm5fY190cnlfY29tcGlsZSAoKQoreworICBh
c19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFj
az0kYXNfbGluZW5vX3N0YWNrCisgIHJtIC1mIGNvbmZ0ZXN0LiRhY19vYmpleHQKKyAgaWYgeyB7
IGFjX3RyeT0iJGFjX2NvbXBpbGUiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAq
IHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5
OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2
YWwgIiRhY19jb21waWxlIikgMj5jb25mdGVzdC5lcnIKKyAgYWNfc3RhdHVzPSQ/CisgIGlmIHRl
c3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgZ3JlcCAtdiAnXiAqKycgY29uZnRlc3QuZXJy
ID5jb25mdGVzdC5lcjEKKyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICAgIG12IC1mIGNvbmZ0
ZXN0LmVyMSBjb25mdGVzdC5lcnIKKyAgZmkKKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7
IH0gJiYgeworCSB0ZXN0IC16ICIkYWNfY193ZXJyb3JfZmxhZyIgfHwKKwkgdGVzdCAhIC1zIGNv
bmZ0ZXN0LmVycgorICAgICAgIH0gJiYgdGVzdCAtcyBjb25mdGVzdC4kYWNfb2JqZXh0OyB0aGVu
IDoKKyAgYWNfcmV0dmFsPTAKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVkIHByb2dy
YW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisKKwlhY19y
ZXR2YWw9MQorZmkKKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazor
On0gdW5zZXQgYXNfbGluZW5vCisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZhbAorCit9ICMg
YWNfZm5fY190cnlfY29tcGlsZQorCisjIGFjX2ZuX2NfdHJ5X2NwcCBMSU5FTk8KKyMgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQorIyBUcnkgdG8gcHJlcHJvY2VzcyBjb25mdGVzdC4kYWNfZXh0LCBh
bmQgcmV0dXJuIHdoZXRoZXIgdGhpcyBzdWNjZWVkZWQuCithY19mbl9jX3RyeV9jcHAgKCkKK3sK
KyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9f
c3RhY2s9JGFzX2xpbmVub19zdGFjaworICBpZiB7IHsgYWNfdHJ5PSIkYWNfY3BwIGNvbmZ0ZXN0
LiRhY19leHQiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNf
dHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2
YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9l
Y2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19jcHAg
Y29uZnRlc3QuJGFjX2V4dCIpIDI+Y29uZnRlc3QuZXJyCisgIGFjX3N0YXR1cz0kPworICBpZiB0
ZXN0IC1zIGNvbmZ0ZXN0LmVycjsgdGhlbgorICAgIGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0LmVy
ciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgICBtdiAtZiBjb25m
dGVzdC5lcjEgY29uZnRlc3QuZXJyCisgIGZpCisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFwkPyA9ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAw
OyB9ID4gY29uZnRlc3QuaSAmJiB7CisJIHRlc3QgLXogIiRhY19jX3ByZXByb2Nfd2Fybl9mbGFn
JGFjX2Nfd2Vycm9yX2ZsYWciIHx8CisJIHRlc3QgISAtcyBjb25mdGVzdC5lcnIKKyAgICAgICB9
OyB0aGVuIDoKKyAgYWNfcmV0dmFsPTAKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFpbGVk
IHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1CisK
KyAgICBhY19yZXR2YWw9MQorZmkKKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVu
b19zdGFjazorOn0gdW5zZXQgYXNfbGluZW5vCisgIGFzX2ZuX3NldF9zdGF0dXMgJGFjX3JldHZh
bAorCit9ICMgYWNfZm5fY190cnlfY3BwCisKKyMgYWNfZm5fY19jaGVja19oZWFkZXJfbW9uZ3Jl
bCBMSU5FTk8gSEVBREVSIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgSEVBREVSIGV4
aXN0cywgZ2l2aW5nIGEgd2FybmluZyBpZiBpdCBjYW5ub3QgYmUgY29tcGlsZWQgdXNpbmcKKyMg
dGhlIGluY2x1ZGUgZmlsZXMgaW4gSU5DTFVERVMgYW5kIHNldHRpbmcgdGhlIGNhY2hlIHZhcmlh
YmxlIFZBUgorIyBhY2NvcmRpbmdseS4KK2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgKCkK
K3sKKyAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5l
bm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICBpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVu
IDoKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2OyB9CitpZiBl
dmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+
JjY7IH0KK2Vsc2UKKyAgIyBJcyB0aGUgaGVhZGVyIGNvbXBpbGFibGU/Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nICQyIHVzYWJpbGl0eSIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyAkMiB1c2FiaWxpdHkuLi4gIiA+JjY7IH0KK2NhdCBjb25mZGVm
cy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8K
KyQ0CisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfaGVhZGVyX2NvbXBpbGVyPXllcworZWxzZQorICBhY19oZWFkZXJf
Y29tcGlsZXI9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2Jq
ZXh0IGNvbmZ0ZXN0LiRhY19leHQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfaGVhZGVyX2NvbXBpbGVyIiA+JjUKKyRhc19lY2hvICIkYWNfaGVh
ZGVyX2NvbXBpbGVyIiA+JjY7IH0KKworIyBJcyB0aGUgaGVhZGVyIHByZXNlbnQ/Cit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nICQyIHByZXNlbmNlIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nICQyIHByZXNlbmNlLi4uICIgPiY2OyB9CitjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisjaW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NwcCAiJExJTkVOTyI7
IHRoZW4gOgorICBhY19oZWFkZXJfcHJlcHJvYz15ZXMKK2Vsc2UKKyAgYWNfaGVhZGVyX3ByZXBy
b2M9bm8KK2ZpCitybSAtZiBjb25mdGVzdC5lcnIgY29uZnRlc3QuaSBjb25mdGVzdC4kYWNfZXh0
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2hl
YWRlcl9wcmVwcm9jIiA+JjUKKyRhc19lY2hvICIkYWNfaGVhZGVyX3ByZXByb2MiID4mNjsgfQor
CisjIFNvPyAgV2hhdCBhYm91dCB0aGlzIGhlYWRlcj8KK2Nhc2UgJGFjX2hlYWRlcl9jb21waWxl
cjokYWNfaGVhZGVyX3ByZXByb2M6JGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gIygoCisgIHll
czpubzogKQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogJDI6IGFjY2VwdGVkIGJ5IHRoZSBjb21waWxlciwgcmVqZWN0ZWQgYnkgdGhlIHByZXBy
b2Nlc3NvciEiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IGFjY2VwdGVkIGJ5
IHRoZSBjb21waWxlciwgcmVqZWN0ZWQgYnkgdGhlIHByZXByb2Nlc3NvciEiID4mMjt9CisgICAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkMjogcHJv
Y2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBXQVJOSU5HOiAkMjogcHJvY2VlZGluZyB3aXRoIHRoZSBjb21waWxlcidzIHJlc3VsdCIgPiYy
O30KKyAgICA7OworICBubzp5ZXM6KiApCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkMjogcHJlc2VudCBidXQgY2Fubm90IGJlIGNvbXBpbGVk
IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6ICQyOiBwcmVzZW50IGJ1dCBjYW5ub3Qg
YmUgY29tcGlsZWQiID4mMjt9CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBXQVJOSU5HOiAkMjogICAgIGNoZWNrIGZvciBtaXNzaW5nIHByZXJlcXVpc2l0ZSBo
ZWFkZXJzPyIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkMjogICAgIGNoZWNrIGZv
ciBtaXNzaW5nIHByZXJlcXVpc2l0ZSBoZWFkZXJzPyIgPiYyO30KKyAgICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiBzZWUgdGhlIEF1dG9jb25m
IGRvY3VtZW50YXRpb24iID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogJDI6IHNlZSB0
aGUgQXV0b2NvbmYgZG9jdW1lbnRhdGlvbiIgPiYyO30KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICQyOiAgICAgc2VjdGlvbiBcIlByZXNlbnQg
QnV0IENhbm5vdCBCZSBDb21waWxlZFwiIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6
ICQyOiAgICAgc2VjdGlvbiBcIlByZXNlbnQgQnV0IENhbm5vdCBCZSBDb21waWxlZFwiIiA+JjI7
fQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzog
JDI6IHByb2NlZWRpbmcgd2l0aCB0aGUgY29tcGlsZXIncyByZXN1bHQiID4mNQorJGFzX2VjaG8g
IiRhc19tZTogV0FSTklORzogJDI6IHByb2NlZWRpbmcgd2l0aCB0aGUgY29tcGlsZXIncyByZXN1
bHQiID4mMjt9CisoICRhc19lY2hvICIjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLSAjIworIyMgUmVwb3J0IHRoaXMgdG8geGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tICMjIgorICAgICApIHwgc2VkICJzL14vJGFzX21lOiBXQVJOSU5HOiAgICAgLyIgPiYyCisg
ICAgOzsKK2VzYWMKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBj
aGVja2luZyBmb3IgJDIiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICQyLi4uICIgPiY2
OyB9CitpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgZXZhbCAiJDM9XCRhY19oZWFkZXJfY29tcGlsZXIiCitmaQorZXZh
bCBhY19yZXM9XCQkMworCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9Citm
aQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBh
c19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwKKworIyBhY19mbl9j
X3RyeV9ydW4gTElORU5PCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGxpbmsg
Y29uZnRlc3QuJGFjX2V4dCwgYW5kIHJldHVybiB3aGV0aGVyIHRoaXMgc3VjY2VlZGVkLiBBc3N1
bWVzCisjIHRoYXQgZXhlY3V0YWJsZXMgKmNhbiogYmUgcnVuLgorYWNfZm5fY190cnlfcnVuICgp
Cit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGlu
ZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgaWYgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCitj
YXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRh
Y190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2Vj
aG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNf
ZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQorICBh
Y19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/
ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0gJiYgeyBhY190cnk9
Jy4vY29uZnRlc3QkYWNfZXhlZXh0JworICB7IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIq
IHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89
JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1
CisgIChldmFsICIkYWNfdHJ5IikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3Qg
JGFjX3N0YXR1cyA9IDA7IH07IH07IHRoZW4gOgorICBhY19yZXR2YWw9MAorZWxzZQorICAkYXNf
ZWNobyAiJGFzX21lOiBwcm9ncmFtIGV4aXRlZCB3aXRoIHN0YXR1cyAkYWNfc3RhdHVzIiA+JjUK
KyAgICAgICAkYXNfZWNobyAiJGFzX21lOiBmYWlsZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAn
cy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUKKworICAgICAgIGFjX3JldHZhbD0kYWNfc3Rh
dHVzCitmaQorICBybSAtcmYgY29uZnRlc3QuZFNZTSBjb25mdGVzdF9pcGE4X2NvbmZ0ZXN0Lm9v
CisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFz
X2xpbmVubworICBhc19mbl9zZXRfc3RhdHVzICRhY19yZXR2YWwKKworfSAjIGFjX2ZuX2NfdHJ5
X3J1bgorCisjIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX2NvbXBpbGUgTElORU5PIEhFQURFUiBWQVIg
SU5DTFVERVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQorIyBUZXN0cyB3aGV0aGVyIEhFQURFUiBleGlzdHMgYW5kIGNhbiBiZSBjb21w
aWxlZCB1c2luZyB0aGUgaW5jbHVkZSBmaWxlcyBpbgorIyBJTkNMVURFUywgc2V0dGluZyB0aGUg
Y2FjaGUgdmFyaWFibGUgVkFSIGFjY29yZGluZ2x5LgorYWNfZm5fY19jaGVja19oZWFkZXJfY29t
cGlsZSAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNr
PWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNo
ZWNraW5nIGZvciAkMi4uLiAiID4mNjsgfQoraWYgZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6
CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyQ0Cisj
aW5jbHVkZSA8JDI+CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgZXZhbCAiJDM9eWVzIgorZWxzZQorICBldmFsICIkMz1ubyIKK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2Zp
CitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVzIiA+JjY7
IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0gdW5zZXQg
YXNfbGluZW5vCisKK30gIyBhY19mbl9jX2NoZWNrX2hlYWRlcl9jb21waWxlCisKKyMgYWNfZm5f
Y190cnlfbGluayBMSU5FTk8KKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKyMgVHJ5IHRvIGxp
bmsgY29uZnRlc3QuJGFjX2V4dCwgYW5kIHJldHVybiB3aGV0aGVyIHRoaXMgc3VjY2VlZGVkLgor
YWNfZm5fY190cnlfbGluayAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8tIiQxIn0gYXNf
bGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisgIHJtIC1mIGNv
bmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QkYWNfZXhlZXh0CisgIGlmIHsgeyBhY190cnk9IiRh
Y19saW5rIgorY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3Ry
eV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFs
IGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNo
b1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfbGluayIp
IDI+Y29uZnRlc3QuZXJyCisgIGFjX3N0YXR1cz0kPworICBpZiB0ZXN0IC1zIGNvbmZ0ZXN0LmVy
cjsgdGhlbgorICAgIGdyZXAgLXYgJ14gKisnIGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisg
ICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAgICBtdiAtZiBjb25mdGVzdC5lcjEgY29uZnRlc3Qu
ZXJyCisgIGZpCisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9
ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9ICYmIHsKKwkgdGVzdCAt
eiAiJGFjX2Nfd2Vycm9yX2ZsYWciIHx8CisJIHRlc3QgISAtcyBjb25mdGVzdC5lcnIKKyAgICAg
ICB9ICYmIHRlc3QgLXMgY29uZnRlc3QkYWNfZXhlZXh0ICYmIHsKKwkgdGVzdCAiJGNyb3NzX2Nv
bXBpbGluZyIgPSB5ZXMgfHwKKwkgJGFzX3Rlc3RfeCBjb25mdGVzdCRhY19leGVleHQKKyAgICAg
ICB9OyB0aGVuIDoKKyAgYWNfcmV0dmFsPTAKK2Vsc2UKKyAgJGFzX2VjaG8gIiRhc19tZTogZmFp
bGVkIHByb2dyYW0gd2FzOiIgPiY1CitzZWQgJ3MvXi98IC8nIGNvbmZ0ZXN0LiRhY19leHQgPiY1
CisKKwlhY19yZXR2YWw9MQorZmkKKyAgIyBEZWxldGUgdGhlIElQQS9JUE8gKEludGVyIFByb2Nl
ZHVyYWwgQW5hbHlzaXMvT3B0aW1pemF0aW9uKSBpbmZvcm1hdGlvbgorICAjIGNyZWF0ZWQgYnkg
dGhlIFBHSSBjb21waWxlciAoY29uZnRlc3RfaXBhOF9jb25mdGVzdC5vbyksIGFzIGl0IHdvdWxk
CisgICMgaW50ZXJmZXJlIHdpdGggdGhlIG5leHQgbGluayBjb21tYW5kOyBhbHNvIGRlbGV0ZSBh
IGRpcmVjdG9yeSB0aGF0IGlzCisgICMgbGVmdCBiZWhpbmQgYnkgQXBwbGUncyBjb21waWxlci4g
IFdlIGRvIHRoaXMgYmVmb3JlIGV4ZWN1dGluZyB0aGUgYWN0aW9ucy4KKyAgcm0gLXJmIGNvbmZ0
ZXN0LmRTWU0gY29uZnRlc3RfaXBhOF9jb25mdGVzdC5vbworICBldmFsICRhc19saW5lbm9fc3Rh
Y2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKyAgYXNfZm5fc2V0X3N0
YXR1cyAkYWNfcmV0dmFsCisKK30gIyBhY19mbl9jX3RyeV9saW5rCisKKyMgYWNfZm5fY19jaGVj
a190eXBlIExJTkVOTyBUWVBFIFZBUiBJTkNMVURFUworIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIFRlc3RzIHdoZXRoZXIgVFlQRSBleGlzdHMgYWZ0ZXIg
aGF2aW5nIGluY2x1ZGVkIElOQ0xVREVTLCBzZXR0aW5nIGNhY2hlCisjIHZhcmlhYmxlIFZBUiBh
Y2NvcmRpbmdseS4KK2FjX2ZuX2NfY2hlY2tfdHlwZSAoKQoreworICBhc19saW5lbm89JHthc19s
aW5lbm8tIiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0
YWNrCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcg
Zm9yICQyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkMi4uLiAiID4mNjsgfQoraWYg
ZXZhbCBcJHskMys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGV2YWwgIiQzPW5vIgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25m
dGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskNAoraW50CittYWluICgpCit7
CitpZiAoc2l6ZW9mICgkMikpCisJIHJldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FD
RU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGNhdCBjb25m
ZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAg
Ki8KKyQ0CitpbnQKK21haW4gKCkKK3sKK2lmIChzaXplb2YgKCgkMikpKQorCSAgICByZXR1cm4g
MDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAi
JExJTkVOTyI7IHRoZW4gOgorCitlbHNlCisgIGV2YWwgIiQzPXllcyIKK2ZpCitybSAtZiBjb3Jl
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCity
bSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19l
eHQKK2ZpCitldmFsIGFjX3Jlcz1cJCQzCisJICAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfcmVzIiA+JjUKKyRhc19lY2hvICIkYWNfcmVz
IiA+JjY7IH0KKyAgZXZhbCAkYXNfbGluZW5vX3N0YWNrOyAke2FzX2xpbmVub19zdGFjazorOn0g
dW5zZXQgYXNfbGluZW5vCisKK30gIyBhY19mbl9jX2NoZWNrX3R5cGUKKworIyBhY19mbl9jX2No
ZWNrX2Z1bmMgTElORU5PIEZVTkMgVkFSCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KKyMgVGVzdHMgd2hldGhlciBGVU5DIGV4aXN0cywgc2V0dGluZyB0aGUgY2FjaGUgdmFy
aWFibGUgVkFSIGFjY29yZGluZ2x5CithY19mbl9jX2NoZWNrX2Z1bmMgKCkKK3sKKyAgYXNfbGlu
ZW5vPSR7YXNfbGluZW5vLSIkMSJ9IGFzX2xpbmVub19zdGFjaz1hc19saW5lbm9fc3RhY2s9JGFz
X2xpbmVub19zdGFjaworICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciAkMiIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJDIuLi4gIiA+
JjY7IH0KK2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4k
YWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisvKiBEZWZpbmUgJDIgdG8gYW4gaW5ub2N1
b3VzIHZhcmlhbnQsIGluIGNhc2UgPGxpbWl0cy5oPiBkZWNsYXJlcyAkMi4KKyAgIEZvciBleGFt
cGxlLCBIUC1VWCAxMWkgPGxpbWl0cy5oPiBkZWNsYXJlcyBnZXR0aW1lb2ZkYXkuICAqLworI2Rl
ZmluZSAkMiBpbm5vY3VvdXNfJDIKKworLyogU3lzdGVtIGhlYWRlciB0byBkZWZpbmUgX19zdHVi
IG1hY3JvcyBhbmQgaG9wZWZ1bGx5IGZldyBwcm90b3R5cGVzLAorICAgIHdoaWNoIGNhbiBjb25m
bGljdCB3aXRoIGNoYXIgJDIgKCk7IGJlbG93LgorICAgIFByZWZlciA8bGltaXRzLmg+IHRvIDxh
c3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgICA8bGltaXRzLmg+IGV4
aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuICAqLworCisjaWZkZWYgX19TVERD
X18KKyMgaW5jbHVkZSA8bGltaXRzLmg+CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNl
bmRpZgorCisjdW5kZWYgJDIKKworLyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5
cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRj
aCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3Vt
ZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMK
K2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciAkMiAoKTsKKy8qIFRoZSBHTlUgQyBsaWJyYXJ5IGRl
ZmluZXMgdGhpcyBmb3IgZnVuY3Rpb25zIHdoaWNoIGl0IGltcGxlbWVudHMKKyAgICB0byBhbHdh
eXMgZmFpbCB3aXRoIEVOT1NZUy4gIFNvbWUgZnVuY3Rpb25zIGFyZSBhY3R1YWxseSBuYW1lZAor
ICAgIHNvbWV0aGluZyBzdGFydGluZyB3aXRoIF9fIGFuZCB0aGUgbm9ybWFsIG5hbWUgaXMgYW4g
YWxpYXMuICAqLworI2lmIGRlZmluZWQgX19zdHViXyQyIHx8IGRlZmluZWQgX19zdHViX19fJDIK
K2Nob2tlIG1lCisjZW5kaWYKKworaW50CittYWluICgpCit7CityZXR1cm4gJDIgKCk7CisgIDsK
KyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0
aGVuIDoKKyAgZXZhbCAiJDM9eWVzIgorZWxzZQorICBldmFsICIkMz1ubyIKK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK2V2YWwgYWNfcmVzPVwkJDMKKwkgICAgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19yZXMiID4m
NQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQorICBldmFsICRhc19saW5lbm9fc3RhY2s7ICR7
YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKworfSAjIGFjX2ZuX2NfY2hlY2tf
ZnVuYworCisjIGFjX2ZuX2NfZmluZF9pbnRYX3QgTElORU5PIEJJVFMgVkFSCisjIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIEZpbmRzIGEgc2lnbmVkIGludGVnZXIgdHlw
ZSB3aXRoIHdpZHRoIEJJVFMsIHNldHRpbmcgY2FjaGUgdmFyaWFibGUgVkFSCisjIGFjY29yZGlu
Z2x5LgorYWNfZm5fY19maW5kX2ludFhfdCAoKQoreworICBhc19saW5lbm89JHthc19saW5lbm8t
IiQxIn0gYXNfbGluZW5vX3N0YWNrPWFzX2xpbmVub19zdGFjaz0kYXNfbGluZW5vX3N0YWNrCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGlu
dCQyX3QiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGludCQyX3QuLi4gIiA+JjY7IH0K
K2lmIGV2YWwgXCR7JDMrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBldmFsICIkMz1ubyIKKyAgICAgIyBPcmRlciBpcyBpbXBvcnRhbnQgLSBu
ZXZlciBjaGVjayBhIHR5cGUgdGhhdCBpcyBwb3RlbnRpYWxseSBzbWFsbGVyCisgICAgICMgdGhh
biBoYWxmIG9mIHRoZSBleHBlY3RlZCB0YXJnZXQgd2lkdGguCisgICAgIGZvciBhY190eXBlIGlu
IGludCQyX3QgJ2ludCcgJ2xvbmcgaW50JyBcCisJICdsb25nIGxvbmcgaW50JyAnc2hvcnQgaW50
JyAnc2lnbmVkIGNoYXInOyBkbworICAgICAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZh
dWx0CisJICAgICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKK2ludAorbWFpbiAoKQoreworc3Rh
dGljIGludCB0ZXN0X2FycmF5IFsxIC0gMiAqICEoMCA8ICgkYWNfdHlwZSkgKCgoKCgkYWNfdHlw
ZSkgMSA8PCBOKSA8PCBOKSAtIDEpICogMiArIDEpKV07Cit0ZXN0X2FycmF5IFswXSA9IDAKKwor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19l
eHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisJICAgICAg
ICBlbnVtIHsgTiA9ICQyIC8gMiAtIDEgfTsKK2ludAorbWFpbiAoKQoreworc3RhdGljIGludCB0
ZXN0X2FycmF5IFsxIC0gMiAqICEoKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAxIDw8IE4pIDw8
IE4pIC0gMSkgKiAyICsgMSkKKwkJIDwgKCRhY190eXBlKSAoKCgoKCRhY190eXBlKSAxIDw8IE4p
IDw8IE4pIC0gMSkgKiAyICsgMikpXTsKK3Rlc3RfYXJyYXkgWzBdID0gMAorCisgIDsKKyAgcmV0
dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVu
IDoKKworZWxzZQorICBjYXNlICRhY190eXBlIGluICMoCisgIGludCQyX3QpIDoKKyAgICBldmFs
ICIkMz15ZXMiIDs7ICMoCisgICopIDoKKyAgICBldmFsICIkMz1cJGFjX3R5cGUiIDs7Citlc2Fj
CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVz
dC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CisgICAgICAgaWYgZXZhbCB0ZXN0IFwieFwkIiQzIlwiID0geCJu
byI7IHRoZW4gOgorCitlbHNlCisgIGJyZWFrCitmaQorICAgICBkb25lCitmaQorZXZhbCBhY19y
ZXM9XCQkMworCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFjX3JlcyIgPiY2OyB9CisgIGV2YWwg
JGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6Kzp9IHVuc2V0IGFzX2xpbmVubwor
Cit9ICMgYWNfZm5fY19maW5kX2ludFhfdAorCisjIGFjX2ZuX2NfY2hlY2tfbWVtYmVyIExJTkVO
TyBBR0dSIE1FTUJFUiBWQVIgSU5DTFVERVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBUcmllcyB0byBmaW5kIGlmIHRoZSBmaWVsZCBN
RU1CRVIgZXhpc3RzIGluIHR5cGUgQUdHUiwgYWZ0ZXIgaW5jbHVkaW5nCisjIElOQ0xVREVTLCBz
ZXR0aW5nIGNhY2hlIHZhcmlhYmxlIFZBUiBhY2NvcmRpbmdseS4KK2FjX2ZuX2NfY2hlY2tfbWVt
YmVyICgpCit7CisgIGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9
YXNfbGluZW5vX3N0YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJDIuJDMiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICQyLiQzLi4uICIgPiY2OyB9CitpZiBldmFsIFwkeyQ0Kzp9IGZhbHNlOyB0
aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
JDUKK2ludAorbWFpbiAoKQoreworc3RhdGljICQyIGFjX2FnZ3I7CitpZiAoYWNfYWdnci4kMykK
K3JldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9j
b21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGV2YWwgIiQ0PXllcyIKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworJDUKK2ludAorbWFpbiAoKQoreworc3RhdGljICQyIGFjX2FnZ3I7CitpZiAoc2l6ZW9m
IGFjX2FnZ3IuJDMpCityZXR1cm4gMDsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYg
YWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBldmFsICIkND15ZXMiCitl
bHNlCisgIGV2YWwgIiQ0PW5vIgorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0
LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK2V2YWwgYWNfcmVzPVwk
JDQKKwkgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19yZXMiID4mNQorJGFzX2VjaG8gIiRhY19yZXMiID4mNjsgfQorICBldmFsICRhc19s
aW5lbm9fc3RhY2s7ICR7YXNfbGluZW5vX3N0YWNrOis6fSB1bnNldCBhc19saW5lbm8KKworfSAj
IGFjX2ZuX2NfY2hlY2tfbWVtYmVyCisKKyMgYWNfZm5fY19maW5kX3VpbnRYX3QgTElORU5PIEJJ
VFMgVkFSCisjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQorIyBGaW5kcyBh
biB1bnNpZ25lZCBpbnRlZ2VyIHR5cGUgd2l0aCB3aWR0aCBCSVRTLCBzZXR0aW5nIGNhY2hlIHZh
cmlhYmxlIFZBUgorIyBhY2NvcmRpbmdseS4KK2FjX2ZuX2NfZmluZF91aW50WF90ICgpCit7Cisg
IGFzX2xpbmVubz0ke2FzX2xpbmVuby0iJDEifSBhc19saW5lbm9fc3RhY2s9YXNfbGluZW5vX3N0
YWNrPSRhc19saW5lbm9fc3RhY2sKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgdWludCQyX3QiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHVpbnQkMl90Li4uICIgPiY2OyB9CitpZiBldmFsIFwkeyQzKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgZXZhbCAiJDM9bm8iCisgICAg
ICMgT3JkZXIgaXMgaW1wb3J0YW50IC0gbmV2ZXIgY2hlY2sgYSB0eXBlIHRoYXQgaXMgcG90ZW50
aWFsbHkgc21hbGxlcgorICAgICAjIHRoYW4gaGFsZiBvZiB0aGUgZXhwZWN0ZWQgdGFyZ2V0IHdp
ZHRoLgorICAgICBmb3IgYWNfdHlwZSBpbiB1aW50JDJfdCAndW5zaWduZWQgaW50JyAndW5zaWdu
ZWQgbG9uZyBpbnQnIFwKKwkgJ3Vuc2lnbmVkIGxvbmcgbG9uZyBpbnQnICd1bnNpZ25lZCBzaG9y
dCBpbnQnICd1bnNpZ25lZCBjaGFyJzsgZG8KKyAgICAgICBjYXQgY29uZmRlZnMuaCAtIDw8X0FD
RU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVk
ZXNfZGVmYXVsdAoraW50CittYWluICgpCit7CitzdGF0aWMgaW50IHRlc3RfYXJyYXkgWzEgLSAy
ICogISgoKCRhY190eXBlKSAtMSA+PiAoJDIgLyAyIC0gMSkpID4+ICgkMiAvIDIgLSAxKSA9PSAz
KV07Cit0ZXN0X2FycmF5IFswXSA9IDAKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGNhc2UgJGFjX3R5cGUg
aW4gIygKKyAgdWludCQyX3QpIDoKKyAgICBldmFsICIkMz15ZXMiIDs7ICMoCisgICopIDoKKyAg
ICBldmFsICIkMz1cJGFjX3R5cGUiIDs7Citlc2FjCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5l
cnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICAgICAgaWYgZXZhbCB0
ZXN0IFwieFwkIiQzIlwiID0geCJubyI7IHRoZW4gOgorCitlbHNlCisgIGJyZWFrCitmaQorICAg
ICBkb25lCitmaQorZXZhbCBhY19yZXM9XCQkMworCSAgICAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX3JlcyIgPiY1CiskYXNfZWNobyAiJGFj
X3JlcyIgPiY2OyB9CisgIGV2YWwgJGFzX2xpbmVub19zdGFjazsgJHthc19saW5lbm9fc3RhY2s6
Kzp9IHVuc2V0IGFzX2xpbmVubworCit9ICMgYWNfZm5fY19maW5kX3VpbnRYX3QKK2NhdCA+Y29u
ZmlnLmxvZyA8PF9BQ0VPRgorVGhpcyBmaWxlIGNvbnRhaW5zIGFueSBtZXNzYWdlcyBwcm9kdWNl
ZCBieSBjb21waWxlcnMgd2hpbGUKK3J1bm5pbmcgY29uZmlndXJlLCB0byBhaWQgZGVidWdnaW5n
IGlmIGNvbmZpZ3VyZSBtYWtlcyBhIG1pc3Rha2UuCisKK0l0IHdhcyBjcmVhdGVkIGJ5IFhlbiBI
eXBlcnZpc29yICRhc19tZSA0LjIsIHdoaWNoIHdhcworZ2VuZXJhdGVkIGJ5IEdOVSBBdXRvY29u
ZiAyLjY4LiAgSW52b2NhdGlvbiBjb21tYW5kIGxpbmUgd2FzCisKKyAgJCAkMCAkQAorCitfQUNF
T0YKK2V4ZWMgNT4+Y29uZmlnLmxvZworeworY2F0IDw8X0FTVU5BTUUKKyMjIC0tLS0tLS0tLSAj
IworIyMgUGxhdGZvcm0uICMjCisjIyAtLS0tLS0tLS0gIyMKKworaG9zdG5hbWUgPSBgKGhvc3Ru
YW1lIHx8IHVuYW1lIC1uKSAyPi9kZXYvbnVsbCB8IHNlZCAxcWAKK3VuYW1lIC1tID0gYCh1bmFt
ZSAtbSkgMj4vZGV2L251bGwgfHwgZWNobyB1bmtub3duYAordW5hbWUgLXIgPSBgKHVuYW1lIC1y
KSAyPi9kZXYvbnVsbCB8fCBlY2hvIHVua25vd25gCit1bmFtZSAtcyA9IGAodW5hbWUgLXMpIDI+
L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKK3VuYW1lIC12ID0gYCh1bmFtZSAtdikgMj4vZGV2
L251bGwgfHwgZWNobyB1bmtub3duYAorCisvdXNyL2Jpbi91bmFtZSAtcCA9IGAoL3Vzci9iaW4v
dW5hbWUgLXApIDI+L2Rldi9udWxsIHx8IGVjaG8gdW5rbm93bmAKKy9iaW4vdW5hbWUgLVggICAg
ID0gYCgvYmluL3VuYW1lIC1YKSAyPi9kZXYvbnVsbCAgICAgfHwgZWNobyB1bmtub3duYAorCisv
YmluL2FyY2ggICAgICAgICAgICAgID0gYCgvYmluL2FyY2gpIDI+L2Rldi9udWxsICAgICAgICAg
ICAgICB8fCBlY2hvIHVua25vd25gCisvdXNyL2Jpbi9hcmNoIC1rICAgICAgID0gYCgvdXNyL2Jp
bi9hcmNoIC1rKSAyPi9kZXYvbnVsbCAgICAgICB8fCBlY2hvIHVua25vd25gCisvdXNyL2NvbnZl
eC9nZXRzeXNpbmZvID0gYCgvdXNyL2NvbnZleC9nZXRzeXNpbmZvKSAyPi9kZXYvbnVsbCB8fCBl
Y2hvIHVua25vd25gCisvdXNyL2Jpbi9ob3N0aW5mbyAgICAgID0gYCgvdXNyL2Jpbi9ob3N0aW5m
bykgMj4vZGV2L251bGwgICAgICB8fCBlY2hvIHVua25vd25gCisvYmluL21hY2hpbmUgICAgICAg
ICAgID0gYCgvYmluL21hY2hpbmUpIDI+L2Rldi9udWxsICAgICAgICAgICB8fCBlY2hvIHVua25v
d25gCisvdXNyL2Jpbi9vc2xldmVsICAgICAgID0gYCgvdXNyL2Jpbi9vc2xldmVsKSAyPi9kZXYv
bnVsbCAgICAgICB8fCBlY2hvIHVua25vd25gCisvYmluL3VuaXZlcnNlICAgICAgICAgID0gYCgv
YmluL3VuaXZlcnNlKSAyPi9kZXYvbnVsbCAgICAgICAgICB8fCBlY2hvIHVua25vd25gCisKK19B
U1VOQU1FCisKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICAkYXNfZWNobyAiUEFUSDogJGFzX2RpciIKKyAgZG9uZQorSUZTPSRh
c19zYXZlX0lGUworCit9ID4mNQorCitjYXQgPiY1IDw8X0FDRU9GCisKKworIyMgLS0tLS0tLS0t
LS0gIyMKKyMjIENvcmUgdGVzdHMuICMjCisjIyAtLS0tLS0tLS0tLSAjIworCitfQUNFT0YKKwor
CisjIEtlZXAgYSB0cmFjZSBvZiB0aGUgY29tbWFuZCBsaW5lLgorIyBTdHJpcCBvdXQgLS1uby1j
cmVhdGUgYW5kIC0tbm8tcmVjdXJzaW9uIHNvIHRoZXkgZG8gbm90IHBpbGUgdXAuCisjIFN0cmlw
IG91dCAtLXNpbGVudCBiZWNhdXNlIHdlIGRvbid0IHdhbnQgdG8gcmVjb3JkIGl0IGZvciBmdXR1
cmUgcnVucy4KKyMgQWxzbyBxdW90ZSBhbnkgYXJncyBjb250YWluaW5nIHNoZWxsIG1ldGEtY2hh
cmFjdGVycy4KKyMgTWFrZSB0d28gcGFzc2VzIHRvIGFsbG93IGZvciBwcm9wZXIgZHVwbGljYXRl
LWFyZ3VtZW50IHN1cHByZXNzaW9uLgorYWNfY29uZmlndXJlX2FyZ3M9CithY19jb25maWd1cmVf
YXJnczA9CithY19jb25maWd1cmVfYXJnczE9CithY19tdXN0X2tlZXBfbmV4dD1mYWxzZQorZm9y
IGFjX3Bhc3MgaW4gMSAyCitkbworICBmb3IgYWNfYXJnCisgIGRvCisgICAgY2FzZSAkYWNfYXJn
IGluCisgICAgLW5vLWNyZWF0ZSB8IC0tbm8tYyogfCAtbiB8IC1uby1yZWN1cnNpb24gfCAtLW5v
LXIqKSBjb250aW51ZSA7OworICAgIC1xIHwgLXF1aWV0IHwgLS1xdWlldCB8IC0tcXVpZSB8IC0t
cXVpIHwgLS1xdSB8IC0tcSBcCisgICAgfCAtc2lsZW50IHwgLS1zaWxlbnQgfCAtLXNpbGVuIHwg
LS1zaWxlIHwgLS1zaWwpCisgICAgICBjb250aW51ZSA7OworICAgICpcJyopCisgICAgICBhY19h
cmc9YCRhc19lY2hvICIkYWNfYXJnIiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYCA7OworICAg
IGVzYWMKKyAgICBjYXNlICRhY19wYXNzIGluCisgICAgMSkgYXNfZm5fYXBwZW5kIGFjX2NvbmZp
Z3VyZV9hcmdzMCAiICckYWNfYXJnJyIgOzsKKyAgICAyKQorICAgICAgYXNfZm5fYXBwZW5kIGFj
X2NvbmZpZ3VyZV9hcmdzMSAiICckYWNfYXJnJyIKKyAgICAgIGlmIHRlc3QgJGFjX211c3Rfa2Vl
cF9uZXh0ID0gdHJ1ZTsgdGhlbgorCWFjX211c3Rfa2VlcF9uZXh0PWZhbHNlICMgR290IHZhbHVl
LCBiYWNrIHRvIG5vcm1hbC4KKyAgICAgIGVsc2UKKwljYXNlICRhY19hcmcgaW4KKwkgICo9KiB8
IC0tY29uZmlnLWNhY2hlIHwgLUMgfCAtZGlzYWJsZS0qIHwgLS1kaXNhYmxlLSogXAorCSAgfCAt
ZW5hYmxlLSogfCAtLWVuYWJsZS0qIHwgLWdhcyB8IC0tZyogfCAtbmZwIHwgLS1uZiogXAorCSAg
fCAtcSB8IC1xdWlldCB8IC0tcSogfCAtc2lsZW50IHwgLS1zaWwqIHwgLXYgfCAtdmVyYiogXAor
CSAgfCAtd2l0aC0qIHwgLS13aXRoLSogfCAtd2l0aG91dC0qIHwgLS13aXRob3V0LSogfCAtLXgp
CisJICAgIGNhc2UgIiRhY19jb25maWd1cmVfYXJnczAgIiBpbgorCSAgICAgICIkYWNfY29uZmln
dXJlX2FyZ3MxIioiICckYWNfYXJnJyAiKiApIGNvbnRpbnVlIDs7CisJICAgIGVzYWMKKwkgICAg
OzsKKwkgIC0qICkgYWNfbXVzdF9rZWVwX25leHQ9dHJ1ZSA7OworCWVzYWMKKyAgICAgIGZpCisg
ICAgICBhc19mbl9hcHBlbmQgYWNfY29uZmlndXJlX2FyZ3MgIiAnJGFjX2FyZyciCisgICAgICA7
OworICAgIGVzYWMKKyAgZG9uZQorZG9uZQoreyBhY19jb25maWd1cmVfYXJnczA9OyB1bnNldCBh
Y19jb25maWd1cmVfYXJnczA7fQoreyBhY19jb25maWd1cmVfYXJnczE9OyB1bnNldCBhY19jb25m
aWd1cmVfYXJnczE7fQorCisjIFdoZW4gaW50ZXJydXB0ZWQgb3IgZXhpdCdkLCBjbGVhbnVwIHRl
bXBvcmFyeSBmaWxlcywgYW5kIGNvbXBsZXRlCisjIGNvbmZpZy5sb2cuICBXZSByZW1vdmUgY29t
bWVudHMgYmVjYXVzZSBhbnl3YXkgdGhlIHF1b3RlcyBpbiB0aGVyZQorIyB3b3VsZCBjYXVzZSBw
cm9ibGVtcyBvciBsb29rIHVnbHkuCisjIFdBUk5JTkc6IFVzZSAnXCcnIHRvIHJlcHJlc2VudCBh
biBhcG9zdHJvcGhlIHdpdGhpbiB0aGUgdHJhcC4KKyMgV0FSTklORzogRG8gbm90IHN0YXJ0IHRo
ZSB0cmFwIGNvZGUgd2l0aCBhIG5ld2xpbmUsIGR1ZSB0byBhIEZyZWVCU0QgNC4wIGJ1Zy4KK3Ry
YXAgJ2V4aXRfc3RhdHVzPSQ/CisgICMgU2F2ZSBpbnRvIGNvbmZpZy5sb2cgc29tZSBpbmZvcm1h
dGlvbiB0aGF0IG1pZ2h0IGhlbHAgaW4gZGVidWdnaW5nLgorICB7CisgICAgZWNobworCisgICAg
JGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIENhY2hlIHZhcmlhYmxlcy4gIyMK
KyMjIC0tLS0tLS0tLS0tLS0tLS0gIyMiCisgICAgZWNobworICAgICMgVGhlIGZvbGxvd2luZyB3
YXkgb2Ygd3JpdGluZyB0aGUgY2FjaGUgbWlzaGFuZGxlcyBuZXdsaW5lcyBpbiB2YWx1ZXMsCiso
CisgIGZvciBhY192YXIgaW4gYChzZXQpIDI+JjEgfCBzZWQgLW4gJ1wnJ3MvXlwoW2EtekEtWl9d
W2EtekEtWjAtOV9dKlwpPS4qL1wxL3AnXCcnYDsgZG8KKyAgICBldmFsIGFjX3ZhbD1cJCRhY192
YXIKKyAgICBjYXNlICRhY192YWwgaW4gIygKKyAgICAqJHthc19ubH0qKQorICAgICAgY2FzZSAk
YWNfdmFyIGluICMoCisgICAgICAqX2N2XyopIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogV0FSTklORzogY2FjaGUgdmFyaWFibGUgJGFjX3ZhciBjb250YWlucyBhIG5l
d2xpbmUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogY2FjaGUgdmFyaWFibGUgJGFj
X3ZhciBjb250YWlucyBhIG5ld2xpbmUiID4mMjt9IDs7CisgICAgICBlc2FjCisgICAgICBjYXNl
ICRhY192YXIgaW4gIygKKyAgICAgIF8gfCBJRlMgfCBhc19ubCkgOzsgIygKKyAgICAgIEJBU0hf
QVJHViB8IEJBU0hfU09VUkNFKSBldmFsICRhY192YXI9IDs7ICMoCisgICAgICAqKSB7IGV2YWwg
JGFjX3Zhcj07IHVuc2V0ICRhY192YXI7fSA7OworICAgICAgZXNhYyA7OworICAgIGVzYWMKKyAg
ZG9uZQorICAoc2V0KSAyPiYxIHwKKyAgICBjYXNlICRhc19ubGAoYWNfc3BhY2U9J1wnJyAnXCcn
OyBzZXQpIDI+JjFgIGluICMoCisgICAgKiR7YXNfbmx9YWNfc3BhY2U9XCAqKQorICAgICAgc2Vk
IC1uIFwKKwkicy8nXCcnLydcJydcXFxcJ1wnJydcJycvZzsKKwkgIHMvXlxcKFtfJGFzX2NyX2Fs
bnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKlxcKT1cXCguKlxcKS9cXDE9J1wnJ1xcMidcJycvcCIK
KyAgICAgIDs7ICMoCisgICAgKikKKyAgICAgIHNlZCAtbiAiL15bXyRhc19jcl9hbG51bV0qX2N2
X1tfJGFzX2NyX2FsbnVtXSo9L3AiCisgICAgICA7OworICAgIGVzYWMgfAorICAgIHNvcnQKKykK
KyAgICBlY2hvCisKKyAgICAkYXNfZWNobyAiIyMgLS0tLS0tLS0tLS0tLS0tLS0gIyMKKyMjIE91
dHB1dCB2YXJpYWJsZXMuICMjCisjIyAtLS0tLS0tLS0tLS0tLS0tLSAjIyIKKyAgICBlY2hvCisg
ICAgZm9yIGFjX3ZhciBpbiAkYWNfc3Vic3RfdmFycworICAgIGRvCisgICAgICBldmFsIGFjX3Zh
bD1cJCRhY192YXIKKyAgICAgIGNhc2UgJGFjX3ZhbCBpbgorICAgICAgKlwnXCcnKikgYWNfdmFs
PWAkYXNfZWNobyAiJGFjX3ZhbCIgfCBzZWQgInMvJ1wnJy8nXCcnXFxcXFxcXFwnXCcnJ1wnJy9n
ImA7OworICAgICAgZXNhYworICAgICAgJGFzX2VjaG8gIiRhY192YXI9J1wnJyRhY192YWwnXCcn
IgorICAgIGRvbmUgfCBzb3J0CisgICAgZWNobworCisgICAgaWYgdGVzdCAtbiAiJGFjX3N1YnN0
X2ZpbGVzIjsgdGhlbgorICAgICAgJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tLS0tLS0tLS0gIyMK
KyMjIEZpbGUgc3Vic3RpdHV0aW9ucy4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0gIyMiCisg
ICAgICBlY2hvCisgICAgICBmb3IgYWNfdmFyIGluICRhY19zdWJzdF9maWxlcworICAgICAgZG8K
KwlldmFsIGFjX3ZhbD1cJCRhY192YXIKKwljYXNlICRhY192YWwgaW4KKwkqXCdcJycqKSBhY192
YWw9YCRhc19lY2hvICIkYWNfdmFsIiB8IHNlZCAicy8nXCcnLydcJydcXFxcXFxcXCdcJycnXCcn
L2ciYDs7CisJZXNhYworCSRhc19lY2hvICIkYWNfdmFyPSdcJyckYWNfdmFsJ1wnJyIKKyAgICAg
IGRvbmUgfCBzb3J0CisgICAgICBlY2hvCisgICAgZmkKKworICAgIGlmIHRlc3QgLXMgY29uZmRl
ZnMuaDsgdGhlbgorICAgICAgJGFzX2VjaG8gIiMjIC0tLS0tLS0tLS0tICMjCisjIyBjb25mZGVm
cy5oLiAjIworIyMgLS0tLS0tLS0tLS0gIyMiCisgICAgICBlY2hvCisgICAgICBjYXQgY29uZmRl
ZnMuaAorICAgICAgZWNobworICAgIGZpCisgICAgdGVzdCAiJGFjX3NpZ25hbCIgIT0gMCAmJgor
ICAgICAgJGFzX2VjaG8gIiRhc19tZTogY2F1Z2h0IHNpZ25hbCAkYWNfc2lnbmFsIgorICAgICRh
c19lY2hvICIkYXNfbWU6IGV4aXQgJGV4aXRfc3RhdHVzIgorICB9ID4mNQorICBybSAtZiBjb3Jl
ICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogJiYKKyAgICBybSAtZiAtciBjb25mdGVzdCogY29uZmRl
ZnMqIGNvbmYkJCogJGFjX2NsZWFuX2ZpbGVzICYmCisgICAgZXhpdCAkZXhpdF9zdGF0dXMKKycg
MAorZm9yIGFjX3NpZ25hbCBpbiAxIDIgMTMgMTU7IGRvCisgIHRyYXAgJ2FjX3NpZ25hbD0nJGFj
X3NpZ25hbCc7IGFzX2ZuX2V4aXQgMScgJGFjX3NpZ25hbAorZG9uZQorYWNfc2lnbmFsPTAKKwor
IyBjb25mZGVmcy5oIGF2b2lkcyBPUyBjb21tYW5kIGxpbmUgbGVuZ3RoIGxpbWl0cyB0aGF0IERF
RlMgY2FuIGV4Y2VlZC4KK3JtIC1mIC1yIGNvbmZ0ZXN0KiBjb25mZGVmcy5oCisKKyRhc19lY2hv
ICIvKiBjb25mZGVmcy5oICovIiA+IGNvbmZkZWZzLmgKKworIyBQcmVkZWZpbmVkIHByZXByb2Nl
c3NvciB2YXJpYWJsZXMuCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFD
S0FHRV9OQU1FICIkUEFDS0FHRV9OQU1FIgorX0FDRU9GCisKK2NhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9UQVJOQU1FICIkUEFDS0FHRV9UQVJOQU1FIgorX0FDRU9G
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgUEFDS0FHRV9WRVJTSU9OICIk
UEFDS0FHRV9WRVJTSU9OIgorX0FDRU9GCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgUEFDS0FHRV9TVFJJTkcgIiRQQUNLQUdFX1NUUklORyIKK19BQ0VPRgorCitjYXQgPj5j
b25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIFBBQ0tBR0VfQlVHUkVQT1JUICIkUEFDS0FHRV9C
VUdSRVBPUlQiCitfQUNFT0YKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBQ
QUNLQUdFX1VSTCAiJFBBQ0tBR0VfVVJMIgorX0FDRU9GCisKKworIyBMZXQgdGhlIHNpdGUgZmls
ZSBzZWxlY3QgYW4gYWx0ZXJuYXRlIGNhY2hlIGZpbGUgaWYgaXQgd2FudHMgdG8uCisjIFByZWZl
ciBhbiBleHBsaWNpdGx5IHNlbGVjdGVkIGZpbGUgdG8gYXV0b21hdGljYWxseSBzZWxlY3RlZCBv
bmVzLgorYWNfc2l0ZV9maWxlMT1OT05FCithY19zaXRlX2ZpbGUyPU5PTkUKK2lmIHRlc3QgLW4g
IiRDT05GSUdfU0lURSI7IHRoZW4KKyAgIyBXZSBkbyBub3Qgd2FudCBhIFBBVEggc2VhcmNoIGZv
ciBjb25maWcuc2l0ZS4KKyAgY2FzZSAkQ09ORklHX1NJVEUgaW4gIygoCisgICAgLSopICBhY19z
aXRlX2ZpbGUxPS4vJENPTkZJR19TSVRFOzsKKyAgICAqLyopIGFjX3NpdGVfZmlsZTE9JENPTkZJ
R19TSVRFOzsKKyAgICAqKSAgIGFjX3NpdGVfZmlsZTE9Li8kQ09ORklHX1NJVEU7OworICBlc2Fj
CitlbGlmIHRlc3QgIngkcHJlZml4IiAhPSB4Tk9ORTsgdGhlbgorICBhY19zaXRlX2ZpbGUxPSRw
cmVmaXgvc2hhcmUvY29uZmlnLnNpdGUKKyAgYWNfc2l0ZV9maWxlMj0kcHJlZml4L2V0Yy9jb25m
aWcuc2l0ZQorZWxzZQorICBhY19zaXRlX2ZpbGUxPSRhY19kZWZhdWx0X3ByZWZpeC9zaGFyZS9j
b25maWcuc2l0ZQorICBhY19zaXRlX2ZpbGUyPSRhY19kZWZhdWx0X3ByZWZpeC9ldGMvY29uZmln
LnNpdGUKK2ZpCitmb3IgYWNfc2l0ZV9maWxlIGluICIkYWNfc2l0ZV9maWxlMSIgIiRhY19zaXRl
X2ZpbGUyIgorZG8KKyAgdGVzdCAieCRhY19zaXRlX2ZpbGUiID0geE5PTkUgJiYgY29udGludWUK
KyAgaWYgdGVzdCAvZGV2L251bGwgIT0gIiRhY19zaXRlX2ZpbGUiICYmIHRlc3QgLXIgIiRhY19z
aXRlX2ZpbGUiOyB0aGVuCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBsb2FkaW5nIHNpdGUgc2NyaXB0ICRhY19zaXRlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRh
c19tZTogbG9hZGluZyBzaXRlIHNjcmlwdCAkYWNfc2l0ZV9maWxlIiA+JjY7fQorICAgIHNlZCAn
cy9eL3wgLycgIiRhY19zaXRlX2ZpbGUiID4mNQorICAgIC4gIiRhY19zaXRlX2ZpbGUiIFwKKyAg
ICAgIHx8IHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjog
aW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3
ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gImZhaWxlZCB0byBsb2FkIHNpdGUgc2NyaXB0ICRh
Y19zaXRlX2ZpbGUKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5P
IiA1OyB9CisgIGZpCitkb25lCisKK2lmIHRlc3QgLXIgIiRjYWNoZV9maWxlIjsgdGhlbgorICAj
IFNvbWUgdmVyc2lvbnMgb2YgYmFzaCB3aWxsIGZhaWwgdG8gc291cmNlIC9kZXYvbnVsbCAoc3Bl
Y2lhbCBmaWxlcworICAjIGFjdHVhbGx5KSwgc28gd2UgYXZvaWQgZG9pbmcgdGhhdC4gIERKR1BQ
IGVtdWxhdGVzIGl0IGFzIGEgcmVndWxhciBmaWxlLgorICBpZiB0ZXN0IC9kZXYvbnVsbCAhPSAi
JGNhY2hlX2ZpbGUiICYmIHRlc3QgLWYgIiRjYWNoZV9maWxlIjsgdGhlbgorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogbG9hZGluZyBjYWNoZSAkY2FjaGVfZmls
ZSIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBsb2FkaW5nIGNhY2hlICRjYWNoZV9maWxlIiA+JjY7
fQorICAgIGNhc2UgJGNhY2hlX2ZpbGUgaW4KKyAgICAgIFtcXC9dKiB8ID86W1xcL10qICkgLiAi
JGNhY2hlX2ZpbGUiOzsKKyAgICAgICopICAgICAgICAgICAgICAgICAgICAgIC4gIi4vJGNhY2hl
X2ZpbGUiOzsKKyAgICBlc2FjCisgIGZpCitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY3JlYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2Vj
aG8gIiRhc19tZTogY3JlYXRpbmcgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9CisgID4kY2FjaGVf
ZmlsZQorZmkKKworYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3lzL3RpbWUuaCIKK2Fz
X2ZuX2FwcGVuZCBhY19oZWFkZXJfbGlzdCAiIHVuaXN0ZC5oIgorYXNfZm5fYXBwZW5kIGFjX2Z1
bmNfbGlzdCAiIGFsYXJtIgorYXNfZm5fYXBwZW5kIGFjX2hlYWRlcl9saXN0ICIgc3RkbGliLmgi
Cithc19mbl9hcHBlbmQgYWNfaGVhZGVyX2xpc3QgIiBzeXMvcGFyYW0uaCIKKyMgQ2hlY2sgdGhh
dCB0aGUgcHJlY2lvdXMgdmFyaWFibGVzIHNhdmVkIGluIHRoZSBjYWNoZSBoYXZlIGtlcHQgdGhl
IHNhbWUKKyMgdmFsdWUuCithY19jYWNoZV9jb3JydXB0ZWQ9ZmFsc2UKK2ZvciBhY192YXIgaW4g
JGFjX3ByZWNpb3VzX3ZhcnM7IGRvCisgIGV2YWwgYWNfb2xkX3NldD1cJGFjX2N2X2Vudl8ke2Fj
X3Zhcn1fc2V0CisgIGV2YWwgYWNfbmV3X3NldD1cJGFjX2Vudl8ke2FjX3Zhcn1fc2V0CisgIGV2
YWwgYWNfb2xkX3ZhbD1cJGFjX2N2X2Vudl8ke2FjX3Zhcn1fdmFsdWUKKyAgZXZhbCBhY19uZXdf
dmFsPVwkYWNfZW52XyR7YWNfdmFyfV92YWx1ZQorICBjYXNlICRhY19vbGRfc2V0LCRhY19uZXdf
c2V0IGluCisgICAgc2V0LCkKKyAgICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZXJyb3I6IFxgJGFjX3Zhcicgd2FzIHNldCB0byBcYCRhY19vbGRfdmFsJyBpbiB0
aGUgcHJldmlvdXMgcnVuIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBcYCRhY192YXIn
IHdhcyBzZXQgdG8gXGAkYWNfb2xkX3ZhbCcgaW4gdGhlIHByZXZpb3VzIHJ1biIgPiYyO30KKyAg
ICAgIGFjX2NhY2hlX2NvcnJ1cHRlZD06IDs7CisgICAgLHNldCkKKyAgICAgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IFxgJGFjX3Zhcicgd2FzIG5vdCBz
ZXQgaW4gdGhlIHByZXZpb3VzIHJ1biIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogXGAk
YWNfdmFyJyB3YXMgbm90IHNldCBpbiB0aGUgcHJldmlvdXMgcnVuIiA+JjI7fQorICAgICAgYWNf
Y2FjaGVfY29ycnVwdGVkPTogOzsKKyAgICAsKTs7CisgICAgKikKKyAgICAgIGlmIHRlc3QgIngk
YWNfb2xkX3ZhbCIgIT0gIngkYWNfbmV3X3ZhbCI7IHRoZW4KKwkjIGRpZmZlcmVuY2VzIGluIHdo
aXRlc3BhY2UgZG8gbm90IGxlYWQgdG8gZmFpbHVyZS4KKwlhY19vbGRfdmFsX3c9YGVjaG8geCAk
YWNfb2xkX3ZhbGAKKwlhY19uZXdfdmFsX3c9YGVjaG8geCAkYWNfbmV3X3ZhbGAKKwlpZiB0ZXN0
ICIkYWNfb2xkX3ZhbF93IiAhPSAiJGFjX25ld192YWxfdyI7IHRoZW4KKwkgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IFxgJGFjX3ZhcicgaGFzIGNoYW5n
ZWQgc2luY2UgdGhlIHByZXZpb3VzIHJ1bjoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6
IFxgJGFjX3ZhcicgaGFzIGNoYW5nZWQgc2luY2UgdGhlIHByZXZpb3VzIHJ1bjoiID4mMjt9CisJ
ICBhY19jYWNoZV9jb3JydXB0ZWQ9OgorCWVsc2UKKwkgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogd2FybmluZzogaWdub3Jpbmcgd2hpdGVzcGFjZSBjaGFuZ2VzIGlu
IFxgJGFjX3Zhcicgc2luY2UgdGhlIHByZXZpb3VzIHJ1bjoiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogd2FybmluZzogaWdub3Jpbmcgd2hpdGVzcGFjZSBjaGFuZ2VzIGluIFxgJGFjX3Zhcicgc2lu
Y2UgdGhlIHByZXZpb3VzIHJ1bjoiID4mMjt9CisJICBldmFsICRhY192YXI9XCRhY19vbGRfdmFs
CisJZmkKKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICAgZm9ybWVy
IHZhbHVlOiAgXGAkYWNfb2xkX3ZhbCciID4mNQorJGFzX2VjaG8gIiRhc19tZTogICBmb3JtZXIg
dmFsdWU6ICBcYCRhY19vbGRfdmFsJyIgPiYyO30KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306ICAgY3VycmVudCB2YWx1ZTogXGAkYWNfbmV3X3ZhbCciID4mNQorJGFz
X2VjaG8gIiRhc19tZTogICBjdXJyZW50IHZhbHVlOiBcYCRhY19uZXdfdmFsJyIgPiYyO30KKyAg
ICAgIGZpOzsKKyAgZXNhYworICAjIFBhc3MgcHJlY2lvdXMgdmFyaWFibGVzIHRvIGNvbmZpZy5z
dGF0dXMuCisgIGlmIHRlc3QgIiRhY19uZXdfc2V0IiA9IHNldDsgdGhlbgorICAgIGNhc2UgJGFj
X25ld192YWwgaW4KKyAgICAqXCcqKSBhY19hcmc9JGFjX3Zhcj1gJGFzX2VjaG8gIiRhY19uZXdf
dmFsIiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYCA7OworICAgICopIGFjX2FyZz0kYWNfdmFy
PSRhY19uZXdfdmFsIDs7CisgICAgZXNhYworICAgIGNhc2UgIiAkYWNfY29uZmlndXJlX2FyZ3Mg
IiBpbgorICAgICAgKiIgJyRhY19hcmcnICIqKSA7OyAjIEF2b2lkIGR1cHMuICBVc2Ugb2YgcXVv
dGVzIGVuc3VyZXMgYWNjdXJhY3kuCisgICAgICAqKSBhc19mbl9hcHBlbmQgYWNfY29uZmlndXJl
X2FyZ3MgIiAnJGFjX2FyZyciIDs7CisgICAgZXNhYworICBmaQorZG9uZQoraWYgJGFjX2NhY2hl
X2NvcnJ1cHRlZDsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjog
aW4gXGAkYWNfcHdkJzoiID4mMjt9CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZXJyb3I6IGNoYW5nZXMgaW4gdGhlIGVudmlyb25tZW50IGNhbiBjb21wcm9taXNl
IHRoZSBidWlsZCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogY2hhbmdlcyBpbiB0aGUg
ZW52aXJvbm1lbnQgY2FuIGNvbXByb21pc2UgdGhlIGJ1aWxkIiA+JjI7fQorICBhc19mbl9lcnJv
ciAkPyAicnVuIFxgbWFrZSBkaXN0Y2xlYW4nIGFuZC9vciBcYHJtICRjYWNoZV9maWxlJyBhbmQg
c3RhcnQgb3ZlciIgIiRMSU5FTk8iIDUKK2ZpCisjIyAtLS0tLS0tLS0tLS0tLS0tLS0tLSAjIwor
IyMgTWFpbiBib2R5IG9mIHNjcmlwdC4gIyMKKyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisK
K2FjX2V4dD1jCithY19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRD
RkxBR1MgJENQUEZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNv
bmZ0ZXN0JGFjX2V4ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNf
ZXh0ICRMSUJTID4mNScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKKwor
CisKK2FjX2NvbmZpZ19maWxlcz0iJGFjX2NvbmZpZ19maWxlcyAuLi9jb25maWcvVG9vbHMubWsi
CisKK2FjX2NvbmZpZ19oZWFkZXJzPSIkYWNfY29uZmlnX2hlYWRlcnMgY29uZmlnLmgiCisKKwor
YWNfYXV4X2Rpcj0KK2ZvciBhY19kaXIgaW4gLiAiJHNyY2RpciIvLjsgZG8KKyAgaWYgdGVzdCAt
ZiAiJGFjX2Rpci9pbnN0YWxsLXNoIjsgdGhlbgorICAgIGFjX2F1eF9kaXI9JGFjX2RpcgorICAg
IGFjX2luc3RhbGxfc2g9IiRhY19hdXhfZGlyL2luc3RhbGwtc2ggLWMiCisgICAgYnJlYWsKKyAg
ZWxpZiB0ZXN0IC1mICIkYWNfZGlyL2luc3RhbGwuc2giOyB0aGVuCisgICAgYWNfYXV4X2Rpcj0k
YWNfZGlyCisgICAgYWNfaW5zdGFsbF9zaD0iJGFjX2F1eF9kaXIvaW5zdGFsbC5zaCAtYyIKKyAg
ICBicmVhaworICBlbGlmIHRlc3QgLWYgIiRhY19kaXIvc2h0b29sIjsgdGhlbgorICAgIGFjX2F1
eF9kaXI9JGFjX2RpcgorICAgIGFjX2luc3RhbGxfc2g9IiRhY19hdXhfZGlyL3NodG9vbCBpbnN0
YWxsIC1jIgorICAgIGJyZWFrCisgIGZpCitkb25lCitpZiB0ZXN0IC16ICIkYWNfYXV4X2RpciI7
IHRoZW4KKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBmaW5kIGluc3RhbGwtc2gsIGluc3RhbGwu
c2gsIG9yIHNodG9vbCBpbiAuIFwiJHNyY2RpclwiLy4iICIkTElORU5PIiA1CitmaQorCisjIFRo
ZXNlIHRocmVlIHZhcmlhYmxlcyBhcmUgdW5kb2N1bWVudGVkIGFuZCB1bnN1cHBvcnRlZCwKKyMg
YW5kIGFyZSBpbnRlbmRlZCB0byBiZSB3aXRoZHJhd24gaW4gYSBmdXR1cmUgQXV0b2NvbmYgcmVs
ZWFzZS4KKyMgVGhleSBjYW4gY2F1c2Ugc2VyaW91cyBwcm9ibGVtcyBpZiBhIGJ1aWxkZXIncyBz
b3VyY2UgdHJlZSBpcyBpbiBhIGRpcmVjdG9yeQorIyB3aG9zZSBmdWxsIG5hbWUgY29udGFpbnMg
dW51c3VhbCBjaGFyYWN0ZXJzLgorYWNfY29uZmlnX2d1ZXNzPSIkU0hFTEwgJGFjX2F1eF9kaXIv
Y29uZmlnLmd1ZXNzIiAgIyBQbGVhc2UgZG9uJ3QgdXNlIHRoaXMgdmFyLgorYWNfY29uZmlnX3N1
Yj0iJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICAjIFBsZWFzZSBkb24ndCB1c2UgdGhp
cyB2YXIuCithY19jb25maWd1cmU9IiRTSEVMTCAkYWNfYXV4X2Rpci9jb25maWd1cmUiICAjIFBs
ZWFzZSBkb24ndCB1c2UgdGhpcyB2YXIuCisKKworCisjIENoZWNrIGlmIENGTEFHUywgTERGTEFH
UywgTElCUywgQ1BQRkxBR1Mgb3IgQ1BQIGlzIHNldCBhbmQgcHJpbnQgYSB3YXJuaW5nCisKK2lm
IHRlc3QgLW4gIiRDQyRDRkxBR1MkTERGTEFHUyRMSUJTJENQUEZMQUdTJENQUCI7IHRoZW4gOgor
CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiBT
ZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBpcyBub3Qg
XAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVTLCBQUkVQRU5EX0xJQiwgXAorQVBQ
RU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQgd2hlbiBwb3NzaWJsZS4iID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogU2V0dGluZyBDQywgQ0ZMQUdTLCBMREZMQUdTLCBM
SUJTLCBDUFBGTEFHUyBvciBDUFAgaXMgbm90IFwKK3JlY29tbWVuZGVkLCB1c2UgUFJFUEVORF9J
TkNMVURFUywgUFJFUEVORF9MSUIsIFwKK0FQUEVORF9JTkNMVURFUyBhbmQgQVBQRU5EX0xJQiBp
bnN0ZWFkIHdoZW4gcG9zc2libGUuIiA+JjI7fQorCitmaQorCithY19leHQ9YworYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG
TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j
b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CitpZiB0ZXN0IC1uICIkYWNfdG9vbF9w
cmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJHthY190b29sX3By
ZWZpeH1nY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1
bW15ICR7YWNfdG9vbF9wcmVmaXh9Z2NjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19D
Qys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAjIExldCB0aGUg
dXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFU
SF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMK
KyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4g
JycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9vbF9wcmVmaXh9
Z2NjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUK
KyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK0NDPSRhY19jdl9wcm9nX0NDCitp
ZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkQ0MiID4mNQorJGFzX2VjaG8gIiRDQyIgPiY2OyB9CitlbHNlCisg
IHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1
CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2X3By
b2dfQ0MiOyB0aGVuCisgIGFjX2N0X0NDPSRDQworICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQg
b2YgImdjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgZ2NjOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9DQys6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4g
IiRhY19jdF9DQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9ImdjYyIK
KyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRv
bmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9DQz0kYWNfY3ZfcHJvZ19hY19j
dF9DQworaWYgdGVzdCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X0NDIiA+JjUKKyRhc19lY2hvICIk
YWNfY3RfQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAg
aWYgdGVzdCAieCRhY19jdF9DQyIgPSB4OyB0aGVuCisgICAgQ0M9IiIKKyAgZWxzZQorICAgIGNh
c2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xz
IG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBX
QVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQi
ID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBDQz0kYWNfY3RfQ0MKKyAg
ZmkKK2Vsc2UKKyAgQ0M9IiRhY19jdl9wcm9nX0NDIgorZmkKKworaWYgdGVzdCAteiAiJENDIjsg
dGhlbgorICAgICAgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgICAj
IEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Y2MiLCBzbyBpdCBj
YW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVm
aXh9Y2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoK
KyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsg
dGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFz
X2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGly
IiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9l
eHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVu
CisgICAgYWNfY3ZfcHJvZ19DQz0iJHthY190b29sX3ByZWZpeH1jYyIKKyAgICAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2
ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhl
bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEND
IiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKworICBmaQorZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgIyBFeHRyYWN0
IHRoZSBmaXJzdCB3b3JkIG9mICJjYyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRo
IGFyZ3MuCitzZXQgZHVtbXkgY2M7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24g
ImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9
IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9wcm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2Vy
IG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorICBhY19wcm9nX3JlamVjdGVkPW5vCithc19zYXZl
X0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbwor
ICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAg
Zm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlm
IHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBpZiB0ZXN0ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA9ICIvdXNyL3VjYi9jYyI7IHRoZW4KKyAgICAgICBh
Y19wcm9nX3JlamVjdGVkPXllcworICAgICAgIGNvbnRpbnVlCisgICAgIGZpCisgICAgYWNfY3Zf
cHJvZ19DQz0iY2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2lmIHRlc3QgJGFjX3Byb2dfcmVq
ZWN0ZWQgPSB5ZXM7IHRoZW4KKyAgIyBXZSBmb3VuZCBhIGJvZ29uIGluIHRoZSBwYXRoLCBzbyBt
YWtlIHN1cmUgd2UgbmV2ZXIgdXNlIGl0LgorICBzZXQgZHVtbXkgJGFjX2N2X3Byb2dfQ0MKKyAg
c2hpZnQKKyAgaWYgdGVzdCAkIyAhPSAwOyB0aGVuCisgICAgIyBXZSBjaG9zZSBhIGRpZmZlcmVu
dCBjb21waWxlciBmcm9tIHRoZSBib2d1cyBvbmUuCisgICAgIyBIb3dldmVyLCBpdCBoYXMgdGhl
IHNhbWUgYmFzZW5hbWUsIHNvIHRoZSBib2dvbiB3aWxsIGJlIGNob3NlbgorICAgICMgZmlyc3Qg
aWYgd2Ugc2V0IENDIHRvIGp1c3QgdGhlIGJhc2VuYW1lOyB1c2UgdGhlIGZ1bGwgZmlsZSBuYW1l
LgorICAgIHNoaWZ0CisgICAgYWNfY3ZfcHJvZ19DQz0iJGFzX2Rpci8kYWNfd29yZCR7MSsnICd9
JEAiCisgIGZpCitmaQorZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJEND
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgaWYgdGVzdCAt
biAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKKyAgZG8K
KyAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiRhY190b29sX3ByZWZpeCRhY19wcm9n
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAkYWNf
dG9vbF9wcmVmaXgkYWNfcHJvZzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0
ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFjX2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQ
QVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRl
c3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRh
Y19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX0NDPSIkYWNfdG9vbF9wcmVmaXgkYWNfcHJv
ZyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisg
IGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYg
dGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRhc19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQor
JGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworICAgIHRlc3QgLW4gIiRDQyIgJiYgYnJlYWsK
KyAgZG9uZQorZmkKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgYWNfY3RfQ0M9JENDCisgIGZv
ciBhY19wcm9nIGluIGNsLmV4ZQorZG8KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
YWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgJGFjX3Byb2c7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X0NDKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVz
dCAtbiAiJGFjX2N0X0NDIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X0NDPSIkYWNfY3RfQ0Mi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9DQz0i
JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91
bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQor
ZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfQ0M9JGFjX2N2
X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdF9DQyIgPiY1Cisk
YXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9
CitmaQorCisKKyAgdGVzdCAtbiAiJGFjX2N0X0NDIiAmJiBicmVhaworZG9uZQorCisgIGlmIHRl
c3QgIngkYWNfY3RfQ0MiID0geDsgdGhlbgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitm
aQorCitmaQorCisKK3Rlc3QgLXogIiRDQyIgJiYgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAibm8gYWNj
ZXB0YWJsZSBDIGNvbXBpbGVyIGZvdW5kIGluIFwkUEFUSAorU2VlIFxgY29uZmlnLmxvZycgZm9y
IG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDU7IH0KKworIyBQcm92aWRlIHNvbWUgaW5mb3JtYXRp
b24gYWJvdXQgdGhlIGNvbXBpbGVyLgorJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgdmVyc2lvbiIgPiY1CitzZXQgWCAkYWNfY29t
cGlsZQorYWNfY29tcGlsZXI9JDIKK2ZvciBhY19vcHRpb24gaW4gLS12ZXJzaW9uIC12IC1WIC1x
dmVyc2lvbjsgZG8KKyAgeyB7IGFjX3RyeT0iJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1Igor
Y2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIqIHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwk
YWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9l
Y2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFz
X2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1CisgIChldmFsICIkYWNfY29tcGlsZXIgJGFjX29w
dGlvbiA+JjUiKSAyPmNvbmZ0ZXN0LmVycgorICBhY19zdGF0dXM9JD8KKyAgaWYgdGVzdCAtcyBj
b25mdGVzdC5lcnI7IHRoZW4KKyAgICBzZWQgJzEwYVwKKy4uLiByZXN0IG9mIHN0ZGVyciBvdXRw
dXQgZGVsZXRlZCAuLi4KKyAgICAgICAgIDEwcScgY29uZnRlc3QuZXJyID5jb25mdGVzdC5lcjEK
KyAgICBjYXQgY29uZnRlc3QuZXIxID4mNQorICBmaQorICBybSAtZiBjb25mdGVzdC5lcjEgY29u
ZnRlc3QuZXJyCisgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFwkPyA9
ICRhY19zdGF0dXMiID4mNQorICB0ZXN0ICRhY19zdGF0dXMgPSAwOyB9Citkb25lCisKK2NhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgor
YWNfY2xlYW5fZmlsZXNfc2F2ZT0kYWNfY2xlYW5fZmlsZXMKK2FjX2NsZWFuX2ZpbGVzPSIkYWNf
Y2xlYW5fZmlsZXMgYS5vdXQgYS5vdXQuZFNZTSBhLmV4ZSBiLm91dCIKKyMgVHJ5IHRvIGNyZWF0
ZSBhbiBleGVjdXRhYmxlIHdpdGhvdXQgLW8gZmlyc3QsIGRpc3JlZ2FyZCBhLm91dC4KKyMgSXQg
d2lsbCBoZWxwIHVzIGRpYWdub3NlIGJyb2tlbiBjb21waWxlcnMsIGFuZCBmaW5kaW5nIG91dCBh
biBpbnR1aXRpb24KKyMgb2YgZXhlZXh0LgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyIHRoZSBDIGNvbXBpbGVyIHdvcmtzIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgdGhlIEMgY29tcGlsZXIgd29ya3MuLi4gIiA+JjY7
IH0KK2FjX2xpbmtfZGVmYXVsdD1gJGFzX2VjaG8gIiRhY19saW5rIiB8IHNlZCAncy8gLW8gKmNv
bmZ0ZXN0W14gXSovLydgCisKKyMgVGhlIHBvc3NpYmxlIG91dHB1dCBmaWxlczoKK2FjX2ZpbGVz
PSJhLm91dCBjb25mdGVzdC5leGUgY29uZnRlc3QgYS5leGUgYV9vdXQuZXhlIGIub3V0IGNvbmZ0
ZXN0LioiCisKK2FjX3JtZmlsZXM9Citmb3IgYWNfZmlsZSBpbiAkYWNfZmlsZXMKK2RvCisgIGNh
c2UgJGFjX2ZpbGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAq
LnBkYiB8ICoueFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAq
Lm8gfCAqLm9iaiApIDs7CisgICAgKiApIGFjX3JtZmlsZXM9IiRhY19ybWZpbGVzICRhY19maWxl
Ijs7CisgIGVzYWMKK2RvbmUKK3JtIC1mICRhY19ybWZpbGVzCisKK2lmIHsgeyBhY190cnk9IiRh
Y19saW5rX2RlZmF1bHQiCitjYXNlICIoKCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxc
KikgYWNfdHJ5X2VjaG89XCRhY190cnk7OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2Vz
YWMKK2V2YWwgYWNfdHJ5X2VjaG89IlwiXCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFj
X3RyeV9lY2hvXCIiCiskYXNfZWNobyAiJGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRh
Y19saW5rX2RlZmF1bHQiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfTsgdGhlbiA6CisgICMgQXV0b2NvbmYtMi4xMyBjb3VsZCBzZXQgdGhlIGFj
X2N2X2V4ZWV4dCB2YXJpYWJsZSB0byBgbm8nLgorIyBTbyBpZ25vcmUgYSB2YWx1ZSBvZiBgbm8n
LCBvdGhlcndpc2UgdGhpcyB3b3VsZCBsZWFkIHRvIGBFWEVFWFQgPSBubycKKyMgaW4gYSBNYWtl
ZmlsZS4gIFdlIHNob3VsZCBub3Qgb3ZlcnJpZGUgYWNfY3ZfZXhlZXh0IGlmIGl0IHdhcyBjYWNo
ZWQsCisjIHNvIHRoYXQgdGhlIHVzZXIgY2FuIHNob3J0LWNpcmN1aXQgdGhpcyB0ZXN0IGZvciBj
b21waWxlcnMgdW5rbm93biB0bworIyBBdXRvY29uZi4KK2ZvciBhY19maWxlIGluICRhY19maWxl
cyAnJworZG8KKyAgdGVzdCAtZiAiJGFjX2ZpbGUiIHx8IGNvbnRpbnVlCisgIGNhc2UgJGFjX2Zp
bGUgaW4KKyAgICAqLiRhY19leHQgfCAqLnhjb2ZmIHwgKi50ZHMgfCAqLmQgfCAqLnBkYiB8ICou
eFNZTSB8ICouYmIgfCAqLmJiZyB8ICoubWFwIHwgKi5pbmYgfCAqLmRTWU0gfCAqLm8gfCAqLm9i
aiApCisJOzsKKyAgICBbYWJdLm91dCApCisJIyBXZSBmb3VuZCB0aGUgZGVmYXVsdCBleGVjdXRh
YmxlLCBidXQgZXhlZXh0PScnIGlzIG1vc3QKKwkjIGNlcnRhaW5seSByaWdodC4KKwlicmVhazs7
CisgICAgKi4qICkKKwlpZiB0ZXN0ICIke2FjX2N2X2V4ZWV4dCtzZXR9IiA9IHNldCAmJiB0ZXN0
ICIkYWNfY3ZfZXhlZXh0IiAhPSBubzsKKwl0aGVuIDo7IGVsc2UKKwkgICBhY19jdl9leGVleHQ9
YGV4cHIgIiRhY19maWxlIiA6ICdbXi5dKlwoXC4uKlwpJ2AKKwlmaQorCSMgV2Ugc2V0IGFjX2N2
X2V4ZWV4dCBoZXJlIGJlY2F1c2UgdGhlIGxhdGVyIHRlc3QgZm9yIGl0IGlzIG5vdAorCSMgc2Fm
ZTogY3Jvc3MgY29tcGlsZXJzIG1heSBub3QgYWRkIHRoZSBzdWZmaXggaWYgZ2l2ZW4gYW4gYC1v
JworCSMgYXJndW1lbnQsIHNvIHdlIG1heSBuZWVkIHRvIGtub3cgaXQgYXQgdGhhdCBwb2ludCBh
bHJlYWR5LgorCSMgRXZlbiBpZiB0aGlzIHNlY3Rpb24gbG9va3MgY3J1ZnR5OiBpdCBoYXMgdGhl
IGFkdmFudGFnZSBvZgorCSMgYWN0dWFsbHkgd29ya2luZy4KKwlicmVhazs7CisgICAgKiApCisJ
YnJlYWs7OworICBlc2FjCitkb25lCit0ZXN0ICIkYWNfY3ZfZXhlZXh0IiA9IG5vICYmIGFjX2N2
X2V4ZWV4dD0KKworZWxzZQorICBhY19maWxlPScnCitmaQoraWYgdGVzdCAteiAiJGFjX2ZpbGUi
OyB0aGVuIDoKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CiskYXNfZWNobyAiJGFzX21lOiBmYWls
ZWQgcHJvZ3JhbSB3YXM6IiA+JjUKK3NlZCAncy9eL3wgLycgY29uZnRlc3QuJGFjX2V4dCA+JjUK
KworeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBc
YCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoi
ID4mMjt9Cithc19mbl9lcnJvciA3NyAiQyBjb21waWxlciBjYW5ub3QgY3JlYXRlIGV4ZWN1dGFi
bGVzCitTZWUgXGBjb25maWcubG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQor
ZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
eWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIEMgY29tcGlsZXIgZGVmYXVsdCBvdXRw
dXQgZmlsZSBuYW1lIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBDIGNvbXBpbGVyIGRl
ZmF1bHQgb3V0cHV0IGZpbGUgbmFtZS4uLiAiID4mNjsgfQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19maWxlIiA+JjUKKyRhc19lY2hvICIkYWNf
ZmlsZSIgPiY2OyB9CithY19leGVleHQ9JGFjX2N2X2V4ZWV4dAorCitybSAtZiAtciBhLm91dCBh
Lm91dC5kU1lNIGEuZXhlIGNvbmZ0ZXN0JGFjX2N2X2V4ZWV4dCBiLm91dAorYWNfY2xlYW5fZmls
ZXM9JGFjX2NsZWFuX2ZpbGVzX3NhdmUKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgZm9yIHN1ZmZpeCBvZiBleGVjdXRhYmxlcyIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3Igc3VmZml4IG9mIGV4ZWN1dGFibGVzLi4uICIgPiY2OyB9CitpZiB7
IHsgYWNfdHJ5PSIkYWNfbGluayIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCog
fCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7
OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZh
bCAiJGFjX2xpbmsiKSAyPiY1CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3Rh
dHVzID0gMDsgfTsgdGhlbiA6CisgICMgSWYgYm90aCBgY29uZnRlc3QuZXhlJyBhbmQgYGNvbmZ0
ZXN0JyBhcmUgYHByZXNlbnQnICh3ZWxsLCBvYnNlcnZhYmxlKQorIyBjYXRjaCBgY29uZnRlc3Qu
ZXhlJy4gIEZvciBpbnN0YW5jZSB3aXRoIEN5Z3dpbiwgYGxzIGNvbmZ0ZXN0JyB3aWxsCisjIHdv
cmsgcHJvcGVybHkgKGkuZS4sIHJlZmVyIHRvIGBjb25mdGVzdC5leGUnKSwgd2hpbGUgaXQgd29u
J3Qgd2l0aAorIyBgcm0nLgorZm9yIGFjX2ZpbGUgaW4gY29uZnRlc3QuZXhlIGNvbmZ0ZXN0IGNv
bmZ0ZXN0Lio7IGRvCisgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZQorICBjYXNlICRh
Y19maWxlIGluCisgICAgKi4kYWNfZXh0IHwgKi54Y29mZiB8ICoudGRzIHwgKi5kIHwgKi5wZGIg
fCAqLnhTWU0gfCAqLmJiIHwgKi5iYmcgfCAqLm1hcCB8ICouaW5mIHwgKi5kU1lNIHwgKi5vIHwg
Ki5vYmogKSA7OworICAgICouKiApIGFjX2N2X2V4ZWV4dD1gZXhwciAiJGFjX2ZpbGUiIDogJ1te
Ll0qXChcLi4qXCknYAorCSAgYnJlYWs7OworICAgICogKSBicmVhazs7CisgIGVzYWMKK2RvbmUK
K2Vsc2UKKyAgeyB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGVycm9y
OiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNf
cHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAiY2Fubm90IGNvbXB1dGUgc3VmZml4IG9mIGV4
ZWN1dGFibGVzOiBjYW5ub3QgY29tcGlsZSBhbmQgbGluaworU2VlIFxgY29uZmlnLmxvZycgZm9y
IG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDU7IH0KK2ZpCitybSAtZiBjb25mdGVzdCBjb25mdGVz
dCRhY19jdl9leGVleHQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfZXhlZXh0IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZXhlZXh0IiA+JjY7
IH0KKworcm0gLWYgY29uZnRlc3QuJGFjX2V4dAorRVhFRVhUPSRhY19jdl9leGVleHQKK2FjX2V4
ZWV4dD0kRVhFRVhUCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFpbiAo
KQoreworRklMRSAqZiA9IGZvcGVuICgiY29uZnRlc3Qub3V0IiwgInciKTsKKyByZXR1cm4gZmVy
cm9yIChmKSB8fCBmY2xvc2UgKGYpICE9IDA7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VP
RgorYWNfY2xlYW5fZmlsZXM9IiRhY19jbGVhbl9maWxlcyBjb25mdGVzdC5vdXQiCisjIENoZWNr
IHRoYXQgdGhlIGNvbXBpbGVyIHByb2R1Y2VzIGV4ZWN1dGFibGVzIHdlIGNhbiBydW4uICBJZiBu
b3QsIGVpdGhlcgorIyB0aGUgY29tcGlsZXIgaXMgYnJva2VuLCBvciB3ZSBjcm9zcyBjb21waWxl
LgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0
aGVyIHdlIGFyZSBjcm9zcyBjb21waWxpbmciID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hl
dGhlciB3ZSBhcmUgY3Jvc3MgY29tcGlsaW5nLi4uICIgPiY2OyB9CitpZiB0ZXN0ICIkY3Jvc3Nf
Y29tcGlsaW5nIiAhPSB5ZXM7IHRoZW4KKyAgeyB7IGFjX3RyeT0iJGFjX2xpbmsiCitjYXNlICIo
KCRhY190cnkiIGluCisgICpcIiogfCAqXGAqIHwgKlxcKikgYWNfdHJ5X2VjaG89XCRhY190cnk7
OworICAqKSBhY190cnlfZWNobz0kYWNfdHJ5OzsKK2VzYWMKK2V2YWwgYWNfdHJ5X2VjaG89Ilwi
XCRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogJGFjX3RyeV9lY2hvXCIiCiskYXNfZWNobyAi
JGFjX3RyeV9lY2hvIjsgfSA+JjUKKyAgKGV2YWwgIiRhY19saW5rIikgMj4mNQorICBhY19zdGF0
dXM9JD8KKyAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFj
X3N0YXR1cyIgPiY1CisgIHRlc3QgJGFjX3N0YXR1cyA9IDA7IH0KKyAgaWYgeyBhY190cnk9Jy4v
Y29uZnRlc3QkYWNfY3ZfZXhlZXh0JworICB7IHsgY2FzZSAiKCgkYWNfdHJ5IiBpbgorICAqXCIq
IHwgKlxgKiB8ICpcXCopIGFjX3RyeV9lY2hvPVwkYWNfdHJ5OzsKKyAgKikgYWNfdHJ5X2VjaG89
JGFjX3RyeTs7Citlc2FjCitldmFsIGFjX3RyeV9lY2hvPSJcIlwkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306ICRhY190cnlfZWNob1wiIgorJGFzX2VjaG8gIiRhY190cnlfZWNobyI7IH0gPiY1
CisgIChldmFsICIkYWNfdHJ5IikgMj4mNQorICBhY19zdGF0dXM9JD8KKyAgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogXCQ/ID0gJGFjX3N0YXR1cyIgPiY1CisgIHRlc3Qg
JGFjX3N0YXR1cyA9IDA7IH07IH07IHRoZW4KKyAgICBjcm9zc19jb21waWxpbmc9bm8KKyAgZWxz
ZQorICAgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0gbWF5YmU7IHRoZW4KKwljcm9zc19j
b21waWxpbmc9eWVzCisgICAgZWxzZQorCXsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTog
ZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+JjI7fQorYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBydW4g
QyBjb21waWxlZCBwcm9ncmFtcy4KK0lmIHlvdSBtZWFudCB0byBjcm9zcyBjb21waWxlLCB1c2Ug
XGAtLWhvc3QnLgorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8i
IDU7IH0KKyAgICBmaQorICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkY3Jvc3NfY29tcGlsaW5nIiA+JjUKKyRhc19lY2hvICIkY3Jvc3Nf
Y29tcGlsaW5nIiA+JjY7IH0KKworcm0gLWYgY29uZnRlc3QuJGFjX2V4dCBjb25mdGVzdCRhY19j
dl9leGVleHQgY29uZnRlc3Qub3V0CithY19jbGVhbl9maWxlcz0kYWNfY2xlYW5fZmlsZXNfc2F2
ZQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
c3VmZml4IG9mIG9iamVjdCBmaWxlcyIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igc3Vm
Zml4IG9mIG9iamVjdCBmaWxlcy4uLiAiID4mNjsgfQoraWYgJHthY19jdl9vYmpleHQrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK3Jt
IC1mIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqCitpZiB7IHsgYWNfdHJ5PSIkYWNfY29tcGlsZSIK
K2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1c
JGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRhY190cnk7OworZXNhYworZXZhbCBhY190cnlf
ZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRh
c19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQorICAoZXZhbCAiJGFjX2NvbXBpbGUiKSAyPiY1
CisgIGFjX3N0YXR1cz0kPworICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNfc3RhdHVzID0gMDsgfTsgdGhlbiA6
CisgIGZvciBhY19maWxlIGluIGNvbmZ0ZXN0Lm8gY29uZnRlc3Qub2JqIGNvbmZ0ZXN0Lio7IGRv
CisgIHRlc3QgLWYgIiRhY19maWxlIiB8fCBjb250aW51ZTsKKyAgY2FzZSAkYWNfZmlsZSBpbgor
ICAgICouJGFjX2V4dCB8ICoueGNvZmYgfCAqLnRkcyB8ICouZCB8ICoucGRiIHwgKi54U1lNIHwg
Ki5iYiB8ICouYmJnIHwgKi5tYXAgfCAqLmluZiB8ICouZFNZTSApIDs7CisgICAgKikgYWNfY3Zf
b2JqZXh0PWBleHByICIkYWNfZmlsZSIgOiAnLipcLlwoLipcKSdgCisgICAgICAgYnJlYWs7Owor
ICBlc2FjCitkb25lCitlbHNlCisgICRhc19lY2hvICIkYXNfbWU6IGZhaWxlZCBwcm9ncmFtIHdh
czoiID4mNQorc2VkICdzL14vfCAvJyBjb25mdGVzdC4kYWNfZXh0ID4mNQorCit7IHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiYyO30KK2FzX2Zu
X2Vycm9yICQ/ICJjYW5ub3QgY29tcHV0ZSBzdWZmaXggb2Ygb2JqZWN0IGZpbGVzOiBjYW5ub3Qg
Y29tcGlsZQorU2VlIFxgY29uZmlnLmxvZycgZm9yIG1vcmUgZGV0YWlscyIgIiRMSU5FTk8iIDU7
IH0KK2ZpCitybSAtZiBjb25mdGVzdC4kYWNfY3Zfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X29iamV4dCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X29iamV4dCIgPiY2OyB9CitPQkpFWFQ9JGFj
X2N2X29iamV4dAorYWNfb2JqZXh0PSRPQkpFWFQKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB3ZSBhcmUgdXNpbmcgdGhlIEdOVSBDIGNv
bXBpbGVyIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRo
ZSBHTlUgQyBjb21waWxlci4uLiAiID4mNjsgfQoraWYgJHthY19jdl9jX2NvbXBpbGVyX2dudSs6
fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNh
dCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVm
cy5oLiAgKi8KKworaW50CittYWluICgpCit7CisjaWZuZGVmIF9fR05VQ19fCisgICAgICAgY2hv
a2UgbWUKKyNlbmRpZgorCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY29tcGlsZXJfZ251PXllcworZWxz
ZQorICBhY19jb21waWxlcl9nbnU9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2FjX2N2X2NfY29tcGlsZXJfZ251PSRh
Y19jb21waWxlcl9nbnUKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfY19jb21waWxlcl9nbnUiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9jX2NvbXBpbGVyX2dudSIgPiY2OyB9CitpZiB0ZXN0ICRhY19jb21waWxlcl9nbnUgPSB5ZXM7
IHRoZW4KKyAgR0NDPXllcworZWxzZQorICBHQ0M9CitmaQorYWNfdGVzdF9DRkxBR1M9JHtDRkxB
R1Mrc2V0fQorYWNfc2F2ZV9DRkxBR1M9JENGTEFHUworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nIiA+JjUKKyRh
c19lY2hvX24gImNoZWNraW5nIHdoZXRoZXIgJENDIGFjY2VwdHMgLWcuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19jY19nKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgYWNfc2F2ZV9jX3dlcnJvcl9mbGFnPSRhY19jX3dlcnJvcl9mbGFn
CisgICBhY19jX3dlcnJvcl9mbGFnPXllcworICAgYWNfY3ZfcHJvZ19jY19nPW5vCisgICBDRkxB
R1M9Ii1nIgorICAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAor
LyogZW5kIGNvbmZkZWZzLmguICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X3Byb2dfY2NfZz15ZXMKK2Vsc2UKKyAgQ0ZMQUdTPSIiCisgICAgICBjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisKK2ludAorbWFpbiAoKQoreworCisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lm
IGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQorICBhY19jX3dl
cnJvcl9mbGFnPSRhY19zYXZlX2Nfd2Vycm9yX2ZsYWcKKwkgQ0ZMQUdTPSItZyIKKwkgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworCitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3Byb2dfY2Nf
Zz15ZXMKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IGNv
bmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LiRhY19leHQKKyAgIGFjX2Nfd2Vycm9yX2ZsYWc9JGFj
X3NhdmVfY193ZXJyb3JfZmxhZworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19nIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
cHJvZ19jY19nIiA+JjY7IH0KK2lmIHRlc3QgIiRhY190ZXN0X0NGTEFHUyIgPSBzZXQ7IHRoZW4K
KyAgQ0ZMQUdTPSRhY19zYXZlX0NGTEFHUworZWxpZiB0ZXN0ICRhY19jdl9wcm9nX2NjX2cgPSB5
ZXM7IHRoZW4KKyAgaWYgdGVzdCAiJEdDQyIgPSB5ZXM7IHRoZW4KKyAgICBDRkxBR1M9Ii1nIC1P
MiIKKyAgZWxzZQorICAgIENGTEFHUz0iLWciCisgIGZpCitlbHNlCisgIGlmIHRlc3QgIiRHQ0Mi
ID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItTzIiCisgIGVsc2UKKyAgICBDRkxBR1M9CisgIGZp
CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OSIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJENDIG9wdGlvbiB0byBhY2NlcHQgSVNPIEM4OS4uLiAiID4mNjsgfQoraWYgJHthY19j
dl9wcm9nX2NjX2M4OSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGFjX2N2X3Byb2dfY2NfYzg5PW5vCithY19zYXZlX0NDPSRDQworY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVkZSA8
c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3N0YXQuaD4KKy8qIE1vc3Qgb2YgdGhlIGZvbGxv
d2luZyB0ZXN0cyBhcmUgc3RvbGVuIGZyb20gUkNTIDUuNydzIHNyYy9jb25mLnNoLiAgKi8KK3N0
cnVjdCBidWYgeyBpbnQgeDsgfTsKK0ZJTEUgKiAoKnJjc29wZW4pIChzdHJ1Y3QgYnVmICosIHN0
cnVjdCBzdGF0ICosIGludCk7CitzdGF0aWMgY2hhciAqZSAocCwgaSkKKyAgICAgY2hhciAqKnA7
CisgICAgIGludCBpOworeworICByZXR1cm4gcFtpXTsKK30KK3N0YXRpYyBjaGFyICpmIChjaGFy
ICogKCpnKSAoY2hhciAqKiwgaW50KSwgY2hhciAqKnAsIC4uLikKK3sKKyAgY2hhciAqczsKKyAg
dmFfbGlzdCB2OworICB2YV9zdGFydCAodixwKTsKKyAgcyA9IGcgKHAsIHZhX2FyZyAodixpbnQp
KTsKKyAgdmFfZW5kICh2KTsKKyAgcmV0dXJuIHM7Cit9CisKKy8qIE9TRiA0LjAgQ29tcGFxIGNj
IGlzIHNvbWUgc29ydCBvZiBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LiAgSXQgaGFzCisgICBmdW5j
dGlvbiBwcm90b3R5cGVzIGFuZCBzdHVmZiwgYnV0IG5vdCAnXHhISCcgaGV4IGNoYXJhY3RlciBj
b25zdGFudHMuCisgICBUaGVzZSBkb24ndCBwcm92b2tlIGFuIGVycm9yIHVuZm9ydHVuYXRlbHks
IGluc3RlYWQgYXJlIHNpbGVudGx5IHRyZWF0ZWQKKyAgIGFzICd4Jy4gIFRoZSBmb2xsb3dpbmcg
aW5kdWNlcyBhbiBlcnJvciwgdW50aWwgLXN0ZCBpcyBhZGRlZCB0byBnZXQKKyAgIHByb3BlciBB
TlNJIG1vZGUuICBDdXJpb3VzbHkgJ1x4MDAnIT0neCcgYWx3YXlzIGNvbWVzIG91dCB0cnVlLCBm
b3IgYW4KKyAgIGFycmF5IHNpemUgYXQgbGVhc3QuICBJdCdzIG5lY2Vzc2FyeSB0byB3cml0ZSAn
XHgwMCc9PTAgdG8gZ2V0IHNvbWV0aGluZworICAgdGhhdCdzIHRydWUgb25seSB3aXRoIC1zdGQu
ICAqLworaW50IG9zZjRfY2NfYXJyYXkgWydceDAwJyA9PSAwID8gMSA6IC0xXTsKKworLyogSUJN
IEMgNiBmb3IgQUlYIGlzIGFsbW9zdC1BTlNJIGJ5IGRlZmF1bHQsIGJ1dCBpdCByZXBsYWNlcyBt
YWNybyBwYXJhbWV0ZXJzCisgICBpbnNpZGUgc3RyaW5ncyBhbmQgY2hhcmFjdGVyIGNvbnN0YW50
cy4gICovCisjZGVmaW5lIEZPTyh4KSAneCcKK2ludCB4bGM2X2NjX2FycmF5W0ZPTyhhKSA9PSAn
eCcgPyAxIDogLTFdOworCitpbnQgdGVzdCAoaW50IGksIGRvdWJsZSB4KTsKK3N0cnVjdCBzMSB7
aW50ICgqZikgKGludCBhKTt9Oworc3RydWN0IHMyIHtpbnQgKCpmKSAoZG91YmxlIGEpO307Citp
bnQgcGFpcm5hbWVzIChpbnQsIGNoYXIgKiosIEZJTEUgKigqKShzdHJ1Y3QgYnVmICosIHN0cnVj
dCBzdGF0ICosIGludCksIGludCwgaW50KTsKK2ludCBhcmdjOworY2hhciAqKmFyZ3Y7CitpbnQK
K21haW4gKCkKK3sKK3JldHVybiBmIChlLCBhcmd2LCAwKSAhPSBhcmd2WzBdICB8fCAgZiAoZSwg
YXJndiwgMSkgIT0gYXJndlsxXTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgorZm9yIGFj
X2FyZyBpbiAnJyAtcWxhbmdsdmw9ZXh0Yzg5IC1xbGFuZ2x2bD1hbnNpIC1zdGQgXAorCS1BZSAi
LUFhIC1EX0hQVVhfU09VUkNFIiAiLVhjIC1EX19FWFRFTlNJT05TX18iCitkbworICBDQz0iJGFj
X3NhdmVfQ0MgJGFjX2FyZyIKKyAgaWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRo
ZW4gOgorICBhY19jdl9wcm9nX2NjX2M4OT0kYWNfYXJnCitmaQorcm0gLWYgY29yZSBjb25mdGVz
dC5lcnIgY29uZnRlc3QuJGFjX29iamV4dAorICB0ZXN0ICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiAh
PSAieG5vIiAmJiBicmVhaworZG9uZQorcm0gLWYgY29uZnRlc3QuJGFjX2V4dAorQ0M9JGFjX3Nh
dmVfQ0MKKworZmkKKyMgQUNfQ0FDSEVfVkFMCitjYXNlICJ4JGFjX2N2X3Byb2dfY2NfYzg5IiBp
bgorICB4KQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVz
dWx0OiBub25lIG5lZWRlZCIgPiY1CiskYXNfZWNobyAibm9uZSBuZWVkZWQiID4mNjsgfSA7Owor
ICB4bm8pCisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IHVuc3VwcG9ydGVkIiA+JjUKKyRhc19lY2hvICJ1bnN1cHBvcnRlZCIgPiY2OyB9IDs7Cisg
ICopCisgICAgQ0M9IiRDQyAkYWNfY3ZfcHJvZ19jY19jODkiCisgICAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wcm9nX2NjX2M4OSIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2NfYzg5IiA+JjY7IH0gOzsKK2VzYWMKK2lmIHRlc3Qg
IngkYWNfY3ZfcHJvZ19jY19jODkiICE9IHhubzsgdGhlbiA6CisKK2ZpCisKK2FjX2V4dD1jCith
Y19jcHA9JyRDUFAgJENQUEZMQUdTJworYWNfY29tcGlsZT0nJENDIC1jICRDRkxBR1MgJENQUEZM
QUdTIGNvbmZ0ZXN0LiRhY19leHQgPiY1JworYWNfbGluaz0nJENDIC1vIGNvbmZ0ZXN0JGFjX2V4
ZWV4dCAkQ0ZMQUdTICRDUFBGTEFHUyAkTERGTEFHUyBjb25mdGVzdC4kYWNfZXh0ICRMSUJTID4m
NScKK2FjX2NvbXBpbGVyX2dudT0kYWNfY3ZfY19jb21waWxlcl9nbnUKKworCithY19leHQ9Ywor
YWNfY3BwPSckQ1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBG
TEFHUyBjb25mdGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19l
eGVleHQgJENGTEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+
JjUnCithY19jb21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251Cit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJl
cHJvY2Vzc29yIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGhvdyB0byBydW4gdGhlIEMgcHJl
cHJvY2Vzc29yLi4uICIgPiY2OyB9CisjIE9uIFN1bnMsIHNvbWV0aW1lcyAkQ1BQIG5hbWVzIGEg
ZGlyZWN0b3J5LgoraWYgdGVzdCAtbiAiJENQUCIgJiYgdGVzdCAtZCAiJENQUCI7IHRoZW4KKyAg
Q1BQPQorZmkKK2lmIHRlc3QgLXogIiRDUFAiOyB0aGVuCisgIGlmICR7YWNfY3ZfcHJvZ19DUFAr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICAg
ICAgIyBEb3VibGUgcXVvdGVzIGJlY2F1c2UgQ1BQIG5lZWRzIHRvIGJlIGV4cGFuZGVkCisgICAg
Zm9yIENQUCBpbiAiJENDIC1FIiAiJENDIC1FIC10cmFkaXRpb25hbC1jcHAiICIvbGliL2NwcCIK
KyAgICBkbworICAgICAgYWNfcHJlcHJvY19vaz1mYWxzZQorZm9yIGFjX2NfcHJlcHJvY193YXJu
X2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRlciBmaWxlIHRoYXQgY29tZXMgd2l0
aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0aCBhIGZyZXNoIGNyb3NzLWNvbXBp
bGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRvIDxhc3NlcnQuaD4gaWYgX19TVERD
X18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+IGV4aXN0cyBldmVuIG9uIGZyZWVz
dGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQsIGNjIC1FIHJ1bnMgdGhlIGNvZGUg
dGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMgbm90IGp1c3QgdGhyb3VnaCBjcHAu
ICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhpcyBjYXNlLgorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRzLmg+CisjZWxzZQorIyBpbmNsdWRl
IDxhc3NlcnQuaD4KKyNlbmRpZgorCQkgICAgIFN5bnRheCBlcnJvcgorX0FDRU9GCitpZiBhY19m
bl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQorICAjIEJyb2tlbjogZmFpbHMg
b24gdmFsaWQgaW5wdXQuCitjb250aW51ZQorZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25mdGVz
dC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3JrcyBvbiBzYW5lIGNhc2VzLiAgTm93
IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycworICAjIGNhbiBiZSBkZXRlY3RlZCBh
bmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNfbm9uZXhpc3RlbnQuaD4KK19BQ0VP
RgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6CisgICMgQnJva2VuOiBzdWNj
ZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxzZQorICAjIFBhc3NlcyBib3RoIHRl
c3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhaworZmkKK3JtIC1mIGNvbmZ0ZXN0LmVyciBjb25m
dGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworZG9uZQorIyBCZWNhdXNlIG9mIGBicmVhaycsIF9B
Q19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNraXBwZWQuCitybSAtZiBjb25m
dGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0CitpZiAkYWNfcHJlcHJvY19vazsg
dGhlbiA6CisgIGJyZWFrCitmaQorCisgICAgZG9uZQorICAgIGFjX2N2X3Byb2dfQ1BQPSRDUFAK
KworZmkKKyAgQ1BQPSRhY19jdl9wcm9nX0NQUAorZWxzZQorICBhY19jdl9wcm9nX0NQUD0kQ1BQ
CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRD
UFAiID4mNQorJGFzX2VjaG8gIiRDUFAiID4mNjsgfQorYWNfcHJlcHJvY19vaz1mYWxzZQorZm9y
IGFjX2NfcHJlcHJvY193YXJuX2ZsYWcgaW4gJycgeWVzCitkbworICAjIFVzZSBhIGhlYWRlciBm
aWxlIHRoYXQgY29tZXMgd2l0aCBnY2MsIHNvIGNvbmZpZ3VyaW5nIGdsaWJjCisgICMgd2l0aCBh
IGZyZXNoIGNyb3NzLWNvbXBpbGVyIHdvcmtzLgorICAjIFByZWZlciA8bGltaXRzLmg+IHRvIDxh
c3NlcnQuaD4gaWYgX19TVERDX18gaXMgZGVmaW5lZCwgc2luY2UKKyAgIyA8bGltaXRzLmg+IGV4
aXN0cyBldmVuIG9uIGZyZWVzdGFuZGluZyBjb21waWxlcnMuCisgICMgT24gdGhlIE5lWFQsIGNj
IC1FIHJ1bnMgdGhlIGNvZGUgdGhyb3VnaCB0aGUgY29tcGlsZXIncyBwYXJzZXIsCisgICMgbm90
IGp1c3QgdGhyb3VnaCBjcHAuICJTeW50YXggZXJyb3IiIGlzIGhlcmUgdG8gY2F0Y2ggdGhpcyBj
YXNlLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBl
bmQgY29uZmRlZnMuaC4gICovCisjaWZkZWYgX19TVERDX18KKyMgaW5jbHVkZSA8bGltaXRzLmg+
CisjZWxzZQorIyBpbmNsdWRlIDxhc3NlcnQuaD4KKyNlbmRpZgorCQkgICAgIFN5bnRheCBlcnJv
cgorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jcHAgIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQor
ICAjIEJyb2tlbjogZmFpbHMgb24gdmFsaWQgaW5wdXQuCitjb250aW51ZQorZmkKK3JtIC1mIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworICAjIE9LLCB3b3JrcyBv
biBzYW5lIGNhc2VzLiAgTm93IGNoZWNrIHdoZXRoZXIgbm9uZXhpc3RlbnQgaGVhZGVycworICAj
IGNhbiBiZSBkZXRlY3RlZCBhbmQgaG93LgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWNfbm9u
ZXhpc3RlbnQuaD4KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY3BwICIkTElORU5PIjsgdGhlbiA6
CisgICMgQnJva2VuOiBzdWNjZXNzIG9uIGludmFsaWQgaW5wdXQuCitjb250aW51ZQorZWxzZQor
ICAjIFBhc3NlcyBib3RoIHRlc3RzLgorYWNfcHJlcHJvY19vaz06CiticmVhaworZmkKK3JtIC1m
IGNvbmZ0ZXN0LmVyciBjb25mdGVzdC5pIGNvbmZ0ZXN0LiRhY19leHQKKworZG9uZQorIyBCZWNh
dXNlIG9mIGBicmVhaycsIF9BQ19QUkVQUk9DX0lGRUxTRSdzIGNsZWFuaW5nIGNvZGUgd2FzIHNr
aXBwZWQuCitybSAtZiBjb25mdGVzdC5pIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfZXh0Citp
ZiAkYWNfcHJlcHJvY19vazsgdGhlbiA6CisKK2Vsc2UKKyAgeyB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGVycm9yOiBpbiBcYCRhY19wd2QnOiIgPiY1CiskYXNfZWNo
byAiJGFzX21lOiBlcnJvcjogaW4gXGAkYWNfcHdkJzoiID4mMjt9Cithc19mbl9lcnJvciAkPyAi
QyBwcmVwcm9jZXNzb3IgXCIkQ1BQXCIgZmFpbHMgc2FuaXR5IGNoZWNrCitTZWUgXGBjb25maWcu
bG9nJyBmb3IgbW9yZSBkZXRhaWxzIiAiJExJTkVOTyIgNTsgfQorZmkKKworYWNfZXh0PWMKK2Fj
X2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSckQ0MgLWMgJENGTEFHUyAkQ1BQRkxB
R1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSckQ0MgLW8gY29uZnRlc3QkYWNfZXhl
ZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0ZXN0LiRhY19leHQgJExJQlMgPiY1
JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVyX2dudQorCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGdyZXAgdGhhdCBoYW5k
bGVzIGxvbmcgbGluZXMgYW5kIC1lIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBncmVw
IHRoYXQgaGFuZGxlcyBsb25nIGxpbmVzIGFuZCAtZS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9w
YXRoX0dSRVArOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBpZiB0ZXN0IC16ICIkR1JFUCI7IHRoZW4KKyAgYWNfcGF0aF9HUkVQX2ZvdW5kPWZh
bHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBv
ZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9y
IGFjX3Byb2cgaW4gZ3JlcCBnZ3JlcDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFj
X2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfR1JFUD0iJGFzX2Rpci8k
YWNfcHJvZyRhY19leGVjX2V4dCIKKyAgICAgIHsgdGVzdCAtZiAiJGFjX3BhdGhfR1JFUCIgJiYg
JGFzX3Rlc3RfeCAiJGFjX3BhdGhfR1JFUCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sgZm9yIEdO
VSBhY19wYXRoX0dSRVAgYW5kIHNlbGVjdCBpdCBpZiBpdCBpcyBmb3VuZC4KKyAgIyBDaGVjayBm
b3IgR05VICRhY19wYXRoX0dSRVAKK2Nhc2UgYCIkYWNfcGF0aF9HUkVQIiAtLXZlcnNpb24gMj4m
MWAgaW4KKypHTlUqKQorICBhY19jdl9wYXRoX0dSRVA9IiRhY19wYXRoX0dSRVAiIGFjX3BhdGhf
R1JFUF9mb3VuZD06OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5
ID4iY29uZnRlc3QuaW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0LmluIiAi
Y29uZnRlc3QuaW4iID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJjb25m
dGVzdC5pbiIKKyAgICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNfZWNo
byAnR1JFUCcgPj4gImNvbmZ0ZXN0Lm5sIgorICAgICIkYWNfcGF0aF9HUkVQIiAtZSAnR1JFUCQn
IC1lICctKGNhbm5vdCBtYXRjaCktJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+
L2Rldi9udWxsIHx8IGJyZWFrCisgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3Qubmwi
ID4vZGV2L251bGwgMj4mMSB8fCBicmVhaworICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCArIDEg
JiYgYWNfY291bnQ9JGFzX3ZhbAorICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhf
R1JFUF9tYXgtMH07IHRoZW4KKyAgICAgICMgQmVzdCBvbmUgc28gZmFyLCBzYXZlIGl0IGJ1dCBr
ZWVwIGxvb2tpbmcgZm9yIGEgYmV0dGVyIG9uZQorICAgICAgYWNfY3ZfcGF0aF9HUkVQPSIkYWNf
cGF0aF9HUkVQIgorICAgICAgYWNfcGF0aF9HUkVQX21heD0kYWNfY291bnQKKyAgICBmaQorICAg
ICMgMTAqKDJeMTApIGNoYXJzIGFzIGlucHV0IHNlZW1zIG1vcmUgdGhhbiBlbm91Z2gKKyAgICB0
ZXN0ICRhY19jb3VudCAtZ3QgMTAgJiYgYnJlYWsKKyAgZG9uZQorICBybSAtZiBjb25mdGVzdC5p
biBjb25mdGVzdC50bXAgY29uZnRlc3QubmwgY29uZnRlc3Qub3V0OzsKK2VzYWMKKworICAgICAg
JGFjX3BhdGhfR1JFUF9mb3VuZCAmJiBicmVhayAzCisgICAgZG9uZQorICBkb25lCisgIGRvbmUK
K0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAteiAiJGFjX2N2X3BhdGhfR1JFUCI7IHRoZW4K
KyAgICBhc19mbl9lcnJvciAkPyAibm8gYWNjZXB0YWJsZSBncmVwIGNvdWxkIGJlIGZvdW5kIGlu
ICRQQVRIJFBBVEhfU0VQQVJBVE9SL3Vzci94cGc0L2JpbiIgIiRMSU5FTk8iIDUKKyAgZmkKK2Vs
c2UKKyAgYWNfY3ZfcGF0aF9HUkVQPSRHUkVQCitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9wYXRoX0dSRVAiID4mNQorJGFz
X2VjaG8gIiRhY19jdl9wYXRoX0dSRVAiID4mNjsgfQorIEdSRVA9IiRhY19jdl9wYXRoX0dSRVAi
CisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBm
b3IgZWdyZXAiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGVncmVwLi4uICIgPiY2OyB9
CitpZiAke2FjX2N2X3BhdGhfRUdSRVArOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBpZiBlY2hvIGEgfCAkR1JFUCAtRSAnKGF8YiknID4vZGV2
L251bGwgMj4mMQorICAgdGhlbiBhY19jdl9wYXRoX0VHUkVQPSIkR1JFUCAtRSIKKyAgIGVsc2UK
KyAgICAgaWYgdGVzdCAteiAiJEVHUkVQIjsgdGhlbgorICBhY19wYXRoX0VHUkVQX2ZvdW5kPWZh
bHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2VyJ3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBv
ZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgkUEFUSF9TRVBBUkFUT1IvdXNyL3hwZzQvYmluCitkbworICBJ
RlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9y
IGFjX3Byb2cgaW4gZWdyZXA7IGRvCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVj
dXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgICAgICBhY19wYXRoX0VHUkVQPSIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9FR1JFUCIgJiYgJGFz
X3Rlc3RfeCAiJGFjX3BhdGhfRUdSRVAiOyB9IHx8IGNvbnRpbnVlCisjIENoZWNrIGZvciBHTlUg
YWNfcGF0aF9FR1JFUCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAjIENoZWNrIGZv
ciBHTlUgJGFjX3BhdGhfRUdSRVAKK2Nhc2UgYCIkYWNfcGF0aF9FR1JFUCIgLS12ZXJzaW9uIDI+
JjFgIGluCisqR05VKikKKyAgYWNfY3ZfcGF0aF9FR1JFUD0iJGFjX3BhdGhfRUdSRVAiIGFjX3Bh
dGhfRUdSRVBfZm91bmQ9Ojs7CisqKQorICBhY19jb3VudD0wCisgICRhc19lY2hvX24gMDEyMzQ1
Njc4OSA+ImNvbmZ0ZXN0LmluIgorICB3aGlsZSA6CisgIGRvCisgICAgY2F0ICJjb25mdGVzdC5p
biIgImNvbmZ0ZXN0LmluIiA+ImNvbmZ0ZXN0LnRtcCIKKyAgICBtdiAiY29uZnRlc3QudG1wIiAi
Y29uZnRlc3QuaW4iCisgICAgY3AgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QubmwiCisgICAgJGFz
X2VjaG8gJ0VHUkVQJyA+PiAiY29uZnRlc3QubmwiCisgICAgIiRhY19wYXRoX0VHUkVQIiAnRUdS
RVAkJyA8ICJjb25mdGVzdC5ubCIgPiJjb25mdGVzdC5vdXQiIDI+L2Rldi9udWxsIHx8IGJyZWFr
CisgICAgZGlmZiAiY29uZnRlc3Qub3V0IiAiY29uZnRlc3QubmwiID4vZGV2L251bGwgMj4mMSB8
fCBicmVhaworICAgIGFzX2ZuX2FyaXRoICRhY19jb3VudCArIDEgJiYgYWNfY291bnQ9JGFzX3Zh
bAorICAgIGlmIHRlc3QgJGFjX2NvdW50IC1ndCAke2FjX3BhdGhfRUdSRVBfbWF4LTB9OyB0aGVu
CisgICAgICAjIEJlc3Qgb25lIHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBh
IGJldHRlciBvbmUKKyAgICAgIGFjX2N2X3BhdGhfRUdSRVA9IiRhY19wYXRoX0VHUkVQIgorICAg
ICAgYWNfcGF0aF9FR1JFUF9tYXg9JGFjX2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBj
aGFycyBhcyBpbnB1dCBzZWVtcyBtb3JlIHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQg
LWd0IDEwICYmIGJyZWFrCisgIGRvbmUKKyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1w
IGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX0VHUkVQ
X2ZvdW5kICYmIGJyZWFrIDMKKyAgICBkb25lCisgIGRvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworICBpZiB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9FR1JFUCI7IHRoZW4KKyAgICBhc19mbl9l
cnJvciAkPyAibm8gYWNjZXB0YWJsZSBlZ3JlcCBjb3VsZCBiZSBmb3VuZCBpbiAkUEFUSCRQQVRI
X1NFUEFSQVRPUi91c3IveHBnNC9iaW4iICIkTElORU5PIiA1CisgIGZpCitlbHNlCisgIGFjX2N2
X3BhdGhfRUdSRVA9JEVHUkVQCitmaQorCisgICBmaQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcGF0aF9FR1JFUCIgPiY1CiskYXNf
ZWNobyAiJGFjX2N2X3BhdGhfRUdSRVAiID4mNjsgfQorIEVHUkVQPSIkYWNfY3ZfcGF0aF9FR1JF
UCIKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IGZvciBBTlNJIEMgaGVhZGVyIGZpbGVzIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBB
TlNJIEMgaGVhZGVyIGZpbGVzLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2hlYWRlcl9zdGRjKzp9
IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0
IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZz
LmguICAqLworI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1ZGUgPHN0ZGFyZy5oPgorI2luY2x1
ZGUgPHN0cmluZy5oPgorI2luY2x1ZGUgPGZsb2F0Lmg+CisKK2ludAorbWFpbiAoKQoreworCisg
IDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5F
Tk8iOyB0aGVuIDoKKyAgYWNfY3ZfaGVhZGVyX3N0ZGM9eWVzCitlbHNlCisgIGFjX2N2X2hlYWRl
cl9zdGRjPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CisKK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0geWVzOyB0
aGVuCisgICMgU3VuT1MgNC54IHN0cmluZy5oIGRvZXMgbm90IGRlY2xhcmUgbWVtKiwgY29udHJh
cnkgdG8gQU5TSS4KKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4
dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUgPHN0cmluZy5oPgorCitfQUNFT0YK
K2lmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19leHQiKSAyPiY1IHwKKyAgJEVHUkVQICJt
ZW1jaHIiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY3ZfaGVhZGVyX3N0
ZGM9bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKKworZmkKKworaWYgdGVzdCAkYWNfY3ZfaGVhZGVy
X3N0ZGMgPSB5ZXM7IHRoZW4KKyAgIyBJU0MgMi4wLjIgc3RkbGliLmggZG9lcyBub3QgZGVjbGFy
ZSBmcmVlLCBjb250cmFyeSB0byBBTlNJLgorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3RkbGli
Lmg+CisKK19BQ0VPRgoraWYgKGV2YWwgIiRhY19jcHAgY29uZnRlc3QuJGFjX2V4dCIpIDI+JjUg
fAorICAkRUdSRVAgImZyZWUiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisKK2Vsc2UKKyAgYWNf
Y3ZfaGVhZGVyX3N0ZGM9bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKKworZmkKKworaWYgdGVzdCAk
YWNfY3ZfaGVhZGVyX3N0ZGMgPSB5ZXM7IHRoZW4KKyAgIyAvYmluL2NjIGluIElyaXgtNC4wLjUg
Z2V0cyBub24tQU5TSSBjdHlwZSBtYWNyb3MgdW5sZXNzIHVzaW5nIC1hbnNpLgorICBpZiB0ZXN0
ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIDoKK2Vsc2UKKyAgY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworI2luY2x1ZGUgPGN0eXBlLmg+CisjaW5jbHVkZSA8c3RkbGliLmg+CisjaWYgKCgnICcgJiAw
eDBGRikgPT0gMHgwMjApCisjIGRlZmluZSBJU0xPV0VSKGMpICgnYScgPD0gKGMpICYmIChjKSA8
PSAneicpCisjIGRlZmluZSBUT1VQUEVSKGMpIChJU0xPV0VSKGMpID8gJ0EnICsgKChjKSAtICdh
JykgOiAoYykpCisjZWxzZQorIyBkZWZpbmUgSVNMT1dFUihjKSBcCisJCSAgICgoJ2EnIDw9IChj
KSAmJiAoYykgPD0gJ2knKSBcCisJCSAgICAgfHwgKCdqJyA8PSAoYykgJiYgKGMpIDw9ICdyJykg
XAorCQkgICAgIHx8ICgncycgPD0gKGMpICYmIChjKSA8PSAneicpKQorIyBkZWZpbmUgVE9VUFBF
UihjKSAoSVNMT1dFUihjKSA/ICgoYykgfCAweDQwKSA6IChjKSkKKyNlbmRpZgorCisjZGVmaW5l
IFhPUihlLCBmKSAoKChlKSAmJiAhKGYpKSB8fCAoIShlKSAmJiAoZikpKQoraW50CittYWluICgp
Cit7CisgIGludCBpOworICBmb3IgKGkgPSAwOyBpIDwgMjU2OyBpKyspCisgICAgaWYgKFhPUiAo
aXNsb3dlciAoaSksIElTTE9XRVIgKGkpKQorCXx8IHRvdXBwZXIgKGkpICE9IFRPVVBQRVIgKGkp
KQorICAgICAgcmV0dXJuIDI7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKworZWxzZQorICBhY19jdl9oZWFkZXJfc3RkYz1ubwor
ZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29u
ZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNv
bmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3RkYyIgPiY1CiskYXNfZWNobyAi
JGFjX2N2X2hlYWRlcl9zdGRjIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRjID0g
eWVzOyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIFNURENfSEVBREVSUyAxIiA+PmNvbmZkZWZz
LmgKKworZmkKKworIyBPbiBJUklYIDUuMywgc3lzL3R5cGVzIGFuZCBpbnR0eXBlcy5oIGFyZSBj
b25mbGljdGluZy4KK2ZvciBhY19oZWFkZXIgaW4gc3lzL3R5cGVzLmggc3lzL3N0YXQuaCBzdGRs
aWIuaCBzdHJpbmcuaCBtZW1vcnkuaCBzdHJpbmdzLmggXAorCQkgIGludHR5cGVzLmggc3RkaW50
LmggdW5pc3RkLmgKK2RvIDoKKyAgYXNfYWNfSGVhZGVyPWAkYXNfZWNobyAiYWNfY3ZfaGVhZGVy
XyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19oZWFkZXJfY29tcGlsZSAi
JExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQKKyIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVhZGVyIlwiID0geCJ5ZXMiOyB0aGVu
IDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVf
JGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkKKworZG9uZQorCisKKwor
ICBhY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAibWluaXgvY29uZmlnLmgi
ICJhY19jdl9oZWFkZXJfbWluaXhfY29uZmlnX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lm
IHRlc3QgIngkYWNfY3ZfaGVhZGVyX21pbml4X2NvbmZpZ19oIiA9IHh5ZXM7IHRoZW4gOgorICBN
SU5JWD15ZXMKK2Vsc2UKKyAgTUlOSVg9CitmaQorCisKKyAgaWYgdGVzdCAiJE1JTklYIiA9IHll
czsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBfUE9TSVhfU09VUkNFIDEiID4+Y29uZmRlZnMu
aAorCisKKyRhc19lY2hvICIjZGVmaW5lIF9QT1NJWF8xX1NPVVJDRSAyIiA+PmNvbmZkZWZzLmgK
KworCiskYXNfZWNobyAiI2RlZmluZSBfTUlOSVggMSIgPj5jb25mZGVmcy5oCisKKyAgZmkKKwor
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hl
dGhlciBpdCBpcyBzYWZlIHRvIGRlZmluZSBfX0VYVEVOU0lPTlNfXyIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyIGl0IGlzIHNhZmUgdG8gZGVmaW5lIF9fRVhURU5TSU9OU19fLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fKzp9IGZh
bHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNv
bmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmgu
ICAqLworCisjCSAgZGVmaW5lIF9fRVhURU5TSU9OU19fIDEKKwkgICRhY19pbmNsdWRlc19kZWZh
dWx0CitpbnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBh
Y19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X3NhZmVfdG9fZGVm
aW5lX19fZXh0ZW5zaW9uc19fPXllcworZWxzZQorICBhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4
dGVuc2lvbnNfXz1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19v
YmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfc2FmZV90b19kZWZpbmVfX19leHRlbnNpb25zX18i
ID4mNQorJGFzX2VjaG8gIiRhY19jdl9zYWZlX3RvX2RlZmluZV9fX2V4dGVuc2lvbnNfXyIgPiY2
OyB9CisgIHRlc3QgJGFjX2N2X3NhZmVfdG9fZGVmaW5lX19fZXh0ZW5zaW9uc19fID0geWVzICYm
CisgICAgJGFzX2VjaG8gIiNkZWZpbmUgX19FWFRFTlNJT05TX18gMSIgPj5jb25mZGVmcy5oCisK
KyAgJGFzX2VjaG8gIiNkZWZpbmUgX0FMTF9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKyAgJGFz
X2VjaG8gIiNkZWZpbmUgX0dOVV9TT1VSQ0UgMSIgPj5jb25mZGVmcy5oCisKKyAgJGFzX2VjaG8g
IiNkZWZpbmUgX1BPU0lYX1BUSFJFQURfU0VNQU5USUNTIDEiID4+Y29uZmRlZnMuaAorCisgICRh
c19lY2hvICIjZGVmaW5lIF9UQU5ERU1fU09VUkNFIDEiID4+Y29uZmRlZnMuaAorCisKKyMgTWFr
ZSBzdXJlIHdlIGNhbiBydW4gY29uZmlnLnN1Yi4KKyRTSEVMTCAiJGFjX2F1eF9kaXIvY29uZmln
LnN1YiIgc3VuNCA+L2Rldi9udWxsIDI+JjEgfHwKKyAgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBy
dW4gJFNIRUxMICRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICIkTElORU5PIiA1CisKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5
cGUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgYnVpbGQgc3lzdGVtIHR5cGUuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfYnVpbGQrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2Fj
aGVkKSAiID4mNgorZWxzZQorICBhY19idWlsZF9hbGlhcz0kYnVpbGRfYWxpYXMKK3Rlc3QgIngk
YWNfYnVpbGRfYWxpYXMiID0geCAmJgorICBhY19idWlsZF9hbGlhcz1gJFNIRUxMICIkYWNfYXV4
X2Rpci9jb25maWcuZ3Vlc3MiYAordGVzdCAieCRhY19idWlsZF9hbGlhcyIgPSB4ICYmCisgIGFz
X2ZuX2Vycm9yICQ/ICJjYW5ub3QgZ3Vlc3MgYnVpbGQgdHlwZTsgeW91IG11c3Qgc3BlY2lmeSBv
bmUiICIkTElORU5PIiA1CithY19jdl9idWlsZD1gJFNIRUxMICIkYWNfYXV4X2Rpci9jb25maWcu
c3ViIiAkYWNfYnVpbGRfYWxpYXNgIHx8CisgIGFzX2ZuX2Vycm9yICQ/ICIkU0hFTEwgJGFjX2F1
eF9kaXIvY29uZmlnLnN1YiAkYWNfYnVpbGRfYWxpYXMgZmFpbGVkIiAiJExJTkVOTyIgNQorCitm
aQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19j
dl9idWlsZCIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2J1aWxkIiA+JjY7IH0KK2Nhc2UgJGFjX2N2
X2J1aWxkIGluCisqLSotKikgOzsKKyopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHZhbHVlIG9m
IGNhbm9uaWNhbCBidWlsZCIgIiRMSU5FTk8iIDU7OworZXNhYworYnVpbGQ9JGFjX2N2X2J1aWxk
CithY19zYXZlX0lGUz0kSUZTOyBJRlM9Jy0nCitzZXQgeCAkYWNfY3ZfYnVpbGQKK3NoaWZ0Citi
dWlsZF9jcHU9JDEKK2J1aWxkX3ZlbmRvcj0kMgorc2hpZnQ7IHNoaWZ0CisjIFJlbWVtYmVyLCB0
aGUgZmlyc3QgY2hhcmFjdGVyIG9mIElGUyBpcyB1c2VkIHRvIGNyZWF0ZSAkKiwKKyMgZXhjZXB0
IHdpdGggb2xkIHNoZWxsczoKK2J1aWxkX29zPSQqCitJRlM9JGFjX3NhdmVfSUZTCitjYXNlICRi
dWlsZF9vcyBpbiAqXCAqKSBidWlsZF9vcz1gZWNobyAiJGJ1aWxkX29zIiB8IHNlZCAncy8gLy0v
ZydgOzsgZXNhYworCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgaG9zdCBzeXN0ZW0gdHlwZSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBob3N0
IHN5c3RlbSB0eXBlLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2hvc3QrOn0gZmFsc2U7IHRoZW4g
OgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICJ4JGhvc3Rf
YWxpYXMiID0geDsgdGhlbgorICBhY19jdl9ob3N0PSRhY19jdl9idWlsZAorZWxzZQorICBhY19j
dl9ob3N0PWAkU0hFTEwgIiRhY19hdXhfZGlyL2NvbmZpZy5zdWIiICRob3N0X2FsaWFzYCB8fAor
ICAgIGFzX2ZuX2Vycm9yICQ/ICIkU0hFTEwgJGFjX2F1eF9kaXIvY29uZmlnLnN1YiAkaG9zdF9h
bGlhcyBmYWlsZWQiICIkTElORU5PIiA1CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9ob3N0IiA+JjUKKyRhc19lY2hvICIk
YWNfY3ZfaG9zdCIgPiY2OyB9CitjYXNlICRhY19jdl9ob3N0IGluCisqLSotKikgOzsKKyopIGFz
X2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHZhbHVlIG9mIGNhbm9uaWNhbCBob3N0IiAiJExJTkVOTyIg
NTs7Citlc2FjCitob3N0PSRhY19jdl9ob3N0CithY19zYXZlX0lGUz0kSUZTOyBJRlM9Jy0nCitz
ZXQgeCAkYWNfY3ZfaG9zdAorc2hpZnQKK2hvc3RfY3B1PSQxCitob3N0X3ZlbmRvcj0kMgorc2hp
ZnQ7IHNoaWZ0CisjIFJlbWVtYmVyLCB0aGUgZmlyc3QgY2hhcmFjdGVyIG9mIElGUyBpcyB1c2Vk
IHRvIGNyZWF0ZSAkKiwKKyMgZXhjZXB0IHdpdGggb2xkIHNoZWxsczoKK2hvc3Rfb3M9JCoKK0lG
Uz0kYWNfc2F2ZV9JRlMKK2Nhc2UgJGhvc3Rfb3MgaW4gKlwgKikgaG9zdF9vcz1gZWNobyAiJGhv
c3Rfb3MiIHwgc2VkICdzLyAvLS9nJ2A7OyBlc2FjCisKKworCisjIE00IE1hY3JvIGluY2x1ZGVz
CisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKworCisK
KworCisKKworCisKKworCisKKworCisKKworCisKKworCisKKyMgRW5hYmxlL2Rpc2FibGUgb3B0
aW9ucworIyBDaGVjayB3aGV0aGVyIC0tZW5hYmxlLXhzbSB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV94c20rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV94c207
CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieHllcyI7IHRoZW4gOgorCisgICAg
YXhfY3ZfeHNtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3hzbSIgPSAieG5vIjsgdGhlbiA6
CisKKyAgICBheF9jdl94c209Im4iCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfeHNtOyB0aGVuIDoK
KworICAgIGF4X2N2X3hzbT0ibiIKKworZmkKK3hzbT0kYXhfY3ZfeHNtCisKKyMgQ2hlY2sgd2hl
dGhlciAtLWVuYWJsZS1naXRodHRwIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2dpdGh0
dHArc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9naXRodHRwOworZmkK
KworCitpZiB0ZXN0ICJ4JGVuYWJsZV9naXRodHRwIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBh
eF9jdl9naXRodHRwPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2dpdGh0dHAiID0gInhubyI7
IHRoZW4gOgorCisgICAgYXhfY3ZfZ2l0aHR0cD0ibiIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9n
aXRodHRwOyB0aGVuIDoKKworICAgIGF4X2N2X2dpdGh0dHA9Im4iCisKK2ZpCitnaXRodHRwPSRh
eF9jdl9naXRodHRwCisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1tb25pdG9ycyB3YXMgZ2l2
ZW4uCitpZiB0ZXN0ICIke2VuYWJsZV9tb25pdG9ycytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVu
YWJsZXZhbD0kZW5hYmxlX21vbml0b3JzOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9tb25p
dG9ycyIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9tb25pdG9ycz0ibiIKKworZWxpZiB0
ZXN0ICJ4JGVuYWJsZV9tb25pdG9ycyIgPSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfbW9u
aXRvcnM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3ZfbW9uaXRvcnM7IHRoZW4gOgorCisgICAg
YXhfY3ZfbW9uaXRvcnM9InkiCisKK2ZpCittb25pdG9ycz0kYXhfY3ZfbW9uaXRvcnMKKworIyBD
aGVjayB3aGV0aGVyIC0tZW5hYmxlLXZ0cG0gd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVf
dnRwbStzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3Z0cG07CitmaQor
CisKK2lmIHRlc3QgIngkZW5hYmxlX3Z0cG0iID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2
X3Z0cG09InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfdnRwbSIgPSAieG5vIjsgdGhlbiA6CisK
KyAgICBheF9jdl92dHBtPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3Z0cG07IHRoZW4gOgor
CisgICAgYXhfY3ZfdnRwbT0ibiIKKworZmkKK3Z0cG09JGF4X2N2X3Z0cG0KKworIyBDaGVjayB3
aGV0aGVyIC0tZW5hYmxlLXhhcGkgd2FzIGdpdmVuLgoraWYgdGVzdCAiJHtlbmFibGVfeGFwaStz
ZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5hYmxlX3hhcGk7CitmaQorCisKK2lm
IHRlc3QgIngkZW5hYmxlX3hhcGkiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X3hhcGk9
InkiCisKK2VsaWYgdGVzdCAieCRlbmFibGVfeGFwaSIgPSAieG5vIjsgdGhlbiA6CisKKyAgICBh
eF9jdl94YXBpPSJuIgorCitlbGlmIHRlc3QgLXogJGF4X2N2X3hhcGk7IHRoZW4gOgorCisgICAg
YXhfY3ZfeGFwaT0ibiIKKworZmkKK3hhcGk9JGF4X2N2X3hhcGkKKworIyBDaGVjayB3aGV0aGVy
IC0tZW5hYmxlLXB5dGhvbnRvb2xzIHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX3B5dGhv
bnRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFibGVfcHl0aG9udG9v
bHM7CitmaQorCisKK2lmIHRlc3QgIngkZW5hYmxlX3B5dGhvbnRvb2xzIiA9ICJ4bm8iOyB0aGVu
IDoKKworICAgIGF4X2N2X3B5dGhvbnRvb2xzPSJuIgorCitlbGlmIHRlc3QgIngkZW5hYmxlX3B5
dGhvbnRvb2xzIiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9weXRob250b29scz0ieSIK
KworZWxpZiB0ZXN0IC16ICRheF9jdl9weXRob250b29sczsgdGhlbiA6CisKKyAgICBheF9jdl9w
eXRob250b29scz0ieSIKKworZmkKK3B5dGhvbnRvb2xzPSRheF9jdl9weXRob250b29scworCisj
IENoZWNrIHdoZXRoZXIgLS1lbmFibGUtb2NhbWx0b29scyB3YXMgZ2l2ZW4uCitpZiB0ZXN0ICIk
e2VuYWJsZV9vY2FtbHRvb2xzK3NldH0iID0gc2V0OyB0aGVuIDoKKyAgZW5hYmxldmFsPSRlbmFi
bGVfb2NhbWx0b29sczsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICBheF9jdl9vY2FtbHRvb2xzPSJuIgorCitlbGlmIHRlc3QgIngk
ZW5hYmxlX29jYW1sdG9vbHMiID0gInh5ZXMiOyB0aGVuIDoKKworICAgIGF4X2N2X29jYW1sdG9v
bHM9InkiCisKK2VsaWYgdGVzdCAteiAkYXhfY3Zfb2NhbWx0b29sczsgdGhlbiA6CisKKyAgICBh
eF9jdl9vY2FtbHRvb2xzPSJ5IgorCitmaQorb2NhbWx0b29scz0kYXhfY3Zfb2NhbWx0b29scwor
CisjIENoZWNrIHdoZXRoZXIgLS1lbmFibGUtbWluaXRlcm0gd2FzIGdpdmVuLgoraWYgdGVzdCAi
JHtlbmFibGVfbWluaXRlcm0rc2V0fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJs
ZV9taW5pdGVybTsKK2ZpCisKKworaWYgdGVzdCAieCRlbmFibGVfbWluaXRlcm0iID0gInh5ZXMi
OyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxl
X21pbml0ZXJtIiA9ICJ4bm8iOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJtPSJuIgorCitl
bGlmIHRlc3QgLXogJGF4X2N2X21pbml0ZXJtOyB0aGVuIDoKKworICAgIGF4X2N2X21pbml0ZXJt
PSJuIgorCitmaQorbWluaXRlcm09JGF4X2N2X21pbml0ZXJtCisKKyMgQ2hlY2sgd2hldGhlciAt
LWVuYWJsZS1sb21vdW50IHdhcyBnaXZlbi4KK2lmIHRlc3QgIiR7ZW5hYmxlX2xvbW91bnQrc2V0
fSIgPSBzZXQ7IHRoZW4gOgorICBlbmFibGV2YWw9JGVuYWJsZV9sb21vdW50OworZmkKKworCitp
ZiB0ZXN0ICJ4JGVuYWJsZV9sb21vdW50IiA9ICJ4eWVzIjsgdGhlbiA6CisKKyAgICBheF9jdl9s
b21vdW50PSJ5IgorCitlbGlmIHRlc3QgIngkZW5hYmxlX2xvbW91bnQiID0gInhubyI7IHRoZW4g
OgorCisgICAgYXhfY3ZfbG9tb3VudD0ibiIKKworZWxpZiB0ZXN0IC16ICRheF9jdl9sb21vdW50
OyB0aGVuIDoKKworICAgIGF4X2N2X2xvbW91bnQ9Im4iCisKK2ZpCitsb21vdW50PSRheF9jdl9s
b21vdW50CisKKyMgQ2hlY2sgd2hldGhlciAtLWVuYWJsZS1kZWJ1ZyB3YXMgZ2l2ZW4uCitpZiB0
ZXN0ICIke2VuYWJsZV9kZWJ1ZytzZXR9IiA9IHNldDsgdGhlbiA6CisgIGVuYWJsZXZhbD0kZW5h
YmxlX2RlYnVnOworZmkKKworCitpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIgPSAieG5vIjsgdGhl
biA6CisKKyAgICBheF9jdl9kZWJ1Zz0ibiIKKworZWxpZiB0ZXN0ICJ4JGVuYWJsZV9kZWJ1ZyIg
PSAieHllcyI7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2VsaWYgdGVzdCAteiAk
YXhfY3ZfZGVidWc7IHRoZW4gOgorCisgICAgYXhfY3ZfZGVidWc9InkiCisKK2ZpCitkZWJ1Zz0k
YXhfY3ZfZGVidWcKKworCisKKworCisKKworZm9yIGNmbGFnIGluICRQUkVQRU5EX0lOQ0xVREVT
CitkbworICAgIFBSRVBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBp
biAkUFJFUEVORF9MSUIKK2RvCisgICAgUFJFUEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2Rv
bmUKK2ZvciBjZmxhZyBpbiAkQVBQRU5EX0lOQ0xVREVTCitkbworICAgIEFQUEVORF9DRkxBR1Mr
PSIgLUkkY2ZsYWciCitkb25lCitmb3IgbGRmbGFnIGluICRBUFBFTkRfTElCCitkbworICAgIEFQ
UEVORF9MREZMQUdTKz0iIC1MJGxkZmxhZyIKK2RvbmUKK0NGTEFHUz0iJFBSRVBFTkRfQ0ZMQUdT
ICRDRkxBR1MgJEFQUEVORF9DRkxBR1MiCitMREZMQUdTPSIkUFJFUEVORF9MREZMQUdTICRMREZM
QUdTICRBUFBFTkRfTERGTEFHUyIKKworCisKKworCisKKworCisKKworCisKKyMgQ2hlY2tzIGZv
ciBwcm9ncmFtcy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hl
Y2tpbmcgZm9yIGEgc2VkIHRoYXQgZG9lcyBub3QgdHJ1bmNhdGUgb3V0cHV0IiA+JjUKKyRhc19l
Y2hvX24gImNoZWNraW5nIGZvciBhIHNlZCB0aGF0IGRvZXMgbm90IHRydW5jYXRlIG91dHB1dC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX1NFRCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19l
Y2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgICAgICAgICAgICBhY19zY3JpcHQ9cy9hYWFh
YWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYS9iYmJiYmJiYmJiYmJiYmJiYmJiYmJiYmJi
YmJiYmJiYmIvCisgICAgIGZvciBhY19pIGluIDEgMiAzIDQgNSA2IDc7IGRvCisgICAgICAgYWNf
c2NyaXB0PSIkYWNfc2NyaXB0JGFzX25sJGFjX3NjcmlwdCIKKyAgICAgZG9uZQorICAgICBlY2hv
ICIkYWNfc2NyaXB0IiAyPi9kZXYvbnVsbCB8IHNlZCA5OXEgPmNvbmZ0ZXN0LnNlZAorICAgICB7
IGFjX3NjcmlwdD07IHVuc2V0IGFjX3NjcmlwdDt9CisgICAgIGlmIHRlc3QgLXogIiRTRUQiOyB0
aGVuCisgIGFjX3BhdGhfU0VEX2ZvdW5kPWZhbHNlCisgICMgTG9vcCB0aHJvdWdoIHRoZSB1c2Vy
J3MgcGF0aCBhbmQgdGVzdCBmb3IgZWFjaCBvZiBQUk9HTkFNRS1MSVNUCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfcHJvZyBpbiBzZWQgZ3NlZDsgZG8KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgICAgIGFjX3BhdGhfU0VEPSIkYXNfZGlyLyRhY19w
cm9nJGFjX2V4ZWNfZXh0IgorICAgICAgeyB0ZXN0IC1mICIkYWNfcGF0aF9TRUQiICYmICRhc190
ZXN0X3ggIiRhY19wYXRoX1NFRCI7IH0gfHwgY29udGludWUKKyMgQ2hlY2sgZm9yIEdOVSBhY19w
YXRoX1NFRCBhbmQgc2VsZWN0IGl0IGlmIGl0IGlzIGZvdW5kLgorICAjIENoZWNrIGZvciBHTlUg
JGFjX3BhdGhfU0VECitjYXNlIGAiJGFjX3BhdGhfU0VEIiAtLXZlcnNpb24gMj4mMWAgaW4KKypH
TlUqKQorICBhY19jdl9wYXRoX1NFRD0iJGFjX3BhdGhfU0VEIiBhY19wYXRoX1NFRF9mb3VuZD06
OzsKKyopCisgIGFjX2NvdW50PTAKKyAgJGFzX2VjaG9fbiAwMTIzNDU2Nzg5ID4iY29uZnRlc3Qu
aW4iCisgIHdoaWxlIDoKKyAgZG8KKyAgICBjYXQgImNvbmZ0ZXN0LmluIiAiY29uZnRlc3QuaW4i
ID4iY29uZnRlc3QudG1wIgorICAgIG12ICJjb25mdGVzdC50bXAiICJjb25mdGVzdC5pbiIKKyAg
ICBjcCAiY29uZnRlc3QuaW4iICJjb25mdGVzdC5ubCIKKyAgICAkYXNfZWNobyAnJyA+PiAiY29u
ZnRlc3QubmwiCisgICAgIiRhY19wYXRoX1NFRCIgLWYgY29uZnRlc3Quc2VkIDwgImNvbmZ0ZXN0
Lm5sIiA+ImNvbmZ0ZXN0Lm91dCIgMj4vZGV2L251bGwgfHwgYnJlYWsKKyAgICBkaWZmICJjb25m
dGVzdC5vdXQiICJjb25mdGVzdC5ubCIgPi9kZXYvbnVsbCAyPiYxIHx8IGJyZWFrCisgICAgYXNf
Zm5fYXJpdGggJGFjX2NvdW50ICsgMSAmJiBhY19jb3VudD0kYXNfdmFsCisgICAgaWYgdGVzdCAk
YWNfY291bnQgLWd0ICR7YWNfcGF0aF9TRURfbWF4LTB9OyB0aGVuCisgICAgICAjIEJlc3Qgb25l
IHNvIGZhciwgc2F2ZSBpdCBidXQga2VlcCBsb29raW5nIGZvciBhIGJldHRlciBvbmUKKyAgICAg
IGFjX2N2X3BhdGhfU0VEPSIkYWNfcGF0aF9TRUQiCisgICAgICBhY19wYXRoX1NFRF9tYXg9JGFj
X2NvdW50CisgICAgZmkKKyAgICAjIDEwKigyXjEwKSBjaGFycyBhcyBpbnB1dCBzZWVtcyBtb3Jl
IHRoYW4gZW5vdWdoCisgICAgdGVzdCAkYWNfY291bnQgLWd0IDEwICYmIGJyZWFrCisgIGRvbmUK
KyAgcm0gLWYgY29uZnRlc3QuaW4gY29uZnRlc3QudG1wIGNvbmZ0ZXN0Lm5sIGNvbmZ0ZXN0Lm91
dDs7Citlc2FjCisKKyAgICAgICRhY19wYXRoX1NFRF9mb3VuZCAmJiBicmVhayAzCisgICAgZG9u
ZQorICBkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKyAgaWYgdGVzdCAteiAiJGFjX2N2
X3BhdGhfU0VEIjsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJubyBhY2NlcHRhYmxlIHNlZCBj
b3VsZCBiZSBmb3VuZCBpbiBcJFBBVEgiICIkTElORU5PIiA1CisgIGZpCitlbHNlCisgIGFjX2N2
X3BhdGhfU0VEPSRTRUQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IHJlc3VsdDogJGFjX2N2X3BhdGhfU0VEIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zf
cGF0aF9TRUQiID4mNjsgfQorIFNFRD0iJGFjX2N2X3BhdGhfU0VEIgorICBybSAtZiBjb25mdGVz
dC5zZWQKKworYWNfZXh0PWMKK2FjX2NwcD0nJENQUCAkQ1BQRkxBR1MnCithY19jb21waWxlPSck
Q0MgLWMgJENGTEFHUyAkQ1BQRkxBR1MgY29uZnRlc3QuJGFjX2V4dCA+JjUnCithY19saW5rPSck
Q0MgLW8gY29uZnRlc3QkYWNfZXhlZXh0ICRDRkxBR1MgJENQUEZMQUdTICRMREZMQUdTIGNvbmZ0
ZXN0LiRhY19leHQgJExJQlMgPiY1JworYWNfY29tcGlsZXJfZ251PSRhY19jdl9jX2NvbXBpbGVy
X2dudQoraWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhl
IGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9Z2NjIiwgc28gaXQgY2FuIGJlIGEgcHJv
Z3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWdjYzsgYWNf
d29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2lu
ZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4u
ICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNo
b19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkQ0MiOyB0aGVuCisgIGFj
X2N2X3Byb2dfQ0M9IiRDQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNl
Cithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wcm9nX0NDPSIke2FjX3Rvb2xfcHJlZml4fWdjYyIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwor
ZmkKK2ZpCitDQz0kYWNfY3ZfcHJvZ19DQworaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJENDIiA+JjUKKyRh
c19lY2hvICIkQ0MiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisK
KworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX0NDIjsgdGhlbgorICBhY19jdF9DQz0kQ0MK
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJnY2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGdjYzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3Byb2dfYWNfY3RfQ0MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkYWNfY3RfQ0MiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfQ0M9IiRhY19jdF9DQyIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qu
CitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGly
IGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYm
IGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVu
c2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
JiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAg
ICBhY19jdl9wcm9nX2FjX2N0X0NDPSJnY2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitm
aQorYWNfY3RfQ0M9JGFjX2N2X3Byb2dfYWNfY3RfQ0MKK2lmIHRlc3QgLW4gIiRhY19jdF9DQyI7
IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
ICRhY19jdF9DQyIgPiY1CiskYXNfZWNobyAiJGFjX2N0X0NDIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfQ0MiID0geDsgdGhl
bgorICAgIENDPSIiCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xf
d2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90
IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7
Citlc2FjCisgICAgQ0M9JGFjX2N0X0NDCisgIGZpCitlbHNlCisgIENDPSIkYWNfY3ZfcHJvZ19D
QyIKK2ZpCisKK2lmIHRlc3QgLXogIiRDQyI7IHRoZW4KKyAgICAgICAgICBpZiB0ZXN0IC1uICIk
YWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIk
e2FjX3Rvb2xfcHJlZml4fWNjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fWNjOyBhY193b3JkPSQyCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1
CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19DQz0iJENDIiAj
IExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7
IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNf
c2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhl
Y19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1m
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfQ0M9IiR7YWNfdG9v
bF9wcmVmaXh9Y2MiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Zm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBm
aQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorQ0M9JGFjX2N2X3By
b2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgZmkKK2ZpCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiY2MiLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGNjOyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19DQz0iJENDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKKyAg
YWNfcHJvZ19yZWplY3RlZD1ubworYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCisgICAgaWYgdGVzdCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPSAi
L3Vzci91Y2IvY2MiOyB0aGVuCisgICAgICAgYWNfcHJvZ19yZWplY3RlZD15ZXMKKyAgICAgICBj
b250aW51ZQorICAgICBmaQorICAgIGFjX2N2X3Byb2dfQ0M9ImNjIgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCitpZiB0ZXN0ICRhY19wcm9nX3JlamVjdGVkID0geWVzOyB0aGVuCisgICMgV2UgZm91
bmQgYSBib2dvbiBpbiB0aGUgcGF0aCwgc28gbWFrZSBzdXJlIHdlIG5ldmVyIHVzZSBpdC4KKyAg
c2V0IGR1bW15ICRhY19jdl9wcm9nX0NDCisgIHNoaWZ0CisgIGlmIHRlc3QgJCMgIT0gMDsgdGhl
bgorICAgICMgV2UgY2hvc2UgYSBkaWZmZXJlbnQgY29tcGlsZXIgZnJvbSB0aGUgYm9ndXMgb25l
LgorICAgICMgSG93ZXZlciwgaXQgaGFzIHRoZSBzYW1lIGJhc2VuYW1lLCBzbyB0aGUgYm9nb24g
d2lsbCBiZSBjaG9zZW4KKyAgICAjIGZpcnN0IGlmIHdlIHNldCBDQyB0byBqdXN0IHRoZSBiYXNl
bmFtZTsgdXNlIHRoZSBmdWxsIGZpbGUgbmFtZS4KKyAgICBzaGlmdAorICAgIGFjX2N2X3Byb2df
Q0M9IiRhc19kaXIvJGFjX3dvcmQkezErJyAnfSRAIgorICBmaQorZmkKK2ZpCitmaQorQ0M9JGFj
X2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNfZWNobyAiJENDIiA+
JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0
IC16ICIkQ0MiOyB0aGVuCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
Zm9yIGFjX3Byb2cgaW4gY2wuZXhlCisgIGRvCisgICAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3Jk
IG9mICIkYWNfdG9vbF9wcmVmaXgkYWNfcHJvZyIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2c7IGFjX3dvcmQ9
JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9y
ICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4m
NjsgfQoraWYgJHthY19jdl9wcm9nX0NDKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJENDIjsgdGhlbgorICBhY19jdl9w
cm9nX0NDPSIkQ0MiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19DQz0iJGFjX3Rvb2xfcHJlZml4JGFjX3Byb2ciCisgICAgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1
CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2Zp
CitmaQorQ0M9JGFjX2N2X3Byb2dfQ0MKK2lmIHRlc3QgLW4gIiRDQyI7IHRoZW4KKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRDQyIgPiY1CiskYXNf
ZWNobyAiJENDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisK
KyAgICB0ZXN0IC1uICIkQ0MiICYmIGJyZWFrCisgIGRvbmUKK2ZpCitpZiB0ZXN0IC16ICIkQ0Mi
OyB0aGVuCisgIGFjX2N0X0NDPSRDQworICBmb3IgYWNfcHJvZyBpbiBjbC5leGUKK2RvCisgICMg
RXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiJGFjX3Byb2ciLCBzbyBpdCBjYW4gYmUgYSBwcm9n
cmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICRhY19wcm9nOyBhY193b3JkPSQyCit7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29y
ZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lm
ICR7YWNfY3ZfcHJvZ19hY19jdF9DQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9DQyI7IHRoZW4KKyAgYWNf
Y3ZfcHJvZ19hY19jdF9DQz0iJGFjX2N0X0NDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUg
dGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBh
c19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2Rp
ciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVf
ZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNf
ZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhl
bgorICAgIGFjX2N2X3Byb2dfYWNfY3RfQ0M9IiRhY19wcm9nIgorICAgICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lG
UworCitmaQorZmkKK2FjX2N0X0NDPSRhY19jdl9wcm9nX2FjX2N0X0NDCitpZiB0ZXN0IC1uICIk
YWNfY3RfQ0MiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfQ0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9DQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgIHRlc3QgLW4gIiRhY19jdF9D
QyIgJiYgYnJlYWsKK2RvbmUKKworICBpZiB0ZXN0ICJ4JGFjX2N0X0NDIiA9IHg7IHRoZW4KKyAg
ICBDQz0iIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGlsaW5nOiRhY190b29sX3dhcm5l
ZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FS
TklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+
JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVm
aXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xfd2FybmVkPXllcyA7OworZXNh
YworICAgIENDPSRhY19jdF9DQworICBmaQorZmkKKworZmkKKworCit0ZXN0IC16ICIkQ0MiICYm
IHsgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBlcnJvcjogaW4gXGAk
YWNfcHdkJzoiID4mNQorJGFzX2VjaG8gIiRhc19tZTogZXJyb3I6IGluIFxgJGFjX3B3ZCc6IiA+
JjI7fQorYXNfZm5fZXJyb3IgJD8gIm5vIGFjY2VwdGFibGUgQyBjb21waWxlciBmb3VuZCBpbiBc
JFBBVEgKK1NlZSBcYGNvbmZpZy5sb2cnIGZvciBtb3JlIGRldGFpbHMiICIkTElORU5PIiA1OyB9
CisKKyMgUHJvdmlkZSBzb21lIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb21waWxlci4KKyRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBDIGNvbXBpbGVy
IHZlcnNpb24iID4mNQorc2V0IFggJGFjX2NvbXBpbGUKK2FjX2NvbXBpbGVyPSQyCitmb3IgYWNf
b3B0aW9uIGluIC0tdmVyc2lvbiAtdiAtViAtcXZlcnNpb247IGRvCisgIHsgeyBhY190cnk9IiRh
Y19jb21waWxlciAkYWNfb3B0aW9uID4mNSIKK2Nhc2UgIigoJGFjX3RyeSIgaW4KKyAgKlwiKiB8
ICpcYCogfCAqXFwqKSBhY190cnlfZWNobz1cJGFjX3RyeTs7CisgICopIGFjX3RyeV9lY2hvPSRh
Y190cnk7OworZXNhYworZXZhbCBhY190cnlfZWNobz0iXCJcJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiAkYWNfdHJ5X2VjaG9cIiIKKyRhc19lY2hvICIkYWNfdHJ5X2VjaG8iOyB9ID4mNQor
ICAoZXZhbCAiJGFjX2NvbXBpbGVyICRhY19vcHRpb24gPiY1IikgMj5jb25mdGVzdC5lcnIKKyAg
YWNfc3RhdHVzPSQ/CisgIGlmIHRlc3QgLXMgY29uZnRlc3QuZXJyOyB0aGVuCisgICAgc2VkICcx
MGFcCisuLi4gcmVzdCBvZiBzdGRlcnIgb3V0cHV0IGRlbGV0ZWQgLi4uCisgICAgICAgICAxMHEn
IGNvbmZ0ZXN0LmVyciA+Y29uZnRlc3QuZXIxCisgICAgY2F0IGNvbmZ0ZXN0LmVyMSA+JjUKKyAg
ZmkKKyAgcm0gLWYgY29uZnRlc3QuZXIxIGNvbmZ0ZXN0LmVycgorICAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBcJD8gPSAkYWNfc3RhdHVzIiA+JjUKKyAgdGVzdCAkYWNf
c3RhdHVzID0gMDsgfQorZG9uZQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIHdoZXRoZXIgd2UgYXJlIHVzaW5nIHRoZSBHTlUgQyBjb21waWxlciIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIHdlIGFyZSB1c2luZyB0aGUgR05VIEMg
Y29tcGlsZXIuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19jb21waWxlcl9nbnUrOn0gZmFsc2U7
IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQgY29uZmRl
ZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICov
CisKK2ludAorbWFpbiAoKQoreworI2lmbmRlZiBfX0dOVUNfXworICAgICAgIGNob2tlIG1lCisj
ZW5kaWYKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21w
aWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2NvbXBpbGVyX2dudT15ZXMKK2Vsc2UKKyAgYWNf
Y29tcGlsZXJfZ251PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CithY19jdl9jX2NvbXBpbGVyX2dudT0kYWNfY29tcGls
ZXJfZ251CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2NfY29tcGlsZXJfZ251IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19jb21w
aWxlcl9nbnUiID4mNjsgfQoraWYgdGVzdCAkYWNfY29tcGlsZXJfZ251ID0geWVzOyB0aGVuCisg
IEdDQz15ZXMKK2Vsc2UKKyAgR0NDPQorZmkKK2FjX3Rlc3RfQ0ZMQUdTPSR7Q0ZMQUdTK3NldH0K
K2FjX3NhdmVfQ0ZMQUdTPSRDRkxBR1MKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgd2hldGhlciAkQ0MgYWNjZXB0cyAtZyIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyB3aGV0aGVyICRDQyBhY2NlcHRzIC1nLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3Byb2dfY2NfZys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGFjX3NhdmVfY193ZXJyb3JfZmxhZz0kYWNfY193ZXJyb3JfZmxhZworICAgYWNf
Y193ZXJyb3JfZmxhZz15ZXMKKyAgIGFjX2N2X3Byb2dfY2NfZz1ubworICAgQ0ZMQUdTPSItZyIK
KyAgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKworaW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30K
K19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9wcm9nX2NjX2c9eWVzCitlbHNlCisgIENGTEFHUz0iIgorICAgICAgY2F0IGNvbmZkZWZzLmgg
LSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCitp
bnQKK21haW4gKCkKK3sKKworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9j
X3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisKK2Vsc2UKKyAgYWNfY193ZXJyb3JfZmxh
Zz0kYWNfc2F2ZV9jX3dlcnJvcl9mbGFnCisJIENGTEFHUz0iLWciCisJIGNhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKwor
aW50CittYWluICgpCit7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9wcm9nX2NjX2c9eWVzCitm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4k
YWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBj
b25mdGVzdC4kYWNfZXh0CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFj
X29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICBhY19jX3dlcnJvcl9mbGFnPSRhY19zYXZlX2Nf
d2Vycm9yX2ZsYWcKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X3Byb2dfY2NfZyIgPiY1CiskYXNfZWNobyAiJGFjX2N2X3Byb2dfY2Nf
ZyIgPiY2OyB9CitpZiB0ZXN0ICIkYWNfdGVzdF9DRkxBR1MiID0gc2V0OyB0aGVuCisgIENGTEFH
Uz0kYWNfc2F2ZV9DRkxBR1MKK2VsaWYgdGVzdCAkYWNfY3ZfcHJvZ19jY19nID0geWVzOyB0aGVu
CisgIGlmIHRlc3QgIiRHQ0MiID0geWVzOyB0aGVuCisgICAgQ0ZMQUdTPSItZyAtTzIiCisgIGVs
c2UKKyAgICBDRkxBR1M9Ii1nIgorICBmaQorZWxzZQorICBpZiB0ZXN0ICIkR0NDIiA9IHllczsg
dGhlbgorICAgIENGTEFHUz0iLU8yIgorICBlbHNlCisgICAgQ0ZMQUdTPQorICBmaQorZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRDQyBv
cHRpb24gdG8gYWNjZXB0IElTTyBDODkiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRD
QyBvcHRpb24gdG8gYWNjZXB0IElTTyBDODkuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19j
Y19jODkrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBhY19jdl9wcm9nX2NjX2M4OT1ubworYWNfc2F2ZV9DQz0kQ0MKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNp
bmNsdWRlIDxzdGRhcmcuaD4KKyNpbmNsdWRlIDxzdGRpby5oPgorI2luY2x1ZGUgPHN5cy90eXBl
cy5oPgorI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CisvKiBNb3N0IG9mIHRoZSBmb2xsb3dpbmcgdGVz
dHMgYXJlIHN0b2xlbiBmcm9tIFJDUyA1LjcncyBzcmMvY29uZi5zaC4gICovCitzdHJ1Y3QgYnVm
IHsgaW50IHg7IH07CitGSUxFICogKCpyY3NvcGVuKSAoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3Rh
dCAqLCBpbnQpOworc3RhdGljIGNoYXIgKmUgKHAsIGkpCisgICAgIGNoYXIgKipwOworICAgICBp
bnQgaTsKK3sKKyAgcmV0dXJuIHBbaV07Cit9CitzdGF0aWMgY2hhciAqZiAoY2hhciAqICgqZykg
KGNoYXIgKiosIGludCksIGNoYXIgKipwLCAuLi4pCit7CisgIGNoYXIgKnM7CisgIHZhX2xpc3Qg
djsKKyAgdmFfc3RhcnQgKHYscCk7CisgIHMgPSBnIChwLCB2YV9hcmcgKHYsaW50KSk7CisgIHZh
X2VuZCAodik7CisgIHJldHVybiBzOworfQorCisvKiBPU0YgNC4wIENvbXBhcSBjYyBpcyBzb21l
IHNvcnQgb2YgYWxtb3N0LUFOU0kgYnkgZGVmYXVsdC4gIEl0IGhhcworICAgZnVuY3Rpb24gcHJv
dG90eXBlcyBhbmQgc3R1ZmYsIGJ1dCBub3QgJ1x4SEgnIGhleCBjaGFyYWN0ZXIgY29uc3RhbnRz
LgorICAgVGhlc2UgZG9uJ3QgcHJvdm9rZSBhbiBlcnJvciB1bmZvcnR1bmF0ZWx5LCBpbnN0ZWFk
IGFyZSBzaWxlbnRseSB0cmVhdGVkCisgICBhcyAneCcuICBUaGUgZm9sbG93aW5nIGluZHVjZXMg
YW4gZXJyb3IsIHVudGlsIC1zdGQgaXMgYWRkZWQgdG8gZ2V0CisgICBwcm9wZXIgQU5TSSBtb2Rl
LiAgQ3VyaW91c2x5ICdceDAwJyE9J3gnIGFsd2F5cyBjb21lcyBvdXQgdHJ1ZSwgZm9yIGFuCisg
ICBhcnJheSBzaXplIGF0IGxlYXN0LiAgSXQncyBuZWNlc3NhcnkgdG8gd3JpdGUgJ1x4MDAnPT0w
IHRvIGdldCBzb21ldGhpbmcKKyAgIHRoYXQncyB0cnVlIG9ubHkgd2l0aCAtc3RkLiAgKi8KK2lu
dCBvc2Y0X2NjX2FycmF5IFsnXHgwMCcgPT0gMCA/IDEgOiAtMV07CisKKy8qIElCTSBDIDYgZm9y
IEFJWCBpcyBhbG1vc3QtQU5TSSBieSBkZWZhdWx0LCBidXQgaXQgcmVwbGFjZXMgbWFjcm8gcGFy
YW1ldGVycworICAgaW5zaWRlIHN0cmluZ3MgYW5kIGNoYXJhY3RlciBjb25zdGFudHMuICAqLwor
I2RlZmluZSBGT08oeCkgJ3gnCitpbnQgeGxjNl9jY19hcnJheVtGT08oYSkgPT0gJ3gnID8gMSA6
IC0xXTsKKworaW50IHRlc3QgKGludCBpLCBkb3VibGUgeCk7CitzdHJ1Y3QgczEge2ludCAoKmYp
IChpbnQgYSk7fTsKK3N0cnVjdCBzMiB7aW50ICgqZikgKGRvdWJsZSBhKTt9OworaW50IHBhaXJu
YW1lcyAoaW50LCBjaGFyICoqLCBGSUxFICooKikoc3RydWN0IGJ1ZiAqLCBzdHJ1Y3Qgc3RhdCAq
LCBpbnQpLCBpbnQsIGludCk7CitpbnQgYXJnYzsKK2NoYXIgKiphcmd2OworaW50CittYWluICgp
Cit7CityZXR1cm4gZiAoZSwgYXJndiwgMCkgIT0gYXJndlswXSAgfHwgIGYgKGUsIGFyZ3YsIDEp
ICE9IGFyZ3ZbMV07CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2ZvciBhY19hcmcgaW4g
JycgLXFsYW5nbHZsPWV4dGM4OSAtcWxhbmdsdmw9YW5zaSAtc3RkIFwKKwktQWUgIi1BYSAtRF9I
UFVYX1NPVVJDRSIgIi1YYyAtRF9fRVhURU5TSU9OU19fIgorZG8KKyAgQ0M9IiRhY19zYXZlX0ND
ICRhY19hcmciCisgIGlmIGFjX2ZuX2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAg
YWNfY3ZfcHJvZ19jY19jODk9JGFjX2FyZworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNv
bmZ0ZXN0LiRhY19vYmpleHQKKyAgdGVzdCAieCRhY19jdl9wcm9nX2NjX2M4OSIgIT0gInhubyIg
JiYgYnJlYWsKK2RvbmUKK3JtIC1mIGNvbmZ0ZXN0LiRhY19leHQKK0NDPSRhY19zYXZlX0NDCisK
K2ZpCisjIEFDX0NBQ0hFX1ZBTAorY2FzZSAieCRhY19jdl9wcm9nX2NjX2M4OSIgaW4KKyAgeCkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm9u
ZSBuZWVkZWQiID4mNQorJGFzX2VjaG8gIm5vbmUgbmVlZGVkIiA+JjY7IH0gOzsKKyAgeG5vKQor
ICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB1bnN1
cHBvcnRlZCIgPiY1CiskYXNfZWNobyAidW5zdXBwb3J0ZWQiID4mNjsgfSA7OworICAqKQorICAg
IENDPSIkQ0MgJGFjX2N2X3Byb2dfY2NfYzg5IgorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2Fz
X2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfcHJvZ19jY19jODkiID4mNQorJGFzX2Vj
aG8gIiRhY19jdl9wcm9nX2NjX2M4OSIgPiY2OyB9IDs7Citlc2FjCitpZiB0ZXN0ICJ4JGFjX2N2
X3Byb2dfY2NfYzg5IiAhPSB4bm87IHRoZW4gOgorCitmaQorCithY19leHQ9YworYWNfY3BwPSck
Q1BQICRDUFBGTEFHUycKK2FjX2NvbXBpbGU9JyRDQyAtYyAkQ0ZMQUdTICRDUFBGTEFHUyBjb25m
dGVzdC4kYWNfZXh0ID4mNScKK2FjX2xpbms9JyRDQyAtbyBjb25mdGVzdCRhY19leGVleHQgJENG
TEFHUyAkQ1BQRkxBR1MgJExERkxBR1MgY29uZnRlc3QuJGFjX2V4dCAkTElCUyA+JjUnCithY19j
b21waWxlcl9nbnU9JGFjX2N2X2NfY29tcGlsZXJfZ251CisKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciBsbiAtcyB3b3JrcyIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxuIC1zIHdvcmtzLi4uICIgPiY2OyB9CitMTl9T
PSRhc19sbl9zCitpZiB0ZXN0ICIkTE5fUyIgPSAibG4gLXMiOyB0aGVuCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8g
InllcyIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiBubywgdXNpbmcgJExOX1MiID4mNQorJGFzX2VjaG8gIm5vLCB1c2luZyAk
TE5fUyIgPiY2OyB9CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIHdoZXRoZXIgJHtNQUtFLW1ha2V9IHNldHMgXCQoTUFLRSkiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciAke01BS0UtbWFrZX0gc2V0cyBcJChNQUtFKS4uLiAi
ID4mNjsgfQorc2V0IHggJHtNQUtFLW1ha2V9CithY19tYWtlPWAkYXNfZWNobyAiJDIiIHwgc2Vk
ICdzLysvcC9nOyBzL1teYS16QS1aMC05X10vXy9nJ2AKK2lmIGV2YWwgXCR7YWNfY3ZfcHJvZ19t
YWtlXyR7YWNfbWFrZX1fc2V0Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hl
ZCkgIiA+JjYKK2Vsc2UKKyAgY2F0ID5jb25mdGVzdC5tYWtlIDw8XF9BQ0VPRgorU0hFTEwgPSAv
YmluL3NoCithbGw6CisJQGVjaG8gJ0BAQCUlJT0kKE1BS0UpPUBAQCUlJScKK19BQ0VPRgorIyBH
TlUgbWFrZSBzb21ldGltZXMgcHJpbnRzICJtYWtlWzFdOiBFbnRlcmluZyAuLi4iLCB3aGljaCB3
b3VsZCBjb25mdXNlIHVzLgorY2FzZSBgJHtNQUtFLW1ha2V9IC1mIGNvbmZ0ZXN0Lm1ha2UgMj4v
ZGV2L251bGxgIGluCisgICpAQEAlJSU9Pyo9QEBAJSUlKikKKyAgICBldmFsIGFjX2N2X3Byb2df
bWFrZV8ke2FjX21ha2V9X3NldD15ZXM7OworICAqKQorICAgIGV2YWwgYWNfY3ZfcHJvZ19tYWtl
XyR7YWNfbWFrZX1fc2V0PW5vOzsKK2VzYWMKK3JtIC1mIGNvbmZ0ZXN0Lm1ha2UKK2ZpCitpZiBl
dmFsIHRlc3QgXCRhY19jdl9wcm9nX21ha2VfJHthY19tYWtlfV9zZXQgPSB5ZXM7IHRoZW4KKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHllcyIgPiY1
CiskYXNfZWNobyAieWVzIiA+JjY7IH0KKyAgU0VUX01BS0U9CitlbHNlCisgIHsgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAi
bm8iID4mNjsgfQorICBTRVRfTUFLRT0iTUFLRT0ke01BS0UtbWFrZX0iCitmaQorCisjIEZpbmQg
YSBnb29kIGluc3RhbGwgcHJvZ3JhbS4gIFdlIHByZWZlciBhIEMgcHJvZ3JhbSAoZmFzdGVyKSwK
KyMgc28gb25lIHNjcmlwdCBpcyBhcyBnb29kIGFzIGFub3RoZXIuICBCdXQgYXZvaWQgdGhlIGJy
b2tlbiBvcgorIyBpbmNvbXBhdGlibGUgdmVyc2lvbnM6CisjIFN5c1YgL2V0Yy9pbnN0YWxsLCAv
dXNyL3NiaW4vaW5zdGFsbAorIyBTdW5PUyAvdXNyL2V0Yy9pbnN0YWxsCisjIElSSVggL3NiaW4v
aW5zdGFsbAorIyBBSVggL2Jpbi9pbnN0YWxsCisjIEFtaWdhT1MgL0MvaW5zdGFsbCwgd2hpY2gg
aW5zdGFsbHMgYm9vdGJsb2NrcyBvbiBmbG9wcHkgZGlzY3MKKyMgQUlYIDQgL3Vzci9iaW4vaW5z
dGFsbGJzZCwgd2hpY2ggZG9lc24ndCB3b3JrIHdpdGhvdXQgYSAtZyBmbGFnCisjIEFGUyAvdXNy
L2Fmc3dzL2Jpbi9pbnN0YWxsLCB3aGljaCBtaXNoYW5kbGVzIG5vbmV4aXN0ZW50IGFyZ3MKKyMg
U1ZSNCAvdXNyL3VjYi9pbnN0YWxsLCB3aGljaCB0cmllcyB0byB1c2UgdGhlIG5vbmV4aXN0ZW50
IGdyb3VwICJzdGFmZiIKKyMgT1MvMidzIHN5c3RlbSBpbnN0YWxsLCB3aGljaCBoYXMgYSBjb21w
bGV0ZWx5IGRpZmZlcmVudCBzZW1hbnRpYworIyAuL2luc3RhbGwsIHdoaWNoIGNhbiBiZSBlcnJv
bmVvdXNseSBjcmVhdGVkIGJ5IG1ha2UgZnJvbSAuL2luc3RhbGwuc2guCisjIFJlamVjdCBpbnN0
YWxsIHByb2dyYW1zIHRoYXQgY2Fubm90IGluc3RhbGwgbXVsdGlwbGUgZmlsZXMuCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBhIEJTRC1jb21w
YXRpYmxlIGluc3RhbGwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGEgQlNELWNvbXBh
dGlibGUgaW5zdGFsbC4uLiAiID4mNjsgfQoraWYgdGVzdCAteiAiJElOU1RBTEwiOyB0aGVuCitp
ZiAke2FjX2N2X3BhdGhfaW5zdGFsbCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICAjIEFjY291bnQgZm9yIHBlb3BsZSB3aG8gcHV0
IHRyYWlsaW5nIHNsYXNoZXMgaW4gUEFUSCBlbGVtZW50cy4KK2Nhc2UgJGFzX2Rpci8gaW4gIygo
CisgIC4vIHwgLi8vIHwgL1tjQ10vKiB8IFwKKyAgL2V0Yy8qIHwgL3Vzci9zYmluLyogfCAvdXNy
L2V0Yy8qIHwgL3NiaW4vKiB8IC91c3IvYWZzd3MvYmluLyogfCBcCisgID86W1xcL11vczJbXFwv
XWluc3RhbGxbXFwvXSogfCA/OltcXC9dT1MyW1xcL11JTlNUQUxMW1xcL10qIHwgXAorICAvdXNy
L3VjYi8qICkgOzsKKyAgKikKKyAgICAjIE9TRjEgYW5kIFNDTyBPRFQgMy4wIGhhdmUgdGhlaXIg
b3duIG5hbWVzIGZvciBpbnN0YWxsLgorICAgICMgRG9uJ3QgdXNlIGluc3RhbGxic2QgZnJvbSBP
U0Ygc2luY2UgaXQgaW5zdGFsbHMgc3R1ZmYgYXMgcm9vdAorICAgICMgYnkgZGVmYXVsdC4KKyAg
ICBmb3IgYWNfcHJvZyBpbiBnaW5zdGFsbCBzY29pbnN0IGluc3RhbGw7IGRvCisgICAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKwlpZiB7IHRl
c3QgLWYgIiRhc19kaXIvJGFjX3Byb2ckYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19k
aXIvJGFjX3Byb2ckYWNfZXhlY19leHQiOyB9OyB0aGVuCisJICBpZiB0ZXN0ICRhY19wcm9nID0g
aW5zdGFsbCAmJgorCSAgICBncmVwIGRzcG1zZyAiJGFzX2Rpci8kYWNfcHJvZyRhY19leGVjX2V4
dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgQUlYIGluc3RhbGwuICBJdCBoYXMgYW4g
aW5jb21wYXRpYmxlIGNhbGxpbmcgY29udmVudGlvbi4KKwkgICAgOgorCSAgZWxpZiB0ZXN0ICRh
Y19wcm9nID0gaW5zdGFsbCAmJgorCSAgICBncmVwIHB3cGx1cyAiJGFzX2Rpci8kYWNfcHJvZyRh
Y19leGVjX2V4dCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisJICAgICMgcHJvZ3JhbS1zcGVjaWZp
YyBpbnN0YWxsIHNjcmlwdCB1c2VkIGJ5IEhQIHB3cGx1cy0tZG9uJ3QgdXNlLgorCSAgICA6CisJ
ICBlbHNlCisJICAgIHJtIC1yZiBjb25mdGVzdC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRp
cgorCSAgICBlY2hvIG9uZSA+IGNvbmZ0ZXN0Lm9uZQorCSAgICBlY2hvIHR3byA+IGNvbmZ0ZXN0
LnR3bworCSAgICBta2RpciBjb25mdGVzdC5kaXIKKwkgICAgaWYgIiRhc19kaXIvJGFjX3Byb2ck
YWNfZXhlY19leHQiIC1jIGNvbmZ0ZXN0Lm9uZSBjb25mdGVzdC50d28gImBwd2RgL2NvbmZ0ZXN0
LmRpciIgJiYKKwkgICAgICB0ZXN0IC1zIGNvbmZ0ZXN0Lm9uZSAmJiB0ZXN0IC1zIGNvbmZ0ZXN0
LnR3byAmJgorCSAgICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0Lm9uZSAmJgorCSAg
ICAgIHRlc3QgLXMgY29uZnRlc3QuZGlyL2NvbmZ0ZXN0LnR3bworCSAgICB0aGVuCisJICAgICAg
YWNfY3ZfcGF0aF9pbnN0YWxsPSIkYXNfZGlyLyRhY19wcm9nJGFjX2V4ZWNfZXh0IC1jIgorCSAg
ICAgIGJyZWFrIDMKKwkgICAgZmkKKwkgIGZpCisJZmkKKyAgICAgIGRvbmUKKyAgICBkb25lCisg
ICAgOzsKK2VzYWMKKworICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK3JtIC1yZiBjb25mdGVz
dC5vbmUgY29uZnRlc3QudHdvIGNvbmZ0ZXN0LmRpcgorCitmaQorICBpZiB0ZXN0ICIke2FjX2N2
X3BhdGhfaW5zdGFsbCtzZXR9IiA9IHNldDsgdGhlbgorICAgIElOU1RBTEw9JGFjX2N2X3BhdGhf
aW5zdGFsbAorICBlbHNlCisgICAgIyBBcyBhIGxhc3QgcmVzb3J0LCB1c2UgdGhlIHNsb3cgc2hl
bGwgc2NyaXB0LiAgRG9uJ3QgY2FjaGUgYQorICAgICMgdmFsdWUgZm9yIElOU1RBTEwgd2l0aGlu
IGEgc291cmNlIGRpcmVjdG9yeSwgYmVjYXVzZSB0aGF0IHdpbGwKKyAgICAjIGJyZWFrIG90aGVy
IHBhY2thZ2VzIHVzaW5nIHRoZSBjYWNoZSBpZiB0aGF0IGRpcmVjdG9yeSBpcworICAgICMgcmVt
b3ZlZCwgb3IgaWYgdGhlIHZhbHVlIGlzIGEgcmVsYXRpdmUgbmFtZS4KKyAgICBJTlNUQUxMPSRh
Y19pbnN0YWxsX3NoCisgIGZpCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRJTlNUQUxMIiA+JjUKKyRhc19lY2hvICIkSU5TVEFMTCIgPiY2OyB9
CisKKyMgVXNlIHRlc3QgLXogYmVjYXVzZSBTdW5PUzQgc2ggbWlzaGFuZGxlcyBicmFjZXMgaW4g
JHt2YXItdmFsfS4KKyMgSXQgdGhpbmtzIHRoZSBmaXJzdCBjbG9zZSBicmFjZSBlbmRzIHRoZSB2
YXJpYWJsZSBzdWJzdGl0dXRpb24uCit0ZXN0IC16ICIkSU5TVEFMTF9QUk9HUkFNIiAmJiBJTlNU
QUxMX1BST0dSQU09JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNUQUxMX1NDUklQVCIgJiYg
SU5TVEFMTF9TQ1JJUFQ9JyR7SU5TVEFMTH0nCisKK3Rlc3QgLXogIiRJTlNUQUxMX0RBVEEiICYm
IElOU1RBTExfREFUQT0nJHtJTlNUQUxMfSAtbSA2NDQnCisKKyMgRXh0cmFjdCB0aGUgZmlyc3Qg
d29yZCBvZiAicGVybCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitz
ZXQgZHVtbXkgcGVybDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tp
bmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfUEVSTCs6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFBF
UkwgaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfUEVSTD0iJFBFUkwiICMg
TGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQor
ICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQ
QVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rp
cj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7
IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFz
X3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19j
dl9wYXRoX1BFUkw9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfUEVSTCIgJiYgYWNfY3ZfcGF0aF9QRVJM
PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitQRVJMPSRhY19jdl9wYXRoX1BFUkwKK2lmIHRlc3QgLW4g
IiRQRVJMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJFBFUkwiID4mNQorJGFzX2VjaG8gIiRQRVJMIiA+JjY7IH0KK2Vsc2UKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRh
c19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke1BFUkx9IiA9PSB4Im5vIgor
dGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBwZXJsLCBwbGVhc2UgaW5z
dGFsbCBwZXJsIiAiJExJTkVOTyIgNQorZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAi
YnJjdGwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15
IGJyY3RsOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9CUkNUTCs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEJSQ1RMIGlu
CisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0JSQ1RMPSIkQlJDVEwiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBh
c19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRI
CitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0u
CisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRv
CisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rl
c3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9w
YXRoX0JSQ1RMPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0JSQ1RMIiAmJiBhY19jdl9wYXRoX0JSQ1RM
PSJubyIKKyAgOzsKK2VzYWMKK2ZpCitCUkNUTD0kYWNfY3ZfcGF0aF9CUkNUTAoraWYgdGVzdCAt
biAiJEJSQ1RMIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogJEJSQ1RMIiA+JjUKKyRhc19lY2hvICIkQlJDVEwiID4mNjsgfQorZWxzZQor
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4m
NQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7QlJDVEx9IiA9PSB4
Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBicmN0bCwgcGxl
YXNlIGluc3RhbGwgYnJjdGwiICIkTElORU5PIiA1CitmaQorIyBFeHRyYWN0IHRoZSBmaXJzdCB3
b3JkIG9mICJpcCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQg
ZHVtbXkgaXA7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZv
ciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0lQKzp9IGZhbHNlOyB0aGVu
IDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkSVAgaW4KKyAg
W1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfSVA9IiRJUCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfSVA9IiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1Cisg
ICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVz
dCAteiAiJGFjX2N2X3BhdGhfSVAiICYmIGFjX2N2X3BhdGhfSVA9Im5vIgorICA7OworZXNhYwor
ZmkKK0lQPSRhY19jdl9wYXRoX0lQCitpZiB0ZXN0IC1uICIkSVAiOyB0aGVuCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkSVAiID4mNQorJGFzX2Vj
aG8gIiRJUCIgPiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitp
ZiB0ZXN0IHgiJHtJUH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJs
ZSB0byBmaW5kIGlwLCBwbGVhc2UgaW5zdGFsbCBpcCIgIiRMSU5FTk8iIDUKK2ZpCisjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgImJpc29uIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1l
IHdpdGggYXJncy4KK3NldCBkdW1teSBiaXNvbjsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFz
X2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Bh
dGhfQklTT04rOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgor
ZWxzZQorICBjYXNlICRCSVNPTiBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0
aF9CSVNPTj0iJEJJU09OIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEg
cGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRP
UgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16
ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhl
Y3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQk
YWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQi
OyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9CSVNPTj0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVj
X2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25l
CisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9CSVNP
TiIgJiYgYWNfY3ZfcGF0aF9CSVNPTj0ibm8iCisgIDs7Citlc2FjCitmaQorQklTT049JGFjX2N2
X3BhdGhfQklTT04KK2lmIHRlc3QgLW4gIiRCSVNPTiI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRCSVNPTiIgPiY1CiskYXNfZWNobyAi
JEJJU09OIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lm
IHRlc3QgeCIke0JJU09OfSIgPT0geCJubyIKK3RoZW4KKyAgICBhc19mbl9lcnJvciAkPyAiVW5h
YmxlIHRvIGZpbmQgYmlzb24sIHBsZWFzZSBpbnN0YWxsIGJpc29uIiAiJExJTkVOTyIgNQorZmkK
KyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAiZmxleCIsIHNvIGl0IGNhbiBiZSBhIHByb2dy
YW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgZmxleDsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3BhdGhfRkxFWCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhc2UgJEZMRVggaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2
X3BhdGhfRkxFWD0iJEZMRVgiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGgg
YSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJB
VE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3Qg
LXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19l
eGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX0ZMRVg9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQg
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9u
ZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfRkxF
WCIgJiYgYWNfY3ZfcGF0aF9GTEVYPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitGTEVYPSRhY19jdl9w
YXRoX0ZMRVgKK2lmIHRlc3QgLW4gIiRGTEVYIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJEZMRVgiID4mNQorJGFzX2VjaG8gIiRGTEVY
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3Qg
eCIke0ZMRVh9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8g
ZmluZCBmbGV4LCBwbGVhc2UgaW5zdGFsbCBmbGV4IiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3Qg
IngkeGFwaSIgPSAieHkiOyB0aGVuIDoKKworICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiY3VybC1jb25maWciLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15IGN1cmwtY29uZmlnOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9DVVJM
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
Y2FzZSAkQ1VSTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3ZfcGF0aF9DVVJMPSIk
Q1VSTCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7
CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3BhdGhfQ1VSTD0iJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lG
Uz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0aF9DVVJMIiAmJiBhY19jdl9w
YXRoX0NVUkw9Im5vIgorICA7OworZXNhYworZmkKK0NVUkw9JGFjX2N2X3BhdGhfQ1VSTAoraWYg
dGVzdCAtbiAiJENVUkwiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogcmVzdWx0OiAkQ1VSTCIgPiY1CiskYXNfZWNobyAiJENVUkwiID4mNjsgfQorZWxz
ZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8i
ID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVzdCB4IiR7Q1VSTH0iID09
IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0byBmaW5kIGN1cmwtY29u
ZmlnLCBwbGVhc2UgaW5zdGFsbCBjdXJsLWNvbmZpZyIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBF
eHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4bWwyLWNvbmZpZyIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeG1sMi1jb25maWc7IGFjX3dvcmQ9JDIK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRh
Y193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsg
fQoraWYgJHthY19jdl9wYXRoX1hNTCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFhNTCBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9YTUw9IiRYTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0
IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhf
U0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisg
IHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcn
ICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8k
YWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1hNTD0iJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16ICIkYWNfY3ZfcGF0
aF9YTUwiICYmIGFjX2N2X3BhdGhfWE1MPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitYTUw9JGFjX2N2
X3BhdGhfWE1MCitpZiB0ZXN0IC1uICIkWE1MIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFhNTCIgPiY1CiskYXNfZWNobyAiJFhNTCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitpZiB0ZXN0IHgi
JHtYTUx9IiA9PSB4Im5vIgordGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmlu
ZCB4bWwyLWNvbmZpZywgcGxlYXNlIGluc3RhbGwgeG1sMi1jb25maWciICIkTElORU5PIiA1Citm
aQorCitmaQoraWYgdGVzdCAieCRvY2FtbHRvb2xzIiA9ICJ4eSI7IHRoZW4gOgorCisgICAgICAj
IGNoZWNraW5nIGZvciBvY2FtbGMKKyAgaWYgdGVzdCAtbiAiJGFjX3Rvb2xfcHJlZml4IjsgdGhl
bgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxj
Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2Fj
X3Rvb2xfcHJlZml4fW9jYW1sYzsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAi
Y2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfT0NBTUxD
Kzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAg
aWYgdGVzdCAtbiAiJE9DQU1MQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiRPQ0FNTEMi
ICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElG
UzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRh
c19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19l
eGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3Qg
LWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19PQ0FNTEM9IiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJy
ZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09D
QU1MQz0kYWNfY3ZfcHJvZ19PQ0FNTEMKK2lmIHRlc3QgLW4gIiRPQ0FNTEMiOyB0aGVuCisgIHsg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxDIiA+
JjUKKyRhc19lY2hvICIkT0NBTUxDIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTEMiOyB0aGVuCisg
IGFjX2N0X09DQU1MQz0kT0NBTUxDCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2Nh
bWxjIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSBv
Y2FtbGM7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X09DQU1MQys6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3Qg
LW4gIiRhY19jdF9PQ0FNTEMiOyB0aGVuCisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxDPSIkYWNf
Y3RfT0NBTUxDIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxDPSJvY2FtbGMiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNf
Y3RfT0NBTUxDPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MQworaWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTEMiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTEMiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTEMiID0geDsgdGhlbgorICAgIE9DQU1MQz0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxDPSRhY19jdF9PQ0FNTEMK
KyAgZmkKK2Vsc2UKKyAgT0NBTUxDPSIkYWNfY3ZfcHJvZ19PQ0FNTEMiCitmaQorCisKKyAgaWYg
dGVzdCAiJE9DQU1MQyIgIT0gIm5vIjsgdGhlbgorICAgICBPQ0FNTFZFUlNJT049YCRPQ0FNTEMg
LXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJ2AKKyAgICAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IE9DYW1sIHZlcnNpb24g
aXMgJE9DQU1MVkVSU0lPTiIgPiY1CiskYXNfZWNobyAiT0NhbWwgdmVyc2lvbiBpcyAkT0NBTUxW
RVJTSU9OIiA+JjY7IH0KKyAgICAgIyBJZiBPQ0FNTExJQiBpcyBzZXQsIHVzZSBpdAorICAgICBp
ZiB0ZXN0ICIkT0NBTUxMSUIiID0gIiI7IHRoZW4KKyAgICAgICAgT0NBTUxMSUI9YCRPQ0FNTEMg
LXdoZXJlIDI+L2Rldi9udWxsIHx8ICRPQ0FNTEMgLXZ8dGFpbCAtMXxjdXQgLWQgJyAnIC1mIDRg
CisgICAgIGVsc2UKKyAgICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6IE9DQU1MTElCIHByZXZpb3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0LiIgPiY1
CiskYXNfZWNobyAiT0NBTUxMSUIgcHJldmlvdXNseSBzZXQ7IHByZXNlcnZpbmcgaXQuIiA+JjY7
IH0KKyAgICAgZmkKKyAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IE9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNQorJGFzX2VjaG8g
Ik9DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUIiID4mNjsgfQorCisKKworCisgICAgICMg
Y2hlY2tpbmcgZm9yIG9jYW1sb3B0CisgICAgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7
IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9j
YW1sb3B0Iiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1t
eSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sb3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNf
ZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJv
Z19PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FN
TE9QVD0iJE9DQU1MT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UK
K2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBB
VEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGly
PS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsg
ZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNf
dGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2
X3Byb2dfT0NBTUxPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQiCisgICAgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19l
eGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3Nh
dmVfSUZTCisKK2ZpCitmaQorT0NBTUxPUFQ9JGFjX2N2X3Byb2dfT0NBTUxPUFQKK2lmIHRlc3Qg
LW4gIiRPQ0FNTE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRPQ0FNTE9QVCIgPiY1CiskYXNfZWNobyAiJE9DQU1MT1BUIiA+JjY7
IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16
ICIkYWNfY3ZfcHJvZ19PQ0FNTE9QVCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxPUFQ9JE9DQU1MT1BU
CisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxvcHQiLCBzbyBpdCBjYW4gYmUg
YSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sb3B0OyBhY193b3JkPSQy
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAk
YWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7
IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVCs6fSBmYWxzZTsgdGhlbiA6CisgICRh
c19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FN
TE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVD0iJGFjX2N0X09DQU1MT1BU
IiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJ
RlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0k
YXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNf
ZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0
IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGly
LyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NB
TUxPUFQ9Im9jYW1sb3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIK
KyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09D
QU1MT1BUPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MT1BUCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NB
TUxPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3RfT0NBTUxPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTE9QVCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4
JGFjX2N0X09DQU1MT1BUIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE9QVD0ibm8iCisgIGVsc2UKKyAg
ICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0
b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19t
ZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlw
bGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxPUFQ9JGFj
X2N0X09DQU1MT1BUCisgIGZpCitlbHNlCisgIE9DQU1MT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTE9Q
VCIKK2ZpCisKKyAgICAgT0NBTUxCRVNUPWJ5dGUKKyAgICAgaWYgdGVzdCAiJE9DQU1MT1BUIiA9
ICJubyI7IHRoZW4KKwl7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdB
Uk5JTkc6IENhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21waWxhdGlvbiBvbmx5LiIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiBDYW5ub3QgZmluZCBvY2FtbG9wdDsgYnl0
ZWNvZGUgY29tcGlsYXRpb24gb25seS4iID4mMjt9CisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAk
T0NBTUxPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJ
aWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IHZlcnNpb25zIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZl
cnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0IGRpc2NhcmRlZC4iID4mNjsgfQor
CSAgICBPQ0FNTE9QVD1ubworCWVsc2UKKwkgICAgT0NBTUxCRVNUPW9wdAorCWZpCisgICAgIGZp
CisKKworCisgICAgICMgY2hlY2tpbmcgZm9yIG9jYW1sYy5vcHQKKyAgICAgaWYgdGVzdCAtbiAi
JGFjX3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxjLm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3
aXRoIGFyZ3MuCitzZXQgZHVtbXkgJHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0OyBhY193b3Jk
PSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+
JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxDRE9U
T1BUIjsgdGhlbgorICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0iJE9DQU1MQ0RPVE9QVCIgIyBM
ZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJ
RlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3Nh
dmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNf
ZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAi
JGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNf
d29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MQ0RPVE9QVD0i
JHthY190b29sX3ByZWZpeH1vY2FtbGMub3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQor
ICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQor
ZmkKK09DQU1MQ0RPVE9QVD0kYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQKK2lmIHRlc3QgLW4gIiRP
Q0FNTENET1RPUFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkT0NBTUxDRE9UT1BUIiA+JjUKKyRhc19lY2hvICIkT0NBTUxDRE9UT1BU
IiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0
ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MQ0RP
VE9QVD0kT0NBTUxDRE9UT1BUCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxj
Lm9wdCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
b2NhbWxjLm9wdDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxDRE9U
T1BUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTENET1RPUFQ9IiRhY19jdF9PQ0FNTENET1RPUFQiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTENET1RPUFQ9Im9jYW1sYy5v
cHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQor
ICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NBTUxDRE9UT1BUPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MQ0RPVE9QVAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQ0RP
VE9QVCI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdF9PQ0FNTENET1RPUFQiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTENE
T1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTENET1RPUFQiID0geDsgdGhlbgorICAgIE9DQU1MQ0RPVE9QVD0i
bm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGlu
Cit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5H
OiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQor
JGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVk
IHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisg
ICAgT0NBTUxDRE9UT1BUPSRhY19jdF9PQ0FNTENET1RPUFQKKyAgZmkKK2Vsc2UKKyAgT0NBTUxD
RE9UT1BUPSIkYWNfY3ZfcHJvZ19PQ0FNTENET1RPUFQiCitmaQorCisgICAgIGlmIHRlc3QgIiRP
Q0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAkT0NBTUxDRE9UT1BUIC12
IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcgYAorCWlmIHRlc3QgIiRU
TVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAgIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiB2ZXJzaW9ucyBkaWZmZXJzIGZyb20g
b2NhbWxjOyBvY2FtbGMub3B0IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb25zIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQgZGlzY2FyZGVkLiIgPiY2OyB9CisJZWxzZQor
CSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAgIGZpCisKKyAgICAgIyBjaGVja2lu
ZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgIT0gIm5vIiA7IHRo
ZW4KKwlpZiB0ZXN0IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUg
Zmlyc3Qgd29yZCBvZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG9wdC5vcHQiLCBzbyBpdCBjYW4g
YmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9
b2NhbWxvcHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8t
JExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTE9QVERPVE9Q
VCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRPQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE9Q
VERPVE9QVD0iJE9DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVz
dC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19k
aXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIg
JiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0
ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgor
ICAgIGFjX2N2X3Byb2dfT0NBTUxPUFRET1RPUFQ9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxvcHQu
b3B0IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUK
KyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MT1BURE9UT1BUPSRhY19j
dl9wcm9nX09DQU1MT1BURE9UT1BUCitpZiB0ZXN0IC1uICIkT0NBTUxPUFRET1RPUFQiOyB0aGVu
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NB
TUxPUFRET1RPUFQiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE9QVERPVE9QVCIgPiY2OyB9CitlbHNl
CisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIg
PiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitmaQoraWYgdGVzdCAteiAiJGFjX2N2
X3Byb2dfT0NBTUxPUFRET1RPUFQiOyB0aGVuCisgIGFjX2N0X09DQU1MT1BURE9UT1BUPSRPQ0FN
TE9QVERPVE9QVAorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIm9jYW1sb3B0Lm9wdCIs
IHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxv
cHQub3B0OyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9Q
VCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTE9QVERPVE9QVCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTE9QVERPVE9QVD0iJGFjX2N0X09DQU1MT1BURE9UT1BUIiAjIExldCB0aGUgdXNl
ciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9T
RVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAg
dGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycg
JGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRh
Y193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4
ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxPUFRET1RPUFQ9Im9j
YW1sb3B0Lm9wdCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBm
b3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBicmVhayAyCisgIGZp
Citkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCithY19jdF9PQ0FNTE9Q
VERPVE9QVD0kYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE9QVERPVE9QVAoraWYgdGVzdCAtbiAiJGFj
X2N0X09DQU1MT1BURE9UT1BUIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MT1BURE9UT1BUIiA+JjUKKyRhc19lY2hv
ICIkYWNfY3RfT0NBTUxPUFRET1RPUFQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+
JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19jdF9PQ0FNTE9QVERPVE9QVCIgPSB4OyB0aGVu
CisgICAgT0NBTUxPUFRET1RPUFQ9Im5vIgorICBlbHNlCisgICAgY2FzZSAkY3Jvc3NfY29tcGls
aW5nOiRhY190b29sX3dhcm5lZCBpbgoreWVzOikKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xp
bmVuby0kTElORU5PfTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdp
dGggaG9zdCB0cmlwbGV0IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHVzaW5nIGNy
b3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiYyO30KK2FjX3Rvb2xf
d2FybmVkPXllcyA7OworZXNhYworICAgIE9DQU1MT1BURE9UT1BUPSRhY19jdF9PQ0FNTE9QVERP
VE9QVAorICBmaQorZWxzZQorICBPQ0FNTE9QVERPVE9QVD0iJGFjX2N2X3Byb2dfT0NBTUxPUFRE
T1RPUFQiCitmaQorCisJaWYgdGVzdCAiJE9DQU1MT1BURE9UT1BUIiAhPSAibm8iOyB0aGVuCisJ
ICAgVE1QVkVSU0lPTj1gJE9DQU1MT1BURE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lv
biogKlwoLipcKSR8XDF8cCcgYAorCSAgIGlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1M
VkVSU0lPTiIgOyB0aGVuCisJICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6IHZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQub3B0
IGRpc2NhcmRlZC4iID4mNQorJGFzX2VjaG8gInZlcnNpb24gZGlmZmVycyBmcm9tIG9jYW1sYzsg
b2NhbWxvcHQub3B0IGRpc2NhcmRlZC4iID4mNjsgfQorCSAgIGVsc2UKKwkgICAgICBPQ0FNTE9Q
VD0kT0NBTUxPUFRET1RPUFQKKwkgICBmaQorICAgICAgICBmaQorICAgICBmaQorCisKKyAgZmkK
KworCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWwgdG9wbGV2ZWwKKyAgaWYgdGVzdCAtbiAiJGFj
X3Rvb2xfcHJlZml4IjsgdGhlbgorICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgIiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWwiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdz
Lgorc2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHth
Y19jdl9wcm9nX09DQU1MKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkg
IiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX09D
QU1MPSIkT0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJv
Z19PQ0FNTD0iJHthY190b29sX3ByZWZpeH1vY2FtbCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+
JjUKKyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKwor
ZmkKK2ZpCitPQ0FNTD0kYWNfY3ZfcHJvZ19PQ0FNTAoraWYgdGVzdCAtbiAiJE9DQU1MIjsgdGhl
bgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJE9D
QU1MIiA+JjUKKyRhc19lY2hvICIkT0NBTUwiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MIjsgdGhl
bgorICBhY19jdF9PQ0FNTD0kT0NBTUwKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJv
Y2FtbCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkg
b2NhbWw7IGFjX3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogY2hlY2tpbmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAk
YWNfd29yZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX2FjX2N0X09DQU1MKzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAt
biAiJGFjX2N0X09DQU1MIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MPSIkYWNfY3Rf
T0NBTUwiICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9J
RlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAg
SUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZv
ciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7
IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19j
dF9PQ0FNTD0ib2NhbWwiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsgMgor
ICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorYWNfY3RfT0NB
TUw9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUwKK2lmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTCI7IHRo
ZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRh
Y19jdF9PQ0FNTCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MIiA+JjY7IH0KK2Vsc2UKKyAg
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUK
KyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUwiID0g
eDsgdGhlbgorICAgIE9DQU1MPSJubyIKKyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGlu
ZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRo
IGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9z
cyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dh
cm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTD0kYWNfY3RfT0NBTUwKKyAgZmkKK2Vsc2UKKyAg
T0NBTUw9IiRhY19jdl9wcm9nX09DQU1MIgorZmkKKworCisgICMgY2hlY2tpbmcgZm9yIG9jYW1s
ZGVwCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRo
ZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZGVwIiwgc28gaXQgY2FuIGJl
IGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9j
YW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTERFUCs6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4g
IiRPQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERFUD0iJE9DQU1MREVQIiAjIExl
dCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElG
Uz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2
ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19l
eHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193
b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxERVA9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxkZXAiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJl
YWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKK2ZpCitmaQorT0NB
TUxERVA9JGFjX2N2X3Byb2dfT0NBTUxERVAKK2lmIHRlc3QgLW4gIiRPQ0FNTERFUCI7IHRoZW4K
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRPQ0FN
TERFUCIgPiY1CiskYXNfZWNobyAiJE9DQU1MREVQIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3ZfcHJvZ19PQ0FNTERF
UCI7IHRoZW4KKyAgYWNfY3RfT0NBTUxERVA9JE9DQU1MREVQCisgICMgRXh0cmFjdCB0aGUgZmly
c3Qgd29yZCBvZiAib2NhbWxkZXAiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBh
cmdzLgorc2V0IGR1bW15IG9jYW1sZGVwOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNo
b19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19h
Y19jdF9PQ0FNTERFUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERFUCI7IHRoZW4KKyAgYWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTERFUD0iJGFjX2N0X09DQU1MREVQIiAjIExldCB0aGUgdXNlciBvdmVy
cmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFU
T1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAt
eiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4
ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0
IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxERVA9Im9jYW1sZGVwIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MREVQPSRhY19jdl9wcm9nX2Fj
X2N0X09DQU1MREVQCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxERVAiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3RfT0NBTUxE
RVAiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERFUCIgPiY2OyB9CitlbHNlCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBubyIgPiY1CiskYXNf
ZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09DQU1MREVQIiA9IHg7
IHRoZW4KKyAgICBPQ0FNTERFUD0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxp
bmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jv
c3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93
YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxERVA9JGFjX2N0X09DQU1MREVQCisgIGZpCitl
bHNlCisgIE9DQU1MREVQPSIkYWNfY3ZfcHJvZ19PQ0FNTERFUCIKK2ZpCisKKworICAjIGNoZWNr
aW5nIGZvciBvY2FtbG1rdG9wCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4K
KyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWt0
b3AiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15ICR7
YWNfdG9vbF9wcmVmaXh9b2NhbWxta3RvcDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3Byb2df
T0NBTUxNS1RPUCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2
CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTE1LVE9QIjsgdGhlbgorICBhY19jdl9wcm9nX09D
QU1MTUtUT1A9IiRPQ0FNTE1LVE9QIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4K
K2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIg
aW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYg
YXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5z
aW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAm
JiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAg
IGFjX2N2X3Byb2dfT0NBTUxNS1RPUD0iJHthY190b29sX3ByZWZpeH1vY2FtbG1rdG9wIgorICAg
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQor
SUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MTUtUT1A9JGFjX2N2X3Byb2dfT0NBTUxN
S1RPUAoraWYgdGVzdCAtbiAiJE9DQU1MTUtUT1AiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNo
byAiJE9DQU1MTUtUT1AiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2Zp
CisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MTUtUT1AiOyB0aGVuCisgIGFj
X2N0X09DQU1MTUtUT1A9JE9DQU1MTUtUT1AKKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9m
ICJvY2FtbG1rdG9wIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3Nl
dCBkdW1teSBvY2FtbG1rdG9wOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19hY19jdF9P
Q0FNTE1LVE9QKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYK
K2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0aGVuCisgIGFjX2N2X3By
b2dfYWNfY3RfT0NBTUxNS1RPUD0iJGFjX2N0X09DQU1MTUtUT1AiICMgTGV0IHRoZSB1c2VyIG92
ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFS
QVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0
IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNf
ZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19l
eHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTE1LVE9QPSJvY2FtbG1rdG9w
IgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19k
aXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAg
ZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MTUtUT1A9JGFjX2N2
X3Byb2dfYWNfY3RfT0NBTUxNS1RPUAoraWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MTUtUT1AiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3RfT0NBTUxNS1RPUCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1MTUtUT1AiID4mNjsg
fQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYgdGVzdCAieCRhY19j
dF9PQ0FNTE1LVE9QIiA9IHg7IHRoZW4KKyAgICBPQ0FNTE1LVE9QPSJubyIKKyAgZWxzZQorICAg
IGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3llczopCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVzaW5nIGNyb3NzIHRv
b2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNfZWNobyAiJGFzX21l
OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRyaXBs
ZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBPQ0FNTE1LVE9QPSRh
Y19jdF9PQ0FNTE1LVE9QCisgIGZpCitlbHNlCisgIE9DQU1MTUtUT1A9IiRhY19jdl9wcm9nX09D
QU1MTUtUT1AiCitmaQorCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxta2xpYgorICBpZiB0ZXN0
IC1uICIkYWNfdG9vbF9wcmVmaXgiOyB0aGVuCisgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiJHthY190b29sX3ByZWZpeH1vY2FtbG1rbGliIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rvb2xfcHJlZml4fW9jYW1sbWtsaWI7IGFj
X3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wcm9nX09DQU1MTUtMSUIrOn0gZmFsc2U7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0IC1uICIkT0NBTUxN
S0xJQiI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTE1LTElCPSIkT0NBTUxNS0xJQiIgIyBMZXQg
dGhlIHVzZXIgb3ZlcnJpZGUgdGhlIHRlc3QuCitlbHNlCithc19zYXZlX0lGUz0kSUZTOyBJRlM9
JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVf
SUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0
IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29y
ZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wcm9nX09DQU1MTUtMSUI9IiR7YWNf
dG9vbF9wcmVmaXh9b2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkKK2ZpCitP
Q0FNTE1LTElCPSRhY19jdl9wcm9nX09DQU1MTUtMSUIKK2lmIHRlc3QgLW4gIiRPQ0FNTE1LTElC
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJE9DQU1MTUtMSUIiID4mNQorJGFzX2VjaG8gIiRPQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTE1LTElCIjsgdGhlbgorICBhY19jdF9PQ0FNTE1LTElCPSRPQ0FNTE1LTElCCisg
ICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxta2xpYiIsIHNvIGl0IGNhbiBiZSBh
IHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgb2NhbWxta2xpYjsgYWNfd29yZD0k
MgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Ig
JGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X3Byb2dfYWNfY3RfT0NBTUxNS0xJQis6fSBmYWxzZTsgdGhlbiA6Cisg
ICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9P
Q0FNTE1LTElCIjsgdGhlbgorICBhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUI9IiRhY19jdF9P
Q0FNTE1LTElCIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAg
aWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94
ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2df
YWNfY3RfT0NBTUxNS0xJQj0ib2NhbWxta2xpYiIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNf
bGluZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUK
KyAgICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworZmkK
K2ZpCithY19jdF9PQ0FNTE1LTElCPSRhY19jdl9wcm9nX2FjX2N0X09DQU1MTUtMSUIKK2lmIHRl
c3QgLW4gIiRhY19jdF9PQ0FNTE1LTElCIjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N0X09DQU1MTUtMSUIiID4mNQorJGFzX2Vj
aG8gIiRhY19jdF9PQ0FNTE1LTElCIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21l
OiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2
OyB9CitmaQorCisgIGlmIHRlc3QgIngkYWNfY3RfT0NBTUxNS0xJQiIgPSB4OyB0aGVuCisgICAg
T0NBTUxNS0xJQj0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRjcm9zc19jb21waWxpbmc6JGFjX3Rv
b2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0aCBob3N0IHRy
aXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogdXNpbmcgY3Jvc3MgdG9vbHMg
bm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7fQorYWNfdG9vbF93YXJuZWQ9eWVz
IDs7Citlc2FjCisgICAgT0NBTUxNS0xJQj0kYWNfY3RfT0NBTUxNS0xJQgorICBmaQorZWxzZQor
ICBPQ0FNTE1LTElCPSIkYWNfY3ZfcHJvZ19PQ0FNTE1LTElCIgorZmkKKworCisgICMgY2hlY2tp
bmcgZm9yIG9jYW1sZG9jCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3ByZWZpeCI7IHRoZW4KKyAg
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJlZml4fW9jYW1sZG9jIiwg
c28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJncy4KK3NldCBkdW1teSAke2FjX3Rv
b2xfcHJlZml4fW9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19s
aW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcHJvZ19PQ0FNTERP
Qys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGlmIHRlc3QgLW4gIiRPQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3ZfcHJvZ19PQ0FNTERPQz0iJE9D
QU1MRE9DIiAjIExldCB0aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVf
SUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisg
IElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBm
b3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYg
eyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIk
YXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NB
TUxET0M9IiR7YWNfdG9vbF9wcmVmaXh9b2NhbWxkb2MiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
K2ZpCitmaQorT0NBTUxET0M9JGFjX2N2X3Byb2dfT0NBTUxET0MKK2lmIHRlc3QgLW4gIiRPQ0FN
TERPQyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRPQ0FNTERPQyIgPiY1CiskYXNfZWNobyAiJE9DQU1MRE9DIiA+JjY7IH0KK2Vsc2UK
KyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+
JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKK2ZpCitpZiB0ZXN0IC16ICIkYWNfY3Zf
cHJvZ19PQ0FNTERPQyI7IHRoZW4KKyAgYWNfY3RfT0NBTUxET0M9JE9DQU1MRE9DCisgICMgRXh0
cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAib2NhbWxkb2MiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFt
IG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IG9jYW1sZG9jOyBhY193b3JkPSQyCit7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7
YWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQys6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24g
IihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRhY19jdF9PQ0FNTERPQyI7IHRo
ZW4KKyAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTERPQz0iJGFjX2N0X09DQU1MRE9DIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxET0M9Im9j
YW1sZG9jIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1MRE9DPSRh
Y19jdl9wcm9nX2FjX2N0X09DQU1MRE9DCitpZiB0ZXN0IC1uICIkYWNfY3RfT0NBTUxET0MiOyB0
aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3RfT0NBTUxET0MiID4mNQorJGFzX2VjaG8gIiRhY19jdF9PQ0FNTERPQyIgPiY2OyB9Citl
bHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiBu
byIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworICBpZiB0ZXN0ICJ4JGFjX2N0X09D
QU1MRE9DIiA9IHg7IHRoZW4KKyAgICBPQ0FNTERPQz0ibm8iCisgIGVsc2UKKyAgICBjYXNlICRj
cm9zc19jb21waWxpbmc6JGFjX3Rvb2xfd2FybmVkIGluCit5ZXM6KQoreyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3Qg
cHJlZml4ZWQgd2l0aCBob3N0IHRyaXBsZXQiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklO
RzogdXNpbmcgY3Jvc3MgdG9vbHMgbm90IHByZWZpeGVkIHdpdGggaG9zdCB0cmlwbGV0IiA+JjI7
fQorYWNfdG9vbF93YXJuZWQ9eWVzIDs7Citlc2FjCisgICAgT0NBTUxET0M9JGFjX2N0X09DQU1M
RE9DCisgIGZpCitlbHNlCisgIE9DQU1MRE9DPSIkYWNfY3ZfcHJvZ19PQ0FNTERPQyIKK2ZpCisK
KworICAjIGNoZWNraW5nIGZvciBvY2FtbGJ1aWxkCisgIGlmIHRlc3QgLW4gIiRhY190b29sX3By
ZWZpeCI7IHRoZW4KKyAgIyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICIke2FjX3Rvb2xfcHJl
Zml4fW9jYW1sYnVpbGQiLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgor
c2V0IGR1bW15ICR7YWNfdG9vbF9wcmVmaXh9b2NhbWxidWlsZDsgYWNfd29yZD0kMgoreyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X3Byb2dfT0NBTUxCVUlMRCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRlc3QgLW4gIiRPQ0FNTEJVSUxEIjsgdGhlbgorICBh
Y19jdl9wcm9nX09DQU1MQlVJTEQ9IiRPQ0FNTEJVSUxEIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdC4KK2Vsc2UKK2FzX3NhdmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IK
K2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAi
JGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1
dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFj
X2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Ijsg
fTsgdGhlbgorICAgIGFjX2N2X3Byb2dfT0NBTUxCVUlMRD0iJHthY190b29sX3ByZWZpeH1vY2Ft
bGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5k
ICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2Rv
bmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK09DQU1MQlVJTEQ9JGFjX2N2
X3Byb2dfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJE9DQU1MQlVJTEQiOyB0aGVuCisgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkT0NBTUxCVUlMRCIg
PiY1CiskYXNfZWNobyAiJE9DQU1MQlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5v
IiA+JjY7IH0KK2ZpCisKKworZmkKK2lmIHRlc3QgLXogIiRhY19jdl9wcm9nX09DQU1MQlVJTEQi
OyB0aGVuCisgIGFjX2N0X09DQU1MQlVJTEQ9JE9DQU1MQlVJTEQKKyAgIyBFeHRyYWN0IHRoZSBm
aXJzdCB3b3JkIG9mICJvY2FtbGJ1aWxkIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdp
dGggYXJncy4KK3NldCBkdW1teSBvY2FtbGJ1aWxkOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3Zf
cHJvZ19hY19jdF9PQ0FNTEJVSUxEKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAtbiAiJGFjX2N0X09DQU1MQlVJTEQiOyB0aGVu
CisgIGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRD0iJGFjX2N0X09DQU1MQlVJTEQiICMgTGV0
IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0LgorZWxzZQorYXNfc2F2ZV9JRlM9JElGUzsgSUZT
PSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19zYXZl
X0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVjX2V4
dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYgIiRh
c19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFjX3dv
cmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcHJvZ19hY19jdF9PQ0FNTEJVSUxE
PSJvY2FtbGJ1aWxkIgorICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAg
ZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZlX0lGUworCitmaQorZmkKK2FjX2N0X09DQU1M
QlVJTEQ9JGFjX2N2X3Byb2dfYWNfY3RfT0NBTUxCVUlMRAoraWYgdGVzdCAtbiAiJGFjX2N0X09D
QU1MQlVJTEQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiAkYWNfY3RfT0NBTUxCVUlMRCIgPiY1CiskYXNfZWNobyAiJGFjX2N0X09DQU1M
QlVJTEQiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKyAgaWYg
dGVzdCAieCRhY19jdF9PQ0FNTEJVSUxEIiA9IHg7IHRoZW4KKyAgICBPQ0FNTEJVSUxEPSJubyIK
KyAgZWxzZQorICAgIGNhc2UgJGNyb3NzX2NvbXBpbGluZzokYWNfdG9vbF93YXJuZWQgaW4KK3ll
czopCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVz
aW5nIGNyb3NzIHRvb2xzIG5vdCBwcmVmaXhlZCB3aXRoIGhvc3QgdHJpcGxldCIgPiY1CiskYXNf
ZWNobyAiJGFzX21lOiBXQVJOSU5HOiB1c2luZyBjcm9zcyB0b29scyBub3QgcHJlZml4ZWQgd2l0
aCBob3N0IHRyaXBsZXQiID4mMjt9CithY190b29sX3dhcm5lZD15ZXMgOzsKK2VzYWMKKyAgICBP
Q0FNTEJVSUxEPSRhY19jdF9PQ0FNTEJVSUxECisgIGZpCitlbHNlCisgIE9DQU1MQlVJTEQ9IiRh
Y19jdl9wcm9nX09DQU1MQlVJTEQiCitmaQorCisKKyAgICBpZiB0ZXN0ICJ4JE9DQU1MQyIgPSAi
eG5vIjsgdGhlbiA6CisKKyAgICAgICAgaWYgdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAi
eHllcyI7IHRoZW4gOgorCisgICAgICAgICAgICBhc19mbl9lcnJvciAkPyAiT2NhbWwgdG9vbHMg
ZW5hYmxlZCwgYnV0IHVuYWJsZSB0byBmaW5kIE9jYW1sIiAiJExJTkVOTyIgNQorZmkKKyAgICAg
ICAgb2NhbWx0b29scz0ibiIKKworZmkKKworZmkKKyMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBv
ZiAiYmFzaCIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVt
bXkgYmFzaDsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
ICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3BhdGhfQkFTSCs6fSBmYWxzZTsgdGhl
biA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJEJBU0ggaW4K
KyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFjX2N2X3BhdGhfQkFTSD0iJEJBU0giICMgTGV0IHRo
ZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19z
YXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitk
bworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisg
ICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisg
IGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3Rf
eCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRo
X0JBU0g9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19t
ZToke2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgPiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZT
CisKKyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfQkFTSCIgJiYgYWNfY3ZfcGF0aF9CQVNIPSJubyIK
KyAgOzsKK2VzYWMKK2ZpCitCQVNIPSRhY19jdl9wYXRoX0JBU0gKK2lmIHRlc3QgLW4gIiRCQVNI
IjsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJEJBU0giID4mNQorJGFzX2VjaG8gIiRCQVNIIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19lY2hv
ICJubyIgPiY2OyB9CitmaQorCisKK2lmIHRlc3QgeCIke0JBU0h9IiA9PSB4Im5vIgordGhlbgor
ICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCBiYXNoLCBwbGVhc2UgaW5zdGFsbCBi
YXNoIiAiJExJTkVOTyIgNQorZmkKK2lmIHRlc3QgIngkcHl0aG9udG9vbHMiID0gInh5IjsgdGhl
biA6CisKKyAgICBpZiBlY2hvICIkUFlUSE9OIiB8IGdyZXAgLXEgIl4vIjsgdGhlbiA6CisKKyAg
ICAgICAgUFlUSE9OUEFUSD0kUFlUSE9OCisgICAgICAgIFBZVEhPTj1gYmFzZW5hbWUgJFBZVEhP
TlBBVEhgCisKK2VsaWYgdGVzdCAteiAiJFBZVEhPTiI7IHRoZW4gOgorICBQWVRIT049InB5dGhv
biIKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIlBZVEhPTiBzcGVjaWZpZWQsIGJ1dCBpcyBub3Qg
YW4gYWJzb2x1dGUgcGF0aCIgIiRMSU5FTk8iIDUKK2ZpCisgICAgIyBFeHRyYWN0IHRoZSBmaXJz
dCB3b3JkIG9mICIkUFlUSE9OIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBuYW1lIHdpdGggYXJn
cy4KK3NldCBkdW1teSAkUFlUSE9OOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19u
ICJjaGVja2luZyBmb3IgJGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9QWVRI
T05QQVRIKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vs
c2UKKyAgY2FzZSAkUFlUSE9OUEFUSCBpbgorICBbXFwvXSogfCA/OltcXC9dKikKKyAgYWNfY3Zf
cGF0aF9QWVRIT05QQVRIPSIkUFlUSE9OUEFUSCIgIyBMZXQgdGhlIHVzZXIgb3ZlcnJpZGUgdGhl
IHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZTPSRJRlM7IElGUz0k
UEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElGUz0kYXNfc2F2ZV9J
RlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3IgYWNfZXhlY19leHQg
aW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0ZXN0IC1mICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNfZGlyLyRhY193b3Jk
JGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfUFlUSE9OUEFUSD0iJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5v
LSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAgICBi
cmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0IC16
ICIkYWNfY3ZfcGF0aF9QWVRIT05QQVRIIiAmJiBhY19jdl9wYXRoX1BZVEhPTlBBVEg9Im5vIgor
ICA7OworZXNhYworZmkKK1BZVEhPTlBBVEg9JGFjX2N2X3BhdGhfUFlUSE9OUEFUSAoraWYgdGVz
dCAtbiAiJFBZVEhPTlBBVEgiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkUFlUSE9OUEFUSCIgPiY1CiskYXNfZWNobyAiJFBZVEhPTlBB
VEgiID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7IH0KK2ZpCisKKworaWYgdGVz
dCB4IiR7UFlUSE9OUEFUSH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVu
YWJsZSB0byBmaW5kICRQWVRIT04sIHBsZWFzZSBpbnN0YWxsICRQWVRIT04iICIkTElORU5PIiA1
CitmaQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIHB5dGhvbiB2ZXJzaW9uID49IDIuMyAuLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBv
cnQgc3lzOyBleGl0KGV2YWwoInN5cy52ZXJzaW9uX2luZm8gPCAoMiwgMykiKSknYAoraWYgdGVz
dCAiJD8iICE9ICIwIgordGhlbgorICAgIHB5dGhvbl92ZXJzaW9uPWAkUFlUSE9OIC1WIDI+JjFg
CisgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5v
IiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CisgICAgYXNfZm5fZXJyb3IgJD8gIiRweXRob25f
dmVyc2lvbiBpcyB0b28gb2xkLCBtaW5pbXVtIHJlcXVpcmVkIHZlcnNpb24gaXMgMi4zIiAiJExJ
TkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5P
fTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQorICAgIHsgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHB5dGhvbiB4
bWwuZG9tLm1pbmlkb20iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiB4bWwu
ZG9tLm1pbmlkb20uLi4gIiA+JjY7IH0KK2AkUFlUSE9OIC1jICdpbXBvcnQgeG1sLmRvbS5taW5p
ZG9tJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KKyAgICBhc19mbl9lcnJvciAkPyAiVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5taW5pZG9tIG1v
ZHVsZSIgIiRMSU5FTk8iIDUKK2Vsc2UKKyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5l
bm8tJExJTkVOT306IHJlc3VsdDogeWVzIiA+JjUKKyRhc19lY2hvICJ5ZXMiID4mNjsgfQorZmkK
KyAgICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZv
ciBweXRob24gZGV2ZWwiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHB5dGhvbiBkZXZl
bC4uLiAiID4mNjsgfQorCitgJFBZVEhPTiAtYyAnCitpbXBvcnQgb3MucGF0aCwgc3lzCitmb3Ig
cCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRoLmV4aXN0cyhwICsgIi9jb25maWcvTWFrZWZp
bGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5cy5leGl0KDEpCisnID4gL2Rldi9udWxsIDI+
JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KKyAgICBhc19mbl9lcnJvciAkPyAiUHl0aG9uIGRldmVsIHBhY2thZ2Ugbm90IGZvdW5kIiAi
JExJTkVOTyIgNQorZWxzZQorICAgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiB5ZXMiID4mNQorJGFzX2VjaG8gInllcyIgPiY2OyB9CitmaQorCitmaQor
IyBFeHRyYWN0IHRoZSBmaXJzdCB3b3JkIG9mICJ4Z2V0dGV4dCIsIHNvIGl0IGNhbiBiZSBhIHBy
b2dyYW0gbmFtZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgeGdldHRleHQ7IGFjX3dvcmQ9JDIKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yICRhY193
b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9wYXRoX1hHRVRURVhUKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAi
KGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2FzZSAkWEdFVFRFWFQgaW4KKyAgW1xcL10qIHwgPzpb
XFwvXSopCisgIGFjX2N2X3BhdGhfWEdFVFRFWFQ9IiRYR0VUVEVYVCIgIyBMZXQgdGhlIHVzZXIg
b3ZlcnJpZGUgdGhlIHRlc3Qgd2l0aCBhIHBhdGguCisgIDs7CisgICopCisgIGFzX3NhdmVfSUZT
PSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2RvCisgIElG
Uz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAgICBmb3Ig
YWNfZXhlY19leHQgaW4gJycgJGFjX2V4ZWN1dGFibGVfZXh0ZW5zaW9uczsgZG8KKyAgaWYgeyB0
ZXN0IC1mICIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiAmJiAkYXNfdGVzdF94ICIkYXNf
ZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IjsgfTsgdGhlbgorICAgIGFjX2N2X3BhdGhfWEdFVFRF
WFQ9IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIg
PiY1CisgICAgYnJlYWsgMgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisK
KyAgdGVzdCAteiAiJGFjX2N2X3BhdGhfWEdFVFRFWFQiICYmIGFjX2N2X3BhdGhfWEdFVFRFWFQ9
Im5vIgorICA7OworZXNhYworZmkKK1hHRVRURVhUPSRhY19jdl9wYXRoX1hHRVRURVhUCitpZiB0
ZXN0IC1uICIkWEdFVFRFWFQiOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkWEdFVFRFWFQiID4mNQorJGFzX2VjaG8gIiRYR0VUVEVYVCIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCitpZiB0ZXN0IHgi
JHtYR0VUVEVYVH0iID09IHgibm8iCit0aGVuCisgICAgYXNfZm5fZXJyb3IgJD8gIlVuYWJsZSB0
byBmaW5kIHhnZXR0ZXh0LCBwbGVhc2UgaW5zdGFsbCB4Z2V0dGV4dCIgIiRMSU5FTk8iIDUKK2Zp
CitpZiB0ZXN0ICJ4JGhvc3Rfb3MiID09ICJ4bGludXgtZ251IgordGhlbgorICAgICMgRXh0cmFj
dCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmFkbSIsIHNvIGl0IGNhbiBiZSBhIHByb2dyYW0gbmFt
ZSB3aXRoIGFyZ3MuCitzZXQgZHVtbXkgdWRldmFkbTsgYWNfd29yZD0kMgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4mNQor
JGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2FjX2N2
X3BhdGhfVURFVkFETSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGNhc2UgJFVERVZBRE0gaW4KKyAgW1xcL10qIHwgPzpbXFwvXSopCisgIGFj
X2N2X3BhdGhfVURFVkFETT0iJFVERVZBRE0iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0
ZXN0IHdpdGggYSBwYXRoLgorICA7OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBB
VEhfU0VQQVJBVE9SCitmb3IgYXNfZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZT
CisgIHRlc3QgLXogIiRhc19kaXIiICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGlu
ICcnICRhY19leGVjdXRhYmxlX2V4dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rp
ci8kYWNfd29yZCRhY19leGVjX2V4dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRh
Y19leGVjX2V4dCI7IH07IHRoZW4KKyAgICBhY19jdl9wYXRoX1VERVZBRE09IiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiCisgICAgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogZm91bmQgJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIgPiY1CisgICAgYnJlYWsg
MgorICBmaQorZG9uZQorICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgdGVzdCAteiAiJGFj
X2N2X3BhdGhfVURFVkFETSIgJiYgYWNfY3ZfcGF0aF9VREVWQURNPSJubyIKKyAgOzsKK2VzYWMK
K2ZpCitVREVWQURNPSRhY19jdl9wYXRoX1VERVZBRE0KK2lmIHRlc3QgLW4gIiRVREVWQURNIjsg
dGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDog
JFVERVZBRE0iID4mNQorJGFzX2VjaG8gIiRVREVWQURNIiA+JjY7IH0KK2Vsc2UKKyAgeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6IG5vIiA+JjUKKyRhc19l
Y2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtVREVWQURNfSIgPT0geCJu
byIKKyAgICB0aGVuCisgICAgICAgICMgRXh0cmFjdCB0aGUgZmlyc3Qgd29yZCBvZiAidWRldmlu
Zm8iLCBzbyBpdCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IHVk
ZXZpbmZvOyBhY193b3JkPSQyCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciAkYWNfd29yZCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
JGFjX3dvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfcGF0aF9VREVWSU5GTys6fSBmYWxzZTsg
dGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhc2UgJFVERVZJ
TkZPIGluCisgIFtcXC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX1VERVZJTkZPPSIkVURF
VklORk8iICMgTGV0IHRoZSB1c2VyIG92ZXJyaWRlIHRoZSB0ZXN0IHdpdGggYSBwYXRoLgorICA7
OworICAqKQorICBhc19zYXZlX0lGUz0kSUZTOyBJRlM9JFBBVEhfU0VQQVJBVE9SCitmb3IgYXNf
ZGlyIGluICRQQVRICitkbworICBJRlM9JGFzX3NhdmVfSUZTCisgIHRlc3QgLXogIiRhc19kaXIi
ICYmIGFzX2Rpcj0uCisgICAgZm9yIGFjX2V4ZWNfZXh0IGluICcnICRhY19leGVjdXRhYmxlX2V4
dGVuc2lvbnM7IGRvCisgIGlmIHsgdGVzdCAtZiAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4
dCIgJiYgJGFzX3Rlc3RfeCAiJGFzX2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCI7IH07IHRoZW4K
KyAgICBhY19jdl9wYXRoX1VERVZJTkZPPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0Igor
ICAgICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIv
JGFjX3dvcmQkYWNfZXhlY19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9u
ZQorSUZTPSRhc19zYXZlX0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX1VERVZJTkZPIiAm
JiBhY19jdl9wYXRoX1VERVZJTkZPPSJubyIKKyAgOzsKK2VzYWMKK2ZpCitVREVWSU5GTz0kYWNf
Y3ZfcGF0aF9VREVWSU5GTworaWYgdGVzdCAtbiAiJFVERVZJTkZPIjsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJFVERVZJTkZPIiA+JjUK
KyRhc19lY2hvICIkVURFVklORk8iID4mNjsgfQorZWxzZQorICB7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogbm8iID4mNQorJGFzX2VjaG8gIm5vIiA+JjY7
IH0KK2ZpCisKKworICAgICAgICBpZiB0ZXN0IHgiJHtVREVWSU5GT30iID09IHgibm8iCisgICAg
ICAgIHRoZW4KKyAgICAgICAgICAgIGFzX2ZuX2Vycm9yICQ/ICJVbmFibGUgdG8gZmluZCB1ZGV2
YWRtIG9yIHVkZXZpbmZvLCBwbGVhc2UgaW5zdGFsbCB1ZGV2IiAiJExJTkVOTyIgNQorICAgICAg
ICBmaQorICAgICAgICB1ZGV2dmVyPWAke1VERVZJTkZPfSAtViB8IGF3ayAne3ByaW50ICRORn0n
YAorICAgIGVsc2UKKyAgICAgICAgdWRldnZlcj1gJHtVREVWQURNfSBpbmZvIC1WIHwgYXdrICd7
cHJpbnQgJE5GfSdgCisgICAgZmkKKyAgICBpZiB0ZXN0ICR7dWRldnZlcn0gLWx0IDU5CisgICAg
dGhlbgorICAgICAgICAjIEV4dHJhY3QgdGhlIGZpcnN0IHdvcmQgb2YgImhvdHBsdWciLCBzbyBp
dCBjYW4gYmUgYSBwcm9ncmFtIG5hbWUgd2l0aCBhcmdzLgorc2V0IGR1bW15IGhvdHBsdWc7IGFj
X3dvcmQ9JDIKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yICRhY193b3JkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciAkYWNfd29yZC4u
LiAiID4mNjsgfQoraWYgJHthY19jdl9wYXRoX0hPVFBMVUcrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXNlICRIT1RQTFVHIGluCisgIFtc
XC9dKiB8ID86W1xcL10qKQorICBhY19jdl9wYXRoX0hPVFBMVUc9IiRIT1RQTFVHIiAjIExldCB0
aGUgdXNlciBvdmVycmlkZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNf
c2F2ZV9JRlM9JElGUzsgSUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAor
ZG8KKyAgSUZTPSRhc19zYXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9Lgor
ICAgIGZvciBhY19leGVjX2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbwor
ICBpZiB7IHRlc3QgLWYgIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0
X3ggIiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0
aF9IT1RQTFVHPSIkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IgorICAgICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGZvdW5kICRhc19kaXIvJGFjX3dvcmQkYWNfZXhl
Y19leHQiID4mNQorICAgIGJyZWFrIDIKKyAgZmkKK2RvbmUKKyAgZG9uZQorSUZTPSRhc19zYXZl
X0lGUworCisgIHRlc3QgLXogIiRhY19jdl9wYXRoX0hPVFBMVUciICYmIGFjX2N2X3BhdGhfSE9U
UExVRz0ibm8iCisgIDs7Citlc2FjCitmaQorSE9UUExVRz0kYWNfY3ZfcGF0aF9IT1RQTFVHCitp
ZiB0ZXN0IC1uICIkSE9UUExVRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRIT1RQTFVHIiA+JjUKKyRhc19lY2hvICIkSE9UUExVRyIg
PiY2OyB9CitlbHNlCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiBubyIgPiY1CiskYXNfZWNobyAibm8iID4mNjsgfQorZmkKKworCisgICAgICAgIGlm
IHRlc3QgeCIke0hPVFBMVUd9IiA9PSB4Im5vIgorICAgICAgICB0aGVuCisgICAgICAgICAgICBh
c19mbl9lcnJvciAkPyAidWRldiBpcyB0b28gb2xkLCB1cGdyYWRlIHRvIHZlcnNpb24gNTkgb3Ig
bGF0ZXIiICIkTElORU5PIiA1CisgICAgICAgIGZpCisgICAgZmkKK2Vsc2UKKyAgICAjIEV4dHJh
Y3QgdGhlIGZpcnN0IHdvcmQgb2YgInZuY29uZmlnIiwgc28gaXQgY2FuIGJlIGEgcHJvZ3JhbSBu
YW1lIHdpdGggYXJncy4KK3NldCBkdW1teSB2bmNvbmZpZzsgYWNfd29yZD0kMgoreyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgJGFjX3dvcmQiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yICRhY193b3JkLi4uICIgPiY2OyB9CitpZiAke2Fj
X2N2X3BhdGhfVk5DT05GSUcrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBjYXNlICRWTkNPTkZJRyBpbgorICBbXFwvXSogfCA/OltcXC9dKikK
KyAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJFZOQ09ORklHIiAjIExldCB0aGUgdXNlciBvdmVycmlk
ZSB0aGUgdGVzdCB3aXRoIGEgcGF0aC4KKyAgOzsKKyAgKikKKyAgYXNfc2F2ZV9JRlM9JElGUzsg
SUZTPSRQQVRIX1NFUEFSQVRPUgorZm9yIGFzX2RpciBpbiAkUEFUSAorZG8KKyAgSUZTPSRhc19z
YXZlX0lGUworICB0ZXN0IC16ICIkYXNfZGlyIiAmJiBhc19kaXI9LgorICAgIGZvciBhY19leGVj
X2V4dCBpbiAnJyAkYWNfZXhlY3V0YWJsZV9leHRlbnNpb25zOyBkbworICBpZiB7IHRlc3QgLWYg
IiRhc19kaXIvJGFjX3dvcmQkYWNfZXhlY19leHQiICYmICRhc190ZXN0X3ggIiRhc19kaXIvJGFj
X3dvcmQkYWNfZXhlY19leHQiOyB9OyB0aGVuCisgICAgYWNfY3ZfcGF0aF9WTkNPTkZJRz0iJGFz
X2Rpci8kYWNfd29yZCRhY19leGVjX2V4dCIKKyAgICAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBmb3VuZCAkYXNfZGlyLyRhY193b3JkJGFjX2V4ZWNfZXh0IiA+JjUKKyAg
ICBicmVhayAyCisgIGZpCitkb25lCisgIGRvbmUKK0lGUz0kYXNfc2F2ZV9JRlMKKworICB0ZXN0
IC16ICIkYWNfY3ZfcGF0aF9WTkNPTkZJRyIgJiYgYWNfY3ZfcGF0aF9WTkNPTkZJRz0ibm8iCisg
IDs7Citlc2FjCitmaQorVk5DT05GSUc9JGFjX2N2X3BhdGhfVk5DT05GSUcKK2lmIHRlc3QgLW4g
IiRWTkNPTkZJRyI7IHRoZW4KKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRWTkNPTkZJRyIgPiY1CiskYXNfZWNobyAiJFZOQ09ORklHIiA+JjY7IH0K
K2Vsc2UKKyAgeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6
IG5vIiA+JjUKKyRhc19lY2hvICJubyIgPiY2OyB9CitmaQorCisKKyAgICBpZiB0ZXN0IHgiJHtW
TkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAgICAgICBhc19mbl9lcnJvciAkPyAiTm90
IGEgTGludXggc3lzdGVtIGFuZCB1bmFibGUgdG8gZmluZCB2bmQiICIkTElORU5PIiA1CisgICAg
ZmkKK2ZpCisKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK2lmIHRlc3QgLWQgIiRwcmVmaXgvbGli
NjQiOyB0aGVuIDoKKworICAgIExJQl9QQVRIPSJsaWI2NCIKKworZWxzZQorCisgICAgTElCX1BB
VEg9ImxpYiIKKworZmkKKworCisjIENoZWNrcyBmb3IgbGlicmFyaWVzLgoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgaW9fc2V0dXAgaW4gLWxh
aW8iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGlvX3NldHVwIGluIC1sYWlvLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X2xpYl9haW9faW9fc2V0dXArOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJT
PSRMSUJTCitMSUJTPSItbGFpbyAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5j
b25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFu
eSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIg
YmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWls
dGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAq
LworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgaW9fc2V0dXAg
KCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBpb19zZXR1cCAoKTsKKyAgOworICByZXR1cm4g
MDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBh
Y19jdl9saWJfYWlvX2lvX3NldHVwPXllcworZWxzZQorICBhY19jdl9saWJfYWlvX2lvX3NldHVw
PW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisg
ICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xp
Yl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IHJlc3VsdDogJGFjX2N2X2xpYl9haW9faW9fc2V0dXAiID4mNQorJGFzX2VjaG8gIiRhY19jdl9s
aWJfYWlvX2lvX3NldHVwIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2Fpb19pb19zZXR1
cCIgPSB4eWVzOyB0aGVuIDoKKyAgc3lzdGVtX2Fpbz0ieSIKK2Vsc2UKKyAgc3lzdGVtX2Fpbz0i
biIKK2ZpCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVj
a2luZyBmb3IgTUQ1IGluIC1sY3J5cHRvIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBN
RDUgaW4gLWxjcnlwdG8uLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX2NyeXB0b19NRDUrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19j
aGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGNyeXB0byAgJExJQlMiCitjYXQgY29u
ZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4g
ICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lkIGFu
IGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVybiB0
eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5cGUg
d291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMiCisj
ZW5kaWYKK2NoYXIgTUQ1ICgpOworaW50CittYWluICgpCit7CityZXR1cm4gTUQ1ICgpOworICA7
CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsg
dGhlbiA6CisgIGFjX2N2X2xpYl9jcnlwdG9fTUQ1PXllcworZWxzZQorICBhY19jdl9saWJfY3J5
cHRvX01ENT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpl
eHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19j
aGVja19saWJfc2F2ZV9MSUJTCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfY3J5cHRvX01ENSIgPiY1CiskYXNfZWNobyAiJGFj
X2N2X2xpYl9jcnlwdG9fTUQ1IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2NyeXB0b19N
RDUiID0geHllczsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUg
SEFWRV9MSUJDUllQVE8gMQorX0FDRU9GCisKKyAgTElCUz0iLWxjcnlwdG8gJExJQlMiCisKK2Vs
c2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIGxpYmNyeXB0byIgIiRMSU5FTk8i
IDUKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIGV4dDJmc19vcGVuMiBpbiAtbGV4dDJmcyIgPiY1CiskYXNfZWNob19uICJjaGVja2lu
ZyBmb3IgZXh0MmZzX29wZW4yIGluIC1sZXh0MmZzLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xp
Yl9leHQyZnNfZXh0MmZzX29wZW4yKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNh
Y2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0i
LWxleHQyZnMgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFj
X2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVy
bmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50
IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhl
biBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBf
X2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIGV4dDJmc19vcGVuMiAoKTsKK2lu
dAorbWFpbiAoKQoreworcmV0dXJuIGV4dDJmc19vcGVuMiAoKTsKKyAgOworICByZXR1cm4gMDsK
K30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMj15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX2V4dDJmc19l
eHQyZnNfb3BlbjI9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0k
YWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2V4dDJmc19leHQyZnNfb3BlbjIiID4mNQor
JGFzX2VjaG8gIiRhY19jdl9saWJfZXh0MmZzX2V4dDJmc19vcGVuMiIgPiY2OyB9CitpZiB0ZXN0
ICJ4JGFjX2N2X2xpYl9leHQyZnNfZXh0MmZzX29wZW4yIiA9IHh5ZXM7IHRoZW4gOgorICBsaWJl
eHQyZnM9InkiCitlbHNlCisgIGxpYmV4dDJmcz0ibiIKK2ZpCisKKworeyAkYXNfZWNobyAiJGFz
X21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNoX2J1ZmZl
ciBpbiAtbGdjcnlwdCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgZ2NyeV9tZF9oYXNo
X2J1ZmZlciBpbiAtbGdjcnlwdC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfZ2NyeXB0X2dj
cnlfbWRfaGFzaF9idWZmZXIrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVk
KSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbGdj
cnlwdCAgJExJQlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwg
cHJvdG90eXBlIHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWln
aHQgbWF0Y2ggdGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0
cyBhcmd1bWVudCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3Bs
dXNwbHVzCitleHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZ2NyeV9tZF9oYXNoX2J1ZmZlciAoKTsK
K2ludAorbWFpbiAoKQoreworcmV0dXJuIGdjcnlfbWRfaGFzaF9idWZmZXIgKCk7CisgIDsKKyAg
cmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVu
IDoKKyAgYWNfY3ZfbGliX2djcnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyPXllcworZWxzZQorICBh
Y19jdl9saWJfZ2NyeXB0X2djcnlfbWRfaGFzaF9idWZmZXI9bm8KK2ZpCitybSAtZiBjb3JlIGNv
bmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQg
Y29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX2dj
cnlwdF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX2djcnlw
dF9nY3J5X21kX2hhc2hfYnVmZmVyIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2djcnlw
dF9nY3J5X21kX2hhc2hfYnVmZmVyIiA9IHh5ZXM7IHRoZW4gOgorICBsaWJnY3J5cHQ9InkiCitl
bHNlCisgIGxpYmdjcnlwdD0ibiIKK2ZpCisKKworeyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGlu
ZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgcHRocmVhZF9jcmVhdGUgaW4gLWxwdGhyZWFkIiA+
JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBwdGhyZWFkX2NyZWF0ZSBpbiAtbHB0aHJlYWQu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGUrOn0gZmFs
c2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVj
a19saWJfc2F2ZV9MSUJTPSRMSUJTCitMSUJTPSItbHB0aHJlYWQgICRMSUJTIgorY2F0IGNvbmZk
ZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAq
LworCisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBl
cnJvci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlw
ZSBvZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdv
dWxkIHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2Vu
ZGlmCitjaGFyIHB0aHJlYWRfY3JlYXRlICgpOworaW50CittYWluICgpCit7CityZXR1cm4gcHRo
cmVhZF9jcmVhdGUgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2Nf
dHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3B0aHJlYWRfcHRocmVhZF9j
cmVhdGU9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlPW5vCitm
aQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29u
ZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZl
X0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3Vs
dDogJGFjX2N2X2xpYl9wdGhyZWFkX3B0aHJlYWRfY3JlYXRlIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfbGliX3B0aHJlYWRfcHRocmVhZF9jcmVhdGUiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9s
aWJfcHRocmVhZF9wdGhyZWFkX2NyZWF0ZSIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorICBhc19m
bl9lcnJvciAkPyAiQ291bGQgbm90IGZpbmQgbGlicHRocmVhZCIgIiRMSU5FTk8iIDUKK2ZpCisK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIGNs
b2NrX2dldHRpbWUgaW4gLWxydCIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgY2xvY2tf
Z2V0dGltZSBpbiAtbHJ0Li4uICIgPiY2OyB9CitpZiAke2FjX2N2X2xpYl9ydF9jbG9ja19nZXR0
aW1lKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UK
KyAgYWNfY2hlY2tfbGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWxydCAgJExJQlMiCitjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMu
aC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBlIHRvIGF2b2lk
IGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2ggdGhlIHJldHVy
biB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVudCBwcm90b3R5
cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitleHRlcm4gIkMi
CisjZW5kaWYKK2NoYXIgY2xvY2tfZ2V0dGltZSAoKTsKK2ludAorbWFpbiAoKQoreworcmV0dXJu
IGNsb2NrX2dldHRpbWUgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX3J0X2Nsb2NrX2dldHRp
bWU9eWVzCitlbHNlCisgIGFjX2N2X2xpYl9ydF9jbG9ja19nZXR0aW1lPW5vCitmaQorcm0gLWYg
Y29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNf
ZXhlZXh0IGNvbmZ0ZXN0LiRhY19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2Zp
Cit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2
X2xpYl9ydF9jbG9ja19nZXR0aW1lIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX3J0X2Nsb2Nr
X2dldHRpbWUiID4mNjsgfQoraWYgdGVzdCAieCRhY19jdl9saWJfcnRfY2xvY2tfZ2V0dGltZSIg
PSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZF
X0xJQlJUIDEKK19BQ0VPRgorCisgIExJQlM9Ii1scnQgJExJQlMiCisKK2ZpCisKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHV1aWRfY2xlYXIg
aW4gLWx1dWlkIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB1dWlkX2NsZWFyIGluIC1s
dXVpZC4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfdXVpZF91dWlkX2NsZWFyKzp9IGZhbHNl
OyB0aGVuIDoKKyAgJGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tf
bGliX3NhdmVfTElCUz0kTElCUworTElCUz0iLWx1dWlkICAkTElCUyIKK2NhdCBjb25mZGVmcy5o
IC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKwor
LyogT3ZlcnJpZGUgYW55IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3Iu
CisgICBVc2UgY2hhciBiZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2Yg
YSBHQ0MKKyAgIGJ1aWx0aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBz
dGlsbCBhcHBseS4gICovCisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgor
Y2hhciB1dWlkX2NsZWFyICgpOworaW50CittYWluICgpCit7CityZXR1cm4gdXVpZF9jbGVhciAo
KTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfbGluayAiJExJ
TkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyPXllcworZWxzZQorICBh
Y19jdl9saWJfdXVpZF91dWlkX2NsZWFyPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIg
Y29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNvbmZ0ZXN0LiRh
Y19leHQKK0xJQlM9JGFjX2NoZWNrX2xpYl9zYXZlX0xJQlMKK2ZpCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2xpYl91dWlkX3V1aWRfY2xl
YXIiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfdXVpZF91dWlkX2NsZWFyIiA+JjY7IH0KK2lm
IHRlc3QgIngkYWNfY3ZfbGliX3V1aWRfdXVpZF9jbGVhciIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0
ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX0xJQlVVSUQgMQorX0FDRU9GCisK
KyAgTElCUz0iLWx1dWlkICRMSUJTIgorCitlbHNlCisgIGFzX2ZuX2Vycm9yICQ/ICJDb3VsZCBu
b3QgZmluZCBsaWJ1dWlkIiAiJExJTkVOTyIgNQorZmkKKworeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgeWFqbF9hbGxvYyBpbiAtbHlhamwiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHlhamxfYWxsb2MgaW4gLWx5YWpsLi4uICIgPiY2
OyB9CitpZiAke2FjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MrOn0gZmFsc2U7IHRoZW4gOgorICAk
YXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBhY19jaGVja19saWJfc2F2ZV9MSUJT
PSRMSUJTCitMSUJTPSItbHlhamwgICRMSUJTIgorY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworCisvKiBPdmVycmlkZSBh
bnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJvci4KKyAgIFVzZSBjaGFy
IGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBvZiBhIEdDQworICAgYnVp
bHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxkIHN0aWxsIGFwcGx5LiAg
Ki8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlmCitjaGFyIHlhamxfYWxs
b2MgKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiB5YWpsX2FsbG9jICgpOworICA7CisgIHJl
dHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2M9eWVzCitlbHNlCisgIGFjX2N2X2xpYl95YWps
X3lhamxfYWxsb2M9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0k
YWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX3lhamxfeWFqbF9hbGxvYyIgPiY1CiskYXNf
ZWNobyAiJGFjX2N2X2xpYl95YWpsX3lhamxfYWxsb2MiID4mNjsgfQoraWYgdGVzdCAieCRhY19j
dl9saWJfeWFqbF95YWpsX2FsbG9jIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5o
IDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfTElCWUFKTCAxCitfQUNFT0YKKworICBMSUJTPSItbHlh
amwgJExJQlMiCisKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNvdWxkIG5vdCBmaW5kIHlhamwi
ICIkTElORU5PIiA1CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVO
T306IGNoZWNraW5nIGZvciBkZWZsYXRlQ29weSBpbiAtbHoiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIGRlZmxhdGVDb3B5IGluIC1sei4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJf
el9kZWZsYXRlQ29weSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIg
PiY2CitlbHNlCisgIGFjX2NoZWNrX2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1seiAgJExJ
QlMiCitjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisKKy8qIE92ZXJyaWRlIGFueSBHQ0MgaW50ZXJuYWwgcHJvdG90eXBl
IHRvIGF2b2lkIGFuIGVycm9yLgorICAgVXNlIGNoYXIgYmVjYXVzZSBpbnQgbWlnaHQgbWF0Y2gg
dGhlIHJldHVybiB0eXBlIG9mIGEgR0NDCisgICBidWlsdGluIGFuZCB0aGVuIGl0cyBhcmd1bWVu
dCBwcm90b3R5cGUgd291bGQgc3RpbGwgYXBwbHkuICAqLworI2lmZGVmIF9fY3BsdXNwbHVzCitl
eHRlcm4gIkMiCisjZW5kaWYKK2NoYXIgZGVmbGF0ZUNvcHkgKCk7CitpbnQKK21haW4gKCkKK3sK
K3JldHVybiBkZWZsYXRlQ29weSAoKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYg
YWNfZm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9saWJfel9kZWZsYXRl
Q29weT15ZXMKK2Vsc2UKKyAgYWNfY3ZfbGliX3pfZGVmbGF0ZUNvcHk9bm8KK2ZpCitybSAtZiBj
b3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19l
eGVleHQgY29uZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
bGliX3pfZGVmbGF0ZUNvcHkiID4mNQorJGFzX2VjaG8gIiRhY19jdl9saWJfel9kZWZsYXRlQ29w
eSIgPiY2OyB9CitpZiB0ZXN0ICJ4JGFjX2N2X2xpYl96X2RlZmxhdGVDb3B5IiA9IHh5ZXM7IHRo
ZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVfTElCWiAxCitf
QUNFT0YKKworICBMSUJTPSItbHogJExJQlMiCisKK2Vsc2UKKyAgYXNfZm5fZXJyb3IgJD8gIkNv
dWxkIG5vdCBmaW5kIHpsaWIiICIkTElORU5PIiA1CitmaQorCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBsaWJpY29udl9vcGVuIGluIC1saWNv
bnYiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIGxpYmljb252X29wZW4gaW4gLWxpY29u
di4uLiAiID4mNjsgfQoraWYgJHthY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbis6fSBmYWxz
ZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGFjX2NoZWNr
X2xpYl9zYXZlX0xJQlM9JExJQlMKK0xJQlM9Ii1saWNvbnYgICRMSUJTIgorY2F0IGNvbmZkZWZz
LmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLwor
CisvKiBPdmVycmlkZSBhbnkgR0NDIGludGVybmFsIHByb3RvdHlwZSB0byBhdm9pZCBhbiBlcnJv
ci4KKyAgIFVzZSBjaGFyIGJlY2F1c2UgaW50IG1pZ2h0IG1hdGNoIHRoZSByZXR1cm4gdHlwZSBv
ZiBhIEdDQworICAgYnVpbHRpbiBhbmQgdGhlbiBpdHMgYXJndW1lbnQgcHJvdG90eXBlIHdvdWxk
IHN0aWxsIGFwcGx5LiAgKi8KKyNpZmRlZiBfX2NwbHVzcGx1cworZXh0ZXJuICJDIgorI2VuZGlm
CitjaGFyIGxpYmljb252X29wZW4gKCk7CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBsaWJpY29u
dl9vcGVuICgpOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9s
aW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2xpYl9pY29udl9saWJpY29udl9vcGVuPXll
cworZWxzZQorICBhY19jdl9saWJfaWNvbnZfbGliaWNvbnZfb3Blbj1ubworZmkKK3JtIC1mIGNv
cmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4
ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitMSUJTPSRhY19jaGVja19saWJfc2F2ZV9MSUJTCitmaQor
eyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9s
aWJfaWNvbnZfbGliaWNvbnZfb3BlbiIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9pY29udl9s
aWJpY29udl9vcGVuIiA+JjY7IH0KK2lmIHRlc3QgIngkYWNfY3ZfbGliX2ljb252X2xpYmljb252
X29wZW4iID0geHllczsgdGhlbiA6CisgIGxpYmljb252PSJ5IgorZWxzZQorICBsaWJpY29udj0i
biIKK2ZpCisKKworCisjIEF1dG9zY2FuIHN0dWZmIChleGNlcHQgZm9yIHlhamwveWFqbF92ZXJz
aW9uLmggY2hlY2spCisjIENoZWNrcyBmb3IgaGVhZGVyIGZpbGVzLgorYWNfZm5fY19jaGVja190
eXBlICIkTElORU5PIiAic2l6ZV90IiAiYWNfY3ZfdHlwZV9zaXplX3QiICIkYWNfaW5jbHVkZXNf
ZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9zaXplX3QiID0geHllczsgdGhlbiA6CisK
K2Vsc2UKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBzaXplX3QgdW5zaWdu
ZWQgaW50CitfQUNFT0YKKworZmkKKworIyBUaGUgVWx0cml4IDQuMiBtaXBzIGJ1aWx0aW4gYWxs
b2NhIGRlY2xhcmVkIGJ5IGFsbG9jYS5oIG9ubHkgd29ya3MKKyMgZm9yIGNvbnN0YW50IGFyZ3Vt
ZW50cy4gIFVzZWxlc3MhCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306
IGNoZWNraW5nIGZvciB3b3JraW5nIGFsbG9jYS5oIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5n
IGZvciB3b3JraW5nIGFsbG9jYS5oLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X3dvcmtpbmdfYWxs
b2NhX2grOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQg
Y29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8YWxsb2NhLmg+CitpbnQKK21haW4gKCkKK3sKK2No
YXIgKnAgPSAoY2hhciAqKSBhbGxvY2EgKDIgKiBzaXplb2YgKGludCkpOworCQkJICBpZiAocCkg
cmV0dXJuIDA7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X2xp
bmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3Zfd29ya2luZ19hbGxvY2FfaD15ZXMKK2Vsc2UK
KyAgYWNfY3Zfd29ya2luZ19hbGxvY2FfaD1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJy
IGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4k
YWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1
bHQ6ICRhY19jdl93b3JraW5nX2FsbG9jYV9oIiA+JjUKKyRhc19lY2hvICIkYWNfY3Zfd29ya2lu
Z19hbGxvY2FfaCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl93b3JraW5nX2FsbG9jYV9oID0geWVz
OyB0aGVuCisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfQUxMT0NBX0ggMSIgPj5jb25mZGVmcy5o
CisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIGFsbG9jYSIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3IgYWxsb2NhLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzKzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2lmZGVmIF9f
R05VQ19fCisjIGRlZmluZSBhbGxvY2EgX19idWlsdGluX2FsbG9jYQorI2Vsc2UKKyMgaWZkZWYg
X01TQ19WRVIKKyMgIGluY2x1ZGUgPG1hbGxvYy5oPgorIyAgZGVmaW5lIGFsbG9jYSBfYWxsb2Nh
CisjIGVsc2UKKyMgIGlmZGVmIEhBVkVfQUxMT0NBX0gKKyMgICBpbmNsdWRlIDxhbGxvY2EuaD4K
KyMgIGVsc2UKKyMgICBpZmRlZiBfQUlYCisgI3ByYWdtYSBhbGxvY2EKKyMgICBlbHNlCisjICAg
IGlmbmRlZiBhbGxvY2EgLyogcHJlZGVmaW5lZCBieSBIUCBjYyArT2xpYmNhbGxzICovCit2b2lk
ICphbGxvY2EgKHNpemVfdCk7CisjICAgIGVuZGlmCisjICAgZW5kaWYKKyMgIGVuZGlmCisjIGVu
ZGlmCisjZW5kaWYKKworaW50CittYWluICgpCit7CitjaGFyICpwID0gKGNoYXIgKikgYWxsb2Nh
ICgxKTsKKwkJCQkgICAgaWYgKHApIHJldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FD
RU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNf
YWxsb2NhX3dvcmtzPXllcworZWxzZQorICBhY19jdl9mdW5jX2FsbG9jYV93b3Jrcz1ubworZmkK
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0
ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9mdW5jX2FsbG9jYV93b3JrcyIgPiY1
CiskYXNfZWNobyAiJGFjX2N2X2Z1bmNfYWxsb2NhX3dvcmtzIiA+JjY7IH0KKworaWYgdGVzdCAk
YWNfY3ZfZnVuY19hbGxvY2Ffd29ya3MgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUg
SEFWRV9BTExPQ0EgMSIgPj5jb25mZGVmcy5oCisKK2Vsc2UKKyAgIyBUaGUgU1ZSMyBsaWJQVyBh
bmQgU1ZSNCBsaWJ1Y2IgYm90aCBjb250YWluIGluY29tcGF0aWJsZSBmdW5jdGlvbnMKKyMgdGhh
dCBjYXVzZSB0cm91YmxlLiAgU29tZSB2ZXJzaW9ucyBkbyBub3QgZXZlbiBjb250YWluIGFsbG9j
YSBvcgorIyBjb250YWluIGEgYnVnZ3kgdmVyc2lvbi4gIElmIHlvdSBzdGlsbCB3YW50IHRvIHVz
ZSB0aGVpciBhbGxvY2EsCisjIHVzZSBhciB0byBleHRyYWN0IGFsbG9jYS5vIGZyb20gdGhlbSBp
bnN0ZWFkIG9mIGNvbXBpbGluZyBhbGxvY2EuYy4KKworQUxMT0NBPVwke0xJQk9CSkRJUn1hbGxv
Y2EuJGFjX29iamV4dAorCiskYXNfZWNobyAiI2RlZmluZSBDX0FMTE9DQSAxIiA+PmNvbmZkZWZz
LmgKKworCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5n
IHdoZXRoZXIgXGBhbGxvY2EuYycgbmVlZHMgQ3JheSBob29rcyIgPiY1CiskYXNfZWNob19uICJj
aGVja2luZyB3aGV0aGVyIFxgYWxsb2NhLmMnIG5lZWRzIENyYXkgaG9va3MuLi4gIiA+JjY7IH0K
K2lmICR7YWNfY3Zfb3NfY3JheSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNo
ZWQpICIgPiY2CitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZiBkZWZpbmVkIENSQVkgJiYgISBkZWZp
bmVkIENSQVkyCit3ZWJlY3JheQorI2Vsc2UKK3dlbm90YmVjcmF5CisjZW5kaWYKKworX0FDRU9G
CitpZiAoZXZhbCAiJGFjX2NwcCBjb25mdGVzdC4kYWNfZXh0IikgMj4mNSB8CisgICRFR1JFUCAi
d2ViZWNyYXkiID4vZGV2L251bGwgMj4mMTsgdGhlbiA6CisgIGFjX2N2X29zX2NyYXk9eWVzCitl
bHNlCisgIGFjX2N2X29zX2NyYXk9bm8KK2ZpCitybSAtZiBjb25mdGVzdCoKKworZmkKK3sgJGFz
X2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zfb3NfY3Jh
eSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X29zX2NyYXkiID4mNjsgfQoraWYgdGVzdCAkYWNfY3Zf
b3NfY3JheSA9IHllczsgdGhlbgorICBmb3IgYWNfZnVuYyBpbiBfZ2V0YjY3IEdFVEI2NyBnZXRi
Njc7IGRvCisgICAgYXNfYWNfdmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAk
YXNfdHJfc2hgCithY19mbl9jX2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19h
Y192YXIiCitpZiBldmFsIHRlc3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgQ1JBWV9TVEFDS1NFR19FTkQg
JGFjX2Z1bmMKK19BQ0VPRgorCisgICAgYnJlYWsKK2ZpCisKKyAgZG9uZQorZmkKKworeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBzdGFjayBkaXJlY3Rp
b24gZm9yIEMgYWxsb2NhIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIHN0YWNrIGRpcmVjdGlv
biBmb3IgQyBhbGxvY2EuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19zdGFja19kaXJlY3Rpb24r
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBp
ZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Nfc3RhY2tf
ZGlyZWN0aW9uPTAKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3Qu
JGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKK2lu
dAorZmluZF9zdGFja19kaXJlY3Rpb24gKCkKK3sKKyAgc3RhdGljIGNoYXIgKmFkZHIgPSAwOwor
ICBhdXRvIGNoYXIgZHVtbXk7CisgIGlmIChhZGRyID09IDApCisgICAgeworICAgICAgYWRkciA9
ICZkdW1teTsKKyAgICAgIHJldHVybiBmaW5kX3N0YWNrX2RpcmVjdGlvbiAoKTsKKyAgICB9Cisg
IGVsc2UKKyAgICByZXR1cm4gKCZkdW1teSA+IGFkZHIpID8gMSA6IC0xOworfQorCitpbnQKK21h
aW4gKCkKK3sKKyAgcmV0dXJuIGZpbmRfc3RhY2tfZGlyZWN0aW9uICgpIDwgMDsKK30KK19BQ0VP
RgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Nfc3RhY2tf
ZGlyZWN0aW9uPTEKK2Vsc2UKKyAgYWNfY3ZfY19zdGFja19kaXJlY3Rpb249LTEKK2ZpCitybSAt
ZiBjb3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFj
X2V4ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4k
YWNfZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99
OiByZXN1bHQ6ICRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbiIgPiY1CiskYXNfZWNobyAiJGFjX2N2
X2Nfc3RhY2tfZGlyZWN0aW9uIiA+JjY7IH0KK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNk
ZWZpbmUgU1RBQ0tfRElSRUNUSU9OICRhY19jdl9jX3N0YWNrX2RpcmVjdGlvbgorX0FDRU9GCisK
KworZmkKKworZm9yIGFjX2hlYWRlciBpbiAgXAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5o
IGZjbnRsLmggaW50dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAg
ICAgICAgICAgIG5ldGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5o
IHN0cmluZy5oIFwKKyAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9j
dGwuaCBzeXMvbW91bnQuaCBzeXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tl
dC5oIHN5cy9zdGF0dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAg
ICAgICAgICAgIHVuaXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorCitkbyA6CisgIGFzX2Fj
X0hlYWRlcj1gJGFzX2VjaG8gImFjX2N2X2hlYWRlcl8kYWNfaGVhZGVyIiB8ICRhc190cl9zaGAK
K2FjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5FTk8iICIkYWNfaGVhZGVyIiAiJGFz
X2FjX0hlYWRlciIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgZXZhbCB0ZXN0IFwieFwkIiRh
c19hY19IZWFkZXIiXCIgPSB4InllcyI7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FD
RU9GCisjZGVmaW5lIGAkYXNfZWNobyAiSEFWRV8kYWNfaGVhZGVyIiB8ICRhc190cl9jcHBgIDEK
K19BQ0VPRgorCitmaQorCitkb25lCisKKworIyBDaGVja3MgZm9yIHR5cGVkZWZzLCBzdHJ1Y3R1
cmVzLCBhbmQgY29tcGlsZXIgY2hhcmFjdGVyaXN0aWNzLgoreyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igc3RkYm9vbC5oIHRoYXQgY29uZm9ybXMg
dG8gQzk5IiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBzdGRib29sLmggdGhhdCBjb25m
b3JtcyB0byBDOTkuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGNhdCBj
b25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5o
LiAgKi8KKworI2luY2x1ZGUgPHN0ZGJvb2wuaD4KKyNpZm5kZWYgYm9vbAorICJlcnJvcjogYm9v
bCBpcyBub3QgZGVmaW5lZCIKKyNlbmRpZgorI2lmbmRlZiBmYWxzZQorICJlcnJvcjogZmFsc2Ug
aXMgbm90IGRlZmluZWQiCisjZW5kaWYKKyNpZiBmYWxzZQorICJlcnJvcjogZmFsc2UgaXMgbm90
IDAiCisjZW5kaWYKKyNpZm5kZWYgdHJ1ZQorICJlcnJvcjogdHJ1ZSBpcyBub3QgZGVmaW5lZCIK
KyNlbmRpZgorI2lmIHRydWUgIT0gMQorICJlcnJvcjogdHJ1ZSBpcyBub3QgMSIKKyNlbmRpZgor
I2lmbmRlZiBfX2Jvb2xfdHJ1ZV9mYWxzZV9hcmVfZGVmaW5lZAorICJlcnJvcjogX19ib29sX3Ry
dWVfZmFsc2VfYXJlX2RlZmluZWQgaXMgbm90IGRlZmluZWQiCisjZW5kaWYKKworCXN0cnVjdCBz
IHsgX0Jvb2wgczogMTsgX0Jvb2wgdDsgfSBzOworCisJY2hhciBhW3RydWUgPT0gMSA/IDEgOiAt
MV07CisJY2hhciBiW2ZhbHNlID09IDAgPyAxIDogLTFdOworCWNoYXIgY1tfX2Jvb2xfdHJ1ZV9m
YWxzZV9hcmVfZGVmaW5lZCA9PSAxID8gMSA6IC0xXTsKKwljaGFyIGRbKGJvb2wpIDAuNSA9PSB0
cnVlID8gMSA6IC0xXTsKKwkvKiBTZWUgYm9keSBvZiBtYWluIHByb2dyYW0gZm9yICdlJy4gICov
CisJY2hhciBmWyhfQm9vbCkgMC4wID09IGZhbHNlID8gMSA6IC0xXTsKKwljaGFyIGdbdHJ1ZV07
CisJY2hhciBoW3NpemVvZiAoX0Jvb2wpXTsKKwljaGFyIGlbc2l6ZW9mIHMudF07CisJZW51bSB7
IGogPSBmYWxzZSwgayA9IHRydWUsIGwgPSBmYWxzZSAqIHRydWUsIG0gPSB0cnVlICogMjU2IH07
CisJLyogVGhlIGZvbGxvd2luZyBmYWlscyBmb3IKKwkgICBIUCBhQysrL0FOU0kgQyBCMzkxMEIg
QS4wNS41NSBbRGVjIDA0IDIwMDNdLiAqLworCV9Cb29sIG5bbV07CisJY2hhciBvW3NpemVvZiBu
ID09IG0gKiBzaXplb2YgblswXSA/IDEgOiAtMV07CisJY2hhciBwWy0xIC0gKF9Cb29sKSAwIDwg
MCAmJiAtMSAtIChib29sKSAwIDwgMCA/IDEgOiAtMV07CisJLyogQ2F0Y2ggYSBidWcgaW4gYW4g
SFAtVVggQyBjb21waWxlci4gIFNlZQorCSAgIGh0dHA6Ly9nY2MuZ251Lm9yZy9tbC9nY2MtcGF0
Y2hlcy8yMDAzLTEyL21zZzAyMzAzLmh0bWwKKwkgICBodHRwOi8vbGlzdHMuZ251Lm9yZy9hcmNo
aXZlL2h0bWwvYnVnLWNvcmV1dGlscy8yMDA1LTExL21zZzAwMTYxLmh0bWwKKwkgKi8KKwlfQm9v
bCBxID0gdHJ1ZTsKKwlfQm9vbCAqcHEgPSAmcTsKKworaW50CittYWluICgpCit7CisKKwlib29s
IGUgPSAmczsKKwkqcHEgfD0gcTsKKwkqcHEgfD0gISBxOworCS8qIFJlZmVyIHRvIGV2ZXJ5IGRl
Y2xhcmVkIHZhbHVlLCB0byBhdm9pZCBjb21waWxlciBvcHRpbWl6YXRpb25zLiAgKi8KKwlyZXR1
cm4gKCFhICsgIWIgKyAhYyArICFkICsgIWUgKyAhZiArICFnICsgIWggKyAhaSArICEhaiArICFr
ICsgISFsCisJCSsgIW0gKyAhbiArICFvICsgIXAgKyAhcSArICFwcSk7CisKKyAgOworICByZXR1
cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfY29tcGlsZSAiJExJTkVOTyI7IHRoZW4g
OgorICBhY19jdl9oZWFkZXJfc3RkYm9vbF9oPXllcworZWxzZQorICBhY19jdl9oZWFkZXJfc3Rk
Ym9vbF9oPW5vCitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRM
SU5FTk99OiByZXN1bHQ6ICRhY19jdl9oZWFkZXJfc3RkYm9vbF9oIiA+JjUKKyRhc19lY2hvICIk
YWNfY3ZfaGVhZGVyX3N0ZGJvb2xfaCIgPiY2OyB9CithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5F
Tk8iICJfQm9vbCIgImFjX2N2X3R5cGVfX0Jvb2wiICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lm
IHRlc3QgIngkYWNfY3ZfdHlwZV9fQm9vbCIgPSB4eWVzOyB0aGVuIDoKKworY2F0ID4+Y29uZmRl
ZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX19CT09MIDEKK19BQ0VPRgorCisKK2ZpCisKK2lm
IHRlc3QgJGFjX2N2X2hlYWRlcl9zdGRib29sX2ggPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNk
ZWZpbmUgSEFWRV9TVERCT09MX0ggMSIgPj5jb25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8g
IiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHVpZF90IGluIHN5cy90
eXBlcy5oIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciB1aWRfdCBpbiBzeXMvdHlwZXMu
aC4uLiAiID4mNjsgfQoraWYgJHthY19jdl90eXBlX3VpZF90Kzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9B
Q0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworI2luY2x1ZGUg
PHN5cy90eXBlcy5oPgorCitfQUNFT0YKK2lmIChldmFsICIkYWNfY3BwIGNvbmZ0ZXN0LiRhY19l
eHQiKSAyPiY1IHwKKyAgJEVHUkVQICJ1aWRfdCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuIDoKKyAg
YWNfY3ZfdHlwZV91aWRfdD15ZXMKK2Vsc2UKKyAgYWNfY3ZfdHlwZV91aWRfdD1ubworZmkKK3Jt
IC1mIGNvbmZ0ZXN0KgorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5F
Tk99OiByZXN1bHQ6ICRhY19jdl90eXBlX3VpZF90IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfdHlw
ZV91aWRfdCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl90eXBlX3VpZF90ID0gbm87IHRoZW4KKwor
JGFzX2VjaG8gIiNkZWZpbmUgdWlkX3QgaW50IiA+PmNvbmZkZWZzLmgKKworCiskYXNfZWNobyAi
I2RlZmluZSBnaWRfdCBpbnQiID4+Y29uZmRlZnMuaAorCitmaQorCit7ICRhc19lY2hvICIkYXNf
bWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciBpbmxpbmUiID4mNQorJGFzX2Vj
aG9fbiAiY2hlY2tpbmcgZm9yIGlubGluZS4uLiAiID4mNjsgfQoraWYgJHthY19jdl9jX2lubGlu
ZSs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisg
IGFjX2N2X2NfaW5saW5lPW5vCitmb3IgYWNfa3cgaW4gaW5saW5lIF9faW5saW5lX18gX19pbmxp
bmU7IGRvCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8q
IGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZm5kZWYgX19jcGx1c3BsdXMKK3R5cGVkZWYgaW50IGZv
b190Oworc3RhdGljICRhY19rdyBmb29fdCBzdGF0aWNfZm9vICgpIHtyZXR1cm4gMDsgfQorJGFj
X2t3IGZvb190IGZvbyAoKSB7cmV0dXJuIDA7IH0KKyNlbmRpZgorCitfQUNFT0YKK2lmIGFjX2Zu
X2NfdHJ5X2NvbXBpbGUgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfY19pbmxpbmU9JGFjX2t3
CitmaQorcm0gLWYgY29yZSBjb25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVz
dC4kYWNfZXh0CisgIHRlc3QgIiRhY19jdl9jX2lubGluZSIgIT0gbm8gJiYgYnJlYWsKK2RvbmUK
KworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAk
YWNfY3ZfY19pbmxpbmUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9jX2lubGluZSIgPiY2OyB9CisK
K2Nhc2UgJGFjX2N2X2NfaW5saW5lIGluCisgIGlubGluZSB8IHllcykgOzsKKyAgKikKKyAgICBj
YXNlICRhY19jdl9jX2lubGluZSBpbgorICAgICAgbm8pIGFjX3ZhbD07OworICAgICAgKikgYWNf
dmFsPSRhY19jdl9jX2lubGluZTs7CisgICAgZXNhYworICAgIGNhdCA+PmNvbmZkZWZzLmggPDxf
QUNFT0YKKyNpZm5kZWYgX19jcGx1c3BsdXMKKyNkZWZpbmUgaW5saW5lICRhY192YWwKKyNlbmRp
ZgorX0FDRU9GCisgICAgOzsKK2VzYWMKKworYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIg
IjE2IiAiYWNfY3ZfY19pbnQxNl90IgorY2FzZSAkYWNfY3ZfY19pbnQxNl90IGluICMoCisgIG5v
fHllcykgOzsgIygKKyAgKikKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBp
bnQxNl90ICRhY19jdl9jX2ludDE2X3QKK19BQ0VPRgorOzsKK2VzYWMKKworYWNfZm5fY19maW5k
X2ludFhfdCAiJExJTkVOTyIgIjMyIiAiYWNfY3ZfY19pbnQzMl90IgorY2FzZSAkYWNfY3ZfY19p
bnQzMl90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikKKworY2F0ID4+Y29uZmRlZnMuaCA8
PF9BQ0VPRgorI2RlZmluZSBpbnQzMl90ICRhY19jdl9jX2ludDMyX3QKK19BQ0VPRgorOzsKK2Vz
YWMKKworYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIgIjY0IiAiYWNfY3ZfY19pbnQ2NF90
IgorY2FzZSAkYWNfY3ZfY19pbnQ2NF90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBpbnQ2NF90ICRhY19jdl9jX2ludDY0
X3QKK19BQ0VPRgorOzsKK2VzYWMKKworYWNfZm5fY19maW5kX2ludFhfdCAiJExJTkVOTyIgIjgi
ICJhY19jdl9jX2ludDhfdCIKK2Nhc2UgJGFjX2N2X2NfaW50OF90IGluICMoCisgIG5vfHllcykg
OzsgIygKKyAgKikKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBpbnQ4X3Qg
JGFjX2N2X2NfaW50OF90CitfQUNFT0YKKzs7Citlc2FjCisKK2FjX2ZuX2NfY2hlY2tfdHlwZSAi
JExJTkVOTyIgIm1vZGVfdCIgImFjX2N2X3R5cGVfbW9kZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1
bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfbW9kZV90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNl
CisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgbW9kZV90IGludAorX0FDRU9G
CisKK2ZpCisKK2FjX2ZuX2NfY2hlY2tfdHlwZSAiJExJTkVOTyIgIm9mZl90IiAiYWNfY3ZfdHlw
ZV9vZmZfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX29m
Zl90IiA9IHh5ZXM7IHRoZW4gOgorCitlbHNlCisKK2NhdCA+PmNvbmZkZWZzLmggPDxfQUNFT0YK
KyNkZWZpbmUgb2ZmX3QgbG9uZyBpbnQKK19BQ0VPRgorCitmaQorCithY19mbl9jX2NoZWNrX3R5
cGUgIiRMSU5FTk8iICJwaWRfdCIgImFjX2N2X3R5cGVfcGlkX3QiICIkYWNfaW5jbHVkZXNfZGVm
YXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfdHlwZV9waWRfdCIgPSB4eWVzOyB0aGVuIDoKKworZWxz
ZQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIHBpZF90IGludAorX0FDRU9G
CisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcg
Zm9yIEMvQysrIHJlc3RyaWN0IGtleXdvcmQuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfY19yZXN0
cmljdCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGFjX2N2X2NfcmVzdHJpY3Q9bm8KKyAgICMgVGhlIG9yZGVyIGhlcmUgY2F0ZXJzIHRvIHRo
ZSBmYWN0IHRoYXQgQysrIGRvZXMgbm90IHJlcXVpcmUgcmVzdHJpY3QuCisgICBmb3IgYWNfa3cg
aW4gX19yZXN0cmljdCBfX3Jlc3RyaWN0X18gX1Jlc3RyaWN0IHJlc3RyaWN0OyBkbworICAgICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCit0eXBlZGVmIGludCAqIGludF9wdHI7CisJaW50IGZvbyAoaW50X3B0ciAkYWNf
a3cgaXApIHsKKwlyZXR1cm4gaXBbMF07CisgICAgICAgfQoraW50CittYWluICgpCit7CitpbnQg
c1sxXTsKKwlpbnQgKiAkYWNfa3cgdCA9IHM7CisJdFswXSA9IDA7CisJcmV0dXJuIGZvbyh0KQor
ICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElO
RU5PIjsgdGhlbiA6CisgIGFjX2N2X2NfcmVzdHJpY3Q9JGFjX2t3CitmaQorcm0gLWYgY29yZSBj
b25mdGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC4kYWNfZXh0CisgICAgIHRl
c3QgIiRhY19jdl9jX3Jlc3RyaWN0IiAhPSBubyAmJiBicmVhaworICAgZG9uZQorCitmaQoreyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9jX3Jl
c3RyaWN0IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfY19yZXN0cmljdCIgPiY2OyB9CisKKyBjYXNl
ICRhY19jdl9jX3Jlc3RyaWN0IGluCisgICByZXN0cmljdCkgOzsKKyAgIG5vKSAkYXNfZWNobyAi
I2RlZmluZSByZXN0cmljdCAvKiovIiA+PmNvbmZkZWZzLmgKKyA7OworICAgKikgIGNhdCA+PmNv
bmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgcmVzdHJpY3QgJGFjX2N2X2NfcmVzdHJpY3QKK19B
Q0VPRgorIDs7CisgZXNhYworCithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJzaXplX3Qi
ICJhY19jdl90eXBlX3NpemVfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRh
Y19jdl90eXBlX3NpemVfdCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorCitjYXQgPj5jb25mZGVm
cy5oIDw8X0FDRU9GCisjZGVmaW5lIHNpemVfdCB1bnNpZ25lZCBpbnQKK19BQ0VPRgorCitmaQor
CithY19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJzc2l6ZV90IiAiYWNfY3ZfdHlwZV9zc2l6
ZV90IiAiJGFjX2luY2x1ZGVzX2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X3R5cGVfc3NpemVf
dCIgPSB4eWVzOyB0aGVuIDoKKworZWxzZQorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIHNzaXplX3QgaW50CitfQUNFT0YKKworZmkKKworYWNfZm5fY19jaGVja19tZW1iZXIg
IiRMSU5FTk8iICJzdHJ1Y3Qgc3RhdCIgInN0X2Jsa3NpemUiICJhY19jdl9tZW1iZXJfc3RydWN0
X3N0YXRfc3RfYmxrc2l6ZSIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19j
dl9tZW1iZXJfc3RydWN0X3N0YXRfc3RfYmxrc2l6ZSIgPSB4eWVzOyB0aGVuIDoKKworY2F0ID4+
Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBIQVZFX1NUUlVDVF9TVEFUX1NUX0JMS1NJWkUg
MQorX0FDRU9GCisKKworZmkKKworYWNfZm5fY19jaGVja19tZW1iZXIgIiRMSU5FTk8iICJzdHJ1
Y3Qgc3RhdCIgInN0X2Jsb2NrcyIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9ibG9ja3Mi
ICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfbWVtYmVyX3N0cnVjdF9z
dGF0X3N0X2Jsb2NrcyIgPSB4eWVzOyB0aGVuIDoKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VP
RgorI2RlZmluZSBIQVZFX1NUUlVDVF9TVEFUX1NUX0JMT0NLUyAxCitfQUNFT0YKKworCiskYXNf
ZWNobyAiI2RlZmluZSBIQVZFX1NUX0JMT0NLUyAxIiA+PmNvbmZkZWZzLmgKKworZWxzZQorICBj
YXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBmaWxlYmxvY2tzLiRhY19vYmpleHQgIiogKSA7Owor
ICAqKSBMSUJPQkpTPSIkTElCT0JKUyBmaWxlYmxvY2tzLiRhY19vYmpleHQiCisgOzsKK2VzYWMK
KworZmkKKworCithY19mbl9jX2NoZWNrX21lbWJlciAiJExJTkVOTyIgInN0cnVjdCBzdGF0IiAi
c3RfcmRldiIgImFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9yZGV2IiAiJGFjX2luY2x1ZGVz
X2RlZmF1bHQiCitpZiB0ZXN0ICJ4JGFjX2N2X21lbWJlcl9zdHJ1Y3Rfc3RhdF9zdF9yZGV2IiA9
IHh5ZXM7IHRoZW4gOgorCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVf
U1RSVUNUX1NUQVRfU1RfUkRFViAxCitfQUNFT0YKKworCitmaQorCithY19mbl9jX2ZpbmRfdWlu
dFhfdCAiJExJTkVOTyIgIjE2IiAiYWNfY3ZfY191aW50MTZfdCIKK2Nhc2UgJGFjX2N2X2NfdWlu
dDE2X3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAorICAqKQorCisKK2NhdCA+PmNvbmZkZWZzLmgg
PDxfQUNFT0YKKyNkZWZpbmUgdWludDE2X3QgJGFjX2N2X2NfdWludDE2X3QKK19BQ0VPRgorOzsK
KyAgZXNhYworCithY19mbl9jX2ZpbmRfdWludFhfdCAiJExJTkVOTyIgIjMyIiAiYWNfY3ZfY191
aW50MzJfdCIKK2Nhc2UgJGFjX2N2X2NfdWludDMyX3QgaW4gIygKKyAgbm98eWVzKSA7OyAjKAor
ICAqKQorCiskYXNfZWNobyAiI2RlZmluZSBfVUlOVDMyX1QgMSIgPj5jb25mZGVmcy5oCisKKwor
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSB1aW50MzJfdCAkYWNfY3ZfY191aW50
MzJfdAorX0FDRU9GCis7OworICBlc2FjCisKK2FjX2ZuX2NfZmluZF91aW50WF90ICIkTElORU5P
IiAiNjQiICJhY19jdl9jX3VpbnQ2NF90IgorY2FzZSAkYWNfY3ZfY191aW50NjRfdCBpbiAjKAor
ICBub3x5ZXMpIDs7ICMoCisgICopCisKKyRhc19lY2hvICIjZGVmaW5lIF9VSU5UNjRfVCAxIiA+
PmNvbmZkZWZzLmgKKworCitjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIHVpbnQ2
NF90ICRhY19jdl9jX3VpbnQ2NF90CitfQUNFT0YKKzs7CisgIGVzYWMKKworYWNfZm5fY19maW5k
X3VpbnRYX3QgIiRMSU5FTk8iICI4IiAiYWNfY3ZfY191aW50OF90IgorY2FzZSAkYWNfY3ZfY191
aW50OF90IGluICMoCisgIG5vfHllcykgOzsgIygKKyAgKikKKworJGFzX2VjaG8gIiNkZWZpbmUg
X1VJTlQ4X1QgMSIgPj5jb25mZGVmcy5oCisKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSB1aW50OF90ICRhY19jdl9jX3VpbnQ4X3QKK19BQ0VPRgorOzsKKyAgZXNhYworCith
Y19mbl9jX2NoZWNrX3R5cGUgIiRMSU5FTk8iICJwdHJkaWZmX3QiICJhY19jdl90eXBlX3B0cmRp
ZmZfdCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVzdCAieCRhY19jdl90eXBlX3B0cmRp
ZmZfdCIgPSB4eWVzOyB0aGVuIDoKKworY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmlu
ZSBIQVZFX1BUUkRJRkZfVCAxCitfQUNFT0YKKworCitmaQorCisKKyMgQ2hlY2tzIGZvciBsaWJy
YXJ5IGZ1bmN0aW9ucy4KK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIGVycm9yX2F0X2xpbmUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9y
IGVycm9yX2F0X2xpbmUuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX2Vycm9yX2F0X2xpbmUr
On0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBj
YXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRl
ZnMuaC4gICovCisjaW5jbHVkZSA8ZXJyb3IuaD4KK2ludAorbWFpbiAoKQoreworZXJyb3JfYXRf
bGluZSAoMCwgMCwgIiIsIDAsICJhbiBlcnJvciBvY2N1cnJlZCIpOworICA7CisgIHJldHVybiAw
OworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFj
X2N2X2xpYl9lcnJvcl9hdF9saW5lPXllcworZWxzZQorICBhY19jdl9saWJfZXJyb3JfYXRfbGlu
ZT1ubworZmkKK3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAor
ICAgIGNvbmZ0ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CitmaQoreyAkYXNfZWNobyAi
JGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiByZXN1bHQ6ICRhY19jdl9saWJfZXJyb3JfYXRf
bGluZSIgPiY1CiskYXNfZWNobyAiJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lIiA+JjY7IH0KK2lm
IHRlc3QgJGFjX2N2X2xpYl9lcnJvcl9hdF9saW5lID0gbm87IHRoZW4KKyAgY2FzZSAiICRMSUJP
QkpTICIgaW4KKyAgKiIgZXJyb3IuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRM
SUJPQkpTIGVycm9yLiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworZmkKKworZm9yIGFjX2hlYWRl
ciBpbiB2Zm9yay5oCitkbyA6CisgIGFjX2ZuX2NfY2hlY2tfaGVhZGVyX21vbmdyZWwgIiRMSU5F
Tk8iICJ2Zm9yay5oIiAiYWNfY3ZfaGVhZGVyX3Zmb3JrX2giICIkYWNfaW5jbHVkZXNfZGVmYXVs
dCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3Zmb3JrX2giID0geHllczsgdGhlbiA6CisgIGNh
dCA+PmNvbmZkZWZzLmggPDxfQUNFT0YKKyNkZWZpbmUgSEFWRV9WRk9SS19IIDEKK19BQ0VPRgor
CitmaQorCitkb25lCisKK2ZvciBhY19mdW5jIGluIGZvcmsgdmZvcmsKK2RvIDoKKyAgYXNfYWNf
dmFyPWAkYXNfZWNobyAiYWNfY3ZfZnVuY18kYWNfZnVuYyIgfCAkYXNfdHJfc2hgCithY19mbl9j
X2NoZWNrX2Z1bmMgIiRMSU5FTk8iICIkYWNfZnVuYyIgIiRhc19hY192YXIiCitpZiBldmFsIHRl
c3QgXCJ4XCQiJGFzX2FjX3ZhciJcIiA9IHgieWVzIjsgdGhlbiA6CisgIGNhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKKyNkZWZpbmUgYCRhc19lY2hvICJIQVZFXyRhY19mdW5jIiB8ICRhc190cl9j
cHBgIDEKK19BQ0VPRgorCitmaQorZG9uZQorCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9yayIg
PSB4eWVzOyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgZm9yIHdvcmtpbmcgZm9yayIgPiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Ig
d29ya2luZyBmb3JrLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfZm9ya193b3Jrcys6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19mb3JrX3dv
cmtzPWNyb3NzCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRh
Y19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CitpbnQK
K21haW4gKCkKK3sKKworCSAgLyogQnkgUnVlZGlnZXIgS3VobG1hbm4uICovCisJICByZXR1cm4g
Zm9yayAoKSA8IDA7CisKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfZm9ya193b3Jrcz15ZXMKK2Vs
c2UKKyAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUgY29y
ZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBjb25m
dGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKworZmkK
K3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3Zf
ZnVuY19mb3JrX3dvcmtzIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA+
JjY7IH0KKworZWxzZQorICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9JGFjX2N2X2Z1bmNfZm9yawor
ZmkKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHhjcm9zczsgdGhlbgorICBj
YXNlICRob3N0IGluCisgICAgKi0qLWFtaWdhb3MqIHwgKi0qLW1zZG9zZGpncHAqKQorICAgICAg
IyBPdmVycmlkZSwgYXMgdGhlc2Ugc3lzdGVtcyBoYXZlIG9ubHkgYSBkdW1teSBmb3JrKCkgc3R1
YgorICAgICAgYWNfY3ZfZnVuY19mb3JrX3dvcmtzPW5vCisgICAgICA7OworICAgICopCisgICAg
ICBhY19jdl9mdW5jX2Zvcmtfd29ya3M9eWVzCisgICAgICA7OworICBlc2FjCisgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogcmVzdWx0ICRhY19jdl9m
dW5jX2Zvcmtfd29ya3MgZ3Vlc3NlZCBiZWNhdXNlIG9mIGNyb3NzIGNvbXBpbGF0aW9uIiA+JjUK
KyRhc19lY2hvICIkYXNfbWU6IFdBUk5JTkc6IHJlc3VsdCAkYWNfY3ZfZnVuY19mb3JrX3dvcmtz
IGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiYyO30KK2ZpCithY19jdl9m
dW5jX3Zmb3JrX3dvcmtzPSRhY19jdl9mdW5jX3Zmb3JrCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNf
dmZvcmsiID0geHllczsgdGhlbgorICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHZmb3JrIiA+JjUKKyRhc19lY2hvX24gImNoZWNr
aW5nIGZvciB3b3JraW5nIHZmb3JrLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfdmZvcmtf
d29ya3MrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxz
ZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3M9Y3Jvc3MKK2Vsc2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+
Y29uZnRlc3QuJGFjX2V4dAorLyogZW5kIGNvbmZkZWZzLmguICAqLworLyogVGhhbmtzIHRvIFBh
dWwgRWdnZXJ0IGZvciB0aGlzIHRlc3QuICAqLworJGFjX2luY2x1ZGVzX2RlZmF1bHQKKyNpbmNs
dWRlIDxzeXMvd2FpdC5oPgorI2lmZGVmIEhBVkVfVkZPUktfSAorIyBpbmNsdWRlIDx2Zm9yay5o
PgorI2VuZGlmCisvKiBPbiBzb21lIHNwYXJjIHN5c3RlbXMsIGNoYW5nZXMgYnkgdGhlIGNoaWxk
IHRvIGxvY2FsIGFuZCBpbmNvbWluZworICAgYXJndW1lbnQgcmVnaXN0ZXJzIGFyZSBwcm9wYWdh
dGVkIGJhY2sgdG8gdGhlIHBhcmVudC4gIFRoZSBjb21waWxlcgorICAgaXMgdG9sZCBhYm91dCB0
aGlzIHdpdGggI2luY2x1ZGUgPHZmb3JrLmg+LCBidXQgc29tZSBjb21waWxlcnMKKyAgIChlLmcu
IGdjYyAtTykgZG9uJ3QgZ3JvayA8dmZvcmsuaD4uICBUZXN0IGZvciB0aGlzIGJ5IHVzaW5nIGEK
KyAgIHN0YXRpYyB2YXJpYWJsZSB3aG9zZSBhZGRyZXNzIGlzIHB1dCBpbnRvIGEgcmVnaXN0ZXIg
dGhhdCBpcworICAgY2xvYmJlcmVkIGJ5IHRoZSB2Zm9yay4gICovCitzdGF0aWMgdm9pZAorI2lm
ZGVmIF9fY3BsdXNwbHVzCitzcGFyY19hZGRyZXNzX3Rlc3QgKGludCBhcmcpCisjIGVsc2UKK3Nw
YXJjX2FkZHJlc3NfdGVzdCAoYXJnKSBpbnQgYXJnOworI2VuZGlmCit7CisgIHN0YXRpYyBwaWRf
dCBjaGlsZDsKKyAgaWYgKCFjaGlsZCkgeworICAgIGNoaWxkID0gdmZvcmsgKCk7CisgICAgaWYg
KGNoaWxkIDwgMCkgeworICAgICAgcGVycm9yICgidmZvcmsiKTsKKyAgICAgIF9leGl0KDIpOwor
ICAgIH0KKyAgICBpZiAoIWNoaWxkKSB7CisgICAgICBhcmcgPSBnZXRwaWQoKTsKKyAgICAgIHdy
aXRlKC0xLCAiIiwgMCk7CisgICAgICBfZXhpdCAoYXJnKTsKKyAgICB9CisgIH0KK30KKworaW50
CittYWluICgpCit7CisgIHBpZF90IHBhcmVudCA9IGdldHBpZCAoKTsKKyAgcGlkX3QgY2hpbGQ7
CisKKyAgc3BhcmNfYWRkcmVzc190ZXN0ICgwKTsKKworICBjaGlsZCA9IHZmb3JrICgpOworCisg
IGlmIChjaGlsZCA9PSAwKSB7CisgICAgLyogSGVyZSBpcyBhbm90aGVyIHRlc3QgZm9yIHNwYXJj
IHZmb3JrIHJlZ2lzdGVyIHByb2JsZW1zLiAgVGhpcworICAgICAgIHRlc3QgdXNlcyBsb3RzIG9m
IGxvY2FsIHZhcmlhYmxlcywgYXQgbGVhc3QgYXMgbWFueSBsb2NhbAorICAgICAgIHZhcmlhYmxl
cyBhcyBtYWluIGhhcyBhbGxvY2F0ZWQgc28gZmFyIGluY2x1ZGluZyBjb21waWxlcgorICAgICAg
IHRlbXBvcmFyaWVzLiAgNCBsb2NhbHMgYXJlIGVub3VnaCBmb3IgZ2NjIDEuNDAuMyBvbiBhIFNv
bGFyaXMKKyAgICAgICA0LjEuMyBzcGFyYywgYnV0IHdlIHVzZSA4IHRvIGJlIHNhZmUuICBBIGJ1
Z2d5IGNvbXBpbGVyIHNob3VsZAorICAgICAgIHJldXNlIHRoZSByZWdpc3RlciBvZiBwYXJlbnQg
Zm9yIG9uZSBvZiB0aGUgbG9jYWwgdmFyaWFibGVzLAorICAgICAgIHNpbmNlIGl0IHdpbGwgdGhp
bmsgdGhhdCBwYXJlbnQgY2FuJ3QgcG9zc2libHkgYmUgdXNlZCBhbnkgbW9yZQorICAgICAgIGlu
IHRoaXMgcm91dGluZS4gIEFzc2lnbmluZyB0byB0aGUgbG9jYWwgdmFyaWFibGUgd2lsbCB0aHVz
CisgICAgICAgbXVuZ2UgcGFyZW50IGluIHRoZSBwYXJlbnQgcHJvY2Vzcy4gICovCisgICAgcGlk
X3QKKyAgICAgIHAgPSBnZXRwaWQoKSwgcDEgPSBnZXRwaWQoKSwgcDIgPSBnZXRwaWQoKSwgcDMg
PSBnZXRwaWQoKSwKKyAgICAgIHA0ID0gZ2V0cGlkKCksIHA1ID0gZ2V0cGlkKCksIHA2ID0gZ2V0
cGlkKCksIHA3ID0gZ2V0cGlkKCk7CisgICAgLyogQ29udmluY2UgdGhlIGNvbXBpbGVyIHRoYXQg
cC4ucDcgYXJlIGxpdmU7IG90aGVyd2lzZSwgaXQgbWlnaHQKKyAgICAgICB1c2UgdGhlIHNhbWUg
aGFyZHdhcmUgcmVnaXN0ZXIgZm9yIGFsbCA4IGxvY2FsIHZhcmlhYmxlcy4gICovCisgICAgaWYg
KHAgIT0gcDEgfHwgcCAhPSBwMiB8fCBwICE9IHAzIHx8IHAgIT0gcDQKKwl8fCBwICE9IHA1IHx8
IHAgIT0gcDYgfHwgcCAhPSBwNykKKyAgICAgIF9leGl0KDEpOworCisgICAgLyogT24gc29tZSBz
eXN0ZW1zIChlLmcuIElSSVggMy4zKSwgdmZvcmsgZG9lc24ndCBzZXBhcmF0ZSBwYXJlbnQKKyAg
ICAgICBmcm9tIGNoaWxkIGZpbGUgZGVzY3JpcHRvcnMuICBJZiB0aGUgY2hpbGQgY2xvc2VzIGEg
ZGVzY3JpcHRvcgorICAgICAgIGJlZm9yZSBpdCBleGVjcyBvciBleGl0cywgdGhpcyBtdW5nZXMg
dGhlIHBhcmVudCdzIGRlc2NyaXB0b3IKKyAgICAgICBhcyB3ZWxsLiAgVGVzdCBmb3IgdGhpcyBi
eSBjbG9zaW5nIHN0ZG91dCBpbiB0aGUgY2hpbGQuICAqLworICAgIF9leGl0KGNsb3NlKGZpbGVu
byhzdGRvdXQpKSAhPSAwKTsKKyAgfSBlbHNlIHsKKyAgICBpbnQgc3RhdHVzOworICAgIHN0cnVj
dCBzdGF0IHN0OworCisgICAgd2hpbGUgKHdhaXQoJnN0YXR1cykgIT0gY2hpbGQpCisgICAgICA7
CisgICAgcmV0dXJuICgKKwkgLyogV2FzIHRoZXJlIHNvbWUgcHJvYmxlbSB3aXRoIHZmb3JraW5n
PyAgKi8KKwkgY2hpbGQgPCAwCisKKwkgLyogRGlkIHRoZSBjaGlsZCBmYWlsPyAgKFRoaXMgc2hv
dWxkbid0IGhhcHBlbi4pICAqLworCSB8fCBzdGF0dXMKKworCSAvKiBEaWQgdGhlIHZmb3JrL2Nv
bXBpbGVyIGJ1ZyBvY2N1cj8gICovCisJIHx8IHBhcmVudCAhPSBnZXRwaWQoKQorCisJIC8qIERp
ZCB0aGUgZmlsZSBkZXNjcmlwdG9yIGJ1ZyBvY2N1cj8gICovCisJIHx8IGZzdGF0KGZpbGVubyhz
dGRvdXQpLCAmc3QpICE9IDAKKwkgKTsKKyAgfQorfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9y
dW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY192Zm9ya193b3Jrcz15ZXMKK2Vsc2UK
KyAgYWNfY3ZfZnVuY192Zm9ya193b3Jrcz1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUu
Y29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRl
c3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1
bmNfdmZvcmtfd29ya3MiID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX3Zmb3JrX3dvcmtzIiA+
JjY7IH0KKworZmk7CitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNfZm9ya193b3JrcyIgPSB4Y3Jvc3M7
IHRoZW4KKyAgYWNfY3ZfZnVuY192Zm9ya193b3Jrcz0kYWNfY3ZfZnVuY192Zm9yaworICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHJlc3VsdCAkYWNf
Y3ZfZnVuY192Zm9ya193b3JrcyBndWVzc2VkIGJlY2F1c2Ugb2YgY3Jvc3MgY29tcGlsYXRpb24i
ID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogcmVzdWx0ICRhY19jdl9mdW5jX3Zmb3Jr
X3dvcmtzIGd1ZXNzZWQgYmVjYXVzZSBvZiBjcm9zcyBjb21waWxhdGlvbiIgPiYyO30KK2ZpCisK
K2lmIHRlc3QgIngkYWNfY3ZfZnVuY192Zm9ya193b3JrcyIgPSB4eWVzOyB0aGVuCisKKyRhc19l
Y2hvICIjZGVmaW5lIEhBVkVfV09SS0lOR19WRk9SSyAxIiA+PmNvbmZkZWZzLmgKKworZWxzZQor
CiskYXNfZWNobyAiI2RlZmluZSB2Zm9yayBmb3JrIiA+PmNvbmZkZWZzLmgKKworZmkKK2lmIHRl
c3QgIngkYWNfY3ZfZnVuY19mb3JrX3dvcmtzIiA9IHh5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNk
ZWZpbmUgSEFWRV9XT1JLSU5HX0ZPUksgMSIgPj5jb25mZGVmcy5oCisKK2ZpCisKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIF9MQVJHRUZJTEVf
U09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMiID4mNQorJGFzX2VjaG9fbiAiY2hl
Y2tpbmcgZm9yIF9MQVJHRUZJTEVfU09VUkNFIHZhbHVlIG5lZWRlZCBmb3IgbGFyZ2UgZmlsZXMu
Li4gIiA+JjY7IH0KK2lmICR7YWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UrOn0gZmFsc2U7IHRo
ZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICB3aGlsZSA6OyBkbwor
ICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29u
ZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+IC8qIGZvciBvZmZfdCAqLworICAg
ICAjaW5jbHVkZSA8c3RkaW8uaD4KK2ludAorbWFpbiAoKQoreworaW50ICgqZnApIChGSUxFICos
IG9mZl90LCBpbnQpID0gZnNlZWtvOworICAgICByZXR1cm4gZnNlZWtvIChzdGRpbiwgMCwgMCkg
JiYgZnAgKHN0ZGluLCAwLCAwKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNf
Zm5fY190cnlfbGluayAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9zeXNfbGFyZ2VmaWxlX3Nv
dXJjZT1ubzsgYnJlYWsKK2ZpCitybSAtZiBjb3JlIGNvbmZ0ZXN0LmVyciBjb25mdGVzdC4kYWNf
b2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29uZnRlc3QuJGFjX2V4dAorICBjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMu
aC4gICovCisjZGVmaW5lIF9MQVJHRUZJTEVfU09VUkNFIDEKKyNpbmNsdWRlIDxzeXMvdHlwZXMu
aD4gLyogZm9yIG9mZl90ICovCisgICAgICNpbmNsdWRlIDxzdGRpby5oPgoraW50CittYWluICgp
Cit7CitpbnQgKCpmcCkgKEZJTEUgKiwgb2ZmX3QsIGludCkgPSBmc2Vla287CisgICAgIHJldHVy
biBmc2Vla28gKHN0ZGluLCAwLCAwKSAmJiBmcCAoc3RkaW4sIDAsIDApOworICA7CisgIHJldHVy
biAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3RyeV9saW5rICIkTElORU5PIjsgdGhlbiA6Cisg
IGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlPTE7IGJyZWFrCitmaQorcm0gLWYgY29yZSBjb25m
dGVzdC5lcnIgY29uZnRlc3QuJGFjX29iamV4dCBcCisgICAgY29uZnRlc3QkYWNfZXhlZXh0IGNv
bmZ0ZXN0LiRhY19leHQKKyAgYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2U9dW5rbm93bgorICBi
cmVhaworZG9uZQorZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3Zfc3lzX2xhcmdlZmlsZV9zb3VyY2UiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9zeXNfbGFyZ2VmaWxlX3NvdXJjZSIgPiY2OyB9CitjYXNlICRhY19jdl9zeXNfbGFyZ2VmaWxl
X3NvdXJjZSBpbiAjKAorICBubyB8IHVua25vd24pIDs7CisgICopCitjYXQgPj5jb25mZGVmcy5o
IDw8X0FDRU9GCisjZGVmaW5lIF9MQVJHRUZJTEVfU09VUkNFICRhY19jdl9zeXNfbGFyZ2VmaWxl
X3NvdXJjZQorX0FDRU9GCis7OworZXNhYworcm0gLXJmIGNvbmZ0ZXN0KgorCisjIFdlIHVzZWQg
dG8gdHJ5IGRlZmluaW5nIF9YT1BFTl9TT1VSQ0U9NTAwIHRvbywgdG8gd29yayBhcm91bmQgYSBi
dWcKKyMgaW4gZ2xpYmMgMi4xLjMsIGJ1dCB0aGF0IGJyZWFrcyB0b28gbWFueSBvdGhlciB0aGlu
Z3MuCisjIElmIHlvdSB3YW50IGZzZWVrbyBhbmQgZnRlbGxvIHdpdGggZ2xpYmMsIHVwZ3JhZGUg
dG8gYSBmaXhlZCBnbGliYy4KK2lmIHRlc3QgJGFjX2N2X3N5c19sYXJnZWZpbGVfc291cmNlICE9
IHVua25vd247IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9GU0VFS08gMSIgPj5jb25m
ZGVmcy5oCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
Y2hlY2tpbmcgd2hldGhlciBsc3RhdCBjb3JyZWN0bHkgaGFuZGxlcyB0cmFpbGluZyBzbGFzaCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyB3aGV0aGVyIGxzdGF0IGNvcnJlY3RseSBoYW5kbGVz
IHRyYWlsaW5nIHNsYXNoLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfbHN0YXRfZGVyZWZl
cmVuY2VzX3NsYXNoZWRfc3ltbGluays6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihj
YWNoZWQpICIgPiY2CitlbHNlCisgIHJtIC1mIGNvbmZ0ZXN0LnN5bSBjb25mdGVzdC5maWxlCitl
Y2hvID5jb25mdGVzdC5maWxlCitpZiB0ZXN0ICIkYXNfbG5fcyIgPSAibG4gLXMiICYmIGxuIC1z
IGNvbmZ0ZXN0LmZpbGUgY29uZnRlc3Quc3ltOyB0aGVuCisgIGlmIHRlc3QgIiRjcm9zc19jb21w
aWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xh
c2hlZF9zeW1saW5rPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0
ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0
CitpbnQKK21haW4gKCkKK3sKK3N0cnVjdCBzdGF0IHNidWY7CisgICAgIC8qIExpbnV4IHdpbGwg
ZGVyZWZlcmVuY2UgdGhlIHN5bWxpbmsgYW5kIGZhaWwsIGFzIHJlcXVpcmVkIGJ5IFBPU0lYLgor
CVRoYXQgaXMgYmV0dGVyIGluIHRoZSBzZW5zZSB0aGF0IGl0IG1lYW5zIHdlIHdpbGwgbm90CisJ
aGF2ZSB0byBjb21waWxlIGFuZCB1c2UgdGhlIGxzdGF0IHdyYXBwZXIuICAqLworICAgICByZXR1
cm4gbHN0YXQgKCJjb25mdGVzdC5zeW0vIiwgJnNidWYpID09IDA7CisgIDsKKyAgcmV0dXJuIDA7
Cit9CitfQUNFT0YKK2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19j
dl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVkX3N5bWxpbms9eWVzCitlbHNlCisgIGFj
X2N2X2Z1bmNfbHN0YXRfZGVyZWZlcmVuY2VzX3NsYXNoZWRfc3ltbGluaz1ubworZmkKK3JtIC1m
IGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNf
ZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRh
Y19leHQKK2ZpCisKK2Vsc2UKKyAgIyBJZiB0aGUgYGxuIC1zJyBjb21tYW5kIGZhaWxlZCwgdGhl
biB3ZSBwcm9iYWJseSBkb24ndCBldmVuCisgICMgaGF2ZSBhbiBsc3RhdCBmdW5jdGlvbi4KKyAg
YWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rPW5vCitmaQorcm0g
LWYgY29uZnRlc3Quc3ltIGNvbmZ0ZXN0LmZpbGUKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY19sc3RhdF9kZXJlZmVyZW5j
ZXNfc2xhc2hlZF9zeW1saW5rIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY19sc3RhdF9kZXJl
ZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rIiA+JjY7IH0KKwordGVzdCAkYWNfY3ZfZnVuY19sc3Rh
dF9kZXJlZmVyZW5jZXNfc2xhc2hlZF9zeW1saW5rID0geWVzICYmCisKK2NhdCA+PmNvbmZkZWZz
LmggPDxfQUNFT0YKKyNkZWZpbmUgTFNUQVRfRk9MTE9XU19TTEFTSEVEX1NZTUxJTksgMQorX0FD
RU9GCisKKworaWYgdGVzdCAieCRhY19jdl9mdW5jX2xzdGF0X2RlcmVmZXJlbmNlc19zbGFzaGVk
X3N5bWxpbmsiID0geG5vOyB0aGVuCisgIGNhc2UgIiAkTElCT0JKUyAiIGluCisgICoiIGxzdGF0
LiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIkTElCT0JKUyBsc3RhdC4kYWNfb2Jq
ZXh0IgorIDs7Citlc2FjCisKK2ZpCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0k
TElORU5PfTogY2hlY2tpbmcgd2hldGhlciBzeXMvdHlwZXMuaCBkZWZpbmVzIG1ha2VkZXYiID4m
NQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciBzeXMvdHlwZXMuaCBkZWZpbmVzIG1ha2Vk
ZXYuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYrOn0g
ZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBjYXQg
Y29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMu
aC4gICovCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CitpbnQKK21haW4gKCkKK3sKK3JldHVybiBt
YWtlZGV2KDAsIDApOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9saW5rICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9tYWtl
ZGV2PXllcworZWxzZQorICBhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldj1ubworZmkK
K3JtIC1mIGNvcmUgY29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgXAorICAgIGNvbmZ0
ZXN0JGFjX2V4ZWV4dCBjb25mdGVzdC4kYWNfZXh0CisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6
JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2hlYWRlcl9zeXNfdHlwZXNfaF9t
YWtlZGV2IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfaGVhZGVyX3N5c190eXBlc19oX21ha2VkZXYi
ID4mNjsgfQorCitpZiB0ZXN0ICRhY19jdl9oZWFkZXJfc3lzX3R5cGVzX2hfbWFrZWRldiA9IG5v
OyB0aGVuCithY19mbl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3lzL21rZGV2
LmgiICJhY19jdl9oZWFkZXJfc3lzX21rZGV2X2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lm
IHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N5c19ta2Rldl9oIiA9IHh5ZXM7IHRoZW4gOgorCiskYXNf
ZWNobyAiI2RlZmluZSBNQUpPUl9JTl9NS0RFViAxIiA+PmNvbmZkZWZzLmgKKworZmkKKworCisK
KyAgaWYgdGVzdCAkYWNfY3ZfaGVhZGVyX3N5c19ta2Rldl9oID0gbm87IHRoZW4KKyAgICBhY19m
bl9jX2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3lzL3N5c21hY3Jvcy5oIiAiYWNf
Y3ZfaGVhZGVyX3N5c19zeXNtYWNyb3NfaCIgIiRhY19pbmNsdWRlc19kZWZhdWx0IgoraWYgdGVz
dCAieCRhY19jdl9oZWFkZXJfc3lzX3N5c21hY3Jvc19oIiA9IHh5ZXM7IHRoZW4gOgorCiskYXNf
ZWNobyAiI2RlZmluZSBNQUpPUl9JTl9TWVNNQUNST1MgMSIgPj5jb25mZGVmcy5oCisKK2ZpCisK
KworICBmaQorZmkKKworZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAorZG8gOgorICBhY19mbl9j
X2NoZWNrX2hlYWRlcl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJf
c3RkbGliX2giICIkYWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVy
X3N0ZGxpYl9oIiA9IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisj
ZGVmaW5lIEhBVkVfU1RETElCX0ggMQorX0FDRU9GCisKK2ZpCisKK2RvbmUKKworeyAkYXNfZWNo
byAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgR05VIGxpYmMgY29t
cGF0aWJsZSBtYWxsb2MiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIEdOVSBsaWJjIGNv
bXBhdGlibGUgbWFsbG9jLi4uICIgPiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfbWFsbG9jXzBfbm9u
bnVsbCs6fSBmYWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNl
CisgIGlmIHRlc3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVu
Y19tYWxsb2NfMF9ub25udWxsPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0Yg
PmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKyNpZiBkZWZpbmVkIFNU
RENfSEVBREVSUyB8fCBkZWZpbmVkIEhBVkVfU1RETElCX0gKKyMgaW5jbHVkZSA8c3RkbGliLmg+
CisjZWxzZQorY2hhciAqbWFsbG9jICgpOworI2VuZGlmCisKK2ludAorbWFpbiAoKQoreworcmV0
dXJuICEgbWFsbG9jICgwKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5f
Y190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfbWFsbG9jXzBfbm9ubnVs
bD15ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsPW5vCitmaQorcm0gLWYg
Y29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19l
eGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFj
X2V4dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTog
cmVzdWx0OiAkYWNfY3ZfZnVuY19tYWxsb2NfMF9ub25udWxsIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfZnVuY19tYWxsb2NfMF9ub25udWxsIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfbWFs
bG9jXzBfbm9ubnVsbCA9IHllczsgdGhlbiA6CisKKyRhc19lY2hvICIjZGVmaW5lIEhBVkVfTUFM
TE9DIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisgICRhc19lY2hvICIjZGVmaW5lIEhBVkVfTUFM
TE9DIDAiID4+Y29uZmRlZnMuaAorCisgICBjYXNlICIgJExJQk9CSlMgIiBpbgorICAqIiBtYWxs
b2MuJGFjX29iamV4dCAiKiApIDs7CisgICopIExJQk9CSlM9IiRMSUJPQkpTIG1hbGxvYy4kYWNf
b2JqZXh0IgorIDs7Citlc2FjCisKKworJGFzX2VjaG8gIiNkZWZpbmUgbWFsbG9jIHJwbF9tYWxs
b2MiID4+Y29uZmRlZnMuaAorCitmaQorCisKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVu
by0kTElORU5PfTogY2hlY2tpbmcgd2hldGhlciB0aW1lLmggYW5kIHN5cy90aW1lLmggbWF5IGJv
dGggYmUgaW5jbHVkZWQiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgd2hldGhlciB0aW1lLmgg
YW5kIHN5cy90aW1lLmggbWF5IGJvdGggYmUgaW5jbHVkZWQuLi4gIiA+JjY7IH0KK2lmICR7YWNf
Y3ZfaGVhZGVyX3RpbWUrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIoY2FjaGVkKSAi
ID4mNgorZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0
CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVk
ZSA8c3lzL3RpbWUuaD4KKyNpbmNsdWRlIDx0aW1lLmg+CisKK2ludAorbWFpbiAoKQoreworaWYg
KChzdHJ1Y3QgdG0gKikgMCkKK3JldHVybiAwOworICA7CisgIHJldHVybiAwOworfQorX0FDRU9G
CitpZiBhY19mbl9jX3RyeV9jb21waWxlICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2hlYWRl
cl90aW1lPXllcworZWxzZQorICBhY19jdl9oZWFkZXJfdGltZT1ubworZmkKK3JtIC1mIGNvcmUg
Y29uZnRlc3QuZXJyIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuJGFjX2V4dAorZmkKK3sg
JGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfaGVh
ZGVyX3RpbWUiID4mNQorJGFzX2VjaG8gIiRhY19jdl9oZWFkZXJfdGltZSIgPiY2OyB9CitpZiB0
ZXN0ICRhY19jdl9oZWFkZXJfdGltZSA9IHllczsgdGhlbgorCiskYXNfZWNobyAiI2RlZmluZSBU
SU1FX1dJVEhfU1lTX1RJTUUgMSIgPj5jb25mZGVmcy5oCisKK2ZpCisKKworCisKKyAgZm9yIGFj
X2hlYWRlciBpbiAkYWNfaGVhZGVyX2xpc3QKK2RvIDoKKyAgYXNfYWNfSGVhZGVyPWAkYXNfZWNo
byAiYWNfY3ZfaGVhZGVyXyRhY19oZWFkZXIiIHwgJGFzX3RyX3NoYAorYWNfZm5fY19jaGVja19o
ZWFkZXJfY29tcGlsZSAiJExJTkVOTyIgIiRhY19oZWFkZXIiICIkYXNfYWNfSGVhZGVyIiAiJGFj
X2luY2x1ZGVzX2RlZmF1bHQKKyIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfSGVhZGVyIlwi
ID0geCJ5ZXMiOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBg
JGFzX2VjaG8gIkhBVkVfJGFjX2hlYWRlciIgfCAkYXNfdHJfY3BwYCAxCitfQUNFT0YKKworZmkK
KworZG9uZQorCisKKworCisKKworCisKKyAgZm9yIGFjX2Z1bmMgaW4gJGFjX2Z1bmNfbGlzdAor
ZG8gOgorICBhc19hY192YXI9YCRhc19lY2hvICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190
cl9zaGAKK2FjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3Zh
ciIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNfYWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKKyAg
Y2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2Z1
bmMiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9GCisKK2ZpCitkb25lCisKKworCisKKworeyAkYXNf
ZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3Igd29ya2luZyBt
a3RpbWUiID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbWt0aW1lLi4uICIg
PiY2OyB9CitpZiAke2FjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUrOn0gZmFsc2U7IHRoZW4gOgor
ICAkYXNfZWNob19uICIoY2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29t
cGlsaW5nIiA9IHllczsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWU9bm8KK2Vs
c2UKKyAgY2F0IGNvbmZkZWZzLmggLSA8PF9BQ0VPRiA+Y29uZnRlc3QuJGFjX2V4dAorLyogZW5k
IGNvbmZkZWZzLmguICAqLworLyogVGVzdCBwcm9ncmFtIGZyb20gUGF1bCBFZ2dlcnQgYW5kIFRv
bnkgTGVuZWlzLiAgKi8KKyNpZmRlZiBUSU1FX1dJVEhfU1lTX1RJTUUKKyMgaW5jbHVkZSA8c3lz
L3RpbWUuaD4KKyMgaW5jbHVkZSA8dGltZS5oPgorI2Vsc2UKKyMgaWZkZWYgSEFWRV9TWVNfVElN
RV9ICisjICBpbmNsdWRlIDxzeXMvdGltZS5oPgorIyBlbHNlCisjICBpbmNsdWRlIDx0aW1lLmg+
CisjIGVuZGlmCisjZW5kaWYKKworI2luY2x1ZGUgPGxpbWl0cy5oPgorI2luY2x1ZGUgPHN0ZGxp
Yi5oPgorCisjaWZkZWYgSEFWRV9VTklTVERfSAorIyBpbmNsdWRlIDx1bmlzdGQuaD4KKyNlbmRp
ZgorCisjaWZuZGVmIEhBVkVfQUxBUk0KKyMgZGVmaW5lIGFsYXJtKFgpIC8qIGVtcHR5ICovCisj
ZW5kaWYKKworLyogV29yayBhcm91bmQgcmVkZWZpbml0aW9uIHRvIHJwbF9wdXRlbnYgYnkgb3Ro
ZXIgY29uZmlnIHRlc3RzLiAgKi8KKyN1bmRlZiBwdXRlbnYKKworc3RhdGljIHRpbWVfdCB0aW1l
X3RfbWF4Oworc3RhdGljIHRpbWVfdCB0aW1lX3RfbWluOworCisvKiBWYWx1ZXMgd2UnbGwgdXNl
IHRvIHNldCB0aGUgVFogZW52aXJvbm1lbnQgdmFyaWFibGUuICAqLworc3RhdGljIGNvbnN0IGNo
YXIgKnR6X3N0cmluZ3NbXSA9IHsKKyAgKGNvbnN0IGNoYXIgKikgMCwgIlRaPUdNVDAiLCAiVFo9
SlNULTkiLAorICAiVFo9RVNUKzNFRFQrMixNMTAuMS4wLzAwOjAwOjAwLE0yLjMuMC8wMDowMDow
MCIKK307CisjZGVmaW5lIE5fU1RSSU5HUyAoc2l6ZW9mICh0el9zdHJpbmdzKSAvIHNpemVvZiAo
dHpfc3RyaW5nc1swXSkpCisKKy8qIFJldHVybiAwIGlmIG1rdGltZSBmYWlscyB0byBjb252ZXJ0
IGEgZGF0ZSBpbiB0aGUgc3ByaW5nLWZvcndhcmQgZ2FwLgorICAgQmFzZWQgb24gYSBwcm9ibGVt
IHJlcG9ydCBmcm9tIEFuZHJlYXMgSmFlZ2VyLiAgKi8KK3N0YXRpYyBpbnQKK3NwcmluZ19mb3J3
YXJkX2dhcCAoKQoreworICAvKiBnbGliYyAodXAgdG8gYWJvdXQgMTk5OC0xMC0wNykgZmFpbGVk
IHRoaXMgdGVzdC4gKi8KKyAgc3RydWN0IHRtIHRtOworCisgIC8qIFVzZSB0aGUgcG9ydGFibGUg
UE9TSVguMSBzcGVjaWZpY2F0aW9uICJUWj1QU1Q4UERULE00LjEuMCxNMTAuNS4wIgorICAgICBp
bnN0ZWFkIG9mICJUWj1BbWVyaWNhL1ZhbmNvdXZlciIgaW4gb3JkZXIgdG8gZGV0ZWN0IHRoZSBi
dWcgZXZlbgorICAgICBvbiBzeXN0ZW1zIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgT2xzb24gZXh0
ZW5zaW9uLCBvciBkb24ndCBoYXZlIHRoZQorICAgICBmdWxsIHpvbmVpbmZvIHRhYmxlcyBpbnN0
YWxsZWQuICAqLworICBwdXRlbnYgKChjaGFyKikgIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41LjAi
KTsKKworICB0bS50bV95ZWFyID0gOTg7CisgIHRtLnRtX21vbiA9IDM7CisgIHRtLnRtX21kYXkg
PSA1OworICB0bS50bV9ob3VyID0gMjsKKyAgdG0udG1fbWluID0gMDsKKyAgdG0udG1fc2VjID0g
MDsKKyAgdG0udG1faXNkc3QgPSAtMTsKKyAgcmV0dXJuIG1rdGltZSAoJnRtKSAhPSAodGltZV90
KSAtMTsKK30KKworc3RhdGljIGludAorbWt0aW1lX3Rlc3QxICh0aW1lX3Qgbm93KQoreworICBz
dHJ1Y3QgdG0gKmx0OworICByZXR1cm4gISAobHQgPSBsb2NhbHRpbWUgKCZub3cpKSB8fCBta3Rp
bWUgKGx0KSA9PSBub3c7Cit9CisKK3N0YXRpYyBpbnQKK21rdGltZV90ZXN0ICh0aW1lX3Qgbm93
KQoreworICByZXR1cm4gKG1rdGltZV90ZXN0MSAobm93KQorCSAgJiYgbWt0aW1lX3Rlc3QxICgo
dGltZV90KSAodGltZV90X21heCAtIG5vdykpCisJICAmJiBta3RpbWVfdGVzdDEgKCh0aW1lX3Qp
ICh0aW1lX3RfbWluICsgbm93KSkpOworfQorCitzdGF0aWMgaW50Citpcml4XzZfNF9idWcgKCkK
K3sKKyAgLyogQmFzZWQgb24gY29kZSBmcm9tIEFyaWVsIEZhaWdvbi4gICovCisgIHN0cnVjdCB0
bSB0bTsKKyAgdG0udG1feWVhciA9IDk2OworICB0bS50bV9tb24gPSAzOworICB0bS50bV9tZGF5
ID0gMDsKKyAgdG0udG1faG91ciA9IDA7CisgIHRtLnRtX21pbiA9IDA7CisgIHRtLnRtX3NlYyA9
IDA7CisgIHRtLnRtX2lzZHN0ID0gLTE7CisgIG1rdGltZSAoJnRtKTsKKyAgcmV0dXJuIHRtLnRt
X21vbiA9PSAyICYmIHRtLnRtX21kYXkgPT0gMzE7Cit9CisKK3N0YXRpYyBpbnQKK2JpZ3RpbWVf
dGVzdCAoaW50IGopCit7CisgIHN0cnVjdCB0bSB0bTsKKyAgdGltZV90IG5vdzsKKyAgdG0udG1f
eWVhciA9IHRtLnRtX21vbiA9IHRtLnRtX21kYXkgPSB0bS50bV9ob3VyID0gdG0udG1fbWluID0g
dG0udG1fc2VjID0gajsKKyAgbm93ID0gbWt0aW1lICgmdG0pOworICBpZiAobm93ICE9ICh0aW1l
X3QpIC0xKQorICAgIHsKKyAgICAgIHN0cnVjdCB0bSAqbHQgPSBsb2NhbHRpbWUgKCZub3cpOwor
ICAgICAgaWYgKCEgKGx0CisJICAgICAmJiBsdC0+dG1feWVhciA9PSB0bS50bV95ZWFyCisJICAg
ICAmJiBsdC0+dG1fbW9uID09IHRtLnRtX21vbgorCSAgICAgJiYgbHQtPnRtX21kYXkgPT0gdG0u
dG1fbWRheQorCSAgICAgJiYgbHQtPnRtX2hvdXIgPT0gdG0udG1faG91cgorCSAgICAgJiYgbHQt
PnRtX21pbiA9PSB0bS50bV9taW4KKwkgICAgICYmIGx0LT50bV9zZWMgPT0gdG0udG1fc2VjCisJ
ICAgICAmJiBsdC0+dG1feWRheSA9PSB0bS50bV95ZGF5CisJICAgICAmJiBsdC0+dG1fd2RheSA9
PSB0bS50bV93ZGF5CisJICAgICAmJiAoKGx0LT50bV9pc2RzdCA8IDAgPyAtMSA6IDAgPCBsdC0+
dG1faXNkc3QpCisJCSAgPT0gKHRtLnRtX2lzZHN0IDwgMCA/IC0xIDogMCA8IHRtLnRtX2lzZHN0
KSkpKQorCXJldHVybiAwOworICAgIH0KKyAgcmV0dXJuIDE7Cit9CisKK3N0YXRpYyBpbnQKK3ll
YXJfMjA1MF90ZXN0ICgpCit7CisgIC8qIFRoZSBjb3JyZWN0IGFuc3dlciBmb3IgMjA1MC0wMi0w
MSAwMDowMDowMCBpbiBQYWNpZmljIHRpbWUsCisgICAgIGlnbm9yaW5nIGxlYXAgc2Vjb25kcy4g
ICovCisgIHVuc2lnbmVkIGxvbmcgaW50IGFuc3dlciA9IDI1MjczMTUyMDBVTDsKKworICBzdHJ1
Y3QgdG0gdG07CisgIHRpbWVfdCB0OworICB0bS50bV95ZWFyID0gMjA1MCAtIDE5MDA7CisgIHRt
LnRtX21vbiA9IDIgLSAxOworICB0bS50bV9tZGF5ID0gMTsKKyAgdG0udG1faG91ciA9IHRtLnRt
X21pbiA9IHRtLnRtX3NlYyA9IDA7CisgIHRtLnRtX2lzZHN0ID0gLTE7CisKKyAgLyogVXNlIHRo
ZSBwb3J0YWJsZSBQT1NJWC4xIHNwZWNpZmljYXRpb24gIlRaPVBTVDhQRFQsTTQuMS4wLE0xMC41
LjAiCisgICAgIGluc3RlYWQgb2YgIlRaPUFtZXJpY2EvVmFuY291dmVyIiBpbiBvcmRlciB0byBk
ZXRlY3QgdGhlIGJ1ZyBldmVuCisgICAgIG9uIHN5c3RlbXMgdGhhdCBkb24ndCBzdXBwb3J0IHRo
ZSBPbHNvbiBleHRlbnNpb24sIG9yIGRvbid0IGhhdmUgdGhlCisgICAgIGZ1bGwgem9uZWluZm8g
dGFibGVzIGluc3RhbGxlZC4gICovCisgIHB1dGVudiAoKGNoYXIqKSAiVFo9UFNUOFBEVCxNNC4x
LjAsTTEwLjUuMCIpOworCisgIHQgPSBta3RpbWUgKCZ0bSk7CisKKyAgLyogQ2hlY2sgdGhhdCB0
aGUgcmVzdWx0IGlzIGVpdGhlciBhIGZhaWx1cmUsIG9yIGNsb3NlIGVub3VnaAorICAgICB0byB0
aGUgY29ycmVjdCBhbnN3ZXIgdGhhdCB3ZSBjYW4gYXNzdW1lIHRoZSBkaXNjcmVwYW5jeSBpcwor
ICAgICBkdWUgdG8gbGVhcCBzZWNvbmRzLiAgKi8KKyAgcmV0dXJuICh0ID09ICh0aW1lX3QpIC0x
CisJICB8fCAoMCA8IHQgJiYgYW5zd2VyIC0gMTIwIDw9IHQgJiYgdCA8PSBhbnN3ZXIgKyAxMjAp
KTsKK30KKworaW50CittYWluICgpCit7CisgIHRpbWVfdCB0LCBkZWx0YTsKKyAgaW50IGksIGo7
CisKKyAgLyogVGhpcyB0ZXN0IG1ha2VzIHNvbWUgYnVnZ3kgbWt0aW1lIGltcGxlbWVudGF0aW9u
cyBsb29wLgorICAgICBHaXZlIHVwIGFmdGVyIDYwIHNlY29uZHM7IGEgbWt0aW1lIHNsb3dlciB0
aGFuIHRoYXQKKyAgICAgaXNuJ3Qgd29ydGggdXNpbmcgYW55d2F5LiAgKi8KKyAgYWxhcm0gKDYw
KTsKKworICBmb3IgKDs7KQorICAgIHsKKyAgICAgIHQgPSAodGltZV90X21heCA8PCAxKSArIDE7
CisgICAgICBpZiAodCA8PSB0aW1lX3RfbWF4KQorCWJyZWFrOworICAgICAgdGltZV90X21heCA9
IHQ7CisgICAgfQorICB0aW1lX3RfbWluID0gLSAoKHRpbWVfdCkgfiAodGltZV90KSAwID09ICh0
aW1lX3QpIC0xKSAtIHRpbWVfdF9tYXg7CisKKyAgZGVsdGEgPSB0aW1lX3RfbWF4IC8gOTk3OyAv
KiBhIHN1aXRhYmxlIHByaW1lIG51bWJlciAqLworICBmb3IgKGkgPSAwOyBpIDwgTl9TVFJJTkdT
OyBpKyspCisgICAgeworICAgICAgaWYgKHR6X3N0cmluZ3NbaV0pCisJcHV0ZW52ICgoY2hhciop
IHR6X3N0cmluZ3NbaV0pOworCisgICAgICBmb3IgKHQgPSAwOyB0IDw9IHRpbWVfdF9tYXggLSBk
ZWx0YTsgdCArPSBkZWx0YSkKKwlpZiAoISBta3RpbWVfdGVzdCAodCkpCisJICByZXR1cm4gMTsK
KyAgICAgIGlmICghIChta3RpbWVfdGVzdCAoKHRpbWVfdCkgMSkKKwkgICAgICYmIG1rdGltZV90
ZXN0ICgodGltZV90KSAoNjAgKiA2MCkpCisJICAgICAmJiBta3RpbWVfdGVzdCAoKHRpbWVfdCkg
KDYwICogNjAgKiAyNCkpKSkKKwlyZXR1cm4gMTsKKworICAgICAgZm9yIChqID0gMTsgOyBqIDw8
PSAxKQorCWlmICghIGJpZ3RpbWVfdGVzdCAoaikpCisJICByZXR1cm4gMTsKKwllbHNlIGlmIChJ
TlRfTUFYIC8gMiA8IGopCisJICBicmVhazsKKyAgICAgIGlmICghIGJpZ3RpbWVfdGVzdCAoSU5U
X01BWCkpCisJcmV0dXJuIDE7CisgICAgfQorICByZXR1cm4gISAoaXJpeF82XzRfYnVnICgpICYm
IHNwcmluZ19mb3J3YXJkX2dhcCAoKSAmJiB5ZWFyXzIwNTBfdGVzdCAoKSk7Cit9CitfQUNFT0YK
K2lmIGFjX2ZuX2NfdHJ5X3J1biAiJExJTkVOTyI7IHRoZW4gOgorICBhY19jdl9mdW5jX3dvcmtp
bmdfbWt0aW1lPXllcworZWxzZQorICBhY19jdl9mdW5jX3dvcmtpbmdfbWt0aW1lPW5vCitmaQor
cm0gLWYgY29yZSAqLmNvcmUgY29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVz
dCRhY19leGVleHQgXAorICBjb25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRl
c3QuJGFjX2V4dAorZmkKKworZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElO
RU5PfTogcmVzdWx0OiAkYWNfY3ZfZnVuY193b3JraW5nX21rdGltZSIgPiY1CiskYXNfZWNobyAi
JGFjX2N2X2Z1bmNfd29ya2luZ19ta3RpbWUiID4mNjsgfQoraWYgdGVzdCAkYWNfY3ZfZnVuY193
b3JraW5nX21rdGltZSA9IG5vOyB0aGVuCisgIGNhc2UgIiAkTElCT0JKUyAiIGluCisgICoiIG1r
dGltZS4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgbWt0aW1lLiRh
Y19vYmpleHQiCisgOzsKK2VzYWMKKworZmkKKworCisKKworCisKK2ZvciBhY19mdW5jIGluIGdl
dHBhZ2VzaXplCitkbyA6CisgIGFjX2ZuX2NfY2hlY2tfZnVuYyAiJExJTkVOTyIgImdldHBhZ2Vz
aXplIiAiYWNfY3ZfZnVuY19nZXRwYWdlc2l6ZSIKK2lmIHRlc3QgIngkYWNfY3ZfZnVuY19nZXRw
YWdlc2l6ZSIgPSB4eWVzOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgorI2Rl
ZmluZSBIQVZFX0dFVFBBR0VTSVpFIDEKK19BQ0VPRgorCitmaQorZG9uZQorCit7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIG1tYXAi
ID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHdvcmtpbmcgbW1hcC4uLiAiID4mNjsgfQor
aWYgJHthY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFz
X2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGlu
ZyIgPSB5ZXM7IHRoZW4gOgorICBhY19jdl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkPW5vCitlbHNl
CisgIGNhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBj
b25mZGVmcy5oLiAgKi8KKyRhY19pbmNsdWRlc19kZWZhdWx0CisvKiBtYWxsb2MgbWlnaHQgaGF2
ZSBiZWVuIHJlbmFtZWQgYXMgcnBsX21hbGxvYy4gKi8KKyN1bmRlZiBtYWxsb2MKKworLyogVGhh
bmtzIHRvIE1pa2UgSGFlcnRlbCBhbmQgSmltIEF2ZXJhIGZvciB0aGlzIHRlc3QuCisgICBIZXJl
IGlzIGEgbWF0cml4IG9mIG1tYXAgcG9zc2liaWxpdGllczoKKwltbWFwIHByaXZhdGUgbm90IGZp
eGVkCisJbW1hcCBwcml2YXRlIGZpeGVkIGF0IHNvbWV3aGVyZSBjdXJyZW50bHkgdW5tYXBwZWQK
KwltbWFwIHByaXZhdGUgZml4ZWQgYXQgc29tZXdoZXJlIGFscmVhZHkgbWFwcGVkCisJbW1hcCBz
aGFyZWQgbm90IGZpeGVkCisJbW1hcCBzaGFyZWQgZml4ZWQgYXQgc29tZXdoZXJlIGN1cnJlbnRs
eSB1bm1hcHBlZAorCW1tYXAgc2hhcmVkIGZpeGVkIGF0IHNvbWV3aGVyZSBhbHJlYWR5IG1hcHBl
ZAorICAgRm9yIHByaXZhdGUgbWFwcGluZ3MsIHdlIHNob3VsZCB2ZXJpZnkgdGhhdCBjaGFuZ2Vz
IGNhbm5vdCBiZSByZWFkKCkKKyAgIGJhY2sgZnJvbSB0aGUgZmlsZSwgbm9yIG1tYXAncyBiYWNr
IGZyb20gdGhlIGZpbGUgYXQgYSBkaWZmZXJlbnQKKyAgIGFkZHJlc3MuICAoVGhlcmUgaGF2ZSBi
ZWVuIHN5c3RlbXMgd2hlcmUgcHJpdmF0ZSB3YXMgbm90IGNvcnJlY3RseQorICAgaW1wbGVtZW50
ZWQgbGlrZSB0aGUgaW5mYW1vdXMgaTM4NiBzdnI0LjAsIGFuZCBzeXN0ZW1zIHdoZXJlIHRoZQor
ICAgVk0gcGFnZSBjYWNoZSB3YXMgbm90IGNvaGVyZW50IHdpdGggdGhlIGZpbGUgc3lzdGVtIGJ1
ZmZlciBjYWNoZQorICAgbGlrZSBlYXJseSB2ZXJzaW9ucyBvZiBGcmVlQlNEIGFuZCBwb3NzaWJs
eSBjb250ZW1wb3JhcnkgTmV0QlNELikKKyAgIEZvciBzaGFyZWQgbWFwcGluZ3MsIHdlIHNob3Vs
ZCBjb252ZXJzZWx5IHZlcmlmeSB0aGF0IGNoYW5nZXMgZ2V0CisgICBwcm9wYWdhdGVkIGJhY2sg
dG8gYWxsIHRoZSBwbGFjZXMgdGhleSdyZSBzdXBwb3NlZCB0byBiZS4KKworICAgR3JlcCB3YW50
cyBwcml2YXRlIGZpeGVkIGFscmVhZHkgbWFwcGVkLgorICAgVGhlIG1haW4gdGhpbmdzIGdyZXAg
bmVlZHMgdG8ga25vdyBhYm91dCBtbWFwIGFyZToKKyAgICogZG9lcyBpdCBleGlzdCBhbmQgaXMg
aXQgc2FmZSB0byB3cml0ZSBpbnRvIHRoZSBtbWFwJ2QgYXJlYQorICAgKiBob3cgdG8gdXNlIGl0
IChCU0QgdmFyaWFudHMpICAqLworCisjaW5jbHVkZSA8ZmNudGwuaD4KKyNpbmNsdWRlIDxzeXMv
bW1hbi5oPgorCisjaWYgIWRlZmluZWQgU1REQ19IRUFERVJTICYmICFkZWZpbmVkIEhBVkVfU1RE
TElCX0gKK2NoYXIgKm1hbGxvYyAoKTsKKyNlbmRpZgorCisvKiBUaGlzIG1lc3Mgd2FzIGNvcGll
ZCBmcm9tIHRoZSBHTlUgZ2V0cGFnZXNpemUuaC4gICovCisjaWZuZGVmIEhBVkVfR0VUUEFHRVNJ
WkUKKyMgaWZkZWYgX1NDX1BBR0VTSVpFCisjICBkZWZpbmUgZ2V0cGFnZXNpemUoKSBzeXNjb25m
KF9TQ19QQUdFU0laRSkKKyMgZWxzZSAvKiBubyBfU0NfUEFHRVNJWkUgKi8KKyMgIGlmZGVmIEhB
VkVfU1lTX1BBUkFNX0gKKyMgICBpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyMgICBpZmRlZiBFWEVD
X1BBR0VTSVpFCisjICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIEVYRUNfUEFHRVNJWkUKKyMgICBl
bHNlIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KKyMgICAgaWZkZWYgTkJQRworIyAgICAgZGVmaW5l
IGdldHBhZ2VzaXplKCkgTkJQRyAqIENMU0laRQorIyAgICAgaWZuZGVmIENMU0laRQorIyAgICAg
IGRlZmluZSBDTFNJWkUgMQorIyAgICAgZW5kaWYgLyogbm8gQ0xTSVpFICovCisjICAgIGVsc2Ug
Lyogbm8gTkJQRyAqLworIyAgICAgaWZkZWYgTkJQQworIyAgICAgIGRlZmluZSBnZXRwYWdlc2l6
ZSgpIE5CUEMKKyMgICAgIGVsc2UgLyogbm8gTkJQQyAqLworIyAgICAgIGlmZGVmIFBBR0VTSVpF
CisjICAgICAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIFBBR0VTSVpFCisjICAgICAgZW5kaWYgLyog
UEFHRVNJWkUgKi8KKyMgICAgIGVuZGlmIC8qIG5vIE5CUEMgKi8KKyMgICAgZW5kaWYgLyogbm8g
TkJQRyAqLworIyAgIGVuZGlmIC8qIG5vIEVYRUNfUEFHRVNJWkUgKi8KKyMgIGVsc2UgLyogbm8g
SEFWRV9TWVNfUEFSQU1fSCAqLworIyAgIGRlZmluZSBnZXRwYWdlc2l6ZSgpIDgxOTIJLyogcHVu
dCB0b3RhbGx5ICovCisjICBlbmRpZiAvKiBubyBIQVZFX1NZU19QQVJBTV9IICovCisjIGVuZGlm
IC8qIG5vIF9TQ19QQUdFU0laRSAqLworCisjZW5kaWYgLyogbm8gSEFWRV9HRVRQQUdFU0laRSAq
LworCitpbnQKK21haW4gKCkKK3sKKyAgY2hhciAqZGF0YSwgKmRhdGEyLCAqZGF0YTM7CisgIGNv
bnN0IGNoYXIgKmNkYXRhMjsKKyAgaW50IGksIHBhZ2VzaXplOworICBpbnQgZmQsIGZkMjsKKwor
ICBwYWdlc2l6ZSA9IGdldHBhZ2VzaXplICgpOworCisgIC8qIEZpcnN0LCBtYWtlIGEgZmlsZSB3
aXRoIHNvbWUga25vd24gZ2FyYmFnZSBpbiBpdC4gKi8KKyAgZGF0YSA9IChjaGFyICopIG1hbGxv
YyAocGFnZXNpemUpOworICBpZiAoIWRhdGEpCisgICAgcmV0dXJuIDE7CisgIGZvciAoaSA9IDA7
IGkgPCBwYWdlc2l6ZTsgKytpKQorICAgICooZGF0YSArIGkpID0gcmFuZCAoKTsKKyAgdW1hc2sg
KDApOworICBmZCA9IGNyZWF0ICgiY29uZnRlc3QubW1hcCIsIDA2MDApOworICBpZiAoZmQgPCAw
KQorICAgIHJldHVybiAyOworICBpZiAod3JpdGUgKGZkLCBkYXRhLCBwYWdlc2l6ZSkgIT0gcGFn
ZXNpemUpCisgICAgcmV0dXJuIDM7CisgIGNsb3NlIChmZCk7CisKKyAgLyogTmV4dCwgY2hlY2sg
dGhhdCB0aGUgdGFpbCBvZiBhIHBhZ2UgaXMgemVyby1maWxsZWQuICBGaWxlIG11c3QgaGF2ZQor
ICAgICBub24temVybyBsZW5ndGgsIG90aGVyd2lzZSB3ZSByaXNrIFNJR0JVUyBmb3IgZW50aXJl
IHBhZ2UuICAqLworICBmZDIgPSBvcGVuICgiY29uZnRlc3QudHh0IiwgT19SRFdSIHwgT19DUkVB
VCB8IE9fVFJVTkMsIDA2MDApOworICBpZiAoZmQyIDwgMCkKKyAgICByZXR1cm4gNDsKKyAgY2Rh
dGEyID0gIiI7CisgIGlmICh3cml0ZSAoZmQyLCBjZGF0YTIsIDEpICE9IDEpCisgICAgcmV0dXJu
IDU7CisgIGRhdGEyID0gKGNoYXIgKikgbW1hcCAoMCwgcGFnZXNpemUsIFBST1RfUkVBRCB8IFBS
T1RfV1JJVEUsIE1BUF9TSEFSRUQsIGZkMiwgMEwpOworICBpZiAoZGF0YTIgPT0gTUFQX0ZBSUxF
RCkKKyAgICByZXR1cm4gNjsKKyAgZm9yIChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCisgICAg
aWYgKCooZGF0YTIgKyBpKSkKKyAgICAgIHJldHVybiA3OworICBjbG9zZSAoZmQyKTsKKyAgaWYg
KG11bm1hcCAoZGF0YTIsIHBhZ2VzaXplKSkKKyAgICByZXR1cm4gODsKKworICAvKiBOZXh0LCB0
cnkgdG8gbW1hcCB0aGUgZmlsZSBhdCBhIGZpeGVkIGFkZHJlc3Mgd2hpY2ggYWxyZWFkeSBoYXMK
KyAgICAgc29tZXRoaW5nIGVsc2UgYWxsb2NhdGVkIGF0IGl0LiAgSWYgd2UgY2FuLCBhbHNvIG1h
a2Ugc3VyZSB0aGF0CisgICAgIHdlIHNlZSB0aGUgc2FtZSBnYXJiYWdlLiAgKi8KKyAgZmQgPSBv
cGVuICgiY29uZnRlc3QubW1hcCIsIE9fUkRXUik7CisgIGlmIChmZCA8IDApCisgICAgcmV0dXJu
IDk7CisgIGlmIChkYXRhMiAhPSBtbWFwIChkYXRhMiwgcGFnZXNpemUsIFBST1RfUkVBRCB8IFBS
T1RfV1JJVEUsCisJCSAgICAgTUFQX1BSSVZBVEUgfCBNQVBfRklYRUQsIGZkLCAwTCkpCisgICAg
cmV0dXJuIDEwOworICBmb3IgKGkgPSAwOyBpIDwgcGFnZXNpemU7ICsraSkKKyAgICBpZiAoKihk
YXRhICsgaSkgIT0gKihkYXRhMiArIGkpKQorICAgICAgcmV0dXJuIDExOworCisgIC8qIEZpbmFs
bHksIG1ha2Ugc3VyZSB0aGF0IGNoYW5nZXMgdG8gdGhlIG1hcHBlZCBhcmVhIGRvIG5vdAorICAg
ICBwZXJjb2xhdGUgYmFjayB0byB0aGUgZmlsZSBhcyBzZWVuIGJ5IHJlYWQoKS4gIChUaGlzIGlz
IGEgYnVnIG9uCisgICAgIHNvbWUgdmFyaWFudHMgb2YgaTM4NiBzdnI0LjAuKSAgKi8KKyAgZm9y
IChpID0gMDsgaSA8IHBhZ2VzaXplOyArK2kpCisgICAgKihkYXRhMiArIGkpID0gKihkYXRhMiAr
IGkpICsgMTsKKyAgZGF0YTMgPSAoY2hhciAqKSBtYWxsb2MgKHBhZ2VzaXplKTsKKyAgaWYgKCFk
YXRhMykKKyAgICByZXR1cm4gMTI7CisgIGlmIChyZWFkIChmZCwgZGF0YTMsIHBhZ2VzaXplKSAh
PSBwYWdlc2l6ZSkKKyAgICByZXR1cm4gMTM7CisgIGZvciAoaSA9IDA7IGkgPCBwYWdlc2l6ZTsg
KytpKQorICAgIGlmICgqKGRhdGEgKyBpKSAhPSAqKGRhdGEzICsgaSkpCisgICAgICByZXR1cm4g
MTQ7CisgIGNsb3NlIChmZCk7CisgIHJldHVybiAwOworfQorX0FDRU9GCitpZiBhY19mbl9jX3Ry
eV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZD15
ZXMKK2Vsc2UKKyAgYWNfY3ZfZnVuY19tbWFwX2ZpeGVkX21hcHBlZD1ubworZmkKK3JtIC1mIGNv
cmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBnbW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhl
ZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19l
eHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJl
c3VsdDogJGFjX2N2X2Z1bmNfbW1hcF9maXhlZF9tYXBwZWQiID4mNQorJGFzX2VjaG8gIiRhY19j
dl9mdW5jX21tYXBfZml4ZWRfbWFwcGVkIiA+JjY7IH0KK2lmIHRlc3QgJGFjX2N2X2Z1bmNfbW1h
cF9maXhlZF9tYXBwZWQgPSB5ZXM7IHRoZW4KKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9NTUFQ
IDEiID4+Y29uZmRlZnMuaAorCitmaQorcm0gLWYgY29uZnRlc3QubW1hcCBjb25mdGVzdC50eHQK
KworZm9yIGFjX2hlYWRlciBpbiBzdGRsaWIuaAorZG8gOgorICBhY19mbl9jX2NoZWNrX2hlYWRl
cl9tb25ncmVsICIkTElORU5PIiAic3RkbGliLmgiICJhY19jdl9oZWFkZXJfc3RkbGliX2giICIk
YWNfaW5jbHVkZXNfZGVmYXVsdCIKK2lmIHRlc3QgIngkYWNfY3ZfaGVhZGVyX3N0ZGxpYl9oIiA9
IHh5ZXM7IHRoZW4gOgorICBjYXQgPj5jb25mZGVmcy5oIDw8X0FDRU9GCisjZGVmaW5lIEhBVkVf
U1RETElCX0ggMQorX0FDRU9GCisKK2ZpCisKK2RvbmUKKworeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjaGVja2luZyBmb3IgR05VIGxpYmMgY29tcGF0aWJsZSByZWFs
bG9jIiA+JjUKKyRhc19lY2hvX24gImNoZWNraW5nIGZvciBHTlUgbGliYyBjb21wYXRpYmxlIHJl
YWxsb2MuLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbCs6fSBm
YWxzZTsgdGhlbiA6CisgICRhc19lY2hvX24gIihjYWNoZWQpICIgPiY2CitlbHNlCisgIGlmIHRl
c3QgIiRjcm9zc19jb21waWxpbmciID0geWVzOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19yZWFsbG9j
XzBfbm9ubnVsbD1ubworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVz
dC4kYWNfZXh0CisvKiBlbmQgY29uZmRlZnMuaC4gICovCisjaWYgZGVmaW5lZCBTVERDX0hFQURF
UlMgfHwgZGVmaW5lZCBIQVZFX1NURExJQl9ICisjIGluY2x1ZGUgPHN0ZGxpYi5oPgorI2Vsc2UK
K2NoYXIgKnJlYWxsb2MgKCk7CisjZW5kaWYKKworaW50CittYWluICgpCit7CityZXR1cm4gISBy
ZWFsbG9jICgwLCAwKTsKKyAgOworICByZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190
cnlfcnVuICIkTElORU5PIjsgdGhlbiA6CisgIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGw9
eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfcmVhbGxvY18wX25vbm51bGw9bm8KK2ZpCitybSAtZiBj
b3JlICouY29yZSBjb3JlLmNvbmZ0ZXN0LiogZ21vbi5vdXQgYmIub3V0IGNvbmZ0ZXN0JGFjX2V4
ZWV4dCBcCisgIGNvbmZ0ZXN0LiRhY19vYmpleHQgY29uZnRlc3QuYmVhbSBjb25mdGVzdC4kYWNf
ZXh0CitmaQorCitmaQoreyAkYXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBy
ZXN1bHQ6ICRhY19jdl9mdW5jX3JlYWxsb2NfMF9ub25udWxsIiA+JjUKKyRhc19lY2hvICIkYWNf
Y3ZfZnVuY19yZWFsbG9jXzBfbm9ubnVsbCIgPiY2OyB9CitpZiB0ZXN0ICRhY19jdl9mdW5jX3Jl
YWxsb2NfMF9ub25udWxsID0geWVzOyB0aGVuIDoKKworJGFzX2VjaG8gIiNkZWZpbmUgSEFWRV9S
RUFMTE9DIDEiID4+Y29uZmRlZnMuaAorCitlbHNlCisgICRhc19lY2hvICIjZGVmaW5lIEhBVkVf
UkVBTExPQyAwIiA+PmNvbmZkZWZzLmgKKworICAgY2FzZSAiICRMSUJPQkpTICIgaW4KKyAgKiIg
cmVhbGxvYy4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJQk9CSlMgcmVhbGxv
Yy4kYWNfb2JqZXh0IgorIDs7Citlc2FjCisKKworJGFzX2VjaG8gIiNkZWZpbmUgcmVhbGxvYyBy
cGxfcmVhbGxvYyIgPj5jb25mZGVmcy5oCisKK2ZpCisKKworIHsgJGFzX2VjaG8gIiRhc19tZTok
e2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tpbmcgZm9yIHdvcmtpbmcgc3RybmxlbiIgPiY1Cisk
YXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBzdHJubGVuLi4uICIgPiY2OyB9CitpZiAk
e2FjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nKzp9IGZhbHNlOyB0aGVuIDoKKyAgJGFzX2VjaG9f
biAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgaWYgdGVzdCAiJGNyb3NzX2NvbXBpbGluZyIgPSB5
ZXM7IHRoZW4gOgorICAjIEd1ZXNzIG5vIG9uIEFJWCBzeXN0ZW1zLCB5ZXMgb3RoZXJ3aXNlLgor
CQljYXNlICIkaG9zdF9vcyIgaW4KKwkJICBhaXgqKSBhY19jdl9mdW5jX3N0cm5sZW5fd29ya2lu
Zz1ubzs7CisJCSAgKikgICAgYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmc9eWVzOzsKKwkJZXNh
YworZWxzZQorICBjYXQgY29uZmRlZnMuaCAtIDw8X0FDRU9GID5jb25mdGVzdC4kYWNfZXh0Cisv
KiBlbmQgY29uZmRlZnMuaC4gICovCiskYWNfaW5jbHVkZXNfZGVmYXVsdAoraW50CittYWluICgp
Cit7CisKKyNkZWZpbmUgUyAiZm9vYmFyIgorI2RlZmluZSBTX0xFTiAoc2l6ZW9mIFMgLSAxKQor
CisgIC8qIEF0IGxlYXN0IG9uZSBpbXBsZW1lbnRhdGlvbiBpcyBidWdneTogdGhhdCBvZiBBSVgg
NC4zIHdvdWxkCisgICAgIGdpdmUgc3RybmxlbiAoUywgMSkgPT0gMy4gICovCisKKyAgaW50IGk7
CisgIGZvciAoaSA9IDA7IGkgPCBTX0xFTiArIDE7ICsraSkKKyAgICB7CisgICAgICBpbnQgZXhw
ZWN0ZWQgPSBpIDw9IFNfTEVOID8gaSA6IFNfTEVOOworICAgICAgaWYgKHN0cm5sZW4gKFMsIGkp
ICE9IGV4cGVjdGVkKQorCXJldHVybiAxOworICAgIH0KKyAgcmV0dXJuIDA7CisKKyAgOworICBy
ZXR1cm4gMDsKK30KK19BQ0VPRgoraWYgYWNfZm5fY190cnlfcnVuICIkTElORU5PIjsgdGhlbiA6
CisgIGFjX2N2X2Z1bmNfc3Rybmxlbl93b3JraW5nPXllcworZWxzZQorICBhY19jdl9mdW5jX3N0
cm5sZW5fd29ya2luZz1ubworZmkKK3JtIC1mIGNvcmUgKi5jb3JlIGNvcmUuY29uZnRlc3QuKiBn
bW9uLm91dCBiYi5vdXQgY29uZnRlc3QkYWNfZXhlZXh0IFwKKyAgY29uZnRlc3QuJGFjX29iamV4
dCBjb25mdGVzdC5iZWFtIGNvbmZ0ZXN0LiRhY19leHQKK2ZpCisKK2ZpCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHJlc3VsdDogJGFjX2N2X2Z1bmNfc3Rybmxlbl93
b3JraW5nIiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmciID4mNjsg
fQordGVzdCAkYWNfY3ZfZnVuY19zdHJubGVuX3dvcmtpbmcgPSBubyAmJiBjYXNlICIgJExJQk9C
SlMgIiBpbgorICAqIiBzdHJubGVuLiRhY19vYmpleHQgIiogKSA7OworICAqKSBMSUJPQkpTPSIk
TElCT0JKUyBzdHJubGVuLiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworCit7ICRhc19lY2hvICIk
YXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IGNoZWNraW5nIGZvciB3b3JraW5nIHN0cnRvZCIg
PiY1CiskYXNfZWNob19uICJjaGVja2luZyBmb3Igd29ya2luZyBzdHJ0b2QuLi4gIiA+JjY7IH0K
K2lmICR7YWNfY3ZfZnVuY19zdHJ0b2QrOn0gZmFsc2U7IHRoZW4gOgorICAkYXNfZWNob19uICIo
Y2FjaGVkKSAiID4mNgorZWxzZQorICBpZiB0ZXN0ICIkY3Jvc3NfY29tcGlsaW5nIiA9IHllczsg
dGhlbiA6CisgIGFjX2N2X2Z1bmNfc3RydG9kPW5vCitlbHNlCisgIGNhdCBjb25mZGVmcy5oIC0g
PDxfQUNFT0YgPmNvbmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworJGFj
X2luY2x1ZGVzX2RlZmF1bHQKKyNpZm5kZWYgc3RydG9kCitkb3VibGUgc3RydG9kICgpOworI2Vu
ZGlmCitpbnQKK21haW4oKQoreworICB7CisgICAgLyogU29tZSB2ZXJzaW9ucyBvZiBMaW51eCBz
dHJ0b2QgbWlzLXBhcnNlIHN0cmluZ3Mgd2l0aCBsZWFkaW5nICcrJy4gICovCisgICAgY2hhciAq
c3RyaW5nID0gIiArNjkiOworICAgIGNoYXIgKnRlcm07CisgICAgZG91YmxlIHZhbHVlOworICAg
IHZhbHVlID0gc3RydG9kIChzdHJpbmcsICZ0ZXJtKTsKKyAgICBpZiAodmFsdWUgIT0gNjkgfHwg
dGVybSAhPSAoc3RyaW5nICsgNCkpCisgICAgICByZXR1cm4gMTsKKyAgfQorCisgIHsKKyAgICAv
KiBVbmRlciBTb2xhcmlzIDIuNCwgc3RydG9kIHJldHVybnMgdGhlIHdyb25nIHZhbHVlIGZvciB0
aGUKKyAgICAgICB0ZXJtaW5hdGluZyBjaGFyYWN0ZXIgdW5kZXIgc29tZSBjb25kaXRpb25zLiAg
Ki8KKyAgICBjaGFyICpzdHJpbmcgPSAiTmFOIjsKKyAgICBjaGFyICp0ZXJtOworICAgIHN0cnRv
ZCAoc3RyaW5nLCAmdGVybSk7CisgICAgaWYgKHRlcm0gIT0gc3RyaW5nICYmICoodGVybSAtIDEp
ID09IDApCisgICAgICByZXR1cm4gMTsKKyAgfQorICByZXR1cm4gMDsKK30KKworX0FDRU9GCitp
ZiBhY19mbl9jX3RyeV9ydW4gIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfZnVuY19zdHJ0b2Q9
eWVzCitlbHNlCisgIGFjX2N2X2Z1bmNfc3RydG9kPW5vCitmaQorcm0gLWYgY29yZSAqLmNvcmUg
Y29yZS5jb25mdGVzdC4qIGdtb24ub3V0IGJiLm91dCBjb25mdGVzdCRhY19leGVleHQgXAorICBj
b25mdGVzdC4kYWNfb2JqZXh0IGNvbmZ0ZXN0LmJlYW0gY29uZnRlc3QuJGFjX2V4dAorZmkKKwor
ZmkKK3sgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNf
Y3ZfZnVuY19zdHJ0b2QiID4mNQorJGFzX2VjaG8gIiRhY19jdl9mdW5jX3N0cnRvZCIgPiY2OyB9
CitpZiB0ZXN0ICRhY19jdl9mdW5jX3N0cnRvZCA9IG5vOyB0aGVuCisgIGNhc2UgIiAkTElCT0JK
UyAiIGluCisgICoiIHN0cnRvZC4kYWNfb2JqZXh0ICIqICkgOzsKKyAgKikgTElCT0JKUz0iJExJ
Qk9CSlMgc3RydG9kLiRhY19vYmpleHQiCisgOzsKK2VzYWMKKworYWNfZm5fY19jaGVja19mdW5j
ICIkTElORU5PIiAicG93IiAiYWNfY3ZfZnVuY19wb3ciCitpZiB0ZXN0ICJ4JGFjX2N2X2Z1bmNf
cG93IiA9IHh5ZXM7IHRoZW4gOgorCitmaQorCitpZiB0ZXN0ICRhY19jdl9mdW5jX3BvdyA9IG5v
OyB0aGVuCisgIHsgJGFzX2VjaG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogY2hlY2tp
bmcgZm9yIHBvdyBpbiAtbG0iID4mNQorJGFzX2VjaG9fbiAiY2hlY2tpbmcgZm9yIHBvdyBpbiAt
bG0uLi4gIiA+JjY7IH0KK2lmICR7YWNfY3ZfbGliX21fcG93Kzp9IGZhbHNlOyB0aGVuIDoKKyAg
JGFzX2VjaG9fbiAiKGNhY2hlZCkgIiA+JjYKK2Vsc2UKKyAgYWNfY2hlY2tfbGliX3NhdmVfTElC
Uz0kTElCUworTElCUz0iLWxtICAkTElCUyIKK2NhdCBjb25mZGVmcy5oIC0gPDxfQUNFT0YgPmNv
bmZ0ZXN0LiRhY19leHQKKy8qIGVuZCBjb25mZGVmcy5oLiAgKi8KKworLyogT3ZlcnJpZGUgYW55
IEdDQyBpbnRlcm5hbCBwcm90b3R5cGUgdG8gYXZvaWQgYW4gZXJyb3IuCisgICBVc2UgY2hhciBi
ZWNhdXNlIGludCBtaWdodCBtYXRjaCB0aGUgcmV0dXJuIHR5cGUgb2YgYSBHQ0MKKyAgIGJ1aWx0
aW4gYW5kIHRoZW4gaXRzIGFyZ3VtZW50IHByb3RvdHlwZSB3b3VsZCBzdGlsbCBhcHBseS4gICov
CisjaWZkZWYgX19jcGx1c3BsdXMKK2V4dGVybiAiQyIKKyNlbmRpZgorY2hhciBwb3cgKCk7Citp
bnQKK21haW4gKCkKK3sKK3JldHVybiBwb3cgKCk7CisgIDsKKyAgcmV0dXJuIDA7Cit9CitfQUNF
T0YKK2lmIGFjX2ZuX2NfdHJ5X2xpbmsgIiRMSU5FTk8iOyB0aGVuIDoKKyAgYWNfY3ZfbGliX21f
cG93PXllcworZWxzZQorICBhY19jdl9saWJfbV9wb3c9bm8KK2ZpCitybSAtZiBjb3JlIGNvbmZ0
ZXN0LmVyciBjb25mdGVzdC4kYWNfb2JqZXh0IFwKKyAgICBjb25mdGVzdCRhY19leGVleHQgY29u
ZnRlc3QuJGFjX2V4dAorTElCUz0kYWNfY2hlY2tfbGliX3NhdmVfTElCUworZmkKK3sgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogcmVzdWx0OiAkYWNfY3ZfbGliX21fcG93
IiA+JjUKKyRhc19lY2hvICIkYWNfY3ZfbGliX21fcG93IiA+JjY7IH0KK2lmIHRlc3QgIngkYWNf
Y3ZfbGliX21fcG93IiA9IHh5ZXM7IHRoZW4gOgorICBQT1dfTElCPS1sbQorZWxzZQorICB7ICRh
c19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IGNhbm5vdCBmaW5k
IGxpYnJhcnkgY29udGFpbmluZyBkZWZpbml0aW9uIG9mIHBvdyIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBXQVJOSU5HOiBjYW5ub3QgZmluZCBsaWJyYXJ5IGNvbnRhaW5pbmcgZGVmaW5pdGlvbiBv
ZiBwb3ciID4mMjt9CitmaQorCitmaQorCitmaQorCitmb3IgYWNfZnVuYyBpbiAgXAorICAgICAg
ICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5j
IGZ0cnVuY2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9z
dG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250
b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAg
ICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRp
ciBzZWxlY3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJj
aHIgc3RyY3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3Ry
cGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQg
XAorICAgICAgICAgICAgICAgIHVuYW1lIFwKKworZG8gOgorICBhc19hY192YXI9YCRhc19lY2hv
ICJhY19jdl9mdW5jXyRhY19mdW5jIiB8ICRhc190cl9zaGAKK2FjX2ZuX2NfY2hlY2tfZnVuYyAi
JExJTkVOTyIgIiRhY19mdW5jIiAiJGFzX2FjX3ZhciIKK2lmIGV2YWwgdGVzdCBcInhcJCIkYXNf
YWNfdmFyIlwiID0geCJ5ZXMiOyB0aGVuIDoKKyAgY2F0ID4+Y29uZmRlZnMuaCA8PF9BQ0VPRgor
I2RlZmluZSBgJGFzX2VjaG8gIkhBVkVfJGFjX2Z1bmMiIHwgJGFzX3RyX2NwcGAgMQorX0FDRU9G
CisKK2ZpCitkb25lCisKKworY2F0ID5jb25mY2FjaGUgPDxcX0FDRU9GCisjIFRoaXMgZmlsZSBp
cyBhIHNoZWxsIHNjcmlwdCB0aGF0IGNhY2hlcyB0aGUgcmVzdWx0cyBvZiBjb25maWd1cmUKKyMg
dGVzdHMgcnVuIG9uIHRoaXMgc3lzdGVtIHNvIHRoZXkgY2FuIGJlIHNoYXJlZCBiZXR3ZWVuIGNv
bmZpZ3VyZQorIyBzY3JpcHRzIGFuZCBjb25maWd1cmUgcnVucywgc2VlIGNvbmZpZ3VyZSdzIG9w
dGlvbiAtLWNvbmZpZy1jYWNoZS4KKyMgSXQgaXMgbm90IHVzZWZ1bCBvbiBvdGhlciBzeXN0ZW1z
LiAgSWYgaXQgY29udGFpbnMgcmVzdWx0cyB5b3UgZG9uJ3QKKyMgd2FudCB0byBrZWVwLCB5b3Ug
bWF5IHJlbW92ZSBvciBlZGl0IGl0LgorIworIyBjb25maWcuc3RhdHVzIG9ubHkgcGF5cyBhdHRl
bnRpb24gdG8gdGhlIGNhY2hlIGZpbGUgaWYgeW91IGdpdmUgaXQKKyMgdGhlIC0tcmVjaGVjayBv
cHRpb24gdG8gcmVydW4gY29uZmlndXJlLgorIworIyBgYWNfY3ZfZW52X2ZvbycgdmFyaWFibGVz
IChzZXQgb3IgdW5zZXQpIHdpbGwgYmUgb3ZlcnJpZGRlbiB3aGVuCisjIGxvYWRpbmcgdGhpcyBm
aWxlLCBvdGhlciAqdW5zZXQqIGBhY19jdl9mb28nIHdpbGwgYmUgYXNzaWduZWQgdGhlCisjIGZv
bGxvd2luZyB2YWx1ZXMuCisKK19BQ0VPRgorCisjIFRoZSBmb2xsb3dpbmcgd2F5IG9mIHdyaXRp
bmcgdGhlIGNhY2hlIG1pc2hhbmRsZXMgbmV3bGluZXMgaW4gdmFsdWVzLAorIyBidXQgd2Uga25v
dyBvZiBubyB3b3JrYXJvdW5kIHRoYXQgaXMgc2ltcGxlLCBwb3J0YWJsZSwgYW5kIGVmZmljaWVu
dC4KKyMgU28sIHdlIGtpbGwgdmFyaWFibGVzIGNvbnRhaW5pbmcgbmV3bGluZXMuCisjIFVsdHJp
eCBzaCBzZXQgd3JpdGVzIHRvIHN0ZGVyciBhbmQgY2FuJ3QgYmUgcmVkaXJlY3RlZCBkaXJlY3Rs
eSwKKyMgYW5kIHNldHMgdGhlIGhpZ2ggYml0IGluIHRoZSBjYWNoZSBmaWxlIHVubGVzcyB3ZSBh
c3NpZ24gdG8gdGhlIHZhcnMuCisoCisgIGZvciBhY192YXIgaW4gYChzZXQpIDI+JjEgfCBzZWQg
LW4gJ3MvXlwoW2EtekEtWl9dW2EtekEtWjAtOV9dKlwpPS4qL1wxL3AnYDsgZG8KKyAgICBldmFs
IGFjX3ZhbD1cJCRhY192YXIKKyAgICBjYXNlICRhY192YWwgaW4gIygKKyAgICAqJHthc19ubH0q
KQorICAgICAgY2FzZSAkYWNfdmFyIGluICMoCisgICAgICAqX2N2XyopIHsgJGFzX2VjaG8gIiRh
c19tZToke2FzX2xpbmVuby0kTElORU5PfTogV0FSTklORzogY2FjaGUgdmFyaWFibGUgJGFjX3Zh
ciBjb250YWlucyBhIG5ld2xpbmUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FSTklORzogY2Fj
aGUgdmFyaWFibGUgJGFjX3ZhciBjb250YWlucyBhIG5ld2xpbmUiID4mMjt9IDs7CisgICAgICBl
c2FjCisgICAgICBjYXNlICRhY192YXIgaW4gIygKKyAgICAgIF8gfCBJRlMgfCBhc19ubCkgOzsg
IygKKyAgICAgIEJBU0hfQVJHViB8IEJBU0hfU09VUkNFKSBldmFsICRhY192YXI9IDs7ICMoCisg
ICAgICAqKSB7IGV2YWwgJGFjX3Zhcj07IHVuc2V0ICRhY192YXI7fSA7OworICAgICAgZXNhYyA7
OworICAgIGVzYWMKKyAgZG9uZQorCisgIChzZXQpIDI+JjEgfAorICAgIGNhc2UgJGFzX25sYChh
Y19zcGFjZT0nICc7IHNldCkgMj4mMWAgaW4gIygKKyAgICAqJHthc19ubH1hY19zcGFjZT1cICop
CisgICAgICAjIGBzZXQnIGRvZXMgbm90IHF1b3RlIGNvcnJlY3RseSwgc28gYWRkIHF1b3Rlczog
ZG91YmxlLXF1b3RlCisgICAgICAjIHN1YnN0aXR1dGlvbiB0dXJucyBcXFxcIGludG8gXFwsIGFu
ZCBzZWQgdHVybnMgXFwgaW50byBcLgorICAgICAgc2VkIC1uIFwKKwkicy8nLydcXFxcJycvZzsK
KwkgIHMvXlxcKFtfJGFzX2NyX2FsbnVtXSpfY3ZfW18kYXNfY3JfYWxudW1dKlxcKT1cXCguKlxc
KS9cXDE9J1xcMicvcCIKKyAgICAgIDs7ICMoCisgICAgKikKKyAgICAgICMgYHNldCcgcXVvdGVz
IGNvcnJlY3RseSBhcyByZXF1aXJlZCBieSBQT1NJWCwgc28gZG8gbm90IGFkZCBxdW90ZXMuCisg
ICAgICBzZWQgLW4gIi9eW18kYXNfY3JfYWxudW1dKl9jdl9bXyRhc19jcl9hbG51bV0qPS9wIgor
ICAgICAgOzsKKyAgICBlc2FjIHwKKyAgICBzb3J0CispIHwKKyAgc2VkICcKKyAgICAgL15hY19j
dl9lbnZfL2IgZW5kCisgICAgIHQgY2xlYXIKKyAgICAgOmNsZWFyCisgICAgIHMvXlwoW149XSpc
KT1cKC4qW3t9XS4qXCkkL3Rlc3QgIiR7XDErc2V0fSIgPSBzZXQgfHwgJi8KKyAgICAgdCBlbmQK
KyAgICAgcy9eXChbXj1dKlwpPVwoLipcKSQvXDE9JHtcMT1cMn0vCisgICAgIDplbmQnID4+Y29u
ZmNhY2hlCitpZiBkaWZmICIkY2FjaGVfZmlsZSIgY29uZmNhY2hlID4vZGV2L251bGwgMj4mMTsg
dGhlbiA6OyBlbHNlCisgIGlmIHRlc3QgLXcgIiRjYWNoZV9maWxlIjsgdGhlbgorICAgIGlmIHRl
c3QgIngkY2FjaGVfZmlsZSIgIT0gIngvZGV2L251bGwiOyB0aGVuCisgICAgICB7ICRhc19lY2hv
ICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IHVwZGF0aW5nIGNhY2hlICRjYWNoZV9maWxl
IiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IHVwZGF0aW5nIGNhY2hlICRjYWNoZV9maWxlIiA+JjY7
fQorICAgICAgaWYgdGVzdCAhIC1mICIkY2FjaGVfZmlsZSIgfHwgdGVzdCAtaCAiJGNhY2hlX2Zp
bGUiOyB0aGVuCisJY2F0IGNvbmZjYWNoZSA+IiRjYWNoZV9maWxlIgorICAgICAgZWxzZQorICAg
ICAgICBjYXNlICRjYWNoZV9maWxlIGluICMoCisgICAgICAgICovKiB8ID86KikKKwkgIG12IC1m
IGNvbmZjYWNoZSAiJGNhY2hlX2ZpbGUiJCQgJiYKKwkgIG12IC1mICIkY2FjaGVfZmlsZSIkJCAi
JGNhY2hlX2ZpbGUiIDs7ICMoCisgICAgICAgICopCisJICBtdiAtZiBjb25mY2FjaGUgIiRjYWNo
ZV9maWxlIiA7OworCWVzYWMKKyAgICAgIGZpCisgICAgZmkKKyAgZWxzZQorICAgIHsgJGFzX2Vj
aG8gIiRhc19tZToke2FzX2xpbmVuby0kTElORU5PfTogbm90IHVwZGF0aW5nIHVud3JpdGFibGUg
Y2FjaGUgJGNhY2hlX2ZpbGUiID4mNQorJGFzX2VjaG8gIiRhc19tZTogbm90IHVwZGF0aW5nIHVu
d3JpdGFibGUgY2FjaGUgJGNhY2hlX2ZpbGUiID4mNjt9CisgIGZpCitmaQorcm0gLWYgY29uZmNh
Y2hlCisKK3Rlc3QgIngkcHJlZml4IiA9IHhOT05FICYmIHByZWZpeD0kYWNfZGVmYXVsdF9wcmVm
aXgKKyMgTGV0IG1ha2UgZXhwYW5kIGV4ZWNfcHJlZml4LgordGVzdCAieCRleGVjX3ByZWZpeCIg
PSB4Tk9ORSAmJiBleGVjX3ByZWZpeD0nJHtwcmVmaXh9JworCitERUZTPS1ESEFWRV9DT05GSUdf
SAorCithY19saWJvYmpzPQorYWNfbHRsaWJvYmpzPQorVT0KK2ZvciBhY19pIGluIDogJExJQk9C
SlM7IGRvIHRlc3QgIngkYWNfaSIgPSB4OiAmJiBjb250aW51ZQorICAjIDEuIFJlbW92ZSB0aGUg
ZXh0ZW5zaW9uLCBhbmQgJFUgaWYgYWxyZWFkeSBpbnN0YWxsZWQuCisgIGFjX3NjcmlwdD0ncy9c
JFVcLi8uLztzL1wubyQvLztzL1wub2JqJC8vJworICBhY19pPWAkYXNfZWNobyAiJGFjX2kiIHwg
c2VkICIkYWNfc2NyaXB0ImAKKyAgIyAyLiBQcmVwZW5kIExJQk9CSkRJUi4gIFdoZW4gdXNlZCB3
aXRoIGF1dG9tYWtlPj0xLjEwIExJQk9CSkRJUgorICAjICAgIHdpbGwgYmUgc2V0IHRvIHRoZSBk
aXJlY3Rvcnkgd2hlcmUgTElCT0JKUyBvYmplY3RzIGFyZSBidWlsdC4KKyAgYXNfZm5fYXBwZW5k
IGFjX2xpYm9ianMgIiBcJHtMSUJPQkpESVJ9JGFjX2lcJFUuJGFjX29iamV4dCIKKyAgYXNfZm5f
YXBwZW5kIGFjX2x0bGlib2JqcyAiIFwke0xJQk9CSkRJUn0kYWNfaSInJFUubG8nCitkb25lCitM
SUJPQkpTPSRhY19saWJvYmpzCisKK0xUTElCT0JKUz0kYWNfbHRsaWJvYmpzCisKKworCis6ICIk
e0NPTkZJR19TVEFUVVM9Li9jb25maWcuc3RhdHVzfSIKK2FjX3dyaXRlX2ZhaWw9MAorYWNfY2xl
YW5fZmlsZXNfc2F2ZT0kYWNfY2xlYW5fZmlsZXMKK2FjX2NsZWFuX2ZpbGVzPSIkYWNfY2xlYW5f
ZmlsZXMgJENPTkZJR19TVEFUVVMiCit7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJ
TkVOT306IGNyZWF0aW5nICRDT05GSUdfU1RBVFVTIiA+JjUKKyRhc19lY2hvICIkYXNfbWU6IGNy
ZWF0aW5nICRDT05GSUdfU1RBVFVTIiA+JjY7fQorYXNfd3JpdGVfZmFpbD0wCitjYXQgPiRDT05G
SUdfU1RBVFVTIDw8X0FTRU9GIHx8IGFzX3dyaXRlX2ZhaWw9MQorIyEgJFNIRUxMCisjIEdlbmVy
YXRlZCBieSAkYXNfbWUuCisjIFJ1biB0aGlzIGZpbGUgdG8gcmVjcmVhdGUgdGhlIGN1cnJlbnQg
Y29uZmlndXJhdGlvbi4KKyMgQ29tcGlsZXIgb3V0cHV0IHByb2R1Y2VkIGJ5IGNvbmZpZ3VyZSwg
dXNlZnVsIGZvciBkZWJ1Z2dpbmcKKyMgY29uZmlndXJlLCBpcyBpbiBjb25maWcubG9nIGlmIGl0
IGV4aXN0cy4KKworZGVidWc9ZmFsc2UKK2FjX2NzX3JlY2hlY2s9ZmFsc2UKK2FjX2NzX3NpbGVu
dD1mYWxzZQorCitTSEVMTD1cJHtDT05GSUdfU0hFTEwtJFNIRUxMfQorZXhwb3J0IFNIRUxMCitf
QVNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BU0VPRiB8fCBhc193cml0ZV9mYWlsPTEK
KyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBNNHNoIEluaXRpYWxpemF0aW9uLiAjIwor
IyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0gIyMKKworIyBCZSBtb3JlIEJvdXJuZSBjb21wYXRpYmxl
CitEVUFMQ0FTRT0xOyBleHBvcnQgRFVBTENBU0UgIyBmb3IgTUtTIHNoCitpZiB0ZXN0IC1uICIk
e1pTSF9WRVJTSU9OK3NldH0iICYmIChlbXVsYXRlIHNoKSA+L2Rldi9udWxsIDI+JjE7IHRoZW4g
OgorICBlbXVsYXRlIHNoCisgIE5VTExDTUQ9OgorICAjIFByZS00LjIgdmVyc2lvbnMgb2YgWnNo
IGRvIHdvcmQgc3BsaXR0aW5nIG9uICR7MSsiJEAifSwgd2hpY2gKKyAgIyBpcyBjb250cmFyeSB0
byBvdXIgdXNhZ2UuICBEaXNhYmxlIHRoaXMgZmVhdHVyZS4KKyAgYWxpYXMgLWcgJyR7MSsiJEAi
fSc9JyIkQCInCisgIHNldG9wdCBOT19HTE9CX1NVQlNUCitlbHNlCisgIGNhc2UgYChzZXQgLW8p
IDI+L2Rldi9udWxsYCBpbiAjKAorICAqcG9zaXgqKSA6CisgICAgc2V0IC1vIHBvc2l4IDs7ICMo
CisgICopIDoKKyAgICAgOzsKK2VzYWMKK2ZpCisKKworYXNfbmw9JworJworZXhwb3J0IGFzX25s
CisjIFByaW50aW5nIGEgbG9uZyBzdHJpbmcgY3Jhc2hlcyBTb2xhcmlzIDcgL3Vzci9iaW4vcHJp
bnRmLgorYXNfZWNobz0nXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxcXFxc
XFxcXCcKK2FzX2VjaG89JGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobwor
YXNfZWNobz0kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8kYXNfZWNobyRhc19lY2hvJGFzX2VjaG8K
KyMgUHJlZmVyIGEga3NoIHNoZWxsIGJ1aWx0aW4gb3ZlciBhbiBleHRlcm5hbCBwcmludGYgcHJv
Z3JhbSBvbiBTb2xhcmlzLAorIyBidXQgd2l0aG91dCB3YXN0aW5nIGZvcmtzIGZvciBiYXNoIG9y
IHpzaC4KK2lmIHRlc3QgLXogIiRCQVNIX1ZFUlNJT04kWlNIX1ZFUlNJT04iIFwKKyAgICAmJiAo
dGVzdCAiWGBwcmludCAtciAtLSAkYXNfZWNob2AiID0gIlgkYXNfZWNobyIpIDI+L2Rldi9udWxs
OyB0aGVuCisgIGFzX2VjaG89J3ByaW50IC1yIC0tJworICBhc19lY2hvX249J3ByaW50IC1ybiAt
LScKK2VsaWYgKHRlc3QgIlhgcHJpbnRmICVzICRhc19lY2hvYCIgPSAiWCRhc19lY2hvIikgMj4v
ZGV2L251bGw7IHRoZW4KKyAgYXNfZWNobz0ncHJpbnRmICVzXG4nCisgIGFzX2VjaG9fbj0ncHJp
bnRmICVzJworZWxzZQorICBpZiB0ZXN0ICJYYCgvdXNyL3VjYi9lY2hvIC1uIC1uICRhc19lY2hv
KSAyPi9kZXYvbnVsbGAiID0gIlgtbiAkYXNfZWNobyI7IHRoZW4KKyAgICBhc19lY2hvX2JvZHk9
J2V2YWwgL3Vzci91Y2IvZWNobyAtbiAiJDEkYXNfbmwiJworICAgIGFzX2VjaG9fbj0nL3Vzci91
Y2IvZWNobyAtbicKKyAgZWxzZQorICAgIGFzX2VjaG9fYm9keT0nZXZhbCBleHByICJYJDEiIDog
IlhcXCguKlxcKSInCisgICAgYXNfZWNob19uX2JvZHk9J2V2YWwKKyAgICAgIGFyZz0kMTsKKyAg
ICAgIGNhc2UgJGFyZyBpbiAjKAorICAgICAgKiIkYXNfbmwiKikKKwlleHByICJYJGFyZyIgOiAi
WFxcKC4qXFwpJGFzX25sIjsKKwlhcmc9YGV4cHIgIlgkYXJnIiA6ICIuKiRhc19ubFxcKC4qXFwp
ImA7OworICAgICAgZXNhYzsKKyAgICAgIGV4cHIgIlgkYXJnIiA6ICJYXFwoLipcXCkiIHwgdHIg
LWQgIiRhc19ubCIKKyAgICAnCisgICAgZXhwb3J0IGFzX2VjaG9fbl9ib2R5CisgICAgYXNfZWNo
b19uPSdzaCAtYyAkYXNfZWNob19uX2JvZHkgYXNfZWNobycKKyAgZmkKKyAgZXhwb3J0IGFzX2Vj
aG9fYm9keQorICBhc19lY2hvPSdzaCAtYyAkYXNfZWNob19ib2R5IGFzX2VjaG8nCitmaQorCisj
IFRoZSB1c2VyIGlzIGFsd2F5cyByaWdodC4KK2lmIHRlc3QgIiR7UEFUSF9TRVBBUkFUT1Irc2V0
fSIgIT0gc2V0OyB0aGVuCisgIFBBVEhfU0VQQVJBVE9SPToKKyAgKFBBVEg9Jy9iaW47L2Jpbic7
IEZQQVRIPSRQQVRIOyBzaCAtYyA6KSA+L2Rldi9udWxsIDI+JjEgJiYgeworICAgIChQQVRIPScv
YmluOi9iaW4nOyBGUEFUSD0kUEFUSDsgc2ggLWMgOikgPi9kZXYvbnVsbCAyPiYxIHx8CisgICAg
ICBQQVRIX1NFUEFSQVRPUj0nOycKKyAgfQorZmkKKworCisjIElGUworIyBXZSBuZWVkIHNwYWNl
LCB0YWIgYW5kIG5ldyBsaW5lLCBpbiBwcmVjaXNlbHkgdGhhdCBvcmRlci4gIFF1b3RpbmcgaXMK
KyMgdGhlcmUgdG8gcHJldmVudCBlZGl0b3JzIGZyb20gY29tcGxhaW5pbmcgYWJvdXQgc3BhY2Ut
dGFiLgorIyAoSWYgX0FTX1BBVEhfV0FMSyB3ZXJlIGNhbGxlZCB3aXRoIElGUyB1bnNldCwgaXQg
d291bGQgZGlzYWJsZSB3b3JkCisjIHNwbGl0dGluZyBieSBzZXR0aW5nIElGUyB0byBlbXB0eSB2
YWx1ZS4pCitJRlM9IiAiIgkkYXNfbmwiCisKKyMgRmluZCB3aG8gd2UgYXJlLiAgTG9vayBpbiB0
aGUgcGF0aCBpZiB3ZSBjb250YWluIG5vIGRpcmVjdG9yeSBzZXBhcmF0b3IuCithc19teXNlbGY9
CitjYXNlICQwIGluICMoKAorICAqW1xcL10qICkgYXNfbXlzZWxmPSQwIDs7CisgICopIGFzX3Nh
dmVfSUZTPSRJRlM7IElGUz0kUEFUSF9TRVBBUkFUT1IKK2ZvciBhc19kaXIgaW4gJFBBVEgKK2Rv
CisgIElGUz0kYXNfc2F2ZV9JRlMKKyAgdGVzdCAteiAiJGFzX2RpciIgJiYgYXNfZGlyPS4KKyAg
ICB0ZXN0IC1yICIkYXNfZGlyLyQwIiAmJiBhc19teXNlbGY9JGFzX2Rpci8kMCAmJiBicmVhawor
ICBkb25lCitJRlM9JGFzX3NhdmVfSUZTCisKKyAgICAgOzsKK2VzYWMKKyMgV2UgZGlkIG5vdCBm
aW5kIG91cnNlbHZlcywgbW9zdCBwcm9iYWJseSB3ZSB3ZXJlIHJ1biBhcyBgc2ggQ09NTUFORCcK
KyMgaW4gd2hpY2ggY2FzZSB3ZSBhcmUgbm90IHRvIGJlIGZvdW5kIGluIHRoZSBwYXRoLgoraWYg
dGVzdCAieCRhc19teXNlbGYiID0geDsgdGhlbgorICBhc19teXNlbGY9JDAKK2ZpCitpZiB0ZXN0
ICEgLWYgIiRhc19teXNlbGYiOyB0aGVuCisgICRhc19lY2hvICIkYXNfbXlzZWxmOiBlcnJvcjog
Y2Fubm90IGZpbmQgbXlzZWxmOyByZXJ1biB3aXRoIGFuIGFic29sdXRlIGZpbGUgbmFtZSIgPiYy
CisgIGV4aXQgMQorZmkKKworIyBVbnNldCB2YXJpYWJsZXMgdGhhdCB3ZSBkbyBub3QgbmVlZCBh
bmQgd2hpY2ggY2F1c2UgYnVncyAoZS5nLiBpbgorIyBwcmUtMy4wIFVXSU4ga3NoKS4gIEJ1dCBk
byBub3QgY2F1c2UgYnVncyBpbiBiYXNoIDIuMDE7IHRoZSAifHwgZXhpdCAxIgorIyBzdXBwcmVz
c2VzIGFueSAiU2VnbWVudGF0aW9uIGZhdWx0IiBtZXNzYWdlIHRoZXJlLiAgJygoJyBjb3VsZAor
IyB0cmlnZ2VyIGEgYnVnIGluIHBka3NoIDUuMi4xNC4KK2ZvciBhc192YXIgaW4gQkFTSF9FTlYg
RU5WIE1BSUwgTUFJTFBBVEgKK2RvIGV2YWwgdGVzdCB4XCR7JGFzX3ZhcitzZXR9ID0geHNldCBc
CisgICYmICggKHVuc2V0ICRhc192YXIpIHx8IGV4aXQgMSkgPi9kZXYvbnVsbCAyPiYxICYmIHVu
c2V0ICRhc192YXIgfHwgOgorZG9uZQorUFMxPSckICcKK1BTMj0nPiAnCitQUzQ9JysgJworCisj
IE5MUyBudWlzYW5jZXMuCitMQ19BTEw9QworZXhwb3J0IExDX0FMTAorTEFOR1VBR0U9QworZXhw
b3J0IExBTkdVQUdFCisKKyMgQ0RQQVRILgorKHVuc2V0IENEUEFUSCkgPi9kZXYvbnVsbCAyPiYx
ICYmIHVuc2V0IENEUEFUSAorCisKKyMgYXNfZm5fZXJyb3IgU1RBVFVTIEVSUk9SIFtMSU5FTk8g
TE9HX0ZEXQorIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIE91
dHB1dCAiYGJhc2VuYW1lICQwYDogZXJyb3I6IEVSUk9SIiB0byBzdGRlcnIuIElmIExJTkVOTyBh
bmQgTE9HX0ZEIGFyZQorIyBwcm92aWRlZCwgYWxzbyBvdXRwdXQgdGhlIGVycm9yIHRvIExPR19G
RCwgcmVmZXJlbmNpbmcgTElORU5PLiBUaGVuIGV4aXQgdGhlCisjIHNjcmlwdCB3aXRoIFNUQVRV
UywgdXNpbmcgMSBpZiB0aGF0IHdhcyAwLgorYXNfZm5fZXJyb3IgKCkKK3sKKyAgYXNfc3RhdHVz
PSQxOyB0ZXN0ICRhc19zdGF0dXMgLWVxIDAgJiYgYXNfc3RhdHVzPTEKKyAgaWYgdGVzdCAiJDQi
OyB0aGVuCisgICAgYXNfbGluZW5vPSR7YXNfbGluZW5vLSIkMyJ9IGFzX2xpbmVub19zdGFjaz1h
c19saW5lbm9fc3RhY2s9JGFzX2xpbmVub19zdGFjaworICAgICRhc19lY2hvICIkYXNfbWU6JHth
c19saW5lbm8tJExJTkVOT306IGVycm9yOiAkMiIgPiYkNAorICBmaQorICAkYXNfZWNobyAiJGFz
X21lOiBlcnJvcjogJDIiID4mMgorICBhc19mbl9leGl0ICRhc19zdGF0dXMKK30gIyBhc19mbl9l
cnJvcgorCisKKyMgYXNfZm5fc2V0X3N0YXR1cyBTVEFUVVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0KKyMgU2V0ICQ/IHRvIFNUQVRVUywgd2l0aG91dCBmb3JraW5nLgorYXNfZm5fc2V0X3N0
YXR1cyAoKQoreworICByZXR1cm4gJDEKK30gIyBhc19mbl9zZXRfc3RhdHVzCisKKyMgYXNfZm5f
ZXhpdCBTVEFUVVMKKyMgLS0tLS0tLS0tLS0tLS0tLS0KKyMgRXhpdCB0aGUgc2hlbGwgd2l0aCBT
VEFUVVMsIGV2ZW4gaW4gYSAidHJhcCAwIiBvciAic2V0IC1lIiBjb250ZXh0LgorYXNfZm5fZXhp
dCAoKQoreworICBzZXQgK2UKKyAgYXNfZm5fc2V0X3N0YXR1cyAkMQorICBleGl0ICQxCit9ICMg
YXNfZm5fZXhpdAorCisjIGFzX2ZuX3Vuc2V0IFZBUgorIyAtLS0tLS0tLS0tLS0tLS0KKyMgUG9y
dGFibHkgdW5zZXQgVkFSLgorYXNfZm5fdW5zZXQgKCkKK3sKKyAgeyBldmFsICQxPTsgdW5zZXQg
JDE7fQorfQorYXNfdW5zZXQ9YXNfZm5fdW5zZXQKKyMgYXNfZm5fYXBwZW5kIFZBUiBWQUxVRQor
IyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tCisjIEFwcGVuZCB0aGUgdGV4dCBpbiBWQUxVRSB0byB0
aGUgZW5kIG9mIHRoZSBkZWZpbml0aW9uIGNvbnRhaW5lZCBpbiBWQVIuIFRha2UKKyMgYWR2YW50
YWdlIG9mIGFueSBzaGVsbCBvcHRpbWl6YXRpb25zIHRoYXQgYWxsb3cgYW1vcnRpemVkIGxpbmVh
ciBncm93dGggb3ZlcgorIyByZXBlYXRlZCBhcHBlbmRzLCBpbnN0ZWFkIG9mIHRoZSB0eXBpY2Fs
IHF1YWRyYXRpYyBncm93dGggcHJlc2VudCBpbiBuYWl2ZQorIyBpbXBsZW1lbnRhdGlvbnMuCitp
ZiAoZXZhbCAiYXNfdmFyPTE7IGFzX3Zhcis9MjsgdGVzdCB4XCRhc192YXIgPSB4MTIiKSAyPi9k
ZXYvbnVsbDsgdGhlbiA6CisgIGV2YWwgJ2FzX2ZuX2FwcGVuZCAoKQorICB7CisgICAgZXZhbCAk
MSs9XCQyCisgIH0nCitlbHNlCisgIGFzX2ZuX2FwcGVuZCAoKQorICB7CisgICAgZXZhbCAkMT1c
JCQxXCQyCisgIH0KK2ZpICMgYXNfZm5fYXBwZW5kCisKKyMgYXNfZm5fYXJpdGggQVJHLi4uCisj
IC0tLS0tLS0tLS0tLS0tLS0tLQorIyBQZXJmb3JtIGFyaXRobWV0aWMgZXZhbHVhdGlvbiBvbiB0
aGUgQVJHcywgYW5kIHN0b3JlIHRoZSByZXN1bHQgaW4gdGhlCisjIGdsb2JhbCAkYXNfdmFsLiBU
YWtlIGFkdmFudGFnZSBvZiBzaGVsbHMgdGhhdCBjYW4gYXZvaWQgZm9ya3MuIFRoZSBhcmd1bWVu
dHMKKyMgbXVzdCBiZSBwb3J0YWJsZSBhY3Jvc3MgJCgoKSkgYW5kIGV4cHIuCitpZiAoZXZhbCAi
dGVzdCBcJCgoIDEgKyAxICkpID0gMiIpIDI+L2Rldi9udWxsOyB0aGVuIDoKKyAgZXZhbCAnYXNf
Zm5fYXJpdGggKCkKKyAgeworICAgIGFzX3ZhbD0kKCggJCogKSkKKyAgfScKK2Vsc2UKKyAgYXNf
Zm5fYXJpdGggKCkKKyAgeworICAgIGFzX3ZhbD1gZXhwciAiJEAiIHx8IHRlc3QgJD8gLWVxIDFg
CisgIH0KK2ZpICMgYXNfZm5fYXJpdGgKKworCitpZiBleHByIGEgOiAnXChhXCknID4vZGV2L251
bGwgMj4mMSAmJgorICAgdGVzdCAiWGBleHByIDAwMDAxIDogJy4qXCguLi5cKSdgIiA9IFgwMDE7
IHRoZW4KKyAgYXNfZXhwcj1leHByCitlbHNlCisgIGFzX2V4cHI9ZmFsc2UKK2ZpCisKK2lmIChi
YXNlbmFtZSAtLSAvKSA+L2Rldi9udWxsIDI+JjEgJiYgdGVzdCAiWGBiYXNlbmFtZSAtLSAvIDI+
JjFgIiA9ICJYLyI7IHRoZW4KKyAgYXNfYmFzZW5hbWU9YmFzZW5hbWUKK2Vsc2UKKyAgYXNfYmFz
ZW5hbWU9ZmFsc2UKK2ZpCisKK2lmIChhc19kaXI9YGRpcm5hbWUgLS0gL2AgJiYgdGVzdCAiWCRh
c19kaXIiID0gWC8pID4vZGV2L251bGwgMj4mMTsgdGhlbgorICBhc19kaXJuYW1lPWRpcm5hbWUK
K2Vsc2UKKyAgYXNfZGlybmFtZT1mYWxzZQorZmkKKworYXNfbWU9YCRhc19iYXNlbmFtZSAtLSAi
JDAiIHx8CiskYXNfZXhwciBYLyIkMCIgOiAnLiovXChbXi9dW14vXSpcKS8qJCcgXHwgXAorCSBY
IiQwIiA6ICdYXCgvL1wpJCcgXHwgXAorCSBYIiQwIiA6ICdYXCgvXCknIFx8IC4gMj4vZGV2L251
bGwgfHwKKyRhc19lY2hvIFgvIiQwIiB8CisgICAgc2VkICcvXi4qXC9cKFteL11bXi9dKlwpXC8q
JC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cL1wpJC97CisJICAg
IHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhcL1woXC9cKS4qL3sKKwkgICAgcy8vXDEvCisJ
ICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorCisjIEF2b2lkIGRlcGVuZGluZyB1cG9uIENo
YXJhY3RlciBSYW5nZXMuCithc19jcl9sZXR0ZXJzPSdhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3h5
eicKK2FzX2NyX0xFVFRFUlM9J0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaJworYXNfY3JfTGV0
dGVycz0kYXNfY3JfbGV0dGVycyRhc19jcl9MRVRURVJTCithc19jcl9kaWdpdHM9JzAxMjM0NTY3
ODknCithc19jcl9hbG51bT0kYXNfY3JfTGV0dGVycyRhc19jcl9kaWdpdHMKKworRUNIT19DPSBF
Q0hPX049IEVDSE9fVD0KK2Nhc2UgYGVjaG8gLW4geGAgaW4gIygoKCgoCistbiopCisgIGNhc2Ug
YGVjaG8gJ3h5XGMnYCBpbgorICAqYyopIEVDSE9fVD0nCSc7OwkjIEVDSE9fVCBpcyBzaW5nbGUg
dGFiIGNoYXJhY3Rlci4KKyAgeHkpICBFQ0hPX0M9J1xjJzs7CisgICopICAgZWNobyBgZWNobyBr
c2g4OCBidWcgb24gQUlYIDYuMWAgPiAvZGV2L251bGwKKyAgICAgICBFQ0hPX1Q9JwknOzsKKyAg
ZXNhYzs7CisqKQorICBFQ0hPX049Jy1uJzs7Citlc2FjCisKK3JtIC1mIGNvbmYkJCBjb25mJCQu
ZXhlIGNvbmYkJC5maWxlCitpZiB0ZXN0IC1kIGNvbmYkJC5kaXI7IHRoZW4KKyAgcm0gLWYgY29u
ZiQkLmRpci9jb25mJCQuZmlsZQorZWxzZQorICBybSAtZiBjb25mJCQuZGlyCisgIG1rZGlyIGNv
bmYkJC5kaXIgMj4vZGV2L251bGwKK2ZpCitpZiAoZWNobyA+Y29uZiQkLmZpbGUpIDI+L2Rldi9u
dWxsOyB0aGVuCisgIGlmIGxuIC1zIGNvbmYkJC5maWxlIGNvbmYkJCAyPi9kZXYvbnVsbDsgdGhl
bgorICAgIGFzX2xuX3M9J2xuIC1zJworICAgICMgLi4uIGJ1dCB0aGVyZSBhcmUgdHdvIGdvdGNo
YXM6CisgICAgIyAxKSBPbiBNU1lTLCBib3RoIGBsbiAtcyBmaWxlIGRpcicgYW5kIGBsbiBmaWxl
IGRpcicgZmFpbC4KKyAgICAjIDIpIERKR1BQIDwgMi4wNCBoYXMgbm8gc3ltbGlua3M7IGBsbiAt
cycgY3JlYXRlcyBhIHdyYXBwZXIgZXhlY3V0YWJsZS4KKyAgICAjIEluIGJvdGggY2FzZXMsIHdl
IGhhdmUgdG8gZGVmYXVsdCB0byBgY3AgLXAnLgorICAgIGxuIC1zIGNvbmYkJC5maWxlIGNvbmYk
JC5kaXIgMj4vZGV2L251bGwgJiYgdGVzdCAhIC1mIGNvbmYkJC5leGUgfHwKKyAgICAgIGFzX2xu
X3M9J2NwIC1wJworICBlbGlmIGxuIGNvbmYkJC5maWxlIGNvbmYkJCAyPi9kZXYvbnVsbDsgdGhl
bgorICAgIGFzX2xuX3M9bG4KKyAgZWxzZQorICAgIGFzX2xuX3M9J2NwIC1wJworICBmaQorZWxz
ZQorICBhc19sbl9zPSdjcCAtcCcKK2ZpCitybSAtZiBjb25mJCQgY29uZiQkLmV4ZSBjb25mJCQu
ZGlyL2NvbmYkJC5maWxlIGNvbmYkJC5maWxlCitybWRpciBjb25mJCQuZGlyIDI+L2Rldi9udWxs
CisKKworIyBhc19mbl9ta2Rpcl9wCisjIC0tLS0tLS0tLS0tLS0KKyMgQ3JlYXRlICIkYXNfZGly
IiBhcyBhIGRpcmVjdG9yeSwgaW5jbHVkaW5nIHBhcmVudHMgaWYgbmVjZXNzYXJ5LgorYXNfZm5f
bWtkaXJfcCAoKQoreworCisgIGNhc2UgJGFzX2RpciBpbiAjKAorICAtKikgYXNfZGlyPS4vJGFz
X2Rpcjs7CisgIGVzYWMKKyAgdGVzdCAtZCAiJGFzX2RpciIgfHwgZXZhbCAkYXNfbWtkaXJfcCB8
fCB7CisgICAgYXNfZGlycz0KKyAgICB3aGlsZSA6OyBkbworICAgICAgY2FzZSAkYXNfZGlyIGlu
ICMoCisgICAgICAqXCcqKSBhc19xZGlyPWAkYXNfZWNobyAiJGFzX2RpciIgfCBzZWQgInMvJy8n
XFxcXFxcXFwnJy9nImA7OyAjJygKKyAgICAgICopIGFzX3FkaXI9JGFzX2Rpcjs7CisgICAgICBl
c2FjCisgICAgICBhc19kaXJzPSInJGFzX3FkaXInICRhc19kaXJzIgorICAgICAgYXNfZGlyPWAk
YXNfZGlybmFtZSAtLSAiJGFzX2RpciIgfHwKKyRhc19leHByIFgiJGFzX2RpciIgOiAnWFwoLipb
Xi9dXCkvLypbXi9dW14vXSovKiQnIFx8IFwKKwkgWCIkYXNfZGlyIiA6ICdYXCgvL1wpW14vXScg
XHwgXAorCSBYIiRhc19kaXIiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJGFzX2RpciIgOiAnWFwo
L1wpJyBcfCAuIDI+L2Rldi9udWxsIHx8CiskYXNfZWNobyBYIiRhc19kaXIiIHwKKyAgICBzZWQg
Jy9eWFwoLipbXi9dXClcL1wvKlteL11bXi9dKlwvKiQveworCSAgICBzLy9cMS8KKwkgICAgcQor
CSAgfQorCSAgL15YXChcL1wvXClbXi9dLioveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQor
CSAgL15YXChcL1wvXCkkL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIC9eWFwoXC9c
KS4qL3sKKwkgICAgcy8vXDEvCisJICAgIHEKKwkgIH0KKwkgIHMvLiovLi87IHEnYAorICAgICAg
dGVzdCAtZCAiJGFzX2RpciIgJiYgYnJlYWsKKyAgICBkb25lCisgICAgdGVzdCAteiAiJGFzX2Rp
cnMiIHx8IGV2YWwgIm1rZGlyICRhc19kaXJzIgorICB9IHx8IHRlc3QgLWQgIiRhc19kaXIiIHx8
IGFzX2ZuX2Vycm9yICQ/ICJjYW5ub3QgY3JlYXRlIGRpcmVjdG9yeSAkYXNfZGlyIgorCisKK30g
IyBhc19mbl9ta2Rpcl9wCitpZiBta2RpciAtcCAuIDI+L2Rldi9udWxsOyB0aGVuCisgIGFzX21r
ZGlyX3A9J21rZGlyIC1wICIkYXNfZGlyIicKK2Vsc2UKKyAgdGVzdCAtZCAuLy1wICYmIHJtZGly
IC4vLXAKKyAgYXNfbWtkaXJfcD1mYWxzZQorZmkKKworaWYgdGVzdCAteCAvID4vZGV2L251bGwg
Mj4mMTsgdGhlbgorICBhc190ZXN0X3g9J3Rlc3QgLXgnCitlbHNlCisgIGlmIGxzIC1kTCAvID4v
ZGV2L251bGwgMj4mMTsgdGhlbgorICAgIGFzX2xzX0xfb3B0aW9uPUwKKyAgZWxzZQorICAgIGFz
X2xzX0xfb3B0aW9uPQorICBmaQorICBhc190ZXN0X3g9JworICAgIGV2YWwgc2ggLWMgJ1wnJwor
ICAgICAgaWYgdGVzdCAtZCAiJDEiOyB0aGVuCisJdGVzdCAtZCAiJDEvLiI7CisgICAgICBlbHNl
CisJY2FzZSAkMSBpbiAjKAorCS0qKXNldCAiLi8kMSI7OworCWVzYWM7CisJY2FzZSBgbHMgLWxk
JyRhc19sc19MX29wdGlvbicgIiQxIiAyPi9kZXYvbnVsbGAgaW4gIygoCisJPz8/W3N4XSopOjs7
KilmYWxzZTs7ZXNhYztmaQorICAgICdcJycgc2gKKyAgJworZmkKK2FzX2V4ZWN1dGFibGVfcD0k
YXNfdGVzdF94CisKKyMgU2VkIGV4cHJlc3Npb24gdG8gbWFwIGEgc3RyaW5nIG9udG8gYSB2YWxp
ZCBDUFAgbmFtZS4KK2FzX3RyX2NwcD0iZXZhbCBzZWQgJ3klKiRhc19jcl9sZXR0ZXJzJVAkYXNf
Y3JfTEVUVEVSUyU7cyVbXl8kYXNfY3JfYWxudW1dJV8lZyciCisKKyMgU2VkIGV4cHJlc3Npb24g
dG8gbWFwIGEgc3RyaW5nIG9udG8gYSB2YWxpZCB2YXJpYWJsZSBuYW1lLgorYXNfdHJfc2g9ImV2
YWwgc2VkICd5JSorJXBwJTtzJVteXyRhc19jcl9hbG51bV0lXyVnJyIKKworCitleGVjIDY+JjEK
KyMjIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICMjCisjIyBNYWluIGJvZHkg
b2YgJENPTkZJR19TVEFUVVMgc2NyaXB0LiAjIworIyMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gIyMKK19BU0VPRgordGVzdCAkYXNfd3JpdGVfZmFpbCA9IDAgJiYgY2htb2Qg
K3ggJENPTkZJR19TVEFUVVMgfHwgYWNfd3JpdGVfZmFpbD0xCisKK2NhdCA+PiRDT05GSUdfU1RB
VFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKyMgU2F2ZSB0aGUgbG9nIG1lc3NhZ2Us
IHRvIGtlZXAgJDAgYW5kIHNvIG9uIG1lYW5pbmdmdWwsIGFuZCB0bworIyByZXBvcnQgYWN0dWFs
IGlucHV0IHZhbHVlcyBvZiBDT05GSUdfRklMRVMgZXRjLiBpbnN0ZWFkIG9mIHRoZWlyCisjIHZh
bHVlcyBhZnRlciBvcHRpb25zIGhhbmRsaW5nLgorYWNfbG9nPSIKK1RoaXMgZmlsZSB3YXMgZXh0
ZW5kZWQgYnkgWGVuIEh5cGVydmlzb3IgJGFzX21lIDQuMiwgd2hpY2ggd2FzCitnZW5lcmF0ZWQg
YnkgR05VIEF1dG9jb25mIDIuNjguICBJbnZvY2F0aW9uIGNvbW1hbmQgbGluZSB3YXMKKworICBD
T05GSUdfRklMRVMgICAgPSAkQ09ORklHX0ZJTEVTCisgIENPTkZJR19IRUFERVJTICA9ICRDT05G
SUdfSEVBREVSUworICBDT05GSUdfTElOS1MgICAgPSAkQ09ORklHX0xJTktTCisgIENPTkZJR19D
T01NQU5EUyA9ICRDT05GSUdfQ09NTUFORFMKKyAgJCAkMCAkQAorCitvbiBgKGhvc3RuYW1lIHx8
IHVuYW1lIC1uKSAyPi9kZXYvbnVsbCB8IHNlZCAxcWAKKyIKKworX0FDRU9GCisKK2Nhc2UgJGFj
X2NvbmZpZ19maWxlcyBpbiAqIgorIiopIHNldCB4ICRhY19jb25maWdfZmlsZXM7IHNoaWZ0OyBh
Y19jb25maWdfZmlsZXM9JCo7OworZXNhYworCitjYXNlICRhY19jb25maWdfaGVhZGVycyBpbiAq
IgorIiopIHNldCB4ICRhY19jb25maWdfaGVhZGVyczsgc2hpZnQ7IGFjX2NvbmZpZ19oZWFkZXJz
PSQqOzsKK2VzYWMKKworCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0
ZV9mYWlsPTEKKyMgRmlsZXMgdGhhdCBjb25maWcuc3RhdHVzIHdhcyBtYWRlIGZvci4KK2NvbmZp
Z19maWxlcz0iJGFjX2NvbmZpZ19maWxlcyIKK2NvbmZpZ19oZWFkZXJzPSIkYWNfY29uZmlnX2hl
YWRlcnMiCisKK19BQ0VPRgorCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNf
d3JpdGVfZmFpbD0xCithY19jc191c2FnZT0iXAorXGAkYXNfbWUnIGluc3RhbnRpYXRlcyBmaWxl
cyBhbmQgb3RoZXIgY29uZmlndXJhdGlvbiBhY3Rpb25zCitmcm9tIHRlbXBsYXRlcyBhY2NvcmRp
bmcgdG8gdGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbi4gIFVubGVzcyB0aGUgZmlsZXMKK2FuZCBh
Y3Rpb25zIGFyZSBzcGVjaWZpZWQgYXMgVEFHcywgYWxsIGFyZSBpbnN0YW50aWF0ZWQgYnkgZGVm
YXVsdC4KKworVXNhZ2U6ICQwIFtPUFRJT05dLi4uIFtUQUddLi4uCisKKyAgLWgsIC0taGVscCAg
ICAgICBwcmludCB0aGlzIGhlbHAsIHRoZW4gZXhpdAorICAtViwgLS12ZXJzaW9uICAgIHByaW50
IHZlcnNpb24gbnVtYmVyIGFuZCBjb25maWd1cmF0aW9uIHNldHRpbmdzLCB0aGVuIGV4aXQKKyAg
ICAgIC0tY29uZmlnICAgICBwcmludCBjb25maWd1cmF0aW9uLCB0aGVuIGV4aXQKKyAgLXEsIC0t
cXVpZXQsIC0tc2lsZW50CisgICAgICAgICAgICAgICAgICAgZG8gbm90IHByaW50IHByb2dyZXNz
IG1lc3NhZ2VzCisgIC1kLCAtLWRlYnVnICAgICAgZG9uJ3QgcmVtb3ZlIHRlbXBvcmFyeSBmaWxl
cworICAgICAgLS1yZWNoZWNrICAgIHVwZGF0ZSAkYXNfbWUgYnkgcmVjb25maWd1cmluZyBpbiB0
aGUgc2FtZSBjb25kaXRpb25zCisgICAgICAtLWZpbGU9RklMRVs6VEVNUExBVEVdCisgICAgICAg
ICAgICAgICAgICAgaW5zdGFudGlhdGUgdGhlIGNvbmZpZ3VyYXRpb24gZmlsZSBGSUxFCisgICAg
ICAtLWhlYWRlcj1GSUxFWzpURU1QTEFURV0KKyAgICAgICAgICAgICAgICAgICBpbnN0YW50aWF0
ZSB0aGUgY29uZmlndXJhdGlvbiBoZWFkZXIgRklMRQorCitDb25maWd1cmF0aW9uIGZpbGVzOgor
JGNvbmZpZ19maWxlcworCitDb25maWd1cmF0aW9uIGhlYWRlcnM6CiskY29uZmlnX2hlYWRlcnMK
KworUmVwb3J0IGJ1Z3MgdG8gPHhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tPi4iCisKK19B
Q0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCith
Y19jc19jb25maWc9ImAkYXNfZWNobyAiJGFjX2NvbmZpZ3VyZV9hcmdzIiB8IHNlZCAncy9eIC8v
OyBzL1tcXCIiXGBcJF0vXFxcXCYvZydgIgorYWNfY3NfdmVyc2lvbj0iXFwKK1hlbiBIeXBlcnZp
c29yIGNvbmZpZy5zdGF0dXMgNC4yCitjb25maWd1cmVkIGJ5ICQwLCBnZW5lcmF0ZWQgYnkgR05V
IEF1dG9jb25mIDIuNjgsCisgIHdpdGggb3B0aW9ucyBcXCJcJGFjX2NzX2NvbmZpZ1xcIgorCitD
b3B5cmlnaHQgKEMpIDIwMTAgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCitUaGlzIGNv
bmZpZy5zdGF0dXMgc2NyaXB0IGlzIGZyZWUgc29mdHdhcmU7IHRoZSBGcmVlIFNvZnR3YXJlIEZv
dW5kYXRpb24KK2dpdmVzIHVubGltaXRlZCBwZXJtaXNzaW9uIHRvIGNvcHksIGRpc3RyaWJ1dGUg
YW5kIG1vZGlmeSBpdC4iCisKK2FjX3B3ZD0nJGFjX3B3ZCcKK3NyY2Rpcj0nJHNyY2RpcicKK0lO
U1RBTEw9JyRJTlNUQUxMJwordGVzdCAtbiAiXCRBV0siIHx8IEFXSz1hd2sKK19BQ0VPRgorCitj
YXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisjIFRoZSBk
ZWZhdWx0IGxpc3RzIGFwcGx5IGlmIHRoZSB1c2VyIGRvZXMgbm90IHNwZWNpZnkgYW55IGZpbGUu
CithY19uZWVkX2RlZmF1bHRzPToKK3doaWxlIHRlc3QgJCMgIT0gMAorZG8KKyAgY2FzZSAkMSBp
bgorICAtLSo9PyopCisgICAgYWNfb3B0aW9uPWBleHByICJYJDEiIDogJ1hcKFtePV0qXCk9J2AK
KyAgICBhY19vcHRhcmc9YGV4cHIgIlgkMSIgOiAnWFtePV0qPVwoLipcKSdgCisgICAgYWNfc2hp
ZnQ9OgorICAgIDs7CisgIC0tKj0pCisgICAgYWNfb3B0aW9uPWBleHByICJYJDEiIDogJ1hcKFte
PV0qXCk9J2AKKyAgICBhY19vcHRhcmc9CisgICAgYWNfc2hpZnQ9OgorICAgIDs7CisgICopCisg
ICAgYWNfb3B0aW9uPSQxCisgICAgYWNfb3B0YXJnPSQyCisgICAgYWNfc2hpZnQ9c2hpZnQKKyAg
ICA7OworICBlc2FjCisKKyAgY2FzZSAkYWNfb3B0aW9uIGluCisgICMgSGFuZGxpbmcgb2YgdGhl
IG9wdGlvbnMuCisgIC1yZWNoZWNrIHwgLS1yZWNoZWNrIHwgLS1yZWNoZWMgfCAtLXJlY2hlIHwg
LS1yZWNoIHwgLS1yZWMgfCAtLXJlIHwgLS1yKQorICAgIGFjX2NzX3JlY2hlY2s9OiA7OworICAt
LXZlcnNpb24gfCAtLXZlcnNpbyB8IC0tdmVyc2kgfCAtLXZlcnMgfCAtLXZlciB8IC0tdmUgfCAt
LXYgfCAtViApCisgICAgJGFzX2VjaG8gIiRhY19jc192ZXJzaW9uIjsgZXhpdCA7OworICAtLWNv
bmZpZyB8IC0tY29uZmkgfCAtLWNvbmYgfCAtLWNvbiB8IC0tY28gfCAtLWMgKQorICAgICRhc19l
Y2hvICIkYWNfY3NfY29uZmlnIjsgZXhpdCA7OworICAtLWRlYnVnIHwgLS1kZWJ1IHwgLS1kZWIg
fCAtLWRlIHwgLS1kIHwgLWQgKQorICAgIGRlYnVnPTogOzsKKyAgLS1maWxlIHwgLS1maWwgfCAt
LWZpIHwgLS1mICkKKyAgICAkYWNfc2hpZnQKKyAgICBjYXNlICRhY19vcHRhcmcgaW4KKyAgICAq
XCcqKSBhY19vcHRhcmc9YCRhc19lY2hvICIkYWNfb3B0YXJnIiB8IHNlZCAicy8nLydcXFxcXFxc
XCcnL2ciYCA7OworICAgICcnKSBhc19mbl9lcnJvciAkPyAibWlzc2luZyBmaWxlIGFyZ3VtZW50
IiA7OworICAgIGVzYWMKKyAgICBhc19mbl9hcHBlbmQgQ09ORklHX0ZJTEVTICIgJyRhY19vcHRh
cmcnIgorICAgIGFjX25lZWRfZGVmYXVsdHM9ZmFsc2U7OworICAtLWhlYWRlciB8IC0taGVhZGUg
fCAtLWhlYWQgfCAtLWhlYSApCisgICAgJGFjX3NoaWZ0CisgICAgY2FzZSAkYWNfb3B0YXJnIGlu
CisgICAgKlwnKikgYWNfb3B0YXJnPWAkYXNfZWNobyAiJGFjX29wdGFyZyIgfCBzZWQgInMvJy8n
XFxcXFxcXFwnJy9nImAgOzsKKyAgICBlc2FjCisgICAgYXNfZm5fYXBwZW5kIENPTkZJR19IRUFE
RVJTICIgJyRhY19vcHRhcmcnIgorICAgIGFjX25lZWRfZGVmYXVsdHM9ZmFsc2U7OworICAtLWhl
IHwgLS1oKQorICAgICMgQ29uZmxpY3QgYmV0d2VlbiAtLWhlbHAgYW5kIC0taGVhZGVyCisgICAg
YXNfZm5fZXJyb3IgJD8gImFtYmlndW91cyBvcHRpb246IFxgJDEnCitUcnkgXGAkMCAtLWhlbHAn
IGZvciBtb3JlIGluZm9ybWF0aW9uLiI7OworICAtLWhlbHAgfCAtLWhlbCB8IC1oICkKKyAgICAk
YXNfZWNobyAiJGFjX2NzX3VzYWdlIjsgZXhpdCA7OworICAtcSB8IC1xdWlldCB8IC0tcXVpZXQg
fCAtLXF1aWUgfCAtLXF1aSB8IC0tcXUgfCAtLXEgXAorICB8IC1zaWxlbnQgfCAtLXNpbGVudCB8
IC0tc2lsZW4gfCAtLXNpbGUgfCAtLXNpbCB8IC0tc2kgfCAtLXMpCisgICAgYWNfY3Nfc2lsZW50
PTogOzsKKworICAjIFRoaXMgaXMgYW4gZXJyb3IuCisgIC0qKSBhc19mbl9lcnJvciAkPyAidW5y
ZWNvZ25pemVkIG9wdGlvbjogXGAkMScKK1RyeSBcYCQwIC0taGVscCcgZm9yIG1vcmUgaW5mb3Jt
YXRpb24uIiA7OworCisgICopIGFzX2ZuX2FwcGVuZCBhY19jb25maWdfdGFyZ2V0cyAiICQxIgor
ICAgICBhY19uZWVkX2RlZmF1bHRzPWZhbHNlIDs7CisKKyAgZXNhYworICBzaGlmdAorZG9uZQor
CithY19jb25maWd1cmVfZXh0cmFfYXJncz0KKworaWYgJGFjX2NzX3NpbGVudDsgdGhlbgorICBl
eGVjIDY+L2Rldi9udWxsCisgIGFjX2NvbmZpZ3VyZV9leHRyYV9hcmdzPSIkYWNfY29uZmlndXJl
X2V4dHJhX2FyZ3MgLS1zaWxlbnQiCitmaQorCitfQUNFT0YKK2NhdCA+PiRDT05GSUdfU1RBVFVT
IDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQoraWYgXCRhY19jc19yZWNoZWNrOyB0aGVuCisg
IHNldCBYICckU0hFTEwnICckMCcgJGFjX2NvbmZpZ3VyZV9hcmdzIFwkYWNfY29uZmlndXJlX2V4
dHJhX2FyZ3MgLS1uby1jcmVhdGUgLS1uby1yZWN1cnNpb24KKyAgc2hpZnQKKyAgXCRhc19lY2hv
ICJydW5uaW5nIENPTkZJR19TSEVMTD0kU0hFTEwgXCQqIiA+JjYKKyAgQ09ORklHX1NIRUxMPSck
U0hFTEwnCisgIGV4cG9ydCBDT05GSUdfU0hFTEwKKyAgZXhlYyAiXCRAIgorZmkKKworX0FDRU9G
CitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCitleGVj
IDU+PmNvbmZpZy5sb2cKK3sKKyAgZWNobworICBzZWQgJ2g7cy8uLy0vZztzL14uLi4vIyMgLztz
Ly4uLiQvICMjLztwO3g7cDt4JyA8PF9BU0JPWAorIyMgUnVubmluZyAkYXNfbWUuICMjCitfQVNC
T1gKKyAgJGFzX2VjaG8gIiRhY19sb2ciCit9ID4mNQorCitfQUNFT0YKK2NhdCA+PiRDT05GSUdf
U1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorX0FDRU9GCisKK2NhdCA+PiRDT05G
SUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKKworIyBIYW5kbGluZyBvZiBh
cmd1bWVudHMuCitmb3IgYWNfY29uZmlnX3RhcmdldCBpbiAkYWNfY29uZmlnX3RhcmdldHMKK2Rv
CisgIGNhc2UgJGFjX2NvbmZpZ190YXJnZXQgaW4KKyAgICAiLi4vY29uZmlnL1Rvb2xzLm1rIikg
Q09ORklHX0ZJTEVTPSIkQ09ORklHX0ZJTEVTIC4uL2NvbmZpZy9Ub29scy5tayIgOzsKKyAgICAi
Y29uZmlnLmgiKSBDT05GSUdfSEVBREVSUz0iJENPTkZJR19IRUFERVJTIGNvbmZpZy5oIiA7Owor
CisgICopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIGFyZ3VtZW50OiBcYCRhY19jb25maWdfdGFy
Z2V0JyIgIiRMSU5FTk8iIDU7OworICBlc2FjCitkb25lCisKKworIyBJZiB0aGUgdXNlciBkaWQg
bm90IHVzZSB0aGUgYXJndW1lbnRzIHRvIHNwZWNpZnkgdGhlIGl0ZW1zIHRvIGluc3RhbnRpYXRl
LAorIyB0aGVuIHRoZSBlbnZ2YXIgaW50ZXJmYWNlIGlzIHVzZWQuICBTZXQgb25seSB0aG9zZSB0
aGF0IGFyZSBub3QuCisjIFdlIHVzZSB0aGUgbG9uZyBmb3JtIGZvciB0aGUgZGVmYXVsdCBhc3Np
Z25tZW50IGJlY2F1c2Ugb2YgYW4gZXh0cmVtZWx5CisjIGJpemFycmUgYnVnIG9uIFN1bk9TIDQu
MS4zLgoraWYgJGFjX25lZWRfZGVmYXVsdHM7IHRoZW4KKyAgdGVzdCAiJHtDT05GSUdfRklMRVMr
c2V0fSIgPSBzZXQgfHwgQ09ORklHX0ZJTEVTPSRjb25maWdfZmlsZXMKKyAgdGVzdCAiJHtDT05G
SUdfSEVBREVSUytzZXR9IiA9IHNldCB8fCBDT05GSUdfSEVBREVSUz0kY29uZmlnX2hlYWRlcnMK
K2ZpCisKKyMgSGF2ZSBhIHRlbXBvcmFyeSBkaXJlY3RvcnkgZm9yIGNvbnZlbmllbmNlLiAgTWFr
ZSBpdCBpbiB0aGUgYnVpbGQgdHJlZQorIyBzaW1wbHkgYmVjYXVzZSB0aGVyZSBpcyBubyByZWFz
b24gYWdhaW5zdCBoYXZpbmcgaXQgaGVyZSwgYW5kIGluIGFkZGl0aW9uLAorIyBjcmVhdGluZyBh
bmQgbW92aW5nIGZpbGVzIGZyb20gL3RtcCBjYW4gc29tZXRpbWVzIGNhdXNlIHByb2JsZW1zLgor
IyBIb29rIGZvciBpdHMgcmVtb3ZhbCB1bmxlc3MgZGVidWdnaW5nLgorIyBOb3RlIHRoYXQgdGhl
cmUgaXMgYSBzbWFsbCB3aW5kb3cgaW4gd2hpY2ggdGhlIGRpcmVjdG9yeSB3aWxsIG5vdCBiZSBj
bGVhbmVkOgorIyBhZnRlciBpdHMgY3JlYXRpb24gYnV0IGJlZm9yZSBpdHMgbmFtZSBoYXMgYmVl
biBhc3NpZ25lZCB0byBgJHRtcCcuCiskZGVidWcgfHwKK3sKKyAgdG1wPSBhY190bXA9CisgIHRy
YXAgJ2V4aXRfc3RhdHVzPSQ/CisgIDogIiR7YWNfdG1wOj0kdG1wfSIKKyAgeyB0ZXN0ICEgLWQg
IiRhY190bXAiIHx8IHJtIC1mciAiJGFjX3RtcCI7IH0gJiYgZXhpdCAkZXhpdF9zdGF0dXMKKycg
MAorICB0cmFwICdhc19mbl9leGl0IDEnIDEgMiAxMyAxNQorfQorIyBDcmVhdGUgYSAoc2VjdXJl
KSB0bXAgZGlyZWN0b3J5IGZvciB0bXAgZmlsZXMuCisKK3sKKyAgdG1wPWAodW1hc2sgMDc3ICYm
IG1rdGVtcCAtZCAiLi9jb25mWFhYWFhYIikgMj4vZGV2L251bGxgICYmCisgIHRlc3QgLWQgIiR0
bXAiCit9ICB8fAoreworICB0bXA9Li9jb25mJCQtJFJBTkRPTQorICAodW1hc2sgMDc3ICYmIG1r
ZGlyICIkdG1wIikKK30gfHwgYXNfZm5fZXJyb3IgJD8gImNhbm5vdCBjcmVhdGUgYSB0ZW1wb3Jh
cnkgZGlyZWN0b3J5IGluIC4iICIkTElORU5PIiA1CithY190bXA9JHRtcAorCisjIFNldCB1cCB0
aGUgc2NyaXB0cyBmb3IgQ09ORklHX0ZJTEVTIHNlY3Rpb24uCisjIE5vIG5lZWQgdG8gZ2VuZXJh
dGUgdGhlbSBpZiB0aGVyZSBhcmUgbm8gQ09ORklHX0ZJTEVTLgorIyBUaGlzIGhhcHBlbnMgZm9y
IGluc3RhbmNlIHdpdGggYC4vY29uZmlnLnN0YXR1cyBjb25maWcuaCcuCitpZiB0ZXN0IC1uICIk
Q09ORklHX0ZJTEVTIjsgdGhlbgorCisKK2FjX2NyPWBlY2hvIFggfCB0ciBYICdcMDE1J2AKKyMg
T24gY3lnd2luLCBiYXNoIGNhbiBlYXQgXHIgaW5zaWRlIGBgIGlmIHRoZSB1c2VyIHJlcXVlc3Rl
ZCBpZ25jci4KKyMgQnV0IHdlIGtub3cgb2Ygbm8gb3RoZXIgc2hlbGwgd2hlcmUgYWNfY3Igd291
bGQgYmUgZW1wdHkgYXQgdGhpcworIyBwb2ludCwgc28gd2UgY2FuIHVzZSBhIGJhc2hpc20gYXMg
YSBmYWxsYmFjay4KK2lmIHRlc3QgIngkYWNfY3IiID0geDsgdGhlbgorICBldmFsIGFjX2NyPVwk
XCdcXHJcJworZmkKK2FjX2NzX2F3a19jcj1gJEFXSyAnQkVHSU4geyBwcmludCAiYVxyYiIgfScg
PC9kZXYvbnVsbCAyPi9kZXYvbnVsbGAKK2lmIHRlc3QgIiRhY19jc19hd2tfY3IiID0gImEke2Fj
X2NyfWIiOyB0aGVuCisgIGFjX2NzX2F3a19jcj0nXFxyJworZWxzZQorICBhY19jc19hd2tfY3I9
JGFjX2NyCitmaQorCitlY2hvICdCRUdJTiB7JyA+IiRhY190bXAvc3ViczEuYXdrIiAmJgorX0FD
RU9GCisKKworeworICBlY2hvICJjYXQgPmNvbmYkJHN1YnMuYXdrIDw8X0FDRU9GIiAmJgorICBl
Y2hvICIkYWNfc3Vic3RfdmFycyIgfCBzZWQgJ3MvLiovJiEkJiRhY19kZWxpbS8nICYmCisgIGVj
aG8gIl9BQ0VPRiIKK30gPmNvbmYkJHN1YnMuc2ggfHwKKyAgYXNfZm5fZXJyb3IgJD8gImNvdWxk
IG5vdCBtYWtlICRDT05GSUdfU1RBVFVTIiAiJExJTkVOTyIgNQorYWNfZGVsaW1fbnVtPWBlY2hv
ICIkYWNfc3Vic3RfdmFycyIgfCBncmVwIC1jICdeJ2AKK2FjX2RlbGltPSclIV8hIyAnCitmb3Ig
YWNfbGFzdF90cnkgaW4gZmFsc2UgZmFsc2UgZmFsc2UgZmFsc2UgZmFsc2UgOjsgZG8KKyAgLiAu
L2NvbmYkJHN1YnMuc2ggfHwKKyAgICBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IG1ha2UgJENP
TkZJR19TVEFUVVMiICIkTElORU5PIiA1CisKKyAgYWNfZGVsaW1fbj1gc2VkIC1uICJzLy4qJGFj
X2RlbGltXCQvWC9wIiBjb25mJCRzdWJzLmF3ayB8IGdyZXAgLWMgWGAKKyAgaWYgdGVzdCAkYWNf
ZGVsaW1fbiA9ICRhY19kZWxpbV9udW07IHRoZW4KKyAgICBicmVhaworICBlbGlmICRhY19sYXN0
X3RyeTsgdGhlbgorICAgIGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgbWFrZSAkQ09ORklHX1NU
QVRVUyIgIiRMSU5FTk8iIDUKKyAgZWxzZQorICAgIGFjX2RlbGltPSIkYWNfZGVsaW0hJGFjX2Rl
bGltIF8kYWNfZGVsaW0hISAiCisgIGZpCitkb25lCitybSAtZiBjb25mJCRzdWJzLnNoCisKK2Nh
dCA+PiRDT05GSUdfU1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorY2F0ID4+Ilwk
YWNfdG1wL3N1YnMxLmF3ayIgPDxcXF9BQ0FXSyAmJgorX0FDRU9GCitzZWQgLW4gJworaAorcy9e
L1NbIi87IHMvIS4qLyJdPS8KK3AKK2cKK3MvXlteIV0qIS8vCis6cmVwbAordCByZXBsCitzLyci
JGFjX2RlbGltIickLy8KK3QgZGVsaW0KKzpubAoraAorcy9cKC5cezE0OFx9XCkuLiovXDEvCit0
IG1vcmUxCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC9cXG4iXFwvCitwCituCitiIHJlcGwK
Kzptb3JlMQorcy9bIlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvIlxcLworcAorZworcy8uXHsxNDhc
fS8vCit0IG5sCis6ZGVsaW0KK2gKK3MvXCguXHsxNDhcfVwpLi4qL1wxLwordCBtb3JlMgorcy9b
IlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvIi8KK3AKK2IKKzptb3JlMgorcy9bIlxcXS9cXCYvZzsg
cy9eLyIvOyBzLyQvIlxcLworcAorZworcy8uXHsxNDhcfS8vCit0IGRlbGltCisnIDxjb25mJCRz
dWJzLmF3ayB8IHNlZCAnCisvXlteIiJdL3sKKyAgTgorICBzL1xuLy8KK30KKycgPj4kQ09ORklH
X1NUQVRVUyB8fCBhY193cml0ZV9mYWlsPTEKK3JtIC1mIGNvbmYkJHN1YnMuYXdrCitjYXQgPj4k
Q09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK19BQ0FXSworY2F0ID4+
IlwkYWNfdG1wL3N1YnMxLmF3ayIgPDxfQUNBV0sgJiYKKyAgZm9yIChrZXkgaW4gUykgU19pc19z
ZXRba2V5XSA9IDEKKyAgRlMgPSAiByIKKworfQoreworICBsaW5lID0gJCAwCisgIG5maWVsZHMg
PSBzcGxpdChsaW5lLCBmaWVsZCwgIkAiKQorICBzdWJzdGVkID0gMAorICBsZW4gPSBsZW5ndGgo
ZmllbGRbMV0pCisgIGZvciAoaSA9IDI7IGkgPCBuZmllbGRzOyBpKyspIHsKKyAgICBrZXkgPSBm
aWVsZFtpXQorICAgIGtleWxlbiA9IGxlbmd0aChrZXkpCisgICAgaWYgKFNfaXNfc2V0W2tleV0p
IHsKKyAgICAgIHZhbHVlID0gU1trZXldCisgICAgICBsaW5lID0gc3Vic3RyKGxpbmUsIDEsIGxl
bikgIiIgdmFsdWUgIiIgc3Vic3RyKGxpbmUsIGxlbiArIGtleWxlbiArIDMpCisgICAgICBsZW4g
Kz0gbGVuZ3RoKHZhbHVlKSArIGxlbmd0aChmaWVsZFsrK2ldKQorICAgICAgc3Vic3RlZCA9IDEK
KyAgICB9IGVsc2UKKyAgICAgIGxlbiArPSAxICsga2V5bGVuCisgIH0KKworICBwcmludCBsaW5l
Cit9CisKK19BQ0FXSworX0FDRU9GCitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwg
YWNfd3JpdGVfZmFpbD0xCitpZiBzZWQgInMvJGFjX2NyLy8iIDwgL2Rldi9udWxsID4gL2Rldi9u
dWxsIDI+JjE7IHRoZW4KKyAgc2VkICJzLyRhY19jclwkLy87IHMvJGFjX2NyLyRhY19jc19hd2tf
Y3IvZyIKK2Vsc2UKKyAgY2F0CitmaSA8ICIkYWNfdG1wL3N1YnMxLmF3ayIgPiAiJGFjX3RtcC9z
dWJzLmF3ayIgXAorICB8fCBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IHNldHVwIGNvbmZpZyBm
aWxlcyBtYWNoaW5lcnkiICIkTElORU5PIiA1CitfQUNFT0YKKworIyBWUEFUSCBtYXkgY2F1c2Ug
dHJvdWJsZSB3aXRoIHNvbWUgbWFrZXMsIHNvIHdlIHJlbW92ZSBzb2xlICQoc3JjZGlyKSwKKyMg
JHtzcmNkaXJ9IGFuZCBAc3JjZGlyQCBlbnRyaWVzIGZyb20gVlBBVEggaWYgc3JjZGlyIGlzICIu
Iiwgc3RyaXAgbGVhZGluZyBhbmQKKyMgdHJhaWxpbmcgY29sb25zIGFuZCB0aGVuIHJlbW92ZSB0
aGUgd2hvbGUgbGluZSBpZiBWUEFUSCBiZWNvbWVzIGVtcHR5CisjIChhY3R1YWxseSB3ZSBsZWF2
ZSBhbiBlbXB0eSBsaW5lIHRvIHByZXNlcnZlIGxpbmUgbnVtYmVycykuCitpZiB0ZXN0ICJ4JHNy
Y2RpciIgPSB4LjsgdGhlbgorICBhY192cHN1Yj0nL15bCSBdKlZQQVRIWwkgXSo9WwkgXSovewor
aAorcy8vLworcy9eLzovCitzL1sJIF0qJC86Lworcy86XCQoc3JjZGlyKTovOi9nCitzLzpcJHtz
cmNkaXJ9Oi86L2cKK3MvOkBzcmNkaXJAOi86L2cKK3MvXjoqLy8KK3MvOiokLy8KK3gKK3MvXCg9
WwkgXSpcKS4qL1wxLworRworcy9cbi8vCitzL15bXj1dKj1bCSBdKiQvLworfScKK2ZpCisKK2Nh
dCA+PiRDT05GSUdfU1RBVFVTIDw8XF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2ZpICMgdGVz
dCAtbiAiJENPTkZJR19GSUxFUyIKKworIyBTZXQgdXAgdGhlIHNjcmlwdHMgZm9yIENPTkZJR19I
RUFERVJTIHNlY3Rpb24uCisjIE5vIG5lZWQgdG8gZ2VuZXJhdGUgdGhlbSBpZiB0aGVyZSBhcmUg
bm8gQ09ORklHX0hFQURFUlMuCisjIFRoaXMgaGFwcGVucyBmb3IgaW5zdGFuY2Ugd2l0aCBgLi9j
b25maWcuc3RhdHVzIE1ha2VmaWxlJy4KK2lmIHRlc3QgLW4gIiRDT05GSUdfSEVBREVSUyI7IHRo
ZW4KK2NhdCA+IiRhY190bXAvZGVmaW5lcy5hd2siIDw8XF9BQ0FXSyB8fAorQkVHSU4geworX0FD
RU9GCisKKyMgVHJhbnNmb3JtIGNvbmZkZWZzLmggaW50byBhbiBhd2sgc2NyaXB0IGBkZWZpbmVz
LmF3aycsIGVtYmVkZGVkIGFzCisjIGhlcmUtZG9jdW1lbnQgaW4gY29uZmlnLnN0YXR1cywgdGhh
dCBzdWJzdGl0dXRlcyB0aGUgcHJvcGVyIHZhbHVlcyBpbnRvCisjIGNvbmZpZy5oLmluIHRvIHBy
b2R1Y2UgY29uZmlnLmguCisKKyMgQ3JlYXRlIGEgZGVsaW1pdGVyIHN0cmluZyB0aGF0IGRvZXMg
bm90IGV4aXN0IGluIGNvbmZkZWZzLmgsIHRvIGVhc2UKKyMgaGFuZGxpbmcgb2YgbG9uZyBsaW5l
cy4KK2FjX2RlbGltPSclIV8hIyAnCitmb3IgYWNfbGFzdF90cnkgaW4gZmFsc2UgZmFsc2UgOjsg
ZG8KKyAgYWNfdHQ9YHNlZCAtbiAiLyRhY19kZWxpbS9wIiBjb25mZGVmcy5oYAorICBpZiB0ZXN0
IC16ICIkYWNfdHQiOyB0aGVuCisgICAgYnJlYWsKKyAgZWxpZiAkYWNfbGFzdF90cnk7IHRoZW4K
KyAgICBhc19mbl9lcnJvciAkPyAiY291bGQgbm90IG1ha2UgJENPTkZJR19IRUFERVJTIiAiJExJ
TkVOTyIgNQorICBlbHNlCisgICAgYWNfZGVsaW09IiRhY19kZWxpbSEkYWNfZGVsaW0gXyRhY19k
ZWxpbSEhICIKKyAgZmkKK2RvbmUKKworIyBGb3IgdGhlIGF3ayBzY3JpcHQsIEQgaXMgYW4gYXJy
YXkgb2YgbWFjcm8gdmFsdWVzIGtleWVkIGJ5IG5hbWUsCisjIGxpa2V3aXNlIFAgY29udGFpbnMg
bWFjcm8gcGFyYW1ldGVycyBpZiBhbnkuICBQcmVzZXJ2ZSBiYWNrc2xhc2gKKyMgbmV3bGluZSBz
ZXF1ZW5jZXMuCisKK2FjX3dvcmRfcmU9W18kYXNfY3JfTGV0dGVyc11bXyRhc19jcl9hbG51bV0q
CitzZWQgLW4gJworcy8uXHsxNDhcfS8mJyIkYWNfZGVsaW0iJy9nCit0IHJzZXQKKzpyc2V0Citz
L15bCSBdKiNbCSBdKmRlZmluZVsJIF1bCSBdKi8gLwordCBkZWYKK2QKKzpkZWYKK3MvXFwkLy8K
K3QgYnNubAorcy9bIlxcXS9cXCYvZworcy9eIFwoJyIkYWNfd29yZF9yZSInXClcKChbXigpXSop
XClbCSBdKlwoLipcKS9QWyJcMSJdPSJcMiJcCitEWyJcMSJdPSIgXDMiL3AKK3MvXiBcKCciJGFj
X3dvcmRfcmUiJ1wpWwkgXSpcKC4qXCkvRFsiXDEiXT0iIFwyIi9wCitkCis6YnNubAorcy9bIlxc
XS9cXCYvZworcy9eIFwoJyIkYWNfd29yZF9yZSInXClcKChbXigpXSopXClbCSBdKlwoLipcKS9Q
WyJcMSJdPSJcMiJcCitEWyJcMSJdPSIgXDNcXFxcXFxuIlxcL3AKK3QgY29udAorcy9eIFwoJyIk
YWNfd29yZF9yZSInXClbCSBdKlwoLipcKS9EWyJcMSJdPSIgXDJcXFxcXFxuIlxcL3AKK3QgY29u
dAorZAorOmNvbnQKK24KK3MvLlx7MTQ4XH0vJiciJGFjX2RlbGltIicvZwordCBjbGVhcgorOmNs
ZWFyCitzL1xcJC8vCit0IGJzbmxjCitzL1siXFxdL1xcJi9nOyBzL14vIi87IHMvJC8iL3AKK2QK
Kzpic25sYworcy9bIlxcXS9cXCYvZzsgcy9eLyIvOyBzLyQvXFxcXFxcbiJcXC9wCitiIGNvbnQK
KycgPGNvbmZkZWZzLmggfCBzZWQgJworcy8nIiRhY19kZWxpbSInLyJcXFwKKyIvZycgPj4kQ09O
RklHX1NUQVRVUyB8fCBhY193cml0ZV9mYWlsPTEKKworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxf
QUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisgIGZvciAoa2V5IGluIEQpIERfaXNfc2V0W2tleV0g
PSAxCisgIEZTID0gIgciCit9CisvXltcdCBdKiNbXHQgXSooZGVmaW5lfHVuZGVmKVtcdCBdKyRh
Y193b3JkX3JlKFtcdCAoXXxcJCkvIHsKKyAgbGluZSA9IFwkIDAKKyAgc3BsaXQobGluZSwgYXJn
LCAiICIpCisgIGlmIChhcmdbMV0gPT0gIiMiKSB7CisgICAgZGVmdW5kZWYgPSBhcmdbMl0KKyAg
ICBtYWMxID0gYXJnWzNdCisgIH0gZWxzZSB7CisgICAgZGVmdW5kZWYgPSBzdWJzdHIoYXJnWzFd
LCAyKQorICAgIG1hYzEgPSBhcmdbMl0KKyAgfQorICBzcGxpdChtYWMxLCBtYWMyLCAiKCIpICMp
CisgIG1hY3JvID0gbWFjMlsxXQorICBwcmVmaXggPSBzdWJzdHIobGluZSwgMSwgaW5kZXgobGlu
ZSwgZGVmdW5kZWYpIC0gMSkKKyAgaWYgKERfaXNfc2V0W21hY3JvXSkgeworICAgICMgUHJlc2Vy
dmUgdGhlIHdoaXRlIHNwYWNlIHN1cnJvdW5kaW5nIHRoZSAiIyIuCisgICAgcHJpbnQgcHJlZml4
ICJkZWZpbmUiLCBtYWNybyBQW21hY3JvXSBEW21hY3JvXQorICAgIG5leHQKKyAgfSBlbHNlIHsK
KyAgICAjIFJlcGxhY2UgI3VuZGVmIHdpdGggY29tbWVudHMuICBUaGlzIGlzIG5lY2Vzc2FyeSwg
Zm9yIGV4YW1wbGUsCisgICAgIyBpbiB0aGUgY2FzZSBvZiBfUE9TSVhfU09VUkNFLCB3aGljaCBp
cyBwcmVkZWZpbmVkIGFuZCByZXF1aXJlZAorICAgICMgb24gc29tZSBzeXN0ZW1zIHdoZXJlIGNv
bmZpZ3VyZSB3aWxsIG5vdCBkZWNpZGUgdG8gZGVmaW5lIGl0LgorICAgIGlmIChkZWZ1bmRlZiA9
PSAidW5kZWYiKSB7CisgICAgICBwcmludCAiLyoiLCBwcmVmaXggZGVmdW5kZWYsIG1hY3JvLCAi
Ki8iCisgICAgICBuZXh0CisgICAgfQorICB9Cit9Cit7IHByaW50IH0KK19BQ0FXSworX0FDRU9G
CitjYXQgPj4kQ09ORklHX1NUQVRVUyA8PFxfQUNFT0YgfHwgYWNfd3JpdGVfZmFpbD0xCisgIGFz
X2ZuX2Vycm9yICQ/ICJjb3VsZCBub3Qgc2V0dXAgY29uZmlnIGhlYWRlcnMgbWFjaGluZXJ5IiAi
JExJTkVOTyIgNQorZmkgIyB0ZXN0IC1uICIkQ09ORklHX0hFQURFUlMiCisKKworZXZhbCBzZXQg
WCAiICA6RiAkQ09ORklHX0ZJTEVTICA6SCAkQ09ORklHX0hFQURFUlMgICAgIgorc2hpZnQKK2Zv
ciBhY190YWcKK2RvCisgIGNhc2UgJGFjX3RhZyBpbgorICA6W0ZITENdKSBhY19tb2RlPSRhY190
YWc7IGNvbnRpbnVlOzsKKyAgZXNhYworICBjYXNlICRhY19tb2RlJGFjX3RhZyBpbgorICA6W0ZI
TF0qOiopOzsKKyAgOkwqIHwgOkMqOiopIGFzX2ZuX2Vycm9yICQ/ICJpbnZhbGlkIHRhZyBcYCRh
Y190YWcnIiAiJExJTkVOTyIgNTs7CisgIDpbRkhdLSkgYWNfdGFnPS06LTs7CisgIDpbRkhdKikg
YWNfdGFnPSRhY190YWc6JGFjX3RhZy5pbjs7CisgIGVzYWMKKyAgYWNfc2F2ZV9JRlM9JElGUwor
ICBJRlM9OgorICBzZXQgeCAkYWNfdGFnCisgIElGUz0kYWNfc2F2ZV9JRlMKKyAgc2hpZnQKKyAg
YWNfZmlsZT0kMQorICBzaGlmdAorCisgIGNhc2UgJGFjX21vZGUgaW4KKyAgOkwpIGFjX3NvdXJj
ZT0kMTs7CisgIDpbRkhdKQorICAgIGFjX2ZpbGVfaW5wdXRzPQorICAgIGZvciBhY19mCisgICAg
ZG8KKyAgICAgIGNhc2UgJGFjX2YgaW4KKyAgICAgIC0pIGFjX2Y9IiRhY190bXAvc3RkaW4iOzsK
KyAgICAgICopICMgTG9vayBmb3IgdGhlIGZpbGUgZmlyc3QgaW4gdGhlIGJ1aWxkIHRyZWUsIHRo
ZW4gaW4gdGhlIHNvdXJjZSB0cmVlCisJICMgKGlmIHRoZSBwYXRoIGlzIG5vdCBhYnNvbHV0ZSku
ICBUaGUgYWJzb2x1dGUgcGF0aCBjYW5ub3QgYmUgRE9TLXN0eWxlLAorCSAjIGJlY2F1c2UgJGFj
X2YgY2Fubm90IGNvbnRhaW4gYDonLgorCSB0ZXN0IC1mICIkYWNfZiIgfHwKKwkgICBjYXNlICRh
Y19mIGluCisJICAgW1xcLyRdKikgZmFsc2U7OworCSAgICopIHRlc3QgLWYgIiRzcmNkaXIvJGFj
X2YiICYmIGFjX2Y9IiRzcmNkaXIvJGFjX2YiOzsKKwkgICBlc2FjIHx8CisJICAgYXNfZm5fZXJy
b3IgMSAiY2Fubm90IGZpbmQgaW5wdXQgZmlsZTogXGAkYWNfZiciICIkTElORU5PIiA1OzsKKyAg
ICAgIGVzYWMKKyAgICAgIGNhc2UgJGFjX2YgaW4gKlwnKikgYWNfZj1gJGFzX2VjaG8gIiRhY19m
IiB8IHNlZCAicy8nLydcXFxcXFxcXCcnL2ciYDs7IGVzYWMKKyAgICAgIGFzX2ZuX2FwcGVuZCBh
Y19maWxlX2lucHV0cyAiICckYWNfZiciCisgICAgZG9uZQorCisgICAgIyBMZXQncyBzdGlsbCBw
cmV0ZW5kIGl0IGlzIGBjb25maWd1cmUnIHdoaWNoIGluc3RhbnRpYXRlcyAoaS5lLiwgZG9uJ3QK
KyAgICAjIHVzZSAkYXNfbWUpLCBwZW9wbGUgd291bGQgYmUgc3VycHJpc2VkIHRvIHJlYWQ6Cisg
ICAgIyAgICAvKiBjb25maWcuaC4gIEdlbmVyYXRlZCBieSBjb25maWcuc3RhdHVzLiAgKi8KKyAg
ICBjb25maWd1cmVfaW5wdXQ9J0dlbmVyYXRlZCBmcm9tICdgCisJICAkYXNfZWNobyAiJCoiIHwg
c2VkICdzfF5bXjpdKi98fDtzfDpbXjpdKi98LCB8ZycKKwlgJyBieSBjb25maWd1cmUuJworICAg
IGlmIHRlc3QgeCIkYWNfZmlsZSIgIT0geC07IHRoZW4KKyAgICAgIGNvbmZpZ3VyZV9pbnB1dD0i
JGFjX2ZpbGUuICAkY29uZmlndXJlX2lucHV0IgorICAgICAgeyAkYXNfZWNobyAiJGFzX21lOiR7
YXNfbGluZW5vLSRMSU5FTk99OiBjcmVhdGluZyAkYWNfZmlsZSIgPiY1CiskYXNfZWNobyAiJGFz
X21lOiBjcmVhdGluZyAkYWNfZmlsZSIgPiY2O30KKyAgICBmaQorICAgICMgTmV1dHJhbGl6ZSBz
cGVjaWFsIGNoYXJhY3RlcnMgaW50ZXJwcmV0ZWQgYnkgc2VkIGluIHJlcGxhY2VtZW50IHN0cmlu
Z3MuCisgICAgY2FzZSAkY29uZmlndXJlX2lucHV0IGluICMoCisgICAgKlwmKiB8ICpcfCogfCAq
XFwqICkKKyAgICAgICBhY19zZWRfY29uZl9pbnB1dD1gJGFzX2VjaG8gIiRjb25maWd1cmVfaW5w
dXQiIHwKKyAgICAgICBzZWQgJ3MvW1xcXFwmfF0vXFxcXCYvZydgOzsgIygKKyAgICAqKSBhY19z
ZWRfY29uZl9pbnB1dD0kY29uZmlndXJlX2lucHV0OzsKKyAgICBlc2FjCisKKyAgICBjYXNlICRh
Y190YWcgaW4KKyAgICAqOi06KiB8ICo6LSkgY2F0ID4iJGFjX3RtcC9zdGRpbiIgXAorICAgICAg
fHwgYXNfZm5fZXJyb3IgJD8gImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1
IDs7CisgICAgZXNhYworICAgIDs7CisgIGVzYWMKKworICBhY19kaXI9YCRhc19kaXJuYW1lIC0t
ICIkYWNfZmlsZSIgfHwKKyRhc19leHByIFgiJGFjX2ZpbGUiIDogJ1hcKC4qW14vXVwpLy8qW14v
XVteL10qLyokJyBcfCBcCisJIFgiJGFjX2ZpbGUiIDogJ1hcKC8vXClbXi9dJyBcfCBcCisJIFgi
JGFjX2ZpbGUiIDogJ1hcKC8vXCkkJyBcfCBcCisJIFgiJGFjX2ZpbGUiIDogJ1hcKC9cKScgXHwg
LiAyPi9kZXYvbnVsbCB8fAorJGFzX2VjaG8gWCIkYWNfZmlsZSIgfAorICAgIHNlZCAnL15YXCgu
KlteL11cKVwvXC8qW14vXVteL10qXC8qJC97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJ
ICAvXlhcKFwvXC9cKVteL10uKi97CisJICAgIHMvL1wxLworCSAgICBxCisJICB9CisJICAvXlhc
KFwvXC9cKSQveworCSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgL15YXChcL1wpLiovewor
CSAgICBzLy9cMS8KKwkgICAgcQorCSAgfQorCSAgcy8uKi8uLzsgcSdgCisgIGFzX2Rpcj0iJGFj
X2RpciI7IGFzX2ZuX21rZGlyX3AKKyAgYWNfYnVpbGRkaXI9LgorCitjYXNlICIkYWNfZGlyIiBp
bgorLikgYWNfZGlyX3N1ZmZpeD0gYWNfdG9wX2J1aWxkZGlyX3N1Yj0uIGFjX3RvcF9idWlsZF9w
cmVmaXg9IDs7CisqKQorICBhY19kaXJfc3VmZml4PS9gJGFzX2VjaG8gIiRhY19kaXIiIHwgc2Vk
ICdzfF5cLltcXC9dfHwnYAorICAjIEEgIi4uIiBmb3IgZWFjaCBkaXJlY3RvcnkgaW4gJGFjX2Rp
cl9zdWZmaXguCisgIGFjX3RvcF9idWlsZGRpcl9zdWI9YCRhc19lY2hvICIkYWNfZGlyX3N1ZmZp
eCIgfCBzZWQgJ3N8L1teXFwvXSp8Ly4ufGc7c3wvfHwnYAorICBjYXNlICRhY190b3BfYnVpbGRk
aXJfc3ViIGluCisgICIiKSBhY190b3BfYnVpbGRkaXJfc3ViPS4gYWNfdG9wX2J1aWxkX3ByZWZp
eD0gOzsKKyAgKikgIGFjX3RvcF9idWlsZF9wcmVmaXg9JGFjX3RvcF9idWlsZGRpcl9zdWIvIDs7
CisgIGVzYWMgOzsKK2VzYWMKK2FjX2Fic190b3BfYnVpbGRkaXI9JGFjX3B3ZAorYWNfYWJzX2J1
aWxkZGlyPSRhY19wd2QkYWNfZGlyX3N1ZmZpeAorIyBmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0
eToKK2FjX3RvcF9idWlsZGRpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeAorCitjYXNlICRzcmNkaXIg
aW4KKyAgLikgICMgV2UgYXJlIGJ1aWxkaW5nIGluIHBsYWNlLgorICAgIGFjX3NyY2Rpcj0uCisg
ICAgYWNfdG9wX3NyY2Rpcj0kYWNfdG9wX2J1aWxkZGlyX3N1YgorICAgIGFjX2Fic190b3Bfc3Jj
ZGlyPSRhY19wd2QgOzsKKyAgW1xcL10qIHwgPzpbXFwvXSogKSAgIyBBYnNvbHV0ZSBuYW1lLgor
ICAgIGFjX3NyY2Rpcj0kc3JjZGlyJGFjX2Rpcl9zdWZmaXg7CisgICAgYWNfdG9wX3NyY2Rpcj0k
c3JjZGlyCisgICAgYWNfYWJzX3RvcF9zcmNkaXI9JHNyY2RpciA7OworICAqKSAjIFJlbGF0aXZl
IG5hbWUuCisgICAgYWNfc3JjZGlyPSRhY190b3BfYnVpbGRfcHJlZml4JHNyY2RpciRhY19kaXJf
c3VmZml4CisgICAgYWNfdG9wX3NyY2Rpcj0kYWNfdG9wX2J1aWxkX3ByZWZpeCRzcmNkaXIKKyAg
ICBhY19hYnNfdG9wX3NyY2Rpcj0kYWNfcHdkLyRzcmNkaXIgOzsKK2VzYWMKK2FjX2Fic19zcmNk
aXI9JGFjX2Fic190b3Bfc3JjZGlyJGFjX2Rpcl9zdWZmaXgKKworCisgIGNhc2UgJGFjX21vZGUg
aW4KKyAgOkYpCisgICMKKyAgIyBDT05GSUdfRklMRQorICAjCisKKyAgY2FzZSAkSU5TVEFMTCBp
bgorICBbXFwvJF0qIHwgPzpbXFwvXSogKSBhY19JTlNUQUxMPSRJTlNUQUxMIDs7CisgICopIGFj
X0lOU1RBTEw9JGFjX3RvcF9idWlsZF9wcmVmaXgkSU5TVEFMTCA7OworICBlc2FjCitfQUNFT0YK
KworY2F0ID4+JENPTkZJR19TVEFUVVMgPDxcX0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorIyBJ
ZiB0aGUgdGVtcGxhdGUgZG9lcyBub3Qga25vdyBhYm91dCBkYXRhcm9vdGRpciwgZXhwYW5kIGl0
LgorIyBGSVhNRTogVGhpcyBoYWNrIHNob3VsZCBiZSByZW1vdmVkIGEgZmV3IHllYXJzIGFmdGVy
IDIuNjAuCithY19kYXRhcm9vdGRpcl9oYWNrPTsgYWNfZGF0YXJvb3RkaXJfc2Vlbj0KK2FjX3Nl
ZF9kYXRhcm9vdD0nCisvZGF0YXJvb3RkaXIvIHsKKyAgcAorICBxCit9CisvQGRhdGFkaXJAL3AK
Ky9AZG9jZGlyQC9wCisvQGluZm9kaXJAL3AKKy9AbG9jYWxlZGlyQC9wCisvQG1hbmRpckAvcCcK
K2Nhc2UgYGV2YWwgInNlZCAtbiBcIlwkYWNfc2VkX2RhdGFyb290XCIgJGFjX2ZpbGVfaW5wdXRz
ImAgaW4KKypkYXRhcm9vdGRpciopIGFjX2RhdGFyb290ZGlyX3NlZW49eWVzOzsKKypAZGF0YWRp
ckAqfCpAZG9jZGlyQCp8KkBpbmZvZGlyQCp8KkBsb2NhbGVkaXJAKnwqQG1hbmRpckAqKQorICB7
ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6ICRhY19maWxl
X2lucHV0cyBzZWVtcyB0byBpZ25vcmUgdGhlIC0tZGF0YXJvb3RkaXIgc2V0dGluZyIgPiY1Cisk
YXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkYWNfZmlsZV9pbnB1dHMgc2VlbXMgdG8gaWdub3Jl
IHRoZSAtLWRhdGFyb290ZGlyIHNldHRpbmciID4mMjt9CitfQUNFT0YKK2NhdCA+PiRDT05GSUdf
U1RBVFVTIDw8X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorICBhY19kYXRhcm9vdGRpcl9oYWNr
PScKKyAgcyZAZGF0YWRpckAmJGRhdGFkaXImZworICBzJkBkb2NkaXJAJiRkb2NkaXImZworICBz
JkBpbmZvZGlyQCYkaW5mb2RpciZnCisgIHMmQGxvY2FsZWRpckAmJGxvY2FsZWRpciZnCisgIHMm
QG1hbmRpckAmJG1hbmRpciZnCisgIHMmXFxcJHtkYXRhcm9vdGRpcn0mJGRhdGFyb290ZGlyJmcn
IDs7Citlc2FjCitfQUNFT0YKKworIyBOZXV0cmFsaXplIFZQQVRIIHdoZW4gYCRzcmNkaXInID0g
YC4nLgorIyBTaGVsbCBjb2RlIGluIGNvbmZpZ3VyZS5hYyBtaWdodCBzZXQgZXh0cmFzdWIuCisj
IEZJWE1FOiBkbyB3ZSByZWFsbHkgd2FudCB0byBtYWludGFpbiB0aGlzIGZlYXR1cmU/CitjYXQg
Pj4kQ09ORklHX1NUQVRVUyA8PF9BQ0VPRiB8fCBhY193cml0ZV9mYWlsPTEKK2FjX3NlZF9leHRy
YT0iJGFjX3Zwc3ViCiskZXh0cmFzdWIKK19BQ0VPRgorY2F0ID4+JENPTkZJR19TVEFUVVMgPDxc
X0FDRU9GIHx8IGFjX3dyaXRlX2ZhaWw9MQorOnQKKy9AW2EtekEtWl9dW2EtekEtWl8wLTldKkAv
IWIKK3N8QGNvbmZpZ3VyZV9pbnB1dEB8JGFjX3NlZF9jb25mX2lucHV0fDt0IHQKK3MmQHRvcF9i
dWlsZGRpckAmJGFjX3RvcF9idWlsZGRpcl9zdWImO3QgdAorcyZAdG9wX2J1aWxkX3ByZWZpeEAm
JGFjX3RvcF9idWlsZF9wcmVmaXgmO3QgdAorcyZAc3JjZGlyQCYkYWNfc3JjZGlyJjt0IHQKK3Mm
QGFic19zcmNkaXJAJiRhY19hYnNfc3JjZGlyJjt0IHQKK3MmQHRvcF9zcmNkaXJAJiRhY190b3Bf
c3JjZGlyJjt0IHQKK3MmQGFic190b3Bfc3JjZGlyQCYkYWNfYWJzX3RvcF9zcmNkaXImO3QgdAor
cyZAYnVpbGRkaXJAJiRhY19idWlsZGRpciY7dCB0CitzJkBhYnNfYnVpbGRkaXJAJiRhY19hYnNf
YnVpbGRkaXImO3QgdAorcyZAYWJzX3RvcF9idWlsZGRpckAmJGFjX2Fic190b3BfYnVpbGRkaXIm
O3QgdAorcyZASU5TVEFMTEAmJGFjX0lOU1RBTEwmO3QgdAorJGFjX2RhdGFyb290ZGlyX2hhY2sK
KyIKK2V2YWwgc2VkIFwiXCRhY19zZWRfZXh0cmFcIiAiJGFjX2ZpbGVfaW5wdXRzIiB8ICRBV0sg
LWYgIiRhY190bXAvc3Vicy5hd2siIFwKKyAgPiRhY190bXAvb3V0IHx8IGFzX2ZuX2Vycm9yICQ/
ICJjb3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorCit0ZXN0IC16ICIkYWNf
ZGF0YXJvb3RkaXJfaGFjayRhY19kYXRhcm9vdGRpcl9zZWVuIiAmJgorICB7IGFjX291dD1gc2Vk
IC1uICcvXCR7ZGF0YXJvb3RkaXJ9L3AnICIkYWNfdG1wL291dCJgOyB0ZXN0IC1uICIkYWNfb3V0
IjsgfSAmJgorICB7IGFjX291dD1gc2VkIC1uICcvXlsJIF0qZGF0YXJvb3RkaXJbCSBdKjoqPS9w
JyBcCisgICAgICAiJGFjX3RtcC9vdXQiYDsgdGVzdCAteiAiJGFjX291dCI7IH0gJiYKKyAgeyAk
YXNfZWNobyAiJGFzX21lOiR7YXNfbGluZW5vLSRMSU5FTk99OiBXQVJOSU5HOiAkYWNfZmlsZSBj
b250YWlucyBhIHJlZmVyZW5jZSB0byB0aGUgdmFyaWFibGUgXGBkYXRhcm9vdGRpcicKK3doaWNo
IHNlZW1zIHRvIGJlIHVuZGVmaW5lZC4gIFBsZWFzZSBtYWtlIHN1cmUgaXQgaXMgZGVmaW5lZCIg
PiY1CiskYXNfZWNobyAiJGFzX21lOiBXQVJOSU5HOiAkYWNfZmlsZSBjb250YWlucyBhIHJlZmVy
ZW5jZSB0byB0aGUgdmFyaWFibGUgXGBkYXRhcm9vdGRpcicKK3doaWNoIHNlZW1zIHRvIGJlIHVu
ZGVmaW5lZC4gIFBsZWFzZSBtYWtlIHN1cmUgaXQgaXMgZGVmaW5lZCIgPiYyO30KKworICBybSAt
ZiAiJGFjX3RtcC9zdGRpbiIKKyAgY2FzZSAkYWNfZmlsZSBpbgorICAtKSBjYXQgIiRhY190bXAv
b3V0IiAmJiBybSAtZiAiJGFjX3RtcC9vdXQiOzsKKyAgKikgcm0gLWYgIiRhY19maWxlIiAmJiBt
diAiJGFjX3RtcC9vdXQiICIkYWNfZmlsZSI7OworICBlc2FjIFwKKyAgfHwgYXNfZm5fZXJyb3Ig
JD8gImNvdWxkIG5vdCBjcmVhdGUgJGFjX2ZpbGUiICIkTElORU5PIiA1CisgOzsKKyAgOkgpCisg
ICMKKyAgIyBDT05GSUdfSEVBREVSCisgICMKKyAgaWYgdGVzdCB4IiRhY19maWxlIiAhPSB4LTsg
dGhlbgorICAgIHsKKyAgICAgICRhc19lY2hvICIvKiAkY29uZmlndXJlX2lucHV0ICAqLyIgXAor
ICAgICAgJiYgZXZhbCAnJEFXSyAtZiAiJGFjX3RtcC9kZWZpbmVzLmF3ayInICIkYWNfZmlsZV9p
bnB1dHMiCisgICAgfSA+IiRhY190bXAvY29uZmlnLmgiIFwKKyAgICAgIHx8IGFzX2ZuX2Vycm9y
ICQ/ICJjb3VsZCBub3QgY3JlYXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorICAgIGlmIGRpZmYg
IiRhY19maWxlIiAiJGFjX3RtcC9jb25maWcuaCIgPi9kZXYvbnVsbCAyPiYxOyB0aGVuCisgICAg
ICB7ICRhc19lY2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306ICRhY19maWxlIGlzIHVu
Y2hhbmdlZCIgPiY1CiskYXNfZWNobyAiJGFzX21lOiAkYWNfZmlsZSBpcyB1bmNoYW5nZWQiID4m
Njt9CisgICAgZWxzZQorICAgICAgcm0gLWYgIiRhY19maWxlIgorICAgICAgbXYgIiRhY190bXAv
Y29uZmlnLmgiICIkYWNfZmlsZSIgXAorCXx8IGFzX2ZuX2Vycm9yICQ/ICJjb3VsZCBub3QgY3Jl
YXRlICRhY19maWxlIiAiJExJTkVOTyIgNQorICAgIGZpCisgIGVsc2UKKyAgICAkYXNfZWNobyAi
LyogJGNvbmZpZ3VyZV9pbnB1dCAgKi8iIFwKKyAgICAgICYmIGV2YWwgJyRBV0sgLWYgIiRhY190
bXAvZGVmaW5lcy5hd2siJyAiJGFjX2ZpbGVfaW5wdXRzIiBcCisgICAgICB8fCBhc19mbl9lcnJv
ciAkPyAiY291bGQgbm90IGNyZWF0ZSAtIiAiJExJTkVOTyIgNQorICBmaQorIDs7CisKKworICBl
c2FjCisKK2RvbmUgIyBmb3IgYWNfdGFnCisKKworYXNfZm5fZXhpdCAwCitfQUNFT0YKK2FjX2Ns
ZWFuX2ZpbGVzPSRhY19jbGVhbl9maWxlc19zYXZlCisKK3Rlc3QgJGFjX3dyaXRlX2ZhaWwgPSAw
IHx8CisgIGFzX2ZuX2Vycm9yICQ/ICJ3cml0ZSBmYWlsdXJlIGNyZWF0aW5nICRDT05GSUdfU1RB
VFVTIiAiJExJTkVOTyIgNQorCisKKyMgY29uZmlndXJlIGlzIHdyaXRpbmcgdG8gY29uZmlnLmxv
ZywgYW5kIHRoZW4gY2FsbHMgY29uZmlnLnN0YXR1cy4KKyMgY29uZmlnLnN0YXR1cyBkb2VzIGl0
cyBvd24gcmVkaXJlY3Rpb24sIGFwcGVuZGluZyB0byBjb25maWcubG9nLgorIyBVbmZvcnR1bmF0
ZWx5LCBvbiBET1MgdGhpcyBmYWlscywgYXMgY29uZmlnLmxvZyBpcyBzdGlsbCBrZXB0IG9wZW4K
KyMgYnkgY29uZmlndXJlLCBzbyBjb25maWcuc3RhdHVzIHdvbid0IGJlIGFibGUgdG8gd3JpdGUg
dG8gaXQ7IGl0cworIyBvdXRwdXQgaXMgc2ltcGx5IGRpc2NhcmRlZC4gIFNvIHdlIGV4ZWMgdGhl
IEZEIHRvIC9kZXYvbnVsbCwKKyMgZWZmZWN0aXZlbHkgY2xvc2luZyBjb25maWcubG9nLCBzbyBp
dCBjYW4gYmUgcHJvcGVybHkgKHJlKW9wZW5lZCBhbmQKKyMgYXBwZW5kZWQgdG8gYnkgY29uZmln
LnN0YXR1cy4gIFdoZW4gY29taW5nIGJhY2sgdG8gY29uZmlndXJlLCB3ZQorIyBuZWVkIHRvIG1h
a2UgdGhlIEZEIGF2YWlsYWJsZSBhZ2Fpbi4KK2lmIHRlc3QgIiRub19jcmVhdGUiICE9IHllczsg
dGhlbgorICBhY19jc19zdWNjZXNzPToKKyAgYWNfY29uZmlnX3N0YXR1c19hcmdzPQorICB0ZXN0
ICIkc2lsZW50IiA9IHllcyAmJgorICAgIGFjX2NvbmZpZ19zdGF0dXNfYXJncz0iJGFjX2NvbmZp
Z19zdGF0dXNfYXJncyAtLXF1aWV0IgorICBleGVjIDU+L2Rldi9udWxsCisgICRTSEVMTCAkQ09O
RklHX1NUQVRVUyAkYWNfY29uZmlnX3N0YXR1c19hcmdzIHx8IGFjX2NzX3N1Y2Nlc3M9ZmFsc2UK
KyAgZXhlYyA1Pj5jb25maWcubG9nCisgICMgVXNlIHx8LCBub3QgJiYsIHRvIGF2b2lkIGV4aXRp
bmcgZnJvbSB0aGUgaWYgd2l0aCAkPyA9IDEsIHdoaWNoCisgICMgd291bGQgbWFrZSBjb25maWd1
cmUgZmFpbCBpZiB0aGlzIGlzIHRoZSBsYXN0IGluc3RydWN0aW9uLgorICAkYWNfY3Nfc3VjY2Vz
cyB8fCBhc19mbl9leGl0IDEKK2ZpCitpZiB0ZXN0IC1uICIkYWNfdW5yZWNvZ25pemVkX29wdHMi
ICYmIHRlc3QgIiRlbmFibGVfb3B0aW9uX2NoZWNraW5nIiAhPSBubzsgdGhlbgorICB7ICRhc19l
Y2hvICIkYXNfbWU6JHthc19saW5lbm8tJExJTkVOT306IFdBUk5JTkc6IHVucmVjb2duaXplZCBv
cHRpb25zOiAkYWNfdW5yZWNvZ25pemVkX29wdHMiID4mNQorJGFzX2VjaG8gIiRhc19tZTogV0FS
TklORzogdW5yZWNvZ25pemVkIG9wdGlvbnM6ICRhY191bnJlY29nbml6ZWRfb3B0cyIgPiYyO30K
K2ZpCisKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2NvbmZpZ3Vy
ZS5hYwotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9jb25maWd1cmUuYWMJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAg
KzEsMTg5IEBACisjICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAtKi0gQXV0b2NvbmYgLSotCisjIFByb2Nlc3MgdGhpcyBmaWxlIHdpdGggYXV0b2NvbmYgdG8g
cHJvZHVjZSBhIGNvbmZpZ3VyZSBzY3JpcHQuCisKK0FDX1BSRVJFUShbMi42N10pCitBQ19JTklU
KFtYZW4gSHlwZXJ2aXNvcl0sIG00X2VzeXNjbWQoWy4uL3ZlcnNpb24uc2ggLi4veGVuL01ha2Vm
aWxlXSksCisgICAgW3hlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tXSkKK0FDX0NPTkZJR19T
UkNESVIoW2xpYnhsL2xpYnhsLmNdKQorQUNfQ09ORklHX0ZJTEVTKFsuLi9jb25maWcvVG9vbHMu
bWtdKQorQUNfQ09ORklHX0hFQURFUlMoW2NvbmZpZy5oXSkKK0FDX1BSRUZJWF9ERUZBVUxUKFsv
dXNyXSkKK0FDX0NPTkZJR19BVVhfRElSKFsuXSkKKworIyBDaGVjayBpZiBDRkxBR1MsIExERkxB
R1MsIExJQlMsIENQUEZMQUdTIG9yIENQUCBpcyBzZXQgYW5kIHByaW50IGEgd2FybmluZworCitB
U19JRihbdGVzdCAtbiAiJENDJENGTEFHUyRMREZMQUdTJExJQlMkQ1BQRkxBR1MkQ1BQIl0sIFsK
KyAgICBBQ19NU0dfV0FSTigKK1tTZXR0aW5nIENDLCBDRkxBR1MsIExERkxBR1MsIExJQlMsIENQ
UEZMQUdTIG9yIENQUCBpcyBub3QgXAorcmVjb21tZW5kZWQsIHVzZSBQUkVQRU5EX0lOQ0xVREVT
LCBQUkVQRU5EX0xJQiwgXAorQVBQRU5EX0lOQ0xVREVTIGFuZCBBUFBFTkRfTElCIGluc3RlYWQg
d2hlbiBwb3NzaWJsZS5dKQorXSkKKworQUNfVVNFX1NZU1RFTV9FWFRFTlNJT05TCitBQ19DQU5P
TklDQUxfSE9TVAorCisjIE00IE1hY3JvIGluY2x1ZGVzCittNF9pbmNsdWRlKFttNC9lbmFibGVf
ZmVhdHVyZS5tNF0pCittNF9pbmNsdWRlKFttNC9kaXNhYmxlX2ZlYXR1cmUubTRdKQorbTRfaW5j
bHVkZShbbTQvcGF0aF9vcl9mYWlsLm00XSkKK200X2luY2x1ZGUoW200L3B5dGhvbl94bWwubTRd
KQorbTRfaW5jbHVkZShbbTQvcHl0aG9uX3ZlcnNpb24ubTRdKQorbTRfaW5jbHVkZShbbTQvcHl0
aG9uX2RldmVsLm00XSkKK200X2luY2x1ZGUoW200L3VkZXYubTRdKQorbTRfaW5jbHVkZShbbTQv
b2NhbWwubTRdKQorbTRfaW5jbHVkZShbbTQvZGVmYXVsdF9saWIubTRdKQorbTRfaW5jbHVkZShb
bTQvc2V0X2NmbGFnc19sZGZsYWdzLm00XSkKKworIyBFbmFibGUvZGlzYWJsZSBvcHRpb25zCitB
WF9BUkdfRU5BQkxFX0FORF9FWFBPUlQoW3hzbV0sCisgICAgW0VuYWJsZSBYU00gc2VjdXJpdHkg
bW9kdWxlIChieSBkZWZhdWx0LCBGbGFzayldKQorQVhfQVJHX0VOQUJMRV9BTkRfRVhQT1JUKFtn
aXRodHRwXSwgW0Rvd25sb2FkIEdJVCByZXBvc2l0b3JpZXMgdmlhIEhUVFBdKQorQVhfQVJHX0RJ
U0FCTEVfQU5EX0VYUE9SVChbbW9uaXRvcnNdLAorICAgIFtEaXNhYmxlIHhlbnN0YXQgYW5kIHhl
bnRvcCBtb25pdG9yaW5nIHRvb2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbdnRwbV0s
IFtFbmFibGUgVmlydHVhbCBUcnVzdGVkIFBsYXRmb3JtIE1vZHVsZV0pCitBWF9BUkdfRU5BQkxF
X0FORF9FWFBPUlQoW3hhcGldLCBbRW5hYmxlIFhlbiBBUEkgQmluZGluZ3NdKQorQVhfQVJHX0RJ
U0FCTEVfQU5EX0VYUE9SVChbcHl0aG9udG9vbHNdLCBbRGlzYWJsZSBQeXRob24gdG9vbHNdKQor
QVhfQVJHX0RJU0FCTEVfQU5EX0VYUE9SVChbb2NhbWx0b29sc10sIFtEaXNhYmxlIE9jYW1sIHRv
b2xzXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbWluaXRlcm1dLCBbRW5hYmxlIG1pbml0
ZXJtXSkKK0FYX0FSR19FTkFCTEVfQU5EX0VYUE9SVChbbG9tb3VudF0sIFtFbmFibGUgbG9tb3Vu
dF0pCitBWF9BUkdfRElTQUJMRV9BTkRfRVhQT1JUKFtkZWJ1Z10sIFtEaXNhYmxlIGRlYnVnIGJ1
aWxkIG9mIFhlbiBhbmQgdG9vbHNdKQorCitBQ19BUkdfVkFSKFtQUkVQRU5EX0lOQ0xVREVTXSwK
KyAgICBbTGlzdCBvZiBpbmNsdWRlIGZvbGRlcnMgdG8gcHJlcGVuZCB0byBDRkxBR1MgKHdpdGhv
dXQgLUkpXSkKK0FDX0FSR19WQVIoW1BSRVBFTkRfTElCXSwKKyAgICBbTGlzdCBvZiBsaWJyYXJ5
IGZvbGRlcnMgdG8gcHJlcGVuZCB0byBMREZMQUdTICh3aXRob3V0IC1MKV0pCitBQ19BUkdfVkFS
KFtBUFBFTkRfSU5DTFVERVNdLAorICAgIFtMaXN0IG9mIGluY2x1ZGUgZm9sZGVycyB0byBhcHBl
bmQgdG8gQ0ZMQUdTICh3aXRob3V0IC1JKV0pCitBQ19BUkdfVkFSKFtBUFBFTkRfTElCXSwKKyAg
ICBbTGlzdCBvZiBsaWJyYXJ5IGZvbGRlcnMgdG8gYXBwZW5kIHRvIExERkxBR1MgKHdpdGhvdXQg
LUwpXSkKKworQVhfU0VUX0ZMQUdTCisKK0FDX0FSR19WQVIoW1BZVEhPTl0sIFtQYXRoIHRvIHRo
ZSBQeXRob24gcGFyc2VyXSkKK0FDX0FSR19WQVIoW1BFUkxdLCBbUGF0aCB0byBQZXJsIHBhcnNl
cl0pCitBQ19BUkdfVkFSKFtCUkNUTF0sIFtQYXRoIHRvIGJyY3RsIHRvb2xdKQorQUNfQVJHX1ZB
UihbSVBdLCBbUGF0aCB0byBpcCB0b29sXSkKK0FDX0FSR19WQVIoW0JJU09OXSwgW1BhdGggdG8g
Qmlzb24gcGFyc2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtGTEVYXSwgW1BhdGggdG8gRmxl
eCBsZXhpY2FsIGFuYWx5c2VyIGdlbmVyYXRvcl0pCitBQ19BUkdfVkFSKFtDVVJMXSwgW1BhdGgg
dG8gY3VybC1jb25maWcgdG9vbF0pCitBQ19BUkdfVkFSKFtYTUxdLCBbUGF0aCB0byB4bWwyLWNv
bmZpZyB0b29sXSkKK0FDX0FSR19WQVIoW0JBU0hdLCBbUGF0aCB0byBiYXNoIHNoZWxsXSkKK0FD
X0FSR19WQVIoW1hHRVRURVhUXSwgW1BhdGggdG8geGdldHR0ZXh0IHRvb2xdKQorCisjIENoZWNr
cyBmb3IgcHJvZ3JhbXMuCitBQ19QUk9HX1NFRAorQUNfUFJPR19DQworQUNfUFJPR19MTl9TCitB
Q19QUk9HX01BS0VfU0VUCitBQ19QUk9HX0lOU1RBTEwKK0FYX1BBVEhfUFJPR19PUl9GQUlMKFtQ
RVJMXSwgW3BlcmxdKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0JSQ1RMXSwgW2JyY3RsXSkKK0FY
X1BBVEhfUFJPR19PUl9GQUlMKFtJUF0sIFtpcF0pCitBWF9QQVRIX1BST0dfT1JfRkFJTChbQklT
T05dLCBbYmlzb25dKQorQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0ZMRVhdLCBbZmxleF0pCitBU19J
RihbdGVzdCAieCR4YXBpIiA9ICJ4eSJdLCBbCisgICAgQVhfUEFUSF9QUk9HX09SX0ZBSUwoW0NV
UkxdLCBbY3VybC1jb25maWddKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtYTUxdLCBbeG1s
Mi1jb25maWddKQorXSkKK0FTX0lGKFt0ZXN0ICJ4JG9jYW1sdG9vbHMiID0gInh5Il0sIFsKKyAg
ICBBQ19QUk9HX09DQU1MCisgICAgQVNfSUYoW3Rlc3QgIngkT0NBTUxDIiA9ICJ4bm8iXSwgWwor
ICAgICAgICBBU19JRihbdGVzdCAieCRlbmFibGVfb2NhbWx0b29scyIgPSAieHllcyJdLCBbCisg
ICAgICAgICAgICBBQ19NU0dfRVJST1IoW09jYW1sIHRvb2xzIGVuYWJsZWQsIGJ1dCB1bmFibGUg
dG8gZmluZCBPY2FtbF0pXSkKKyAgICAgICAgb2NhbWx0b29scz0ibiIKKyAgICBdKQorXSkKK0FY
X1BBVEhfUFJPR19PUl9GQUlMKFtCQVNIXSwgW2Jhc2hdKQorQVNfSUYoW3Rlc3QgIngkcHl0aG9u
dG9vbHMiID0gInh5Il0sIFsKKyAgICBBU19JRihbZWNobyAiJFBZVEhPTiIgfCBncmVwIC1xICJe
LyJdLCBbCisgICAgICAgIFBZVEhPTlBBVEg9JFBZVEhPTgorICAgICAgICBQWVRIT049YGJhc2Vu
YW1lICRQWVRIT05QQVRIYAorICAgIF0sW3Rlc3QgLXogIiRQWVRIT04iXSwgW1BZVEhPTj0icHl0
aG9uIl0sCisgICAgW0FDX01TR19FUlJPUihbUFlUSE9OIHNwZWNpZmllZCwgYnV0IGlzIG5vdCBh
biBhYnNvbHV0ZSBwYXRoXSldKQorICAgIEFYX1BBVEhfUFJPR19PUl9GQUlMKFtQWVRIT05QQVRI
XSwgWyRQWVRIT05dKQorICAgIEFYX0NIRUNLX1BZVEhPTl9WRVJTSU9OKFsyXSwgWzNdKQorICAg
IEFYX0NIRUNLX1BZVEhPTl9YTUwoKQorICAgIEFYX0NIRUNLX1BZVEhPTl9ERVZFTCgpCitdKQor
QVhfUEFUSF9QUk9HX09SX0ZBSUwoW1hHRVRURVhUXSwgW3hnZXR0ZXh0XSkKK0FYX0NIRUNLX1VE
RVYoWzU5XSkKKworIyBDaGVjayBsaWJyYXJ5IHBhdGgKK0FYX0RFRkFVTFRfTElCCisKKyMgQ2hl
Y2tzIGZvciBsaWJyYXJpZXMuCitBQ19DSEVDS19MSUIoW2Fpb10sIFtpb19zZXR1cF0sIFtzeXN0
ZW1fYWlvPSJ5Il0sIFtzeXN0ZW1fYWlvPSJuIl0pCitBQ19TVUJTVChzeXN0ZW1fYWlvKQorQUNf
Q0hFQ0tfTElCKFtjcnlwdG9dLCBbTUQ1XSwgW10sIFtBQ19NU0dfRVJST1IoW0NvdWxkIG5vdCBm
aW5kIGxpYmNyeXB0b10pXSkKK0FDX0NIRUNLX0xJQihbZXh0MmZzXSwgW2V4dDJmc19vcGVuMl0s
IFtsaWJleHQyZnM9InkiXSwgW2xpYmV4dDJmcz0ibiJdKQorQUNfU1VCU1QobGliZXh0MmZzKQor
QUNfQ0hFQ0tfTElCKFtnY3J5cHRdLCBbZ2NyeV9tZF9oYXNoX2J1ZmZlcl0sIFtsaWJnY3J5cHQ9
InkiXSwgW2xpYmdjcnlwdD0ibiJdKQorQUNfU1VCU1QobGliZ2NyeXB0KQorQUNfQ0hFQ0tfTElC
KFtwdGhyZWFkXSwgW3B0aHJlYWRfY3JlYXRlXSwgW10gLAorICAgIFtBQ19NU0dfRVJST1IoW0Nv
dWxkIG5vdCBmaW5kIGxpYnB0aHJlYWRdKV0pCitBQ19DSEVDS19MSUIoW3J0XSwgW2Nsb2NrX2dl
dHRpbWVdKQorQUNfQ0hFQ0tfTElCKFt1dWlkXSwgW3V1aWRfY2xlYXJdLCBbXSwKKyAgICBbQUNf
TVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCBsaWJ1dWlkXSldKQorQUNfQ0hFQ0tfTElCKFt5YWps
XSwgW3lhamxfYWxsb2NdLCBbXSwKKyAgICBbQUNfTVNHX0VSUk9SKFtDb3VsZCBub3QgZmluZCB5
YWpsXSldKQorQUNfQ0hFQ0tfTElCKFt6XSwgW2RlZmxhdGVDb3B5XSwgW10sIFtBQ19NU0dfRVJS
T1IoW0NvdWxkIG5vdCBmaW5kIHpsaWJdKV0pCitBQ19DSEVDS19MSUIoW2ljb252XSwgW2xpYmlj
b252X29wZW5dLCBbbGliaWNvbnY9InkiXSwgW2xpYmljb252PSJuIl0pCitBQ19TVUJTVChsaWJp
Y29udikKKworIyBBdXRvc2NhbiBzdHVmZiAoZXhjZXB0IGZvciB5YWpsL3lhamxfdmVyc2lvbi5o
IGNoZWNrKQorIyBDaGVja3MgZm9yIGhlYWRlciBmaWxlcy4KK0FDX0ZVTkNfQUxMT0NBCitBQ19D
SEVDS19IRUFERVJTKFsgXAorICAgICAgICAgICAgICAgIGFycGEvaW5ldC5oIGZjbnRsLmggaW50
dHlwZXMuaCBsaWJpbnRsLmggbGltaXRzLmggbWFsbG9jLmggXAorICAgICAgICAgICAgICAgIG5l
dGRiLmggbmV0aW5ldC9pbi5oIHN0ZGRlZi5oIHN0ZGludC5oIHN0ZGxpYi5oIHN0cmluZy5oIFwK
KyAgICAgICAgICAgICAgICBzdHJpbmdzLmggc3lzL2ZpbGUuaCBzeXMvaW9jdGwuaCBzeXMvbW91
bnQuaCBzeXMvcGFyYW0uaCBcCisgICAgICAgICAgICAgICAgc3lzL3NvY2tldC5oIHN5cy9zdGF0
dmZzLmggc3lzL3RpbWUuaCBzeXNsb2cuaCB0ZXJtaW9zLmggXAorICAgICAgICAgICAgICAgIHVu
aXN0ZC5oIHlhamwveWFqbF92ZXJzaW9uLmggXAorICAgICAgICAgICAgICAgIF0pCisKKyMgQ2hl
Y2tzIGZvciB0eXBlZGVmcywgc3RydWN0dXJlcywgYW5kIGNvbXBpbGVyIGNoYXJhY3RlcmlzdGlj
cy4KK0FDX0hFQURFUl9TVERCT09MCitBQ19UWVBFX1VJRF9UCitBQ19DX0lOTElORQorQUNfVFlQ
RV9JTlQxNl9UCitBQ19UWVBFX0lOVDMyX1QKK0FDX1RZUEVfSU5UNjRfVAorQUNfVFlQRV9JTlQ4
X1QKK0FDX1RZUEVfTU9ERV9UCitBQ19UWVBFX09GRl9UCitBQ19UWVBFX1BJRF9UCitBQ19DX1JF
U1RSSUNUCitBQ19UWVBFX1NJWkVfVAorQUNfVFlQRV9TU0laRV9UCitBQ19DSEVDS19NRU1CRVJT
KFtzdHJ1Y3Qgc3RhdC5zdF9ibGtzaXplXSkKK0FDX1NUUlVDVF9TVF9CTE9DS1MKK0FDX0NIRUNL
X01FTUJFUlMoW3N0cnVjdCBzdGF0LnN0X3JkZXZdKQorQUNfVFlQRV9VSU5UMTZfVAorQUNfVFlQ
RV9VSU5UMzJfVAorQUNfVFlQRV9VSU5UNjRfVAorQUNfVFlQRV9VSU5UOF9UCitBQ19DSEVDS19U
WVBFUyhbcHRyZGlmZl90XSkKKworIyBDaGVja3MgZm9yIGxpYnJhcnkgZnVuY3Rpb25zLgorQUNf
RlVOQ19FUlJPUl9BVF9MSU5FCitBQ19GVU5DX0ZPUksKK0FDX0ZVTkNfRlNFRUtPCitBQ19GVU5D
X0xTVEFUX0ZPTExPV1NfU0xBU0hFRF9TWU1MSU5LCitBQ19IRUFERVJfTUFKT1IKK0FDX0ZVTkNf
TUFMTE9DCitBQ19GVU5DX01LVElNRQorQUNfRlVOQ19NTUFQCitBQ19GVU5DX1JFQUxMT0MKK0FD
X0ZVTkNfU1RSTkxFTgorQUNfRlVOQ19TVFJUT0QKK0FDX0NIRUNLX0ZVTkNTKFsgXAorICAgICAg
ICAgICAgICAgIGFsYXJtIGF0ZXhpdCBiemVybyBjbG9ja19nZXR0aW1lIGR1cDIgZmRhdGFzeW5j
IGZ0cnVuY2F0ZSBcCisgICAgICAgICAgICAgICAgZ2V0Y3dkIGdldGhvc3RieW5hbWUgZ2V0aG9z
dG5hbWUgZ2V0cGFnZXNpemUgZ2V0dGltZW9mZGF5IFwKKyAgICAgICAgICAgICAgICBpbmV0X250
b2EgaXNhc2NpaSBsb2NhbHRpbWVfciBtZW1jaHIgbWVtbW92ZSBtZW1zZXQgbWtkaXIgXAorICAg
ICAgICAgICAgICAgIG1rZmlmbyBtdW5tYXAgcGF0aGNvbmYgcmVhbHBhdGggcmVnY29tcCBybWRp
ciBzZWxlY3Qgc2V0ZW52IFwKKyAgICAgICAgICAgICAgICBzb2NrZXQgc3RyY2FzZWNtcCBzdHJj
aHIgc3RyY3NwbiBzdHJkdXAgc3RyZXJyb3Igc3RybmR1cCBcCisgICAgICAgICAgICAgICAgc3Ry
cGJyayBzdHJyY2hyIHN0cnNwbiBzdHJzdHIgc3RydG9sIHN0cnRvdWwgc3RydG91bGwgdHpzZXQg
XAorICAgICAgICAgICAgICAgIHVuYW1lIFwKKyAgICAgICAgICAgICAgICBdKQorCitBQ19PVVRQ
VVQoKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvZGVidWdnZXIv
Z2Ric3gveGcvTWFrZWZpbGUKLS0tIGEvdG9vbHMvZGVidWdnZXIvZ2Ric3gveGcvTWFrZWZpbGUJ
VGh1IEphbiAwNSAxNzoyNToyMyAyMDEyICswMDAwCisrKyBiL3Rvb2xzL2RlYnVnZ2VyL2dkYnN4
L3hnL01ha2VmaWxlCVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMjEsNyArMjEs
NiBAQCB4Z19hbGwuYTogJChYR19PQkpTKSBNYWtlZmlsZSAkKFhHX0hEUlMpCiAjCSQoQ0MpIC1t
MzIgLWMgLW8gJEAgJF4KIAogeGVuLWhlYWRlcnM6Ci0JJChNQUtFKSAtQyAuLi8uLi8uLi9jaGVj
ayAKIAkkKE1BS0UpIC1DIC4uLy4uLy4uL2luY2x1ZGUKIAogIyB4Z19tYWluLm86IHhnX21haW4u
YyBNYWtlZmlsZSAkKFhHX0hEUlMpCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIw
ZiB0b29scy9pbnN0YWxsLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcw
ICswMDAwCisrKyBiL3Rvb2xzL2luc3RhbGwuc2gJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICsw
MTAwCkBAIC0wLDAgKzEsMSBAQAorLi4vaW5zdGFsbC5zaApcIE5vIG5ld2xpbmUgYXQgZW5kIG9m
IGZpbGUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL2xpYmZzaW1h
Z2UvTWFrZWZpbGUKLS0tIGEvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlUaHUgSmFuIDA1IDE3
OjI1OjIzIDIwMTIgKzAwMDAKKysrIGIvdG9vbHMvbGliZnNpbWFnZS9NYWtlZmlsZQlUdWUgSmFu
IDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTIsNyArMiwxMSBAQCBYRU5fUk9PVCA9ICQoQ1VS
RElSKS8uLi8uLgogaW5jbHVkZSAkKFhFTl9ST09UKS90b29scy9SdWxlcy5tawogCiBTVUJESVJT
LXkgPSBjb21tb24gdWZzIHJlaXNlcmZzIGlzbzk2NjAgZmF0IHpmcyB4ZnMKLVNVQkRJUlMteSAr
PSAkKHNoZWxsIGVudiBDQz0iJChDQykiIC4vY2hlY2stbGliZXh0MmZzKQoraWZlcSAoJChDT05G
SUdfRVhUMkZTKSwgeSkKKyAgICBTVUJESVJTLXkgKz0gZXh0MmZzLWxpYgorZWxzZQorICAgIFNV
QkRJUlMteSArPSBleHQyZnMKK2VuZGlmCiAKIC5QSE9OWTogYWxsIGNsZWFuIGluc3RhbGwKIGFs
bCBjbGVhbiBpbnN0YWxsOiAlOiBzdWJkaXJzLSUKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2
NWQ5NGRhYjBmIHRvb2xzL2xpYmZzaW1hZ2UvY2hlY2stbGliZXh0MmZzCi0tLSBhL3Rvb2xzL2xp
YmZzaW1hZ2UvY2hlY2stbGliZXh0MmZzCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAor
KysgL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMApAQCAtMSwyMSArMCww
IEBACi0jIS9iaW4vc2gKLQotY2F0ID5leHQyLXRlc3QuYyA8PEVPRgotI2luY2x1ZGUgPGV4dDJm
cy9leHQyZnMuaD4KLQotaW50IG1haW4oKQotewotCWV4dDJmc19vcGVuMjsKLX0KLUVPRgotCi0k
e0NDLWdjY30gLW8gZXh0Mi10ZXN0IGV4dDItdGVzdC5jIC1sZXh0MmZzID4vZGV2L251bGwgMj4m
MQotaWYgWyAkPyA9IDAgXTsgdGhlbgotCWVjaG8gZXh0MmZzLWxpYgotZWxzZQotCWVjaG8gZXh0
MmZzCi1maQotCi1ybSAtZiBleHQyLXRlc3QgZXh0Mi10ZXN0LmMKLQotZXhpdCAwCmRpZmYgLXIg
NDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9saWJ4ZW4vTWFrZWZpbGUKLS0tIGEv
dG9vbHMvbGlieGVuL01ha2VmaWxlCVRodSBKYW4gMDUgMTc6MjU6MjMgMjAxMiArMDAwMAorKysg
Yi90b29scy9saWJ4ZW4vTWFrZWZpbGUJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBA
IC0yMiwxMiArMjIsMTIgQEAgTUFKT1IgPSAxLjAKIE1JTk9SID0gMAogCiBDRkxBR1MgKz0gLUlp
bmNsdWRlICAgICAgICAgICAgICAgICAgICAgXAotICAgICAgICAgICQoc2hlbGwgeG1sMi1jb25m
aWcgLS1jZmxhZ3MpIFwKLSAgICAgICAgICAkKHNoZWxsIGN1cmwtY29uZmlnIC0tY2ZsYWdzKSBc
CisgICAgICAgICAgJChzaGVsbCAkKFhNTDJfQ09ORklHKSAtLWNmbGFncykgXAorICAgICAgICAg
ICQoc2hlbGwgJChDVVJMX0NPTkZJRykgLS1jZmxhZ3MpIFwKICAgICAgICAgICAtZlBJQwogCi1M
REZMQUdTICs9ICQoc2hlbGwgeG1sMi1jb25maWcgLS1saWJzKSBcCi0gICAgICAgICAgICQoc2hl
bGwgY3VybC1jb25maWcgLS1saWJzKQorTERGTEFHUyArPSAkKHNoZWxsICQoWE1MMl9DT05GSUcp
IC0tbGlicykgXAorICAgICAgICAgICAkKHNoZWxsICQoQ1VSTF9DT05GSUcpIC0tbGlicykKIAog
TElCWEVOQVBJX0hEUlMgPSAkKHdpbGRjYXJkIGluY2x1ZGUveGVuL2FwaS8qLmgpIGluY2x1ZGUv
eGVuL2FwaS94ZW5fYWxsLmgKIExJQlhFTkFQSV9PQkpTID0gJChwYXRzdWJzdCAlLmMsICUubywg
JCh3aWxkY2FyZCBzcmMvKi5jKSkKZGlmZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBm
IHRvb2xzL200L2RlZmF1bHRfbGliLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDow
MCAxOTcwICswMDAwCisrKyBiL3Rvb2xzL200L2RlZmF1bHRfbGliLm00CVR1ZSBKYW4gMTAgMTk6
MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDggQEAKK0FDX0RFRlVOKFtBWF9ERUZBVUxUX0xJ
Ql0sCitbQVNfSUYoW3Rlc3QgLWQgIiRwcmVmaXgvbGliNjQiXSwgWworICAgIExJQl9QQVRIPSJs
aWI2NCIKK10sWworICAgIExJQl9QQVRIPSJsaWIiCitdKQorQUNfU1VCU1QoTElCX1BBVEgpXSkK
KwpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvZGlzYWJsZV9m
ZWF0dXJlLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisr
KyBiL3Rvb2xzL200L2Rpc2FibGVfZmVhdHVyZS5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIg
KzAxMDAKQEAgLTAsMCArMSwxMyBAQAorQUNfREVGVU4oW0FYX0FSR19ESVNBQkxFX0FORF9FWFBP
UlRdLAorW0FDX0FSR19FTkFCTEUoWyQxXSwKKyAgICBBU19IRUxQX1NUUklORyhbLS1kaXNhYmxl
LSQxXSwgWyQyXSkpCisKK0FTX0lGKFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieG5vIl0sIFsKKyAg
ICBheF9jdl8kMT0ibiIKK10sIFt0ZXN0ICJ4JGVuYWJsZV8kMSIgPSAieHllcyJdLCBbCisgICAg
YXhfY3ZfJDE9InkiCitdLCBbdGVzdCAteiAkYXhfY3ZfJDFdLCBbCisgICAgYXhfY3ZfJDE9Inki
CitdKQorJDE9JGF4X2N2XyQxCitBQ19TVUJTVCgkMSldKQpkaWZmIC1yIDQwODZlNDgxMTU0NyAt
ciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvZW5hYmxlX2ZlYXR1cmUubTQKLS0tIC9kZXYvbnVsbAlU
aHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAwMDAKKysrIGIvdG9vbHMvbTQvZW5hYmxlX2ZlYXR1
cmUubTQJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAgKzEsMTMgQEAKK0FD
X0RFRlVOKFtBWF9BUkdfRU5BQkxFX0FORF9FWFBPUlRdLAorW0FDX0FSR19FTkFCTEUoWyQxXSwK
KyAgICBBU19IRUxQX1NUUklORyhbLS1lbmFibGUtJDFdLCBbJDJdKSkKKworQVNfSUYoW3Rlc3Qg
IngkZW5hYmxlXyQxIiA9ICJ4eWVzIl0sIFsKKyAgICBheF9jdl8kMT0ieSIKK10sIFt0ZXN0ICJ4
JGVuYWJsZV8kMSIgPSAieG5vIl0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10sIFt0ZXN0IC16ICRh
eF9jdl8kMV0sIFsKKyAgICBheF9jdl8kMT0ibiIKK10pCiskMT0kYXhfY3ZfJDEKK0FDX1NVQlNU
KCQxKV0pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9tNC9vY2Ft
bC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9vY2FtbC5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAKQEAgLTAsMCAr
MSwyNDEgQEAKK2RubCBhdXRvY29uZiBtYWNyb3MgZm9yIE9DYW1sCitkbmwgZnJvbSBodHRwOi8v
Zm9yZ2Uub2NhbWxjb3JlLm9yZy8KK2RubAorZG5sIENvcHlyaWdodCDCqSAyMDA5ICAgICAgUmlj
aGFyZCBXLk0uIEpvbmVzCitkbmwgQ29weXJpZ2h0IMKpIDIwMDkgICAgICBTdGVmYW5vIFphY2No
aXJvbGkKK2RubCBDb3B5cmlnaHQgwqkgMjAwMC0yMDA1IE9saXZpZXIgQW5kcmlldQorZG5sIENv
cHlyaWdodCDCqSAyMDAwLTIwMDUgSmVhbi1DaHJpc3RvcGhlIEZpbGxpw6J0cmUKK2RubCBDb3B5
cmlnaHQgwqkgMjAwMC0yMDA1IEdlb3JnZXMgTWFyaWFubworZG5sCitkbmwgRm9yIGRvY3VtZW50
YXRpb24sIHBsZWFzZSByZWFkIHRoZSBvY2FtbC5tNCBtYW4gcGFnZS4KKworQUNfREVGVU4oW0FD
X1BST0dfT0NBTUxdLAorW2RubAorICAjIGNoZWNraW5nIGZvciBvY2FtbGMKKyAgQUNfQ0hFQ0tf
VE9PTChbT0NBTUxDXSxbb2NhbWxjXSxbbm9dKQorCisgIGlmIHRlc3QgIiRPQ0FNTEMiICE9ICJu
byI7IHRoZW4KKyAgICAgT0NBTUxWRVJTSU9OPWAkT0NBTUxDIC12IHwgc2VkIC1uIC1lICdzfC4q
dmVyc2lvbiogKlwoLipcKSR8XDF8cCdgCisgICAgIEFDX01TR19SRVNVTFQoW09DYW1sIHZlcnNp
b24gaXMgJE9DQU1MVkVSU0lPTl0pCisgICAgICMgSWYgT0NBTUxMSUIgaXMgc2V0LCB1c2UgaXQK
KyAgICAgaWYgdGVzdCAiJE9DQU1MTElCIiA9ICIiOyB0aGVuCisgICAgICAgIE9DQU1MTElCPWAk
T0NBTUxDIC13aGVyZSAyPi9kZXYvbnVsbCB8fCAkT0NBTUxDIC12fHRhaWwgLTF8Y3V0IC1kICcg
JyAtZiA0YAorICAgICBlbHNlCisgICAgICAgIEFDX01TR19SRVNVTFQoW09DQU1MTElCIHByZXZp
b3VzbHkgc2V0OyBwcmVzZXJ2aW5nIGl0Ll0pCisgICAgIGZpCisgICAgIEFDX01TR19SRVNVTFQo
W09DYW1sIGxpYnJhcnkgcGF0aCBpcyAkT0NBTUxMSUJdKQorCisgICAgIEFDX1NVQlNUKFtPQ0FN
TFZFUlNJT05dKQorICAgICBBQ19TVUJTVChbT0NBTUxMSUJdKQorCisgICAgICMgY2hlY2tpbmcg
Zm9yIG9jYW1sb3B0CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MT1BUXSxbb2NhbWxvcHRdLFtu
b10pCisgICAgIE9DQU1MQkVTVD1ieXRlCisgICAgIGlmIHRlc3QgIiRPQ0FNTE9QVCIgPSAibm8i
OyB0aGVuCisJQUNfTVNHX1dBUk4oW0Nhbm5vdCBmaW5kIG9jYW1sb3B0OyBieXRlY29kZSBjb21w
aWxhdGlvbiBvbmx5Ll0pCisgICAgIGVsc2UKKwlUTVBWRVJTSU9OPWAkT0NBTUxPUFQgLXYgfCBz
ZWQgLW4gLWUgJ3N8Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJaWYgdGVzdCAiJFRNUFZF
UlNJT04iICE9ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgQUNfTVNHX1JFU1VMVChbdmVy
c2lvbnMgZGlmZmVycyBmcm9tIG9jYW1sYzsgb2NhbWxvcHQgZGlzY2FyZGVkLl0pCisJICAgIE9D
QU1MT1BUPW5vCisJZWxzZQorCSAgICBPQ0FNTEJFU1Q9b3B0CisJZmkKKyAgICAgZmkKKworICAg
ICBBQ19TVUJTVChbT0NBTUxCRVNUXSkKKworICAgICAjIGNoZWNraW5nIGZvciBvY2FtbGMub3B0
CisgICAgIEFDX0NIRUNLX1RPT0woW09DQU1MQ0RPVE9QVF0sW29jYW1sYy5vcHRdLFtub10pCisg
ICAgIGlmIHRlc3QgIiRPQ0FNTENET1RPUFQiICE9ICJubyI7IHRoZW4KKwlUTVBWRVJTSU9OPWAk
T0NBTUxDRE9UT1BUIC12IHwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiogKlwoLipcKSR8XDF8cCcg
YAorCWlmIHRlc3QgIiRUTVBWRVJTSU9OIiAhPSAiJE9DQU1MVkVSU0lPTiIgOyB0aGVuCisJICAg
IEFDX01TR19SRVNVTFQoW3ZlcnNpb25zIGRpZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sYy5vcHQg
ZGlzY2FyZGVkLl0pCisJZWxzZQorCSAgICBPQ0FNTEM9JE9DQU1MQ0RPVE9QVAorCWZpCisgICAg
IGZpCisKKyAgICAgIyBjaGVja2luZyBmb3Igb2NhbWxvcHQub3B0CisgICAgIGlmIHRlc3QgIiRP
Q0FNTE9QVCIgIT0gIm5vIiA7IHRoZW4KKwlBQ19DSEVDS19UT09MKFtPQ0FNTE9QVERPVE9QVF0s
W29jYW1sb3B0Lm9wdF0sW25vXSkKKwlpZiB0ZXN0ICIkT0NBTUxPUFRET1RPUFQiICE9ICJubyI7
IHRoZW4KKwkgICBUTVBWRVJTSU9OPWAkT0NBTUxPUFRET1RPUFQgLXYgfCBzZWQgLW4gLWUgJ3N8
Lip2ZXJzaW9uKiAqXCguKlwpJHxcMXxwJyBgCisJICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9
ICIkT0NBTUxWRVJTSU9OIiA7IHRoZW4KKwkgICAgICBBQ19NU0dfUkVTVUxUKFt2ZXJzaW9uIGRp
ZmZlcnMgZnJvbSBvY2FtbGM7IG9jYW1sb3B0Lm9wdCBkaXNjYXJkZWQuXSkKKwkgICBlbHNlCisJ
ICAgICAgT0NBTUxPUFQ9JE9DQU1MT1BURE9UT1BUCisJICAgZmkKKyAgICAgICAgZmkKKyAgICAg
ZmkKKworICAgICBBQ19TVUJTVChbT0NBTUxPUFRdKQorICBmaQorCisgIEFDX1NVQlNUKFtPQ0FN
TENdKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sIHRvcGxldmVsCisgIEFDX0NIRUNLX1RPT0wo
W09DQU1MXSxbb2NhbWxdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkZXAKKyAgQUNf
Q0hFQ0tfVE9PTChbT0NBTUxERVBdLFtvY2FtbGRlcF0sW25vXSkKKworICAjIGNoZWNraW5nIGZv
ciBvY2FtbG1rdG9wCisgIEFDX0NIRUNLX1RPT0woW09DQU1MTUtUT1BdLFtvY2FtbG1rdG9wXSxb
bm9dKQorCisgICMgY2hlY2tpbmcgZm9yIG9jYW1sbWtsaWIKKyAgQUNfQ0hFQ0tfVE9PTChbT0NB
TUxNS0xJQl0sW29jYW1sbWtsaWJdLFtub10pCisKKyAgIyBjaGVja2luZyBmb3Igb2NhbWxkb2MK
KyAgQUNfQ0hFQ0tfVE9PTChbT0NBTUxET0NdLFtvY2FtbGRvY10sW25vXSkKKworICAjIGNoZWNr
aW5nIGZvciBvY2FtbGJ1aWxkCisgIEFDX0NIRUNLX1RPT0woW09DQU1MQlVJTERdLFtvY2FtbGJ1
aWxkXSxbbm9dKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJPR19PQ0FNTExFWF0sCitbZG5sCisg
ICMgY2hlY2tpbmcgZm9yIG9jYW1sbGV4CisgIEFDX0NIRUNLX1RPT0woW09DQU1MTEVYXSxbb2Nh
bWxsZXhdLFtub10pCisgIGlmIHRlc3QgIiRPQ0FNTExFWCIgIT0gIm5vIjsgdGhlbgorICAgIEFD
X0NIRUNLX1RPT0woW09DQU1MTEVYRE9UT1BUXSxbb2NhbWxsZXgub3B0XSxbbm9dKQorICAgIGlm
IHRlc3QgIiRPQ0FNTExFWERPVE9QVCIgIT0gIm5vIjsgdGhlbgorCU9DQU1MTEVYPSRPQ0FNTExF
WERPVE9QVAorICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtPQ0FNTExFWF0pCitdKQorCitBQ19E
RUZVTihbQUNfUFJPR19PQ0FNTFlBQ0NdLAorW2RubAorICBBQ19DSEVDS19UT09MKFtPQ0FNTFlB
Q0NdLFtvY2FtbHlhY2NdLFtub10pCisgIEFDX1NVQlNUKFtPQ0FNTFlBQ0NdKQorXSkKKworCitB
Q19ERUZVTihbQUNfUFJPR19DQU1MUDRdLAorW2RubAorICBBQ19SRVFVSVJFKFtBQ19QUk9HX09D
QU1MXSlkbmwKKworICAjIGNoZWNraW5nIGZvciBjYW1scDQKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FN
TFA0XSxbY2FtbHA0XSxbbm9dKQorICBpZiB0ZXN0ICIkQ0FNTFA0IiAhPSAibm8iOyB0aGVuCisg
ICAgIFRNUFZFUlNJT049YCRDQU1MUDQgLXYgMj4mMXwgc2VkIC1uIC1lICdzfC4qdmVyc2lvbiAq
XCguKlwpJHxcMXxwJ2AKKyAgICAgaWYgdGVzdCAiJFRNUFZFUlNJT04iICE9ICIkT0NBTUxWRVJT
SU9OIiA7IHRoZW4KKwlBQ19NU0dfUkVTVUxUKFt2ZXJzaW9ucyBkaWZmZXJzIGZyb20gb2NhbWxj
XSkKKyAgICAgICAgQ0FNTFA0PW5vCisgICAgIGZpCisgIGZpCisgIEFDX1NVQlNUKFtDQU1MUDRd
KQorCisgICMgY2hlY2tpbmcgZm9yIGNvbXBhbmlvbiB0b29scworICBBQ19DSEVDS19UT09MKFtD
QU1MUDRCT09UXSxbY2FtbHA0Ym9vdF0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0T10s
W2NhbWxwNG9dLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9GXSxbY2FtbHA0b2ZdLFtu
b10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNE9PRl0sW2NhbWxwNG9vZl0sW25vXSkKKyAgQUNf
Q0hFQ0tfVE9PTChbQ0FNTFA0T1JGXSxbY2FtbHA0b3JmXSxbbm9dKQorICBBQ19DSEVDS19UT09M
KFtDQU1MUDRQUk9GXSxbY2FtbHA0cHJvZl0sW25vXSkKKyAgQUNfQ0hFQ0tfVE9PTChbQ0FNTFA0
Ul0sW2NhbWxwNHJdLFtub10pCisgIEFDX0NIRUNLX1RPT0woW0NBTUxQNFJGXSxbY2FtbHA0cmZd
LFtub10pCisgIEFDX1NVQlNUKFtDQU1MUDRCT09UXSkKKyAgQUNfU1VCU1QoW0NBTUxQNE9dKQor
ICBBQ19TVUJTVChbQ0FNTFA0T0ZdKQorICBBQ19TVUJTVChbQ0FNTFA0T09GXSkKKyAgQUNfU1VC
U1QoW0NBTUxQNE9SRl0pCisgIEFDX1NVQlNUKFtDQU1MUDRQUk9GXSkKKyAgQUNfU1VCU1QoW0NB
TUxQNFJdKQorICBBQ19TVUJTVChbQ0FNTFA0UkZdKQorXSkKKworCitBQ19ERUZVTihbQUNfUFJP
R19GSU5ETElCXSwKK1tkbmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisKKyAg
IyBjaGVja2luZyBmb3Igb2NhbWxmaW5kCisgIEFDX0NIRUNLX1RPT0woW09DQU1MRklORF0sW29j
YW1sZmluZF0sW25vXSkKKyAgQUNfU1VCU1QoW09DQU1MRklORF0pCitdKQorCisKK2RubCBUaGFu
a3MgdG8gSmltIE1leWVyaW5nIGZvciB3b3JraW5nIHRoaXMgbmV4dCBiaXQgb3V0IGZvciB1cy4K
K2RubCBYWFggV2Ugc2hvdWxkIGRlZmluZSBBU19UUl9TSCBpZiBpdCdzIG5vdCBkZWZpbmVkIGFs
cmVhZHkKK2RubCAoZWcuIGZvciBvbGQgYXV0b2NvbmYpLgorQUNfREVGVU4oW0FDX0NIRUNLX09D
QU1MX1BLR10sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FDX1BST0dfRklORExJQl0pZG5sCisKKyAg
QUNfTVNHX0NIRUNLSU5HKFtmb3IgT0NhbWwgZmluZGxpYiBwYWNrYWdlICQxXSkKKworICB1bnNl
dCBmb3VuZAorICB1bnNldCBwa2cKKyAgZm91bmQ9bm8KKyAgZm9yIHBrZyBpbiAkMSAkMiA7IGRv
CisgICAgaWYgJE9DQU1MRklORCBxdWVyeSAkcGtnID4vZGV2L251bGwgMj4vZGV2L251bGw7IHRo
ZW4KKyAgICAgIEFDX01TR19SRVNVTFQoW2ZvdW5kXSkKKyAgICAgIEFTX1RSX1NIKFtPQ0FNTF9Q
S0dfJDFdKT0kcGtnCisgICAgICBmb3VuZD15ZXMKKyAgICAgIGJyZWFrCisgICAgZmkKKyAgZG9u
ZQorICBpZiB0ZXN0ICIkZm91bmQiID0gIm5vIiA7IHRoZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtu
b3QgZm91bmRdKQorICAgIEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKT1ubworICBmaQorCisgIEFD
X1NVQlNUKEFTX1RSX1NIKFtPQ0FNTF9QS0dfJDFdKSkKK10pCisKKworQUNfREVGVU4oW0FDX0NI
RUNLX09DQU1MX01PRFVMRV0sCitbZG5sCisgIEFDX01TR19DSEVDS0lORyhbZm9yIE9DYW1sIG1v
ZHVsZSAkMl0pCisKKyAgY2F0ID4gY29uZnRlc3QubWwgPDxFT0YKK29wZW4gJDMKK0VPRgorICB1
bnNldCBmb3VuZAorICBmb3IgJDEgaW4gJCQxICQ0IDsgZG8KKyAgICBpZiAkT0NBTUxDIC1jIC1J
ICIkJDEiIGNvbmZ0ZXN0Lm1sID4mNSAyPiY1IDsgdGhlbgorICAgICAgZm91bmQ9eWVzCisgICAg
ICBicmVhaworICAgIGZpCisgIGRvbmUKKworICBpZiB0ZXN0ICIkZm91bmQiIDsgdGhlbgorICAg
IEFDX01TR19SRVNVTFQoWyQkMV0pCisgIGVsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFtub3QgZm91
bmRdKQorICAgICQxPW5vCisgIGZpCisgIEFDX1NVQlNUKFskMV0pCitdKQorCisKK2RubCBYWFgg
Q3Jvc3MtY29tcGlsaW5nCitBQ19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfV09SRF9TSVpFXSwKK1tk
bmwKKyAgQUNfUkVRVUlSRShbQUNfUFJPR19PQ0FNTF0pZG5sCisgIEFDX01TR19DSEVDS0lORyhb
Zm9yIE9DYW1sIGNvbXBpbGVyIHdvcmQgc2l6ZV0pCisgIGNhdCA+IGNvbmZ0ZXN0Lm1sIDw8RU9G
CisgIHByaW50X2VuZGxpbmUgKHN0cmluZ19vZl9pbnQgU3lzLndvcmRfc2l6ZSkKKyAgRU9GCisg
IE9DQU1MX1dPUkRfU0laRT1gJE9DQU1MIGNvbmZ0ZXN0Lm1sYAorICBBQ19NU0dfUkVTVUxUKFsk
T0NBTUxfV09SRF9TSVpFXSkKKyAgQUNfU1VCU1QoW09DQU1MX1dPUkRfU0laRV0pCitdKQorCitB
Q19ERUZVTihbQUNfQ0hFQ0tfT0NBTUxfT1NfVFlQRV0sCitbZG5sCisgIEFDX1JFUVVJUkUoW0FD
X1BST0dfT0NBTUxdKWRubAorICBBQ19NU0dfQ0hFQ0tJTkcoW09DYW1sIFN5cy5vc190eXBlXSkK
KworICBjYXQgPiBjb25mdGVzdC5tbCA8PEVPRgorICBwcmludF9zdHJpbmcoU3lzLm9zX3R5cGUp
OzsKK0VPRgorCisgIE9DQU1MX09TX1RZUEU9YCRPQ0FNTCBjb25mdGVzdC5tbGAKKyAgQUNfTVNH
X1JFU1VMVChbJE9DQU1MX09TX1RZUEVdKQorICBBQ19TVUJTVChbT0NBTUxfT1NfVFlQRV0pCitd
KQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvcGF0aF9vcl9m
YWlsLm00Ci0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAwCisrKyBi
L3Rvb2xzL200L3BhdGhfb3JfZmFpbC5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIgKzAxMDAK
QEAgLTAsMCArMSw2IEBACitBQ19ERUZVTihbQVhfUEFUSF9QUk9HX09SX0ZBSUxdLAorW0FDX1BB
VEhfUFJPRyhbJDFdLCBbJDJdLCBbbm9dKQoraWYgdGVzdCB4IiR7JDF9IiA9PSB4Im5vIiAKK3Ro
ZW4KKyAgICBBQ19NU0dfRVJST1IoW1VuYWJsZSB0byBmaW5kICQyLCBwbGVhc2UgaW5zdGFsbCAk
Ml0pCitmaV0pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9tNC9w
eXRob25fZGV2ZWwubTQKLS0tIC9kZXYvbnVsbAlUaHUgSmFuIDAxIDAwOjAwOjAwIDE5NzAgKzAw
MDAKKysrIGIvdG9vbHMvbTQvcHl0aG9uX2RldmVsLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAx
MiArMDEwMApAQCAtMCwwICsxLDE4IEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX0RFVkVM
XSwKK1tBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gZGV2ZWxdKQorCitgJFBZVEhPTiAtYyAn
CitpbXBvcnQgb3MucGF0aCwgc3lzCitmb3IgcCBpbiBzeXMucGF0aDoKKyAgICBpZiBvcy5wYXRo
LmV4aXN0cyhwICsgIi9jb25maWcvTWFrZWZpbGUiKToKKyAgICAgICAgc3lzLmV4aXQoMCkKK3N5
cy5leGl0KDEpCisnID4gL2Rldi9udWxsIDI+JjFgCisKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3Ro
ZW4KKyAgICBBQ19NU0dfUkVTVUxUKFtub10pCisgICAgQUNfTVNHX0VSUk9SKFtQeXRob24gZGV2
ZWwgcGFja2FnZSBub3QgZm91bmRdKQorZWxzZQorICAgIEFDX01TR19SRVNVTFQoW3llc10pCitm
aV0pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIwZiB0b29scy9tNC9weXRob25f
dmVyc2lvbi5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAor
KysgYi90b29scy9tNC9weXRob25fdmVyc2lvbi5tNAlUdWUgSmFuIDEwIDE5OjEzOjAxIDIwMTIg
KzAxMDAKQEAgLTAsMCArMSwxMiBAQAorQUNfREVGVU4oW0FYX0NIRUNLX1BZVEhPTl9WRVJTSU9O
XSwKK1tBQ19NU0dfQ0hFQ0tJTkcoW2ZvciBweXRob24gdmVyc2lvbiA+PSAkMS4kMiBdKQorYCRQ
WVRIT04gLWMgJ2ltcG9ydCBzeXM7IGV4aXQoZXZhbCgic3lzLnZlcnNpb25faW5mbyA8ICgkMSwg
JDIpIikpJ2AKK2lmIHRlc3QgIiQ/IiAhPSAiMCIKK3RoZW4KKyAgICBweXRob25fdmVyc2lvbj1g
JFBZVEhPTiAtViAyPiYxYAorICAgIEFDX01TR19SRVNVTFQoW25vXSkKKyAgICBBQ19NU0dfRVJS
T1IoCisgICAgICAgIFskcHl0aG9uX3ZlcnNpb24gaXMgdG9vIG9sZCwgbWluaW11bSByZXF1aXJl
ZCB2ZXJzaW9uIGlzICQxLiQyXSkKK2Vsc2UKKyAgICBBQ19NU0dfUkVTVUxUKFt5ZXNdKQorZmld
KQpkaWZmIC1yIDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvcHl0aG9uX3ht
bC5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90
b29scy9tNC9weXRob25feG1sLm00CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAt
MCwwICsxLDEwIEBACitBQ19ERUZVTihbQVhfQ0hFQ0tfUFlUSE9OX1hNTF0sCitbQUNfTVNHX0NI
RUNLSU5HKFtmb3IgcHl0aG9uIHhtbC5kb20ubWluaWRvbV0pCitgJFBZVEhPTiAtYyAnaW1wb3J0
IHhtbC5kb20ubWluaWRvbSdgCitpZiB0ZXN0ICIkPyIgIT0gIjAiCit0aGVuCisgICAgQUNfTVNH
X1JFU1VMVChbbm9dKQorICAgIEFDX01TR19FUlJPUihbVW5hYmxlIHRvIGZpbmQgeG1sLmRvbS5t
aW5pZG9tIG1vZHVsZV0pCitlbHNlCisgICAgQUNfTVNHX1JFU1VMVChbeWVzXSkKK2ZpXSkKZGlm
ZiAtciA0MDg2ZTQ4MTE1NDcgLXIgZDY2NWQ5NGRhYjBmIHRvb2xzL200L3NldF9jZmxhZ3NfbGRm
bGFncy5tNAotLS0gL2Rldi9udWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysg
Yi90b29scy9tNC9zZXRfY2ZsYWdzX2xkZmxhZ3MubTQJVHVlIEphbiAxMCAxOToxMzowMSAyMDEy
ICswMTAwCkBAIC0wLDAgKzEsMjAgQEAKK0FDX0RFRlVOKFtBWF9TRVRfRkxBR1NdLAorW2ZvciBj
ZmxhZyBpbiAkUFJFUEVORF9JTkNMVURFUworZG8KKyAgICBQUkVQRU5EX0NGTEFHUys9IiAtSSRj
ZmxhZyIKK2RvbmUKK2ZvciBsZGZsYWcgaW4gJFBSRVBFTkRfTElCCitkbworICAgIFBSRVBFTkRf
TERGTEFHUys9IiAtTCRsZGZsYWciCitkb25lCitmb3IgY2ZsYWcgaW4gJEFQUEVORF9JTkNMVURF
UworZG8KKyAgICBBUFBFTkRfQ0ZMQUdTKz0iIC1JJGNmbGFnIgorZG9uZQorZm9yIGxkZmxhZyBp
biAkQVBQRU5EX0xJQgorZG8KKyAgICBBUFBFTkRfTERGTEFHUys9IiAtTCRsZGZsYWciCitkb25l
CitDRkxBR1M9IiRQUkVQRU5EX0NGTEFHUyAkQ0ZMQUdTICRBUFBFTkRfQ0ZMQUdTIgorTERGTEFH
Uz0iJFBSRVBFTkRfTERGTEFHUyAkTERGTEFHUyAkQVBQRU5EX0xERkxBR1MiXSkKKwpkaWZmIC1y
IDQwODZlNDgxMTU0NyAtciBkNjY1ZDk0ZGFiMGYgdG9vbHMvbTQvdWRldi5tNAotLS0gL2Rldi9u
dWxsCVRodSBKYW4gMDEgMDA6MDA6MDAgMTk3MCArMDAwMAorKysgYi90b29scy9tNC91ZGV2Lm00
CVR1ZSBKYW4gMTAgMTk6MTM6MDEgMjAxMiArMDEwMApAQCAtMCwwICsxLDMyIEBACitBQ19ERUZV
TihbQVhfQ0hFQ0tfVURFVl0sCitbaWYgdGVzdCAieCRob3N0X29zIiA9PSAieGxpbnV4LWdudSIK
K3RoZW4KKyAgICBBQ19QQVRIX1BST0coW1VERVZBRE1dLCBbdWRldmFkbV0sIFtub10pCisgICAg
aWYgdGVzdCB4IiR7VURFVkFETX0iID09IHgibm8iIAorICAgIHRoZW4KKyAgICAgICAgQUNfUEFU
SF9QUk9HKFtVREVWSU5GT10sIFt1ZGV2aW5mb10sIFtub10pCisgICAgICAgIGlmIHRlc3QgeCIk
e1VERVZJTkZPfSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VS
Uk9SKAorICAgICAgICAgICAgICAgIFtVbmFibGUgdG8gZmluZCB1ZGV2YWRtIG9yIHVkZXZpbmZv
LCBwbGVhc2UgaW5zdGFsbCB1ZGV2XSkKKyAgICAgICAgZmkKKyAgICAgICAgdWRldnZlcj1gJHtV
REVWSU5GT30gLVYgfCBhd2sgJ3twcmludCAkTkZ9J2AKKyAgICBlbHNlCisgICAgICAgIHVkZXZ2
ZXI9YCR7VURFVkFETX0gaW5mbyAtViB8IGF3ayAne3ByaW50ICRORn0nYAorICAgIGZpCisgICAg
aWYgdGVzdCAke3VkZXZ2ZXJ9IC1sdCA1OQorICAgIHRoZW4KKyAgICAgICAgQUNfUEFUSF9QUk9H
KFtIT1RQTFVHXSwgW2hvdHBsdWddLCBbbm9dKQorICAgICAgICBpZiB0ZXN0IHgiJHtIT1RQTFVH
fSIgPT0geCJubyIKKyAgICAgICAgdGhlbgorICAgICAgICAgICAgQUNfTVNHX0VSUk9SKFt1ZGV2
IGlzIHRvbyBvbGQsIHVwZ3JhZGUgdG8gdmVyc2lvbiA1OSBvciBsYXRlcl0pCisgICAgICAgIGZp
CisgICAgZmkKK2Vsc2UKKyAgICBBQ19QQVRIX1BST0coW1ZOQ09ORklHXSwgW3ZuY29uZmlnXSwg
W25vXSkKKyAgICBpZiB0ZXN0IHgiJHtWTkNPTkZJR30iID09IHgibm8iCisgICAgdGhlbgorICAg
ICAgICBBQ19NU0dfRVJST1IoW05vdCBhIExpbnV4IHN5c3RlbSBhbmQgdW5hYmxlIHRvIGZpbmQg
dm5kXSkKKyAgICBmaQorZmkKK10pCmRpZmYgLXIgNDA4NmU0ODExNTQ3IC1yIGQ2NjVkOTRkYWIw
ZiB2ZXJzaW9uLnNoCi0tLSAvZGV2L251bGwJVGh1IEphbiAwMSAwMDowMDowMCAxOTcwICswMDAw
CisrKyBiL3ZlcnNpb24uc2gJVHVlIEphbiAxMCAxOToxMzowMSAyMDEyICswMTAwCkBAIC0wLDAg
KzEsNCBAQAorIyEvYmluL3NoCitNQUpPUj1gZ3JlcCAiZXhwb3J0IFhFTl9WRVJTSU9OIiAkMSB8
IHNlZCAncy8uKj0vL2cnIHwgdHIgLXMgIiAiYAorTUlOT1I9YGdyZXAgImV4cG9ydCBYRU5fU1VC
VkVSU0lPTiIgJDEgfCBzZWQgJ3MvLio9Ly9nJyB8IHRyIC1zICIgImAKK3ByaW50ZiAiJWQuJWQi
ICRNQUpPUiAkTUlOT1IKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhb-00018l-8r; Mon, 16 Jan 2012 11:26:15 +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 1Rm8Jn-0002K6-OU
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:27:08 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326565620!9140454!1
X-Originating-IP: [32.97.182.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NiA9PiA1MjM5MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12406 invoked from network); 14 Jan 2012 18:27:01 -0000
Received: from e6.ny.us.ibm.com (HELO e6.ny.us.ibm.com) (32.97.182.146)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:27:01 -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>; Sat, 14 Jan 2012 13:27:00 -0500
Received: from d01relay05.pok.ibm.com (9.56.227.237)
	by e6.ny.us.ibm.com (192.168.1.106) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:26:58 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0EIQw9i255554
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:26:58 -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
	q0EIQuwI021888
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 16:26:58 -0200
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIQg72021192; Sat, 14 Jan 2012 16:26:44 -0200
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>, X86 <x86@kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Gleb Natapov <gleb@redhat.com>, 
	Avi Kivity <avi@redhat.com>, Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Rob Landley <rlandley@parallels.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:56:46 +0530
Message-Id: <20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-1976-0000-0000-00000980BFF1
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 4/5] kvm : pv-ticketlocks support for
	linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Extends Linux guest running on KVM hypervisor to support pv-ticketlocks. 

During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
 support for pv-ticketlocks is registered via pv_lock_ops.

Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.

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 7a94987..cf5327c 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -195,10 +195,20 @@ 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)
+
 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..ec55a0b 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,250 @@ 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, u32 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 by its apicid*/
+static inline void kvm_kick_cpu(int apicid)
+{
+	kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
+}
+
+/* Kick vcpu waiting on @lock->head to reach value @ticket */
+static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
+{
+	int cpu;
+	int apicid;
+
+	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);
+			apicid = per_cpu(x86_cpu_to_apicid, cpu);
+			kvm_kick_cpu(apicid);
+			break;
+		}
+	}
+}
+
+/*
+ * Setup pv_lock_ops to exploit KVM_FEATURE_PVLOCK_KICK if present.
+ */
+void __init kvm_spinlock_init(void)
+{
+	if (!kvm_para_available())
+		return;
+	/* Does host kernel support KVM_FEATURE_PVLOCK_KICK? */
+	if (!kvm_para_has_feature(KVM_FEATURE_PVLOCK_KICK))
+		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/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c7b05fc..4d7a950 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
 
 	local_irq_disable();
 
-	if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
-	    || need_resched() || signal_pending(current)) {
+	if (vcpu->mode == EXITING_GUEST_MODE
+		 || (vcpu->requests & ~(1UL<<KVM_REQ_PVLOCK_KICK))
+		 || need_resched() || signal_pending(current)) {
 		vcpu->mode = OUTSIDE_GUEST_MODE;
 		smp_wmb();
 		local_irq_enable();
@@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
 		!vcpu->arch.apf.halted)
 		|| !list_empty_careful(&vcpu->async_pf.done)
 		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
+		|| kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
 		|| atomic_read(&vcpu->arch.nmi_queued) ||
 		(kvm_arch_interrupt_allowed(vcpu) &&
 		 kvm_cpu_has_interrupt(vcpu));


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhg-0001CW-2C; Mon, 16 Jan 2012 11:26: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 1RmiEp-0005ZC-Id
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:48:23 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326703667!48524260!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28940 invoked from network); 16 Jan 2012 08:47:47 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	16 Jan 2012 08:47:47 -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 q0G8lxRb018628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 03:47:59 -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 q0G8lpQW017619; Mon, 16 Jan 2012 03:47:52 -0500
Message-ID: <4F13E437.4060205@redhat.com>
Date: Mon, 16 Jan 2012 10:47:51 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
	<20120116035114.GI9129@linux.vnet.ibm.com>
	<5E0038B3-3830-4668-B4BB-781976710ED1@suse.de>
In-Reply-To: <5E0038B3-3830-4668-B4BB-781976710ED1@suse.de>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.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>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/16/2012 06:00 AM, Alexander Graf wrote:
> On 16.01.2012, at 04:51, Srivatsa Vaddagiri wrote:
>
> > * Alexander Graf <agraf@suse.de> [2012-01-16 04:23:24]:
> > 
> >>> +5. KVM_HC_KICK_CPU
> >>> +------------------------
> >>> +value: 5
> >>> +Architecture: x86
> >>> +Purpose: Hypercall used to wakeup a vcpu from HLT state
> >>> +
> >>> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> >>> +kernel mode for an event to occur (ex: a spinlock to become available)
> >>> +can execute HLT instruction once it has busy-waited for more than a
> >>> +threshold time-interval. Execution of HLT instruction would cause
> >>> +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
> >>> +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
> >>> +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
> >>> +wokenup.
> >> 
> >> The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu.
> > 
> > Hmm ..the hypercall does not allow a vcpu to yield. It just allows some
> > target vcpu to be prodded/wokenup, after which vcpu continues execution.
> > 
> > Note that semantics of this hypercall is different from the hypercall on which
> > PPC pv-spinlock (__spin_yield()) is currently dependent. This is mainly because 
> > of ticketlocks on x86 (which does not allow us to easily store owning cpu
> > details in lock word itself).
>
> Yes, sorry for not being more exact in my wording. It is a directed yield(). Not like the normal old style thing that just says "I'm done, get some work to someone else" but more something like "I'm done, get some work to this specific guy over there" :).
>

It's not a yield.  It unhalts a vcpu.  Kind of like an IPI, but without
actually issuing an interrupt on the target, and disregarding the
interrupt flag.  It says nothing about the source.

-- 
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 Jan 16 11:26:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhg-0001CW-2C; Mon, 16 Jan 2012 11:26: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 1RmiEp-0005ZC-Id
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 08:48:23 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326703667!48524260!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA0OTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28940 invoked from network); 16 Jan 2012 08:47:47 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-27.messagelabs.com with SMTP;
	16 Jan 2012 08:47:47 -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 q0G8lxRb018628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 03:47:59 -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 q0G8lpQW017619; Mon, 16 Jan 2012 03:47:52 -0500
Message-ID: <4F13E437.4060205@redhat.com>
Date: Mon, 16 Jan 2012 10:47:51 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<AD31813D-E4D5-43F3-B06A-9EB1B6FC9381@suse.de>
	<20120116035114.GI9129@linux.vnet.ibm.com>
	<5E0038B3-3830-4668-B4BB-781976710ED1@suse.de>
In-Reply-To: <5E0038B3-3830-4668-B4BB-781976710ED1@suse.de>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.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>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/16/2012 06:00 AM, Alexander Graf wrote:
> On 16.01.2012, at 04:51, Srivatsa Vaddagiri wrote:
>
> > * Alexander Graf <agraf@suse.de> [2012-01-16 04:23:24]:
> > 
> >>> +5. KVM_HC_KICK_CPU
> >>> +------------------------
> >>> +value: 5
> >>> +Architecture: x86
> >>> +Purpose: Hypercall used to wakeup a vcpu from HLT state
> >>> +
> >>> +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
> >>> +kernel mode for an event to occur (ex: a spinlock to become available)
> >>> +can execute HLT instruction once it has busy-waited for more than a
> >>> +threshold time-interval. Execution of HLT instruction would cause
> >>> +the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
> >>> +of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
> >>> +vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
> >>> +wokenup.
> >> 
> >> The description is way too specific. The hypercall basically gives the guest the ability to yield() its current vcpu to another chosen vcpu.
> > 
> > Hmm ..the hypercall does not allow a vcpu to yield. It just allows some
> > target vcpu to be prodded/wokenup, after which vcpu continues execution.
> > 
> > Note that semantics of this hypercall is different from the hypercall on which
> > PPC pv-spinlock (__spin_yield()) is currently dependent. This is mainly because 
> > of ticketlocks on x86 (which does not allow us to easily store owning cpu
> > details in lock word itself).
>
> Yes, sorry for not being more exact in my wording. It is a directed yield(). Not like the normal old style thing that just says "I'm done, get some work to someone else" but more something like "I'm done, get some work to this specific guy over there" :).
>

It's not a yield.  It unhalts a vcpu.  Kind of like an IPI, but without
actually issuing an interrupt on the target, and disregarding the
interrupt flag.  It says nothing about the source.

-- 
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 Jan 16 11:26:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhi-0001FD-C2; Mon, 16 Jan 2012 11:26:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmjIK-000768-Hp
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:56:04 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326707704!57041140!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA2Nzk2NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3951 invoked from network); 16 Jan 2012 09:55:06 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 09:55:06 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 15:25:58 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 15:25:24 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G9tMqd4071508
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 15:25:23 +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
	q0G9tCUI003224
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 20:55:21 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0G9t5qc002916; Mon, 16 Jan 2012 20:55:07 +1100
Message-ID: <4F13F3FB.3010508@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 15:25:07 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
	<4F13E7D3.1060004@redhat.com>
In-Reply-To: <4F13E7D3.1060004@redhat.com>
x-cbid: 12011609-8878-0000-0000-000000F3F515
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 2/5] 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 01/16/2012 02:33 PM, Avi Kivity wrote:
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @apicid - apicid of vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>> +{
>> +	struct kvm_vcpu *vcpu = NULL;
>> +	int i;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_apic_present(vcpu))
>> +			continue;
>> +
>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>> +			break;
>> +	}
>> +	if (vcpu) {
>> +		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
>> +		kvm_vcpu_kick(vcpu);
>> +	}
>> +}
>> +
>
> The code that handles KVM_REQ_PVLOCK_KICK needs to be in this patch.
>
>

Yes, Agree. as Alex also pointed, the related hunk from patch 4 should 
be added here.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhi-0001FD-C2; Mon, 16 Jan 2012 11:26:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmjIK-000768-Hp
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 09:56:04 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326707704!57041140!1
X-Originating-IP: [122.248.162.7]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNyA9PiA2Nzk2NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3951 invoked from network); 16 Jan 2012 09:55:06 -0000
Received: from e28smtp07.in.ibm.com (HELO e28smtp07.in.ibm.com) (122.248.162.7)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 09:55:06 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 15:25:58 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp07.in.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 15:25:24 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0G9tMqd4071508
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 15:25:23 +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
	q0G9tCUI003224
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 20:55:21 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0G9t5qc002916; Mon, 16 Jan 2012 20:55:07 +1100
Message-ID: <4F13F3FB.3010508@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 15:25:07 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182553.8604.41642.sendpatchset@oc5400248562.ibm.com>
	<4F13E7D3.1060004@redhat.com>
In-Reply-To: <4F13E7D3.1060004@redhat.com>
x-cbid: 12011609-8878-0000-0000-000000F3F515
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 2/5] 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 01/16/2012 02:33 PM, Avi Kivity wrote:
>> +/*
>> + * kvm_pv_kick_cpu_op:  Kick a vcpu.
>> + *
>> + * @apicid - apicid of vcpu to be kicked.
>> + */
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int apicid)
>> +{
>> +	struct kvm_vcpu *vcpu = NULL;
>> +	int i;
>> +
>> +	kvm_for_each_vcpu(i, vcpu, kvm) {
>> +		if (!kvm_apic_present(vcpu))
>> +			continue;
>> +
>> +		if (kvm_apic_match_dest(vcpu, 0, 0, apicid, 0))
>> +			break;
>> +	}
>> +	if (vcpu) {
>> +		kvm_make_request(KVM_REQ_PVLOCK_KICK, vcpu);
>> +		kvm_vcpu_kick(vcpu);
>> +	}
>> +}
>> +
>
> The code that handles KVM_REQ_PVLOCK_KICK needs to be in this patch.
>
>

Yes, Agree. as Alex also pointed, the related hunk from patch 4 should 
be added here.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhd-0001AP-Pm; Mon, 16 Jan 2012 11:26:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1Rmdhm-0002LD-Ec
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:57:58 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326686271!9256555!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10876 invoked from network); 16 Jan 2012 03:57:51 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 03:57:51 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id B56D889471;
	Mon, 16 Jan 2012 04:57:50 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
Date: Mon, 16 Jan 2012 04:57:45 +0100
Message-Id: <3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 14.01.2012, at 19:25, Raghavendra K T wrote:

> The 5-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.

Is the code for this even upstream? Prerequisite series seem to have been posted by Jeremy, but they didn't appear to have made it in yet.

Either way, thinking about this I stumbled over the following passage of his patch:

> +               unsigned count = SPIN_THRESHOLD;
> +
> +               do {
> +                       if (inc.head == inc.tail)
> +                               goto out;
> +                       cpu_relax();
> +                       inc.head = ACCESS_ONCE(lock->tickets.head);
> +               } while (--count);
> +               __ticket_lock_spinning(lock, inc.tail);


That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.

Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.

Imagine we have a contended host. Every vcpu gets at most 10% of a real CPU's runtime. So chances are 1:10 that you're currently running while you need to be. In such a setup, it's probably a good idea to be very pessimistic. Try to fetch the lock for 100 cycles and then immediately make room for all the other VMs that have real work going on!

So what I'm trying to get to is that if we had a hypervisor settable spin threshold, we could adjust it according to the host's load, getting VMs to behave differently on different (guest invisible) circumstances.

Speaking of which - don't we have spin lock counters in the CPUs now? I thought we could set intercepts that notify us when the guest issues too many repz nops or whatever the typical spinlock identifier was. Can't we reuse that and just interrupt the guest if we see this with a special KVM interrupt that kicks off the internal spin lock waiting code? That way we don't slow down all those bare metal boxes.

Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.

> 
> Changes in V4:
> - reabsed to 3.2.0 pre.
> - use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching. (Avi)
> - fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
>  changes for UNHALT path to make pv ticket spinlock migration friendly. (Avi, Marcello)
> - Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
>  and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
> - Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
> - cumulative variable type changed (int ==> u32) in add_stat (Konrad)
> - remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case
> 
> 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 (5): 
>  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
>  Add documentation on Hypercalls and features used for PV spinlock
> 
> Test Set up :
> The BASE patch is pre 3.2.0 + Jeremy's following patches.
> xadd (https://lkml.org/lkml/2011/10/4/328)
> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
> Kernel for host/guest : 3.2.0 + Jeremy's xadd, pv spinlock patches as BASE
> (Note:locked add change is not taken yet)
> 
> Results:
> The performance gain is mainly because of reduced busy-wait time.
> 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 (non PLE).
> On PLE machine we do not see greater performance improvement because of PLE
> complimenting halt()
> 
> 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
> 
> scenario B: unpinned, run kernbench on all the guests no hogs.
> 
> Dbench on PLE machine:
> dbench run on all the guest simultaneously with
> dbench --warmup=30 -t 120 with NRCLIENTS=(8/16/32).
> 
> 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:	 164.233 (16.5506) 	 163.584 (15.4598 	0.39517
> case 2x:	 897.654 (543.993) 	 328.63 (103.771) 	63.3901
> case 3x:	 2855.73 (2201.41) 	 315.029 (111.854) 	88.9685
> 
> Dbench:
> Throughput is in MB/sec
> NRCLIENTS	 BASE                    BASE+patch            %improvement
>               	 mean (sd)               mean (sd)
> 8       	1.774307  (0.061361) 	1.725667  (0.034644) 	-2.74135
> 16      	1.445967  (0.044805) 	1.463173  (0.094399) 	1.18993
> 32        	2.136667  (0.105717) 	2.193792  (0.129357) 	2.67356
> 
> 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
> 
> Kernbench:
> 		 BASE                    BASE+patch            %improvement
> 		 mean (sd)               mean (sd)
> Scenario A:	 			
> case 1x:	 161.263 (56.518) 	 159.635 (40.5621) 	1.00953
> case 2x:	 190.748 (61.2745) 	 190.606 (54.4766) 	0.0744438
> case 3x:	 227.378 (100.215) 	 225.442 (92.0809) 	0.851446
> 
> Scenario B:
> 		 446.104 (58.54 )	 433.12733 (54.476)	2.91
> 
> Dbench:
> Throughput is in MB/sec
> NRCLIENTS	 BASE                    BASE+patch            %improvement
>               	 mean (sd)               mean (sd)
> 8       	1.101190  (0.875082) 	1.700395  (0.846809) 	54.4143
> 16      	1.524312  (0.120354) 	1.477553  (0.058166) 	-3.06755
> 32        	2.143028  (0.157103) 	2.090307  (0.136778) 	-2.46012

So on a very contended system we're actually slower? Is this expected?


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:26:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmkhd-0001AP-Pm; Mon, 16 Jan 2012 11:26:17 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1Rmdhm-0002LD-Ec
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 03:57:58 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326686271!9256555!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10876 invoked from network); 16 Jan 2012 03:57:51 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 03:57:51 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id B56D889471;
	Mon, 16 Jan 2012 04:57:50 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
Date: Mon, 16 Jan 2012 04:57:45 +0100
Message-Id: <3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 14.01.2012, at 19:25, Raghavendra K T wrote:

> The 5-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.

Is the code for this even upstream? Prerequisite series seem to have been posted by Jeremy, but they didn't appear to have made it in yet.

Either way, thinking about this I stumbled over the following passage of his patch:

> +               unsigned count = SPIN_THRESHOLD;
> +
> +               do {
> +                       if (inc.head == inc.tail)
> +                               goto out;
> +                       cpu_relax();
> +                       inc.head = ACCESS_ONCE(lock->tickets.head);
> +               } while (--count);
> +               __ticket_lock_spinning(lock, inc.tail);


That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.

Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.

Imagine we have a contended host. Every vcpu gets at most 10% of a real CPU's runtime. So chances are 1:10 that you're currently running while you need to be. In such a setup, it's probably a good idea to be very pessimistic. Try to fetch the lock for 100 cycles and then immediately make room for all the other VMs that have real work going on!

So what I'm trying to get to is that if we had a hypervisor settable spin threshold, we could adjust it according to the host's load, getting VMs to behave differently on different (guest invisible) circumstances.

Speaking of which - don't we have spin lock counters in the CPUs now? I thought we could set intercepts that notify us when the guest issues too many repz nops or whatever the typical spinlock identifier was. Can't we reuse that and just interrupt the guest if we see this with a special KVM interrupt that kicks off the internal spin lock waiting code? That way we don't slow down all those bare metal boxes.

Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.

> 
> Changes in V4:
> - reabsed to 3.2.0 pre.
> - use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching. (Avi)
> - fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
>  changes for UNHALT path to make pv ticket spinlock migration friendly. (Avi, Marcello)
> - Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
>  and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
> - Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
> - cumulative variable type changed (int ==> u32) in add_stat (Konrad)
> - remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case
> 
> 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 (5): 
>  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
>  Add documentation on Hypercalls and features used for PV spinlock
> 
> Test Set up :
> The BASE patch is pre 3.2.0 + Jeremy's following patches.
> xadd (https://lkml.org/lkml/2011/10/4/328)
> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
> Kernel for host/guest : 3.2.0 + Jeremy's xadd, pv spinlock patches as BASE
> (Note:locked add change is not taken yet)
> 
> Results:
> The performance gain is mainly because of reduced busy-wait time.
> 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 (non PLE).
> On PLE machine we do not see greater performance improvement because of PLE
> complimenting halt()
> 
> 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
> 
> scenario B: unpinned, run kernbench on all the guests no hogs.
> 
> Dbench on PLE machine:
> dbench run on all the guest simultaneously with
> dbench --warmup=30 -t 120 with NRCLIENTS=(8/16/32).
> 
> 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:	 164.233 (16.5506) 	 163.584 (15.4598 	0.39517
> case 2x:	 897.654 (543.993) 	 328.63 (103.771) 	63.3901
> case 3x:	 2855.73 (2201.41) 	 315.029 (111.854) 	88.9685
> 
> Dbench:
> Throughput is in MB/sec
> NRCLIENTS	 BASE                    BASE+patch            %improvement
>               	 mean (sd)               mean (sd)
> 8       	1.774307  (0.061361) 	1.725667  (0.034644) 	-2.74135
> 16      	1.445967  (0.044805) 	1.463173  (0.094399) 	1.18993
> 32        	2.136667  (0.105717) 	2.193792  (0.129357) 	2.67356
> 
> 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
> 
> Kernbench:
> 		 BASE                    BASE+patch            %improvement
> 		 mean (sd)               mean (sd)
> Scenario A:	 			
> case 1x:	 161.263 (56.518) 	 159.635 (40.5621) 	1.00953
> case 2x:	 190.748 (61.2745) 	 190.606 (54.4766) 	0.0744438
> case 3x:	 227.378 (100.215) 	 225.442 (92.0809) 	0.851446
> 
> Scenario B:
> 		 446.104 (58.54 )	 433.12733 (54.476)	2.91
> 
> Dbench:
> Throughput is in MB/sec
> NRCLIENTS	 BASE                    BASE+patch            %improvement
>               	 mean (sd)               mean (sd)
> 8       	1.101190  (0.875082) 	1.700395  (0.846809) 	54.4143
> 16      	1.524312  (0.120354) 	1.477553  (0.058166) 	-3.06755
> 32        	2.143028  (0.157103) 	2.090307  (0.136778) 	-2.46012

So on a very contended system we're actually slower? Is this expected?


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhe-0001B7-J3; Mon, 16 Jan 2012 11:26:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RmgG5-0003Bi-Fd
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 06:41:33 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326696084!11167821!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29502 invoked from network); 16 Jan 2012 06:41:26 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 06:41:26 -0000
Received: from [192.168.0.14] (114-198-86-3.dyn.iinet.net.au [114.198.86.3])
	(Authenticated sender: jeremy)
	by claw.goop.org (Postfix) with ESMTPSA id BC3DA8F89;
	Sun, 15 Jan 2012 22:41:13 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Jeremy Fitzhardinge <jeremy@goop.org>
In-Reply-To: <3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
Date: Mon, 16 Jan 2012 17:40:58 +1100
Message-Id: <03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
To: Alexander Graf <agraf@suse.de>
X-Mailer: Apple Mail (2.1251.1)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Jan 16, 2012, at 2:57 PM, Alexander Graf wrote:

> 
> On 14.01.2012, at 19:25, Raghavendra K T wrote:
> 
>> The 5-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.
> 
> Is the code for this even upstream? Prerequisite series seem to have been posted by Jeremy, but they didn't appear to have made it in yet.

No, not yet.  The patches are unchanged since I last posted them, and as far as I know there are no objections to them, but I'd like to get some performance numbers just to make sure they don't cause any surprising regressions, especially in the non-virtual case.

> 
> Either way, thinking about this I stumbled over the following passage of his patch:
> 
>> +               unsigned count = SPIN_THRESHOLD;
>> +
>> +               do {
>> +                       if (inc.head == inc.tail)
>> +                               goto out;
>> +                       cpu_relax();
>> +                       inc.head = ACCESS_ONCE(lock->tickets.head);
>> +               } while (--count);
>> +               __ticket_lock_spinning(lock, inc.tail);
> 
> 
> That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
> 
> Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.

I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.

> 
> Imagine we have a contended host. Every vcpu gets at most 10% of a real CPU's runtime. So chances are 1:10 that you're currently running while you need to be. In such a setup, it's probably a good idea to be very pessimistic. Try to fetch the lock for 100 cycles and then immediately make room for all the other VMs that have real work going on!

Are you saying the threshold should be dynamic depending on how loaded the system is?  How can a guest know what the overall system contention is?  How should a guest use that to work out a good spin time?

One possibility is to use the ticket lock queue depth to work out how contended the lock is, and therefore how long it might be worth waiting for.  I was thinking of something along the lines of "threshold = (THRESHOLD >> queue_depth)".  But that's pure hand wave, and someone would actually need to experiment before coming up with something reasonable.

But all of this is good to consider for future work, rather than being essential for the first version.

> So what I'm trying to get to is that if we had a hypervisor settable spin threshold, we could adjust it according to the host's load, getting VMs to behave differently on different (guest invisible) circumstances.
> 
> Speaking of which - don't we have spin lock counters in the CPUs now? I thought we could set intercepts that notify us when the guest issues too many repz nops or whatever the typical spinlock identifier was. Can't we reuse that and just interrupt the guest if we see this with a special KVM interrupt that kicks off the internal spin lock waiting code? That way we don't slow down all those bare metal boxes.

Yes, that mechanism exists, but it doesn't solve a very interesting problem.

The most important thing to solve is making sure that when *releasing* a ticketlock, the correct next VCPU gets scheduled promptly.  If you don't, you're just relying on the VCPU scheduler getting around to scheduling the correct VCPU, but if it doesn't it just ends up burning a timeslice of PCPU time while the wrong VCPU spins.

Limiting the spin time with a timeout or the rep/nop interrupt somewhat mitigates this, but it still means you end up spending a lot of time slices spinning the wrong VCPU until it finally schedules the correct one.  And the more contended the machine is, the worse the problem gets.

> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.

The whole point of the pv-ticketlock work is to keep the pvops hooks out of the locking fast path, so that the calls are only made on the slow path - that is, when spinning too long on a contended lock, and when releasing a lock that's in a "slow" state.  In the fast path case of no contention, there are no pvops, and the executed code path is almost identical to native.

But as I mentioned above, I'd like to see some benchmarks to prove that's the case.

	J

> 
>> 
>> Changes in V4:
>> - reabsed to 3.2.0 pre.
>> - use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching. (Avi)
>> - fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
>> changes for UNHALT path to make pv ticket spinlock migration friendly. (Avi, Marcello)
>> - Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
>> and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
>> - Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
>> - cumulative variable type changed (int ==> u32) in add_stat (Konrad)
>> - remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case
>> 
>> 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 (5): 
>> 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
>> Add documentation on Hypercalls and features used for PV spinlock
>> 
>> Test Set up :
>> The BASE patch is pre 3.2.0 + Jeremy's following patches.
>> xadd (https://lkml.org/lkml/2011/10/4/328)
>> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
>> Kernel for host/guest : 3.2.0 + Jeremy's xadd, pv spinlock patches as BASE
>> (Note:locked add change is not taken yet)
>> 
>> Results:
>> The performance gain is mainly because of reduced busy-wait time.
>> 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 (non PLE).
>> On PLE machine we do not see greater performance improvement because of PLE
>> complimenting halt()
>> 
>> 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
>> 
>> scenario B: unpinned, run kernbench on all the guests no hogs.
>> 
>> Dbench on PLE machine:
>> dbench run on all the guest simultaneously with
>> dbench --warmup=30 -t 120 with NRCLIENTS=(8/16/32).
>> 
>> 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:	 164.233 (16.5506) 	 163.584 (15.4598 	0.39517
>> case 2x:	 897.654 (543.993) 	 328.63 (103.771) 	63.3901
>> case 3x:	 2855.73 (2201.41) 	 315.029 (111.854) 	88.9685
>> 
>> Dbench:
>> Throughput is in MB/sec
>> NRCLIENTS	 BASE                    BASE+patch            %improvement
>>              	 mean (sd)               mean (sd)
>> 8       	1.774307  (0.061361) 	1.725667  (0.034644) 	-2.74135
>> 16      	1.445967  (0.044805) 	1.463173  (0.094399) 	1.18993
>> 32        	2.136667  (0.105717) 	2.193792  (0.129357) 	2.67356
>> 
>> 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
>> 
>> Kernbench:
>> 		 BASE                    BASE+patch            %improvement
>> 		 mean (sd)               mean (sd)
>> Scenario A:	 			
>> case 1x:	 161.263 (56.518) 	 159.635 (40.5621) 	1.00953
>> case 2x:	 190.748 (61.2745) 	 190.606 (54.4766) 	0.0744438
>> case 3x:	 227.378 (100.215) 	 225.442 (92.0809) 	0.851446
>> 
>> Scenario B:
>> 		 446.104 (58.54 )	 433.12733 (54.476)	2.91
>> 
>> Dbench:
>> Throughput is in MB/sec
>> NRCLIENTS	 BASE                    BASE+patch            %improvement
>>              	 mean (sd)               mean (sd)
>> 8       	1.101190  (0.875082) 	1.700395  (0.846809) 	54.4143
>> 16      	1.524312  (0.120354) 	1.477553  (0.058166) 	-3.06755
>> 32        	2.143028  (0.157103) 	2.090307  (0.136778) 	-2.46012
> 
> So on a very contended system we're actually slower? Is this expected?
> 
> 
> Alex
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:26:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rmkhe-0001B7-J3; Mon, 16 Jan 2012 11:26:18 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RmgG5-0003Bi-Fd
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 06:41:33 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326696084!11167821!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29502 invoked from network); 16 Jan 2012 06:41:26 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 06:41:26 -0000
Received: from [192.168.0.14] (114-198-86-3.dyn.iinet.net.au [114.198.86.3])
	(Authenticated sender: jeremy)
	by claw.goop.org (Postfix) with ESMTPSA id BC3DA8F89;
	Sun, 15 Jan 2012 22:41:13 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Jeremy Fitzhardinge <jeremy@goop.org>
In-Reply-To: <3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
Date: Mon, 16 Jan 2012 17:40:58 +1100
Message-Id: <03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
To: Alexander Graf <agraf@suse.de>
X-Mailer: Apple Mail (2.1251.1)
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Jan 16, 2012, at 2:57 PM, Alexander Graf wrote:

> 
> On 14.01.2012, at 19:25, Raghavendra K T wrote:
> 
>> The 5-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.
> 
> Is the code for this even upstream? Prerequisite series seem to have been posted by Jeremy, but they didn't appear to have made it in yet.

No, not yet.  The patches are unchanged since I last posted them, and as far as I know there are no objections to them, but I'd like to get some performance numbers just to make sure they don't cause any surprising regressions, especially in the non-virtual case.

> 
> Either way, thinking about this I stumbled over the following passage of his patch:
> 
>> +               unsigned count = SPIN_THRESHOLD;
>> +
>> +               do {
>> +                       if (inc.head == inc.tail)
>> +                               goto out;
>> +                       cpu_relax();
>> +                       inc.head = ACCESS_ONCE(lock->tickets.head);
>> +               } while (--count);
>> +               __ticket_lock_spinning(lock, inc.tail);
> 
> 
> That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
> 
> Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.

I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.

> 
> Imagine we have a contended host. Every vcpu gets at most 10% of a real CPU's runtime. So chances are 1:10 that you're currently running while you need to be. In such a setup, it's probably a good idea to be very pessimistic. Try to fetch the lock for 100 cycles and then immediately make room for all the other VMs that have real work going on!

Are you saying the threshold should be dynamic depending on how loaded the system is?  How can a guest know what the overall system contention is?  How should a guest use that to work out a good spin time?

One possibility is to use the ticket lock queue depth to work out how contended the lock is, and therefore how long it might be worth waiting for.  I was thinking of something along the lines of "threshold = (THRESHOLD >> queue_depth)".  But that's pure hand wave, and someone would actually need to experiment before coming up with something reasonable.

But all of this is good to consider for future work, rather than being essential for the first version.

> So what I'm trying to get to is that if we had a hypervisor settable spin threshold, we could adjust it according to the host's load, getting VMs to behave differently on different (guest invisible) circumstances.
> 
> Speaking of which - don't we have spin lock counters in the CPUs now? I thought we could set intercepts that notify us when the guest issues too many repz nops or whatever the typical spinlock identifier was. Can't we reuse that and just interrupt the guest if we see this with a special KVM interrupt that kicks off the internal spin lock waiting code? That way we don't slow down all those bare metal boxes.

Yes, that mechanism exists, but it doesn't solve a very interesting problem.

The most important thing to solve is making sure that when *releasing* a ticketlock, the correct next VCPU gets scheduled promptly.  If you don't, you're just relying on the VCPU scheduler getting around to scheduling the correct VCPU, but if it doesn't it just ends up burning a timeslice of PCPU time while the wrong VCPU spins.

Limiting the spin time with a timeout or the rep/nop interrupt somewhat mitigates this, but it still means you end up spending a lot of time slices spinning the wrong VCPU until it finally schedules the correct one.  And the more contended the machine is, the worse the problem gets.

> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.

The whole point of the pv-ticketlock work is to keep the pvops hooks out of the locking fast path, so that the calls are only made on the slow path - that is, when spinning too long on a contended lock, and when releasing a lock that's in a "slow" state.  In the fast path case of no contention, there are no pvops, and the executed code path is almost identical to native.

But as I mentioned above, I'd like to see some benchmarks to prove that's the case.

	J

> 
>> 
>> Changes in V4:
>> - reabsed to 3.2.0 pre.
>> - use APIC ID for kicking the vcpu and use kvm_apic_match_dest for matching. (Avi)
>> - fold vcpu->kicked flag into vcpu->requests (KVM_REQ_PVLOCK_KICK) and related 
>> changes for UNHALT path to make pv ticket spinlock migration friendly. (Avi, Marcello)
>> - Added Documentation for CPUID, Hypercall (KVM_HC_KICK_CPU)
>> and capabilty (KVM_CAP_PVLOCK_KICK) (Avi)
>> - Remove unneeded kvm_arch_vcpu_ioctl_set_mpstate call. (Marcello)
>> - cumulative variable type changed (int ==> u32) in add_stat (Konrad)
>> - remove unneeded kvm_guest_init for !CONFIG_KVM_GUEST case
>> 
>> 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 (5): 
>> 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
>> Add documentation on Hypercalls and features used for PV spinlock
>> 
>> Test Set up :
>> The BASE patch is pre 3.2.0 + Jeremy's following patches.
>> xadd (https://lkml.org/lkml/2011/10/4/328)
>> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
>> Kernel for host/guest : 3.2.0 + Jeremy's xadd, pv spinlock patches as BASE
>> (Note:locked add change is not taken yet)
>> 
>> Results:
>> The performance gain is mainly because of reduced busy-wait time.
>> 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 (non PLE).
>> On PLE machine we do not see greater performance improvement because of PLE
>> complimenting halt()
>> 
>> 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
>> 
>> scenario B: unpinned, run kernbench on all the guests no hogs.
>> 
>> Dbench on PLE machine:
>> dbench run on all the guest simultaneously with
>> dbench --warmup=30 -t 120 with NRCLIENTS=(8/16/32).
>> 
>> 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:	 164.233 (16.5506) 	 163.584 (15.4598 	0.39517
>> case 2x:	 897.654 (543.993) 	 328.63 (103.771) 	63.3901
>> case 3x:	 2855.73 (2201.41) 	 315.029 (111.854) 	88.9685
>> 
>> Dbench:
>> Throughput is in MB/sec
>> NRCLIENTS	 BASE                    BASE+patch            %improvement
>>              	 mean (sd)               mean (sd)
>> 8       	1.774307  (0.061361) 	1.725667  (0.034644) 	-2.74135
>> 16      	1.445967  (0.044805) 	1.463173  (0.094399) 	1.18993
>> 32        	2.136667  (0.105717) 	2.193792  (0.129357) 	2.67356
>> 
>> 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
>> 
>> Kernbench:
>> 		 BASE                    BASE+patch            %improvement
>> 		 mean (sd)               mean (sd)
>> Scenario A:	 			
>> case 1x:	 161.263 (56.518) 	 159.635 (40.5621) 	1.00953
>> case 2x:	 190.748 (61.2745) 	 190.606 (54.4766) 	0.0744438
>> case 3x:	 227.378 (100.215) 	 225.442 (92.0809) 	0.851446
>> 
>> Scenario B:
>> 		 446.104 (58.54 )	 433.12733 (54.476)	2.91
>> 
>> Dbench:
>> Throughput is in MB/sec
>> NRCLIENTS	 BASE                    BASE+patch            %improvement
>>              	 mean (sd)               mean (sd)
>> 8       	1.101190  (0.875082) 	1.700395  (0.846809) 	54.4143
>> 16      	1.524312  (0.120354) 	1.477553  (0.058166) 	-3.06755
>> 32        	2.143028  (0.157103) 	2.090307  (0.136778) 	-2.46012
> 
> So on a very contended system we're actually slower? Is this expected?
> 
> 
> Alex
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 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 1Rmkhb-00018w-Na; Mon, 16 Jan 2012 11:26:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8KB-0002KS-Ui
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:27:32 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326565581!60980449!1
X-Originating-IP: [32.97.182.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NSA9PiA1MzM1OTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16598 invoked from network); 14 Jan 2012 18:26:22 -0000
Received: from e5.ny.us.ibm.com (HELO e5.ny.us.ibm.com) (32.97.182.145)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:26:22 -0000
Received: from /spool/local
	by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Sat, 14 Jan 2012 13:27:26 -0500
Received: from d01relay03.pok.ibm.com (9.56.227.235)
	by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:27:24 -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
	q0EIROGw319024
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:27:24 -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
	q0EIRMAo003728
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:27:24 -0500
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIR8mR003012; Sat, 14 Jan 2012 13:27:10 -0500
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:57:11 +0530
Message-Id: <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-5930-0000-0000-0000041E8A35
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 Documentation on CPUID, KVM_CAP_PVLOCK_KICK, and Hypercalls supported.

KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in
paravirtual spinlock enabled guest.

KVM_FEATURE_PVLOCK_KICK enables guest to check whether pv spinlock can
be enabled in guest. support in host is queried via
ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)

A minimal Documentation and template is added for hypercalls.

Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
---
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index e2a4b52..1583bc7 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1109,6 +1109,13 @@ support.  Instead it is reported via
 if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
 feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
 
+Paravirtualized ticket spinlocks can be enabled in guest by checking whether
+support exists in host via,
+
+  ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
+
+if this call return true, guest can use the feature.
+
 4.47 KVM_PPC_GET_PVINFO
 
 Capability: KVM_CAP_PPC_GET_PVINFO
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index 8820685..c7fc0da 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
 KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
                                    ||       || writing to msr 0x4b564d02
 ------------------------------------------------------------------------------
+KVM_FEATURE_PVLOCK_KICK            ||     6 || guest checks this feature bit
+                                   ||       || before enabling paravirtualized
+                                   ||       || spinlock support.
+------------------------------------------------------------------------------
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
                                    ||       || per-cpu warps are expected in
                                    ||       || kvmclock.
diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
new file mode 100644
index 0000000..7872da5
--- /dev/null
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -0,0 +1,54 @@
+KVM Hypercalls Documentation
+===========================
+Template for documentation is
+The documenenation for hypercalls should inlcude
+1. Hypercall name, value.
+2. Architecture(s)
+3. Purpose
+
+
+1. KVM_HC_VAPIC_POLL_IRQ
+------------------------
+value: 1
+Architecture: x86
+Purpose:
+
+2. KVM_HC_MMU_OP
+------------------------
+value: 2
+Architecture: x86
+Purpose: Support MMU operations such as writing to PTE,
+flushing TLB, release PT.
+
+3. KVM_HC_FEATURES
+------------------------
+value: 3
+Architecture: PPC
+Purpose:
+
+4. KVM_HC_PPC_MAP_MAGIC_PAGE
+------------------------
+value: 4
+Architecture: PPC
+Purpose: To enable communication between the hypervisor and guest there is a
+new shared page that contains parts of supervisor visible register state.
+The guest can map this shared page using this hypercall.
+
+5. KVM_HC_KICK_CPU
+------------------------
+value: 5
+Architecture: x86
+Purpose: Hypercall used to wakeup a vcpu from HLT state
+
+Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
+kernel mode for an event to occur (ex: a spinlock to become available)
+can execute HLT instruction once it has busy-waited for more than a
+threshold time-interval. Execution of HLT instruction would cause
+the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
+of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
+vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
+wokenup.
+
+TODO:
+1. more information on input and output needed?
+2. Add more detail to purpose of hypercalls.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 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 1Rmkhb-00018w-Na; Mon, 16 Jan 2012 11:26:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rm8KB-0002KS-Ui
	for xen-devel@lists.xensource.com; Sat, 14 Jan 2012 18:27:32 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326565581!60980449!1
X-Originating-IP: [32.97.182.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0NSA9PiA1MzM1OTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16598 invoked from network); 14 Jan 2012 18:26:22 -0000
Received: from e5.ny.us.ibm.com (HELO e5.ny.us.ibm.com) (32.97.182.145)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 14 Jan 2012 18:26:22 -0000
Received: from /spool/local
	by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Sat, 14 Jan 2012 13:27:26 -0500
Received: from d01relay03.pok.ibm.com (9.56.227.235)
	by e5.ny.us.ibm.com (192.168.1.105) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Sat, 14 Jan 2012 13:27:24 -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
	q0EIROGw319024
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:27:24 -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
	q0EIRMAo003728
	for <xen-devel@lists.xensource.com>; Sat, 14 Jan 2012 13:27:24 -0500
Received: from oc5400248562.ibm.com ([9.124.223.242])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0EIR8mR003012; Sat, 14 Jan 2012 13:27:10 -0500
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>, Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Glauber Costa <glommer@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Rik van Riel <riel@redhat.com>,
	Dave Jiang <dave.jiang@intel.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Gleb Natapov <gleb@redhat.com>, Avi Kivity <avi@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Paul Mackerras <paulus@samba.org>, Sedat Dilek <sedat.dilek@gmail.com>, 
	Ingo Molnar <mingo@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, Xen <xen-devel@lists.xensource.com>
Date: Sat, 14 Jan 2012 23:57:11 +0530
Message-Id: <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
In-Reply-To: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
x-cbid: 12011418-5930-0000-0000-0000041E8A35
X-Mailman-Approved-At: Mon, 16 Jan 2012 11:26:11 +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 V4 5/5] Documentation/kvm : Add
	documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 Documentation on CPUID, KVM_CAP_PVLOCK_KICK, and Hypercalls supported.

KVM_HC_KICK_CPU  hypercall added to wakeup halted vcpu in
paravirtual spinlock enabled guest.

KVM_FEATURE_PVLOCK_KICK enables guest to check whether pv spinlock can
be enabled in guest. support in host is queried via
ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)

A minimal Documentation and template is added for hypercalls.

Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
---
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index e2a4b52..1583bc7 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1109,6 +1109,13 @@ support.  Instead it is reported via
 if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the
 feature in userspace, then you can enable the feature for KVM_SET_CPUID2.
 
+Paravirtualized ticket spinlocks can be enabled in guest by checking whether
+support exists in host via,
+
+  ioctl(KVM_CHECK_EXTENSION, KVM_CAP_PVLOCK_KICK)
+
+if this call return true, guest can use the feature.
+
 4.47 KVM_PPC_GET_PVINFO
 
 Capability: KVM_CAP_PPC_GET_PVINFO
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index 8820685..c7fc0da 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -39,6 +39,10 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
 KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
                                    ||       || writing to msr 0x4b564d02
 ------------------------------------------------------------------------------
+KVM_FEATURE_PVLOCK_KICK            ||     6 || guest checks this feature bit
+                                   ||       || before enabling paravirtualized
+                                   ||       || spinlock support.
+------------------------------------------------------------------------------
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||    24 || host will warn if no guest-side
                                    ||       || per-cpu warps are expected in
                                    ||       || kvmclock.
diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
new file mode 100644
index 0000000..7872da5
--- /dev/null
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -0,0 +1,54 @@
+KVM Hypercalls Documentation
+===========================
+Template for documentation is
+The documenenation for hypercalls should inlcude
+1. Hypercall name, value.
+2. Architecture(s)
+3. Purpose
+
+
+1. KVM_HC_VAPIC_POLL_IRQ
+------------------------
+value: 1
+Architecture: x86
+Purpose:
+
+2. KVM_HC_MMU_OP
+------------------------
+value: 2
+Architecture: x86
+Purpose: Support MMU operations such as writing to PTE,
+flushing TLB, release PT.
+
+3. KVM_HC_FEATURES
+------------------------
+value: 3
+Architecture: PPC
+Purpose:
+
+4. KVM_HC_PPC_MAP_MAGIC_PAGE
+------------------------
+value: 4
+Architecture: PPC
+Purpose: To enable communication between the hypervisor and guest there is a
+new shared page that contains parts of supervisor visible register state.
+The guest can map this shared page using this hypercall.
+
+5. KVM_HC_KICK_CPU
+------------------------
+value: 5
+Architecture: x86
+Purpose: Hypercall used to wakeup a vcpu from HLT state
+
+Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
+kernel mode for an event to occur (ex: a spinlock to become available)
+can execute HLT instruction once it has busy-waited for more than a
+threshold time-interval. Execution of HLT instruction would cause
+the hypervisor to put the vcpu to sleep (unless yield_on_hlt=0) until occurence
+of an appropriate event. Another vcpu of the same guest can wakeup the sleeping
+vcpu by issuing KVM_HC_KICK_CPU hypercall, specifying APIC ID of the vcpu to be
+wokenup.
+
+TODO:
+1. more information on input and output needed?
+2. Add more detail to purpose of hypercalls.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:46:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rml0w-0007IR-Mt; Mon, 16 Jan 2012 11:46:14 +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 1Rml0v-0007II-G6
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 11:46:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326714365!11176870!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24373 invoked from network); 16 Jan 2012 11:46:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 11:46:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20905812"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 06:46:05 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Jan 2012
	06:46:05 -0500
Message-ID: <4F140DFB.60009@citrix.com>
Date: Mon, 16 Jan 2012 11:46: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: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>	
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>	
	<4F107625.7090601@citrix.com>
	<1326706394.5285.5.camel@liuw-desktop>	
	<1326710711.17210.411.camel@zakaz.uk.xensource.com>	
	<291EDFCB1E9E224A99088639C4762022B5991BEC4D@LONPMAILBOX01.citrite.net>
	<1326712173.17210.412.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326712173.17210.412.camel@zakaz.uk.xensource.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/01/12 11:09, Ian Campbell wrote:
> I think you'd want to keep moving the event pointer to
> handle wrap around, i.e. by keeping it always either far enough away or
> right behind. (I think "req_cons - 1" is probably the correct option
> BTW).

When using RING_FINAL_CHECK_FOR_REQUESTS() as-is you will get an
additional spurious event every 4 billion events.

Something like this would fix it.

#define RING_FINAL_CHECK_FOR_REQUESTS(_r, _work_to_do) do {
    (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
    if (_work_to_do) {
        /* ensure req_event is always in the past to avoid spurious
           interrupt on wrap-around. */
        (_r)->sring->req_event = (_r)->req_cons;
        break;
    }
    (_r)->sring->req_event = (_r)->req_cons + 1;
    mb();
    (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
} while (0)

And similarly for RING_FINAL_CHECK_FOR_RESPONSES().

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:46:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11: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 1Rml0w-0007IR-Mt; Mon, 16 Jan 2012 11:46:14 +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 1Rml0v-0007II-G6
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 11:46:13 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326714365!11176870!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24373 invoked from network); 16 Jan 2012 11:46:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 11:46:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20905812"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 06:46:05 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Jan 2012
	06:46:05 -0500
Message-ID: <4F140DFB.60009@citrix.com>
Date: Mon, 16 Jan 2012 11:46: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: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326473949-22389-1-git-send-email-wei.liu2@citrix.com>	
	<1326473949-22389-4-git-send-email-wei.liu2@citrix.com>	
	<4F107625.7090601@citrix.com>
	<1326706394.5285.5.camel@liuw-desktop>	
	<1326710711.17210.411.camel@zakaz.uk.xensource.com>	
	<291EDFCB1E9E224A99088639C4762022B5991BEC4D@LONPMAILBOX01.citrite.net>
	<1326712173.17210.412.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326712173.17210.412.camel@zakaz.uk.xensource.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH 3/6] netback: switch to NAPI + kthread
 model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/01/12 11:09, Ian Campbell wrote:
> I think you'd want to keep moving the event pointer to
> handle wrap around, i.e. by keeping it always either far enough away or
> right behind. (I think "req_cons - 1" is probably the correct option
> BTW).

When using RING_FINAL_CHECK_FOR_REQUESTS() as-is you will get an
additional spurious event every 4 billion events.

Something like this would fix it.

#define RING_FINAL_CHECK_FOR_REQUESTS(_r, _work_to_do) do {
    (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
    if (_work_to_do) {
        /* ensure req_event is always in the past to avoid spurious
           interrupt on wrap-around. */
        (_r)->sring->req_event = (_r)->req_cons;
        break;
    }
    (_r)->sring->req_event = (_r)->req_cons + 1;
    mb();
    (_work_to_do) = RING_HAS_UNCONSUMED_REQUESTS(_r);
} while (0)

And similarly for RING_FINAL_CHECK_FOR_RESPONSES().

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 11:55:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlA4-0007xm-Ls; Mon, 16 Jan 2012 11:55:40 +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 1RmlA3-0007xf-BO
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 11:55:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326714871!61140778!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 11413 invoked from network); 16 Jan 2012 11:54:32 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 11:54:32 -0000
Received: by iahk25 with SMTP id k25so18674349iah.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 03:55: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=jAVV0/PyvHkg6778BwkWWmHlTj8bO5Q8jxeSKALCt68=;
	b=mFu7FsTAEM89zyw9cjLYcDaLw5AHFWjQUwtnLQ/xppzc6CLLQXc4CWY7RgtNlfoj68
	9l1EkoYaDo9MGJkWis5jx4BcFU1Z2EHXxbTpi1lq/Ue1rn1fSLTMwJYT7YlSUahNUiZz
	ll0ah/WsFekzxefce7LX2lB+fAXeKgv3UDA2Q=
MIME-Version: 1.0
Received: by 10.43.53.1 with SMTP id vo1mr12683114icb.2.1326714936594; Mon, 16
	Jan 2012 03:55:36 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Mon, 16 Jan 2012 03:55:36 -0800 (PST)
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
Date: Mon, 16 Jan 2012 11:55:36 +0000
X-Google-Sender-Auth: EK6241kVVKyy-VQZe9QTvqzGtq4
Message-ID: <CAFLBxZZdPc=oSHwZuZ0d3XB3mXHC7EO+xCEa8S0EbhfV8MEDJA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 4, 2012 at 4:29 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
>
> hypervisor:
>
> =A0 =A0 =A0* ??? - Keir, Tim, Jan?
>
> tools:
>
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* event handling (IanJ working on this)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* drop libxl_device_model_info (move bits to b=
uild_info or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0elsewhere as appropriate) (IanC working on=
 this, patches
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0shortly)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* add libxl_defbool and generally try and arra=
nge that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(foo,0,...) requests the defaults (I=
anC working on
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this, patches shortly)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* The topologyinfo datastructure should be a l=
ist of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tuples, not a tuple of lists. (nobody curr=
ently looking
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at this, not 100% sure this makes sense, c=
ould possibly
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0defer and change after 4.2 in a compatible=
 way)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Block script support -- can be done post 4.2?
> =A0 =A0 =A0* Hotplug script stuff -- internal to libxl (I think, therefor=
e I
> =A0 =A0 =A0 =A0didn't put this under stable API above) but still good to =
have
> =A0 =A0 =A0 =A0for 4.2? Roger Pau Monet was looking at this but its looki=
ng
> =A0 =A0 =A0 =A0like a big can-o-worms...
> =A0 =A0 =A0* Integrate qemu+seabios upstream into the build (Stefano has
> =A0 =A0 =A0 =A0posted patches, I guess they need refreshing and reposting=
). No
> =A0 =A0 =A0 =A0change in default qemu for 4.2.
> =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in
> =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to
> =A0 =A0 =A0 =A0remind people to test xl.
>
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?

Seems like making sure xl has feature parity with xend wrt driver
domains would be something good to make sure we have, if we're going
to be deprecating xend.

>
> 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 Jan 16 11:55:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 11:55:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlA4-0007xm-Ls; Mon, 16 Jan 2012 11:55:40 +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 1RmlA3-0007xf-BO
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 11:55:39 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326714871!61140778!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 11413 invoked from network); 16 Jan 2012 11:54:32 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 11:54:32 -0000
Received: by iahk25 with SMTP id k25so18674349iah.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 03:55: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=jAVV0/PyvHkg6778BwkWWmHlTj8bO5Q8jxeSKALCt68=;
	b=mFu7FsTAEM89zyw9cjLYcDaLw5AHFWjQUwtnLQ/xppzc6CLLQXc4CWY7RgtNlfoj68
	9l1EkoYaDo9MGJkWis5jx4BcFU1Z2EHXxbTpi1lq/Ue1rn1fSLTMwJYT7YlSUahNUiZz
	ll0ah/WsFekzxefce7LX2lB+fAXeKgv3UDA2Q=
MIME-Version: 1.0
Received: by 10.43.53.1 with SMTP id vo1mr12683114icb.2.1326714936594; Mon, 16
	Jan 2012 03:55:36 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Mon, 16 Jan 2012 03:55:36 -0800 (PST)
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
Date: Mon, 16 Jan 2012 11:55:36 +0000
X-Google-Sender-Auth: EK6241kVVKyy-VQZe9QTvqzGtq4
Message-ID: <CAFLBxZZdPc=oSHwZuZ0d3XB3mXHC7EO+xCEa8S0EbhfV8MEDJA@mail.gmail.com>
From: George Dunlap <dunlapg@umich.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 4, 2012 at 4:29 PM, Ian Campbell <Ian.Campbell@citrix.com> wrot=
e:
> What are the outstanding things to do before we think we can start on
> the 4.2 -rc's? Does anyone have a timetable in mind?
>
> hypervisor:
>
> =A0 =A0 =A0* ??? - Keir, Tim, Jan?
>
> tools:
>
> =A0 =A0 =A0* libxl stable API -- we would like 4.2 to define a stable API
> =A0 =A0 =A0 =A0which downstream's can start to rely on not changing. Aspe=
cts of
> =A0 =A0 =A0 =A0this are:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* event handling (IanJ working on this)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* drop libxl_device_model_info (move bits to b=
uild_info or
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0elsewhere as appropriate) (IanC working on=
 this, patches
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0shortly)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* add libxl_defbool and generally try and arra=
nge that
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memset(foo,0,...) requests the defaults (I=
anC working on
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this, patches shortly)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* The topologyinfo datastructure should be a l=
ist of
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tuples, not a tuple of lists. (nobody curr=
ently looking
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0at this, not 100% sure this makes sense, c=
ould possibly
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0defer and change after 4.2 in a compatible=
 way)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0* Block script support -- can be done post 4.2?
> =A0 =A0 =A0* Hotplug script stuff -- internal to libxl (I think, therefor=
e I
> =A0 =A0 =A0 =A0didn't put this under stable API above) but still good to =
have
> =A0 =A0 =A0 =A0for 4.2? Roger Pau Monet was looking at this but its looki=
ng
> =A0 =A0 =A0 =A0like a big can-o-worms...
> =A0 =A0 =A0* Integrate qemu+seabios upstream into the build (Stefano has
> =A0 =A0 =A0 =A0posted patches, I guess they need refreshing and reposting=
). No
> =A0 =A0 =A0 =A0change in default qemu for 4.2.
> =A0 =A0 =A0* More formally deprecate xm/xend. Manpage patches already in
> =A0 =A0 =A0 =A0tree. Needs release noting and communication around -rc1 to
> =A0 =A0 =A0 =A0remind people to test xl.
>
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?

Seems like making sure xl has feature parity with xend wrt driver
domains would be something good to make sure we have, if we're going
to be deprecating xend.

>
> 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 Jan 16 12:03:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:03:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlH9-0008Qs-SS; Mon, 16 Jan 2012 12:02: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 1RmlH8-0008QW-SH; Mon, 16 Jan 2012 12:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326715371!9109170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17658 invoked from network); 16 Jan 2012 12:02:51 -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;
	16 Jan 2012 12:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10045625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12:02: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, 16 Jan 2012 12:02:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, <xen-arm@lists.xensource.com>
Date: Mon, 16 Jan 2012 12:02:50 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/5] ARM: Start working on tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Now that we have an ARM build environment[0] I've made a very basic
start on getting the Xen tools for the ARMv7 w/ virt extensions port to
compile. A short series follows. Nothing too earth shatteringly
exciting...

Currently compiles a fair bit of interesting stuff (libxc, xenstore,
xenconsole) and gets as far as mid way through libxl before it fails due
to CPUID stuff. Solving that needs some more infrastructure work in
libxl to be able to have per-arch members in IDL structs. But I thought
I might as well share what I have now. Note that I've not run any of it.

Obviously the final patch is not to be applied!

Ian.

[0] https://plus.google.com/106815887686504011057/posts/Kgdakxs5cFt


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:03:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:03:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlH9-0008Qs-SS; Mon, 16 Jan 2012 12:02: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 1RmlH8-0008QW-SH; Mon, 16 Jan 2012 12:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326715371!9109170!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17658 invoked from network); 16 Jan 2012 12:02:51 -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;
	16 Jan 2012 12:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10045625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12:02: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, 16 Jan 2012 12:02:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>, <xen-arm@lists.xensource.com>
Date: Mon, 16 Jan 2012 12:02:50 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 0/5] ARM: Start working on tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Now that we have an ARM build environment[0] I've made a very basic
start on getting the Xen tools for the ARMv7 w/ virt extensions port to
compile. A short series follows. Nothing too earth shatteringly
exciting...

Currently compiles a fair bit of interesting stuff (libxc, xenstore,
xenconsole) and gets as far as mid way through libxl before it fails due
to CPUID stuff. Solving that needs some more infrastructure work in
libxl to be able to have per-arch members in IDL structs. But I thought
I might as well share what I have now. Note that I've not run any of it.

Obviously the final patch is not to be applied!

Ian.

[0] https://plus.google.com/106815887686504011057/posts/Kgdakxs5cFt


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT3-0000zz-QP; Mon, 16 Jan 2012 12:15:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT2-0000wR-4f
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5167 invoked from network); 16 Jan 2012 12:15:08 -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;
	16 Jan 2012 12:15:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907086"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0ct032155;	Mon, 16 Jan 2012 04:15:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: ed7106b3f874d93e8ed8d05a8464099e611edd0b
Message-ID: <ed7106b3f874d93e8ed8.1326716103@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 32 RFC] libxl: define libxl_vnc_info to
 hold all info about the vnc info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326212392 0
# Node ID ed7106b3f874d93e8ed8d05a8464099e611edd0b
# Parent  d5c8efa9ef9e55a08e06a6011681bdb827dd88c7
libxl: define libxl_vnc_info to hold all info about the vnc info

Reduces duplication in libxl_vfb and libxl_device_model.

Updated bindings but the python ones in particular are unlikely to be useful
until a user presents itself and fixes them up.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Jan 10 16:19:52 2012 +0000
@@ -1954,11 +1954,11 @@ int libxl_device_vfb_init(libxl_ctx *ctx
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     vfb->display = NULL;
     vfb->xauthority = NULL;
-    vfb->vnc = 1;
-    vfb->vncpasswd = NULL;
-    vfb->vnclisten = strdup("127.0.0.1");
-    vfb->vncdisplay = 0;
-    vfb->vncunused = 1;
+    vfb->vnc.enable = 1;
+    vfb->vnc.passwd = NULL;
+    vfb->vnc.listen = strdup("127.0.0.1");
+    vfb->vnc.display = 0;
+    vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
     vfb->sdl = 0;
     vfb->opengl = 0;
@@ -2004,11 +2004,14 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     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, "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, "vnc",
+                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+    flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
+    flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
+    flexarray_append_pair(back, "vncdisplay",
+                          libxl__sprintf(gc, "%d", vfb->vnc.display));
+    flexarray_append_pair(back, "vncunused",
+                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
     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) {
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/libxl_create.c	Tue Jan 10 16:19:52 2012 +0000
@@ -132,10 +132,10 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->vcpu_avail = b_info->cur_vcpus;
 
     dm_info->stdvga = 0;
-    dm_info->vnc = 1;
-    dm_info->vnclisten = strdup("127.0.0.1");
-    dm_info->vncdisplay = 0;
-    dm_info->vncunused = 1;
+    dm_info->vnc.enable = 1;
+    dm_info->vnc.listen = strdup("127.0.0.1");
+    dm_info->vnc.display = 0;
+    dm_info->vnc.findunused = 1;
     dm_info->keymap = NULL;
     dm_info->sdl = 0;
     dm_info->opengl = 0;
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Jan 10 16:19:52 2012 +0000
@@ -100,31 +100,31 @@ static char ** libxl__build_device_model
     if (info->dom_name)
         flexarray_vappend(dm_args, "-domain-name", info->dom_name, NULL);
 
-    if (info->vnc) {
+    if (info->vnc.enable) {
         char *vncarg;
-        if (info->vncdisplay) {
-            if (info->vnclisten && strchr(info->vnclisten, ':') == NULL) {
+        if (info->vnc.display) {
+            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
                 vncarg = libxl__sprintf(gc, "%s:%d",
-                                  info->vnclisten,
-                                  info->vncdisplay);
+                                  info->vnc.listen,
+                                  info->vnc.display);
             } else {
-                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vncdisplay);
+                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vnc.display);
             }
-        } else if (info->vnclisten) {
-            if (strchr(info->vnclisten, ':') != NULL) {
-                vncarg = info->vnclisten;
+        } else if (info->vnc.listen) {
+            if (strchr(info->vnc.listen, ':') != NULL) {
+                vncarg = info->vnc.listen;
             } else {
-                vncarg = libxl__sprintf(gc, "%s:0", info->vnclisten);
+                vncarg = libxl__sprintf(gc, "%s:0", info->vnc.listen);
             }
         } else {
             vncarg = "127.0.0.1:0";
         }
-        if (info->vncpasswd && (info->vncpasswd[0] != '\0'))
+        if (info->vnc.passwd && (info->vnc.passwd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (info->vncunused) {
+        if (info->vnc.findunused) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
@@ -137,7 +137,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc)) {
+    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -268,32 +268,32 @@ static char ** libxl__build_device_model
     if (info->dom_name) {
         flexarray_vappend(dm_args, "-name", info->dom_name, NULL);
     }
-    if (info->vnc) {
+    if (info->vnc.enable) {
         int display = 0;
         const char *listen = "127.0.0.1";
 
-        if (info->vncpasswd && info->vncpasswd[0]) {
+        if (info->vnc.passwd && info->vnc.passwd[0]) {
             assert(!"missing code for supplying vnc password to qemu");
         }
         flexarray_append(dm_args, "-vnc");
 
-        if (info->vncdisplay) {
-            display = info->vncdisplay;
-            if (info->vnclisten && strchr(info->vnclisten, ':') == NULL) {
-                listen = info->vnclisten;
+        if (info->vnc.display) {
+            display = info->vnc.display;
+            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
+                listen = info->vnc.listen;
             }
-        } else if (info->vnclisten) {
-            listen = info->vnclisten;
+        } else if (info->vnc.listen) {
+            listen = info->vnc.listen;
         }
 
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        info->vncunused ? ",to=99" : ""));
+                        info->vnc.findunused ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vncunused ? ",to=99" : ""));
+                        info->vnc.findunused ? ",to=99" : ""));
     }
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -343,7 +343,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc)) {
+    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -532,10 +532,6 @@ static int libxl__vfb_and_vkb_from_devic
     vfb->backend_domid = 0;
     vfb->devid = 0;
     vfb->vnc = info->vnc;
-    vfb->vnclisten = info->vnclisten;
-    vfb->vncdisplay = info->vncdisplay;
-    vfb->vncunused = info->vncunused;
-    vfb->vncpasswd = info->vncpasswd;
     vfb->keymap = info->keymap;
     vfb->sdl = info->sdl;
     vfb->opengl = info->opengl;
@@ -861,7 +857,7 @@ int libxl__create_device_model(libxl__gc
         goto out_close;
     }
 
-    if (info->vncpasswd) {
+    if (info->vnc.passwd) {
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
@@ -870,7 +866,7 @@ retry_transaction:
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
             pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = info->vncpasswd;
+            pass_stuff[1] = info->vnc.passwd;
             libxl__xs_writev(gc,t,vm_path,pass_stuff);
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
@@ -985,13 +981,13 @@ static int libxl__build_xenpv_qemu_args(
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     if (vfb != NULL) {
-        info->vnc = vfb->vnc;
-        if (vfb->vnclisten)
-            info->vnclisten = libxl__strdup(gc, vfb->vnclisten);
-        info->vncdisplay = vfb->vncdisplay;
-        info->vncunused = vfb->vncunused;
-        if (vfb->vncpasswd)
-            info->vncpasswd = vfb->vncpasswd;
+        info->vnc.enable = vfb->vnc.enable;
+        if (vfb->vnc.listen)
+            info->vnc.listen = libxl__strdup(gc, vfb->vnc.listen);
+        info->vnc.display = vfb->vnc.display;
+        info->vnc.findunused = vfb->vnc.findunused;
+        if (vfb->vnc.passwd)
+            info->vnc.passwd = vfb->vnc.passwd;
         if (vfb->keymap)
             info->keymap = libxl__strdup(gc, vfb->keymap);
         info->sdl = vfb->sdl;
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 16:19:52 2012 +0000
@@ -95,6 +95,16 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 #
 # Complex libxl types
 #
+libxl_vnc_info = Struct("vnc_info", [
+    ("enable",        bool),
+    # "address:port" that should be listened on
+    ("listen",        string),
+    ("passwd",        string),
+    ("display",       integer),
+    # If set then try to find an unused port
+    ("findunused",    bool),
+    ])
+
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
@@ -222,14 +232,7 @@ libxl_device_model_info = Struct("device
     # size of the videoram in MB
     ("videoram",         integer), 
     ("stdvga",           bool),
-    ("vnc",              bool),
-    # "address:port" that should be listened on for the VNC server
-    ("vnclisten",        string),
-    ("vncpasswd",        string),
-    # VNC display number
-    ("vncdisplay",       integer),
-    # If set then try to find an unused port for the VNC server
-    ("vncunused",        bool),
+    ("vnc",              libxl_vnc_info),
     # keyboard layout, default is en-us keyboard
     ("keymap",           string),
     ("sdl",              bool),
@@ -268,12 +271,7 @@ libxl_device_model_info = Struct("device
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
-    ("vnc",           bool),
-    # address:port that should be listened on for the VNC server if vnc is set
-    ("vnclisten",     string),
-    ("vncpasswd",     string),
-    ("vncdisplay",    integer),
-    ("vncunused",     bool),
+    ("vnc",           libxl_vnc_info),
     # set keyboard layout, default is en-us keyboard
     ("keymap",        string),
     ("sdl",           bool),
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 16:19:52 2012 +0000
@@ -364,10 +364,10 @@ static void printf_info(int domid,
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
         printf("\t\t\t(stdvga %d)\n", dm_info->stdvga);
-        printf("\t\t\t(vnc %d)\n", dm_info->vnc);
-        printf("\t\t\t(vnclisten %s)\n", dm_info->vnclisten);
-        printf("\t\t\t(vncdisplay %d)\n", dm_info->vncdisplay);
-        printf("\t\t\t(vncunused %d)\n", dm_info->vncunused);
+        printf("\t\t\t(vnc %d)\n", dm_info->vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", dm_info->vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
+        printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
         printf("\t\t\t(keymap %s)\n", dm_info->keymap);
         printf("\t\t\t(sdl %d)\n", dm_info->sdl);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
@@ -454,10 +454,10 @@ static void printf_info(int domid,
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc);
-        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnclisten);
-        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vncdisplay);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vncunused);
+        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
+        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
         printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl);
         printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].opengl);
@@ -961,17 +961,17 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc = atoi(p2 + 1);
+                    vfb->vnc.enable = atoi(p2 + 1);
                 } else if (!strcmp(p, "vnclisten")) {
-                    free(vfb->vnclisten);
-                    vfb->vnclisten = strdup(p2 + 1);
+                    free(vfb->vnc.listen);
+                    vfb->vnc.listen = strdup(p2 + 1);
                 } else if (!strcmp(p, "vncpasswd")) {
-                    free(vfb->vncpasswd);
-                    vfb->vncpasswd = strdup(p2 + 1);
+                    free(vfb->vnc.passwd);
+                    vfb->vnc.passwd = strdup(p2 + 1);
                 } else if (!strcmp(p, "vncdisplay")) {
-                    vfb->vncdisplay = atoi(p2 + 1);
+                    vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vncunused = atoi(p2 + 1);
+                    vfb->vnc.findunused = atoi(p2 + 1);
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
@@ -1178,13 +1178,13 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
         if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+            dm_info->vnc.enable = l;
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
-            dm_info->vncdisplay = l;
+            dm_info->vnc.display = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            dm_info->vncunused = l;
+            dm_info->vnc.findunused = l;
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/python/genwrap.py	Tue Jan 10 16:19:52 2012 +0000
@@ -4,7 +4,7 @@ import sys,os
 
 import libxltypes
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING) = range(4)
+(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
 
 def py_type(ty):
     if ty == libxltypes.bool:
@@ -16,6 +16,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, libxltypes.Aggregate):
+        return TYPE_AGGREGATE
     if ty == libxltypes.string:
         return TYPE_STRING
     return None
@@ -66,6 +68,9 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
+    elif t == TYPE_AGGREGATE:
+        l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
+        l.append('    return NULL;')
     else:
         tn = f.type.typename
         l.append('    return attrib__%s_get((%s *)&self->obj.%s);'%(fsanitize(tn), tn, f.name))
@@ -92,6 +97,9 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
+    elif t == TYPE_AGGREGATE:
+        l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
+        l.append('    return -1;')
     else:
         tn = f.type.typename
         l.append('    return attrib__%s_set(v, (%s *)&self->obj.%s);'%(fsanitize(tn), tn, f.name))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT3-0000zz-QP; Mon, 16 Jan 2012 12:15:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT2-0000wR-4f
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5167 invoked from network); 16 Jan 2012 12:15:08 -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;
	16 Jan 2012 12:15:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907086"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:07 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0ct032155;	Mon, 16 Jan 2012 04:15:06 -0800
MIME-Version: 1.0
X-Mercurial-Node: ed7106b3f874d93e8ed8d05a8464099e611edd0b
Message-ID: <ed7106b3f874d93e8ed8.1326716103@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:03 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 32 RFC] libxl: define libxl_vnc_info to
 hold all info about the vnc info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326212392 0
# Node ID ed7106b3f874d93e8ed8d05a8464099e611edd0b
# Parent  d5c8efa9ef9e55a08e06a6011681bdb827dd88c7
libxl: define libxl_vnc_info to hold all info about the vnc info

Reduces duplication in libxl_vfb and libxl_device_model.

Updated bindings but the python ones in particular are unlikely to be useful
until a user presents itself and fixes them up.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Jan 10 16:19:52 2012 +0000
@@ -1954,11 +1954,11 @@ int libxl_device_vfb_init(libxl_ctx *ctx
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     vfb->display = NULL;
     vfb->xauthority = NULL;
-    vfb->vnc = 1;
-    vfb->vncpasswd = NULL;
-    vfb->vnclisten = strdup("127.0.0.1");
-    vfb->vncdisplay = 0;
-    vfb->vncunused = 1;
+    vfb->vnc.enable = 1;
+    vfb->vnc.passwd = NULL;
+    vfb->vnc.listen = strdup("127.0.0.1");
+    vfb->vnc.display = 0;
+    vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
     vfb->sdl = 0;
     vfb->opengl = 0;
@@ -2004,11 +2004,14 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     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, "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, "vnc",
+                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+    flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
+    flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
+    flexarray_append_pair(back, "vncdisplay",
+                          libxl__sprintf(gc, "%d", vfb->vnc.display));
+    flexarray_append_pair(back, "vncunused",
+                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
     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) {
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/libxl_create.c	Tue Jan 10 16:19:52 2012 +0000
@@ -132,10 +132,10 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->vcpu_avail = b_info->cur_vcpus;
 
     dm_info->stdvga = 0;
-    dm_info->vnc = 1;
-    dm_info->vnclisten = strdup("127.0.0.1");
-    dm_info->vncdisplay = 0;
-    dm_info->vncunused = 1;
+    dm_info->vnc.enable = 1;
+    dm_info->vnc.listen = strdup("127.0.0.1");
+    dm_info->vnc.display = 0;
+    dm_info->vnc.findunused = 1;
     dm_info->keymap = NULL;
     dm_info->sdl = 0;
     dm_info->opengl = 0;
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Jan 10 16:19:52 2012 +0000
@@ -100,31 +100,31 @@ static char ** libxl__build_device_model
     if (info->dom_name)
         flexarray_vappend(dm_args, "-domain-name", info->dom_name, NULL);
 
-    if (info->vnc) {
+    if (info->vnc.enable) {
         char *vncarg;
-        if (info->vncdisplay) {
-            if (info->vnclisten && strchr(info->vnclisten, ':') == NULL) {
+        if (info->vnc.display) {
+            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
                 vncarg = libxl__sprintf(gc, "%s:%d",
-                                  info->vnclisten,
-                                  info->vncdisplay);
+                                  info->vnc.listen,
+                                  info->vnc.display);
             } else {
-                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vncdisplay);
+                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vnc.display);
             }
-        } else if (info->vnclisten) {
-            if (strchr(info->vnclisten, ':') != NULL) {
-                vncarg = info->vnclisten;
+        } else if (info->vnc.listen) {
+            if (strchr(info->vnc.listen, ':') != NULL) {
+                vncarg = info->vnc.listen;
             } else {
-                vncarg = libxl__sprintf(gc, "%s:0", info->vnclisten);
+                vncarg = libxl__sprintf(gc, "%s:0", info->vnc.listen);
             }
         } else {
             vncarg = "127.0.0.1:0";
         }
-        if (info->vncpasswd && (info->vncpasswd[0] != '\0'))
+        if (info->vnc.passwd && (info->vnc.passwd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (info->vncunused) {
+        if (info->vnc.findunused) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
@@ -137,7 +137,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc)) {
+    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -268,32 +268,32 @@ static char ** libxl__build_device_model
     if (info->dom_name) {
         flexarray_vappend(dm_args, "-name", info->dom_name, NULL);
     }
-    if (info->vnc) {
+    if (info->vnc.enable) {
         int display = 0;
         const char *listen = "127.0.0.1";
 
-        if (info->vncpasswd && info->vncpasswd[0]) {
+        if (info->vnc.passwd && info->vnc.passwd[0]) {
             assert(!"missing code for supplying vnc password to qemu");
         }
         flexarray_append(dm_args, "-vnc");
 
-        if (info->vncdisplay) {
-            display = info->vncdisplay;
-            if (info->vnclisten && strchr(info->vnclisten, ':') == NULL) {
-                listen = info->vnclisten;
+        if (info->vnc.display) {
+            display = info->vnc.display;
+            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
+                listen = info->vnc.listen;
             }
-        } else if (info->vnclisten) {
-            listen = info->vnclisten;
+        } else if (info->vnc.listen) {
+            listen = info->vnc.listen;
         }
 
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        info->vncunused ? ",to=99" : ""));
+                        info->vnc.findunused ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vncunused ? ",to=99" : ""));
+                        info->vnc.findunused ? ",to=99" : ""));
     }
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -343,7 +343,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc)) {
+    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -532,10 +532,6 @@ static int libxl__vfb_and_vkb_from_devic
     vfb->backend_domid = 0;
     vfb->devid = 0;
     vfb->vnc = info->vnc;
-    vfb->vnclisten = info->vnclisten;
-    vfb->vncdisplay = info->vncdisplay;
-    vfb->vncunused = info->vncunused;
-    vfb->vncpasswd = info->vncpasswd;
     vfb->keymap = info->keymap;
     vfb->sdl = info->sdl;
     vfb->opengl = info->opengl;
@@ -861,7 +857,7 @@ int libxl__create_device_model(libxl__gc
         goto out_close;
     }
 
-    if (info->vncpasswd) {
+    if (info->vnc.passwd) {
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
@@ -870,7 +866,7 @@ retry_transaction:
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
             pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = info->vncpasswd;
+            pass_stuff[1] = info->vnc.passwd;
             libxl__xs_writev(gc,t,vm_path,pass_stuff);
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
@@ -985,13 +981,13 @@ static int libxl__build_xenpv_qemu_args(
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     if (vfb != NULL) {
-        info->vnc = vfb->vnc;
-        if (vfb->vnclisten)
-            info->vnclisten = libxl__strdup(gc, vfb->vnclisten);
-        info->vncdisplay = vfb->vncdisplay;
-        info->vncunused = vfb->vncunused;
-        if (vfb->vncpasswd)
-            info->vncpasswd = vfb->vncpasswd;
+        info->vnc.enable = vfb->vnc.enable;
+        if (vfb->vnc.listen)
+            info->vnc.listen = libxl__strdup(gc, vfb->vnc.listen);
+        info->vnc.display = vfb->vnc.display;
+        info->vnc.findunused = vfb->vnc.findunused;
+        if (vfb->vnc.passwd)
+            info->vnc.passwd = vfb->vnc.passwd;
         if (vfb->keymap)
             info->keymap = libxl__strdup(gc, vfb->keymap);
         info->sdl = vfb->sdl;
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 16:19:52 2012 +0000
@@ -95,6 +95,16 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 #
 # Complex libxl types
 #
+libxl_vnc_info = Struct("vnc_info", [
+    ("enable",        bool),
+    # "address:port" that should be listened on
+    ("listen",        string),
+    ("passwd",        string),
+    ("display",       integer),
+    # If set then try to find an unused port
+    ("findunused",    bool),
+    ])
+
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
@@ -222,14 +232,7 @@ libxl_device_model_info = Struct("device
     # size of the videoram in MB
     ("videoram",         integer), 
     ("stdvga",           bool),
-    ("vnc",              bool),
-    # "address:port" that should be listened on for the VNC server
-    ("vnclisten",        string),
-    ("vncpasswd",        string),
-    # VNC display number
-    ("vncdisplay",       integer),
-    # If set then try to find an unused port for the VNC server
-    ("vncunused",        bool),
+    ("vnc",              libxl_vnc_info),
     # keyboard layout, default is en-us keyboard
     ("keymap",           string),
     ("sdl",              bool),
@@ -268,12 +271,7 @@ libxl_device_model_info = Struct("device
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
-    ("vnc",           bool),
-    # address:port that should be listened on for the VNC server if vnc is set
-    ("vnclisten",     string),
-    ("vncpasswd",     string),
-    ("vncdisplay",    integer),
-    ("vncunused",     bool),
+    ("vnc",           libxl_vnc_info),
     # set keyboard layout, default is en-us keyboard
     ("keymap",        string),
     ("sdl",           bool),
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 16:19:52 2012 +0000
@@ -364,10 +364,10 @@ static void printf_info(int domid,
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
         printf("\t\t\t(stdvga %d)\n", dm_info->stdvga);
-        printf("\t\t\t(vnc %d)\n", dm_info->vnc);
-        printf("\t\t\t(vnclisten %s)\n", dm_info->vnclisten);
-        printf("\t\t\t(vncdisplay %d)\n", dm_info->vncdisplay);
-        printf("\t\t\t(vncunused %d)\n", dm_info->vncunused);
+        printf("\t\t\t(vnc %d)\n", dm_info->vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", dm_info->vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
+        printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
         printf("\t\t\t(keymap %s)\n", dm_info->keymap);
         printf("\t\t\t(sdl %d)\n", dm_info->sdl);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
@@ -454,10 +454,10 @@ static void printf_info(int domid,
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc);
-        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnclisten);
-        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vncdisplay);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vncunused);
+        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
+        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
         printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl);
         printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].opengl);
@@ -961,17 +961,17 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc = atoi(p2 + 1);
+                    vfb->vnc.enable = atoi(p2 + 1);
                 } else if (!strcmp(p, "vnclisten")) {
-                    free(vfb->vnclisten);
-                    vfb->vnclisten = strdup(p2 + 1);
+                    free(vfb->vnc.listen);
+                    vfb->vnc.listen = strdup(p2 + 1);
                 } else if (!strcmp(p, "vncpasswd")) {
-                    free(vfb->vncpasswd);
-                    vfb->vncpasswd = strdup(p2 + 1);
+                    free(vfb->vnc.passwd);
+                    vfb->vnc.passwd = strdup(p2 + 1);
                 } else if (!strcmp(p, "vncdisplay")) {
-                    vfb->vncdisplay = atoi(p2 + 1);
+                    vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vncunused = atoi(p2 + 1);
+                    vfb->vnc.findunused = atoi(p2 + 1);
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
@@ -1178,13 +1178,13 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
         if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+            dm_info->vnc.enable = l;
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
-            dm_info->vncdisplay = l;
+            dm_info->vnc.display = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            dm_info->vncunused = l;
+            dm_info->vnc.findunused = l;
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
diff -r d5c8efa9ef9e -r ed7106b3f874 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Tue Jan 10 16:19:09 2012 +0000
+++ b/tools/python/genwrap.py	Tue Jan 10 16:19:52 2012 +0000
@@ -4,7 +4,7 @@ import sys,os
 
 import libxltypes
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING) = range(4)
+(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
 
 def py_type(ty):
     if ty == libxltypes.bool:
@@ -16,6 +16,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, libxltypes.Aggregate):
+        return TYPE_AGGREGATE
     if ty == libxltypes.string:
         return TYPE_STRING
     return None
@@ -66,6 +68,9 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
+    elif t == TYPE_AGGREGATE:
+        l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
+        l.append('    return NULL;')
     else:
         tn = f.type.typename
         l.append('    return attrib__%s_get((%s *)&self->obj.%s);'%(fsanitize(tn), tn, f.name))
@@ -92,6 +97,9 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
+    elif t == TYPE_AGGREGATE:
+        l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
+        l.append('    return -1;')
     else:
         tn = f.type.typename
         l.append('    return attrib__%s_set(v, (%s *)&self->obj.%s);'%(fsanitize(tn), tn, f.name))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTA-00019Q-MD; Mon, 16 Jan 2012 12:15:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT9-0000zx-5D
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!8
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5661 invoked from network); 16 Jan 2012 12:15:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907092"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:16 -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
	q0GCF0d5032155;	Mon, 16 Jan 2012 04:15:15 -0800
MIME-Version: 1.0
X-Mercurial-Node: 28f0d13e7deafd13ae37322bb56c17541ff43a5e
Message-ID: <28f0d13e7deafd13ae37.1326716113@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:13 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 32 RFC] libxl: move gfx_passthru setting
	to b_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326367542 0
# Node ID 28f0d13e7deafd13ae37322bb56c17541ff43a5e
# Parent  540c9fa96606437f319762663b0892af9e79a6f3
libxl: move gfx_passthru setting to b_info->u.hvm

Although xl parsed this value for both PV and HVM domains (and then a second
time for HVM domains) inside libxl it only impacts HVM guests so I think this
is the right place for it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 540c9fa96606 -r 28f0d13e7dea tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 11:23:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 11:25:42 2012 +0000
@@ -248,7 +248,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (info->gfx_passthru) {
+        if (b_info->u.hvm.gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -488,7 +488,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (info->gfx_passthru) {
+        if (b_info->u.hvm.gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 540c9fa96606 -r 28f0d13e7dea tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 11:23:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 11:25:42 2012 +0000
@@ -227,6 +227,8 @@ libxl_domain_build_info = Struct("domain
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
+                                       ("gfx_passthru",     bool),
+                                       
                                        ("serial",           string),
                                        ("boot",             string),
                                        ("usb",              bool),
@@ -264,7 +266,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    ("gfx_passthru",     bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 540c9fa96606 -r 28f0d13e7dea tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:23:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:25:42 2012 +0000
@@ -379,7 +379,7 @@ static void printf_info(int domid,
         printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
+        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
@@ -732,9 +732,6 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-        dm_info->gfx_passthru = l;
-
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
@@ -1208,7 +1205,7 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            dm_info->gfx_passthru = l;
+            b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         if (!xlu_cfg_get_long (config, "usb", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTA-00019Q-MD; Mon, 16 Jan 2012 12:15:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT9-0000zx-5D
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!8
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5661 invoked from network); 16 Jan 2012 12:15:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907092"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:16 -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
	q0GCF0d5032155;	Mon, 16 Jan 2012 04:15:15 -0800
MIME-Version: 1.0
X-Mercurial-Node: 28f0d13e7deafd13ae37322bb56c17541ff43a5e
Message-ID: <28f0d13e7deafd13ae37.1326716113@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:13 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 32 RFC] libxl: move gfx_passthru setting
	to b_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326367542 0
# Node ID 28f0d13e7deafd13ae37322bb56c17541ff43a5e
# Parent  540c9fa96606437f319762663b0892af9e79a6f3
libxl: move gfx_passthru setting to b_info->u.hvm

Although xl parsed this value for both PV and HVM domains (and then a second
time for HVM domains) inside libxl it only impacts HVM guests so I think this
is the right place for it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 540c9fa96606 -r 28f0d13e7dea tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 11:23:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 11:25:42 2012 +0000
@@ -248,7 +248,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (info->gfx_passthru) {
+        if (b_info->u.hvm.gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -488,7 +488,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (info->gfx_passthru) {
+        if (b_info->u.hvm.gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 540c9fa96606 -r 28f0d13e7dea tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 11:23:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 11:25:42 2012 +0000
@@ -227,6 +227,8 @@ libxl_domain_build_info = Struct("domain
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
+                                       ("gfx_passthru",     bool),
+                                       
                                        ("serial",           string),
                                        ("boot",             string),
                                        ("usb",              bool),
@@ -264,7 +266,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    ("gfx_passthru",     bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 540c9fa96606 -r 28f0d13e7dea tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:23:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:25:42 2012 +0000
@@ -379,7 +379,7 @@ static void printf_info(int domid,
         printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
+        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
@@ -732,9 +732,6 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-        dm_info->gfx_passthru = l;
-
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
@@ -1208,7 +1205,7 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            dm_info->gfx_passthru = l;
+            b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         if (!xlu_cfg_get_long (config, "usb", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlSl-0000uG-5f; Mon, 16 Jan 2012 12:14: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 1RmlSj-0000tF-0X
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:14:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326716090!7464823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3695 invoked from network); 16 Jan 2012 12:14:50 -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;
	16 Jan 2012 12:14:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10046363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12:14: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; Mon, 16 Jan 2012 12:14: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
	1RmlSb-0003Ik-85; Mon, 16 Jan 2012 12:14:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmlSb-0004zA-47;
	Mon, 16 Jan 2012 12:14:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.5305.98918.136965@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 12:14:49 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK6NovBFv7JSD0K7K3erM9bqjzkGtomQQFdKs6QT-Y8hjw@mail.gmail.com>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
	<1326460025.17210.343.camel@zakaz.uk.xensource.com>
	<CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@mail.gmail.com>
	<1326460844.17210.349.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NovBFv7JSD0K7K3erM9bqjzkGtomQQFdKs6QT-Y8hjw@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] libxl: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] libxl: don't set backend=
 state to 5 when trying to unplug a device"):
> 2012/1/13 Ian Campbell <Ian.Campbell@citrix.com>:
> > I think really any changes in these areas should be backed up with
> > empirical experiments on a variety of system types (both front and
> > back), otherwise we are basing things on supposition and heresay about
> > how things are supposed to/do work. No one really knows for sure
> > (witness the number of times we've all gone round on this).

I agree that we don't seem to know what's going on.  One way to try to
understand more would be to look at the xend code, since that's what
everyone currently has to work with.

> Ok, I'm doing a new patch that enclosures everything inside a
> transaction, and I will test it both on NetBSD and Linux. However, I
> have a doubt, can we assume that a transaction that only performs a
> read will always succeed (xs_transaction_end will never return < 0)?

I think the answer is "yes" (or alternatively "you can ignore the
error if there is one") but I can't see any good reason for wanting to
know the answer to that question.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT7-00013R-2v; Mon, 16 Jan 2012 12:15:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT5-0000xQ-5c
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25370 invoked from network); 16 Jan 2012 12:15:11 -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;
	16 Jan 2012 12:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671886"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cw032155;	Mon, 16 Jan 2012 04:15:09 -0800
MIME-Version: 1.0
X-Mercurial-Node: 14605ae17bd9d8a3e2a5111ae6f06ffda0ddc441
Message-ID: <14605ae17bd9d8a3e2a5.1326716106@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 32 RFC] libxl: plumb libxl_domain_config
 down into device model 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 Ian Campbell <ian.campbell@citrix.com>
# Date 1326296799 0
# Node ID 14605ae17bd9d8a3e2a5111ae6f06ffda0ddc441
# Parent  2cf31bf780380c42d859bb0b8f7c701cbf424180
libxl: plumb libxl_domain_config down into device model creation.

Creating the device model derives lots of bits from the guest configuration.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 15:46:39 2012 +0000
@@ -558,7 +558,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, d_config, dm_info,
                                         d_config->disks, d_config->num_disks,
                                         d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
@@ -605,7 +605,8 @@ static int do_domain_create(libxl__gc *g
             xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
             xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
-            libxl__create_xenpv_qemu(gc, domid, &xenpv_dm_info,
+            libxl__create_xenpv_qemu(gc, domid,
+                                     d_config, &xenpv_dm_info,
                                      d_config->vfbs, &dm_starting);
         }
         break;
diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 15:46:39 2012 +0000
@@ -82,10 +82,11 @@ 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_device_disk *disks, int num_disks,
-                                                  libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     int i;
     flexarray_t *dm_args;
@@ -236,10 +237,11 @@ 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_device_disk *disks, int num_disks,
-                                                  libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     flexarray_t *dm_args;
@@ -500,20 +502,21 @@ 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_device_disk *disks, int num_disks,
-                                              libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     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, guest_config, 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, guest_config, info,
                                                   disks, num_disks,
                                                   vifs, num_vifs);
     default:
@@ -524,9 +527,9 @@ static char ** libxl__build_device_model
 }
 
 static int libxl__vfb_and_vkb_from_device_model_info(libxl__gc *gc,
-                                                     libxl_device_model_info *info,
-                                                     libxl_device_vfb *vfb,
-                                                     libxl_device_vkb *vkb)
+                                        const libxl_device_model_info *info,
+                                        libxl_device_vfb *vfb,
+                                        libxl_device_vkb *vkb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
@@ -591,6 +594,7 @@ retry_transaction:
 }
 
 static int libxl__create_stubdom(libxl__gc *gc,
+                                 libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
                                  libxl_device_disk *disks, int num_disks,
                                  libxl_device_nic *vifs, int num_vifs,
@@ -601,8 +605,7 @@ static int libxl__create_stubdom(libxl__
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl_device_console *console;
-    libxl_domain_create_info c_info;
-    libxl_domain_build_info b_info;
+    libxl_domain_config dm_config;
     libxl__domain_build_state state;
     uint32_t domid;
     char **args;
@@ -616,7 +619,35 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm", info,
+    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
+
+    libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
+
+    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    dm_config.b_info.max_vcpus = 1;
+    dm_config.b_info.max_memkb = 32 * 1024;
+    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+
+    dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+                                              libxl_xenfirmwaredir_path());
+    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
+    dm_config.b_info.u.pv.ramdisk.path = "";
+    dm_config.b_info.u.pv.features = "";
+
+    /* fixme: this function can leak the stubdom if it fails */
+    domid = 0;
+    ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
+    if (ret)
+        goto out;
+    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &state);
+    if (ret)
+        goto out;
+
+    args = libxl__build_device_model_args(gc, "stubdom-dm",
+                                          guest_config, info,
                                           disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
@@ -624,33 +655,6 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&c_info, 0x00, sizeof(libxl_domain_create_info));
-    c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
-
-    libxl_uuid_copy(&c_info.uuid, &info->uuid);
-
-    memset(&b_info, 0x00, sizeof(libxl_domain_build_info));
-    b_info.max_vcpus = 1;
-    b_info.max_memkb = 32 * 1024;
-    b_info.target_memkb = b_info.max_memkb;
-
-    b_info.type = LIBXL_DOMAIN_TYPE_PV;
-    b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
-                                              libxl_xenfirmwaredir_path());
-    b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
-    b_info.u.pv.ramdisk.path = "";
-    b_info.u.pv.features = "";
-
-    /* fixme: this function can leak the stubdom if it fails */
-    domid = 0;
-    ret = libxl__domain_make(gc, &c_info, &domid);
-    if (ret)
-        goto out_free;
-    ret = libxl__domain_build(gc, &b_info, info, domid, &state);
-    if (ret)
-        goto out_free;
-
     libxl__write_dmargs(gc, domid, info->domid, args);
     libxl__xs_write(gc, XBT_NULL,
                    libxl__sprintf(gc, "%s/image/device-model-domid", libxl__xs_get_dompath(gc, info->domid)),
@@ -749,6 +753,7 @@ retry_transaction:
     xenpv_dm_info.extra_hvm = info->extra_hvm;
 
     if (libxl__create_xenpv_qemu(gc, domid,
+                                 &dm_config,
                                  &xenpv_dm_info,
                                  vfb, &dm_starting) < 0) {
         ret = ERROR_FAIL;
@@ -778,6 +783,7 @@ out:
 }
 
 int libxl__create_device_model(libxl__gc *gc,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
                               libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
@@ -799,7 +805,7 @@ int libxl__create_device_model(libxl__gc
         libxl_device_vkb vkb;
 
         libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-        rc = libxl__create_stubdom(gc, info,
+        rc = libxl__create_stubdom(gc, guest_config, info,
                                    disks, num_disks,
                                    vifs, num_vifs,
                                    &vfb, &vkb, starting_r);
@@ -817,7 +823,8 @@ 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, guest_config, info,
+                                          disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
         rc = ERROR_FAIL;
@@ -1037,12 +1044,13 @@ out:
 }
 
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
+                             libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
                              libxl_device_vfb *vfb,
                              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, guest_config, info, NULL, 0, NULL, 0, starting_r);
     return 0;
 }
 
diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Jan 11 15:46:39 2012 +0000
@@ -465,11 +465,13 @@ _hidden int libxl__domain_build(libxl__g
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                                libxl_device_model_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disk, int num_disks,
+                              libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
                               libxl_device_vfb *vfb,
                               libxl__spawner_starting **starting_r);
diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_uuid.c
--- a/tools/libxl/libxl_uuid.c	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_uuid.c	Wed Jan 11 15:46:39 2012 +0000
@@ -35,7 +35,7 @@ int libxl_uuid_from_string(libxl_uuid *u
      return uuid_parse(in, uuid->uuid);
 }
 
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src)
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
 {
      uuid_copy(dst->uuid, src->uuid);
 }
@@ -82,7 +82,7 @@ int libxl_uuid_from_string(libxl_uuid *u
 }
 #undef LIBXL__UUID_PTRS
 
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src)
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
 {
      memcpy(dst->uuid, src->uuid, sizeof(dst->uuid));
 }
diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_uuid.h
--- a/tools/libxl/libxl_uuid.h	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_uuid.h	Wed Jan 11 15:46:39 2012 +0000
@@ -56,7 +56,7 @@ typedef struct {
 int libxl_uuid_is_nil(libxl_uuid *uuid);
 void libxl_uuid_generate(libxl_uuid *uuid);
 int libxl_uuid_from_string(libxl_uuid *uuid, const char *in);
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src);
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src);
 void libxl_uuid_clear(libxl_uuid *uuid);
 int libxl_uuid_compare(libxl_uuid *uuid1, libxl_uuid *uuid2);
 uint8_t *libxl_uuid_bytearray(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 Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlSl-0000uG-5f; Mon, 16 Jan 2012 12:14: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 1RmlSj-0000tF-0X
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:14:57 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326716090!7464823!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3695 invoked from network); 16 Jan 2012 12:14:50 -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;
	16 Jan 2012 12:14:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10046363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12:14: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; Mon, 16 Jan 2012 12:14: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
	1RmlSb-0003Ik-85; Mon, 16 Jan 2012 12:14:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmlSb-0004zA-47;
	Mon, 16 Jan 2012 12:14:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.5305.98918.136965@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 12:14:49 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <CAPLaKK6NovBFv7JSD0K7K3erM9bqjzkGtomQQFdKs6QT-Y8hjw@mail.gmail.com>
References: <887a3229fd7a50c04981.1326455824@loki.upc.es>
	<1326460025.17210.343.camel@zakaz.uk.xensource.com>
	<CAPLaKK5mDv6Efk7svxww7mr9zJPhJ=h2dC-_yM+H-W4qkwUjjQ@mail.gmail.com>
	<1326460844.17210.349.camel@zakaz.uk.xensource.com>
	<CAPLaKK6NovBFv7JSD0K7K3erM9bqjzkGtomQQFdKs6QT-Y8hjw@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] libxl: don't set backend state to 5 when
 trying to unplug a device
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH] libxl: don't set backend=
 state to 5 when trying to unplug a device"):
> 2012/1/13 Ian Campbell <Ian.Campbell@citrix.com>:
> > I think really any changes in these areas should be backed up with
> > empirical experiments on a variety of system types (both front and
> > back), otherwise we are basing things on supposition and heresay about
> > how things are supposed to/do work. No one really knows for sure
> > (witness the number of times we've all gone round on this).

I agree that we don't seem to know what's going on.  One way to try to
understand more would be to look at the xend code, since that's what
everyone currently has to work with.

> Ok, I'm doing a new patch that enclosures everything inside a
> transaction, and I will test it both on NetBSD and Linux. However, I
> have a doubt, can we assume that a transaction that only performs a
> read will always succeed (xs_transaction_end will never return < 0)?

I think the answer is "yes" (or alternatively "you can ignore the
error if there is one") but I can't see any good reason for wanting to
know the answer to that question.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT7-00013R-2v; Mon, 16 Jan 2012 12:15:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT5-0000xQ-5c
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25370 invoked from network); 16 Jan 2012 12:15:11 -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;
	16 Jan 2012 12:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671886"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:10 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cw032155;	Mon, 16 Jan 2012 04:15:09 -0800
MIME-Version: 1.0
X-Mercurial-Node: 14605ae17bd9d8a3e2a5111ae6f06ffda0ddc441
Message-ID: <14605ae17bd9d8a3e2a5.1326716106@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:06 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 32 RFC] libxl: plumb libxl_domain_config
 down into device model 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 Ian Campbell <ian.campbell@citrix.com>
# Date 1326296799 0
# Node ID 14605ae17bd9d8a3e2a5111ae6f06ffda0ddc441
# Parent  2cf31bf780380c42d859bb0b8f7c701cbf424180
libxl: plumb libxl_domain_config down into device model creation.

Creating the device model derives lots of bits from the guest configuration.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 15:46:39 2012 +0000
@@ -558,7 +558,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, d_config, dm_info,
                                         d_config->disks, d_config->num_disks,
                                         d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
@@ -605,7 +605,8 @@ static int do_domain_create(libxl__gc *g
             xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
             xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
-            libxl__create_xenpv_qemu(gc, domid, &xenpv_dm_info,
+            libxl__create_xenpv_qemu(gc, domid,
+                                     d_config, &xenpv_dm_info,
                                      d_config->vfbs, &dm_starting);
         }
         break;
diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 15:46:39 2012 +0000
@@ -82,10 +82,11 @@ 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_device_disk *disks, int num_disks,
-                                                  libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     int i;
     flexarray_t *dm_args;
@@ -236,10 +237,11 @@ 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_device_disk *disks, int num_disks,
-                                                  libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     flexarray_t *dm_args;
@@ -500,20 +502,21 @@ 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_device_disk *disks, int num_disks,
-                                              libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     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, guest_config, 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, guest_config, info,
                                                   disks, num_disks,
                                                   vifs, num_vifs);
     default:
@@ -524,9 +527,9 @@ static char ** libxl__build_device_model
 }
 
 static int libxl__vfb_and_vkb_from_device_model_info(libxl__gc *gc,
-                                                     libxl_device_model_info *info,
-                                                     libxl_device_vfb *vfb,
-                                                     libxl_device_vkb *vkb)
+                                        const libxl_device_model_info *info,
+                                        libxl_device_vfb *vfb,
+                                        libxl_device_vkb *vkb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
@@ -591,6 +594,7 @@ retry_transaction:
 }
 
 static int libxl__create_stubdom(libxl__gc *gc,
+                                 libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
                                  libxl_device_disk *disks, int num_disks,
                                  libxl_device_nic *vifs, int num_vifs,
@@ -601,8 +605,7 @@ static int libxl__create_stubdom(libxl__
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl_device_console *console;
-    libxl_domain_create_info c_info;
-    libxl_domain_build_info b_info;
+    libxl_domain_config dm_config;
     libxl__domain_build_state state;
     uint32_t domid;
     char **args;
@@ -616,7 +619,35 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm", info,
+    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
+
+    libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
+
+    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    dm_config.b_info.max_vcpus = 1;
+    dm_config.b_info.max_memkb = 32 * 1024;
+    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+
+    dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+                                              libxl_xenfirmwaredir_path());
+    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
+    dm_config.b_info.u.pv.ramdisk.path = "";
+    dm_config.b_info.u.pv.features = "";
+
+    /* fixme: this function can leak the stubdom if it fails */
+    domid = 0;
+    ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
+    if (ret)
+        goto out;
+    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &state);
+    if (ret)
+        goto out;
+
+    args = libxl__build_device_model_args(gc, "stubdom-dm",
+                                          guest_config, info,
                                           disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
@@ -624,33 +655,6 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&c_info, 0x00, sizeof(libxl_domain_create_info));
-    c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
-
-    libxl_uuid_copy(&c_info.uuid, &info->uuid);
-
-    memset(&b_info, 0x00, sizeof(libxl_domain_build_info));
-    b_info.max_vcpus = 1;
-    b_info.max_memkb = 32 * 1024;
-    b_info.target_memkb = b_info.max_memkb;
-
-    b_info.type = LIBXL_DOMAIN_TYPE_PV;
-    b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
-                                              libxl_xenfirmwaredir_path());
-    b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
-    b_info.u.pv.ramdisk.path = "";
-    b_info.u.pv.features = "";
-
-    /* fixme: this function can leak the stubdom if it fails */
-    domid = 0;
-    ret = libxl__domain_make(gc, &c_info, &domid);
-    if (ret)
-        goto out_free;
-    ret = libxl__domain_build(gc, &b_info, info, domid, &state);
-    if (ret)
-        goto out_free;
-
     libxl__write_dmargs(gc, domid, info->domid, args);
     libxl__xs_write(gc, XBT_NULL,
                    libxl__sprintf(gc, "%s/image/device-model-domid", libxl__xs_get_dompath(gc, info->domid)),
@@ -749,6 +753,7 @@ retry_transaction:
     xenpv_dm_info.extra_hvm = info->extra_hvm;
 
     if (libxl__create_xenpv_qemu(gc, domid,
+                                 &dm_config,
                                  &xenpv_dm_info,
                                  vfb, &dm_starting) < 0) {
         ret = ERROR_FAIL;
@@ -778,6 +783,7 @@ out:
 }
 
 int libxl__create_device_model(libxl__gc *gc,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
                               libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
@@ -799,7 +805,7 @@ int libxl__create_device_model(libxl__gc
         libxl_device_vkb vkb;
 
         libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-        rc = libxl__create_stubdom(gc, info,
+        rc = libxl__create_stubdom(gc, guest_config, info,
                                    disks, num_disks,
                                    vifs, num_vifs,
                                    &vfb, &vkb, starting_r);
@@ -817,7 +823,8 @@ 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, guest_config, info,
+                                          disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
         rc = ERROR_FAIL;
@@ -1037,12 +1044,13 @@ out:
 }
 
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
+                             libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
                              libxl_device_vfb *vfb,
                              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, guest_config, info, NULL, 0, NULL, 0, starting_r);
     return 0;
 }
 
diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Jan 11 15:46:39 2012 +0000
@@ -465,11 +465,13 @@ _hidden int libxl__domain_build(libxl__g
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                                libxl_device_model_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disk, int num_disks,
+                              libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
                               libxl_device_vfb *vfb,
                               libxl__spawner_starting **starting_r);
diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_uuid.c
--- a/tools/libxl/libxl_uuid.c	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_uuid.c	Wed Jan 11 15:46:39 2012 +0000
@@ -35,7 +35,7 @@ int libxl_uuid_from_string(libxl_uuid *u
      return uuid_parse(in, uuid->uuid);
 }
 
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src)
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
 {
      uuid_copy(dst->uuid, src->uuid);
 }
@@ -82,7 +82,7 @@ int libxl_uuid_from_string(libxl_uuid *u
 }
 #undef LIBXL__UUID_PTRS
 
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src)
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
 {
      memcpy(dst->uuid, src->uuid, sizeof(dst->uuid));
 }
diff -r 2cf31bf78038 -r 14605ae17bd9 tools/libxl/libxl_uuid.h
--- a/tools/libxl/libxl_uuid.h	Wed Jan 11 15:42:33 2012 +0000
+++ b/tools/libxl/libxl_uuid.h	Wed Jan 11 15:46:39 2012 +0000
@@ -56,7 +56,7 @@ typedef struct {
 int libxl_uuid_is_nil(libxl_uuid *uuid);
 void libxl_uuid_generate(libxl_uuid *uuid);
 int libxl_uuid_from_string(libxl_uuid *uuid, const char *in);
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src);
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src);
 void libxl_uuid_clear(libxl_uuid *uuid);
 int libxl_uuid_compare(libxl_uuid *uuid1, libxl_uuid *uuid2);
 uint8_t *libxl_uuid_bytearray(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 Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT1-0000yH-0K; Mon, 16 Jan 2012 12:15:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSz-0000vr-GQ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25001 invoked from network); 16 Jan 2012 12:15:05 -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;
	16 Jan 2012 12:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671864"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cq032155;	Mon, 16 Jan 2012 04:15:03 -0800
MIME-Version: 1.0
X-Mercurial-Node: cf86bcb7c89568a2c60f246d0e2443acb756e1c1
Message-ID: <cf86bcb7c89568a2c60f.1326716100@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 32 RFC] libxl: use keyword arguments for
 field definitions in aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326190542 0
# Node ID cf86bcb7c89568a2c60f246d0e2443acb756e1c1
# Parent  485945937a27ea1d9736b8f9bf8d21183b928780
libxl: use keyword arguments for field definitions in aggregate types.

The original code is not so bad now that the comments are gone but this is
still a bit cleaner.

No change in the generated code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 485945937a27 -r cf86bcb7c895 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 10:15:42 2012 +0000
@@ -196,7 +196,7 @@ libxl_domain_build_info = Struct("domain
                                       ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
-                                      ("features", string, True),
+                                      ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", bool),
                                       ])),
diff -r 485945937a27 -r cf86bcb7c895 tools/libxl/libxltypes.py
--- a/tools/libxl/libxltypes.py	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/libxltypes.py	Tue Jan 10 10:15:42 2012 +0000
@@ -154,17 +154,17 @@ class Aggregate(Type):
 
         self.fields = []
         for f in fields:
-            # (name, type[, const=False])
+            # (name, type[, {kw args}])
             if len(f) == 2:
                 n,t = f
-                const = False
+                kw = {}
             elif len(f) == 3:
-                n,t,const = f
+                n,t,kw = f
             else:
                 raise ValueError
             if n is None:
                 raise ValueError
-            self.fields.append(Field(t,n,const=const))
+            self.fields.append(Field(t,n,**kw))
 
     # Returns a tuple (stem, field-expr)
     #

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT7-000146-GI; Mon, 16 Jan 2012 12:15:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT5-0000xw-TX
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5433 invoked from network); 16 Jan 2012 12:15:13 -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;
	16 Jan 2012 12:15:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907090"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0d1032155;	Mon, 16 Jan 2012 04:15:11 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3db40f3e8b2af814b9f79b514de82c3751c213f8
Message-ID: <3db40f3e8b2af814b9f7.1326716109@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 32 RFC] libxl: drop dm_info.dom_name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326304712 0
# Node ID 3db40f3e8b2af814b9f79b514de82c3751c213f8
# Parent  a27ac2ae9cefc42e3eee504cb2805824fd80d3f8
libxl: drop dm_info.dom_name

This is always the same as the c_info name which we now have available.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a27ac2ae9cef -r 3db40f3e8b2a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 17:50:21 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:58:32 2012 +0000
@@ -121,7 +121,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 
     libxl_uuid_generate(&dm_info->uuid);
 
-    dm_info->dom_name = strdup(c_info->name);
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
diff -r a27ac2ae9cef -r 3db40f3e8b2a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 17:50:21 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 17:58:32 2012 +0000
@@ -86,6 +86,7 @@ static char ** libxl__build_device_model
                                         const libxl_domain_config *guest_config,
                                         const libxl_device_model_info *info)
 {
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_vifs = guest_config->num_vifs;
@@ -99,8 +100,8 @@ static char ** libxl__build_device_model
     flexarray_vappend(dm_args, dm,
                       "-d", libxl__sprintf(gc, "%d", info->domid), NULL);
 
-    if (info->dom_name)
-        flexarray_vappend(dm_args, "-domain-name", info->dom_name, NULL);
+    if (c_info->name)
+        flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
 
     if (info->vnc.enable) {
         char *vncarg;
@@ -247,6 +248,7 @@ static char ** libxl__build_device_model
                                         const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_disk *disks = guest_config->disks;
     const libxl_device_nic *vifs = guest_config->vifs;
@@ -276,8 +278,8 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-xen-attach");
     }
 
-    if (info->dom_name) {
-        flexarray_vappend(dm_args, "-name", info->dom_name, NULL);
+    if (c_info->name) {
+        flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
     if (info->vnc.enable) {
         int display = 0;
@@ -803,6 +805,7 @@ int libxl__create_device_model(libxl__gc
                               libxl_device_model_info *info,
                               libxl__spawner_starting **starting_r)
 {
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path, *logfile;
     int logfile_w, null;
@@ -845,7 +848,9 @@ int libxl__create_device_model(libxl__gc
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
 
-    libxl_create_logfile(ctx, libxl__sprintf(gc, "qemu-dm-%s", info->dom_name), &logfile);
+    libxl_create_logfile(ctx,
+                         libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
+                         &logfile);
     logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
     free(logfile);
     null = open("/dev/null", O_RDONLY);
@@ -991,8 +996,6 @@ static int libxl__build_xenpv_qemu_args(
                                         libxl_device_vfb *vfb,
                                         libxl_device_model_info *info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-
     if (vfb != NULL) {
         info->vnc.enable = vfb->vnc.enable;
         if (vfb->vnc.listen)
@@ -1007,7 +1010,6 @@ static int libxl__build_xenpv_qemu_args(
     } else
         info->nographic = 1;
     info->domid = domid;
-    info->dom_name = libxl_domid_to_name(ctx, domid);
     return 0;
 }
 
diff -r a27ac2ae9cef -r 3db40f3e8b2a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 11 17:50:21 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 11 17:58:32 2012 +0000
@@ -241,7 +241,6 @@ libxl_device_model_info = Struct("device
     # uuid is used only with stubdom, and must be different from the
     # domain uuid
     ("uuid",             libxl_uuid),
-    ("dom_name",         string),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT4-00010n-LU; Mon, 16 Jan 2012 12:15: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 1RmlT3-0000wn-FV
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25229 invoked from network); 16 Jan 2012 12:15:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671881"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cu032155;	Mon, 16 Jan 2012 04:15:07 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3308d2dfd9dddb36f8a65e7a44916c6bcf02170e
Message-ID: <3308d2dfd9dddb36f8a6.1326716104@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 32 RFC] libxl: define libxl_spice_info to
 hold all info about the spice server
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326215019 0
# Node ID 3308d2dfd9dddb36f8a65e7a44916c6bcf02170e
# Parent  ed7106b3f874d93e8ed8d05a8464099e611edd0b
libxl: define libxl_spice_info to hold all info about the spice server

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ed7106b3f874 -r 3308d2dfd9dd tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Jan 10 16:19:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Jan 10 17:03:39 2012 +0000
@@ -298,39 +298,39 @@ static char ** libxl__build_device_model
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
     }
-    if (info->spice) {
+    if (info->spice.enable) {
         char *spiceoptions = NULL;
-        if (!info->spiceport && !info->spicetls_port) {
+        if (!info->spice.port && !info->spice.tls_port) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "at least one of the spiceport or tls_port must be provided");
             return NULL;
         }
 
-        if (!info->spicedisable_ticketing) {
-            if (!info->spicepasswd) {
+        if (!info->spice.disable_ticketing) {
+            if (!info->spice.passwd) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                     "spice ticketing is enabled but missing password");
                 return NULL;
             }
-            else if (!info->spicepasswd[0]) {
+            else if (!info->spice.passwd[0]) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                     "spice password can't be empty");
                 return NULL;
             }
         }
         spiceoptions = libxl__sprintf(gc, "port=%d,tls-port=%d",
-                       info->spiceport, info->spicetls_port);
-        if (info->spicehost)
+                                      info->spice.port, info->spice.tls_port);
+        if (info->spice.host)
             spiceoptions = libxl__sprintf(gc,
-                    "%s,addr=%s", spiceoptions, info->spicehost);
-        if (info->spicedisable_ticketing)
+                    "%s,addr=%s", spiceoptions, info->spice.host);
+        if (info->spice.disable_ticketing)
             spiceoptions = libxl__sprintf(gc, "%s,disable-ticketing",
                                                spiceoptions);
         else
             spiceoptions = libxl__sprintf(gc,
-                    "%s,password=%s", spiceoptions, info->spicepasswd);
+                    "%s,password=%s", spiceoptions, info->spice.passwd);
         spiceoptions = libxl__sprintf(gc, "%s,agent-mouse=%s", spiceoptions,
-                                      info->spiceagent_mouse ? "on" : "off");
+                                      info->spice.agent_mouse ? "on" : "off");
 
         flexarray_append(dm_args, "-spice");
         flexarray_append(dm_args, spiceoptions);
diff -r ed7106b3f874 -r 3308d2dfd9dd tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 16:19:52 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 17:03:39 2012 +0000
@@ -105,6 +105,26 @@ libxl_vnc_info = Struct("vnc_info", [
     ("findunused",    bool),
     ])
 
+libxl_spice_info = Struct("spice_info", [
+    ("enable",            bool),
+    # At least one of spice port or spicetls_post must be given
+    ("port",        integer),
+    ("tls_port",    integer),
+    # Interface to bind to
+    ("host",        string),
+    # enable client connection with no password
+    ("disable_ticketing", bool),
+    ("passwd",      string),
+    ("agent_mouse", bool),
+    ])
+
+libxl_sdl_info = Struct("sdl_info", [
+    ("enable",        bool),
+    ("opengl",        bool),
+    ("display",       string),
+    ("xauthority",    string),
+    ])
+
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
@@ -237,16 +257,7 @@ libxl_device_model_info = Struct("device
     ("keymap",           string),
     ("sdl",              bool),
     ("opengl",           bool), # (requires sdl enabled)
-    ("spice",            bool),
-    # At least one of spice port or spicetls_post must be given
-    ("spiceport",        integer),
-    ("spicetls_port",    integer),
-    # Interface to bind to
-    ("spicehost",        string),
-    # enable client connection with no password
-    ("spicedisable_ticketing", bool),
-    ("spicepasswd",      string),
-    ("spiceagent_mouse", bool),
+    ("spice",            libxl_spice_info),
     ("nographic",        bool),
     ("gfx_passthru",     bool),
     ("serial",           string),
diff -r ed7106b3f874 -r 3308d2dfd9dd tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 16:19:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:03:39 2012 +0000
@@ -378,13 +378,13 @@ static void printf_info(int domid,
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
         printf("\t\t\t(acpi %d)\n", dm_info->acpi);
-        printf("\t\t\t(spice %d)\n", dm_info->spice);
-        printf("\t\t\t(spiceport %d)\n", dm_info->spiceport);
-        printf("\t\t\t(spicetls_port %d)\n", dm_info->spicetls_port);
-        printf("\t\t\t(spicehost %s)\n", dm_info->spicehost);
+        printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
+        printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", dm_info->spice.host);
         printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    dm_info->spicedisable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spiceagent_mouse);
+                    dm_info->spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spice.agent_mouse);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1191,19 +1191,20 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            dm_info->spice = l;
+            dm_info->spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
-            dm_info->spiceport = l;
+            dm_info->spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
-            dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+            dm_info->spice.tls_port = l;
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spice.host, 0);
         if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+            dm_info->spice.disable_ticketing = l;
+        xlu_cfg_replace_string (config, "spicepasswd",
+                                &dm_info->spice.passwd, 0);
         if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            dm_info->spiceagent_mouse = l;
+            dm_info->spice.agent_mouse = l;
         else
-            dm_info->spiceagent_mouse = 1;
+            dm_info->spice.agent_mouse = 1;
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT0-0000xb-0W; Mon, 16 Jan 2012 12:15:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSx-0000vV-Oi
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4911 invoked from network); 16 Jan 2012 12:15:05 -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;
	16 Jan 2012 12:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907084"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0GCF0cp032155;	Mon, 16 Jan 2012 04:15:02 -0800
MIME-Version: 1.0
X-Mercurial-Node: 485945937a27ea1d9736b8f9bf8d21183b928780
Message-ID: <485945937a27ea1d9736.1326716099@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:14:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 32 RFC] libxl: remove comment support from
	IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326190542 0
# Node ID 485945937a27ea1d9736b8f9bf8d21183b928780
# Parent  f4956ec4b28602f512b69d07f5ea3d001dc688ad
libxl: remove comment support from IDL

People typically don't look for comments in generated source and the syntax for
specifying them in the IDL makes things harder to follow.

Instead just use source code comments in the IDL itself.

I dropped a bunch of "foo bool # enable or disable foo" type comments. A lot of
the remainder still aren't terribly useful though.

No change to the generate code other than the comments being removed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f4956ec4b286 -r 485945937a27 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/gentypes.py	Tue Jan 10 10:15:42 2012 +0000
@@ -5,19 +5,6 @@ import re
 
 import libxltypes
 
-def format_comment(level, comment):
-    indent = reduce(lambda x,y: x + " ", range(level), "")
-    s  = "%s/*\n" % indent
-    s += "%s * " % indent
-    comment = comment.replace("\n", "\n%s * " % indent)
-    x = re.compile(r'^%s \* $' % indent, re.MULTILINE)
-    comment = x.sub("%s *" % indent, comment)
-    s += comment
-    s += "\n"
-    s += "%s */" % indent
-    s += "\n"
-    return s
-
 def libxl_C_instance_of(ty, instancename):
     if isinstance(ty, libxltypes.Aggregate) and ty.typename is None:
         if instancename is None:
@@ -30,17 +17,12 @@ def libxl_C_instance_of(ty, instancename
 def libxl_C_type_define(ty, indent = ""):
     s = ""
     if isinstance(ty, libxltypes.Enumeration):
-        if ty.comment is not None:
-            s += format_comment(0, ty.comment)
-
         if ty.typename is None:
             s += "enum {\n"
         else:
             s += "typedef enum %s {\n" % ty.typename
 
         for v in ty.values:
-            if v.comment is not None:
-                s += format_comment(4, v.comment)
             x = "%s = %d" % (v.name, v.value)
             x = x.replace("\n", "\n    ")
             s += "    " + x + ",\n"
@@ -50,17 +32,12 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, libxltypes.Aggregate):
-        if ty.comment is not None:
-            s += format_comment(0, ty.comment)
-
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
             s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
-            if f.comment is not None:
-                s += format_comment(4, f.comment)
             x = libxl_C_instance_of(f.type, f.name)
             if f.const:
                 x = "const " + x
diff -r f4956ec4b286 -r 485945937a27 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 10:15:42 2012 +0000
@@ -28,8 +28,8 @@ libxl_domain_type = Enumeration("domain_
     ])
 
 libxl_device_model_version = Enumeration("device_model_version", [
-    (1, "QEMU_XEN_TRADITIONAL", "Historical qemu-xen device model (qemu-dm)"),
-    (2, "QEMU_XEN", "Upstream based qemu-xen device model"),
+    (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm)
+    (2, "QEMU_XEN"),             # Upstream based qemu-xen device model
     ])
 
 libxl_console_type = Enumeration("console_type", [
@@ -98,18 +98,18 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
-    ("ssidref",      uint32),
+    ("ssidref",     uint32),
     ("running",     bool),
     ("blocked",     bool),
     ("paused",      bool),
     ("shutdown",    bool),
     ("dying",       bool),
 
-    ("shutdown_reason", uint8, False,
-"""Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
-
-Otherwise set to a value guaranteed not to clash with any valid
-SHUTDOWN_* constant."""),
+    # Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
+    #
+    # Otherwise set to a value guaranteed not to clash with any valid
+    # SHUTDOWN_* constant.
+    ("shutdown_reason", uint8),
     ("current_memkb",   uint64),
     ("shared_memkb", uint64),
     ("max_memkb",   uint64),
@@ -159,6 +159,11 @@ libxl_domain_create_info = Struct("domai
     ("poolname",     string),
     ])
 
+# Instances of libxl_file_reference contained in this struct which
+# have been mapped (with libxl_file_reference_map) will be unmapped
+# by libxl_domain_build/restore. If either of these are never called
+# then the user is responsible for calling
+# libxl_file_reference_unmap.
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
@@ -192,84 +197,87 @@ libxl_domain_build_info = Struct("domain
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
-                                      ("e820_host", bool, False, "Use host's E820 for PCI passthrough."),
+                                      # Use host's E820 for PCI passthrough.
+                                      ("e820_host", bool),
                                       ])),
                  ])),
     ],
-    comment =
-"""Instances of libxl_file_reference contained in this struct which
-have been mapped (with libxl_file_reference_map) will be unmapped
-by libxl_domain_build/restore. If either of these are never called
-then the user is responsible for calling
-libxl_file_reference_unmap.""")
+)
 
+# Device Model Information
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
-    ("uuid",             libxl_uuid,  False, "this is use only with stubdom, and must be different from the domain uuid"),
+    
+    # uuid is used only with stubdom, and must be different from the
+    # domain uuid
+    ("uuid",             libxl_uuid),
     ("dom_name",         string),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
-    ("device_model",     string, False, "if you set this you must set device_model_version too"),
+    # you set device_model you must set device_model_version too
+    ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
     ("target_ram",       uint32),
-    ("videoram",         integer,           False, "size of the videoram in MB"),
-    ("stdvga",           bool,              False, "stdvga enabled or disabled"),
-    ("vnc",              bool,              False, "vnc enabled or disabled"),
-    ("vnclisten",        string,            False, "address:port that should be listened on for the VNC server if vnc is set"),
-    ("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"),
-    ("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)"),
-    ("spice",            bool,              False,
-    "spice enabled or disabled"),
-    ("spiceport",        integer,           False,
-    "the port that should be listened on for the spice server"),
-    ("spicetls_port",    integer,           False, """the tls port
-that should be listened on for the spice server,
-at least one of the port or tls port must be given"""),
-    ("spicehost",        string,            False, """the interface
-that should be listened on if given otherwise any interface"""),
-    ("spicedisable_ticketing", bool,        False,
-    "enable client connection with no password"),
-    ("spicepasswd",      string,            False, """set ticket password
-witch must be used by a client for connection.
-The password never expires"""),
-    ("spiceagent_mouse", bool,              False,
-    "Whether spice agent is used for client mouse mode(default is on)"),
-    ("nographic",        bool,              False, "no graphics, use serial port"),
-    ("gfx_passthru",     bool,              False, "graphics passthrough enabled or disabled"),
-    ("serial",           string,            False, "serial port re-direct to pty deivce"),
-    ("boot",             string,            False, "boot order, for example dca"),
-    ("usb",              bool,              False, "usb support enabled or disabled"),
-    ("usbdevice",        string,            False, "enable usb mouse: tablet for absolute mouse, mouse for PS/2 protocol relative mouse"),
-    ("soundhw",          string,            False, "enable sound hardware"),
-    ("acpi",             bool,              False, "acpi enabled or disabled"),
-    ("vcpus",            integer,           False, "max number of vcpus"),
-    ("vcpu_avail",       integer,           False, "vcpus actually available"),
-    ("xen_platform_pci", bool,              False, "enable/disable the xen platform pci device"),
-    ("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"),
+    # size of the videoram in MB
+    ("videoram",         integer), 
+    ("stdvga",           bool),
+    ("vnc",              bool),
+    # "address:port" that should be listened on for the VNC server
+    ("vnclisten",        string),
+    ("vncpasswd",        string),
+    # VNC display number
+    ("vncdisplay",       integer),
+    # If set then try to find an unused port for the VNC server
+    ("vncunused",        bool),
+    # keyboard layout, default is en-us keyboard
+    ("keymap",           string),
+    ("sdl",              bool),
+    ("opengl",           bool), # (requires sdl enabled)
+    ("spice",            bool),
+    # At least one of spice port or spicetls_post must be given
+    ("spiceport",        integer),
+    ("spicetls_port",    integer),
+    # Interface to bind to
+    ("spicehost",        string),
+    # enable client connection with no password
+    ("spicedisable_ticketing", bool),
+    ("spicepasswd",      string),
+    ("spiceagent_mouse", bool),
+    ("nographic",        bool),
+    ("gfx_passthru",     bool),
+    ("serial",           string),
+    ("boot",             string),
+    ("usb",              bool),
+    # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
+    ("usbdevice",        string),
+    ("soundhw",          string),
+    ("acpi",             bool),
+    ("vcpus",            integer), # max number of vcpus
+    ("vcpu_avail",       integer), # vcpus actually available
+    ("xen_platform_pci", bool),
+    # extra parameters pass directly to qemu, NULL terminated
+    ("extra",            libxl_string_list),
+    # extra parameters pass directly to qemu for PV guest, NULL terminated
+    ("extra_pv",         libxl_string_list),
+    # extra parameters pass directly to qemu for HVM guest, NULL terminated
+    ("extra_hvm",        libxl_string_list),
     ],
-    comment=
-"""Device Model information.
-
-Network is missing""")
+)
 
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
-    ("vnc",           bool,     False, "vnc enabled or disabled"),
-    ("vnclisten",     string,   False, "address:port that should be listened on for the VNC server if vnc is set"),
-    ("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"),
-    ("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)"),
+    ("vnc",           bool),
+    # address:port that should be listened on for the VNC server if vnc is set
+    ("vnclisten",     string),
+    ("vncpasswd",     string),
+    ("vncdisplay",    integer),
+    ("vncunused",     bool),
+    # set keyboard layout, default is en-us keyboard
+    ("keymap",        string),
+    ("sdl",           bool),
+    ("opengl",        bool), # (if enabled requires sdl enabled)
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -346,13 +354,13 @@ libxl_nicinfo = Struct("nicinfo", [
     ])
 
 libxl_vcpuinfo = Struct("vcpuinfo", [
-    ("vcpuid", uint32,              False, "vcpu's id"),
-    ("cpu", uint32,                 False, "current mapping"),
-    ("online", bool,                False, "currently online (not hotplugged)?"),
-    ("blocked", bool,               False, "blocked waiting for an event?"),
-    ("running", bool,               False, "currently scheduled on its CPU?"),
-    ("vcpu_time", uint64,           False, "total vcpu time ran (ns)"),
-    ("cpumap", libxl_cpumap,        False, "current cpu's affinities"),
+    ("vcpuid", uint32),
+    ("cpu", uint32),
+    ("online", bool),
+    ("blocked", bool),
+    ("running", bool),
+    ("vcpu_time", uint64), # total vcpu time ran (ns)
+    ("cpumap", libxl_cpumap), # current cpu's affinities
     ])
 
 libxl_physinfo = Struct("physinfo", [
@@ -373,9 +381,9 @@ libxl_physinfo = Struct("physinfo", [
     ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_topologyinfo = Struct("topologyinfo", [
-    ("coremap", libxl_cpuarray,   False, "cpu to core map"),
-    ("socketmap", libxl_cpuarray, False, "cpu to socket map"),
-    ("nodemap", libxl_cpuarray,   False, "cpu to node map"),
+    ("coremap", libxl_cpuarray),   # cpu to core map
+    ("socketmap", libxl_cpuarray), # cpu to socket map
+    ("nodemap", libxl_cpuarray),   # cpu to node map
     ])
 
 libxl_sched_credit = Struct("sched_credit", [
diff -r f4956ec4b286 -r 485945937a27 tools/libxl/libxltypes.py
--- a/tools/libxl/libxltypes.py	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/libxltypes.py	Tue Jan 10 10:15:42 2012 +0000
@@ -22,7 +22,6 @@ def _get_default_namespace():
 
 class Type(object):
     def __init__(self, typename, **kwargs):
-        self.comment = kwargs.setdefault('comment', None)
         self.namespace = kwargs.setdefault('namespace',
                 _get_default_namespace())
         self.dir = kwargs.setdefault('dir', DIR_BOTH)
@@ -120,7 +119,6 @@ class EnumerationValue(object):
         self.rawname = str.upper(enum.rawname) + "_" + self.valuename
         self.name = str.upper(enum.namespace) + self.rawname
         self.value = value
-        self.comment = kwargs.setdefault("comment", None)
 
 class Enumeration(Type):
     def __init__(self, typename, values, **kwargs):
@@ -129,16 +127,9 @@ class Enumeration(Type):
 
         self.values = []
         for v in values:
-            # (value, name[, comment=None])
-            if len(v) == 2:
-                (num,name) = v
-                comment = None
-            elif len(v) == 3:
-                num,name,comment = v
-            else:
-                raise ""
+            # (value, name)
+            (num,name) = v
             self.values.append(EnumerationValue(self, num, name,
-                                                comment=comment,
                                                 typename=self.rawname))
     def lookup(self, name):
         for v in self.values:
@@ -152,7 +143,6 @@ class Field(object):
         self.type = type
         self.name = name
         self.const = kwargs.setdefault('const', False)
-        self.comment = kwargs.setdefault('comment', None)
         self.enumname = kwargs.setdefault('enumname', None)
 
 class Aggregate(Type):
@@ -164,19 +154,17 @@ class Aggregate(Type):
 
         self.fields = []
         for f in fields:
-            # (name, type[, const=False[, comment=None]])
+            # (name, type[, const=False])
             if len(f) == 2:
                 n,t = f
                 const = False
-                comment = None
             elif len(f) == 3:
                 n,t,const = f
-                comment = None
             else:
-                n,t,const,comment = f
+                raise ValueError
             if n is None:
                 raise ValueError
-            self.fields.append(Field(t,n,const=const,comment=comment))
+            self.fields.append(Field(t,n,const=const))
 
     # Returns a tuple (stem, field-expr)
     #

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT0-0000xs-DN; Mon, 16 Jan 2012 12:15:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSy-0000vY-75
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4990 invoked from network); 16 Jan 2012 12:15:06 -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;
	16 Jan 2012 12:15:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907085"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cr032155;	Mon, 16 Jan 2012 04:15:04 -0800
MIME-Version: 1.0
X-Mercurial-Node: 07c4b8a8d50c8562472c8f6607ec145146c3828c
Message-ID: <07c4b8a8d50c8562472c.1326716101@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 32 RFC] ocaml: use libxl IDL type helpers
 for C argument passing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326212333 0
# Node ID 07c4b8a8d50c8562472c8f6607ec145146c3828c
# Parent  cf86bcb7c89568a2c60f246d0e2443acb756e1c1
ocaml: use libxl IDL type helpers for C argument passing

Makes handling of nested structs more correct.

Only change to the generated code right now is that the FOO_Val
(C->ocamlC) function for Enumeration types now takes the C argument by
value instead of reference.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r cf86bcb7c895 -r 07c4b8a8d50c tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Tue Jan 10 16:18:53 2012 +0000
@@ -110,11 +110,6 @@ def gen_ocaml_ml(ty, interface, indent="
     return s.replace("\n", "\n%s" % indent)
 
 def c_val(ty, c, o, indent="", parent = None):
-    if ty.passby == libxltypes.PASS_BY_REFERENCE:
-        makeref = ""
-    else:
-        makeref = "&"
-
     s = indent
     if isinstance(ty,libxltypes.UInt):
         if ty.width in [8, 16]:
@@ -146,17 +141,18 @@ def c_val(ty, c, o, indent="", parent = 
     elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
-            s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
+            (nparent,fexpr) = ty.member(c, f, parent is None)
+            s += "%s\n" % c_val(f.type, fexpr, "Field(%s, %d)" % (o,n), parent=nparent)
             n = n + 1
     else:
-        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, makeref + c, o)
+        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, ty.pass_arg(c, parent is None, passby=libxltypes.PASS_BY_REFERENCE), o)
     
     return s.replace("\n", "\n%s" % indent)
 
 def gen_c_val(ty, indent=""):
     s = "/* Convert caml value to %s */\n" % ty.rawname
     
-    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s *c_val, value v)\n" % (ty.rawname, ty.typename)
+    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s, value v)\n" % (ty.rawname, ty.make_arg("c_val", passby=libxltypes.PASS_BY_REFERENCE))
     s += "{\n"
     s += "\tCAMLparam1(v);\n"
     s += "\n"
@@ -169,11 +165,6 @@ def gen_c_val(ty, indent=""):
     return s.replace("\n", "\n%s" % indent)
 
 def ocaml_Val(ty, o, c, indent="", parent = None):
-    if ty.passby == libxltypes.PASS_BY_REFERENCE:
-        makeref = ""
-    else:
-        makeref = "&"
-    
     s = indent
     if isinstance(ty,libxltypes.UInt):
         if ty.width in [8, 16]:
@@ -196,7 +187,7 @@ def ocaml_Val(ty, o, c, indent="", paren
         s += "%s = %s;" % (o, fn % { "c": c })
     elif isinstance(ty,libxltypes.Enumeration) and (parent is None):
         n = 0
-        s += "switch(*%s) {\n" % c
+        s += "switch(%s) {\n" % c
         for e in ty.values:
             s += "    case %s: %s = Int_val(%d); break;\n" % (e.name, o, n)
             n += 1
@@ -210,20 +201,22 @@ def ocaml_Val(ty, o, c, indent="", paren
         
         n = 0
         for f in ty.fields:
+            (nparent,fexpr) = ty.member(c, f, parent is None)
+
             s += "\n"
-            s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
+            s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, ty.pass_arg(fexpr, c), parent=nparent)
             s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
             n = n + 1
         s += "}"
     else:
-        s += "%s = Val_%s(gc, lg, %s);" % (o, ty.rawname, makeref + c)
+        s += "%s = Val_%s(gc, lg, %s);" % (o, ty.rawname, ty.pass_arg(c, parent is None))
     
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
 def gen_Val_ocaml(ty, indent=""):
     s = "/* Convert %s to a caml value */\n" % ty.rawname
 
-    s += "static value Val_%s (caml_gc *gc, struct caml_logger *lg, %s *%s_c)\n" % (ty.rawname, ty.typename, ty.rawname)
+    s += "static value Val_%s (caml_gc *gc, struct caml_logger *lg, %s)\n" % (ty.rawname, ty.make_arg(ty.rawname+"_c"))
     s += "{\n"
     s += "\tCAMLparam0();\n"
     s += "\tCAMLlocal1(%s_ocaml);\n" % ty.rawname

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT1-0000yH-0K; Mon, 16 Jan 2012 12:15:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSz-0000vr-GQ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25001 invoked from network); 16 Jan 2012 12:15:05 -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;
	16 Jan 2012 12:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671864"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cq032155;	Mon, 16 Jan 2012 04:15:03 -0800
MIME-Version: 1.0
X-Mercurial-Node: cf86bcb7c89568a2c60f246d0e2443acb756e1c1
Message-ID: <cf86bcb7c89568a2c60f.1326716100@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:00 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 32 RFC] libxl: use keyword arguments for
 field definitions in aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326190542 0
# Node ID cf86bcb7c89568a2c60f246d0e2443acb756e1c1
# Parent  485945937a27ea1d9736b8f9bf8d21183b928780
libxl: use keyword arguments for field definitions in aggregate types.

The original code is not so bad now that the comments are gone but this is
still a bit cleaner.

No change in the generated code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 485945937a27 -r cf86bcb7c895 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 10:15:42 2012 +0000
@@ -196,7 +196,7 @@ libxl_domain_build_info = Struct("domain
                                       ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
-                                      ("features", string, True),
+                                      ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", bool),
                                       ])),
diff -r 485945937a27 -r cf86bcb7c895 tools/libxl/libxltypes.py
--- a/tools/libxl/libxltypes.py	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/libxltypes.py	Tue Jan 10 10:15:42 2012 +0000
@@ -154,17 +154,17 @@ class Aggregate(Type):
 
         self.fields = []
         for f in fields:
-            # (name, type[, const=False])
+            # (name, type[, {kw args}])
             if len(f) == 2:
                 n,t = f
-                const = False
+                kw = {}
             elif len(f) == 3:
-                n,t,const = f
+                n,t,kw = f
             else:
                 raise ValueError
             if n is None:
                 raise ValueError
-            self.fields.append(Field(t,n,const=const))
+            self.fields.append(Field(t,n,**kw))
 
     # Returns a tuple (stem, field-expr)
     #

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlSy-0000x3-JP; Mon, 16 Jan 2012 12:15:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSx-0000vM-6c
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24923 invoked from network); 16 Jan 2012 12:15:04 -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;
	16 Jan 2012 12:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671848"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:02 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0co032155;	Mon, 16 Jan 2012 04:15:01 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:14:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 32 RFC] libxl: drop device_model_info,
 better defaults support, stubdoms 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

My original intention with this series was to introduce the ability
for users of libxl to explicitly say "pick the default". Mainly by
introducing the libxl_defbool type but also by arranging more
generally that leaving a value set to zero means "default".

However it turned into something of a yakk shaving excercise and so
contains the following:

* Removes support for comments in the IDL language itself. Generating
  comments in the generated files is not all that useful so lets just
  use source level comments in the .idl instead.

* Switches to using keyword arguments for Fields in Aggregate types
  instead of a variadic tuple.

* Removes libxl_device_model_info from the library API. The use of
  a device model to supply specific features is really an
  implementation detail within the library and not something users of
  the library should need to be concerned with.

  Many of the fields of the struct we really guest configuration
  details, e.g. VNC setup and therefore belong in
  libxl_domain_build_info.

  This struct also contained a number of things which were duplicated
  from the build_info and which could never sensibly differ in this
  context (e.g. guest total RAM, ACPI on off etc).

  I have tried to make a determination whether something belongs in
  the global part of libxl_domain_build_info or whether it is HVM
  specific.

  This forms a big part of the series.

* Introduce libxl_defbool and switch to using it.

* Some other changes to arrange that the 0 value means "default". At
  least one instance of this (the timer_mode enum) introduces a wierd
  disconnect between the underlying values and the libxl exposed
  values. I'm not sure that I like this.

* Use device model stubdoms by default when possible.

One question which arised from this change is how we deal with
per-arch options in the future. Do we need to define
libxl_domain_build_info_x86? We could also tag fields with a list of
architectures.

This series has been lightly tested with PV domains (with and without
PVFB) and HVM domains (with and without stubdom).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT6-00012M-8m; Mon, 16 Jan 2012 12:15:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT5-0000xL-2L
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5367 invoked from network); 16 Jan 2012 12:15:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907088"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cx032155;	Mon, 16 Jan 2012 04:15:09 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9f9995e2e34967929053c8c75e7c86562b58acf9
Message-ID: <9f9995e2e34967929053.1326716107@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 32 RFC] libxl: now that dm creation takes
 domain_config stop passing down 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326303938 0
# Node ID 9f9995e2e34967929053c8c75e7c86562b58acf9
# Parent  14605ae17bd9d8a3e2a5111ae6f06ffda0ddc441
libxl: now that dm creation takes domain_config stop passing down devices.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 14605ae17bd9 -r 9f9995e2e349 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 15:46:39 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:45:38 2012 +0000
@@ -559,8 +559,6 @@ static int do_domain_create(libxl__gc *g
 
         dm_info->domid = domid;
         ret = libxl__create_device_model(gc, d_config, dm_info,
-                                        d_config->disks, d_config->num_disks,
-                                        d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -606,8 +604,7 @@ static int do_domain_create(libxl__gc *g
             xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
             libxl__create_xenpv_qemu(gc, domid,
-                                     d_config, &xenpv_dm_info,
-                                     d_config->vfbs, &dm_starting);
+                                     d_config, &xenpv_dm_info, &dm_starting);
         }
         break;
     }
diff -r 14605ae17bd9 -r 9f9995e2e349 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 15:46:39 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 17:45:38 2012 +0000
@@ -84,10 +84,10 @@ static const char *libxl__domain_bios(li
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
+    const libxl_device_nic *vifs = guest_config->vifs;
+    const int num_vifs = guest_config->num_vifs;
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -239,11 +239,13 @@ static const char *qemu_disk_format_stri
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_device_disk *disks = guest_config->disks;
+    const libxl_device_nic *vifs = guest_config->vifs;
+    const int num_disks = guest_config->num_disks;
+    const int num_vifs = guest_config->num_vifs;
     flexarray_t *dm_args;
     int i;
 
@@ -504,21 +506,15 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (info->device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info,
-                                                  disks, num_disks,
-                                                  vifs, num_vifs);
+        return libxl__build_device_model_args_old(gc, dm, guest_config, info);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info,
-                                                  disks, num_disks,
-                                                  vifs, num_vifs);
+        return libxl__build_device_model_args_new(gc, dm, guest_config, info);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          info->device_model_version);
@@ -596,16 +592,14 @@ retry_transaction:
 static int libxl__create_stubdom(libxl__gc *gc,
                                  libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
-                                 libxl_device_disk *disks, int num_disks,
-                                 libxl_device_nic *vifs, int num_vifs,
-                                 libxl_device_vfb *vfb,
-                                 libxl_device_vkb *vkb,
                                  libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl_device_console *console;
     libxl_domain_config dm_config;
+    libxl_device_vfb vfb;
+    libxl_device_vkb vkb;
     libxl__domain_build_state state;
     uint32_t domid;
     char **args;
@@ -637,6 +631,19 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
+    dm_config.disks = guest_config->disks;
+    dm_config.num_disks = guest_config->num_disks;
+
+    dm_config.vifs = guest_config->vifs;
+    dm_config.num_vifs = guest_config->num_vifs;
+
+    libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
+
+    dm_config.vfbs = &vfb;
+    dm_config.num_vfbs = 1;
+    dm_config.vkbs = &vkb;
+    dm_config.num_vkbs = 1;
+
     /* fixme: this function can leak the stubdom if it fails */
     domid = 0;
     ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
@@ -647,9 +654,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
 
     args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info,
-                                          disks, num_disks,
-                                          vifs, num_vifs);
+                                          guest_config, info);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
@@ -684,20 +689,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &disks[i]);
+    for (i = 0; i < dm_config.num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, domid, &dm_config.disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &vifs[i]);
+    for (i = 0; i < dm_config.num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, domid, &dm_config.vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, domid, vfb);
+    ret = libxl_device_vfb_add(ctx, domid, &dm_config.vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, domid, vkb);
+    ret = libxl_device_vkb_add(ctx, domid, &dm_config.vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -755,7 +760,7 @@ retry_transaction:
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
                                  &xenpv_dm_info,
-                                 vfb, &dm_starting) < 0) {
+                                 &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -785,8 +790,6 @@ out:
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disks, int num_disks,
-                              libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -801,14 +804,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (info->device_model_stubdomain) {
-        libxl_device_vfb vfb;
-        libxl_device_vkb vkb;
-
-        libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-        rc = libxl__create_stubdom(gc, guest_config, info,
-                                   disks, num_disks,
-                                   vifs, num_vifs,
-                                   &vfb, &vkb, starting_r);
+        rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
         goto out;
     }
 
@@ -823,9 +819,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info,
-                                          disks, num_disks,
-                                          vifs, num_vifs);
+    args = libxl__build_device_model_args(gc, dm, guest_config, info);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
@@ -1046,11 +1040,10 @@ out:
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
-                             libxl_device_vfb *vfb,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, vfb, info);
-    libxl__create_device_model(gc, guest_config, info, NULL, 0, NULL, 0, starting_r);
+    libxl__build_xenpv_qemu_args(gc, domid, &guest_config->vfbs[0], info);
+    libxl__create_device_model(gc, guest_config, info, starting_r);
     return 0;
 }
 
diff -r 14605ae17bd9 -r 9f9995e2e349 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Jan 11 15:46:39 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Jan 11 17:45:38 2012 +0000
@@ -467,13 +467,10 @@ _hidden const char *libxl__domain_device
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disks, int num_disks,
-                              libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
-                              libxl_device_vfb *vfb,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT4-00010n-LU; Mon, 16 Jan 2012 12:15: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 1RmlT3-0000wn-FV
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25229 invoked from network); 16 Jan 2012 12:15:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671881"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:08 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cu032155;	Mon, 16 Jan 2012 04:15:07 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3308d2dfd9dddb36f8a65e7a44916c6bcf02170e
Message-ID: <3308d2dfd9dddb36f8a6.1326716104@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:04 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 32 RFC] libxl: define libxl_spice_info to
 hold all info about the spice server
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326215019 0
# Node ID 3308d2dfd9dddb36f8a65e7a44916c6bcf02170e
# Parent  ed7106b3f874d93e8ed8d05a8464099e611edd0b
libxl: define libxl_spice_info to hold all info about the spice server

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ed7106b3f874 -r 3308d2dfd9dd tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Jan 10 16:19:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Tue Jan 10 17:03:39 2012 +0000
@@ -298,39 +298,39 @@ static char ** libxl__build_device_model
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
     }
-    if (info->spice) {
+    if (info->spice.enable) {
         char *spiceoptions = NULL;
-        if (!info->spiceport && !info->spicetls_port) {
+        if (!info->spice.port && !info->spice.tls_port) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "at least one of the spiceport or tls_port must be provided");
             return NULL;
         }
 
-        if (!info->spicedisable_ticketing) {
-            if (!info->spicepasswd) {
+        if (!info->spice.disable_ticketing) {
+            if (!info->spice.passwd) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                     "spice ticketing is enabled but missing password");
                 return NULL;
             }
-            else if (!info->spicepasswd[0]) {
+            else if (!info->spice.passwd[0]) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                     "spice password can't be empty");
                 return NULL;
             }
         }
         spiceoptions = libxl__sprintf(gc, "port=%d,tls-port=%d",
-                       info->spiceport, info->spicetls_port);
-        if (info->spicehost)
+                                      info->spice.port, info->spice.tls_port);
+        if (info->spice.host)
             spiceoptions = libxl__sprintf(gc,
-                    "%s,addr=%s", spiceoptions, info->spicehost);
-        if (info->spicedisable_ticketing)
+                    "%s,addr=%s", spiceoptions, info->spice.host);
+        if (info->spice.disable_ticketing)
             spiceoptions = libxl__sprintf(gc, "%s,disable-ticketing",
                                                spiceoptions);
         else
             spiceoptions = libxl__sprintf(gc,
-                    "%s,password=%s", spiceoptions, info->spicepasswd);
+                    "%s,password=%s", spiceoptions, info->spice.passwd);
         spiceoptions = libxl__sprintf(gc, "%s,agent-mouse=%s", spiceoptions,
-                                      info->spiceagent_mouse ? "on" : "off");
+                                      info->spice.agent_mouse ? "on" : "off");
 
         flexarray_append(dm_args, "-spice");
         flexarray_append(dm_args, spiceoptions);
diff -r ed7106b3f874 -r 3308d2dfd9dd tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 16:19:52 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 17:03:39 2012 +0000
@@ -105,6 +105,26 @@ libxl_vnc_info = Struct("vnc_info", [
     ("findunused",    bool),
     ])
 
+libxl_spice_info = Struct("spice_info", [
+    ("enable",            bool),
+    # At least one of spice port or spicetls_post must be given
+    ("port",        integer),
+    ("tls_port",    integer),
+    # Interface to bind to
+    ("host",        string),
+    # enable client connection with no password
+    ("disable_ticketing", bool),
+    ("passwd",      string),
+    ("agent_mouse", bool),
+    ])
+
+libxl_sdl_info = Struct("sdl_info", [
+    ("enable",        bool),
+    ("opengl",        bool),
+    ("display",       string),
+    ("xauthority",    string),
+    ])
+
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
@@ -237,16 +257,7 @@ libxl_device_model_info = Struct("device
     ("keymap",           string),
     ("sdl",              bool),
     ("opengl",           bool), # (requires sdl enabled)
-    ("spice",            bool),
-    # At least one of spice port or spicetls_post must be given
-    ("spiceport",        integer),
-    ("spicetls_port",    integer),
-    # Interface to bind to
-    ("spicehost",        string),
-    # enable client connection with no password
-    ("spicedisable_ticketing", bool),
-    ("spicepasswd",      string),
-    ("spiceagent_mouse", bool),
+    ("spice",            libxl_spice_info),
     ("nographic",        bool),
     ("gfx_passthru",     bool),
     ("serial",           string),
diff -r ed7106b3f874 -r 3308d2dfd9dd tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 16:19:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:03:39 2012 +0000
@@ -378,13 +378,13 @@ static void printf_info(int domid,
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
         printf("\t\t\t(acpi %d)\n", dm_info->acpi);
-        printf("\t\t\t(spice %d)\n", dm_info->spice);
-        printf("\t\t\t(spiceport %d)\n", dm_info->spiceport);
-        printf("\t\t\t(spicetls_port %d)\n", dm_info->spicetls_port);
-        printf("\t\t\t(spicehost %s)\n", dm_info->spicehost);
+        printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
+        printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", dm_info->spice.host);
         printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    dm_info->spicedisable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spiceagent_mouse);
+                    dm_info->spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spice.agent_mouse);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1191,19 +1191,20 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            dm_info->spice = l;
+            dm_info->spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
-            dm_info->spiceport = l;
+            dm_info->spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
-            dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+            dm_info->spice.tls_port = l;
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spice.host, 0);
         if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+            dm_info->spice.disable_ticketing = l;
+        xlu_cfg_replace_string (config, "spicepasswd",
+                                &dm_info->spice.passwd, 0);
         if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            dm_info->spiceagent_mouse = l;
+            dm_info->spice.agent_mouse = l;
         else
-            dm_info->spiceagent_mouse = 1;
+            dm_info->spice.agent_mouse = 1;
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT1-0000yX-DY; Mon, 16 Jan 2012 12:15:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSz-0000w0-TJ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25094 invoked from network); 16 Jan 2012 12:15:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671877"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:06 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0GCF0cs032155;	Mon, 16 Jan 2012 04:15:05 -0800
MIME-Version: 1.0
X-Mercurial-Node: d5c8efa9ef9e55a08e06a6011681bdb827dd88c7
Message-ID: <d5c8efa9ef9e55a08e06.1326716102@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 32 RFC] ocaml: Correct ocaml type name for
 Aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326212349 0
# Node ID d5c8efa9ef9e55a08e06a6011681bdb827dd88c7
# Parent  07c4b8a8d50c8562472c8f6607ec145146c3828c
ocaml: Correct ocaml type name for Aggregate types.

No change to the generated code because this path isn't used yet.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 07c4b8a8d50c -r d5c8efa9ef9e tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Tue Jan 10 16:18:53 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Tue Jan 10 16:19:09 2012 +0000
@@ -59,6 +59,8 @@ def ocaml_type_of(ty):
         if not typename:
             raise NotImplementedError("No typename for Builtin %s (%s)" % (ty.typename, type(ty)))
         return typename
+    elif isinstance(ty,libxltypes.Aggregate):
+        return ty.rawname.capitalize() + ".t"
     else:
         return ty.rawname
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlT0-0000xb-0W; Mon, 16 Jan 2012 12:15:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSx-0000vV-Oi
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4911 invoked from network); 16 Jan 2012 12:15:05 -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;
	16 Jan 2012 12:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907084"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:03 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:03 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0GCF0cp032155;	Mon, 16 Jan 2012 04:15:02 -0800
MIME-Version: 1.0
X-Mercurial-Node: 485945937a27ea1d9736b8f9bf8d21183b928780
Message-ID: <485945937a27ea1d9736.1326716099@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:14:59 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 32 RFC] libxl: remove comment support from
	IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326190542 0
# Node ID 485945937a27ea1d9736b8f9bf8d21183b928780
# Parent  f4956ec4b28602f512b69d07f5ea3d001dc688ad
libxl: remove comment support from IDL

People typically don't look for comments in generated source and the syntax for
specifying them in the IDL makes things harder to follow.

Instead just use source code comments in the IDL itself.

I dropped a bunch of "foo bool # enable or disable foo" type comments. A lot of
the remainder still aren't terribly useful though.

No change to the generate code other than the comments being removed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r f4956ec4b286 -r 485945937a27 tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/gentypes.py	Tue Jan 10 10:15:42 2012 +0000
@@ -5,19 +5,6 @@ import re
 
 import libxltypes
 
-def format_comment(level, comment):
-    indent = reduce(lambda x,y: x + " ", range(level), "")
-    s  = "%s/*\n" % indent
-    s += "%s * " % indent
-    comment = comment.replace("\n", "\n%s * " % indent)
-    x = re.compile(r'^%s \* $' % indent, re.MULTILINE)
-    comment = x.sub("%s *" % indent, comment)
-    s += comment
-    s += "\n"
-    s += "%s */" % indent
-    s += "\n"
-    return s
-
 def libxl_C_instance_of(ty, instancename):
     if isinstance(ty, libxltypes.Aggregate) and ty.typename is None:
         if instancename is None:
@@ -30,17 +17,12 @@ def libxl_C_instance_of(ty, instancename
 def libxl_C_type_define(ty, indent = ""):
     s = ""
     if isinstance(ty, libxltypes.Enumeration):
-        if ty.comment is not None:
-            s += format_comment(0, ty.comment)
-
         if ty.typename is None:
             s += "enum {\n"
         else:
             s += "typedef enum %s {\n" % ty.typename
 
         for v in ty.values:
-            if v.comment is not None:
-                s += format_comment(4, v.comment)
             x = "%s = %d" % (v.name, v.value)
             x = x.replace("\n", "\n    ")
             s += "    " + x + ",\n"
@@ -50,17 +32,12 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, libxltypes.Aggregate):
-        if ty.comment is not None:
-            s += format_comment(0, ty.comment)
-
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
             s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
-            if f.comment is not None:
-                s += format_comment(4, f.comment)
             x = libxl_C_instance_of(f.type, f.name)
             if f.const:
                 x = "const " + x
diff -r f4956ec4b286 -r 485945937a27 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 10 10:15:42 2012 +0000
@@ -28,8 +28,8 @@ libxl_domain_type = Enumeration("domain_
     ])
 
 libxl_device_model_version = Enumeration("device_model_version", [
-    (1, "QEMU_XEN_TRADITIONAL", "Historical qemu-xen device model (qemu-dm)"),
-    (2, "QEMU_XEN", "Upstream based qemu-xen device model"),
+    (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm)
+    (2, "QEMU_XEN"),             # Upstream based qemu-xen device model
     ])
 
 libxl_console_type = Enumeration("console_type", [
@@ -98,18 +98,18 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
-    ("ssidref",      uint32),
+    ("ssidref",     uint32),
     ("running",     bool),
     ("blocked",     bool),
     ("paused",      bool),
     ("shutdown",    bool),
     ("dying",       bool),
 
-    ("shutdown_reason", uint8, False,
-"""Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
-
-Otherwise set to a value guaranteed not to clash with any valid
-SHUTDOWN_* constant."""),
+    # Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
+    #
+    # Otherwise set to a value guaranteed not to clash with any valid
+    # SHUTDOWN_* constant.
+    ("shutdown_reason", uint8),
     ("current_memkb",   uint64),
     ("shared_memkb", uint64),
     ("max_memkb",   uint64),
@@ -159,6 +159,11 @@ libxl_domain_create_info = Struct("domai
     ("poolname",     string),
     ])
 
+# Instances of libxl_file_reference contained in this struct which
+# have been mapped (with libxl_file_reference_map) will be unmapped
+# by libxl_domain_build/restore. If either of these are never called
+# then the user is responsible for calling
+# libxl_file_reference_unmap.
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
@@ -192,84 +197,87 @@ libxl_domain_build_info = Struct("domain
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
-                                      ("e820_host", bool, False, "Use host's E820 for PCI passthrough."),
+                                      # Use host's E820 for PCI passthrough.
+                                      ("e820_host", bool),
                                       ])),
                  ])),
     ],
-    comment =
-"""Instances of libxl_file_reference contained in this struct which
-have been mapped (with libxl_file_reference_map) will be unmapped
-by libxl_domain_build/restore. If either of these are never called
-then the user is responsible for calling
-libxl_file_reference_unmap.""")
+)
 
+# Device Model Information
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
-    ("uuid",             libxl_uuid,  False, "this is use only with stubdom, and must be different from the domain uuid"),
+    
+    # uuid is used only with stubdom, and must be different from the
+    # domain uuid
+    ("uuid",             libxl_uuid),
     ("dom_name",         string),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
-    ("device_model",     string, False, "if you set this you must set device_model_version too"),
+    # you set device_model you must set device_model_version too
+    ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
     ("target_ram",       uint32),
-    ("videoram",         integer,           False, "size of the videoram in MB"),
-    ("stdvga",           bool,              False, "stdvga enabled or disabled"),
-    ("vnc",              bool,              False, "vnc enabled or disabled"),
-    ("vnclisten",        string,            False, "address:port that should be listened on for the VNC server if vnc is set"),
-    ("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"),
-    ("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)"),
-    ("spice",            bool,              False,
-    "spice enabled or disabled"),
-    ("spiceport",        integer,           False,
-    "the port that should be listened on for the spice server"),
-    ("spicetls_port",    integer,           False, """the tls port
-that should be listened on for the spice server,
-at least one of the port or tls port must be given"""),
-    ("spicehost",        string,            False, """the interface
-that should be listened on if given otherwise any interface"""),
-    ("spicedisable_ticketing", bool,        False,
-    "enable client connection with no password"),
-    ("spicepasswd",      string,            False, """set ticket password
-witch must be used by a client for connection.
-The password never expires"""),
-    ("spiceagent_mouse", bool,              False,
-    "Whether spice agent is used for client mouse mode(default is on)"),
-    ("nographic",        bool,              False, "no graphics, use serial port"),
-    ("gfx_passthru",     bool,              False, "graphics passthrough enabled or disabled"),
-    ("serial",           string,            False, "serial port re-direct to pty deivce"),
-    ("boot",             string,            False, "boot order, for example dca"),
-    ("usb",              bool,              False, "usb support enabled or disabled"),
-    ("usbdevice",        string,            False, "enable usb mouse: tablet for absolute mouse, mouse for PS/2 protocol relative mouse"),
-    ("soundhw",          string,            False, "enable sound hardware"),
-    ("acpi",             bool,              False, "acpi enabled or disabled"),
-    ("vcpus",            integer,           False, "max number of vcpus"),
-    ("vcpu_avail",       integer,           False, "vcpus actually available"),
-    ("xen_platform_pci", bool,              False, "enable/disable the xen platform pci device"),
-    ("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"),
+    # size of the videoram in MB
+    ("videoram",         integer), 
+    ("stdvga",           bool),
+    ("vnc",              bool),
+    # "address:port" that should be listened on for the VNC server
+    ("vnclisten",        string),
+    ("vncpasswd",        string),
+    # VNC display number
+    ("vncdisplay",       integer),
+    # If set then try to find an unused port for the VNC server
+    ("vncunused",        bool),
+    # keyboard layout, default is en-us keyboard
+    ("keymap",           string),
+    ("sdl",              bool),
+    ("opengl",           bool), # (requires sdl enabled)
+    ("spice",            bool),
+    # At least one of spice port or spicetls_post must be given
+    ("spiceport",        integer),
+    ("spicetls_port",    integer),
+    # Interface to bind to
+    ("spicehost",        string),
+    # enable client connection with no password
+    ("spicedisable_ticketing", bool),
+    ("spicepasswd",      string),
+    ("spiceagent_mouse", bool),
+    ("nographic",        bool),
+    ("gfx_passthru",     bool),
+    ("serial",           string),
+    ("boot",             string),
+    ("usb",              bool),
+    # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
+    ("usbdevice",        string),
+    ("soundhw",          string),
+    ("acpi",             bool),
+    ("vcpus",            integer), # max number of vcpus
+    ("vcpu_avail",       integer), # vcpus actually available
+    ("xen_platform_pci", bool),
+    # extra parameters pass directly to qemu, NULL terminated
+    ("extra",            libxl_string_list),
+    # extra parameters pass directly to qemu for PV guest, NULL terminated
+    ("extra_pv",         libxl_string_list),
+    # extra parameters pass directly to qemu for HVM guest, NULL terminated
+    ("extra_hvm",        libxl_string_list),
     ],
-    comment=
-"""Device Model information.
-
-Network is missing""")
+)
 
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
-    ("vnc",           bool,     False, "vnc enabled or disabled"),
-    ("vnclisten",     string,   False, "address:port that should be listened on for the VNC server if vnc is set"),
-    ("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"),
-    ("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)"),
+    ("vnc",           bool),
+    # address:port that should be listened on for the VNC server if vnc is set
+    ("vnclisten",     string),
+    ("vncpasswd",     string),
+    ("vncdisplay",    integer),
+    ("vncunused",     bool),
+    # set keyboard layout, default is en-us keyboard
+    ("keymap",        string),
+    ("sdl",           bool),
+    ("opengl",        bool), # (if enabled requires sdl enabled)
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -346,13 +354,13 @@ libxl_nicinfo = Struct("nicinfo", [
     ])
 
 libxl_vcpuinfo = Struct("vcpuinfo", [
-    ("vcpuid", uint32,              False, "vcpu's id"),
-    ("cpu", uint32,                 False, "current mapping"),
-    ("online", bool,                False, "currently online (not hotplugged)?"),
-    ("blocked", bool,               False, "blocked waiting for an event?"),
-    ("running", bool,               False, "currently scheduled on its CPU?"),
-    ("vcpu_time", uint64,           False, "total vcpu time ran (ns)"),
-    ("cpumap", libxl_cpumap,        False, "current cpu's affinities"),
+    ("vcpuid", uint32),
+    ("cpu", uint32),
+    ("online", bool),
+    ("blocked", bool),
+    ("running", bool),
+    ("vcpu_time", uint64), # total vcpu time ran (ns)
+    ("cpumap", libxl_cpumap), # current cpu's affinities
     ])
 
 libxl_physinfo = Struct("physinfo", [
@@ -373,9 +381,9 @@ libxl_physinfo = Struct("physinfo", [
     ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_topologyinfo = Struct("topologyinfo", [
-    ("coremap", libxl_cpuarray,   False, "cpu to core map"),
-    ("socketmap", libxl_cpuarray, False, "cpu to socket map"),
-    ("nodemap", libxl_cpuarray,   False, "cpu to node map"),
+    ("coremap", libxl_cpuarray),   # cpu to core map
+    ("socketmap", libxl_cpuarray), # cpu to socket map
+    ("nodemap", libxl_cpuarray),   # cpu to node map
     ])
 
 libxl_sched_credit = Struct("sched_credit", [
diff -r f4956ec4b286 -r 485945937a27 tools/libxl/libxltypes.py
--- a/tools/libxl/libxltypes.py	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/libxl/libxltypes.py	Tue Jan 10 10:15:42 2012 +0000
@@ -22,7 +22,6 @@ def _get_default_namespace():
 
 class Type(object):
     def __init__(self, typename, **kwargs):
-        self.comment = kwargs.setdefault('comment', None)
         self.namespace = kwargs.setdefault('namespace',
                 _get_default_namespace())
         self.dir = kwargs.setdefault('dir', DIR_BOTH)
@@ -120,7 +119,6 @@ class EnumerationValue(object):
         self.rawname = str.upper(enum.rawname) + "_" + self.valuename
         self.name = str.upper(enum.namespace) + self.rawname
         self.value = value
-        self.comment = kwargs.setdefault("comment", None)
 
 class Enumeration(Type):
     def __init__(self, typename, values, **kwargs):
@@ -129,16 +127,9 @@ class Enumeration(Type):
 
         self.values = []
         for v in values:
-            # (value, name[, comment=None])
-            if len(v) == 2:
-                (num,name) = v
-                comment = None
-            elif len(v) == 3:
-                num,name,comment = v
-            else:
-                raise ""
+            # (value, name)
+            (num,name) = v
             self.values.append(EnumerationValue(self, num, name,
-                                                comment=comment,
                                                 typename=self.rawname))
     def lookup(self, name):
         for v in self.values:
@@ -152,7 +143,6 @@ class Field(object):
         self.type = type
         self.name = name
         self.const = kwargs.setdefault('const', False)
-        self.comment = kwargs.setdefault('comment', None)
         self.enumname = kwargs.setdefault('enumname', None)
 
 class Aggregate(Type):
@@ -164,19 +154,17 @@ class Aggregate(Type):
 
         self.fields = []
         for f in fields:
-            # (name, type[, const=False[, comment=None]])
+            # (name, type[, const=False])
             if len(f) == 2:
                 n,t = f
                 const = False
-                comment = None
             elif len(f) == 3:
                 n,t,const = f
-                comment = None
             else:
-                n,t,const,comment = f
+                raise ValueError
             if n is None:
                 raise ValueError
-            self.fields.append(Field(t,n,const=const,comment=comment))
+            self.fields.append(Field(t,n,const=const))
 
     # Returns a tuple (stem, field-expr)
     #

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlSy-0000x3-JP; Mon, 16 Jan 2012 12:15:12 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSx-0000vM-6c
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24923 invoked from network); 16 Jan 2012 12:15:04 -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;
	16 Jan 2012 12:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671848"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:02 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0co032155;	Mon, 16 Jan 2012 04:15:01 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:14:58 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 32 RFC] libxl: drop device_model_info,
 better defaults support, stubdoms 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

My original intention with this series was to introduce the ability
for users of libxl to explicitly say "pick the default". Mainly by
introducing the libxl_defbool type but also by arranging more
generally that leaving a value set to zero means "default".

However it turned into something of a yakk shaving excercise and so
contains the following:

* Removes support for comments in the IDL language itself. Generating
  comments in the generated files is not all that useful so lets just
  use source level comments in the .idl instead.

* Switches to using keyword arguments for Fields in Aggregate types
  instead of a variadic tuple.

* Removes libxl_device_model_info from the library API. The use of
  a device model to supply specific features is really an
  implementation detail within the library and not something users of
  the library should need to be concerned with.

  Many of the fields of the struct we really guest configuration
  details, e.g. VNC setup and therefore belong in
  libxl_domain_build_info.

  This struct also contained a number of things which were duplicated
  from the build_info and which could never sensibly differ in this
  context (e.g. guest total RAM, ACPI on off etc).

  I have tried to make a determination whether something belongs in
  the global part of libxl_domain_build_info or whether it is HVM
  specific.

  This forms a big part of the series.

* Introduce libxl_defbool and switch to using it.

* Some other changes to arrange that the 0 value means "default". At
  least one instance of this (the timer_mode enum) introduces a wierd
  disconnect between the underlying values and the libxl exposed
  values. I'm not sure that I like this.

* Use device model stubdoms by default when possible.

One question which arised from this change is how we deal with
per-arch options in the future. Do we need to define
libxl_domain_build_info_x86? We could also tag fields with a list of
architectures.

This series has been lightly tested with PV domains (with and without
PVFB) and HVM domains (with and without stubdom).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTA-00018k-9O; Mon, 16 Jan 2012 12:15:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT8-0000zW-6i
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5555 invoked from network); 16 Jan 2012 12:15:15 -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;
	16 Jan 2012 12:15:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907091"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:14 -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
	q0GCF0d3032155;	Mon, 16 Jan 2012 04:15:13 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0ef52f0b6c58344ee371d668ea343628aaecb714
Message-ID: <0ef52f0b6c58344ee371.1326716111@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 32 RFC] libxl: move HVM emulated GFX
 support into b_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326367192 0
# Node ID 0ef52f0b6c58344ee371d668ea343628aaecb714
# Parent  714cb45a8327bae6ede162f12e21cc8e0397ae1f
libxl: move HVM emulated GFX support into b_info->u.hvm

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 714cb45a8327 -r 0ef52f0b6c58 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 10:25:59 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 11:19:52 2012 +0000
@@ -99,6 +99,16 @@ 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.stdvga = 0;
+        b_info->u.hvm.vnc.enable = 1;
+        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
+        b_info->u.hvm.vnc.display = 0;
+        b_info->u.hvm.vnc.findunused = 1;
+        b_info->u.hvm.keymap = NULL;
+        b_info->u.hvm.sdl.enable = 0;
+        b_info->u.hvm.sdl.opengl = 0;
+        b_info->u.hvm.nographic = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -124,17 +134,7 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
-    dm_info->videoram = libxl__sizekb_to_mb(b_info->video_memkb);
 
-    dm_info->stdvga = 0;
-    dm_info->vnc.enable = 1;
-    dm_info->vnc.listen = strdup("127.0.0.1");
-    dm_info->vnc.display = 0;
-    dm_info->vnc.findunused = 1;
-    dm_info->keymap = NULL;
-    dm_info->sdl.enable = 0;
-    dm_info->sdl.opengl = 0;
-    dm_info->nographic = 0;
     dm_info->serial = NULL;
     dm_info->boot = strdup("cda");
     dm_info->usb = 0;
diff -r 714cb45a8327 -r 0ef52f0b6c58 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 10:25:59 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 11:19:52 2012 +0000
@@ -86,7 +86,7 @@ static const libxl_vnc_info *dm_vnc(cons
 {
     const libxl_vnc_info *vnc = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        vnc = &info->vnc;
+        vnc = &guest_config->b_info.u.hvm.vnc;
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
@@ -98,13 +98,24 @@ static const libxl_sdl_info *dm_sdl(cons
 {
     const libxl_sdl_info *sdl = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        sdl = &info->sdl;
+        sdl = &guest_config->b_info.u.hvm.sdl;
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
     return sdl && sdl->enable ? sdl : NULL;
 }
 
+static const char *dm_keymap(const libxl_domain_config *guest_config,
+                             const libxl_device_model_info *info)
+{
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        return guest_config->b_info.u.hvm.keymap;
+    } else if (guest_config->num_vfbs > 0) {
+        return guest_config->vfbs[0].keymap;
+    } else
+        return NULL;
+}
+
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -116,6 +127,7 @@ static char ** libxl__build_device_model
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     const int num_vifs = guest_config->num_vifs;
+    const char *keymap = dm_keymap(guest_config, info);
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -164,11 +176,8 @@ static char ** libxl__build_device_model
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
-    if (info->keymap) {
-        flexarray_vappend(dm_args, "-k", info->keymap, NULL);
-    }
-    if (info->nographic && (!sdl && !vnc)) {
-        flexarray_append(dm_args, "-nographic");
+    if (keymap) {
+        flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
     if (info->serial) {
         flexarray_vappend(dm_args, "-serial", info->serial, NULL);
@@ -176,10 +185,17 @@ static char ** libxl__build_device_model
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
-        if (info->videoram) {
-            flexarray_vappend(dm_args, "-videoram", libxl__sprintf(gc, "%d", info->videoram), NULL);
+        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+            flexarray_append(dm_args, "-nographic");
         }
-        if (info->stdvga) {
+
+        if (b_info->video_memkb) {
+            flexarray_vappend(dm_args, "-videoram",
+                    libxl__sprintf(gc, "%d",
+                                   libxl__sizekb_to_mb(b_info->video_memkb)),
+                    NULL);
+        }
+        if (b_info->u.hvm.stdvga) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -233,7 +249,11 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+    } else {
+        if (!sdl && !vnc)
+            flexarray_append(dm_args, "-nographic");
     }
+
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
     }
@@ -268,6 +288,42 @@ static const char *qemu_disk_format_stri
     }
 }
 
+static char *dm_spice_options(libxl__gc *gc,
+                                    const libxl_spice_info *spice)
+{
+    char *opt;
+
+    if (!spice->port && !spice->tls_port) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "at least one of the spiceport or tls_port must be provided");
+        return NULL;
+    }
+
+    if (!spice->disable_ticketing) {
+        if (!spice->passwd) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "spice ticketing is enabled but missing password");
+            return NULL;
+        }
+        else if (!spice->passwd[0]) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                               "spice password can't be empty");
+            return NULL;
+        }
+    }
+    opt = libxl__sprintf(gc, "port=%d,tls-port=%d",
+                         spice->port, spice->tls_port);
+    if (spice->host)
+        opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
+    if (spice->disable_ticketing)
+        opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
+    else
+        opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
+    opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
+                         spice->agent_mouse ? "on" : "off");
+    return opt;
+}
+
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -282,6 +338,7 @@ static char ** libxl__build_device_model
     const int num_vifs = guest_config->num_vifs;
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
+    const char *keymap = dm_keymap(guest_config, info);
     flexarray_t *dm_args;
     int i;
 
@@ -340,61 +397,36 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-sdl");
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
-    if (info->spice.enable) {
-        char *spiceoptions = NULL;
-        if (!info->spice.port && !info->spice.tls_port) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                "at least one of the spiceport or tls_port must be provided");
-            return NULL;
-        }
 
-        if (!info->spice.disable_ticketing) {
-            if (!info->spice.passwd) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                    "spice ticketing is enabled but missing password");
-                return NULL;
-            }
-            else if (!info->spice.passwd[0]) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                    "spice password can't be empty");
-                return NULL;
-            }
-        }
-        spiceoptions = libxl__sprintf(gc, "port=%d,tls-port=%d",
-                                      info->spice.port, info->spice.tls_port);
-        if (info->spice.host)
-            spiceoptions = libxl__sprintf(gc,
-                    "%s,addr=%s", spiceoptions, info->spice.host);
-        if (info->spice.disable_ticketing)
-            spiceoptions = libxl__sprintf(gc, "%s,disable-ticketing",
-                                               spiceoptions);
-        else
-            spiceoptions = libxl__sprintf(gc,
-                    "%s,password=%s", spiceoptions, info->spice.passwd);
-        spiceoptions = libxl__sprintf(gc, "%s,agent-mouse=%s", spiceoptions,
-                                      info->spice.agent_mouse ? "on" : "off");
+    /*if (info->type == LIBXL_DOMAIN_TYPE_PV && !b_info->nographic) {
+        flexarray_vappend(dm_args, "-vga", "xenfb", NULL);
+      } never was possible?*/
 
-        flexarray_append(dm_args, "-spice");
-        flexarray_append(dm_args, spiceoptions);
+    if (keymap) {
+        flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->type == LIBXL_DOMAIN_TYPE_PV && !info->nographic) {
-        flexarray_vappend(dm_args, "-vga", "xenfb", NULL);
-    }
-
-    if (info->keymap) {
-        flexarray_vappend(dm_args, "-k", info->keymap, NULL);
-    }
-    if (info->nographic && (!sdl && !vnc)) {
-        flexarray_append(dm_args, "-nographic");
-    }
     if (info->serial) {
         flexarray_vappend(dm_args, "-serial", info->serial, NULL);
     }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
-        if (info->stdvga) {
+        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+            flexarray_append(dm_args, "-nographic");
+        }
+
+        if (b_info->u.hvm.spice.enable) {
+            const libxl_spice_info *spice = &b_info->u.hvm.spice;
+            char *spiceoptions = dm_spice_options(gc, spice);
+            if (!spiceoptions)
+                return NULL;
+
+            flexarray_append(dm_args, "-spice");
+            flexarray_append(dm_args, spiceoptions);
+        }
+
+        if (b_info->u.hvm.stdvga) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -454,7 +486,12 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+    } else {
+        if (!sdl && !vnc) {
+            flexarray_append(dm_args, "-nographic");
+        }
     }
+
     if (info->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
         int migration_fd = open(info->saved_state, O_RDONLY);
@@ -563,19 +600,24 @@ static char ** libxl__build_device_model
     }
 }
 
-static int libxl__vfb_and_vkb_from_device_model_info(libxl__gc *gc,
-                                        const libxl_device_model_info *info,
+static int libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc *gc,
+                                        const libxl_domain_config *guest_config,
                                         libxl_device_vfb *vfb,
                                         libxl_device_vkb *vkb)
 {
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
+
+    if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
-    vfb->vnc = info->vnc;
-    vfb->keymap = info->keymap;
-    vfb->sdl = info->sdl;
+    vfb->vnc = b_info->u.hvm.vnc;
+    vfb->keymap = b_info->u.hvm.keymap;
+    vfb->sdl = b_info->u.hvm.sdl;
 
     vkb->backend_domid = 0;
     vkb->devid = 0;
@@ -678,8 +720,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
-    libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-
+    libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
     dm_config.vkbs = &vkb;
diff -r 714cb45a8327 -r 0ef52f0b6c58 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 10:25:59 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 11:19:52 2012 +0000
@@ -219,6 +219,13 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("nographic",        bool),
+                                       ("stdvga",           bool),
+                                       ("vnc",              libxl_vnc_info),
+                                       # keyboard layout, default is en-us keyboard
+                                       ("keymap",           string),
+                                       ("sdl",              libxl_sdl_info),
+                                       ("spice",            libxl_spice_info),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -247,15 +254,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    # size of the videoram in MB
-    ("videoram",         integer), 
-    ("stdvga",           bool),
-    ("vnc",              libxl_vnc_info),
-    # keyboard layout, default is en-us keyboard
-    ("keymap",           string),
-    ("sdl",              libxl_sdl_info),
-    ("spice",            libxl_spice_info),
-    ("nographic",        bool),
     ("gfx_passthru",     bool),
     ("serial",           string),
     ("boot",             string),
diff -r 714cb45a8327 -r 0ef52f0b6c58 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 10:25:59 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:19:52 2012 +0000
@@ -361,29 +361,29 @@ static void printf_info(int domid,
         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(stdvga %d)\n", b_info->u.hvm.stdvga);
+        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
+        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
+        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
+        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
+        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
+        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
+        printf("\t\t\t(spicedisable_ticketing %d)\n",
+                    b_info->u.hvm.spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
-        printf("\t\t\t(videoram %d)\n", dm_info->videoram);
-        printf("\t\t\t(stdvga %d)\n", dm_info->stdvga);
-        printf("\t\t\t(vnc %d)\n", dm_info->vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", dm_info->vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
-        printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", dm_info->keymap);
-        printf("\t\t\t(sdl %d)\n", dm_info->sdl.enable);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(opengl %d)\n", dm_info->sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", dm_info->nographic);
         printf("\t\t\t(serial %s)\n", dm_info->serial);
         printf("\t\t\t(boot %s)\n", dm_info->boot);
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
-        printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
-        printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
-        printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);
-        printf("\t\t\t(spicehost %s)\n", dm_info->spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    dm_info->spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spice.agent_mouse);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1175,37 +1175,38 @@ skip_vfb:
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            dm_info->stdvga = l;
+            b_info->u.hvm.stdvga = l;
         if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            dm_info->vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vnc.passwd, 0);
+            b_info->u.hvm.vnc.enable = l;
+        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
-            dm_info->vnc.display = l;
+            b_info->u.hvm.vnc.display = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            dm_info->vnc.findunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            dm_info->sdl.enable = l;
+            b_info->u.hvm.sdl.enable = l;
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            dm_info->sdl.opengl = l;
+            b_info->u.hvm.sdl.opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            dm_info->spice.enable = l;
+            b_info->u.hvm.spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
-            dm_info->spice.port = l;
+            b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
-            dm_info->spice.tls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spice.host, 0);
+            b_info->u.hvm.spice.tls_port = l;
+        xlu_cfg_replace_string (config, "spicehost",
+                                &b_info->u.hvm.spice.host, 0);
         if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            dm_info->spice.disable_ticketing = l;
+            b_info->u.hvm.spice.disable_ticketing = l;
         xlu_cfg_replace_string (config, "spicepasswd",
-                                &dm_info->spice.passwd, 0);
+                                &b_info->u.hvm.spice.passwd, 0);
         if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            dm_info->spice.agent_mouse = l;
+            b_info->u.hvm.spice.agent_mouse = l;
         else
-            dm_info->spice.agent_mouse = 1;
+            b_info->u.hvm.spice.agent_mouse = 1;
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            dm_info->nographic = l;
+            b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT1-0000yX-DY; Mon, 16 Jan 2012 12:15:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSz-0000w0-TJ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25094 invoked from network); 16 Jan 2012 12:15:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671877"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:06 -0500
Received: from cosworth.uk.xensource.com (cosworth.uk.xensource.com
	[10.80.16.52])	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0GCF0cs032155;	Mon, 16 Jan 2012 04:15:05 -0800
MIME-Version: 1.0
X-Mercurial-Node: d5c8efa9ef9e55a08e06a6011681bdb827dd88c7
Message-ID: <d5c8efa9ef9e55a08e06.1326716102@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:02 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 32 RFC] ocaml: Correct ocaml type name for
 Aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326212349 0
# Node ID d5c8efa9ef9e55a08e06a6011681bdb827dd88c7
# Parent  07c4b8a8d50c8562472c8f6607ec145146c3828c
ocaml: Correct ocaml type name for Aggregate types.

No change to the generated code because this path isn't used yet.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 07c4b8a8d50c -r d5c8efa9ef9e tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Tue Jan 10 16:18:53 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Tue Jan 10 16:19:09 2012 +0000
@@ -59,6 +59,8 @@ def ocaml_type_of(ty):
         if not typename:
             raise NotImplementedError("No typename for Builtin %s (%s)" % (ty.typename, type(ty)))
         return typename
+    elif isinstance(ty,libxltypes.Aggregate):
+        return ty.rawname.capitalize() + ".t"
     else:
         return ty.rawname
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTB-0001A4-4E; Mon, 16 Jan 2012 12:15:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT9-00010O-He
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25524 invoked from network); 16 Jan 2012 12:15: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;
	16 Jan 2012 12:15:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671891"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:13 -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
	q0GCF0d2032155;	Mon, 16 Jan 2012 04:15:12 -0800
MIME-Version: 1.0
X-Mercurial-Node: 714cb45a8327bae6ede162f12e21cc8e0397ae1f
Message-ID: <714cb45a8327bae6ede1.1326716110@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 32 RFC] libxl: use vfb[0] directly for
	xenpv device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326363959 0
# Node ID 714cb45a8327bae6ede162f12e21cc8e0397ae1f
# Parent  3db40f3e8b2af814b9f79b514de82c3751c213f8
libxl: use vfb[0] directly for xenpv device model

Rather than laundering it via dm info.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 3db40f3e8b2a -r 714cb45a8327 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 17:58:32 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 10:25:59 2012 +0000
@@ -81,6 +81,30 @@ static const char *libxl__domain_bios(li
     }
 }
 
+static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config,
+                                    const libxl_device_model_info *info)
+{
+    const libxl_vnc_info *vnc = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        vnc = &info->vnc;
+    } else if (guest_config->num_vfbs > 0) {
+        vnc = &guest_config->vfbs[0].vnc;
+    }
+    return vnc && vnc->enable ? vnc : NULL;
+}
+
+static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config,
+                                    const libxl_device_model_info *info)
+{
+    const libxl_sdl_info *sdl = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        sdl = &info->sdl;
+    } else if (guest_config->num_vfbs > 0) {
+        sdl = &guest_config->vfbs[0].sdl;
+    }
+    return sdl && sdl->enable ? sdl : NULL;
+}
+
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -89,6 +113,8 @@ static char ** libxl__build_device_model
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     const int num_vifs = guest_config->num_vifs;
     int i;
     flexarray_t *dm_args;
@@ -103,45 +129,45 @@ static char ** libxl__build_device_model
     if (c_info->name)
         flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
 
-    if (info->vnc.enable) {
+    if (vnc) {
         char *vncarg;
-        if (info->vnc.display) {
-            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
+        if (vnc->display) {
+            if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
                 vncarg = libxl__sprintf(gc, "%s:%d",
-                                  info->vnc.listen,
-                                  info->vnc.display);
+                                  vnc->listen,
+                                  vnc->display);
             } else {
-                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vnc.display);
+                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", vnc->display);
             }
-        } else if (info->vnc.listen) {
-            if (strchr(info->vnc.listen, ':') != NULL) {
-                vncarg = info->vnc.listen;
+        } else if (vnc->listen) {
+            if (strchr(vnc->listen, ':') != NULL) {
+                vncarg = vnc->listen;
             } else {
-                vncarg = libxl__sprintf(gc, "%s:0", info->vnc.listen);
+                vncarg = libxl__sprintf(gc, "%s:0", vnc->listen);
             }
         } else {
             vncarg = "127.0.0.1:0";
         }
-        if (info->vnc.passwd && (info->vnc.passwd[0] != '\0'))
+        if (vnc->passwd && (vnc->passwd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (info->vnc.findunused) {
+        if (vnc->findunused) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
-    if (info->sdl.enable) {
+    if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!info->sdl.opengl) {
+        if (!sdl->opengl) {
             flexarray_append(dm_args, "-disable-opengl");
         }
-        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
+        /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
+    if (info->nographic && (!sdl && !vnc)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -254,6 +280,8 @@ static char ** libxl__build_device_model
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     flexarray_t *dm_args;
     int i;
 
@@ -281,36 +309,36 @@ static char ** libxl__build_device_model
     if (c_info->name) {
         flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
-    if (info->vnc.enable) {
+    if (vnc) {
         int display = 0;
         const char *listen = "127.0.0.1";
 
-        if (info->vnc.passwd && info->vnc.passwd[0]) {
+        if (vnc->passwd && vnc->passwd[0]) {
             assert(!"missing code for supplying vnc password to qemu");
         }
         flexarray_append(dm_args, "-vnc");
 
-        if (info->vnc.display) {
-            display = info->vnc.display;
-            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
-                listen = info->vnc.listen;
+        if (vnc->display) {
+            display = vnc->display;
+            if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
+                listen = vnc->listen;
             }
-        } else if (info->vnc.listen) {
-            listen = info->vnc.listen;
+        } else if (vnc->listen) {
+            listen = vnc->listen;
         }
 
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        info->vnc.findunused ? ",to=99" : ""));
+                        vnc->findunused ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vnc.findunused ? ",to=99" : ""));
+                        vnc->findunused ? ",to=99" : ""));
     }
-    if (info->sdl.enable) {
+    if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
+        /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->spice.enable) {
         char *spiceoptions = NULL;
@@ -357,7 +385,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
+    if (info->nographic && (!sdl && !vnc)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -805,8 +833,9 @@ int libxl__create_device_model(libxl__gc
                               libxl_device_model_info *info,
                               libxl__spawner_starting **starting_r)
 {
+    libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
@@ -875,7 +904,7 @@ int libxl__create_device_model(libxl__gc
         goto out_close;
     }
 
-    if (info->vnc.passwd) {
+    if (vnc && vnc->passwd) {
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
@@ -884,7 +913,7 @@ retry_transaction:
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
             pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = info->vnc.passwd;
+            pass_stuff[1] = vnc->passwd;
             libxl__xs_writev(gc,t,vm_path,pass_stuff);
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
@@ -993,22 +1022,8 @@ out:
 
 static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
                                         uint32_t domid,
-                                        libxl_device_vfb *vfb,
                                         libxl_device_model_info *info)
 {
-    if (vfb != NULL) {
-        info->vnc.enable = vfb->vnc.enable;
-        if (vfb->vnc.listen)
-            info->vnc.listen = libxl__strdup(gc, vfb->vnc.listen);
-        info->vnc.display = vfb->vnc.display;
-        info->vnc.findunused = vfb->vnc.findunused;
-        if (vfb->vnc.passwd)
-            info->vnc.passwd = vfb->vnc.passwd;
-        if (vfb->keymap)
-            info->keymap = libxl__strdup(gc, vfb->keymap);
-        info->sdl = vfb->sdl;
-    } else
-        info->nographic = 1;
     info->domid = domid;
     return 0;
 }
@@ -1055,7 +1070,7 @@ int libxl__create_xenpv_qemu(libxl__gc *
                              libxl_device_model_info *info,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, &guest_config->vfbs[0], info);
+    libxl__build_xenpv_qemu_args(gc, domid, info);
     libxl__create_device_model(gc, guest_config, info, starting_r);
     return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT4-00010Q-7y; Mon, 16 Jan 2012 12:15: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 1RmlT2-0000wT-Bn
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5242 invoked from network); 16 Jan 2012 12:15:09 -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;
	16 Jan 2012 12:15:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907087"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cv032155;	Mon, 16 Jan 2012 04:15:08 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2cf31bf780380c42d859bb0b8f7c701cbf424180
Message-ID: <2cf31bf780380c42d859.1326716105@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 32 RFC] libxl: define libxl_sdl_info to
 hold all info about the SDL config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326296553 0
# Node ID 2cf31bf780380c42d859bb0b8f7c701cbf424180
# Parent  3308d2dfd9dddb36f8a65e7a44916c6bcf02170e
libxl: define libxl_sdl_info to hold all info about the SDL config

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Jan 11 15:42:33 2012 +0000
@@ -1952,16 +1952,16 @@ out:
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->display = NULL;
-    vfb->xauthority = NULL;
     vfb->vnc.enable = 1;
     vfb->vnc.passwd = NULL;
     vfb->vnc.listen = strdup("127.0.0.1");
     vfb->vnc.display = 0;
     vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
-    vfb->sdl = 0;
-    vfb->opengl = 0;
+    vfb->sdl.enable = 0;
+    vfb->sdl.opengl = 0;
+    vfb->sdl.display = NULL;
+    vfb->sdl.xauthority = NULL;
     return 0;
 }
 
@@ -2012,16 +2012,19 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
                           libxl__sprintf(gc, "%d", vfb->vnc.findunused));
-    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);
+    flexarray_append_pair(back, "sdl",
+                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+    flexarray_append_pair(back, "opengl",
+                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+    if (vfb->sdl.xauthority) {
+        flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
-    if (vfb->display) {
-        flexarray_append_pair(back, "display", vfb->display);
+    if (vfb->sdl.display) {
+        flexarray_append_pair(back, "display", vfb->sdl.display);
     }
 
-    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
+    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,
diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 15:42:33 2012 +0000
@@ -137,8 +137,8 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->vnc.display = 0;
     dm_info->vnc.findunused = 1;
     dm_info->keymap = NULL;
-    dm_info->sdl = 0;
-    dm_info->opengl = 0;
+    dm_info->sdl.enable = 0;
+    dm_info->sdl.opengl = 0;
     dm_info->nographic = 0;
     dm_info->serial = NULL;
     dm_info->boot = strdup("cda");
diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 15:42:33 2012 +0000
@@ -128,16 +128,17 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-vncunused");
         }
     }
-    if (info->sdl) {
+    if (info->sdl.enable) {
         flexarray_append(dm_args, "-sdl");
-        if (!info->opengl) {
+        if (!info->sdl.opengl) {
             flexarray_append(dm_args, "-disable-opengl");
         }
+        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
+    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -295,8 +296,9 @@ static char ** libxl__build_device_model
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
                         info->vnc.findunused ? ",to=99" : ""));
     }
-    if (info->sdl) {
+    if (info->sdl.enable) {
         flexarray_append(dm_args, "-sdl");
+        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->spice.enable) {
         char *spiceoptions = NULL;
@@ -343,7 +345,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
+    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -534,7 +536,6 @@ static int libxl__vfb_and_vkb_from_devic
     vfb->vnc = info->vnc;
     vfb->keymap = info->keymap;
     vfb->sdl = info->sdl;
-    vfb->opengl = info->opengl;
 
     vkb->backend_domid = 0;
     vkb->devid = 0;
@@ -991,7 +992,6 @@ static int libxl__build_xenpv_qemu_args(
         if (vfb->keymap)
             info->keymap = libxl__strdup(gc, vfb->keymap);
         info->sdl = vfb->sdl;
-        info->opengl = vfb->opengl;
     } else
         info->nographic = 1;
     info->domid = domid;
diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 11 15:42:33 2012 +0000
@@ -255,8 +255,7 @@ libxl_device_model_info = Struct("device
     ("vnc",              libxl_vnc_info),
     # keyboard layout, default is en-us keyboard
     ("keymap",           string),
-    ("sdl",              bool),
-    ("opengl",           bool), # (requires sdl enabled)
+    ("sdl",              libxl_sdl_info),
     ("spice",            libxl_spice_info),
     ("nographic",        bool),
     ("gfx_passthru",     bool),
@@ -283,12 +282,9 @@ libxl_device_vfb = Struct("device_vfb", 
     ("backend_domid", libxl_domid),
     ("devid",         integer),
     ("vnc",           libxl_vnc_info),
+    ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
     ("keymap",        string),
-    ("sdl",           bool),
-    ("opengl",        bool), # (if enabled requires sdl enabled)
-    ("display",       string),
-    ("xauthority",    string),
     ])
 
 libxl_device_vkb = Struct("device_vkb", [
diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 15:42:33 2012 +0000
@@ -369,9 +369,9 @@ static void printf_info(int domid,
         printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
         printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
         printf("\t\t\t(keymap %s)\n", dm_info->keymap);
-        printf("\t\t\t(sdl %d)\n", dm_info->sdl);
+        printf("\t\t\t(sdl %d)\n", dm_info->sdl.enable);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(opengl %d)\n", dm_info->opengl);
+        printf("\t\t\t(opengl %d)\n", dm_info->sdl.opengl);
         printf("\t\t\t(nographic %d)\n", dm_info->nographic);
         printf("\t\t\t(serial %s)\n", dm_info->serial);
         printf("\t\t\t(boot %s)\n", dm_info->boot);
@@ -459,10 +459,10 @@ static void printf_info(int domid,
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
         printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].opengl);
-        printf("\t\t\t(display %s)\n", d_config->vfbs[i].display);
-        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].xauthority);
+        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
+        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
+        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");
         printf("\t)\n");
     }
@@ -976,15 +976,15 @@ skip:
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl = atoi(p2 + 1);
+                    vfb->sdl.enable = atoi(p2 + 1);
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->opengl = atoi(p2 + 1);
+                    vfb->sdl.opengl = atoi(p2 + 1);
                 } else if (!strcmp(p, "display")) {
-                    free(vfb->display);
-                    vfb->display = strdup(p2 + 1);
+                    free(vfb->sdl.display);
+                    vfb->sdl.display = strdup(p2 + 1);
                 } else if (!strcmp(p, "xauthority")) {
-                    free(vfb->xauthority);
-                    vfb->xauthority = strdup(p2 + 1);
+                    free(vfb->sdl.xauthority);
+                    vfb->sdl.xauthority = strdup(p2 + 1);
                 }
             } while ((p = strtok(NULL, ",")) != NULL);
 skip_vfb:
@@ -1187,9 +1187,9 @@ skip_vfb:
             dm_info->vnc.findunused = l;
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            dm_info->sdl = l;
+            dm_info->sdl.enable = l;
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            dm_info->opengl = l;
+            dm_info->sdl.opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT7-000146-GI; Mon, 16 Jan 2012 12:15:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT5-0000xw-TX
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5433 invoked from network); 16 Jan 2012 12:15:13 -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;
	16 Jan 2012 12:15:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907090"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0d1032155;	Mon, 16 Jan 2012 04:15:11 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3db40f3e8b2af814b9f79b514de82c3751c213f8
Message-ID: <3db40f3e8b2af814b9f7.1326716109@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 32 RFC] libxl: drop dm_info.dom_name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326304712 0
# Node ID 3db40f3e8b2af814b9f79b514de82c3751c213f8
# Parent  a27ac2ae9cefc42e3eee504cb2805824fd80d3f8
libxl: drop dm_info.dom_name

This is always the same as the c_info name which we now have available.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a27ac2ae9cef -r 3db40f3e8b2a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 17:50:21 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:58:32 2012 +0000
@@ -121,7 +121,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 
     libxl_uuid_generate(&dm_info->uuid);
 
-    dm_info->dom_name = strdup(c_info->name);
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
diff -r a27ac2ae9cef -r 3db40f3e8b2a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 17:50:21 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 17:58:32 2012 +0000
@@ -86,6 +86,7 @@ static char ** libxl__build_device_model
                                         const libxl_domain_config *guest_config,
                                         const libxl_device_model_info *info)
 {
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_vifs = guest_config->num_vifs;
@@ -99,8 +100,8 @@ static char ** libxl__build_device_model
     flexarray_vappend(dm_args, dm,
                       "-d", libxl__sprintf(gc, "%d", info->domid), NULL);
 
-    if (info->dom_name)
-        flexarray_vappend(dm_args, "-domain-name", info->dom_name, NULL);
+    if (c_info->name)
+        flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
 
     if (info->vnc.enable) {
         char *vncarg;
@@ -247,6 +248,7 @@ static char ** libxl__build_device_model
                                         const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_disk *disks = guest_config->disks;
     const libxl_device_nic *vifs = guest_config->vifs;
@@ -276,8 +278,8 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-xen-attach");
     }
 
-    if (info->dom_name) {
-        flexarray_vappend(dm_args, "-name", info->dom_name, NULL);
+    if (c_info->name) {
+        flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
     if (info->vnc.enable) {
         int display = 0;
@@ -803,6 +805,7 @@ int libxl__create_device_model(libxl__gc
                               libxl_device_model_info *info,
                               libxl__spawner_starting **starting_r)
 {
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path, *logfile;
     int logfile_w, null;
@@ -845,7 +848,9 @@ int libxl__create_device_model(libxl__gc
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
 
-    libxl_create_logfile(ctx, libxl__sprintf(gc, "qemu-dm-%s", info->dom_name), &logfile);
+    libxl_create_logfile(ctx,
+                         libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
+                         &logfile);
     logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
     free(logfile);
     null = open("/dev/null", O_RDONLY);
@@ -991,8 +996,6 @@ static int libxl__build_xenpv_qemu_args(
                                         libxl_device_vfb *vfb,
                                         libxl_device_model_info *info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-
     if (vfb != NULL) {
         info->vnc.enable = vfb->vnc.enable;
         if (vfb->vnc.listen)
@@ -1007,7 +1010,6 @@ static int libxl__build_xenpv_qemu_args(
     } else
         info->nographic = 1;
     info->domid = domid;
-    info->dom_name = libxl_domid_to_name(ctx, domid);
     return 0;
 }
 
diff -r a27ac2ae9cef -r 3db40f3e8b2a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 11 17:50:21 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 11 17:58:32 2012 +0000
@@ -241,7 +241,6 @@ libxl_device_model_info = Struct("device
     # uuid is used only with stubdom, and must be different from the
     # domain uuid
     ("uuid",             libxl_uuid),
-    ("dom_name",         string),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTA-00018k-9O; Mon, 16 Jan 2012 12:15:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT8-0000zW-6i
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5555 invoked from network); 16 Jan 2012 12:15:15 -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;
	16 Jan 2012 12:15:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907091"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:14 -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
	q0GCF0d3032155;	Mon, 16 Jan 2012 04:15:13 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0ef52f0b6c58344ee371d668ea343628aaecb714
Message-ID: <0ef52f0b6c58344ee371.1326716111@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 32 RFC] libxl: move HVM emulated GFX
 support into b_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326367192 0
# Node ID 0ef52f0b6c58344ee371d668ea343628aaecb714
# Parent  714cb45a8327bae6ede162f12e21cc8e0397ae1f
libxl: move HVM emulated GFX support into b_info->u.hvm

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 714cb45a8327 -r 0ef52f0b6c58 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 10:25:59 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 11:19:52 2012 +0000
@@ -99,6 +99,16 @@ 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.stdvga = 0;
+        b_info->u.hvm.vnc.enable = 1;
+        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
+        b_info->u.hvm.vnc.display = 0;
+        b_info->u.hvm.vnc.findunused = 1;
+        b_info->u.hvm.keymap = NULL;
+        b_info->u.hvm.sdl.enable = 0;
+        b_info->u.hvm.sdl.opengl = 0;
+        b_info->u.hvm.nographic = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -124,17 +134,7 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
-    dm_info->videoram = libxl__sizekb_to_mb(b_info->video_memkb);
 
-    dm_info->stdvga = 0;
-    dm_info->vnc.enable = 1;
-    dm_info->vnc.listen = strdup("127.0.0.1");
-    dm_info->vnc.display = 0;
-    dm_info->vnc.findunused = 1;
-    dm_info->keymap = NULL;
-    dm_info->sdl.enable = 0;
-    dm_info->sdl.opengl = 0;
-    dm_info->nographic = 0;
     dm_info->serial = NULL;
     dm_info->boot = strdup("cda");
     dm_info->usb = 0;
diff -r 714cb45a8327 -r 0ef52f0b6c58 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 10:25:59 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 11:19:52 2012 +0000
@@ -86,7 +86,7 @@ static const libxl_vnc_info *dm_vnc(cons
 {
     const libxl_vnc_info *vnc = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        vnc = &info->vnc;
+        vnc = &guest_config->b_info.u.hvm.vnc;
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
@@ -98,13 +98,24 @@ static const libxl_sdl_info *dm_sdl(cons
 {
     const libxl_sdl_info *sdl = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        sdl = &info->sdl;
+        sdl = &guest_config->b_info.u.hvm.sdl;
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
     return sdl && sdl->enable ? sdl : NULL;
 }
 
+static const char *dm_keymap(const libxl_domain_config *guest_config,
+                             const libxl_device_model_info *info)
+{
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        return guest_config->b_info.u.hvm.keymap;
+    } else if (guest_config->num_vfbs > 0) {
+        return guest_config->vfbs[0].keymap;
+    } else
+        return NULL;
+}
+
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -116,6 +127,7 @@ static char ** libxl__build_device_model
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     const int num_vifs = guest_config->num_vifs;
+    const char *keymap = dm_keymap(guest_config, info);
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -164,11 +176,8 @@ static char ** libxl__build_device_model
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
-    if (info->keymap) {
-        flexarray_vappend(dm_args, "-k", info->keymap, NULL);
-    }
-    if (info->nographic && (!sdl && !vnc)) {
-        flexarray_append(dm_args, "-nographic");
+    if (keymap) {
+        flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
     if (info->serial) {
         flexarray_vappend(dm_args, "-serial", info->serial, NULL);
@@ -176,10 +185,17 @@ static char ** libxl__build_device_model
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
-        if (info->videoram) {
-            flexarray_vappend(dm_args, "-videoram", libxl__sprintf(gc, "%d", info->videoram), NULL);
+        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+            flexarray_append(dm_args, "-nographic");
         }
-        if (info->stdvga) {
+
+        if (b_info->video_memkb) {
+            flexarray_vappend(dm_args, "-videoram",
+                    libxl__sprintf(gc, "%d",
+                                   libxl__sizekb_to_mb(b_info->video_memkb)),
+                    NULL);
+        }
+        if (b_info->u.hvm.stdvga) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -233,7 +249,11 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+    } else {
+        if (!sdl && !vnc)
+            flexarray_append(dm_args, "-nographic");
     }
+
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
     }
@@ -268,6 +288,42 @@ static const char *qemu_disk_format_stri
     }
 }
 
+static char *dm_spice_options(libxl__gc *gc,
+                                    const libxl_spice_info *spice)
+{
+    char *opt;
+
+    if (!spice->port && !spice->tls_port) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "at least one of the spiceport or tls_port must be provided");
+        return NULL;
+    }
+
+    if (!spice->disable_ticketing) {
+        if (!spice->passwd) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "spice ticketing is enabled but missing password");
+            return NULL;
+        }
+        else if (!spice->passwd[0]) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                               "spice password can't be empty");
+            return NULL;
+        }
+    }
+    opt = libxl__sprintf(gc, "port=%d,tls-port=%d",
+                         spice->port, spice->tls_port);
+    if (spice->host)
+        opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
+    if (spice->disable_ticketing)
+        opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
+    else
+        opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
+    opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
+                         spice->agent_mouse ? "on" : "off");
+    return opt;
+}
+
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -282,6 +338,7 @@ static char ** libxl__build_device_model
     const int num_vifs = guest_config->num_vifs;
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
+    const char *keymap = dm_keymap(guest_config, info);
     flexarray_t *dm_args;
     int i;
 
@@ -340,61 +397,36 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-sdl");
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
-    if (info->spice.enable) {
-        char *spiceoptions = NULL;
-        if (!info->spice.port && !info->spice.tls_port) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                "at least one of the spiceport or tls_port must be provided");
-            return NULL;
-        }
 
-        if (!info->spice.disable_ticketing) {
-            if (!info->spice.passwd) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                    "spice ticketing is enabled but missing password");
-                return NULL;
-            }
-            else if (!info->spice.passwd[0]) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                    "spice password can't be empty");
-                return NULL;
-            }
-        }
-        spiceoptions = libxl__sprintf(gc, "port=%d,tls-port=%d",
-                                      info->spice.port, info->spice.tls_port);
-        if (info->spice.host)
-            spiceoptions = libxl__sprintf(gc,
-                    "%s,addr=%s", spiceoptions, info->spice.host);
-        if (info->spice.disable_ticketing)
-            spiceoptions = libxl__sprintf(gc, "%s,disable-ticketing",
-                                               spiceoptions);
-        else
-            spiceoptions = libxl__sprintf(gc,
-                    "%s,password=%s", spiceoptions, info->spice.passwd);
-        spiceoptions = libxl__sprintf(gc, "%s,agent-mouse=%s", spiceoptions,
-                                      info->spice.agent_mouse ? "on" : "off");
+    /*if (info->type == LIBXL_DOMAIN_TYPE_PV && !b_info->nographic) {
+        flexarray_vappend(dm_args, "-vga", "xenfb", NULL);
+      } never was possible?*/
 
-        flexarray_append(dm_args, "-spice");
-        flexarray_append(dm_args, spiceoptions);
+    if (keymap) {
+        flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->type == LIBXL_DOMAIN_TYPE_PV && !info->nographic) {
-        flexarray_vappend(dm_args, "-vga", "xenfb", NULL);
-    }
-
-    if (info->keymap) {
-        flexarray_vappend(dm_args, "-k", info->keymap, NULL);
-    }
-    if (info->nographic && (!sdl && !vnc)) {
-        flexarray_append(dm_args, "-nographic");
-    }
     if (info->serial) {
         flexarray_vappend(dm_args, "-serial", info->serial, NULL);
     }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
-        if (info->stdvga) {
+        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+            flexarray_append(dm_args, "-nographic");
+        }
+
+        if (b_info->u.hvm.spice.enable) {
+            const libxl_spice_info *spice = &b_info->u.hvm.spice;
+            char *spiceoptions = dm_spice_options(gc, spice);
+            if (!spiceoptions)
+                return NULL;
+
+            flexarray_append(dm_args, "-spice");
+            flexarray_append(dm_args, spiceoptions);
+        }
+
+        if (b_info->u.hvm.stdvga) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -454,7 +486,12 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+    } else {
+        if (!sdl && !vnc) {
+            flexarray_append(dm_args, "-nographic");
+        }
     }
+
     if (info->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
         int migration_fd = open(info->saved_state, O_RDONLY);
@@ -563,19 +600,24 @@ static char ** libxl__build_device_model
     }
 }
 
-static int libxl__vfb_and_vkb_from_device_model_info(libxl__gc *gc,
-                                        const libxl_device_model_info *info,
+static int libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc *gc,
+                                        const libxl_domain_config *guest_config,
                                         libxl_device_vfb *vfb,
                                         libxl_device_vkb *vkb)
 {
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
+
+    if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
-    vfb->vnc = info->vnc;
-    vfb->keymap = info->keymap;
-    vfb->sdl = info->sdl;
+    vfb->vnc = b_info->u.hvm.vnc;
+    vfb->keymap = b_info->u.hvm.keymap;
+    vfb->sdl = b_info->u.hvm.sdl;
 
     vkb->backend_domid = 0;
     vkb->devid = 0;
@@ -678,8 +720,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
-    libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-
+    libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
     dm_config.vkbs = &vkb;
diff -r 714cb45a8327 -r 0ef52f0b6c58 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 10:25:59 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 11:19:52 2012 +0000
@@ -219,6 +219,13 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align", bool),
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
+                                       ("nographic",        bool),
+                                       ("stdvga",           bool),
+                                       ("vnc",              libxl_vnc_info),
+                                       # keyboard layout, default is en-us keyboard
+                                       ("keymap",           string),
+                                       ("sdl",              libxl_sdl_info),
+                                       ("spice",            libxl_spice_info),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -247,15 +254,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    # size of the videoram in MB
-    ("videoram",         integer), 
-    ("stdvga",           bool),
-    ("vnc",              libxl_vnc_info),
-    # keyboard layout, default is en-us keyboard
-    ("keymap",           string),
-    ("sdl",              libxl_sdl_info),
-    ("spice",            libxl_spice_info),
-    ("nographic",        bool),
     ("gfx_passthru",     bool),
     ("serial",           string),
     ("boot",             string),
diff -r 714cb45a8327 -r 0ef52f0b6c58 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 10:25:59 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:19:52 2012 +0000
@@ -361,29 +361,29 @@ static void printf_info(int domid,
         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(stdvga %d)\n", b_info->u.hvm.stdvga);
+        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
+        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
+        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
+        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
+        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
+        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
+        printf("\t\t\t(spicedisable_ticketing %d)\n",
+                    b_info->u.hvm.spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
-        printf("\t\t\t(videoram %d)\n", dm_info->videoram);
-        printf("\t\t\t(stdvga %d)\n", dm_info->stdvga);
-        printf("\t\t\t(vnc %d)\n", dm_info->vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", dm_info->vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
-        printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", dm_info->keymap);
-        printf("\t\t\t(sdl %d)\n", dm_info->sdl.enable);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(opengl %d)\n", dm_info->sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", dm_info->nographic);
         printf("\t\t\t(serial %s)\n", dm_info->serial);
         printf("\t\t\t(boot %s)\n", dm_info->boot);
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
-        printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
-        printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
-        printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);
-        printf("\t\t\t(spicehost %s)\n", dm_info->spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    dm_info->spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spice.agent_mouse);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1175,37 +1175,38 @@ skip_vfb:
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            dm_info->stdvga = l;
+            b_info->u.hvm.stdvga = l;
         if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            dm_info->vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vnc.passwd, 0);
+            b_info->u.hvm.vnc.enable = l;
+        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
-            dm_info->vnc.display = l;
+            b_info->u.hvm.vnc.display = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            dm_info->vnc.findunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            dm_info->sdl.enable = l;
+            b_info->u.hvm.sdl.enable = l;
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            dm_info->sdl.opengl = l;
+            b_info->u.hvm.sdl.opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            dm_info->spice.enable = l;
+            b_info->u.hvm.spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
-            dm_info->spice.port = l;
+            b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
-            dm_info->spice.tls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spice.host, 0);
+            b_info->u.hvm.spice.tls_port = l;
+        xlu_cfg_replace_string (config, "spicehost",
+                                &b_info->u.hvm.spice.host, 0);
         if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            dm_info->spice.disable_ticketing = l;
+            b_info->u.hvm.spice.disable_ticketing = l;
         xlu_cfg_replace_string (config, "spicepasswd",
-                                &dm_info->spice.passwd, 0);
+                                &b_info->u.hvm.spice.passwd, 0);
         if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            dm_info->spice.agent_mouse = l;
+            b_info->u.hvm.spice.agent_mouse = l;
         else
-            dm_info->spice.agent_mouse = 1;
+            b_info->u.hvm.spice.agent_mouse = 1;
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            dm_info->nographic = l;
+            b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT6-000132-NC; Mon, 16 Jan 2012 12:15:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT5-0000xV-4n
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25429 invoked from network); 16 Jan 2012 12:15:12 -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;
	16 Jan 2012 12:15:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671887"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0d0032155;	Mon, 16 Jan 2012 04:15:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: a27ac2ae9cefc42e3eee504cb2805824fd80d3f8
Message-ID: <a27ac2ae9cefc42e3eee.1326716108@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 32 RFC] libxl: remove redundant info from
	dm info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326304221 0
# Node ID a27ac2ae9cefc42e3eee504cb2805824fd80d3f8
# Parent  9f9995e2e34967929053c8c75e7c86562b58acf9
libxl: remove redundant info from dm info.

Remove "target_ram", "acpi", "vcpus" and "vcpu_avail" from device model info
and use domain_build_info instead. These must all be consistently specified to
both the domain and the device model, there is no need (and a great deal of
danger) in exposing a way for a user of libxl to set them differently.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9f9995e2e349 -r a27ac2ae9cef tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 17:45:38 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:50:21 2012 +0000
@@ -125,11 +125,7 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
-    dm_info->target_ram = libxl__sizekb_to_mb(b_info->target_memkb);
     dm_info->videoram = libxl__sizekb_to_mb(b_info->video_memkb);
-    dm_info->acpi = b_info->u.hvm.acpi;
-    dm_info->vcpus = b_info->max_vcpus;
-    dm_info->vcpu_avail = b_info->cur_vcpus;
 
     dm_info->stdvga = 0;
     dm_info->vnc.enable = 1;
diff -r 9f9995e2e349 -r a27ac2ae9cef tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 17:45:38 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 17:50:21 2012 +0000
@@ -86,6 +86,7 @@ static char ** libxl__build_device_model
                                         const libxl_domain_config *guest_config,
                                         const libxl_device_model_info *info)
 {
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_vifs = guest_config->num_vifs;
     int i;
@@ -167,14 +168,18 @@ static char ** libxl__build_device_model
         if (info->soundhw) {
             flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
         }
-        if (info->acpi) {
+        if (b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-acpi");
         }
-        if (info->vcpus > 1) {
-            flexarray_vappend(dm_args, "-vcpus", libxl__sprintf(gc, "%d", info->vcpus), NULL);
+        if (b_info->max_vcpus > 1) {
+            flexarray_vappend(dm_args, "-vcpus",
+                              libxl__sprintf(gc, "%d", b_info->max_vcpus),
+                              NULL);
         }
-        if (info->vcpu_avail) {
-            flexarray_vappend(dm_args, "-vcpu_avail", libxl__sprintf(gc, "0x%x", info->vcpu_avail), NULL);
+        if (b_info->cur_vcpus) {
+            flexarray_vappend(dm_args, "-vcpu_avail",
+                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
+                              NULL);
         }
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
@@ -242,6 +247,7 @@ static char ** libxl__build_device_model
                                         const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_disk *disks = guest_config->disks;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
@@ -374,15 +380,18 @@ static char ** libxl__build_device_model
         if (info->soundhw) {
             flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
         }
-        if (!info->acpi) {
+        if (!b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-no-acpi");
         }
-        if (info->vcpus > 1) {
+        if (b_info->max_vcpus > 1) {
             flexarray_append(dm_args, "-smp");
-            if (info->vcpu_avail)
-                flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d", info->vcpus, info->vcpu_avail));
+            if (b_info->cur_vcpus)
+                flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d",
+                                                         b_info->max_vcpus,
+                                                         b_info->cur_vcpus));
             else
-                flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->vcpus));
+                flexarray_append(dm_args, libxl__sprintf(gc, "%d",
+                                                         b_info->max_vcpus));
         }
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
@@ -440,7 +449,9 @@ static char ** libxl__build_device_model
 
     /* RAM Size */
     flexarray_append(dm_args, "-m");
-    flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->target_ram));
+    flexarray_append(dm_args,
+                     libxl__sprintf(gc, "%d",
+                                    libxl__sizekb_to_mb(b_info->target_memkb)));
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         for (i = 0; i < num_disks; i++) {
diff -r 9f9995e2e349 -r a27ac2ae9cef tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 11 17:45:38 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 11 17:50:21 2012 +0000
@@ -248,7 +248,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    ("target_ram",       uint32),
     # size of the videoram in MB
     ("videoram",         integer), 
     ("stdvga",           bool),
@@ -265,9 +264,6 @@ libxl_device_model_info = Struct("device
     # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
     ("usbdevice",        string),
     ("soundhw",          string),
-    ("acpi",             bool),
-    ("vcpus",            integer), # max number of vcpus
-    ("vcpu_avail",       integer), # vcpus actually available
     ("xen_platform_pci", bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
diff -r 9f9995e2e349 -r a27ac2ae9cef tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:45:38 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:50:21 2012 +0000
@@ -377,7 +377,6 @@ static void printf_info(int domid,
         printf("\t\t\t(boot %s)\n", dm_info->boot);
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
-        printf("\t\t\t(acpi %d)\n", dm_info->acpi);
         printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
         printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
         printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT0-0000xs-DN; Mon, 16 Jan 2012 12:15:14 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlSy-0000vY-75
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4990 invoked from network); 16 Jan 2012 12:15:06 -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;
	16 Jan 2012 12:15:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907085"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:05 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cr032155;	Mon, 16 Jan 2012 04:15:04 -0800
MIME-Version: 1.0
X-Mercurial-Node: 07c4b8a8d50c8562472c8f6607ec145146c3828c
Message-ID: <07c4b8a8d50c8562472c.1326716101@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:01 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 32 RFC] ocaml: use libxl IDL type helpers
 for C argument passing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326212333 0
# Node ID 07c4b8a8d50c8562472c8f6607ec145146c3828c
# Parent  cf86bcb7c89568a2c60f246d0e2443acb756e1c1
ocaml: use libxl IDL type helpers for C argument passing

Makes handling of nested structs more correct.

Only change to the generated code right now is that the FOO_Val
(C->ocamlC) function for Enumeration types now takes the C argument by
value instead of reference.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r cf86bcb7c895 -r 07c4b8a8d50c tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Tue Jan 10 10:15:42 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Tue Jan 10 16:18:53 2012 +0000
@@ -110,11 +110,6 @@ def gen_ocaml_ml(ty, interface, indent="
     return s.replace("\n", "\n%s" % indent)
 
 def c_val(ty, c, o, indent="", parent = None):
-    if ty.passby == libxltypes.PASS_BY_REFERENCE:
-        makeref = ""
-    else:
-        makeref = "&"
-
     s = indent
     if isinstance(ty,libxltypes.UInt):
         if ty.width in [8, 16]:
@@ -146,17 +141,18 @@ def c_val(ty, c, o, indent="", parent = 
     elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
-            s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
+            (nparent,fexpr) = ty.member(c, f, parent is None)
+            s += "%s\n" % c_val(f.type, fexpr, "Field(%s, %d)" % (o,n), parent=nparent)
             n = n + 1
     else:
-        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, makeref + c, o)
+        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, ty.pass_arg(c, parent is None, passby=libxltypes.PASS_BY_REFERENCE), o)
     
     return s.replace("\n", "\n%s" % indent)
 
 def gen_c_val(ty, indent=""):
     s = "/* Convert caml value to %s */\n" % ty.rawname
     
-    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s *c_val, value v)\n" % (ty.rawname, ty.typename)
+    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s, value v)\n" % (ty.rawname, ty.make_arg("c_val", passby=libxltypes.PASS_BY_REFERENCE))
     s += "{\n"
     s += "\tCAMLparam1(v);\n"
     s += "\n"
@@ -169,11 +165,6 @@ def gen_c_val(ty, indent=""):
     return s.replace("\n", "\n%s" % indent)
 
 def ocaml_Val(ty, o, c, indent="", parent = None):
-    if ty.passby == libxltypes.PASS_BY_REFERENCE:
-        makeref = ""
-    else:
-        makeref = "&"
-    
     s = indent
     if isinstance(ty,libxltypes.UInt):
         if ty.width in [8, 16]:
@@ -196,7 +187,7 @@ def ocaml_Val(ty, o, c, indent="", paren
         s += "%s = %s;" % (o, fn % { "c": c })
     elif isinstance(ty,libxltypes.Enumeration) and (parent is None):
         n = 0
-        s += "switch(*%s) {\n" % c
+        s += "switch(%s) {\n" % c
         for e in ty.values:
             s += "    case %s: %s = Int_val(%d); break;\n" % (e.name, o, n)
             n += 1
@@ -210,20 +201,22 @@ def ocaml_Val(ty, o, c, indent="", paren
         
         n = 0
         for f in ty.fields:
+            (nparent,fexpr) = ty.member(c, f, parent is None)
+
             s += "\n"
-            s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
+            s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, ty.pass_arg(fexpr, c), parent=nparent)
             s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
             n = n + 1
         s += "}"
     else:
-        s += "%s = Val_%s(gc, lg, %s);" % (o, ty.rawname, makeref + c)
+        s += "%s = Val_%s(gc, lg, %s);" % (o, ty.rawname, ty.pass_arg(c, parent is None))
     
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
 def gen_Val_ocaml(ty, indent=""):
     s = "/* Convert %s to a caml value */\n" % ty.rawname
 
-    s += "static value Val_%s (caml_gc *gc, struct caml_logger *lg, %s *%s_c)\n" % (ty.rawname, ty.typename, ty.rawname)
+    s += "static value Val_%s (caml_gc *gc, struct caml_logger *lg, %s)\n" % (ty.rawname, ty.make_arg(ty.rawname+"_c"))
     s += "{\n"
     s += "\tCAMLparam0();\n"
     s += "\tCAMLlocal1(%s_ocaml);\n" % ty.rawname

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTB-0001A4-4E; Mon, 16 Jan 2012 12:15:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT9-00010O-He
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25524 invoked from network); 16 Jan 2012 12:15: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;
	16 Jan 2012 12:15:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671891"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:13 -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
	q0GCF0d2032155;	Mon, 16 Jan 2012 04:15:12 -0800
MIME-Version: 1.0
X-Mercurial-Node: 714cb45a8327bae6ede162f12e21cc8e0397ae1f
Message-ID: <714cb45a8327bae6ede1.1326716110@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 32 RFC] libxl: use vfb[0] directly for
	xenpv device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326363959 0
# Node ID 714cb45a8327bae6ede162f12e21cc8e0397ae1f
# Parent  3db40f3e8b2af814b9f79b514de82c3751c213f8
libxl: use vfb[0] directly for xenpv device model

Rather than laundering it via dm info.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 3db40f3e8b2a -r 714cb45a8327 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 17:58:32 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 10:25:59 2012 +0000
@@ -81,6 +81,30 @@ static const char *libxl__domain_bios(li
     }
 }
 
+static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config,
+                                    const libxl_device_model_info *info)
+{
+    const libxl_vnc_info *vnc = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        vnc = &info->vnc;
+    } else if (guest_config->num_vfbs > 0) {
+        vnc = &guest_config->vfbs[0].vnc;
+    }
+    return vnc && vnc->enable ? vnc : NULL;
+}
+
+static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config,
+                                    const libxl_device_model_info *info)
+{
+    const libxl_sdl_info *sdl = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        sdl = &info->sdl;
+    } else if (guest_config->num_vfbs > 0) {
+        sdl = &guest_config->vfbs[0].sdl;
+    }
+    return sdl && sdl->enable ? sdl : NULL;
+}
+
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -89,6 +113,8 @@ static char ** libxl__build_device_model
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     const int num_vifs = guest_config->num_vifs;
     int i;
     flexarray_t *dm_args;
@@ -103,45 +129,45 @@ static char ** libxl__build_device_model
     if (c_info->name)
         flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
 
-    if (info->vnc.enable) {
+    if (vnc) {
         char *vncarg;
-        if (info->vnc.display) {
-            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
+        if (vnc->display) {
+            if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
                 vncarg = libxl__sprintf(gc, "%s:%d",
-                                  info->vnc.listen,
-                                  info->vnc.display);
+                                  vnc->listen,
+                                  vnc->display);
             } else {
-                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vnc.display);
+                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", vnc->display);
             }
-        } else if (info->vnc.listen) {
-            if (strchr(info->vnc.listen, ':') != NULL) {
-                vncarg = info->vnc.listen;
+        } else if (vnc->listen) {
+            if (strchr(vnc->listen, ':') != NULL) {
+                vncarg = vnc->listen;
             } else {
-                vncarg = libxl__sprintf(gc, "%s:0", info->vnc.listen);
+                vncarg = libxl__sprintf(gc, "%s:0", vnc->listen);
             }
         } else {
             vncarg = "127.0.0.1:0";
         }
-        if (info->vnc.passwd && (info->vnc.passwd[0] != '\0'))
+        if (vnc->passwd && (vnc->passwd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (info->vnc.findunused) {
+        if (vnc->findunused) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
-    if (info->sdl.enable) {
+    if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!info->sdl.opengl) {
+        if (!sdl->opengl) {
             flexarray_append(dm_args, "-disable-opengl");
         }
-        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
+        /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
+    if (info->nographic && (!sdl && !vnc)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -254,6 +280,8 @@ static char ** libxl__build_device_model
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     flexarray_t *dm_args;
     int i;
 
@@ -281,36 +309,36 @@ static char ** libxl__build_device_model
     if (c_info->name) {
         flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
-    if (info->vnc.enable) {
+    if (vnc) {
         int display = 0;
         const char *listen = "127.0.0.1";
 
-        if (info->vnc.passwd && info->vnc.passwd[0]) {
+        if (vnc->passwd && vnc->passwd[0]) {
             assert(!"missing code for supplying vnc password to qemu");
         }
         flexarray_append(dm_args, "-vnc");
 
-        if (info->vnc.display) {
-            display = info->vnc.display;
-            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
-                listen = info->vnc.listen;
+        if (vnc->display) {
+            display = vnc->display;
+            if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
+                listen = vnc->listen;
             }
-        } else if (info->vnc.listen) {
-            listen = info->vnc.listen;
+        } else if (vnc->listen) {
+            listen = vnc->listen;
         }
 
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        info->vnc.findunused ? ",to=99" : ""));
+                        vnc->findunused ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vnc.findunused ? ",to=99" : ""));
+                        vnc->findunused ? ",to=99" : ""));
     }
-    if (info->sdl.enable) {
+    if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
+        /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->spice.enable) {
         char *spiceoptions = NULL;
@@ -357,7 +385,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
+    if (info->nographic && (!sdl && !vnc)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -805,8 +833,9 @@ int libxl__create_device_model(libxl__gc
                               libxl_device_model_info *info,
                               libxl__spawner_starting **starting_r)
 {
+    libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
@@ -875,7 +904,7 @@ int libxl__create_device_model(libxl__gc
         goto out_close;
     }
 
-    if (info->vnc.passwd) {
+    if (vnc && vnc->passwd) {
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
@@ -884,7 +913,7 @@ retry_transaction:
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
             pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = info->vnc.passwd;
+            pass_stuff[1] = vnc->passwd;
             libxl__xs_writev(gc,t,vm_path,pass_stuff);
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
@@ -993,22 +1022,8 @@ out:
 
 static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
                                         uint32_t domid,
-                                        libxl_device_vfb *vfb,
                                         libxl_device_model_info *info)
 {
-    if (vfb != NULL) {
-        info->vnc.enable = vfb->vnc.enable;
-        if (vfb->vnc.listen)
-            info->vnc.listen = libxl__strdup(gc, vfb->vnc.listen);
-        info->vnc.display = vfb->vnc.display;
-        info->vnc.findunused = vfb->vnc.findunused;
-        if (vfb->vnc.passwd)
-            info->vnc.passwd = vfb->vnc.passwd;
-        if (vfb->keymap)
-            info->keymap = libxl__strdup(gc, vfb->keymap);
-        info->sdl = vfb->sdl;
-    } else
-        info->nographic = 1;
     info->domid = domid;
     return 0;
 }
@@ -1055,7 +1070,7 @@ int libxl__create_xenpv_qemu(libxl__gc *
                              libxl_device_model_info *info,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, &guest_config->vfbs[0], info);
+    libxl__build_xenpv_qemu_args(gc, domid, info);
     libxl__create_device_model(gc, guest_config, info, starting_r);
     return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT6-000132-NC; Mon, 16 Jan 2012 12:15:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT5-0000xV-4n
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25429 invoked from network); 16 Jan 2012 12:15:12 -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;
	16 Jan 2012 12:15:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671887"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0d0032155;	Mon, 16 Jan 2012 04:15:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: a27ac2ae9cefc42e3eee504cb2805824fd80d3f8
Message-ID: <a27ac2ae9cefc42e3eee.1326716108@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 32 RFC] libxl: remove redundant info from
	dm info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326304221 0
# Node ID a27ac2ae9cefc42e3eee504cb2805824fd80d3f8
# Parent  9f9995e2e34967929053c8c75e7c86562b58acf9
libxl: remove redundant info from dm info.

Remove "target_ram", "acpi", "vcpus" and "vcpu_avail" from device model info
and use domain_build_info instead. These must all be consistently specified to
both the domain and the device model, there is no need (and a great deal of
danger) in exposing a way for a user of libxl to set them differently.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9f9995e2e349 -r a27ac2ae9cef tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 17:45:38 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:50:21 2012 +0000
@@ -125,11 +125,7 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
-    dm_info->target_ram = libxl__sizekb_to_mb(b_info->target_memkb);
     dm_info->videoram = libxl__sizekb_to_mb(b_info->video_memkb);
-    dm_info->acpi = b_info->u.hvm.acpi;
-    dm_info->vcpus = b_info->max_vcpus;
-    dm_info->vcpu_avail = b_info->cur_vcpus;
 
     dm_info->stdvga = 0;
     dm_info->vnc.enable = 1;
diff -r 9f9995e2e349 -r a27ac2ae9cef tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 17:45:38 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 17:50:21 2012 +0000
@@ -86,6 +86,7 @@ static char ** libxl__build_device_model
                                         const libxl_domain_config *guest_config,
                                         const libxl_device_model_info *info)
 {
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_vifs = guest_config->num_vifs;
     int i;
@@ -167,14 +168,18 @@ static char ** libxl__build_device_model
         if (info->soundhw) {
             flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
         }
-        if (info->acpi) {
+        if (b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-acpi");
         }
-        if (info->vcpus > 1) {
-            flexarray_vappend(dm_args, "-vcpus", libxl__sprintf(gc, "%d", info->vcpus), NULL);
+        if (b_info->max_vcpus > 1) {
+            flexarray_vappend(dm_args, "-vcpus",
+                              libxl__sprintf(gc, "%d", b_info->max_vcpus),
+                              NULL);
         }
-        if (info->vcpu_avail) {
-            flexarray_vappend(dm_args, "-vcpu_avail", libxl__sprintf(gc, "0x%x", info->vcpu_avail), NULL);
+        if (b_info->cur_vcpus) {
+            flexarray_vappend(dm_args, "-vcpu_avail",
+                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
+                              NULL);
         }
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
@@ -242,6 +247,7 @@ static char ** libxl__build_device_model
                                         const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_disk *disks = guest_config->disks;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
@@ -374,15 +380,18 @@ static char ** libxl__build_device_model
         if (info->soundhw) {
             flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
         }
-        if (!info->acpi) {
+        if (!b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-no-acpi");
         }
-        if (info->vcpus > 1) {
+        if (b_info->max_vcpus > 1) {
             flexarray_append(dm_args, "-smp");
-            if (info->vcpu_avail)
-                flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d", info->vcpus, info->vcpu_avail));
+            if (b_info->cur_vcpus)
+                flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d",
+                                                         b_info->max_vcpus,
+                                                         b_info->cur_vcpus));
             else
-                flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->vcpus));
+                flexarray_append(dm_args, libxl__sprintf(gc, "%d",
+                                                         b_info->max_vcpus));
         }
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
@@ -440,7 +449,9 @@ static char ** libxl__build_device_model
 
     /* RAM Size */
     flexarray_append(dm_args, "-m");
-    flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->target_ram));
+    flexarray_append(dm_args,
+                     libxl__sprintf(gc, "%d",
+                                    libxl__sizekb_to_mb(b_info->target_memkb)));
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         for (i = 0; i < num_disks; i++) {
diff -r 9f9995e2e349 -r a27ac2ae9cef tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 11 17:45:38 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 11 17:50:21 2012 +0000
@@ -248,7 +248,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    ("target_ram",       uint32),
     # size of the videoram in MB
     ("videoram",         integer), 
     ("stdvga",           bool),
@@ -265,9 +264,6 @@ libxl_device_model_info = Struct("device
     # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
     ("usbdevice",        string),
     ("soundhw",          string),
-    ("acpi",             bool),
-    ("vcpus",            integer), # max number of vcpus
-    ("vcpu_avail",       integer), # vcpus actually available
     ("xen_platform_pci", bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
diff -r 9f9995e2e349 -r a27ac2ae9cef tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:45:38 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 17:50:21 2012 +0000
@@ -377,7 +377,6 @@ static void printf_info(int domid,
         printf("\t\t\t(boot %s)\n", dm_info->boot);
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
-        printf("\t\t\t(acpi %d)\n", dm_info->acpi);
         printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
         printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
         printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT6-00012M-8m; Mon, 16 Jan 2012 12:15:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlT5-0000xL-2L
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5367 invoked from network); 16 Jan 2012 12:15:11 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907088"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cx032155;	Mon, 16 Jan 2012 04:15:09 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9f9995e2e34967929053c8c75e7c86562b58acf9
Message-ID: <9f9995e2e34967929053.1326716107@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:07 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 32 RFC] libxl: now that dm creation takes
 domain_config stop passing down 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326303938 0
# Node ID 9f9995e2e34967929053c8c75e7c86562b58acf9
# Parent  14605ae17bd9d8a3e2a5111ae6f06ffda0ddc441
libxl: now that dm creation takes domain_config stop passing down devices.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 14605ae17bd9 -r 9f9995e2e349 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 11 15:46:39 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 17:45:38 2012 +0000
@@ -559,8 +559,6 @@ static int do_domain_create(libxl__gc *g
 
         dm_info->domid = domid;
         ret = libxl__create_device_model(gc, d_config, dm_info,
-                                        d_config->disks, d_config->num_disks,
-                                        d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -606,8 +604,7 @@ static int do_domain_create(libxl__gc *g
             xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
             libxl__create_xenpv_qemu(gc, domid,
-                                     d_config, &xenpv_dm_info,
-                                     d_config->vfbs, &dm_starting);
+                                     d_config, &xenpv_dm_info, &dm_starting);
         }
         break;
     }
diff -r 14605ae17bd9 -r 9f9995e2e349 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Wed Jan 11 15:46:39 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 17:45:38 2012 +0000
@@ -84,10 +84,10 @@ static const char *libxl__domain_bios(li
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
+    const libxl_device_nic *vifs = guest_config->vifs;
+    const int num_vifs = guest_config->num_vifs;
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -239,11 +239,13 @@ static const char *qemu_disk_format_stri
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_device_disk *disks = guest_config->disks;
+    const libxl_device_nic *vifs = guest_config->vifs;
+    const int num_disks = guest_config->num_disks;
+    const int num_vifs = guest_config->num_vifs;
     flexarray_t *dm_args;
     int i;
 
@@ -504,21 +506,15 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (info->device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info,
-                                                  disks, num_disks,
-                                                  vifs, num_vifs);
+        return libxl__build_device_model_args_old(gc, dm, guest_config, info);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info,
-                                                  disks, num_disks,
-                                                  vifs, num_vifs);
+        return libxl__build_device_model_args_new(gc, dm, guest_config, info);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          info->device_model_version);
@@ -596,16 +592,14 @@ retry_transaction:
 static int libxl__create_stubdom(libxl__gc *gc,
                                  libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
-                                 libxl_device_disk *disks, int num_disks,
-                                 libxl_device_nic *vifs, int num_vifs,
-                                 libxl_device_vfb *vfb,
-                                 libxl_device_vkb *vkb,
                                  libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl_device_console *console;
     libxl_domain_config dm_config;
+    libxl_device_vfb vfb;
+    libxl_device_vkb vkb;
     libxl__domain_build_state state;
     uint32_t domid;
     char **args;
@@ -637,6 +631,19 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
+    dm_config.disks = guest_config->disks;
+    dm_config.num_disks = guest_config->num_disks;
+
+    dm_config.vifs = guest_config->vifs;
+    dm_config.num_vifs = guest_config->num_vifs;
+
+    libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
+
+    dm_config.vfbs = &vfb;
+    dm_config.num_vfbs = 1;
+    dm_config.vkbs = &vkb;
+    dm_config.num_vkbs = 1;
+
     /* fixme: this function can leak the stubdom if it fails */
     domid = 0;
     ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
@@ -647,9 +654,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
 
     args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info,
-                                          disks, num_disks,
-                                          vifs, num_vifs);
+                                          guest_config, info);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
@@ -684,20 +689,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &disks[i]);
+    for (i = 0; i < dm_config.num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, domid, &dm_config.disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &vifs[i]);
+    for (i = 0; i < dm_config.num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, domid, &dm_config.vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, domid, vfb);
+    ret = libxl_device_vfb_add(ctx, domid, &dm_config.vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, domid, vkb);
+    ret = libxl_device_vkb_add(ctx, domid, &dm_config.vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -755,7 +760,7 @@ retry_transaction:
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
                                  &xenpv_dm_info,
-                                 vfb, &dm_starting) < 0) {
+                                 &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -785,8 +790,6 @@ out:
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disks, int num_disks,
-                              libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -801,14 +804,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (info->device_model_stubdomain) {
-        libxl_device_vfb vfb;
-        libxl_device_vkb vkb;
-
-        libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-        rc = libxl__create_stubdom(gc, guest_config, info,
-                                   disks, num_disks,
-                                   vifs, num_vifs,
-                                   &vfb, &vkb, starting_r);
+        rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
         goto out;
     }
 
@@ -823,9 +819,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info,
-                                          disks, num_disks,
-                                          vifs, num_vifs);
+    args = libxl__build_device_model_args(gc, dm, guest_config, info);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
@@ -1046,11 +1040,10 @@ out:
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
-                             libxl_device_vfb *vfb,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, vfb, info);
-    libxl__create_device_model(gc, guest_config, info, NULL, 0, NULL, 0, starting_r);
+    libxl__build_xenpv_qemu_args(gc, domid, &guest_config->vfbs[0], info);
+    libxl__create_device_model(gc, guest_config, info, starting_r);
     return 0;
 }
 
diff -r 14605ae17bd9 -r 9f9995e2e349 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Wed Jan 11 15:46:39 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Wed Jan 11 17:45:38 2012 +0000
@@ -467,13 +467,10 @@ _hidden const char *libxl__domain_device
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disks, int num_disks,
-                              libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
-                              libxl_device_vfb *vfb,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlT4-00010Q-7y; Mon, 16 Jan 2012 12:15: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 1RmlT2-0000wT-Bn
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5242 invoked from network); 16 Jan 2012 12:15:09 -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;
	16 Jan 2012 12:15:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907087"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0cv032155;	Mon, 16 Jan 2012 04:15:08 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2cf31bf780380c42d859bb0b8f7c701cbf424180
Message-ID: <2cf31bf780380c42d859.1326716105@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:05 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 32 RFC] libxl: define libxl_sdl_info to
 hold all info about the SDL config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326296553 0
# Node ID 2cf31bf780380c42d859bb0b8f7c701cbf424180
# Parent  3308d2dfd9dddb36f8a65e7a44916c6bcf02170e
libxl: define libxl_sdl_info to hold all info about the SDL config

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Jan 11 15:42:33 2012 +0000
@@ -1952,16 +1952,16 @@ out:
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->display = NULL;
-    vfb->xauthority = NULL;
     vfb->vnc.enable = 1;
     vfb->vnc.passwd = NULL;
     vfb->vnc.listen = strdup("127.0.0.1");
     vfb->vnc.display = 0;
     vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
-    vfb->sdl = 0;
-    vfb->opengl = 0;
+    vfb->sdl.enable = 0;
+    vfb->sdl.opengl = 0;
+    vfb->sdl.display = NULL;
+    vfb->sdl.xauthority = NULL;
     return 0;
 }
 
@@ -2012,16 +2012,19 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
                           libxl__sprintf(gc, "%d", vfb->vnc.findunused));
-    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);
+    flexarray_append_pair(back, "sdl",
+                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+    flexarray_append_pair(back, "opengl",
+                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+    if (vfb->sdl.xauthority) {
+        flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
-    if (vfb->display) {
-        flexarray_append_pair(back, "display", vfb->display);
+    if (vfb->sdl.display) {
+        flexarray_append_pair(back, "display", vfb->sdl.display);
     }
 
-    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
+    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,
diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 11 15:42:33 2012 +0000
@@ -137,8 +137,8 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->vnc.display = 0;
     dm_info->vnc.findunused = 1;
     dm_info->keymap = NULL;
-    dm_info->sdl = 0;
-    dm_info->opengl = 0;
+    dm_info->sdl.enable = 0;
+    dm_info->sdl.opengl = 0;
     dm_info->nographic = 0;
     dm_info->serial = NULL;
     dm_info->boot = strdup("cda");
diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Wed Jan 11 15:42:33 2012 +0000
@@ -128,16 +128,17 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-vncunused");
         }
     }
-    if (info->sdl) {
+    if (info->sdl.enable) {
         flexarray_append(dm_args, "-sdl");
-        if (!info->opengl) {
+        if (!info->sdl.opengl) {
             flexarray_append(dm_args, "-disable-opengl");
         }
+        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
+    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -295,8 +296,9 @@ static char ** libxl__build_device_model
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
                         info->vnc.findunused ? ",to=99" : ""));
     }
-    if (info->sdl) {
+    if (info->sdl.enable) {
         flexarray_append(dm_args, "-sdl");
+        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->spice.enable) {
         char *spiceoptions = NULL;
@@ -343,7 +345,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
+    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -534,7 +536,6 @@ static int libxl__vfb_and_vkb_from_devic
     vfb->vnc = info->vnc;
     vfb->keymap = info->keymap;
     vfb->sdl = info->sdl;
-    vfb->opengl = info->opengl;
 
     vkb->backend_domid = 0;
     vkb->devid = 0;
@@ -991,7 +992,6 @@ static int libxl__build_xenpv_qemu_args(
         if (vfb->keymap)
             info->keymap = libxl__strdup(gc, vfb->keymap);
         info->sdl = vfb->sdl;
-        info->opengl = vfb->opengl;
     } else
         info->nographic = 1;
     info->domid = domid;
diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 11 15:42:33 2012 +0000
@@ -255,8 +255,7 @@ libxl_device_model_info = Struct("device
     ("vnc",              libxl_vnc_info),
     # keyboard layout, default is en-us keyboard
     ("keymap",           string),
-    ("sdl",              bool),
-    ("opengl",           bool), # (requires sdl enabled)
+    ("sdl",              libxl_sdl_info),
     ("spice",            libxl_spice_info),
     ("nographic",        bool),
     ("gfx_passthru",     bool),
@@ -283,12 +282,9 @@ libxl_device_vfb = Struct("device_vfb", 
     ("backend_domid", libxl_domid),
     ("devid",         integer),
     ("vnc",           libxl_vnc_info),
+    ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
     ("keymap",        string),
-    ("sdl",           bool),
-    ("opengl",        bool), # (if enabled requires sdl enabled)
-    ("display",       string),
-    ("xauthority",    string),
     ])
 
 libxl_device_vkb = Struct("device_vkb", [
diff -r 3308d2dfd9dd -r 2cf31bf78038 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 10 17:03:39 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 11 15:42:33 2012 +0000
@@ -369,9 +369,9 @@ static void printf_info(int domid,
         printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
         printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
         printf("\t\t\t(keymap %s)\n", dm_info->keymap);
-        printf("\t\t\t(sdl %d)\n", dm_info->sdl);
+        printf("\t\t\t(sdl %d)\n", dm_info->sdl.enable);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(opengl %d)\n", dm_info->opengl);
+        printf("\t\t\t(opengl %d)\n", dm_info->sdl.opengl);
         printf("\t\t\t(nographic %d)\n", dm_info->nographic);
         printf("\t\t\t(serial %s)\n", dm_info->serial);
         printf("\t\t\t(boot %s)\n", dm_info->boot);
@@ -459,10 +459,10 @@ static void printf_info(int domid,
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
         printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].opengl);
-        printf("\t\t\t(display %s)\n", d_config->vfbs[i].display);
-        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].xauthority);
+        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
+        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
+        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");
         printf("\t)\n");
     }
@@ -976,15 +976,15 @@ skip:
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl = atoi(p2 + 1);
+                    vfb->sdl.enable = atoi(p2 + 1);
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->opengl = atoi(p2 + 1);
+                    vfb->sdl.opengl = atoi(p2 + 1);
                 } else if (!strcmp(p, "display")) {
-                    free(vfb->display);
-                    vfb->display = strdup(p2 + 1);
+                    free(vfb->sdl.display);
+                    vfb->sdl.display = strdup(p2 + 1);
                 } else if (!strcmp(p, "xauthority")) {
-                    free(vfb->xauthority);
-                    vfb->xauthority = strdup(p2 + 1);
+                    free(vfb->sdl.xauthority);
+                    vfb->sdl.xauthority = strdup(p2 + 1);
                 }
             } while ((p = strtok(NULL, ",")) != NULL);
 skip_vfb:
@@ -1187,9 +1187,9 @@ skip_vfb:
             dm_info->vnc.findunused = l;
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            dm_info->sdl = l;
+            dm_info->sdl.enable = l;
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            dm_info->opengl = l;
+            dm_info->sdl.opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTD-0001DU-96; Mon, 16 Jan 2012 12: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 1RmlTB-00011x-0L
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!9
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5741 invoked from network); 16 Jan 2012 12:15:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907093"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0d7032155;	Mon, 16 Jan 2012 04:15:17 -0800
MIME-Version: 1.0
X-Mercurial-Node: 20f5a6a37f6aac5eb314262c16e3548e6ab7a2a9
Message-ID: <20f5a6a37f6aac5eb314.1326716115@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 17 of 32 RFC] libxl: remove uuid from device
	model info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326383425 0
# Node ID 20f5a6a37f6aac5eb314262c16e3548e6ab7a2a9
# Parent  934adb649b43db974d247c3a774ec55aa95930b6
libxl: remove uuid from device model info.

This should be managed by libxl and need not be exposed to the user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 934adb649b43 -r 20f5a6a37f6a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 11:33:01 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 15:50:25 2012 +0000
@@ -134,8 +134,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 {
     memset(dm_info, '\0', sizeof(*dm_info));
 
-    libxl_uuid_generate(&dm_info->uuid);
-
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
diff -r 934adb649b43 -r 20f5a6a37f6a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 11:33:01 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 15:50:25 2012 +0000
@@ -705,7 +705,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
 
-    libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
+    libxl_uuid_generate(&dm_config.c_info.uuid);
 
     memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
     dm_config.b_info.type = dm_config.c_info.type;
diff -r 934adb649b43 -r 20f5a6a37f6a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 11:33:01 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 15:50:25 2012 +0000
@@ -257,9 +257,6 @@ libxl_domain_build_info = Struct("domain
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
     
-    # uuid is used only with stubdom, and must be different from the
-    # domain uuid
-    ("uuid",             libxl_uuid),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTC-0001Ci-QB; Mon, 16 Jan 2012 12:15: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 1RmlTA-00011M-HT
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326716116!11067258!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1593 invoked from network); 16 Jan 2012 12:15:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671895"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:17 -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, 16 Jan 2012 07:15: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
	q0GCF0d6032155;	Mon, 16 Jan 2012 04:15:16 -0800
MIME-Version: 1.0
X-Mercurial-Node: 934adb649b43db974d247c3a774ec55aa95930b6
Message-ID: <934adb649b43db974d24.1326716114@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 16 of 32 RFC] libxl: Remove
	libxl_device_model_info.type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326367981 0
# Node ID 934adb649b43db974d247c3a774ec55aa95930b6
# Parent  28f0d13e7deafd13ae37322bb56c17541ff43a5e
libxl: Remove libxl_device_model_info.type.

This is the type of the target guest which is part of the guest config.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 28f0d13e7dea -r 934adb649b43 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 11:25:42 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 11:33:01 2012 +0000
@@ -592,7 +592,6 @@ static int do_domain_create(libxl__gc *g
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
             xenpv_dm_info.device_model_version =
                 d_config->dm_info.device_model_version;
-            xenpv_dm_info.type = d_config->dm_info.type;
             xenpv_dm_info.device_model = d_config->dm_info.device_model;
             xenpv_dm_info.extra = d_config->dm_info.extra;
             xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
diff -r 28f0d13e7dea -r 934adb649b43 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 11:25:42 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 11:33:01 2012 +0000
@@ -85,7 +85,7 @@ static const libxl_vnc_info *dm_vnc(cons
                                     const libxl_device_model_info *info)
 {
     const libxl_vnc_info *vnc = NULL;
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         vnc = &guest_config->b_info.u.hvm.vnc;
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
@@ -97,7 +97,7 @@ static const libxl_sdl_info *dm_sdl(cons
                                     const libxl_device_model_info *info)
 {
     const libxl_sdl_info *sdl = NULL;
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         sdl = &guest_config->b_info.u.hvm.sdl;
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
@@ -108,7 +108,7 @@ static const libxl_sdl_info *dm_sdl(cons
 static const char *dm_keymap(const libxl_domain_config *guest_config,
                              const libxl_device_model_info *info)
 {
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         return guest_config->b_info.u.hvm.keymap;
     } else if (guest_config->num_vfbs > 0) {
         return guest_config->vfbs[0].keymap;
@@ -179,7 +179,7 @@ static char ** libxl__build_device_model
     if (keymap) {
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
         if (b_info->u.hvm.serial) {
@@ -262,7 +262,7 @@ static char ** libxl__build_device_model
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
     flexarray_append(dm_args, "-M");
-    switch (info->type) {
+    switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
         for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
@@ -361,7 +361,7 @@ static char ** libxl__build_device_model
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
 
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
         flexarray_append(dm_args, "-xen-attach");
     }
 
@@ -408,7 +408,7 @@ static char ** libxl__build_device_model
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
         if (b_info->u.hvm.serial) {
@@ -506,7 +506,7 @@ static char ** libxl__build_device_model
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
     flexarray_append(dm_args, "-M");
-    switch (info->type) {
+    switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
         for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
@@ -525,7 +525,7 @@ static char ** libxl__build_device_model
                      libxl__sprintf(gc, "%d",
                                     libxl__sizekb_to_mb(b_info->target_memkb)));
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         for (i = 0; i < num_disks; i++) {
             int disk, part;
             int dev_number =
@@ -708,6 +708,7 @@ static int libxl__create_stubdom(libxl__
     libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
 
     memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    dm_config.b_info.type = dm_config.c_info.type;
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
@@ -838,7 +839,6 @@ retry_transaction:
 
     memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
     xenpv_dm_info.device_model_version = info->device_model_version;
-    xenpv_dm_info.type = LIBXL_DOMAIN_TYPE_PV;
     xenpv_dm_info.device_model = info->device_model;
     xenpv_dm_info.extra = info->extra;
     xenpv_dm_info.extra_pv = info->extra_pv;
diff -r 28f0d13e7dea -r 934adb649b43 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 11:25:42 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 11:33:01 2012 +0000
@@ -265,7 +265,6 @@ libxl_device_model_info = Struct("device
     # you set device_model you must set device_model_version too
     ("device_model",     string),
     ("saved_state",      string),
-    ("type",             libxl_domain_type),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 28f0d13e7dea -r 934adb649b43 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:25:42 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:33:01 2012 +0000
@@ -1216,8 +1216,6 @@ skip_vfb:
             b_info->u.hvm.xen_platform_pci = l;
     }
 
-    dm_info->type = c_info->type;
-
     xlu_cfg_destroy(config);
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTD-0001DU-96; Mon, 16 Jan 2012 12: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 1RmlTB-00011x-0L
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!9
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5741 invoked from network); 16 Jan 2012 12:15:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907093"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0d7032155;	Mon, 16 Jan 2012 04:15:17 -0800
MIME-Version: 1.0
X-Mercurial-Node: 20f5a6a37f6aac5eb314262c16e3548e6ab7a2a9
Message-ID: <20f5a6a37f6aac5eb314.1326716115@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 17 of 32 RFC] libxl: remove uuid from device
	model info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326383425 0
# Node ID 20f5a6a37f6aac5eb314262c16e3548e6ab7a2a9
# Parent  934adb649b43db974d247c3a774ec55aa95930b6
libxl: remove uuid from device model info.

This should be managed by libxl and need not be exposed to the user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 934adb649b43 -r 20f5a6a37f6a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 11:33:01 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 15:50:25 2012 +0000
@@ -134,8 +134,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 {
     memset(dm_info, '\0', sizeof(*dm_info));
 
-    libxl_uuid_generate(&dm_info->uuid);
-
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
diff -r 934adb649b43 -r 20f5a6a37f6a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 11:33:01 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 15:50:25 2012 +0000
@@ -705,7 +705,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
 
-    libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
+    libxl_uuid_generate(&dm_config.c_info.uuid);
 
     memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
     dm_config.b_info.type = dm_config.c_info.type;
diff -r 934adb649b43 -r 20f5a6a37f6a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 11:33:01 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 15:50:25 2012 +0000
@@ -257,9 +257,6 @@ libxl_domain_build_info = Struct("domain
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
     
-    # uuid is used only with stubdom, and must be different from the
-    # domain uuid
-    ("uuid",             libxl_uuid),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTC-0001Ci-QB; Mon, 16 Jan 2012 12:15: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 1RmlTA-00011M-HT
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326716116!11067258!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1593 invoked from network); 16 Jan 2012 12:15:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671895"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:17 -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, 16 Jan 2012 07:15: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
	q0GCF0d6032155;	Mon, 16 Jan 2012 04:15:16 -0800
MIME-Version: 1.0
X-Mercurial-Node: 934adb649b43db974d247c3a774ec55aa95930b6
Message-ID: <934adb649b43db974d24.1326716114@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 16 of 32 RFC] libxl: Remove
	libxl_device_model_info.type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326367981 0
# Node ID 934adb649b43db974d247c3a774ec55aa95930b6
# Parent  28f0d13e7deafd13ae37322bb56c17541ff43a5e
libxl: Remove libxl_device_model_info.type.

This is the type of the target guest which is part of the guest config.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 28f0d13e7dea -r 934adb649b43 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 11:25:42 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 11:33:01 2012 +0000
@@ -592,7 +592,6 @@ static int do_domain_create(libxl__gc *g
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
             xenpv_dm_info.device_model_version =
                 d_config->dm_info.device_model_version;
-            xenpv_dm_info.type = d_config->dm_info.type;
             xenpv_dm_info.device_model = d_config->dm_info.device_model;
             xenpv_dm_info.extra = d_config->dm_info.extra;
             xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
diff -r 28f0d13e7dea -r 934adb649b43 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 11:25:42 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 11:33:01 2012 +0000
@@ -85,7 +85,7 @@ static const libxl_vnc_info *dm_vnc(cons
                                     const libxl_device_model_info *info)
 {
     const libxl_vnc_info *vnc = NULL;
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         vnc = &guest_config->b_info.u.hvm.vnc;
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
@@ -97,7 +97,7 @@ static const libxl_sdl_info *dm_sdl(cons
                                     const libxl_device_model_info *info)
 {
     const libxl_sdl_info *sdl = NULL;
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         sdl = &guest_config->b_info.u.hvm.sdl;
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
@@ -108,7 +108,7 @@ static const libxl_sdl_info *dm_sdl(cons
 static const char *dm_keymap(const libxl_domain_config *guest_config,
                              const libxl_device_model_info *info)
 {
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         return guest_config->b_info.u.hvm.keymap;
     } else if (guest_config->num_vfbs > 0) {
         return guest_config->vfbs[0].keymap;
@@ -179,7 +179,7 @@ static char ** libxl__build_device_model
     if (keymap) {
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
         if (b_info->u.hvm.serial) {
@@ -262,7 +262,7 @@ static char ** libxl__build_device_model
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
     flexarray_append(dm_args, "-M");
-    switch (info->type) {
+    switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
         for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
@@ -361,7 +361,7 @@ static char ** libxl__build_device_model
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
 
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
         flexarray_append(dm_args, "-xen-attach");
     }
 
@@ -408,7 +408,7 @@ static char ** libxl__build_device_model
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
         if (b_info->u.hvm.serial) {
@@ -506,7 +506,7 @@ static char ** libxl__build_device_model
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
     flexarray_append(dm_args, "-M");
-    switch (info->type) {
+    switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
         for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
@@ -525,7 +525,7 @@ static char ** libxl__build_device_model
                      libxl__sprintf(gc, "%d",
                                     libxl__sizekb_to_mb(b_info->target_memkb)));
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         for (i = 0; i < num_disks; i++) {
             int disk, part;
             int dev_number =
@@ -708,6 +708,7 @@ static int libxl__create_stubdom(libxl__
     libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
 
     memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    dm_config.b_info.type = dm_config.c_info.type;
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
@@ -838,7 +839,6 @@ retry_transaction:
 
     memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
     xenpv_dm_info.device_model_version = info->device_model_version;
-    xenpv_dm_info.type = LIBXL_DOMAIN_TYPE_PV;
     xenpv_dm_info.device_model = info->device_model;
     xenpv_dm_info.extra = info->extra;
     xenpv_dm_info.extra_pv = info->extra_pv;
diff -r 28f0d13e7dea -r 934adb649b43 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 11:25:42 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 11:33:01 2012 +0000
@@ -265,7 +265,6 @@ libxl_device_model_info = Struct("device
     # you set device_model you must set device_model_version too
     ("device_model",     string),
     ("saved_state",      string),
-    ("type",             libxl_domain_type),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 28f0d13e7dea -r 934adb649b43 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:25:42 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:33:01 2012 +0000
@@ -1216,8 +1216,6 @@ skip_vfb:
             b_info->u.hvm.xen_platform_pci = l;
     }
 
-    dm_info->type = c_info->type;
-
     xlu_cfg_destroy(config);
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTD-0001Ec-QB; Mon, 16 Jan 2012 12: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 1RmlTB-00012g-Oa
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25616 invoked from network); 16 Jan 2012 12:15:16 -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;
	16 Jan 2012 12:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671893"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15: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; Mon, 16 Jan 2012 07:15:15 -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
	q0GCF0d4032155;	Mon, 16 Jan 2012 04:15:14 -0800
MIME-Version: 1.0
X-Mercurial-Node: 540c9fa96606437f319762663b0892af9e79a6f3
Message-ID: <540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:12 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configuration
 info build_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326367397 0
# Node ID 540c9fa96606437f319762663b0892af9e79a6f3
# Parent  0ef52f0b6c58344ee371d668ea343628aaecb714
libxl: HVM device configuration info build_info->u.hvm

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0ef52f0b6c58 -r 540c9fa96606 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 11:19:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 11:23:17 2012 +0000
@@ -109,6 +109,11 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.sdl.enable = 0;
         b_info->u.hvm.sdl.opengl = 0;
         b_info->u.hvm.nographic = 0;
+        b_info->u.hvm.serial = NULL;
+        b_info->u.hvm.boot = strdup("cda");
+        b_info->u.hvm.usb = 0;
+        b_info->u.hvm.usbdevice = NULL;
+        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -135,11 +140,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
 
-    dm_info->serial = NULL;
-    dm_info->boot = strdup("cda");
-    dm_info->usb = 0;
-    dm_info->usbdevice = NULL;
-    dm_info->xen_platform_pci = 1;
     return 0;
 }
 
diff -r 0ef52f0b6c58 -r 540c9fa96606 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 11:19:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 11:23:17 2012 +0000
@@ -179,12 +179,13 @@ static char ** libxl__build_device_model
     if (keymap) {
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
-    if (info->serial) {
-        flexarray_vappend(dm_args, "-serial", info->serial, NULL);
-    }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
+        if (b_info->u.hvm.serial) {
+            flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
+        }
+
         if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
@@ -199,17 +200,18 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-std-vga");
         }
 
-        if (info->boot) {
-            flexarray_vappend(dm_args, "-boot", info->boot, NULL);
+        if (b_info->u.hvm.boot) {
+            flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (info->usb || info->usbdevice) {
+        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
-            if (info->usbdevice) {
-                flexarray_vappend(dm_args, "-usbdevice", info->usbdevice, NULL);
+            if (b_info->u.hvm.usbdevice) {
+                flexarray_vappend(dm_args,
+                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
             }
         }
-        if (info->soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
+        if (b_info->u.hvm.soundhw) {
+            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
         if (b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-acpi");
@@ -406,12 +408,13 @@ static char ** libxl__build_device_model
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->serial) {
-        flexarray_vappend(dm_args, "-serial", info->serial, NULL);
-    }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
+        if (b_info->u.hvm.serial) {
+            flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
+        }
+
         if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
@@ -430,17 +433,19 @@ static char ** libxl__build_device_model
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
-        if (info->boot) {
-            flexarray_vappend(dm_args, "-boot", libxl__sprintf(gc, "order=%s", info->boot), NULL);
+        if (b_info->u.hvm.boot) {
+            flexarray_vappend(dm_args, "-boot",
+                    libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (info->usb || info->usbdevice) {
+        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
-            if (info->usbdevice) {
-                flexarray_vappend(dm_args, "-usbdevice", info->usbdevice, NULL);
+            if (b_info->u.hvm.usbdevice) {
+                flexarray_vappend(dm_args,
+                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
             }
         }
-        if (info->soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
+        if (b_info->u.hvm.soundhw) {
+            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
         if (!b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-no-acpi");
@@ -788,7 +793,7 @@ retry_transaction:
     if (ret)
         goto out_free;
 
-    if (info->serial)
+    if (guest_config->b_info.u.hvm.serial)
         num_console++;
 
     console = libxl__calloc(gc, num_console, sizeof(libxl_device_console));
@@ -916,7 +921,8 @@ int libxl__create_device_model(libxl__gc
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
+                    "%d", !guest_config->b_info.u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 0ef52f0b6c58 -r 540c9fa96606 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 11:19:52 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 11:23:17 2012 +0000
@@ -226,6 +226,16 @@ libxl_domain_build_info = Struct("domain
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
+                                       
+                                       ("serial",           string),
+                                       ("boot",             string),
+                                       ("usb",              bool),
+                                       # usbdevice:
+                                       # - "tablet" for absolute mouse,
+                                       # - "mouse" for PS/2 protocol relative mouse
+                                       ("usbdevice",        string),
+                                       ("soundhw",          string),
+                                       ("xen_platform_pci", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -255,13 +265,6 @@ libxl_device_model_info = Struct("device
     ("saved_state",      string),
     ("type",             libxl_domain_type),
     ("gfx_passthru",     bool),
-    ("serial",           string),
-    ("boot",             string),
-    ("usb",              bool),
-    # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
-    ("usbdevice",        string),
-    ("soundhw",          string),
-    ("xen_platform_pci", bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 0ef52f0b6c58 -r 540c9fa96606 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:19:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:23:17 2012 +0000
@@ -380,10 +380,10 @@ static void printf_info(int domid,
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(serial %s)\n", dm_info->serial);
-        printf("\t\t\t(boot %s)\n", dm_info->boot);
-        printf("\t\t\t(usb %d)\n", dm_info->usb);
-        printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
+        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
+        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
+        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1209,14 +1209,14 @@ skip_vfb:
             b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
+        xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+            b_info->u.hvm.usb = l;
+        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
         if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            dm_info->xen_platform_pci = l;
+            b_info->u.hvm.xen_platform_pci = 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 Mon Jan 16 12:15:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTD-0001Ec-QB; Mon, 16 Jan 2012 12: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 1RmlTB-00012g-Oa
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326716102!11193372!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25616 invoked from network); 16 Jan 2012 12:15:16 -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;
	16 Jan 2012 12:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671893"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15: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; Mon, 16 Jan 2012 07:15:15 -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
	q0GCF0d4032155;	Mon, 16 Jan 2012 04:15:14 -0800
MIME-Version: 1.0
X-Mercurial-Node: 540c9fa96606437f319762663b0892af9e79a6f3
Message-ID: <540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:12 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configuration
 info build_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326367397 0
# Node ID 540c9fa96606437f319762663b0892af9e79a6f3
# Parent  0ef52f0b6c58344ee371d668ea343628aaecb714
libxl: HVM device configuration info build_info->u.hvm

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0ef52f0b6c58 -r 540c9fa96606 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 11:19:52 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 11:23:17 2012 +0000
@@ -109,6 +109,11 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.sdl.enable = 0;
         b_info->u.hvm.sdl.opengl = 0;
         b_info->u.hvm.nographic = 0;
+        b_info->u.hvm.serial = NULL;
+        b_info->u.hvm.boot = strdup("cda");
+        b_info->u.hvm.usb = 0;
+        b_info->u.hvm.usbdevice = NULL;
+        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -135,11 +140,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
 
-    dm_info->serial = NULL;
-    dm_info->boot = strdup("cda");
-    dm_info->usb = 0;
-    dm_info->usbdevice = NULL;
-    dm_info->xen_platform_pci = 1;
     return 0;
 }
 
diff -r 0ef52f0b6c58 -r 540c9fa96606 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 11:19:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 11:23:17 2012 +0000
@@ -179,12 +179,13 @@ static char ** libxl__build_device_model
     if (keymap) {
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
-    if (info->serial) {
-        flexarray_vappend(dm_args, "-serial", info->serial, NULL);
-    }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
+        if (b_info->u.hvm.serial) {
+            flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
+        }
+
         if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
@@ -199,17 +200,18 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-std-vga");
         }
 
-        if (info->boot) {
-            flexarray_vappend(dm_args, "-boot", info->boot, NULL);
+        if (b_info->u.hvm.boot) {
+            flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (info->usb || info->usbdevice) {
+        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
-            if (info->usbdevice) {
-                flexarray_vappend(dm_args, "-usbdevice", info->usbdevice, NULL);
+            if (b_info->u.hvm.usbdevice) {
+                flexarray_vappend(dm_args,
+                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
             }
         }
-        if (info->soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
+        if (b_info->u.hvm.soundhw) {
+            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
         if (b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-acpi");
@@ -406,12 +408,13 @@ static char ** libxl__build_device_model
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->serial) {
-        flexarray_vappend(dm_args, "-serial", info->serial, NULL);
-    }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
+        if (b_info->u.hvm.serial) {
+            flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
+        }
+
         if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
@@ -430,17 +433,19 @@ static char ** libxl__build_device_model
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
-        if (info->boot) {
-            flexarray_vappend(dm_args, "-boot", libxl__sprintf(gc, "order=%s", info->boot), NULL);
+        if (b_info->u.hvm.boot) {
+            flexarray_vappend(dm_args, "-boot",
+                    libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (info->usb || info->usbdevice) {
+        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
-            if (info->usbdevice) {
-                flexarray_vappend(dm_args, "-usbdevice", info->usbdevice, NULL);
+            if (b_info->u.hvm.usbdevice) {
+                flexarray_vappend(dm_args,
+                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
             }
         }
-        if (info->soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
+        if (b_info->u.hvm.soundhw) {
+            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
         if (!b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-no-acpi");
@@ -788,7 +793,7 @@ retry_transaction:
     if (ret)
         goto out_free;
 
-    if (info->serial)
+    if (guest_config->b_info.u.hvm.serial)
         num_console++;
 
     console = libxl__calloc(gc, num_console, sizeof(libxl_device_console));
@@ -916,7 +921,8 @@ int libxl__create_device_model(libxl__gc
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
+                    "%d", !guest_config->b_info.u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 0ef52f0b6c58 -r 540c9fa96606 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 11:19:52 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 11:23:17 2012 +0000
@@ -226,6 +226,16 @@ libxl_domain_build_info = Struct("domain
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
+                                       
+                                       ("serial",           string),
+                                       ("boot",             string),
+                                       ("usb",              bool),
+                                       # usbdevice:
+                                       # - "tablet" for absolute mouse,
+                                       # - "mouse" for PS/2 protocol relative mouse
+                                       ("usbdevice",        string),
+                                       ("soundhw",          string),
+                                       ("xen_platform_pci", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -255,13 +265,6 @@ libxl_device_model_info = Struct("device
     ("saved_state",      string),
     ("type",             libxl_domain_type),
     ("gfx_passthru",     bool),
-    ("serial",           string),
-    ("boot",             string),
-    ("usb",              bool),
-    # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
-    ("usbdevice",        string),
-    ("soundhw",          string),
-    ("xen_platform_pci", bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 0ef52f0b6c58 -r 540c9fa96606 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:19:52 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 11:23:17 2012 +0000
@@ -380,10 +380,10 @@ static void printf_info(int domid,
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(serial %s)\n", dm_info->serial);
-        printf("\t\t\t(boot %s)\n", dm_info->boot);
-        printf("\t\t\t(usb %d)\n", dm_info->usb);
-        printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
+        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
+        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
+        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1209,14 +1209,14 @@ skip_vfb:
             b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
+        xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+            b_info->u.hvm.usb = l;
+        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
         if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            dm_info->xen_platform_pci = l;
+            b_info->u.hvm.xen_platform_pci = 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 Mon Jan 16 12:15:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTI-0001PU-Es; Mon, 16 Jan 2012 12:15: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 1RmlTF-00018O-9p
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!10
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5842 invoked from network); 16 Jan 2012 12:15:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907094"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:19 -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
	q0GCF0d9032155;	Mon, 16 Jan 2012 04:15:18 -0800
MIME-Version: 1.0
X-Mercurial-Node: c7160a835d3c01b6317551faac90bee4f5b4601c
Message-ID: <c7160a835d3c01b63175.1326716117@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:17 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 19 of 32 RFC] libxl: move "saved_state" to
 libxl__domain_build_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 1326384100 0
# Node ID c7160a835d3c01b6317551faac90bee4f5b4601c
# Parent  ff41e5fc0f12450cd836ce1466c0c51ab685e04b
libxl: move "saved_state" to libxl__domain_build_state.

This is internal to the library and need not be exposed to the user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ff41e5fc0f12 -r c7160a835d3c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 15:57:08 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 16:01:40 2012 +0000
@@ -281,9 +281,8 @@ static int domain_restore(libxl__gc *gc,
     if (ret)
         goto out;
 
-    dm_info->saved_state = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&dm_info->saved_state,
+        ret = asprintf(&state->saved_state,
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
         ret = (ret < 0) ? ERROR_FAIL : 0;
     }
@@ -499,13 +498,11 @@ static int do_domain_create(libxl__gc *g
         }
     }
 
+    memset(&state, 0, sizeof(state));
+
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state, dm_info);
     } else {
-        if (dm_info->saved_state) {
-            free(dm_info->saved_state);
-            dm_info->saved_state = NULL;
-        }
         ret = libxl__domain_build(gc, &d_config->b_info, dm_info, domid, &state);
     }
 
@@ -555,7 +552,7 @@ static int do_domain_create(libxl__gc *g
 
         dm_info->domid = domid;
         ret = libxl__create_device_model(gc, d_config, dm_info,
-                                        &dm_starting);
+                                         &state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -592,8 +589,8 @@ static int do_domain_create(libxl__gc *g
             /* only copy those useful configs */
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
 
-            libxl__create_xenpv_qemu(gc, domid,
-                                     d_config, &xenpv_dm_info, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config,
+                                     &xenpv_dm_info, &state, &dm_starting);
         }
         break;
     }
@@ -607,7 +604,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_info, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff -r ff41e5fc0f12 -r c7160a835d3c tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 15:57:08 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 16:01:40 2012 +0000
@@ -119,7 +119,8 @@ static const char *dm_keymap(const libxl
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
@@ -256,8 +257,8 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-nographic");
     }
 
-    if (info->saved_state) {
-        flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
+    if (state->saved_state) {
+        flexarray_vappend(dm_args, "-loadvm", state->saved_state, NULL);
     }
     for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
         flexarray_append(dm_args, b_info->extra[i]);
@@ -329,7 +330,8 @@ static char *dm_spice_options(libxl__gc 
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
@@ -497,9 +499,9 @@ static char ** libxl__build_device_model
         }
     }
 
-    if (info->saved_state) {
+    if (state->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
-        int migration_fd = open(info->saved_state, O_RDONLY);
+        int migration_fd = open(state->saved_state, O_RDONLY);
         flexarray_append(dm_args, "-incoming");
         flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
@@ -589,15 +591,16 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info);
+        return libxl__build_device_model_args_old(gc, dm, guest_config, info, state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info);
+        return libxl__build_device_model_args_new(gc, dm, guest_config, info, state);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          guest_config->b_info.device_model_version);
@@ -680,6 +683,7 @@ retry_transaction:
 static int libxl__create_stubdom(libxl__gc *gc,
                                  libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
+                                 libxl__domain_build_state *d_state,
                                  libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -688,7 +692,7 @@ static int libxl__create_stubdom(libxl__
     libxl_domain_config dm_config;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state state;
+    libxl__domain_build_state stubdom_state;
     uint32_t domid;
     char **args;
     struct xs_permissions perm[2];
@@ -746,12 +750,12 @@ static int libxl__create_stubdom(libxl__
     ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &state);
+    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &stubdom_state);
     if (ret)
         goto out;
 
     args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info);
+                                          guest_config, info, d_state);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
@@ -823,7 +827,8 @@ retry_transaction:
             char *filename;
             char *name;
             case STUBDOM_CONSOLE_LOGGING:
-                name = libxl__sprintf(gc, "qemu-dm-%s", libxl_domid_to_name(ctx, info->domid));
+                name = libxl__sprintf(gc, "qemu-dm-%s",
+                                      libxl_domid_to_name(ctx, info->domid));
                 libxl_create_logfile(ctx, name, &filename);
                 console[i].output = libxl__sprintf(gc, "file:%s", filename);
                 free(filename);
@@ -833,15 +838,16 @@ retry_transaction:
                                 libxl__device_model_savefile(gc, info->domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
-                if (info->saved_state)
-                    console[i].output = libxl__sprintf(gc, "pipe:%s", info->saved_state);
+                if (d_state->saved_state)
+                    console[i].output =
+                        libxl__sprintf(gc, "pipe:%s", d_state->saved_state);
                 break;
             default:
                 console[i].output = "pty";
                 break;
         }
         ret = libxl__device_console_add(gc, domid, &console[i],
-                                    i == STUBDOM_CONSOLE_LOGGING ? &state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
@@ -851,12 +857,12 @@ retry_transaction:
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
                                  &xenpv_dm_info,
+                                 &stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
-    if (libxl__confirm_device_model_startup(gc, &xenpv_dm_info,
-                                            dm_starting) < 0) {
+    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -881,6 +887,7 @@ out:
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -898,7 +905,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (b_info->device_model_stubdomain) {
-        rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
+        rc = libxl__create_stubdom(gc, guest_config, info, state, starting_r);
         goto out;
     }
 
@@ -913,7 +920,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info);
+    args = libxl__build_device_model_args(gc, dm, guest_config, info, state);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
@@ -994,10 +1001,9 @@ out:
 
 
 int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl_device_model_info *dm_info,
+                                libxl__domain_build_state *state,
                                 libxl__spawner_starting *starting)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     int domid = starting->domid;
     int ret, ret2;
@@ -1005,11 +1011,11 @@ int libxl__confirm_device_model_startup(
     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,
+    if (state->saved_state) {
+        ret2 = unlink(state->saved_state);
+        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
                                    "failed to remove device-model state %s\n",
-                                   dm_info->saved_state);
+                                   state->saved_state);
         /* Do not clobber spawn_confirm error code with unlink error code. */
         if (!ret) ret = ret2;
     }
@@ -1120,10 +1126,11 @@ out:
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
+                             libxl__domain_build_state *state,
                              libxl__spawner_starting **starting_r)
 {
     libxl__build_xenpv_qemu_args(gc, domid, info);
-    libxl__create_device_model(gc, guest_config, info, starting_r);
+    libxl__create_device_model(gc, guest_config, info, state, starting_r);
     return 0;
 }
 
diff -r ff41e5fc0f12 -r c7160a835d3c tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 12 15:57:08 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Jan 12 16:01:40 2012 +0000
@@ -220,6 +220,8 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+
+    char *saved_state;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
@@ -467,10 +469,12 @@ _hidden const char *libxl__domain_device
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,
@@ -480,7 +484,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__domain_build_state *state,
                               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,
diff -r ff41e5fc0f12 -r c7160a835d3c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 15:57:08 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 16:01:40 2012 +0000
@@ -269,8 +269,6 @@ libxl_domain_build_info = Struct("domain
 # Device Model Information
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
-    
-    ("saved_state",      string),
     ],
 )
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTI-0001QE-TM; Mon, 16 Jan 2012 12:15:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTF-00018B-6l
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326716120!10604198!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10755 invoked from network); 16 Jan 2012 12:15:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671908"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:20 -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
	q0GCF0dA032155;	Mon, 16 Jan 2012 04:15:19 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1e558d62909f4f236bb5edd7019073593564ac31
Message-ID: <1e558d62909f4f236bb5.1326716118@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 20 of 32 RFC] libxl: remove
	libxl_device_model_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326385359 0
# Node ID 1e558d62909f4f236bb5edd7019073593564ac31
# Parent  c7160a835d3c01b6317551faac90bee4f5b4601c
libxl: remove libxl_device_model_info.

All that is left here is the target domain's domid which we can pass around as
a parameter.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Jan 12 16:22:39 2012 +0000
@@ -2381,7 +2381,7 @@ out:
 }
 
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
-        libxl_device_model_info *dm_info, uint32_t *need_memkb)
+                             uint32_t *need_memkb)
 {
     GC_INIT(ctx);
     int rc = ERROR_INVAL;
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Jan 12 16:22:39 2012 +0000
@@ -230,7 +230,6 @@ enum {
 typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
-    libxl_device_model_info dm_info;
 
     int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
 
@@ -258,10 +257,6 @@ int libxl_init_create_info(libxl_ctx *ct
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
                           libxl_domain_create_info *c_info);
-int libxl_init_dm_info(libxl_ctx *ctx,
-                       libxl_device_model_info *dm_info,
-                       libxl_domain_create_info *c_info,
-                       libxl_domain_build_info *b_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
@@ -359,7 +354,7 @@ int libxl_set_memory_target(libxl_ctx *c
 int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target);
 /* how much free memory in the system a domain needs to be built */
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
-        libxl_device_model_info *dm_info, uint32_t *need_memkb);
+                             uint32_t *need_memkb);
 /* how much free memory is available in the system */
 int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb);
 /* wait for a given amount of memory to be free in the system */
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 16:22:39 2012 +0000
@@ -55,7 +55,6 @@ void libxl_domain_config_dispose(libxl_d
 
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
-    libxl_device_model_info_dispose(&d_config->dm_info);
 }
 
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
@@ -133,17 +132,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     return 0;
 }
 
-int libxl_init_dm_info(libxl_ctx *ctx,
-                       libxl_device_model_info *dm_info,
-                       libxl_domain_create_info *c_info,
-                       libxl_domain_build_info *b_info)
-{
-    memset(dm_info, '\0', sizeof(*dm_info));
-
-
-    return 0;
-}
-
 static int init_console_info(libxl_device_console *console, int dev_num)
 {
     memset(console, 0x00, sizeof(libxl_device_console));
@@ -157,7 +145,6 @@ static int init_console_info(libxl_devic
 
 int libxl__domain_build(libxl__gc *gc,
                         libxl_domain_build_info *info,
-                        libxl_device_model_info *dm_info,
                         uint32_t domid,
                         libxl__domain_build_state *state)
 {
@@ -173,7 +160,7 @@ int libxl__domain_build(libxl__gc *gc,
 
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        ret = libxl__build_hvm(gc, domid, info, dm_info, state);
+        ret = libxl__build_hvm(gc, domid, info, state);
         if (ret)
             goto out;
 
@@ -227,8 +214,7 @@ out:
 
 static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
                           uint32_t domid, int fd,
-                          libxl__domain_build_state *state,
-                          libxl_device_model_info *dm_info)
+                          libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
@@ -464,7 +450,6 @@ static int do_domain_create(libxl__gc *g
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl_device_model_info *dm_info = &d_config->dm_info;
     libxl__domain_build_state state;
     uint32_t domid;
     int i, ret;
@@ -501,9 +486,9 @@ static int do_domain_create(libxl__gc *g
     memset(&state, 0, sizeof(state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state, dm_info);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, dm_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
     }
 
     if (ret) {
@@ -550,8 +535,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        dm_info->domid = domid;
-        ret = libxl__create_device_model(gc, d_config, dm_info,
+        ret = libxl__create_device_model(gc, domid, d_config,
                                          &state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -564,7 +548,6 @@ static int do_domain_create(libxl__gc *g
     {
         int need_qemu = 0;
         libxl_device_console console;
-        libxl_device_model_info xenpv_dm_info;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
             libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
@@ -586,11 +569,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_console_dispose(&console);
 
         if (need_qemu) {
-            /* only copy those useful configs */
-            memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-
-            libxl__create_xenpv_qemu(gc, domid, d_config,
-                                     &xenpv_dm_info, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
         }
         break;
     }
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 16:22:39 2012 +0000
@@ -81,8 +81,7 @@ static const char *libxl__domain_bios(li
     }
 }
 
-static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config,
-                                    const libxl_device_model_info *info)
+static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config)
 {
     const libxl_vnc_info *vnc = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -93,8 +92,7 @@ static const libxl_vnc_info *dm_vnc(cons
     return vnc && vnc->enable ? vnc : NULL;
 }
 
-static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config,
-                                    const libxl_device_model_info *info)
+static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
 {
     const libxl_sdl_info *sdl = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -105,8 +103,7 @@ static const libxl_sdl_info *dm_sdl(cons
     return sdl && sdl->enable ? sdl : NULL;
 }
 
-static const char *dm_keymap(const libxl_domain_config *guest_config,
-                             const libxl_device_model_info *info)
+static const char *dm_keymap(const libxl_domain_config *guest_config)
 {
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         return guest_config->b_info.u.hvm.keymap;
@@ -117,18 +114,17 @@ static const char *dm_keymap(const libxl
 }
 
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const int num_vifs = guest_config->num_vifs;
-    const char *keymap = dm_keymap(guest_config, info);
+    const char *keymap = dm_keymap(guest_config);
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -137,7 +133,7 @@ static char ** libxl__build_device_model
         return NULL;
 
     flexarray_vappend(dm_args, dm,
-                      "-d", libxl__sprintf(gc, "%d", info->domid), NULL);
+                      "-d", libxl__sprintf(gc, "%d", domid), NULL);
 
     if (c_info->name)
         flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
@@ -233,7 +229,8 @@ static char ** libxl__build_device_model
                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname)
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc,
+                                            "tap%d.%d", domid, vifs[i].devid);
                 else
                     ifname = vifs[i].ifname;
                 flexarray_vappend(dm_args,
@@ -328,9 +325,8 @@ static char *dm_spice_options(libxl__gc 
 }
 
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int guest_domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -340,9 +336,9 @@ static char ** libxl__build_device_model
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
-    const char *keymap = dm_keymap(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config);
+    const char *keymap = dm_keymap(guest_config);
     flexarray_t *dm_args;
     int i;
 
@@ -351,14 +347,14 @@ static char ** libxl__build_device_model
         return NULL;
 
     flexarray_vappend(dm_args, dm,
-                      "-xen-domid", libxl__sprintf(gc, "%d", info->domid), NULL);
+                      "-xen-domid",
+                      libxl__sprintf(gc, "%d", guest_domid), NULL);
 
     flexarray_append(dm_args, "-chardev");
     flexarray_append(dm_args,
                      libxl__sprintf(gc, "socket,id=libxl-cmd,"
                                     "path=%s/qmp-libxl-%d,server,nowait",
-                                    libxl_run_dir_path(),
-                                    info->domid));
+                                    libxl_run_dir_path(), guest_domid));
 
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
@@ -468,7 +464,8 @@ static char ** libxl__build_device_model
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc, "tap%d.%d",
+                                            guest_domid, vifs[i].devid);
                 } else {
                     ifname = vifs[i].ifname;
                 }
@@ -589,18 +586,21 @@ static char ** libxl__build_device_model
 }
 
 static char ** libxl__build_device_model_args(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int guest_domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info, state);
+        return libxl__build_device_model_args_old(gc, dm,
+                                                  guest_domid, guest_config,
+                                                  state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info, state);
+        return libxl__build_device_model_args_new(gc, dm,
+                                                  guest_domid, guest_config,
+                                                  state);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          guest_config->b_info.device_model_version);
@@ -632,7 +632,9 @@ static int libxl__vfb_and_vkb_from_hvm_g
     return 0;
 }
 
-static int libxl__write_dmargs(libxl__gc *gc, int domid, int guest_domid, char **args)
+static int libxl__write_stub_dmargs(libxl__gc *gc,
+                                    int dm_domid, int guest_domid,
+                                    char **args)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i;
@@ -644,7 +646,7 @@ static int libxl__write_dmargs(libxl__gc
 
     roperm[0].id = 0;
     roperm[0].perms = XS_PERM_NONE;
-    roperm[1].id = domid;
+    roperm[1].id = dm_domid;
     roperm[1].perms = XS_PERM_READ;
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/vm", guest_domid));
@@ -681,8 +683,8 @@ retry_transaction:
 }
 
 static int libxl__create_stubdom(libxl__gc *gc,
+                                 int guest_domid,
                                  libxl_domain_config *guest_config,
-                                 libxl_device_model_info *info,
                                  libxl__domain_build_state *d_state,
                                  libxl__spawner_starting **starting_r)
 {
@@ -693,12 +695,11 @@ static int libxl__create_stubdom(libxl__
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
     libxl__domain_build_state stubdom_state;
-    uint32_t domid;
+    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
     libxl__spawner_starting *dm_starting = 0;
-    libxl_device_model_info xenpv_dm_info;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -708,7 +709,8 @@ static int libxl__create_stubdom(libxl__
 
     memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
+    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+                                    libxl__domid_to_name(gc, guest_domid));
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
@@ -721,7 +723,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
+    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
@@ -746,64 +748,74 @@ static int libxl__create_stubdom(libxl__
     dm_config.num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
+    dm_domid = 0;
+    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
     if (ret)
         goto out;
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info, d_state);
+    args = libxl__build_device_model_args(gc, "stubdom-dm", guest_domid,
+                                          guest_config, d_state);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
     }
 
-    libxl__write_dmargs(gc, domid, info->domid, args);
+    libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
     libxl__xs_write(gc, XBT_NULL,
-                   libxl__sprintf(gc, "%s/image/device-model-domid", libxl__xs_get_dompath(gc, info->domid)),
-                   "%d", domid);
+                   libxl__sprintf(gc, "%s/image/device-model-domid",
+                                  libxl__xs_get_dompath(gc, guest_domid)),
+                   "%d", dm_domid);
     libxl__xs_write(gc, XBT_NULL,
-                   libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)),
-                   "%d", info->domid);
-    ret = xc_domain_set_target(ctx->xch, domid, info->domid);
+                   libxl__sprintf(gc, "%s/target",
+                                  libxl__xs_get_dompath(gc, dm_domid)),
+                   "%d", guest_domid);
+    ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
     if (ret<0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting target domain %d -> %d", domid, info->domid);
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "setting target domain %d -> %d",
+                         dm_domid, guest_domid);
         ret = ERROR_FAIL;
         goto out_free;
     }
-    xs_set_target(ctx->xsh, domid, info->domid);
+    xs_set_target(ctx->xsh, dm_domid, guest_domid);
 
-    perm[0].id = domid;
+    perm[0].id = dm_domid;
     perm[0].perms = XS_PERM_NONE;
-    perm[1].id = info->domid;
+    perm[1].id = guest_domid;
     perm[1].perms = XS_PERM_READ;
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
-    xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid));
-    xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid), perm, ARRAY_SIZE(perm));
-    xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/%d/device/vfs", domid));
-    xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/%d/device/vfs",domid), perm, ARRAY_SIZE(perm));
+    xs_mkdir(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid));
+    xs_set_permissions(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid),
+                       perm, ARRAY_SIZE(perm));
+    xs_mkdir(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/%d/device/vfs", dm_domid));
+    xs_set_permissions(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/%d/device/vfs", dm_domid),
+                       perm, ARRAY_SIZE(perm));
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
         if (ret)
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -828,14 +840,14 @@ retry_transaction:
             char *name;
             case STUBDOM_CONSOLE_LOGGING:
                 name = libxl__sprintf(gc, "qemu-dm-%s",
-                                      libxl_domid_to_name(ctx, info->domid));
+                                      libxl_domid_to_name(ctx, guest_domid));
                 libxl_create_logfile(ctx, name, &filename);
                 console[i].output = libxl__sprintf(gc, "file:%s", filename);
                 free(filename);
                 break;
             case STUBDOM_CONSOLE_SAVE:
                 console[i].output = libxl__sprintf(gc, "file:%s",
-                                libxl__device_model_savefile(gc, info->domid));
+                                libxl__device_model_savefile(gc, guest_domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
                 if (d_state->saved_state)
@@ -846,17 +858,14 @@ retry_transaction:
                 console[i].output = "pty";
                 break;
         }
-        ret = libxl__device_console_add(gc, domid, &console[i],
+        ret = libxl__device_console_add(gc, dm_domid, &console[i],
                         i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
-    memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-
-    if (libxl__create_xenpv_qemu(gc, domid,
+    if (libxl__create_xenpv_qemu(gc, dm_domid,
                                  &dm_config,
-                                 &xenpv_dm_info,
                                  &stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
@@ -867,12 +876,12 @@ retry_transaction:
         goto out_free;
     }
 
-    libxl_domain_unpause(ctx, domid);
+    libxl_domain_unpause(ctx, dm_domid);
 
     if (starting_r) {
         *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = info->domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, info->domid);
+        (*starting_r)->domid = guest_domid;
+        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
         (*starting_r)->for_spawn = NULL;
     }
 
@@ -885,15 +894,15 @@ out:
 }
 
 int libxl__create_device_model(libxl__gc *gc,
+                              int domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
@@ -905,7 +914,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (b_info->device_model_stubdomain) {
-        rc = libxl__create_stubdom(gc, guest_config, info, state, starting_r);
+        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
 
@@ -920,18 +929,18 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info, state);
+    args = libxl__build_device_model_args(gc, dm, domid, guest_config, state);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
+    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
                     "%s", libxl__domain_bios(gc, b_info));
 
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
                     "%d", !b_info->u.hvm.xen_platform_pci);
@@ -955,8 +964,8 @@ int libxl__create_device_model(libxl__gc
         p->for_spawn = NULL;
     }
 
-    p->domid = info->domid;
-    p->dom_path = libxl__xs_get_dompath(gc, info->domid);
+    p->domid = domid;
+    p->dom_path = libxl__xs_get_dompath(gc, domid);
     p->pid_path = "image/device-model-pid";
     if (!p->dom_path) {
         rc = ERROR_FAIL;
@@ -1078,14 +1087,6 @@ out:
     return ret;
 }
 
-static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
-                                        uint32_t domid,
-                                        libxl_device_model_info *info)
-{
-    info->domid = domid;
-    return 0;
-}
-
 int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1125,12 +1126,10 @@ out:
 
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
-                             libxl_device_model_info *info,
                              libxl__domain_build_state *state,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, info);
-    libxl__create_device_model(gc, guest_config, info, state, starting_r);
+    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
     return 0;
 }
 
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Jan 12 16:22:39 2012 +0000
@@ -288,8 +288,7 @@ static int hvm_build_set_params(xc_inter
 }
 
 static const char *libxl__domain_firmware(libxl__gc *gc,
-                                          libxl_domain_build_info *info,
-                                          libxl_device_model_info *dm_info)
+                                          libxl_domain_build_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *firmware;
@@ -317,12 +316,11 @@ static const char *libxl__domain_firmwar
 
 int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info,
-              libxl_device_model_info *dm_info,
               libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret, rc = ERROR_FAIL;
-    const char *firmware = libxl__domain_firmware(gc, info, dm_info);
+    const char *firmware = libxl__domain_firmware(gc, info);
 
     if (!firmware)
         goto out;
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Jan 12 16:22:39 2012 +0000
@@ -234,7 +234,6 @@ _hidden int libxl__build_pv(libxl__gc *g
              libxl_domain_build_info *info, libxl__domain_build_state *state);
 _hidden int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info,
-              libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
@@ -456,10 +455,11 @@ _hidden void libxl__exec(int stdinfd, in
                const char *arg0, char **args); // logs errors, never returns
 
 /* from xl_create */
-_hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
+_hidden int libxl__domain_make(libxl__gc *gc,
+                               libxl_domain_create_info *info,
+                               uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,
                                 libxl_domain_build_info *info,
-                                libxl_device_model_info *dm_info,
                                 uint32_t domid,
                                 libxl__domain_build_state *state);
 
@@ -467,13 +467,12 @@ _hidden int libxl__domain_build(libxl__g
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
+                              int domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *dm_info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 16:22:39 2012 +0000
@@ -289,8 +289,7 @@ static void dolog(const char *file, int 
 }
 
 static void printf_info(int domid,
-                        libxl_domain_config *d_config,
-                        libxl_device_model_info *dm_info)
+                        libxl_domain_config *d_config)
 {
     int i;
     libxl_dominfo info;
@@ -569,8 +568,7 @@ static void split_string_into_string_lis
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
-                              libxl_domain_config *d_config,
-                              libxl_device_model_info *dm_info)
+                              libxl_domain_config *d_config)
 {
     const char *buf;
     long l;
@@ -1110,9 +1108,6 @@ skip_vfb:
         break;
     }
 
-    /* init dm from c and b */
-    if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
-        exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
     if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
@@ -1362,7 +1357,7 @@ struct domain_create {
     char **migration_domname_r; /* from malloc */
 };
 
-static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
+static int freemem(libxl_domain_build_info *b_info)
 {
     int rc, retries = 3;
     uint32_t need_memkb, free_memkb;
@@ -1370,7 +1365,7 @@ static int freemem(libxl_domain_build_in
     if (!autoballoon)
         return 0;
 
-    rc = libxl_domain_need_memory(ctx, b_info, dm_info, &need_memkb);
+    rc = libxl_domain_need_memory(ctx, b_info, &need_memkb);
     if (rc < 0)
         return rc;
 
@@ -1553,7 +1548,7 @@ static int create_domain(struct domain_c
     if (!dom_info->quiet)
         printf("Parsing config file %s\n", config_file);
 
-    parse_config_data(config_file, config_data, config_len, &d_config, &d_config.dm_info);
+    parse_config_data(config_file, config_data, config_len, &d_config);
 
     if (migrate_fd >= 0) {
         if (d_config.c_info.name) {
@@ -1574,7 +1569,7 @@ static int create_domain(struct domain_c
     }
 
     if (debug || dom_info->dryrun)
-        printf_info(-1, &d_config, &d_config.dm_info);
+        printf_info(-1, &d_config);
 
     ret = 0;
     if (dom_info->dryrun)
@@ -1587,7 +1582,7 @@ start:
     if (rc < 0)
         goto error_out;
 
-    ret = freemem(&d_config.b_info, &d_config.dm_info);
+    ret = freemem(&d_config.b_info);
     if (ret < 0) {
         fprintf(stderr, "failed to free memory for the domain\n");
         ret = ERROR_FAIL;
@@ -2331,7 +2326,6 @@ static void list_domains_details(const l
     char *config_file;
     uint8_t *data;
     int i, len, rc;
-    libxl_device_model_info dm_info;
 
     for (i = 0; i < nb_domain; i++) {
         /* no detailed info available on dom0 */
@@ -2342,8 +2336,8 @@ static void list_domains_details(const l
             continue;
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
-        parse_config_data(config_file, (char *)data, len, &d_config, &dm_info);
-        printf_info(info[i].domid, &d_config, &dm_info);
+        parse_config_data(config_file, (char *)data, len, &d_config);
+        printf_info(info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_file);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTH-0001OO-Ul; Mon, 16 Jan 2012 12:15:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTF-00018R-AL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!11
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5942 invoked from network); 16 Jan 2012 12:15:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907096"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dB032155;	Mon, 16 Jan 2012 04:15:20 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9771c7a1959e680ab8ef7de9008232770f04aecd
Message-ID: <9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:19 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 21 of 32 RFC] libxl: drop vfs patch --
 fsback/front were deleted some time ago
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326386958 0
# Node ID 9771c7a1959e680ab8ef7de9008232770f04aecd
# Parent  1e558d62909f4f236bb5edd7019073593564ac31
libxl: drop vfs patch -- fsback/front were deleted some time ago

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1e558d62909f -r 9771c7a1959e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 16:22:39 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 16:49:18 2012 +0000
@@ -793,11 +793,6 @@ retry_transaction:
     xs_set_permissions(ctx->xsh, t,
         libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid),
                        perm, ARRAY_SIZE(perm));
-    xs_mkdir(ctx->xsh, t,
-        libxl__sprintf(gc, "/local/domain/%d/device/vfs", dm_domid));
-    xs_set_permissions(ctx->xsh, t,
-        libxl__sprintf(gc, "/local/domain/%d/device/vfs", dm_domid),
-                       perm, ARRAY_SIZE(perm));
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTI-0001QE-TM; Mon, 16 Jan 2012 12:15:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTF-00018B-6l
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326716120!10604198!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10755 invoked from network); 16 Jan 2012 12:15:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671908"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:20 -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
	q0GCF0dA032155;	Mon, 16 Jan 2012 04:15:19 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1e558d62909f4f236bb5edd7019073593564ac31
Message-ID: <1e558d62909f4f236bb5.1326716118@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 20 of 32 RFC] libxl: remove
	libxl_device_model_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326385359 0
# Node ID 1e558d62909f4f236bb5edd7019073593564ac31
# Parent  c7160a835d3c01b6317551faac90bee4f5b4601c
libxl: remove libxl_device_model_info.

All that is left here is the target domain's domid which we can pass around as
a parameter.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Jan 12 16:22:39 2012 +0000
@@ -2381,7 +2381,7 @@ out:
 }
 
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
-        libxl_device_model_info *dm_info, uint32_t *need_memkb)
+                             uint32_t *need_memkb)
 {
     GC_INIT(ctx);
     int rc = ERROR_INVAL;
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl.h	Thu Jan 12 16:22:39 2012 +0000
@@ -230,7 +230,6 @@ enum {
 typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
-    libxl_device_model_info dm_info;
 
     int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
 
@@ -258,10 +257,6 @@ int libxl_init_create_info(libxl_ctx *ct
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
                           libxl_domain_create_info *c_info);
-int libxl_init_dm_info(libxl_ctx *ctx,
-                       libxl_device_model_info *dm_info,
-                       libxl_domain_create_info *c_info,
-                       libxl_domain_build_info *b_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
@@ -359,7 +354,7 @@ int libxl_set_memory_target(libxl_ctx *c
 int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target);
 /* how much free memory in the system a domain needs to be built */
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
-        libxl_device_model_info *dm_info, uint32_t *need_memkb);
+                             uint32_t *need_memkb);
 /* how much free memory is available in the system */
 int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb);
 /* wait for a given amount of memory to be free in the system */
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 16:22:39 2012 +0000
@@ -55,7 +55,6 @@ void libxl_domain_config_dispose(libxl_d
 
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
-    libxl_device_model_info_dispose(&d_config->dm_info);
 }
 
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
@@ -133,17 +132,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     return 0;
 }
 
-int libxl_init_dm_info(libxl_ctx *ctx,
-                       libxl_device_model_info *dm_info,
-                       libxl_domain_create_info *c_info,
-                       libxl_domain_build_info *b_info)
-{
-    memset(dm_info, '\0', sizeof(*dm_info));
-
-
-    return 0;
-}
-
 static int init_console_info(libxl_device_console *console, int dev_num)
 {
     memset(console, 0x00, sizeof(libxl_device_console));
@@ -157,7 +145,6 @@ static int init_console_info(libxl_devic
 
 int libxl__domain_build(libxl__gc *gc,
                         libxl_domain_build_info *info,
-                        libxl_device_model_info *dm_info,
                         uint32_t domid,
                         libxl__domain_build_state *state)
 {
@@ -173,7 +160,7 @@ int libxl__domain_build(libxl__gc *gc,
 
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        ret = libxl__build_hvm(gc, domid, info, dm_info, state);
+        ret = libxl__build_hvm(gc, domid, info, state);
         if (ret)
             goto out;
 
@@ -227,8 +214,7 @@ out:
 
 static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
                           uint32_t domid, int fd,
-                          libxl__domain_build_state *state,
-                          libxl_device_model_info *dm_info)
+                          libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
@@ -464,7 +450,6 @@ static int do_domain_create(libxl__gc *g
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl_device_model_info *dm_info = &d_config->dm_info;
     libxl__domain_build_state state;
     uint32_t domid;
     int i, ret;
@@ -501,9 +486,9 @@ static int do_domain_create(libxl__gc *g
     memset(&state, 0, sizeof(state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state, dm_info);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, dm_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
     }
 
     if (ret) {
@@ -550,8 +535,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        dm_info->domid = domid;
-        ret = libxl__create_device_model(gc, d_config, dm_info,
+        ret = libxl__create_device_model(gc, domid, d_config,
                                          &state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -564,7 +548,6 @@ static int do_domain_create(libxl__gc *g
     {
         int need_qemu = 0;
         libxl_device_console console;
-        libxl_device_model_info xenpv_dm_info;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
             libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
@@ -586,11 +569,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_console_dispose(&console);
 
         if (need_qemu) {
-            /* only copy those useful configs */
-            memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-
-            libxl__create_xenpv_qemu(gc, domid, d_config,
-                                     &xenpv_dm_info, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
         }
         break;
     }
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 16:22:39 2012 +0000
@@ -81,8 +81,7 @@ static const char *libxl__domain_bios(li
     }
 }
 
-static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config,
-                                    const libxl_device_model_info *info)
+static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config)
 {
     const libxl_vnc_info *vnc = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -93,8 +92,7 @@ static const libxl_vnc_info *dm_vnc(cons
     return vnc && vnc->enable ? vnc : NULL;
 }
 
-static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config,
-                                    const libxl_device_model_info *info)
+static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
 {
     const libxl_sdl_info *sdl = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -105,8 +103,7 @@ static const libxl_sdl_info *dm_sdl(cons
     return sdl && sdl->enable ? sdl : NULL;
 }
 
-static const char *dm_keymap(const libxl_domain_config *guest_config,
-                             const libxl_device_model_info *info)
+static const char *dm_keymap(const libxl_domain_config *guest_config)
 {
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         return guest_config->b_info.u.hvm.keymap;
@@ -117,18 +114,17 @@ static const char *dm_keymap(const libxl
 }
 
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const int num_vifs = guest_config->num_vifs;
-    const char *keymap = dm_keymap(guest_config, info);
+    const char *keymap = dm_keymap(guest_config);
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -137,7 +133,7 @@ static char ** libxl__build_device_model
         return NULL;
 
     flexarray_vappend(dm_args, dm,
-                      "-d", libxl__sprintf(gc, "%d", info->domid), NULL);
+                      "-d", libxl__sprintf(gc, "%d", domid), NULL);
 
     if (c_info->name)
         flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
@@ -233,7 +229,8 @@ static char ** libxl__build_device_model
                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname)
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc,
+                                            "tap%d.%d", domid, vifs[i].devid);
                 else
                     ifname = vifs[i].ifname;
                 flexarray_vappend(dm_args,
@@ -328,9 +325,8 @@ static char *dm_spice_options(libxl__gc 
 }
 
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int guest_domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -340,9 +336,9 @@ static char ** libxl__build_device_model
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
-    const char *keymap = dm_keymap(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config);
+    const char *keymap = dm_keymap(guest_config);
     flexarray_t *dm_args;
     int i;
 
@@ -351,14 +347,14 @@ static char ** libxl__build_device_model
         return NULL;
 
     flexarray_vappend(dm_args, dm,
-                      "-xen-domid", libxl__sprintf(gc, "%d", info->domid), NULL);
+                      "-xen-domid",
+                      libxl__sprintf(gc, "%d", guest_domid), NULL);
 
     flexarray_append(dm_args, "-chardev");
     flexarray_append(dm_args,
                      libxl__sprintf(gc, "socket,id=libxl-cmd,"
                                     "path=%s/qmp-libxl-%d,server,nowait",
-                                    libxl_run_dir_path(),
-                                    info->domid));
+                                    libxl_run_dir_path(), guest_domid));
 
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
@@ -468,7 +464,8 @@ static char ** libxl__build_device_model
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc, "tap%d.%d",
+                                            guest_domid, vifs[i].devid);
                 } else {
                     ifname = vifs[i].ifname;
                 }
@@ -589,18 +586,21 @@ static char ** libxl__build_device_model
 }
 
 static char ** libxl__build_device_model_args(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int guest_domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info, state);
+        return libxl__build_device_model_args_old(gc, dm,
+                                                  guest_domid, guest_config,
+                                                  state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info, state);
+        return libxl__build_device_model_args_new(gc, dm,
+                                                  guest_domid, guest_config,
+                                                  state);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          guest_config->b_info.device_model_version);
@@ -632,7 +632,9 @@ static int libxl__vfb_and_vkb_from_hvm_g
     return 0;
 }
 
-static int libxl__write_dmargs(libxl__gc *gc, int domid, int guest_domid, char **args)
+static int libxl__write_stub_dmargs(libxl__gc *gc,
+                                    int dm_domid, int guest_domid,
+                                    char **args)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i;
@@ -644,7 +646,7 @@ static int libxl__write_dmargs(libxl__gc
 
     roperm[0].id = 0;
     roperm[0].perms = XS_PERM_NONE;
-    roperm[1].id = domid;
+    roperm[1].id = dm_domid;
     roperm[1].perms = XS_PERM_READ;
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/vm", guest_domid));
@@ -681,8 +683,8 @@ retry_transaction:
 }
 
 static int libxl__create_stubdom(libxl__gc *gc,
+                                 int guest_domid,
                                  libxl_domain_config *guest_config,
-                                 libxl_device_model_info *info,
                                  libxl__domain_build_state *d_state,
                                  libxl__spawner_starting **starting_r)
 {
@@ -693,12 +695,11 @@ static int libxl__create_stubdom(libxl__
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
     libxl__domain_build_state stubdom_state;
-    uint32_t domid;
+    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
     libxl__spawner_starting *dm_starting = 0;
-    libxl_device_model_info xenpv_dm_info;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -708,7 +709,8 @@ static int libxl__create_stubdom(libxl__
 
     memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
+    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+                                    libxl__domid_to_name(gc, guest_domid));
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
@@ -721,7 +723,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
+    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
@@ -746,64 +748,74 @@ static int libxl__create_stubdom(libxl__
     dm_config.num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
+    dm_domid = 0;
+    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
     if (ret)
         goto out;
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info, d_state);
+    args = libxl__build_device_model_args(gc, "stubdom-dm", guest_domid,
+                                          guest_config, d_state);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
     }
 
-    libxl__write_dmargs(gc, domid, info->domid, args);
+    libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
     libxl__xs_write(gc, XBT_NULL,
-                   libxl__sprintf(gc, "%s/image/device-model-domid", libxl__xs_get_dompath(gc, info->domid)),
-                   "%d", domid);
+                   libxl__sprintf(gc, "%s/image/device-model-domid",
+                                  libxl__xs_get_dompath(gc, guest_domid)),
+                   "%d", dm_domid);
     libxl__xs_write(gc, XBT_NULL,
-                   libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)),
-                   "%d", info->domid);
-    ret = xc_domain_set_target(ctx->xch, domid, info->domid);
+                   libxl__sprintf(gc, "%s/target",
+                                  libxl__xs_get_dompath(gc, dm_domid)),
+                   "%d", guest_domid);
+    ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
     if (ret<0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting target domain %d -> %d", domid, info->domid);
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "setting target domain %d -> %d",
+                         dm_domid, guest_domid);
         ret = ERROR_FAIL;
         goto out_free;
     }
-    xs_set_target(ctx->xsh, domid, info->domid);
+    xs_set_target(ctx->xsh, dm_domid, guest_domid);
 
-    perm[0].id = domid;
+    perm[0].id = dm_domid;
     perm[0].perms = XS_PERM_NONE;
-    perm[1].id = info->domid;
+    perm[1].id = guest_domid;
     perm[1].perms = XS_PERM_READ;
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
-    xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid));
-    xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid), perm, ARRAY_SIZE(perm));
-    xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/%d/device/vfs", domid));
-    xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/%d/device/vfs",domid), perm, ARRAY_SIZE(perm));
+    xs_mkdir(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid));
+    xs_set_permissions(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid),
+                       perm, ARRAY_SIZE(perm));
+    xs_mkdir(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/%d/device/vfs", dm_domid));
+    xs_set_permissions(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/%d/device/vfs", dm_domid),
+                       perm, ARRAY_SIZE(perm));
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
         if (ret)
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -828,14 +840,14 @@ retry_transaction:
             char *name;
             case STUBDOM_CONSOLE_LOGGING:
                 name = libxl__sprintf(gc, "qemu-dm-%s",
-                                      libxl_domid_to_name(ctx, info->domid));
+                                      libxl_domid_to_name(ctx, guest_domid));
                 libxl_create_logfile(ctx, name, &filename);
                 console[i].output = libxl__sprintf(gc, "file:%s", filename);
                 free(filename);
                 break;
             case STUBDOM_CONSOLE_SAVE:
                 console[i].output = libxl__sprintf(gc, "file:%s",
-                                libxl__device_model_savefile(gc, info->domid));
+                                libxl__device_model_savefile(gc, guest_domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
                 if (d_state->saved_state)
@@ -846,17 +858,14 @@ retry_transaction:
                 console[i].output = "pty";
                 break;
         }
-        ret = libxl__device_console_add(gc, domid, &console[i],
+        ret = libxl__device_console_add(gc, dm_domid, &console[i],
                         i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
-    memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-
-    if (libxl__create_xenpv_qemu(gc, domid,
+    if (libxl__create_xenpv_qemu(gc, dm_domid,
                                  &dm_config,
-                                 &xenpv_dm_info,
                                  &stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
@@ -867,12 +876,12 @@ retry_transaction:
         goto out_free;
     }
 
-    libxl_domain_unpause(ctx, domid);
+    libxl_domain_unpause(ctx, dm_domid);
 
     if (starting_r) {
         *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = info->domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, info->domid);
+        (*starting_r)->domid = guest_domid;
+        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
         (*starting_r)->for_spawn = NULL;
     }
 
@@ -885,15 +894,15 @@ out:
 }
 
 int libxl__create_device_model(libxl__gc *gc,
+                              int domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
@@ -905,7 +914,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (b_info->device_model_stubdomain) {
-        rc = libxl__create_stubdom(gc, guest_config, info, state, starting_r);
+        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
 
@@ -920,18 +929,18 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info, state);
+    args = libxl__build_device_model_args(gc, dm, domid, guest_config, state);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
     }
 
-    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid);
+    path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path),
                     "%s", libxl__domain_bios(gc, b_info));
 
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
                     "%d", !b_info->u.hvm.xen_platform_pci);
@@ -955,8 +964,8 @@ int libxl__create_device_model(libxl__gc
         p->for_spawn = NULL;
     }
 
-    p->domid = info->domid;
-    p->dom_path = libxl__xs_get_dompath(gc, info->domid);
+    p->domid = domid;
+    p->dom_path = libxl__xs_get_dompath(gc, domid);
     p->pid_path = "image/device-model-pid";
     if (!p->dom_path) {
         rc = ERROR_FAIL;
@@ -1078,14 +1087,6 @@ out:
     return ret;
 }
 
-static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
-                                        uint32_t domid,
-                                        libxl_device_model_info *info)
-{
-    info->domid = domid;
-    return 0;
-}
-
 int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1125,12 +1126,10 @@ out:
 
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
-                             libxl_device_model_info *info,
                              libxl__domain_build_state *state,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, info);
-    libxl__create_device_model(gc, guest_config, info, state, starting_r);
+    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
     return 0;
 }
 
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Jan 12 16:22:39 2012 +0000
@@ -288,8 +288,7 @@ static int hvm_build_set_params(xc_inter
 }
 
 static const char *libxl__domain_firmware(libxl__gc *gc,
-                                          libxl_domain_build_info *info,
-                                          libxl_device_model_info *dm_info)
+                                          libxl_domain_build_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *firmware;
@@ -317,12 +316,11 @@ static const char *libxl__domain_firmwar
 
 int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info,
-              libxl_device_model_info *dm_info,
               libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret, rc = ERROR_FAIL;
-    const char *firmware = libxl__domain_firmware(gc, info, dm_info);
+    const char *firmware = libxl__domain_firmware(gc, info);
 
     if (!firmware)
         goto out;
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Jan 12 16:22:39 2012 +0000
@@ -234,7 +234,6 @@ _hidden int libxl__build_pv(libxl__gc *g
              libxl_domain_build_info *info, libxl__domain_build_state *state);
 _hidden int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info,
-              libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
@@ -456,10 +455,11 @@ _hidden void libxl__exec(int stdinfd, in
                const char *arg0, char **args); // logs errors, never returns
 
 /* from xl_create */
-_hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
+_hidden int libxl__domain_make(libxl__gc *gc,
+                               libxl_domain_create_info *info,
+                               uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,
                                 libxl_domain_build_info *info,
-                                libxl_device_model_info *dm_info,
                                 uint32_t domid,
                                 libxl__domain_build_state *state);
 
@@ -467,13 +467,12 @@ _hidden int libxl__domain_build(libxl__g
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
+                              int domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *dm_info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
diff -r c7160a835d3c -r 1e558d62909f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 16:01:40 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 16:22:39 2012 +0000
@@ -289,8 +289,7 @@ static void dolog(const char *file, int 
 }
 
 static void printf_info(int domid,
-                        libxl_domain_config *d_config,
-                        libxl_device_model_info *dm_info)
+                        libxl_domain_config *d_config)
 {
     int i;
     libxl_dominfo info;
@@ -569,8 +568,7 @@ static void split_string_into_string_lis
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
-                              libxl_domain_config *d_config,
-                              libxl_device_model_info *dm_info)
+                              libxl_domain_config *d_config)
 {
     const char *buf;
     long l;
@@ -1110,9 +1108,6 @@ skip_vfb:
         break;
     }
 
-    /* init dm from c and b */
-    if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
-        exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
     if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
@@ -1362,7 +1357,7 @@ struct domain_create {
     char **migration_domname_r; /* from malloc */
 };
 
-static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
+static int freemem(libxl_domain_build_info *b_info)
 {
     int rc, retries = 3;
     uint32_t need_memkb, free_memkb;
@@ -1370,7 +1365,7 @@ static int freemem(libxl_domain_build_in
     if (!autoballoon)
         return 0;
 
-    rc = libxl_domain_need_memory(ctx, b_info, dm_info, &need_memkb);
+    rc = libxl_domain_need_memory(ctx, b_info, &need_memkb);
     if (rc < 0)
         return rc;
 
@@ -1553,7 +1548,7 @@ static int create_domain(struct domain_c
     if (!dom_info->quiet)
         printf("Parsing config file %s\n", config_file);
 
-    parse_config_data(config_file, config_data, config_len, &d_config, &d_config.dm_info);
+    parse_config_data(config_file, config_data, config_len, &d_config);
 
     if (migrate_fd >= 0) {
         if (d_config.c_info.name) {
@@ -1574,7 +1569,7 @@ static int create_domain(struct domain_c
     }
 
     if (debug || dom_info->dryrun)
-        printf_info(-1, &d_config, &d_config.dm_info);
+        printf_info(-1, &d_config);
 
     ret = 0;
     if (dom_info->dryrun)
@@ -1587,7 +1582,7 @@ start:
     if (rc < 0)
         goto error_out;
 
-    ret = freemem(&d_config.b_info, &d_config.dm_info);
+    ret = freemem(&d_config.b_info);
     if (ret < 0) {
         fprintf(stderr, "failed to free memory for the domain\n");
         ret = ERROR_FAIL;
@@ -2331,7 +2326,6 @@ static void list_domains_details(const l
     char *config_file;
     uint8_t *data;
     int i, len, rc;
-    libxl_device_model_info dm_info;
 
     for (i = 0; i < nb_domain; i++) {
         /* no detailed info available on dom0 */
@@ -2342,8 +2336,8 @@ static void list_domains_details(const l
             continue;
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
-        parse_config_data(config_file, (char *)data, len, &d_config, &dm_info);
-        printf_info(info[i].domid, &d_config, &dm_info);
+        parse_config_data(config_file, (char *)data, len, &d_config);
+        printf_info(info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_file);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTH-0001OO-Ul; Mon, 16 Jan 2012 12:15:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTF-00018R-AL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!11
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5942 invoked from network); 16 Jan 2012 12:15:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907096"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:21 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dB032155;	Mon, 16 Jan 2012 04:15:20 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9771c7a1959e680ab8ef7de9008232770f04aecd
Message-ID: <9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:19 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 21 of 32 RFC] libxl: drop vfs patch --
 fsback/front were deleted some time ago
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326386958 0
# Node ID 9771c7a1959e680ab8ef7de9008232770f04aecd
# Parent  1e558d62909f4f236bb5edd7019073593564ac31
libxl: drop vfs patch -- fsback/front were deleted some time ago

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1e558d62909f -r 9771c7a1959e tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 16:22:39 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 16:49:18 2012 +0000
@@ -793,11 +793,6 @@ retry_transaction:
     xs_set_permissions(ctx->xsh, t,
         libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid),
                        perm, ARRAY_SIZE(perm));
-    xs_mkdir(ctx->xsh, t,
-        libxl__sprintf(gc, "/local/domain/%d/device/vfs", dm_domid));
-    xs_set_permissions(ctx->xsh, t,
-        libxl__sprintf(gc, "/local/domain/%d/device/vfs", dm_domid),
-                       perm, ARRAY_SIZE(perm));
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTI-0001PU-Es; Mon, 16 Jan 2012 12:15: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 1RmlTF-00018O-9p
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!10
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5842 invoked from network); 16 Jan 2012 12:15:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907094"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:19 -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
	q0GCF0d9032155;	Mon, 16 Jan 2012 04:15:18 -0800
MIME-Version: 1.0
X-Mercurial-Node: c7160a835d3c01b6317551faac90bee4f5b4601c
Message-ID: <c7160a835d3c01b63175.1326716117@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:17 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 19 of 32 RFC] libxl: move "saved_state" to
 libxl__domain_build_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 1326384100 0
# Node ID c7160a835d3c01b6317551faac90bee4f5b4601c
# Parent  ff41e5fc0f12450cd836ce1466c0c51ab685e04b
libxl: move "saved_state" to libxl__domain_build_state.

This is internal to the library and need not be exposed to the user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r ff41e5fc0f12 -r c7160a835d3c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 15:57:08 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 16:01:40 2012 +0000
@@ -281,9 +281,8 @@ static int domain_restore(libxl__gc *gc,
     if (ret)
         goto out;
 
-    dm_info->saved_state = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&dm_info->saved_state,
+        ret = asprintf(&state->saved_state,
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
         ret = (ret < 0) ? ERROR_FAIL : 0;
     }
@@ -499,13 +498,11 @@ static int do_domain_create(libxl__gc *g
         }
     }
 
+    memset(&state, 0, sizeof(state));
+
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state, dm_info);
     } else {
-        if (dm_info->saved_state) {
-            free(dm_info->saved_state);
-            dm_info->saved_state = NULL;
-        }
         ret = libxl__domain_build(gc, &d_config->b_info, dm_info, domid, &state);
     }
 
@@ -555,7 +552,7 @@ static int do_domain_create(libxl__gc *g
 
         dm_info->domid = domid;
         ret = libxl__create_device_model(gc, d_config, dm_info,
-                                        &dm_starting);
+                                         &state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -592,8 +589,8 @@ static int do_domain_create(libxl__gc *g
             /* only copy those useful configs */
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
 
-            libxl__create_xenpv_qemu(gc, domid,
-                                     d_config, &xenpv_dm_info, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config,
+                                     &xenpv_dm_info, &state, &dm_starting);
         }
         break;
     }
@@ -607,7 +604,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_info, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff -r ff41e5fc0f12 -r c7160a835d3c tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 15:57:08 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 16:01:40 2012 +0000
@@ -119,7 +119,8 @@ static const char *dm_keymap(const libxl
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
@@ -256,8 +257,8 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-nographic");
     }
 
-    if (info->saved_state) {
-        flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
+    if (state->saved_state) {
+        flexarray_vappend(dm_args, "-loadvm", state->saved_state, NULL);
     }
     for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
         flexarray_append(dm_args, b_info->extra[i]);
@@ -329,7 +330,8 @@ static char *dm_spice_options(libxl__gc 
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
@@ -497,9 +499,9 @@ static char ** libxl__build_device_model
         }
     }
 
-    if (info->saved_state) {
+    if (state->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
-        int migration_fd = open(info->saved_state, O_RDONLY);
+        int migration_fd = open(state->saved_state, O_RDONLY);
         flexarray_append(dm_args, "-incoming");
         flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
@@ -589,15 +591,16 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info);
+        return libxl__build_device_model_args_old(gc, dm, guest_config, info, state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info);
+        return libxl__build_device_model_args_new(gc, dm, guest_config, info, state);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          guest_config->b_info.device_model_version);
@@ -680,6 +683,7 @@ retry_transaction:
 static int libxl__create_stubdom(libxl__gc *gc,
                                  libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
+                                 libxl__domain_build_state *d_state,
                                  libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -688,7 +692,7 @@ static int libxl__create_stubdom(libxl__
     libxl_domain_config dm_config;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state state;
+    libxl__domain_build_state stubdom_state;
     uint32_t domid;
     char **args;
     struct xs_permissions perm[2];
@@ -746,12 +750,12 @@ static int libxl__create_stubdom(libxl__
     ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &state);
+    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &stubdom_state);
     if (ret)
         goto out;
 
     args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info);
+                                          guest_config, info, d_state);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
@@ -823,7 +827,8 @@ retry_transaction:
             char *filename;
             char *name;
             case STUBDOM_CONSOLE_LOGGING:
-                name = libxl__sprintf(gc, "qemu-dm-%s", libxl_domid_to_name(ctx, info->domid));
+                name = libxl__sprintf(gc, "qemu-dm-%s",
+                                      libxl_domid_to_name(ctx, info->domid));
                 libxl_create_logfile(ctx, name, &filename);
                 console[i].output = libxl__sprintf(gc, "file:%s", filename);
                 free(filename);
@@ -833,15 +838,16 @@ retry_transaction:
                                 libxl__device_model_savefile(gc, info->domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
-                if (info->saved_state)
-                    console[i].output = libxl__sprintf(gc, "pipe:%s", info->saved_state);
+                if (d_state->saved_state)
+                    console[i].output =
+                        libxl__sprintf(gc, "pipe:%s", d_state->saved_state);
                 break;
             default:
                 console[i].output = "pty";
                 break;
         }
         ret = libxl__device_console_add(gc, domid, &console[i],
-                                    i == STUBDOM_CONSOLE_LOGGING ? &state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
@@ -851,12 +857,12 @@ retry_transaction:
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
                                  &xenpv_dm_info,
+                                 &stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
-    if (libxl__confirm_device_model_startup(gc, &xenpv_dm_info,
-                                            dm_starting) < 0) {
+    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -881,6 +887,7 @@ out:
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -898,7 +905,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (b_info->device_model_stubdomain) {
-        rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
+        rc = libxl__create_stubdom(gc, guest_config, info, state, starting_r);
         goto out;
     }
 
@@ -913,7 +920,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info);
+    args = libxl__build_device_model_args(gc, dm, guest_config, info, state);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
@@ -994,10 +1001,9 @@ out:
 
 
 int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl_device_model_info *dm_info,
+                                libxl__domain_build_state *state,
                                 libxl__spawner_starting *starting)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     int domid = starting->domid;
     int ret, ret2;
@@ -1005,11 +1011,11 @@ int libxl__confirm_device_model_startup(
     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,
+    if (state->saved_state) {
+        ret2 = unlink(state->saved_state);
+        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
                                    "failed to remove device-model state %s\n",
-                                   dm_info->saved_state);
+                                   state->saved_state);
         /* Do not clobber spawn_confirm error code with unlink error code. */
         if (!ret) ret = ret2;
     }
@@ -1120,10 +1126,11 @@ out:
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
+                             libxl__domain_build_state *state,
                              libxl__spawner_starting **starting_r)
 {
     libxl__build_xenpv_qemu_args(gc, domid, info);
-    libxl__create_device_model(gc, guest_config, info, starting_r);
+    libxl__create_device_model(gc, guest_config, info, state, starting_r);
     return 0;
 }
 
diff -r ff41e5fc0f12 -r c7160a835d3c tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 12 15:57:08 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Jan 12 16:01:40 2012 +0000
@@ -220,6 +220,8 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+
+    char *saved_state;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
@@ -467,10 +469,12 @@ _hidden const char *libxl__domain_device
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,
@@ -480,7 +484,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__domain_build_state *state,
                               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,
diff -r ff41e5fc0f12 -r c7160a835d3c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 15:57:08 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 16:01:40 2012 +0000
@@ -269,8 +269,6 @@ libxl_domain_build_info = Struct("domain
 # Device Model Information
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
-    
-    ("saved_state",      string),
     ],
 )
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTJ-0001R3-IE; Mon, 16 Jan 2012 12:15:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTG-00019X-3N
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326716121!2365104!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7201 invoked from network); 16 Jan 2012 12:15:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671914"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:22 -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
	q0GCF0dC032155;	Mon, 16 Jan 2012 04:15:21 -0800
MIME-Version: 1.0
X-Mercurial-Node: fa999f4bcd85526a9ad1a6649f4069497801c5cd
Message-ID: <fa999f4bcd85526a9ad1.1326716120@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:20 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 22 of 32 RFC] libxl: only write "disable_pf" key
 to xenstore when it makes sense
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326387397 0
# Node ID fa999f4bcd85526a9ad1a6649f4069497801c5cd
# Parent  9771c7a1959e680ab8ef7de9008232770f04aecd
libxl: only write "disable_pf" key to xenstore when it makes sense

This key is only used by the traditional qemu-dm when servicing an HVM domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9771c7a1959e -r fa999f4bcd85 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 16:49:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 16:56:37 2012 +0000
@@ -937,8 +937,12 @@ int libxl__create_device_model(libxl__gc
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                    "%d", !b_info->u.hvm.xen_platform_pci);
+
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        b_info->device_model_version
+        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
+        libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
+                        "%d", !b_info->u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTH-0001NO-BL; Mon, 16 Jan 2012 12:15:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTE-00016O-Bx
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326716120!10604198!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10714 invoked from network); 16 Jan 2012 12:15:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671907"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:18 -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
	q0GCF0d8032155;	Mon, 16 Jan 2012 04:15:17 -0800
MIME-Version: 1.0
X-Mercurial-Node: ff41e5fc0f12450cd836ce1466c0c51ab685e04b
Message-ID: <ff41e5fc0f12450cd836.1326716116@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:16 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 18 of 32 RFC] libxl: move device model selection
 variables to b_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326383828 0
# Node ID ff41e5fc0f12450cd836ce1466c0c51ab685e04b
# Parent  20f5a6a37f6aac5eb314262c16e3548e6ab7a2a9
libxl: move device model selection variables to b_info.

Currently we have one set of device model version (and associated) variables.
However we can actually have two device models (stub device model + non-stub PV
device model) which need not necessarily be the same version. Perhaps this
needs more thought.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Jan 12 15:57:08 2012 +0000
@@ -2389,7 +2389,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (dm_info->device_model_stubdomain)
+        if (b_info->device_model_stubdomain)
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 15:57:08 2012 +0000
@@ -84,6 +84,12 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->cpuid = NULL;
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
+
+    b_info->device_model_version =
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+    b_info->device_model_stubdomain = false;
+    b_info->device_model = NULL;
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
@@ -134,9 +140,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 {
     memset(dm_info, '\0', sizeof(*dm_info));
 
-    dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-    dm_info->device_model_stubdomain = false;
-    dm_info->device_model = NULL;
 
     return 0;
 }
@@ -446,14 +449,14 @@ retry_transaction:
 }
 
 static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
-                             libxl_device_model_info *dm_info)
+                             libxl_domain_build_info *b_info)
 {
     char *path = NULL;
 
     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_device_model_version_to_string(dm_info->device_model_version));
+        libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
@@ -512,7 +515,7 @@ static int do_domain_create(libxl__gc *g
         goto error_out;
     }
 
-    store_libxl_entry(gc, domid, dm_info);
+    store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
@@ -588,12 +591,6 @@ static int do_domain_create(libxl__gc *g
         if (need_qemu) {
             /* only copy those useful configs */
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-            xenpv_dm_info.device_model_version =
-                d_config->dm_info.device_model_version;
-            xenpv_dm_info.device_model = d_config->dm_info.device_model;
-            xenpv_dm_info.extra = d_config->dm_info.extra;
-            xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
-            xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
             libxl__create_xenpv_qemu(gc, domid,
                                      d_config, &xenpv_dm_info, &dm_starting);
@@ -606,7 +603,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (dm_starting) {
-        if (dm_info->device_model_version
+        if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(ctx, domid);
         }
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 15:57:08 2012 +0000
@@ -42,7 +42,7 @@ const char *libxl__device_model_savefile
 }
 
 const char *libxl__domain_device_model(libxl__gc *gc,
-                                       libxl_device_model_info *info)
+                                       const libxl_domain_build_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
@@ -72,7 +72,7 @@ const char *libxl__domain_device_model(l
 }
 
 static const char *libxl__domain_bios(libxl__gc *gc,
-                                libxl_device_model_info *info)
+                                const libxl_domain_build_info *info)
 {
     switch (info->device_model_version) {
     case 1: return "rombios";
@@ -259,19 +259,19 @@ static char ** libxl__build_device_model
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
     }
-    for (i = 0; info->extra && info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, info->extra[i]);
+    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
+        flexarray_append(dm_args, b_info->extra[i]);
     flexarray_append(dm_args, "-M");
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
-        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_pv[i]);
+        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_pv[i]);
         break;
     case LIBXL_DOMAIN_TYPE_HVM:
         flexarray_append(dm_args, "xenfv");
-        for (i = 0; info->extra_hvm && info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_hvm[i]);
+        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
     }
     flexarray_append(dm_args, NULL);
@@ -503,19 +503,19 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-incoming");
         flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
-    for (i = 0; info->extra && info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, info->extra[i]);
+    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
+        flexarray_append(dm_args, b_info->extra[i]);
     flexarray_append(dm_args, "-M");
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
-        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_pv[i]);
+        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_pv[i]);
         break;
     case LIBXL_DOMAIN_TYPE_HVM:
         flexarray_append(dm_args, "xenfv");
-        for (i = 0; info->extra_hvm && info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_hvm[i]);
+        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
     }
 
@@ -593,14 +593,14 @@ static char ** libxl__build_device_model
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
-    switch (info->device_model_version) {
+    switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
         return libxl__build_device_model_args_old(gc, dm, guest_config, info);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         return libxl__build_device_model_args_new(gc, dm, guest_config, info);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
-                         info->device_model_version);
+                         guest_config->b_info.device_model_version);
         return NULL;
     }
 }
@@ -696,7 +696,8 @@ static int libxl__create_stubdom(libxl__
     libxl__spawner_starting *dm_starting = 0;
     libxl_device_model_info xenpv_dm_info;
 
-    if (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
+    if (guest_config->b_info.device_model_version !=
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
         ret = ERROR_INVAL;
         goto out;
     }
@@ -720,6 +721,14 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
+    dm_config.b_info.device_model_version =
+        guest_config->b_info.device_model_version;
+    dm_config.b_info.device_model =
+        guest_config->b_info.device_model;
+    dm_config.b_info.extra = guest_config->b_info.extra;
+    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+
     dm_config.disks = guest_config->disks;
     dm_config.num_disks = guest_config->num_disks;
 
@@ -838,11 +847,6 @@ retry_transaction:
     }
 
     memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-    xenpv_dm_info.device_model_version = info->device_model_version;
-    xenpv_dm_info.device_model = info->device_model;
-    xenpv_dm_info.extra = info->extra;
-    xenpv_dm_info.extra_pv = info->extra_pv;
-    xenpv_dm_info.extra_hvm = info->extra_hvm;
 
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
@@ -881,6 +885,7 @@ int libxl__create_device_model(libxl__gc
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     char *path, *logfile;
     int logfile_w, null;
@@ -892,12 +897,12 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (info->device_model_stubdomain) {
+    if (b_info->device_model_stubdomain) {
         rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
         goto out;
     }
 
-    dm = libxl__domain_device_model(gc, info);
+    dm = libxl__domain_device_model(gc, b_info);
     if (!dm) {
         rc = ERROR_FAIL;
         goto out;
@@ -917,12 +922,12 @@ int libxl__create_device_model(libxl__gc
     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),
-                    "%s", libxl__domain_bios(gc, info));
+                    "%s", libxl__domain_bios(gc, b_info));
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                    "%d", !guest_config->b_info.u.hvm.xen_platform_pci);
+                    "%d", !b_info->u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Jan 12 15:57:08 2012 +0000
@@ -297,7 +297,7 @@ static const char *libxl__domain_firmwar
     if (info->u.hvm.firmware)
         firmware = info->u.hvm.firmware;
     else {
-        switch (dm_info->device_model_version)
+        switch (info->device_model_version)
         {
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
             firmware = "hvmloader";
@@ -307,7 +307,7 @@ static const char *libxl__domain_firmwar
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model version %d",
-                       dm_info->device_model_version);
+                       info->device_model_version);
             return NULL;
             break;
         }
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Jan 12 15:57:08 2012 +0000
@@ -463,7 +463,7 @@ _hidden int libxl__domain_build(libxl__g
 
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
-                                               libxl_device_model_info *info);
+                                        const libxl_domain_build_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 15:57:08 2012 +0000
@@ -205,6 +205,19 @@ libxl_domain_build_info = Struct("domain
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
+    
+    ("device_model_version", libxl_device_model_version),
+    ("device_model_stubdomain", bool),
+    # you set device_model you must set device_model_version too
+    ("device_model",     string),
+
+    # extra parameters pass directly to qemu, NULL terminated
+    ("extra",            libxl_string_list),
+    # extra parameters pass directly to qemu for PV guest, NULL terminated
+    ("extra_pv",         libxl_string_list),
+    # extra parameters pass directly to qemu for HVM guest, NULL terminated
+    ("extra_hvm",        libxl_string_list),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
                                        ("pae", bool),
@@ -257,17 +270,7 @@ libxl_domain_build_info = Struct("domain
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
     
-    ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
-    ("device_model",     string),
     ("saved_state",      string),
-    # extra parameters pass directly to qemu, NULL terminated
-    ("extra",            libxl_string_list),
-    # extra parameters pass directly to qemu for PV guest, NULL terminated
-    ("extra_pv",         libxl_string_list),
-    # extra parameters pass directly to qemu for HVM guest, NULL terminated
-    ("extra_hvm",        libxl_string_list),
     ],
 )
 
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 15:57:08 2012 +0000
@@ -378,7 +378,7 @@ static void printf_info(int domid,
                     b_info->u.hvm.spice.disable_ticketing);
         printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
 
-        printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
+        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
@@ -1133,27 +1133,27 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model, 0);
+                            &b_info->device_model, 0);
     if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
-            dm_info->device_model_version
+            b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
         } else if (!strcmp(buf, "qemu-xen")) {
-            dm_info->device_model_version
+            b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
         } else {
             fprintf(stderr,
                     "Unknown device_model_version \"%s\" specified\n", buf);
             exit(1);
         }
-    } else if (dm_info->device_model)
+    } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        dm_info->device_model_stubdomain = l;
+        b_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
-                                    &dm_info->extra##type, 0);            \
+                                    &b_info->extra##type, 0);            \
     if (e && e != ESRCH) {                                                \
         fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
         exit(-ERROR_FAIL);                                                \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTH-0001NO-BL; Mon, 16 Jan 2012 12:15:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTE-00016O-Bx
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326716120!10604198!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10714 invoked from network); 16 Jan 2012 12:15:21 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671907"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:18 -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
	q0GCF0d8032155;	Mon, 16 Jan 2012 04:15:17 -0800
MIME-Version: 1.0
X-Mercurial-Node: ff41e5fc0f12450cd836ce1466c0c51ab685e04b
Message-ID: <ff41e5fc0f12450cd836.1326716116@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:16 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 18 of 32 RFC] libxl: move device model selection
 variables to b_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326383828 0
# Node ID ff41e5fc0f12450cd836ce1466c0c51ab685e04b
# Parent  20f5a6a37f6aac5eb314262c16e3548e6ab7a2a9
libxl: move device model selection variables to b_info.

Currently we have one set of device model version (and associated) variables.
However we can actually have two device models (stub device model + non-stub PV
device model) which need not necessarily be the same version. Perhaps this
needs more thought.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl.c	Thu Jan 12 15:57:08 2012 +0000
@@ -2389,7 +2389,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (dm_info->device_model_stubdomain)
+        if (b_info->device_model_stubdomain)
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_create.c	Thu Jan 12 15:57:08 2012 +0000
@@ -84,6 +84,12 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->cpuid = NULL;
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
+
+    b_info->device_model_version =
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+    b_info->device_model_stubdomain = false;
+    b_info->device_model = NULL;
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
@@ -134,9 +140,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 {
     memset(dm_info, '\0', sizeof(*dm_info));
 
-    dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-    dm_info->device_model_stubdomain = false;
-    dm_info->device_model = NULL;
 
     return 0;
 }
@@ -446,14 +449,14 @@ retry_transaction:
 }
 
 static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
-                             libxl_device_model_info *dm_info)
+                             libxl_domain_build_info *b_info)
 {
     char *path = NULL;
 
     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_device_model_version_to_string(dm_info->device_model_version));
+        libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
@@ -512,7 +515,7 @@ static int do_domain_create(libxl__gc *g
         goto error_out;
     }
 
-    store_libxl_entry(gc, domid, dm_info);
+    store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
@@ -588,12 +591,6 @@ static int do_domain_create(libxl__gc *g
         if (need_qemu) {
             /* only copy those useful configs */
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-            xenpv_dm_info.device_model_version =
-                d_config->dm_info.device_model_version;
-            xenpv_dm_info.device_model = d_config->dm_info.device_model;
-            xenpv_dm_info.extra = d_config->dm_info.extra;
-            xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
-            xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
             libxl__create_xenpv_qemu(gc, domid,
                                      d_config, &xenpv_dm_info, &dm_starting);
@@ -606,7 +603,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (dm_starting) {
-        if (dm_info->device_model_version
+        if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(ctx, domid);
         }
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 15:57:08 2012 +0000
@@ -42,7 +42,7 @@ const char *libxl__device_model_savefile
 }
 
 const char *libxl__domain_device_model(libxl__gc *gc,
-                                       libxl_device_model_info *info)
+                                       const libxl_domain_build_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
@@ -72,7 +72,7 @@ const char *libxl__domain_device_model(l
 }
 
 static const char *libxl__domain_bios(libxl__gc *gc,
-                                libxl_device_model_info *info)
+                                const libxl_domain_build_info *info)
 {
     switch (info->device_model_version) {
     case 1: return "rombios";
@@ -259,19 +259,19 @@ static char ** libxl__build_device_model
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
     }
-    for (i = 0; info->extra && info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, info->extra[i]);
+    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
+        flexarray_append(dm_args, b_info->extra[i]);
     flexarray_append(dm_args, "-M");
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
-        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_pv[i]);
+        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_pv[i]);
         break;
     case LIBXL_DOMAIN_TYPE_HVM:
         flexarray_append(dm_args, "xenfv");
-        for (i = 0; info->extra_hvm && info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_hvm[i]);
+        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
     }
     flexarray_append(dm_args, NULL);
@@ -503,19 +503,19 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-incoming");
         flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
-    for (i = 0; info->extra && info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, info->extra[i]);
+    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
+        flexarray_append(dm_args, b_info->extra[i]);
     flexarray_append(dm_args, "-M");
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
-        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_pv[i]);
+        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_pv[i]);
         break;
     case LIBXL_DOMAIN_TYPE_HVM:
         flexarray_append(dm_args, "xenfv");
-        for (i = 0; info->extra_hvm && info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_hvm[i]);
+        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
     }
 
@@ -593,14 +593,14 @@ static char ** libxl__build_device_model
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
-    switch (info->device_model_version) {
+    switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
         return libxl__build_device_model_args_old(gc, dm, guest_config, info);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         return libxl__build_device_model_args_new(gc, dm, guest_config, info);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
-                         info->device_model_version);
+                         guest_config->b_info.device_model_version);
         return NULL;
     }
 }
@@ -696,7 +696,8 @@ static int libxl__create_stubdom(libxl__
     libxl__spawner_starting *dm_starting = 0;
     libxl_device_model_info xenpv_dm_info;
 
-    if (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
+    if (guest_config->b_info.device_model_version !=
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
         ret = ERROR_INVAL;
         goto out;
     }
@@ -720,6 +721,14 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
+    dm_config.b_info.device_model_version =
+        guest_config->b_info.device_model_version;
+    dm_config.b_info.device_model =
+        guest_config->b_info.device_model;
+    dm_config.b_info.extra = guest_config->b_info.extra;
+    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+
     dm_config.disks = guest_config->disks;
     dm_config.num_disks = guest_config->num_disks;
 
@@ -838,11 +847,6 @@ retry_transaction:
     }
 
     memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-    xenpv_dm_info.device_model_version = info->device_model_version;
-    xenpv_dm_info.device_model = info->device_model;
-    xenpv_dm_info.extra = info->extra;
-    xenpv_dm_info.extra_pv = info->extra_pv;
-    xenpv_dm_info.extra_hvm = info->extra_hvm;
 
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
@@ -881,6 +885,7 @@ int libxl__create_device_model(libxl__gc
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     char *path, *logfile;
     int logfile_w, null;
@@ -892,12 +897,12 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (info->device_model_stubdomain) {
+    if (b_info->device_model_stubdomain) {
         rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
         goto out;
     }
 
-    dm = libxl__domain_device_model(gc, info);
+    dm = libxl__domain_device_model(gc, b_info);
     if (!dm) {
         rc = ERROR_FAIL;
         goto out;
@@ -917,12 +922,12 @@ int libxl__create_device_model(libxl__gc
     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),
-                    "%s", libxl__domain_bios(gc, info));
+                    "%s", libxl__domain_bios(gc, b_info));
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                    "%d", !guest_config->b_info.u.hvm.xen_platform_pci);
+                    "%d", !b_info->u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Thu Jan 12 15:57:08 2012 +0000
@@ -297,7 +297,7 @@ static const char *libxl__domain_firmwar
     if (info->u.hvm.firmware)
         firmware = info->u.hvm.firmware;
     else {
-        switch (dm_info->device_model_version)
+        switch (info->device_model_version)
         {
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
             firmware = "hvmloader";
@@ -307,7 +307,7 @@ static const char *libxl__domain_firmwar
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model version %d",
-                       dm_info->device_model_version);
+                       info->device_model_version);
             return NULL;
             break;
         }
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Thu Jan 12 15:57:08 2012 +0000
@@ -463,7 +463,7 @@ _hidden int libxl__domain_build(libxl__g
 
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
-                                               libxl_device_model_info *info);
+                                        const libxl_domain_build_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Thu Jan 12 15:57:08 2012 +0000
@@ -205,6 +205,19 @@ libxl_domain_build_info = Struct("domain
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
+    
+    ("device_model_version", libxl_device_model_version),
+    ("device_model_stubdomain", bool),
+    # you set device_model you must set device_model_version too
+    ("device_model",     string),
+
+    # extra parameters pass directly to qemu, NULL terminated
+    ("extra",            libxl_string_list),
+    # extra parameters pass directly to qemu for PV guest, NULL terminated
+    ("extra_pv",         libxl_string_list),
+    # extra parameters pass directly to qemu for HVM guest, NULL terminated
+    ("extra_hvm",        libxl_string_list),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
                                        ("pae", bool),
@@ -257,17 +270,7 @@ libxl_domain_build_info = Struct("domain
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
     
-    ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
-    ("device_model",     string),
     ("saved_state",      string),
-    # extra parameters pass directly to qemu, NULL terminated
-    ("extra",            libxl_string_list),
-    # extra parameters pass directly to qemu for PV guest, NULL terminated
-    ("extra_pv",         libxl_string_list),
-    # extra parameters pass directly to qemu for HVM guest, NULL terminated
-    ("extra_hvm",        libxl_string_list),
     ],
 )
 
diff -r 20f5a6a37f6a -r ff41e5fc0f12 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Jan 12 15:50:25 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 12 15:57:08 2012 +0000
@@ -378,7 +378,7 @@ static void printf_info(int domid,
                     b_info->u.hvm.spice.disable_ticketing);
         printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
 
-        printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
+        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
@@ -1133,27 +1133,27 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model, 0);
+                            &b_info->device_model, 0);
     if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
-            dm_info->device_model_version
+            b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
         } else if (!strcmp(buf, "qemu-xen")) {
-            dm_info->device_model_version
+            b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
         } else {
             fprintf(stderr,
                     "Unknown device_model_version \"%s\" specified\n", buf);
             exit(1);
         }
-    } else if (dm_info->device_model)
+    } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        dm_info->device_model_stubdomain = l;
+        b_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
-                                    &dm_info->extra##type, 0);            \
+                                    &b_info->extra##type, 0);            \
     if (e && e != ESRCH) {                                                \
         fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
         exit(-ERROR_FAIL);                                                \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTJ-0001R3-IE; Mon, 16 Jan 2012 12:15:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTG-00019X-3N
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326716121!2365104!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7201 invoked from network); 16 Jan 2012 12:15:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671914"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:22 -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
	q0GCF0dC032155;	Mon, 16 Jan 2012 04:15:21 -0800
MIME-Version: 1.0
X-Mercurial-Node: fa999f4bcd85526a9ad1a6649f4069497801c5cd
Message-ID: <fa999f4bcd85526a9ad1.1326716120@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:20 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 22 of 32 RFC] libxl: only write "disable_pf" key
 to xenstore when it makes sense
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326387397 0
# Node ID fa999f4bcd85526a9ad1a6649f4069497801c5cd
# Parent  9771c7a1959e680ab8ef7de9008232770f04aecd
libxl: only write "disable_pf" key to xenstore when it makes sense

This key is only used by the traditional qemu-dm when servicing an HVM domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9771c7a1959e -r fa999f4bcd85 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 16:49:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 16:56:37 2012 +0000
@@ -937,8 +937,12 @@ int libxl__create_device_model(libxl__gc
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                    "%d", !b_info->u.hvm.xen_platform_pci);
+
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        b_info->device_model_version
+        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
+        libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
+                        "%d", !b_info->u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTK-0001TV-Ps; Mon, 16 Jan 2012 12:15:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTG-0001AA-HG
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326716120!10604198!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10865 invoked from network); 16 Jan 2012 12:15:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671915"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:23 -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
	q0GCF0dD032155;	Mon, 16 Jan 2012 04:15:22 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0d3abdb6c01894e4e07400317a0b49433dbaf1a5
Message-ID: <0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:21 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 23 of 32 RFC] libxl: use libxl_*_init internally
	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326388309 0
# Node ID 0d3abdb6c01894e4e07400317a0b49433dbaf1a5
# Parent  fa999f4bcd85526a9ad1a6649f4069497801c5cd
libxl: use libxl_*_init internally too

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r fa999f4bcd85 -r 0d3abdb6c018 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 16:56:37 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 17:11:49 2012 +0000
@@ -614,12 +614,16 @@ static int libxl__vfb_and_vkb_from_hvm_g
                                         libxl_device_vkb *vkb)
 {
     const libxl_domain_build_info *b_info = &guest_config->b_info;
+    int ret;
 
     if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
         return ERROR_INVAL;
 
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
+    ret = libxl_device_vfb_init(CTX, vfb);
+    if (ret) return ret;
+
+    ret = libxl_device_vkb_init(CTX, vkb);
+    if (ret) return ret;
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
@@ -707,14 +711,18 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    ret = libxl_init_create_info(CTX, &dm_config.c_info);
+    if (ret) goto out;
+
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    ret = libxl_init_build_info(CTX, &dm_config.b_info, &dm_config.c_info);
+    if (ret) goto out;
+
     dm_config.b_info.type = dm_config.c_info.type;
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTK-0001TV-Ps; Mon, 16 Jan 2012 12:15:34 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTG-0001AA-HG
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326716120!10604198!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10865 invoked from network); 16 Jan 2012 12:15:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671915"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:23 -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
	q0GCF0dD032155;	Mon, 16 Jan 2012 04:15:22 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0d3abdb6c01894e4e07400317a0b49433dbaf1a5
Message-ID: <0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:21 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 23 of 32 RFC] libxl: use libxl_*_init internally
	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326388309 0
# Node ID 0d3abdb6c01894e4e07400317a0b49433dbaf1a5
# Parent  fa999f4bcd85526a9ad1a6649f4069497801c5cd
libxl: use libxl_*_init internally too

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r fa999f4bcd85 -r 0d3abdb6c018 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Thu Jan 12 16:56:37 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Thu Jan 12 17:11:49 2012 +0000
@@ -614,12 +614,16 @@ static int libxl__vfb_and_vkb_from_hvm_g
                                         libxl_device_vkb *vkb)
 {
     const libxl_domain_build_info *b_info = &guest_config->b_info;
+    int ret;
 
     if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
         return ERROR_INVAL;
 
-    memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    memset(vkb, 0x00, sizeof(libxl_device_vkb));
+    ret = libxl_device_vfb_init(CTX, vfb);
+    if (ret) return ret;
+
+    ret = libxl_device_vkb_init(CTX, vkb);
+    if (ret) return ret;
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
@@ -707,14 +711,18 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    ret = libxl_init_create_info(CTX, &dm_config.c_info);
+    if (ret) goto out;
+
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
                                     libxl__domid_to_name(gc, guest_domid));
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
-    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    ret = libxl_init_build_info(CTX, &dm_config.b_info, &dm_config.c_info);
+    if (ret) goto out;
+
     dm_config.b_info.type = dm_config.c_info.type;
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTP-0001dz-1A; Mon, 16 Jan 2012 12:15:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTH-0001BR-6q
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!12
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 16 Jan 2012 12:15:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907099"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dE032155;	Mon, 16 Jan 2012 04:15:23 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7e9f3ce2cd1f05ae30727bed05f295c7fdfbb2ea
Message-ID: <7e9f3ce2cd1f05ae3072.1326716122@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:22 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 24 of 32 RFC] libxl: add new "defbool" built in
	type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326470399 0
# Node ID 7e9f3ce2cd1f05ae30727bed05f295c7fdfbb2ea
# Parent  0d3abdb6c01894e4e07400317a0b49433dbaf1a5
libxl: add new "defbool" built in type.

This type is a but like a "boolean" but with a third state "default" (so really
I suppose its a tristate).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/gentest.py	Fri Jan 13 15:59:59 2012 +0000
@@ -19,7 +19,8 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
+             "libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list", "libxl_cpuarray"]
 
@@ -54,6 +55,8 @@ def gen_rand_init(ty, v, indent = "    "
               ty.pass_arg(v, parent is None))
     elif ty.typename in ["bool"]:
         s += "%s = rand() %% 2;\n" % v
+    elif ty.typename in ["libxl_defbool"]:
+        s += "libxl_defbool_set(%s, !!rand() %% 1);\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
     elif ty.private:
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxl.c	Fri Jan 13 15:59:59 2012 +0000
@@ -126,6 +126,47 @@ void libxl_key_value_list_dispose(libxl_
     free(kvl);
 }
 
+#define LIBXL__DEFBOOL_DEFAULT (0)
+#define LIBXL__DEFBOOL_FALSE (-1)
+#define LIBXL__DEFBOOL_TRUE (1)
+
+void libxl_defbool_set(libxl_defbool *db, bool b)
+{
+    db->val = b ? LIBXL__DEFBOOL_TRUE : LIBXL__DEFBOOL_FALSE;
+}
+
+void libxl_defbool_unset(libxl_defbool *db)
+{
+    db->val = LIBXL__DEFBOOL_DEFAULT;
+}
+
+bool libxl_defbool_is_default(libxl_defbool db)
+{
+    return !db.val;
+}
+
+void libxl_defbool_setdefault(libxl_defbool *db, bool b)
+{
+    if (libxl_defbool_is_default(*db))
+        libxl_defbool_set(db, b);
+}
+
+bool libxl_defbool_val(libxl_defbool db)
+{
+    assert(!libxl_defbool_is_default(db));
+    return db.val > 0;
+}
+
+const char *libxl_defbool_to_string(libxl_defbool b)
+{
+    if (b.val < 0)
+        return "False";
+    else if (b.val > 0)
+        return "True";
+    else
+        return "<default>";
+}
+
 /******************************************************************************/
 
 
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxl.h	Fri Jan 13 15:59:59 2012 +0000
@@ -199,6 +199,30 @@ typedef struct {
     int v;
 } libxl_enum_string_table;
 
+/*
+ * A boolean variable with an explicit default state.
+ *
+ * Users should treat this struct as opaque and use the following
+ * defined macros and accessor functions.
+ *
+ * To allow users of the library to naively select all defaults this
+ * state is represented as 0. False is < 0 and True is > 0.
+ */
+typedef struct {
+    int val;
+} libxl_defbool;
+
+void libxl_defbool_set(libxl_defbool *db, bool b);
+/* Resets to default */
+void libxl_defbool_unset(libxl_defbool *db);
+/* Sets db only if it is currently == default */
+void libxl_defbool_setdefault(libxl_defbool *db, bool b);
+bool libxl_defbool_is_default(libxl_defbool db);
+/* db must not be == default */
+bool libxl_defbool_val(libxl_defbool db);
+
+const char *libxl_defbool_to_string(libxl_defbool b);
+
 typedef struct libxl__ctx libxl_ctx;
 
 #include "_libxl_types.h"
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxl_json.c	Fri Jan 13 15:59:59 2012 +0000
@@ -87,6 +87,12 @@ yajl_gen_status libxl__yajl_gen_enum(yaj
 /*
  * YAJL generators for builtin libxl types.
  */
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand,
+                                       libxl_defbool *db)
+{
+    return libxl__yajl_gen_asciiz(hand, libxl_defbool_to_string(*db));
+}
+
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand,
                                     libxl_uuid *uuid)
 {
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Jan 13 15:59:59 2012 +0000
@@ -5,6 +5,8 @@
 
 namespace("libxl_")
 
+libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
+
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxlu_cfg.c	Fri Jan 13 15:59:59 2012 +0000
@@ -235,6 +235,17 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, libxl_defbool *b,
+                     int dont_warn)
+{
+    int ret;
+    long l;
+
+    ret = xlu_cfg_get_long(cfg, n, &l, dont_warn);
+    if (ret) return ret;
+    libxl_defbool_set(b, !!l);
+    return 0;
+}
 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxlutil.h	Fri Jan 13 15:59:59 2012 +0000
@@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
                            char **value_r, int dont_warn);
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
                      int dont_warn);
+int xlu_cfg_get_defbool(const XLU_Config*, const char *n, libxl_defbool *b,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTP-0001dz-1A; Mon, 16 Jan 2012 12:15:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTH-0001BR-6q
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!12
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6081 invoked from network); 16 Jan 2012 12:15:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907099"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dE032155;	Mon, 16 Jan 2012 04:15:23 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7e9f3ce2cd1f05ae30727bed05f295c7fdfbb2ea
Message-ID: <7e9f3ce2cd1f05ae3072.1326716122@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:22 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 24 of 32 RFC] libxl: add new "defbool" built in
	type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326470399 0
# Node ID 7e9f3ce2cd1f05ae30727bed05f295c7fdfbb2ea
# Parent  0d3abdb6c01894e4e07400317a0b49433dbaf1a5
libxl: add new "defbool" built in type.

This type is a but like a "boolean" but with a third state "default" (so really
I suppose its a tristate).

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/gentest.py	Fri Jan 13 15:59:59 2012 +0000
@@ -19,7 +19,8 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
+             "libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list", "libxl_cpuarray"]
 
@@ -54,6 +55,8 @@ def gen_rand_init(ty, v, indent = "    "
               ty.pass_arg(v, parent is None))
     elif ty.typename in ["bool"]:
         s += "%s = rand() %% 2;\n" % v
+    elif ty.typename in ["libxl_defbool"]:
+        s += "libxl_defbool_set(%s, !!rand() %% 1);\n" % v
     elif ty.typename in ["char *"]:
         s += "%s = rand_str();\n" % v
     elif ty.private:
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxl.c	Fri Jan 13 15:59:59 2012 +0000
@@ -126,6 +126,47 @@ void libxl_key_value_list_dispose(libxl_
     free(kvl);
 }
 
+#define LIBXL__DEFBOOL_DEFAULT (0)
+#define LIBXL__DEFBOOL_FALSE (-1)
+#define LIBXL__DEFBOOL_TRUE (1)
+
+void libxl_defbool_set(libxl_defbool *db, bool b)
+{
+    db->val = b ? LIBXL__DEFBOOL_TRUE : LIBXL__DEFBOOL_FALSE;
+}
+
+void libxl_defbool_unset(libxl_defbool *db)
+{
+    db->val = LIBXL__DEFBOOL_DEFAULT;
+}
+
+bool libxl_defbool_is_default(libxl_defbool db)
+{
+    return !db.val;
+}
+
+void libxl_defbool_setdefault(libxl_defbool *db, bool b)
+{
+    if (libxl_defbool_is_default(*db))
+        libxl_defbool_set(db, b);
+}
+
+bool libxl_defbool_val(libxl_defbool db)
+{
+    assert(!libxl_defbool_is_default(db));
+    return db.val > 0;
+}
+
+const char *libxl_defbool_to_string(libxl_defbool b)
+{
+    if (b.val < 0)
+        return "False";
+    else if (b.val > 0)
+        return "True";
+    else
+        return "<default>";
+}
+
 /******************************************************************************/
 
 
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxl.h	Fri Jan 13 15:59:59 2012 +0000
@@ -199,6 +199,30 @@ typedef struct {
     int v;
 } libxl_enum_string_table;
 
+/*
+ * A boolean variable with an explicit default state.
+ *
+ * Users should treat this struct as opaque and use the following
+ * defined macros and accessor functions.
+ *
+ * To allow users of the library to naively select all defaults this
+ * state is represented as 0. False is < 0 and True is > 0.
+ */
+typedef struct {
+    int val;
+} libxl_defbool;
+
+void libxl_defbool_set(libxl_defbool *db, bool b);
+/* Resets to default */
+void libxl_defbool_unset(libxl_defbool *db);
+/* Sets db only if it is currently == default */
+void libxl_defbool_setdefault(libxl_defbool *db, bool b);
+bool libxl_defbool_is_default(libxl_defbool db);
+/* db must not be == default */
+bool libxl_defbool_val(libxl_defbool db);
+
+const char *libxl_defbool_to_string(libxl_defbool b);
+
 typedef struct libxl__ctx libxl_ctx;
 
 #include "_libxl_types.h"
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxl_json.c	Fri Jan 13 15:59:59 2012 +0000
@@ -87,6 +87,12 @@ yajl_gen_status libxl__yajl_gen_enum(yaj
 /*
  * YAJL generators for builtin libxl types.
  */
+yajl_gen_status libxl_defbool_gen_json(yajl_gen hand,
+                                       libxl_defbool *db)
+{
+    return libxl__yajl_gen_asciiz(hand, libxl_defbool_to_string(*db));
+}
+
 yajl_gen_status libxl_uuid_gen_json(yajl_gen hand,
                                     libxl_uuid *uuid)
 {
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Jan 13 15:59:59 2012 +0000
@@ -5,6 +5,8 @@
 
 namespace("libxl_")
 
+libxl_defbool = Builtin("defbool", passby=PASS_BY_REFERENCE)
+
 libxl_domid = Builtin("domid", json_fn = "yajl_gen_integer", autogenerate_json = False)
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxlu_cfg.c	Fri Jan 13 15:59:59 2012 +0000
@@ -235,6 +235,17 @@ int xlu_cfg_get_long(const XLU_Config *c
     return 0;
 }
 
+int xlu_cfg_get_defbool(const XLU_Config *cfg, const char *n, libxl_defbool *b,
+                     int dont_warn)
+{
+    int ret;
+    long l;
+
+    ret = xlu_cfg_get_long(cfg, n, &l, dont_warn);
+    if (ret) return ret;
+    libxl_defbool_set(b, !!l);
+    return 0;
+}
 
 int xlu_cfg_get_list(const XLU_Config *cfg, const char *n,
                      XLU_ConfigList **list_r, int *entries_r, int dont_warn) {
diff -r 0d3abdb6c018 -r 7e9f3ce2cd1f tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h	Thu Jan 12 17:11:49 2012 +0000
+++ b/tools/libxl/libxlutil.h	Fri Jan 13 15:59:59 2012 +0000
@@ -52,6 +52,8 @@ int xlu_cfg_replace_string(const XLU_Con
                            char **value_r, int dont_warn);
 int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
                      int dont_warn);
+int xlu_cfg_get_defbool(const XLU_Config*, const char *n, libxl_defbool *b,
+                     int dont_warn);
 
 int xlu_cfg_get_list(const XLU_Config*, const char *n,
                      XLU_ConfigList **list_r /* may be 0 */,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTQ-0001g9-3K; Mon, 16 Jan 2012 12:15:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTI-0001Cr-8D
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!13
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6130 invoked from network); 16 Jan 2012 12:15:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907100"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dF032155;	Mon, 16 Jan 2012 04:15:24 -0800
MIME-Version: 1.0
X-Mercurial-Node: 87c469583499236e6a524f9c9271323ae91394fe
Message-ID: <87c469583499236e6a52.1326716123@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 25 of 32 RFC] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326470400 0
# Node ID 87c469583499236e6a524f9c9271323ae91394fe
# Parent  7e9f3ce2cd1f05ae30727bed05f295c7fdfbb2ea
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

All members of libxl_domain_create_info are now "0 == default".

It doesn't seem reasonble for the library to pick a default for the domain type
so reject as invalid.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/gentest.py	Fri Jan 13 16:00:00 2012 +0000
@@ -19,8 +19,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
-             "libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list", "libxl_cpuarray"]
 
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/libxl_create.c	Fri Jan 13 16:00:00 2012 +0000
@@ -60,13 +60,20 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->xsdata = NULL;
-    c_info->platformdata = NULL;
-    c_info->hap = 1;
-    c_info->type = LIBXL_DOMAIN_TYPE_HVM;
-    c_info->oos = 1;
-    c_info->ssidref = 0;
-    c_info->poolid = 0;
+    return 0;
+}
+
+int libxl__domain_create_info_setdefaults(libxl__gc *gc,
+                                          libxl_domain_create_info *c_info)
+{
+    if (!c_info->type)
+        return ERROR_INVAL;
+
+    if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        libxl_defbool_setdefault(&c_info->hap, true);
+        libxl_defbool_setdefault(&c_info->oos, true);
+    }
+
     return 0;
 }
 
@@ -325,8 +332,8 @@ int libxl__domain_make(libxl__gc *gc, li
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
-        flags |= info->hap ? XEN_DOMCTL_CDF_hap : 0;
-        flags |= info->oos ? 0 : XEN_DOMCTL_CDF_oos_off;
+        flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+        flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
     *domid = -1;
 
@@ -456,6 +463,9 @@ static int do_domain_create(libxl__gc *g
 
     domid = 0;
 
+    ret = libxl__domain_create_info_setdefaults(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Jan 13 16:00:00 2012 +0000
@@ -749,6 +749,9 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
+    ret = libxl__domain_create_info_setdefaults(gc, &dm_config.c_info);
+    if (ret) goto out;
+
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Jan 13 16:00:00 2012 +0000
@@ -224,6 +224,15 @@ typedef struct {
     char *saved_state;
 } libxl__domain_build_state;
 
+/*
+ * Idempotently set the defaults for various user provided data structures.
+ *
+ * All libxl API functions are expected to have arranged for this to
+ * be called before using any values within these structures.
+ */
+int libxl__domain_create_info_setdefaults(libxl__gc *gc,
+                                          libxl_domain_create_info *c_info);
+
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info, libxl__domain_build_state *state);
 _hidden int libxl__build_post(libxl__gc *gc, uint32_t domid,
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Jan 13 16:00:00 2012 +0000
@@ -180,8 +180,8 @@ libxl_version_info = Struct("version_inf
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
-    ("hap",          bool),
-    ("oos",          bool),
+    ("hap",          libxl_defbool),
+    ("oos",          libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jan 13 16:00:00 2012 +0000
@@ -300,8 +300,8 @@ static void printf_info(int domid,
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
+    printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 
@@ -614,8 +614,7 @@ static void parse_config_data(const char
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l, 0))
-        c_info->hap = l;
+    xlu_cfg_get_defbool(config, "hap", &c_info->hap, 0);
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.");
@@ -631,8 +630,7 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l, 0))
-        c_info->oos = l;
+    xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/python/genwrap.py	Fri Jan 13 16:00:00 2012 +0000
@@ -4,11 +4,13 @@ import sys,os
 
 import libxltypes
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
 
 def py_type(ty):
     if ty == libxltypes.bool:
         return TYPE_BOOL
+    if ty.typename == "libxl_defbool":
+        return TYPE_DEFBOOL
     if isinstance(ty, libxltypes.Enumeration):
         return TYPE_UINT
     if isinstance(ty, libxltypes.Number):
@@ -44,6 +46,8 @@ def py_decls(ty):
         for f in ty.fields:
             if py_type(f.type) is not None:
                 continue
+            if py_type(f.type) == TYPE_DEFBOOL:
+                continue
             if ty.marshal_out():
                 l.append('_hidden PyObject *attrib__%s_get(%s *%s);'%(\
                     fsanitize(f.type.typename), f.type.typename, f.name))
@@ -62,6 +66,8 @@ def py_attrib_get(ty, f):
         l.append('    ret = (self->obj.%s) ? Py_True : Py_False;'%f.name)
         l.append('    Py_INCREF(ret);')
         l.append('    return ret;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_get(&self->obj.%s);'%f.name)
     elif t == TYPE_INT:
         l.append('    return genwrap__ll_get(self->obj.%s);'%f.name)
     elif t == TYPE_UINT:
@@ -85,6 +91,8 @@ def py_attrib_set(ty, f):
     if t == TYPE_BOOL:
         l.append('    self->obj.%s = (NULL == v || Py_None == v || Py_False == v) ? 0 : 1;'%f.name)
         l.append('    return 0;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_set(v, &self->obj.%s);'%f.name)
     elif t == TYPE_UINT or t == TYPE_INT:
         l.append('    %slong long tmp;'%(t == TYPE_UINT and 'unsigned ' or ''))
         l.append('    int ret;')
@@ -276,6 +284,8 @@ _hidden PyObject *genwrap__ull_get(unsig
 _hidden int genwrap__ull_set(PyObject *v, unsigned long long *val, unsigned long long mask);
 _hidden PyObject *genwrap__ll_get(long long val);
 _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
+_hidden PyObject *genwrap__defbool_get(libxl_defbool *db);
+_hidden int genwrap__defbool_set(PyObject *v, libxl_defbool *db);
 
 """ % " ".join(sys.argv))
     for ty in [ty for ty in types if isinstance(ty, libxltypes.Aggregate)]:
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Fri Jan 13 16:00:00 2012 +0000
@@ -156,6 +156,21 @@ int genwrap__ll_set(PyObject *v, long lo
     return 0;
 }
 
+PyObject *genwrap__defbool_get(libxl_defbool *db)
+{
+    PyObject *ret;
+    ret = libxl_defbool_val(*db) ? Py_True : Py_False;
+    Py_INCREF(ret);
+    return ret;
+}
+
+int genwrap__defbool_set(PyObject *v, libxl_defbool *db)
+{
+    bool val = !(NULL == v || Py_None == v || Py_False == v);
+    libxl_defbool_set(db, val);
+    return 0;
+}
+
 static int fixed_bytearray_set(PyObject *v, uint8_t *ptr, size_t len)
 {
     char *tmp;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTQ-0001g9-3K; Mon, 16 Jan 2012 12:15:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTI-0001Cr-8D
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!13
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6130 invoked from network); 16 Jan 2012 12:15:25 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907100"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dF032155;	Mon, 16 Jan 2012 04:15:24 -0800
MIME-Version: 1.0
X-Mercurial-Node: 87c469583499236e6a524f9c9271323ae91394fe
Message-ID: <87c469583499236e6a52.1326716123@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 25 of 32 RFC] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326470400 0
# Node ID 87c469583499236e6a524f9c9271323ae91394fe
# Parent  7e9f3ce2cd1f05ae30727bed05f295c7fdfbb2ea
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

All members of libxl_domain_create_info are now "0 == default".

It doesn't seem reasonble for the library to pick a default for the domain type
so reject as invalid.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/gentest.py	Fri Jan 13 16:00:00 2012 +0000
@@ -19,8 +19,7 @@ def randomize_case(s):
 def randomize_enum(e):
     return random.choice([v.name for v in e.values])
 
-handcoded = ["libxl_defbool", # Temp until a user appears in the next patch
-             "libxl_cpumap", "libxl_key_value_list",
+handcoded = ["libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
              "libxl_string_list", "libxl_cpuarray"]
 
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/libxl_create.c	Fri Jan 13 16:00:00 2012 +0000
@@ -60,13 +60,20 @@ void libxl_domain_config_dispose(libxl_d
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
 {
     memset(c_info, '\0', sizeof(*c_info));
-    c_info->xsdata = NULL;
-    c_info->platformdata = NULL;
-    c_info->hap = 1;
-    c_info->type = LIBXL_DOMAIN_TYPE_HVM;
-    c_info->oos = 1;
-    c_info->ssidref = 0;
-    c_info->poolid = 0;
+    return 0;
+}
+
+int libxl__domain_create_info_setdefaults(libxl__gc *gc,
+                                          libxl_domain_create_info *c_info)
+{
+    if (!c_info->type)
+        return ERROR_INVAL;
+
+    if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        libxl_defbool_setdefault(&c_info->hap, true);
+        libxl_defbool_setdefault(&c_info->oos, true);
+    }
+
     return 0;
 }
 
@@ -325,8 +332,8 @@ int libxl__domain_make(libxl__gc *gc, li
     flags = 0;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         flags |= XEN_DOMCTL_CDF_hvm_guest;
-        flags |= info->hap ? XEN_DOMCTL_CDF_hap : 0;
-        flags |= info->oos ? 0 : XEN_DOMCTL_CDF_oos_off;
+        flags |= libxl_defbool_val(info->hap) ? XEN_DOMCTL_CDF_hap : 0;
+        flags |= libxl_defbool_val(info->oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
     }
     *domid = -1;
 
@@ -456,6 +463,9 @@ static int do_domain_create(libxl__gc *g
 
     domid = 0;
 
+    ret = libxl__domain_create_info_setdefaults(gc, &d_config->c_info);
+    if (ret) goto error_out;
+
     ret = libxl__domain_make(gc, &d_config->c_info, &domid);
     if (ret) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot make domain: %d", ret);
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Jan 13 16:00:00 2012 +0000
@@ -749,6 +749,9 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
+    ret = libxl__domain_create_info_setdefaults(gc, &dm_config.c_info);
+    if (ret) goto out;
+
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Jan 13 16:00:00 2012 +0000
@@ -224,6 +224,15 @@ typedef struct {
     char *saved_state;
 } libxl__domain_build_state;
 
+/*
+ * Idempotently set the defaults for various user provided data structures.
+ *
+ * All libxl API functions are expected to have arranged for this to
+ * be called before using any values within these structures.
+ */
+int libxl__domain_create_info_setdefaults(libxl__gc *gc,
+                                          libxl_domain_create_info *c_info);
+
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info, libxl__domain_build_state *state);
 _hidden int libxl__build_post(libxl__gc *gc, uint32_t domid,
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Jan 13 16:00:00 2012 +0000
@@ -180,8 +180,8 @@ libxl_version_info = Struct("version_inf
 
 libxl_domain_create_info = Struct("domain_create_info",[
     ("type",         libxl_domain_type),
-    ("hap",          bool),
-    ("oos",          bool),
+    ("hap",          libxl_defbool),
+    ("oos",          libxl_defbool),
     ("ssidref",      uint32),
     ("name",         string),
     ("uuid",         libxl_uuid),
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jan 13 16:00:00 2012 +0000
@@ -300,8 +300,8 @@ static void printf_info(int domid,
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(hap %s)\n", libxl_defbool_to_string(c_info->hap));
+    printf("\t(oos %s)\n", libxl_defbool_to_string(c_info->oos));
     printf("\t(ssidref %d)\n", c_info->ssidref);
     printf("\t(name %s)\n", c_info->name);
 
@@ -614,8 +614,7 @@ static void parse_config_data(const char
         !strncmp(buf, "hvm", strlen(buf)))
         c_info->type = LIBXL_DOMAIN_TYPE_HVM;
 
-    if (!xlu_cfg_get_long (config, "hap", &l, 0))
-        c_info->hap = l;
+    xlu_cfg_get_defbool(config, "hap", &c_info->hap, 0);
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
         fprintf(stderr, "Domain name must be specified.");
@@ -631,8 +630,7 @@ static void parse_config_data(const char
         libxl_uuid_generate(&c_info->uuid);
     }
 
-    if (!xlu_cfg_get_long(config, "oos", &l, 0))
-        c_info->oos = l;
+    xlu_cfg_get_defbool(config, "oos", &c_info->oos, 0);
 
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
         c_info->poolid = -1;
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/python/genwrap.py
--- a/tools/python/genwrap.py	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/python/genwrap.py	Fri Jan 13 16:00:00 2012 +0000
@@ -4,11 +4,13 @@ import sys,os
 
 import libxltypes
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
+(TYPE_DEFBOOL, TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(6)
 
 def py_type(ty):
     if ty == libxltypes.bool:
         return TYPE_BOOL
+    if ty.typename == "libxl_defbool":
+        return TYPE_DEFBOOL
     if isinstance(ty, libxltypes.Enumeration):
         return TYPE_UINT
     if isinstance(ty, libxltypes.Number):
@@ -44,6 +46,8 @@ def py_decls(ty):
         for f in ty.fields:
             if py_type(f.type) is not None:
                 continue
+            if py_type(f.type) == TYPE_DEFBOOL:
+                continue
             if ty.marshal_out():
                 l.append('_hidden PyObject *attrib__%s_get(%s *%s);'%(\
                     fsanitize(f.type.typename), f.type.typename, f.name))
@@ -62,6 +66,8 @@ def py_attrib_get(ty, f):
         l.append('    ret = (self->obj.%s) ? Py_True : Py_False;'%f.name)
         l.append('    Py_INCREF(ret);')
         l.append('    return ret;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_get(&self->obj.%s);'%f.name)
     elif t == TYPE_INT:
         l.append('    return genwrap__ll_get(self->obj.%s);'%f.name)
     elif t == TYPE_UINT:
@@ -85,6 +91,8 @@ def py_attrib_set(ty, f):
     if t == TYPE_BOOL:
         l.append('    self->obj.%s = (NULL == v || Py_None == v || Py_False == v) ? 0 : 1;'%f.name)
         l.append('    return 0;')
+    elif t == TYPE_DEFBOOL:
+        l.append('    return genwrap__defbool_set(v, &self->obj.%s);'%f.name)
     elif t == TYPE_UINT or t == TYPE_INT:
         l.append('    %slong long tmp;'%(t == TYPE_UINT and 'unsigned ' or ''))
         l.append('    int ret;')
@@ -276,6 +284,8 @@ _hidden PyObject *genwrap__ull_get(unsig
 _hidden int genwrap__ull_set(PyObject *v, unsigned long long *val, unsigned long long mask);
 _hidden PyObject *genwrap__ll_get(long long val);
 _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
+_hidden PyObject *genwrap__defbool_get(libxl_defbool *db);
+_hidden int genwrap__defbool_set(PyObject *v, libxl_defbool *db);
 
 """ % " ".join(sys.argv))
     for ty in [ty for ty in types if isinstance(ty, libxltypes.Aggregate)]:
diff -r 7e9f3ce2cd1f -r 87c469583499 tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c	Fri Jan 13 15:59:59 2012 +0000
+++ b/tools/python/xen/lowlevel/xl/xl.c	Fri Jan 13 16:00:00 2012 +0000
@@ -156,6 +156,21 @@ int genwrap__ll_set(PyObject *v, long lo
     return 0;
 }
 
+PyObject *genwrap__defbool_get(libxl_defbool *db)
+{
+    PyObject *ret;
+    ret = libxl_defbool_val(*db) ? Py_True : Py_False;
+    Py_INCREF(ret);
+    return ret;
+}
+
+int genwrap__defbool_set(PyObject *v, libxl_defbool *db)
+{
+    bool val = !(NULL == v || Py_None == v || Py_False == v);
+    libxl_defbool_set(db, val);
+    return 0;
+}
+
 static int fixed_bytearray_set(PyObject *v, uint8_t *ptr, size_t len)
 {
     char *tmp;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTR-0001if-BC; Mon, 16 Jan 2012 12:15:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTJ-0001Pn-37
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326716101!55859788!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10960 invoked from network); 16 Jan 2012 12:15:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671940"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dM032155;	Mon, 16 Jan 2012 04:15:30 -0800
MIME-Version: 1.0
X-Mercurial-Node: 953a1ce643856edcf9fbbbc2680690b3a26dede8
Message-ID: <953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:30 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326715929 0
# Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
# Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
libxl: Default to stub device model whenever possible.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 16 11:33:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 12:12:09 2012 +0000
@@ -94,7 +94,20 @@ int libxl__domain_build_info_setdefaults
         b_info->device_model_version =
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 
-    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+    /* Default to stub domain device model if possible */
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM
+        && b_info->device_model_version
+        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL
+        && access(libxl__stubdom_kernel(gc), R_OK) == 0) {
+        libxl_defbool_setdefault(&b_info->device_model_stubdomain, true);
+    } else {
+        libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+    }
+
+    if (b_info->device_model_version !=
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
+        libxl_defbool_val(b_info->device_model_stubdomain))
+        return ERROR_INVAL;
 
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 16 11:33:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 16 12:12:09 2012 +0000
@@ -686,6 +686,11 @@ retry_transaction:
     return 0;
 }
 
+char *libxl__stubdom_kernel(libxl__gc *gc)
+{
+    return libxl__abs_path(gc, "ioemu-stubdom.gz", libxl_xenfirmwaredir_path());
+}
+
 static int libxl__create_stubdom(libxl__gc *gc,
                                  int guest_domid,
                                  libxl_domain_config *guest_config,
@@ -729,8 +734,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
 
     dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
-                                              libxl_xenfirmwaredir_path());
+    dm_config.b_info.u.pv.kernel.path = libxl__stubdom_kernel(gc);
     dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 16 11:33:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 16 12:12:09 2012 +0000
@@ -482,6 +482,8 @@ _hidden int libxl__create_device_model(l
                               libxl_domain_config *guest_config,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
+_hidden char *libxl__stubdom_kernel(libxl__gc *gc);
+
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl__domain_build_state *state,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTR-0001if-BC; Mon, 16 Jan 2012 12:15:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTJ-0001Pn-37
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326716101!55859788!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10960 invoked from network); 16 Jan 2012 12:15:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671940"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dM032155;	Mon, 16 Jan 2012 04:15:30 -0800
MIME-Version: 1.0
X-Mercurial-Node: 953a1ce643856edcf9fbbbc2680690b3a26dede8
Message-ID: <953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:30 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326715929 0
# Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
# Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
libxl: Default to stub device model whenever possible.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 16 11:33:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 12:12:09 2012 +0000
@@ -94,7 +94,20 @@ int libxl__domain_build_info_setdefaults
         b_info->device_model_version =
             LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 
-    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+    /* Default to stub domain device model if possible */
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM
+        && b_info->device_model_version
+        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL
+        && access(libxl__stubdom_kernel(gc), R_OK) == 0) {
+        libxl_defbool_setdefault(&b_info->device_model_stubdomain, true);
+    } else {
+        libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+    }
+
+    if (b_info->device_model_version !=
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
+        libxl_defbool_val(b_info->device_model_stubdomain))
+        return ERROR_INVAL;
 
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 16 11:33:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 16 12:12:09 2012 +0000
@@ -686,6 +686,11 @@ retry_transaction:
     return 0;
 }
 
+char *libxl__stubdom_kernel(libxl__gc *gc)
+{
+    return libxl__abs_path(gc, "ioemu-stubdom.gz", libxl_xenfirmwaredir_path());
+}
+
 static int libxl__create_stubdom(libxl__gc *gc,
                                  int guest_domid,
                                  libxl_domain_config *guest_config,
@@ -729,8 +734,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
 
     dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
-                                              libxl_xenfirmwaredir_path());
+    dm_config.b_info.u.pv.kernel.path = libxl__stubdom_kernel(gc);
     dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 16 11:33:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 16 12:12:09 2012 +0000
@@ -482,6 +482,8 @@ _hidden int libxl__create_device_model(l
                               libxl_domain_config *guest_config,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
+_hidden char *libxl__stubdom_kernel(libxl__gc *gc);
+
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl__domain_build_state *state,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTT-0001nf-Sw; Mon, 16 Jan 2012 12:15: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 1RmlTK-0001Hy-3u
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!14
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6218 invoked from network); 16 Jan 2012 12:15:27 -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;
	16 Jan 2012 12:15:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907101"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:26 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:26 -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
	q0GCF0dG032155;	Mon, 16 Jan 2012 04:15:25 -0800
MIME-Version: 1.0
X-Mercurial-Node: 81def18dfda0899a8c7309f284d7ee4d6009da62
Message-ID: <81def18dfda0899a8c73.1326716124@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:24 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 26 of 32 RFC] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326471469 0
# Node ID 81def18dfda0899a8c7309f284d7ee4d6009da62
# Parent  87c469583499236e6a524f9c9271323ae91394fe
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

This just covers the obvious ones.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl.c	Fri Jan 13 16:17:49 2012 +0000
@@ -2425,7 +2425,11 @@ int libxl_domain_need_memory(libxl_ctx *
                              uint32_t *need_memkb)
 {
     GC_INIT(ctx);
-    int rc = ERROR_INVAL;
+    int rc;
+
+    rc = libxl__domain_build_info_setdefaults(gc, b_info);
+    if (rc) goto out;
+
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -2437,6 +2441,7 @@ int libxl_domain_need_memory(libxl_ctx *
         *need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
         break;
     default:
+        rc = ERROR_INVAL;
         goto out;
     }
     if (*need_memkb % (2 * 1024))
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl.h	Fri Jan 13 16:17:49 2012 +0000
@@ -280,7 +280,7 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info);
+                          const libxl_domain_create_info *c_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Fri Jan 13 16:17:49 2012 +0000
@@ -352,6 +352,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
+    rc = libxl__domain_build_info_setdefaults(gc, info);
+    if (rc) goto out;
+
     rc = ERROR_INVAL;
     if (!disk)
         goto out;
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_create.c	Fri Jan 13 16:17:49 2012 +0000
@@ -79,14 +79,13 @@ int libxl__domain_create_info_setdefault
 
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info)
+                          const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
     b_info->max_vcpus = 1;
     b_info->cur_vcpus = 1;
     b_info->max_memkb = 32 * 1024;
     b_info->target_memkb = b_info->max_memkb;
-    b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
@@ -100,17 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
-        b_info->u.hvm.pae = 1;
-        b_info->u.hvm.apic = 1;
-        b_info->u.hvm.acpi = 1;
-        b_info->u.hvm.acpi_s3 = 1;
-        b_info->u.hvm.acpi_s4 = 1;
-        b_info->u.hvm.nx = 1;
-        b_info->u.hvm.viridian = 0;
-        b_info->u.hvm.hpet = 1;
-        b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
-        b_info->u.hvm.nested_hvm = 0;
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
@@ -123,9 +112,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.nographic = 0;
         b_info->u.hvm.serial = NULL;
         b_info->u.hvm.boot = strdup("cda");
-        b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
-        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -139,6 +126,39 @@ int libxl_init_build_info(libxl_ctx *ctx
     return 0;
 }
 
+int libxl__domain_build_info_setdefaults(libxl__gc *gc,
+                                         libxl_domain_build_info *b_info)
+{
+    libxl_defbool_setdefault(&b_info->disable_migrate, false);
+    switch (b_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nx, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.viridian, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
+        break;
+    default:
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "invalid domain type %s in create info",
+                   libxl_domain_type_to_string(b_info->type));
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
+
 static int init_console_info(libxl_device_console *console, int dev_num)
 {
     memset(console, 0x00, sizeof(libxl_device_console));
@@ -181,11 +201,11 @@ int libxl__domain_build(libxl__gc *gc,
 
         localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
-        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[1] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
-        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[3] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
-        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[5] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -478,6 +498,8 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
+    ret = libxl__domain_build_info_setdefaults(gc, &d_config->b_info);
+    if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
@@ -615,7 +637,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
+        libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
         int rc;
         rc = libxl__e820_alloc(gc, domid, d_config);
         if (rc)
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Jan 13 16:17:49 2012 +0000
@@ -200,7 +200,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.boot) {
             flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -210,7 +210,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (b_info->u.hvm.acpi) {
+        if (libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -435,7 +435,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-boot",
                     libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -445,7 +445,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (!b_info->u.hvm.acpi) {
+        if (!libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-no-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -751,6 +751,8 @@ static int libxl__create_stubdom(libxl__
 
     ret = libxl__domain_create_info_setdefaults(gc, &dm_config.c_info);
     if (ret) goto out;
+    ret = libxl__domain_build_info_setdefaults(gc, &dm_config.b_info);
+    if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
@@ -953,7 +955,7 @@ int libxl__create_device_model(libxl__gc
         b_info->device_model_version
         == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
         libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                        "%d", !b_info->u.hvm.xen_platform_pci);
+                    "%d", !libxl_defbool_val(b_info->u.hvm.xen_platform_pci));
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Jan 13 16:17:49 2012 +0000
@@ -95,7 +95,7 @@ int libxl__build_pre(libxl__gc *gc, uint
         abort();
     }
     xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
-    if ( info->disable_migrate )
+    if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -264,7 +264,7 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->apic_mode = info->u.hvm.apic;
+    va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
@@ -274,14 +274,19 @@ static int hvm_build_set_params(xc_inter
 
     xc_get_hvm_param(handle, domid, HVM_PARAM_STORE_PFN, store_mfn);
     xc_get_hvm_param(handle, domid, HVM_PARAM_CONSOLE_PFN, console_mfn);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED, info->u.hvm.pae);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED,
+                     libxl_defbool_val(info->u.hvm.pae));
 #if defined(__i386__) || defined(__x86_64__)
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN, info->u.hvm.viridian);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED, (unsigned long) info->u.hvm.hpet);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN,
+                     libxl_defbool_val(info->u.hvm.viridian));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED,
+                     libxl_defbool_val(info->u.hvm.hpet));
 #endif
     xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, (unsigned long) info->u.hvm.timer_mode);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->u.hvm.vpt_align);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN,
+                     libxl_defbool_val(info->u.hvm.vpt_align));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM,
+                     libxl_defbool_val(info->u.hvm.nested_hvm));
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
     return 0;
@@ -358,7 +363,7 @@ int libxl__domain_restore_common(libxl__
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
-        pae = info->u.hvm.pae;
+        pae = libxl_defbool_val(info->u.hvm.pae);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Jan 13 16:17:49 2012 +0000
@@ -232,6 +232,8 @@ typedef struct {
  */
 int libxl__domain_create_info_setdefaults(libxl__gc *gc,
                                           libxl_domain_create_info *c_info);
+int libxl__domain_build_info_setdefaults(libxl__gc *gc,
+                                         libxl_domain_build_info *b_info);
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info, libxl__domain_build_state *state);
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Fri Jan 13 16:17:49 2012 +0000
@@ -1381,7 +1381,7 @@ int libxl__e820_alloc(libxl__gc *gc, uin
         return ERROR_INVAL;
 
     b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
+    if (!libxl_defbool_val(b_info->u.pv.e820_host))
         return ERROR_INVAL;
 
     rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Jan 13 16:17:49 2012 +0000
@@ -204,7 +204,7 @@ libxl_domain_build_info = Struct("domain
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
     ("shadow_memkb",    uint32),
-    ("disable_migrate", bool),
+    ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
     
@@ -221,19 +221,19 @@ libxl_domain_build_info = Struct("domain
     ("extra_hvm",        libxl_string_list),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
-                [("hvm", Struct(None, [("firmware", string),
-                                       ("pae", bool),
-                                       ("apic", bool),
-                                       ("acpi", bool),
-                                       ("acpi_s3", bool),
-                                       ("acpi_s4", bool),
-                                       ("nx", bool),
-                                       ("viridian", bool),
-                                       ("timeoffset", string),
-                                       ("hpet", bool),
-                                       ("vpt_align", bool),
-                                       ("timer_mode", integer),
-                                       ("nested_hvm", bool),
+                [("hvm", Struct(None, [("firmware",         string),
+                                       ("pae",              libxl_defbool),
+                                       ("apic",             libxl_defbool),
+                                       ("acpi",             libxl_defbool),
+                                       ("acpi_s3",          libxl_defbool),
+                                       ("acpi_s4",          libxl_defbool),
+                                       ("nx",               libxl_defbool),
+                                       ("viridian",         libxl_defbool),
+                                       ("timeoffset",       string),
+                                       ("hpet",             libxl_defbool),
+                                       ("vpt_align",        libxl_defbool),
+                                       ("timer_mode",       integer),
+                                       ("nested_hvm",       libxl_defbool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
                                        ("vnc",              libxl_vnc_info),
@@ -246,13 +246,13 @@ libxl_domain_build_info = Struct("domain
                                        
                                        ("serial",           string),
                                        ("boot",             string),
-                                       ("usb",              bool),
+                                       ("usb",              libxl_defbool),
                                        # usbdevice:
                                        # - "tablet" for absolute mouse,
                                        # - "mouse" for PS/2 protocol relative mouse
                                        ("usbdevice",        string),
                                        ("soundhw",          string),
-                                       ("xen_platform_pci", bool),
+                                       ("xen_platform_pci", libxl_defbool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -262,7 +262,7 @@ libxl_domain_build_info = Struct("domain
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
-                                      ("e820_host", bool),
+                                      ("e820_host", libxl_defbool),
                                       ])),
                  ])),
     ],
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jan 13 16:17:49 2012 +0000
@@ -330,7 +330,8 @@ static void printf_info(int domid,
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
+    printf("\t(nomigrate %s)\n",
+           libxl_defbool_to_string(b_info->disable_migrate));
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
         int i;
@@ -350,16 +351,21 @@ static void printf_info(int domid,
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
         printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
         printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
+        printf("\t\t\t(apic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.apic));
+        printf("\t\t\t(acpi %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.acpi));
+        printf("\t\t\t(nx %s)\n", libxl_defbool_to_string(b_info->u.hvm.nx));
+        printf("\t\t\t(viridian %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.viridian));
+        printf("\t\t\t(hpet %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.hpet));
+        printf("\t\t\t(vpt_align %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vpt_align));
         printf("\t\t\t(timer_mode %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(nestedhvm %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
         printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
@@ -381,7 +387,7 @@ static void printf_info(int domid,
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
         printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
@@ -390,7 +396,8 @@ static void printf_info(int domid,
         printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
         printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
         printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t\t(e820_host %s)\n",
+               libxl_defbool_to_string(b_info->u.pv.e820_host));
         printf("\t\t)\n");
         break;
     default:
@@ -699,8 +706,7 @@ static void parse_config_data(const char
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
-        b_info->disable_migrate = l;
+    xlu_cfg_get_defbool(config, "nomigrate", &b_info->disable_migrate, 0);
 
     if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
         const char *s = libxl_tsc_mode_to_string(l);
@@ -736,28 +742,19 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
-        if (!xlu_cfg_get_long (config, "pae", &l, 0))
-            b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l, 0))
-            b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
-            b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
-            b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
-            b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l, 0))
-            b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
-            b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
-            b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
-            b_info->u.hvm.vpt_align = l;
+
+        xlu_cfg_get_defbool(config, "pae", &b_info->u.hvm.pae, 0);
+        xlu_cfg_get_defbool(config, "apic", &b_info->u.hvm.apic, 0);
+        xlu_cfg_get_defbool(config, "acpi", &b_info->u.hvm.acpi, 0);
+        xlu_cfg_get_defbool(config, "acpi_s3", &b_info->u.hvm.acpi_s3, 0);
+        xlu_cfg_get_defbool(config, "acpi_s4", &b_info->u.hvm.acpi_s4, 0);
+        xlu_cfg_get_defbool(config, "nx", &b_info->u.hvm.nx, 0);
+        xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
+        xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
+        xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
         if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
             b_info->u.hvm.timer_mode = l;
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
-            b_info->u.hvm.nested_hvm = l;
+        xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
@@ -994,19 +991,10 @@ skip_vfb:
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
-        switch (c_info->type) {
-        case LIBXL_DOMAIN_TYPE_HVM:
-            fprintf(stderr, "Can't do e820_host in HVM mode!");
-            break;
-        case LIBXL_DOMAIN_TYPE_PV:
-            if (l)
-                b_info->u.pv.e820_host = true;
-            break;
-        default:
-            abort();
-        }
-    }
+    if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
+        xlu_cfg_get_defbool(config, "e820_host", &b_info->u.pv.e820_host, 0);
+    }
+
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
         int i;
         d_config->num_pcidevs = 0;
@@ -1024,7 +1012,7 @@ skip_vfb:
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
-            b_info->u.pv.e820_host = true;
+            libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
 
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
@@ -1201,12 +1189,12 @@ skip_vfb:
             b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
-        if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            b_info->u.hvm.usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
+        xlu_cfg_replace_string (config, "usbdevice",
+                                &b_info->u.hvm.usbdevice, 0);
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            b_info->u.hvm.xen_platform_pci = l;
+        xlu_cfg_get_defbool(config, "xen_platform_pci",
+                            &b_info->u.hvm.xen_platform_pci, 0);
     }
 
     xlu_cfg_destroy(config);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTT-0001nf-Sw; Mon, 16 Jan 2012 12:15: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 1RmlTK-0001Hy-3u
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!14
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6218 invoked from network); 16 Jan 2012 12:15:27 -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;
	16 Jan 2012 12:15:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907101"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:26 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:26 -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
	q0GCF0dG032155;	Mon, 16 Jan 2012 04:15:25 -0800
MIME-Version: 1.0
X-Mercurial-Node: 81def18dfda0899a8c7309f284d7ee4d6009da62
Message-ID: <81def18dfda0899a8c73.1326716124@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:24 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 26 of 32 RFC] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326471469 0
# Node ID 81def18dfda0899a8c7309f284d7ee4d6009da62
# Parent  87c469583499236e6a524f9c9271323ae91394fe
libxl: make boolean members of libxl_domain_create_info into libxl_defbool

This just covers the obvious ones.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl.c	Fri Jan 13 16:17:49 2012 +0000
@@ -2425,7 +2425,11 @@ int libxl_domain_need_memory(libxl_ctx *
                              uint32_t *need_memkb)
 {
     GC_INIT(ctx);
-    int rc = ERROR_INVAL;
+    int rc;
+
+    rc = libxl__domain_build_info_setdefaults(gc, b_info);
+    if (rc) goto out;
+
     *need_memkb = b_info->target_memkb;
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -2437,6 +2441,7 @@ int libxl_domain_need_memory(libxl_ctx *
         *need_memkb += b_info->shadow_memkb + LIBXL_PV_EXTRA_MEMORY;
         break;
     default:
+        rc = ERROR_INVAL;
         goto out;
     }
     if (*need_memkb % (2 * 1024))
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl.h	Fri Jan 13 16:17:49 2012 +0000
@@ -280,7 +280,7 @@ int libxl_ctx_postfork(libxl_ctx *ctx);
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info);
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info);
+                          const libxl_domain_create_info *c_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_bootloader.c	Fri Jan 13 16:17:49 2012 +0000
@@ -352,6 +352,9 @@ int libxl_run_bootloader(libxl_ctx *ctx,
     if (info->type != LIBXL_DOMAIN_TYPE_PV || !info->u.pv.bootloader)
         goto out;
 
+    rc = libxl__domain_build_info_setdefaults(gc, info);
+    if (rc) goto out;
+
     rc = ERROR_INVAL;
     if (!disk)
         goto out;
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_create.c	Fri Jan 13 16:17:49 2012 +0000
@@ -79,14 +79,13 @@ int libxl__domain_create_info_setdefault
 
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
-                          libxl_domain_create_info *c_info)
+                          const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
     b_info->max_vcpus = 1;
     b_info->cur_vcpus = 1;
     b_info->max_memkb = 32 * 1024;
     b_info->target_memkb = b_info->max_memkb;
-    b_info->disable_migrate = 0;
     b_info->cpuid = NULL;
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
@@ -100,17 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
         b_info->u.hvm.firmware = NULL;
-        b_info->u.hvm.pae = 1;
-        b_info->u.hvm.apic = 1;
-        b_info->u.hvm.acpi = 1;
-        b_info->u.hvm.acpi_s3 = 1;
-        b_info->u.hvm.acpi_s4 = 1;
-        b_info->u.hvm.nx = 1;
-        b_info->u.hvm.viridian = 0;
-        b_info->u.hvm.hpet = 1;
-        b_info->u.hvm.vpt_align = 1;
         b_info->u.hvm.timer_mode = 1;
-        b_info->u.hvm.nested_hvm = 0;
 
         b_info->u.hvm.stdvga = 0;
         b_info->u.hvm.vnc.enable = 1;
@@ -123,9 +112,7 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.nographic = 0;
         b_info->u.hvm.serial = NULL;
         b_info->u.hvm.boot = strdup("cda");
-        b_info->u.hvm.usb = 0;
         b_info->u.hvm.usbdevice = NULL;
-        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -139,6 +126,39 @@ int libxl_init_build_info(libxl_ctx *ctx
     return 0;
 }
 
+int libxl__domain_build_info_setdefaults(libxl__gc *gc,
+                                         libxl_domain_build_info *b_info)
+{
+    libxl_defbool_setdefault(&b_info->disable_migrate, false);
+    switch (b_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s3, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.acpi_s4, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nx, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.viridian, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.hpet, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.vpt_align, true);
+        libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
+        break;
+    default:
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "invalid domain type %s in create info",
+                   libxl_domain_type_to_string(b_info->type));
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
+
 static int init_console_info(libxl_device_console *console, int dev_num)
 {
     memset(console, 0x00, sizeof(libxl_device_console));
@@ -181,11 +201,11 @@ int libxl__domain_build(libxl__gc *gc,
 
         localents = libxl__calloc(gc, 7, sizeof(char *));
         localents[0] = "platform/acpi";
-        localents[1] = (info->u.hvm.acpi) ? "1" : "0";
+        localents[1] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
         localents[2] = "platform/acpi_s3";
-        localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
+        localents[3] = libxl_defbool_val(info->u.hvm.acpi_s3) ? "1" : "0";
         localents[4] = "platform/acpi_s4";
-        localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[5] = libxl_defbool_val(info->u.hvm.acpi_s4) ? "1" : "0";
 
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -478,6 +498,8 @@ static int do_domain_create(libxl__gc *g
             goto error_out;
     }
 
+    ret = libxl__domain_build_info_setdefaults(gc, &d_config->b_info);
+    if (ret) goto error_out;
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl__device_disk_set_backend(gc, &d_config->disks[i]);
@@ -615,7 +637,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
-        d_config->b_info.u.pv.e820_host) {
+        libxl_defbool_val(d_config->b_info.u.pv.e820_host)) {
         int rc;
         rc = libxl__e820_alloc(gc, domid, d_config);
         if (rc)
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Jan 13 16:17:49 2012 +0000
@@ -200,7 +200,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.boot) {
             flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -210,7 +210,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (b_info->u.hvm.acpi) {
+        if (libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -435,7 +435,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-boot",
                     libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
+        if (libxl_defbool_val(b_info->u.hvm.usb) || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
             if (b_info->u.hvm.usbdevice) {
                 flexarray_vappend(dm_args,
@@ -445,7 +445,7 @@ static char ** libxl__build_device_model
         if (b_info->u.hvm.soundhw) {
             flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
-        if (!b_info->u.hvm.acpi) {
+        if (!libxl_defbool_val(b_info->u.hvm.acpi)) {
             flexarray_append(dm_args, "-no-acpi");
         }
         if (b_info->max_vcpus > 1) {
@@ -751,6 +751,8 @@ static int libxl__create_stubdom(libxl__
 
     ret = libxl__domain_create_info_setdefaults(gc, &dm_config.c_info);
     if (ret) goto out;
+    ret = libxl__domain_build_info_setdefaults(gc, &dm_config.b_info);
+    if (ret) goto out;
 
     libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
@@ -953,7 +955,7 @@ int libxl__create_device_model(libxl__gc
         b_info->device_model_version
         == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
         libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                        "%d", !b_info->u.hvm.xen_platform_pci);
+                    "%d", !libxl_defbool_val(b_info->u.hvm.xen_platform_pci));
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Fri Jan 13 16:17:49 2012 +0000
@@ -95,7 +95,7 @@ int libxl__build_pre(libxl__gc *gc, uint
         abort();
     }
     xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
-    if ( info->disable_migrate )
+    if (libxl_defbool_val(info->disable_migrate))
         xc_domain_disable_migrate(ctx->xch, domid);
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -264,7 +264,7 @@ static int hvm_build_set_params(xc_inter
         return -1;
 
     va_hvm = (struct hvm_info_table *)(va_map + HVM_INFO_OFFSET);
-    va_hvm->apic_mode = info->u.hvm.apic;
+    va_hvm->apic_mode = libxl_defbool_val(info->u.hvm.apic);
     va_hvm->nr_vcpus = info->max_vcpus;
     memcpy(va_hvm->vcpu_online, &info->cur_vcpus, sizeof(info->cur_vcpus));
     for (i = 0, sum = 0; i < va_hvm->length; i++)
@@ -274,14 +274,19 @@ static int hvm_build_set_params(xc_inter
 
     xc_get_hvm_param(handle, domid, HVM_PARAM_STORE_PFN, store_mfn);
     xc_get_hvm_param(handle, domid, HVM_PARAM_CONSOLE_PFN, console_mfn);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED, info->u.hvm.pae);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_PAE_ENABLED,
+                     libxl_defbool_val(info->u.hvm.pae));
 #if defined(__i386__) || defined(__x86_64__)
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN, info->u.hvm.viridian);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED, (unsigned long) info->u.hvm.hpet);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN,
+                     libxl_defbool_val(info->u.hvm.viridian));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED,
+                     libxl_defbool_val(info->u.hvm.hpet));
 #endif
     xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, (unsigned long) info->u.hvm.timer_mode);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->u.hvm.vpt_align);
-    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN,
+                     libxl_defbool_val(info->u.hvm.vpt_align));
+    xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM,
+                     libxl_defbool_val(info->u.hvm.nested_hvm));
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
     return 0;
@@ -358,7 +363,7 @@ int libxl__domain_restore_common(libxl__
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
-        pae = info->u.hvm.pae;
+        pae = libxl_defbool_val(info->u.hvm.pae);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Fri Jan 13 16:17:49 2012 +0000
@@ -232,6 +232,8 @@ typedef struct {
  */
 int libxl__domain_create_info_setdefaults(libxl__gc *gc,
                                           libxl_domain_create_info *c_info);
+int libxl__domain_build_info_setdefaults(libxl__gc *gc,
+                                         libxl_domain_build_info *b_info);
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info, libxl__domain_build_state *state);
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Fri Jan 13 16:17:49 2012 +0000
@@ -1381,7 +1381,7 @@ int libxl__e820_alloc(libxl__gc *gc, uin
         return ERROR_INVAL;
 
     b_info = &d_config->b_info;
-    if (!b_info->u.pv.e820_host)
+    if (!libxl_defbool_val(b_info->u.pv.e820_host))
         return ERROR_INVAL;
 
     rc = xc_get_machine_memory_map(ctx->xch, map, E820MAX);
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Jan 13 16:17:49 2012 +0000
@@ -204,7 +204,7 @@ libxl_domain_build_info = Struct("domain
     ("target_memkb",    uint32),
     ("video_memkb",     uint32),
     ("shadow_memkb",    uint32),
-    ("disable_migrate", bool),
+    ("disable_migrate", libxl_defbool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
     
@@ -221,19 +221,19 @@ libxl_domain_build_info = Struct("domain
     ("extra_hvm",        libxl_string_list),
 
     ("u", KeyedUnion(None, libxl_domain_type, "type",
-                [("hvm", Struct(None, [("firmware", string),
-                                       ("pae", bool),
-                                       ("apic", bool),
-                                       ("acpi", bool),
-                                       ("acpi_s3", bool),
-                                       ("acpi_s4", bool),
-                                       ("nx", bool),
-                                       ("viridian", bool),
-                                       ("timeoffset", string),
-                                       ("hpet", bool),
-                                       ("vpt_align", bool),
-                                       ("timer_mode", integer),
-                                       ("nested_hvm", bool),
+                [("hvm", Struct(None, [("firmware",         string),
+                                       ("pae",              libxl_defbool),
+                                       ("apic",             libxl_defbool),
+                                       ("acpi",             libxl_defbool),
+                                       ("acpi_s3",          libxl_defbool),
+                                       ("acpi_s4",          libxl_defbool),
+                                       ("nx",               libxl_defbool),
+                                       ("viridian",         libxl_defbool),
+                                       ("timeoffset",       string),
+                                       ("hpet",             libxl_defbool),
+                                       ("vpt_align",        libxl_defbool),
+                                       ("timer_mode",       integer),
+                                       ("nested_hvm",       libxl_defbool),
                                        ("nographic",        bool),
                                        ("stdvga",           bool),
                                        ("vnc",              libxl_vnc_info),
@@ -246,13 +246,13 @@ libxl_domain_build_info = Struct("domain
                                        
                                        ("serial",           string),
                                        ("boot",             string),
-                                       ("usb",              bool),
+                                       ("usb",              libxl_defbool),
                                        # usbdevice:
                                        # - "tablet" for absolute mouse,
                                        # - "mouse" for PS/2 protocol relative mouse
                                        ("usbdevice",        string),
                                        ("soundhw",          string),
-                                       ("xen_platform_pci", bool),
+                                       ("xen_platform_pci", libxl_defbool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -262,7 +262,7 @@ libxl_domain_build_info = Struct("domain
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
-                                      ("e820_host", bool),
+                                      ("e820_host", libxl_defbool),
                                       ])),
                  ])),
     ],
diff -r 87c469583499 -r 81def18dfda0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 13 16:00:00 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jan 13 16:17:49 2012 +0000
@@ -330,7 +330,8 @@ static void printf_info(int domid,
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
+    printf("\t(nomigrate %s)\n",
+           libxl_defbool_to_string(b_info->disable_migrate));
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
         int i;
@@ -350,16 +351,21 @@ static void printf_info(int domid,
         printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
         printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
         printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(pae %s)\n", libxl_defbool_to_string(b_info->u.hvm.pae));
+        printf("\t\t\t(apic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.apic));
+        printf("\t\t\t(acpi %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.acpi));
+        printf("\t\t\t(nx %s)\n", libxl_defbool_to_string(b_info->u.hvm.nx));
+        printf("\t\t\t(viridian %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.viridian));
+        printf("\t\t\t(hpet %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.hpet));
+        printf("\t\t\t(vpt_align %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vpt_align));
         printf("\t\t\t(timer_mode %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(nestedhvm %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
         printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
@@ -381,7 +387,7 @@ static void printf_info(int domid,
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
         printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
@@ -390,7 +396,8 @@ static void printf_info(int domid,
         printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
         printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
         printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t\t(e820_host %s)\n",
+               libxl_defbool_to_string(b_info->u.pv.e820_host));
         printf("\t\t)\n");
         break;
     default:
@@ -699,8 +706,7 @@ static void parse_config_data(const char
         : libxl_get_required_shadow_memory(b_info->max_memkb,
                                            b_info->max_vcpus);
 
-    if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
-        b_info->disable_migrate = l;
+    xlu_cfg_get_defbool(config, "nomigrate", &b_info->disable_migrate, 0);
 
     if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
         const char *s = libxl_tsc_mode_to_string(l);
@@ -736,28 +742,19 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "firmware_override",
                                 &b_info->u.hvm.firmware, 0);
-        if (!xlu_cfg_get_long (config, "pae", &l, 0))
-            b_info->u.hvm.pae = l;
-        if (!xlu_cfg_get_long (config, "apic", &l, 0))
-            b_info->u.hvm.apic = l;
-        if (!xlu_cfg_get_long (config, "acpi", &l, 0))
-            b_info->u.hvm.acpi = l;
-        if (!xlu_cfg_get_long (config, "acpi_s3", &l, 0))
-            b_info->u.hvm.acpi_s3 = l;
-        if (!xlu_cfg_get_long (config, "acpi_s4", &l, 0))
-            b_info->u.hvm.acpi_s4 = l;
-        if (!xlu_cfg_get_long (config, "nx", &l, 0))
-            b_info->u.hvm.nx = l;
-        if (!xlu_cfg_get_long (config, "viridian", &l, 0))
-            b_info->u.hvm.viridian = l;
-        if (!xlu_cfg_get_long (config, "hpet", &l, 0))
-            b_info->u.hvm.hpet = l;
-        if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
-            b_info->u.hvm.vpt_align = l;
+
+        xlu_cfg_get_defbool(config, "pae", &b_info->u.hvm.pae, 0);
+        xlu_cfg_get_defbool(config, "apic", &b_info->u.hvm.apic, 0);
+        xlu_cfg_get_defbool(config, "acpi", &b_info->u.hvm.acpi, 0);
+        xlu_cfg_get_defbool(config, "acpi_s3", &b_info->u.hvm.acpi_s3, 0);
+        xlu_cfg_get_defbool(config, "acpi_s4", &b_info->u.hvm.acpi_s4, 0);
+        xlu_cfg_get_defbool(config, "nx", &b_info->u.hvm.nx, 0);
+        xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
+        xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
+        xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
         if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
             b_info->u.hvm.timer_mode = l;
-        if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
-            b_info->u.hvm.nested_hvm = l;
+        xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
     {
@@ -994,19 +991,10 @@ skip_vfb:
 
     /* To be reworked (automatically enabled) once the auto ballooning
      * after guest starts is done (with PCI devices passed in). */
-    if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
-        switch (c_info->type) {
-        case LIBXL_DOMAIN_TYPE_HVM:
-            fprintf(stderr, "Can't do e820_host in HVM mode!");
-            break;
-        case LIBXL_DOMAIN_TYPE_PV:
-            if (l)
-                b_info->u.pv.e820_host = true;
-            break;
-        default:
-            abort();
-        }
-    }
+    if (c_info->type == LIBXL_DOMAIN_TYPE_PV) {
+        xlu_cfg_get_defbool(config, "e820_host", &b_info->u.pv.e820_host, 0);
+    }
+
     if (!xlu_cfg_get_list (config, "pci", &pcis, 0, 0)) {
         int i;
         d_config->num_pcidevs = 0;
@@ -1024,7 +1012,7 @@ skip_vfb:
                 d_config->num_pcidevs++;
         }
         if (d_config->num_pcidevs && c_info->type == LIBXL_DOMAIN_TYPE_PV)
-            b_info->u.pv.e820_host = true;
+            libxl_defbool_set(&b_info->u.pv.e820_host, true);
     }
 
     switch (xlu_cfg_get_list(config, "cpuid", &cpuids, 0, 1)) {
@@ -1201,12 +1189,12 @@ skip_vfb:
             b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
-        if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            b_info->u.hvm.usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
+        xlu_cfg_replace_string (config, "usbdevice",
+                                &b_info->u.hvm.usbdevice, 0);
         xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
-        if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            b_info->u.hvm.xen_platform_pci = l;
+        xlu_cfg_get_defbool(config, "xen_platform_pci",
+                            &b_info->u.hvm.xen_platform_pci, 0);
     }
 
     xlu_cfg_destroy(config);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTU-0001pP-Vq; Mon, 16 Jan 2012 12:15:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTM-0001N5-Gy
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326716101!55859788!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10836 invoked from network); 16 Jan 2012 12:15:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671933"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dK032155;	Mon, 16 Jan 2012 04:15:28 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7ffc8e870fbb5a9edcd6f8d46f2b0296d38cb5ed
Message-ID: <7ffc8e870fbb5a9edcd6.1326716128@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:28 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 30 of 32 RFC] libxl: drop 8M slack for PV guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326713350 0
# Node ID 7ffc8e870fbb5a9edcd6f8d46f2b0296d38cb5ed
# Parent  feeea78c60ef4a0ec5d4d827bb15cc004ece9774
libxl: drop 8M slack for PV guests.

As far as I can tell this serves no purpose. I think it relates to the old
8M to "account for backend allocations" which we used to add. This leaves a bit
of unpopulated space in the Pseudo-physical address space which can be used by
backends when mapping foreign memory. However 8M is not representative of that
any more and modern kernels do not operate in this way anyway.

I suspect an argument could be made for removing this from the libxl API
altogether but instead lets jsut set the overhead to 0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r feeea78c60ef -r 7ffc8e870fbb tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 16 11:25:49 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 11:29:10 2012 +0000
@@ -89,18 +89,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
-    switch (b_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 8 * 1024;
-        break;
-    default:
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "invalid domain type %s in create info",
-                   libxl_domain_type_to_string(b_info->type));
-        return ERROR_INVAL;
-    }
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTU-0001pP-Vq; Mon, 16 Jan 2012 12:15:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTM-0001N5-Gy
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326716101!55859788!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10836 invoked from network); 16 Jan 2012 12:15:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671933"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dK032155;	Mon, 16 Jan 2012 04:15:28 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7ffc8e870fbb5a9edcd6f8d46f2b0296d38cb5ed
Message-ID: <7ffc8e870fbb5a9edcd6.1326716128@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:28 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 30 of 32 RFC] libxl: drop 8M slack for PV guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326713350 0
# Node ID 7ffc8e870fbb5a9edcd6f8d46f2b0296d38cb5ed
# Parent  feeea78c60ef4a0ec5d4d827bb15cc004ece9774
libxl: drop 8M slack for PV guests.

As far as I can tell this serves no purpose. I think it relates to the old
8M to "account for backend allocations" which we used to add. This leaves a bit
of unpopulated space in the Pseudo-physical address space which can be used by
backends when mapping foreign memory. However 8M is not representative of that
any more and modern kernels do not operate in this way anyway.

I suspect an argument could be made for removing this from the libxl API
altogether but instead lets jsut set the overhead to 0.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r feeea78c60ef -r 7ffc8e870fbb tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 16 11:25:49 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 11:29:10 2012 +0000
@@ -89,18 +89,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->device_model_stubdomain = false;
     b_info->device_model = NULL;
 
-    switch (b_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        b_info->u.pv.slack_memkb = 8 * 1024;
-        break;
-    default:
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                   "invalid domain type %s in create info",
-                   libxl_domain_type_to_string(b_info->type));
-        return ERROR_INVAL;
-    }
     return 0;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTW-0001sa-ER; Mon, 16 Jan 2012 12:15:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTM-0001Mg-C0
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326716128!9313365!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10547 invoked from network); 16 Jan 2012 12:15:29 -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;
	16 Jan 2012 12:15:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907104"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dJ032155;	Mon, 16 Jan 2012 04:15:27 -0800
MIME-Version: 1.0
X-Mercurial-Node: feeea78c60ef4a0ec5d4d827bb15cc004ece9774
Message-ID: <feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer
	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326713149 0
# Node ID feeea78c60ef4a0ec5d4d827bb15cc004ece9774
# Parent  90fe4b95bdc935b2d5328603aa77d4de37253c36
libxl: add named enum for timer mode.

In order to have 0 == default the specific values are off-by-one from the
underlying domctl. I'm not sure I like this.

I looked at updating xl.cfg(5) for these while I was here but frankly, even
after reading the comment in xen/include/public/hvm/params.h, I don't have a
clue what they mean, no_missed_ticks_pending in particular might as well be
written in klingon...

For the same reason I didn't try and give the enum more user-friendly names.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 90fe4b95bdc9 -r feeea78c60ef tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 16 11:18:54 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 11:25:49 2012 +0000
@@ -91,7 +91,6 @@ int libxl_init_build_info(libxl_ctx *ctx
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.timer_mode = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -122,6 +121,9 @@ int libxl__domain_build_info_setdefaults
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!b_info->video_memkb)
             b_info->video_memkb = 8 * 1024;
+        if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
+            b_info->u.hvm.timer_mode =
+                LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
 
         libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
         libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
diff -r 90fe4b95bdc9 -r feeea78c60ef tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 16 11:18:54 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 16 11:25:49 2012 +0000
@@ -248,6 +248,13 @@ out:
     return ret == 0 ? 0 : ERROR_FAIL;
 }
 
+static unsigned long timer_mode(const libxl_domain_build_info *info)
+{
+    const libxl_timer_mode mode = info->u.hvm.timer_mode;
+    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
+           mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
+    return ((unsigned long)mode) - 1;
+}
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
@@ -282,7 +289,7 @@ static int hvm_build_set_params(xc_inter
     xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED,
                      libxl_defbool_val(info->u.hvm.hpet));
 #endif
-    xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, (unsigned long) info->u.hvm.timer_mode);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
     xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN,
                      libxl_defbool_val(info->u.hvm.vpt_align));
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM,
diff -r 90fe4b95bdc9 -r feeea78c60ef tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 16 11:18:54 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 16 11:25:49 2012 +0000
@@ -94,6 +94,15 @@ libxl_tsc_mode = Enumeration("tsc_mode",
     (3, "native_paravirt"),
     ])
 
+# NB: specific values are + 1 from underlying hypercall value
+libxl_timer_mode = Enumeration("timer_mode", [
+    (0, "default"),
+    (1, "delay_for_missed_ticks"),
+    (2, "no_delay_for_missed_ticks"),
+    (3, "no_missed_ticks_pending"),
+    (4, "one_missed_tick_pending"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -232,7 +241,7 @@ libxl_domain_build_info = Struct("domain
                                        ("timeoffset",       string),
                                        ("hpet",             libxl_defbool),
                                        ("vpt_align",        libxl_defbool),
-                                       ("timer_mode",       integer),
+                                       ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
                                        ("nographic",        libxl_defbool),
                                        ("stdvga",           libxl_defbool),
diff -r 90fe4b95bdc9 -r feeea78c60ef tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 16 11:18:54 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 16 11:25:49 2012 +0000
@@ -363,7 +363,8 @@ static void printf_info(int domid,
                libxl_defbool_to_string(b_info->u.hvm.hpet));
         printf("\t\t\t(vpt_align %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.vpt_align));
-        printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
+        printf("\t\t\t(timer_mode %s)\n",
+               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
         printf("\t\t\t(nestedhvm %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(stdvga %s)\n",
@@ -765,8 +766,31 @@ static void parse_config_data(const char
         xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
         xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
         xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
-        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
+
+        if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
+            /* enum is off by one from raw number */
+            const char *s = libxl_timer_mode_to_string(l++);
+            fprintf(stderr, "WARNING: specifying \"timer_mode\" as an integer is deprecated. "
+                    "Please use the named parameter variant. %s%s%s\n",
+                    s ? "e.g. timer_mode=\"" : "",
+                    s ? s : "",
+                    s ? "\"" : "");
+
+            if (l < LIBXL_TIMER_MODE_DEFAULT ||
+                l > LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING) {
+                fprintf(stderr, "ERROR: invalid value %ld for \"timer_mode\"\n", l);
+                exit (1);
+            }
             b_info->u.hvm.timer_mode = l;
+        } else if (!xlu_cfg_get_string(config, "timer_mode", &buf, 0)) {
+            fprintf(stderr, "got a timer mode string: \"%s\"\n", buf);
+            if (libxl_timer_mode_from_string(buf, &b_info->u.hvm.timer_mode)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"timer_mode\"\n",
+                        buf);
+                exit (1);
+            }
+        }
+
         xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
         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 Mon Jan 16 12:15:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTW-0001sa-ER; Mon, 16 Jan 2012 12:15:46 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTM-0001Mg-C0
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326716128!9313365!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10547 invoked from network); 16 Jan 2012 12:15:29 -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;
	16 Jan 2012 12:15:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907104"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dJ032155;	Mon, 16 Jan 2012 04:15:27 -0800
MIME-Version: 1.0
X-Mercurial-Node: feeea78c60ef4a0ec5d4d827bb15cc004ece9774
Message-ID: <feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer
	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326713149 0
# Node ID feeea78c60ef4a0ec5d4d827bb15cc004ece9774
# Parent  90fe4b95bdc935b2d5328603aa77d4de37253c36
libxl: add named enum for timer mode.

In order to have 0 == default the specific values are off-by-one from the
underlying domctl. I'm not sure I like this.

I looked at updating xl.cfg(5) for these while I was here but frankly, even
after reading the comment in xen/include/public/hvm/params.h, I don't have a
clue what they mean, no_missed_ticks_pending in particular might as well be
written in klingon...

For the same reason I didn't try and give the enum more user-friendly names.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 90fe4b95bdc9 -r feeea78c60ef tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 16 11:18:54 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 11:25:49 2012 +0000
@@ -91,7 +91,6 @@ int libxl_init_build_info(libxl_ctx *ctx
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->u.hvm.timer_mode = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -122,6 +121,9 @@ int libxl__domain_build_info_setdefaults
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!b_info->video_memkb)
             b_info->video_memkb = 8 * 1024;
+        if (b_info->u.hvm.timer_mode == LIBXL_TIMER_MODE_DEFAULT)
+            b_info->u.hvm.timer_mode =
+                LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS;
 
         libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
         libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
diff -r 90fe4b95bdc9 -r feeea78c60ef tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 16 11:18:54 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 16 11:25:49 2012 +0000
@@ -248,6 +248,13 @@ out:
     return ret == 0 ? 0 : ERROR_FAIL;
 }
 
+static unsigned long timer_mode(const libxl_domain_build_info *info)
+{
+    const libxl_timer_mode mode = info->u.hvm.timer_mode;
+    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
+           mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
+    return ((unsigned long)mode) - 1;
+}
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
@@ -282,7 +289,7 @@ static int hvm_build_set_params(xc_inter
     xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED,
                      libxl_defbool_val(info->u.hvm.hpet));
 #endif
-    xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, (unsigned long) info->u.hvm.timer_mode);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
     xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN,
                      libxl_defbool_val(info->u.hvm.vpt_align));
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM,
diff -r 90fe4b95bdc9 -r feeea78c60ef tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 16 11:18:54 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 16 11:25:49 2012 +0000
@@ -94,6 +94,15 @@ libxl_tsc_mode = Enumeration("tsc_mode",
     (3, "native_paravirt"),
     ])
 
+# NB: specific values are + 1 from underlying hypercall value
+libxl_timer_mode = Enumeration("timer_mode", [
+    (0, "default"),
+    (1, "delay_for_missed_ticks"),
+    (2, "no_delay_for_missed_ticks"),
+    (3, "no_missed_ticks_pending"),
+    (4, "one_missed_tick_pending"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -232,7 +241,7 @@ libxl_domain_build_info = Struct("domain
                                        ("timeoffset",       string),
                                        ("hpet",             libxl_defbool),
                                        ("vpt_align",        libxl_defbool),
-                                       ("timer_mode",       integer),
+                                       ("timer_mode",       libxl_timer_mode),
                                        ("nested_hvm",       libxl_defbool),
                                        ("nographic",        libxl_defbool),
                                        ("stdvga",           libxl_defbool),
diff -r 90fe4b95bdc9 -r feeea78c60ef tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 16 11:18:54 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 16 11:25:49 2012 +0000
@@ -363,7 +363,8 @@ static void printf_info(int domid,
                libxl_defbool_to_string(b_info->u.hvm.hpet));
         printf("\t\t\t(vpt_align %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.vpt_align));
-        printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
+        printf("\t\t\t(timer_mode %s)\n",
+               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
         printf("\t\t\t(nestedhvm %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
         printf("\t\t\t(stdvga %s)\n",
@@ -765,8 +766,31 @@ static void parse_config_data(const char
         xlu_cfg_get_defbool(config, "viridian", &b_info->u.hvm.viridian, 0);
         xlu_cfg_get_defbool(config, "hpet", &b_info->u.hvm.hpet, 0);
         xlu_cfg_get_defbool(config, "vpt_align", &b_info->u.hvm.vpt_align, 0);
-        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
+
+        if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
+            /* enum is off by one from raw number */
+            const char *s = libxl_timer_mode_to_string(l++);
+            fprintf(stderr, "WARNING: specifying \"timer_mode\" as an integer is deprecated. "
+                    "Please use the named parameter variant. %s%s%s\n",
+                    s ? "e.g. timer_mode=\"" : "",
+                    s ? s : "",
+                    s ? "\"" : "");
+
+            if (l < LIBXL_TIMER_MODE_DEFAULT ||
+                l > LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING) {
+                fprintf(stderr, "ERROR: invalid value %ld for \"timer_mode\"\n", l);
+                exit (1);
+            }
             b_info->u.hvm.timer_mode = l;
+        } else if (!xlu_cfg_get_string(config, "timer_mode", &buf, 0)) {
+            fprintf(stderr, "got a timer mode string: \"%s\"\n", buf);
+            if (libxl_timer_mode_from_string(buf, &b_info->u.hvm.timer_mode)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"timer_mode\"\n",
+                        buf);
+                exit (1);
+            }
+        }
+
         xlu_cfg_get_defbool(config, "nestedhvm", &b_info->u.hvm.nested_hvm, 0);
         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 Mon Jan 16 12:15:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTY-0001vs-0i; Mon, 16 Jan 2012 12:15: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 1RmlTL-0001LY-GT
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!15
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6344 invoked from network); 16 Jan 2012 12:15:28 -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;
	16 Jan 2012 12:15:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907102"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dH032155;	Mon, 16 Jan 2012 04:15:26 -0800
MIME-Version: 1.0
X-Mercurial-Node: b8426902efa002b6941aee6dff109aa33a4372c8
Message-ID: <b8426902efa002b6941a.1326716125@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:25 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 27 of 32 RFC] libxl: use defbool for graphics
	related options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326474297 0
# Node ID b8426902efa002b6941aee6dff109aa33a4372c8
# Parent  81def18dfda0899a8c7309f284d7ee4d6009da62
libxl: use defbool for graphics related options

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/libxl.c	Fri Jan 13 17:04:57 2012 +0000
@@ -1993,16 +1993,24 @@ out:
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->vnc.enable = 1;
-    vfb->vnc.passwd = NULL;
-    vfb->vnc.listen = strdup("127.0.0.1");
-    vfb->vnc.display = 0;
-    vfb->vnc.findunused = 1;
-    vfb->keymap = NULL;
-    vfb->sdl.enable = 0;
-    vfb->sdl.opengl = 0;
-    vfb->sdl.display = NULL;
-    vfb->sdl.xauthority = NULL;
+    return 0;
+}
+
+static int libxl__device_vfb_setdefaults(libxl__gc *gc,
+                                         libxl_device_vfb *vfb)
+{
+    libxl_defbool_setdefault(&vfb->vnc.enable, true);
+    if (libxl_defbool_val(vfb->vnc.enable)) {
+        if (!vfb->vnc.listen)
+            vfb->vnc.listen = strdup("127.0.0.1");
+        libxl_defbool_setdefault(&vfb->vnc.findunused, true);
+    }
+
+    libxl_defbool_setdefault(&vfb->sdl.enable, false);
+    if (libxl_defbool_val(vfb->sdl.enable)) {
+        libxl_defbool_setdefault(&vfb->sdl.opengl, false);
+    }
+
     return 0;
 }
 
@@ -2027,6 +2035,9 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vfb_setdefaults(gc, vfb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
@@ -2046,17 +2057,17 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
     flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
     flexarray_append_pair(back, "vnc",
-                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+                          libxl_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
     flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
     flexarray_append_pair(back, "vncdisplay",
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
-                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
+                          libxl_defbool_val(vfb->vnc.findunused) ? "1" : "0");
     flexarray_append_pair(back, "sdl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+                          libxl_defbool_val(vfb->sdl.enable) ? "1" : "0");
     flexarray_append_pair(back, "opengl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+                          libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0");
     if (vfb->sdl.xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/libxl_create.c	Fri Jan 13 17:04:57 2012 +0000
@@ -101,15 +101,9 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = 1;
 
-        b_info->u.hvm.stdvga = 0;
-        b_info->u.hvm.vnc.enable = 1;
         b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
         b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.keymap = NULL;
-        b_info->u.hvm.sdl.enable = 0;
-        b_info->u.hvm.sdl.opengl = 0;
-        b_info->u.hvm.nographic = 0;
         b_info->u.hvm.serial = NULL;
         b_info->u.hvm.boot = strdup("cda");
         b_info->u.hvm.usbdevice = NULL;
@@ -144,6 +138,28 @@ int libxl__domain_build_info_setdefaults
         libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
         libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
+
+        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
+        if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.sdl.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.sdl.opengl, false);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.disable_ticketing,
+                                     false);
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.agent_mouse, true);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.nographic, false);
+
+        libxl_defbool_setdefault(&b_info->u.hvm.gfx_passthru, false);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Jan 13 17:04:57 2012 +0000
@@ -89,7 +89,7 @@ static const libxl_vnc_info *dm_vnc(cons
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
-    return vnc && vnc->enable ? vnc : NULL;
+    return vnc && libxl_defbool_val(vnc->enable) ? vnc : NULL;
 }
 
 static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
@@ -100,7 +100,7 @@ static const libxl_sdl_info *dm_sdl(cons
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
-    return sdl && sdl->enable ? sdl : NULL;
+    return sdl && libxl_defbool_val(sdl->enable) ? sdl : NULL;
 }
 
 static const char *dm_keymap(const libxl_domain_config *guest_config)
@@ -162,13 +162,13 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (vnc->findunused) {
+        if (libxl_defbool_val(vnc->findunused)) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!sdl->opengl) {
+        if (!libxl_defbool_val(sdl->opengl)) {
             flexarray_append(dm_args, "-disable-opengl");
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
@@ -183,7 +183,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
@@ -193,7 +193,7 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb)),
                     NULL);
         }
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -246,7 +246,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -299,7 +299,7 @@ static char *dm_spice_options(libxl__gc 
         return NULL;
     }
 
-    if (!spice->disable_ticketing) {
+    if (!libxl_defbool_val(spice->disable_ticketing)) {
         if (!spice->passwd) {
             LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                        "spice ticketing is enabled but missing password");
@@ -315,12 +315,12 @@ static char *dm_spice_options(libxl__gc 
                          spice->port, spice->tls_port);
     if (spice->host)
         opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
-    if (spice->disable_ticketing)
+    if (libxl_defbool_val(spice->disable_ticketing))
         opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
     else
         opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
     opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
-                         spice->agent_mouse ? "on" : "off");
+                         libxl_defbool_val(spice->agent_mouse) ? "on" : "off");
     return opt;
 }
 
@@ -387,11 +387,11 @@ static char ** libxl__build_device_model
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        vnc->findunused ? ",to=99" : ""));
+                        libxl_defbool_val(vnc->findunused) ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        vnc->findunused ? ",to=99" : ""));
+                        libxl_defbool_val(vnc->findunused) ? ",to=99" : ""));
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -413,11 +413,11 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
-        if (b_info->u.hvm.spice.enable) {
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
             const libxl_spice_info *spice = &b_info->u.hvm.spice;
             char *spiceoptions = dm_spice_options(gc, spice);
             if (!spiceoptions)
@@ -427,7 +427,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }
 
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -487,7 +487,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Jan 13 17:04:57 2012 +0000
@@ -98,31 +98,31 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 # Complex libxl types
 #
 libxl_vnc_info = Struct("vnc_info", [
-    ("enable",        bool),
+    ("enable",        libxl_defbool),
     # "address:port" that should be listened on
     ("listen",        string),
     ("passwd",        string),
     ("display",       integer),
     # If set then try to find an unused port
-    ("findunused",    bool),
+    ("findunused",    libxl_defbool),
     ])
 
 libxl_spice_info = Struct("spice_info", [
-    ("enable",            bool),
+    ("enable",      libxl_defbool),
     # At least one of spice port or spicetls_post must be given
     ("port",        integer),
     ("tls_port",    integer),
     # Interface to bind to
     ("host",        string),
     # enable client connection with no password
-    ("disable_ticketing", bool),
+    ("disable_ticketing", libxl_defbool),
     ("passwd",      string),
-    ("agent_mouse", bool),
+    ("agent_mouse", libxl_defbool),
     ])
 
 libxl_sdl_info = Struct("sdl_info", [
-    ("enable",        bool),
-    ("opengl",        bool),
+    ("enable",        libxl_defbool),
+    ("opengl",        libxl_defbool),
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -234,15 +234,15 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align",        libxl_defbool),
                                        ("timer_mode",       integer),
                                        ("nested_hvm",       libxl_defbool),
-                                       ("nographic",        bool),
-                                       ("stdvga",           bool),
+                                       ("nographic",        libxl_defbool),
+                                       ("stdvga",           libxl_defbool),
                                        ("vnc",              libxl_vnc_info),
                                        # keyboard layout, default is en-us keyboard
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
-                                       ("gfx_passthru",     bool),
+                                       ("gfx_passthru",     libxl_defbool),
                                        
                                        ("serial",           string),
                                        ("boot",             string),
diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jan 13 17:04:57 2012 +0000
@@ -366,25 +366,34 @@ static void printf_info(int domid,
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(stdvga %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.findunused));
         printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.opengl));
+        printf("\t\t\t(nographic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nographic));
+        printf("\t\t\t(spice %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.enable));
         printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
         printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
         printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+        printf("\t\t\t(spicedisable_ticketing %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.disable_ticketing));
+        printf("\t\t\t(spiceagent_mouse %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.agent_mouse));
 
         printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(gfx_passthru %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.gfx_passthru));
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
@@ -459,13 +468,17 @@ static void printf_info(int domid,
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.findunused));
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.opengl));
         printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
         printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");
@@ -950,7 +963,7 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "vnclisten")) {
                     free(vfb->vnc.listen);
                     vfb->vnc.listen = strdup(p2 + 1);
@@ -960,14 +973,14 @@ skip:
                 } else if (!strcmp(p, "vncdisplay")) {
                     vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vnc.findunused = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.findunused, atoi(p2 + 1));
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->sdl.opengl = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.opengl, atoi(p2 + 1));
                 } else if (!strcmp(p, "display")) {
                     free(vfb->sdl.display);
                     vfb->sdl.display = strdup(p2 + 1);
@@ -1152,41 +1165,35 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            b_info->u.hvm.stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            b_info->u.hvm.vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
+        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
+        xlu_cfg_replace_string (config, "vnclisten",
+                                &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd",
+                                &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             b_info->u.hvm.vnc.display = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_get_defbool(config, "vncunused",
+                            &b_info->u.hvm.vnc.findunused, 0);
         xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
-        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            b_info->u.hvm.sdl.enable = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            b_info->u.hvm.sdl.opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            b_info->u.hvm.spice.enable = l;
+        xlu_cfg_get_defbool(config, "sdl", &b_info->u.hvm.sdl.enable, 0);
+        xlu_cfg_get_defbool(config, "opengl", &b_info->u.hvm.sdl.opengl, 0);
+        xlu_cfg_get_defbool (config, "spice", &b_info->u.hvm.spice.enable, 0);
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             b_info->u.hvm.spice.tls_port = l;
         xlu_cfg_replace_string (config, "spicehost",
                                 &b_info->u.hvm.spice.host, 0);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            b_info->u.hvm.spice.disable_ticketing = l;
+        xlu_cfg_get_defbool(config, "spicedisable_ticketing",
+                            &b_info->u.hvm.spice.disable_ticketing, 0);
         xlu_cfg_replace_string (config, "spicepasswd",
                                 &b_info->u.hvm.spice.passwd, 0);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            b_info->u.hvm.spice.agent_mouse = l;
-        else
-            b_info->u.hvm.spice.agent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            b_info->u.hvm.nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            b_info->u.hvm.gfx_passthru = l;
+        xlu_cfg_get_defbool(config, "spiceagent_mouse",
+                            &b_info->u.hvm.spice.agent_mouse, 0);
+        xlu_cfg_get_defbool(config, "nographic", &b_info->u.hvm.nographic, 0);
+        xlu_cfg_get_defbool(config, "gfx_passthru", 
+                            &b_info->u.hvm.gfx_passthru, 0);
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
diff -r 81def18dfda0 -r b8426902efa0 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Fri Jan 13 17:04:57 2012 +0000
@@ -10,6 +10,7 @@ builtins = {
     "int":                  ("int",                    "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_defbool":        ("bool option",            "%(c)s = Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,                                None),
     "libxl_mac":            ("int array",              "Mac_val(gc, lg, &%(c)s, %(o)s)",    "Val_mac(&%(c)s)"),
diff -r 81def18dfda0 -r b8426902efa0 tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 17:04:57 2012 +0000
@@ -130,6 +130,19 @@ static int string_string_tuple_array_val
 
 #endif
 
+/* Option type support as per http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php */
+#define Val_none Val_int(0)
+#define Some_val(v) Field(v,0)
+
+static value Val_some(value v)
+{
+	CAMLparam1(v);
+	CAMLlocal1(some);
+	some = caml_alloc(1, 0);
+	Store_field(some, 0, v);
+	CAMLreturn(some);
+}
+
 static value Val_mac (libxl_mac *c_val)
 {
 	CAMLparam0();
@@ -182,6 +195,33 @@ static int Uuid_val(caml_gc *gc, struct 
 	CAMLreturn(0);
 }
 
+static value Val_defbool(libxl_defbool c_val)
+{
+	CAMLparam0();
+	CAMLlocal1(v);
+
+	if (libxl_defbool_is_default(c_val))
+		v = Val_none;
+	else {
+		bool b = libxl_defbool_val(c_val);
+		v = Val_some(b ? Val_bool(true) : Val_bool(false));
+	}
+	CAMLreturn(v);
+}
+
+static libxl_defbool Defbool_val(value v)
+{
+	CAMLparam1(v);
+	libxl_defbool db;
+	if (v == Val_none)
+		libxl_defbool_unset(&db);
+	else {
+		bool b = Bool_val(Some_val(v));
+		libxl_defbool_set(&db, b);
+	}
+	return db;
+}
+
 static value Val_hwcap(libxl_hwcap *c_val)
 {
 	CAMLparam0();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTY-0001vs-0i; Mon, 16 Jan 2012 12:15: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 1RmlTL-0001LY-GT
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326716103!8680236!15
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6344 invoked from network); 16 Jan 2012 12:15:28 -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;
	16 Jan 2012 12:15:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907102"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dH032155;	Mon, 16 Jan 2012 04:15:26 -0800
MIME-Version: 1.0
X-Mercurial-Node: b8426902efa002b6941aee6dff109aa33a4372c8
Message-ID: <b8426902efa002b6941a.1326716125@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:25 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 27 of 32 RFC] libxl: use defbool for graphics
	related options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326474297 0
# Node ID b8426902efa002b6941aee6dff109aa33a4372c8
# Parent  81def18dfda0899a8c7309f284d7ee4d6009da62
libxl: use defbool for graphics related options

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/libxl.c	Fri Jan 13 17:04:57 2012 +0000
@@ -1993,16 +1993,24 @@ out:
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->vnc.enable = 1;
-    vfb->vnc.passwd = NULL;
-    vfb->vnc.listen = strdup("127.0.0.1");
-    vfb->vnc.display = 0;
-    vfb->vnc.findunused = 1;
-    vfb->keymap = NULL;
-    vfb->sdl.enable = 0;
-    vfb->sdl.opengl = 0;
-    vfb->sdl.display = NULL;
-    vfb->sdl.xauthority = NULL;
+    return 0;
+}
+
+static int libxl__device_vfb_setdefaults(libxl__gc *gc,
+                                         libxl_device_vfb *vfb)
+{
+    libxl_defbool_setdefault(&vfb->vnc.enable, true);
+    if (libxl_defbool_val(vfb->vnc.enable)) {
+        if (!vfb->vnc.listen)
+            vfb->vnc.listen = strdup("127.0.0.1");
+        libxl_defbool_setdefault(&vfb->vnc.findunused, true);
+    }
+
+    libxl_defbool_setdefault(&vfb->sdl.enable, false);
+    if (libxl_defbool_val(vfb->sdl.enable)) {
+        libxl_defbool_setdefault(&vfb->sdl.opengl, false);
+    }
+
     return 0;
 }
 
@@ -2027,6 +2035,9 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     libxl__device device;
     int rc;
 
+    rc = libxl__device_vfb_setdefaults(gc, vfb);
+    if (rc) goto out;
+
     front = flexarray_make(16, 1);
     if (!front) {
         rc = ERROR_NOMEM;
@@ -2046,17 +2057,17 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     flexarray_append_pair(back, "state", libxl__sprintf(gc, "%d", 1));
     flexarray_append_pair(back, "domain", libxl__domid_to_name(gc, domid));
     flexarray_append_pair(back, "vnc",
-                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+                          libxl_defbool_val(vfb->vnc.enable) ? "1" : "0");
     flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
     flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
     flexarray_append_pair(back, "vncdisplay",
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
-                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
+                          libxl_defbool_val(vfb->vnc.findunused) ? "1" : "0");
     flexarray_append_pair(back, "sdl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+                          libxl_defbool_val(vfb->sdl.enable) ? "1" : "0");
     flexarray_append_pair(back, "opengl",
-                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+                          libxl_defbool_val(vfb->sdl.opengl) ? "1" : "0");
     if (vfb->sdl.xauthority) {
         flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/libxl_create.c	Fri Jan 13 17:04:57 2012 +0000
@@ -101,15 +101,9 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = 1;
 
-        b_info->u.hvm.stdvga = 0;
-        b_info->u.hvm.vnc.enable = 1;
         b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
         b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.vnc.findunused = 1;
         b_info->u.hvm.keymap = NULL;
-        b_info->u.hvm.sdl.enable = 0;
-        b_info->u.hvm.sdl.opengl = 0;
-        b_info->u.hvm.nographic = 0;
         b_info->u.hvm.serial = NULL;
         b_info->u.hvm.boot = strdup("cda");
         b_info->u.hvm.usbdevice = NULL;
@@ -144,6 +138,28 @@ int libxl__domain_build_info_setdefaults
         libxl_defbool_setdefault(&b_info->u.hvm.nested_hvm, false);
         libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
+
+        libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
+        libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
+        if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.sdl.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.sdl.opengl, false);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.spice.enable, false);
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.disable_ticketing,
+                                     false);
+            libxl_defbool_setdefault(&b_info->u.hvm.spice.agent_mouse, true);
+        }
+
+        libxl_defbool_setdefault(&b_info->u.hvm.nographic, false);
+
+        libxl_defbool_setdefault(&b_info->u.hvm.gfx_passthru, false);
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         libxl_defbool_setdefault(&b_info->u.pv.e820_host, false);
diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Jan 13 17:04:57 2012 +0000
@@ -89,7 +89,7 @@ static const libxl_vnc_info *dm_vnc(cons
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
-    return vnc && vnc->enable ? vnc : NULL;
+    return vnc && libxl_defbool_val(vnc->enable) ? vnc : NULL;
 }
 
 static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
@@ -100,7 +100,7 @@ static const libxl_sdl_info *dm_sdl(cons
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
-    return sdl && sdl->enable ? sdl : NULL;
+    return sdl && libxl_defbool_val(sdl->enable) ? sdl : NULL;
 }
 
 static const char *dm_keymap(const libxl_domain_config *guest_config)
@@ -162,13 +162,13 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (vnc->findunused) {
+        if (libxl_defbool_val(vnc->findunused)) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!sdl->opengl) {
+        if (!libxl_defbool_val(sdl->opengl)) {
             flexarray_append(dm_args, "-disable-opengl");
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
@@ -183,7 +183,7 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
@@ -193,7 +193,7 @@ static char ** libxl__build_device_model
                                    libxl__sizekb_to_mb(b_info->video_memkb)),
                     NULL);
         }
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -246,7 +246,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -299,7 +299,7 @@ static char *dm_spice_options(libxl__gc 
         return NULL;
     }
 
-    if (!spice->disable_ticketing) {
+    if (!libxl_defbool_val(spice->disable_ticketing)) {
         if (!spice->passwd) {
             LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
                        "spice ticketing is enabled but missing password");
@@ -315,12 +315,12 @@ static char *dm_spice_options(libxl__gc 
                          spice->port, spice->tls_port);
     if (spice->host)
         opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
-    if (spice->disable_ticketing)
+    if (libxl_defbool_val(spice->disable_ticketing))
         opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
     else
         opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
     opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
-                         spice->agent_mouse ? "on" : "off");
+                         libxl_defbool_val(spice->agent_mouse) ? "on" : "off");
     return opt;
 }
 
@@ -387,11 +387,11 @@ static char ** libxl__build_device_model
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        vnc->findunused ? ",to=99" : ""));
+                        libxl_defbool_val(vnc->findunused) ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        vnc->findunused ? ",to=99" : ""));
+                        libxl_defbool_val(vnc->findunused) ? ",to=99" : ""));
     }
     if (sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -413,11 +413,11 @@ static char ** libxl__build_device_model
             flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
         }
 
-        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+        if (libxl_defbool_val(b_info->u.hvm.nographic) && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
 
-        if (b_info->u.hvm.spice.enable) {
+        if (libxl_defbool_val(b_info->u.hvm.spice.enable)) {
             const libxl_spice_info *spice = &b_info->u.hvm.spice;
             char *spiceoptions = dm_spice_options(gc, spice);
             if (!spiceoptions)
@@ -427,7 +427,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, spiceoptions);
         }
 
-        if (b_info->u.hvm.stdvga) {
+        if (libxl_defbool_val(b_info->u.hvm.stdvga)) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -487,7 +487,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (b_info->u.hvm.gfx_passthru) {
+        if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Fri Jan 13 17:04:57 2012 +0000
@@ -98,31 +98,31 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 # Complex libxl types
 #
 libxl_vnc_info = Struct("vnc_info", [
-    ("enable",        bool),
+    ("enable",        libxl_defbool),
     # "address:port" that should be listened on
     ("listen",        string),
     ("passwd",        string),
     ("display",       integer),
     # If set then try to find an unused port
-    ("findunused",    bool),
+    ("findunused",    libxl_defbool),
     ])
 
 libxl_spice_info = Struct("spice_info", [
-    ("enable",            bool),
+    ("enable",      libxl_defbool),
     # At least one of spice port or spicetls_post must be given
     ("port",        integer),
     ("tls_port",    integer),
     # Interface to bind to
     ("host",        string),
     # enable client connection with no password
-    ("disable_ticketing", bool),
+    ("disable_ticketing", libxl_defbool),
     ("passwd",      string),
-    ("agent_mouse", bool),
+    ("agent_mouse", libxl_defbool),
     ])
 
 libxl_sdl_info = Struct("sdl_info", [
-    ("enable",        bool),
-    ("opengl",        bool),
+    ("enable",        libxl_defbool),
+    ("opengl",        libxl_defbool),
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -234,15 +234,15 @@ libxl_domain_build_info = Struct("domain
                                        ("vpt_align",        libxl_defbool),
                                        ("timer_mode",       integer),
                                        ("nested_hvm",       libxl_defbool),
-                                       ("nographic",        bool),
-                                       ("stdvga",           bool),
+                                       ("nographic",        libxl_defbool),
+                                       ("stdvga",           libxl_defbool),
                                        ("vnc",              libxl_vnc_info),
                                        # keyboard layout, default is en-us keyboard
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
-                                       ("gfx_passthru",     bool),
+                                       ("gfx_passthru",     libxl_defbool),
                                        
                                        ("serial",           string),
                                        ("boot",             string),
diff -r 81def18dfda0 -r b8426902efa0 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jan 13 17:04:57 2012 +0000
@@ -366,25 +366,34 @@ static void printf_info(int domid,
         printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
         printf("\t\t\t(nestedhvm %s)\n",
                libxl_defbool_to_string(b_info->u.hvm.nested_hvm));
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(stdvga %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.stdvga));
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.vnc.findunused));
         printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.sdl.opengl));
+        printf("\t\t\t(nographic %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.nographic));
+        printf("\t\t\t(spice %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.enable));
         printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
         printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
         printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+        printf("\t\t\t(spicedisable_ticketing %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.disable_ticketing));
+        printf("\t\t\t(spiceagent_mouse %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.spice.agent_mouse));
 
         printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(gfx_passthru %s)\n",
+               libxl_defbool_to_string(b_info->u.hvm.gfx_passthru));
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %s)\n", libxl_defbool_to_string(b_info->u.hvm.usb));
@@ -459,13 +468,17 @@ static void printf_info(int domid,
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnc %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.enable));
         printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(vncunused %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].vnc.findunused));
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(sdl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.enable));
+        printf("\t\t\t(opengl %s)\n",
+               libxl_defbool_to_string(d_config->vfbs[i].sdl.opengl));
         printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
         printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");
@@ -950,7 +963,7 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "vnclisten")) {
                     free(vfb->vnc.listen);
                     vfb->vnc.listen = strdup(p2 + 1);
@@ -960,14 +973,14 @@ skip:
                 } else if (!strcmp(p, "vncdisplay")) {
                     vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vnc.findunused = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->vnc.findunused, atoi(p2 + 1));
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl.enable = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.enable, atoi(p2 + 1));
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->sdl.opengl = atoi(p2 + 1);
+                    libxl_defbool_set(&vfb->sdl.opengl, atoi(p2 + 1));
                 } else if (!strcmp(p, "display")) {
                     free(vfb->sdl.display);
                     vfb->sdl.display = strdup(p2 + 1);
@@ -1152,41 +1165,35 @@ skip_vfb:
 #undef parse_extra_args
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            b_info->u.hvm.stdvga = l;
-        if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            b_info->u.hvm.vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
+        xlu_cfg_get_defbool(config, "stdvga", &b_info->u.hvm.stdvga, 0);
+        xlu_cfg_get_defbool(config, "vnc", &b_info->u.hvm.vnc.enable, 0);
+        xlu_cfg_replace_string (config, "vnclisten",
+                                &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd",
+                                &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
             b_info->u.hvm.vnc.display = l;
-        if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_get_defbool(config, "vncunused",
+                            &b_info->u.hvm.vnc.findunused, 0);
         xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
-        if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            b_info->u.hvm.sdl.enable = l;
-        if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            b_info->u.hvm.sdl.opengl = l;
-        if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            b_info->u.hvm.spice.enable = l;
+        xlu_cfg_get_defbool(config, "sdl", &b_info->u.hvm.sdl.enable, 0);
+        xlu_cfg_get_defbool(config, "opengl", &b_info->u.hvm.sdl.opengl, 0);
+        xlu_cfg_get_defbool (config, "spice", &b_info->u.hvm.spice.enable, 0);
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
             b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
             b_info->u.hvm.spice.tls_port = l;
         xlu_cfg_replace_string (config, "spicehost",
                                 &b_info->u.hvm.spice.host, 0);
-        if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            b_info->u.hvm.spice.disable_ticketing = l;
+        xlu_cfg_get_defbool(config, "spicedisable_ticketing",
+                            &b_info->u.hvm.spice.disable_ticketing, 0);
         xlu_cfg_replace_string (config, "spicepasswd",
                                 &b_info->u.hvm.spice.passwd, 0);
-        if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            b_info->u.hvm.spice.agent_mouse = l;
-        else
-            b_info->u.hvm.spice.agent_mouse = 1;
-        if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            b_info->u.hvm.nographic = l;
-        if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            b_info->u.hvm.gfx_passthru = l;
+        xlu_cfg_get_defbool(config, "spiceagent_mouse",
+                            &b_info->u.hvm.spice.agent_mouse, 0);
+        xlu_cfg_get_defbool(config, "nographic", &b_info->u.hvm.nographic, 0);
+        xlu_cfg_get_defbool(config, "gfx_passthru", 
+                            &b_info->u.hvm.gfx_passthru, 0);
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         xlu_cfg_get_defbool(config, "usb", &b_info->u.hvm.usb, 0);
diff -r 81def18dfda0 -r b8426902efa0 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Fri Jan 13 17:04:57 2012 +0000
@@ -10,6 +10,7 @@ builtins = {
     "int":                  ("int",                    "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
     "char *":               ("string",                 "%(c)s = dup_String_val(gc, %(o)s)", "caml_copy_string(%(c)s)"),
     "libxl_domid":          ("domid",                  "%(c)s = Int_val(%(o)s)",            "Val_int(%(c)s)"  ),
+    "libxl_defbool":        ("bool option",            "%(c)s = Defbool_val(%(o)s)",        "Val_defbool(%(c)s)" ),
     "libxl_uuid":           ("int array",              "Uuid_val(gc, lg, &%(c)s, %(o)s)",   "Val_uuid(&%(c)s)"),
     "libxl_key_value_list": ("(string * string) list", None,                                None),
     "libxl_mac":            ("int array",              "Mac_val(gc, lg, &%(c)s, %(o)s)",    "Val_mac(&%(c)s)"),
diff -r 81def18dfda0 -r b8426902efa0 tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 16:17:49 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 17:04:57 2012 +0000
@@ -130,6 +130,19 @@ static int string_string_tuple_array_val
 
 #endif
 
+/* Option type support as per http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php */
+#define Val_none Val_int(0)
+#define Some_val(v) Field(v,0)
+
+static value Val_some(value v)
+{
+	CAMLparam1(v);
+	CAMLlocal1(some);
+	some = caml_alloc(1, 0);
+	Store_field(some, 0, v);
+	CAMLreturn(some);
+}
+
 static value Val_mac (libxl_mac *c_val)
 {
 	CAMLparam0();
@@ -182,6 +195,33 @@ static int Uuid_val(caml_gc *gc, struct 
 	CAMLreturn(0);
 }
 
+static value Val_defbool(libxl_defbool c_val)
+{
+	CAMLparam0();
+	CAMLlocal1(v);
+
+	if (libxl_defbool_is_default(c_val))
+		v = Val_none;
+	else {
+		bool b = libxl_defbool_val(c_val);
+		v = Val_some(b ? Val_bool(true) : Val_bool(false));
+	}
+	CAMLreturn(v);
+}
+
+static libxl_defbool Defbool_val(value v)
+{
+	CAMLparam1(v);
+	libxl_defbool db;
+	if (v == Val_none)
+		libxl_defbool_unset(&db);
+	else {
+		bool b = Bool_val(Some_val(v));
+		libxl_defbool_set(&db, b);
+	}
+	return db;
+}
+
 static value Val_hwcap(libxl_hwcap *c_val)
 {
 	CAMLparam0();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTY-0001xc-RL; Mon, 16 Jan 2012 12:15:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTL-0001Lr-PB
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326716101!55859788!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10778 invoked from network); 16 Jan 2012 12:15:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671928"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dI032155;	Mon, 16 Jan 2012 04:15:27 -0800
MIME-Version: 1.0
X-Mercurial-Node: 90fe4b95bdc935b2d5328603aa77d4de37253c36
Message-ID: <90fe4b95bdc935b2d532.1326716126@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 28 of 32 RFC] libxl: initialise NULL==default
 members of build info later
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326712734 0
# Node ID 90fe4b95bdc935b2d5328603aa77d4de37253c36
# Parent  b8426902efa002b6941aee6dff109aa33a4372c8
libxl: initialise NULL==default members of build info later.

Specifically do it at setdefaults time instead of init time.

I'm not entirely sure if video_memkb can legitimately be 0. Hopefully this
corresponds to 'nographics' instead.

I think the rest are reasonable although it's not clear that shadow_memkb
doesn't belong in u.hvm I didn't change that here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b8426902efa0 -r 90fe4b95bdc9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 13 17:04:57 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 11:18:54 2012 +0000
@@ -82,12 +82,6 @@ int libxl_init_build_info(libxl_ctx *ctx
                           const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_vcpus = 1;
-    b_info->cur_vcpus = 1;
-    b_info->max_memkb = 32 * 1024;
-    b_info->target_memkb = b_info->max_memkb;
-    b_info->cpuid = NULL;
-    b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
     b_info->device_model_version =
@@ -97,16 +91,7 @@ int libxl_init_build_info(libxl_ctx *ctx
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->video_memkb = 8 * 1024;
-        b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = 1;
-
-        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
-        b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.keymap = NULL;
-        b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.boot = strdup("cda");
-        b_info->u.hvm.usbdevice = NULL;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -123,9 +108,21 @@ int libxl_init_build_info(libxl_ctx *ctx
 int libxl__domain_build_info_setdefaults(libxl__gc *gc,
                                          libxl_domain_build_info *b_info)
 {
+    if (!b_info->max_vcpus)
+        b_info->max_vcpus = 1;
+    if (!b_info->cur_vcpus)
+        b_info->cur_vcpus = 1;
+    if (!b_info->max_memkb)
+        b_info->max_memkb = 32 * 1024;
+    if (!b_info->target_memkb)
+        b_info->target_memkb = b_info->max_memkb;
+
     libxl_defbool_setdefault(&b_info->disable_migrate, false);
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (!b_info->video_memkb)
+            b_info->video_memkb = 8 * 1024;
+
         libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
         libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
         libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
@@ -139,10 +136,15 @@ int libxl__domain_build_info_setdefaults
         libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
 
+        if (!b_info->u.hvm.boot)
+            b_info->u.hvm.boot = strdup("cda");
+
         libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
+            if (!b_info->u.hvm.vnc.listen)
+                b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
         }
 
         libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlTY-0001xc-RL; Mon, 16 Jan 2012 12:15:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmlTL-0001Lr-PB
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326716101!55859788!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10778 invoked from network); 16 Jan 2012 12:15:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671928"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15: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
	q0GCF0dI032155;	Mon, 16 Jan 2012 04:15:27 -0800
MIME-Version: 1.0
X-Mercurial-Node: 90fe4b95bdc935b2d5328603aa77d4de37253c36
Message-ID: <90fe4b95bdc935b2d532.1326716126@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 28 of 32 RFC] libxl: initialise NULL==default
 members of build info later
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326712734 0
# Node ID 90fe4b95bdc935b2d5328603aa77d4de37253c36
# Parent  b8426902efa002b6941aee6dff109aa33a4372c8
libxl: initialise NULL==default members of build info later.

Specifically do it at setdefaults time instead of init time.

I'm not entirely sure if video_memkb can legitimately be 0. Hopefully this
corresponds to 'nographics' instead.

I think the rest are reasonable although it's not clear that shadow_memkb
doesn't belong in u.hvm I didn't change that here.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b8426902efa0 -r 90fe4b95bdc9 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 13 17:04:57 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 11:18:54 2012 +0000
@@ -82,12 +82,6 @@ int libxl_init_build_info(libxl_ctx *ctx
                           const libxl_domain_create_info *c_info)
 {
     memset(b_info, '\0', sizeof(*b_info));
-    b_info->max_vcpus = 1;
-    b_info->cur_vcpus = 1;
-    b_info->max_memkb = 32 * 1024;
-    b_info->target_memkb = b_info->max_memkb;
-    b_info->cpuid = NULL;
-    b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
 
     b_info->device_model_version =
@@ -97,16 +91,7 @@ int libxl_init_build_info(libxl_ctx *ctx
 
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        b_info->video_memkb = 8 * 1024;
-        b_info->u.hvm.firmware = NULL;
         b_info->u.hvm.timer_mode = 1;
-
-        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
-        b_info->u.hvm.vnc.display = 0;
-        b_info->u.hvm.keymap = NULL;
-        b_info->u.hvm.serial = NULL;
-        b_info->u.hvm.boot = strdup("cda");
-        b_info->u.hvm.usbdevice = NULL;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -123,9 +108,21 @@ int libxl_init_build_info(libxl_ctx *ctx
 int libxl__domain_build_info_setdefaults(libxl__gc *gc,
                                          libxl_domain_build_info *b_info)
 {
+    if (!b_info->max_vcpus)
+        b_info->max_vcpus = 1;
+    if (!b_info->cur_vcpus)
+        b_info->cur_vcpus = 1;
+    if (!b_info->max_memkb)
+        b_info->max_memkb = 32 * 1024;
+    if (!b_info->target_memkb)
+        b_info->target_memkb = b_info->max_memkb;
+
     libxl_defbool_setdefault(&b_info->disable_migrate, false);
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
+        if (!b_info->video_memkb)
+            b_info->video_memkb = 8 * 1024;
+
         libxl_defbool_setdefault(&b_info->u.hvm.pae, true);
         libxl_defbool_setdefault(&b_info->u.hvm.apic, true);
         libxl_defbool_setdefault(&b_info->u.hvm.acpi, true);
@@ -139,10 +136,15 @@ int libxl__domain_build_info_setdefaults
         libxl_defbool_setdefault(&b_info->u.hvm.usb, false);
         libxl_defbool_setdefault(&b_info->u.hvm.xen_platform_pci, true);
 
+        if (!b_info->u.hvm.boot)
+            b_info->u.hvm.boot = strdup("cda");
+
         libxl_defbool_setdefault(&b_info->u.hvm.stdvga, false);
         libxl_defbool_setdefault(&b_info->u.hvm.vnc.enable, true);
         if (libxl_defbool_val(b_info->u.hvm.vnc.enable)) {
             libxl_defbool_setdefault(&b_info->u.hvm.vnc.findunused, true);
+            if (!b_info->u.hvm.vnc.listen)
+                b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
         }
 
         libxl_defbool_setdefault(&b_info->u.hvm.sdl.enable, false);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTa-00020U-2P; Mon, 16 Jan 2012 12:15: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 1RmlTN-0001Oj-E4
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326716101!55859788!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10905 invoked from network); 16 Jan 2012 12:15:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671937"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:30 -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
	q0GCF0dL032155;	Mon, 16 Jan 2012 04:15:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: a2dc899d0f229d82baca92a06b3b7a5b4d918324
Message-ID: <a2dc899d0f229d82baca.1326716129@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:29 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 31 of 32 RFC] libxl: switch device model
 selection over to libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326713598 0
# Node ID a2dc899d0f229d82baca92a06b3b7a5b4d918324
# Parent  7ffc8e870fbb5a9edcd6f8d46f2b0296d38cb5ed
libxl: switch device model selection over to libxl_defbool

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 16 11:33:18 2012 +0000
@@ -2445,7 +2445,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (b_info->device_model_stubdomain)
+        if (libxl_defbool_val(b_info->device_model_stubdomain))
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 11:33:18 2012 +0000
@@ -84,17 +84,18 @@ int libxl_init_build_info(libxl_ctx *ctx
     memset(b_info, '\0', sizeof(*b_info));
     b_info->type = c_info->type;
 
-    b_info->device_model_version =
-        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-    b_info->device_model_stubdomain = false;
-    b_info->device_model = NULL;
-
     return 0;
 }
 
 int libxl__domain_build_info_setdefaults(libxl__gc *gc,
                                          libxl_domain_build_info *b_info)
 {
+    if (!b_info->device_model_version)
+        b_info->device_model_version =
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->cur_vcpus)
diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 16 11:33:18 2012 +0000
@@ -47,7 +47,7 @@ const char *libxl__domain_device_model(l
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
 
-    if (info->device_model_stubdomain)
+    if (libxl_defbool_val(info->device_model_stubdomain))
         return NULL;
 
     if (info->device_model) {
@@ -921,7 +921,7 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (b_info->device_model_stubdomain) {
+    if (libxl_defbool_val(b_info->device_model_stubdomain)) {
         rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 16 11:33:18 2012 +0000
@@ -218,8 +218,8 @@ libxl_domain_build_info = Struct("domain
     ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
+    ("device_model_stubdomain", libxl_defbool),
+    # if you set device_model you must set device_model_version too
     ("device_model",     string),
 
     # extra parameters pass directly to qemu, NULL terminated
diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 16 11:33:18 2012 +0000
@@ -1166,8 +1166,8 @@ skip_vfb:
         }
     } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        b_info->device_model_stubdomain = l;
+    xlu_cfg_get_defbool (config, "device_model_stubdomain_override",
+                         &b_info->device_model_stubdomain, 0);
 
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:15:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:15:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTa-00020U-2P; Mon, 16 Jan 2012 12:15: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 1RmlTN-0001Oj-E4
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:15:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326716101!55859788!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10905 invoked from network); 16 Jan 2012 12:15:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:15:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177671937"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:15:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:15:30 -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
	q0GCF0dL032155;	Mon, 16 Jan 2012 04:15:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: a2dc899d0f229d82baca92a06b3b7a5b4d918324
Message-ID: <a2dc899d0f229d82baca.1326716129@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1326716098@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 16 Jan 2012 12:15:29 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 31 of 32 RFC] libxl: switch device model
 selection over to libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326713598 0
# Node ID a2dc899d0f229d82baca92a06b3b7a5b4d918324
# Parent  7ffc8e870fbb5a9edcd6f8d46f2b0296d38cb5ed
libxl: switch device model selection over to libxl_defbool

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 16 11:33:18 2012 +0000
@@ -2445,7 +2445,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (b_info->device_model_stubdomain)
+        if (libxl_defbool_val(b_info->device_model_stubdomain))
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 16 11:33:18 2012 +0000
@@ -84,17 +84,18 @@ int libxl_init_build_info(libxl_ctx *ctx
     memset(b_info, '\0', sizeof(*b_info));
     b_info->type = c_info->type;
 
-    b_info->device_model_version =
-        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-    b_info->device_model_stubdomain = false;
-    b_info->device_model = NULL;
-
     return 0;
 }
 
 int libxl__domain_build_info_setdefaults(libxl__gc *gc,
                                          libxl_domain_build_info *b_info)
 {
+    if (!b_info->device_model_version)
+        b_info->device_model_version =
+            LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+
+    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
+
     if (!b_info->max_vcpus)
         b_info->max_vcpus = 1;
     if (!b_info->cur_vcpus)
diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 16 11:33:18 2012 +0000
@@ -47,7 +47,7 @@ const char *libxl__domain_device_model(l
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
 
-    if (info->device_model_stubdomain)
+    if (libxl_defbool_val(info->device_model_stubdomain))
         return NULL;
 
     if (info->device_model) {
@@ -921,7 +921,7 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (b_info->device_model_stubdomain) {
+    if (libxl_defbool_val(b_info->device_model_stubdomain)) {
         rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 16 11:33:18 2012 +0000
@@ -218,8 +218,8 @@ libxl_domain_build_info = Struct("domain
     ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
+    ("device_model_stubdomain", libxl_defbool),
+    # if you set device_model you must set device_model_version too
     ("device_model",     string),
 
     # extra parameters pass directly to qemu, NULL terminated
diff -r 7ffc8e870fbb -r a2dc899d0f22 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 16 11:29:10 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 16 11:33:18 2012 +0000
@@ -1166,8 +1166,8 @@ skip_vfb:
         }
     } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
-    if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        b_info->device_model_stubdomain = l;
+    xlu_cfg_get_defbool (config, "device_model_stubdomain_override",
+                         &b_info->device_model_stubdomain, 0);
 
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTr-0002bj-Dk; Mon, 16 Jan 2012 12:16: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 1RmlTn-0002I5-BL; Mon, 16 Jan 2012 12:16:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326716157!9257316!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21658 invoked from network); 16 Jan 2012 12:15:57 -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;
	16 Jan 2012 12:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10046412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12:15:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 12:15:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 12:15:56 +0000
In-Reply-To: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326716156.17210.422.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [PATCH 0/5] ARM: Start working on tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 12:02 +0000, Ian Campbell wrote:
> Now that we have an ARM build environment[0] I've made a very basic
> start on getting the Xen tools for the ARMv7 w/ virt extensions port to
> compile. A short series follows. Nothing too earth shatteringly
> exciting...

I made a typo in the xen-devel address on first posting of the series so
I'm resending. Apologies for the noise.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:16:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlTr-0002bj-Dk; Mon, 16 Jan 2012 12:16: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 1RmlTn-0002I5-BL; Mon, 16 Jan 2012 12:16:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326716157!9257316!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21658 invoked from network); 16 Jan 2012 12:15:57 -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;
	16 Jan 2012 12:15:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10046412"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12:15:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 12:15:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 12:15:56 +0000
In-Reply-To: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326716156.17210.422.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [PATCH 0/5] ARM: Start working on tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 12:02 +0000, Ian Campbell wrote:
> Now that we have an ARM build environment[0] I've made a very basic
> start on getting the Xen tools for the ARMv7 w/ virt extensions port to
> compile. A short series follows. Nothing too earth shatteringly
> exciting...

I made a typo in the xen-devel address on first posting of the series so
I'm resending. Apologies for the noise.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlU8-00039o-Bd; Mon, 16 Jan 2012 12:16: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 1RmlU5-0002t0-N1; Mon, 16 Jan 2012 12:16:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326716174!11067432!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4830 invoked from network); 16 Jan 2012 12:16:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177672050"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:16:13 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTX032222;	Mon, 16 Jan 2012 04:16:12 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:06 +0000
Message-ID: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlU8-00039o-Bd; Mon, 16 Jan 2012 12:16: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 1RmlU5-0002t0-N1; Mon, 16 Jan 2012 12:16:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326716174!11067432!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4830 invoked from network); 16 Jan 2012 12:16:15 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:16:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177672050"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:16:13 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTX032222;	Mon, 16 Jan 2012 04:16:12 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:06 +0000
Message-ID: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 1/5] arm: add stub hvm/save.h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/public/arch-arm/hvm/save.h |   39 ++++++++++++++++++++++++++++++++
 xen/include/public/hvm/save.h          |    2 +
 2 files changed, 41 insertions(+), 0 deletions(-)
 create mode 100644 xen/include/public/arch-arm/hvm/save.h

diff --git a/xen/include/public/arch-arm/hvm/save.h b/xen/include/public/arch-arm/hvm/save.h
new file mode 100644
index 0000000..ec61298
--- /dev/null
+++ b/xen/include/public/arch-arm/hvm/save.h
@@ -0,0 +1,39 @@
+/*
+ * Structure definitions for HVM state that is held by Xen and must
+ * be saved along with the domain's memory and device-model state.
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_HVM_SAVE_ARM_H__
+#define __XEN_PUBLIC_HVM_SAVE_ARM_H__
+
+#endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/hvm/save.h b/xen/include/public/hvm/save.h
index d0f2661..58f8433 100644
--- a/xen/include/public/hvm/save.h
+++ b/xen/include/public/hvm/save.h
@@ -104,6 +104,8 @@ DECLARE_HVM_SAVE_TYPE(END, 0, struct hvm_save_end);
 #include "../arch-x86/hvm/save.h"
 #elif defined(__ia64__)
 #include "../arch-ia64/hvm/save.h"
+#elif defined(__arm__)
+#include "../arch-arm/hvm/save.h"
 #else
 #error "unsupported architecture"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlU9-0003BG-0r; Mon, 16 Jan 2012 12:16: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 1RmlU7-0002ve-14; Mon, 16 Jan 2012 12:16:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326716174!11067432!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4894 invoked from network); 16 Jan 2012 12:16:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:16:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177672055"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:16:15 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTZ032222;	Mon, 16 Jan 2012 04:16:14 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:08 +0000
Message-ID: <1326716171-4298-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] libxl: do not allocate e820 for non x86
	guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ++-
 tools/libxl/libxl_pci.c    |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ebf2ed7..1c04e22 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -640,7 +640,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
+#if defined(__i386__) || defined(__x86_64__)
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         d_config->b_info.u.pv.e820_host) {
         int rc;
@@ -650,6 +650,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
                       rc, errno);
     }
+#endif
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 8b2a1c5..cae4fe6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1163,6 +1163,7 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 static const char *e820_names(int type)
 {
     switch (type) {
@@ -1404,6 +1405,7 @@ int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_conf
     }
     return 0;
 }
+#endif
 
 /*
  * Local variables:
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:16:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmlU9-0003BG-0r; Mon, 16 Jan 2012 12:16: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 1RmlU7-0002ve-14; Mon, 16 Jan 2012 12:16:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326716174!11067432!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4894 invoked from network); 16 Jan 2012 12:16:16 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:16:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177672055"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:16:15 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTZ032222;	Mon, 16 Jan 2012 04:16:14 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:08 +0000
Message-ID: <1326716171-4298-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 3/5] libxl: do not allocate e820 for non x86
	guests.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_create.c |    3 ++-
 tools/libxl/libxl_pci.c    |    2 ++
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index ebf2ed7..1c04e22 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -640,7 +640,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
             goto error_out;
         }
     }
-
+#if defined(__i386__) || defined(__x86_64__)
     if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
         d_config->b_info.u.pv.e820_host) {
         int rc;
@@ -650,6 +650,7 @@ static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
                       "Failed while collecting E820 with: %d (errno:%d)\n",
                       rc, errno);
     }
+#endif
     if ( cb && (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM ||
                 (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV &&
                  d_config->b_info.u.pv.bootloader ))) {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 8b2a1c5..cae4fe6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1163,6 +1163,7 @@ int libxl__device_pci_destroy_all(libxl__gc *gc, uint32_t domid)
     return 0;
 }
 
+#if defined(__i386__) || defined(__x86_64__)
 static const char *e820_names(int type)
 {
     switch (type) {
@@ -1404,6 +1405,7 @@ int libxl__e820_alloc(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_conf
     }
     return 0;
 }
+#endif
 
 /*
  * Local variables:
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlU9-0003DR-TW; Mon, 16 Jan 2012 12:16: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 1RmlU7-0002vy-7U; Mon, 16 Jan 2012 12:16:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326716175!9313871!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16898 invoked from network); 16 Jan 2012 12:16:16 -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;
	16 Jan 2012 12:16:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907167"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:16:14 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTY032222;	Mon, 16 Jan 2012 04:16:13 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:07 +0000
Message-ID: <1326716171-4298-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] arm: allow libxc to build (untested)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Config.mk                 |    2 +-
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |   70 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   61 +++++++++++++++++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 6 files changed, 139 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/Config.mk b/Config.mk
index 1c229c0..13a569e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,7 +13,7 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
-                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
+                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
 
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..b5bd7fb 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -6,6 +6,7 @@ MINOR    = 0
 
 CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
 CTRL_SRCS-y       += xc_cpupool.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..9009295
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,70 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* default to trying to map the page */
+    /* TODO consult p2m */
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch,
+                            struct xc_core_arch_context *arch_ctxt,
+                            xc_dominfo_t *info,
+                            shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    /* TODO return the memory map! */
+    ERROR("%s is not implemented yet\n", __func__);
+    errno = ENOSYS;
+    return -1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    /* All domains are auto_translated_physmap mode. */
+    return 1;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                     shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                     unsigned long *pfnp)
+{
+    /* All domains are auto_translated_physmap mode. */
+    errno = ENOSYS;
+    return -1;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..a2ef5a8
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,61 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2007 Isaku Yamahata <yamahata at valinux co jp>
+ *                    VA Linux Systems Japan K.K.
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 1e149c1..1054584 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -81,6 +81,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dsb" : : : "memory")
+#define xen_rmb()  asm volatile ("dsb" : : : "memory")
+#define xen_wmb()  asm volatile ("dsb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlU9-0003DR-TW; Mon, 16 Jan 2012 12:16: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 1RmlU7-0002vy-7U; Mon, 16 Jan 2012 12:16:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326716175!9313871!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16898 invoked from network); 16 Jan 2012 12:16:16 -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;
	16 Jan 2012 12:16:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907167"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:16:14 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTY032222;	Mon, 16 Jan 2012 04:16:13 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:07 +0000
Message-ID: <1326716171-4298-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 2/5] arm: allow libxc to build (untested)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Config.mk                 |    2 +-
 tools/libxc/Makefile      |    1 +
 tools/libxc/xc_core.h     |    2 +
 tools/libxc/xc_core_arm.c |   70 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_core_arm.h |   61 +++++++++++++++++++++++++++++++++++++++
 tools/libxc/xenctrl.h     |    4 ++
 6 files changed, 139 insertions(+), 1 deletions(-)
 create mode 100644 tools/libxc/xc_core_arm.c
 create mode 100644 tools/libxc/xc_core_arm.h

diff --git a/Config.mk b/Config.mk
index 1c229c0..13a569e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -13,7 +13,7 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
 debug ?= y
 
 XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
-                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
+                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
 XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
 XEN_OS              ?= $(shell uname -s)
 
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b5e7022..b5bd7fb 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -6,6 +6,7 @@ MINOR    = 0
 
 CTRL_SRCS-y       :=
 CTRL_SRCS-y       += xc_core.c
+CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
 CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
 CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
 CTRL_SRCS-y       += xc_cpupool.c
diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
index 1e88a75..358a8c1 100644
--- a/tools/libxc/xc_core.h
+++ b/tools/libxc/xc_core.h
@@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
 # include "xc_core_x86.h"
 #elif defined (__ia64__)
 # include "xc_core_ia64.h"
+#elif defined (__arm__)
+# include "xc_core_arm.h"
 #else
 # error "unsupported architecture"
 #endif
diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
new file mode 100644
index 0000000..9009295
--- /dev/null
+++ b/tools/libxc/xc_core_arm.c
@@ -0,0 +1,70 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2012 Citrix Systems Ltd.
+ */
+
+#include "xg_private.h"
+#include "xc_core.h"
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn)
+{
+    /* default to trying to map the page */
+    /* TODO consult p2m */
+    return 1;
+}
+
+int
+xc_core_arch_memory_map_get(xc_interface *xch,
+                            struct xc_core_arch_context *arch_ctxt,
+                            xc_dominfo_t *info,
+                            shared_info_any_t *live_shinfo,
+                            xc_core_memory_map_t **mapp,
+                            unsigned int *nr_entries)
+{
+    /* TODO return the memory map! */
+    ERROR("%s is not implemented yet\n", __func__);
+    errno = ENOSYS;
+    return -1;
+}
+
+int
+xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
+{
+    /* All domains are auto_translated_physmap mode. */
+    return 1;
+}
+
+int
+xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
+                     shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
+                     unsigned long *pfnp)
+{
+    /* All domains are auto_translated_physmap mode. */
+    errno = ENOSYS;
+    return -1;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
new file mode 100644
index 0000000..a2ef5a8
--- /dev/null
+++ b/tools/libxc/xc_core_arm.h
@@ -0,0 +1,61 @@
+/*
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ * Copyright (c) 2007 Isaku Yamahata <yamahata at valinux co jp>
+ *                    VA Linux Systems Japan K.K.
+ *
+ */
+
+#ifndef XC_CORE_ARM_H
+#define XC_CORE_ARM_H
+
+#define ELF_ARCH_DATA           ELFDATA2LSB
+#define ELF_ARCH_MACHINE        EM_ARM
+
+struct xc_core_arch_context {
+    /* nothing */
+};
+
+#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
+#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
+                                                                (0)
+#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
+
+int
+xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
+                              unsigned long pfn);
+static inline int
+xc_core_arch_context_get_shdr(xc_interface *xch,
+                              struct xc_core_arch_context *arch_ctxt, 
+                              struct xc_core_section_headers *sheaders,
+                              struct xc_core_strtab *strtab,
+                              uint64_t *filesz, uint64_t offset)
+{
+    *filesz = 0;
+    return 0;
+}
+
+#endif /* XC_CORE_ARM_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 1e149c1..1054584 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -81,6 +81,10 @@
 #define xen_mb()   asm volatile ("mf" ::: "memory")
 #define xen_rmb()  asm volatile ("mf" ::: "memory")
 #define xen_wmb()  asm volatile ("mf" ::: "memory")
+#elif defined(__arm__)
+#define xen_mb()   asm volatile ("dsb" : : : "memory")
+#define xen_rmb()  asm volatile ("dsb" : : : "memory")
+#define xen_wmb()  asm volatile ("dsb" : : : "memory")
 #else
 #error "Define barriers"
 #endif
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlUD-0003LP-1s; Mon, 16 Jan 2012 12:16: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 1RmlU8-0002yK-3U; Mon, 16 Jan 2012 12:16:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326716175!9313871!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16993 invoked from network); 16 Jan 2012 12:16:17 -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;
	16 Jan 2012 12:16:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907169"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:17 -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, 16 Jan 2012 07:16:17 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTa032222;	Mon, 16 Jan 2012 04:16:15 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:09 +0000
Message-ID: <1326716171-4298-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] blktap2/libvhd: Build shared objects using
	-fPIC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap2/vhd/lib/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/blktap2/vhd/lib/Makefile b/tools/blktap2/vhd/lib/Makefile
index 97379c1..8ee169e 100644
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -45,27 +45,32 @@ LIB-SRCS        += atomicio.c
 LIB-OBJS         = $(patsubst %.c,%.o,$(LIB-SRCS))
 LIB-OBJS        += $(LVM-UTIL-OBJ)
 
+LIB-PICOBJS      = $(patsubst %.o,%.opic,$(LIB-OBJS))
+
 LIBVHD           = libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 all: build
 
-build: $(LIBVHD-BUILD)
+build: libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 libvhd.a: $(LIB-OBJS)
+	$(AR) rc $@ $^
+
+libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR): $(LIB-PICOBJS)
 	$(CC) -Wl,$(SONAME_LDFLAG),$(LIBVHD-SONAME) $(SHLIB_LDFLAGS) \
 		$(LDFLAGS) -o libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $^ $(LIBS)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) libvhd.so
-	$(AR) rc $@ $^
 
 install: all
 	$(INSTALL_DIR) -p $(DESTDIR)$(INST-DIR)
-	$(INSTALL_PROG) $(LIBVHD) $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.a $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)/libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) $(DESTDIR)$(INST-DIR)/libvhd.so
 
 clean:
-	rm -rf *.a *.so* *.o *~ $(DEPS) $(LIBVHD)
+	rm -rf *.a *.so* *.o *.opic *~ $(DEPS) $(LIBVHD)
 
 .PHONY: all build clean install libvhd
 
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlUD-0003LP-1s; Mon, 16 Jan 2012 12:16: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 1RmlU8-0002yK-3U; Mon, 16 Jan 2012 12:16:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326716175!9313871!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16993 invoked from network); 16 Jan 2012 12:16:17 -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;
	16 Jan 2012 12:16:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="20907169"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:17 -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, 16 Jan 2012 07:16:17 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTa032222;	Mon, 16 Jan 2012 04:16:15 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:09 +0000
Message-ID: <1326716171-4298-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 4/5] blktap2/libvhd: Build shared objects using
	-fPIC.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/blktap2/vhd/lib/Makefile |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/blktap2/vhd/lib/Makefile b/tools/blktap2/vhd/lib/Makefile
index 97379c1..8ee169e 100644
--- a/tools/blktap2/vhd/lib/Makefile
+++ b/tools/blktap2/vhd/lib/Makefile
@@ -45,27 +45,32 @@ LIB-SRCS        += atomicio.c
 LIB-OBJS         = $(patsubst %.c,%.o,$(LIB-SRCS))
 LIB-OBJS        += $(LVM-UTIL-OBJ)
 
+LIB-PICOBJS      = $(patsubst %.o,%.opic,$(LIB-OBJS))
+
 LIBVHD           = libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 all: build
 
-build: $(LIBVHD-BUILD)
+build: libvhd.a libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR)
 
 libvhd.a: $(LIB-OBJS)
+	$(AR) rc $@ $^
+
+libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR): $(LIB-PICOBJS)
 	$(CC) -Wl,$(SONAME_LDFLAG),$(LIBVHD-SONAME) $(SHLIB_LDFLAGS) \
 		$(LDFLAGS) -o libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $^ $(LIBS)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) libvhd.so
-	$(AR) rc $@ $^
 
 install: all
 	$(INSTALL_DIR) -p $(DESTDIR)$(INST-DIR)
-	$(INSTALL_PROG) $(LIBVHD) $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.a $(DESTDIR)$(INST-DIR)
+	$(INSTALL_PROG) libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR).$(LIBVHD-MINOR) $(DESTDIR)$(INST-DIR)/libvhd.so.$(LIBVHD-MAJOR)
 	ln -sf libvhd.so.$(LIBVHD-MAJOR) $(DESTDIR)$(INST-DIR)/libvhd.so
 
 clean:
-	rm -rf *.a *.so* *.o *~ $(DEPS) $(LIBVHD)
+	rm -rf *.a *.so* *.o *.opic *~ $(DEPS) $(LIBVHD)
 
 .PHONY: all build clean install libvhd
 
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlUD-0003Ne-Tt; Mon, 16 Jan 2012 12:16:29 +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 1RmlU9-00030N-7p; Mon, 16 Jan 2012 12:16:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326716174!11067432!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5270 invoked from network); 16 Jan 2012 12:16:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:16:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177672057"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:16:18 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTb032222;	Mon, 16 Jan 2012 04:16:17 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:10 +0000
Message-ID: <1326716171-4298-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] DO-NOT-APPLY: Hackily remove bits which
	don't (yet) build on ARM.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For the most part these tools need domU support to be more fully baked before
they can be ported.

In a few cases (e.g. blktap 1) I don't think it makes sense to provide them for
a new platform.

In some cases the lack of portability is just gratuitous (libfsimage/xfs -- I'm
looking at you).
---
 tools/Makefile            |    6 +++---
 tools/libfsimage/Makefile |    3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 443ee7f..7ad7afc 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -14,7 +14,7 @@ SUBDIRS-y += xenstore
 SUBDIRS-y += misc
 SUBDIRS-y += examples
 SUBDIRS-y += hotplug
-SUBDIRS-y += xentrace
+#SUBDIRS-y += xentrace
 SUBDIRS-$(CONFIG_XCUTILS) += xcutils
 SUBDIRS-$(CONFIG_X86) += firmware
 SUBDIRS-y += console
@@ -23,8 +23,8 @@ SUBDIRS-$(VTPM_TOOLS) += vtpm_manager
 SUBDIRS-$(VTPM_TOOLS) += vtpm
 SUBDIRS-y += xenstat
 SUBDIRS-$(CONFIG_Linux) += $(SUBDIRS-libaio)
-SUBDIRS-$(CONFIG_Linux) += memshr 
-SUBDIRS-$(CONFIG_Linux) += blktap
+#SUBDIRS-$(CONFIG_Linux) += memshr 
+#SUBDIRS-$(CONFIG_Linux) += blktap
 SUBDIRS-$(CONFIG_Linux) += blktap2
 SUBDIRS-$(CONFIG_NetBSD) += $(SUBDIRS-libaio)
 SUBDIRS-$(CONFIG_NetBSD) += blktap2
diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
index 2deb830..bcb8b40 100644
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -1,7 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-SUBDIRS-y = common ufs reiserfs iso9660 fat zfs xfs
+SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
+SUBDIRS-$(CONFIG_X86) += xfs
 SUBDIRS-y += $(shell env CC="$(CC)" ./check-libext2fs)
 
 .PHONY: all clean install
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1RmlUD-0003Ne-Tt; Mon, 16 Jan 2012 12:16:29 +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 1RmlU9-00030N-7p; Mon, 16 Jan 2012 12:16:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326716174!11067432!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5270 invoked from network); 16 Jan 2012 12:16:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 12:16:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320642000"; d="scan'208";a="177672057"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 07:16:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 07:16:18 -0500
Received: from army.uk.xensource.com (army.80.10.in-addr.arpa [10.80.246.74]
	(may be forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP
	id q0GCGBTb032222;	Mon, 16 Jan 2012 04:16:17 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com, xen-arm@lists.xensource.com
Date: Mon, 16 Jan 2012 12:16:10 +0000
Message-ID: <1326716171-4298-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.8.3
In-Reply-To: <1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
MIME-Version: 1.0
Cc: stefano.stabellini@citrix.com, Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 5/5] DO-NOT-APPLY: Hackily remove bits which
	don't (yet) build on ARM.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

For the most part these tools need domU support to be more fully baked before
they can be ported.

In a few cases (e.g. blktap 1) I don't think it makes sense to provide them for
a new platform.

In some cases the lack of portability is just gratuitous (libfsimage/xfs -- I'm
looking at you).
---
 tools/Makefile            |    6 +++---
 tools/libfsimage/Makefile |    3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 443ee7f..7ad7afc 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -14,7 +14,7 @@ SUBDIRS-y += xenstore
 SUBDIRS-y += misc
 SUBDIRS-y += examples
 SUBDIRS-y += hotplug
-SUBDIRS-y += xentrace
+#SUBDIRS-y += xentrace
 SUBDIRS-$(CONFIG_XCUTILS) += xcutils
 SUBDIRS-$(CONFIG_X86) += firmware
 SUBDIRS-y += console
@@ -23,8 +23,8 @@ SUBDIRS-$(VTPM_TOOLS) += vtpm_manager
 SUBDIRS-$(VTPM_TOOLS) += vtpm
 SUBDIRS-y += xenstat
 SUBDIRS-$(CONFIG_Linux) += $(SUBDIRS-libaio)
-SUBDIRS-$(CONFIG_Linux) += memshr 
-SUBDIRS-$(CONFIG_Linux) += blktap
+#SUBDIRS-$(CONFIG_Linux) += memshr 
+#SUBDIRS-$(CONFIG_Linux) += blktap
 SUBDIRS-$(CONFIG_Linux) += blktap2
 SUBDIRS-$(CONFIG_NetBSD) += $(SUBDIRS-libaio)
 SUBDIRS-$(CONFIG_NetBSD) += blktap2
diff --git a/tools/libfsimage/Makefile b/tools/libfsimage/Makefile
index 2deb830..bcb8b40 100644
--- a/tools/libfsimage/Makefile
+++ b/tools/libfsimage/Makefile
@@ -1,7 +1,8 @@
 XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/tools/Rules.mk
 
-SUBDIRS-y = common ufs reiserfs iso9660 fat zfs xfs
+SUBDIRS-y = common ufs reiserfs iso9660 fat zfs
+SUBDIRS-$(CONFIG_X86) += xfs
 SUBDIRS-y += $(shell env CC="$(CC)" ./check-libext2fs)
 
 .PHONY: all clean install
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:35:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:35:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmlmc-0008Pf-6D; Mon, 16 Jan 2012 12:35: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 1Rmlma-0008Pa-SQ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:35:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326717322!11222986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12199 invoked from network); 16 Jan 2012 12:35:22 -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;
	16 Jan 2012 12:35:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10047495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12:35:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 12:35: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
	1RmlVd-0003Lr-6R; Mon, 16 Jan 2012 12:17:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmlVd-000504-5Y;
	Mon, 16 Jan 2012 12:17:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.5493.159092.178261@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 12:17:57 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl"):
> It all seems to be gated correctly on the whether the VM is HVM and/or the existence of the appropriate save record.

Well, the bisector, when it fingers a changeset, is pretty reliable.
The revision graph shows that it tried each of 3c4c5df2cd0e and
92630d4b093e three times and got consistent results.

So as you were the author of the original patch, can you please try to
reproduce the problem and fix 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 Mon Jan 16 12:35:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12:35:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmlmc-0008Pf-6D; Mon, 16 Jan 2012 12:35: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 1Rmlma-0008Pa-SQ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:35:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326717322!11222986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12199 invoked from network); 16 Jan 2012 12:35:22 -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;
	16 Jan 2012 12:35:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10047495"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12:35:22 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 12:35: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
	1RmlVd-0003Lr-6R; Mon, 16 Jan 2012 12:17:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmlVd-000504-5Y;
	Mon, 16 Jan 2012 12:17:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.5493.159092.178261@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 12:17:57 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl"):
> It all seems to be gated correctly on the whether the VM is HVM and/or the existence of the appropriate save record.

Well, the bisector, when it fingers a changeset, is pretty reliable.
The revision graph shows that it tried each of 3c4c5df2cd0e and
92630d4b093e three times and got consistent results.

So as you were the author of the original patch, can you please try to
reproduce the problem and fix 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 Mon Jan 16 12:55:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1Rmm5f-0000SW-GQ; Mon, 16 Jan 2012 12:55:11 +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 1Rmm5d-0000SM-TI
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:55:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326718491!9326839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14919 invoked from network); 16 Jan 2012 12:54:51 -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;
	16 Jan 2012 12:54:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10048150"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12: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; Mon, 16 Jan 2012 12:54: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 1Rmm5K-0003dm-8K;
	Mon, 16 Jan 2012 12:54:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rmm5K-0000f7-7h;
	Mon, 16 Jan 2012 12:54:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10764-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 12:54:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10764: 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 10764 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10764/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10565
 test-i386-i386-xl-win         7 windows-install              fail   like 10589
 test-i386-i386-win            7 windows-install              fail   like 10574

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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce
baseline version:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=8664c694e49d4d095706524a27b1fc734b9881ce
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 8664c694e49d4d095706524a27b1fc734b9881ce
+ branch=linux
+ revision=8664c694e49d4d095706524a27b1fc734b9881ce
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 8664c694e49d4d095706524a27b1fc734b9881ce:master
Counting objects: 1   
Counting objects: 391, done.
Compressing objects:   1% (1/54)   
Compressing objects:   3% (2/54)   
Compressing objects:   5% (3/54)   
Compressing objects:   7% (4/54)   
Compressing objects:   9% (5/54)   
Compressing objects:  11% (6/54)   
Compressing objects:  12% (7/54)   
Compressing objects:  14% (8/54)   
Compressing objects:  16% (9/54)   
Compressing objects:  18% (10/54)   
Compressing objects:  20% (11/54)   
Compressing objects:  22% (12/54)   
Compressing objects:  24% (13/54)   
Compressing objects:  25% (14/54)   
Compressing objects:  27% (15/54)   
Compressing objects:  29% (16/54)   
Compressing objects:  31% (17/54)   
Compressing objects:  33% (18/54)   
Compressing objects:  35% (19/54)   
Compressing objects:  37% (20/54)   
Compressing objects:  38% (21/54)   
Compressing objects:  40% (22/54)   
Compressing objects:  42% (23/54)   
Compressing objects:  44% (24/54)   
Compressing objects:  46% (25/54)   
Compressing objects:  48% (26/54)   
Compressing objects:  50% (27/54)   
Compressing objects:  51% (28/54)   
Compressing objects:  53% (29/54)   
Compressing objects:  55% (30/54)   
Compressing objects:  57% (31/54)   
Compressing objects:  59% (32/54)   
Compressing objects:  61% (33/54)   
Compressing objects:  62% (34/54)   
Compressing objects:  64% (35/54)   
Compressing objects:  66% (36/54)   
Compressing objects:  68% (37/54)   
Compressing objects:  70% (38/54)   
Compressing objects:  72% (39/54)   
Compressing objects:  74% (40/54)   
Compressing objects:  75% (41/54)   
Compressing objects:  77% (42/54)   
Compressing objects:  79% (43/54)   
Compressing objects:  81% (44/54)   
Compressing objects:  83% (45/54)   
Compressing objects:  85% (46/54)   
Compressing objects:  87% (47/54)   
Compressing objects:  88% (48/54)   
Compressing objects:  90% (49/54)   
Compressing objects:  92% (50/54)   
Compressing objects:  94% (51/54)   
Compressing objects:  96% (52/54)   
Compressing objects:  98% (53/54)   
Compressing objects: 100% (54/54)   
Compressing objects: 100% (54/54), done.
Writing objects:   0% (1/285)   
Writing objects:   1% (3/285)   
Writing objects:   2% (6/285)   
Writing objects:   3% (9/285)   
Writing objects:   4% (12/285)   
Writing objects:   5% (15/285)   
Writing objects:   6% (18/285)   
Writing objects:   7% (20/285)   
Writing objects:   8% (23/285)   
Writing objects:   9% (26/285)   
Writing objects:  10% (29/285)   
Writing objects:  11% (32/285)   
Writing objects:  12% (35/285)   
Writing objects:  13% (38/285)   
Writing objects:  14% (40/285)   
Writing objects:  15% (43/285)   
Writing objects:  16% (46/285)   
Writing objects:  17% (49/285)   
Writing objects:  18% (52/285)   
Writing objects:  19% (55/285)   
Writing objects:  20% (57/285)   
Writing objects:  21% (60/285)   
Writing objects:  22% (64/285)   
Writing objects:  23% (67/285)   
Writing objects:  24% (69/285)   
Writing objects:  25% (72/285)   
Writing objects:  26% (75/285)   
Writing objects:  27% (77/285)   
Writing objects:  28% (80/285)   
Writing objects:  29% (83/285)   
Writing objects:  30% (86/285)   
Writing objects:  31% (89/285)   
Writing objects:  32% (92/285)   
Writing objects:  33% (95/285)   
Writing objects:  34% (97/285)   
Writing objects:  35% (100/285)   
Writing objects:  36% (104/285)   
Writing objects:  37% (106/285)   
Writing objects:  38% (109/285)   
Writing objects:  39% (112/285)   
Writing objects:  40% (114/285)   
Writing objects:  41% (117/285)   
Writing objects:  42% (120/285)   
Writing objects:  43% (123/285)   
Writing objects:  44% (126/285)   
Writing objects:  45% (129/285)   
Writing objects:  46% (132/285)   
Writing objects:  47% (134/285)   
Writing objects:  48% (138/285)   
Writing objects:  49% (140/285)   
Writing objects:  50% (143/285)   
Writing objects:  51% (146/285)   
Writing objects:  52% (149/285)   
Writing objects:  53% (152/285)   
Writing objects:  54% (154/285)   
Writing objects:  55% (157/285)   
Writing objects:  56% (160/285)   
Writing objects:  57% (163/285)   
Writing objects:  58% (166/285)   
Writing objects:  59% (169/285)   
Writing objects:  60% (172/285)   
Writing objects:  61% (175/285)   
Writing objects:  62% (177/285)   
Writing objects:  63% (180/285)   
Writing objects:  64% (183/285)   
Writing objects:  65% (186/285)   
Writing objects:  66% (189/285)   
Writing objects:  67% (191/285)   
Writing objects:  68% (194/285)   
Writing objects:  69% (197/285)   
Writing objects:  70% (200/285)   
Writing objects:  71% (203/285)   
Writing objects:  72% (206/285)   
Writing objects:  73% (209/285)   
Writing objects:  74% (211/285)   
Writing objects:  75% (214/285)   
Writing objects:  76% (217/285)   
Writing objects:  77% (220/285)   
Writing objects:  78% (223/285)   
Writing objects:  79% (226/285)   
Writing objects:  80% (228/285)   
Writing objects:  81% (231/285)   
Writing objects:  82% (234/285)   
Writing objects:  83% (237/285)   
Writing objects:  84% (240/285)   
Writing objects:  85% (243/285)   
Writing objects:  86% (246/285)   
Writing objects:  87% (248/285)   
Writing objects:  88% (251/285)   
Writing objects:  89% (254/285)   
Writing objects:  90% (257/285)   
Writing objects:  91% (260/285)   
Writing objects:  92% (263/285)   
Writing objects:  93% (266/285)   
Writing objects:  94% (268/285)   
Writing objects:  95% (271/285)   
Writing objects:  96% (274/285)   
Writing objects:  97% (277/285)   
Writing objects:  98% (280/285)   
Writing objects:  99% (283/285)   
Writing objects: 100% (285/285)   
Writing objects: 100% (285/285), 55.06 KiB, done.
Total 285 (delta 231), reused 285 (delta 231)
To xen@xenbits.xensource.com:git/linux-pvops
   59b1ffe..8664c69  8664c694e49d4d095706524a27b1fc734b9881ce -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 12:55:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 12: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 1Rmm5f-0000SW-GQ; Mon, 16 Jan 2012 12:55:11 +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 1Rmm5d-0000SM-TI
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 12:55:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326718491!9326839!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14919 invoked from network); 16 Jan 2012 12:54:51 -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;
	16 Jan 2012 12:54:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,517,1320624000"; d="scan'208";a="10048150"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 12: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; Mon, 16 Jan 2012 12:54: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 1Rmm5K-0003dm-8K;
	Mon, 16 Jan 2012 12:54:50 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rmm5K-0000f7-7h;
	Mon, 16 Jan 2012 12:54:50 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10764-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 12:54:50 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 10764: 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 10764 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10764/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10565
 test-i386-i386-xl-win         7 windows-install              fail   like 10589
 test-i386-i386-win            7 windows-install              fail   like 10574

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-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce
baseline version:
 linux                59b1ffe039ce366305d48176b7fccce29ce729d3

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=linux
+ revision=8664c694e49d4d095706524a27b1fc734b9881ce
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 8664c694e49d4d095706524a27b1fc734b9881ce
+ branch=linux
+ revision=8664c694e49d4d095706524a27b1fc734b9881ce
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 8664c694e49d4d095706524a27b1fc734b9881ce:master
Counting objects: 1   
Counting objects: 391, done.
Compressing objects:   1% (1/54)   
Compressing objects:   3% (2/54)   
Compressing objects:   5% (3/54)   
Compressing objects:   7% (4/54)   
Compressing objects:   9% (5/54)   
Compressing objects:  11% (6/54)   
Compressing objects:  12% (7/54)   
Compressing objects:  14% (8/54)   
Compressing objects:  16% (9/54)   
Compressing objects:  18% (10/54)   
Compressing objects:  20% (11/54)   
Compressing objects:  22% (12/54)   
Compressing objects:  24% (13/54)   
Compressing objects:  25% (14/54)   
Compressing objects:  27% (15/54)   
Compressing objects:  29% (16/54)   
Compressing objects:  31% (17/54)   
Compressing objects:  33% (18/54)   
Compressing objects:  35% (19/54)   
Compressing objects:  37% (20/54)   
Compressing objects:  38% (21/54)   
Compressing objects:  40% (22/54)   
Compressing objects:  42% (23/54)   
Compressing objects:  44% (24/54)   
Compressing objects:  46% (25/54)   
Compressing objects:  48% (26/54)   
Compressing objects:  50% (27/54)   
Compressing objects:  51% (28/54)   
Compressing objects:  53% (29/54)   
Compressing objects:  55% (30/54)   
Compressing objects:  57% (31/54)   
Compressing objects:  59% (32/54)   
Compressing objects:  61% (33/54)   
Compressing objects:  62% (34/54)   
Compressing objects:  64% (35/54)   
Compressing objects:  66% (36/54)   
Compressing objects:  68% (37/54)   
Compressing objects:  70% (38/54)   
Compressing objects:  72% (39/54)   
Compressing objects:  74% (40/54)   
Compressing objects:  75% (41/54)   
Compressing objects:  77% (42/54)   
Compressing objects:  79% (43/54)   
Compressing objects:  81% (44/54)   
Compressing objects:  83% (45/54)   
Compressing objects:  85% (46/54)   
Compressing objects:  87% (47/54)   
Compressing objects:  88% (48/54)   
Compressing objects:  90% (49/54)   
Compressing objects:  92% (50/54)   
Compressing objects:  94% (51/54)   
Compressing objects:  96% (52/54)   
Compressing objects:  98% (53/54)   
Compressing objects: 100% (54/54)   
Compressing objects: 100% (54/54), done.
Writing objects:   0% (1/285)   
Writing objects:   1% (3/285)   
Writing objects:   2% (6/285)   
Writing objects:   3% (9/285)   
Writing objects:   4% (12/285)   
Writing objects:   5% (15/285)   
Writing objects:   6% (18/285)   
Writing objects:   7% (20/285)   
Writing objects:   8% (23/285)   
Writing objects:   9% (26/285)   
Writing objects:  10% (29/285)   
Writing objects:  11% (32/285)   
Writing objects:  12% (35/285)   
Writing objects:  13% (38/285)   
Writing objects:  14% (40/285)   
Writing objects:  15% (43/285)   
Writing objects:  16% (46/285)   
Writing objects:  17% (49/285)   
Writing objects:  18% (52/285)   
Writing objects:  19% (55/285)   
Writing objects:  20% (57/285)   
Writing objects:  21% (60/285)   
Writing objects:  22% (64/285)   
Writing objects:  23% (67/285)   
Writing objects:  24% (69/285)   
Writing objects:  25% (72/285)   
Writing objects:  26% (75/285)   
Writing objects:  27% (77/285)   
Writing objects:  28% (80/285)   
Writing objects:  29% (83/285)   
Writing objects:  30% (86/285)   
Writing objects:  31% (89/285)   
Writing objects:  32% (92/285)   
Writing objects:  33% (95/285)   
Writing objects:  34% (97/285)   
Writing objects:  35% (100/285)   
Writing objects:  36% (104/285)   
Writing objects:  37% (106/285)   
Writing objects:  38% (109/285)   
Writing objects:  39% (112/285)   
Writing objects:  40% (114/285)   
Writing objects:  41% (117/285)   
Writing objects:  42% (120/285)   
Writing objects:  43% (123/285)   
Writing objects:  44% (126/285)   
Writing objects:  45% (129/285)   
Writing objects:  46% (132/285)   
Writing objects:  47% (134/285)   
Writing objects:  48% (138/285)   
Writing objects:  49% (140/285)   
Writing objects:  50% (143/285)   
Writing objects:  51% (146/285)   
Writing objects:  52% (149/285)   
Writing objects:  53% (152/285)   
Writing objects:  54% (154/285)   
Writing objects:  55% (157/285)   
Writing objects:  56% (160/285)   
Writing objects:  57% (163/285)   
Writing objects:  58% (166/285)   
Writing objects:  59% (169/285)   
Writing objects:  60% (172/285)   
Writing objects:  61% (175/285)   
Writing objects:  62% (177/285)   
Writing objects:  63% (180/285)   
Writing objects:  64% (183/285)   
Writing objects:  65% (186/285)   
Writing objects:  66% (189/285)   
Writing objects:  67% (191/285)   
Writing objects:  68% (194/285)   
Writing objects:  69% (197/285)   
Writing objects:  70% (200/285)   
Writing objects:  71% (203/285)   
Writing objects:  72% (206/285)   
Writing objects:  73% (209/285)   
Writing objects:  74% (211/285)   
Writing objects:  75% (214/285)   
Writing objects:  76% (217/285)   
Writing objects:  77% (220/285)   
Writing objects:  78% (223/285)   
Writing objects:  79% (226/285)   
Writing objects:  80% (228/285)   
Writing objects:  81% (231/285)   
Writing objects:  82% (234/285)   
Writing objects:  83% (237/285)   
Writing objects:  84% (240/285)   
Writing objects:  85% (243/285)   
Writing objects:  86% (246/285)   
Writing objects:  87% (248/285)   
Writing objects:  88% (251/285)   
Writing objects:  89% (254/285)   
Writing objects:  90% (257/285)   
Writing objects:  91% (260/285)   
Writing objects:  92% (263/285)   
Writing objects:  93% (266/285)   
Writing objects:  94% (268/285)   
Writing objects:  95% (271/285)   
Writing objects:  96% (274/285)   
Writing objects:  97% (277/285)   
Writing objects:  98% (280/285)   
Writing objects:  99% (283/285)   
Writing objects: 100% (285/285)   
Writing objects: 100% (285/285), 55.06 KiB, done.
Total 285 (delta 231), reused 285 (delta 231)
To xen@xenbits.xensource.com:git/linux-pvops
   59b1ffe..8664c69  8664c694e49d4d095706524a27b1fc734b9881ce -> master

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 13:18:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 13:18:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmmRX-0001Md-C3; Mon, 16 Jan 2012 13:17:47 +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 1RmmRV-0001MK-56
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:17:45 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326719858!11096540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21010 invoked from network); 16 Jan 2012 13:17:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 13:17:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10049205"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 13:17:37 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 16 Jan 2012
	13:17:36 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 13:17:34 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUS1CNQxRG3pQVRwS0euEyW4W2TAABds6w
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC67@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
	<20244.5493.159092.178261@mariner.uk.xensource.com>
In-Reply-To: <20244.5493.159092.178261@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 16 January 2012 12:18
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xensource.com; Keir (Xen.org); Stefano
> Stabellini
> Subject: RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete
> test-i386-i386-xl"):
> > It all seems to be gated correctly on the whether the VM is HVM and/or
> the existence of the appropriate save record.
> 
> Well, the bisector, when it fingers a changeset, is pretty reliable.
> The revision graph shows that it tried each of 3c4c5df2cd0e and
> 92630d4b093e three times and got consistent results.
> 
> So as you were the author of the original patch, can you please try to
> reproduce the problem and fix it ?
> 

Already on it.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 13:18:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 13:18:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmmRX-0001Md-C3; Mon, 16 Jan 2012 13:17:47 +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 1RmmRV-0001MK-56
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:17:45 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326719858!11096540!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21010 invoked from network); 16 Jan 2012 13:17:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 13:17:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10049205"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 13:17:37 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 16 Jan 2012
	13:17:36 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 13:17:34 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUS1CNQxRG3pQVRwS0euEyW4W2TAABds6w
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BEC67@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
	<20244.5493.159092.178261@mariner.uk.xensource.com>
In-Reply-To: <20244.5493.159092.178261@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 16 January 2012 12:18
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xensource.com; Keir (Xen.org); Stefano
> Stabellini
> Subject: RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete
> test-i386-i386-xl"):
> > It all seems to be gated correctly on the whether the VM is HVM and/or
> the existence of the appropriate save record.
> 
> Well, the bisector, when it fingers a changeset, is pretty reliable.
> The revision graph shows that it tried each of 3c4c5df2cd0e and
> 92630d4b093e three times and got consistent results.
> 
> So as you were the author of the original patch, can you please try to
> reproduce the problem and fix it ?
> 

Already on it.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 13:28:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 13:28:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmmbt-0001rJ-Pn; Mon, 16 Jan 2012 13:28:29 +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 1Rmmbr-0001rE-Ce
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:28:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326720501!11097889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19622 invoked from network); 16 Jan 2012 13:28:21 -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 Jan 2012 13:28:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10049868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 13:28: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;
	Mon, 16 Jan 2012 13:28:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Mon, 16 Jan 2012 13:28:20 +0000
In-Reply-To: <20120104172519.GS12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326720500.17210.442.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTA0IGF0IDE3OjI1ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiAKPiAtIEFsc28gdGhlcmUncyBhIGJ1bmNoIG9mIFZHQSBwYXNzdGhydSByZWxhdGVkIHBh
dGNoZXMsCj4gdGhhdCBJIG9uY2Ugdm9sdW50ZWVyZWQgdG8gY29sbGVjdC9yZWJhc2UvY2xlYW51
cC9yZXBvc3QgbXlzZWxmLAo+IGJ1dCBJIHN0aWxsIGhhdmVuJ3QgaGFkIHRpbWUgZm9yIHRoYXQg
OiggCgpJJ20gbm90IGdvaW5nIHRvIGluY2x1ZGUgdGhpcyBpbiB0aGUgbGlzdCB1bmxlc3Mgc29t
ZW9uZSBzdGVwcyB1cCBhbmQKc3RhcnRzIHN1Ym1pdHRpbmcgcGF0Y2hlcy4KCklhbi4KCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 16 13:28:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 13:28:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmmbt-0001rJ-Pn; Mon, 16 Jan 2012 13:28:29 +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 1Rmmbr-0001rE-Ce
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:28:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326720501!11097889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19622 invoked from network); 16 Jan 2012 13:28:21 -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 Jan 2012 13:28:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10049868"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 13:28: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;
	Mon, 16 Jan 2012 13:28:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Mon, 16 Jan 2012 13:28:20 +0000
In-Reply-To: <20120104172519.GS12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326720500.17210.442.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTA0IGF0IDE3OjI1ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiAKPiAtIEFsc28gdGhlcmUncyBhIGJ1bmNoIG9mIFZHQSBwYXNzdGhydSByZWxhdGVkIHBh
dGNoZXMsCj4gdGhhdCBJIG9uY2Ugdm9sdW50ZWVyZWQgdG8gY29sbGVjdC9yZWJhc2UvY2xlYW51
cC9yZXBvc3QgbXlzZWxmLAo+IGJ1dCBJIHN0aWxsIGhhdmVuJ3QgaGFkIHRpbWUgZm9yIHRoYXQg
OiggCgpJJ20gbm90IGdvaW5nIHRvIGluY2x1ZGUgdGhpcyBpbiB0aGUgbGlzdCB1bmxlc3Mgc29t
ZW9uZSBzdGVwcyB1cCBhbmQKc3RhcnRzIHN1Ym1pdHRpbmcgcGF0Y2hlcy4KCklhbi4KCgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 16 13:39:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 13: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 1Rmmmf-0002Ch-4r; Mon, 16 Jan 2012 13:39:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmmmd-0002Cc-Rb
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:39:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326721168!9126179!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30705 invoked from network); 16 Jan 2012 13:39:29 -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;
	16 Jan 2012 13:39:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10050397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 13:39:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 13:39:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 16 Jan 2012 13:39:27 +0000
In-Reply-To: <4F049293020000780006A6FE@nat28.tlf.novell.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<4F049293020000780006A6FE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326721167.17210.449.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > What are the outstanding things to do before we think we can start on
> > the 4.2 -rc's? Does anyone have a timetable in mind?
> > 
> > hypervisor:
> > 
> >       * ??? - Keir, Tim, Jan?
> 
> Apart from a few small things that I have on my todo list, the only
> bigger one (at least from an possible impact perspective) is the
> round-up of the closing of the security hole in MSI-X passthrough
> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
> table pages), which I intended to do only once the upstream qemu
> patch series also incorporates the respective recent qemu-xen
> change.

It sounds like this issue is a blocker for the release, whereas the
upstream qemu support for pci passthrough is not necessarily. Has your
precondition for inclusion been met yet or do we need to prod someone?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 13:39:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 13: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 1Rmmmf-0002Ch-4r; Mon, 16 Jan 2012 13:39:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmmmd-0002Cc-Rb
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:39:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326721168!9126179!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30705 invoked from network); 16 Jan 2012 13:39:29 -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;
	16 Jan 2012 13:39:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10050397"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 13:39:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 13:39:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 16 Jan 2012 13:39:27 +0000
In-Reply-To: <4F049293020000780006A6FE@nat28.tlf.novell.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<4F049293020000780006A6FE@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326721167.17210.449.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > What are the outstanding things to do before we think we can start on
> > the 4.2 -rc's? Does anyone have a timetable in mind?
> > 
> > hypervisor:
> > 
> >       * ??? - Keir, Tim, Jan?
> 
> Apart from a few small things that I have on my todo list, the only
> bigger one (at least from an possible impact perspective) is the
> round-up of the closing of the security hole in MSI-X passthrough
> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
> table pages), which I intended to do only once the upstream qemu
> patch series also incorporates the respective recent qemu-xen
> change.

It sounds like this issue is a blocker for the release, whereas the
upstream qemu support for pci passthrough is not necessarily. Has your
precondition for inclusion been met yet or do we need to prod someone?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 13:43:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 13:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmmpt-0002K5-QG; Mon, 16 Jan 2012 13:42:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmmps-0002Jv-Bm
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:42:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326721369!9341782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23220 invoked from network); 16 Jan 2012 13:42:49 -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;
	16 Jan 2012 13:42:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10050543"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 13:42:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 13:42:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 13:42:49 +0000
In-Reply-To: <alpine.DEB.2.00.1201041650300.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104164713.GA6294@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201041650300.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326721369.17210.452.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 16:51 +0000, Stefano Stabellini wrote:
> On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > >       * Integrate qemu+seabios upstream into the build (Stefano has
> > >         posted patches, I guess they need refreshing and reposting). No
> > >         change in default qemu for 4.2.
> > 
> > Anthony's PCI passthrough patches?
> 
> Right. And Anthony's save/restore patches as well.

Since these are dependent on external factors (qemu upstream) are we
willing to block our own release for them?

Given that upstream qemu won't be the default in this release I think
the answer is "no", although obviously they are nice to haves.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 13:43:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 13:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmmpt-0002K5-QG; Mon, 16 Jan 2012 13:42:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmmps-0002Jv-Bm
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:42:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326721369!9341782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23220 invoked from network); 16 Jan 2012 13:42:49 -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;
	16 Jan 2012 13:42:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10050543"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 13:42:49 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 13:42:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 13:42:49 +0000
In-Reply-To: <alpine.DEB.2.00.1201041650300.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104164713.GA6294@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201041650300.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326721369.17210.452.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-04 at 16:51 +0000, Stefano Stabellini wrote:
> On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > >       * Integrate qemu+seabios upstream into the build (Stefano has
> > >         posted patches, I guess they need refreshing and reposting). No
> > >         change in default qemu for 4.2.
> > 
> > Anthony's PCI passthrough patches?
> 
> Right. And Anthony's save/restore patches as well.

Since these are dependent on external factors (qemu upstream) are we
willing to block our own release for them?

Given that upstream qemu won't be the default in this release I think
the answer is "no", although obviously they are nice to haves.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:31:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmnaR-0003aX-4b; Mon, 16 Jan 2012 14:31: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 1RmnaP-0003aS-FU
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:31:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326724255!11089415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10353 invoked from network); 16 Jan 2012 14:30:55 -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;
	16 Jan 2012 14:30:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10052784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:30:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 14:30: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
	1RmnaJ-0004Bd-2P; Mon, 16 Jan 2012 14:30:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmnaI-00059Z-W5;
	Mon, 16 Jan 2012 14:30:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.13470.956567.815603@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 14:30:54 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC67@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
	<20244.5493.159092.178261@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC67@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl"):
> > -----Original Message-----
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
...
> > So as you were the author of the original patch, can you please try to
> > reproduce the problem and fix it ?
> > 
> 
> Already on it.

Great, thanks.  If you need any help, or to borrow the machine from my
test pool, or something, just let me know.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:31:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:31:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmnaR-0003aX-4b; Mon, 16 Jan 2012 14:31: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 1RmnaP-0003aS-FU
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:31:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326724255!11089415!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10353 invoked from network); 16 Jan 2012 14:30:55 -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;
	16 Jan 2012 14:30:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10052784"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:30:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 14:30: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
	1RmnaJ-0004Bd-2P; Mon, 16 Jan 2012 14:30:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmnaI-00059Z-W5;
	Mon, 16 Jan 2012 14:30:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.13470.956567.815603@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 14:30:54 +0000
To: Paul Durrant <Paul.Durrant@citrix.com>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BEC67@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
	<20244.5493.159092.178261@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC67@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl"):
> > -----Original Message-----
> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
...
> > So as you were the author of the original patch, can you please try to
> > reproduce the problem and fix it ?
> > 
> 
> Already on it.

Great, thanks.  If you need any help, or to borrow the machine from my
test pool, or something, just let me know.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:40:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:40:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmniP-0003sK-Te; Mon, 16 Jan 2012 14:39:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RmniO-0003rS-8A
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:39:16 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326724749!9060533!1
X-Originating-IP: [212.82.109.203]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 32695 invoked from network); 16 Jan 2012 14:39:09 -0000
Received: from nm25-vm2.bullet.mail.ird.yahoo.com (HELO
	nm25-vm2.bullet.mail.ird.yahoo.com) (212.82.109.203)
	by server-15.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 14:39:09 -0000
Received: from [77.238.189.231] by nm25.bullet.mail.ird.yahoo.com with NNFMP;
	16 Jan 2012 14:39:09 -0000
Received: from [212.82.108.117] by tm12.bullet.mail.ird.yahoo.com with NNFMP;
	16 Jan 2012 14:39:08 -0000
Received: from [127.0.0.1] by omp1026.mail.ird.yahoo.com with NNFMP;
	16 Jan 2012 14:39:08 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 915053.38487.bm@omp1026.mail.ird.yahoo.com
Received: (qmail 74596 invoked by uid 60001); 16 Jan 2012 14:39:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1326724748; bh=fWIda6MC6YKPWfa16K/OR10ZmPIw+27wmr4+yKkAjUA=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=L4OQrL0wH5X6cc+lZlZx0MdRcoYnoJh1x60FQ5DkxRCxAf5hdCqSTUfHsWp133gLUtBnEhAdUbXa7tlj9ypqdQRulrTfnQIAHazFbfOXemnb46pqkxRN+Dq5ghDQobcdiv3yQ5cEW/wmVmOE8NWRmlZehmhNjkRSCRy2z9M5sgA=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=6fSJuIUk0Z8b2v7oJgBluEhlbLrCAmxLWTl4ITC1knTGXH03WMq2yXHujvlR/oONbOP/bzBD6Tuf/27/l/ESl/fpWs/dqk5mcB7zto5cApZ+n886eCmhNQdb2jyEwQorgiTqfWkmTIMdtPYBykmaoKLWx0K12oFo0yD4LdA2Hco=;
X-YMail-OSG: lgxfdtkVM1kKyvayHZG6bOFFJmWnJIldM5EWfddsLMLmFL.
	UHCZbLRSyBgtIvB7B0fpmgDOBxWcRD2b5vs.Fhwz6ckWjhiaNT87Z_j8_EOh
	sAx2Bk68PxGopWcysUYOYzW2ERIEfD._HhKbN9o9wkdRrhYDZ6vfjX2WrcvC
	OmNRb3zk2z8omzzGvw1O.DJWJHi96bZlXvRxl187TSjnnSNH.dCpjNcfIAqC
	3NWYzRv0ojvkIpkO4jglKmgBnTKw2bxVs_nOPmawH3xaUAUy8bI.gsQfiwih
	.nF4x.1Qbpt5D9FNHhrwJHVLL0UB.GTMEujsrpN9a6GuplnCPGsMaCHx4j3O
	iqsLyNjUarhzvz5lDw_9UnEt66sCBsjvw185Gx.RDUxcLSd4ZfseQJuSUg4v
	QvwEH4tsWr1n6l7NDUCjIklGLpjkY1odW7OUjjoKNK1Dc0pgGVatzK5IyKLQ
	4PS5Gyvao_RtnGzQQnbIIf13UV.U-
Received: from [195.167.237.98] by web29802.mail.ird.yahoo.com via HTTP;
	Mon, 16 Jan 2012 14:39:07 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
	<1326720500.17210.442.camel@zakaz.uk.xensource.com>
Message-ID: <1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Mon, 16 Jan 2012 14:39:07 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	=?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <1326720500.17210.442.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
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="===============9083096898812060388=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9083096898812060388==
Content-Type: multipart/alternative; boundary="478945831-1678704402-1326724747=:73001"

--478945831-1678704402-1326724747=:73001
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I told a couple weeks ago that I will try to submit the patches.=0A=0ASorry=
 I am not submitting patches. I was/am very busy these last weeks.=0A=0A=0A=
I will try to submit patches for VGA passthrough this week-end.=0A=0AKind r=
egards.=0A=0ADavid.=0A=0A=0A=0A________________________________=0A De=A0: I=
an Campbell <Ian.Campbell@citrix.com>=0A=C0=A0: Pasi K=E4rkk=E4inen <pasik@=
iki.fi> =0ACc=A0: xen-devel <xen-devel@lists.xensource.com>; Keir (Xen.org)=
 <keir@xen.org>; Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>; Ian=
 Jackson <Ian.Jackson@eu.citrix.com>; Tim (Xen.org) <tim@xen.org>; Jan Beul=
ich <JBeulich@suse.com> =0AEnvoy=E9 le : Lundi 16 Janvier 2012 14h28=0AObje=
t=A0: Re: [Xen-devel] RFC: Still TODO for 4.2?=0A =0AOn Wed, 2012-01-04 at =
17:25 +0000, Pasi K=E4rkk=E4inen wrote:=0A> =0A> - Also there's a bunch of =
VGA passthru related patches,=0A> that I once volunteered to collect/rebase=
/cleanup/repost myself,=0A> but I still haven't had time for that :( =0A=0A=
I'm not going to include this in the list unless someone steps up and=0Asta=
rts submitting patches.=0A=0AIan.=0A=0A=0A=0A______________________________=
_________________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=
=0Ahttp://lists.xensource.com/xen-devel
--478945831-1678704402-1326724747=:73001
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>I told a c=
ouple weeks ago that I will try to submit the patches.</span></div><div><br=
><span></span></div><div><span>Sorry I am not submitting patches. I was/am =
very busy these last weeks.<br></span></div><div><br><span></span></div><di=
v><span>I will try to submit patches for VGA passthrough this week-end.</sp=
an></div><div><br><span></span></div><div><span>Kind regards.</span></div><=
div><br><span></span></div><div><span>David.<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, times,=
 serif; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2" face=3D"Arial=
"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></=
b> Ian Campbell &lt;Ian.Campbell@citrix.com&gt;<br> <b><span style=3D"font-=
weight:
 bold;">=C0&nbsp;:</span></b> Pasi K=E4rkk=E4inen &lt;pasik@iki.fi&gt; <br>=
<b><span style=3D"font-weight: bold;">Cc&nbsp;:</span></b> xen-devel &lt;xe=
n-devel@lists.xensource.com&gt;; Keir (Xen.org) &lt;keir@xen.org&gt;; Stefa=
no Stabellini &lt;Stefano.Stabellini@eu.citrix.com&gt;; Ian Jackson &lt;Ian=
.Jackson@eu.citrix.com&gt;; Tim (Xen.org) &lt;tim@xen.org&gt;; Jan Beulich =
&lt;JBeulich@suse.com&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=
=E9 le :</span></b> Lundi 16 Janvier 2012 14h28<br> <b><span style=3D"font-=
weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] RFC: Still TODO for =
4.2?<br> </font> </div> <br>On Wed, 2012-01-04 at 17:25 +0000, Pasi K=E4rkk=
=E4inen wrote:<br>&gt; <br>&gt; - Also there's a bunch of VGA passthru rela=
ted patches,<br>&gt; that I once volunteered to collect/rebase/cleanup/repo=
st myself,<br>&gt; but I still haven't had time for that :( <br><br>I'm not=
 going to include this in the list unless someone steps up and<br>starts
 submitting patches.<br><br>Ian.<br><br><br><br>___________________________=
____________________<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-=
devel@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xensource.com">Xe=
n-devel@lists.xensource.com</a><br><a href=3D"http://lists.xensource.com/xe=
n-devel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br><br>=
<br> </div> </div>  </div></body></html>
--478945831-1678704402-1326724747=:73001--


--===============9083096898812060388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9083096898812060388==--


From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:40:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:40:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmniP-0003sK-Te; Mon, 16 Jan 2012 14:39:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RmniO-0003rS-8A
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:39:16 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326724749!9060533!1
X-Originating-IP: [212.82.109.203]
X-SpamReason: No, hits=0.1 required=7.0 tests=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 32695 invoked from network); 16 Jan 2012 14:39:09 -0000
Received: from nm25-vm2.bullet.mail.ird.yahoo.com (HELO
	nm25-vm2.bullet.mail.ird.yahoo.com) (212.82.109.203)
	by server-15.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 14:39:09 -0000
Received: from [77.238.189.231] by nm25.bullet.mail.ird.yahoo.com with NNFMP;
	16 Jan 2012 14:39:09 -0000
Received: from [212.82.108.117] by tm12.bullet.mail.ird.yahoo.com with NNFMP;
	16 Jan 2012 14:39:08 -0000
Received: from [127.0.0.1] by omp1026.mail.ird.yahoo.com with NNFMP;
	16 Jan 2012 14:39:08 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 915053.38487.bm@omp1026.mail.ird.yahoo.com
Received: (qmail 74596 invoked by uid 60001); 16 Jan 2012 14:39:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1326724748; bh=fWIda6MC6YKPWfa16K/OR10ZmPIw+27wmr4+yKkAjUA=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=L4OQrL0wH5X6cc+lZlZx0MdRcoYnoJh1x60FQ5DkxRCxAf5hdCqSTUfHsWp133gLUtBnEhAdUbXa7tlj9ypqdQRulrTfnQIAHazFbfOXemnb46pqkxRN+Dq5ghDQobcdiv3yQ5cEW/wmVmOE8NWRmlZehmhNjkRSCRy2z9M5sgA=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=6fSJuIUk0Z8b2v7oJgBluEhlbLrCAmxLWTl4ITC1knTGXH03WMq2yXHujvlR/oONbOP/bzBD6Tuf/27/l/ESl/fpWs/dqk5mcB7zto5cApZ+n886eCmhNQdb2jyEwQorgiTqfWkmTIMdtPYBykmaoKLWx0K12oFo0yD4LdA2Hco=;
X-YMail-OSG: lgxfdtkVM1kKyvayHZG6bOFFJmWnJIldM5EWfddsLMLmFL.
	UHCZbLRSyBgtIvB7B0fpmgDOBxWcRD2b5vs.Fhwz6ckWjhiaNT87Z_j8_EOh
	sAx2Bk68PxGopWcysUYOYzW2ERIEfD._HhKbN9o9wkdRrhYDZ6vfjX2WrcvC
	OmNRb3zk2z8omzzGvw1O.DJWJHi96bZlXvRxl187TSjnnSNH.dCpjNcfIAqC
	3NWYzRv0ojvkIpkO4jglKmgBnTKw2bxVs_nOPmawH3xaUAUy8bI.gsQfiwih
	.nF4x.1Qbpt5D9FNHhrwJHVLL0UB.GTMEujsrpN9a6GuplnCPGsMaCHx4j3O
	iqsLyNjUarhzvz5lDw_9UnEt66sCBsjvw185Gx.RDUxcLSd4ZfseQJuSUg4v
	QvwEH4tsWr1n6l7NDUCjIklGLpjkY1odW7OUjjoKNK1Dc0pgGVatzK5IyKLQ
	4PS5Gyvao_RtnGzQQnbIIf13UV.U-
Received: from [195.167.237.98] by web29802.mail.ird.yahoo.com via HTTP;
	Mon, 16 Jan 2012 14:39:07 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
	<1326720500.17210.442.camel@zakaz.uk.xensource.com>
Message-ID: <1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
Date: Mon, 16 Jan 2012 14:39:07 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	=?iso-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <1326720500.17210.442.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
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="===============9083096898812060388=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9083096898812060388==
Content-Type: multipart/alternative; boundary="478945831-1678704402-1326724747=:73001"

--478945831-1678704402-1326724747=:73001
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I told a couple weeks ago that I will try to submit the patches.=0A=0ASorry=
 I am not submitting patches. I was/am very busy these last weeks.=0A=0A=0A=
I will try to submit patches for VGA passthrough this week-end.=0A=0AKind r=
egards.=0A=0ADavid.=0A=0A=0A=0A________________________________=0A De=A0: I=
an Campbell <Ian.Campbell@citrix.com>=0A=C0=A0: Pasi K=E4rkk=E4inen <pasik@=
iki.fi> =0ACc=A0: xen-devel <xen-devel@lists.xensource.com>; Keir (Xen.org)=
 <keir@xen.org>; Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>; Ian=
 Jackson <Ian.Jackson@eu.citrix.com>; Tim (Xen.org) <tim@xen.org>; Jan Beul=
ich <JBeulich@suse.com> =0AEnvoy=E9 le : Lundi 16 Janvier 2012 14h28=0AObje=
t=A0: Re: [Xen-devel] RFC: Still TODO for 4.2?=0A =0AOn Wed, 2012-01-04 at =
17:25 +0000, Pasi K=E4rkk=E4inen wrote:=0A> =0A> - Also there's a bunch of =
VGA passthru related patches,=0A> that I once volunteered to collect/rebase=
/cleanup/repost myself,=0A> but I still haven't had time for that :( =0A=0A=
I'm not going to include this in the list unless someone steps up and=0Asta=
rts submitting patches.=0A=0AIan.=0A=0A=0A=0A______________________________=
_________________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=
=0Ahttp://lists.xensource.com/xen-devel
--478945831-1678704402-1326724747=:73001
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>I told a c=
ouple weeks ago that I will try to submit the patches.</span></div><div><br=
><span></span></div><div><span>Sorry I am not submitting patches. I was/am =
very busy these last weeks.<br></span></div><div><br><span></span></div><di=
v><span>I will try to submit patches for VGA passthrough this week-end.</sp=
an></div><div><br><span></span></div><div><span>Kind regards.</span></div><=
div><br><span></span></div><div><span>David.<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, times,=
 serif; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2" face=3D"Arial=
"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nbsp;:</span></=
b> Ian Campbell &lt;Ian.Campbell@citrix.com&gt;<br> <b><span style=3D"font-=
weight:
 bold;">=C0&nbsp;:</span></b> Pasi K=E4rkk=E4inen &lt;pasik@iki.fi&gt; <br>=
<b><span style=3D"font-weight: bold;">Cc&nbsp;:</span></b> xen-devel &lt;xe=
n-devel@lists.xensource.com&gt;; Keir (Xen.org) &lt;keir@xen.org&gt;; Stefa=
no Stabellini &lt;Stefano.Stabellini@eu.citrix.com&gt;; Ian Jackson &lt;Ian=
.Jackson@eu.citrix.com&gt;; Tim (Xen.org) &lt;tim@xen.org&gt;; Jan Beulich =
&lt;JBeulich@suse.com&gt; <br> <b><span style=3D"font-weight: bold;">Envoy=
=E9 le :</span></b> Lundi 16 Janvier 2012 14h28<br> <b><span style=3D"font-=
weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] RFC: Still TODO for =
4.2?<br> </font> </div> <br>On Wed, 2012-01-04 at 17:25 +0000, Pasi K=E4rkk=
=E4inen wrote:<br>&gt; <br>&gt; - Also there's a bunch of VGA passthru rela=
ted patches,<br>&gt; that I once volunteered to collect/rebase/cleanup/repo=
st myself,<br>&gt; but I still haven't had time for that :( <br><br>I'm not=
 going to include this in the list unless someone steps up and<br>starts
 submitting patches.<br><br>Ian.<br><br><br><br>___________________________=
____________________<br>Xen-devel mailing list<br><a ymailto=3D"mailto:Xen-=
devel@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xensource.com">Xe=
n-devel@lists.xensource.com</a><br><a href=3D"http://lists.xensource.com/xe=
n-devel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br><br>=
<br> </div> </div>  </div></body></html>
--478945831-1678704402-1326724747=:73001--


--===============9083096898812060388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9083096898812060388==--


From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:41:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmnjU-0003y5-FW; Mon, 16 Jan 2012 14:40:24 +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 1RmnjT-0003xc-7h
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:40:23 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326724816!11213563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12441 invoked from network); 16 Jan 2012 14:40:17 -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;
	16 Jan 2012 14:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10053349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:40:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 14:40:16 +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 1RmnjL-0004Ex-OG;
	Mon, 16 Jan 2012 14:40:15 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RmnjE-0006hK-6U;
	Mon, 16 Jan 2012 14:40:08 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 14:40:07 +0000
Message-ID: <1326724807-25718-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>
Subject: [Xen-devel] [PATCH] [passthrough] Change init for pt_pci_host
	return value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


With an init of -1 all the return value smaller than a double word
will be prefixed with "f"s.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..6a77657 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2085,7 +2085,7 @@ struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
 {
-    u32 val = -1;
+    u32 val = 0;
 
     pci_access_init();
     pci_read_block(pci_dev, addr, (u8 *) &val, len);

--------------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 Mon Jan 16 14:41:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmnjU-0003y5-FW; Mon, 16 Jan 2012 14:40:24 +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 1RmnjT-0003xc-7h
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:40:23 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326724816!11213563!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12441 invoked from network); 16 Jan 2012 14:40:17 -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;
	16 Jan 2012 14:40:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10053349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:40:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 14:40:16 +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 1RmnjL-0004Ex-OG;
	Mon, 16 Jan 2012 14:40:15 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RmnjE-0006hK-6U;
	Mon, 16 Jan 2012 14:40:08 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 14:40:07 +0000
Message-ID: <1326724807-25718-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>
Subject: [Xen-devel] [PATCH] [passthrough] Change init for pt_pci_host
	return value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


With an init of -1 all the return value smaller than a double word
will be prefixed with "f"s.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..6a77657 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2085,7 +2085,7 @@ struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
 {
-    u32 val = -1;
+    u32 val = 0;
 
     pci_access_init();
     pci_read_block(pci_dev, addr, (u8 *) &val, len);

--------------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 Mon Jan 16 14:41:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmnjn-00040V-Sq; Mon, 16 Jan 2012 14:40:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rmnjn-0003zb-2h
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:40:43 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326724836!11091062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11390 invoked from network); 16 Jan 2012 14:40:36 -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;
	16 Jan 2012 14:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10053364"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:40:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 14:40:36 +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 1Rmnjg-0004FA-3P;
	Mon, 16 Jan 2012 14:40:36 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RmnjY-0006hz-IP;
	Mon, 16 Jan 2012 14:40:28 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 14:40:27 +0000
Message-ID: <1326724827-25759-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>
Subject: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor specific
	pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


Some versions of the Windows Intel GPU driver expect the vendor
PCI capability to be there on the host bridge config space when
passing through a Intel GPU.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 46 insertions(+), 5 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..1120639 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -60,6 +60,44 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     }
 }
 
+#define PCI_INTEL_VENDOR_CAP            0x34
+#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
+static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
+                                        uint32_t val)
+{
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    uint32_t vendor_cap = 0;
+    uint32_t cap_type = 0;
+    uint32_t cap_size = 0;
+
+    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
+    if (config_addr == PCI_INTEL_VENDOR_CAP)
+    {
+        /* Only do the following for vendor specific caps (0x09) */
+        if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
+            return 0;
+
+        if (vendor_cap == 0)
+            return 0;
+    }
+
+    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
+    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
+
+    /* Remove the next capability link */
+    if (config_addr == vendor_cap + 1)
+        return 0;
+
+    if (config_addr >= vendor_cap &&
+            config_addr + len < vendor_cap + cap_size)
+    {
+        return pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+    }
+
+    /* -1, this function doesn't deal with this config space offset */
+    return -1;
+}
+
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -82,14 +120,17 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
             val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            val = pci_default_read_config(pci_dev, config_addr, len);
+            val = igd_pci_read_vendor_cap(pci_dev, config_addr, len, val);
+            if (val == -1)
+                val = pci_default_read_config(pci_dev, config_addr, len);
+
     }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+            config_addr, len, val);
+#endif
     return val;
 }
 

--------------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 Mon Jan 16 14:41:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:41:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmnjn-00040V-Sq; Mon, 16 Jan 2012 14:40:43 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rmnjn-0003zb-2h
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:40:43 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326724836!11091062!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11390 invoked from network); 16 Jan 2012 14:40:36 -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;
	16 Jan 2012 14:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10053364"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:40:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 14:40:36 +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 1Rmnjg-0004FA-3P;
	Mon, 16 Jan 2012 14:40:36 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RmnjY-0006hz-IP;
	Mon, 16 Jan 2012 14:40:28 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 14:40:27 +0000
Message-ID: <1326724827-25759-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>
Subject: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor specific
	pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


Some versions of the Windows Intel GPU driver expect the vendor
PCI capability to be there on the host bridge config space when
passing through a Intel GPU.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 46 insertions(+), 5 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..1120639 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -60,6 +60,44 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     }
 }
 
+#define PCI_INTEL_VENDOR_CAP            0x34
+#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
+static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
+                                        uint32_t val)
+{
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    uint32_t vendor_cap = 0;
+    uint32_t cap_type = 0;
+    uint32_t cap_size = 0;
+
+    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
+    if (config_addr == PCI_INTEL_VENDOR_CAP)
+    {
+        /* Only do the following for vendor specific caps (0x09) */
+        if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
+            return 0;
+
+        if (vendor_cap == 0)
+            return 0;
+    }
+
+    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
+    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
+
+    /* Remove the next capability link */
+    if (config_addr == vendor_cap + 1)
+        return 0;
+
+    if (config_addr >= vendor_cap &&
+            config_addr + len < vendor_cap + cap_size)
+    {
+        return pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+    }
+
+    /* -1, this function doesn't deal with this config space offset */
+    return -1;
+}
+
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -82,14 +120,17 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
             val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            val = pci_default_read_config(pci_dev, config_addr, len);
+            val = igd_pci_read_vendor_cap(pci_dev, config_addr, len, val);
+            if (val == -1)
+                val = pci_default_read_config(pci_dev, config_addr, len);
+
     }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+            config_addr, len, val);
+#endif
     return val;
 }
 

--------------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 Mon Jan 16 14:44:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14: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 1Rmnn1-0004N1-Nf; Mon, 16 Jan 2012 14:44:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1Rmnmz-0004MM-J6
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:44:01 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326725034!11124701!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 28256 invoked from network); 16 Jan 2012 14:43:55 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 14:43:55 -0000
Received: by vcbfo13 with SMTP id fo13so3194149vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 06:43:54 -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=A9yUwtWsS+hzX5SNNhB1ArNW1vfqXlLZGHdFcYOArOE=;
	b=iLsJfvpn3p1echxvaExUpaeLah/3ncdLY9pC8H2CNKTpIsItT7kUerjg5/8APwkFWM
	Dhphrm+fNTa1QiHgqQAbMEsLhSvpxkJs81RCkuq0a/8CM8amRQOXro4OGr3Nc1t2y07t
	tjInDGuh1CtAmW9EyuGUSYa2tIdHPOD9m1fr0=
MIME-Version: 1.0
Received: by 10.220.213.200 with SMTP id gx8mr7690416vcb.13.1326725034117;
	Mon, 16 Jan 2012 06:43:54 -0800 (PST)
Received: by 10.220.18.20 with HTTP; Mon, 16 Jan 2012 06:43:54 -0800 (PST)
In-Reply-To: <4F14345B.4040807@gmail.com>
References: <4F14345B.4040807@gmail.com>
Date: Mon, 16 Jan 2012 22:43:54 +0800
Message-ID: <CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
From: Nai Xia <nai.xia@gmail.com>
To: Grzegorz Milos <Grzegorz.Milos@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Is this a racing bug in page_make_sharable()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Grzegorz,

As I understand, the purpose of the code in page_make_sharable()
checking the ref count is to ensure that nobody unexpected is working
on the page, and so we can migrate it to dom_cow, right?

====
    /* Check if the ref count is 2. The first from PGT_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;
    }
====

However, it seems to me that this ref check and the following page
migration is not atomic( although the operations for type_info ref
check seems good) i.e. it's possible that it passed this ref
check but just before it goes to dom_cow, someone else gets this page?
As far as I know, in Linux kernel's similar scenarios, they do ref-freezing
tricks.

And if we don't need to worry about this racing case, then what is
this check trying to ensure?


Thanks,
Nai

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:44:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14: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 1Rmnn1-0004N1-Nf; Mon, 16 Jan 2012 14:44:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1Rmnmz-0004MM-J6
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:44:01 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326725034!11124701!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 28256 invoked from network); 16 Jan 2012 14:43:55 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 14:43:55 -0000
Received: by vcbfo13 with SMTP id fo13so3194149vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 06:43:54 -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=A9yUwtWsS+hzX5SNNhB1ArNW1vfqXlLZGHdFcYOArOE=;
	b=iLsJfvpn3p1echxvaExUpaeLah/3ncdLY9pC8H2CNKTpIsItT7kUerjg5/8APwkFWM
	Dhphrm+fNTa1QiHgqQAbMEsLhSvpxkJs81RCkuq0a/8CM8amRQOXro4OGr3Nc1t2y07t
	tjInDGuh1CtAmW9EyuGUSYa2tIdHPOD9m1fr0=
MIME-Version: 1.0
Received: by 10.220.213.200 with SMTP id gx8mr7690416vcb.13.1326725034117;
	Mon, 16 Jan 2012 06:43:54 -0800 (PST)
Received: by 10.220.18.20 with HTTP; Mon, 16 Jan 2012 06:43:54 -0800 (PST)
In-Reply-To: <4F14345B.4040807@gmail.com>
References: <4F14345B.4040807@gmail.com>
Date: Mon, 16 Jan 2012 22:43:54 +0800
Message-ID: <CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
From: Nai Xia <nai.xia@gmail.com>
To: Grzegorz Milos <Grzegorz.Milos@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Is this a racing bug in page_make_sharable()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Grzegorz,

As I understand, the purpose of the code in page_make_sharable()
checking the ref count is to ensure that nobody unexpected is working
on the page, and so we can migrate it to dom_cow, right?

====
    /* Check if the ref count is 2. The first from PGT_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;
    }
====

However, it seems to me that this ref check and the following page
migration is not atomic( although the operations for type_info ref
check seems good) i.e. it's possible that it passed this ref
check but just before it goes to dom_cow, someone else gets this page?
As far as I know, in Linux kernel's similar scenarios, they do ref-freezing
tricks.

And if we don't need to worry about this racing case, then what is
this check trying to ensure?


Thanks,
Nai

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:49:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmnrl-0004iV-R6; Mon, 16 Jan 2012 14:48:57 +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 1Rmnrk-0004hy-HD
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:48:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326725330!11234328!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 19348 invoked from network); 16 Jan 2012 14:48:50 -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; 16 Jan 2012 14:48:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Jan 2012 14:48:49 +0000
Message-Id: <4F1446DF020000780006CF46@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Jan 2012 14:48:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <anthony.perard@citrix.com>,
 "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<4F049293020000780006A6FE@nat28.tlf.novell.com>
	<1326721167.17210.449.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326721167.17210.449.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > What are the outstanding things to do before we think we can start on
>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>> > 
>> > hypervisor:
>> > 
>> >       * ??? - Keir, Tim, Jan?
>> 
>> Apart from a few small things that I have on my todo list, the only
>> bigger one (at least from an possible impact perspective) is the
>> round-up of the closing of the security hole in MSI-X passthrough
>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
>> table pages), which I intended to do only once the upstream qemu
>> patch series also incorporates the respective recent qemu-xen
>> change.
> 
> It sounds like this issue is a blocker for the release, whereas the
> upstream qemu support for pci passthrough is not necessarily. Has your
> precondition for inclusion been met yet or do we need to prod someone?

I didn't see updated upstream qemu patches since this was discussed
on irc - Anthony, do you have a rough time line?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:49:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmnrl-0004iV-R6; Mon, 16 Jan 2012 14:48:57 +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 1Rmnrk-0004hy-HD
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:48:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326725330!11234328!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 19348 invoked from network); 16 Jan 2012 14:48:50 -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; 16 Jan 2012 14:48:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 16 Jan 2012 14:48:49 +0000
Message-Id: <4F1446DF020000780006CF46@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 16 Jan 2012 14:48:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <anthony.perard@citrix.com>,
 "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<4F049293020000780006A6FE@nat28.tlf.novell.com>
	<1326721167.17210.449.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326721167.17210.449.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > What are the outstanding things to do before we think we can start on
>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>> > 
>> > hypervisor:
>> > 
>> >       * ??? - Keir, Tim, Jan?
>> 
>> Apart from a few small things that I have on my todo list, the only
>> bigger one (at least from an possible impact perspective) is the
>> round-up of the closing of the security hole in MSI-X passthrough
>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
>> table pages), which I intended to do only once the upstream qemu
>> patch series also incorporates the respective recent qemu-xen
>> change.
> 
> It sounds like this issue is a blocker for the release, whereas the
> upstream qemu support for pci passthrough is not necessarily. Has your
> precondition for inclusion been met yet or do we need to prod someone?

I didn't see updated upstream qemu patches since this was discussed
on irc - Anthony, do you have a rough time line?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:52:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14: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 1Rmnuk-0004ro-40; Mon, 16 Jan 2012 14:52:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1Rmnui-0004rc-LE
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:52:00 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326725513!3787823!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 27942 invoked from network); 16 Jan 2012 14:51:54 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 14:51:54 -0000
Received: by vbbfo1 with SMTP id fo1so10884958vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 06:51:53 -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=MWKyxEElpj/hz83KnPyN7e5SWv3zAf5vYM0n154p+d8=;
	b=wjADj9FxQwCZa66H6XqorZ2cxYjqy4v6N+iHu5tZEdIuAbyyofVERjrCm2Rijy0MTx
	l3d8/exrARaqmn44EISJZmjALvXKIsTK1LPJpVR0L8dZO+94hCZ+fPAyMcCUwyQwLRKn
	KuIyhEmTdfTvGzfksEZpfOPhoyzX/IdMBsRb0=
MIME-Version: 1.0
Received: by 10.52.88.193 with SMTP id bi1mr6003689vdb.105.1326725513165; Mon,
	16 Jan 2012 06:51:53 -0800 (PST)
Received: by 10.220.18.20 with HTTP; Mon, 16 Jan 2012 06:51:53 -0800 (PST)
Date: Mon, 16 Jan 2012 22:51:53 +0800
Message-ID: <CAPQyPG6JRzfR5TOuvZ+h415Hm2RF2BMbxtgKshA93SFmt=uiaQ@mail.gmail.com>
From: Nai Xia <nai.xia@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Is this a racing bug in page_make_sharable()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

As I understand, the purpose of the code in page_make_sharable()
checking the ref count is to ensure that nobody unexpected is working
on the page, and so we can migrate it to dom_cow, right?

====
   /* Check if the ref count is 2. The first from PGT_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;
   }
====

However, it seems to me that this ref check and the following page
migration is not atomic( although the operations for type_info ref
check seems good) i.e. it's possible that it passed this ref
check but just before it goes to dom_cow, someone else gets this page?
As far as I know, in Linux kernel's similar scenarios, they do ref-freezing
tricks.

And if we don't need to worry about this racing case, then what is
this check trying to ensure?


Thanks,
Nai

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:52:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14: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 1Rmnuk-0004ro-40; Mon, 16 Jan 2012 14:52:02 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nai.xia@gmail.com>) id 1Rmnui-0004rc-LE
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:52:00 +0000
X-Env-Sender: nai.xia@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326725513!3787823!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 27942 invoked from network); 16 Jan 2012 14:51:54 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 14:51:54 -0000
Received: by vbbfo1 with SMTP id fo1so10884958vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 06:51:53 -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=MWKyxEElpj/hz83KnPyN7e5SWv3zAf5vYM0n154p+d8=;
	b=wjADj9FxQwCZa66H6XqorZ2cxYjqy4v6N+iHu5tZEdIuAbyyofVERjrCm2Rijy0MTx
	l3d8/exrARaqmn44EISJZmjALvXKIsTK1LPJpVR0L8dZO+94hCZ+fPAyMcCUwyQwLRKn
	KuIyhEmTdfTvGzfksEZpfOPhoyzX/IdMBsRb0=
MIME-Version: 1.0
Received: by 10.52.88.193 with SMTP id bi1mr6003689vdb.105.1326725513165; Mon,
	16 Jan 2012 06:51:53 -0800 (PST)
Received: by 10.220.18.20 with HTTP; Mon, 16 Jan 2012 06:51:53 -0800 (PST)
Date: Mon, 16 Jan 2012 22:51:53 +0800
Message-ID: <CAPQyPG6JRzfR5TOuvZ+h415Hm2RF2BMbxtgKshA93SFmt=uiaQ@mail.gmail.com>
From: Nai Xia <nai.xia@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Is this a racing bug in page_make_sharable()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

As I understand, the purpose of the code in page_make_sharable()
checking the ref count is to ensure that nobody unexpected is working
on the page, and so we can migrate it to dom_cow, right?

====
   /* Check if the ref count is 2. The first from PGT_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;
   }
====

However, it seems to me that this ref check and the following page
migration is not atomic( although the operations for type_info ref
check seems good) i.e. it's possible that it passed this ref
check but just before it goes to dom_cow, someone else gets this page?
As far as I know, in Linux kernel's similar scenarios, they do ref-freezing
tricks.

And if we don't need to worry about this racing case, then what is
this check trying to ensure?


Thanks,
Nai

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:55:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14: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 1Rmny2-00059b-OC; Mon, 16 Jan 2012 14:55: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 1Rmny1-00059N-9r
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:55:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326725718!11235564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13626 invoked from network); 16 Jan 2012 14:55:18 -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;
	16 Jan 2012 14:55:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10054146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:55: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;
	Mon, 16 Jan 2012 14:55:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David TECHER <davidtecher@yahoo.fr>
Date: Mon, 16 Jan 2012 14:55:17 +0000
In-Reply-To: <1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
	<1326720500.17210.442.camel@zakaz.uk.xensource.com>
	<1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326725717.14689.2.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAxLTE2IGF0IDE0OjM5ICswMDAwLCBEYXZpZCBURUNIRVIgd3JvdGU6Cj4g
SSB0b2xkIGEgY291cGxlIHdlZWtzIGFnbyB0aGF0IEkgd2lsbCB0cnkgdG8gc3VibWl0IHRoZSBw
YXRjaGVzLgo+IAo+IAo+IFNvcnJ5IEkgYW0gbm90IHN1Ym1pdHRpbmcgcGF0Y2hlcy4gSSB3YXMv
YW0gdmVyeSBidXN5IHRoZXNlIGxhc3QKPiB3ZWVrcy4KPgo+IEkgd2lsbCB0cnkgdG8gc3VibWl0
IHBhdGNoZXMgZm9yIFZHQSBwYXNzdGhyb3VnaCB0aGlzIHdlZWstZW5kLgoKUGxlYXNlIGRvIHNl
bmQgdGhlbSBBU0FQIG9yIHdlIG1heSBub3QgYmUgYWJsZSB0byBpbmNsdWRlIHRoZW0gaW4gNC4y
LgoKSWFuLgoKPiAKPiAKPiBLaW5kIHJlZ2FyZHMuCj4gCj4gCj4gRGF2aWQuCj4gCj4gCj4gCj4g
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwo+IERlIDogSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4
LmNvbT4KPiDDgCA6IFBhc2kgS8Okcmtrw6RpbmVuIDxwYXNpa0Bpa2kuZmk+IAo+IENjIDogeGVu
LWRldmVsIDx4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbT47IEtlaXIgKFhlbi5vcmcpCj4g
PGtlaXJAeGVuLm9yZz47IFN0ZWZhbm8gU3RhYmVsbGluaSA8U3RlZmFuby5TdGFiZWxsaW5pQGV1
LmNpdHJpeC5jb20+Owo+IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjsg
VGltIChYZW4ub3JnKSA8dGltQHhlbi5vcmc+Owo+IEphbiBCZXVsaWNoIDxKQmV1bGljaEBzdXNl
LmNvbT4gCj4gRW52b3nDqSBsZSA6IEx1bmRpIDE2IEphbnZpZXIgMjAxMiAxNGgyOAo+IE9iamV0
IDogUmU6IFtYZW4tZGV2ZWxdIFJGQzogU3RpbGwgVE9ETyBmb3IgNC4yPwo+IAo+IAo+IE9uIFdl
ZCwgMjAxMi0wMS0wNCBhdCAxNzoyNSArMDAwMCwgUGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4g
PiAKPiA+IC0gQWxzbyB0aGVyZSdzIGEgYnVuY2ggb2YgVkdBIHBhc3N0aHJ1IHJlbGF0ZWQgcGF0
Y2hlcywKPiA+IHRoYXQgSSBvbmNlIHZvbHVudGVlcmVkIHRvIGNvbGxlY3QvcmViYXNlL2NsZWFu
dXAvcmVwb3N0IG15c2VsZiwKPiA+IGJ1dCBJIHN0aWxsIGhhdmVuJ3QgaGFkIHRpbWUgZm9yIHRo
YXQgOiggCj4gCj4gSSdtIG5vdCBnb2luZyB0byBpbmNsdWRlIHRoaXMgaW4gdGhlIGxpc3QgdW5s
ZXNzIHNvbWVvbmUgc3RlcHMgdXAgYW5kCj4gc3RhcnRzIHN1Ym1pdHRpbmcgcGF0Y2hlcy4KPiAK
PiBJYW4uCj4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPiAKPiAKPiAK
CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 16 14:55:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 14: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 1Rmny2-00059b-OC; Mon, 16 Jan 2012 14:55: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 1Rmny1-00059N-9r
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:55:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326725718!11235564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13626 invoked from network); 16 Jan 2012 14:55:18 -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;
	16 Jan 2012 14:55:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10054146"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:55: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;
	Mon, 16 Jan 2012 14:55:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David TECHER <davidtecher@yahoo.fr>
Date: Mon, 16 Jan 2012 14:55:17 +0000
In-Reply-To: <1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120104172519.GS12984@reaktio.net>
	<1326720500.17210.442.camel@zakaz.uk.xensource.com>
	<1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326725717.14689.2.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAxLTE2IGF0IDE0OjM5ICswMDAwLCBEYXZpZCBURUNIRVIgd3JvdGU6Cj4g
SSB0b2xkIGEgY291cGxlIHdlZWtzIGFnbyB0aGF0IEkgd2lsbCB0cnkgdG8gc3VibWl0IHRoZSBw
YXRjaGVzLgo+IAo+IAo+IFNvcnJ5IEkgYW0gbm90IHN1Ym1pdHRpbmcgcGF0Y2hlcy4gSSB3YXMv
YW0gdmVyeSBidXN5IHRoZXNlIGxhc3QKPiB3ZWVrcy4KPgo+IEkgd2lsbCB0cnkgdG8gc3VibWl0
IHBhdGNoZXMgZm9yIFZHQSBwYXNzdGhyb3VnaCB0aGlzIHdlZWstZW5kLgoKUGxlYXNlIGRvIHNl
bmQgdGhlbSBBU0FQIG9yIHdlIG1heSBub3QgYmUgYWJsZSB0byBpbmNsdWRlIHRoZW0gaW4gNC4y
LgoKSWFuLgoKPiAKPiAKPiBLaW5kIHJlZ2FyZHMuCj4gCj4gCj4gRGF2aWQuCj4gCj4gCj4gCj4g
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwo+IERlIDogSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4
LmNvbT4KPiDDgCA6IFBhc2kgS8Okcmtrw6RpbmVuIDxwYXNpa0Bpa2kuZmk+IAo+IENjIDogeGVu
LWRldmVsIDx4ZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbT47IEtlaXIgKFhlbi5vcmcpCj4g
PGtlaXJAeGVuLm9yZz47IFN0ZWZhbm8gU3RhYmVsbGluaSA8U3RlZmFuby5TdGFiZWxsaW5pQGV1
LmNpdHJpeC5jb20+Owo+IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjsg
VGltIChYZW4ub3JnKSA8dGltQHhlbi5vcmc+Owo+IEphbiBCZXVsaWNoIDxKQmV1bGljaEBzdXNl
LmNvbT4gCj4gRW52b3nDqSBsZSA6IEx1bmRpIDE2IEphbnZpZXIgMjAxMiAxNGgyOAo+IE9iamV0
IDogUmU6IFtYZW4tZGV2ZWxdIFJGQzogU3RpbGwgVE9ETyBmb3IgNC4yPwo+IAo+IAo+IE9uIFdl
ZCwgMjAxMi0wMS0wNCBhdCAxNzoyNSArMDAwMCwgUGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4g
PiAKPiA+IC0gQWxzbyB0aGVyZSdzIGEgYnVuY2ggb2YgVkdBIHBhc3N0aHJ1IHJlbGF0ZWQgcGF0
Y2hlcywKPiA+IHRoYXQgSSBvbmNlIHZvbHVudGVlcmVkIHRvIGNvbGxlY3QvcmViYXNlL2NsZWFu
dXAvcmVwb3N0IG15c2VsZiwKPiA+IGJ1dCBJIHN0aWxsIGhhdmVuJ3QgaGFkIHRpbWUgZm9yIHRo
YXQgOiggCj4gCj4gSSdtIG5vdCBnb2luZyB0byBpbmNsdWRlIHRoaXMgaW4gdGhlIGxpc3QgdW5s
ZXNzIHNvbWVvbmUgc3RlcHMgdXAgYW5kCj4gc3RhcnRzIHN1Ym1pdHRpbmcgcGF0Y2hlcy4KPiAK
PiBJYW4uCj4gCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KPiBYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Cj4gWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KPiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPiAKPiAKPiAK
CgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:00:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmo2K-0005Iz-JL; Mon, 16 Jan 2012 14:59:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rmo2I-0005Im-WD
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:59:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326725985!2397065!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1481 invoked from network); 16 Jan 2012 14:59: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;
	16 Jan 2012 14:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10054296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:59:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 14:59:45 +0000
Date: Mon, 16 Jan 2012 15:00: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: <4F1446DF020000780006CF46@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201161457230.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<4F049293020000780006A6FE@nat28.tlf.novell.com>
	<1326721167.17210.449.camel@zakaz.uk.xensource.com>
	<4F1446DF020000780006CF46@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 16 Jan 2012, Jan Beulich wrote:
> >>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > What are the outstanding things to do before we think we can start on
> >> > the 4.2 -rc's? Does anyone have a timetable in mind?
> >> > 
> >> > hypervisor:
> >> > 
> >> >       * ??? - Keir, Tim, Jan?
> >> 
> >> Apart from a few small things that I have on my todo list, the only
> >> bigger one (at least from an possible impact perspective) is the
> >> round-up of the closing of the security hole in MSI-X passthrough
> >> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
> >> table pages), which I intended to do only once the upstream qemu
> >> patch series also incorporates the respective recent qemu-xen
> >> change.
> > 
> > It sounds like this issue is a blocker for the release, whereas the
> > upstream qemu support for pci passthrough is not necessarily. Has your
> > precondition for inclusion been met yet or do we need to prod someone?
> 
> I didn't see updated upstream qemu patches since this was discussed
> on irc - Anthony, do you have a rough time line?
 
We had long discussions on qemu-devel and on #qemu, I think we have a
plan now and I am currently prototyping a different approach to solve
the issue. The new approach requires libxl support, so I would still
like to put upstream qemu save/restore in the roadmap, at least for the
libxl side.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:00:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:00:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmo2K-0005Iz-JL; Mon, 16 Jan 2012 14:59:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rmo2I-0005Im-WD
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:59:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326725985!2397065!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1481 invoked from network); 16 Jan 2012 14:59: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;
	16 Jan 2012 14:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10054296"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 14:59:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 14:59:45 +0000
Date: Mon, 16 Jan 2012 15:00: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: <4F1446DF020000780006CF46@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201161457230.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<4F049293020000780006A6FE@nat28.tlf.novell.com>
	<1326721167.17210.449.camel@zakaz.uk.xensource.com>
	<4F1446DF020000780006CF46@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 16 Jan 2012, Jan Beulich wrote:
> >>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > What are the outstanding things to do before we think we can start on
> >> > the 4.2 -rc's? Does anyone have a timetable in mind?
> >> > 
> >> > hypervisor:
> >> > 
> >> >       * ??? - Keir, Tim, Jan?
> >> 
> >> Apart from a few small things that I have on my todo list, the only
> >> bigger one (at least from an possible impact perspective) is the
> >> round-up of the closing of the security hole in MSI-X passthrough
> >> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
> >> table pages), which I intended to do only once the upstream qemu
> >> patch series also incorporates the respective recent qemu-xen
> >> change.
> > 
> > It sounds like this issue is a blocker for the release, whereas the
> > upstream qemu support for pci passthrough is not necessarily. Has your
> > precondition for inclusion been met yet or do we need to prod someone?
> 
> I didn't see updated upstream qemu patches since this was discussed
> on irc - Anthony, do you have a rough time line?
 
We had long discussions on qemu-devel and on #qemu, I think we have a
plan now and I am currently prototyping a different approach to solve
the issue. The new approach requires libxl support, so I would still
like to put upstream qemu save/restore in the roadmap, at least for the
libxl side.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:04:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmo73-0005VE-B0; Mon, 16 Jan 2012 15:04:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rmo71-0005V9-Sx
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:04:44 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326726237!50799642!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 16 Jan 2012 15:03:57 -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;
	16 Jan 2012 15:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10054824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 15:04: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, 16 Jan 2012 15:04:43 +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 1Rmo70-0004Ua-Ha;
	Mon, 16 Jan 2012 15:04:42 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rmo6t-0006jz-0D;
	Mon, 16 Jan 2012 15:04:35 +0000
Date: Mon, 16 Jan 2012 15:04:34 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <20120116150434.GC25486@spongy.cam.xci-test.com>
References: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326724827-25759-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>,
	Ross Philipson <Ross.Philipson@citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
 specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/01 02:40, Jean Guyader wrote:
> 
> Some versions of the Windows Intel GPU driver expect the vendor
> PCI capability to be there on the host bridge config space when
> passing through a Intel GPU.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
From: Ross Philipson <Ross.Philipson@citrix.com>

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:04:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:04:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmo73-0005VE-B0; Mon, 16 Jan 2012 15:04:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rmo71-0005V9-Sx
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:04:44 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326726237!50799642!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26214 invoked from network); 16 Jan 2012 15:03:57 -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;
	16 Jan 2012 15:03:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10054824"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 15:04: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, 16 Jan 2012 15:04:43 +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 1Rmo70-0004Ua-Ha;
	Mon, 16 Jan 2012 15:04:42 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rmo6t-0006jz-0D;
	Mon, 16 Jan 2012 15:04:35 +0000
Date: Mon, 16 Jan 2012 15:04:34 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <20120116150434.GC25486@spongy.cam.xci-test.com>
References: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326724827-25759-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>,
	Ross Philipson <Ross.Philipson@citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
 specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 16/01 02:40, Jean Guyader wrote:
> 
> Some versions of the Windows Intel GPU driver expect the vendor
> PCI capability to be there on the host bridge config space when
> passing through a Intel GPU.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
From: Ross Philipson <Ross.Philipson@citrix.com>

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:05:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmo7R-0005X4-OJ; Mon, 16 Jan 2012 15:05:09 +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 1Rmo7Q-0005Wm-Co
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:05:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326726301!9344078!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjg4NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjg4NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13854 invoked from network); 16 Jan 2012 15:05:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-10.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Jan 2012 15:05:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326726301; l=1261;
	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=eJqDTCdIhEAshXYxc4XwnN+J9KE=;
	b=h2esiSKMENI6IdkKAIGbfwOy4EPkbvqDKfqBjtiqhOZrCLMYfdDUNVduYZ/Q15zjTB/
	wJs0ycvZulT8W4p908x/gBL05m9mEA/CEmT+ksgVdmVMjEzrUJasgZ7voWmF7bM9DuM/4
	TmrEnhX6rVnFABMZ8PWi9+HDdQEciuDsW3M=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by post.strato.de (mrclete mo12) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N07255o0GF2voB ;
	Mon, 16 Jan 2012 16:04:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A1EB018637; Mon, 16 Jan 2012 16:04:44 +0100 (CET)
Date: Mon, 16 Jan 2012 16:04:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116150444.GA30327@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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, Jan 11, Andres Lagar-Cavilla wrote:

> @@ -898,7 +902,7 @@ void p2m_mem_paging_drop_page(struct dom
>   * already sent to the pager. In this case the caller has to try again until the
>   * gfn is fully paged in again.
>   */
> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>  {
>      struct vcpu *v = current;
>      mem_event_request_t req;

What is the reason to return an error here? None of the callers need to
check it because they already know their condition (which is
p2m_is_paging()). And your patch doesnt seem to update them. Foreigners
try again, requests from the target domain do currently also try again
until my change to use wait queues in gfn_to_mfn* is finished. And even
then the call p2m_mem_paging_populate() will most likely remain a
one-shot/must-succeed thing if the request is from the target domain.

The only condition to care about in p2m_mem_paging_populate() is -ENOSYS
from mem_event_claim_slot(), which your patch already handles by
crashing the guest. Since the guest is in an kind-of undefined state
anyway if the pager disappears while some gfns are still in paging state,
this is one of the possible actions.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:05:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:05:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmo7R-0005X4-OJ; Mon, 16 Jan 2012 15:05:09 +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 1Rmo7Q-0005Wm-Co
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:05:08 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326726301!9344078!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjg4NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjg4NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13854 invoked from network); 16 Jan 2012 15:05:02 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-10.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Jan 2012 15:05:02 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326726301; l=1261;
	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=eJqDTCdIhEAshXYxc4XwnN+J9KE=;
	b=h2esiSKMENI6IdkKAIGbfwOy4EPkbvqDKfqBjtiqhOZrCLMYfdDUNVduYZ/Q15zjTB/
	wJs0ycvZulT8W4p908x/gBL05m9mEA/CEmT+ksgVdmVMjEzrUJasgZ7voWmF7bM9DuM/4
	TmrEnhX6rVnFABMZ8PWi9+HDdQEciuDsW3M=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by post.strato.de (mrclete mo12) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N07255o0GF2voB ;
	Mon, 16 Jan 2012 16:04:44 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A1EB018637; Mon, 16 Jan 2012 16:04:44 +0100 (CET)
Date: Mon, 16 Jan 2012 16:04:44 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116150444.GA30327@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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, Jan 11, Andres Lagar-Cavilla wrote:

> @@ -898,7 +902,7 @@ void p2m_mem_paging_drop_page(struct dom
>   * already sent to the pager. In this case the caller has to try again until the
>   * gfn is fully paged in again.
>   */
> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>  {
>      struct vcpu *v = current;
>      mem_event_request_t req;

What is the reason to return an error here? None of the callers need to
check it because they already know their condition (which is
p2m_is_paging()). And your patch doesnt seem to update them. Foreigners
try again, requests from the target domain do currently also try again
until my change to use wait queues in gfn_to_mfn* is finished. And even
then the call p2m_mem_paging_populate() will most likely remain a
one-shot/must-succeed thing if the request is from the target domain.

The only condition to care about in p2m_mem_paging_populate() is -ENOSYS
from mem_event_claim_slot(), which your patch already handles by
crashing the guest. Since the guest is in an kind-of undefined state
anyway if the pager disappears while some gfns are still in paging state,
this is one of the possible actions.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:08:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15: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 1RmoAc-0005k5-C6; Mon, 16 Jan 2012 15:08:26 +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 1RmoAb-0005jH-4V
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:08:25 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326726497!8711887!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzYxMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11230 invoked from network); 16 Jan 2012 15:08:18 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-6.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 15:08:18 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4A7FD7EC078;
	Mon, 16 Jan 2012 07:08: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=mZGVUIGJSTJPan2DG11NoGG+ngnRJxtwjEvNMsWaVnpZ
	F1kGZrVVbXKykiaOuOcHACDFA7OehiZLdrxHUxVhlTHsgq9U3xfssc97QNpnVuO/
	C6xN2q1HaN09nZr2FQFjkOmKTef3Jq7Ef2R2kWWbcZSwaaZvCQ7F4CBdD3pmYyg=
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=XKZBiDGUZ3jb9Po5LJ804e8jdAQ=; b=DNt3pb+q
	K4g3OCYltPy/0gSotrS//rNjYlbhV91hud6KIeiVZdQ+nM5To1bRjjlcOlvwN5zm
	6h+zKyKu2X1qCZ2OqXuMhuqdqepHbzPG58jbJcW/ueygfiExSNneZ1eS6aga67jl
	lzKJhv3nebp1y7DD6wImVmWKksRMM1KOQr4=
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 DC0957EC069; 
	Mon, 16 Jan 2012 07:08: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;
	Mon, 16 Jan 2012 07:08:16 -0800
Message-ID: <953ee1a357fc032687dc9c49f80980cc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120116150444.GA30327@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120116150444.GA30327@aepfle.de>
Date: Mon, 16 Jan 2012 07:08:16 -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,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
>> @@ -898,7 +902,7 @@ void p2m_mem_paging_drop_page(struct dom
>>   * already sent to the pager. In this case the caller has to try again
>> until the
>>   * gfn is fully paged in again.
>>   */
>> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>>  {
>>      struct vcpu *v = current;
>>      mem_event_request_t req;
>
> What is the reason to return an error here? None of the callers need to
> check it because they already know their condition (which is
> p2m_is_paging()). And your patch doesnt seem to update them. Foreigners
> try again, requests from the target domain do currently also try again
> until my change to use wait queues in gfn_to_mfn* is finished. And even
> then the call p2m_mem_paging_populate() will most likely remain a
> one-shot/must-succeed thing if the request is from the target domain.
>
> The only condition to care about in p2m_mem_paging_populate() is -ENOSYS
> from mem_event_claim_slot(), which your patch already handles by
> crashing the guest. Since the guest is in an kind-of undefined state
> anyway if the pager disappears while some gfns are still in paging state,
> this is one of the possible actions.

Ok, we'll make it void. Anything else pending?
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 Mon Jan 16 15:08:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15: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 1RmoAc-0005k5-C6; Mon, 16 Jan 2012 15:08:26 +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 1RmoAb-0005jH-4V
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:08:25 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326726497!8711887!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzYxMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11230 invoked from network); 16 Jan 2012 15:08:18 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-6.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 15:08:18 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4A7FD7EC078;
	Mon, 16 Jan 2012 07:08: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=mZGVUIGJSTJPan2DG11NoGG+ngnRJxtwjEvNMsWaVnpZ
	F1kGZrVVbXKykiaOuOcHACDFA7OehiZLdrxHUxVhlTHsgq9U3xfssc97QNpnVuO/
	C6xN2q1HaN09nZr2FQFjkOmKTef3Jq7Ef2R2kWWbcZSwaaZvCQ7F4CBdD3pmYyg=
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=XKZBiDGUZ3jb9Po5LJ804e8jdAQ=; b=DNt3pb+q
	K4g3OCYltPy/0gSotrS//rNjYlbhV91hud6KIeiVZdQ+nM5To1bRjjlcOlvwN5zm
	6h+zKyKu2X1qCZ2OqXuMhuqdqepHbzPG58jbJcW/ueygfiExSNneZ1eS6aga67jl
	lzKJhv3nebp1y7DD6wImVmWKksRMM1KOQr4=
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 DC0957EC069; 
	Mon, 16 Jan 2012 07:08: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;
	Mon, 16 Jan 2012 07:08:16 -0800
Message-ID: <953ee1a357fc032687dc9c49f80980cc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120116150444.GA30327@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120116150444.GA30327@aepfle.de>
Date: Mon, 16 Jan 2012 07:08:16 -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,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Wed, Jan 11, Andres Lagar-Cavilla wrote:
>
>> @@ -898,7 +902,7 @@ void p2m_mem_paging_drop_page(struct dom
>>   * already sent to the pager. In this case the caller has to try again
>> until the
>>   * gfn is fully paged in again.
>>   */
>> -void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
>>  {
>>      struct vcpu *v = current;
>>      mem_event_request_t req;
>
> What is the reason to return an error here? None of the callers need to
> check it because they already know their condition (which is
> p2m_is_paging()). And your patch doesnt seem to update them. Foreigners
> try again, requests from the target domain do currently also try again
> until my change to use wait queues in gfn_to_mfn* is finished. And even
> then the call p2m_mem_paging_populate() will most likely remain a
> one-shot/must-succeed thing if the request is from the target domain.
>
> The only condition to care about in p2m_mem_paging_populate() is -ENOSYS
> from mem_event_claim_slot(), which your patch already handles by
> crashing the guest. Since the guest is in an kind-of undefined state
> anyway if the pager disappears while some gfns are still in paging state,
> this is one of the possible actions.

Ok, we'll make it void. Anything else pending?
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 Mon Jan 16 15:08:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:08:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoAd-0005kR-Ob; Mon, 16 Jan 2012 15:08:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RmoAc-0005jO-7Y
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:08:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326726384!59895652!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg1ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg1ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19065 invoked from network); 16 Jan 2012 15:06:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Jan 2012 15:06:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326726499; l=1459;
	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=3O3U9kXppkJnmF4VGbpi9kw1abw=;
	b=uFz8EjQ5n6s33Tyz8TBxF+VObKtp2K7xKcSReAV/h5MWaOHONp5F3LZfzSWSF+Bhlz3
	isTaL9RoZWJfZ/pdi9FFC84nYTmBlBcXH5ND4YTu9v4bVzxyGxJymke6iu3cn86zHzLJB
	YGtVs57hTdKvxQN0iX7zA+8ZKOhV6c9RQwg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by post.strato.de (mrclete mo51) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a01466o0GEAOOr ;
	Mon, 16 Jan 2012 16:08:01 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D470218637; Mon, 16 Jan 2012 16:08:01 +0100 (CET)
Date: Mon, 16 Jan 2012 16:08:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116150801.GB30327@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
	<873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
	<20120113195706.GA26566@aepfle.de>
	<c7c228ea2fa1f07ffbdfbb167bec5152.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c7c228ea2fa1f07ffbdfbb167bec5152.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Fri, Jan 13, Andres Lagar-Cavilla wrote:

> > On Fri, Jan 13, Andres Lagar-Cavilla wrote:
> >
> >> > p2m_mem_paging_drop_page() should remain void because the caller has
> >> > already done its work, making it not restartable. Also it is only
> >> called
> >> > when a gfn is in paging state, which I'm sure can not happen without a
> >> > ring.
> >>
> >> Well, the rationale is that returning an error code can only help,
> >> should
> >> new error conditions arise. Keep in mind that the pager and the ring can
> >> disappear at any time, so ENOSYS can still happen.
> >
> > The ring should rather not disappear at all until ->paged_pages drops to
> > zero. Unless the goal is a restartable pager,
> > XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when
> > ->pages_pages is not zero. Then the checks in drop_page and populate can
> > be relaxed.
> 
> Well, there are two separate things here. Should drop return an error
> code? No harm in that. Then there is your point about the ring not going
> away if ->paged_pages is nonzero. Which I like, but is currently not
> implemented, afaict. Separate patch I guess.

Since there is no consumer of the added return codes from
p2m_mem_paging_drop_page() and p2m_mem_paging_populate() I dont see the
point to change the function prototypes.

I will prepare a patch to improve the check wether the ring is
available. As you said, it can disappear any time.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:08:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:08:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoAd-0005kR-Ob; Mon, 16 Jan 2012 15:08:27 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RmoAc-0005jO-7Y
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:08:26 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326726384!59895652!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg1ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg1ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19065 invoked from network); 16 Jan 2012 15:06:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Jan 2012 15:06:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326726499; l=1459;
	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=3O3U9kXppkJnmF4VGbpi9kw1abw=;
	b=uFz8EjQ5n6s33Tyz8TBxF+VObKtp2K7xKcSReAV/h5MWaOHONp5F3LZfzSWSF+Bhlz3
	isTaL9RoZWJfZ/pdi9FFC84nYTmBlBcXH5ND4YTu9v4bVzxyGxJymke6iu3cn86zHzLJB
	YGtVs57hTdKvxQN0iX7zA+8ZKOhV6c9RQwg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by post.strato.de (mrclete mo51) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a01466o0GEAOOr ;
	Mon, 16 Jan 2012 16:08:01 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D470218637; Mon, 16 Jan 2012 16:08:01 +0100 (CET)
Date: Mon, 16 Jan 2012 16:08:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116150801.GB30327@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
	<873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
	<20120113195706.GA26566@aepfle.de>
	<c7c228ea2fa1f07ffbdfbb167bec5152.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c7c228ea2fa1f07ffbdfbb167bec5152.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Fri, Jan 13, Andres Lagar-Cavilla wrote:

> > On Fri, Jan 13, Andres Lagar-Cavilla wrote:
> >
> >> > p2m_mem_paging_drop_page() should remain void because the caller has
> >> > already done its work, making it not restartable. Also it is only
> >> called
> >> > when a gfn is in paging state, which I'm sure can not happen without a
> >> > ring.
> >>
> >> Well, the rationale is that returning an error code can only help,
> >> should
> >> new error conditions arise. Keep in mind that the pager and the ring can
> >> disappear at any time, so ENOSYS can still happen.
> >
> > The ring should rather not disappear at all until ->paged_pages drops to
> > zero. Unless the goal is a restartable pager,
> > XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when
> > ->pages_pages is not zero. Then the checks in drop_page and populate can
> > be relaxed.
> 
> Well, there are two separate things here. Should drop return an error
> code? No harm in that. Then there is your point about the ring not going
> away if ->paged_pages is nonzero. Which I like, but is currently not
> implemented, afaict. Separate patch I guess.

Since there is no consumer of the added return codes from
p2m_mem_paging_drop_page() and p2m_mem_paging_populate() I dont see the
point to change the function prototypes.

I will prepare a patch to improve the check wether the ring is
available. As you said, it can disappear any time.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:11:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoDQ-000628-Gf; Mon, 16 Jan 2012 15:11:20 +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 1RmoDO-00061p-VA
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:11:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326726671!11119039!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjg4NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjg4NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8509 invoked from network); 16 Jan 2012 15:11:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Jan 2012 15:11:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326726671; l=974;
	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=4taObxVbEtKJ1SYXbM2SCv/yBng=;
	b=HYngGB5S6C830rViEkQ1v6DR7G8B+6k+tPJ20SsOP7+xZOrDtZIoLk3USns1E09IcwK
	uVLkDHWH5GPwbMyoLKgS5hH+4gzbMbLphRQ/VuhpsfWUarVnLntpVUm2ZBZKL48r2EPkb
	NQ7dWOABVn5VCvM5WAQfytNnrkQmt8HbCiw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (fruni mo45) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 60335ao0GDKtFU ;
	Mon, 16 Jan 2012 16:10:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 843B218637; Mon, 16 Jan 2012 16:10:58 +0100 (CET)
Date: Mon, 16 Jan 2012 16:10:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116151058.GC30327@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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, Jan 11, Andres Lagar-Cavilla wrote:

>  xen/arch/x86/hvm/hvm.c          |   18 +-
>  xen/arch/x86/mm/mem_event.c     |  298 +++++++++++++++++++++++++++++++++------
>  xen/arch/x86/mm/mem_sharing.c   |   30 +--
>  xen/arch/x86/mm/p2m.c           |   81 +++++-----
>  xen/common/memory.c             |    7 +-
>  xen/include/asm-x86/mem_event.h |   22 +-
>  xen/include/asm-x86/p2m.h       |   12 +-
>  xen/include/xen/mm.h            |    2 +
>  xen/include/xen/sched.h         |   22 ++-
>  9 files changed, 359 insertions(+), 133 deletions(-)
> 
> 
> This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
> and our work.
> 
> It combines logic changes to simplify the memory event API, as well as
> leveraging wait queues to deal with extreme conditions in which too many events are
> generated by a guest vcpu.

I'm ok with the approach, and it looks like the approach does not
conflict with my attempt to use waitqueues in get_gfn_type_access().
If the ring is full, the vcpu is put in a wait queue.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:11:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:11:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoDQ-000628-Gf; Mon, 16 Jan 2012 15:11:20 +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 1RmoDO-00061p-VA
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:11:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326726671!11119039!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjg4NzQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjg4NzQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8509 invoked from network); 16 Jan 2012 15:11:12 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-6.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Jan 2012 15:11:12 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326726671; l=974;
	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=4taObxVbEtKJ1SYXbM2SCv/yBng=;
	b=HYngGB5S6C830rViEkQ1v6DR7G8B+6k+tPJ20SsOP7+xZOrDtZIoLk3USns1E09IcwK
	uVLkDHWH5GPwbMyoLKgS5hH+4gzbMbLphRQ/VuhpsfWUarVnLntpVUm2ZBZKL48r2EPkb
	NQ7dWOABVn5VCvM5WAQfytNnrkQmt8HbCiw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (fruni mo45) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 60335ao0GDKtFU ;
	Mon, 16 Jan 2012 16:10:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 843B218637; Mon, 16 Jan 2012 16:10:58 +0100 (CET)
Date: Mon, 16 Jan 2012 16:10:58 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116151058.GC30327@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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, Jan 11, Andres Lagar-Cavilla wrote:

>  xen/arch/x86/hvm/hvm.c          |   18 +-
>  xen/arch/x86/mm/mem_event.c     |  298 +++++++++++++++++++++++++++++++++------
>  xen/arch/x86/mm/mem_sharing.c   |   30 +--
>  xen/arch/x86/mm/p2m.c           |   81 +++++-----
>  xen/common/memory.c             |    7 +-
>  xen/include/asm-x86/mem_event.h |   22 +-
>  xen/include/asm-x86/p2m.h       |   12 +-
>  xen/include/xen/mm.h            |    2 +
>  xen/include/xen/sched.h         |   22 ++-
>  9 files changed, 359 insertions(+), 133 deletions(-)
> 
> 
> This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
> and our work.
> 
> It combines logic changes to simplify the memory event API, as well as
> leveraging wait queues to deal with extreme conditions in which too many events are
> generated by a guest vcpu.

I'm ok with the approach, and it looks like the approach does not
conflict with my attempt to use waitqueues in get_gfn_type_access().
If the ring is full, the vcpu is put in a wait queue.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:11:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 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 1RmoDm-00065V-Qj; Mon, 16 Jan 2012 15:11:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RmoDl-00064X-PD
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:11:41 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326726693!11109757!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15750 invoked from network); 16 Jan 2012 15:11:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 15:11:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="177700484"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:11:33 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Mon, 16 Jan 2012
	10:11:33 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 10:11:40 -0500
Thread-Topic: [PATCH] intel gpu passthrough: Expose vendor specific pci cap
	on host bridge.
Thread-Index: AczUYC37TxfSHUKSTOa7iT3f22SMawAAO0bQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724DE76EDF@FTLPMAILBOX02.citrite.net>
References: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120116150434.GC25486@spongy.cam.xci-test.com>
In-Reply-To: <20120116150434.GC25486@spongy.cam.xci-test.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] intel gpu passthrough: Expose vendor
 specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Jean Guyader [mailto:jean.guyader@eu.citrix.com]
> Sent: Monday, January 16, 2012 10:05 AM
> To: xen-devel@lists.xensource.com
> Cc: allen.m.kay@intel.com; Ian Jackson; Jean Guyader; Ross Philipson
> Subject: Re: [PATCH] intel gpu passthrough: Expose vendor specific pci
> cap on host bridge.
> 
> On 16/01 02:40, Jean Guyader wrote:
> >
> > Some versions of the Windows Intel GPU driver expect the vendor PCI
> > capability to be there on the host bridge config space when passing
> > through a Intel GPU.
> >
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> From: Ross Philipson <Ross.Philipson@citrix.com>
> 
> Jean
Acked-by: Ross Philipson <Ross.Philipson@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 Jan 16 15:11:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 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 1RmoDm-00065V-Qj; Mon, 16 Jan 2012 15:11:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ross.Philipson@citrix.com>) id 1RmoDl-00064X-PD
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:11:41 +0000
X-Env-Sender: Ross.Philipson@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326726693!11109757!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15750 invoked from network); 16 Jan 2012 15:11:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 15:11:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="177700484"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 10:11:33 -0500
Received: from FTLPMAILBOX02.citrite.net ([10.13.98.209]) by
	FTLPMAILMX01.citrite.net ([10.13.107.65]) with mapi; Mon, 16 Jan 2012
	10:11:33 -0500
From: Ross Philipson <Ross.Philipson@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 10:11:40 -0500
Thread-Topic: [PATCH] intel gpu passthrough: Expose vendor specific pci cap
	on host bridge.
Thread-Index: AczUYC37TxfSHUKSTOa7iT3f22SMawAAO0bQ
Message-ID: <831D55AF5A11D64C9B4B43F59EEBF720724DE76EDF@FTLPMAILBOX02.citrite.net>
References: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120116150434.GC25486@spongy.cam.xci-test.com>
In-Reply-To: <20120116150434.GC25486@spongy.cam.xci-test.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] intel gpu passthrough: Expose vendor
 specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



> -----Original Message-----
> From: Jean Guyader [mailto:jean.guyader@eu.citrix.com]
> Sent: Monday, January 16, 2012 10:05 AM
> To: xen-devel@lists.xensource.com
> Cc: allen.m.kay@intel.com; Ian Jackson; Jean Guyader; Ross Philipson
> Subject: Re: [PATCH] intel gpu passthrough: Expose vendor specific pci
> cap on host bridge.
> 
> On 16/01 02:40, Jean Guyader wrote:
> >
> > Some versions of the Windows Intel GPU driver expect the vendor PCI
> > capability to be there on the host bridge config space when passing
> > through a Intel GPU.
> >
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> From: Ross Philipson <Ross.Philipson@citrix.com>
> 
> Jean
Acked-by: Ross Philipson <Ross.Philipson@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 Jan 16 15:12:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15: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 1RmoEe-0006FV-9D; Mon, 16 Jan 2012 15:12:36 +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 1RmoEc-0006EB-OF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:12:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326726746!9321239!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzg0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32022 invoked from network); 16 Jan 2012 15:12:27 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-8.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 15:12:27 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 291864B008F;
	Mon, 16 Jan 2012 07:12: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=Cc5HbJIdvDAuzxGuqkUAFVP4/ryJxUeoN5qvULOjDnzY
	4h82209u3KzEioa3TJ0E4TAqtCwpF9tJFSugFnWpD7M9aYN9zsVtyU/29mHNcHVY
	fvAifseJx7C44gMM7cQZMAVuIhtScmnGWGIDZwe1yuM6x95qn4w7U8d5eVHjTeQ=
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=RTVWdPp+ttEpSMbUge7vAyrC0hs=; b=Zr96yWeG
	C0d7SGfFxkeQj+/3dSw+APvck5pYEtmePG9RuXKha6B3cBTbc9vdGGLXN2SwNdCn
	mKId81iMHJVb+C8VR1tduqpg/eY8qf98sFHkp8xvKGxuoRFEahZVrghEAr/X10ts
	fUP2kqM4NM0SZnBb+2kTGqxaVzAlS2agNm8=
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 B3DD84B0091; 
	Mon, 16 Jan 2012 07:12: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;
	Mon, 16 Jan 2012 07:12:26 -0800
Message-ID: <8da50621783ffb0e1f4bce866ae12d58.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.456.1326725042.1471.xen-devel@lists.xensource.com>
References: <mailman.456.1326725042.1471.xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 07:12:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] RFC: Still TODO for 4.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

> Date: Mon, 16 Jan 2012 13:39:27 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Jan Beulich <JBeulich@suse.com>
> Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)"
> 	<tim@xen.org>,	xen-devel <xen-devel@lists.xensource.com>,	Ian Jackson
> 	<Ian.Jackson@eu.citrix.com>,	Stefano Stabellini
> 	<Stefano.Stabellini@eu.citrix.com>
> Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
> Message-ID: <1326721167.17210.449.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > What are the outstanding things to do before we think we can start on
>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>> >
>> > hypervisor:
>> >
>> >       * ??? - Keir, Tim, Jan?
Insofar paging/sharing for 4.2:
- mem event ring management posted, seems close to going in.
- I would love to have wait queue support for paging, which Olaf is
working on.
- Just posted sharing patches.
- A long standing issue is a fully synchronized p2m (locking lookups),
which is something I'll look into as all of the above becomes resolved.

Thanks,
Andres
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 16 Jan 2012 13:42:49 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
> Cc: xen-devel <xen-devel@lists.xensource.com>,	"Keir \(Xen.org\)"
> 	<keir@xen.org>,	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,	Ian
> 	Jackson <Ian.Jackson@eu.citrix.com>, "Tim	\(Xen.org\)" <tim@xen.org>,
> 	Jan Beulich <JBeulich@suse.com>
> Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
> Message-ID: <1326721369.17210.452.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2012-01-04 at 16:51 +0000, Stefano Stabellini wrote:
>> On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
>> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
>> > >       * Integrate qemu+seabios upstream into the build (Stefano has
>> > >         posted patches, I guess they need refreshing and reposting).
>> No
>> > >         change in default qemu for 4.2.
>> >
>> > Anthony's PCI passthrough patches?
>>
>> Right. And Anthony's save/restore patches as well.
>
> Since these are dependent on external factors (qemu upstream) are we
> willing to block our own release for them?
>
> Given that upstream qemu won't be the default in this release I think
> the answer is "no", although obviously they are nice to haves.
>
> Ian.
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 16 Jan 2012 14:30:54 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Paul Durrant <Paul.Durrant@citrix.com>
> 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] [xen-unstable bisection] complete
> 	test-i386-i386-xl
> Message-ID: <20244.13470.956567.815603@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete
> test-i386-i386-xl"):
>> > -----Original Message-----
>> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> ...
>> > So as you were the author of the original patch, can you please try to
>> > reproduce the problem and fix it ?
>> >
>>
>> Already on it.
>
> Great, thanks.  If you need any help, or to borrow the machine from my
> test pool, or something, just let me know.
>
> Ian.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 16 Jan 2012 14:39:07 +0000 (GMT)
> From: David TECHER <davidtecher@yahoo.fr>
> To: Ian Campbell <Ian.Campbell@citrix.com>, Pasi K?rkk?inen
> 	<pasik@iki.fi>
> Cc: xen-devel <xen-devel@lists.xensource.com>,	"Keir \(Xen.org\)"
> 	<keir@xen.org>,	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
> 	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson
> 	<Ian.Jackson@eu.citrix.com>,	Jan Beulich <JBeulich@suse.com>
> Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
> Message-ID:
> 	<1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I told a couple weeks ago that I will try to submit the patches.
>
> Sorry I am not submitting patches. I was/am very busy these last weeks.
>
>
> I will try to submit patches for VGA passthrough this week-end.
>
> Kind regards.
>
> David.
>
>
>
> ________________________________
>  De?: Ian Campbell <Ian.Campbell@citrix.com>
> ??: Pasi K?rkk?inen <pasik@iki.fi>
> Cc?: xen-devel <xen-devel@lists.xensource.com>; Keir (Xen.org)
> <keir@xen.org>; Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>; Ian
> Jackson <Ian.Jackson@eu.citrix.com>; Tim (Xen.org) <tim@xen.org>; Jan
> Beulich <JBeulich@suse.com>
> Envoy? le : Lundi 16 Janvier 2012 14h28
> Objet?: Re: [Xen-devel] RFC: Still TODO for 4.2?
>
> On Wed, 2012-01-04 at 17:25 +0000, Pasi K?rkk?inen wrote:
>>
>> - Also there's a bunch of VGA passthru related patches,
>> that I once volunteered to collect/rebase/cleanup/repost myself,
>> but I still haven't had time for that :(
>
> I'm not going to include this in the list unless someone steps up and
> starts submitting patches.
>
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/a7a09a9a/attachment.html>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 16 Jan 2012 14:40:07 +0000
> From: Jean Guyader <jean.guyader@eu.citrix.com>
> To: <xen-devel@lists.xensource.com>
> Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,	Jean Guyader
> 	<jean.guyader@eu.citrix.com>
> Subject: [Xen-devel] [PATCH] [passthrough] Change init for pt_pci_host
> 	return value.
> Message-ID:
> 	<1326724807-25718-1-git-send-email-jean.guyader@eu.citrix.com>
> Content-Type: text/plain; charset="utf-8"; Format="fixed"
>
>
> With an init of -1 all the return value smaller than a double word
> will be prefixed with "f"s.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-passthrough-Change-init-for-pt_pci_host-return-value.patch
> Type: text/x-patch
> Size: 396 bytes
> Desc: not available
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/ec356780/attachment.bin>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 16 Jan 2012 14:40:27 +0000
> From: Jean Guyader <jean.guyader@eu.citrix.com>
> To: xen-devel@lists.xensource.com
> Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,	Jean Guyader
> 	<jean.guyader@eu.citrix.com>
> Subject: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
> 	specific	pci cap on host bridge.
> Message-ID:
> 	<1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
> Content-Type: text/plain; charset="utf-8"; Format="fixed"
>
>
> Some versions of the Windows Intel GPU driver expect the vendor
> PCI capability to be there on the host bridge config space when
> passing through a Intel GPU.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pt-graphics.c |   51
> ++++++++++++++++++++++++++++++++++++++++++++++-----
>  1 files changed, 46 insertions(+), 5 deletions(-)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch
> Type: text/x-patch
> Size: 2551 bytes
> Desc: not available
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/fa8c7dac/attachment.bin>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 16 Jan 2012 22:43:54 +0800
> From: Nai Xia <nai.xia@gmail.com>
> To: Grzegorz Milos <Grzegorz.Milos@citrix.com>
> Cc: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Is this a racing bug in page_make_sharable()?
> Message-ID:
> 	<CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Grzegorz,
>
> As I understand, the purpose of the code in page_make_sharable()
> checking the ref count is to ensure that nobody unexpected is working
> on the page, and so we can migrate it to dom_cow, right?
>
> ====
>     /* Check if the ref count is 2. The first from PGT_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;
>     }
> ====
>
> However, it seems to me that this ref check and the following page
> migration is not atomic( although the operations for type_info ref
> check seems good) i.e. it's possible that it passed this ref
> check but just before it goes to dom_cow, someone else gets this page?
> As far as I know, in Linux kernel's similar scenarios, they do
> ref-freezing
> tricks.
>
> And if we don't need to worry about this racing case, then what is
> this check trying to ensure?
>
>
> Thanks,
> Nai
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 233
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:12:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15: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 1RmoEe-0006FV-9D; Mon, 16 Jan 2012 15:12:36 +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 1RmoEc-0006EB-OF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:12:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326726746!9321239!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzg0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32022 invoked from network); 16 Jan 2012 15:12:27 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-8.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 15:12:27 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 291864B008F;
	Mon, 16 Jan 2012 07:12: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=Cc5HbJIdvDAuzxGuqkUAFVP4/ryJxUeoN5qvULOjDnzY
	4h82209u3KzEioa3TJ0E4TAqtCwpF9tJFSugFnWpD7M9aYN9zsVtyU/29mHNcHVY
	fvAifseJx7C44gMM7cQZMAVuIhtScmnGWGIDZwe1yuM6x95qn4w7U8d5eVHjTeQ=
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=RTVWdPp+ttEpSMbUge7vAyrC0hs=; b=Zr96yWeG
	C0d7SGfFxkeQj+/3dSw+APvck5pYEtmePG9RuXKha6B3cBTbc9vdGGLXN2SwNdCn
	mKId81iMHJVb+C8VR1tduqpg/eY8qf98sFHkp8xvKGxuoRFEahZVrghEAr/X10ts
	fUP2kqM4NM0SZnBb+2kTGqxaVzAlS2agNm8=
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 B3DD84B0091; 
	Mon, 16 Jan 2012 07:12: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;
	Mon, 16 Jan 2012 07:12:26 -0800
Message-ID: <8da50621783ffb0e1f4bce866ae12d58.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.456.1326725042.1471.xen-devel@lists.xensource.com>
References: <mailman.456.1326725042.1471.xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 07:12:26 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] RFC: Still TODO for 4.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

> Date: Mon, 16 Jan 2012 13:39:27 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Jan Beulich <JBeulich@suse.com>
> Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)"
> 	<tim@xen.org>,	xen-devel <xen-devel@lists.xensource.com>,	Ian Jackson
> 	<Ian.Jackson@eu.citrix.com>,	Stefano Stabellini
> 	<Stefano.Stabellini@eu.citrix.com>
> Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
> Message-ID: <1326721167.17210.449.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > What are the outstanding things to do before we think we can start on
>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>> >
>> > hypervisor:
>> >
>> >       * ??? - Keir, Tim, Jan?
Insofar paging/sharing for 4.2:
- mem event ring management posted, seems close to going in.
- I would love to have wait queue support for paging, which Olaf is
working on.
- Just posted sharing patches.
- A long standing issue is a fully synchronized p2m (locking lookups),
which is something I'll look into as all of the above becomes resolved.

Thanks,
Andres
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 16 Jan 2012 13:42:49 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
> Cc: xen-devel <xen-devel@lists.xensource.com>,	"Keir \(Xen.org\)"
> 	<keir@xen.org>,	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,	Ian
> 	Jackson <Ian.Jackson@eu.citrix.com>, "Tim	\(Xen.org\)" <tim@xen.org>,
> 	Jan Beulich <JBeulich@suse.com>
> Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
> Message-ID: <1326721369.17210.452.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2012-01-04 at 16:51 +0000, Stefano Stabellini wrote:
>> On Wed, 4 Jan 2012, Konrad Rzeszutek Wilk wrote:
>> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
>> > >       * Integrate qemu+seabios upstream into the build (Stefano has
>> > >         posted patches, I guess they need refreshing and reposting).
>> No
>> > >         change in default qemu for 4.2.
>> >
>> > Anthony's PCI passthrough patches?
>>
>> Right. And Anthony's save/restore patches as well.
>
> Since these are dependent on external factors (qemu upstream) are we
> willing to block our own release for them?
>
> Given that upstream qemu won't be the default in this release I think
> the answer is "no", although obviously they are nice to haves.
>
> Ian.
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 16 Jan 2012 14:30:54 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Paul Durrant <Paul.Durrant@citrix.com>
> 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] [xen-unstable bisection] complete
> 	test-i386-i386-xl
> Message-ID: <20244.13470.956567.815603@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete
> test-i386-i386-xl"):
>> > -----Original Message-----
>> > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> ...
>> > So as you were the author of the original patch, can you please try to
>> > reproduce the problem and fix it ?
>> >
>>
>> Already on it.
>
> Great, thanks.  If you need any help, or to borrow the machine from my
> test pool, or something, just let me know.
>
> Ian.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 16 Jan 2012 14:39:07 +0000 (GMT)
> From: David TECHER <davidtecher@yahoo.fr>
> To: Ian Campbell <Ian.Campbell@citrix.com>, Pasi K?rkk?inen
> 	<pasik@iki.fi>
> Cc: xen-devel <xen-devel@lists.xensource.com>,	"Keir \(Xen.org\)"
> 	<keir@xen.org>,	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
> 	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson
> 	<Ian.Jackson@eu.citrix.com>,	Jan Beulich <JBeulich@suse.com>
> Subject: [Xen-devel] Re :  RFC: Still TODO for 4.2?
> Message-ID:
> 	<1326724747.73001.YahooMailNeo@web29802.mail.ird.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I told a couple weeks ago that I will try to submit the patches.
>
> Sorry I am not submitting patches. I was/am very busy these last weeks.
>
>
> I will try to submit patches for VGA passthrough this week-end.
>
> Kind regards.
>
> David.
>
>
>
> ________________________________
>  De?: Ian Campbell <Ian.Campbell@citrix.com>
> ??: Pasi K?rkk?inen <pasik@iki.fi>
> Cc?: xen-devel <xen-devel@lists.xensource.com>; Keir (Xen.org)
> <keir@xen.org>; Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>; Ian
> Jackson <Ian.Jackson@eu.citrix.com>; Tim (Xen.org) <tim@xen.org>; Jan
> Beulich <JBeulich@suse.com>
> Envoy? le : Lundi 16 Janvier 2012 14h28
> Objet?: Re: [Xen-devel] RFC: Still TODO for 4.2?
>
> On Wed, 2012-01-04 at 17:25 +0000, Pasi K?rkk?inen wrote:
>>
>> - Also there's a bunch of VGA passthru related patches,
>> that I once volunteered to collect/rebase/cleanup/repost myself,
>> but I still haven't had time for that :(
>
> I'm not going to include this in the list unless someone steps up and
> starts submitting patches.
>
> Ian.
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/a7a09a9a/attachment.html>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 16 Jan 2012 14:40:07 +0000
> From: Jean Guyader <jean.guyader@eu.citrix.com>
> To: <xen-devel@lists.xensource.com>
> Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,	Jean Guyader
> 	<jean.guyader@eu.citrix.com>
> Subject: [Xen-devel] [PATCH] [passthrough] Change init for pt_pci_host
> 	return value.
> Message-ID:
> 	<1326724807-25718-1-git-send-email-jean.guyader@eu.citrix.com>
> Content-Type: text/plain; charset="utf-8"; Format="fixed"
>
>
> With an init of -1 all the return value smaller than a double word
> will be prefixed with "f"s.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pass-through.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-passthrough-Change-init-for-pt_pci_host-return-value.patch
> Type: text/x-patch
> Size: 396 bytes
> Desc: not available
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/ec356780/attachment.bin>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 16 Jan 2012 14:40:27 +0000
> From: Jean Guyader <jean.guyader@eu.citrix.com>
> To: xen-devel@lists.xensource.com
> Cc: Ian.Jackson@eu.citrix.com, allen.m.kay@intel.com,	Jean Guyader
> 	<jean.guyader@eu.citrix.com>
> Subject: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
> 	specific	pci cap on host bridge.
> Message-ID:
> 	<1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
> Content-Type: text/plain; charset="utf-8"; Format="fixed"
>
>
> Some versions of the Windows Intel GPU driver expect the vendor
> PCI capability to be there on the host bridge config space when
> passing through a Intel GPU.
>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> ---
>  hw/pt-graphics.c |   51
> ++++++++++++++++++++++++++++++++++++++++++++++-----
>  1 files changed, 46 insertions(+), 5 deletions(-)
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: 0001-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch
> Type: text/x-patch
> Size: 2551 bytes
> Desc: not available
> URL:
> <http://lists.xensource.com/archives/html/xen-devel/attachments/20120116/fa8c7dac/attachment.bin>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 16 Jan 2012 22:43:54 +0800
> From: Nai Xia <nai.xia@gmail.com>
> To: Grzegorz Milos <Grzegorz.Milos@citrix.com>
> Cc: xen-devel@lists.xensource.com
> Subject: [Xen-devel] Is this a racing bug in page_make_sharable()?
> Message-ID:
> 	<CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Grzegorz,
>
> As I understand, the purpose of the code in page_make_sharable()
> checking the ref count is to ensure that nobody unexpected is working
> on the page, and so we can migrate it to dom_cow, right?
>
> ====
>     /* Check if the ref count is 2. The first from PGT_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;
>     }
> ====
>
> However, it seems to me that this ref check and the following page
> migration is not atomic( although the operations for type_info ref
> check seems good) i.e. it's possible that it passed this ref
> check but just before it goes to dom_cow, someone else gets this page?
> As far as I know, in Linux kernel's similar scenarios, they do
> ref-freezing
> tricks.
>
> And if we don't need to worry about this racing case, then what is
> this check trying to ensure?
>
>
> Thanks,
> Nai
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 233
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:16:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoHy-0006j9-V2; Mon, 16 Jan 2012 15:16:02 +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 1RmoHw-0006ib-Vx
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:16:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326726953!9344999!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 29854 invoked from network); 16 Jan 2012 15:15:54 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 15:15:54 -0000
Received: by wibhj8 with SMTP id hj8so9084196wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 07:15:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=esASqA8m4JkzvJyZNREYXmS9leH+QkokSHxDdTOa5KE=;
	b=vcMDs7Hl0LZIkcWgCaAM1PDO8n/J46UtyAZ4uS3cDTWXGUdCLwzXQIfvVDD+3n1x7A
	M2544LgLTgw2NiO/uTrO9lGMFnzRDt6Sd0T0aduiNotxPdRG5uB9+28Ay/C5OcQBCFLj
	18ilWiRbox5ClPv6EByYXxQln/W5BUkcQ57Dc=
Received: by 10.180.106.202 with SMTP id gw10mr19327468wib.3.1326726953505;
	Mon, 16 Jan 2012 07:15:53 -0800 (PST)
Received: from localhost.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id v28sm22615712wbo.18.2012.01.16.07.15.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 16 Jan 2012 07:15:52 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:15:36 +0100
Message-Id: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.2.5
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 was not reacting when setting xenstore state of a device to
XenbusStateClosing (5). This patch makes qemu react to this state and
close the appropiate device.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 hw/xen_backend.c |   18 ++++++++++++++++--
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 64dc93a..4e4dd77 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -285,11 +285,23 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
  */
 static void xen_be_backend_changed(struct XenDevice *xendev, const char *node)
 {
+    int be_state;
+
     if (node == NULL  ||  strcmp(node, "online") == 0) {
 	if (xenstore_read_be_int(xendev, "online", &xendev->online) == -1)
 	    xendev->online = 0;
     }
 
+    if (node != NULL && strcmp(node, "state") == 0) {
+        if (xenstore_read_be_int(xendev, "state", &be_state) == -1) {
+            xendev->be_state = XenbusStateUnknown;
+        } else if (xendev->be_state == be_state) {
+            return;
+        } else {
+            xendev->be_state = be_state;
+        }
+    }
+
     if (node) {
 	xen_be_printf(xendev, 2, "backend update: %s\n", node);
 	if (xendev->ops->backend_changed)
@@ -461,8 +473,7 @@ static void xen_be_try_connected(struct XenDevice *xendev)
  */
 static void xen_be_disconnect(struct XenDevice *xendev, enum xenbus_state state)
 {
-    if (xendev->be_state != XenbusStateClosing &&
-        xendev->be_state != XenbusStateClosed  &&
+    if (xendev->be_state != XenbusStateClosed  &&
         xendev->ops->disconnect)
 	xendev->ops->disconnect(xendev);
     if (xendev->be_state != state)
@@ -513,6 +524,9 @@ void xen_be_check_state(struct XenDevice *xendev)
 	    xen_be_try_connected(xendev);
 	    rc = -1;
 	    break;
+    case XenbusStateClosing:
+        xen_be_disconnect(xendev, XenbusStateClosed);
+        break;
         case XenbusStateClosed:
             rc = xen_be_try_reset(xendev);
             break;
-- 
1.7.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 Jan 16 15:16:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:16:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoHy-0006j9-V2; Mon, 16 Jan 2012 15:16:02 +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 1RmoHw-0006ib-Vx
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:16:01 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326726953!9344999!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 29854 invoked from network); 16 Jan 2012 15:15:54 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 15:15:54 -0000
Received: by wibhj8 with SMTP id hj8so9084196wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 07:15:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:from:to:cc:subject:date:message-id:x-mailer;
	bh=esASqA8m4JkzvJyZNREYXmS9leH+QkokSHxDdTOa5KE=;
	b=vcMDs7Hl0LZIkcWgCaAM1PDO8n/J46UtyAZ4uS3cDTWXGUdCLwzXQIfvVDD+3n1x7A
	M2544LgLTgw2NiO/uTrO9lGMFnzRDt6Sd0T0aduiNotxPdRG5uB9+28Ay/C5OcQBCFLj
	18ilWiRbox5ClPv6EByYXxQln/W5BUkcQ57Dc=
Received: by 10.180.106.202 with SMTP id gw10mr19327468wib.3.1326726953505;
	Mon, 16 Jan 2012 07:15:53 -0800 (PST)
Received: from localhost.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id v28sm22615712wbo.18.2012.01.16.07.15.51
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 16 Jan 2012 07:15:52 -0800 (PST)
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:15:36 +0100
Message-Id: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
X-Mailer: git-send-email 1.7.2.5
Cc: Roger Pau Monne <roger.pau@entel.upc.edu>
Subject: [Xen-devel] [PATCH] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 was not reacting when setting xenstore state of a device to
XenbusStateClosing (5). This patch makes qemu react to this state and
close the appropiate device.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
---
 hw/xen_backend.c |   18 ++++++++++++++++--
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 64dc93a..4e4dd77 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -285,11 +285,23 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
  */
 static void xen_be_backend_changed(struct XenDevice *xendev, const char *node)
 {
+    int be_state;
+
     if (node == NULL  ||  strcmp(node, "online") == 0) {
 	if (xenstore_read_be_int(xendev, "online", &xendev->online) == -1)
 	    xendev->online = 0;
     }
 
+    if (node != NULL && strcmp(node, "state") == 0) {
+        if (xenstore_read_be_int(xendev, "state", &be_state) == -1) {
+            xendev->be_state = XenbusStateUnknown;
+        } else if (xendev->be_state == be_state) {
+            return;
+        } else {
+            xendev->be_state = be_state;
+        }
+    }
+
     if (node) {
 	xen_be_printf(xendev, 2, "backend update: %s\n", node);
 	if (xendev->ops->backend_changed)
@@ -461,8 +473,7 @@ static void xen_be_try_connected(struct XenDevice *xendev)
  */
 static void xen_be_disconnect(struct XenDevice *xendev, enum xenbus_state state)
 {
-    if (xendev->be_state != XenbusStateClosing &&
-        xendev->be_state != XenbusStateClosed  &&
+    if (xendev->be_state != XenbusStateClosed  &&
         xendev->ops->disconnect)
 	xendev->ops->disconnect(xendev);
     if (xendev->be_state != state)
@@ -513,6 +524,9 @@ void xen_be_check_state(struct XenDevice *xendev)
 	    xen_be_try_connected(xendev);
 	    rc = -1;
 	    break;
+    case XenbusStateClosing:
+        xen_be_disconnect(xendev, XenbusStateClosed);
+        break;
         case XenbusStateClosed:
             rc = xen_be_try_reset(xendev);
             break;
-- 
1.7.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 Jan 16 15:22:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoOQ-00078K-31; Mon, 16 Jan 2012 15:22:42 +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 1RmoOO-00078B-30
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:22:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326727312!50803068!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25469 invoked from network); 16 Jan 2012 15:21:53 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 15:21:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326727358; l=829;
	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=bz4f59HQ+T8c24CaurPpTx+axFA=;
	b=figG4x89KEkjgXOKjMHPoTEFTbFXU0qaZq6X00QJSKxO98R7eoOHdJ5NB04BLbcRsgD
	kEoxbTxQ8OvaFyWlIHmcc3DnoOwRyTAt5CIRYUJybOfjw1Tp1aPnRgUpiQw2FjYAPPn96
	NkCgzp+JmrO8qbop7ja8+Pyu9w13WL4XEk8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (jimi mo40) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L044dbo0GDN9lA ;
	Mon, 16 Jan 2012 16:22:27 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1110618637; Mon, 16 Jan 2012 16:22:27 +0100 (CET)
Date: Mon, 16 Jan 2012 16:22:27 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116152227.GB30697@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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, Jan 11, Andres Lagar-Cavilla wrote:

>  xen/arch/x86/hvm/hvm.c          |   18 +-
>  xen/arch/x86/mm/mem_event.c     |  298 +++++++++++++++++++++++++++++++++------
>  xen/arch/x86/mm/mem_sharing.c   |   30 +--
>  xen/arch/x86/mm/p2m.c           |   81 +++++-----
>  xen/common/memory.c             |    7 +-
>  xen/include/asm-x86/mem_event.h |   22 +-
>  xen/include/asm-x86/p2m.h       |   12 +-
>  xen/include/xen/mm.h            |    2 +
>  xen/include/xen/sched.h         |   22 ++-
>  9 files changed, 359 insertions(+), 133 deletions(-)
> 
> 
> This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
> and our work.
> 
> It combines logic changes to simplify the memory event API, as well as
> leveraging wait queues to deal with extreme conditions in which too many events are
> generated by a guest vcpu.


Signed-off-by: Olaf Hering <olaf@aepfle.de>

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:22:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoOQ-00078K-31; Mon, 16 Jan 2012 15:22:42 +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 1RmoOO-00078B-30
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:22:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326727312!50803068!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25469 invoked from network); 16 Jan 2012 15:21:53 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 15:21:53 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326727358; l=829;
	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=bz4f59HQ+T8c24CaurPpTx+axFA=;
	b=figG4x89KEkjgXOKjMHPoTEFTbFXU0qaZq6X00QJSKxO98R7eoOHdJ5NB04BLbcRsgD
	kEoxbTxQ8OvaFyWlIHmcc3DnoOwRyTAt5CIRYUJybOfjw1Tp1aPnRgUpiQw2FjYAPPn96
	NkCgzp+JmrO8qbop7ja8+Pyu9w13WL4XEk8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (jimi mo40) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L044dbo0GDN9lA ;
	Mon, 16 Jan 2012 16:22:27 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1110618637; Mon, 16 Jan 2012 16:22:27 +0100 (CET)
Date: Mon, 16 Jan 2012 16:22:27 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116152227.GB30697@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a85e7d46401b1d419629.1326306504@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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, Jan 11, Andres Lagar-Cavilla wrote:

>  xen/arch/x86/hvm/hvm.c          |   18 +-
>  xen/arch/x86/mm/mem_event.c     |  298 +++++++++++++++++++++++++++++++++------
>  xen/arch/x86/mm/mem_sharing.c   |   30 +--
>  xen/arch/x86/mm/p2m.c           |   81 +++++-----
>  xen/common/memory.c             |    7 +-
>  xen/include/asm-x86/mem_event.h |   22 +-
>  xen/include/asm-x86/p2m.h       |   12 +-
>  xen/include/xen/mm.h            |    2 +
>  xen/include/xen/sched.h         |   22 ++-
>  9 files changed, 359 insertions(+), 133 deletions(-)
> 
> 
> This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
> and our work.
> 
> It combines logic changes to simplify the memory event API, as well as
> leveraging wait queues to deal with extreme conditions in which too many events are
> generated by a guest vcpu.


Signed-off-by: Olaf Hering <olaf@aepfle.de>

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:34:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:34:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoZx-0007Tv-No; Mon, 16 Jan 2012 15:34:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RmoZv-0007Tq-K1
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:34:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326728067!11222638!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTk3ODY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31967 invoked from network); 16 Jan 2012 15:34:28 -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;
	16 Jan 2012 15:34:28 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 0DAB076C072;
	Mon, 16 Jan 2012 07:34:27 -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=l81spulP9JnsNx274tLPGd
	mKSNTqqoPYzcKJ3RJm1sc4aRzB36YhtOfHzXwWbuY1FjNcnOjlxzyGUvN9vQeTNc
	lr6HuBvaSuBDvjpf7MiLbR7SmI2vsk5RE86ybSU7tBMYGdhrwr7om200RqnD5aKN
	1RyNG70p9w0m1tDnCX+18=
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=G1E5iWkvk1Pm
	l1/ShmI93+jrOqw=; b=gkmI6PBJjzXkFIhaolJ85kYUMpEMW2NfLckNewi+a0rr
	4g50mq5WCaE5SXkLgpSazv7GSSvBFJ9Y0HPBJ0zaQQfhYewHDTzC3xSCpjTHKzkO
	D8sPjROUTtFaDi8HXVjt9orxYWxfE7IicU5sTG/sRpQKR6IjgcVrh7uHKj9rjmY=
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-a15.g.dreamhost.com (Postfix) with ESMTPSA id F2F9E76C06F; 
	Mon, 16 Jan 2012 07:34:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 28c68de1ea253d7dbe3402f9496aef635055e0f4
Message-Id: <28c68de1ea253d7dbe34.1326728344@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 16 Jan 2012 10:39:04 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: 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          |   16 +-
 xen/arch/x86/mm/mem_event.c     |  296 +++++++++++++++++++++++++++++++++------
 xen/arch/x86/mm/mem_sharing.c   |   30 +--
 xen/arch/x86/mm/p2m.c           |   78 +++++-----
 xen/include/asm-x86/mem_event.h |   22 +-
 xen/include/asm-x86/p2m.h       |    9 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |   22 ++-
 8 files changed, 347 insertions(+), 128 deletions(-)


This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
and our work.

It combines logic changes to simplify the memory event API, as well as
leveraging wait queues to deal with extreme conditions in which too many events are
generated by a guest vcpu.

In order to generate a new event, a slot in the ring is claimed. If a guest vcpu
is generating the event and there is no space, it is put on a wait queue. If a
foreign vcpu is generating the event and there is no space, the vcpu is expected
to retry its operation. If an error happens later, the function returns the
claimed slot via a cancel operation.

Thus, the API has only four calls: claim slot, cancel claimed slot, put request
in the ring, consume the response.

With all these mechanisms, no guest events are lost.
Our testing includes 1. ballooning down 512 MiBs; 2. using mem access n2rwx, 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.

For full disclosure, here is Olaf's log of changes:

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()

This version also includes Olaf's latest (Jan 16th 2012) comments.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Olaf hering <olaf@aepfle.de>

diff -r c0bb1c65797b -r 28c68de1ea25 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4198,15 +4198,21 @@ 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 == -ENOSYS )
+    {
+        /* If there was no ring to handle the event, then
+         * simple continue executing normally. */
+        return 1;
+    }
+    else if ( rc < 0 )
         return rc;
-    
+
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
-    
+
     if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
     {
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
diff -r c0bb1c65797b -r 28c68de1ea25 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;
@@ -93,6 +95,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,
@@ -110,8 +115,11 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    /* Save the pause flag for this particular ring. */
+    med->pause_flag = pause_flag;
+
+    /* Initialize the last-chance wait queue. */
+    init_waitqueue_head(&med->wq);
 
     return 0;
 
@@ -125,48 +133,216 @@ static int mem_event_enable(
     return rc;
 }
 
-static int mem_event_disable(struct mem_event_domain *med)
+static unsigned int mem_event_ring_available(struct mem_event_domain *med)
 {
-    unmap_domain_page(med->ring_page);
-    med->ring_page = NULL;
+    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
+    avail_req -= med->target_producers;
+    avail_req -= med->foreign_producers;
 
-    unmap_domain_page(med->shared_page);
-    med->shared_page = NULL;
+    BUG_ON(avail_req < 0);
+
+    return avail_req;
+}
+
+/*
+ * mem_event_wake_blocked() will wakeup vcpus waiting for room in the
+ * ring. These vCPUs were paused on their way out after placing an event,
+ * but need to be resumed where the ring is capable of processing at least
+ * one event from them.
+ */
+static void mem_event_wake_blocked(struct domain *d, struct mem_event_domain *med)
+{
+    struct vcpu *v;
+    int online = d->max_vcpus;
+    unsigned int avail_req = mem_event_ring_available(med);
+
+    if ( avail_req == 0 || med->blocked == 0 )
+        return;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit).
+     * See comment below in mem_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(med->pause_flag, &v->pause_flags) )
+            online--;
+
+    ASSERT(online == (d->max_vcpus - med->blocked));
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        int i, j, k;
+
+        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v )
+                continue;
+
+            if ( !(med->blocked) || online >= avail_req )
+               break;
+
+            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                med->blocked--;
+                med->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+/*
+ * In the event that a vCPU attempted to place an event in the ring and
+ * was unable to do so, it is queued on a wait queue.  These are woken as
+ * needed, and take precedence over the blocked vCPUs.
+ */
+static void mem_event_wake_queued(struct domain *d, struct mem_event_domain *med)
+{
+    unsigned int avail_req = mem_event_ring_available(med);
+
+    if ( avail_req > 0 )
+        wake_up_nr(&med->wq, avail_req);
+}
+
+/*
+ * mem_event_wake() will wakeup all vcpus waiting for the ring to
+ * become available.  If we have queued vCPUs, they get top priority. We
+ * are guaranteed that they will go through code paths that will eventually
+ * call mem_event_wake() again, ensuring that any blocked vCPUs will get
+ * unpaused once all the queued vCPUs have made it through.
+ */
+void mem_event_wake(struct domain *d, struct mem_event_domain *med)
+{
+    if (!list_empty(&med->wq.list))
+        mem_event_wake_queued(d, med);
+    else
+        mem_event_wake_blocked(d, med);
+}
+
+static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
+{
+    if ( med->ring_page )
+    {
+        struct vcpu *v;
+
+        mem_event_ring_lock(med);
+
+        if ( !list_empty(&med->wq.list) )
+        {
+            mem_event_ring_unlock(med);
+            return -EBUSY;
+        }
+
+        unmap_domain_page(med->ring_page);
+        med->ring_page = NULL;
+
+        unmap_domain_page(med->shared_page);
+        med->shared_page = NULL;
+
+        /* Unblock all vCPUs */
+        for_each_vcpu ( d, v )
+        {
+            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                med->blocked--;
+            }
+        }
+
+        mem_event_ring_unlock(med);
+    }
 
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static inline void mem_event_release_slot(struct domain *d,
+                                          struct mem_event_domain *med)
+{
+    /* Update the accounting */
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
+
+    /* Kick any waiters */
+    mem_event_wake(d, med);
+}
+
+/*
+ * mem_event_mark_and_pause() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
+{
+    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        med->blocked++;
+    }
+}
+
+/*
+ * This must be preceded by a call to claim_slot(), and is guaranteed to
+ * succeed.  As a side-effect however, the vCPU may be paused if the ring is
+ * overly full and its continued execution would cause stalling and excessive
+ * waiting.  The vCPU will be automatically unpaused when the ring clears.
+ */
+void mem_event_put_request(struct domain *d,
+                           struct mem_event_domain *med,
+                           mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req;
+    unsigned int avail_req;
     RING_IDX req_prod;
 
-    mem_event_ring_lock(med);
-
-    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) );
     }
 
+    mem_event_ring_lock(med);
+
+    /* Due to the reservations, this step must succeed. */
+    front_ring = &med->front_ring;
+    free_req = RING_FREE_REQUESTS(front_ring);
+    ASSERT(free_req > 0);
+
     /* Copy request */
+    req_prod = front_ring->req_prod_pvt;
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
+    /* We've actually *used* our reservation, so release the slot. */
+    mem_event_release_slot(d, med);
+
+    /* Give this vCPU a black eye if necessary, on the way out.
+     * See the comments above wake_blocked() for more information
+     * on how this mechanism works to avoid waiting. */
+    avail_req = mem_event_ring_available(med);
+    if( current->domain == d && avail_req < d->max_vcpus )
+        mem_event_mark_and_pause(current, med);
+
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
 }
 
-int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med, mem_event_response_t *rsp)
 {
     mem_event_front_ring_t *front_ring;
     RING_IDX rsp_cons;
@@ -190,57 +366,81 @@ int mem_event_get_response(struct mem_ev
     front_ring->rsp_cons = rsp_cons;
     front_ring->sring->rsp_event = rsp_cons + 1;
 
+    /* Kick any waiters -- since we've just consumed an event,
+     * there may be additional space available in the ring. */
+    mem_event_wake(d, med);
+
     mem_event_ring_unlock(med);
 
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
-{
-    struct vcpu *v;
-
-    for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
-            vcpu_wake(v);
-}
-
-void mem_event_mark_and_pause(struct vcpu *v)
-{
-    set_bit(_VPF_mem_event, &v->pause_flags);
-    vcpu_sleep_nosync(v);
-}
-
-void mem_event_put_req_producers(struct mem_event_domain *med)
+void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    mem_event_release_slot(d, med);
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+static int mem_event_grab_slot(struct mem_event_domain *med, int foreign)
 {
-    struct vcpu *curr = current;
-    int free_requests;
-    int ring_full = 1;
+    unsigned int avail_req;
 
     if ( !med->ring_page )
-        return -1;
+        return -ENOSYS;
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    avail_req = mem_event_ring_available(med);
+    if ( avail_req == 0 )
     {
-        med->req_producers++;
-        ring_full = 0;
+        mem_event_ring_unlock(med);
+        return -EBUSY;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
+    if ( !foreign )
+        med->target_producers++;
+    else
+        med->foreign_producers++;
 
     mem_event_ring_unlock(med);
 
-    return ring_full;
+    return 0;
+}
+
+/* Simple try_grab wrapper for use in the wait_event() macro. */
+static int mem_event_wait_try_grab(struct mem_event_domain *med, int *rc)
+{
+    *rc = mem_event_grab_slot(med, 0);
+    return *rc;
+}
+
+/* Call mem_event_grab_slot() until the ring doesn't exist, or is available. */
+static int mem_event_wait_slot(struct mem_event_domain *med)
+{
+    int rc = -EBUSY;
+    wait_event(med->wq, mem_event_wait_try_grab(med, &rc) != -EBUSY);
+    return rc;
+}
+
+/*
+ * Determines whether or not the current vCPU belongs to the target domain,
+ * and calls the appropriate wait function.  If it is a guest vCPU, then we
+ * use mem_event_wait_slot() to reserve a slot.  As long as there is a ring,
+ * this function will always return 0 for a guest.  For a non-guest, we check
+ * for space and return -EBUSY if the ring is not available.
+ *
+ * Return codes: -ENOSYS: the ring is not yet configured
+ *               -EBUSY: the ring is busy
+ *               0: a spot has been reserved
+ *
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
+{
+    if ( current->domain == d )
+        return mem_event_wait_slot(med);
+    else
+        return mem_event_grab_slot(med, 1);
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */
@@ -316,14 +516,14 @@ 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;
 
         case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
@@ -355,14 +555,14 @@ 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;
 
         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 c0bb1c65797b -r 28c68de1ea25 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,21 @@ 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;
     }
 
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+    {
+        return;
+    }
+
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     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);
-
-    return page;
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -301,7 +294,7 @@ int mem_sharing_sharing_resume(struct do
     mem_event_response_t rsp;
 
     /* Get all requests off the ring */
-    while ( mem_event_get_response(&d->mem_event->share, &rsp) )
+    while ( mem_event_get_response(d, &d->mem_event->share, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -658,13 +651,14 @@ 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
          * gfn_info to relevant list */
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
+        mem_sharing_notify_helper(d, gfn);
         shr_unlock();
         return -ENOMEM;
     }
diff -r c0bb1c65797b -r 28c68de1ea25 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -861,20 +861,23 @@ 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;
 
-    /* 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;
+    /* We allow no ring in this unique case, because it won't affect
+     * correctness of the guest execution at this point.  If this is the only
+     * page that happens to be paged-out, we'll be okay..  but it's likely the
+     * guest will crash shortly anyways. */
+    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    if ( rc < 0 )
+        return;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    /* Send release notification to pager */
+    memset(&req, 0, sizeof(req));
+    req.type = MEM_EVENT_TYPE_PAGING;
+    req.gfn = gfn;
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
+
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -898,7 +901,7 @@ void p2m_mem_paging_drop_page(struct dom
  * already sent to the pager. In this case the caller has to try again until the
  * gfn is fully paged in again.
  */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
@@ -907,9 +910,17 @@ 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 */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
-        return;
+    /* We're paging. There should be a ring */
+    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    if ( rc == -ENOSYS )
+    {
+        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
+                             "in place\n", d->domain_id, gfn);
+        domain_crash(d);
+        return 0;
+    }
+    else if ( rc < 0 )
+        return rc;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -929,7 +940,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_unlock(p2m);
 
     /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain == d )
+    if ( p2m_is_paging(p2mt) && v->domain == d )
     {
         vcpu_pause_nosync(v);
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
@@ -938,8 +949,8 @@ 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;
+        mem_event_cancel_slot(d, &d->mem_event->paging);
+        return 0;
     }
 
     /* Send request to pager */
@@ -948,6 +959,7 @@ void p2m_mem_paging_populate(struct doma
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->paging, &req);
+    return 0;
 }
 
 /**
@@ -1065,7 +1077,7 @@ void p2m_mem_paging_resume(struct domain
     mfn_t mfn;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(&d->mem_event->paging, &rsp) )
+    while( mem_event_get_response(d, &d->mem_event->paging, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -1090,9 +1102,6 @@ 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);
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1103,7 +1112,6 @@ bool_t p2m_mem_access_check(unsigned lon
     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;
@@ -1126,17 +1134,16 @@ 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);
-    if ( res < 0 ) 
+    if ( mem_event_claim_slot(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);
+            return 0;
         }
         else
         {
@@ -1149,11 +1156,7 @@ bool_t p2m_mem_access_check(unsigned lon
             }
             return 1;
         }
-
-        return 0;
     }
-    else if ( res > 0 )
-        return 0;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1188,7 +1191,7 @@ void p2m_mem_access_resume(struct domain
     mem_event_response_t rsp;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(&d->mem_event->access, &rsp) )
+    while( mem_event_get_response(d, &d->mem_event->access, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -1196,13 +1199,8 @@ 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);
 }
 
-
 /* Set access type for a region of pfns.
  * If start_pfn == -1ul, sets the default access type */
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn, 
diff -r c0bb1c65797b -r 28c68de1ea25 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,18 +24,24 @@
 #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_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);
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
+ * available space. For success or -EBUSY, the vCPU may be left blocked
+ * temporarily to ensure that the ring does not lose future events.  In
+ * general, you must follow a claim_slot() call with either put_request() or
+ * cancel_slot(), both of which are guaranteed to succeed. */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+
+void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med);
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                            mem_event_request_t *req);
+
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
+                           mem_event_response_t *rsp);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
 
-
 #endif /* __MEM_EVENT_H__ */
 
 
diff -r c0bb1c65797b -r 28c68de1ea25 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -480,16 +480,15 @@ int p2m_mem_paging_evict(struct domain *
 /* Tell xenpaging to drop a paged out frame */
 void 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);
+int 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, uint64_t buffer);
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
-{ }
-static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
-{ }
+#define p2m_mem_paging_drop_page(d, g)  ((void)0)
+static inline int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+{ return 0; }
 #endif
 
 #ifdef __x86_64__
diff -r c0bb1c65797b -r 28c68de1ea25 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 c0bb1c65797b -r 28c68de1ea25 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,9 @@ 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 target_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +195,14 @@ 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;
+    /* the number of vCPUs blocked */
+    unsigned int blocked;
+    /* The last vcpu woken up */
+    unsigned int last_vcpu_wake_up;
 };
 
 struct mem_event_per_domain
@@ -615,9 +626,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 Jan 16 15:34:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:34:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmoZx-0007Tv-No; Mon, 16 Jan 2012 15:34:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RmoZv-0007Tq-K1
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:34:36 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326728067!11222638!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTk3ODY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31967 invoked from network); 16 Jan 2012 15:34:28 -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;
	16 Jan 2012 15:34:28 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 0DAB076C072;
	Mon, 16 Jan 2012 07:34:27 -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=l81spulP9JnsNx274tLPGd
	mKSNTqqoPYzcKJ3RJm1sc4aRzB36YhtOfHzXwWbuY1FjNcnOjlxzyGUvN9vQeTNc
	lr6HuBvaSuBDvjpf7MiLbR7SmI2vsk5RE86ybSU7tBMYGdhrwr7om200RqnD5aKN
	1RyNG70p9w0m1tDnCX+18=
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=G1E5iWkvk1Pm
	l1/ShmI93+jrOqw=; b=gkmI6PBJjzXkFIhaolJ85kYUMpEMW2NfLckNewi+a0rr
	4g50mq5WCaE5SXkLgpSazv7GSSvBFJ9Y0HPBJ0zaQQfhYewHDTzC3xSCpjTHKzkO
	D8sPjROUTtFaDi8HXVjt9orxYWxfE7IicU5sTG/sRpQKR6IjgcVrh7uHKj9rjmY=
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-a15.g.dreamhost.com (Postfix) with ESMTPSA id F2F9E76C06F; 
	Mon, 16 Jan 2012 07:34:25 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 28c68de1ea253d7dbe3402f9496aef635055e0f4
Message-Id: <28c68de1ea253d7dbe34.1326728344@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Mon, 16 Jan 2012 10:39:04 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] x86/mm: 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          |   16 +-
 xen/arch/x86/mm/mem_event.c     |  296 +++++++++++++++++++++++++++++++++------
 xen/arch/x86/mm/mem_sharing.c   |   30 +--
 xen/arch/x86/mm/p2m.c           |   78 +++++-----
 xen/include/asm-x86/mem_event.h |   22 +-
 xen/include/asm-x86/p2m.h       |    9 +-
 xen/include/xen/mm.h            |    2 +
 xen/include/xen/sched.h         |   22 ++-
 8 files changed, 347 insertions(+), 128 deletions(-)


This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
and our work.

It combines logic changes to simplify the memory event API, as well as
leveraging wait queues to deal with extreme conditions in which too many events are
generated by a guest vcpu.

In order to generate a new event, a slot in the ring is claimed. If a guest vcpu
is generating the event and there is no space, it is put on a wait queue. If a
foreign vcpu is generating the event and there is no space, the vcpu is expected
to retry its operation. If an error happens later, the function returns the
claimed slot via a cancel operation.

Thus, the API has only four calls: claim slot, cancel claimed slot, put request
in the ring, consume the response.

With all these mechanisms, no guest events are lost.
Our testing includes 1. ballooning down 512 MiBs; 2. using mem access n2rwx, 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.

For full disclosure, here is Olaf's log of changes:

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()

This version also includes Olaf's latest (Jan 16th 2012) comments.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Olaf hering <olaf@aepfle.de>

diff -r c0bb1c65797b -r 28c68de1ea25 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4198,15 +4198,21 @@ 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 == -ENOSYS )
+    {
+        /* If there was no ring to handle the event, then
+         * simple continue executing normally. */
+        return 1;
+    }
+    else if ( rc < 0 )
         return rc;
-    
+
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
     req.reason = reason;
-    
+
     if ( (p & HVMPME_MODE_MASK) == HVMPME_mode_sync ) 
     {
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;    
diff -r c0bb1c65797b -r 28c68de1ea25 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;
@@ -93,6 +95,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,
@@ -110,8 +115,11 @@ static int mem_event_enable(
 
     mem_event_ring_lock_init(med);
 
-    /* Wake any VCPUs paused for memory events */
-    mem_event_unpause_vcpus(d);
+    /* Save the pause flag for this particular ring. */
+    med->pause_flag = pause_flag;
+
+    /* Initialize the last-chance wait queue. */
+    init_waitqueue_head(&med->wq);
 
     return 0;
 
@@ -125,48 +133,216 @@ static int mem_event_enable(
     return rc;
 }
 
-static int mem_event_disable(struct mem_event_domain *med)
+static unsigned int mem_event_ring_available(struct mem_event_domain *med)
 {
-    unmap_domain_page(med->ring_page);
-    med->ring_page = NULL;
+    int avail_req = RING_FREE_REQUESTS(&med->front_ring);
+    avail_req -= med->target_producers;
+    avail_req -= med->foreign_producers;
 
-    unmap_domain_page(med->shared_page);
-    med->shared_page = NULL;
+    BUG_ON(avail_req < 0);
+
+    return avail_req;
+}
+
+/*
+ * mem_event_wake_blocked() will wakeup vcpus waiting for room in the
+ * ring. These vCPUs were paused on their way out after placing an event,
+ * but need to be resumed where the ring is capable of processing at least
+ * one event from them.
+ */
+static void mem_event_wake_blocked(struct domain *d, struct mem_event_domain *med)
+{
+    struct vcpu *v;
+    int online = d->max_vcpus;
+    unsigned int avail_req = mem_event_ring_available(med);
+
+    if ( avail_req == 0 || med->blocked == 0 )
+        return;
+
+    /*
+     * We ensure that we only have vCPUs online if there are enough free slots
+     * for their memory events to be processed.  This will ensure that no
+     * memory events are lost (due to the fact that certain types of events
+     * cannot be replayed, we need to ensure that there is space in the ring
+     * for when they are hit).
+     * See comment below in mem_event_put_request().
+     */
+    for_each_vcpu ( d, v )
+        if ( test_bit(med->pause_flag, &v->pause_flags) )
+            online--;
+
+    ASSERT(online == (d->max_vcpus - med->blocked));
+
+    /* We remember which vcpu last woke up to avoid scanning always linearly
+     * from zero and starving higher-numbered vcpus under high load */
+    if ( d->vcpu )
+    {
+        int i, j, k;
+
+        for (i = med->last_vcpu_wake_up + 1, j = 0; j < d->max_vcpus; i++, j++)
+        {
+            k = i % d->max_vcpus;
+            v = d->vcpu[k];
+            if ( !v )
+                continue;
+
+            if ( !(med->blocked) || online >= avail_req )
+               break;
+
+            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                online++;
+                med->blocked--;
+                med->last_vcpu_wake_up = k;
+            }
+        }
+    }
+}
+
+/*
+ * In the event that a vCPU attempted to place an event in the ring and
+ * was unable to do so, it is queued on a wait queue.  These are woken as
+ * needed, and take precedence over the blocked vCPUs.
+ */
+static void mem_event_wake_queued(struct domain *d, struct mem_event_domain *med)
+{
+    unsigned int avail_req = mem_event_ring_available(med);
+
+    if ( avail_req > 0 )
+        wake_up_nr(&med->wq, avail_req);
+}
+
+/*
+ * mem_event_wake() will wakeup all vcpus waiting for the ring to
+ * become available.  If we have queued vCPUs, they get top priority. We
+ * are guaranteed that they will go through code paths that will eventually
+ * call mem_event_wake() again, ensuring that any blocked vCPUs will get
+ * unpaused once all the queued vCPUs have made it through.
+ */
+void mem_event_wake(struct domain *d, struct mem_event_domain *med)
+{
+    if (!list_empty(&med->wq.list))
+        mem_event_wake_queued(d, med);
+    else
+        mem_event_wake_blocked(d, med);
+}
+
+static int mem_event_disable(struct domain *d, struct mem_event_domain *med)
+{
+    if ( med->ring_page )
+    {
+        struct vcpu *v;
+
+        mem_event_ring_lock(med);
+
+        if ( !list_empty(&med->wq.list) )
+        {
+            mem_event_ring_unlock(med);
+            return -EBUSY;
+        }
+
+        unmap_domain_page(med->ring_page);
+        med->ring_page = NULL;
+
+        unmap_domain_page(med->shared_page);
+        med->shared_page = NULL;
+
+        /* Unblock all vCPUs */
+        for_each_vcpu ( d, v )
+        {
+            if ( test_and_clear_bit(med->pause_flag, &v->pause_flags) )
+            {
+                vcpu_unpause(v);
+                med->blocked--;
+            }
+        }
+
+        mem_event_ring_unlock(med);
+    }
 
     return 0;
 }
 
-void mem_event_put_request(struct domain *d, struct mem_event_domain *med, mem_event_request_t *req)
+static inline void mem_event_release_slot(struct domain *d,
+                                          struct mem_event_domain *med)
+{
+    /* Update the accounting */
+    if ( current->domain == d )
+        med->target_producers--;
+    else
+        med->foreign_producers--;
+
+    /* Kick any waiters */
+    mem_event_wake(d, med);
+}
+
+/*
+ * mem_event_mark_and_pause() tags vcpu and put it to sleep.
+ * The vcpu will resume execution in mem_event_wake_waiters().
+ */
+void mem_event_mark_and_pause(struct vcpu *v, struct mem_event_domain *med)
+{
+    if ( !test_and_set_bit(med->pause_flag, &v->pause_flags) )
+    {
+        vcpu_pause_nosync(v);
+        med->blocked++;
+    }
+}
+
+/*
+ * This must be preceded by a call to claim_slot(), and is guaranteed to
+ * succeed.  As a side-effect however, the vCPU may be paused if the ring is
+ * overly full and its continued execution would cause stalling and excessive
+ * waiting.  The vCPU will be automatically unpaused when the ring clears.
+ */
+void mem_event_put_request(struct domain *d,
+                           struct mem_event_domain *med,
+                           mem_event_request_t *req)
 {
     mem_event_front_ring_t *front_ring;
+    int free_req;
+    unsigned int avail_req;
     RING_IDX req_prod;
 
-    mem_event_ring_lock(med);
-
-    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) );
     }
 
+    mem_event_ring_lock(med);
+
+    /* Due to the reservations, this step must succeed. */
+    front_ring = &med->front_ring;
+    free_req = RING_FREE_REQUESTS(front_ring);
+    ASSERT(free_req > 0);
+
     /* Copy request */
+    req_prod = front_ring->req_prod_pvt;
     memcpy(RING_GET_REQUEST(front_ring, req_prod), req, sizeof(*req));
     req_prod++;
 
     /* Update ring */
-    med->req_producers--;
     front_ring->req_prod_pvt = req_prod;
     RING_PUSH_REQUESTS(front_ring);
 
+    /* We've actually *used* our reservation, so release the slot. */
+    mem_event_release_slot(d, med);
+
+    /* Give this vCPU a black eye if necessary, on the way out.
+     * See the comments above wake_blocked() for more information
+     * on how this mechanism works to avoid waiting. */
+    avail_req = mem_event_ring_available(med);
+    if( current->domain == d && avail_req < d->max_vcpus )
+        mem_event_mark_and_pause(current, med);
+
     mem_event_ring_unlock(med);
 
     notify_via_xen_event_channel(d, med->xen_port);
 }
 
-int mem_event_get_response(struct mem_event_domain *med, mem_event_response_t *rsp)
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med, mem_event_response_t *rsp)
 {
     mem_event_front_ring_t *front_ring;
     RING_IDX rsp_cons;
@@ -190,57 +366,81 @@ int mem_event_get_response(struct mem_ev
     front_ring->rsp_cons = rsp_cons;
     front_ring->sring->rsp_event = rsp_cons + 1;
 
+    /* Kick any waiters -- since we've just consumed an event,
+     * there may be additional space available in the ring. */
+    mem_event_wake(d, med);
+
     mem_event_ring_unlock(med);
 
     return 1;
 }
 
-void mem_event_unpause_vcpus(struct domain *d)
-{
-    struct vcpu *v;
-
-    for_each_vcpu ( d, v )
-        if ( test_and_clear_bit(_VPF_mem_event, &v->pause_flags) )
-            vcpu_wake(v);
-}
-
-void mem_event_mark_and_pause(struct vcpu *v)
-{
-    set_bit(_VPF_mem_event, &v->pause_flags);
-    vcpu_sleep_nosync(v);
-}
-
-void mem_event_put_req_producers(struct mem_event_domain *med)
+void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med)
 {
     mem_event_ring_lock(med);
-    med->req_producers--;
+    mem_event_release_slot(d, med);
     mem_event_ring_unlock(med);
 }
 
-int mem_event_check_ring(struct domain *d, struct mem_event_domain *med)
+static int mem_event_grab_slot(struct mem_event_domain *med, int foreign)
 {
-    struct vcpu *curr = current;
-    int free_requests;
-    int ring_full = 1;
+    unsigned int avail_req;
 
     if ( !med->ring_page )
-        return -1;
+        return -ENOSYS;
 
     mem_event_ring_lock(med);
 
-    free_requests = RING_FREE_REQUESTS(&med->front_ring);
-    if ( med->req_producers < free_requests )
+    avail_req = mem_event_ring_available(med);
+    if ( avail_req == 0 )
     {
-        med->req_producers++;
-        ring_full = 0;
+        mem_event_ring_unlock(med);
+        return -EBUSY;
     }
 
-    if ( ring_full && (curr->domain == d) )
-        mem_event_mark_and_pause(curr);
+    if ( !foreign )
+        med->target_producers++;
+    else
+        med->foreign_producers++;
 
     mem_event_ring_unlock(med);
 
-    return ring_full;
+    return 0;
+}
+
+/* Simple try_grab wrapper for use in the wait_event() macro. */
+static int mem_event_wait_try_grab(struct mem_event_domain *med, int *rc)
+{
+    *rc = mem_event_grab_slot(med, 0);
+    return *rc;
+}
+
+/* Call mem_event_grab_slot() until the ring doesn't exist, or is available. */
+static int mem_event_wait_slot(struct mem_event_domain *med)
+{
+    int rc = -EBUSY;
+    wait_event(med->wq, mem_event_wait_try_grab(med, &rc) != -EBUSY);
+    return rc;
+}
+
+/*
+ * Determines whether or not the current vCPU belongs to the target domain,
+ * and calls the appropriate wait function.  If it is a guest vCPU, then we
+ * use mem_event_wait_slot() to reserve a slot.  As long as there is a ring,
+ * this function will always return 0 for a guest.  For a non-guest, we check
+ * for space and return -EBUSY if the ring is not available.
+ *
+ * Return codes: -ENOSYS: the ring is not yet configured
+ *               -EBUSY: the ring is busy
+ *               0: a spot has been reserved
+ *
+ */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med)
+{
+    if ( current->domain == d )
+        return mem_event_wait_slot(med);
+    else
+        return mem_event_grab_slot(med, 1);
 }
 
 /* Registered with Xen-bound event channel for incoming notifications. */
@@ -316,14 +516,14 @@ 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;
 
         case XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE:
         {
             if ( med->ring_page )
-                rc = mem_event_disable(med);
+                rc = mem_event_disable(d, med);
         }
         break;
 
@@ -355,14 +555,14 @@ 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;
 
         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 c0bb1c65797b -r 28c68de1ea25 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,21 @@ 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;
     }
 
+    if (mem_event_claim_slot(d, &d->mem_event->share) < 0)
+    {
+        return;
+    }
+
+    req.flags = MEM_EVENT_FLAG_VCPU_PAUSED;
     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);
-
-    return page;
 }
 
 unsigned int mem_sharing_get_nr_saved_mfns(void)
@@ -301,7 +294,7 @@ int mem_sharing_sharing_resume(struct do
     mem_event_response_t rsp;
 
     /* Get all requests off the ring */
-    while ( mem_event_get_response(&d->mem_event->share, &rsp) )
+    while ( mem_event_get_response(d, &d->mem_event->share, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -658,13 +651,14 @@ 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
          * gfn_info to relevant list */
         list_add(&gfn_info->list, &hash_entry->gfns);
         put_gfn(d, gfn);
+        mem_sharing_notify_helper(d, gfn);
         shr_unlock();
         return -ENOMEM;
     }
diff -r c0bb1c65797b -r 28c68de1ea25 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -861,20 +861,23 @@ 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;
 
-    /* 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;
+    /* We allow no ring in this unique case, because it won't affect
+     * correctness of the guest execution at this point.  If this is the only
+     * page that happens to be paged-out, we'll be okay..  but it's likely the
+     * guest will crash shortly anyways. */
+    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    if ( rc < 0 )
+        return;
 
-        mem_event_put_request(d, &d->mem_event->paging, &req);
-    }
+    /* Send release notification to pager */
+    memset(&req, 0, sizeof(req));
+    req.type = MEM_EVENT_TYPE_PAGING;
+    req.gfn = gfn;
+    req.flags = MEM_EVENT_FLAG_DROP_PAGE;
+
+    mem_event_put_request(d, &d->mem_event->paging, &req);
 }
 
 /**
@@ -898,7 +901,7 @@ void p2m_mem_paging_drop_page(struct dom
  * already sent to the pager. In this case the caller has to try again until the
  * gfn is fully paged in again.
  */
-void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
 {
     struct vcpu *v = current;
     mem_event_request_t req;
@@ -907,9 +910,17 @@ 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 */
-    if ( mem_event_check_ring(d, &d->mem_event->paging) )
-        return;
+    /* We're paging. There should be a ring */
+    int rc = mem_event_claim_slot(d, &d->mem_event->paging);
+    if ( rc == -ENOSYS )
+    {
+        gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
+                             "in place\n", d->domain_id, gfn);
+        domain_crash(d);
+        return 0;
+    }
+    else if ( rc < 0 )
+        return rc;
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_PAGING;
@@ -929,7 +940,7 @@ void p2m_mem_paging_populate(struct doma
     p2m_unlock(p2m);
 
     /* Pause domain if request came from guest and gfn has paging type */
-    if (  p2m_is_paging(p2mt) && v->domain == d )
+    if ( p2m_is_paging(p2mt) && v->domain == d )
     {
         vcpu_pause_nosync(v);
         req.flags |= MEM_EVENT_FLAG_VCPU_PAUSED;
@@ -938,8 +949,8 @@ 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;
+        mem_event_cancel_slot(d, &d->mem_event->paging);
+        return 0;
     }
 
     /* Send request to pager */
@@ -948,6 +959,7 @@ void p2m_mem_paging_populate(struct doma
     req.vcpu_id = v->vcpu_id;
 
     mem_event_put_request(d, &d->mem_event->paging, &req);
+    return 0;
 }
 
 /**
@@ -1065,7 +1077,7 @@ void p2m_mem_paging_resume(struct domain
     mfn_t mfn;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(&d->mem_event->paging, &rsp) )
+    while( mem_event_get_response(d, &d->mem_event->paging, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -1090,9 +1102,6 @@ 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);
 }
 
 bool_t p2m_mem_access_check(unsigned long gpa, bool_t gla_valid, unsigned long gla, 
@@ -1103,7 +1112,6 @@ bool_t p2m_mem_access_check(unsigned lon
     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;
@@ -1126,17 +1134,16 @@ 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);
-    if ( res < 0 ) 
+    if ( mem_event_claim_slot(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);
+            return 0;
         }
         else
         {
@@ -1149,11 +1156,7 @@ bool_t p2m_mem_access_check(unsigned lon
             }
             return 1;
         }
-
-        return 0;
     }
-    else if ( res > 0 )
-        return 0;  /* No space in buffer; VCPU paused */
 
     memset(&req, 0, sizeof(req));
     req.type = MEM_EVENT_TYPE_ACCESS;
@@ -1188,7 +1191,7 @@ void p2m_mem_access_resume(struct domain
     mem_event_response_t rsp;
 
     /* Pull all responses off the ring */
-    while( mem_event_get_response(&d->mem_event->access, &rsp) )
+    while( mem_event_get_response(d, &d->mem_event->access, &rsp) )
     {
         if ( rsp.flags & MEM_EVENT_FLAG_DUMMY )
             continue;
@@ -1196,13 +1199,8 @@ 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);
 }
 
-
 /* Set access type for a region of pfns.
  * If start_pfn == -1ul, sets the default access type */
 int p2m_set_mem_access(struct domain *d, unsigned long start_pfn, 
diff -r c0bb1c65797b -r 28c68de1ea25 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -24,18 +24,24 @@
 #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_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);
+/* Returns 0 on success, -ENOSYS if there is no ring, -EBUSY if there is no
+ * available space. For success or -EBUSY, the vCPU may be left blocked
+ * temporarily to ensure that the ring does not lose future events.  In
+ * general, you must follow a claim_slot() call with either put_request() or
+ * cancel_slot(), both of which are guaranteed to succeed. */
+int mem_event_claim_slot(struct domain *d, struct mem_event_domain *med);
+
+void mem_event_cancel_slot(struct domain *d, struct mem_event_domain *med);
+
+void mem_event_put_request(struct domain *d, struct mem_event_domain *med,
+                            mem_event_request_t *req);
+
+int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
+                           mem_event_response_t *rsp);
 
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
 
-
 #endif /* __MEM_EVENT_H__ */
 
 
diff -r c0bb1c65797b -r 28c68de1ea25 xen/include/asm-x86/p2m.h
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -480,16 +480,15 @@ int p2m_mem_paging_evict(struct domain *
 /* Tell xenpaging to drop a paged out frame */
 void 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);
+int 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, uint64_t buffer);
 /* Resume normal operation (in case a domain was paused) */
 void p2m_mem_paging_resume(struct domain *d);
 #else
-static inline void p2m_mem_paging_drop_page(struct domain *d, unsigned long gfn)
-{ }
-static inline void p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
-{ }
+#define p2m_mem_paging_drop_page(d, g)  ((void)0)
+static inline int p2m_mem_paging_populate(struct domain *d, unsigned long gfn)
+{ return 0; }
 #endif
 
 #ifdef __x86_64__
diff -r c0bb1c65797b -r 28c68de1ea25 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 c0bb1c65797b -r 28c68de1ea25 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,9 @@ 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 target_producers;
     /* shared page */
     mem_event_shared_page_t *shared_page;
     /* shared ring page */
@@ -192,6 +195,14 @@ 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;
+    /* the number of vCPUs blocked */
+    unsigned int blocked;
+    /* The last vcpu woken up */
+    unsigned int last_vcpu_wake_up;
 };
 
 struct mem_event_per_domain
@@ -615,9 +626,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 Jan 16 15:41:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15: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 1Rmoge-0007gv-R3; Mon, 16 Jan 2012 15:41:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rmogd-0007gn-SN
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:41:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326728484!10675186!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10032 invoked from network); 16 Jan 2012 15:41:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Jan 2012 15:41:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326728484; l=591;
	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=sLF01cSpvPvpWuJRWpr9N12uxo0=;
	b=QRpLwGDUXLiCIDvHNFpRyk0MLLI+C4eE71b2OSxnTAqU2rIHepcIu5pCZmbRXTjbIM5
	8TH5EhuYe98UZpfhWFU+964LOGgi0OfQKLoowPSyku8zhddFgIUqJQAg/Hql6/olgMD//
	1lIdNYPsH/5GuF+kBduLXfe0PYik2mGrkR8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (fruni mo40) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L03a30o0GFeuq9 ;
	Mon, 16 Jan 2012 16:41:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 92F1218637; Mon, 16 Jan 2012 16:41:16 +0100 (CET)
Date: Mon, 16 Jan 2012 16:41:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116154116.GA31139@aepfle.de>
References: <28c68de1ea253d7dbe34.1326728344@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <28c68de1ea253d7dbe34.1326728344@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Mon, Jan 16, Andres Lagar-Cavilla wrote:

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -480,16 +480,15 @@ int p2m_mem_paging_evict(struct domain *
>  /* Tell xenpaging to drop a paged out frame */
>  void 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);
> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn);


As I said, this should remain void because the callers cant possibly
care about errors.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:41:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15: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 1Rmoge-0007gv-R3; Mon, 16 Jan 2012 15:41:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rmogd-0007gn-SN
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:41:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326728484!10675186!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10032 invoked from network); 16 Jan 2012 15:41:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-14.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 16 Jan 2012 15:41:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326728484; l=591;
	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=sLF01cSpvPvpWuJRWpr9N12uxo0=;
	b=QRpLwGDUXLiCIDvHNFpRyk0MLLI+C4eE71b2OSxnTAqU2rIHepcIu5pCZmbRXTjbIM5
	8TH5EhuYe98UZpfhWFU+964LOGgi0OfQKLoowPSyku8zhddFgIUqJQAg/Hql6/olgMD//
	1lIdNYPsH/5GuF+kBduLXfe0PYik2mGrkR8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (fruni mo40) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L03a30o0GFeuq9 ;
	Mon, 16 Jan 2012 16:41:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 92F1218637; Mon, 16 Jan 2012 16:41:16 +0100 (CET)
Date: Mon, 16 Jan 2012 16:41:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116154116.GA31139@aepfle.de>
References: <28c68de1ea253d7dbe34.1326728344@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <28c68de1ea253d7dbe34.1326728344@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Mon, Jan 16, Andres Lagar-Cavilla wrote:

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -480,16 +480,15 @@ int p2m_mem_paging_evict(struct domain *
>  /* Tell xenpaging to drop a paged out frame */
>  void 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);
> +int p2m_mem_paging_populate(struct domain *d, unsigned long gfn);


As I said, this should remain void because the callers cant possibly
care about errors.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 15:53:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmorm-0007rz-4I; Mon, 16 Jan 2012 15:53:02 +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 1Rmork-0007rq-K5
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:53:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326729174!11122927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18592 invoked from network); 16 Jan 2012 15:52:54 -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 Jan 2012 15:52:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10058302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 15:52:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 15:52:53 +0000
Date: Mon, 16 Jan 2012 15:53: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: <953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@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 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 16 Jan 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1326715929 0
> # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> libxl: Default to stub device model whenever possible.

Considering that stubdoms are not yet at feature parity I don't think we
should make this change for 4.2.
At the very least we should expand the set of conditions on which we base
the decision on: certainly the presence of an audio device, maybe pci
passthrough and the type of block backend (considering that some of them
go through qemu now) in case they aren't working properly.


> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Jan 16 11:33:18 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Mon Jan 16 12:12:09 2012 +0000
> @@ -94,7 +94,20 @@ int libxl__domain_build_info_setdefaults
>          b_info->device_model_version =
>              LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
>  
> -    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
> +    /* Default to stub domain device model if possible */
> +    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM
> +        && b_info->device_model_version
> +        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL
> +        && access(libxl__stubdom_kernel(gc), R_OK) == 0) {
> +        libxl_defbool_setdefault(&b_info->device_model_stubdomain, true);
> +    } else {
> +        libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
> +    }
> +
> +    if (b_info->device_model_version !=
> +        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
> +        libxl_defbool_val(b_info->device_model_stubdomain))
> +        return ERROR_INVAL;
>  
>      if (!b_info->max_vcpus)
>          b_info->max_vcpus = 1;
> diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Mon Jan 16 11:33:18 2012 +0000
> +++ b/tools/libxl/libxl_dm.c	Mon Jan 16 12:12:09 2012 +0000
> @@ -686,6 +686,11 @@ retry_transaction:
>      return 0;
>  }
>  
> +char *libxl__stubdom_kernel(libxl__gc *gc)
> +{
> +    return libxl__abs_path(gc, "ioemu-stubdom.gz", libxl_xenfirmwaredir_path());
> +}
> +
>  static int libxl__create_stubdom(libxl__gc *gc,
>                                   int guest_domid,
>                                   libxl_domain_config *guest_config,
> @@ -729,8 +734,7 @@ static int libxl__create_stubdom(libxl__
>      dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
>  
>      dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
> -    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
> -                                              libxl_xenfirmwaredir_path());
> +    dm_config.b_info.u.pv.kernel.path = libxl__stubdom_kernel(gc);
>      dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
>      dm_config.b_info.u.pv.ramdisk.path = "";
>      dm_config.b_info.u.pv.features = "";
> diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Mon Jan 16 11:33:18 2012 +0000
> +++ b/tools/libxl/libxl_internal.h	Mon Jan 16 12:12:09 2012 +0000
> @@ -482,6 +482,8 @@ _hidden int libxl__create_device_model(l
>                                libxl_domain_config *guest_config,
>                                libxl__domain_build_state *state,
>                                libxl__spawner_starting **starting_r);
> +_hidden char *libxl__stubdom_kernel(libxl__gc *gc);
> +
>  _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
>                                libxl_domain_config *guest_config,
>                                libxl__domain_build_state *state,
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 16 15:53:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 15:53:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmorm-0007rz-4I; Mon, 16 Jan 2012 15:53:02 +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 1Rmork-0007rq-K5
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 15:53:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326729174!11122927!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18592 invoked from network); 16 Jan 2012 15:52:54 -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 Jan 2012 15:52:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10058302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 15:52:53 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 15:52:53 +0000
Date: Mon, 16 Jan 2012 15:53: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: <953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@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 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 16 Jan 2012, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1326715929 0
> # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> libxl: Default to stub device model whenever possible.

Considering that stubdoms are not yet at feature parity I don't think we
should make this change for 4.2.
At the very least we should expand the set of conditions on which we base
the decision on: certainly the presence of an audio device, maybe pci
passthrough and the type of block backend (considering that some of them
go through qemu now) in case they aren't working properly.


> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Jan 16 11:33:18 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Mon Jan 16 12:12:09 2012 +0000
> @@ -94,7 +94,20 @@ int libxl__domain_build_info_setdefaults
>          b_info->device_model_version =
>              LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
>  
> -    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
> +    /* Default to stub domain device model if possible */
> +    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM
> +        && b_info->device_model_version
> +        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL
> +        && access(libxl__stubdom_kernel(gc), R_OK) == 0) {
> +        libxl_defbool_setdefault(&b_info->device_model_stubdomain, true);
> +    } else {
> +        libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
> +    }
> +
> +    if (b_info->device_model_version !=
> +        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
> +        libxl_defbool_val(b_info->device_model_stubdomain))
> +        return ERROR_INVAL;
>  
>      if (!b_info->max_vcpus)
>          b_info->max_vcpus = 1;
> diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_dm.c
> --- a/tools/libxl/libxl_dm.c	Mon Jan 16 11:33:18 2012 +0000
> +++ b/tools/libxl/libxl_dm.c	Mon Jan 16 12:12:09 2012 +0000
> @@ -686,6 +686,11 @@ retry_transaction:
>      return 0;
>  }
>  
> +char *libxl__stubdom_kernel(libxl__gc *gc)
> +{
> +    return libxl__abs_path(gc, "ioemu-stubdom.gz", libxl_xenfirmwaredir_path());
> +}
> +
>  static int libxl__create_stubdom(libxl__gc *gc,
>                                   int guest_domid,
>                                   libxl_domain_config *guest_config,
> @@ -729,8 +734,7 @@ static int libxl__create_stubdom(libxl__
>      dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
>  
>      dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
> -    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
> -                                              libxl_xenfirmwaredir_path());
> +    dm_config.b_info.u.pv.kernel.path = libxl__stubdom_kernel(gc);
>      dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
>      dm_config.b_info.u.pv.ramdisk.path = "";
>      dm_config.b_info.u.pv.features = "";
> diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Mon Jan 16 11:33:18 2012 +0000
> +++ b/tools/libxl/libxl_internal.h	Mon Jan 16 12:12:09 2012 +0000
> @@ -482,6 +482,8 @@ _hidden int libxl__create_device_model(l
>                                libxl_domain_config *guest_config,
>                                libxl__domain_build_state *state,
>                                libxl__spawner_starting **starting_r);
> +_hidden char *libxl__stubdom_kernel(libxl__gc *gc);
> +
>  _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
>                                libxl_domain_config *guest_config,
>                                libxl__domain_build_state *state,
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 16 16:01:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmozC-0008SK-DI; Mon, 16 Jan 2012 16:00:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RmozB-0008SE-5J
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:00:41 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326729634!11126080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23765 invoked from network); 16 Jan 2012 16:00: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;
	16 Jan 2012 16:00:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10058933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:00:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:00:33 +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 1Rmoz3-0004qO-Ld;
	Mon, 16 Jan 2012 16:00:33 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rmoyw-0006qB-3G;
	Mon, 16 Jan 2012 16:00:26 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 16:00:25 +0000
Message-ID: <1326729625-26264-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>
Subject: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config 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>
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


Expose more host bridge config space value to make
the driver happy for all the different revisions
of the device.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-Intel-GPU-passthrough-Host-bridge-config-space.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-Intel-GPU-passthrough-Host-bridge-config-space.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..17ce8c0 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -74,6 +74,9 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
     {
         case 0x00:        /* vendor id */
         case 0x02:        /* device id */
+        case 0x08:        /* revision id */
+        case 0x2c:        /* sybsystem vendor id */
+        case 0x2e:        /* sybsystem id */
         case 0x50:        /* SNB: processor graphics control register */
         case 0x52:        /* processor graphics control register */
         case 0xa0:        /* top of memory */

--------------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 Mon Jan 16 16:01:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmozC-0008SK-DI; Mon, 16 Jan 2012 16:00:42 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RmozB-0008SE-5J
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:00:41 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326729634!11126080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23765 invoked from network); 16 Jan 2012 16:00: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;
	16 Jan 2012 16:00:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10058933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:00:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:00:33 +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 1Rmoz3-0004qO-Ld;
	Mon, 16 Jan 2012 16:00:33 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rmoyw-0006qB-3G;
	Mon, 16 Jan 2012 16:00:26 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 16 Jan 2012 16:00:25 +0000
Message-ID: <1326729625-26264-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>
Subject: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config 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>
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


Expose more host bridge config space value to make
the driver happy for all the different revisions
of the device.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-Intel-GPU-passthrough-Host-bridge-config-space.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-Intel-GPU-passthrough-Host-bridge-config-space.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..17ce8c0 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -74,6 +74,9 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
     {
         case 0x00:        /* vendor id */
         case 0x02:        /* device id */
+        case 0x08:        /* revision id */
+        case 0x2c:        /* sybsystem vendor id */
+        case 0x2e:        /* sybsystem id */
         case 0x50:        /* SNB: processor graphics control register */
         case 0x52:        /* processor graphics control register */
         case 0xa0:        /* top of memory */

--------------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 Mon Jan 16 16:03:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmp1Y-00006U-BP; Mon, 16 Jan 2012 16:03:08 +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 1Rmp1X-00005s-BV
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:03:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326729781!11138486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32559 invoked from network); 16 Jan 2012 16:03:01 -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 Jan 2012 16:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:03: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; Mon, 16 Jan 2012 16:03:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rmp1Q-0004rB-MW; Mon, 16 Jan 2012 16:03:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp1Q-0005Gz-Lm;
	Mon, 16 Jan 2012 16:03:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.18996.662061.303782@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:03:00 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <cf86bcb7c89568a2c60f.1326716100@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<cf86bcb7c89568a2c60f.1326716100@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 02 of 32 RFC] libxl: use keyword arguments
 for field definitions in aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 02 of 32 RFC] libxl: use keyword arguments for field definitions in aggregate types"):
> libxl: use keyword arguments for field definitions in aggregate types.
> 
> The original code is not so bad now that the comments are gone but this is
> still a bit cleaner.
> 
> No change in the generated code.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:03:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:03:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmp1Y-00006U-BP; Mon, 16 Jan 2012 16:03:08 +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 1Rmp1X-00005s-BV
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:03:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326729781!11138486!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32559 invoked from network); 16 Jan 2012 16:03:01 -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 Jan 2012 16:03:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059058"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:03: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; Mon, 16 Jan 2012 16:03:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rmp1Q-0004rB-MW; Mon, 16 Jan 2012 16:03:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp1Q-0005Gz-Lm;
	Mon, 16 Jan 2012 16:03:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.18996.662061.303782@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:03:00 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <cf86bcb7c89568a2c60f.1326716100@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<cf86bcb7c89568a2c60f.1326716100@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 02 of 32 RFC] libxl: use keyword arguments
 for field definitions in aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 02 of 32 RFC] libxl: use keyword arguments for field definitions in aggregate types"):
> libxl: use keyword arguments for field definitions in aggregate types.
> 
> The original code is not so bad now that the comments are gone but this is
> still a bit cleaner.
> 
> No change in the generated code.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:03:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1Rmp1P-00005g-Ud; Mon, 16 Jan 2012 16:02: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 1Rmp1P-00005a-83
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326729773!11235851!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29814 invoked from network); 16 Jan 2012 16:02:53 -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;
	16 Jan 2012 16:02:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:02: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, 16 Jan 2012 16:02:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:02:52 +0000
In-Reply-To: <alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326729772.14689.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 15:53 +0000, Stefano Stabellini wrote:
> On Mon, 16 Jan 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1326715929 0
> > # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> > # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> > libxl: Default to stub device model whenever possible.
> 
> Considering that stubdoms are not yet at feature parity I don't think we
> should make this change for 4.2.
> At the very least we should expand the set of conditions on which we base
> the decision on: certainly the presence of an audio device, maybe pci
> passthrough and the type of block backend (considering that some of them
> go through qemu now) in case they aren't working properly.

Tweaking the precise conditions is reasonable and indeed the main thrust
of the series is to allow to make this sort of determination and to
change our minds about it.

Disabling stub-dm in the face of an audio is a no brainer. PCI
passthrough less obviously so since itm in theory, works but given the
number of problems we've had with it I'm inclined to also gate on that.

Which leaves block devices which is an interesting one because currently
I don't have enough info in hand during
libxl__domain_build_info_setdefaults to make that determination. I shall
look at how I can resolve that.

Ian.

> 
> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c	Mon Jan 16 11:33:18 2012 +0000
> > +++ b/tools/libxl/libxl_create.c	Mon Jan 16 12:12:09 2012 +0000
> > @@ -94,7 +94,20 @@ int libxl__domain_build_info_setdefaults
> >          b_info->device_model_version =
> >              LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
> >  
> > -    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
> > +    /* Default to stub domain device model if possible */
> > +    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM
> > +        && b_info->device_model_version
> > +        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL
> > +        && access(libxl__stubdom_kernel(gc), R_OK) == 0) {
> > +        libxl_defbool_setdefault(&b_info->device_model_stubdomain, true);
> > +    } else {
> > +        libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
> > +    }
> > +
> > +    if (b_info->device_model_version !=
> > +        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
> > +        libxl_defbool_val(b_info->device_model_stubdomain))
> > +        return ERROR_INVAL;
> >  
> >      if (!b_info->max_vcpus)
> >          b_info->max_vcpus = 1;
> > diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_dm.c
> > --- a/tools/libxl/libxl_dm.c	Mon Jan 16 11:33:18 2012 +0000
> > +++ b/tools/libxl/libxl_dm.c	Mon Jan 16 12:12:09 2012 +0000
> > @@ -686,6 +686,11 @@ retry_transaction:
> >      return 0;
> >  }
> >  
> > +char *libxl__stubdom_kernel(libxl__gc *gc)
> > +{
> > +    return libxl__abs_path(gc, "ioemu-stubdom.gz", libxl_xenfirmwaredir_path());
> > +}
> > +
> >  static int libxl__create_stubdom(libxl__gc *gc,
> >                                   int guest_domid,
> >                                   libxl_domain_config *guest_config,
> > @@ -729,8 +734,7 @@ static int libxl__create_stubdom(libxl__
> >      dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
> >  
> >      dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
> > -    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
> > -                                              libxl_xenfirmwaredir_path());
> > +    dm_config.b_info.u.pv.kernel.path = libxl__stubdom_kernel(gc);
> >      dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
> >      dm_config.b_info.u.pv.ramdisk.path = "";
> >      dm_config.b_info.u.pv.features = "";
> > diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h	Mon Jan 16 11:33:18 2012 +0000
> > +++ b/tools/libxl/libxl_internal.h	Mon Jan 16 12:12:09 2012 +0000
> > @@ -482,6 +482,8 @@ _hidden int libxl__create_device_model(l
> >                                libxl_domain_config *guest_config,
> >                                libxl__domain_build_state *state,
> >                                libxl__spawner_starting **starting_r);
> > +_hidden char *libxl__stubdom_kernel(libxl__gc *gc);
> > +
> >  _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
> >                                libxl_domain_config *guest_config,
> >                                libxl__domain_build_state *state,
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/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 Jan 16 16:03:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1Rmp1P-00005g-Ud; Mon, 16 Jan 2012 16:02: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 1Rmp1P-00005a-83
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:02:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326729773!11235851!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29814 invoked from network); 16 Jan 2012 16:02:53 -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;
	16 Jan 2012 16:02:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059057"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:02: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, 16 Jan 2012 16:02:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:02:52 +0000
In-Reply-To: <alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326729772.14689.10.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 15:53 +0000, Stefano Stabellini wrote:
> On Mon, 16 Jan 2012, Ian Campbell wrote:
> > # HG changeset patch
> > # User Ian Campbell <ian.campbell@citrix.com>
> > # Date 1326715929 0
> > # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> > # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> > libxl: Default to stub device model whenever possible.
> 
> Considering that stubdoms are not yet at feature parity I don't think we
> should make this change for 4.2.
> At the very least we should expand the set of conditions on which we base
> the decision on: certainly the presence of an audio device, maybe pci
> passthrough and the type of block backend (considering that some of them
> go through qemu now) in case they aren't working properly.

Tweaking the precise conditions is reasonable and indeed the main thrust
of the series is to allow to make this sort of determination and to
change our minds about it.

Disabling stub-dm in the face of an audio is a no brainer. PCI
passthrough less obviously so since itm in theory, works but given the
number of problems we've had with it I'm inclined to also gate on that.

Which leaves block devices which is an interesting one because currently
I don't have enough info in hand during
libxl__domain_build_info_setdefaults to make that determination. I shall
look at how I can resolve that.

Ian.

> 
> 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_create.c
> > --- a/tools/libxl/libxl_create.c	Mon Jan 16 11:33:18 2012 +0000
> > +++ b/tools/libxl/libxl_create.c	Mon Jan 16 12:12:09 2012 +0000
> > @@ -94,7 +94,20 @@ int libxl__domain_build_info_setdefaults
> >          b_info->device_model_version =
> >              LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
> >  
> > -    libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
> > +    /* Default to stub domain device model if possible */
> > +    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM
> > +        && b_info->device_model_version
> > +        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL
> > +        && access(libxl__stubdom_kernel(gc), R_OK) == 0) {
> > +        libxl_defbool_setdefault(&b_info->device_model_stubdomain, true);
> > +    } else {
> > +        libxl_defbool_setdefault(&b_info->device_model_stubdomain, false);
> > +    }
> > +
> > +    if (b_info->device_model_version !=
> > +        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL &&
> > +        libxl_defbool_val(b_info->device_model_stubdomain))
> > +        return ERROR_INVAL;
> >  
> >      if (!b_info->max_vcpus)
> >          b_info->max_vcpus = 1;
> > diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_dm.c
> > --- a/tools/libxl/libxl_dm.c	Mon Jan 16 11:33:18 2012 +0000
> > +++ b/tools/libxl/libxl_dm.c	Mon Jan 16 12:12:09 2012 +0000
> > @@ -686,6 +686,11 @@ retry_transaction:
> >      return 0;
> >  }
> >  
> > +char *libxl__stubdom_kernel(libxl__gc *gc)
> > +{
> > +    return libxl__abs_path(gc, "ioemu-stubdom.gz", libxl_xenfirmwaredir_path());
> > +}
> > +
> >  static int libxl__create_stubdom(libxl__gc *gc,
> >                                   int guest_domid,
> >                                   libxl_domain_config *guest_config,
> > @@ -729,8 +734,7 @@ static int libxl__create_stubdom(libxl__
> >      dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
> >  
> >      dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
> > -    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
> > -                                              libxl_xenfirmwaredir_path());
> > +    dm_config.b_info.u.pv.kernel.path = libxl__stubdom_kernel(gc);
> >      dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
> >      dm_config.b_info.u.pv.ramdisk.path = "";
> >      dm_config.b_info.u.pv.features = "";
> > diff -r a2dc899d0f22 -r 953a1ce64385 tools/libxl/libxl_internal.h
> > --- a/tools/libxl/libxl_internal.h	Mon Jan 16 11:33:18 2012 +0000
> > +++ b/tools/libxl/libxl_internal.h	Mon Jan 16 12:12:09 2012 +0000
> > @@ -482,6 +482,8 @@ _hidden int libxl__create_device_model(l
> >                                libxl_domain_config *guest_config,
> >                                libxl__domain_build_state *state,
> >                                libxl__spawner_starting **starting_r);
> > +_hidden char *libxl__stubdom_kernel(libxl__gc *gc);
> > +
> >  _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
> >                                libxl_domain_config *guest_config,
> >                                libxl__domain_build_state *state,
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/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 Jan 16 16:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1Rmp2b-0000Dy-Qn; Mon, 16 Jan 2012 16:04: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 1Rmp2a-0000D4-EL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:04:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326729846!8506355!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17662 invoked from network); 16 Jan 2012 16:04:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:04:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:04: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, 16 Jan 2012 16:04: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
	1Rmp2T-0004rX-QI; Mon, 16 Jan 2012 16:04:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp2T-0005HH-PV;
	Mon, 16 Jan 2012 16:04:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19058.131905.170632@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:04:02 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <fa999f4bcd85526a9ad1.1326716120@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<fa999f4bcd85526a9ad1.1326716120@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 22 of 32 RFC] libxl: only write "disable_pf"
 key to xenstore when it makes sense
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 22 of 32 RFC] libxl: only write "disable_pf" key to xenstore when it makes sense"):
> libxl: only write "disable_pf" key to xenstore when it makes sense
> 
> This key is only used by the traditional qemu-dm when servicing an HVM domain.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:04:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1Rmp2b-0000Dy-Qn; Mon, 16 Jan 2012 16:04: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 1Rmp2a-0000D4-EL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:04:12 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326729846!8506355!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17662 invoked from network); 16 Jan 2012 16:04:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:04:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059092"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:04: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, 16 Jan 2012 16:04: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
	1Rmp2T-0004rX-QI; Mon, 16 Jan 2012 16:04:05 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp2T-0005HH-PV;
	Mon, 16 Jan 2012 16:04:05 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19058.131905.170632@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:04:02 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <fa999f4bcd85526a9ad1.1326716120@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<fa999f4bcd85526a9ad1.1326716120@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 22 of 32 RFC] libxl: only write "disable_pf"
 key to xenstore when it makes sense
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 22 of 32 RFC] libxl: only write "disable_pf" key to xenstore when it makes sense"):
> libxl: only write "disable_pf" key to xenstore when it makes sense
> 
> This key is only used by the traditional qemu-dm when servicing an HVM domain.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1Rmp3B-0000JD-8C; Mon, 16 Jan 2012 16:04: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 1Rmp3A-0000IN-Bm
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:04:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326729881!9326172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5411 invoked from network); 16 Jan 2012 16:04:42 -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 Jan 2012 16:04:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:04:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:04: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
	1Rmp32-0004ro-RR; Mon, 16 Jan 2012 16:04:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp32-0005HQ-Qr;
	Mon, 16 Jan 2012 16:04:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19096.820060.662140@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:04:40 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3308d2dfd9dddb36f8a6.1326716104@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<3308d2dfd9dddb36f8a6.1326716104@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 06 of 32 RFC] libxl: define libxl_spice_info
 to hold all info about the spice server
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 06 of 32 RFC] libxl: define libxl_spice> libxl: define libxl_spice_info to hold all info about the spice server

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1Rmp3B-0000JD-8C; Mon, 16 Jan 2012 16:04: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 1Rmp3A-0000IN-Bm
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:04:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326729881!9326172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5411 invoked from network); 16 Jan 2012 16:04:42 -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 Jan 2012 16:04:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:04:41 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:04: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
	1Rmp32-0004ro-RR; Mon, 16 Jan 2012 16:04:40 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp32-0005HQ-Qr;
	Mon, 16 Jan 2012 16:04:40 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19096.820060.662140@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:04:40 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3308d2dfd9dddb36f8a6.1326716104@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<3308d2dfd9dddb36f8a6.1326716104@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 06 of 32 RFC] libxl: define libxl_spice_info
 to hold all info about the spice server
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 06 of 32 RFC] libxl: define libxl_spice> libxl: define libxl_spice_info to hold all info about the spice server

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmp4T-0000Vi-VO; Mon, 16 Jan 2012 16:06: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 1Rmp4S-0000Ut-6M
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:06:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326729961!5137267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17049 invoked from network); 16 Jan 2012 16:06:02 -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;
	16 Jan 2012 16:06:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:06: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; Mon, 16 Jan 2012 16:06: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
	1Rmp4L-0004sM-Gw; Mon, 16 Jan 2012 16:06:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp4L-0005HZ-GE;
	Mon, 16 Jan 2012 16:06:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19177.489672.651626@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:06:01 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7e9f3ce2cd1f05ae3072.1326716122@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<7e9f3ce2cd1f05ae3072.1326716122@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 24 of 32 RFC] libxl: add new "defbool" built
	in	type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 24 of 32 RFC] libxl: add new "defbool" built in type"):
> libxl: add new "defbool" built in type.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:06:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:06:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmp4T-0000Vi-VO; Mon, 16 Jan 2012 16:06: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 1Rmp4S-0000Ut-6M
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:06:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326729961!5137267!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17049 invoked from network); 16 Jan 2012 16:06:02 -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;
	16 Jan 2012 16:06:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059190"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:06: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; Mon, 16 Jan 2012 16:06: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
	1Rmp4L-0004sM-Gw; Mon, 16 Jan 2012 16:06:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp4L-0005HZ-GE;
	Mon, 16 Jan 2012 16:06:01 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19177.489672.651626@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:06:01 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <7e9f3ce2cd1f05ae3072.1326716122@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<7e9f3ce2cd1f05ae3072.1326716122@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 24 of 32 RFC] libxl: add new "defbool" built
	in	type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 24 of 32 RFC] libxl: add new "defbool" built in type"):
> libxl: add new "defbool" built in type.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:10:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 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 1Rmp8O-0000s0-L6; Mon, 16 Jan 2012 16:10: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 1Rmp8M-0000rY-Bc
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:10:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326730203!9355477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12849 invoked from network); 16 Jan 2012 16:10:04 -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;
	16 Jan 2012 16:10:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:10: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; Mon, 16 Jan 2012 16:10: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
	1Rmp8F-0004tq-Bh; Mon, 16 Jan 2012 16:10:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp8F-0005ID-Ag;
	Mon, 16 Jan 2012 16:10:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19419.317401.627201@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:10:03 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2cf31bf780380c42d859.1326716105@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<2cf31bf780380c42d859.1326716105@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 07 of 32 RFC] libxl: define libxl_sdl_info
 to hold all info about the SDL config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 07 of 32 RFC] libxl: define libxl_sdl_info to hold all info about the SDL config"):
> libxl: define libxl_sdl_info to hold all info about the SDL config

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:10:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 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 1Rmp8O-0000s0-L6; Mon, 16 Jan 2012 16:10: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 1Rmp8M-0000rY-Bc
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:10:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326730203!9355477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12849 invoked from network); 16 Jan 2012 16:10:04 -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;
	16 Jan 2012 16:10:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059334"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:10: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; Mon, 16 Jan 2012 16:10: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
	1Rmp8F-0004tq-Bh; Mon, 16 Jan 2012 16:10:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp8F-0005ID-Ag;
	Mon, 16 Jan 2012 16:10:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19419.317401.627201@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:10:03 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <2cf31bf780380c42d859.1326716105@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<2cf31bf780380c42d859.1326716105@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 07 of 32 RFC] libxl: define libxl_sdl_info
 to hold all info about the SDL config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 07 of 32 RFC] libxl: define libxl_sdl_info to hold all info about the SDL config"):
> libxl: define libxl_sdl_info to hold all info about the SDL config

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:11:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmp9d-0000xw-4I; Mon, 16 Jan 2012 16:11:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rmp9b-0000xQ-Ny
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:11:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326730281!9354370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18019 invoked from network); 16 Jan 2012 16:11:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:11:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059391"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:11: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, 16 Jan 2012 16:11: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
	1Rmp9V-0004uR-7M; Mon, 16 Jan 2012 16:11:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp9V-0005IT-6X;
	Mon, 16 Jan 2012 16:11:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19497.187819.644371@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:11:21 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <28f0d13e7deafd13ae37.1326716113@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<28f0d13e7deafd13ae37.1326716113@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 15 of 32 RFC] libxl: move gfx_passthru
	setting	to b_info->u.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

Ian Campbell writes ("[Xen-devel] [PATCH 15 of 32 RFC] libxl: move gfx_passthru > libxl: move gfx_passthru setting to b_info->u.hvm

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:11:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:11:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmp9d-0000xw-4I; Mon, 16 Jan 2012 16:11:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rmp9b-0000xQ-Ny
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:11:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326730281!9354370!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18019 invoked from network); 16 Jan 2012 16:11:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:11:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059391"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:11: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, 16 Jan 2012 16:11: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
	1Rmp9V-0004uR-7M; Mon, 16 Jan 2012 16:11:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp9V-0005IT-6X;
	Mon, 16 Jan 2012 16:11:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19497.187819.644371@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:11:21 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <28f0d13e7deafd13ae37.1326716113@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<28f0d13e7deafd13ae37.1326716113@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 15 of 32 RFC] libxl: move gfx_passthru
	setting	to b_info->u.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

Ian Campbell writes ("[Xen-devel] [PATCH 15 of 32 RFC] libxl: move gfx_passthru > libxl: move gfx_passthru setting to b_info->u.hvm

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:12:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpAk-00015B-JT; Mon, 16 Jan 2012 16:12: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 1RmpAi-00014S-PG
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:12:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326730304!50451184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30797 invoked from network); 16 Jan 2012 16:11: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;
	16 Jan 2012 16:11:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:12: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, 16 Jan 2012 16:12: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
	1RmpAP-0004up-GY; Mon, 16 Jan 2012 16:12:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpAP-0005Ig-Fw;
	Mon, 16 Jan 2012 16:12:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19553.482085.748655@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:12:17 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a2dc899d0f229d82baca.1326716129@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<a2dc899d0f229d82baca.1326716129@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 31 of 32 RFC] libxl: switch device model
 selection over to libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 31 of 32 RFC] libxl: switch device model selection over to libxl_defbool"):
> libxl: switch device model selection over to libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:12:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpAk-00015B-JT; Mon, 16 Jan 2012 16:12: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 1RmpAi-00014S-PG
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:12:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326730304!50451184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30797 invoked from network); 16 Jan 2012 16:11: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;
	16 Jan 2012 16:11:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059438"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:12: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, 16 Jan 2012 16:12: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
	1RmpAP-0004up-GY; Mon, 16 Jan 2012 16:12:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpAP-0005Ig-Fw;
	Mon, 16 Jan 2012 16:12:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19553.482085.748655@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:12:17 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a2dc899d0f229d82baca.1326716129@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<a2dc899d0f229d82baca.1326716129@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 31 of 32 RFC] libxl: switch device model
 selection over to libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 31 of 32 RFC] libxl: switch device model selection over to libxl_defbool"):
> libxl: switch device model selection over to libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:13:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpBM-00019p-1L; Mon, 16 Jan 2012 16:13:16 +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 1RmpBK-00018k-Er
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:13:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326730387!9152108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9820 invoked from network); 16 Jan 2012 16:13:08 -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;
	16 Jan 2012 16:13:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:13: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, 16 Jan 2012 16:13: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
	1RmpBD-0004vA-8d; Mon, 16 Jan 2012 16:13:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpBD-0005Iv-7v;
	Mon, 16 Jan 2012 16:13:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19603.233137.934271@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:13:07 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <714cb45a8327bae6ede1.1326716110@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<714cb45a8327bae6ede1.1326716110@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 12 of 32 RFC] libxl: use vfb[0] directly
	for	xenpv device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 12 of 32 RFC] libxl: use vfb[0] directly for xenpv device model"):
> libxl: use vfb[0] directly for xenpv device model

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:13:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpBM-00019p-1L; Mon, 16 Jan 2012 16:13:16 +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 1RmpBK-00018k-Er
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:13:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326730387!9152108!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9820 invoked from network); 16 Jan 2012 16:13:08 -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;
	16 Jan 2012 16:13:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:13: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, 16 Jan 2012 16:13: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
	1RmpBD-0004vA-8d; Mon, 16 Jan 2012 16:13:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpBD-0005Iv-7v;
	Mon, 16 Jan 2012 16:13:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19603.233137.934271@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:13:07 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <714cb45a8327bae6ede1.1326716110@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<714cb45a8327bae6ede1.1326716110@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 12 of 32 RFC] libxl: use vfb[0] directly
	for	xenpv device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 12 of 32 RFC] libxl: use vfb[0] directly for xenpv device model"):
> libxl: use vfb[0] directly for xenpv device model

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:14:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpBt-0001FO-Fr; Mon, 16 Jan 2012 16:13:49 +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 1RmpBs-0001E9-2j
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:13:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326730421!11237545!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27121 invoked from network); 16 Jan 2012 16:13:41 -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;
	16 Jan 2012 16:13:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16: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; Mon, 16 Jan 2012 16: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
	1RmpBl-0004vL-6W; Mon, 16 Jan 2012 16:13:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpBl-0005J4-5s;
	Mon, 16 Jan 2012 16:13:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19637.169291.747875@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:13:41 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20f5a6a37f6aac5eb314.1326716115@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<20f5a6a37f6aac5eb314.1326716115@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 17 of 32 RFC] libxl: remove uuid from
	device	model info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 17 of 32 RFC] libxl: remove uuid from device model info"):
> libxl: remove uuid from device model info.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:14:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:14:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpBt-0001FO-Fr; Mon, 16 Jan 2012 16:13:49 +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 1RmpBs-0001E9-2j
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:13:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326730421!11237545!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27121 invoked from network); 16 Jan 2012 16:13:41 -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;
	16 Jan 2012 16:13:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059478"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16: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; Mon, 16 Jan 2012 16: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
	1RmpBl-0004vL-6W; Mon, 16 Jan 2012 16:13:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpBl-0005J4-5s;
	Mon, 16 Jan 2012 16:13:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19637.169291.747875@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:13:41 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20f5a6a37f6aac5eb314.1326716115@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<20f5a6a37f6aac5eb314.1326716115@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 17 of 32 RFC] libxl: remove uuid from
	device	model info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 17 of 32 RFC] libxl: remove uuid from device model info"):
> libxl: remove uuid from device model info.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:14:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpCg-0001NG-VH; Mon, 16 Jan 2012 16:14: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 1RmpCf-0001Mc-Rp
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:14:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326730358!59907376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21752 invoked from network); 16 Jan 2012 16:12: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;
	16 Jan 2012 16:12:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:14:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:14: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
	1RmpCb-0004vc-6t; Mon, 16 Jan 2012 16:14:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpCb-0005JI-6A;
	Mon, 16 Jan 2012 16:14:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19689.176362.921419@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:14:33 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3db40f3e8b2af814b9f7.1326716109@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<3db40f3e8b2af814b9f7.1326716109@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
Subject: Re: [Xen-devel] [PATCH 11 of 32 RFC] libxl: drop dm_info.dom_name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 11 of 32 RFC] libxl: drop dm_info.dom_name"):
> libxl: drop dm_info.dom_name

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:14:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpCg-0001NG-VH; Mon, 16 Jan 2012 16:14: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 1RmpCf-0001Mc-Rp
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:14:38 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326730358!59907376!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21752 invoked from network); 16 Jan 2012 16:12: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;
	16 Jan 2012 16:12:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:14:33 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:14: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
	1RmpCb-0004vc-6t; Mon, 16 Jan 2012 16:14:33 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpCb-0005JI-6A;
	Mon, 16 Jan 2012 16:14:33 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19689.176362.921419@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:14:33 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <3db40f3e8b2af814b9f7.1326716109@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<3db40f3e8b2af814b9f7.1326716109@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
Subject: Re: [Xen-devel] [PATCH 11 of 32 RFC] libxl: drop dm_info.dom_name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 11 of 32 RFC] libxl: drop dm_info.dom_name"):
> libxl: drop dm_info.dom_name

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:15:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpDJ-0001UR-Ck; Mon, 16 Jan 2012 16:15:17 +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 1RmpDH-0001T8-8Z
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:15:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326730504!11111418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11243 invoked from network); 16 Jan 2012 16:15:05 -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;
	16 Jan 2012 16:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:15:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 16:15:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:15:04 +0000
In-Reply-To: <20244.19379.430191.296744@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
	<20244.19379.430191.296744@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326730504.14689.17.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 23 of 32 RFC] libxl: use libxl_*_init
 internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:09 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 23 of 32 RFC] libxl: use libxl_*_init internally too"):
> > libxl: use libxl_*_init internally too
> ...
> > +    ret = libxl_device_vfb_init(CTX, vfb);
> > +    if (ret) return ret;
> 
> Can we make these init functions infallible ?  (I haven't read
> their code yet...)

I think the reason is that sometimes they might allocate memory. Many of
them don't (I don't know about vfb in particular) and I don't know
whether we prefer consistency in similar functions or avoiding pointless
return values (I prefer the former so as to avoid needing to change the
public API in the future when we find that we have introduced a way for
a function to fail).

Possibly in the new world order (where init ~= memset and setdefaults
does thework) this will no longer be the case, but then the same will
become true of the setdefaults function.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:15:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:15:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpDJ-0001UR-Ck; Mon, 16 Jan 2012 16:15:17 +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 1RmpDH-0001T8-8Z
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:15:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326730504!11111418!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11243 invoked from network); 16 Jan 2012 16:15:05 -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;
	16 Jan 2012 16:15:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059713"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:15:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 16:15:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:15:04 +0000
In-Reply-To: <20244.19379.430191.296744@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
	<20244.19379.430191.296744@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326730504.14689.17.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 23 of 32 RFC] libxl: use libxl_*_init
 internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:09 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 23 of 32 RFC] libxl: use libxl_*_init internally too"):
> > libxl: use libxl_*_init internally too
> ...
> > +    ret = libxl_device_vfb_init(CTX, vfb);
> > +    if (ret) return ret;
> 
> Can we make these init functions infallible ?  (I haven't read
> their code yet...)

I think the reason is that sometimes they might allocate memory. Many of
them don't (I don't know about vfb in particular) and I don't know
whether we prefer consistency in similar functions or avoiding pointless
return values (I prefer the former so as to avoid needing to change the
public API in the future when we find that we have introduced a way for
a function to fail).

Possibly in the new world order (where init ~= memset and setdefaults
does thework) this will no longer be the case, but then the same will
become true of the setdefaults function.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:16:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpEj-0001lx-TW; Mon, 16 Jan 2012 16:16: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 1RmpEi-0001l4-Hb
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:16:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326730598!8584020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1987 invoked from network); 16 Jan 2012 16:16:38 -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;
	16 Jan 2012 16:16:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:16: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, 16 Jan 2012 16:16: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
	1RmpEb-0004wM-LU; Mon, 16 Jan 2012 16:16:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpEb-0005Jd-Ki;
	Mon, 16 Jan 2012 16:16:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19813.629009.581935@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:16:37 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326730504.14689.17.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
	<20244.19379.430191.296744@mariner.uk.xensource.com>
	<1326730504.14689.17.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 23 of 32 RFC] libxl: use libxl_*_init
 internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 23 of 32 RFC] libxl: use libxl_*_init internally	too"):
> I think the reason is that sometimes they might allocate memory. Many of
> them don't (I don't know about vfb in particular) and I don't know
> whether we prefer consistency in similar functions or avoiding pointless
> return values (I prefer the former so as to avoid needing to change the
> public API in the future when we find that we have introduced a way for
> a function to fail).

Why might they need to allocate memory ?

> Possibly in the new world order (where init ~= memset and setdefaults
> does thework) this will no longer be the case, but then the same will
> become true of the setdefaults function.

Yes.  I think it's OK for setdefaults to be able to fail.

Having infallible init functions is a real boon because it makes the
caller's memory management much easier, because they can always safely
dispose.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:16:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:16:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpEj-0001lx-TW; Mon, 16 Jan 2012 16:16: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 1RmpEi-0001l4-Hb
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:16:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326730598!8584020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1987 invoked from network); 16 Jan 2012 16:16:38 -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;
	16 Jan 2012 16:16:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060033"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:16: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, 16 Jan 2012 16:16: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
	1RmpEb-0004wM-LU; Mon, 16 Jan 2012 16:16:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpEb-0005Jd-Ki;
	Mon, 16 Jan 2012 16:16:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19813.629009.581935@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:16:37 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326730504.14689.17.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
	<20244.19379.430191.296744@mariner.uk.xensource.com>
	<1326730504.14689.17.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 23 of 32 RFC] libxl: use libxl_*_init
 internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 23 of 32 RFC] libxl: use libxl_*_init internally	too"):
> I think the reason is that sometimes they might allocate memory. Many of
> them don't (I don't know about vfb in particular) and I don't know
> whether we prefer consistency in similar functions or avoiding pointless
> return values (I prefer the former so as to avoid needing to change the
> public API in the future when we find that we have introduced a way for
> a function to fail).

Why might they need to allocate memory ?

> Possibly in the new world order (where init ~= memset and setdefaults
> does thework) this will no longer be the case, but then the same will
> become true of the setdefaults function.

Yes.  I think it's OK for setdefaults to be able to fail.

Having infallible init functions is a real boon because it makes the
caller's memory management much easier, because they can always safely
dispose.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:17:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpFO-0001xp-BZ; Mon, 16 Jan 2012 16:17:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmpFN-0001x1-BK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:17:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326730614!55906441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24379 invoked from network); 16 Jan 2012 16:16:54 -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 Jan 2012 16:16:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:16: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, 16 Jan 2012 16:16: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
	1RmpEs-0004wX-19; Mon, 16 Jan 2012 16:16:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpEs-0005Jh-0W;
	Mon, 16 Jan 2012 16:16:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19830.4674.184535@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:16:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ed7106b3f874d93e8ed8.1326716103@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<ed7106b3f874d93e8ed8.1326716103@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 05 of 32 RFC] libxl: define libxl_vnc_info
 to hold all info about the vnc info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 05 of 32 RFC] libxl: define libxl_vnc_info to hold all info about the vnc info"):
> libxl: define libxl_vnc_info to hold all info about the vnc info

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:17:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpFO-0001xp-BZ; Mon, 16 Jan 2012 16:17:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmpFN-0001x1-BK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:17:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326730614!55906441!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24379 invoked from network); 16 Jan 2012 16:16:54 -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 Jan 2012 16:16:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060043"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:16: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, 16 Jan 2012 16:16: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
	1RmpEs-0004wX-19; Mon, 16 Jan 2012 16:16:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpEs-0005Jh-0W;
	Mon, 16 Jan 2012 16:16:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19830.4674.184535@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:16:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <ed7106b3f874d93e8ed8.1326716103@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<ed7106b3f874d93e8ed8.1326716103@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 05 of 32 RFC] libxl: define libxl_vnc_info
 to hold all info about the vnc info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 05 of 32 RFC] libxl: define libxl_vnc_info to hold all info about the vnc info"):
> libxl: define libxl_vnc_info to hold all info about the vnc info

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:18:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:18:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpFy-0002B6-UT; Mon, 16 Jan 2012 16:18: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 1RmpFw-00029Y-VV
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:18:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326730674!9299510!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23297 invoked from network); 16 Jan 2012 16:17:55 -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;
	16 Jan 2012 16:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:17: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, 16 Jan 2012 16:17: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
	1RmpFq-0004ww-E0; Mon, 16 Jan 2012 16:17:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpFq-0005Ju-DB;
	Mon, 16 Jan 2012 16:17:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19890.395440.528682@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:17:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<feeea78c60ef4a0ec5d4.1326716127@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 29 of 32 RFC] libxl: add named enum for
	timer	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer mode"):
> libxl: add named enum for timer mode.
> 
> In order to have 0 == default the specific values are off-by-one from the
> underlying domctl. I'm not sure I like this.

If we're abolishing the idea of memsetting infos to 0, and instead
requiring everyone to call _init, we could decree that all-bits-set
means "use default value".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:18:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:18:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpFy-0002B6-UT; Mon, 16 Jan 2012 16:18: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 1RmpFw-00029Y-VV
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:18:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326730674!9299510!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23297 invoked from network); 16 Jan 2012 16:17:55 -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;
	16 Jan 2012 16:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:17: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, 16 Jan 2012 16:17: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
	1RmpFq-0004ww-E0; Mon, 16 Jan 2012 16:17:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpFq-0005Ju-DB;
	Mon, 16 Jan 2012 16:17:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19890.395440.528682@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:17:54 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<feeea78c60ef4a0ec5d4.1326716127@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 29 of 32 RFC] libxl: add named enum for
	timer	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer mode"):
> libxl: add named enum for timer mode.
> 
> In order to have 0 == default the specific values are off-by-one from the
> underlying domctl. I'm not sure I like this.

If we're abolishing the idea of memsetting infos to 0, and instead
requiring everyone to call _init, we could decree that all-bits-set
means "use default value".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:20:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpIL-0002Vl-IS; Mon, 16 Jan 2012 16:20:29 +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 1RmpIK-0002VF-PK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:20:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326730822!3801564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14325 invoked from network); 16 Jan 2012 16:20:22 -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;
	16 Jan 2012 16:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:20:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:20: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
	1RmpIA-0004xw-Qd; Mon, 16 Jan 2012 16:20:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpIA-0005KA-On;
	Mon, 16 Jan 2012 16:20:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20034.600655.133108@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:20:18 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <934adb649b43db974d24.1326716114@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<934adb649b43db974d24.1326716114@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 16 of 32 RFC] libxl:
	Remove	libxl_device_model_info.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

Ian Campbell writes ("[Xen-devel] [PATCH 16 of 32 RFC] libxl: Remove libxl_device_model_info.type"):
> libxl: Remove libxl_device_model_info.type.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:20:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:20:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpIL-0002Vl-IS; Mon, 16 Jan 2012 16:20:29 +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 1RmpIK-0002VF-PK
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:20:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326730822!3801564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14325 invoked from network); 16 Jan 2012 16:20:22 -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;
	16 Jan 2012 16:20:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:20:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:20: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
	1RmpIA-0004xw-Qd; Mon, 16 Jan 2012 16:20:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpIA-0005KA-On;
	Mon, 16 Jan 2012 16:20:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20034.600655.133108@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:20:18 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <934adb649b43db974d24.1326716114@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<934adb649b43db974d24.1326716114@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 16 of 32 RFC] libxl:
	Remove	libxl_device_model_info.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

Ian Campbell writes ("[Xen-devel] [PATCH 16 of 32 RFC] libxl: Remove libxl_device_model_info.type"):
> libxl: Remove libxl_device_model_info.type.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:21:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpJD-0002cA-0m; Mon, 16 Jan 2012 16:21:23 +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 1RmpJB-0002ba-C5
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:21:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326730875!9367657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1561 invoked from network); 16 Jan 2012 16:21:15 -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;
	16 Jan 2012 16:21:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:21: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, 16 Jan 2012 16:21: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
	1RmpJ4-0004yD-3s; Mon, 16 Jan 2012 16:21:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpJ4-0005KU-2y;
	Mon, 16 Jan 2012 16:21:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20090.79697.777479@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:21:14 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <14605ae17bd9d8a3e2a5.1326716106@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<14605ae17bd9d8a3e2a5.1326716106@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 08 of 32 RFC] libxl: plumb
 libxl_domain_config down into device model 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

Ian Campbell writes ("[Xen-devel] [PATCH 08 of 32 RFC] libxl: plumb libxl_domain_config down into device model creation"):
> libxl: plumb libxl_domain_config down into device model creation.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Although there are some lines which are still wrapping on my screen.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:21:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:21:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpJD-0002cA-0m; Mon, 16 Jan 2012 16:21:23 +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 1RmpJB-0002ba-C5
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:21:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326730875!9367657!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1561 invoked from network); 16 Jan 2012 16:21:15 -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;
	16 Jan 2012 16:21:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060483"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:21: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, 16 Jan 2012 16:21: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
	1RmpJ4-0004yD-3s; Mon, 16 Jan 2012 16:21:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpJ4-0005KU-2y;
	Mon, 16 Jan 2012 16:21:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20090.79697.777479@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:21:14 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <14605ae17bd9d8a3e2a5.1326716106@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<14605ae17bd9d8a3e2a5.1326716106@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 08 of 32 RFC] libxl: plumb
 libxl_domain_config down into device model 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

Ian Campbell writes ("[Xen-devel] [PATCH 08 of 32 RFC] libxl: plumb libxl_domain_config down into device model creation"):
> libxl: plumb libxl_domain_config down into device model creation.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Although there are some lines which are still wrapping on my screen.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:22:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpKG-0002js-G8; Mon, 16 Jan 2012 16:22:28 +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 1RmpKF-0002jB-0C
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:22:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326730940!11254923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14988 invoked from network); 16 Jan 2012 16:22:21 -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;
	16 Jan 2012 16:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:22:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:22: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
	1RmpJx-0004yg-Lr; Mon, 16 Jan 2012 16:22:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpJx-0005Kr-LE;
	Mon, 16 Jan 2012 16:22:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20145.646636.572075@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:22:09 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a27ac2ae9cefc42e3eee.1326716108@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<a27ac2ae9cefc42e3eee.1326716108@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 10 of 32 RFC] libxl: remove redundant info
	from	dm info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 10 of 32 RFC] libxl: remove redundant info from dm info"):
> libxl: remove redundant info from dm info.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:22:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:22:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpKG-0002js-G8; Mon, 16 Jan 2012 16:22:28 +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 1RmpKF-0002jB-0C
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:22:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326730940!11254923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14988 invoked from network); 16 Jan 2012 16:22:21 -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;
	16 Jan 2012 16:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060522"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:22:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:22: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
	1RmpJx-0004yg-Lr; Mon, 16 Jan 2012 16:22:09 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpJx-0005Kr-LE;
	Mon, 16 Jan 2012 16:22:09 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20145.646636.572075@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:22:09 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a27ac2ae9cefc42e3eee.1326716108@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<a27ac2ae9cefc42e3eee.1326716108@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 10 of 32 RFC] libxl: remove redundant info
	from	dm info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 10 of 32 RFC] libxl: remove redundant info from dm info"):
> libxl: remove redundant info from dm info.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:22:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:22:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpKG-0002k3-Tz; Mon, 16 Jan 2012 16:22:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmpKF-0002jD-7r
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:22:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326730940!7507896!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22805 invoked from network); 16 Jan 2012 16:22:21 -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;
	16 Jan 2012 16:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:21: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, 16 Jan 2012 16:21: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
	1RmpJb-0004yQ-4z; Mon, 16 Jan 2012 16:21:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpJb-0005Ki-3E;
	Mon, 16 Jan 2012 16:21:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20123.87053.524510@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:21:47 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <c7160a835d3c01b63175.1326716117@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<c7160a835d3c01b63175.1326716117@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 19 of 32 RFC] libxl: move "saved_state" to
 libxl__domain_build_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 19 of 32 RFC] libxl: move "saved_state" to libxl__domain_build_state"):
> libxl: move "saved_state" to libxl__domain_build_state.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:22:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:22:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpKG-0002k3-Tz; Mon, 16 Jan 2012 16:22:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmpKF-0002jD-7r
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:22:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326730940!7507896!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22805 invoked from network); 16 Jan 2012 16:22:21 -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;
	16 Jan 2012 16:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060514"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:21: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, 16 Jan 2012 16:21: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
	1RmpJb-0004yQ-4z; Mon, 16 Jan 2012 16:21:47 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpJb-0005Ki-3E;
	Mon, 16 Jan 2012 16:21:47 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20123.87053.524510@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:21:47 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <c7160a835d3c01b63175.1326716117@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<c7160a835d3c01b63175.1326716117@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 19 of 32 RFC] libxl: move "saved_state" to
 libxl__domain_build_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 19 of 32 RFC] libxl: move "saved_state" to libxl__domain_build_state"):
> libxl: move "saved_state" to libxl__domain_build_state.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:23:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpKh-0002pE-C7; Mon, 16 Jan 2012 16:22:55 +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 1RmpKg-0002oF-D1
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:22:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326730967!9300233!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6078 invoked from network); 16 Jan 2012 16:22:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Jan 2012 16:22:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326730967; 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=xMVa4sMii3ZxKIVadC+9C5Vidrk=;
	b=RDqPJ0ogPPvH/+jtGoiEMnozZC1QqMY4IXbt4fyZehzLMEVyiFmHTCnN/3Xp3CiAgN2
	f093pFA9dqg5RoV84jbITA+UXLw2F8XUL1q5BOPOeOXT7ABC/wEC1YnuYzFDJyFK2gqzq
	OlGWS0puZjzAwEUDFLcKPp7CHqVYR72eF5Q=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (cohen mo36) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x05549o0GFbW8s ;
	Mon, 16 Jan 2012 17:22:29 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id EF3CC18637; Mon, 16 Jan 2012 17:22:29 +0100 (CET)
Date: Mon, 16 Jan 2012 17:22:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116162229.GA32190@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
	<873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
	<20120113195706.GA26566@aepfle.de>
	<c7c228ea2fa1f07ffbdfbb167bec5152.squirrel@webmail.lagarcavilla.org>
	<20120116150801.GB30327@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120116150801.GB30327@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Mon, Jan 16, Olaf Hering wrote:

> I will prepare a patch to improve the check wether the ring is
> available. As you said, it can disappear any time.

Your changes to mem_event_disable() already contain the changes I would
have made as well, making changes only with the ring lock held.

Minor detail:
In mem_event_enable(), the call to mem_event_ring_lock_init() should be
moved up before the pointers are assigned to close the tiny window
between lock init and assignment.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:23:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpKh-0002pE-C7; Mon, 16 Jan 2012 16:22:55 +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 1RmpKg-0002oF-D1
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:22:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326730967!9300233!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTM0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6078 invoked from network); 16 Jan 2012 16:22:48 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Jan 2012 16:22:48 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326730967; 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=xMVa4sMii3ZxKIVadC+9C5Vidrk=;
	b=RDqPJ0ogPPvH/+jtGoiEMnozZC1QqMY4IXbt4fyZehzLMEVyiFmHTCnN/3Xp3CiAgN2
	f093pFA9dqg5RoV84jbITA+UXLw2F8XUL1q5BOPOeOXT7ABC/wEC1YnuYzFDJyFK2gqzq
	OlGWS0puZjzAwEUDFLcKPp7CHqVYR72eF5Q=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (cohen mo36) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x05549o0GFbW8s ;
	Mon, 16 Jan 2012 17:22:29 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id EF3CC18637; Mon, 16 Jan 2012 17:22:29 +0100 (CET)
Date: Mon, 16 Jan 2012 17:22:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120116162229.GA32190@aepfle.de>
References: <a85e7d46401b1d419629.1326306504@xdev.gridcentric.ca>
	<20120113095022.GA18130@aepfle.de>
	<873a666b95bbe7e50992fb1059bc2220.squirrel@webmail.lagarcavilla.org>
	<20120113195706.GA26566@aepfle.de>
	<c7c228ea2fa1f07ffbdfbb167bec5152.squirrel@webmail.lagarcavilla.org>
	<20120116150801.GB30327@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120116150801.GB30327@aepfle.de>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 Mon, Jan 16, Olaf Hering wrote:

> I will prepare a patch to improve the check wether the ring is
> available. As you said, it can disappear any time.

Your changes to mem_event_disable() already contain the changes I would
have made as well, making changes only with the ring lock held.

Minor detail:
In mem_event_enable(), the call to mem_event_ring_lock_init() should be
moved up before the pointers are assigned to close the tiny window
between lock init and assignment.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:23:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:23:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpKz-0002tg-Qb; Mon, 16 Jan 2012 16:23:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmpKy-0002s4-EZ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:23:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326730986!9298401!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21710 invoked from network); 16 Jan 2012 16:23:06 -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;
	16 Jan 2012 16:23:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:23:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 16:23:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:23:05 +0000
In-Reply-To: <20244.19813.629009.581935@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
	<20244.19379.430191.296744@mariner.uk.xensource.com>
	<1326730504.14689.17.camel@zakaz.uk.xensource.com>
	<20244.19813.629009.581935@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326730986.14689.19.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 23 of 32 RFC] libxl: use libxl_*_init
 internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:16 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 23 of 32 RFC] libxl: use libxl_*_init internally	too"):
> > I think the reason is that sometimes they might allocate memory. Many of
> > them don't (I don't know about vfb in particular) and I don't know
> > whether we prefer consistency in similar functions or avoiding pointless
> > return values (I prefer the former so as to avoid needing to change the
> > public API in the future when we find that we have introduced a way for
> > a function to fail).
> 
> Why might they need to allocate memory ?

e.g. vif->model = strdup("rtl8139").

> > Possibly in the new world order (where init ~= memset and setdefaults
> > does thework) this will no longer be the case, but then the same will
> > become true of the setdefaults function.
> 
> Yes.  I think it's OK for setdefaults to be able to fail.
> 
> Having infallible init functions is a real boon because it makes the
> caller's memory management much easier, because they can always safely
> dispose.

I think my series has made more *_init functions have no possibility of
failure but I don't think it is all of 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 Jan 16 16:23:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:23:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpKz-0002tg-Qb; Mon, 16 Jan 2012 16:23:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmpKy-0002s4-EZ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:23:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326730986!9298401!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21710 invoked from network); 16 Jan 2012 16:23:06 -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;
	16 Jan 2012 16:23:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060562"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:23:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 16:23:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:23:05 +0000
In-Reply-To: <20244.19813.629009.581935@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
	<20244.19379.430191.296744@mariner.uk.xensource.com>
	<1326730504.14689.17.camel@zakaz.uk.xensource.com>
	<20244.19813.629009.581935@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326730986.14689.19.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 23 of 32 RFC] libxl: use libxl_*_init
 internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:16 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 23 of 32 RFC] libxl: use libxl_*_init internally	too"):
> > I think the reason is that sometimes they might allocate memory. Many of
> > them don't (I don't know about vfb in particular) and I don't know
> > whether we prefer consistency in similar functions or avoiding pointless
> > return values (I prefer the former so as to avoid needing to change the
> > public API in the future when we find that we have introduced a way for
> > a function to fail).
> 
> Why might they need to allocate memory ?

e.g. vif->model = strdup("rtl8139").

> > Possibly in the new world order (where init ~= memset and setdefaults
> > does thework) this will no longer be the case, but then the same will
> > become true of the setdefaults function.
> 
> Yes.  I think it's OK for setdefaults to be able to fail.
> 
> Having infallible init functions is a real boon because it makes the
> caller's memory management much easier, because they can always safely
> dispose.

I think my series has made more *_init functions have no possibility of
failure but I don't think it is all of 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 Jan 16 16:23:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpLf-00035E-9T; Mon, 16 Jan 2012 16:23: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 1RmpLd-00033U-Mm
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:23:54 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326731026!8873825!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 11085 invoked from network); 16 Jan 2012 16:23:47 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:23:47 -0000
Received: by vbbfo1 with SMTP id fo1so11343230vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 08:23:46 -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=bGExbhUVqpCQ0JuDWwaVe5Npv0oAk30c0g/4cV9CGgE=;
	b=V91UDZpk3Yytj3qsVQsuJ75/L3H+iagJ2+N0ydWKMUTEoB9PlQLHMp1GyumPi5BQ7n
	p7GkcSFcsgu1Bi5pmZbB6I+s8bKTY67jFEJO0pOA9kVTXoaQ3/Oy6EoVD50AzytG02vB
	14L80IUnHjBHvvhRYTohAwoTf8aaTyX0w57hA=
Received: by 10.52.22.46 with SMTP id a14mr5343744vdf.102.1326731026183; Mon,
	16 Jan 2012 08:23:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.108.207 with HTTP; Mon, 16 Jan 2012 08:23:25 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 16 Jan 2012 16:23:25 +0000
Message-ID: <CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12 January 2012 14:34, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 12 Jan 2012, Jean Guyader wrote:
>> On 12/01 12:41, 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 addre=
ss
>> > in the guest.
>> >
>> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
>> Author: Jean Guyader <jean.guyader@eu.citrix.com>
>> Date: =A0 Wed Nov 23 07:53:30 2011 +0000
>>
>> =A0 =A0 qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
>>
>> =A0 =A0 The OpRegion shouldn't be mapped 1:1 because the address in the =
host
>> =A0 =A0 can't be used in the guest directly.
>>
>> =A0 =A0 This patch traps read and write access to the opregion of the In=
tel
>> =A0 =A0 GPU config space (offset 0xfc).
>>
>> =A0 =A0 To work correctly this patch needs a change in hvmloader.
>>
>> =A0 =A0 HVMloader will allocate 2 pages for the OpRegion and write this =
address
>> =A0 =A0 on the config space of the Intel GPU. Qemu will trap and map the=
 host
>> =A0 =A0 OpRegion to the guest. Any write to this offset after that won't=
 have
>> =A0 =A0 any effect. Any read of this config space offset will return the=
 address
>> =A0 =A0 in the guest.
>>
>> diff --git a/hw/pass-through.c b/hw/pass-through.c
>> index dbe8804..7ee3c61 100644
>> --- a/hw/pass-through.c
>> +++ b/hw/pass-through.c
>> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
>> =A0static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
>> =A0 =A0 =A0struct pt_reg_tbl *cfg_entry,
>> =A0 =A0 =A0uint32_t real_offset, uint32_t dev_value, uint32_t *value);
>> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
>> + =A0 =A0 =A0 =A0struct pt_reg_tbl *cfg_entry,
>> + =A0 =A0 =A0 =A0uint32_t *value, uint32_t valid_mask);
>> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
>> + =A0 =A0 =A0 =A0struct pt_reg_tbl *cfg_entry,
>> + =A0 =A0 =A0 =A0uint32_t *value, uint32_t dev_value, uint32_t valid_mas=
k);
>> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
>> + =A0 =A0 =A0 =A0struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offs=
et);
>>
>> =A0/* pt_reg_info_tbl declaration
>> =A0 * - only for emulated register (either a part or whole bit).
>> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tb=
l[] =3D {
>> =A0 =A0 =A0 =A0 =A0.u.dw.write =3D pt_exp_rom_bar_reg_write,
>> =A0 =A0 =A0 =A0 =A0.u.dw.restore =3D pt_exp_rom_bar_reg_restore,
>> =A0 =A0 =A0},
>> + =A0 =A0/* Intel IGFX OpRegion reg */
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0.offset =A0 =A0 =3D PCI_INTEL_OPREGION,
>> + =A0 =A0 =A0 =A0.size =A0 =A0 =A0 =3D 4,
>> + =A0 =A0 =A0 =A0.init_val =A0 =3D 0,
>> + =A0 =A0 =A0 =A0.no_wb =A0 =A0 =A0=3D 1,
>> + =A0 =A0 =A0 =A0.u.dw.read =A0 =3D pt_intel_opregion_read,
>> + =A0 =A0 =A0 =A0.u.dw.write =A0=3D pt_intel_opregion_write,
>> + =A0 =A0 =A0 =A0.u.dw.restore =A0=3D NULL,
>> + =A0 =A0},
>> =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0.size =3D 0,
>> =A0 =A0 =A0},
>> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_g=
rp_tbl[] =3D {
>> =A0 =A0 =A0 =A0 =A0.grp_id =A0 =A0 =3D 0xFF,
>> =A0 =A0 =A0 =A0 =A0.grp_type =A0 =3D GRP_TYPE_EMU,
>> =A0 =A0 =A0 =A0 =A0.grp_size =A0 =3D 0x40,
>> - =A0 =A0 =A0 =A0.size_init =A0=3D pt_reg_grp_size_init,
>> + =A0 =A0 =A0 =A0.size_init =A0=3D pt_reg_grp_header0_size_init,
>> =A0 =A0 =A0 =A0 =A0.emu_reg_tbl=3D pt_emu_reg_header0_tbl,
>> =A0 =A0 =A0},
>> =A0 =A0 =A0/* PCI PowerManagement Capability reg group */
>> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_de=
v *ptdev,
>> =A0 =A0 =A0return reg->init_val;
>> =A0}
>>
>> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
>> + =A0 =A0 =A0 =A0struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offs=
et)
>> +{
>> + =A0 =A0/*
>> + =A0 =A0** By default we will trap up to 0x40 in the cfg space.
>> + =A0 =A0** If an intel device is pass through we need to trap 0xfc,
>> + =A0 =A0** therefore the size should be 0xff.
>> + =A0 =A0*/
>> + =A0 =A0if (igd_passthru)
>> + =A0 =A0 =A0 =A0return 0xFF;
>> + =A0 =A0return grp_reg->grp_size;
>> +}
>
> Apart from the trivial code style error in the comment above, is this
> going to have the unintended side effect of initializing as 0 all the
> emulated registers between 0x40 and 0xff, that previously were probably
> passed through?
>

Based on how pt_find_reg_grp is implemented that doesn't make any differenc=
e.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:23:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpLf-00035E-9T; Mon, 16 Jan 2012 16:23: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 1RmpLd-00033U-Mm
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:23:54 +0000
X-Env-Sender: jean.guyader@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326731026!8873825!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 11085 invoked from network); 16 Jan 2012 16:23:47 -0000
Received: from mail-vw0-f43.google.com (HELO mail-vw0-f43.google.com)
	(209.85.212.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:23:47 -0000
Received: by vbbfo1 with SMTP id fo1so11343230vbb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 08:23:46 -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=bGExbhUVqpCQ0JuDWwaVe5Npv0oAk30c0g/4cV9CGgE=;
	b=V91UDZpk3Yytj3qsVQsuJ75/L3H+iagJ2+N0ydWKMUTEoB9PlQLHMp1GyumPi5BQ7n
	p7GkcSFcsgu1Bi5pmZbB6I+s8bKTY67jFEJO0pOA9kVTXoaQ3/Oy6EoVD50AzytG02vB
	14L80IUnHjBHvvhRYTohAwoTf8aaTyX0w57hA=
Received: by 10.52.22.46 with SMTP id a14mr5343744vdf.102.1326731026183; Mon,
	16 Jan 2012 08:23:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.108.207 with HTTP; Mon, 16 Jan 2012 08:23:25 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
From: Jean Guyader <jean.guyader@gmail.com>
Date: Mon, 16 Jan 2012 16:23:25 +0000
Message-ID: <CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <jean.guyader@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 12 January 2012 14:34, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 12 Jan 2012, Jean Guyader wrote:
>> On 12/01 12:41, 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 addre=
ss
>> > in the guest.
>> >
>> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
>> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
>> Author: Jean Guyader <jean.guyader@eu.citrix.com>
>> Date: =A0 Wed Nov 23 07:53:30 2011 +0000
>>
>> =A0 =A0 qemu-xen: Intel GPU passthrough, fix OpRegion mapping.
>>
>> =A0 =A0 The OpRegion shouldn't be mapped 1:1 because the address in the =
host
>> =A0 =A0 can't be used in the guest directly.
>>
>> =A0 =A0 This patch traps read and write access to the opregion of the In=
tel
>> =A0 =A0 GPU config space (offset 0xfc).
>>
>> =A0 =A0 To work correctly this patch needs a change in hvmloader.
>>
>> =A0 =A0 HVMloader will allocate 2 pages for the OpRegion and write this =
address
>> =A0 =A0 on the config space of the Intel GPU. Qemu will trap and map the=
 host
>> =A0 =A0 OpRegion to the guest. Any write to this offset after that won't=
 have
>> =A0 =A0 any effect. Any read of this config space offset will return the=
 address
>> =A0 =A0 in the guest.
>>
>> diff --git a/hw/pass-through.c b/hw/pass-through.c
>> index dbe8804..7ee3c61 100644
>> --- a/hw/pass-through.c
>> +++ b/hw/pass-through.c
>> @@ -238,6 +238,14 @@ static int pt_bar_reg_restore(struct pt_dev *ptdev,
>> =A0static int pt_exp_rom_bar_reg_restore(struct pt_dev *ptdev,
>> =A0 =A0 =A0struct pt_reg_tbl *cfg_entry,
>> =A0 =A0 =A0uint32_t real_offset, uint32_t dev_value, uint32_t *value);
>> +static int pt_intel_opregion_read(struct pt_dev *ptdev,
>> + =A0 =A0 =A0 =A0struct pt_reg_tbl *cfg_entry,
>> + =A0 =A0 =A0 =A0uint32_t *value, uint32_t valid_mask);
>> +static int pt_intel_opregion_write(struct pt_dev *ptdev,
>> + =A0 =A0 =A0 =A0struct pt_reg_tbl *cfg_entry,
>> + =A0 =A0 =A0 =A0uint32_t *value, uint32_t dev_value, uint32_t valid_mas=
k);
>> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
>> + =A0 =A0 =A0 =A0struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offs=
et);
>>
>> =A0/* pt_reg_info_tbl declaration
>> =A0 * - only for emulated register (either a part or whole bit).
>> @@ -444,6 +452,16 @@ static struct pt_reg_info_tbl pt_emu_reg_header0_tb=
l[] =3D {
>> =A0 =A0 =A0 =A0 =A0.u.dw.write =3D pt_exp_rom_bar_reg_write,
>> =A0 =A0 =A0 =A0 =A0.u.dw.restore =3D pt_exp_rom_bar_reg_restore,
>> =A0 =A0 =A0},
>> + =A0 =A0/* Intel IGFX OpRegion reg */
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0.offset =A0 =A0 =3D PCI_INTEL_OPREGION,
>> + =A0 =A0 =A0 =A0.size =A0 =A0 =A0 =3D 4,
>> + =A0 =A0 =A0 =A0.init_val =A0 =3D 0,
>> + =A0 =A0 =A0 =A0.no_wb =A0 =A0 =A0=3D 1,
>> + =A0 =A0 =A0 =A0.u.dw.read =A0 =3D pt_intel_opregion_read,
>> + =A0 =A0 =A0 =A0.u.dw.write =A0=3D pt_intel_opregion_write,
>> + =A0 =A0 =A0 =A0.u.dw.restore =A0=3D NULL,
>> + =A0 =A0},
>> =A0 =A0 =A0{
>> =A0 =A0 =A0 =A0 =A0.size =3D 0,
>> =A0 =A0 =A0},
>> @@ -737,7 +755,7 @@ static const struct pt_reg_grp_info_tbl pt_emu_reg_g=
rp_tbl[] =3D {
>> =A0 =A0 =A0 =A0 =A0.grp_id =A0 =A0 =3D 0xFF,
>> =A0 =A0 =A0 =A0 =A0.grp_type =A0 =3D GRP_TYPE_EMU,
>> =A0 =A0 =A0 =A0 =A0.grp_size =A0 =3D 0x40,
>> - =A0 =A0 =A0 =A0.size_init =A0=3D pt_reg_grp_size_init,
>> + =A0 =A0 =A0 =A0.size_init =A0=3D pt_reg_grp_header0_size_init,
>> =A0 =A0 =A0 =A0 =A0.emu_reg_tbl=3D pt_emu_reg_header0_tbl,
>> =A0 =A0 =A0},
>> =A0 =A0 =A0/* PCI PowerManagement Capability reg group */
>> @@ -3006,6 +3024,19 @@ static uint32_t pt_msixctrl_reg_init(struct pt_de=
v *ptdev,
>> =A0 =A0 =A0return reg->init_val;
>> =A0}
>>
>> +static uint8_t pt_reg_grp_header0_size_init(struct pt_dev *ptdev,
>> + =A0 =A0 =A0 =A0struct pt_reg_grp_info_tbl *grp_reg, uint32_t base_offs=
et)
>> +{
>> + =A0 =A0/*
>> + =A0 =A0** By default we will trap up to 0x40 in the cfg space.
>> + =A0 =A0** If an intel device is pass through we need to trap 0xfc,
>> + =A0 =A0** therefore the size should be 0xff.
>> + =A0 =A0*/
>> + =A0 =A0if (igd_passthru)
>> + =A0 =A0 =A0 =A0return 0xFF;
>> + =A0 =A0return grp_reg->grp_size;
>> +}
>
> Apart from the trivial code style error in the comment above, is this
> going to have the unintended side effect of initializing as 0 all the
> emulated registers between 0x40 and 0xff, that previously were probably
> passed through?
>

Based on how pt_find_reg_grp is implemented that doesn't make any differenc=
e.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:24:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:24:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpLo-00038n-T5; Mon, 16 Jan 2012 16:24:04 +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 1RmpLn-00036J-P7
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:24:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326731037!11129862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11977 invoked from network); 16 Jan 2012 16:23:57 -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;
	16 Jan 2012 16:23:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:23: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, 16 Jan 2012 16:23: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
	1RmpLh-0004zK-5X; Mon, 16 Jan 2012 16:23:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpLh-0005LE-4l;
	Mon, 16 Jan 2012 16:23:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20253.4325.923423@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:23:57 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <485945937a27ea1d9736.1326716099@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<485945937a27ea1d9736.1326716099@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 01 of 32 RFC] libxl: remove comment support
	from	IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 01 of 32 RFC] libxl: remove comment support from IDL"):
> libxl: remove comment support from IDL

I'm not entirely convinced by this, or at least not yet.

Are we going to eventually have an automatic docs generator and find
that this "literate" style (if I may grossly stretch the term) is what
we wanted ?

I guess the current syntax is not really suitable for going for a
literate style in the idl.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:24:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:24:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpLo-00038n-T5; Mon, 16 Jan 2012 16:24:04 +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 1RmpLn-00036J-P7
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:24:03 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326731037!11129862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11977 invoked from network); 16 Jan 2012 16:23:57 -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;
	16 Jan 2012 16:23:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060642"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:23: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, 16 Jan 2012 16:23: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
	1RmpLh-0004zK-5X; Mon, 16 Jan 2012 16:23:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpLh-0005LE-4l;
	Mon, 16 Jan 2012 16:23:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20253.4325.923423@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:23:57 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <485945937a27ea1d9736.1326716099@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<485945937a27ea1d9736.1326716099@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 01 of 32 RFC] libxl: remove comment support
	from	IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 01 of 32 RFC] libxl: remove comment support from IDL"):
> libxl: remove comment support from IDL

I'm not entirely convinced by this, or at least not yet.

Are we going to eventually have an automatic docs generator and find
that this "literate" style (if I may grossly stretch the term) is what
we wanted ?

I guess the current syntax is not really suitable for going for a
literate style in the idl.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:25:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpN5-0003Tl-Gn; Mon, 16 Jan 2012 16:25: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 1RmpN3-0003T8-Qi
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:25:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326731005!59909473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28661 invoked from network); 16 Jan 2012 16:23:25 -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;
	16 Jan 2012 16:23:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:25: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;
	Mon, 16 Jan 2012 16:25:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:25:20 +0000
In-Reply-To: <20244.19890.395440.528682@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
	<20244.19890.395440.528682@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326731120.14689.21.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 29 of 32 RFC] libxl: add named enum for
 timer	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:17 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer mode"):
> > libxl: add named enum for timer mode.
> > 
> > In order to have 0 == default the specific values are off-by-one from the
> > underlying domctl. I'm not sure I like this.
> 
> If we're abolishing the idea of memsetting infos to 0, and instead
> requiring everyone to call _init, 

I'm happy to take either approach to be honest. I imagine most _init
functions will turn into just a memset anyway at which point maybe we
should just ditch them.

I'd rather either all data types had an init or none is my only real
feeling on the matter.

> we could decree that all-bits-set means "use default value".

Do you mean in genral or just this specific field?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:25:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:25:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpN5-0003Tl-Gn; Mon, 16 Jan 2012 16:25: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 1RmpN3-0003T8-Qi
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:25:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326731005!59909473!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28661 invoked from network); 16 Jan 2012 16:23:25 -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;
	16 Jan 2012 16:23:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:25: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;
	Mon, 16 Jan 2012 16:25:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:25:20 +0000
In-Reply-To: <20244.19890.395440.528682@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
	<20244.19890.395440.528682@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326731120.14689.21.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 29 of 32 RFC] libxl: add named enum for
 timer	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:17 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer mode"):
> > libxl: add named enum for timer mode.
> > 
> > In order to have 0 == default the specific values are off-by-one from the
> > underlying domctl. I'm not sure I like this.
> 
> If we're abolishing the idea of memsetting infos to 0, and instead
> requiring everyone to call _init, 

I'm happy to take either approach to be honest. I imagine most _init
functions will turn into just a memset anyway at which point maybe we
should just ditch them.

I'd rather either all data types had an init or none is my only real
feeling on the matter.

> we could decree that all-bits-set means "use default value".

Do you mean in genral or just this specific field?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:25:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpNM-0003Yp-2F; Mon, 16 Jan 2012 16:25: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 1RmpNK-0003XH-Mx
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:25:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326731132!11112932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10263 invoked from network); 16 Jan 2012 16:25:32 -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;
	16 Jan 2012 16:25:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:25: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, 16 Jan 2012 16:25: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
	1RmpNE-0004zy-4E; Mon, 16 Jan 2012 16:25:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpNE-0005LZ-3O;
	Mon, 16 Jan 2012 16:25:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20348.91061.443779@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:25:32 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326730986.14689.19.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
	<20244.19379.430191.296744@mariner.uk.xensource.com>
	<1326730504.14689.17.camel@zakaz.uk.xensource.com>
	<20244.19813.629009.581935@mariner.uk.xensource.com>
	<1326730986.14689.19.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 23 of 32 RFC] libxl: use libxl_*_init
 internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 23 of 32 RFC] libxl: use libxl_*_init internally	too"):
> On Mon, 2012-01-16 at 16:16 +0000, Ian Jackson wrote:
> > Why might they need to allocate memory ?
> 
> e.g. vif->model = strdup("rtl8139").

That should be done in setdefault, not in init.  If for no other
reason than doing it in init means the application has to free again
this string which we pointless allocated.

> > Having infallible init functions is a real boon because it makes the
> > caller's memory management much easier, because they can always safely
> > dispose.
> 
> I think my series has made more *_init functions have no possibility of
> failure but I don't think it is all of them.

Are there any that are left that are fallible ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:25:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:25:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpNM-0003Yp-2F; Mon, 16 Jan 2012 16:25: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 1RmpNK-0003XH-Mx
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:25:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326731132!11112932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10263 invoked from network); 16 Jan 2012 16:25:32 -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;
	16 Jan 2012 16:25:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:25: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, 16 Jan 2012 16:25: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
	1RmpNE-0004zy-4E; Mon, 16 Jan 2012 16:25:32 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpNE-0005LZ-3O;
	Mon, 16 Jan 2012 16:25:32 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20348.91061.443779@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:25:32 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326730986.14689.19.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
	<20244.19379.430191.296744@mariner.uk.xensource.com>
	<1326730504.14689.17.camel@zakaz.uk.xensource.com>
	<20244.19813.629009.581935@mariner.uk.xensource.com>
	<1326730986.14689.19.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 23 of 32 RFC] libxl: use libxl_*_init
 internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 23 of 32 RFC] libxl: use libxl_*_init internally	too"):
> On Mon, 2012-01-16 at 16:16 +0000, Ian Jackson wrote:
> > Why might they need to allocate memory ?
> 
> e.g. vif->model = strdup("rtl8139").

That should be done in setdefault, not in init.  If for no other
reason than doing it in init means the application has to free again
this string which we pointless allocated.

> > Having infallible init functions is a real boon because it makes the
> > caller's memory management much easier, because they can always safely
> > dispose.
> 
> I think my series has made more *_init functions have no possibility of
> failure but I don't think it is all of them.

Are there any that are left that are fallible ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:26:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:26:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpNW-0003cG-8T; Mon, 16 Jan 2012 16:25:50 +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 1RmpNU-0003Za-0y
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:25:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326731141!9363368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32277 invoked from network); 16 Jan 2012 16:25:42 -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;
	16 Jan 2012 16:25:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059267"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:09:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:09: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
	1Rmp7b-0004tV-FC; Mon, 16 Jan 2012 16:09:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp7b-0005Hy-EL;
	Mon, 16 Jan 2012 16:09:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19379.430191.296744@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:09:23 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 23 of 32 RFC] libxl: use libxl_*_init
	internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 23 of 32 RFC] libxl: use libxl_*_init internally too"):
> libxl: use libxl_*_init internally too
...
> +    ret = libxl_device_vfb_init(CTX, vfb);
> +    if (ret) return ret;

Can we make these init functions infallible ?  (I haven't read
their code yet...)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:26:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:26:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpNW-0003cG-8T; Mon, 16 Jan 2012 16:25:50 +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 1RmpNU-0003Za-0y
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:25:48 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326731141!9363368!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32277 invoked from network); 16 Jan 2012 16:25:42 -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;
	16 Jan 2012 16:25:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10059267"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:09:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:09: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
	1Rmp7b-0004tV-FC; Mon, 16 Jan 2012 16:09:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmp7b-0005Hy-EL;
	Mon, 16 Jan 2012 16:09:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.19379.430191.296744@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:09:23 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0d3abdb6c01894e4e074.1326716121@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 23 of 32 RFC] libxl: use libxl_*_init
	internally	too
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 23 of 32 RFC] libxl: use libxl_*_init internally too"):
> libxl: use libxl_*_init internally too
...
> +    ret = libxl_device_vfb_init(CTX, vfb);
> +    if (ret) return ret;

Can we make these init functions infallible ?  (I haven't read
their code yet...)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:26:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpOB-0003qV-BV; Mon, 16 Jan 2012 16:26: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 1RmpOA-0003oa-BX
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:26:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326731183!11203146!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12225 invoked from network); 16 Jan 2012 16:26:23 -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;
	16 Jan 2012 16:26:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:26:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:26: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
	1RmpO2-00050H-Nj; Mon, 16 Jan 2012 16:26:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpO2-0005Ld-Mv;
	Mon, 16 Jan 2012 16:26:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20398.698055.75483@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:26:22 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b8426902efa002b6941a.1326716125@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<b8426902efa002b6941a.1326716125@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 27 of 32 RFC] libxl: use defbool for
	graphics	related options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 27 of 32 RFC] libxl: use defbool for graphics related options"):
> libxl: use defbool for graphics related options
...
> diff -r 81def18dfda0 -r b8426902efa0 tools/ocaml/libs/xl/xenlight_stubs.c
> --- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 16:17:49 2012 +0000
> +++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 17:04:57 2012 +0000
> @@ -130,6 +130,19 @@ static int string_string_tuple_array_val
>  
>  #endif
>  
> +/* Option type support as per http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php */
> +#define Val_none Val_int(0)
> +#define Some_val(v) Field(v,0)
...
> +static value Val_some(value v)
> +{
...

I wasn't expecting to find this at the end of 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 Mon Jan 16 16:26:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:26:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpOB-0003qV-BV; Mon, 16 Jan 2012 16:26: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 1RmpOA-0003oa-BX
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:26:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326731183!11203146!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12225 invoked from network); 16 Jan 2012 16:26:23 -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;
	16 Jan 2012 16:26:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:26:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:26: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
	1RmpO2-00050H-Nj; Mon, 16 Jan 2012 16:26:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpO2-0005Ld-Mv;
	Mon, 16 Jan 2012 16:26:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20398.698055.75483@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:26:22 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b8426902efa002b6941a.1326716125@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<b8426902efa002b6941a.1326716125@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 27 of 32 RFC] libxl: use defbool for
	graphics	related options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 27 of 32 RFC] libxl: use defbool for graphics related options"):
> libxl: use defbool for graphics related options
...
> diff -r 81def18dfda0 -r b8426902efa0 tools/ocaml/libs/xl/xenlight_stubs.c
> --- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 16:17:49 2012 +0000
> +++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 17:04:57 2012 +0000
> @@ -130,6 +130,19 @@ static int string_string_tuple_array_val
>  
>  #endif
>  
> +/* Option type support as per http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php */
> +#define Val_none Val_int(0)
> +#define Some_val(v) Field(v,0)
...
> +static value Val_some(value v)
> +{
...

I wasn't expecting to find this at the end of 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 Mon Jan 16 16:27:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpPD-000480-Ru; Mon, 16 Jan 2012 16:27: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 1RmpPB-00046U-VR
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:27:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326731120!48759843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7104 invoked from network); 16 Jan 2012 16:25:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:25:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:27: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, 16 Jan 2012 16:27: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
	1RmpP7-00050e-Bw; Mon, 16 Jan 2012 16:27:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpP7-0005Ls-BG;
	Mon, 16 Jan 2012 16:27:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20465.336196.143853@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:27:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326731120.14689.21.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
	<20244.19890.395440.528682@mariner.uk.xensource.com>
	<1326731120.14689.21.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 29 of 32 RFC] libxl: add named enum for
 timer	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer	mode"):
> I'm happy to take either approach to be honest. I imagine most _init
> functions will turn into just a memset anyway at which point maybe we
> should just ditch them.
> 
> I'd rather either all data types had an init or none is my only real
> feeling on the matter.

I absolutely agree.  (The init function could be autogenerated.)

> > we could decree that all-bits-set means "use default value".
> 
> Do you mean in genral or just this specific field?

In general.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:27:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpPD-000480-Ru; Mon, 16 Jan 2012 16:27: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 1RmpPB-00046U-VR
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:27:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326731120!48759843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7104 invoked from network); 16 Jan 2012 16:25:21 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:25:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:27: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, 16 Jan 2012 16:27: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
	1RmpP7-00050e-Bw; Mon, 16 Jan 2012 16:27:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpP7-0005Ls-BG;
	Mon, 16 Jan 2012 16:27:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20465.336196.143853@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:27:29 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326731120.14689.21.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
	<20244.19890.395440.528682@mariner.uk.xensource.com>
	<1326731120.14689.21.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 29 of 32 RFC] libxl: add named enum for
 timer	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("Re: [Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer	mode"):
> I'm happy to take either approach to be honest. I imagine most _init
> functions will turn into just a memset anyway at which point maybe we
> should just ditch them.
> 
> I'd rather either all data types had an init or none is my only real
> feeling on the matter.

I absolutely agree.  (The init function could be autogenerated.)

> > we could decree that all-bits-set means "use default value".
> 
> Do you mean in genral or just this specific field?

In general.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:28:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpPW-0004DA-AP; Mon, 16 Jan 2012 16:27: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 1RmpPU-0004B4-F9
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:27:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326731266!11231035!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17943 invoked from network); 16 Jan 2012 16:27:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:27:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:27:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:27: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
	1RmpPN-00050n-Jo; Mon, 16 Jan 2012 16:27:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpPN-0005Ly-JF;
	Mon, 16 Jan 2012 16:27:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20481.583820.669235@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:27:45 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0ef52f0b6c58344ee371.1326716111@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0ef52f0b6c58344ee371.1326716111@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 13 of 32 RFC] libxl: move HVM emulated GFX
 support into b_info->u.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

Ian Campbell writes ("[Xen-devel] [PATCH 13 of 32 RFC] libxl: move HVM emulated GFX support into b_info->u.hvm"):
> libxl: move HVM emulated GFX support into b_info->u.hvm

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:28:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:28:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpPW-0004DA-AP; Mon, 16 Jan 2012 16:27: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 1RmpPU-0004B4-F9
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:27:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326731266!11231035!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17943 invoked from network); 16 Jan 2012 16:27:46 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:27:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10060997"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:27:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:27: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
	1RmpPN-00050n-Jo; Mon, 16 Jan 2012 16:27:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpPN-0005Ly-JF;
	Mon, 16 Jan 2012 16:27:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20481.583820.669235@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:27:45 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0ef52f0b6c58344ee371.1326716111@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<0ef52f0b6c58344ee371.1326716111@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 13 of 32 RFC] libxl: move HVM emulated GFX
 support into b_info->u.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

Ian Campbell writes ("[Xen-devel] [PATCH 13 of 32 RFC] libxl: move HVM emulated GFX support into b_info->u.hvm"):
> libxl: move HVM emulated GFX support into b_info->u.hvm

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:28:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:28:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpQ3-0004MT-OY; Mon, 16 Jan 2012 16:28: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 1RmpQ2-0004KY-DP
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:28:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326731300!11139824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26575 invoked from network); 16 Jan 2012 16:28:20 -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;
	16 Jan 2012 16:28:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:28: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; Mon, 16 Jan 2012 16:28: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
	1RmpPw-000516-0v; Mon, 16 Jan 2012 16:28:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpPw-0005MA-0L;
	Mon, 16 Jan 2012 16:28:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20515.999284.901172@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:28:19 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <81def18dfda0899a8c73.1326716124@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<81def18dfda0899a8c73.1326716124@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 26 of 32 RFC] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 26 of 32 RFC] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> libxl: make boolean members of libxl_domain_create_info into libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:28:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:28:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpQ3-0004MT-OY; Mon, 16 Jan 2012 16:28: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 1RmpQ2-0004KY-DP
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:28:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326731300!11139824!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26575 invoked from network); 16 Jan 2012 16:28:20 -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;
	16 Jan 2012 16:28:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061016"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:28: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; Mon, 16 Jan 2012 16:28: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
	1RmpPw-000516-0v; Mon, 16 Jan 2012 16:28:20 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpPw-0005MA-0L;
	Mon, 16 Jan 2012 16:28:20 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20515.999284.901172@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:28:19 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <81def18dfda0899a8c73.1326716124@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<81def18dfda0899a8c73.1326716124@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 26 of 32 RFC] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 26 of 32 RFC] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> libxl: make boolean members of libxl_domain_create_info into libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:29:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpRL-0004dp-KB; Mon, 16 Jan 2012 16:29:47 +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 1RmpRJ-0004cf-SY
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:29:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326731379!2412741!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg1ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg1ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10857 invoked from network); 16 Jan 2012 16:29:39 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 16:29:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326731378; l=155;
	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=3t20ET58TJQBSlokX5ssTK8U1ag=;
	b=thtV0neHa6uRSEkZceAKzIzpFzNPNnZya8qf/Qs5Qr5rclavwMbAo8Qj3Xu1xNzOn+Q
	q5HtSNtf9A1ZMoNKVoAa5aMrMswsQTUSHMya9dNMgmwAOU60CqSXDFQzVUnBPjBtZW+JT
	HEjoH6+k5xV/iAKLLI810AbsTgJhSgV9tO4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (jimi mo25) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 206d84o0GFYI47 ;
	Mon, 16 Jan 2012 17:29:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 24C7C18637; Mon, 16 Jan 2012 17:29:26 +0100 (CET)
Date: Mon, 16 Jan 2012 17:29:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120116162925.GA32412@aepfle.de>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 21 of 32 RFC] libxl: drop vfs patch --
 fsback/front were deleted some time ago
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 16, Ian Campbell wrote:


> libxl: drop vfs patch -- fsback/front were deleted some time ago

Do you mean path instead of patch?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:29:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:29:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpRL-0004dp-KB; Mon, 16 Jan 2012 16:29:47 +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 1RmpRJ-0004cf-SY
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:29:46 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326731379!2412741!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg1ODM=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTg1ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10857 invoked from network); 16 Jan 2012 16:29:39 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 16:29:39 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326731378; l=155;
	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=3t20ET58TJQBSlokX5ssTK8U1ag=;
	b=thtV0neHa6uRSEkZceAKzIzpFzNPNnZya8qf/Qs5Qr5rclavwMbAo8Qj3Xu1xNzOn+Q
	q5HtSNtf9A1ZMoNKVoAa5aMrMswsQTUSHMya9dNMgmwAOU60CqSXDFQzVUnBPjBtZW+JT
	HEjoH6+k5xV/iAKLLI810AbsTgJhSgV9tO4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHiy0ME11M
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-095-202.pools.arcor-ip.net [88.65.95.202])
	by smtp.strato.de (jimi mo25) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 206d84o0GFYI47 ;
	Mon, 16 Jan 2012 17:29:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 24C7C18637; Mon, 16 Jan 2012 17:29:26 +0100 (CET)
Date: Mon, 16 Jan 2012 17:29:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <ian.campbell@citrix.com>
Message-ID: <20120116162925.GA32412@aepfle.de>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 21 of 32 RFC] libxl: drop vfs patch --
 fsback/front were deleted some time ago
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 16, Ian Campbell wrote:


> libxl: drop vfs patch -- fsback/front were deleted some time ago

Do you mean path instead of patch?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:30:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpRa-0004iY-Tp; Mon, 16 Jan 2012 16:30: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 1RmpRY-0004fn-KU
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:30:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326731394!9154749!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31498 invoked from network); 16 Jan 2012 16:29:54 -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;
	16 Jan 2012 16:29:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:29: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, 16 Jan 2012 16:29: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
	1RmpRS-00051Y-4Z; Mon, 16 Jan 2012 16:29:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpRS-0005MR-3m;
	Mon, 16 Jan 2012 16:29:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20607.725332.428230@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:29:51 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@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 14 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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

Ian Campbell writes ("[Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configu> libxl: HVM device configuration info build_info->u.hvm

I'm not sure I agree with this change.  In general our model is that
devices might be provided via HVM or PV interfaces but the config
doesn't distinguish.

Eg, if we implement some kind of pvusb, aren't we just going to have
to move it back ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:30:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpRa-0004iY-Tp; Mon, 16 Jan 2012 16:30: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 1RmpRY-0004fn-KU
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:30:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326731394!9154749!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31498 invoked from network); 16 Jan 2012 16:29:54 -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;
	16 Jan 2012 16:29:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:29: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, 16 Jan 2012 16:29: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
	1RmpRS-00051Y-4Z; Mon, 16 Jan 2012 16:29:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpRS-0005MR-3m;
	Mon, 16 Jan 2012 16:29:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20607.725332.428230@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:29:51 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@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 14 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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

Ian Campbell writes ("[Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configu> libxl: HVM device configuration info build_info->u.hvm

I'm not sure I agree with this change.  In general our model is that
devices might be provided via HVM or PV interfaces but the config
doesn't distinguish.

Eg, if we implement some kind of pvusb, aren't we just going to have
to move it back ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:30:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpRS-0004fK-3X; Mon, 16 Jan 2012 16:29:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmpRQ-0004do-7P
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:29:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326731386!9333100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11109 invoked from network); 16 Jan 2012 16:29:46 -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;
	16 Jan 2012 16:29:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:29: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, 16 Jan 2012 16:29:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:29:45 +0000
In-Reply-To: <20244.20253.4325.923423@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<485945937a27ea1d9736.1326716099@cosworth.uk.xensource.com>
	<20244.20253.4325.923423@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326731385.14689.25.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 01 of 32 RFC] libxl: remove comment support
 from	IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:23 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 01 of 32 RFC] libxl: remove comment support from IDL"):
> > libxl: remove comment support from IDL
> 
> I'm not entirely convinced by this, or at least not yet.
> 
> Are we going to eventually have an automatic docs generator and find
> that this "literate" style (if I may grossly stretch the term) is what
> we wanted ?

I honestly don't know.

I guess in some sense this new scheme is no different in this respect to
any other source file which we might want to extract docs from?

> I guess the current syntax is not really suitable for going for a
> literate style in the idl.

It is pretty limited/limiting.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:30:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:30:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpRS-0004fK-3X; Mon, 16 Jan 2012 16:29:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmpRQ-0004do-7P
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:29:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326731386!9333100!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11109 invoked from network); 16 Jan 2012 16:29:46 -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;
	16 Jan 2012 16:29:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:29: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, 16 Jan 2012 16:29:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:29:45 +0000
In-Reply-To: <20244.20253.4325.923423@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<485945937a27ea1d9736.1326716099@cosworth.uk.xensource.com>
	<20244.20253.4325.923423@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326731385.14689.25.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 01 of 32 RFC] libxl: remove comment support
 from	IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:23 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 01 of 32 RFC] libxl: remove comment support from IDL"):
> > libxl: remove comment support from IDL
> 
> I'm not entirely convinced by this, or at least not yet.
> 
> Are we going to eventually have an automatic docs generator and find
> that this "literate" style (if I may grossly stretch the term) is what
> we wanted ?

I honestly don't know.

I guess in some sense this new scheme is no different in this respect to
any other source file which we might want to extract docs from?

> I guess the current syntax is not really suitable for going for a
> literate style in the idl.

It is pretty limited/limiting.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:31:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpSM-0004xU-GW; Mon, 16 Jan 2012 16:30: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 1RmpSL-0004vz-1c
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:30:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326731442!11130636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20114 invoked from network); 16 Jan 2012 16:30:43 -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;
	16 Jan 2012 16:30:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:30: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, 16 Jan 2012 16:30: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
	1RmpSE-00051v-G9; Mon, 16 Jan 2012 16:30:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpSE-0005Mh-FY;
	Mon, 16 Jan 2012 16:30:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20658.300427.528263@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:30:42 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326731385.14689.25.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<485945937a27ea1d9736.1326716099@cosworth.uk.xensource.com>
	<20244.20253.4325.923423@mariner.uk.xensource.com>
	<1326731385.14689.25.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 01 of 32 RFC] libxl: remove comment support
 from	IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 01 of 32 RFC] libxl: remove comment support from	IDL"):
> On Mon, 2012-01-16 at 16:23 +0000, Ian Jackson wrote:
> > Are we going to eventually have an automatic docs generator and find
> > that this "literate" style (if I may grossly stretch the term) is what
> > we wanted ?
> 
> I honestly don't know.
> 
> I guess in some sense this new scheme is no different in this respect to
> any other source file which we might want to extract docs from?
> 
> > I guess the current syntax is not really suitable for going for a
> > literate style in the idl.
> 
> It is pretty limited/limiting.

OK, I think this will do for now.  Certainly the comments you're
removing aren't valuable, so

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:31:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpSM-0004xU-GW; Mon, 16 Jan 2012 16:30: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 1RmpSL-0004vz-1c
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:30:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326731442!11130636!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20114 invoked from network); 16 Jan 2012 16:30:43 -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;
	16 Jan 2012 16:30:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:30: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, 16 Jan 2012 16:30: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
	1RmpSE-00051v-G9; Mon, 16 Jan 2012 16:30:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpSE-0005Mh-FY;
	Mon, 16 Jan 2012 16:30:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20658.300427.528263@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:30:42 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326731385.14689.25.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<485945937a27ea1d9736.1326716099@cosworth.uk.xensource.com>
	<20244.20253.4325.923423@mariner.uk.xensource.com>
	<1326731385.14689.25.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 01 of 32 RFC] libxl: remove comment support
 from	IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 01 of 32 RFC] libxl: remove comment support from	IDL"):
> On Mon, 2012-01-16 at 16:23 +0000, Ian Jackson wrote:
> > Are we going to eventually have an automatic docs generator and find
> > that this "literate" style (if I may grossly stretch the term) is what
> > we wanted ?
> 
> I honestly don't know.
> 
> I guess in some sense this new scheme is no different in this respect to
> any other source file which we might want to extract docs from?
> 
> > I guess the current syntax is not really suitable for going for a
> > literate style in the idl.
> 
> It is pretty limited/limiting.

OK, I think this will do for now.  Certainly the comments you're
removing aren't valuable, so

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:31:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpSb-00051x-U3; Mon, 16 Jan 2012 16:31: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 1RmpSa-0004zn-M5
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:31:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326731458!5140522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28405 invoked from network); 16 Jan 2012 16:30:58 -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;
	16 Jan 2012 16:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:30:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:30: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
	1RmpSU-000522-2q; Mon, 16 Jan 2012 16:30:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpSU-0005Ml-27;
	Mon, 16 Jan 2012 16:30:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20674.52120.949057@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:30:58 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1e558d62909f4f236bb5.1326716118@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<1e558d62909f4f236bb5.1326716118@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 32 RFC] libxl:
	remove	libxl_device_model_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 20 of 32 RFC] libxl: remove libxl_device_model_info"):
> libxl: remove libxl_device_model_info.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:31:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpSb-00051x-U3; Mon, 16 Jan 2012 16:31: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 1RmpSa-0004zn-M5
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:31:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326731458!5140522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28405 invoked from network); 16 Jan 2012 16:30:58 -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;
	16 Jan 2012 16:30:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061122"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:30:58 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:30: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
	1RmpSU-000522-2q; Mon, 16 Jan 2012 16:30:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpSU-0005Ml-27;
	Mon, 16 Jan 2012 16:30:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20674.52120.949057@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:30:58 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1e558d62909f4f236bb5.1326716118@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<1e558d62909f4f236bb5.1326716118@cosworth.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 20 of 32 RFC] libxl:
	remove	libxl_device_model_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 20 of 32 RFC] libxl: remove libxl_device_model_info"):
> libxl: remove libxl_device_model_info.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:32:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpTr-0005LK-R0; Mon, 16 Jan 2012 16:32: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 1RmpTp-0005Kc-Dg
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:32:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326731500!56162210!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6400 invoked from network); 16 Jan 2012 16:31:40 -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;
	16 Jan 2012 16:31:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061151"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:31:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:31: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
	1RmpTF-00052L-Ms; Mon, 16 Jan 2012 16:31:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpTF-0005My-MG;
	Mon, 16 Jan 2012 16:31:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20721.659130.654696@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:31:45 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <87c469583499236e6a52.1326716123@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<87c469583499236e6a52.1326716123@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 25 of 32 RFC] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 25 of 32 RFC] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> libxl: make boolean members of libxl_domain_create_info into libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Modulo a decision about the representation of "default".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:32:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpTr-0005LK-R0; Mon, 16 Jan 2012 16:32: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 1RmpTp-0005Kc-Dg
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:32:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326731500!56162210!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6400 invoked from network); 16 Jan 2012 16:31:40 -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;
	16 Jan 2012 16:31:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061151"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:31:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:31: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
	1RmpTF-00052L-Ms; Mon, 16 Jan 2012 16:31:45 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpTF-0005My-MG;
	Mon, 16 Jan 2012 16:31:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.20721.659130.654696@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:31:45 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <87c469583499236e6a52.1326716123@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<87c469583499236e6a52.1326716123@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 25 of 32 RFC] libxl: make boolean members of
 libxl_domain_create_info into libxl_defbool
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[Xen-devel] [PATCH 25 of 32 RFC] libxl: make boolean members of libxl_domain_create_info into libxl_defbool"):
> libxl: make boolean members of libxl_domain_create_info into libxl_defbool

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Modulo a decision about the representation of "default".

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmpbc-0005rZ-9q; Mon, 16 Jan 2012 16:40: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 1Rmpba-0005rU-M1
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:40:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326732015!11074073!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15248 invoked from network); 16 Jan 2012 16:40:16 -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;
	16 Jan 2012 16:40:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:40: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, 16 Jan 2012 16:40:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:40:11 +0000
In-Reply-To: <20244.20398.698055.75483@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<b8426902efa002b6941a.1326716125@cosworth.uk.xensource.com>
	<20244.20398.698055.75483@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326732011.14689.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 27 of 32 RFC] libxl: use defbool for
 graphics	related options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:26 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 27 of 32 RFC] libxl: use defbool for graphics related options"):
> > libxl: use defbool for graphics related options
> ...
> > diff -r 81def18dfda0 -r b8426902efa0 tools/ocaml/libs/xl/xenlight_stubs.c
> > --- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 16:17:49 2012 +0000
> > +++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 17:04:57 2012 +0000
> > @@ -130,6 +130,19 @@ static int string_string_tuple_array_val
> >  
> >  #endif
> >  
> > +/* Option type support as per http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php */
> > +#define Val_none Val_int(0)
> > +#define Some_val(v) Field(v,0)
> ...
> > +static value Val_some(value v)
> > +{
> ...
> 
> I wasn't expecting to find this at the end of this patch.

I think this is the first time a struct which is covered by the ocaml
stubs used a defbool.

It's tricky to do this in a staged manner because you get all sorts of
"unused static function" warnings.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:40:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmpbc-0005rZ-9q; Mon, 16 Jan 2012 16:40: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 1Rmpba-0005rU-M1
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:40:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326732015!11074073!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15248 invoked from network); 16 Jan 2012 16:40:16 -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;
	16 Jan 2012 16:40:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:40: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, 16 Jan 2012 16:40:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:40:11 +0000
In-Reply-To: <20244.20398.698055.75483@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<b8426902efa002b6941a.1326716125@cosworth.uk.xensource.com>
	<20244.20398.698055.75483@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326732011.14689.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 27 of 32 RFC] libxl: use defbool for
 graphics	related options
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:26 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 27 of 32 RFC] libxl: use defbool for graphics related options"):
> > libxl: use defbool for graphics related options
> ...
> > diff -r 81def18dfda0 -r b8426902efa0 tools/ocaml/libs/xl/xenlight_stubs.c
> > --- a/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 16:17:49 2012 +0000
> > +++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Fri Jan 13 17:04:57 2012 +0000
> > @@ -130,6 +130,19 @@ static int string_string_tuple_array_val
> >  
> >  #endif
> >  
> > +/* Option type support as per http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php */
> > +#define Val_none Val_int(0)
> > +#define Some_val(v) Field(v,0)
> ...
> > +static value Val_some(value v)
> > +{
> ...
> 
> I wasn't expecting to find this at the end of this patch.

I think this is the first time a struct which is covered by the ocaml
stubs used a defbool.

It's tricky to do this in a staged manner because you get all sorts of
"unused static function" warnings.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:41:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpcQ-0005vu-Nu; Mon, 16 Jan 2012 16:41: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 1RmpcP-0005uy-CW
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:41:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326732063!11133531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7128 invoked from network); 16 Jan 2012 16:41:03 -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;
	16 Jan 2012 16:41:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:41: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, 16 Jan 2012 16:41:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 16 Jan 2012 16:41:02 +0000
In-Reply-To: <20120116162925.GA32412@aepfle.de>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
	<20120116162925.GA32412@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326732063.14689.28.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 21 of 32 RFC] libxl: drop vfs patch --
 fsback/front were deleted some time ago
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:29 +0000, Olaf Hering wrote:
> On Mon, Jan 16, Ian Campbell wrote:
> 
> 
> > libxl: drop vfs patch -- fsback/front were deleted some time ago
> 
> Do you mean path instead of patch?

Yes I did, finger macros got in the way.

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 Jan 16 16:41:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpcQ-0005vu-Nu; Mon, 16 Jan 2012 16:41: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 1RmpcP-0005uy-CW
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:41:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326732063!11133531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7128 invoked from network); 16 Jan 2012 16:41:03 -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;
	16 Jan 2012 16:41:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061447"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:41: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, 16 Jan 2012 16:41:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Mon, 16 Jan 2012 16:41:02 +0000
In-Reply-To: <20120116162925.GA32412@aepfle.de>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
	<20120116162925.GA32412@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326732063.14689.28.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 21 of 32 RFC] libxl: drop vfs patch --
 fsback/front were deleted some time ago
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:29 +0000, Olaf Hering wrote:
> On Mon, Jan 16, Ian Campbell wrote:
> 
> 
> > libxl: drop vfs patch -- fsback/front were deleted some time ago
> 
> Do you mean path instead of patch?

Yes I did, finger macros got in the way.

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 Jan 16 16:47:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpiO-0006FC-K6; Mon, 16 Jan 2012 16:47: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 1RmpiN-0006Es-6d
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:47:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326732436!9157588!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27342 invoked from network); 16 Jan 2012 16:47:16 -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;
	16 Jan 2012 16:47:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:46: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, 16 Jan 2012 16:46:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:46:44 +0000
In-Reply-To: <20244.20607.725332.428230@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
	<20244.20607.725332.428230@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326732404.14689.34.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 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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 Mon, 2012-01-16 at 16:29 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configu> libxl: HVM device configuration info build_info->u.hvm
> 
> I'm not sure I agree with this change.

There were several things that I wasn't sure about the placement of. I
just knew that device_model_info was wrong ;-)

>   In general our model is that
> devices might be provided via HVM or PV interfaces but the config
> doesn't distinguish.
> 
> Eg, if we implement some kind of pvusb, aren't we just going to have
> to move it back ?

On the one hand I agree.

On the other hand these particular two USB options are very thin shims
over the equivalent qemu options and do not contain anything like the
necessary richness to allow them to describe a device in the detail
needed to be a first class thing in the IDL. I suspect that if/when we
have PVUSB we will gain libxl_device_usb as a thing which is completely
orthogonal to these two.

I think a similar argument applies to the audio option?

Boot, Serial and the platform PCI options are pretty HVM specific I
think.

While we are at it -- do you have any thoughts on how per-arch options
should be handled? I was thinking of adding the possibility in the IDL
to tag a field with a list of architectures?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:47:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:47:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpiO-0006FC-K6; Mon, 16 Jan 2012 16:47: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 1RmpiN-0006Es-6d
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:47:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326732436!9157588!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27342 invoked from network); 16 Jan 2012 16:47:16 -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;
	16 Jan 2012 16:47:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10061887"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:46: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, 16 Jan 2012 16:46:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 16:46:44 +0000
In-Reply-To: <20244.20607.725332.428230@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
	<20244.20607.725332.428230@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326732404.14689.34.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 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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 Mon, 2012-01-16 at 16:29 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configu> libxl: HVM device configuration info build_info->u.hvm
> 
> I'm not sure I agree with this change.

There were several things that I wasn't sure about the placement of. I
just knew that device_model_info was wrong ;-)

>   In general our model is that
> devices might be provided via HVM or PV interfaces but the config
> doesn't distinguish.
> 
> Eg, if we implement some kind of pvusb, aren't we just going to have
> to move it back ?

On the one hand I agree.

On the other hand these particular two USB options are very thin shims
over the equivalent qemu options and do not contain anything like the
necessary richness to allow them to describe a device in the detail
needed to be a first class thing in the IDL. I suspect that if/when we
have PVUSB we will gain libxl_device_usb as a thing which is completely
orthogonal to these two.

I think a similar argument applies to the audio option?

Boot, Serial and the platform PCI options are pretty HVM specific I
think.

While we are at it -- do you have any thoughts on how per-arch options
should be handled? I was thinking of adding the possibility in the IDL
to tag a field with a list of architectures?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:50:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmplI-0006Nz-7M; Mon, 16 Jan 2012 16:50: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 1RmplG-0006Nr-O0
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:50:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326732606!8589173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29865 invoked from network); 16 Jan 2012 16:50:16 -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;
	16 Jan 2012 16:50:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:49: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, 16 Jan 2012 16:49: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
	1Rmpks-00058N-Vv; Mon, 16 Jan 2012 16:49:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmpks-00013b-Rh;
	Mon, 16 Jan 2012 16:49:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.21814.845883.780844@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:49:58 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d5c8efa9ef9e55a08e06.1326716102@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<d5c8efa9ef9e55a08e06.1326716102@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 04 of 32] ocaml: Correct ocaml type name for
 Aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 04 of 32] ocaml: Correct ocaml type name for Aggregate types"):
> ocaml: Correct ocaml type name for Aggregate types.
> 
> No change to the generated code because this path isn't used yet.
> 
> 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 Mon Jan 16 16:50:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:50:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmplI-0006Nz-7M; Mon, 16 Jan 2012 16:50: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 1RmplG-0006Nr-O0
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:50:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326732606!8589173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29865 invoked from network); 16 Jan 2012 16:50:16 -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;
	16 Jan 2012 16:50:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062017"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:49: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, 16 Jan 2012 16:49: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
	1Rmpks-00058N-Vv; Mon, 16 Jan 2012 16:49:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmpks-00013b-Rh;
	Mon, 16 Jan 2012 16:49:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.21814.845883.780844@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:49:58 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <d5c8efa9ef9e55a08e06.1326716102@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<d5c8efa9ef9e55a08e06.1326716102@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 04 of 32] ocaml: Correct ocaml type name for
 Aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 04 of 32] ocaml: Correct ocaml type name for Aggregate types"):
> ocaml: Correct ocaml type name for Aggregate types.
> 
> No change to the generated code because this path isn't used yet.
> 
> 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 Mon Jan 16 16:51:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1Rmply-0006Rb-LU; Mon, 16 Jan 2012 16:51: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 1Rmplx-0006R5-Jl
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:51:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326732659!8877788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21249 invoked from network); 16 Jan 2012 16:50: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;
	16 Jan 2012 16:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062036"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:50: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, 16 Jan 2012 16:50: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
	1Rmplq-00058o-Tl; Mon, 16 Jan 2012 16:50:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmplq-00013s-SX;
	Mon, 16 Jan 2012 16:50:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.21874.852622.418848@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:50:58 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@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 21 of 32] libxl: drop vfs patch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 21 of 32] libxl: drop vfs patch"):
> libxl: drop vfs path -- fsback/front were deleted some time ago
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

I was going to apply this, but it doesn't fit in the current tree.  I
guess the context is updated by earlier patches in your series.  So
for now:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:51:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1Rmply-0006Rb-LU; Mon, 16 Jan 2012 16:51: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 1Rmplx-0006R5-Jl
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:51:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326732659!8877788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21249 invoked from network); 16 Jan 2012 16:50: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;
	16 Jan 2012 16:50:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062036"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:50: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, 16 Jan 2012 16:50: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
	1Rmplq-00058o-Tl; Mon, 16 Jan 2012 16:50:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmplq-00013s-SX;
	Mon, 16 Jan 2012 16:50:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.21874.852622.418848@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:50:58 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@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 21 of 32] libxl: drop vfs patch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 21 of 32] libxl: drop vfs patch"):
> libxl: drop vfs path -- fsback/front were deleted some time ago
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

I was going to apply this, but it doesn't fit in the current tree.  I
guess the context is updated by earlier patches in your series.  So
for now:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:52:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmpmf-0006WX-3X; Mon, 16 Jan 2012 16:51:49 +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 1Rmpmc-0006Vb-TS
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:51:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326732700!9372096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5060 invoked from network); 16 Jan 2012 16:51:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:51:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:51:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:51:40 +0000
Date: Mon, 16 Jan 2012 16:52:20 +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.1201161606280.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 0/7] build upstream qemu and 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

Hi all,
this is the tenth version of the patch series to introduce upstream qemu
and seabios in the xen-unstable build system.

Changes to v9:

- rename QEMU_UPSTREAM_TAG to QEMU_UPSTREAM_REVISION: we are going to
use it with a branch name by default;

- set QEMU_UPSTREAM_REVISION to "master" by default;

- set SEABIOS_UPSTREAM_URL to git://xenbits.xen.org/seabios.git by
default;

- add a patch to update MAINTAINERS.


Changes to v8:

- build upstream qemu out of tree;

- add a tools/qemu-xen-dir-force-update target;

- add a tools/firmware/seabios-dir-force-update target;

- call make install from subdir-all and subdir-install
qemu-xen-traditional and qemu-xen targets; 

- fix a typo in patch #5;


Changes to v7:

- call upstream qemu's configure script right before building qemu and
after building libxc and xenstore because it needs them;

- introduce a new patch to move the call to xen-setup after building
libxc and xenstore for consistency with upstream qemu;

- fix a typo in tools/Makefile (patch #4);


Changes to v6:

- add "set -e" to git-checkout.sh;

- add argument count check to git-checkout.sh;

- remove spurious semicolons in git-checkout.sh.


Changes to v5:

- use $GIT in git-checkout.sh;

- add an http mirror for seabios;

- use $(LIBEXEC) to configure upstream qemu;

- append a patch for libxenlight to find the upstream qemu binary under
$(LIBEXEC).


Changes to v4:

- remove an obsolete comment;

- use /bin/sh to execute git-checkout.sh rathen than /bin/bash.


Changes to v3:

- reduce the scope of git-checkout.sh, now it only does what the name
says; calling "configure" is responsibility of the caller. As a result
of this change, the build still works when the user specifies a local
directory in the CONFIG_QEMU environmental variable;

- use a more official qemu repository hosted on xenbits;

- use a changeset as QEMU_UPSTREAM_TAG rather than a branch name.



Changes to v2:

- move tools/git-checkout.sh to scripts/git-checkout.sh;

- use git-checkout.sh for seabios;

- improve seabios integration with tools/firmware make system;

- add qemu-xen-traditional, qemu-xen and seabios dir entries to
.hgignore.



Changes to v1:

- always build upstream qemu and seabios, rather than introducing them
as an option.


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:52:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmpmf-0006WX-3X; Mon, 16 Jan 2012 16:51:49 +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 1Rmpmc-0006Vb-TS
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:51:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326732700!9372096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5060 invoked from network); 16 Jan 2012 16:51:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:51:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062070"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:51:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:51:40 +0000
Date: Mon, 16 Jan 2012 16:52:20 +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.1201161606280.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 0/7] build upstream qemu and 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

Hi all,
this is the tenth version of the patch series to introduce upstream qemu
and seabios in the xen-unstable build system.

Changes to v9:

- rename QEMU_UPSTREAM_TAG to QEMU_UPSTREAM_REVISION: we are going to
use it with a branch name by default;

- set QEMU_UPSTREAM_REVISION to "master" by default;

- set SEABIOS_UPSTREAM_URL to git://xenbits.xen.org/seabios.git by
default;

- add a patch to update MAINTAINERS.


Changes to v8:

- build upstream qemu out of tree;

- add a tools/qemu-xen-dir-force-update target;

- add a tools/firmware/seabios-dir-force-update target;

- call make install from subdir-all and subdir-install
qemu-xen-traditional and qemu-xen targets; 

- fix a typo in patch #5;


Changes to v7:

- call upstream qemu's configure script right before building qemu and
after building libxc and xenstore because it needs them;

- introduce a new patch to move the call to xen-setup after building
libxc and xenstore for consistency with upstream qemu;

- fix a typo in tools/Makefile (patch #4);


Changes to v6:

- add "set -e" to git-checkout.sh;

- add argument count check to git-checkout.sh;

- remove spurious semicolons in git-checkout.sh.


Changes to v5:

- use $GIT in git-checkout.sh;

- add an http mirror for seabios;

- use $(LIBEXEC) to configure upstream qemu;

- append a patch for libxenlight to find the upstream qemu binary under
$(LIBEXEC).


Changes to v4:

- remove an obsolete comment;

- use /bin/sh to execute git-checkout.sh rathen than /bin/bash.


Changes to v3:

- reduce the scope of git-checkout.sh, now it only does what the name
says; calling "configure" is responsibility of the caller. As a result
of this change, the build still works when the user specifies a local
directory in the CONFIG_QEMU environmental variable;

- use a more official qemu repository hosted on xenbits;

- use a changeset as QEMU_UPSTREAM_TAG rather than a branch name.



Changes to v2:

- move tools/git-checkout.sh to scripts/git-checkout.sh;

- use git-checkout.sh for seabios;

- improve seabios integration with tools/firmware make system;

- add qemu-xen-traditional, qemu-xen and seabios dir entries to
.hgignore.



Changes to v1:

- always build upstream qemu and seabios, rather than introducing them
as an option.


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:52:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpnN-0006d9-MG; Mon, 16 Jan 2012 16:52: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 1RmpnM-0006bv-ND
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326732744!11146270!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5858 invoked from network); 16 Jan 2012 16:52:26 -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 Jan 2012 16:52:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="177722850"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0GGqGMD000346;
	Mon, 16 Jan 2012 08:52:17 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:49 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 1/7] Introduce git-checkout.sh
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Introduce a script to perform git checkout on an external git tree; use
git-checkout.sh in ioemu-dir-find.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore               |    2 +-
 scripts/git-checkout.sh |   27 +++++++++++++++++++++++++++
 tools/Makefile          |   20 ++++----------------
 3 files changed, 32 insertions(+), 17 deletions(-)
 create mode 100755 scripts/git-checkout.sh

diff --git a/.hgignore b/.hgignore
index 87d8ef7..3145eee 100644
--- a/.hgignore
+++ b/.hgignore
@@ -296,7 +296,7 @@
 ^tools/xm-test/lib/XmTestLib/config.py$
 ^tools/xm-test/lib/XmTestReport/xmtest.py$
 ^tools/xm-test/tests/.*\.test$
-^tools/ioemu-remote
+^tools/ioemu-dir-remote
 ^tools/ioemu-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh
new file mode 100755
index 0000000..15b3ce9
--- /dev/null
+++ b/scripts/git-checkout.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+if test $# -lt 3; then
+	echo "Usage: $0 <tree> <tag> <dir>"
+	exit 1
+fi
+
+TREE=$1
+TAG=$2
+DIR=$3
+
+set -e
+
+if test \! -d $DIR-remote; then
+	rm -rf $DIR-remote $DIR-remote.tmp
+	mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp
+	$GIT clone $TREE $DIR-remote.tmp
+	if test "$TAG" ; then
+		cd $DIR-remote.tmp
+		$GIT branch -D dummy >/dev/null 2>&1 ||:
+		$GIT checkout -b dummy $TAG
+		cd ..
+	fi
+	mv $DIR-remote.tmp $DIR-remote
+fi
+rm -f $DIR
+ln -sf $DIR-remote $DIR
diff --git a/tools/Makefile b/tools/Makefile
index 443ee7f..7f5ee3e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -75,7 +75,7 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean
-	rm -rf ioemu-dir ioemu-remote
+	rm -rf ioemu-dir ioemu-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -93,20 +93,8 @@ ioemu-dir-find:
 	if test -d $(CONFIG_QEMU); then \
 		mkdir -p ioemu-dir; \
 	else \
-		if [ ! -d ioemu-remote ]; then \
-			rm -rf ioemu-remote ioemu-remote.tmp; \
-			mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \
-			$(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \
-			if [ "$(QEMU_TAG)" ]; then			\
-				cd ioemu-remote.tmp;			\
-				$(GIT) branch -D dummy >/dev/null 2>&1 ||:; \
-				$(GIT) checkout -b dummy $(QEMU_TAG);	\
-				cd ..;					\
-			fi;						\
-			mv ioemu-remote.tmp ioemu-remote; \
-		fi; \
-		rm -f ioemu-dir; \
-		ln -sf ioemu-remote ioemu-dir; \
+		export GIT=$(GIT); \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
 	fi
 	set -e; \
 		$(buildmakevars2shellvars); \
@@ -117,7 +105,7 @@ ioemu-dir-find:
 ioemu-dir-force-update:
 	set -ex; \
 	if [ "$(QEMU_TAG)" ]; then \
-		cd ioemu-remote; \
+		cd ioemu-dir-remote; \
 		$(GIT) fetch origin; \
 		$(GIT) reset --hard $(QEMU_TAG); \
 	fi
-- 
1.7.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 Jan 16 16:52:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpnN-0006d9-MG; Mon, 16 Jan 2012 16:52: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 1RmpnM-0006bv-ND
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326732744!11146270!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5858 invoked from network); 16 Jan 2012 16:52:26 -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 Jan 2012 16:52:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="177722850"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0GGqGMD000346;
	Mon, 16 Jan 2012 08:52:17 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:49 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 1/7] Introduce git-checkout.sh
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Introduce a script to perform git checkout on an external git tree; use
git-checkout.sh in ioemu-dir-find.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore               |    2 +-
 scripts/git-checkout.sh |   27 +++++++++++++++++++++++++++
 tools/Makefile          |   20 ++++----------------
 3 files changed, 32 insertions(+), 17 deletions(-)
 create mode 100755 scripts/git-checkout.sh

diff --git a/.hgignore b/.hgignore
index 87d8ef7..3145eee 100644
--- a/.hgignore
+++ b/.hgignore
@@ -296,7 +296,7 @@
 ^tools/xm-test/lib/XmTestLib/config.py$
 ^tools/xm-test/lib/XmTestReport/xmtest.py$
 ^tools/xm-test/tests/.*\.test$
-^tools/ioemu-remote
+^tools/ioemu-dir-remote
 ^tools/ioemu-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh
new file mode 100755
index 0000000..15b3ce9
--- /dev/null
+++ b/scripts/git-checkout.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+if test $# -lt 3; then
+	echo "Usage: $0 <tree> <tag> <dir>"
+	exit 1
+fi
+
+TREE=$1
+TAG=$2
+DIR=$3
+
+set -e
+
+if test \! -d $DIR-remote; then
+	rm -rf $DIR-remote $DIR-remote.tmp
+	mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp
+	$GIT clone $TREE $DIR-remote.tmp
+	if test "$TAG" ; then
+		cd $DIR-remote.tmp
+		$GIT branch -D dummy >/dev/null 2>&1 ||:
+		$GIT checkout -b dummy $TAG
+		cd ..
+	fi
+	mv $DIR-remote.tmp $DIR-remote
+fi
+rm -f $DIR
+ln -sf $DIR-remote $DIR
diff --git a/tools/Makefile b/tools/Makefile
index 443ee7f..7f5ee3e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -75,7 +75,7 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean
-	rm -rf ioemu-dir ioemu-remote
+	rm -rf ioemu-dir ioemu-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -93,20 +93,8 @@ ioemu-dir-find:
 	if test -d $(CONFIG_QEMU); then \
 		mkdir -p ioemu-dir; \
 	else \
-		if [ ! -d ioemu-remote ]; then \
-			rm -rf ioemu-remote ioemu-remote.tmp; \
-			mkdir ioemu-remote.tmp; rmdir ioemu-remote.tmp; \
-			$(GIT) clone $(CONFIG_QEMU) ioemu-remote.tmp; \
-			if [ "$(QEMU_TAG)" ]; then			\
-				cd ioemu-remote.tmp;			\
-				$(GIT) branch -D dummy >/dev/null 2>&1 ||:; \
-				$(GIT) checkout -b dummy $(QEMU_TAG);	\
-				cd ..;					\
-			fi;						\
-			mv ioemu-remote.tmp ioemu-remote; \
-		fi; \
-		rm -f ioemu-dir; \
-		ln -sf ioemu-remote ioemu-dir; \
+		export GIT=$(GIT); \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
 	fi
 	set -e; \
 		$(buildmakevars2shellvars); \
@@ -117,7 +105,7 @@ ioemu-dir-find:
 ioemu-dir-force-update:
 	set -ex; \
 	if [ "$(QEMU_TAG)" ]; then \
-		cd ioemu-remote; \
+		cd ioemu-dir-remote; \
 		$(GIT) fetch origin; \
 		$(GIT) reset --hard $(QEMU_TAG); \
 	fi
-- 
1.7.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 Jan 16 16:52:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpnV-0006g1-P0; Mon, 16 Jan 2012 16: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 1RmpnT-0006dN-Uu
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326732749!9188741!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25540 invoked from network); 16 Jan 2012 16:52:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="20927699"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMG000346;
	Mon, 16 Jan 2012 08:52:21 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:52 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 4/7] Clone and build upstream Qemu 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

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore      |    2 ++
 Config.mk      |    7 +++++++
 Makefile       |    9 ++++++++-
 tools/Makefile |   44 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 61 insertions(+), 1 deletions(-)

diff --git a/.hgignore b/.hgignore
index 4b773c3..cbcc0f5 100644
--- a/.hgignore
+++ b/.hgignore
@@ -298,6 +298,8 @@
 ^tools/xm-test/tests/.*\.test$
 ^tools/qemu-xen-traditional-dir-remote
 ^tools/qemu-xen-traditional-dir$
+^tools/qemu-xen-dir-remote
+^tools/qemu-xen-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Config.mk b/Config.mk
index 1c229c0..d229ab6 100644
--- a/Config.mk
+++ b/Config.mk
@@ -202,6 +202,13 @@ else
 QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git
 endif
 
+ifeq ($(GIT_HTTP),y)
+QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
+else
+QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+endif
+QEMU_UPSTREAM_REVISION ?= master
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/Makefile b/Makefile
index c0197a5..edc5e3d 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/qemu-xen-traditional-dir
+install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir
 endif
 
 .PHONY: install-kernels
@@ -91,6 +91,13 @@ tools/qemu-xen-traditional-dir:
 tools/qemu-xen-traditional-dir-force-update:
 	$(MAKE) -C tools qemu-xen-traditional-dir-force-update
 
+tools/qemu-xen-dir:
+	$(MAKE) -C tools qemu-xen-dir-find
+
+.PHONY: tools/qemu-xen-dir-force-update
+tools/qemu-xen-dir-force-update:
+	$(MAKE) -C tools qemu-xen-dir-force-update
+
 .PHONY: install-docs
 install-docs:
 	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
diff --git a/tools/Makefile b/tools/Makefile
index 3ff1ed1..03ac66f 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -36,6 +36,7 @@ SUBDIRS-y += libvchan
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
 SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
+SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir
 endif
 
 SUBDIRS-y += xenpmd
@@ -76,6 +77,7 @@ clean: subdirs-clean
 .PHONY: distclean
 distclean: subdirs-distclean
 	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
+	rm -rf qemu-xen-dir qemu-xen-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -97,6 +99,14 @@ qemu-xen-traditional-dir-find:
 		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
 
+qemu-xen-dir-find:
+	if test -d $(QEMU_UPSTREAM_URL) ; then \
+		mkdir -p qemu-xen-dir; \
+	else \
+		export GIT=$(GIT); \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_REVISION) qemu-xen-dir ; \
+	fi
+
 .PHONY: qemu-xen-traditional-dir-force-update
 qemu-xen-traditional-dir-force-update:
 	set -ex; \
@@ -119,6 +129,40 @@ subdir-clean-qemu-xen-traditional-dir:
 		$(MAKE) -C qemu-xen-traditional-dir clean; \
 	fi
 
+.PHONY: qemu-xen-dir-force-update
+qemu-xen-dir-force-update:
+	set -ex; \
+	if [ "$(QEMU_UPSTREAM_REVISION)" ]; then \
+		cd qemu-xen-dir-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(QEMU_UPSTREAM_REVISION); \
+	fi
+
+subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find
+	if test -d $(QEMU_UPSTREAM_URL) ; then \
+		source=$(QEMU_UPSTREAM_URL); \
+	else \
+		source=.; \
+	fi; \
+	cd qemu-xen-dir; \
+	$$source/configure --enable-xen --target-list=i386-softmmu \
+		--source-path=$$source \
+		--extra-cflags="-I$(XEN_ROOT)/tools/include \
+		-I$(XEN_ROOT)/tools/libxc \
+		-I$(XEN_ROOT)/tools/xenstore" \
+		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
+		-L$(XEN_ROOT)/tools/xenstore" \
+		--bindir=$(LIBEXEC) \
+		--disable-kvm \
+		$(IOEMU_CONFIGURE_CROSS); \
+	$(MAKE) install
+
+subdir-clean-qemu-xen-dir:
+	set -e; if test -d qemu-xen-dir/.; then \
+		$(buildmakevars2shellvars); \
+		$(MAKE) -C qemu-xen-dir clean; \
+	fi
+
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
 	$(MAKE) -C debugger/gdbsx clean
 
-- 
1.7.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 Jan 16 16:52:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpnV-0006g1-P0; Mon, 16 Jan 2012 16: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 1RmpnT-0006dN-Uu
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326732749!9188741!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25540 invoked from network); 16 Jan 2012 16:52:33 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:52:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="20927699"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMG000346;
	Mon, 16 Jan 2012 08:52:21 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:52 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 4/7] Clone and build upstream Qemu 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

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore      |    2 ++
 Config.mk      |    7 +++++++
 Makefile       |    9 ++++++++-
 tools/Makefile |   44 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 61 insertions(+), 1 deletions(-)

diff --git a/.hgignore b/.hgignore
index 4b773c3..cbcc0f5 100644
--- a/.hgignore
+++ b/.hgignore
@@ -298,6 +298,8 @@
 ^tools/xm-test/tests/.*\.test$
 ^tools/qemu-xen-traditional-dir-remote
 ^tools/qemu-xen-traditional-dir$
+^tools/qemu-xen-dir-remote
+^tools/qemu-xen-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Config.mk b/Config.mk
index 1c229c0..d229ab6 100644
--- a/Config.mk
+++ b/Config.mk
@@ -202,6 +202,13 @@ else
 QEMU_REMOTE=git://xenbits.xensource.com/qemu-xen-unstable.git
 endif
 
+ifeq ($(GIT_HTTP),y)
+QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
+else
+QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+endif
+QEMU_UPSTREAM_REVISION ?= master
+
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
 # CONFIG_QEMU ?= `pwd`/$(XEN_ROOT)/../qemu-xen.git
diff --git a/Makefile b/Makefile
index c0197a5..edc5e3d 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/qemu-xen-traditional-dir
+install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir
 endif
 
 .PHONY: install-kernels
@@ -91,6 +91,13 @@ tools/qemu-xen-traditional-dir:
 tools/qemu-xen-traditional-dir-force-update:
 	$(MAKE) -C tools qemu-xen-traditional-dir-force-update
 
+tools/qemu-xen-dir:
+	$(MAKE) -C tools qemu-xen-dir-find
+
+.PHONY: tools/qemu-xen-dir-force-update
+tools/qemu-xen-dir-force-update:
+	$(MAKE) -C tools qemu-xen-dir-force-update
+
 .PHONY: install-docs
 install-docs:
 	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
diff --git a/tools/Makefile b/tools/Makefile
index 3ff1ed1..03ac66f 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -36,6 +36,7 @@ SUBDIRS-y += libvchan
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
 SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
+SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-dir
 endif
 
 SUBDIRS-y += xenpmd
@@ -76,6 +77,7 @@ clean: subdirs-clean
 .PHONY: distclean
 distclean: subdirs-distclean
 	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
+	rm -rf qemu-xen-dir qemu-xen-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -97,6 +99,14 @@ qemu-xen-traditional-dir-find:
 		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
 
+qemu-xen-dir-find:
+	if test -d $(QEMU_UPSTREAM_URL) ; then \
+		mkdir -p qemu-xen-dir; \
+	else \
+		export GIT=$(GIT); \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(QEMU_UPSTREAM_URL) $(QEMU_UPSTREAM_REVISION) qemu-xen-dir ; \
+	fi
+
 .PHONY: qemu-xen-traditional-dir-force-update
 qemu-xen-traditional-dir-force-update:
 	set -ex; \
@@ -119,6 +129,40 @@ subdir-clean-qemu-xen-traditional-dir:
 		$(MAKE) -C qemu-xen-traditional-dir clean; \
 	fi
 
+.PHONY: qemu-xen-dir-force-update
+qemu-xen-dir-force-update:
+	set -ex; \
+	if [ "$(QEMU_UPSTREAM_REVISION)" ]; then \
+		cd qemu-xen-dir-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(QEMU_UPSTREAM_REVISION); \
+	fi
+
+subdir-all-qemu-xen-dir subdir-install-qemu-xen-dir: qemu-xen-dir-find
+	if test -d $(QEMU_UPSTREAM_URL) ; then \
+		source=$(QEMU_UPSTREAM_URL); \
+	else \
+		source=.; \
+	fi; \
+	cd qemu-xen-dir; \
+	$$source/configure --enable-xen --target-list=i386-softmmu \
+		--source-path=$$source \
+		--extra-cflags="-I$(XEN_ROOT)/tools/include \
+		-I$(XEN_ROOT)/tools/libxc \
+		-I$(XEN_ROOT)/tools/xenstore" \
+		--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
+		-L$(XEN_ROOT)/tools/xenstore" \
+		--bindir=$(LIBEXEC) \
+		--disable-kvm \
+		$(IOEMU_CONFIGURE_CROSS); \
+	$(MAKE) install
+
+subdir-clean-qemu-xen-dir:
+	set -e; if test -d qemu-xen-dir/.; then \
+		$(buildmakevars2shellvars); \
+		$(MAKE) -C qemu-xen-dir clean; \
+	fi
+
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
 	$(MAKE) -C debugger/gdbsx clean
 
-- 
1.7.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 Jan 16 16:52:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpnT-0006eX-3K; Mon, 16 Jan 2012 16:52:39 +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 1RmpnR-0006ce-8j
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326732744!11146270!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6010 invoked from network); 16 Jan 2012 16:52:30 -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 Jan 2012 16:52:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="177722863"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 11:52: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 q0GGqGME000346;
	Mon, 16 Jan 2012 08:52:18 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:50 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 2/7] Rename ioemu-dir as
	qemu-xen-traditional-dir
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore        |    4 ++--
 Makefile         |   14 +++++++-------
 stubdom/Makefile |    8 ++++----
 tools/Makefile   |   26 +++++++++++++-------------
 4 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/.hgignore b/.hgignore
index 3145eee..4b773c3 100644
--- a/.hgignore
+++ b/.hgignore
@@ -296,8 +296,8 @@
 ^tools/xm-test/lib/XmTestLib/config.py$
 ^tools/xm-test/lib/XmTestReport/xmtest.py$
 ^tools/xm-test/tests/.*\.test$
-^tools/ioemu-dir-remote
-^tools/ioemu-dir$
+^tools/qemu-xen-traditional-dir-remote
+^tools/qemu-xen-traditional-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Makefile b/Makefile
index 31e8795..c0197a5 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/ioemu-dir
+install-tools: tools/qemu-xen-traditional-dir
 endif
 
 .PHONY: install-kernels
@@ -78,18 +78,18 @@ install-kernels:
 	for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done
 
 .PHONY: install-stubdom
-install-stubdom: tools/ioemu-dir install-tools
+install-stubdom: tools/qemu-xen-traditional-dir install-tools
 	$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
 	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
 endif
 
-tools/ioemu-dir:
-	$(MAKE) -C tools ioemu-dir-find
+tools/qemu-xen-traditional-dir:
+	$(MAKE) -C tools qemu-xen-traditional-dir-find
 
-.PHONY: tools/ioemu-dir-force-update
-tools/ioemu-dir-force-update:
-	$(MAKE) -C tools ioemu-dir-force-update
+.PHONY: tools/qemu-xen-traditional-dir-force-update
+tools/qemu-xen-traditional-dir-force-update:
+	$(MAKE) -C tools qemu-xen-traditional-dir-force-update
 
 .PHONY: install-docs
 install-docs:
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 3705059..e9dbf02 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -218,15 +218,15 @@ $(CROSS_ROOT): cross-newlib cross-zlib cross-libpci
 QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi)
 
 ifeq ($(QEMU_ROOT),.)
-$(XEN_ROOT)/tools/ioemu-dir:
-	$(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find
+$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
+	$(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
 
-ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir
+ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir
 	mkdir -p ioemu
 	set -e;									\
 	$(buildmakevars2shellvars);						\
 	cd ioemu;								\
-	src="$$XEN_ROOT/tools/ioemu-dir"; export src;				\
+	src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src;		\
 	(cd $$src && find * -type d -print) | xargs mkdir -p;			\
 	(cd $$src && find *	! -type l  -type f  $(addprefix ! -name ,	\
 			'*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen	\
diff --git a/tools/Makefile b/tools/Makefile
index 7f5ee3e..14e6d07 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -35,7 +35,7 @@ SUBDIRS-y += libvchan
 
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
-SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir
+SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
 endif
 
 SUBDIRS-y += xenpmd
@@ -75,7 +75,7 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean
-	rm -rf ioemu-dir ioemu-dir-remote
+	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -88,34 +88,34 @@ ifneq ($(QEMU_ROOT),.)
 export QEMU_ROOT
 endif
 
-ioemu-dir-find:
+qemu-xen-traditional-dir-find:
 	set -ex; \
 	if test -d $(CONFIG_QEMU); then \
-		mkdir -p ioemu-dir; \
+		mkdir -p qemu-xen-traditional-dir; \
 	else \
 		export GIT=$(GIT); \
-		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
 	set -e; \
 		$(buildmakevars2shellvars); \
-		cd ioemu-dir; \
+		cd qemu-xen-traditional-dir; \
 		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS)
 
-.PHONY: ioemu-dir-force-update
-ioemu-dir-force-update:
+.PHONY: qemu-xen-traditional-dir-force-update
+qemu-xen-traditional-dir-force-update:
 	set -ex; \
 	if [ "$(QEMU_TAG)" ]; then \
-		cd ioemu-dir-remote; \
+		cd qemu-xen-traditional-dir-remote; \
 		$(GIT) fetch origin; \
 		$(GIT) reset --hard $(QEMU_TAG); \
 	fi
 
-subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find
+subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 
-subdir-clean-ioemu-dir:
-	set -e; if test -d ioemu-dir/.; then \
+subdir-clean-qemu-xen-traditional-dir:
+	set -e; if test -d qemu-xen-traditional-dir/.; then \
 		$(buildmakevars2shellvars); \
-		$(MAKE) -C ioemu-dir clean; \
+		$(MAKE) -C qemu-xen-traditional-dir clean; \
 	fi
 
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
-- 
1.7.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 Jan 16 16:52:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpnT-0006eX-3K; Mon, 16 Jan 2012 16:52:39 +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 1RmpnR-0006ce-8j
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326732744!11146270!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6010 invoked from network); 16 Jan 2012 16:52:30 -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 Jan 2012 16:52:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="177722863"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 11:52: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 q0GGqGME000346;
	Mon, 16 Jan 2012 08:52:18 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:50 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 2/7] Rename ioemu-dir as
	qemu-xen-traditional-dir
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore        |    4 ++--
 Makefile         |   14 +++++++-------
 stubdom/Makefile |    8 ++++----
 tools/Makefile   |   26 +++++++++++++-------------
 4 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/.hgignore b/.hgignore
index 3145eee..4b773c3 100644
--- a/.hgignore
+++ b/.hgignore
@@ -296,8 +296,8 @@
 ^tools/xm-test/lib/XmTestLib/config.py$
 ^tools/xm-test/lib/XmTestReport/xmtest.py$
 ^tools/xm-test/tests/.*\.test$
-^tools/ioemu-dir-remote
-^tools/ioemu-dir$
+^tools/qemu-xen-traditional-dir-remote
+^tools/qemu-xen-traditional-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Makefile b/Makefile
index 31e8795..c0197a5 100644
--- a/Makefile
+++ b/Makefile
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/ioemu-dir
+install-tools: tools/qemu-xen-traditional-dir
 endif
 
 .PHONY: install-kernels
@@ -78,18 +78,18 @@ install-kernels:
 	for i in $(XKERNELS) ; do $(MAKE) $$i-install || exit 1; done
 
 .PHONY: install-stubdom
-install-stubdom: tools/ioemu-dir install-tools
+install-stubdom: tools/qemu-xen-traditional-dir install-tools
 	$(MAKE) -C stubdom install
 ifeq (x86_64,$(XEN_TARGET_ARCH))
 	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
 endif
 
-tools/ioemu-dir:
-	$(MAKE) -C tools ioemu-dir-find
+tools/qemu-xen-traditional-dir:
+	$(MAKE) -C tools qemu-xen-traditional-dir-find
 
-.PHONY: tools/ioemu-dir-force-update
-tools/ioemu-dir-force-update:
-	$(MAKE) -C tools ioemu-dir-force-update
+.PHONY: tools/qemu-xen-traditional-dir-force-update
+tools/qemu-xen-traditional-dir-force-update:
+	$(MAKE) -C tools qemu-xen-traditional-dir-force-update
 
 .PHONY: install-docs
 install-docs:
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 3705059..e9dbf02 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -218,15 +218,15 @@ $(CROSS_ROOT): cross-newlib cross-zlib cross-libpci
 QEMU_ROOT := $(shell if [ -d "$(CONFIG_QEMU)" ]; then echo "$(CONFIG_QEMU)"; else echo .; fi)
 
 ifeq ($(QEMU_ROOT),.)
-$(XEN_ROOT)/tools/ioemu-dir:
-	$(CROSS_MAKE) -C $(XEN_ROOT)/tools ioemu-dir-find
+$(XEN_ROOT)/tools/qemu-xen-traditional-dir:
+	$(CROSS_MAKE) -C $(XEN_ROOT)/tools qemu-xen-traditional-dir-find
 
-ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/ioemu-dir
+ioemu/linkfarm.stamp: $(XEN_ROOT)/tools/qemu-xen-traditional-dir
 	mkdir -p ioemu
 	set -e;									\
 	$(buildmakevars2shellvars);						\
 	cd ioemu;								\
-	src="$$XEN_ROOT/tools/ioemu-dir"; export src;				\
+	src="$$XEN_ROOT/tools/qemu-xen-traditional-dir"; export src;		\
 	(cd $$src && find * -type d -print) | xargs mkdir -p;			\
 	(cd $$src && find *	! -type l  -type f  $(addprefix ! -name ,	\
 			'*.[oda1]' 'config-*' config.mak qemu-dm qemu-img-xen	\
diff --git a/tools/Makefile b/tools/Makefile
index 7f5ee3e..14e6d07 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -35,7 +35,7 @@ SUBDIRS-y += libvchan
 
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
-SUBDIRS-$(CONFIG_IOEMU) += ioemu-dir
+SUBDIRS-$(CONFIG_IOEMU) += qemu-xen-traditional-dir
 endif
 
 SUBDIRS-y += xenpmd
@@ -75,7 +75,7 @@ clean: subdirs-clean
 
 .PHONY: distclean
 distclean: subdirs-distclean
-	rm -rf ioemu-dir ioemu-dir-remote
+	rm -rf qemu-xen-traditional-dir qemu-xen-traditional-dir-remote
 
 ifneq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
 IOEMU_CONFIGURE_CROSS ?= --cpu=$(XEN_TARGET_ARCH) \
@@ -88,34 +88,34 @@ ifneq ($(QEMU_ROOT),.)
 export QEMU_ROOT
 endif
 
-ioemu-dir-find:
+qemu-xen-traditional-dir-find:
 	set -ex; \
 	if test -d $(CONFIG_QEMU); then \
-		mkdir -p ioemu-dir; \
+		mkdir -p qemu-xen-traditional-dir; \
 	else \
 		export GIT=$(GIT); \
-		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) ioemu-dir; \
+		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
 	set -e; \
 		$(buildmakevars2shellvars); \
-		cd ioemu-dir; \
+		cd qemu-xen-traditional-dir; \
 		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS)
 
-.PHONY: ioemu-dir-force-update
-ioemu-dir-force-update:
+.PHONY: qemu-xen-traditional-dir-force-update
+qemu-xen-traditional-dir-force-update:
 	set -ex; \
 	if [ "$(QEMU_TAG)" ]; then \
-		cd ioemu-dir-remote; \
+		cd qemu-xen-traditional-dir-remote; \
 		$(GIT) fetch origin; \
 		$(GIT) reset --hard $(QEMU_TAG); \
 	fi
 
-subdir-all-ioemu-dir subdir-install-ioemu-dir: ioemu-dir-find
+subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
 
-subdir-clean-ioemu-dir:
-	set -e; if test -d ioemu-dir/.; then \
+subdir-clean-qemu-xen-traditional-dir:
+	set -e; if test -d qemu-xen-traditional-dir/.; then \
 		$(buildmakevars2shellvars); \
-		$(MAKE) -C ioemu-dir clean; \
+		$(MAKE) -C qemu-xen-traditional-dir clean; \
 	fi
 
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
-- 
1.7.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 Jan 16 16:52:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpnT-0006f4-Ut; Mon, 16 Jan 2012 16:52: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 1RmpnS-0006cp-8K
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326732749!9188741!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25499 invoked from network); 16 Jan 2012 16:52:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:52:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="20927698"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMF000346;
	Mon, 16 Jan 2012 08:52:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:51 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 3/7] move the call to xen-setup after libxc
	and xenstore are built
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Move the call to xen-setup, the wrapper script to configure
qemu-xen-traditional, right before building qemu-xen-traditional and
after libxc and xenstore are already built.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/Makefile |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 14e6d07..3ff1ed1 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -96,10 +96,6 @@ qemu-xen-traditional-dir-find:
 		export GIT=$(GIT); \
 		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
-	set -e; \
-		$(buildmakevars2shellvars); \
-		cd qemu-xen-traditional-dir; \
-		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS)
 
 .PHONY: qemu-xen-traditional-dir-force-update
 qemu-xen-traditional-dir-force-update:
@@ -111,6 +107,11 @@ qemu-xen-traditional-dir-force-update:
 	fi
 
 subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
+	set -e; \
+		$(buildmakevars2shellvars); \
+		cd qemu-xen-traditional-dir; \
+		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
+		$(MAKE) install
 
 subdir-clean-qemu-xen-traditional-dir:
 	set -e; if test -d qemu-xen-traditional-dir/.; then \
-- 
1.7.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 Jan 16 16:52:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpnT-0006f4-Ut; Mon, 16 Jan 2012 16:52: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 1RmpnS-0006cp-8K
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326732749!9188741!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25499 invoked from network); 16 Jan 2012 16:52:32 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:52:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="20927698"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMF000346;
	Mon, 16 Jan 2012 08:52:19 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:51 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 3/7] move the call to xen-setup after libxc
	and xenstore are built
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Move the call to xen-setup, the wrapper script to configure
qemu-xen-traditional, right before building qemu-xen-traditional and
after libxc and xenstore are already built.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/Makefile |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index 14e6d07..3ff1ed1 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -96,10 +96,6 @@ qemu-xen-traditional-dir-find:
 		export GIT=$(GIT); \
 		$(XEN_ROOT)/scripts/git-checkout.sh $(CONFIG_QEMU) $(QEMU_TAG) qemu-xen-traditional-dir; \
 	fi
-	set -e; \
-		$(buildmakevars2shellvars); \
-		cd qemu-xen-traditional-dir; \
-		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS)
 
 .PHONY: qemu-xen-traditional-dir-force-update
 qemu-xen-traditional-dir-force-update:
@@ -111,6 +107,11 @@ qemu-xen-traditional-dir-force-update:
 	fi
 
 subdir-all-qemu-xen-traditional-dir subdir-install-qemu-xen-traditional-dir: qemu-xen-traditional-dir-find
+	set -e; \
+		$(buildmakevars2shellvars); \
+		cd qemu-xen-traditional-dir; \
+		$(QEMU_ROOT)/xen-setup $(IOEMU_CONFIGURE_CROSS); \
+		$(MAKE) install
 
 subdir-clean-qemu-xen-traditional-dir:
 	set -e; if test -d qemu-xen-traditional-dir/.; then \
-- 
1.7.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 Jan 16 16:52:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpnT-0006en-H0; Mon, 16 Jan 2012 16:52: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 1RmpnR-0006cc-8G
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326732749!9188741!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25452 invoked from network); 16 Jan 2012 16:52:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:52:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="20927695"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMH000346;
	Mon, 16 Jan 2012 08:52:22 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:53 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 5/7] 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

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore                         |    2 +
 Config.mk                         |   12 ++-----
 Makefile                          |    4 ++
 tools/firmware/Makefile           |   21 ++++++++++-
 tools/firmware/hvmloader/Makefile |    1 +
 tools/firmware/seabios-config     |   73 +++++++++++++++++++++++++++++++++++++
 6 files changed, 102 insertions(+), 11 deletions(-)
 create mode 100644 tools/firmware/seabios-config

diff --git a/.hgignore b/.hgignore
index cbcc0f5..64b440e 100644
--- a/.hgignore
+++ b/.hgignore
@@ -300,6 +300,8 @@
 ^tools/qemu-xen-traditional-dir$
 ^tools/qemu-xen-dir-remote
 ^tools/qemu-xen-dir$
+^tools/firmware/seabios-dir-remote
+^tools/firmware/seabios-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Config.mk b/Config.mk
index d229ab6..152c783 100644
--- a/Config.mk
+++ b/Config.mk
@@ -204,10 +204,13 @@ endif
 
 ifeq ($(GIT_HTTP),y)
 QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
+SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
 else
 QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
 QEMU_UPSTREAM_REVISION ?= master
+SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
@@ -221,15 +224,6 @@ QEMU_TAG ?= bb36d632e4cabf47882adff07a45c6702c4a5b30
 # Short answer -- do not enable this unless you know what you are
 # doing and are prepared for some pain.
 
-# SeaBIOS integration is a work in progress. Before enabling this
-# option you must clone git://git.qemu.org/seabios.git/, possibly add
-# some development patches and then build it yourself before pointing
-# this variable to it (using an absolute path).
-#
-# Note that using SeaBIOS requires the use the upstream qemu as the
-# device model.
-SEABIOS_DIR ?= 
-
 # Optional components
 XENSTAT_XENTOP     ?= y
 VTPM_TOOLS         ?= n
diff --git a/Makefile b/Makefile
index edc5e3d..8edea0d 100644
--- a/Makefile
+++ b/Makefile
@@ -98,6 +98,10 @@ tools/qemu-xen-dir:
 tools/qemu-xen-dir-force-update:
 	$(MAKE) -C tools qemu-xen-dir-force-update
 
+.PHONY: tools/firmware/seabios-dir-force-update
+tools/firmware/seabios-dir-force-update:
+	$(MAKE) -C tools/firmware seabios-dir-force-update
+
 .PHONY: install-docs
 install-docs:
 	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 4b6d144..c3ec9a0 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,13 +6,18 @@ TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS :=
+SUBDIRS += seabios-dir
 SUBDIRS += rombios
 SUBDIRS += vgabios
 SUBDIRS += etherboot
 SUBDIRS += hvmloader
 
+seabios-dir:
+	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
+	cp seabios-config seabios-dir/.config;
+
 .PHONY: all
-all:
+all: seabios-dir
 	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
 	echo "==========================================================================="; \
 	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
@@ -35,4 +40,16 @@ clean: subdirs-clean
 distclean: subdirs-distclean
 
 subdir-distclean-etherboot: .phony
-	$(MAKE) -C etherboot distclean
\ No newline at end of file
+	$(MAKE) -C etherboot distclean
+
+subdir-distclean-seabios-dir: .phony
+	rm -rf seabios-dir seabios-dir-remote
+
+.PHONY: seabios-dir-force-update
+seabios-dir-force-update:
+	set -ex; \
+	if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \
+		cd seabios-dir-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(SEABIOS_UPSTREAM_TAG); \
+	fi
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index ec33155..41a4369 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
 
+SEABIOS_DIR := ../seabios-dir
 ifneq ($(SEABIOS_DIR),)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
diff --git a/tools/firmware/seabios-config b/tools/firmware/seabios-config
new file mode 100644
index 0000000..202d15f
--- /dev/null
+++ b/tools/firmware/seabios-config
@@ -0,0 +1,73 @@
+#
+# Automatically generated make config: don't edit
+# SeaBIOS Configuration
+# Wed Sep  7 13:03:21 2011
+#
+
+#
+# General Features
+#
+# CONFIG_COREBOOT is not set
+CONFIG_XEN=y
+CONFIG_THREADS=y
+# CONFIG_THREAD_OPTIONROMS is not set
+CONFIG_RELOCATE_INIT=y
+CONFIG_BOOTMENU=y
+# CONFIG_BOOTSPLASH is not set
+CONFIG_BOOTORDER=y
+
+#
+# Hardware support
+#
+CONFIG_ATA=y
+CONFIG_ATA_DMA=y
+CONFIG_ATA_PIO32=y
+CONFIG_AHCI=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_FLOPPY=y
+CONFIG_PS2PORT=y
+CONFIG_USB=y
+CONFIG_USB_UHCI=y
+CONFIG_USB_OHCI=y
+CONFIG_USB_EHCI=y
+CONFIG_USB_MSC=y
+CONFIG_USB_HUB=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_MOUSE=y
+CONFIG_SERIAL=y
+CONFIG_LPT=y
+# CONFIG_USE_SMM is not set
+CONFIG_MTRR_INIT=y
+
+#
+# BIOS interfaces
+#
+CONFIG_DRIVES=y
+CONFIG_CDROM_BOOT=y
+CONFIG_CDROM_EMU=y
+CONFIG_PCIBIOS=y
+CONFIG_APMBIOS=y
+CONFIG_PNPBIOS=y
+CONFIG_OPTIONROMS=y
+# CONFIG_OPTIONROMS_DEPLOYED is not set
+CONFIG_PMM=y
+CONFIG_BOOT=y
+CONFIG_KEYBOARD=y
+CONFIG_KBD_CALL_INT15_4F=y
+CONFIG_MOUSE=y
+CONFIG_S3_RESUME=y
+# CONFIG_DISABLE_A20 is not set
+
+#
+# BIOS Tables
+#
+CONFIG_PIRTABLE=y
+CONFIG_MPTABLE=y
+CONFIG_SMBIOS=y
+CONFIG_ACPI=y
+
+#
+# Debugging
+#
+CONFIG_DEBUG_LEVEL=1
+# CONFIG_DEBUG_SERIAL is not set
-- 
1.7.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 Jan 16 16:52:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmpnT-0006en-H0; Mon, 16 Jan 2012 16:52: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 1RmpnR-0006cc-8G
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326732749!9188741!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25452 invoked from network); 16 Jan 2012 16:52:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:52:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="20927695"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMH000346;
	Mon, 16 Jan 2012 08:52:22 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:53 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	"stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 5/7] 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

From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 .hgignore                         |    2 +
 Config.mk                         |   12 ++-----
 Makefile                          |    4 ++
 tools/firmware/Makefile           |   21 ++++++++++-
 tools/firmware/hvmloader/Makefile |    1 +
 tools/firmware/seabios-config     |   73 +++++++++++++++++++++++++++++++++++++
 6 files changed, 102 insertions(+), 11 deletions(-)
 create mode 100644 tools/firmware/seabios-config

diff --git a/.hgignore b/.hgignore
index cbcc0f5..64b440e 100644
--- a/.hgignore
+++ b/.hgignore
@@ -300,6 +300,8 @@
 ^tools/qemu-xen-traditional-dir$
 ^tools/qemu-xen-dir-remote
 ^tools/qemu-xen-dir$
+^tools/firmware/seabios-dir-remote
+^tools/firmware/seabios-dir$
 ^tools/ocaml/.*/.*\.annot$
 ^tools/ocaml/.*/.*\.cmx?a$
 ^tools/ocaml/.*/META$
diff --git a/Config.mk b/Config.mk
index d229ab6..152c783 100644
--- a/Config.mk
+++ b/Config.mk
@@ -204,10 +204,13 @@ endif
 
 ifeq ($(GIT_HTTP),y)
 QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
+SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
 else
 QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
+SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
 QEMU_UPSTREAM_REVISION ?= master
+SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.
@@ -221,15 +224,6 @@ QEMU_TAG ?= bb36d632e4cabf47882adff07a45c6702c4a5b30
 # Short answer -- do not enable this unless you know what you are
 # doing and are prepared for some pain.
 
-# SeaBIOS integration is a work in progress. Before enabling this
-# option you must clone git://git.qemu.org/seabios.git/, possibly add
-# some development patches and then build it yourself before pointing
-# this variable to it (using an absolute path).
-#
-# Note that using SeaBIOS requires the use the upstream qemu as the
-# device model.
-SEABIOS_DIR ?= 
-
 # Optional components
 XENSTAT_XENTOP     ?= y
 VTPM_TOOLS         ?= n
diff --git a/Makefile b/Makefile
index edc5e3d..8edea0d 100644
--- a/Makefile
+++ b/Makefile
@@ -98,6 +98,10 @@ tools/qemu-xen-dir:
 tools/qemu-xen-dir-force-update:
 	$(MAKE) -C tools qemu-xen-dir-force-update
 
+.PHONY: tools/firmware/seabios-dir-force-update
+tools/firmware/seabios-dir-force-update:
+	$(MAKE) -C tools/firmware seabios-dir-force-update
+
 .PHONY: install-docs
 install-docs:
 	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 4b6d144..c3ec9a0 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,13 +6,18 @@ TARGET      := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS :=
+SUBDIRS += seabios-dir
 SUBDIRS += rombios
 SUBDIRS += vgabios
 SUBDIRS += etherboot
 SUBDIRS += hvmloader
 
+seabios-dir:
+	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
+	cp seabios-config seabios-dir/.config;
+
 .PHONY: all
-all:
+all: seabios-dir
 	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
 	echo "==========================================================================="; \
 	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
@@ -35,4 +40,16 @@ clean: subdirs-clean
 distclean: subdirs-distclean
 
 subdir-distclean-etherboot: .phony
-	$(MAKE) -C etherboot distclean
\ No newline at end of file
+	$(MAKE) -C etherboot distclean
+
+subdir-distclean-seabios-dir: .phony
+	rm -rf seabios-dir seabios-dir-remote
+
+.PHONY: seabios-dir-force-update
+seabios-dir-force-update:
+	set -ex; \
+	if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \
+		cd seabios-dir-remote; \
+		$(GIT) fetch origin; \
+		$(GIT) reset --hard $(SEABIOS_UPSTREAM_TAG); \
+	fi
diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
index ec33155..41a4369 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS
 ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 endif
 
+SEABIOS_DIR := ../seabios-dir
 ifneq ($(SEABIOS_DIR),)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
diff --git a/tools/firmware/seabios-config b/tools/firmware/seabios-config
new file mode 100644
index 0000000..202d15f
--- /dev/null
+++ b/tools/firmware/seabios-config
@@ -0,0 +1,73 @@
+#
+# Automatically generated make config: don't edit
+# SeaBIOS Configuration
+# Wed Sep  7 13:03:21 2011
+#
+
+#
+# General Features
+#
+# CONFIG_COREBOOT is not set
+CONFIG_XEN=y
+CONFIG_THREADS=y
+# CONFIG_THREAD_OPTIONROMS is not set
+CONFIG_RELOCATE_INIT=y
+CONFIG_BOOTMENU=y
+# CONFIG_BOOTSPLASH is not set
+CONFIG_BOOTORDER=y
+
+#
+# Hardware support
+#
+CONFIG_ATA=y
+CONFIG_ATA_DMA=y
+CONFIG_ATA_PIO32=y
+CONFIG_AHCI=y
+CONFIG_VIRTIO_BLK=y
+CONFIG_FLOPPY=y
+CONFIG_PS2PORT=y
+CONFIG_USB=y
+CONFIG_USB_UHCI=y
+CONFIG_USB_OHCI=y
+CONFIG_USB_EHCI=y
+CONFIG_USB_MSC=y
+CONFIG_USB_HUB=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_USB_MOUSE=y
+CONFIG_SERIAL=y
+CONFIG_LPT=y
+# CONFIG_USE_SMM is not set
+CONFIG_MTRR_INIT=y
+
+#
+# BIOS interfaces
+#
+CONFIG_DRIVES=y
+CONFIG_CDROM_BOOT=y
+CONFIG_CDROM_EMU=y
+CONFIG_PCIBIOS=y
+CONFIG_APMBIOS=y
+CONFIG_PNPBIOS=y
+CONFIG_OPTIONROMS=y
+# CONFIG_OPTIONROMS_DEPLOYED is not set
+CONFIG_PMM=y
+CONFIG_BOOT=y
+CONFIG_KEYBOARD=y
+CONFIG_KBD_CALL_INT15_4F=y
+CONFIG_MOUSE=y
+CONFIG_S3_RESUME=y
+# CONFIG_DISABLE_A20 is not set
+
+#
+# BIOS Tables
+#
+CONFIG_PIRTABLE=y
+CONFIG_MPTABLE=y
+CONFIG_SMBIOS=y
+CONFIG_ACPI=y
+
+#
+# Debugging
+#
+CONFIG_DEBUG_LEVEL=1
+# CONFIG_DEBUG_SERIAL is not set
-- 
1.7.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 Jan 16 16:52:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpnZ-0006iw-D7; Mon, 16 Jan 2012 16:52:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RmpnY-0006eY-Jv
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326732749!9188741!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25883 invoked from network); 16 Jan 2012 16:52:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:52:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="20927701"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMJ000346;
	Mon, 16 Jan 2012 08:52:25 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:55 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 7/7] update MAINTAINERS 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

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Add Ian as Seabios maintainer and myself as upstream Qemu maintainer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 MAINTAINERS |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 60f724d..cd0d71d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -176,6 +176,11 @@ M:	Ian Jackson <ian.jackson@eu.citrix.com>
 S:	Supported
 T:	git git://xenbits.xen.org/qemu-xen-*.git
 
+QEMU UPSTREAM
+M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+S:	Supported
+T:	git git://xenbits.xen.org/qemu-upstream-*.git
+
 REMUS
 M:	Shriram Rajagopalan <rshriram@cs.ubc.ca>
 S:	Maintained
@@ -190,6 +195,11 @@ M:	George Dunlap <george.dunlap@eu.citrix.com>
 S:	Supported
 F:	xen/common/sched*
 
+SEABIOS UPSTREAM
+M:	Ian Campbell <ian.campbell@citrix.com>
+S:	Supported
+T:	git git://xenbits.xen.org/seabios.git
+
 STUB DOMAINS
 M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
 S:	Supported
-- 
1.7.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 Jan 16 16:52:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpnZ-0006iw-D7; Mon, 16 Jan 2012 16:52:45 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RmpnY-0006eY-Jv
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326732749!9188741!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc2MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25883 invoked from network); 16 Jan 2012 16:52:37 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:52:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="20927701"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMJ000346;
	Mon, 16 Jan 2012 08:52:25 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:55 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v10 7/7] update MAINTAINERS 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

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Add Ian as Seabios maintainer and myself as upstream Qemu maintainer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 MAINTAINERS |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 60f724d..cd0d71d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -176,6 +176,11 @@ M:	Ian Jackson <ian.jackson@eu.citrix.com>
 S:	Supported
 T:	git git://xenbits.xen.org/qemu-xen-*.git
 
+QEMU UPSTREAM
+M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+S:	Supported
+T:	git git://xenbits.xen.org/qemu-upstream-*.git
+
 REMUS
 M:	Shriram Rajagopalan <rshriram@cs.ubc.ca>
 S:	Maintained
@@ -190,6 +195,11 @@ M:	George Dunlap <george.dunlap@eu.citrix.com>
 S:	Supported
 F:	xen/common/sched*
 
+SEABIOS UPSTREAM
+M:	Ian Campbell <ian.campbell@citrix.com>
+S:	Supported
+T:	git git://xenbits.xen.org/seabios.git
+
 STUB DOMAINS
 M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
 S:	Supported
-- 
1.7.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 Jan 16 16:53:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpnV-0006fn-Cg; Mon, 16 Jan 2012 16:52:41 +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 1RmpnT-0006ee-Mh
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326732691!61197361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9227 invoked from network); 16 Jan 2012 16:51:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:51:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="177722872"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMI000346;
	Mon, 16 Jan 2012 08:52:24 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:54 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v10 6/7] libxl: use new qemu at the location
	where xen-unstable installs 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

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..9d84b6f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -58,7 +58,7 @@ const char *libxl__domain_device_model(libxl__gc *gc,
             dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm = libxl__strdup(gc, "/usr/bin/qemu");
+            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-- 
1.7.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 Jan 16 16:53:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpnV-0006fn-Cg; Mon, 16 Jan 2012 16:52:41 +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 1RmpnT-0006ee-Mh
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:52:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326732691!61197361!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzE5ODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9227 invoked from network); 16 Jan 2012 16:51:32 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 16:51:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="177722872"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 11:52: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; Mon, 16 Jan 2012 11:52: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 q0GGqGMI000346;
	Mon, 16 Jan 2012 08:52:24 -0800
From: <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 16 Jan 2012 16:52:54 +0000
Message-ID: <1326732775-15485-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.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Jackson@eu.citrix.com, Ian Campbell <ian.campbell@citrix.com>,
	Stefano.Stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH v10 6/7] libxl: use new qemu at the location
	where xen-unstable installs 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

From: Ian Campbell <ian.campbell@citrix.com>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..9d84b6f 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -58,7 +58,7 @@ const char *libxl__domain_device_model(libxl__gc *gc,
             dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm = libxl__strdup(gc, "/usr/bin/qemu");
+            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-- 
1.7.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 Jan 16 16:53:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpoV-0007Bh-Rp; Mon, 16 Jan 2012 16:53: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 1RmpoU-00078w-AL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:53:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326732750!61197578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12761 invoked from network); 16 Jan 2012 16:52:30 -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;
	16 Jan 2012 16:52:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:53: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, 16 Jan 2012 16:53: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
	1RmpoN-00059l-34; Mon, 16 Jan 2012 16:53:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpoN-00014b-2G;
	Mon, 16 Jan 2012 16:53:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.22029.761565.805780@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:53:33 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326732404.14689.34.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
	<20244.20607.725332.428230@mariner.uk.xensource.com>
	<1326732404.14689.34.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 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configuration info build_info->u.hvm"):
> While we are at it -- do you have any thoughts on how per-arch options
> should be handled? I was thinking of adding the possibility in the IDL
> to tag a field with a list of architectures?

If we eventually tunnel these structures over some kind of IPC
mechanism it might be necessary to deal with values from other than
the native architecture.

So perhaps per-arch fields should exist in every version and just have
the arch in their name somehow, although that wouldn't spot people
setting them inappropriately.

Alternative a variadic substructure where _init sets the enum to the
default native arch ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:53:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16: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 1RmpoV-0007Bh-Rp; Mon, 16 Jan 2012 16:53: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 1RmpoU-00078w-AL
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:53:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326732750!61197578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12761 invoked from network); 16 Jan 2012 16:52:30 -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;
	16 Jan 2012 16:52:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062222"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:53: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, 16 Jan 2012 16:53: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
	1RmpoN-00059l-34; Mon, 16 Jan 2012 16:53:35 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmpoN-00014b-2G;
	Mon, 16 Jan 2012 16:53:35 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.22029.761565.805780@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:53:33 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326732404.14689.34.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
	<20244.20607.725332.428230@mariner.uk.xensource.com>
	<1326732404.14689.34.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 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configuration info build_info->u.hvm"):
> While we are at it -- do you have any thoughts on how per-arch options
> should be handled? I was thinking of adding the possibility in the IDL
> to tag a field with a list of architectures?

If we eventually tunnel these structures over some kind of IPC
mechanism it might be necessary to deal with values from other than
the native architecture.

So perhaps per-arch fields should exist in every version and just have
the arch in their name somehow, although that wouldn't spot people
setting them inappropriately.

Alternative a variadic substructure where _init sets the enum to the
default native arch ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:56:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmprY-0007wy-6w; Mon, 16 Jan 2012 16:56:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmprW-0007vb-TT
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:56:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326733004!9189276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8393 invoked from network); 16 Jan 2012 16:56:44 -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;
	16 Jan 2012 16:56:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:56:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:56: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
	1RmprP-0005Aq-MZ; Mon, 16 Jan 2012 16:56:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmprP-00014v-Ll;
	Mon, 16 Jan 2012 16:56:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.22219.661745.97406@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:56:43 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@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 v10 0/7] build upstream qemu and 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 ("[PATCH v10 0/7] build upstream qemu and seabios by default"):
> this is the tenth version of the patch series to introduce upstream qemu
> and seabios in the xen-unstable build system.

Thanks.  This all looks good and I intend to apply it as soon as we
get a push in xen-unstable.  (Until then I'll wait in case it breaks
the build and makes it harder to get a push.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 16:56:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 16:56:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmprY-0007wy-6w; Mon, 16 Jan 2012 16:56:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmprW-0007vb-TT
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:56:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326733004!9189276!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8393 invoked from network); 16 Jan 2012 16:56:44 -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;
	16 Jan 2012 16:56:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 16:56:44 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 16:56: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
	1RmprP-0005Aq-MZ; Mon, 16 Jan 2012 16:56:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RmprP-00014v-Ll;
	Mon, 16 Jan 2012 16:56:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.22219.661745.97406@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 16:56:43 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
In-Reply-To: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@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 v10 0/7] build upstream qemu and 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 ("[PATCH v10 0/7] build upstream qemu and seabios by default"):
> this is the tenth version of the patch series to introduce upstream qemu
> and seabios in the xen-unstable build system.

Thanks.  This all looks good and I intend to apply it as soon as we
get a push in xen-unstable.  (Until then I'll wait in case it breaks
the build and makes it harder to get a push.)

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:01:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmpvu-0000Bo-U4; Mon, 16 Jan 2012 17:01:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rmpvt-0000B6-00
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:01:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326733274!11256222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9064 invoked from network); 16 Jan 2012 17:01:15 -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;
	16 Jan 2012 17:01:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:01: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, 16 Jan 2012 17:01:14 +0000
Date: Mon, 16 Jan 2012 17:01: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: <1326729772.14689.10.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201161615340.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
	<1326729772.14689.10.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 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 16 Jan 2012, Ian Campbell wrote:
> On Mon, 2012-01-16 at 15:53 +0000, Stefano Stabellini wrote:
> > On Mon, 16 Jan 2012, Ian Campbell wrote:
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1326715929 0
> > > # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> > > # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> > > libxl: Default to stub device model whenever possible.
> > 
> > Considering that stubdoms are not yet at feature parity I don't think we
> > should make this change for 4.2.
> > At the very least we should expand the set of conditions on which we base
> > the decision on: certainly the presence of an audio device, maybe pci
> > passthrough and the type of block backend (considering that some of them
> > go through qemu now) in case they aren't working properly.
> 
> Tweaking the precise conditions is reasonable and indeed the main thrust
> of the series is to allow to make this sort of determination and to
> change our minds about it.

The danger of this approach is that stubdoms are not really transparent
from the admin point of view.
>From the basic difference when you "xl list", to memory usage, a stubdom
based setup is quite different from a non-stubdom based setup.
If I were an admin I would really want to know when I am running one or
the other.
Making the change under their feet is bad enough but making a difference
choice depending on a various set of variables is certainly not going to
be popular.


> Disabling stub-dm in the face of an audio is a no brainer. PCI
> passthrough less obviously so since itm in theory, works but given the
> number of problems we've had with it I'm inclined to also gate on that.
> 
> Which leaves block devices which is an interesting one because currently
> I don't have enough info in hand during
> libxl__domain_build_info_setdefaults to make that determination. I shall
> look at how I can resolve that.

Theoretically this case could also work with stubdoms because the block
backend would be provided by the other qemu, the one running in dom0.
However it is not probably going to work right now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:01:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:01:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmpvu-0000Bo-U4; Mon, 16 Jan 2012 17:01:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rmpvt-0000B6-00
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:01:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326733274!11256222!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9064 invoked from network); 16 Jan 2012 17:01:15 -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;
	16 Jan 2012 17:01:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:01: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, 16 Jan 2012 17:01:14 +0000
Date: Mon, 16 Jan 2012 17:01: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: <1326729772.14689.10.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201161615340.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
	<1326729772.14689.10.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 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 16 Jan 2012, Ian Campbell wrote:
> On Mon, 2012-01-16 at 15:53 +0000, Stefano Stabellini wrote:
> > On Mon, 16 Jan 2012, Ian Campbell wrote:
> > > # HG changeset patch
> > > # User Ian Campbell <ian.campbell@citrix.com>
> > > # Date 1326715929 0
> > > # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> > > # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> > > libxl: Default to stub device model whenever possible.
> > 
> > Considering that stubdoms are not yet at feature parity I don't think we
> > should make this change for 4.2.
> > At the very least we should expand the set of conditions on which we base
> > the decision on: certainly the presence of an audio device, maybe pci
> > passthrough and the type of block backend (considering that some of them
> > go through qemu now) in case they aren't working properly.
> 
> Tweaking the precise conditions is reasonable and indeed the main thrust
> of the series is to allow to make this sort of determination and to
> change our minds about it.

The danger of this approach is that stubdoms are not really transparent
from the admin point of view.
>From the basic difference when you "xl list", to memory usage, a stubdom
based setup is quite different from a non-stubdom based setup.
If I were an admin I would really want to know when I am running one or
the other.
Making the change under their feet is bad enough but making a difference
choice depending on a various set of variables is certainly not going to
be popular.


> Disabling stub-dm in the face of an audio is a no brainer. PCI
> passthrough less obviously so since itm in theory, works but given the
> number of problems we've had with it I'm inclined to also gate on that.
> 
> Which leaves block devices which is an interesting one because currently
> I don't have enough info in hand during
> libxl__domain_build_info_setdefaults to make that determination. I shall
> look at how I can resolve that.

Theoretically this case could also work with stubdoms because the block
backend would be provided by the other qemu, the one running in dom0.
However it is not probably going to work right now.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:09:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17: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 1Rmq40-0000c0-WB; Mon, 16 Jan 2012 17:09:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmq3z-0000bm-0J
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:09:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326733777!11273564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1641 invoked from network); 16 Jan 2012 17:09:37 -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;
	16 Jan 2012 17:09:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:09: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, 16 Jan 2012 17:09:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:09:36 +0000
In-Reply-To: <20244.21874.852622.418848@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
	<20244.21874.852622.418848@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326733776.14689.35.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 21 of 32] libxl: drop vfs patch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:50 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 21 of 32] libxl: drop vfs patch"):
> > libxl: drop vfs path -- fsback/front were deleted some time ago
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I was going to apply this, but it doesn't fit in the current tree.  I
> guess the context is updated by earlier patches in your series.  So
> for now:
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks, I'll pull it to the front for the next posting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:09:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17: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 1Rmq40-0000c0-WB; Mon, 16 Jan 2012 17:09:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmq3z-0000bm-0J
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:09:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326733777!11273564!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1641 invoked from network); 16 Jan 2012 17:09:37 -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;
	16 Jan 2012 17:09:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062662"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:09: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, 16 Jan 2012 17:09:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:09:36 +0000
In-Reply-To: <20244.21874.852622.418848@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
	<20244.21874.852622.418848@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326733776.14689.35.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 21 of 32] libxl: drop vfs patch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:50 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 21 of 32] libxl: drop vfs patch"):
> > libxl: drop vfs path -- fsback/front were deleted some time ago
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I was going to apply this, but it doesn't fit in the current tree.  I
> guess the context is updated by earlier patches in your series.  So
> for now:
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks, I'll pull it to the front for the next posting.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:15:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17: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 1Rmq8r-0000mM-OF; Mon, 16 Jan 2012 17:14:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmq8q-0000mH-Lu
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:14:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326734042!60433084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28746 invoked from network); 16 Jan 2012 17:14:02 -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;
	16 Jan 2012 17:14:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:14: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, 16 Jan 2012 17:14:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:14:43 +0000
In-Reply-To: <alpine.DEB.2.00.1201161615340.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
	<1326729772.14689.10.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201161615340.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326734083.14689.39.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 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 17:01 +0000, Stefano Stabellini wrote:
> On Mon, 16 Jan 2012, Ian Campbell wrote:
> > On Mon, 2012-01-16 at 15:53 +0000, Stefano Stabellini wrote:
> > > On Mon, 16 Jan 2012, Ian Campbell wrote:
> > > > # HG changeset patch
> > > > # User Ian Campbell <ian.campbell@citrix.com>
> > > > # Date 1326715929 0
> > > > # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> > > > # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> > > > libxl: Default to stub device model whenever possible.
> > > 
> > > Considering that stubdoms are not yet at feature parity I don't think we
> > > should make this change for 4.2.
> > > At the very least we should expand the set of conditions on which we base
> > > the decision on: certainly the presence of an audio device, maybe pci
> > > passthrough and the type of block backend (considering that some of them
> > > go through qemu now) in case they aren't working properly.
> > 
> > Tweaking the precise conditions is reasonable and indeed the main thrust
> > of the series is to allow to make this sort of determination and to
> > change our minds about it.
> 
> The danger of this approach is that stubdoms are not really transparent
> from the admin point of view.
> From the basic difference when you "xl list", to memory usage, a stubdom
> based setup is quite different from a non-stubdom based setup.
> If I were an admin I would really want to know when I am running one or
> the other.

> Making the change under their feet is bad enough but making a difference
> choice depending on a various set of variables is certainly not going to
> be popular.

Our recommendation as upstream is that stub domains are the most
scalable and secure configuration. I think our defaults should reflect
that.

Users who care specifically about stubdom or not can continue to force
the choice (using device_model_stubdomain_override=1|0 in their config).

Ian.
> 
> 
> > Disabling stub-dm in the face of an audio is a no brainer. PCI
> > passthrough less obviously so since itm in theory, works but given the
> > number of problems we've had with it I'm inclined to also gate on that.
> > 
> > Which leaves block devices which is an interesting one because currently
> > I don't have enough info in hand during
> > libxl__domain_build_info_setdefaults to make that determination. I shall
> > look at how I can resolve that.
> 
> Theoretically this case could also work with stubdoms because the block
> backend would be provided by the other qemu, the one running in dom0.
> However it is not probably going to work right now.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:15:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17: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 1Rmq8r-0000mM-OF; Mon, 16 Jan 2012 17:14:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmq8q-0000mH-Lu
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:14:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326734042!60433084!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28746 invoked from network); 16 Jan 2012 17:14:02 -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;
	16 Jan 2012 17:14:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10062759"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:14: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, 16 Jan 2012 17:14:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:14:43 +0000
In-Reply-To: <alpine.DEB.2.00.1201161615340.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
	<1326729772.14689.10.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201161615340.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326734083.14689.39.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 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 17:01 +0000, Stefano Stabellini wrote:
> On Mon, 16 Jan 2012, Ian Campbell wrote:
> > On Mon, 2012-01-16 at 15:53 +0000, Stefano Stabellini wrote:
> > > On Mon, 16 Jan 2012, Ian Campbell wrote:
> > > > # HG changeset patch
> > > > # User Ian Campbell <ian.campbell@citrix.com>
> > > > # Date 1326715929 0
> > > > # Node ID 953a1ce643856edcf9fbbbc2680690b3a26dede8
> > > > # Parent  a2dc899d0f229d82baca92a06b3b7a5b4d918324
> > > > libxl: Default to stub device model whenever possible.
> > > 
> > > Considering that stubdoms are not yet at feature parity I don't think we
> > > should make this change for 4.2.
> > > At the very least we should expand the set of conditions on which we base
> > > the decision on: certainly the presence of an audio device, maybe pci
> > > passthrough and the type of block backend (considering that some of them
> > > go through qemu now) in case they aren't working properly.
> > 
> > Tweaking the precise conditions is reasonable and indeed the main thrust
> > of the series is to allow to make this sort of determination and to
> > change our minds about it.
> 
> The danger of this approach is that stubdoms are not really transparent
> from the admin point of view.
> From the basic difference when you "xl list", to memory usage, a stubdom
> based setup is quite different from a non-stubdom based setup.
> If I were an admin I would really want to know when I am running one or
> the other.

> Making the change under their feet is bad enough but making a difference
> choice depending on a various set of variables is certainly not going to
> be popular.

Our recommendation as upstream is that stub domains are the most
scalable and secure configuration. I think our defaults should reflect
that.

Users who care specifically about stubdom or not can continue to force
the choice (using device_model_stubdomain_override=1|0 in their config).

Ian.
> 
> 
> > Disabling stub-dm in the face of an audio is a no brainer. PCI
> > passthrough less obviously so since itm in theory, works but given the
> > number of problems we've had with it I'm inclined to also gate on that.
> > 
> > Which leaves block devices which is an interesting one because currently
> > I don't have enough info in hand during
> > libxl__domain_build_info_setdefaults to make that determination. I shall
> > look at how I can resolve that.
> 
> Theoretically this case could also work with stubdoms because the block
> backend would be provided by the other qemu, the one running in dom0.
> However it is not probably going to work right now.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:28:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17: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 1RmqLO-0001GG-1i; Mon, 16 Jan 2012 17:27: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 1RmqLM-0001GB-E8
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:27:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326734853!10598042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19061 invoked from network); 16 Jan 2012 17:27:34 -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;
	16 Jan 2012 17:27:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:27: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, 16 Jan 2012 17:27:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:27:33 +0000
In-Reply-To: <1326732775-15485-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
	<1326732775-15485-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326734853.14689.41.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 v10 7/7] update MAINTAINERS file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:52 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Add Ian as Seabios maintainer and myself as upstream Qemu maintainer.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  MAINTAINERS |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 60f724d..cd0d71d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -176,6 +176,11 @@ M:	Ian Jackson <ian.jackson@eu.citrix.com>
>  S:	Supported
>  T:	git git://xenbits.xen.org/qemu-xen-*.git
>  
> +QEMU UPSTREAM
> +M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> +S:	Supported
> +T:	git git://xenbits.xen.org/qemu-upstream-*.git
> +
>  REMUS
>  M:	Shriram Rajagopalan <rshriram@cs.ubc.ca>
>  S:	Maintained
> @@ -190,6 +195,11 @@ M:	George Dunlap <george.dunlap@eu.citrix.com>
>  S:	Supported
>  F:	xen/common/sched*
>  
> +SEABIOS UPSTREAM
> +M:	Ian Campbell <ian.campbell@citrix.com>
> +S:	Supported
> +T:	git git://xenbits.xen.org/seabios.git
> +
>  STUB DOMAINS
>  M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>  S:	Supported



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:28:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17: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 1RmqLO-0001GG-1i; Mon, 16 Jan 2012 17:27: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 1RmqLM-0001GB-E8
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:27:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326734853!10598042!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19061 invoked from network); 16 Jan 2012 17:27:34 -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;
	16 Jan 2012 17:27:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063095"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:27: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, 16 Jan 2012 17:27:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:27:33 +0000
In-Reply-To: <1326732775-15485-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
	<1326732775-15485-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326734853.14689.41.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 v10 7/7] update MAINTAINERS file
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:52 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> Add Ian as Seabios maintainer and myself as upstream Qemu maintainer.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  MAINTAINERS |   10 ++++++++++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 60f724d..cd0d71d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -176,6 +176,11 @@ M:	Ian Jackson <ian.jackson@eu.citrix.com>
>  S:	Supported
>  T:	git git://xenbits.xen.org/qemu-xen-*.git
>  
> +QEMU UPSTREAM
> +M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> +S:	Supported
> +T:	git git://xenbits.xen.org/qemu-upstream-*.git
> +
>  REMUS
>  M:	Shriram Rajagopalan <rshriram@cs.ubc.ca>
>  S:	Maintained
> @@ -190,6 +195,11 @@ M:	George Dunlap <george.dunlap@eu.citrix.com>
>  S:	Supported
>  F:	xen/common/sched*
>  
> +SEABIOS UPSTREAM
> +M:	Ian Campbell <ian.campbell@citrix.com>
> +S:	Supported
> +T:	git git://xenbits.xen.org/seabios.git
> +
>  STUB DOMAINS
>  M:	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>  S:	Supported



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:28:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqM6-0001JO-Fv; Mon, 16 Jan 2012 17:28: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 1RmqM4-0001J1-Bs
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:28:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326734898!11081109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20826 invoked from network); 16 Jan 2012 17:28:18 -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;
	16 Jan 2012 17:28:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:28: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;
	Mon, 16 Jan 2012 17:28:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:28:17 +0000
In-Reply-To: <1326732775-15485-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
	<1326732775-15485-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326734897.14689.42.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 v10 5/7] 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, 2012-01-16 at 16:52 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Something is weird in your git metadata here..

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  .hgignore                         |    2 +
>  Config.mk                         |   12 ++-----
>  Makefile                          |    4 ++
>  tools/firmware/Makefile           |   21 ++++++++++-
>  tools/firmware/hvmloader/Makefile |    1 +
>  tools/firmware/seabios-config     |   73 +++++++++++++++++++++++++++++++++++++
>  6 files changed, 102 insertions(+), 11 deletions(-)
>  create mode 100644 tools/firmware/seabios-config
> 
> diff --git a/.hgignore b/.hgignore
> index cbcc0f5..64b440e 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -300,6 +300,8 @@
>  ^tools/qemu-xen-traditional-dir$
>  ^tools/qemu-xen-dir-remote
>  ^tools/qemu-xen-dir$
> +^tools/firmware/seabios-dir-remote
> +^tools/firmware/seabios-dir$
>  ^tools/ocaml/.*/.*\.annot$
>  ^tools/ocaml/.*/.*\.cmx?a$
>  ^tools/ocaml/.*/META$
> diff --git a/Config.mk b/Config.mk
> index d229ab6..152c783 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -204,10 +204,13 @@ endif
>  
>  ifeq ($(GIT_HTTP),y)
>  QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
> +SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
>  else
>  QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
> +SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  endif
>  QEMU_UPSTREAM_REVISION ?= master
> +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560
>  
>  # Specify which qemu-dm to use. This may be `ioemu' to use the old
>  # Mercurial in-tree version, or a local directory, or a git URL.
> @@ -221,15 +224,6 @@ QEMU_TAG ?= bb36d632e4cabf47882adff07a45c6702c4a5b30
>  # Short answer -- do not enable this unless you know what you are
>  # doing and are prepared for some pain.
>  
> -# SeaBIOS integration is a work in progress. Before enabling this
> -# option you must clone git://git.qemu.org/seabios.git/, possibly add
> -# some development patches and then build it yourself before pointing
> -# this variable to it (using an absolute path).
> -#
> -# Note that using SeaBIOS requires the use the upstream qemu as the
> -# device model.
> -SEABIOS_DIR ?= 
> -
>  # Optional components
>  XENSTAT_XENTOP     ?= y
>  VTPM_TOOLS         ?= n
> diff --git a/Makefile b/Makefile
> index edc5e3d..8edea0d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -98,6 +98,10 @@ tools/qemu-xen-dir:
>  tools/qemu-xen-dir-force-update:
>  	$(MAKE) -C tools qemu-xen-dir-force-update
>  
> +.PHONY: tools/firmware/seabios-dir-force-update
> +tools/firmware/seabios-dir-force-update:
> +	$(MAKE) -C tools/firmware seabios-dir-force-update
> +
>  .PHONY: install-docs
>  install-docs:
>  	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
> diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
> index 4b6d144..c3ec9a0 100644
> --- a/tools/firmware/Makefile
> +++ b/tools/firmware/Makefile
> @@ -6,13 +6,18 @@ TARGET      := hvmloader/hvmloader
>  INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
>  
>  SUBDIRS :=
> +SUBDIRS += seabios-dir
>  SUBDIRS += rombios
>  SUBDIRS += vgabios
>  SUBDIRS += etherboot
>  SUBDIRS += hvmloader
>  
> +seabios-dir:
> +	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
> +	cp seabios-config seabios-dir/.config;
> +
>  .PHONY: all
> -all:
> +all: seabios-dir
>  	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
>  	echo "==========================================================================="; \
>  	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
> @@ -35,4 +40,16 @@ clean: subdirs-clean
>  distclean: subdirs-distclean
>  
>  subdir-distclean-etherboot: .phony
> -	$(MAKE) -C etherboot distclean
> \ No newline at end of file
> +	$(MAKE) -C etherboot distclean
> +
> +subdir-distclean-seabios-dir: .phony
> +	rm -rf seabios-dir seabios-dir-remote
> +
> +.PHONY: seabios-dir-force-update
> +seabios-dir-force-update:
> +	set -ex; \
> +	if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \
> +		cd seabios-dir-remote; \
> +		$(GIT) fetch origin; \
> +		$(GIT) reset --hard $(SEABIOS_UPSTREAM_TAG); \
> +	fi
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index ec33155..41a4369 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS
>  ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
>  endif
>  
> +SEABIOS_DIR := ../seabios-dir
>  ifneq ($(SEABIOS_DIR),)
>  OBJS += seabios.o
>  CFLAGS += -DENABLE_SEABIOS
> diff --git a/tools/firmware/seabios-config b/tools/firmware/seabios-config
> new file mode 100644
> index 0000000..202d15f
> --- /dev/null
> +++ b/tools/firmware/seabios-config
> @@ -0,0 +1,73 @@
> +#
> +# Automatically generated make config: don't edit
> +# SeaBIOS Configuration
> +# Wed Sep  7 13:03:21 2011
> +#
> +
> +#
> +# General Features
> +#
> +# CONFIG_COREBOOT is not set
> +CONFIG_XEN=y
> +CONFIG_THREADS=y
> +# CONFIG_THREAD_OPTIONROMS is not set
> +CONFIG_RELOCATE_INIT=y
> +CONFIG_BOOTMENU=y
> +# CONFIG_BOOTSPLASH is not set
> +CONFIG_BOOTORDER=y
> +
> +#
> +# Hardware support
> +#
> +CONFIG_ATA=y
> +CONFIG_ATA_DMA=y
> +CONFIG_ATA_PIO32=y
> +CONFIG_AHCI=y
> +CONFIG_VIRTIO_BLK=y
> +CONFIG_FLOPPY=y
> +CONFIG_PS2PORT=y
> +CONFIG_USB=y
> +CONFIG_USB_UHCI=y
> +CONFIG_USB_OHCI=y
> +CONFIG_USB_EHCI=y
> +CONFIG_USB_MSC=y
> +CONFIG_USB_HUB=y
> +CONFIG_USB_KEYBOARD=y
> +CONFIG_USB_MOUSE=y
> +CONFIG_SERIAL=y
> +CONFIG_LPT=y
> +# CONFIG_USE_SMM is not set
> +CONFIG_MTRR_INIT=y
> +
> +#
> +# BIOS interfaces
> +#
> +CONFIG_DRIVES=y
> +CONFIG_CDROM_BOOT=y
> +CONFIG_CDROM_EMU=y
> +CONFIG_PCIBIOS=y
> +CONFIG_APMBIOS=y
> +CONFIG_PNPBIOS=y
> +CONFIG_OPTIONROMS=y
> +# CONFIG_OPTIONROMS_DEPLOYED is not set
> +CONFIG_PMM=y
> +CONFIG_BOOT=y
> +CONFIG_KEYBOARD=y
> +CONFIG_KBD_CALL_INT15_4F=y
> +CONFIG_MOUSE=y
> +CONFIG_S3_RESUME=y
> +# CONFIG_DISABLE_A20 is not set
> +
> +#
> +# BIOS Tables
> +#
> +CONFIG_PIRTABLE=y
> +CONFIG_MPTABLE=y
> +CONFIG_SMBIOS=y
> +CONFIG_ACPI=y
> +
> +#
> +# Debugging
> +#
> +CONFIG_DEBUG_LEVEL=1
> +# CONFIG_DEBUG_SERIAL 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 Mon Jan 16 17:28:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:28:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqM6-0001JO-Fv; Mon, 16 Jan 2012 17:28: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 1RmqM4-0001J1-Bs
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:28:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326734898!11081109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20826 invoked from network); 16 Jan 2012 17:28:18 -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;
	16 Jan 2012 17:28:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063109"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:28: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;
	Mon, 16 Jan 2012 17:28:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:28:17 +0000
In-Reply-To: <1326732775-15485-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
	<1326732775-15485-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326734897.14689.42.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 v10 5/7] 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, 2012-01-16 at 16:52 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: stefano.stabellini@eu.citrix.com <stefano.stabellini@eu.citrix.com>

Something is weird in your git metadata here..

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  .hgignore                         |    2 +
>  Config.mk                         |   12 ++-----
>  Makefile                          |    4 ++
>  tools/firmware/Makefile           |   21 ++++++++++-
>  tools/firmware/hvmloader/Makefile |    1 +
>  tools/firmware/seabios-config     |   73 +++++++++++++++++++++++++++++++++++++
>  6 files changed, 102 insertions(+), 11 deletions(-)
>  create mode 100644 tools/firmware/seabios-config
> 
> diff --git a/.hgignore b/.hgignore
> index cbcc0f5..64b440e 100644
> --- a/.hgignore
> +++ b/.hgignore
> @@ -300,6 +300,8 @@
>  ^tools/qemu-xen-traditional-dir$
>  ^tools/qemu-xen-dir-remote
>  ^tools/qemu-xen-dir$
> +^tools/firmware/seabios-dir-remote
> +^tools/firmware/seabios-dir$
>  ^tools/ocaml/.*/.*\.annot$
>  ^tools/ocaml/.*/.*\.cmx?a$
>  ^tools/ocaml/.*/META$
> diff --git a/Config.mk b/Config.mk
> index d229ab6..152c783 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -204,10 +204,13 @@ endif
>  
>  ifeq ($(GIT_HTTP),y)
>  QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
> +SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
>  else
>  QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
> +SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
>  endif
>  QEMU_UPSTREAM_REVISION ?= master
> +SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560
>  
>  # Specify which qemu-dm to use. This may be `ioemu' to use the old
>  # Mercurial in-tree version, or a local directory, or a git URL.
> @@ -221,15 +224,6 @@ QEMU_TAG ?= bb36d632e4cabf47882adff07a45c6702c4a5b30
>  # Short answer -- do not enable this unless you know what you are
>  # doing and are prepared for some pain.
>  
> -# SeaBIOS integration is a work in progress. Before enabling this
> -# option you must clone git://git.qemu.org/seabios.git/, possibly add
> -# some development patches and then build it yourself before pointing
> -# this variable to it (using an absolute path).
> -#
> -# Note that using SeaBIOS requires the use the upstream qemu as the
> -# device model.
> -SEABIOS_DIR ?= 
> -
>  # Optional components
>  XENSTAT_XENTOP     ?= y
>  VTPM_TOOLS         ?= n
> diff --git a/Makefile b/Makefile
> index edc5e3d..8edea0d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -98,6 +98,10 @@ tools/qemu-xen-dir:
>  tools/qemu-xen-dir-force-update:
>  	$(MAKE) -C tools qemu-xen-dir-force-update
>  
> +.PHONY: tools/firmware/seabios-dir-force-update
> +tools/firmware/seabios-dir-force-update:
> +	$(MAKE) -C tools/firmware seabios-dir-force-update
> +
>  .PHONY: install-docs
>  install-docs:
>  	sh ./docs/check_pkgs && $(MAKE) -C docs install || true
> diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
> index 4b6d144..c3ec9a0 100644
> --- a/tools/firmware/Makefile
> +++ b/tools/firmware/Makefile
> @@ -6,13 +6,18 @@ TARGET      := hvmloader/hvmloader
>  INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
>  
>  SUBDIRS :=
> +SUBDIRS += seabios-dir
>  SUBDIRS += rombios
>  SUBDIRS += vgabios
>  SUBDIRS += etherboot
>  SUBDIRS += hvmloader
>  
> +seabios-dir:
> +	GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(SEABIOS_UPSTREAM_URL) $(SEABIOS_UPSTREAM_TAG) seabios-dir
> +	cp seabios-config seabios-dir/.config;
> +
>  .PHONY: all
> -all:
> +all: seabios-dir
>  	@set -e; if [ $$((`( bcc -v 2>&1 | grep version || echo 0.0.0 ) | cut -d' ' -f 3 | awk -F. '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -lt $$((0x00100e)) ] ; then \
>  	echo "==========================================================================="; \
>  	echo "Require dev86 rpm or bin86 & bcc debs version >= 0.16.14 to build firmware!"; \
> @@ -35,4 +40,16 @@ clean: subdirs-clean
>  distclean: subdirs-distclean
>  
>  subdir-distclean-etherboot: .phony
> -	$(MAKE) -C etherboot distclean
> \ No newline at end of file
> +	$(MAKE) -C etherboot distclean
> +
> +subdir-distclean-seabios-dir: .phony
> +	rm -rf seabios-dir seabios-dir-remote
> +
> +.PHONY: seabios-dir-force-update
> +seabios-dir-force-update:
> +	set -ex; \
> +	if [ "$(SEABIOS_UPSTREAM_TAG)" ]; then \
> +		cd seabios-dir-remote; \
> +		$(GIT) fetch origin; \
> +		$(GIT) reset --hard $(SEABIOS_UPSTREAM_TAG); \
> +	fi
> diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile
> index ec33155..41a4369 100644
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -44,6 +44,7 @@ CFLAGS += -DENABLE_ROMBIOS
>  ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
>  endif
>  
> +SEABIOS_DIR := ../seabios-dir
>  ifneq ($(SEABIOS_DIR),)
>  OBJS += seabios.o
>  CFLAGS += -DENABLE_SEABIOS
> diff --git a/tools/firmware/seabios-config b/tools/firmware/seabios-config
> new file mode 100644
> index 0000000..202d15f
> --- /dev/null
> +++ b/tools/firmware/seabios-config
> @@ -0,0 +1,73 @@
> +#
> +# Automatically generated make config: don't edit
> +# SeaBIOS Configuration
> +# Wed Sep  7 13:03:21 2011
> +#
> +
> +#
> +# General Features
> +#
> +# CONFIG_COREBOOT is not set
> +CONFIG_XEN=y
> +CONFIG_THREADS=y
> +# CONFIG_THREAD_OPTIONROMS is not set
> +CONFIG_RELOCATE_INIT=y
> +CONFIG_BOOTMENU=y
> +# CONFIG_BOOTSPLASH is not set
> +CONFIG_BOOTORDER=y
> +
> +#
> +# Hardware support
> +#
> +CONFIG_ATA=y
> +CONFIG_ATA_DMA=y
> +CONFIG_ATA_PIO32=y
> +CONFIG_AHCI=y
> +CONFIG_VIRTIO_BLK=y
> +CONFIG_FLOPPY=y
> +CONFIG_PS2PORT=y
> +CONFIG_USB=y
> +CONFIG_USB_UHCI=y
> +CONFIG_USB_OHCI=y
> +CONFIG_USB_EHCI=y
> +CONFIG_USB_MSC=y
> +CONFIG_USB_HUB=y
> +CONFIG_USB_KEYBOARD=y
> +CONFIG_USB_MOUSE=y
> +CONFIG_SERIAL=y
> +CONFIG_LPT=y
> +# CONFIG_USE_SMM is not set
> +CONFIG_MTRR_INIT=y
> +
> +#
> +# BIOS interfaces
> +#
> +CONFIG_DRIVES=y
> +CONFIG_CDROM_BOOT=y
> +CONFIG_CDROM_EMU=y
> +CONFIG_PCIBIOS=y
> +CONFIG_APMBIOS=y
> +CONFIG_PNPBIOS=y
> +CONFIG_OPTIONROMS=y
> +# CONFIG_OPTIONROMS_DEPLOYED is not set
> +CONFIG_PMM=y
> +CONFIG_BOOT=y
> +CONFIG_KEYBOARD=y
> +CONFIG_KBD_CALL_INT15_4F=y
> +CONFIG_MOUSE=y
> +CONFIG_S3_RESUME=y
> +# CONFIG_DISABLE_A20 is not set
> +
> +#
> +# BIOS Tables
> +#
> +CONFIG_PIRTABLE=y
> +CONFIG_MPTABLE=y
> +CONFIG_SMBIOS=y
> +CONFIG_ACPI=y
> +
> +#
> +# Debugging
> +#
> +CONFIG_DEBUG_LEVEL=1
> +# CONFIG_DEBUG_SERIAL 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 Mon Jan 16 17:30:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqOF-0001Vm-6p; Mon, 16 Jan 2012 17:30:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmqOD-0001VG-Ta
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:30:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326735031!1991554!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23066 invoked from network); 16 Jan 2012 17:30:31 -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;
	16 Jan 2012 17:30:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:30:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 17:30:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:30:30 +0000
In-Reply-To: <1326733776.14689.35.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
	<20244.21874.852622.418848@mariner.uk.xensource.com>
	<1326733776.14689.35.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326735030.14689.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 21 of 32] libxl: drop vfs patch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 17:09 +0000, Ian Campbell wrote:
> On Mon, 2012-01-16 at 16:50 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 21 of 32] libxl: drop vfs patch"):
> > > libxl: drop vfs path -- fsback/front were deleted some time ago
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I was going to apply this, but it doesn't fit in the current tree.  I
> > guess the context is updated by earlier patches in your series.  So
> > for now:
> > 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Thanks, I'll pull it to the front for the next posting.

In fact, why I don't I just post the rebased version of that one patch
now, it doesn't really have much to do with this series.

This applies to current unstable.

8<------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326734948 0
# Node ID fed4bb058ea7200ef79b32f54254db92761fd258
# Parent  71571eced36ed674df3d38b4222c2a4bbebe0749
libxl: drop vfs path -- fsback/front were deleted some time ago

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 71571eced36e -r fed4bb058ea7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 16 17:26:03 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 16 17:29:08 2012 +0000
@@ -669,8 +669,6 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid));
     xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid), perm, ARRAY_SIZE(perm));
-    xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/%d/device/vfs", domid));
-    xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/%d/device/vfs",domid), perm, ARRAY_SIZE(perm));
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:30:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:30:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqOF-0001Vm-6p; Mon, 16 Jan 2012 17:30:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RmqOD-0001VG-Ta
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:30:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326735031!1991554!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23066 invoked from network); 16 Jan 2012 17:30:31 -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;
	16 Jan 2012 17:30:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063143"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:30:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 16 Jan 2012 17:30:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:30:30 +0000
In-Reply-To: <1326733776.14689.35.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
	<20244.21874.852622.418848@mariner.uk.xensource.com>
	<1326733776.14689.35.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326735030.14689.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 21 of 32] libxl: drop vfs patch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 17:09 +0000, Ian Campbell wrote:
> On Mon, 2012-01-16 at 16:50 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[Xen-devel] [PATCH 21 of 32] libxl: drop vfs patch"):
> > > libxl: drop vfs path -- fsback/front were deleted some time ago
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > I was going to apply this, but it doesn't fit in the current tree.  I
> > guess the context is updated by earlier patches in your series.  So
> > for now:
> > 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Thanks, I'll pull it to the front for the next posting.

In fact, why I don't I just post the rebased version of that one patch
now, it doesn't really have much to do with this series.

This applies to current unstable.

8<------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1326734948 0
# Node ID fed4bb058ea7200ef79b32f54254db92761fd258
# Parent  71571eced36ed674df3d38b4222c2a4bbebe0749
libxl: drop vfs path -- fsback/front were deleted some time ago

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 71571eced36e -r fed4bb058ea7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 16 17:26:03 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 16 17:29:08 2012 +0000
@@ -669,8 +669,6 @@ retry_transaction:
     t = xs_transaction_start(ctx->xsh);
     xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid));
     xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid), perm, ARRAY_SIZE(perm));
-    xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/%d/device/vfs", domid));
-    xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/%d/device/vfs",domid), perm, ARRAY_SIZE(perm));
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:41:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqYQ-0002Bn-W2; Mon, 16 Jan 2012 17: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 1RmqYP-0002Bf-Co
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:41:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326735663!11213251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15682 invoked from network); 16 Jan 2012 17:41:03 -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;
	16 Jan 2012 17:41:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:41:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 17:41:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RmqYI-0005Pu-66;
	Mon, 16 Jan 2012 17:41:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmqYI-0000QK-1Q;
	Mon, 16 Jan 2012 17:41:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10769-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:41:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10769: 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 10769 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10769/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10539
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-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          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

version targeted for testing:
 xen                  d5b26918cd94
baseline version:
 xen                  5d372b8bccef

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.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=d5b26918cd94
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d5b26918cd94
+ branch=xen-4.0-testing
+ revision=d5b26918cd94
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d5b26918cd94 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 Mon Jan 16 17:41:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqYQ-0002Bn-W2; Mon, 16 Jan 2012 17: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 1RmqYP-0002Bf-Co
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:41:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326735663!11213251!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15682 invoked from network); 16 Jan 2012 17:41:03 -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;
	16 Jan 2012 17:41:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063302"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:41:02 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 17:41:02 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RmqYI-0005Pu-66;
	Mon, 16 Jan 2012 17:41:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmqYI-0000QK-1Q;
	Mon, 16 Jan 2012 17:41:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10769-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:41:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10769: 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 10769 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10769/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10539
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-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          15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-amd64-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass

version targeted for testing:
 xen                  d5b26918cd94
baseline version:
 xen                  5d372b8bccef

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.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=d5b26918cd94
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d5b26918cd94
+ branch=xen-4.0-testing
+ revision=d5b26918cd94
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 d5b26918cd94 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 Mon Jan 16 17:46:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmqd9-0002Qc-S5; Mon, 16 Jan 2012 17:46:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmqd7-0002QK-9X
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:46:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326735955!11275024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15613 invoked from network); 16 Jan 2012 17:45:55 -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;
	16 Jan 2012 17:45:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063342"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:45: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;
	Mon, 16 Jan 2012 17:45:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:45:54 +0000
In-Reply-To: <20244.22029.761565.805780@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
	<20244.20607.725332.428230@mariner.uk.xensource.com>
	<1326732404.14689.34.camel@zakaz.uk.xensource.com>
	<20244.22029.761565.805780@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326735955.14689.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] [PATCH 14 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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 Mon, 2012-01-16 at 16:53 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configuration info build_info->u.hvm"):
> > While we are at it -- do you have any thoughts on how per-arch options
> > should be handled? I was thinking of adding the possibility in the IDL
> > to tag a field with a list of architectures?
> 
> If we eventually tunnel these structures over some kind of IPC
> mechanism it might be necessary to deal with values from other than
> the native architecture.

Hrm, yes.

> So perhaps per-arch fields should exist in every version and just have
> the arch in their name somehow, although that wouldn't spot people
> setting them inappropriately.
> 
> Alternative a variadic substructure where _init sets the enum to the
> default native arch ?

I wonder if these all fit into the existing build_info.u.{hvm,pv}. e.g.
if we shouldn't have hvm_x86,pv_x86,arm etc instead?

Another alternative is to do like we do for for foreign structures in
the hypervisor and generate compat versions of each struct as well as
native ones (e.g. libxl_x86_...).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:46:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmqd9-0002Qc-S5; Mon, 16 Jan 2012 17:46:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rmqd7-0002QK-9X
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:46:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326735955!11275024!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15613 invoked from network); 16 Jan 2012 17:45:55 -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;
	16 Jan 2012 17:45:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,518,1320624000"; d="scan'208";a="10063342"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:45: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;
	Mon, 16 Jan 2012 17:45:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 17:45:54 +0000
In-Reply-To: <20244.22029.761565.805780@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
	<20244.20607.725332.428230@mariner.uk.xensource.com>
	<1326732404.14689.34.camel@zakaz.uk.xensource.com>
	<20244.22029.761565.805780@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326735955.14689.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] [PATCH 14 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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 Mon, 2012-01-16 at 16:53 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configuration info build_info->u.hvm"):
> > While we are at it -- do you have any thoughts on how per-arch options
> > should be handled? I was thinking of adding the possibility in the IDL
> > to tag a field with a list of architectures?
> 
> If we eventually tunnel these structures over some kind of IPC
> mechanism it might be necessary to deal with values from other than
> the native architecture.

Hrm, yes.

> So perhaps per-arch fields should exist in every version and just have
> the arch in their name somehow, although that wouldn't spot people
> setting them inappropriately.
> 
> Alternative a variadic substructure where _init sets the enum to the
> default native arch ?

I wonder if these all fit into the existing build_info.u.{hvm,pv}. e.g.
if we shouldn't have hvm_x86,pv_x86,arm etc instead?

Another alternative is to do like we do for for foreign structures in
the hypervisor and generate compat versions of each struct as well as
native ones (e.g. libxl_x86_...).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:52:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17: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 1Rmqja-0002oP-Mu; Mon, 16 Jan 2012 17:52:42 +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 1RmqjZ-0002oK-Pa
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:52:41 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326736353!8597653!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 21791 invoked from network); 16 Jan 2012 17:52:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 17:52:34 -0000
Received: by dadp15 with SMTP id p15so19473025dad.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 09:52:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ftyiBNp6A6Hg20cy9eGY7bzALZ6n3+QUVgEsi9SwK7g=;
	b=xoCt2x94LVvtx2xhSu0EjkRwoeQyXPK92IBTD16TI3zpmsevfklff/Gm+c1GNwovUX
	A0bpj25jy3jVgd/hBhi7+qDWf8aD6Uw6byNr0JguLjnBpkh2jvXemgX1C3DAV7JiOunq
	RFHCr9hIVCSrrY80/i8niVaDXRqY5G2IJ1GQ4=
MIME-Version: 1.0
Received: by 10.68.116.12 with SMTP id js12mr28702399pbb.9.1326736352490; Mon,
	16 Jan 2012 09:52:32 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 16 Jan 2012 09:52:32 -0800 (PST)
In-Reply-To: <20239.3781.557131.765561@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 18:52:32 +0100
X-Google-Sender-Auth: il4_wXSifJztlBSJLlZS_UnS-bg
Message-ID: <CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEyIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBJYW4g
Q2FtcGJlbGwgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIERyaXZlciBkb21haW5zIGFuZCBob3Rw
bHVnIHNjcmlwdHMsIHJlZHV4Iik6Cj4+IFdlIG5lZWQgdG8gY29uc2lkZXIgMyBjYXNlczoKPj4g
wqAgwqAgwqAgKiBndWVzdCBpbml0aWF0ZWQgZ3JhY2VmdWwgc2h1dGRvd24KPj4gwqAgwqAgwqAg
KiB0b29sc3RhY2sgaW5pdGlhdGVkIGdyYWNlZnVsIHNodXRkb3duCj4+IMKgIMKgIMKgICogdG9v
bHN0YWNrIGluaXRpYXRlZCBmb3JjZWZ1bCBkZXN0cm95Lgo+Cj4gV2hlbiB3ZSBjb25zaWRlciB0
aGF0IHRoZSBkcml2ZXIgYW5kIHRvb2xzdGFjayBkb21haW5zIG1pZ2h0IGJlCj4gZGlmZmVyZW50
LCB0aGVyZSBhcmUgaW4gZmFjdCB0aHJlZSBkaWZmZXJlbnQgbGV2ZWxzIG9mIGdyYWNlOgo+IMKg
aS4gwqAgZnVsbHkgZ3JhY2VmdWw6IHdhaXQgZm9yIGJvdGggZ3Vlc3QgYW5kIGRyaXZlciBkb21h
aW4KPiDCoGlpLiDCoHNlbWkgZ3JhY2VmdWw6IG1lc3MgdXAgdGhlIGd1ZXN0LCB3YWl0IG9ubHkg
Zm9yIGRyaXZlciBkb21haW4KPiDCoGlpaS4gdmVyeSB1bmdyYWNlZnVsOiBtZXNzIHVwIHRoZSBn
dWVzdCBhbmQgdGhlIGRyaXZlciBkb21haW4KPgo+IEknbSBub3Qgc3VyZSB3aGV0aGVyIGhvdyBv
ZnRlbiB3ZSB3YW50IChpaWkpLCBidXQgKGlpKSBpcyBnb2luZyB0byBiZQo+IHRoZSBjb21tb24g
Y2FzZS4gwqBIb3dldmVyOgo+Cj4+IFRoZSBmb3JjZWZ1bCBkZXN0cm95IGNhc2UgaXMgZGlmZmVy
ZW50LCBpdCBpcyBlZmZlY3RpdmVseToKPj4gMS4gcm0gYmFja2VuZCBkaXIgaW4geGVuc3RvcmUu
Cj4KPiBUaGF0J3MgKGlpaSkuIMKgV2Ugd2FudCBhIHdheSB0byBkbyAoaWkpIGFzIHdlbGwuCgpG
cm9tIG15IHBvaW50IG9mIHZpZXcsIChpaWkpIHNob3VsZCBvbmx5IGhhcHBlbiBhZnRlciAoaSkg
b3IgKGlpKSBoYXMKZmFpbGVkICh0aW1lb3V0IG9yIGVycm9yIHRyeWluZyB0byB1bnBsdWcgZGV2
aWNlcykuCgpXaGF0IHNob3VsZCB3ZSBkbyB3aXRoIHhlbmQ/IEFyZSB3ZSBrZWVwaW5nIGl0IG9u
IDQuMj8gSSdtIGFza2luZyB0aGlzCmJlY2F1c2UgdGhlIGNoYW5nZXMgSSdtIGludHJvZHVjaW5n
IGRpc2FibGVzIHNvbWUgdWRldiBydWxlcyB0aGF0IGFyZQpuZWVkZWQgZm9yIHhlbmQuIFRoZSBv
dGhlciBvcHRpb24gaXMgdG8gdXBkYXRlIHhlbmQgdG8gdGFsayB0bwp4ZW5iYWNrZW5kZCBhbHNv
LgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:52:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17: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 1Rmqja-0002oP-Mu; Mon, 16 Jan 2012 17:52:42 +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 1RmqjZ-0002oK-Pa
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:52:41 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326736353!8597653!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 21791 invoked from network); 16 Jan 2012 17:52:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 17:52:34 -0000
Received: by dadp15 with SMTP id p15so19473025dad.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 09:52:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=ftyiBNp6A6Hg20cy9eGY7bzALZ6n3+QUVgEsi9SwK7g=;
	b=xoCt2x94LVvtx2xhSu0EjkRwoeQyXPK92IBTD16TI3zpmsevfklff/Gm+c1GNwovUX
	A0bpj25jy3jVgd/hBhi7+qDWf8aD6Uw6byNr0JguLjnBpkh2jvXemgX1C3DAV7JiOunq
	RFHCr9hIVCSrrY80/i8niVaDXRqY5G2IJ1GQ4=
MIME-Version: 1.0
Received: by 10.68.116.12 with SMTP id js12mr28702399pbb.9.1326736352490; Mon,
	16 Jan 2012 09:52:32 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Mon, 16 Jan 2012 09:52:32 -0800 (PST)
In-Reply-To: <20239.3781.557131.765561@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 18:52:32 +0100
X-Google-Sender-Auth: il4_wXSifJztlBSJLlZS_UnS-bg
Message-ID: <CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzEyIElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBJYW4g
Q2FtcGJlbGwgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIERyaXZlciBkb21haW5zIGFuZCBob3Rw
bHVnIHNjcmlwdHMsIHJlZHV4Iik6Cj4+IFdlIG5lZWQgdG8gY29uc2lkZXIgMyBjYXNlczoKPj4g
wqAgwqAgwqAgKiBndWVzdCBpbml0aWF0ZWQgZ3JhY2VmdWwgc2h1dGRvd24KPj4gwqAgwqAgwqAg
KiB0b29sc3RhY2sgaW5pdGlhdGVkIGdyYWNlZnVsIHNodXRkb3duCj4+IMKgIMKgIMKgICogdG9v
bHN0YWNrIGluaXRpYXRlZCBmb3JjZWZ1bCBkZXN0cm95Lgo+Cj4gV2hlbiB3ZSBjb25zaWRlciB0
aGF0IHRoZSBkcml2ZXIgYW5kIHRvb2xzdGFjayBkb21haW5zIG1pZ2h0IGJlCj4gZGlmZmVyZW50
LCB0aGVyZSBhcmUgaW4gZmFjdCB0aHJlZSBkaWZmZXJlbnQgbGV2ZWxzIG9mIGdyYWNlOgo+IMKg
aS4gwqAgZnVsbHkgZ3JhY2VmdWw6IHdhaXQgZm9yIGJvdGggZ3Vlc3QgYW5kIGRyaXZlciBkb21h
aW4KPiDCoGlpLiDCoHNlbWkgZ3JhY2VmdWw6IG1lc3MgdXAgdGhlIGd1ZXN0LCB3YWl0IG9ubHkg
Zm9yIGRyaXZlciBkb21haW4KPiDCoGlpaS4gdmVyeSB1bmdyYWNlZnVsOiBtZXNzIHVwIHRoZSBn
dWVzdCBhbmQgdGhlIGRyaXZlciBkb21haW4KPgo+IEknbSBub3Qgc3VyZSB3aGV0aGVyIGhvdyBv
ZnRlbiB3ZSB3YW50IChpaWkpLCBidXQgKGlpKSBpcyBnb2luZyB0byBiZQo+IHRoZSBjb21tb24g
Y2FzZS4gwqBIb3dldmVyOgo+Cj4+IFRoZSBmb3JjZWZ1bCBkZXN0cm95IGNhc2UgaXMgZGlmZmVy
ZW50LCBpdCBpcyBlZmZlY3RpdmVseToKPj4gMS4gcm0gYmFja2VuZCBkaXIgaW4geGVuc3RvcmUu
Cj4KPiBUaGF0J3MgKGlpaSkuIMKgV2Ugd2FudCBhIHdheSB0byBkbyAoaWkpIGFzIHdlbGwuCgpG
cm9tIG15IHBvaW50IG9mIHZpZXcsIChpaWkpIHNob3VsZCBvbmx5IGhhcHBlbiBhZnRlciAoaSkg
b3IgKGlpKSBoYXMKZmFpbGVkICh0aW1lb3V0IG9yIGVycm9yIHRyeWluZyB0byB1bnBsdWcgZGV2
aWNlcykuCgpXaGF0IHNob3VsZCB3ZSBkbyB3aXRoIHhlbmQ/IEFyZSB3ZSBrZWVwaW5nIGl0IG9u
IDQuMj8gSSdtIGFza2luZyB0aGlzCmJlY2F1c2UgdGhlIGNoYW5nZXMgSSdtIGludHJvZHVjaW5n
IGRpc2FibGVzIHNvbWUgdWRldiBydWxlcyB0aGF0IGFyZQpuZWVkZWQgZm9yIHhlbmQuIFRoZSBv
dGhlciBvcHRpb24gaXMgdG8gdXBkYXRlIHhlbmQgdG8gdGFsayB0bwp4ZW5iYWNrZW5kZCBhbHNv
LgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRl
dmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlz
dHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:56:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqnE-0002wP-Bn; Mon, 16 Jan 2012 17:56:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmqnC-0002wF-FJ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:56:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326736579!5152117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 16 Jan 2012 17:56:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 17:56:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="scan'208";a="10063477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:56:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 17:56: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
	1Rmqn4-0005VH-SC; Mon, 16 Jan 2012 17:56:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmqn4-0001BH-RY;
	Mon, 16 Jan 2012 17:56:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.25794.841199.497872@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 17:56:18 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326735030.14689.44.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
	<20244.21874.852622.418848@mariner.uk.xensource.com>
	<1326733776.14689.35.camel@zakaz.uk.xensource.com>
	<1326735030.14689.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 21 of 32] libxl: drop vfs patch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 21 of 32] libxl: drop vfs patch"):
> In fact, why I don't I just post the rebased version of that one patch
> now, it doesn't really have much to do with this series.
> 
> This applies to current unstable.

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 Jan 16 17:56:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqnE-0002wP-Bn; Mon, 16 Jan 2012 17:56:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RmqnC-0002wF-FJ
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:56:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326736579!5152117!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 16 Jan 2012 17:56:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 17:56:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="scan'208";a="10063477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:56:19 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 17:56: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
	1Rmqn4-0005VH-SC; Mon, 16 Jan 2012 17:56:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmqn4-0001BH-RY;
	Mon, 16 Jan 2012 17:56:18 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.25794.841199.497872@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 17:56:18 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326735030.14689.44.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<9771c7a1959e680ab8ef.1326716119@cosworth.uk.xensource.com>
	<20244.21874.852622.418848@mariner.uk.xensource.com>
	<1326733776.14689.35.camel@zakaz.uk.xensource.com>
	<1326735030.14689.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 21 of 32] libxl: drop vfs patch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 21 of 32] libxl: drop vfs patch"):
> In fact, why I don't I just post the rebased version of that one patch
> now, it doesn't really have much to do with this series.
> 
> This applies to current unstable.

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 Jan 16 17:58:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmqp1-000331-SW; Mon, 16 Jan 2012 17:58:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rmqoz-00032k-N0
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:58:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326736646!48793346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10937 invoked from network); 16 Jan 2012 17:57:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 17:57:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="scan'208";a="10063492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:58:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 17:58: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
	1Rmqot-0005Vx-8J; Mon, 16 Jan 2012 17:58:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmqot-0001Bh-7d;
	Mon, 16 Jan 2012 17:58:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.25907.223422.50324@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 17:58:11 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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] Driver domains and hotplug scrip=
ts, redux"):
> 2012/1/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Ian Campbell writes ("Re: [Xen-devel] Driver domains and hotplug script=
s, redux"):
> >> The forceful destroy case is different, it is effectively:
> >> 1. rm backend dir in xenstore.
> >
> > That's (iii). =A0We want a way to do (ii) as well.
> =

> From my point of view, (iii) should only happen after (i) or (ii) has
> failed (timeout or error trying to unplug devices).

There has to be a user option to ask for a "very forceful" detach.

> What should we do with xend? Are we keeping it on 4.2? I'm asking this
> because the changes I'm introducing disables some udev rules that are
> needed for xend. The other option is to update xend to talk to
> xenbackendd also.

I think xend is not going to go away in 4.2, unfortunately.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 17:58:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 17:58:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmqp1-000331-SW; Mon, 16 Jan 2012 17:58:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rmqoz-00032k-N0
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 17:58:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326736646!48793346!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10937 invoked from network); 16 Jan 2012 17:57:26 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 17:57:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="scan'208";a="10063492"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 17:58:11 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 16 Jan 2012 17:58: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
	1Rmqot-0005Vx-8J; Mon, 16 Jan 2012 17:58:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rmqot-0001Bh-7d;
	Mon, 16 Jan 2012 17:58:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20244.25907.223422.50324@mariner.uk.xensource.com>
Date: Mon, 16 Jan 2012 17:58:11 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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] Driver domains and hotplug scrip=
ts, redux"):
> 2012/1/12 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Ian Campbell writes ("Re: [Xen-devel] Driver domains and hotplug script=
s, redux"):
> >> The forceful destroy case is different, it is effectively:
> >> 1. rm backend dir in xenstore.
> >
> > That's (iii). =A0We want a way to do (ii) as well.
> =

> From my point of view, (iii) should only happen after (i) or (ii) has
> failed (timeout or error trying to unplug devices).

There has to be a user option to ask for a "very forceful" detach.

> What should we do with xend? Are we keeping it on 4.2? I'm asking this
> because the changes I'm introducing disables some udev rules that are
> needed for xend. The other option is to update xend to talk to
> xenbackendd also.

I think xend is not going to go away in 4.2, unfortunately.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 18:01:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 18:01:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqrX-0003IE-MP; Mon, 16 Jan 2012 18:00:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RmqrW-0003Hs-L4; Mon, 16 Jan 2012 18:00:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326736848!9380503!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2022 invoked from network); 16 Jan 2012 18:00:48 -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;
	16 Jan 2012 18:00:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="scan'208";a="10063568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 18:00: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; Mon, 16 Jan 2012 18:00:47 +0000
Date: Mon, 16 Jan 2012 18:01:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1326716171-4298-2-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.00.1201161800510.3150@kaball-desktop>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
	<1326716171-4298-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/5] arm: allow libxc to build (untested)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 16 Jan 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  Config.mk                 |    2 +-
>  tools/libxc/Makefile      |    1 +
>  tools/libxc/xc_core.h     |    2 +
>  tools/libxc/xc_core_arm.c |   70 +++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_core_arm.h |   61 +++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xenctrl.h     |    4 ++
>  6 files changed, 139 insertions(+), 1 deletions(-)
>  create mode 100644 tools/libxc/xc_core_arm.c
>  create mode 100644 tools/libxc/xc_core_arm.h
> 
> diff --git a/Config.mk b/Config.mk
> index 1c229c0..13a569e 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -13,7 +13,7 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
>  debug ?= y
>  
>  XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
> -                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
> +                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
>  XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
>  XEN_OS              ?= $(shell uname -s)
>  
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index b5e7022..b5bd7fb 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -6,6 +6,7 @@ MINOR    = 0
>  
>  CTRL_SRCS-y       :=
>  CTRL_SRCS-y       += xc_core.c
> +CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
>  CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
>  CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
>  CTRL_SRCS-y       += xc_cpupool.c
> diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
> index 1e88a75..358a8c1 100644
> --- a/tools/libxc/xc_core.h
> +++ b/tools/libxc/xc_core.h
> @@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
>  # include "xc_core_x86.h"
>  #elif defined (__ia64__)
>  # include "xc_core_ia64.h"
> +#elif defined (__arm__)
> +# include "xc_core_arm.h"
>  #else
>  # error "unsupported architecture"
>  #endif
> diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
> new file mode 100644
> index 0000000..9009295
> --- /dev/null
> +++ b/tools/libxc/xc_core_arm.c
> @@ -0,0 +1,70 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2012 Citrix Systems Ltd.
> + */
> +
> +#include "xg_private.h"
> +#include "xc_core.h"
> +
> +int
> +xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> +                              unsigned long pfn)
> +{
> +    /* default to trying to map the page */
> +    /* TODO consult p2m */
> +    return 1;
> +}
> +
> +int
> +xc_core_arch_memory_map_get(xc_interface *xch,
> +                            struct xc_core_arch_context *arch_ctxt,
> +                            xc_dominfo_t *info,
> +                            shared_info_any_t *live_shinfo,
> +                            xc_core_memory_map_t **mapp,
> +                            unsigned int *nr_entries)
> +{
> +    /* TODO return the memory map! */
> +    ERROR("%s is not implemented yet\n", __func__);
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int
> +xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
> +{
> +    /* All domains are auto_translated_physmap mode. */
> +    return 1;
> +}
> +
> +int
> +xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
> +                     shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
> +                     unsigned long *pfnp)
> +{
> +    /* All domains are auto_translated_physmap mode. */
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
> new file mode 100644
> index 0000000..a2ef5a8
> --- /dev/null
> +++ b/tools/libxc/xc_core_arm.h
> @@ -0,0 +1,61 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2007 Isaku Yamahata <yamahata at valinux co jp>
> + *                    VA Linux Systems Japan K.K.
> + *
> + */
> +
> +#ifndef XC_CORE_ARM_H
> +#define XC_CORE_ARM_H
> +
> +#define ELF_ARCH_DATA           ELFDATA2LSB
> +#define ELF_ARCH_MACHINE        EM_ARM
> +
> +struct xc_core_arch_context {
> +    /* nothing */
> +};
> +
> +#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
> +#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
> +#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
> +                                                                (0)
> +#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
> +
> +int
> +xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> +                              unsigned long pfn);
> +static inline int
> +xc_core_arch_context_get_shdr(xc_interface *xch,
> +                              struct xc_core_arch_context *arch_ctxt, 
> +                              struct xc_core_section_headers *sheaders,
> +                              struct xc_core_strtab *strtab,
> +                              uint64_t *filesz, uint64_t offset)
> +{

/* TODO */ ?

> +    *filesz = 0;
> +    return 0;
> +}
> +
> +#endif /* XC_CORE_ARM_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> index 1e149c1..1054584 100644
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -81,6 +81,10 @@
>  #define xen_mb()   asm volatile ("mf" ::: "memory")
>  #define xen_rmb()  asm volatile ("mf" ::: "memory")
>  #define xen_wmb()  asm volatile ("mf" ::: "memory")
> +#elif defined(__arm__)
> +#define xen_mb()   asm volatile ("dsb" : : : "memory")
> +#define xen_rmb()  asm volatile ("dsb" : : : "memory")
> +#define xen_wmb()  asm volatile ("dsb" : : : "memory")
>  #else
>  #error "Define barriers"
>  #endif
 
I think the memory barriers are correct

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 18:01:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 18:01:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RmqrX-0003IE-MP; Mon, 16 Jan 2012 18:00:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RmqrW-0003Hs-L4; Mon, 16 Jan 2012 18:00:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326736848!9380503!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTMwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2022 invoked from network); 16 Jan 2012 18:00:48 -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;
	16 Jan 2012 18:00:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="scan'208";a="10063568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 18:00: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; Mon, 16 Jan 2012 18:00:47 +0000
Date: Mon, 16 Jan 2012 18:01:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <1326716171-4298-2-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.00.1201161800510.3150@kaball-desktop>
References: <1326715371.17210.417.camel@zakaz.uk.xensource.com>
	<1326716171-4298-1-git-send-email-ian.campbell@citrix.com>
	<1326716171-4298-2-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/5] arm: allow libxc to build (untested)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 16 Jan 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  Config.mk                 |    2 +-
>  tools/libxc/Makefile      |    1 +
>  tools/libxc/xc_core.h     |    2 +
>  tools/libxc/xc_core_arm.c |   70 +++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xc_core_arm.h |   61 +++++++++++++++++++++++++++++++++++++++
>  tools/libxc/xenctrl.h     |    4 ++
>  6 files changed, 139 insertions(+), 1 deletions(-)
>  create mode 100644 tools/libxc/xc_core_arm.c
>  create mode 100644 tools/libxc/xc_core_arm.h
> 
> diff --git a/Config.mk b/Config.mk
> index 1c229c0..13a569e 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -13,7 +13,7 @@ realpath = $(wildcard $(foreach file,$(1),$(shell cd -P $(dir $(file)) && echo "
>  debug ?= y
>  
>  XEN_COMPILE_ARCH    ?= $(shell uname -m | sed -e s/i.86/x86_32/ \
> -                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/)
> +                         -e s/i86pc/x86_32/ -e s/amd64/x86_64/ -e s/arm.*/arm/)
>  XEN_TARGET_ARCH     ?= $(XEN_COMPILE_ARCH)
>  XEN_OS              ?= $(shell uname -s)
>  
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index b5e7022..b5bd7fb 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -6,6 +6,7 @@ MINOR    = 0
>  
>  CTRL_SRCS-y       :=
>  CTRL_SRCS-y       += xc_core.c
> +CTRL_SRCS-$(CONFIG_ARM) += xc_core_arm.c
>  CTRL_SRCS-$(CONFIG_X86) += xc_core_x86.c
>  CTRL_SRCS-$(CONFIG_IA64) += xc_core_ia64.c
>  CTRL_SRCS-y       += xc_cpupool.c
> diff --git a/tools/libxc/xc_core.h b/tools/libxc/xc_core.h
> index 1e88a75..358a8c1 100644
> --- a/tools/libxc/xc_core.h
> +++ b/tools/libxc/xc_core.h
> @@ -155,6 +155,8 @@ int xc_core_arch_map_p2m_writable(xc_interface *xch, unsigned int guest_width,
>  # include "xc_core_x86.h"
>  #elif defined (__ia64__)
>  # include "xc_core_ia64.h"
> +#elif defined (__arm__)
> +# include "xc_core_arm.h"
>  #else
>  # error "unsupported architecture"
>  #endif
> diff --git a/tools/libxc/xc_core_arm.c b/tools/libxc/xc_core_arm.c
> new file mode 100644
> index 0000000..9009295
> --- /dev/null
> +++ b/tools/libxc/xc_core_arm.c
> @@ -0,0 +1,70 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation;
> + * version 2.1 of the License.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2012 Citrix Systems Ltd.
> + */
> +
> +#include "xg_private.h"
> +#include "xc_core.h"
> +
> +int
> +xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> +                              unsigned long pfn)
> +{
> +    /* default to trying to map the page */
> +    /* TODO consult p2m */
> +    return 1;
> +}
> +
> +int
> +xc_core_arch_memory_map_get(xc_interface *xch,
> +                            struct xc_core_arch_context *arch_ctxt,
> +                            xc_dominfo_t *info,
> +                            shared_info_any_t *live_shinfo,
> +                            xc_core_memory_map_t **mapp,
> +                            unsigned int *nr_entries)
> +{
> +    /* TODO return the memory map! */
> +    ERROR("%s is not implemented yet\n", __func__);
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +int
> +xc_core_arch_auto_translated_physmap(const xc_dominfo_t *info)
> +{
> +    /* All domains are auto_translated_physmap mode. */
> +    return 1;
> +}
> +
> +int
> +xc_core_arch_map_p2m(xc_interface *xch, unsigned int guest_width, xc_dominfo_t *info,
> +                     shared_info_any_t *live_shinfo, xen_pfn_t **live_p2m,
> +                     unsigned long *pfnp)
> +{
> +    /* All domains are auto_translated_physmap mode. */
> +    errno = ENOSYS;
> +    return -1;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xc_core_arm.h b/tools/libxc/xc_core_arm.h
> new file mode 100644
> index 0000000..a2ef5a8
> --- /dev/null
> +++ b/tools/libxc/xc_core_arm.h
> @@ -0,0 +1,61 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with this library; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + * Copyright (c) 2007 Isaku Yamahata <yamahata at valinux co jp>
> + *                    VA Linux Systems Japan K.K.
> + *
> + */
> +
> +#ifndef XC_CORE_ARM_H
> +#define XC_CORE_ARM_H
> +
> +#define ELF_ARCH_DATA           ELFDATA2LSB
> +#define ELF_ARCH_MACHINE        EM_ARM
> +
> +struct xc_core_arch_context {
> +    /* nothing */
> +};
> +
> +#define xc_core_arch_context_init(arch_ctxt)            do {} while (0)
> +#define xc_core_arch_context_free(arch_ctxt)            do {} while (0)
> +#define xc_core_arch_context_get(arch_ctxt, ctxt, xch, domid) \
> +                                                                (0)
> +#define xc_core_arch_context_dump(xch, arch_ctxt, args, dump_rtn)    (0)
> +
> +int
> +xc_core_arch_gpfn_may_present(struct xc_core_arch_context *arch_ctxt,
> +                              unsigned long pfn);
> +static inline int
> +xc_core_arch_context_get_shdr(xc_interface *xch,
> +                              struct xc_core_arch_context *arch_ctxt, 
> +                              struct xc_core_section_headers *sheaders,
> +                              struct xc_core_strtab *strtab,
> +                              uint64_t *filesz, uint64_t offset)
> +{

/* TODO */ ?

> +    *filesz = 0;
> +    return 0;
> +}
> +
> +#endif /* XC_CORE_ARM_H */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-set-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
> index 1e149c1..1054584 100644
> --- a/tools/libxc/xenctrl.h
> +++ b/tools/libxc/xenctrl.h
> @@ -81,6 +81,10 @@
>  #define xen_mb()   asm volatile ("mf" ::: "memory")
>  #define xen_rmb()  asm volatile ("mf" ::: "memory")
>  #define xen_wmb()  asm volatile ("mf" ::: "memory")
> +#elif defined(__arm__)
> +#define xen_mb()   asm volatile ("dsb" : : : "memory")
> +#define xen_rmb()  asm volatile ("dsb" : : : "memory")
> +#define xen_wmb()  asm volatile ("dsb" : : : "memory")
>  #else
>  #error "Define barriers"
>  #endif
 
I think the memory barriers are correct

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 19:00:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 19:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmrml-0004Xl-Jl; Mon, 16 Jan 2012 19:00:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1Rmrmj-0004VU-6D; Mon, 16 Jan 2012 19:00:01 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326740393!11169099!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 8284 invoked from network); 16 Jan 2012 18:59:54 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 18:59:54 -0000
Received: by werb10 with SMTP id b10so1997045wer.30
	for <multiple recipients>; Mon, 16 Jan 2012 10:59:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=ao/wH834oXo3Q6J2krM7bF/vS/S+JZmgnvCOg/nM5Jw=;
	b=JNeilv8lfWlm4jWz38ELWHfxjbqL1EI4KtV55Gu86c41UUcnwuMcAPKlICGrB26HCt
	PY9uYCfwdExWCbpewrk1mT0iZcApnjTwG9XlVgJMNafw8EfV6eZQHwY3wTSjjVOfflGQ
	nUOTF4P26kX58QtplqskJxis9QhVNGwfNuBKk=
Received: by 10.216.136.155 with SMTP id w27mr7023478wei.8.1326740390353;
	Mon, 16 Jan 2012 10:59:50 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id fy5sm35693754wib.7.2012.01.16.10.59.48
	(version=SSLv3 cipher=OTHER); Mon, 16 Jan 2012 10:59:48 -0800 (PST)
Message-ID: <4F1473A2.4060103@xen.org>
Date: Mon, 16 Jan 2012 18:59:46 +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-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	xen-arm@lists.xensource.com
Subject: [Xen-devel] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everybody,

I have been asked when we should hold the next Xen Document Day. Rather 
than going through this every single month, I am proposing dates until 
March. I.e.
- January 30, 2012
- Feb 27, 2012
- March 26, 2012
Please go to the Xen Document Days etherpad page 
(http://openetherpad.org/TSPGIEOBiS) to propose a new date or to vote 
for a day.

I also listed items that could be worked on, on the etherpad page (and 
removed stuff which has been done). Feel free to add to it. It is 
actually quite incredible how much we (and YOU) did in the last two Xen 
Document Days. I wanted to thank everybody who was involved!

I am also looking for a couple of volunteers (moderators), in particular 
in Asia and/or Australia and in the US who commit to being on the 
#xendocday IRC channels for a few hours and points other participates to 
this document and generally provides advice. If you are interested, 
please also sign up on the Xen Document Days etherpad page.

Best Regards
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 19:00:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 19:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmrml-0004Xl-Jl; Mon, 16 Jan 2012 19:00:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1Rmrmj-0004VU-6D; Mon, 16 Jan 2012 19:00:01 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326740393!11169099!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 8284 invoked from network); 16 Jan 2012 18:59:54 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	16 Jan 2012 18:59:54 -0000
Received: by werb10 with SMTP id b10so1997045wer.30
	for <multiple recipients>; Mon, 16 Jan 2012 10:59:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=ao/wH834oXo3Q6J2krM7bF/vS/S+JZmgnvCOg/nM5Jw=;
	b=JNeilv8lfWlm4jWz38ELWHfxjbqL1EI4KtV55Gu86c41UUcnwuMcAPKlICGrB26HCt
	PY9uYCfwdExWCbpewrk1mT0iZcApnjTwG9XlVgJMNafw8EfV6eZQHwY3wTSjjVOfflGQ
	nUOTF4P26kX58QtplqskJxis9QhVNGwfNuBKk=
Received: by 10.216.136.155 with SMTP id w27mr7023478wei.8.1326740390353;
	Mon, 16 Jan 2012 10:59:50 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id fy5sm35693754wib.7.2012.01.16.10.59.48
	(version=SSLv3 cipher=OTHER); Mon, 16 Jan 2012 10:59:48 -0800 (PST)
Message-ID: <4F1473A2.4060103@xen.org>
Date: Mon, 16 Jan 2012 18:59:46 +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-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	xen-arm@lists.xensource.com
Subject: [Xen-devel] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi everybody,

I have been asked when we should hold the next Xen Document Day. Rather 
than going through this every single month, I am proposing dates until 
March. I.e.
- January 30, 2012
- Feb 27, 2012
- March 26, 2012
Please go to the Xen Document Days etherpad page 
(http://openetherpad.org/TSPGIEOBiS) to propose a new date or to vote 
for a day.

I also listed items that could be worked on, on the etherpad page (and 
removed stuff which has been done). Feel free to add to it. It is 
actually quite incredible how much we (and YOU) did in the last two Xen 
Document Days. I wanted to thank everybody who was involved!

I am also looking for a couple of volunteers (moderators), in particular 
in Asia and/or Australia and in the US who commit to being on the 
#xendocday IRC channels for a few hours and points other participates to 
this document and generally provides advice. If you are interested, 
please also sign up on the Xen Document Days etherpad page.

Best Regards
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 21:13:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 21:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmtqk-00064c-NU; Mon, 16 Jan 2012 21:12:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Rmtqj-00064X-4Z
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 21:12:17 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326748327!1531555!1
X-Originating-IP: [216.32.181.184]
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 15947 invoked from network); 16 Jan 2012 21:12:09 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Jan 2012 21:12:09 -0000
Received: from mail19-ch1-R.bigfish.com (10.43.68.249) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Mon, 16 Jan 2012 21:12:02 +0000
Received: from mail19-ch1 (localhost [127.0.0.1])	by mail19-ch1-R.bigfish.com
	(Postfix) with ESMTP id A5DE04A01F3	for
	<xen-devel@lists.xensource.com>; Mon,
	16 Jan 2012 21:12:03 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail19-ch1 (localhost.localdomain [127.0.0.1]) by mail19-ch1
	(MessageSwitch) id 1326748321286196_22527;
	Mon, 16 Jan 2012 21:12:01 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.240])	by mail19-ch1.bigfish.com (Postfix) with ESMTP id
	31EC3700046 for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 21:12:01 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Mon, 16 Jan 2012 21:11:56 +0000
X-WSS-ID: 0LXWTJW-02-03Q-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 2572DC808F	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 15:11:55 -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;
	Mon, 16 Jan 2012 15:12:03 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 16 Jan 2012 15:11:57 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Jan 2012
	16:11:56 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2F0D649C2B0; Mon, 16 Jan 2012
	21:11:55 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 1A1E72D202B; Mon,
	16 Jan 2012 22:11:55 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f157d40df95aa3b8becb970968d33f4eca6c7e75
Message-ID: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Mon, 16 Jan 2012 22:11:17 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com
Subject: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature in
	guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1326748089 -3600
# Node ID f157d40df95aa3b8becb970968d33f4eca6c7e75
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 5b2676ac1321 -r f157d40df95a tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+		    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
@@ -524,7 +525,6 @@ static void xc_cpuid_pv_policy(
         clear_bit(X86_FEATURE_RDTSCP, regs[3]);
 
         clear_bit(X86_FEATURE_SVM, regs[2]);
-        clear_bit(X86_FEATURE_OSVW, regs[2]);
         clear_bit(X86_FEATURE_IBS, regs[2]);
         clear_bit(X86_FEATURE_SKINIT, regs[2]);
         clear_bit(X86_FEATURE_WDT, regs[2]);
diff -r 5b2676ac1321 -r f157d40df95a xen/arch/x86/cpu/amd.c
--- a/xen/arch/x86/cpu/amd.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/cpu/amd.c	Mon Jan 16 22:08:09 2012 +0100
@@ -32,6 +32,13 @@
 static char opt_famrev[14];
 string_param("cpuid_mask_cpu", opt_famrev);
 
+/*
+ * Set osvw_len to higher number when updated Revision Guides
+ * are published and we know what the new status bits are
+ */
+static uint64_t osvw_length = 4, osvw_status;
+static DEFINE_SPINLOCK(amd_lock);
+
 static inline void wrmsr_amd(unsigned int index, unsigned int lo, 
 		unsigned int hi)
 {
@@ -182,6 +189,35 @@ static void __devinit set_cpuidmask(cons
 	}
 }
 
+static void amd_guest_osvw_init(struct vcpu *vcpu)
+{
+    if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+	return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.amd.osvw.length = (osvw_length >= 3) ? (osvw_length) : 3;
+    vcpu->arch.amd.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if (osvw_length == 0 && boot_cpu_data.x86 == 0x10)
+	vcpu->arch.amd.osvw.status |= 1;
+}
+
+void amd_vcpu_initialise(struct vcpu *vcpu)
+{
+    amd_guest_osvw_init(vcpu);
+}
+
 /*
  * Check for the presence of an AMD erratum. Arguments are defined in amd.h 
  * for each known erratum. Return 1 if erratum is found.
@@ -512,6 +548,30 @@ static void __devinit init_amd(struct cp
 	set_cpuidmask(c);
 
 	check_syscfg_dram_mod_en();
+
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+     if (test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability)) {
+         uint64_t len, status;
+
+        if (rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+            rdmsr_safe(MSR_AMD_OSVW_STATUS, status))
+            len = status = 0;
+
+        spin_lock(&amd_lock);
+        
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+
+        spin_unlock(&amd_lock);
+    } else
+	 osvw_length = osvw_status = 0;
 }
 
 static struct cpu_dev amd_cpu_dev __cpuinitdata = {
diff -r 5b2676ac1321 -r f157d40df95a xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/domain.c	Mon Jan 16 22:08:09 2012 +0100
@@ -422,6 +422,10 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc = vcpu_init_fpu(v)) != 0 )
         return rc;
 
+    /* Vendor-specific initialization */
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+        amd_vcpu_initialise(v);
+
     if ( is_hvm_domain(d) )
     {
         rc = hvm_vcpu_initialise(v);
diff -r 5b2676ac1321 -r f157d40df95a xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Mon Jan 16 22:08:09 2012 +0100
@@ -1044,6 +1044,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, uint read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if (!test_bit((X86_FEATURE_OSVW & 31), &ecx))
+        return -1;
+
+    if (read) {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.amd.osvw.length;
+        else
+            *val = v->arch.amd.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1385,6 +1406,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if (ret < 0)
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1509,6 +1537,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if (ret < 0)
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r 5b2676ac1321 -r f157d40df95a xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/traps.c	Mon Jan 16 22:08:09 2012 +0100
@@ -71,6 +71,7 @@
 #include <asm/apic.h>
 #include <asm/mc146818rtc.h>
 #include <asm/hpet.h>
+#include <asm/amd.h>
 #include <public/arch-x86/cpuid.h>
 #include <xsm/xsm.h>
 
@@ -889,7 +890,6 @@ static void pv_cpuid(struct cpu_user_reg
         __clear_bit(X86_FEATURE_SVM % 32, &c);
         if ( !cpu_has_apic )
            __clear_bit(X86_FEATURE_EXTAPIC % 32, &c);
-        __clear_bit(X86_FEATURE_OSVW % 32, &c);
         __clear_bit(X86_FEATURE_IBS % 32, &c);
         __clear_bit(X86_FEATURE_SKINIT % 32, &c);
         __clear_bit(X86_FEATURE_WDT % 32, &c);
@@ -2542,6 +2542,15 @@ static int emulate_privileged_op(struct 
             if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
                 goto fail;
             break;
+        case MSR_AMD_OSVW_ID_LENGTH:
+        case MSR_AMD_OSVW_STATUS:
+            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) {
+                if (!boot_cpu_has(X86_FEATURE_OSVW))
+                    goto fail;
+                else
+                    break; /* Writes are ignored */
+            }
+            /* Fall through to default case */
         default:
             if ( wrmsr_hypervisor_regs(regs->ecx, msr_content) )
                 break;
@@ -2573,6 +2582,7 @@ static int emulate_privileged_op(struct 
         break;
 
     case 0x32: /* RDMSR */
+
         switch ( (u32)regs->ecx )
         {
 #ifdef CONFIG_X86_64
@@ -2632,6 +2642,23 @@ static int emulate_privileged_op(struct 
             regs->eax = (uint32_t)msr_content;
             regs->edx = (uint32_t)(msr_content >> 32);
             break;
+        case MSR_AMD_OSVW_ID_LENGTH:
+        case MSR_AMD_OSVW_STATUS:
+            if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+                if (!boot_cpu_has(X86_FEATURE_OSVW))
+                    goto fail;
+                else {
+                    if ((u32)regs->ecx == MSR_AMD_OSVW_ID_LENGTH)
+                        msr_content = v->arch.amd.osvw.length;
+                    else
+                        msr_content = v->arch.amd.osvw.status;
+
+                    regs->eax = (uint32_t)msr_content;
+                    regs->edx = (uint32_t)(msr_content >> 32);
+                }
+            } else
+                goto rdmsr_normal;
+            break;
         default:
             if ( rdmsr_hypervisor_regs(regs->ecx, &val) )
             {
diff -r 5b2676ac1321 -r f157d40df95a xen/include/asm-x86/amd.h
--- a/xen/include/asm-x86/amd.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/include/asm-x86/amd.h	Mon Jan 16 22:08:09 2012 +0100
@@ -140,7 +140,17 @@
                        AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
                        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
 
+struct vcpu_amd {
+
+    /* OSVW MSRs */
+    struct {
+	u64 length;
+	u64 status;
+    } osvw;
+};
+
 struct cpuinfo_x86;
+void amd_vcpu_initialise(struct vcpu *);
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
 
 #ifdef __x86_64__
diff -r 5b2676ac1321 -r f157d40df95a xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/include/asm-x86/domain.h	Mon Jan 16 22:08:09 2012 +0100
@@ -8,6 +8,7 @@
 #include <asm/hvm/domain.h>
 #include <asm/e820.h>
 #include <asm/mce.h>
+#include <asm/amd.h>
 #include <public/vcpu.h>
 
 #define has_32bit_shinfo(d)    ((d)->arch.has_32bit_shinfo)
@@ -495,6 +496,11 @@ struct arch_vcpu
 
     uint32_t gdbsx_vcpu_event;
 
+    /* Vendor-specific data */
+    union {
+        struct vcpu_amd amd;
+    };
+
     /* A secondary copy of the vcpu time info. */
     XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 21:13:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 21:13:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmtqk-00064c-NU; Mon, 16 Jan 2012 21:12:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1Rmtqj-00064X-4Z
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 21:12:17 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326748327!1531555!1
X-Originating-IP: [216.32.181.184]
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 15947 invoked from network); 16 Jan 2012 21:12:09 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-5.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	16 Jan 2012 21:12:09 -0000
Received: from mail19-ch1-R.bigfish.com (10.43.68.249) by
	CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id
	14.1.225.23; Mon, 16 Jan 2012 21:12:02 +0000
Received: from mail19-ch1 (localhost [127.0.0.1])	by mail19-ch1-R.bigfish.com
	(Postfix) with ESMTP id A5DE04A01F3	for
	<xen-devel@lists.xensource.com>; Mon,
	16 Jan 2012 21:12:03 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1ahc1bh668h839h944h)
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 mail19-ch1 (localhost.localdomain [127.0.0.1]) by mail19-ch1
	(MessageSwitch) id 1326748321286196_22527;
	Mon, 16 Jan 2012 21:12:01 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.240])	by mail19-ch1.bigfish.com (Postfix) with ESMTP id
	31EC3700046 for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 21:12:01 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Mon, 16 Jan 2012 21:11:56 +0000
X-WSS-ID: 0LXWTJW-02-03Q-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 2572DC808F	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 15:11:55 -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;
	Mon, 16 Jan 2012 15:12:03 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag03.amd.com
	(163.181.55.3) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Mon, 16 Jan 2012 15:11:57 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Jan 2012
	16:11:56 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2F0D649C2B0; Mon, 16 Jan 2012
	21:11:55 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 1A1E72D202B; Mon,
	16 Jan 2012 22:11:55 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: f157d40df95aa3b8becb970968d33f4eca6c7e75
Message-ID: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Mon, 16 Jan 2012 22:11:17 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com
Subject: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature in
	guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1326748089 -3600
# Node ID f157d40df95aa3b8becb970968d33f4eca6c7e75
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>

diff -r 5b2676ac1321 -r f157d40df95a tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+		    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
@@ -524,7 +525,6 @@ static void xc_cpuid_pv_policy(
         clear_bit(X86_FEATURE_RDTSCP, regs[3]);
 
         clear_bit(X86_FEATURE_SVM, regs[2]);
-        clear_bit(X86_FEATURE_OSVW, regs[2]);
         clear_bit(X86_FEATURE_IBS, regs[2]);
         clear_bit(X86_FEATURE_SKINIT, regs[2]);
         clear_bit(X86_FEATURE_WDT, regs[2]);
diff -r 5b2676ac1321 -r f157d40df95a xen/arch/x86/cpu/amd.c
--- a/xen/arch/x86/cpu/amd.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/cpu/amd.c	Mon Jan 16 22:08:09 2012 +0100
@@ -32,6 +32,13 @@
 static char opt_famrev[14];
 string_param("cpuid_mask_cpu", opt_famrev);
 
+/*
+ * Set osvw_len to higher number when updated Revision Guides
+ * are published and we know what the new status bits are
+ */
+static uint64_t osvw_length = 4, osvw_status;
+static DEFINE_SPINLOCK(amd_lock);
+
 static inline void wrmsr_amd(unsigned int index, unsigned int lo, 
 		unsigned int hi)
 {
@@ -182,6 +189,35 @@ static void __devinit set_cpuidmask(cons
 	}
 }
 
+static void amd_guest_osvw_init(struct vcpu *vcpu)
+{
+    if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+	return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.amd.osvw.length = (osvw_length >= 3) ? (osvw_length) : 3;
+    vcpu->arch.amd.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if (osvw_length == 0 && boot_cpu_data.x86 == 0x10)
+	vcpu->arch.amd.osvw.status |= 1;
+}
+
+void amd_vcpu_initialise(struct vcpu *vcpu)
+{
+    amd_guest_osvw_init(vcpu);
+}
+
 /*
  * Check for the presence of an AMD erratum. Arguments are defined in amd.h 
  * for each known erratum. Return 1 if erratum is found.
@@ -512,6 +548,30 @@ static void __devinit init_amd(struct cp
 	set_cpuidmask(c);
 
 	check_syscfg_dram_mod_en();
+
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+     if (test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability)) {
+         uint64_t len, status;
+
+        if (rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+            rdmsr_safe(MSR_AMD_OSVW_STATUS, status))
+            len = status = 0;
+
+        spin_lock(&amd_lock);
+        
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+
+        spin_unlock(&amd_lock);
+    } else
+	 osvw_length = osvw_status = 0;
 }
 
 static struct cpu_dev amd_cpu_dev __cpuinitdata = {
diff -r 5b2676ac1321 -r f157d40df95a xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/domain.c	Mon Jan 16 22:08:09 2012 +0100
@@ -422,6 +422,10 @@ int vcpu_initialise(struct vcpu *v)
     if ( (rc = vcpu_init_fpu(v)) != 0 )
         return rc;
 
+    /* Vendor-specific initialization */
+    if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+        amd_vcpu_initialise(v);
+
     if ( is_hvm_domain(d) )
     {
         rc = hvm_vcpu_initialise(v);
diff -r 5b2676ac1321 -r f157d40df95a xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/hvm/svm/svm.c	Mon Jan 16 22:08:09 2012 +0100
@@ -1044,6 +1044,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, uint read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if (!test_bit((X86_FEATURE_OSVW & 31), &ecx))
+        return -1;
+
+    if (read) {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.amd.osvw.length;
+        else
+            *val = v->arch.amd.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1385,6 +1406,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if (ret < 0)
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1509,6 +1537,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if (ret < 0)
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r 5b2676ac1321 -r f157d40df95a xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/traps.c	Mon Jan 16 22:08:09 2012 +0100
@@ -71,6 +71,7 @@
 #include <asm/apic.h>
 #include <asm/mc146818rtc.h>
 #include <asm/hpet.h>
+#include <asm/amd.h>
 #include <public/arch-x86/cpuid.h>
 #include <xsm/xsm.h>
 
@@ -889,7 +890,6 @@ static void pv_cpuid(struct cpu_user_reg
         __clear_bit(X86_FEATURE_SVM % 32, &c);
         if ( !cpu_has_apic )
            __clear_bit(X86_FEATURE_EXTAPIC % 32, &c);
-        __clear_bit(X86_FEATURE_OSVW % 32, &c);
         __clear_bit(X86_FEATURE_IBS % 32, &c);
         __clear_bit(X86_FEATURE_SKINIT % 32, &c);
         __clear_bit(X86_FEATURE_WDT % 32, &c);
@@ -2542,6 +2542,15 @@ static int emulate_privileged_op(struct 
             if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
                 goto fail;
             break;
+        case MSR_AMD_OSVW_ID_LENGTH:
+        case MSR_AMD_OSVW_STATUS:
+            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) {
+                if (!boot_cpu_has(X86_FEATURE_OSVW))
+                    goto fail;
+                else
+                    break; /* Writes are ignored */
+            }
+            /* Fall through to default case */
         default:
             if ( wrmsr_hypervisor_regs(regs->ecx, msr_content) )
                 break;
@@ -2573,6 +2582,7 @@ static int emulate_privileged_op(struct 
         break;
 
     case 0x32: /* RDMSR */
+
         switch ( (u32)regs->ecx )
         {
 #ifdef CONFIG_X86_64
@@ -2632,6 +2642,23 @@ static int emulate_privileged_op(struct 
             regs->eax = (uint32_t)msr_content;
             regs->edx = (uint32_t)(msr_content >> 32);
             break;
+        case MSR_AMD_OSVW_ID_LENGTH:
+        case MSR_AMD_OSVW_STATUS:
+            if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+                if (!boot_cpu_has(X86_FEATURE_OSVW))
+                    goto fail;
+                else {
+                    if ((u32)regs->ecx == MSR_AMD_OSVW_ID_LENGTH)
+                        msr_content = v->arch.amd.osvw.length;
+                    else
+                        msr_content = v->arch.amd.osvw.status;
+
+                    regs->eax = (uint32_t)msr_content;
+                    regs->edx = (uint32_t)(msr_content >> 32);
+                }
+            } else
+                goto rdmsr_normal;
+            break;
         default:
             if ( rdmsr_hypervisor_regs(regs->ecx, &val) )
             {
diff -r 5b2676ac1321 -r f157d40df95a xen/include/asm-x86/amd.h
--- a/xen/include/asm-x86/amd.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/include/asm-x86/amd.h	Mon Jan 16 22:08:09 2012 +0100
@@ -140,7 +140,17 @@
                        AMD_MODEL_RANGE(0x11, 0x0, 0x0, 0xff, 0xf),	\
                        AMD_MODEL_RANGE(0x12, 0x0, 0x0, 0xff, 0xf))
 
+struct vcpu_amd {
+
+    /* OSVW MSRs */
+    struct {
+	u64 length;
+	u64 status;
+    } osvw;
+};
+
 struct cpuinfo_x86;
+void amd_vcpu_initialise(struct vcpu *);
 int cpu_has_amd_erratum(const struct cpuinfo_x86 *, int, ...);
 
 #ifdef __x86_64__
diff -r 5b2676ac1321 -r f157d40df95a xen/include/asm-x86/domain.h
--- a/xen/include/asm-x86/domain.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/include/asm-x86/domain.h	Mon Jan 16 22:08:09 2012 +0100
@@ -8,6 +8,7 @@
 #include <asm/hvm/domain.h>
 #include <asm/e820.h>
 #include <asm/mce.h>
+#include <asm/amd.h>
 #include <public/vcpu.h>
 
 #define has_32bit_shinfo(d)    ((d)->arch.has_32bit_shinfo)
@@ -495,6 +496,11 @@ struct arch_vcpu
 
     uint32_t gdbsx_vcpu_event;
 
+    /* Vendor-specific data */
+    union {
+        struct vcpu_amd amd;
+    };
+
     /* A secondary copy of the vcpu time info. */
     XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 21:21:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 21: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 1RmtzF-0006Kh-Ri; Mon, 16 Jan 2012 21:21:05 +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 1RmtzE-0006KY-6B
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 21:21:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326748858!11172599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTQxNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5863 invoked from network); 16 Jan 2012 21:20:58 -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;
	16 Jan 2012 21:20:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="scan'208";a="10070976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 21:20: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, 16 Jan 2012 21:20: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 1Rmtz7-0006gO-Hd;
	Mon, 16 Jan 2012 21:20:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rmtz7-0005kx-Gx;
	Mon, 16 Jan 2012 21:20:57 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10771-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 21:20:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10771: 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 10771 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10771/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xl-multivcpu 11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl           11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-credit2   11 guest-localmigrate        fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  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

version targeted for testing:
 xen                  0d4a60bf37b9
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                           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                                 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 780 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 Jan 16 21:21:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 21: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 1RmtzF-0006Kh-Ri; Mon, 16 Jan 2012 21:21:05 +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 1RmtzE-0006KY-6B
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 21:21:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326748858!11172599!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTQxNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5863 invoked from network); 16 Jan 2012 21:20:58 -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;
	16 Jan 2012 21:20:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,519,1320624000"; d="scan'208";a="10070976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	16 Jan 2012 21:20: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, 16 Jan 2012 21:20: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 1Rmtz7-0006gO-Hd;
	Mon, 16 Jan 2012 21:20:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rmtz7-0005kx-Gx;
	Mon, 16 Jan 2012 21:20:57 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10771-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 16 Jan 2012 21:20:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10771: 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 10771 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10771/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xl-multivcpu 11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl           11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-credit2   11 guest-localmigrate        fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  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

version targeted for testing:
 xen                  0d4a60bf37b9
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                           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                                 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 780 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 Jan 16 22:36:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 22: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 1RmvA0-0007DC-C4; Mon, 16 Jan 2012 22:36:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rmv9y-0007D4-NE
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 22:36:14 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326753366!11299924!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6807 invoked from network); 16 Jan 2012 22:36:07 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 22:36:07 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0GMa5QA006416
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 17:36:05 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Mon, 16 Jan 2012 17:35:49 -0500
MIME-Version: 1.0
X-Mercurial-Node: 301cc006677f645bf4cb3d9d4d09507d2779420d
Message-Id: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 16 Jan 2012 17:36:03 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 16 Jan 2012 22:35:49.0416 (UTC)
	FILETIME=[32358A80:01CCD49F]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl_pci: check that host device is assignable
 before adding 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

Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Mon Jan 16 17:31:25 2012 -0500
@@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
     libxl_device_pci *assigned;
     int num_assigned, i, rc;
     int stubdomid = 0;
+    struct dirent *de;
+    DIR *dir;
+    int assignable = 0;
 
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {
@@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
         goto out;
     }
 
+    dir = opendir(SYSFS_PCIBACK_DRIVER);
+    if ( NULL == dir ) {
+        if ( errno == ENOENT ) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
+        }else{
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
+        }
+        rc = ERROR_FAIL;
+        goto out_closedir;
+    }
+
+    while( (de = readdir(dir)) ) {
+        unsigned dom, bus, dev, func;
+        if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
+            continue;
+        if ( dom == pcidev->domain && bus == pcidev->bus &&
+              dev == pcidev->dev && func == pcidev->func ) {
+            assignable = 1;
+            break;
+        }
+    }
+
+    if ( !assignable ) {
+        rc = ERROR_FAIL;
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
+        goto out_closedir;
+    }
+
+
     libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
 
     stubdomid = libxl_get_stubdom_id(ctx, domid);
@@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
         /* stubdomain is always running by now, even at create time */
         rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
         if ( rc )
-            goto out;
+            goto out_closedir;
     }
 
     orig_vdev = pcidev->vdevfn & ~7U;
@@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
         if ( !(pcidev->vdevfn >> 3) ) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
             rc = ERROR_INVAL;
-            goto out;
+            goto out_closedir;
         }
         if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_closedir;
         }
         pcidev->vfunc_mask &= pfunc_mask;
         /* so now vfunc_mask == pfunc_mask */
@@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
         }
     }
 
+out_closedir:
+    closedir(dir);
 out:
     return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 16 22:36:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 16 Jan 2012 22: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 1RmvA0-0007DC-C4; Mon, 16 Jan 2012 22:36:16 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rmv9y-0007D4-NE
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 22:36:14 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326753366!11299924!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6807 invoked from network); 16 Jan 2012 22:36:07 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 22:36:07 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0GMa5QA006416
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 17:36:05 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Mon, 16 Jan 2012 17:35:49 -0500
MIME-Version: 1.0
X-Mercurial-Node: 301cc006677f645bf4cb3d9d4d09507d2779420d
Message-Id: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Mon, 16 Jan 2012 17:36:03 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 16 Jan 2012 22:35:49.0416 (UTC)
	FILETIME=[32358A80:01CCD49F]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH] libxl_pci: check that host device is assignable
 before adding 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

Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Mon Jan 16 17:31:25 2012 -0500
@@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
     libxl_device_pci *assigned;
     int num_assigned, i, rc;
     int stubdomid = 0;
+    struct dirent *de;
+    DIR *dir;
+    int assignable = 0;
 
     rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
     if ( rc ) {
@@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
         goto out;
     }
 
+    dir = opendir(SYSFS_PCIBACK_DRIVER);
+    if ( NULL == dir ) {
+        if ( errno == ENOENT ) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
+        }else{
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
+        }
+        rc = ERROR_FAIL;
+        goto out_closedir;
+    }
+
+    while( (de = readdir(dir)) ) {
+        unsigned dom, bus, dev, func;
+        if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
+            continue;
+        if ( dom == pcidev->domain && bus == pcidev->bus &&
+              dev == pcidev->dev && func == pcidev->func ) {
+            assignable = 1;
+            break;
+        }
+    }
+
+    if ( !assignable ) {
+        rc = ERROR_FAIL;
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
+        goto out_closedir;
+    }
+
+
     libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
 
     stubdomid = libxl_get_stubdom_id(ctx, domid);
@@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
         /* stubdomain is always running by now, even at create time */
         rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
         if ( rc )
-            goto out;
+            goto out_closedir;
     }
 
     orig_vdev = pcidev->vdevfn & ~7U;
@@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
         if ( !(pcidev->vdevfn >> 3) ) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
             rc = ERROR_INVAL;
-            goto out;
+            goto out_closedir;
         }
         if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
             rc = ERROR_FAIL;
-            goto out;
+            goto out_closedir;
         }
         pcidev->vfunc_mask &= pfunc_mask;
         /* so now vfunc_mask == pfunc_mask */
@@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
         }
     }
 
+out_closedir:
+    closedir(dir);
 out:
     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 Jan 17 00:51:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 00: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 1RmxFo-0000Fi-Sk; Tue, 17 Jan 2012 00:50:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Antony.Saba@mandiant.com>) id 1RmxFn-0000Fd-M8
	for xen-devel@lists.xen.org; Tue, 17 Jan 2012 00:50:23 +0000
X-Env-Sender: Antony.Saba@mandiant.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326761416!7554832!1
X-Originating-IP: [165.212.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTY1LjIxMi42NC4yMiA9PiA4ODY2Njg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32009 invoked from network); 17 Jan 2012 00:50:17 -0000
Received: from gateout02.mbox.net (HELO gateout02.mbox.net) (165.212.64.22)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 00:50:17 -0000
Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1])
	by gateout02.mbox.net (Postfix) with ESMTP id CD9B6410002
	for <xen-devel@lists.xen.org>; Tue, 17 Jan 2012 00:50:14 +0000 (GMT)
X-USANET-Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net
	via mtad (C8.MAIN.3.72B) 
	with ESMTP id 092qaqaYm8480Mo2; Tue, 17 Jan 2012 00:50:12 -0000
Received: from S1HUB5.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net
	via smtad (C8.MAIN.3.72B) 
	with ESMTPS id XID896qaqaYm2302Xo2; Tue, 17 Jan 2012 00:50:12 -0000
X-USANET-Source: 165.212.120.254 IN Antony.Saba@mandiant.com
	S1HUB5.EXCHPROD.USA.NET
X-USANET-MsgId: XID896qaqaYm2302Xo2
Received: from MBX3.EXCHPROD.USA.NET ([10.120.221.31]) by
	S1HUB5.EXCHPROD.USA.NET ([10.120.220.35]) with mapi; Tue, 17 Jan 2012
	00:50:05 +0000
From: Antony Saba <Antony.Saba@mandiant.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Tue, 17 Jan 2012 00:50:01 +0000
Thread-Topic: Problems calling HVMOP_flush_tlbs
Thread-Index: AczUsfPNvr7hMdedTR+pQNZ77OMhWA==
Message-ID: <4F14C5B9.9080501@mandiant.com>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222
	Thunderbird/9.0.1
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] Problems calling HVMOP_flush_tlbs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 xen-devel,

I am using xen 4.2.1 and have tried the following with kernel 3.0.0 and 
3.2.1.

I am trying to invoke the HVMOP_flush_tlbs hypercall but have been 
unsuccessful.  I am basing my call on the functions in in xc_misc.c, 
trying to guess what is meant by "@arg must be null" in the comment 
where HVMOP_flush_tlbs is defined.  What is the correct way to invoke 
this hypercall?

If I call it like this, I receive an invalid parameter (EINVAL) error:
     struct privcmd_hypercall
     {
         uint64_t op;
         uint64_t arg[5];
     } hypercall;
     hypercall.op     = __HYPERVISOR_hvm_op;
     hypercall.arg[0] = HVMOP_flush_tlbs;
     hypercall.arg[1] = 0;
     ret = do_xen_hypercall(xch, (void*)&hypercall);


If I call it like this, I get function not implemented (ENOSYS), where 3 
is a valid domain id:
     hypercall.op     = __HYPERVISOR_hvm_op;
     hypercall.arg[0] = HVMOP_flush_tlbs;
     hypercall.arg[1] = 3;  /* 3 is the domain whose tlbs should be 
flushed */
     hypercall.arg[2] = 0;

I have also tried this, mimicking the arg struct for the other HVMOP 
calls, which also returns ENOSYS:
    typedef struct _arg_t {
         domid_t domid;
         uint64_t ptr;
    } arg_t;
    struct privcmd_hypercall {
         uint64_t op;
         uint64_t arg[5];
     } hypercall;
     DECLARE_HYPERCALL_BUFFER(arg_t, arg);
     arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));

     hypercall.op     = __HYPERVISOR_hvm_op;
     hypercall.arg[0] = HVMOP_flush_tlbs;
     hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
     hypercall.arg[2]= 0;
     arg->ptr = 0;
     arg->domid = 0; /* or a valid dom id, the results are the same */


Any help is appreciated.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 00:51:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 00: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 1RmxFo-0000Fi-Sk; Tue, 17 Jan 2012 00:50:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Antony.Saba@mandiant.com>) id 1RmxFn-0000Fd-M8
	for xen-devel@lists.xen.org; Tue, 17 Jan 2012 00:50:23 +0000
X-Env-Sender: Antony.Saba@mandiant.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326761416!7554832!1
X-Originating-IP: [165.212.64.22]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTY1LjIxMi42NC4yMiA9PiA4ODY2Njg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32009 invoked from network); 17 Jan 2012 00:50:17 -0000
Received: from gateout02.mbox.net (HELO gateout02.mbox.net) (165.212.64.22)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 00:50:17 -0000
Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1])
	by gateout02.mbox.net (Postfix) with ESMTP id CD9B6410002
	for <xen-devel@lists.xen.org>; Tue, 17 Jan 2012 00:50:14 +0000 (GMT)
X-USANET-Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net
	via mtad (C8.MAIN.3.72B) 
	with ESMTP id 092qaqaYm8480Mo2; Tue, 17 Jan 2012 00:50:12 -0000
Received: from S1HUB5.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net
	via smtad (C8.MAIN.3.72B) 
	with ESMTPS id XID896qaqaYm2302Xo2; Tue, 17 Jan 2012 00:50:12 -0000
X-USANET-Source: 165.212.120.254 IN Antony.Saba@mandiant.com
	S1HUB5.EXCHPROD.USA.NET
X-USANET-MsgId: XID896qaqaYm2302Xo2
Received: from MBX3.EXCHPROD.USA.NET ([10.120.221.31]) by
	S1HUB5.EXCHPROD.USA.NET ([10.120.220.35]) with mapi; Tue, 17 Jan 2012
	00:50:05 +0000
From: Antony Saba <Antony.Saba@mandiant.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Date: Tue, 17 Jan 2012 00:50:01 +0000
Thread-Topic: Problems calling HVMOP_flush_tlbs
Thread-Index: AczUsfPNvr7hMdedTR+pQNZ77OMhWA==
Message-ID: <4F14C5B9.9080501@mandiant.com>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222
	Thunderbird/9.0.1
acceptlanguage: en-US
MIME-Version: 1.0
Subject: [Xen-devel] Problems calling HVMOP_flush_tlbs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 xen-devel,

I am using xen 4.2.1 and have tried the following with kernel 3.0.0 and 
3.2.1.

I am trying to invoke the HVMOP_flush_tlbs hypercall but have been 
unsuccessful.  I am basing my call on the functions in in xc_misc.c, 
trying to guess what is meant by "@arg must be null" in the comment 
where HVMOP_flush_tlbs is defined.  What is the correct way to invoke 
this hypercall?

If I call it like this, I receive an invalid parameter (EINVAL) error:
     struct privcmd_hypercall
     {
         uint64_t op;
         uint64_t arg[5];
     } hypercall;
     hypercall.op     = __HYPERVISOR_hvm_op;
     hypercall.arg[0] = HVMOP_flush_tlbs;
     hypercall.arg[1] = 0;
     ret = do_xen_hypercall(xch, (void*)&hypercall);


If I call it like this, I get function not implemented (ENOSYS), where 3 
is a valid domain id:
     hypercall.op     = __HYPERVISOR_hvm_op;
     hypercall.arg[0] = HVMOP_flush_tlbs;
     hypercall.arg[1] = 3;  /* 3 is the domain whose tlbs should be 
flushed */
     hypercall.arg[2] = 0;

I have also tried this, mimicking the arg struct for the other HVMOP 
calls, which also returns ENOSYS:
    typedef struct _arg_t {
         domid_t domid;
         uint64_t ptr;
    } arg_t;
    struct privcmd_hypercall {
         uint64_t op;
         uint64_t arg[5];
     } hypercall;
     DECLARE_HYPERCALL_BUFFER(arg_t, arg);
     arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));

     hypercall.op     = __HYPERVISOR_hvm_op;
     hypercall.arg[0] = HVMOP_flush_tlbs;
     hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
     hypercall.arg[2]= 0;
     arg->ptr = 0;
     arg->domid = 0; /* or a valid dom id, the results are the same */


Any help is appreciated.

-Tony

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 02:51:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 02:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmz8b-0005MK-VO; Tue, 17 Jan 2012 02:51:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rmz8a-0005MA-0E
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 02:51:04 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326768655!8564472!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22492 invoked from network); 17 Jan 2012 02:50:56 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 02:50:56 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0H2opFt017000;
	Mon, 16 Jan 2012 21:50:52 -0500
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 16 Jan 2012 21:50:30 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451AA@mnetexch2.adamapps.host>
In-Reply-To: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
	specificpci cap on host bridge.
Thread-Index: AczUXZEW1GAOiNjDQCidFbChJ+FwhgAZLekA
References: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
From: <djmagee@mageenet.net>
To: "Jean Guyader" <jean.guyader@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Subject: Re: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
	specificpci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This always fails because it checks cap_type before it's set.  Moving the pt_pci_host_read call before the check gets rid of these messages in qemu log:

pcilib: sysfs_read: read failed: Invalid argument

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Jean Guyader
Sent: Monday, January 16, 2012 9:40 AM
To: xen-devel@lists.xensource.com
Cc: Ian.Jackson@eu.citrix.com; allen.m.kay@intel.com; Jean Guyader
Subject: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor specificpci cap on host bridge.


Some versions of the Windows Intel GPU driver expect the vendor PCI capability to be there on the host bridge config space when passing through a Intel GPU.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 46 insertions(+), 5 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 02:51:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 02:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rmz8b-0005MK-VO; Tue, 17 Jan 2012 02:51:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rmz8a-0005MA-0E
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 02:51:04 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326768655!8564472!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22492 invoked from network); 17 Jan 2012 02:50:56 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 02:50:56 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0H2opFt017000;
	Mon, 16 Jan 2012 21:50:52 -0500
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 16 Jan 2012 21:50:30 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451AA@mnetexch2.adamapps.host>
In-Reply-To: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
	specificpci cap on host bridge.
Thread-Index: AczUXZEW1GAOiNjDQCidFbChJ+FwhgAZLekA
References: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
From: <djmagee@mageenet.net>
To: "Jean Guyader" <jean.guyader@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Subject: Re: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
	specificpci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This always fails because it checks cap_type before it's set.  Moving the pt_pci_host_read call before the check gets rid of these messages in qemu log:

pcilib: sysfs_read: read failed: Invalid argument

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Jean Guyader
Sent: Monday, January 16, 2012 9:40 AM
To: xen-devel@lists.xensource.com
Cc: Ian.Jackson@eu.citrix.com; allen.m.kay@intel.com; Jean Guyader
Subject: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor specificpci cap on host bridge.


Some versions of the Windows Intel GPU driver expect the vendor PCI capability to be there on the host bridge config space when passing through a Intel GPU.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 46 insertions(+), 5 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 03:06:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 03: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 1RmzMY-0005Z7-4J; Tue, 17 Jan 2012 03:05: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 1RmzMW-0005Yo-Ub
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 03:05:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326769521!9419529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTQxNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27001 invoked from network); 17 Jan 2012 03:05:21 -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;
	17 Jan 2012 03:05:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,521,1320624000"; d="scan'208";a="10073561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 03:05:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 03:05: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 1RmzMO-000085-Qb;
	Tue, 17 Jan 2012 03:05:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmzMO-0000jH-Pi;
	Tue, 17 Jan 2012 03:05:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10776-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 03:05:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10776: 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 10776 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10776/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xl-multivcpu 11 guest-localmigrate        fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl           11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install               fail   like 10645

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  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

version targeted for testing:
 xen                  2913ccc6d70f
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                           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                                 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 815 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 Jan 17 03:06:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 03: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 1RmzMN-0005Yd-NK; Tue, 17 Jan 2012 03:05:19 +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 1RmzML-0005YY-9w
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 03:05:17 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326769509!1558263!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk3MjQx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22169 invoked from network); 17 Jan 2012 03:05:10 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-21.messagelabs.com with SMTP;
	17 Jan 2012 03:05:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Jan 2012 19:05:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="97219398"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 16 Jan 2012 19:05:02 -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; Tue, 17 Jan 2012 11:03:33 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Jan 2012 11:03:33 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Tue, 17 Jan 2012 11:03:31 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, liang tang
	<liang.tang@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: AQHMwR8jSQj+OztfxUuz+mAW9L1uCZXtWRMwgA1TuICAA+19QIAL4bKAgAWEyUA=
Date: Tue, 17 Jan 2012 03:03:30 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
References: <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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
	<20120113222451.GA6922@phenom.dumpdata.com>
In-Reply-To: <20120113222451.GA6922@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "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@kernel.org" <konrad@kernel.org>, "Nakajima,
	Jun" <jun.nakajima@intel.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 Rzeszutek Wilk <konrad@darnok.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.wilk@oracle.com]
> Sent: Saturday, January 14, 2012 6:25 AM
> 
> > > > sure. VCPU!=PCPU requirement is orthogonal to the basic part for gearing
> > > > ACPI information to Xen.
> 
> .. snip..
> > > >
> > > > >  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).
> 
> .. snip..
> 
> > yes, this is a big question. First, I'd like to give my sincere thanks to you and
> > Liang for help push this part to Linux upstream. You've done a great job. :-)
> 
> Thanks!
> > Unfortunately I can't afford the time in the short term, due to extremely busy
> > tasks in other projects, at least in the whole Q1. Really sorry about that. :/
> 
> Bummer.
> >
> > I would very appreciate your help if you could continue lending some time
> here,
> > since you've done plenty of works on the cleanup. The majority of the tricky
> > part is related to VCPU/PCPU handling. If putting that part aside, the
> remaining
> > logic should be much simpler.
> 
> I was trying to figure out how difficult it would be to just bring Pxx states to
> the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
> all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
> be enabled in the hypercall to make this work), it demonstrates what I had in
> mind.
> 
> 
> #include <linux/device.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/types.h>
> #include <acpi/acpi_bus.h>
> #include <acpi/acpi_drivers.h>
> #include <acpi/processor.h>
> #include <linux/cpumask.h>
> 
> #include <xen/interface/platform.h>
> #include <asm/xen/hypercall.h>
> 
> #define DRV_NAME	"ACPI_PXX"
> #define DRV_CLASS	"ACPI_PXX_CLASS"
> MODULE_AUTHOR("Konrad Rzeszutek Wilk");
> MODULE_DESCRIPTION("ACPI Processor Driver to send data to Xen
> hypervisor");
> MODULE_LICENSE("GPL");
> 
> static int parse_acpi_cxx(struct acpi_processor *_pr)
> {
> 	struct acpi_processor_cx *cx;
> 	int i;
> 
> 	for (i = 1; i <= _pr->power.count; i++) {
> 		cx = &_pr->power.states[i];
> 		if (!cx->valid)
> 			continue;
> 		pr_info("%s: %d %d %d 0x%x\n", __func__,
> 			cx->type, cx->latency, cx->power, (u32)cx->address);
> 	}
> 	/* TODO: Under Xen, the C-states information is not present.
>  	 * Figure out why. */

it's possible related to this long thread:

http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html

IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
Final solution is to have a para-virtualized PDC call for that.

> 	return 0;
> }
> static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
> {
> 	int ret = -EINVAL;
> 	struct xen_platform_op op = {
> 		.cmd			= XENPF_set_processor_pminfo,
> 		.interface_version	= XENPF_INTERFACE_VERSION,
> 		.u.set_pminfo.id	= _pr->acpi_id,
> 		.u.set_pminfo.type	= XEN_PM_PX,
> 	};
> 	struct xen_processor_performance *xen_perf;
> 	struct xen_processor_px *xen_states, *xen_px = NULL;
> 	struct acpi_processor_px *px;
> 	unsigned i;
> 
> 	xen_perf = &op.u.set_pminfo.perf;
> 	xen_perf->flags = XEN_PX_PSS;
> 
> 	xen_perf->state_count = _pr->performance->state_count;
> 	xen_states = kzalloc(xen_perf->state_count *
> 			     sizeof(struct xen_processor_px), GFP_KERNEL);
> 	if (!xen_states)
> 		return -ENOMEM;
> 
> 	for (i = 0; i < _pr->performance->state_count; i++) {
> 		xen_px = &(xen_states[i]);
> 		px = &(_pr->performance->states[i]);
> 
> 		xen_px->core_frequency = px->core_frequency;
> 		xen_px->power = px->power;
> 		xen_px->transition_latency = px->transition_latency;
> 		xen_px->bus_master_latency = px->bus_master_latency;
> 		xen_px->control = px->control;
> 		xen_px->status = px->status;
> 	}
> 	set_xen_guest_handle(xen_perf->states, xen_states);
> 	ret = HYPERVISOR_dom0_op(&op);
> 	kfree(xen_states);
> 	return ret;
> }
> static int parse_acpi_pxx(struct acpi_processor *_pr)
> {
> 	struct acpi_processor_px *px;
> 	int i;
> 
> 	for (i = 0; i < _pr->performance->state_count;i++) {
> 		px = &(_pr->performance->states[i]);
> 		pr_info("%s: [%d]: %d, %d, %d, %d, %d, %d\n", __func__,
> 			i, (u32)px->core_frequency, (u32)px->power,
> 			(u32)px->transition_latency,
> 			(u32)px->bus_master_latency,
> 			(u32)px->control, (u32)px->status);
> 	}
> 	if (xen_initial_domain())
> 		return push_pxx_to_hypervisor(_pr);
> 	return 0;
> }
> static int parse_acpi_data(void)
> {
> 	int cpu;
> 	int err = -ENODEV;
> 	struct acpi_processor *_pr;
> 	struct cpuinfo_x86 *c = &cpu_data(0);
> 
> 	/* TODO: Under AMD, the information is populated
> 	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
> 	 * MSR which returns the wrong value so the population of 'processors'
> 	 * has bogus data. So only run this under Intel for right now. */
> 	if (!cpu_has(c, X86_FEATURE_EST))
> 		return -ENODEV;
> 	for_each_possible_cpu(cpu) {
> 		_pr = per_cpu(processors, cpu);
> 		if (!_pr)
> 			continue;
> 
> 		if (_pr->flags.power)
> 			(void)parse_acpi_cxx(_pr);
> 
> 		if (_pr->performance->states)
> 			err = parse_acpi_pxx(_pr);
> 		if (err)
> 			break;
> 	}
> 	return -ENODEV; /* force it to unload */
> }
> static int __init acpi_pxx_init(void)
> {
> 	return parse_acpi_data();
> }
> static void __exit acpi_pxx_exit(void)
> {
> }
> module_init(acpi_pxx_init);
> module_exit(acpi_pxx_exit);

the prerequisites for this module to work correctly, is that dom0 has the right
configurations to have all necessary Cx/Px information ready before this 
module is loaded. That may mean enabling full CONFIG_CPU_IDLE and CONFIG_CPUFREQ,
which in current form may add some negative impact, e.g. dom0 will try to control
Px/Cx to conflict with Xen. So some tweaks may be required in that part.

given our purpose now, is to come up a cleaner approach which tolerate some
assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
mainly two roles:
	- a dummy driver to prevent dom0 touching actual Px/Cx
	- parse ACPI Cx/Px information to Xen, in a similar way you did above

there may have some other trickiness, but the majority code will be self-contained.

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 Jan 17 03:06:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 03: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 1RmzMY-0005Z7-4J; Tue, 17 Jan 2012 03:05: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 1RmzMW-0005Yo-Ub
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 03:05:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326769521!9419529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTQxNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27001 invoked from network); 17 Jan 2012 03:05:21 -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;
	17 Jan 2012 03:05:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,521,1320624000"; d="scan'208";a="10073561"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 03:05:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 03:05: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 1RmzMO-000085-Qb;
	Tue, 17 Jan 2012 03:05:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RmzMO-0000jH-Pi;
	Tue, 17 Jan 2012 03:05:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10776-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 03:05:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10776: 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 10776 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10776/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xl-multivcpu 11 guest-localmigrate        fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl           11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install               fail   like 10645

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  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

version targeted for testing:
 xen                  2913ccc6d70f
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                           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                                 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 815 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 Jan 17 03:06:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 03: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 1RmzMN-0005Yd-NK; Tue, 17 Jan 2012 03:05:19 +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 1RmzML-0005YY-9w
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 03:05:17 +0000
X-Env-Sender: kevin.tian@intel.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326769509!1558263!1
X-Originating-IP: [134.134.136.20]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTM0LjEzNC4xMzYuMjAgPT4gMjk3MjQx\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22169 invoked from network); 17 Jan 2012 03:05:10 -0000
Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20)
	by server-5.tower-21.messagelabs.com with SMTP;
	17 Jan 2012 03:05:10 -0000
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga101.jf.intel.com with ESMTP; 16 Jan 2012 19:05:08 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="97219398"
Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69])
	by orsmga001.jf.intel.com with ESMTP; 16 Jan 2012 19:05:02 -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; Tue, 17 Jan 2012 11:03:33 +0800
Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by
	PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 17 Jan 2012 11:03:33 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by
	SHSMSX151.ccr.corp.intel.com ([169.254.3.223]) with mapi id
	14.01.0355.002; Tue, 17 Jan 2012 11:03:31 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, liang tang
	<liang.tang@oracle.com>
Thread-Topic: [Xen-devel] [PATCH 3/8] ACPI: processor: add
	__acpi_processor_[un]register_driver helpers.
Thread-Index: AQHMwR8jSQj+OztfxUuz+mAW9L1uCZXtWRMwgA1TuICAA+19QIAL4bKAgAWEyUA=
Date: Tue, 17 Jan 2012 03:03:30 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
References: <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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
	<20120113222451.GA6922@phenom.dumpdata.com>
In-Reply-To: <20120113222451.GA6922@phenom.dumpdata.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.239.127.40]
MIME-Version: 1.0
Cc: "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@kernel.org" <konrad@kernel.org>, "Nakajima,
	Jun" <jun.nakajima@intel.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 Rzeszutek Wilk <konrad@darnok.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.wilk@oracle.com]
> Sent: Saturday, January 14, 2012 6:25 AM
> 
> > > > sure. VCPU!=PCPU requirement is orthogonal to the basic part for gearing
> > > > ACPI information to Xen.
> 
> .. snip..
> > > >
> > > > >  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).
> 
> .. snip..
> 
> > yes, this is a big question. First, I'd like to give my sincere thanks to you and
> > Liang for help push this part to Linux upstream. You've done a great job. :-)
> 
> Thanks!
> > Unfortunately I can't afford the time in the short term, due to extremely busy
> > tasks in other projects, at least in the whole Q1. Really sorry about that. :/
> 
> Bummer.
> >
> > I would very appreciate your help if you could continue lending some time
> here,
> > since you've done plenty of works on the cleanup. The majority of the tricky
> > part is related to VCPU/PCPU handling. If putting that part aside, the
> remaining
> > logic should be much simpler.
> 
> I was trying to figure out how difficult it would be to just bring Pxx states to
> the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
> all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
> be enabled in the hypercall to make this work), it demonstrates what I had in
> mind.
> 
> 
> #include <linux/device.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/types.h>
> #include <acpi/acpi_bus.h>
> #include <acpi/acpi_drivers.h>
> #include <acpi/processor.h>
> #include <linux/cpumask.h>
> 
> #include <xen/interface/platform.h>
> #include <asm/xen/hypercall.h>
> 
> #define DRV_NAME	"ACPI_PXX"
> #define DRV_CLASS	"ACPI_PXX_CLASS"
> MODULE_AUTHOR("Konrad Rzeszutek Wilk");
> MODULE_DESCRIPTION("ACPI Processor Driver to send data to Xen
> hypervisor");
> MODULE_LICENSE("GPL");
> 
> static int parse_acpi_cxx(struct acpi_processor *_pr)
> {
> 	struct acpi_processor_cx *cx;
> 	int i;
> 
> 	for (i = 1; i <= _pr->power.count; i++) {
> 		cx = &_pr->power.states[i];
> 		if (!cx->valid)
> 			continue;
> 		pr_info("%s: %d %d %d 0x%x\n", __func__,
> 			cx->type, cx->latency, cx->power, (u32)cx->address);
> 	}
> 	/* TODO: Under Xen, the C-states information is not present.
>  	 * Figure out why. */

it's possible related to this long thread:

http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html

IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
Final solution is to have a para-virtualized PDC call for that.

> 	return 0;
> }
> static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
> {
> 	int ret = -EINVAL;
> 	struct xen_platform_op op = {
> 		.cmd			= XENPF_set_processor_pminfo,
> 		.interface_version	= XENPF_INTERFACE_VERSION,
> 		.u.set_pminfo.id	= _pr->acpi_id,
> 		.u.set_pminfo.type	= XEN_PM_PX,
> 	};
> 	struct xen_processor_performance *xen_perf;
> 	struct xen_processor_px *xen_states, *xen_px = NULL;
> 	struct acpi_processor_px *px;
> 	unsigned i;
> 
> 	xen_perf = &op.u.set_pminfo.perf;
> 	xen_perf->flags = XEN_PX_PSS;
> 
> 	xen_perf->state_count = _pr->performance->state_count;
> 	xen_states = kzalloc(xen_perf->state_count *
> 			     sizeof(struct xen_processor_px), GFP_KERNEL);
> 	if (!xen_states)
> 		return -ENOMEM;
> 
> 	for (i = 0; i < _pr->performance->state_count; i++) {
> 		xen_px = &(xen_states[i]);
> 		px = &(_pr->performance->states[i]);
> 
> 		xen_px->core_frequency = px->core_frequency;
> 		xen_px->power = px->power;
> 		xen_px->transition_latency = px->transition_latency;
> 		xen_px->bus_master_latency = px->bus_master_latency;
> 		xen_px->control = px->control;
> 		xen_px->status = px->status;
> 	}
> 	set_xen_guest_handle(xen_perf->states, xen_states);
> 	ret = HYPERVISOR_dom0_op(&op);
> 	kfree(xen_states);
> 	return ret;
> }
> static int parse_acpi_pxx(struct acpi_processor *_pr)
> {
> 	struct acpi_processor_px *px;
> 	int i;
> 
> 	for (i = 0; i < _pr->performance->state_count;i++) {
> 		px = &(_pr->performance->states[i]);
> 		pr_info("%s: [%d]: %d, %d, %d, %d, %d, %d\n", __func__,
> 			i, (u32)px->core_frequency, (u32)px->power,
> 			(u32)px->transition_latency,
> 			(u32)px->bus_master_latency,
> 			(u32)px->control, (u32)px->status);
> 	}
> 	if (xen_initial_domain())
> 		return push_pxx_to_hypervisor(_pr);
> 	return 0;
> }
> static int parse_acpi_data(void)
> {
> 	int cpu;
> 	int err = -ENODEV;
> 	struct acpi_processor *_pr;
> 	struct cpuinfo_x86 *c = &cpu_data(0);
> 
> 	/* TODO: Under AMD, the information is populated
> 	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
> 	 * MSR which returns the wrong value so the population of 'processors'
> 	 * has bogus data. So only run this under Intel for right now. */
> 	if (!cpu_has(c, X86_FEATURE_EST))
> 		return -ENODEV;
> 	for_each_possible_cpu(cpu) {
> 		_pr = per_cpu(processors, cpu);
> 		if (!_pr)
> 			continue;
> 
> 		if (_pr->flags.power)
> 			(void)parse_acpi_cxx(_pr);
> 
> 		if (_pr->performance->states)
> 			err = parse_acpi_pxx(_pr);
> 		if (err)
> 			break;
> 	}
> 	return -ENODEV; /* force it to unload */
> }
> static int __init acpi_pxx_init(void)
> {
> 	return parse_acpi_data();
> }
> static void __exit acpi_pxx_exit(void)
> {
> }
> module_init(acpi_pxx_init);
> module_exit(acpi_pxx_exit);

the prerequisites for this module to work correctly, is that dom0 has the right
configurations to have all necessary Cx/Px information ready before this 
module is loaded. That may mean enabling full CONFIG_CPU_IDLE and CONFIG_CPUFREQ,
which in current form may add some negative impact, e.g. dom0 will try to control
Px/Cx to conflict with Xen. So some tweaks may be required in that part.

given our purpose now, is to come up a cleaner approach which tolerate some
assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
mainly two roles:
	- a dummy driver to prevent dom0 touching actual Px/Cx
	- parse ACPI Cx/Px information to Xen, in a similar way you did above

there may have some other trickiness, but the majority code will be self-contained.

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 Jan 17 07:32:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 07:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn3WJ-0007o0-AV; Tue, 17 Jan 2012 07:31:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rn3WG-0007ns-Vp
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 07:31:49 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326785502!2493323!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25344 invoked from network); 17 Jan 2012 07:31:42 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 07:31:42 -0000
Received: by eekc1 with SMTP id c1so9440321eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 23:31:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=lTfL5+6CGP/rFFc/eyXcXSlZvCDtllhCRUEzoSwIiRU=;
	b=WnG6Q5hTl1Wa1uu+O/cYHghhiD0qMFrtmZ0NzsPEInMD+V/OyxeKcAVnE27bsMNXwR
	M0VNoVDutLvo7n1ybhsRZcYPpE6FQXsSY1tGYcsuyjy/CFuZIb4MU2iZnzPT1JV5LErN
	yOpu/szH761RcueL4IbZNTY41GqelQpRYOTeQ=
Received: by 10.213.13.217 with SMTP id d25mr3034128eba.36.1326785502170;
	Mon, 16 Jan 2012 23:31:42 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-200-238.ip51.fastwebnet.it.
	[93.34.200.238])
	by mx.google.com with ESMTPS id u53sm82641776eeu.6.2012.01.16.23.31.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 16 Jan 2012 23:31:41 -0800 (PST)
Message-ID: <4F1523DC.4060209@redhat.com>
Date: Tue, 17 Jan 2012 08:31:40 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Gerd Hoffmann <kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v2 0/6] initial suspend support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 07:15 PM, Gerd Hoffmann wrote:
> This patch series makes suspend support in qemu alot more useful.  Right
> now the guest can put itself into s3, but qemu will wakeup the guest
> instantly.  With this patch series applied the guest will stay suspended
> instead and there are a few events which can kick the guest out of
> suspend state:  A monitor command, ps/2 input, serial input, rtc.  Not
> much yet, but it's a start with the low hanging fruits ;)
>
> Changes in v2:
>   * Add a suspend notifier.
>   * Replace the cmos_s3 qemu_irq with the notifier, zap a bunch of hackish
>     cmos_s3 windup code (this touches xen-all.c, thus cc xen-devel).
>   * Add rtc wakeup support.
>
> Gerd Hoffmann (6):
>    suspend: add infrastructure
>    suspend: switch acpi s3 to new infrastructure.
>    suspend: add wakeup monitor command
>    suspend: make ps/2 devices wakeup the guest
>    suspend: make serial ports wakeup the guest.
>    suspend: make rtc alarm wakeup the guest.
>
>   hmp-commands.hx  |   14 ++++++++++++++
>   hmp.c            |    5 +++++
>   hmp.h            |    1 +
>   hw/acpi.c        |   11 +----------
>   hw/acpi.h        |    2 --
>   hw/acpi_piix4.c  |    3 +--
>   hw/mc146818rtc.c |   17 +++++++++++++++++
>   hw/mips_malta.c  |    2 +-
>   hw/pc.c          |   11 -----------
>   hw/pc.h          |    3 +--
>   hw/pc_piix.c     |    8 +-------
>   hw/ps2.c         |    6 ++++++
>   hw/serial.c      |    6 ++++++
>   hw/vt82c686.c    |    1 -
>   qapi-schema.json |   11 +++++++++++
>   qmp-commands.hx  |   21 +++++++++++++++++++++
>   qmp.c            |    5 +++++
>   sysemu.h         |    3 +++
>   vl.c             |   28 ++++++++++++++++++++++++++++
>   xen-all.c        |   11 ++++++-----
>   20 files changed, 128 insertions(+), 41 deletions(-)

Nice. :)

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 07:32:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 07:32:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn3WJ-0007o0-AV; Tue, 17 Jan 2012 07:31:51 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rn3WG-0007ns-Vp
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 07:31:49 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326785502!2493323!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25344 invoked from network); 17 Jan 2012 07:31:42 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 07:31:42 -0000
Received: by eekc1 with SMTP id c1so9440321eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 23:31:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=lTfL5+6CGP/rFFc/eyXcXSlZvCDtllhCRUEzoSwIiRU=;
	b=WnG6Q5hTl1Wa1uu+O/cYHghhiD0qMFrtmZ0NzsPEInMD+V/OyxeKcAVnE27bsMNXwR
	M0VNoVDutLvo7n1ybhsRZcYPpE6FQXsSY1tGYcsuyjy/CFuZIb4MU2iZnzPT1JV5LErN
	yOpu/szH761RcueL4IbZNTY41GqelQpRYOTeQ=
Received: by 10.213.13.217 with SMTP id d25mr3034128eba.36.1326785502170;
	Mon, 16 Jan 2012 23:31:42 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-200-238.ip51.fastwebnet.it.
	[93.34.200.238])
	by mx.google.com with ESMTPS id u53sm82641776eeu.6.2012.01.16.23.31.40
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 16 Jan 2012 23:31:41 -0800 (PST)
Message-ID: <4F1523DC.4060209@redhat.com>
Date: Tue, 17 Jan 2012 08:31:40 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Gerd Hoffmann <kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v2 0/6] initial suspend support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 07:15 PM, Gerd Hoffmann wrote:
> This patch series makes suspend support in qemu alot more useful.  Right
> now the guest can put itself into s3, but qemu will wakeup the guest
> instantly.  With this patch series applied the guest will stay suspended
> instead and there are a few events which can kick the guest out of
> suspend state:  A monitor command, ps/2 input, serial input, rtc.  Not
> much yet, but it's a start with the low hanging fruits ;)
>
> Changes in v2:
>   * Add a suspend notifier.
>   * Replace the cmos_s3 qemu_irq with the notifier, zap a bunch of hackish
>     cmos_s3 windup code (this touches xen-all.c, thus cc xen-devel).
>   * Add rtc wakeup support.
>
> Gerd Hoffmann (6):
>    suspend: add infrastructure
>    suspend: switch acpi s3 to new infrastructure.
>    suspend: add wakeup monitor command
>    suspend: make ps/2 devices wakeup the guest
>    suspend: make serial ports wakeup the guest.
>    suspend: make rtc alarm wakeup the guest.
>
>   hmp-commands.hx  |   14 ++++++++++++++
>   hmp.c            |    5 +++++
>   hmp.h            |    1 +
>   hw/acpi.c        |   11 +----------
>   hw/acpi.h        |    2 --
>   hw/acpi_piix4.c  |    3 +--
>   hw/mc146818rtc.c |   17 +++++++++++++++++
>   hw/mips_malta.c  |    2 +-
>   hw/pc.c          |   11 -----------
>   hw/pc.h          |    3 +--
>   hw/pc_piix.c     |    8 +-------
>   hw/ps2.c         |    6 ++++++
>   hw/serial.c      |    6 ++++++
>   hw/vt82c686.c    |    1 -
>   qapi-schema.json |   11 +++++++++++
>   qmp-commands.hx  |   21 +++++++++++++++++++++
>   qmp.c            |    5 +++++
>   sysemu.h         |    3 +++
>   vl.c             |   28 ++++++++++++++++++++++++++++
>   xen-all.c        |   11 ++++++-----
>   20 files changed, 128 insertions(+), 41 deletions(-)

Nice. :)

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 08:09:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 08: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 1Rn45V-0000UN-Ab; Tue, 17 Jan 2012 08:08:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <studyxen@gmail.com>) id 1Rn45T-0000UF-GW
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 08:08:11 +0000
X-Env-Sender: studyxen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326787684!7465465!1
X-Originating-IP: [209.85.214.65]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17958 invoked from network); 17 Jan 2012 08:08:05 -0000
Received: from mail-bk0-f65.google.com (HELO mail-bk0-f65.google.com)
	(209.85.214.65)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 08:08:05 -0000
Received: by bke17 with SMTP id 17so113403bke.0
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 00:08:04 -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=TKWVvMjylpXWtv/O7m0iNOGtq3sdx0ZuZDRymzs/zD8=;
	b=GlOTqcj4rY6iogltPsLMqtvq8F+Vy75mXUilGzDqamZa0ee3xsIS/vjw5yObN8cMNM
	LqnDRngFOF4IcxN+eLeHR94T3lDepj83l/NkiFBBCYDoOi+kMiTM/8RcMC7OMmZAXJB5
	5qVeazbuHR0JuwytyLj/NIGTuVDVE3IvI3B2k=
MIME-Version: 1.0
Received: by 10.205.139.76 with SMTP id iv12mr6398031bkc.100.1326787684492;
	Tue, 17 Jan 2012 00:08:04 -0800 (PST)
Received: by 10.205.42.67 with HTTP; Tue, 17 Jan 2012 00:08:04 -0800 (PST)
Date: Tue, 17 Jan 2012 03:08:04 -0500
Message-ID: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
From: Study Xen <studyxen@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] unable to capture an expected page fault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3268980539522535240=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3268980539522535240==
Content-Type: multipart/alternative; boundary=0015173fe6b2a0668304b6b4d435

--0015173fe6b2a0668304b6b4d435
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I was trying to modify part of Xen and faced a page fault missing issue.

I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only
domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux
kernel's "native_set_pte" in "arch/x86/include/asm/pgtable_64.h" traps into
Xen due to Xen's write-protection of the pagetable page. But in our
modified version, this expected page fault seems missing.

I tried to debug and had the following observations.

(1) I have verified that the (L1) pte pointing to the page containing the
faulting vaddr has its R/W=0 so it is indeed write-protected.

(2) In Xen, I have verified that the page_fault interrupt is trapped (the
"set_intr_gate" logic for page fault in xen/arch/x86/traps.c remains
unchanged compared with original Xen).

(3) And I called printk directly from within "ENTRY(page_fault)"
(xen/arch/x86/x86_64/entry.S) in the hope that if the expected faulting
vaddr is detected (my understanding is that ENTRY(page_fault) is the first
code that gets executed in Xen when there is a page fault interrupt, am I
right?), then the printk message will immediately appear. I can see this
debug message if I insert the printk to unmodified Xen's entry.S, but it
does not generate any output in the modified project.

(4) I also checked the value of CR0 just in case the WP bit is mistakenly
cleared. And I found that it was correctly set. (is this really related? I
assume PV is running with CPL==1 so I would like to check this. )

So I was baffled with the situation that modifying a write-protected page
does not generate a page fault that can be intercepted by (modified) Xen.

Could someone suggest some thoughts on my above debugging procedure?

Thanks.

X

--0015173fe6b2a0668304b6b4d435
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I was trying to modify part of Xen and faced a pa=
ge fault missing issue.=A0</div><div><br></div><div>I am testing a PV Linux=
 64-bit guest (kernel 3.1.1, as dom0, the only domain in my setting) atop X=
en 4.1.2. In an unmodified Xen, the Linux kernel&#39;s &quot;native_set_pte=
&quot; in &quot;arch/x86/include/asm/pgtable_64.h&quot; traps into Xen due =
to Xen&#39;s write-protection of the pagetable page. But in our modified ve=
rsion, this expected page fault seems missing.=A0</div>
<div><br></div><div>I tried to debug and had the following observations.</d=
iv><div><br></div><div>(1) I have verified that the (L1) pte pointing to th=
e page containing the faulting vaddr has its R/W=3D0 so it is indeed write-=
protected.=A0</div>
<div><br></div><div>(2) In Xen, I have verified that the page_fault interru=
pt is trapped (the &quot;set_intr_gate&quot; logic for page fault in xen/ar=
ch/x86/traps.c remains unchanged compared with original Xen).=A0</div><div>
<br></div><div>(3) And I called printk directly from within &quot;ENTRY(pag=
e_fault)&quot; (xen/arch/x86/x86_64/entry.S) in the hope that if the expect=
ed faulting vaddr is detected (my understanding is that ENTRY(page_fault) i=
s the first code that gets executed in Xen when there is a page fault inter=
rupt, am I right?), then the printk message will immediately appear. I can =
see this debug message if I insert the printk to unmodified Xen&#39;s entry=
.S, but it does not generate any output in the modified project.=A0</div>
<div><br></div><div>(4) I also checked the value of CR0 just in case the WP=
 bit is mistakenly cleared. And I found that it was correctly set. (is this=
 really related? I assume PV is running with CPL=3D=3D1 so I would like to =
check this. )</div>
<div><br></div><div>So I was baffled with the situation that modifying a wr=
ite-protected page does not generate a page fault that can be intercepted b=
y (modified) Xen.=A0</div><div><br></div><div>Could someone suggest some th=
oughts on my above debugging procedure?=A0</div>
<div><br></div><div>Thanks.</div><div><br></div><div>X</div>

--0015173fe6b2a0668304b6b4d435--


--===============3268980539522535240==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3268980539522535240==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 08:09:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 08: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 1Rn45V-0000UN-Ab; Tue, 17 Jan 2012 08:08:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <studyxen@gmail.com>) id 1Rn45T-0000UF-GW
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 08:08:11 +0000
X-Env-Sender: studyxen@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326787684!7465465!1
X-Originating-IP: [209.85.214.65]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17958 invoked from network); 17 Jan 2012 08:08:05 -0000
Received: from mail-bk0-f65.google.com (HELO mail-bk0-f65.google.com)
	(209.85.214.65)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 08:08:05 -0000
Received: by bke17 with SMTP id 17so113403bke.0
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 00:08:04 -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=TKWVvMjylpXWtv/O7m0iNOGtq3sdx0ZuZDRymzs/zD8=;
	b=GlOTqcj4rY6iogltPsLMqtvq8F+Vy75mXUilGzDqamZa0ee3xsIS/vjw5yObN8cMNM
	LqnDRngFOF4IcxN+eLeHR94T3lDepj83l/NkiFBBCYDoOi+kMiTM/8RcMC7OMmZAXJB5
	5qVeazbuHR0JuwytyLj/NIGTuVDVE3IvI3B2k=
MIME-Version: 1.0
Received: by 10.205.139.76 with SMTP id iv12mr6398031bkc.100.1326787684492;
	Tue, 17 Jan 2012 00:08:04 -0800 (PST)
Received: by 10.205.42.67 with HTTP; Tue, 17 Jan 2012 00:08:04 -0800 (PST)
Date: Tue, 17 Jan 2012 03:08:04 -0500
Message-ID: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
From: Study Xen <studyxen@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] unable to capture an expected page fault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3268980539522535240=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3268980539522535240==
Content-Type: multipart/alternative; boundary=0015173fe6b2a0668304b6b4d435

--0015173fe6b2a0668304b6b4d435
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I was trying to modify part of Xen and faced a page fault missing issue.

I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only
domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux
kernel's "native_set_pte" in "arch/x86/include/asm/pgtable_64.h" traps into
Xen due to Xen's write-protection of the pagetable page. But in our
modified version, this expected page fault seems missing.

I tried to debug and had the following observations.

(1) I have verified that the (L1) pte pointing to the page containing the
faulting vaddr has its R/W=0 so it is indeed write-protected.

(2) In Xen, I have verified that the page_fault interrupt is trapped (the
"set_intr_gate" logic for page fault in xen/arch/x86/traps.c remains
unchanged compared with original Xen).

(3) And I called printk directly from within "ENTRY(page_fault)"
(xen/arch/x86/x86_64/entry.S) in the hope that if the expected faulting
vaddr is detected (my understanding is that ENTRY(page_fault) is the first
code that gets executed in Xen when there is a page fault interrupt, am I
right?), then the printk message will immediately appear. I can see this
debug message if I insert the printk to unmodified Xen's entry.S, but it
does not generate any output in the modified project.

(4) I also checked the value of CR0 just in case the WP bit is mistakenly
cleared. And I found that it was correctly set. (is this really related? I
assume PV is running with CPL==1 so I would like to check this. )

So I was baffled with the situation that modifying a write-protected page
does not generate a page fault that can be intercepted by (modified) Xen.

Could someone suggest some thoughts on my above debugging procedure?

Thanks.

X

--0015173fe6b2a0668304b6b4d435
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I was trying to modify part of Xen and faced a pa=
ge fault missing issue.=A0</div><div><br></div><div>I am testing a PV Linux=
 64-bit guest (kernel 3.1.1, as dom0, the only domain in my setting) atop X=
en 4.1.2. In an unmodified Xen, the Linux kernel&#39;s &quot;native_set_pte=
&quot; in &quot;arch/x86/include/asm/pgtable_64.h&quot; traps into Xen due =
to Xen&#39;s write-protection of the pagetable page. But in our modified ve=
rsion, this expected page fault seems missing.=A0</div>
<div><br></div><div>I tried to debug and had the following observations.</d=
iv><div><br></div><div>(1) I have verified that the (L1) pte pointing to th=
e page containing the faulting vaddr has its R/W=3D0 so it is indeed write-=
protected.=A0</div>
<div><br></div><div>(2) In Xen, I have verified that the page_fault interru=
pt is trapped (the &quot;set_intr_gate&quot; logic for page fault in xen/ar=
ch/x86/traps.c remains unchanged compared with original Xen).=A0</div><div>
<br></div><div>(3) And I called printk directly from within &quot;ENTRY(pag=
e_fault)&quot; (xen/arch/x86/x86_64/entry.S) in the hope that if the expect=
ed faulting vaddr is detected (my understanding is that ENTRY(page_fault) i=
s the first code that gets executed in Xen when there is a page fault inter=
rupt, am I right?), then the printk message will immediately appear. I can =
see this debug message if I insert the printk to unmodified Xen&#39;s entry=
.S, but it does not generate any output in the modified project.=A0</div>
<div><br></div><div>(4) I also checked the value of CR0 just in case the WP=
 bit is mistakenly cleared. And I found that it was correctly set. (is this=
 really related? I assume PV is running with CPL=3D=3D1 so I would like to =
check this. )</div>
<div><br></div><div>So I was baffled with the situation that modifying a wr=
ite-protected page does not generate a page fault that can be intercepted b=
y (modified) Xen.=A0</div><div><br></div><div>Could someone suggest some th=
oughts on my above debugging procedure?=A0</div>
<div><br></div><div>Thanks.</div><div><br></div><div>X</div>

--0015173fe6b2a0668304b6b4d435--


--===============3268980539522535240==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3268980539522535240==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 08:27:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 08: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 1Rn4NF-0000kE-L5; Tue, 17 Jan 2012 08:26:33 +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 1Rn4NC-0000k9-Os
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 08:26:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326788783!9384436!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 32634 invoked from network); 17 Jan 2012 08:26:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 08:26:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Jan 2012 08:26:22 +0000
Message-Id: <4F153EBA020000780006D248@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Jan 2012 08:26:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <boris.ostrovsky@amd.com>
References: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
In-Reply-To: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.01.12 at 22:11, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> --- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_SSE4A) |
>                      bitmaskof(X86_FEATURE_MISALIGNSSE) |
>                      bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
> +		    bitmaskof(X86_FEATURE_OSVW) |

Indentation.

Also, is this really meaningful to PV guests? And valid for pre-Fam10?

>                      bitmaskof(X86_FEATURE_XOP) |
>                      bitmaskof(X86_FEATURE_FMA4) |
>                      bitmaskof(X86_FEATURE_TBM) |
> --- a/xen/arch/x86/cpu/amd.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/xen/arch/x86/cpu/amd.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -32,6 +32,13 @@
>  static char opt_famrev[14];
>  string_param("cpuid_mask_cpu", opt_famrev);
>  
> +/*
> + * Set osvw_len to higher number when updated Revision Guides
> + * are published and we know what the new status bits are
> + */

This is ugly, as it requires permanent attention. The value to start
with should really be 64 (beyond which other code adjustments are
going to be necessary anyway).

> +static uint64_t osvw_length = 4, osvw_status;
> +static DEFINE_SPINLOCK(amd_lock);
> +
>  static inline void wrmsr_amd(unsigned int index, unsigned int lo, 
>  		unsigned int hi)
>  {
> @@ -182,6 +189,35 @@ static void __devinit set_cpuidmask(cons
>  	}
>  }
>  
> +static void amd_guest_osvw_init(struct vcpu *vcpu)
> +{
> +    if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
> +	return;

Shouldn't we bail here for pre-Fam10 CPUs too?

Further, as asked above already - is all this really meaningful to PV
guests? Otherwise the code would better go somewhere under
xen/arch/x86/hvm/svm/ ...

Also, throughout this file indentation needs to be changed to Linux
style (tabs instead of spaces), unless you want to contribute a patch
to convert the whole file to Xen style (in which case you'd still need
to make adjustments here).

> +
> +    /*
> +     * Guests should see errata 400 and 415 as fixed (assuming that
> +     * HLT and IO instructions are intercepted).
> +     */
> +    vcpu->arch.amd.osvw.length = (osvw_length >= 3) ? (osvw_length) : 3;

An expression consisting of just an identifier for sure doesn't need
parentheses.

> +    vcpu->arch.amd.osvw.status = osvw_status & ~(6ULL);
> +
> +    /*
> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
> +     * all osvw.status bits inside that length, including bit 0 (which is
> +     * reserved for erratum 298), are valid. However, if host processor's
> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
> +     * be conservative here and therefore we tell the guest that erratum 298
> +     * is present (because we really don't know).
> +     */
> +    if (osvw_length == 0 && boot_cpu_data.x86 == 0x10)

Why do you check the family here? If osvw_length can only ever be
zero on Fam10, then the first check is sufficient. If osvw_length can
be zero on other than Fam10 (no matter whether we bail early older
CPUs), then the check is actually wrong.

> +	vcpu->arch.amd.osvw.status |= 1;
> +}
> +
> +void amd_vcpu_initialise(struct vcpu *vcpu)
> +{
> +    amd_guest_osvw_init(vcpu);
> +}
> +
>  /*
>   * Check for the presence of an AMD erratum. Arguments are defined in amd.h 
> 
>   * for each known erratum. Return 1 if erratum is found.
> @@ -512,6 +548,30 @@ static void __devinit init_amd(struct cp
>  	set_cpuidmask(c);
>  
>  	check_syscfg_dram_mod_en();
> +
> +    /* 
> +     * Get OSVW bits. If bits are not the same on different processors then
> +     * choose the worst case (i.e. if erratum is present on one processor and
> +     * not on another assume that the erratum is present everywhere).
> +     */
> +     if (test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability)) {
> +         uint64_t len, status;
> +
> +        if (rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
> +            rdmsr_safe(MSR_AMD_OSVW_STATUS, status))
> +            len = status = 0;
> +
> +        spin_lock(&amd_lock);

What is the locking here supposed to protect against? The AP call tree
is smp_callin() -> identify_cpu() -> init_amd(), which cannot race with
anything (as the initiating processor is waiting for cpu_state to change
to CPU_STATE_CALLIN).

> +        
> +        if (len < osvw_length)
> +            osvw_length = len;
> +
> +        osvw_status |= status;
> +        osvw_status &= (1ULL << osvw_length) - 1;
> +
> +        spin_unlock(&amd_lock);
> +    } else
> +	 osvw_length = osvw_status = 0;
>  }
>  
>  static struct cpu_dev amd_cpu_dev __cpuinitdata = {
> --- a/xen/arch/x86/domain.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/xen/arch/x86/domain.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -422,6 +422,10 @@ int vcpu_initialise(struct vcpu *v)
>      if ( (rc = vcpu_init_fpu(v)) != 0 )
>          return rc;
>  
> +    /* Vendor-specific initialization */
> +    if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)

If you check the vendor here, you don't need to anywhere in the
descendant functions.

> +        amd_vcpu_initialise(v);
> +
>      if ( is_hvm_domain(d) )
>      {
>          rc = hvm_vcpu_initialise(v);
> --- a/xen/arch/x86/hvm/svm/svm.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -1044,6 +1044,27 @@ static void svm_init_erratum_383(struct 
>      }
>  }
>  
> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, uint read)
> +{
> +    uint eax, ebx, ecx, edx;
> +     
> +    /* Guest OSVW support */
> +    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
> +    if (!test_bit((X86_FEATURE_OSVW & 31), &ecx))

Formatting of changes to this file should be changed to Xen style.

> +        return -1;
> +
> +    if (read) {
> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
> +            *val = v->arch.amd.osvw.length;
> +        else
> +            *val = v->arch.amd.osvw.status;
> +    } 
> +    /* Writes are ignored */
> +
> +    return 0;
> +}
> +
> +
>  static int svm_cpu_up(void)
>  {
>      uint64_t msr_content;
> --- a/xen/arch/x86/traps.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/xen/arch/x86/traps.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -2542,6 +2542,15 @@ static int emulate_privileged_op(struct 
>              if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
>                  goto fail;
>              break;
> +        case MSR_AMD_OSVW_ID_LENGTH:
> +        case MSR_AMD_OSVW_STATUS:
> +            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) {
> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
> +                    goto fail;
> +                else

Bogus "else" after a "goto". And I wonder, provided there is some
point in doing all this for PV guests in the first place, whether this
shouldn't be kept getting handled by the default case.

> +                    break; /* Writes are ignored */
> +            }
> +            /* Fall through to default case */
>          default:
>              if ( wrmsr_hypervisor_regs(regs->ecx, msr_content) )
>                  break;
> @@ -2573,6 +2582,7 @@ static int emulate_privileged_op(struct 
>          break;
>  
>      case 0x32: /* RDMSR */
> +

Stray addition of a newline.

>          switch ( (u32)regs->ecx )
>          {
>  #ifdef CONFIG_X86_64
> @@ -2632,6 +2642,23 @@ static int emulate_privileged_op(struct 
>              regs->eax = (uint32_t)msr_content;
>              regs->edx = (uint32_t)(msr_content >> 32);
>              break;
> +        case MSR_AMD_OSVW_ID_LENGTH:
> +        case MSR_AMD_OSVW_STATUS:
> +            if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
> +                    goto fail;
> +                else {

Bogus "else" after a "goto".

Jan

> +                    if ((u32)regs->ecx == MSR_AMD_OSVW_ID_LENGTH)
> +                        msr_content = v->arch.amd.osvw.length;
> +                    else
> +                        msr_content = v->arch.amd.osvw.status;
> +
> +                    regs->eax = (uint32_t)msr_content;
> +                    regs->edx = (uint32_t)(msr_content >> 32);
> +                }
> +            } else
> +                goto rdmsr_normal;
> +            break;
>          default:
>              if ( rdmsr_hypervisor_regs(regs->ecx, &val) )
>              {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 08:27:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 08: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 1Rn4NF-0000kE-L5; Tue, 17 Jan 2012 08:26:33 +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 1Rn4NC-0000k9-Os
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 08:26:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326788783!9384436!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 32634 invoked from network); 17 Jan 2012 08:26:24 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 08:26:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Jan 2012 08:26:22 +0000
Message-Id: <4F153EBA020000780006D248@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Jan 2012 08:26:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <boris.ostrovsky@amd.com>
References: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
In-Reply-To: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.01.12 at 22:11, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> --- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>                      bitmaskof(X86_FEATURE_SSE4A) |
>                      bitmaskof(X86_FEATURE_MISALIGNSSE) |
>                      bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
> +		    bitmaskof(X86_FEATURE_OSVW) |

Indentation.

Also, is this really meaningful to PV guests? And valid for pre-Fam10?

>                      bitmaskof(X86_FEATURE_XOP) |
>                      bitmaskof(X86_FEATURE_FMA4) |
>                      bitmaskof(X86_FEATURE_TBM) |
> --- a/xen/arch/x86/cpu/amd.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/xen/arch/x86/cpu/amd.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -32,6 +32,13 @@
>  static char opt_famrev[14];
>  string_param("cpuid_mask_cpu", opt_famrev);
>  
> +/*
> + * Set osvw_len to higher number when updated Revision Guides
> + * are published and we know what the new status bits are
> + */

This is ugly, as it requires permanent attention. The value to start
with should really be 64 (beyond which other code adjustments are
going to be necessary anyway).

> +static uint64_t osvw_length = 4, osvw_status;
> +static DEFINE_SPINLOCK(amd_lock);
> +
>  static inline void wrmsr_amd(unsigned int index, unsigned int lo, 
>  		unsigned int hi)
>  {
> @@ -182,6 +189,35 @@ static void __devinit set_cpuidmask(cons
>  	}
>  }
>  
> +static void amd_guest_osvw_init(struct vcpu *vcpu)
> +{
> +    if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
> +	return;

Shouldn't we bail here for pre-Fam10 CPUs too?

Further, as asked above already - is all this really meaningful to PV
guests? Otherwise the code would better go somewhere under
xen/arch/x86/hvm/svm/ ...

Also, throughout this file indentation needs to be changed to Linux
style (tabs instead of spaces), unless you want to contribute a patch
to convert the whole file to Xen style (in which case you'd still need
to make adjustments here).

> +
> +    /*
> +     * Guests should see errata 400 and 415 as fixed (assuming that
> +     * HLT and IO instructions are intercepted).
> +     */
> +    vcpu->arch.amd.osvw.length = (osvw_length >= 3) ? (osvw_length) : 3;

An expression consisting of just an identifier for sure doesn't need
parentheses.

> +    vcpu->arch.amd.osvw.status = osvw_status & ~(6ULL);
> +
> +    /*
> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
> +     * all osvw.status bits inside that length, including bit 0 (which is
> +     * reserved for erratum 298), are valid. However, if host processor's
> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
> +     * be conservative here and therefore we tell the guest that erratum 298
> +     * is present (because we really don't know).
> +     */
> +    if (osvw_length == 0 && boot_cpu_data.x86 == 0x10)

Why do you check the family here? If osvw_length can only ever be
zero on Fam10, then the first check is sufficient. If osvw_length can
be zero on other than Fam10 (no matter whether we bail early older
CPUs), then the check is actually wrong.

> +	vcpu->arch.amd.osvw.status |= 1;
> +}
> +
> +void amd_vcpu_initialise(struct vcpu *vcpu)
> +{
> +    amd_guest_osvw_init(vcpu);
> +}
> +
>  /*
>   * Check for the presence of an AMD erratum. Arguments are defined in amd.h 
> 
>   * for each known erratum. Return 1 if erratum is found.
> @@ -512,6 +548,30 @@ static void __devinit init_amd(struct cp
>  	set_cpuidmask(c);
>  
>  	check_syscfg_dram_mod_en();
> +
> +    /* 
> +     * Get OSVW bits. If bits are not the same on different processors then
> +     * choose the worst case (i.e. if erratum is present on one processor and
> +     * not on another assume that the erratum is present everywhere).
> +     */
> +     if (test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability)) {
> +         uint64_t len, status;
> +
> +        if (rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
> +            rdmsr_safe(MSR_AMD_OSVW_STATUS, status))
> +            len = status = 0;
> +
> +        spin_lock(&amd_lock);

What is the locking here supposed to protect against? The AP call tree
is smp_callin() -> identify_cpu() -> init_amd(), which cannot race with
anything (as the initiating processor is waiting for cpu_state to change
to CPU_STATE_CALLIN).

> +        
> +        if (len < osvw_length)
> +            osvw_length = len;
> +
> +        osvw_status |= status;
> +        osvw_status &= (1ULL << osvw_length) - 1;
> +
> +        spin_unlock(&amd_lock);
> +    } else
> +	 osvw_length = osvw_status = 0;
>  }
>  
>  static struct cpu_dev amd_cpu_dev __cpuinitdata = {
> --- a/xen/arch/x86/domain.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/xen/arch/x86/domain.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -422,6 +422,10 @@ int vcpu_initialise(struct vcpu *v)
>      if ( (rc = vcpu_init_fpu(v)) != 0 )
>          return rc;
>  
> +    /* Vendor-specific initialization */
> +    if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)

If you check the vendor here, you don't need to anywhere in the
descendant functions.

> +        amd_vcpu_initialise(v);
> +
>      if ( is_hvm_domain(d) )
>      {
>          rc = hvm_vcpu_initialise(v);
> --- a/xen/arch/x86/hvm/svm/svm.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/xen/arch/x86/hvm/svm/svm.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -1044,6 +1044,27 @@ static void svm_init_erratum_383(struct 
>      }
>  }
>  
> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, uint read)
> +{
> +    uint eax, ebx, ecx, edx;
> +     
> +    /* Guest OSVW support */
> +    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
> +    if (!test_bit((X86_FEATURE_OSVW & 31), &ecx))

Formatting of changes to this file should be changed to Xen style.

> +        return -1;
> +
> +    if (read) {
> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
> +            *val = v->arch.amd.osvw.length;
> +        else
> +            *val = v->arch.amd.osvw.status;
> +    } 
> +    /* Writes are ignored */
> +
> +    return 0;
> +}
> +
> +
>  static int svm_cpu_up(void)
>  {
>      uint64_t msr_content;
> --- a/xen/arch/x86/traps.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/xen/arch/x86/traps.c	Mon Jan 16 22:08:09 2012 +0100
> @@ -2542,6 +2542,15 @@ static int emulate_privileged_op(struct 
>              if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
>                  goto fail;
>              break;
> +        case MSR_AMD_OSVW_ID_LENGTH:
> +        case MSR_AMD_OSVW_STATUS:
> +            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) {
> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
> +                    goto fail;
> +                else

Bogus "else" after a "goto". And I wonder, provided there is some
point in doing all this for PV guests in the first place, whether this
shouldn't be kept getting handled by the default case.

> +                    break; /* Writes are ignored */
> +            }
> +            /* Fall through to default case */
>          default:
>              if ( wrmsr_hypervisor_regs(regs->ecx, msr_content) )
>                  break;
> @@ -2573,6 +2582,7 @@ static int emulate_privileged_op(struct 
>          break;
>  
>      case 0x32: /* RDMSR */
> +

Stray addition of a newline.

>          switch ( (u32)regs->ecx )
>          {
>  #ifdef CONFIG_X86_64
> @@ -2632,6 +2642,23 @@ static int emulate_privileged_op(struct 
>              regs->eax = (uint32_t)msr_content;
>              regs->edx = (uint32_t)(msr_content >> 32);
>              break;
> +        case MSR_AMD_OSVW_ID_LENGTH:
> +        case MSR_AMD_OSVW_STATUS:
> +            if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
> +                    goto fail;
> +                else {

Bogus "else" after a "goto".

Jan

> +                    if ((u32)regs->ecx == MSR_AMD_OSVW_ID_LENGTH)
> +                        msr_content = v->arch.amd.osvw.length;
> +                    else
> +                        msr_content = v->arch.amd.osvw.status;
> +
> +                    regs->eax = (uint32_t)msr_content;
> +                    regs->edx = (uint32_t)(msr_content >> 32);
> +                }
> +            } else
> +                goto rdmsr_normal;
> +            break;
>          default:
>              if ( rdmsr_hypervisor_regs(regs->ecx, &val) )
>              {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 08:59:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 08: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 1Rn4sJ-00011X-Ir; Tue, 17 Jan 2012 08:58:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1Rn4sH-00011S-Qe
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 08:58:38 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326790710!12691610!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8235 invoked from network); 17 Jan 2012 08:58:31 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 08:58:31 -0000
Received: by lago2 with SMTP id o2so1895089lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 00:58:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=BMtWOCEP3iYefAV9xHxxcp0ERwsw8OBnU58ndJYGLQA=;
	b=O/YxhQ7NEYHcXzVDJC57HB1zxEli2NGAXiRA/L13W0lWwVg+w36FGMu7Nw3p5I+KBt
	ApqwLwQZ+/MjKfQAMiish+mHHqDriwEqVB5ENYHboaW7B9i9RNukhCS8+d6fbpBAE1DK
	Q0iRPbkewC7tLHbsV4gQtwjpSuY3xI9WWtBUc=
Received: by 10.112.86.135 with SMTP id p7mr3777804lbz.86.1326790710264; Tue,
	17 Jan 2012 00:58:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Tue, 17 Jan 2012 00:58:14 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 17 Jan 2012 12:58:14 +0400
X-Google-Sender-Auth: UMXeG4NP_C6sT2pCSFsldIs-DZU
Message-ID: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] shutdown/migration stop working on paravirt 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

Hello. Today i'm try to research, why most of our vm (pvm) not
shutdown correctly (we use shutdown with timeout, then it arrives we
destroy vm), and write simple test case to check that domU watches
works correctly:

xenstore write /local/domain/DOMID/control/shutdown testflag;
xenstore read /local/domain/DOMID/control/shutdown

If userspace watches works correctly - xenstore read returns empty,
becouse domU kernel respond only to known actions and printk and clean
path on unknown actions.
I can't see difference in various kernel versions
(centos/opensuse/debian and other), we use oxenstored old version
(that shipped with 4.0.1_21326_06-0.4.1 on sles)
How can i debug this issue and get more info on this problem?
P.S. Some domains, that has small uptime respond to my check and
shutdown/migrate correctly.

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 08:59:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 08: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 1Rn4sJ-00011X-Ir; Tue, 17 Jan 2012 08:58:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1Rn4sH-00011S-Qe
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 08:58:38 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326790710!12691610!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8235 invoked from network); 17 Jan 2012 08:58:31 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 08:58:31 -0000
Received: by lago2 with SMTP id o2so1895089lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 00:58:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfip.ru; s=google;
	h=mime-version:sender:x-originating-ip:from:date:x-google-sender-auth
	:message-id:subject:to:content-type;
	bh=BMtWOCEP3iYefAV9xHxxcp0ERwsw8OBnU58ndJYGLQA=;
	b=O/YxhQ7NEYHcXzVDJC57HB1zxEli2NGAXiRA/L13W0lWwVg+w36FGMu7Nw3p5I+KBt
	ApqwLwQZ+/MjKfQAMiish+mHHqDriwEqVB5ENYHboaW7B9i9RNukhCS8+d6fbpBAE1DK
	Q0iRPbkewC7tLHbsV4gQtwjpSuY3xI9WWtBUc=
Received: by 10.112.86.135 with SMTP id p7mr3777804lbz.86.1326790710264; Tue,
	17 Jan 2012 00:58:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Tue, 17 Jan 2012 00:58:14 -0800 (PST)
X-Originating-IP: [85.143.161.18]
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 17 Jan 2012 12:58:14 +0400
X-Google-Sender-Auth: UMXeG4NP_C6sT2pCSFsldIs-DZU
Message-ID: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] shutdown/migration stop working on paravirt 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

Hello. Today i'm try to research, why most of our vm (pvm) not
shutdown correctly (we use shutdown with timeout, then it arrives we
destroy vm), and write simple test case to check that domU watches
works correctly:

xenstore write /local/domain/DOMID/control/shutdown testflag;
xenstore read /local/domain/DOMID/control/shutdown

If userspace watches works correctly - xenstore read returns empty,
becouse domU kernel respond only to known actions and printk and clean
path on unknown actions.
I can't see difference in various kernel versions
(centos/opensuse/debian and other), we use oxenstored old version
(that shipped with 4.0.1_21326_06-0.4.1 on sles)
How can i debug this issue and get more info on this problem?
P.S. Some domains, that has small uptime respond to my check and
shutdown/migrate correctly.

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:08:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:08:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn511-0001E3-UI; Tue, 17 Jan 2012 09:07: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 1Rn511-0001Dy-15
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:07:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326791252!11345495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4615 invoked from network); 17 Jan 2012 09:07:32 -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;
	17 Jan 2012 09:07:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10076730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 09:07: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, 17 Jan 2012 09:07: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 1Rn50u-0002K7-CR;
	Tue, 17 Jan 2012 09:07:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rn50u-0007t1-8G;
	Tue, 17 Jan 2012 09:07:32 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10781-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 09:07:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10781: 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 10781 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10781/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xl-multivcpu 11 guest-localmigrate        fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl           11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-credit2   11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10776 REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10776 REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10776
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10776
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10776

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install        fail in 10776 like 10645

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  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 in 10776 never pass

version targeted for testing:
 xen                  2913ccc6d70f
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                           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                                 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 815 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 Jan 17 09:08:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:08:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn511-0001E3-UI; Tue, 17 Jan 2012 09:07: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 1Rn511-0001Dy-15
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:07:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326791252!11345495!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4615 invoked from network); 17 Jan 2012 09:07:32 -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;
	17 Jan 2012 09:07:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10076730"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 09:07: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, 17 Jan 2012 09:07: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 1Rn50u-0002K7-CR;
	Tue, 17 Jan 2012 09:07:32 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rn50u-0007t1-8G;
	Tue, 17 Jan 2012 09:07:32 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10781-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 09:07:32 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10781: 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 10781 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10781/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xl-multivcpu 11 guest-localmigrate        fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl           11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-credit2   11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10776 REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10776 REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10776
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10776
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10776

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install        fail in 10776 like 10645

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  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 in 10776 never pass

version targeted for testing:
 xen                  2913ccc6d70f
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                           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                                 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 815 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 Jan 17 09:10:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn52w-0001IT-Eo; Tue, 17 Jan 2012 09:09:38 +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 1Rn52v-0001IH-Ay
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:09:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326791369!11291558!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 5044 invoked from network); 17 Jan 2012 09:09:30 -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; 17 Jan 2012 09:09:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Jan 2012 09:09:29 +0000
Message-Id: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Jan 2012 09:09:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <anthony.perard@citrix.com>,
 "Ian Campbell" <Ian.Campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > What are the outstanding things to do before we think we can start on
>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>> > 
>> > hypervisor:
>> > 
>> >       * ??? - Keir, Tim, Jan?
>> 
>> Apart from a few small things that I have on my todo list, the only
>> bigger one (at least from an possible impact perspective) is the
>> round-up of the closing of the security hole in MSI-X passthrough
>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
>> table pages), which I intended to do only once the upstream qemu
>> patch series also incorporates the respective recent qemu-xen
>> change.
> 
> It sounds like this issue is a blocker for the release, whereas the
> upstream qemu support for pci passthrough is not necessarily. Has your
> precondition for inclusion been met yet or do we need to prod someone?

Just for reference, below the intended (trivial) change.

Jan

This continues to leave unaddressed the case where PV guests map the
MSI-X table page(s) before setting up the first MSI-X interrupt (see
the original c/s 22182:68cc3c514a0a description for options).

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -869,7 +869,7 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
-        if ( !(l1f & _PAGE_RW) || IS_PRIV(pg_owner) ||
+        if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
         dprintk(XENLOG_G_WARNING,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:10:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:10:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn52w-0001IT-Eo; Tue, 17 Jan 2012 09:09:38 +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 1Rn52v-0001IH-Ay
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:09:37 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326791369!11291558!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 5044 invoked from network); 17 Jan 2012 09:09:30 -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; 17 Jan 2012 09:09:30 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 17 Jan 2012 09:09:29 +0000
Message-Id: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 17 Jan 2012 09:09:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <anthony.perard@citrix.com>,
 "Ian Campbell" <Ian.Campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, "Tim \(Xen.org\)" <tim@xen.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > What are the outstanding things to do before we think we can start on
>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>> > 
>> > hypervisor:
>> > 
>> >       * ??? - Keir, Tim, Jan?
>> 
>> Apart from a few small things that I have on my todo list, the only
>> bigger one (at least from an possible impact perspective) is the
>> round-up of the closing of the security hole in MSI-X passthrough
>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
>> table pages), which I intended to do only once the upstream qemu
>> patch series also incorporates the respective recent qemu-xen
>> change.
> 
> It sounds like this issue is a blocker for the release, whereas the
> upstream qemu support for pci passthrough is not necessarily. Has your
> precondition for inclusion been met yet or do we need to prod someone?

Just for reference, below the intended (trivial) change.

Jan

This continues to leave unaddressed the case where PV guests map the
MSI-X table page(s) before setting up the first MSI-X interrupt (see
the original c/s 22182:68cc3c514a0a description for options).

--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -869,7 +869,7 @@ get_page_from_l1e(
             return -EINVAL;
         }
 
-        if ( !(l1f & _PAGE_RW) || IS_PRIV(pg_owner) ||
+        if ( !(l1f & _PAGE_RW) ||
              !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             return 0;
         dprintk(XENLOG_G_WARNING,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:18:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09: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 1Rn5Ao-0001ZW-O2; Tue, 17 Jan 2012 09:17: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 1Rn5An-0001ZR-3T
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:17:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326791836!56002906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19086 invoked from network); 17 Jan 2012 09:17:16 -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;
	17 Jan 2012 09:17:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10076976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 09:17:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 09:17:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 09:17:43 +0000
In-Reply-To: <20244.25907.223422.50324@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326791863.14689.52.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAxLTE2IGF0IDE3OjU4ICswMDAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBS
b2dlciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBEcml2ZXIgZG9tYWlucyBh
bmQgaG90cGx1ZyBzY3JpcHRzLCByZWR1eCIpOgo+ID4gMjAxMi8xLzEyIElhbiBKYWNrc29uIDxJ
YW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiA+ID4gSWFuIENhbXBiZWxsIHdyaXRlcyAoIlJl
OiBbWGVuLWRldmVsXSBEcml2ZXIgZG9tYWlucyBhbmQgaG90cGx1ZyBzY3JpcHRzLCByZWR1eCIp
Ogo+ID4gPj4gVGhlIGZvcmNlZnVsIGRlc3Ryb3kgY2FzZSBpcyBkaWZmZXJlbnQsIGl0IGlzIGVm
ZmVjdGl2ZWx5Ogo+ID4gPj4gMS4gcm0gYmFja2VuZCBkaXIgaW4geGVuc3RvcmUuCj4gPiA+Cj4g
PiA+IFRoYXQncyAoaWlpKS4gIFdlIHdhbnQgYSB3YXkgdG8gZG8gKGlpKSBhcyB3ZWxsLgo+ID4g
Cj4gPiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIChpaWkpIHNob3VsZCBvbmx5IGhhcHBlbiBhZnRl
ciAoaSkgb3IgKGlpKSBoYXMKPiA+IGZhaWxlZCAodGltZW91dCBvciBlcnJvciB0cnlpbmcgdG8g
dW5wbHVnIGRldmljZXMpLgo+IAo+IFRoZXJlIGhhcyB0byBiZSBhIHVzZXIgb3B0aW9uIHRvIGFz
ayBmb3IgYSAidmVyeSBmb3JjZWZ1bCIgZGV0YWNoLgo+IAo+ID4gV2hhdCBzaG91bGQgd2UgZG8g
d2l0aCB4ZW5kPyBBcmUgd2Uga2VlcGluZyBpdCBvbiA0LjI/IEknbSBhc2tpbmcgdGhpcwo+ID4g
YmVjYXVzZSB0aGUgY2hhbmdlcyBJJ20gaW50cm9kdWNpbmcgZGlzYWJsZXMgc29tZSB1ZGV2IHJ1
bGVzIHRoYXQgYXJlCj4gPiBuZWVkZWQgZm9yIHhlbmQuIFRoZSBvdGhlciBvcHRpb24gaXMgdG8g
dXBkYXRlIHhlbmQgdG8gdGFsayB0bwo+ID4geGVuYmFja2VuZGQgYWxzby4KPiAKPiBJIHRoaW5r
IHhlbmQgaXMgbm90IGdvaW5nIHRvIGdvIGF3YXkgaW4gNC4yLCB1bmZvcnR1bmF0ZWx5LgoKSG93
ZXZlciB4ZW5kIHNob3VsZCBub3QgYmUgdHJhbnNpdGlvbiB0byB0aGlzIG5ldyBzY2hlbWUgYnV0
IHNob3VsZApjb250aW51ZSB0byB1c2UgaXRzIGV4aXN0aW5nIHNjcmlwdHMgaW4gdGhlIGN1cnJl
bnQgbWFubmVyLgoKVGhlcmUgd2FzIGEgY29udmVyc2F0aW9uIGxhc3QgeWVhclswXSBhYm91dCBo
b3cgYSB0b29sc3RhY2sgY291bGQKb3B0LWluL291dCBvZiB0aGUgdXNlIG9mIHRoZSBob3RwbHVn
IHNjcmlwdHMuIFdlIGRlY2lkZWQgdGhhdCB0b29sc3RhY2tzCnNob3VsZCBoYXZlIHRvIG9wdCBp
bnRvIHRoZSB1c2Ugb2YgdGhlc2Ugc2NyaXB0cywgYnkgdG91Y2hpbmcgYSBzdGFtcApmaWxlLgoK
QWx0aG91Z2ggdGhpcyB3YXNuJ3QgaW1wbGVtZW50ZWQgeWV0ICh1bmxlc3MgSSBtaXNzZWQgaXQp
IEkgZ3Vlc3MgdGhlCnNhbWUgc2NoZW1lIHdvdWxkIGFwcGx5IHRvIHRoaXMgd29yayBpZiB0aGF0
IHNvcnQgb2YgdGhpbmcgdHVybnMgb3V0IHRvCmJlIG5lY2Vzc2FyeS4KCklhbi4KClswXSBodHRw
Oi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTA2L21zZzAwOTUy
Lmh0bWwKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:18:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09: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 1Rn5Ao-0001ZW-O2; Tue, 17 Jan 2012 09:17: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 1Rn5An-0001ZR-3T
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:17:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326791836!56002906!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19086 invoked from network); 17 Jan 2012 09:17:16 -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;
	17 Jan 2012 09:17:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10076976"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 09:17:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 09:17:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 09:17:43 +0000
In-Reply-To: <20244.25907.223422.50324@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326791863.14689.52.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gTW9uLCAyMDEyLTAxLTE2IGF0IDE3OjU4ICswMDAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBS
b2dlciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBEcml2ZXIgZG9tYWlucyBh
bmQgaG90cGx1ZyBzY3JpcHRzLCByZWR1eCIpOgo+ID4gMjAxMi8xLzEyIElhbiBKYWNrc29uIDxJ
YW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiA+ID4gSWFuIENhbXBiZWxsIHdyaXRlcyAoIlJl
OiBbWGVuLWRldmVsXSBEcml2ZXIgZG9tYWlucyBhbmQgaG90cGx1ZyBzY3JpcHRzLCByZWR1eCIp
Ogo+ID4gPj4gVGhlIGZvcmNlZnVsIGRlc3Ryb3kgY2FzZSBpcyBkaWZmZXJlbnQsIGl0IGlzIGVm
ZmVjdGl2ZWx5Ogo+ID4gPj4gMS4gcm0gYmFja2VuZCBkaXIgaW4geGVuc3RvcmUuCj4gPiA+Cj4g
PiA+IFRoYXQncyAoaWlpKS4gIFdlIHdhbnQgYSB3YXkgdG8gZG8gKGlpKSBhcyB3ZWxsLgo+ID4g
Cj4gPiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIChpaWkpIHNob3VsZCBvbmx5IGhhcHBlbiBhZnRl
ciAoaSkgb3IgKGlpKSBoYXMKPiA+IGZhaWxlZCAodGltZW91dCBvciBlcnJvciB0cnlpbmcgdG8g
dW5wbHVnIGRldmljZXMpLgo+IAo+IFRoZXJlIGhhcyB0byBiZSBhIHVzZXIgb3B0aW9uIHRvIGFz
ayBmb3IgYSAidmVyeSBmb3JjZWZ1bCIgZGV0YWNoLgo+IAo+ID4gV2hhdCBzaG91bGQgd2UgZG8g
d2l0aCB4ZW5kPyBBcmUgd2Uga2VlcGluZyBpdCBvbiA0LjI/IEknbSBhc2tpbmcgdGhpcwo+ID4g
YmVjYXVzZSB0aGUgY2hhbmdlcyBJJ20gaW50cm9kdWNpbmcgZGlzYWJsZXMgc29tZSB1ZGV2IHJ1
bGVzIHRoYXQgYXJlCj4gPiBuZWVkZWQgZm9yIHhlbmQuIFRoZSBvdGhlciBvcHRpb24gaXMgdG8g
dXBkYXRlIHhlbmQgdG8gdGFsayB0bwo+ID4geGVuYmFja2VuZGQgYWxzby4KPiAKPiBJIHRoaW5r
IHhlbmQgaXMgbm90IGdvaW5nIHRvIGdvIGF3YXkgaW4gNC4yLCB1bmZvcnR1bmF0ZWx5LgoKSG93
ZXZlciB4ZW5kIHNob3VsZCBub3QgYmUgdHJhbnNpdGlvbiB0byB0aGlzIG5ldyBzY2hlbWUgYnV0
IHNob3VsZApjb250aW51ZSB0byB1c2UgaXRzIGV4aXN0aW5nIHNjcmlwdHMgaW4gdGhlIGN1cnJl
bnQgbWFubmVyLgoKVGhlcmUgd2FzIGEgY29udmVyc2F0aW9uIGxhc3QgeWVhclswXSBhYm91dCBo
b3cgYSB0b29sc3RhY2sgY291bGQKb3B0LWluL291dCBvZiB0aGUgdXNlIG9mIHRoZSBob3RwbHVn
IHNjcmlwdHMuIFdlIGRlY2lkZWQgdGhhdCB0b29sc3RhY2tzCnNob3VsZCBoYXZlIHRvIG9wdCBp
bnRvIHRoZSB1c2Ugb2YgdGhlc2Ugc2NyaXB0cywgYnkgdG91Y2hpbmcgYSBzdGFtcApmaWxlLgoK
QWx0aG91Z2ggdGhpcyB3YXNuJ3QgaW1wbGVtZW50ZWQgeWV0ICh1bmxlc3MgSSBtaXNzZWQgaXQp
IEkgZ3Vlc3MgdGhlCnNhbWUgc2NoZW1lIHdvdWxkIGFwcGx5IHRvIHRoaXMgd29yayBpZiB0aGF0
IHNvcnQgb2YgdGhpbmcgdHVybnMgb3V0IHRvCmJlIG5lY2Vzc2FyeS4KCklhbi4KClswXSBodHRw
Oi8vbGlzdHMueGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTA2L21zZzAwOTUy
Lmh0bWwKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpY
ZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6
Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:23:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:23:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5Fo-0001hm-GF; Tue, 17 Jan 2012 09:22:56 +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 1Rn5Fn-0001hc-Tj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:22:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326792167!9396849!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 2277 invoked from network); 17 Jan 2012 09:22:49 -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;
	17 Jan 2012 09:22:49 -0000
Received: by dadp15 with SMTP id p15so22424569dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 01:22: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=FFdl1zvty+b/kf8fuYrV26mw3xyt7UqHFMmnqkiVt8M=;
	b=Pi0RKw3NY8BH2stLsS2BTSEFFDDFhOpW9VIcfX6NO8S5BnBBpeoswDj/lvemhlEFfU
	UxMF5T7zWt2BM8VLu3AY+JrqX6Ja45RalpxMCFBRdGWYs3XJmWek/xZkKZVk6nAf6zZI
	UtpdH7kNIGBLqoIKUg+caym8Qvf7kIYDIfDUM=
MIME-Version: 1.0
Received: by 10.68.211.104 with SMTP id nb8mr25653985pbc.39.1326792166552;
	Tue, 17 Jan 2012 01:22:46 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 01:22:46 -0800 (PST)
In-Reply-To: <20244.25907.223422.50324@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
Date: Tue, 17 Jan 2012 10:22:46 +0100
X-Google-Sender-Auth: mnm3I9XoBwYHMmjydQTx5BAy-xs
Message-ID: <CAPLaKK5yrBF8iU0uE9Zfd=oUWSGMcntBTcrtjFbdtAyNUaoK4A@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE2IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBEcml2ZXIgZG9tYWlucyBhbmQg
aG90cGx1ZyBzY3JpcHRzLCByZWR1eCIpOgo+PiAyMDEyLzEvMTIgSWFuIEphY2tzb24gPElhbi5K
YWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiA+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hl
bi1kZXZlbF0gRHJpdmVyIGRvbWFpbnMgYW5kIGhvdHBsdWcgc2NyaXB0cywgcmVkdXgiKToKPj4g
Pj4gVGhlIGZvcmNlZnVsIGRlc3Ryb3kgY2FzZSBpcyBkaWZmZXJlbnQsIGl0IGlzIGVmZmVjdGl2
ZWx5Ogo+PiA+PiAxLiBybSBiYWNrZW5kIGRpciBpbiB4ZW5zdG9yZS4KPj4gPgo+PiA+IFRoYXQn
cyAoaWlpKS4gwqBXZSB3YW50IGEgd2F5IHRvIGRvIChpaSkgYXMgd2VsbC4KPj4KPj4gRnJvbSBt
eSBwb2ludCBvZiB2aWV3LCAoaWlpKSBzaG91bGQgb25seSBoYXBwZW4gYWZ0ZXIgKGkpIG9yIChp
aSkgaGFzCj4+IGZhaWxlZCAodGltZW91dCBvciBlcnJvciB0cnlpbmcgdG8gdW5wbHVnIGRldmlj
ZXMpLgo+Cj4gVGhlcmUgaGFzIHRvIGJlIGEgdXNlciBvcHRpb24gdG8gYXNrIGZvciBhICJ2ZXJ5
IGZvcmNlZnVsIiBkZXRhY2guCgpMZXQncyBtYXAgY3VycmVudCBzaHV0ZG93biBvcHRpb25zIHRv
IHlvdXIgcG9pbnRzOgoKeGwgc2h1dGRvd24gLT4gKGkpCnhsIGRlc3Ryb3kgLT4gKGlpKSBvciAo
aWlpKSBpZiB0aW1lb3V0IGhhcHBlbnMgd2hpbGUgdHJ5aW5nIHRvIHVucGx1ZyBkZXZpY2VzLgp4
bCBkZXN0cm95IC1mIC0+IChpaWkpPwoKSSBndWVzcyBhZGRpbmcgYSAtZiB0byBkZXN0cm95IGlz
IGVhc3kgYW5kIGl0IHNob3VsZCB3b3JrIGFzIHlvdQpkZXNjcmliZWQgaW4gKGlpaSkuCgo+Cj4+
IFdoYXQgc2hvdWxkIHdlIGRvIHdpdGggeGVuZD8gQXJlIHdlIGtlZXBpbmcgaXQgb24gNC4yPyBJ
J20gYXNraW5nIHRoaXMKPj4gYmVjYXVzZSB0aGUgY2hhbmdlcyBJJ20gaW50cm9kdWNpbmcgZGlz
YWJsZXMgc29tZSB1ZGV2IHJ1bGVzIHRoYXQgYXJlCj4+IG5lZWRlZCBmb3IgeGVuZC4gVGhlIG90
aGVyIG9wdGlvbiBpcyB0byB1cGRhdGUgeGVuZCB0byB0YWxrIHRvCj4+IHhlbmJhY2tlbmRkIGFs
c28uCj4KPiBJIHRoaW5rIHhlbmQgaXMgbm90IGdvaW5nIHRvIGdvIGF3YXkgaW4gNC4yLCB1bmZv
cnR1bmF0ZWx5LgoKSSBzZWUgcGFpbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:23:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:23:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5Fo-0001hm-GF; Tue, 17 Jan 2012 09:22:56 +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 1Rn5Fn-0001hc-Tj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:22:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326792167!9396849!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 2277 invoked from network); 17 Jan 2012 09:22:49 -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;
	17 Jan 2012 09:22:49 -0000
Received: by dadp15 with SMTP id p15so22424569dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 01:22: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=FFdl1zvty+b/kf8fuYrV26mw3xyt7UqHFMmnqkiVt8M=;
	b=Pi0RKw3NY8BH2stLsS2BTSEFFDDFhOpW9VIcfX6NO8S5BnBBpeoswDj/lvemhlEFfU
	UxMF5T7zWt2BM8VLu3AY+JrqX6Ja45RalpxMCFBRdGWYs3XJmWek/xZkKZVk6nAf6zZI
	UtpdH7kNIGBLqoIKUg+caym8Qvf7kIYDIfDUM=
MIME-Version: 1.0
Received: by 10.68.211.104 with SMTP id nb8mr25653985pbc.39.1326792166552;
	Tue, 17 Jan 2012 01:22:46 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 01:22:46 -0800 (PST)
In-Reply-To: <20244.25907.223422.50324@mariner.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
Date: Tue, 17 Jan 2012 10:22:46 +0100
X-Google-Sender-Auth: mnm3I9XoBwYHMmjydQTx5BAy-xs
Message-ID: <CAPLaKK5yrBF8iU0uE9Zfd=oUWSGMcntBTcrtjFbdtAyNUaoK4A@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE2IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBEcml2ZXIgZG9tYWlucyBhbmQg
aG90cGx1ZyBzY3JpcHRzLCByZWR1eCIpOgo+PiAyMDEyLzEvMTIgSWFuIEphY2tzb24gPElhbi5K
YWNrc29uQGV1LmNpdHJpeC5jb20+Ogo+PiA+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hl
bi1kZXZlbF0gRHJpdmVyIGRvbWFpbnMgYW5kIGhvdHBsdWcgc2NyaXB0cywgcmVkdXgiKToKPj4g
Pj4gVGhlIGZvcmNlZnVsIGRlc3Ryb3kgY2FzZSBpcyBkaWZmZXJlbnQsIGl0IGlzIGVmZmVjdGl2
ZWx5Ogo+PiA+PiAxLiBybSBiYWNrZW5kIGRpciBpbiB4ZW5zdG9yZS4KPj4gPgo+PiA+IFRoYXQn
cyAoaWlpKS4gwqBXZSB3YW50IGEgd2F5IHRvIGRvIChpaSkgYXMgd2VsbC4KPj4KPj4gRnJvbSBt
eSBwb2ludCBvZiB2aWV3LCAoaWlpKSBzaG91bGQgb25seSBoYXBwZW4gYWZ0ZXIgKGkpIG9yIChp
aSkgaGFzCj4+IGZhaWxlZCAodGltZW91dCBvciBlcnJvciB0cnlpbmcgdG8gdW5wbHVnIGRldmlj
ZXMpLgo+Cj4gVGhlcmUgaGFzIHRvIGJlIGEgdXNlciBvcHRpb24gdG8gYXNrIGZvciBhICJ2ZXJ5
IGZvcmNlZnVsIiBkZXRhY2guCgpMZXQncyBtYXAgY3VycmVudCBzaHV0ZG93biBvcHRpb25zIHRv
IHlvdXIgcG9pbnRzOgoKeGwgc2h1dGRvd24gLT4gKGkpCnhsIGRlc3Ryb3kgLT4gKGlpKSBvciAo
aWlpKSBpZiB0aW1lb3V0IGhhcHBlbnMgd2hpbGUgdHJ5aW5nIHRvIHVucGx1ZyBkZXZpY2VzLgp4
bCBkZXN0cm95IC1mIC0+IChpaWkpPwoKSSBndWVzcyBhZGRpbmcgYSAtZiB0byBkZXN0cm95IGlz
IGVhc3kgYW5kIGl0IHNob3VsZCB3b3JrIGFzIHlvdQpkZXNjcmliZWQgaW4gKGlpaSkuCgo+Cj4+
IFdoYXQgc2hvdWxkIHdlIGRvIHdpdGggeGVuZD8gQXJlIHdlIGtlZXBpbmcgaXQgb24gNC4yPyBJ
J20gYXNraW5nIHRoaXMKPj4gYmVjYXVzZSB0aGUgY2hhbmdlcyBJJ20gaW50cm9kdWNpbmcgZGlz
YWJsZXMgc29tZSB1ZGV2IHJ1bGVzIHRoYXQgYXJlCj4+IG5lZWRlZCBmb3IgeGVuZC4gVGhlIG90
aGVyIG9wdGlvbiBpcyB0byB1cGRhdGUgeGVuZCB0byB0YWxrIHRvCj4+IHhlbmJhY2tlbmRkIGFs
c28uCj4KPiBJIHRoaW5rIHhlbmQgaXMgbm90IGdvaW5nIHRvIGdvIGF3YXkgaW4gNC4yLCB1bmZv
cnR1bmF0ZWx5LgoKSSBzZWUgcGFpbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:31:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:31:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5NS-0001sy-GB; Tue, 17 Jan 2012 09:30:50 +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 1Rn5NQ-0001sq-Mj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:30:48 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326792640!11219600!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 9043 invoked from network); 17 Jan 2012 09:30:41 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 09:30:41 -0000
Received: by dadp15 with SMTP id p15so22447924dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 01:30:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=/0ZEh83PxR7Fh9CdEv3c/J/t4sFs5KdFDRJ2I/hvFEs=;
	b=rTADOb7h9G45eiX+QmqTleBLWCKISI06h+9H4OGX5m5FYc1eqLEuNbArN2ZPTJkYsB
	P4aSPGWuPLiABzLT4lGqQMK3sHBKWI2wYB8VgNb10FExJK6M3UptmuHsMKQxU40MxTBt
	aI0jqLpUFeQOamjegKcjwuPzsXAC62ymBpFwU=
MIME-Version: 1.0
Received: by 10.68.212.40 with SMTP id nh8mr26062103pbc.73.1326792639595; Tue,
	17 Jan 2012 01:30:39 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 01:30:39 -0800 (PST)
In-Reply-To: <1326791863.14689.52.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Jan 2012 10:30:39 +0100
X-Google-Sender-Auth: N9XrzMsbz0JHxtZGNB1uTKFsgfM
Message-ID: <CAPLaKK4XbdEVYC41mwtYkf2Y7883oWK38t8cAYfFufeKs2THsQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMS0xNiBhdCAxNzo1OCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+IFJvZ2Vy
IFBhdSBNb25uw6kgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIERyaXZlciBkb21haW5zIGFuZCBo
b3RwbHVnIHNjcmlwdHMsIHJlZHV4Iik6Cj4+ID4gMjAxMi8xLzEyIElhbiBKYWNrc29uIDxJYW4u
SmFja3NvbkBldS5jaXRyaXguY29tPjoKPj4gPiA+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTog
W1hlbi1kZXZlbF0gRHJpdmVyIGRvbWFpbnMgYW5kIGhvdHBsdWcgc2NyaXB0cywgcmVkdXgiKToK
Pj4gPiA+PiBUaGUgZm9yY2VmdWwgZGVzdHJveSBjYXNlIGlzIGRpZmZlcmVudCwgaXQgaXMgZWZm
ZWN0aXZlbHk6Cj4+ID4gPj4gMS4gcm0gYmFja2VuZCBkaXIgaW4geGVuc3RvcmUuCj4+ID4gPgo+
PiA+ID4gVGhhdCdzIChpaWkpLiDCoFdlIHdhbnQgYSB3YXkgdG8gZG8gKGlpKSBhcyB3ZWxsLgo+
PiA+Cj4+ID4gRnJvbSBteSBwb2ludCBvZiB2aWV3LCAoaWlpKSBzaG91bGQgb25seSBoYXBwZW4g
YWZ0ZXIgKGkpIG9yIChpaSkgaGFzCj4+ID4gZmFpbGVkICh0aW1lb3V0IG9yIGVycm9yIHRyeWlu
ZyB0byB1bnBsdWcgZGV2aWNlcykuCj4+Cj4+IFRoZXJlIGhhcyB0byBiZSBhIHVzZXIgb3B0aW9u
IHRvIGFzayBmb3IgYSAidmVyeSBmb3JjZWZ1bCIgZGV0YWNoLgo+Pgo+PiA+IFdoYXQgc2hvdWxk
IHdlIGRvIHdpdGggeGVuZD8gQXJlIHdlIGtlZXBpbmcgaXQgb24gNC4yPyBJJ20gYXNraW5nIHRo
aXMKPj4gPiBiZWNhdXNlIHRoZSBjaGFuZ2VzIEknbSBpbnRyb2R1Y2luZyBkaXNhYmxlcyBzb21l
IHVkZXYgcnVsZXMgdGhhdCBhcmUKPj4gPiBuZWVkZWQgZm9yIHhlbmQuIFRoZSBvdGhlciBvcHRp
b24gaXMgdG8gdXBkYXRlIHhlbmQgdG8gdGFsayB0bwo+PiA+IHhlbmJhY2tlbmRkIGFsc28uCj4+
Cj4+IEkgdGhpbmsgeGVuZCBpcyBub3QgZ29pbmcgdG8gZ28gYXdheSBpbiA0LjIsIHVuZm9ydHVu
YXRlbHkuCj4KPiBIb3dldmVyIHhlbmQgc2hvdWxkIG5vdCBiZSB0cmFuc2l0aW9uIHRvIHRoaXMg
bmV3IHNjaGVtZSBidXQgc2hvdWxkCj4gY29udGludWUgdG8gdXNlIGl0cyBleGlzdGluZyBzY3Jp
cHRzIGluIHRoZSBjdXJyZW50IG1hbm5lci4KPgo+IFRoZXJlIHdhcyBhIGNvbnZlcnNhdGlvbiBs
YXN0IHllYXJbMF0gYWJvdXQgaG93IGEgdG9vbHN0YWNrIGNvdWxkCj4gb3B0LWluL291dCBvZiB0
aGUgdXNlIG9mIHRoZSBob3RwbHVnIHNjcmlwdHMuIFdlIGRlY2lkZWQgdGhhdCB0b29sc3RhY2tz
Cj4gc2hvdWxkIGhhdmUgdG8gb3B0IGludG8gdGhlIHVzZSBvZiB0aGVzZSBzY3JpcHRzLCBieSB0
b3VjaGluZyBhIHN0YW1wCj4gZmlsZS4KCkknbSBub3Qgc3VyZSB0aGlzIHNvbHZlcyBvdXIgcHJv
YmxlbXMsIHNpbmNlIHRoaXMgZG9lc24ndCBkaXNhYmxlIHVkZXYKZXhhY3RseSwgaXQgZGlzYWJs
ZXMgaG90cGx1ZyBzY3JpcHRzIGVudGlyZWx5LCBidXQgdGhleSBhcmUgbmVlZGVkCmZyb20gbGli
eGwgYWxzbyAobXkgYXBwcm9hY2ggdXNlcyB0aGUgY3VycmVudCBob3RwbHVnIHNjcmlwdHMpLgoK
QWxzbywgaWYgYm90aCB4bCBhbmQgeGVuZCBhcmUgcnVubmluZywgdGhlcmUgYXJlIGEgbG90IG9m
IGNoYW5jZXMgb2YKZ2V0dGluZyBhIG1lc3MsIHNpbmNlIG1hY2hpbmVzIHN0YXJ0ZWQgZnJvbSB4
bCAodXNpbmcgdGhlIG5ldyB4ZW5zdG9yZQpwcm90b2NvbCAvaG90cGx1Zy8uLi4pIGNvdWxkIG5v
dCBiZSBzdG9wcGVkIHN1Y2Nlc3NmdWxseSBmcm9tIHhlbmQsCmFuZCB0aGUgb3RoZXIgd2F5IGFy
b3VuZC4KCj4gQWx0aG91Z2ggdGhpcyB3YXNuJ3QgaW1wbGVtZW50ZWQgeWV0ICh1bmxlc3MgSSBt
aXNzZWQgaXQpIEkgZ3Vlc3MgdGhlCj4gc2FtZSBzY2hlbWUgd291bGQgYXBwbHkgdG8gdGhpcyB3
b3JrIGlmIHRoYXQgc29ydCBvZiB0aGluZyB0dXJucyBvdXQgdG8KPiBiZSBuZWNlc3NhcnkuCj4K
PiBJYW4uCj4KPiBbMF0gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2
ZWwvMjAxMS0wNi9tc2cwMDk1Mi5odG1sCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:31:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:31:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5NS-0001sy-GB; Tue, 17 Jan 2012 09:30:50 +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 1Rn5NQ-0001sq-Mj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:30:48 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326792640!11219600!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 9043 invoked from network); 17 Jan 2012 09:30:41 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 09:30:41 -0000
Received: by dadp15 with SMTP id p15so22447924dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 01:30:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=/0ZEh83PxR7Fh9CdEv3c/J/t4sFs5KdFDRJ2I/hvFEs=;
	b=rTADOb7h9G45eiX+QmqTleBLWCKISI06h+9H4OGX5m5FYc1eqLEuNbArN2ZPTJkYsB
	P4aSPGWuPLiABzLT4lGqQMK3sHBKWI2wYB8VgNb10FExJK6M3UptmuHsMKQxU40MxTBt
	aI0jqLpUFeQOamjegKcjwuPzsXAC62ymBpFwU=
MIME-Version: 1.0
Received: by 10.68.212.40 with SMTP id nh8mr26062103pbc.73.1326792639595; Tue,
	17 Jan 2012 01:30:39 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 01:30:39 -0800 (PST)
In-Reply-To: <1326791863.14689.52.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Jan 2012 10:30:39 +0100
X-Google-Sender-Auth: N9XrzMsbz0JHxtZGNB1uTKFsgfM
Message-ID: <CAPLaKK4XbdEVYC41mwtYkf2Y7883oWK38t8cAYfFufeKs2THsQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMS0xNiBhdCAxNzo1OCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+IFJvZ2Vy
IFBhdSBNb25uw6kgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIERyaXZlciBkb21haW5zIGFuZCBo
b3RwbHVnIHNjcmlwdHMsIHJlZHV4Iik6Cj4+ID4gMjAxMi8xLzEyIElhbiBKYWNrc29uIDxJYW4u
SmFja3NvbkBldS5jaXRyaXguY29tPjoKPj4gPiA+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTog
W1hlbi1kZXZlbF0gRHJpdmVyIGRvbWFpbnMgYW5kIGhvdHBsdWcgc2NyaXB0cywgcmVkdXgiKToK
Pj4gPiA+PiBUaGUgZm9yY2VmdWwgZGVzdHJveSBjYXNlIGlzIGRpZmZlcmVudCwgaXQgaXMgZWZm
ZWN0aXZlbHk6Cj4+ID4gPj4gMS4gcm0gYmFja2VuZCBkaXIgaW4geGVuc3RvcmUuCj4+ID4gPgo+
PiA+ID4gVGhhdCdzIChpaWkpLiDCoFdlIHdhbnQgYSB3YXkgdG8gZG8gKGlpKSBhcyB3ZWxsLgo+
PiA+Cj4+ID4gRnJvbSBteSBwb2ludCBvZiB2aWV3LCAoaWlpKSBzaG91bGQgb25seSBoYXBwZW4g
YWZ0ZXIgKGkpIG9yIChpaSkgaGFzCj4+ID4gZmFpbGVkICh0aW1lb3V0IG9yIGVycm9yIHRyeWlu
ZyB0byB1bnBsdWcgZGV2aWNlcykuCj4+Cj4+IFRoZXJlIGhhcyB0byBiZSBhIHVzZXIgb3B0aW9u
IHRvIGFzayBmb3IgYSAidmVyeSBmb3JjZWZ1bCIgZGV0YWNoLgo+Pgo+PiA+IFdoYXQgc2hvdWxk
IHdlIGRvIHdpdGggeGVuZD8gQXJlIHdlIGtlZXBpbmcgaXQgb24gNC4yPyBJJ20gYXNraW5nIHRo
aXMKPj4gPiBiZWNhdXNlIHRoZSBjaGFuZ2VzIEknbSBpbnRyb2R1Y2luZyBkaXNhYmxlcyBzb21l
IHVkZXYgcnVsZXMgdGhhdCBhcmUKPj4gPiBuZWVkZWQgZm9yIHhlbmQuIFRoZSBvdGhlciBvcHRp
b24gaXMgdG8gdXBkYXRlIHhlbmQgdG8gdGFsayB0bwo+PiA+IHhlbmJhY2tlbmRkIGFsc28uCj4+
Cj4+IEkgdGhpbmsgeGVuZCBpcyBub3QgZ29pbmcgdG8gZ28gYXdheSBpbiA0LjIsIHVuZm9ydHVu
YXRlbHkuCj4KPiBIb3dldmVyIHhlbmQgc2hvdWxkIG5vdCBiZSB0cmFuc2l0aW9uIHRvIHRoaXMg
bmV3IHNjaGVtZSBidXQgc2hvdWxkCj4gY29udGludWUgdG8gdXNlIGl0cyBleGlzdGluZyBzY3Jp
cHRzIGluIHRoZSBjdXJyZW50IG1hbm5lci4KPgo+IFRoZXJlIHdhcyBhIGNvbnZlcnNhdGlvbiBs
YXN0IHllYXJbMF0gYWJvdXQgaG93IGEgdG9vbHN0YWNrIGNvdWxkCj4gb3B0LWluL291dCBvZiB0
aGUgdXNlIG9mIHRoZSBob3RwbHVnIHNjcmlwdHMuIFdlIGRlY2lkZWQgdGhhdCB0b29sc3RhY2tz
Cj4gc2hvdWxkIGhhdmUgdG8gb3B0IGludG8gdGhlIHVzZSBvZiB0aGVzZSBzY3JpcHRzLCBieSB0
b3VjaGluZyBhIHN0YW1wCj4gZmlsZS4KCkknbSBub3Qgc3VyZSB0aGlzIHNvbHZlcyBvdXIgcHJv
YmxlbXMsIHNpbmNlIHRoaXMgZG9lc24ndCBkaXNhYmxlIHVkZXYKZXhhY3RseSwgaXQgZGlzYWJs
ZXMgaG90cGx1ZyBzY3JpcHRzIGVudGlyZWx5LCBidXQgdGhleSBhcmUgbmVlZGVkCmZyb20gbGli
eGwgYWxzbyAobXkgYXBwcm9hY2ggdXNlcyB0aGUgY3VycmVudCBob3RwbHVnIHNjcmlwdHMpLgoK
QWxzbywgaWYgYm90aCB4bCBhbmQgeGVuZCBhcmUgcnVubmluZywgdGhlcmUgYXJlIGEgbG90IG9m
IGNoYW5jZXMgb2YKZ2V0dGluZyBhIG1lc3MsIHNpbmNlIG1hY2hpbmVzIHN0YXJ0ZWQgZnJvbSB4
bCAodXNpbmcgdGhlIG5ldyB4ZW5zdG9yZQpwcm90b2NvbCAvaG90cGx1Zy8uLi4pIGNvdWxkIG5v
dCBiZSBzdG9wcGVkIHN1Y2Nlc3NmdWxseSBmcm9tIHhlbmQsCmFuZCB0aGUgb3RoZXIgd2F5IGFy
b3VuZC4KCj4gQWx0aG91Z2ggdGhpcyB3YXNuJ3QgaW1wbGVtZW50ZWQgeWV0ICh1bmxlc3MgSSBt
aXNzZWQgaXQpIEkgZ3Vlc3MgdGhlCj4gc2FtZSBzY2hlbWUgd291bGQgYXBwbHkgdG8gdGhpcyB3
b3JrIGlmIHRoYXQgc29ydCBvZiB0aGluZyB0dXJucyBvdXQgdG8KPiBiZSBuZWNlc3NhcnkuCj4K
PiBJYW4uCj4KPiBbMF0gaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2
ZWwvMjAxMS0wNi9tc2cwMDk1Mi5odG1sCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:41:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09: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 1Rn5X1-0002EC-6Z; Tue, 17 Jan 2012 09:40:43 +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 1Rn5X0-0002Dp-9E
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:40:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326793234!11302307!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 31161 invoked from network); 17 Jan 2012 09:40:36 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 09:40:36 -0000
Received: by pbcc6 with SMTP id c6so28896557pbc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 01:40: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;
	bh=SZnzO2yZ226vctrQlqJvromlAEi8v7+WFXyZSvYZES4=;
	b=IQR5kuEC801sTkq00pSNXAt2ixYE1fJPljt9dO97+JXNqPqWE+LtATpC1W3683mf6y
	1dE0V2iH/Fb+nzAKR9ROehacoIgdORqcT1kfwJXFE27Uy3TqhzUiKIL+hyr4mP7fa0tu
	GNWXslAI05Hm3YT0B/SFv43qz70ZOcjixfXzg=
MIME-Version: 1.0
Received: by 10.68.212.40 with SMTP id nh8mr26118065pbc.73.1326793233886; Tue,
	17 Jan 2012 01:40:33 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 01:40:33 -0800 (PST)
In-Reply-To: <1326791863.14689.52.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Jan 2012 10:40:33 +0100
X-Google-Sender-Auth: NNNvmWxYUynXuaSh25WhiWJSB2k
Message-ID: <CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
> However xend should not be transition to this new scheme but should
> continue to use its existing scripts in the current manner.
>
> There was a conversation last year[0] about how a toolstack could
> opt-in/out of the use of the hotplug scripts. We decided that toolstacks
> should have to opt into the use of these scripts, by touching a stamp
> file.
>
> Although this wasn't implemented yet (unless I missed it) I guess the
> same scheme would apply to this work if that sort of thing turns out to
> be necessary.

Sorry for replying so many times, this is a big maybe, and possibly
it's too drastic, but after this changes xl and xend will not be
compatible anymore, so why don't we disable xend by default, and only
build xl?

When the new configure script is in, it will be trivial to select if
you want xl or xend, and only install one of those. Adding the option
--enable-xend should disable xl and only build and install xend
(printing a very big warning that xend is deprecated).

> Ian.
>
> [0] http://lists.xen.org/archives/html/xen-devel/2011-06/msg00952.html
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:41:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09: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 1Rn5X1-0002EC-6Z; Tue, 17 Jan 2012 09:40:43 +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 1Rn5X0-0002Dp-9E
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:40:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326793234!11302307!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 31161 invoked from network); 17 Jan 2012 09:40:36 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 09:40:36 -0000
Received: by pbcc6 with SMTP id c6so28896557pbc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 01:40: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;
	bh=SZnzO2yZ226vctrQlqJvromlAEi8v7+WFXyZSvYZES4=;
	b=IQR5kuEC801sTkq00pSNXAt2ixYE1fJPljt9dO97+JXNqPqWE+LtATpC1W3683mf6y
	1dE0V2iH/Fb+nzAKR9ROehacoIgdORqcT1kfwJXFE27Uy3TqhzUiKIL+hyr4mP7fa0tu
	GNWXslAI05Hm3YT0B/SFv43qz70ZOcjixfXzg=
MIME-Version: 1.0
Received: by 10.68.212.40 with SMTP id nh8mr26118065pbc.73.1326793233886; Tue,
	17 Jan 2012 01:40:33 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 01:40:33 -0800 (PST)
In-Reply-To: <1326791863.14689.52.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Jan 2012 10:40:33 +0100
X-Google-Sender-Auth: NNNvmWxYUynXuaSh25WhiWJSB2k
Message-ID: <CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/17 Ian Campbell <Ian.Campbell@citrix.com>:
> However xend should not be transition to this new scheme but should
> continue to use its existing scripts in the current manner.
>
> There was a conversation last year[0] about how a toolstack could
> opt-in/out of the use of the hotplug scripts. We decided that toolstacks
> should have to opt into the use of these scripts, by touching a stamp
> file.
>
> Although this wasn't implemented yet (unless I missed it) I guess the
> same scheme would apply to this work if that sort of thing turns out to
> be necessary.

Sorry for replying so many times, this is a big maybe, and possibly
it's too drastic, but after this changes xl and xend will not be
compatible anymore, so why don't we disable xend by default, and only
build xl?

When the new configure script is in, it will be trivial to select if
you want xl or xend, and only install one of those. Adding the option
--enable-xend should disable xl and only build and install xend
(printing a very big warning that xend is deprecated).

> Ian.
>
> [0] http://lists.xen.org/archives/html/xen-devel/2011-06/msg00952.html
>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:43:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5Zd-0002P2-PD; Tue, 17 Jan 2012 09:43:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rn5Zc-0002Ob-28
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:43:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326793398!11331345!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16113 invoked from network); 17 Jan 2012 09:43:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 09:43:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10077590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 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;
	Tue, 17 Jan 2012 09:43:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 17 Jan 2012 09:43:17 +0000
In-Reply-To: <CAPLaKK4XbdEVYC41mwtYkf2Y7883oWK38t8cAYfFufeKs2THsQ@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK4XbdEVYC41mwtYkf2Y7883oWK38t8cAYfFufeKs2THsQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326793397.14689.71.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAxLTE3IGF0IDA5OjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8xNyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIE1vbiwgMjAxMi0wMS0xNiBhdCAxNzo1OCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4g
Pj4gUm9nZXIgUGF1IE1vbm7DqSB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gRHJpdmVyIGRvbWFp
bnMgYW5kIGhvdHBsdWcgc2NyaXB0cywgcmVkdXgiKToKPiA+PiA+IDIwMTIvMS8xMiBJYW4gSmFj
a3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gPj4gPiA+IElhbiBDYW1wYmVsbCB3
cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gRHJpdmVyIGRvbWFpbnMgYW5kIGhvdHBsdWcgc2NyaXB0
cywgcmVkdXgiKToKPiA+PiA+ID4+IFRoZSBmb3JjZWZ1bCBkZXN0cm95IGNhc2UgaXMgZGlmZmVy
ZW50LCBpdCBpcyBlZmZlY3RpdmVseToKPiA+PiA+ID4+IDEuIHJtIGJhY2tlbmQgZGlyIGluIHhl
bnN0b3JlLgo+ID4+ID4gPgo+ID4+ID4gPiBUaGF0J3MgKGlpaSkuICBXZSB3YW50IGEgd2F5IHRv
IGRvIChpaSkgYXMgd2VsbC4KPiA+PiA+Cj4gPj4gPiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIChp
aWkpIHNob3VsZCBvbmx5IGhhcHBlbiBhZnRlciAoaSkgb3IgKGlpKSBoYXMKPiA+PiA+IGZhaWxl
ZCAodGltZW91dCBvciBlcnJvciB0cnlpbmcgdG8gdW5wbHVnIGRldmljZXMpLgo+ID4+Cj4gPj4g
VGhlcmUgaGFzIHRvIGJlIGEgdXNlciBvcHRpb24gdG8gYXNrIGZvciBhICJ2ZXJ5IGZvcmNlZnVs
IiBkZXRhY2guCj4gPj4KPiA+PiA+IFdoYXQgc2hvdWxkIHdlIGRvIHdpdGggeGVuZD8gQXJlIHdl
IGtlZXBpbmcgaXQgb24gNC4yPyBJJ20gYXNraW5nIHRoaXMKPiA+PiA+IGJlY2F1c2UgdGhlIGNo
YW5nZXMgSSdtIGludHJvZHVjaW5nIGRpc2FibGVzIHNvbWUgdWRldiBydWxlcyB0aGF0IGFyZQo+
ID4+ID4gbmVlZGVkIGZvciB4ZW5kLiBUaGUgb3RoZXIgb3B0aW9uIGlzIHRvIHVwZGF0ZSB4ZW5k
IHRvIHRhbGsgdG8KPiA+PiA+IHhlbmJhY2tlbmRkIGFsc28uCj4gPj4KPiA+PiBJIHRoaW5rIHhl
bmQgaXMgbm90IGdvaW5nIHRvIGdvIGF3YXkgaW4gNC4yLCB1bmZvcnR1bmF0ZWx5Lgo+ID4KPiA+
IEhvd2V2ZXIgeGVuZCBzaG91bGQgbm90IGJlIHRyYW5zaXRpb24gdG8gdGhpcyBuZXcgc2NoZW1l
IGJ1dCBzaG91bGQKPiA+IGNvbnRpbnVlIHRvIHVzZSBpdHMgZXhpc3Rpbmcgc2NyaXB0cyBpbiB0
aGUgY3VycmVudCBtYW5uZXIuCj4gPgo+ID4gVGhlcmUgd2FzIGEgY29udmVyc2F0aW9uIGxhc3Qg
eWVhclswXSBhYm91dCBob3cgYSB0b29sc3RhY2sgY291bGQKPiA+IG9wdC1pbi9vdXQgb2YgdGhl
IHVzZSBvZiB0aGUgaG90cGx1ZyBzY3JpcHRzLiBXZSBkZWNpZGVkIHRoYXQgdG9vbHN0YWNrcwo+
ID4gc2hvdWxkIGhhdmUgdG8gb3B0IGludG8gdGhlIHVzZSBvZiB0aGVzZSBzY3JpcHRzLCBieSB0
b3VjaGluZyBhIHN0YW1wCj4gPiBmaWxlLgo+IAo+IEknbSBub3Qgc3VyZSB0aGlzIHNvbHZlcyBv
dXIgcHJvYmxlbXMsIHNpbmNlIHRoaXMgZG9lc24ndCBkaXNhYmxlIHVkZXYKPiBleGFjdGx5LCBp
dCBkaXNhYmxlcyBob3RwbHVnIHNjcmlwdHMgZW50aXJlbHksIGJ1dCB0aGV5IGFyZSBuZWVkZWQK
PiBmcm9tIGxpYnhsIGFsc28gKG15IGFwcHJvYWNoIHVzZXMgdGhlIGN1cnJlbnQgaG90cGx1ZyBz
Y3JpcHRzKS4KClN1cmUsIEkgd2Fzbid0IHN1cmUgZXhhY3RseSB3aGF0IGFwcHJvYWNoIHdhcyBi
ZWluZyBwbGFubmVkLgoKPiBBbHNvLCBpZiBib3RoIHhsIGFuZCB4ZW5kIGFyZSBydW5uaW5nLAoK
VGhhdCBpcyBub3QgYSBzdXBwb3J0ZWQgY29uZmlndXJhdGlvbiBzbyBJIGRvbid0IHRoaW5rIHdl
IHNob3VsZCBjb25jZXJuCm91cnNlbHZlcyB1bmR1bHkgd2l0aCBpdC4KCkxldHMgZml4IHhsIHRv
IHdvcmsgaG93IHdlIHdhbnQgaXQgYW5kIHRoZW4gd2UgY2FuIGxvb2sgYXQgd2F5cyBvZgptYWtp
bmcgc3VyZSB0aGF0IG5vdGhpbmcgY2hhbmdlcyBpZiB5b3UgYXJlIHVzaW5nIHhlbmQuCgo+ICB0
aGVyZSBhcmUgYSBsb3Qgb2YgY2hhbmNlcyBvZgo+IGdldHRpbmcgYSBtZXNzLCBzaW5jZSBtYWNo
aW5lcyBzdGFydGVkIGZyb20geGwgKHVzaW5nIHRoZSBuZXcgeGVuc3RvcmUKPiBwcm90b2NvbCAv
aG90cGx1Zy8uLi4pIGNvdWxkIG5vdCBiZSBzdG9wcGVkIHN1Y2Nlc3NmdWxseSBmcm9tIHhlbmQs
Cj4gYW5kIHRoZSBvdGhlciB3YXkgYXJvdW5kLgo+IAo+ID4gQWx0aG91Z2ggdGhpcyB3YXNuJ3Qg
aW1wbGVtZW50ZWQgeWV0ICh1bmxlc3MgSSBtaXNzZWQgaXQpIEkgZ3Vlc3MgdGhlCj4gPiBzYW1l
IHNjaGVtZSB3b3VsZCBhcHBseSB0byB0aGlzIHdvcmsgaWYgdGhhdCBzb3J0IG9mIHRoaW5nIHR1
cm5zIG91dCB0bwo+ID4gYmUgbmVjZXNzYXJ5Lgo+ID4KPiA+IElhbi4KPiA+Cj4gPiBbMF0gaHR0
cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0wNi9tc2cwMDk1
Mi5odG1sCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:43:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:43:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5Zd-0002P2-PD; Tue, 17 Jan 2012 09:43:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rn5Zc-0002Ob-28
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:43:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326793398!11331345!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16113 invoked from network); 17 Jan 2012 09:43:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 09:43:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10077590"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 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;
	Tue, 17 Jan 2012 09:43:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 17 Jan 2012 09:43:17 +0000
In-Reply-To: <CAPLaKK4XbdEVYC41mwtYkf2Y7883oWK38t8cAYfFufeKs2THsQ@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK4XbdEVYC41mwtYkf2Y7883oWK38t8cAYfFufeKs2THsQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326793397.14689.71.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAxLTE3IGF0IDA5OjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8xNyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIE1vbiwgMjAxMi0wMS0xNiBhdCAxNzo1OCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4g
Pj4gUm9nZXIgUGF1IE1vbm7DqSB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gRHJpdmVyIGRvbWFp
bnMgYW5kIGhvdHBsdWcgc2NyaXB0cywgcmVkdXgiKToKPiA+PiA+IDIwMTIvMS8xMiBJYW4gSmFj
a3NvbiA8SWFuLkphY2tzb25AZXUuY2l0cml4LmNvbT46Cj4gPj4gPiA+IElhbiBDYW1wYmVsbCB3
cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gRHJpdmVyIGRvbWFpbnMgYW5kIGhvdHBsdWcgc2NyaXB0
cywgcmVkdXgiKToKPiA+PiA+ID4+IFRoZSBmb3JjZWZ1bCBkZXN0cm95IGNhc2UgaXMgZGlmZmVy
ZW50LCBpdCBpcyBlZmZlY3RpdmVseToKPiA+PiA+ID4+IDEuIHJtIGJhY2tlbmQgZGlyIGluIHhl
bnN0b3JlLgo+ID4+ID4gPgo+ID4+ID4gPiBUaGF0J3MgKGlpaSkuICBXZSB3YW50IGEgd2F5IHRv
IGRvIChpaSkgYXMgd2VsbC4KPiA+PiA+Cj4gPj4gPiBGcm9tIG15IHBvaW50IG9mIHZpZXcsIChp
aWkpIHNob3VsZCBvbmx5IGhhcHBlbiBhZnRlciAoaSkgb3IgKGlpKSBoYXMKPiA+PiA+IGZhaWxl
ZCAodGltZW91dCBvciBlcnJvciB0cnlpbmcgdG8gdW5wbHVnIGRldmljZXMpLgo+ID4+Cj4gPj4g
VGhlcmUgaGFzIHRvIGJlIGEgdXNlciBvcHRpb24gdG8gYXNrIGZvciBhICJ2ZXJ5IGZvcmNlZnVs
IiBkZXRhY2guCj4gPj4KPiA+PiA+IFdoYXQgc2hvdWxkIHdlIGRvIHdpdGggeGVuZD8gQXJlIHdl
IGtlZXBpbmcgaXQgb24gNC4yPyBJJ20gYXNraW5nIHRoaXMKPiA+PiA+IGJlY2F1c2UgdGhlIGNo
YW5nZXMgSSdtIGludHJvZHVjaW5nIGRpc2FibGVzIHNvbWUgdWRldiBydWxlcyB0aGF0IGFyZQo+
ID4+ID4gbmVlZGVkIGZvciB4ZW5kLiBUaGUgb3RoZXIgb3B0aW9uIGlzIHRvIHVwZGF0ZSB4ZW5k
IHRvIHRhbGsgdG8KPiA+PiA+IHhlbmJhY2tlbmRkIGFsc28uCj4gPj4KPiA+PiBJIHRoaW5rIHhl
bmQgaXMgbm90IGdvaW5nIHRvIGdvIGF3YXkgaW4gNC4yLCB1bmZvcnR1bmF0ZWx5Lgo+ID4KPiA+
IEhvd2V2ZXIgeGVuZCBzaG91bGQgbm90IGJlIHRyYW5zaXRpb24gdG8gdGhpcyBuZXcgc2NoZW1l
IGJ1dCBzaG91bGQKPiA+IGNvbnRpbnVlIHRvIHVzZSBpdHMgZXhpc3Rpbmcgc2NyaXB0cyBpbiB0
aGUgY3VycmVudCBtYW5uZXIuCj4gPgo+ID4gVGhlcmUgd2FzIGEgY29udmVyc2F0aW9uIGxhc3Qg
eWVhclswXSBhYm91dCBob3cgYSB0b29sc3RhY2sgY291bGQKPiA+IG9wdC1pbi9vdXQgb2YgdGhl
IHVzZSBvZiB0aGUgaG90cGx1ZyBzY3JpcHRzLiBXZSBkZWNpZGVkIHRoYXQgdG9vbHN0YWNrcwo+
ID4gc2hvdWxkIGhhdmUgdG8gb3B0IGludG8gdGhlIHVzZSBvZiB0aGVzZSBzY3JpcHRzLCBieSB0
b3VjaGluZyBhIHN0YW1wCj4gPiBmaWxlLgo+IAo+IEknbSBub3Qgc3VyZSB0aGlzIHNvbHZlcyBv
dXIgcHJvYmxlbXMsIHNpbmNlIHRoaXMgZG9lc24ndCBkaXNhYmxlIHVkZXYKPiBleGFjdGx5LCBp
dCBkaXNhYmxlcyBob3RwbHVnIHNjcmlwdHMgZW50aXJlbHksIGJ1dCB0aGV5IGFyZSBuZWVkZWQK
PiBmcm9tIGxpYnhsIGFsc28gKG15IGFwcHJvYWNoIHVzZXMgdGhlIGN1cnJlbnQgaG90cGx1ZyBz
Y3JpcHRzKS4KClN1cmUsIEkgd2Fzbid0IHN1cmUgZXhhY3RseSB3aGF0IGFwcHJvYWNoIHdhcyBi
ZWluZyBwbGFubmVkLgoKPiBBbHNvLCBpZiBib3RoIHhsIGFuZCB4ZW5kIGFyZSBydW5uaW5nLAoK
VGhhdCBpcyBub3QgYSBzdXBwb3J0ZWQgY29uZmlndXJhdGlvbiBzbyBJIGRvbid0IHRoaW5rIHdl
IHNob3VsZCBjb25jZXJuCm91cnNlbHZlcyB1bmR1bHkgd2l0aCBpdC4KCkxldHMgZml4IHhsIHRv
IHdvcmsgaG93IHdlIHdhbnQgaXQgYW5kIHRoZW4gd2UgY2FuIGxvb2sgYXQgd2F5cyBvZgptYWtp
bmcgc3VyZSB0aGF0IG5vdGhpbmcgY2hhbmdlcyBpZiB5b3UgYXJlIHVzaW5nIHhlbmQuCgo+ICB0
aGVyZSBhcmUgYSBsb3Qgb2YgY2hhbmNlcyBvZgo+IGdldHRpbmcgYSBtZXNzLCBzaW5jZSBtYWNo
aW5lcyBzdGFydGVkIGZyb20geGwgKHVzaW5nIHRoZSBuZXcgeGVuc3RvcmUKPiBwcm90b2NvbCAv
aG90cGx1Zy8uLi4pIGNvdWxkIG5vdCBiZSBzdG9wcGVkIHN1Y2Nlc3NmdWxseSBmcm9tIHhlbmQs
Cj4gYW5kIHRoZSBvdGhlciB3YXkgYXJvdW5kLgo+IAo+ID4gQWx0aG91Z2ggdGhpcyB3YXNuJ3Qg
aW1wbGVtZW50ZWQgeWV0ICh1bmxlc3MgSSBtaXNzZWQgaXQpIEkgZ3Vlc3MgdGhlCj4gPiBzYW1l
IHNjaGVtZSB3b3VsZCBhcHBseSB0byB0aGlzIHdvcmsgaWYgdGhhdCBzb3J0IG9mIHRoaW5nIHR1
cm5zIG91dCB0bwo+ID4gYmUgbmVjZXNzYXJ5Lgo+ID4KPiA+IElhbi4KPiA+Cj4gPiBbMF0gaHR0
cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0wNi9tc2cwMDk1
Mi5odG1sCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Clhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:48:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09: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 1Rn5dl-0002kZ-Fc; Tue, 17 Jan 2012 09:47:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rn5dk-0002gr-14
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:47:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326793612!60523891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14576 invoked from network); 17 Jan 2012 09:46:52 -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;
	17 Jan 2012 09:46:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10077677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 09:47: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, 17 Jan 2012 09:47:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Doug Magee <djmagee@mageenet.net>
Date: Tue, 17 Jan 2012 09:47:25 +0000
In-Reply-To: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326793645.14689.75.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
 assignable before adding 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

On Mon, 2012-01-16 at 22:36 +0000, Doug Magee wrote:
> Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.
> 
> Signed-off-by: Doug Magee <djmagee@mageenet.net>

Thanks Doug. Would this be better done by adding a call to
libxl_device_pci_list_assignable and looking for the device in it? In
fact from the looks of things this could replace the existing call to
get_all_assigned_devices from .._pci_add since
libxl_device_pci_list_assignable already omits devices which are
assigned to another domain.

Ian.

> 
> diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_pci.c	Mon Jan 16 17:31:25 2012 -0500
> @@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
>      libxl_device_pci *assigned;
>      int num_assigned, i, rc;
>      int stubdomid = 0;
> +    struct dirent *de;
> +    DIR *dir;
> +    int assignable = 0;
>  
>      rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
>      if ( rc ) {
> @@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
>          goto out;
>      }
>  
> +    dir = opendir(SYSFS_PCIBACK_DRIVER);
> +    if ( NULL == dir ) {
> +        if ( errno == ENOENT ) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
> +        }else{
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
> +        }
> +        rc = ERROR_FAIL;
> +        goto out_closedir;
> +    }
> +
> +    while( (de = readdir(dir)) ) {
> +        unsigned dom, bus, dev, func;
> +        if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
> +            continue;
> +        if ( dom == pcidev->domain && bus == pcidev->bus &&
> +              dev == pcidev->dev && func == pcidev->func ) {
> +            assignable = 1;
> +            break;
> +        }
> +    }
> +
> +    if ( !assignable ) {
> +        rc = ERROR_FAIL;
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
> +        goto out_closedir;
> +    }
> +
> +
>      libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
>  
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
> @@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
>          /* stubdomain is always running by now, even at create time */
>          rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
>          if ( rc )
> -            goto out;
> +            goto out_closedir;
>      }
>  
>      orig_vdev = pcidev->vdevfn & ~7U;
> @@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
>          if ( !(pcidev->vdevfn >> 3) ) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
>              rc = ERROR_INVAL;
> -            goto out;
> +            goto out_closedir;
>          }
>          if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
>              rc = ERROR_FAIL;
> -            goto out;
> +            goto out_closedir;
>          }
>          pcidev->vfunc_mask &= pfunc_mask;
>          /* so now vfunc_mask == pfunc_mask */
> @@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
>          }
>      }
>  
> +out_closedir:
> +    closedir(dir);
>  out:
>      return rc;
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 17 09:48:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09: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 1Rn5dl-0002kZ-Fc; Tue, 17 Jan 2012 09:47:41 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rn5dk-0002gr-14
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:47:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326793612!60523891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14576 invoked from network); 17 Jan 2012 09:46:52 -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;
	17 Jan 2012 09:46:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10077677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 09:47: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, 17 Jan 2012 09:47:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Doug Magee <djmagee@mageenet.net>
Date: Tue, 17 Jan 2012 09:47:25 +0000
In-Reply-To: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326793645.14689.75.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
 assignable before adding 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

On Mon, 2012-01-16 at 22:36 +0000, Doug Magee wrote:
> Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.
> 
> Signed-off-by: Doug Magee <djmagee@mageenet.net>

Thanks Doug. Would this be better done by adding a call to
libxl_device_pci_list_assignable and looking for the device in it? In
fact from the looks of things this could replace the existing call to
get_all_assigned_devices from .._pci_add since
libxl_device_pci_list_assignable already omits devices which are
assigned to another domain.

Ian.

> 
> diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_pci.c	Mon Jan 16 17:31:25 2012 -0500
> @@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
>      libxl_device_pci *assigned;
>      int num_assigned, i, rc;
>      int stubdomid = 0;
> +    struct dirent *de;
> +    DIR *dir;
> +    int assignable = 0;
>  
>      rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
>      if ( rc ) {
> @@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
>          goto out;
>      }
>  
> +    dir = opendir(SYSFS_PCIBACK_DRIVER);
> +    if ( NULL == dir ) {
> +        if ( errno == ENOENT ) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
> +        }else{
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
> +        }
> +        rc = ERROR_FAIL;
> +        goto out_closedir;
> +    }
> +
> +    while( (de = readdir(dir)) ) {
> +        unsigned dom, bus, dev, func;
> +        if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
> +            continue;
> +        if ( dom == pcidev->domain && bus == pcidev->bus &&
> +              dev == pcidev->dev && func == pcidev->func ) {
> +            assignable = 1;
> +            break;
> +        }
> +    }
> +
> +    if ( !assignable ) {
> +        rc = ERROR_FAIL;
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
> +        goto out_closedir;
> +    }
> +
> +
>      libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
>  
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
> @@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
>          /* stubdomain is always running by now, even at create time */
>          rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
>          if ( rc )
> -            goto out;
> +            goto out_closedir;
>      }
>  
>      orig_vdev = pcidev->vdevfn & ~7U;
> @@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
>          if ( !(pcidev->vdevfn >> 3) ) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
>              rc = ERROR_INVAL;
> -            goto out;
> +            goto out_closedir;
>          }
>          if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
>              rc = ERROR_FAIL;
> -            goto out;
> +            goto out_closedir;
>          }
>          pcidev->vfunc_mask &= pfunc_mask;
>          /* so now vfunc_mask == pfunc_mask */
> @@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
>          }
>      }
>  
> +out_closedir:
> +    closedir(dir);
>  out:
>      return rc;
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 17 09:52:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5iQ-0002ys-C0; Tue, 17 Jan 2012 09:52: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 1Rn5iP-0002yi-5J
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:52:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326793942!8612646!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2757 invoked from network); 17 Jan 2012 09:52:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 09:52:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10077766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 09:52:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 09:52:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 17 Jan 2012 09:52:06 +0000
In-Reply-To: <CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326793927.14689.80.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAxLTE3IGF0IDA5OjQwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8xNyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IEhvd2V2ZXIgeGVuZCBzaG91bGQgbm90IGJlIHRyYW5zaXRpb24gdG8gdGhpcyBuZXcgc2NoZW1l
IGJ1dCBzaG91bGQKPiA+IGNvbnRpbnVlIHRvIHVzZSBpdHMgZXhpc3Rpbmcgc2NyaXB0cyBpbiB0
aGUgY3VycmVudCBtYW5uZXIuCj4gPgo+ID4gVGhlcmUgd2FzIGEgY29udmVyc2F0aW9uIGxhc3Qg
eWVhclswXSBhYm91dCBob3cgYSB0b29sc3RhY2sgY291bGQKPiA+IG9wdC1pbi9vdXQgb2YgdGhl
IHVzZSBvZiB0aGUgaG90cGx1ZyBzY3JpcHRzLiBXZSBkZWNpZGVkIHRoYXQgdG9vbHN0YWNrcwo+
ID4gc2hvdWxkIGhhdmUgdG8gb3B0IGludG8gdGhlIHVzZSBvZiB0aGVzZSBzY3JpcHRzLCBieSB0
b3VjaGluZyBhIHN0YW1wCj4gPiBmaWxlLgo+ID4KPiA+IEFsdGhvdWdoIHRoaXMgd2Fzbid0IGlt
cGxlbWVudGVkIHlldCAodW5sZXNzIEkgbWlzc2VkIGl0KSBJIGd1ZXNzIHRoZQo+ID4gc2FtZSBz
Y2hlbWUgd291bGQgYXBwbHkgdG8gdGhpcyB3b3JrIGlmIHRoYXQgc29ydCBvZiB0aGluZyB0dXJu
cyBvdXQgdG8KPiA+IGJlIG5lY2Vzc2FyeS4KPiAKPiBTb3JyeSBmb3IgcmVwbHlpbmcgc28gbWFu
eSB0aW1lcywgdGhpcyBpcyBhIGJpZyBtYXliZSwgYW5kIHBvc3NpYmx5Cj4gaXQncyB0b28gZHJh
c3RpYywgYnV0IGFmdGVyIHRoaXMgY2hhbmdlcyB4bCBhbmQgeGVuZCB3aWxsIG5vdCBiZQo+IGNv
bXBhdGlibGUgYW55bW9yZSwgc28gd2h5IGRvbid0IHdlIGRpc2FibGUgeGVuZCBieSBkZWZhdWx0
LCBhbmQgb25seQo+IGJ1aWxkIHhsPwoKSSBkb24ndCB0aGluayB0aGV5IGFyZSBjb21wYXRpYmxl
IG5vdywgYXJlIHRoZXk/IEkndmUgY2VydGFpbmx5IHNlZW4gb2RkCmJlaGF2aW91ciB3aGVuIHVz
aW5nIHhsIHdpdGggeGVuZCAoYWNjaWRlbnRhbGx5KSBydW5uaW5nLCB1c3VhbGx5IHhlbmQKcmVh
cHMgdGhlIGRvbWFpbiBJJ3ZlIGp1c3Qgc3RhcnRlZC4uLgoKSSdtIGFsbCBmb3IgZGlzYWJsaW5n
IHRoZSBidWlsZCBvZiB4ZW5kIGJ5IGRlZmF1bHQgYnV0IEkgaGFkIGFzc3VtZWQKdGhhdCBvdGhl
cnMgd291bGQgdGhpbmsgNC4yIHdhcyByYXRoZXIgYW4gYWdncmVzc2l2ZSB0aW1lbGluZSBmb3Ig
dGhhdC4KCj4gV2hlbiB0aGUgbmV3IGNvbmZpZ3VyZSBzY3JpcHQgaXMgaW4sIGl0IHdpbGwgYmUg
dHJpdmlhbCB0byBzZWxlY3QgaWYKPiB5b3Ugd2FudCB4bCBvciB4ZW5kLCBhbmQgb25seSBpbnN0
YWxsIG9uZSBvZiB0aG9zZS4gQWRkaW5nIHRoZSBvcHRpb24KPiAtLWVuYWJsZS14ZW5kIHNob3Vs
ZCBkaXNhYmxlIHhsIGFuZCBvbmx5IGJ1aWxkIGFuZCBpbnN0YWxsIHhlbmQKPiAocHJpbnRpbmcg
YSB2ZXJ5IGJpZyB3YXJuaW5nIHRoYXQgeGVuZCBpcyBkZXByZWNhdGVkKS4KCkkgZG9uJ3QgdGhp
bmsgLS1lbmFibGUteGVuZCBzaG91bGQgZXZlciBkaXNhYmxlIHhsIChvciB2aWNlIHZlcnNhKS4g
TWFueQpmb2xrcyAoZS5nLiBkaXN0cm9zKSB3aWxsIHdhbnQgdG8gYnVpbGQgYm90aCwgcGVyaGFw
cyB0byBwYWNrYWdlIHRoZW0gaW4KdHdvIGRpZmZlcmVudCBiaW5hcnkgcGFja2FnZXMsIGJ1dCBj
ZXJ0YWlubHkgdG8gb2ZmZXIgdGhlaXIgdXNlcnMgdGhlCmNob2ljZSwgYXQgbGVhc3QgZm9yIHRo
ZSB0aW1lIGJlaW5nLgoKPiAKPiA+IElhbi4KPiA+Cj4gPiBbMF0gaHR0cDovL2xpc3RzLnhlbi5v
cmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0wNi9tc2cwMDk1Mi5odG1sCj4gPgoKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 17 09:52:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 09:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5iQ-0002ys-C0; Tue, 17 Jan 2012 09:52: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 1Rn5iP-0002yi-5J
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:52:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326793942!8612646!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2757 invoked from network); 17 Jan 2012 09:52:22 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 09:52:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10077766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 09:52:07 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 09:52:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 17 Jan 2012 09:52:06 +0000
In-Reply-To: <CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326793927.14689.80.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAxLTE3IGF0IDA5OjQwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8xNyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IEhvd2V2ZXIgeGVuZCBzaG91bGQgbm90IGJlIHRyYW5zaXRpb24gdG8gdGhpcyBuZXcgc2NoZW1l
IGJ1dCBzaG91bGQKPiA+IGNvbnRpbnVlIHRvIHVzZSBpdHMgZXhpc3Rpbmcgc2NyaXB0cyBpbiB0
aGUgY3VycmVudCBtYW5uZXIuCj4gPgo+ID4gVGhlcmUgd2FzIGEgY29udmVyc2F0aW9uIGxhc3Qg
eWVhclswXSBhYm91dCBob3cgYSB0b29sc3RhY2sgY291bGQKPiA+IG9wdC1pbi9vdXQgb2YgdGhl
IHVzZSBvZiB0aGUgaG90cGx1ZyBzY3JpcHRzLiBXZSBkZWNpZGVkIHRoYXQgdG9vbHN0YWNrcwo+
ID4gc2hvdWxkIGhhdmUgdG8gb3B0IGludG8gdGhlIHVzZSBvZiB0aGVzZSBzY3JpcHRzLCBieSB0
b3VjaGluZyBhIHN0YW1wCj4gPiBmaWxlLgo+ID4KPiA+IEFsdGhvdWdoIHRoaXMgd2Fzbid0IGlt
cGxlbWVudGVkIHlldCAodW5sZXNzIEkgbWlzc2VkIGl0KSBJIGd1ZXNzIHRoZQo+ID4gc2FtZSBz
Y2hlbWUgd291bGQgYXBwbHkgdG8gdGhpcyB3b3JrIGlmIHRoYXQgc29ydCBvZiB0aGluZyB0dXJu
cyBvdXQgdG8KPiA+IGJlIG5lY2Vzc2FyeS4KPiAKPiBTb3JyeSBmb3IgcmVwbHlpbmcgc28gbWFu
eSB0aW1lcywgdGhpcyBpcyBhIGJpZyBtYXliZSwgYW5kIHBvc3NpYmx5Cj4gaXQncyB0b28gZHJh
c3RpYywgYnV0IGFmdGVyIHRoaXMgY2hhbmdlcyB4bCBhbmQgeGVuZCB3aWxsIG5vdCBiZQo+IGNv
bXBhdGlibGUgYW55bW9yZSwgc28gd2h5IGRvbid0IHdlIGRpc2FibGUgeGVuZCBieSBkZWZhdWx0
LCBhbmQgb25seQo+IGJ1aWxkIHhsPwoKSSBkb24ndCB0aGluayB0aGV5IGFyZSBjb21wYXRpYmxl
IG5vdywgYXJlIHRoZXk/IEkndmUgY2VydGFpbmx5IHNlZW4gb2RkCmJlaGF2aW91ciB3aGVuIHVz
aW5nIHhsIHdpdGggeGVuZCAoYWNjaWRlbnRhbGx5KSBydW5uaW5nLCB1c3VhbGx5IHhlbmQKcmVh
cHMgdGhlIGRvbWFpbiBJJ3ZlIGp1c3Qgc3RhcnRlZC4uLgoKSSdtIGFsbCBmb3IgZGlzYWJsaW5n
IHRoZSBidWlsZCBvZiB4ZW5kIGJ5IGRlZmF1bHQgYnV0IEkgaGFkIGFzc3VtZWQKdGhhdCBvdGhl
cnMgd291bGQgdGhpbmsgNC4yIHdhcyByYXRoZXIgYW4gYWdncmVzc2l2ZSB0aW1lbGluZSBmb3Ig
dGhhdC4KCj4gV2hlbiB0aGUgbmV3IGNvbmZpZ3VyZSBzY3JpcHQgaXMgaW4sIGl0IHdpbGwgYmUg
dHJpdmlhbCB0byBzZWxlY3QgaWYKPiB5b3Ugd2FudCB4bCBvciB4ZW5kLCBhbmQgb25seSBpbnN0
YWxsIG9uZSBvZiB0aG9zZS4gQWRkaW5nIHRoZSBvcHRpb24KPiAtLWVuYWJsZS14ZW5kIHNob3Vs
ZCBkaXNhYmxlIHhsIGFuZCBvbmx5IGJ1aWxkIGFuZCBpbnN0YWxsIHhlbmQKPiAocHJpbnRpbmcg
YSB2ZXJ5IGJpZyB3YXJuaW5nIHRoYXQgeGVuZCBpcyBkZXByZWNhdGVkKS4KCkkgZG9uJ3QgdGhp
bmsgLS1lbmFibGUteGVuZCBzaG91bGQgZXZlciBkaXNhYmxlIHhsIChvciB2aWNlIHZlcnNhKS4g
TWFueQpmb2xrcyAoZS5nLiBkaXN0cm9zKSB3aWxsIHdhbnQgdG8gYnVpbGQgYm90aCwgcGVyaGFw
cyB0byBwYWNrYWdlIHRoZW0gaW4KdHdvIGRpZmZlcmVudCBiaW5hcnkgcGFja2FnZXMsIGJ1dCBj
ZXJ0YWlubHkgdG8gb2ZmZXIgdGhlaXIgdXNlcnMgdGhlCmNob2ljZSwgYXQgbGVhc3QgZm9yIHRo
ZSB0aW1lIGJlaW5nLgoKPiAKPiA+IElhbi4KPiA+Cj4gPiBbMF0gaHR0cDovL2xpc3RzLnhlbi5v
cmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0wNi9tc2cwMDk1Mi5odG1sCj4gPgoKCgpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwg
bWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54
ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:00:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 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 1Rn5pq-0003Gg-AS; Tue, 17 Jan 2012 10:00: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 1Rn5po-0003Gb-Fl
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:00:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326794401!9466193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1483 invoked from network); 17 Jan 2012 10:00:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 10:00:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10077957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 10:00:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 10:00:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Tue, 17 Jan 2012 10:00:01 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Roger Pau Monne <roger.pau@entel.upc.edu>, Stefano
	Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] Xen 4.2 TODO List 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

An updated version of the list is below. Some items are marked "nice to
have" meaning that we don't think they should block the release. I'll
try and post an update on a semi-regular basis as and when things are
completed.

I think I have incorporated all the updates made in the last thread as
well as correctly reflected the status of each item. Please let me know
if something is out of date e.g. if progress has been made which I
haven't reflected below.

hypervisor, blockers:

      * round-up of the closing of the security hole in MSI-X
        passthrough (uniformly - i.e. even for Dom0 - disallowing write
        access to MSI-X table pages). (Jan Beulich, after upstream qemu
        patch series also incorporates the respective recent qemu-xen
        change)
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice (and schedule rate, if that ever makes it
        in). (George Dunlap)
      * get the interface changes for sharing/paging/mem-events done and
        dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
        Andres Lagar-Cavilla et al)
              * mem event ring management posted, seems close to going
                in.
              * sharing patches posted
              * 

tools, blockers:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (Ian Jackson, posted several rounds,
                nearing completion?)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate) (Ian Campbell, first RFC sent)
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                first RFC sent)
              * The topologyinfo datastructure should be a list of
                tuples, not a tuple of lists. (nobody currently looking
                at this, not 100% sure this makes sense, could possibly
                defer and change after 4.2 in a compatible way)
              * Block script support -- can be done post 4.2? should be
                nice to have not blocker? Somewhere on IanJ's todo?
      * xl to use json for machine readable output instead of sexp by
        default (Ian Campbell to revisit existing patch)
      * xl feature parity with xend wrt driver domain support (George
        Dunlap)
      * Integrate qemu+seabios upstream into the build (Stefano to
        repost). No change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

hypervisor, nice to have:

      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al)
      * A long standing issue is a fully synchronized p2m (locking
        lookups) (Andres Lagar-Cavilla)

tools, nice to have:

      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms. (discussion on-going)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard)
              * Upstream qemu save restore (Anthony Perard)
      * Nested-virtualisation (currently should be marked experimental,
        likely to release that way? Consider nested-svm separate to
        nested-vmx. Nested-svm is in better shape)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:00:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 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 1Rn5pq-0003Gg-AS; Tue, 17 Jan 2012 10:00: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 1Rn5po-0003Gb-Fl
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:00:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326794401!9466193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1483 invoked from network); 17 Jan 2012 10:00:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 10:00:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10077957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 10:00:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 10:00:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Tue, 17 Jan 2012 10:00:01 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, Keir Fraser <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Roger Pau Monne <roger.pau@entel.upc.edu>, Stefano
	Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: [Xen-devel] Xen 4.2 TODO List 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

An updated version of the list is below. Some items are marked "nice to
have" meaning that we don't think they should block the release. I'll
try and post an update on a semi-regular basis as and when things are
completed.

I think I have incorporated all the updates made in the last thread as
well as correctly reflected the status of each item. Please let me know
if something is out of date e.g. if progress has been made which I
haven't reflected below.

hypervisor, blockers:

      * round-up of the closing of the security hole in MSI-X
        passthrough (uniformly - i.e. even for Dom0 - disallowing write
        access to MSI-X table pages). (Jan Beulich, after upstream qemu
        patch series also incorporates the respective recent qemu-xen
        change)
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice (and schedule rate, if that ever makes it
        in). (George Dunlap)
      * get the interface changes for sharing/paging/mem-events done and
        dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
        Andres Lagar-Cavilla et al)
              * mem event ring management posted, seems close to going
                in.
              * sharing patches posted
              * 

tools, blockers:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (Ian Jackson, posted several rounds,
                nearing completion?)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate) (Ian Campbell, first RFC sent)
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                first RFC sent)
              * The topologyinfo datastructure should be a list of
                tuples, not a tuple of lists. (nobody currently looking
                at this, not 100% sure this makes sense, could possibly
                defer and change after 4.2 in a compatible way)
              * Block script support -- can be done post 4.2? should be
                nice to have not blocker? Somewhere on IanJ's todo?
      * xl to use json for machine readable output instead of sexp by
        default (Ian Campbell to revisit existing patch)
      * xl feature parity with xend wrt driver domain support (George
        Dunlap)
      * Integrate qemu+seabios upstream into the build (Stefano to
        repost). No change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

hypervisor, nice to have:

      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al)
      * A long standing issue is a fully synchronized p2m (locking
        lookups) (Andres Lagar-Cavilla)

tools, nice to have:

      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms. (discussion on-going)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard)
              * Upstream qemu save restore (Anthony Perard)
      * Nested-virtualisation (currently should be marked experimental,
        likely to release that way? Consider nested-svm separate to
        nested-vmx. Nested-svm is in better shape)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:00:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5qH-0003IE-OH; Tue, 17 Jan 2012 10:00:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rn5qF-0003Hz-KL
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:00:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326794426!8979928!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 16355 invoked from network); 17 Jan 2012 10:00:28 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 10:00:28 -0000
Received: by pbcc6 with SMTP id c6so28955607pbc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 02:00: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=GTxJqIvXWo7yBChszT8qDsq1YFWfZMJ7HhyDTmjJ5FQ=;
	b=rbObOQDfS8PDqklgOfms/971cuAXPReQ64EtJ6eXw9J/uiRncu6uut4YYJ31VIZ/B0
	DKWVummfmpzKqUwCKGW+iHF+kc7aFuSLAIEQJg095UCdGYnn0VX6Ej2WwpvoIXR1BZKU
	VcCod+3p3tMYWf99xzRem82CGDhEHMoFiPvFU=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr33392864pbu.124.1326794425499; Tue,
	17 Jan 2012 02:00:25 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 02:00:25 -0800 (PST)
In-Reply-To: <1326793927.14689.80.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Jan 2012 11:00:25 +0100
X-Google-Sender-Auth: N52XjwYfcS_kr4Foy7R0Fu_x3U4
Message-ID: <CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFR1
ZSwgMjAxMi0wMS0xNyBhdCAwOTo0MCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IEhv
d2V2ZXIgeGVuZCBzaG91bGQgbm90IGJlIHRyYW5zaXRpb24gdG8gdGhpcyBuZXcgc2NoZW1lIGJ1
dCBzaG91bGQKPj4gPiBjb250aW51ZSB0byB1c2UgaXRzIGV4aXN0aW5nIHNjcmlwdHMgaW4gdGhl
IGN1cnJlbnQgbWFubmVyLgo+PiA+Cj4+ID4gVGhlcmUgd2FzIGEgY29udmVyc2F0aW9uIGxhc3Qg
eWVhclswXSBhYm91dCBob3cgYSB0b29sc3RhY2sgY291bGQKPj4gPiBvcHQtaW4vb3V0IG9mIHRo
ZSB1c2Ugb2YgdGhlIGhvdHBsdWcgc2NyaXB0cy4gV2UgZGVjaWRlZCB0aGF0IHRvb2xzdGFja3MK
Pj4gPiBzaG91bGQgaGF2ZSB0byBvcHQgaW50byB0aGUgdXNlIG9mIHRoZXNlIHNjcmlwdHMsIGJ5
IHRvdWNoaW5nIGEgc3RhbXAKPj4gPiBmaWxlLgo+PiA+Cj4+ID4gQWx0aG91Z2ggdGhpcyB3YXNu
J3QgaW1wbGVtZW50ZWQgeWV0ICh1bmxlc3MgSSBtaXNzZWQgaXQpIEkgZ3Vlc3MgdGhlCj4+ID4g
c2FtZSBzY2hlbWUgd291bGQgYXBwbHkgdG8gdGhpcyB3b3JrIGlmIHRoYXQgc29ydCBvZiB0aGlu
ZyB0dXJucyBvdXQgdG8KPj4gPiBiZSBuZWNlc3NhcnkuCj4+Cj4+IFNvcnJ5IGZvciByZXBseWlu
ZyBzbyBtYW55IHRpbWVzLCB0aGlzIGlzIGEgYmlnIG1heWJlLCBhbmQgcG9zc2libHkKPj4gaXQn
cyB0b28gZHJhc3RpYywgYnV0IGFmdGVyIHRoaXMgY2hhbmdlcyB4bCBhbmQgeGVuZCB3aWxsIG5v
dCBiZQo+PiBjb21wYXRpYmxlIGFueW1vcmUsIHNvIHdoeSBkb24ndCB3ZSBkaXNhYmxlIHhlbmQg
YnkgZGVmYXVsdCwgYW5kIG9ubHkKPj4gYnVpbGQgeGw/Cj4KPiBJIGRvbid0IHRoaW5rIHRoZXkg
YXJlIGNvbXBhdGlibGUgbm93LCBhcmUgdGhleT8gSSd2ZSBjZXJ0YWlubHkgc2VlbiBvZGQKPiBi
ZWhhdmlvdXIgd2hlbiB1c2luZyB4bCB3aXRoIHhlbmQgKGFjY2lkZW50YWxseSkgcnVubmluZywg
dXN1YWxseSB4ZW5kCj4gcmVhcHMgdGhlIGRvbWFpbiBJJ3ZlIGp1c3Qgc3RhcnRlZC4uLgo+Cj4g
SSdtIGFsbCBmb3IgZGlzYWJsaW5nIHRoZSBidWlsZCBvZiB4ZW5kIGJ5IGRlZmF1bHQgYnV0IEkg
aGFkIGFzc3VtZWQKPiB0aGF0IG90aGVycyB3b3VsZCB0aGluayA0LjIgd2FzIHJhdGhlciBhbiBh
Z2dyZXNzaXZlIHRpbWVsaW5lIGZvciB0aGF0Lgo+Cj4+IFdoZW4gdGhlIG5ldyBjb25maWd1cmUg
c2NyaXB0IGlzIGluLCBpdCB3aWxsIGJlIHRyaXZpYWwgdG8gc2VsZWN0IGlmCj4+IHlvdSB3YW50
IHhsIG9yIHhlbmQsIGFuZCBvbmx5IGluc3RhbGwgb25lIG9mIHRob3NlLiBBZGRpbmcgdGhlIG9w
dGlvbgo+PiAtLWVuYWJsZS14ZW5kIHNob3VsZCBkaXNhYmxlIHhsIGFuZCBvbmx5IGJ1aWxkIGFu
ZCBpbnN0YWxsIHhlbmQKPj4gKHByaW50aW5nIGEgdmVyeSBiaWcgd2FybmluZyB0aGF0IHhlbmQg
aXMgZGVwcmVjYXRlZCkuCj4KPiBJIGRvbid0IHRoaW5rIC0tZW5hYmxlLXhlbmQgc2hvdWxkIGV2
ZXIgZGlzYWJsZSB4bCAob3IgdmljZSB2ZXJzYSkuIE1hbnkKPiBmb2xrcyAoZS5nLiBkaXN0cm9z
KSB3aWxsIHdhbnQgdG8gYnVpbGQgYm90aCwgcGVyaGFwcyB0byBwYWNrYWdlIHRoZW0gaW4KPiB0
d28gZGlmZmVyZW50IGJpbmFyeSBwYWNrYWdlcywgYnV0IGNlcnRhaW5seSB0byBvZmZlciB0aGVp
ciB1c2VycyB0aGUKPiBjaG9pY2UsIGF0IGxlYXN0IGZvciB0aGUgdGltZSBiZWluZy4KCk15IG1h
aW4gY29uY2VybiB3aXRoIHRoaXMgaXMgdGhhdCB4ZW5kIGFuZCB4bCB3aWxsIHN0YXJ0IHRvIHVz
ZQpkaWZmZXJlbnQgdWRldiBydWxlcyAod2VsbCwgeGVuZCB3aWxsIGNvbnRpbnVlIHRvIHVzZSB0
aGUgZXhpc3RpbmcKb25lcywgd2hpbGUgeGwgd2lsbCBvbmx5IHVzZSBhIHN1YnNldCBvZiB0aG9z
ZSkuIFNvIHdlIGhhdmUgdG8gZGVjaWRlCndoaWNoIHVkZXYgcnVsZXMgZmlsZSB0byBpbnN0YWxs
LCBiZWNhdXNlIHdlIGNhbid0IGhhdmUgYm90aCBpbnN0YWxsZWQKYXQgdGhlIHNhbWUgdGltZS4K
CkFub3RoZXIgb3B0aW9uIGlzIHRvIGluc3RhbGwgeGwgdWRldiBydWxlcyBieSBkZWZhdWx0LCBh
bmQgbWFrZSB4ZW5kCm1vdmUgaXQncyBvd24gcnVsZXMgaW4gdGhlIGluaXQgc2NyaXB0LiBTaW5j
ZSB4bCBkb2Vzbid0IHVzZSBhIGRhZW1vbiwKeGwgc2hvdWxkIGFsd2F5cyBjaGVjayBpZiB4ZW5k
IGlzIHJ1bm5pbmcgYmVmb3JlIGRvaW5nIGFueXRoaW5nIGFuZApmYWlsIGlmIHhlbmQgaXMgZm91
bmQuCgo+Pgo+PiA+IElhbi4KPj4gPgo+PiA+IFswXSBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNo
aXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTA2L21zZzAwOTUyLmh0bWwKPj4gPgo+Cj4KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNv
dXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:00:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:00:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5qH-0003IE-OH; Tue, 17 Jan 2012 10:00:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rn5qF-0003Hz-KL
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:00:35 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326794426!8979928!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 16355 invoked from network); 17 Jan 2012 10:00:28 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 10:00:28 -0000
Received: by pbcc6 with SMTP id c6so28955607pbc.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 02:00: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=GTxJqIvXWo7yBChszT8qDsq1YFWfZMJ7HhyDTmjJ5FQ=;
	b=rbObOQDfS8PDqklgOfms/971cuAXPReQ64EtJ6eXw9J/uiRncu6uut4YYJ31VIZ/B0
	DKWVummfmpzKqUwCKGW+iHF+kc7aFuSLAIEQJg095UCdGYnn0VX6Ej2WwpvoIXR1BZKU
	VcCod+3p3tMYWf99xzRem82CGDhEHMoFiPvFU=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr33392864pbu.124.1326794425499; Tue,
	17 Jan 2012 02:00:25 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 02:00:25 -0800 (PST)
In-Reply-To: <1326793927.14689.80.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Jan 2012 11:00:25 +0100
X-Google-Sender-Auth: N52XjwYfcS_kr4Foy7R0Fu_x3U4
Message-ID: <CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFR1
ZSwgMjAxMi0wMS0xNyBhdCAwOTo0MCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IEhv
d2V2ZXIgeGVuZCBzaG91bGQgbm90IGJlIHRyYW5zaXRpb24gdG8gdGhpcyBuZXcgc2NoZW1lIGJ1
dCBzaG91bGQKPj4gPiBjb250aW51ZSB0byB1c2UgaXRzIGV4aXN0aW5nIHNjcmlwdHMgaW4gdGhl
IGN1cnJlbnQgbWFubmVyLgo+PiA+Cj4+ID4gVGhlcmUgd2FzIGEgY29udmVyc2F0aW9uIGxhc3Qg
eWVhclswXSBhYm91dCBob3cgYSB0b29sc3RhY2sgY291bGQKPj4gPiBvcHQtaW4vb3V0IG9mIHRo
ZSB1c2Ugb2YgdGhlIGhvdHBsdWcgc2NyaXB0cy4gV2UgZGVjaWRlZCB0aGF0IHRvb2xzdGFja3MK
Pj4gPiBzaG91bGQgaGF2ZSB0byBvcHQgaW50byB0aGUgdXNlIG9mIHRoZXNlIHNjcmlwdHMsIGJ5
IHRvdWNoaW5nIGEgc3RhbXAKPj4gPiBmaWxlLgo+PiA+Cj4+ID4gQWx0aG91Z2ggdGhpcyB3YXNu
J3QgaW1wbGVtZW50ZWQgeWV0ICh1bmxlc3MgSSBtaXNzZWQgaXQpIEkgZ3Vlc3MgdGhlCj4+ID4g
c2FtZSBzY2hlbWUgd291bGQgYXBwbHkgdG8gdGhpcyB3b3JrIGlmIHRoYXQgc29ydCBvZiB0aGlu
ZyB0dXJucyBvdXQgdG8KPj4gPiBiZSBuZWNlc3NhcnkuCj4+Cj4+IFNvcnJ5IGZvciByZXBseWlu
ZyBzbyBtYW55IHRpbWVzLCB0aGlzIGlzIGEgYmlnIG1heWJlLCBhbmQgcG9zc2libHkKPj4gaXQn
cyB0b28gZHJhc3RpYywgYnV0IGFmdGVyIHRoaXMgY2hhbmdlcyB4bCBhbmQgeGVuZCB3aWxsIG5v
dCBiZQo+PiBjb21wYXRpYmxlIGFueW1vcmUsIHNvIHdoeSBkb24ndCB3ZSBkaXNhYmxlIHhlbmQg
YnkgZGVmYXVsdCwgYW5kIG9ubHkKPj4gYnVpbGQgeGw/Cj4KPiBJIGRvbid0IHRoaW5rIHRoZXkg
YXJlIGNvbXBhdGlibGUgbm93LCBhcmUgdGhleT8gSSd2ZSBjZXJ0YWlubHkgc2VlbiBvZGQKPiBi
ZWhhdmlvdXIgd2hlbiB1c2luZyB4bCB3aXRoIHhlbmQgKGFjY2lkZW50YWxseSkgcnVubmluZywg
dXN1YWxseSB4ZW5kCj4gcmVhcHMgdGhlIGRvbWFpbiBJJ3ZlIGp1c3Qgc3RhcnRlZC4uLgo+Cj4g
SSdtIGFsbCBmb3IgZGlzYWJsaW5nIHRoZSBidWlsZCBvZiB4ZW5kIGJ5IGRlZmF1bHQgYnV0IEkg
aGFkIGFzc3VtZWQKPiB0aGF0IG90aGVycyB3b3VsZCB0aGluayA0LjIgd2FzIHJhdGhlciBhbiBh
Z2dyZXNzaXZlIHRpbWVsaW5lIGZvciB0aGF0Lgo+Cj4+IFdoZW4gdGhlIG5ldyBjb25maWd1cmUg
c2NyaXB0IGlzIGluLCBpdCB3aWxsIGJlIHRyaXZpYWwgdG8gc2VsZWN0IGlmCj4+IHlvdSB3YW50
IHhsIG9yIHhlbmQsIGFuZCBvbmx5IGluc3RhbGwgb25lIG9mIHRob3NlLiBBZGRpbmcgdGhlIG9w
dGlvbgo+PiAtLWVuYWJsZS14ZW5kIHNob3VsZCBkaXNhYmxlIHhsIGFuZCBvbmx5IGJ1aWxkIGFu
ZCBpbnN0YWxsIHhlbmQKPj4gKHByaW50aW5nIGEgdmVyeSBiaWcgd2FybmluZyB0aGF0IHhlbmQg
aXMgZGVwcmVjYXRlZCkuCj4KPiBJIGRvbid0IHRoaW5rIC0tZW5hYmxlLXhlbmQgc2hvdWxkIGV2
ZXIgZGlzYWJsZSB4bCAob3IgdmljZSB2ZXJzYSkuIE1hbnkKPiBmb2xrcyAoZS5nLiBkaXN0cm9z
KSB3aWxsIHdhbnQgdG8gYnVpbGQgYm90aCwgcGVyaGFwcyB0byBwYWNrYWdlIHRoZW0gaW4KPiB0
d28gZGlmZmVyZW50IGJpbmFyeSBwYWNrYWdlcywgYnV0IGNlcnRhaW5seSB0byBvZmZlciB0aGVp
ciB1c2VycyB0aGUKPiBjaG9pY2UsIGF0IGxlYXN0IGZvciB0aGUgdGltZSBiZWluZy4KCk15IG1h
aW4gY29uY2VybiB3aXRoIHRoaXMgaXMgdGhhdCB4ZW5kIGFuZCB4bCB3aWxsIHN0YXJ0IHRvIHVz
ZQpkaWZmZXJlbnQgdWRldiBydWxlcyAod2VsbCwgeGVuZCB3aWxsIGNvbnRpbnVlIHRvIHVzZSB0
aGUgZXhpc3RpbmcKb25lcywgd2hpbGUgeGwgd2lsbCBvbmx5IHVzZSBhIHN1YnNldCBvZiB0aG9z
ZSkuIFNvIHdlIGhhdmUgdG8gZGVjaWRlCndoaWNoIHVkZXYgcnVsZXMgZmlsZSB0byBpbnN0YWxs
LCBiZWNhdXNlIHdlIGNhbid0IGhhdmUgYm90aCBpbnN0YWxsZWQKYXQgdGhlIHNhbWUgdGltZS4K
CkFub3RoZXIgb3B0aW9uIGlzIHRvIGluc3RhbGwgeGwgdWRldiBydWxlcyBieSBkZWZhdWx0LCBh
bmQgbWFrZSB4ZW5kCm1vdmUgaXQncyBvd24gcnVsZXMgaW4gdGhlIGluaXQgc2NyaXB0LiBTaW5j
ZSB4bCBkb2Vzbid0IHVzZSBhIGRhZW1vbiwKeGwgc2hvdWxkIGFsd2F5cyBjaGVjayBpZiB4ZW5k
IGlzIHJ1bm5pbmcgYmVmb3JlIGRvaW5nIGFueXRoaW5nIGFuZApmYWlsIGlmIHhlbmQgaXMgZm91
bmQuCgo+Pgo+PiA+IElhbi4KPj4gPgo+PiA+IFswXSBodHRwOi8vbGlzdHMueGVuLm9yZy9hcmNo
aXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTA2L21zZzAwOTUyLmh0bWwKPj4gPgo+Cj4KCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWls
aW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNv
dXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:05:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10: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 1Rn5uW-0003Wg-Tr; Tue, 17 Jan 2012 10:05:00 +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 1Rn5uV-0003Vy-GH
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:04:59 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326794692!11213842!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8548 invoked from network); 17 Jan 2012 10:04:52 -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;
	17 Jan 2012 10:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10078112"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 10:04:51 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 17 Jan 2012
	10:04:51 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 10:04:51 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUW3WsO0m3e1wtTi+9q9RN5lp4LgAopq0Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BECAD@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
	<20244.5493.159092.178261@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC67@LONPMAILBOX01.citrite.net>
	<20244.13470.956567.815603@mariner.uk.xensource.com>
In-Reply-To: <20244.13470.956567.815603@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

So far I've been unable to repro. with a build of staging tip from yesterday (running a 512MB PV debian guest with a 3.2.0-rc2+ kernel). I'll revert to the appropriate c/s and see if I can repro. with that. The errors unfortunately don't give much away other than the receiving process clearly didn't like something about the migration data stream.

libxl: error: libxl_utils.c:409:libxl_read_exactly: file/stream truncated reading ready message from migration receiver stream
libxl: info: libxl_exec.c:124:libxl_report_child_exitstatus: migration target process [14446] exited with error status 255

  Paul

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 16 January 2012 14:31
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xensource.com; Keir (Xen.org); Stefano
> Stabellini
> Subject: RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete
> test-i386-i386-xl"):
> > > -----Original Message-----
> > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> ...
> > > So as you were the author of the original patch, can you please try
> > > to reproduce the problem and fix it ?
> > >
> >
> > Already on it.
> 
> Great, thanks.  If you need any help, or to borrow the machine from my test
> pool, or something, just let me know.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:05:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10: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 1Rn5uW-0003Wg-Tr; Tue, 17 Jan 2012 10:05:00 +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 1Rn5uV-0003Vy-GH
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:04:59 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326794692!11213842!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8548 invoked from network); 17 Jan 2012 10:04:52 -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;
	17 Jan 2012 10:04:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10078112"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 10:04:51 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Tue, 17 Jan 2012
	10:04:51 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 10:04:51 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUW3WsO0m3e1wtTi+9q9RN5lp4LgAopq0Q
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BECAD@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
	<20244.5493.159092.178261@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC67@LONPMAILBOX01.citrite.net>
	<20244.13470.956567.815603@mariner.uk.xensource.com>
In-Reply-To: <20244.13470.956567.815603@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

So far I've been unable to repro. with a build of staging tip from yesterday (running a 512MB PV debian guest with a 3.2.0-rc2+ kernel). I'll revert to the appropriate c/s and see if I can repro. with that. The errors unfortunately don't give much away other than the receiving process clearly didn't like something about the migration data stream.

libxl: error: libxl_utils.c:409:libxl_read_exactly: file/stream truncated reading ready message from migration receiver stream
libxl: info: libxl_exec.c:124:libxl_report_child_exitstatus: migration target process [14446] exited with error status 255

  Paul

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 16 January 2012 14:31
> To: Paul Durrant
> Cc: Ian Campbell; xen-devel@lists.xensource.com; Keir (Xen.org); Stefano
> Stabellini
> Subject: RE: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> Paul Durrant writes ("RE: [Xen-devel] [xen-unstable bisection] complete
> test-i386-i386-xl"):
> > > -----Original Message-----
> > > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> ...
> > > So as you were the author of the original patch, can you please try
> > > to reproduce the problem and fix it ?
> > >
> >
> > Already on it.
> 
> Great, thanks.  If you need any help, or to borrow the machine from my test
> pool, or something, just let me know.
> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:05:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10: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 1Rn5uT-0003WC-F1; Tue, 17 Jan 2012 10:04: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 1Rn5uS-0003Vn-CL
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:04:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326794687!8831820!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 15401 invoked from network); 17 Jan 2012 10:04:49 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 10:04:49 -0000
Received: by dadp15 with SMTP id p15so22549143dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 02:04: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=+Q92GAONRkh7JObefcgsmxmZW7k7QkMsA4UWg3lpiEI=;
	b=bdmkxs3454YdZG6HNn1Yh+qbtntHBnwglbdpc3+cbP8Nn6C33JQn/9hdGJCJpkhuVr
	laO2iLTDpvUZ9+xY0OR5LH+0EUsnVdNFFmN1Pok8juCDOjkEcdTXjl3e93XIAM2tY7Ra
	ZSwu9VeAsB6AKEHqOTPZz4KE/X+d4snYY+IBo=
MIME-Version: 1.0
Received: by 10.68.213.33 with SMTP id np1mr33416783pbc.107.1326794686888;
	Tue, 17 Jan 2012 02:04:46 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 02:04:46 -0800 (PST)
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
References: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Jan 2012 11:04:46 +0100
X-Google-Sender-Auth: DAuQPYJLU1-Q1n_oGEWlUnE_MaI
Message-ID: <CAPLaKK6QEKiXOe9c3TgWK8KpLvTehQ1f5mjOheg6UYYiOO0v0A@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 <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IEFuIHVw
ZGF0ZWQgdmVyc2lvbiBvZiB0aGUgbGlzdCBpcyBiZWxvdy4gU29tZSBpdGVtcyBhcmUgbWFya2Vk
ICJuaWNlIHRvCj4gaGF2ZSIgbWVhbmluZyB0aGF0IHdlIGRvbid0IHRoaW5rIHRoZXkgc2hvdWxk
IGJsb2NrIHRoZSByZWxlYXNlLiBJJ2xsCj4gdHJ5IGFuZCBwb3N0IGFuIHVwZGF0ZSBvbiBhIHNl
bWktcmVndWxhciBiYXNpcyBhcyBhbmQgd2hlbiB0aGluZ3MgYXJlCj4gY29tcGxldGVkLgo+Cj4g
SSB0aGluayBJIGhhdmUgaW5jb3Jwb3JhdGVkIGFsbCB0aGUgdXBkYXRlcyBtYWRlIGluIHRoZSBs
YXN0IHRocmVhZCBhcwo+IHdlbGwgYXMgY29ycmVjdGx5IHJlZmxlY3RlZCB0aGUgc3RhdHVzIG9m
IGVhY2ggaXRlbS4gUGxlYXNlIGxldCBtZSBrbm93Cj4gaWYgc29tZXRoaW5nIGlzIG91dCBvZiBk
YXRlIGUuZy4gaWYgcHJvZ3Jlc3MgaGFzIGJlZW4gbWFkZSB3aGljaCBJCj4gaGF2ZW4ndCByZWZs
ZWN0ZWQgYmVsb3cuCj4KPiBoeXBlcnZpc29yLCBibG9ja2VyczoKPgo+IMKgIMKgIMKgKiByb3Vu
ZC11cCBvZiB0aGUgY2xvc2luZyBvZiB0aGUgc2VjdXJpdHkgaG9sZSBpbiBNU0ktWAo+IMKgIMKg
IMKgIMKgcGFzc3Rocm91Z2ggKHVuaWZvcm1seSAtIGkuZS4gZXZlbiBmb3IgRG9tMCAtIGRpc2Fs
bG93aW5nIHdyaXRlCj4gwqAgwqAgwqAgwqBhY2Nlc3MgdG8gTVNJLVggdGFibGUgcGFnZXMpLiAo
SmFuIEJldWxpY2gsIGFmdGVyIHVwc3RyZWFtIHFlbXUKPiDCoCDCoCDCoCDCoHBhdGNoIHNlcmll
cyBhbHNvIGluY29ycG9yYXRlcyB0aGUgcmVzcGVjdGl2ZSByZWNlbnQgcWVtdS14ZW4KPiDCoCDC
oCDCoCDCoGNoYW5nZSkKPiDCoCDCoCDCoCogZG9tY3RscyAvIHN5c2N0bHMgc2V0IHVwIHRvIG1v
ZGlmeSBzY2hlZHVsZXIgcGFyYW1ldGVycywgbGlrZQo+IMKgIMKgIMKgIMKgdGhlIGNyZWRpdDEg
dGltZXNsaWNlIChhbmQgc2NoZWR1bGUgcmF0ZSwgaWYgdGhhdCBldmVyIG1ha2VzIGl0Cj4gwqAg
wqAgwqAgwqBpbikuIChHZW9yZ2UgRHVubGFwKQo+IMKgIMKgIMKgKiBnZXQgdGhlIGludGVyZmFj
ZSBjaGFuZ2VzIGZvciBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCj4gwqAgwqAg
wqAgwqBkdXN0ZWQgc28gdGhhdCA0LjIgaXMgYSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4g
KFRpbSBEZWVnYW4sCj4gwqAgwqAgwqAgwqBBbmRyZXMgTGFnYXItQ2F2aWxsYSBldCBhbCkKPiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNl
ZW1zIGNsb3NlIHRvIGdvaW5nCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbi4KPiDCoCDCoCDC
oCDCoCDCoCDCoCDCoCogc2hhcmluZyBwYXRjaGVzIHBvc3RlZAo+IMKgIMKgIMKgIMKgIMKgIMKg
IMKgKgo+Cj4gdG9vbHMsIGJsb2NrZXJzOgo+Cj4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkg
LS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+IMKgIMKgIMKgIMKg
d2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNw
ZWN0cyBvZgo+IMKgIMKgIMKgIMKgdGhpcyBhcmU6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGV2
ZW50IGhhbmRsaW5nIChJYW4gSmFja3NvbiwgcG9zdGVkIHNldmVyYWwgcm91bmRzLAo+IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgbmVhcmluZyBjb21wbGV0aW9uPykKPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCogZHJvcCBsaWJ4bF9kZXZpY2VfbW9kZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2lu
Zm8gb3IKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkg
KElhbiBDYW1wYmVsbCwgZmlyc3QgUkZDIHNlbnQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGFk
ZCBsaWJ4bF9kZWZib29sIGFuZCBnZW5lcmFsbHkgdHJ5IGFuZCBhcnJhbmdlIHRoYXQKPiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoG1lbXNldChmb28sMCwuLi4pIHJlcXVlc3RzIHRoZSBkZWZhdWx0
cyAoSWFuIENhbXBiZWxsLAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmlyc3QgUkZDIHNlbnQp
Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIFRoZSB0b3BvbG9neWluZm8gZGF0YXN0cnVjdHVyZSBz
aG91bGQgYmUgYSBsaXN0IG9mCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0dXBsZXMsIG5vdCBh
IHR1cGxlIG9mIGxpc3RzLiAobm9ib2R5IGN1cnJlbnRseSBsb29raW5nCj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqBhdCB0aGlzLCBub3QgMTAwJSBzdXJlIHRoaXMgbWFrZXMgc2Vuc2UsIGNvdWxk
IHBvc3NpYmx5Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZWZlciBhbmQgY2hhbmdlIGFmdGVy
IDQuMiBpbiBhIGNvbXBhdGlibGUgd2F5KQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBCbG9jayBz
Y3JpcHQgc3VwcG9ydCAtLSBjYW4gYmUgZG9uZSBwb3N0IDQuMj8gc2hvdWxkIGJlCj4gwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqBuaWNlIHRvIGhhdmUgbm90IGJsb2NrZXI/IFNvbWV3aGVyZSBvbiBJ
YW5KJ3MgdG9kbz8KClRoaXMgaXMgcXVpdGUgcmVsYXRlZCB0byB4bCBob3RwbHVnIHN0dWZmLCBv
bmNlIHRoZSBob3RwbHVnIHRoaW5nIGlzCmluLCBpdCBzaG91bGQgYmUgdHJpdmlhbCB0byBhZGQg
dGhpcy4KCj4gwqAgwqAgwqAqIHhsIHRvIHVzZSBqc29uIGZvciBtYWNoaW5lIHJlYWRhYmxlIG91
dHB1dCBpbnN0ZWFkIG9mIHNleHAgYnkKPiDCoCDCoCDCoCDCoGRlZmF1bHQgKElhbiBDYW1wYmVs
bCB0byByZXZpc2l0IGV4aXN0aW5nIHBhdGNoKQo+IMKgIMKgIMKgKiB4bCBmZWF0dXJlIHBhcml0
eSB3aXRoIHhlbmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9ydCAoR2VvcmdlCj4gwqAgwqAgwqAg
wqBEdW5sYXApCj4gwqAgwqAgwqAqIEludGVncmF0ZSBxZW11K3NlYWJpb3MgdXBzdHJlYW0gaW50
byB0aGUgYnVpbGQgKFN0ZWZhbm8gdG8KPiDCoCDCoCDCoCDCoHJlcG9zdCkuIE5vIGNoYW5nZSBp
biBkZWZhdWx0IHFlbXUgZm9yIDQuMi4KPiDCoCDCoCDCoCogTW9yZSBmb3JtYWxseSBkZXByZWNh
dGUgeG0veGVuZC4gTWFucGFnZSBwYXRjaGVzIGFscmVhZHkgaW4KPiDCoCDCoCDCoCDCoHRyZWUu
IE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMxIHRvCj4g
wqAgwqAgwqAgwqByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwuCj4KPiBoeXBlcnZpc29yLCBuaWNl
IHRvIGhhdmU6Cj4KPiDCoCDCoCDCoCogc29saWQgaW1wbGVtZW50YXRpb24gb2Ygc2hhcmluZy9w
YWdpbmcvbWVtLWV2ZW50cyAodXNpbmcgd29yawo+IMKgIMKgIMKgIMKgcXVldWVzKSAoVGltIERl
ZWdhbiwgT2xhZiBIZXJyaW5nIGV0IGFsKQo+IMKgIMKgIMKgKiBBIGxvbmcgc3RhbmRpbmcgaXNz
dWUgaXMgYSBmdWxseSBzeW5jaHJvbml6ZWQgcDJtIChsb2NraW5nCj4gwqAgwqAgwqAgwqBsb29r
dXBzKSAoQW5kcmVzIExhZ2FyLUNhdmlsbGEpCj4KPiB0b29scywgbmljZSB0byBoYXZlOgo+Cj4g
wqAgwqAgwqAqIEhvdHBsdWcgc2NyaXB0IHN0dWZmIC0tIGludGVybmFsIHRvIGxpYnhsIChJIHRo
aW5rLCB0aGVyZWZvcmUgSQo+IMKgIMKgIMKgIMKgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0YWJs
ZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhhdmUKPiDCoCDCoCDCoCDCoGZvciA0LjI/
IFJvZ2VyIFBhdSBNb25ldCB3YXMgbG9va2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9va2luZwo+IMKg
IMKgIMKgIMKgbGlrZSBhIGJpZyBjYW4tby13b3Jtcy4gKGRpc2N1c3Npb24gb24tZ29pbmcpCj4g
wqAgwqAgwqAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgo+IMKgIMKgIMKgIMKgIMKg
IMKgIMKgKiBVcHN0cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRob255IFBl
cmFyZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBzYXZlIHJlc3RvcmUg
KEFudGhvbnkgUGVyYXJkKQo+IMKgIMKgIMKgKiBOZXN0ZWQtdmlydHVhbGlzYXRpb24gKGN1cnJl
bnRseSBzaG91bGQgYmUgbWFya2VkIGV4cGVyaW1lbnRhbCwKPiDCoCDCoCDCoCDCoGxpa2VseSB0
byByZWxlYXNlIHRoYXQgd2F5PyBDb25zaWRlciBuZXN0ZWQtc3ZtIHNlcGFyYXRlIHRvCj4gwqAg
wqAgwqAgwqBuZXN0ZWQtdm14LiBOZXN0ZWQtc3ZtIGlzIGluIGJldHRlciBzaGFwZSkKPgo+Cj4K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:05:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10: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 1Rn5uT-0003WC-F1; Tue, 17 Jan 2012 10:04: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 1Rn5uS-0003Vn-CL
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:04:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326794687!8831820!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 15401 invoked from network); 17 Jan 2012 10:04:49 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 10:04:49 -0000
Received: by dadp15 with SMTP id p15so22549143dad.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 02:04: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=+Q92GAONRkh7JObefcgsmxmZW7k7QkMsA4UWg3lpiEI=;
	b=bdmkxs3454YdZG6HNn1Yh+qbtntHBnwglbdpc3+cbP8Nn6C33JQn/9hdGJCJpkhuVr
	laO2iLTDpvUZ9+xY0OR5LH+0EUsnVdNFFmN1Pok8juCDOjkEcdTXjl3e93XIAM2tY7Ra
	ZSwu9VeAsB6AKEHqOTPZz4KE/X+d4snYY+IBo=
MIME-Version: 1.0
Received: by 10.68.213.33 with SMTP id np1mr33416783pbc.107.1326794686888;
	Tue, 17 Jan 2012 02:04:46 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Tue, 17 Jan 2012 02:04:46 -0800 (PST)
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
References: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
Date: Tue, 17 Jan 2012 11:04:46 +0100
X-Google-Sender-Auth: DAuQPYJLU1-Q1n_oGEWlUnE_MaI
Message-ID: <CAPLaKK6QEKiXOe9c3TgWK8KpLvTehQ1f5mjOheg6UYYiOO0v0A@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 <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IEFuIHVw
ZGF0ZWQgdmVyc2lvbiBvZiB0aGUgbGlzdCBpcyBiZWxvdy4gU29tZSBpdGVtcyBhcmUgbWFya2Vk
ICJuaWNlIHRvCj4gaGF2ZSIgbWVhbmluZyB0aGF0IHdlIGRvbid0IHRoaW5rIHRoZXkgc2hvdWxk
IGJsb2NrIHRoZSByZWxlYXNlLiBJJ2xsCj4gdHJ5IGFuZCBwb3N0IGFuIHVwZGF0ZSBvbiBhIHNl
bWktcmVndWxhciBiYXNpcyBhcyBhbmQgd2hlbiB0aGluZ3MgYXJlCj4gY29tcGxldGVkLgo+Cj4g
SSB0aGluayBJIGhhdmUgaW5jb3Jwb3JhdGVkIGFsbCB0aGUgdXBkYXRlcyBtYWRlIGluIHRoZSBs
YXN0IHRocmVhZCBhcwo+IHdlbGwgYXMgY29ycmVjdGx5IHJlZmxlY3RlZCB0aGUgc3RhdHVzIG9m
IGVhY2ggaXRlbS4gUGxlYXNlIGxldCBtZSBrbm93Cj4gaWYgc29tZXRoaW5nIGlzIG91dCBvZiBk
YXRlIGUuZy4gaWYgcHJvZ3Jlc3MgaGFzIGJlZW4gbWFkZSB3aGljaCBJCj4gaGF2ZW4ndCByZWZs
ZWN0ZWQgYmVsb3cuCj4KPiBoeXBlcnZpc29yLCBibG9ja2VyczoKPgo+IMKgIMKgIMKgKiByb3Vu
ZC11cCBvZiB0aGUgY2xvc2luZyBvZiB0aGUgc2VjdXJpdHkgaG9sZSBpbiBNU0ktWAo+IMKgIMKg
IMKgIMKgcGFzc3Rocm91Z2ggKHVuaWZvcm1seSAtIGkuZS4gZXZlbiBmb3IgRG9tMCAtIGRpc2Fs
bG93aW5nIHdyaXRlCj4gwqAgwqAgwqAgwqBhY2Nlc3MgdG8gTVNJLVggdGFibGUgcGFnZXMpLiAo
SmFuIEJldWxpY2gsIGFmdGVyIHVwc3RyZWFtIHFlbXUKPiDCoCDCoCDCoCDCoHBhdGNoIHNlcmll
cyBhbHNvIGluY29ycG9yYXRlcyB0aGUgcmVzcGVjdGl2ZSByZWNlbnQgcWVtdS14ZW4KPiDCoCDC
oCDCoCDCoGNoYW5nZSkKPiDCoCDCoCDCoCogZG9tY3RscyAvIHN5c2N0bHMgc2V0IHVwIHRvIG1v
ZGlmeSBzY2hlZHVsZXIgcGFyYW1ldGVycywgbGlrZQo+IMKgIMKgIMKgIMKgdGhlIGNyZWRpdDEg
dGltZXNsaWNlIChhbmQgc2NoZWR1bGUgcmF0ZSwgaWYgdGhhdCBldmVyIG1ha2VzIGl0Cj4gwqAg
wqAgwqAgwqBpbikuIChHZW9yZ2UgRHVubGFwKQo+IMKgIMKgIMKgKiBnZXQgdGhlIGludGVyZmFj
ZSBjaGFuZ2VzIGZvciBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCj4gwqAgwqAg
wqAgwqBkdXN0ZWQgc28gdGhhdCA0LjIgaXMgYSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4g
KFRpbSBEZWVnYW4sCj4gwqAgwqAgwqAgwqBBbmRyZXMgTGFnYXItQ2F2aWxsYSBldCBhbCkKPiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNl
ZW1zIGNsb3NlIHRvIGdvaW5nCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbi4KPiDCoCDCoCDC
oCDCoCDCoCDCoCDCoCogc2hhcmluZyBwYXRjaGVzIHBvc3RlZAo+IMKgIMKgIMKgIMKgIMKgIMKg
IMKgKgo+Cj4gdG9vbHMsIGJsb2NrZXJzOgo+Cj4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkg
LS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+IMKgIMKgIMKgIMKg
d2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNw
ZWN0cyBvZgo+IMKgIMKgIMKgIMKgdGhpcyBhcmU6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGV2
ZW50IGhhbmRsaW5nIChJYW4gSmFja3NvbiwgcG9zdGVkIHNldmVyYWwgcm91bmRzLAo+IMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgbmVhcmluZyBjb21wbGV0aW9uPykKPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCogZHJvcCBsaWJ4bF9kZXZpY2VfbW9kZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2lu
Zm8gb3IKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkg
KElhbiBDYW1wYmVsbCwgZmlyc3QgUkZDIHNlbnQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGFk
ZCBsaWJ4bF9kZWZib29sIGFuZCBnZW5lcmFsbHkgdHJ5IGFuZCBhcnJhbmdlIHRoYXQKPiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoG1lbXNldChmb28sMCwuLi4pIHJlcXVlc3RzIHRoZSBkZWZhdWx0
cyAoSWFuIENhbXBiZWxsLAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmlyc3QgUkZDIHNlbnQp
Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIFRoZSB0b3BvbG9neWluZm8gZGF0YXN0cnVjdHVyZSBz
aG91bGQgYmUgYSBsaXN0IG9mCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB0dXBsZXMsIG5vdCBh
IHR1cGxlIG9mIGxpc3RzLiAobm9ib2R5IGN1cnJlbnRseSBsb29raW5nCj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqBhdCB0aGlzLCBub3QgMTAwJSBzdXJlIHRoaXMgbWFrZXMgc2Vuc2UsIGNvdWxk
IHBvc3NpYmx5Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBkZWZlciBhbmQgY2hhbmdlIGFmdGVy
IDQuMiBpbiBhIGNvbXBhdGlibGUgd2F5KQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBCbG9jayBz
Y3JpcHQgc3VwcG9ydCAtLSBjYW4gYmUgZG9uZSBwb3N0IDQuMj8gc2hvdWxkIGJlCj4gwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqBuaWNlIHRvIGhhdmUgbm90IGJsb2NrZXI/IFNvbWV3aGVyZSBvbiBJ
YW5KJ3MgdG9kbz8KClRoaXMgaXMgcXVpdGUgcmVsYXRlZCB0byB4bCBob3RwbHVnIHN0dWZmLCBv
bmNlIHRoZSBob3RwbHVnIHRoaW5nIGlzCmluLCBpdCBzaG91bGQgYmUgdHJpdmlhbCB0byBhZGQg
dGhpcy4KCj4gwqAgwqAgwqAqIHhsIHRvIHVzZSBqc29uIGZvciBtYWNoaW5lIHJlYWRhYmxlIG91
dHB1dCBpbnN0ZWFkIG9mIHNleHAgYnkKPiDCoCDCoCDCoCDCoGRlZmF1bHQgKElhbiBDYW1wYmVs
bCB0byByZXZpc2l0IGV4aXN0aW5nIHBhdGNoKQo+IMKgIMKgIMKgKiB4bCBmZWF0dXJlIHBhcml0
eSB3aXRoIHhlbmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9ydCAoR2VvcmdlCj4gwqAgwqAgwqAg
wqBEdW5sYXApCj4gwqAgwqAgwqAqIEludGVncmF0ZSBxZW11K3NlYWJpb3MgdXBzdHJlYW0gaW50
byB0aGUgYnVpbGQgKFN0ZWZhbm8gdG8KPiDCoCDCoCDCoCDCoHJlcG9zdCkuIE5vIGNoYW5nZSBp
biBkZWZhdWx0IHFlbXUgZm9yIDQuMi4KPiDCoCDCoCDCoCogTW9yZSBmb3JtYWxseSBkZXByZWNh
dGUgeG0veGVuZC4gTWFucGFnZSBwYXRjaGVzIGFscmVhZHkgaW4KPiDCoCDCoCDCoCDCoHRyZWUu
IE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0aW9uIGFyb3VuZCAtcmMxIHRvCj4g
wqAgwqAgwqAgwqByZW1pbmQgcGVvcGxlIHRvIHRlc3QgeGwuCj4KPiBoeXBlcnZpc29yLCBuaWNl
IHRvIGhhdmU6Cj4KPiDCoCDCoCDCoCogc29saWQgaW1wbGVtZW50YXRpb24gb2Ygc2hhcmluZy9w
YWdpbmcvbWVtLWV2ZW50cyAodXNpbmcgd29yawo+IMKgIMKgIMKgIMKgcXVldWVzKSAoVGltIERl
ZWdhbiwgT2xhZiBIZXJyaW5nIGV0IGFsKQo+IMKgIMKgIMKgKiBBIGxvbmcgc3RhbmRpbmcgaXNz
dWUgaXMgYSBmdWxseSBzeW5jaHJvbml6ZWQgcDJtIChsb2NraW5nCj4gwqAgwqAgwqAgwqBsb29r
dXBzKSAoQW5kcmVzIExhZ2FyLUNhdmlsbGEpCj4KPiB0b29scywgbmljZSB0byBoYXZlOgo+Cj4g
wqAgwqAgwqAqIEhvdHBsdWcgc2NyaXB0IHN0dWZmIC0tIGludGVybmFsIHRvIGxpYnhsIChJIHRo
aW5rLCB0aGVyZWZvcmUgSQo+IMKgIMKgIMKgIMKgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0YWJs
ZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhhdmUKPiDCoCDCoCDCoCDCoGZvciA0LjI/
IFJvZ2VyIFBhdSBNb25ldCB3YXMgbG9va2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9va2luZwo+IMKg
IMKgIMKgIMKgbGlrZSBhIGJpZyBjYW4tby13b3Jtcy4gKGRpc2N1c3Npb24gb24tZ29pbmcpCj4g
wqAgwqAgwqAqIFVwc3RyZWFtIHFlbXUgZmVhdHVyZSBwYXRjaGVzOgo+IMKgIMKgIMKgIMKgIMKg
IMKgIMKgKiBVcHN0cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRob255IFBl
cmFyZCkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBzYXZlIHJlc3RvcmUg
KEFudGhvbnkgUGVyYXJkKQo+IMKgIMKgIMKgKiBOZXN0ZWQtdmlydHVhbGlzYXRpb24gKGN1cnJl
bnRseSBzaG91bGQgYmUgbWFya2VkIGV4cGVyaW1lbnRhbCwKPiDCoCDCoCDCoCDCoGxpa2VseSB0
byByZWxlYXNlIHRoYXQgd2F5PyBDb25zaWRlciBuZXN0ZWQtc3ZtIHNlcGFyYXRlIHRvCj4gwqAg
wqAgwqAgwqBuZXN0ZWQtdm14LiBOZXN0ZWQtc3ZtIGlzIGluIGJldHRlciBzaGFwZSkKPgo+Cj4K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:09:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:09:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5yI-0003pd-PC; Tue, 17 Jan 2012 10:08:54 +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 1Rn5yG-0003p3-PF
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:08:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326794926!11196888!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTUwNjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTUwNjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7220 invoked from network); 17 Jan 2012 10:08:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 17 Jan 2012 10:08:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326794925; l=510;
	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=+72sRZNQVuiVtedsUSKlfqURo20=;
	b=whWpKgMiNJCNSvBTVdfPMskGgBAQrFEyuKFFfAdxD6bL1Yv0+LP/HhX6Kt9KfTGIJyV
	FxG02KM2GMa/+AoTQAGUeedlG795Dy7acqvRCG3ByDzl+tzZpHQ3Qm3oMcfDPmzK+BApQ
	OeRm2e7/qseiQ9jiBgZNlSHa7B74OUJaTQ0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQESob
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-111-022.pools.arcor-ip.net [88.65.111.22])
	by smtp.strato.de (klopstock mo38) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j00300o0H9mock ;
	Tue, 17 Jan 2012 11:08:39 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 89EF218637; Tue, 17 Jan 2012 11:08:39 +0100 (CET)
Date: Tue, 17 Jan 2012 11:08:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120117100839.GA11552@aepfle.de>
References: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Roger Pau Monne <roger.pau@entel.upc.edu>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, Ian Campbell wrote:

> I think I have incorporated all the updates made in the last thread as
> well as correctly reflected the status of each item. Please let me know
> if something is out of date e.g. if progress has been made which I
> haven't reflected below.

Now that paging is reasonable mature, it should be possible to configure
and tune it via libxl/xl in some way. There is some discussion going on
about how it could be done. I will follow up and prepare a patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:09:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:09:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5yI-0003pd-PC; Tue, 17 Jan 2012 10:08:54 +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 1Rn5yG-0003p3-PF
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:08:53 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326794926!11196888!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTUwNjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTUwNjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7220 invoked from network); 17 Jan 2012 10:08:46 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 17 Jan 2012 10:08:46 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326794925; l=510;
	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=+72sRZNQVuiVtedsUSKlfqURo20=;
	b=whWpKgMiNJCNSvBTVdfPMskGgBAQrFEyuKFFfAdxD6bL1Yv0+LP/HhX6Kt9KfTGIJyV
	FxG02KM2GMa/+AoTQAGUeedlG795Dy7acqvRCG3ByDzl+tzZpHQ3Qm3oMcfDPmzK+BApQ
	OeRm2e7/qseiQ9jiBgZNlSHa7B74OUJaTQ0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQESob
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-111-022.pools.arcor-ip.net [88.65.111.22])
	by smtp.strato.de (klopstock mo38) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j00300o0H9mock ;
	Tue, 17 Jan 2012 11:08:39 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 89EF218637; Tue, 17 Jan 2012 11:08:39 +0100 (CET)
Date: Tue, 17 Jan 2012 11:08:39 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120117100839.GA11552@aepfle.de>
References: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Roger Pau Monne <roger.pau@entel.upc.edu>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, Ian Campbell wrote:

> I think I have incorporated all the updates made in the last thread as
> well as correctly reflected the status of each item. Please let me know
> if something is out of date e.g. if progress has been made which I
> haven't reflected below.

Now that paging is reasonable mature, it should be possible to configure
and tune it via libxl/xl in some way. There is some discussion going on
about how it could be done. I will follow up and prepare a patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:10:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5zc-0003w9-8G; Tue, 17 Jan 2012 10:10:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1Rn5zb-0003va-7Z
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:10:15 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326794966!60528796!1
X-Originating-IP: [209.85.210.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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21829 invoked from network); 17 Jan 2012 10:09:27 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 10:09:27 -0000
Received: by iahk25 with SMTP id k25so22844016iah.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 02:10:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=9g9S3TSNmO69k7mHz0EO5XdjibNZVha3UoPuwOsOZU4=;
	b=HWJpqLw5lLKuAjCNaMJu0gSL1szwZnG8ZvO5N1FQX4lffOBhWntu7mMDX3t+pZ6Laf
	gcecF0mT/YWGLnRiQX+gPeXQTKUUic6UzbxlYyDeLW+8qfH+S9DeGxX6AjnSPagZ1JTx
	/DRB1XJiBcQMo/N+4dI2tnlZveJcuXeuWmZRU=
MIME-Version: 1.0
Received: by 10.50.47.170 with SMTP id e10mr16848529ign.14.1326795007294; Tue,
	17 Jan 2012 02:10:07 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Tue, 17 Jan 2012 02:10:07 -0800 (PST)
Date: Tue, 17 Jan 2012 11:10:07 +0100
Message-ID: <CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Available PCIe lanes for VGA 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: multipart/mixed; boundary="===============1720965453389369555=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1720965453389369555==
Content-Type: multipart/alternative; boundary=14dae9340e3b197ef904b6b68979

--14dae9340e3b197ef904b6b68979
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I hope that I am posting the correct list with this question.

I have been trying to get VGA passthrough working on my system for some
time now without success.
I do not have the system with me right now, so I will not be able to
provide any logs or error messages right now. I will be able to to do so in
a couple of hours.

I have a VT-d enabled system (Motherboard and CPU) on which I wish to pass
the secondary graphics card (EVGA GTX480 SE) through to the HVM (WinXP
32-bit).
Currently I am testing with Debian Squeeze, using the 3.1.8 kernel and Xen
4.2.unstable according to these instructions:
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

I can only boot the WinXP client via the VNC console (gfx_passthrough=0),
and from within WinXP I see that the OS has detected the GTX480 card (as
its secondary card), but I am not able to use it. I have tried the 275.33
drives, and they make no difference.

My question is related to the number of PCIe lanes I have available to the
graphics card.
I only have 8 lanes available for the GTX480 (which is a PCIe x16 card),
could this pose an issue for Xen?


I plan to test VGA passthrough with an ATI graphics card (also in a PCIe x8
slot) later to see if it will work or not. I will update what I find.

Regards

Sandi

--14dae9340e3b197ef904b6b68979
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I hope that I am posting the correct list with th=
is question.</div><div><br></div><div>I have been trying to get VGA passthr=
ough working on my system for some time now without success.</div><div>I do=
 not have the system with me right now, so I will not be able to provide an=
y logs or error messages right now. I will be able to to do so in a couple =
of hours.</div>
<div><br></div><div>I have a VT-d enabled system (Motherboard and CPU) on w=
hich I wish to pass the secondary graphics card (EVGA GTX480 SE) through to=
 the HVM (WinXP 32-bit).</div><div>Currently I am testing with Debian Squee=
ze, using the 3.1.8 kernel and Xen 4.2.unstable according to these instruct=
ions:=A0<a href=3D"http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen=
-42unstable-patches-for-vga-pass-through">http://www.davidgis.fr/blog/index=
.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through</a></div>
<div><br></div><div>I can only boot the WinXP client via the VNC console (g=
fx_passthrough=3D0), and from within WinXP I see that the OS has detected t=
he GTX480 card (as its secondary card), but I am not able to use it. I have=
 tried the=A0<span style=3D"font-family:Verdana,Arial,Geneva,Helvetica,sans=
-serif;font-size:13px">275.33 drives, and they make no difference.</span></=
div>
<div><span style=3D"font-family:Verdana,Arial,Geneva,Helvetica,sans-serif;f=
ont-size:13px"><br></span></div><div><font face=3D"Verdana, Arial, Geneva, =
Helvetica, sans-serif">My question is related to the number of PCIe lanes I=
 have available to the graphics card.</font></div>
<div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">I only ha=
ve 8 lanes available for the GTX480 (which is a PCIe x16 card), could this =
pose an issue for Xen?</font></div><div><font face=3D"Verdana, Arial, Genev=
a, Helvetica, sans-serif"><br>
</font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-ser=
if"><br></font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, =
sans-serif">I plan to test VGA passthrough with an ATI graphics card (also =
in a PCIe x8 slot) later to see if it will work or not. I will update what =
I find.</font></div>
<div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif"><br></fon=
t></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">R=
egards<br><br>Sandi</font></div>

--14dae9340e3b197ef904b6b68979--


--===============1720965453389369555==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1720965453389369555==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:10:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn5zc-0003w9-8G; Tue, 17 Jan 2012 10:10:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1Rn5zb-0003va-7Z
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:10:15 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326794966!60528796!1
X-Originating-IP: [209.85.210.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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21829 invoked from network); 17 Jan 2012 10:09:27 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 10:09:27 -0000
Received: by iahk25 with SMTP id k25so22844016iah.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 02:10:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=9g9S3TSNmO69k7mHz0EO5XdjibNZVha3UoPuwOsOZU4=;
	b=HWJpqLw5lLKuAjCNaMJu0gSL1szwZnG8ZvO5N1FQX4lffOBhWntu7mMDX3t+pZ6Laf
	gcecF0mT/YWGLnRiQX+gPeXQTKUUic6UzbxlYyDeLW+8qfH+S9DeGxX6AjnSPagZ1JTx
	/DRB1XJiBcQMo/N+4dI2tnlZveJcuXeuWmZRU=
MIME-Version: 1.0
Received: by 10.50.47.170 with SMTP id e10mr16848529ign.14.1326795007294; Tue,
	17 Jan 2012 02:10:07 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Tue, 17 Jan 2012 02:10:07 -0800 (PST)
Date: Tue, 17 Jan 2012 11:10:07 +0100
Message-ID: <CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Available PCIe lanes for VGA 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: multipart/mixed; boundary="===============1720965453389369555=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1720965453389369555==
Content-Type: multipart/alternative; boundary=14dae9340e3b197ef904b6b68979

--14dae9340e3b197ef904b6b68979
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I hope that I am posting the correct list with this question.

I have been trying to get VGA passthrough working on my system for some
time now without success.
I do not have the system with me right now, so I will not be able to
provide any logs or error messages right now. I will be able to to do so in
a couple of hours.

I have a VT-d enabled system (Motherboard and CPU) on which I wish to pass
the secondary graphics card (EVGA GTX480 SE) through to the HVM (WinXP
32-bit).
Currently I am testing with Debian Squeeze, using the 3.1.8 kernel and Xen
4.2.unstable according to these instructions:
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through

I can only boot the WinXP client via the VNC console (gfx_passthrough=0),
and from within WinXP I see that the OS has detected the GTX480 card (as
its secondary card), but I am not able to use it. I have tried the 275.33
drives, and they make no difference.

My question is related to the number of PCIe lanes I have available to the
graphics card.
I only have 8 lanes available for the GTX480 (which is a PCIe x16 card),
could this pose an issue for Xen?


I plan to test VGA passthrough with an ATI graphics card (also in a PCIe x8
slot) later to see if it will work or not. I will update what I find.

Regards

Sandi

--14dae9340e3b197ef904b6b68979
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I hope that I am posting the correct list with th=
is question.</div><div><br></div><div>I have been trying to get VGA passthr=
ough working on my system for some time now without success.</div><div>I do=
 not have the system with me right now, so I will not be able to provide an=
y logs or error messages right now. I will be able to to do so in a couple =
of hours.</div>
<div><br></div><div>I have a VT-d enabled system (Motherboard and CPU) on w=
hich I wish to pass the secondary graphics card (EVGA GTX480 SE) through to=
 the HVM (WinXP 32-bit).</div><div>Currently I am testing with Debian Squee=
ze, using the 3.1.8 kernel and Xen 4.2.unstable according to these instruct=
ions:=A0<a href=3D"http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen=
-42unstable-patches-for-vga-pass-through">http://www.davidgis.fr/blog/index=
.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through</a></div>
<div><br></div><div>I can only boot the WinXP client via the VNC console (g=
fx_passthrough=3D0), and from within WinXP I see that the OS has detected t=
he GTX480 card (as its secondary card), but I am not able to use it. I have=
 tried the=A0<span style=3D"font-family:Verdana,Arial,Geneva,Helvetica,sans=
-serif;font-size:13px">275.33 drives, and they make no difference.</span></=
div>
<div><span style=3D"font-family:Verdana,Arial,Geneva,Helvetica,sans-serif;f=
ont-size:13px"><br></span></div><div><font face=3D"Verdana, Arial, Geneva, =
Helvetica, sans-serif">My question is related to the number of PCIe lanes I=
 have available to the graphics card.</font></div>
<div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">I only ha=
ve 8 lanes available for the GTX480 (which is a PCIe x16 card), could this =
pose an issue for Xen?</font></div><div><font face=3D"Verdana, Arial, Genev=
a, Helvetica, sans-serif"><br>
</font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-ser=
if"><br></font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, =
sans-serif">I plan to test VGA passthrough with an ATI graphics card (also =
in a PCIe x8 slot) later to see if it will work or not. I will update what =
I find.</font></div>
<div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif"><br></fon=
t></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">R=
egards<br><br>Sandi</font></div>

--14dae9340e3b197ef904b6b68979--


--===============1720965453389369555==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1720965453389369555==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:16:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 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 1Rn659-0004Pg-Ng; Tue, 17 Jan 2012 10:15:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rn657-0004Pa-HM
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:15:57 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326795335!49065148!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31201 invoked from network); 17 Jan 2012 10:15:35 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-11.tower-27.messagelabs.com with SMTP;
	17 Jan 2012 10:15:35 -0000
Received: (qmail 23478 invoked from network); 17 Jan 2012 11:15:54 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	17 Jan 2012 11:15:54 +0100
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 11:15:53 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-rc4-amd64; KDE/4.6.5; x86_64; ; )
MIME-Version: 1.0
Message-Id: <201201171115.53993.pavel@netsafe.cz>
Subject: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,
I've upgraded my XEN system with Windows 7 virtual hosts to:
MB: ASUS Crosshair V Formula (BIOS 1102)
CPU: AMD FX-8150
which is basically working bus seems to be less stable than old system.

I tried to upgrade BIOS on Formula IV but linux failed to boot the FX even on 
baremetal.

I can't hear sound in DomU. Hmm, to be honest I've heard some broken pieces,..

I tried to pass AMD HD7970 but the VGA BIOS init has probably been changed and 
virtual machine won't start.

And there is one more stange thing (even on old system):
lspci in Dom0 and GPU-Z in virtual machine reports only 2,5GT/s (PCI-E 1.1) on 
PCI-E for VGA while the same kernel on baremetal reports 5GT/s (PCI-E 2.0).
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:16:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 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 1Rn659-0004Pg-Ng; Tue, 17 Jan 2012 10:15:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rn657-0004Pa-HM
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:15:57 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326795335!49065148!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31201 invoked from network); 17 Jan 2012 10:15:35 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-11.tower-27.messagelabs.com with SMTP;
	17 Jan 2012 10:15:35 -0000
Received: (qmail 23478 invoked from network); 17 Jan 2012 11:15:54 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	17 Jan 2012 11:15:54 +0100
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 11:15:53 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-rc4-amd64; KDE/4.6.5; x86_64; ; )
MIME-Version: 1.0
Message-Id: <201201171115.53993.pavel@netsafe.cz>
Subject: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,
I've upgraded my XEN system with Windows 7 virtual hosts to:
MB: ASUS Crosshair V Formula (BIOS 1102)
CPU: AMD FX-8150
which is basically working bus seems to be less stable than old system.

I tried to upgrade BIOS on Formula IV but linux failed to boot the FX even on 
baremetal.

I can't hear sound in DomU. Hmm, to be honest I've heard some broken pieces,..

I tried to pass AMD HD7970 but the VGA BIOS init has probably been changed and 
virtual machine won't start.

And there is one more stange thing (even on old system):
lspci in Dom0 and GPU-Z in virtual machine reports only 2,5GT/s (PCI-E 1.1) on 
PCI-E for VGA while the same kernel on baremetal reports 5GT/s (PCI-E 2.0).
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:39:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6Rf-0004pu-Vt; Tue, 17 Jan 2012 10:39:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rn6Re-0004pm-Dk
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:39:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326796748!1614616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16274 invoked from network); 17 Jan 2012 10:39:08 -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;
	17 Jan 2012 10:39:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10079621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 10:39: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, 17 Jan 2012 10:39:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 17 Jan 2012 10:39:07 +0000
In-Reply-To: <CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326796747.14689.93.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAxLTE3IGF0IDEwOjAwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8xNyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFR1ZSwgMjAxMi0wMS0xNyBhdCAwOTo0MCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90
ZToKPiA+PiAyMDEyLzEvMTcgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46
Cj4gPj4gPiBIb3dldmVyIHhlbmQgc2hvdWxkIG5vdCBiZSB0cmFuc2l0aW9uIHRvIHRoaXMgbmV3
IHNjaGVtZSBidXQgc2hvdWxkCj4gPj4gPiBjb250aW51ZSB0byB1c2UgaXRzIGV4aXN0aW5nIHNj
cmlwdHMgaW4gdGhlIGN1cnJlbnQgbWFubmVyLgo+ID4+ID4KPiA+PiA+IFRoZXJlIHdhcyBhIGNv
bnZlcnNhdGlvbiBsYXN0IHllYXJbMF0gYWJvdXQgaG93IGEgdG9vbHN0YWNrIGNvdWxkCj4gPj4g
PiBvcHQtaW4vb3V0IG9mIHRoZSB1c2Ugb2YgdGhlIGhvdHBsdWcgc2NyaXB0cy4gV2UgZGVjaWRl
ZCB0aGF0IHRvb2xzdGFja3MKPiA+PiA+IHNob3VsZCBoYXZlIHRvIG9wdCBpbnRvIHRoZSB1c2Ug
b2YgdGhlc2Ugc2NyaXB0cywgYnkgdG91Y2hpbmcgYSBzdGFtcAo+ID4+ID4gZmlsZS4KPiA+PiA+
Cj4gPj4gPiBBbHRob3VnaCB0aGlzIHdhc24ndCBpbXBsZW1lbnRlZCB5ZXQgKHVubGVzcyBJIG1p
c3NlZCBpdCkgSSBndWVzcyB0aGUKPiA+PiA+IHNhbWUgc2NoZW1lIHdvdWxkIGFwcGx5IHRvIHRo
aXMgd29yayBpZiB0aGF0IHNvcnQgb2YgdGhpbmcgdHVybnMgb3V0IHRvCj4gPj4gPiBiZSBuZWNl
c3NhcnkuCj4gPj4KPiA+PiBTb3JyeSBmb3IgcmVwbHlpbmcgc28gbWFueSB0aW1lcywgdGhpcyBp
cyBhIGJpZyBtYXliZSwgYW5kIHBvc3NpYmx5Cj4gPj4gaXQncyB0b28gZHJhc3RpYywgYnV0IGFm
dGVyIHRoaXMgY2hhbmdlcyB4bCBhbmQgeGVuZCB3aWxsIG5vdCBiZQo+ID4+IGNvbXBhdGlibGUg
YW55bW9yZSwgc28gd2h5IGRvbid0IHdlIGRpc2FibGUgeGVuZCBieSBkZWZhdWx0LCBhbmQgb25s
eQo+ID4+IGJ1aWxkIHhsPwo+ID4KPiA+IEkgZG9uJ3QgdGhpbmsgdGhleSBhcmUgY29tcGF0aWJs
ZSBub3csIGFyZSB0aGV5PyBJJ3ZlIGNlcnRhaW5seSBzZWVuIG9kZAo+ID4gYmVoYXZpb3VyIHdo
ZW4gdXNpbmcgeGwgd2l0aCB4ZW5kIChhY2NpZGVudGFsbHkpIHJ1bm5pbmcsIHVzdWFsbHkgeGVu
ZAo+ID4gcmVhcHMgdGhlIGRvbWFpbiBJJ3ZlIGp1c3Qgc3RhcnRlZC4uLgo+ID4KPiA+IEknbSBh
bGwgZm9yIGRpc2FibGluZyB0aGUgYnVpbGQgb2YgeGVuZCBieSBkZWZhdWx0IGJ1dCBJIGhhZCBh
c3N1bWVkCj4gPiB0aGF0IG90aGVycyB3b3VsZCB0aGluayA0LjIgd2FzIHJhdGhlciBhbiBhZ2dy
ZXNzaXZlIHRpbWVsaW5lIGZvciB0aGF0Lgo+ID4KPiA+PiBXaGVuIHRoZSBuZXcgY29uZmlndXJl
IHNjcmlwdCBpcyBpbiwgaXQgd2lsbCBiZSB0cml2aWFsIHRvIHNlbGVjdCBpZgo+ID4+IHlvdSB3
YW50IHhsIG9yIHhlbmQsIGFuZCBvbmx5IGluc3RhbGwgb25lIG9mIHRob3NlLiBBZGRpbmcgdGhl
IG9wdGlvbgo+ID4+IC0tZW5hYmxlLXhlbmQgc2hvdWxkIGRpc2FibGUgeGwgYW5kIG9ubHkgYnVp
bGQgYW5kIGluc3RhbGwgeGVuZAo+ID4+IChwcmludGluZyBhIHZlcnkgYmlnIHdhcm5pbmcgdGhh
dCB4ZW5kIGlzIGRlcHJlY2F0ZWQpLgo+ID4KPiA+IEkgZG9uJ3QgdGhpbmsgLS1lbmFibGUteGVu
ZCBzaG91bGQgZXZlciBkaXNhYmxlIHhsIChvciB2aWNlIHZlcnNhKS4gTWFueQo+ID4gZm9sa3Mg
KGUuZy4gZGlzdHJvcykgd2lsbCB3YW50IHRvIGJ1aWxkIGJvdGgsIHBlcmhhcHMgdG8gcGFja2Fn
ZSB0aGVtIGluCj4gPiB0d28gZGlmZmVyZW50IGJpbmFyeSBwYWNrYWdlcywgYnV0IGNlcnRhaW5s
eSB0byBvZmZlciB0aGVpciB1c2VycyB0aGUKPiA+IGNob2ljZSwgYXQgbGVhc3QgZm9yIHRoZSB0
aW1lIGJlaW5nLgo+IAo+IE15IG1haW4gY29uY2VybiB3aXRoIHRoaXMgaXMgdGhhdCB4ZW5kIGFu
ZCB4bCB3aWxsIHN0YXJ0IHRvIHVzZQo+IGRpZmZlcmVudCB1ZGV2IHJ1bGVzICh3ZWxsLCB4ZW5k
IHdpbGwgY29udGludWUgdG8gdXNlIHRoZSBleGlzdGluZwo+IG9uZXMsIHdoaWxlIHhsIHdpbGwg
b25seSB1c2UgYSBzdWJzZXQgb2YgdGhvc2UpLiBTbyB3ZSBoYXZlIHRvIGRlY2lkZQo+IHdoaWNo
IHVkZXYgcnVsZXMgZmlsZSB0byBpbnN0YWxsLCBiZWNhdXNlIHdlIGNhbid0IGhhdmUgYm90aCBp
bnN0YWxsZWQKPiBhdCB0aGUgc2FtZSB0aW1lLgoKU3VyZSB3ZSBjYW4uIFBlcmhhcHMgdGhleSBu
ZWVkIHRvIGhhdmUgYW4gImlmICRUT09MU1RBQ0siIGNoZWNrIChlLmcuIGlmClsgLWYgL3Zhci9y
dW4veGVuZC5ob3RwbHVnIF0pIGFkZGVkIHRvIHRoZSB0b3AsIHRoYXQgaXMgYWxsLgoKPiBBbm90
aGVyIG9wdGlvbiBpcyB0byBpbnN0YWxsIHhsIHVkZXYgcnVsZXMgYnkgZGVmYXVsdCwgYW5kIG1h
a2UgeGVuZAo+IG1vdmUgaXQncyBvd24gcnVsZXMgaW4gdGhlIGluaXQgc2NyaXB0LgoKSSBkb24n
dCB0aGluayBpbml0c2NyaXB0cyBzaG91bGQgYmUgbWVzc2luZyB3aXRoIHVkZXYgcnVsZXMuCgpQ
ZXJoYXBzIHRoZSBvcHQtaW4gbmVlZHMgdG8gYmUgbW9yZSBmaW5lIGdyYWluZWQgZS5nLiBvcHQt
aW4gdG8gdmlmIGJ1dApub3QgYmxvY2sgc2NyaXB0cyBvciB3aGF0ZXZlciBkaXN0aW5jdGlvbiB5
b3UgdGhpbmsgaXMgbmVjZXNzYXJ5IGluc3RlYWQKb2YganV0IGEgZ2xvYmFsIG9wdCBpbiwgaXQn
cyBqdXN0IGEgZGlmZmVyZW50IG5hbWluZyBjb252ZW50aW9uIGZvciB0aGUKc3RhbXAgZmlsZS4g
VGhpcyBhdm9pZHMgcmVjb25maWd1cmF0aW9uIGFuZCB0aGUgbmVlZCB0byBpbnN0YWxsIHN1YnNl
dHMKb2YgdGhlIHNjcmlwdHMgZXRjLgoKPiAgU2luY2UgeGwgZG9lc24ndCB1c2UgYSBkYWVtb24s
Cj4geGwgc2hvdWxkIGFsd2F5cyBjaGVjayBpZiB4ZW5kIGlzIHJ1bm5pbmcgYmVmb3JlIGRvaW5n
IGFueXRoaW5nIGFuZAo+IGZhaWwgaWYgeGVuZCBpcyBmb3VuZC4KCkkgdGhpbmsgdGhhdCBpcyBh
IHNlcGFyYXRlIHF1ZXN0aW9uL2lzc3VlIHRvIHRoZSBvbmUgb2YgaG90cGx1ZyBzY3JpcHRzLgoK
SWFuLgoKPiAKPiA+Pgo+ID4+ID4gSWFuLgo+ID4+ID4KPiA+PiA+IFswXSBodHRwOi8vbGlzdHMu
eGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTA2L21zZzAwOTUyLmh0bWwKPiA+
PiA+Cj4gPgo+ID4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:39:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:39:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6Rf-0004pu-Vt; Tue, 17 Jan 2012 10:39:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rn6Re-0004pm-Dk
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:39:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326796748!1614616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16274 invoked from network); 17 Jan 2012 10:39:08 -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;
	17 Jan 2012 10:39:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10079621"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 10:39: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, 17 Jan 2012 10:39:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 17 Jan 2012 10:39:07 +0000
In-Reply-To: <CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326796747.14689.93.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gVHVlLCAyMDEyLTAxLTE3IGF0IDEwOjAwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8xNyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFR1ZSwgMjAxMi0wMS0xNyBhdCAwOTo0MCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90
ZToKPiA+PiAyMDEyLzEvMTcgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46
Cj4gPj4gPiBIb3dldmVyIHhlbmQgc2hvdWxkIG5vdCBiZSB0cmFuc2l0aW9uIHRvIHRoaXMgbmV3
IHNjaGVtZSBidXQgc2hvdWxkCj4gPj4gPiBjb250aW51ZSB0byB1c2UgaXRzIGV4aXN0aW5nIHNj
cmlwdHMgaW4gdGhlIGN1cnJlbnQgbWFubmVyLgo+ID4+ID4KPiA+PiA+IFRoZXJlIHdhcyBhIGNv
bnZlcnNhdGlvbiBsYXN0IHllYXJbMF0gYWJvdXQgaG93IGEgdG9vbHN0YWNrIGNvdWxkCj4gPj4g
PiBvcHQtaW4vb3V0IG9mIHRoZSB1c2Ugb2YgdGhlIGhvdHBsdWcgc2NyaXB0cy4gV2UgZGVjaWRl
ZCB0aGF0IHRvb2xzdGFja3MKPiA+PiA+IHNob3VsZCBoYXZlIHRvIG9wdCBpbnRvIHRoZSB1c2Ug
b2YgdGhlc2Ugc2NyaXB0cywgYnkgdG91Y2hpbmcgYSBzdGFtcAo+ID4+ID4gZmlsZS4KPiA+PiA+
Cj4gPj4gPiBBbHRob3VnaCB0aGlzIHdhc24ndCBpbXBsZW1lbnRlZCB5ZXQgKHVubGVzcyBJIG1p
c3NlZCBpdCkgSSBndWVzcyB0aGUKPiA+PiA+IHNhbWUgc2NoZW1lIHdvdWxkIGFwcGx5IHRvIHRo
aXMgd29yayBpZiB0aGF0IHNvcnQgb2YgdGhpbmcgdHVybnMgb3V0IHRvCj4gPj4gPiBiZSBuZWNl
c3NhcnkuCj4gPj4KPiA+PiBTb3JyeSBmb3IgcmVwbHlpbmcgc28gbWFueSB0aW1lcywgdGhpcyBp
cyBhIGJpZyBtYXliZSwgYW5kIHBvc3NpYmx5Cj4gPj4gaXQncyB0b28gZHJhc3RpYywgYnV0IGFm
dGVyIHRoaXMgY2hhbmdlcyB4bCBhbmQgeGVuZCB3aWxsIG5vdCBiZQo+ID4+IGNvbXBhdGlibGUg
YW55bW9yZSwgc28gd2h5IGRvbid0IHdlIGRpc2FibGUgeGVuZCBieSBkZWZhdWx0LCBhbmQgb25s
eQo+ID4+IGJ1aWxkIHhsPwo+ID4KPiA+IEkgZG9uJ3QgdGhpbmsgdGhleSBhcmUgY29tcGF0aWJs
ZSBub3csIGFyZSB0aGV5PyBJJ3ZlIGNlcnRhaW5seSBzZWVuIG9kZAo+ID4gYmVoYXZpb3VyIHdo
ZW4gdXNpbmcgeGwgd2l0aCB4ZW5kIChhY2NpZGVudGFsbHkpIHJ1bm5pbmcsIHVzdWFsbHkgeGVu
ZAo+ID4gcmVhcHMgdGhlIGRvbWFpbiBJJ3ZlIGp1c3Qgc3RhcnRlZC4uLgo+ID4KPiA+IEknbSBh
bGwgZm9yIGRpc2FibGluZyB0aGUgYnVpbGQgb2YgeGVuZCBieSBkZWZhdWx0IGJ1dCBJIGhhZCBh
c3N1bWVkCj4gPiB0aGF0IG90aGVycyB3b3VsZCB0aGluayA0LjIgd2FzIHJhdGhlciBhbiBhZ2dy
ZXNzaXZlIHRpbWVsaW5lIGZvciB0aGF0Lgo+ID4KPiA+PiBXaGVuIHRoZSBuZXcgY29uZmlndXJl
IHNjcmlwdCBpcyBpbiwgaXQgd2lsbCBiZSB0cml2aWFsIHRvIHNlbGVjdCBpZgo+ID4+IHlvdSB3
YW50IHhsIG9yIHhlbmQsIGFuZCBvbmx5IGluc3RhbGwgb25lIG9mIHRob3NlLiBBZGRpbmcgdGhl
IG9wdGlvbgo+ID4+IC0tZW5hYmxlLXhlbmQgc2hvdWxkIGRpc2FibGUgeGwgYW5kIG9ubHkgYnVp
bGQgYW5kIGluc3RhbGwgeGVuZAo+ID4+IChwcmludGluZyBhIHZlcnkgYmlnIHdhcm5pbmcgdGhh
dCB4ZW5kIGlzIGRlcHJlY2F0ZWQpLgo+ID4KPiA+IEkgZG9uJ3QgdGhpbmsgLS1lbmFibGUteGVu
ZCBzaG91bGQgZXZlciBkaXNhYmxlIHhsIChvciB2aWNlIHZlcnNhKS4gTWFueQo+ID4gZm9sa3Mg
KGUuZy4gZGlzdHJvcykgd2lsbCB3YW50IHRvIGJ1aWxkIGJvdGgsIHBlcmhhcHMgdG8gcGFja2Fn
ZSB0aGVtIGluCj4gPiB0d28gZGlmZmVyZW50IGJpbmFyeSBwYWNrYWdlcywgYnV0IGNlcnRhaW5s
eSB0byBvZmZlciB0aGVpciB1c2VycyB0aGUKPiA+IGNob2ljZSwgYXQgbGVhc3QgZm9yIHRoZSB0
aW1lIGJlaW5nLgo+IAo+IE15IG1haW4gY29uY2VybiB3aXRoIHRoaXMgaXMgdGhhdCB4ZW5kIGFu
ZCB4bCB3aWxsIHN0YXJ0IHRvIHVzZQo+IGRpZmZlcmVudCB1ZGV2IHJ1bGVzICh3ZWxsLCB4ZW5k
IHdpbGwgY29udGludWUgdG8gdXNlIHRoZSBleGlzdGluZwo+IG9uZXMsIHdoaWxlIHhsIHdpbGwg
b25seSB1c2UgYSBzdWJzZXQgb2YgdGhvc2UpLiBTbyB3ZSBoYXZlIHRvIGRlY2lkZQo+IHdoaWNo
IHVkZXYgcnVsZXMgZmlsZSB0byBpbnN0YWxsLCBiZWNhdXNlIHdlIGNhbid0IGhhdmUgYm90aCBp
bnN0YWxsZWQKPiBhdCB0aGUgc2FtZSB0aW1lLgoKU3VyZSB3ZSBjYW4uIFBlcmhhcHMgdGhleSBu
ZWVkIHRvIGhhdmUgYW4gImlmICRUT09MU1RBQ0siIGNoZWNrIChlLmcuIGlmClsgLWYgL3Zhci9y
dW4veGVuZC5ob3RwbHVnIF0pIGFkZGVkIHRvIHRoZSB0b3AsIHRoYXQgaXMgYWxsLgoKPiBBbm90
aGVyIG9wdGlvbiBpcyB0byBpbnN0YWxsIHhsIHVkZXYgcnVsZXMgYnkgZGVmYXVsdCwgYW5kIG1h
a2UgeGVuZAo+IG1vdmUgaXQncyBvd24gcnVsZXMgaW4gdGhlIGluaXQgc2NyaXB0LgoKSSBkb24n
dCB0aGluayBpbml0c2NyaXB0cyBzaG91bGQgYmUgbWVzc2luZyB3aXRoIHVkZXYgcnVsZXMuCgpQ
ZXJoYXBzIHRoZSBvcHQtaW4gbmVlZHMgdG8gYmUgbW9yZSBmaW5lIGdyYWluZWQgZS5nLiBvcHQt
aW4gdG8gdmlmIGJ1dApub3QgYmxvY2sgc2NyaXB0cyBvciB3aGF0ZXZlciBkaXN0aW5jdGlvbiB5
b3UgdGhpbmsgaXMgbmVjZXNzYXJ5IGluc3RlYWQKb2YganV0IGEgZ2xvYmFsIG9wdCBpbiwgaXQn
cyBqdXN0IGEgZGlmZmVyZW50IG5hbWluZyBjb252ZW50aW9uIGZvciB0aGUKc3RhbXAgZmlsZS4g
VGhpcyBhdm9pZHMgcmVjb25maWd1cmF0aW9uIGFuZCB0aGUgbmVlZCB0byBpbnN0YWxsIHN1YnNl
dHMKb2YgdGhlIHNjcmlwdHMgZXRjLgoKPiAgU2luY2UgeGwgZG9lc24ndCB1c2UgYSBkYWVtb24s
Cj4geGwgc2hvdWxkIGFsd2F5cyBjaGVjayBpZiB4ZW5kIGlzIHJ1bm5pbmcgYmVmb3JlIGRvaW5n
IGFueXRoaW5nIGFuZAo+IGZhaWwgaWYgeGVuZCBpcyBmb3VuZC4KCkkgdGhpbmsgdGhhdCBpcyBh
IHNlcGFyYXRlIHF1ZXN0aW9uL2lzc3VlIHRvIHRoZSBvbmUgb2YgaG90cGx1ZyBzY3JpcHRzLgoK
SWFuLgoKPiAKPiA+Pgo+ID4+ID4gSWFuLgo+ID4+ID4KPiA+PiA+IFswXSBodHRwOi8vbGlzdHMu
eGVuLm9yZy9hcmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTA2L21zZzAwOTUyLmh0bWwKPiA+
PiA+Cj4gPgo+ID4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:53:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6fW-00057T-CL; Tue, 17 Jan 2012 10:53: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 1Rn6fV-00057N-Oa
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:53:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326797607!11339621!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 28828 invoked from network); 17 Jan 2012 10:53:27 -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; 17 Jan 2012 10:53:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rn6fM-0001pt-EP; Tue, 17 Jan 2012 10:53:24 +0000
Date: Tue, 17 Jan 2012 10:53:23 +0000
From: Tim Deegan <tim@xen.org>
To: Nai Xia <nai.xia@gmail.com>
Message-ID: <20120117105323.GA74654@ocelot.phlegethon.org>
References: <4F14345B.4040807@gmail.com>
	<CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Grzegorz Milos <Grzegorz.Milos@citrix.com>
Subject: Re: [Xen-devel] Is this a racing bug in page_make_sharable()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:43 +0800 on 16 Jan (1326753834), Nai Xia wrote:
> Hi Grzegorz,
> 
> As I understand, the purpose of the code in page_make_sharable()
> checking the ref count is to ensure that nobody unexpected is working
> on the page, and so we can migrate it to dom_cow, right?
> 
> ====
>     /* Check if the ref count is 2. The first from PGT_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;
>     }
> ====
> 
> However, it seems to me that this ref check and the following page
> migration is not atomic( although the operations for type_info ref
> check seems good) i.e. it's possible that it passed this ref
> check but just before it goes to dom_cow, someone else gets this page?

Yes, there are a number of races around the p2m code; Anders
Lagar-Cavilla has been working on fixing the locking around p2m lookups
to take care of this.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:53:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:53:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6fW-00057T-CL; Tue, 17 Jan 2012 10:53: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 1Rn6fV-00057N-Oa
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:53:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326797607!11339621!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 28828 invoked from network); 17 Jan 2012 10:53:27 -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; 17 Jan 2012 10:53:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rn6fM-0001pt-EP; Tue, 17 Jan 2012 10:53:24 +0000
Date: Tue, 17 Jan 2012 10:53:23 +0000
From: Tim Deegan <tim@xen.org>
To: Nai Xia <nai.xia@gmail.com>
Message-ID: <20120117105323.GA74654@ocelot.phlegethon.org>
References: <4F14345B.4040807@gmail.com>
	<CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPQyPG5tW+Y2Snyf8qF8nn5pYcwrz=craTeedv_nAP8r8c9Q-A@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com, Grzegorz Milos <Grzegorz.Milos@citrix.com>
Subject: Re: [Xen-devel] Is this a racing bug in page_make_sharable()?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:43 +0800 on 16 Jan (1326753834), Nai Xia wrote:
> Hi Grzegorz,
> 
> As I understand, the purpose of the code in page_make_sharable()
> checking the ref count is to ensure that nobody unexpected is working
> on the page, and so we can migrate it to dom_cow, right?
> 
> ====
>     /* Check if the ref count is 2. The first from PGT_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;
>     }
> ====
> 
> However, it seems to me that this ref check and the following page
> migration is not atomic( although the operations for type_info ref
> check seems good) i.e. it's possible that it passed this ref
> check but just before it goes to dom_cow, someone else gets this page?

Yes, there are a number of races around the p2m code; Anders
Lagar-Cavilla has been working on fixing the locking around p2m lookups
to take care of this.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:54:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:54:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6fb-00057k-Ou; Tue, 17 Jan 2012 10:53:39 +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 1Rn6fa-00057O-0d
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:53:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326797611!11343583!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzA0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzA0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29177 invoked from network); 17 Jan 2012 10:53:32 -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; 17 Jan 2012 10:53:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326797611; l=174;
	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=jbegrd66Yr/6LaCZW1EuIMYu/xs=;
	b=ABNiPrxkcu0WM8SpHZbml87jmzwi0PusCG9vM0rjwPmiGYazjGMTz4ARiR/Yg8xzUlu
	FK3AsmCzD5ggrdWm0d/7VzWncvDKFt/nWooQFjGv8YVwIu3o+za2wOiXmbkanPmbrnuDX
	K8RsPOboAe8MDOM8fdAyVP0W1SwEWZjvfpg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQESob
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-111-022.pools.arcor-ip.net [88.65.111.22])
	by post.strato.de (mrclete mo21) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 6018f8o0H9tZvV ;
	Tue, 17 Jan 2012 11:53:21 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A056E18637; Tue, 17 Jan 2012 11:53:21 +0100 (CET)
Date: Tue, 17 Jan 2012 11:53:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120117105321.GA11327@aepfle.de>
References: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Roger Pau Monne <roger.pau@entel.upc.edu>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List 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


For libxl, it would be nice to have also libyajl2 support. OpenSuSE 11.4
was the last version which shipped libyajl1, 12.1 and later seem to have
just libyajl2.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 10:54:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 10:54:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6fb-00057k-Ou; Tue, 17 Jan 2012 10:53:39 +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 1Rn6fa-00057O-0d
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 10:53:38 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326797611!11343583!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzA0MTE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzA0MTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29177 invoked from network); 17 Jan 2012 10:53:32 -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; 17 Jan 2012 10:53:32 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326797611; l=174;
	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=jbegrd66Yr/6LaCZW1EuIMYu/xs=;
	b=ABNiPrxkcu0WM8SpHZbml87jmzwi0PusCG9vM0rjwPmiGYazjGMTz4ARiR/Yg8xzUlu
	FK3AsmCzD5ggrdWm0d/7VzWncvDKFt/nWooQFjGv8YVwIu3o+za2wOiXmbkanPmbrnuDX
	K8RsPOboAe8MDOM8fdAyVP0W1SwEWZjvfpg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzIQESob
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-111-022.pools.arcor-ip.net [88.65.111.22])
	by post.strato.de (mrclete mo21) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 6018f8o0H9tZvV ;
	Tue, 17 Jan 2012 11:53:21 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A056E18637; Tue, 17 Jan 2012 11:53:21 +0100 (CET)
Date: Tue, 17 Jan 2012 11:53:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120117105321.GA11327@aepfle.de>
References: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Roger Pau Monne <roger.pau@entel.upc.edu>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List 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


For libxl, it would be nice to have also libyajl2 support. OpenSuSE 11.4
was the last version which shipped libyajl1, 12.1 and later seem to have
just libyajl2.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:02:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6o7-0005fu-EB; Tue, 17 Jan 2012 11:02:27 +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 1Rn6o6-0005fk-EH
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:02:26 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326798023!60025546!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6994 invoked from network); 17 Jan 2012 11:00:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 11:00:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320642000"; d="scan'208";a="177820020"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 06:02:19 -0500
Received: from [127.0.1.1] (10.80.3.161) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 17 Jan 2012
	06:02:18 -0500
MIME-Version: 1.0
X-Mercurial-Node: 37b60f1b74641ba9e10064d11ce7178680d1536e
Message-ID: <37b60f1b74641ba9e100.1326798297@fountains-ubuntu>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 17 Jan 2012 11:04:57 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Add missing gate for HVM 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 Paul Durrant <paul.durrant@citrix.com>
# Date 1326798293 0
# Node ID 37b60f1b74641ba9e10064d11ce7178680d1536e
# Parent  2913ccc6d70f15ffcc15c7e066c9269b15a30a09
Add missing gate for HVM domain.

This will fix localhost migrate failures found by the automatic tests.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 2913ccc6d70f -r 37b60f1b7464 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 16 17:56:07 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 17 11:04:53 2012 +0000
@@ -1580,7 +1580,8 @@ static int create_domain(struct domain_c
         }
     }
 
-    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+    if (d_config.c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+        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);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:02:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6o7-0005fu-EB; Tue, 17 Jan 2012 11:02:27 +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 1Rn6o6-0005fk-EH
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:02:26 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326798023!60025546!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6994 invoked from network); 17 Jan 2012 11:00:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 11:00:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320642000"; d="scan'208";a="177820020"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 06:02:19 -0500
Received: from [127.0.1.1] (10.80.3.161) by FTLPMAILMX02.citrite.net
	(10.13.107.66) with Microsoft SMTP Server id 8.3.213.0; Tue, 17 Jan 2012
	06:02:18 -0500
MIME-Version: 1.0
X-Mercurial-Node: 37b60f1b74641ba9e10064d11ce7178680d1536e
Message-ID: <37b60f1b74641ba9e100.1326798297@fountains-ubuntu>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Tue, 17 Jan 2012 11:04:57 +0000
From: Paul Durrant <paul.durrant@citrix.com>
To: xen-devel@lists.xensource.com
Cc: paul.durrant@citrix.com
Subject: [Xen-devel] [PATCH] Add missing gate for HVM 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 Paul Durrant <paul.durrant@citrix.com>
# Date 1326798293 0
# Node ID 37b60f1b74641ba9e10064d11ce7178680d1536e
# Parent  2913ccc6d70f15ffcc15c7e066c9269b15a30a09
Add missing gate for HVM domain.

This will fix localhost migrate failures found by the automatic tests.

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

diff -r 2913ccc6d70f -r 37b60f1b7464 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 16 17:56:07 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 17 11:04:53 2012 +0000
@@ -1580,7 +1580,8 @@ static int create_domain(struct domain_c
         }
     }
 
-    d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid;
+    if (d_config.c_info.type == LIBXL_DOMAIN_TYPE_HVM)
+        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);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:03:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6oN-0005h3-3X; Tue, 17 Jan 2012 11:02: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 1Rn6oK-0005gJ-SH
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:02:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326798154!9480635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5157 invoked from network); 17 Jan 2012 11:02:34 -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;
	17 Jan 2012 11:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10080291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 11:02:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 11:02:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 17 Jan 2012 11:02:31 +0000
In-Reply-To: <20120117105321.GA11327@aepfle.de>
References: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
	<20120117105321.GA11327@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326798151.14689.94.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Roger Pau Monne <roger.pau@entel.upc.edu>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-17 at 10:53 +0000, Olaf Hering wrote:
> For libxl, it would be nice to have also libyajl2 support. OpenSuSE 11.4
> was the last version which shipped libyajl1, 12.1 and later seem to have
> just libyajl2.

Roger Pau Monet posted such a patch but it ended up depending on the
switch to autoconf. I will add those two to the next version of the TODO
list, as blockers unless someone objects.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:03:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:03:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6oN-0005h3-3X; Tue, 17 Jan 2012 11:02: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 1Rn6oK-0005gJ-SH
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:02:41 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326798154!9480635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5157 invoked from network); 17 Jan 2012 11:02:34 -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;
	17 Jan 2012 11:02:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10080291"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 11:02:32 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 11:02:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Date: Tue, 17 Jan 2012 11:02:31 +0000
In-Reply-To: <20120117105321.GA11327@aepfle.de>
References: <1326794401.14689.84.camel@zakaz.uk.xensource.com>
	<20120117105321.GA11327@aepfle.de>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326798151.14689.94.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, "Tim \(Xen.org\)" <tim@xen.org>,
	Roger Pau Monne <roger.pau@entel.upc.edu>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <JBeulich@suse.com>, Anthony Perard <anthony.perard@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-17 at 10:53 +0000, Olaf Hering wrote:
> For libxl, it would be nice to have also libyajl2 support. OpenSuSE 11.4
> was the last version which shipped libyajl1, 12.1 and later seem to have
> just libyajl2.

Roger Pau Monet posted such a patch but it ended up depending on the
switch to autoconf. I will add those two to the next version of the TODO
list, as blockers unless someone objects.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:06:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 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 1Rn6rH-0005wo-W0; Tue, 17 Jan 2012 11:05:43 +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 1Rn6rG-0005wV-Po
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:05:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326798336!7497298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32548 invoked from network); 17 Jan 2012 11:05:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 11:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10080394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 11:05:35 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 17 Jan 2012
	11:05:34 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 11:05:35 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUW3WsO0m3e1wtTi+9q9RN5lp4LgAopq0QAAJegqA=
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BECB2@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
	<20244.5493.159092.178261@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC67@LONPMAILBOX01.citrite.net>
	<20244.13470.956567.815603@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BECAD@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BECAD@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
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] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Paul Durrant
> Sent: 17 January 2012 10:05
> To: Ian Jackson
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Ian Campbell; Stefano
> Stabellini
> Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> So far I've been unable to repro. with a build of staging tip from yesterday
> (running a 512MB PV debian guest with a 3.2.0-rc2+ kernel). I'll revert to the
> appropriate c/s and see if I can repro. with that. The errors unfortunately
> don't give much away other than the receiving process clearly didn't like
> something about the migration data stream.
> 
> libxl: error: libxl_utils.c:409:libxl_read_exactly: file/stream truncated
> reading ready message from migration receiver stream
> libxl: info: libxl_exec.c:124:libxl_report_child_exitstatus: migration target
> process [14446] exited with error status 255
> 

Apologies for the previous top-post; it seems impossible to configure outlook to not do that by default :-(

I reproduced the problem. The bug has been identified and a fix verified. I posted the patch a couple of minutes ago.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:06:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 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 1Rn6rH-0005wo-W0; Tue, 17 Jan 2012 11:05:43 +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 1Rn6rG-0005wV-Po
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:05:43 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326798336!7497298!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32548 invoked from network); 17 Jan 2012 11:05:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 11:05:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10080394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 11:05:35 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.161]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Tue, 17 Jan 2012
	11:05:34 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 11:05:35 +0000
Thread-Topic: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
Thread-Index: AczUW3WsO0m3e1wtTi+9q9RN5lp4LgAopq0QAAJegqA=
Message-ID: <291EDFCB1E9E224A99088639C4762022B5991BECB2@LONPMAILBOX01.citrite.net>
References: <E1Rm2Ma-0002v3-0k@woking.xci-test.com>
	<1326709302.17210.402.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4B@LONPMAILBOX01.citrite.net>
	<291EDFCB1E9E224A99088639C4762022B5991BEC4E@LONPMAILBOX01.citrite.net>
	<20244.5493.159092.178261@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BEC67@LONPMAILBOX01.citrite.net>
	<20244.13470.956567.815603@mariner.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022B5991BECAD@LONPMAILBOX01.citrite.net>
In-Reply-To: <291EDFCB1E9E224A99088639C4762022B5991BECAD@LONPMAILBOX01.citrite.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
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] [xen-unstable bisection] complete test-i386-i386-xl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Paul Durrant
> Sent: 17 January 2012 10:05
> To: Ian Jackson
> Cc: xen-devel@lists.xensource.com; Keir (Xen.org); Ian Campbell; Stefano
> Stabellini
> Subject: Re: [Xen-devel] [xen-unstable bisection] complete test-i386-i386-xl
> 
> So far I've been unable to repro. with a build of staging tip from yesterday
> (running a 512MB PV debian guest with a 3.2.0-rc2+ kernel). I'll revert to the
> appropriate c/s and see if I can repro. with that. The errors unfortunately
> don't give much away other than the receiving process clearly didn't like
> something about the migration data stream.
> 
> libxl: error: libxl_utils.c:409:libxl_read_exactly: file/stream truncated
> reading ready message from migration receiver stream
> libxl: info: libxl_exec.c:124:libxl_report_child_exitstatus: migration target
> process [14446] exited with error status 255
> 

Apologies for the previous top-post; it seems impossible to configure outlook to not do that by default :-(

I reproduced the problem. The bug has been identified and a fix verified. I posted the patch a couple of minutes ago.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:08:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6tr-00068w-IM; Tue, 17 Jan 2012 11:08: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 1Rn6tp-00068f-Q3
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:08:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326798494!8844574!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14818 invoked from network); 17 Jan 2012 11:08:15 -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;
	17 Jan 2012 11:08:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320642000"; d="scan'208";a="20956439"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 06:08:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 06:08: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
	q0HB8Bht002793;	Tue, 17 Jan 2012 03:08:12 -0800
MIME-Version: 1.0
X-Mercurial-Node: 8032df4baf729fc215de7bf8d3015c4ddc107a00
Message-ID: <8032df4baf729fc215de.1326798490@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 17 Jan 2012 11:08:10 +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 _libxl_json_internal.h from
	libxl_json.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 Ian Campbell <ian.campbell@citrix.com>
# Date 1326798471 0
# Node ID 8032df4baf729fc215de7bf8d3015c4ddc107a00
# Parent  120035806c1bf1ab81bdc1664e84302c8c0066c6
libxl: remove _libxl_json_internal.h from libxl_json.h

libxl_json.h is intended as a user-includable header for applications which
would like to use libyajl directly with libxl types. It should not expose libxl
internals.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 120035806c1b -r 8032df4baf72 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Jan 17 11:04:46 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Jan 17 11:07:51 2012 +0000
@@ -61,8 +61,10 @@
 #include "flexarray.h"
 #include "libxl_utils.h"
 
+#include "libxl_json.h"
+
 #include "_libxl_types_internal.h"
-#include "libxl_json.h"
+#include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
diff -r 120035806c1b -r 8032df4baf72 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Tue Jan 17 11:04:46 2012 +0000
+++ b/tools/libxl/libxl_json.h	Tue Jan 17 11:07:51 2012 +0000
@@ -18,6 +18,5 @@
 #include <yajl/yajl_gen.h>
 
 #include <_libxl_types_json.h>
-#include <_libxl_types_internal_json.h>
 
 #endif /* LIBXL_JSON_H */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:08:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:08:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6tr-00068w-IM; Tue, 17 Jan 2012 11:08: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 1Rn6tp-00068f-Q3
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:08:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326798494!8844574!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14818 invoked from network); 17 Jan 2012 11:08:15 -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;
	17 Jan 2012 11:08:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320642000"; d="scan'208";a="20956439"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 06:08:13 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 06:08: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
	q0HB8Bht002793;	Tue, 17 Jan 2012 03:08:12 -0800
MIME-Version: 1.0
X-Mercurial-Node: 8032df4baf729fc215de7bf8d3015c4ddc107a00
Message-ID: <8032df4baf729fc215de.1326798490@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Tue, 17 Jan 2012 11:08:10 +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 _libxl_json_internal.h from
	libxl_json.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 Ian Campbell <ian.campbell@citrix.com>
# Date 1326798471 0
# Node ID 8032df4baf729fc215de7bf8d3015c4ddc107a00
# Parent  120035806c1bf1ab81bdc1664e84302c8c0066c6
libxl: remove _libxl_json_internal.h from libxl_json.h

libxl_json.h is intended as a user-includable header for applications which
would like to use libyajl directly with libxl types. It should not expose libxl
internals.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 120035806c1b -r 8032df4baf72 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Tue Jan 17 11:04:46 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Tue Jan 17 11:07:51 2012 +0000
@@ -61,8 +61,10 @@
 #include "flexarray.h"
 #include "libxl_utils.h"
 
+#include "libxl_json.h"
+
 #include "_libxl_types_internal.h"
-#include "libxl_json.h"
+#include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
diff -r 120035806c1b -r 8032df4baf72 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Tue Jan 17 11:04:46 2012 +0000
+++ b/tools/libxl/libxl_json.h	Tue Jan 17 11:07:51 2012 +0000
@@ -18,6 +18,5 @@
 #include <yajl/yajl_gen.h>
 
 #include <_libxl_types_json.h>
-#include <_libxl_types_internal_json.h>
 
 #endif /* LIBXL_JSON_H */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:09:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6uI-0006C9-W1; Tue, 17 Jan 2012 11:08:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rn6uH-0006BL-IF
	for xen-devel@lists.xen.org; Tue, 17 Jan 2012 11:08:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326798523!8627533!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 13818 invoked from network); 17 Jan 2012 11:08:43 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 11:08:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rn6u9-0001vz-Qu; Tue, 17 Jan 2012 11:08:42 +0000
Date: Tue, 17 Jan 2012 11:08:40 +0000
From: Tim Deegan <tim@xen.org>
To: Antony Saba <Antony.Saba@mandiant.com>
Message-ID: <20120117110840.GB74654@ocelot.phlegethon.org>
References: <4F14C5B9.9080501@mandiant.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F14C5B9.9080501@mandiant.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems calling HVMOP_flush_tlbs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 00:50 +0000 on 17 Jan (1326761401), Antony Saba wrote:
> Hello xen-devel,
> 
> I am using xen 4.2.1 and have tried the following with kernel 3.0.0 and 
> 3.2.1.
> 
> I am trying to invoke the HVMOP_flush_tlbs hypercall but have been 
> unsuccessful.  I am basing my call on the functions in in xc_misc.c, 
> trying to guess what is meant by "@arg must be null" in the comment 
> where HVMOP_flush_tlbs is defined.  What is the correct way to invoke 
> this hypercall?
> 
> If I call it like this, I receive an invalid parameter (EINVAL) error:
>      struct privcmd_hypercall
>      {
>          uint64_t op;
>          uint64_t arg[5];
>      } hypercall;
>      hypercall.op     = __HYPERVISOR_hvm_op;
>      hypercall.arg[0] = HVMOP_flush_tlbs;
>      hypercall.arg[1] = 0;
>      ret = do_xen_hypercall(xch, (void*)&hypercall);
> 
> 
> If I call it like this, I get function not implemented (ENOSYS), where 3 
> is a valid domain id:
>      hypercall.op     = __HYPERVISOR_hvm_op;
>      hypercall.arg[0] = HVMOP_flush_tlbs;
>      hypercall.arg[1] = 3;  /* 3 is the domain whose tlbs should be 
> flushed */
>      hypercall.arg[2] = 0;

Did you look at the code of Xen?  A quick grep finds this:

    case HVMOP_flush_tlbs:
        rc = guest_handle_is_null(arg) ? hvmop_flush_tlb_all() : -ENOSYS;
        break;

So that's what "@arg must ne null" means: if you provide an argument,
you get ENOSYS.  And just inside hvmop_flush_tlb_all() is this:

    if ( !is_hvm_domain(d) )
        return -EINVAL;

So if you call from a non-HVM domain, you get EINVAL.  That matches what
you're seeing. 

I think the important detail is that HVMOP_flush_tlbs doesn't take a target
domain - it always flushes the _caller's_ TLBs.  I guess you want to
flush the TLBs of another domain for some reason?  AFAICS the version in
mainline Xen has never taken an argument so perhaps you could add one
(making sure to keep backward compatibility, of course).

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:09:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:09:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6uI-0006C9-W1; Tue, 17 Jan 2012 11:08:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rn6uH-0006BL-IF
	for xen-devel@lists.xen.org; Tue, 17 Jan 2012 11:08:49 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326798523!8627533!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 13818 invoked from network); 17 Jan 2012 11:08:43 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 11:08:43 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rn6u9-0001vz-Qu; Tue, 17 Jan 2012 11:08:42 +0000
Date: Tue, 17 Jan 2012 11:08:40 +0000
From: Tim Deegan <tim@xen.org>
To: Antony Saba <Antony.Saba@mandiant.com>
Message-ID: <20120117110840.GB74654@ocelot.phlegethon.org>
References: <4F14C5B9.9080501@mandiant.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F14C5B9.9080501@mandiant.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems calling HVMOP_flush_tlbs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 00:50 +0000 on 17 Jan (1326761401), Antony Saba wrote:
> Hello xen-devel,
> 
> I am using xen 4.2.1 and have tried the following with kernel 3.0.0 and 
> 3.2.1.
> 
> I am trying to invoke the HVMOP_flush_tlbs hypercall but have been 
> unsuccessful.  I am basing my call on the functions in in xc_misc.c, 
> trying to guess what is meant by "@arg must be null" in the comment 
> where HVMOP_flush_tlbs is defined.  What is the correct way to invoke 
> this hypercall?
> 
> If I call it like this, I receive an invalid parameter (EINVAL) error:
>      struct privcmd_hypercall
>      {
>          uint64_t op;
>          uint64_t arg[5];
>      } hypercall;
>      hypercall.op     = __HYPERVISOR_hvm_op;
>      hypercall.arg[0] = HVMOP_flush_tlbs;
>      hypercall.arg[1] = 0;
>      ret = do_xen_hypercall(xch, (void*)&hypercall);
> 
> 
> If I call it like this, I get function not implemented (ENOSYS), where 3 
> is a valid domain id:
>      hypercall.op     = __HYPERVISOR_hvm_op;
>      hypercall.arg[0] = HVMOP_flush_tlbs;
>      hypercall.arg[1] = 3;  /* 3 is the domain whose tlbs should be 
> flushed */
>      hypercall.arg[2] = 0;

Did you look at the code of Xen?  A quick grep finds this:

    case HVMOP_flush_tlbs:
        rc = guest_handle_is_null(arg) ? hvmop_flush_tlb_all() : -ENOSYS;
        break;

So that's what "@arg must ne null" means: if you provide an argument,
you get ENOSYS.  And just inside hvmop_flush_tlb_all() is this:

    if ( !is_hvm_domain(d) )
        return -EINVAL;

So if you call from a non-HVM domain, you get EINVAL.  That matches what
you're seeing. 

I think the important detail is that HVMOP_flush_tlbs doesn't take a target
domain - it always flushes the _caller's_ TLBs.  I guess you want to
flush the TLBs of another domain for some reason?  AFAICS the version in
mainline Xen has never taken an argument so perhaps you could add one
(making sure to keep backward compatibility, of course).

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:12:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:12:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6xr-0006Ul-KQ; Tue, 17 Jan 2012 11:12: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 1Rn6xq-0006UT-TT
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:12:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326798744!9447465!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 30622 invoked from network); 17 Jan 2012 11:12:24 -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; 17 Jan 2012 11:12:24 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rn6xj-0001xl-2J; Tue, 17 Jan 2012 11:12:23 +0000
Date: Tue, 17 Jan 2012 11:12:22 +0000
From: Tim Deegan <tim@xen.org>
To: Study Xen <studyxen@gmail.com>
Message-ID: <20120117111222.GC74654@ocelot.phlegethon.org>
References: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] unable to capture an expected page fault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 03:08 -0500 on 17 Jan (1326769684), Study Xen wrote:
> I was trying to modify part of Xen and faced a page fault missing issue.
> 
> I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only
> domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux
> kernel's "native_set_pte" in "arch/x86/include/asm/pgtable_64.h" traps into
> Xen due to Xen's write-protection of the pagetable page. But in our
> modified version, this expected page fault seems missing.

Well, I suppose it must be something you changed. :)  But since you don't
say what you changed I'm not sure how much we can help you.  If the
pagetables are indeed correct then maybe you're missing a TLB flush
somewhere?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:12:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:12:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn6xr-0006Ul-KQ; Tue, 17 Jan 2012 11:12: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 1Rn6xq-0006UT-TT
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:12:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326798744!9447465!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 30622 invoked from network); 17 Jan 2012 11:12:24 -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; 17 Jan 2012 11:12:24 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rn6xj-0001xl-2J; Tue, 17 Jan 2012 11:12:23 +0000
Date: Tue, 17 Jan 2012 11:12:22 +0000
From: Tim Deegan <tim@xen.org>
To: Study Xen <studyxen@gmail.com>
Message-ID: <20120117111222.GC74654@ocelot.phlegethon.org>
References: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] unable to capture an expected page fault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 

At 03:08 -0500 on 17 Jan (1326769684), Study Xen wrote:
> I was trying to modify part of Xen and faced a page fault missing issue.
> 
> I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only
> domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux
> kernel's "native_set_pte" in "arch/x86/include/asm/pgtable_64.h" traps into
> Xen due to Xen's write-protection of the pagetable page. But in our
> modified version, this expected page fault seems missing.

Well, I suppose it must be something you changed. :)  But since you don't
say what you changed I'm not sure how much we can help you.  If the
pagetables are indeed correct then maybe you're missing a TLB flush
somewhere?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:17:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn72w-0006oa-UN; Tue, 17 Jan 2012 11:17:46 +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 1Rn72v-0006o9-Lr
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:17:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326799059!11217749!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 14665 invoked from network); 17 Jan 2012 11:17:39 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 11:17:39 -0000
Received: by werh12 with SMTP id h12so1223494wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 03:17:39 -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=qm9uF8qSYf+Q0PXFF9ZSLYIlCOAf0FRwYoruvArs8cg=;
	b=Tk33Gzn/KBmtDHh9b3q+uLHKz8uesRclvuzPZADj/4/5Pjq00lViO5K45ybpMEhW34
	sNd1aI5nLoC+bZt8BuDYnKJGWO59EfWNEPCtAQmWDLNOvW90uBpGpj2XnpvGjjVImCGu
	shJNnfakOmmRUbim1CCaEWoJEU2e1XLIE8vG8=
Received: by 10.216.137.149 with SMTP id y21mr6409213wei.38.1326799059263;
	Tue, 17 Jan 2012 03:17:39 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dr7sm13032559wib.3.2012.01.17.03.17.37
	(version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 03:17:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Jan 2012 11:17:35 +0000
From: Keir Fraser <keir@xen.org>
To: Dario Faggioli <raistlin@linux.it>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3B094F.379B1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCHv2 2 of 2] Move IOMMU faults handling into
	softirq for AMD-Vi.
Thread-Index: AczVCZzc4JtY+gxe7kSV9XS5lgTYtA==
In-Reply-To: <1325777220.2728.11.camel@Solace>
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: Re: [Xen-devel] [PATCHv2 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 05/01/2012 15:27, "Dario Faggioli" <raistlin@linux.it> wrote:

> Dealing with interrupts from AMD-Vi IOMMU(s) 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>

This patch needs fixing to apply to xen-unstable tip. Please do that and
resubmit.

 -- Keir

> diff -r 3cb587bb34d0 xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c Thu Jan 05 15:12:35 2012 +0100
> +++ b/xen/drivers/passthrough/amd/iommu_init.c Thu Jan 05 15:14:03 2012 +0100
> @@ -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,45 @@ 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 ( !iommu_found() )
> +    {
> +        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 IOMMUs) 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 +923,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 Jan 17 11:17:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:17:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn72w-0006oa-UN; Tue, 17 Jan 2012 11:17:46 +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 1Rn72v-0006o9-Lr
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:17:45 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326799059!11217749!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 14665 invoked from network); 17 Jan 2012 11:17:39 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 11:17:39 -0000
Received: by werh12 with SMTP id h12so1223494wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 03:17:39 -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=qm9uF8qSYf+Q0PXFF9ZSLYIlCOAf0FRwYoruvArs8cg=;
	b=Tk33Gzn/KBmtDHh9b3q+uLHKz8uesRclvuzPZADj/4/5Pjq00lViO5K45ybpMEhW34
	sNd1aI5nLoC+bZt8BuDYnKJGWO59EfWNEPCtAQmWDLNOvW90uBpGpj2XnpvGjjVImCGu
	shJNnfakOmmRUbim1CCaEWoJEU2e1XLIE8vG8=
Received: by 10.216.137.149 with SMTP id y21mr6409213wei.38.1326799059263;
	Tue, 17 Jan 2012 03:17:39 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dr7sm13032559wib.3.2012.01.17.03.17.37
	(version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 03:17:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Jan 2012 11:17:35 +0000
From: Keir Fraser <keir@xen.org>
To: Dario Faggioli <raistlin@linux.it>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3B094F.379B1%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCHv2 2 of 2] Move IOMMU faults handling into
	softirq for AMD-Vi.
Thread-Index: AczVCZzc4JtY+gxe7kSV9XS5lgTYtA==
In-Reply-To: <1325777220.2728.11.camel@Solace>
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: Re: [Xen-devel] [PATCHv2 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 05/01/2012 15:27, "Dario Faggioli" <raistlin@linux.it> wrote:

> Dealing with interrupts from AMD-Vi IOMMU(s) 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>

This patch needs fixing to apply to xen-unstable tip. Please do that and
resubmit.

 -- Keir

> diff -r 3cb587bb34d0 xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c Thu Jan 05 15:12:35 2012 +0100
> +++ b/xen/drivers/passthrough/amd/iommu_init.c Thu Jan 05 15:14:03 2012 +0100
> @@ -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,45 @@ 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 ( !iommu_found() )
> +    {
> +        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 IOMMUs) 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 +923,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 Jan 17 11:18:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11: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 1Rn72t-0006oG-I8; Tue, 17 Jan 2012 11:17:43 +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 1Rn72r-0006o6-SR
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:17:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326799055!11201968!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 2382 invoked from network); 17 Jan 2012 11:17:35 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 11:17:35 -0000
Received: by wibhj8 with SMTP id hj8so11625273wib.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 03:17:35 -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=Eh1r5kuzvlfm0spRxHjM5KB3z75f7WSznf9K7YvMVHI=;
	b=YR1xxo7PilnC7+tr6VoQ+8NNJMLB1CJHggzJUGD5TgqG2C/5iIFPKELoEpuyb9uLKb
	IgOcTsDCZJUMZeGkdfT08ycoW04nW2Dx0aTS+U9Og224ZmAM+UIA2g6WQif/7PhG3qST
	W9UySBIoLrHpNEbboxLH3SPya07R6KL82jcp0=
Received: by 10.180.84.163 with SMTP id a3mr33759427wiz.3.1326799055448;
	Tue, 17 Jan 2012 03:17:35 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dr7sm13032559wib.3.2012.01.17.03.17.32
	(version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 03:17:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Jan 2012 11:17:13 +0000
From: Keir Fraser <keir@xen.org>
To: Dario Faggioli <raistlin@linux.it>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3B0939.379B0%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCHv2 1 of 2] Move IOMMU faults handling into
	softirq for VT-d.
Thread-Index: AczVCY+/g7WzCUhZaUOTImMLX/cSNw==
In-Reply-To: <1325777149.2728.9.camel@Solace>
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: Re: [Xen-devel] [PATCHv2 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: text/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/01/2012 15:25, "Dario Faggioli" <raistlin@linux.it> wrote:

> Dealing with interrupts from VT-d IOMMU(s) 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 of 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>

Applied, thanks.

 -- Keir

> diff -r efaa28639a71 xen/drivers/passthrough/vtd/iommu.c
> --- a/xen/drivers/passthrough/vtd/iommu.c Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/drivers/passthrough/vtd/iommu.c Thu Jan 05 15:17:47 2012 +0100
> @@ -53,6 +53,8 @@ bool_t __read_mostly untrusted_msi;
>  
>  int nr_iommus;
>  
> +static struct tasklet vtd_fault_tasklet;
> +
>  static void setup_dom0_device(struct pci_dev *);
>  static void setup_dom0_rmrr(struct domain *d);
>  
> @@ -918,10 +920,8 @@ static void iommu_fault_status(u32 fault
>  }
>  
>  #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 = dev_id;
>      int reg, fault_index;
>      u32 fault_status;
>      unsigned long flags;
> @@ -996,6 +996,37 @@ clear_overflow:
>      }
>  }
>  
> +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 IOMMUs) 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 = desc->action->dev_id;
> @@ -2144,6 +2175,8 @@ int __init intel_vtd_setup(void)
>          iommu->irq = ret;
>      }
>  
> +    softirq_tasklet_init(&vtd_fault_tasklet, do_iommu_page_fault, 0);
> +
>      if ( !iommu_qinval && iommu_intremap )
>      {
>          iommu_intremap = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:18:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11: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 1Rn72t-0006oG-I8; Tue, 17 Jan 2012 11:17:43 +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 1Rn72r-0006o6-SR
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:17:42 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326799055!11201968!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 2382 invoked from network); 17 Jan 2012 11:17:35 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 11:17:35 -0000
Received: by wibhj8 with SMTP id hj8so11625273wib.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 03:17:35 -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=Eh1r5kuzvlfm0spRxHjM5KB3z75f7WSznf9K7YvMVHI=;
	b=YR1xxo7PilnC7+tr6VoQ+8NNJMLB1CJHggzJUGD5TgqG2C/5iIFPKELoEpuyb9uLKb
	IgOcTsDCZJUMZeGkdfT08ycoW04nW2Dx0aTS+U9Og224ZmAM+UIA2g6WQif/7PhG3qST
	W9UySBIoLrHpNEbboxLH3SPya07R6KL82jcp0=
Received: by 10.180.84.163 with SMTP id a3mr33759427wiz.3.1326799055448;
	Tue, 17 Jan 2012 03:17:35 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dr7sm13032559wib.3.2012.01.17.03.17.32
	(version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 03:17:34 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 17 Jan 2012 11:17:13 +0000
From: Keir Fraser <keir@xen.org>
To: Dario Faggioli <raistlin@linux.it>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3B0939.379B0%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCHv2 1 of 2] Move IOMMU faults handling into
	softirq for VT-d.
Thread-Index: AczVCY+/g7WzCUhZaUOTImMLX/cSNw==
In-Reply-To: <1325777149.2728.9.camel@Solace>
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: Re: [Xen-devel] [PATCHv2 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: text/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/01/2012 15:25, "Dario Faggioli" <raistlin@linux.it> wrote:

> Dealing with interrupts from VT-d IOMMU(s) 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 of 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>

Applied, thanks.

 -- Keir

> diff -r efaa28639a71 xen/drivers/passthrough/vtd/iommu.c
> --- a/xen/drivers/passthrough/vtd/iommu.c Wed Jan 04 16:12:44 2012 +0000
> +++ b/xen/drivers/passthrough/vtd/iommu.c Thu Jan 05 15:17:47 2012 +0100
> @@ -53,6 +53,8 @@ bool_t __read_mostly untrusted_msi;
>  
>  int nr_iommus;
>  
> +static struct tasklet vtd_fault_tasklet;
> +
>  static void setup_dom0_device(struct pci_dev *);
>  static void setup_dom0_rmrr(struct domain *d);
>  
> @@ -918,10 +920,8 @@ static void iommu_fault_status(u32 fault
>  }
>  
>  #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 = dev_id;
>      int reg, fault_index;
>      u32 fault_status;
>      unsigned long flags;
> @@ -996,6 +996,37 @@ clear_overflow:
>      }
>  }
>  
> +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 IOMMUs) 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 = desc->action->dev_id;
> @@ -2144,6 +2175,8 @@ int __init intel_vtd_setup(void)
>          iommu->irq = ret;
>      }
>  
> +    softirq_tasklet_init(&vtd_fault_tasklet, do_iommu_page_fault, 0);
> +
>      if ( !iommu_qinval && iommu_intremap )
>      {
>          iommu_intremap = 0;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:27:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn7CM-00078m-Px; Tue, 17 Jan 2012 11:27: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 1Rn7CL-00078U-7I
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:27:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326799642!8831816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10375 invoked from network); 17 Jan 2012 11:27:23 -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;
	17 Jan 2012 11:27:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10080929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 11:26: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, 17 Jan 2012 11:26:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 11:26:49 +0000
In-Reply-To: <20244.20465.336196.143853@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
	<20244.19890.395440.528682@mariner.uk.xensource.com>
	<1326731120.14689.21.camel@zakaz.uk.xensource.com>
	<20244.20465.336196.143853@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326799609.14689.101.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 29 of 32 RFC] libxl: add named enum for
 timer	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:27 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer	mode"):
> > I'm happy to take either approach to be honest. I imagine most _init
> > functions will turn into just a memset anyway at which point maybe we
> > should just ditch them.
> > 
> > I'd rather either all data types had an init or none is my only real
> > feeling on the matter.
> 
> I absolutely agree.  (The init function could be autogenerated.)

OK, I shall arrange that each type libxl_FOO has a libxl_FOO_init which
cannot fail and which is (normally) generated from the IDL. Likewise I
will arrange for a libxl_FOO_setdefaults which can fail.

This gives us the freedom to have non-zero representation for the
default on a per-type or per-field exceptional basis.

This will however make this series even larger...

> > > we could decree that all-bits-set means "use default value".
> > 
> > Do you mean in genral or just this specific field?
> 
> In general.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 11:27:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 11:27:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn7CM-00078m-Px; Tue, 17 Jan 2012 11:27: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 1Rn7CL-00078U-7I
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:27:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326799642!8831816!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10375 invoked from network); 17 Jan 2012 11:27:23 -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;
	17 Jan 2012 11:27:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10080929"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 11:26: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, 17 Jan 2012 11:26:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 11:26:49 +0000
In-Reply-To: <20244.20465.336196.143853@mariner.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<feeea78c60ef4a0ec5d4.1326716127@cosworth.uk.xensource.com>
	<20244.19890.395440.528682@mariner.uk.xensource.com>
	<1326731120.14689.21.camel@zakaz.uk.xensource.com>
	<20244.20465.336196.143853@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326799609.14689.101.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 29 of 32 RFC] libxl: add named enum for
 timer	mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 16:27 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 29 of 32 RFC] libxl: add named enum for timer	mode"):
> > I'm happy to take either approach to be honest. I imagine most _init
> > functions will turn into just a memset anyway at which point maybe we
> > should just ditch them.
> > 
> > I'd rather either all data types had an init or none is my only real
> > feeling on the matter.
> 
> I absolutely agree.  (The init function could be autogenerated.)

OK, I shall arrange that each type libxl_FOO has a libxl_FOO_init which
cannot fail and which is (normally) generated from the IDL. Likewise I
will arrange for a libxl_FOO_setdefaults which can fail.

This gives us the freedom to have non-zero representation for the
default on a per-type or per-field exceptional basis.

This will however make this series even larger...

> > > we could decree that all-bits-set means "use default value".
> > 
> > Do you mean in genral or just this specific field?
> 
> In general.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 12:41:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 12:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8Lg-0000Tx-Hr; Tue, 17 Jan 2012 12:41: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 1Rn8Le-0000Tp-FK
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 12:41:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326804063!9488523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15783 invoked from network); 17 Jan 2012 12:41:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 12:41:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10082732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 12:41:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 12:41: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
	1Rn8LX-0004H1-2g; Tue, 17 Jan 2012 12:41:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rn8LX-0001tD-0q;
	Tue, 17 Jan 2012 12:41:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20245.27743.4276.395435@mariner.uk.xensource.com>
Date: Tue, 17 Jan 2012 12:41:03 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <37b60f1b74641ba9e100.1326798297@fountains-ubuntu>
References: <37b60f1b74641ba9e100.1326798297@fountains-ubuntu>
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 missing gate for HVM 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

Paul Durrant writes ("[Xen-devel] [PATCH] Add missing gate for HVM domain"):
> Add missing gate for HVM domain.
> 
> This will fix localhost migrate failures found by the automatic tests.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

Applied, 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 Jan 17 12:41:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 12:41:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8Lg-0000Tx-Hr; Tue, 17 Jan 2012 12:41: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 1Rn8Le-0000Tp-FK
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 12:41:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326804063!9488523!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15783 invoked from network); 17 Jan 2012 12:41:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 12:41:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,522,1320624000"; d="scan'208";a="10082732"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 12:41:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 12:41: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
	1Rn8LX-0004H1-2g; Tue, 17 Jan 2012 12:41:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rn8LX-0001tD-0q;
	Tue, 17 Jan 2012 12:41:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20245.27743.4276.395435@mariner.uk.xensource.com>
Date: Tue, 17 Jan 2012 12:41:03 +0000
To: Paul Durrant <paul.durrant@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <37b60f1b74641ba9e100.1326798297@fountains-ubuntu>
References: <37b60f1b74641ba9e100.1326798297@fountains-ubuntu>
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 missing gate for HVM 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

Paul Durrant writes ("[Xen-devel] [PATCH] Add missing gate for HVM domain"):
> Add missing gate for HVM domain.
> 
> This will fix localhost migrate failures found by the automatic tests.
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

Applied, 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 Jan 17 12:53:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 12:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8X8-0000mm-6E; Tue, 17 Jan 2012 12:53:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Antony.Saba@mandiant.com>) id 1Rn8X7-0000mh-Ew
	for xen-devel@lists.xen.org; Tue, 17 Jan 2012 12:53:01 +0000
X-Env-Sender: Antony.Saba@mandiant.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326804774!10780661!1
X-Originating-IP: [165.212.64.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTY1LjIxMi42NC4yNSA9PiAxNDk0MjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26505 invoked from network); 17 Jan 2012 12:52:55 -0000
Received: from gateout03.mbox.net (HELO gateout03.mbox.net) (165.212.64.25)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 12:52:55 -0000
Received: from gateout03.mbox.net (localhost.localdomain [127.0.0.1])
	by gateout03.mbox.net (Postfix) with ESMTP id BE0E6E003D45;
	Tue, 17 Jan 2012 12:52:53 +0000 (GMT)
X-USANET-Received: from gateout03.mbox.net [127.0.0.1] by gateout03.mbox.net
	via mtad (C8.MAIN.3.75Z) 
	with ESMTP id 103qaqm110864Mo3; Tue, 17 Jan 2012 12:52:52 -0000
Received: from S1HUB5.EXCHPROD.USA.NET [165.212.120.254] by gateout03.mbox.net
	via smtad (C8.MAIN.3.75S) 
	with ESMTPS id XID635qaqm116749Xo3; Tue, 17 Jan 2012 12:52:52 -0000
X-USANET-Source: 165.212.120.254 IN Antony.Saba@mandiant.com
	S1HUB5.EXCHPROD.USA.NET
X-USANET-MsgId: XID635qaqm116749Xo3
Received: from MBX3.EXCHPROD.USA.NET ([10.120.221.31]) by
	S1HUB5.EXCHPROD.USA.NET ([10.120.220.35]) with mapi; Tue, 17 Jan 2012
	12:52:18 +0000
From: Antony Saba <Antony.Saba@mandiant.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 17 Jan 2012 12:52:15 +0000
Thread-Topic: [Xen-devel] Problems calling HVMOP_flush_tlbs
Thread-Index: AczVFtguqTFUK/YYR8+dh5OjktmFzQ==
Message-ID: <4F156EFF.6010800@mandiant.com>
References: <4F14C5B9.9080501@mandiant.com>
	<20120117110840.GB74654@ocelot.phlegethon.org>
In-Reply-To: <20120117110840.GB74654@ocelot.phlegethon.org>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222
	Thunderbird/9.0.1
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems calling HVMOP_flush_tlbs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1008483540462182968=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1008483540462182968==
Content-Type: multipart/alternative;
	boundary="_000_4F156EFF6010800mandiantcom_"

--_000_4F156EFF6010800mandiantcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 01/17/2012 04:08 AM, Tim Deegan wrote

I think the important detail is that HVMOP_flush_tlbs doesn't take a target
domain - it always flushes the _caller's_ TLBs.  I guess you want to
flush the TLBs of another domain for some reason?  AFAICS the version in
mainline Xen has never taken an argument so perhaps you could add one
(making sure to keep backward compatibility, of course).



Thanks, Tim.

Yes, I am trying flush a guests TLBs from dom0.  I am using mem_events, and=
 are seeing events that are not caught all the time.  The difference appear=
s to be that the guest does a mov cr3 in the case where they are caught.

I was hoping it was a simple matter of flushing the guest TLBs somehow.

-Tony


--
Antony Saba, antony.saba@mandiant.com<mailto:antony.saba@mandiant.com>

--_000_4F156EFF6010800mandiantcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
   =20
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    On 01/17/2012 04:08 AM, Tim Deegan wrote<br>
    <blockquote cite=3D"mid:20120117110840.GB74654@ocelot.phlegethon.org"
      type=3D"cite">
      <p><font size=3D"2">
          I think the important detail is that HVMOP_flush_tlbs doesn't
          take a target<br>
          domain - it always flushes the _caller's_ TLBs.&nbsp; I guess you
          want to<br>
          flush the TLBs of another domain for some reason?&nbsp; AFAICS th=
e
          version in<br>
          mainline Xen has never taken an argument so perhaps you could
          add one<br>
          (making sure to keep backward compatibility, of course).<br>
          <br>
          <br>
        </font></p>
    </blockquote>
    Thanks, Tim.<br>
    <br>
    Yes, I am trying flush a guests TLBs from dom0.&nbsp; I am using
    mem_events, and are seeing events that are not caught all the time.&nbs=
p;
    The difference appears to be that the guest does a mov cr3 in the
    case where they are caught.<br>
    <br>
    I was hoping it was a simple matter of flushing the guest TLBs
    somehow.<br>
    <br>
    -Tony<br>
    <br>
    <pre class=3D"moz-signature" cols=3D"72">--=20
Antony Saba, <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:antony.sa=
ba@mandiant.com">antony.saba@mandiant.com</a></pre>
  </body>
</html>

--_000_4F156EFF6010800mandiantcom_--


--===============1008483540462182968==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1008483540462182968==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 12:53:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 12:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8X8-0000mm-6E; Tue, 17 Jan 2012 12:53:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Antony.Saba@mandiant.com>) id 1Rn8X7-0000mh-Ew
	for xen-devel@lists.xen.org; Tue, 17 Jan 2012 12:53:01 +0000
X-Env-Sender: Antony.Saba@mandiant.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326804774!10780661!1
X-Originating-IP: [165.212.64.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTY1LjIxMi42NC4yNSA9PiAxNDk0MjI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26505 invoked from network); 17 Jan 2012 12:52:55 -0000
Received: from gateout03.mbox.net (HELO gateout03.mbox.net) (165.212.64.25)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 12:52:55 -0000
Received: from gateout03.mbox.net (localhost.localdomain [127.0.0.1])
	by gateout03.mbox.net (Postfix) with ESMTP id BE0E6E003D45;
	Tue, 17 Jan 2012 12:52:53 +0000 (GMT)
X-USANET-Received: from gateout03.mbox.net [127.0.0.1] by gateout03.mbox.net
	via mtad (C8.MAIN.3.75Z) 
	with ESMTP id 103qaqm110864Mo3; Tue, 17 Jan 2012 12:52:52 -0000
Received: from S1HUB5.EXCHPROD.USA.NET [165.212.120.254] by gateout03.mbox.net
	via smtad (C8.MAIN.3.75S) 
	with ESMTPS id XID635qaqm116749Xo3; Tue, 17 Jan 2012 12:52:52 -0000
X-USANET-Source: 165.212.120.254 IN Antony.Saba@mandiant.com
	S1HUB5.EXCHPROD.USA.NET
X-USANET-MsgId: XID635qaqm116749Xo3
Received: from MBX3.EXCHPROD.USA.NET ([10.120.221.31]) by
	S1HUB5.EXCHPROD.USA.NET ([10.120.220.35]) with mapi; Tue, 17 Jan 2012
	12:52:18 +0000
From: Antony Saba <Antony.Saba@mandiant.com>
To: Tim Deegan <tim@xen.org>
Date: Tue, 17 Jan 2012 12:52:15 +0000
Thread-Topic: [Xen-devel] Problems calling HVMOP_flush_tlbs
Thread-Index: AczVFtguqTFUK/YYR8+dh5OjktmFzQ==
Message-ID: <4F156EFF.6010800@mandiant.com>
References: <4F14C5B9.9080501@mandiant.com>
	<20120117110840.GB74654@ocelot.phlegethon.org>
In-Reply-To: <20120117110840.GB74654@ocelot.phlegethon.org>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222
	Thunderbird/9.0.1
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Xen-devel] Problems calling HVMOP_flush_tlbs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1008483540462182968=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1008483540462182968==
Content-Type: multipart/alternative;
	boundary="_000_4F156EFF6010800mandiantcom_"

--_000_4F156EFF6010800mandiantcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 01/17/2012 04:08 AM, Tim Deegan wrote

I think the important detail is that HVMOP_flush_tlbs doesn't take a target
domain - it always flushes the _caller's_ TLBs.  I guess you want to
flush the TLBs of another domain for some reason?  AFAICS the version in
mainline Xen has never taken an argument so perhaps you could add one
(making sure to keep backward compatibility, of course).



Thanks, Tim.

Yes, I am trying flush a guests TLBs from dom0.  I am using mem_events, and=
 are seeing events that are not caught all the time.  The difference appear=
s to be that the guest does a mov cr3 in the case where they are caught.

I was hoping it was a simple matter of flushing the guest TLBs somehow.

-Tony


--
Antony Saba, antony.saba@mandiant.com<mailto:antony.saba@mandiant.com>

--_000_4F156EFF6010800mandiantcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
   =20
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    On 01/17/2012 04:08 AM, Tim Deegan wrote<br>
    <blockquote cite=3D"mid:20120117110840.GB74654@ocelot.phlegethon.org"
      type=3D"cite">
      <p><font size=3D"2">
          I think the important detail is that HVMOP_flush_tlbs doesn't
          take a target<br>
          domain - it always flushes the _caller's_ TLBs.&nbsp; I guess you
          want to<br>
          flush the TLBs of another domain for some reason?&nbsp; AFAICS th=
e
          version in<br>
          mainline Xen has never taken an argument so perhaps you could
          add one<br>
          (making sure to keep backward compatibility, of course).<br>
          <br>
          <br>
        </font></p>
    </blockquote>
    Thanks, Tim.<br>
    <br>
    Yes, I am trying flush a guests TLBs from dom0.&nbsp; I am using
    mem_events, and are seeing events that are not caught all the time.&nbs=
p;
    The difference appears to be that the guest does a mov cr3 in the
    case where they are caught.<br>
    <br>
    I was hoping it was a simple matter of flushing the guest TLBs
    somehow.<br>
    <br>
    -Tony<br>
    <br>
    <pre class=3D"moz-signature" cols=3D"72">--=20
Antony Saba, <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:antony.sa=
ba@mandiant.com">antony.saba@mandiant.com</a></pre>
  </body>
</html>

--_000_4F156EFF6010800mandiantcom_--


--===============1008483540462182968==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1008483540462182968==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:02:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8g3-0000yS-7Y; Tue, 17 Jan 2012 13:02:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1Rn8g1-0000yN-H8
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:02:14 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326805284!48918496!1
X-Originating-IP: [209.85.210.193]
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 16038 invoked from network); 17 Jan 2012 13:01:25 -0000
Received: from mail-iy0-f193.google.com (HELO mail-iy0-f193.google.com)
	(209.85.210.193)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:01:25 -0000
Received: by iabz21 with SMTP id z21so162296iab.0
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 05:02:10 -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=AGWG34G5llcr5mAIY8iSzgJ5XtmLqNX9L5Pq6rh8J0c=;
	b=fvxCQ7gEqnESghVIGJnP8Bf0bJuh5BfYjx83kGZXG9X4vQsiw9e/Dxy9uIeG47D8RM
	S3VCUyNig+YBSJOmai5Lq9Btg5l4SIEJwxkaEo9iz1gylWJc6trlbAKPWGrsAgMY9caU
	skl0wEFyMWYG81972+fX7gTQv0LNXUvpPeKWU=
MIME-Version: 1.0
Received: by 10.50.156.130 with SMTP id we2mr17491515igb.10.1326805329096;
	Tue, 17 Jan 2012 05:02:09 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Tue, 17 Jan 2012 05:02:09 -0800 (PST)
In-Reply-To: <CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
References: <CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
Date: Tue, 17 Jan 2012 14:02:09 +0100
Message-ID: <CAFoWEVPww5rA96qvApmpV9+jkDxmm1BXkXddvf8in8AhaoPcmA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Available PCIe lanes for VGA 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: multipart/mixed; boundary="===============4887586873585106406=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4887586873585106406==
Content-Type: multipart/alternative; boundary=e89a8f2357ff53b01904b6b8f01b

--e89a8f2357ff53b01904b6b8f01b
Content-Type: text/plain; charset=ISO-8859-1

Hello everyone,

Looks like my initial email to xen-devel did not get delivered or
something...
Please see it below this email.

Okay, here is some info about my system:

lspci | grep -i vga
03:00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce GTX
480] (rev a3)
06:04.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM450
(rev 0a)


lspci | grep -i 03:00
03:00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce GTX
480] (rev a3)
03:00.1 Audio device: nVidia Corporation GF100 High Definition Audio
Controller (rev a1)


dmesg | grep -i 03:00
[    0.000000] Command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    5.114443] Kernel command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    5.356290] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300
[    5.356310] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9ffffff]
[    5.356332] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0xdfffffff 64bit
pref]
[    5.356353] pci 0000:03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64bit
pref]
[    5.356368] pci 0000:03:00.0: reg 24: [io  0xdc00-0xdc7f]
[    5.356383] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaefffff pref]
[    5.356475] pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403
[    5.356494] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]
[    5.425416] vgaarb: device added:
PCI:0000:03:00.0,decodes=io+mem,owns=none,locks=none
[    5.425438] vgaarb: bridge control possible 0000:03:00.0
[    5.443721] pciback 0000:03:00.0: seizing device
[    5.443726] pciback 0000:03:00.1: seizing device
[    5.713088] pciback 0000:03:00.0: Signaling PME through PCIe PME
interrupt
[    5.713090] pciback 0000:03:00.1: Signaling PME through PCIe PME
interrupt
[    5.713566] pciback 0000:03:00.1: PCI INT B -> GSI 25 (level, low) ->
IRQ 25
[    5.713574] pciback 0000:03:00.1: PCI INT B disabled
[    5.713610] pciback 0000:03:00.0: enabling device (0146 -> 0147)
[    5.713627] pciback 0000:03:00.0: PCI INT A -> GSI 26 (level, low) ->
IRQ 26
[    5.713633] pciback 0000:03:00.0: PCI INT A disabled


xl pci-list-assignable-devices
0000:03:00.0
0000:03:00.1


cat /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="nomodeset xen-pciback.passthrough=1
xen-pciback.permissive xen-pciback.hide=(03:00.0)(03:00.1)"
GRUB_DISABLE_OS_PROBER=true
GRUB_CMDLINE_XEN="dom0_mem=1G"


>From all that, I assume that the VGA card, and its on-board audio device,
is owned by pciback.


This is how I start the domain:
xl create xenwinxp.cfg
Parsing config file xenwinxp.cfg
WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override"
instead if you really want a non-default firmware
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001819b4
  TOTAL:         0000000000000000->00000000bf800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000001
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
Daemon running with PID 3001

Quick confirmation that it is up and running:
xl list
Name                                        ID   Mem VCPUs State Time(s)
Domain-0                                     0  1024    12     r-----
255.7
winxp                                        1  3067     4     -b----
 61.2

This is my xen config file:
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 3072
# shadow_memory = 1024
name = "winxp"
vcpus='4'
vif = [ 'bridge=eth0,mac=00:14:3e:00:8f:c2' ]
disk =
['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/winxp.iso,hdc:cdrom,r']
boot="cd"
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncconsole=1
vncpasswd=''
acpi=1
apic=1
xen_extended_power_mgmt=1
pae=1
arch='x86_64'
hpet = 1
hap = 1
viridian = 1
monitor=1
serial='pty'
# keymap='fr'
# soundhw = "all"
# audio="on"
ne2000=0
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
xen_platform_pci=1
gfx_passthru=0
pci  = [ "03:00.0,msitranslate=1,power_mgmt=1" ]
acpi_s3 = 1
acpi_s4 = 1


The Windows XP boots up fine, I can see the GTX480 in the device manager,
but it is not useable.

 Now, let me try gfx_passthru=1

Create the domain:
xl create xenwinxp.cfg
Parsing config file xenwinxp.cfg
WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override"
instead if you really want a non-default firmware
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001819b4
  TOTAL:         0000000000000000->00000000bf800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000001
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
Daemon running with PID 3454

When the domain starts, my dom0 screen attached to the 06:04.0 VGA
controller goes blank, and after a few seconds I get a message from my
monitor that 'this video format is not supported'. I can get back to my
dom0 by first going Ctrl-Alt-F1 (where I will see a whole bunch of garbage
in the screen) and then Ctrl-Alt-F7.

The domain is running:
xl list
Name                                        ID   Mem VCPUs State Time(s)
Domain-0                                     0  1024    12     r-----
385.3
winxp                                        3  3063     1     r-----
324.5

And if I check out what is happening through vncviewer, I see just the QEMU
console (QEMU 0.10.2 monitor - type 'help' for more information)

And finally, I see that the VGA card is no longer available:
xl pci-list-assignable-devices
0000:03:00.1


I have checked all three of the video cards outputs, no video signal
anywhere.


Any ideas about what could be causing the problems I am encountering?
I would be grateful for any info.

Thanks in advance.

Sandi





On Tue, Jan 17, 2012 at 11:10 AM, Sandi Romih <romihs.forums@gmail.com>wrote:

> Hello,
>
> I hope that I am posting the correct list with this question.
>
> I have been trying to get VGA passthrough working on my system for some
> time now without success.
> I do not have the system with me right now, so I will not be able to
> provide any logs or error messages right now. I will be able to to do so in
> a couple of hours.
>
> I have a VT-d enabled system (Motherboard and CPU) on which I wish to pass
> the secondary graphics card (EVGA GTX480 SE) through to the HVM (WinXP
> 32-bit).
> Currently I am testing with Debian Squeeze, using the 3.1.8 kernel and Xen
> 4.2.unstable according to these instructions:
> http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through
>
> I can only boot the WinXP client via the VNC console (gfx_passthrough=0),
> and from within WinXP I see that the OS has detected the GTX480 card (as
> its secondary card), but I am not able to use it. I have tried the 275.33
> drives, and they make no difference.
>
> My question is related to the number of PCIe lanes I have available to the
> graphics card.
> I only have 8 lanes available for the GTX480 (which is a PCIe x16 card),
> could this pose an issue for Xen?
>
>
> I plan to test VGA passthrough with an ATI graphics card (also in a PCIe
> x8 slot) later to see if it will work or not. I will update what I find.
>
> Regards
>
> Sandi
>

--e89a8f2357ff53b01904b6b8f01b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello everyone,<div><br></div><div>Looks like my initial email to xen-devel=
 did not get delivered or something...</div><div>Please see it below this e=
mail.</div><div><br></div><div>Okay, here is some info about my system:</di=
v>
<div><br></div><div><div>lspci | grep -i vga</div><div>03:00.0 VGA compatib=
le controller: nVidia Corporation GF100 [GeForce GTX 480] (rev a3)</div><di=
v>06:04.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM4=
50 (rev 0a)</div>
<div><br></div><div><br></div><div><div>lspci | grep -i 03:00</div><div>03:=
00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce GTX 480] =
(rev a3)</div><div>03:00.1 Audio device: nVidia Corporation GF100 High Defi=
nition Audio Controller (rev a1)</div>
</div><div><br></div><div><br></div><div><div>dmesg | grep -i 03:00</div><d=
iv>[ =A0 =A00.000000] Command line: placeholder root=3DUUID=3Dd5f5207b-d2aa=
-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.passthrough=3D1 xen-pcibac=
k.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet</div>
<div>[ =A0 =A05.114443] Kernel command line: placeholder root=3DUUID=3Dd5f5=
207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.passthrough=3D1 x=
en-pciback.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet</div><div=
>[ =A0 =A05.356290] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300</di=
v>
<div>[ =A0 =A05.356310] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9fffff=
f]</div><div>[ =A0 =A05.356332] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0=
xdfffffff 64bit pref]</div><div>[ =A0 =A05.356353] pci 0000:03:00.0: reg 1c=
: [mem 0xd4000000-0xd7ffffff 64bit pref]</div>
<div>[ =A0 =A05.356368] pci 0000:03:00.0: reg 24: [io =A00xdc00-0xdc7f]</di=
v><div>[ =A0 =A05.356383] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaeff=
fff pref]</div><div>[ =A0 =A05.356475] pci 0000:03:00.1: [10de:0be5] type 0=
 class 0x000403</div>
<div>[ =A0 =A05.356494] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7fff=
f]</div><div>[ =A0 =A05.425416] vgaarb: device added: PCI:0000:03:00.0,deco=
des=3Dio+mem,owns=3Dnone,locks=3Dnone</div><div>[ =A0 =A05.425438] vgaarb: =
bridge control possible 0000:03:00.0</div>
<div>[ =A0 =A05.443721] pciback 0000:03:00.0: seizing device</div><div>[ =
=A0 =A05.443726] pciback 0000:03:00.1: seizing device</div><div>[ =A0 =A05.=
713088] pciback 0000:03:00.0: Signaling PME through PCIe PME interrupt</div=
><div>[ =A0 =A05.713090] pciback 0000:03:00.1: Signaling PME through PCIe P=
ME interrupt</div>
<div>[ =A0 =A05.713566] pciback 0000:03:00.1: PCI INT B -&gt; GSI 25 (level=
, low) -&gt; IRQ 25</div><div>[ =A0 =A05.713574] pciback 0000:03:00.1: PCI =
INT B disabled</div><div>[ =A0 =A05.713610] pciback 0000:03:00.0: enabling =
device (0146 -&gt; 0147)</div>
<div>[ =A0 =A05.713627] pciback 0000:03:00.0: PCI INT A -&gt; GSI 26 (level=
, low) -&gt; IRQ 26</div><div>[ =A0 =A05.713633] pciback 0000:03:00.0: PCI =
INT A disabled</div></div><div><br></div><div><br></div><div><div>xl pci-li=
st-assignable-devices=A0</div>
<div>0000:03:00.0</div><div>0000:03:00.1</div></div><div><br></div><div><br=
></div><div><div>cat /etc/default/grub=A0</div><div>GRUB_DEFAULT=3D0</div><=
div>GRUB_TIMEOUT=3D5</div><div>GRUB_DISTRIBUTOR=3D`lsb_release -i -s 2&gt; =
/dev/null || echo Debian`</div>
<div>GRUB_CMDLINE_LINUX_DEFAULT=3D&quot;quiet&quot;</div><div>GRUB_CMDLINE_=
LINUX=3D&quot;nomodeset xen-pciback.passthrough=3D1 xen-pciback.permissive =
xen-pciback.hide=3D(03:00.0)(03:00.1)&quot;</div><div>GRUB_DISABLE_OS_PROBE=
R=3Dtrue</div>
<div>GRUB_CMDLINE_XEN=3D&quot;dom0_mem=3D1G&quot;</div></div><div><br></div=
><div><br></div><div>From all that, I assume that the VGA card, and its=A0o=
n-board=A0audio device, is owned by pciback.</div><div><br></div><div><br><=
/div>
<div>This is how I start the domain:</div><div><div>xl create xenwinxp.cfg=
=A0</div><div>Parsing config file xenwinxp.cfg</div><div>WARNING: ignoring =
&quot;kernel&quot; directive for HVM guest. Use &quot;firmware_override&quo=
t; instead if you really want a non-default firmware</div>
<div>xc: info: VIRTUAL MEMORY ARRANGEMENT:</div><div>=A0 Loader: =A0 =A0 =
=A0 =A00000000000100000-&gt;00000000001819b4</div><div>=A0 TOTAL: =A0 =A0 =
=A0 =A0 0000000000000000-&gt;00000000bf800000</div><div>=A0 ENTRY ADDRESS: =
0000000000100000</div>
<div>xc: info: PHYSICAL MEMORY ALLOCATION:</div><div>=A0 4KB PAGES: 0x00000=
00000000200</div><div>=A0 2MB PAGES: 0x00000000000003fb</div><div>=A0 1GB P=
AGES: 0x0000000000000001</div><div><font color=3D"#ff0000">libxl: error: li=
bxl_pci.c:776:libxl__device_pci_reset: The kernel doesn&#39;t support reset=
 from sysfs for PCI device 0000:03:00.0</font></div>
<div>Daemon running with PID 3001</div></div><div><br></div><div>Quick conf=
irmation that it is up and running:</div><div><div>xl list</div><div>Name =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0ID =A0 Mem VCPUs<span class=3D"Apple-tab-span" style=3D"white-space:pre=
">	</span>State<span class=3D"Apple-tab-span" style=3D"white-space:pre">	</=
span>Time(s)</div>
<div>Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 0 =A01024 =A0 =A012 =A0 =A0 r----- =A0 =A0 255.7</div><div>winx=
p =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A01 =A03067 =A0 =A0 4 =A0 =A0 -b---- =A0 =A0 =A061.2</div></div><div><=
br></div><div>This is my xen config file:</div>
<div><div>kernel =3D &quot;/usr/lib/xen/boot/hvmloader&quot;</div><div>buil=
der=3D&#39;hvm&#39;</div><div>memory =3D 3072</div><div># shadow_memory =3D=
 1024</div><div>name =3D &quot;winxp&quot;</div><div>vcpus=3D&#39;4&#39;</d=
iv><div>
vif =3D [ &#39;bridge=3Deth0,mac=3D00:14:3e:00:8f:c2&#39; ]</div><div>disk =
=3D [&#39;file:/xen-vms/winxp/xenwinxp.img,hda,w&#39;,&#39;file:/xen-vms/is=
os/winxp.iso,hdc:cdrom,r&#39;]</div><div>boot=3D&quot;cd&quot;</div><div>sd=
l=3D0</div>
<div>vnc=3D1</div><div>vnclisten=3D&quot;0.0.0.0&quot;</div><div>vncconsole=
=3D1</div><div>vncpasswd=3D&#39;&#39;</div><div>acpi=3D1</div><div>apic=3D1=
</div><div>xen_extended_power_mgmt=3D1</div><div>pae=3D1</div><div>arch=3D&=
#39;x86_64&#39;</div>
<div>hpet =3D 1</div><div>hap =3D 1</div><div>viridian =3D 1</div><div>moni=
tor=3D1</div><div>serial=3D&#39;pty&#39;</div><div># keymap=3D&#39;fr&#39;<=
/div><div># soundhw =3D &quot;all&quot;</div><div># audio=3D&quot;on&quot;<=
/div><div>ne2000=3D0</div>
<div>on_poweroff =3D &#39;destroy&#39;</div><div>on_reboot =A0 =3D &#39;res=
tart&#39;</div><div>on_crash =A0 =A0=3D &#39;restart&#39;</div><div>xen_pla=
tform_pci=3D1</div><div>gfx_passthru=3D0</div><div>pci =A0=3D [ &quot;03:00=
.0,msitranslate=3D1,power_mgmt=3D1&quot; ]</div>
<div>acpi_s3 =3D 1</div><div>acpi_s4 =3D 1</div></div><div><br></div><div><=
br></div><div>The Windows XP boots up fine, I can see the GTX480 in the dev=
ice manager, but it is not useable.</div><div><br></div><div>=A0Now, let me=
 try gfx_passthru=3D1</div>
<div><br></div><div>Create the domain:</div><div><div>xl create xenwinxp.cf=
g=A0</div><div>Parsing config file xenwinxp.cfg</div><div>WARNING: ignoring=
 &quot;kernel&quot; directive for HVM guest. Use &quot;firmware_override&qu=
ot; instead if you really want a non-default firmware</div>
<div>xc: info: VIRTUAL MEMORY ARRANGEMENT:</div><div>=A0 Loader: =A0 =A0 =
=A0 =A00000000000100000-&gt;00000000001819b4</div><div>=A0 TOTAL: =A0 =A0 =
=A0 =A0 0000000000000000-&gt;00000000bf800000</div><div>=A0 ENTRY ADDRESS: =
0000000000100000</div>
<div>xc: info: PHYSICAL MEMORY ALLOCATION:</div><div>=A0 4KB PAGES: 0x00000=
00000000200</div><div>=A0 2MB PAGES: 0x00000000000003fb</div><div>=A0 1GB P=
AGES: 0x0000000000000001</div><div>libxl: error: libxl_pci.c:776:libxl__dev=
ice_pci_reset: The kernel doesn&#39;t support reset from sysfs for PCI devi=
ce 0000:03:00.0</div>
<div>Daemon running with PID 3454</div></div><div><br></div><div>When the d=
omain starts, my dom0=A0screen=A0attached to the=A006:04.0 VGA controller g=
oes blank, and after a few seconds I get a message from my monitor that &#3=
9;this video format is not supported&#39;. I can get back to my dom0 by fir=
st going Ctrl-Alt-F1 (where I will see a whole bunch of garbage in the scre=
en) and then Ctrl-Alt-F7.</div>
<div><br></div><div>The domain is running:</div><div><div>xl list</div><div=
>Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0ID =A0 Mem VCPUs<span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre">	</span>State<span class=3D"Apple-tab-span" style=3D"white-space:p=
re">	</span>Time(s)</div>
<div>Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 0 =A01024 =A0 =A012 =A0 =A0 r----- =A0 =A0 385.3</div><div>winx=
p =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A03 =A03063 =A0 =A0 1 =A0 =A0 r----- =A0 =A0 324.5</div></div><div><br=
></div><div>And if I check out what is happening through vncviewer, I see j=
ust the QEMU console (QEMU 0.10.2 monitor - type &#39;help&#39; for more in=
formation)</div>
<div><br></div><div>And=A0finally, I see that the VGA card is no longer ava=
ilable:</div><div><div>xl pci-list-assignable-devices=A0</div><div>0000:03:=
00.1</div></div><div><br></div><div><br></div><div>I have checked all three=
 of the video cards outputs, no video signal anywhere.</div>
<div><br></div><div><br></div><div>Any ideas about what could be causing th=
e=A0problems=A0I am encountering?</div><div>I would be grateful for any inf=
o.</div><div><br></div><div>Thanks in advance.</div><div><br></div><div>San=
di</div>
<div><br></div><div><br></div><div><br></div><div><br></div><br><div class=
=3D"gmail_quote">On Tue, Jan 17, 2012 at 11:10 AM, Sandi Romih <span dir=3D=
"ltr">&lt;<a href=3D"mailto:romihs.forums@gmail.com">romihs.forums@gmail.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hello,<div><br></div><div>I hope that I am p=
osting the correct list with this question.</div><div><br></div><div>I have=
 been trying to get VGA passthrough working on my system for some time now =
without success.</div>
<div>I do not have the system with me right now, so I will not be able to p=
rovide any logs or error messages right now. I will be able to to do so in =
a couple of hours.</div>
<div><br></div><div>I have a VT-d enabled system (Motherboard and CPU) on w=
hich I wish to pass the secondary graphics card (EVGA GTX480 SE) through to=
 the HVM (WinXP 32-bit).</div><div>Currently I am testing with Debian Squee=
ze, using the 3.1.8 kernel and Xen 4.2.unstable according to these instruct=
ions:=A0<a href=3D"http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen=
-42unstable-patches-for-vga-pass-through" target=3D"_blank">http://www.davi=
dgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-t=
hrough</a></div>

<div><br></div><div>I can only boot the WinXP client via the VNC console (g=
fx_passthrough=3D0), and from within WinXP I see that the OS has detected t=
he GTX480 card (as its secondary card), but I am not able to use it. I have=
 tried the=A0<span style=3D"font-family:Verdana,Arial,Geneva,Helvetica,sans=
-serif;font-size:13px">275.33 drives, and they make no difference.</span></=
div>

<div><span style=3D"font-family:Verdana,Arial,Geneva,Helvetica,sans-serif;f=
ont-size:13px"><br></span></div><div><font face=3D"Verdana, Arial, Geneva, =
Helvetica, sans-serif">My question is related to the number of PCIe lanes I=
 have available to the graphics card.</font></div>

<div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">I only ha=
ve 8 lanes available for the GTX480 (which is a PCIe x16 card), could this =
pose an issue for Xen?</font></div><div><font face=3D"Verdana, Arial, Genev=
a, Helvetica, sans-serif"><br>

</font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-ser=
if"><br></font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, =
sans-serif">I plan to test VGA passthrough with an ATI graphics card (also =
in a PCIe x8 slot) later to see if it will work or not. I will update what =
I find.</font></div>

<div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif"><br></fon=
t></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">R=
egards<span class=3D"HOEnZb"><font color=3D"#888888"><br><br>Sandi</font></=
span></font></div>

</blockquote></div><br></div>

--e89a8f2357ff53b01904b6b8f01b--


--===============4887586873585106406==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4887586873585106406==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:02:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8g3-0000yS-7Y; Tue, 17 Jan 2012 13:02:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1Rn8g1-0000yN-H8
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:02:14 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326805284!48918496!1
X-Originating-IP: [209.85.210.193]
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 16038 invoked from network); 17 Jan 2012 13:01:25 -0000
Received: from mail-iy0-f193.google.com (HELO mail-iy0-f193.google.com)
	(209.85.210.193)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:01:25 -0000
Received: by iabz21 with SMTP id z21so162296iab.0
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 05:02:10 -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=AGWG34G5llcr5mAIY8iSzgJ5XtmLqNX9L5Pq6rh8J0c=;
	b=fvxCQ7gEqnESghVIGJnP8Bf0bJuh5BfYjx83kGZXG9X4vQsiw9e/Dxy9uIeG47D8RM
	S3VCUyNig+YBSJOmai5Lq9Btg5l4SIEJwxkaEo9iz1gylWJc6trlbAKPWGrsAgMY9caU
	skl0wEFyMWYG81972+fX7gTQv0LNXUvpPeKWU=
MIME-Version: 1.0
Received: by 10.50.156.130 with SMTP id we2mr17491515igb.10.1326805329096;
	Tue, 17 Jan 2012 05:02:09 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Tue, 17 Jan 2012 05:02:09 -0800 (PST)
In-Reply-To: <CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
References: <CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
Date: Tue, 17 Jan 2012 14:02:09 +0100
Message-ID: <CAFoWEVPww5rA96qvApmpV9+jkDxmm1BXkXddvf8in8AhaoPcmA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Available PCIe lanes for VGA 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: multipart/mixed; boundary="===============4887586873585106406=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4887586873585106406==
Content-Type: multipart/alternative; boundary=e89a8f2357ff53b01904b6b8f01b

--e89a8f2357ff53b01904b6b8f01b
Content-Type: text/plain; charset=ISO-8859-1

Hello everyone,

Looks like my initial email to xen-devel did not get delivered or
something...
Please see it below this email.

Okay, here is some info about my system:

lspci | grep -i vga
03:00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce GTX
480] (rev a3)
06:04.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM450
(rev 0a)


lspci | grep -i 03:00
03:00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce GTX
480] (rev a3)
03:00.1 Audio device: nVidia Corporation GF100 High Definition Audio
Controller (rev a1)


dmesg | grep -i 03:00
[    0.000000] Command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    5.114443] Kernel command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    5.356290] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300
[    5.356310] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9ffffff]
[    5.356332] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0xdfffffff 64bit
pref]
[    5.356353] pci 0000:03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64bit
pref]
[    5.356368] pci 0000:03:00.0: reg 24: [io  0xdc00-0xdc7f]
[    5.356383] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaefffff pref]
[    5.356475] pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403
[    5.356494] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]
[    5.425416] vgaarb: device added:
PCI:0000:03:00.0,decodes=io+mem,owns=none,locks=none
[    5.425438] vgaarb: bridge control possible 0000:03:00.0
[    5.443721] pciback 0000:03:00.0: seizing device
[    5.443726] pciback 0000:03:00.1: seizing device
[    5.713088] pciback 0000:03:00.0: Signaling PME through PCIe PME
interrupt
[    5.713090] pciback 0000:03:00.1: Signaling PME through PCIe PME
interrupt
[    5.713566] pciback 0000:03:00.1: PCI INT B -> GSI 25 (level, low) ->
IRQ 25
[    5.713574] pciback 0000:03:00.1: PCI INT B disabled
[    5.713610] pciback 0000:03:00.0: enabling device (0146 -> 0147)
[    5.713627] pciback 0000:03:00.0: PCI INT A -> GSI 26 (level, low) ->
IRQ 26
[    5.713633] pciback 0000:03:00.0: PCI INT A disabled


xl pci-list-assignable-devices
0000:03:00.0
0000:03:00.1


cat /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="nomodeset xen-pciback.passthrough=1
xen-pciback.permissive xen-pciback.hide=(03:00.0)(03:00.1)"
GRUB_DISABLE_OS_PROBER=true
GRUB_CMDLINE_XEN="dom0_mem=1G"


>From all that, I assume that the VGA card, and its on-board audio device,
is owned by pciback.


This is how I start the domain:
xl create xenwinxp.cfg
Parsing config file xenwinxp.cfg
WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override"
instead if you really want a non-default firmware
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001819b4
  TOTAL:         0000000000000000->00000000bf800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000001
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
Daemon running with PID 3001

Quick confirmation that it is up and running:
xl list
Name                                        ID   Mem VCPUs State Time(s)
Domain-0                                     0  1024    12     r-----
255.7
winxp                                        1  3067     4     -b----
 61.2

This is my xen config file:
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 3072
# shadow_memory = 1024
name = "winxp"
vcpus='4'
vif = [ 'bridge=eth0,mac=00:14:3e:00:8f:c2' ]
disk =
['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/winxp.iso,hdc:cdrom,r']
boot="cd"
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncconsole=1
vncpasswd=''
acpi=1
apic=1
xen_extended_power_mgmt=1
pae=1
arch='x86_64'
hpet = 1
hap = 1
viridian = 1
monitor=1
serial='pty'
# keymap='fr'
# soundhw = "all"
# audio="on"
ne2000=0
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
xen_platform_pci=1
gfx_passthru=0
pci  = [ "03:00.0,msitranslate=1,power_mgmt=1" ]
acpi_s3 = 1
acpi_s4 = 1


The Windows XP boots up fine, I can see the GTX480 in the device manager,
but it is not useable.

 Now, let me try gfx_passthru=1

Create the domain:
xl create xenwinxp.cfg
Parsing config file xenwinxp.cfg
WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override"
instead if you really want a non-default firmware
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->00000000001819b4
  TOTAL:         0000000000000000->00000000bf800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000003fb
  1GB PAGES: 0x0000000000000001
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
Daemon running with PID 3454

When the domain starts, my dom0 screen attached to the 06:04.0 VGA
controller goes blank, and after a few seconds I get a message from my
monitor that 'this video format is not supported'. I can get back to my
dom0 by first going Ctrl-Alt-F1 (where I will see a whole bunch of garbage
in the screen) and then Ctrl-Alt-F7.

The domain is running:
xl list
Name                                        ID   Mem VCPUs State Time(s)
Domain-0                                     0  1024    12     r-----
385.3
winxp                                        3  3063     1     r-----
324.5

And if I check out what is happening through vncviewer, I see just the QEMU
console (QEMU 0.10.2 monitor - type 'help' for more information)

And finally, I see that the VGA card is no longer available:
xl pci-list-assignable-devices
0000:03:00.1


I have checked all three of the video cards outputs, no video signal
anywhere.


Any ideas about what could be causing the problems I am encountering?
I would be grateful for any info.

Thanks in advance.

Sandi





On Tue, Jan 17, 2012 at 11:10 AM, Sandi Romih <romihs.forums@gmail.com>wrote:

> Hello,
>
> I hope that I am posting the correct list with this question.
>
> I have been trying to get VGA passthrough working on my system for some
> time now without success.
> I do not have the system with me right now, so I will not be able to
> provide any logs or error messages right now. I will be able to to do so in
> a couple of hours.
>
> I have a VT-d enabled system (Motherboard and CPU) on which I wish to pass
> the secondary graphics card (EVGA GTX480 SE) through to the HVM (WinXP
> 32-bit).
> Currently I am testing with Debian Squeeze, using the 3.1.8 kernel and Xen
> 4.2.unstable according to these instructions:
> http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-through
>
> I can only boot the WinXP client via the VNC console (gfx_passthrough=0),
> and from within WinXP I see that the OS has detected the GTX480 card (as
> its secondary card), but I am not able to use it. I have tried the 275.33
> drives, and they make no difference.
>
> My question is related to the number of PCIe lanes I have available to the
> graphics card.
> I only have 8 lanes available for the GTX480 (which is a PCIe x16 card),
> could this pose an issue for Xen?
>
>
> I plan to test VGA passthrough with an ATI graphics card (also in a PCIe
> x8 slot) later to see if it will work or not. I will update what I find.
>
> Regards
>
> Sandi
>

--e89a8f2357ff53b01904b6b8f01b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello everyone,<div><br></div><div>Looks like my initial email to xen-devel=
 did not get delivered or something...</div><div>Please see it below this e=
mail.</div><div><br></div><div>Okay, here is some info about my system:</di=
v>
<div><br></div><div><div>lspci | grep -i vga</div><div>03:00.0 VGA compatib=
le controller: nVidia Corporation GF100 [GeForce GTX 480] (rev a3)</div><di=
v>06:04.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM4=
50 (rev 0a)</div>
<div><br></div><div><br></div><div><div>lspci | grep -i 03:00</div><div>03:=
00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce GTX 480] =
(rev a3)</div><div>03:00.1 Audio device: nVidia Corporation GF100 High Defi=
nition Audio Controller (rev a1)</div>
</div><div><br></div><div><br></div><div><div>dmesg | grep -i 03:00</div><d=
iv>[ =A0 =A00.000000] Command line: placeholder root=3DUUID=3Dd5f5207b-d2aa=
-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.passthrough=3D1 xen-pcibac=
k.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet</div>
<div>[ =A0 =A05.114443] Kernel command line: placeholder root=3DUUID=3Dd5f5=
207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.passthrough=3D1 x=
en-pciback.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet</div><div=
>[ =A0 =A05.356290] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300</di=
v>
<div>[ =A0 =A05.356310] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9fffff=
f]</div><div>[ =A0 =A05.356332] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0=
xdfffffff 64bit pref]</div><div>[ =A0 =A05.356353] pci 0000:03:00.0: reg 1c=
: [mem 0xd4000000-0xd7ffffff 64bit pref]</div>
<div>[ =A0 =A05.356368] pci 0000:03:00.0: reg 24: [io =A00xdc00-0xdc7f]</di=
v><div>[ =A0 =A05.356383] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaeff=
fff pref]</div><div>[ =A0 =A05.356475] pci 0000:03:00.1: [10de:0be5] type 0=
 class 0x000403</div>
<div>[ =A0 =A05.356494] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7fff=
f]</div><div>[ =A0 =A05.425416] vgaarb: device added: PCI:0000:03:00.0,deco=
des=3Dio+mem,owns=3Dnone,locks=3Dnone</div><div>[ =A0 =A05.425438] vgaarb: =
bridge control possible 0000:03:00.0</div>
<div>[ =A0 =A05.443721] pciback 0000:03:00.0: seizing device</div><div>[ =
=A0 =A05.443726] pciback 0000:03:00.1: seizing device</div><div>[ =A0 =A05.=
713088] pciback 0000:03:00.0: Signaling PME through PCIe PME interrupt</div=
><div>[ =A0 =A05.713090] pciback 0000:03:00.1: Signaling PME through PCIe P=
ME interrupt</div>
<div>[ =A0 =A05.713566] pciback 0000:03:00.1: PCI INT B -&gt; GSI 25 (level=
, low) -&gt; IRQ 25</div><div>[ =A0 =A05.713574] pciback 0000:03:00.1: PCI =
INT B disabled</div><div>[ =A0 =A05.713610] pciback 0000:03:00.0: enabling =
device (0146 -&gt; 0147)</div>
<div>[ =A0 =A05.713627] pciback 0000:03:00.0: PCI INT A -&gt; GSI 26 (level=
, low) -&gt; IRQ 26</div><div>[ =A0 =A05.713633] pciback 0000:03:00.0: PCI =
INT A disabled</div></div><div><br></div><div><br></div><div><div>xl pci-li=
st-assignable-devices=A0</div>
<div>0000:03:00.0</div><div>0000:03:00.1</div></div><div><br></div><div><br=
></div><div><div>cat /etc/default/grub=A0</div><div>GRUB_DEFAULT=3D0</div><=
div>GRUB_TIMEOUT=3D5</div><div>GRUB_DISTRIBUTOR=3D`lsb_release -i -s 2&gt; =
/dev/null || echo Debian`</div>
<div>GRUB_CMDLINE_LINUX_DEFAULT=3D&quot;quiet&quot;</div><div>GRUB_CMDLINE_=
LINUX=3D&quot;nomodeset xen-pciback.passthrough=3D1 xen-pciback.permissive =
xen-pciback.hide=3D(03:00.0)(03:00.1)&quot;</div><div>GRUB_DISABLE_OS_PROBE=
R=3Dtrue</div>
<div>GRUB_CMDLINE_XEN=3D&quot;dom0_mem=3D1G&quot;</div></div><div><br></div=
><div><br></div><div>From all that, I assume that the VGA card, and its=A0o=
n-board=A0audio device, is owned by pciback.</div><div><br></div><div><br><=
/div>
<div>This is how I start the domain:</div><div><div>xl create xenwinxp.cfg=
=A0</div><div>Parsing config file xenwinxp.cfg</div><div>WARNING: ignoring =
&quot;kernel&quot; directive for HVM guest. Use &quot;firmware_override&quo=
t; instead if you really want a non-default firmware</div>
<div>xc: info: VIRTUAL MEMORY ARRANGEMENT:</div><div>=A0 Loader: =A0 =A0 =
=A0 =A00000000000100000-&gt;00000000001819b4</div><div>=A0 TOTAL: =A0 =A0 =
=A0 =A0 0000000000000000-&gt;00000000bf800000</div><div>=A0 ENTRY ADDRESS: =
0000000000100000</div>
<div>xc: info: PHYSICAL MEMORY ALLOCATION:</div><div>=A0 4KB PAGES: 0x00000=
00000000200</div><div>=A0 2MB PAGES: 0x00000000000003fb</div><div>=A0 1GB P=
AGES: 0x0000000000000001</div><div><font color=3D"#ff0000">libxl: error: li=
bxl_pci.c:776:libxl__device_pci_reset: The kernel doesn&#39;t support reset=
 from sysfs for PCI device 0000:03:00.0</font></div>
<div>Daemon running with PID 3001</div></div><div><br></div><div>Quick conf=
irmation that it is up and running:</div><div><div>xl list</div><div>Name =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0ID =A0 Mem VCPUs<span class=3D"Apple-tab-span" style=3D"white-space:pre=
">	</span>State<span class=3D"Apple-tab-span" style=3D"white-space:pre">	</=
span>Time(s)</div>
<div>Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 0 =A01024 =A0 =A012 =A0 =A0 r----- =A0 =A0 255.7</div><div>winx=
p =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A01 =A03067 =A0 =A0 4 =A0 =A0 -b---- =A0 =A0 =A061.2</div></div><div><=
br></div><div>This is my xen config file:</div>
<div><div>kernel =3D &quot;/usr/lib/xen/boot/hvmloader&quot;</div><div>buil=
der=3D&#39;hvm&#39;</div><div>memory =3D 3072</div><div># shadow_memory =3D=
 1024</div><div>name =3D &quot;winxp&quot;</div><div>vcpus=3D&#39;4&#39;</d=
iv><div>
vif =3D [ &#39;bridge=3Deth0,mac=3D00:14:3e:00:8f:c2&#39; ]</div><div>disk =
=3D [&#39;file:/xen-vms/winxp/xenwinxp.img,hda,w&#39;,&#39;file:/xen-vms/is=
os/winxp.iso,hdc:cdrom,r&#39;]</div><div>boot=3D&quot;cd&quot;</div><div>sd=
l=3D0</div>
<div>vnc=3D1</div><div>vnclisten=3D&quot;0.0.0.0&quot;</div><div>vncconsole=
=3D1</div><div>vncpasswd=3D&#39;&#39;</div><div>acpi=3D1</div><div>apic=3D1=
</div><div>xen_extended_power_mgmt=3D1</div><div>pae=3D1</div><div>arch=3D&=
#39;x86_64&#39;</div>
<div>hpet =3D 1</div><div>hap =3D 1</div><div>viridian =3D 1</div><div>moni=
tor=3D1</div><div>serial=3D&#39;pty&#39;</div><div># keymap=3D&#39;fr&#39;<=
/div><div># soundhw =3D &quot;all&quot;</div><div># audio=3D&quot;on&quot;<=
/div><div>ne2000=3D0</div>
<div>on_poweroff =3D &#39;destroy&#39;</div><div>on_reboot =A0 =3D &#39;res=
tart&#39;</div><div>on_crash =A0 =A0=3D &#39;restart&#39;</div><div>xen_pla=
tform_pci=3D1</div><div>gfx_passthru=3D0</div><div>pci =A0=3D [ &quot;03:00=
.0,msitranslate=3D1,power_mgmt=3D1&quot; ]</div>
<div>acpi_s3 =3D 1</div><div>acpi_s4 =3D 1</div></div><div><br></div><div><=
br></div><div>The Windows XP boots up fine, I can see the GTX480 in the dev=
ice manager, but it is not useable.</div><div><br></div><div>=A0Now, let me=
 try gfx_passthru=3D1</div>
<div><br></div><div>Create the domain:</div><div><div>xl create xenwinxp.cf=
g=A0</div><div>Parsing config file xenwinxp.cfg</div><div>WARNING: ignoring=
 &quot;kernel&quot; directive for HVM guest. Use &quot;firmware_override&qu=
ot; instead if you really want a non-default firmware</div>
<div>xc: info: VIRTUAL MEMORY ARRANGEMENT:</div><div>=A0 Loader: =A0 =A0 =
=A0 =A00000000000100000-&gt;00000000001819b4</div><div>=A0 TOTAL: =A0 =A0 =
=A0 =A0 0000000000000000-&gt;00000000bf800000</div><div>=A0 ENTRY ADDRESS: =
0000000000100000</div>
<div>xc: info: PHYSICAL MEMORY ALLOCATION:</div><div>=A0 4KB PAGES: 0x00000=
00000000200</div><div>=A0 2MB PAGES: 0x00000000000003fb</div><div>=A0 1GB P=
AGES: 0x0000000000000001</div><div>libxl: error: libxl_pci.c:776:libxl__dev=
ice_pci_reset: The kernel doesn&#39;t support reset from sysfs for PCI devi=
ce 0000:03:00.0</div>
<div>Daemon running with PID 3454</div></div><div><br></div><div>When the d=
omain starts, my dom0=A0screen=A0attached to the=A006:04.0 VGA controller g=
oes blank, and after a few seconds I get a message from my monitor that &#3=
9;this video format is not supported&#39;. I can get back to my dom0 by fir=
st going Ctrl-Alt-F1 (where I will see a whole bunch of garbage in the scre=
en) and then Ctrl-Alt-F7.</div>
<div><br></div><div>The domain is running:</div><div><div>xl list</div><div=
>Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0ID =A0 Mem VCPUs<span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre">	</span>State<span class=3D"Apple-tab-span" style=3D"white-space:p=
re">	</span>Time(s)</div>
<div>Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 0 =A01024 =A0 =A012 =A0 =A0 r----- =A0 =A0 385.3</div><div>winx=
p =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A03 =A03063 =A0 =A0 1 =A0 =A0 r----- =A0 =A0 324.5</div></div><div><br=
></div><div>And if I check out what is happening through vncviewer, I see j=
ust the QEMU console (QEMU 0.10.2 monitor - type &#39;help&#39; for more in=
formation)</div>
<div><br></div><div>And=A0finally, I see that the VGA card is no longer ava=
ilable:</div><div><div>xl pci-list-assignable-devices=A0</div><div>0000:03:=
00.1</div></div><div><br></div><div><br></div><div>I have checked all three=
 of the video cards outputs, no video signal anywhere.</div>
<div><br></div><div><br></div><div>Any ideas about what could be causing th=
e=A0problems=A0I am encountering?</div><div>I would be grateful for any inf=
o.</div><div><br></div><div>Thanks in advance.</div><div><br></div><div>San=
di</div>
<div><br></div><div><br></div><div><br></div><div><br></div><br><div class=
=3D"gmail_quote">On Tue, Jan 17, 2012 at 11:10 AM, Sandi Romih <span dir=3D=
"ltr">&lt;<a href=3D"mailto:romihs.forums@gmail.com">romihs.forums@gmail.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hello,<div><br></div><div>I hope that I am p=
osting the correct list with this question.</div><div><br></div><div>I have=
 been trying to get VGA passthrough working on my system for some time now =
without success.</div>
<div>I do not have the system with me right now, so I will not be able to p=
rovide any logs or error messages right now. I will be able to to do so in =
a couple of hours.</div>
<div><br></div><div>I have a VT-d enabled system (Motherboard and CPU) on w=
hich I wish to pass the secondary graphics card (EVGA GTX480 SE) through to=
 the HVM (WinXP 32-bit).</div><div>Currently I am testing with Debian Squee=
ze, using the 3.1.8 kernel and Xen 4.2.unstable according to these instruct=
ions:=A0<a href=3D"http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen=
-42unstable-patches-for-vga-pass-through" target=3D"_blank">http://www.davi=
dgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for-vga-pass-t=
hrough</a></div>

<div><br></div><div>I can only boot the WinXP client via the VNC console (g=
fx_passthrough=3D0), and from within WinXP I see that the OS has detected t=
he GTX480 card (as its secondary card), but I am not able to use it. I have=
 tried the=A0<span style=3D"font-family:Verdana,Arial,Geneva,Helvetica,sans=
-serif;font-size:13px">275.33 drives, and they make no difference.</span></=
div>

<div><span style=3D"font-family:Verdana,Arial,Geneva,Helvetica,sans-serif;f=
ont-size:13px"><br></span></div><div><font face=3D"Verdana, Arial, Geneva, =
Helvetica, sans-serif">My question is related to the number of PCIe lanes I=
 have available to the graphics card.</font></div>

<div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">I only ha=
ve 8 lanes available for the GTX480 (which is a PCIe x16 card), could this =
pose an issue for Xen?</font></div><div><font face=3D"Verdana, Arial, Genev=
a, Helvetica, sans-serif"><br>

</font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-ser=
if"><br></font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, =
sans-serif">I plan to test VGA passthrough with an ATI graphics card (also =
in a PCIe x8 slot) later to see if it will work or not. I will update what =
I find.</font></div>

<div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif"><br></fon=
t></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">R=
egards<span class=3D"HOEnZb"><font color=3D"#888888"><br><br>Sandi</font></=
span></font></div>

</blockquote></div><br></div>

--e89a8f2357ff53b01904b6b8f01b--


--===============4887586873585106406==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4887586873585106406==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:21:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:21:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8yB-0001M2-8l; Tue, 17 Jan 2012 13:20:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1Rn8y9-0001L9-SH; Tue, 17 Jan 2012 13:20:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326806451!11390909!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24365 invoked from network); 17 Jan 2012 13:20:51 -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;
	17 Jan 2012 13:20:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10083635"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 13:20:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 13:20:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth@xen.org>
Date: Tue, 17 Jan 2012 13:20:50 +0000
In-Reply-To: <4F1473A2.4060103@xen.org>
References: <4F1473A2.4060103@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326806451.14689.103.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [XenARM] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 18:59 +0000, Lars Kurth wrote:
> Hi everybody,
> 
> I have been asked when we should hold the next Xen Document Day. Rather 
> than going through this every single month, I am proposing dates until 
> March. I.e.
> - January 30, 2012
> - Feb 27, 2012
> - March 26, 2012

Perhaps we should just nominate a formula (e.g. last Thursday, 3rd Prime
Numbered Day of the month etc)?

> Please go to the Xen Document Days etherpad page 
> (http://openetherpad.org/TSPGIEOBiS) to propose a new date or to vote 
> for a day.
> 
> I also listed items that could be worked on, on the etherpad page (and 
> removed stuff which has been done). Feel free to add to it. It is 
> actually quite incredible how much we (and YOU) did in the last two Xen 
> Document Days. I wanted to thank everybody who was involved!
> 
> I am also looking for a couple of volunteers (moderators), in particular 
> in Asia and/or Australia and in the US who commit to being on the 
> #xendocday IRC channels for a few hours and points other participates to 
> this document and generally provides advice. If you are interested, 
> please also sign up on the Xen Document Days etherpad page.
> 
> Best Regards
> Lars
> 
> 
> _______________________________________________
> Xen-arm mailing list
> Xen-arm@lists.xensource.com
> http://lists.xensource.com/mailman/listinfo/xen-arm



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:21:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:21:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8yB-0001M2-8l; Tue, 17 Jan 2012 13:20:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>)
	id 1Rn8y9-0001L9-SH; Tue, 17 Jan 2012 13:20:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326806451!11390909!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24365 invoked from network); 17 Jan 2012 13:20:51 -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;
	17 Jan 2012 13:20:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10083635"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 13:20:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 13:20:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Lars Kurth <lars.kurth@xen.org>
Date: Tue, 17 Jan 2012 13:20:50 +0000
In-Reply-To: <4F1473A2.4060103@xen.org>
References: <4F1473A2.4060103@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326806451.14689.103.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [XenARM] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 18:59 +0000, Lars Kurth wrote:
> Hi everybody,
> 
> I have been asked when we should hold the next Xen Document Day. Rather 
> than going through this every single month, I am proposing dates until 
> March. I.e.
> - January 30, 2012
> - Feb 27, 2012
> - March 26, 2012

Perhaps we should just nominate a formula (e.g. last Thursday, 3rd Prime
Numbered Day of the month etc)?

> Please go to the Xen Document Days etherpad page 
> (http://openetherpad.org/TSPGIEOBiS) to propose a new date or to vote 
> for a day.
> 
> I also listed items that could be worked on, on the etherpad page (and 
> removed stuff which has been done). Feel free to add to it. It is 
> actually quite incredible how much we (and YOU) did in the last two Xen 
> Document Days. I wanted to thank everybody who was involved!
> 
> I am also looking for a couple of volunteers (moderators), in particular 
> in Asia and/or Australia and in the US who commit to being on the 
> #xendocday IRC channels for a few hours and points other participates to 
> this document and generally provides advice. If you are interested, 
> please also sign up on the Xen Document Days etherpad page.
> 
> Best Regards
> Lars
> 
> 
> _______________________________________________
> Xen-arm mailing list
> Xen-arm@lists.xensource.com
> http://lists.xensource.com/mailman/listinfo/xen-arm



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:22:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8zW-0001bv-Pw; Tue, 17 Jan 2012 13:22:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1Rn8zU-0001Zc-R6; Tue, 17 Jan 2012 13:22:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326806534!11366858!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 21563 invoked from network); 17 Jan 2012 13:22:14 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:22:14 -0000
Received: by wibhj8 with SMTP id hj8so11908708wib.30
	for <multiple recipients>; Tue, 17 Jan 2012 05:22:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=cv+HN0uzR6UOyoF7RcqGMM6C7+hYSxzOALTnCrHdugg=;
	b=ulQ5IDRU0cRkO+JD13EEkNa63BiR/aEc2Fux/SM3JNLkId6itdjiiLbadel67GXHL0
	YG0kdHeInXKfiqN2ulVJToFC1S86Zh9KL6IXwlCAtYlyrOVKiRiEpVUVy5JTGjww7YzH
	6IxPb4RS3AB/Zi8UiObpusSO9Ydv6kT7Dkh+A=
Received: by 10.180.19.168 with SMTP id g8mr28309593wie.4.1326806534239;
	Tue, 17 Jan 2012 05:22:14 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id l8sm29505137wiy.5.2012.01.17.05.22.12
	(version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 05:22:13 -0800 (PST)
Message-ID: <4F157600.2030106@xen.org>
Date: Tue, 17 Jan 2012 13:22:08 +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: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F1473A2.4060103@xen.org>
	<1326806451.14689.103.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326806451.14689.103.camel@zakaz.uk.xensource.com>
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [XenARM] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 17/01/2012 13:20, Ian Campbell wrote:
> On Mon, 2012-01-16 at 18:59 +0000, Lars Kurth wrote:
>> Hi everybody,
>>
>> I have been asked when we should hold the next Xen Document Day. Rather
>> than going through this every single month, I am proposing dates until
>> March. I.e.
>> - January 30, 2012
>> - Feb 27, 2012
>> - March 26, 2012
> Perhaps we should just nominate a formula (e.g. last Thursday, 3rd Prime
> Numbered Day of the month etc)?
These dates are actually the last Monday of a month.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:22:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:22:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn8zW-0001bv-Pw; Tue, 17 Jan 2012 13:22:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1Rn8zU-0001Zc-R6; Tue, 17 Jan 2012 13:22:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326806534!11366858!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 21563 invoked from network); 17 Jan 2012 13:22:14 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:22:14 -0000
Received: by wibhj8 with SMTP id hj8so11908708wib.30
	for <multiple recipients>; Tue, 17 Jan 2012 05:22:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=cv+HN0uzR6UOyoF7RcqGMM6C7+hYSxzOALTnCrHdugg=;
	b=ulQ5IDRU0cRkO+JD13EEkNa63BiR/aEc2Fux/SM3JNLkId6itdjiiLbadel67GXHL0
	YG0kdHeInXKfiqN2ulVJToFC1S86Zh9KL6IXwlCAtYlyrOVKiRiEpVUVy5JTGjww7YzH
	6IxPb4RS3AB/Zi8UiObpusSO9Ydv6kT7Dkh+A=
Received: by 10.180.19.168 with SMTP id g8mr28309593wie.4.1326806534239;
	Tue, 17 Jan 2012 05:22:14 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id l8sm29505137wiy.5.2012.01.17.05.22.12
	(version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 05:22:13 -0800 (PST)
Message-ID: <4F157600.2030106@xen.org>
Date: Tue, 17 Jan 2012 13:22:08 +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: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F1473A2.4060103@xen.org>
	<1326806451.14689.103.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326806451.14689.103.camel@zakaz.uk.xensource.com>
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [XenARM] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 17/01/2012 13:20, Ian Campbell wrote:
> On Mon, 2012-01-16 at 18:59 +0000, Lars Kurth wrote:
>> Hi everybody,
>>
>> I have been asked when we should hold the next Xen Document Day. Rather
>> than going through this every single month, I am proposing dates until
>> March. I.e.
>> - January 30, 2012
>> - Feb 27, 2012
>> - March 26, 2012
> Perhaps we should just nominate a formula (e.g. last Thursday, 3rd Prime
> Numbered Day of the month etc)?
These dates are actually the last Monday of a month.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Og-00030I-Gd; Tue, 17 Jan 2012 13:48:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9Of-0002xi-9t
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19187 invoked from network); 17 Jan 2012 13:47:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:47:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838517"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 08:48:16 -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 q0HDm0fa005778;
	Tue, 17 Jan 2012 05:48:14 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:04 +0000
Message-ID: <1326808024-3744-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 8/8] netback: remove unwanted
	notification generation during NAPI processing.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 original implementation, tx_build_gops tends to update req_event
pointer every time it sees tx error or finish one batch. Remove those
code to only update req_event pointer when we really want to shut down
NAPI.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    5 +++--
 drivers/net/xen-netback/netback.c   |    4 +---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 05caccc..7cf0947 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -58,8 +58,8 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
-	if (likely(napi_schedule_prep(&vif->napi)))
-		__napi_schedule(&vif->napi);
+	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
+		napi_schedule(&vif->napi);
 
 	return IRQ_HANDLED;
 }
@@ -74,6 +74,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	if (work_done < budget) {
 		int more_to_do = 0;
 		unsigned long flag;
+
 		local_irq_save(flag);
 
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index fa864f4..34f34f5 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -663,7 +663,6 @@ static void xenvif_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xenvif_check_rx_xenvif(vif);
 }
 
 static int xenvif_count_requests(struct xenvif *vif,
@@ -1048,7 +1047,7 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
+		work_to_do = RING_HAS_UNCONSUMED_REQUESTS(&vif->tx);
 		if (!work_to_do) {
 			break;
 		}
@@ -1188,7 +1187,6 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xenvif_check_rx_xenvif(vif);
 
 		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
-- 
1.7.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 Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Og-00030I-Gd; Tue, 17 Jan 2012 13:48:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9Of-0002xi-9t
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:21 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19187 invoked from network); 17 Jan 2012 13:47:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:47:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838517"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 08:48:16 -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 q0HDm0fa005778;
	Tue, 17 Jan 2012 05:48:14 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:04 +0000
Message-ID: <1326808024-3744-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 8/8] netback: remove unwanted
	notification generation during NAPI processing.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 original implementation, tx_build_gops tends to update req_event
pointer every time it sees tx error or finish one batch. Remove those
code to only update req_event pointer when we really want to shut down
NAPI.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    5 +++--
 drivers/net/xen-netback/netback.c   |    4 +---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 05caccc..7cf0947 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -58,8 +58,8 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
-	if (likely(napi_schedule_prep(&vif->napi)))
-		__napi_schedule(&vif->napi);
+	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
+		napi_schedule(&vif->napi);
 
 	return IRQ_HANDLED;
 }
@@ -74,6 +74,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	if (work_done < budget) {
 		int more_to_do = 0;
 		unsigned long flag;
+
 		local_irq_save(flag);
 
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index fa864f4..34f34f5 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -663,7 +663,6 @@ static void xenvif_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xenvif_check_rx_xenvif(vif);
 }
 
 static int xenvif_count_requests(struct xenvif *vif,
@@ -1048,7 +1047,7 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
+		work_to_do = RING_HAS_UNCONSUMED_REQUESTS(&vif->tx);
 		if (!work_to_do) {
 			break;
 		}
@@ -1188,7 +1187,6 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xenvif_check_rx_xenvif(vif);
 
 		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
-- 
1.7.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 Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9OU-0002vZ-UI; Tue, 17 Jan 2012 13:48:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9OS-0002vG-Tj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18243 invoked from network); 17 Jan 2012 13:47:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:47:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838490"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48:05 -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 q0HDm0fT005778;
	Tue, 17 Jan 2012 05:48:03 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:46:57 +0000
Message-ID: <1326808024-3744-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 1/8] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A global page pool. Since we are moving to 1:1 model netback, it is
better to limit total RAM consumed by all the vifs.

With this patch, each vif gets page from the pool and puts the page
back when it is finished with the page.

This pool is only meant to access via exported interfaces. Internals
are subject to change when we discover new requirements for the pool.

Current exported interfaces include:

page_pool_init: pool init
page_pool_destroy: pool destruction
page_pool_get: get a page from pool
page_pool_put: put page back to pool
is_in_pool: tell whether a page belongs to the pool

Current implementation has following defects:
 - Global locking
 - No starve prevention mechanism / reservation logic

Global locking tends to cause contention on the pool. No reservation
logic may cause vif to starve. A possible solution to these two
problems will be each vif maintains its local cache and claims a
portion of the pool. However the implementation will be tricky when
coming to pool management, so let's worry about that later.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |    6 +
 drivers/net/xen-netback/netback.c   |  158 ++++++++++++------------------
 drivers/net/xen-netback/page_pool.c |  185 +++++++++++++++++++++++++++++++++++
 drivers/net/xen-netback/page_pool.h |   63 ++++++++++++
 5 files changed, 317 insertions(+), 97 deletions(-)
 create mode 100644 drivers/net/xen-netback/page_pool.c
 create mode 100644 drivers/net/xen-netback/page_pool.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..dc4b8b1 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..288b2f3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,12 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+	struct xenvif *vif;
+};
+typedef unsigned int pending_ring_idx_t;
+
 struct xen_netbk;
 
 struct xenvif {
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 59effac..d11205f 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -33,6 +33,7 @@
  */
 
 #include "common.h"
+#include "page_pool.h"
 
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
@@ -46,12 +47,6 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-	struct xenvif *vif;
-};
-typedef unsigned int pending_ring_idx_t;
-
 struct netbk_rx_meta {
 	int id;
 	int size;
@@ -65,21 +60,6 @@ struct netbk_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-/* extra field used in struct page */
-union page_ext {
-	struct {
-#if BITS_PER_LONG < 64
-#define IDX_WIDTH   8
-#define GROUP_WIDTH (BITS_PER_LONG - IDX_WIDTH)
-		unsigned int group:GROUP_WIDTH;
-		unsigned int idx:IDX_WIDTH;
-#else
-		unsigned int group, idx;
-#endif
-	} e;
-	void *mapping;
-};
-
 struct xen_netbk {
 	wait_queue_head_t wq;
 	struct task_struct *task;
@@ -89,7 +69,7 @@ struct xen_netbk {
 
 	struct timer_list net_timer;
 
-	struct page *mmap_pages[MAX_PENDING_REQS];
+	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
@@ -100,7 +80,6 @@ struct xen_netbk {
 
 	atomic_t netfront_count;
 
-	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
 	u16 pending_ring[MAX_PENDING_REQS];
@@ -160,7 +139,7 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
 				       u16 idx)
 {
-	return page_to_pfn(netbk->mmap_pages[idx]);
+	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
 }
 
 static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
@@ -169,45 +148,6 @@ static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
 	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
 }
 
-/* extra field used in struct page */
-static inline void set_page_ext(struct page *pg, struct xen_netbk *netbk,
-				unsigned int idx)
-{
-	unsigned int group = netbk - xen_netbk;
-	union page_ext ext = { .e = { .group = group + 1, .idx = idx } };
-
-	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
-	pg->mapping = ext.mapping;
-}
-
-static int get_page_ext(struct page *pg,
-			unsigned int *pgroup, unsigned int *pidx)
-{
-	union page_ext ext = { .mapping = pg->mapping };
-	struct xen_netbk *netbk;
-	unsigned int group, idx;
-
-	group = ext.e.group - 1;
-
-	if (group < 0 || group >= xen_netbk_group_nr)
-		return 0;
-
-	netbk = &xen_netbk[group];
-
-	idx = ext.e.idx;
-
-	if ((idx < 0) || (idx >= MAX_PENDING_REQS))
-		return 0;
-
-	if (netbk->mmap_pages[idx] != pg)
-		return 0;
-
-	*pgroup = group;
-	*pidx = idx;
-
-	return 1;
-}
-
 /*
  * This is the amount of packet we copy rather than map, so that the
  * guest can't fiddle with the contents of the headers while we do
@@ -398,8 +338,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
-	unsigned int uninitialized_var(group), uninitialized_var(idx);
-	int foreign = get_page_ext(page, &group, &idx);
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
@@ -427,10 +367,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = &xen_netbk[group];
-			struct pending_tx_info *src_pend;
-
-			src_pend = &netbk->pending_tx_info[idx];
+			struct pending_tx_info *src_pend = to_txinfo(idx);
 
 			copy_gop->source.domid = src_pend->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
@@ -906,11 +843,11 @@ static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
 					 u16 pending_idx)
 {
 	struct page *page;
-	page = alloc_page(GFP_KERNEL|__GFP_COLD);
+	int idx;
+	page = page_pool_get(netbk, &idx);
 	if (!page)
 		return NULL;
-	set_page_ext(page, netbk, pending_idx);
-	netbk->mmap_pages[pending_idx] = page;
+	netbk->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
@@ -931,8 +868,8 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	for (i = start; i < shinfo->nr_frags; i++, txp++) {
 		struct page *page;
 		pending_ring_idx_t index;
-		struct pending_tx_info *pending_tx_info =
-			netbk->pending_tx_info;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		index = pending_index(netbk->pending_cons++);
 		pending_idx = netbk->pending_ring[index];
@@ -940,6 +877,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		if (!page)
 			return NULL;
 
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txp->offset;
@@ -953,9 +893,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 
 		gop++;
 
-		memcpy(&pending_tx_info[pending_idx].req, txp, sizeof(*txp));
+		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
 		xenvif_get(vif);
-		pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -968,8 +908,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
+	struct pending_tx_info *pending_tx_info;
+	int idx;
+	struct xenvif *vif = NULL;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -980,7 +921,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
 		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[index];
+		pending_tx_info = to_txinfo(idx);
+		txp = &pending_tx_info->req;
+		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
 		xenvif_put(vif);
@@ -1005,7 +949,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		txp = &to_txinfo(idx)->req;
+		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
@@ -1042,10 +988,15 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		struct xen_netif_tx_request *txp;
 		struct page *page;
 		u16 pending_idx;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		txp = &pending_tx_info->req;
 		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
@@ -1053,7 +1004,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(netbk->mmap_pages[pending_idx]);
+		get_page(page);
 		xen_netbk_idx_release(netbk, pending_idx);
 	}
 }
@@ -1233,6 +1184,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int work_to_do;
 		unsigned int data_len;
 		pending_ring_idx_t index;
+		int pool_idx;
+		struct pending_tx_info *pending_tx_info;
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
@@ -1347,9 +1300,12 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		gop++;
 
-		memcpy(&netbk->pending_tx_info[pending_idx].req,
+		pool_idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(pool_idx);
+
+		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		netbk->pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1397,10 +1353,16 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = *((u16 *)skb->data);
-		vif = netbk->pending_tx_info[pending_idx].vif;
-		txp = &netbk->pending_tx_info[pending_idx].req;
+
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		vif = pending_tx_info->vif;
+		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
 		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
@@ -1480,12 +1442,14 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
+	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == NULL)
+	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	pending_tx_info = &netbk->pending_tx_info[pending_idx];
+	idx = netbk->mmap_pages[pending_idx];
+	pending_tx_info = to_txinfo(idx);
 
 	vif = pending_tx_info->vif;
 
@@ -1496,9 +1460,9 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	xenvif_put(vif);
 
-	netbk->mmap_pages[pending_idx]->mapping = 0;
-	put_page(netbk->mmap_pages[pending_idx]);
-	netbk->mmap_pages[pending_idx] = NULL;
+	page_pool_put(netbk->mmap_pages[pending_idx]);
+
+	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1681,19 +1645,21 @@ static int __init netback_init(void)
 		wake_up_process(netbk->task);
 	}
 
-	rc = xenvif_xenbus_init();
+	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto pool_failed_init;
+
 	return 0;
 
+pool_failed_init:
+	page_pool_destroy();
 failed_init:
 	while (--group >= 0) {
 		struct xen_netbk *netbk = &xen_netbk[group];
-		for (i = 0; i < MAX_PENDING_REQS; i++) {
-			if (netbk->mmap_pages[i])
-				__free_page(netbk->mmap_pages[i]);
-		}
 		del_timer(&netbk->net_timer);
 		kthread_stop(netbk->task);
 	}
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
new file mode 100644
index 0000000..294f48b
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.c
@@ -0,0 +1,185 @@
+/*
+ * Global page pool for netback.
+ *
+ * Wei Liu <wei.liu2@citrix.com>
+ * Copyright (c) Citrix Systems
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "common.h"
+#include "page_pool.h"
+#include <asm/xen/page.h>
+
+static idx_t free_head;
+static int free_count;
+static unsigned long pool_size;
+static DEFINE_SPINLOCK(pool_lock);
+static struct page_pool_entry *pool;
+
+static int get_free_entry(void)
+{
+	int idx;
+
+	spin_lock(&pool_lock);
+
+	if (free_count == 0) {
+		spin_unlock(&pool_lock);
+		return -ENOSPC;
+	}
+
+	idx = free_head;
+	free_count--;
+	free_head = pool[idx].u.fl;
+	pool[idx].u.fl = INVALID_ENTRY;
+
+	spin_unlock(&pool_lock);
+
+	return idx;
+}
+
+static void put_free_entry(idx_t idx)
+{
+	spin_lock(&pool_lock);
+
+	pool[idx].u.fl = free_head;
+	free_head = idx;
+	free_count++;
+
+	spin_unlock(&pool_lock);
+}
+
+static inline void set_page_ext(struct page *pg, unsigned int idx)
+{
+	union page_ext ext = { .idx = idx };
+
+	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
+	pg->mapping = ext.mapping;
+}
+
+static int get_page_ext(struct page *pg, unsigned int *pidx)
+{
+	union page_ext ext = { .mapping = pg->mapping };
+	int idx;
+
+	idx = ext.idx;
+
+	if ((idx < 0) || (idx >= pool_size))
+		return 0;
+
+	if (pool[idx].page != pg)
+		return 0;
+
+	*pidx = idx;
+
+	return 1;
+}
+
+int is_in_pool(struct page *page, int *pidx)
+{
+	return get_page_ext(page, pidx);
+}
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+{
+	int idx;
+	struct page *page;
+
+	idx = get_free_entry();
+	if (idx < 0)
+		return NULL;
+	page = alloc_page(GFP_ATOMIC);
+
+	if (page == NULL) {
+		put_free_entry(idx);
+		return NULL;
+	}
+
+	set_page_ext(page, idx);
+	pool[idx].u.netbk = netbk;
+	pool[idx].page = page;
+
+	*pidx = idx;
+
+	return page;
+}
+
+void page_pool_put(int idx)
+{
+	struct page *page = pool[idx].page;
+
+	pool[idx].page = NULL;
+	pool[idx].u.netbk = NULL;
+	page->mapping = 0;
+	put_page(page);
+	put_free_entry(idx);
+}
+
+int page_pool_init()
+{
+	int cpus = 0;
+	int i;
+
+	cpus = num_online_cpus();
+	pool_size = cpus * ENTRIES_PER_CPU;
+
+	pool = vzalloc(sizeof(struct page_pool_entry) * pool_size);
+
+	if (!pool)
+		return -ENOMEM;
+
+	for (i = 0; i < pool_size - 1; i++)
+		pool[i].u.fl = i+1;
+	pool[pool_size-1].u.fl = INVALID_ENTRY;
+	free_count = pool_size;
+	free_head = 0;
+
+	return 0;
+}
+
+void page_pool_destroy()
+{
+	int i;
+	for (i = 0; i < pool_size; i++)
+		if (pool[i].page)
+			put_page(pool[i].page);
+
+	vfree(pool);
+}
+
+struct page *to_page(int idx)
+{
+	return pool[idx].page;
+}
+
+struct xen_netbk *to_netbk(int idx)
+{
+	return pool[idx].u.netbk;
+}
+
+struct pending_tx_info *to_txinfo(int idx)
+{
+	return &pool[idx].tx_info;
+}
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
new file mode 100644
index 0000000..572b037
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.h
@@ -0,0 +1,63 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __PAGE_POOL_H__
+#define __PAGE_POOL_H__
+
+#include "common.h"
+
+typedef uint32_t idx_t;
+
+#define ENTRIES_PER_CPU (1024)
+#define INVALID_ENTRY 0xffffffff
+
+struct page_pool_entry {
+	struct page *page;
+	struct pending_tx_info tx_info;
+	union {
+		struct xen_netbk *netbk;
+		idx_t             fl;
+	} u;
+};
+
+union page_ext {
+	idx_t idx;
+	void *mapping;
+};
+
+int  page_pool_init(void);
+void page_pool_destroy(void);
+
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+void         page_pool_put(int idx);
+int          is_in_pool(struct page *page, int *pidx);
+
+struct page            *to_page(int idx);
+struct xen_netbk       *to_netbk(int idx);
+struct pending_tx_info *to_txinfo(int idx);
+
+#endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9OU-0002vZ-UI; Tue, 17 Jan 2012 13:48:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9OS-0002vG-Tj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:09 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18243 invoked from network); 17 Jan 2012 13:47:26 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:47:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838490"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48:05 -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 q0HDm0fT005778;
	Tue, 17 Jan 2012 05:48:03 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:46:57 +0000
Message-ID: <1326808024-3744-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 1/8] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A global page pool. Since we are moving to 1:1 model netback, it is
better to limit total RAM consumed by all the vifs.

With this patch, each vif gets page from the pool and puts the page
back when it is finished with the page.

This pool is only meant to access via exported interfaces. Internals
are subject to change when we discover new requirements for the pool.

Current exported interfaces include:

page_pool_init: pool init
page_pool_destroy: pool destruction
page_pool_get: get a page from pool
page_pool_put: put page back to pool
is_in_pool: tell whether a page belongs to the pool

Current implementation has following defects:
 - Global locking
 - No starve prevention mechanism / reservation logic

Global locking tends to cause contention on the pool. No reservation
logic may cause vif to starve. A possible solution to these two
problems will be each vif maintains its local cache and claims a
portion of the pool. However the implementation will be tricky when
coming to pool management, so let's worry about that later.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |    6 +
 drivers/net/xen-netback/netback.c   |  158 ++++++++++++------------------
 drivers/net/xen-netback/page_pool.c |  185 +++++++++++++++++++++++++++++++++++
 drivers/net/xen-netback/page_pool.h |   63 ++++++++++++
 5 files changed, 317 insertions(+), 97 deletions(-)
 create mode 100644 drivers/net/xen-netback/page_pool.c
 create mode 100644 drivers/net/xen-netback/page_pool.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..dc4b8b1 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..288b2f3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,12 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+	struct xenvif *vif;
+};
+typedef unsigned int pending_ring_idx_t;
+
 struct xen_netbk;
 
 struct xenvif {
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 59effac..d11205f 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -33,6 +33,7 @@
  */
 
 #include "common.h"
+#include "page_pool.h"
 
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
@@ -46,12 +47,6 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-	struct xenvif *vif;
-};
-typedef unsigned int pending_ring_idx_t;
-
 struct netbk_rx_meta {
 	int id;
 	int size;
@@ -65,21 +60,6 @@ struct netbk_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-/* extra field used in struct page */
-union page_ext {
-	struct {
-#if BITS_PER_LONG < 64
-#define IDX_WIDTH   8
-#define GROUP_WIDTH (BITS_PER_LONG - IDX_WIDTH)
-		unsigned int group:GROUP_WIDTH;
-		unsigned int idx:IDX_WIDTH;
-#else
-		unsigned int group, idx;
-#endif
-	} e;
-	void *mapping;
-};
-
 struct xen_netbk {
 	wait_queue_head_t wq;
 	struct task_struct *task;
@@ -89,7 +69,7 @@ struct xen_netbk {
 
 	struct timer_list net_timer;
 
-	struct page *mmap_pages[MAX_PENDING_REQS];
+	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
@@ -100,7 +80,6 @@ struct xen_netbk {
 
 	atomic_t netfront_count;
 
-	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
 	u16 pending_ring[MAX_PENDING_REQS];
@@ -160,7 +139,7 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
 				       u16 idx)
 {
-	return page_to_pfn(netbk->mmap_pages[idx]);
+	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
 }
 
 static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
@@ -169,45 +148,6 @@ static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
 	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
 }
 
-/* extra field used in struct page */
-static inline void set_page_ext(struct page *pg, struct xen_netbk *netbk,
-				unsigned int idx)
-{
-	unsigned int group = netbk - xen_netbk;
-	union page_ext ext = { .e = { .group = group + 1, .idx = idx } };
-
-	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
-	pg->mapping = ext.mapping;
-}
-
-static int get_page_ext(struct page *pg,
-			unsigned int *pgroup, unsigned int *pidx)
-{
-	union page_ext ext = { .mapping = pg->mapping };
-	struct xen_netbk *netbk;
-	unsigned int group, idx;
-
-	group = ext.e.group - 1;
-
-	if (group < 0 || group >= xen_netbk_group_nr)
-		return 0;
-
-	netbk = &xen_netbk[group];
-
-	idx = ext.e.idx;
-
-	if ((idx < 0) || (idx >= MAX_PENDING_REQS))
-		return 0;
-
-	if (netbk->mmap_pages[idx] != pg)
-		return 0;
-
-	*pgroup = group;
-	*pidx = idx;
-
-	return 1;
-}
-
 /*
  * This is the amount of packet we copy rather than map, so that the
  * guest can't fiddle with the contents of the headers while we do
@@ -398,8 +338,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
-	unsigned int uninitialized_var(group), uninitialized_var(idx);
-	int foreign = get_page_ext(page, &group, &idx);
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
@@ -427,10 +367,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = &xen_netbk[group];
-			struct pending_tx_info *src_pend;
-
-			src_pend = &netbk->pending_tx_info[idx];
+			struct pending_tx_info *src_pend = to_txinfo(idx);
 
 			copy_gop->source.domid = src_pend->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
@@ -906,11 +843,11 @@ static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
 					 u16 pending_idx)
 {
 	struct page *page;
-	page = alloc_page(GFP_KERNEL|__GFP_COLD);
+	int idx;
+	page = page_pool_get(netbk, &idx);
 	if (!page)
 		return NULL;
-	set_page_ext(page, netbk, pending_idx);
-	netbk->mmap_pages[pending_idx] = page;
+	netbk->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
@@ -931,8 +868,8 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	for (i = start; i < shinfo->nr_frags; i++, txp++) {
 		struct page *page;
 		pending_ring_idx_t index;
-		struct pending_tx_info *pending_tx_info =
-			netbk->pending_tx_info;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		index = pending_index(netbk->pending_cons++);
 		pending_idx = netbk->pending_ring[index];
@@ -940,6 +877,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		if (!page)
 			return NULL;
 
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txp->offset;
@@ -953,9 +893,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 
 		gop++;
 
-		memcpy(&pending_tx_info[pending_idx].req, txp, sizeof(*txp));
+		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
 		xenvif_get(vif);
-		pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -968,8 +908,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
+	struct pending_tx_info *pending_tx_info;
+	int idx;
+	struct xenvif *vif = NULL;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -980,7 +921,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
 		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[index];
+		pending_tx_info = to_txinfo(idx);
+		txp = &pending_tx_info->req;
+		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
 		xenvif_put(vif);
@@ -1005,7 +949,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		txp = &to_txinfo(idx)->req;
+		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
@@ -1042,10 +988,15 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		struct xen_netif_tx_request *txp;
 		struct page *page;
 		u16 pending_idx;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		txp = &pending_tx_info->req;
 		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
@@ -1053,7 +1004,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(netbk->mmap_pages[pending_idx]);
+		get_page(page);
 		xen_netbk_idx_release(netbk, pending_idx);
 	}
 }
@@ -1233,6 +1184,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int work_to_do;
 		unsigned int data_len;
 		pending_ring_idx_t index;
+		int pool_idx;
+		struct pending_tx_info *pending_tx_info;
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
@@ -1347,9 +1300,12 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		gop++;
 
-		memcpy(&netbk->pending_tx_info[pending_idx].req,
+		pool_idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(pool_idx);
+
+		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		netbk->pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1397,10 +1353,16 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = *((u16 *)skb->data);
-		vif = netbk->pending_tx_info[pending_idx].vif;
-		txp = &netbk->pending_tx_info[pending_idx].req;
+
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		vif = pending_tx_info->vif;
+		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
 		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
@@ -1480,12 +1442,14 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
+	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == NULL)
+	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	pending_tx_info = &netbk->pending_tx_info[pending_idx];
+	idx = netbk->mmap_pages[pending_idx];
+	pending_tx_info = to_txinfo(idx);
 
 	vif = pending_tx_info->vif;
 
@@ -1496,9 +1460,9 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	xenvif_put(vif);
 
-	netbk->mmap_pages[pending_idx]->mapping = 0;
-	put_page(netbk->mmap_pages[pending_idx]);
-	netbk->mmap_pages[pending_idx] = NULL;
+	page_pool_put(netbk->mmap_pages[pending_idx]);
+
+	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1681,19 +1645,21 @@ static int __init netback_init(void)
 		wake_up_process(netbk->task);
 	}
 
-	rc = xenvif_xenbus_init();
+	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto pool_failed_init;
+
 	return 0;
 
+pool_failed_init:
+	page_pool_destroy();
 failed_init:
 	while (--group >= 0) {
 		struct xen_netbk *netbk = &xen_netbk[group];
-		for (i = 0; i < MAX_PENDING_REQS; i++) {
-			if (netbk->mmap_pages[i])
-				__free_page(netbk->mmap_pages[i]);
-		}
 		del_timer(&netbk->net_timer);
 		kthread_stop(netbk->task);
 	}
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
new file mode 100644
index 0000000..294f48b
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.c
@@ -0,0 +1,185 @@
+/*
+ * Global page pool for netback.
+ *
+ * Wei Liu <wei.liu2@citrix.com>
+ * Copyright (c) Citrix Systems
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "common.h"
+#include "page_pool.h"
+#include <asm/xen/page.h>
+
+static idx_t free_head;
+static int free_count;
+static unsigned long pool_size;
+static DEFINE_SPINLOCK(pool_lock);
+static struct page_pool_entry *pool;
+
+static int get_free_entry(void)
+{
+	int idx;
+
+	spin_lock(&pool_lock);
+
+	if (free_count == 0) {
+		spin_unlock(&pool_lock);
+		return -ENOSPC;
+	}
+
+	idx = free_head;
+	free_count--;
+	free_head = pool[idx].u.fl;
+	pool[idx].u.fl = INVALID_ENTRY;
+
+	spin_unlock(&pool_lock);
+
+	return idx;
+}
+
+static void put_free_entry(idx_t idx)
+{
+	spin_lock(&pool_lock);
+
+	pool[idx].u.fl = free_head;
+	free_head = idx;
+	free_count++;
+
+	spin_unlock(&pool_lock);
+}
+
+static inline void set_page_ext(struct page *pg, unsigned int idx)
+{
+	union page_ext ext = { .idx = idx };
+
+	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
+	pg->mapping = ext.mapping;
+}
+
+static int get_page_ext(struct page *pg, unsigned int *pidx)
+{
+	union page_ext ext = { .mapping = pg->mapping };
+	int idx;
+
+	idx = ext.idx;
+
+	if ((idx < 0) || (idx >= pool_size))
+		return 0;
+
+	if (pool[idx].page != pg)
+		return 0;
+
+	*pidx = idx;
+
+	return 1;
+}
+
+int is_in_pool(struct page *page, int *pidx)
+{
+	return get_page_ext(page, pidx);
+}
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+{
+	int idx;
+	struct page *page;
+
+	idx = get_free_entry();
+	if (idx < 0)
+		return NULL;
+	page = alloc_page(GFP_ATOMIC);
+
+	if (page == NULL) {
+		put_free_entry(idx);
+		return NULL;
+	}
+
+	set_page_ext(page, idx);
+	pool[idx].u.netbk = netbk;
+	pool[idx].page = page;
+
+	*pidx = idx;
+
+	return page;
+}
+
+void page_pool_put(int idx)
+{
+	struct page *page = pool[idx].page;
+
+	pool[idx].page = NULL;
+	pool[idx].u.netbk = NULL;
+	page->mapping = 0;
+	put_page(page);
+	put_free_entry(idx);
+}
+
+int page_pool_init()
+{
+	int cpus = 0;
+	int i;
+
+	cpus = num_online_cpus();
+	pool_size = cpus * ENTRIES_PER_CPU;
+
+	pool = vzalloc(sizeof(struct page_pool_entry) * pool_size);
+
+	if (!pool)
+		return -ENOMEM;
+
+	for (i = 0; i < pool_size - 1; i++)
+		pool[i].u.fl = i+1;
+	pool[pool_size-1].u.fl = INVALID_ENTRY;
+	free_count = pool_size;
+	free_head = 0;
+
+	return 0;
+}
+
+void page_pool_destroy()
+{
+	int i;
+	for (i = 0; i < pool_size; i++)
+		if (pool[i].page)
+			put_page(pool[i].page);
+
+	vfree(pool);
+}
+
+struct page *to_page(int idx)
+{
+	return pool[idx].page;
+}
+
+struct xen_netbk *to_netbk(int idx)
+{
+	return pool[idx].u.netbk;
+}
+
+struct pending_tx_info *to_txinfo(int idx)
+{
+	return &pool[idx].tx_info;
+}
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
new file mode 100644
index 0000000..572b037
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.h
@@ -0,0 +1,63 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __PAGE_POOL_H__
+#define __PAGE_POOL_H__
+
+#include "common.h"
+
+typedef uint32_t idx_t;
+
+#define ENTRIES_PER_CPU (1024)
+#define INVALID_ENTRY 0xffffffff
+
+struct page_pool_entry {
+	struct page *page;
+	struct pending_tx_info tx_info;
+	union {
+		struct xen_netbk *netbk;
+		idx_t             fl;
+	} u;
+};
+
+union page_ext {
+	idx_t idx;
+	void *mapping;
+};
+
+int  page_pool_init(void);
+void page_pool_destroy(void);
+
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+void         page_pool_put(int idx);
+int          is_in_pool(struct page *page, int *pidx);
+
+struct page            *to_page(int idx);
+struct xen_netbk       *to_netbk(int idx);
+struct pending_tx_info *to_txinfo(int idx);
+
+#endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Ob-0002xa-QL; Tue, 17 Jan 2012 13:48:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9Oa-0002wd-6P
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18955 invoked from network); 17 Jan 2012 13:47: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;
	17 Jan 2012 13:47:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838511"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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; Tue, 17 Jan 2012 08:48:13 -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 q0HDm0fY005778;
	Tue, 17 Jan 2012 05:48:11 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:02 +0000
Message-ID: <1326808024-3744-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 6/8] netback: melt xen_netbk into xenvif
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, there is no need to keep xen_netbk and xenvif
separated.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   36 +++---
 drivers/net/xen-netback/interface.c |   36 +++----
 drivers/net/xen-netback/netback.c   |  207 +++++++++++++----------------------
 drivers/net/xen-netback/page_pool.c |   10 +-
 drivers/net/xen-netback/page_pool.h |   13 ++-
 5 files changed, 120 insertions(+), 182 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 3b85563..17d4e1a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,34 +45,29 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#include "page_pool.h"
+
 struct netbk_rx_meta {
 	int id;
 	int size;
 	int gso_size;
 };
 
-#define MAX_PENDING_REQS 256
-
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-};
-typedef unsigned int pending_ring_idx_t;
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
 
-struct xen_netbk;
+#define MAX_PENDING_REQS 256
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
-	/* Reference to netback processing backend. */
-	struct xen_netbk *netbk;
-
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -115,6 +110,16 @@ struct xenvif {
 
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
+
+	struct sk_buff_head rx_queue;
+	struct sk_buff_head tx_queue;
+
+	idx_t mmap_pages[MAX_PENDING_REQS];
+
+	pending_ring_idx_t pending_prod;
+	pending_ring_idx_t pending_cons;
+
+	u16 pending_ring[MAX_PENDING_REQS];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +127,6 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
@@ -161,12 +163,8 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-/* Allocate and free xen_netbk structure */
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
-void xen_netbk_free_netbk(struct xen_netbk *netbk);
-
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
-void xen_netbk_rx_action(struct xen_netbk *netbk);
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
+void xen_netbk_rx_action(struct xenvif *vif);
 
 int xen_netbk_kthread(void *data);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 7c86187..11e638b 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -55,9 +55,6 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (vif->netbk == NULL)
-		return IRQ_NONE;
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
@@ -72,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+	xen_netbk_tx_action(vif, &work_done, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -95,7 +92,8 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	BUG_ON(skb->dev != dev);
 
-	if (vif->netbk == NULL)
+	/* Drop the packet if vif is not ready */
+	if (vif->task == NULL)
 		goto drop;
 
 	/* Drop the packet if the target domain has no receive buffers. */
@@ -257,6 +255,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	int err;
 	struct net_device *dev;
 	struct xenvif *vif;
+	int i;
 	char name[IFNAMSIZ] = {};
 
 	snprintf(name, IFNAMSIZ - 1, "vif%u.%u", domid, handle);
@@ -271,7 +270,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk = NULL;
 
 	vif->can_sg = 1;
 	vif->csum = 1;
@@ -290,6 +288,17 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 
 	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
 
+	skb_queue_head_init(&vif->rx_queue);
+	skb_queue_head_init(&vif->tx_queue);
+
+	vif->pending_cons = 0;
+	vif->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->mmap_pages[i] = INVALID_ENTRY;
+
 	/*
 	 * Initialise a dummy MAC address. We choose the numerically
 	 * largest non-broadcast address to prevent the address getting
@@ -337,14 +346,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	vif->netbk = xen_netbk_alloc_netbk(vif);
-	if (!vif->netbk) {
-		pr_warn("Could not allocate xen_netbk\n");
-		err = -ENOMEM;
-		goto err_unbind;
-	}
-
-
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xen_netbk_kthread,
 				   (void *)vif,
@@ -352,7 +353,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (IS_ERR(vif->task)) {
 		pr_warn("Could not create kthread\n");
 		err = PTR_ERR(vif->task);
-		goto err_free_netbk;
+		goto err_unbind;
 	}
 
 	rtnl_lock();
@@ -367,8 +368,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	wake_up_process(vif->task);
 
 	return 0;
-err_free_netbk:
-	xen_netbk_free_netbk(vif->netbk);
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
@@ -392,9 +391,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	if (vif->task)
 		kthread_stop(vif->task);
 
-	if (vif->netbk)
-		xen_netbk_free_netbk(vif->netbk);
-
 	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 714f508..1842e4e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -59,28 +59,13 @@ struct gnttab_copy *tx_copy_ops;
 struct gnttab_copy *grant_copy_op;
 struct netbk_rx_meta *meta;
 
-
-struct xen_netbk {
-	struct sk_buff_head rx_queue;
-	struct sk_buff_head tx_queue;
-
-	idx_t mmap_pages[MAX_PENDING_REQS];
-
-	pending_ring_idx_t pending_prod;
-	pending_ring_idx_t pending_cons;
-
-	struct xenvif *vif;
-
-	u16 pending_ring[MAX_PENDING_REQS];
-};
-
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
 
-static inline int tx_work_todo(struct xen_netbk *netbk);
-static inline int rx_work_todo(struct xen_netbk *netbk);
+static inline int tx_work_todo(struct xenvif *vif);
+static inline int rx_work_todo(struct xenvif *vif);
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
@@ -89,16 +74,16 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      size,
 					     u16      flags);
 
-static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
+static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
-	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
+	return page_to_pfn(to_page(vif->mmap_pages[idx]));
 }
 
-static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
+static inline unsigned long idx_to_kaddr(struct xenvif *vif,
 					 u16 idx)
 {
-	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
+	return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
 }
 
 /*
@@ -126,10 +111,10 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 	return i & (MAX_PENDING_REQS-1);
 }
 
-static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
+static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 {
 	return MAX_PENDING_REQS -
-		netbk->pending_prod + netbk->pending_cons;
+		vif->pending_prod + vif->pending_cons;
 }
 
 static int max_required_rx_slots(struct xenvif *vif)
@@ -475,16 +460,13 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xenvif *vif)
 {
-	struct xenvif *vif = netbk->vif;
-
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xen_netbk *netbk)
+void xen_netbk_rx_action(struct xenvif *vif)
 {
-	struct xenvif *vif = NULL;
 	s8 status;
 	u16 flags;
 	struct xen_netif_rx_response *resp;
@@ -510,7 +492,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	count = 0;
 
-	while ((skb = skb_dequeue(&netbk->rx_queue)) != NULL) {
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
 		vif = netdev_priv(skb->dev);
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
@@ -542,7 +524,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	while ((skb = __skb_dequeue(&rxq)) != NULL) {
 		sco = (struct skb_cb_overlay *)skb->cb;
 
-		vif = netdev_priv(skb->dev);
+		/* vif = netdev_priv(skb->dev); */
 
 		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
@@ -615,8 +597,8 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
 
-	if (!skb_queue_empty(&netbk->rx_queue))
-		xen_netbk_kick_thread(netbk);
+	if (!skb_queue_empty(&vif->rx_queue))
+		xen_netbk_kick_thread(vif);
 
 	put_cpu_ptr(gco);
 	put_cpu_ptr(m);
@@ -624,11 +606,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	struct xen_netbk *netbk = vif->netbk;
-
-	skb_queue_tail(&netbk->rx_queue, skb);
+	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(netbk);
+	xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
@@ -727,21 +707,20 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
+static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 					 struct sk_buff *skb,
 					 u16 pending_idx)
 {
 	struct page *page;
 	int idx;
-	page = page_pool_get(netbk, &idx);
+	page = page_pool_get(vif, &idx);
 	if (!page)
 		return NULL;
-	netbk->mmap_pages[pending_idx] = idx;
+	vif->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
-						  struct xenvif *vif,
+static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 						  struct sk_buff *skb,
 						  struct xen_netif_tx_request *txp,
 						  struct gnttab_copy *gop)
@@ -760,13 +739,13 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		int idx;
 		struct pending_tx_info *pending_tx_info;
 
-		index = pending_index(netbk->pending_cons++);
-		pending_idx = netbk->pending_ring[index];
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		gop->source.u.ref = txp->gref;
@@ -790,7 +769,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
+static int xen_netbk_tx_check_gop(struct xenvif *vif,
 				  struct sk_buff *skb,
 				  struct gnttab_copy **gopp)
 {
@@ -798,8 +777,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = netbk->vif;
-
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -809,12 +786,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	err = gop->status;
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		idx = netbk->mmap_pages[index];
+		index = pending_index(vif->pending_prod++);
+		idx = vif->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
+		vif->pending_ring[index] = pending_idx;
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -831,16 +808,16 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(vif, pending_idx);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
+		index = pending_index(vif->pending_prod++);
+		vif->pending_ring[index] = pending_idx;
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -848,10 +825,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -862,7 +839,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
+static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -878,11 +855,11 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
-		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
+		page = virt_to_page(idx_to_kaddr(vif, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
 		skb->data_len += txp->size;
@@ -890,7 +867,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 	}
 }
 
@@ -1051,15 +1028,14 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 					struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
-	struct xenvif *vif = netbk->vif;
 
-	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
+	while ((nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1127,8 +1103,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 			break;
 		}
 
-		index = pending_index(netbk->pending_cons);
-		pending_idx = netbk->pending_ring[index];
+		index = pending_index(vif->pending_cons);
+		pending_idx = vif->pending_ring[index];
 
 		data_len = (txreq.size > PKT_PROT_LEN &&
 			    ret < MAX_SKB_FRAGS) ?
@@ -1158,7 +1134,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
@@ -1178,7 +1154,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 
 		gop++;
 
-		pool_idx = netbk->mmap_pages[pending_idx];
+		pool_idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(pool_idx);
 
 		memcpy(&pending_tx_info->req,
@@ -1198,11 +1174,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
+		__skb_queue_tail(&vif->tx_queue, skb);
 
-		netbk->pending_cons++;
+		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(netbk, vif,
+		request_gop = xen_netbk_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
@@ -1221,16 +1197,15 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 	return gop - tco;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+static void xen_netbk_tx_submit(struct xenvif *vif,
 				struct gnttab_copy *tco,
 				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
-	struct xenvif *vif = netbk->vif;
 
 	while ((*work_done < budget) &&
-	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
 		unsigned data_len;
@@ -1239,13 +1214,13 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		pending_idx = *((u16 *)skb->data);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
+		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1254,7 +1229,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		data_len = skb->len;
 		memcpy(skb->data,
-		       (void *)(idx_to_kaddr(netbk, pending_idx)|txp->offset),
+		       (void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
 		       data_len);
 		if (data_len < txp->size) {
 			/* Append the packet payload as a fragment. */
@@ -1262,7 +1237,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1270,7 +1245,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(netbk, skb);
+		xen_netbk_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1302,18 +1277,18 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 	struct gnttab_copy *tco;
 
-	if (unlikely(!tx_work_todo(netbk)))
+	if (unlikely(!tx_work_todo(vif)))
 		return;
 
 	tco = get_cpu_ptr(tx_copy_ops);
 
-	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+	nr_gops = xen_netbk_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_ptr(tco);
@@ -1323,32 +1298,31 @@ void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, tco, work_done, budget);
+	xen_netbk_tx_submit(vif, tco, work_done, budget);
 	put_cpu_ptr(tco);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
 {
-	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
+	if (vif->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	idx = netbk->mmap_pages[pending_idx];
+	idx = vif->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
-	index = pending_index(netbk->pending_prod++);
-	netbk->pending_ring[index] = pending_idx;
+	index = pending_index(vif->pending_prod++);
+	vif->pending_ring[index] = pending_idx;
 
-	page_pool_put(netbk->mmap_pages[pending_idx]);
+	page_pool_put(vif->mmap_pages[pending_idx]);
 
-	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
+	vif->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1395,15 +1369,15 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 	return resp;
 }
 
-static inline int rx_work_todo(struct xen_netbk *netbk)
+static inline int rx_work_todo(struct xenvif *vif)
 {
-	return !skb_queue_empty(&netbk->rx_queue);
+	return !skb_queue_empty(&vif->rx_queue);
 }
 
-static inline int tx_work_todo(struct xen_netbk *netbk)
+static inline int tx_work_todo(struct xenvif *vif)
 {
-	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
-	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
+	    (nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
@@ -1454,54 +1428,21 @@ err:
 	return err;
 }
 
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
-{
-	int i;
-	struct xen_netbk *netbk;
-
-	netbk = vzalloc(sizeof(struct xen_netbk));
-	if (!netbk) {
-		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return NULL;
-	}
-
-	netbk->vif = vif;
-
-	skb_queue_head_init(&netbk->rx_queue);
-	skb_queue_head_init(&netbk->tx_queue);
-
-	netbk->pending_cons = 0;
-	netbk->pending_prod = MAX_PENDING_REQS;
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->pending_ring[i] = i;
-
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->mmap_pages[i] = INVALID_ENTRY;
-
-	return netbk;
-}
-
-void xen_netbk_free_netbk(struct xen_netbk *netbk)
-{
-	vfree(netbk);
-}
-
 int xen_netbk_kthread(void *data)
 {
 	struct xenvif *vif = data;
-	struct xen_netbk *netbk = vif->netbk;
 
 	while (!kthread_should_stop()) {
 		wait_event_interruptible(vif->wq,
-					 rx_work_todo(netbk) ||
+					 rx_work_todo(vif) ||
 					 kthread_should_stop());
 		cond_resched();
 
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
+		if (rx_work_todo(vif))
+			xen_netbk_rx_action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
index 294f48b..ce00a93 100644
--- a/drivers/net/xen-netback/page_pool.c
+++ b/drivers/net/xen-netback/page_pool.c
@@ -102,7 +102,7 @@ int is_in_pool(struct page *page, int *pidx)
 	return get_page_ext(page, pidx);
 }
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+struct page *page_pool_get(struct xenvif *vif, int *pidx)
 {
 	int idx;
 	struct page *page;
@@ -118,7 +118,7 @@ struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
 	}
 
 	set_page_ext(page, idx);
-	pool[idx].u.netbk = netbk;
+	pool[idx].u.vif = vif;
 	pool[idx].page = page;
 
 	*pidx = idx;
@@ -131,7 +131,7 @@ void page_pool_put(int idx)
 	struct page *page = pool[idx].page;
 
 	pool[idx].page = NULL;
-	pool[idx].u.netbk = NULL;
+	pool[idx].u.vif = NULL;
 	page->mapping = 0;
 	put_page(page);
 	put_free_entry(idx);
@@ -174,9 +174,9 @@ struct page *to_page(int idx)
 	return pool[idx].page;
 }
 
-struct xen_netbk *to_netbk(int idx)
+struct xenvif *to_vif(int idx)
 {
-	return pool[idx].u.netbk;
+	return pool[idx].u.vif;
 }
 
 struct pending_tx_info *to_txinfo(int idx)
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
index 572b037..efae17c 100644
--- a/drivers/net/xen-netback/page_pool.h
+++ b/drivers/net/xen-netback/page_pool.h
@@ -27,7 +27,10 @@
 #ifndef __PAGE_POOL_H__
 #define __PAGE_POOL_H__
 
-#include "common.h"
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+};
+typedef unsigned int pending_ring_idx_t;
 
 typedef uint32_t idx_t;
 
@@ -38,8 +41,8 @@ struct page_pool_entry {
 	struct page *page;
 	struct pending_tx_info tx_info;
 	union {
-		struct xen_netbk *netbk;
-		idx_t             fl;
+		struct xenvif *vif;
+		idx_t          fl;
 	} u;
 };
 
@@ -52,12 +55,12 @@ int  page_pool_init(void);
 void page_pool_destroy(void);
 
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+struct page *page_pool_get(struct xenvif *vif, int *pidx);
 void         page_pool_put(int idx);
 int          is_in_pool(struct page *page, int *pidx);
 
 struct page            *to_page(int idx);
-struct xen_netbk       *to_netbk(int idx);
+struct xenvif          *to_vif(int idx);
 struct pending_tx_info *to_txinfo(int idx);
 
 #endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Ob-0002xa-QL; Tue, 17 Jan 2012 13:48:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9Oa-0002wd-6P
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18955 invoked from network); 17 Jan 2012 13:47: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;
	17 Jan 2012 13:47:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838511"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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; Tue, 17 Jan 2012 08:48:13 -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 q0HDm0fY005778;
	Tue, 17 Jan 2012 05:48:11 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:02 +0000
Message-ID: <1326808024-3744-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 6/8] netback: melt xen_netbk into xenvif
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, there is no need to keep xen_netbk and xenvif
separated.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   36 +++---
 drivers/net/xen-netback/interface.c |   36 +++----
 drivers/net/xen-netback/netback.c   |  207 +++++++++++++----------------------
 drivers/net/xen-netback/page_pool.c |   10 +-
 drivers/net/xen-netback/page_pool.h |   13 ++-
 5 files changed, 120 insertions(+), 182 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 3b85563..17d4e1a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,34 +45,29 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#include "page_pool.h"
+
 struct netbk_rx_meta {
 	int id;
 	int size;
 	int gso_size;
 };
 
-#define MAX_PENDING_REQS 256
-
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-};
-typedef unsigned int pending_ring_idx_t;
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
 
-struct xen_netbk;
+#define MAX_PENDING_REQS 256
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
-	/* Reference to netback processing backend. */
-	struct xen_netbk *netbk;
-
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -115,6 +110,16 @@ struct xenvif {
 
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
+
+	struct sk_buff_head rx_queue;
+	struct sk_buff_head tx_queue;
+
+	idx_t mmap_pages[MAX_PENDING_REQS];
+
+	pending_ring_idx_t pending_prod;
+	pending_ring_idx_t pending_cons;
+
+	u16 pending_ring[MAX_PENDING_REQS];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +127,6 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
@@ -161,12 +163,8 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-/* Allocate and free xen_netbk structure */
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
-void xen_netbk_free_netbk(struct xen_netbk *netbk);
-
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
-void xen_netbk_rx_action(struct xen_netbk *netbk);
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
+void xen_netbk_rx_action(struct xenvif *vif);
 
 int xen_netbk_kthread(void *data);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 7c86187..11e638b 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -55,9 +55,6 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (vif->netbk == NULL)
-		return IRQ_NONE;
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
@@ -72,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+	xen_netbk_tx_action(vif, &work_done, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -95,7 +92,8 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	BUG_ON(skb->dev != dev);
 
-	if (vif->netbk == NULL)
+	/* Drop the packet if vif is not ready */
+	if (vif->task == NULL)
 		goto drop;
 
 	/* Drop the packet if the target domain has no receive buffers. */
@@ -257,6 +255,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	int err;
 	struct net_device *dev;
 	struct xenvif *vif;
+	int i;
 	char name[IFNAMSIZ] = {};
 
 	snprintf(name, IFNAMSIZ - 1, "vif%u.%u", domid, handle);
@@ -271,7 +270,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk = NULL;
 
 	vif->can_sg = 1;
 	vif->csum = 1;
@@ -290,6 +288,17 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 
 	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
 
+	skb_queue_head_init(&vif->rx_queue);
+	skb_queue_head_init(&vif->tx_queue);
+
+	vif->pending_cons = 0;
+	vif->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->mmap_pages[i] = INVALID_ENTRY;
+
 	/*
 	 * Initialise a dummy MAC address. We choose the numerically
 	 * largest non-broadcast address to prevent the address getting
@@ -337,14 +346,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	vif->netbk = xen_netbk_alloc_netbk(vif);
-	if (!vif->netbk) {
-		pr_warn("Could not allocate xen_netbk\n");
-		err = -ENOMEM;
-		goto err_unbind;
-	}
-
-
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xen_netbk_kthread,
 				   (void *)vif,
@@ -352,7 +353,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (IS_ERR(vif->task)) {
 		pr_warn("Could not create kthread\n");
 		err = PTR_ERR(vif->task);
-		goto err_free_netbk;
+		goto err_unbind;
 	}
 
 	rtnl_lock();
@@ -367,8 +368,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	wake_up_process(vif->task);
 
 	return 0;
-err_free_netbk:
-	xen_netbk_free_netbk(vif->netbk);
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
@@ -392,9 +391,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	if (vif->task)
 		kthread_stop(vif->task);
 
-	if (vif->netbk)
-		xen_netbk_free_netbk(vif->netbk);
-
 	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 714f508..1842e4e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -59,28 +59,13 @@ struct gnttab_copy *tx_copy_ops;
 struct gnttab_copy *grant_copy_op;
 struct netbk_rx_meta *meta;
 
-
-struct xen_netbk {
-	struct sk_buff_head rx_queue;
-	struct sk_buff_head tx_queue;
-
-	idx_t mmap_pages[MAX_PENDING_REQS];
-
-	pending_ring_idx_t pending_prod;
-	pending_ring_idx_t pending_cons;
-
-	struct xenvif *vif;
-
-	u16 pending_ring[MAX_PENDING_REQS];
-};
-
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
 
-static inline int tx_work_todo(struct xen_netbk *netbk);
-static inline int rx_work_todo(struct xen_netbk *netbk);
+static inline int tx_work_todo(struct xenvif *vif);
+static inline int rx_work_todo(struct xenvif *vif);
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
@@ -89,16 +74,16 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      size,
 					     u16      flags);
 
-static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
+static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
-	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
+	return page_to_pfn(to_page(vif->mmap_pages[idx]));
 }
 
-static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
+static inline unsigned long idx_to_kaddr(struct xenvif *vif,
 					 u16 idx)
 {
-	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
+	return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
 }
 
 /*
@@ -126,10 +111,10 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 	return i & (MAX_PENDING_REQS-1);
 }
 
-static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
+static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 {
 	return MAX_PENDING_REQS -
-		netbk->pending_prod + netbk->pending_cons;
+		vif->pending_prod + vif->pending_cons;
 }
 
 static int max_required_rx_slots(struct xenvif *vif)
@@ -475,16 +460,13 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xenvif *vif)
 {
-	struct xenvif *vif = netbk->vif;
-
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xen_netbk *netbk)
+void xen_netbk_rx_action(struct xenvif *vif)
 {
-	struct xenvif *vif = NULL;
 	s8 status;
 	u16 flags;
 	struct xen_netif_rx_response *resp;
@@ -510,7 +492,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	count = 0;
 
-	while ((skb = skb_dequeue(&netbk->rx_queue)) != NULL) {
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
 		vif = netdev_priv(skb->dev);
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
@@ -542,7 +524,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	while ((skb = __skb_dequeue(&rxq)) != NULL) {
 		sco = (struct skb_cb_overlay *)skb->cb;
 
-		vif = netdev_priv(skb->dev);
+		/* vif = netdev_priv(skb->dev); */
 
 		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
@@ -615,8 +597,8 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
 
-	if (!skb_queue_empty(&netbk->rx_queue))
-		xen_netbk_kick_thread(netbk);
+	if (!skb_queue_empty(&vif->rx_queue))
+		xen_netbk_kick_thread(vif);
 
 	put_cpu_ptr(gco);
 	put_cpu_ptr(m);
@@ -624,11 +606,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	struct xen_netbk *netbk = vif->netbk;
-
-	skb_queue_tail(&netbk->rx_queue, skb);
+	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(netbk);
+	xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
@@ -727,21 +707,20 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
+static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 					 struct sk_buff *skb,
 					 u16 pending_idx)
 {
 	struct page *page;
 	int idx;
-	page = page_pool_get(netbk, &idx);
+	page = page_pool_get(vif, &idx);
 	if (!page)
 		return NULL;
-	netbk->mmap_pages[pending_idx] = idx;
+	vif->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
-						  struct xenvif *vif,
+static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 						  struct sk_buff *skb,
 						  struct xen_netif_tx_request *txp,
 						  struct gnttab_copy *gop)
@@ -760,13 +739,13 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		int idx;
 		struct pending_tx_info *pending_tx_info;
 
-		index = pending_index(netbk->pending_cons++);
-		pending_idx = netbk->pending_ring[index];
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		gop->source.u.ref = txp->gref;
@@ -790,7 +769,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
+static int xen_netbk_tx_check_gop(struct xenvif *vif,
 				  struct sk_buff *skb,
 				  struct gnttab_copy **gopp)
 {
@@ -798,8 +777,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = netbk->vif;
-
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -809,12 +786,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	err = gop->status;
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		idx = netbk->mmap_pages[index];
+		index = pending_index(vif->pending_prod++);
+		idx = vif->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
+		vif->pending_ring[index] = pending_idx;
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -831,16 +808,16 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(vif, pending_idx);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
+		index = pending_index(vif->pending_prod++);
+		vif->pending_ring[index] = pending_idx;
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -848,10 +825,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -862,7 +839,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
+static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -878,11 +855,11 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
-		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
+		page = virt_to_page(idx_to_kaddr(vif, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
 		skb->data_len += txp->size;
@@ -890,7 +867,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 	}
 }
 
@@ -1051,15 +1028,14 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 					struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
-	struct xenvif *vif = netbk->vif;
 
-	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
+	while ((nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1127,8 +1103,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 			break;
 		}
 
-		index = pending_index(netbk->pending_cons);
-		pending_idx = netbk->pending_ring[index];
+		index = pending_index(vif->pending_cons);
+		pending_idx = vif->pending_ring[index];
 
 		data_len = (txreq.size > PKT_PROT_LEN &&
 			    ret < MAX_SKB_FRAGS) ?
@@ -1158,7 +1134,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
@@ -1178,7 +1154,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 
 		gop++;
 
-		pool_idx = netbk->mmap_pages[pending_idx];
+		pool_idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(pool_idx);
 
 		memcpy(&pending_tx_info->req,
@@ -1198,11 +1174,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
+		__skb_queue_tail(&vif->tx_queue, skb);
 
-		netbk->pending_cons++;
+		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(netbk, vif,
+		request_gop = xen_netbk_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
@@ -1221,16 +1197,15 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 	return gop - tco;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+static void xen_netbk_tx_submit(struct xenvif *vif,
 				struct gnttab_copy *tco,
 				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
-	struct xenvif *vif = netbk->vif;
 
 	while ((*work_done < budget) &&
-	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
 		unsigned data_len;
@@ -1239,13 +1214,13 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		pending_idx = *((u16 *)skb->data);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
+		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1254,7 +1229,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		data_len = skb->len;
 		memcpy(skb->data,
-		       (void *)(idx_to_kaddr(netbk, pending_idx)|txp->offset),
+		       (void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
 		       data_len);
 		if (data_len < txp->size) {
 			/* Append the packet payload as a fragment. */
@@ -1262,7 +1237,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1270,7 +1245,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(netbk, skb);
+		xen_netbk_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1302,18 +1277,18 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 	struct gnttab_copy *tco;
 
-	if (unlikely(!tx_work_todo(netbk)))
+	if (unlikely(!tx_work_todo(vif)))
 		return;
 
 	tco = get_cpu_ptr(tx_copy_ops);
 
-	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+	nr_gops = xen_netbk_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_ptr(tco);
@@ -1323,32 +1298,31 @@ void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, tco, work_done, budget);
+	xen_netbk_tx_submit(vif, tco, work_done, budget);
 	put_cpu_ptr(tco);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
 {
-	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
+	if (vif->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	idx = netbk->mmap_pages[pending_idx];
+	idx = vif->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
-	index = pending_index(netbk->pending_prod++);
-	netbk->pending_ring[index] = pending_idx;
+	index = pending_index(vif->pending_prod++);
+	vif->pending_ring[index] = pending_idx;
 
-	page_pool_put(netbk->mmap_pages[pending_idx]);
+	page_pool_put(vif->mmap_pages[pending_idx]);
 
-	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
+	vif->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1395,15 +1369,15 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 	return resp;
 }
 
-static inline int rx_work_todo(struct xen_netbk *netbk)
+static inline int rx_work_todo(struct xenvif *vif)
 {
-	return !skb_queue_empty(&netbk->rx_queue);
+	return !skb_queue_empty(&vif->rx_queue);
 }
 
-static inline int tx_work_todo(struct xen_netbk *netbk)
+static inline int tx_work_todo(struct xenvif *vif)
 {
-	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
-	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
+	    (nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
@@ -1454,54 +1428,21 @@ err:
 	return err;
 }
 
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
-{
-	int i;
-	struct xen_netbk *netbk;
-
-	netbk = vzalloc(sizeof(struct xen_netbk));
-	if (!netbk) {
-		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return NULL;
-	}
-
-	netbk->vif = vif;
-
-	skb_queue_head_init(&netbk->rx_queue);
-	skb_queue_head_init(&netbk->tx_queue);
-
-	netbk->pending_cons = 0;
-	netbk->pending_prod = MAX_PENDING_REQS;
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->pending_ring[i] = i;
-
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->mmap_pages[i] = INVALID_ENTRY;
-
-	return netbk;
-}
-
-void xen_netbk_free_netbk(struct xen_netbk *netbk)
-{
-	vfree(netbk);
-}
-
 int xen_netbk_kthread(void *data)
 {
 	struct xenvif *vif = data;
-	struct xen_netbk *netbk = vif->netbk;
 
 	while (!kthread_should_stop()) {
 		wait_event_interruptible(vif->wq,
-					 rx_work_todo(netbk) ||
+					 rx_work_todo(vif) ||
 					 kthread_should_stop());
 		cond_resched();
 
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
+		if (rx_work_todo(vif))
+			xen_netbk_rx_action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
index 294f48b..ce00a93 100644
--- a/drivers/net/xen-netback/page_pool.c
+++ b/drivers/net/xen-netback/page_pool.c
@@ -102,7 +102,7 @@ int is_in_pool(struct page *page, int *pidx)
 	return get_page_ext(page, pidx);
 }
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+struct page *page_pool_get(struct xenvif *vif, int *pidx)
 {
 	int idx;
 	struct page *page;
@@ -118,7 +118,7 @@ struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
 	}
 
 	set_page_ext(page, idx);
-	pool[idx].u.netbk = netbk;
+	pool[idx].u.vif = vif;
 	pool[idx].page = page;
 
 	*pidx = idx;
@@ -131,7 +131,7 @@ void page_pool_put(int idx)
 	struct page *page = pool[idx].page;
 
 	pool[idx].page = NULL;
-	pool[idx].u.netbk = NULL;
+	pool[idx].u.vif = NULL;
 	page->mapping = 0;
 	put_page(page);
 	put_free_entry(idx);
@@ -174,9 +174,9 @@ struct page *to_page(int idx)
 	return pool[idx].page;
 }
 
-struct xen_netbk *to_netbk(int idx)
+struct xenvif *to_vif(int idx)
 {
-	return pool[idx].u.netbk;
+	return pool[idx].u.vif;
 }
 
 struct pending_tx_info *to_txinfo(int idx)
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
index 572b037..efae17c 100644
--- a/drivers/net/xen-netback/page_pool.h
+++ b/drivers/net/xen-netback/page_pool.h
@@ -27,7 +27,10 @@
 #ifndef __PAGE_POOL_H__
 #define __PAGE_POOL_H__
 
-#include "common.h"
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+};
+typedef unsigned int pending_ring_idx_t;
 
 typedef uint32_t idx_t;
 
@@ -38,8 +41,8 @@ struct page_pool_entry {
 	struct page *page;
 	struct pending_tx_info tx_info;
 	union {
-		struct xen_netbk *netbk;
-		idx_t             fl;
+		struct xenvif *vif;
+		idx_t          fl;
 	} u;
 };
 
@@ -52,12 +55,12 @@ int  page_pool_init(void);
 void page_pool_destroy(void);
 
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+struct page *page_pool_get(struct xenvif *vif, int *pidx);
 void         page_pool_put(int idx);
 int          is_in_pool(struct page *page, int *pidx);
 
 struct page            *to_page(int idx);
-struct xen_netbk       *to_netbk(int idx);
+struct xenvif          *to_vif(int idx);
 struct pending_tx_info *to_txinfo(int idx);
 
 #endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Oe-0002z8-1x; Tue, 17 Jan 2012 13:48:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9Oc-0002vt-En
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18800 invoked from network); 17 Jan 2012 13:47:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:47:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838499"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48:11 -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 q0HDm0fX005778;
	Tue, 17 Jan 2012 05:48:10 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:01 +0000
Message-ID: <1326808024-3744-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 5/8] netback: add module get/put
	operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If there is vif running and user unloads netback, it will certainly
cause problems -- guest's network interface just mysteriously stops
working.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index dfc04f8..7c86187 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -405,4 +407,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	module_put(THIS_MODULE);
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Oe-0002z8-1x; Tue, 17 Jan 2012 13:48:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9Oc-0002vt-En
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:18 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18800 invoked from network); 17 Jan 2012 13:47:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:47:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838499"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48:11 -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 q0HDm0fX005778;
	Tue, 17 Jan 2012 05:48:10 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:01 +0000
Message-ID: <1326808024-3744-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 5/8] netback: add module get/put
	operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If there is vif running and user unloads netback, it will certainly
cause problems -- guest's network interface just mysteriously stops
working.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index dfc04f8..7c86187 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -405,4 +407,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	module_put(THIS_MODULE);
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Oi-00031n-UU; Tue, 17 Jan 2012 13:48:24 +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 1Rn9Oh-0002xM-4U
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808084!3920126!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18862 invoked from network); 17 Jan 2012 13:48:15 -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;
	17 Jan 2012 13:48:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="20960265"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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; Tue, 17 Jan 2012 08:48:14 -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 q0HDm0fZ005778;
	Tue, 17 Jan 2012 05:48:13 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:03 +0000
Message-ID: <1326808024-3744-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 7/8] netback: alter internal
	function/structure names.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since we've melted xen_netbk into xenvif, so it is better to give
functions clearer names.

Also alter napi poll handler function prototypes a bit.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   26 ++--
 drivers/net/xen-netback/interface.c |   20 ++--
 drivers/net/xen-netback/netback.c   |  229 ++++++++++++++++++-----------------
 3 files changed, 141 insertions(+), 134 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 17d4e1a..53141c7 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,7 @@
 
 #include "page_pool.h"
 
-struct netbk_rx_meta {
+struct xenvif_rx_meta {
 	int id;
 	int size;
 	int gso_size;
@@ -140,32 +140,32 @@ void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
-int xen_netbk_rx_ring_full(struct xenvif *vif);
+int xenvif_rx_ring_full(struct xenvif *vif);
 
-int xen_netbk_must_stop_queue(struct xenvif *vif);
+int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xenvif *vif);
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
-void xen_netbk_check_rx_xenvif(struct xenvif *vif);
+void xenvif_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
-void xen_netbk_rx_action(struct xenvif *vif);
+int xenvif_tx_action(struct xenvif *vif, int budget);
+void xenvif_rx_action(struct xenvif *vif);
 
-int xen_netbk_kthread(void *data);
+int xenvif_kthread(void *data);
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 11e638b..05caccc 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -48,7 +48,7 @@ int xenvif_schedulable(struct xenvif *vif)
 
 static int xenvif_rx_schedulable(struct xenvif *vif)
 {
-	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
+	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
@@ -69,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif, &work_done, budget);
+	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -101,12 +101,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
+	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
 
-	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
 		netif_stop_queue(dev);
 
-	xen_netbk_queue_tx_skb(vif, skb);
+	xenvif_queue_tx_skb(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -137,7 +137,7 @@ static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
@@ -334,7 +334,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
 
@@ -347,7 +347,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	disable_irq(vif->irq);
 
 	init_waitqueue_head(&vif->wq);
-	vif->task = kthread_create(xen_netbk_kthread,
+	vif->task = kthread_create(xenvif_kthread,
 				   (void *)vif,
 				   "vif%d.%d", vif->domid, vif->handle);
 	if (IS_ERR(vif->task)) {
@@ -371,7 +371,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 err:
 	return err;
 }
@@ -400,7 +400,7 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1842e4e..fa864f4 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -57,9 +57,9 @@ struct gnttab_copy *tx_copy_ops;
  * straddles two buffers in the frontend.
  */
 struct gnttab_copy *grant_copy_op;
-struct netbk_rx_meta *meta;
+struct xenvif_rx_meta *meta;
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -127,7 +127,7 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xen_netbk_rx_ring_full(struct xenvif *vif)
+int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
@@ -136,16 +136,16 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
 }
 
-int xen_netbk_must_stop_queue(struct xenvif *vif)
+int xenvif_must_stop_queue(struct xenvif *vif)
 {
-	if (!xen_netbk_rx_ring_full(vif))
+	if (!xenvif_rx_ring_full(vif))
 		return 0;
 
 	vif->rx.sring->req_event = vif->rx_req_cons_peek +
 		max_required_rx_slots(vif);
 	mb(); /* request notification /then/ check the queue */
 
-	return xen_netbk_rx_ring_full(vif);
+	return xenvif_rx_ring_full(vif);
 }
 
 /*
@@ -191,9 +191,9 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
 /*
  * Figure out how many ring slots we're going to need to send @skb to
  * the guest. This function is essentially a dry run of
- * netbk_gop_frag_copy.
+ * xenvif_gop_frag_copy.
  */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 {
 	unsigned int count;
 	int i, copy_off;
@@ -232,15 +232,15 @@ struct netrx_pending_operations {
 	unsigned copy_prod, copy_cons;
 	unsigned meta_prod, meta_cons;
 	struct gnttab_copy *copy;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	int copy_off;
 	grant_ref_t copy_gref;
 };
 
-static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-						struct netrx_pending_operations *npo)
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+					struct netrx_pending_operations *npo)
 {
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	struct xen_netif_rx_request *req;
 
 	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
@@ -260,13 +260,13 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				struct netrx_pending_operations *npo,
-				struct page *page, unsigned long size,
-				unsigned long offset, int *head)
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				 struct netrx_pending_operations *npo,
+				 struct page *page, unsigned long size,
+				 unsigned long offset, int *head)
 {
 	struct gnttab_copy *copy_gop;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	/*
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
@@ -344,14 +344,14 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
  * zero GSO descriptors (for non-GSO packets) or one descriptor (for
  * frontend-side LRO).
  */
-static int netbk_gop_skb(struct sk_buff *skb,
-			 struct netrx_pending_operations *npo)
+static int xenvif_gop_skb(struct sk_buff *skb,
+			  struct netrx_pending_operations *npo)
 {
 	struct xenvif *vif = netdev_priv(skb->dev);
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	int i;
 	struct xen_netif_rx_request *req;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	unsigned char *data;
 	int head = 1;
 	int old_meta_prod;
@@ -388,30 +388,30 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     virt_to_page(data), len, offset, &head);
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
-				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				     skb_shinfo(skb)->frags[i].page_offset,
+				     &head);
 	}
 
 	return npo->meta_prod - old_meta_prod;
 }
 
 /*
- * This is a twin to netbk_gop_skb.  Assume that netbk_gop_skb was
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
  * used to set up the operations on the top of
  * netrx_pending_operations, which have since been done.  Check that
  * they didn't give any errors and advance over them.
  */
-static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
-			   struct netrx_pending_operations *npo)
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			    struct netrx_pending_operations *npo)
 {
 	struct gnttab_copy     *copy_op;
 	int status = XEN_NETIF_RSP_OKAY;
@@ -430,9 +430,9 @@ static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
 	return status;
 }
 
-static void netbk_add_frag_responses(struct xenvif *vif, int status,
-				     struct netbk_rx_meta *meta,
-				     int nr_meta_slots)
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				      struct xenvif_rx_meta *meta,
+				      int nr_meta_slots)
 {
 	int i;
 	unsigned long offset;
@@ -460,12 +460,12 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xenvif *vif)
+static void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xenvif *vif)
+void xenvif_rx_action(struct xenvif *vif)
 {
 	s8 status;
 	u16 flags;
@@ -481,7 +481,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 	int need_to_notify = 0;
 
 	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
-	struct netbk_rx_meta *m = get_cpu_ptr(meta);
+	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
 
 	struct netrx_pending_operations npo = {
 		.copy  = gco,
@@ -497,7 +497,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
 		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = netbk_gop_skb(skb, &npo);
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
 
 		count += nr_frags + 1;
 
@@ -544,7 +544,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		vif->dev->stats.tx_bytes += skb->len;
 		vif->dev->stats.tx_packets++;
 
-		status = netbk_check_gop(vif, sco->meta_slots_used, &npo);
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
 
 		if (sco->meta_slots_used == 1)
 			flags = 0;
@@ -580,9 +580,9 @@ void xen_netbk_rx_action(struct xenvif *vif)
 			gso->flags = 0;
 		}
 
-		netbk_add_frag_responses(vif, status,
-					 m + npo.meta_cons + 1,
-					 sco->meta_slots_used);
+		xenvif_add_frag_responses(vif, status,
+					  m + npo.meta_cons + 1,
+					  sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
 		if (ret)
@@ -598,20 +598,20 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		notify_remote_via_irq(vif->irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
-		xen_netbk_kick_thread(vif);
+		xenvif_kick_thread(vif);
 
 	put_cpu_ptr(gco);
 	put_cpu_ptr(m);
 }
 
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(vif);
+	xenvif_kick_thread(vif);
 }
 
-void xen_netbk_check_rx_xenvif(struct xenvif *vif)
+void xenvif_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
@@ -648,11 +648,11 @@ static void tx_credit_callback(unsigned long data)
 {
 	struct xenvif *vif = (struct xenvif *)data;
 	tx_add_credit(vif);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static void netbk_tx_err(struct xenvif *vif,
-			 struct xen_netif_tx_request *txp, RING_IDX end)
+static void xenvif_tx_err(struct xenvif *vif,
+			  struct xen_netif_tx_request *txp, RING_IDX end)
 {
 	RING_IDX cons = vif->tx.req_cons;
 
@@ -663,10 +663,10 @@ static void netbk_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static int netbk_count_requests(struct xenvif *vif,
+static int xenvif_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
 				int work_to_do)
@@ -707,9 +707,9 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xenvif *vif,
-					 struct sk_buff *skb,
-					 u16 pending_idx)
+static struct page *xenvif_alloc_page(struct xenvif *vif,
+				      struct sk_buff *skb,
+				      u16 pending_idx)
 {
 	struct page *page;
 	int idx;
@@ -720,10 +720,10 @@ static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
-						  struct sk_buff *skb,
-						  struct xen_netif_tx_request *txp,
-						  struct gnttab_copy *gop)
+static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+					       struct sk_buff *skb,
+					       struct xen_netif_tx_request *txp,
+					       struct gnttab_copy *gop)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
@@ -741,7 +741,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 
 		index = pending_index(vif->pending_cons++);
 		pending_idx = vif->pending_ring[index];
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -769,9 +769,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xenvif *vif,
-				  struct sk_buff *skb,
-				  struct gnttab_copy **gopp)
+static int xenvif_tx_check_gop(struct xenvif *vif,
+			       struct sk_buff *skb,
+			       struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
@@ -808,7 +808,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(vif, pending_idx);
+				xenvif_idx_release(vif, pending_idx);
 			continue;
 		}
 
@@ -825,10 +825,10 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -839,7 +839,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
+static void xenvif_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -865,15 +865,15 @@ static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
-		/* Take an extra reference to offset xen_netbk_idx_release */
+		/* Take an extra reference to offset xenvif_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 	}
 }
 
-static int xen_netbk_get_extras(struct xenvif *vif,
-				struct xen_netif_extra_info *extras,
-				int work_to_do)
+static int xenvif_get_extras(struct xenvif *vif,
+			     struct xen_netif_extra_info *extras,
+			     int work_to_do)
 {
 	struct xen_netif_extra_info extra;
 	RING_IDX cons = vif->tx.req_cons;
@@ -901,9 +901,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 	return work_to_do;
 }
 
-static int netbk_set_skb_gso(struct xenvif *vif,
-			     struct sk_buff *skb,
-			     struct xen_netif_extra_info *gso)
+static int xenvif_set_skb_gso(struct xenvif *vif,
+			      struct sk_buff *skb,
+			      struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
 		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
@@ -1028,8 +1028,8 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
-					struct gnttab_copy *tco)
+static unsigned xenvif_tx_build_gops(struct xenvif *vif,
+				     struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
@@ -1070,18 +1070,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		memset(extras, 0, sizeof(extras));
 		if (txreq.flags & XEN_NETTXF_extra_info) {
-			work_to_do = xen_netbk_get_extras(vif, extras,
+			work_to_do = xenvif_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
-		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
+		ret = xenvif_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+			xenvif_tx_err(vif, &txreq, idx - ret);
 			break;
 		}
 		idx += ret;
@@ -1089,7 +1089,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(txreq.size < ETH_HLEN)) {
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1099,7 +1099,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1115,7 +1115,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(skb == NULL)) {
 			netdev_dbg(vif->dev,
 				   "Can't allocate a skb in start_xmit.\n");
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1126,18 +1126,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 			struct xen_netif_extra_info *gso;
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
-			if (netbk_set_skb_gso(vif, skb, gso)) {
+			if (xenvif_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1178,17 +1178,17 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(vif,
+		request_gop = xenvif_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xen_netbk_check_rx_xenvif(vif);
+		xenvif_check_rx_xenvif(vif);
 
 		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
@@ -1197,14 +1197,15 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 	return gop - tco;
 }
 
-static void xen_netbk_tx_submit(struct xenvif *vif,
-				struct gnttab_copy *tco,
-				int *work_done, int budget)
+static int xenvif_tx_submit(struct xenvif *vif,
+			    struct gnttab_copy *tco,
+			    int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
+	int work_done = 0;
 
-	while ((*work_done < budget) &&
+	while ((work_done < budget) &&
 	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
@@ -1220,7 +1221,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
+		if (unlikely(xenvif_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1237,7 +1238,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1245,7 +1246,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(vif, skb);
+		xenvif_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1270,25 +1271,28 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
-		(*work_done)++;
+		work_done++;
 
 		xenvif_receive_skb(vif, skb);
 	}
+
+	return work_done;
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
+int xenvif_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 	struct gnttab_copy *tco;
+	int work_done;
 
 	if (unlikely(!tx_work_todo(vif)))
-		return;
+		return 0;
 
 	tco = get_cpu_ptr(tx_copy_ops);
 
-	nr_gops = xen_netbk_tx_build_gops(vif, tco);
+	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_ptr(tco);
@@ -1298,11 +1302,14 @@ void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(vif, tco, work_done, budget);
+	work_done = xenvif_tx_submit(vif, tco, budget);
+
 	put_cpu_ptr(tco);
+
+	return work_done;
 }
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx)
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
@@ -1383,7 +1390,7 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
 		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
@@ -1393,9 +1400,9 @@ void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 					vif->rx.sring);
 }
 
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref)
 {
 	void *addr;
 	struct xen_netif_tx_sring *txs;
@@ -1424,11 +1431,11 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	return 0;
 
 err:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
-int xen_netbk_kthread(void *data)
+int xenvif_kthread(void *data)
 {
 	struct xenvif *vif = data;
 
@@ -1442,7 +1449,7 @@ int xen_netbk_kthread(void *data)
 			break;
 
 		if (rx_work_todo(vif))
-			xen_netbk_rx_action(vif);
+			xenvif_rx_action(vif);
 	}
 
 	return 0;
@@ -1468,9 +1475,9 @@ static int __init netback_init(void)
 	if (!grant_copy_op)
 		goto failed_init_gco;
 
-	meta = __alloc_percpu(sizeof(struct netbk_rx_meta)
+	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
 			      * 2 * XEN_NETIF_RX_RING_SIZE,
-			      __alignof__(struct netbk_rx_meta));
+			      __alignof__(struct xenvif_rx_meta));
 	if (!meta)
 		goto failed_init_meta;
 
-- 
1.7.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 Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Oi-00031n-UU; Tue, 17 Jan 2012 13:48:24 +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 1Rn9Oh-0002xM-4U
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:23 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808084!3920126!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18862 invoked from network); 17 Jan 2012 13:48:15 -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;
	17 Jan 2012 13:48:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="20960265"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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; Tue, 17 Jan 2012 08:48:14 -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 q0HDm0fZ005778;
	Tue, 17 Jan 2012 05:48:13 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:03 +0000
Message-ID: <1326808024-3744-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 7/8] netback: alter internal
	function/structure names.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since we've melted xen_netbk into xenvif, so it is better to give
functions clearer names.

Also alter napi poll handler function prototypes a bit.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   26 ++--
 drivers/net/xen-netback/interface.c |   20 ++--
 drivers/net/xen-netback/netback.c   |  229 ++++++++++++++++++-----------------
 3 files changed, 141 insertions(+), 134 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 17d4e1a..53141c7 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,7 @@
 
 #include "page_pool.h"
 
-struct netbk_rx_meta {
+struct xenvif_rx_meta {
 	int id;
 	int size;
 	int gso_size;
@@ -140,32 +140,32 @@ void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
-int xen_netbk_rx_ring_full(struct xenvif *vif);
+int xenvif_rx_ring_full(struct xenvif *vif);
 
-int xen_netbk_must_stop_queue(struct xenvif *vif);
+int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xenvif *vif);
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
-void xen_netbk_check_rx_xenvif(struct xenvif *vif);
+void xenvif_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
-void xen_netbk_rx_action(struct xenvif *vif);
+int xenvif_tx_action(struct xenvif *vif, int budget);
+void xenvif_rx_action(struct xenvif *vif);
 
-int xen_netbk_kthread(void *data);
+int xenvif_kthread(void *data);
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 11e638b..05caccc 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -48,7 +48,7 @@ int xenvif_schedulable(struct xenvif *vif)
 
 static int xenvif_rx_schedulable(struct xenvif *vif)
 {
-	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
+	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
@@ -69,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif, &work_done, budget);
+	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -101,12 +101,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
+	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
 
-	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
 		netif_stop_queue(dev);
 
-	xen_netbk_queue_tx_skb(vif, skb);
+	xenvif_queue_tx_skb(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -137,7 +137,7 @@ static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
@@ -334,7 +334,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
 
@@ -347,7 +347,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	disable_irq(vif->irq);
 
 	init_waitqueue_head(&vif->wq);
-	vif->task = kthread_create(xen_netbk_kthread,
+	vif->task = kthread_create(xenvif_kthread,
 				   (void *)vif,
 				   "vif%d.%d", vif->domid, vif->handle);
 	if (IS_ERR(vif->task)) {
@@ -371,7 +371,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 err:
 	return err;
 }
@@ -400,7 +400,7 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1842e4e..fa864f4 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -57,9 +57,9 @@ struct gnttab_copy *tx_copy_ops;
  * straddles two buffers in the frontend.
  */
 struct gnttab_copy *grant_copy_op;
-struct netbk_rx_meta *meta;
+struct xenvif_rx_meta *meta;
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -127,7 +127,7 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xen_netbk_rx_ring_full(struct xenvif *vif)
+int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
@@ -136,16 +136,16 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
 }
 
-int xen_netbk_must_stop_queue(struct xenvif *vif)
+int xenvif_must_stop_queue(struct xenvif *vif)
 {
-	if (!xen_netbk_rx_ring_full(vif))
+	if (!xenvif_rx_ring_full(vif))
 		return 0;
 
 	vif->rx.sring->req_event = vif->rx_req_cons_peek +
 		max_required_rx_slots(vif);
 	mb(); /* request notification /then/ check the queue */
 
-	return xen_netbk_rx_ring_full(vif);
+	return xenvif_rx_ring_full(vif);
 }
 
 /*
@@ -191,9 +191,9 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
 /*
  * Figure out how many ring slots we're going to need to send @skb to
  * the guest. This function is essentially a dry run of
- * netbk_gop_frag_copy.
+ * xenvif_gop_frag_copy.
  */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 {
 	unsigned int count;
 	int i, copy_off;
@@ -232,15 +232,15 @@ struct netrx_pending_operations {
 	unsigned copy_prod, copy_cons;
 	unsigned meta_prod, meta_cons;
 	struct gnttab_copy *copy;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	int copy_off;
 	grant_ref_t copy_gref;
 };
 
-static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-						struct netrx_pending_operations *npo)
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+					struct netrx_pending_operations *npo)
 {
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	struct xen_netif_rx_request *req;
 
 	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
@@ -260,13 +260,13 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				struct netrx_pending_operations *npo,
-				struct page *page, unsigned long size,
-				unsigned long offset, int *head)
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				 struct netrx_pending_operations *npo,
+				 struct page *page, unsigned long size,
+				 unsigned long offset, int *head)
 {
 	struct gnttab_copy *copy_gop;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	/*
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
@@ -344,14 +344,14 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
  * zero GSO descriptors (for non-GSO packets) or one descriptor (for
  * frontend-side LRO).
  */
-static int netbk_gop_skb(struct sk_buff *skb,
-			 struct netrx_pending_operations *npo)
+static int xenvif_gop_skb(struct sk_buff *skb,
+			  struct netrx_pending_operations *npo)
 {
 	struct xenvif *vif = netdev_priv(skb->dev);
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	int i;
 	struct xen_netif_rx_request *req;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	unsigned char *data;
 	int head = 1;
 	int old_meta_prod;
@@ -388,30 +388,30 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     virt_to_page(data), len, offset, &head);
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
-				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				     skb_shinfo(skb)->frags[i].page_offset,
+				     &head);
 	}
 
 	return npo->meta_prod - old_meta_prod;
 }
 
 /*
- * This is a twin to netbk_gop_skb.  Assume that netbk_gop_skb was
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
  * used to set up the operations on the top of
  * netrx_pending_operations, which have since been done.  Check that
  * they didn't give any errors and advance over them.
  */
-static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
-			   struct netrx_pending_operations *npo)
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			    struct netrx_pending_operations *npo)
 {
 	struct gnttab_copy     *copy_op;
 	int status = XEN_NETIF_RSP_OKAY;
@@ -430,9 +430,9 @@ static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
 	return status;
 }
 
-static void netbk_add_frag_responses(struct xenvif *vif, int status,
-				     struct netbk_rx_meta *meta,
-				     int nr_meta_slots)
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				      struct xenvif_rx_meta *meta,
+				      int nr_meta_slots)
 {
 	int i;
 	unsigned long offset;
@@ -460,12 +460,12 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xenvif *vif)
+static void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xenvif *vif)
+void xenvif_rx_action(struct xenvif *vif)
 {
 	s8 status;
 	u16 flags;
@@ -481,7 +481,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 	int need_to_notify = 0;
 
 	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
-	struct netbk_rx_meta *m = get_cpu_ptr(meta);
+	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
 
 	struct netrx_pending_operations npo = {
 		.copy  = gco,
@@ -497,7 +497,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
 		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = netbk_gop_skb(skb, &npo);
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
 
 		count += nr_frags + 1;
 
@@ -544,7 +544,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		vif->dev->stats.tx_bytes += skb->len;
 		vif->dev->stats.tx_packets++;
 
-		status = netbk_check_gop(vif, sco->meta_slots_used, &npo);
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
 
 		if (sco->meta_slots_used == 1)
 			flags = 0;
@@ -580,9 +580,9 @@ void xen_netbk_rx_action(struct xenvif *vif)
 			gso->flags = 0;
 		}
 
-		netbk_add_frag_responses(vif, status,
-					 m + npo.meta_cons + 1,
-					 sco->meta_slots_used);
+		xenvif_add_frag_responses(vif, status,
+					  m + npo.meta_cons + 1,
+					  sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
 		if (ret)
@@ -598,20 +598,20 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		notify_remote_via_irq(vif->irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
-		xen_netbk_kick_thread(vif);
+		xenvif_kick_thread(vif);
 
 	put_cpu_ptr(gco);
 	put_cpu_ptr(m);
 }
 
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(vif);
+	xenvif_kick_thread(vif);
 }
 
-void xen_netbk_check_rx_xenvif(struct xenvif *vif)
+void xenvif_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
@@ -648,11 +648,11 @@ static void tx_credit_callback(unsigned long data)
 {
 	struct xenvif *vif = (struct xenvif *)data;
 	tx_add_credit(vif);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static void netbk_tx_err(struct xenvif *vif,
-			 struct xen_netif_tx_request *txp, RING_IDX end)
+static void xenvif_tx_err(struct xenvif *vif,
+			  struct xen_netif_tx_request *txp, RING_IDX end)
 {
 	RING_IDX cons = vif->tx.req_cons;
 
@@ -663,10 +663,10 @@ static void netbk_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static int netbk_count_requests(struct xenvif *vif,
+static int xenvif_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
 				int work_to_do)
@@ -707,9 +707,9 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xenvif *vif,
-					 struct sk_buff *skb,
-					 u16 pending_idx)
+static struct page *xenvif_alloc_page(struct xenvif *vif,
+				      struct sk_buff *skb,
+				      u16 pending_idx)
 {
 	struct page *page;
 	int idx;
@@ -720,10 +720,10 @@ static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
-						  struct sk_buff *skb,
-						  struct xen_netif_tx_request *txp,
-						  struct gnttab_copy *gop)
+static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+					       struct sk_buff *skb,
+					       struct xen_netif_tx_request *txp,
+					       struct gnttab_copy *gop)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
@@ -741,7 +741,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 
 		index = pending_index(vif->pending_cons++);
 		pending_idx = vif->pending_ring[index];
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -769,9 +769,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xenvif *vif,
-				  struct sk_buff *skb,
-				  struct gnttab_copy **gopp)
+static int xenvif_tx_check_gop(struct xenvif *vif,
+			       struct sk_buff *skb,
+			       struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
@@ -808,7 +808,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(vif, pending_idx);
+				xenvif_idx_release(vif, pending_idx);
 			continue;
 		}
 
@@ -825,10 +825,10 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -839,7 +839,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
+static void xenvif_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -865,15 +865,15 @@ static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
-		/* Take an extra reference to offset xen_netbk_idx_release */
+		/* Take an extra reference to offset xenvif_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 	}
 }
 
-static int xen_netbk_get_extras(struct xenvif *vif,
-				struct xen_netif_extra_info *extras,
-				int work_to_do)
+static int xenvif_get_extras(struct xenvif *vif,
+			     struct xen_netif_extra_info *extras,
+			     int work_to_do)
 {
 	struct xen_netif_extra_info extra;
 	RING_IDX cons = vif->tx.req_cons;
@@ -901,9 +901,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 	return work_to_do;
 }
 
-static int netbk_set_skb_gso(struct xenvif *vif,
-			     struct sk_buff *skb,
-			     struct xen_netif_extra_info *gso)
+static int xenvif_set_skb_gso(struct xenvif *vif,
+			      struct sk_buff *skb,
+			      struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
 		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
@@ -1028,8 +1028,8 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
-					struct gnttab_copy *tco)
+static unsigned xenvif_tx_build_gops(struct xenvif *vif,
+				     struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
@@ -1070,18 +1070,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		memset(extras, 0, sizeof(extras));
 		if (txreq.flags & XEN_NETTXF_extra_info) {
-			work_to_do = xen_netbk_get_extras(vif, extras,
+			work_to_do = xenvif_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
-		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
+		ret = xenvif_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+			xenvif_tx_err(vif, &txreq, idx - ret);
 			break;
 		}
 		idx += ret;
@@ -1089,7 +1089,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(txreq.size < ETH_HLEN)) {
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1099,7 +1099,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1115,7 +1115,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(skb == NULL)) {
 			netdev_dbg(vif->dev,
 				   "Can't allocate a skb in start_xmit.\n");
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1126,18 +1126,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 			struct xen_netif_extra_info *gso;
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
-			if (netbk_set_skb_gso(vif, skb, gso)) {
+			if (xenvif_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1178,17 +1178,17 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(vif,
+		request_gop = xenvif_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xen_netbk_check_rx_xenvif(vif);
+		xenvif_check_rx_xenvif(vif);
 
 		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
@@ -1197,14 +1197,15 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 	return gop - tco;
 }
 
-static void xen_netbk_tx_submit(struct xenvif *vif,
-				struct gnttab_copy *tco,
-				int *work_done, int budget)
+static int xenvif_tx_submit(struct xenvif *vif,
+			    struct gnttab_copy *tco,
+			    int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
+	int work_done = 0;
 
-	while ((*work_done < budget) &&
+	while ((work_done < budget) &&
 	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
@@ -1220,7 +1221,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
+		if (unlikely(xenvif_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1237,7 +1238,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1245,7 +1246,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(vif, skb);
+		xenvif_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1270,25 +1271,28 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
-		(*work_done)++;
+		work_done++;
 
 		xenvif_receive_skb(vif, skb);
 	}
+
+	return work_done;
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
+int xenvif_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 	struct gnttab_copy *tco;
+	int work_done;
 
 	if (unlikely(!tx_work_todo(vif)))
-		return;
+		return 0;
 
 	tco = get_cpu_ptr(tx_copy_ops);
 
-	nr_gops = xen_netbk_tx_build_gops(vif, tco);
+	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_ptr(tco);
@@ -1298,11 +1302,14 @@ void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(vif, tco, work_done, budget);
+	work_done = xenvif_tx_submit(vif, tco, budget);
+
 	put_cpu_ptr(tco);
+
+	return work_done;
 }
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx)
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
@@ -1383,7 +1390,7 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
 		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
@@ -1393,9 +1400,9 @@ void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 					vif->rx.sring);
 }
 
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref)
 {
 	void *addr;
 	struct xen_netif_tx_sring *txs;
@@ -1424,11 +1431,11 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	return 0;
 
 err:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
-int xen_netbk_kthread(void *data)
+int xenvif_kthread(void *data)
 {
 	struct xenvif *vif = data;
 
@@ -1442,7 +1449,7 @@ int xen_netbk_kthread(void *data)
 			break;
 
 		if (rx_work_todo(vif))
-			xen_netbk_rx_action(vif);
+			xenvif_rx_action(vif);
 	}
 
 	return 0;
@@ -1468,9 +1475,9 @@ static int __init netback_init(void)
 	if (!grant_copy_op)
 		goto failed_init_gco;
 
-	meta = __alloc_percpu(sizeof(struct netbk_rx_meta)
+	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
 			      * 2 * XEN_NETIF_RX_RING_SIZE,
-			      __alignof__(struct netbk_rx_meta));
+			      __alignof__(struct xenvif_rx_meta));
 	if (!meta)
 		goto failed_init_meta;
 
-- 
1.7.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 Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9OX-0002vu-BK; Tue, 17 Jan 2012 13:48:13 +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 1Rn9OW-0002vE-0p
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808084!3920126!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18273 invoked from network); 17 Jan 2012 13:48:05 -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;
	17 Jan 2012 13:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="20960261"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48: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 q0HDm0fS005778;
	Tue, 17 Jan 2012 05:48:01 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:46:56 +0000
Message-ID: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A new netback implementation which includes three major features:

 - Global page pool support
 - NAPI + kthread 1:1 model
 - Netback internal name changes

Changes in V2:
 - Fix minor bugs in V1
 - Embed pending_tx_info into page pool
 - Per-cpu scratch space
 - Notification code path clean up

This patch series is the foundation of furture work. So it is better
to get it right first. Patch 1 and 3 have the real meat.

The first benifit of 1:1 model will be scheduling fairness.

The rational behind a global page pool is that we need to limit
overall memory consumed by all vifs.

Utilization of NAPI enables the possibility to mitigate
interrupts/events, the code path is cleaned up in a separated patch.

Netback internal changes cleans up the code structure after switching
to 1:1 model. It also prepares netback for further code layout
changes.

---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |   78 ++--
 drivers/net/xen-netback/interface.c |  117 ++++--
 drivers/net/xen-netback/netback.c   |  836 ++++++++++++++---------------------
 drivers/net/xen-netback/page_pool.c |  185 ++++++++
 drivers/net/xen-netback/page_pool.h |   66 +++
 drivers/net/xen-netback/xenbus.c    |    6 +-
 7 files changed, 704 insertions(+), 586 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:48:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9OX-0002vu-BK; Tue, 17 Jan 2012 13:48:13 +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 1Rn9OW-0002vE-0p
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:12 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808084!3920126!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18273 invoked from network); 17 Jan 2012 13:48:05 -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;
	17 Jan 2012 13:48:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="20960261"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48: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 q0HDm0fS005778;
	Tue, 17 Jan 2012 05:48:01 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:46:56 +0000
Message-ID: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A new netback implementation which includes three major features:

 - Global page pool support
 - NAPI + kthread 1:1 model
 - Netback internal name changes

Changes in V2:
 - Fix minor bugs in V1
 - Embed pending_tx_info into page pool
 - Per-cpu scratch space
 - Notification code path clean up

This patch series is the foundation of furture work. So it is better
to get it right first. Patch 1 and 3 have the real meat.

The first benifit of 1:1 model will be scheduling fairness.

The rational behind a global page pool is that we need to limit
overall memory consumed by all vifs.

Utilization of NAPI enables the possibility to mitigate
interrupts/events, the code path is cleaned up in a separated patch.

Netback internal changes cleans up the code structure after switching
to 1:1 model. It also prepares netback for further code layout
changes.

---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |   78 ++--
 drivers/net/xen-netback/interface.c |  117 ++++--
 drivers/net/xen-netback/netback.c   |  836 ++++++++++++++---------------------
 drivers/net/xen-netback/page_pool.c |  185 ++++++++
 drivers/net/xen-netback/page_pool.h |   66 +++
 drivers/net/xen-netback/xenbus.c    |    6 +-
 7 files changed, 704 insertions(+), 586 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13: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 1Rn9Oc-0002yC-DW; Tue, 17 Jan 2012 13:48:18 +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 1Rn9Ob-0002vl-BW
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808084!3920126!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18655 invoked from network); 17 Jan 2012 13:48:10 -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;
	17 Jan 2012 13:48:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="20960263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48:10 -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 q0HDm0fW005778;
	Tue, 17 Jan 2012 05:48:08 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:00 +0000
Message-ID: <1326808024-3744-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 4/8] netback: switch to per-cpu scratch
	space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, given that there are maximum nr_online_cpus netbacks
running, we can use per-cpu scratch space, thus shrinking size of
struct xen_netbk.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |   13 ++++
 drivers/net/xen-netback/netback.c |  134 ++++++++++++++++++++++++-------------
 2 files changed, 100 insertions(+), 47 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 31c331c..3b85563 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,19 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct netbk_rx_meta {
+	int id;
+	int size;
+	int gso_size;
+};
+
+#define MAX_PENDING_REQS 256
+
+/* Discriminate from any valid pending_idx value. */
+#define INVALID_PENDING_IDX 0xFFFF
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
 };
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 7378d63..714f508 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1,3 +1,4 @@
+
 /*
  * Back-end of the driver for virtual network devices. This portion of the
  * driver exports a 'unified' network-device interface that can be accessed
@@ -47,18 +48,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct netbk_rx_meta {
-	int id;
-	int size;
-	int gso_size;
-};
 
-#define MAX_PENDING_REQS 256
+struct gnttab_copy *tx_copy_ops;
 
-/* Discriminate from any valid pending_idx value. */
-#define INVALID_PENDING_IDX 0xFFFF
+/*
+ * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
+ * head/fragment page uses 2 copy operations because it
+ * straddles two buffers in the frontend.
+ */
+struct gnttab_copy *grant_copy_op;
+struct netbk_rx_meta *meta;
 
-#define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
 	struct sk_buff_head rx_queue;
@@ -71,17 +71,7 @@ struct xen_netbk {
 
 	struct xenvif *vif;
 
-	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
-
 	u16 pending_ring[MAX_PENDING_REQS];
-
-	/*
-	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
-	 * head/fragment page uses 2 copy operations because it
-	 * straddles two buffers in the frontend.
-	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
@@ -508,9 +498,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
 
+	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
+	struct netbk_rx_meta *m = get_cpu_ptr(meta);
+
 	struct netrx_pending_operations npo = {
-		.copy  = netbk->grant_copy_op,
-		.meta  = netbk->meta,
+		.copy  = gco,
+		.meta  = m,
 	};
 
 	skb_queue_head_init(&rxq);
@@ -533,13 +526,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			break;
 	}
 
-	BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
+	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
 
-	if (!npo.copy_prod)
+	if (!npo.copy_prod) {
+		put_cpu_ptr(gco);
+		put_cpu_ptr(m);
 		return;
+	}
 
-	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
+	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
 
@@ -548,14 +544,14 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 		vif = netdev_priv(skb->dev);
 
-		if (netbk->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
 
 			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
 
-			resp->offset = netbk->meta[npo.meta_cons].gso_size;
-			resp->id = netbk->meta[npo.meta_cons].id;
+			resp->offset = m[npo.meta_cons].gso_size;
+			resp->id = m[npo.meta_cons].id;
 			resp->status = sco->meta_slots_used;
 
 			npo.meta_cons++;
@@ -580,12 +576,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			flags |= XEN_NETRXF_data_validated;
 
 		offset = 0;
-		resp = make_rx_response(vif, netbk->meta[npo.meta_cons].id,
+		resp = make_rx_response(vif, m[npo.meta_cons].id,
 					status, offset,
-					netbk->meta[npo.meta_cons].size,
+					m[npo.meta_cons].size,
 					flags);
 
-		if (netbk->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
 			struct xen_netif_extra_info *gso =
 				(struct xen_netif_extra_info *)
 				RING_GET_RESPONSE(&vif->rx,
@@ -593,7 +589,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 			resp->flags |= XEN_NETRXF_extra_info;
 
-			gso->u.gso.size = netbk->meta[npo.meta_cons].gso_size;
+			gso->u.gso.size = m[npo.meta_cons].gso_size;
 			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
 			gso->u.gso.pad = 0;
 			gso->u.gso.features = 0;
@@ -603,7 +599,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 		}
 
 		netbk_add_frag_responses(vif, status,
-					 netbk->meta + npo.meta_cons + 1,
+					 m + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
@@ -621,6 +617,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
+
+	put_cpu_ptr(gco);
+	put_cpu_ptr(m);
 }
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
@@ -1052,9 +1051,10 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
+static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+					struct gnttab_copy *tco)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
+	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
 	struct xenvif *vif = netbk->vif;
@@ -1214,17 +1214,18 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
+		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
 	}
 
-	return gop - netbk->tx_copy_ops;
+	return gop - tco;
 }
 
 static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				struct gnttab_copy *tco,
 				int *work_done, int budget)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops;
+	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
 	struct xenvif *vif = netbk->vif;
 
@@ -1305,19 +1306,25 @@ void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
+	struct gnttab_copy *tco;
 
 	if (unlikely(!tx_work_todo(netbk)))
 		return;
 
-	nr_gops = xen_netbk_tx_build_gops(netbk);
+	tco = get_cpu_ptr(tx_copy_ops);
 
-	if (nr_gops == 0)
-		return;
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
-					netbk->tx_copy_ops, nr_gops);
+	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+
+	if (nr_gops == 0) {
+		put_cpu_ptr(tco);
+		return 0;
+	}
+
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, work_done, budget);
+	xen_netbk_tx_submit(netbk, tco, work_done, budget);
+	put_cpu_ptr(tco);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
@@ -1503,17 +1510,47 @@ int xen_netbk_kthread(void *data)
 
 static int __init netback_init(void)
 {
-	int rc = 0;
+	int rc = -ENOMEM;
 
 	if (!xen_domain())
 		return -ENODEV;
 
+	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
+				     * MAX_PENDING_REQS,
+				     __alignof__(struct gnttab_copy));
+	if (!tx_copy_ops)
+		goto failed_init;
+
+	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
+				       * 2 * XEN_NETIF_RX_RING_SIZE,
+				       __alignof__(struct gnttab_copy));
+	if (!grant_copy_op)
+		goto failed_init_gco;
+
+	meta = __alloc_percpu(sizeof(struct netbk_rx_meta)
+			      * 2 * XEN_NETIF_RX_RING_SIZE,
+			      __alignof__(struct netbk_rx_meta));
+	if (!meta)
+		goto failed_init_meta;
+
 	rc = page_pool_init();
 	if (rc)
-		goto failed_init;
+		goto failed_init_pool;
+
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto failed_init_xenbus;
 
-	return xenvif_xenbus_init();
+	return rc;
 
+failed_init_xenbus:
+	page_pool_destroy();
+failed_init_pool:
+	free_percpu(meta);
+failed_init_meta:
+	free_percpu(grant_copy_op);
+failed_init_gco:
+	free_percpu(tx_copy_ops);
 failed_init:
 	return rc;
 
@@ -1525,6 +1562,9 @@ static void __exit netback_exit(void)
 {
 	xenvif_xenbus_exit();
 	page_pool_destroy();
+	free_percpu(meta);
+	free_percpu(grant_copy_op);
+	free_percpu(tx_copy_ops);
 }
 module_exit(netback_exit);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13: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 1Rn9OY-0002wM-US; Tue, 17 Jan 2012 13:48:14 +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 1Rn9OY-0002vH-5W
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808084!3920126!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18528 invoked from network); 17 Jan 2012 13:48:07 -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;
	17 Jan 2012 13:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="20960262"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48:06 -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 q0HDm0fU005778;
	Tue, 17 Jan 2012 05:48:05 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:46:58 +0000
Message-ID: <1326808024-3744-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 2/8] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Enables users to unload netback module.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   14 ++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 288b2f3..372c7f5 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -126,6 +126,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index d11205f..3059684 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1670,5 +1670,19 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int i;
+	xenvif_xenbus_exit();
+	for (i = 0; i < xen_netbk_group_nr; i++) {
+		struct xen_netbk *netbk = &xen_netbk[i];
+		del_timer_sync(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+	page_pool_destroy();
+}
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13: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 1Rn9OY-0002wM-US; Tue, 17 Jan 2012 13:48:14 +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 1Rn9OY-0002vH-5W
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:14 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808084!3920126!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18528 invoked from network); 17 Jan 2012 13:48:07 -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;
	17 Jan 2012 13:48:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="20960262"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48:06 -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 q0HDm0fU005778;
	Tue, 17 Jan 2012 05:48:05 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:46:58 +0000
Message-ID: <1326808024-3744-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 2/8] netback: add module unload function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Enables users to unload netback module.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   14 ++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 288b2f3..372c7f5 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -126,6 +126,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index d11205f..3059684 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1670,5 +1670,19 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int i;
+	xenvif_xenbus_exit();
+	for (i = 0; i < xen_netbk_group_nr; i++) {
+		struct xen_netbk *netbk = &xen_netbk[i];
+		del_timer_sync(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+	page_pool_destroy();
+}
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13: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 1Rn9Oc-0002yC-DW; Tue, 17 Jan 2012 13:48:18 +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 1Rn9Ob-0002vl-BW
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:17 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808084!3920126!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgwOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18655 invoked from network); 17 Jan 2012 13:48:10 -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;
	17 Jan 2012 13:48:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="20960263"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48: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, 17 Jan 2012 08:48:10 -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 q0HDm0fW005778;
	Tue, 17 Jan 2012 05:48:08 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:47:00 +0000
Message-ID: <1326808024-3744-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 4/8] netback: switch to per-cpu scratch
	space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, given that there are maximum nr_online_cpus netbacks
running, we can use per-cpu scratch space, thus shrinking size of
struct xen_netbk.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |   13 ++++
 drivers/net/xen-netback/netback.c |  134 ++++++++++++++++++++++++-------------
 2 files changed, 100 insertions(+), 47 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 31c331c..3b85563 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,19 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct netbk_rx_meta {
+	int id;
+	int size;
+	int gso_size;
+};
+
+#define MAX_PENDING_REQS 256
+
+/* Discriminate from any valid pending_idx value. */
+#define INVALID_PENDING_IDX 0xFFFF
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
 };
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 7378d63..714f508 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1,3 +1,4 @@
+
 /*
  * Back-end of the driver for virtual network devices. This portion of the
  * driver exports a 'unified' network-device interface that can be accessed
@@ -47,18 +48,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct netbk_rx_meta {
-	int id;
-	int size;
-	int gso_size;
-};
 
-#define MAX_PENDING_REQS 256
+struct gnttab_copy *tx_copy_ops;
 
-/* Discriminate from any valid pending_idx value. */
-#define INVALID_PENDING_IDX 0xFFFF
+/*
+ * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
+ * head/fragment page uses 2 copy operations because it
+ * straddles two buffers in the frontend.
+ */
+struct gnttab_copy *grant_copy_op;
+struct netbk_rx_meta *meta;
 
-#define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
 	struct sk_buff_head rx_queue;
@@ -71,17 +71,7 @@ struct xen_netbk {
 
 	struct xenvif *vif;
 
-	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
-
 	u16 pending_ring[MAX_PENDING_REQS];
-
-	/*
-	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
-	 * head/fragment page uses 2 copy operations because it
-	 * straddles two buffers in the frontend.
-	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
@@ -508,9 +498,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
 
+	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
+	struct netbk_rx_meta *m = get_cpu_ptr(meta);
+
 	struct netrx_pending_operations npo = {
-		.copy  = netbk->grant_copy_op,
-		.meta  = netbk->meta,
+		.copy  = gco,
+		.meta  = m,
 	};
 
 	skb_queue_head_init(&rxq);
@@ -533,13 +526,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			break;
 	}
 
-	BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
+	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
 
-	if (!npo.copy_prod)
+	if (!npo.copy_prod) {
+		put_cpu_ptr(gco);
+		put_cpu_ptr(m);
 		return;
+	}
 
-	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
+	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
 
@@ -548,14 +544,14 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 		vif = netdev_priv(skb->dev);
 
-		if (netbk->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
 
 			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
 
-			resp->offset = netbk->meta[npo.meta_cons].gso_size;
-			resp->id = netbk->meta[npo.meta_cons].id;
+			resp->offset = m[npo.meta_cons].gso_size;
+			resp->id = m[npo.meta_cons].id;
 			resp->status = sco->meta_slots_used;
 
 			npo.meta_cons++;
@@ -580,12 +576,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			flags |= XEN_NETRXF_data_validated;
 
 		offset = 0;
-		resp = make_rx_response(vif, netbk->meta[npo.meta_cons].id,
+		resp = make_rx_response(vif, m[npo.meta_cons].id,
 					status, offset,
-					netbk->meta[npo.meta_cons].size,
+					m[npo.meta_cons].size,
 					flags);
 
-		if (netbk->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
 			struct xen_netif_extra_info *gso =
 				(struct xen_netif_extra_info *)
 				RING_GET_RESPONSE(&vif->rx,
@@ -593,7 +589,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 			resp->flags |= XEN_NETRXF_extra_info;
 
-			gso->u.gso.size = netbk->meta[npo.meta_cons].gso_size;
+			gso->u.gso.size = m[npo.meta_cons].gso_size;
 			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
 			gso->u.gso.pad = 0;
 			gso->u.gso.features = 0;
@@ -603,7 +599,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 		}
 
 		netbk_add_frag_responses(vif, status,
-					 netbk->meta + npo.meta_cons + 1,
+					 m + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
@@ -621,6 +617,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
+
+	put_cpu_ptr(gco);
+	put_cpu_ptr(m);
 }
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
@@ -1052,9 +1051,10 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
+static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+					struct gnttab_copy *tco)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
+	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
 	struct xenvif *vif = netbk->vif;
@@ -1214,17 +1214,18 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
+		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
 	}
 
-	return gop - netbk->tx_copy_ops;
+	return gop - tco;
 }
 
 static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				struct gnttab_copy *tco,
 				int *work_done, int budget)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops;
+	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
 	struct xenvif *vif = netbk->vif;
 
@@ -1305,19 +1306,25 @@ void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
+	struct gnttab_copy *tco;
 
 	if (unlikely(!tx_work_todo(netbk)))
 		return;
 
-	nr_gops = xen_netbk_tx_build_gops(netbk);
+	tco = get_cpu_ptr(tx_copy_ops);
 
-	if (nr_gops == 0)
-		return;
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
-					netbk->tx_copy_ops, nr_gops);
+	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+
+	if (nr_gops == 0) {
+		put_cpu_ptr(tco);
+		return 0;
+	}
+
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, work_done, budget);
+	xen_netbk_tx_submit(netbk, tco, work_done, budget);
+	put_cpu_ptr(tco);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
@@ -1503,17 +1510,47 @@ int xen_netbk_kthread(void *data)
 
 static int __init netback_init(void)
 {
-	int rc = 0;
+	int rc = -ENOMEM;
 
 	if (!xen_domain())
 		return -ENODEV;
 
+	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
+				     * MAX_PENDING_REQS,
+				     __alignof__(struct gnttab_copy));
+	if (!tx_copy_ops)
+		goto failed_init;
+
+	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
+				       * 2 * XEN_NETIF_RX_RING_SIZE,
+				       __alignof__(struct gnttab_copy));
+	if (!grant_copy_op)
+		goto failed_init_gco;
+
+	meta = __alloc_percpu(sizeof(struct netbk_rx_meta)
+			      * 2 * XEN_NETIF_RX_RING_SIZE,
+			      __alignof__(struct netbk_rx_meta));
+	if (!meta)
+		goto failed_init_meta;
+
 	rc = page_pool_init();
 	if (rc)
-		goto failed_init;
+		goto failed_init_pool;
+
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto failed_init_xenbus;
 
-	return xenvif_xenbus_init();
+	return rc;
 
+failed_init_xenbus:
+	page_pool_destroy();
+failed_init_pool:
+	free_percpu(meta);
+failed_init_meta:
+	free_percpu(grant_copy_op);
+failed_init_gco:
+	free_percpu(tx_copy_ops);
 failed_init:
 	return rc;
 
@@ -1525,6 +1562,9 @@ static void __exit netback_exit(void)
 {
 	xenvif_xenbus_exit();
 	page_pool_destroy();
+	free_percpu(meta);
+	free_percpu(grant_copy_op);
+	free_percpu(tx_copy_ops);
 }
 module_exit(netback_exit);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13: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 1Rn9Ob-0002x3-Bk; Tue, 17 Jan 2012 13:48:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9Oa-0002vY-4Y
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18477 invoked from network); 17 Jan 2012 13:47:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:47:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838496"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 08:48:08 -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 q0HDm0fV005778;
	Tue, 17 Jan 2012 05:48:06 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:46:59 +0000
Message-ID: <1326808024-3744-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 3/8] netback: switch to NAPI + kthread
	model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements 1:1 model netback. We utilizes NAPI and kthread
to do the weight-lifting job:

  - NAPI is used for guest side TX (host side RX)
  - kthread is used for guest side RX (host side TX)

This model provides better scheduling fairness among vifs. It also
lays the foundation for future work.

The major defect for the current implementation is that in the NAPI
poll handler we don't actually disable interrupt. Xen stuff is
different from real hardware, it requires some other tuning of ring
macros.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   34 ++--
 drivers/net/xen-netback/interface.c |   92 ++++++---
 drivers/net/xen-netback/netback.c   |  366 ++++++++++-------------------------
 drivers/net/xen-netback/xenbus.c    |    1 -
 4 files changed, 185 insertions(+), 308 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 372c7f5..31c331c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,6 @@
 
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
-	struct xenvif *vif;
 };
 typedef unsigned int pending_ring_idx_t;
 
@@ -61,14 +60,17 @@ struct xenvif {
 	/* Reference to netback processing backend. */
 	struct xen_netbk *netbk;
 
+	/* Use NAPI for guest TX */
+	struct napi_struct napi;
+	/* Use kthread for guest RX */
+	struct task_struct *task;
+	wait_queue_head_t wq;
+
 	u8               fe_dev_addr[6];
 
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* List of frontends to notify after a batch of frames sent. */
-	struct list_head notify_list;
-
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
@@ -99,11 +101,7 @@ struct xenvif {
 	unsigned long rx_gso_checksum_fixup;
 
 	/* Miscellaneous private stuff. */
-	struct list_head schedule_list;
-	atomic_t         refcnt;
 	struct net_device *dev;
-
-	wait_queue_head_t waiting_to_free;
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +120,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
-void xenvif_get(struct xenvif *vif);
-void xenvif_put(struct xenvif *vif);
-
 int xenvif_xenbus_init(void);
 void xenvif_xenbus_exit(void);
 
@@ -140,14 +135,6 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 				 grant_ref_t tx_ring_ref,
 				 grant_ref_t rx_ring_ref);
 
-/* (De)Register a xenvif with the netback backend. */
-void xen_netbk_add_xenvif(struct xenvif *vif);
-void xen_netbk_remove_xenvif(struct xenvif *vif);
-
-/* (De)Schedule backend processing for a xenvif */
-void xen_netbk_schedule_xenvif(struct xenvif *vif);
-void xen_netbk_deschedule_xenvif(struct xenvif *vif);
-
 /* Check for SKBs from frontend and schedule backend processing */
 void xen_netbk_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
@@ -161,4 +148,13 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+/* Allocate and free xen_netbk structure */
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
+void xen_netbk_free_netbk(struct xen_netbk *netbk);
+
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
+void xen_netbk_rx_action(struct xen_netbk *netbk);
+
+int xen_netbk_kthread(void *data);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1825629..dfc04f8 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -30,6 +30,7 @@
 
 #include "common.h"
 
+#include <linux/kthread.h>
 #include <linux/ethtool.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
@@ -38,17 +39,7 @@
 #include <asm/xen/hypercall.h>
 
 #define XENVIF_QUEUE_LENGTH 32
-
-void xenvif_get(struct xenvif *vif)
-{
-	atomic_inc(&vif->refcnt);
-}
-
-void xenvif_put(struct xenvif *vif)
-{
-	if (atomic_dec_and_test(&vif->refcnt))
-		wake_up(&vif->waiting_to_free);
-}
+#define XENVIF_NAPI_WEIGHT  64
 
 int xenvif_schedulable(struct xenvif *vif)
 {
@@ -67,14 +58,37 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (vif->netbk == NULL)
 		return IRQ_NONE;
 
-	xen_netbk_schedule_xenvif(vif);
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
+	if (likely(napi_schedule_prep(&vif->napi)))
+		__napi_schedule(&vif->napi);
+
 	return IRQ_HANDLED;
 }
 
+static int xenvif_poll(struct napi_struct *napi, int budget)
+{
+	struct xenvif *vif = container_of(napi, struct xenvif, napi);
+	int work_done = 0;
+
+	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+
+	if (work_done < budget) {
+		int more_to_do = 0;
+		unsigned long flag;
+		local_irq_save(flag);
+
+		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
+		if (!more_to_do)
+			__napi_complete(napi);
+
+		local_irq_restore(flag);
+	}
+
+	return work_done;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -90,7 +104,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Reserve ring slots for the worst-case number of fragments. */
 	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
-	xenvif_get(vif);
 
 	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
 		netif_stop_queue(dev);
@@ -107,7 +120,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	netif_rx_ni(skb);
+	netif_receive_skb(skb);
 }
 
 void xenvif_notify_tx_completion(struct xenvif *vif)
@@ -124,16 +137,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 
 static void xenvif_up(struct xenvif *vif)
 {
-	xen_netbk_add_xenvif(vif);
+	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
+	napi_disable(&vif->napi);
 	disable_irq(vif->irq);
-	xen_netbk_deschedule_xenvif(vif);
-	xen_netbk_remove_xenvif(vif);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -259,14 +271,11 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk  = NULL;
+	vif->netbk = NULL;
+
 	vif->can_sg = 1;
 	vif->csum = 1;
-	atomic_set(&vif->refcnt, 1);
-	init_waitqueue_head(&vif->waiting_to_free);
 	vif->dev = dev;
-	INIT_LIST_HEAD(&vif->schedule_list);
-	INIT_LIST_HEAD(&vif->notify_list);
 
 	vif->credit_bytes = vif->remaining_credit = ~0UL;
 	vif->credit_usec  = 0UL;
@@ -290,6 +299,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	memset(dev->dev_addr, 0xFF, ETH_ALEN);
 	dev->dev_addr[0] &= ~0x01;
 
+	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
+
 	netif_carrier_off(dev);
 
 	err = register_netdev(dev);
@@ -324,7 +335,23 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
+	vif->netbk = xen_netbk_alloc_netbk(vif);
+	if (!vif->netbk) {
+		pr_warn("Could not allocate xen_netbk\n");
+		err = -ENOMEM;
+		goto err_unbind;
+	}
+
+
+	init_waitqueue_head(&vif->wq);
+	vif->task = kthread_create(xen_netbk_kthread,
+				   (void *)vif,
+				   "vif%d.%d", vif->domid, vif->handle);
+	if (IS_ERR(vif->task)) {
+		pr_warn("Could not create kthread\n");
+		err = PTR_ERR(vif->task);
+		goto err_free_netbk;
+	}
 
 	rtnl_lock();
 	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
@@ -335,7 +362,13 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		xenvif_up(vif);
 	rtnl_unlock();
 
+	wake_up_process(vif->task);
+
 	return 0;
+err_free_netbk:
+	xen_netbk_free_netbk(vif->netbk);
+err_unbind:
+	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
@@ -345,17 +378,22 @@ err:
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
 		netif_carrier_off(dev); /* discard queued packets */
 		if (netif_running(dev))
 			xenvif_down(vif);
 		rtnl_unlock();
-		xenvif_put(vif);
 	}
 
-	atomic_dec(&vif->refcnt);
-	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
+	if (vif->task)
+		kthread_stop(vif->task);
+
+	if (vif->netbk)
+		xen_netbk_free_netbk(vif->netbk);
+
+	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3059684..7378d63 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -61,24 +61,15 @@ struct netbk_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
-	wait_queue_head_t wq;
-	struct task_struct *task;
-
 	struct sk_buff_head rx_queue;
 	struct sk_buff_head tx_queue;
 
-	struct timer_list net_timer;
-
 	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
-	struct list_head net_schedule_list;
-
-	/* Protect the net_schedule_list in netif. */
-	spinlock_t net_schedule_list_lock;
 
-	atomic_t netfront_count;
+	struct xenvif *vif;
 
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
@@ -93,42 +84,14 @@ struct xen_netbk {
 	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
-static struct xen_netbk *xen_netbk;
-static int xen_netbk_group_nr;
-
-void xen_netbk_add_xenvif(struct xenvif *vif)
-{
-	int i;
-	int min_netfront_count;
-	int min_group = 0;
-	struct xen_netbk *netbk;
-
-	min_netfront_count = atomic_read(&xen_netbk[0].netfront_count);
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		int netfront_count = atomic_read(&xen_netbk[i].netfront_count);
-		if (netfront_count < min_netfront_count) {
-			min_group = i;
-			min_netfront_count = netfront_count;
-		}
-	}
-
-	netbk = &xen_netbk[min_group];
-
-	vif->netbk = netbk;
-	atomic_inc(&netbk->netfront_count);
-}
-
-void xen_netbk_remove_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	vif->netbk = NULL;
-	atomic_dec(&netbk->netfront_count);
-}
-
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
+
+static inline int tx_work_todo(struct xen_netbk *netbk);
+static inline int rx_work_todo(struct xen_netbk *netbk);
+
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
 					     s8       st,
@@ -179,11 +142,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
 		netbk->pending_prod + netbk->pending_cons;
 }
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
-{
-	wake_up(&netbk->wq);
-}
-
 static int max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
@@ -369,7 +327,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
 
-			copy_gop->source.domid = src_pend->vif->domid;
+			copy_gop->source.domid = vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -527,11 +485,18 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_rx_action(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xen_netbk *netbk)
 {
-	struct xenvif *vif = NULL, *tmp;
+	struct xenvif *vif = netbk->vif;
+
+	wake_up(&vif->wq);
+}
+
+void xen_netbk_rx_action(struct xen_netbk *netbk)
+{
+	struct xenvif *vif = NULL;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -541,6 +506,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int count;
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
 		.copy  = netbk->grant_copy_op,
@@ -641,25 +607,19 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
-		if (ret && list_empty(&vif->notify_list))
-			list_add_tail(&vif->notify_list, &notify);
+		if (ret)
+			need_to_notify = 1;
 
 		xenvif_notify_tx_completion(vif);
 
-		xenvif_put(vif);
 		npo.meta_cons += sco->meta_slots_used;
 		dev_kfree_skb(skb);
 	}
 
-	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
+	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
-		list_del_init(&vif->notify_list);
-	}
 
-	/* More work to do? */
-	if (!skb_queue_empty(&netbk->rx_queue) &&
-			!timer_pending(&netbk->net_timer))
+	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
 }
 
@@ -672,86 +632,17 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 	xen_netbk_kick_thread(netbk);
 }
 
-static void xen_netbk_alarm(unsigned long data)
-{
-	struct xen_netbk *netbk = (struct xen_netbk *)data;
-	xen_netbk_kick_thread(netbk);
-}
-
-static int __on_net_schedule_list(struct xenvif *vif)
-{
-	return !list_empty(&vif->schedule_list);
-}
-
-/* Must be called with net_schedule_list_lock held */
-static void remove_from_net_schedule_list(struct xenvif *vif)
-{
-	if (likely(__on_net_schedule_list(vif))) {
-		list_del_init(&vif->schedule_list);
-		xenvif_put(vif);
-	}
-}
-
-static struct xenvif *poll_net_schedule_list(struct xen_netbk *netbk)
-{
-	struct xenvif *vif = NULL;
-
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	if (list_empty(&netbk->net_schedule_list))
-		goto out;
-
-	vif = list_first_entry(&netbk->net_schedule_list,
-			       struct xenvif, schedule_list);
-	if (!vif)
-		goto out;
-
-	xenvif_get(vif);
-
-	remove_from_net_schedule_list(vif);
-out:
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-	return vif;
-}
-
-void xen_netbk_schedule_xenvif(struct xenvif *vif)
-{
-	unsigned long flags;
-	struct xen_netbk *netbk = vif->netbk;
-
-	if (__on_net_schedule_list(vif))
-		goto kick;
-
-	spin_lock_irqsave(&netbk->net_schedule_list_lock, flags);
-	if (!__on_net_schedule_list(vif) &&
-	    likely(xenvif_schedulable(vif))) {
-		list_add_tail(&vif->schedule_list, &netbk->net_schedule_list);
-		xenvif_get(vif);
-	}
-	spin_unlock_irqrestore(&netbk->net_schedule_list_lock, flags);
-
-kick:
-	smp_mb();
-	if ((nr_pending_reqs(netbk) < (MAX_PENDING_REQS/2)) &&
-	    !list_empty(&netbk->net_schedule_list))
-		xen_netbk_kick_thread(netbk);
-}
-
-void xen_netbk_deschedule_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	remove_from_net_schedule_list(vif);
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-}
-
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
 	RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
 
+	/* In this check function, we are supposed to do be's rx,
+	 * which means fe's tx */
+
 	if (more_to_do)
-		xen_netbk_schedule_xenvif(vif);
+		napi_schedule(&vif->napi);
 }
 
 static void tx_add_credit(struct xenvif *vif)
@@ -794,7 +685,6 @@ static void netbk_tx_err(struct xenvif *vif,
 	} while (1);
 	vif->tx.req_cons = cons;
 	xen_netbk_check_rx_xenvif(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
@@ -894,8 +784,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		gop++;
 
 		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
-		xenvif_get(vif);
-		pending_tx_info->vif = vif;
+
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -910,7 +799,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = NULL;
+	struct xenvif *vif = netbk->vif;
+
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -924,10 +814,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		idx = netbk->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
-		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -951,11 +839,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		/* Error on this fragment: respond to client with an error. */
 		idx = netbk->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
-		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1171,10 +1057,9 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
+	struct xenvif *vif = netbk->vif;
 
-	while (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-		!list_empty(&netbk->net_schedule_list)) {
-		struct xenvif *vif;
+	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1187,26 +1072,19 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		/* Get a netif from the list with work to do. */
-		vif = poll_net_schedule_list(netbk);
-		if (!vif)
-			continue;
-
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		idx = vif->tx.req_cons;
 		rmb(); /* Ensure that we see the request before we copy it. */
 		memcpy(&txreq, RING_GET_REQUEST(&vif->tx, idx), sizeof(txreq));
 
-		/* Credit-based scheduling. */
+		/* Credit-based traffic shaping. */
 		if (txreq.size > vif->remaining_credit &&
 		    tx_credit_exceeded(vif, txreq.size)) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		vif->remaining_credit -= txreq.size;
@@ -1221,14 +1099,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
 			netbk_tx_err(vif, &txreq, idx - ret);
-			continue;
+			break;
 		}
 		idx += ret;
 
@@ -1236,7 +1114,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
@@ -1246,7 +1124,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		index = pending_index(netbk->pending_cons);
@@ -1275,7 +1153,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			if (netbk_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
@@ -1284,7 +1162,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		gop->source.u.ref = txreq.gref;
@@ -1305,7 +1183,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		pending_tx_info->vif = vif;
+
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1329,7 +1207,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (request_gop == NULL) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 		gop = request_gop;
 
@@ -1343,14 +1221,16 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	return gop - netbk->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk)
+static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = netbk->tx_copy_ops;
 	struct sk_buff *skb;
+	struct xenvif *vif = netbk->vif;
 
-	while ((skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	while ((*work_done < budget) &&
+	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
-		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
 		int idx;
@@ -1361,7 +1241,6 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		idx = netbk->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
-		vif = pending_tx_info->vif;
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
@@ -1415,16 +1294,21 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
+		(*work_done)++;
+
 		xenvif_receive_skb(vif, skb);
 	}
 }
 
 /* Called after netfront has transmitted */
-static void xen_netbk_tx_action(struct xen_netbk *netbk)
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
+	if (unlikely(!tx_work_todo(netbk)))
+		return;
+
 	nr_gops = xen_netbk_tx_build_gops(netbk);
 
 	if (nr_gops == 0)
@@ -1433,13 +1317,12 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 					netbk->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk);
-
+	xen_netbk_tx_submit(netbk, work_done, budget);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 {
-	struct xenvif *vif;
+	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
@@ -1451,15 +1334,11 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	idx = netbk->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
-	vif = pending_tx_info->vif;
-
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
 
-	xenvif_put(vif);
-
 	page_pool_put(netbk->mmap_pages[pending_idx]);
 
 	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
@@ -1516,37 +1395,13 @@ static inline int rx_work_todo(struct xen_netbk *netbk)
 
 static inline int tx_work_todo(struct xen_netbk *netbk)
 {
-
-	if (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-			!list_empty(&netbk->net_schedule_list))
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
+	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
 }
 
-static int xen_netbk_kthread(void *data)
-{
-	struct xen_netbk *netbk = data;
-	while (!kthread_should_stop()) {
-		wait_event_interruptible(netbk->wq,
-				rx_work_todo(netbk) ||
-				tx_work_todo(netbk) ||
-				kthread_should_stop());
-		cond_resched();
-
-		if (kthread_should_stop())
-			break;
-
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
-
-		if (tx_work_todo(netbk))
-			xen_netbk_tx_action(netbk);
-	}
-
-	return 0;
-}
-
 void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
@@ -1592,78 +1447,74 @@ err:
 	return err;
 }
 
-static int __init netback_init(void)
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 {
 	int i;
-	int rc = 0;
-	int group;
-
-	if (!xen_domain())
-		return -ENODEV;
+	struct xen_netbk *netbk;
 
-	xen_netbk_group_nr = num_online_cpus();
-	xen_netbk = vzalloc(sizeof(struct xen_netbk) * xen_netbk_group_nr);
-	if (!xen_netbk) {
+	netbk = vzalloc(sizeof(struct xen_netbk));
+	if (!netbk) {
 		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return -ENOMEM;
+		return NULL;
 	}
 
-	for (group = 0; group < xen_netbk_group_nr; group++) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		skb_queue_head_init(&netbk->rx_queue);
-		skb_queue_head_init(&netbk->tx_queue);
-
-		init_timer(&netbk->net_timer);
-		netbk->net_timer.data = (unsigned long)netbk;
-		netbk->net_timer.function = xen_netbk_alarm;
-
-		netbk->pending_cons = 0;
-		netbk->pending_prod = MAX_PENDING_REQS;
-		for (i = 0; i < MAX_PENDING_REQS; i++)
-			netbk->pending_ring[i] = i;
-
-		init_waitqueue_head(&netbk->wq);
-		netbk->task = kthread_create(xen_netbk_kthread,
-					     (void *)netbk,
-					     "netback/%u", group);
-
-		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_create() fails at netback\n");
-			del_timer(&netbk->net_timer);
-			rc = PTR_ERR(netbk->task);
-			goto failed_init;
-		}
+	netbk->vif = vif;
 
-		kthread_bind(netbk->task, group);
+	skb_queue_head_init(&netbk->rx_queue);
+	skb_queue_head_init(&netbk->tx_queue);
 
-		INIT_LIST_HEAD(&netbk->net_schedule_list);
+	netbk->pending_cons = 0;
+	netbk->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->pending_ring[i] = i;
 
-		spin_lock_init(&netbk->net_schedule_list_lock);
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->mmap_pages[i] = INVALID_ENTRY;
 
-		atomic_set(&netbk->netfront_count, 0);
+	return netbk;
+}
 
-		wake_up_process(netbk->task);
+void xen_netbk_free_netbk(struct xen_netbk *netbk)
+{
+	vfree(netbk);
+}
+
+int xen_netbk_kthread(void *data)
+{
+	struct xenvif *vif = data;
+	struct xen_netbk *netbk = vif->netbk;
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(vif->wq,
+					 rx_work_todo(netbk) ||
+					 kthread_should_stop());
+		cond_resched();
+
+		if (kthread_should_stop())
+			break;
+
+		if (rx_work_todo(netbk))
+			xen_netbk_rx_action(netbk);
 	}
 
+	return 0;
+}
+
+
+static int __init netback_init(void)
+{
+	int rc = 0;
+
+	if (!xen_domain())
+		return -ENODEV;
+
 	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
-	rc = xenvif_xenbus_init();
-	if (rc)
-		goto pool_failed_init;
-
-	return 0;
+	return xenvif_xenbus_init();
 
-pool_failed_init:
-	page_pool_destroy();
 failed_init:
-	while (--group >= 0) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	return rc;
 
 }
@@ -1672,14 +1523,7 @@ module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
-	int i;
 	xenvif_xenbus_exit();
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		struct xen_netbk *netbk = &xen_netbk[i];
-		del_timer_sync(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	page_pool_destroy();
 }
 module_exit(netback_exit);
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..f1e89ca 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -387,7 +387,6 @@ static void connect(struct backend_info *be)
 	netif_wake_queue(be->vif->dev);
 }
 
-
 static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13: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 1Rn9Ob-0002x3-Bk; Tue, 17 Jan 2012 13:48:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rn9Oa-0002vY-4Y
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:48:16 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326808044!60572708!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzIzNzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18477 invoked from network); 17 Jan 2012 13:47:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:47:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320642000"; d="scan'208";a="177838496"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 08:48:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 08:48:08 -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 q0HDm0fV005778;
	Tue, 17 Jan 2012 05:48:06 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: ian.campbell@citrix.com, netdev@vger.kernel.org,
	xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:46:59 +0000
Message-ID: <1326808024-3744-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>,
	david.vrabel@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V2 3/8] netback: switch to NAPI + kthread
	model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements 1:1 model netback. We utilizes NAPI and kthread
to do the weight-lifting job:

  - NAPI is used for guest side TX (host side RX)
  - kthread is used for guest side RX (host side TX)

This model provides better scheduling fairness among vifs. It also
lays the foundation for future work.

The major defect for the current implementation is that in the NAPI
poll handler we don't actually disable interrupt. Xen stuff is
different from real hardware, it requires some other tuning of ring
macros.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   34 ++--
 drivers/net/xen-netback/interface.c |   92 ++++++---
 drivers/net/xen-netback/netback.c   |  366 ++++++++++-------------------------
 drivers/net/xen-netback/xenbus.c    |    1 -
 4 files changed, 185 insertions(+), 308 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 372c7f5..31c331c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,6 @@
 
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
-	struct xenvif *vif;
 };
 typedef unsigned int pending_ring_idx_t;
 
@@ -61,14 +60,17 @@ struct xenvif {
 	/* Reference to netback processing backend. */
 	struct xen_netbk *netbk;
 
+	/* Use NAPI for guest TX */
+	struct napi_struct napi;
+	/* Use kthread for guest RX */
+	struct task_struct *task;
+	wait_queue_head_t wq;
+
 	u8               fe_dev_addr[6];
 
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* List of frontends to notify after a batch of frames sent. */
-	struct list_head notify_list;
-
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
@@ -99,11 +101,7 @@ struct xenvif {
 	unsigned long rx_gso_checksum_fixup;
 
 	/* Miscellaneous private stuff. */
-	struct list_head schedule_list;
-	atomic_t         refcnt;
 	struct net_device *dev;
-
-	wait_queue_head_t waiting_to_free;
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +120,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
-void xenvif_get(struct xenvif *vif);
-void xenvif_put(struct xenvif *vif);
-
 int xenvif_xenbus_init(void);
 void xenvif_xenbus_exit(void);
 
@@ -140,14 +135,6 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 				 grant_ref_t tx_ring_ref,
 				 grant_ref_t rx_ring_ref);
 
-/* (De)Register a xenvif with the netback backend. */
-void xen_netbk_add_xenvif(struct xenvif *vif);
-void xen_netbk_remove_xenvif(struct xenvif *vif);
-
-/* (De)Schedule backend processing for a xenvif */
-void xen_netbk_schedule_xenvif(struct xenvif *vif);
-void xen_netbk_deschedule_xenvif(struct xenvif *vif);
-
 /* Check for SKBs from frontend and schedule backend processing */
 void xen_netbk_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
@@ -161,4 +148,13 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+/* Allocate and free xen_netbk structure */
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
+void xen_netbk_free_netbk(struct xen_netbk *netbk);
+
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
+void xen_netbk_rx_action(struct xen_netbk *netbk);
+
+int xen_netbk_kthread(void *data);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1825629..dfc04f8 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -30,6 +30,7 @@
 
 #include "common.h"
 
+#include <linux/kthread.h>
 #include <linux/ethtool.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
@@ -38,17 +39,7 @@
 #include <asm/xen/hypercall.h>
 
 #define XENVIF_QUEUE_LENGTH 32
-
-void xenvif_get(struct xenvif *vif)
-{
-	atomic_inc(&vif->refcnt);
-}
-
-void xenvif_put(struct xenvif *vif)
-{
-	if (atomic_dec_and_test(&vif->refcnt))
-		wake_up(&vif->waiting_to_free);
-}
+#define XENVIF_NAPI_WEIGHT  64
 
 int xenvif_schedulable(struct xenvif *vif)
 {
@@ -67,14 +58,37 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (vif->netbk == NULL)
 		return IRQ_NONE;
 
-	xen_netbk_schedule_xenvif(vif);
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
+	if (likely(napi_schedule_prep(&vif->napi)))
+		__napi_schedule(&vif->napi);
+
 	return IRQ_HANDLED;
 }
 
+static int xenvif_poll(struct napi_struct *napi, int budget)
+{
+	struct xenvif *vif = container_of(napi, struct xenvif, napi);
+	int work_done = 0;
+
+	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+
+	if (work_done < budget) {
+		int more_to_do = 0;
+		unsigned long flag;
+		local_irq_save(flag);
+
+		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
+		if (!more_to_do)
+			__napi_complete(napi);
+
+		local_irq_restore(flag);
+	}
+
+	return work_done;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -90,7 +104,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Reserve ring slots for the worst-case number of fragments. */
 	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
-	xenvif_get(vif);
 
 	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
 		netif_stop_queue(dev);
@@ -107,7 +120,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	netif_rx_ni(skb);
+	netif_receive_skb(skb);
 }
 
 void xenvif_notify_tx_completion(struct xenvif *vif)
@@ -124,16 +137,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 
 static void xenvif_up(struct xenvif *vif)
 {
-	xen_netbk_add_xenvif(vif);
+	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
+	napi_disable(&vif->napi);
 	disable_irq(vif->irq);
-	xen_netbk_deschedule_xenvif(vif);
-	xen_netbk_remove_xenvif(vif);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -259,14 +271,11 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk  = NULL;
+	vif->netbk = NULL;
+
 	vif->can_sg = 1;
 	vif->csum = 1;
-	atomic_set(&vif->refcnt, 1);
-	init_waitqueue_head(&vif->waiting_to_free);
 	vif->dev = dev;
-	INIT_LIST_HEAD(&vif->schedule_list);
-	INIT_LIST_HEAD(&vif->notify_list);
 
 	vif->credit_bytes = vif->remaining_credit = ~0UL;
 	vif->credit_usec  = 0UL;
@@ -290,6 +299,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	memset(dev->dev_addr, 0xFF, ETH_ALEN);
 	dev->dev_addr[0] &= ~0x01;
 
+	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
+
 	netif_carrier_off(dev);
 
 	err = register_netdev(dev);
@@ -324,7 +335,23 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
+	vif->netbk = xen_netbk_alloc_netbk(vif);
+	if (!vif->netbk) {
+		pr_warn("Could not allocate xen_netbk\n");
+		err = -ENOMEM;
+		goto err_unbind;
+	}
+
+
+	init_waitqueue_head(&vif->wq);
+	vif->task = kthread_create(xen_netbk_kthread,
+				   (void *)vif,
+				   "vif%d.%d", vif->domid, vif->handle);
+	if (IS_ERR(vif->task)) {
+		pr_warn("Could not create kthread\n");
+		err = PTR_ERR(vif->task);
+		goto err_free_netbk;
+	}
 
 	rtnl_lock();
 	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
@@ -335,7 +362,13 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		xenvif_up(vif);
 	rtnl_unlock();
 
+	wake_up_process(vif->task);
+
 	return 0;
+err_free_netbk:
+	xen_netbk_free_netbk(vif->netbk);
+err_unbind:
+	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
@@ -345,17 +378,22 @@ err:
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
 		netif_carrier_off(dev); /* discard queued packets */
 		if (netif_running(dev))
 			xenvif_down(vif);
 		rtnl_unlock();
-		xenvif_put(vif);
 	}
 
-	atomic_dec(&vif->refcnt);
-	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
+	if (vif->task)
+		kthread_stop(vif->task);
+
+	if (vif->netbk)
+		xen_netbk_free_netbk(vif->netbk);
+
+	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3059684..7378d63 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -61,24 +61,15 @@ struct netbk_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
-	wait_queue_head_t wq;
-	struct task_struct *task;
-
 	struct sk_buff_head rx_queue;
 	struct sk_buff_head tx_queue;
 
-	struct timer_list net_timer;
-
 	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
-	struct list_head net_schedule_list;
-
-	/* Protect the net_schedule_list in netif. */
-	spinlock_t net_schedule_list_lock;
 
-	atomic_t netfront_count;
+	struct xenvif *vif;
 
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
@@ -93,42 +84,14 @@ struct xen_netbk {
 	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
-static struct xen_netbk *xen_netbk;
-static int xen_netbk_group_nr;
-
-void xen_netbk_add_xenvif(struct xenvif *vif)
-{
-	int i;
-	int min_netfront_count;
-	int min_group = 0;
-	struct xen_netbk *netbk;
-
-	min_netfront_count = atomic_read(&xen_netbk[0].netfront_count);
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		int netfront_count = atomic_read(&xen_netbk[i].netfront_count);
-		if (netfront_count < min_netfront_count) {
-			min_group = i;
-			min_netfront_count = netfront_count;
-		}
-	}
-
-	netbk = &xen_netbk[min_group];
-
-	vif->netbk = netbk;
-	atomic_inc(&netbk->netfront_count);
-}
-
-void xen_netbk_remove_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	vif->netbk = NULL;
-	atomic_dec(&netbk->netfront_count);
-}
-
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
+
+static inline int tx_work_todo(struct xen_netbk *netbk);
+static inline int rx_work_todo(struct xen_netbk *netbk);
+
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
 					     s8       st,
@@ -179,11 +142,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
 		netbk->pending_prod + netbk->pending_cons;
 }
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
-{
-	wake_up(&netbk->wq);
-}
-
 static int max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
@@ -369,7 +327,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
 
-			copy_gop->source.domid = src_pend->vif->domid;
+			copy_gop->source.domid = vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -527,11 +485,18 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_rx_action(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xen_netbk *netbk)
 {
-	struct xenvif *vif = NULL, *tmp;
+	struct xenvif *vif = netbk->vif;
+
+	wake_up(&vif->wq);
+}
+
+void xen_netbk_rx_action(struct xen_netbk *netbk)
+{
+	struct xenvif *vif = NULL;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -541,6 +506,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int count;
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
 		.copy  = netbk->grant_copy_op,
@@ -641,25 +607,19 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
-		if (ret && list_empty(&vif->notify_list))
-			list_add_tail(&vif->notify_list, &notify);
+		if (ret)
+			need_to_notify = 1;
 
 		xenvif_notify_tx_completion(vif);
 
-		xenvif_put(vif);
 		npo.meta_cons += sco->meta_slots_used;
 		dev_kfree_skb(skb);
 	}
 
-	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
+	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
-		list_del_init(&vif->notify_list);
-	}
 
-	/* More work to do? */
-	if (!skb_queue_empty(&netbk->rx_queue) &&
-			!timer_pending(&netbk->net_timer))
+	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
 }
 
@@ -672,86 +632,17 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 	xen_netbk_kick_thread(netbk);
 }
 
-static void xen_netbk_alarm(unsigned long data)
-{
-	struct xen_netbk *netbk = (struct xen_netbk *)data;
-	xen_netbk_kick_thread(netbk);
-}
-
-static int __on_net_schedule_list(struct xenvif *vif)
-{
-	return !list_empty(&vif->schedule_list);
-}
-
-/* Must be called with net_schedule_list_lock held */
-static void remove_from_net_schedule_list(struct xenvif *vif)
-{
-	if (likely(__on_net_schedule_list(vif))) {
-		list_del_init(&vif->schedule_list);
-		xenvif_put(vif);
-	}
-}
-
-static struct xenvif *poll_net_schedule_list(struct xen_netbk *netbk)
-{
-	struct xenvif *vif = NULL;
-
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	if (list_empty(&netbk->net_schedule_list))
-		goto out;
-
-	vif = list_first_entry(&netbk->net_schedule_list,
-			       struct xenvif, schedule_list);
-	if (!vif)
-		goto out;
-
-	xenvif_get(vif);
-
-	remove_from_net_schedule_list(vif);
-out:
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-	return vif;
-}
-
-void xen_netbk_schedule_xenvif(struct xenvif *vif)
-{
-	unsigned long flags;
-	struct xen_netbk *netbk = vif->netbk;
-
-	if (__on_net_schedule_list(vif))
-		goto kick;
-
-	spin_lock_irqsave(&netbk->net_schedule_list_lock, flags);
-	if (!__on_net_schedule_list(vif) &&
-	    likely(xenvif_schedulable(vif))) {
-		list_add_tail(&vif->schedule_list, &netbk->net_schedule_list);
-		xenvif_get(vif);
-	}
-	spin_unlock_irqrestore(&netbk->net_schedule_list_lock, flags);
-
-kick:
-	smp_mb();
-	if ((nr_pending_reqs(netbk) < (MAX_PENDING_REQS/2)) &&
-	    !list_empty(&netbk->net_schedule_list))
-		xen_netbk_kick_thread(netbk);
-}
-
-void xen_netbk_deschedule_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	remove_from_net_schedule_list(vif);
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-}
-
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
 	RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
 
+	/* In this check function, we are supposed to do be's rx,
+	 * which means fe's tx */
+
 	if (more_to_do)
-		xen_netbk_schedule_xenvif(vif);
+		napi_schedule(&vif->napi);
 }
 
 static void tx_add_credit(struct xenvif *vif)
@@ -794,7 +685,6 @@ static void netbk_tx_err(struct xenvif *vif,
 	} while (1);
 	vif->tx.req_cons = cons;
 	xen_netbk_check_rx_xenvif(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
@@ -894,8 +784,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		gop++;
 
 		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
-		xenvif_get(vif);
-		pending_tx_info->vif = vif;
+
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -910,7 +799,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = NULL;
+	struct xenvif *vif = netbk->vif;
+
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -924,10 +814,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		idx = netbk->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
-		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -951,11 +839,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		/* Error on this fragment: respond to client with an error. */
 		idx = netbk->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
-		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1171,10 +1057,9 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
+	struct xenvif *vif = netbk->vif;
 
-	while (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-		!list_empty(&netbk->net_schedule_list)) {
-		struct xenvif *vif;
+	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1187,26 +1072,19 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		/* Get a netif from the list with work to do. */
-		vif = poll_net_schedule_list(netbk);
-		if (!vif)
-			continue;
-
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		idx = vif->tx.req_cons;
 		rmb(); /* Ensure that we see the request before we copy it. */
 		memcpy(&txreq, RING_GET_REQUEST(&vif->tx, idx), sizeof(txreq));
 
-		/* Credit-based scheduling. */
+		/* Credit-based traffic shaping. */
 		if (txreq.size > vif->remaining_credit &&
 		    tx_credit_exceeded(vif, txreq.size)) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		vif->remaining_credit -= txreq.size;
@@ -1221,14 +1099,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
 			netbk_tx_err(vif, &txreq, idx - ret);
-			continue;
+			break;
 		}
 		idx += ret;
 
@@ -1236,7 +1114,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
@@ -1246,7 +1124,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		index = pending_index(netbk->pending_cons);
@@ -1275,7 +1153,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			if (netbk_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
@@ -1284,7 +1162,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		gop->source.u.ref = txreq.gref;
@@ -1305,7 +1183,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		pending_tx_info->vif = vif;
+
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1329,7 +1207,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (request_gop == NULL) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 		gop = request_gop;
 
@@ -1343,14 +1221,16 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	return gop - netbk->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk)
+static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = netbk->tx_copy_ops;
 	struct sk_buff *skb;
+	struct xenvif *vif = netbk->vif;
 
-	while ((skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	while ((*work_done < budget) &&
+	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
-		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
 		int idx;
@@ -1361,7 +1241,6 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		idx = netbk->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
-		vif = pending_tx_info->vif;
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
@@ -1415,16 +1294,21 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
+		(*work_done)++;
+
 		xenvif_receive_skb(vif, skb);
 	}
 }
 
 /* Called after netfront has transmitted */
-static void xen_netbk_tx_action(struct xen_netbk *netbk)
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
+	if (unlikely(!tx_work_todo(netbk)))
+		return;
+
 	nr_gops = xen_netbk_tx_build_gops(netbk);
 
 	if (nr_gops == 0)
@@ -1433,13 +1317,12 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 					netbk->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk);
-
+	xen_netbk_tx_submit(netbk, work_done, budget);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 {
-	struct xenvif *vif;
+	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
@@ -1451,15 +1334,11 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	idx = netbk->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
-	vif = pending_tx_info->vif;
-
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
 
-	xenvif_put(vif);
-
 	page_pool_put(netbk->mmap_pages[pending_idx]);
 
 	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
@@ -1516,37 +1395,13 @@ static inline int rx_work_todo(struct xen_netbk *netbk)
 
 static inline int tx_work_todo(struct xen_netbk *netbk)
 {
-
-	if (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-			!list_empty(&netbk->net_schedule_list))
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
+	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
 }
 
-static int xen_netbk_kthread(void *data)
-{
-	struct xen_netbk *netbk = data;
-	while (!kthread_should_stop()) {
-		wait_event_interruptible(netbk->wq,
-				rx_work_todo(netbk) ||
-				tx_work_todo(netbk) ||
-				kthread_should_stop());
-		cond_resched();
-
-		if (kthread_should_stop())
-			break;
-
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
-
-		if (tx_work_todo(netbk))
-			xen_netbk_tx_action(netbk);
-	}
-
-	return 0;
-}
-
 void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
@@ -1592,78 +1447,74 @@ err:
 	return err;
 }
 
-static int __init netback_init(void)
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 {
 	int i;
-	int rc = 0;
-	int group;
-
-	if (!xen_domain())
-		return -ENODEV;
+	struct xen_netbk *netbk;
 
-	xen_netbk_group_nr = num_online_cpus();
-	xen_netbk = vzalloc(sizeof(struct xen_netbk) * xen_netbk_group_nr);
-	if (!xen_netbk) {
+	netbk = vzalloc(sizeof(struct xen_netbk));
+	if (!netbk) {
 		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return -ENOMEM;
+		return NULL;
 	}
 
-	for (group = 0; group < xen_netbk_group_nr; group++) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		skb_queue_head_init(&netbk->rx_queue);
-		skb_queue_head_init(&netbk->tx_queue);
-
-		init_timer(&netbk->net_timer);
-		netbk->net_timer.data = (unsigned long)netbk;
-		netbk->net_timer.function = xen_netbk_alarm;
-
-		netbk->pending_cons = 0;
-		netbk->pending_prod = MAX_PENDING_REQS;
-		for (i = 0; i < MAX_PENDING_REQS; i++)
-			netbk->pending_ring[i] = i;
-
-		init_waitqueue_head(&netbk->wq);
-		netbk->task = kthread_create(xen_netbk_kthread,
-					     (void *)netbk,
-					     "netback/%u", group);
-
-		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_create() fails at netback\n");
-			del_timer(&netbk->net_timer);
-			rc = PTR_ERR(netbk->task);
-			goto failed_init;
-		}
+	netbk->vif = vif;
 
-		kthread_bind(netbk->task, group);
+	skb_queue_head_init(&netbk->rx_queue);
+	skb_queue_head_init(&netbk->tx_queue);
 
-		INIT_LIST_HEAD(&netbk->net_schedule_list);
+	netbk->pending_cons = 0;
+	netbk->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->pending_ring[i] = i;
 
-		spin_lock_init(&netbk->net_schedule_list_lock);
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->mmap_pages[i] = INVALID_ENTRY;
 
-		atomic_set(&netbk->netfront_count, 0);
+	return netbk;
+}
 
-		wake_up_process(netbk->task);
+void xen_netbk_free_netbk(struct xen_netbk *netbk)
+{
+	vfree(netbk);
+}
+
+int xen_netbk_kthread(void *data)
+{
+	struct xenvif *vif = data;
+	struct xen_netbk *netbk = vif->netbk;
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(vif->wq,
+					 rx_work_todo(netbk) ||
+					 kthread_should_stop());
+		cond_resched();
+
+		if (kthread_should_stop())
+			break;
+
+		if (rx_work_todo(netbk))
+			xen_netbk_rx_action(netbk);
 	}
 
+	return 0;
+}
+
+
+static int __init netback_init(void)
+{
+	int rc = 0;
+
+	if (!xen_domain())
+		return -ENODEV;
+
 	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
-	rc = xenvif_xenbus_init();
-	if (rc)
-		goto pool_failed_init;
-
-	return 0;
+	return xenvif_xenbus_init();
 
-pool_failed_init:
-	page_pool_destroy();
 failed_init:
-	while (--group >= 0) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	return rc;
 
 }
@@ -1672,14 +1523,7 @@ module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
-	int i;
 	xenvif_xenbus_exit();
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		struct xen_netbk *netbk = &xen_netbk[i];
-		del_timer_sync(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	page_pool_destroy();
 }
 module_exit(netback_exit);
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..f1e89ca 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -387,7 +387,6 @@ static void connect(struct backend_info *be)
 	netif_wake_queue(be->vif->dev);
 }
 
-
 static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:51:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:51:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9RO-0003xt-Un; Tue, 17 Jan 2012 13:51:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rn9RO-0003wO-4X
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:51:10 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808263!3920681!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27584 invoked from network); 17 Jan 2012 13:51:04 -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;
	17 Jan 2012 13:51:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10084477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 13:51:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 13:51:03 +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 1Rn9RH-0004hs-4R;
	Tue, 17 Jan 2012 13:51:03 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rn9R9-0002tx-Aa;
	Tue, 17 Jan 2012 13:50:55 +0000
Date: Tue, 17 Jan 2012 13:50:55 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: "djmagee@mageenet.net" <djmagee@mageenet.net>
Message-ID: <20120117135055.GC8921@spongy.cam.xci-test.com>
References: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
	<EECC125FCE18E740AF561189E12602851451AA@mnetexch2.adamapps.host>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EECC125FCE18E740AF561189E12602851451AA@mnetexch2.adamapps.host>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
 specificpci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 17/01 02:50, djmagee@mageenet.net wrote:
> This always fails because it checks cap_type before it's set.  Moving the pt_pci_host_read call before the check gets rid of these messages in qemu log:
> 
> pcilib: sysfs_read: read failed: Invalid argument
> 

This error is due to a missing patch that should be applied before this one.
I'll resend the patch within a serie that will include the extra patch.

Thanks for your review.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:51:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:51:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9RO-0003xt-Un; Tue, 17 Jan 2012 13:51:10 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rn9RO-0003wO-4X
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:51:10 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326808263!3920681!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27584 invoked from network); 17 Jan 2012 13:51:04 -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;
	17 Jan 2012 13:51:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10084477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 13:51:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 13:51:03 +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 1Rn9RH-0004hs-4R;
	Tue, 17 Jan 2012 13:51:03 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rn9R9-0002tx-Aa;
	Tue, 17 Jan 2012 13:50:55 +0000
Date: Tue, 17 Jan 2012 13:50:55 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: "djmagee@mageenet.net" <djmagee@mageenet.net>
Message-ID: <20120117135055.GC8921@spongy.cam.xci-test.com>
References: <1326724827-25759-1-git-send-email-jean.guyader@eu.citrix.com>
	<EECC125FCE18E740AF561189E12602851451AA@mnetexch2.adamapps.host>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EECC125FCE18E740AF561189E12602851451AA@mnetexch2.adamapps.host>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] intel gpu passthrough: Expose vendor
 specificpci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 17/01 02:50, djmagee@mageenet.net wrote:
> This always fails because it checks cap_type before it's set.  Moving the pt_pci_host_read call before the check gets rid of these messages in qemu log:
> 
> pcilib: sysfs_read: read failed: Invalid argument
> 

This error is due to a missing patch that should be applied before this one.
I'll resend the patch within a serie that will include the extra patch.

Thanks for your review.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 13:53:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Tk-0004QO-VB; Tue, 17 Jan 2012 13:53:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rn9Tj-0004PK-Bb
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:53:35 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326808408!9228584!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28331 invoked from network); 17 Jan 2012 13:53:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:53:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10084543"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 13:53:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 13:53:29 +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 1Rn9Tc-0004j5-Uy;
	Tue, 17 Jan 2012 13:53:28 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rn9TV-0002vk-4f;
	Tue, 17 Jan 2012 13:53:21 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 17 Jan 2012 13:53:18 +0000
Message-ID: <1326808398-11229-2-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
In-Reply-To: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, djmagee@mageenet.net, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, Ross.Philipson@citrix.com
Subject: [Xen-devel] [PATCH 2/2] intel gpu passthrough: Expose vendor
	specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


Some versions of the Windows Intel GPU driver expect the vendor
PCI capability to be there on the host bridge config space when
passing through a Intel GPU.

From: Ross Philipson <Ross.Philipson@citrix.com>
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Acked-by: Ross Philipson <Ross.Philipson@citrix.com>

---
 hw/pt-graphics.c |   49 ++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 44 insertions(+), 5 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..25e28ff 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -60,6 +60,42 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     }
 }
 
+#define PCI_INTEL_VENDOR_CAP            0x34
+#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
+static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
+                                        uint32_t val)
+{
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    uint32_t vendor_cap = 0;
+    uint32_t cap_type = 0;
+    uint32_t cap_size = 0;
+
+    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
+    if (!vendor_cap)
+        return -1;
+
+    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
+    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
+        return -1;
+
+    if (config_addr == PCI_INTEL_VENDOR_CAP)
+        return vendor_cap;
+
+    /* Remove the next capability link */
+    if (config_addr == vendor_cap + 1)
+        return 0;
+
+    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
+    if (config_addr >= vendor_cap &&
+            config_addr + len < vendor_cap + cap_size)
+    {
+        return pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+    }
+
+    /* -1, this function doesn't deal with this config space offset */
+    return -1;
+}
+
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -82,14 +118,17 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
             val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            val = pci_default_read_config(pci_dev, config_addr, len);
+            val = igd_pci_read_vendor_cap(pci_dev, config_addr, len, val);
+            if (val == -1)
+                val = pci_default_read_config(pci_dev, config_addr, len);
+
     }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+            config_addr, len, val);
+#endif
     return val;
 }
 

--------------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 Tue Jan 17 13:53:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 13:53:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9Tk-0004QO-VB; Tue, 17 Jan 2012 13:53:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rn9Tj-0004PK-Bb
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:53:35 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326808408!9228584!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28331 invoked from network); 17 Jan 2012 13:53:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:53:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10084543"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 13:53:29 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 13:53:29 +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 1Rn9Tc-0004j5-Uy;
	Tue, 17 Jan 2012 13:53:28 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rn9TV-0002vk-4f;
	Tue, 17 Jan 2012 13:53:21 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 17 Jan 2012 13:53:18 +0000
Message-ID: <1326808398-11229-2-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
In-Reply-To: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, djmagee@mageenet.net, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, Ross.Philipson@citrix.com
Subject: [Xen-devel] [PATCH 2/2] intel gpu passthrough: Expose vendor
	specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


Some versions of the Windows Intel GPU driver expect the vendor
PCI capability to be there on the host bridge config space when
passing through a Intel GPU.

From: Ross Philipson <Ross.Philipson@citrix.com>
Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
Acked-by: Ross Philipson <Ross.Philipson@citrix.com>

---
 hw/pt-graphics.c |   49 ++++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 44 insertions(+), 5 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..25e28ff 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -60,6 +60,42 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     }
 }
 
+#define PCI_INTEL_VENDOR_CAP            0x34
+#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
+static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
+                                        uint32_t val)
+{
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    uint32_t vendor_cap = 0;
+    uint32_t cap_type = 0;
+    uint32_t cap_size = 0;
+
+    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
+    if (!vendor_cap)
+        return -1;
+
+    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
+    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
+        return -1;
+
+    if (config_addr == PCI_INTEL_VENDOR_CAP)
+        return vendor_cap;
+
+    /* Remove the next capability link */
+    if (config_addr == vendor_cap + 1)
+        return 0;
+
+    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
+    if (config_addr >= vendor_cap &&
+            config_addr + len < vendor_cap + cap_size)
+    {
+        return pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+    }
+
+    /* -1, this function doesn't deal with this config space offset */
+    return -1;
+}
+
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -82,14 +118,17 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
             val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            val = pci_default_read_config(pci_dev, config_addr, len);
+            val = igd_pci_read_vendor_cap(pci_dev, config_addr, len, val);
+            if (val == -1)
+                val = pci_default_read_config(pci_dev, config_addr, len);
+
     }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+            config_addr, len, val);
+#endif
     return val;
 }
 

--------------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 Tue Jan 17 13:53:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 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 1Rn9Tk-0004QD-IV; Tue, 17 Jan 2012 13:53:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rn9Ti-0004PC-Mr
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:53:34 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326808408!9228584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28290 invoked from network); 17 Jan 2012 13:53:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:53:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10084542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 13: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; Tue, 17 Jan 2012 13:53: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 1Rn9Tc-0004j2-8K;
	Tue, 17 Jan 2012 13:53:28 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rn9TU-0002vd-Di;
	Tue, 17 Jan 2012 13:53:20 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:53:17 +0000
Message-ID: <1326808398-11229-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, djmagee@mageenet.net, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, Ross.Philipson@citrix.com
Subject: [Xen-devel] [PATCH 1/2] [passthrough] Change init for pt_pci_host
	return value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


With an init of -1 all the return value smaller than a double word
will be prefixed with "f"s.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..6a77657 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2085,7 +2085,7 @@ struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
 {
-    u32 val = -1;
+    u32 val = 0;
 
     pci_access_init();
     pci_read_block(pci_dev, addr, (u8 *) &val, len);

--------------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 Tue Jan 17 13:53:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 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 1Rn9Tk-0004QD-IV; Tue, 17 Jan 2012 13:53:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1Rn9Ti-0004PC-Mr
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:53:34 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326808408!9228584!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28290 invoked from network); 17 Jan 2012 13:53:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 13:53:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10084542"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 13: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; Tue, 17 Jan 2012 13:53: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 1Rn9Tc-0004j2-8K;
	Tue, 17 Jan 2012 13:53:28 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1Rn9TU-0002vd-Di;
	Tue, 17 Jan 2012 13:53:20 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 13:53:17 +0000
Message-ID: <1326808398-11229-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, djmagee@mageenet.net, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, Ross.Philipson@citrix.com
Subject: [Xen-devel] [PATCH 1/2] [passthrough] Change init for pt_pci_host
	return value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


With an init of -1 all the return value smaller than a double word
will be prefixed with "f"s.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..6a77657 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2085,7 +2085,7 @@ struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
 {
-    u32 val = -1;
+    u32 val = 0;
 
     pci_access_init();
     pci_read_block(pci_dev, addr, (u8 *) &val, len);

--------------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 Tue Jan 17 14:04:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14: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 1Rn9dm-0005Fr-QD; Tue, 17 Jan 2012 14:03:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1Rn9dl-0005Fc-LE
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:03:57 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326809030!11373630!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=1.9 required=7.0 tests=HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8433 invoked from network); 17 Jan 2012 14:03:51 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:03:51 -0000
Received: by ghbg18 with SMTP id g18so69751445ghb.30
	for <multiple recipients>; Tue, 17 Jan 2012 06:03:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=HCyeKHbQN21z0u6/Dmtz0vugIYT7qntYNQOaGQyjlvY=;
	b=C0QUGJ9AB/gL30rBJ/Vo1MszJEqQGHiPQOHR/3QweEKFzysNyYeCSo/tNqxm1Kluu/
	4uusWwf5yeDfSSsQLYE/pkj7ZqYNHM+DtzzqKIV6Qn/9nLYK4zk07qsOsXdU8Rcw5S8L
	qsDl2K2/NvyGyjx5H3gnhmK7vTylkkxIZ+DBE=
MIME-Version: 1.0
Received: by 10.50.190.196 with SMTP id gs4mr17678252igc.14.1326809030080;
	Tue, 17 Jan 2012 06:03:50 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Tue, 17 Jan 2012 06:03:50 -0800 (PST)
Date: Tue, 17 Jan 2012 15:03:50 +0100
Message-ID: <CAFoWEVN2YKRsKUvJ7uJDvegtRdre8TsgKY_rFJXq2=yYrPBO-A@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com, xen-user@lists.xensource.com
Subject: [Xen-devel] test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4689012186783824100=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4689012186783824100==
Content-Type: multipart/alternative; boundary=f46d04479ee3ec399504b6b9cc21

--f46d04479ee3ec399504b6b9cc21
Content-Type: text/plain; charset=ISO-8859-1

Just sending this test as I sent an email to the xen-devel and I never saw
it arrive in the list.

--f46d04479ee3ec399504b6b9cc21
Content-Type: text/html; charset=ISO-8859-1

Just sending this test as I sent an email to the xen-devel and I never saw it arrive in the list.

--f46d04479ee3ec399504b6b9cc21--


--===============4689012186783824100==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4689012186783824100==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:04:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14: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 1Rn9dm-0005Fr-QD; Tue, 17 Jan 2012 14:03:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1Rn9dl-0005Fc-LE
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:03:57 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326809030!11373630!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=1.9 required=7.0 tests=HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8433 invoked from network); 17 Jan 2012 14:03:51 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:03:51 -0000
Received: by ghbg18 with SMTP id g18so69751445ghb.30
	for <multiple recipients>; Tue, 17 Jan 2012 06:03:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=HCyeKHbQN21z0u6/Dmtz0vugIYT7qntYNQOaGQyjlvY=;
	b=C0QUGJ9AB/gL30rBJ/Vo1MszJEqQGHiPQOHR/3QweEKFzysNyYeCSo/tNqxm1Kluu/
	4uusWwf5yeDfSSsQLYE/pkj7ZqYNHM+DtzzqKIV6Qn/9nLYK4zk07qsOsXdU8Rcw5S8L
	qsDl2K2/NvyGyjx5H3gnhmK7vTylkkxIZ+DBE=
MIME-Version: 1.0
Received: by 10.50.190.196 with SMTP id gs4mr17678252igc.14.1326809030080;
	Tue, 17 Jan 2012 06:03:50 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Tue, 17 Jan 2012 06:03:50 -0800 (PST)
Date: Tue, 17 Jan 2012 15:03:50 +0100
Message-ID: <CAFoWEVN2YKRsKUvJ7uJDvegtRdre8TsgKY_rFJXq2=yYrPBO-A@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com, xen-user@lists.xensource.com
Subject: [Xen-devel] test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4689012186783824100=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4689012186783824100==
Content-Type: multipart/alternative; boundary=f46d04479ee3ec399504b6b9cc21

--f46d04479ee3ec399504b6b9cc21
Content-Type: text/plain; charset=ISO-8859-1

Just sending this test as I sent an email to the xen-devel and I never saw
it arrive in the list.

--f46d04479ee3ec399504b6b9cc21
Content-Type: text/html; charset=ISO-8859-1

Just sending this test as I sent an email to the xen-devel and I never saw it arrive in the list.

--f46d04479ee3ec399504b6b9cc21--


--===============4689012186783824100==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4689012186783824100==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:06:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9gJ-0005ZT-3y; Tue, 17 Jan 2012 14:06:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rn9gH-0005Y0-0o
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:06:33 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326809185!9331947!1
X-Originating-IP: [64.78.148.212]
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 19616 invoked from network); 17 Jan 2012 14:06:26 -0000
Received: from host212.adamapps.net (HELO host212.adamapps.net) (64.78.148.212)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 14:06:26 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host212.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HE6KBH001291;
	Tue, 17 Jan 2012 09:06:20 -0500
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 17 Jan 2012 09:05:57 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
In-Reply-To: <1326793645.14689.75.camel@zakaz.uk.xensource.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding to the domain
Thread-Index: AczU/ZoGPs4TQs+hSiSiIrD6+L/8FQAIv78w
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
From: <djmagee@mageenet.net>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

That was my first thought, but this was also the first thing in libxl I touched and wasn't sure what would happen if I ended up nesting GC_INITs.  If it's safe to do then I can call libxl_device_pci_list_assignable, otherwise I'd have to pull the meat out and put it in another function.  What's the best way to do it?

Doug

-----Original Message-----
From: Ian Campbell [mailto:Ian.Campbell@citrix.com] 
Sent: Tuesday, January 17, 2012 4:47 AM
To: djmagee@mageenet.net
Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is assignable before adding to the domain

On Mon, 2012-01-16 at 22:36 +0000, Doug Magee wrote:
> Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.
> 
> Signed-off-by: Doug Magee <djmagee@mageenet.net>

Thanks Doug. Would this be better done by adding a call to
libxl_device_pci_list_assignable and looking for the device in it? In
fact from the looks of things this could replace the existing call to
get_all_assigned_devices from .._pci_add since
libxl_device_pci_list_assignable already omits devices which are
assigned to another domain.

Ian.

> 
> diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_pci.c	Mon Jan 16 17:31:25 2012 -0500
> @@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
>      libxl_device_pci *assigned;
>      int num_assigned, i, rc;
>      int stubdomid = 0;
> +    struct dirent *de;
> +    DIR *dir;
> +    int assignable = 0;
>  
>      rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
>      if ( rc ) {
> @@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
>          goto out;
>      }
>  
> +    dir = opendir(SYSFS_PCIBACK_DRIVER);
> +    if ( NULL == dir ) {
> +        if ( errno == ENOENT ) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
> +        }else{
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
> +        }
> +        rc = ERROR_FAIL;
> +        goto out_closedir;
> +    }
> +
> +    while( (de = readdir(dir)) ) {
> +        unsigned dom, bus, dev, func;
> +        if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
> +            continue;
> +        if ( dom == pcidev->domain && bus == pcidev->bus &&
> +              dev == pcidev->dev && func == pcidev->func ) {
> +            assignable = 1;
> +            break;
> +        }
> +    }
> +
> +    if ( !assignable ) {
> +        rc = ERROR_FAIL;
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
> +        goto out_closedir;
> +    }
> +
> +
>      libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
>  
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
> @@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
>          /* stubdomain is always running by now, even at create time */
>          rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
>          if ( rc )
> -            goto out;
> +            goto out_closedir;
>      }
>  
>      orig_vdev = pcidev->vdevfn & ~7U;
> @@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
>          if ( !(pcidev->vdevfn >> 3) ) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
>              rc = ERROR_INVAL;
> -            goto out;
> +            goto out_closedir;
>          }
>          if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
>              rc = ERROR_FAIL;
> -            goto out;
> +            goto out_closedir;
>          }
>          pcidev->vfunc_mask &= pfunc_mask;
>          /* so now vfunc_mask == pfunc_mask */
> @@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
>          }
>      }
>  
> +out_closedir:
> +    closedir(dir);
>  out:
>      return rc;
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 17 14:06:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:06:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9gJ-0005ZT-3y; Tue, 17 Jan 2012 14:06:35 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rn9gH-0005Y0-0o
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:06:33 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326809185!9331947!1
X-Originating-IP: [64.78.148.212]
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 19616 invoked from network); 17 Jan 2012 14:06:26 -0000
Received: from host212.adamapps.net (HELO host212.adamapps.net) (64.78.148.212)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 14:06:26 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host212.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HE6KBH001291;
	Tue, 17 Jan 2012 09:06:20 -0500
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 17 Jan 2012 09:05:57 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
In-Reply-To: <1326793645.14689.75.camel@zakaz.uk.xensource.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding to the domain
Thread-Index: AczU/ZoGPs4TQs+hSiSiIrD6+L/8FQAIv78w
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
From: <djmagee@mageenet.net>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

That was my first thought, but this was also the first thing in libxl I touched and wasn't sure what would happen if I ended up nesting GC_INITs.  If it's safe to do then I can call libxl_device_pci_list_assignable, otherwise I'd have to pull the meat out and put it in another function.  What's the best way to do it?

Doug

-----Original Message-----
From: Ian Campbell [mailto:Ian.Campbell@citrix.com] 
Sent: Tuesday, January 17, 2012 4:47 AM
To: djmagee@mageenet.net
Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is assignable before adding to the domain

On Mon, 2012-01-16 at 22:36 +0000, Doug Magee wrote:
> Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.
> 
> Signed-off-by: Doug Magee <djmagee@mageenet.net>

Thanks Doug. Would this be better done by adding a call to
libxl_device_pci_list_assignable and looking for the device in it? In
fact from the looks of things this could replace the existing call to
get_all_assigned_devices from .._pci_add since
libxl_device_pci_list_assignable already omits devices which are
assigned to another domain.

Ian.

> 
> diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_pci.c	Mon Jan 16 17:31:25 2012 -0500
> @@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
>      libxl_device_pci *assigned;
>      int num_assigned, i, rc;
>      int stubdomid = 0;
> +    struct dirent *de;
> +    DIR *dir;
> +    int assignable = 0;
>  
>      rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
>      if ( rc ) {
> @@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
>          goto out;
>      }
>  
> +    dir = opendir(SYSFS_PCIBACK_DRIVER);
> +    if ( NULL == dir ) {
> +        if ( errno == ENOENT ) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
> +        }else{
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
> +        }
> +        rc = ERROR_FAIL;
> +        goto out_closedir;
> +    }
> +
> +    while( (de = readdir(dir)) ) {
> +        unsigned dom, bus, dev, func;
> +        if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
> +            continue;
> +        if ( dom == pcidev->domain && bus == pcidev->bus &&
> +              dev == pcidev->dev && func == pcidev->func ) {
> +            assignable = 1;
> +            break;
> +        }
> +    }
> +
> +    if ( !assignable ) {
> +        rc = ERROR_FAIL;
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
> +        goto out_closedir;
> +    }
> +
> +
>      libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
>  
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
> @@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
>          /* stubdomain is always running by now, even at create time */
>          rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
>          if ( rc )
> -            goto out;
> +            goto out_closedir;
>      }
>  
>      orig_vdev = pcidev->vdevfn & ~7U;
> @@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
>          if ( !(pcidev->vdevfn >> 3) ) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
>              rc = ERROR_INVAL;
> -            goto out;
> +            goto out_closedir;
>          }
>          if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
>              rc = ERROR_FAIL;
> -            goto out;
> +            goto out_closedir;
>          }
>          pcidev->vfunc_mask &= pfunc_mask;
>          /* so now vfunc_mask == pfunc_mask */
> @@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
>          }
>      }
>  
> +out_closedir:
> +    closedir(dir);
>  out:
>      return rc;
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 17 14:10:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14: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 1Rn9k3-00067O-UV; Tue, 17 Jan 2012 14:10:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rn9k2-00066k-K9
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:10:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326809417!8200607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2146 invoked from network); 17 Jan 2012 14:10:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:10:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10085419"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:10: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, 17 Jan 2012 14:10:17 +0000
Date: Tue, 17 Jan 2012 14:11:00 +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: <1326734083.14689.39.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201171401390.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
	<1326729772.14689.10.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201161615340.3150@kaball-desktop>
	<1326734083.14689.39.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 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 16 Jan 2012, Ian Campbell wrote:
> > > > Considering that stubdoms are not yet at feature parity I don't think we
> > > > should make this change for 4.2.
> > > > At the very least we should expand the set of conditions on which we base
> > > > the decision on: certainly the presence of an audio device, maybe pci
> > > > passthrough and the type of block backend (considering that some of them
> > > > go through qemu now) in case they aren't working properly.
> > > 
> > > Tweaking the precise conditions is reasonable and indeed the main thrust
> > > of the series is to allow to make this sort of determination and to
> > > change our minds about it.
> > 
> > The danger of this approach is that stubdoms are not really transparent
> > from the admin point of view.
> > From the basic difference when you "xl list", to memory usage, a stubdom
> > based setup is quite different from a non-stubdom based setup.
> > If I were an admin I would really want to know when I am running one or
> > the other.
> 
> > Making the change under their feet is bad enough but making a difference
> > choice depending on a various set of variables is certainly not going to
> > be popular.
> 
> Our recommendation as upstream is that stub domains are the most
> scalable and secure configuration. I think our defaults should reflect
> that.
> 
> Users who care specifically about stubdom or not can continue to force
> the choice (using device_model_stubdomain_override=1|0 in their config).

While the benefits of stubdoms in terms of security are a no brainer,
the benefits in terms of scalability are certainly less clear: are we
actually sure that using stubdoms is more scalable than a 64 bit dom0
with multiple vcpus?
I am asking because qemu instances running on Linux would share text and
use only the ram they actually need (nowadays most VMs have PV drivers
anyway) while stubdoms would unconditionally take 32MB of ram.
I don't think anybody actually run any real world benchmarks to
demonstrate any scalability benefits. Before saying that they are our
recommended solution and before switching them to default maybe we ought
to run at least one?
Otherwise if these tests have been run, I would like a link to some
nice figures :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:10:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14: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 1Rn9k3-00067O-UV; Tue, 17 Jan 2012 14:10:27 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rn9k2-00066k-K9
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:10:26 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326809417!8200607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2146 invoked from network); 17 Jan 2012 14:10:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:10:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10085419"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:10: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, 17 Jan 2012 14:10:17 +0000
Date: Tue, 17 Jan 2012 14:11:00 +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: <1326734083.14689.39.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201171401390.3150@kaball-desktop>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<953a1ce643856edcf9fb.1326716130@cosworth.uk.xensource.com>
	<alpine.DEB.2.00.1201161504390.3150@kaball-desktop>
	<1326729772.14689.10.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201161615340.3150@kaball-desktop>
	<1326734083.14689.39.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 32 of 32 RFC] libxl: Default to stub device
 model whenever possible
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 16 Jan 2012, Ian Campbell wrote:
> > > > Considering that stubdoms are not yet at feature parity I don't think we
> > > > should make this change for 4.2.
> > > > At the very least we should expand the set of conditions on which we base
> > > > the decision on: certainly the presence of an audio device, maybe pci
> > > > passthrough and the type of block backend (considering that some of them
> > > > go through qemu now) in case they aren't working properly.
> > > 
> > > Tweaking the precise conditions is reasonable and indeed the main thrust
> > > of the series is to allow to make this sort of determination and to
> > > change our minds about it.
> > 
> > The danger of this approach is that stubdoms are not really transparent
> > from the admin point of view.
> > From the basic difference when you "xl list", to memory usage, a stubdom
> > based setup is quite different from a non-stubdom based setup.
> > If I were an admin I would really want to know when I am running one or
> > the other.
> 
> > Making the change under their feet is bad enough but making a difference
> > choice depending on a various set of variables is certainly not going to
> > be popular.
> 
> Our recommendation as upstream is that stub domains are the most
> scalable and secure configuration. I think our defaults should reflect
> that.
> 
> Users who care specifically about stubdom or not can continue to force
> the choice (using device_model_stubdomain_override=1|0 in their config).

While the benefits of stubdoms in terms of security are a no brainer,
the benefits in terms of scalability are certainly less clear: are we
actually sure that using stubdoms is more scalable than a 64 bit dom0
with multiple vcpus?
I am asking because qemu instances running on Linux would share text and
use only the ram they actually need (nowadays most VMs have PV drivers
anyway) while stubdoms would unconditionally take 32MB of ram.
I don't think anybody actually run any real world benchmarks to
demonstrate any scalability benefits. Before saying that they are our
recommended solution and before switching them to default maybe we ought
to run at least one?
Otherwise if these tests have been run, I would like a link to some
nice figures :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:16:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9pp-0006TL-Ov; Tue, 17 Jan 2012 14:16: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 1Rn9pn-0006TD-TU
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:16:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326809737!50440233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11775 invoked from network); 17 Jan 2012 14:15:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10085570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:16: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, 17 Jan 2012 14:16:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "djmagee@mageenet.net" <djmagee@mageenet.net>
Date: Tue, 17 Jan 2012 14:16:22 +0000
In-Reply-To: <EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326809782.14689.114.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
 assignable before adding 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

Please don't top post.

On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> That was my first thought, but this was also the first thing in libxl
> I touched and wasn't sure what would happen if I ended up nesting
> GC_INITs.  If it's safe to do then I can call
> libxl_device_pci_list_assignable, otherwise I'd have to pull the meat
> out and put it in another function.  What's the best way to do it?

You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get a ctx
from a gc which you use to call an externally visible function from
within libxl -- it'll do the right thing (TM).

Ian.

> 
> Doug
> 
> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com] 
> Sent: Tuesday, January 17, 2012 4:47 AM
> To: djmagee@mageenet.net
> Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is assignable before adding to the domain
> 
> On Mon, 2012-01-16 at 22:36 +0000, Doug Magee wrote:
> > Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.
> > 
> > Signed-off-by: Doug Magee <djmagee@mageenet.net>
> 
> Thanks Doug. Would this be better done by adding a call to
> libxl_device_pci_list_assignable and looking for the device in it? In
> fact from the looks of things this could replace the existing call to
> get_all_assigned_devices from .._pci_add since
> libxl_device_pci_list_assignable already omits devices which are
> assigned to another domain.
> 
> Ian.
> 
> > 
> > diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
> > --- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
> > +++ b/tools/libxl/libxl_pci.c	Mon Jan 16 17:31:25 2012 -0500
> > @@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
> >      libxl_device_pci *assigned;
> >      int num_assigned, i, rc;
> >      int stubdomid = 0;
> > +    struct dirent *de;
> > +    DIR *dir;
> > +    int assignable = 0;
> >  
> >      rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
> >      if ( rc ) {
> > @@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
> >          goto out;
> >      }
> >  
> > +    dir = opendir(SYSFS_PCIBACK_DRIVER);
> > +    if ( NULL == dir ) {
> > +        if ( errno == ENOENT ) {
> > +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
> > +        }else{
> > +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
> > +        }
> > +        rc = ERROR_FAIL;
> > +        goto out_closedir;
> > +    }
> > +
> > +    while( (de = readdir(dir)) ) {
> > +        unsigned dom, bus, dev, func;
> > +        if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
> > +            continue;
> > +        if ( dom == pcidev->domain && bus == pcidev->bus &&
> > +              dev == pcidev->dev && func == pcidev->func ) {
> > +            assignable = 1;
> > +            break;
> > +        }
> > +    }
> > +
> > +    if ( !assignable ) {
> > +        rc = ERROR_FAIL;
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
> > +        goto out_closedir;
> > +    }
> > +
> > +
> >      libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
> >  
> >      stubdomid = libxl_get_stubdom_id(ctx, domid);
> > @@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
> >          /* stubdomain is always running by now, even at create time */
> >          rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
> >          if ( rc )
> > -            goto out;
> > +            goto out_closedir;
> >      }
> >  
> >      orig_vdev = pcidev->vdevfn & ~7U;
> > @@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
> >          if ( !(pcidev->vdevfn >> 3) ) {
> >              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
> >              rc = ERROR_INVAL;
> > -            goto out;
> > +            goto out_closedir;
> >          }
> >          if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
> >              rc = ERROR_FAIL;
> > -            goto out;
> > +            goto out_closedir;
> >          }
> >          pcidev->vfunc_mask &= pfunc_mask;
> >          /* so now vfunc_mask == pfunc_mask */
> > @@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
> >          }
> >      }
> >  
> > +out_closedir:
> > +    closedir(dir);
> >  out:
> >      return rc;
> >  }
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/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 Jan 17 14:16:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9pp-0006TL-Ov; Tue, 17 Jan 2012 14:16: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 1Rn9pn-0006TD-TU
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:16:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326809737!50440233!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11775 invoked from network); 17 Jan 2012 14:15:37 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:15:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10085570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:16: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, 17 Jan 2012 14:16:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "djmagee@mageenet.net" <djmagee@mageenet.net>
Date: Tue, 17 Jan 2012 14:16:22 +0000
In-Reply-To: <EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326809782.14689.114.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
 assignable before adding 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

Please don't top post.

On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> That was my first thought, but this was also the first thing in libxl
> I touched and wasn't sure what would happen if I ended up nesting
> GC_INITs.  If it's safe to do then I can call
> libxl_device_pci_list_assignable, otherwise I'd have to pull the meat
> out and put it in another function.  What's the best way to do it?

You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get a ctx
from a gc which you use to call an externally visible function from
within libxl -- it'll do the right thing (TM).

Ian.

> 
> Doug
> 
> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com] 
> Sent: Tuesday, January 17, 2012 4:47 AM
> To: djmagee@mageenet.net
> Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is assignable before adding to the domain
> 
> On Mon, 2012-01-16 at 22:36 +0000, Doug Magee wrote:
> > Previously, on ..._pci_add, libxl only checks that a device is not assigned to another domain. This quick patch checks that the device is also owned by pciback, otherwise the call fails.
> > 
> > Signed-off-by: Doug Magee <djmagee@mageenet.net>
> 
> Thanks Doug. Would this be better done by adding a call to
> libxl_device_pci_list_assignable and looking for the device in it? In
> fact from the looks of things this could replace the existing call to
> get_all_assigned_devices from .._pci_add since
> libxl_device_pci_list_assignable already omits devices which are
> assigned to another domain.
> 
> Ian.
> 
> > 
> > diff -r 5b2676ac1321 -r 301cc006677f tools/libxl/libxl_pci.c
> > --- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
> > +++ b/tools/libxl/libxl_pci.c	Mon Jan 16 17:31:25 2012 -0500
> > @@ -796,6 +796,9 @@ int libxl__device_pci_add(libxl__gc *gc,
> >      libxl_device_pci *assigned;
> >      int num_assigned, i, rc;
> >      int stubdomid = 0;
> > +    struct dirent *de;
> > +    DIR *dir;
> > +    int assignable = 0;
> >  
> >      rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
> >      if ( rc ) {
> > @@ -809,6 +812,35 @@ int libxl__device_pci_add(libxl__gc *gc,
> >          goto out;
> >      }
> >  
> > +    dir = opendir(SYSFS_PCIBACK_DRIVER);
> > +    if ( NULL == dir ) {
> > +        if ( errno == ENOENT ) {
> > +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Looks like pciback driver not loaded");
> > +        }else{
> > +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't open %s", SYSFS_PCIBACK_DRIVER);
> > +        }
> > +        rc = ERROR_FAIL;
> > +        goto out_closedir;
> > +    }
> > +
> > +    while( (de = readdir(dir)) ) {
> > +        unsigned dom, bus, dev, func;
> > +        if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
> > +            continue;
> > +        if ( dom == pcidev->domain && bus == pcidev->bus &&
> > +              dev == pcidev->dev && func == pcidev->func ) {
> > +            assignable = 1;
> > +            break;
> > +        }
> > +    }
> > +
> > +    if ( !assignable ) {
> > +        rc = ERROR_FAIL;
> > +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not owned by pciback");
> > +        goto out_closedir;
> > +    }
> > +
> > +
> >      libxl__device_pci_reset(gc, pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
> >  
> >      stubdomid = libxl_get_stubdom_id(ctx, domid);
> > @@ -817,7 +849,7 @@ int libxl__device_pci_add(libxl__gc *gc,
> >          /* stubdomain is always running by now, even at create time */
> >          rc = do_pci_add(gc, stubdomid, &pcidev_s, 0);
> >          if ( rc )
> > -            goto out;
> > +            goto out_closedir;
> >      }
> >  
> >      orig_vdev = pcidev->vdevfn & ~7U;
> > @@ -826,11 +858,11 @@ int libxl__device_pci_add(libxl__gc *gc,
> >          if ( !(pcidev->vdevfn >> 3) ) {
> >              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Must specify a v-slot for multi-function devices");
> >              rc = ERROR_INVAL;
> > -            goto out;
> > +            goto out_closedir;
> >          }
> >          if ( pci_multifunction_check(gc, pcidev, &pfunc_mask) ) {
> >              rc = ERROR_FAIL;
> > -            goto out;
> > +            goto out_closedir;
> >          }
> >          pcidev->vfunc_mask &= pfunc_mask;
> >          /* so now vfunc_mask == pfunc_mask */
> > @@ -855,6 +887,8 @@ int libxl__device_pci_add(libxl__gc *gc,
> >          }
> >      }
> >  
> > +out_closedir:
> > +    closedir(dir);
> >  out:
> >      return rc;
> >  }
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/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 Jan 17 14:25:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9yO-0006wV-4I; Tue, 17 Jan 2012 14:25:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rn9yM-0006wN-FF
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:25:14 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326810304!1574292!1
X-Originating-IP: [64.78.148.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27192 invoked from network); 17 Jan 2012 14:25:06 -0000
Received: from host212.adamapps.net (HELO host212.adamapps.net) (64.78.148.212)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 14:25:06 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host212.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HEP0BB005197;
	Tue, 17 Jan 2012 09:25:00 -0500
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 17 Jan 2012 09:24:39 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
In-Reply-To: <1326809782.14689.114.camel@zakaz.uk.xensource.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding to the domain
Thread-Index: AczVIprdeZvFQ2BoQ2G3BbPP/aOQfgAANDzA
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
	<1326809782.14689.114.camel@zakaz.uk.xensource.com>
From: <djmagee@mageenet.net>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, January 17, 2012 9:16 AM
> To: djmagee@mageenet.net
> Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> Subject: RE: [Xen-devel] [PATCH] libxl_pci: check that host device is
> assignable before adding to the domain
> 
> Please don't top post.
> 
> On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> > That was my first thought, but this was also the first thing in libxl
> > I touched and wasn't sure what would happen if I ended up nesting
> > GC_INITs.  If it's safe to do then I can call
> > libxl_device_pci_list_assignable, otherwise I'd have to pull the meat
> > out and put it in another function.  What's the best way to do it?
> 
> You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get a ctx
> from a gc which you use to call an externally visible function from
> within libxl -- it'll do the right thing (TM).

Cool, I'll send an updated patch along today.

Doug

> 
> Ian.
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:25:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:25:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rn9yO-0006wV-4I; Tue, 17 Jan 2012 14:25:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rn9yM-0006wN-FF
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:25:14 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326810304!1574292!1
X-Originating-IP: [64.78.148.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27192 invoked from network); 17 Jan 2012 14:25:06 -0000
Received: from host212.adamapps.net (HELO host212.adamapps.net) (64.78.148.212)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 14:25:06 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host212.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HEP0BB005197;
	Tue, 17 Jan 2012 09:25:00 -0500
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 17 Jan 2012 09:24:39 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
In-Reply-To: <1326809782.14689.114.camel@zakaz.uk.xensource.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding to the domain
Thread-Index: AczVIprdeZvFQ2BoQ2G3BbPP/aOQfgAANDzA
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
	<1326809782.14689.114.camel@zakaz.uk.xensource.com>
From: <djmagee@mageenet.net>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, January 17, 2012 9:16 AM
> To: djmagee@mageenet.net
> Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> Subject: RE: [Xen-devel] [PATCH] libxl_pci: check that host device is
> assignable before adding to the domain
> 
> Please don't top post.
> 
> On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> > That was my first thought, but this was also the first thing in libxl
> > I touched and wasn't sure what would happen if I ended up nesting
> > GC_INITs.  If it's safe to do then I can call
> > libxl_device_pci_list_assignable, otherwise I'd have to pull the meat
> > out and put it in another function.  What's the best way to do it?
> 
> You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get a ctx
> from a gc which you use to call an externally visible function from
> within libxl -- it'll do the right thing (TM).

Cool, I'll send an updated patch along today.

Doug

> 
> Ian.
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:34:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14: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 1RnA6y-0007I8-UQ; Tue, 17 Jan 2012 14:34:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RnA6x-0007Hn-El
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:34:07 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326810800!60581705!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15621 invoked from network); 17 Jan 2012 14:33:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:33:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10086493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:34:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 14:34:01 +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 1RnA6q-00053u-Ut;
	Tue, 17 Jan 2012 14:34:00 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnA6j-00036w-4A;
	Tue, 17 Jan 2012 14:33:53 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 14:33:52 +0000
Message-ID: <1326810832-11927-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, Jean Guyader <jean.guyader@eu.citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH] xl: Add missing trigger for the xl trigger cmd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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


Add s3resume trigger in the usage of the xl trigger cmd.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/libxl/xl_cmdtable.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-xl-Add-missing-trigger-for-the-xl-trigger-cmd.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-xl-Add-missing-trigger-for-the-xl-trigger-cmd.patch"

diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 3ad2b1b..3f7008b 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -240,7 +240,7 @@ struct cmd_spec cmd_table[] = {
     { "trigger",
       &main_trigger, 0,
       "Send a trigger to a domain",
-      "<Domain> <nmi|reset|init|power|sleep> [<VCPU>]",
+      "<Domain> <nmi|reset|init|power|sleep|s3resume> [<VCPU>]",
     },
     { "sysrq",
       &main_sysrq, 0,

--------------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 Tue Jan 17 14:34:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14: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 1RnA6y-0007I8-UQ; Tue, 17 Jan 2012 14:34:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RnA6x-0007Hn-El
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:34:07 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326810800!60581705!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15621 invoked from network); 17 Jan 2012 14:33:20 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:33:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10086493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:34:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 14:34:01 +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 1RnA6q-00053u-Ut;
	Tue, 17 Jan 2012 14:34:00 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnA6j-00036w-4A;
	Tue, 17 Jan 2012 14:33:53 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 14:33:52 +0000
Message-ID: <1326810832-11927-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, Jean Guyader <jean.guyader@eu.citrix.com>,
	Jean Guyader <jean.guyader@citrix.com>
Subject: [Xen-devel] [PATCH] xl: Add missing trigger for the xl trigger cmd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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


Add s3resume trigger in the usage of the xl trigger cmd.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 tools/libxl/xl_cmdtable.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-xl-Add-missing-trigger-for-the-xl-trigger-cmd.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-xl-Add-missing-trigger-for-the-xl-trigger-cmd.patch"

diff --git a/tools/libxl/xl_cmdtable.c b/tools/libxl/xl_cmdtable.c
index 3ad2b1b..3f7008b 100644
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -240,7 +240,7 @@ struct cmd_spec cmd_table[] = {
     { "trigger",
       &main_trigger, 0,
       "Send a trigger to a domain",
-      "<Domain> <nmi|reset|init|power|sleep> [<VCPU>]",
+      "<Domain> <nmi|reset|init|power|sleep|s3resume> [<VCPU>]",
     },
     { "sysrq",
       &main_sysrq, 0,

--------------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 Tue Jan 17 14:43:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14: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 1RnAFd-0007as-VI; Tue, 17 Jan 2012 14:43: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 1RnAFc-0007af-51
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:43:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326811377!9513551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31396 invoked from network); 17 Jan 2012 14:42:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:42:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10086971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:42: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, 17 Jan 2012 14:42: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 1RnAFV-000578-0I;
	Tue, 17 Jan 2012 14:42:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnAFU-0001nv-QX;
	Tue, 17 Jan 2012 14:42:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10785-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 14:42:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10785: 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 10785 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10785/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xl-multivcpu 11 guest-localmigrate        fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl           11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-credit2   11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10776 REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10776 REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10776
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10776

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install        fail in 10776 like 10645

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  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

version targeted for testing:
 xen                  2913ccc6d70f
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                           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                                 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 815 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 Jan 17 14:43:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14: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 1RnAFd-0007as-VI; Tue, 17 Jan 2012 14:43: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 1RnAFc-0007af-51
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:43:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326811377!9513551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31396 invoked from network); 17 Jan 2012 14:42:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:42:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10086971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:42: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, 17 Jan 2012 14:42: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 1RnAFV-000578-0I;
	Tue, 17 Jan 2012 14:42:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnAFU-0001nv-QX;
	Tue, 17 Jan 2012 14:42:56 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10785-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 14:42:56 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10785: 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 10785 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10785/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xl-multivcpu 11 guest-localmigrate        fail REGR. vs. 10649
 test-i386-i386-xl            11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl           11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xl-credit2   11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win      8 guest-saverestore fail in 10776 REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1 8 guest-saverestore fail in 10776 REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10776
 test-amd64-i386-xl-win-vcpus1  7 windows-install            fail pass in 10776

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install        fail in 10776 like 10645

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  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

version targeted for testing:
 xen                  2913ccc6d70f
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                           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                                 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 815 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 Jan 17 14:51:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAMy-0007yK-IN; Tue, 17 Jan 2012 14:50:40 +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 1RnAMw-0007xf-VY
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:50:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326811832!11423988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32424 invoked from network); 17 Jan 2012 14:50:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:50:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10087216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:50: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; Tue, 17 Jan 2012 14:50:32 +0000
Date: Tue, 17 Jan 2012 14:51:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@gmail.com>
In-Reply-To: <CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
	<CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-620858218-1326811881=:3150"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (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

--8323329-620858218-1326811881=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 16 Jan 2012, Jean Guyader wrote:
> On 12 January 2012 14:34, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 12 Jan 2012, Jean Guyader wrote:
> >> On 12/01 12:41, 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>
> >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> >> Date:   Wed Nov 23 07:53:30 2011 +0000
> >>
> >>     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.
> >>
> >>     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.
> >>
> >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> >> index dbe8804..7ee3c61 100644
> >> --- a/hw/pass-through.c
> >> +++ b/hw/pass-through.c
> >> @@ -238,6 +238,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).
> >> @@ -444,6 +452,16 @@ 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,
> >>      },
> >> +    /* Intel IGFX OpRegion reg */
> >> +    {
> >> +        .offset     = PCI_INTEL_OPREGION,
> >> +        .size       = 4,
> >> +        .init_val   = 0,
> >> +        .no_wb      = 1,
> >> +        .u.dw.read   = pt_intel_opregion_read,
> >> +        .u.dw.write  = pt_intel_opregion_write,
> >> +        .u.dw.restore  = NULL,
> >> +    },
> >>      {
> >>          .size = 0,
> >>      },
> >> @@ -737,7 +755,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 */
> >> @@ -3006,6 +3024,19 @@ 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)
> >> +{
> >> +    /*
> >> +    ** By default we will trap up to 0x40 in the cfg space.
> >> +    ** If an intel device is pass through we need to trap 0xfc,
> >> +    ** therefore the size should be 0xff.
> >> +    */
> >> +    if (igd_passthru)
> >> +        return 0xFF;
> >> +    return grp_reg->grp_size;
> >> +}
> >
> > Apart from the trivial code style error in the comment above, is this
> > going to have the unintended side effect of initializing as 0 all the
> > emulated registers between 0x40 and 0xff, that previously were probably
> > passed through?
> >
> 
> Based on how pt_find_reg_grp is implemented that doesn't make any difference.
 
actually there is a small change in behaviour: before your patch
pt_find_reg_grp would return NULL for any cfg register between 0x40 and
0xff. Now if igd_passthru is set pt_find_reg_grp would return the
reg_grp_entry corresponding to "Header Type0 reg group" and then
pt_find_reg would return NULL.
This case seems to be handled correctly and bring to the same results
in both pt_pci_write_config and pt_pci_read_config.

In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
group" only it if really is part of this group otherwise it should be in
its own separate group.
--8323329-620858218-1326811881=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-620858218-1326811881=:3150--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:51:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAMy-0007yK-IN; Tue, 17 Jan 2012 14:50:40 +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 1RnAMw-0007xf-VY
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:50:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326811832!11423988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32424 invoked from network); 17 Jan 2012 14:50:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:50:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10087216"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:50: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; Tue, 17 Jan 2012 14:50:32 +0000
Date: Tue, 17 Jan 2012 14:51:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jean Guyader <jean.guyader@gmail.com>
In-Reply-To: <CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
	<CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-620858218-1326811881=:3150"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (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

--8323329-620858218-1326811881=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 16 Jan 2012, Jean Guyader wrote:
> On 12 January 2012 14:34, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 12 Jan 2012, Jean Guyader wrote:
> >> On 12/01 12:41, 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>
> >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> >> Date:   Wed Nov 23 07:53:30 2011 +0000
> >>
> >>     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.
> >>
> >>     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.
> >>
> >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> >> index dbe8804..7ee3c61 100644
> >> --- a/hw/pass-through.c
> >> +++ b/hw/pass-through.c
> >> @@ -238,6 +238,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).
> >> @@ -444,6 +452,16 @@ 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,
> >>      },
> >> +    /* Intel IGFX OpRegion reg */
> >> +    {
> >> +        .offset     = PCI_INTEL_OPREGION,
> >> +        .size       = 4,
> >> +        .init_val   = 0,
> >> +        .no_wb      = 1,
> >> +        .u.dw.read   = pt_intel_opregion_read,
> >> +        .u.dw.write  = pt_intel_opregion_write,
> >> +        .u.dw.restore  = NULL,
> >> +    },
> >>      {
> >>          .size = 0,
> >>      },
> >> @@ -737,7 +755,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 */
> >> @@ -3006,6 +3024,19 @@ 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)
> >> +{
> >> +    /*
> >> +    ** By default we will trap up to 0x40 in the cfg space.
> >> +    ** If an intel device is pass through we need to trap 0xfc,
> >> +    ** therefore the size should be 0xff.
> >> +    */
> >> +    if (igd_passthru)
> >> +        return 0xFF;
> >> +    return grp_reg->grp_size;
> >> +}
> >
> > Apart from the trivial code style error in the comment above, is this
> > going to have the unintended side effect of initializing as 0 all the
> > emulated registers between 0x40 and 0xff, that previously were probably
> > passed through?
> >
> 
> Based on how pt_find_reg_grp is implemented that doesn't make any difference.
 
actually there is a small change in behaviour: before your patch
pt_find_reg_grp would return NULL for any cfg register between 0x40 and
0xff. Now if igd_passthru is set pt_find_reg_grp would return the
reg_grp_entry corresponding to "Header Type0 reg group" and then
pt_find_reg would return NULL.
This case seems to be handled correctly and bring to the same results
in both pt_pci_write_config and pt_pci_read_config.

In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
group" only it if really is part of this group otherwise it should be in
its own separate group.
--8323329-620858218-1326811881=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-620858218-1326811881=:3150--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:59:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAVS-0008Td-IT; Tue, 17 Jan 2012 14:59:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RnAVR-0008TS-8n
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:59:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326812359!1580132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4313 invoked from network); 17 Jan 2012 14:59:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:59:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10088001"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:59:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 14:59:19 +0000
Date: Tue, 17 Jan 2012 14:59:52 +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: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1201171459451.3150@kaball-desktop>
References: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"djmagee@mageenet.net" <djmagee@mageenet.net>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] [passthrough] Change init for
 pt_pci_host return value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 17 Jan 2012, Jean Guyader wrote:
> With an init of -1 all the return value smaller than a double word
> will be prefixed with "f"s.

ack


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 14:59:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 14:59:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAVS-0008Td-IT; Tue, 17 Jan 2012 14:59:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RnAVR-0008TS-8n
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:59:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326812359!1580132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4313 invoked from network); 17 Jan 2012 14:59:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 14:59:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10088001"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 14:59:19 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 14:59:19 +0000
Date: Tue, 17 Jan 2012 14:59:52 +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: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1201171459451.3150@kaball-desktop>
References: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"djmagee@mageenet.net" <djmagee@mageenet.net>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] [passthrough] Change init for
 pt_pci_host return value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 17 Jan 2012, Jean Guyader wrote:
> With an init of -1 all the return value smaller than a double word
> will be prefixed with "f"s.

ack


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:16:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAlB-0000K9-3l; Tue, 17 Jan 2012 15:15:41 +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 1RnAl9-0000K4-6X
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:15:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326813332!11263165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21585 invoked from network); 17 Jan 2012 15:15:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 15:15:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10088789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 15:15: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; Tue, 17 Jan 2012 15:15:32 +0000
Date: Tue, 17 Jan 2012 15:16:05 +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: <1326808398-11229-2-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1201171507030.3150@kaball-desktop>
References: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
	<1326808398-11229-2-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"djmagee@mageenet.net" <djmagee@mageenet.net>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] intel gpu passthrough: Expose vendor
 specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 17 Jan 2012, Jean Guyader wrote:
> Some versions of the Windows Intel GPU driver expect the vendor
> PCI capability to be there on the host bridge config space when
> passing through a Intel GPU.
> 
> From: Ross Philipson <Ross.Philipson@citrix.com>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> Acked-by: Ross Philipson <Ross.Philipson@citrix.com>
> 
> ---
>  hw/pt-graphics.c |   49 ++++++++++++++++++++++++++++++++++++++++++++-----
>  1 files changed, 44 insertions(+), 5 deletions(-)
> 
> 
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..25e28ff 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -60,6 +60,42 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
>      }
>  }
>  
> +#define PCI_INTEL_VENDOR_CAP            0x34
> +#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
> +static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
> +                                        uint32_t val)
> +{
> +    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    uint32_t vendor_cap = 0;
> +    uint32_t cap_type = 0;
> +    uint32_t cap_size = 0;
> +
> +    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
> +    if (!vendor_cap)
> +        return -1;
> +
> +    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
> +    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
> +        return -1;
> +
> +    if (config_addr == PCI_INTEL_VENDOR_CAP)
> +        return vendor_cap;
> +
> +    /* Remove the next capability link */
> +    if (config_addr == vendor_cap + 1)
> +        return 0;
> +
> +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
> +    if (config_addr >= vendor_cap &&
> +            config_addr + len < vendor_cap + cap_size)
> +    {
> +        return pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +    }
> +
> +    /* -1, this function doesn't deal with this config space offset */
> +    return -1;
> +}

You are passing val to igd_pci_read_vendor_cap without actually using
it.
Also you are returning -1 from a function that returns uint32_t.

I would change the prototype of igd_pci_read_vendor_cap to:

static int igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
                                        uint32_t *val)

return only 0 or error and set *val to the correct value.



>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  {
>      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> @@ -82,14 +118,17 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>          case 0xa4:        /* SNB: graphics base of stolen memory */
>          case 0xa8:        /* SNB: base of GTT stolen memory */
>              val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> -            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> -                    config_addr, len, val);
> -#endif
>              break;
>          default:
> -            val = pci_default_read_config(pci_dev, config_addr, len);
> +            val = igd_pci_read_vendor_cap(pci_dev, config_addr, len, val);
> +            if (val == -1)
> +                val = pci_default_read_config(pci_dev, config_addr, len);
> +
>      }
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> +            config_addr, len, val);
> +#endif
>      return val;
>  }
>  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:16:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAlB-0000K9-3l; Tue, 17 Jan 2012 15:15:41 +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 1RnAl9-0000K4-6X
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:15:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326813332!11263165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21585 invoked from network); 17 Jan 2012 15:15:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 15:15:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10088789"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 15:15: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; Tue, 17 Jan 2012 15:15:32 +0000
Date: Tue, 17 Jan 2012 15:16:05 +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: <1326808398-11229-2-git-send-email-jean.guyader@eu.citrix.com>
Message-ID: <alpine.DEB.2.00.1201171507030.3150@kaball-desktop>
References: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
	<1326808398-11229-2-git-send-email-jean.guyader@eu.citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"djmagee@mageenet.net" <djmagee@mageenet.net>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] intel gpu passthrough: Expose vendor
 specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 17 Jan 2012, Jean Guyader wrote:
> Some versions of the Windows Intel GPU driver expect the vendor
> PCI capability to be there on the host bridge config space when
> passing through a Intel GPU.
> 
> From: Ross Philipson <Ross.Philipson@citrix.com>
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> Acked-by: Ross Philipson <Ross.Philipson@citrix.com>
> 
> ---
>  hw/pt-graphics.c |   49 ++++++++++++++++++++++++++++++++++++++++++++-----
>  1 files changed, 44 insertions(+), 5 deletions(-)
> 
> 
> diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> index fec7390..25e28ff 100644
> --- a/hw/pt-graphics.c
> +++ b/hw/pt-graphics.c
> @@ -60,6 +60,42 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
>      }
>  }
>  
> +#define PCI_INTEL_VENDOR_CAP            0x34
> +#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
> +static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
> +                                        uint32_t val)
> +{
> +    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> +    uint32_t vendor_cap = 0;
> +    uint32_t cap_type = 0;
> +    uint32_t cap_size = 0;
> +
> +    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
> +    if (!vendor_cap)
> +        return -1;
> +
> +    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
> +    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
> +        return -1;
> +
> +    if (config_addr == PCI_INTEL_VENDOR_CAP)
> +        return vendor_cap;
> +
> +    /* Remove the next capability link */
> +    if (config_addr == vendor_cap + 1)
> +        return 0;
> +
> +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
> +    if (config_addr >= vendor_cap &&
> +            config_addr + len < vendor_cap + cap_size)
> +    {
> +        return pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> +    }
> +
> +    /* -1, this function doesn't deal with this config space offset */
> +    return -1;
> +}

You are passing val to igd_pci_read_vendor_cap without actually using
it.
Also you are returning -1 from a function that returns uint32_t.

I would change the prototype of igd_pci_read_vendor_cap to:

static int igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
                                        uint32_t *val)

return only 0 or error and set *val to the correct value.



>  uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>  {
>      struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> @@ -82,14 +118,17 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
>          case 0xa4:        /* SNB: graphics base of stolen memory */
>          case 0xa8:        /* SNB: base of GTT stolen memory */
>              val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> -#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> -            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> -                    config_addr, len, val);
> -#endif
>              break;
>          default:
> -            val = pci_default_read_config(pci_dev, config_addr, len);
> +            val = igd_pci_read_vendor_cap(pci_dev, config_addr, len, val);
> +            if (val == -1)
> +                val = pci_default_read_config(pci_dev, config_addr, len);
> +
>      }
> +#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
> +    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
> +            config_addr, len, val);
> +#endif
>      return val;
>  }
>  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:27:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15: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 1RnAwE-0000hD-U3; Tue, 17 Jan 2012 15:27:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnAwD-0000gs-QR
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:27:06 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326814018!11206233!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6496 invoked from network); 17 Jan 2012 15:26:59 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 15:26:59 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HFQvsr032735
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 10:26:57 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 10:26:41 -0500
MIME-Version: 1.0
X-Mercurial-Node: 3becc16526930a5bc6a3e5f64a109529bc615ac2
Message-Id: <3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
In-Reply-To: <patchbomb.1326813905@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 10:25:06 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 15:26:41.0701 (UTC)
	FILETIME=[69C9C550:01CCD52C]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl_pci: rename is_assigned to
	is_pcidev_in_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

All this function does is check to see if a device is in an array of pcidevs passed by the caller.  The function name can be misleading if ever used to check against a list of devices other than those assigned to a domain.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r 5b2676ac1321 -r 3becc1652693 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Tue Jan 17 10:14:15 2012 -0500
@@ -461,7 +461,7 @@ static int get_all_assigned_devices(libx
     return 0;
 }
 
-static int is_assigned(libxl_device_pci *assigned, int num_assigned,
+static int is_pcidev_in_array(libxl_device_pci *assigned, int num_assigned,
                        int dom, int bus, int dev, int func)
 {
     int i;
@@ -510,7 +510,7 @@ libxl_device_pci *libxl_device_pci_list_
         if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
             continue;
 
-        if ( is_assigned(assigned, num_assigned, dom, bus, dev, func) )
+        if ( is_pcidev_in_array(assigned, num_assigned, dom, bus, dev, func) )
             continue;
 
         new = realloc(pcidevs, ((*num) + 1) * sizeof(*new));
@@ -802,7 +802,7 @@ int libxl__device_pci_add(libxl__gc *gc,
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
         goto out;
     }
-    if ( is_assigned(assigned, num_assigned, pcidev->domain,
+    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
                      pcidev->bus, pcidev->dev, pcidev->func) ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
         rc = ERROR_FAIL;
@@ -906,7 +906,7 @@ static int do_pci_remove(libxl__gc *gc, 
         return ERROR_FAIL;
 
     rc = ERROR_INVAL;
-    if ( !is_assigned(assigned, num, pcidev->domain,
+    if ( !is_pcidev_in_array(assigned, num, pcidev->domain,
                       pcidev->bus, pcidev->dev, pcidev->func) ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not attached to this domain");
         goto out_fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:27:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15: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 1RnAwE-0000hD-U3; Tue, 17 Jan 2012 15:27:06 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnAwD-0000gs-QR
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:27:06 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326814018!11206233!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6496 invoked from network); 17 Jan 2012 15:26:59 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 15:26:59 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HFQvsr032735
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 10:26:57 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 10:26:41 -0500
MIME-Version: 1.0
X-Mercurial-Node: 3becc16526930a5bc6a3e5f64a109529bc615ac2
Message-Id: <3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
In-Reply-To: <patchbomb.1326813905@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 10:25:06 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 15:26:41.0701 (UTC)
	FILETIME=[69C9C550:01CCD52C]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl_pci: rename is_assigned to
	is_pcidev_in_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

All this function does is check to see if a device is in an array of pcidevs passed by the caller.  The function name can be misleading if ever used to check against a list of devices other than those assigned to a domain.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r 5b2676ac1321 -r 3becc1652693 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Tue Jan 17 10:14:15 2012 -0500
@@ -461,7 +461,7 @@ static int get_all_assigned_devices(libx
     return 0;
 }
 
-static int is_assigned(libxl_device_pci *assigned, int num_assigned,
+static int is_pcidev_in_array(libxl_device_pci *assigned, int num_assigned,
                        int dom, int bus, int dev, int func)
 {
     int i;
@@ -510,7 +510,7 @@ libxl_device_pci *libxl_device_pci_list_
         if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
             continue;
 
-        if ( is_assigned(assigned, num_assigned, dom, bus, dev, func) )
+        if ( is_pcidev_in_array(assigned, num_assigned, dom, bus, dev, func) )
             continue;
 
         new = realloc(pcidevs, ((*num) + 1) * sizeof(*new));
@@ -802,7 +802,7 @@ int libxl__device_pci_add(libxl__gc *gc,
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
         goto out;
     }
-    if ( is_assigned(assigned, num_assigned, pcidev->domain,
+    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
                      pcidev->bus, pcidev->dev, pcidev->func) ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
         rc = ERROR_FAIL;
@@ -906,7 +906,7 @@ static int do_pci_remove(libxl__gc *gc, 
         return ERROR_FAIL;
 
     rc = ERROR_INVAL;
-    if ( !is_assigned(assigned, num, pcidev->domain,
+    if ( !is_pcidev_in_array(assigned, num, pcidev->domain,
                       pcidev->bus, pcidev->dev, pcidev->func) ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not attached to this domain");
         goto out_fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:27:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAwE-0000h6-I9; Tue, 17 Jan 2012 15:27:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnAwD-0000gr-3o
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:27:05 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326813952!61355558!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2568 invoked from network); 17 Jan 2012 15:25:53 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 15:25:53 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HFQv03032731
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 10:26:57 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 10:26:41 -0500
MIME-Version: 1.0
Message-Id: <patchbomb.1326813905@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 10:25:05 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 15:26:41.0233 (UTC)
	FILETIME=[69825C10:01CCD52C]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl_pci: verify device is assignable,
 rename misleading 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

This series contains one patch that changes the behavior of libxl__device_pci_add to verify the device is properly assignable.  There's also a patch that renames a function so it's not misleading.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:27:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:27:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAwE-0000h6-I9; Tue, 17 Jan 2012 15:27:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnAwD-0000gr-3o
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:27:05 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326813952!61355558!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2568 invoked from network); 17 Jan 2012 15:25:53 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 15:25:53 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HFQv03032731
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 10:26:57 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 10:26:41 -0500
MIME-Version: 1.0
Message-Id: <patchbomb.1326813905@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 10:25:05 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 15:26:41.0233 (UTC)
	FILETIME=[69825C10:01CCD52C]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl_pci: verify device is assignable,
 rename misleading 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

This series contains one patch that changes the behavior of libxl__device_pci_add to verify the device is properly assignable.  There's also a patch that renames a function so it's not misleading.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:27:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:27:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAwF-0000hK-92; Tue, 17 Jan 2012 15:27:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnAwE-0000gt-1W
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:27:06 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326814018!11413584!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6607 invoked from network); 17 Jan 2012 15:26:59 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 15:26:59 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HFQwMI032739
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 10:26:58 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 10:26:42 -0500
MIME-Version: 1.0
X-Mercurial-Node: be1313a6b4898c0197ab03a68e9fb81b62f1fe79
Message-Id: <be1313a6b4898c0197ab.1326813907@mnetdjm4.mageenet.host>
In-Reply-To: <patchbomb.1326813905@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 10:25:07 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 15:26:42.0185 (UTC)
	FILETIME=[6A139F90:01CCD52C]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is assignable
 before adding to a 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

Previously, libxl__device_pci_add only checks that the device is not assigned to another domain.  This patch updates this function to check against the list of assignable devices, which only includes devices owned by pciback and already excludes devices assigned to other domains.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r 3becc1652693 -r be1313a6b489 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Tue Jan 17 10:14:15 2012 -0500
+++ b/tools/libxl/libxl_pci.c	Tue Jan 17 10:19:24 2012 -0500
@@ -793,18 +793,15 @@ int libxl__device_pci_add(libxl__gc *gc,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     unsigned int orig_vdev, pfunc_mask;
-    libxl_device_pci *assigned;
-    int num_assigned, i, rc;
+    libxl_device_pci *assignable;
+    int num_assignable, i, rc;
     int stubdomid = 0;
 
-    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
-    if ( rc ) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
-        goto out;
-    }
-    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
+    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);
+
+    if ( !is_pcidev_in_array(assignable, num_assignable, pcidev->domain,
                      pcidev->bus, pcidev->dev, pcidev->func) ) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device is either assigned to another domain, or not owned by pciback");
         rc = ERROR_FAIL;
         goto out;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:27:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:27:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnAwF-0000hK-92; Tue, 17 Jan 2012 15:27:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnAwE-0000gt-1W
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:27:06 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326814018!11413584!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6607 invoked from network); 17 Jan 2012 15:26:59 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 15:26:59 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HFQwMI032739
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 10:26:58 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 10:26:42 -0500
MIME-Version: 1.0
X-Mercurial-Node: be1313a6b4898c0197ab03a68e9fb81b62f1fe79
Message-Id: <be1313a6b4898c0197ab.1326813907@mnetdjm4.mageenet.host>
In-Reply-To: <patchbomb.1326813905@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 10:25:07 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 15:26:42.0185 (UTC)
	FILETIME=[6A139F90:01CCD52C]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is assignable
 before adding to a 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

Previously, libxl__device_pci_add only checks that the device is not assigned to another domain.  This patch updates this function to check against the list of assignable devices, which only includes devices owned by pciback and already excludes devices assigned to other domains.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r 3becc1652693 -r be1313a6b489 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Tue Jan 17 10:14:15 2012 -0500
+++ b/tools/libxl/libxl_pci.c	Tue Jan 17 10:19:24 2012 -0500
@@ -793,18 +793,15 @@ int libxl__device_pci_add(libxl__gc *gc,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     unsigned int orig_vdev, pfunc_mask;
-    libxl_device_pci *assigned;
-    int num_assigned, i, rc;
+    libxl_device_pci *assignable;
+    int num_assignable, i, rc;
     int stubdomid = 0;
 
-    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
-    if ( rc ) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
-        goto out;
-    }
-    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
+    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);
+
+    if ( !is_pcidev_in_array(assignable, num_assignable, pcidev->domain,
                      pcidev->bus, pcidev->dev, pcidev->func) ) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device is either assigned to another domain, or not owned by pciback");
         rc = ERROR_FAIL;
         goto out;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:33:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:33:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnB2J-000198-7V; Tue, 17 Jan 2012 15:33:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RnB2H-00018w-12; Tue, 17 Jan 2012 15:33:21 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326814393!9494456!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.9 required=7.0 tests=HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15927 invoked from network); 17 Jan 2012 15:33:14 -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;
	17 Jan 2012 15:33:14 -0000
Received: by iahk25 with SMTP id k25so23707749iah.30
	for <multiple recipients>; Tue, 17 Jan 2012 07:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=mHHJDiAcHYcIOushdNso3mtHtjgxXl5oMxaOSnRSZrM=;
	b=wm6IXOtdDS68e1WjXnmTmHKWlDKSLpUEvJAEqpLZG9dYTgEbLjs5B/edbyWtoo0w1E
	F3c2VoEKBI0eU3guVRc8rnwt2DT8En32Bacmqs5XiIDRJtw842SFql9SzFAFDaMjrXqG
	jCcNXfGBuFA28giDoyYlH+mmK4xnB0uDPjllA=
MIME-Version: 1.0
Received: by 10.42.151.68 with SMTP id d4mr14492813icw.36.1326814392905; Tue,
	17 Jan 2012 07:33:12 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Tue, 17 Jan 2012 07:33:12 -0800 (PST)
Date: Tue, 17 Jan 2012 16:33:12 +0100
Message-ID: <CAFoWEVM2B3BA-UUUQ9-1EuR=OnuqPc1-QYOi5E=pmCpxHYGzFg@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [Xen-devel] test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2471276378708187152=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2471276378708187152==
Content-Type: multipart/alternative; boundary=90e6ba6e872e92719504b6bb0c95

--90e6ba6e872e92719504b6bb0c95
Content-Type: text/plain; charset=ISO-8859-1

Testing to see if my emails get into the lists....

--90e6ba6e872e92719504b6bb0c95
Content-Type: text/html; charset=ISO-8859-1

Testing to see if my emails get into the lists....

--90e6ba6e872e92719504b6bb0c95--


--===============2471276378708187152==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2471276378708187152==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:33:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:33:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnB2J-000198-7V; Tue, 17 Jan 2012 15:33:23 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RnB2H-00018w-12; Tue, 17 Jan 2012 15:33:21 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326814393!9494456!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.9 required=7.0 tests=HTML_MESSAGE,
	HTML_SHORT_LENGTH,ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15927 invoked from network); 17 Jan 2012 15:33:14 -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;
	17 Jan 2012 15:33:14 -0000
Received: by iahk25 with SMTP id k25so23707749iah.30
	for <multiple recipients>; Tue, 17 Jan 2012 07:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=mHHJDiAcHYcIOushdNso3mtHtjgxXl5oMxaOSnRSZrM=;
	b=wm6IXOtdDS68e1WjXnmTmHKWlDKSLpUEvJAEqpLZG9dYTgEbLjs5B/edbyWtoo0w1E
	F3c2VoEKBI0eU3guVRc8rnwt2DT8En32Bacmqs5XiIDRJtw842SFql9SzFAFDaMjrXqG
	jCcNXfGBuFA28giDoyYlH+mmK4xnB0uDPjllA=
MIME-Version: 1.0
Received: by 10.42.151.68 with SMTP id d4mr14492813icw.36.1326814392905; Tue,
	17 Jan 2012 07:33:12 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Tue, 17 Jan 2012 07:33:12 -0800 (PST)
Date: Tue, 17 Jan 2012 16:33:12 +0100
Message-ID: <CAFoWEVM2B3BA-UUUQ9-1EuR=OnuqPc1-QYOi5E=pmCpxHYGzFg@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [Xen-devel] test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2471276378708187152=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2471276378708187152==
Content-Type: multipart/alternative; boundary=90e6ba6e872e92719504b6bb0c95

--90e6ba6e872e92719504b6bb0c95
Content-Type: text/plain; charset=ISO-8859-1

Testing to see if my emails get into the lists....

--90e6ba6e872e92719504b6bb0c95
Content-Type: text/html; charset=ISO-8859-1

Testing to see if my emails get into the lists....

--90e6ba6e872e92719504b6bb0c95--


--===============2471276378708187152==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2471276378708187152==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:39:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnB7c-0001WO-Mn; Tue, 17 Jan 2012 15:38:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RnB7b-0001WF-36
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:38:51 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326814683!50454711!1
X-Originating-IP: [212.82.109.208]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23871 invoked from network); 17 Jan 2012 15:38:03 -0000
Received: from nm25-vm7.bullet.mail.ird.yahoo.com (HELO
	nm25-vm7.bullet.mail.ird.yahoo.com) (212.82.109.208)
	by server-6.tower-27.messagelabs.com with SMTP;
	17 Jan 2012 15:38:03 -0000
Received: from [77.238.189.56] by nm25.bullet.mail.ird.yahoo.com with NNFMP;
	17 Jan 2012 15:38:48 -0000
Received: from [212.82.108.250] by tm9.bullet.mail.ird.yahoo.com with NNFMP;
	17 Jan 2012 15:38:48 -0000
Received: from [127.0.0.1] by omp1015.mail.ird.yahoo.com with NNFMP;
	17 Jan 2012 15:38:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 385447.71716.bm@omp1015.mail.ird.yahoo.com
Received: (qmail 2010 invoked by uid 60001); 17 Jan 2012 15:38:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1326814728; bh=HMgSpgxPvWNEmN1grAVMPBg5/QoGizYpFCVKeEh3jAQ=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=Hslp+3fi4tBF47JKP/V+t1LMS1U7+yOaJNfiyZGJpvUUGjjFaShbilkiGAMISoJ6uCVKC16/rzNa+G1KQGi7yOaO6PXxvsOMXsIUWwmlrscjgI7ytx2LjS4l4UZ4r4BJG+7W9sAw1qDCM6X7SJkxciE3QiFVBA4oNTCvwZzhnt8=
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=d2QcRVsnZDpvAsXonWx2cgJ5fCkaEWOlD4bXr/qTvDBLWvZQFtAxT3ZZ5tgiDqc+9uvv7p7KigoeWCh40xhswbSTUVm9QBi9CPqalr7b0F+MLR2PIEU8rCVJXGF0h+Mu9coLYdCb32QAFeT4ZbvjjO534Afex73WUWioX6ciXd8=;
X-YMail-OSG: 8RndlXcVM1mvXNbK13IfO9PyAjTbkboyfo.Mu9Yv8wKSRWt
	My7BlAxYgrbk5GhNaesOreoGgBXLJ52N8YO_VQ4u_.gHZTzsQbTh5PJklrVl
	HQsFTGh8tM.9XGeJ4H5Ll6sn7h6WajanZ2fjnuXbx3KBqXOhL3sAi.slx_Jl
	oFuoFsLANtnln_REJC228II6KXz8uqKsjbUc1M4zSIkgdM5UeZCz7.SltNng
	jzEpugunf3P4nUSikw0Gs9U1LS4TEGTdkyf0get0qxv86cWt9lCKjkepPBKH
	LwhJ6nqpcGJt5uVTvob7XHZ17Irlst0IiuP_hP_PAn8utAqQklhLw4ul7HY5
	2ZBaOY9dlYkJTxsxjSBOSWHBfri.JjcZI5zgFjgXgjH1i9YcllMxCo6DNCqN
	inGBmzaBaycOiBwpeK7su9EPM6Az42IuvEg_kOAFLg9Y9MvBtmFowx4YiXoz
	_qHtg8l1mC7cbyMuk9aXhhA3mSn.AeUKD0a63ToMSDjphbcIpt3vBqONbiBc
	0RJ9qOZ0JVVGMOfnHcCWdOgfkibMSXyhVHIZc2hcTxF0gd7F.lv_cRwMhnr4
	CkMw06kxJAbQcKhynNwnERyY.E7OFVxckaNjJaw1gMCNWGslb7AfoWCJys9Q
	iE7CD8OM0TtnVFcu5IbLlKxWwlFtjZztnxwemexMwWeY-
Received: from [195.167.237.98] by web29803.mail.ird.yahoo.com via HTTP;
	Tue, 17 Jan 2012 15:38:48 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
	<CAFoWEVPww5rA96qvApmpV9+jkDxmm1BXkXddvf8in8AhaoPcmA@mail.gmail.com>
Message-ID: <1326814728.463.YahooMailNeo@web29803.mail.ird.yahoo.com>
Date: Tue, 17 Jan 2012 15:38:48 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Sandi Romih <romihs.forums@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <CAFoWEVPww5rA96qvApmpV9+jkDxmm1BXkXddvf8in8AhaoPcmA@mail.gmail.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re :  Available PCIe lanes for VGA passthrough
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="===============8421687508330393308=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8421687508330393308==
Content-Type: multipart/alternative; boundary="-829503087-1199233997-1326814728=:463"

---829503087-1199233997-1326814728=:463
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=0A=0AFirst of all, be sure that you have tested the revision <=3D 24491.=
=0A=0AI mean=0A=0Ahg clone -r $rev http://xenbits.xensource.com/staging/xen=
-unstable.hg/ xen-unstable.hg-rev-${rev}=0A=0Arev<=3D24491=0A=0A=0Arevision=
 between, 24492 and 24516 may not work for the moment due to revision 24492=
 (ATS device driver for IOMMU+HVM) it may not work.=0A=0AFor the moment I d=
id not try revision > 24516.=0A=0AThen check that=A0 tools/firmware/hvmload=
er/acpi/dsdt.aslis updated according to the 3 mem ranges.=0A=0Admesg | grep=
 03:00.0 | grep BAR=0A=0AHave a look on my blog. There is an example Sectio=
n 6. "Quick instructions to install Xen with patches" - Point 5=0A=0A=0AFin=
ally rebuild Xen.=0A=0A=0A________________________________=0A De=A0: Sandi =
Romih <romihs.forums@gmail.com>=0A=C0=A0: xen-devel@lists.xensource.com =0A=
Envoy=E9 le : Mardi 17 Janvier 2012 14h02=0AObjet=A0: Re: [Xen-devel] Avail=
able PCIe lanes for VGA passthrough=0A =0A=0AHello everyone,=0A=0ALooks lik=
e my initial email to xen-devel did not get delivered or something...=0APle=
ase see it below this email.=0A=0AOkay, here is some info about my system:=
=0A=0Alspci | grep -i vga=0A03:00.0 VGA compatible controller: nVidia Corpo=
ration GF100 [GeForce GTX 480] (rev a3)=0A06:04.0 VGA compatible controller=
: Matrox Graphics, Inc. MGA G200eW WPCM450 (rev 0a)=0A=0A=0Alspci | grep -i=
 03:00=0A03:00.0 VGA compatible controller: nVidia Corporation GF100 [GeFor=
ce GTX 480] (rev a3)=0A03:00.1 Audio device: nVidia Corporation GF100 High =
Definition Audio Controller (rev a1)=0A=0A=0Admesg | grep -i 03:00=0A[ =A0 =
=A00.000000] Command line: placeholder root=3DUUID=3Dd5f5207b-d2aa-4f19-b51=
d-bc2c727b9e8f ro nomodeset xen-pciback.passthrough=3D1 xen-pciback.permiss=
ive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet=0A[ =A0 =A05.114443] Kernel=
 command line: placeholder root=3DUUID=3Dd5f5207b-d2aa-4f19-b51d-bc2c727b9e=
8f ro nomodeset xen-pciback.passthrough=3D1 xen-pciback.permissive xen-pcib=
ack.hide=3D(03:00.0)(03:00.1) quiet=0A[ =A0 =A05.356290] pci 0000:03:00.0: =
[10de:06c0] type 0 class 0x000300=0A[ =A0 =A05.356310] pci 0000:03:00.0: re=
g 10: [mem 0xf8000000-0xf9ffffff]=0A[ =A0 =A05.356332] pci 0000:03:00.0: re=
g 14: [mem 0xd8000000-0xdfffffff 64bit pref]=0A[ =A0 =A05.356353] pci 0000:=
03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64bit pref]=0A[ =A0 =A05.356368=
] pci 0000:03:00.0: reg 24: [io =A00xdc00-0xdc7f]=0A[ =A0 =A05.356383] pci =
0000:03:00.0: reg 30: [mem 0xfae80000-0xfaefffff pref]=0A[ =A0 =A05.356475]=
 pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403=0A[ =A0 =A05.356494] p=
ci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]=0A[ =A0 =A05.425416] v=
gaarb: device added: PCI:0000:03:00.0,decodes=3Dio+mem,owns=3Dnone,locks=3D=
none=0A[ =A0 =A05.425438] vgaarb: bridge control possible 0000:03:00.0=0A[ =
=A0 =A05.443721] pciback 0000:03:00.0: seizing device=0A[ =A0 =A05.443726] =
pciback 0000:03:00.1: seizing device=0A[ =A0 =A05.713088] pciback 0000:03:0=
0.0: Signaling PME through PCIe PME interrupt=0A[ =A0 =A05.713090] pciback =
0000:03:00.1: Signaling PME through PCIe PME interrupt=0A[ =A0 =A05.713566]=
 pciback 0000:03:00.1: PCI INT B -> GSI 25 (level, low) -> IRQ 25=0A[ =A0 =
=A05.713574] pciback 0000:03:00.1: PCI INT B disabled=0A[ =A0 =A05.713610] =
pciback 0000:03:00.0: enabling device (0146 -> 0147)=0A[ =A0 =A05.713627] p=
ciback 0000:03:00.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26=0A[ =A0 =A0=
5.713633] pciback 0000:03:00.0: PCI INT A disabled=0A=0A=0Axl pci-list-assi=
gnable-devices=A0=0A0000:03:00.0=0A0000:03:00.1=0A=0A=0Acat /etc/default/gr=
ub=A0=0AGRUB_DEFAULT=3D0=0AGRUB_TIMEOUT=3D5=0AGRUB_DISTRIBUTOR=3D`lsb_relea=
se -i -s 2> /dev/null || echo Debian`=0AGRUB_CMDLINE_LINUX_DEFAULT=3D"quiet=
"=0AGRUB_CMDLINE_LINUX=3D"nomodeset xen-pciback.passthrough=3D1 xen-pciback=
.permissive xen-pciback.hide=3D(03:00.0)(03:00.1)"=0AGRUB_DISABLE_OS_PROBER=
=3Dtrue=0AGRUB_CMDLINE_XEN=3D"dom0_mem=3D1G"=0A=0A=0AFrom all that, I assum=
e that the VGA card, and its=A0on-board=A0audio device, is owned by pciback=
.=0A=0A=0AThis is how I start the domain:=0Axl create xenwinxp.cfg=A0=0APar=
sing config file xenwinxp.cfg=0AWARNING: ignoring "kernel" directive for HV=
M guest. Use "firmware_override" instead if you really want a non-default f=
irmware=0Axc: info: VIRTUAL MEMORY ARRANGEMENT:=0A=A0 Loader: =A0 =A0 =A0 =
=A00000000000100000->00000000001819b4=0A=A0 TOTAL: =A0 =A0 =A0 =A0 00000000=
00000000->00000000bf800000=0A=A0 ENTRY ADDRESS: 0000000000100000=0Axc: info=
: PHYSICAL MEMORY ALLOCATION:=0A=A0 4KB PAGES: 0x0000000000000200=0A=A0 2MB=
 PAGES: 0x00000000000003fb=0A=A0 1GB PAGES: 0x0000000000000001=0Alibxl: err=
or: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't support res=
et from sysfs for PCI device 0000:03:00.0=0ADaemon running with PID 3001=0A=
=0AQuick confirmation that it is up and running:=0Axl list=0AName =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ID =
=A0 Mem VCPUsStateTime(s)=0ADomain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A01024 =A0 =A012 =A0 =A0 r----- =A0 =
=A0 255.7=0Awinxp =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A01 =A03067 =A0 =A0 4 =A0 =A0 -b---- =A0 =A0 =A061.2=
=0A=0AThis is my xen config file:=0Akernel =3D "/usr/lib/xen/boot/hvmloader=
"=0Abuilder=3D'hvm'=0Amemory =3D 3072=0A# shadow_memory =3D 1024=0Aname =3D=
 "winxp"=0Avcpus=3D'4'=0Avif =3D [ 'bridge=3Deth0,mac=3D00:14:3e:00:8f:c2' =
]=0Adisk =3D ['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/=
winxp.iso,hdc:cdrom,r']=0Aboot=3D"cd"=0Asdl=3D0=0Avnc=3D1=0Avnclisten=3D"0.=
0.0.0"=0Avncconsole=3D1=0Avncpasswd=3D''=0Aacpi=3D1=0Aapic=3D1=0Axen_extend=
ed_power_mgmt=3D1=0Apae=3D1=0Aarch=3D'x86_64'=0Ahpet =3D 1=0Ahap =3D 1=0Avi=
ridian =3D 1=0Amonitor=3D1=0Aserial=3D'pty'=0A# keymap=3D'fr'=0A# soundhw =
=3D "all"=0A# audio=3D"on"=0Ane2000=3D0=0Aon_poweroff =3D 'destroy'=0Aon_re=
boot =A0 =3D 'restart'=0Aon_crash =A0 =A0=3D 'restart'=0Axen_platform_pci=
=3D1=0Agfx_passthru=3D0=0Apci =A0=3D [ "03:00.0,msitranslate=3D1,power_mgmt=
=3D1" ]=0Aacpi_s3 =3D 1=0Aacpi_s4 =3D 1=0A=0A=0AThe Windows XP boots up fin=
e, I can see the GTX480 in the device manager, but it is not useable.=0A=0A=
=A0Now, let me try gfx_passthru=3D1=0A=0ACreate the domain:=0Axl create xen=
winxp.cfg=A0=0AParsing config file xenwinxp.cfg=0AWARNING: ignoring "kernel=
" directive for HVM guest. Use "firmware_override" instead if you really wa=
nt a non-default firmware=0Axc: info: VIRTUAL MEMORY ARRANGEMENT:=0A=A0 Loa=
der: =A0 =A0 =A0 =A00000000000100000->00000000001819b4=0A=A0 TOTAL: =A0 =A0=
 =A0 =A0 0000000000000000->00000000bf800000=0A=A0 ENTRY ADDRESS: 0000000000=
100000=0Axc: info: PHYSICAL MEMORY ALLOCATION:=0A=A0 4KB PAGES: 0x000000000=
0000200=0A=A0 2MB PAGES: 0x00000000000003fb=0A=A0 1GB PAGES: 0x000000000000=
0001=0Alibxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel do=
esn't support reset from sysfs for PCI device 0000:03:00.0=0ADaemon running=
 with PID 3454=0A=0AWhen the domain starts, my dom0=A0screen=A0attached to =
the=A006:04.0 VGA controller goes blank, and after a few seconds I get a me=
ssage from my monitor that 'this video format is not supported'. I can get =
back to my dom0 by first going Ctrl-Alt-F1 (where I will see a whole bunch =
of garbage in the screen) and then Ctrl-Alt-F7.=0A=0AThe domain is running:=
=0Axl list=0AName =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0ID =A0 Mem VCPUsStateTime(s)=0ADomain-0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A01024 =A0 =
=A012 =A0 =A0 r----- =A0 =A0 385.3=0Awinxp =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03 =A03063 =A0 =A0 1 =A0 =A0 =
r----- =A0 =A0 324.5=0A=0AAnd if I check out what is happening through vncv=
iewer, I see just the QEMU console (QEMU 0.10.2 monitor - type 'help' for m=
ore information)=0A=0AAnd=A0finally, I see that the VGA card is no longer a=
vailable:=0Axl pci-list-assignable-devices=A0=0A0000:03:00.1=0A=0A=0AI have=
 checked all three of the video cards outputs, no video signal anywhere.=0A=
=0A=0AAny ideas about what could be causing the=A0problems=A0I am encounter=
ing?=0AI would be grateful for any info.=0A=0AThanks in advance.=0A=0ASandi=
=0A=0A=0A=0A=0A=0AOn Tue, Jan 17, 2012 at 11:10 AM, Sandi Romih <romihs.for=
ums@gmail.com> wrote:=0A=0AHello,=0A>=0A>=0A>I hope that I am posting the c=
orrect list with this question.=0A>=0A>=0A>I have been trying to get VGA pa=
ssthrough working on my system for some time now without success.=0A>I do n=
ot have the system with me right now, so I will not be able to provide any =
logs or error messages right now. I will be able to to do so in a couple of=
 hours.=0A>=0A>=0A>I have a VT-d enabled system (Motherboard and CPU) on wh=
ich I wish to pass the secondary graphics card (EVGA GTX480 SE) through to =
the HVM (WinXP 32-bit).=0A>Currently I am testing with Debian Squeeze, usin=
g the 3.1.8 kernel and Xen 4.2.unstable according to these instructions:=A0=
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches=
-for-vga-pass-through=0A>=0A>=0A>I can only boot the WinXP client via the V=
NC console (gfx_passthrough=3D0), and from within WinXP I see that the OS h=
as detected the GTX480 card (as its secondary card), but I am not able to u=
se it. I have tried the=A0275.33 drives, and they make no difference.=0A>=
=0A>=0A>My question is related to the number of PCIe lanes I have available=
 to the graphics card.=0A>I only have 8 lanes available for the GTX480 (whi=
ch is a PCIe x16 card), could this pose an issue for Xen?=0A>=0A>=0A>=0A>=
=0A>I plan to test VGA passthrough with an ATI graphics card (also in a PCI=
e x8 slot) later to see if it will work or not. I will update what I find.=
=0A>=0A>=0A>Regards=0A>=0A>Sandi=0A=0A_____________________________________=
__________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp:=
//lists.xensource.com/xen-devel
---829503087-1199233997-1326814728=:463
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>First of all, be sure that you =
have tested the revision &lt;=3D 24491.</span></div><div><br><span></span><=
/div><div><span>I mean</span></div><div><br><span></span></div><pre>hg clon=
e -r $rev http://xenbits.xensource.com/staging/xen-unstable.hg/ xen-unstabl=
e.hg-rev-${rev}<br><br>rev&lt;=3D24491<br></pre><div><br><span></span></div=
><div><span>revision between, 24492 and 24516 may not work for the moment <=
/span><span>due to revision 24492 (ATS device driver for IOMMU+HVM) it may =
not work.</span></div><div><br><span></span></div><div><span>For the moment=
 I did not try revision &gt; 24516.</span></div><div><span><br></span></div=
><div><span>Then check that&nbsp; </span><code>tools/firmware/hvmloader/acp=
i/dsdt.asl</code><span> is updated according to the 3 mem
 ranges.</span></div><div><br><span></span></div><pre>dmesg | grep 03:00.0<=
strong></strong> | grep BAR<br><br>Have a look on my blog. There is an exam=
ple Section 6. "Quick instructions to install Xen with patches" - Point 5<b=
r></pre><h2><br></h2><div>Finally rebuild Xen.<br></div>  <div style=3D"fon=
t-family: times new roman, new york, times, serif; font-size: 12pt;"> <div =
style=3D"font-family: times new roman, new york, times, serif; font-size: 1=
2pt;"> <div dir=3D"ltr"> <font size=3D"2" face=3D"Arial"> <hr size=3D"1">  =
<b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> Sandi Romih &lt;r=
omihs.forums@gmail.com&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nb=
sp;:</span></b> xen-devel@lists.xensource.com <br> <b><span style=3D"font-w=
eight: bold;">Envoy=E9 le :</span></b> Mardi 17 Janvier 2012 14h02<br> <b><=
span style=3D"font-weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] A=
vailable PCIe lanes for VGA passthrough<br> </font> </div> <br><div
 id=3D"yiv404097981">Hello everyone,<div><br></div><div>Looks like my initi=
al email to xen-devel did not get delivered or something...</div><div>Pleas=
e see it below this email.</div><div><br></div><div>Okay, here is some info=
 about my system:</div>=0A<div><br></div><div><div>lspci | grep -i vga</div=
><div>03:00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce =
GTX 480] (rev a3)</div><div>06:04.0 VGA compatible controller: Matrox Graph=
ics, Inc. MGA G200eW WPCM450 (rev 0a)</div>=0A<div><br></div><div><br></div=
><div><div>lspci | grep -i 03:00</div><div>03:00.0 VGA compatible controlle=
r: nVidia Corporation GF100 [GeForce GTX 480] (rev a3)</div><div>03:00.1 Au=
dio device: nVidia Corporation GF100 High Definition Audio Controller (rev =
a1)</div>=0A</div><div><br></div><div><br></div><div><div>dmesg | grep -i 0=
3:00</div><div>[ &nbsp; &nbsp;0.000000] Command line: placeholder root=3DUU=
ID=3Dd5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.passthro=
ugh=3D1 xen-pciback.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet<=
/div>=0A<div>[ &nbsp; &nbsp;5.114443] Kernel command line: placeholder root=
=3DUUID=3Dd5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.pas=
sthrough=3D1 xen-pciback.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) q=
uiet</div><div>[ &nbsp; &nbsp;5.356290] pci 0000:03:00.0: [10de:06c0] type =
0 class 0x000300</div>=0A<div>[ &nbsp; &nbsp;5.356310] pci 0000:03:00.0: re=
g 10: [mem 0xf8000000-0xf9ffffff]</div><div>[ &nbsp; &nbsp;5.356332] pci 00=
00:03:00.0: reg 14: [mem 0xd8000000-0xdfffffff 64bit pref]</div><div>[ &nbs=
p; &nbsp;5.356353] pci 0000:03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64b=
it pref]</div>=0A<div>[ &nbsp; &nbsp;5.356368] pci 0000:03:00.0: reg 24: [i=
o &nbsp;0xdc00-0xdc7f]</div><div>[ &nbsp; &nbsp;5.356383] pci 0000:03:00.0:=
 reg 30: [mem 0xfae80000-0xfaefffff pref]</div><div>[ &nbsp; &nbsp;5.356475=
] pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403</div>=0A<div>[ &nbsp;=
 &nbsp;5.356494] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]</div=
><div>[ &nbsp; &nbsp;5.425416] vgaarb: device added: PCI:0000:03:00.0,decod=
es=3Dio+mem,owns=3Dnone,locks=3Dnone</div><div>[ &nbsp; &nbsp;5.425438] vga=
arb: bridge control possible 0000:03:00.0</div>=0A<div>[ &nbsp; &nbsp;5.443=
721] pciback 0000:03:00.0: seizing device</div><div>[ &nbsp; &nbsp;5.443726=
] pciback 0000:03:00.1: seizing device</div><div>[ &nbsp; &nbsp;5.713088] p=
ciback 0000:03:00.0: Signaling PME through PCIe PME interrupt</div><div>[ &=
nbsp; &nbsp;5.713090] pciback 0000:03:00.1: Signaling PME through PCIe PME =
interrupt</div>=0A<div>[ &nbsp; &nbsp;5.713566] pciback 0000:03:00.1: PCI I=
NT B -&gt; GSI 25 (level, low) -&gt; IRQ 25</div><div>[ &nbsp; &nbsp;5.7135=
74] pciback 0000:03:00.1: PCI INT B disabled</div><div>[ &nbsp; &nbsp;5.713=
610] pciback 0000:03:00.0: enabling device (0146 -&gt; 0147)</div>=0A<div>[=
 &nbsp; &nbsp;5.713627] pciback 0000:03:00.0: PCI INT A -&gt; GSI 26 (level=
, low) -&gt; IRQ 26</div><div>[ &nbsp; &nbsp;5.713633] pciback 0000:03:00.0=
: PCI INT A disabled</div></div><div><br></div><div><br></div><div><div>xl =
pci-list-assignable-devices&nbsp;</div>=0A<div>0000:03:00.0</div><div>0000:=
03:00.1</div></div><div><br></div><div><br></div><div><div>cat /etc/default=
/grub&nbsp;</div><div>GRUB_DEFAULT=3D0</div><div>GRUB_TIMEOUT=3D5</div><div=
>GRUB_DISTRIBUTOR=3D`lsb_release -i -s 2&gt; /dev/null || echo Debian`</div=
>=0A<div>GRUB_CMDLINE_LINUX_DEFAULT=3D"quiet"</div><div>GRUB_CMDLINE_LINUX=
=3D"nomodeset xen-pciback.passthrough=3D1 xen-pciback.permissive xen-pcibac=
k.hide=3D(03:00.0)(03:00.1)"</div><div>GRUB_DISABLE_OS_PROBER=3Dtrue</div>=
=0A<div>GRUB_CMDLINE_XEN=3D"dom0_mem=3D1G"</div></div><div><br></div><div><=
br></div><div>From all that, I assume that the VGA card, and its&nbsp;on-bo=
ard&nbsp;audio device, is owned by pciback.</div><div><br></div><div><br></=
div>=0A<div>This is how I start the domain:</div><div><div>xl create xenwin=
xp.cfg&nbsp;</div><div>Parsing config file xenwinxp.cfg</div><div>WARNING: =
ignoring "kernel" directive for HVM guest. Use "firmware_override" instead =
if you really want a non-default firmware</div>=0A<div>xc: info: VIRTUAL ME=
MORY ARRANGEMENT:</div><div>&nbsp; Loader: &nbsp; &nbsp; &nbsp; &nbsp;00000=
00000100000-&gt;00000000001819b4</div><div>&nbsp; TOTAL: &nbsp; &nbsp; &nbs=
p; &nbsp; 0000000000000000-&gt;00000000bf800000</div><div>&nbsp; ENTRY ADDR=
ESS: 0000000000100000</div>=0A<div>xc: info: PHYSICAL MEMORY ALLOCATION:</d=
iv><div>&nbsp; 4KB PAGES: 0x0000000000000200</div><div>&nbsp; 2MB PAGES: 0x=
00000000000003fb</div><div>&nbsp; 1GB PAGES: 0x0000000000000001</div><div><=
font color=3D"#ff0000">libxl: error: libxl_pci.c:776:libxl__device_pci_rese=
t: The kernel doesn't support reset from sysfs for PCI device 0000:03:00.0<=
/font></div>=0A<div>Daemon running with PID 3001</div></div><div><br></div>=
<div>Quick confirmation that it is up and running:</div><div><div>xl list</=
div><div>Name &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp;ID &nbsp; Mem VCPUs<span class=3D"yiv404097981Apple-tab-span" style=3D"w=
hite-space:pre;">=09</span>State<span class=3D"yiv404097981Apple-tab-span" =
style=3D"white-space:pre;">=09</span>Time(s)</div>=0A<div>Domain-0 &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0 &nbsp;1024 &nbsp; &nbsp;12 &nb=
sp; &nbsp; r----- &nbsp; &nbsp; 255.7</div><div>winxp &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp;3067 &nbsp; &nbsp; 4 &nb=
sp; &nbsp; -b---- &nbsp; &nbsp; &nbsp;61.2</div></div><div><br></div><div>T=
his is my xen config file:</div>=0A<div><div>kernel =3D "/usr/lib/xen/boot/=
hvmloader"</div><div>builder=3D'hvm'</div><div>memory =3D 3072</div><div># =
shadow_memory =3D 1024</div><div>name =3D "winxp"</div><div>vcpus=3D'4'</di=
v><div>=0Avif =3D [ 'bridge=3Deth0,mac=3D00:14:3e:00:8f:c2' ]</div><div>dis=
k =3D ['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/winxp.i=
so,hdc:cdrom,r']</div><div>boot=3D"cd"</div><div>sdl=3D0</div>=0A<div>vnc=
=3D1</div><div>vnclisten=3D"0.0.0.0"</div><div>vncconsole=3D1</div><div>vnc=
passwd=3D''</div><div>acpi=3D1</div><div>apic=3D1</div><div>xen_extended_po=
wer_mgmt=3D1</div><div>pae=3D1</div><div>arch=3D'x86_64'</div>=0A<div>hpet =
=3D 1</div><div>hap =3D 1</div><div>viridian =3D 1</div><div>monitor=3D1</d=
iv><div>serial=3D'pty'</div><div># keymap=3D'fr'</div><div># soundhw =3D "a=
ll"</div><div># audio=3D"on"</div><div>ne2000=3D0</div>=0A<div>on_poweroff =
=3D 'destroy'</div><div>on_reboot &nbsp; =3D 'restart'</div><div>on_crash &=
nbsp; &nbsp;=3D 'restart'</div><div>xen_platform_pci=3D1</div><div>gfx_pass=
thru=3D0</div><div>pci &nbsp;=3D [ "03:00.0,msitranslate=3D1,power_mgmt=3D1=
" ]</div>=0A<div>acpi_s3 =3D 1</div><div>acpi_s4 =3D 1</div></div><div><br>=
</div><div><br></div><div>The Windows XP boots up fine, I can see the GTX48=
0 in the device manager, but it is not useable.</div><div><br></div><div>&n=
bsp;Now, let me try gfx_passthru=3D1</div>=0A<div><br></div><div>Create the=
 domain:</div><div><div>xl create xenwinxp.cfg&nbsp;</div><div>Parsing conf=
ig file xenwinxp.cfg</div><div>WARNING: ignoring "kernel" directive for HVM=
 guest. Use "firmware_override" instead if you really want a non-default fi=
rmware</div>=0A<div>xc: info: VIRTUAL MEMORY ARRANGEMENT:</div><div>&nbsp; =
Loader: &nbsp; &nbsp; &nbsp; &nbsp;0000000000100000-&gt;00000000001819b4</d=
iv><div>&nbsp; TOTAL: &nbsp; &nbsp; &nbsp; &nbsp; 0000000000000000-&gt;0000=
0000bf800000</div><div>&nbsp; ENTRY ADDRESS: 0000000000100000</div>=0A<div>=
xc: info: PHYSICAL MEMORY ALLOCATION:</div><div>&nbsp; 4KB PAGES: 0x0000000=
000000200</div><div>&nbsp; 2MB PAGES: 0x00000000000003fb</div><div>&nbsp; 1=
GB PAGES: 0x0000000000000001</div><div>libxl: error: libxl_pci.c:776:libxl_=
_device_pci_reset: The kernel doesn't support reset from sysfs for PCI devi=
ce 0000:03:00.0</div>=0A<div>Daemon running with PID 3454</div></div><div><=
br></div><div>When the domain starts, my dom0&nbsp;screen&nbsp;attached to =
the&nbsp;06:04.0 VGA controller goes blank, and after a few seconds I get a=
 message from my monitor that 'this video format is not supported'. I can g=
et back to my dom0 by first going Ctrl-Alt-F1 (where I will see a whole bun=
ch of garbage in the screen) and then Ctrl-Alt-F7.</div>=0A<div><br></div><=
div>The domain is running:</div><div><div>xl list</div><div>Name &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ID &nbsp; Mem VCPUs<s=
pan class=3D"yiv404097981Apple-tab-span" style=3D"white-space:pre;">=09</sp=
an>State<span class=3D"yiv404097981Apple-tab-span" style=3D"white-space:pre=
;">=09</span>Time(s)</div>=0A<div>Domain-0 &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; 0 &nbsp;1024 &nbsp; &nbsp;12 &nbsp; &nbsp; r----- &nbsp;=
 &nbsp; 385.3</div><div>winxp &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp;3 &nbsp;3063 &nbsp; &nbsp; 1 &nbsp; &nbsp; r----- &nbsp;=
 &nbsp; 324.5</div></div><div><br></div><div>And if I check out what is hap=
pening through vncviewer, I see just the QEMU console (QEMU 0.10.2 monitor =
- type 'help' for more information)</div>=0A<div><br></div><div>And&nbsp;fi=
nally, I see that the VGA card is no longer available:</div><div><div>xl pc=
i-list-assignable-devices&nbsp;</div><div>0000:03:00.1</div></div><div><br>=
</div><div><br></div><div>I have checked all three of the video cards outpu=
ts, no video signal anywhere.</div>=0A<div><br></div><div><br></div><div>An=
y ideas about what could be causing the&nbsp;problems&nbsp;I am encounterin=
g?</div><div>I would be grateful for any info.</div><div><br></div><div>Tha=
nks in advance.</div><div><br></div><div>Sandi</div>=0A<div><br></div><div>=
<br></div><div><br></div><div><br></div><br><div class=3D"yiv404097981gmail=
_quote">On Tue, Jan 17, 2012 at 11:10 AM, Sandi Romih <span dir=3D"ltr">&lt=
;<a rel=3D"nofollow" ymailto=3D"mailto:romihs.forums@gmail.com" target=3D"_=
blank" href=3D"mailto:romihs.forums@gmail.com">romihs.forums@gmail.com</a>&=
gt;</span> wrote:<br>=0A<blockquote class=3D"yiv404097981gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello,<=
div><br></div><div>I hope that I am posting the correct list with this ques=
tion.</div><div><br></div><div>I have been trying to get VGA passthrough wo=
rking on my system for some time now without success.</div>=0A<div>I do not=
 have the system with me right now, so I will not be able to provide any lo=
gs or error messages right now. I will be able to to do so in a couple of h=
ours.</div>=0A<div><br></div><div>I have a VT-d enabled system (Motherboard=
 and CPU) on which I wish to pass the secondary graphics card (EVGA GTX480 =
SE) through to the HVM (WinXP 32-bit).</div><div>Currently I am testing wit=
h Debian Squeeze, using the 3.1.8 kernel and Xen 4.2.unstable according to =
these instructions:&nbsp;<a rel=3D"nofollow" target=3D"_blank" href=3D"http=
://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for=
-vga-pass-through">http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen=
-42unstable-patches-for-vga-pass-through</a></div>=0A=0A<div><br></div><div=
>I can only boot the WinXP client via the VNC console (gfx_passthrough=3D0)=
, and from within WinXP I see that the OS has detected the GTX480 card (as =
its secondary card), but I am not able to use it. I have tried the&nbsp;<sp=
an style=3D"font-family:Verdana, Arial, Geneva, Helvetica, sans-serif;font-=
size:13px;">275.33 drives, and they make no difference.</span></div>=0A=0A<=
div><span style=3D"font-family:Verdana, Arial, Geneva, Helvetica, sans-seri=
f;font-size:13px;"><br></span></div><div><font face=3D"Verdana, Arial, Gene=
va, Helvetica, sans-serif">My question is related to the number of PCIe lan=
es I have available to the graphics card.</font></div>=0A=0A<div><font face=
=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">I only have 8 lanes avai=
lable for the GTX480 (which is a PCIe x16 card), could this pose an issue f=
or Xen?</font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, s=
ans-serif"><br>=0A=0A</font></div><div><font face=3D"Verdana, Arial, Geneva=
, Helvetica, sans-serif"><br></font></div><div><font face=3D"Verdana, Arial=
, Geneva, Helvetica, sans-serif">I plan to test VGA passthrough with an ATI=
 graphics card (also in a PCIe x8 slot) later to see if it will work or not=
. I will update what I find.</font></div>=0A=0A<div><font face=3D"Verdana, =
Arial, Geneva, Helvetica, sans-serif"><br></font></div><div><font face=3D"V=
erdana, Arial, Geneva, Helvetica, sans-serif">Regards<span class=3D"yiv4040=
97981HOEnZb"><font color=3D"#888888"><br><br>Sandi</font></span></font></di=
v>=0A=0A</blockquote></div><br></div>=0A</div><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>
---829503087-1199233997-1326814728=:463--


--===============8421687508330393308==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8421687508330393308==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:39:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:39:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnB7c-0001WO-Mn; Tue, 17 Jan 2012 15:38:52 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RnB7b-0001WF-36
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:38:51 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326814683!50454711!1
X-Originating-IP: [212.82.109.208]
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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23871 invoked from network); 17 Jan 2012 15:38:03 -0000
Received: from nm25-vm7.bullet.mail.ird.yahoo.com (HELO
	nm25-vm7.bullet.mail.ird.yahoo.com) (212.82.109.208)
	by server-6.tower-27.messagelabs.com with SMTP;
	17 Jan 2012 15:38:03 -0000
Received: from [77.238.189.56] by nm25.bullet.mail.ird.yahoo.com with NNFMP;
	17 Jan 2012 15:38:48 -0000
Received: from [212.82.108.250] by tm9.bullet.mail.ird.yahoo.com with NNFMP;
	17 Jan 2012 15:38:48 -0000
Received: from [127.0.0.1] by omp1015.mail.ird.yahoo.com with NNFMP;
	17 Jan 2012 15:38:48 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 385447.71716.bm@omp1015.mail.ird.yahoo.com
Received: (qmail 2010 invoked by uid 60001); 17 Jan 2012 15:38:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1326814728; bh=HMgSpgxPvWNEmN1grAVMPBg5/QoGizYpFCVKeEh3jAQ=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=Hslp+3fi4tBF47JKP/V+t1LMS1U7+yOaJNfiyZGJpvUUGjjFaShbilkiGAMISoJ6uCVKC16/rzNa+G1KQGi7yOaO6PXxvsOMXsIUWwmlrscjgI7ytx2LjS4l4UZ4r4BJG+7W9sAw1qDCM6X7SJkxciE3QiFVBA4oNTCvwZzhnt8=
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=d2QcRVsnZDpvAsXonWx2cgJ5fCkaEWOlD4bXr/qTvDBLWvZQFtAxT3ZZ5tgiDqc+9uvv7p7KigoeWCh40xhswbSTUVm9QBi9CPqalr7b0F+MLR2PIEU8rCVJXGF0h+Mu9coLYdCb32QAFeT4ZbvjjO534Afex73WUWioX6ciXd8=;
X-YMail-OSG: 8RndlXcVM1mvXNbK13IfO9PyAjTbkboyfo.Mu9Yv8wKSRWt
	My7BlAxYgrbk5GhNaesOreoGgBXLJ52N8YO_VQ4u_.gHZTzsQbTh5PJklrVl
	HQsFTGh8tM.9XGeJ4H5Ll6sn7h6WajanZ2fjnuXbx3KBqXOhL3sAi.slx_Jl
	oFuoFsLANtnln_REJC228II6KXz8uqKsjbUc1M4zSIkgdM5UeZCz7.SltNng
	jzEpugunf3P4nUSikw0Gs9U1LS4TEGTdkyf0get0qxv86cWt9lCKjkepPBKH
	LwhJ6nqpcGJt5uVTvob7XHZ17Irlst0IiuP_hP_PAn8utAqQklhLw4ul7HY5
	2ZBaOY9dlYkJTxsxjSBOSWHBfri.JjcZI5zgFjgXgjH1i9YcllMxCo6DNCqN
	inGBmzaBaycOiBwpeK7su9EPM6Az42IuvEg_kOAFLg9Y9MvBtmFowx4YiXoz
	_qHtg8l1mC7cbyMuk9aXhhA3mSn.AeUKD0a63ToMSDjphbcIpt3vBqONbiBc
	0RJ9qOZ0JVVGMOfnHcCWdOgfkibMSXyhVHIZc2hcTxF0gd7F.lv_cRwMhnr4
	CkMw06kxJAbQcKhynNwnERyY.E7OFVxckaNjJaw1gMCNWGslb7AfoWCJys9Q
	iE7CD8OM0TtnVFcu5IbLlKxWwlFtjZztnxwemexMwWeY-
Received: from [195.167.237.98] by web29803.mail.ird.yahoo.com via HTTP;
	Tue, 17 Jan 2012 15:38:48 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
	<CAFoWEVPww5rA96qvApmpV9+jkDxmm1BXkXddvf8in8AhaoPcmA@mail.gmail.com>
Message-ID: <1326814728.463.YahooMailNeo@web29803.mail.ird.yahoo.com>
Date: Tue, 17 Jan 2012 15:38:48 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Sandi Romih <romihs.forums@gmail.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <CAFoWEVPww5rA96qvApmpV9+jkDxmm1BXkXddvf8in8AhaoPcmA@mail.gmail.com>
MIME-Version: 1.0
Subject: [Xen-devel] Re :  Available PCIe lanes for VGA passthrough
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="===============8421687508330393308=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8421687508330393308==
Content-Type: multipart/alternative; boundary="-829503087-1199233997-1326814728=:463"

---829503087-1199233997-1326814728=:463
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi=0A=0AFirst of all, be sure that you have tested the revision <=3D 24491.=
=0A=0AI mean=0A=0Ahg clone -r $rev http://xenbits.xensource.com/staging/xen=
-unstable.hg/ xen-unstable.hg-rev-${rev}=0A=0Arev<=3D24491=0A=0A=0Arevision=
 between, 24492 and 24516 may not work for the moment due to revision 24492=
 (ATS device driver for IOMMU+HVM) it may not work.=0A=0AFor the moment I d=
id not try revision > 24516.=0A=0AThen check that=A0 tools/firmware/hvmload=
er/acpi/dsdt.aslis updated according to the 3 mem ranges.=0A=0Admesg | grep=
 03:00.0 | grep BAR=0A=0AHave a look on my blog. There is an example Sectio=
n 6. "Quick instructions to install Xen with patches" - Point 5=0A=0A=0AFin=
ally rebuild Xen.=0A=0A=0A________________________________=0A De=A0: Sandi =
Romih <romihs.forums@gmail.com>=0A=C0=A0: xen-devel@lists.xensource.com =0A=
Envoy=E9 le : Mardi 17 Janvier 2012 14h02=0AObjet=A0: Re: [Xen-devel] Avail=
able PCIe lanes for VGA passthrough=0A =0A=0AHello everyone,=0A=0ALooks lik=
e my initial email to xen-devel did not get delivered or something...=0APle=
ase see it below this email.=0A=0AOkay, here is some info about my system:=
=0A=0Alspci | grep -i vga=0A03:00.0 VGA compatible controller: nVidia Corpo=
ration GF100 [GeForce GTX 480] (rev a3)=0A06:04.0 VGA compatible controller=
: Matrox Graphics, Inc. MGA G200eW WPCM450 (rev 0a)=0A=0A=0Alspci | grep -i=
 03:00=0A03:00.0 VGA compatible controller: nVidia Corporation GF100 [GeFor=
ce GTX 480] (rev a3)=0A03:00.1 Audio device: nVidia Corporation GF100 High =
Definition Audio Controller (rev a1)=0A=0A=0Admesg | grep -i 03:00=0A[ =A0 =
=A00.000000] Command line: placeholder root=3DUUID=3Dd5f5207b-d2aa-4f19-b51=
d-bc2c727b9e8f ro nomodeset xen-pciback.passthrough=3D1 xen-pciback.permiss=
ive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet=0A[ =A0 =A05.114443] Kernel=
 command line: placeholder root=3DUUID=3Dd5f5207b-d2aa-4f19-b51d-bc2c727b9e=
8f ro nomodeset xen-pciback.passthrough=3D1 xen-pciback.permissive xen-pcib=
ack.hide=3D(03:00.0)(03:00.1) quiet=0A[ =A0 =A05.356290] pci 0000:03:00.0: =
[10de:06c0] type 0 class 0x000300=0A[ =A0 =A05.356310] pci 0000:03:00.0: re=
g 10: [mem 0xf8000000-0xf9ffffff]=0A[ =A0 =A05.356332] pci 0000:03:00.0: re=
g 14: [mem 0xd8000000-0xdfffffff 64bit pref]=0A[ =A0 =A05.356353] pci 0000:=
03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64bit pref]=0A[ =A0 =A05.356368=
] pci 0000:03:00.0: reg 24: [io =A00xdc00-0xdc7f]=0A[ =A0 =A05.356383] pci =
0000:03:00.0: reg 30: [mem 0xfae80000-0xfaefffff pref]=0A[ =A0 =A05.356475]=
 pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403=0A[ =A0 =A05.356494] p=
ci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]=0A[ =A0 =A05.425416] v=
gaarb: device added: PCI:0000:03:00.0,decodes=3Dio+mem,owns=3Dnone,locks=3D=
none=0A[ =A0 =A05.425438] vgaarb: bridge control possible 0000:03:00.0=0A[ =
=A0 =A05.443721] pciback 0000:03:00.0: seizing device=0A[ =A0 =A05.443726] =
pciback 0000:03:00.1: seizing device=0A[ =A0 =A05.713088] pciback 0000:03:0=
0.0: Signaling PME through PCIe PME interrupt=0A[ =A0 =A05.713090] pciback =
0000:03:00.1: Signaling PME through PCIe PME interrupt=0A[ =A0 =A05.713566]=
 pciback 0000:03:00.1: PCI INT B -> GSI 25 (level, low) -> IRQ 25=0A[ =A0 =
=A05.713574] pciback 0000:03:00.1: PCI INT B disabled=0A[ =A0 =A05.713610] =
pciback 0000:03:00.0: enabling device (0146 -> 0147)=0A[ =A0 =A05.713627] p=
ciback 0000:03:00.0: PCI INT A -> GSI 26 (level, low) -> IRQ 26=0A[ =A0 =A0=
5.713633] pciback 0000:03:00.0: PCI INT A disabled=0A=0A=0Axl pci-list-assi=
gnable-devices=A0=0A0000:03:00.0=0A0000:03:00.1=0A=0A=0Acat /etc/default/gr=
ub=A0=0AGRUB_DEFAULT=3D0=0AGRUB_TIMEOUT=3D5=0AGRUB_DISTRIBUTOR=3D`lsb_relea=
se -i -s 2> /dev/null || echo Debian`=0AGRUB_CMDLINE_LINUX_DEFAULT=3D"quiet=
"=0AGRUB_CMDLINE_LINUX=3D"nomodeset xen-pciback.passthrough=3D1 xen-pciback=
.permissive xen-pciback.hide=3D(03:00.0)(03:00.1)"=0AGRUB_DISABLE_OS_PROBER=
=3Dtrue=0AGRUB_CMDLINE_XEN=3D"dom0_mem=3D1G"=0A=0A=0AFrom all that, I assum=
e that the VGA card, and its=A0on-board=A0audio device, is owned by pciback=
.=0A=0A=0AThis is how I start the domain:=0Axl create xenwinxp.cfg=A0=0APar=
sing config file xenwinxp.cfg=0AWARNING: ignoring "kernel" directive for HV=
M guest. Use "firmware_override" instead if you really want a non-default f=
irmware=0Axc: info: VIRTUAL MEMORY ARRANGEMENT:=0A=A0 Loader: =A0 =A0 =A0 =
=A00000000000100000->00000000001819b4=0A=A0 TOTAL: =A0 =A0 =A0 =A0 00000000=
00000000->00000000bf800000=0A=A0 ENTRY ADDRESS: 0000000000100000=0Axc: info=
: PHYSICAL MEMORY ALLOCATION:=0A=A0 4KB PAGES: 0x0000000000000200=0A=A0 2MB=
 PAGES: 0x00000000000003fb=0A=A0 1GB PAGES: 0x0000000000000001=0Alibxl: err=
or: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't support res=
et from sysfs for PCI device 0000:03:00.0=0ADaemon running with PID 3001=0A=
=0AQuick confirmation that it is up and running:=0Axl list=0AName =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ID =
=A0 Mem VCPUsStateTime(s)=0ADomain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A01024 =A0 =A012 =A0 =A0 r----- =A0 =
=A0 255.7=0Awinxp =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A01 =A03067 =A0 =A0 4 =A0 =A0 -b---- =A0 =A0 =A061.2=
=0A=0AThis is my xen config file:=0Akernel =3D "/usr/lib/xen/boot/hvmloader=
"=0Abuilder=3D'hvm'=0Amemory =3D 3072=0A# shadow_memory =3D 1024=0Aname =3D=
 "winxp"=0Avcpus=3D'4'=0Avif =3D [ 'bridge=3Deth0,mac=3D00:14:3e:00:8f:c2' =
]=0Adisk =3D ['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/=
winxp.iso,hdc:cdrom,r']=0Aboot=3D"cd"=0Asdl=3D0=0Avnc=3D1=0Avnclisten=3D"0.=
0.0.0"=0Avncconsole=3D1=0Avncpasswd=3D''=0Aacpi=3D1=0Aapic=3D1=0Axen_extend=
ed_power_mgmt=3D1=0Apae=3D1=0Aarch=3D'x86_64'=0Ahpet =3D 1=0Ahap =3D 1=0Avi=
ridian =3D 1=0Amonitor=3D1=0Aserial=3D'pty'=0A# keymap=3D'fr'=0A# soundhw =
=3D "all"=0A# audio=3D"on"=0Ane2000=3D0=0Aon_poweroff =3D 'destroy'=0Aon_re=
boot =A0 =3D 'restart'=0Aon_crash =A0 =A0=3D 'restart'=0Axen_platform_pci=
=3D1=0Agfx_passthru=3D0=0Apci =A0=3D [ "03:00.0,msitranslate=3D1,power_mgmt=
=3D1" ]=0Aacpi_s3 =3D 1=0Aacpi_s4 =3D 1=0A=0A=0AThe Windows XP boots up fin=
e, I can see the GTX480 in the device manager, but it is not useable.=0A=0A=
=A0Now, let me try gfx_passthru=3D1=0A=0ACreate the domain:=0Axl create xen=
winxp.cfg=A0=0AParsing config file xenwinxp.cfg=0AWARNING: ignoring "kernel=
" directive for HVM guest. Use "firmware_override" instead if you really wa=
nt a non-default firmware=0Axc: info: VIRTUAL MEMORY ARRANGEMENT:=0A=A0 Loa=
der: =A0 =A0 =A0 =A00000000000100000->00000000001819b4=0A=A0 TOTAL: =A0 =A0=
 =A0 =A0 0000000000000000->00000000bf800000=0A=A0 ENTRY ADDRESS: 0000000000=
100000=0Axc: info: PHYSICAL MEMORY ALLOCATION:=0A=A0 4KB PAGES: 0x000000000=
0000200=0A=A0 2MB PAGES: 0x00000000000003fb=0A=A0 1GB PAGES: 0x000000000000=
0001=0Alibxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel do=
esn't support reset from sysfs for PCI device 0000:03:00.0=0ADaemon running=
 with PID 3454=0A=0AWhen the domain starts, my dom0=A0screen=A0attached to =
the=A006:04.0 VGA controller goes blank, and after a few seconds I get a me=
ssage from my monitor that 'this video format is not supported'. I can get =
back to my dom0 by first going Ctrl-Alt-F1 (where I will see a whole bunch =
of garbage in the screen) and then Ctrl-Alt-F7.=0A=0AThe domain is running:=
=0Axl list=0AName =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0ID =A0 Mem VCPUsStateTime(s)=0ADomain-0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A01024 =A0 =
=A012 =A0 =A0 r----- =A0 =A0 385.3=0Awinxp =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03 =A03063 =A0 =A0 1 =A0 =A0 =
r----- =A0 =A0 324.5=0A=0AAnd if I check out what is happening through vncv=
iewer, I see just the QEMU console (QEMU 0.10.2 monitor - type 'help' for m=
ore information)=0A=0AAnd=A0finally, I see that the VGA card is no longer a=
vailable:=0Axl pci-list-assignable-devices=A0=0A0000:03:00.1=0A=0A=0AI have=
 checked all three of the video cards outputs, no video signal anywhere.=0A=
=0A=0AAny ideas about what could be causing the=A0problems=A0I am encounter=
ing?=0AI would be grateful for any info.=0A=0AThanks in advance.=0A=0ASandi=
=0A=0A=0A=0A=0A=0AOn Tue, Jan 17, 2012 at 11:10 AM, Sandi Romih <romihs.for=
ums@gmail.com> wrote:=0A=0AHello,=0A>=0A>=0A>I hope that I am posting the c=
orrect list with this question.=0A>=0A>=0A>I have been trying to get VGA pa=
ssthrough working on my system for some time now without success.=0A>I do n=
ot have the system with me right now, so I will not be able to provide any =
logs or error messages right now. I will be able to to do so in a couple of=
 hours.=0A>=0A>=0A>I have a VT-d enabled system (Motherboard and CPU) on wh=
ich I wish to pass the secondary graphics card (EVGA GTX480 SE) through to =
the HVM (WinXP 32-bit).=0A>Currently I am testing with Debian Squeeze, usin=
g the 3.1.8 kernel and Xen 4.2.unstable according to these instructions:=A0=
http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches=
-for-vga-pass-through=0A>=0A>=0A>I can only boot the WinXP client via the V=
NC console (gfx_passthrough=3D0), and from within WinXP I see that the OS h=
as detected the GTX480 card (as its secondary card), but I am not able to u=
se it. I have tried the=A0275.33 drives, and they make no difference.=0A>=
=0A>=0A>My question is related to the number of PCIe lanes I have available=
 to the graphics card.=0A>I only have 8 lanes available for the GTX480 (whi=
ch is a PCIe x16 card), could this pose an issue for Xen?=0A>=0A>=0A>=0A>=
=0A>I plan to test VGA passthrough with an ATI graphics card (also in a PCI=
e x8 slot) later to see if it will work or not. I will update what I find.=
=0A>=0A>=0A>Regards=0A>=0A>Sandi=0A=0A_____________________________________=
__________=0AXen-devel mailing list=0AXen-devel@lists.xensource.com=0Ahttp:=
//lists.xensource.com/xen-devel
---829503087-1199233997-1326814728=:463
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>First of all, be sure that you =
have tested the revision &lt;=3D 24491.</span></div><div><br><span></span><=
/div><div><span>I mean</span></div><div><br><span></span></div><pre>hg clon=
e -r $rev http://xenbits.xensource.com/staging/xen-unstable.hg/ xen-unstabl=
e.hg-rev-${rev}<br><br>rev&lt;=3D24491<br></pre><div><br><span></span></div=
><div><span>revision between, 24492 and 24516 may not work for the moment <=
/span><span>due to revision 24492 (ATS device driver for IOMMU+HVM) it may =
not work.</span></div><div><br><span></span></div><div><span>For the moment=
 I did not try revision &gt; 24516.</span></div><div><span><br></span></div=
><div><span>Then check that&nbsp; </span><code>tools/firmware/hvmloader/acp=
i/dsdt.asl</code><span> is updated according to the 3 mem
 ranges.</span></div><div><br><span></span></div><pre>dmesg | grep 03:00.0<=
strong></strong> | grep BAR<br><br>Have a look on my blog. There is an exam=
ple Section 6. "Quick instructions to install Xen with patches" - Point 5<b=
r></pre><h2><br></h2><div>Finally rebuild Xen.<br></div>  <div style=3D"fon=
t-family: times new roman, new york, times, serif; font-size: 12pt;"> <div =
style=3D"font-family: times new roman, new york, times, serif; font-size: 1=
2pt;"> <div dir=3D"ltr"> <font size=3D"2" face=3D"Arial"> <hr size=3D"1">  =
<b><span style=3D"font-weight:bold;">De&nbsp;:</span></b> Sandi Romih &lt;r=
omihs.forums@gmail.com&gt;<br> <b><span style=3D"font-weight: bold;">=C0&nb=
sp;:</span></b> xen-devel@lists.xensource.com <br> <b><span style=3D"font-w=
eight: bold;">Envoy=E9 le :</span></b> Mardi 17 Janvier 2012 14h02<br> <b><=
span style=3D"font-weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] A=
vailable PCIe lanes for VGA passthrough<br> </font> </div> <br><div
 id=3D"yiv404097981">Hello everyone,<div><br></div><div>Looks like my initi=
al email to xen-devel did not get delivered or something...</div><div>Pleas=
e see it below this email.</div><div><br></div><div>Okay, here is some info=
 about my system:</div>=0A<div><br></div><div><div>lspci | grep -i vga</div=
><div>03:00.0 VGA compatible controller: nVidia Corporation GF100 [GeForce =
GTX 480] (rev a3)</div><div>06:04.0 VGA compatible controller: Matrox Graph=
ics, Inc. MGA G200eW WPCM450 (rev 0a)</div>=0A<div><br></div><div><br></div=
><div><div>lspci | grep -i 03:00</div><div>03:00.0 VGA compatible controlle=
r: nVidia Corporation GF100 [GeForce GTX 480] (rev a3)</div><div>03:00.1 Au=
dio device: nVidia Corporation GF100 High Definition Audio Controller (rev =
a1)</div>=0A</div><div><br></div><div><br></div><div><div>dmesg | grep -i 0=
3:00</div><div>[ &nbsp; &nbsp;0.000000] Command line: placeholder root=3DUU=
ID=3Dd5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.passthro=
ugh=3D1 xen-pciback.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet<=
/div>=0A<div>[ &nbsp; &nbsp;5.114443] Kernel command line: placeholder root=
=3DUUID=3Dd5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.pas=
sthrough=3D1 xen-pciback.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) q=
uiet</div><div>[ &nbsp; &nbsp;5.356290] pci 0000:03:00.0: [10de:06c0] type =
0 class 0x000300</div>=0A<div>[ &nbsp; &nbsp;5.356310] pci 0000:03:00.0: re=
g 10: [mem 0xf8000000-0xf9ffffff]</div><div>[ &nbsp; &nbsp;5.356332] pci 00=
00:03:00.0: reg 14: [mem 0xd8000000-0xdfffffff 64bit pref]</div><div>[ &nbs=
p; &nbsp;5.356353] pci 0000:03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64b=
it pref]</div>=0A<div>[ &nbsp; &nbsp;5.356368] pci 0000:03:00.0: reg 24: [i=
o &nbsp;0xdc00-0xdc7f]</div><div>[ &nbsp; &nbsp;5.356383] pci 0000:03:00.0:=
 reg 30: [mem 0xfae80000-0xfaefffff pref]</div><div>[ &nbsp; &nbsp;5.356475=
] pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403</div>=0A<div>[ &nbsp;=
 &nbsp;5.356494] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]</div=
><div>[ &nbsp; &nbsp;5.425416] vgaarb: device added: PCI:0000:03:00.0,decod=
es=3Dio+mem,owns=3Dnone,locks=3Dnone</div><div>[ &nbsp; &nbsp;5.425438] vga=
arb: bridge control possible 0000:03:00.0</div>=0A<div>[ &nbsp; &nbsp;5.443=
721] pciback 0000:03:00.0: seizing device</div><div>[ &nbsp; &nbsp;5.443726=
] pciback 0000:03:00.1: seizing device</div><div>[ &nbsp; &nbsp;5.713088] p=
ciback 0000:03:00.0: Signaling PME through PCIe PME interrupt</div><div>[ &=
nbsp; &nbsp;5.713090] pciback 0000:03:00.1: Signaling PME through PCIe PME =
interrupt</div>=0A<div>[ &nbsp; &nbsp;5.713566] pciback 0000:03:00.1: PCI I=
NT B -&gt; GSI 25 (level, low) -&gt; IRQ 25</div><div>[ &nbsp; &nbsp;5.7135=
74] pciback 0000:03:00.1: PCI INT B disabled</div><div>[ &nbsp; &nbsp;5.713=
610] pciback 0000:03:00.0: enabling device (0146 -&gt; 0147)</div>=0A<div>[=
 &nbsp; &nbsp;5.713627] pciback 0000:03:00.0: PCI INT A -&gt; GSI 26 (level=
, low) -&gt; IRQ 26</div><div>[ &nbsp; &nbsp;5.713633] pciback 0000:03:00.0=
: PCI INT A disabled</div></div><div><br></div><div><br></div><div><div>xl =
pci-list-assignable-devices&nbsp;</div>=0A<div>0000:03:00.0</div><div>0000:=
03:00.1</div></div><div><br></div><div><br></div><div><div>cat /etc/default=
/grub&nbsp;</div><div>GRUB_DEFAULT=3D0</div><div>GRUB_TIMEOUT=3D5</div><div=
>GRUB_DISTRIBUTOR=3D`lsb_release -i -s 2&gt; /dev/null || echo Debian`</div=
>=0A<div>GRUB_CMDLINE_LINUX_DEFAULT=3D"quiet"</div><div>GRUB_CMDLINE_LINUX=
=3D"nomodeset xen-pciback.passthrough=3D1 xen-pciback.permissive xen-pcibac=
k.hide=3D(03:00.0)(03:00.1)"</div><div>GRUB_DISABLE_OS_PROBER=3Dtrue</div>=
=0A<div>GRUB_CMDLINE_XEN=3D"dom0_mem=3D1G"</div></div><div><br></div><div><=
br></div><div>From all that, I assume that the VGA card, and its&nbsp;on-bo=
ard&nbsp;audio device, is owned by pciback.</div><div><br></div><div><br></=
div>=0A<div>This is how I start the domain:</div><div><div>xl create xenwin=
xp.cfg&nbsp;</div><div>Parsing config file xenwinxp.cfg</div><div>WARNING: =
ignoring "kernel" directive for HVM guest. Use "firmware_override" instead =
if you really want a non-default firmware</div>=0A<div>xc: info: VIRTUAL ME=
MORY ARRANGEMENT:</div><div>&nbsp; Loader: &nbsp; &nbsp; &nbsp; &nbsp;00000=
00000100000-&gt;00000000001819b4</div><div>&nbsp; TOTAL: &nbsp; &nbsp; &nbs=
p; &nbsp; 0000000000000000-&gt;00000000bf800000</div><div>&nbsp; ENTRY ADDR=
ESS: 0000000000100000</div>=0A<div>xc: info: PHYSICAL MEMORY ALLOCATION:</d=
iv><div>&nbsp; 4KB PAGES: 0x0000000000000200</div><div>&nbsp; 2MB PAGES: 0x=
00000000000003fb</div><div>&nbsp; 1GB PAGES: 0x0000000000000001</div><div><=
font color=3D"#ff0000">libxl: error: libxl_pci.c:776:libxl__device_pci_rese=
t: The kernel doesn't support reset from sysfs for PCI device 0000:03:00.0<=
/font></div>=0A<div>Daemon running with PID 3001</div></div><div><br></div>=
<div>Quick confirmation that it is up and running:</div><div><div>xl list</=
div><div>Name &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp;ID &nbsp; Mem VCPUs<span class=3D"yiv404097981Apple-tab-span" style=3D"w=
hite-space:pre;">=09</span>State<span class=3D"yiv404097981Apple-tab-span" =
style=3D"white-space:pre;">=09</span>Time(s)</div>=0A<div>Domain-0 &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 0 &nbsp;1024 &nbsp; &nbsp;12 &nb=
sp; &nbsp; r----- &nbsp; &nbsp; 255.7</div><div>winxp &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1 &nbsp;3067 &nbsp; &nbsp; 4 &nb=
sp; &nbsp; -b---- &nbsp; &nbsp; &nbsp;61.2</div></div><div><br></div><div>T=
his is my xen config file:</div>=0A<div><div>kernel =3D "/usr/lib/xen/boot/=
hvmloader"</div><div>builder=3D'hvm'</div><div>memory =3D 3072</div><div># =
shadow_memory =3D 1024</div><div>name =3D "winxp"</div><div>vcpus=3D'4'</di=
v><div>=0Avif =3D [ 'bridge=3Deth0,mac=3D00:14:3e:00:8f:c2' ]</div><div>dis=
k =3D ['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/winxp.i=
so,hdc:cdrom,r']</div><div>boot=3D"cd"</div><div>sdl=3D0</div>=0A<div>vnc=
=3D1</div><div>vnclisten=3D"0.0.0.0"</div><div>vncconsole=3D1</div><div>vnc=
passwd=3D''</div><div>acpi=3D1</div><div>apic=3D1</div><div>xen_extended_po=
wer_mgmt=3D1</div><div>pae=3D1</div><div>arch=3D'x86_64'</div>=0A<div>hpet =
=3D 1</div><div>hap =3D 1</div><div>viridian =3D 1</div><div>monitor=3D1</d=
iv><div>serial=3D'pty'</div><div># keymap=3D'fr'</div><div># soundhw =3D "a=
ll"</div><div># audio=3D"on"</div><div>ne2000=3D0</div>=0A<div>on_poweroff =
=3D 'destroy'</div><div>on_reboot &nbsp; =3D 'restart'</div><div>on_crash &=
nbsp; &nbsp;=3D 'restart'</div><div>xen_platform_pci=3D1</div><div>gfx_pass=
thru=3D0</div><div>pci &nbsp;=3D [ "03:00.0,msitranslate=3D1,power_mgmt=3D1=
" ]</div>=0A<div>acpi_s3 =3D 1</div><div>acpi_s4 =3D 1</div></div><div><br>=
</div><div><br></div><div>The Windows XP boots up fine, I can see the GTX48=
0 in the device manager, but it is not useable.</div><div><br></div><div>&n=
bsp;Now, let me try gfx_passthru=3D1</div>=0A<div><br></div><div>Create the=
 domain:</div><div><div>xl create xenwinxp.cfg&nbsp;</div><div>Parsing conf=
ig file xenwinxp.cfg</div><div>WARNING: ignoring "kernel" directive for HVM=
 guest. Use "firmware_override" instead if you really want a non-default fi=
rmware</div>=0A<div>xc: info: VIRTUAL MEMORY ARRANGEMENT:</div><div>&nbsp; =
Loader: &nbsp; &nbsp; &nbsp; &nbsp;0000000000100000-&gt;00000000001819b4</d=
iv><div>&nbsp; TOTAL: &nbsp; &nbsp; &nbsp; &nbsp; 0000000000000000-&gt;0000=
0000bf800000</div><div>&nbsp; ENTRY ADDRESS: 0000000000100000</div>=0A<div>=
xc: info: PHYSICAL MEMORY ALLOCATION:</div><div>&nbsp; 4KB PAGES: 0x0000000=
000000200</div><div>&nbsp; 2MB PAGES: 0x00000000000003fb</div><div>&nbsp; 1=
GB PAGES: 0x0000000000000001</div><div>libxl: error: libxl_pci.c:776:libxl_=
_device_pci_reset: The kernel doesn't support reset from sysfs for PCI devi=
ce 0000:03:00.0</div>=0A<div>Daemon running with PID 3454</div></div><div><=
br></div><div>When the domain starts, my dom0&nbsp;screen&nbsp;attached to =
the&nbsp;06:04.0 VGA controller goes blank, and after a few seconds I get a=
 message from my monitor that 'this video format is not supported'. I can g=
et back to my dom0 by first going Ctrl-Alt-F1 (where I will see a whole bun=
ch of garbage in the screen) and then Ctrl-Alt-F7.</div>=0A<div><br></div><=
div>The domain is running:</div><div><div>xl list</div><div>Name &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ID &nbsp; Mem VCPUs<s=
pan class=3D"yiv404097981Apple-tab-span" style=3D"white-space:pre;">=09</sp=
an>State<span class=3D"yiv404097981Apple-tab-span" style=3D"white-space:pre=
;">=09</span>Time(s)</div>=0A<div>Domain-0 &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; 0 &nbsp;1024 &nbsp; &nbsp;12 &nbsp; &nbsp; r----- &nbsp;=
 &nbsp; 385.3</div><div>winxp &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp;3 &nbsp;3063 &nbsp; &nbsp; 1 &nbsp; &nbsp; r----- &nbsp;=
 &nbsp; 324.5</div></div><div><br></div><div>And if I check out what is hap=
pening through vncviewer, I see just the QEMU console (QEMU 0.10.2 monitor =
- type 'help' for more information)</div>=0A<div><br></div><div>And&nbsp;fi=
nally, I see that the VGA card is no longer available:</div><div><div>xl pc=
i-list-assignable-devices&nbsp;</div><div>0000:03:00.1</div></div><div><br>=
</div><div><br></div><div>I have checked all three of the video cards outpu=
ts, no video signal anywhere.</div>=0A<div><br></div><div><br></div><div>An=
y ideas about what could be causing the&nbsp;problems&nbsp;I am encounterin=
g?</div><div>I would be grateful for any info.</div><div><br></div><div>Tha=
nks in advance.</div><div><br></div><div>Sandi</div>=0A<div><br></div><div>=
<br></div><div><br></div><div><br></div><br><div class=3D"yiv404097981gmail=
_quote">On Tue, Jan 17, 2012 at 11:10 AM, Sandi Romih <span dir=3D"ltr">&lt=
;<a rel=3D"nofollow" ymailto=3D"mailto:romihs.forums@gmail.com" target=3D"_=
blank" href=3D"mailto:romihs.forums@gmail.com">romihs.forums@gmail.com</a>&=
gt;</span> wrote:<br>=0A<blockquote class=3D"yiv404097981gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello,<=
div><br></div><div>I hope that I am posting the correct list with this ques=
tion.</div><div><br></div><div>I have been trying to get VGA passthrough wo=
rking on my system for some time now without success.</div>=0A<div>I do not=
 have the system with me right now, so I will not be able to provide any lo=
gs or error messages right now. I will be able to to do so in a couple of h=
ours.</div>=0A<div><br></div><div>I have a VT-d enabled system (Motherboard=
 and CPU) on which I wish to pass the secondary graphics card (EVGA GTX480 =
SE) through to the HVM (WinXP 32-bit).</div><div>Currently I am testing wit=
h Debian Squeeze, using the 3.1.8 kernel and Xen 4.2.unstable according to =
these instructions:&nbsp;<a rel=3D"nofollow" target=3D"_blank" href=3D"http=
://www.davidgis.fr/blog/index.php?2011/12/07/860-xen-42unstable-patches-for=
-vga-pass-through">http://www.davidgis.fr/blog/index.php?2011/12/07/860-xen=
-42unstable-patches-for-vga-pass-through</a></div>=0A=0A<div><br></div><div=
>I can only boot the WinXP client via the VNC console (gfx_passthrough=3D0)=
, and from within WinXP I see that the OS has detected the GTX480 card (as =
its secondary card), but I am not able to use it. I have tried the&nbsp;<sp=
an style=3D"font-family:Verdana, Arial, Geneva, Helvetica, sans-serif;font-=
size:13px;">275.33 drives, and they make no difference.</span></div>=0A=0A<=
div><span style=3D"font-family:Verdana, Arial, Geneva, Helvetica, sans-seri=
f;font-size:13px;"><br></span></div><div><font face=3D"Verdana, Arial, Gene=
va, Helvetica, sans-serif">My question is related to the number of PCIe lan=
es I have available to the graphics card.</font></div>=0A=0A<div><font face=
=3D"Verdana, Arial, Geneva, Helvetica, sans-serif">I only have 8 lanes avai=
lable for the GTX480 (which is a PCIe x16 card), could this pose an issue f=
or Xen?</font></div><div><font face=3D"Verdana, Arial, Geneva, Helvetica, s=
ans-serif"><br>=0A=0A</font></div><div><font face=3D"Verdana, Arial, Geneva=
, Helvetica, sans-serif"><br></font></div><div><font face=3D"Verdana, Arial=
, Geneva, Helvetica, sans-serif">I plan to test VGA passthrough with an ATI=
 graphics card (also in a PCIe x8 slot) later to see if it will work or not=
. I will update what I find.</font></div>=0A=0A<div><font face=3D"Verdana, =
Arial, Geneva, Helvetica, sans-serif"><br></font></div><div><font face=3D"V=
erdana, Arial, Geneva, Helvetica, sans-serif">Regards<span class=3D"yiv4040=
97981HOEnZb"><font color=3D"#888888"><br><br>Sandi</font></span></font></di=
v>=0A=0A</blockquote></div><br></div>=0A</div><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>
---829503087-1199233997-1326814728=:463--


--===============8421687508330393308==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8421687508330393308==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:39:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnB8F-0001a7-An; Tue, 17 Jan 2012 15:39:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnB8E-0001ZU-0y
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:39:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326814763!7878165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30161 invoked from network); 17 Jan 2012 15:39:24 -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;
	17 Jan 2012 15:39:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10090098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 15:39: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, 17 Jan 2012 15:39:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Tue, 17 Jan 2012 15:39:23 +0000
In-Reply-To: <CAFoWEVN2YKRsKUvJ7uJDvegtRdre8TsgKY_rFJXq2=yYrPBO-A@mail.gmail.com>
References: <CAFoWEVN2YKRsKUvJ7uJDvegtRdre8TsgKY_rFJXq2=yYrPBO-A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326814763.14689.130.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-user@lists.xensource.com" <xen-user@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 to not cross post.

On Tue, 2012-01-17 at 14:03 +0000, Sandi Romih wrote:
> Just sending this test as I sent an email to the xen-devel and I never
> saw it arrive in the list.

As well as this email I have seen
	<CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
and
	<CAFoWEVPww5rA96qvApmpV9+jkDxmm1BXkXddvf8in8AhaoPcmA@mail.gmail.com>
earlier today (both titled "Available PCIe lanes for VGA passthrough".
They are visible in the archives:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01237.html

This suggests that the error is on your end, or perhaps you have
disabled delivery of your own posts in your mailman options?

Anyway, please contact the list admin if you are having trouble instead
of spamming all of the subscribers to the list.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 15:39:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 15:39:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnB8F-0001a7-An; Tue, 17 Jan 2012 15:39:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnB8E-0001ZU-0y
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:39:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326814763!7878165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30161 invoked from network); 17 Jan 2012 15:39:24 -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;
	17 Jan 2012 15:39:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10090098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 15:39: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, 17 Jan 2012 15:39:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Tue, 17 Jan 2012 15:39:23 +0000
In-Reply-To: <CAFoWEVN2YKRsKUvJ7uJDvegtRdre8TsgKY_rFJXq2=yYrPBO-A@mail.gmail.com>
References: <CAFoWEVN2YKRsKUvJ7uJDvegtRdre8TsgKY_rFJXq2=yYrPBO-A@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326814763.14689.130.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-user@lists.xensource.com" <xen-user@lists.xensource.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 to not cross post.

On Tue, 2012-01-17 at 14:03 +0000, Sandi Romih wrote:
> Just sending this test as I sent an email to the xen-devel and I never
> saw it arrive in the list.

As well as this email I have seen
	<CAFoWEVN_Nu__JSw608GsEsUtkaOXfV-HNk+dyO-ix2mZAUmrYA@mail.gmail.com>
and
	<CAFoWEVPww5rA96qvApmpV9+jkDxmm1BXkXddvf8in8AhaoPcmA@mail.gmail.com>
earlier today (both titled "Available PCIe lanes for VGA passthrough".
They are visible in the archives:
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01237.html

This suggests that the error is on your end, or perhaps you have
disabled delivery of your own posts in your mailman options?

Anyway, please contact the list admin if you are having trouble instead
of spamming all of the subscribers to the list.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:20:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16: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 1RnBlm-0002oD-SE; Tue, 17 Jan 2012 16:20:22 +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 1RnBlk-0002o8-Sm
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:20:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326817212!9471096!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwMDA0Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1883 invoked from network); 17 Jan 2012 16:20:14 -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; 17 Jan 2012 16:20:14 -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
	q0HGK2D5025334
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 16:20:11 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
	q0HGEAeJ010482
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 16:14:10 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0HGE94p007907; Tue, 17 Jan 2012 10:14:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 08:14:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 50DC940316; Tue, 17 Jan 2012 11:12:08 -0500 (EST)
Date: Tue, 17 Jan 2012 11:12:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Todd Deshane <todd.deshane@xen.org>
Message-ID: <20120117161208.GA21545@phenom.dumpdata.com>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F159FBC.0028,ss=1,re=0.000,fgs=0
Cc: xen-devel mailing list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
> Hi,
> 
> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
> static on the Dom0 system. (I can PCI passthrough the audio card to a
> DomU and that works). Native sound works fine.
> 
> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
> UTC 2012 i686 i686 i386 GNU/Linux

Did you try 64-bit dom0? What happens if you do not use 'dom0_mem=' arguments?
Does your machine have IOMMU? What is the hypervisor output?

> Here is the "ubuntu-bug audio" generated report:
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/916985
> 
> Let me know if there is any other information that I can provide.
> 
> Thanks,
> Todd
> 
> -- 
> Todd Deshane
> http://www.linkedin.com/in/deshantm
> http://www.xen.org/products/cloudxen.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:20:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16: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 1RnBlm-0002oD-SE; Tue, 17 Jan 2012 16:20:22 +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 1RnBlk-0002o8-Sm
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:20:21 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326817212!9471096!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwMDA0Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1883 invoked from network); 17 Jan 2012 16:20:14 -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; 17 Jan 2012 16:20:14 -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
	q0HGK2D5025334
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 16:20:11 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
	q0HGEAeJ010482
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 16:14:10 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0HGE94p007907; Tue, 17 Jan 2012 10:14:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 08:14:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 50DC940316; Tue, 17 Jan 2012 11:12:08 -0500 (EST)
Date: Tue, 17 Jan 2012 11:12:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Todd Deshane <todd.deshane@xen.org>
Message-ID: <20120117161208.GA21545@phenom.dumpdata.com>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F159FBC.0028,ss=1,re=0.000,fgs=0
Cc: xen-devel mailing list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
> Hi,
> 
> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
> static on the Dom0 system. (I can PCI passthrough the audio card to a
> DomU and that works). Native sound works fine.
> 
> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
> UTC 2012 i686 i686 i386 GNU/Linux

Did you try 64-bit dom0? What happens if you do not use 'dom0_mem=' arguments?
Does your machine have IOMMU? What is the hypervisor output?

> Here is the "ubuntu-bug audio" generated report:
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/916985
> 
> Let me know if there is any other information that I can provide.
> 
> Thanks,
> Todd
> 
> -- 
> Todd Deshane
> http://www.linkedin.com/in/deshantm
> http://www.xen.org/products/cloudxen.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:24:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnBpn-0002x8-HY; Tue, 17 Jan 2012 16:24:31 +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 1RnBpl-0002wm-If
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:24:29 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326817462!9355604!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30984 invoked from network); 17 Jan 2012 16:24:23 -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;
	17 Jan 2012 16:24:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10091795"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:24: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, 17 Jan 2012 16:24:22 +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 1RnBpe-0005on-6J;
	Tue, 17 Jan 2012 16:24:22 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnBpW-0006aJ-Bb;
	Tue, 17 Jan 2012 16:24:14 +0000
Date: Tue, 17 Jan 2012 16:24:14 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120117162414.GA25281@spongy.cam.xci-test.com>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
	<CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
	<alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (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 17/01 02:51, Stefano Stabellini wrote:
> On Mon, 16 Jan 2012, Jean Guyader wrote:
> > On 12 January 2012 14:34, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > >> On 12/01 12:41, 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>
> > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > >>
> > >> ?? ?? 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.
> > >>
> > >> ?? ?? 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.
> > >>
> > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > >> index dbe8804..7ee3c61 100644
> > >> --- a/hw/pass-through.c
> > >> +++ b/hw/pass-through.c
> > >> @@ -238,6 +238,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).
> > >> @@ -444,6 +452,16 @@ 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,
> > >> ?? ?? ??},
> > >> + ?? ??/* Intel IGFX OpRegion reg */
> > >> + ?? ??{
> > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > >> + ?? ?? ?? ??.init_val ?? = 0,
> > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > >> + ?? ??},
> > >> ?? ?? ??{
> > >> ?? ?? ?? ?? ??.size = 0,
> > >> ?? ?? ??},
> > >> @@ -737,7 +755,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 */
> > >> @@ -3006,6 +3024,19 @@ 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)
> > >> +{
> > >> + ?? ??/*
> > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > >> + ?? ??** therefore the size should be 0xff.
> > >> + ?? ??*/
> > >> + ?? ??if (igd_passthru)
> > >> + ?? ?? ?? ??return 0xFF;
> > >> + ?? ??return grp_reg->grp_size;
> > >> +}
> > >
> > > Apart from the trivial code style error in the comment above, is this
> > > going to have the unintended side effect of initializing as 0 all the
> > > emulated registers between 0x40 and 0xff, that previously were probably
> > > passed through?
> > >
> > 
> > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
>  
> actually there is a small change in behaviour: before your patch
> pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> reg_grp_entry corresponding to "Header Type0 reg group" and then
> pt_find_reg would return NULL.
> This case seems to be handled correctly and bring to the same results
> in both pt_pci_write_config and pt_pci_read_config.
> 
> In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> group" only it if really is part of this group otherwise it should be in
> its own separate group.

The pci pass through groups have been designed to pass through pci capabilities
from the device. You can't really create a group for something which isn't a pci
capability.

I have noted the change of behavior but that doesn't have any impact on what we
will return to the guest so I think it fine.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:24:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnBpn-0002x8-HY; Tue, 17 Jan 2012 16:24:31 +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 1RnBpl-0002wm-If
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:24:29 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326817462!9355604!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30984 invoked from network); 17 Jan 2012 16:24:23 -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;
	17 Jan 2012 16:24:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="10091795"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:24: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, 17 Jan 2012 16:24:22 +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 1RnBpe-0005on-6J;
	Tue, 17 Jan 2012 16:24:22 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnBpW-0006aJ-Bb;
	Tue, 17 Jan 2012 16:24:14 +0000
Date: Tue, 17 Jan 2012 16:24:14 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120117162414.GA25281@spongy.cam.xci-test.com>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
	<CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
	<alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (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 17/01 02:51, Stefano Stabellini wrote:
> On Mon, 16 Jan 2012, Jean Guyader wrote:
> > On 12 January 2012 14:34, Stefano Stabellini
> > <stefano.stabellini@eu.citrix.com> wrote:
> > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > >> On 12/01 12:41, 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>
> > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > >>
> > >> ?? ?? 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.
> > >>
> > >> ?? ?? 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.
> > >>
> > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > >> index dbe8804..7ee3c61 100644
> > >> --- a/hw/pass-through.c
> > >> +++ b/hw/pass-through.c
> > >> @@ -238,6 +238,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).
> > >> @@ -444,6 +452,16 @@ 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,
> > >> ?? ?? ??},
> > >> + ?? ??/* Intel IGFX OpRegion reg */
> > >> + ?? ??{
> > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > >> + ?? ?? ?? ??.init_val ?? = 0,
> > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > >> + ?? ??},
> > >> ?? ?? ??{
> > >> ?? ?? ?? ?? ??.size = 0,
> > >> ?? ?? ??},
> > >> @@ -737,7 +755,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 */
> > >> @@ -3006,6 +3024,19 @@ 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)
> > >> +{
> > >> + ?? ??/*
> > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > >> + ?? ??** therefore the size should be 0xff.
> > >> + ?? ??*/
> > >> + ?? ??if (igd_passthru)
> > >> + ?? ?? ?? ??return 0xFF;
> > >> + ?? ??return grp_reg->grp_size;
> > >> +}
> > >
> > > Apart from the trivial code style error in the comment above, is this
> > > going to have the unintended side effect of initializing as 0 all the
> > > emulated registers between 0x40 and 0xff, that previously were probably
> > > passed through?
> > >
> > 
> > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
>  
> actually there is a small change in behaviour: before your patch
> pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> reg_grp_entry corresponding to "Header Type0 reg group" and then
> pt_find_reg would return NULL.
> This case seems to be handled correctly and bring to the same results
> in both pt_pci_write_config and pt_pci_read_config.
> 
> In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> group" only it if really is part of this group otherwise it should be in
> its own separate group.

The pci pass through groups have been designed to pass through pci capabilities
from the device. You can't really create a group for something which isn't a pci
capability.

I have noted the change of behavior but that doesn't have any impact on what we
will return to the guest so I think it fine.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:34:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16: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 1RnBzI-00039i-KR; Tue, 17 Jan 2012 16:34:20 +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 1RnBzH-00039c-DG
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:34:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326818047!10856421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28085 invoked from network); 17 Jan 2012 16:34:13 -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;
	17 Jan 2012 16:34:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092507"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:34:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 16:34:07 +0000
Date: Tue, 17 Jan 2012 16:34:40 +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: <20120117162414.GA25281@spongy.cam.xci-test.com>
Message-ID: <alpine.DEB.2.00.1201171634300.3150@kaball-desktop>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
	<CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
	<alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
	<20120117162414.GA25281@spongy.cam.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 17 Jan 2012, Jean Guyader wrote:
> On 17/01 02:51, Stefano Stabellini wrote:
> > On Mon, 16 Jan 2012, Jean Guyader wrote:
> > > On 12 January 2012 14:34, Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > > >> On 12/01 12:41, 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>
> > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > > >>
> > > >> ?? ?? 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.
> > > >>
> > > >> ?? ?? 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.
> > > >>
> > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > > >> index dbe8804..7ee3c61 100644
> > > >> --- a/hw/pass-through.c
> > > >> +++ b/hw/pass-through.c
> > > >> @@ -238,6 +238,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).
> > > >> @@ -444,6 +452,16 @@ 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,
> > > >> ?? ?? ??},
> > > >> + ?? ??/* Intel IGFX OpRegion reg */
> > > >> + ?? ??{
> > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > > >> + ?? ?? ?? ??.init_val ?? = 0,
> > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > > >> + ?? ??},
> > > >> ?? ?? ??{
> > > >> ?? ?? ?? ?? ??.size = 0,
> > > >> ?? ?? ??},
> > > >> @@ -737,7 +755,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 */
> > > >> @@ -3006,6 +3024,19 @@ 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)
> > > >> +{
> > > >> + ?? ??/*
> > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > > >> + ?? ??** therefore the size should be 0xff.
> > > >> + ?? ??*/
> > > >> + ?? ??if (igd_passthru)
> > > >> + ?? ?? ?? ??return 0xFF;
> > > >> + ?? ??return grp_reg->grp_size;
> > > >> +}
> > > >
> > > > Apart from the trivial code style error in the comment above, is this
> > > > going to have the unintended side effect of initializing as 0 all the
> > > > emulated registers between 0x40 and 0xff, that previously were probably
> > > > passed through?
> > > >
> > > 
> > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
> >  
> > actually there is a small change in behaviour: before your patch
> > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> > reg_grp_entry corresponding to "Header Type0 reg group" and then
> > pt_find_reg would return NULL.
> > This case seems to be handled correctly and bring to the same results
> > in both pt_pci_write_config and pt_pci_read_config.
> > 
> > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> > group" only it if really is part of this group otherwise it should be in
> > its own separate group.
> 
> The pci pass through groups have been designed to pass through pci capabilities
> from the device. You can't really create a group for something which isn't a pci
> capability.
> 
> I have noted the change of behavior but that doesn't have any impact on what we
> will return to the guest so I think it fine.
 
in that case, ack

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:34:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16: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 1RnBzI-00039i-KR; Tue, 17 Jan 2012 16:34:20 +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 1RnBzH-00039c-DG
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:34:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326818047!10856421!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28085 invoked from network); 17 Jan 2012 16:34:13 -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;
	17 Jan 2012 16:34:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092507"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:34:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 16:34:07 +0000
Date: Tue, 17 Jan 2012 16:34:40 +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: <20120117162414.GA25281@spongy.cam.xci-test.com>
Message-ID: <alpine.DEB.2.00.1201171634300.3150@kaball-desktop>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
	<CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
	<alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
	<20120117162414.GA25281@spongy.cam.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (v3)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 17 Jan 2012, Jean Guyader wrote:
> On 17/01 02:51, Stefano Stabellini wrote:
> > On Mon, 16 Jan 2012, Jean Guyader wrote:
> > > On 12 January 2012 14:34, Stefano Stabellini
> > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > > >> On 12/01 12:41, 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>
> > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > > >>
> > > >> ?? ?? 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.
> > > >>
> > > >> ?? ?? 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.
> > > >>
> > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > > >> index dbe8804..7ee3c61 100644
> > > >> --- a/hw/pass-through.c
> > > >> +++ b/hw/pass-through.c
> > > >> @@ -238,6 +238,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).
> > > >> @@ -444,6 +452,16 @@ 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,
> > > >> ?? ?? ??},
> > > >> + ?? ??/* Intel IGFX OpRegion reg */
> > > >> + ?? ??{
> > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > > >> + ?? ?? ?? ??.init_val ?? = 0,
> > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > > >> + ?? ??},
> > > >> ?? ?? ??{
> > > >> ?? ?? ?? ?? ??.size = 0,
> > > >> ?? ?? ??},
> > > >> @@ -737,7 +755,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 */
> > > >> @@ -3006,6 +3024,19 @@ 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)
> > > >> +{
> > > >> + ?? ??/*
> > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > > >> + ?? ??** therefore the size should be 0xff.
> > > >> + ?? ??*/
> > > >> + ?? ??if (igd_passthru)
> > > >> + ?? ?? ?? ??return 0xFF;
> > > >> + ?? ??return grp_reg->grp_size;
> > > >> +}
> > > >
> > > > Apart from the trivial code style error in the comment above, is this
> > > > going to have the unintended side effect of initializing as 0 all the
> > > > emulated registers between 0x40 and 0xff, that previously were probably
> > > > passed through?
> > > >
> > > 
> > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
> >  
> > actually there is a small change in behaviour: before your patch
> > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> > reg_grp_entry corresponding to "Header Type0 reg group" and then
> > pt_find_reg would return NULL.
> > This case seems to be handled correctly and bring to the same results
> > in both pt_pci_write_config and pt_pci_read_config.
> > 
> > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> > group" only it if really is part of this group otherwise it should be in
> > its own separate group.
> 
> The pci pass through groups have been designed to pass through pci capabilities
> from the device. You can't really create a group for something which isn't a pci
> capability.
> 
> I have noted the change of behavior but that doesn't have any impact on what we
> will return to the guest so I think it fine.
 
in that case, ack

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:34:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16: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 1RnBzP-0003A5-11; Tue, 17 Jan 2012 16:34:27 +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 1RnBzN-00039h-PE
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:34:26 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326818058!9501779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14338 invoked from network); 17 Jan 2012 16:34:19 -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;
	17 Jan 2012 16:34:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:34: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, 17 Jan 2012 16:34:18 +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 1RnBzG-0005sa-3l;
	Tue, 17 Jan 2012 16:34:18 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnBz8-0006lA-8Z;
	Tue, 17 Jan 2012 16:34:10 +0000
Date: Tue, 17 Jan 2012 16:34:10 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120117163410.GB25281@spongy.cam.xci-test.com>
References: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
	<1326808398-11229-2-git-send-email-jean.guyader@eu.citrix.com>
	<alpine.DEB.2.00.1201171507030.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201171507030.3150@kaball-desktop>
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>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"djmagee@mageenet.net" <djmagee@mageenet.net>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] intel gpu passthrough: Expose vendor
 specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/01 03:16, Stefano Stabellini wrote:
> On Tue, 17 Jan 2012, Jean Guyader wrote:
> > Some versions of the Windows Intel GPU driver expect the vendor
> > PCI capability to be there on the host bridge config space when
> > passing through a Intel GPU.
> > 
> > From: Ross Philipson <Ross.Philipson@citrix.com>
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > Acked-by: Ross Philipson <Ross.Philipson@citrix.com>
> > 
> > ---
> >  hw/pt-graphics.c |   49 ++++++++++++++++++++++++++++++++++++++++++++-----
> >  1 files changed, 44 insertions(+), 5 deletions(-)
> > 
> > 
> > diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> > index fec7390..25e28ff 100644
> > --- a/hw/pt-graphics.c
> > +++ b/hw/pt-graphics.c
> > @@ -60,6 +60,42 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
> >      }
> >  }
> >  
> > +#define PCI_INTEL_VENDOR_CAP            0x34
> > +#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
> > +static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
> > +                                        uint32_t val)
> > +{
> > +    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > +    uint32_t vendor_cap = 0;
> > +    uint32_t cap_type = 0;
> > +    uint32_t cap_size = 0;
> > +
> > +    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
> > +    if (!vendor_cap)
> > +        return -1;
> > +
> > +    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
> > +    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
> > +        return -1;
> > +
> > +    if (config_addr == PCI_INTEL_VENDOR_CAP)
> > +        return vendor_cap;
> > +
> > +    /* Remove the next capability link */
> > +    if (config_addr == vendor_cap + 1)
> > +        return 0;
> > +
> > +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
> > +    if (config_addr >= vendor_cap &&
> > +            config_addr + len < vendor_cap + cap_size)
> > +    {
> > +        return pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> > +    }
> > +
> > +    /* -1, this function doesn't deal with this config space offset */
> > +    return -1;
> > +}
> 
> You are passing val to igd_pci_read_vendor_cap without actually using
> it.
> Also you are returning -1 from a function that returns uint32_t.
> 
> I would change the prototype of igd_pci_read_vendor_cap to:
> 
> static int igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
>                                         uint32_t *val)
> 
> return only 0 or error and set *val to the correct value.
> 
> 
> 

Thanks for the review.

I'll update the patch and send a new series.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:34:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16: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 1RnBzP-0003A5-11; Tue, 17 Jan 2012 16:34:27 +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 1RnBzN-00039h-PE
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:34:26 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326818058!9501779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14338 invoked from network); 17 Jan 2012 16:34:19 -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;
	17 Jan 2012 16:34:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092510"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:34: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, 17 Jan 2012 16:34:18 +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 1RnBzG-0005sa-3l;
	Tue, 17 Jan 2012 16:34:18 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnBz8-0006lA-8Z;
	Tue, 17 Jan 2012 16:34:10 +0000
Date: Tue, 17 Jan 2012 16:34:10 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120117163410.GB25281@spongy.cam.xci-test.com>
References: <1326808398-11229-1-git-send-email-jean.guyader@eu.citrix.com>
	<1326808398-11229-2-git-send-email-jean.guyader@eu.citrix.com>
	<alpine.DEB.2.00.1201171507030.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201171507030.3150@kaball-desktop>
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>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"djmagee@mageenet.net" <djmagee@mageenet.net>,
	Ross Philipson <Ross.Philipson@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] intel gpu passthrough: Expose vendor
 specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 17/01 03:16, Stefano Stabellini wrote:
> On Tue, 17 Jan 2012, Jean Guyader wrote:
> > Some versions of the Windows Intel GPU driver expect the vendor
> > PCI capability to be there on the host bridge config space when
> > passing through a Intel GPU.
> > 
> > From: Ross Philipson <Ross.Philipson@citrix.com>
> > Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
> > Acked-by: Ross Philipson <Ross.Philipson@citrix.com>
> > 
> > ---
> >  hw/pt-graphics.c |   49 ++++++++++++++++++++++++++++++++++++++++++++-----
> >  1 files changed, 44 insertions(+), 5 deletions(-)
> > 
> > 
> > diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
> > index fec7390..25e28ff 100644
> > --- a/hw/pt-graphics.c
> > +++ b/hw/pt-graphics.c
> > @@ -60,6 +60,42 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
> >      }
> >  }
> >  
> > +#define PCI_INTEL_VENDOR_CAP            0x34
> > +#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
> > +static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
> > +                                        uint32_t val)
> > +{
> > +    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
> > +    uint32_t vendor_cap = 0;
> > +    uint32_t cap_type = 0;
> > +    uint32_t cap_size = 0;
> > +
> > +    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
> > +    if (!vendor_cap)
> > +        return -1;
> > +
> > +    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
> > +    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
> > +        return -1;
> > +
> > +    if (config_addr == PCI_INTEL_VENDOR_CAP)
> > +        return vendor_cap;
> > +
> > +    /* Remove the next capability link */
> > +    if (config_addr == vendor_cap + 1)
> > +        return 0;
> > +
> > +    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
> > +    if (config_addr >= vendor_cap &&
> > +            config_addr + len < vendor_cap + cap_size)
> > +    {
> > +        return pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
> > +    }
> > +
> > +    /* -1, this function doesn't deal with this config space offset */
> > +    return -1;
> > +}
> 
> You are passing val to igd_pci_read_vendor_cap without actually using
> it.
> Also you are returning -1 from a function that returns uint32_t.
> 
> I would change the prototype of igd_pci_read_vendor_cap to:
> 
> static int igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
>                                         uint32_t *val)
> 
> return only 0 or error and set *val to the correct value.
> 
> 
> 

Thanks for the review.

I'll update the patch and send a new series.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 16:39:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnC3j-0003R9-Ti; Tue, 17 Jan 2012 16:38:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnC3h-0003Qn-JD
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:38:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326818327!12773431!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14189 invoked from network); 17 Jan 2012 16:38:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 16:38:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:38:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 16:38:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Doug Magee <djmagee@mageenet.net>
Date: Tue, 17 Jan 2012 16:38:47 +0000
In-Reply-To: <3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
	<3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326818327.14689.140.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl_pci: rename is_assigned to
 is_pcidev_in_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, 2012-01-17 at 15:25 +0000, Doug Magee wrote:
> All this function does is check to see if a device is in an array of pcidevs passed by the caller.  The function name can be misleading if ever used to check against a list of devices other than those assigned to a domain.

In the future please try and wrap your commit messages to <80 columns
but otherwise looks good, thanks.

> Signed-off-by: Doug Magee <djmagee@mageenet.net>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 5b2676ac1321 -r 3becc1652693 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_pci.c	Tue Jan 17 10:14:15 2012 -0500
> @@ -461,7 +461,7 @@ static int get_all_assigned_devices(libx
>      return 0;
>  }
>  
> -static int is_assigned(libxl_device_pci *assigned, int num_assigned,
> +static int is_pcidev_in_array(libxl_device_pci *assigned, int num_assigned,
>                         int dom, int bus, int dev, int func)
>  {
>      int i;
> @@ -510,7 +510,7 @@ libxl_device_pci *libxl_device_pci_list_
>          if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
>              continue;
>  
> -        if ( is_assigned(assigned, num_assigned, dom, bus, dev, func) )
> +        if ( is_pcidev_in_array(assigned, num_assigned, dom, bus, dev, func) )
>              continue;
>  
>          new = realloc(pcidevs, ((*num) + 1) * sizeof(*new));
> @@ -802,7 +802,7 @@ int libxl__device_pci_add(libxl__gc *gc,
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
>          goto out;
>      }
> -    if ( is_assigned(assigned, num_assigned, pcidev->domain,
> +    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
>                       pcidev->bus, pcidev->dev, pcidev->func) ) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
>          rc = ERROR_FAIL;
> @@ -906,7 +906,7 @@ static int do_pci_remove(libxl__gc *gc, 
>          return ERROR_FAIL;
>  
>      rc = ERROR_INVAL;
> -    if ( !is_assigned(assigned, num, pcidev->domain,
> +    if ( !is_pcidev_in_array(assigned, num, pcidev->domain,
>                        pcidev->bus, pcidev->dev, pcidev->func) ) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not attached to this domain");
>          goto out_fail;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 17 16:39:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnC3j-0003R9-Ti; Tue, 17 Jan 2012 16:38:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnC3h-0003Qn-JD
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:38:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326818327!12773431!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14189 invoked from network); 17 Jan 2012 16:38:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 16:38:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:38:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 17 Jan 2012 16:38:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Doug Magee <djmagee@mageenet.net>
Date: Tue, 17 Jan 2012 16:38:47 +0000
In-Reply-To: <3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
	<3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326818327.14689.140.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl_pci: rename is_assigned to
 is_pcidev_in_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, 2012-01-17 at 15:25 +0000, Doug Magee wrote:
> All this function does is check to see if a device is in an array of pcidevs passed by the caller.  The function name can be misleading if ever used to check against a list of devices other than those assigned to a domain.

In the future please try and wrap your commit messages to <80 columns
but otherwise looks good, thanks.

> Signed-off-by: Doug Magee <djmagee@mageenet.net>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 5b2676ac1321 -r 3becc1652693 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/libxl_pci.c	Tue Jan 17 10:14:15 2012 -0500
> @@ -461,7 +461,7 @@ static int get_all_assigned_devices(libx
>      return 0;
>  }
>  
> -static int is_assigned(libxl_device_pci *assigned, int num_assigned,
> +static int is_pcidev_in_array(libxl_device_pci *assigned, int num_assigned,
>                         int dom, int bus, int dev, int func)
>  {
>      int i;
> @@ -510,7 +510,7 @@ libxl_device_pci *libxl_device_pci_list_
>          if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
>              continue;
>  
> -        if ( is_assigned(assigned, num_assigned, dom, bus, dev, func) )
> +        if ( is_pcidev_in_array(assigned, num_assigned, dom, bus, dev, func) )
>              continue;
>  
>          new = realloc(pcidevs, ((*num) + 1) * sizeof(*new));
> @@ -802,7 +802,7 @@ int libxl__device_pci_add(libxl__gc *gc,
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
>          goto out;
>      }
> -    if ( is_assigned(assigned, num_assigned, pcidev->domain,
> +    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
>                       pcidev->bus, pcidev->dev, pcidev->func) ) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
>          rc = ERROR_FAIL;
> @@ -906,7 +906,7 @@ static int do_pci_remove(libxl__gc *gc, 
>          return ERROR_FAIL;
>  
>      rc = ERROR_INVAL;
> -    if ( !is_assigned(assigned, num, pcidev->domain,
> +    if ( !is_pcidev_in_array(assigned, num, pcidev->domain,
>                        pcidev->bus, pcidev->dev, pcidev->func) ) {
>          LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not attached to this domain");
>          goto out_fail;
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 17 16:41:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnC5W-0003YZ-Dr; Tue, 17 Jan 2012 16:40:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RnC5V-0003YB-6w
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:40:45 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326818436!8225569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18217 invoked from network); 17 Jan 2012 16:40:36 -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;
	17 Jan 2012 16:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:40: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, 17 Jan 2012 16:40:35 +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 1RnC5L-0005ux-Hn;
	Tue, 17 Jan 2012 16:40:35 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnC5D-0006p0-Lp;
	Tue, 17 Jan 2012 16:40:27 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 17 Jan 2012 16:40:24 +0000
Message-ID: <1326818425-26194-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, djmagee@mageenet.net, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, Ross.Philipson@citrix.com
Subject: [Xen-devel] [PATCH 1/2] [passthrough] Change init for pt_pci_host
	return value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


With an init of -1 all the return value smaller than a double word
will be prefixed with "f"s.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..6a77657 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2085,7 +2085,7 @@ struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
 {
-    u32 val = -1;
+    u32 val = 0;
 
     pci_access_init();
     pci_read_block(pci_dev, addr, (u8 *) &val, len);

--------------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 Tue Jan 17 16:41:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnC5W-0003YZ-Dr; Tue, 17 Jan 2012 16:40:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RnC5V-0003YB-6w
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:40:45 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326818436!8225569!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18217 invoked from network); 17 Jan 2012 16:40:36 -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;
	17 Jan 2012 16:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:40: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, 17 Jan 2012 16:40:35 +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 1RnC5L-0005ux-Hn;
	Tue, 17 Jan 2012 16:40:35 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnC5D-0006p0-Lp;
	Tue, 17 Jan 2012 16:40:27 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 17 Jan 2012 16:40:24 +0000
Message-ID: <1326818425-26194-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, djmagee@mageenet.net, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, Ross.Philipson@citrix.com
Subject: [Xen-devel] [PATCH 1/2] [passthrough] Change init for pt_pci_host
	return value.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


With an init of -1 all the return value smaller than a double word
will be prefixed with "f"s.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-passthrough-Change-init-for-pt_pci_host-return-value.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..6a77657 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -2085,7 +2085,7 @@ struct pci_dev *pt_pci_get_dev(int bus, int dev, int fn)
 
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len)
 {
-    u32 val = -1;
+    u32 val = 0;
 
     pci_access_init();
     pci_read_block(pci_dev, addr, (u8 *) &val, len);

--------------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 Tue Jan 17 16:41:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:41:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnC5X-0003Ym-QV; Tue, 17 Jan 2012 16:40:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RnC5W-0003YF-Aj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:40:46 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326818436!8225569!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18253 invoked from network); 17 Jan 2012 16:40:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 16:40:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:40: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, 17 Jan 2012 16:40:36 +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 1RnC5L-0005v0-Oq;
	Tue, 17 Jan 2012 16:40:35 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnC5D-0006p2-QU;
	Tue, 17 Jan 2012 16:40:27 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 16:40:25 +0000
Message-ID: <1326818425-26194-2-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
In-Reply-To: <1326818425-26194-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1326818425-26194-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, djmagee@mageenet.net, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, Ross.Philipson@citrix.com
Subject: [Xen-devel] [PATCH 2/2] intel gpu passthrough: Expose vendor
	specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


Some versions of the Windows Intel GPU driver expect the vendor
PCI capability to be there on the host bridge config space when
passing through a Intel GPU.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |   59 +++++++++++++++++++++++++++++++++++++++++++++++++----
 1 files changed, 54 insertions(+), 5 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..55cbf75 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -60,6 +60,53 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     }
 }
 
+#define PCI_INTEL_VENDOR_CAP            0x34
+#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
+/*
+ * This function returns 0 is the value hasn't been
+ * updated. That mean the offset doesn't anything to
+ * do with the vendor capability.
+ */
+static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
+                                        uint32_t *val)
+{
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    uint32_t vendor_cap = 0;
+    uint32_t cap_type = 0;
+    uint32_t cap_size = 0;
+
+    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
+    if (!vendor_cap)
+        return 0;
+
+    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
+    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
+        return 0;
+
+    if (config_addr == PCI_INTEL_VENDOR_CAP)
+    {
+        *val = vendor_cap;
+        return 1;
+    }
+
+    /* Remove the next capability link */
+    if (config_addr == vendor_cap + 1)
+    {
+        *val = 0;
+        return 1;
+    }
+
+    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
+    if (config_addr >= vendor_cap &&
+            config_addr + len < vendor_cap + cap_size)
+    {
+        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+        return 1;
+    }
+
+    return 0;
+}
+
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -82,14 +129,16 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
             val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            val = pci_default_read_config(pci_dev, config_addr, len);
+            if (!igd_pci_read_vendor_cap(pci_dev, config_addr, len, &val))
+                val = pci_default_read_config(pci_dev, config_addr, len);
+
     }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+            config_addr, len, val);
+#endif
     return val;
 }
 

--------------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 Tue Jan 17 16:41:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:41:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnC5X-0003Ym-QV; Tue, 17 Jan 2012 16:40:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RnC5W-0003YF-Aj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:40:46 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326818436!8225569!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18253 invoked from network); 17 Jan 2012 16:40:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 16:40:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10092993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:40: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, 17 Jan 2012 16:40:36 +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 1RnC5L-0005v0-Oq;
	Tue, 17 Jan 2012 16:40:35 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RnC5D-0006p2-QU;
	Tue, 17 Jan 2012 16:40:27 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 17 Jan 2012 16:40:25 +0000
Message-ID: <1326818425-26194-2-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.6.3.3
In-Reply-To: <1326818425-26194-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1326818425-26194-1-git-send-email-jean.guyader@eu.citrix.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------true"
Cc: Ian.Jackson@eu.citrix.com, djmagee@mageenet.net, allen.m.kay@intel.com,
	Jean Guyader <jean.guyader@eu.citrix.com>, Ross.Philipson@citrix.com
Subject: [Xen-devel] [PATCH 2/2] intel gpu passthrough: Expose vendor
	specific pci cap on host bridge.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


Some versions of the Windows Intel GPU driver expect the vendor
PCI capability to be there on the host bridge config space when
passing through a Intel GPU.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |   59 +++++++++++++++++++++++++++++++++++++++++++++++++----
 1 files changed, 54 insertions(+), 5 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0002-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-intel-gpu-passthrough-Expose-vendor-specific-pci-cap.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..55cbf75 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -60,6 +60,53 @@ void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int l
     }
 }
 
+#define PCI_INTEL_VENDOR_CAP            0x34
+#define PCI_INTEL_VENDOR_CAP_TYPE       0x09
+/*
+ * This function returns 0 is the value hasn't been
+ * updated. That mean the offset doesn't anything to
+ * do with the vendor capability.
+ */
+static uint32_t igd_pci_read_vendor_cap(PCIDevice *pci_dev, uint32_t config_addr, int len,
+                                        uint32_t *val)
+{
+    struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
+    uint32_t vendor_cap = 0;
+    uint32_t cap_type = 0;
+    uint32_t cap_size = 0;
+
+    vendor_cap = pt_pci_host_read(pci_dev_host_bridge, PCI_INTEL_VENDOR_CAP, 1);
+    if (!vendor_cap)
+        return 0;
+
+    cap_type = pt_pci_host_read(pci_dev_host_bridge, vendor_cap, 1);
+    if (cap_type != PCI_INTEL_VENDOR_CAP_TYPE)
+        return 0;
+
+    if (config_addr == PCI_INTEL_VENDOR_CAP)
+    {
+        *val = vendor_cap;
+        return 1;
+    }
+
+    /* Remove the next capability link */
+    if (config_addr == vendor_cap + 1)
+    {
+        *val = 0;
+        return 1;
+    }
+
+    cap_size = pt_pci_host_read(pci_dev_host_bridge, vendor_cap + 2, 1);
+    if (config_addr >= vendor_cap &&
+            config_addr + len < vendor_cap + cap_size)
+    {
+        *val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
+        return 1;
+    }
+
+    return 0;
+}
+
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -82,14 +129,16 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
         case 0xa4:        /* SNB: graphics base of stolen memory */
         case 0xa8:        /* SNB: base of GTT stolen memory */
             val = pt_pci_host_read(pci_dev_host_bridge, config_addr, len);
-#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
-            PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
-                    config_addr, len, val);
-#endif
             break;
         default:
-            val = pci_default_read_config(pci_dev, config_addr, len);
+            if (!igd_pci_read_vendor_cap(pci_dev, config_addr, len, &val))
+                val = pci_default_read_config(pci_dev, config_addr, len);
+
     }
+#ifdef PT_DEBUG_PCI_CONFIG_ACCESS
+    PT_LOG_DEV(pci_dev, "addr=%x len=%x val=%x\n",
+            config_addr, len, val);
+#endif
     return val;
 }
 

--------------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 Tue Jan 17 16:41:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnC5y-0003cM-86; Tue, 17 Jan 2012 16:41:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnC5w-0003bW-Mf
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:41:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326818466!11437434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12735 invoked from network); 17 Jan 2012 16:41:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 16:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10093007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:41: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, 17 Jan 2012 16:41:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Doug Magee <djmagee@mageenet.net>
Date: Tue, 17 Jan 2012 16:41:05 +0000
In-Reply-To: <be1313a6b4898c0197ab.1326813907@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
	<be1313a6b4898c0197ab.1326813907@mnetdjm4.mageenet.host>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326818465.14689.142.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is
 assignable before adding to a 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 Tue, 2012-01-17 at 15:25 +0000, Doug Magee wrote:
> Previously, libxl__device_pci_add only checks that the device is not assigned to another domain.  This patch updates this function to check against the list of assignable devices, which only includes devices owned by pciback and already excludes devices assigned to other domains.
> 
> Signed-off-by: Doug Magee <djmagee@mageenet.net>
> 
> diff -r 3becc1652693 -r be1313a6b489 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Tue Jan 17 10:14:15 2012 -0500
> +++ b/tools/libxl/libxl_pci.c	Tue Jan 17 10:19:24 2012 -0500
> @@ -793,18 +793,15 @@ int libxl__device_pci_add(libxl__gc *gc,
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      unsigned int orig_vdev, pfunc_mask;
> -    libxl_device_pci *assigned;
> -    int num_assigned, i, rc;
> +    libxl_device_pci *assignable;
> +    int num_assignable, i, rc;
>      int stubdomid = 0;
>  
> -    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
> -    if ( rc ) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
> -        goto out;
> -    }
> -    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
> +    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);

Unlike get_all_assigned_devices you need to free the returned assignable
array explicitly (since it is in a different category per the comment
near the top of libxl.h).

Ian.

> +
> +    if ( !is_pcidev_in_array(assignable, num_assignable, pcidev->domain,
>                       pcidev->bus, pcidev->dev, pcidev->func) ) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device is either assigned to another domain, or not owned by pciback");
>          rc = ERROR_FAIL;
>          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 Tue Jan 17 16:41:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 16:41:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnC5y-0003cM-86; Tue, 17 Jan 2012 16:41:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnC5w-0003bW-Mf
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 16:41:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326818466!11437434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12735 invoked from network); 17 Jan 2012 16:41:06 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 16:41:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10093007"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 16:41: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, 17 Jan 2012 16:41:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Doug Magee <djmagee@mageenet.net>
Date: Tue, 17 Jan 2012 16:41:05 +0000
In-Reply-To: <be1313a6b4898c0197ab.1326813907@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
	<be1313a6b4898c0197ab.1326813907@mnetdjm4.mageenet.host>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326818465.14689.142.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is
 assignable before adding to a 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 Tue, 2012-01-17 at 15:25 +0000, Doug Magee wrote:
> Previously, libxl__device_pci_add only checks that the device is not assigned to another domain.  This patch updates this function to check against the list of assignable devices, which only includes devices owned by pciback and already excludes devices assigned to other domains.
> 
> Signed-off-by: Doug Magee <djmagee@mageenet.net>
> 
> diff -r 3becc1652693 -r be1313a6b489 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Tue Jan 17 10:14:15 2012 -0500
> +++ b/tools/libxl/libxl_pci.c	Tue Jan 17 10:19:24 2012 -0500
> @@ -793,18 +793,15 @@ int libxl__device_pci_add(libxl__gc *gc,
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      unsigned int orig_vdev, pfunc_mask;
> -    libxl_device_pci *assigned;
> -    int num_assigned, i, rc;
> +    libxl_device_pci *assignable;
> +    int num_assignable, i, rc;
>      int stubdomid = 0;
>  
> -    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
> -    if ( rc ) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
> -        goto out;
> -    }
> -    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
> +    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);

Unlike get_all_assigned_devices you need to free the returned assignable
array explicitly (since it is in a different category per the comment
near the top of libxl.h).

Ian.

> +
> +    if ( !is_pcidev_in_array(assignable, num_assignable, pcidev->domain,
>                       pcidev->bus, pcidev->dev, pcidev->func) ) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device is either assigned to another domain, or not owned by pciback");
>          rc = ERROR_FAIL;
>          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 Tue Jan 17 17:08:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCVY-0004Bc-JO; Tue, 17 Jan 2012 17:07:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <shemminger@vyatta.com>) id 1RnCVX-0004BP-PY
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:07:40 +0000
X-Env-Sender: shemminger@vyatta.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326820053!3859073!1
X-Originating-IP: [76.74.103.46]
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 20099 invoked from network); 17 Jan 2012 17:07:33 -0000
Received: from mail.vyatta.com (HELO mail.vyatta.com) (76.74.103.46)
	by server-8.tower-182.messagelabs.com with SMTP;
	17 Jan 2012 17:07:33 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.vyatta.com (Postfix) with ESMTP id A22381410027;
	Tue, 17 Jan 2012 09:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at tahiti.vyatta.com
Received: from mail.vyatta.com ([127.0.0.1])
	by localhost (mail.vyatta.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id f4RTD1Lk4fIL; Tue, 17 Jan 2012 09:07:31 -0800 (PST)
Received: from nehalam.linuxnetplumber.net
	(static-50-53-80-93.bvtn.or.frontiernet.net [50.53.80.93])
	by mail.vyatta.com (Postfix) with ESMTPSA id 7251B1410020;
	Tue, 17 Jan 2012 09:07:31 -0800 (PST)
Date: Tue, 17 Jan 2012 09:07:30 -0800
From: Stephen Hemminger <shemminger@vyatta.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120117090730.13ae3c6e@nehalam.linuxnetplumber.net>
In-Reply-To: <1326808024-3744-4-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<1326808024-3744-4-git-send-email-wei.liu2@citrix.com>
Organization: Vyatta
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	konrad.wilk@oracle.com, netdev@vger.kernel.org,
	paul.durrant@citrix.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V2 3/8] netback: switch to NAPI +
	kthread model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 17 Jan 2012 13:46:59 +0000
Wei Liu <wei.liu2@citrix.com> wrote:

> This patch implements 1:1 model netback. We utilizes NAPI and kthread
> to do the weight-lifting job:
> 
>   - NAPI is used for guest side TX (host side RX)
>   - kthread is used for guest side RX (host side TX)
> 
> This model provides better scheduling fairness among vifs. It also
> lays the foundation for future work.
> 
> The major defect for the current implementation is that in the NAPI
> poll handler we don't actually disable interrupt. Xen stuff is
> different from real hardware, it requires some other tuning of ring
> macros.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

The network receive processing is sensitive to the context it is run in.
Normally it is run in softirq with interrupts enabled. With your code,
the poll routine disables IRQ's which shouldn't be necessary.

Why does xenvif_receive_skb() need to still exist? Couldn't it
just be replaced with call to netif_receive_skb() in one place it is called.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:08:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:08:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCVY-0004Bc-JO; Tue, 17 Jan 2012 17:07:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <shemminger@vyatta.com>) id 1RnCVX-0004BP-PY
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:07:40 +0000
X-Env-Sender: shemminger@vyatta.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326820053!3859073!1
X-Originating-IP: [76.74.103.46]
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 20099 invoked from network); 17 Jan 2012 17:07:33 -0000
Received: from mail.vyatta.com (HELO mail.vyatta.com) (76.74.103.46)
	by server-8.tower-182.messagelabs.com with SMTP;
	17 Jan 2012 17:07:33 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mail.vyatta.com (Postfix) with ESMTP id A22381410027;
	Tue, 17 Jan 2012 09:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at tahiti.vyatta.com
Received: from mail.vyatta.com ([127.0.0.1])
	by localhost (mail.vyatta.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id f4RTD1Lk4fIL; Tue, 17 Jan 2012 09:07:31 -0800 (PST)
Received: from nehalam.linuxnetplumber.net
	(static-50-53-80-93.bvtn.or.frontiernet.net [50.53.80.93])
	by mail.vyatta.com (Postfix) with ESMTPSA id 7251B1410020;
	Tue, 17 Jan 2012 09:07:31 -0800 (PST)
Date: Tue, 17 Jan 2012 09:07:30 -0800
From: Stephen Hemminger <shemminger@vyatta.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120117090730.13ae3c6e@nehalam.linuxnetplumber.net>
In-Reply-To: <1326808024-3744-4-git-send-email-wei.liu2@citrix.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<1326808024-3744-4-git-send-email-wei.liu2@citrix.com>
Organization: Vyatta
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	konrad.wilk@oracle.com, netdev@vger.kernel.org,
	paul.durrant@citrix.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V2 3/8] netback: switch to NAPI +
	kthread model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 17 Jan 2012 13:46:59 +0000
Wei Liu <wei.liu2@citrix.com> wrote:

> This patch implements 1:1 model netback. We utilizes NAPI and kthread
> to do the weight-lifting job:
> 
>   - NAPI is used for guest side TX (host side RX)
>   - kthread is used for guest side RX (host side TX)
> 
> This model provides better scheduling fairness among vifs. It also
> lays the foundation for future work.
> 
> The major defect for the current implementation is that in the NAPI
> poll handler we don't actually disable interrupt. Xen stuff is
> different from real hardware, it requires some other tuning of ring
> macros.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

The network receive processing is sensitive to the context it is run in.
Normally it is run in softirq with interrupts enabled. With your code,
the poll routine disables IRQ's which shouldn't be necessary.

Why does xenvif_receive_skb() need to still exist? Couldn't it
just be replaced with call to netif_receive_skb() in one place it is called.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:13:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCac-0004QI-BG; Tue, 17 Jan 2012 17:12:54 +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 1RnCaa-0004Q8-Hv
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:12:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326820366!9542297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3680 invoked from network); 17 Jan 2012 17:12: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;
	17 Jan 2012 17:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10093676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 17:12:46 +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;
	Tue, 17 Jan 2012 17:12:46 +0000
Message-ID: <1326820317.5285.13.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 17 Jan 2012 17:11:57 +0000
In-Reply-To: <20120117090730.13ae3c6e@nehalam.linuxnetplumber.net>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<1326808024-3744-4-git-send-email-wei.liu2@citrix.com>
	<20120117090730.13ae3c6e@nehalam.linuxnetplumber.net>
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, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2 3/8] netback: switch to NAPI +
	kthread model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-17 at 17:07 +0000, Stephen Hemminger wrote:
> On Tue, 17 Jan 2012 13:46:59 +0000
> Wei Liu <wei.liu2@citrix.com> wrote:
> 
> > This patch implements 1:1 model netback. We utilizes NAPI and kthread
> > to do the weight-lifting job:
> > 
> >   - NAPI is used for guest side TX (host side RX)
> >   - kthread is used for guest side RX (host side TX)
> > 
> > This model provides better scheduling fairness among vifs. It also
> > lays the foundation for future work.
> > 
> > The major defect for the current implementation is that in the NAPI
> > poll handler we don't actually disable interrupt. Xen stuff is
> > different from real hardware, it requires some other tuning of ring
> > macros.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> The network receive processing is sensitive to the context it is run in.
> Normally it is run in softirq with interrupts enabled. With your code,
> the poll routine disables IRQ's which shouldn't be necessary.
> 

Misunderstanding here. I should rewrite my commit message.

By "disabling interrupt" I mean stop the other end from generating
events, not system wide disabling interrupt.

> Why does xenvif_receive_skb() need to still exist? Couldn't it
> just be replaced with call to netif_receive_skb() in one place it is called.

Sure.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:13:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:13:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCac-0004QI-BG; Tue, 17 Jan 2012 17:12:54 +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 1RnCaa-0004Q8-Hv
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:12:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326820366!9542297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3680 invoked from network); 17 Jan 2012 17:12: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;
	17 Jan 2012 17:12:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10093676"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 17:12:46 +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;
	Tue, 17 Jan 2012 17:12:46 +0000
Message-ID: <1326820317.5285.13.camel@liuw-desktop>
From: Wei Liu <wei.liu2@citrix.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 17 Jan 2012 17:11:57 +0000
In-Reply-To: <20120117090730.13ae3c6e@nehalam.linuxnetplumber.net>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<1326808024-3744-4-git-send-email-wei.liu2@citrix.com>
	<20120117090730.13ae3c6e@nehalam.linuxnetplumber.net>
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, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2 3/8] netback: switch to NAPI +
	kthread model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-17 at 17:07 +0000, Stephen Hemminger wrote:
> On Tue, 17 Jan 2012 13:46:59 +0000
> Wei Liu <wei.liu2@citrix.com> wrote:
> 
> > This patch implements 1:1 model netback. We utilizes NAPI and kthread
> > to do the weight-lifting job:
> > 
> >   - NAPI is used for guest side TX (host side RX)
> >   - kthread is used for guest side RX (host side TX)
> > 
> > This model provides better scheduling fairness among vifs. It also
> > lays the foundation for future work.
> > 
> > The major defect for the current implementation is that in the NAPI
> > poll handler we don't actually disable interrupt. Xen stuff is
> > different from real hardware, it requires some other tuning of ring
> > macros.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> The network receive processing is sensitive to the context it is run in.
> Normally it is run in softirq with interrupts enabled. With your code,
> the poll routine disables IRQ's which shouldn't be necessary.
> 

Misunderstanding here. I should rewrite my commit message.

By "disabling interrupt" I mean stop the other end from generating
events, not system wide disabling interrupt.

> Why does xenvif_receive_skb() need to still exist? Couldn't it
> just be replaced with call to netif_receive_skb() in one place it is called.

Sure.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:16:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17: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 1RnCeA-0004aS-3f; Tue, 17 Jan 2012 17:16:34 +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 1RnCe8-0004Zs-Ed
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:16:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326820584!7685929!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21314 invoked from network); 17 Jan 2012 17:16:26 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 17:16:26 -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
	q0HHFMl2023627
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 17:15:23 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
	q0HHFJk7013982
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 17:15:21 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0HHFGAe014071; Tue, 17 Jan 2012 11:15:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 09:15:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5A75540316; Tue, 17 Jan 2012 12:13:14 -0500 (EST)
Date: Tue, 17 Jan 2012 12:13:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120117171314.GB5494@phenom.dumpdata.com>
References: <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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
	<20120113222451.GA6922@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F15ACAC.0076,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@citrix.com" <Ian.Campbell@citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>, "Nakajima,
	Jun" <jun.nakajima@intel.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 <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.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

> > I was trying to figure out how difficult it would be to just bring Pxx states to
> > the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
> > all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
> > be enabled in the hypercall to make this work), it demonstrates what I had in
> > mind. 

.. snip..
> > 	/* TODO: Under Xen, the C-states information is not present.
> >  	 * Figure out why. */
> 
> it's possible related to this long thread:
> 
> http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html
> 
> IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
> Final solution is to have a para-virtualized PDC call for that.

Aaah. Let me play with that a bit. Thanks for the pointer.

.. snip..
> the prerequisites for this module to work correctly, is that dom0 has the right
> configurations to have all necessary Cx/Px information ready before this 
> module is loaded. That may mean enabling full CONFIG_CPU_IDLE and CONFIG_CPUFREQ,

Right.
> which in current form may add some negative impact, e.g. dom0 will try to control
> Px/Cx to conflict with Xen. So some tweaks may be required in that part.

Yup. Hadn't even looked at the cpufreq tries to do yet.
> 
> given our purpose now, is to come up a cleaner approach which tolerate some
> assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
> trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
> xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
> mainly two roles:
> 	- a dummy driver to prevent dom0 touching actual Px/Cx
> 	- parse ACPI Cx/Px information to Xen, in a similar way you did above

Yeah, I like where you are heading.
> 
> there may have some other trickiness, but the majority code will be self-contained.

<nods>
> 
> Thanks
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:16:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17: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 1RnCeA-0004aS-3f; Tue, 17 Jan 2012 17:16:34 +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 1RnCe8-0004Zs-Ed
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:16:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326820584!7685929!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21314 invoked from network); 17 Jan 2012 17:16:26 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 17:16:26 -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
	q0HHFMl2023627
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 17:15:23 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
	q0HHFJk7013982
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 17:15:21 GMT
Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0HHFGAe014071; Tue, 17 Jan 2012 11:15:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 09:15:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 5A75540316; Tue, 17 Jan 2012 12:13:14 -0500 (EST)
Date: Tue, 17 Jan 2012 12:13:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120117171314.GB5494@phenom.dumpdata.com>
References: <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>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
	<20120113222451.GA6922@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F15ACAC.0076,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@citrix.com" <Ian.Campbell@citrix.com>,
	"konrad@kernel.org" <konrad@kernel.org>, "Nakajima,
	Jun" <jun.nakajima@intel.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 <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.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

> > I was trying to figure out how difficult it would be to just bring Pxx states to
> > the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
> > all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
> > be enabled in the hypercall to make this work), it demonstrates what I had in
> > mind. 

.. snip..
> > 	/* TODO: Under Xen, the C-states information is not present.
> >  	 * Figure out why. */
> 
> it's possible related to this long thread:
> 
> http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html
> 
> IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
> Final solution is to have a para-virtualized PDC call for that.

Aaah. Let me play with that a bit. Thanks for the pointer.

.. snip..
> the prerequisites for this module to work correctly, is that dom0 has the right
> configurations to have all necessary Cx/Px information ready before this 
> module is loaded. That may mean enabling full CONFIG_CPU_IDLE and CONFIG_CPUFREQ,

Right.
> which in current form may add some negative impact, e.g. dom0 will try to control
> Px/Cx to conflict with Xen. So some tweaks may be required in that part.

Yup. Hadn't even looked at the cpufreq tries to do yet.
> 
> given our purpose now, is to come up a cleaner approach which tolerate some
> assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
> trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
> xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
> mainly two roles:
> 	- a dummy driver to prevent dom0 touching actual Px/Cx
> 	- parse ACPI Cx/Px information to Xen, in a similar way you did above

Yeah, I like where you are heading.
> 
> there may have some other trickiness, but the majority code will be self-contained.

<nods>
> 
> Thanks
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:32:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:32:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCt1-000512-Oy; Tue, 17 Jan 2012 17:31:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnCt0-00050b-5v
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:31:54 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326821506!11225523!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1077 invoked from network); 17 Jan 2012 17:31:47 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 17:31:47 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HHVjR5005556
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 12:31:45 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 12:31:29 -0500
MIME-Version: 1.0
X-Mercurial-Node: eb59afed10a66ee6837f3b19c417682295afe2c6
Message-Id: <eb59afed10a66ee6837f.1326821189@mnetdjm4.mageenet.host>
In-Reply-To: <patchbomb.1326821188@mnetdjm4.mageenet.host>
References: <patchbomb.1326821188@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 12:26:29 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 17:31:29.0592 (UTC)
	FILETIME=[D8EB4380:01CCD53D]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl_pci: rename is_assigned to
	is_pcidev_in_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

All this function does is check to see if a device is in an array of pcidevs passed by the caller.  The function name can be misleading if ever used to check against a list of devices other than those assigned to a domain.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r 5b2676ac1321 -r eb59afed10a6 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Tue Jan 17 12:20:09 2012 -0500
@@ -461,7 +461,7 @@ static int get_all_assigned_devices(libx
     return 0;
 }
 
-static int is_assigned(libxl_device_pci *assigned, int num_assigned,
+static int is_pcidev_in_array(libxl_device_pci *assigned, int num_assigned,
                        int dom, int bus, int dev, int func)
 {
     int i;
@@ -510,7 +510,7 @@ libxl_device_pci *libxl_device_pci_list_
         if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
             continue;
 
-        if ( is_assigned(assigned, num_assigned, dom, bus, dev, func) )
+        if ( is_pcidev_in_array(assigned, num_assigned, dom, bus, dev, func) )
             continue;
 
         new = realloc(pcidevs, ((*num) + 1) * sizeof(*new));
@@ -802,7 +802,7 @@ int libxl__device_pci_add(libxl__gc *gc,
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
         goto out;
     }
-    if ( is_assigned(assigned, num_assigned, pcidev->domain,
+    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
                      pcidev->bus, pcidev->dev, pcidev->func) ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
         rc = ERROR_FAIL;
@@ -906,7 +906,7 @@ static int do_pci_remove(libxl__gc *gc, 
         return ERROR_FAIL;
 
     rc = ERROR_INVAL;
-    if ( !is_assigned(assigned, num, pcidev->domain,
+    if ( !is_pcidev_in_array(assigned, num, pcidev->domain,
                       pcidev->bus, pcidev->dev, pcidev->func) ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not attached to this domain");
         goto out_fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:32:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:32:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCt1-000512-Oy; Tue, 17 Jan 2012 17:31:55 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnCt0-00050b-5v
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:31:54 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326821506!11225523!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1077 invoked from network); 17 Jan 2012 17:31:47 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-15.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 17:31:47 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HHVjR5005556
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 12:31:45 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 12:31:29 -0500
MIME-Version: 1.0
X-Mercurial-Node: eb59afed10a66ee6837f3b19c417682295afe2c6
Message-Id: <eb59afed10a66ee6837f.1326821189@mnetdjm4.mageenet.host>
In-Reply-To: <patchbomb.1326821188@mnetdjm4.mageenet.host>
References: <patchbomb.1326821188@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 12:26:29 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 17:31:29.0592 (UTC)
	FILETIME=[D8EB4380:01CCD53D]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl_pci: rename is_assigned to
	is_pcidev_in_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

All this function does is check to see if a device is in an array of pcidevs passed by the caller.  The function name can be misleading if ever used to check against a list of devices other than those assigned to a domain.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r 5b2676ac1321 -r eb59afed10a6 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Tue Jan 17 12:20:09 2012 -0500
@@ -461,7 +461,7 @@ static int get_all_assigned_devices(libx
     return 0;
 }
 
-static int is_assigned(libxl_device_pci *assigned, int num_assigned,
+static int is_pcidev_in_array(libxl_device_pci *assigned, int num_assigned,
                        int dom, int bus, int dev, int func)
 {
     int i;
@@ -510,7 +510,7 @@ libxl_device_pci *libxl_device_pci_list_
         if ( sscanf(de->d_name, PCI_BDF, &dom, &bus, &dev, &func) != 4 )
             continue;
 
-        if ( is_assigned(assigned, num_assigned, dom, bus, dev, func) )
+        if ( is_pcidev_in_array(assigned, num_assigned, dom, bus, dev, func) )
             continue;
 
         new = realloc(pcidevs, ((*num) + 1) * sizeof(*new));
@@ -802,7 +802,7 @@ int libxl__device_pci_add(libxl__gc *gc,
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
         goto out;
     }
-    if ( is_assigned(assigned, num_assigned, pcidev->domain,
+    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
                      pcidev->bus, pcidev->dev, pcidev->func) ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
         rc = ERROR_FAIL;
@@ -906,7 +906,7 @@ static int do_pci_remove(libxl__gc *gc, 
         return ERROR_FAIL;
 
     rc = ERROR_INVAL;
-    if ( !is_assigned(assigned, num, pcidev->domain,
+    if ( !is_pcidev_in_array(assigned, num, pcidev->domain,
                       pcidev->bus, pcidev->dev, pcidev->func) ) {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device not attached to this domain");
         goto out_fail;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:32:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:32:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCsz-00050g-Vy; Tue, 17 Jan 2012 17:31:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnCsz-00050W-88
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:31:53 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326821448!57302076!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32047 invoked from network); 17 Jan 2012 17:30:49 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 17:30:49 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HHVjTf005552
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 12:31:45 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 12:31:29 -0500
MIME-Version: 1.0
Message-Id: <patchbomb.1326821188@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 12:26:28 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 17:31:29.0155 (UTC)
	FILETIME=[D8A89530:01CCD53D]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl_pci: verify device is assignable,
 rename misleading function (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 series contains one patch that changes the behavior of 
libxl__device_pci_add to verify the device is properly assignable.  There's also
a patch that renames a function so it's not misleading.

This second version explicitly frees the values returned by 
libxl_device_pci_list_assignable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:32:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:32:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCsz-00050g-Vy; Tue, 17 Jan 2012 17:31:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnCsz-00050W-88
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:31:53 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326821448!57302076!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32047 invoked from network); 17 Jan 2012 17:30:49 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 17:30:49 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HHVjTf005552
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 12:31:45 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 12:31:29 -0500
MIME-Version: 1.0
Message-Id: <patchbomb.1326821188@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 12:26:28 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 17:31:29.0155 (UTC)
	FILETIME=[D8A89530:01CCD53D]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl_pci: verify device is assignable,
 rename misleading function (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 series contains one patch that changes the behavior of 
libxl__device_pci_add to verify the device is properly assignable.  There's also
a patch that renames a function so it's not misleading.

This second version explicitly frees the values returned by 
libxl_device_pci_list_assignable.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:32:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCt1-00050v-Cz; Tue, 17 Jan 2012 17:31:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnCt0-00050a-2Y
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:31:54 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326821506!11444570!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8518 invoked from network); 17 Jan 2012 17:31:47 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 17:31:47 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HHVkB1005560
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 12:31:46 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 12:31:29 -0500
MIME-Version: 1.0
X-Mercurial-Node: 6a3f270992ebb15b7ea436c30326aaff559ee2ab
Message-Id: <6a3f270992ebb15b7ea4.1326821190@mnetdjm4.mageenet.host>
In-Reply-To: <patchbomb.1326821188@mnetdjm4.mageenet.host>
References: <patchbomb.1326821188@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 12:26:30 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 17:31:30.0029 (UTC)
	FILETIME=[D92DF1D0:01CCD53D]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is assignable
 before adding to 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

Previously, libxl__device_pci_add only checked the device to be added against
the list of currently assigned devices.  This patch changes the behavior to
check that the device to be assigned is in the list of assignable devices,
which only includes those owned by pciback and not assigned to another domain.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r eb59afed10a6 -r 6a3f270992eb tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Tue Jan 17 12:20:09 2012 -0500
+++ b/tools/libxl/libxl_pci.c	Tue Jan 17 12:24:07 2012 -0500
@@ -793,18 +793,15 @@ int libxl__device_pci_add(libxl__gc *gc,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     unsigned int orig_vdev, pfunc_mask;
-    libxl_device_pci *assigned;
-    int num_assigned, i, rc;
+    libxl_device_pci *assignable;
+    int num_assignable, i, rc;
     int stubdomid = 0;
 
-    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
-    if ( rc ) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
-        goto out;
-    }
-    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
+    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);
+
+    if ( !is_pcidev_in_array(assignable, num_assignable, pcidev->domain,
                      pcidev->bus, pcidev->dev, pcidev->func) ) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device is either assigned to another domain, or not owned by pciback");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -856,6 +853,9 @@ int libxl__device_pci_add(libxl__gc *gc,
     }
 
 out:
+    for ( i = 0; i < num_assignable; i++ )
+        libxl_device_pci_dispose(&assignable[i]);
+    free(assignable);
     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 Jan 17 17:32:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:32:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCt1-00050v-Cz; Tue, 17 Jan 2012 17:31:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnCt0-00050a-2Y
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:31:54 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-216.messagelabs.com!1326821506!11444570!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8518 invoked from network); 17 Jan 2012 17:31:47 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 17:31:47 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HHVkB1005560
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 12:31:46 -0500
Received: from mnetdjm4.mageenet.host ([172.16.21.62]) by mnetweb5 with
	Microsoft SMTPSVC(7.5.7600.16601); Tue, 17 Jan 2012 12:31:29 -0500
MIME-Version: 1.0
X-Mercurial-Node: 6a3f270992ebb15b7ea436c30326aaff559ee2ab
Message-Id: <6a3f270992ebb15b7ea4.1326821190@mnetdjm4.mageenet.host>
In-Reply-To: <patchbomb.1326821188@mnetdjm4.mageenet.host>
References: <patchbomb.1326821188@mnetdjm4.mageenet.host>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Tue, 17 Jan 2012 12:26:30 -0500
From: Doug Magee <djmagee@mageenet.net>
To: xen-devel@lists.xensource.com
X-OriginalArrivalTime: 17 Jan 2012 17:31:30.0029 (UTC)
	FILETIME=[D92DF1D0:01CCD53D]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] libxl_pci: verify device is assignable
 before adding to 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

Previously, libxl__device_pci_add only checked the device to be added against
the list of currently assigned devices.  This patch changes the behavior to
check that the device to be assigned is in the list of assignable devices,
which only includes those owned by pciback and not assigned to another domain.

Signed-off-by: Doug Magee <djmagee@mageenet.net>

diff -r eb59afed10a6 -r 6a3f270992eb tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Tue Jan 17 12:20:09 2012 -0500
+++ b/tools/libxl/libxl_pci.c	Tue Jan 17 12:24:07 2012 -0500
@@ -793,18 +793,15 @@ int libxl__device_pci_add(libxl__gc *gc,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     unsigned int orig_vdev, pfunc_mask;
-    libxl_device_pci *assigned;
-    int num_assigned, i, rc;
+    libxl_device_pci *assignable;
+    int num_assignable, i, rc;
     int stubdomid = 0;
 
-    rc = get_all_assigned_devices(gc, &assigned, &num_assigned);
-    if ( rc ) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "cannot determine if device is assigned, refusing to continue");
-        goto out;
-    }
-    if ( is_pcidev_in_array(assigned, num_assigned, pcidev->domain,
+    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);
+
+    if ( !is_pcidev_in_array(assignable, num_assignable, pcidev->domain,
                      pcidev->bus, pcidev->dev, pcidev->func) ) {
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device is either assigned to another domain, or not owned by pciback");
         rc = ERROR_FAIL;
         goto out;
     }
@@ -856,6 +853,9 @@ int libxl__device_pci_add(libxl__gc *gc,
     }
 
 out:
+    for ( i = 0; i < num_assignable; i++ )
+        libxl_device_pci_dispose(&assignable[i]);
+    free(assignable);
     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 Jan 17 17:38:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCyZ-0005Rc-K4; Tue, 17 Jan 2012 17:37:39 +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 1RnCyX-0005RR-8G
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:37:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326821850!9058423!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28560 invoked from network); 17 Jan 2012 17:37:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 17:37:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10094265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 17:37:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 17:37:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnCy9-0006MI-Ve;
	Tue, 17 Jan 2012 17:37:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnCy9-0003z8-Qd;
	Tue, 17 Jan 2012 17:37:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10790-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 17:37:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10790: 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 10790 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10790/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            9 guest-start               fail REGR. vs. 10769
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 10769

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 10769
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10769
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass

version targeted for testing:
 xen                  271e30252c16
baseline version:
 xen                  d5b26918cd94

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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:   21560:271e30252c16
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:35:30 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
changeset:   21559:75007e524cd8
user:        David Vrabel <david.vrabel@citrix.com>
date:        Tue Jan 17 11:35:03 2012 +0000
    
    x86: emulate lea with two register operands correctly
    
    An lea instruction with two register operands should raise an
    undefined instruction exception.
    
    Skype does such a instruction and will crash when starting if it does
    not get the exception.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24456:03781de56c31
    xen-unstable date:        Thu Jan 05 15:47:16 2012 +0000
    
    
changeset:   21558:3f7117070ba1
user:        Yongan Liu <Liuyongan@huawei.com>
date:        Tue Jan 17 11:34:43 2012 +0000
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24453:02b92d035f64
    xen-unstable date:        Thu Jan 05 09:29:59 2012 +0100
    
    
changeset:   21557:d5b26918cd94
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:54 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
    
    
(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 Tue Jan 17 17:38:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnCyZ-0005Rc-K4; Tue, 17 Jan 2012 17:37:39 +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 1RnCyX-0005RR-8G
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:37:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326821850!9058423!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28560 invoked from network); 17 Jan 2012 17:37:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 17:37:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10094265"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 17:37:14 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 17:37:14 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnCy9-0006MI-Ve;
	Tue, 17 Jan 2012 17:37:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnCy9-0003z8-Qd;
	Tue, 17 Jan 2012 17:37:13 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10790-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 17:37:13 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10790: 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 10790 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10790/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl            9 guest-start               fail REGR. vs. 10769
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 10769

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  5 xen-boot                  fail REGR. vs. 10769
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10769
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass

version targeted for testing:
 xen                  271e30252c16
baseline version:
 xen                  d5b26918cd94

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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:   21560:271e30252c16
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:35:30 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
changeset:   21559:75007e524cd8
user:        David Vrabel <david.vrabel@citrix.com>
date:        Tue Jan 17 11:35:03 2012 +0000
    
    x86: emulate lea with two register operands correctly
    
    An lea instruction with two register operands should raise an
    undefined instruction exception.
    
    Skype does such a instruction and will crash when starting if it does
    not get the exception.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24456:03781de56c31
    xen-unstable date:        Thu Jan 05 15:47:16 2012 +0000
    
    
changeset:   21558:3f7117070ba1
user:        Yongan Liu <Liuyongan@huawei.com>
date:        Tue Jan 17 11:34:43 2012 +0000
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24453:02b92d035f64
    xen-unstable date:        Thu Jan 05 09:29:59 2012 +0100
    
    
changeset:   21557:d5b26918cd94
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:54 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
    
    
(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 Tue Jan 17 17:54:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17: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 1RnDEo-0005o8-9Q; Tue, 17 Jan 2012 17:54:26 +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 1RnDEm-0005o2-Uu
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:54:25 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326822842!49145696!1
X-Originating-IP: [213.199.154.209]
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 23519 invoked from network); 17 Jan 2012 17:54:02 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Jan 2012 17:54:02 -0000
Received: from mail68-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 17 Jan 2012 17:54:17 +0000
Received: from mail68-am1 (localhost [127.0.0.1])	by mail68-am1-R.bigfish.com
	(Postfix) with ESMTP id 16A8F4C04FE;
	Tue, 17 Jan 2012 17:54:13 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI1102K1432N98dKzz1202hzz8275bhz2dhc1ahc1bh668h839h)
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-am1 (localhost.localdomain [127.0.0.1]) by mail68-am1
	(MessageSwitch) id 1326822852767635_27224;
	Tue, 17 Jan 2012 17:54:12 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.249])	by
	mail68-am1.bigfish.com (Postfix) with ESMTP id ABA7F2C006F;
	Tue, 17 Jan 2012 17:54:12 +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; Tue, 17 Jan 2012 17:54:12 +0000
X-WSS-ID: 0LXYF2F-01-HTZ-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 2674E1028066;	Tue, 17 Jan 2012 11:54:14 -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, 17 Jan 2012 11:54:24 -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;
	Tue, 17 Jan 2012 11:54:15 -0600
Message-ID: <4F15B5C6.6070808@amd.com>
Date: Tue, 17 Jan 2012 12:54:14 -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: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
In-Reply-To: <4F153EBA020000780006D248@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Responses inline.

On 01/17/12 03:26, Jan Beulich wrote:
>>>> On 16.01.12 at 22:11, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> --- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>>                       bitmaskof(X86_FEATURE_SSE4A) |
>>                       bitmaskof(X86_FEATURE_MISALIGNSSE) |
>>                       bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
>> +		    bitmaskof(X86_FEATURE_OSVW) |
>
> Indentation.
>
> Also, is this really meaningful to PV guests?

Does amd_xc_cpuid_policy() get called for PV guests? I thought this is 
HVM path only.

xc_cpuid_pv_policy() is where clear_bit(X86_FEATURE_OSVW, regs[2]) was 
removed to handle PV.

I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum 
400 as an example -- we don't need a Linux PV guest reading an MSR 
before going to idle (in amd_e400_idle()).

> And valid for pre-Fam10?

No, it indeed shouldn't be set in those cases.

I could set the bit conditionally, based on host family but the trouble 
is I don't necessarily know what family the guest will be. Or is this 
known at this point?

>
>>                       bitmaskof(X86_FEATURE_XOP) |
>>                       bitmaskof(X86_FEATURE_FMA4) |
>>                       bitmaskof(X86_FEATURE_TBM) |
>> --- a/xen/arch/x86/cpu/amd.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/xen/arch/x86/cpu/amd.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -32,6 +32,13 @@
>>   static char opt_famrev[14];
>>   string_param("cpuid_mask_cpu", opt_famrev);
>>
>> +/*
>> + * Set osvw_len to higher number when updated Revision Guides
>> + * are published and we know what the new status bits are
>> + */
>
> This is ugly, as it requires permanent attention. The value to start
> with should really be 64 (beyond which other code adjustments are
> going to be necessary anyway).

I went back and forth on this. The reason I settled on 4 is because we 
obviously don't know what errata the higher bits will cover and because 
it is (at least theoretically) possible that a guest shouldn't see the 
same status bits as the host.

But maybe code maintenance is more burden than it's worth?

>
>> +static uint64_t osvw_length = 4, osvw_status;
>> +static DEFINE_SPINLOCK(amd_lock);
>> +
>>   static inline void wrmsr_amd(unsigned int index, unsigned int lo,
>>   		unsigned int hi)
>>   {
>> @@ -182,6 +189,35 @@ static void __devinit set_cpuidmask(cons
>>   	}
>>   }
>>
>> +static void amd_guest_osvw_init(struct vcpu *vcpu)
>> +{
>> +    if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
>> +	return;
>
> Shouldn't we bail here for pre-Fam10 CPUs too?

As you noted below the vendor check should be removed anyway since this 
is being called from under such a check already.

As for family --- I think I need to solve how X86_FEATURE_OSVW is set 
and that will take care of whether anything that gets initialized in 
this routine is ever used.

>
> Further, as asked above already - is all this really meaningful to PV
> guests? Otherwise the code would better go somewhere under
> xen/arch/x86/hvm/svm/ ...
>
> Also, throughout this file indentation needs to be changed to Linux
> style (tabs instead of spaces), unless you want to contribute a patch
> to convert the whole file to Xen style (in which case you'd still need
> to make adjustments here).
>
>> +
>> +    /*
>> +     * Guests should see errata 400 and 415 as fixed (assuming that
>> +     * HLT and IO instructions are intercepted).
>> +     */
>> +    vcpu->arch.amd.osvw.length = (osvw_length>= 3) ? (osvw_length) : 3;
>
> An expression consisting of just an identifier for sure doesn't need
> parentheses.
>
>> +    vcpu->arch.amd.osvw.status = osvw_status&  ~(6ULL);
>> +
>> +    /*
>> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
>> +     * all osvw.status bits inside that length, including bit 0 (which is
>> +     * reserved for erratum 298), are valid. However, if host processor's
>> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
>> +     * be conservative here and therefore we tell the guest that erratum 298
>> +     * is present (because we really don't know).
>> +     */
>> +    if (osvw_length == 0&&  boot_cpu_data.x86 == 0x10)
>
> Why do you check the family here? If osvw_length can only ever be
> zero on Fam10, then the first check is sufficient. If osvw_length can
> be zero on other than Fam10 (no matter whether we bail early older
> CPUs), then the check is actually wrong.

10h is the only family affected by this erratum.

>
>> +	vcpu->arch.amd.osvw.status |= 1;
>> +}
>> +
>> +void amd_vcpu_initialise(struct vcpu *vcpu)
>> +{
>> +    amd_guest_osvw_init(vcpu);
>> +}
>> +
>>   /*
>>    * Check for the presence of an AMD erratum. Arguments are defined in amd.h
>>
>>    * for each known erratum. Return 1 if erratum is found.
>> @@ -512,6 +548,30 @@ static void __devinit init_amd(struct cp
>>   	set_cpuidmask(c);
>>
>>   	check_syscfg_dram_mod_en();
>> +
>> +    /*
>> +     * Get OSVW bits. If bits are not the same on different processors then
>> +     * choose the worst case (i.e. if erratum is present on one processor and
>> +     * not on another assume that the erratum is present everywhere).
>> +     */
>> +     if (test_bit(X86_FEATURE_OSVW,&boot_cpu_data.x86_capability)) {
>> +         uint64_t len, status;
>> +
>> +        if (rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
>> +            rdmsr_safe(MSR_AMD_OSVW_STATUS, status))
>> +            len = status = 0;
>> +
>> +        spin_lock(&amd_lock);
>
> What is the locking here supposed to protect against? The AP call tree
> is smp_callin() ->  identify_cpu() ->  init_amd(), which cannot race with
> anything (as the initiating processor is waiting for cpu_state to change
> to CPU_STATE_CALLIN).
>
>> +
>> +        if (len<  osvw_length)
>> +            osvw_length = len;
>> +
>> +        osvw_status |= status;
>> +        osvw_status&= (1ULL<<  osvw_length) - 1;
>> +
>> +        spin_unlock(&amd_lock);
>> +    } else
>> +	 osvw_length = osvw_status = 0;
>>   }
>>
>>   static struct cpu_dev amd_cpu_dev __cpuinitdata = {
>> --- a/xen/arch/x86/domain.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/xen/arch/x86/domain.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -422,6 +422,10 @@ int vcpu_initialise(struct vcpu *v)
>>       if ( (rc = vcpu_init_fpu(v)) != 0 )
>>           return rc;
>>
>> +    /* Vendor-specific initialization */
>> +    if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
>
> If you check the vendor here, you don't need to anywhere in the
> descendant functions.
>
>> +        amd_vcpu_initialise(v);
>> +
>>       if ( is_hvm_domain(d) )
>>       {
>>           rc = hvm_vcpu_initialise(v);
>> --- a/xen/arch/x86/hvm/svm/svm.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/xen/arch/x86/hvm/svm/svm.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -1044,6 +1044,27 @@ static void svm_init_erratum_383(struct
>>       }
>>   }
>>
>> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, uint read)
>> +{
>> +    uint eax, ebx, ecx, edx;
>> +
>> +    /* Guest OSVW support */
>> +    hvm_cpuid(0x80000001,&eax,&ebx,&ecx,&edx);
>> +    if (!test_bit((X86_FEATURE_OSVW&  31),&ecx))
>
> Formatting of changes to this file should be changed to Xen style.
>
>> +        return -1;
>> +
>> +    if (read) {
>> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
>> +            *val = v->arch.amd.osvw.length;
>> +        else
>> +            *val = v->arch.amd.osvw.status;
>> +    }
>> +    /* Writes are ignored */
>> +
>> +    return 0;
>> +}
>> +
>> +
>>   static int svm_cpu_up(void)
>>   {
>>       uint64_t msr_content;
>> --- a/xen/arch/x86/traps.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/xen/arch/x86/traps.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -2542,6 +2542,15 @@ static int emulate_privileged_op(struct
>>               if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
>>                   goto fail;
>>               break;
>> +        case MSR_AMD_OSVW_ID_LENGTH:
>> +        case MSR_AMD_OSVW_STATUS:
>> +            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) {
>> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
>> +                    goto fail;
>> +                else
>
> Bogus "else" after a "goto". And I wonder, provided there is some
> point in doing all this for PV guests in the first place, whether this
> shouldn't be kept getting handled by the default case.


If we go into default case we will emit "Domain attempted WRMSR ..." 
message in the log. I was trying to avoid that since writing to these 
registers is not really an error, it just gets ignored.

I'll fix the rest.

Thanks for review.
-boris

>
>> +                    break; /* Writes are ignored */
>> +            }
>> +            /* Fall through to default case */
>>           default:
>>               if ( wrmsr_hypervisor_regs(regs->ecx, msr_content) )
>>                   break;
>> @@ -2573,6 +2582,7 @@ static int emulate_privileged_op(struct
>>           break;
>>
>>       case 0x32: /* RDMSR */
>> +
>
> Stray addition of a newline.
>
>>           switch ( (u32)regs->ecx )
>>           {
>>   #ifdef CONFIG_X86_64
>> @@ -2632,6 +2642,23 @@ static int emulate_privileged_op(struct
>>               regs->eax = (uint32_t)msr_content;
>>               regs->edx = (uint32_t)(msr_content>>  32);
>>               break;
>> +        case MSR_AMD_OSVW_ID_LENGTH:
>> +        case MSR_AMD_OSVW_STATUS:
>> +            if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
>> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
>> +                    goto fail;
>> +                else {
>
> Bogus "else" after a "goto".
>
> Jan
>
>> +                    if ((u32)regs->ecx == MSR_AMD_OSVW_ID_LENGTH)
>> +                        msr_content = v->arch.amd.osvw.length;
>> +                    else
>> +                        msr_content = v->arch.amd.osvw.status;
>> +
>> +                    regs->eax = (uint32_t)msr_content;
>> +                    regs->edx = (uint32_t)(msr_content>>  32);
>> +                }
>> +            } else
>> +                goto rdmsr_normal;
>> +            break;
>>           default:
>>               if ( rdmsr_hypervisor_regs(regs->ecx,&val) )
>>               {
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 17:54:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 17: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 1RnDEo-0005o8-9Q; Tue, 17 Jan 2012 17:54:26 +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 1RnDEm-0005o2-Uu
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:54:25 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326822842!49145696!1
X-Originating-IP: [213.199.154.209]
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 23519 invoked from network); 17 Jan 2012 17:54:02 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	17 Jan 2012 17:54:02 -0000
Received: from mail68-am1-R.bigfish.com (10.3.201.245) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 17 Jan 2012 17:54:17 +0000
Received: from mail68-am1 (localhost [127.0.0.1])	by mail68-am1-R.bigfish.com
	(Postfix) with ESMTP id 16A8F4C04FE;
	Tue, 17 Jan 2012 17:54:13 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI1102K1432N98dKzz1202hzz8275bhz2dhc1ahc1bh668h839h)
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-am1 (localhost.localdomain [127.0.0.1]) by mail68-am1
	(MessageSwitch) id 1326822852767635_27224;
	Tue, 17 Jan 2012 17:54:12 +0000 (UTC)
Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.249])	by
	mail68-am1.bigfish.com (Postfix) with ESMTP id ABA7F2C006F;
	Tue, 17 Jan 2012 17:54:12 +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; Tue, 17 Jan 2012 17:54:12 +0000
X-WSS-ID: 0LXYF2F-01-HTZ-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 2674E1028066;	Tue, 17 Jan 2012 11:54:14 -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, 17 Jan 2012 11:54:24 -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;
	Tue, 17 Jan 2012 11:54:15 -0600
Message-ID: <4F15B5C6.6070808@amd.com>
Date: Tue, 17 Jan 2012 12:54:14 -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: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
In-Reply-To: <4F153EBA020000780006D248@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Responses inline.

On 01/17/12 03:26, Jan Beulich wrote:
>>>> On 16.01.12 at 22:11, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> --- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>>                       bitmaskof(X86_FEATURE_SSE4A) |
>>                       bitmaskof(X86_FEATURE_MISALIGNSSE) |
>>                       bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
>> +		    bitmaskof(X86_FEATURE_OSVW) |
>
> Indentation.
>
> Also, is this really meaningful to PV guests?

Does amd_xc_cpuid_policy() get called for PV guests? I thought this is 
HVM path only.

xc_cpuid_pv_policy() is where clear_bit(X86_FEATURE_OSVW, regs[2]) was 
removed to handle PV.

I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum 
400 as an example -- we don't need a Linux PV guest reading an MSR 
before going to idle (in amd_e400_idle()).

> And valid for pre-Fam10?

No, it indeed shouldn't be set in those cases.

I could set the bit conditionally, based on host family but the trouble 
is I don't necessarily know what family the guest will be. Or is this 
known at this point?

>
>>                       bitmaskof(X86_FEATURE_XOP) |
>>                       bitmaskof(X86_FEATURE_FMA4) |
>>                       bitmaskof(X86_FEATURE_TBM) |
>> --- a/xen/arch/x86/cpu/amd.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/xen/arch/x86/cpu/amd.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -32,6 +32,13 @@
>>   static char opt_famrev[14];
>>   string_param("cpuid_mask_cpu", opt_famrev);
>>
>> +/*
>> + * Set osvw_len to higher number when updated Revision Guides
>> + * are published and we know what the new status bits are
>> + */
>
> This is ugly, as it requires permanent attention. The value to start
> with should really be 64 (beyond which other code adjustments are
> going to be necessary anyway).

I went back and forth on this. The reason I settled on 4 is because we 
obviously don't know what errata the higher bits will cover and because 
it is (at least theoretically) possible that a guest shouldn't see the 
same status bits as the host.

But maybe code maintenance is more burden than it's worth?

>
>> +static uint64_t osvw_length = 4, osvw_status;
>> +static DEFINE_SPINLOCK(amd_lock);
>> +
>>   static inline void wrmsr_amd(unsigned int index, unsigned int lo,
>>   		unsigned int hi)
>>   {
>> @@ -182,6 +189,35 @@ static void __devinit set_cpuidmask(cons
>>   	}
>>   }
>>
>> +static void amd_guest_osvw_init(struct vcpu *vcpu)
>> +{
>> +    if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
>> +	return;
>
> Shouldn't we bail here for pre-Fam10 CPUs too?

As you noted below the vendor check should be removed anyway since this 
is being called from under such a check already.

As for family --- I think I need to solve how X86_FEATURE_OSVW is set 
and that will take care of whether anything that gets initialized in 
this routine is ever used.

>
> Further, as asked above already - is all this really meaningful to PV
> guests? Otherwise the code would better go somewhere under
> xen/arch/x86/hvm/svm/ ...
>
> Also, throughout this file indentation needs to be changed to Linux
> style (tabs instead of spaces), unless you want to contribute a patch
> to convert the whole file to Xen style (in which case you'd still need
> to make adjustments here).
>
>> +
>> +    /*
>> +     * Guests should see errata 400 and 415 as fixed (assuming that
>> +     * HLT and IO instructions are intercepted).
>> +     */
>> +    vcpu->arch.amd.osvw.length = (osvw_length>= 3) ? (osvw_length) : 3;
>
> An expression consisting of just an identifier for sure doesn't need
> parentheses.
>
>> +    vcpu->arch.amd.osvw.status = osvw_status&  ~(6ULL);
>> +
>> +    /*
>> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
>> +     * all osvw.status bits inside that length, including bit 0 (which is
>> +     * reserved for erratum 298), are valid. However, if host processor's
>> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
>> +     * be conservative here and therefore we tell the guest that erratum 298
>> +     * is present (because we really don't know).
>> +     */
>> +    if (osvw_length == 0&&  boot_cpu_data.x86 == 0x10)
>
> Why do you check the family here? If osvw_length can only ever be
> zero on Fam10, then the first check is sufficient. If osvw_length can
> be zero on other than Fam10 (no matter whether we bail early older
> CPUs), then the check is actually wrong.

10h is the only family affected by this erratum.

>
>> +	vcpu->arch.amd.osvw.status |= 1;
>> +}
>> +
>> +void amd_vcpu_initialise(struct vcpu *vcpu)
>> +{
>> +    amd_guest_osvw_init(vcpu);
>> +}
>> +
>>   /*
>>    * Check for the presence of an AMD erratum. Arguments are defined in amd.h
>>
>>    * for each known erratum. Return 1 if erratum is found.
>> @@ -512,6 +548,30 @@ static void __devinit init_amd(struct cp
>>   	set_cpuidmask(c);
>>
>>   	check_syscfg_dram_mod_en();
>> +
>> +    /*
>> +     * Get OSVW bits. If bits are not the same on different processors then
>> +     * choose the worst case (i.e. if erratum is present on one processor and
>> +     * not on another assume that the erratum is present everywhere).
>> +     */
>> +     if (test_bit(X86_FEATURE_OSVW,&boot_cpu_data.x86_capability)) {
>> +         uint64_t len, status;
>> +
>> +        if (rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
>> +            rdmsr_safe(MSR_AMD_OSVW_STATUS, status))
>> +            len = status = 0;
>> +
>> +        spin_lock(&amd_lock);
>
> What is the locking here supposed to protect against? The AP call tree
> is smp_callin() ->  identify_cpu() ->  init_amd(), which cannot race with
> anything (as the initiating processor is waiting for cpu_state to change
> to CPU_STATE_CALLIN).
>
>> +
>> +        if (len<  osvw_length)
>> +            osvw_length = len;
>> +
>> +        osvw_status |= status;
>> +        osvw_status&= (1ULL<<  osvw_length) - 1;
>> +
>> +        spin_unlock(&amd_lock);
>> +    } else
>> +	 osvw_length = osvw_status = 0;
>>   }
>>
>>   static struct cpu_dev amd_cpu_dev __cpuinitdata = {
>> --- a/xen/arch/x86/domain.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/xen/arch/x86/domain.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -422,6 +422,10 @@ int vcpu_initialise(struct vcpu *v)
>>       if ( (rc = vcpu_init_fpu(v)) != 0 )
>>           return rc;
>>
>> +    /* Vendor-specific initialization */
>> +    if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
>
> If you check the vendor here, you don't need to anywhere in the
> descendant functions.
>
>> +        amd_vcpu_initialise(v);
>> +
>>       if ( is_hvm_domain(d) )
>>       {
>>           rc = hvm_vcpu_initialise(v);
>> --- a/xen/arch/x86/hvm/svm/svm.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/xen/arch/x86/hvm/svm/svm.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -1044,6 +1044,27 @@ static void svm_init_erratum_383(struct
>>       }
>>   }
>>
>> +static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, uint read)
>> +{
>> +    uint eax, ebx, ecx, edx;
>> +
>> +    /* Guest OSVW support */
>> +    hvm_cpuid(0x80000001,&eax,&ebx,&ecx,&edx);
>> +    if (!test_bit((X86_FEATURE_OSVW&  31),&ecx))
>
> Formatting of changes to this file should be changed to Xen style.
>
>> +        return -1;
>> +
>> +    if (read) {
>> +        if (msr == MSR_AMD_OSVW_ID_LENGTH)
>> +            *val = v->arch.amd.osvw.length;
>> +        else
>> +            *val = v->arch.amd.osvw.status;
>> +    }
>> +    /* Writes are ignored */
>> +
>> +    return 0;
>> +}
>> +
>> +
>>   static int svm_cpu_up(void)
>>   {
>>       uint64_t msr_content;
>> --- a/xen/arch/x86/traps.c	Mon Jan 09 16:01:44 2012 +0100
>> +++ b/xen/arch/x86/traps.c	Mon Jan 16 22:08:09 2012 +0100
>> @@ -2542,6 +2542,15 @@ static int emulate_privileged_op(struct
>>               if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
>>                   goto fail;
>>               break;
>> +        case MSR_AMD_OSVW_ID_LENGTH:
>> +        case MSR_AMD_OSVW_STATUS:
>> +            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) {
>> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
>> +                    goto fail;
>> +                else
>
> Bogus "else" after a "goto". And I wonder, provided there is some
> point in doing all this for PV guests in the first place, whether this
> shouldn't be kept getting handled by the default case.


If we go into default case we will emit "Domain attempted WRMSR ..." 
message in the log. I was trying to avoid that since writing to these 
registers is not really an error, it just gets ignored.

I'll fix the rest.

Thanks for review.
-boris

>
>> +                    break; /* Writes are ignored */
>> +            }
>> +            /* Fall through to default case */
>>           default:
>>               if ( wrmsr_hypervisor_regs(regs->ecx, msr_content) )
>>                   break;
>> @@ -2573,6 +2582,7 @@ static int emulate_privileged_op(struct
>>           break;
>>
>>       case 0x32: /* RDMSR */
>> +
>
> Stray addition of a newline.
>
>>           switch ( (u32)regs->ecx )
>>           {
>>   #ifdef CONFIG_X86_64
>> @@ -2632,6 +2642,23 @@ static int emulate_privileged_op(struct
>>               regs->eax = (uint32_t)msr_content;
>>               regs->edx = (uint32_t)(msr_content>>  32);
>>               break;
>> +        case MSR_AMD_OSVW_ID_LENGTH:
>> +        case MSR_AMD_OSVW_STATUS:
>> +            if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
>> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
>> +                    goto fail;
>> +                else {
>
> Bogus "else" after a "goto".
>
> Jan
>
>> +                    if ((u32)regs->ecx == MSR_AMD_OSVW_ID_LENGTH)
>> +                        msr_content = v->arch.amd.osvw.length;
>> +                    else
>> +                        msr_content = v->arch.amd.osvw.status;
>> +
>> +                    regs->eax = (uint32_t)msr_content;
>> +                    regs->edx = (uint32_t)(msr_content>>  32);
>> +                }
>> +            } else
>> +                goto rdmsr_normal;
>> +            break;
>>           default:
>>               if ( rdmsr_hypervisor_regs(regs->ecx,&val) )
>>               {
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 18:12:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 18:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnDVa-00065A-5I; Tue, 17 Jan 2012 18:11:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <studyxen@gmail.com>) id 1RnDVY-000655-F3
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:11:44 +0000
X-Env-Sender: studyxen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326823897!1608413!1
X-Originating-IP: [209.85.214.65]
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 3428 invoked from network); 17 Jan 2012 18:11:37 -0000
Received: from mail-bk0-f65.google.com (HELO mail-bk0-f65.google.com)
	(209.85.214.65)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 18:11:37 -0000
Received: by bkaq10 with SMTP id q10so53171bka.0
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 10:11:37 -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=fgi1O4gwROWV985FSyHcBQwPeStMY+Rl12pjM5NGjW0=;
	b=rZdnYJSxRkO8rUOKNIFvgIdub2jo+O1ry+GszBSWWWdcG6xyiixwXjDRndNzG88ej7
	CbR2j47/6GwxqzFB1RlqJlkWOJVDTKfEkDPIF+roGJE/TcYdfFSwNvKYoNmRVaHMm2fA
	sK3oPCV2j6i6gS51JL4DcP9lzs+B1AEULmLpQ=
MIME-Version: 1.0
Received: by 10.204.153.216 with SMTP id l24mr7329331bkw.64.1326823897226;
	Tue, 17 Jan 2012 10:11:37 -0800 (PST)
Received: by 10.205.42.67 with HTTP; Tue, 17 Jan 2012 10:11:37 -0800 (PST)
In-Reply-To: <20120117111222.GC74654@ocelot.phlegethon.org>
References: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
	<20120117111222.GC74654@ocelot.phlegethon.org>
Date: Tue, 17 Jan 2012 13:11:37 -0500
Message-ID: <CAJEOSFsECuhG1UDH+DCUO650URE=+nGv6=V236kNVUKNipMWmg@mail.gmail.com>
From: Study Xen <studyxen@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] unable to capture an expected page fault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3524151603254786564=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3524151603254786564==
Content-Type: multipart/alternative; boundary=0015175d07b212dcf804b6bd4367

--0015175d07b212dcf804b6bd4367
Content-Type: text/plain; charset=ISO-8859-1

Hello Tim,

Thanks for your reply. I am actually learning (and the same time trying to
port) the code written by a former student. That is why it is currently
hard for me to clearly explain what have been modified in the code.

The former member's intention was to make use of Xen's ability of modifying
pagetables underneath the guest kernel to achieve data protection of user
applications from a compromised kernel. So his modification scattered into
several places, mainly in Xen's memory management code and interrupt
handling code. Unfortunately I have not been able to pinpoint which code
caused the current bug I mentioned in the previous mail.

X


On Tue, Jan 17, 2012 at 6:12 AM, Tim Deegan <tim@xen.org> wrote:

> Hi,
>
> At 03:08 -0500 on 17 Jan (1326769684), Study Xen wrote:
> > I was trying to modify part of Xen and faced a page fault missing issue.
> >
> > I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only
> > domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux
> > kernel's "native_set_pte" in "arch/x86/include/asm/pgtable_64.h" traps
> into
> > Xen due to Xen's write-protection of the pagetable page. But in our
> > modified version, this expected page fault seems missing.
>
> Well, I suppose it must be something you changed. :)  But since you don't
> say what you changed I'm not sure how much we can help you.  If the
> pagetables are indeed correct then maybe you're missing a TLB flush
> somewhere?
>
> Tim.
>

--0015175d07b212dcf804b6bd4367
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Tim,<div><br></div><div>Thanks for your reply. I am actually learning=
 (and the same time trying to port) the code written by a former student. T=
hat is why it is currently hard for me to clearly explain what have been mo=
dified in the code.=A0</div>
<div><br></div><div>The former member&#39;s intention was to make use of Xe=
n&#39;s ability of modifying pagetables underneath the guest kernel to achi=
eve data protection of user applications from a compromised kernel. So his =
modification scattered into several places, mainly in Xen&#39;s memory mana=
gement code and interrupt handling code. Unfortunately I have not been able=
 to pinpoint which code caused the current bug I mentioned in the previous =
mail.=A0</div>
<div><br></div><div>X</div><div><br><br><div class=3D"gmail_quote">On Tue, =
Jan 17, 2012 at 6:12 AM, Tim Deegan <span dir=3D"ltr">&lt;<a href=3D"mailto=
:tim@xen.org">tim@xen.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
Hi,<br>
<div class=3D"im"><br>
At 03:08 -0500 on 17 Jan (1326769684), Study Xen wrote:<br>
&gt; I was trying to modify part of Xen and faced a page fault missing issu=
e.<br>
&gt;<br>
&gt; I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only<=
br>
&gt; domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux<=
br>
&gt; kernel&#39;s &quot;native_set_pte&quot; in &quot;arch/x86/include/asm/=
pgtable_64.h&quot; traps into<br>
&gt; Xen due to Xen&#39;s write-protection of the pagetable page. But in ou=
r<br>
&gt; modified version, this expected page fault seems missing.<br>
<br>
</div>Well, I suppose it must be something you changed. :) =A0But since you=
 don&#39;t<br>
say what you changed I&#39;m not sure how much we can help you. =A0If the<b=
r>
pagetables are indeed correct then maybe you&#39;re missing a TLB flush<br>
somewhere?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>

--0015175d07b212dcf804b6bd4367--


--===============3524151603254786564==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3524151603254786564==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 18:12:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 18:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnDVa-00065A-5I; Tue, 17 Jan 2012 18:11:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <studyxen@gmail.com>) id 1RnDVY-000655-F3
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:11:44 +0000
X-Env-Sender: studyxen@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326823897!1608413!1
X-Originating-IP: [209.85.214.65]
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 3428 invoked from network); 17 Jan 2012 18:11:37 -0000
Received: from mail-bk0-f65.google.com (HELO mail-bk0-f65.google.com)
	(209.85.214.65)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 18:11:37 -0000
Received: by bkaq10 with SMTP id q10so53171bka.0
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 10:11:37 -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=fgi1O4gwROWV985FSyHcBQwPeStMY+Rl12pjM5NGjW0=;
	b=rZdnYJSxRkO8rUOKNIFvgIdub2jo+O1ry+GszBSWWWdcG6xyiixwXjDRndNzG88ej7
	CbR2j47/6GwxqzFB1RlqJlkWOJVDTKfEkDPIF+roGJE/TcYdfFSwNvKYoNmRVaHMm2fA
	sK3oPCV2j6i6gS51JL4DcP9lzs+B1AEULmLpQ=
MIME-Version: 1.0
Received: by 10.204.153.216 with SMTP id l24mr7329331bkw.64.1326823897226;
	Tue, 17 Jan 2012 10:11:37 -0800 (PST)
Received: by 10.205.42.67 with HTTP; Tue, 17 Jan 2012 10:11:37 -0800 (PST)
In-Reply-To: <20120117111222.GC74654@ocelot.phlegethon.org>
References: <CAJEOSFtHjhU1=eQ8ghDTcKvErso46OgAqOL8-jKeae0QnywDjw@mail.gmail.com>
	<20120117111222.GC74654@ocelot.phlegethon.org>
Date: Tue, 17 Jan 2012 13:11:37 -0500
Message-ID: <CAJEOSFsECuhG1UDH+DCUO650URE=+nGv6=V236kNVUKNipMWmg@mail.gmail.com>
From: Study Xen <studyxen@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] unable to capture an expected page fault
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3524151603254786564=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3524151603254786564==
Content-Type: multipart/alternative; boundary=0015175d07b212dcf804b6bd4367

--0015175d07b212dcf804b6bd4367
Content-Type: text/plain; charset=ISO-8859-1

Hello Tim,

Thanks for your reply. I am actually learning (and the same time trying to
port) the code written by a former student. That is why it is currently
hard for me to clearly explain what have been modified in the code.

The former member's intention was to make use of Xen's ability of modifying
pagetables underneath the guest kernel to achieve data protection of user
applications from a compromised kernel. So his modification scattered into
several places, mainly in Xen's memory management code and interrupt
handling code. Unfortunately I have not been able to pinpoint which code
caused the current bug I mentioned in the previous mail.

X


On Tue, Jan 17, 2012 at 6:12 AM, Tim Deegan <tim@xen.org> wrote:

> Hi,
>
> At 03:08 -0500 on 17 Jan (1326769684), Study Xen wrote:
> > I was trying to modify part of Xen and faced a page fault missing issue.
> >
> > I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only
> > domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux
> > kernel's "native_set_pte" in "arch/x86/include/asm/pgtable_64.h" traps
> into
> > Xen due to Xen's write-protection of the pagetable page. But in our
> > modified version, this expected page fault seems missing.
>
> Well, I suppose it must be something you changed. :)  But since you don't
> say what you changed I'm not sure how much we can help you.  If the
> pagetables are indeed correct then maybe you're missing a TLB flush
> somewhere?
>
> Tim.
>

--0015175d07b212dcf804b6bd4367
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Tim,<div><br></div><div>Thanks for your reply. I am actually learning=
 (and the same time trying to port) the code written by a former student. T=
hat is why it is currently hard for me to clearly explain what have been mo=
dified in the code.=A0</div>
<div><br></div><div>The former member&#39;s intention was to make use of Xe=
n&#39;s ability of modifying pagetables underneath the guest kernel to achi=
eve data protection of user applications from a compromised kernel. So his =
modification scattered into several places, mainly in Xen&#39;s memory mana=
gement code and interrupt handling code. Unfortunately I have not been able=
 to pinpoint which code caused the current bug I mentioned in the previous =
mail.=A0</div>
<div><br></div><div>X</div><div><br><br><div class=3D"gmail_quote">On Tue, =
Jan 17, 2012 at 6:12 AM, Tim Deegan <span dir=3D"ltr">&lt;<a href=3D"mailto=
:tim@xen.org">tim@xen.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
Hi,<br>
<div class=3D"im"><br>
At 03:08 -0500 on 17 Jan (1326769684), Study Xen wrote:<br>
&gt; I was trying to modify part of Xen and faced a page fault missing issu=
e.<br>
&gt;<br>
&gt; I am testing a PV Linux 64-bit guest (kernel 3.1.1, as dom0, the only<=
br>
&gt; domain in my setting) atop Xen 4.1.2. In an unmodified Xen, the Linux<=
br>
&gt; kernel&#39;s &quot;native_set_pte&quot; in &quot;arch/x86/include/asm/=
pgtable_64.h&quot; traps into<br>
&gt; Xen due to Xen&#39;s write-protection of the pagetable page. But in ou=
r<br>
&gt; modified version, this expected page fault seems missing.<br>
<br>
</div>Well, I suppose it must be something you changed. :) =A0But since you=
 don&#39;t<br>
say what you changed I&#39;m not sure how much we can help you. =A0If the<b=
r>
pagetables are indeed correct then maybe you&#39;re missing a TLB flush<br>
somewhere?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>

--0015175d07b212dcf804b6bd4367--


--===============3524151603254786564==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3524151603254786564==--


From xen-devel-bounces@lists.xensource.com Tue Jan 17 18:23:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 18:23:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnDg3-0006fS-1p; Tue, 17 Jan 2012 18:22: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 1RnDg1-0006fE-PU
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:22:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326824545!11416593!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwMDA0Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6089 invoked from network); 17 Jan 2012 18:22:27 -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; 17 Jan 2012 18:22: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
	q0HILTdT004708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 18:21:30 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
	q0HILQCX028939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 18:21:28 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
	q0HILPO0013904; Tue, 17 Jan 2012 12:21:25 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 10:21:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DCB8A40316; Tue, 17 Jan 2012 13:19:22 -0500 (EST)
Date: Tue, 17 Jan 2012 13:19:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120117181922.GA12900@phenom.dumpdata.com>
References: <625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
	<20111220153145.GB13253@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
	<20111223030103.GA7218@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
	<20120113222451.GA6922@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
	<20120117171314.GB5494@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117171314.GB5494@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F15BC2C.0074,ss=1,re=-2.300,fgs=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@kernel.org" <konrad@kernel.org>, "Nakajima,
	Jun" <jun.nakajima@intel.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 <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.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, Jan 17, 2012 at 12:13:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > > I was trying to figure out how difficult it would be to just bring Pxx states to
> > > the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
> > > all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
> > > be enabled in the hypercall to make this work), it demonstrates what I had in
> > > mind. 
> 
> .. snip..
> > > 	/* TODO: Under Xen, the C-states information is not present.
> > >  	 * Figure out why. */
> > 
> > it's possible related to this long thread:
> > 
> > http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html
> > 
> > IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
> > Final solution is to have a para-virtualized PDC call for that.
> 
> Aaah. Let me play with that a bit. Thanks for the pointer.
> 
> .. snip..
> > the prerequisites for this module to work correctly, is that dom0 has the right
> > configurations to have all necessary Cx/Px information ready before this 
> > module is loaded. That may mean enabling full CONFIG_CPU_IDLE and CONFIG_CPUFREQ,
> 
> Right.
> > which in current form may add some negative impact, e.g. dom0 will try to control
> > Px/Cx to conflict with Xen. So some tweaks may be required in that part.
> 
> Yup. Hadn't even looked at the cpufreq tries to do yet.
> > 
> > given our purpose now, is to come up a cleaner approach which tolerate some
> > assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
> > trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
> > xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
> > mainly two roles:
> > 	- a dummy driver to prevent dom0 touching actual Px/Cx
> > 	- parse ACPI Cx/Px information to Xen, in a similar way you did above
> 
> Yeah, I like where you are heading.
> > 
> > there may have some other trickiness, but the majority code will be self-contained.
> 
> <nods>

For reference, the attached module does end up programming the Pxx states in the
hypervisor. The issues that I hit on a Core i3 box (some MSI motherboard) it would fail
on the PCT, but I hadn't really dug into this. And did not look any further in the
Cxx states issue either. On a old Core 2 Duo it looked to have programmed the hypervisor
fine, but the machine afterwards started to act very weird so I am sure there is
something extra that needs to be done (like maybe not using memcpy in this module).

#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
#include <acpi/processor.h>
#include <linux/cpumask.h>

#include <xen/interface/platform.h>
#include <asm/xen/hypercall.h>

#define DRV_NAME	"ACPI_PXX"
#define DRV_CLASS	"ACPI_PXX_CLASS"
MODULE_AUTHOR("Konrad Rzeszutek Wilk");
MODULE_DESCRIPTION("ACPI Processor Driver to send data to Xen hypervisor");
MODULE_LICENSE("GPL");

static int parse_acpi_cxx(struct acpi_processor *_pr)
{
	struct acpi_processor_cx *cx;
	int i;

	for (i = 1; i <= _pr->power.count; i++) {
		cx = &_pr->power.states[i];
		if (!cx->valid)
			continue;
		pr_info("%s: %d %d %d 0x%x\n", __func__,
			cx->type, cx->latency, cx->power, (u32)cx->address);
	}
	/* TODO: Under Xen, the C-states information is not present.
 	 * Figure out why.
 	 * Kevin thinks it might be: http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html
 	 * But perhaps it is http://lists.xen.org/archives/html/xen-devel/2011-08/msg00521.html?
 	 */
	return 0;
}
static struct xen_processor_px *xen_copy_pss_data(struct acpi_processor *_pr,
		  				  struct xen_processor_performance *xen_perf)
{
	struct xen_processor_px *xen_states = NULL;
	int i;

	xen_states = kzalloc(_pr->performance->state_count *
			     sizeof(struct xen_processor_px), GFP_KERNEL);
	if (!xen_states)
		return ERR_PTR(-ENOMEM);

	xen_perf->state_count = _pr->performance->state_count;
	for (i = 0; i < _pr->performance->state_count; i++) {
		/* Figure out if the lack of __packed is bad */
		memcpy(&(xen_states[i]), &(_pr->performance->states[i]),
		       sizeof(struct acpi_processor_px));
	}
	return xen_states;
}
static int
xen_copy_psd_data(struct acpi_processor *_pr,
		  struct xen_processor_performance *xen_perf)
{
	/* Figure out if the lack of __packed is bad */
	printk(KERN_INFO "psd: %ld\n",
		offsetof(struct xen_processor_performance, domain_info.num_entries));

	xen_perf->shared_type = _pr->performance->shared_type;
	memcpy(&(xen_perf->domain_info), &(_pr->performance->domain_info),
	       sizeof(struct acpi_psd_package));

	return 0;
}
static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
{
	int ret = -EINVAL;
	struct xen_platform_op op = {
		.cmd			= XENPF_set_processor_pminfo,
		.interface_version	= XENPF_INTERFACE_VERSION,
		.u.set_pminfo.id	= _pr->acpi_id,
		.u.set_pminfo.type	= XEN_PM_PX,
	};
	struct xen_processor_performance *xen_perf;
	struct xen_processor_px *xen_states = NULL;

	if (!_pr->performance)
		return -ENODEV;

	xen_perf = &op.u.set_pminfo.perf;

	/* PPC */
	xen_perf->platform_limit = _pr->performance_platform_limit;
	xen_perf->flags |= XEN_PX_PPC;
	/* PCT */
	/* Mmight need to copy them individually as there are no __packed
	 * so the offset might be wrong on a 32-bit host with 64-bit hypervisor. */
	printk(KERN_INFO "address: %ld\n", offsetof(struct xen_processor_performance, control_register.address));
	printk(KERN_INFO "address: %ld\n", offsetof(struct xen_processor_performance, status_register.address));
	printk(KERN_INFO "state_count: %ld\n", offsetof(struct xen_processor_performance, state_count));
	memcpy(&xen_perf->control_register, &(_pr->performance->control_register),
	       sizeof(struct acpi_pct_register));
	memcpy(&xen_perf->status_register, &(_pr->performance->status_register),
	       sizeof(struct acpi_pct_register));
	xen_perf->flags |= XEN_PX_PCT;
	/* PSS */
	xen_states = xen_copy_pss_data(_pr, xen_perf);
	if (!IS_ERR_OR_NULL(xen_states)) {
		set_xen_guest_handle(xen_perf->states, xen_states);
		xen_perf->flags |= XEN_PX_PSS;
	}
	/* PSD */
	if (!xen_copy_psd_data(_pr, xen_perf)) {
		xen_perf->flags |= XEN_PX_PSD;
	}
	printk(KERN_INFO "Sending %x\n", xen_perf->flags);

	ret = HYPERVISOR_dom0_op(&op);
	if (!IS_ERR_OR_NULL(xen_states))
		kfree(xen_states);
	return ret;
}
static int parse_acpi_pxx(struct acpi_processor *_pr)
{
/*
	struct acpi_processor_px *px;
	int i;

	for (i = 0; i < _pr->performance->state_count;i++) {
		px = &(_pr->performance->states[i]);
		pr_info("%s: [%d]: %d, %d, %d, %d, %d, %d\n", __func__,
			i, (u32)px->core_frequency, (u32)px->power,
			(u32)px->transition_latency,
			(u32)px->bus_master_latency,
			(u32)px->control, (u32)px->status);
	}
*/
	if (xen_initial_domain())
		return push_pxx_to_hypervisor(_pr);
	return 0;
}
static int parse_acpi_data(void)
{
	int cpu;
	int err = -ENODEV;
	struct acpi_processor *_pr;
	struct cpuinfo_x86 *c = &cpu_data(0);

	/* TODO: Under AMD, the information is populated
	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
	 * MSR which returns the wrong value so the population of 'processors'
	 * has bogus data. So only run this under Intel for right now. */
	if (!cpu_has(c, X86_FEATURE_EST))
		return -ENODEV;
	for_each_possible_cpu(cpu) {
		_pr = per_cpu(processors, cpu);
		if (!_pr)
			continue;

		if (_pr->flags.power)
			(void)parse_acpi_cxx(_pr);

		if (_pr->performance->states)
			err = parse_acpi_pxx(_pr);
		if (err)
			break;
	}
	return -ENODEV; /* force it to unload */
}
static int __init acpi_pxx_init(void)
{
	return parse_acpi_data();
}
static void __exit acpi_pxx_exit(void)
{
}
module_init(acpi_pxx_init);
module_exit(acpi_pxx_exit);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 18:23:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 18:23:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnDg3-0006fS-1p; Tue, 17 Jan 2012 18:22: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 1RnDg1-0006fE-PU
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:22:34 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326824545!11416593!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwMDA0Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6089 invoked from network); 17 Jan 2012 18:22:27 -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; 17 Jan 2012 18:22: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
	q0HILTdT004708
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 18:21:30 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
	q0HILQCX028939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 18:21:28 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
	q0HILPO0013904; Tue, 17 Jan 2012 12:21:25 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 10:21:25 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DCB8A40316; Tue, 17 Jan 2012 13:19:22 -0500 (EST)
Date: Tue, 17 Jan 2012 13:19:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120117181922.GA12900@phenom.dumpdata.com>
References: <625BA99ED14B2D499DC4E29D8138F1506E01AAC03A@shsmsx502.ccr.corp.intel.com>
	<20111220153145.GB13253@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
	<20111223030103.GA7218@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
	<20120113222451.GA6922@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
	<20120117171314.GB5494@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117171314.GB5494@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090207.4F15BC2C.0074,ss=1,re=-2.300,fgs=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@kernel.org" <konrad@kernel.org>, "Nakajima,
	Jun" <jun.nakajima@intel.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 <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.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, Jan 17, 2012 at 12:13:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > > I was trying to figure out how difficult it would be to just bring Pxx states to
> > > the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
> > > all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
> > > be enabled in the hypercall to make this work), it demonstrates what I had in
> > > mind. 
> 
> .. snip..
> > > 	/* TODO: Under Xen, the C-states information is not present.
> > >  	 * Figure out why. */
> > 
> > it's possible related to this long thread:
> > 
> > http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html
> > 
> > IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
> > Final solution is to have a para-virtualized PDC call for that.
> 
> Aaah. Let me play with that a bit. Thanks for the pointer.
> 
> .. snip..
> > the prerequisites for this module to work correctly, is that dom0 has the right
> > configurations to have all necessary Cx/Px information ready before this 
> > module is loaded. That may mean enabling full CONFIG_CPU_IDLE and CONFIG_CPUFREQ,
> 
> Right.
> > which in current form may add some negative impact, e.g. dom0 will try to control
> > Px/Cx to conflict with Xen. So some tweaks may be required in that part.
> 
> Yup. Hadn't even looked at the cpufreq tries to do yet.
> > 
> > given our purpose now, is to come up a cleaner approach which tolerate some
> > assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
> > trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
> > xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
> > mainly two roles:
> > 	- a dummy driver to prevent dom0 touching actual Px/Cx
> > 	- parse ACPI Cx/Px information to Xen, in a similar way you did above
> 
> Yeah, I like where you are heading.
> > 
> > there may have some other trickiness, but the majority code will be self-contained.
> 
> <nods>

For reference, the attached module does end up programming the Pxx states in the
hypervisor. The issues that I hit on a Core i3 box (some MSI motherboard) it would fail
on the PCT, but I hadn't really dug into this. And did not look any further in the
Cxx states issue either. On a old Core 2 Duo it looked to have programmed the hypervisor
fine, but the machine afterwards started to act very weird so I am sure there is
something extra that needs to be done (like maybe not using memcpy in this module).

#include <linux/device.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/types.h>
#include <acpi/acpi_bus.h>
#include <acpi/acpi_drivers.h>
#include <acpi/processor.h>
#include <linux/cpumask.h>

#include <xen/interface/platform.h>
#include <asm/xen/hypercall.h>

#define DRV_NAME	"ACPI_PXX"
#define DRV_CLASS	"ACPI_PXX_CLASS"
MODULE_AUTHOR("Konrad Rzeszutek Wilk");
MODULE_DESCRIPTION("ACPI Processor Driver to send data to Xen hypervisor");
MODULE_LICENSE("GPL");

static int parse_acpi_cxx(struct acpi_processor *_pr)
{
	struct acpi_processor_cx *cx;
	int i;

	for (i = 1; i <= _pr->power.count; i++) {
		cx = &_pr->power.states[i];
		if (!cx->valid)
			continue;
		pr_info("%s: %d %d %d 0x%x\n", __func__,
			cx->type, cx->latency, cx->power, (u32)cx->address);
	}
	/* TODO: Under Xen, the C-states information is not present.
 	 * Figure out why.
 	 * Kevin thinks it might be: http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html
 	 * But perhaps it is http://lists.xen.org/archives/html/xen-devel/2011-08/msg00521.html?
 	 */
	return 0;
}
static struct xen_processor_px *xen_copy_pss_data(struct acpi_processor *_pr,
		  				  struct xen_processor_performance *xen_perf)
{
	struct xen_processor_px *xen_states = NULL;
	int i;

	xen_states = kzalloc(_pr->performance->state_count *
			     sizeof(struct xen_processor_px), GFP_KERNEL);
	if (!xen_states)
		return ERR_PTR(-ENOMEM);

	xen_perf->state_count = _pr->performance->state_count;
	for (i = 0; i < _pr->performance->state_count; i++) {
		/* Figure out if the lack of __packed is bad */
		memcpy(&(xen_states[i]), &(_pr->performance->states[i]),
		       sizeof(struct acpi_processor_px));
	}
	return xen_states;
}
static int
xen_copy_psd_data(struct acpi_processor *_pr,
		  struct xen_processor_performance *xen_perf)
{
	/* Figure out if the lack of __packed is bad */
	printk(KERN_INFO "psd: %ld\n",
		offsetof(struct xen_processor_performance, domain_info.num_entries));

	xen_perf->shared_type = _pr->performance->shared_type;
	memcpy(&(xen_perf->domain_info), &(_pr->performance->domain_info),
	       sizeof(struct acpi_psd_package));

	return 0;
}
static int push_pxx_to_hypervisor(struct acpi_processor *_pr)
{
	int ret = -EINVAL;
	struct xen_platform_op op = {
		.cmd			= XENPF_set_processor_pminfo,
		.interface_version	= XENPF_INTERFACE_VERSION,
		.u.set_pminfo.id	= _pr->acpi_id,
		.u.set_pminfo.type	= XEN_PM_PX,
	};
	struct xen_processor_performance *xen_perf;
	struct xen_processor_px *xen_states = NULL;

	if (!_pr->performance)
		return -ENODEV;

	xen_perf = &op.u.set_pminfo.perf;

	/* PPC */
	xen_perf->platform_limit = _pr->performance_platform_limit;
	xen_perf->flags |= XEN_PX_PPC;
	/* PCT */
	/* Mmight need to copy them individually as there are no __packed
	 * so the offset might be wrong on a 32-bit host with 64-bit hypervisor. */
	printk(KERN_INFO "address: %ld\n", offsetof(struct xen_processor_performance, control_register.address));
	printk(KERN_INFO "address: %ld\n", offsetof(struct xen_processor_performance, status_register.address));
	printk(KERN_INFO "state_count: %ld\n", offsetof(struct xen_processor_performance, state_count));
	memcpy(&xen_perf->control_register, &(_pr->performance->control_register),
	       sizeof(struct acpi_pct_register));
	memcpy(&xen_perf->status_register, &(_pr->performance->status_register),
	       sizeof(struct acpi_pct_register));
	xen_perf->flags |= XEN_PX_PCT;
	/* PSS */
	xen_states = xen_copy_pss_data(_pr, xen_perf);
	if (!IS_ERR_OR_NULL(xen_states)) {
		set_xen_guest_handle(xen_perf->states, xen_states);
		xen_perf->flags |= XEN_PX_PSS;
	}
	/* PSD */
	if (!xen_copy_psd_data(_pr, xen_perf)) {
		xen_perf->flags |= XEN_PX_PSD;
	}
	printk(KERN_INFO "Sending %x\n", xen_perf->flags);

	ret = HYPERVISOR_dom0_op(&op);
	if (!IS_ERR_OR_NULL(xen_states))
		kfree(xen_states);
	return ret;
}
static int parse_acpi_pxx(struct acpi_processor *_pr)
{
/*
	struct acpi_processor_px *px;
	int i;

	for (i = 0; i < _pr->performance->state_count;i++) {
		px = &(_pr->performance->states[i]);
		pr_info("%s: [%d]: %d, %d, %d, %d, %d, %d\n", __func__,
			i, (u32)px->core_frequency, (u32)px->power,
			(u32)px->transition_latency,
			(u32)px->bus_master_latency,
			(u32)px->control, (u32)px->status);
	}
*/
	if (xen_initial_domain())
		return push_pxx_to_hypervisor(_pr);
	return 0;
}
static int parse_acpi_data(void)
{
	int cpu;
	int err = -ENODEV;
	struct acpi_processor *_pr;
	struct cpuinfo_x86 *c = &cpu_data(0);

	/* TODO: Under AMD, the information is populated
	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
	 * MSR which returns the wrong value so the population of 'processors'
	 * has bogus data. So only run this under Intel for right now. */
	if (!cpu_has(c, X86_FEATURE_EST))
		return -ENODEV;
	for_each_possible_cpu(cpu) {
		_pr = per_cpu(processors, cpu);
		if (!_pr)
			continue;

		if (_pr->flags.power)
			(void)parse_acpi_cxx(_pr);

		if (_pr->performance->states)
			err = parse_acpi_pxx(_pr);
		if (err)
			break;
	}
	return -ENODEV; /* force it to unload */
}
static int __init acpi_pxx_init(void)
{
	return parse_acpi_data();
}
static void __exit acpi_pxx_exit(void)
{
}
module_init(acpi_pxx_init);
module_exit(acpi_pxx_exit);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 18:35:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 18:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnDrX-0007Ar-V7; Tue, 17 Jan 2012 18:34:27 +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 1RnDrW-0007Am-TX
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:34:27 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326825258!9539598!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 6450 invoked from network); 17 Jan 2012 18:34:20 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 18:34: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
	q0HIYCRv016727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 17 Jan 2012 13:34:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0HIYC4W016724;
	Tue, 17 Jan 2012 13:34:12 -0500
Date: Tue, 17 Jan 2012 14:34:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120117183412.GA16578@andromeda.dapyr.net>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
	<1325750535.29084.1.camel@dagon.hellion.org.uk>
	<D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
	<1325775922.25206.395.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325775922.25206.395.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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 Thu, Jan 05, 2012 at 03:05:21PM +0000, Ian Campbell wrote:
> On Thu, 2012-01-05 at 15:00 +0000, Wei, Gang wrote:
> > Ian Campbell wrote on 2012-01-05:
> > > On Wed, 2012-01-04 at 21:57 +0000, Kay, Allen M wrote:
> > >> Attached patch fix build error in latest xen-unstable.hg.
> > > 
> > > What is the specific build error?
> > > 
> > > What version of yajl do you have and on which distro?
> > > 
> > 
> > I am not try to answer this for Allen, but I also met similar build error(it says yajl_gen_no_buf was not defined) in RHEL6.2 64bit with yajl 1.0.7-3.
> 
> I use 1.0.8 so I guess this must be new there.
> 
> Any patch which says "fix build error/warning/message" should, IMHO,
> always include a verbatim copy of the error message being fixed.
> 
> Please can one of you resubmit with the changelog corrected in that
> manner?

Yes please. You can also add 'Tested-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>'. Thanks.
> 
> Eventually we could use autoconf to detect this stuff, although that
> does sound rather like overkill...
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 18:35:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 18:35:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnDrX-0007Ar-V7; Tue, 17 Jan 2012 18:34:27 +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 1RnDrW-0007Am-TX
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:34:27 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326825258!9539598!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 6450 invoked from network); 17 Jan 2012 18:34:20 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 18:34: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
	q0HIYCRv016727
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 17 Jan 2012 13:34:12 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0HIYC4W016724;
	Tue, 17 Jan 2012 13:34:12 -0500
Date: Tue, 17 Jan 2012 14:34:12 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120117183412.GA16578@andromeda.dapyr.net>
References: <003AAFE53969E14CB1F09B6FD68C3CD4019C28@ORSMSX105.amr.corp.intel.com>
	<1325750535.29084.1.camel@dagon.hellion.org.uk>
	<D0B11485C64D4B47B66902F8A4E901BEFEC0@SHSMSX101.ccr.corp.intel.com>
	<1325775922.25206.395.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325775922.25206.395.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.9i
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Kay, Allen M" <allen.m.kay@intel.com>, "Wei, Gang" <gang.wei@intel.com>
Subject: Re: [Xen-devel] [PATCH] fix build 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 Thu, Jan 05, 2012 at 03:05:21PM +0000, Ian Campbell wrote:
> On Thu, 2012-01-05 at 15:00 +0000, Wei, Gang wrote:
> > Ian Campbell wrote on 2012-01-05:
> > > On Wed, 2012-01-04 at 21:57 +0000, Kay, Allen M wrote:
> > >> Attached patch fix build error in latest xen-unstable.hg.
> > > 
> > > What is the specific build error?
> > > 
> > > What version of yajl do you have and on which distro?
> > > 
> > 
> > I am not try to answer this for Allen, but I also met similar build error(it says yajl_gen_no_buf was not defined) in RHEL6.2 64bit with yajl 1.0.7-3.
> 
> I use 1.0.8 so I guess this must be new there.
> 
> Any patch which says "fix build error/warning/message" should, IMHO,
> always include a verbatim copy of the error message being fixed.
> 
> Please can one of you resubmit with the changelog corrected in that
> manner?

Yes please. You can also add 'Tested-by: Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>'. Thanks.
> 
> Eventually we could use autoconf to detect this stuff, although that
> does sound rather like overkill...
> 
> Ian.
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 18:57:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 18:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnED7-0007ww-Mg; Tue, 17 Jan 2012 18:56: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 1RnED6-0007wp-1v
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:56:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326826596!9374582!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8941 invoked from network); 17 Jan 2012 18:56:36 -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;
	17 Jan 2012 18:56:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10095349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 18:56:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 18:56:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnECx-0006nH-4x;
	Tue, 17 Jan 2012 18:56:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnECx-0006iQ-4L;
	Tue, 17 Jan 2012 18:56:35 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10791-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 18:56:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10791: 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 10791 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10791/

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. 10762
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10762

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-amd64-xl-win7-amd64 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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   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

version targeted for testing:
 xen                  27e959546916
baseline version:
 xen                  e29b7691fefc

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Gang Wei <gang.wei@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Tim Deegan <Tim.Deegan@citrix.com>
  Tim Deegan <tim@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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:   23218:27e959546916
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:32:46 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
changeset:   23217:a5a9479b07cc
user:        David Vrabel <david.vrabel@citrix.com>
date:        Tue Jan 17 11:32:04 2012 +0000
    
    x86: emulate lea with two register operands correctly
    
    An lea instruction with two register operands should raise an
    undefined instruction exception.
    
    Skype does such a instruction and will crash when starting if it does
    not get the exception.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24456:03781de56c31
    xen-unstable date:        Thu Jan 05 15:47:16 2012 +0000
    
    
changeset:   23216:c358c4213d23
user:        Yongan Liu <Liuyongan@huawei.com>
date:        Tue Jan 17 11:31:28 2012 +0000
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24453:02b92d035f64
    xen-unstable date:        Thu Jan 05 09:29:59 2012 +0100
    
    
changeset:   23215:2fb706161c09
user:        Tim Deegan <Tim.Deegan@citrix.com>
date:        Tue Jan 17 11:30:37 2012 +0000
    
    x86: Remove timeouts from INIT-SIPI-SIPI sequence when using x2apic.
    
    Some of the timeouts are pointless since they're waiting for the ICR
    to ack the IPI delivery and that doesn't happen on x2apic.
    The others should be benign (and are suggested in the SDM) but
    removing them makes AP bringup much more reliable on some test boxes.
    
    Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
    xen-unstable changeset:   23724:b3434f24b082
    xen-unstable date:        Tue Jul 19 14:13:01 2011 +0100
    
    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>
    xen-unstable changeset:   24447:a7b2610b8e5c
    xen-unstable date:        Thu Dec 29 10:07:54 2011 +0000
    
    
changeset:   23214:e29b7691fefc
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:13 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1
    
    
========================================
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 Tue Jan 17 18:57:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 18:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnED7-0007ww-Mg; Tue, 17 Jan 2012 18:56: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 1RnED6-0007wp-1v
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:56:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326826596!9374582!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8941 invoked from network); 17 Jan 2012 18:56:36 -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;
	17 Jan 2012 18:56:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,524,1320624000"; d="scan'208";a="10095349"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 18:56:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 18:56:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnECx-0006nH-4x;
	Tue, 17 Jan 2012 18:56:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnECx-0006iQ-4L;
	Tue, 17 Jan 2012 18:56:35 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10791-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 18:56:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10791: 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 10791 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10791/

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. 10762
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10762

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-amd64-xl-win7-amd64 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-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   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

version targeted for testing:
 xen                  27e959546916
baseline version:
 xen                  e29b7691fefc

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Gang Wei <gang.wei@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Tim Deegan <Tim.Deegan@citrix.com>
  Tim Deegan <tim@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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:   23218:27e959546916
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:32:46 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
changeset:   23217:a5a9479b07cc
user:        David Vrabel <david.vrabel@citrix.com>
date:        Tue Jan 17 11:32:04 2012 +0000
    
    x86: emulate lea with two register operands correctly
    
    An lea instruction with two register operands should raise an
    undefined instruction exception.
    
    Skype does such a instruction and will crash when starting if it does
    not get the exception.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24456:03781de56c31
    xen-unstable date:        Thu Jan 05 15:47:16 2012 +0000
    
    
changeset:   23216:c358c4213d23
user:        Yongan Liu <Liuyongan@huawei.com>
date:        Tue Jan 17 11:31:28 2012 +0000
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24453:02b92d035f64
    xen-unstable date:        Thu Jan 05 09:29:59 2012 +0100
    
    
changeset:   23215:2fb706161c09
user:        Tim Deegan <Tim.Deegan@citrix.com>
date:        Tue Jan 17 11:30:37 2012 +0000
    
    x86: Remove timeouts from INIT-SIPI-SIPI sequence when using x2apic.
    
    Some of the timeouts are pointless since they're waiting for the ICR
    to ack the IPI delivery and that doesn't happen on x2apic.
    The others should be benign (and are suggested in the SDM) but
    removing them makes AP bringup much more reliable on some test boxes.
    
    Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
    xen-unstable changeset:   23724:b3434f24b082
    xen-unstable date:        Tue Jul 19 14:13:01 2011 +0100
    
    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>
    xen-unstable changeset:   24447:a7b2610b8e5c
    xen-unstable date:        Thu Dec 29 10:07:54 2011 +0000
    
    
changeset:   23214:e29b7691fefc
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:13 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.1
    
    
========================================
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 Tue Jan 17 20:14:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 20:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnFOv-0000Go-7d; Tue, 17 Jan 2012 20:13:01 +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 1RnFOu-0000Gj-25
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 20:13:00 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326831172!9551769!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 21451 invoked from network); 17 Jan 2012 20:12:53 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 20:12:53 -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
	q0HKCjwa027603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 17 Jan 2012 15:12:46 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0HKCjYU027601;
	Tue, 17 Jan 2012 15:12:45 -0500
Date: Tue, 17 Jan 2012 16:12:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: djmagee@mageenet.net
Message-ID: <20120117201245.GA25805@andromeda.dapyr.net>
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
	<1326809782.14689.114.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

On Tue, Jan 17, 2012 at 09:24:39AM -0500, djmagee@mageenet.net wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, January 17, 2012 9:16 AM
> > To: djmagee@mageenet.net
> > Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> > Subject: RE: [Xen-devel] [PATCH] libxl_pci: check that host device is
> > assignable before adding to the domain
> > 
> > Please don't top post.
> > 
> > On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> > > That was my first thought, but this was also the first thing in libxl
> > > I touched and wasn't sure what would happen if I ended up nesting
> > > GC_INITs.  If it's safe to do then I can call
> > > libxl_device_pci_list_assignable, otherwise I'd have to pull the meat
> > > out and put it in another function.  What's the best way to do it?
> > 
> > You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get a ctx
> > from a gc which you use to call an externally visible function from
> > within libxl -- it'll do the right thing (TM).
> 
> Cool, I'll send an updated patch along today.

You might want to check for 'xen-pciback', 'pciback' and 'pci-stub'
as they are valid.
> 
> Doug
> 
> > 
> > Ian.
> > 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 20:14:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 20:14:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnFOv-0000Go-7d; Tue, 17 Jan 2012 20:13:01 +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 1RnFOu-0000Gj-25
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 20:13:00 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326831172!9551769!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 21451 invoked from network); 17 Jan 2012 20:12:53 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 20:12:53 -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
	q0HKCjwa027603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 17 Jan 2012 15:12:46 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0HKCjYU027601;
	Tue, 17 Jan 2012 15:12:45 -0500
Date: Tue, 17 Jan 2012 16:12:45 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: djmagee@mageenet.net
Message-ID: <20120117201245.GA25805@andromeda.dapyr.net>
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
	<1326809782.14689.114.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

On Tue, Jan 17, 2012 at 09:24:39AM -0500, djmagee@mageenet.net wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, January 17, 2012 9:16 AM
> > To: djmagee@mageenet.net
> > Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> > Subject: RE: [Xen-devel] [PATCH] libxl_pci: check that host device is
> > assignable before adding to the domain
> > 
> > Please don't top post.
> > 
> > On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> > > That was my first thought, but this was also the first thing in libxl
> > > I touched and wasn't sure what would happen if I ended up nesting
> > > GC_INITs.  If it's safe to do then I can call
> > > libxl_device_pci_list_assignable, otherwise I'd have to pull the meat
> > > out and put it in another function.  What's the best way to do it?
> > 
> > You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get a ctx
> > from a gc which you use to call an externally visible function from
> > within libxl -- it'll do the right thing (TM).
> 
> Cool, I'll send an updated patch along today.

You might want to check for 'xen-pciback', 'pciback' and 'pci-stub'
as they are valid.
> 
> Doug
> 
> > 
> > Ian.
> > 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 20:16:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 20: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 1RnFRR-0000LO-QB; Tue, 17 Jan 2012 20:15:37 +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 1RnFRQ-0000LG-EB
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 20:15:36 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326831328!9497252!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3267 invoked from network); 17 Jan 2012 20:15:29 -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; 17 Jan 2012 20:15:29 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q0HKFPvv027807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 17 Jan 2012 15:15:26 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0HKFPaG027805;
	Tue, 17 Jan 2012 15:15:25 -0500
Date: Tue, 17 Jan 2012 16:15:25 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120117201525.GB25805@andromeda.dapyr.net>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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 Tue, Jan 17, 2012 at 12:58:14PM +0400, Vasiliy Tolstov wrote:
> Hello. Today i'm try to research, why most of our vm (pvm) not
> shutdown correctly (we use shutdown with timeout, then it arrives we
> destroy vm), and write simple test case to check that domU watches

Which kernel version of DomU?
> works correctly:
> 
> xenstore write /local/domain/DOMID/control/shutdown testflag;
> xenstore read /local/domain/DOMID/control/shutdown
> 
> If userspace watches works correctly - xenstore read returns empty,
> becouse domU kernel respond only to known actions and printk and clean
> path on unknown actions.
> I can't see difference in various kernel versions
> (centos/opensuse/debian and other), we use oxenstored old version
> (that shipped with 4.0.1_21326_06-0.4.1 on sles)
> How can i debug this issue and get more info on this problem?

Play a bit with xenctx to get an idea where the guest is stuck at.

> P.S. Some domains, that has small uptime respond to my check and
> shutdown/migrate correctly.
> 
> -- 
> Vasiliy Tolstov,
> Clodo.ru
> e-mail: v.tolstov@selfip.ru
> jabber: vase@selfip.ru
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 20:16:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 20: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 1RnFRR-0000LO-QB; Tue, 17 Jan 2012 20:15:37 +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 1RnFRQ-0000LG-EB
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 20:15:36 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326831328!9497252!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3267 invoked from network); 17 Jan 2012 20:15:29 -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; 17 Jan 2012 20:15:29 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q0HKFPvv027807
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 17 Jan 2012 15:15:26 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0HKFPaG027805;
	Tue, 17 Jan 2012 15:15:25 -0500
Date: Tue, 17 Jan 2012 16:15:25 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120117201525.GB25805@andromeda.dapyr.net>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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 Tue, Jan 17, 2012 at 12:58:14PM +0400, Vasiliy Tolstov wrote:
> Hello. Today i'm try to research, why most of our vm (pvm) not
> shutdown correctly (we use shutdown with timeout, then it arrives we
> destroy vm), and write simple test case to check that domU watches

Which kernel version of DomU?
> works correctly:
> 
> xenstore write /local/domain/DOMID/control/shutdown testflag;
> xenstore read /local/domain/DOMID/control/shutdown
> 
> If userspace watches works correctly - xenstore read returns empty,
> becouse domU kernel respond only to known actions and printk and clean
> path on unknown actions.
> I can't see difference in various kernel versions
> (centos/opensuse/debian and other), we use oxenstored old version
> (that shipped with 4.0.1_21326_06-0.4.1 on sles)
> How can i debug this issue and get more info on this problem?

Play a bit with xenctx to get an idea where the guest is stuck at.

> P.S. Some domains, that has small uptime respond to my check and
> shutdown/migrate correctly.
> 
> -- 
> Vasiliy Tolstov,
> Clodo.ru
> e-mail: v.tolstov@selfip.ru
> jabber: vase@selfip.ru
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 21:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 21: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 1RnGCw-0000zi-UH; Tue, 17 Jan 2012 21:04:42 +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 1RnGCv-0000zd-DJ
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:04:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326834273!11230854!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk2NTIz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9401 invoked from network); 17 Jan 2012 21:04:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 21:04:34 -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
	q0HL4SSx002363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 21:04:29 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
	q0HL4RB2011696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 21:04:28 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
	q0HL4RDo004197; Tue, 17 Jan 2012 15:04:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 13:04:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DFCAD40325; Tue, 17 Jan 2012 16:02:25 -0500 (EST)
Date: Tue, 17 Jan 2012 16:02:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120117210225.GA23782@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1383590207.20120115123259@eikelenboom.it>
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.0A090201.4F15E25D.00A5,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.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

> The thing i was wondering about is if my AMD IOMMU is actually doing something for PV guests.
> When booting with iommu=off machine has 8GB mem, dom0 limited to 1024M and just starting one domU with iommu=soft, with pci-passthrough and the USB pci-cards with USB videograbbers attached to it, i would expect to find some bounce buffering going.
> 
>                 (HV_START_LOW 18446603336221196288)
>                 (FEATURES '!writable_page_tables|pae_pgdir_above_4gb')
>                 (VIRT_BASE 18446744071562067968)
>                 (GUEST_VERSION 2.6)
>                 (PADDR_OFFSET 0)
>                 (GUEST_OS linux)
>                 (HYPERCALL_PAGE 18446744071578849280)
>                 (LOADER generic)
>                 (SUSPEND_CANCEL 1)
>                 (PAE_MODE yes)
>                 (ENTRY 18446744071594476032)
>                 (XEN_VERSION xen-3.0)
> 
> Still i only see:
> 
> [   47.449072] Starting SWIOTLB debug thread.
> [   47.449090] swiotlb_start_thread: Go!
> [   47.449262] xen_swiotlb_start_thread: Go!
> [   52.449158] 0 [ehci_hcd 0000:0a:00.3] bounce: from:432(slow:0)to:1329 map:1756 unmap:1781 sync:0

There is bouncing there.
..
> [  172.449102] 0 [ehci_hcd 0000:0a:00.7] bounce: from:3839(slow:0)to:664 map:4486 unmap:4617 sync:0

And there.. 3839 of them.
> [  172.449123] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:82 map:111 unmap:0 sync:0
> [  172.449130] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:32 map:36 unmap:0 sync:0
> [  172.449170] SWIOTLB is 0% full
> [  177.449109] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5348(slow:0)to:524 map:5834 unmap:5952 sync:0

And 5348 here!

So bounce-buffering is definitly happening with this guest.
.. snip..
> 
> And the devices do work ... so how does that work ...

Most (all?) drivers are written to work with bounce-buffering.
That has never been a problem.

The issue as I understand is that the DVB drivers allocate their buffers
from 0->4GB most (all the time?) so they never have to do bounce-buffering.

While the pv-ops one ends up quite frequently doing the bounce-buffering, which
implies that the DVB drivers end up allocating their buffers above the 4GB.
This means we end up spending some CPU time (in the guest) copying the memory
from >4GB to 0-4GB region (And vice-versa).

And I am not clear why this is happening. Hence my thought
was to run an Xen-O-Linux kernel v2.6.3X and a PVOPS v2.6.3X (where X is the
same) with the same PCI device (and the test would entail rebooting the
box in between the launches) to confirm that the Xen-O-Linux is doing something
that the PVOPS is not.

So far, I've haven't had much luck compiling a Xen-O-Linux v2.6.38 kernel
so :-(

> 
> Thx for your explanation so far !

Sure thing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 21:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 21: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 1RnGCw-0000zi-UH; Tue, 17 Jan 2012 21:04:42 +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 1RnGCv-0000zd-DJ
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:04:41 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326834273!11230854!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk2NTIz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9401 invoked from network); 17 Jan 2012 21:04:34 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 21:04:34 -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
	q0HL4SSx002363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 21:04:29 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
	q0HL4RB2011696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 21:04:28 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
	q0HL4RDo004197; Tue, 17 Jan 2012 15:04:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 13:04:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DFCAD40325; Tue, 17 Jan 2012 16:02:25 -0500 (EST)
Date: Tue, 17 Jan 2012 16:02:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Sander Eikelenboom <linux@eikelenboom.it>
Message-ID: <20120117210225.GA23782@phenom.dumpdata.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1383590207.20120115123259@eikelenboom.it>
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.0A090201.4F15E25D.00A5,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.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

> The thing i was wondering about is if my AMD IOMMU is actually doing something for PV guests.
> When booting with iommu=off machine has 8GB mem, dom0 limited to 1024M and just starting one domU with iommu=soft, with pci-passthrough and the USB pci-cards with USB videograbbers attached to it, i would expect to find some bounce buffering going.
> 
>                 (HV_START_LOW 18446603336221196288)
>                 (FEATURES '!writable_page_tables|pae_pgdir_above_4gb')
>                 (VIRT_BASE 18446744071562067968)
>                 (GUEST_VERSION 2.6)
>                 (PADDR_OFFSET 0)
>                 (GUEST_OS linux)
>                 (HYPERCALL_PAGE 18446744071578849280)
>                 (LOADER generic)
>                 (SUSPEND_CANCEL 1)
>                 (PAE_MODE yes)
>                 (ENTRY 18446744071594476032)
>                 (XEN_VERSION xen-3.0)
> 
> Still i only see:
> 
> [   47.449072] Starting SWIOTLB debug thread.
> [   47.449090] swiotlb_start_thread: Go!
> [   47.449262] xen_swiotlb_start_thread: Go!
> [   52.449158] 0 [ehci_hcd 0000:0a:00.3] bounce: from:432(slow:0)to:1329 map:1756 unmap:1781 sync:0

There is bouncing there.
..
> [  172.449102] 0 [ehci_hcd 0000:0a:00.7] bounce: from:3839(slow:0)to:664 map:4486 unmap:4617 sync:0

And there.. 3839 of them.
> [  172.449123] 1 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:82 map:111 unmap:0 sync:0
> [  172.449130] 2 [ehci_hcd 0000:0a:00.7] bounce: from:0(slow:0)to:32 map:36 unmap:0 sync:0
> [  172.449170] SWIOTLB is 0% full
> [  177.449109] 0 [ehci_hcd 0000:0a:00.7] bounce: from:5348(slow:0)to:524 map:5834 unmap:5952 sync:0

And 5348 here!

So bounce-buffering is definitly happening with this guest.
.. snip..
> 
> And the devices do work ... so how does that work ...

Most (all?) drivers are written to work with bounce-buffering.
That has never been a problem.

The issue as I understand is that the DVB drivers allocate their buffers
from 0->4GB most (all the time?) so they never have to do bounce-buffering.

While the pv-ops one ends up quite frequently doing the bounce-buffering, which
implies that the DVB drivers end up allocating their buffers above the 4GB.
This means we end up spending some CPU time (in the guest) copying the memory
from >4GB to 0-4GB region (And vice-versa).

And I am not clear why this is happening. Hence my thought
was to run an Xen-O-Linux kernel v2.6.3X and a PVOPS v2.6.3X (where X is the
same) with the same PCI device (and the test would entail rebooting the
box in between the launches) to confirm that the Xen-O-Linux is doing something
that the PVOPS is not.

So far, I've haven't had much luck compiling a Xen-O-Linux v2.6.38 kernel
so :-(

> 
> Thx for your explanation so far !

Sure thing.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 21:17:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 21: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 1RnGOQ-0001ZP-QA; Tue, 17 Jan 2012 21:16:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RnGOP-0001W6-E3
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:16:33 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326834986!11302519!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14983 invoked from network); 17 Jan 2012 21:16:27 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 21:16:27 -0000
Received: by lago2 with SMTP id o2so2597751lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 13:16:26 -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=xuG4O4RYS1eKZCSySEmtWIHX2GPahU2GkbVWA2yKXfY=;
	b=ZQ1dwwbpTaXxLf2LHmvSsn6JNNfwTQAPvG+m6hAOpF2lXMtB7RG5lKIA/T2dGggAV+
	oowZGDhRkEakEZTtwQ2m5yKwIrePZz6mbkvmnfuyka/xSzr/8+3W1LMFZ1UgVpGq/M+N
	2lFVFxVl8qtiXDvvd/z0ZVmg7M5Pu2i18Dr0Q=
Received: by 10.112.86.135 with SMTP id p7mr4434970lbz.86.1326834986305; Tue,
	17 Jan 2012 13:16:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Tue, 17 Jan 2012 13:16:10 -0800 (PST)
X-Originating-IP: [78.37.224.60]
In-Reply-To: <20120117201525.GB25805@andromeda.dapyr.net>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Wed, 18 Jan 2012 01:16:10 +0400
X-Google-Sender-Auth: dg_D9vqzJBXAIfi3pSRlVubKciU
Message-ID: <CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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

2012/1/18 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> On Tue, Jan 17, 2012 at 12:58:14PM +0400, Vasiliy Tolstov wrote:
>> Hello. Today i'm try to research, why most of our vm (pvm) not
>> shutdown correctly (we use shutdown with timeout, then it arrives we
>> destroy vm), and write simple test case to check that domU watches
>
> Which kernel version of DomU?

2.6.32.26 from xen git tree and  2.6.18-194.26.1.el5xen


>
> Play a bit with xenctx to get an idea where the guest is stuck at.
>

Ok, nice. When i need to run xenctx and what i need to see in its output?

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 21:17:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 21: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 1RnGOQ-0001ZP-QA; Tue, 17 Jan 2012 21:16:34 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RnGOP-0001W6-E3
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:16:33 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326834986!11302519!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14983 invoked from network); 17 Jan 2012 21:16:27 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	17 Jan 2012 21:16:27 -0000
Received: by lago2 with SMTP id o2so2597751lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 13:16:26 -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=xuG4O4RYS1eKZCSySEmtWIHX2GPahU2GkbVWA2yKXfY=;
	b=ZQ1dwwbpTaXxLf2LHmvSsn6JNNfwTQAPvG+m6hAOpF2lXMtB7RG5lKIA/T2dGggAV+
	oowZGDhRkEakEZTtwQ2m5yKwIrePZz6mbkvmnfuyka/xSzr/8+3W1LMFZ1UgVpGq/M+N
	2lFVFxVl8qtiXDvvd/z0ZVmg7M5Pu2i18Dr0Q=
Received: by 10.112.86.135 with SMTP id p7mr4434970lbz.86.1326834986305; Tue,
	17 Jan 2012 13:16:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Tue, 17 Jan 2012 13:16:10 -0800 (PST)
X-Originating-IP: [78.37.224.60]
In-Reply-To: <20120117201525.GB25805@andromeda.dapyr.net>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Wed, 18 Jan 2012 01:16:10 +0400
X-Google-Sender-Auth: dg_D9vqzJBXAIfi3pSRlVubKciU
Message-ID: <CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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

2012/1/18 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> On Tue, Jan 17, 2012 at 12:58:14PM +0400, Vasiliy Tolstov wrote:
>> Hello. Today i'm try to research, why most of our vm (pvm) not
>> shutdown correctly (we use shutdown with timeout, then it arrives we
>> destroy vm), and write simple test case to check that domU watches
>
> Which kernel version of DomU?

2.6.32.26 from xen git tree and  2.6.18-194.26.1.el5xen


>
> Play a bit with xenctx to get an idea where the guest is stuck at.
>

Ok, nice. When i need to run xenctx and what i need to see in its output?

-- 
Vasiliy Tolstov,
Clodo.ru
e-mail: v.tolstov@selfip.ru
jabber: vase@selfip.ru

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 21:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 21:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnGnn-0002Av-Mz; Tue, 17 Jan 2012 21:42:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tina.yang@oracle.com>) id 1RnGnl-0002Ac-Eq
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:42:45 +0000
X-Env-Sender: tina.yang@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326836557!2191416!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27210 invoked from network); 17 Jan 2012 21:42:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 21:42:38 -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
	q0HLgW5P017361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 21:42:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0HLgTpP013263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 21:42:30 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
	q0HLgRHf009690; Tue, 17 Jan 2012 15:42:28 -0600
Received: from [10.159.220.138] (/10.159.220.138)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 13:42:27 -0800
Message-ID: <4F15EB3E.3060700@oracle.com>
Date: Tue, 17 Jan 2012 13:42:22 -0800
From: Tina Yang <tina.yang@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326452769.17210.331.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F15EB4A.0080,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/13/2012 3:06 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 14:17 +0000, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
>>> add polling interface to xen-netfront device to support netconsole
>>>
>> Ian, any thoughts on the spinlock changes?
> What are they for?
When I did this patch back in 2008, both netconsole and netdump
were supported.  Spin_lock w/o irqsave and irqrestore would cause
netdump hang due to the unexpected change of the irq status.
Although netdump is now obsolete, I think it's always a good practice
to preserve caller's irq status as we had a very bad experience
chasing a similar problem caused by such a irq change in RDS
in the not too long ago past.
> At a guess they are a necessary consequence of the new calling context.
> However not all the drivers I looked at which supported netpool were
> using the irqsave variants in this context so I guess it must be some
> secondary effect.
>
> Anyway, the upshot is that I think the changelog needs to explain the
> rationale for the locking change.
>
> Ian.
>
>>> Signed-off-by: Tina.Yang<tina.yang@oracle.com>
>>> Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>>> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
>>> Signed-off-by: Zhenzhong.Duan<zhenzhong.duan@oracle.com>
>>> Tested-by: gurudas.pai<gurudas.pai@oracle.com>
>>> ---
>>>   drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
>>>   1 files changed, 34 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>> index fa67905..db638b4 100644
>>> --- a/drivers/net/xen-netfront.c
>>> +++ b/drivers/net/xen-netfront.c
>>> @@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>   	int frags = skb_shinfo(skb)->nr_frags;
>>>   	unsigned int offset = offset_in_page(data);
>>>   	unsigned int len = skb_headlen(skb);
>>> +	unsigned long flags;
>>>
>>>   	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
>>>   	if (unlikely(frags>  MAX_SKB_FRAGS + 1)) {
>>> @@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>   		goto drop;
>>>   	}
>>>
>>> -	spin_lock_irq(&np->tx_lock);
>>> +	spin_lock_irqsave(&np->tx_lock, flags);
>>>
>>>   	if (unlikely(!netif_carrier_ok(dev) ||
>>>   		     (frags>  1&&  !xennet_can_sg(dev)) ||
>>>   		     netif_needs_gso(skb, netif_skb_features(skb)))) {
>>> -		spin_unlock_irq(&np->tx_lock);
>>> +		spin_unlock_irqrestore(&np->tx_lock, flags);
>>>   		goto drop;
>>>   	}
>>>
>>> @@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>   	if (!netfront_tx_slot_available(np))
>>>   		netif_stop_queue(dev);
>>>
>>> -	spin_unlock_irq(&np->tx_lock);
>>> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>>>
>>>   	return NETDEV_TX_OK;
>>>
>>> @@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
>>>   	return 0;
>>>   }
>>>
>>> +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
>>> +{
>>> +	struct net_device *dev = dev_id;
>>> +	struct netfront_info *np = netdev_priv(dev);
>>> +	unsigned long flags;
>>> +
>>> +	spin_lock_irqsave(&np->tx_lock, flags);
>>> +
>>> +	if (likely(netif_carrier_ok(dev))) {
>>> +		xennet_tx_buf_gc(dev);
>>> +		/* Under tx_lock: protects access to rx shared-ring indexes. */
>>> +		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
>>> +			napi_schedule(&np->napi);
>>> +	}
>>> +
>>> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>>> +
>>> +	return IRQ_HANDLED;
>>> +}
>>> +
>>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>>> +static void xennet_poll_controller(struct net_device *dev)
>>> +{
>>> +	xennet_interrupt(0, dev);
>>> +}
>>> +#endif
>>> +
>>>   static const struct net_device_ops xennet_netdev_ops = {
>>>   	.ndo_open            = xennet_open,
>>>   	.ndo_uninit          = xennet_uninit,
>>> @@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
>>>   	.ndo_validate_addr   = eth_validate_addr,
>>>   	.ndo_fix_features    = xennet_fix_features,
>>>   	.ndo_set_features    = xennet_set_features,
>>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>>> +	.ndo_poll_controller = xennet_poll_controller,
>>> +#endif
>>>   };
>>>
>>>   static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
>>> @@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
>>>   	return 0;
>>>   }
>>>
>>> -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
>>> -{
>>> -	struct net_device *dev = dev_id;
>>> -	struct netfront_info *np = netdev_priv(dev);
>>> -	unsigned long flags;
>>> -
>>> -	spin_lock_irqsave(&np->tx_lock, flags);
>>> -
>>> -	if (likely(netif_carrier_ok(dev))) {
>>> -		xennet_tx_buf_gc(dev);
>>> -		/* Under tx_lock: protects access to rx shared-ring indexes. */
>>> -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
>>> -			napi_schedule(&np->napi);
>>> -	}
>>> -
>>> -	spin_unlock_irqrestore(&np->tx_lock, flags);
>>> -
>>> -	return IRQ_HANDLED;
>>> -}
>>> -
>>>   static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>>>   {
>>>   	struct xen_netif_tx_sring *txs;
>>> -- 
>>> 1.7.3
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 21:43:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 21:43:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnGnn-0002Av-Mz; Tue, 17 Jan 2012 21:42:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tina.yang@oracle.com>) id 1RnGnl-0002Ac-Eq
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:42:45 +0000
X-Env-Sender: tina.yang@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326836557!2191416!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk1MDU5\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27210 invoked from network); 17 Jan 2012 21:42:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 21:42:38 -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
	q0HLgW5P017361
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 21:42:33 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0HLgTpP013263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 21:42:30 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
	q0HLgRHf009690; Tue, 17 Jan 2012 15:42:28 -0600
Received: from [10.159.220.138] (/10.159.220.138)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 13:42:27 -0800
Message-ID: <4F15EB3E.3060700@oracle.com>
Date: Tue, 17 Jan 2012 13:42:22 -0800
From: Tina Yang <tina.yang@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326452769.17210.331.camel@zakaz.uk.xensource.com>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F15EB4A.0080,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/13/2012 3:06 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 14:17 +0000, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
>>> add polling interface to xen-netfront device to support netconsole
>>>
>> Ian, any thoughts on the spinlock changes?
> What are they for?
When I did this patch back in 2008, both netconsole and netdump
were supported.  Spin_lock w/o irqsave and irqrestore would cause
netdump hang due to the unexpected change of the irq status.
Although netdump is now obsolete, I think it's always a good practice
to preserve caller's irq status as we had a very bad experience
chasing a similar problem caused by such a irq change in RDS
in the not too long ago past.
> At a guess they are a necessary consequence of the new calling context.
> However not all the drivers I looked at which supported netpool were
> using the irqsave variants in this context so I guess it must be some
> secondary effect.
>
> Anyway, the upshot is that I think the changelog needs to explain the
> rationale for the locking change.
>
> Ian.
>
>>> Signed-off-by: Tina.Yang<tina.yang@oracle.com>
>>> Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>>> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
>>> Signed-off-by: Zhenzhong.Duan<zhenzhong.duan@oracle.com>
>>> Tested-by: gurudas.pai<gurudas.pai@oracle.com>
>>> ---
>>>   drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
>>>   1 files changed, 34 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>> index fa67905..db638b4 100644
>>> --- a/drivers/net/xen-netfront.c
>>> +++ b/drivers/net/xen-netfront.c
>>> @@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>   	int frags = skb_shinfo(skb)->nr_frags;
>>>   	unsigned int offset = offset_in_page(data);
>>>   	unsigned int len = skb_headlen(skb);
>>> +	unsigned long flags;
>>>
>>>   	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
>>>   	if (unlikely(frags>  MAX_SKB_FRAGS + 1)) {
>>> @@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>   		goto drop;
>>>   	}
>>>
>>> -	spin_lock_irq(&np->tx_lock);
>>> +	spin_lock_irqsave(&np->tx_lock, flags);
>>>
>>>   	if (unlikely(!netif_carrier_ok(dev) ||
>>>   		     (frags>  1&&  !xennet_can_sg(dev)) ||
>>>   		     netif_needs_gso(skb, netif_skb_features(skb)))) {
>>> -		spin_unlock_irq(&np->tx_lock);
>>> +		spin_unlock_irqrestore(&np->tx_lock, flags);
>>>   		goto drop;
>>>   	}
>>>
>>> @@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>   	if (!netfront_tx_slot_available(np))
>>>   		netif_stop_queue(dev);
>>>
>>> -	spin_unlock_irq(&np->tx_lock);
>>> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>>>
>>>   	return NETDEV_TX_OK;
>>>
>>> @@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
>>>   	return 0;
>>>   }
>>>
>>> +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
>>> +{
>>> +	struct net_device *dev = dev_id;
>>> +	struct netfront_info *np = netdev_priv(dev);
>>> +	unsigned long flags;
>>> +
>>> +	spin_lock_irqsave(&np->tx_lock, flags);
>>> +
>>> +	if (likely(netif_carrier_ok(dev))) {
>>> +		xennet_tx_buf_gc(dev);
>>> +		/* Under tx_lock: protects access to rx shared-ring indexes. */
>>> +		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
>>> +			napi_schedule(&np->napi);
>>> +	}
>>> +
>>> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>>> +
>>> +	return IRQ_HANDLED;
>>> +}
>>> +
>>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>>> +static void xennet_poll_controller(struct net_device *dev)
>>> +{
>>> +	xennet_interrupt(0, dev);
>>> +}
>>> +#endif
>>> +
>>>   static const struct net_device_ops xennet_netdev_ops = {
>>>   	.ndo_open            = xennet_open,
>>>   	.ndo_uninit          = xennet_uninit,
>>> @@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
>>>   	.ndo_validate_addr   = eth_validate_addr,
>>>   	.ndo_fix_features    = xennet_fix_features,
>>>   	.ndo_set_features    = xennet_set_features,
>>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>>> +	.ndo_poll_controller = xennet_poll_controller,
>>> +#endif
>>>   };
>>>
>>>   static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
>>> @@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
>>>   	return 0;
>>>   }
>>>
>>> -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
>>> -{
>>> -	struct net_device *dev = dev_id;
>>> -	struct netfront_info *np = netdev_priv(dev);
>>> -	unsigned long flags;
>>> -
>>> -	spin_lock_irqsave(&np->tx_lock, flags);
>>> -
>>> -	if (likely(netif_carrier_ok(dev))) {
>>> -		xennet_tx_buf_gc(dev);
>>> -		/* Under tx_lock: protects access to rx shared-ring indexes. */
>>> -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
>>> -			napi_schedule(&np->napi);
>>> -	}
>>> -
>>> -	spin_unlock_irqrestore(&np->tx_lock, flags);
>>> -
>>> -	return IRQ_HANDLED;
>>> -}
>>> -
>>>   static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>>>   {
>>>   	struct xen_netif_tx_sring *txs;
>>> -- 
>>> 1.7.3
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 21:53:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 21: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 1RnGxr-0002Vy-RC; Tue, 17 Jan 2012 21:53:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RnGxq-0002Vq-Ne
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:53:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326837122!61397415!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk2NTIz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31213 invoked from network); 17 Jan 2012 21:52:03 -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; 17 Jan 2012 21:52:03 -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
	q0HLr3nP030580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 21:53:04 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
	q0HLr3da026604
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 21:53:03 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
	q0HLr2Dm024519; Tue, 17 Jan 2012 15:53:02 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 13:53:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 207A540325; Tue, 17 Jan 2012 16:51:00 -0500 (EST)
Date: Tue, 17 Jan 2012 16:51:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tina Yang <tina.yang@oracle.com>
Message-ID: <20120117215100.GA25367@phenom.dumpdata.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F15EB3E.3060700@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.0A090209.4F15EDC1.0098,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
> On 1/13/2012 3:06 AM, Ian Campbell wrote:
> >On Thu, 2012-01-12 at 14:17 +0000, Konrad Rzeszutek Wilk wrote:
> >>On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
> >>>add polling interface to xen-netfront device to support netconsole
> >>>
> >>Ian, any thoughts on the spinlock changes?
> >What are they for?
> When I did this patch back in 2008, both netconsole and netdump
> were supported.  Spin_lock w/o irqsave and irqrestore would cause
> netdump hang due to the unexpected change of the irq status.

Hm, that might have been due to the bug that was lurking in there since
2.6.27: d198d499148a0c64a41b3aba9e7dd43772832b91 "xen: x86_32: do not enable iterrupts when returning from exception in interrupt context"

> Although netdump is now obsolete, I think it's always a good practice
> to preserve caller's irq status as we had a very bad experience
> chasing a similar problem caused by such a irq change in RDS

Did you find the culprit of it? Was there a patch for that in the
upstream kernel?

> in the not too long ago past.

OK, it sounds like it was issues in the past but might not be the
case anymore.

Could please re-test it without that spinlock irqsave patch using
the upstream kernel (or just UEK2 since it is an 3.0 type kernel).

Thanks.

> >At a guess they are a necessary consequence of the new calling context.
> >However not all the drivers I looked at which supported netpool were
> >using the irqsave variants in this context so I guess it must be some
> >secondary effect.
> >
> >Anyway, the upshot is that I think the changelog needs to explain the
> >rationale for the locking change.
> >
> >Ian.
> >
> >>>Signed-off-by: Tina.Yang<tina.yang@oracle.com>
> >>>Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
> >>>Cc: Jeremy Fitzhardinge<jeremy@goop.org>
> >>>Signed-off-by: Zhenzhong.Duan<zhenzhong.duan@oracle.com>
> >>>Tested-by: gurudas.pai<gurudas.pai@oracle.com>
> >>>---
> >>>  drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
> >>>  1 files changed, 34 insertions(+), 23 deletions(-)
> >>>
> >>>diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> >>>index fa67905..db638b4 100644
> >>>--- a/drivers/net/xen-netfront.c
> >>>+++ b/drivers/net/xen-netfront.c
> >>>@@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >>>  	int frags = skb_shinfo(skb)->nr_frags;
> >>>  	unsigned int offset = offset_in_page(data);
> >>>  	unsigned int len = skb_headlen(skb);
> >>>+	unsigned long flags;
> >>>
> >>>  	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
> >>>  	if (unlikely(frags>  MAX_SKB_FRAGS + 1)) {
> >>>@@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >>>  		goto drop;
> >>>  	}
> >>>
> >>>-	spin_lock_irq(&np->tx_lock);
> >>>+	spin_lock_irqsave(&np->tx_lock, flags);
> >>>
> >>>  	if (unlikely(!netif_carrier_ok(dev) ||
> >>>  		     (frags>  1&&  !xennet_can_sg(dev)) ||
> >>>  		     netif_needs_gso(skb, netif_skb_features(skb)))) {
> >>>-		spin_unlock_irq(&np->tx_lock);
> >>>+		spin_unlock_irqrestore(&np->tx_lock, flags);
> >>>  		goto drop;
> >>>  	}
> >>>
> >>>@@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >>>  	if (!netfront_tx_slot_available(np))
> >>>  		netif_stop_queue(dev);
> >>>
> >>>-	spin_unlock_irq(&np->tx_lock);
> >>>+	spin_unlock_irqrestore(&np->tx_lock, flags);
> >>>
> >>>  	return NETDEV_TX_OK;
> >>>
> >>>@@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
> >>>  	return 0;
> >>>  }
> >>>
> >>>+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> >>>+{
> >>>+	struct net_device *dev = dev_id;
> >>>+	struct netfront_info *np = netdev_priv(dev);
> >>>+	unsigned long flags;
> >>>+
> >>>+	spin_lock_irqsave(&np->tx_lock, flags);
> >>>+
> >>>+	if (likely(netif_carrier_ok(dev))) {
> >>>+		xennet_tx_buf_gc(dev);
> >>>+		/* Under tx_lock: protects access to rx shared-ring indexes. */
> >>>+		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> >>>+			napi_schedule(&np->napi);
> >>>+	}
> >>>+
> >>>+	spin_unlock_irqrestore(&np->tx_lock, flags);
> >>>+
> >>>+	return IRQ_HANDLED;
> >>>+}
> >>>+
> >>>+#ifdef CONFIG_NET_POLL_CONTROLLER
> >>>+static void xennet_poll_controller(struct net_device *dev)
> >>>+{
> >>>+	xennet_interrupt(0, dev);
> >>>+}
> >>>+#endif
> >>>+
> >>>  static const struct net_device_ops xennet_netdev_ops = {
> >>>  	.ndo_open            = xennet_open,
> >>>  	.ndo_uninit          = xennet_uninit,
> >>>@@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
> >>>  	.ndo_validate_addr   = eth_validate_addr,
> >>>  	.ndo_fix_features    = xennet_fix_features,
> >>>  	.ndo_set_features    = xennet_set_features,
> >>>+#ifdef CONFIG_NET_POLL_CONTROLLER
> >>>+	.ndo_poll_controller = xennet_poll_controller,
> >>>+#endif
> >>>  };
> >>>
> >>>  static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
> >>>@@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
> >>>  	return 0;
> >>>  }
> >>>
> >>>-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> >>>-{
> >>>-	struct net_device *dev = dev_id;
> >>>-	struct netfront_info *np = netdev_priv(dev);
> >>>-	unsigned long flags;
> >>>-
> >>>-	spin_lock_irqsave(&np->tx_lock, flags);
> >>>-
> >>>-	if (likely(netif_carrier_ok(dev))) {
> >>>-		xennet_tx_buf_gc(dev);
> >>>-		/* Under tx_lock: protects access to rx shared-ring indexes. */
> >>>-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> >>>-			napi_schedule(&np->napi);
> >>>-	}
> >>>-
> >>>-	spin_unlock_irqrestore(&np->tx_lock, flags);
> >>>-
> >>>-	return IRQ_HANDLED;
> >>>-}
> >>>-
> >>>  static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >>>  {
> >>>  	struct xen_netif_tx_sring *txs;
> >>>-- 
> >>>1.7.3
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 21:53:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 21: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 1RnGxr-0002Vy-RC; Tue, 17 Jan 2012 21:53:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RnGxq-0002Vq-Ne
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:53:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326837122!61397415!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk2NTIz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31213 invoked from network); 17 Jan 2012 21:52:03 -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; 17 Jan 2012 21:52:03 -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
	q0HLr3nP030580
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 21:53:04 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
	q0HLr3da026604
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 21:53:03 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
	q0HLr2Dm024519; Tue, 17 Jan 2012 15:53:02 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 13:53:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 207A540325; Tue, 17 Jan 2012 16:51:00 -0500 (EST)
Date: Tue, 17 Jan 2012 16:51:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tina Yang <tina.yang@oracle.com>
Message-ID: <20120117215100.GA25367@phenom.dumpdata.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F15EB3E.3060700@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.0A090209.4F15EDC1.0098,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
> On 1/13/2012 3:06 AM, Ian Campbell wrote:
> >On Thu, 2012-01-12 at 14:17 +0000, Konrad Rzeszutek Wilk wrote:
> >>On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
> >>>add polling interface to xen-netfront device to support netconsole
> >>>
> >>Ian, any thoughts on the spinlock changes?
> >What are they for?
> When I did this patch back in 2008, both netconsole and netdump
> were supported.  Spin_lock w/o irqsave and irqrestore would cause
> netdump hang due to the unexpected change of the irq status.

Hm, that might have been due to the bug that was lurking in there since
2.6.27: d198d499148a0c64a41b3aba9e7dd43772832b91 "xen: x86_32: do not enable iterrupts when returning from exception in interrupt context"

> Although netdump is now obsolete, I think it's always a good practice
> to preserve caller's irq status as we had a very bad experience
> chasing a similar problem caused by such a irq change in RDS

Did you find the culprit of it? Was there a patch for that in the
upstream kernel?

> in the not too long ago past.

OK, it sounds like it was issues in the past but might not be the
case anymore.

Could please re-test it without that spinlock irqsave patch using
the upstream kernel (or just UEK2 since it is an 3.0 type kernel).

Thanks.

> >At a guess they are a necessary consequence of the new calling context.
> >However not all the drivers I looked at which supported netpool were
> >using the irqsave variants in this context so I guess it must be some
> >secondary effect.
> >
> >Anyway, the upshot is that I think the changelog needs to explain the
> >rationale for the locking change.
> >
> >Ian.
> >
> >>>Signed-off-by: Tina.Yang<tina.yang@oracle.com>
> >>>Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
> >>>Cc: Jeremy Fitzhardinge<jeremy@goop.org>
> >>>Signed-off-by: Zhenzhong.Duan<zhenzhong.duan@oracle.com>
> >>>Tested-by: gurudas.pai<gurudas.pai@oracle.com>
> >>>---
> >>>  drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
> >>>  1 files changed, 34 insertions(+), 23 deletions(-)
> >>>
> >>>diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> >>>index fa67905..db638b4 100644
> >>>--- a/drivers/net/xen-netfront.c
> >>>+++ b/drivers/net/xen-netfront.c
> >>>@@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >>>  	int frags = skb_shinfo(skb)->nr_frags;
> >>>  	unsigned int offset = offset_in_page(data);
> >>>  	unsigned int len = skb_headlen(skb);
> >>>+	unsigned long flags;
> >>>
> >>>  	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
> >>>  	if (unlikely(frags>  MAX_SKB_FRAGS + 1)) {
> >>>@@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >>>  		goto drop;
> >>>  	}
> >>>
> >>>-	spin_lock_irq(&np->tx_lock);
> >>>+	spin_lock_irqsave(&np->tx_lock, flags);
> >>>
> >>>  	if (unlikely(!netif_carrier_ok(dev) ||
> >>>  		     (frags>  1&&  !xennet_can_sg(dev)) ||
> >>>  		     netif_needs_gso(skb, netif_skb_features(skb)))) {
> >>>-		spin_unlock_irq(&np->tx_lock);
> >>>+		spin_unlock_irqrestore(&np->tx_lock, flags);
> >>>  		goto drop;
> >>>  	}
> >>>
> >>>@@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >>>  	if (!netfront_tx_slot_available(np))
> >>>  		netif_stop_queue(dev);
> >>>
> >>>-	spin_unlock_irq(&np->tx_lock);
> >>>+	spin_unlock_irqrestore(&np->tx_lock, flags);
> >>>
> >>>  	return NETDEV_TX_OK;
> >>>
> >>>@@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
> >>>  	return 0;
> >>>  }
> >>>
> >>>+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> >>>+{
> >>>+	struct net_device *dev = dev_id;
> >>>+	struct netfront_info *np = netdev_priv(dev);
> >>>+	unsigned long flags;
> >>>+
> >>>+	spin_lock_irqsave(&np->tx_lock, flags);
> >>>+
> >>>+	if (likely(netif_carrier_ok(dev))) {
> >>>+		xennet_tx_buf_gc(dev);
> >>>+		/* Under tx_lock: protects access to rx shared-ring indexes. */
> >>>+		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> >>>+			napi_schedule(&np->napi);
> >>>+	}
> >>>+
> >>>+	spin_unlock_irqrestore(&np->tx_lock, flags);
> >>>+
> >>>+	return IRQ_HANDLED;
> >>>+}
> >>>+
> >>>+#ifdef CONFIG_NET_POLL_CONTROLLER
> >>>+static void xennet_poll_controller(struct net_device *dev)
> >>>+{
> >>>+	xennet_interrupt(0, dev);
> >>>+}
> >>>+#endif
> >>>+
> >>>  static const struct net_device_ops xennet_netdev_ops = {
> >>>  	.ndo_open            = xennet_open,
> >>>  	.ndo_uninit          = xennet_uninit,
> >>>@@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
> >>>  	.ndo_validate_addr   = eth_validate_addr,
> >>>  	.ndo_fix_features    = xennet_fix_features,
> >>>  	.ndo_set_features    = xennet_set_features,
> >>>+#ifdef CONFIG_NET_POLL_CONTROLLER
> >>>+	.ndo_poll_controller = xennet_poll_controller,
> >>>+#endif
> >>>  };
> >>>
> >>>  static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
> >>>@@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
> >>>  	return 0;
> >>>  }
> >>>
> >>>-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> >>>-{
> >>>-	struct net_device *dev = dev_id;
> >>>-	struct netfront_info *np = netdev_priv(dev);
> >>>-	unsigned long flags;
> >>>-
> >>>-	spin_lock_irqsave(&np->tx_lock, flags);
> >>>-
> >>>-	if (likely(netif_carrier_ok(dev))) {
> >>>-		xennet_tx_buf_gc(dev);
> >>>-		/* Under tx_lock: protects access to rx shared-ring indexes. */
> >>>-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> >>>-			napi_schedule(&np->napi);
> >>>-	}
> >>>-
> >>>-	spin_unlock_irqrestore(&np->tx_lock, flags);
> >>>-
> >>>-	return IRQ_HANDLED;
> >>>-}
> >>>-
> >>>  static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >>>  {
> >>>  	struct xen_netif_tx_sring *txs;
> >>>-- 
> >>>1.7.3
> >

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 22:04:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 22:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnH7j-0002lE-8L; Tue, 17 Jan 2012 22:03:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnH7h-0002l9-KQ
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 22:03:21 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326837753!48988041!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 534 invoked from network); 17 Jan 2012 22:02:34 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 22:02:34 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HM2T6R017156;
	Tue, 17 Jan 2012 17:02:29 -0500
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 17 Jan 2012 17:02:08 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451B0@mnetexch2.adamapps.host>
In-Reply-To: <20120117201245.GA25805@andromeda.dapyr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding to the domain
Thread-Index: AczVVRh0AMvV6DJATViZXzg7U7pupQADcWRw
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
	<1326809782.14689.114.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
	<20120117201245.GA25805@andromeda.dapyr.net>
From: <djmagee@mageenet.net>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Tuesday, January 17, 2012 3:13 PM
> To: djmagee@mageenet.net
> Cc: Ian Campbell; xen-devel@lists.xensource.com; Ian Jackson; Stefano
> Stabellini
> Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
> assignable before adding to the domain
> 
> On Tue, Jan 17, 2012 at 09:24:39AM -0500, djmagee@mageenet.net wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Tuesday, January 17, 2012 9:16 AM
> > > To: djmagee@mageenet.net
> > > Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> > > Subject: RE: [Xen-devel] [PATCH] libxl_pci: check that host device
> is
> > > assignable before adding to the domain
> > >
> > > Please don't top post.
> > >
> > > On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> > > > That was my first thought, but this was also the first thing in
> libxl
> > > > I touched and wasn't sure what would happen if I ended up
nesting
> > > > GC_INITs.  If it's safe to do then I can call
> > > > libxl_device_pci_list_assignable, otherwise I'd have to pull the
> meat
> > > > out and put it in another function.  What's the best way to do
> it?
> > >
> > > You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get
a
> ctx
> > > from a gc which you use to call an externally visible function
from
> > > within libxl -- it'll do the right thing (TM).
> >
> > Cool, I'll send an updated patch along today.
> 
> You might want to check for 'xen-pciback', 'pciback' and 'pci-stub'
> as they are valid.

Agreed. I posted an updated patch that calls ..._list_assignable instead
of looping through the directory itself.  I'll work on a separate patch
to update that function to check all applicable places.

In the 3.2.1 kernel I'm using, the module name is xen-pcipack, but the
sysfs directory is just pciback.  Is there an instance where the
directory is called xen-pcipack?

> >
> > Doug
> >
> > >
> > > Ian.
> > >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 22:04:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 22:04:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnH7j-0002lE-8L; Tue, 17 Jan 2012 22:03:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RnH7h-0002l9-KQ
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 22:03:21 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326837753!48988041!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 534 invoked from network); 17 Jan 2012 22:02:34 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 22:02:34 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0HM2T6R017156;
	Tue, 17 Jan 2012 17:02:29 -0500
MIME-Version: 1.0
Content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 17 Jan 2012 17:02:08 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451B0@mnetexch2.adamapps.host>
In-Reply-To: <20120117201245.GA25805@andromeda.dapyr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding to the domain
Thread-Index: AczVVRh0AMvV6DJATViZXzg7U7pupQADcWRw
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
	<1326809782.14689.114.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
	<20120117201245.GA25805@andromeda.dapyr.net>
From: <djmagee@mageenet.net>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> Sent: Tuesday, January 17, 2012 3:13 PM
> To: djmagee@mageenet.net
> Cc: Ian Campbell; xen-devel@lists.xensource.com; Ian Jackson; Stefano
> Stabellini
> Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
> assignable before adding to the domain
> 
> On Tue, Jan 17, 2012 at 09:24:39AM -0500, djmagee@mageenet.net wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > Sent: Tuesday, January 17, 2012 9:16 AM
> > > To: djmagee@mageenet.net
> > > Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> > > Subject: RE: [Xen-devel] [PATCH] libxl_pci: check that host device
> is
> > > assignable before adding to the domain
> > >
> > > Please don't top post.
> > >
> > > On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> > > > That was my first thought, but this was also the first thing in
> libxl
> > > > I touched and wasn't sure what would happen if I ended up
nesting
> > > > GC_INITs.  If it's safe to do then I can call
> > > > libxl_device_pci_list_assignable, otherwise I'd have to pull the
> meat
> > > > out and put it in another function.  What's the best way to do
> it?
> > >
> > > You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get
a
> ctx
> > > from a gc which you use to call an externally visible function
from
> > > within libxl -- it'll do the right thing (TM).
> >
> > Cool, I'll send an updated patch along today.
> 
> You might want to check for 'xen-pciback', 'pciback' and 'pci-stub'
> as they are valid.

Agreed. I posted an updated patch that calls ..._list_assignable instead
of looping through the directory itself.  I'll work on a separate patch
to update that function to check all applicable places.

In the 3.2.1 kernel I'm using, the module name is xen-pcipack, but the
sysfs directory is just pciback.  Is there an instance where the
directory is called xen-pcipack?

> >
> > Doug
> >
> > >
> > > Ian.
> > >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 22:28:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 22:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnHVM-00038Q-3V; Tue, 17 Jan 2012 22:27:48 +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 1RnHVK-00037n-R6
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 22:27:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326839260!11307382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 420 invoked from network); 17 Jan 2012 22:27:40 -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;
	17 Jan 2012 22:27:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,525,1320624000"; d="scan'208";a="10101160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 22:27:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 22:27: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 1RnHVD-000813-Vc;
	Tue, 17 Jan 2012 22:27:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnHVD-0000zb-TN;
	Tue, 17 Jan 2012 22:27:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10861-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 22:27:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10861: 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 10861 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10861/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  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-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-i386-xend-winxpsp3  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-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-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-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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 870 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 Jan 17 22:28:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 22:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnHVM-00038Q-3V; Tue, 17 Jan 2012 22:27:48 +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 1RnHVK-00037n-R6
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 22:27:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326839260!11307382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTU0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 420 invoked from network); 17 Jan 2012 22:27:40 -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;
	17 Jan 2012 22:27:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,525,1320624000"; d="scan'208";a="10101160"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 22:27:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 22:27: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 1RnHVD-000813-Vc;
	Tue, 17 Jan 2012 22:27:40 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnHVD-0000zb-TN;
	Tue, 17 Jan 2012 22:27:39 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10861-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 22:27:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10861: 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 10861 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10861/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  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-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-i386-xend-winxpsp3  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-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-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-win7-amd64  1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@intel.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  fail    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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 870 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 Jan 17 23:16:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 23:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnIFv-0004G3-BU; Tue, 17 Jan 2012 23:15:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tina.yang@oracle.com>) id 1RnIFu-0004FK-66
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 23:15:54 +0000
X-Env-Sender: tina.yang@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326842146!2624781!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk2NTIz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6754 invoked from network); 17 Jan 2012 23:15:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 23:15:47 -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
	q0HNFej3028363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 23:15:41 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
	q0HNFdfT022834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 23:15:39 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0HNFbC9025584; Tue, 17 Jan 2012 17:15:37 -0600
Received: from [10.159.220.138] (/10.159.220.138)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 15:15:36 -0800
Message-ID: <4F160113.1030503@oracle.com>
Date: Tue, 17 Jan 2012 15:15:31 -0800
From: Tina Yang <tina.yang@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
In-Reply-To: <20120117215100.GA25367@phenom.dumpdata.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F16011E.0087,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/17/2012 1:51 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
>> On 1/13/2012 3:06 AM, Ian Campbell wrote:
>>> On Thu, 2012-01-12 at 14:17 +0000, Konrad Rzeszutek Wilk wrote:
>>>> On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
>>>>> add polling interface to xen-netfront device to support netconsole
>>>>>
>>>> Ian, any thoughts on the spinlock changes?
>>> What are they for?
>> When I did this patch back in 2008, both netconsole and netdump
>> were supported.  Spin_lock w/o irqsave and irqrestore would cause
>> netdump hang due to the unexpected change of the irq status.
> Hm, that might have been due to the bug that was lurking in there since
> 2.6.27: d198d499148a0c64a41b3aba9e7dd43772832b91 "xen: x86_32: do not enable iterrupts when returning from exception in interrupt context"
Don't think so.  Btw, the (guest) kernels back then were el4 (2.6.9) and 
el5 (2.6.18).
>> Although netdump is now obsolete, I think it's always a good practice
>> to preserve caller's irq status as we had a very bad experience
>> chasing a similar problem caused by such a irq change in RDS
> Did you find the culprit of it? Was there a patch for that in the
> upstream kernel?
Yes.  It has nothing to do with net drivers but same cause
elsewhere in the kernel.
>> in the not too long ago past.
> OK, it sounds like it was issues in the past but might not be the
> case anymore.
>
> Could please re-test it without that spinlock irqsave patch using
> the upstream kernel (or just UEK2 since it is an 3.0 type kernel).
Shouldn't be the case now, but don't know about the future.
The fact is as long as there is a new caller that has the expectation
of preserved irq status, it would be a problem.  As Ian said,
some net drivers have been cautious in this regard already by
saving/restoring the status, but apparently not everyone.
> Thanks.
>
>>> At a guess they are a necessary consequence of the new calling context.
>>> However not all the drivers I looked at which supported netpool were
>>> using the irqsave variants in this context so I guess it must be some
>>> secondary effect.
>>>
>>> Anyway, the upshot is that I think the changelog needs to explain the
>>> rationale for the locking change.
>>>
>>> Ian.
>>>
>>>>> Signed-off-by: Tina.Yang<tina.yang@oracle.com>
>>>>> Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>>>>> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
>>>>> Signed-off-by: Zhenzhong.Duan<zhenzhong.duan@oracle.com>
>>>>> Tested-by: gurudas.pai<gurudas.pai@oracle.com>
>>>>> ---
>>>>>   drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
>>>>>   1 files changed, 34 insertions(+), 23 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>>>> index fa67905..db638b4 100644
>>>>> --- a/drivers/net/xen-netfront.c
>>>>> +++ b/drivers/net/xen-netfront.c
>>>>> @@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>   	int frags = skb_shinfo(skb)->nr_frags;
>>>>>   	unsigned int offset = offset_in_page(data);
>>>>>   	unsigned int len = skb_headlen(skb);
>>>>> +	unsigned long flags;
>>>>>
>>>>>   	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
>>>>>   	if (unlikely(frags>   MAX_SKB_FRAGS + 1)) {
>>>>> @@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>   		goto drop;
>>>>>   	}
>>>>>
>>>>> -	spin_lock_irq(&np->tx_lock);
>>>>> +	spin_lock_irqsave(&np->tx_lock, flags);
>>>>>
>>>>>   	if (unlikely(!netif_carrier_ok(dev) ||
>>>>>   		     (frags>   1&&   !xennet_can_sg(dev)) ||
>>>>>   		     netif_needs_gso(skb, netif_skb_features(skb)))) {
>>>>> -		spin_unlock_irq(&np->tx_lock);
>>>>> +		spin_unlock_irqrestore(&np->tx_lock, flags);
>>>>>   		goto drop;
>>>>>   	}
>>>>>
>>>>> @@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>   	if (!netfront_tx_slot_available(np))
>>>>>   		netif_stop_queue(dev);
>>>>>
>>>>> -	spin_unlock_irq(&np->tx_lock);
>>>>> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>>>>>
>>>>>   	return NETDEV_TX_OK;
>>>>>
>>>>> @@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
>>>>>   	return 0;
>>>>>   }
>>>>>
>>>>> +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
>>>>> +{
>>>>> +	struct net_device *dev = dev_id;
>>>>> +	struct netfront_info *np = netdev_priv(dev);
>>>>> +	unsigned long flags;
>>>>> +
>>>>> +	spin_lock_irqsave(&np->tx_lock, flags);
>>>>> +
>>>>> +	if (likely(netif_carrier_ok(dev))) {
>>>>> +		xennet_tx_buf_gc(dev);
>>>>> +		/* Under tx_lock: protects access to rx shared-ring indexes. */
>>>>> +		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
>>>>> +			napi_schedule(&np->napi);
>>>>> +	}
>>>>> +
>>>>> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>>>>> +
>>>>> +	return IRQ_HANDLED;
>>>>> +}
>>>>> +
>>>>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>>>>> +static void xennet_poll_controller(struct net_device *dev)
>>>>> +{
>>>>> +	xennet_interrupt(0, dev);
>>>>> +}
>>>>> +#endif
>>>>> +
>>>>>   static const struct net_device_ops xennet_netdev_ops = {
>>>>>   	.ndo_open            = xennet_open,
>>>>>   	.ndo_uninit          = xennet_uninit,
>>>>> @@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
>>>>>   	.ndo_validate_addr   = eth_validate_addr,
>>>>>   	.ndo_fix_features    = xennet_fix_features,
>>>>>   	.ndo_set_features    = xennet_set_features,
>>>>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>>>>> +	.ndo_poll_controller = xennet_poll_controller,
>>>>> +#endif
>>>>>   };
>>>>>
>>>>>   static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
>>>>> @@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
>>>>>   	return 0;
>>>>>   }
>>>>>
>>>>> -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
>>>>> -{
>>>>> -	struct net_device *dev = dev_id;
>>>>> -	struct netfront_info *np = netdev_priv(dev);
>>>>> -	unsigned long flags;
>>>>> -
>>>>> -	spin_lock_irqsave(&np->tx_lock, flags);
>>>>> -
>>>>> -	if (likely(netif_carrier_ok(dev))) {
>>>>> -		xennet_tx_buf_gc(dev);
>>>>> -		/* Under tx_lock: protects access to rx shared-ring indexes. */
>>>>> -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
>>>>> -			napi_schedule(&np->napi);
>>>>> -	}
>>>>> -
>>>>> -	spin_unlock_irqrestore(&np->tx_lock, flags);
>>>>> -
>>>>> -	return IRQ_HANDLED;
>>>>> -}
>>>>> -
>>>>>   static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>>>>>   {
>>>>>   	struct xen_netif_tx_sring *txs;
>>>>> -- 
>>>>> 1.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 23:16:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 23:16:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnIFv-0004G3-BU; Tue, 17 Jan 2012 23:15:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tina.yang@oracle.com>) id 1RnIFu-0004FK-66
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 23:15:54 +0000
X-Env-Sender: tina.yang@oracle.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326842146!2624781!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk2NTIz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6754 invoked from network); 17 Jan 2012 23:15:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 23:15:47 -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
	q0HNFej3028363
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 23:15:41 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
	q0HNFdfT022834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 17 Jan 2012 23:15:39 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0HNFbC9025584; Tue, 17 Jan 2012 17:15:37 -0600
Received: from [10.159.220.138] (/10.159.220.138)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 17 Jan 2012 15:15:36 -0800
Message-ID: <4F160113.1030503@oracle.com>
Date: Tue, 17 Jan 2012 15:15:31 -0800
From: Tina Yang <tina.yang@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
In-Reply-To: <20120117215100.GA25367@phenom.dumpdata.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F16011E.0087,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/17/2012 1:51 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
>> On 1/13/2012 3:06 AM, Ian Campbell wrote:
>>> On Thu, 2012-01-12 at 14:17 +0000, Konrad Rzeszutek Wilk wrote:
>>>> On Wed, Jan 11, 2012 at 04:52:36PM +0800, Zhenzhong Duan wrote:
>>>>> add polling interface to xen-netfront device to support netconsole
>>>>>
>>>> Ian, any thoughts on the spinlock changes?
>>> What are they for?
>> When I did this patch back in 2008, both netconsole and netdump
>> were supported.  Spin_lock w/o irqsave and irqrestore would cause
>> netdump hang due to the unexpected change of the irq status.
> Hm, that might have been due to the bug that was lurking in there since
> 2.6.27: d198d499148a0c64a41b3aba9e7dd43772832b91 "xen: x86_32: do not enable iterrupts when returning from exception in interrupt context"
Don't think so.  Btw, the (guest) kernels back then were el4 (2.6.9) and 
el5 (2.6.18).
>> Although netdump is now obsolete, I think it's always a good practice
>> to preserve caller's irq status as we had a very bad experience
>> chasing a similar problem caused by such a irq change in RDS
> Did you find the culprit of it? Was there a patch for that in the
> upstream kernel?
Yes.  It has nothing to do with net drivers but same cause
elsewhere in the kernel.
>> in the not too long ago past.
> OK, it sounds like it was issues in the past but might not be the
> case anymore.
>
> Could please re-test it without that spinlock irqsave patch using
> the upstream kernel (or just UEK2 since it is an 3.0 type kernel).
Shouldn't be the case now, but don't know about the future.
The fact is as long as there is a new caller that has the expectation
of preserved irq status, it would be a problem.  As Ian said,
some net drivers have been cautious in this regard already by
saving/restoring the status, but apparently not everyone.
> Thanks.
>
>>> At a guess they are a necessary consequence of the new calling context.
>>> However not all the drivers I looked at which supported netpool were
>>> using the irqsave variants in this context so I guess it must be some
>>> secondary effect.
>>>
>>> Anyway, the upshot is that I think the changelog needs to explain the
>>> rationale for the locking change.
>>>
>>> Ian.
>>>
>>>>> Signed-off-by: Tina.Yang<tina.yang@oracle.com>
>>>>> Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
>>>>> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
>>>>> Signed-off-by: Zhenzhong.Duan<zhenzhong.duan@oracle.com>
>>>>> Tested-by: gurudas.pai<gurudas.pai@oracle.com>
>>>>> ---
>>>>>   drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
>>>>>   1 files changed, 34 insertions(+), 23 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
>>>>> index fa67905..db638b4 100644
>>>>> --- a/drivers/net/xen-netfront.c
>>>>> +++ b/drivers/net/xen-netfront.c
>>>>> @@ -489,6 +489,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>   	int frags = skb_shinfo(skb)->nr_frags;
>>>>>   	unsigned int offset = offset_in_page(data);
>>>>>   	unsigned int len = skb_headlen(skb);
>>>>> +	unsigned long flags;
>>>>>
>>>>>   	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
>>>>>   	if (unlikely(frags>   MAX_SKB_FRAGS + 1)) {
>>>>> @@ -498,12 +499,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>   		goto drop;
>>>>>   	}
>>>>>
>>>>> -	spin_lock_irq(&np->tx_lock);
>>>>> +	spin_lock_irqsave(&np->tx_lock, flags);
>>>>>
>>>>>   	if (unlikely(!netif_carrier_ok(dev) ||
>>>>>   		     (frags>   1&&   !xennet_can_sg(dev)) ||
>>>>>   		     netif_needs_gso(skb, netif_skb_features(skb)))) {
>>>>> -		spin_unlock_irq(&np->tx_lock);
>>>>> +		spin_unlock_irqrestore(&np->tx_lock, flags);
>>>>>   		goto drop;
>>>>>   	}
>>>>>
>>>>> @@ -574,7 +575,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>>>   	if (!netfront_tx_slot_available(np))
>>>>>   		netif_stop_queue(dev);
>>>>>
>>>>> -	spin_unlock_irq(&np->tx_lock);
>>>>> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>>>>>
>>>>>   	return NETDEV_TX_OK;
>>>>>
>>>>> @@ -1228,6 +1229,33 @@ static int xennet_set_features(struct net_device *dev,
>>>>>   	return 0;
>>>>>   }
>>>>>
>>>>> +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
>>>>> +{
>>>>> +	struct net_device *dev = dev_id;
>>>>> +	struct netfront_info *np = netdev_priv(dev);
>>>>> +	unsigned long flags;
>>>>> +
>>>>> +	spin_lock_irqsave(&np->tx_lock, flags);
>>>>> +
>>>>> +	if (likely(netif_carrier_ok(dev))) {
>>>>> +		xennet_tx_buf_gc(dev);
>>>>> +		/* Under tx_lock: protects access to rx shared-ring indexes. */
>>>>> +		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
>>>>> +			napi_schedule(&np->napi);
>>>>> +	}
>>>>> +
>>>>> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>>>>> +
>>>>> +	return IRQ_HANDLED;
>>>>> +}
>>>>> +
>>>>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>>>>> +static void xennet_poll_controller(struct net_device *dev)
>>>>> +{
>>>>> +	xennet_interrupt(0, dev);
>>>>> +}
>>>>> +#endif
>>>>> +
>>>>>   static const struct net_device_ops xennet_netdev_ops = {
>>>>>   	.ndo_open            = xennet_open,
>>>>>   	.ndo_uninit          = xennet_uninit,
>>>>> @@ -1239,6 +1267,9 @@ static const struct net_device_ops xennet_netdev_ops = {
>>>>>   	.ndo_validate_addr   = eth_validate_addr,
>>>>>   	.ndo_fix_features    = xennet_fix_features,
>>>>>   	.ndo_set_features    = xennet_set_features,
>>>>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>>>>> +	.ndo_poll_controller = xennet_poll_controller,
>>>>> +#endif
>>>>>   };
>>>>>
>>>>>   static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
>>>>> @@ -1448,26 +1479,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
>>>>>   	return 0;
>>>>>   }
>>>>>
>>>>> -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
>>>>> -{
>>>>> -	struct net_device *dev = dev_id;
>>>>> -	struct netfront_info *np = netdev_priv(dev);
>>>>> -	unsigned long flags;
>>>>> -
>>>>> -	spin_lock_irqsave(&np->tx_lock, flags);
>>>>> -
>>>>> -	if (likely(netif_carrier_ok(dev))) {
>>>>> -		xennet_tx_buf_gc(dev);
>>>>> -		/* Under tx_lock: protects access to rx shared-ring indexes. */
>>>>> -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
>>>>> -			napi_schedule(&np->napi);
>>>>> -	}
>>>>> -
>>>>> -	spin_unlock_irqrestore(&np->tx_lock, flags);
>>>>> -
>>>>> -	return IRQ_HANDLED;
>>>>> -}
>>>>> -
>>>>>   static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>>>>>   {
>>>>>   	struct xen_netif_tx_sring *txs;
>>>>> -- 
>>>>> 1.7.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 17 23:47:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 23: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 1RnIjg-0004tp-Ug; Tue, 17 Jan 2012 23:46:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RnIjf-0004tk-LI
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 23:46:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326843879!60126225!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4475 invoked from network); 17 Jan 2012 23:44:39 -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;
	17 Jan 2012 23:44:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,526,1320624000"; d="scan'208";a="10102398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 23:46:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 23:46:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnIja-0008RJ-Oy;
	Tue, 17 Jan 2012 23:46:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnIja-0004Lc-Ho;
	Tue, 17 Jan 2012 23:46:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10859-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 23:46:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10859: 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 10859 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10859/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 10769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2   15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf     15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass

version targeted for testing:
 xen                  271e30252c16
baseline version:
 xen                  d5b26918cd94

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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:   21560:271e30252c16
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:35:30 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
changeset:   21559:75007e524cd8
user:        David Vrabel <david.vrabel@citrix.com>
date:        Tue Jan 17 11:35:03 2012 +0000
    
    x86: emulate lea with two register operands correctly
    
    An lea instruction with two register operands should raise an
    undefined instruction exception.
    
    Skype does such a instruction and will crash when starting if it does
    not get the exception.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24456:03781de56c31
    xen-unstable date:        Thu Jan 05 15:47:16 2012 +0000
    
    
changeset:   21558:3f7117070ba1
user:        Yongan Liu <Liuyongan@huawei.com>
date:        Tue Jan 17 11:34:43 2012 +0000
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24453:02b92d035f64
    xen-unstable date:        Thu Jan 05 09:29:59 2012 +0100
    
    
changeset:   21557:d5b26918cd94
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:54 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
    
    
(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 Tue Jan 17 23:47:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 17 Jan 2012 23: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 1RnIjg-0004tp-Ug; Tue, 17 Jan 2012 23:46:40 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RnIjf-0004tk-LI
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 23:46:39 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326843879!60126225!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4475 invoked from network); 17 Jan 2012 23:44:39 -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;
	17 Jan 2012 23:44:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,526,1320624000"; d="scan'208";a="10102398"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	17 Jan 2012 23:46:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 17 Jan 2012 23:46:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnIja-0008RJ-Oy;
	Tue, 17 Jan 2012 23:46:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnIja-0004Lc-Ho;
	Tue, 17 Jan 2012 23:46:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10859-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 17 Jan 2012 23:46:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10859: 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 10859 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10859/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 10769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-amd64-i386-xl-credit2   15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf     15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-rhel6hvm-intel  7 redhat-install               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-amd  7 redhat-install               fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass

version targeted for testing:
 xen                  271e30252c16
baseline version:
 xen                  d5b26918cd94

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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:   21560:271e30252c16
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:35:30 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
changeset:   21559:75007e524cd8
user:        David Vrabel <david.vrabel@citrix.com>
date:        Tue Jan 17 11:35:03 2012 +0000
    
    x86: emulate lea with two register operands correctly
    
    An lea instruction with two register operands should raise an
    undefined instruction exception.
    
    Skype does such a instruction and will crash when starting if it does
    not get the exception.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24456:03781de56c31
    xen-unstable date:        Thu Jan 05 15:47:16 2012 +0000
    
    
changeset:   21558:3f7117070ba1
user:        Yongan Liu <Liuyongan@huawei.com>
date:        Tue Jan 17 11:34:43 2012 +0000
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24453:02b92d035f64
    xen-unstable date:        Thu Jan 05 09:29:59 2012 +0100
    
    
changeset:   21557:d5b26918cd94
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:54 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 01:51:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 01:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnKf7-0002GW-6l; Wed, 18 Jan 2012 01:50: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 1RnKf5-0002GN-Tk
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 01:50:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326851397!2635128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26779 invoked from network); 18 Jan 2012 01:49:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 01:49:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,526,1320624000"; d="scan'208";a="10104816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 01:49: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; Wed, 18 Jan 2012 01:49: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 1RnKez-0000gI-3g;
	Wed, 18 Jan 2012 01:49:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnKez-0005ER-2w;
	Wed, 18 Jan 2012 01:49:57 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10862-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 01:49:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10862: 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 10862 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10862/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install            fail pass in 10791
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail in 10791 pass in 10862
 test-amd64-i386-win           7 windows-install    fail in 10791 pass in 10862

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   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-i386-i386-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-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10791 never pass

version targeted for testing:
 xen                  27e959546916
baseline version:
 xen                  e29b7691fefc

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Gang Wei <gang.wei@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Tim Deegan <Tim.Deegan@citrix.com>
  Tim Deegan <tim@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=27e959546916
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 27e959546916
+ branch=xen-4.1-testing
+ revision=27e959546916
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 27e959546916 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 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 01:51:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 01:51:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnKf7-0002GW-6l; Wed, 18 Jan 2012 01:50: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 1RnKf5-0002GN-Tk
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 01:50:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326851397!2635128!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26779 invoked from network); 18 Jan 2012 01:49:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 01:49:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,526,1320624000"; d="scan'208";a="10104816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 01:49: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; Wed, 18 Jan 2012 01:49: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 1RnKez-0000gI-3g;
	Wed, 18 Jan 2012 01:49:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnKez-0005ER-2w;
	Wed, 18 Jan 2012 01:49:57 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10862-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 01:49:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10862: 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 10862 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10862/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install            fail pass in 10791
 test-amd64-i386-xl-win-vcpus1 12 guest-localmigrate/x10 fail in 10791 pass in 10862
 test-amd64-i386-win           7 windows-install    fail in 10791 pass in 10862

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   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-i386-i386-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-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10791 never pass

version targeted for testing:
 xen                  27e959546916
baseline version:
 xen                  e29b7691fefc

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Gang Wei <gang.wei@intel.com>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Tim Deegan <Tim.Deegan@citrix.com>
  Tim Deegan <tim@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=27e959546916
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 27e959546916
+ branch=xen-4.1-testing
+ revision=27e959546916
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 27e959546916 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 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 07:50:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 07:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnQHJ-0007jq-6t; Wed, 18 Jan 2012 07:49: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 1RnQHH-0007jl-J7
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 07:49:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326872952!48859426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5099 invoked from network); 18 Jan 2012 07:49:12 -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;
	18 Jan 2012 07:49:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,528,1320624000"; d="scan'208";a="10107814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 07:49:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 07:49: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 1RnQHC-0002fv-E6;
	Wed, 18 Jan 2012 07:49:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnQHC-000557-Co;
	Wed, 18 Jan 2012 07:49:46 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10867-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 07:49:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10867: 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 10867 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10867/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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 870 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 Jan 18 07:50:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 07:50:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnQHJ-0007jq-6t; Wed, 18 Jan 2012 07:49: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 1RnQHH-0007jl-J7
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 07:49:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326872952!48859426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5099 invoked from network); 18 Jan 2012 07:49:12 -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;
	18 Jan 2012 07:49:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,528,1320624000"; d="scan'208";a="10107814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 07:49:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 07:49: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 1RnQHC-0002fv-E6;
	Wed, 18 Jan 2012 07:49:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnQHC-000557-Co;
	Wed, 18 Jan 2012 07:49:46 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10867-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 07:49:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10867: 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 10867 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10867/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-rhel6hvm-amd  7 redhat-install            fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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 870 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 Jan 18 08:14:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 08:14:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnQeU-0008NV-Kz; Wed, 18 Jan 2012 08:13:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RnQeS-0008NN-On
	for Xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:13:49 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326874421!9611701!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 2896 invoked from network); 18 Jan 2012 08:13:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 08:13:42 -0000
Received: by wibhj8 with SMTP id hj8so14333731wib.30
	for <Xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 00:13: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=hcmhJX0mTmC1MukvncE8iWsc5+HN5NTtXH61uf1IaYQ=;
	b=bhTwEcJHqTrI/jYQ37JrhAbhSvzSfC/bP9lab6Oq3YtbtKzKr1vDOvpIqhS43LfjTc
	kORt+Ke+aWlyZe/MvSlxPmRNCXOmHZ6pQWcrFZV8lWM8UYse8kCqBatXNzudm5qC9ZoE
	IATtEQGtmUBlmxEucimK2GK6kd+fD8Pyp7UZM=
MIME-Version: 1.0
Received: by 10.180.19.97 with SMTP id d1mr34470580wie.12.1326874421569; Wed,
	18 Jan 2012 00:13:41 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Wed, 18 Jan 2012 00:13:41 -0800 (PST)
Date: Wed, 18 Jan 2012 16:13:41 +0800
Message-ID: <CANqQZNHUMrf-sNpfH3zsnPwYr3uGpeFSjycUufYHxR3kZ006+A@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [question] bug in cpu_schedule_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

Hi,

I see below code in cpu_schedule_up in xen-unstable hg repository
(xen/common/schedule.c).

    if ( idle_vcpu[cpu] == NULL )
        alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
    if ( idle_vcpu[cpu] == NULL )
        return -ENOMEM;

Seems it's a bug? Should be like this?

    if ( idle_vcpu[cpu] == NULL )
        idle_vcpu[cpu] = alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
    if ( idle_vcpu[cpu] == NULL )
        return -ENOMEM;


-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 08:14:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 08:14:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnQeU-0008NV-Kz; Wed, 18 Jan 2012 08:13:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RnQeS-0008NN-On
	for Xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:13:49 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326874421!9611701!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 2896 invoked from network); 18 Jan 2012 08:13:42 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 08:13:42 -0000
Received: by wibhj8 with SMTP id hj8so14333731wib.30
	for <Xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 00:13: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=hcmhJX0mTmC1MukvncE8iWsc5+HN5NTtXH61uf1IaYQ=;
	b=bhTwEcJHqTrI/jYQ37JrhAbhSvzSfC/bP9lab6Oq3YtbtKzKr1vDOvpIqhS43LfjTc
	kORt+Ke+aWlyZe/MvSlxPmRNCXOmHZ6pQWcrFZV8lWM8UYse8kCqBatXNzudm5qC9ZoE
	IATtEQGtmUBlmxEucimK2GK6kd+fD8Pyp7UZM=
MIME-Version: 1.0
Received: by 10.180.19.97 with SMTP id d1mr34470580wie.12.1326874421569; Wed,
	18 Jan 2012 00:13:41 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Wed, 18 Jan 2012 00:13:41 -0800 (PST)
Date: Wed, 18 Jan 2012 16:13:41 +0800
Message-ID: <CANqQZNHUMrf-sNpfH3zsnPwYr3uGpeFSjycUufYHxR3kZ006+A@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [question] bug in cpu_schedule_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

Hi,

I see below code in cpu_schedule_up in xen-unstable hg repository
(xen/common/schedule.c).

    if ( idle_vcpu[cpu] == NULL )
        alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
    if ( idle_vcpu[cpu] == NULL )
        return -ENOMEM;

Seems it's a bug? Should be like this?

    if ( idle_vcpu[cpu] == NULL )
        idle_vcpu[cpu] = alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
    if ( idle_vcpu[cpu] == NULL )
        return -ENOMEM;


-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 08:39:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 08:39:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnR2u-0000db-GQ; Wed, 18 Jan 2012 08:39:04 +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 1RnR2s-0000dW-G6
	for Xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:39:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326875936!11354294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23543 invoked from network); 18 Jan 2012 08:38:56 -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;
	18 Jan 2012 08:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,528,1320624000"; d="scan'208";a="10108601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 08:38:56 +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, 18 Jan 2012 08:38:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kai Huang <mail.kai.huang@gmail.com>
In-Reply-To: <CANqQZNHUMrf-sNpfH3zsnPwYr3uGpeFSjycUufYHxR3kZ006+A@mail.gmail.com>
References: <CANqQZNHUMrf-sNpfH3zsnPwYr3uGpeFSjycUufYHxR3kZ006+A@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Wed, 18 Jan 2012 08:38:55 +0000
Message-ID: <1326875935.29475.23.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] [question] bug in cpu_schedule_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 Wed, 2012-01-18 at 08:13 +0000, Kai Huang wrote:
> Hi,
> 
> I see below code in cpu_schedule_up in xen-unstable hg repository
> (xen/common/schedule.c).
> 
>     if ( idle_vcpu[cpu] == NULL )
>         alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
>     if ( idle_vcpu[cpu] == NULL )
>         return -ENOMEM;
> 
> Seems it's a bug? Should be like this?
> 
>     if ( idle_vcpu[cpu] == NULL )
>         idle_vcpu[cpu] = alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
>     if ( idle_vcpu[cpu] == NULL )
>         return -ENOMEM;

alloc_vcpu will set idle_vcpu[0]->domain->vcpu[cpu] to the newly
allocated vcpu. idle_vcpu[0]->domain == idle_domain and
idle_vcpu[0]->domain->vcpu == idle_vcpu (both are by construction in
scheduler_init). Therefore idle_vcpu[cpu] is already being set inside
alloc_vcpu.

The return value of alloc_vcpu is to save code which wants a local
handle on the newly allocated vcpu to perform further setup from doing
the lookup itself.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 08:39:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 08:39:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnR2u-0000db-GQ; Wed, 18 Jan 2012 08:39:04 +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 1RnR2s-0000dW-G6
	for Xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:39:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326875936!11354294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23543 invoked from network); 18 Jan 2012 08:38:56 -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;
	18 Jan 2012 08:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,528,1320624000"; d="scan'208";a="10108601"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 08:38:56 +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, 18 Jan 2012 08:38:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kai Huang <mail.kai.huang@gmail.com>
In-Reply-To: <CANqQZNHUMrf-sNpfH3zsnPwYr3uGpeFSjycUufYHxR3kZ006+A@mail.gmail.com>
References: <CANqQZNHUMrf-sNpfH3zsnPwYr3uGpeFSjycUufYHxR3kZ006+A@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Wed, 18 Jan 2012 08:38:55 +0000
Message-ID: <1326875935.29475.23.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] [question] bug in cpu_schedule_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 Wed, 2012-01-18 at 08:13 +0000, Kai Huang wrote:
> Hi,
> 
> I see below code in cpu_schedule_up in xen-unstable hg repository
> (xen/common/schedule.c).
> 
>     if ( idle_vcpu[cpu] == NULL )
>         alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
>     if ( idle_vcpu[cpu] == NULL )
>         return -ENOMEM;
> 
> Seems it's a bug? Should be like this?
> 
>     if ( idle_vcpu[cpu] == NULL )
>         idle_vcpu[cpu] = alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
>     if ( idle_vcpu[cpu] == NULL )
>         return -ENOMEM;

alloc_vcpu will set idle_vcpu[0]->domain->vcpu[cpu] to the newly
allocated vcpu. idle_vcpu[0]->domain == idle_domain and
idle_vcpu[0]->domain->vcpu == idle_vcpu (both are by construction in
scheduler_init). Therefore idle_vcpu[cpu] is already being set inside
alloc_vcpu.

The return value of alloc_vcpu is to save code which wants a local
handle on the newly allocated vcpu to perform further setup from doing
the lookup itself.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 08:54:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 08: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 1RnRGm-00018d-IX; Wed, 18 Jan 2012 08:53:24 +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 1RnRGk-00018U-KD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:53:22 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326876795!9559923!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2ODU1NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 314 invoked from network); 18 Jan 2012 08:53:16 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 08:53:16 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=m9B6nETgAokKwvMU7rVzED8xwjsJe75T01WXKcdlY/Zk5WNk42BZNX+/
	JpJ4f5qHRkVET0P97Ga5bpwKijpPlth8Dx+Pohlfus7KmeK5NyOhSJBeP
	YD518qy8yeWdOqACk1YBYxbi+rq7APPGa5hQcQj2WDqB794kLuOWtz0zN
	VO7wn1JraSA4Y75YopkPLuUR6CXbZPw4HaXce9OqjWA3pxVYgV8UUe0Mj
	Y0trdfjKa7SOW+6PJ59R5DGZ951gV;
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=1326876796; x=1358412796;
	h=mime-version:subject:message-id:date:from:to;
	bh=ADmRJEmaTpvKEy5nVL6Un0J9pz0BcikA3FXpu1HiGlc=;
	b=H94kquKFc+zQ3pY7Zx3YY5soypmqjvXZ4ByEd2u9T4oLOHooZvV6grZX
	BsOqM8IV+Qt3kqDkhrbPNZ+CD8rKGK0lSKReLKbXFOpgj8g0Sn+HfvHUw
	sYszReRp326wolRy/NAI+3ZOYzWoRPwhOgrxXwONVW0bJxAsS3isMjXgW
	GvDXK8UiFkVqkSedXeonnxWEa+YNW8EdvwLA/F80z8A9IrJN1h5SapG4B
	PUIfXb70r3ehOzcbp3jHdg8fTP4jM;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,527,1320620400"; d="scan'208";a="83865676"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 18 Jan 2012 09:53:16 +0100
X-IronPort-AV: E=Sophos;i="4.71,527,1320620400"; d="scan'208";a="126955291"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 18 Jan 2012 09:53:15 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 356644A586E;
	Wed, 18 Jan 2012 09:53:15 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============7421071610834031546=="
MIME-Version: 1.0
X-Mercurial-Node: 88318e850353da840fe70a7a953e1037ef32e2cd
Message-Id: <88318e850353da840fe7.1326876484@nehalem1>
Date: Wed, 18 Jan 2012 09:48:04 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7421071610834031546==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

On a real machine a cpu disabled via hlt with interrupts disabled can be
reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 4 insertions(+), 1 deletion(-)
xen/arch/x86/hvm/vlapic.c |    5 ++++-



--===============7421071610834031546==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1326876456 -3600
# Node ID 88318e850353da840fe70a7a953e1037ef32e2cd
# Parent  15ab61865ecbd146f6ce65fbea5bf49bfd9c6cb1
Allow wake up of offline vcpu via nmi-ipi

On a real machine a cpu disabled via hlt with interrupts disabled can be
reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 15ab61865ecb -r 88318e850353 xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/arch/x86/hvm/vlapic.c	Wed Jan 18 09:47:36 2012 +0100
@@ -323,7 +323,10 @@ static int vlapic_accept_irq(struct vcpu
 
     case APIC_DM_NMI:
         if ( !test_and_set_bool(v->nmi_pending) )
-            vcpu_kick(v);
+        {
+            clear_bit(_VPF_down, &v->pause_flags);
+            vcpu_wake(v);
+        }
         break;
 
     case APIC_DM_INIT:

--===============7421071610834031546==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7421071610834031546==--


From xen-devel-bounces@lists.xensource.com Wed Jan 18 08:54:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 08: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 1RnRGs-000194-Vh; Wed, 18 Jan 2012 08:53:30 +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 1RnRGq-00018c-Ui
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:53:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326876802!11359567!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 392 invoked from network); 18 Jan 2012 08:53:22 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-182.messagelabs.com with SMTP;
	18 Jan 2012 08:53:22 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74585591; Wed, 18 Jan 2012 09:53:21 +0100
Message-ID: <1326876800.2375.18.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Keir Fraser <keir@xen.org>
Date: Wed, 18 Jan 2012 09:53:20 +0100
In-Reply-To: <CB3B094F.379B1%keir@xen.org>
References: <CB3B094F.379B1%keir@xen.org>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>,
	"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] [PATCHv2 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="===============0938465777819928307=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0938465777819928307==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-j2CJJSqMR/ySgF/V7Jqc"


--=-j2CJJSqMR/ySgF/V7Jqc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-01-17 at 11:17 +0000, Keir Fraser wrote:=20
> > Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-t=
asklet,
> > raised by the actual IRQ handler. To avoid more interrupts being genera=
ted
> > (because of further faults), they must be masked in the IOMMU within th=
e low
> > level IRQ handler and enabled back in the tasklet body. Notice that thi=
s may
> > cause the log to overflow, but none of the existing entry will be overw=
ritten.
> >=20
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> This patch needs fixing to apply to xen-unstable tip. Please do that and
> resubmit.
>=20
I see. I can easily rebase the patch but there are functional changes
involved, so I'd like to know what you think it's best to do first.

In particular, the clash is against Wei's patches introducing PPR. So
now the IOMMU interrupt handler checks both event log and ppr log.

Question is, should I move _BOTH_ these checks into softirq or just
defer event log processing, and leave ppr log handling in hard-irq
context? Quickly looking at the new specs, it seems to me that deferring
both should be fine, but I'd really appreciate your thoughts...

Wei, Jan, Tim?

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)



--=-j2CJJSqMR/ySgF/V7Jqc
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)

iEYEABECAAYFAk8WiIAACgkQk4XaBE3IOsSgRACfTrKRFsf0Z7rOT3Nsrg85swe/
0LQAn2fixhNOxDh5qg3ATE+KBKuJTFSu
=OTnY
-----END PGP SIGNATURE-----

--=-j2CJJSqMR/ySgF/V7Jqc--



--===============0938465777819928307==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0938465777819928307==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 08:54:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 08: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 1RnRGm-00018d-IX; Wed, 18 Jan 2012 08:53:24 +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 1RnRGk-00018U-KD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:53:22 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326876795!9559923!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2ODU1NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 314 invoked from network); 18 Jan 2012 08:53:16 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 08:53:16 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=m9B6nETgAokKwvMU7rVzED8xwjsJe75T01WXKcdlY/Zk5WNk42BZNX+/
	JpJ4f5qHRkVET0P97Ga5bpwKijpPlth8Dx+Pohlfus7KmeK5NyOhSJBeP
	YD518qy8yeWdOqACk1YBYxbi+rq7APPGa5hQcQj2WDqB794kLuOWtz0zN
	VO7wn1JraSA4Y75YopkPLuUR6CXbZPw4HaXce9OqjWA3pxVYgV8UUe0Mj
	Y0trdfjKa7SOW+6PJ59R5DGZ951gV;
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=1326876796; x=1358412796;
	h=mime-version:subject:message-id:date:from:to;
	bh=ADmRJEmaTpvKEy5nVL6Un0J9pz0BcikA3FXpu1HiGlc=;
	b=H94kquKFc+zQ3pY7Zx3YY5soypmqjvXZ4ByEd2u9T4oLOHooZvV6grZX
	BsOqM8IV+Qt3kqDkhrbPNZ+CD8rKGK0lSKReLKbXFOpgj8g0Sn+HfvHUw
	sYszReRp326wolRy/NAI+3ZOYzWoRPwhOgrxXwONVW0bJxAsS3isMjXgW
	GvDXK8UiFkVqkSedXeonnxWEa+YNW8EdvwLA/F80z8A9IrJN1h5SapG4B
	PUIfXb70r3ehOzcbp3jHdg8fTP4jM;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,527,1320620400"; d="scan'208";a="83865676"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 18 Jan 2012 09:53:16 +0100
X-IronPort-AV: E=Sophos;i="4.71,527,1320620400"; d="scan'208";a="126955291"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 18 Jan 2012 09:53:15 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 356644A586E;
	Wed, 18 Jan 2012 09:53:15 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============7421071610834031546=="
MIME-Version: 1.0
X-Mercurial-Node: 88318e850353da840fe70a7a953e1037ef32e2cd
Message-Id: <88318e850353da840fe7.1326876484@nehalem1>
Date: Wed, 18 Jan 2012 09:48:04 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7421071610834031546==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

On a real machine a cpu disabled via hlt with interrupts disabled can be
reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 4 insertions(+), 1 deletion(-)
xen/arch/x86/hvm/vlapic.c |    5 ++++-



--===============7421071610834031546==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1326876456 -3600
# Node ID 88318e850353da840fe70a7a953e1037ef32e2cd
# Parent  15ab61865ecbd146f6ce65fbea5bf49bfd9c6cb1
Allow wake up of offline vcpu via nmi-ipi

On a real machine a cpu disabled via hlt with interrupts disabled can be
reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 15ab61865ecb -r 88318e850353 xen/arch/x86/hvm/vlapic.c
--- a/xen/arch/x86/hvm/vlapic.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/arch/x86/hvm/vlapic.c	Wed Jan 18 09:47:36 2012 +0100
@@ -323,7 +323,10 @@ static int vlapic_accept_irq(struct vcpu
 
     case APIC_DM_NMI:
         if ( !test_and_set_bool(v->nmi_pending) )
-            vcpu_kick(v);
+        {
+            clear_bit(_VPF_down, &v->pause_flags);
+            vcpu_wake(v);
+        }
         break;
 
     case APIC_DM_INIT:

--===============7421071610834031546==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7421071610834031546==--


From xen-devel-bounces@lists.xensource.com Wed Jan 18 08:54:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 08: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 1RnRGs-000194-Vh; Wed, 18 Jan 2012 08:53:30 +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 1RnRGq-00018c-Ui
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:53:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326876802!11359567!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 392 invoked from network); 18 Jan 2012 08:53:22 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-182.messagelabs.com with SMTP;
	18 Jan 2012 08:53:22 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74585591; Wed, 18 Jan 2012 09:53:21 +0100
Message-ID: <1326876800.2375.18.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Keir Fraser <keir@xen.org>
Date: Wed, 18 Jan 2012 09:53:20 +0100
In-Reply-To: <CB3B094F.379B1%keir@xen.org>
References: <CB3B094F.379B1%keir@xen.org>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAAAA3NCSVQICAjb4U/gAAAVx0lEQVRYwzWY6a/d953XP9/tt51zfme/+37t692OtzhxtzTuJFPaTDVt0cDQeTIajToSKBJICBASQkI8Q1Q8ACQEhUGgCsF0OrSkaRLaxknqOl7i9dq++3727bd/Vx5k+CNe7+WFvvkvbvoywAZF1BMYOFNFbqWEW1gho42yB9jJq1QihEGVCh7BxrXpeNlxbJZmcmNvkArIhAIMJd+drlmA0aiXuBbN5x3Pxq6NS6X85l5/rxNnGtJYgAYhgVCa8UxqAwgQIABAGGMD1JWtS7/48Vy0W1k5GxXnmh41br1y6fxXv3LCEPXLu3vv3N3t2kXPAi0EIjTjnDGcKawzHceZl3N0mIExrmfnGS1iSij2pxgDxJhlsOFID8LUsVjecXvNPiJg2ZYySiODGUVcAwBCCAAMAIAhNc82C2xvuLG8uX422VvZfHrx9Mz5P7kRR51wby188YD+8metqQWBLa00F1JIlQk5imIhle+XBsHI9/PVUoFCBp7JOZbSjGiS92mx7IE0SICRkC/Yw2GSZECpIsYYwEmWGkDGIAAAAIQAY4QMEA6Nvc7G6aaYzKQlUs/x/O99VywsZcZd33w++l9/NbN6Z905MSqPGYO10QDYGCI1EIQQGMdzkzCo+G4pb5eY7blWKhKadiZ92yYsFWoYpwhRv0A4h/4oK5Zcl9nGAMLUgEYYMAZAmhBkM6KkoYpVIRjU47SRRUuVlXRlUZ08nxDyi50na+2jV1r9tTjK/DwYqgFRLHMuYdhCMou1bg64a0M15yKiCyCcLJlJspl+e6x3QNtuv1TbKIwHxpHIZDEYorGFh32eK3h+yc06XYqA2MyyLCmk0lobAFC04NsTyCGjOAbrp5svrs/N1sqeRegKscrF2aiz1ZfJweZPjLzojB0fdPcqFcv481592Y15KiKOLBDyd
	OPw1b37JZ3Qosdspk2Eh71iZ3MmJafLE/2l4w/pjBiiRMVJKjOtLItypb18LkxCmSilAIAorQCA0nLl0lGSqY5kyCP55bFpOwvW1vo79+7vb+z5yjSF1Wg9RaNNjKxRlObPnd/c+UurPFMZPzO5cPpcIt/c/HApaZp+Jzoa6FKhcu4kogzZFGmEGgczG6v1O+8uLp1eQ0VdOrXuLFqu0mAwwZkUCBOMmJAKDAIgAJq88f1/NucwtbZqaXP9pfNnFxY++ujmI4OZVzoYHfKtxnrY2PFAS46yuJTPNzvNYXvbDJsvTfr/5PSJl3/676cbhzvPV4ccbN9KTCoHHYa5xQoZRPpglw1SEim5tzN58KSc4b1LFzEmFiMEYwCSca01MsYAAoyRUYrGgjXOXfgbg8aE5hPV8vsPPr7XHJaPn4x6MY0GjsUWvnxy+dLSB7+43W6zN77y9Q/e/3ENvMvI/dO4WftX/xzidDvrO7Mnxqt+P0kshcCyRj2pe89zKSKxVjrWWKs4balUO/s26MwgqZU2JsmkUhjAAPpr0ACA3vjKydHuAa56B2u7Hz59qDFOkD149x1n9VkW81LevvCH54b5ztiY/+rLr7zxu1+TwdEr99deD0Ln1tMw4ixVhVpuemZGYT5W8JQCgyAMR1whY1IGqRI8E1ks0m2pnqq0k6ogUpgRroBLDQgjDBgTjAEUUgDUJI16Se7sbcWdfoxdzrRUwj7aV1I7165Mnjhx+oLz2+CTyclL3/2D74ApfOFr3w4Hf7778/dmSclIzoXKTy6n2QBrjRQyBPdGQ6RVlCQ8TXScMGk8iwWErsV8Z/58J9KZ0IgbBJgQiok2BghBCCFjMACQlesvrzjY/tWtOM0EoZwCU0Ym2ag+VZ5fLOf9xZXph61s8dibtdpYnApmFe3JmX6372UByfg+wKNOt+hYSgHBNjiesW3H9SyhqEKJlE2ZHiSjrVS2c8Xm639nhEoACAzGhDCGKSVKGQ
	AwBgECxQXNuz7uD1QvQFJEeeOm0iiFBbDu/uEzwW8O+P826hu/d6v0/PTx5Y8/ee/l66/lFqdqb9xQ//pRJ+KBwfmp8U1tmkgnXqaxbPd6/V4fJ1kJ6JQhderZ1OvE/aYSfeKBAYSQQVgbI5Q2UgMgBMgYAxgBAE1U6uQKuS9e7310qzwQ2pDUghR4JU3UZji07BfFamHtIF00O839zx7ceeXaFxGY/J1Hz1sHPEGHDlnTreLkyeNXrpQLDgjtBHF+GI6i4VEYfnpwpAejvNBnUdG2qkBdw4w2Bhv0eXeZzwMfIYQ+7zKgc7VynCux73176ktXV//ix6Onq67RxIhEGTDSHybQH4Xt6LU3317f2pycmGJUVxudOZ+o6Zn764dB0YHx6dCwp88eIYSIxpLLIIziLJbSOAKEW9QlZ7Posijv5awsSw1yDMIAGMAgZBBCGGNjDEJGAdCJnI9thwHLFr3pt9+e3Wl2W41fbj1NlD51sHvmxeP1YfqMya9fvfaf//E/3T/cfPP6K8vv3Wz/3w/SxiBPaDFUeGZ6V2Sd7UOtACmkpeRSaI0wMogZYzNk05KfG5Z8q5a9bBeaA90P0kRixGyuPqddY4wwQgKAFosVQjEANjF1lFIz4/1x50g0kyR+uVi79jtf/vmHL4LKhZ7WreYWMbH5b/8zu3vHGkUZlxjrSOkzy/Px/n5fYxAxNUCNIdhIojEhmDFM3By2sWdJNlajeKmUnqiwQNuRZJ0I398LDVBkABPABgEA7o/CMEhlplzHKlZL1WJVY4LB5Ci6+p2rvRv1uxm8evba/Qe/UaPuDUEXP/kNTdJewqtV/+zlK9yQnfWtdrsVp+koEWEmpQELUwcTqrGMVZpEiUqVU43PflUzLR2pbFqkenncKniZsRNjcaAcocRmGQBQh1kIISmllJLrbG/3oCujE7PHahYo8eDu46fUqawsLzx4+vEZN/eHQcJHyVBjz5DqsYWOwDm/nmP52TF
	vY79x1O4bKcp5b7JWIQoNklRhYhvKjBkfCrf3xJ7+ijVKo+TAsQuO4wKlDsMGpRRjlYm8U+wBp57jWrYlpFRKGa7G56b/4i//x0Hj4OKU9/03Tj3e3BuvFvP1QhJmf2Zcuz/UhGiNWK3a7US8Ovvaq7/zcXenmfWqrmdKpTRLGCO9KELGhJmIOHcZLY9XGo3BBTrUJxuzCtJ8refnuDY6EwRjbaRnA3OxjQ0AUK2U4EIZrYw2gIYyzVQyNV48e9wzRt6729p5sl+2ci8/+Gy80x5hMFIBsZOyf4TIrC4Uld05bChP+kpZNo4RywAERgyTPCJgO1bBmfALzb3B5msXrg0UqxaG5QJgy0UMrIxYjAhHZ4HtJVW3uAaCUkYNGAxGKYkBd/pNC2AizxYq/LPHn9hWfb4eFxob59cakhpXmIaCnGu9u7td9MdajTsvnbxAmY94YEFojOEGEcYQAYSY4VEx79J8QQ+yiPlBFq/aE1Gt7BmTwwo7jh5wjDlxGDWKMGKMAgBsW45t2TazGWHI0hs7G1oJIgavXjmTCKcXwJeuXsv+zwexyhLmxoRix3rEUAv0++3tDweHdzafvlZfxH6RS8cYAkAPW/0Xe612t2sAwNC0nz67t+rmcgEPW82+yEgqdZImo2Gnfbge9p6AaliuGsUj5lAAoJQxKYUCDYAEhkEYFPzCXA0q9eLme0m7K6auTgUf3ynYrCzprhJHBSdYnLX3jvSoNwrMzfbW7Y9aIaCwQMHlOS83XvWTRGDLihCkoyTujpiiBAOSYTKAOAjdXAFjLGTWae0/W3skwa3WJiYnpse9BQCgwyhCCAhBwOgoDErVCd1tLc2ge4+fBKHDjJk/fsrR76BhHBoIy6VoeSlFEmxKHNpN0rGJqbDbV9KwgWj3IlWQhGGlTXuUacvKMxtJhA3oLGZJL+Nht1M/eeZaq90wGDtu7tj8cYUsIU3J8yzKAAQVimdSICmlUQ93Xxw1W8cnxhYW
	wkKhY/C8X+ufq891Wy3P4Nsg26eWolx9dLC9P+wpZBKbNnv9AiGWlipNXEP1gGNKjJIFg0lmLJOWmS2UylMU91qWXw663X4nUAYjkNRxX9zd0oj4lclykTNCAIDatqORMVpJhNY21raP9lS0+bdeWd7ePXr8wlqaXiK//qDX3P20Nr41tZASRtSwhSRCUHVsZkO3F9qkgFKJDC4QprRSmcgTSjHFBjEwjtR5hEm7xxzmunkZhL1Od2F5th+2DQJDqF2ezo8vAcbUpABAkyTjUhjJRzrRQe9CsXj9st0ZbDVeDK8M7b+Nk+7qnaevfvVAC8G5ATTx2mtLRt7+d/+WpKHrWEnRO2gPxqUtMU4UV0bbzMKISCmBIKAUAGyAzvZWrmjZ1SJS/OHde/MzE2OVeqHgX3n5qnLHO/3UIO55GAAoF0pppbTuBoOEGkqsGqPXotlLvUp1pto8ffGdXuPFbz+lsSL5YovoW+++c2q8rmyLaocinCN6VLaToZFcYoM0xpHiHFAOU8aIBpAAgFEmZNLpmFpJsk5hciYeDmsTi/fuf7bX2auWx0rjc47v7j2+BXCRUoK4QQDQaB0Zg7SRhVSxx0NfzHWPrzxfXlj76EObxxqhv1p7fOLiJd8Ujp890z46HG5tGNAIKdtloRCJUjnMMAKsMEK4RbhCAhuMElkkdozAjIb5YZToZiDM5XNntQ2u5VKtGzsbe/tbpXye1SbBvkgJAMVYEzIajTyEj83YQ7/104Xhb37WvLGwEm3shUnAMhUiM1AZz9KjVmtydrpFCAeFMaYWtQBpn0mtBpkCpZAFiGLm2KAhHaY5REEjhJUDhAcxx05hLBcnaa1UKjALE+aVqpHIJienbBAAgEt+frxURBZRBkOuNF2lC2P4fif7JXa2uD7Y3+VxQlO5GwfMyecK+Xq1WB8b6yaBJEhqhRBGGGML56s+rnhW3XeqBavoEERFkFmAkdIIQR4wjlMRxx5zUgG3769qo
	U7MzLS7w04QGcs2zPbLPgDg3qAXh8PV7fXEoPm5xWIt543nRe585djS1vN7+MXDwfZGe9Dc63XSRBwcNOIoAgQjkQqGhdGAkNEaaUW0ylnUw9g1BIdKdsK8op4hNiUSa8VFvVI5ff6sSFOG2YOnG0kii26+6BeJxbjRSZpg1wMAbDMgFjxZvb+/u/X81ntJZysYos7hcNbLjy1MPtp6gkbdqD+oF6vFSs3NeTNT04NePwQtsNZAldYGIaUUaIkkRxrCME0GSQk7HmCiDQWEAQMCGcYXjh2zjQShohiGcXb1pQvH5ueLOafgOkaK2bEiAFDFZTcc2CpayMPSWO3kUn5zbXtwNNjfffTW3/9Hd29+mISBkWRhYf7333xzZqKUBaNOp9/ziqUgwSBSJGxqy0xrYUAZLkUUpXVs5zHJQEstkAFsMGNOOgiS++s05AiACp7G8Vi1xMPk5LFjbrGUQzA3UYOHQA1mz7e3D1qDAtNTp+cZNd2B+NaXvtjvqGrRs4pETXuHR73NezcDHTsMX7n2ansYzc2drnO7K5+vzEwqrtf3okAbkxgeZyCMTy0bUY1U9v/FmMUoaHPc5LOZY7/urk9Yo3H2eu+ou1ir/urxqtHZialp98wUAGAA9XhrPaH+SJPKhB+lfL2de//uemblk0hcml34g7feOHN+5eyZk6eXpoP2YaXsdzdXv3ugb9SXSi75va9d+4f/4I+/89aNotb9ILYFnrYLHsYUAUMYGQAD1CCCSd0tfPrg/hwH0ttctgN7dDjGu0sOdqmZKlvnj88SpAGAPtnYyESKVFTP8Zw16rUOW116FOPr5fqz7b2fP36hP+7zWAkplxdmEUEF1748O/7wg59MaOv7J065NzcOnrW8nKeo48lwxStSLi3QgCkiaATYGMMMgNG1QmlfxxO9Xtn1Ro2+UnDz5z+LgzTP0Hgtl7MhzmIAwI/XVgNBAqNXTh2v5Mwwg3Z3wEfJ7OxyHHPb9SNuEi
	64Ed1RmAjm58rbHz85qdCfzi2fHfH67sj+6EX6s0/hoPvW5Mmq5MwimlCikUXtIYOYIYWUz1impU75ve6WzeHK+OKf/+AHYchVKuJRsLrTfHHY6A77AEAnZ6bBXc6ePj+1UOmPntxfkx3t5yzI5Uu7e3sYEDKmXirisisJnqxPH7Q68aD3rYVllkQJF6GUsRQmiE4j9/Wpkz9tHhGtDSUKACgOmcmQdhS1LDvLMoOwjJJ4d/ir4cfP0qaA23pxWc5N0FKhnQiLMQCgFceSFl24dPwLF4s/efe2P3llmoAbB5ZLw3gYxFE/jkdZNl8udA47KyunB72jb1Qn7c5gmGVcqJTzkVbAzY1TV89fvHR398nBYMgNikD5mhSQHWJuXM/OFaJhKLHhowAIWfjGl7b3nwbx8Nw3f9cCEDJjXAeDEQCQOGjFRzsny8FkRe43i0+fH2jIn5qZkxG/fft+rlDNlSYzxOanZxuj/hfPnLu+erCyvquSmKd6oOORkoMw+VTEb37hm6oXzdq5o2DU0akUMnbJhhgUHHeCelRBnGXDLAGDLMcrvHJ58dtvfXC4tdntCQG+bU/MTPl8sD5cIlMztSAOvvX6ceJEO3tHn7z3JG20XJleu3w1ToPdvQ0j+GS9/vWv3Xjl1Onru935W59ClnZGQ4sxi7FA8N+OBs8QOZqvD20z7fpoGDbikIMwMiNSlRG1DVWZiHiCCHUtG1vW+T/6fXDtrfZRnGSDqN8bdMbLpaS909EXaYBYKafPXl367PH9nd0gzTRRoWPnKWJ/81vfPnNy5Yc//OGt28/nHHhjoz03AD4cZdgUixULcJylFnZ7AOlYuXjj5R/9x//033cPr1VnRjKyLUtkkRYyFIJDUsv5DsWI0ZFUr/2977Gx+iCJDnu9IAgRNYVqaTjomFEEOaA2QV//8qLD0t2do62dWChIs2R8cqbgl0DJ4/NLb//dtzvd7kub2xceHQUqjJDqRmHQjQuOqyn
	ZiaKpyoRz4wuXzr70/MTyi8bR+72NEqPVTGL4a1NvIQRK5Cw3MDBz+RI6tpAAhJIzy65WEGOEYEhF5iv6+VE0F05P+f7Ui61Od4iV1hb1p6amM5USQFoh368t5IvjP/m1ylIuJAhFCGXMotQyjGCbbzX39p88Pvyv/8V2XZT3yED2sHYskteYCcIwBg0DwTVzZLkQ1XyTSuvzgUCpEglFVGMMmNSrzpEAim310sWX7j5ZI9Zc5/ARF6w651dqVSllKIWJhxF3is9XaaPNNOQsBkAdLRLCNMbNLBYGIbcgbdJu7iEpjO+aOE45fxIPl73SuFeORBpgaSwmPUp8ZutU89S1LRwazKgyFkLYY7bHnIXp4sNtoCtLtYnx8n/40Y+2d5U21PfL/+YH/5JqY7v5Ti950DksKlV4+CQnpaY441xzJUBigjMpM6N247ANOGKUKAnaOPliRILBsJ8geDDq1ZhjuzatFsMoKlBdMUbE8aDfY5S5tnvp8pWUZzzL0iR2bdbpHALA/wMUjQteOh3xIgAAAABJRU5ErkJggg==
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
Cc: Wei Wang2 <wei.wang2@amd.com>,
	"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] [PATCHv2 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="===============0938465777819928307=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0938465777819928307==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-j2CJJSqMR/ySgF/V7Jqc"


--=-j2CJJSqMR/ySgF/V7Jqc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 2012-01-17 at 11:17 +0000, Keir Fraser wrote:=20
> > Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-t=
asklet,
> > raised by the actual IRQ handler. To avoid more interrupts being genera=
ted
> > (because of further faults), they must be masked in the IOMMU within th=
e low
> > level IRQ handler and enabled back in the tasklet body. Notice that thi=
s may
> > cause the log to overflow, but none of the existing entry will be overw=
ritten.
> >=20
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> This patch needs fixing to apply to xen-unstable tip. Please do that and
> resubmit.
>=20
I see. I can easily rebase the patch but there are functional changes
involved, so I'd like to know what you think it's best to do first.

In particular, the clash is against Wei's patches introducing PPR. So
now the IOMMU interrupt handler checks both event log and ppr log.

Question is, should I move _BOTH_ these checks into softirq or just
defer event log processing, and leave ppr log handling in hard-irq
context? Quickly looking at the new specs, it seems to me that deferring
both should be fine, but I'd really appreciate your thoughts...

Wei, Jan, Tim?

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)



--=-j2CJJSqMR/ySgF/V7Jqc
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)

iEYEABECAAYFAk8WiIAACgkQk4XaBE3IOsSgRACfTrKRFsf0Z7rOT3Nsrg85swe/
0LQAn2fixhNOxDh5qg3ATE+KBKuJTFSu
=OTnY
-----END PGP SIGNATURE-----

--=-j2CJJSqMR/ySgF/V7Jqc--



--===============0938465777819928307==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0938465777819928307==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:00:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnRMu-0001eO-Uy; Wed, 18 Jan 2012 08:59:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnRMt-0001e3-IO
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:59:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326877177!11489068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7885 invoked from network); 18 Jan 2012 08:59:37 -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;
	18 Jan 2012 08:59:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,528,1320624000"; d="scan'208";a="10108939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 08:59:37 +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, 18 Jan 2012 08:59:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tina Yang <tina.yang@oracle.com>
In-Reply-To: <4F160113.1030503@oracle.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
	<4F160113.1030503@oracle.com>
Organization: Citrix Systems, Inc.
Date: Wed, 18 Jan 2012 08:59:36 +0000
Message-ID: <1326877176.29475.37.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-17 at 23:15 +0000, Tina Yang wrote:
> On 1/17/2012 1:51 PM, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
> >> On 1/13/2012 3:06 AM, Ian Campbell wrote:
> >> Although netdump is now obsolete, I think it's always a good practice
> >> to preserve caller's irq status as we had a very bad experience
> >> chasing a similar problem caused by such a irq change in RDS
> > Did you find the culprit of it? Was there a patch for that in the
> > upstream kernel?
> Yes.  It has nothing to do with net drivers but same cause
> elsewhere in the kernel.

I didn't think start_xmit could be called with interrupts disabled or
from interrupt context but perhaps I am wrong about that or perhaps
netconsole changes things?

Right, Documentation/networking/netdevices.txt states that start_xmit
can be called with interrupts disabled by netconsole and therefore using
the irqsave/restore locking in this function is, AFAICT, correct.

> >> in the not too long ago past.
> > OK, it sounds like it was issues in the past but might not be the
> > case anymore.
> >
> > Could please re-test it without that spinlock irqsave patch using
> > the upstream kernel (or just UEK2 since it is an 3.0 type kernel).
> Shouldn't be the case now, but don't know about the future.
> The fact is as long as there is a new caller that has the expectation
> of preserved irq status, it would be a problem.

The question is not so much what may or may not be a problem in the
future but what the requirements of this function are, in particular
those imposed by the network stack for the start_xmit function.

> As Ian said, some net drivers have been cautious in this regard already by
> saving/restoring the status, but apparently not everyone.

I was talking about the interrupt/poll handler here since I hadn't yet
noticed that the locking change was also in start_xmit and not just the
poll/interrupt paths (which was actually just code motion and not a
locking change in any case).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:00:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:00:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnRMu-0001eO-Uy; Wed, 18 Jan 2012 08:59:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnRMt-0001e3-IO
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 08:59:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326877177!11489068!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTYzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7885 invoked from network); 18 Jan 2012 08:59:37 -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;
	18 Jan 2012 08:59:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,528,1320624000"; d="scan'208";a="10108939"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 08:59:37 +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, 18 Jan 2012 08:59:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tina Yang <tina.yang@oracle.com>
In-Reply-To: <4F160113.1030503@oracle.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
	<4F160113.1030503@oracle.com>
Organization: Citrix Systems, Inc.
Date: Wed, 18 Jan 2012 08:59:36 +0000
Message-ID: <1326877176.29475.37.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-17 at 23:15 +0000, Tina Yang wrote:
> On 1/17/2012 1:51 PM, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
> >> On 1/13/2012 3:06 AM, Ian Campbell wrote:
> >> Although netdump is now obsolete, I think it's always a good practice
> >> to preserve caller's irq status as we had a very bad experience
> >> chasing a similar problem caused by such a irq change in RDS
> > Did you find the culprit of it? Was there a patch for that in the
> > upstream kernel?
> Yes.  It has nothing to do with net drivers but same cause
> elsewhere in the kernel.

I didn't think start_xmit could be called with interrupts disabled or
from interrupt context but perhaps I am wrong about that or perhaps
netconsole changes things?

Right, Documentation/networking/netdevices.txt states that start_xmit
can be called with interrupts disabled by netconsole and therefore using
the irqsave/restore locking in this function is, AFAICT, correct.

> >> in the not too long ago past.
> > OK, it sounds like it was issues in the past but might not be the
> > case anymore.
> >
> > Could please re-test it without that spinlock irqsave patch using
> > the upstream kernel (or just UEK2 since it is an 3.0 type kernel).
> Shouldn't be the case now, but don't know about the future.
> The fact is as long as there is a new caller that has the expectation
> of preserved irq status, it would be a problem.

The question is not so much what may or may not be a problem in the
future but what the requirements of this function are, in particular
those imposed by the network stack for the start_xmit function.

> As Ian said, some net drivers have been cautious in this regard already by
> saving/restoring the status, but apparently not everyone.

I was talking about the interrupt/poll handler here since I hadn't yet
noticed that the locking change was also in start_xmit and not just the
poll/interrupt paths (which was actually just code motion and not a
locking change in any case).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:00:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09: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 1RnRNN-0001iH-EY; Wed, 18 Jan 2012 09:00: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 1RnRNL-0001hr-A6
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:00:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326877203!9619293!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 19267 invoked from network); 18 Jan 2012 09:00:05 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 09:00:05 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74585806; Wed, 18 Jan 2012 10:00:02 +0100
Message-ID: <1326877166.5856.1.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 18 Jan 2012 09:59:26 +0100
In-Reply-To: <CAFLBxZZz19COBDvdmWmKFsr4MOSxQtxAZRYz6vBYudXFJANxtA@mail.gmail.com>
References: <1325776621.2728.7.camel@Solace>
	<CAFLBxZZz19COBDvdmWmKFsr4MOSxQtxAZRYz6vBYudXFJANxtA@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] [PATCHv3] 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="===============5458345571560142728=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5458345571560142728==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Rj9auNbsHetQQ9rSYk79"


--=-Rj9auNbsHetQQ9rSYk79
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-01-09 at 10:46 +0000, George Dunlap wrote:
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> Looks good -- thanks, Dario.
>=20
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>=20
Keir, ping. :-)

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)


--=-Rj9auNbsHetQQ9rSYk79
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)

iEYEABECAAYFAk8Wie4ACgkQk4XaBE3IOsSiPgCgnD4ObeG4tpcGwZLkaBdY+Phm
/NMAn1I96J8gispMGygOPPdwjsqUV83+
=VY5z
-----END PGP SIGNATURE-----

--=-Rj9auNbsHetQQ9rSYk79--



--===============5458345571560142728==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5458345571560142728==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:00:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09: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 1RnRNN-0001iH-EY; Wed, 18 Jan 2012 09:00: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 1RnRNL-0001hr-A6
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:00:11 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326877203!9619293!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 19267 invoked from network); 18 Jan 2012 09:00:05 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 09:00:05 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74585806; Wed, 18 Jan 2012 10:00:02 +0100
Message-ID: <1326877166.5856.1.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 18 Jan 2012 09:59:26 +0100
In-Reply-To: <CAFLBxZZz19COBDvdmWmKFsr4MOSxQtxAZRYz6vBYudXFJANxtA@mail.gmail.com>
References: <1325776621.2728.7.camel@Solace>
	<CAFLBxZZz19COBDvdmWmKFsr4MOSxQtxAZRYz6vBYudXFJANxtA@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] [PATCHv3] 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="===============5458345571560142728=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5458345571560142728==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Rj9auNbsHetQQ9rSYk79"


--=-Rj9auNbsHetQQ9rSYk79
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-01-09 at 10:46 +0000, George Dunlap wrote:
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> Looks good -- thanks, Dario.
>=20
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>=20
Keir, ping. :-)

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)


--=-Rj9auNbsHetQQ9rSYk79
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)

iEYEABECAAYFAk8Wie4ACgkQk4XaBE3IOsSiPgCgnD4ObeG4tpcGwZLkaBdY+Phm
/NMAn1I96J8gispMGygOPPdwjsqUV83+
=VY5z
-----END PGP SIGNATURE-----

--=-Rj9auNbsHetQQ9rSYk79--



--===============5458345571560142728==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5458345571560142728==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:07:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09: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 1RnRUC-0001yY-GW; Wed, 18 Jan 2012 09:07:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RnRUA-0001yN-Dk
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:07:14 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326877628!11336021!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMDUwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21748 invoked from network); 18 Jan 2012 09:07:08 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:07:08 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:Subject:References:In-Reply-To:
	Content-Type:Content-Transfer-Encoding;
	b=uUQz38vhVoKxZDDEnacijpzed51Y3QMa0k3C+z8mysVQTu565wM6G7ab
	ej3c7aFhyHDzkKNAJbDLBu5QwZ1rIaUqq/oHgM48Ri1m9Tt0TlIIJeqYU
	WwnSOpfGyQx4uKd4tsWTa0Ib7gxuNK4ZEW8WIYxDtJcm7ZgdiqCTeLoxS
	LOwmX6jHvBUR/VzsDSfZJxdKmn+eJ94i5tPNYjvcHCt7eN2awu3Si9i/Z
	45Kdg8rGoBEiiXsBMpNqGmsscSmqK;
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=1326877628; x=1358413628;
	h=message-id:date:from:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=GMyHxGipdNgiBiC8e0hu8CxN90XNoEIWRvToViIPRDQ=;
	b=JpqpuM37Eh30CPfXAg8jnjN8SBL764iWSkc3tNAFeyxSY9LAfdoU+ocG
	SmNcXoV6roHynrsnBIk0Yl6+siP6nc/+vIH9ZZATExTwOgurenIKtAZaN
	y/sWX+eInxczar2s7BH9xqAwxu6C3L58/RT+tbLBH3Dv8PhA1DunFRDSB
	s7+ndyC6qf9Owugg3vdFnMb3EkeJT7dXrCCqKRKTgIlGmp/w7YkOTOH8X
	lt2ydWBt3LBD2NNFjOpVuMa3QasW5;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,527,1320620400"; d="scan'208";a="98972839"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 18 Jan 2012 10:07:07 +0100
X-IronPort-AV: E=Sophos;i="4.71,527,1320620400"; d="scan'208";a="127287181"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 18 Jan 2012 10:07:08 +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 BF8B695F246
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 10:07:07 +0100 (CET)
Message-ID: <4F168BB6.7090905@ts.fujitsu.com>
Date: Wed, 18 Jan 2012 10:07:02 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <88318e850353da840fe7.1326876484@nehalem1>
In-Reply-To: <88318e850353da840fe7.1326876484@nehalem1>
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 09:48 AM, Juergen Gross wrote:
> On a real machine a cpu disabled via hlt with interrupts disabled can be
> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.
>
> Signed-off-by: juergen.gross@ts.fujitsu.com
>
>
> 1 file changed, 4 insertions(+), 1 deletion(-)
> xen/arch/x86/hvm/vlapic.c |    5 ++++-

BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It works
on initial system boot when the target vcpu is activated the first time. If I
deactivate a vcpu and try to activate it again it will start to run, but it is
not starting at the specified entry point (at least it isn't performing the
first instruction there).
Is there some special initialization needed to make this work? Do I have to reset
something on the vcpu before deactivating it?


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 Wed Jan 18 09:07:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09: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 1RnRUC-0001yY-GW; Wed, 18 Jan 2012 09:07:16 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RnRUA-0001yN-Dk
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:07:14 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326877628!11336021!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMDUwOQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21748 invoked from network); 18 Jan 2012 09:07:08 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:07:08 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:Subject:References:In-Reply-To:
	Content-Type:Content-Transfer-Encoding;
	b=uUQz38vhVoKxZDDEnacijpzed51Y3QMa0k3C+z8mysVQTu565wM6G7ab
	ej3c7aFhyHDzkKNAJbDLBu5QwZ1rIaUqq/oHgM48Ri1m9Tt0TlIIJeqYU
	WwnSOpfGyQx4uKd4tsWTa0Ib7gxuNK4ZEW8WIYxDtJcm7ZgdiqCTeLoxS
	LOwmX6jHvBUR/VzsDSfZJxdKmn+eJ94i5tPNYjvcHCt7eN2awu3Si9i/Z
	45Kdg8rGoBEiiXsBMpNqGmsscSmqK;
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=1326877628; x=1358413628;
	h=message-id:date:from:mime-version:to:subject:references:
	in-reply-to:content-transfer-encoding;
	bh=GMyHxGipdNgiBiC8e0hu8CxN90XNoEIWRvToViIPRDQ=;
	b=JpqpuM37Eh30CPfXAg8jnjN8SBL764iWSkc3tNAFeyxSY9LAfdoU+ocG
	SmNcXoV6roHynrsnBIk0Yl6+siP6nc/+vIH9ZZATExTwOgurenIKtAZaN
	y/sWX+eInxczar2s7BH9xqAwxu6C3L58/RT+tbLBH3Dv8PhA1DunFRDSB
	s7+ndyC6qf9Owugg3vdFnMb3EkeJT7dXrCCqKRKTgIlGmp/w7YkOTOH8X
	lt2ydWBt3LBD2NNFjOpVuMa3QasW5;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,527,1320620400"; d="scan'208";a="98972839"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 18 Jan 2012 10:07:07 +0100
X-IronPort-AV: E=Sophos;i="4.71,527,1320620400"; d="scan'208";a="127287181"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 18 Jan 2012 10:07:08 +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 BF8B695F246
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 10:07:07 +0100 (CET)
Message-ID: <4F168BB6.7090905@ts.fujitsu.com>
Date: Wed, 18 Jan 2012 10:07:02 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: xen-devel@lists.xensource.com
References: <88318e850353da840fe7.1326876484@nehalem1>
In-Reply-To: <88318e850353da840fe7.1326876484@nehalem1>
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 09:48 AM, Juergen Gross wrote:
> On a real machine a cpu disabled via hlt with interrupts disabled can be
> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.
>
> Signed-off-by: juergen.gross@ts.fujitsu.com
>
>
> 1 file changed, 4 insertions(+), 1 deletion(-)
> xen/arch/x86/hvm/vlapic.c |    5 ++++-

BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It works
on initial system boot when the target vcpu is activated the first time. If I
deactivate a vcpu and try to activate it again it will start to run, but it is
not starting at the specified entry point (at least it isn't performing the
first instruction there).
Is there some special initialization needed to make this work? Do I have to reset
something on the vcpu before deactivating it?


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 Wed Jan 18 09:29:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnRoq-0002fM-4I; Wed, 18 Jan 2012 09:28:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RnRoo-0002f5-FG
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:28:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326878908!1528663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15164 invoked from network); 18 Jan 2012 09:28:28 -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;
	18 Jan 2012 09:28:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,528,1320624000"; d="scan'208";a="10109509"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 09:28:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 09:28: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 1RnRoh-0003Ly-Mo;
	Wed, 18 Jan 2012 09:28:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnRoh-0005iH-Fh;
	Wed, 18 Jan 2012 09:28:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10870-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 09:28:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10870: 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 10870 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10870/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 10769

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                    fail pass in 10859

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10769
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-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-credit2   15 guest-stop            fail in 10859 never pass
 test-amd64-amd64-xl-sedf     15 guest-stop            fail in 10859 never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 10859 never pass

version targeted for testing:
 xen                  271e30252c16
baseline version:
 xen                  d5b26918cd94

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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:   21560:271e30252c16
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:35:30 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
changeset:   21559:75007e524cd8
user:        David Vrabel <david.vrabel@citrix.com>
date:        Tue Jan 17 11:35:03 2012 +0000
    
    x86: emulate lea with two register operands correctly
    
    An lea instruction with two register operands should raise an
    undefined instruction exception.
    
    Skype does such a instruction and will crash when starting if it does
    not get the exception.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24456:03781de56c31
    xen-unstable date:        Thu Jan 05 15:47:16 2012 +0000
    
    
changeset:   21558:3f7117070ba1
user:        Yongan Liu <Liuyongan@huawei.com>
date:        Tue Jan 17 11:34:43 2012 +0000
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24453:02b92d035f64
    xen-unstable date:        Thu Jan 05 09:29:59 2012 +0100
    
    
changeset:   21557:d5b26918cd94
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:54 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:29:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnRoq-0002fM-4I; Wed, 18 Jan 2012 09:28:36 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RnRoo-0002f5-FG
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:28:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326878908!1528663!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15164 invoked from network); 18 Jan 2012 09:28:28 -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;
	18 Jan 2012 09:28:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,528,1320624000"; d="scan'208";a="10109509"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 09:28:28 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 09:28: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 1RnRoh-0003Ly-Mo;
	Wed, 18 Jan 2012 09:28:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnRoh-0005iH-Fh;
	Wed, 18 Jan 2012 09:28:27 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10870-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 09:28:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10870: 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 10870 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10870/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win       5 xen-boot                  fail REGR. vs. 10769

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                    fail pass in 10859

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10769
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore            fail  never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore            fail never pass
 test-amd64-i386-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-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-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-credit2   15 guest-stop            fail in 10859 never pass
 test-amd64-amd64-xl-sedf     15 guest-stop            fail in 10859 never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 10859 never pass

version targeted for testing:
 xen                  271e30252c16
baseline version:
 xen                  d5b26918cd94

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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:   21560:271e30252c16
tag:         tip
user:        Jan Beulich <jbeulich@suse.com>
date:        Tue Jan 17 11:35:30 2012 +0000
    
    VMX: print Pause Loop Exiting disabled message just once
    
    ... rather than per booting CPU.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Acked-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24465:5b2676ac1321
    xen-unstable date:        Mon Jan 09 16:01:44 2012 +0100
    
    
changeset:   21559:75007e524cd8
user:        David Vrabel <david.vrabel@citrix.com>
date:        Tue Jan 17 11:35:03 2012 +0000
    
    x86: emulate lea with two register operands correctly
    
    An lea instruction with two register operands should raise an
    undefined instruction exception.
    
    Skype does such a instruction and will crash when starting if it does
    not get the exception.
    
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    xen-unstable changeset:   24456:03781de56c31
    xen-unstable date:        Thu Jan 05 15:47:16 2012 +0000
    
    
changeset:   21558:3f7117070ba1
user:        Yongan Liu <Liuyongan@huawei.com>
date:        Tue Jan 17 11:34:43 2012 +0000
    
    x86/vIRQ: IRR and TMR race condition bug fix
    
    In vlapic_set_irq, we set the IRR register before the TMR. And the IRR
    might be serviced before setting TMR, and even worse EOI might occur
    before TMR setting, in which case the vioapic_update_EOI won't be
    called, and further prevent all the subsequent interrupt injecting.
    Reorder setting the TMR and IRR will solve the problem.
    
    Besides, KVM has fixed a similar bug in:
    http://markmail.org/search/?q=APIC_TMR#query:APIC_TMR+page:1+mid:rphs4f7lkxjlldne+state:results
    
    Signed-off-by: Yongan Liu<Liuyongan@huawei.com>
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Jan Beulich <jbeulich@suse.com>
    xen-unstable changeset:   24453:02b92d035f64
    xen-unstable date:        Thu Jan 05 09:29:59 2012 +0100
    
    
changeset:   21557:d5b26918cd94
user:        Christoph Egger <Christoph.Egger@amd.com>
date:        Sun Jan 15 22:08:54 2012 +0000
    
    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>
    Backport from xen-unstable changeset 24411:ca5f588bd203 to Xen 4.0
    
    
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:30:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnRpi-0002i3-J2; Wed, 18 Jan 2012 09:29:30 +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 1RnRpg-0002hY-NA
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:29:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326878913!53022429!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 32547 invoked from network); 18 Jan 2012 09:28:33 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:28:33 -0000
Received: by wibhj8 with SMTP id hj8so14480316wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 01:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Vk3HxRC0O8Lk/1Nx/slAT9b0umLKSLdwMgF7dy0nI3U=;
	b=Vn4wD8xgBKz8bIpqw8iS3R64iod1nORbJbNEkQ7W/ONgtlRsJlndSWdCDHHP2+Aq9R
	J0MJmC9k8pngU0Y27jSkMWVO4IHMdcZY4iAZ4p7oDOUABOu7mA1gWS1T84tleIB8e7Kg
	U+Ll7SRem+1pe8mIMARjPgQ5YtlIf6aDuNlj8=
Received: by 10.180.86.5 with SMTP id l5mr35138844wiz.17.1326878964535;
	Wed, 18 Jan 2012 01:29:24 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fd1sm21647926wib.0.2012.01.18.01.29.23
	(version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 01:29:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Jan 2012 09:29:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3C4170.28FF8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
Thread-Index: AczVw6fz9sJE1eACLE2QPRLu2592ZQ==
In-Reply-To: <88318e850353da840fe7.1326876484@nehalem1>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 08:48, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> On a real machine a cpu disabled via hlt with interrupts disabled can be
> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.

I think the vcpu_kick() path is still needed where the vcpu is HLTed with
interrupts enabled. I'll have to give this a bit of thought... Probably
 clear_bit(_VPF_down)
 vcpu_wake()
 vcpu_kick()
Would work just fine.

 -- Keir

> Signed-off-by: juergen.gross@ts.fujitsu.com
> 
> 
> 1 file changed, 4 insertions(+), 1 deletion(-)
> xen/arch/x86/hvm/vlapic.c |    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 Jan 18 09:30:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnRpi-0002i3-J2; Wed, 18 Jan 2012 09:29:30 +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 1RnRpg-0002hY-NA
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:29:28 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326878913!53022429!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 32547 invoked from network); 18 Jan 2012 09:28:33 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:28:33 -0000
Received: by wibhj8 with SMTP id hj8so14480316wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 01:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=Vk3HxRC0O8Lk/1Nx/slAT9b0umLKSLdwMgF7dy0nI3U=;
	b=Vn4wD8xgBKz8bIpqw8iS3R64iod1nORbJbNEkQ7W/ONgtlRsJlndSWdCDHHP2+Aq9R
	J0MJmC9k8pngU0Y27jSkMWVO4IHMdcZY4iAZ4p7oDOUABOu7mA1gWS1T84tleIB8e7Kg
	U+Ll7SRem+1pe8mIMARjPgQ5YtlIf6aDuNlj8=
Received: by 10.180.86.5 with SMTP id l5mr35138844wiz.17.1326878964535;
	Wed, 18 Jan 2012 01:29:24 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fd1sm21647926wib.0.2012.01.18.01.29.23
	(version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 01:29:23 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Jan 2012 09:29:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3C4170.28FF8%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
Thread-Index: AczVw6fz9sJE1eACLE2QPRLu2592ZQ==
In-Reply-To: <88318e850353da840fe7.1326876484@nehalem1>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 08:48, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> On a real machine a cpu disabled via hlt with interrupts disabled can be
> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.

I think the vcpu_kick() path is still needed where the vcpu is HLTed with
interrupts enabled. I'll have to give this a bit of thought... Probably
 clear_bit(_VPF_down)
 vcpu_wake()
 vcpu_kick()
Would work just fine.

 -- Keir

> Signed-off-by: juergen.gross@ts.fujitsu.com
> 
> 
> 1 file changed, 4 insertions(+), 1 deletion(-)
> xen/arch/x86/hvm/vlapic.c |    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 Jan 18 09:31:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnRqb-0002nI-1Z; Wed, 18 Jan 2012 09:30:25 +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 1RnRqZ-0002mY-Vo
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:30:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326879017!12862255!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25100 invoked from network); 18 Jan 2012 09:30:17 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:30:17 -0000
Received: by werh12 with SMTP id h12so4035659wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 01:30:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=KdFpnX+DNTNUJi4tE1kOwqwwNnWHM1fL2qORbId/WMg=;
	b=s/3DPGq7w+9YAhANIrNunlVkspsT1srY9LoNRanBECsv0FhRyqQLnR+554ve4YFjdt
	MHxC5QFaiunCpIxbTAi1CWkBjTXWIyy9QK29DYnK7MqvDzLblHuaRWTUT4AGhfNC0shY
	uf2xip+6gWjGsEykpRhHYkV+J7/lr8H4kIr18=
Received: by 10.216.136.27 with SMTP id v27mr5944618wei.45.1326879017129;
	Wed, 18 Jan 2012 01:30:17 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id g12sm53195862wiw.10.2012.01.18.01.30.15
	(version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 01:30:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Jan 2012 09:30:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Dario Faggioli <raistlin@linux.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CB3C41A5.28FF9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCHv3] sedf: remove useless tracing printk and
	harmonize comments style.
Thread-Index: AczVw8eKjcOTehEh8kyYNMz46fh8MQ==
In-Reply-To: <1326877166.5856.1.camel@Solace>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv3] 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/01/2012 08:59, "Dario Faggioli" <raistlin@linux.it> wrote:

> On Mon, 2012-01-09 at 10:46 +0000, George Dunlap wrote:
>>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>> 
>> Looks good -- thanks, Dario.
>> 
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> 
> Keir, ping. :-)

Already applied xen-unstable:24512.

> Dario



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:31:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnRqb-0002nI-1Z; Wed, 18 Jan 2012 09:30:25 +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 1RnRqZ-0002mY-Vo
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:30:24 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326879017!12862255!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25100 invoked from network); 18 Jan 2012 09:30:17 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:30:17 -0000
Received: by werh12 with SMTP id h12so4035659wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 01:30:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=KdFpnX+DNTNUJi4tE1kOwqwwNnWHM1fL2qORbId/WMg=;
	b=s/3DPGq7w+9YAhANIrNunlVkspsT1srY9LoNRanBECsv0FhRyqQLnR+554ve4YFjdt
	MHxC5QFaiunCpIxbTAi1CWkBjTXWIyy9QK29DYnK7MqvDzLblHuaRWTUT4AGhfNC0shY
	uf2xip+6gWjGsEykpRhHYkV+J7/lr8H4kIr18=
Received: by 10.216.136.27 with SMTP id v27mr5944618wei.45.1326879017129;
	Wed, 18 Jan 2012 01:30:17 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id g12sm53195862wiw.10.2012.01.18.01.30.15
	(version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 01:30:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Jan 2012 09:30:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Dario Faggioli <raistlin@linux.it>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CB3C41A5.28FF9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCHv3] sedf: remove useless tracing printk and
	harmonize comments style.
Thread-Index: AczVw8eKjcOTehEh8kyYNMz46fh8MQ==
In-Reply-To: <1326877166.5856.1.camel@Solace>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv3] 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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 18/01/2012 08:59, "Dario Faggioli" <raistlin@linux.it> wrote:

> On Mon, 2012-01-09 at 10:46 +0000, George Dunlap wrote:
>>> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>> 
>> Looks good -- thanks, Dario.
>> 
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> 
> Keir, ping. :-)

Already applied xen-unstable:24512.

> Dario



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:32:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09: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 1RnRro-0002xN-N5; Wed, 18 Jan 2012 09:31:40 +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 1RnRrm-0002wM-Kq
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:31:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326879065!56175428!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10702 invoked from network); 18 Jan 2012 09:31:05 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:31:05 -0000
Received: by werh12 with SMTP id h12so4038569wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 01:31: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=dZPT/CL81uiXJP2K6H+XAB7L8oh8eI7lTZ8QslCk+pw=;
	b=eKnc5A4gX5hyqDg829RjsefI5EfB0ndBrg4xn0C8WheUSXV9SsaXGAoGzWhA847ati
	97DBufJqSJvVw07308lkCMmY3cZLet5w6HgKwS+6ESNVnovDojOKQM36x2i35E9hSfRT
	1dqzJqyygUVRmMMH5YCNEkPTZMPxQo46/tw1A=
Received: by 10.216.134.36 with SMTP id r36mr9308638wei.40.1326879092403;
	Wed, 18 Jan 2012 01:31:32 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id r1sm21420403wia.8.2012.01.18.01.31.30
	(version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 01:31:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Jan 2012 09:31:28 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3C41F0.28FFA%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
Thread-Index: AczVw/Q+Cjbk8B14+Uy6l0c+PxeTZw==
In-Reply-To: <4F168BB6.7090905@ts.fujitsu.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 09:07, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>> On a real machine a cpu disabled via hlt with interrupts disabled can be
>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.
>> 
>> Signed-off-by: juergen.gross@ts.fujitsu.com
>> 
>> 
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
> 
> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It works
> on initial system boot when the target vcpu is activated the first time. If I
> deactivate a vcpu and try to activate it again it will start to run, but it is
> not starting at the specified entry point (at least it isn't performing the
> first instruction there).
> Is there some special initialization needed to make this work? Do I have to
> reset
> something on the vcpu before deactivating it?

No it should just work. Hvmloader wakes and then sleeps every AP, in
hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS
is not the first, as hvmloader already did it once! So this path should be
working and indeed tested on every HVM guest boot.

 -- Keir

> 
> Juergen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:32:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09: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 1RnRro-0002xN-N5; Wed, 18 Jan 2012 09:31:40 +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 1RnRrm-0002wM-Kq
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:31:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326879065!56175428!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10702 invoked from network); 18 Jan 2012 09:31:05 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:31:05 -0000
Received: by werh12 with SMTP id h12so4038569wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 01:31: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=dZPT/CL81uiXJP2K6H+XAB7L8oh8eI7lTZ8QslCk+pw=;
	b=eKnc5A4gX5hyqDg829RjsefI5EfB0ndBrg4xn0C8WheUSXV9SsaXGAoGzWhA847ati
	97DBufJqSJvVw07308lkCMmY3cZLet5w6HgKwS+6ESNVnovDojOKQM36x2i35E9hSfRT
	1dqzJqyygUVRmMMH5YCNEkPTZMPxQo46/tw1A=
Received: by 10.216.134.36 with SMTP id r36mr9308638wei.40.1326879092403;
	Wed, 18 Jan 2012 01:31:32 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id r1sm21420403wia.8.2012.01.18.01.31.30
	(version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 01:31:31 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Jan 2012 09:31:28 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3C41F0.28FFA%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
Thread-Index: AczVw/Q+Cjbk8B14+Uy6l0c+PxeTZw==
In-Reply-To: <4F168BB6.7090905@ts.fujitsu.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 09:07, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>> On a real machine a cpu disabled via hlt with interrupts disabled can be
>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.
>> 
>> Signed-off-by: juergen.gross@ts.fujitsu.com
>> 
>> 
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
> 
> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It works
> on initial system boot when the target vcpu is activated the first time. If I
> deactivate a vcpu and try to activate it again it will start to run, but it is
> not starting at the specified entry point (at least it isn't performing the
> first instruction there).
> Is there some special initialization needed to make this work? Do I have to
> reset
> something on the vcpu before deactivating it?

No it should just work. Hvmloader wakes and then sleeps every AP, in
hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS
is not the first, as hvmloader already did it once! So this path should be
working and indeed tested on every HVM guest boot.

 -- Keir

> 
> Juergen



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:37:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnRwW-0003LE-EV; Wed, 18 Jan 2012 09:36:32 +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 1RnRwU-0003L4-7X
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:36:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326879383!11310368!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 32133 invoked from network); 18 Jan 2012 09:36:23 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:36:23 -0000
Received: by wibhj8 with SMTP id hj8so14494494wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 01:36:22 -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=0MIiB//OZ17yAL7ZeB3IfsfHro+pQS1Ec1Xcw46N/Ps=;
	b=NB7V1/NVqDCvQDIjZ9KVwWoy+rFEAMTnB8BES3n80KnZvihn69l2DsdbQF1UGm8tio
	DP+o4j70ovlM707Zrg/xWgsPonpcOOXLgkwgNMM6vZV4qZr4vt9L1IETyVFECmW06J1+
	yhIUbO0CHuZ/I6fGP1NwQ6KmrECxI3mdxOHpI=
Received: by 10.180.92.101 with SMTP id cl5mr10190242wib.21.1326879382856;
	Wed, 18 Jan 2012 01:36:22 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l2sm40811322wie.11.2012.01.18.01.36.21
	(version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 01:36:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Jan 2012 09:36:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3C430D.29008%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
Thread-Index: AczVw/Q+Cjbk8B14+Uy6l0c+PxeTZwAAKnhc
In-Reply-To: <CB3C41F0.28FFA%keir.xen@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 09:31, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 18/01/2012 09:07, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:
> 
>> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>>> On a real machine a cpu disabled via hlt with interrupts disabled can be
>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.
>>> 
>>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>> 
>>> 
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
>> 
>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It
>> works
>> on initial system boot when the target vcpu is activated the first time. If I
>> deactivate a vcpu and try to activate it again it will start to run, but it
>> is
>> not starting at the specified entry point (at least it isn't performing the
>> first instruction there).
>> Is there some special initialization needed to make this work? Do I have to
>> reset
>> something on the vcpu before deactivating it?
> 
> No it should just work. Hvmloader wakes and then sleeps every AP, in
> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS
> is not the first, as hvmloader already did it once! So this path should be
> working and indeed tested on every HVM guest boot.

Bit more info: INIT-SIPI logic is complicated by needing to avoid deadlocks
between two VCPUs attempting to pause and reset each other. But the core
dispatch logic is in vlapic_init_sipi_action(). You will see that on INIT,
we should call vcpu_reset() which will de-initialise and VCPU_down the vcpu.
And then on SIPI we call hvm_vcpu_reset_state(), which should reinitialise
and wake the vcpu to start running at the specified CS:IP.

So the above will be good places for you to add tracing and work out what's
going on. :-)

 -- Keir

>  -- Keir
> 
>> 
>> Juergen
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:37:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:37:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnRwW-0003LE-EV; Wed, 18 Jan 2012 09:36:32 +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 1RnRwU-0003L4-7X
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:36:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326879383!11310368!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 32133 invoked from network); 18 Jan 2012 09:36:23 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 09:36:23 -0000
Received: by wibhj8 with SMTP id hj8so14494494wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 01:36:22 -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=0MIiB//OZ17yAL7ZeB3IfsfHro+pQS1Ec1Xcw46N/Ps=;
	b=NB7V1/NVqDCvQDIjZ9KVwWoy+rFEAMTnB8BES3n80KnZvihn69l2DsdbQF1UGm8tio
	DP+o4j70ovlM707Zrg/xWgsPonpcOOXLgkwgNMM6vZV4qZr4vt9L1IETyVFECmW06J1+
	yhIUbO0CHuZ/I6fGP1NwQ6KmrECxI3mdxOHpI=
Received: by 10.180.92.101 with SMTP id cl5mr10190242wib.21.1326879382856;
	Wed, 18 Jan 2012 01:36:22 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l2sm40811322wie.11.2012.01.18.01.36.21
	(version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 01:36:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 18 Jan 2012 09:36:13 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3C430D.29008%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
Thread-Index: AczVw/Q+Cjbk8B14+Uy6l0c+PxeTZwAAKnhc
In-Reply-To: <CB3C41F0.28FFA%keir.xen@gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 09:31, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 18/01/2012 09:07, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:
> 
>> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>>> On a real machine a cpu disabled via hlt with interrupts disabled can be
>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.
>>> 
>>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>> 
>>> 
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
>> 
>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It
>> works
>> on initial system boot when the target vcpu is activated the first time. If I
>> deactivate a vcpu and try to activate it again it will start to run, but it
>> is
>> not starting at the specified entry point (at least it isn't performing the
>> first instruction there).
>> Is there some special initialization needed to make this work? Do I have to
>> reset
>> something on the vcpu before deactivating it?
> 
> No it should just work. Hvmloader wakes and then sleeps every AP, in
> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS
> is not the first, as hvmloader already did it once! So this path should be
> working and indeed tested on every HVM guest boot.

Bit more info: INIT-SIPI logic is complicated by needing to avoid deadlocks
between two VCPUs attempting to pause and reset each other. But the core
dispatch logic is in vlapic_init_sipi_action(). You will see that on INIT,
we should call vcpu_reset() which will de-initialise and VCPU_down the vcpu.
And then on SIPI we call hvm_vcpu_reset_state(), which should reinitialise
and wake the vcpu to start running at the specified CS:IP.

So the above will be good places for you to add tracing and work out what's
going on. :-)

 -- Keir

>  -- Keir
> 
>> 
>> Juergen
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:51:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSAP-0003Wd-9B; Wed, 18 Jan 2012 09:50:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RnSAN-0003WJ-Km
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:50:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326880245!11536498!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 25983 invoked from network); 18 Jan 2012 09:50:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jan 2012 09:50:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 09:50:44 +0000
Message-Id: <4F16A402020000780006D571@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 09:50:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
In-Reply-To: <4F15B5C6.6070808@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] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.01.12 at 18:54, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 01/17/12 03:26, Jan Beulich wrote:
>>>>> On 16.01.12 at 22:11, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> --- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
>>> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
>>> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>>>                       bitmaskof(X86_FEATURE_SSE4A) |
>>>                       bitmaskof(X86_FEATURE_MISALIGNSSE) |
>>>                       bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
>>> +		    bitmaskof(X86_FEATURE_OSVW) |
>>
>> Indentation.
>>
>> Also, is this really meaningful to PV guests?
> 
> Does amd_xc_cpuid_policy() get called for PV guests? I thought this is 
> HVM path only.

In that case I simply misplaced the comment.

> xc_cpuid_pv_policy() is where clear_bit(X86_FEATURE_OSVW, regs[2]) was 
> removed to handle PV.
> 
> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum 
> 400 as an example -- we don't need a Linux PV guest reading an MSR 
> before going to idle (in amd_e400_idle()).

It is bogus in the first place if a pv guest does so - after all, not doing
stuff like this is the nature of being pv.

>> And valid for pre-Fam10?
> 
> No, it indeed shouldn't be set in those cases.
> 
> I could set the bit conditionally, based on host family but the trouble 
> is I don't necessarily know what family the guest will be. Or is this 
> known at this point?

I think basing this on the host family is a good first shot. I would hope
others could comment on how to properly deal with a dependency like
this...

>>> --- a/xen/arch/x86/cpu/amd.c	Mon Jan 09 16:01:44 2012 +0100
>>> +++ b/xen/arch/x86/cpu/amd.c	Mon Jan 16 22:08:09 2012 +0100
>>> @@ -32,6 +32,13 @@
>>>   static char opt_famrev[14];
>>>   string_param("cpuid_mask_cpu", opt_famrev);
>>>
>>> +/*
>>> + * Set osvw_len to higher number when updated Revision Guides
>>> + * are published and we know what the new status bits are
>>> + */
>>
>> This is ugly, as it requires permanent attention. The value to start
>> with should really be 64 (beyond which other code adjustments are
>> going to be necessary anyway).
> 
> I went back and forth on this. The reason I settled on 4 is because we 
> obviously don't know what errata the higher bits will cover and because 
> it is (at least theoretically) possible that a guest shouldn't see the 
> same status bits as the host.

I think allowing the guest to know of (not) worked around errata is
even desirable (aiui in the worst case it'll apply a redundant fix).

>>> +    vcpu->arch.amd.osvw.status = osvw_status&  ~(6ULL);
>>> +
>>> +    /*
>>> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
>>> +     * all osvw.status bits inside that length, including bit 0 (which is
>>> +     * reserved for erratum 298), are valid. However, if host processor's
>>> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
>>> +     * be conservative here and therefore we tell the guest that erratum 
> 298
>>> +     * is present (because we really don't know).
>>> +     */
>>> +    if (osvw_length == 0&&  boot_cpu_data.x86 == 0x10)
>>
>> Why do you check the family here? If osvw_length can only ever be
>> zero on Fam10, then the first check is sufficient. If osvw_length can
>> be zero on other than Fam10 (no matter whether we bail early older
>> CPUs), then the check is actually wrong.
> 
> 10h is the only family affected by this erratum.

What is "this erratum" here? My comment was to suggest that either
of the two conditions can likely be eliminated for being redundant.

>>> --- a/xen/arch/x86/traps.c	Mon Jan 09 16:01:44 2012 +0100
>>> +++ b/xen/arch/x86/traps.c	Mon Jan 16 22:08:09 2012 +0100
>>> @@ -2542,6 +2542,15 @@ static int emulate_privileged_op(struct
>>>               if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
>>>                   goto fail;
>>>               break;
>>> +        case MSR_AMD_OSVW_ID_LENGTH:
>>> +        case MSR_AMD_OSVW_STATUS:
>>> +            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) {
>>> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
>>> +                    goto fail;
>>> +                else
>>
>> Bogus "else" after a "goto". And I wonder, provided there is some
>> point in doing all this for PV guests in the first place, whether this
>> shouldn't be kept getting handled by the default case.
> 
> 
> If we go into default case we will emit "Domain attempted WRMSR ..." 
> message in the log. I was trying to avoid that since writing to these 
> registers is not really an error, it just gets ignored.

The documentation says that both MSRs are read/write, so issuing a
message here appears to be The Right Thing (tm). Kernels shouldn't
be doing this in general, and for PV kernels imo it is definitely a 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 Jan 18 09:51:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSAM-0003WQ-T9; Wed, 18 Jan 2012 09:50:50 +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 1RnSAM-0003WH-1m
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:50:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326880243!11515667!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 18614 invoked from network); 18 Jan 2012 09:50:43 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 09:50:43 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74587725; Wed, 18 Jan 2012 10:50:43 +0100
Message-ID: <1326880219.5856.7.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Keir Fraser <keir.xen@gmail.com>
Date: Wed, 18 Jan 2012 10:50:19 +0100
In-Reply-To: <CB3C41A5.28FF9%keir.xen@gmail.com>
References: <CB3C41A5.28FF9%keir.xen@gmail.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv3] 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="===============6961375274693036259=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6961375274693036259==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-H3TfU7KVxwL0TcfLSZFi"


--=-H3TfU7KVxwL0TcfLSZFi
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-18 at 09:30 +0000, Keir Fraser wrote:
> > Keir, ping. :-)
>=20
> Already applied xen-unstable:24512.
>=20
Oops! Sorry then, I didn't notice... :-P

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)


--=-H3TfU7KVxwL0TcfLSZFi
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)

iEYEABECAAYFAk8WldsACgkQk4XaBE3IOsQnzgCffIfSEFArJokoMHu2baSv/2A9
i90An3k72Vu8af4CgnNbtqm16HoY8O5M
=EhhE
-----END PGP SIGNATURE-----

--=-H3TfU7KVxwL0TcfLSZFi--



--===============6961375274693036259==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6961375274693036259==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 09:51:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSAP-0003Wd-9B; Wed, 18 Jan 2012 09:50:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RnSAN-0003WJ-Km
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:50:51 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326880245!11536498!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 25983 invoked from network); 18 Jan 2012 09:50:45 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jan 2012 09:50:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 09:50:44 +0000
Message-Id: <4F16A402020000780006D571@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 09:50:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
In-Reply-To: <4F15B5C6.6070808@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] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.01.12 at 18:54, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 01/17/12 03:26, Jan Beulich wrote:
>>>>> On 16.01.12 at 22:11, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> --- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
>>> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
>>> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>>>                       bitmaskof(X86_FEATURE_SSE4A) |
>>>                       bitmaskof(X86_FEATURE_MISALIGNSSE) |
>>>                       bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
>>> +		    bitmaskof(X86_FEATURE_OSVW) |
>>
>> Indentation.
>>
>> Also, is this really meaningful to PV guests?
> 
> Does amd_xc_cpuid_policy() get called for PV guests? I thought this is 
> HVM path only.

In that case I simply misplaced the comment.

> xc_cpuid_pv_policy() is where clear_bit(X86_FEATURE_OSVW, regs[2]) was 
> removed to handle PV.
> 
> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum 
> 400 as an example -- we don't need a Linux PV guest reading an MSR 
> before going to idle (in amd_e400_idle()).

It is bogus in the first place if a pv guest does so - after all, not doing
stuff like this is the nature of being pv.

>> And valid for pre-Fam10?
> 
> No, it indeed shouldn't be set in those cases.
> 
> I could set the bit conditionally, based on host family but the trouble 
> is I don't necessarily know what family the guest will be. Or is this 
> known at this point?

I think basing this on the host family is a good first shot. I would hope
others could comment on how to properly deal with a dependency like
this...

>>> --- a/xen/arch/x86/cpu/amd.c	Mon Jan 09 16:01:44 2012 +0100
>>> +++ b/xen/arch/x86/cpu/amd.c	Mon Jan 16 22:08:09 2012 +0100
>>> @@ -32,6 +32,13 @@
>>>   static char opt_famrev[14];
>>>   string_param("cpuid_mask_cpu", opt_famrev);
>>>
>>> +/*
>>> + * Set osvw_len to higher number when updated Revision Guides
>>> + * are published and we know what the new status bits are
>>> + */
>>
>> This is ugly, as it requires permanent attention. The value to start
>> with should really be 64 (beyond which other code adjustments are
>> going to be necessary anyway).
> 
> I went back and forth on this. The reason I settled on 4 is because we 
> obviously don't know what errata the higher bits will cover and because 
> it is (at least theoretically) possible that a guest shouldn't see the 
> same status bits as the host.

I think allowing the guest to know of (not) worked around errata is
even desirable (aiui in the worst case it'll apply a redundant fix).

>>> +    vcpu->arch.amd.osvw.status = osvw_status&  ~(6ULL);
>>> +
>>> +    /*
>>> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
>>> +     * all osvw.status bits inside that length, including bit 0 (which is
>>> +     * reserved for erratum 298), are valid. However, if host processor's
>>> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
>>> +     * be conservative here and therefore we tell the guest that erratum 
> 298
>>> +     * is present (because we really don't know).
>>> +     */
>>> +    if (osvw_length == 0&&  boot_cpu_data.x86 == 0x10)
>>
>> Why do you check the family here? If osvw_length can only ever be
>> zero on Fam10, then the first check is sufficient. If osvw_length can
>> be zero on other than Fam10 (no matter whether we bail early older
>> CPUs), then the check is actually wrong.
> 
> 10h is the only family affected by this erratum.

What is "this erratum" here? My comment was to suggest that either
of the two conditions can likely be eliminated for being redundant.

>>> --- a/xen/arch/x86/traps.c	Mon Jan 09 16:01:44 2012 +0100
>>> +++ b/xen/arch/x86/traps.c	Mon Jan 16 22:08:09 2012 +0100
>>> @@ -2542,6 +2542,15 @@ static int emulate_privileged_op(struct
>>>               if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
>>>                   goto fail;
>>>               break;
>>> +        case MSR_AMD_OSVW_ID_LENGTH:
>>> +        case MSR_AMD_OSVW_STATUS:
>>> +            if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD ) {
>>> +                if (!boot_cpu_has(X86_FEATURE_OSVW))
>>> +                    goto fail;
>>> +                else
>>
>> Bogus "else" after a "goto". And I wonder, provided there is some
>> point in doing all this for PV guests in the first place, whether this
>> shouldn't be kept getting handled by the default case.
> 
> 
> If we go into default case we will emit "Domain attempted WRMSR ..." 
> message in the log. I was trying to avoid that since writing to these 
> registers is not really an error, it just gets ignored.

The documentation says that both MSRs are read/write, so issuing a
message here appears to be The Right Thing (tm). Kernels shouldn't
be doing this in general, and for PV kernels imo it is definitely a 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 Jan 18 09:51:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 09:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSAM-0003WQ-T9; Wed, 18 Jan 2012 09:50:50 +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 1RnSAM-0003WH-1m
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 09:50:50 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326880243!11515667!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 18614 invoked from network); 18 Jan 2012 09:50:43 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 09:50:43 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74587725; Wed, 18 Jan 2012 10:50:43 +0100
Message-ID: <1326880219.5856.7.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Keir Fraser <keir.xen@gmail.com>
Date: Wed, 18 Jan 2012 10:50:19 +0100
In-Reply-To: <CB3C41A5.28FF9%keir.xen@gmail.com>
References: <CB3C41A5.28FF9%keir.xen@gmail.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv3] 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="===============6961375274693036259=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6961375274693036259==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-H3TfU7KVxwL0TcfLSZFi"


--=-H3TfU7KVxwL0TcfLSZFi
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-18 at 09:30 +0000, Keir Fraser wrote:
> > Keir, ping. :-)
>=20
> Already applied xen-unstable:24512.
>=20
Oops! Sorry then, I didn't notice... :-P

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)


--=-H3TfU7KVxwL0TcfLSZFi
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)

iEYEABECAAYFAk8WldsACgkQk4XaBE3IOsQnzgCffIfSEFArJokoMHu2baSv/2A9
i90An3k72Vu8af4CgnNbtqm16HoY8O5M
=EhhE
-----END PGP SIGNATURE-----

--=-H3TfU7KVxwL0TcfLSZFi--



--===============6961375274693036259==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6961375274693036259==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSc6-0004dK-8W; Wed, 18 Jan 2012 10:19:30 +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 1RnSc4-0004cj-RD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326881962!11504875!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 18473 invoked from network); 18 Jan 2012 10:19:22 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:22 -0000
Received: by wibhj8 with SMTP id hj8so14586977wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=JfaOewaoyTAgXAp0HOppsBq/0HIt11UCS8vPY7/W4+8=;
	b=DsXQjXv6jeCz8JmDYaily1Ss1vwR+VIxljGliqfVAuTXfVUCK20XUuQeEfTM7lYlCi
	W5JYRxtlYB9aaoFjk0RvaquE/B10J03XIbRXKZ7ypaRz7gAIyqRPclwz2bhu2+2MMmLw
	WgUI+20OYi5VnWbVb74YHRWWGWBmbnDQ1I6+s=
Received: by 10.180.93.132 with SMTP id cu4mr30089075wib.9.1326881961831;
	Wed, 18 Jan 2012 02:19:21 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:20 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b9a79fd1b93d44cf7b9ccf288c9f5df169adeb4d
Message-Id: <b9a79fd1b93d44cf7b9c.1326880687@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:07 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 13 RFC] libxl: allow libxl__exec to take a
 parameter containing the env variables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324934702 -3600
# Node ID b9a79fd1b93d44cf7b9ccf288c9f5df169adeb4d
# Parent  25752ced44427caec863c3e64185429c39b28c3a
libxl: allow libxl__exec to take a parameter containing the env variables

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 25752ced4442 -r b9a79fd1b93d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl.c	Mon Dec 26 22:25:02 2011 +0100
@@ -951,7 +951,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff -r 25752ced4442 -r b9a79fd1b93d tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_bootloader.c	Mon Dec 26 22:25:02 2011 +0100
@@ -116,12 +116,12 @@ static int open_xenconsoled_pty(int *mas
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff -r 25752ced4442 -r b9a79fd1b93d tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_dm.c	Mon Dec 26 22:25:02 2011 +0100
@@ -884,7 +884,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff -r 25752ced4442 -r b9a79fd1b93d 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	Mon Dec 26 22:25:02 2011 +0100
@@ -83,7 +83,7 @@ static void check_open_fds(const char *w
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -106,6 +106,11 @@ void libxl__exec(int stdinfd, int stdout
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff -r 25752ced4442 -r b9a79fd1b93d 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	Mon Dec 26 22:25:02 2011 +0100
@@ -451,7 +451,7 @@ _hidden int libxl__spawn_check(libxl__gc
  /* low-level stuff, for synchronous subprocesses etc. */
 
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSc6-0004dK-8W; Wed, 18 Jan 2012 10:19:30 +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 1RnSc4-0004cj-RD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:29 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326881962!11504875!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 18473 invoked from network); 18 Jan 2012 10:19:22 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:22 -0000
Received: by wibhj8 with SMTP id hj8so14586977wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=JfaOewaoyTAgXAp0HOppsBq/0HIt11UCS8vPY7/W4+8=;
	b=DsXQjXv6jeCz8JmDYaily1Ss1vwR+VIxljGliqfVAuTXfVUCK20XUuQeEfTM7lYlCi
	W5JYRxtlYB9aaoFjk0RvaquE/B10J03XIbRXKZ7ypaRz7gAIyqRPclwz2bhu2+2MMmLw
	WgUI+20OYi5VnWbVb74YHRWWGWBmbnDQ1I6+s=
Received: by 10.180.93.132 with SMTP id cu4mr30089075wib.9.1326881961831;
	Wed, 18 Jan 2012 02:19:21 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.20
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:20 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b9a79fd1b93d44cf7b9ccf288c9f5df169adeb4d
Message-Id: <b9a79fd1b93d44cf7b9c.1326880687@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:07 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 13 RFC] libxl: allow libxl__exec to take a
 parameter containing the env variables
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1324934702 -3600
# Node ID b9a79fd1b93d44cf7b9ccf288c9f5df169adeb4d
# Parent  25752ced44427caec863c3e64185429c39b28c3a
libxl: allow libxl__exec to take a parameter containing the env variables

Add another parameter to libxl__exec call that contains the
environment variables to use when performing the execvp call.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 25752ced4442 -r b9a79fd1b93d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl.c	Mon Dec 26 22:25:02 2011 +0100
@@ -951,7 +951,7 @@ int libxl_vncviewer_exec(libxl_ctx *ctx,
         args[2] = "-autopass";
     }
 
-    libxl__exec(autopass_fd, -1, -1, args[0], args);
+    libxl__exec(autopass_fd, -1, -1, args[0], args, NULL);
     abort();
 
  x_fail:
diff -r 25752ced4442 -r b9a79fd1b93d tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_bootloader.c	Mon Dec 26 22:25:02 2011 +0100
@@ -116,12 +116,12 @@ static int open_xenconsoled_pty(int *mas
 static pid_t fork_exec_bootloader(int *master, const char *arg0, char **args)
 {
     struct termios termattr;
+    char *env[] = {"TERM", "vt100", NULL};
     pid_t pid = forkpty(master, NULL, NULL, NULL);
     if (pid == -1)
         return -1;
     else if (pid == 0) {
-        setenv("TERM", "vt100", 1);
-        libxl__exec(-1, -1, -1, arg0, args);
+        libxl__exec(-1, -1, -1, arg0, args, env);
         return -1;
     }
 
diff -r 25752ced4442 -r b9a79fd1b93d tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_dm.c	Mon Dec 26 22:25:02 2011 +0100
@@ -884,7 +884,7 @@ retry_transaction:
         goto out_close;
     if (!rc) { /* inner child */
         setsid();
-        libxl__exec(null, logfile_w, logfile_w, dm, args);
+        libxl__exec(null, logfile_w, logfile_w, dm, args, NULL);
     }
 
     rc = 0;
diff -r 25752ced4442 -r b9a79fd1b93d 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	Mon Dec 26 22:25:02 2011 +0100
@@ -83,7 +83,7 @@ static void check_open_fds(const char *w
 }
 
 void libxl__exec(int stdinfd, int stdoutfd, int stderrfd, const char *arg0,
-                char **args)
+                char **args, char **env)
      /* call this in the child */
 {
     if (stdinfd != -1)
@@ -106,6 +106,11 @@ void libxl__exec(int stdinfd, int stdout
     /* in case our caller set it to IGN.  subprocesses are entitled
      * to assume they got DFL. */
 
+    if (env != NULL) {
+        for (int i = 0; env[i] != NULL && env[i+1] != NULL; i += 2) {
+            setenv(env[i], env[i+1], 1);
+        }
+    }
     execvp(arg0, args);
 
     fprintf(stderr, "libxl: cannot execute %s: %s\n", arg0, strerror(errno));
diff -r 25752ced4442 -r b9a79fd1b93d 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	Mon Dec 26 22:25:02 2011 +0100
@@ -451,7 +451,7 @@ _hidden int libxl__spawn_check(libxl__gc
  /* low-level stuff, for synchronous subprocesses etc. */
 
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
-               const char *arg0, char **args); // logs errors, never returns
+               const char *arg0, char **args, char **env); // logs errors, never returns
 
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSc1-0004cp-F9; Wed, 18 Jan 2012 10:19:25 +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 1RnSc0-0004ch-9P
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:24 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!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 29341 invoked from network); 18 Jan 2012 10:18:36 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:18:36 -0000
Received: by wgbdr11 with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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
	:message-id:user-agent:date:from:to;
	bh=u9k55ZKa5U0fiTZ08bLyyuU+64E/ojyYa7t2xHd2ks0=;
	b=Nj0Y4Ikz1s7MhRzg1qEX5drPXZxwCIfi6GkvoQc8mSFtyX7LFCNg/zpGKidHKIuTUT
	+EKCpXQ3eP1oQOMWFZ9rTFiZM/mdC1gq5hIRcWQ2+dkfxlX44pS+QgcGF7Go9F7vCYWR
	wB4Gr7GD4LEYvG5BQqlMHZxrUEMI2h7ks3zVQ=
Received: by 10.180.88.10 with SMTP id bc10mr35505571wib.13.1326881958061;
	Wed, 18 Jan 2012 02:19:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:17 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:05 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 13 RFC] libxl: add 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

This series is a WIP, and I'm posting it now that it has reached a 
state where hotplug scripts are called directly from libxl from both 
Linux and NetBSD. The series has been tested with Debian stable and 
NetBSD current. This is not intented to be commited to the repository, 
mainly because it breaks xend by disabling udev rules on Linux. Also, 
this should be applied on top of my previous patches:

libxl: fix parse_backend_path and device_backend_path to be mutual
libxl: Atomicaly check backend state and set it to 5 at device_remove
qemu: react to XenbusStateClosing

Having that said, I have in mind to move this into a separate daemon, 
just like xenbackendd, but instead of listening to 
/local/domain/<domid>/backend/ for changes the daemon should listen to 
/hotplug/<domid>/. Then when the Dom0 request the addition of a 
device (by writting the necessary entries to /hotplug/<domid>/), the 
daemon should call libxl_device_*_add(...) and the same when the 
device is removed (I think you can get the idea).

It would be nice if someone could take a look at this while I work on 
the rest of the series, since I think that this *could* be a separate 
series if it didn't break xend compatibility. In fact it will be nice 
to split driver domains into two separate series, one that adds 
hotplug script calling to libxl (the former), and the other one that 
moves the device hotplug into a separate daemon, this will probably be 
less painful than reviewing all at once.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSc1-0004cp-F9; Wed, 18 Jan 2012 10:19:25 +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 1RnSc0-0004ch-9P
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:24 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!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 29341 invoked from network); 18 Jan 2012 10:18:36 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:18:36 -0000
Received: by wgbdr11 with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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
	:message-id:user-agent:date:from:to;
	bh=u9k55ZKa5U0fiTZ08bLyyuU+64E/ojyYa7t2xHd2ks0=;
	b=Nj0Y4Ikz1s7MhRzg1qEX5drPXZxwCIfi6GkvoQc8mSFtyX7LFCNg/zpGKidHKIuTUT
	+EKCpXQ3eP1oQOMWFZ9rTFiZM/mdC1gq5hIRcWQ2+dkfxlX44pS+QgcGF7Go9F7vCYWR
	wB4Gr7GD4LEYvG5BQqlMHZxrUEMI2h7ks3zVQ=
Received: by 10.180.88.10 with SMTP id bc10mr35505571wib.13.1326881958061;
	Wed, 18 Jan 2012 02:19:18 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:17 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:05 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 13 RFC] libxl: add 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

This series is a WIP, and I'm posting it now that it has reached a 
state where hotplug scripts are called directly from libxl from both 
Linux and NetBSD. The series has been tested with Debian stable and 
NetBSD current. This is not intented to be commited to the repository, 
mainly because it breaks xend by disabling udev rules on Linux. Also, 
this should be applied on top of my previous patches:

libxl: fix parse_backend_path and device_backend_path to be mutual
libxl: Atomicaly check backend state and set it to 5 at device_remove
qemu: react to XenbusStateClosing

Having that said, I have in mind to move this into a separate daemon, 
just like xenbackendd, but instead of listening to 
/local/domain/<domid>/backend/ for changes the daemon should listen to 
/hotplug/<domid>/. Then when the Dom0 request the addition of a 
device (by writting the necessary entries to /hotplug/<domid>/), the 
daemon should call libxl_device_*_add(...) and the same when the 
device is removed (I think you can get the idea).

It would be nice if someone could take a look at this while I work on 
the rest of the series, since I think that this *could* be a separate 
series if it didn't break xend compatibility. In fact it will be nice 
to split driver domains into two separate series, one that adds 
hotplug script calling to libxl (the former), and the other one that 
moves the device hotplug into a separate daemon, this will probably be 
less painful than reviewing all at once.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScA-0004ef-89; Wed, 18 Jan 2012 10:19:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RnSc8-0004dy-Ce
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!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 30401 invoked from network); 18 Jan 2012 10:18:49 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:18:49 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=pHYBWTP7ZDoHSr0uUxniGlHSieJ3DbOJf5ICF7r5+oQ=;
	b=wT1vGndwUBocnIfWxnmczy7qYcEPXCYuNlkkLK1PWHIdvjYvZ5mMZ0YuhhqeHJGVa9
	0v4ihhBSFDgMbHhpHuBk+U2/C83CI7BZ9b9ln7OmVc0FFa1gi/oAuGwtJ7FsOxhc8qY1
	P7kmWkMYGVQfYlRRncgO+7HAna6fMiTzVLUrI=
Received: by 10.180.99.199 with SMTP id es7mr25838837wib.10.1326881971266;
	Wed, 18 Jan 2012 02:19:31 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f7b6d7cd98202be1ca642949c4722c5e6da75540
Message-Id: <f7b6d7cd98202be1ca64.1326880691@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:11 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 13 RFC] libxl: perform xenstore device
	cleanup from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728389 -3600
# Node ID f7b6d7cd98202be1ca642949c4722c5e6da75540
# Parent  0b45289e57b9fbeee3780f24a6398f7911a3320c
libxl: perform xenstore device cleanup from libxl

Perform cleanup of xenstore device entries in libxl, instead of
relying on xen-hotplug-cleanup script.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 0b45289e57b9 -r f7b6d7cd9820 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_device.c	Mon Jan 16 16:39:49 2012 +0100
@@ -414,6 +414,28 @@ start:
     return rc;
 }
 
+int libxl__device_cleanup(libxl__gc *gc, libxl__device *dev) {
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *path = libxl__device_backend_path(gc, dev);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
+
 /*
  * Handler function for device destruction to be passed to
  * libxl__wait_for_device_state
@@ -421,14 +443,26 @@ start:
 static int destroy_device(libxl__gc *gc, char **l1, char *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__device dev;
+    int rc = -1;
 
     xs_unwatch(ctx->xsh, l1[0], l1[1]);
-    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+
+    rc = libxl__parse_backend_path(gc, l1[0], &dev);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to generate device from backend path %s",
+                   l1[0]);
+        goto out;
+    }
+
+    libxl__device_cleanup(gc, &dev);
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                "Destroyed device backend at %s",
                l1[XS_WATCH_TOKEN]);
-
-    return 0;
+    rc = 0;
+out:
+    return rc;
 }
 
 /*
@@ -454,7 +488,7 @@ retry_transaction:
     if (atoi(state) != 4) {
         xs_transaction_end(ctx->xsh, t, 0);
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
+        libxl__device_cleanup(gc, dev);
         goto out;
     }
 
@@ -495,7 +529,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);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
+    libxl__device_cleanup(gc, dev);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
diff -r 0b45289e57b9 -r f7b6d7cd9820 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Mon Jan 16 16:39:49 2012 +0100
@@ -306,6 +306,11 @@ _hidden int libxl__wait_for_device_state
                                          libxl__device_state_handler handler);
 
 /*
+ * libxl__device_cleanup - clean xenstore entries recursively for a given device
+ */
+_hidden int libxl__device_cleanup(libxl__gc *gc, libxl__device *dev);
+
+/*
  * 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScA-0004ef-89; Wed, 18 Jan 2012 10:19:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RnSc8-0004dy-Ce
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!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 30401 invoked from network); 18 Jan 2012 10:18:49 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:18:49 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=pHYBWTP7ZDoHSr0uUxniGlHSieJ3DbOJf5ICF7r5+oQ=;
	b=wT1vGndwUBocnIfWxnmczy7qYcEPXCYuNlkkLK1PWHIdvjYvZ5mMZ0YuhhqeHJGVa9
	0v4ihhBSFDgMbHhpHuBk+U2/C83CI7BZ9b9ln7OmVc0FFa1gi/oAuGwtJ7FsOxhc8qY1
	P7kmWkMYGVQfYlRRncgO+7HAna6fMiTzVLUrI=
Received: by 10.180.99.199 with SMTP id es7mr25838837wib.10.1326881971266;
	Wed, 18 Jan 2012 02:19:31 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:30 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f7b6d7cd98202be1ca642949c4722c5e6da75540
Message-Id: <f7b6d7cd98202be1ca64.1326880691@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:11 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 13 RFC] libxl: perform xenstore device
	cleanup from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728389 -3600
# Node ID f7b6d7cd98202be1ca642949c4722c5e6da75540
# Parent  0b45289e57b9fbeee3780f24a6398f7911a3320c
libxl: perform xenstore device cleanup from libxl

Perform cleanup of xenstore device entries in libxl, instead of
relying on xen-hotplug-cleanup script.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 0b45289e57b9 -r f7b6d7cd9820 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_device.c	Mon Jan 16 16:39:49 2012 +0100
@@ -414,6 +414,28 @@ start:
     return rc;
 }
 
+int libxl__device_cleanup(libxl__gc *gc, libxl__device *dev) {
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *path = libxl__device_backend_path(gc, dev);
+    unsigned int nb = 0;
+    char *last;
+
+    if (!path)
+        return 0;
+
+    xs_rm(ctx->xsh, XBT_NULL, path);
+
+    for (last = strrchr(path, '/'); last != NULL; last = strrchr(path, '/')) {
+        *last = '\0';
+        if (!libxl__xs_directory(gc, XBT_NULL, path, &nb))
+            continue;
+        if (nb == 0) {
+            xs_rm(ctx->xsh, XBT_NULL, path);
+        }
+    }
+    return 0;
+}
+
 /*
  * Handler function for device destruction to be passed to
  * libxl__wait_for_device_state
@@ -421,14 +443,26 @@ start:
 static int destroy_device(libxl__gc *gc, char **l1, char *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    libxl__device dev;
+    int rc = -1;
 
     xs_unwatch(ctx->xsh, l1[0], l1[1]);
-    xs_rm(ctx->xsh, XBT_NULL, l1[XS_WATCH_TOKEN]);
+
+    rc = libxl__parse_backend_path(gc, l1[0], &dev);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to generate device from backend path %s",
+                   l1[0]);
+        goto out;
+    }
+
+    libxl__device_cleanup(gc, &dev);
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                "Destroyed device backend at %s",
                l1[XS_WATCH_TOKEN]);
-
-    return 0;
+    rc = 0;
+out:
+    return rc;
 }
 
 /*
@@ -454,7 +488,7 @@ retry_transaction:
     if (atoi(state) != 4) {
         xs_transaction_end(ctx->xsh, t, 0);
         libxl__device_destroy_tapdisk(gc, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, be_path);
+        libxl__device_cleanup(gc, dev);
         goto out;
     }
 
@@ -495,7 +529,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);
 
-    xs_rm(ctx->xsh, XBT_NULL, be_path);
+    libxl__device_cleanup(gc, dev);
     xs_rm(ctx->xsh, XBT_NULL, fe_path);
 
     libxl__device_destroy_tapdisk(gc, be_path);
diff -r 0b45289e57b9 -r f7b6d7cd9820 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Mon Jan 16 16:39:49 2012 +0100
@@ -306,6 +306,11 @@ _hidden int libxl__wait_for_device_state
                                          libxl__device_state_handler handler);
 
 /*
+ * libxl__device_cleanup - clean xenstore entries recursively for a given device
+ */
+_hidden int libxl__device_cleanup(libxl__gc *gc, libxl__device *dev);
+
+/*
  * 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScF-0004gf-FW; Wed, 18 Jan 2012 10:19:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RnScE-0004g4-43
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:38 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!4
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 30799 invoked from network); 18 Jan 2012 10:18:55 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:18:55 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=fl5KCFjTc4YBYG4KJDEJE+2TYTRD77wxTEzccNJeEQU=;
	b=I7hIDb2blvjZ1NNkjwpGtliG7yURg1aJC1KxDsbnibFWDJZ1xowJfOKzNTyn9MNTD8
	Y9H3oJ0HjXQIketYgLSFIiZDc35ewoor3XZL+Rq58DwofX0Z1VVOIrbZVyliclSsyMxg
	pYP5PwA9afOeI5yS2PocEEG2K+Ng47EFIlwqY=
Received: by 10.180.84.163 with SMTP id a3mr43746668wiz.3.1326881977005;
	Wed, 18 Jan 2012 02:19:37 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b5d63cf90d4ef8d222ae282e279b90b7f73f18c3
Message-Id: <b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 13 RFC] libxl: destroy devices before
	device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728472 -3600
# Node ID b5d63cf90d4ef8d222ae282e279b90b7f73f18c3
# Parent  5849bf7c4507edbe900de00332f1218de2d9f45f
libxl: destroy devices before device model

Destroying the device model before unplugging the devices prevented
from doing a clean unplug, since libxl was waiting for dm  devices
to shutdown when the userspace process was already killed.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5849bf7c4507 -r b5d63cf90d4e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 16 16:40:40 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Jan 16 16:41:12 2012 +0100
@@ -802,15 +802,15 @@ int libxl_domain_destroy(libxl_ctx *ctx,
     if (rc < 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
     }
+    if (libxl__devices_destroy(gc, domid) < 0)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
+                   "libxl__devices_destroy failed for %d", domid);
     if (dm_present) {
         if (libxl__destroy_device_model(gc, domid) < 0)
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
-                   "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScF-0004gf-FW; Wed, 18 Jan 2012 10:19:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RnScE-0004g4-43
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:38 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!4
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 30799 invoked from network); 18 Jan 2012 10:18:55 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:18:55 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=fl5KCFjTc4YBYG4KJDEJE+2TYTRD77wxTEzccNJeEQU=;
	b=I7hIDb2blvjZ1NNkjwpGtliG7yURg1aJC1KxDsbnibFWDJZ1xowJfOKzNTyn9MNTD8
	Y9H3oJ0HjXQIketYgLSFIiZDc35ewoor3XZL+Rq58DwofX0Z1VVOIrbZVyliclSsyMxg
	pYP5PwA9afOeI5yS2PocEEG2K+Ng47EFIlwqY=
Received: by 10.180.84.163 with SMTP id a3mr43746668wiz.3.1326881977005;
	Wed, 18 Jan 2012 02:19:37 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:36 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: b5d63cf90d4ef8d222ae282e279b90b7f73f18c3
Message-Id: <b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:14 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 13 RFC] libxl: destroy devices before
	device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728472 -3600
# Node ID b5d63cf90d4ef8d222ae282e279b90b7f73f18c3
# Parent  5849bf7c4507edbe900de00332f1218de2d9f45f
libxl: destroy devices before device model

Destroying the device model before unplugging the devices prevented
from doing a clean unplug, since libxl was waiting for dm  devices
to shutdown when the userspace process was already killed.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 5849bf7c4507 -r b5d63cf90d4e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 16 16:40:40 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Jan 16 16:41:12 2012 +0100
@@ -802,15 +802,15 @@ int libxl_domain_destroy(libxl_ctx *ctx,
     if (rc < 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
     }
+    if (libxl__devices_destroy(gc, domid) < 0)
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
+                   "libxl__devices_destroy failed for %d", domid);
     if (dm_present) {
         if (libxl__destroy_device_model(gc, domid) < 0)
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
 
         libxl__qmp_cleanup(gc, domid);
     }
-    if (libxl__devices_destroy(gc, domid) < 0)
-        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
-                   "libxl__devices_destroy failed for %d", domid);
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
     if (vm_path)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSc4-0004d6-Rr; Wed, 18 Jan 2012 10:19:28 +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 1RnSc2-0004ci-Ms
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!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 31719 invoked from network); 18 Jan 2012 10:19:20 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:20 -0000
Received: by werh12 with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=H1NbrNEKWM54yTDtZdlu8MZ2pCdqZ6vFu24EkXEgcbM=;
	b=oqqICaSqy31+W40ktADJcL9al5UbNavR/sVDmYOdTQs3s0o/KGLp2LHpxi4sgaKmA3
	bCKgVxMWnTkn1rmcL+tjA+U/eGWL1/gWRVU0mrR4UkWsCpRNnUeTF3VdA0wAn0ANx4lm
	5PbPJdWcAZWsm52Ezm1BbIwuRVBQZBf/piWQE=
Received: by 10.216.136.27 with SMTP id v27mr6023743wei.45.1326881959942;
	Wed, 18 Jan 2012 02:19:19 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 25752ced44427caec863c3e64185429c39b28c3a
Message-Id: <25752ced44427caec863.1326880686@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:06 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 13 RFC] hotplug/block: get the type of
 block device from file path (NetBSD)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 25752ced44427caec863c3e64185429c39b28c3a
# Parent  9482810bc60588c7d340009d85a20891253be27d
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 9482810bc605 -r 25752ced4442 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,9 +19,14 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
 xparams=$(xenstore-read "$xpath/params")
 
+if [ -f $xparams ]; then
+	xtype="file"
+else
+	xtype="phy"
+fi
+
 case $xstatus in
 6)
 	# device removed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSc4-0004d6-Rr; Wed, 18 Jan 2012 10:19:28 +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 1RnSc2-0004ci-Ms
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:26 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!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 31719 invoked from network); 18 Jan 2012 10:19:20 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:20 -0000
Received: by werh12 with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=H1NbrNEKWM54yTDtZdlu8MZ2pCdqZ6vFu24EkXEgcbM=;
	b=oqqICaSqy31+W40ktADJcL9al5UbNavR/sVDmYOdTQs3s0o/KGLp2LHpxi4sgaKmA3
	bCKgVxMWnTkn1rmcL+tjA+U/eGWL1/gWRVU0mrR4UkWsCpRNnUeTF3VdA0wAn0ANx4lm
	5PbPJdWcAZWsm52Ezm1BbIwuRVBQZBf/piWQE=
Received: by 10.216.136.27 with SMTP id v27mr6023743wei.45.1326881959942;
	Wed, 18 Jan 2012 02:19:19 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.18
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:18 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 25752ced44427caec863c3e64185429c39b28c3a
Message-Id: <25752ced44427caec863.1326880686@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:06 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 13 RFC] hotplug/block: get the type of
 block device from file path (NetBSD)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 25752ced44427caec863c3e64185429c39b28c3a
# Parent  9482810bc60588c7d340009d85a20891253be27d
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 9482810bc605 -r 25752ced4442 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/block	Fri Sep 30 14:38:55 2011 +0200
@@ -19,9 +19,14 @@ error() {
 
 xpath=$1
 xstatus=$2
-xtype=$(xenstore-read "$xpath/type")
 xparams=$(xenstore-read "$xpath/params")
 
+if [ -f $xparams ]; then
+	xtype="file"
+else
+	xtype="phy"
+fi
+
 case $xstatus in
 6)
 	# device removed

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScG-0004hP-Sp; Wed, 18 Jan 2012 10:19:40 +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 1RnScF-0004em-Um
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!4
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 892 invoked from network); 18 Jan 2012 10:19:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:33 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=07ZkP0GehTLgDNOgIu2Qcwh4JK9DKgTkLUQft095HUc=;
	b=bqTMVDsK+XzJTX0Odf/HJtbgpn+l6OemQkDH2sjOQ7Xwp3ry8u+XmB9eYZuzFg5/Rh
	1xNolM+UURs/jvnBWSDH0X1YK2e4Pn37acQjpXgetqzdJ9YvqInxuokVcb6O2A9kyqIn
	iIu8ySSsYciiVbHLgth3msv1foRNfdh76RBPI=
Received: by 10.216.132.28 with SMTP id n28mr4277308wei.35.1326881973253;
	Wed, 18 Jan 2012 02:19:33 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2a28a1126ab2fd6ab6b5c959daabdc6b3afd1fc6
Message-Id: <2a28a1126ab2fd6ab6b5.1326880692@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 13 RFC] libxl: remove force parameter from
 libxl__device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728426 -3600
# Node ID 2a28a1126ab2fd6ab6b5c959daabdc6b3afd1fc6
# Parent  f7b6d7cd98202be1ca642949c4722c5e6da75540
libxl: remove force parameter from libxl__device_remove

All callers where using the wait parameter from
libxl__device_remove, so it's safe to simplify the logic of the
function and assume that the callers always want libxl__device_remove
to wait for the unplug of the device.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f7b6d7cd9820 -r 2a28a1126ab2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 16 16:39:49 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Jan 16 16:40:26 2012 +0100
@@ -1160,7 +1160,7 @@ int libxl_device_disk_remove(libxl_ctx *
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -1628,7 +1628,7 @@ int libxl_device_nic_remove(libxl_ctx *c
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -1968,7 +1968,7 @@ int libxl_device_vkb_remove(libxl_ctx *c
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -2085,7 +2085,7 @@ int libxl_device_vfb_remove(libxl_ctx *c
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
diff -r f7b6d7cd9820 -r 2a28a1126ab2 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 16 16:39:49 2012 +0100
+++ b/tools/libxl/libxl_device.c	Mon Jan 16 16:40:26 2012 +0100
@@ -469,13 +469,14 @@ out:
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__device_remove(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state;
+    struct timeval tv;
     int rc = 0;
 
 retry_transaction:
@@ -506,18 +507,13 @@ retry_transaction:
     xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+    tv.tv_usec = 0;
+    rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                      destroy_device);
+    if (rc < 0) /* an error or timeout occurred, clear watches */
+        xs_unwatch(ctx->xsh, state_path, be_path);
+    xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
 
 out:
     return rc;
diff -r f7b6d7cd9820 -r 2a28a1126ab2 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 16 16:39:49 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Mon Jan 16 16:40:26 2012 +0100
@@ -275,7 +275,7 @@ _hidden char *libxl__device_backend_path
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
+_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScG-0004hP-Sp; Wed, 18 Jan 2012 10:19:40 +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 1RnScF-0004em-Um
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!4
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 892 invoked from network); 18 Jan 2012 10:19:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:33 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=07ZkP0GehTLgDNOgIu2Qcwh4JK9DKgTkLUQft095HUc=;
	b=bqTMVDsK+XzJTX0Odf/HJtbgpn+l6OemQkDH2sjOQ7Xwp3ry8u+XmB9eYZuzFg5/Rh
	1xNolM+UURs/jvnBWSDH0X1YK2e4Pn37acQjpXgetqzdJ9YvqInxuokVcb6O2A9kyqIn
	iIu8ySSsYciiVbHLgth3msv1foRNfdh76RBPI=
Received: by 10.216.132.28 with SMTP id n28mr4277308wei.35.1326881973253;
	Wed, 18 Jan 2012 02:19:33 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.31
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:32 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2a28a1126ab2fd6ab6b5c959daabdc6b3afd1fc6
Message-Id: <2a28a1126ab2fd6ab6b5.1326880692@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:12 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 13 RFC] libxl: remove force parameter from
 libxl__device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728426 -3600
# Node ID 2a28a1126ab2fd6ab6b5c959daabdc6b3afd1fc6
# Parent  f7b6d7cd98202be1ca642949c4722c5e6da75540
libxl: remove force parameter from libxl__device_remove

All callers where using the wait parameter from
libxl__device_remove, so it's safe to simplify the logic of the
function and assume that the callers always want libxl__device_remove
to wait for the unplug of the device.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f7b6d7cd9820 -r 2a28a1126ab2 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 16 16:39:49 2012 +0100
+++ b/tools/libxl/libxl.c	Mon Jan 16 16:40:26 2012 +0100
@@ -1160,7 +1160,7 @@ int libxl_device_disk_remove(libxl_ctx *
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -1628,7 +1628,7 @@ int libxl_device_nic_remove(libxl_ctx *c
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -1968,7 +1968,7 @@ int libxl_device_vkb_remove(libxl_ctx *c
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
@@ -2085,7 +2085,7 @@ int libxl_device_vfb_remove(libxl_ctx *c
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__device_remove(gc, &device);
 out:
     GC_FREE;
     return rc;
diff -r f7b6d7cd9820 -r 2a28a1126ab2 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 16 16:39:49 2012 +0100
+++ b/tools/libxl/libxl_device.c	Mon Jan 16 16:40:26 2012 +0100
@@ -469,13 +469,14 @@ out:
  * Returns 0 (device already destroyed) or 1 (caller must
  * wait_for_dev_destroy) on success, ERROR_* on fail.
  */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__device_remove(libxl__gc *gc, libxl__device *dev)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state;
+    struct timeval tv;
     int rc = 0;
 
 retry_transaction:
@@ -506,18 +507,13 @@ retry_transaction:
     xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+    tv.tv_usec = 0;
+    rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
+                                      destroy_device);
+    if (rc < 0) /* an error or timeout occurred, clear watches */
+        xs_unwatch(ctx->xsh, state_path, be_path);
+    xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
 
 out:
     return rc;
diff -r f7b6d7cd9820 -r 2a28a1126ab2 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 16 16:39:49 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Mon Jan 16 16:40:26 2012 +0100
@@ -275,7 +275,7 @@ _hidden char *libxl__device_backend_path
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
+_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScJ-0004jM-RZ; Wed, 18 Jan 2012 10:19:43 +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 1RnScH-0004fV-Jz
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:41 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!5
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1107 invoked from network); 18 Jan 2012 10:19:35 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:35 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=23uvyL/w5ftVvErXSmbkvbMUsHMpbo41vZRV0Kl1qto=;
	b=V3wAIqjymQvT0GzqZ/OR428CQMP6Wgy8Yd0lzdJ22tfq5BdXk6BMcAI6t9Z5Jorua8
	oFmtTtcD91Su1tei8AG2t6shQ7Q2kFHgk/7odoF495z/jFuGrTTL4x0N6bSeQPfFW8TQ
	cCueKnJKMg6IMV0fgWc1SQt0XYMvVn4ahqqFA=
Received: by 10.216.25.10 with SMTP id y10mr2830926wey.55.1326881975120;
	Wed, 18 Jan 2012 02:19:35 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:34 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5849bf7c4507edbe900de00332f1218de2d9f45f
Message-Id: <5849bf7c4507edbe900d.1326880693@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 13 RFC] libxl: add better error checking
 on libxl__device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728440 -3600
# Node ID 5849bf7c4507edbe900de00332f1218de2d9f45f
# Parent  2a28a1126ab2fd6ab6b5c959daabdc6b3afd1fc6
libxl: add better error checking on libxl__device_remove

Check return value of libxl__wait_for_device_state on
libxl__device_remove and print an error message accordingly.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 2a28a1126ab2 -r 5849bf7c4507 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 16 16:40:26 2012 +0100
+++ b/tools/libxl/libxl_device.c	Mon Jan 16 16:40:40 2012 +0100
@@ -511,8 +511,17 @@ retry_transaction:
     tv.tv_usec = 0;
     rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
                                       destroy_device);
-    if (rc < 0) /* an error or timeout occurred, clear watches */
+    if (rc == ERROR_TIMEDOUT) {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Timeout while waiting for unplug of "
+                   "device with backend path %s", be_path);
         xs_unwatch(ctx->xsh, state_path, be_path);
+    } else if (rc == ERROR_FAIL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to destroy device with "
+                   "backend path %s", be_path);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+    }
     xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
 
 out:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScJ-0004jM-RZ; Wed, 18 Jan 2012 10:19:43 +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 1RnScH-0004fV-Jz
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:41 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!5
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1107 invoked from network); 18 Jan 2012 10:19:35 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:35 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:in-reply-to:references:user-agent:date
	:from:to; bh=23uvyL/w5ftVvErXSmbkvbMUsHMpbo41vZRV0Kl1qto=;
	b=V3wAIqjymQvT0GzqZ/OR428CQMP6Wgy8Yd0lzdJ22tfq5BdXk6BMcAI6t9Z5Jorua8
	oFmtTtcD91Su1tei8AG2t6shQ7Q2kFHgk/7odoF495z/jFuGrTTL4x0N6bSeQPfFW8TQ
	cCueKnJKMg6IMV0fgWc1SQt0XYMvVn4ahqqFA=
Received: by 10.216.25.10 with SMTP id y10mr2830926wey.55.1326881975120;
	Wed, 18 Jan 2012 02:19:35 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.33
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:34 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 5849bf7c4507edbe900de00332f1218de2d9f45f
Message-Id: <5849bf7c4507edbe900d.1326880693@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:13 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 13 RFC] libxl: add better error checking
 on libxl__device_remove
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728440 -3600
# Node ID 5849bf7c4507edbe900de00332f1218de2d9f45f
# Parent  2a28a1126ab2fd6ab6b5c959daabdc6b3afd1fc6
libxl: add better error checking on libxl__device_remove

Check return value of libxl__wait_for_device_state on
libxl__device_remove and print an error message accordingly.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 2a28a1126ab2 -r 5849bf7c4507 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 16 16:40:26 2012 +0100
+++ b/tools/libxl/libxl_device.c	Mon Jan 16 16:40:40 2012 +0100
@@ -511,8 +511,17 @@ retry_transaction:
     tv.tv_usec = 0;
     rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
                                       destroy_device);
-    if (rc < 0) /* an error or timeout occurred, clear watches */
+    if (rc == ERROR_TIMEDOUT) {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Timeout while waiting for unplug of "
+                   "device with backend path %s", be_path);
         xs_unwatch(ctx->xsh, state_path, be_path);
+    } else if (rc == ERROR_FAIL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to destroy device with "
+                   "backend path %s", be_path);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+    }
     xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
 
 out:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScC-0004fN-2M; Wed, 18 Jan 2012 10:19: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 1RnScA-0004dI-LF
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!3
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32758 invoked from network); 18 Jan 2012 10:19:28 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:28 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=p8UIplGegThXI+kTMHbGTCOpqWIjRHDtlRuq/jWgsDM=;
	b=oOkXg3PkgZ1FqxkCT++bZmENv+Qxf4ol656Cffmm173Um5cILA3dvpmDlVzGYlZbgK
	20hUL8tzgX2XTWg0yRXms4LnXLvt2o1sLuGyzbR7WM5rbzhVlsMzp7CVrniq4CcSw/8c
	7wKsyaHAxlXa+6WqjSkefDNxLFgzbJNEaF2AI=
Received: by 10.216.139.150 with SMTP id c22mr2624756wej.25.1326881968179;
	Wed, 18 Jan 2012 02:19:28 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0b45289e57b9fbeee3780f24a6398f7911a3320c
Message-Id: <0b45289e57b9fbeee378.1326880690@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:10 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 13 RFC] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 0b45289e57b9fbeee3780f24a6398f7911a3320c
# Parent  4ae3d8e89ed8b491d342ebb8877386f9b72e1c06
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 4ae3d8e89ed8 -r 0b45289e57b9 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
@@ -18,7 +18,7 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xparams=$(xenstore-read "$xpath/params")
 
 if [ -f $xparams ]; then
@@ -27,8 +27,8 @@ else
 	xtype="phy"
 fi
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -46,7 +46,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r 4ae3d8e89ed8 -r 0b45289e57b9 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Sat Jan 14 19:04:48 2012 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 4ae3d8e89ed8 -r 0b45289e57b9 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Sat Jan 14 19:04:48 2012 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 4ae3d8e89ed8 -r 0b45289e57b9 tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Sat Jan 14 19:04:48 2012 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -149,6 +152,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *p;
 	char buf[80];
@@ -297,11 +301,13 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action);
 			break;
 
 		default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScC-0004fN-2M; Wed, 18 Jan 2012 10:19: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 1RnScA-0004dI-LF
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:34 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!3
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32758 invoked from network); 18 Jan 2012 10:19:28 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:28 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=p8UIplGegThXI+kTMHbGTCOpqWIjRHDtlRuq/jWgsDM=;
	b=oOkXg3PkgZ1FqxkCT++bZmENv+Qxf4ol656Cffmm173Um5cILA3dvpmDlVzGYlZbgK
	20hUL8tzgX2XTWg0yRXms4LnXLvt2o1sLuGyzbR7WM5rbzhVlsMzp7CVrniq4CcSw/8c
	7wKsyaHAxlXa+6WqjSkefDNxLFgzbJNEaF2AI=
Received: by 10.216.139.150 with SMTP id c22mr2624756wej.25.1326881968179;
	Wed, 18 Jan 2012 02:19:28 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.26
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:27 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 0b45289e57b9fbeee3780f24a6398f7911a3320c
Message-Id: <0b45289e57b9fbeee378.1326880690@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:10 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 13 RFC] hotplug NetBSD: pass an action
 instead of a state to hotplug scripts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 0b45289e57b9fbeee3780f24a6398f7911a3320c
# Parent  4ae3d8e89ed8b491d342ebb8877386f9b72e1c06
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 4ae3d8e89ed8 -r 0b45289e57b9 tools/hotplug/NetBSD/block
--- a/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/block	Sat Jan 14 19:04:48 2012 +0100
@@ -18,7 +18,7 @@ error() {
 	
 
 xpath=$1
-xstatus=$2
+xaction=$2
 xparams=$(xenstore-read "$xpath/params")
 
 if [ -f $xparams ]; then
@@ -27,8 +27,8 @@ else
 	xtype="phy"
 fi
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	case $xtype in
 	file)
@@ -46,7 +46,7 @@ 6)
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	case $xtype in
 	file)
 		# Store the list of available vnd(4) devices in
diff -r 4ae3d8e89ed8 -r 0b45289e57b9 tools/hotplug/NetBSD/vif-bridge
--- a/tools/hotplug/NetBSD/vif-bridge	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/vif-bridge	Sat Jan 14 19:04:48 2012 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xbridge=$(xenstore-read "$xpath/bridge")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 4ae3d8e89ed8 -r 0b45289e57b9 tools/hotplug/NetBSD/vif-ip
--- a/tools/hotplug/NetBSD/vif-ip	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/hotplug/NetBSD/vif-ip	Sat Jan 14 19:04:48 2012 +0100
@@ -11,15 +11,15 @@ PATH=${BINDIR}:${SBINDIR}:${LIBEXEC}:${P
 export PATH
 
 xpath=$1
-xstatus=$2
+xaction=$2
 
-case $xstatus in
-6)
+case $xaction in
+2)
 	# device removed
 	xenstore-rm $xpath
 	exit 0
 	;;
-2)
+1)
 	xip=$(xenstore-read "$xpath/ip")
 	xfid=$(xenstore-read "$xpath/frontend-id")
 	xhandle=$(xenstore-read "$xpath/handle")
diff -r 4ae3d8e89ed8 -r 0b45289e57b9 tools/xenbackendd/xenbackendd.c
--- a/tools/xenbackendd/xenbackendd.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/xenbackendd/xenbackendd.c	Sat Jan 14 19:04:48 2012 +0100
@@ -34,6 +34,9 @@
 #define DEVTYPE_VIF 1
 #define DEVTYPE_VBD 2
 
+#define CONNECT "1"
+#define DISCONNECT "2"
+
 #define DOMAIN_PATH "/local/domain/0"
 
 #ifndef XEN_SCRIPT_DIR
@@ -149,6 +152,7 @@ main(int argc, char * const argv[])
 	unsigned int num;
 	char *s;
 	int state;
+	char *action;
 	char *sstate;
 	char *p;
 	char buf[80];
@@ -297,11 +301,13 @@ main(int argc, char * const argv[])
 				    strerror(errno));
 				goto next2;
 			}
-			doexec(s, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(s, vec[XS_WATCH_PATH], action);
 			break;
 
 		case DEVTYPE_VBD:
-			doexec(vbd_script, vec[XS_WATCH_PATH], sstate);
+			action = (state == 6 ? DISCONNECT : CONNECT);
+			doexec(vbd_script, vec[XS_WATCH_PATH], action);
 			break;
 
 		default:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSc7-0004ds-R8; Wed, 18 Jan 2012 10:19:31 +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 1RnSc6-0004co-Ci
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!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 29882 invoked from network); 18 Jan 2012 10:18:42 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:18:42 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19:24 -0800 (PST)
DKIM-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=emdU1G07VaEztKDzyQiSXGRCsrFqPe2sgh7v2M0QyqA=;
	b=XnayZbWJtraA6O2G6iQwolV1fpK62ebvTgXftpmY4GTNpLTyn5C6Mo109Ugkfiq2xh
	lLjsT/w3sQ80KIgcGHCT46tQylt+QCsianMpe909x+zWQbmlph+H+O4h9e8b3XL+Cl0l
	boTkcPI3wocyo1/0Gp6kJlrDMH22C4/8TLX7M=
Received: by 10.180.81.66 with SMTP id y2mr16827898wix.20.1326881964010;
	Wed, 18 Jan 2012 02:19:24 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 74c7175a9bcfb48e4db3ad9e92bdb5eaf4f05c31
Message-Id: <74c7175a9bcfb48e4db3.1326880688@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 13 RFC] libxl: add libxl__forkexec
	function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 74c7175a9bcfb48e4db3ad9e92bdb5eaf4f05c31
# Parent  b9a79fd1b93d44cf7b9ccf288c9f5df169adeb4d
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 b9a79fd1b93d -r 74c7175a9bcf tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Mon Dec 26 22:25:02 2011 +0100
+++ b/tools/libxl/libxl_exec.c	Sat Jan 14 19:04:48 2012 +0100
@@ -454,6 +454,42 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, const char *arg0, char **args,
+                    char **env, const char *what)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, arg0, args, env);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                                 "waitpid failed for %s\n",
+                                 what);
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          what, pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r b9a79fd1b93d -r 74c7175a9bcf tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Dec 26 22:25:02 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
@@ -453,6 +453,21 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args, char **env); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * argv0: file name associated with the file being executed.
+ * args: list of arguments. See execvp(3) man page for more info.
+ * env: environment variables. See execvp(3) man page for more info.
+ *
+ * Returns -1 if the execution fails or the exit status, as reported
+ * by waitpid, on success.
+ *
+ * Logs errors.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, const char *arg0, char **args,
+                            char **env, const char *what);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScA-0004ep-Kg; Wed, 18 Jan 2012 10:19:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RnSc8-0004d0-N7
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!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 32600 invoked from network); 18 Jan 2012 10:19:26 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:26 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=ZcErps8UehIDAnyR2rTCvoxw2aWTmd7fxETUbh6LfuA=;
	b=jkTDHfzquQzp5JlI2cgWKNEPtURcERj1vYWJdTsmL/zE7BLx8ywFTJBSAFL0FkQPRU
	VXHAEPjfS1vGK+BlMPfqEU0FgFY0EkCqX7Z8n9kvxBD+kNfl7bVscTQ5uMlMfOwMXSvs
	UCGVZbAciR8xdYDqwPP4sip+V/pYrwO7tt9Jc=
Received: by 10.216.135.138 with SMTP id u10mr689910wei.43.1326881966249;
	Wed, 18 Jan 2012 02:19:26 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4ae3d8e89ed8b491d342ebb8877386f9b72e1c06
Message-Id: <4ae3d8e89ed8b491d342.1326880689@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:09 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 13 RFC] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 4ae3d8e89ed8b491d342ebb8877386f9b72e1c06
# Parent  74c7175a9bcfb48e4db3ad9e92bdb5eaf4f05c31
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices (with backend PHY or TAP) to initialize
(switch to state 2). This is necessary because we need to call the
hotplug scripts when state is 2, otherwise the execution fails. Make
use of the newly introduced function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 74c7175a9bcf -r 4ae3d8e89ed8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
@@ -1013,6 +1013,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;
 
@@ -1117,6 +1119,27 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
+        disk->backend == LIBXL_DISK_BACKEND_TAP) {
+        be_path = libxl__device_backend_path(gc, &device);
+        state_path = libxl__sprintf(gc, "%s/state", be_path);
+        state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+        if (atoi(state) != XenbusStateInitWait) {
+            xs_watch(ctx->xsh, state_path, be_path);
+            tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+            tv.tv_usec = 0;
+            rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait,
+                                              NULL);
+            xs_unwatch(ctx->xsh, state_path, be_path);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unable to initialize disk device: %s",
+                           disk->pdev_path);
+                goto out_free;
+            }
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1492,6 +1515,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);
@@ -1566,8 +1591,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", be_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScA-0004ep-Kg; Wed, 18 Jan 2012 10:19:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RnSc8-0004d0-N7
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:32 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!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 32600 invoked from network); 18 Jan 2012 10:19:26 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:26 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=ZcErps8UehIDAnyR2rTCvoxw2aWTmd7fxETUbh6LfuA=;
	b=jkTDHfzquQzp5JlI2cgWKNEPtURcERj1vYWJdTsmL/zE7BLx8ywFTJBSAFL0FkQPRU
	VXHAEPjfS1vGK+BlMPfqEU0FgFY0EkCqX7Z8n9kvxBD+kNfl7bVscTQ5uMlMfOwMXSvs
	UCGVZbAciR8xdYDqwPP4sip+V/pYrwO7tt9Jc=
Received: by 10.216.135.138 with SMTP id u10mr689910wei.43.1326881966249;
	Wed, 18 Jan 2012 02:19:26 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.24
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:24 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4ae3d8e89ed8b491d342ebb8877386f9b72e1c06
Message-Id: <4ae3d8e89ed8b491d342.1326880689@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:09 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 13 RFC] libxl: wait for devices to
 initialize upon addition to the domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 4ae3d8e89ed8b491d342ebb8877386f9b72e1c06
# Parent  74c7175a9bcfb48e4db3ad9e92bdb5eaf4f05c31
libxl: wait for devices to initialize upon addition to the domain.

Block waiting for devices (with backend PHY or TAP) to initialize
(switch to state 2). This is necessary because we need to call the
hotplug scripts when state is 2, otherwise the execution fails. Make
use of the newly introduced function libxl__wait_for_device_state.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 74c7175a9bcf -r 4ae3d8e89ed8 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
@@ -1013,6 +1013,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;
 
@@ -1117,6 +1119,27 @@ int libxl_device_disk_add(libxl_ctx *ctx
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
+    if (disk->backend == LIBXL_DISK_BACKEND_PHY ||
+        disk->backend == LIBXL_DISK_BACKEND_TAP) {
+        be_path = libxl__device_backend_path(gc, &device);
+        state_path = libxl__sprintf(gc, "%s/state", be_path);
+        state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+        if (atoi(state) != XenbusStateInitWait) {
+            xs_watch(ctx->xsh, state_path, be_path);
+            tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+            tv.tv_usec = 0;
+            rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait,
+                                              NULL);
+            xs_unwatch(ctx->xsh, state_path, be_path);
+            if (rc < 0) {
+                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                           "unable to initialize disk device: %s",
+                           disk->pdev_path);
+                goto out_free;
+            }
+        }
+    }
     rc = 0;
 
 out_free:
@@ -1492,6 +1515,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);
@@ -1566,8 +1591,25 @@ int libxl_device_nic_add(libxl_ctx *ctx,
                              libxl__xs_kvs_of_flexarray(gc, back, back->count),
                              libxl__xs_kvs_of_flexarray(gc, front, front->count));
 
-    /* FIXME: wait for plug */
+    be_path = libxl__device_backend_path(gc, &device);
+    state_path = libxl__sprintf(gc, "%s/state", be_path);
+    state = libxl__xs_read(gc, XBT_NULL, state_path);
+
+    if (atoi(state) != XenbusStateInitWait) {
+        xs_watch(ctx->xsh, state_path, be_path);
+        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
+        tv.tv_usec = 0;
+        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateInitWait, NULL);
+        xs_unwatch(ctx->xsh, state_path, be_path);
+        if (rc < 0) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "unable to initialize nic device: %s",
+                       nic->ifname);
+            goto out_free;
+        }
+    }
     rc = 0;
+
 out_free:
     flexarray_free(back);
     flexarray_free(front);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSc7-0004ds-R8; Wed, 18 Jan 2012 10:19:31 +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 1RnSc6-0004co-Ci
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:30 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!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 29882 invoked from network); 18 Jan 2012 10:18:42 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:18:42 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19:24 -0800 (PST)
DKIM-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=emdU1G07VaEztKDzyQiSXGRCsrFqPe2sgh7v2M0QyqA=;
	b=XnayZbWJtraA6O2G6iQwolV1fpK62ebvTgXftpmY4GTNpLTyn5C6Mo109Ugkfiq2xh
	lLjsT/w3sQ80KIgcGHCT46tQylt+QCsianMpe909x+zWQbmlph+H+O4h9e8b3XL+Cl0l
	boTkcPI3wocyo1/0Gp6kJlrDMH22C4/8TLX7M=
Received: by 10.180.81.66 with SMTP id y2mr16827898wix.20.1326881964010;
	Wed, 18 Jan 2012 02:19:24 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.21
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:22 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 74c7175a9bcfb48e4db3ad9e92bdb5eaf4f05c31
Message-Id: <74c7175a9bcfb48e4db3.1326880688@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:08 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 13 RFC] libxl: add libxl__forkexec
	function to libxl_exec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326564288 -3600
# Node ID 74c7175a9bcfb48e4db3ad9e92bdb5eaf4f05c31
# Parent  b9a79fd1b93d44cf7b9ccf288c9f5df169adeb4d
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 b9a79fd1b93d -r 74c7175a9bcf tools/libxl/libxl_exec.c
--- a/tools/libxl/libxl_exec.c	Mon Dec 26 22:25:02 2011 +0100
+++ b/tools/libxl/libxl_exec.c	Sat Jan 14 19:04:48 2012 +0100
@@ -454,6 +454,42 @@ int libxl__spawn_check(libxl__gc *gc, li
     return ERROR_FAIL;
 }
 
+int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                    int stderrfd, const char *arg0, char **args,
+                    char **env, const char *what)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int status;
+    int rc = 0;
+    pid_t pid = fork();
+
+    switch (pid) {
+    case -1:
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fork failed\n");
+        rc = -1;
+        break;
+    case 0:
+        libxl__exec(stdinfd, stdoutfd, stderrfd, arg0, args, env);
+        /* libxl__exec never returns */
+    default:
+        while (waitpid(pid, &status, 0) < 0) {
+            if (errno != EINTR) {
+                LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                                 "waitpid failed for %s\n",
+                                 what);
+                rc = -1;
+                break;
+            }
+        }
+        if (status)
+            libxl_report_child_exitstatus(ctx, LIBXL__LOG_ERROR,
+                                          what, pid, status);
+        rc = status;
+        break;
+    }
+    return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r b9a79fd1b93d -r 74c7175a9bcf tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Dec 26 22:25:02 2011 +0100
+++ b/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
@@ -453,6 +453,21 @@ _hidden int libxl__spawn_check(libxl__gc
 _hidden void libxl__exec(int stdinfd, int stdoutfd, int stderrfd,
                const char *arg0, char **args, char **env); // logs errors, never returns
 
+/*
+ * libxl__forkexec - Executes a file synchronously
+ * argv0: file name associated with the file being executed.
+ * args: list of arguments. See execvp(3) man page for more info.
+ * env: environment variables. See execvp(3) man page for more info.
+ *
+ * Returns -1 if the execution fails or the exit status, as reported
+ * by waitpid, on success.
+ *
+ * Logs errors.
+ */
+_hidden int libxl__forkexec(libxl__gc *gc, int stdinfd, int stdoutfd,
+                            int stderrfd, const char *arg0, char **args,
+                            char **env, const char *what);
+
 /* from xl_create */
 _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScS-0004nu-Ki; Wed, 18 Jan 2012 10:19:52 +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 1RnScQ-0004kV-Rw
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326881962!11504875!2
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21192 invoked from network); 18 Jan 2012 10:19:44 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:44 -0000
Received: by mail-wi0-f171.google.com with SMTP id hj8so14586977wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=dVaKjXAQxlBzLoC2vHbwzDtnjevWr/D6Vo4IffXU7+k=;
	b=L+WyLWs0tNFmq+qewtFGk2hgJeleW+pVw8pUdT5pm98ideGLI5Cv4ZWHhojuFGvVZx
	TUcF8w8kbVI02YB4+FTEuF2/AsUGrdvJFBGpm+H/YKlPw66aZ9lc3k8mFM7qhxwlipgd
	gFwn+c1H9j4OlKKkKFWb1/Q2+jABYUcas7qXo=
Received: by 10.181.11.163 with SMTP id ej3mr35559976wid.4.1326881984516;
	Wed, 18 Jan 2012 02:19:44 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d0eb0f3a305fbcdb5fca853e7c674b9b59719e4a
Message-Id: <d0eb0f3a305fbcdb5fca.1326880696@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 13 RFC] libxl: add hotplug script calling
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728652 -3600
# Node ID d0eb0f3a305fbcdb5fca853e7c674b9b59719e4a
# Parent  70359826f535461fedbbd86c18c772117030bc91
libxl: add hotplug script calling for NetBSD

Hotplug scripts in NetBSD are in charge of adding the virtual DomU
network interface to the desired bridge and also mount the vnd device
to use virtual images as block devices. The following scripts are
currently implemented:

 * block: executed when a vbd is used, is in charge mounting the
   virtual image to the vnd device and setting the state of xenstore
   to 4 (connected). When using a physical partition, the script only
   sets the state to 4.

 * vif-bridge: adds the virtual DomU interface to the desired bridge.

 * vif-ip: configures the physical network interface assigned to the
   DomU.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 70359826f535 -r d0eb0f3a305f tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_netbsd.c	Mon Jan 16 16:44:12 2012 +0100
@@ -31,5 +31,50 @@ int libxl__try_phy_backend(mode_t st_mod
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
-    return 0;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    if (dev->backend_kind != LIBXL__DEVICE_KIND_VIF &&
+        dev->backend_kind != LIBXL__DEVICE_KIND_VBD)
+        return 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, NULL, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScS-0004nu-Ki; Wed, 18 Jan 2012 10:19:52 +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 1RnScQ-0004kV-Rw
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326881962!11504875!2
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21192 invoked from network); 18 Jan 2012 10:19:44 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:44 -0000
Received: by mail-wi0-f171.google.com with SMTP id hj8so14586977wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=dVaKjXAQxlBzLoC2vHbwzDtnjevWr/D6Vo4IffXU7+k=;
	b=L+WyLWs0tNFmq+qewtFGk2hgJeleW+pVw8pUdT5pm98ideGLI5Cv4ZWHhojuFGvVZx
	TUcF8w8kbVI02YB4+FTEuF2/AsUGrdvJFBGpm+H/YKlPw66aZ9lc3k8mFM7qhxwlipgd
	gFwn+c1H9j4OlKKkKFWb1/Q2+jABYUcas7qXo=
Received: by 10.181.11.163 with SMTP id ej3mr35559976wid.4.1326881984516;
	Wed, 18 Jan 2012 02:19:44 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.42
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d0eb0f3a305fbcdb5fca853e7c674b9b59719e4a
Message-Id: <d0eb0f3a305fbcdb5fca.1326880696@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:16 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 11 of 13 RFC] libxl: add hotplug script calling
	for NetBSD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326728652 -3600
# Node ID d0eb0f3a305fbcdb5fca853e7c674b9b59719e4a
# Parent  70359826f535461fedbbd86c18c772117030bc91
libxl: add hotplug script calling for NetBSD

Hotplug scripts in NetBSD are in charge of adding the virtual DomU
network interface to the desired bridge and also mount the vnd device
to use virtual images as block devices. The following scripts are
currently implemented:

 * block: executed when a vbd is used, is in charge mounting the
   virtual image to the vnd device and setting the state of xenstore
   to 4 (connected). When using a physical partition, the script only
   sets the state to 4.

 * vif-bridge: adds the virtual DomU interface to the desired bridge.

 * vif-ip: configures the physical network interface assigned to the
   DomU.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 70359826f535 -r d0eb0f3a305f tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Fri Sep 30 14:38:55 2011 +0200
+++ b/tools/libxl/libxl_netbsd.c	Mon Jan 16 16:44:12 2012 +0100
@@ -31,5 +31,50 @@ int libxl__try_phy_backend(mode_t st_mod
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
                           libxl__hotplug_action action)
 {
-    return 0;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    if (dev->backend_kind != LIBXL__DEVICE_KIND_VIF &&
+        dev->backend_kind != LIBXL__DEVICE_KIND_VBD)
+        return 0;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args)
+        return -1;
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, be_path);
+    flexarray_set(f_args, nr++, libxl__sprintf(gc, "%d", action));
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, NULL, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(args);
+    return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScQ-0004mx-89; Wed, 18 Jan 2012 10:19: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 1RnScO-0004j0-Gn
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:48 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!5
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 31255 invoked from network); 18 Jan 2012 10:19:00 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:00 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=0FOW4qTTPRo+Dz94ZH3dPvVEPocWAztlMfHxvdnlgj0=;
	b=T29ych1AYOKSuyb32hgY5DZ9cjOZyARTQneS6F+Ry/48AjaXxo9KyNPJuqb/45ypXT
	79CZ1GCbV+B1+BKe/jp6ZVHAgGQBm3hT2CyHi00zHjPXtgQ2Z63E48MvgAIL1GEpVvTM
	ulTxrnaWzuD++zD5P1r2c84mYZruthhlThmSY=
Received: by 10.180.19.97 with SMTP id d1mr35245211wie.12.1326881982211;
	Wed, 18 Jan 2012 02:19:42 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 70359826f535461fedbbd86c18c772117030bc91
Message-Id: <70359826f535461fedbb.1326880695@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 13 RFC] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 70359826f535461fedbbd86c18c772117030bc91
# Parent  b5d63cf90d4ef8d222ae282e279b90b7f73f18c3
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. This
patch adds the necessary functions to call hotplug scripts, but the
implementation of those functions is left empty and will be filled in
future patches.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r b5d63cf90d4e -r 70359826f535 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 16 16:41:12 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1060,6 +1060,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:
@@ -1072,6 +1077,10 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
 
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
@@ -1140,6 +1149,16 @@ int libxl_device_disk_add(libxl_ctx *ctx
             }
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for disk: %s",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1608,6 +1627,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 b5d63cf90d4e -r 70359826f535 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 16 16:41:12 2012 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -456,10 +456,16 @@ static int destroy_device(libxl__gc *gc,
         goto out;
     }
 
+    rc = libxl__device_hotplug(gc, &dev, DISCONNECT);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to execute hotplug script for "
+                   "device with backend path %s", l1[0]);
+        goto out;
+    }
+
     libxl__device_cleanup(gc, &dev);
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-               "Destroyed device backend at %s",
-               l1[XS_WATCH_TOKEN]);
+
     rc = 0;
 out:
     return rc;
@@ -488,6 +494,12 @@ retry_transaction:
     }
     if (atoi(state) != 4) {
         xs_transaction_end(ctx->xsh, t, 0);
+        rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+        if (rc < 0) {
+             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                        "failed to execute hotplug script for "
+                        "device with backend path %s", be_path);
+        }
         libxl__device_destroy_tapdisk(gc, be_path);
         libxl__device_cleanup(gc, dev);
         goto out;
@@ -533,13 +545,16 @@ 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;
 
+    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    /* Wait for backend status to disconnect */
+    rc = libxl__device_remove(gc, dev);
     libxl__device_cleanup(gc, dev);
-    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)
diff -r b5d63cf90d4e -r 70359826f535 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 16 16:41:12 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -319,6 +319,25 @@ _hidden int libxl__device_cleanup(libxl_
  */
 _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 b5d63cf90d4e -r 70359826f535 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Mon Jan 16 16:41:12 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r b5d63cf90d4e -r 70359826f535 tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Mon Jan 16 16:41:12 2012 +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,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts call function */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScQ-0004mx-89; Wed, 18 Jan 2012 10:19: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 1RnScO-0004j0-Gn
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:48 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326881916!60703572!5
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 31255 invoked from network); 18 Jan 2012 10:19:00 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:00 -0000
Received: by mail-ww0-f43.google.com with SMTP id dr11so3419211wgb.24
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=0FOW4qTTPRo+Dz94ZH3dPvVEPocWAztlMfHxvdnlgj0=;
	b=T29ych1AYOKSuyb32hgY5DZ9cjOZyARTQneS6F+Ry/48AjaXxo9KyNPJuqb/45ypXT
	79CZ1GCbV+B1+BKe/jp6ZVHAgGQBm3hT2CyHi00zHjPXtgQ2Z63E48MvgAIL1GEpVvTM
	ulTxrnaWzuD++zD5P1r2c84mYZruthhlThmSY=
Received: by 10.180.19.97 with SMTP id d1mr35245211wie.12.1326881982211;
	Wed, 18 Jan 2012 02:19:42 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.37
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:38 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 70359826f535461fedbbd86c18c772117030bc91
Message-Id: <70359826f535461fedbb.1326880695@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:15 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 13 RFC] libxl: execute hotplug scripts
 directly from libxl
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 70359826f535461fedbbd86c18c772117030bc91
# Parent  b5d63cf90d4ef8d222ae282e279b90b7f73f18c3
libxl: execute hotplug scripts directly from libxl.

Added the necessary handlers to execute hotplug scripts when necessary
from libxl. Split NetBSD and Linux hotplug calls into two separate
files, because parameters for hotplug scripts are different. This
patch adds the necessary functions to call hotplug scripts, but the
implementation of those functions is left empty and will be filled in
future patches.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r b5d63cf90d4e -r 70359826f535 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 16 16:41:12 2012 +0100
+++ b/tools/libxl/libxl.c	Fri Sep 30 14:38:55 2011 +0200
@@ -1060,6 +1060,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:
@@ -1072,6 +1077,10 @@ int libxl_device_disk_add(libxl_ctx *ctx
             flexarray_append(back, libxl__sprintf(gc, "%s:%s",
                 libxl__device_disk_string_of_format(disk->format),
                 disk->pdev_path));
+            flexarray_append(back, "script");
+            flexarray_append(back, libxl__sprintf(gc, "%s/%s",
+                             libxl_xen_script_dir_path(),
+                             "blktap"));
 
             /* now create a phy device to export the device to the guest */
             goto do_backend_phy;
@@ -1140,6 +1149,16 @@ int libxl_device_disk_add(libxl_ctx *ctx
             }
         }
     }
+
+    /* Call hotplug scripts to attach device */
+    if (libxl__device_hotplug(gc, &device, CONNECT) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to execute hotplug script for disk: %s",
+                   disk->pdev_path);
+        rc = -1;
+        goto out_free;
+    }
+
     rc = 0;
 
 out_free:
@@ -1608,6 +1627,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 b5d63cf90d4e -r 70359826f535 tools/libxl/libxl_device.c
--- a/tools/libxl/libxl_device.c	Mon Jan 16 16:41:12 2012 +0100
+++ b/tools/libxl/libxl_device.c	Fri Sep 30 14:38:55 2011 +0200
@@ -456,10 +456,16 @@ static int destroy_device(libxl__gc *gc,
         goto out;
     }
 
+    rc = libxl__device_hotplug(gc, &dev, DISCONNECT);
+    if (rc < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "failed to execute hotplug script for "
+                   "device with backend path %s", l1[0]);
+        goto out;
+    }
+
     libxl__device_cleanup(gc, &dev);
-    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-               "Destroyed device backend at %s",
-               l1[XS_WATCH_TOKEN]);
+
     rc = 0;
 out:
     return rc;
@@ -488,6 +494,12 @@ retry_transaction:
     }
     if (atoi(state) != 4) {
         xs_transaction_end(ctx->xsh, t, 0);
+        rc = libxl__device_hotplug(gc, dev, DISCONNECT);
+        if (rc < 0) {
+             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                        "failed to execute hotplug script for "
+                        "device with backend path %s", be_path);
+        }
         libxl__device_destroy_tapdisk(gc, be_path);
         libxl__device_cleanup(gc, dev);
         goto out;
@@ -533,13 +545,16 @@ 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;
 
+    xs_rm(ctx->xsh, XBT_NULL, fe_path);
+    /* Wait for backend status to disconnect */
+    rc = libxl__device_remove(gc, dev);
     libxl__device_cleanup(gc, dev);
-    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)
diff -r b5d63cf90d4e -r 70359826f535 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 16 16:41:12 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Fri Sep 30 14:38:55 2011 +0200
@@ -319,6 +319,25 @@ _hidden int libxl__device_cleanup(libxl_
  */
 _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 b5d63cf90d4e -r 70359826f535 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Mon Jan 16 16:41:12 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Fri Sep 30 14:38:55 2011 +0200
@@ -25,3 +25,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 1;
 }
+
+/* Hotplug scripts caller functions */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    return 0;
+}
diff -r b5d63cf90d4e -r 70359826f535 tools/libxl/libxl_netbsd.c
--- a/tools/libxl/libxl_netbsd.c	Mon Jan 16 16:41:12 2012 +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,11 @@ int libxl__try_phy_backend(mode_t st_mod
 
     return 0;
 }
+
+/* Hotplug scripts call function */
+
+int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
+                          libxl__hotplug_action action)
+{
+    return 0;
+}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnScW-0004qP-LY; Wed, 18 Jan 2012 10:19:56 +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 1RnScV-0004mp-9T
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!7
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2299 invoked from network); 18 Jan 2012 10:19:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:48 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19:48 -0800 (PST)
DKIM-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=rtlom+cpCIBOBpkfIt1kEIv6sGiXatmfJu9U7TrUA6k=;
	b=UG8K9oMztzvu8w3fGBRqtRxNA88GtvVm8s3+od3J2aBp95BqMoGG2CKXo4m6INmTDi
	bhQmkwfIpQcncU47icwT9Jzal9g1Sr0NfQElRFTj8DFqcEvpjsuH+Xv78ln+yZNUlWOf
	wDB+ay+dxWKVj7LO1RRMqibBfjPf8gKyfuCaU=
Received: by 10.216.210.38 with SMTP id t38mr7346154weo.26.1326881988615;
	Wed, 18 Jan 2012 02:19:48 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.46
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4416c2b24b9568f860311cbdef44eb5c7f919855
Message-Id: <4416c2b24b9568f86031.1326880698@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 13 RFC] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 4416c2b24b9568f860311cbdef44eb5c7f919855
# Parent  6e076ded8be36a90c6c1e0fb3172bc22011a80b6
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 6e076ded8be3 -r 4416c2b24b95 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 6e076ded8be3 -r 4416c2b24b95 tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Mon Jan 16 16:55:29 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r 6e076ded8be3 -r 4416c2b24b95 tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Mon Jan 16 16:55:29 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnScW-0004qP-LY; Wed, 18 Jan 2012 10:19:56 +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 1RnScV-0004mp-9T
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:55 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!7
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2299 invoked from network); 18 Jan 2012 10:19:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:48 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19:48 -0800 (PST)
DKIM-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=rtlom+cpCIBOBpkfIt1kEIv6sGiXatmfJu9U7TrUA6k=;
	b=UG8K9oMztzvu8w3fGBRqtRxNA88GtvVm8s3+od3J2aBp95BqMoGG2CKXo4m6INmTDi
	bhQmkwfIpQcncU47icwT9Jzal9g1Sr0NfQElRFTj8DFqcEvpjsuH+Xv78ln+yZNUlWOf
	wDB+ay+dxWKVj7LO1RRMqibBfjPf8gKyfuCaU=
Received: by 10.216.210.38 with SMTP id t38mr7346154weo.26.1326881988615;
	Wed, 18 Jan 2012 02:19:48 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.46
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4416c2b24b9568f860311cbdef44eb5c7f919855
Message-Id: <4416c2b24b9568f86031.1326880698@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:18 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 13 of 13 RFC] rc.d NetBSD: don't start
 xenbackendd by default, only when xend needs it
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1317386335 -7200
# Node ID 4416c2b24b9568f860311cbdef44eb5c7f919855
# Parent  6e076ded8be36a90c6c1e0fb3172bc22011a80b6
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 6e076ded8be3 -r 4416c2b24b95 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 6e076ded8be3 -r 4416c2b24b95 tools/hotplug/NetBSD/rc.d/xencommons
--- a/tools/hotplug/NetBSD/rc.d/xencommons	Mon Jan 16 16:55:29 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xencommons	Fri Sep 30 14:38:55 2011 +0200
@@ -22,8 +22,6 @@ required_files="/kern/xen/privcmd"
 
 XENSTORED_PIDFILE="/var/run/xenstored.pid"
 XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
-XENBACKENDD_PIDFILE="/var/run/xenbackendd.pid"
-#XENBACKENDD_DEBUG=1
 #XENCONSOLED_TRACE="/var/log/xen/xenconsole-trace.log"
 #XENSTORED_TRACE="/var/log/xen/xenstore-trace.log"
 
@@ -46,7 +44,7 @@ xen_startcmd()
 			XENSTORED_ROOTDIR="/var/lib/xenstored"
 		fi
 		rm -f ${XENSTORED_ROOTDIR}/tdb* >/dev/null 2>&1
-		printf "Starting xenservices: xenstored, xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenstored, xenconsoled."
 		XENSTORED_ARGS=" --pid-file ${XENSTORED_PIDFILE}"
 		if [ -n "${XENSTORED_TRACE}" ]; then
 			XENSTORED_ARGS="${XENSTORED_ARGS} -T /var/log/xen/xenstored-trace.log"
@@ -58,7 +56,7 @@ xen_startcmd()
 			sleep 1
 		done
 	else
-		printf "Starting xenservices: xenconsoled, xenbackendd."
+		printf "Starting xenservices: xenconsoled."
 	fi
 
 	XENCONSOLED_ARGS=""
@@ -68,13 +66,6 @@ xen_startcmd()
 
 	${SBINDIR}/xenconsoled ${XENCONSOLED_ARGS}
 
-	XENBACKENDD_ARGS=""
-	if [ -n "${XENBACKENDD_DEBUG}" ]; then
-		XENBACKENDD_ARGS="${XENBACKENDD_ARGS} -d"
-	fi
-
-	${SBINDIR}/xenbackendd ${XENBACKENDD_ARGS}
-
 	printf "\n"
 
 	printf "Setting domain 0 name.\n"
@@ -87,8 +78,6 @@ xen_stop()
 	printf "Stopping xencommons.\n"
 	printf "WARNING: Not stopping xenstored, as it cannot be restarted.\n"
 
-	rc_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	pids="$pids $rc_pid"
 	rc_pid=$(check_pidfile ${XENCONSOLED_PIDFILE} ${SBINDIR}/xenconsoled)
 	pids="$pids $rc_pid"
 
@@ -108,17 +97,12 @@ xen_status()
 		pids="$pids $xenconsoled_pid"
 	fi
 
-	xenbackend_pid=$(check_pidfile ${XENBACKENDD_PIDFILE} ${SBINDIR}/xenbackendd)
-	if test -n ${xenbackend_pid}; then
-		pids="$pids $xenbackend_pid"
-	fi
-
-	if test -n "$xenbackend_pid" -a -n "$xenconsoled_pid" -a -n "$xenstored_pid";
+	if test -n "$xenconsoled_pid" -a -n "$xenstored_pid";
 	then
 		echo "xencommons are running as pids $pids."
 		return 0
 	fi
-	if test -z "$xenbackend_pid" -a -z "$xenconsoled_pid" -a -z "$xenstored_pid";
+	if test -z "$xenconsoled_pid" -a -z "$xenstored_pid";
 	then
 		echo "xencommons are not running."
 		return 0
@@ -134,11 +118,6 @@ xen_status()
 	else
 		echo "xenconsoled is not running."
 	fi
-	if test -n $xenbackend_pid; then
-		echo "xenbackendd is running as pid $xenbackend_pid."
-	else
-		echo "xenbackendd is not running."
-	fi
 }
 
 load_rc_config $name
diff -r 6e076ded8be3 -r 4416c2b24b95 tools/hotplug/NetBSD/rc.d/xend
--- a/tools/hotplug/NetBSD/rc.d/xend	Mon Jan 16 16:55:29 2012 +0100
+++ b/tools/hotplug/NetBSD/rc.d/xend	Fri Sep 30 14:38:55 2011 +0200
@@ -1,7 +1,7 @@
 #!/bin/sh
 #
 # PROVIDE: xend
-# REQUIRE: xencommons
+# REQUIRE: xencommons xenbackendd
 
 . /etc/rc.subr
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScV-0004pB-2W; Wed, 18 Jan 2012 10:19: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 1RnScT-0004ls-1O
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!6
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 2178 invoked from network); 18 Jan 2012 10:19:46 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:46 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=a5gsXB8nmhHVumm/KnZ33wmhh8OMuVcJh2IKhX6/wd8=;
	b=tK66k0SmYDjtrUSrgagcx7fJ+JKqxccMDmU0mEVWb9NvhEl6eHpVDOzgml6JnlEKNN
	Ua+omquDoGFNw8+wJK9JALkvhFVw/hOzlDDp5v+cPCUM4oELkzA7hxTBQ4/5C8urf9OQ
	AE4eBbndP3NeTiAkyR0dQWBh/y8CKhxH2RPnQ=
Received: by 10.216.136.132 with SMTP id w4mr8749580wei.53.1326881986481;
	Wed, 18 Jan 2012 02:19:46 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:45 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6e076ded8be36a90c6c1e0fb3172bc22011a80b6
Message-Id: <6e076ded8be36a90c6c1.1326880697@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 13 RFC] libxl: add hotplug script calls
	for Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326729329 -3600
# Node ID 6e076ded8be36a90c6c1e0fb3172bc22011a80b6
# Parent  d0eb0f3a305fbcdb5fca853e7c674b9b59719e4a
libxl: add hotplug script calls for Linux

This patchs adds the necessary logic to call hotplug scripts directly
from libxl. Linux hotplug scritps read most parameters from the caller
environment (since udev set this parameters automatically). In this
implementation we fake udev parameters, so no changes are needed to
the scripts itself.

Currently, the following scripts are called:

 * block: used when disk backend is PHY.

 * blktap: used when disk backend is TAP.

 * vif-*: used when adding a network interface and can be manually set
   by the user.

This patchs disables some udev rules, to prevent udev from trying to
execute hotplug scripts for the devices listed above.

udev rules descrive more device types, currently the following scripts
are NOT executed from libxl because I wasn't able to find any support
for this device types in libxl:

 * vtpm

 * vif2

 * vscsi

 * vif-setup with devices of type tap*

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d0eb0f3a305f -r 6e076ded8be3 tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Mon Jan 16 16:44:12 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Mon Jan 16 16:55:29 2012 +0100
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+# SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+# SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+# SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+# SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+# SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff -r d0eb0f3a305f -r 6e076ded8be3 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Mon Jan 16 16:44:12 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Mon Jan 16 16:55:29 2012 +0100
@@ -26,10 +26,172 @@ int libxl__try_phy_backend(mode_t st_mod
     return 1;
 }
 
+/* Hotplug scripts helpers */
+
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    flexarray_t *f_env;
+    int nr = 0;
+
+    f_env = flexarray_make(11, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,
+                               libxl__sprintf(gc, "%s/%s",
+                                              be_path,
+                                              "script")));
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        flexarray_set(f_env, nr++, "vif");
+        flexarray_set(f_env, nr++,
+                      libxl__sprintf(gc, "%s%u.%d",
+                      libxl__device_kind_to_string(dev->backend_kind),
+                      dev->domid, dev->devid));
+    }
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
 /* Hotplug scripts caller functions */
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "online" : "offline");
+    flexarray_set(f_args, nr++, "type_if=vif");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
-                          libxl__hotplug_action action)
+                         libxl__hotplug_action action)
 {
-    return 0;
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:20:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:20:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnScV-0004pB-2W; Wed, 18 Jan 2012 10:19: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 1RnScT-0004ls-1O
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:19:53 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326881960!9155304!6
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 2178 invoked from network); 18 Jan 2012 10:19:46 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:19:46 -0000
Received: by mail-we0-f171.google.com with SMTP id h12so4140573wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 02:19: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=a5gsXB8nmhHVumm/KnZ33wmhh8OMuVcJh2IKhX6/wd8=;
	b=tK66k0SmYDjtrUSrgagcx7fJ+JKqxccMDmU0mEVWb9NvhEl6eHpVDOzgml6JnlEKNN
	Ua+omquDoGFNw8+wJK9JALkvhFVw/hOzlDDp5v+cPCUM4oELkzA7hxTBQ4/5C8urf9OQ
	AE4eBbndP3NeTiAkyR0dQWBh/y8CKhxH2RPnQ=
Received: by 10.216.136.132 with SMTP id w4mr8749580wei.53.1326881986481;
	Wed, 18 Jan 2012 02:19:46 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id r1sm21626554wia.8.2012.01.18.02.19.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 18 Jan 2012 02:19:45 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 6e076ded8be36a90c6c1e0fb3172bc22011a80b6
Message-Id: <6e076ded8be36a90c6c1.1326880697@loki.upc.es>
In-Reply-To: <patchbomb.1326880685@loki.upc.es>
References: <patchbomb.1326880685@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Wed, 18 Jan 2012 10:58:17 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 12 of 13 RFC] libxl: add hotplug script calls
	for Linux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326729329 -3600
# Node ID 6e076ded8be36a90c6c1e0fb3172bc22011a80b6
# Parent  d0eb0f3a305fbcdb5fca853e7c674b9b59719e4a
libxl: add hotplug script calls for Linux

This patchs adds the necessary logic to call hotplug scripts directly
from libxl. Linux hotplug scritps read most parameters from the caller
environment (since udev set this parameters automatically). In this
implementation we fake udev parameters, so no changes are needed to
the scripts itself.

Currently, the following scripts are called:

 * block: used when disk backend is PHY.

 * blktap: used when disk backend is TAP.

 * vif-*: used when adding a network interface and can be manually set
   by the user.

This patchs disables some udev rules, to prevent udev from trying to
execute hotplug scripts for the devices listed above.

udev rules descrive more device types, currently the following scripts
are NOT executed from libxl because I wasn't able to find any support
for this device types in libxl:

 * vtpm

 * vif2

 * vscsi

 * vif-setup with devices of type tap*

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d0eb0f3a305f -r 6e076ded8be3 tools/hotplug/Linux/xen-backend.rules
--- a/tools/hotplug/Linux/xen-backend.rules	Mon Jan 16 16:44:12 2012 +0100
+++ b/tools/hotplug/Linux/xen-backend.rules	Mon Jan 16 16:55:29 2012 +0100
@@ -1,11 +1,11 @@
-SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
+# SUBSYSTEM=="xen-backend", KERNEL=="tap*", RUN+="/etc/xen/scripts/blktap $env{ACTION}"
+# SUBSYSTEM=="xen-backend", KERNEL=="vbd*", RUN+="/etc/xen/scripts/block $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vtpm*", RUN+="/etc/xen/scripts/vtpm $env{ACTION}"
 SUBSYSTEM=="xen-backend", KERNEL=="vif2-*", RUN+="/etc/xen/scripts/vif2 $env{ACTION}"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
-SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
+# SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="online", RUN+="/etc/xen/scripts/vif-setup online type_if=vif"
+# SUBSYSTEM=="xen-backend", KERNEL=="vif-*", ACTION=="offline", RUN+="/etc/xen/scripts/vif-setup offline type_if=vif"
 SUBSYSTEM=="xen-backend", KERNEL=="vscsi*", RUN+="/etc/xen/scripts/vscsi $env{ACTION}"
-SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
+# SUBSYSTEM=="xen-backend", ACTION=="remove", RUN+="/etc/xen/scripts/xen-hotplug-cleanup"
 KERNEL=="evtchn", NAME="xen/%k"
 SUBSYSTEM=="xen", KERNEL=="blktap[0-9]*", NAME="xen/%k", MODE="0600"
 SUBSYSTEM=="blktap2", KERNEL=="blktap[0-9]*", NAME="xen/blktap-2/%k", MODE="0600"
diff -r d0eb0f3a305f -r 6e076ded8be3 tools/libxl/libxl_linux.c
--- a/tools/libxl/libxl_linux.c	Mon Jan 16 16:44:12 2012 +0100
+++ b/tools/libxl/libxl_linux.c	Mon Jan 16 16:55:29 2012 +0100
@@ -26,10 +26,172 @@ int libxl__try_phy_backend(mode_t st_mod
     return 1;
 }
 
+/* Hotplug scripts helpers */
+
+static char **get_hotplug_env(libxl__gc *gc, libxl__device *dev)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    flexarray_t *f_env;
+    int nr = 0;
+
+    f_env = flexarray_make(11, 1);
+    if (!f_env) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "unable to create environment array");
+        return NULL;
+    }
+
+    flexarray_set(f_env, nr++, "script");
+    flexarray_set(f_env, nr++, libxl__xs_read(gc, XBT_NULL,
+                               libxl__sprintf(gc, "%s/%s",
+                                              be_path,
+                                              "script")));
+    flexarray_set(f_env, nr++, "XENBUS_TYPE");
+    flexarray_set(f_env, nr++, (char *)
+                  libxl__device_kind_to_string(dev->backend_kind));
+    flexarray_set(f_env, nr++, "XENBUS_PATH");
+    flexarray_set(f_env, nr++,
+                  libxl__sprintf(gc, "backend/%s/%u/%d",
+                  libxl__device_kind_to_string(dev->backend_kind),
+                  dev->domid, dev->devid));
+    flexarray_set(f_env, nr++, "XENBUS_BASE_PATH");
+    flexarray_set(f_env, nr++, "backend");
+    if (dev->backend_kind == LIBXL__DEVICE_KIND_VIF) {
+        flexarray_set(f_env, nr++, "vif");
+        flexarray_set(f_env, nr++,
+                      libxl__sprintf(gc, "%s%u.%d",
+                      libxl__device_kind_to_string(dev->backend_kind),
+                      dev->domid, dev->devid));
+    }
+    flexarray_set(f_env, nr++, NULL);
+
+    return (char **) flexarray_contents(f_env);
+}
+
 /* Hotplug scripts caller functions */
 
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(4, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "online" : "offline");
+    flexarray_set(f_args, nr++, "type_if=vif");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s %s",
+               args[0], args[1], args[2]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+                       libxl__hotplug_action action)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    char *be_path = libxl__device_backend_path(gc, dev);
+    char *script, *what;
+    char **args, **env;
+    int status, nr = 0;
+    int rc = -1;
+    flexarray_t *f_args;
+
+    script = libxl__xs_read(gc, XBT_NULL,
+                            libxl__sprintf(gc, "%s/%s", be_path, "script"));
+    if (!script) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to read script from %s",
+                                          be_path);
+        return -1;
+    }
+
+    env = get_hotplug_env(gc, dev);
+    if (!env)
+        return -1;
+
+    f_args = flexarray_make(3, 1);
+    if (!f_args) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "unable to create arguments array");
+        return -1;
+    }
+
+    flexarray_set(f_args, nr++, script);
+    flexarray_set(f_args, nr++, action == CONNECT ? "add" : "remove");
+    flexarray_set(f_args, nr++, NULL);
+
+    args = (char **) flexarray_contents(f_args);
+    what = libxl__sprintf(gc, "%s %s", args[0],
+                          action == CONNECT ? "connect" : "disconnect");
+    LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+               "Calling hotplug script: %s %s",
+               args[0], args[1]);
+    status = libxl__forkexec(gc, -1, -1, -1, args[0], args, env, what);
+    if (status) {
+        rc = -1;
+        goto out;
+    }
+    rc = 0;
+
+out:
+    free(env);
+    free(args);
+    return rc;
+}
+
 int libxl__device_hotplug(libxl__gc *gc, libxl__device *dev,
-                          libxl__hotplug_action action)
+                         libxl__hotplug_action action)
 {
-    return 0;
+    int rc = 0;
+
+    switch (dev->backend_kind) {
+    case LIBXL__DEVICE_KIND_VIF:
+        rc = libxl__hotplug_nic(gc, dev, action);
+        break;
+    case LIBXL__DEVICE_KIND_VBD:
+        rc = libxl__hotplug_disk(gc, dev, action);
+        break;
+    default:
+        rc = 0;
+        break;
+    }
+
+    return rc;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:22:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSeD-0005p4-CA; Wed, 18 Jan 2012 10:21: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 1RnSeB-0005mi-KI
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:21:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326882093!11354101!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28388 invoked from network); 18 Jan 2012 10:21:33 -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;
	18 Jan 2012 10:21:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10110739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:21: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, 18 Jan 2012 10:21:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:21:32 +0000
In-Reply-To: <4F0F1EDA.7040807@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362598.17210.230.camel@zakaz.uk.xensource.com>
	<4F0F1EDA.7040807@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326882092.14689.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 07/18] mini-os: avoid crash if no console is
 provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 17:56 +0000, Daniel De Graaf wrote:
> On 01/12/2012 05:03 AM, Ian Campbell wrote:
> > On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> > 
> > When/why does this happen? 
> 
> Initially, when I use a custom domain builder to create the xenstored
> domain without a xenconsoled running yet (as xenconsoled needs xenstore).

Right, that makes sense.

> > I guess it is because when starting the xenstore domain you cannot use
> > xenstore to communicate with xenconsoled (and/or it isn't even running
> > yet).
> > 
> > I wonder if there is a way we can do lazy-setup of the console for just
> > the xenstore domain?
> 
> Xenstored will produce output on the hypervisor console if Xen is compiled
> with debugging. If xenstored produces a lot of output, it can block on
> waiting for xenconsoled, which might be blocking on xenstored - so I don't
> think we want to hook it up to the console in the normal case, or at least
> not the same xenconsoled that talks to domUs.

Hrm, yes.
 
> > Alternatively I seem to recall a little tool which Diego wrote to pull
> > the console ring out of a domain directly as a debuging aid but that
> > relies on us setting up a console ring and evtchn even if xenconsoled
> > cannot be involved which makes this patch unnecessary.

> This runs into the same blocking problem if xenstored produces too much
> output.

What about if the tools/xenstore/init-xenstore-domain tool you posted in
your v2 provides console_mfn and console_evtch to the stubdom (via the
shared info) and after it has started the domain it would daemonize and
sit there pumping stuff out of the stubdom console ring and
into /var/log or syslog or something. There should be no interaction
with xenstore there, should there?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:22:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:22:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSeD-0005p4-CA; Wed, 18 Jan 2012 10:21: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 1RnSeB-0005mi-KI
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:21:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326882093!11354101!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28388 invoked from network); 18 Jan 2012 10:21:33 -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;
	18 Jan 2012 10:21:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10110739"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:21: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, 18 Jan 2012 10:21:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:21:32 +0000
In-Reply-To: <4F0F1EDA.7040807@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326302490-19428-8-git-send-email-dgdegra@tycho.nsa.gov>
	<1326362598.17210.230.camel@zakaz.uk.xensource.com>
	<4F0F1EDA.7040807@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326882092.14689.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 07/18] mini-os: avoid crash if no console is
 provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 17:56 +0000, Daniel De Graaf wrote:
> On 01/12/2012 05:03 AM, Ian Campbell wrote:
> > On Wed, 2012-01-11 at 17:21 +0000, Daniel De Graaf wrote:
> > 
> > When/why does this happen? 
> 
> Initially, when I use a custom domain builder to create the xenstored
> domain without a xenconsoled running yet (as xenconsoled needs xenstore).

Right, that makes sense.

> > I guess it is because when starting the xenstore domain you cannot use
> > xenstore to communicate with xenconsoled (and/or it isn't even running
> > yet).
> > 
> > I wonder if there is a way we can do lazy-setup of the console for just
> > the xenstore domain?
> 
> Xenstored will produce output on the hypervisor console if Xen is compiled
> with debugging. If xenstored produces a lot of output, it can block on
> waiting for xenconsoled, which might be blocking on xenstored - so I don't
> think we want to hook it up to the console in the normal case, or at least
> not the same xenconsoled that talks to domUs.

Hrm, yes.
 
> > Alternatively I seem to recall a little tool which Diego wrote to pull
> > the console ring out of a domain directly as a debuging aid but that
> > relies on us setting up a console ring and evtchn even if xenconsoled
> > cannot be involved which makes this patch unnecessary.

> This runs into the same blocking problem if xenstored produces too much
> output.

What about if the tools/xenstore/init-xenstore-domain tool you posted in
your v2 provides console_mfn and console_evtch to the stubdom (via the
shared info) and after it has started the domain it would daemonize and
sit there pumping stuff out of the stubdom console ring and
into /var/log or syslog or something. There should be no interaction
with xenstore there, should there?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:24:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSgB-0006QM-Tm; Wed, 18 Jan 2012 10:23: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 1RnSgB-0006OQ-6f
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:23:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326882216!11369102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2143 invoked from network); 18 Jan 2012 10:23:36 -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;
	18 Jan 2012 10:23:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10110796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:23:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 10:23:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:23:36 +0000
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326882216.14689.172.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 00/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Changes from v1:
>  - set_virq_handler implemented in libxc
>  - added custom domain builder for xenstored
>  - xenstore/console domain IDs now pulled from xenstore
>  - migration support when using split xenstored (untested, should work)
>  - slightly less intrusive NO_SOCKETS xenstored patch
>    (still has many ifdefs to avoid pulling in socket headers or symbols)
>  - virq handlers removed from dying domain when clearing event channels
>  - dummy XSM module restricts getdomaininfo similar to no-XSM case
>  - formatting/type fixups
>  - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC
>    (the new device path uses 'B' not 'X' as the base so the ioctl number
>    does not match; otherwise, should be compatible).
> 
> To start xenstored, run:
> 
> tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t
> 
> This will populate the xenstore domid key /tool/xenstore/domid

I'm just about to go through and review this properly but from the above
it's sounding good, thanks!

You have rather undermined my intentions for the next hackathon
though ;-) I was planning to investigate and reinvigorate this stuff, I
guess there is still stub-oxenstored left for me though!

Speaking of which, will you be at the hackathon?
http://lists.xen.org/archives/html/xen-devel/2012-01/msg00268.html

Ian.


> 
> ----
> 
> [PATCH 01/18] xen: reinstate previously unused hypercall
> [PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
> [PATCH 03/18] xen: use XSM instead of IS_PRIV for getdomaininfo
> [PATCH 04/18] xen: Preserve reserved grant entries when switching
> 
> [PATCH 05/18] tools/libxl: pull xenstore/console domids from
> [PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and
> 
> [PATCH 07/18] mini-os: avoid crash if no console is provided
> [PATCH 08/18] mini-os: avoid crash if no xenstore is provided
> [PATCH 09/18] mini-os: remove per-fd evtchn limit
> [PATCH 10/18] xenstored: use grant references instead of
> [PATCH 11/18] xenstored: add NO_SOCKETS compilation option
> [PATCH 12/18] xenstored support for in-memory rather than FS based
> [PATCH 13/18] xenstored: support running in minios stubdom
> [PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
> [PATCH 15/18] xenstored: add --event parameter for bootstrapping
> Removed old #16; shared page is no longer used to pass event.
> [PATCH 16/18] xenstored: use domain_is_unprivileged instead of
> [PATCH 17/18] xenstored: add --priv-domid parameter
> 
> [PATCH 18/18] xenstored: Add stub domain builder
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 18 10:24:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:24:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSgB-0006QM-Tm; Wed, 18 Jan 2012 10:23: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 1RnSgB-0006OQ-6f
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:23:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1326882216!11369102!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2143 invoked from network); 18 Jan 2012 10:23:36 -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;
	18 Jan 2012 10:23:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10110796"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:23:36 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 10:23:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:23:36 +0000
In-Reply-To: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326882216.14689.172.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 00/18] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Changes from v1:
>  - set_virq_handler implemented in libxc
>  - added custom domain builder for xenstored
>  - xenstore/console domain IDs now pulled from xenstore
>  - migration support when using split xenstored (untested, should work)
>  - slightly less intrusive NO_SOCKETS xenstored patch
>    (still has many ifdefs to avoid pulling in socket headers or symbols)
>  - virq handlers removed from dying domain when clearing event channels
>  - dummy XSM module restricts getdomaininfo similar to no-XSM case
>  - formatting/type fixups
>  - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC
>    (the new device path uses 'B' not 'X' as the base so the ioctl number
>    does not match; otherwise, should be compatible).
> 
> To start xenstored, run:
> 
> tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t
> 
> This will populate the xenstore domid key /tool/xenstore/domid

I'm just about to go through and review this properly but from the above
it's sounding good, thanks!

You have rather undermined my intentions for the next hackathon
though ;-) I was planning to investigate and reinvigorate this stuff, I
guess there is still stub-oxenstored left for me though!

Speaking of which, will you be at the hackathon?
http://lists.xen.org/archives/html/xen-devel/2012-01/msg00268.html

Ian.


> 
> ----
> 
> [PATCH 01/18] xen: reinstate previously unused hypercall
> [PATCH 02/18] xen: allow global VIRQ handlers to be delegated to
> [PATCH 03/18] xen: use XSM instead of IS_PRIV for getdomaininfo
> [PATCH 04/18] xen: Preserve reserved grant entries when switching
> 
> [PATCH 05/18] tools/libxl: pull xenstore/console domids from
> [PATCH 06/18] lib{xc,xl}: Seed grant tables with xenstore and
> 
> [PATCH 07/18] mini-os: avoid crash if no console is provided
> [PATCH 08/18] mini-os: avoid crash if no xenstore is provided
> [PATCH 09/18] mini-os: remove per-fd evtchn limit
> [PATCH 10/18] xenstored: use grant references instead of
> [PATCH 11/18] xenstored: add NO_SOCKETS compilation option
> [PATCH 12/18] xenstored support for in-memory rather than FS based
> [PATCH 13/18] xenstored: support running in minios stubdom
> [PATCH 14/18] xenstored: always use xc_gnttab_munmap in stubdom
> [PATCH 15/18] xenstored: add --event parameter for bootstrapping
> Removed old #16; shared page is no longer used to pass event.
> [PATCH 16/18] xenstored: use domain_is_unprivileged instead of
> [PATCH 17/18] xenstored: add --priv-domid parameter
> 
> [PATCH 18/18] xenstored: Add stub domain builder
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 18 10:35:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSp7-0007EP-Lu; Wed, 18 Jan 2012 10:32:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RmpXC-0005lA-0s
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:35:50 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326731742!8709023!1
X-Originating-IP: [32.97.182.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzOSA9PiA1MDczODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21879 invoked from network); 16 Jan 2012 16:35:43 -0000
Received: from e9.ny.us.ibm.com (HELO e9.ny.us.ibm.com) (32.97.182.139)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 16:35:43 -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 <vatsa@linux.vnet.ibm.com>;
	Mon, 16 Jan 2012 11:35:42 -0500
Received: from d01dlp03.pok.ibm.com (9.56.224.17)
	by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 11:35:40 -0500
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235])
	by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 10139C90050
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 11:35:39 -0500 (EST)
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
	q0GGZcXq314898
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 11:35:38 -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
	q0GGYL68012165
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 11:35:38 -0500
Received: from linux.vnet.ibm.com ([9.77.126.209])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0GEBHRc007935; Mon, 16 Jan 2012 09:11:18 -0500
Date: Mon, 16 Jan 2012 19:41:17 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120116141117.GB6019@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F13F883.5090002@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011616-7182-0000-0000-0000008D0B69
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Avi Kivity <avi@redhat.com> [2012-01-16 12:14:27]:

> > One option is to make the kick hypercall available only when
> > yield_on_hlt=1?
> 
> It's not a good idea to tie various options together.  Features should
> be orthogonal.
> 
> Can't we make it work?  Just have different handling for
> KVM_REQ_PVLOCK_KICK (let 's rename it, and the hypercall, PV_UNHALT,
> since we can use it for non-locks too).

The problem case I was thinking of was when guest VCPU would have issued
HLT with interrupts disabled. I guess one option is to inject an NMI,
and have the guest kernel NMI handler recognize this and make
adjustments such that the vcpu avoids going back to HLT instruction.

Having another hypercall to do yield/sleep (rather than effecting that
via HLT) seems like an alternate clean solution here ..

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSp7-0007EP-Lu; Wed, 18 Jan 2012 10:32:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RmpXC-0005lA-0s
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 16:35:50 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326731742!8709023!1
X-Originating-IP: [32.97.182.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjEzOSA9PiA1MDczODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21879 invoked from network); 16 Jan 2012 16:35:43 -0000
Received: from e9.ny.us.ibm.com (HELO e9.ny.us.ibm.com) (32.97.182.139)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 16:35:43 -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 <vatsa@linux.vnet.ibm.com>;
	Mon, 16 Jan 2012 11:35:42 -0500
Received: from d01dlp03.pok.ibm.com (9.56.224.17)
	by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 11:35:40 -0500
Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235])
	by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 10139C90050
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 11:35:39 -0500 (EST)
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
	q0GGZcXq314898
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 11:35:38 -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
	q0GGYL68012165
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 11:35:38 -0500
Received: from linux.vnet.ibm.com ([9.77.126.209])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0GEBHRc007935; Mon, 16 Jan 2012 09:11:18 -0500
Date: Mon, 16 Jan 2012 19:41:17 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Message-ID: <20120116141117.GB6019@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F13F883.5090002@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011616-7182-0000-0000-0000008D0B69
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Avi Kivity <avi@redhat.com> [2012-01-16 12:14:27]:

> > One option is to make the kick hypercall available only when
> > yield_on_hlt=1?
> 
> It's not a good idea to tie various options together.  Features should
> be orthogonal.
> 
> Can't we make it work?  Just have different handling for
> KVM_REQ_PVLOCK_KICK (let 's rename it, and the hypercall, PV_UNHALT,
> since we can use it for non-locks too).

The problem case I was thinking of was when guest VCPU would have issued
HLT with interrupts disabled. I guess one option is to inject an NMI,
and have the guest kernel NMI handler recognize this and make
adjustments such that the vcpu avoids going back to HLT instruction.

Having another hypercall to do yield/sleep (rather than effecting that
via HLT) seems like an alternate clean solution here ..

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp6-0007E4-LD; Wed, 18 Jan 2012 10:32:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmnSq-0003RH-VO
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:23:13 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326723662!48737787!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15692 invoked from network); 16 Jan 2012 14:21:02 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 14:21:02 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 156CE94A8C;
	Mon, 16 Jan 2012 15:23:07 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120116142014.GA10155@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 15:23:02 +0100
Message-Id: <B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:

> * Alexander Graf <agraf@suse.de> [2012-01-16 04:57:45]:
> 
>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
> 
> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for 
> some workload(s)?

Yup

> 
> In some sense, the 1x overcommitcase results posted does measure the overhead
> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
> kernbench ..
> 
>> Result for Non PLE machine :
>> ============================
> 
> [snip]
> 
>> Kernbench:
>>               BASE                    BASE+patch

What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.


Alex

>>               %improvement
>>               mean (sd)               mean (sd)
>> Scenario A:
>> case 1x:	 164.233 (16.5506)	 163.584 (15.4598	0.39517
> 
> [snip]
> 
>> Result for PLE machine:
>> ======================
> 
> [snip]
>> Kernbench:
>>               BASE                    BASE+patch
>>               %improvement
>>               mean (sd)               mean (sd)
>> Scenario A:
>> case 1x:	 161.263 (56.518)        159.635 (40.5621)	1.00953
> 
> - vatsa
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp6-0007E4-LD; Wed, 18 Jan 2012 10:32:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmnSq-0003RH-VO
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:23:13 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326723662!48737787!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15692 invoked from network); 16 Jan 2012 14:21:02 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 14:21:02 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 156CE94A8C;
	Mon, 16 Jan 2012 15:23:07 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <20120116142014.GA10155@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 15:23:02 +0100
Message-Id: <B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:

> * Alexander Graf <agraf@suse.de> [2012-01-16 04:57:45]:
> 
>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
> 
> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for 
> some workload(s)?

Yup

> 
> In some sense, the 1x overcommitcase results posted does measure the overhead
> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
> kernbench ..
> 
>> Result for Non PLE machine :
>> ============================
> 
> [snip]
> 
>> Kernbench:
>>               BASE                    BASE+patch

What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.


Alex

>>               %improvement
>>               mean (sd)               mean (sd)
>> Scenario A:
>> case 1x:	 164.233 (16.5506)	 163.584 (15.4598	0.39517
> 
> [snip]
> 
>> Result for PLE machine:
>> ======================
> 
> [snip]
>> Kernbench:
>>               BASE                    BASE+patch
>>               %improvement
>>               mean (sd)               mean (sd)
>> Scenario A:
>> case 1x:	 161.263 (56.518)        159.635 (40.5621)	1.00953
> 
> - vatsa
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpC-0007Fw-6t; Wed, 18 Jan 2012 10:33:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmsEq-0005NS-GH
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 19:29:04 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326742137!9351841!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1073 invoked from network); 16 Jan 2012 19:28:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 19:28:57 -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 q0GJSlkn028357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 14:28:56 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GIFHWg013754; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 077D540B62; Mon, 16 Jan 2012 19:15:15 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:11 +0100
Message-Id: <1326737715-9867-3-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 2/6] suspend: switch acpi s3 to new
	infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch switches pc s3 suspend over to the new infrastructure.
The cmos_s3 qemu_irq is killed, the new notifier is used instead.
The xen hack goes away with that too, the hypercall can simply be
done in a notifier function now.

This patch also makes the guest actually stay suspended instead
of leaving suspend instantly, so it is useful for more than just
testing whenever the suspend/resume cycle actually works.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/acpi.c        |   11 +----------
 hw/acpi.h        |    2 --
 hw/acpi_piix4.c  |    3 +--
 hw/mc146818rtc.c |   12 ++++++++++++
 hw/mips_malta.c  |    2 +-
 hw/pc.c          |   11 -----------
 hw/pc.h          |    3 +--
 hw/pc_piix.c     |    8 +-------
 hw/vt82c686.c    |    1 -
 xen-all.c        |   11 ++++++-----
 10 files changed, 23 insertions(+), 41 deletions(-)

diff --git a/hw/acpi.c b/hw/acpi.c
index 9c35f2d..de93449 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -327,11 +327,6 @@ void acpi_pm_tmr_reset(ACPIPMTimer *tmr)
 }
 
 /* ACPI PM1aCNT */
-void acpi_pm1_cnt_init(ACPIPM1CNT *pm1_cnt, qemu_irq cmos_s3)
-{
-    pm1_cnt->cmos_s3 = cmos_s3;
-}
-
 void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
 {
     pm1_cnt->cnt = val & ~(ACPI_BITMASK_SLEEP_ENABLE);
@@ -348,8 +343,7 @@ void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
                Pretend that resume was caused by power button */
             pm1a->sts |=
                 (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
-            qemu_system_reset_request();
-            qemu_irq_raise(pm1_cnt->cmos_s3);
+            qemu_system_suspend_request();
         default:
             break;
         }
@@ -370,9 +364,6 @@ void acpi_pm1_cnt_update(ACPIPM1CNT *pm1_cnt,
 void acpi_pm1_cnt_reset(ACPIPM1CNT *pm1_cnt)
 {
     pm1_cnt->cnt = 0;
-    if (pm1_cnt->cmos_s3) {
-        qemu_irq_lower(pm1_cnt->cmos_s3);
-    }
 }
 
 /* ACPI GPE */
diff --git a/hw/acpi.h b/hw/acpi.h
index c141e65..e0c7dbe 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -115,8 +115,6 @@ void acpi_pm1_evt_reset(ACPIPM1EVT *pm1);
 /* PM1a_CNT: piix and ich9 don't implement PM1b CNT. */
 struct ACPIPM1CNT {
     uint16_t cnt;
-
-    qemu_irq cmos_s3;
 };
 typedef struct ACPIPM1CNT ACPIPM1CNT;
 
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index d9075e6..1e575fd 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -373,7 +373,7 @@ static int piix4_pm_initfn(PCIDevice *dev)
 }
 
 i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
-                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+                       qemu_irq sci_irq, qemu_irq smi_irq,
                        int kvm_enabled)
 {
     PCIDevice *dev;
@@ -384,7 +384,6 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
 
     s = DO_UPCAST(PIIX4PMState, dev, dev);
     s->irq = sci_irq;
-    acpi_pm1_cnt_init(&s->pm1_cnt, cmos_s3);
     s->smi_irq = smi_irq;
     s->kvm_enabled = kvm_enabled;
 
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 9cbd052..ae4e16c 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -101,6 +101,7 @@ typedef struct RTCState {
     QEMUTimer *second_timer;
     QEMUTimer *second_timer2;
     Notifier clock_reset_notifier;
+    Notifier suspend_notifier;
 } RTCState;
 
 static void rtc_set_time(RTCState *s);
@@ -590,6 +591,14 @@ static void rtc_notify_clock_reset(Notifier *notifier, void *data)
 #endif
 }
 
+/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
+   BIOS will read it and start S3 resume at POST Entry */
+static void rtc_notify_suspend(Notifier *notifier, void *data)
+{
+    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
+    rtc_set_memory(&s->dev, 0xF, 0xFE);
+}
+
 static void rtc_reset(void *opaque)
 {
     RTCState *s = opaque;
@@ -661,6 +670,9 @@ static int rtc_initfn(ISADevice *dev)
     s->clock_reset_notifier.notify = rtc_notify_clock_reset;
     qemu_register_clock_reset_notifier(rtc_clock, &s->clock_reset_notifier);
 
+    s->suspend_notifier.notify = rtc_notify_suspend;
+    qemu_register_suspend_notifier(&s->suspend_notifier);
+
     s->next_second_time =
         qemu_get_clock_ns(rtc_clock) + (get_ticks_per_sec() * 99) / 100;
     qemu_mod_timer(s->second_timer2, s->next_second_time);
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index e625ec3..b246ebf 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -966,7 +966,7 @@ void mips_malta_init (ram_addr_t ram_size,
     pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
     usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
     smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
-                          isa_get_irq(NULL, 9), NULL, NULL, 0);
+                          isa_get_irq(NULL, 9), NULL, 0);
     /* TODO: Populate SPD eeprom data.  */
     smbus_eeprom_init(smbus, 8, NULL, 0);
     pit = pit_init(isa_bus, 0x40, 0);
diff --git a/hw/pc.c b/hw/pc.c
index 85304cf..4ce046c 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -901,17 +901,6 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
     return dev;
 }
 
-/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
-   BIOS will read it and start S3 resume at POST Entry */
-void pc_cmos_set_s3_resume(void *opaque, int irq, int level)
-{
-    ISADevice *s = opaque;
-
-    if (level) {
-        rtc_set_memory(s, 0xF, 0xFE);
-    }
-}
-
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level)
 {
     CPUState *s = opaque;
diff --git a/hw/pc.h b/hw/pc.h
index 13e41f1..68714c7 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -128,7 +128,6 @@ void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out);
 extern int fd_bootchk;
 
 void pc_register_ferr_irq(qemu_irq irq);
-void pc_cmos_set_s3_resume(void *opaque, int irq, int level);
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
 
 void pc_cpus_init(const char *cpu_model);
@@ -167,7 +166,7 @@ int acpi_table_add(const char *table_desc);
 /* acpi_piix.c */
 
 i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
-                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+                       qemu_irq sci_irq, qemu_irq smi_irq,
                        int kvm_enabled);
 void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index b70431f..9684ed0 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -90,7 +90,6 @@ static void pc_init1(MemoryRegion *system_memory,
     qemu_irq *cpu_irq;
     qemu_irq *gsi;
     qemu_irq *i8259;
-    qemu_irq *cmos_s3;
     qemu_irq *smi_irq;
     GSIState *gsi_state;
     DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
@@ -234,15 +233,10 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled && acpi_enabled) {
         i2c_bus *smbus;
 
-        if (!xen_enabled()) {
-            cmos_s3 = qemu_allocate_irqs(pc_cmos_set_s3_resume, rtc_state, 1);
-        } else {
-            cmos_s3 = qemu_allocate_irqs(xen_cmos_set_s3_resume, rtc_state, 1);
-        }
         smi_irq = qemu_allocate_irqs(pc_acpi_smi_interrupt, first_cpu, 1);
         /* TODO: Populate SPD eeprom data.  */
         smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100,
-                              gsi[9], *cmos_s3, *smi_irq,
+                              gsi[9], *smi_irq,
                               kvm_enabled());
         smbus_eeprom_init(smbus, 8, NULL, 0);
     }
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
index 038128b..9c730d3 100644
--- a/hw/vt82c686.c
+++ b/hw/vt82c686.c
@@ -425,7 +425,6 @@ static int vt82c686b_pm_initfn(PCIDevice *dev)
     apm_init(&s->apm, NULL, s);
 
     acpi_pm_tmr_init(&s->tmr, pm_tmr_timer);
-    acpi_pm1_cnt_init(&s->pm1_cnt, NULL);
 
     pm_smbus_init(&s->dev.qdev, &s->smb);
 
diff --git a/xen-all.c b/xen-all.c
index c86ebf4..4030f3e 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -87,6 +87,7 @@ typedef struct XenIOState {
     const XenPhysmap *log_for_dirtybit;
 
     Notifier exit;
+    Notifier suspend;
 } XenIOState;
 
 /* Xen specific function for piix pci */
@@ -119,12 +120,9 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
-void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
+static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
-    pc_cmos_set_s3_resume(opaque, irq, level);
-    if (level) {
-        xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
-    }
+    xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
 }
 
 /* Xen Interrupt Controller */
@@ -933,6 +931,9 @@ int xen_hvm_init(void)
     state->exit.notify = xen_exit_notifier;
     qemu_add_exit_notifier(&state->exit);
 
+    state->suspend.notify = xen_suspend_notifier;
+    qemu_register_suspend_notifier(&state->suspend);
+
     xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn);
     DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
     state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpC-0007Fw-6t; Wed, 18 Jan 2012 10:33:02 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmsEq-0005NS-GH
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 19:29:04 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326742137!9351841!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1073 invoked from network); 16 Jan 2012 19:28:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 19:28:57 -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 q0GJSlkn028357
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 14:28:56 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GIFHWg013754; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 077D540B62; Mon, 16 Jan 2012 19:15:15 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:11 +0100
Message-Id: <1326737715-9867-3-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 2/6] suspend: switch acpi s3 to new
	infrastructure.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch switches pc s3 suspend over to the new infrastructure.
The cmos_s3 qemu_irq is killed, the new notifier is used instead.
The xen hack goes away with that too, the hypercall can simply be
done in a notifier function now.

This patch also makes the guest actually stay suspended instead
of leaving suspend instantly, so it is useful for more than just
testing whenever the suspend/resume cycle actually works.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/acpi.c        |   11 +----------
 hw/acpi.h        |    2 --
 hw/acpi_piix4.c  |    3 +--
 hw/mc146818rtc.c |   12 ++++++++++++
 hw/mips_malta.c  |    2 +-
 hw/pc.c          |   11 -----------
 hw/pc.h          |    3 +--
 hw/pc_piix.c     |    8 +-------
 hw/vt82c686.c    |    1 -
 xen-all.c        |   11 ++++++-----
 10 files changed, 23 insertions(+), 41 deletions(-)

diff --git a/hw/acpi.c b/hw/acpi.c
index 9c35f2d..de93449 100644
--- a/hw/acpi.c
+++ b/hw/acpi.c
@@ -327,11 +327,6 @@ void acpi_pm_tmr_reset(ACPIPMTimer *tmr)
 }
 
 /* ACPI PM1aCNT */
-void acpi_pm1_cnt_init(ACPIPM1CNT *pm1_cnt, qemu_irq cmos_s3)
-{
-    pm1_cnt->cmos_s3 = cmos_s3;
-}
-
 void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
 {
     pm1_cnt->cnt = val & ~(ACPI_BITMASK_SLEEP_ENABLE);
@@ -348,8 +343,7 @@ void acpi_pm1_cnt_write(ACPIPM1EVT *pm1a, ACPIPM1CNT *pm1_cnt, uint16_t val)
                Pretend that resume was caused by power button */
             pm1a->sts |=
                 (ACPI_BITMASK_WAKE_STATUS | ACPI_BITMASK_POWER_BUTTON_STATUS);
-            qemu_system_reset_request();
-            qemu_irq_raise(pm1_cnt->cmos_s3);
+            qemu_system_suspend_request();
         default:
             break;
         }
@@ -370,9 +364,6 @@ void acpi_pm1_cnt_update(ACPIPM1CNT *pm1_cnt,
 void acpi_pm1_cnt_reset(ACPIPM1CNT *pm1_cnt)
 {
     pm1_cnt->cnt = 0;
-    if (pm1_cnt->cmos_s3) {
-        qemu_irq_lower(pm1_cnt->cmos_s3);
-    }
 }
 
 /* ACPI GPE */
diff --git a/hw/acpi.h b/hw/acpi.h
index c141e65..e0c7dbe 100644
--- a/hw/acpi.h
+++ b/hw/acpi.h
@@ -115,8 +115,6 @@ void acpi_pm1_evt_reset(ACPIPM1EVT *pm1);
 /* PM1a_CNT: piix and ich9 don't implement PM1b CNT. */
 struct ACPIPM1CNT {
     uint16_t cnt;
-
-    qemu_irq cmos_s3;
 };
 typedef struct ACPIPM1CNT ACPIPM1CNT;
 
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index d9075e6..1e575fd 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -373,7 +373,7 @@ static int piix4_pm_initfn(PCIDevice *dev)
 }
 
 i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
-                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+                       qemu_irq sci_irq, qemu_irq smi_irq,
                        int kvm_enabled)
 {
     PCIDevice *dev;
@@ -384,7 +384,6 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
 
     s = DO_UPCAST(PIIX4PMState, dev, dev);
     s->irq = sci_irq;
-    acpi_pm1_cnt_init(&s->pm1_cnt, cmos_s3);
     s->smi_irq = smi_irq;
     s->kvm_enabled = kvm_enabled;
 
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 9cbd052..ae4e16c 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -101,6 +101,7 @@ typedef struct RTCState {
     QEMUTimer *second_timer;
     QEMUTimer *second_timer2;
     Notifier clock_reset_notifier;
+    Notifier suspend_notifier;
 } RTCState;
 
 static void rtc_set_time(RTCState *s);
@@ -590,6 +591,14 @@ static void rtc_notify_clock_reset(Notifier *notifier, void *data)
 #endif
 }
 
+/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
+   BIOS will read it and start S3 resume at POST Entry */
+static void rtc_notify_suspend(Notifier *notifier, void *data)
+{
+    RTCState *s = container_of(notifier, RTCState, suspend_notifier);
+    rtc_set_memory(&s->dev, 0xF, 0xFE);
+}
+
 static void rtc_reset(void *opaque)
 {
     RTCState *s = opaque;
@@ -661,6 +670,9 @@ static int rtc_initfn(ISADevice *dev)
     s->clock_reset_notifier.notify = rtc_notify_clock_reset;
     qemu_register_clock_reset_notifier(rtc_clock, &s->clock_reset_notifier);
 
+    s->suspend_notifier.notify = rtc_notify_suspend;
+    qemu_register_suspend_notifier(&s->suspend_notifier);
+
     s->next_second_time =
         qemu_get_clock_ns(rtc_clock) + (get_ticks_per_sec() * 99) / 100;
     qemu_mod_timer(s->second_timer2, s->next_second_time);
diff --git a/hw/mips_malta.c b/hw/mips_malta.c
index e625ec3..b246ebf 100644
--- a/hw/mips_malta.c
+++ b/hw/mips_malta.c
@@ -966,7 +966,7 @@ void mips_malta_init (ram_addr_t ram_size,
     pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
     usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
     smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
-                          isa_get_irq(NULL, 9), NULL, NULL, 0);
+                          isa_get_irq(NULL, 9), NULL, 0);
     /* TODO: Populate SPD eeprom data.  */
     smbus_eeprom_init(smbus, 8, NULL, 0);
     pit = pit_init(isa_bus, 0x40, 0);
diff --git a/hw/pc.c b/hw/pc.c
index 85304cf..4ce046c 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -901,17 +901,6 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
     return dev;
 }
 
-/* set CMOS shutdown status register (index 0xF) as S3_resume(0xFE)
-   BIOS will read it and start S3 resume at POST Entry */
-void pc_cmos_set_s3_resume(void *opaque, int irq, int level)
-{
-    ISADevice *s = opaque;
-
-    if (level) {
-        rtc_set_memory(s, 0xF, 0xFE);
-    }
-}
-
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level)
 {
     CPUState *s = opaque;
diff --git a/hw/pc.h b/hw/pc.h
index 13e41f1..68714c7 100644
--- a/hw/pc.h
+++ b/hw/pc.h
@@ -128,7 +128,6 @@ void i8042_setup_a20_line(ISADevice *dev, qemu_irq *a20_out);
 extern int fd_bootchk;
 
 void pc_register_ferr_irq(qemu_irq irq);
-void pc_cmos_set_s3_resume(void *opaque, int irq, int level);
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
 
 void pc_cpus_init(const char *cpu_model);
@@ -167,7 +166,7 @@ int acpi_table_add(const char *table_desc);
 /* acpi_piix.c */
 
 i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
-                       qemu_irq sci_irq, qemu_irq cmos_s3, qemu_irq smi_irq,
+                       qemu_irq sci_irq, qemu_irq smi_irq,
                        int kvm_enabled);
 void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
 
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index b70431f..9684ed0 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -90,7 +90,6 @@ static void pc_init1(MemoryRegion *system_memory,
     qemu_irq *cpu_irq;
     qemu_irq *gsi;
     qemu_irq *i8259;
-    qemu_irq *cmos_s3;
     qemu_irq *smi_irq;
     GSIState *gsi_state;
     DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
@@ -234,15 +233,10 @@ static void pc_init1(MemoryRegion *system_memory,
     if (pci_enabled && acpi_enabled) {
         i2c_bus *smbus;
 
-        if (!xen_enabled()) {
-            cmos_s3 = qemu_allocate_irqs(pc_cmos_set_s3_resume, rtc_state, 1);
-        } else {
-            cmos_s3 = qemu_allocate_irqs(xen_cmos_set_s3_resume, rtc_state, 1);
-        }
         smi_irq = qemu_allocate_irqs(pc_acpi_smi_interrupt, first_cpu, 1);
         /* TODO: Populate SPD eeprom data.  */
         smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100,
-                              gsi[9], *cmos_s3, *smi_irq,
+                              gsi[9], *smi_irq,
                               kvm_enabled());
         smbus_eeprom_init(smbus, 8, NULL, 0);
     }
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
index 038128b..9c730d3 100644
--- a/hw/vt82c686.c
+++ b/hw/vt82c686.c
@@ -425,7 +425,6 @@ static int vt82c686b_pm_initfn(PCIDevice *dev)
     apm_init(&s->apm, NULL, s);
 
     acpi_pm_tmr_init(&s->tmr, pm_tmr_timer);
-    acpi_pm1_cnt_init(&s->pm1_cnt, NULL);
 
     pm_smbus_init(&s->dev.qdev, &s->smb);
 
diff --git a/xen-all.c b/xen-all.c
index c86ebf4..4030f3e 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -87,6 +87,7 @@ typedef struct XenIOState {
     const XenPhysmap *log_for_dirtybit;
 
     Notifier exit;
+    Notifier suspend;
 } XenIOState;
 
 /* Xen specific function for piix pci */
@@ -119,12 +120,9 @@ void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
     }
 }
 
-void xen_cmos_set_s3_resume(void *opaque, int irq, int level)
+static void xen_suspend_notifier(Notifier *notifier, void *data)
 {
-    pc_cmos_set_s3_resume(opaque, irq, level);
-    if (level) {
-        xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
-    }
+    xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 3);
 }
 
 /* Xen Interrupt Controller */
@@ -933,6 +931,9 @@ int xen_hvm_init(void)
     state->exit.notify = xen_exit_notifier;
     qemu_add_exit_notifier(&state->exit);
 
+    state->suspend.notify = xen_suspend_notifier;
+    qemu_register_suspend_notifier(&state->suspend);
+
     xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_IOREQ_PFN, &ioreq_pfn);
     DPRINTF("shared page at pfn %lx\n", ioreq_pfn);
     state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSp9-0007Ez-5Z; Wed, 18 Jan 2012 10:32:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmrGu-00048T-Ou
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:27:08 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326738375!52776295!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28225 invoked from network); 16 Jan 2012 18:26:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-27.messagelabs.com with SMTP;
	16 Jan 2012 18:26:16 -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 q0GIR4ls030207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 13:27:06 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0GIFPCo031379; Mon, 16 Jan 2012 13:15:27 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 80E5F40CA8; Mon, 16 Jan 2012 19:15:16 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:15 +0100
Message-Id: <1326737715-9867-7-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 6/6] suspend: make rtc alarm wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a 'wakeup' property to the mc146818rtc.  It is on by default.
When enabled the rtc will wake up the guest when the alarm fires.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/mc146818rtc.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index ae4e16c..039c603 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -86,6 +86,7 @@ typedef struct RTCState {
     uint8_t cmos_index;
     struct tm current_tm;
     int32_t base_year;
+    uint32_t wakeup;
     qemu_irq irq;
     qemu_irq sqw_irq;
     int it_shift;
@@ -431,6 +432,9 @@ static void rtc_update_second2(void *opaque)
             ((s->cmos_data[RTC_HOURS_ALARM] & 0xc0) == 0xc0 ||
              rtc_from_bcd(s, s->cmos_data[RTC_HOURS_ALARM]) == s->current_tm.tm_hour)) {
 
+            if (s->wakeup) {
+                qemu_system_wakeup_request();
+            }
             s->cmos_data[RTC_REG_C] |= 0xa0;
             qemu_irq_raise(s->irq);
         }
@@ -714,6 +718,7 @@ static ISADeviceInfo mc146818rtc_info = {
     .init          = rtc_initfn,
     .qdev.props    = (Property[]) {
         DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
+        DEFINE_PROP_UINT32("wakeup",   RTCState, wakeup,    1),
         DEFINE_PROP_END_OF_LIST(),
     }
 };
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSp9-0007Ez-5Z; Wed, 18 Jan 2012 10:32:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmrGu-00048T-Ou
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:27:08 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326738375!52776295!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28225 invoked from network); 16 Jan 2012 18:26:16 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-27.messagelabs.com with SMTP;
	16 Jan 2012 18:26:16 -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 q0GIR4ls030207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 13:27:06 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0GIFPCo031379; Mon, 16 Jan 2012 13:15:27 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 80E5F40CA8; Mon, 16 Jan 2012 19:15:16 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:15 +0100
Message-Id: <1326737715-9867-7-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 6/6] suspend: make rtc alarm wakeup the guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a 'wakeup' property to the mc146818rtc.  It is on by default.
When enabled the rtc will wake up the guest when the alarm fires.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/mc146818rtc.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index ae4e16c..039c603 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -86,6 +86,7 @@ typedef struct RTCState {
     uint8_t cmos_index;
     struct tm current_tm;
     int32_t base_year;
+    uint32_t wakeup;
     qemu_irq irq;
     qemu_irq sqw_irq;
     int it_shift;
@@ -431,6 +432,9 @@ static void rtc_update_second2(void *opaque)
             ((s->cmos_data[RTC_HOURS_ALARM] & 0xc0) == 0xc0 ||
              rtc_from_bcd(s, s->cmos_data[RTC_HOURS_ALARM]) == s->current_tm.tm_hour)) {
 
+            if (s->wakeup) {
+                qemu_system_wakeup_request();
+            }
             s->cmos_data[RTC_REG_C] |= 0xa0;
             qemu_irq_raise(s->irq);
         }
@@ -714,6 +718,7 @@ static ISADeviceInfo mc146818rtc_info = {
     .init          = rtc_initfn,
     .qdev.props    = (Property[]) {
         DEFINE_PROP_INT32("base_year", RTCState, base_year, 1980),
+        DEFINE_PROP_UINT32("wakeup",   RTCState, wakeup,    1),
         DEFINE_PROP_END_OF_LIST(),
     }
 };
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpF-0007Gp-I9; Wed, 18 Jan 2012 10:33:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1Rn57s-0001XF-RR
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:14:45 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326791677!10653418!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14558 invoked from network); 17 Jan 2012 09:14:38 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	17 Jan 2012 09:14:38 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0H9EHqk028127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 04:14:17 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0H9EExv025394; Tue, 17 Jan 2012 04:14:15 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id D513518D474; Tue, 17 Jan 2012 11:14:13 +0200 (IST)
Date: Tue, 17 Jan 2012 11:14:13 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Message-ID: <20120117091413.GM2167@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120116141117.GB6019@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 16, 2012 at 07:41:17PM +0530, Srivatsa Vaddagiri wrote:
> * Avi Kivity <avi@redhat.com> [2012-01-16 12:14:27]:
> 
> > > One option is to make the kick hypercall available only when
> > > yield_on_hlt=1?
> > 
> > It's not a good idea to tie various options together.  Features should
> > be orthogonal.
> > 
> > Can't we make it work?  Just have different handling for
> > KVM_REQ_PVLOCK_KICK (let 's rename it, and the hypercall, PV_UNHALT,
> > since we can use it for non-locks too).
> 
> The problem case I was thinking of was when guest VCPU would have issued
> HLT with interrupts disabled. I guess one option is to inject an NMI,
> and have the guest kernel NMI handler recognize this and make
> adjustments such that the vcpu avoids going back to HLT instruction.
> 
Just kick vcpu out of a guest mode and adjust rip to point after HLT on
next re-entry. Don't forget to call vmx_clear_hlt().

> Having another hypercall to do yield/sleep (rather than effecting that
> via HLT) seems like an alternate clean solution here ..
> 
> - vatsa

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpF-0007Gp-I9; Wed, 18 Jan 2012 10:33:05 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1Rn57s-0001XF-RR
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 09:14:45 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326791677!10653418!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14558 invoked from network); 17 Jan 2012 09:14:38 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	17 Jan 2012 09:14:38 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0H9EHqk028127
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 04:14:17 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0H9EExv025394; Tue, 17 Jan 2012 04:14:15 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id D513518D474; Tue, 17 Jan 2012 11:14:13 +0200 (IST)
Date: Tue, 17 Jan 2012 11:14:13 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Message-ID: <20120117091413.GM2167@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120116141117.GB6019@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 16, 2012 at 07:41:17PM +0530, Srivatsa Vaddagiri wrote:
> * Avi Kivity <avi@redhat.com> [2012-01-16 12:14:27]:
> 
> > > One option is to make the kick hypercall available only when
> > > yield_on_hlt=1?
> > 
> > It's not a good idea to tie various options together.  Features should
> > be orthogonal.
> > 
> > Can't we make it work?  Just have different handling for
> > KVM_REQ_PVLOCK_KICK (let 's rename it, and the hypercall, PV_UNHALT,
> > since we can use it for non-locks too).
> 
> The problem case I was thinking of was when guest VCPU would have issued
> HLT with interrupts disabled. I guess one option is to inject an NMI,
> and have the guest kernel NMI handler recognize this and make
> adjustments such that the vcpu avoids going back to HLT instruction.
> 
Just kick vcpu out of a guest mode and adjust rip to point after HLT on
next re-entry. Don't forget to call vmx_clear_hlt().

> Having another hypercall to do yield/sleep (rather than effecting that
> via HLT) seems like an alternate clean solution here ..
> 
> - vatsa

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp4-0007DZ-TV; Wed, 18 Jan 2012 10:32:54 +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 1Rmmwt-0002bp-3J
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:50:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326721762!50424847!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24277 invoked from network); 16 Jan 2012 13:49:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	16 Jan 2012 13:49:23 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GDnkql013644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 08:49:46 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GDnbN1006881; Mon, 16 Jan 2012 08:49:38 -0500
Message-ID: <4F142AF1.2020801@redhat.com>
Date: Mon, 16 Jan 2012 15:49:37 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<4F14296B.4070003@linux.vnet.ibm.com>
In-Reply-To: <4F14296B.4070003@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 03:43 PM, Raghavendra K T wrote:
>>> Dbench:
>>> Throughput is in MB/sec
>>> NRCLIENTS     BASE                    BASE+patch           
>>> %improvement
>>>                     mean (sd)               mean (sd)
>>> 8           1.101190  (0.875082)     1.700395  (0.846809)     54.4143
>>> 16          1.524312  (0.120354)     1.477553  (0.058166)     -3.06755
>>> 32            2.143028  (0.157103)     2.090307  (0.136778)    
>>> -2.46012
>>
>> So on a very contended system we're actually slower? Is this expected?
>>
>>
>
>
> I think, the result is interesting because its PLE machine. I have to
> experiment more with parameters, SPIN_THRESHOLD, and also may be
> ple_gap and ple_window.

Perhaps the PLE stuff fights with the PV stuff?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp4-0007DZ-TV; Wed, 18 Jan 2012 10:32:54 +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 1Rmmwt-0002bp-3J
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:50:11 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326721762!50424847!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24277 invoked from network); 16 Jan 2012 13:49:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-27.messagelabs.com with SMTP;
	16 Jan 2012 13:49:23 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GDnkql013644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 08:49:46 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GDnbN1006881; Mon, 16 Jan 2012 08:49:38 -0500
Message-ID: <4F142AF1.2020801@redhat.com>
Date: Mon, 16 Jan 2012 15:49:37 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<4F14296B.4070003@linux.vnet.ibm.com>
In-Reply-To: <4F14296B.4070003@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 03:43 PM, Raghavendra K T wrote:
>>> Dbench:
>>> Throughput is in MB/sec
>>> NRCLIENTS     BASE                    BASE+patch           
>>> %improvement
>>>                     mean (sd)               mean (sd)
>>> 8           1.101190  (0.875082)     1.700395  (0.846809)     54.4143
>>> 16          1.524312  (0.120354)     1.477553  (0.058166)     -3.06755
>>> 32            2.143028  (0.157103)     2.090307  (0.136778)    
>>> -2.46012
>>
>> So on a very contended system we're actually slower? Is this expected?
>>
>>
>
>
> I think, the result is interesting because its PLE machine. I have to
> experiment more with parameters, SPIN_THRESHOLD, and also may be
> ple_gap and ple_window.

Perhaps the PLE stuff fights with the PV stuff?

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpH-0007HJ-CL; Wed, 18 Jan 2012 10:33:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rn884-0000Rf-Jd
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 12:27:08 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326803198!56041122!1
X-Originating-IP: [32.97.110.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE0OSA9PiAxMTAyMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10454 invoked from network); 17 Jan 2012 12:26:40 -0000
Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 12:26:40 -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 <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 05:27:05 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179)
	by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 05:27:03 -0700
Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233])
	by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id B74D819D8052
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 05:26:59 -0700 (MST)
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HCR1Z5281232
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 07:27:01 -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
	q0HCQwVN019475
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 10:27:00 -0200
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.122.216.170])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0HCQpN3018891; Tue, 17 Jan 2012 10:26:51 -0200
Date: Tue, 17 Jan 2012 17:56:50 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Message-ID: <20120117122650.GC30757@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117091413.GM2167@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011712-7282-0000-0000-000005AF41AB
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Gleb Natapov <gleb@redhat.com> [2012-01-17 11:14:13]:

> > The problem case I was thinking of was when guest VCPU would have issued
> > HLT with interrupts disabled. I guess one option is to inject an NMI,
> > and have the guest kernel NMI handler recognize this and make
> > adjustments such that the vcpu avoids going back to HLT instruction.
> > 
> Just kick vcpu out of a guest mode and adjust rip to point after HLT on
> next re-entry. Don't forget to call vmx_clear_hlt().

Looks bit hackish to me compared to having another hypercall to yield!

> > Having another hypercall to do yield/sleep (rather than effecting that
> > via HLT) seems like an alternate clean solution here ..

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpH-0007HJ-CL; Wed, 18 Jan 2012 10:33:07 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rn884-0000Rf-Jd
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 12:27:08 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326803198!56041122!1
X-Originating-IP: [32.97.110.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE0OSA9PiAxMTAyMDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10454 invoked from network); 17 Jan 2012 12:26:40 -0000
Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149)
	by server-13.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 12:26:40 -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 <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 05:27:05 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179)
	by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 05:27:03 -0700
Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233])
	by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id B74D819D8052
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 05:26:59 -0700 (MST)
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HCR1Z5281232
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 07:27:01 -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
	q0HCQwVN019475
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 10:27:00 -0200
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.122.216.170])
	by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0HCQpN3018891; Tue, 17 Jan 2012 10:26:51 -0200
Date: Tue, 17 Jan 2012 17:56:50 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Message-ID: <20120117122650.GC30757@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117091413.GM2167@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011712-7282-0000-0000-000005AF41AB
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Gleb Natapov <gleb@redhat.com> [2012-01-17 11:14:13]:

> > The problem case I was thinking of was when guest VCPU would have issued
> > HLT with interrupts disabled. I guess one option is to inject an NMI,
> > and have the guest kernel NMI handler recognize this and make
> > adjustments such that the vcpu avoids going back to HLT instruction.
> > 
> Just kick vcpu out of a guest mode and adjust rip to point after HLT on
> next re-entry. Don't forget to call vmx_clear_hlt().

Looks bit hackish to me compared to having another hypercall to yield!

> > Having another hypercall to do yield/sleep (rather than effecting that
> > via HLT) seems like an alternate clean solution here ..

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpA-0007FS-5w; Wed, 18 Jan 2012 10:33:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmrSL-0004IZ-Dl
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:38:57 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326739003!48777838!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxMTE4NDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14374 invoked from network); 16 Jan 2012 18:36:47 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 18:36:47 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 18:24:27 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp04.au.ibm.com ([202.81.31.210]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 18:24:17 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0GIY8wp3580118
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 05:34:11 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0GIca80006612
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 05:38:37 +1100
Received: from oc5400248562.ibm.com ([9.124.209.11])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0GIcRtx006437; Tue, 17 Jan 2012 05:38:28 +1100
Message-ID: <4F146EA5.3010106@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 00:08:29 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>, Jeremy Fitzhardinge <jeremy@goop.org>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
In-Reply-To: <B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
x-cbid: 12011608-9264-0000-0000-000000A33A73
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Greg Kroah-Hartman <gregkh@suse.de>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 07:53 PM, Alexander Graf wrote:
>
> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>
>> * Alexander Graf<agraf@suse.de>  [2012-01-16 04:57:45]:
>>
>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>
>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>> some workload(s)?
>
> Yup
>
>>
>> In some sense, the 1x overcommitcase results posted does measure the overhead
>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>> kernbench ..
>>
>>> Result for Non PLE machine :
>>> ============================
>>
>> [snip]
>>
>>> Kernbench:
>>>                BASE                    BASE+patch
>
> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>
>
> Alex

Sorry for confusion, I think I was little imprecise on the BASE.

The BASE is pre 3.2.0 + Jeremy's following patches:
xadd (https://lkml.org/lkml/2011/10/4/328)
x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
So this would have ticketlock cleanups from Jeremy and
CONFIG_PARAVIRT_SPINLOCKS=y

BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
series and CONFIG_PARAVIRT_SPINLOCKS=y

In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.

So let,
A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
D. pre-3.2.0 + Jeremy's above patches + V5 patches with 
CONFIG_PARAVIRT_SPINLOCKS = n
E. pre-3.2.0 + Jeremy's above patches + V5 patches with 
CONFIG_PARAVIRT_SPINLOCKS = y

is it performance of A vs E ? (currently C vs E)

Please let me know the configuration expected for testing.

Jeremy,
I would be happy to test A vs B vs C vs E, for some workload of interest 
if you wish, for your upcoming patches.

Thanks and Regards
Raghu

>
>>>                %improvement
>>>                mean (sd)               mean (sd)
>>> Scenario A:
>>> case 1x:	 164.233 (16.5506)	 163.584 (15.4598	0.39517
>>
>> [snip]
>>
>>> Result for PLE machine:
>>> ======================
>>
>> [snip]
>>> Kernbench:
>>>                BASE                    BASE+patch
>>>                %improvement
>>>                mean (sd)               mean (sd)
>>> Scenario A:
>>> case 1x:	 161.263 (56.518)        159.635 (40.5621)	1.00953
>>
>> - vatsa
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpA-0007FS-5w; Wed, 18 Jan 2012 10:33:00 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmrSL-0004IZ-Dl
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:38:57 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326739003!48777838!1
X-Originating-IP: [202.81.31.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NiA9PiAxMTE4NDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14374 invoked from network); 16 Jan 2012 18:36:47 -0000
Received: from e23smtp04.au.ibm.com (HELO e23smtp04.au.ibm.com) (202.81.31.146)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 18:36:47 -0000
Received: from /spool/local
	by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 18:24:27 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp04.au.ibm.com ([202.81.31.210]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 18:24:17 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0GIY8wp3580118
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 05:34:11 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0GIca80006612
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 05:38:37 +1100
Received: from oc5400248562.ibm.com ([9.124.209.11])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0GIcRtx006437; Tue, 17 Jan 2012 05:38:28 +1100
Message-ID: <4F146EA5.3010106@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 00:08:29 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>, Jeremy Fitzhardinge <jeremy@goop.org>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
In-Reply-To: <B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
x-cbid: 12011608-9264-0000-0000-000000A33A73
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Greg Kroah-Hartman <gregkh@suse.de>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 07:53 PM, Alexander Graf wrote:
>
> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>
>> * Alexander Graf<agraf@suse.de>  [2012-01-16 04:57:45]:
>>
>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>
>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>> some workload(s)?
>
> Yup
>
>>
>> In some sense, the 1x overcommitcase results posted does measure the overhead
>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>> kernbench ..
>>
>>> Result for Non PLE machine :
>>> ============================
>>
>> [snip]
>>
>>> Kernbench:
>>>                BASE                    BASE+patch
>
> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>
>
> Alex

Sorry for confusion, I think I was little imprecise on the BASE.

The BASE is pre 3.2.0 + Jeremy's following patches:
xadd (https://lkml.org/lkml/2011/10/4/328)
x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
So this would have ticketlock cleanups from Jeremy and
CONFIG_PARAVIRT_SPINLOCKS=y

BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
series and CONFIG_PARAVIRT_SPINLOCKS=y

In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.

So let,
A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
D. pre-3.2.0 + Jeremy's above patches + V5 patches with 
CONFIG_PARAVIRT_SPINLOCKS = n
E. pre-3.2.0 + Jeremy's above patches + V5 patches with 
CONFIG_PARAVIRT_SPINLOCKS = y

is it performance of A vs E ? (currently C vs E)

Please let me know the configuration expected for testing.

Jeremy,
I would be happy to test A vs B vs C vs E, for some workload of interest 
if you wish, for your upcoming patches.

Thanks and Regards
Raghu

>
>>>                %improvement
>>>                mean (sd)               mean (sd)
>>> Scenario A:
>>> case 1x:	 164.233 (16.5506)	 163.584 (15.4598	0.39517
>>
>> [snip]
>>
>>> Result for PLE machine:
>>> ======================
>>
>> [snip]
>>> Kernbench:
>>>                BASE                    BASE+patch
>>>                %improvement
>>>                mean (sd)               mean (sd)
>>> Scenario A:
>>> case 1x:	 161.263 (56.518)        159.635 (40.5621)	1.00953
>>
>> - vatsa
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpG-0007Gz-6M; Wed, 18 Jan 2012 10:33:06 +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 1Rn6qG-0005sw-Qu
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:04:41 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326798273!9416595!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24670 invoked from network); 17 Jan 2012 11:04:33 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-174.messagelabs.com with SMTP;
	17 Jan 2012 11:04:33 -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 q0HB4BJj016846
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 06:04:11 -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 q0HB48Se028102; Tue, 17 Jan 2012 06:04:08 -0500
Received: from amt.cnet (vpn1-7-209.ams2.redhat.com [10.36.7.209])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q0HB3uWe028062;
	Tue, 17 Jan 2012 06:03:58 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 782DE652371;
	Tue, 17 Jan 2012 09:02:26 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q0HB2BcW006076;
	Tue, 17 Jan 2012 09:02:11 -0200
Date: Tue, 17 Jan 2012 09:02:11 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120117110210.GA17420@amt.cnet>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.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: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 14, 2012 at 11:56:46PM +0530, Raghavendra K T wrote:
> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks. 
> 
> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
>  support for pv-ticketlocks is registered via pv_lock_ops.
> 
> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
> 
> 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 7a94987..cf5327c 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -195,10 +195,20 @@ 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)
> +
>  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..ec55a0b 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,250 @@ 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, u32 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 by its apicid*/
> +static inline void kvm_kick_cpu(int apicid)
> +{
> +	kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
> +}
> +
> +/* Kick vcpu waiting on @lock->head to reach value @ticket */
> +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
> +{
> +	int cpu;
> +	int apicid;
> +
> +	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);
> +			apicid = per_cpu(x86_cpu_to_apicid, cpu);
> +			kvm_kick_cpu(apicid);
> +			break;
> +		}
> +	}

What prevents a kick from being lost here, if say, the waiter is at
local_irq_save in kvm_lock_spinning, before the lock/want assignments?

> +
> +/*
> + * Setup pv_lock_ops to exploit KVM_FEATURE_PVLOCK_KICK if present.
> + */
> +void __init kvm_spinlock_init(void)
> +{
> +	if (!kvm_para_available())
> +		return;
> +	/* Does host kernel support KVM_FEATURE_PVLOCK_KICK? */
> +	if (!kvm_para_has_feature(KVM_FEATURE_PVLOCK_KICK))
> +		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/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c7b05fc..4d7a950 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>  
>  	local_irq_disable();
>  
> -	if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
> -	    || need_resched() || signal_pending(current)) {
> +	if (vcpu->mode == EXITING_GUEST_MODE
> +		 || (vcpu->requests & ~(1UL<<KVM_REQ_PVLOCK_KICK))
> +		 || need_resched() || signal_pending(current)) {
>  		vcpu->mode = OUTSIDE_GUEST_MODE;
>  		smp_wmb();
>  		local_irq_enable();
> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>  		!vcpu->arch.apf.halted)
>  		|| !list_empty_careful(&vcpu->async_pf.done)
>  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> +		|| kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)

The bit should only be read here (kvm_arch_vcpu_runnable), but cleared
on vcpu entry (along with the other kvm_check_request processing).

Then the first hunk becomes unnecessary.

Please do not mix host/guest patches.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpG-0007Gz-6M; Wed, 18 Jan 2012 10:33:06 +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 1Rn6qG-0005sw-Qu
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:04:41 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326798273!9416595!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24670 invoked from network); 17 Jan 2012 11:04:33 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-12.tower-174.messagelabs.com with SMTP;
	17 Jan 2012 11:04:33 -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 q0HB4BJj016846
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 06:04:11 -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 q0HB48Se028102; Tue, 17 Jan 2012 06:04:08 -0500
Received: from amt.cnet (vpn1-7-209.ams2.redhat.com [10.36.7.209])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q0HB3uWe028062;
	Tue, 17 Jan 2012 06:03:58 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id 782DE652371;
	Tue, 17 Jan 2012 09:02:26 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q0HB2BcW006076;
	Tue, 17 Jan 2012 09:02:11 -0200
Date: Tue, 17 Jan 2012 09:02:11 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Message-ID: <20120117110210.GA17420@amt.cnet>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.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: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 14, 2012 at 11:56:46PM +0530, Raghavendra K T wrote:
> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks. 
> 
> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
>  support for pv-ticketlocks is registered via pv_lock_ops.
> 
> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
> 
> 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 7a94987..cf5327c 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -195,10 +195,20 @@ 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)
> +
>  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..ec55a0b 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,250 @@ 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, u32 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 by its apicid*/
> +static inline void kvm_kick_cpu(int apicid)
> +{
> +	kvm_hypercall1(KVM_HC_KICK_CPU, apicid);
> +}
> +
> +/* Kick vcpu waiting on @lock->head to reach value @ticket */
> +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
> +{
> +	int cpu;
> +	int apicid;
> +
> +	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);
> +			apicid = per_cpu(x86_cpu_to_apicid, cpu);
> +			kvm_kick_cpu(apicid);
> +			break;
> +		}
> +	}

What prevents a kick from being lost here, if say, the waiter is at
local_irq_save in kvm_lock_spinning, before the lock/want assignments?

> +
> +/*
> + * Setup pv_lock_ops to exploit KVM_FEATURE_PVLOCK_KICK if present.
> + */
> +void __init kvm_spinlock_init(void)
> +{
> +	if (!kvm_para_available())
> +		return;
> +	/* Does host kernel support KVM_FEATURE_PVLOCK_KICK? */
> +	if (!kvm_para_has_feature(KVM_FEATURE_PVLOCK_KICK))
> +		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/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index c7b05fc..4d7a950 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>  
>  	local_irq_disable();
>  
> -	if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
> -	    || need_resched() || signal_pending(current)) {
> +	if (vcpu->mode == EXITING_GUEST_MODE
> +		 || (vcpu->requests & ~(1UL<<KVM_REQ_PVLOCK_KICK))
> +		 || need_resched() || signal_pending(current)) {
>  		vcpu->mode = OUTSIDE_GUEST_MODE;
>  		smp_wmb();
>  		local_irq_enable();
> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>  		!vcpu->arch.apf.halted)
>  		|| !list_empty_careful(&vcpu->async_pf.done)
>  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
> +		|| kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)

The bit should only be read here (kvm_arch_vcpu_runnable), but cleared
on vcpu entry (along with the other kvm_check_request processing).

Then the first hunk becomes unnecessary.

Please do not mix host/guest patches.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp6-0007Dv-2o; Wed, 18 Jan 2012 10:32:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RmnQm-0003PP-V4
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:21:05 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326723610!52735277!1
X-Originating-IP: [32.97.182.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0MiA9PiAxNjEyNjk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26915 invoked from network); 16 Jan 2012 14:20:11 -0000
Received: from e2.ny.us.ibm.com (HELO e2.ny.us.ibm.com) (32.97.182.142)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 14:20:11 -0000
Received: from /spool/local
	by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Mon, 16 Jan 2012 09:21:00 -0500
Received: from d03dlp02.boulder.ibm.com (9.17.202.178)
	by e2.ny.us.ibm.com (192.168.1.102) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 09:20:47 -0500
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com
	[9.17.195.228])
	by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 1E5933E40047
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 07:20:47 -0700 (MST)
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0GEKkpV166996
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 07:20:46 -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 q0GEKbpc029919
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 07:20:44 -0700
Received: from linux.vnet.ibm.com ([9.77.126.209])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0GEKO0m028755; Mon, 16 Jan 2012 07:20:25 -0700
Date: Mon, 16 Jan 2012 19:50:23 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
Message-ID: <20120116142014.GA10155@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011614-5112-0000-0000-0000041B5F00
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Alexander Graf <agraf@suse.de> [2012-01-16 04:57:45]:

> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?

You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for 
some workload(s)?

In some sense, the 1x overcommitcase results posted does measure the overhead
of (pv-)spinlocks no? We don't see any overhead in that case for atleast
kernbench ..

> Result for Non PLE machine :
> ============================

[snip]

> Kernbench:
>                BASE                    BASE+patch
>                %improvement
>                mean (sd)               mean (sd)
> Scenario A:
> case 1x:	 164.233 (16.5506)	 163.584 (15.4598	0.39517

[snip]

> Result for PLE machine:
> ======================

[snip]
> Kernbench:
>                BASE                    BASE+patch
>                %improvement
>                mean (sd)               mean (sd)
> Scenario A:
> case 1x:	 161.263 (56.518)        159.635 (40.5621)	1.00953

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp6-0007Dv-2o; Wed, 18 Jan 2012 10:32:56 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RmnQm-0003PP-V4
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:21:05 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326723610!52735277!1
X-Originating-IP: [32.97.182.142]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTgyLjE0MiA9PiAxNjEyNjk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26915 invoked from network); 16 Jan 2012 14:20:11 -0000
Received: from e2.ny.us.ibm.com (HELO e2.ny.us.ibm.com) (32.97.182.142)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 14:20:11 -0000
Received: from /spool/local
	by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Mon, 16 Jan 2012 09:21:00 -0500
Received: from d03dlp02.boulder.ibm.com (9.17.202.178)
	by e2.ny.us.ibm.com (192.168.1.102) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 09:20:47 -0500
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com
	[9.17.195.228])
	by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 1E5933E40047
	for <xen-devel@lists.xensource.com>;
	Mon, 16 Jan 2012 07:20:47 -0700 (MST)
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0GEKkpV166996
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 07:20:46 -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 q0GEKbpc029919
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 07:20:44 -0700
Received: from linux.vnet.ibm.com ([9.77.126.209])
	by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0GEKO0m028755; Mon, 16 Jan 2012 07:20:25 -0700
Date: Mon, 16 Jan 2012 19:50:23 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Alexander Graf <agraf@suse.de>
Message-ID: <20120116142014.GA10155@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011614-5112-0000-0000-0000041B5F00
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Alexander Graf <agraf@suse.de> [2012-01-16 04:57:45]:

> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?

You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for 
some workload(s)?

In some sense, the 1x overcommitcase results posted does measure the overhead
of (pv-)spinlocks no? We don't see any overhead in that case for atleast
kernbench ..

> Result for Non PLE machine :
> ============================

[snip]

> Kernbench:
>                BASE                    BASE+patch
>                %improvement
>                mean (sd)               mean (sd)
> Scenario A:
> case 1x:	 164.233 (16.5506)	 163.584 (15.4598	0.39517

[snip]

> Result for PLE machine:
> ======================

[snip]
> Kernbench:
>                BASE                    BASE+patch
>                %improvement
>                mean (sd)               mean (sd)
> Scenario A:
> case 1x:	 161.263 (56.518)        159.635 (40.5621)	1.00953

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp4-0007DQ-Es; Wed, 18 Jan 2012 10:32:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rmmql-0002Nn-GF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:43:51 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326721327!61161879!1
X-Originating-IP: [122.248.162.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMiA9PiAyMDYzODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27298 invoked from network); 16 Jan 2012 13:42:37 -0000
Received: from e28smtp02.in.ibm.com (HELO e28smtp02.in.ibm.com) (122.248.162.2)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 13:42:37 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 19:13:12 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp02.in.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 19:13:08 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0GDh6o93858664
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:13:08 +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
	q0GDh4D9017679
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 00:43:05 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0GDh3IH017660; Tue, 17 Jan 2012 00:43:04 +1100
Message-ID: <4F14296B.4070003@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 19:13:07 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
In-Reply-To: <3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
x-cbid: 12011613-5816-0000-0000-000000E23077
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 09:27 AM, Alexander Graf wrote:
>
[...]
>> 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
>>
>> Kernbench:
>> 		 BASE                    BASE+patch            %improvement
>> 		 mean (sd)               mean (sd)
>> Scenario A:	 			
>> case 1x:	 161.263 (56.518) 	 159.635 (40.5621) 	1.00953
>> case 2x:	 190.748 (61.2745) 	 190.606 (54.4766) 	0.0744438
>> case 3x:	 227.378 (100.215) 	 225.442 (92.0809) 	0.851446
>>
>> Scenario B:
>> 		 446.104 (58.54 )	 433.12733 (54.476)	2.91
>>
>> Dbench:
>> Throughput is in MB/sec
>> NRCLIENTS	 BASE                    BASE+patch            %improvement
>>                	 mean (sd)               mean (sd)
>> 8       	1.101190  (0.875082) 	1.700395  (0.846809) 	54.4143
>> 16      	1.524312  (0.120354) 	1.477553  (0.058166) 	-3.06755
>> 32        	2.143028  (0.157103) 	2.090307  (0.136778) 	-2.46012
>
> So on a very contended system we're actually slower? Is this expected?
>
>

I think, the result is interesting because its PLE machine. I have to 
experiment more with parameters, SPIN_THRESHOLD, and also may be ple_gap 
and ple_window.

> Alex
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp4-0007DQ-Es; Wed, 18 Jan 2012 10:32:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rmmql-0002Nn-GF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 13:43:51 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326721327!61161879!1
X-Originating-IP: [122.248.162.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMiA9PiAyMDYzODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27298 invoked from network); 16 Jan 2012 13:42:37 -0000
Received: from e28smtp02.in.ibm.com (HELO e28smtp02.in.ibm.com) (122.248.162.2)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 13:42:37 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 19:13:12 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp02.in.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 19:13:08 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0GDh6o93858664
	for <xen-devel@lists.xensource.com>; Mon, 16 Jan 2012 19:13:08 +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
	q0GDh4D9017679
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 00:43:05 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0GDh3IH017660; Tue, 17 Jan 2012 00:43:04 +1100
Message-ID: <4F14296B.4070003@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 19:13:07 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
In-Reply-To: <3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
x-cbid: 12011613-5816-0000-0000-000000E23077
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 09:27 AM, Alexander Graf wrote:
>
[...]
>> 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
>>
>> Kernbench:
>> 		 BASE                    BASE+patch            %improvement
>> 		 mean (sd)               mean (sd)
>> Scenario A:	 			
>> case 1x:	 161.263 (56.518) 	 159.635 (40.5621) 	1.00953
>> case 2x:	 190.748 (61.2745) 	 190.606 (54.4766) 	0.0744438
>> case 3x:	 227.378 (100.215) 	 225.442 (92.0809) 	0.851446
>>
>> Scenario B:
>> 		 446.104 (58.54 )	 433.12733 (54.476)	2.91
>>
>> Dbench:
>> Throughput is in MB/sec
>> NRCLIENTS	 BASE                    BASE+patch            %improvement
>>                	 mean (sd)               mean (sd)
>> 8       	1.101190  (0.875082) 	1.700395  (0.846809) 	54.4143
>> 16      	1.524312  (0.120354) 	1.477553  (0.058166) 	-3.06755
>> 32        	2.143028  (0.157103) 	2.090307  (0.136778) 	-2.46012
>
> So on a very contended system we're actually slower? Is this expected?
>
>

I think, the result is interesting because its PLE machine. I have to 
experiment more with parameters, SPIN_THRESHOLD, and also may be ple_gap 
and ple_window.

> Alex
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSpD-0007GM-Nj; Wed, 18 Jan 2012 10:33:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RmwJ1-0007ha-AA
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 23:49:39 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326757771!2026264!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23606 invoked from network); 16 Jan 2012 23:49:33 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 23:49:33 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 7C5CD9328;
	Mon, 16 Jan 2012 15:49:30 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id D284820867;
	Tue, 17 Jan 2012 10:49:18 +1100 (EST)
Message-ID: <4F14B77E.30202@goop.org>
Date: Tue, 17 Jan 2012 10:49:18 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<4F13E84C.3010808@redhat.com> <4F1430A2.1080401@linux.vnet.ibm.com>
	<4F143874.9010307@redhat.com>
In-Reply-To: <4F143874.9010307@redhat.com>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 01:47 AM, Avi Kivity wrote:
> On 01/16/2012 04:13 PM, Raghavendra K T wrote:
>>> Please drop all of these and replace with tracepoints in the appropriate
>>> spots.  Everything else (including the historgram) can be reconstructed
>>> the tracepoints in userspace.
>>>
>>
>> I think Jeremy pointed that tracepoints use spinlocks and hence debugfs
>> is the option.. no ?
>>
> Yeah, I think you're right.  What a pity.

Yes, I went through the same thought process.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSpD-0007GM-Nj; Wed, 18 Jan 2012 10:33:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RmwJ1-0007ha-AA
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 23:49:39 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326757771!2026264!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23606 invoked from network); 16 Jan 2012 23:49:33 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 23:49:33 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 7C5CD9328;
	Mon, 16 Jan 2012 15:49:30 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id D284820867;
	Tue, 17 Jan 2012 10:49:18 +1100 (EST)
Message-ID: <4F14B77E.30202@goop.org>
Date: Tue, 17 Jan 2012 10:49:18 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<4F13E84C.3010808@redhat.com> <4F1430A2.1080401@linux.vnet.ibm.com>
	<4F143874.9010307@redhat.com>
In-Reply-To: <4F143874.9010307@redhat.com>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 01:47 AM, Avi Kivity wrote:
> On 01/16/2012 04:13 PM, Raghavendra K T wrote:
>>> Please drop all of these and replace with tracepoints in the appropriate
>>> spots.  Everything else (including the historgram) can be reconstructed
>>> the tracepoints in userspace.
>>>
>>
>> I think Jeremy pointed that tracepoints use spinlocks and hence debugfs
>> is the option.. no ?
>>
> Yeah, I think you're right.  What a pity.

Yes, I went through the same thought process.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSpI-0007Hq-RI; Wed, 18 Jan 2012 10:33:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rn8rY-0001BS-QR
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:14:09 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326805999!60566938!1
X-Originating-IP: [202.81.31.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MCA9PiAyNjkzMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3323 invoked from network); 17 Jan 2012 13:13:23 -0000
Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 13:13:23 -0000
Received: from /spool/local
	by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Jan 2012 13:10:05 +1000
Received: from d23relay05.au.ibm.com ([202.81.31.247])
	by e23smtp07.au.ibm.com ([202.81.31.204]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 13:09:59 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HD9A1k3100698
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:09:12 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0HDDfqW000313
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:13:42 +1100
Received: from oc5400248562.ibm.com ([9.124.215.78])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HDDVPC032490; Wed, 18 Jan 2012 00:13:32 +1100
Message-ID: <4F1573FD.3030604@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 18:43:33 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
In-Reply-To: <20120117125126.GQ2167@redhat.com>
x-cbid: 12011703-0260-0000-0000-00000063FDDF
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.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>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 06:21 PM, Gleb Natapov wrote:
> On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote:
>> * Gleb Natapov<gleb@redhat.com>  [2012-01-17 11:14:13]:
>>
>>>> The problem case I was thinking of was when guest VCPU would have issued
>>>> HLT with interrupts disabled. I guess one option is to inject an NMI,
>>>> and have the guest kernel NMI handler recognize this and make
>>>> adjustments such that the vcpu avoids going back to HLT instruction.
>>>>
>>> Just kick vcpu out of a guest mode and adjust rip to point after HLT on
>>> next re-entry. Don't forget to call vmx_clear_hlt().
>>
>> Looks bit hackish to me compared to having another hypercall to yield!
>>
> Do not see anything hackish about it. But what you described above (the
> part I replied to) is not another hypercall, but yet another NMI source
> and special handling in a guest. So what hypercall do you mean?
>

Earlier version had a hypercall to sleep instead of current halt()
approach. This was taken out to avoid extra hypercall.

So here is the hypercall hunk referred :

+/*
+ * kvm_pv_wait_for_kick_op : Block until kicked by either a KVM_HC_KICK_CPU
+ * hypercall or a event like interrupt.
+ *
+ * @vcpu : vcpu which is blocking.
+ */
+static void kvm_pv_wait_for_kick_op(struct kvm_vcpu *vcpu)
+{
+       DEFINE_WAIT(wait);
+
+       /*
+        * Blocking on vcpu->wq allows us to wake up sooner if required to
+        * service pending events (like interrupts).
+        *
+        * Also set state to TASK_INTERRUPTIBLE before checking 
vcpu->kicked to
+        * avoid racing with kvm_pv_kick_cpu_op().
+        */
+       prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
+
+       /*
+        * Somebody has already tried kicking us. Acknowledge that
+        * and terminate the wait.
+        */
+       if (vcpu->kicked) {
+               vcpu->kicked = 0;
+               goto end_wait;
+       }
+
+       /* Let's wait for either KVM_HC_KICK_CPU or someother event
+        * to wake us up.
+        */
+
+       srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
+       schedule();
+       vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
+
+end_wait:
+       finish_wait(&vcpu->wq, &wait);
+}

>>>> Having another hypercall to do yield/sleep (rather than effecting that
>>>> via HLT) seems like an alternate clean solution here ..


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSpI-0007Hq-RI; Wed, 18 Jan 2012 10:33:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rn8rY-0001BS-QR
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:14:09 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326805999!60566938!1
X-Originating-IP: [202.81.31.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MCA9PiAyNjkzMzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3323 invoked from network); 17 Jan 2012 13:13:23 -0000
Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 13:13:23 -0000
Received: from /spool/local
	by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Jan 2012 13:10:05 +1000
Received: from d23relay05.au.ibm.com ([202.81.31.247])
	by e23smtp07.au.ibm.com ([202.81.31.204]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 13:09:59 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HD9A1k3100698
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:09:12 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0HDDfqW000313
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:13:42 +1100
Received: from oc5400248562.ibm.com ([9.124.215.78])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HDDVPC032490; Wed, 18 Jan 2012 00:13:32 +1100
Message-ID: <4F1573FD.3030604@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 18:43:33 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Gleb Natapov <gleb@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
In-Reply-To: <20120117125126.GQ2167@redhat.com>
x-cbid: 12011703-0260-0000-0000-00000063FDDF
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, KVM <kvm@vger.kernel.org>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.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>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 06:21 PM, Gleb Natapov wrote:
> On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote:
>> * Gleb Natapov<gleb@redhat.com>  [2012-01-17 11:14:13]:
>>
>>>> The problem case I was thinking of was when guest VCPU would have issued
>>>> HLT with interrupts disabled. I guess one option is to inject an NMI,
>>>> and have the guest kernel NMI handler recognize this and make
>>>> adjustments such that the vcpu avoids going back to HLT instruction.
>>>>
>>> Just kick vcpu out of a guest mode and adjust rip to point after HLT on
>>> next re-entry. Don't forget to call vmx_clear_hlt().
>>
>> Looks bit hackish to me compared to having another hypercall to yield!
>>
> Do not see anything hackish about it. But what you described above (the
> part I replied to) is not another hypercall, but yet another NMI source
> and special handling in a guest. So what hypercall do you mean?
>

Earlier version had a hypercall to sleep instead of current halt()
approach. This was taken out to avoid extra hypercall.

So here is the hypercall hunk referred :

+/*
+ * kvm_pv_wait_for_kick_op : Block until kicked by either a KVM_HC_KICK_CPU
+ * hypercall or a event like interrupt.
+ *
+ * @vcpu : vcpu which is blocking.
+ */
+static void kvm_pv_wait_for_kick_op(struct kvm_vcpu *vcpu)
+{
+       DEFINE_WAIT(wait);
+
+       /*
+        * Blocking on vcpu->wq allows us to wake up sooner if required to
+        * service pending events (like interrupts).
+        *
+        * Also set state to TASK_INTERRUPTIBLE before checking 
vcpu->kicked to
+        * avoid racing with kvm_pv_kick_cpu_op().
+        */
+       prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);
+
+       /*
+        * Somebody has already tried kicking us. Acknowledge that
+        * and terminate the wait.
+        */
+       if (vcpu->kicked) {
+               vcpu->kicked = 0;
+               goto end_wait;
+       }
+
+       /* Let's wait for either KVM_HC_KICK_CPU or someother event
+        * to wake us up.
+        */
+
+       srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
+       schedule();
+       vcpu->srcu_idx = srcu_read_lock(&vcpu->kvm->srcu);
+
+end_wait:
+       finish_wait(&vcpu->wq, &wait);
+}

>>>> Having another hypercall to do yield/sleep (rather than effecting that
>>>> via HLT) seems like an alternate clean solution here ..


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSpB-0007Fm-7D; Wed, 18 Jan 2012 10:33:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rmrc8-0004M8-3o
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:49:04 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326739618!59928099!1
X-Originating-IP: [202.81.31.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NSA9PiAyMTAwOTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8014 invoked from network); 16 Jan 2012 18:47:02 -0000
Received: from e23smtp03.au.ibm.com (HELO e23smtp03.au.ibm.com) (202.81.31.145)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 18:47:02 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 18:42:17 +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; 
	Mon, 16 Jan 2012 18:42:13 +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
	q0GImkJx5206172
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 05:48:48 +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
	q0GImi2U005443
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 05:48:46 +1100
Received: from oc5400248562.ibm.com ([9.124.209.11])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0GImaJ6005376; Tue, 17 Jan 2012 05:48:36 +1100
Message-ID: <4F147106.4040803@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 00:18:38 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>, Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<4F14296B.4070003@linux.vnet.ibm.com> <4F142AF1.2020801@redhat.com>
In-Reply-To: <4F142AF1.2020801@redhat.com>
x-cbid: 12011608-6102-0000-0000-000000A69533
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 07:19 PM, Avi Kivity wrote:
> On 01/16/2012 03:43 PM, Raghavendra K T wrote:
>>>> Dbench:
>>>> Throughput is in MB/sec
>>>> NRCLIENTS     BASE                    BASE+patch
>>>> %improvement
>>>>                      mean (sd)               mean (sd)
>>>> 8           1.101190  (0.875082)     1.700395  (0.846809)     54.4143
>>>> 16          1.524312  (0.120354)     1.477553  (0.058166)     -3.06755
>>>> 32            2.143028  (0.157103)     2.090307  (0.136778)
>>>> -2.46012
>>>
>>> So on a very contended system we're actually slower? Is this expected?
>>>
>>>
>>
>>
>> I think, the result is interesting because its PLE machine. I have to
>> experiment more with parameters, SPIN_THRESHOLD, and also may be
>> ple_gap and ple_window.
>
> Perhaps the PLE stuff fights with the PV stuff?
>

I also think so. The slight advantage in PLE, with current patch would
be  that, we are be able to say " This is the next guy who should
probably get his turn".  But If total number of unnecessary "halt
exits" disadvantage dominates above advantage, then we see degradation.

One clarification in above benchmarking is,  Dbench is run
simultaneously on all (8 vcpu) 3 guests. So we already have 1:3 
overcommit when we run 8 clients of dbench. after that it was just 
increasing number of clients.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSp5-0007Dj-Fv; Wed, 18 Jan 2012 10:32:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmnKW-0003ER-Qz
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:14:37 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326723221!60401137!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA4Mzk5OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10939 invoked from network); 16 Jan 2012 14:13:44 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 14:13:44 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 14:12:25 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp08.au.ibm.com ([202.81.31.205]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 14:12:04 +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
	q0GE9SfN2928734
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 01:09:31 +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
	q0GEDu8h032074
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 01:13:57 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0GEDp3K031604; Tue, 17 Jan 2012 01:13:51 +1100
Message-ID: <4F1430A2.1080401@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 19:43:54 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<4F13E84C.3010808@redhat.com>
In-Reply-To: <4F13E84C.3010808@redhat.com>
x-cbid: 12011604-5140-0000-0000-00000098C73B
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 02:35 PM, Avi Kivity wrote:
> On 01/14/2012 08:26 PM, Raghavendra K T wrote:
>> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks.
>>
>> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
>> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
>>   support for pv-ticketlocks is registered via pv_lock_ops.
>>
>> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
>> +
>> +	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);
>> +
>>
>
> Please drop all of these and replace with tracepoints in the appropriate
> spots.  Everything else (including the historgram) can be reconstructed
> the tracepoints in userspace.
>

I think Jeremy pointed that tracepoints use spinlocks and hence debugfs
is the option.. no ?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSpB-0007Fm-7D; Wed, 18 Jan 2012 10:33:01 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1Rmrc8-0004M8-3o
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:49:04 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326739618!59928099!1
X-Originating-IP: [202.81.31.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0NSA9PiAyMTAwOTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8014 invoked from network); 16 Jan 2012 18:47:02 -0000
Received: from e23smtp03.au.ibm.com (HELO e23smtp03.au.ibm.com) (202.81.31.145)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 18:47:02 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 18:42:17 +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; 
	Mon, 16 Jan 2012 18:42:13 +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
	q0GImkJx5206172
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 05:48:48 +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
	q0GImi2U005443
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 05:48:46 +1100
Received: from oc5400248562.ibm.com ([9.124.209.11])
	by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0GImaJ6005376; Tue, 17 Jan 2012 05:48:36 +1100
Message-ID: <4F147106.4040803@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 00:18:38 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>, Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<4F14296B.4070003@linux.vnet.ibm.com> <4F142AF1.2020801@redhat.com>
In-Reply-To: <4F142AF1.2020801@redhat.com>
x-cbid: 12011608-6102-0000-0000-000000A69533
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 07:19 PM, Avi Kivity wrote:
> On 01/16/2012 03:43 PM, Raghavendra K T wrote:
>>>> Dbench:
>>>> Throughput is in MB/sec
>>>> NRCLIENTS     BASE                    BASE+patch
>>>> %improvement
>>>>                      mean (sd)               mean (sd)
>>>> 8           1.101190  (0.875082)     1.700395  (0.846809)     54.4143
>>>> 16          1.524312  (0.120354)     1.477553  (0.058166)     -3.06755
>>>> 32            2.143028  (0.157103)     2.090307  (0.136778)
>>>> -2.46012
>>>
>>> So on a very contended system we're actually slower? Is this expected?
>>>
>>>
>>
>>
>> I think, the result is interesting because its PLE machine. I have to
>> experiment more with parameters, SPIN_THRESHOLD, and also may be
>> ple_gap and ple_window.
>
> Perhaps the PLE stuff fights with the PV stuff?
>

I also think so. The slight advantage in PLE, with current patch would
be  that, we are be able to say " This is the next guy who should
probably get his turn".  But If total number of unnecessary "halt
exits" disadvantage dominates above advantage, then we see degradation.

One clarification in above benchmarking is,  Dbench is run
simultaneously on all (8 vcpu) 3 guests. So we already have 1:3 
overcommit when we run 8 clients of dbench. after that it was just 
increasing number of clients.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSp5-0007Dj-Fv; Wed, 18 Jan 2012 10:32:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RmnKW-0003ER-Qz
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:14:37 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326723221!60401137!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA4Mzk5OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10939 invoked from network); 16 Jan 2012 14:13:44 -0000
Received: from e23smtp08.au.ibm.com (HELO e23smtp08.au.ibm.com) (202.81.31.141)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 14:13:44 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Mon, 16 Jan 2012 14:12:25 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp08.au.ibm.com ([202.81.31.205]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Mon, 16 Jan 2012 14:12:04 +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
	q0GE9SfN2928734
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 01:09:31 +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
	q0GEDu8h032074
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 01:13:57 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.158.101])
	by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0GEDp3K031604; Tue, 17 Jan 2012 01:13:51 +1100
Message-ID: <4F1430A2.1080401@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 19:43:54 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<4F13E84C.3010808@redhat.com>
In-Reply-To: <4F13E84C.3010808@redhat.com>
x-cbid: 12011604-5140-0000-0000-00000098C73B
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 02:35 PM, Avi Kivity wrote:
> On 01/14/2012 08:26 PM, Raghavendra K T wrote:
>> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks.
>>
>> During smp_boot_cpus  paravirtualied KVM guest detects if the hypervisor has
>> required feature (KVM_FEATURE_PVLOCK_KICK) to support pv-ticketlocks. If so,
>>   support for pv-ticketlocks is registered via pv_lock_ops.
>>
>> Use KVM_HC_KICK_CPU hypercall to wakeup waiting/halted vcpu.
>> +
>> +	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);
>> +
>>
>
> Please drop all of these and replace with tracepoints in the appropriate
> spots.  Everything else (including the historgram) can be reconstructed
> the tracepoints in userspace.
>

I think Jeremy pointed that tracepoints use spinlocks and hence debugfs
is the option.. no ?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSpG-0007H9-RG; Wed, 18 Jan 2012 10:33:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rn7IS-0007ZG-1o
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:33:48 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326800019!8849348!1
X-Originating-IP: [32.97.110.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MiA9PiAzNjY2OTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13439 invoked from network); 17 Jan 2012 11:33:41 -0000
Received: from e34.co.us.ibm.com (HELO e34.co.us.ibm.com) (32.97.110.152)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 11:33:41 -0000
Received: from /spool/local
	by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 04:33:39 -0700
Received: from d03dlp01.boulder.ibm.com (9.17.202.177)
	by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 04:33:37 -0700
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 4C5801FF0047
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 04:33:35 -0700 (MST)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HBXZ9s195198
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 06:33:35 -0500
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q0HBXUiZ021819
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 04:33:34 -0700
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.122.216.170])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0HBXLh2021241; Tue, 17 Jan 2012 04:33:22 -0700
Date: Tue, 17 Jan 2012 17:03:20 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Message-ID: <20120117113312.GB30398@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117110210.GA17420@amt.cnet>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011711-1780-0000-0000-00000261ADB9
X-IBM-ISS-SpamDetectors: 
X-IBM-ISS-DetailInfo: BY=3.00000245; HX=3.00000181; KW=3.00000007;
	PH=3.00000001; SC=3.00000001; SDB=6.00105699; UDB=6.00026655;
	UTC=2012-01-17 11:33:38
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Marcelo Tosatti <mtosatti@redhat.com> [2012-01-17 09:02:11]:

> > +/* Kick vcpu waiting on @lock->head to reach value @ticket */
> > +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
> > +{
> > +	int cpu;
> > +	int apicid;
> > +
> > +	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);
> > +			apicid = per_cpu(x86_cpu_to_apicid, cpu);
> > +			kvm_kick_cpu(apicid);
> > +			break;
> > +		}
> > +	}
> 
> What prevents a kick from being lost here, if say, the waiter is at
> local_irq_save in kvm_lock_spinning, before the lock/want assignments?

The waiter does check for lock becoming available before actually
sleeping:

+	/*
+        * 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;
+	}

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSpG-0007H9-RG; Wed, 18 Jan 2012 10:33:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rn7IS-0007ZG-1o
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 11:33:48 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326800019!8849348!1
X-Originating-IP: [32.97.110.152]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MiA9PiAzNjY2OTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13439 invoked from network); 17 Jan 2012 11:33:41 -0000
Received: from e34.co.us.ibm.com (HELO e34.co.us.ibm.com) (32.97.110.152)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 11:33:41 -0000
Received: from /spool/local
	by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 04:33:39 -0700
Received: from d03dlp01.boulder.ibm.com (9.17.202.177)
	by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 04:33:37 -0700
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 4C5801FF0047
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 04:33:35 -0700 (MST)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HBXZ9s195198
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 06:33:35 -0500
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q0HBXUiZ021819
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 04:33:34 -0700
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.122.216.170])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0HBXLh2021241; Tue, 17 Jan 2012 04:33:22 -0700
Date: Tue, 17 Jan 2012 17:03:20 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Message-ID: <20120117113312.GB30398@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117110210.GA17420@amt.cnet>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011711-1780-0000-0000-00000261ADB9
X-IBM-ISS-SpamDetectors: 
X-IBM-ISS-DetailInfo: BY=3.00000245; HX=3.00000181; KW=3.00000007;
	PH=3.00000001; SC=3.00000001; SDB=6.00105699; UDB=6.00026655;
	UTC=2012-01-17 11:33:38
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Marcelo Tosatti <mtosatti@redhat.com> [2012-01-17 09:02:11]:

> > +/* Kick vcpu waiting on @lock->head to reach value @ticket */
> > +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
> > +{
> > +	int cpu;
> > +	int apicid;
> > +
> > +	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);
> > +			apicid = per_cpu(x86_cpu_to_apicid, cpu);
> > +			kvm_kick_cpu(apicid);
> > +			break;
> > +		}
> > +	}
> 
> What prevents a kick from being lost here, if say, the waiter is at
> local_irq_save in kvm_lock_spinning, before the lock/want assignments?

The waiter does check for lock becoming available before actually
sleeping:

+	/*
+        * 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;
+	}

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSp8-0007EY-6F; Wed, 18 Jan 2012 10:32:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rmr5e-0003wS-JF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:15:30 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326737723!11281463!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23891 invoked from network); 16 Jan 2012 18:15:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 18:15:23 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GIFLrr026547
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 13:15:22 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GIFH4A026361; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 5147440C6C; Mon, 16 Jan 2012 19:15:16 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:12 +0100
Message-Id: <1326737715-9867-4-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 3/6] suspend: add wakeup monitor command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds a wakeup monitor command which will simply wake up
suspended guests.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hmp-commands.hx  |   14 ++++++++++++++
 hmp.c            |    5 +++++
 hmp.h            |    1 +
 qapi-schema.json |   11 +++++++++++
 qmp-commands.hx  |   21 +++++++++++++++++++++
 qmp.c            |    5 +++++
 6 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index a586498..c62871a 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -313,6 +313,20 @@ Resume emulation.
 ETEXI
 
     {
+        .name       = "wakeup",
+        .args_type  = "",
+        .params     = "",
+        .help       = "wakeup guest from suspend",
+        .mhandler.cmd = hmp_wakeup,
+    },
+
+STEXI
+@item wakeup
+@findex wakeup
+Wakeup guest from suspend.
+ETEXI
+
+    {
         .name       = "gdbserver",
         .args_type  = "device:s?",
         .params     = "[device]",
diff --git a/hmp.c b/hmp.c
index e7659d5..1a14684 100644
--- a/hmp.c
+++ b/hmp.c
@@ -594,6 +594,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
     }
 }
 
+void hmp_wakeup(Monitor *mon, const QDict *qdict)
+{
+    qmp_wakeup(NULL);
+}
+
 void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
 {
     Error *errp = NULL;
diff --git a/hmp.h b/hmp.h
index 093242d..76eb3df 100644
--- a/hmp.h
+++ b/hmp.h
@@ -40,6 +40,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
 void hmp_memsave(Monitor *mon, const QDict *qdict);
 void hmp_pmemsave(Monitor *mon, const QDict *qdict);
 void hmp_cont(Monitor *mon, const QDict *qdict);
+void hmp_wakeup(Monitor *mon, const QDict *qdict);
 void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
 void hmp_set_link(Monitor *mon, const QDict *qdict);
 void hmp_block_passwd(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index 44cf764..75773d4 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -967,6 +967,17 @@
 { 'command': 'cont' }
 
 ##
+# @wakeup:
+#
+# Wakrup guest from suspend
+#
+# Since:  1.1
+#
+# Returns:  nothing.
+##
+{ 'command': 'wakeup' }
+
+##
 # @inject-nmi:
 #
 # Injects an Non-Maskable Interrupt into all guest's VCPUs.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 7e3f4b9..2c84a7a 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -218,6 +218,27 @@ Example:
 EQMP
 
     {
+        .name       = "wakeup",
+        .args_type  = "",
+        .mhandler.cmd_new = qmp_marshal_input_wakeup,
+    },
+
+SQMP
+wakeup
+------
+
+Wakeup guest from suspend.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "wakeup" }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "system_reset",
         .args_type  = "",
         .mhandler.cmd_new = qmp_marshal_input_system_reset,
diff --git a/qmp.c b/qmp.c
index 5e09b41..f8b1dc7 100644
--- a/qmp.c
+++ b/qmp.c
@@ -158,6 +158,11 @@ void qmp_cont(Error **errp)
     vm_start();
 }
 
+void qmp_wakeup(Error **errp)
+{
+    qemu_system_wakeup_request();
+}
+
 DevicePropertyInfoList *qmp_qom_list(const char *path, Error **errp)
 {
     DeviceState *dev;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSp8-0007EY-6F; Wed, 18 Jan 2012 10:32:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rmr5e-0003wS-JF
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:15:30 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326737723!11281463!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23891 invoked from network); 16 Jan 2012 18:15:23 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 18:15:23 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GIFLrr026547
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 13:15:22 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GIFH4A026361; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 5147440C6C; Mon, 16 Jan 2012 19:15:16 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:12 +0100
Message-Id: <1326737715-9867-4-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 3/6] suspend: add wakeup monitor command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds a wakeup monitor command which will simply wake up
suspended guests.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hmp-commands.hx  |   14 ++++++++++++++
 hmp.c            |    5 +++++
 hmp.h            |    1 +
 qapi-schema.json |   11 +++++++++++
 qmp-commands.hx  |   21 +++++++++++++++++++++
 qmp.c            |    5 +++++
 6 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index a586498..c62871a 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -313,6 +313,20 @@ Resume emulation.
 ETEXI
 
     {
+        .name       = "wakeup",
+        .args_type  = "",
+        .params     = "",
+        .help       = "wakeup guest from suspend",
+        .mhandler.cmd = hmp_wakeup,
+    },
+
+STEXI
+@item wakeup
+@findex wakeup
+Wakeup guest from suspend.
+ETEXI
+
+    {
         .name       = "gdbserver",
         .args_type  = "device:s?",
         .params     = "[device]",
diff --git a/hmp.c b/hmp.c
index e7659d5..1a14684 100644
--- a/hmp.c
+++ b/hmp.c
@@ -594,6 +594,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
     }
 }
 
+void hmp_wakeup(Monitor *mon, const QDict *qdict)
+{
+    qmp_wakeup(NULL);
+}
+
 void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
 {
     Error *errp = NULL;
diff --git a/hmp.h b/hmp.h
index 093242d..76eb3df 100644
--- a/hmp.h
+++ b/hmp.h
@@ -40,6 +40,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
 void hmp_memsave(Monitor *mon, const QDict *qdict);
 void hmp_pmemsave(Monitor *mon, const QDict *qdict);
 void hmp_cont(Monitor *mon, const QDict *qdict);
+void hmp_wakeup(Monitor *mon, const QDict *qdict);
 void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
 void hmp_set_link(Monitor *mon, const QDict *qdict);
 void hmp_block_passwd(Monitor *mon, const QDict *qdict);
diff --git a/qapi-schema.json b/qapi-schema.json
index 44cf764..75773d4 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -967,6 +967,17 @@
 { 'command': 'cont' }
 
 ##
+# @wakeup:
+#
+# Wakrup guest from suspend
+#
+# Since:  1.1
+#
+# Returns:  nothing.
+##
+{ 'command': 'wakeup' }
+
+##
 # @inject-nmi:
 #
 # Injects an Non-Maskable Interrupt into all guest's VCPUs.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 7e3f4b9..2c84a7a 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -218,6 +218,27 @@ Example:
 EQMP
 
     {
+        .name       = "wakeup",
+        .args_type  = "",
+        .mhandler.cmd_new = qmp_marshal_input_wakeup,
+    },
+
+SQMP
+wakeup
+------
+
+Wakeup guest from suspend.
+
+Arguments: None.
+
+Example:
+
+-> { "execute": "wakeup" }
+<- { "return": {} }
+
+EQMP
+
+    {
         .name       = "system_reset",
         .args_type  = "",
         .mhandler.cmd_new = qmp_marshal_input_system_reset,
diff --git a/qmp.c b/qmp.c
index 5e09b41..f8b1dc7 100644
--- a/qmp.c
+++ b/qmp.c
@@ -158,6 +158,11 @@ void qmp_cont(Error **errp)
     vm_start();
 }
 
+void qmp_wakeup(Error **errp)
+{
+    qemu_system_wakeup_request();
+}
+
 DevicePropertyInfoList *qmp_qom_list(const char *path, Error **errp)
 {
     DeviceState *dev;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSp8-0007En-NE; Wed, 18 Jan 2012 10:32:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rmr5l-0003wa-2g
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:15:37 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326737729!11123444!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26368 invoked from network); 16 Jan 2012 18:15:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	16 Jan 2012 18:15:30 -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 q0GIFTSf026603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 13:15:29 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0GIFP96031377; Mon, 16 Jan 2012 13:15:27 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 6BED340BCD; Mon, 16 Jan 2012 19:15:16 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:14 +0100
Message-Id: <1326737715-9867-6-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 5/6] suspend: make serial ports wakeup the
	guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a 'wakeup' property to the serial port.  It is off by default.  When
enabled any incoming character on the serial line will wake up the
guest.  Useful for guests which have a serial console configured.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/serial.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/serial.c b/hw/serial.c
index d35c7a9..96ac7c1 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -139,6 +139,7 @@ struct SerialState {
     int it_shift;
     int baudbase;
     int tsr_retry;
+    uint32_t wakeup;
 
     uint64_t last_xmit_ts;              /* Time when the last byte was successfully sent out of the tsr */
     SerialFIFO recv_fifo;
@@ -635,6 +636,10 @@ static int serial_can_receive1(void *opaque)
 static void serial_receive1(void *opaque, const uint8_t *buf, int size)
 {
     SerialState *s = opaque;
+
+    if (s->wakeup) {
+        qemu_system_wakeup_request();
+    }
     if(s->fcr & UART_FCR_FE) {
         int i;
         for (i = 0; i < size; i++) {
@@ -889,6 +894,7 @@ static ISADeviceInfo serial_isa_info = {
         DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
         DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
         DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
+        DEFINE_PROP_UINT32("wakeup", ISASerialState, state.wakeup, 0),
         DEFINE_PROP_END_OF_LIST(),
     },
 };
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnSp8-0007En-NE; Wed, 18 Jan 2012 10:32:58 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1Rmr5l-0003wa-2g
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:15:37 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326737729!11123444!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26368 invoked from network); 16 Jan 2012 18:15:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-182.messagelabs.com with SMTP;
	16 Jan 2012 18:15:30 -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 q0GIFTSf026603
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 13:15:29 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0GIFP96031377; Mon, 16 Jan 2012 13:15:27 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 6BED340BCD; Mon, 16 Jan 2012 19:15:16 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:14 +0100
Message-Id: <1326737715-9867-6-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 5/6] suspend: make serial ports wakeup the
	guest.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Add a 'wakeup' property to the serial port.  It is off by default.  When
enabled any incoming character on the serial line will wake up the
guest.  Useful for guests which have a serial console configured.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/serial.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/serial.c b/hw/serial.c
index d35c7a9..96ac7c1 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -139,6 +139,7 @@ struct SerialState {
     int it_shift;
     int baudbase;
     int tsr_retry;
+    uint32_t wakeup;
 
     uint64_t last_xmit_ts;              /* Time when the last byte was successfully sent out of the tsr */
     SerialFIFO recv_fifo;
@@ -635,6 +636,10 @@ static int serial_can_receive1(void *opaque)
 static void serial_receive1(void *opaque, const uint8_t *buf, int size)
 {
     SerialState *s = opaque;
+
+    if (s->wakeup) {
+        qemu_system_wakeup_request();
+    }
     if(s->fcr & UART_FCR_FE) {
         int i;
         for (i = 0; i < size; i++) {
@@ -889,6 +894,7 @@ static ISADeviceInfo serial_isa_info = {
         DEFINE_PROP_HEX32("iobase", ISASerialState, iobase,  -1),
         DEFINE_PROP_UINT32("irq",   ISASerialState, isairq,  -1),
         DEFINE_PROP_CHR("chardev",  ISASerialState, state.chr),
+        DEFINE_PROP_UINT32("wakeup", ISASerialState, state.wakeup, 0),
         DEFINE_PROP_END_OF_LIST(),
     },
 };
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpM-0007J4-EJ; Wed, 18 Jan 2012 10:33:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnDu9-0007Hf-Cx
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:37:09 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326825385!60619095!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDM0ODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29017 invoked from network); 17 Jan 2012 18:36:26 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 18:36:26 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 00:07:04 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 00:06:33 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HIaXTI4305052
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:06:33 +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
	q0HIaVTD007428
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 05:36:33 +1100
Received: from oc5400248562.ibm.com ([9.124.215.78])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HIaRK7007247; Wed, 18 Jan 2012 05:36:27 +1100
Message-ID: <4F15BFAE.7060500@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 00:06:30 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
In-Reply-To: <1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
x-cbid: 12011718-4790-0000-0000-000000E9B2EA
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 11:09 PM, Alexander Graf wrote:
>
> On 17.01.2012, at 18:27, Raghavendra K T wrote:
>
>> On 01/17/2012 12:12 AM, Alexander Graf wrote:
>>>
>>> On 16.01.2012, at 19:38, Raghavendra K T wrote:
>>>
>>>> On 01/16/2012 07:53 PM, Alexander Graf wrote:
>>>>>
>>>>> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>>>>>
>>>>>> * Alexander Graf<agraf@suse.de>    [2012-01-16 04:57:45]:
>>>>>>
>>>>>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>>>>>
>>>>>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>>>>>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>>>>>> some workload(s)?
>>>>>
>>>>> Yup
>>>>>
>>>>>>
>>>>>> In some sense, the 1x overcommitcase results posted does measure the overhead
>>>>>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>>>>>> kernbench ..
>>>>>>
>>>>>>> Result for Non PLE machine :
>>>>>>> ============================
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>>> Kernbench:
>>>>>>>                BASE                    BASE+patch
>>>>>
>>>>> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>>>>>
>>>>>
>>>>> Alex
>>>>
>>>> Sorry for confusion, I think I was little imprecise on the BASE.
>>>>
>>>> The BASE is pre 3.2.0 + Jeremy's following patches:
>>>> xadd (https://lkml.org/lkml/2011/10/4/328)
>>>> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
>>>> So this would have ticketlock cleanups from Jeremy and
>>>> CONFIG_PARAVIRT_SPINLOCKS=y
>>>>
>>>> BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
>>>> series and CONFIG_PARAVIRT_SPINLOCKS=y
>>>>
>>>> In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.
>>>>
>>>> So let,
>>>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>>>> B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
>>>> C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = n
>>>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>>>
>>>> is it performance of A vs E ? (currently C vs E)
>>>
>>> Since D and E only matter with KVM in use, yes, I'm mostly interested in A, B and C :).
>>>
>>>
>>> Alex
>>>
>>>
>> setup :
>> Native: IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8 core , 64GB RAM, (16 cpu online)
>>
>> Guest : Single guest with 8 VCPU 4GB Ram.
>> benchmark : kernbench -f -H -M -o 20
>>
>> Here is the result :
>> Native Run
>> ============
>> case A               case B             %improvement   case C  %improvement
>> 56.1917 (2.57125)    56.035 (2.02439)   0.278867       56.27 (2.40401)   -0.139344	
>
> This looks a lot like statistical derivation. How often did you execute the test case? Did you make sure to have a clean base state every time?
>
> Maybe it'd be a good idea to create a small in-kernel microbenchmark with a couple threads that take spinlocks, then do work for a specified number of cycles, then release them again and start anew. At the end of it, we can check how long the whole thing took for n runs. That would enable us to measure the worst case scenario.
>

It was a quick test.  two iteration of kernbench (=6runs) and had 
ensured cache is cleared.

echo "1" > /proc/sys/vm/drop_caches
ccache -C. Yes may be I can run test as you mentioned..

>>
>> Guest Run
>> ============
>> case A               case B             %improvement   case C  %improvement
>> 166.999 (15.7613)    161.876 (14.4874) 	3.06768        161.24 (12.6497)  3.44852
>
> Is this the same machine? Why is the guest 3x slower?
Yes non - ple machine but with all 16 cpus online. 3x slower you meant 
case A is slower (pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n) ?

>
>
> Alex
>
>>
>> We do not see much overhead in native run with CONFIG_PARAVIRT_SPINLOCKS = y
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpM-0007J4-EJ; Wed, 18 Jan 2012 10:33:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnDu9-0007Hf-Cx
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:37:09 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326825385!60619095!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDM0ODQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29017 invoked from network); 17 Jan 2012 18:36:26 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 18:36:26 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 00:07:04 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 00:06:33 +0530
Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HIaXTI4305052
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:06:33 +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
	q0HIaVTD007428
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 05:36:33 +1100
Received: from oc5400248562.ibm.com ([9.124.215.78])
	by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HIaRK7007247; Wed, 18 Jan 2012 05:36:27 +1100
Message-ID: <4F15BFAE.7060500@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 00:06:30 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
In-Reply-To: <1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
x-cbid: 12011718-4790-0000-0000-000000E9B2EA
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 11:09 PM, Alexander Graf wrote:
>
> On 17.01.2012, at 18:27, Raghavendra K T wrote:
>
>> On 01/17/2012 12:12 AM, Alexander Graf wrote:
>>>
>>> On 16.01.2012, at 19:38, Raghavendra K T wrote:
>>>
>>>> On 01/16/2012 07:53 PM, Alexander Graf wrote:
>>>>>
>>>>> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>>>>>
>>>>>> * Alexander Graf<agraf@suse.de>    [2012-01-16 04:57:45]:
>>>>>>
>>>>>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>>>>>
>>>>>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>>>>>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>>>>>> some workload(s)?
>>>>>
>>>>> Yup
>>>>>
>>>>>>
>>>>>> In some sense, the 1x overcommitcase results posted does measure the overhead
>>>>>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>>>>>> kernbench ..
>>>>>>
>>>>>>> Result for Non PLE machine :
>>>>>>> ============================
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>>> Kernbench:
>>>>>>>                BASE                    BASE+patch
>>>>>
>>>>> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>>>>>
>>>>>
>>>>> Alex
>>>>
>>>> Sorry for confusion, I think I was little imprecise on the BASE.
>>>>
>>>> The BASE is pre 3.2.0 + Jeremy's following patches:
>>>> xadd (https://lkml.org/lkml/2011/10/4/328)
>>>> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
>>>> So this would have ticketlock cleanups from Jeremy and
>>>> CONFIG_PARAVIRT_SPINLOCKS=y
>>>>
>>>> BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
>>>> series and CONFIG_PARAVIRT_SPINLOCKS=y
>>>>
>>>> In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.
>>>>
>>>> So let,
>>>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>>>> B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
>>>> C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = n
>>>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>>>
>>>> is it performance of A vs E ? (currently C vs E)
>>>
>>> Since D and E only matter with KVM in use, yes, I'm mostly interested in A, B and C :).
>>>
>>>
>>> Alex
>>>
>>>
>> setup :
>> Native: IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8 core , 64GB RAM, (16 cpu online)
>>
>> Guest : Single guest with 8 VCPU 4GB Ram.
>> benchmark : kernbench -f -H -M -o 20
>>
>> Here is the result :
>> Native Run
>> ============
>> case A               case B             %improvement   case C  %improvement
>> 56.1917 (2.57125)    56.035 (2.02439)   0.278867       56.27 (2.40401)   -0.139344	
>
> This looks a lot like statistical derivation. How often did you execute the test case? Did you make sure to have a clean base state every time?
>
> Maybe it'd be a good idea to create a small in-kernel microbenchmark with a couple threads that take spinlocks, then do work for a specified number of cycles, then release them again and start anew. At the end of it, we can check how long the whole thing took for n runs. That would enable us to measure the worst case scenario.
>

It was a quick test.  two iteration of kernbench (=6runs) and had 
ensured cache is cleared.

echo "1" > /proc/sys/vm/drop_caches
ccache -C. Yes may be I can run test as you mentioned..

>>
>> Guest Run
>> ============
>> case A               case B             %improvement   case C  %improvement
>> 166.999 (15.7613)    161.876 (14.4874) 	3.06768        161.24 (12.6497)  3.44852
>
> Is this the same machine? Why is the guest 3x slower?
Yes non - ple machine but with all 16 cpus online. 3x slower you meant 
case A is slower (pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n) ?

>
>
> Alex
>
>>
>> We do not see much overhead in native run with CONFIG_PARAVIRT_SPINLOCKS = y
>>
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpO-0007Jk-Hy; Wed, 18 Jan 2012 10:33:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnLFi-00037E-Ha
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 02:27:54 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326853540!48983497!1
X-Originating-IP: [202.81.31.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MCA9PiAyNjk4NjY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6185 invoked from network); 18 Jan 2012 02:25:43 -0000
Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 02:25:43 -0000
Received: from /spool/local
	by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 02:23:44 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp07.au.ibm.com ([202.81.31.204]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 02:23:38 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0I2RM8A5259278
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 13:27:24 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0I2RJr1002854
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 13:27:22 +1100
Received: from oc5400248562.ibm.com ([9.79.222.195])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0I2RA1t002543; Wed, 18 Jan 2012 13:27:10 +1100
Message-ID: <4F162E00.3040900@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 07:57:12 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Dave Hansen <dave@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
	<4F15EEE6.5020207@linux.vnet.ibm.com>
In-Reply-To: <4F15EEE6.5020207@linux.vnet.ibm.com>
x-cbid: 12011716-0260-0000-0000-00000064BB72
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 03:27 AM, Dave Hansen wrote:
> On 01/17/2012 10:36 AM, Raghavendra K T wrote:
>> It was a quick test.  two iteration of kernbench (=6runs) and had
>> ensured cache is cleared.
>>
>> echo "1">  /proc/sys/vm/drop_caches
>> ccache -C. Yes may be I can run test as you mentioned..
>
> echo 3>  /proc/sys/vm/drop_caches
>
> is better.  1 will only do page cache, but 3 also does dentries fwiw.
>

yes. that needs to be used.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpO-0007Jk-Hy; Wed, 18 Jan 2012 10:33:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnLFi-00037E-Ha
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 02:27:54 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326853540!48983497!1
X-Originating-IP: [202.81.31.140]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MCA9PiAyNjk4NjY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6185 invoked from network); 18 Jan 2012 02:25:43 -0000
Received: from e23smtp07.au.ibm.com (HELO e23smtp07.au.ibm.com) (202.81.31.140)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 02:25:43 -0000
Received: from /spool/local
	by e23smtp07.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 02:23:44 +1000
Received: from d23relay03.au.ibm.com ([202.81.31.245])
	by e23smtp07.au.ibm.com ([202.81.31.204]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 02:23:38 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])
	by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0I2RM8A5259278
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 13:27:24 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	q0I2RJr1002854
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 13:27:22 +1100
Received: from oc5400248562.ibm.com ([9.79.222.195])
	by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0I2RA1t002543; Wed, 18 Jan 2012 13:27:10 +1100
Message-ID: <4F162E00.3040900@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 07:57:12 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Dave Hansen <dave@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
	<4F15EEE6.5020207@linux.vnet.ibm.com>
In-Reply-To: <4F15EEE6.5020207@linux.vnet.ibm.com>
x-cbid: 12011716-0260-0000-0000-00000064BB72
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 03:27 AM, Dave Hansen wrote:
> On 01/17/2012 10:36 AM, Raghavendra K T wrote:
>> It was a quick test.  two iteration of kernbench (=6runs) and had
>> ensured cache is cleared.
>>
>> echo "1">  /proc/sys/vm/drop_caches
>> ccache -C. Yes may be I can run test as you mentioned..
>
> echo 3>  /proc/sys/vm/drop_caches
>
> is better.  1 will only do page cache, but 3 also does dentries fwiw.
>

yes. that needs to be used.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpI-0007He-BL; Wed, 18 Jan 2012 10:33:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rn8ph-0001Az-Hk
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:12:13 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326805796!48899794!1
X-Originating-IP: [32.97.110.154]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1NCA9PiAzMDQyNDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6478 invoked from network); 17 Jan 2012 13:09:57 -0000
Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 13:09:57 -0000
Received: from /spool/local
	by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 06:12:04 -0700
Received: from d03dlp02.boulder.ibm.com (9.17.202.178)
	by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 06:11:28 -0700
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com
	[9.17.195.226])
	by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 2AA633E40054
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 06:11:27 -0700 (MST)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HDBIdH040510
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 06:11:18 -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 q0HDBE9A030403
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 06:11:17 -0700
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.122.216.170])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0HDB49G029154; Tue, 17 Jan 2012 06:11:05 -0700
Date: Tue, 17 Jan 2012 18:41:03 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Message-ID: <20120117131103.GD30398@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117125126.GQ2167@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011713-3352-0000-0000-000001F7A094
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Gleb Natapov <gleb@redhat.com> [2012-01-17 14:51:26]:

> On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote:
> > * Gleb Natapov <gleb@redhat.com> [2012-01-17 11:14:13]:
> > 
> > > > The problem case I was thinking of was when guest VCPU would have issued
> > > > HLT with interrupts disabled. I guess one option is to inject an NMI,
> > > > and have the guest kernel NMI handler recognize this and make
> > > > adjustments such that the vcpu avoids going back to HLT instruction.
> > > > 
> > > Just kick vcpu out of a guest mode and adjust rip to point after HLT on
> > > next re-entry. Don't forget to call vmx_clear_hlt().
> > 
> > Looks bit hackish to me compared to having another hypercall to yield!
> > 
> Do not see anything hackish about it. But what you described above (the
> part I replied to) is not another hypercall, but yet another NMI source
> and special handling in a guest.

True, which I didn't exactly like and hence was suggesting we use
another hypercall to let spinning vcpu sleep.

> So what hypercall do you mean?

The hypercall is described below:

> > > > Having another hypercall to do yield/sleep (rather than effecting that
> > > > via HLT) seems like an alternate clean solution here ..

and was implemented in an earlier version of this patch (v2) as
KVM_HC_WAIT_FOR_KICK hypercall:

https://lkml.org/lkml/2011/10/23/211

Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
hypervisor vs assuming that because of a trapped HLT instruction (which
will anyway won't work when yield_on_hlt=0).

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpE-0007Gg-VR; Wed, 18 Jan 2012 10:33:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RmwwM-00007q-Tj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 00:30:19 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326760210!9408542!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18176 invoked from network); 17 Jan 2012 00:30:11 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 00:30:11 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 7BF7A93B5;
	Mon, 16 Jan 2012 16:30:07 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 3B26120B2C;
	Tue, 17 Jan 2012 11:30:04 +1100 (EST)
Message-ID: <4F14C10C.3010303@goop.org>
Date: Tue, 17 Jan 2012 11:30:04 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
	<0B6BF918-45C7-45C6-AAA4-FB73EFAB9FDB@suse.de>
In-Reply-To: <0B6BF918-45C7-45C6-AAA4-FB73EFAB9FDB@suse.de>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 09:24 PM, Alexander Graf wrote:
> This is true in case you're spinning. If on overcommit spinlocks would
> instead of spin just yield(), we wouldn't have any vcpu running that's
> just waiting for a late ticket.

Yes, but the reality is that most spinlocks are held for a short period
of time and there's a low likelihood of being preempted while within a
spinlock critical section.  Therefore if someone else tries to get the
spinlock and there's contention, it's always worth spinning for a little
while because the lock will likely become free soon.

At least that's the case if the lock has low contention (shallow queue
depth and not in slow state).  Again, maybe it makes sense to never spin
for deep queues or already slowstate locks.

> We still have an issue finding the point in time when a vcpu could run again, which is what this whole series is about. My point above was that instead of doing a count loop, we could just do the normal spin dance and set the threshold to when we enable the magic to have another spin lock notify us in the CPU. That way we
>
>   * don't change the uncontended case

I don't follow you.  What do you mean by "the normal spin dance"?  What
do you mean by "have another spinlock notify us in the CPU"?  Don't
change which uncontended case?  Do you mean in the locking path?  Or the
unlock path?  Or both?

>   * can set the threshold on the host, which knows how contended the system is

Hm, I'm not convinced that knowing how contended the system is is all
that useful overall.  What's important is how contended a particular
lock is, and what state the current holder is in.  If it's not currently
running, then knowing the overall system contention would give you some
idea about how long you need to wait for it to be rescheduled, but
that's getting pretty indirect.

I think the "slowpath if preempted while spinning" idea I mentioned in
the other mail is probably worth following up, since that give specific
actionable information to the guest from the hypervisor.  But lots of
caveats.

[[
A possible mechanism:

  * register ranges of [er]ips with the hypervisor
  * each range is paired with a "resched handler block"
  * if vcpu is preempted within such a range, make sure it is
    rescheduled in the resched handler block

This is obviously akin to the exception mechanism, but it is partially
implemented by the hypervisor.  It allows the spinlock code to be
unchanged from native, but make use of a resched rather than an explicit
counter to determine when to slowpath the lock.  And it's a nice general
mechanism that could be potentially useful elsewhere.

Unfortunately, it doesn't change the unlock path at all; it still needs
to explicitly test if a VCPU needs to be kicked on unlock.
]]


> And since we control what spin locks look like, we can for example always keep the pointer to it in a specific register so that we can handle pv_lock_ops.lock_spinning() inside there and fetch all the information we need from our pt_regs.

You've left a pile of parts of an idea lying around, but I'm not sure
what shape you intend it to be.

>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.
>> The whole point of the pv-ticketlock work is to keep the pvops hooks out of the locking fast path, so that the calls are only made on the slow path - that is, when spinning too long on a contended lock, and when releasing a lock that's in a "slow" state.  In the fast path case of no contention, there are no pvops, and the executed code path is almost identical to native.
> You're still changing a tight loop that does nothing (CPU detects it and saves power) into something that performs calculations.

It still has a "pause" instruction in that loop, so that CPU mechanism
will still come into play.  "pause" doesn't directly "save power"; it's
more about making sure that memory dependence cycles are broken and that
two competing threads will make similar progress.  Besides I'm not sure
adding a dec+test to a loop that's already got a memory read and compare
in it is adding much in the way of "calculations".

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpI-0007He-BL; Wed, 18 Jan 2012 10:33:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1Rn8ph-0001Az-Hk
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:12:13 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326805796!48899794!1
X-Originating-IP: [32.97.110.154]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1NCA9PiAzMDQyNDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6478 invoked from network); 17 Jan 2012 13:09:57 -0000
Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 13:09:57 -0000
Received: from /spool/local
	by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 06:12:04 -0700
Received: from d03dlp02.boulder.ibm.com (9.17.202.178)
	by e36.co.us.ibm.com (192.168.1.136) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 06:11:28 -0700
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com
	[9.17.195.226])
	by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 2AA633E40054
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 06:11:27 -0700 (MST)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HDBIdH040510
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 06:11:18 -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 q0HDBE9A030403
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 06:11:17 -0700
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.122.216.170])
	by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0HDB49G029154; Tue, 17 Jan 2012 06:11:05 -0700
Date: Tue, 17 Jan 2012 18:41:03 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Message-ID: <20120117131103.GD30398@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117125126.GQ2167@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011713-3352-0000-0000-000001F7A094
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Gleb Natapov <gleb@redhat.com> [2012-01-17 14:51:26]:

> On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote:
> > * Gleb Natapov <gleb@redhat.com> [2012-01-17 11:14:13]:
> > 
> > > > The problem case I was thinking of was when guest VCPU would have issued
> > > > HLT with interrupts disabled. I guess one option is to inject an NMI,
> > > > and have the guest kernel NMI handler recognize this and make
> > > > adjustments such that the vcpu avoids going back to HLT instruction.
> > > > 
> > > Just kick vcpu out of a guest mode and adjust rip to point after HLT on
> > > next re-entry. Don't forget to call vmx_clear_hlt().
> > 
> > Looks bit hackish to me compared to having another hypercall to yield!
> > 
> Do not see anything hackish about it. But what you described above (the
> part I replied to) is not another hypercall, but yet another NMI source
> and special handling in a guest.

True, which I didn't exactly like and hence was suggesting we use
another hypercall to let spinning vcpu sleep.

> So what hypercall do you mean?

The hypercall is described below:

> > > > Having another hypercall to do yield/sleep (rather than effecting that
> > > > via HLT) seems like an alternate clean solution here ..

and was implemented in an earlier version of this patch (v2) as
KVM_HC_WAIT_FOR_KICK hypercall:

https://lkml.org/lkml/2011/10/23/211

Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
hypervisor vs assuming that because of a trapped HLT instruction (which
will anyway won't work when yield_on_hlt=0).

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpE-0007Gg-VR; Wed, 18 Jan 2012 10:33:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RmwwM-00007q-Tj
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 00:30:19 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326760210!9408542!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18176 invoked from network); 17 Jan 2012 00:30:11 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 00:30:11 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 7BF7A93B5;
	Mon, 16 Jan 2012 16:30:07 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 3B26120B2C;
	Tue, 17 Jan 2012 11:30:04 +1100 (EST)
Message-ID: <4F14C10C.3010303@goop.org>
Date: Tue, 17 Jan 2012 11:30:04 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
	<0B6BF918-45C7-45C6-AAA4-FB73EFAB9FDB@suse.de>
In-Reply-To: <0B6BF918-45C7-45C6-AAA4-FB73EFAB9FDB@suse.de>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 09:24 PM, Alexander Graf wrote:
> This is true in case you're spinning. If on overcommit spinlocks would
> instead of spin just yield(), we wouldn't have any vcpu running that's
> just waiting for a late ticket.

Yes, but the reality is that most spinlocks are held for a short period
of time and there's a low likelihood of being preempted while within a
spinlock critical section.  Therefore if someone else tries to get the
spinlock and there's contention, it's always worth spinning for a little
while because the lock will likely become free soon.

At least that's the case if the lock has low contention (shallow queue
depth and not in slow state).  Again, maybe it makes sense to never spin
for deep queues or already slowstate locks.

> We still have an issue finding the point in time when a vcpu could run again, which is what this whole series is about. My point above was that instead of doing a count loop, we could just do the normal spin dance and set the threshold to when we enable the magic to have another spin lock notify us in the CPU. That way we
>
>   * don't change the uncontended case

I don't follow you.  What do you mean by "the normal spin dance"?  What
do you mean by "have another spinlock notify us in the CPU"?  Don't
change which uncontended case?  Do you mean in the locking path?  Or the
unlock path?  Or both?

>   * can set the threshold on the host, which knows how contended the system is

Hm, I'm not convinced that knowing how contended the system is is all
that useful overall.  What's important is how contended a particular
lock is, and what state the current holder is in.  If it's not currently
running, then knowing the overall system contention would give you some
idea about how long you need to wait for it to be rescheduled, but
that's getting pretty indirect.

I think the "slowpath if preempted while spinning" idea I mentioned in
the other mail is probably worth following up, since that give specific
actionable information to the guest from the hypervisor.  But lots of
caveats.

[[
A possible mechanism:

  * register ranges of [er]ips with the hypervisor
  * each range is paired with a "resched handler block"
  * if vcpu is preempted within such a range, make sure it is
    rescheduled in the resched handler block

This is obviously akin to the exception mechanism, but it is partially
implemented by the hypervisor.  It allows the spinlock code to be
unchanged from native, but make use of a resched rather than an explicit
counter to determine when to slowpath the lock.  And it's a nice general
mechanism that could be potentially useful elsewhere.

Unfortunately, it doesn't change the unlock path at all; it still needs
to explicitly test if a VCPU needs to be kicked on unlock.
]]


> And since we control what spin locks look like, we can for example always keep the pointer to it in a specific register so that we can handle pv_lock_ops.lock_spinning() inside there and fetch all the information we need from our pt_regs.

You've left a pile of parts of an idea lying around, but I'm not sure
what shape you intend it to be.

>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal? Last time I checked, enabling all the PV ops did incur significant slowdown which is why I went though the work to split the individual pv ops features up to only enable a few for KVM guests.
>> The whole point of the pv-ticketlock work is to keep the pvops hooks out of the locking fast path, so that the calls are only made on the slow path - that is, when spinning too long on a contended lock, and when releasing a lock that's in a "slow" state.  In the fast path case of no contention, there are no pvops, and the executed code path is almost identical to native.
> You're still changing a tight loop that does nothing (CPU detects it and saves power) into something that performs calculations.

It still has a "pause" instruction in that loop, so that CPU mechanism
will still come into play.  "pause" doesn't directly "save power"; it's
more about making sure that memory dependence cycles are broken and that
two competing threads will make similar progress.  Besides I'm not sure
adding a dec+test to a loop that's already got a memory read and compare
in it is adding much in the way of "calculations".

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpL-0007Ii-EZ; Wed, 18 Jan 2012 10:33:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnCpg-0004zr-5H
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:28:28 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326821259!50471733!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxNTI0MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10801 invoked from network); 17 Jan 2012 17:27:41 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 17:27:41 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Jan 2012 22:58:22 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 22:58:16 +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
	q0HHSFlW3059732
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 22:58:15 +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
	q0HHS6kG011887
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 04:28:14 +1100
Received: from oc5400248562.ibm.com ([9.124.215.78])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HHRtdC011085; Wed, 18 Jan 2012 04:27:58 +1100
Message-ID: <4F15AF9E.9000907@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 22:57:58 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
In-Reply-To: <E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
x-cbid: 12011717-5564-0000-0000-000000FDB9A3
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 12:12 AM, Alexander Graf wrote:
>
> On 16.01.2012, at 19:38, Raghavendra K T wrote:
>
>> On 01/16/2012 07:53 PM, Alexander Graf wrote:
>>>
>>> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>>>
>>>> * Alexander Graf<agraf@suse.de>   [2012-01-16 04:57:45]:
>>>>
>>>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>>>
>>>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>>>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>>>> some workload(s)?
>>>
>>> Yup
>>>
>>>>
>>>> In some sense, the 1x overcommitcase results posted does measure the overhead
>>>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>>>> kernbench ..
>>>>
>>>>> Result for Non PLE machine :
>>>>> ============================
>>>>
>>>> [snip]
>>>>
>>>>> Kernbench:
>>>>>                BASE                    BASE+patch
>>>
>>> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>>>
>>>
>>> Alex
>>
>> Sorry for confusion, I think I was little imprecise on the BASE.
>>
>> The BASE is pre 3.2.0 + Jeremy's following patches:
>> xadd (https://lkml.org/lkml/2011/10/4/328)
>> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
>> So this would have ticketlock cleanups from Jeremy and
>> CONFIG_PARAVIRT_SPINLOCKS=y
>>
>> BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
>> series and CONFIG_PARAVIRT_SPINLOCKS=y
>>
>> In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.
>>
>> So let,
>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>> B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
>> C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = n
>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>
>> is it performance of A vs E ? (currently C vs E)
>
> Since D and E only matter with KVM in use, yes, I'm mostly interested in A, B and C :).
>
>
> Alex
>
>
setup :
Native: IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8 core 
, 64GB RAM, (16 cpu online)

Guest : Single guest with 8 VCPU 4GB Ram.
benchmark : kernbench -f -H -M -o 20

Here is the result :
Native Run
============
case A               case B             %improvement   case C 
  %improvement
56.1917 (2.57125)    56.035 (2.02439)   0.278867       56.27 (2.40401) 
   -0.139344	

Guest Run
============
case A               case B             %improvement   case C 
  %improvement
166.999 (15.7613)    161.876 (14.4874) 	3.06768        161.24 (12.6497) 
  3.44852

We do not see much overhead in native run with CONFIG_PARAVIRT_SPINLOCKS = y


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpL-0007Ii-EZ; Wed, 18 Jan 2012 10:33:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnCpg-0004zr-5H
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:28:28 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326821259!50471733!1
X-Originating-IP: [122.248.162.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuNCA9PiAxNTI0MzI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10801 invoked from network); 17 Jan 2012 17:27:41 -0000
Received: from e28smtp04.in.ibm.com (HELO e28smtp04.in.ibm.com) (122.248.162.4)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 17:27:41 -0000
Received: from /spool/local
	by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Tue, 17 Jan 2012 22:58:22 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp04.in.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 22:58:16 +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
	q0HHSFlW3059732
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 22:58:15 +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
	q0HHS6kG011887
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 04:28:14 +1100
Received: from oc5400248562.ibm.com ([9.124.215.78])
	by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HHRtdC011085; Wed, 18 Jan 2012 04:27:58 +1100
Message-ID: <4F15AF9E.9000907@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 22:57:58 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
In-Reply-To: <E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
x-cbid: 12011717-5564-0000-0000-000000FDB9A3
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 12:12 AM, Alexander Graf wrote:
>
> On 16.01.2012, at 19:38, Raghavendra K T wrote:
>
>> On 01/16/2012 07:53 PM, Alexander Graf wrote:
>>>
>>> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>>>
>>>> * Alexander Graf<agraf@suse.de>   [2012-01-16 04:57:45]:
>>>>
>>>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>>>
>>>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>>>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>>>> some workload(s)?
>>>
>>> Yup
>>>
>>>>
>>>> In some sense, the 1x overcommitcase results posted does measure the overhead
>>>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>>>> kernbench ..
>>>>
>>>>> Result for Non PLE machine :
>>>>> ============================
>>>>
>>>> [snip]
>>>>
>>>>> Kernbench:
>>>>>                BASE                    BASE+patch
>>>
>>> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>>>
>>>
>>> Alex
>>
>> Sorry for confusion, I think I was little imprecise on the BASE.
>>
>> The BASE is pre 3.2.0 + Jeremy's following patches:
>> xadd (https://lkml.org/lkml/2011/10/4/328)
>> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
>> So this would have ticketlock cleanups from Jeremy and
>> CONFIG_PARAVIRT_SPINLOCKS=y
>>
>> BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
>> series and CONFIG_PARAVIRT_SPINLOCKS=y
>>
>> In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.
>>
>> So let,
>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>> B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
>> C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = n
>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>
>> is it performance of A vs E ? (currently C vs E)
>
> Since D and E only matter with KVM in use, yes, I'm mostly interested in A, B and C :).
>
>
> Alex
>
>
setup :
Native: IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8 core 
, 64GB RAM, (16 cpu online)

Guest : Single guest with 8 VCPU 4GB Ram.
benchmark : kernbench -f -H -M -o 20

Here is the result :
Native Run
============
case A               case B             %improvement   case C 
  %improvement
56.1917 (2.57125)    56.035 (2.02439)   0.278867       56.27 (2.40401) 
   -0.139344	

Guest Run
============
case A               case B             %improvement   case C 
  %improvement
166.999 (15.7613)    161.876 (14.4874) 	3.06768        161.24 (12.6497) 
  3.44852

We do not see much overhead in native run with CONFIG_PARAVIRT_SPINLOCKS = y


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp7-0007EE-3J; Wed, 18 Jan 2012 10:32:57 +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 1Rmnqt-0004fn-Hj
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:48:03 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326725276!9339930!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19598 invoked from network); 16 Jan 2012 14:47:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 14:47:57 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GElWDI010856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 09:47:33 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GElHiQ023054; Mon, 16 Jan 2012 09:47:18 -0500
Message-ID: <4F143874.9010307@redhat.com>
Date: Mon, 16 Jan 2012 16:47:16 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<4F13E84C.3010808@redhat.com> <4F1430A2.1080401@linux.vnet.ibm.com>
In-Reply-To: <4F1430A2.1080401@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 04:13 PM, Raghavendra K T wrote:
>> Please drop all of these and replace with tracepoints in the appropriate
>> spots.  Everything else (including the historgram) can be reconstructed
>> the tracepoints in userspace.
>>
>
>
> I think Jeremy pointed that tracepoints use spinlocks and hence debugfs
> is the option.. no ?
>

Yeah, I think you're right.  What a pity.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSp7-0007EE-3J; Wed, 18 Jan 2012 10:32:57 +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 1Rmnqt-0004fn-Hj
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 14:48:03 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326725276!9339930!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19598 invoked from network); 16 Jan 2012 14:47:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 14:47:57 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GElWDI010856
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 09:47:33 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GElHiQ023054; Mon, 16 Jan 2012 09:47:18 -0500
Message-ID: <4F143874.9010307@redhat.com>
Date: Mon, 16 Jan 2012 16:47:16 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<4F13E84C.3010808@redhat.com> <4F1430A2.1080401@linux.vnet.ibm.com>
In-Reply-To: <4F1430A2.1080401@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 04:13 PM, Raghavendra K T wrote:
>> Please drop all of these and replace with tracepoints in the appropriate
>> spots.  Everything else (including the historgram) can be reconstructed
>> the tracepoints in userspace.
>>
>
>
> I think Jeremy pointed that tracepoints use spinlocks and hence debugfs
> is the option.. no ?
>

Yeah, I think you're right.  What a pity.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSp9-0007FG-Kg; Wed, 18 Jan 2012 10:32:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmrH0-00048Y-DO
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:27:14 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326738427!8524869!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5380 invoked from network); 16 Jan 2012 18:27:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 18:27: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 q0GIR4lu030207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 13:27:06 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0GIFHtb031333; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id E30A64024B; Mon, 16 Jan 2012 19:15:15 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:10 +0100
Message-Id: <1326737715-9867-2-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 1/6] suspend: add infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds some infrastructure to handle suspend and resume to
qemu.  First there are two functions to switch state and second there
is a suspend notifier:

 * qemu_system_suspend_request() is supposed to be called when the
   guest asks for being be suspended, for example via ACPI.

 * qemu_system_wakeup_request is supposed to be called on events which
   should wake up the guest.

 * qemu_register_suspend_notifier can be used to register a notifier
   which will be called when the guest is suspended.  Machine types
   and device models can hook in there to modify state if needed.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 sysemu.h |    3 +++
 vl.c     |   28 ++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/sysemu.h b/sysemu.h
index ddef2bb..22470a3 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -39,6 +39,9 @@ void vm_stop(RunState state);
 void vm_stop_force_state(RunState state);
 
 void qemu_system_reset_request(void);
+void qemu_system_suspend_request(void);
+void qemu_register_suspend_notifier(Notifier *notifier);
+void qemu_system_wakeup_request(void);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
 void qemu_system_debug_request(void);
diff --git a/vl.c b/vl.c
index ba55b35..755cd67 100644
--- a/vl.c
+++ b/vl.c
@@ -1282,6 +1282,9 @@ static int shutdown_requested, shutdown_signal = -1;
 static pid_t shutdown_pid;
 static int powerdown_requested;
 static int debug_requested;
+static bool is_suspended;
+static NotifierList suspend_notifiers =
+    NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
 static RunState vmstop_requested = RUN_STATE_MAX;
 
 int qemu_shutdown_requested_get(void)
@@ -1397,6 +1400,31 @@ void qemu_system_reset_request(void)
     qemu_notify_event();
 }
 
+void qemu_system_suspend_request(void)
+{
+    if (is_suspended) {
+        return;
+    }
+    cpu_stop_current();
+    notifier_list_notify(&suspend_notifiers, NULL);
+    is_suspended = true;
+}
+
+void qemu_register_suspend_notifier(Notifier *notifier)
+{
+    notifier_list_add(&suspend_notifiers, notifier);
+}
+
+void qemu_system_wakeup_request(void)
+{
+    if (!is_suspended) {
+        return;
+    }
+    reset_requested = 1;
+    qemu_notify_event();
+    is_suspended = false;
+}
+
 void qemu_system_killed(int signal, pid_t pid)
 {
     shutdown_signal = signal;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpL-0007Ir-Tz; Wed, 18 Jan 2012 10:33:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RnD0I-0005Xa-BL
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:39:26 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326821959!3958429!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21121 invoked from network); 17 Jan 2012 17:39:19 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 17:39:19 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id E889994F51;
	Tue, 17 Jan 2012 18:39:17 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <4F15AF9E.9000907@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 18:39:13 +0100
Message-Id: <1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 18:27, Raghavendra K T wrote:

> On 01/17/2012 12:12 AM, Alexander Graf wrote:
>> 
>> On 16.01.2012, at 19:38, Raghavendra K T wrote:
>> 
>>> On 01/16/2012 07:53 PM, Alexander Graf wrote:
>>>> 
>>>> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>>>> 
>>>>> * Alexander Graf<agraf@suse.de>   [2012-01-16 04:57:45]:
>>>>> 
>>>>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>>>> 
>>>>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>>>>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>>>>> some workload(s)?
>>>> 
>>>> Yup
>>>> 
>>>>> 
>>>>> In some sense, the 1x overcommitcase results posted does measure the overhead
>>>>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>>>>> kernbench ..
>>>>> 
>>>>>> Result for Non PLE machine :
>>>>>> ============================
>>>>> 
>>>>> [snip]
>>>>> 
>>>>>> Kernbench:
>>>>>>               BASE                    BASE+patch
>>>> 
>>>> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>>>> 
>>>> 
>>>> Alex
>>> 
>>> Sorry for confusion, I think I was little imprecise on the BASE.
>>> 
>>> The BASE is pre 3.2.0 + Jeremy's following patches:
>>> xadd (https://lkml.org/lkml/2011/10/4/328)
>>> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
>>> So this would have ticketlock cleanups from Jeremy and
>>> CONFIG_PARAVIRT_SPINLOCKS=y
>>> 
>>> BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
>>> series and CONFIG_PARAVIRT_SPINLOCKS=y
>>> 
>>> In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.
>>> 
>>> So let,
>>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>>> B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
>>> C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = n
>>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>> 
>>> is it performance of A vs E ? (currently C vs E)
>> 
>> Since D and E only matter with KVM in use, yes, I'm mostly interested in A, B and C :).
>> 
>> 
>> Alex
>> 
>> 
> setup :
> Native: IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8 core , 64GB RAM, (16 cpu online)
> 
> Guest : Single guest with 8 VCPU 4GB Ram.
> benchmark : kernbench -f -H -M -o 20
> 
> Here is the result :
> Native Run
> ============
> case A               case B             %improvement   case C  %improvement
> 56.1917 (2.57125)    56.035 (2.02439)   0.278867       56.27 (2.40401)   -0.139344	

This looks a lot like statistical derivation. How often did you execute the test case? Did you make sure to have a clean base state every time?

Maybe it'd be a good idea to create a small in-kernel microbenchmark with a couple threads that take spinlocks, then do work for a specified number of cycles, then release them again and start anew. At the end of it, we can check how long the whole thing took for n runs. That would enable us to measure the worst case scenario.

> 
> Guest Run
> ============
> case A               case B             %improvement   case C  %improvement
> 166.999 (15.7613)    161.876 (14.4874) 	3.06768        161.24 (12.6497)  3.44852

Is this the same machine? Why is the guest 3x slower?


Alex

> 
> We do not see much overhead in native run with CONFIG_PARAVIRT_SPINLOCKS = y
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSp9-0007FG-Kg; Wed, 18 Jan 2012 10:32:59 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmrH0-00048Y-DO
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:27:14 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326738427!8524869!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5380 invoked from network); 16 Jan 2012 18:27:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-3.tower-21.messagelabs.com with SMTP;
	16 Jan 2012 18:27: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 q0GIR4lu030207
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 13:27:06 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0GIFHtb031333; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id E30A64024B; Mon, 16 Jan 2012 19:15:15 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:10 +0100
Message-Id: <1326737715-9867-2-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 1/6] suspend: add infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds some infrastructure to handle suspend and resume to
qemu.  First there are two functions to switch state and second there
is a suspend notifier:

 * qemu_system_suspend_request() is supposed to be called when the
   guest asks for being be suspended, for example via ACPI.

 * qemu_system_wakeup_request is supposed to be called on events which
   should wake up the guest.

 * qemu_register_suspend_notifier can be used to register a notifier
   which will be called when the guest is suspended.  Machine types
   and device models can hook in there to modify state if needed.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 sysemu.h |    3 +++
 vl.c     |   28 ++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/sysemu.h b/sysemu.h
index ddef2bb..22470a3 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -39,6 +39,9 @@ void vm_stop(RunState state);
 void vm_stop_force_state(RunState state);
 
 void qemu_system_reset_request(void);
+void qemu_system_suspend_request(void);
+void qemu_register_suspend_notifier(Notifier *notifier);
+void qemu_system_wakeup_request(void);
 void qemu_system_shutdown_request(void);
 void qemu_system_powerdown_request(void);
 void qemu_system_debug_request(void);
diff --git a/vl.c b/vl.c
index ba55b35..755cd67 100644
--- a/vl.c
+++ b/vl.c
@@ -1282,6 +1282,9 @@ static int shutdown_requested, shutdown_signal = -1;
 static pid_t shutdown_pid;
 static int powerdown_requested;
 static int debug_requested;
+static bool is_suspended;
+static NotifierList suspend_notifiers =
+    NOTIFIER_LIST_INITIALIZER(suspend_notifiers);
 static RunState vmstop_requested = RUN_STATE_MAX;
 
 int qemu_shutdown_requested_get(void)
@@ -1397,6 +1400,31 @@ void qemu_system_reset_request(void)
     qemu_notify_event();
 }
 
+void qemu_system_suspend_request(void)
+{
+    if (is_suspended) {
+        return;
+    }
+    cpu_stop_current();
+    notifier_list_notify(&suspend_notifiers, NULL);
+    is_suspended = true;
+}
+
+void qemu_register_suspend_notifier(Notifier *notifier)
+{
+    notifier_list_add(&suspend_notifiers, notifier);
+}
+
+void qemu_system_wakeup_request(void)
+{
+    if (!is_suspended) {
+        return;
+    }
+    reset_requested = 1;
+    qemu_notify_event();
+    is_suspended = false;
+}
+
 void qemu_system_killed(int signal, pid_t pid)
 {
     shutdown_signal = signal;
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpL-0007Ir-Tz; Wed, 18 Jan 2012 10:33:11 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RnD0I-0005Xa-BL
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 17:39:26 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326821959!3958429!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21121 invoked from network); 17 Jan 2012 17:39:19 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 17 Jan 2012 17:39:19 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id E889994F51;
	Tue, 17 Jan 2012 18:39:17 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <4F15AF9E.9000907@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 18:39:13 +0100
Message-Id: <1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 18:27, Raghavendra K T wrote:

> On 01/17/2012 12:12 AM, Alexander Graf wrote:
>> 
>> On 16.01.2012, at 19:38, Raghavendra K T wrote:
>> 
>>> On 01/16/2012 07:53 PM, Alexander Graf wrote:
>>>> 
>>>> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>>>> 
>>>>> * Alexander Graf<agraf@suse.de>   [2012-01-16 04:57:45]:
>>>>> 
>>>>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>>>> 
>>>>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>>>>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>>>>> some workload(s)?
>>>> 
>>>> Yup
>>>> 
>>>>> 
>>>>> In some sense, the 1x overcommitcase results posted does measure the overhead
>>>>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>>>>> kernbench ..
>>>>> 
>>>>>> Result for Non PLE machine :
>>>>>> ============================
>>>>> 
>>>>> [snip]
>>>>> 
>>>>>> Kernbench:
>>>>>>               BASE                    BASE+patch
>>>> 
>>>> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>>>> 
>>>> 
>>>> Alex
>>> 
>>> Sorry for confusion, I think I was little imprecise on the BASE.
>>> 
>>> The BASE is pre 3.2.0 + Jeremy's following patches:
>>> xadd (https://lkml.org/lkml/2011/10/4/328)
>>> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
>>> So this would have ticketlock cleanups from Jeremy and
>>> CONFIG_PARAVIRT_SPINLOCKS=y
>>> 
>>> BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
>>> series and CONFIG_PARAVIRT_SPINLOCKS=y
>>> 
>>> In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.
>>> 
>>> So let,
>>> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
>>> B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
>>> C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>> D. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = n
>>> E. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = y
>>> 
>>> is it performance of A vs E ? (currently C vs E)
>> 
>> Since D and E only matter with KVM in use, yes, I'm mostly interested in A, B and C :).
>> 
>> 
>> Alex
>> 
>> 
> setup :
> Native: IBM xSeries with Intel(R) Xeon(R) x5570 2.93GHz CPU with 8 core , 64GB RAM, (16 cpu online)
> 
> Guest : Single guest with 8 VCPU 4GB Ram.
> benchmark : kernbench -f -H -M -o 20
> 
> Here is the result :
> Native Run
> ============
> case A               case B             %improvement   case C  %improvement
> 56.1917 (2.57125)    56.035 (2.02439)   0.278867       56.27 (2.40401)   -0.139344	

This looks a lot like statistical derivation. How often did you execute the test case? Did you make sure to have a clean base state every time?

Maybe it'd be a good idea to create a small in-kernel microbenchmark with a couple threads that take spinlocks, then do work for a specified number of cycles, then release them again and start anew. At the end of it, we can check how long the whole thing took for n runs. That would enable us to measure the worst case scenario.

> 
> Guest Run
> ============
> case A               case B             %improvement   case C  %improvement
> 166.999 (15.7613)    161.876 (14.4874) 	3.06768        161.24 (12.6497)  3.44852

Is this the same machine? Why is the guest 3x slower?


Alex

> 
> We do not see much overhead in native run with CONFIG_PARAVIRT_SPINLOCKS = y
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpK-0007IO-Cz; Wed, 18 Jan 2012 10:33:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RnB26-00018J-1Q
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:33:10 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326814383!1666162!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3880 invoked from network); 17 Jan 2012 15:33:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	17 Jan 2012 15:33:03 -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 q0HFWcDX026015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 10:32:39 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0HFWYtN014218; Tue, 17 Jan 2012 10:32:34 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id AC91418D474; Tue, 17 Jan 2012 17:32:33 +0200 (IST)
Date: Tue, 17 Jan 2012 17:32:33 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Message-ID: <20120117153233.GA7911@redhat.com>
References: <4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
	<20120117132051.GR2167@redhat.com>
	<20120117142818.GE30398@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117142818.GE30398@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 07:58:18PM +0530, Srivatsa Vaddagiri wrote:
> * Gleb Natapov <gleb@redhat.com> [2012-01-17 15:20:51]:
> 
> > > Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> > > hypervisor vs assuming that because of a trapped HLT instruction (which
> > > will anyway won't work when yield_on_hlt=0).
> > > 
> > The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the
> > entire time slice no mater what. I do not think disabling yield on HLT
> > is even make sense in CPU oversubscribe scenario.
> 
> Yes, so is there any real use for yield_on_hlt=0? I believe Anthony
> initially added it as a way to implement CPU bandwidth capping for VMs,
> which would ensure that busy VMs don't eat into cycles meant for a idle
> VM. Now that we have proper support in scheduler for CPU bandwidth capping, is 
> there any real world use for yield_on_hlt=0? If not, deprecate it?
> 
I was against adding it in the first place, so if IBM no longer needs it
I am for removing it ASAP.

> > Now if you'll call
> > KVM_HC_WAIT_FOR_KICK instead of HLT you will effectively ignore
> > yield_on_hlt=0 setting.
> 
> I guess that depends on what we do in KVM_HC_WAIT_FOR_KICK. If we do
> yield_to() rather than sleep, it should minimize how much cycles vcpu gives away
> to a competing VM (which seems to be the biggest purpose why one may
> want to set yield_on_hlt=0).
> 
> > This is like having PV HLT that does not obey
> > VMX exit control setting.
> 
> - vatsa

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpC-0007G7-Mo; Wed, 18 Jan 2012 10:33:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmsIs-0005O9-Rn
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 19:33:15 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326742387!11219054!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21185 invoked from network); 16 Jan 2012 19:33:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 19:33:08 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GJWx1x019828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 14:33:07 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GIFHsp026359; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id C386740B9B; Mon, 16 Jan 2012 19:15:15 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:09 +0100
Message-Id: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 0/6] initial suspend support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series makes suspend support in qemu alot more useful.  Right
now the guest can put itself into s3, but qemu will wakeup the guest
instantly.  With this patch series applied the guest will stay suspended
instead and there are a few events which can kick the guest out of
suspend state:  A monitor command, ps/2 input, serial input, rtc.  Not
much yet, but it's a start with the low hanging fruits ;)

Changes in v2:
 * Add a suspend notifier.
 * Replace the cmos_s3 qemu_irq with the notifier, zap a bunch of hackish
   cmos_s3 windup code (this touches xen-all.c, thus cc xen-devel).
 * Add rtc wakeup support.

Gerd Hoffmann (6):
  suspend: add infrastructure
  suspend: switch acpi s3 to new infrastructure.
  suspend: add wakeup monitor command
  suspend: make ps/2 devices wakeup the guest
  suspend: make serial ports wakeup the guest.
  suspend: make rtc alarm wakeup the guest.

 hmp-commands.hx  |   14 ++++++++++++++
 hmp.c            |    5 +++++
 hmp.h            |    1 +
 hw/acpi.c        |   11 +----------
 hw/acpi.h        |    2 --
 hw/acpi_piix4.c  |    3 +--
 hw/mc146818rtc.c |   17 +++++++++++++++++
 hw/mips_malta.c  |    2 +-
 hw/pc.c          |   11 -----------
 hw/pc.h          |    3 +--
 hw/pc_piix.c     |    8 +-------
 hw/ps2.c         |    6 ++++++
 hw/serial.c      |    6 ++++++
 hw/vt82c686.c    |    1 -
 qapi-schema.json |   11 +++++++++++
 qmp-commands.hx  |   21 +++++++++++++++++++++
 qmp.c            |    5 +++++
 sysemu.h         |    3 +++
 vl.c             |   28 ++++++++++++++++++++++++++++
 xen-all.c        |   11 ++++++-----
 20 files changed, 128 insertions(+), 41 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpK-0007IO-Cz; Wed, 18 Jan 2012 10:33:10 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1RnB26-00018J-1Q
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:33:10 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326814383!1666162!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3880 invoked from network); 17 Jan 2012 15:33:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-21.messagelabs.com with SMTP;
	17 Jan 2012 15:33:03 -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 q0HFWcDX026015
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 10:32:39 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0HFWYtN014218; Tue, 17 Jan 2012 10:32:34 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id AC91418D474; Tue, 17 Jan 2012 17:32:33 +0200 (IST)
Date: Tue, 17 Jan 2012 17:32:33 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Message-ID: <20120117153233.GA7911@redhat.com>
References: <4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
	<20120117132051.GR2167@redhat.com>
	<20120117142818.GE30398@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117142818.GE30398@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 07:58:18PM +0530, Srivatsa Vaddagiri wrote:
> * Gleb Natapov <gleb@redhat.com> [2012-01-17 15:20:51]:
> 
> > > Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> > > hypervisor vs assuming that because of a trapped HLT instruction (which
> > > will anyway won't work when yield_on_hlt=0).
> > > 
> > The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the
> > entire time slice no mater what. I do not think disabling yield on HLT
> > is even make sense in CPU oversubscribe scenario.
> 
> Yes, so is there any real use for yield_on_hlt=0? I believe Anthony
> initially added it as a way to implement CPU bandwidth capping for VMs,
> which would ensure that busy VMs don't eat into cycles meant for a idle
> VM. Now that we have proper support in scheduler for CPU bandwidth capping, is 
> there any real world use for yield_on_hlt=0? If not, deprecate it?
> 
I was against adding it in the first place, so if IBM no longer needs it
I am for removing it ASAP.

> > Now if you'll call
> > KVM_HC_WAIT_FOR_KICK instead of HLT you will effectively ignore
> > yield_on_hlt=0 setting.
> 
> I guess that depends on what we do in KVM_HC_WAIT_FOR_KICK. If we do
> yield_to() rather than sleep, it should minimize how much cycles vcpu gives away
> to a competing VM (which seems to be the biggest purpose why one may
> want to set yield_on_hlt=0).
> 
> > This is like having PV HLT that does not obey
> > VMX exit control setting.
> 
> - vatsa

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpJ-0007ID-Sa; Wed, 18 Jan 2012 10:33:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RnA25-00073i-0h
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:29:05 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326810536!8662243!1
X-Originating-IP: [32.97.110.159]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1OSA9PiAzMzczODY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28273 invoked from network); 17 Jan 2012 14:28:57 -0000
Received: from e38.co.us.ibm.com (HELO e38.co.us.ibm.com) (32.97.110.159)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 14:28:57 -0000
Received: from /spool/local
	by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 07:28:52 -0700
Received: from d03dlp01.boulder.ibm.com (9.17.202.177)
	by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 07:28:49 -0700
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id A69751FF0047
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 07:28:44 -0700 (MST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HESfaE346406
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 09:28:42 -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
	q0HESWB8022230
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 09:28:37 -0500
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.122.216.170])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0HESJT8021071; Tue, 17 Jan 2012 09:28:20 -0500
Date: Tue, 17 Jan 2012 19:58:18 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Message-ID: <20120117142818.GE30398@linux.vnet.ibm.com>
References: <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
	<20120117132051.GR2167@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117132051.GR2167@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011714-5518-0000-0000-000001961A52
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Gleb Natapov <gleb@redhat.com> [2012-01-17 15:20:51]:

> > Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> > hypervisor vs assuming that because of a trapped HLT instruction (which
> > will anyway won't work when yield_on_hlt=0).
> > 
> The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the
> entire time slice no mater what. I do not think disabling yield on HLT
> is even make sense in CPU oversubscribe scenario.

Yes, so is there any real use for yield_on_hlt=0? I believe Anthony
initially added it as a way to implement CPU bandwidth capping for VMs,
which would ensure that busy VMs don't eat into cycles meant for a idle
VM. Now that we have proper support in scheduler for CPU bandwidth capping, is 
there any real world use for yield_on_hlt=0? If not, deprecate it?

> Now if you'll call
> KVM_HC_WAIT_FOR_KICK instead of HLT you will effectively ignore
> yield_on_hlt=0 setting.

I guess that depends on what we do in KVM_HC_WAIT_FOR_KICK. If we do
yield_to() rather than sleep, it should minimize how much cycles vcpu gives away
to a competing VM (which seems to be the biggest purpose why one may
want to set yield_on_hlt=0).

> This is like having PV HLT that does not obey
> VMX exit control setting.

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpJ-0007ID-Sa; Wed, 18 Jan 2012 10:33:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RnA25-00073i-0h
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 14:29:05 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326810536!8662243!1
X-Originating-IP: [32.97.110.159]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1OSA9PiAzMzczODY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28273 invoked from network); 17 Jan 2012 14:28:57 -0000
Received: from e38.co.us.ibm.com (HELO e38.co.us.ibm.com) (32.97.110.159)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 14:28:57 -0000
Received: from /spool/local
	by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 07:28:52 -0700
Received: from d03dlp01.boulder.ibm.com (9.17.202.177)
	by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 07:28:49 -0700
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id A69751FF0047
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 07:28:44 -0700 (MST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HESfaE346406
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 09:28:42 -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
	q0HESWB8022230
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 09:28:37 -0500
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.122.216.170])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0HESJT8021071; Tue, 17 Jan 2012 09:28:20 -0500
Date: Tue, 17 Jan 2012 19:58:18 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Message-ID: <20120117142818.GE30398@linux.vnet.ibm.com>
References: <20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
	<20120117132051.GR2167@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117132051.GR2167@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011714-5518-0000-0000-000001961A52
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Gleb Natapov <gleb@redhat.com> [2012-01-17 15:20:51]:

> > Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> > hypervisor vs assuming that because of a trapped HLT instruction (which
> > will anyway won't work when yield_on_hlt=0).
> > 
> The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the
> entire time slice no mater what. I do not think disabling yield on HLT
> is even make sense in CPU oversubscribe scenario.

Yes, so is there any real use for yield_on_hlt=0? I believe Anthony
initially added it as a way to implement CPU bandwidth capping for VMs,
which would ensure that busy VMs don't eat into cycles meant for a idle
VM. Now that we have proper support in scheduler for CPU bandwidth capping, is 
there any real world use for yield_on_hlt=0? If not, deprecate it?

> Now if you'll call
> KVM_HC_WAIT_FOR_KICK instead of HLT you will effectively ignore
> yield_on_hlt=0 setting.

I guess that depends on what we do in KVM_HC_WAIT_FOR_KICK. If we do
yield_to() rather than sleep, it should minimize how much cycles vcpu gives away
to a competing VM (which seems to be the biggest purpose why one may
want to set yield_on_hlt=0).

> This is like having PV HLT that does not obey
> VMX exit control setting.

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpP-0007Ju-4H; Wed, 18 Jan 2012 10:33:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnSgG-0006Qk-2E
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:23:48 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326882192!56185891!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA4NTc1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21458 invoked from network); 18 Jan 2012 10:23:16 -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; 18 Jan 2012 10:23:16 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 10:21:41 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp08.au.ibm.com ([202.81.31.205]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 10:21:23 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0IAInEn3109016
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 21:18:49 +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
	q0IANJ1f005335
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 21:23:20 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.124.26])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0IANDwT005238; Wed, 18 Jan 2012 21:23:14 +1100
Message-ID: <4F169D94.2010403@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 15:53:16 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>, Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
	<0B6BF918-45C7-45C6-AAA4-FB73EFAB9FDB@suse.de>
	<4F14C10C.3010303@goop.org>
In-Reply-To: <4F14C10C.3010303@goop.org>
x-cbid: 12011800-5140-0000-0000-0000009B8C60
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Greg Kroah-Hartman <gregkh@suse.de>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	Raghavendra <raghavendra.kt@linux.vnet.ibm.com>,
	"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>,
	Rob Landley <rlandley@parallels.com>, X86 <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>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.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>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 06:00 AM, Jeremy Fitzhardinge wrote:
> On 01/16/2012 09:24 PM, Alexander Graf wrote:
>> This is true in case you're spinning. If on overcommit spinlocks would
>> instead of spin just yield(), we wouldn't have any vcpu running that's
>> just waiting for a late ticket.
>
> Yes, but the reality is that most spinlocks are held for a short period
> of time and there's a low likelihood of being preempted while within a
> spinlock critical section.  Therefore if someone else tries to get the
> spinlock and there's contention, it's always worth spinning for a little
> while because the lock will likely become free soon.

I too believe that lock-holder-preemption forms small part of the 
problem. Non - PLE machine results seem to support that for the patch.

>
> At least that's the case if the lock has low contention (shallow queue
> depth and not in slow state).  Again, maybe it makes sense to never spin
> for deep queues or already slowstate locks.
>
>> We still have an issue finding the point in time when a vcpu could run again, which is what this whole series is about. My point above was that instead of doing a count loop, we could just do the normal spin dance and set the threshold to when we enable the magic to have another spin lock notify us in the CPU. That way we
>>
>>    * don't change the uncontended case
>
> I don't follow you.  What do you mean by "the normal spin dance"?  What
> do you mean by "have another spinlock notify us in the CPU"?  Don't
> change which uncontended case?  Do you mean in the locking path?  Or the
> unlock path?  Or both?
>
>>    * can set the threshold on the host, which knows how contended the system is
>
> Hm, I'm not convinced that knowing how contended the system is is all
> that useful overall.  What's important is how contended a particular
> lock is, and what state the current holder is in.  If it's not currently
> running, then knowing the overall system contention would give you some
> idea about how long you need to wait for it to be rescheduled, but
> that's getting pretty indirect.
>
> I think the "slowpath if preempted while spinning" idea I mentioned in
> the other mail is probably worth following up, since that give specific
> actionable information to the guest from the hypervisor.  But lots of
> caveats.
>
> [[
> A possible mechanism:
>
>    * register ranges of [er]ips with the hypervisor
>    * each range is paired with a "resched handler block"
>    * if vcpu is preempted within such a range, make sure it is
>      rescheduled in the resched handler block
>
> This is obviously akin to the exception mechanism, but it is partially
> implemented by the hypervisor.  It allows the spinlock code to be
> unchanged from native, but make use of a resched rather than an explicit
> counter to determine when to slowpath the lock.  And it's a nice general
> mechanism that could be potentially useful elsewhere.
>
> Unfortunately, it doesn't change the unlock path at all; it still needs
> to explicitly test if a VCPU needs to be kicked on unlock.
> ]]
>
>
>> And since we control what spin locks look like, we can for example always keep the pointer to it in a specific register so that we can handle pv_lock_ops.lock_spinning() inside there and fetch all the information we need from our pt_regs.
>
> You've left a pile of parts of an idea lying around, but I'm not sure
> what shape you intend it to be.

Interesting option But, Is it a feasible option to have specific
registers ? Considering we can have nested locks [ which means we need
a table ] and also considering the fact that "normal" spinlock 
acquisition path should have less overhead.

>
>      J
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpK-0007IY-Ug; Wed, 18 Jan 2012 10:33:10 +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 1RnBNH-00026u-EG
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:55:03 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326815696!9350415!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6634 invoked from network); 17 Jan 2012 15:54:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-174.messagelabs.com with SMTP;
	17 Jan 2012 15:54:57 -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 q0HFsdsI014134
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 10:54:39 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0HFscAT013308; Tue, 17 Jan 2012 10:54:39 -0500
Received: from amt.cnet (vpn1-7-129.ams2.redhat.com [10.36.7.129])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q0HFsRtU011223;
	Tue, 17 Jan 2012 10:54:28 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id E52CE65237B;
	Tue, 17 Jan 2012 13:53:20 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q0HFr3mD029087;
	Tue, 17 Jan 2012 13:53:03 -0200
Date: Tue, 17 Jan 2012 13:53:03 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>
Message-ID: <20120117155303.GA28904@amt.cnet>
References: <20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
	<20120117132051.GR2167@redhat.com>
	<20120117142818.GE30398@linux.vnet.ibm.com>
	<20120117153233.GA7911@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117153233.GA7911@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.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>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 05:32:33PM +0200, Gleb Natapov wrote:
> On Tue, Jan 17, 2012 at 07:58:18PM +0530, Srivatsa Vaddagiri wrote:
> > * Gleb Natapov <gleb@redhat.com> [2012-01-17 15:20:51]:
> > 
> > > > Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> > > > hypervisor vs assuming that because of a trapped HLT instruction (which
> > > > will anyway won't work when yield_on_hlt=0).
> > > > 
> > > The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the
> > > entire time slice no mater what. I do not think disabling yield on HLT
> > > is even make sense in CPU oversubscribe scenario.
> > 
> > Yes, so is there any real use for yield_on_hlt=0? I believe Anthony
> > initially added it as a way to implement CPU bandwidth capping for VMs,
> > which would ensure that busy VMs don't eat into cycles meant for a idle
> > VM. Now that we have proper support in scheduler for CPU bandwidth capping, is 
> > there any real world use for yield_on_hlt=0? If not, deprecate it?
> > 
> I was against adding it in the first place, so if IBM no longer needs it
> I am for removing it ASAP.

+1.

Anthony?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpK-0007IY-Ug; Wed, 18 Jan 2012 10:33:10 +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 1RnBNH-00026u-EG
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 15:55:03 +0000
X-Env-Sender: mtosatti@redhat.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326815696!9350415!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6634 invoked from network); 17 Jan 2012 15:54:57 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-16.tower-174.messagelabs.com with SMTP;
	17 Jan 2012 15:54:57 -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 q0HFsdsI014134
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 10:54:39 -0500
Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199])
	by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0HFscAT013308; Tue, 17 Jan 2012 10:54:39 -0500
Received: from amt.cnet (vpn1-7-129.ams2.redhat.com [10.36.7.129])
	by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q0HFsRtU011223;
	Tue, 17 Jan 2012 10:54:28 -0500
Received: from amt.cnet (amt.cnet [127.0.0.1])
	by amt.cnet (Postfix) with ESMTP id E52CE65237B;
	Tue, 17 Jan 2012 13:53:20 -0200 (BRST)
Received: (from marcelo@localhost)
	by amt.cnet (8.14.5/8.14.5/Submit) id q0HFr3mD029087;
	Tue, 17 Jan 2012 13:53:03 -0200
Date: Tue, 17 Jan 2012 13:53:03 -0200
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Gleb Natapov <gleb@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>
Message-ID: <20120117155303.GA28904@amt.cnet>
References: <20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
	<20120117132051.GR2167@redhat.com>
	<20120117142818.GE30398@linux.vnet.ibm.com>
	<20120117153233.GA7911@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117153233.GA7911@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.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>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 05:32:33PM +0200, Gleb Natapov wrote:
> On Tue, Jan 17, 2012 at 07:58:18PM +0530, Srivatsa Vaddagiri wrote:
> > * Gleb Natapov <gleb@redhat.com> [2012-01-17 15:20:51]:
> > 
> > > > Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> > > > hypervisor vs assuming that because of a trapped HLT instruction (which
> > > > will anyway won't work when yield_on_hlt=0).
> > > > 
> > > The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the
> > > entire time slice no mater what. I do not think disabling yield on HLT
> > > is even make sense in CPU oversubscribe scenario.
> > 
> > Yes, so is there any real use for yield_on_hlt=0? I believe Anthony
> > initially added it as a way to implement CPU bandwidth capping for VMs,
> > which would ensure that busy VMs don't eat into cycles meant for a idle
> > VM. Now that we have proper support in scheduler for CPU bandwidth capping, is 
> > there any real world use for yield_on_hlt=0? If not, deprecate it?
> > 
> I was against adding it in the first place, so if IBM no longer needs it
> I am for removing it ASAP.

+1.

Anthony?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpC-0007G7-Mo; Wed, 18 Jan 2012 10:33:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmsIs-0005O9-Rn
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 19:33:15 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326742387!11219054!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21185 invoked from network); 16 Jan 2012 19:33:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-216.messagelabs.com with SMTP;
	16 Jan 2012 19:33:08 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GJWx1x019828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 14:33:07 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GIFHsp026359; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id C386740B9B; Mon, 16 Jan 2012 19:15:15 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:09 +0100
Message-Id: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 0/6] initial suspend support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series makes suspend support in qemu alot more useful.  Right
now the guest can put itself into s3, but qemu will wakeup the guest
instantly.  With this patch series applied the guest will stay suspended
instead and there are a few events which can kick the guest out of
suspend state:  A monitor command, ps/2 input, serial input, rtc.  Not
much yet, but it's a start with the low hanging fruits ;)

Changes in v2:
 * Add a suspend notifier.
 * Replace the cmos_s3 qemu_irq with the notifier, zap a bunch of hackish
   cmos_s3 windup code (this touches xen-all.c, thus cc xen-devel).
 * Add rtc wakeup support.

Gerd Hoffmann (6):
  suspend: add infrastructure
  suspend: switch acpi s3 to new infrastructure.
  suspend: add wakeup monitor command
  suspend: make ps/2 devices wakeup the guest
  suspend: make serial ports wakeup the guest.
  suspend: make rtc alarm wakeup the guest.

 hmp-commands.hx  |   14 ++++++++++++++
 hmp.c            |    5 +++++
 hmp.h            |    1 +
 hw/acpi.c        |   11 +----------
 hw/acpi.h        |    2 --
 hw/acpi_piix4.c  |    3 +--
 hw/mc146818rtc.c |   17 +++++++++++++++++
 hw/mips_malta.c  |    2 +-
 hw/pc.c          |   11 -----------
 hw/pc.h          |    3 +--
 hw/pc_piix.c     |    8 +-------
 hw/ps2.c         |    6 ++++++
 hw/serial.c      |    6 ++++++
 hw/vt82c686.c    |    1 -
 qapi-schema.json |   11 +++++++++++
 qmp-commands.hx  |   21 +++++++++++++++++++++
 qmp.c            |    5 +++++
 sysemu.h         |    3 +++
 vl.c             |   28 ++++++++++++++++++++++++++++
 xen-all.c        |   11 ++++++-----
 20 files changed, 128 insertions(+), 41 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpP-0007Ju-4H; Wed, 18 Jan 2012 10:33:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnSgG-0006Qk-2E
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:23:48 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326882192!56185891!1
X-Originating-IP: [202.81.31.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAyLjgxLjMxLjE0MSA9PiA4NTc1MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21458 invoked from network); 18 Jan 2012 10:23:16 -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; 18 Jan 2012 10:23:16 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 10:21:41 +1000
Received: from d23relay04.au.ibm.com ([202.81.31.246])
	by e23smtp08.au.ibm.com ([202.81.31.205]) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 10:21:23 +1000
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0IAInEn3109016
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 21:18:49 +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
	q0IANJ1f005335
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 21:23:20 +1100
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.124.26])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0IANDwT005238; Wed, 18 Jan 2012 21:23:14 +1100
Message-ID: <4F169D94.2010403@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 15:53:16 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>, Alexander Graf <agraf@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
	<0B6BF918-45C7-45C6-AAA4-FB73EFAB9FDB@suse.de>
	<4F14C10C.3010303@goop.org>
In-Reply-To: <4F14C10C.3010303@goop.org>
x-cbid: 12011800-5140-0000-0000-0000009B8C60
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Greg Kroah-Hartman <gregkh@suse.de>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	Raghavendra <raghavendra.kt@linux.vnet.ibm.com>,
	"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>,
	Rob Landley <rlandley@parallels.com>, X86 <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>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.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>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 06:00 AM, Jeremy Fitzhardinge wrote:
> On 01/16/2012 09:24 PM, Alexander Graf wrote:
>> This is true in case you're spinning. If on overcommit spinlocks would
>> instead of spin just yield(), we wouldn't have any vcpu running that's
>> just waiting for a late ticket.
>
> Yes, but the reality is that most spinlocks are held for a short period
> of time and there's a low likelihood of being preempted while within a
> spinlock critical section.  Therefore if someone else tries to get the
> spinlock and there's contention, it's always worth spinning for a little
> while because the lock will likely become free soon.

I too believe that lock-holder-preemption forms small part of the 
problem. Non - PLE machine results seem to support that for the patch.

>
> At least that's the case if the lock has low contention (shallow queue
> depth and not in slow state).  Again, maybe it makes sense to never spin
> for deep queues or already slowstate locks.
>
>> We still have an issue finding the point in time when a vcpu could run again, which is what this whole series is about. My point above was that instead of doing a count loop, we could just do the normal spin dance and set the threshold to when we enable the magic to have another spin lock notify us in the CPU. That way we
>>
>>    * don't change the uncontended case
>
> I don't follow you.  What do you mean by "the normal spin dance"?  What
> do you mean by "have another spinlock notify us in the CPU"?  Don't
> change which uncontended case?  Do you mean in the locking path?  Or the
> unlock path?  Or both?
>
>>    * can set the threshold on the host, which knows how contended the system is
>
> Hm, I'm not convinced that knowing how contended the system is is all
> that useful overall.  What's important is how contended a particular
> lock is, and what state the current holder is in.  If it's not currently
> running, then knowing the overall system contention would give you some
> idea about how long you need to wait for it to be rescheduled, but
> that's getting pretty indirect.
>
> I think the "slowpath if preempted while spinning" idea I mentioned in
> the other mail is probably worth following up, since that give specific
> actionable information to the guest from the hypervisor.  But lots of
> caveats.
>
> [[
> A possible mechanism:
>
>    * register ranges of [er]ips with the hypervisor
>    * each range is paired with a "resched handler block"
>    * if vcpu is preempted within such a range, make sure it is
>      rescheduled in the resched handler block
>
> This is obviously akin to the exception mechanism, but it is partially
> implemented by the hypervisor.  It allows the spinlock code to be
> unchanged from native, but make use of a resched rather than an explicit
> counter to determine when to slowpath the lock.  And it's a nice general
> mechanism that could be potentially useful elsewhere.
>
> Unfortunately, it doesn't change the unlock path at all; it still needs
> to explicitly test if a VCPU needs to be kicked on unlock.
> ]]
>
>
>> And since we control what spin locks look like, we can for example always keep the pointer to it in a specific register so that we can handle pv_lock_ops.lock_spinning() inside there and fetch all the information we need from our pt_regs.
>
> You've left a pile of parts of an idea lying around, but I'm not sure
> what shape you intend it to be.

Interesting option But, Is it a feasible option to have specific
registers ? Considering we can have nested locks [ which means we need
a table ] and also considering the fact that "normal" spinlock 
acquisition path should have less overhead.

>
>      J
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpJ-0007I2-At; Wed, 18 Jan 2012 10:33:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1Rn8yV-0001OY-B5
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:21:19 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326806472!9492874!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5388 invoked from network); 17 Jan 2012 13:21:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	17 Jan 2012 13:21:12 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0HDKrXh028071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 08:20:53 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0HDKp7j018721; Tue, 17 Jan 2012 08:20:52 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 6CFE3133EEF; Tue, 17 Jan 2012 15:20:51 +0200 (IST)
Date: Tue, 17 Jan 2012 15:20:51 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Message-ID: <20120117132051.GR2167@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117131103.GD30398@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 06:41:03PM +0530, Srivatsa Vaddagiri wrote:
> * Gleb Natapov <gleb@redhat.com> [2012-01-17 14:51:26]:
> 
> > On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote:
> > > * Gleb Natapov <gleb@redhat.com> [2012-01-17 11:14:13]:
> > > 
> > > > > The problem case I was thinking of was when guest VCPU would have issued
> > > > > HLT with interrupts disabled. I guess one option is to inject an NMI,
> > > > > and have the guest kernel NMI handler recognize this and make
> > > > > adjustments such that the vcpu avoids going back to HLT instruction.
> > > > > 
> > > > Just kick vcpu out of a guest mode and adjust rip to point after HLT on
> > > > next re-entry. Don't forget to call vmx_clear_hlt().
> > > 
> > > Looks bit hackish to me compared to having another hypercall to yield!
> > > 
> > Do not see anything hackish about it. But what you described above (the
> > part I replied to) is not another hypercall, but yet another NMI source
> > and special handling in a guest.
> 
> True, which I didn't exactly like and hence was suggesting we use
> another hypercall to let spinning vcpu sleep.
> 
Ah, sorry. Missed that.

> > So what hypercall do you mean?
> 
> The hypercall is described below:
> 
> > > > > Having another hypercall to do yield/sleep (rather than effecting that
> > > > > via HLT) seems like an alternate clean solution here ..
> 
> and was implemented in an earlier version of this patch (v2) as
> KVM_HC_WAIT_FOR_KICK hypercall:
> 
> https://lkml.org/lkml/2011/10/23/211
> 
> Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> hypervisor vs assuming that because of a trapped HLT instruction (which
> will anyway won't work when yield_on_hlt=0).
> 
The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the
entire time slice no mater what. I do not think disabling yield on HLT
is even make sense in CPU oversubscribe scenario. Now if you'll call
KVM_HC_WAIT_FOR_KICK instead of HLT you will effectively ignore
yield_on_hlt=0 setting. This is like having PV HLT that does not obey
VMX exit control setting.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpJ-0007I2-At; Wed, 18 Jan 2012 10:33:09 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1Rn8yV-0001OY-B5
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 13:21:19 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326806472!9492874!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5388 invoked from network); 17 Jan 2012 13:21:12 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	17 Jan 2012 13:21:12 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0HDKrXh028071
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 08:20:53 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0HDKp7j018721; Tue, 17 Jan 2012 08:20:52 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 6CFE3133EEF; Tue, 17 Jan 2012 15:20:51 +0200 (IST)
Date: Tue, 17 Jan 2012 15:20:51 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Message-ID: <20120117132051.GR2167@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
	<20120117125126.GQ2167@redhat.com>
	<20120117131103.GD30398@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117131103.GD30398@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 06:41:03PM +0530, Srivatsa Vaddagiri wrote:
> * Gleb Natapov <gleb@redhat.com> [2012-01-17 14:51:26]:
> 
> > On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote:
> > > * Gleb Natapov <gleb@redhat.com> [2012-01-17 11:14:13]:
> > > 
> > > > > The problem case I was thinking of was when guest VCPU would have issued
> > > > > HLT with interrupts disabled. I guess one option is to inject an NMI,
> > > > > and have the guest kernel NMI handler recognize this and make
> > > > > adjustments such that the vcpu avoids going back to HLT instruction.
> > > > > 
> > > > Just kick vcpu out of a guest mode and adjust rip to point after HLT on
> > > > next re-entry. Don't forget to call vmx_clear_hlt().
> > > 
> > > Looks bit hackish to me compared to having another hypercall to yield!
> > > 
> > Do not see anything hackish about it. But what you described above (the
> > part I replied to) is not another hypercall, but yet another NMI source
> > and special handling in a guest.
> 
> True, which I didn't exactly like and hence was suggesting we use
> another hypercall to let spinning vcpu sleep.
> 
Ah, sorry. Missed that.

> > So what hypercall do you mean?
> 
> The hypercall is described below:
> 
> > > > > Having another hypercall to do yield/sleep (rather than effecting that
> > > > > via HLT) seems like an alternate clean solution here ..
> 
> and was implemented in an earlier version of this patch (v2) as
> KVM_HC_WAIT_FOR_KICK hypercall:
> 
> https://lkml.org/lkml/2011/10/23/211
> 
> Having the hypercall makes the intent of vcpu (to sleep on a kick) clear to 
> hypervisor vs assuming that because of a trapped HLT instruction (which
> will anyway won't work when yield_on_hlt=0).
> 
The purpose of yield_on_hlt=0 is to allow VCPU to occupy CPU for the
entire time slice no mater what. I do not think disabling yield on HLT
is even make sense in CPU oversubscribe scenario. Now if you'll call
KVM_HC_WAIT_FOR_KICK instead of HLT you will effectively ignore
yield_on_hlt=0 setting. This is like having PV HLT that does not obey
VMX exit control setting.

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpD-0007GE-6I; Wed, 18 Jan 2012 10:33:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmsJp-0005OU-M1
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 19:34:13 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326742446!9369660!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23350 invoked from network); 16 Jan 2012 19:34:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 19:34:07 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GJWx1v019828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 14:33:07 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GIFHGw026357; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 3CAFD40BAC; Mon, 16 Jan 2012 19:15:16 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:13 +0100
Message-Id: <1326737715-9867-5-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 4/6] suspend: make ps/2 devices wakeup the
	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds wakeup support to ps/2 emulation.  Any key press on the
ps/2 keyboard will wakeup the guest.  Likewise any mouse button press
will wakeup the guest.  Mouse moves are ignored, so the guest will not
wakeup in case your mouse crosses the vnc window of a suspended guest by
accident.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/ps2.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/ps2.c b/hw/ps2.c
index 1d9057b..d1b2505 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -24,6 +24,7 @@
 #include "hw.h"
 #include "ps2.h"
 #include "console.h"
+#include "sysemu.h"
 
 /* debug PC keyboard */
 //#define DEBUG_KBD
@@ -154,6 +155,7 @@ static void ps2_put_keycode(void *opaque, int keycode)
 {
     PS2KbdState *s = opaque;
 
+    qemu_system_wakeup_request();
     /* XXX: add support for scancode set 1 */
     if (!s->translate && keycode < 0xe0 && s->scancode_set > 1) {
         if (keycode & 0x80) {
@@ -368,6 +370,10 @@ static void ps2_mouse_event(void *opaque,
 	return;
     s->mouse_buttons = buttons_state;
 
+    if (buttons_state) {
+        qemu_system_wakeup_request();
+    }
+
     if (!(s->mouse_status & MOUSE_STATUS_REMOTE) &&
         (s->common.queue.count < (PS2_QUEUE_SIZE - 16))) {
         for(;;) {
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpD-0007GE-6I; Wed, 18 Jan 2012 10:33:03 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RmsJp-0005OU-M1
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 19:34:13 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326742446!9369660!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA1NDQ=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23350 invoked from network); 16 Jan 2012 19:34:07 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	16 Jan 2012 19:34:07 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0GJWx1v019828
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 16 Jan 2012 14:33:07 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-50.ams2.redhat.com
	[10.36.116.50])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0GIFHGw026357; Mon, 16 Jan 2012 13:15:19 -0500
Received: by rincewind.home.kraxel.org (Postfix, from userid 500)
	id 3CAFD40BAC; Mon, 16 Jan 2012 19:15:16 +0100 (CET)
From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Date: Mon, 16 Jan 2012 19:15:13 +0100
Message-Id: <1326737715-9867-5-git-send-email-kraxel@redhat.com>
In-Reply-To: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: xen-devel@lists.xensource.com, Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH v2 4/6] suspend: make ps/2 devices wakeup the
	guest
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch adds wakeup support to ps/2 emulation.  Any key press on the
ps/2 keyboard will wakeup the guest.  Likewise any mouse button press
will wakeup the guest.  Mouse moves are ignored, so the guest will not
wakeup in case your mouse crosses the vnc window of a suspended guest by
accident.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/ps2.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/hw/ps2.c b/hw/ps2.c
index 1d9057b..d1b2505 100644
--- a/hw/ps2.c
+++ b/hw/ps2.c
@@ -24,6 +24,7 @@
 #include "hw.h"
 #include "ps2.h"
 #include "console.h"
+#include "sysemu.h"
 
 /* debug PC keyboard */
 //#define DEBUG_KBD
@@ -154,6 +155,7 @@ static void ps2_put_keycode(void *opaque, int keycode)
 {
     PS2KbdState *s = opaque;
 
+    qemu_system_wakeup_request();
     /* XXX: add support for scancode set 1 */
     if (!s->translate && keycode < 0xe0 && s->scancode_set > 1) {
         if (keycode & 0x80) {
@@ -368,6 +370,10 @@ static void ps2_mouse_event(void *opaque,
 	return;
     s->mouse_buttons = buttons_state;
 
+    if (buttons_state) {
+        qemu_system_wakeup_request();
+    }
+
     if (!(s->mouse_status & MOUSE_STATUS_REMOTE) &&
         (s->common.queue.count < (PS2_QUEUE_SIZE - 16))) {
         for(;;) {
-- 
1.7.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpA-0007Fd-Mp; Wed, 18 Jan 2012 10:33:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmrW6-0004JD-S8
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:42:51 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326739364!3729801!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28597 invoked from network); 16 Jan 2012 18:42:44 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 18:42:44 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 392DC938E3;
	Mon, 16 Jan 2012 19:42:43 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <4F146EA5.3010106@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 19:42:38 +0100
Message-Id: <E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 19:38, Raghavendra K T wrote:

> On 01/16/2012 07:53 PM, Alexander Graf wrote:
>> 
>> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>> 
>>> * Alexander Graf<agraf@suse.de>  [2012-01-16 04:57:45]:
>>> 
>>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>> 
>>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>>> some workload(s)?
>> 
>> Yup
>> 
>>> 
>>> In some sense, the 1x overcommitcase results posted does measure the overhead
>>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>>> kernbench ..
>>> 
>>>> Result for Non PLE machine :
>>>> ============================
>>> 
>>> [snip]
>>> 
>>>> Kernbench:
>>>>               BASE                    BASE+patch
>> 
>> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>> 
>> 
>> Alex
> 
> Sorry for confusion, I think I was little imprecise on the BASE.
> 
> The BASE is pre 3.2.0 + Jeremy's following patches:
> xadd (https://lkml.org/lkml/2011/10/4/328)
> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
> So this would have ticketlock cleanups from Jeremy and
> CONFIG_PARAVIRT_SPINLOCKS=y
> 
> BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
> series and CONFIG_PARAVIRT_SPINLOCKS=y
> 
> In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.
> 
> So let,
> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
> B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
> C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
> D. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = n
> E. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = y
> 
> is it performance of A vs E ? (currently C vs E)

Since D and E only matter with KVM in use, yes, I'm mostly interested in A, B and C :).


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSpA-0007Fd-Mp; Wed, 18 Jan 2012 10:33:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <agraf@suse.de>) id 1RmrW6-0004JD-S8
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 18:42:51 +0000
X-Env-Sender: agraf@suse.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326739364!3729801!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28597 invoked from network); 16 Jan 2012 18:42:44 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 16 Jan 2012 18:42:44 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 392DC938E3;
	Mon, 16 Jan 2012 19:42:43 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
From: Alexander Graf <agraf@suse.de>
In-Reply-To: <4F146EA5.3010106@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2012 19:42:38 +0100
Message-Id: <E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.2012, at 19:38, Raghavendra K T wrote:

> On 01/16/2012 07:53 PM, Alexander Graf wrote:
>> 
>> On 16.01.2012, at 15:20, Srivatsa Vaddagiri wrote:
>> 
>>> * Alexander Graf<agraf@suse.de>  [2012-01-16 04:57:45]:
>>> 
>>>> Speaking of which - have you benchmarked performance degradation of pv ticket locks on bare metal?
>>> 
>>> You mean, run kernel on bare metal with CONFIG_PARAVIRT_SPINLOCKS
>>> enabled and compare how it performs with CONFIG_PARAVIRT_SPINLOCKS disabled for
>>> some workload(s)?
>> 
>> Yup
>> 
>>> 
>>> In some sense, the 1x overcommitcase results posted does measure the overhead
>>> of (pv-)spinlocks no? We don't see any overhead in that case for atleast
>>> kernbench ..
>>> 
>>>> Result for Non PLE machine :
>>>> ============================
>>> 
>>> [snip]
>>> 
>>>> Kernbench:
>>>>               BASE                    BASE+patch
>> 
>> What is BASE really? Is BASE already with the PV spinlocks enabled? I'm having a hard time understanding which tree you're working against, since the prerequisites aren't upstream yet.
>> 
>> 
>> Alex
> 
> Sorry for confusion, I think I was little imprecise on the BASE.
> 
> The BASE is pre 3.2.0 + Jeremy's following patches:
> xadd (https://lkml.org/lkml/2011/10/4/328)
> x86/ticketlocklock  (https://lkml.org/lkml/2011/10/12/496).
> So this would have ticketlock cleanups from Jeremy and
> CONFIG_PARAVIRT_SPINLOCKS=y
> 
> BASE+patch = pre 3.2.0 + Jeremy's above patches + above V5 PV spinlock
> series and CONFIG_PARAVIRT_SPINLOCKS=y
> 
> In both the cases  CONFIG_PARAVIRT_SPINLOCKS=y.
> 
> So let,
> A. pre-3.2.0 with CONFIG_PARAVIRT_SPINLOCKS = n
> B. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = n
> C. pre-3.2.0 + Jeremy's above patches with CONFIG_PARAVIRT_SPINLOCKS = y
> D. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = n
> E. pre-3.2.0 + Jeremy's above patches + V5 patches with CONFIG_PARAVIRT_SPINLOCKS = y
> 
> is it performance of A vs E ? (currently C vs E)

Since D and E only matter with KVM in use, yes, I'm mostly interested in A, B and C :).


Alex


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpN-0007JL-Fu; Wed, 18 Jan 2012 10:33:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave@linux.vnet.ibm.com>) id 1RnH2t-0002hD-Qs
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:58:24 +0000
X-Env-Sender: dave@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326837495!8716641!1
X-Originating-IP: [32.97.110.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE0OSA9PiAxMTA3OTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7724 invoked from network); 17 Jan 2012 21:58:16 -0000
Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 21:58: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 <dave@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 14:58:13 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179)
	by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 14:58:10 -0700
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 43DF819D804F
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 14:58:07 -0700 (MST)
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HLw8jc207032
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 16:58:08 -0500
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1])
	by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q0HLw4Ag011717
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 14:58:08 -0700
Received: from [9.48.102.71] (sig-9-48-102-71.mts.ibm.com [9.48.102.71])
	by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HLw1n0011424; Tue, 17 Jan 2012 14:58:01 -0700
Message-ID: <4F15EEE6.5020207@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 13:57:58 -0800
From: Dave Hansen <dave@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111109 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
In-Reply-To: <4F15BFAE.7060500@linux.vnet.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011721-7282-0000-0000-000005B36DED
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 10:36 AM, Raghavendra K T wrote:
> It was a quick test.  two iteration of kernbench (=6runs) and had
> ensured cache is cleared.
> 
> echo "1" > /proc/sys/vm/drop_caches
> ccache -C. Yes may be I can run test as you mentioned..

echo 3 > /proc/sys/vm/drop_caches

is better.  1 will only do page cache, but 3 also does dentries fwiw.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpM-0007JC-VW; Wed, 18 Jan 2012 10:33:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnEDz-0007zV-MJ
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:57:39 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326826607!48974173!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiAxMTg5MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16802 invoked from network); 17 Jan 2012 18:56:49 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 18:56:49 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 00:27:31 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 00:27:24 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HIvN9n4030514
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:27:24 +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
	q0HIvMHv020168
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:27:23 +0530
Received: from oc5400248562.ibm.com ([9.124.215.78])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HIvHhV020087; Wed, 18 Jan 2012 00:27:17 +0530
Message-ID: <4F15C48F.1000000@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 00:27:19 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
In-Reply-To: <20120117110210.GA17420@amt.cnet>
x-cbid: 12011718-2674-0000-0000-000003071246
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 04:32 PM, Marcelo Tosatti wrote:
> On Sat, Jan 14, 2012 at 11:56:46PM +0530, Raghavendra K T wrote:
>> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks.
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index c7b05fc..4d7a950 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>>
>>   	local_irq_disable();
>>
>> -	if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
>> -	    || need_resched() || signal_pending(current)) {
>> +	if (vcpu->mode == EXITING_GUEST_MODE
>> +		 || (vcpu->requests&  ~(1UL<<KVM_REQ_PVLOCK_KICK))
>> +		 || need_resched() || signal_pending(current)) {
>>   		vcpu->mode = OUTSIDE_GUEST_MODE;
>>   		smp_wmb();
>>   		local_irq_enable();
>> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>>   		!vcpu->arch.apf.halted)
>>   		|| !list_empty_careful(&vcpu->async_pf.done)
>>   		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
>> +		|| kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
>
> The bit should only be read here (kvm_arch_vcpu_runnable), but cleared
> on vcpu entry (along with the other kvm_check_request processing).
>
> Then the first hunk becomes unnecessary.

true. [ patch below ]

>
> Please do not mix host/guest patches.

yes, will be taken care in next version..

>
>

I had tried alternative approach earlier, I think that is closer
to your expectation.

where
- flag is read in kvm_arch_vcpu_runnable
- flag cleared in vcpu entry along with others.

But it needs per vcpu flag to remember that pv_unhalted while clearing
the flag in vcpu enter [ patch below ]. Could not find third alternative
though.

Simply clearing the request bit in vcpu entry had made guest hang in 
*rare* scenario.  [as kick will be lost].

[ I had observed guest hang after 4 iteration of kernbench with 1:3 
overcommit. with 2/3 guest running while 1 hogs ]

Avi,
do you think having pv_unhalt flag in below patch cause problem to
live migration still? (vcpu->request bit is retained as is) OR do we 
have to have KVM_GET_MP_STATE changes also with below patch you 
mentioned earlier.

---8<---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c38efd7..1bf8fa8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5684,6 +5717,11 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
  			r = 1;
  			goto out;
  		}
+		if (kvm_check_request(KVM_REQ_PVKICK, vcpu)) {
+			vcpu->pv_unhalted = 1;
+			r = 1;
+			goto out;
+		}
  		if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu))
  			record_steal_time(vcpu);
  		if (kvm_check_request(KVM_REQ_NMI, vcpu))
@@ -6683,6 +6720,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
  		!vcpu->arch.apf.halted)
  		|| !list_empty_careful(&vcpu->async_pf.done)
  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
+		|| (kvm_test_request(KVM_REQ_PVKICK, vcpu) || vcpu->pv_unhalted)
  		|| atomic_read(&vcpu->arch.nmi_queued) ||
  		(kvm_arch_interrupt_allowed(vcpu) &&
  		 kvm_cpu_has_interrupt(vcpu));
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d526231..a48e0f2 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -154,6 +155,8 @@ struct kvm_vcpu {
  #endif

  	struct kvm_vcpu_arch arch;
+
+	int pv_unhalted;
  };

  static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
@@ -770,5 +773,12 @@ static inline bool kvm_check_request(int req, 
struct kvm_vcpu *vcpu)
  	}
  }

+static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
+{
+	if (test_bit(req, &vcpu->requests))
+		return true;
+	else
+		return false;
+}
  #endif

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d9cfb78..55c44a2 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm 
*kvm, unsigned id)
  	vcpu->kvm = kvm;
  	vcpu->vcpu_id = id;
  	vcpu->pid = NULL;
+	vcpu->pv_unhalted = 0;
  	init_waitqueue_head(&vcpu->wq);
  	kvm_async_pf_vcpu_init(vcpu);

@@ -1509,11 +1510,12 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
  void kvm_vcpu_block(struct kvm_vcpu *vcpu)
  {
  	DEFINE_WAIT(wait);
  	for (;;) {
  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);

  		if (kvm_arch_vcpu_runnable(vcpu)) {
+			vcpu->pv_unhalted = 0;
  			kvm_make_request(KVM_REQ_UNHALT, vcpu);
  			break;
  		}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpM-0007JC-VW; Wed, 18 Jan 2012 10:33:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnEDz-0007zV-MJ
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 18:57:39 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326826607!48974173!1
X-Originating-IP: [122.248.162.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuOSA9PiAxMTg5MjM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16802 invoked from network); 17 Jan 2012 18:56:49 -0000
Received: from e28smtp09.in.ibm.com (HELO e28smtp09.in.ibm.com) (122.248.162.9)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 18:56:49 -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
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 00:27:31 +0530
Received: from d28relay05.in.ibm.com (9.184.220.62)
	by e28smtp09.in.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 00:27:24 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HIvN9n4030514
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:27:24 +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
	q0HIvMHv020168
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 00:27:23 +0530
Received: from oc5400248562.ibm.com ([9.124.215.78])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HIvHhV020087; Wed, 18 Jan 2012 00:27:17 +0530
Message-ID: <4F15C48F.1000000@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 00:27:19 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
In-Reply-To: <20120117110210.GA17420@amt.cnet>
x-cbid: 12011718-2674-0000-0000-000003071246
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 04:32 PM, Marcelo Tosatti wrote:
> On Sat, Jan 14, 2012 at 11:56:46PM +0530, Raghavendra K T wrote:
>> Extends Linux guest running on KVM hypervisor to support pv-ticketlocks.
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index c7b05fc..4d7a950 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -5754,8 +5754,9 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>>
>>   	local_irq_disable();
>>
>> -	if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
>> -	    || need_resched() || signal_pending(current)) {
>> +	if (vcpu->mode == EXITING_GUEST_MODE
>> +		 || (vcpu->requests&  ~(1UL<<KVM_REQ_PVLOCK_KICK))
>> +		 || need_resched() || signal_pending(current)) {
>>   		vcpu->mode = OUTSIDE_GUEST_MODE;
>>   		smp_wmb();
>>   		local_irq_enable();
>> @@ -6711,6 +6712,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>>   		!vcpu->arch.apf.halted)
>>   		|| !list_empty_careful(&vcpu->async_pf.done)
>>   		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
>> +		|| kvm_check_request(KVM_REQ_PVLOCK_KICK, vcpu)
>
> The bit should only be read here (kvm_arch_vcpu_runnable), but cleared
> on vcpu entry (along with the other kvm_check_request processing).
>
> Then the first hunk becomes unnecessary.

true. [ patch below ]

>
> Please do not mix host/guest patches.

yes, will be taken care in next version..

>
>

I had tried alternative approach earlier, I think that is closer
to your expectation.

where
- flag is read in kvm_arch_vcpu_runnable
- flag cleared in vcpu entry along with others.

But it needs per vcpu flag to remember that pv_unhalted while clearing
the flag in vcpu enter [ patch below ]. Could not find third alternative
though.

Simply clearing the request bit in vcpu entry had made guest hang in 
*rare* scenario.  [as kick will be lost].

[ I had observed guest hang after 4 iteration of kernbench with 1:3 
overcommit. with 2/3 guest running while 1 hogs ]

Avi,
do you think having pv_unhalt flag in below patch cause problem to
live migration still? (vcpu->request bit is retained as is) OR do we 
have to have KVM_GET_MP_STATE changes also with below patch you 
mentioned earlier.

---8<---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c38efd7..1bf8fa8 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5684,6 +5717,11 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
  			r = 1;
  			goto out;
  		}
+		if (kvm_check_request(KVM_REQ_PVKICK, vcpu)) {
+			vcpu->pv_unhalted = 1;
+			r = 1;
+			goto out;
+		}
  		if (kvm_check_request(KVM_REQ_STEAL_UPDATE, vcpu))
  			record_steal_time(vcpu);
  		if (kvm_check_request(KVM_REQ_NMI, vcpu))
@@ -6683,6 +6720,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
  		!vcpu->arch.apf.halted)
  		|| !list_empty_careful(&vcpu->async_pf.done)
  		|| vcpu->arch.mp_state == KVM_MP_STATE_SIPI_RECEIVED
+		|| (kvm_test_request(KVM_REQ_PVKICK, vcpu) || vcpu->pv_unhalted)
  		|| atomic_read(&vcpu->arch.nmi_queued) ||
  		(kvm_arch_interrupt_allowed(vcpu) &&
  		 kvm_cpu_has_interrupt(vcpu));
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index d526231..a48e0f2 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -154,6 +155,8 @@ struct kvm_vcpu {
  #endif

  	struct kvm_vcpu_arch arch;
+
+	int pv_unhalted;
  };

  static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
@@ -770,5 +773,12 @@ static inline bool kvm_check_request(int req, 
struct kvm_vcpu *vcpu)
  	}
  }

+static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
+{
+	if (test_bit(req, &vcpu->requests))
+		return true;
+	else
+		return false;
+}
  #endif

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d9cfb78..55c44a2 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -226,6 +226,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm 
*kvm, unsigned id)
  	vcpu->kvm = kvm;
  	vcpu->vcpu_id = id;
  	vcpu->pid = NULL;
+	vcpu->pv_unhalted = 0;
  	init_waitqueue_head(&vcpu->wq);
  	kvm_async_pf_vcpu_init(vcpu);

@@ -1509,11 +1510,12 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
  void kvm_vcpu_block(struct kvm_vcpu *vcpu)
  {
  	DEFINE_WAIT(wait);
  	for (;;) {
  		prepare_to_wait(&vcpu->wq, &wait, TASK_INTERRUPTIBLE);

  		if (kvm_arch_vcpu_runnable(vcpu)) {
+			vcpu->pv_unhalted = 0;
  			kvm_make_request(KVM_REQ_UNHALT, vcpu);
  			break;
  		}


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpN-0007JL-Fu; Wed, 18 Jan 2012 10:33:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dave@linux.vnet.ibm.com>) id 1RnH2t-0002hD-Qs
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 21:58:24 +0000
X-Env-Sender: dave@linux.vnet.ibm.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326837495!8716641!1
X-Originating-IP: [32.97.110.149]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE0OSA9PiAxMTA3OTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7724 invoked from network); 17 Jan 2012 21:58:16 -0000
Received: from e31.co.us.ibm.com (HELO e31.co.us.ibm.com) (32.97.110.149)
	by server-11.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 17 Jan 2012 21:58: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 <dave@linux.vnet.ibm.com>;
	Tue, 17 Jan 2012 14:58:13 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179)
	by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 17 Jan 2012 14:58:10 -0700
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 43DF819D804F
	for <xen-devel@lists.xensource.com>;
	Tue, 17 Jan 2012 14:58:07 -0700 (MST)
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0HLw8jc207032
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 16:58:08 -0500
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1])
	by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q0HLw4Ag011717
	for <xen-devel@lists.xensource.com>; Tue, 17 Jan 2012 14:58:08 -0700
Received: from [9.48.102.71] (sig-9-48-102-71.mts.ibm.com [9.48.102.71])
	by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0HLw1n0011424; Tue, 17 Jan 2012 14:58:01 -0700
Message-ID: <4F15EEE6.5020207@linux.vnet.ibm.com>
Date: Tue, 17 Jan 2012 13:57:58 -0800
From: Dave Hansen <dave@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111109 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<20120116142014.GA10155@linux.vnet.ibm.com>
	<B6E21B69-17D1-48E0-AFD4-B52075094005@suse.de>
	<4F146EA5.3010106@linux.vnet.ibm.com>
	<E9F33AFD-F051-4D68-84FF-D259FD6AD19D@suse.de>
	<4F15AF9E.9000907@linux.vnet.ibm.com>
	<1485A122-9D48-46E3-A01E-E37B5C9EC54A@suse.de>
	<4F15BFAE.7060500@linux.vnet.ibm.com>
In-Reply-To: <4F15BFAE.7060500@linux.vnet.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011721-7282-0000-0000-000005B36DED
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Greg Kroah-Hartman <gregkh@suse.de>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 10:36 AM, Raghavendra K T wrote:
> It was a quick test.  two iteration of kernbench (=6runs) and had
> ensured cache is cleared.
> 
> echo "1" > /proc/sys/vm/drop_caches
> ccache -C. Yes may be I can run test as you mentioned..

echo 3 > /proc/sys/vm/drop_caches

is better.  1 will only do page cache, but 3 also does dentries fwiw.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpE-0007GY-CY; Wed, 18 Jan 2012 10:33:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RmwST-0007in-FP
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 23:59:25 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326758356!11273062!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7794 invoked from network); 16 Jan 2012 23:59:18 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Jan 2012 23:59:18 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 02AF79341;
	Mon, 16 Jan 2012 15:59:14 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 467AD2097C;
	Tue, 17 Jan 2012 10:59:03 +1100 (EST)
Message-ID: <4F14B9C7.9090709@goop.org>
Date: Tue, 17 Jan 2012 10:59:03 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
	<4F13E613.7090602@redhat.com>
In-Reply-To: <4F13E613.7090602@redhat.com>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 07:55 PM, Avi Kivity wrote:
> On 01/16/2012 08:40 AM, Jeremy Fitzhardinge wrote:
>>> That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
>>>
>>> Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.
>> I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.
> The wakeup path is slower though.  The previous lock holder has to
> hypercall, and the new lock holder has to be scheduled, and transition
> from halted state to running (a vmentry).  So it's only a clear win if
> we can do something with the cpu other than go into the idle loop.

Not burning power is a win too.

Actually what you want is something like "if you preempt a VCPU while
its spinning in a lock, then push it into the slowpath and don't
reschedule it without a kick".  But I think that interface would have a
lot of fiddly corners.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpE-0007GY-CY; Wed, 18 Jan 2012 10:33:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RmwST-0007in-FP
	for xen-devel@lists.xensource.com; Mon, 16 Jan 2012 23:59:25 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326758356!11273062!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7794 invoked from network); 16 Jan 2012 23:59:18 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 16 Jan 2012 23:59:18 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 02AF79341;
	Mon, 16 Jan 2012 15:59:14 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 467AD2097C;
	Tue, 17 Jan 2012 10:59:03 +1100 (EST)
Message-ID: <4F14B9C7.9090709@goop.org>
Date: Tue, 17 Jan 2012 10:59:03 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
	<4F13E613.7090602@redhat.com>
In-Reply-To: <4F13E613.7090602@redhat.com>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Gleb Natapov <gleb@redhat.com>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.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>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/16/2012 07:55 PM, Avi Kivity wrote:
> On 01/16/2012 08:40 AM, Jeremy Fitzhardinge wrote:
>>> That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
>>>
>>> Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.
>> I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.
> The wakeup path is slower though.  The previous lock holder has to
> hypercall, and the new lock holder has to be scheduled, and transition
> from halted state to running (a vmentry).  So it's only a clear win if
> we can do something with the cpu other than go into the idle loop.

Not burning power is a win too.

Actually what you want is something like "if you preempt a VCPU while
its spinning in a lock, then push it into the slowpath and don't
reschedule it without a kick".  But I think that interface would have a
lot of fiddly corners.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpO-0007JW-0U; Wed, 18 Jan 2012 10:33:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RnKQS-0001zz-E3
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 01:34:56 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326850487!9582409!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6793 invoked from network); 18 Jan 2012 01:34:49 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 01:34:49 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id BEF7492DC;
	Tue, 17 Jan 2012 17:34:45 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 56A6C20C3E;
	Wed, 18 Jan 2012 12:34:42 +1100 (EST)
Message-ID: <4F1621B2.3020203@goop.org>
Date: Wed, 18 Jan 2012 12:34:42 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
In-Reply-To: <20120117113312.GB30398@linux.vnet.ibm.com>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 10:33 PM, Srivatsa Vaddagiri wrote:
> * Marcelo Tosatti <mtosatti@redhat.com> [2012-01-17 09:02:11]:
>
>>> +/* Kick vcpu waiting on @lock->head to reach value @ticket */
>>> +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
>>> +{
>>> +	int cpu;
>>> +	int apicid;
>>> +
>>> +	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);
>>> +			apicid = per_cpu(x86_cpu_to_apicid, cpu);
>>> +			kvm_kick_cpu(apicid);
>>> +			break;
>>> +		}
>>> +	}
>> What prevents a kick from being lost here, if say, the waiter is at
>> local_irq_save in kvm_lock_spinning, before the lock/want assignments?
> The waiter does check for lock becoming available before actually
> sleeping:
>
> +	/*
> +        * 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;
> +	}

That logic relies on the "kick" being level triggered, so that "kick"
before "block" will cause the block to fall out immediately.  If you're
using "hlt" as the block and it has the usual edge-triggered behaviour,
what stops a "kick-before-hlt" from losing the kick?

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpO-0007JW-0U; Wed, 18 Jan 2012 10:33:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RnKQS-0001zz-E3
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 01:34:56 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326850487!9582409!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6793 invoked from network); 18 Jan 2012 01:34:49 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 01:34:49 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id BEF7492DC;
	Tue, 17 Jan 2012 17:34:45 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 56A6C20C3E;
	Wed, 18 Jan 2012 12:34:42 +1100 (EST)
Message-ID: <4F1621B2.3020203@goop.org>
Date: Wed, 18 Jan 2012 12:34:42 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
In-Reply-To: <20120117113312.GB30398@linux.vnet.ibm.com>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 10:33 PM, Srivatsa Vaddagiri wrote:
> * Marcelo Tosatti <mtosatti@redhat.com> [2012-01-17 09:02:11]:
>
>>> +/* Kick vcpu waiting on @lock->head to reach value @ticket */
>>> +static void kvm_unlock_kick(struct arch_spinlock *lock, __ticket_t ticket)
>>> +{
>>> +	int cpu;
>>> +	int apicid;
>>> +
>>> +	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);
>>> +			apicid = per_cpu(x86_cpu_to_apicid, cpu);
>>> +			kvm_kick_cpu(apicid);
>>> +			break;
>>> +		}
>>> +	}
>> What prevents a kick from being lost here, if say, the waiter is at
>> local_irq_save in kvm_lock_spinning, before the lock/want assignments?
> The waiter does check for lock becoming available before actually
> sleeping:
>
> +	/*
> +        * 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;
> +	}

That logic relies on the "kick" being level triggered, so that "kick"
before "block" will cause the block to fall out immediately.  If you're
using "hlt" as the block and it has the usual edge-triggered behaviour,
what stops a "kick-before-hlt" from losing the kick?

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpH-0007HU-Ss; Wed, 18 Jan 2012 10:33:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1Rn8W5-0000mK-7r
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 12:51:57 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326804710!11257067!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18002 invoked from network); 17 Jan 2012 12:51:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	17 Jan 2012 12:51:50 -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 q0HCpSGB019835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 07:51:28 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0HCpQNK023633; Tue, 17 Jan 2012 07:51:27 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 5720C18D474; Tue, 17 Jan 2012 14:51:26 +0200 (IST)
Date: Tue, 17 Jan 2012 14:51:26 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Message-ID: <20120117125126.GQ2167@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117122650.GC30757@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote:
> * Gleb Natapov <gleb@redhat.com> [2012-01-17 11:14:13]:
> 
> > > The problem case I was thinking of was when guest VCPU would have issued
> > > HLT with interrupts disabled. I guess one option is to inject an NMI,
> > > and have the guest kernel NMI handler recognize this and make
> > > adjustments such that the vcpu avoids going back to HLT instruction.
> > > 
> > Just kick vcpu out of a guest mode and adjust rip to point after HLT on
> > next re-entry. Don't forget to call vmx_clear_hlt().
> 
> Looks bit hackish to me compared to having another hypercall to yield!
> 
Do not see anything hackish about it. But what you described above (the
part I replied to) is not another hypercall, but yet another NMI source
and special handling in a guest. So what hypercall do you mean?

> > > Having another hypercall to do yield/sleep (rather than effecting that
> > > via HLT) seems like an alternate clean solution here ..
> 
> - vatsa

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:35:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:35:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSpH-0007HU-Ss; Wed, 18 Jan 2012 10:33:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gleb@redhat.com>) id 1Rn8W5-0000mK-7r
	for xen-devel@lists.xensource.com; Tue, 17 Jan 2012 12:51:57 +0000
X-Env-Sender: gleb@redhat.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326804710!11257067!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA5NDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18002 invoked from network); 17 Jan 2012 12:51:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-5.tower-182.messagelabs.com with SMTP;
	17 Jan 2012 12:51:50 -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 q0HCpSGB019835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 17 Jan 2012 07:51:28 -0500
Received: from dhcp-1-237.tlv.redhat.com (dhcp-4-26.tlv.redhat.com
	[10.35.4.26])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0HCpQNK023633; Tue, 17 Jan 2012 07:51:27 -0500
Received: by dhcp-1-237.tlv.redhat.com (Postfix, from userid 13519)
	id 5720C18D474; Tue, 17 Jan 2012 14:51:26 +0200 (IST)
Date: Tue, 17 Jan 2012 14:51:26 +0200
From: Gleb Natapov <gleb@redhat.com>
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Message-ID: <20120117125126.GQ2167@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182710.8604.22277.sendpatchset@oc5400248562.ibm.com>
	<4F13E739.7040300@redhat.com>
	<20120116094020.GA6019@linux.vnet.ibm.com>
	<4F13F883.5090002@redhat.com>
	<20120116141117.GB6019@linux.vnet.ibm.com>
	<20120117091413.GM2167@redhat.com>
	<20120117122650.GC30757@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117122650.GC30757@linux.vnet.ibm.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
X-Mailman-Approved-At: Wed, 18 Jan 2012 10:32:53 +0000
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	KVM <kvm@vger.kernel.org>, linux-doc@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>, Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>, Dave Jiang <dave.jiang@intel.com>,
	Glauber Costa <glommer@redhat.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg Kroah-Hartman <gregkh@suse.de>,
	LKML <linux-kernel@vger.kernel.org>, Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 5/5] Documentation/kvm : Add
 documentation on Hypercalls and features used for PV spinlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 05:56:50PM +0530, Srivatsa Vaddagiri wrote:
> * Gleb Natapov <gleb@redhat.com> [2012-01-17 11:14:13]:
> 
> > > The problem case I was thinking of was when guest VCPU would have issued
> > > HLT with interrupts disabled. I guess one option is to inject an NMI,
> > > and have the guest kernel NMI handler recognize this and make
> > > adjustments such that the vcpu avoids going back to HLT instruction.
> > > 
> > Just kick vcpu out of a guest mode and adjust rip to point after HLT on
> > next re-entry. Don't forget to call vmx_clear_hlt().
> 
> Looks bit hackish to me compared to having another hypercall to yield!
> 
Do not see anything hackish about it. But what you described above (the
part I replied to) is not another hypercall, but yet another NMI source
and special handling in a guest. So what hypercall do you mean?

> > > Having another hypercall to do yield/sleep (rather than effecting that
> > > via HLT) seems like an alternate clean solution here ..
> 
> - vatsa

--
			Gleb.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:38:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSsP-0000yY-Jo; Wed, 18 Jan 2012 10:36: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 1RnSsK-0000oM-Ry
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:36:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326882968!9637652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9292 invoked from network); 18 Jan 2012 10:36:09 -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;
	18 Jan 2012 10:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:36: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, 18 Jan 2012 10:36:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:36:07 +0000
In-Reply-To: <1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326882968.14689.176.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> This patch reinstates the XENMEM_remove_from_physmap hypercall
> which was removed in 19041:ee62aaafff46 because it was not used.
> 
> However, is now needed in order to support xenstored stub domains.
> The xenstored stub domain is not priviliged like dom0 and so cannot
> unilaterally map the xenbus page of other guests into it's address
> space.  Therefore, before creating a domU the domain builder needs to
> seed its grant table with a grant ref allowing the xenstored stub
> domain to access the new domU's xenbus page.
> 
> At present domU's do not start with their grant table mapped.
> Instead it gets mapped when the guest requests a grant table from
> the hypervisor.
> 
> In order to seed the grant table, the domain builder first needs to
> map it into dom0 address space.  But the hypercall to do this
> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
> for HVM guests.  Therfore, in order to seed the grant table of an
> HVM guest, dom0 needs to *temporarily* map it into the guest's
> "physical" address space.
> 
> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
> 
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
about ordering in xlat.lst)

BTW, since Alex and Diego have subsequently left Citrix you could take
my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
no idea if that's necessary though, I expect not.

Ian.

> ---
>  xen/arch/ia64/xen/mm.c          |   34 ++++++++++++++++++++++++++++++++++
>  xen/arch/x86/mm.c               |   35 +++++++++++++++++++++++++++++++++++
>  xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
>  xen/include/public/memory.h     |   16 ++++++++++++++++
>  xen/include/xlat.lst            |    1 +
>  xen/include/xsm/xsm.h           |    6 ++++++
>  xen/xsm/dummy.c                 |    6 ++++++
>  xen/xsm/flask/hooks.c           |    6 ++++++
>  8 files changed, 118 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
> index 84f6a61..a40f96a 100644
> --- a/xen/arch/ia64/xen/mm.c
> +++ b/xen/arch/ia64/xen/mm.c
> @@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case XENMEM_remove_from_physmap:
> +    {
> +        struct xen_remove_from_physmap xrfp;
> +        unsigned long mfn;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xrfp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        if ( xsm_remove_from_physmap(current->domain, d) )
> +        {
> +            rcu_unlock_domain(d);
> +            return -EPERM;
> +        }
> +
> +        domain_lock(d);
> +
> +        mfn = gmfn_to_mfn(d, xrfp.gpfn);
> +
> +        if ( mfn_valid(mfn) )
> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
> +
> +        domain_unlock(d);
> +
> +        rcu_unlock_domain(d);
> +
> +        break;
> +    }
> +
> +
>      case XENMEM_machine_memory_map:
>      {
>          struct xen_memory_map memmap;
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 1f996e0..39cc3c0 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4871,6 +4871,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          return rc;
>      }
>  
> +    case XENMEM_remove_from_physmap:
> +    {
> +        struct xen_remove_from_physmap xrfp;
> +        unsigned long mfn;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xrfp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        if ( xsm_remove_from_physmap(current->domain, d) )
> +        {
> +            rcu_unlock_domain(d);
> +            return -EPERM;
> +        }
> +
> +        domain_lock(d);
> +
> +        mfn = get_gfn_untyped(d, xrfp.gpfn);
> +
> +        if ( mfn_valid(mfn) )
> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
> +
> +        put_gfn(d, xrfp.gpfn);
> +
> +        domain_unlock(d);
> +
> +        rcu_unlock_domain(d);
> +
> +        break;
> +    }
> +
>      case XENMEM_set_memory_map:
>      {
>          struct xen_foreign_memory_map fmap;
> diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
> index bea94fe..dde5430 100644
> --- a/xen/arch/x86/x86_64/compat/mm.c
> +++ b/xen/arch/x86/x86_64/compat/mm.c
> @@ -82,6 +82,20 @@ int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case XENMEM_remove_from_physmap:
> +    {
> +        struct compat_remove_from_physmap cmp;
> +        struct xen_remove_from_physmap *nat = (void *)COMPAT_ARG_XLAT_VIRT_BASE;
> +
> +        if ( copy_from_guest(&cmp, arg, 1) )
> +            return -EFAULT;
> +
> +        XLAT_remove_from_physmap(nat, &cmp);
> +        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
> +
> +        break;
> +    }
> +
>      case XENMEM_set_memory_map:
>      {
>          struct compat_foreign_memory_map cmp;
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index c5b78a8..308deff 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -229,6 +229,22 @@ struct xen_add_to_physmap {
>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>  
> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t     gpfn;
> +};
> +typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
> +
>  /*** REMOVED ***/
>  /*#define XENMEM_translate_gpfn_list  8*/
>  
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> index 3d92175..ee1772c 100644
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -81,6 +81,7 @@
>  !	processor_power			platform.h
>  ?	processor_px			platform.h
>  !	psd_package			platform.h
> +!	remove_from_physmap		memory.h
>  ?	xenpf_pcpuinfo			platform.h
>  ?	xenpf_pcpu_version		platform.h
>  !	sched_poll			sched.h
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index df6cec2..566c808 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -169,6 +169,7 @@ struct xsm_operations {
>      int (*update_va_mapping) (struct domain *d, struct domain *f, 
>                                                              l1_pgentry_t pte);
>      int (*add_to_physmap) (struct domain *d1, struct domain *d2);
> +    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>      int (*sendtrigger) (struct domain *d);
>      int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
>      int (*unbind_pt_irq) (struct domain *d);
> @@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
>      return xsm_call(add_to_physmap(d1, d2));
>  }
>  
> +static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
> +{
> +    return xsm_call(remove_from_physmap(d1, d2));
> +}
> +
>  static inline int xsm_sendtrigger(struct domain *d)
>  {
>      return xsm_call(sendtrigger(d));
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index 4bbfbff..65daa4e 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
>      return 0;
>  }
>  
> +static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
> +{
> +    return 0;
> +}
> +
>  static int dummy_sendtrigger (struct domain *d)
>  {
>      return 0;
> @@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>      set_to_dummy_if_null(ops, mmu_machphys_update);
>      set_to_dummy_if_null(ops, update_va_mapping);
>      set_to_dummy_if_null(ops, add_to_physmap);
> +    set_to_dummy_if_null(ops, remove_from_physmap);
>      set_to_dummy_if_null(ops, sendtrigger);
>      set_to_dummy_if_null(ops, bind_pt_irq);
>      set_to_dummy_if_null(ops, pin_mem_cacheattr);
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 0d35767..a2020a9 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
>      return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>  }
>  
> +static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
> +{
> +    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
> +}
> +
>  static int flask_sendtrigger(struct domain *d)
>  {
>      return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
> @@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
>      .mmu_machphys_update = flask_mmu_machphys_update,
>      .update_va_mapping = flask_update_va_mapping,
>      .add_to_physmap = flask_add_to_physmap,
> +    .remove_from_physmap = flask_remove_from_physmap,
>      .sendtrigger = flask_sendtrigger,
>      .get_device_group = flask_get_device_group,
>      .test_assign_device = flask_test_assign_device,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:38:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:38:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSsP-0000yY-Jo; Wed, 18 Jan 2012 10:36: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 1RnSsK-0000oM-Ry
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:36:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326882968!9637652!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9292 invoked from network); 18 Jan 2012 10:36:09 -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;
	18 Jan 2012 10:36:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:36: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, 18 Jan 2012 10:36:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:36:07 +0000
In-Reply-To: <1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326882968.14689.176.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> This patch reinstates the XENMEM_remove_from_physmap hypercall
> which was removed in 19041:ee62aaafff46 because it was not used.
> 
> However, is now needed in order to support xenstored stub domains.
> The xenstored stub domain is not priviliged like dom0 and so cannot
> unilaterally map the xenbus page of other guests into it's address
> space.  Therefore, before creating a domU the domain builder needs to
> seed its grant table with a grant ref allowing the xenstored stub
> domain to access the new domU's xenbus page.
> 
> At present domU's do not start with their grant table mapped.
> Instead it gets mapped when the guest requests a grant table from
> the hypervisor.
> 
> In order to seed the grant table, the domain builder first needs to
> map it into dom0 address space.  But the hypercall to do this
> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
> for HVM guests.  Therfore, in order to seed the grant table of an
> HVM guest, dom0 needs to *temporarily* map it into the guest's
> "physical" address space.
> 
> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
> 
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
about ordering in xlat.lst)

BTW, since Alex and Diego have subsequently left Citrix you could take
my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
no idea if that's necessary though, I expect not.

Ian.

> ---
>  xen/arch/ia64/xen/mm.c          |   34 ++++++++++++++++++++++++++++++++++
>  xen/arch/x86/mm.c               |   35 +++++++++++++++++++++++++++++++++++
>  xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
>  xen/include/public/memory.h     |   16 ++++++++++++++++
>  xen/include/xlat.lst            |    1 +
>  xen/include/xsm/xsm.h           |    6 ++++++
>  xen/xsm/dummy.c                 |    6 ++++++
>  xen/xsm/flask/hooks.c           |    6 ++++++
>  8 files changed, 118 insertions(+), 0 deletions(-)
> 
> diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
> index 84f6a61..a40f96a 100644
> --- a/xen/arch/ia64/xen/mm.c
> +++ b/xen/arch/ia64/xen/mm.c
> @@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case XENMEM_remove_from_physmap:
> +    {
> +        struct xen_remove_from_physmap xrfp;
> +        unsigned long mfn;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xrfp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        if ( xsm_remove_from_physmap(current->domain, d) )
> +        {
> +            rcu_unlock_domain(d);
> +            return -EPERM;
> +        }
> +
> +        domain_lock(d);
> +
> +        mfn = gmfn_to_mfn(d, xrfp.gpfn);
> +
> +        if ( mfn_valid(mfn) )
> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
> +
> +        domain_unlock(d);
> +
> +        rcu_unlock_domain(d);
> +
> +        break;
> +    }
> +
> +
>      case XENMEM_machine_memory_map:
>      {
>          struct xen_memory_map memmap;
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 1f996e0..39cc3c0 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4871,6 +4871,41 @@ long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          return rc;
>      }
>  
> +    case XENMEM_remove_from_physmap:
> +    {
> +        struct xen_remove_from_physmap xrfp;
> +        unsigned long mfn;
> +        struct domain *d;
> +
> +        if ( copy_from_guest(&xrfp, arg, 1) )
> +            return -EFAULT;
> +
> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
> +        if ( rc != 0 )
> +            return rc;
> +
> +        if ( xsm_remove_from_physmap(current->domain, d) )
> +        {
> +            rcu_unlock_domain(d);
> +            return -EPERM;
> +        }
> +
> +        domain_lock(d);
> +
> +        mfn = get_gfn_untyped(d, xrfp.gpfn);
> +
> +        if ( mfn_valid(mfn) )
> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
> +
> +        put_gfn(d, xrfp.gpfn);
> +
> +        domain_unlock(d);
> +
> +        rcu_unlock_domain(d);
> +
> +        break;
> +    }
> +
>      case XENMEM_set_memory_map:
>      {
>          struct xen_foreign_memory_map fmap;
> diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
> index bea94fe..dde5430 100644
> --- a/xen/arch/x86/x86_64/compat/mm.c
> +++ b/xen/arch/x86/x86_64/compat/mm.c
> @@ -82,6 +82,20 @@ int compat_arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case XENMEM_remove_from_physmap:
> +    {
> +        struct compat_remove_from_physmap cmp;
> +        struct xen_remove_from_physmap *nat = (void *)COMPAT_ARG_XLAT_VIRT_BASE;
> +
> +        if ( copy_from_guest(&cmp, arg, 1) )
> +            return -EFAULT;
> +
> +        XLAT_remove_from_physmap(nat, &cmp);
> +        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
> +
> +        break;
> +    }
> +
>      case XENMEM_set_memory_map:
>      {
>          struct compat_foreign_memory_map cmp;
> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
> index c5b78a8..308deff 100644
> --- a/xen/include/public/memory.h
> +++ b/xen/include/public/memory.h
> @@ -229,6 +229,22 @@ struct xen_add_to_physmap {
>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>  
> +/*
> + * Unmaps the page appearing at a particular GPFN from the specified guest's
> + * pseudophysical address space.
> + * arg == addr of xen_remove_from_physmap_t.
> + */
> +#define XENMEM_remove_from_physmap      15
> +struct xen_remove_from_physmap {
> +    /* Which domain to change the mapping for. */
> +    domid_t domid;
> +
> +    /* GPFN of the current mapping of the page. */
> +    xen_pfn_t     gpfn;
> +};
> +typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
> +
>  /*** REMOVED ***/
>  /*#define XENMEM_translate_gpfn_list  8*/
>  
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> index 3d92175..ee1772c 100644
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -81,6 +81,7 @@
>  !	processor_power			platform.h
>  ?	processor_px			platform.h
>  !	psd_package			platform.h
> +!	remove_from_physmap		memory.h
>  ?	xenpf_pcpuinfo			platform.h
>  ?	xenpf_pcpu_version		platform.h
>  !	sched_poll			sched.h
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index df6cec2..566c808 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -169,6 +169,7 @@ struct xsm_operations {
>      int (*update_va_mapping) (struct domain *d, struct domain *f, 
>                                                              l1_pgentry_t pte);
>      int (*add_to_physmap) (struct domain *d1, struct domain *d2);
> +    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>      int (*sendtrigger) (struct domain *d);
>      int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
>      int (*unbind_pt_irq) (struct domain *d);
> @@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
>      return xsm_call(add_to_physmap(d1, d2));
>  }
>  
> +static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
> +{
> +    return xsm_call(remove_from_physmap(d1, d2));
> +}
> +
>  static inline int xsm_sendtrigger(struct domain *d)
>  {
>      return xsm_call(sendtrigger(d));
> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
> index 4bbfbff..65daa4e 100644
> --- a/xen/xsm/dummy.c
> +++ b/xen/xsm/dummy.c
> @@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
>      return 0;
>  }
>  
> +static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
> +{
> +    return 0;
> +}
> +
>  static int dummy_sendtrigger (struct domain *d)
>  {
>      return 0;
> @@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>      set_to_dummy_if_null(ops, mmu_machphys_update);
>      set_to_dummy_if_null(ops, update_va_mapping);
>      set_to_dummy_if_null(ops, add_to_physmap);
> +    set_to_dummy_if_null(ops, remove_from_physmap);
>      set_to_dummy_if_null(ops, sendtrigger);
>      set_to_dummy_if_null(ops, bind_pt_irq);
>      set_to_dummy_if_null(ops, pin_mem_cacheattr);
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 0d35767..a2020a9 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
>      return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>  }
>  
> +static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
> +{
> +    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
> +}
> +
>  static int flask_sendtrigger(struct domain *d)
>  {
>      return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
> @@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
>      .mmu_machphys_update = flask_mmu_machphys_update,
>      .update_va_mapping = flask_update_va_mapping,
>      .add_to_physmap = flask_add_to_physmap,
> +    .remove_from_physmap = flask_remove_from_physmap,
>      .sendtrigger = flask_sendtrigger,
>      .get_device_group = flask_get_device_group,
>      .test_assign_device = flask_test_assign_device,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:39:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:39:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnStN-0001tx-F9; Wed, 18 Jan 2012 10:37:21 +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 1RnStK-0001qE-4B
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:37:18 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326882987!49059878!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26416 invoked from network); 18 Jan 2012 10:36:29 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Jan 2012 10:36:29 -0000
Received: from mail116-ch1-R.bigfish.com (10.43.68.253) by
	CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 10:37:07 +0000
Received: from mail116-ch1 (localhost [127.0.0.1])	by
	mail116-ch1-R.bigfish.com (Postfix) with ESMTP id AD67A5C033C;
	Wed, 18 Jan 2012 10:37:08 +0000 (UTC)
X-SpamScore: -22
X-BigFish: VPS-22(zzbb2dI9371I936eK1dbaL1432N98dK4015Lzz1202hzz8275bhz2dhc1ahc1bh668h839h93fh)
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 mail116-ch1 (localhost.localdomain [127.0.0.1]) by mail116-ch1
	(MessageSwitch) id 1326883028299676_17847;
	Wed, 18 Jan 2012 10:37:08 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail116-ch1.bigfish.com (Postfix) with ESMTP id
	372456C0255;	Wed, 18 Jan 2012 10:37:08 +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, 18 Jan 2012 10:37:05 +0000
X-WSS-ID: 0LXZPHV-01-4SH-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 26124102806B;	Wed, 18 Jan 2012 04:37:06 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 18 Jan 2012 04:37:21 -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, 18 Jan 2012 04:37:10 -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, 18 Jan 2012
	05:37:09 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id F3DFC49C20C; Wed, 18 Jan 2012
	10:37:07 +0000 (GMT)
Message-ID: <4F16A186.4080303@amd.com>
Date: Wed, 18 Jan 2012 11:40:06 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
In-Reply-To: <1326876800.2375.18.camel@Abyss>
X-OriginatorOrg: amd.com
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCHv2 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 09:53 AM, Dario Faggioli wrote:
> On Tue, 2012-01-17 at 11:17 +0000, Keir Fraser wrote:
>>> Dealing with interrupts from AMD-Vi IOMMU(s) 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>
>>
>> This patch needs fixing to apply to xen-unstable tip. Please do that and
>> resubmit.
>>
> I see. I can easily rebase the patch but there are functional changes
> involved, so I'd like to know what you think it's best to do first.
>
> In particular, the clash is against Wei's patches introducing PPR. So
> now the IOMMU interrupt handler checks both event log and ppr log.
>
> Question is, should I move _BOTH_ these checks into softirq or just
> defer event log processing, and leave ppr log handling in hard-irq
> context? Quickly looking at the new specs, it seems to me that deferring
> both should be fine, but I'd really appreciate your thoughts...

I think put both event log and ppr log into softirq is fine. If you 
could have a patch like this, I can do a quick test on my machine.
Thanks,
Wei

> Wei, Jan, Tim?
>
> Thanks and regards,
> Dario
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:39:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:39:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnStN-0001tx-F9; Wed, 18 Jan 2012 10:37:21 +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 1RnStK-0001qE-4B
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:37:18 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1326882987!49059878!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26416 invoked from network); 18 Jan 2012 10:36:29 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-10.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Jan 2012 10:36:29 -0000
Received: from mail116-ch1-R.bigfish.com (10.43.68.253) by
	CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 10:37:07 +0000
Received: from mail116-ch1 (localhost [127.0.0.1])	by
	mail116-ch1-R.bigfish.com (Postfix) with ESMTP id AD67A5C033C;
	Wed, 18 Jan 2012 10:37:08 +0000 (UTC)
X-SpamScore: -22
X-BigFish: VPS-22(zzbb2dI9371I936eK1dbaL1432N98dK4015Lzz1202hzz8275bhz2dhc1ahc1bh668h839h93fh)
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 mail116-ch1 (localhost.localdomain [127.0.0.1]) by mail116-ch1
	(MessageSwitch) id 1326883028299676_17847;
	Wed, 18 Jan 2012 10:37:08 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.250])	by mail116-ch1.bigfish.com (Postfix) with ESMTP id
	372456C0255;	Wed, 18 Jan 2012 10:37:08 +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, 18 Jan 2012 10:37:05 +0000
X-WSS-ID: 0LXZPHV-01-4SH-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 26124102806B;	Wed, 18 Jan 2012 04:37:06 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 18 Jan 2012 04:37:21 -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, 18 Jan 2012 04:37:10 -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, 18 Jan 2012
	05:37:09 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id F3DFC49C20C; Wed, 18 Jan 2012
	10:37:07 +0000 (GMT)
Message-ID: <4F16A186.4080303@amd.com>
Date: Wed, 18 Jan 2012 11:40:06 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
In-Reply-To: <1326876800.2375.18.camel@Abyss>
X-OriginatorOrg: amd.com
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCHv2 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 09:53 AM, Dario Faggioli wrote:
> On Tue, 2012-01-17 at 11:17 +0000, Keir Fraser wrote:
>>> Dealing with interrupts from AMD-Vi IOMMU(s) 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>
>>
>> This patch needs fixing to apply to xen-unstable tip. Please do that and
>> resubmit.
>>
> I see. I can easily rebase the patch but there are functional changes
> involved, so I'd like to know what you think it's best to do first.
>
> In particular, the clash is against Wei's patches introducing PPR. So
> now the IOMMU interrupt handler checks both event log and ppr log.
>
> Question is, should I move _BOTH_ these checks into softirq or just
> defer event log processing, and leave ppr log handling in hard-irq
> context? Quickly looking at the new specs, it seems to me that deferring
> both should be fine, but I'd really appreciate your thoughts...

I think put both event log and ppr log into softirq is fine. If you 
could have a patch like this, I can do a quick test on my machine.
Thanks,
Wei

> Wei, Jan, Tim?
>
> Thanks and regards,
> Dario
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:41:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSvA-0003OM-5i; Wed, 18 Jan 2012 10:39: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 1RnSv7-0003IF-OQ
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:39:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326883141!11545290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26193 invoked from network); 18 Jan 2012 10:39:01 -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;
	18 Jan 2012 10:39:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:39: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, 18 Jan 2012 10:39:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:39:01 +0000
In-Reply-To: <1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326883141.14689.177.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> 
> +static void clear_global_virq_handlers(struct domain *d)
> +{
> +    uint32_t virq;
> +    int put_count = 0;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +
> +    for (virq = 0; virq < NR_VIRQS; virq++) {
> +        if (global_virq_handlers[virq] == d) {
> +            global_virq_handlers[virq] = NULL;

I don't suppose we should rebind to dom0, should we? 

Seems like we are pretty hosed if this ever happens in a non-controlled
manner anyway...

> +            put_count++;
> +        }
> +    }
> +
> +    spin_unlock(&global_virq_handlers_lock);
> +
> +    while (put_count) {
> +        put_domain(d);
> +        put_count--;
> +    }
> +} 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:41:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSvA-0003OM-5i; Wed, 18 Jan 2012 10:39: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 1RnSv7-0003IF-OQ
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:39:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326883141!11545290!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26193 invoked from network); 18 Jan 2012 10:39:01 -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;
	18 Jan 2012 10:39:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111303"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:39: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, 18 Jan 2012 10:39:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:39:01 +0000
In-Reply-To: <1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326883141.14689.177.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> 
> +static void clear_global_virq_handlers(struct domain *d)
> +{
> +    uint32_t virq;
> +    int put_count = 0;
> +
> +    spin_lock(&global_virq_handlers_lock);
> +
> +    for (virq = 0; virq < NR_VIRQS; virq++) {
> +        if (global_virq_handlers[virq] == d) {
> +            global_virq_handlers[virq] = NULL;

I don't suppose we should rebind to dom0, should we? 

Seems like we are pretty hosed if this ever happens in a non-controlled
manner anyway...

> +            put_count++;
> +        }
> +    }
> +
> +    spin_unlock(&global_virq_handlers_lock);
> +
> +    while (put_count) {
> +        put_domain(d);
> +        put_count--;
> +    }
> +} 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:41:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSvV-0003fx-Tt; Wed, 18 Jan 2012 10:39:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RnSvT-0003Xz-0U
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:39:32 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326883162!10924564!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2ODc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22891 invoked from network); 18 Jan 2012 10:39:23 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:39:23 -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=kR6lvLHbY9KqXRZAIW41epYsRe7dPJU6LECNpil8klGcehZI1AtQiSxs
	c3TYSZERU6NOmwtjwmbW9ZqCVniyXM6ttFvbJw7PPwIRoaKtdgGu843xi
	bnDcuT6ziO0zdkgjaFbiMYjESMo3iGCbGe4mpH8HeQiKqazYrTfk1w/cu
	gIdnJdFk6eGJ1lD+z2hQABuCUsJ0Zv0q/fuoDIdA61taUMM3Aw85cebmU
	V1RWJVWeEIZB4oN4EW2b7CyWkXh8z;
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=1326883163; x=1358419163;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=dPfyUJfz57Zc/MIASIqnj9GunrXBNERjWHAQTD34FS8=;
	b=CMdTTwjxxqCC8b9f16kO4SixIfHLiCHGsEJ1FDhLFsupizZBC9pCmIc9
	H6oRry4iB6mBTVuXr+32MGviIszs6M61qKCkulI0kzMS8Hm2y9VVkozu0
	xp0FNzjAD5qCuxa4+JMkd7nRxCfILhD/G1nrymKBGEYTdK/wu7+qyUCl1
	Qsaq0HxhAP1mplWl1LTdikn2FMpviEWKAe9lqSxw+CYtoXbG0MNn9d3dN
	xVVU/Hgar7+JF2EfNLBt+U2wAtrlr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,528,1320620400"; d="scan'208";a="83881835"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 18 Jan 2012 11:39:23 +0100
X-IronPort-AV: E=Sophos;i="4.71,528,1320620400"; d="scan'208";a="126965500"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 18 Jan 2012 11:39:22 +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 33DA94A586E;
	Wed, 18 Jan 2012 11:39:22 +0100 (CET)
Message-ID: <4F16A15A.3040405@ts.fujitsu.com>
Date: Wed, 18 Jan 2012 11:39:22 +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: Keir Fraser <keir.xen@gmail.com>
References: <CB3C430D.29008%keir.xen@gmail.com>
In-Reply-To: <CB3C430D.29008%keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 10:36 AM, Keir Fraser wrote:
> On 18/01/2012 09:31, "Keir Fraser"<keir.xen@gmail.com>  wrote:
>
>> On 18/01/2012 09:07, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  wrote:
>>
>>> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>>>> On a real machine a cpu disabled via hlt with interrupts disabled can be
>>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.
>>>>
>>>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>>>
>>>>
>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
>>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It
>>> works
>>> on initial system boot when the target vcpu is activated the first time. If I
>>> deactivate a vcpu and try to activate it again it will start to run, but it
>>> is
>>> not starting at the specified entry point (at least it isn't performing the
>>> first instruction there).
>>> Is there some special initialization needed to make this work? Do I have to
>>> reset
>>> something on the vcpu before deactivating it?
>> No it should just work. Hvmloader wakes and then sleeps every AP, in
>> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS
>> is not the first, as hvmloader already did it once! So this path should be
>> working and indeed tested on every HVM guest boot.
> Bit more info: INIT-SIPI logic is complicated by needing to avoid deadlocks
> between two VCPUs attempting to pause and reset each other. But the core
> dispatch logic is in vlapic_init_sipi_action(). You will see that on INIT,
> we should call vcpu_reset() which will de-initialise and VCPU_down the vcpu.
> And then on SIPI we call hvm_vcpu_reset_state(), which should reinitialise
> and wake the vcpu to start running at the specified CS:IP.
>
> So the above will be good places for you to add tracing and work out what's
> going on. :-)

Yeah, thanks for the confirmation this should work.
Printing some diagnostics helped me to spot the error in my code.


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 Wed Jan 18 10:41:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10: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 1RnSvV-0003fx-Tt; Wed, 18 Jan 2012 10:39:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RnSvT-0003Xz-0U
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:39:32 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326883162!10924564!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2ODc5NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22891 invoked from network); 18 Jan 2012 10:39:23 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 10:39:23 -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=kR6lvLHbY9KqXRZAIW41epYsRe7dPJU6LECNpil8klGcehZI1AtQiSxs
	c3TYSZERU6NOmwtjwmbW9ZqCVniyXM6ttFvbJw7PPwIRoaKtdgGu843xi
	bnDcuT6ziO0zdkgjaFbiMYjESMo3iGCbGe4mpH8HeQiKqazYrTfk1w/cu
	gIdnJdFk6eGJ1lD+z2hQABuCUsJ0Zv0q/fuoDIdA61taUMM3Aw85cebmU
	V1RWJVWeEIZB4oN4EW2b7CyWkXh8z;
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=1326883163; x=1358419163;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=dPfyUJfz57Zc/MIASIqnj9GunrXBNERjWHAQTD34FS8=;
	b=CMdTTwjxxqCC8b9f16kO4SixIfHLiCHGsEJ1FDhLFsupizZBC9pCmIc9
	H6oRry4iB6mBTVuXr+32MGviIszs6M61qKCkulI0kzMS8Hm2y9VVkozu0
	xp0FNzjAD5qCuxa4+JMkd7nRxCfILhD/G1nrymKBGEYTdK/wu7+qyUCl1
	Qsaq0HxhAP1mplWl1LTdikn2FMpviEWKAe9lqSxw+CYtoXbG0MNn9d3dN
	xVVU/Hgar7+JF2EfNLBt+U2wAtrlr;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,528,1320620400"; d="scan'208";a="83881835"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 18 Jan 2012 11:39:23 +0100
X-IronPort-AV: E=Sophos;i="4.71,528,1320620400"; d="scan'208";a="126965500"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 18 Jan 2012 11:39:22 +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 33DA94A586E;
	Wed, 18 Jan 2012 11:39:22 +0100 (CET)
Message-ID: <4F16A15A.3040405@ts.fujitsu.com>
Date: Wed, 18 Jan 2012 11:39:22 +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: Keir Fraser <keir.xen@gmail.com>
References: <CB3C430D.29008%keir.xen@gmail.com>
In-Reply-To: <CB3C430D.29008%keir.xen@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via nmi-ipi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 10:36 AM, Keir Fraser wrote:
> On 18/01/2012 09:31, "Keir Fraser"<keir.xen@gmail.com>  wrote:
>
>> On 18/01/2012 09:07, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  wrote:
>>
>>> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>>>> On a real machine a cpu disabled via hlt with interrupts disabled can be
>>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm, too.
>>>>
>>>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>>>
>>>>
>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
>>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence. It
>>> works
>>> on initial system boot when the target vcpu is activated the first time. If I
>>> deactivate a vcpu and try to activate it again it will start to run, but it
>>> is
>>> not starting at the specified entry point (at least it isn't performing the
>>> first instruction there).
>>> Is there some special initialization needed to make this work? Do I have to
>>> reset
>>> something on the vcpu before deactivating it?
>> No it should just work. Hvmloader wakes and then sleeps every AP, in
>> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the guest OS
>> is not the first, as hvmloader already did it once! So this path should be
>> working and indeed tested on every HVM guest boot.
> Bit more info: INIT-SIPI logic is complicated by needing to avoid deadlocks
> between two VCPUs attempting to pause and reset each other. But the core
> dispatch logic is in vlapic_init_sipi_action(). You will see that on INIT,
> we should call vcpu_reset() which will de-initialise and VCPU_down the vcpu.
> And then on SIPI we call hvm_vcpu_reset_state(), which should reinitialise
> and wake the vcpu to start running at the specified CS:IP.
>
> So the above will be good places for you to add tracing and work out what's
> going on. :-)

Yeah, thanks for the confirmation this should work.
Printing some diagnostics helped me to spot the error in my code.


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 Wed Jan 18 10:44:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSz9-0005eE-E9; Wed, 18 Jan 2012 10:43:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnSz8-0005ak-2J
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:43:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326883391!9463630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24334 invoked from network); 18 Jan 2012 10:43:11 -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;
	18 Jan 2012 10:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111413"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:43:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 10:43:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:43:10 +0000
In-Reply-To: <1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326883390.14689.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 04/18] xen: Preserve reserved grant entries
 when switching 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 Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> In order for the toolstack to use reserved grant table entries, the
> grant table for a guest must be initialized prior to the guest's boot.
> When the guest switches grant table versions (necessary if the guest is
> using v2 grant tables, or on kexec if switching grant versions), these
> initial grants will be cleared. Instead of clearing them, preserve
> the grants across the type change.
> 
> Attempting to use or preserve v2-only features such as sub-page grants
> will produce invalid v1 grant entries, which (while they will not work)
> is not a problem since a guest can always produce such invalid entries.

Would it be better to explicitly clear such entries? Perhaps we should
even warn since it is effectively disallowed for the toolstack to use v2
features in the reserved entries.

> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/common/grant_table.c         |   38 +++++++++++++++++++++++++++++++-------
>  xen/include/public/grant_table.h |    6 ++++++
>  2 files changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 014734d..8d4a4cb 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      struct domain *d = current->domain;
>      struct grant_table *gt = d->grant_table;
>      struct active_grant_entry *act;
> +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
>      long res;
>      int i;
>  
> @@ -2126,7 +2127,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      /* (You need to change the version number for e.g. kexec.) */
>      if ( gt->gt_version != 0 )
>      {
> -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
>          {
>              act = &active_entry(gt, i);
>              if ( act->pin != 0 )
> @@ -2151,15 +2152,38 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>              goto out_unlock;
>      }
>  
> +    /* Preserve the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version == 1) {
> +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> +    } else if (gt->gt_version == 2) {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
> +        {
> +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> +            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
> +            reserved_entries[i].flags |= status_entry(gt, i);
> +        }
> +    }
> +
>      if ( op.version < 2 && gt->gt_version == 2 )
>          gnttab_unpopulate_status_frames(d, gt);
>  
> -    if ( op.version != gt->gt_version )
> -    {
> -        /* Make sure there's no crud left over in the table from the
> -           old version. */
> -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +    /* Make sure there's no crud left over in the table from the
> +       old version. */
> +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +
> +    /* Restore the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version != 0 && op.version == 1) {
> +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> +    } else if (gt->gt_version != 0 && op.version == 2) {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> +        {
> +            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> +            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
> +        }
>      }
>  
>      gt->gt_version = op.version;
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 0bf20bc..36d1ac7 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -117,6 +117,12 @@ struct grant_entry_v1 {
>  };
>  typedef struct grant_entry_v1 grant_entry_v1_t;
>  
> +/* External tools reserve first few grant table entries. */
> +#define GNTTAB_NR_RESERVED_ENTRIES     8
> +#define GNTTAB_RESERVED_CONSOLE        0
> +#define GNTTAB_RESERVED_XENSTORE       1
> +/* (the next 6 are reserved for future use) */
> +
>  /*
>   * Type of grant entry.
>   *  GTF_invalid: This grant entry grants no privileges.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:44:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnSz9-0005eE-E9; Wed, 18 Jan 2012 10:43:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnSz8-0005ak-2J
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:43:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326883391!9463630!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24334 invoked from network); 18 Jan 2012 10:43:11 -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;
	18 Jan 2012 10:43:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111413"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:43:11 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 10:43:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:43:10 +0000
In-Reply-To: <1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-5-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326883390.14689.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 04/18] xen: Preserve reserved grant entries
 when switching 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 Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> In order for the toolstack to use reserved grant table entries, the
> grant table for a guest must be initialized prior to the guest's boot.
> When the guest switches grant table versions (necessary if the guest is
> using v2 grant tables, or on kexec if switching grant versions), these
> initial grants will be cleared. Instead of clearing them, preserve
> the grants across the type change.
> 
> Attempting to use or preserve v2-only features such as sub-page grants
> will produce invalid v1 grant entries, which (while they will not work)
> is not a problem since a guest can always produce such invalid entries.

Would it be better to explicitly clear such entries? Perhaps we should
even warn since it is effectively disallowed for the toolstack to use v2
features in the reserved entries.

> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/common/grant_table.c         |   38 +++++++++++++++++++++++++++++++-------
>  xen/include/public/grant_table.h |    6 ++++++
>  2 files changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 014734d..8d4a4cb 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2106,6 +2106,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      struct domain *d = current->domain;
>      struct grant_table *gt = d->grant_table;
>      struct active_grant_entry *act;
> +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
>      long res;
>      int i;
>  
> @@ -2126,7 +2127,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      /* (You need to change the version number for e.g. kexec.) */
>      if ( gt->gt_version != 0 )
>      {
> -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
>          {
>              act = &active_entry(gt, i);
>              if ( act->pin != 0 )
> @@ -2151,15 +2152,38 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>              goto out_unlock;
>      }
>  
> +    /* Preserve the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version == 1) {
> +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> +    } else if (gt->gt_version == 2) {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
> +        {
> +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> +            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
> +            reserved_entries[i].flags |= status_entry(gt, i);
> +        }
> +    }
> +
>      if ( op.version < 2 && gt->gt_version == 2 )
>          gnttab_unpopulate_status_frames(d, gt);
>  
> -    if ( op.version != gt->gt_version )
> -    {
> -        /* Make sure there's no crud left over in the table from the
> -           old version. */
> -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +    /* Make sure there's no crud left over in the table from the
> +       old version. */
> +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +
> +    /* Restore the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version != 0 && op.version == 1) {
> +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> +    } else if (gt->gt_version != 0 && op.version == 2) {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> +        {
> +            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> +            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
> +        }
>      }
>  
>      gt->gt_version = op.version;
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 0bf20bc..36d1ac7 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -117,6 +117,12 @@ struct grant_entry_v1 {
>  };
>  typedef struct grant_entry_v1 grant_entry_v1_t;
>  
> +/* External tools reserve first few grant table entries. */
> +#define GNTTAB_NR_RESERVED_ENTRIES     8
> +#define GNTTAB_RESERVED_CONSOLE        0
> +#define GNTTAB_RESERVED_XENSTORE       1
> +/* (the next 6 are reserved for future use) */
> +
>  /*
>   * Type of grant entry.
>   *  GTF_invalid: This grant entry grants no privileges.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:48:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnT3X-0006RD-KL; Wed, 18 Jan 2012 10:47: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 1RnT3W-0006QM-CO
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:47:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326883664!11379118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19213 invoked from network); 18 Jan 2012 10:47:44 -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;
	18 Jan 2012 10:47:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:47:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 10:47:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:47:43 +0000
In-Reply-To: <1326411330-7915-6-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-6-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326883663.14689.182.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 05/18] tools/libxl: pull xenstore/console
 domids from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Instead of assuming that xenstored and xenconsoled are running in dom0,
> pull the domain IDs from xenstore.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I'm not sure we need to carry these around in the build state, since
they can just be looked up (perhaps by helper functions) but
nevertheless:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_dom.c      |   14 ++++++++++++--
>  tools/libxl/libxl_internal.h |    2 ++
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index a4725fe..5e39595 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -73,6 +73,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int tsc_mode;
> +    char *xs_domid, *con_domid;
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
>      if (info->type == LIBXL_DOMAIN_TYPE_PV)
> @@ -104,9 +105,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>          xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
>      }
>  
> -    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
> -    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
> +    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
> +    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
> +    free(xs_domid);
> +
> +    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
> +    state->console_domid = con_domid ? atoi(con_domid) : 0;
> +    free(con_domid);
> +
> +    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
> +    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
>      state->vm_generationid_addr = 0;
> +
>      return 0;
>  }
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 288c03c..97ead08 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -219,9 +219,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
>      libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
>  typedef struct {
>      uint32_t store_port;
> +    uint32_t store_domid;
>      unsigned long store_mfn;
>  
>      uint32_t console_port;
> +    uint32_t console_domid;
>      unsigned long console_mfn;
>      unsigned long vm_generationid_addr;
>  } libxl__domain_build_state;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 10:48:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 10:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnT3X-0006RD-KL; Wed, 18 Jan 2012 10:47: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 1RnT3W-0006QM-CO
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:47:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326883664!11379118!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19213 invoked from network); 18 Jan 2012 10:47:44 -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;
	18 Jan 2012 10:47:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111527"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 10:47:44 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 10:47:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 10:47:43 +0000
In-Reply-To: <1326411330-7915-6-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-6-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326883663.14689.182.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 05/18] tools/libxl: pull xenstore/console
 domids from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Instead of assuming that xenstored and xenconsoled are running in dom0,
> pull the domain IDs from xenstore.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I'm not sure we need to carry these around in the build state, since
they can just be looked up (perhaps by helper functions) but
nevertheless:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_dom.c      |   14 ++++++++++++--
>  tools/libxl/libxl_internal.h |    2 ++
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index a4725fe..5e39595 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -73,6 +73,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int tsc_mode;
> +    char *xs_domid, *con_domid;
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
>      if (info->type == LIBXL_DOMAIN_TYPE_PV)
> @@ -104,9 +105,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>          xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
>      }
>  
> -    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
> -    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
> +    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
> +    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
> +    free(xs_domid);
> +
> +    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
> +    state->console_domid = con_domid ? atoi(con_domid) : 0;
> +    free(con_domid);
> +
> +    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
> +    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
>      state->vm_generationid_addr = 0;
> +
>      return 0;
>  }
>  
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 288c03c..97ead08 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -219,9 +219,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
>      libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
>  typedef struct {
>      uint32_t store_port;
> +    uint32_t store_domid;
>      unsigned long store_mfn;
>  
>      uint32_t console_port;
> +    uint32_t console_domid;
>      unsigned long console_mfn;
>      unsigned long vm_generationid_addr;
>  } libxl__domain_build_state;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:00:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTEx-00078P-2O; Wed, 18 Jan 2012 10:59:39 +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 1RnTEv-00078K-QD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:59:37 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326884247!49043814!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 14169 invoked from network); 18 Jan 2012 10:57:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-27.messagelabs.com with SMTP;
	18 Jan 2012 10:57:27 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74590252; Wed, 18 Jan 2012 11:59:35 +0100
Message-ID: <1326884350.5856.13.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Wei Wang <wei.wang2@amd.com>
Date: Wed, 18 Jan 2012 11:59:10 +0100
In-Reply-To: <4F16A186.4080303@amd.com>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
	<4F16A186.4080303@amd.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCHv2 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="===============2025974472213284922=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2025974472213284922==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-TGPC0RPmpCq6UMg9F5Ls"


--=-TGPC0RPmpCq6UMg9F5Ls
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-18 at 11:40 +0100, Wei Wang wrote:
> I think put both event log and ppr log into softirq is fine.=20
>
Ok then.

> If you=20
> could have a patch like this, I can do a quick test on my machine.
>
Oh, that would be great. I'll put it together and send ASAP.

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)


--=-TGPC0RPmpCq6UMg9F5Ls
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)

iEYEABECAAYFAk8Wpf4ACgkQk4XaBE3IOsSnQACdFgfjnEVn0NuK8ZeDQXgIe+Ib
u9AAnj2mbSyyte9tO6V0rrD//2+G5IkR
=dhlW
-----END PGP SIGNATURE-----

--=-TGPC0RPmpCq6UMg9F5Ls--



--===============2025974472213284922==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2025974472213284922==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:00:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTEx-00078P-2O; Wed, 18 Jan 2012 10:59:39 +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 1RnTEv-00078K-QD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:59:37 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326884247!49043814!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 14169 invoked from network); 18 Jan 2012 10:57:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-27.messagelabs.com with SMTP;
	18 Jan 2012 10:57:27 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74590252; Wed, 18 Jan 2012 11:59:35 +0100
Message-ID: <1326884350.5856.13.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Wei Wang <wei.wang2@amd.com>
Date: Wed, 18 Jan 2012 11:59:10 +0100
In-Reply-To: <4F16A186.4080303@amd.com>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
	<4F16A186.4080303@amd.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCHv2 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="===============2025974472213284922=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2025974472213284922==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-TGPC0RPmpCq6UMg9F5Ls"


--=-TGPC0RPmpCq6UMg9F5Ls
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-18 at 11:40 +0100, Wei Wang wrote:
> I think put both event log and ppr log into softirq is fine.=20
>
Ok then.

> If you=20
> could have a patch like this, I can do a quick test on my machine.
>
Oh, that would be great. I'll put it together and send ASAP.

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)


--=-TGPC0RPmpCq6UMg9F5Ls
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)

iEYEABECAAYFAk8Wpf4ACgkQk4XaBE3IOsSnQACdFgfjnEVn0NuK8ZeDQXgIe+Ib
u9AAnj2mbSyyte9tO6V0rrD//2+G5IkR
=dhlW
-----END PGP SIGNATURE-----

--=-TGPC0RPmpCq6UMg9F5Ls--



--===============2025974472213284922==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2025974472213284922==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:06:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnTKU-0007QD-QW; Wed, 18 Jan 2012 11:05: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 1RnTKT-0007Pr-Bu
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:05:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326884714!3962764!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6376 invoked from network); 18 Jan 2012 11:05:15 -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;
	18 Jan 2012 11:05:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111975"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:05: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;
	Wed, 18 Jan 2012 11:05:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:05:13 +0000
In-Reply-To: <1326411330-7915-7-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-7-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326884714.14689.191.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> @@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
>      return rc;
>  }
> 
> +static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
> +{
> +    DECLARE_HYPERCALL;
> +    gnttab_setup_table_t setup_table;
> +    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
> +    int rc;
> +       unsigned long gmfn;

There's a bunch of weird alignment issues in this patch. Presumably some
hard tabs have snuck in.

> +
> +    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
> +       if (gmfnp == NULL)
> +               return -1;

Alignment.

> +
> +    setup_table.dom = domid;
> +    setup_table.nr_frames = 1;
> +    set_xen_guest_handle(setup_table.frame_list, gmfnp);
> +    setup_table.status = 0;
> +
> +    hypercall.op = __HYPERVISOR_grant_table_op;
> +    hypercall.arg[0] = GNTTABOP_setup_table;
> +    hypercall.arg[1] = (unsigned long) &setup_table;
> +    hypercall.arg[2] = 1;
> +
> +    rc = do_xen_hypercall(xch, &hypercall);
> +       gmfn = *gmfnp;

Alignment. I'm going to stop pointing these out, I guess grep will find
them...

[...]
> +int xc_dom_gnttab_init(struct xc_dom_image *dom)
> +{
> +    unsigned long console_gmfn;
> +    unsigned long xenstore_gmfn;
> +    int autotranslated;
> +
> +    autotranslated = xc_dom_feature_translated(dom);
> +    console_gmfn = autotranslated ?
> +           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
> +    xenstore_gmfn = autotranslated ?
> +           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
> +
> +    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
> +                              console_gmfn, xenstore_gmfn,
> +                              dom->console_domid, dom->xenstore_domid);

So on build we have can do the p2m lookup and hence use the PV version
of gnttab_seed, whereas on restore we don't have a p2m and hence can't?

The internals of xc_domain_restore do have the p2m though, so in
principal we could avoid the need for the hvm version and the
reintroduction of the remove_from_physmap by making xc_domain_restore
output the necessary mfns? I'm not sure it is worth it though.


> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..8bee684 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
> 
>  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,
> +                      uint32_t store_domid, unsigned int console_evtchn,
> +                      unsigned long *console_mfn, uint32_t console_domid,
>                        unsigned int hvm, unsigned int pae, int superpages,
>                        int no_incr_generationid,
>                        unsigned long *vm_generationid_addr)
> @@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
> 
> +    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
> +                            console_domid, store_domid);
> +    if (rc != 0)
> +    {
> +        ERROR("error seeding grant table");
> +        goto out;
> +    }
> +
>      DPRINTF("Domain ready to be built.\n");
>      rc = 0;
>      goto out;
> @@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>          goto out;
>      }
> 
> +    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
> +                                console_domid, store_domid);

Oh, we don't even need to return them from xc_domain_restore since we
could just translate from gfn to mfn right here (since we have a p2m in
hand) and call xc_dom_gnttab_seed. Or am I missing something?

> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 5e39595..04db22f 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
[...]
> @@ -305,6 +312,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
>      xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
>      xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
>      xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
> +
> +    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);

Didn't this already happen in xc_linux_build_internal which was called
via xc_linux_build_mem?

[...]
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:06:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnTKU-0007QD-QW; Wed, 18 Jan 2012 11:05: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 1RnTKT-0007Pr-Bu
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:05:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326884714!3962764!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6376 invoked from network); 18 Jan 2012 11:05:15 -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;
	18 Jan 2012 11:05:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10111975"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:05: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;
	Wed, 18 Jan 2012 11:05:14 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:05:13 +0000
In-Reply-To: <1326411330-7915-7-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-7-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326884714.14689.191.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> @@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
>      return rc;
>  }
> 
> +static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
> +{
> +    DECLARE_HYPERCALL;
> +    gnttab_setup_table_t setup_table;
> +    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
> +    int rc;
> +       unsigned long gmfn;

There's a bunch of weird alignment issues in this patch. Presumably some
hard tabs have snuck in.

> +
> +    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
> +       if (gmfnp == NULL)
> +               return -1;

Alignment.

> +
> +    setup_table.dom = domid;
> +    setup_table.nr_frames = 1;
> +    set_xen_guest_handle(setup_table.frame_list, gmfnp);
> +    setup_table.status = 0;
> +
> +    hypercall.op = __HYPERVISOR_grant_table_op;
> +    hypercall.arg[0] = GNTTABOP_setup_table;
> +    hypercall.arg[1] = (unsigned long) &setup_table;
> +    hypercall.arg[2] = 1;
> +
> +    rc = do_xen_hypercall(xch, &hypercall);
> +       gmfn = *gmfnp;

Alignment. I'm going to stop pointing these out, I guess grep will find
them...

[...]
> +int xc_dom_gnttab_init(struct xc_dom_image *dom)
> +{
> +    unsigned long console_gmfn;
> +    unsigned long xenstore_gmfn;
> +    int autotranslated;
> +
> +    autotranslated = xc_dom_feature_translated(dom);
> +    console_gmfn = autotranslated ?
> +           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
> +    xenstore_gmfn = autotranslated ?
> +           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
> +
> +    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
> +                              console_gmfn, xenstore_gmfn,
> +                              dom->console_domid, dom->xenstore_domid);

So on build we have can do the p2m lookup and hence use the PV version
of gnttab_seed, whereas on restore we don't have a p2m and hence can't?

The internals of xc_domain_restore do have the p2m though, so in
principal we could avoid the need for the hvm version and the
reintroduction of the remove_from_physmap by making xc_domain_restore
output the necessary mfns? I'm not sure it is worth it though.


> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..8bee684 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
> 
>  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,
> +                      uint32_t store_domid, unsigned int console_evtchn,
> +                      unsigned long *console_mfn, uint32_t console_domid,
>                        unsigned int hvm, unsigned int pae, int superpages,
>                        int no_incr_generationid,
>                        unsigned long *vm_generationid_addr)
> @@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
> 
> +    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
> +                            console_domid, store_domid);
> +    if (rc != 0)
> +    {
> +        ERROR("error seeding grant table");
> +        goto out;
> +    }
> +
>      DPRINTF("Domain ready to be built.\n");
>      rc = 0;
>      goto out;
> @@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>          goto out;
>      }
> 
> +    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
> +                                console_domid, store_domid);

Oh, we don't even need to return them from xc_domain_restore since we
could just translate from gfn to mfn right here (since we have a p2m in
hand) and call xc_dom_gnttab_seed. Or am I missing something?

> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 5e39595..04db22f 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
[...]
> @@ -305,6 +312,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
>      xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
>      xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
>      xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
> +
> +    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);

Didn't this already happen in xc_linux_build_internal which was called
via xc_linux_build_mem?

[...]
Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:06:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:06:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTLR-0007Y6-8n; Wed, 18 Jan 2012 11:06: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 1RnTLP-0007XR-Tq
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:06:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326884773!11327893!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5540 invoked from network); 18 Jan 2012 11:06:13 -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;
	18 Jan 2012 11:06:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112010"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:06:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:06:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:06:12 +0000
In-Reply-To: <1326411330-7915-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-8-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326884772.14689.192.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 07/18] mini-os: avoid crash if no console is
 provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/console/xencons_ring.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
> index 22fd618..14a8bd1 100644
> --- a/extras/mini-os/console/xencons_ring.c
> +++ b/extras/mini-os/console/xencons_ring.c
> @@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
>  
>  static inline struct xencons_interface *xencons_interface(void)
>  {
> -    return mfn_to_virt(start_info.console.domU.mfn);
> +    if (start_info.console.domU.evtchn)
> +        return mfn_to_virt(start_info.console.domU.mfn);
> +    else
> +        return NULL;
>  } 
>   
>  int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
> @@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
>              intf = xencons_interface();
>          else
>              intf = dev->ring;
> +    if (!intf)
> +        return sent;

Indentation. Otherwise

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although I would still prefer if we could figure out some scheme to get
logs out of this domain...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:06:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:06:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTLR-0007Y6-8n; Wed, 18 Jan 2012 11:06: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 1RnTLP-0007XR-Tq
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:06:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326884773!11327893!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5540 invoked from network); 18 Jan 2012 11:06:13 -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;
	18 Jan 2012 11:06:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112010"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:06:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:06:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:06:12 +0000
In-Reply-To: <1326411330-7915-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-8-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326884772.14689.192.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 07/18] mini-os: avoid crash if no console is
 provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/console/xencons_ring.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
> index 22fd618..14a8bd1 100644
> --- a/extras/mini-os/console/xencons_ring.c
> +++ b/extras/mini-os/console/xencons_ring.c
> @@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
>  
>  static inline struct xencons_interface *xencons_interface(void)
>  {
> -    return mfn_to_virt(start_info.console.domU.mfn);
> +    if (start_info.console.domU.evtchn)
> +        return mfn_to_virt(start_info.console.domU.mfn);
> +    else
> +        return NULL;
>  } 
>   
>  int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
> @@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
>              intf = xencons_interface();
>          else
>              intf = dev->ring;
> +    if (!intf)
> +        return sent;

Indentation. Otherwise

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Although I would still prefer if we could figure out some scheme to get
logs out of this domain...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:09:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:09:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTNW-0007lG-0q; Wed, 18 Jan 2012 11:08: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 1RnTNU-0007kx-6Z
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:08:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326884901!2702018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9840 invoked from network); 18 Jan 2012 11:08:21 -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;
	18 Jan 2012 11:08:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:08:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:08:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:08:21 +0000
In-Reply-To: <1326411330-7915-9-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-9-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326884901.14689.193.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 08/18] mini-os: avoid crash if no xenstore
 is provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I suppose we could arrange for xenbus to be omitted entirely but this is
easier.

Ian.

> ---
>  extras/mini-os/xenbus/xenbus.c |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
> index a8081fd..e475e2c 100644
> --- a/extras/mini-os/xenbus/xenbus.c
> +++ b/extras/mini-os/xenbus/xenbus.c
> @@ -328,6 +328,10 @@ static int allocate_xenbus_id(void)
>  void init_xenbus(void)
>  {
>      int err;
> +    if (!start_info.store_evtchn) {
> +        printk("Skipping initialization of xenbus\n");
> +        return;
> +    }
>      printk("Initialising xenbus\n");
>      DEBUG("init_xenbus called.\n");
>      xenstore_buf = mfn_to_virt(start_info.store_mfn);
> @@ -435,6 +439,11 @@ xenbus_msg_reply(int type,
>      DEFINE_WAIT(w);
>      struct xsd_sockmsg *rep;
>  
> +    if (!xenstore_buf) {
> +        printk("xenbus_msg_reply called but no xenstore!\n");
> +        return NULL;
> +    }
> +
>      id = allocate_xenbus_id();
>      add_waiter(w, req_info[id].waitq);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:09:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:09:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTNW-0007lG-0q; Wed, 18 Jan 2012 11:08: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 1RnTNU-0007kx-6Z
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:08:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326884901!2702018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9840 invoked from network); 18 Jan 2012 11:08:21 -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;
	18 Jan 2012 11:08:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:08:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:08:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:08:21 +0000
In-Reply-To: <1326411330-7915-9-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-9-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326884901.14689.193.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 08/18] mini-os: avoid crash if no xenstore
 is provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

I suppose we could arrange for xenbus to be omitted entirely but this is
easier.

Ian.

> ---
>  extras/mini-os/xenbus/xenbus.c |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
> index a8081fd..e475e2c 100644
> --- a/extras/mini-os/xenbus/xenbus.c
> +++ b/extras/mini-os/xenbus/xenbus.c
> @@ -328,6 +328,10 @@ static int allocate_xenbus_id(void)
>  void init_xenbus(void)
>  {
>      int err;
> +    if (!start_info.store_evtchn) {
> +        printk("Skipping initialization of xenbus\n");
> +        return;
> +    }
>      printk("Initialising xenbus\n");
>      DEBUG("init_xenbus called.\n");
>      xenstore_buf = mfn_to_virt(start_info.store_mfn);
> @@ -435,6 +439,11 @@ xenbus_msg_reply(int type,
>      DEFINE_WAIT(w);
>      struct xsd_sockmsg *rep;
>  
> +    if (!xenstore_buf) {
> +        printk("xenbus_msg_reply called but no xenstore!\n");
> +        return NULL;
> +    }
> +
>      id = allocate_xenbus_id();
>      add_waiter(w, req_info[id].waitq);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:11:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTQ0-00081k-PE; Wed, 18 Jan 2012 11:11: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 1RnTQ0-00081N-22
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:11:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326885057!2702583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20757 invoked from network); 18 Jan 2012 11:10:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 11:10:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:10: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, 18 Jan 2012 11:10:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:10:56 +0000
In-Reply-To: <1326411330-7915-10-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-10-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326885057.14689.195.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 09/18] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> Changes the minios evtchn implementation to use a list instead of an array.
> This allows it to grow as necessary to support any number of ports.
> Unfortunately, it's still limited by NR_EVS in events.c.

NR_EVS is 1024 which, IIRC, is the actual ABI limit for a 32 bit domain.
In principal we could make this 4096 for a 64 bit stub domain but I
guess we only need 1 evtchn per domain plus perhaps a couple of
incidental global ones (e.g. console, VIRQ_mumble) and ~1000+ domains is
more than enough for any current system.

> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  extras/mini-os/include/lib.h |   16 +++---
>  tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
>  2 files changed, 81 insertions(+), 74 deletions(-)
> 
> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> index bd3eeaf..12070c3 100644
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -53,6 +53,7 @@
>  #include <xen/xen.h>
>  #include <xen/event_channel.h>
>  #include "gntmap.h"
> +#include "list.h"
>  
>  #ifdef HAVE_LIBC
>  #include <stdio.h>
> @@ -143,7 +144,12 @@ enum fd_type {
>      FTYPE_SAVEFILE,
>  };
>  
> -#define MAX_EVTCHN_PORTS 16
> +struct evtchn_port_info {
> +        struct minios_list_head list;
> +        evtchn_port_t port;
> +        unsigned long pending;
> +        int bound;
> +};
>  
>  extern struct file {
>      enum fd_type type;
> @@ -158,13 +164,7 @@ extern struct file {
>  	    off_t offset;
>  	} file;
>  	struct {
> -            /* To each event channel FD is associated a series of ports which
> -             * wakes select for this FD. */
> -            struct {
> -                evtchn_port_t port;
> -                unsigned long pending;
> -                int bound;
> -            } ports[MAX_EVTCHN_PORTS];
> +	    struct minios_list_head ports;
>  	} evtchn;
>  	struct gntmap gntmap;
>  	struct {
> diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
> index 8bbfd18..29cce63 100644
> --- a/tools/libxc/xc_minios.c
> +++ b/tools/libxc/xc_minios.c
> @@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
>      },
>  };
>  
> +
> +/* XXX Note: This is not threadsafe */
> +static struct evtchn_port_info* port_alloc(int fd) {
> +    struct evtchn_port_info *port_info;
> +    port_info = malloc(sizeof(struct evtchn_port_info));
> +    if (port_info == NULL)
> +        return NULL;
> +    port_info->pending = 0;
> +    port_info->port = -1;
> +    port_info->bound = 0;
> +
> +    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
> +    return port_info;
> +}
> +
> +static void port_dealloc(struct evtchn_port_info *port_info) {
> +    if (port_info->bound)
> +        unbind_evtchn(port_info->port);
> +    minios_list_del(&port_info->list);
> +    free(port_info);
> +}
> +
>  static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
>  {
> -    int fd = alloc_fd(FTYPE_EVTCHN), i;
> +    int fd = alloc_fd(FTYPE_EVTCHN);
>      if ( fd == -1 )
>          return XC_OSDEP_OPEN_ERROR;
> -    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
> -	files[fd].evtchn.ports[i].port = -1;
> -        files[fd].evtchn.ports[i].bound = 0;
> -    }
> +    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
>      printf("evtchn_open() -> %d\n", fd);
>      return (xc_osdep_handle)fd;
>  }
> @@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
>  
>  void minios_evtchn_close_fd(int fd)
>  {
> -    int i;
> -    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
> -        if (files[fd].evtchn.ports[i].bound)
> -            unbind_evtchn(files[fd].evtchn.ports[i].port);
> +    struct evtchn_port_info *port_info, *tmp;
> +    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
> +        port_dealloc(port_info);
> +
>      files[fd].type = FTYPE_NONE;
>  }
>  
> @@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
>      return ret;
>  }
>  
> -/* XXX Note: This is not threadsafe */
> -static int port_alloc(int fd) {
> -    int i;
> -    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
> -	if (files[fd].evtchn.ports[i].port == -1)
> -	    break;
> -    if (i == MAX_EVTCHN_PORTS) {
> -	printf("Too many ports in xc handle\n");
> -	errno = EMFILE;
> -	return -1;
> -    }
> -    files[fd].evtchn.ports[i].pending = 0;
> -    return i;
> -}
> -
>  static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
>  {
>      int fd = (int)(intptr_t)data;
> -    int i;
> +    struct evtchn_port_info *port_info;
>      assert(files[fd].type == FTYPE_EVTCHN);
>      mask_evtchn(port);
> -    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
> -	if (files[fd].evtchn.ports[i].port == port)
> -	    break;
> -    if (i == MAX_EVTCHN_PORTS) {
> -	printk("Unknown port for handle %d\n", fd);
> -	return;
> +    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
> +        if (port_info->port == port)
> +            goto found;
>      }
> -    files[fd].evtchn.ports[i].pending = 1;
> +    printk("Unknown port for handle %d\n", fd);
> +    return;
> +
> + found:
> +    port_info->pending = 1;
>      files[fd].read = 1;
>      wake_up(&event_queue);
>  }
> @@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
>  static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
>  {
>      int fd = (int)h;
> -    int ret, i;
> +    struct evtchn_port_info *port_info;
> +    int ret;
>      evtchn_port_t port;
>  
>      assert(get_current() == main_thread);
> -    i = port_alloc(fd);
> -    if (i == -1)
> +    port_info = port_alloc(fd);
> +    if (port_info == NULL)
>  	return -1;
>  
>      printf("xc_evtchn_bind_unbound_port(%d)", domid);
> @@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
>      printf(" = %d\n", ret);
>  
>      if (ret < 0) {
> +	port_dealloc(port_info);
>  	errno = -ret;
>  	return -1;
>      }
> -    files[fd].evtchn.ports[i].bound = 1;
> -    files[fd].evtchn.ports[i].port = port;
> +    port_info->bound = 1;
> +    port_info->port = port;
>      unmask_evtchn(port);
>      return port;
>  }
> @@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
>      evtchn_port_t remote_port)
>  {
>      int fd = (int)h;
> +    struct evtchn_port_info *port_info;
>      evtchn_port_t local_port;
> -    int ret, i;
> +    int ret;
>  
>      assert(get_current() == main_thread);
> -    i = port_alloc(fd);
> -    if (i == -1)
> +    port_info = port_alloc(fd);
> +    if (port_info == NULL)
>  	return -1;
>  
>      printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
> @@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
>      printf(" = %d\n", ret);
>  
>      if (ret < 0) {
> +	port_dealloc(port_info);
>  	errno = -ret;
>  	return -1;
>      }
> -    files[fd].evtchn.ports[i].bound = 1;
> -    files[fd].evtchn.ports[i].port = local_port;
> +    port_info->bound = 1;
> +    port_info->port = local_port;
>      unmask_evtchn(local_port);
>      return local_port;
>  }
> @@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
>  static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
>  {
>      int fd = (int)h;
> -    int i;
> -    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
> -	if (files[fd].evtchn.ports[i].port == port) {
> -	    files[fd].evtchn.ports[i].port = -1;
> -	    break;
> -	}
> -    if (i == MAX_EVTCHN_PORTS) {
> -	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
> -	errno = -EINVAL;
> -	return -1;
> +    struct evtchn_port_info *port_info;
> +
> +    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
> +        if (port_info->port == port) {
> +            port_dealloc(port_info);
> +            return 0;
> +        }
>      }
> -    files[fd].evtchn.ports[i].bound = 0;
> -    unbind_evtchn(port);
> -    return 0;
> +    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
> +    errno = -EINVAL;
> +    return -1;
>  }
>  
>  static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
>  {
>      int fd = (int)h;
> +    struct evtchn_port_info *port_info;
>      evtchn_port_t port;
> -    int i;
>  
>      assert(get_current() == main_thread);
> -    i = port_alloc(fd);
> -    if (i == -1)
> +    port_info = port_alloc(fd);
> +    if (port_info == NULL)
>  	return -1;
>  
>      printf("xc_evtchn_bind_virq(%d)", virq);
>      port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
>  
>      if (port < 0) {
> +	port_dealloc(port_info);
>  	errno = -port;
>  	return -1;
>      }
> -    files[fd].evtchn.ports[i].bound = 1;
> -    files[fd].evtchn.ports[i].port = port;
> +    port_info->bound = 1;
> +    port_info->port = port;
>      unmask_evtchn(port);
>      return port;
>  }
> @@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
>  static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
>  {
>      int fd = (int)h;
> -    int i;
> +    struct evtchn_port_info *port_info;
>      unsigned long flags;
>      evtchn_port_t ret = -1;
>  
>      local_irq_save(flags);
>      files[fd].read = 0;
> -    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
> -        evtchn_port_t port = files[fd].evtchn.ports[i].port;
> -        if (port != -1 && files[fd].evtchn.ports[i].pending) {
> +
> +    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
> +        if (port_info->port != -1 && port_info->pending) {
>              if (ret == -1) {
> -                ret = port;
> -                files[fd].evtchn.ports[i].pending = 0;
> +                ret = port_info->port;
> +                port_info->pending = 0;
>              } else {
>                  files[fd].read = 1;
>                  break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:11:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTQ0-00081k-PE; Wed, 18 Jan 2012 11:11: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 1RnTQ0-00081N-22
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:11:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326885057!2702583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20757 invoked from network); 18 Jan 2012 11:10:57 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 11:10:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:10: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, 18 Jan 2012 11:10:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:10:56 +0000
In-Reply-To: <1326411330-7915-10-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-10-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326885057.14689.195.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 09/18] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> Changes the minios evtchn implementation to use a list instead of an array.
> This allows it to grow as necessary to support any number of ports.
> Unfortunately, it's still limited by NR_EVS in events.c.

NR_EVS is 1024 which, IIRC, is the actual ABI limit for a 32 bit domain.
In principal we could make this 4096 for a 64 bit stub domain but I
guess we only need 1 evtchn per domain plus perhaps a couple of
incidental global ones (e.g. console, VIRQ_mumble) and ~1000+ domains is
more than enough for any current system.

> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  extras/mini-os/include/lib.h |   16 +++---
>  tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
>  2 files changed, 81 insertions(+), 74 deletions(-)
> 
> diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
> index bd3eeaf..12070c3 100644
> --- a/extras/mini-os/include/lib.h
> +++ b/extras/mini-os/include/lib.h
> @@ -53,6 +53,7 @@
>  #include <xen/xen.h>
>  #include <xen/event_channel.h>
>  #include "gntmap.h"
> +#include "list.h"
>  
>  #ifdef HAVE_LIBC
>  #include <stdio.h>
> @@ -143,7 +144,12 @@ enum fd_type {
>      FTYPE_SAVEFILE,
>  };
>  
> -#define MAX_EVTCHN_PORTS 16
> +struct evtchn_port_info {
> +        struct minios_list_head list;
> +        evtchn_port_t port;
> +        unsigned long pending;
> +        int bound;
> +};
>  
>  extern struct file {
>      enum fd_type type;
> @@ -158,13 +164,7 @@ extern struct file {
>  	    off_t offset;
>  	} file;
>  	struct {
> -            /* To each event channel FD is associated a series of ports which
> -             * wakes select for this FD. */
> -            struct {
> -                evtchn_port_t port;
> -                unsigned long pending;
> -                int bound;
> -            } ports[MAX_EVTCHN_PORTS];
> +	    struct minios_list_head ports;
>  	} evtchn;
>  	struct gntmap gntmap;
>  	struct {
> diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
> index 8bbfd18..29cce63 100644
> --- a/tools/libxc/xc_minios.c
> +++ b/tools/libxc/xc_minios.c
> @@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
>      },
>  };
>  
> +
> +/* XXX Note: This is not threadsafe */
> +static struct evtchn_port_info* port_alloc(int fd) {
> +    struct evtchn_port_info *port_info;
> +    port_info = malloc(sizeof(struct evtchn_port_info));
> +    if (port_info == NULL)
> +        return NULL;
> +    port_info->pending = 0;
> +    port_info->port = -1;
> +    port_info->bound = 0;
> +
> +    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
> +    return port_info;
> +}
> +
> +static void port_dealloc(struct evtchn_port_info *port_info) {
> +    if (port_info->bound)
> +        unbind_evtchn(port_info->port);
> +    minios_list_del(&port_info->list);
> +    free(port_info);
> +}
> +
>  static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
>  {
> -    int fd = alloc_fd(FTYPE_EVTCHN), i;
> +    int fd = alloc_fd(FTYPE_EVTCHN);
>      if ( fd == -1 )
>          return XC_OSDEP_OPEN_ERROR;
> -    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
> -	files[fd].evtchn.ports[i].port = -1;
> -        files[fd].evtchn.ports[i].bound = 0;
> -    }
> +    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
>      printf("evtchn_open() -> %d\n", fd);
>      return (xc_osdep_handle)fd;
>  }
> @@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
>  
>  void minios_evtchn_close_fd(int fd)
>  {
> -    int i;
> -    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
> -        if (files[fd].evtchn.ports[i].bound)
> -            unbind_evtchn(files[fd].evtchn.ports[i].port);
> +    struct evtchn_port_info *port_info, *tmp;
> +    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
> +        port_dealloc(port_info);
> +
>      files[fd].type = FTYPE_NONE;
>  }
>  
> @@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
>      return ret;
>  }
>  
> -/* XXX Note: This is not threadsafe */
> -static int port_alloc(int fd) {
> -    int i;
> -    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
> -	if (files[fd].evtchn.ports[i].port == -1)
> -	    break;
> -    if (i == MAX_EVTCHN_PORTS) {
> -	printf("Too many ports in xc handle\n");
> -	errno = EMFILE;
> -	return -1;
> -    }
> -    files[fd].evtchn.ports[i].pending = 0;
> -    return i;
> -}
> -
>  static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
>  {
>      int fd = (int)(intptr_t)data;
> -    int i;
> +    struct evtchn_port_info *port_info;
>      assert(files[fd].type == FTYPE_EVTCHN);
>      mask_evtchn(port);
> -    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
> -	if (files[fd].evtchn.ports[i].port == port)
> -	    break;
> -    if (i == MAX_EVTCHN_PORTS) {
> -	printk("Unknown port for handle %d\n", fd);
> -	return;
> +    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
> +        if (port_info->port == port)
> +            goto found;
>      }
> -    files[fd].evtchn.ports[i].pending = 1;
> +    printk("Unknown port for handle %d\n", fd);
> +    return;
> +
> + found:
> +    port_info->pending = 1;
>      files[fd].read = 1;
>      wake_up(&event_queue);
>  }
> @@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
>  static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
>  {
>      int fd = (int)h;
> -    int ret, i;
> +    struct evtchn_port_info *port_info;
> +    int ret;
>      evtchn_port_t port;
>  
>      assert(get_current() == main_thread);
> -    i = port_alloc(fd);
> -    if (i == -1)
> +    port_info = port_alloc(fd);
> +    if (port_info == NULL)
>  	return -1;
>  
>      printf("xc_evtchn_bind_unbound_port(%d)", domid);
> @@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
>      printf(" = %d\n", ret);
>  
>      if (ret < 0) {
> +	port_dealloc(port_info);
>  	errno = -ret;
>  	return -1;
>      }
> -    files[fd].evtchn.ports[i].bound = 1;
> -    files[fd].evtchn.ports[i].port = port;
> +    port_info->bound = 1;
> +    port_info->port = port;
>      unmask_evtchn(port);
>      return port;
>  }
> @@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
>      evtchn_port_t remote_port)
>  {
>      int fd = (int)h;
> +    struct evtchn_port_info *port_info;
>      evtchn_port_t local_port;
> -    int ret, i;
> +    int ret;
>  
>      assert(get_current() == main_thread);
> -    i = port_alloc(fd);
> -    if (i == -1)
> +    port_info = port_alloc(fd);
> +    if (port_info == NULL)
>  	return -1;
>  
>      printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
> @@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
>      printf(" = %d\n", ret);
>  
>      if (ret < 0) {
> +	port_dealloc(port_info);
>  	errno = -ret;
>  	return -1;
>      }
> -    files[fd].evtchn.ports[i].bound = 1;
> -    files[fd].evtchn.ports[i].port = local_port;
> +    port_info->bound = 1;
> +    port_info->port = local_port;
>      unmask_evtchn(local_port);
>      return local_port;
>  }
> @@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
>  static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
>  {
>      int fd = (int)h;
> -    int i;
> -    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
> -	if (files[fd].evtchn.ports[i].port == port) {
> -	    files[fd].evtchn.ports[i].port = -1;
> -	    break;
> -	}
> -    if (i == MAX_EVTCHN_PORTS) {
> -	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
> -	errno = -EINVAL;
> -	return -1;
> +    struct evtchn_port_info *port_info;
> +
> +    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
> +        if (port_info->port == port) {
> +            port_dealloc(port_info);
> +            return 0;
> +        }
>      }
> -    files[fd].evtchn.ports[i].bound = 0;
> -    unbind_evtchn(port);
> -    return 0;
> +    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
> +    errno = -EINVAL;
> +    return -1;
>  }
>  
>  static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
>  {
>      int fd = (int)h;
> +    struct evtchn_port_info *port_info;
>      evtchn_port_t port;
> -    int i;
>  
>      assert(get_current() == main_thread);
> -    i = port_alloc(fd);
> -    if (i == -1)
> +    port_info = port_alloc(fd);
> +    if (port_info == NULL)
>  	return -1;
>  
>      printf("xc_evtchn_bind_virq(%d)", virq);
>      port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
>  
>      if (port < 0) {
> +	port_dealloc(port_info);
>  	errno = -port;
>  	return -1;
>      }
> -    files[fd].evtchn.ports[i].bound = 1;
> -    files[fd].evtchn.ports[i].port = port;
> +    port_info->bound = 1;
> +    port_info->port = port;
>      unmask_evtchn(port);
>      return port;
>  }
> @@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
>  static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
>  {
>      int fd = (int)h;
> -    int i;
> +    struct evtchn_port_info *port_info;
>      unsigned long flags;
>      evtchn_port_t ret = -1;
>  
>      local_irq_save(flags);
>      files[fd].read = 0;
> -    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
> -        evtchn_port_t port = files[fd].evtchn.ports[i].port;
> -        if (port != -1 && files[fd].evtchn.ports[i].pending) {
> +
> +    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
> +        if (port_info->port != -1 && port_info->pending) {
>              if (ret == -1) {
> -                ret = port;
> -                files[fd].evtchn.ports[i].pending = 0;
> +                ret = port_info->port;
> +                port_info->pending = 0;
>              } else {
>                  files[fd].read = 1;
>                  break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:16:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11: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 1RnTUQ-0008Iw-G9; Wed, 18 Jan 2012 11:15: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 1RnTUO-0008IY-QH
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:15:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326885264!61476948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26071 invoked from network); 18 Jan 2012 11:14: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;
	18 Jan 2012 11:14:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112235"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:15:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:15:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:15:30 +0000
In-Reply-To: <1326411330-7915-11-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-11-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326885330.14689.198.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/18] xenstored: use grant references
 instead of map_foreign_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 Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> make xenstored use grantref rather than map_foreign_range (which can
> only be used by privileged domains)
> 
> This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
> instead of xc_map_foreign_range where available.
> 
> Previous versions of this patch have been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_domain.c |   45 ++++++++++++++++++++++++++++++++-----
>  1 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 443af82..0b8353b 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -32,8 +32,10 @@
>  #include "xenstored_watch.h"
>  
>  #include <xenctrl.h>
> +#include <xen/grant_table.h>
>  
>  static xc_interface **xc_handle;
> +static xc_gnttab **xcg_handle;
>  static evtchn_port_t virq_port;
>  
>  xc_evtchn *xce_handle = NULL;
> @@ -174,8 +176,12 @@ static int destroy_domain(void *_domain)
>  			eprintf("> Unbinding port %i failed!\n", domain->port);
>  	}
>  
> -	if (domain->interface)
> -		munmap(domain->interface, getpagesize());
> +	if (domain->interface) {
> +		if (*xcg_handle >= 0 && domain->domid != 0)

Why the special case for domid 0 here? There seems to be no equivalent
for the map case, including the one you add in patch 15/18.

I think the map and unmap logic could usefully be made into helper
functions.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:16:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11: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 1RnTUQ-0008Iw-G9; Wed, 18 Jan 2012 11:15: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 1RnTUO-0008IY-QH
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:15:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326885264!61476948!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26071 invoked from network); 18 Jan 2012 11:14: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;
	18 Jan 2012 11:14:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112235"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:15:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:15:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:15:30 +0000
In-Reply-To: <1326411330-7915-11-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-11-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326885330.14689.198.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/18] xenstored: use grant references
 instead of map_foreign_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 Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> make xenstored use grantref rather than map_foreign_range (which can
> only be used by privileged domains)
> 
> This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
> instead of xc_map_foreign_range where available.
> 
> Previous versions of this patch have been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_domain.c |   45 ++++++++++++++++++++++++++++++++-----
>  1 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 443af82..0b8353b 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -32,8 +32,10 @@
>  #include "xenstored_watch.h"
>  
>  #include <xenctrl.h>
> +#include <xen/grant_table.h>
>  
>  static xc_interface **xc_handle;
> +static xc_gnttab **xcg_handle;
>  static evtchn_port_t virq_port;
>  
>  xc_evtchn *xce_handle = NULL;
> @@ -174,8 +176,12 @@ static int destroy_domain(void *_domain)
>  			eprintf("> Unbinding port %i failed!\n", domain->port);
>  	}
>  
> -	if (domain->interface)
> -		munmap(domain->interface, getpagesize());
> +	if (domain->interface) {
> +		if (*xcg_handle >= 0 && domain->domid != 0)

Why the special case for domid 0 here? There seems to be no equivalent
for the map case, including the one you add in patch 15/18.

I think the map and unmap logic could usefully be made into helper
functions.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:24:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTbt-0000PV-Pp; Wed, 18 Jan 2012 11:23:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnTbs-0000PO-OT
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:23:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326885793!2705220!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3929 invoked from network); 18 Jan 2012 11:23:14 -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;
	18 Jan 2012 11:23:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:23: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;
	Wed, 18 Jan 2012 11:23:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:23:12 +0000
In-Reply-To: <1326411330-7915-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326885793.14689.199.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 11/18] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> option for compiling xenstored without unix sockets to support running on mini-OS
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I guess this about as good as it gets, you could avoid some of the
ifdef's with "if (*sock != -1)" type constructions but I don't know that
this is necessarily better.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_core.c |   22 +++++++++++++++++++++-
>  tools/xenstore/xs.c             |    2 ++
>  tools/xenstore/xs_lib.c         |    4 ++++
>  3 files changed, 27 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 9e6c2c7..631bfe4 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -19,9 +19,11 @@
>  
>  #include <sys/types.h>
>  #include <sys/stat.h>
> -#include <sys/socket.h>
>  #include <sys/select.h>
> +#ifndef NO_SOCKETS
> +#include <sys/socket.h>
>  #include <sys/un.h>
> +#endif
>  #include <sys/time.h>
>  #include <time.h>
>  #include <unistd.h>
> @@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	FD_ZERO(inset);
>  	FD_ZERO(outset);
>  
> +#ifndef NO_SOCKETS
>  	set_fd(sock,               inset, &max);
>  	set_fd(ro_sock,            inset, &max);
> +#endif
>  	set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
> @@ -343,12 +347,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	return max;
>  }
>  
> +#ifndef NO_SOCKETS
>  static int destroy_fd(void *_fd)
>  {
>  	int *fd = _fd;
>  	close(*fd);
>  	return 0;
>  }
> +#endif
>  
>  /* Is child a subnode of parent, or equal? */
>  bool is_child(const char *child, const char *parent)
> @@ -1352,6 +1358,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
>  	return new;
>  }
>  
> +#ifndef NO_SOCKETS
>  static int writefd(struct connection *conn, const void *data, unsigned int len)
>  {
>  	int rc;
> @@ -1406,6 +1413,7 @@ static void accept_connection(int sock, bool canwrite)
>  	} else
>  		close(fd);
>  }
> +#endif
>  
>  #define TDB_FLAGS 0
>  
> @@ -1753,7 +1761,11 @@ extern void dump_conn(struct connection *conn);
>  int main(int argc, char *argv[])
>  {
>  	int opt, *sock, *ro_sock, max;
> +#ifdef NO_SOCKETS
> +	int minus_one = -1;
> +#else
>  	struct sockaddr_un addr;
> +#endif
>  	fd_set inset, outset;
>  	bool dofork = true;
>  	bool outputpid = false;
> @@ -1837,6 +1849,9 @@ int main(int argc, char *argv[])
>  	if (!dofork)
>  		talloc_enable_leak_report_full();
>  
> +#ifdef NO_SOCKETS
> +	sock = ro_sock = &minus_one;
> +#else
>  	/* Create sockets for them to listen to. */
>  	sock = talloc(talloc_autofree_context(), int);
>  	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
> @@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
>  		barf_perror("Could not create socket");
>  	talloc_set_destructor(sock, destroy_fd);
>  	talloc_set_destructor(ro_sock, destroy_fd);
> +#endif
>  
>  	/* Don't kill us with SIGPIPE. */
>  	signal(SIGPIPE, SIG_IGN);
>  
> +#ifndef NO_SOCKETS
>  	/* FIXME: Be more sophisticated, don't mug running daemon. */
>  	unlink(xs_daemon_socket());
>  	unlink(xs_daemon_socket_ro());
> @@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
>  	if (listen(*sock, 1) != 0
>  	    || listen(*ro_sock, 1) != 0)
>  		barf_perror("Could not listen on sockets");
> +#endif
>  
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
> @@ -1931,11 +1949,13 @@ int main(int argc, char *argv[])
>  			reopen_log();
>  		}
>  
> +#ifndef NO_SOCKETS
>  		if (FD_ISSET(*sock, &inset))
>  			accept_connection(*sock, true);
>  
>  		if (FD_ISSET(*ro_sock, &inset))
>  			accept_connection(*ro_sock, false);
> +#endif
>  
>  		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
>  			handle_event();
> diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> index 8e54fe0..119d945 100644
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
>  {
>  	struct xs_handle *xsh = NULL;
>  
> +#ifndef NO_SOCKETS
>  	if (flags & XS_OPEN_READONLY)
>  		xsh = get_handle(xs_daemon_socket_ro());
>  	else
>  		xsh = get_handle(xs_daemon_socket());
> +#endif
>  
>  	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
>  		xsh = get_handle(xs_domain_dev());
> diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
> index 03a9ee4..af3db6b 100644
> --- a/tools/xenstore/xs_lib.c
> +++ b/tools/xenstore/xs_lib.c
> @@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
>  	return (s ? s : "/var/run/xenstored");
>  }
>  
> +#ifndef NO_SOCKETS
>  static const char *xs_daemon_path(void)
>  {
>  	static char buf[PATH_MAX];
> @@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
>  		return NULL;
>  	return buf;
>  }
> +#endif
>  
>  const char *xs_daemon_tdb(void)
>  {
> @@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
>  	return buf;
>  }
>  
> +#ifndef NO_SOCKETS
>  const char *xs_daemon_socket(void)
>  {
>  	return xs_daemon_path();
> @@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
>  		return NULL;
>  	return buf;
>  }
> +#endif
>  
>  const char *xs_domain_dev(void)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:24:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:24:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTbt-0000PV-Pp; Wed, 18 Jan 2012 11:23:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnTbs-0000PO-OT
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:23:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326885793!2705220!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3929 invoked from network); 18 Jan 2012 11:23:14 -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;
	18 Jan 2012 11:23:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:23: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;
	Wed, 18 Jan 2012 11:23:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:23:12 +0000
In-Reply-To: <1326411330-7915-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326885793.14689.199.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 11/18] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> option for compiling xenstored without unix sockets to support running on mini-OS
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I guess this about as good as it gets, you could avoid some of the
ifdef's with "if (*sock != -1)" type constructions but I don't know that
this is necessarily better.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_core.c |   22 +++++++++++++++++++++-
>  tools/xenstore/xs.c             |    2 ++
>  tools/xenstore/xs_lib.c         |    4 ++++
>  3 files changed, 27 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 9e6c2c7..631bfe4 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -19,9 +19,11 @@
>  
>  #include <sys/types.h>
>  #include <sys/stat.h>
> -#include <sys/socket.h>
>  #include <sys/select.h>
> +#ifndef NO_SOCKETS
> +#include <sys/socket.h>
>  #include <sys/un.h>
> +#endif
>  #include <sys/time.h>
>  #include <time.h>
>  #include <unistd.h>
> @@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	FD_ZERO(inset);
>  	FD_ZERO(outset);
>  
> +#ifndef NO_SOCKETS
>  	set_fd(sock,               inset, &max);
>  	set_fd(ro_sock,            inset, &max);
> +#endif
>  	set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
> @@ -343,12 +347,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	return max;
>  }
>  
> +#ifndef NO_SOCKETS
>  static int destroy_fd(void *_fd)
>  {
>  	int *fd = _fd;
>  	close(*fd);
>  	return 0;
>  }
> +#endif
>  
>  /* Is child a subnode of parent, or equal? */
>  bool is_child(const char *child, const char *parent)
> @@ -1352,6 +1358,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
>  	return new;
>  }
>  
> +#ifndef NO_SOCKETS
>  static int writefd(struct connection *conn, const void *data, unsigned int len)
>  {
>  	int rc;
> @@ -1406,6 +1413,7 @@ static void accept_connection(int sock, bool canwrite)
>  	} else
>  		close(fd);
>  }
> +#endif
>  
>  #define TDB_FLAGS 0
>  
> @@ -1753,7 +1761,11 @@ extern void dump_conn(struct connection *conn);
>  int main(int argc, char *argv[])
>  {
>  	int opt, *sock, *ro_sock, max;
> +#ifdef NO_SOCKETS
> +	int minus_one = -1;
> +#else
>  	struct sockaddr_un addr;
> +#endif
>  	fd_set inset, outset;
>  	bool dofork = true;
>  	bool outputpid = false;
> @@ -1837,6 +1849,9 @@ int main(int argc, char *argv[])
>  	if (!dofork)
>  		talloc_enable_leak_report_full();
>  
> +#ifdef NO_SOCKETS
> +	sock = ro_sock = &minus_one;
> +#else
>  	/* Create sockets for them to listen to. */
>  	sock = talloc(talloc_autofree_context(), int);
>  	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
> @@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
>  		barf_perror("Could not create socket");
>  	talloc_set_destructor(sock, destroy_fd);
>  	talloc_set_destructor(ro_sock, destroy_fd);
> +#endif
>  
>  	/* Don't kill us with SIGPIPE. */
>  	signal(SIGPIPE, SIG_IGN);
>  
> +#ifndef NO_SOCKETS
>  	/* FIXME: Be more sophisticated, don't mug running daemon. */
>  	unlink(xs_daemon_socket());
>  	unlink(xs_daemon_socket_ro());
> @@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
>  	if (listen(*sock, 1) != 0
>  	    || listen(*ro_sock, 1) != 0)
>  		barf_perror("Could not listen on sockets");
> +#endif
>  
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
> @@ -1931,11 +1949,13 @@ int main(int argc, char *argv[])
>  			reopen_log();
>  		}
>  
> +#ifndef NO_SOCKETS
>  		if (FD_ISSET(*sock, &inset))
>  			accept_connection(*sock, true);
>  
>  		if (FD_ISSET(*ro_sock, &inset))
>  			accept_connection(*ro_sock, false);
> +#endif
>  
>  		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
>  			handle_event();
> diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> index 8e54fe0..119d945 100644
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
>  {
>  	struct xs_handle *xsh = NULL;
>  
> +#ifndef NO_SOCKETS
>  	if (flags & XS_OPEN_READONLY)
>  		xsh = get_handle(xs_daemon_socket_ro());
>  	else
>  		xsh = get_handle(xs_daemon_socket());
> +#endif
>  
>  	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
>  		xsh = get_handle(xs_domain_dev());
> diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
> index 03a9ee4..af3db6b 100644
> --- a/tools/xenstore/xs_lib.c
> +++ b/tools/xenstore/xs_lib.c
> @@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
>  	return (s ? s : "/var/run/xenstored");
>  }
>  
> +#ifndef NO_SOCKETS
>  static const char *xs_daemon_path(void)
>  {
>  	static char buf[PATH_MAX];
> @@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
>  		return NULL;
>  	return buf;
>  }
> +#endif
>  
>  const char *xs_daemon_tdb(void)
>  {
> @@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
>  	return buf;
>  }
>  
> +#ifndef NO_SOCKETS
>  const char *xs_daemon_socket(void)
>  {
>  	return xs_daemon_path();
> @@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
>  		return NULL;
>  	return buf;
>  }
> +#endif
>  
>  const char *xs_domain_dev(void)
>  {



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:28:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTgG-0000ls-72; Wed, 18 Jan 2012 11:27: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 1RnTgE-0000l0-E0
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:27:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326886064!9023052!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5556 invoked from network); 18 Jan 2012 11:27:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 11:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:27:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:27:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:27:43 +0000
In-Reply-To: <1326411330-7915-13-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-13-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326886063.14689.203.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 12/18] xenstored support for in-memory
 rather than FS based trivial DB (needed to run on mini-OS)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> tdb_copy (a xen modification to tdb?)

I believe so, the original author of xenstored was also the author of
tdb, IIRC.

>  should honor the TDB_INTERNAL flag
> for in-memory databases.
> 
> TODO: leaks memory on error case

Does this happen on every/any transaction conflict or just if a bad
thing has occurred?

In any case, is fixing it not just a case of calling talloc_free?

FWIW this bit of C xenstored is the main reason I think oxenstored
is/would be a better fit for a stub xenstored.


> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/tdb.c |   36 ++++++++++++++++++++++++++++++++++++
>  1 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
> index 63205e1..639ce6e 100644
> --- a/tools/xenstore/tdb.c
> +++ b/tools/xenstore/tdb.c
> @@ -2103,6 +2103,42 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
>  	int fd, saved_errno;
>  	TDB_CONTEXT *copy;
>  
> +	if (tdb->flags & TDB_INTERNAL) {
> +		struct tdb_header *copydb;
> +		
> +		copy = talloc_zero(outfile, TDB_CONTEXT);
> +		if (copy == NULL) {
> +			errno = ENOMEM;
> +			goto intfail;
> +		}
> +		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
> +
> +		if (copy->name || copy->locked || copy->device || copy->inode) {
> +			fprintf(stderr, "tdb_copy assumption(s) failed\n");
> +			goto intfail;
> +		}
> +
> +		copydb = talloc_zero_size(copy, copy->map_size);
> +		if (copydb == NULL) {
> +			errno = ENOMEM;
> +			goto intfail;
> +		}
> +		memcpy(copydb, copy->map_ptr, copy->map_size);
> +		copy->map_ptr = (char*) copydb;
> +
> +		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
> +			goto intfail;
> +
> +		copy->next = tdbs;
> +		tdbs = copy;
> +
> +
> +		return copy;
> +intfail:
> +		/* TODO (leaking memory is easier) */
> +		return NULL;
> +	}
> +
>  	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
>  	if (fd < 0)
>  		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 Jan 18 11:28:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:28:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTgG-0000ls-72; Wed, 18 Jan 2012 11:27: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 1RnTgE-0000l0-E0
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:27:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326886064!9023052!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5556 invoked from network); 18 Jan 2012 11:27:44 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 11:27:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112560"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:27:43 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:27:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:27:43 +0000
In-Reply-To: <1326411330-7915-13-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-13-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326886063.14689.203.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 12/18] xenstored support for in-memory
 rather than FS based trivial DB (needed to run on mini-OS)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> tdb_copy (a xen modification to tdb?)

I believe so, the original author of xenstored was also the author of
tdb, IIRC.

>  should honor the TDB_INTERNAL flag
> for in-memory databases.
> 
> TODO: leaks memory on error case

Does this happen on every/any transaction conflict or just if a bad
thing has occurred?

In any case, is fixing it not just a case of calling talloc_free?

FWIW this bit of C xenstored is the main reason I think oxenstored
is/would be a better fit for a stub xenstored.


> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/tdb.c |   36 ++++++++++++++++++++++++++++++++++++
>  1 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
> index 63205e1..639ce6e 100644
> --- a/tools/xenstore/tdb.c
> +++ b/tools/xenstore/tdb.c
> @@ -2103,6 +2103,42 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
>  	int fd, saved_errno;
>  	TDB_CONTEXT *copy;
>  
> +	if (tdb->flags & TDB_INTERNAL) {
> +		struct tdb_header *copydb;
> +		
> +		copy = talloc_zero(outfile, TDB_CONTEXT);
> +		if (copy == NULL) {
> +			errno = ENOMEM;
> +			goto intfail;
> +		}
> +		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
> +
> +		if (copy->name || copy->locked || copy->device || copy->inode) {
> +			fprintf(stderr, "tdb_copy assumption(s) failed\n");
> +			goto intfail;
> +		}
> +
> +		copydb = talloc_zero_size(copy, copy->map_size);
> +		if (copydb == NULL) {
> +			errno = ENOMEM;
> +			goto intfail;
> +		}
> +		memcpy(copydb, copy->map_ptr, copy->map_size);
> +		copy->map_ptr = (char*) copydb;
> +
> +		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
> +			goto intfail;
> +
> +		copy->next = tdbs;
> +		tdbs = copy;
> +
> +
> +		return copy;
> +intfail:
> +		/* TODO (leaking memory is easier) */
> +		return NULL;
> +	}
> +
>  	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
>  	if (fd < 0)
>  		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 Jan 18 11:29:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:29:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTgl-0000q0-M5; Wed, 18 Jan 2012 11:28:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RnTgk-0000p8-LO
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:28:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326886095!9023165!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 7548 invoked from network); 18 Jan 2012 11:28:16 -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; 18 Jan 2012 11:28:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 11:28:15 +0000
Message-Id: <4F16BADD020000780006D6BA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 11:28:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
	<1326883141.14689.177.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326883141.14689.177.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 18.01.12 at 11:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> 
>> +static void clear_global_virq_handlers(struct domain *d)
>> +{
>> +    uint32_t virq;
>> +    int put_count = 0;
>> +
>> +    spin_lock(&global_virq_handlers_lock);
>> +
>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>> +        if (global_virq_handlers[virq] == d) {
>> +            global_virq_handlers[virq] = NULL;
> 
> I don't suppose we should rebind to dom0, should we? 

Storing NULL here effectively means re-binding to Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:29:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:29:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTgl-0000q0-M5; Wed, 18 Jan 2012 11:28:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RnTgk-0000p8-LO
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:28:22 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326886095!9023165!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 7548 invoked from network); 18 Jan 2012 11:28:16 -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; 18 Jan 2012 11:28:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 11:28:15 +0000
Message-Id: <4F16BADD020000780006D6BA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 11:28:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
	<1326883141.14689.177.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326883141.14689.177.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 18.01.12 at 11:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> 
>> +static void clear_global_virq_handlers(struct domain *d)
>> +{
>> +    uint32_t virq;
>> +    int put_count = 0;
>> +
>> +    spin_lock(&global_virq_handlers_lock);
>> +
>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>> +        if (global_virq_handlers[virq] == d) {
>> +            global_virq_handlers[virq] = NULL;
> 
> I don't suppose we should rebind to dom0, should we? 

Storing NULL here effectively means re-binding to Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:29:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTh4-0000tx-9t; Wed, 18 Jan 2012 11:28:42 +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 1RnTh2-0000sb-DC
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:28:40 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326886113!9637101!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTU0Njk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27014 invoked from network); 18 Jan 2012 11:28:34 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 11:28:34 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 1DACC1793;
	Wed, 18 Jan 2012 13:28:12 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D2E0F200B0; Wed, 18 Jan 2012 13:28:12 +0200 (EET)
Date: Wed, 18 Jan 2012 13:28:12 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120118112812.GR12984@reaktio.net>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117210225.GA23782@phenom.dumpdata.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.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 Tue, Jan 17, 2012 at 04:02:25PM -0500, Konrad Rzeszutek Wilk wrote:
> > 
> > And the devices do work ... so how does that work ...
> 
> Most (all?) drivers are written to work with bounce-buffering.
> That has never been a problem.
> 
> The issue as I understand is that the DVB drivers allocate their buffers
> from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> 
> While the pv-ops one ends up quite frequently doing the bounce-buffering, which
> implies that the DVB drivers end up allocating their buffers above the 4GB.
> This means we end up spending some CPU time (in the guest) copying the memory
> from >4GB to 0-4GB region (And vice-versa).
> 
> And I am not clear why this is happening. Hence my thought
> was to run an Xen-O-Linux kernel v2.6.3X and a PVOPS v2.6.3X (where X is the
> same) with the same PCI device (and the test would entail rebooting the
> box in between the launches) to confirm that the Xen-O-Linux is doing something
> that the PVOPS is not.
> 
> So far, I've haven't had much luck compiling a Xen-O-Linux v2.6.38 kernel
> so :-(
> 

Did you try downloading a binary rpm (or src.rpm) from OpenSuse? 
I think they have 2.6.38 xenlinux kernel available.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:29:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:29:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTh4-0000tx-9t; Wed, 18 Jan 2012 11:28:42 +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 1RnTh2-0000sb-DC
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:28:40 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326886113!9637101!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTU0Njk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27014 invoked from network); 18 Jan 2012 11:28:34 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 11:28:34 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 1DACC1793;
	Wed, 18 Jan 2012 13:28:12 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id D2E0F200B0; Wed, 18 Jan 2012 13:28:12 +0200 (EET)
Date: Wed, 18 Jan 2012 13:28:12 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120118112812.GR12984@reaktio.net>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120117210225.GA23782@phenom.dumpdata.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.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 Tue, Jan 17, 2012 at 04:02:25PM -0500, Konrad Rzeszutek Wilk wrote:
> > 
> > And the devices do work ... so how does that work ...
> 
> Most (all?) drivers are written to work with bounce-buffering.
> That has never been a problem.
> 
> The issue as I understand is that the DVB drivers allocate their buffers
> from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> 
> While the pv-ops one ends up quite frequently doing the bounce-buffering, which
> implies that the DVB drivers end up allocating their buffers above the 4GB.
> This means we end up spending some CPU time (in the guest) copying the memory
> from >4GB to 0-4GB region (And vice-versa).
> 
> And I am not clear why this is happening. Hence my thought
> was to run an Xen-O-Linux kernel v2.6.3X and a PVOPS v2.6.3X (where X is the
> same) with the same PCI device (and the test would entail rebooting the
> box in between the launches) to confirm that the Xen-O-Linux is doing something
> that the PVOPS is not.
> 
> So far, I've haven't had much luck compiling a Xen-O-Linux v2.6.38 kernel
> so :-(
> 

Did you try downloading a binary rpm (or src.rpm) from OpenSuse? 
I think they have 2.6.38 xenlinux kernel available.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:34:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTm2-0001gr-Sg; Wed, 18 Jan 2012 11:33:50 +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 1RnTm0-0001gP-TQ
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:33:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326886421!11387979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23197 invoked from network); 18 Jan 2012 11:33: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;
	18 Jan 2012 11:33:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:33:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:33:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:33:40 +0000
In-Reply-To: <1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326886420.14689.206.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/18] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Originally-by: Diego Ongaro <diego.ongaro@citrix.com>
> Originally-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

There's a lot of ifdefery here. I don't have any particularly cunning
plans to improve it though :-(

One thing which might help is to provide nop versions of functions
instead of idef'ing both the definition and callsite. e.g. 
 static void write_pidfile(const char *pidfile)
+#ifndef __MINIOS__
     stuff
+#else
+    nothing
+endif

then you avoid another ifdef at the place which calls write_pidfile. I'm
not sure that pattern helps with many of the instances here though.

> ---
>  extras/mini-os/include/list.h          |    6 ++--
>  extras/mini-os/main.c                  |    4 +++
>  stubdom/Makefile                       |   29 +++++++++++++++++--
>  tools/xenstore/Makefile                |    9 +++++-
>  tools/xenstore/tdb.c                   |    6 ++--
>  tools/xenstore/utils.h                 |    2 +
>  tools/xenstore/xenstored_core.c        |   47 ++++++++++++++++++++++++++++++-
>  tools/xenstore/xenstored_domain.c      |    7 +++++
>  tools/xenstore/xenstored_transaction.c |    2 +
>  9 files changed, 100 insertions(+), 12 deletions(-)
> 
> diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
> index a60ae23..4e6a2ac 100644
> --- a/extras/mini-os/include/list.h
> +++ b/extras/mini-os/include/list.h
> @@ -1,5 +1,5 @@
> -#ifndef _LINUX_LIST_H
> -#define _LINUX_LIST_H
> +#ifndef _MINIOS_LIST_H
> +#define _MINIOS_LIST_H
> 
>  /*
>   * Simple doubly linked list implementation.
> @@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
>                 n = minios_list_entry(pos->member.next, typeof(*pos), member);  \
>              &pos->member != (head);                                    \
>              pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
> -#endif /* _LINUX_LIST_H */
> +#endif /* _MINIOS_LIST_H */
> 
> diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
> index b95b889..cd89849 100644
> --- a/extras/mini-os/main.c
> +++ b/extras/mini-os/main.c
> @@ -60,6 +60,7 @@ static void call_main(void *p)
>       * crashing. */
>      //sleep(1);
> 
> +#ifndef CONFIG_XENSTORE
>  #ifndef CONFIG_GRUB
>      sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
>  #if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
> @@ -67,6 +68,7 @@ static void call_main(void *p)
>  #endif
>  #endif
>      create_thread("pcifront", pcifront_watches, NULL);
> +#endif
> 
>  #ifdef CONFIG_QEMU
>      /* Fetch argc, argv from XenStore */
> @@ -169,9 +171,11 @@ void _exit(int ret)
>      close_all_files();
>      __libc_fini_array();
>      printk("main returned %d\n", ret);
> +#ifndef CONFIG_XENSTORE
>  #ifdef HAVE_LWIP
>      stop_networking();
>  #endif
> +#endif
>      stop_kernel();
>      if (!ret) {
>         /* No problem, just shutdown.  */
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 3705059..e0a90a9 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
> 
>  TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
> 
> -TARGETS=ioemu c caml grub
> +TARGETS=ioemu c caml grub xenstore
> 
>  CROSS_MAKE := $(MAKE) DESTDIR=
> 
>  .PHONY: all
>  all: build
>  ifeq ($(STUBDOM_SUPPORTED),1)
> -build: genpath ioemu-stubdom c-stubdom pv-grub
> +build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
>  else
>  build: genpath
>  endif
> @@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
>           ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
>           ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
>           ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
> +       mkdir -p xenstore
> +       [ -h xenstore/Makefile ] || ( cd xenstore && \
> +         ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
> +         ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
> +         ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
>         $(CROSS_MAKE) -C $(MINI_OS) links
>         touch mk-headers-$(XEN_TARGET_ARCH)
> 
> @@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
>         mkdir -p grub-$(XEN_TARGET_ARCH)
>         CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
> 
> +##########
> +# xenstore
> +##########
> +
> +.PHONY: xenstore
> +xenstore: $(CROSS_ROOT)
> +       CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
> +
>  ########
>  # minios
>  ########
> @@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
>  pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
>         DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
> 
> +.PHONY: xenstore-stubdom
> +xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
> +       DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_XENSTORE $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
> +
>  #########
>  # install
>  #########
> 
>  ifeq ($(STUBDOM_SUPPORTED),1)
> -install: genpath install-readme install-ioemu install-grub
> +install: genpath install-readme install-ioemu install-grub install-xenstore
>  else
>  install: genpath
>  endif
> @@ -379,6 +396,10 @@ install-grub: pv-grub
>         $(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
>         $(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
> 
> +install-xenstore: xenstore-stubdom
> +       $(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
> +       $(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
> +
>  #######
>  # clean
>  #######
> @@ -390,12 +411,14 @@ clean:
>         rm -fr mini-os-$(XEN_TARGET_ARCH)-c
>         rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
>         rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
> +       rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
>         $(CROSS_MAKE) -C caml clean
>         $(CROSS_MAKE) -C c clean
>         rm -fr grub-$(XEN_TARGET_ARCH)
>         rm -f $(STUBDOMPATH)
>         [ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
>         -[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
> +       -[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
> 
>  # clean the cross-compilation result
>  .PHONY: crossclean
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 4facb62..3a061d6 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -28,6 +28,10 @@ endif
> 
>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
> 
> +ifdef CONFIG_STUBDOM
> +CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
> +endif
> +
>  .PHONY: all
>  all: $(ALL_TARGETS)
> 
> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
> 
>  CFLAGS += -DHAVE_DTRACE=1
>  endif
> -
> +
>  xenstored: $(XENSTORED_OBJS)
>         $(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> 
> +xenstored.a: $(XENSTORED_OBJS)
> +       $(AR) cr $@ $^
> +
>  $(CLIENTS): xenstore
>         ln -f xenstore $@
> 
> diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
> index 639ce6e..75ffd2a 100644
> --- a/tools/xenstore/tdb.c
> +++ b/tools/xenstore/tdb.c
> @@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
> 
>                 /* Iterate through chain */
>                 while( tlock->off) {
> -                       tdb_off current;
> +                       tdb_off mycurrent;
>                         if (rec_read(tdb, tlock->off, rec) == -1)
>                                 goto fail;
> 
> @@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>                         }
> 
>                         /* Try to clean dead ones from old traverses */
> -                       current = tlock->off;
> +                       mycurrent = tlock->off;
>                         tlock->off = rec->next;
>                         if (!tdb->read_only &&
> -                           do_delete(tdb, current, rec) != 0)
> +                           do_delete(tdb, mycurrent, rec) != 0)
>                                 goto fail;
>                 }
>                 tdb_unlock(tdb, tlock->hash, F_WRLCK);
> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
> index f378343..2effd17 100644
> --- a/tools/xenstore/utils.h
> +++ b/tools/xenstore/utils.h
> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>         return streq(a + strlen(a) - strlen(b), b);
>  }
> 
> +#ifndef ARRAY_SIZE
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
> 
>  void barf(const char *fmt, ...) __attribute__((noreturn));
>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 631bfe4..e51f2ad 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -32,7 +32,9 @@
>  #include <stdio.h>
>  #include <stdarg.h>
>  #include <stdlib.h>
> +#ifndef NO_SYSLOG
>  #include <syslog.h>
> +#endif
>  #include <string.h>
>  #include <errno.h>
>  #include <dirent.h>
> @@ -61,13 +63,24 @@ LIST_HEAD(connections);
>  static int tracefd = -1;
>  static bool recovery = true;
>  static bool remove_local = true;
> +#ifndef NO_REOPEN_LOG
>  static int reopen_log_pipe[2];
> +#endif
>  static char *tracefile = NULL;
>  static TDB_CONTEXT *tdb_ctx;
> 
>  static void corrupt(struct connection *conn, const char *fmt, ...);
>  static void check_store(void);
> 
> +#ifdef __MINIOS__
> +#define lockf(...) (-ENOSYS)
> +#endif
> +
> +#ifdef NO_SYSLOG
> +#define openlog(...) ((void) 0)
> +#define syslog(...)  ((void) 0)
> +#endif
> +
>  #define log(...)                                                       \
>         do {                                                            \
>                 char *s = talloc_asprintf(NULL, __VA_ARGS__);           \
> @@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
> 
>  bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
>  {
> +#ifndef __MINIOS__
>         if (rename(newname, xs_daemon_tdb()) != 0)
>                 return false;
> +#endif
>         tdb_close(tdb_ctx);
>         tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
>         return true;
> @@ -195,6 +210,7 @@ void trace_destroy(const void *data, const char *type)
>         trace("DESTROY %s %p\n", type, data);
>  }
> 
> +#ifndef NO_REOPEN_LOG
>  /**
>   * Signal handler for SIGHUP, which requests that the trace log is reopened
>   * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
> @@ -222,7 +238,7 @@ static void reopen_log(void)
>                         trace("\n***\n");
>         }
>  }
> -
> +#endif
> 
>  static bool write_messages(struct connection *conn)
>  {
> @@ -326,7 +342,9 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>         set_fd(sock,               inset, &max);
>         set_fd(ro_sock,            inset, &max);
>  #endif
> +#ifndef NO_REOPEN_LOG
>         set_fd(reopen_log_pipe[0], inset, &max);
> +#endif
> 
>         if (xce_handle != NULL)
>                 set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1415,7 +1433,11 @@ static void accept_connection(int sock, bool canwrite)
>  }
>  #endif
> 
> +#ifdef __MINIOS__
> +#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
> +#else
>  #define TDB_FLAGS 0
> +#endif
> 
>  /* We create initial nodes manually. */
>  static void manual_node(const char *name, const char *child)
> @@ -1440,7 +1462,11 @@ static void setup_structure(void)
>  {
>         char *tdbname;
>         tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
> +#ifdef __MINIOS__
> +       tdb_ctx = NULL;
> +#else
>         tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
> +#endif
> 
>         if (tdb_ctx) {
>                 /* XXX When we make xenstored able to restart, this will have
> @@ -1666,6 +1692,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
> 
> 
> +#ifndef __MINIOS__
>  static void write_pidfile(const char *pidfile)
>  {
>         char buf[100];
> @@ -1712,7 +1739,7 @@ static void daemonize(void)
>         /* Discard our parent's old-fashioned umask prejudices. */
>         umask(0);
>  }
> -
> +#endif
> 
>  static void usage(void)
>  {
> @@ -1767,7 +1794,11 @@ int main(int argc, char *argv[])
>         struct sockaddr_un addr;
>  #endif
>         fd_set inset, outset;
> +#ifdef __MINIOS__
> +       bool dofork = false;
> +#else
>         bool dofork = true;
> +#endif
>         bool outputpid = false;
>         bool no_domain_init = false;
>         const char *pidfile = NULL;
> @@ -1821,8 +1852,11 @@ int main(int argc, char *argv[])
>         if (optind != argc)
>                 barf("%s: No arguments desired", argv[0]);
> 
> +#ifndef NO_REOPEN_LOG
>         reopen_log();
> +#endif
> 
> +#ifndef __MINIOS__
>         /* make sure xenstored directory exists */
>         if (mkdir(xs_daemon_rundir(), 0755)) {
>                 if (errno != EEXIST) {
> @@ -1844,6 +1878,7 @@ int main(int argc, char *argv[])
>         }
>         if (pidfile)
>                 write_pidfile(pidfile);
> +#endif
> 
>         /* Talloc leak reports go to stderr, which is closed if we fork. */
>         if (!dofork)
> @@ -1890,9 +1925,11 @@ int main(int argc, char *argv[])
>                 barf_perror("Could not listen on sockets");
>  #endif
> 
> +#ifndef NO_REOPEN_LOG
>         if (pipe(reopen_log_pipe)) {
>                 barf_perror("pipe");
>         }
> +#endif
> 
>         /* Setup the database */
>         setup_structure();
> @@ -1921,7 +1958,9 @@ int main(int argc, char *argv[])
>                 xprintf = trace;
>         }
> 
> +#ifndef NO_REOPEN_LOG
>         signal(SIGHUP, trigger_reopen_log);
> +#endif
> 
>         if (xce_handle != NULL)
>                 evtchn_fd = xc_evtchn_fd(xce_handle);
> @@ -1929,8 +1968,10 @@ int main(int argc, char *argv[])
>         /* Get ready to listen to the tools. */
>         max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
> 
> +#ifndef __MINIOS__
>         /* Tell the kernel we're up and running. */
>         xenbus_notify_running();
> +#endif
> 
>         /* Main loop. */
>         for (;;) {
> @@ -1942,12 +1983,14 @@ int main(int argc, char *argv[])
>                         barf_perror("Select failed");
>                 }
> 
> +#ifndef NO_REOPEN_LOG
>                 if (FD_ISSET(reopen_log_pipe[0], &inset)) {
>                         char c;
>                         if (read(reopen_log_pipe[0], &c, 1) != 1)
>                                 barf_perror("read failed");
>                         reopen_log();
>                 }
> +#endif
> 
>  #ifndef NO_SOCKETS
>                 if (FD_ISSET(*sock, &inset))
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 0b8353b..811ae3c 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -588,6 +588,12 @@ void restore_existing_connections(void)
>  {
>  }
> 
> +#ifdef __MINIOS__
> +static inline int dom0_init(void)
> +{
> +       return 0;
> +}
> +#else
>  static int dom0_init(void)
>  {
>         evtchn_port_t port;
> @@ -611,6 +617,7 @@ static int dom0_init(void)
> 
>         return 0;
>  }
> +#endif
> 
>  void domain_init(void)
>  {
> diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
> index 380c691..c59acfb 100644
> --- a/tools/xenstore/xenstored_transaction.c
> +++ b/tools/xenstore/xenstored_transaction.c
> @@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
>         trace_destroy(trans, "transaction");
>         if (trans->tdb)
>                 tdb_close(trans->tdb);
> +#ifndef __MINIOS__
>         unlink(trans->tdb_name);
> +#endif
>         return 0;
>  }
> 
> --
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:34:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:34:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTm2-0001gr-Sg; Wed, 18 Jan 2012 11:33:50 +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 1RnTm0-0001gP-TQ
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:33:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326886421!11387979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23197 invoked from network); 18 Jan 2012 11:33: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;
	18 Jan 2012 11:33:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112699"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:33:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:33:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:33:40 +0000
In-Reply-To: <1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326886420.14689.206.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/18] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Originally-by: Diego Ongaro <diego.ongaro@citrix.com>
> Originally-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

There's a lot of ifdefery here. I don't have any particularly cunning
plans to improve it though :-(

One thing which might help is to provide nop versions of functions
instead of idef'ing both the definition and callsite. e.g. 
 static void write_pidfile(const char *pidfile)
+#ifndef __MINIOS__
     stuff
+#else
+    nothing
+endif

then you avoid another ifdef at the place which calls write_pidfile. I'm
not sure that pattern helps with many of the instances here though.

> ---
>  extras/mini-os/include/list.h          |    6 ++--
>  extras/mini-os/main.c                  |    4 +++
>  stubdom/Makefile                       |   29 +++++++++++++++++--
>  tools/xenstore/Makefile                |    9 +++++-
>  tools/xenstore/tdb.c                   |    6 ++--
>  tools/xenstore/utils.h                 |    2 +
>  tools/xenstore/xenstored_core.c        |   47 ++++++++++++++++++++++++++++++-
>  tools/xenstore/xenstored_domain.c      |    7 +++++
>  tools/xenstore/xenstored_transaction.c |    2 +
>  9 files changed, 100 insertions(+), 12 deletions(-)
> 
> diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
> index a60ae23..4e6a2ac 100644
> --- a/extras/mini-os/include/list.h
> +++ b/extras/mini-os/include/list.h
> @@ -1,5 +1,5 @@
> -#ifndef _LINUX_LIST_H
> -#define _LINUX_LIST_H
> +#ifndef _MINIOS_LIST_H
> +#define _MINIOS_LIST_H
> 
>  /*
>   * Simple doubly linked list implementation.
> @@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
>                 n = minios_list_entry(pos->member.next, typeof(*pos), member);  \
>              &pos->member != (head);                                    \
>              pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
> -#endif /* _LINUX_LIST_H */
> +#endif /* _MINIOS_LIST_H */
> 
> diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
> index b95b889..cd89849 100644
> --- a/extras/mini-os/main.c
> +++ b/extras/mini-os/main.c
> @@ -60,6 +60,7 @@ static void call_main(void *p)
>       * crashing. */
>      //sleep(1);
> 
> +#ifndef CONFIG_XENSTORE
>  #ifndef CONFIG_GRUB
>      sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
>  #if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
> @@ -67,6 +68,7 @@ static void call_main(void *p)
>  #endif
>  #endif
>      create_thread("pcifront", pcifront_watches, NULL);
> +#endif
> 
>  #ifdef CONFIG_QEMU
>      /* Fetch argc, argv from XenStore */
> @@ -169,9 +171,11 @@ void _exit(int ret)
>      close_all_files();
>      __libc_fini_array();
>      printk("main returned %d\n", ret);
> +#ifndef CONFIG_XENSTORE
>  #ifdef HAVE_LWIP
>      stop_networking();
>  #endif
> +#endif
>      stop_kernel();
>      if (!ret) {
>         /* No problem, just shutdown.  */
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 3705059..e0a90a9 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
> 
>  TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
> 
> -TARGETS=ioemu c caml grub
> +TARGETS=ioemu c caml grub xenstore
> 
>  CROSS_MAKE := $(MAKE) DESTDIR=
> 
>  .PHONY: all
>  all: build
>  ifeq ($(STUBDOM_SUPPORTED),1)
> -build: genpath ioemu-stubdom c-stubdom pv-grub
> +build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
>  else
>  build: genpath
>  endif
> @@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
>           ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
>           ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
>           ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
> +       mkdir -p xenstore
> +       [ -h xenstore/Makefile ] || ( cd xenstore && \
> +         ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
> +         ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
> +         ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
>         $(CROSS_MAKE) -C $(MINI_OS) links
>         touch mk-headers-$(XEN_TARGET_ARCH)
> 
> @@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
>         mkdir -p grub-$(XEN_TARGET_ARCH)
>         CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
> 
> +##########
> +# xenstore
> +##########
> +
> +.PHONY: xenstore
> +xenstore: $(CROSS_ROOT)
> +       CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
> +
>  ########
>  # minios
>  ########
> @@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
>  pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
>         DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
> 
> +.PHONY: xenstore-stubdom
> +xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
> +       DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_XENSTORE $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
> +
>  #########
>  # install
>  #########
> 
>  ifeq ($(STUBDOM_SUPPORTED),1)
> -install: genpath install-readme install-ioemu install-grub
> +install: genpath install-readme install-ioemu install-grub install-xenstore
>  else
>  install: genpath
>  endif
> @@ -379,6 +396,10 @@ install-grub: pv-grub
>         $(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
>         $(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
> 
> +install-xenstore: xenstore-stubdom
> +       $(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
> +       $(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
> +
>  #######
>  # clean
>  #######
> @@ -390,12 +411,14 @@ clean:
>         rm -fr mini-os-$(XEN_TARGET_ARCH)-c
>         rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
>         rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
> +       rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
>         $(CROSS_MAKE) -C caml clean
>         $(CROSS_MAKE) -C c clean
>         rm -fr grub-$(XEN_TARGET_ARCH)
>         rm -f $(STUBDOMPATH)
>         [ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
>         -[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
> +       -[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
> 
>  # clean the cross-compilation result
>  .PHONY: crossclean
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 4facb62..3a061d6 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -28,6 +28,10 @@ endif
> 
>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
> 
> +ifdef CONFIG_STUBDOM
> +CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
> +endif
> +
>  .PHONY: all
>  all: $(ALL_TARGETS)
> 
> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
> 
>  CFLAGS += -DHAVE_DTRACE=1
>  endif
> -
> +
>  xenstored: $(XENSTORED_OBJS)
>         $(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
> 
> +xenstored.a: $(XENSTORED_OBJS)
> +       $(AR) cr $@ $^
> +
>  $(CLIENTS): xenstore
>         ln -f xenstore $@
> 
> diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
> index 639ce6e..75ffd2a 100644
> --- a/tools/xenstore/tdb.c
> +++ b/tools/xenstore/tdb.c
> @@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
> 
>                 /* Iterate through chain */
>                 while( tlock->off) {
> -                       tdb_off current;
> +                       tdb_off mycurrent;
>                         if (rec_read(tdb, tlock->off, rec) == -1)
>                                 goto fail;
> 
> @@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>                         }
> 
>                         /* Try to clean dead ones from old traverses */
> -                       current = tlock->off;
> +                       mycurrent = tlock->off;
>                         tlock->off = rec->next;
>                         if (!tdb->read_only &&
> -                           do_delete(tdb, current, rec) != 0)
> +                           do_delete(tdb, mycurrent, rec) != 0)
>                                 goto fail;
>                 }
>                 tdb_unlock(tdb, tlock->hash, F_WRLCK);
> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
> index f378343..2effd17 100644
> --- a/tools/xenstore/utils.h
> +++ b/tools/xenstore/utils.h
> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>         return streq(a + strlen(a) - strlen(b), b);
>  }
> 
> +#ifndef ARRAY_SIZE
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
> 
>  void barf(const char *fmt, ...) __attribute__((noreturn));
>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 631bfe4..e51f2ad 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -32,7 +32,9 @@
>  #include <stdio.h>
>  #include <stdarg.h>
>  #include <stdlib.h>
> +#ifndef NO_SYSLOG
>  #include <syslog.h>
> +#endif
>  #include <string.h>
>  #include <errno.h>
>  #include <dirent.h>
> @@ -61,13 +63,24 @@ LIST_HEAD(connections);
>  static int tracefd = -1;
>  static bool recovery = true;
>  static bool remove_local = true;
> +#ifndef NO_REOPEN_LOG
>  static int reopen_log_pipe[2];
> +#endif
>  static char *tracefile = NULL;
>  static TDB_CONTEXT *tdb_ctx;
> 
>  static void corrupt(struct connection *conn, const char *fmt, ...);
>  static void check_store(void);
> 
> +#ifdef __MINIOS__
> +#define lockf(...) (-ENOSYS)
> +#endif
> +
> +#ifdef NO_SYSLOG
> +#define openlog(...) ((void) 0)
> +#define syslog(...)  ((void) 0)
> +#endif
> +
>  #define log(...)                                                       \
>         do {                                                            \
>                 char *s = talloc_asprintf(NULL, __VA_ARGS__);           \
> @@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
> 
>  bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
>  {
> +#ifndef __MINIOS__
>         if (rename(newname, xs_daemon_tdb()) != 0)
>                 return false;
> +#endif
>         tdb_close(tdb_ctx);
>         tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
>         return true;
> @@ -195,6 +210,7 @@ void trace_destroy(const void *data, const char *type)
>         trace("DESTROY %s %p\n", type, data);
>  }
> 
> +#ifndef NO_REOPEN_LOG
>  /**
>   * Signal handler for SIGHUP, which requests that the trace log is reopened
>   * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
> @@ -222,7 +238,7 @@ static void reopen_log(void)
>                         trace("\n***\n");
>         }
>  }
> -
> +#endif
> 
>  static bool write_messages(struct connection *conn)
>  {
> @@ -326,7 +342,9 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>         set_fd(sock,               inset, &max);
>         set_fd(ro_sock,            inset, &max);
>  #endif
> +#ifndef NO_REOPEN_LOG
>         set_fd(reopen_log_pipe[0], inset, &max);
> +#endif
> 
>         if (xce_handle != NULL)
>                 set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1415,7 +1433,11 @@ static void accept_connection(int sock, bool canwrite)
>  }
>  #endif
> 
> +#ifdef __MINIOS__
> +#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
> +#else
>  #define TDB_FLAGS 0
> +#endif
> 
>  /* We create initial nodes manually. */
>  static void manual_node(const char *name, const char *child)
> @@ -1440,7 +1462,11 @@ static void setup_structure(void)
>  {
>         char *tdbname;
>         tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
> +#ifdef __MINIOS__
> +       tdb_ctx = NULL;
> +#else
>         tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
> +#endif
> 
>         if (tdb_ctx) {
>                 /* XXX When we make xenstored able to restart, this will have
> @@ -1666,6 +1692,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
> 
> 
> +#ifndef __MINIOS__
>  static void write_pidfile(const char *pidfile)
>  {
>         char buf[100];
> @@ -1712,7 +1739,7 @@ static void daemonize(void)
>         /* Discard our parent's old-fashioned umask prejudices. */
>         umask(0);
>  }
> -
> +#endif
> 
>  static void usage(void)
>  {
> @@ -1767,7 +1794,11 @@ int main(int argc, char *argv[])
>         struct sockaddr_un addr;
>  #endif
>         fd_set inset, outset;
> +#ifdef __MINIOS__
> +       bool dofork = false;
> +#else
>         bool dofork = true;
> +#endif
>         bool outputpid = false;
>         bool no_domain_init = false;
>         const char *pidfile = NULL;
> @@ -1821,8 +1852,11 @@ int main(int argc, char *argv[])
>         if (optind != argc)
>                 barf("%s: No arguments desired", argv[0]);
> 
> +#ifndef NO_REOPEN_LOG
>         reopen_log();
> +#endif
> 
> +#ifndef __MINIOS__
>         /* make sure xenstored directory exists */
>         if (mkdir(xs_daemon_rundir(), 0755)) {
>                 if (errno != EEXIST) {
> @@ -1844,6 +1878,7 @@ int main(int argc, char *argv[])
>         }
>         if (pidfile)
>                 write_pidfile(pidfile);
> +#endif
> 
>         /* Talloc leak reports go to stderr, which is closed if we fork. */
>         if (!dofork)
> @@ -1890,9 +1925,11 @@ int main(int argc, char *argv[])
>                 barf_perror("Could not listen on sockets");
>  #endif
> 
> +#ifndef NO_REOPEN_LOG
>         if (pipe(reopen_log_pipe)) {
>                 barf_perror("pipe");
>         }
> +#endif
> 
>         /* Setup the database */
>         setup_structure();
> @@ -1921,7 +1958,9 @@ int main(int argc, char *argv[])
>                 xprintf = trace;
>         }
> 
> +#ifndef NO_REOPEN_LOG
>         signal(SIGHUP, trigger_reopen_log);
> +#endif
> 
>         if (xce_handle != NULL)
>                 evtchn_fd = xc_evtchn_fd(xce_handle);
> @@ -1929,8 +1968,10 @@ int main(int argc, char *argv[])
>         /* Get ready to listen to the tools. */
>         max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
> 
> +#ifndef __MINIOS__
>         /* Tell the kernel we're up and running. */
>         xenbus_notify_running();
> +#endif
> 
>         /* Main loop. */
>         for (;;) {
> @@ -1942,12 +1983,14 @@ int main(int argc, char *argv[])
>                         barf_perror("Select failed");
>                 }
> 
> +#ifndef NO_REOPEN_LOG
>                 if (FD_ISSET(reopen_log_pipe[0], &inset)) {
>                         char c;
>                         if (read(reopen_log_pipe[0], &c, 1) != 1)
>                                 barf_perror("read failed");
>                         reopen_log();
>                 }
> +#endif
> 
>  #ifndef NO_SOCKETS
>                 if (FD_ISSET(*sock, &inset))
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 0b8353b..811ae3c 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -588,6 +588,12 @@ void restore_existing_connections(void)
>  {
>  }
> 
> +#ifdef __MINIOS__
> +static inline int dom0_init(void)
> +{
> +       return 0;
> +}
> +#else
>  static int dom0_init(void)
>  {
>         evtchn_port_t port;
> @@ -611,6 +617,7 @@ static int dom0_init(void)
> 
>         return 0;
>  }
> +#endif
> 
>  void domain_init(void)
>  {
> diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
> index 380c691..c59acfb 100644
> --- a/tools/xenstore/xenstored_transaction.c
> +++ b/tools/xenstore/xenstored_transaction.c
> @@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
>         trace_destroy(trans, "transaction");
>         if (trans->tdb)
>                 tdb_close(trans->tdb);
> +#ifndef __MINIOS__
>         unlink(trans->tdb_name);
> +#endif
>         return 0;
>  }
> 
> --
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:36:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11: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 1RnTnv-0001rm-E4; Wed, 18 Jan 2012 11:35:47 +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 1RnTnt-0001r4-5E
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:35:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326886538!1555322!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 27391 invoked from network); 18 Jan 2012 11:35:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jan 2012 11:35:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 11:35:38 +0000
Message-Id: <4F16BC97020000780006D6D6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 11:35:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
In-Reply-To: <20120117210225.GA23782@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.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 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The issue as I understand is that the DVB drivers allocate their buffers
> from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> 
> While the pv-ops one ends up quite frequently doing the bounce-buffering, 
> which
> implies that the DVB drivers end up allocating their buffers above the 4GB.
> This means we end up spending some CPU time (in the guest) copying the 
> memory
> from >4GB to 0-4GB region (And vice-versa).

This reminds me of something (not sure what XenoLinux you use for
comparison) - how are they allocating that memory? Not vmalloc_32()
by chance (I remember having seen numerous uses under - iirc -
drivers/media/)?

Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
what their (driver) callers might expect in a PV guest (including the
contiguity assumption for the latter, recalling that you earlier said
you were able to see the problem after several guest starts), and I
had put into our kernels an adjustment to make vmalloc_32() actually
behave as expected.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:36:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11: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 1RnTnv-0001rm-E4; Wed, 18 Jan 2012 11:35:47 +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 1RnTnt-0001r4-5E
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:35:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326886538!1555322!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 27391 invoked from network); 18 Jan 2012 11:35:38 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jan 2012 11:35:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 11:35:38 +0000
Message-Id: <4F16BC97020000780006D6D6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 11:35:35 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Sander Eikelenboom" <linux@eikelenboom.it>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
In-Reply-To: <20120117210225.GA23782@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.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 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> The issue as I understand is that the DVB drivers allocate their buffers
> from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> 
> While the pv-ops one ends up quite frequently doing the bounce-buffering, 
> which
> implies that the DVB drivers end up allocating their buffers above the 4GB.
> This means we end up spending some CPU time (in the guest) copying the 
> memory
> from >4GB to 0-4GB region (And vice-versa).

This reminds me of something (not sure what XenoLinux you use for
comparison) - how are they allocating that memory? Not vmalloc_32()
by chance (I remember having seen numerous uses under - iirc -
drivers/media/)?

Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
what their (driver) callers might expect in a PV guest (including the
contiguity assumption for the latter, recalling that you earlier said
you were able to see the problem after several guest starts), and I
had put into our kernels an adjustment to make vmalloc_32() actually
behave as expected.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:36:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnToB-0001uS-SE; Wed, 18 Jan 2012 11:36: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 1RnToA-0001tV-Td
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:36:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326886556!8805285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14759 invoked from network); 18 Jan 2012 11:35:57 -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;
	18 Jan 2012 11:35:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:35: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, 18 Jan 2012 11:35:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:35:56 +0000
In-Reply-To: <1326411330-7915-16-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-16-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326886556.14689.208.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/18] xenstored: add --event parameter for
 bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> When xenstored is run in a minios domain, it needs a bootstrap
> connection to dom0 so that additional domain introduce messages can be
> sent to it.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_core.c   |    5 +++++
>  tools/xenstore/xenstored_core.h   |    1 +
>  tools/xenstore/xenstored_domain.c |   13 ++++++++++++-
>  3 files changed, 18 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index e51f2ad..4ec63f1 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -1771,6 +1771,7 @@ static struct option options[] = {
>  	{ "no-domain-init", 0, NULL, 'D' },
>  	{ "entry-nb", 1, NULL, 'E' },
>  	{ "pid-file", 1, NULL, 'F' },
> +	{ "event", 1, NULL, 'e' },
>  	{ "help", 0, NULL, 'H' },
>  	{ "no-fork", 0, NULL, 'N' },
>  	{ "output-pid", 0, NULL, 'P' },
> @@ -1784,6 +1785,7 @@ static struct option options[] = {
>  	{ NULL, 0, NULL, 0 } };
>  
>  extern void dump_conn(struct connection *conn); 
> +int dom0_event = 0;
>  
>  int main(int argc, char *argv[])
>  {
> @@ -1847,6 +1849,9 @@ int main(int argc, char *argv[])
>  		case 'W':
>  			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
>  			break;
> +		case 'e':
> +			dom0_event = strtol(optarg, NULL, 10);
> +			break;
>  		}
>  	}
>  	if (optind != argc)
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index c487089..d3040ba 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
>  void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
>  
>  extern int event_fd;
> +extern int dom0_event;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index aca2149..648eb1d 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -593,8 +593,19 @@ void restore_existing_connections(void)
>  }
>  
>  #ifdef __MINIOS__
> -static inline int dom0_init(void) 
> +static int dom0_init(void)
>  {
> +	struct domain *domain;
> +	int domid = 0;
> +	evtchn_port_t port = dom0_event;
> +
> +	domain = new_domain(NULL, domid, port);
> +	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
> +			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
> +	talloc_steal(domain->conn, domain);
> +
> +	xc_evtchn_notify(xce_handle, domain->port);
> +
>  	return 0;
>  }
>  #else



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:36:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnToB-0001uS-SE; Wed, 18 Jan 2012 11:36: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 1RnToA-0001tV-Td
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:36:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1326886556!8805285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14759 invoked from network); 18 Jan 2012 11:35:57 -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;
	18 Jan 2012 11:35:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:35: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, 18 Jan 2012 11:35:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:35:56 +0000
In-Reply-To: <1326411330-7915-16-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-16-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326886556.14689.208.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/18] xenstored: add --event parameter for
 bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> When xenstored is run in a minios domain, it needs a bootstrap
> connection to dom0 so that additional domain introduce messages can be
> sent to it.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_core.c   |    5 +++++
>  tools/xenstore/xenstored_core.h   |    1 +
>  tools/xenstore/xenstored_domain.c |   13 ++++++++++++-
>  3 files changed, 18 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index e51f2ad..4ec63f1 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -1771,6 +1771,7 @@ static struct option options[] = {
>  	{ "no-domain-init", 0, NULL, 'D' },
>  	{ "entry-nb", 1, NULL, 'E' },
>  	{ "pid-file", 1, NULL, 'F' },
> +	{ "event", 1, NULL, 'e' },
>  	{ "help", 0, NULL, 'H' },
>  	{ "no-fork", 0, NULL, 'N' },
>  	{ "output-pid", 0, NULL, 'P' },
> @@ -1784,6 +1785,7 @@ static struct option options[] = {
>  	{ NULL, 0, NULL, 0 } };
>  
>  extern void dump_conn(struct connection *conn); 
> +int dom0_event = 0;
>  
>  int main(int argc, char *argv[])
>  {
> @@ -1847,6 +1849,9 @@ int main(int argc, char *argv[])
>  		case 'W':
>  			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
>  			break;
> +		case 'e':
> +			dom0_event = strtol(optarg, NULL, 10);
> +			break;
>  		}
>  	}
>  	if (optind != argc)
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index c487089..d3040ba 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
>  void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
>  
>  extern int event_fd;
> +extern int dom0_event;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index aca2149..648eb1d 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -593,8 +593,19 @@ void restore_existing_connections(void)
>  }
>  
>  #ifdef __MINIOS__
> -static inline int dom0_init(void) 
> +static int dom0_init(void)
>  {
> +	struct domain *domain;
> +	int domid = 0;
> +	evtchn_port_t port = dom0_event;
> +
> +	domain = new_domain(NULL, domid, port);
> +	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
> +			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
> +	talloc_steal(domain->conn, domain);
> +
> +	xc_evtchn_notify(xce_handle, domain->port);
> +
>  	return 0;
>  }
>  #else



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:39:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11: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 1RnTrH-0002Ie-ND; Wed, 18 Jan 2012 11:39:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RnTrF-0002Hb-Qr
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:39:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326886747!9025572!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 17752 invoked from network); 18 Jan 2012 11:39:07 -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; 18 Jan 2012 11:39:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 11:39:07 +0000
Message-Id: <4F16BD67020000780006D6E0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 11:39:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?=" <pasik@iki.fi>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<20120118112812.GR12984@reaktio.net>
In-Reply-To: <20120118112812.GR12984@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.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

Pj4+IE9uIDE4LjAxLjEyIGF0IDEyOjI4LCBQYXNpIEvDpHJra8OkaW5lbjxwYXNpa0Bpa2kuZmk+
IHdyb3RlOgo+IE9uIFR1ZSwgSmFuIDE3LCAyMDEyIGF0IDA0OjAyOjI1UE0gLTA1MDAsIEtvbnJh
ZCBSemVzenV0ZWsgV2lsayB3cm90ZToKPj4gPiAKPj4gPiBBbmQgdGhlIGRldmljZXMgZG8gd29y
ayAuLi4gc28gaG93IGRvZXMgdGhhdCB3b3JrIC4uLgo+PiAKPj4gTW9zdCAoYWxsPykgZHJpdmVy
cyBhcmUgd3JpdHRlbiB0byB3b3JrIHdpdGggYm91bmNlLWJ1ZmZlcmluZy4KPj4gVGhhdCBoYXMg
bmV2ZXIgYmVlbiBhIHByb2JsZW0uCj4+IAo+PiBUaGUgaXNzdWUgYXMgSSB1bmRlcnN0YW5kIGlz
IHRoYXQgdGhlIERWQiBkcml2ZXJzIGFsbG9jYXRlIHRoZWlyIGJ1ZmZlcnMKPj4gZnJvbSAwLT40
R0IgbW9zdCAoYWxsIHRoZSB0aW1lPykgc28gdGhleSBuZXZlciBoYXZlIHRvIGRvIGJvdW5jZS1i
dWZmZXJpbmcuCj4+IAo+PiBXaGlsZSB0aGUgcHYtb3BzIG9uZSBlbmRzIHVwIHF1aXRlIGZyZXF1
ZW50bHkgZG9pbmcgdGhlIGJvdW5jZS1idWZmZXJpbmcsIAo+IHdoaWNoCj4+IGltcGxpZXMgdGhh
dCB0aGUgRFZCIGRyaXZlcnMgZW5kIHVwIGFsbG9jYXRpbmcgdGhlaXIgYnVmZmVycyBhYm92ZSB0
aGUgNEdCLgo+PiBUaGlzIG1lYW5zIHdlIGVuZCB1cCBzcGVuZGluZyBzb21lIENQVSB0aW1lIChp
biB0aGUgZ3Vlc3QpIGNvcHlpbmcgdGhlIAo+IG1lbW9yeQo+PiBmcm9tID40R0IgdG8gMC00R0Ig
cmVnaW9uIChBbmQgdmljZS12ZXJzYSkuCj4+IAo+PiBBbmQgSSBhbSBub3QgY2xlYXIgd2h5IHRo
aXMgaXMgaGFwcGVuaW5nLiBIZW5jZSBteSB0aG91Z2h0Cj4+IHdhcyB0byBydW4gYW4gWGVuLU8t
TGludXgga2VybmVsIHYyLjYuM1ggYW5kIGEgUFZPUFMgdjIuNi4zWCAod2hlcmUgWCBpcyB0aGUK
Pj4gc2FtZSkgd2l0aCB0aGUgc2FtZSBQQ0kgZGV2aWNlIChhbmQgdGhlIHRlc3Qgd291bGQgZW50
YWlsIHJlYm9vdGluZyB0aGUKPj4gYm94IGluIGJldHdlZW4gdGhlIGxhdW5jaGVzKSB0byBjb25m
aXJtIHRoYXQgdGhlIFhlbi1PLUxpbnV4IGlzIGRvaW5nIAo+IHNvbWV0aGluZwo+PiB0aGF0IHRo
ZSBQVk9QUyBpcyBub3QuCj4+IAo+PiBTbyBmYXIsIEkndmUgaGF2ZW4ndCBoYWQgbXVjaCBsdWNr
IGNvbXBpbGluZyBhIFhlbi1PLUxpbnV4IHYyLjYuMzgga2VybmVsCj4+IHNvIDotKAo+PiAKPiAK
PiBEaWQgeW91IHRyeSBkb3dubG9hZGluZyBhIGJpbmFyeSBycG0gKG9yIHNyYy5ycG0pIGZyb20g
T3BlblN1c2U/IAo+IEkgdGhpbmsgdGhleSBoYXZlIDIuNi4zOCB4ZW5saW51eCBrZXJuZWwgYXZh
aWxhYmxlLgoKb3BlblNVU0UgMTEuNCBpcyB1c2luZyAyLjYuMzc7IDEyLjEgaXMgb24gMy4xIChh
bmQgU0xFIGlzIG9uIDMuMCkuClB1bGxpbmcgb3V0IChjb25zaXN0ZW50KSBwYXRjaGVzIGF0IDIu
Ni4zOCBsZXZlbCBtaWdodCBiZSBhIGxpdHRsZQppbnZvbHZlZC4KCkphbgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:39:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11: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 1RnTrH-0002Ie-ND; Wed, 18 Jan 2012 11:39:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RnTrF-0002Hb-Qr
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:39:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1326886747!9025572!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 17752 invoked from network); 18 Jan 2012 11:39:07 -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; 18 Jan 2012 11:39:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 11:39:07 +0000
Message-Id: <4F16BD67020000780006D6E0@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 11:39:03 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "=?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?=" <pasik@iki.fi>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<20120118112812.GR12984@reaktio.net>
In-Reply-To: <20120118112812.GR12984@reaktio.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.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

Pj4+IE9uIDE4LjAxLjEyIGF0IDEyOjI4LCBQYXNpIEvDpHJra8OkaW5lbjxwYXNpa0Bpa2kuZmk+
IHdyb3RlOgo+IE9uIFR1ZSwgSmFuIDE3LCAyMDEyIGF0IDA0OjAyOjI1UE0gLTA1MDAsIEtvbnJh
ZCBSemVzenV0ZWsgV2lsayB3cm90ZToKPj4gPiAKPj4gPiBBbmQgdGhlIGRldmljZXMgZG8gd29y
ayAuLi4gc28gaG93IGRvZXMgdGhhdCB3b3JrIC4uLgo+PiAKPj4gTW9zdCAoYWxsPykgZHJpdmVy
cyBhcmUgd3JpdHRlbiB0byB3b3JrIHdpdGggYm91bmNlLWJ1ZmZlcmluZy4KPj4gVGhhdCBoYXMg
bmV2ZXIgYmVlbiBhIHByb2JsZW0uCj4+IAo+PiBUaGUgaXNzdWUgYXMgSSB1bmRlcnN0YW5kIGlz
IHRoYXQgdGhlIERWQiBkcml2ZXJzIGFsbG9jYXRlIHRoZWlyIGJ1ZmZlcnMKPj4gZnJvbSAwLT40
R0IgbW9zdCAoYWxsIHRoZSB0aW1lPykgc28gdGhleSBuZXZlciBoYXZlIHRvIGRvIGJvdW5jZS1i
dWZmZXJpbmcuCj4+IAo+PiBXaGlsZSB0aGUgcHYtb3BzIG9uZSBlbmRzIHVwIHF1aXRlIGZyZXF1
ZW50bHkgZG9pbmcgdGhlIGJvdW5jZS1idWZmZXJpbmcsIAo+IHdoaWNoCj4+IGltcGxpZXMgdGhh
dCB0aGUgRFZCIGRyaXZlcnMgZW5kIHVwIGFsbG9jYXRpbmcgdGhlaXIgYnVmZmVycyBhYm92ZSB0
aGUgNEdCLgo+PiBUaGlzIG1lYW5zIHdlIGVuZCB1cCBzcGVuZGluZyBzb21lIENQVSB0aW1lIChp
biB0aGUgZ3Vlc3QpIGNvcHlpbmcgdGhlIAo+IG1lbW9yeQo+PiBmcm9tID40R0IgdG8gMC00R0Ig
cmVnaW9uIChBbmQgdmljZS12ZXJzYSkuCj4+IAo+PiBBbmQgSSBhbSBub3QgY2xlYXIgd2h5IHRo
aXMgaXMgaGFwcGVuaW5nLiBIZW5jZSBteSB0aG91Z2h0Cj4+IHdhcyB0byBydW4gYW4gWGVuLU8t
TGludXgga2VybmVsIHYyLjYuM1ggYW5kIGEgUFZPUFMgdjIuNi4zWCAod2hlcmUgWCBpcyB0aGUK
Pj4gc2FtZSkgd2l0aCB0aGUgc2FtZSBQQ0kgZGV2aWNlIChhbmQgdGhlIHRlc3Qgd291bGQgZW50
YWlsIHJlYm9vdGluZyB0aGUKPj4gYm94IGluIGJldHdlZW4gdGhlIGxhdW5jaGVzKSB0byBjb25m
aXJtIHRoYXQgdGhlIFhlbi1PLUxpbnV4IGlzIGRvaW5nIAo+IHNvbWV0aGluZwo+PiB0aGF0IHRo
ZSBQVk9QUyBpcyBub3QuCj4+IAo+PiBTbyBmYXIsIEkndmUgaGF2ZW4ndCBoYWQgbXVjaCBsdWNr
IGNvbXBpbGluZyBhIFhlbi1PLUxpbnV4IHYyLjYuMzgga2VybmVsCj4+IHNvIDotKAo+PiAKPiAK
PiBEaWQgeW91IHRyeSBkb3dubG9hZGluZyBhIGJpbmFyeSBycG0gKG9yIHNyYy5ycG0pIGZyb20g
T3BlblN1c2U/IAo+IEkgdGhpbmsgdGhleSBoYXZlIDIuNi4zOCB4ZW5saW51eCBrZXJuZWwgYXZh
aWxhYmxlLgoKb3BlblNVU0UgMTEuNCBpcyB1c2luZyAyLjYuMzc7IDEyLjEgaXMgb24gMy4xIChh
bmQgU0xFIGlzIG9uIDMuMCkuClB1bGxpbmcgb3V0IChjb25zaXN0ZW50KSBwYXRjaGVzIGF0IDIu
Ni4zOCBsZXZlbCBtaWdodCBiZSBhIGxpdHRsZQppbnZvbHZlZC4KCkphbgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:44:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTw3-0002ud-Gq; Wed, 18 Jan 2012 11: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 1RnTw2-0002tz-KZ
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:44:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326887044!11411644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27955 invoked from network); 18 Jan 2012 11:44:04 -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;
	18 Jan 2012 11:44:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:44: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, 18 Jan 2012 11:44:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 18 Jan 2012 11:44:03 +0000
In-Reply-To: <4F16BADD020000780006D6BA@nat28.tlf.novell.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
	<1326883141.14689.177.camel@zakaz.uk.xensource.com>
	<4F16BADD020000780006D6BA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326887043.14689.213.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 Wed, 2012-01-18 at 11:28 +0000, Jan Beulich wrote:
> >>> On 18.01.12 at 11:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> >> 
> >> +static void clear_global_virq_handlers(struct domain *d)
> >> +{
> >> +    uint32_t virq;
> >> +    int put_count = 0;
> >> +
> >> +    spin_lock(&global_virq_handlers_lock);
> >> +
> >> +    for (virq = 0; virq < NR_VIRQS; virq++) {
> >> +        if (global_virq_handlers[virq] == d) {
> >> +            global_virq_handlers[virq] = NULL;
> > 
> > I don't suppose we should rebind to dom0, should we? 
> 
> Storing NULL here effectively means re-binding to Dom0.

Oh, good, thanks. In that case:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.

> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:44:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:44:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnTw3-0002ud-Gq; Wed, 18 Jan 2012 11: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 1RnTw2-0002tz-KZ
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:44:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326887044!11411644!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27955 invoked from network); 18 Jan 2012 11:44:04 -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;
	18 Jan 2012 11:44:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112907"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:44: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, 18 Jan 2012 11:44:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 18 Jan 2012 11:44:03 +0000
In-Reply-To: <4F16BADD020000780006D6BA@nat28.tlf.novell.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-3-git-send-email-dgdegra@tycho.nsa.gov>
	<1326883141.14689.177.camel@zakaz.uk.xensource.com>
	<4F16BADD020000780006D6BA@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326887043.14689.213.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers to be
 delegated to other 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 Wed, 2012-01-18 at 11:28 +0000, Jan Beulich wrote:
> >>> On 18.01.12 at 11:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> >> 
> >> +static void clear_global_virq_handlers(struct domain *d)
> >> +{
> >> +    uint32_t virq;
> >> +    int put_count = 0;
> >> +
> >> +    spin_lock(&global_virq_handlers_lock);
> >> +
> >> +    for (virq = 0; virq < NR_VIRQS; virq++) {
> >> +        if (global_virq_handlers[virq] == d) {
> >> +            global_virq_handlers[virq] = NULL;
> > 
> > I don't suppose we should rebind to dom0, should we? 
> 
> Storing NULL here effectively means re-binding to Dom0.

Oh, good, thanks. In that case:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.

> 
> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:45:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11: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 1RnTwb-0002yM-Uj; Wed, 18 Jan 2012 11:44:45 +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 1RnTwa-0002xv-QZ
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:44:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326887078!11366291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21768 invoked from network); 18 Jan 2012 11:44:38 -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;
	18 Jan 2012 11:44:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112918"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:44:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:44:37 +0000
In-Reply-To: <1326411330-7915-17-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-17-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326887077.14689.214.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 16/18] xenstored: use domain_is_unprivileged
 instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> This centralizes all the permission checking for privileged domains in
> preparation for allowing domains other than dom0 to be privileged.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_core.c   |    6 +++---
>  tools/xenstore/xenstored_domain.c |    8 ++++----
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 4ec63f1..eea5fd6 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -488,7 +488,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
>  		mask &= ~XS_PERM_WRITE;
>  
>  	/* Owners and tools get it all... */
> -	if (!conn->id || perms[0].id == conn->id
> +	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id

domain_is_unprivileged is:
        conn && conn->domain && conn->domain->domid != 0
        
which isn't quite the same as the code being replaced. The difference
appears to be the conn->id is valid for socket connections as well as
domain connections whereas conn->domain is only present for domain
connections.

Does this change not mean that, for the dom0-process xenstored
configuration we now treat socket based connections as unprivileged
where previously they would be unprivileged?


>                  || (conn->target && perms[0].id == conn->target->id))
>  		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
>  
> @@ -826,11 +826,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
>  	node->tdb = tdb_context(conn);
>  	node->name = talloc_strdup(node, name);
>  
> -	/* Inherit permissions, except domains own what they create */
> +	/* Inherit permissions, except unprivileged domains own what they create */
>  	node->num_perms = parent->num_perms;
>  	node->perms = talloc_memdup(node, parent->perms,
>  				    node->num_perms * sizeof(node->perms[0]));
> -	if (conn && conn->id)
> +	if (domain_is_unprivileged(conn))
>  		node->perms[0].id = conn->id;
>  
>  	/* No children, no data */
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 648eb1d..5f4a09e 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -336,7 +336,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
>  		return;
>  	}
>  
> -	if (conn->id != 0 || !conn->can_write) {
> +	if (domain_is_unprivileged(conn) || !conn->can_write) {
>  		send_error(conn, EACCES);
>  		return;
>  	}
> @@ -413,7 +413,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
>  		return;
>  	}
>  
> -	if (conn->id != 0 || !conn->can_write) {
> +	if (domain_is_unprivileged(conn) || !conn->can_write) {
>  		send_error(conn, EACCES);
>  		return;
>  	}
> @@ -465,7 +465,7 @@ void do_release(struct connection *conn, const char *domid_str)
>  		return;
>  	}
>  
> -	if (conn->id != 0) {
> +	if (domain_is_unprivileged(conn)) {
>  		send_error(conn, EACCES);
>  		return;
>  	}
> @@ -502,7 +502,7 @@ void do_resume(struct connection *conn, const char *domid_str)
>  		return;
>  	}
>  
> -	if (conn->id != 0) {
> +	if (domain_is_unprivileged(conn)) {
>  		send_error(conn, EACCES);
>  		return;
>  	}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:45:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11: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 1RnTwb-0002yM-Uj; Wed, 18 Jan 2012 11:44:45 +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 1RnTwa-0002xv-QZ
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:44:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326887078!11366291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21768 invoked from network); 18 Jan 2012 11:44:38 -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;
	18 Jan 2012 11:44:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10112918"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:44:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:44:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:44:37 +0000
In-Reply-To: <1326411330-7915-17-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-17-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326887077.14689.214.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 16/18] xenstored: use domain_is_unprivileged
 instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> This centralizes all the permission checking for privileged domains in
> preparation for allowing domains other than dom0 to be privileged.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_core.c   |    6 +++---
>  tools/xenstore/xenstored_domain.c |    8 ++++----
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 4ec63f1..eea5fd6 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -488,7 +488,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
>  		mask &= ~XS_PERM_WRITE;
>  
>  	/* Owners and tools get it all... */
> -	if (!conn->id || perms[0].id == conn->id
> +	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id

domain_is_unprivileged is:
        conn && conn->domain && conn->domain->domid != 0
        
which isn't quite the same as the code being replaced. The difference
appears to be the conn->id is valid for socket connections as well as
domain connections whereas conn->domain is only present for domain
connections.

Does this change not mean that, for the dom0-process xenstored
configuration we now treat socket based connections as unprivileged
where previously they would be unprivileged?


>                  || (conn->target && perms[0].id == conn->target->id))
>  		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
>  
> @@ -826,11 +826,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
>  	node->tdb = tdb_context(conn);
>  	node->name = talloc_strdup(node, name);
>  
> -	/* Inherit permissions, except domains own what they create */
> +	/* Inherit permissions, except unprivileged domains own what they create */
>  	node->num_perms = parent->num_perms;
>  	node->perms = talloc_memdup(node, parent->perms,
>  				    node->num_perms * sizeof(node->perms[0]));
> -	if (conn && conn->id)
> +	if (domain_is_unprivileged(conn))
>  		node->perms[0].id = conn->id;
>  
>  	/* No children, no data */
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 648eb1d..5f4a09e 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -336,7 +336,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
>  		return;
>  	}
>  
> -	if (conn->id != 0 || !conn->can_write) {
> +	if (domain_is_unprivileged(conn) || !conn->can_write) {
>  		send_error(conn, EACCES);
>  		return;
>  	}
> @@ -413,7 +413,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
>  		return;
>  	}
>  
> -	if (conn->id != 0 || !conn->can_write) {
> +	if (domain_is_unprivileged(conn) || !conn->can_write) {
>  		send_error(conn, EACCES);
>  		return;
>  	}
> @@ -465,7 +465,7 @@ void do_release(struct connection *conn, const char *domid_str)
>  		return;
>  	}
>  
> -	if (conn->id != 0) {
> +	if (domain_is_unprivileged(conn)) {
>  		send_error(conn, EACCES);
>  		return;
>  	}
> @@ -502,7 +502,7 @@ void do_resume(struct connection *conn, const char *domid_str)
>  		return;
>  	}
>  
> -	if (conn->id != 0) {
> +	if (domain_is_unprivileged(conn)) {
>  		send_error(conn, EACCES);
>  		return;
>  	}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:49:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnU0f-0003Mm-KP; Wed, 18 Jan 2012 11:48:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnU0d-0003MX-OD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:48:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326887329!9642560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18985 invoked from network); 18 Jan 2012 11:48:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 11:48:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10113002"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:48: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;
	Wed, 18 Jan 2012 11:48:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:48:48 +0000
In-Reply-To: <1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326887328.14689.216.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 17/18] xenstored: add --priv-domid 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

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> This parameter identifies an alternative service domain which has
> superuser access to the xenstore database, which is currently required
> to set up a new domain's xenstore entries.

Is this equivalent to dom0 adding write permissions to various paths for
that domain as it builds it or is there more to it than that.

I know that the determination of "various paths" is non-trivial, so I'm
not actually suggesting that is a better approach.

> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_core.c   |    5 +++++
>  tools/xenstore/xenstored_core.h   |    1 +
>  tools/xenstore/xenstored_domain.c |    2 +-
>  3 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index eea5fd6..9d087de 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -1774,6 +1774,7 @@ static struct option options[] = {
>  	{ "event", 1, NULL, 'e' },
>  	{ "help", 0, NULL, 'H' },
>  	{ "no-fork", 0, NULL, 'N' },
> +	{ "priv-domid", 1, NULL, 'p' },
>  	{ "output-pid", 0, NULL, 'P' },
>  	{ "entry-size", 1, NULL, 'S' },
>  	{ "trace-file", 1, NULL, 'T' },
> @@ -1786,6 +1787,7 @@ static struct option options[] = {
>  
>  extern void dump_conn(struct connection *conn); 
>  int dom0_event = 0;
> +int priv_domid = 0;
>  
>  int main(int argc, char *argv[])
>  {
> @@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
>  		case 'e':
>  			dom0_event = strtol(optarg, NULL, 10);
>  			break;
> +		case 'p':
> +			priv_domid = strtol(optarg, NULL, 10);
> +			break;
>  		}
>  	}
>  	if (optind != argc)
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index d3040ba..03e2e48 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>  
>  extern int event_fd;
>  extern int dom0_event;
> +extern int priv_domid;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 5f4a09e..46bcf3e 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
>  
>  bool domain_is_unprivileged(struct connection *conn)
>  {
> -	return (conn && conn->domain && conn->domain->domid != 0);
> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
>  }
>  
>  bool domain_can_write(struct connection *conn)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:49:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:49:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnU0f-0003Mm-KP; Wed, 18 Jan 2012 11:48:57 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnU0d-0003MX-OD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:48:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326887329!9642560!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18985 invoked from network); 18 Jan 2012 11:48:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 11:48:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10113002"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:48: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;
	Wed, 18 Jan 2012 11:48:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:48:48 +0000
In-Reply-To: <1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326887328.14689.216.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 17/18] xenstored: add --priv-domid 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

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> This parameter identifies an alternative service domain which has
> superuser access to the xenstore database, which is currently required
> to set up a new domain's xenstore entries.

Is this equivalent to dom0 adding write permissions to various paths for
that domain as it builds it or is there more to it than that.

I know that the determination of "various paths" is non-trivial, so I'm
not actually suggesting that is a better approach.

> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_core.c   |    5 +++++
>  tools/xenstore/xenstored_core.h   |    1 +
>  tools/xenstore/xenstored_domain.c |    2 +-
>  3 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index eea5fd6..9d087de 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -1774,6 +1774,7 @@ static struct option options[] = {
>  	{ "event", 1, NULL, 'e' },
>  	{ "help", 0, NULL, 'H' },
>  	{ "no-fork", 0, NULL, 'N' },
> +	{ "priv-domid", 1, NULL, 'p' },
>  	{ "output-pid", 0, NULL, 'P' },
>  	{ "entry-size", 1, NULL, 'S' },
>  	{ "trace-file", 1, NULL, 'T' },
> @@ -1786,6 +1787,7 @@ static struct option options[] = {
>  
>  extern void dump_conn(struct connection *conn); 
>  int dom0_event = 0;
> +int priv_domid = 0;
>  
>  int main(int argc, char *argv[])
>  {
> @@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
>  		case 'e':
>  			dom0_event = strtol(optarg, NULL, 10);
>  			break;
> +		case 'p':
> +			priv_domid = strtol(optarg, NULL, 10);
> +			break;
>  		}
>  	}
>  	if (optind != argc)
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index d3040ba..03e2e48 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>  
>  extern int event_fd;
>  extern int dom0_event;
> +extern int priv_domid;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 5f4a09e..46bcf3e 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
>  
>  bool domain_is_unprivileged(struct connection *conn)
>  {
> -	return (conn && conn->domain && conn->domain->domid != 0);
> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
>  }
>  
>  bool domain_can_write(struct connection *conn)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:51:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnU2T-0003TG-5s; Wed, 18 Jan 2012 11:50: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 1RnU2R-0003T9-7u
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:50:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326887375!61483787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 772 invoked from network); 18 Jan 2012 11:49:35 -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;
	18 Jan 2012 11:49:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10113044"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:50:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:50:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:50:40 +0000
In-Reply-To: <1326411330-7915-19-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-19-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326887440.14689.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] [PATCH 18/18] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I think eventually we should aim to have this be a rough drop in
replacement for /usr/sbin/*xenstored (similar params where it makes
sense etc) but this will do for now:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/include/xen-sys/Linux/xenbus_dev.h |   55 +++++++++++++++++
>  tools/xenstore/Makefile                  |    9 ++-
>  tools/xenstore/init-xenstore-domain.c    |   96 ++++++++++++++++++++++++++++++
>  3 files changed, 158 insertions(+), 2 deletions(-)
>  create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
>  create mode 100644 tools/xenstore/init-xenstore-domain.c
> 
> diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
> new file mode 100644
> index 0000000..b107be9
> --- /dev/null
> +++ b/tools/include/xen-sys/Linux/xenbus_dev.h
> @@ -0,0 +1,55 @@
> +/******************************************************************************
> + * 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)
> +
> +#define IOCTL_XENBUS_ALLOC				\
> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
> +struct ioctl_xenbus_alloc {
> +	/* IN */
> +	/* The domain ID (must exist) for xenstore */
> +	uint16_t dom;
> +	uint16_t pad;
> +	/* OUT */
> +	/* The port allocated for xenbus communication */
> +	uint32_t port;
> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
> +	uint32_t grant_ref;
> +};
> +
> +#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 3a061d6..9b411a5 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
>  xenstore xenstore-control: CFLAGS += -static
>  endif
>  
> -ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
> +ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
>  
>  ifdef CONFIG_STUBDOM
>  CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
> @@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
>  CFLAGS += -DHAVE_DTRACE=1
>  endif
>  
> +init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
> +
> +init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
> +	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> +
>  xenstored: $(XENSTORED_OBJS)
>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
> @@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
>  clean:
>  	rm -f *.a *.o *.opic *.so* xenstored_probes.h
>  	rm -f xenstored xs_random xs_stress xs_crashme
> -	rm -f xs_tdb_dump xenstore-control
> +	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
>  	rm -f xenstore $(CLIENTS)
>  	$(RM) $(DEPS)
>  
> diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
> new file mode 100644
> index 0000000..30f6c9b
> --- /dev/null
> +++ b/tools/xenstore/init-xenstore-domain.c
> @@ -0,0 +1,96 @@
> +#include <fcntl.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <stdint.h>
> +#include <stdlib.h>
> +#include <sys/ioctl.h>
> +#include <sys/mman.h>
> +#include <xenctrl.h>
> +#include <xc_dom.h>
> +#include <xs.h>
> +#include <xen/sys/xenbus_dev.h>
> +
> +static uint32_t domid = -1;
> +
> +static int build(xc_interface *xch, char** argv)
> +{
> +	char cmdline[512];
> +	uint32_t ssid;
> +	xen_domain_handle_t handle = { 0 };
> +	int rv;
> +	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
> +	struct xc_dom_image *dom;
> +	int maxmem = atoi(argv[2]);
> +	int limit_kb = (maxmem + 1)*1024;
> +	struct ioctl_xenbus_alloc alloc;
> +
> +	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
> +	if (rv) return rv;
> +	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
> +	if (rv) return rv;
> +	rv = xc_domain_max_vcpus(xch, domid, 1);
> +	if (rv) return rv;
> +	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
> +	if (rv) return rv;
> +	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
> +	if (rv) return rv;
> +
> +	alloc.dom = domid;
> +	rv = ioctl(xs_fd, IOCTL_XENBUS_ALLOC, &alloc);
> +	if (rv) return rv;
> +	snprintf(cmdline, 512, "--event %d", alloc.port);
> +
> +	dom = xc_dom_allocate(xch, cmdline, NULL);
> +	rv = xc_dom_kernel_file(dom, argv[1]);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_xen_init(dom, xch, domid);
> +	if (rv) return rv;
> +	rv = xc_dom_parse_image(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_mem_init(dom, maxmem);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_mem_init(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_build_image(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_image(dom);
> +	if (rv) return rv;
> +
> +	xc_dom_release(dom);
> +
> +	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
> +	if (rv) return rv;
> +	rv = xc_domain_unpause(xch, domid);
> +	if (rv) return rv;
> +
> +	return 0;
> +}
> +
> +int main(int argc, char** argv)
> +{
> +	xc_interface *xch;
> +	struct xs_handle *xsh;
> +	char buf[16];
> +	int rv;
> +
> +	if (argc != 4) {
> +		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
> +		return 2;
> +	}
> +
> +	xch = xc_interface_open(NULL, NULL, 0);
> +	if (!xch) return 1;
> +
> +	rv = build(xch, argv);
> +
> +	xc_interface_close(xch);
> +
> +	if (rv) return 1;
> +
> +	xsh = xs_open(0);
> +	rv = snprintf(buf, 16, "%d", domid);
> +	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
> +	xs_daemon_close(xsh);
> +
> +	return 0;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 11:51:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 11:51:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnU2T-0003TG-5s; Wed, 18 Jan 2012 11:50: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 1RnU2R-0003T9-7u
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 11:50:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326887375!61483787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 772 invoked from network); 18 Jan 2012 11:49:35 -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;
	18 Jan 2012 11:49:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10113044"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 11:50:41 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 11:50:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 11:50:40 +0000
In-Reply-To: <1326411330-7915-19-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-19-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326887440.14689.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] [PATCH 18/18] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I think eventually we should aim to have this be a rough drop in
replacement for /usr/sbin/*xenstored (similar params where it makes
sense etc) but this will do for now:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/include/xen-sys/Linux/xenbus_dev.h |   55 +++++++++++++++++
>  tools/xenstore/Makefile                  |    9 ++-
>  tools/xenstore/init-xenstore-domain.c    |   96 ++++++++++++++++++++++++++++++
>  3 files changed, 158 insertions(+), 2 deletions(-)
>  create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
>  create mode 100644 tools/xenstore/init-xenstore-domain.c
> 
> diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
> new file mode 100644
> index 0000000..b107be9
> --- /dev/null
> +++ b/tools/include/xen-sys/Linux/xenbus_dev.h
> @@ -0,0 +1,55 @@
> +/******************************************************************************
> + * 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)
> +
> +#define IOCTL_XENBUS_ALLOC				\
> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
> +struct ioctl_xenbus_alloc {
> +	/* IN */
> +	/* The domain ID (must exist) for xenstore */
> +	uint16_t dom;
> +	uint16_t pad;
> +	/* OUT */
> +	/* The port allocated for xenbus communication */
> +	uint32_t port;
> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
> +	uint32_t grant_ref;
> +};
> +
> +#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 3a061d6..9b411a5 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
>  xenstore xenstore-control: CFLAGS += -static
>  endif
>  
> -ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
> +ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
>  
>  ifdef CONFIG_STUBDOM
>  CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
> @@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
>  CFLAGS += -DHAVE_DTRACE=1
>  endif
>  
> +init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
> +
> +init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
> +	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
> +
>  xenstored: $(XENSTORED_OBJS)
>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
> @@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
>  clean:
>  	rm -f *.a *.o *.opic *.so* xenstored_probes.h
>  	rm -f xenstored xs_random xs_stress xs_crashme
> -	rm -f xs_tdb_dump xenstore-control
> +	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
>  	rm -f xenstore $(CLIENTS)
>  	$(RM) $(DEPS)
>  
> diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
> new file mode 100644
> index 0000000..30f6c9b
> --- /dev/null
> +++ b/tools/xenstore/init-xenstore-domain.c
> @@ -0,0 +1,96 @@
> +#include <fcntl.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <stdint.h>
> +#include <stdlib.h>
> +#include <sys/ioctl.h>
> +#include <sys/mman.h>
> +#include <xenctrl.h>
> +#include <xc_dom.h>
> +#include <xs.h>
> +#include <xen/sys/xenbus_dev.h>
> +
> +static uint32_t domid = -1;
> +
> +static int build(xc_interface *xch, char** argv)
> +{
> +	char cmdline[512];
> +	uint32_t ssid;
> +	xen_domain_handle_t handle = { 0 };
> +	int rv;
> +	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
> +	struct xc_dom_image *dom;
> +	int maxmem = atoi(argv[2]);
> +	int limit_kb = (maxmem + 1)*1024;
> +	struct ioctl_xenbus_alloc alloc;
> +
> +	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
> +	if (rv) return rv;
> +	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
> +	if (rv) return rv;
> +	rv = xc_domain_max_vcpus(xch, domid, 1);
> +	if (rv) return rv;
> +	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
> +	if (rv) return rv;
> +	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
> +	if (rv) return rv;
> +
> +	alloc.dom = domid;
> +	rv = ioctl(xs_fd, IOCTL_XENBUS_ALLOC, &alloc);
> +	if (rv) return rv;
> +	snprintf(cmdline, 512, "--event %d", alloc.port);
> +
> +	dom = xc_dom_allocate(xch, cmdline, NULL);
> +	rv = xc_dom_kernel_file(dom, argv[1]);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_xen_init(dom, xch, domid);
> +	if (rv) return rv;
> +	rv = xc_dom_parse_image(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_mem_init(dom, maxmem);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_mem_init(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_build_image(dom);
> +	if (rv) return rv;
> +	rv = xc_dom_boot_image(dom);
> +	if (rv) return rv;
> +
> +	xc_dom_release(dom);
> +
> +	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
> +	if (rv) return rv;
> +	rv = xc_domain_unpause(xch, domid);
> +	if (rv) return rv;
> +
> +	return 0;
> +}
> +
> +int main(int argc, char** argv)
> +{
> +	xc_interface *xch;
> +	struct xs_handle *xsh;
> +	char buf[16];
> +	int rv;
> +
> +	if (argc != 4) {
> +		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
> +		return 2;
> +	}
> +
> +	xch = xc_interface_open(NULL, NULL, 0);
> +	if (!xch) return 1;
> +
> +	rv = build(xch, argv);
> +
> +	xc_interface_close(xch);
> +
> +	if (rv) return 1;
> +
> +	xsh = xs_open(0);
> +	rv = snprintf(buf, 16, "%d", domid);
> +	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
> +	xs_daemon_close(xsh);
> +
> +	return 0;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 12:08:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 12:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnUIl-0004KQ-6U; Wed, 18 Jan 2012 12:07:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnUIj-0004KI-SG
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 12:07:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326888450!11496016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28714 invoked from network); 18 Jan 2012 12:07:31 -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;
	18 Jan 2012 12:07:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10113388"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 12:07: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, 18 Jan 2012 12:07:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 12:07:08 +0000
In-Reply-To: <1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326888429.14689.221.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] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:36 +0000, Daniel De Graaf wrote:
> This adds an ioctl to the /dev/xen/xenbus_backend device allowing the
> xenbus backend to be started after the kernel has booted. This is
> intended to allow dom0 to start another domain to run xenstore.

Does this new ioctl need to be made oneshot? What happens if you call it
twice?

Also it should be disabled once a local xenstored has connected
shouldn't it?

Diego's original patch handled that sort of thing, any reason not to
simply forward port it?

> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_comms.c       |    6 ++++
>  drivers/xen/xenbus/xenbus_comms.h       |    1 +
>  drivers/xen/xenbus/xenbus_dev_backend.c |   44 +++++++++++++++++++++++++++++++
>  include/xen/grant_table.h               |    2 +
>  include/xen/xenbus_dev.h                |   14 ++++++++++
>  5 files changed, 67 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index 2eff7a6..52fe7ad 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -234,3 +234,9 @@ int xb_init_comms(void)
>  
>  	return 0;
>  }
> +
> +void xb_deinit_comms(void)
> +{
> +	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
> +	xenbus_irq = 0;
> +}
> diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
> index 6e42800..c8abd3b 100644
> --- a/drivers/xen/xenbus/xenbus_comms.h
> +++ b/drivers/xen/xenbus/xenbus_comms.h
> @@ -35,6 +35,7 @@
>  
>  int xs_init(void);
>  int xb_init_comms(void);
> +void xb_deinit_comms(void);
>  
>  /* Low level routines. */
>  int xb_write(const void *data, unsigned len);
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
> index 3d3be78..854315c 100644
> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -8,7 +8,11 @@
>  
>  #include <xen/xen.h>
>  #include <xen/page.h>
> +#include <xen/xenbus.h>
>  #include <xen/xenbus_dev.h>
> +#include <xen/grant_table.h>
> +#include <xen/events.h>
> +#include <asm/xen/hypervisor.h>
>  
>  #include "xenbus_comms.h"
>  
> @@ -22,6 +26,43 @@ static int xenbus_backend_open(struct inode *inode, struct file *filp)
>  	return nonseekable_open(inode, filp);
>  }
>  
> +static long xenbus_alloc(void __user * data)
> +{
> +	struct ioctl_xenbus_alloc op;
> +	struct evtchn_alloc_unbound arg;
> +	int err;
> +
> +	if (copy_from_user(&op, data, sizeof(op)))
> +		return -EFAULT;
> +
> +	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, op.dom,
> +			virt_to_mfn(xen_store_interface), 0 /* writable */);
> +
> +	arg.dom = DOMID_SELF;
> +	arg.remote_dom = op.dom;
> +
> +	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
> +	if (err)
> +		return err;
> +
> +	op.port = arg.port;
> +	op.grant_ref = GNTTAB_RESERVED_XENSTORE;
> +
> +	xs_suspend();
> +
> +	if (xen_store_evtchn > 0)
> +		xb_deinit_comms();
> +
> +	xen_store_evtchn = arg.port;
> +
> +	xs_resume();
> +
> +	if (copy_to_user(data, &op, sizeof(op)))
> +		return -EFAULT;
> +
> +	return 0;
> +}
> +
>  static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
>  {
>  	if (!capable(CAP_SYS_ADMIN))
> @@ -33,6 +74,9 @@ static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned l
>  				return xen_store_evtchn;
>  			return -ENODEV;
>  
> +		case IOCTL_XENBUS_ALLOC:
> +			return xenbus_alloc((void __user *)data);
> +
>  		default:
>  			return -ENOTTY;
>  	}
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 15f8a00..11e27c3 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -46,6 +46,8 @@
>  
>  #include <xen/features.h>
>  
> +#define GNTTAB_RESERVED_XENSTORE 1
> +
>  /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
>  #define NR_GRANT_FRAMES 4
>  
> diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
> index ac5f0fe..b107be9 100644
> --- a/include/xen/xenbus_dev.h
> +++ b/include/xen/xenbus_dev.h
> @@ -38,4 +38,18 @@
>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>  	_IOC(_IOC_NONE, 'B', 0, 0)
>  
> +#define IOCTL_XENBUS_ALLOC				\
> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
> +struct ioctl_xenbus_alloc {
> +	/* IN */
> +	/* The domain ID (must exist) for xenstore */
> +	uint16_t dom;
> +	uint16_t pad;
> +	/* OUT */
> +	/* The port allocated for xenbus communication */
> +	uint32_t port;
> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
> +	uint32_t grant_ref;
> +};
> +
>  #endif /* __LINUX_XEN_XENBUS_DEV_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 12:08:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 12:08:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnUIl-0004KQ-6U; Wed, 18 Jan 2012 12:07:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnUIj-0004KI-SG
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 12:07:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326888450!11496016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28714 invoked from network); 18 Jan 2012 12:07:31 -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;
	18 Jan 2012 12:07:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10113388"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 12:07: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, 18 Jan 2012 12:07:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 12:07:08 +0000
In-Reply-To: <1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326888429.14689.221.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] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-12 at 23:36 +0000, Daniel De Graaf wrote:
> This adds an ioctl to the /dev/xen/xenbus_backend device allowing the
> xenbus backend to be started after the kernel has booted. This is
> intended to allow dom0 to start another domain to run xenstore.

Does this new ioctl need to be made oneshot? What happens if you call it
twice?

Also it should be disabled once a local xenstored has connected
shouldn't it?

Diego's original patch handled that sort of thing, any reason not to
simply forward port it?

> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  drivers/xen/xenbus/xenbus_comms.c       |    6 ++++
>  drivers/xen/xenbus/xenbus_comms.h       |    1 +
>  drivers/xen/xenbus/xenbus_dev_backend.c |   44 +++++++++++++++++++++++++++++++
>  include/xen/grant_table.h               |    2 +
>  include/xen/xenbus_dev.h                |   14 ++++++++++
>  5 files changed, 67 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
> index 2eff7a6..52fe7ad 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -234,3 +234,9 @@ int xb_init_comms(void)
>  
>  	return 0;
>  }
> +
> +void xb_deinit_comms(void)
> +{
> +	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
> +	xenbus_irq = 0;
> +}
> diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
> index 6e42800..c8abd3b 100644
> --- a/drivers/xen/xenbus/xenbus_comms.h
> +++ b/drivers/xen/xenbus/xenbus_comms.h
> @@ -35,6 +35,7 @@
>  
>  int xs_init(void);
>  int xb_init_comms(void);
> +void xb_deinit_comms(void);
>  
>  /* Low level routines. */
>  int xb_write(const void *data, unsigned len);
> diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
> index 3d3be78..854315c 100644
> --- a/drivers/xen/xenbus/xenbus_dev_backend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_backend.c
> @@ -8,7 +8,11 @@
>  
>  #include <xen/xen.h>
>  #include <xen/page.h>
> +#include <xen/xenbus.h>
>  #include <xen/xenbus_dev.h>
> +#include <xen/grant_table.h>
> +#include <xen/events.h>
> +#include <asm/xen/hypervisor.h>
>  
>  #include "xenbus_comms.h"
>  
> @@ -22,6 +26,43 @@ static int xenbus_backend_open(struct inode *inode, struct file *filp)
>  	return nonseekable_open(inode, filp);
>  }
>  
> +static long xenbus_alloc(void __user * data)
> +{
> +	struct ioctl_xenbus_alloc op;
> +	struct evtchn_alloc_unbound arg;
> +	int err;
> +
> +	if (copy_from_user(&op, data, sizeof(op)))
> +		return -EFAULT;
> +
> +	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, op.dom,
> +			virt_to_mfn(xen_store_interface), 0 /* writable */);
> +
> +	arg.dom = DOMID_SELF;
> +	arg.remote_dom = op.dom;
> +
> +	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
> +	if (err)
> +		return err;
> +
> +	op.port = arg.port;
> +	op.grant_ref = GNTTAB_RESERVED_XENSTORE;
> +
> +	xs_suspend();
> +
> +	if (xen_store_evtchn > 0)
> +		xb_deinit_comms();
> +
> +	xen_store_evtchn = arg.port;
> +
> +	xs_resume();
> +
> +	if (copy_to_user(data, &op, sizeof(op)))
> +		return -EFAULT;
> +
> +	return 0;
> +}
> +
>  static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
>  {
>  	if (!capable(CAP_SYS_ADMIN))
> @@ -33,6 +74,9 @@ static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned l
>  				return xen_store_evtchn;
>  			return -ENODEV;
>  
> +		case IOCTL_XENBUS_ALLOC:
> +			return xenbus_alloc((void __user *)data);
> +
>  		default:
>  			return -ENOTTY;
>  	}
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 15f8a00..11e27c3 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -46,6 +46,8 @@
>  
>  #include <xen/features.h>
>  
> +#define GNTTAB_RESERVED_XENSTORE 1
> +
>  /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
>  #define NR_GRANT_FRAMES 4
>  
> diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
> index ac5f0fe..b107be9 100644
> --- a/include/xen/xenbus_dev.h
> +++ b/include/xen/xenbus_dev.h
> @@ -38,4 +38,18 @@
>  #define IOCTL_XENBUS_BACKEND_EVTCHN			\
>  	_IOC(_IOC_NONE, 'B', 0, 0)
>  
> +#define IOCTL_XENBUS_ALLOC				\
> +	_IOC(_IOC_NONE, 'B', 1, sizeof(struct ioctl_xenbus_alloc))
> +struct ioctl_xenbus_alloc {
> +	/* IN */
> +	/* The domain ID (must exist) for xenstore */
> +	uint16_t dom;
> +	uint16_t pad;
> +	/* OUT */
> +	/* The port allocated for xenbus communication */
> +	uint32_t port;
> +	/* Always set to GNTTAB_RESERVED_XENSTORE */
> +	uint32_t grant_ref;
> +};
> +
>  #endif /* __LINUX_XEN_XENBUS_DEV_H__ */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 12:11:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 12:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnULU-0004VC-Pq; Wed, 18 Jan 2012 12:10: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 1RnULS-0004Uv-UC
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 12:10:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326888610!11416499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12612 invoked from network); 18 Jan 2012 12:10:20 -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;
	18 Jan 2012 12:10:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10113466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 12:10: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, 18 Jan 2012 12:10:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Date: Wed, 18 Jan 2012 12:10:08 +0000
In-Reply-To: <CANqQZNFL9=8wFBc2Cutrd2nwpk0Wk1EupqGQE6RU9a8aWzf0PA@mail.gmail.com>
References: <CANqQZNHUMrf-sNpfH3zsnPwYr3uGpeFSjycUufYHxR3kZ006+A@mail.gmail.com>
	<1326875935.29475.23.camel@dagon.hellion.org.uk>
	<CANqQZNFL9=8wFBc2Cutrd2nwpk0Wk1EupqGQE6RU9a8aWzf0PA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326888608.14689.224.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [question] bug in cpu_schedule_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

(putting list back)

On Wed, 2012-01-18 at 09:17 +0000, Kai Huang wrote:
> On Wed, Jan 18, 2012 at 4:38 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-01-18 at 08:13 +0000, Kai Huang wrote:
> >> Hi,
> >>
> >> I see below code in cpu_schedule_up in xen-unstable hg repository
> >> (xen/common/schedule.c).
> >>
> >>     if ( idle_vcpu[cpu] == NULL )
> >>         alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
> >>     if ( idle_vcpu[cpu] == NULL )
> >>         return -ENOMEM;
> >>
> >> Seems it's a bug? Should be like this?
> >>
> >>     if ( idle_vcpu[cpu] == NULL )
> >>         idle_vcpu[cpu] = alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
> >>     if ( idle_vcpu[cpu] == NULL )
> >>         return -ENOMEM;
> >
> > alloc_vcpu will set idle_vcpu[0]->domain->vcpu[cpu] to the newly
> > allocated vcpu. idle_vcpu[0]->domain == idle_domain and
> > idle_vcpu[0]->domain->vcpu == idle_vcpu (both are by construction in
> > scheduler_init). Therefore idle_vcpu[cpu] is already being set inside
> > alloc_vcpu.
> 
> Yes you are right. I finally find out this pointer chain. My mistake. Thanks.
> 
> But this brings me questions about vcpu management, specifically:
> 
> 1) When will the vcpu be created exactly? Seems vcpus are created on demand?

Either the toolstack or the domain itself (up to a limit set by the
toolstack) will create them via hypercalls, see VCPUOP_* (initialise and
up in particular) and use grep/TAGS/etc to follow the code from
alloc_vcpus and you should be able to see this and answer your other
questions too.

> 2) The vcpu created at beginning belongs to idle_domain, right?

Yes. The hypervisor will also build domain 0 and create vcpus for it.
All the other domains are created by the toolstack.

> When will the vcpus be assigned to other domain?

When that domain is created and the VCPUs are created/initialised they
will be assigned to the domain.

> 3) I geuss the binding of vcpu to physical cpu will be dynamically
> changed when scheduling, which means changing the binding scheduler
> specific, is this correct?

I'm not sure but I think that the individual schedulers just nominate
which VCPU to run on each PCPU while the core scheduler takes care of
the associated book keeping with actually moving stuff around. I could
be mistaken here though.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 12:11:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 12:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnULU-0004VC-Pq; Wed, 18 Jan 2012 12:10: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 1RnULS-0004Uv-UC
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 12:10:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326888610!11416499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12612 invoked from network); 18 Jan 2012 12:10:20 -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;
	18 Jan 2012 12:10:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10113466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 12:10: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, 18 Jan 2012 12:10:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Kai Huang <mail.kai.huang@gmail.com>
Date: Wed, 18 Jan 2012 12:10:08 +0000
In-Reply-To: <CANqQZNFL9=8wFBc2Cutrd2nwpk0Wk1EupqGQE6RU9a8aWzf0PA@mail.gmail.com>
References: <CANqQZNHUMrf-sNpfH3zsnPwYr3uGpeFSjycUufYHxR3kZ006+A@mail.gmail.com>
	<1326875935.29475.23.camel@dagon.hellion.org.uk>
	<CANqQZNFL9=8wFBc2Cutrd2nwpk0Wk1EupqGQE6RU9a8aWzf0PA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326888608.14689.224.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [question] bug in cpu_schedule_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

(putting list back)

On Wed, 2012-01-18 at 09:17 +0000, Kai Huang wrote:
> On Wed, Jan 18, 2012 at 4:38 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2012-01-18 at 08:13 +0000, Kai Huang wrote:
> >> Hi,
> >>
> >> I see below code in cpu_schedule_up in xen-unstable hg repository
> >> (xen/common/schedule.c).
> >>
> >>     if ( idle_vcpu[cpu] == NULL )
> >>         alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
> >>     if ( idle_vcpu[cpu] == NULL )
> >>         return -ENOMEM;
> >>
> >> Seems it's a bug? Should be like this?
> >>
> >>     if ( idle_vcpu[cpu] == NULL )
> >>         idle_vcpu[cpu] = alloc_vcpu(idle_vcpu[0]->domain, cpu, cpu);
> >>     if ( idle_vcpu[cpu] == NULL )
> >>         return -ENOMEM;
> >
> > alloc_vcpu will set idle_vcpu[0]->domain->vcpu[cpu] to the newly
> > allocated vcpu. idle_vcpu[0]->domain == idle_domain and
> > idle_vcpu[0]->domain->vcpu == idle_vcpu (both are by construction in
> > scheduler_init). Therefore idle_vcpu[cpu] is already being set inside
> > alloc_vcpu.
> 
> Yes you are right. I finally find out this pointer chain. My mistake. Thanks.
> 
> But this brings me questions about vcpu management, specifically:
> 
> 1) When will the vcpu be created exactly? Seems vcpus are created on demand?

Either the toolstack or the domain itself (up to a limit set by the
toolstack) will create them via hypercalls, see VCPUOP_* (initialise and
up in particular) and use grep/TAGS/etc to follow the code from
alloc_vcpus and you should be able to see this and answer your other
questions too.

> 2) The vcpu created at beginning belongs to idle_domain, right?

Yes. The hypervisor will also build domain 0 and create vcpus for it.
All the other domains are created by the toolstack.

> When will the vcpus be assigned to other domain?

When that domain is created and the VCPUs are created/initialised they
will be assigned to the domain.

> 3) I geuss the binding of vcpu to physical cpu will be dynamically
> changed when scheduling, which means changing the binding scheduler
> specific, is this correct?

I'm not sure but I think that the individual schedulers just nominate
which VCPU to run on each PCPU while the core scheduler takes care of
the associated book keeping with actually moving stuff around. I could
be mistaken here though.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 13:36:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 13:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnVfn-0006Nc-0z; Wed, 18 Jan 2012 13:35:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RnVfl-0006NS-CA
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 13:35:29 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326893722!4087384!1
X-Originating-IP: [77.238.189.203]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6567 invoked from network); 18 Jan 2012 13:35:23 -0000
Received: from nm8-vm0.bullet.mail.ird.yahoo.com (HELO
	nm8-vm0.bullet.mail.ird.yahoo.com) (77.238.189.203)
	by server-16.tower-182.messagelabs.com with SMTP;
	18 Jan 2012 13:35:23 -0000
Received: from [77.238.189.233] by nm8.bullet.mail.ird.yahoo.com with NNFMP;
	18 Jan 2012 13:35:22 -0000
Received: from [212.82.108.118] by tm14.bullet.mail.ird.yahoo.com with NNFMP;
	18 Jan 2012 13:35:22 -0000
Received: from [127.0.0.1] by omp1027.mail.ird.yahoo.com with NNFMP;
	18 Jan 2012 13:35:22 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 739190.54755.bm@omp1027.mail.ird.yahoo.com
Received: (qmail 69629 invoked by uid 60001); 18 Jan 2012 13:35:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1326893722; bh=biuEHf42auSjDroqb3e7cfEzWDcFxDUjtfI8lZ94zgA=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type;
	b=ZOg4Se53zdeP9F/oJjWX7tSqejCJBufMXga4UwsBYRS2woQ7zzkzdDe9FxqxO/7pEqXW13r1jGIuDPvvgB1MfDqkv3bmvFCM5HI2MCxlBxU2wMM+lOsxuxVvJ8RIFSHb3mEEjcOjhUm6cFaULPyw5+M5Ko54KxEXM6ZES5ZGGwk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type;
	b=e+u+7pvutQE+eFLQAiQeUWbYfBp2DnMzxBom0sm7JPAKY1Hqiaanl3GtabZt25P6XUfyX+8ZGUgPzCzrINoIeR2XNbiUREzhIk4ERsgziwXbsckPRjVEMTr+2OUgZyfCJbhBFd5RI7OmU9I7dq7Hw8Ggot/e3wfh9K/LcneI/So=;
X-YMail-OSG: 0jCwXiUVM1l91Nlv41OT6iyjTkOljtHdzvJOdLpOPvmYb2B
	MP8kDn3OyEn81EIYTdTj4fliG0dK9UhqXhzU3vVKQzY6f77oIpbr5Xp7mSdX
	KI4PjNL50fUrSlWv_PH0zhCPLNJSNU0yoene8g2UNi07.GyUa7S8azCyl2FA
	lhRGPteZiTZfShWbagYJoVVyku0F3MJHa5VLy6qp8UqNxdAZFjWC.rwKCGdQ
	Fq54ydXD9933KXmjbfgYRE7wAn7vEI_5zSnysIchibRGs8CqoTwErFvYsQFC
	5AvHTwKd968aqV8vrXtNtP3wGkTktC0aYQY0It0tI5WxGDaWcKpnOFPjxfIR
	Qm7AEkoqd7hETtV9MARE0pyBKU0MjzwOswUFI16X9os5BXlKWFVxgJCJFgXA
	S.HfUehyw2nwaQt6vOyE-
Received: from [195.167.237.98] by web29803.mail.ird.yahoo.com via HTTP;
	Wed, 18 Jan 2012 13:35:22 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
Message-ID: <1326893722.59174.YahooMailNeo@web29803.mail.ird.yahoo.com>
Date: Wed, 18 Jan 2012 13:35:22 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Xen <xen-users@lists.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen 4.2 VGA PassThrough Nvidia crash for revision
	24492:6c104b46ef89 and higher
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="===============5113492748609624983=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5113492748609624983==
Content-Type: multipart/alternative; boundary="-829503087-839712994-1326893722=:59174"

---829503087-839712994-1326893722=:59174
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi =0A=0A=0ABe informed that I tried to maintain VGA PassThrough for Xen 4.=
2.=0A=0ASince a few day, I notice that VGA PassThrough for Nvidia crash for=
 domU and dom0 for revision >=3D 24492.=0A=0ATo be more precised, HVM domU =
with VGA PassThrough patches crash for revision submitted by Wei Wang=0A=0A=
"ATS device driver that support PASID [1] and PRI [2] capabilites needs=0At=
o work with iommu driver in guest OS. We have to expose iommu=0Afunctionali=
ty to HVM guest, if we want assign ATS device to it. A new=0Ahypervisor mmi=
o handler is added to intercept iommu mmio accesses from=0Aguest."=0A=0ARev=
ision higher than 24492 will not succeed to=0A=0A=0AI tried a lot of soluti=
on but all revisions >=3D 24492 fail.=0A=0AI am not a Xen Expert but let me=
 know if I can help.=0A=0ARegards.=0A=0ADavid.
---829503087-839712994-1326893722=:59174
Content-Type: text/html; charset=utf-8
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>Hi <br></div><di=
v><br></div><div>Be informed that I tried to maintain VGA PassThrough for X=
en 4.2.</div><div><br></div><div>Since a few day, I notice that VGA PassThr=
ough for Nvidia crash for domU and dom0 for revision &gt;=3D 24492.</div><d=
iv><br></div><div>To be more precised, HVM domU with VGA PassThrough patche=
s crash for revision submitted by Wei Wang</div><div><br></div><div>"ATS de=
vice driver that support PASID [1] and PRI [2] capabilites needs<br>=0Ato w=
ork with iommu driver in guest OS. We have to expose iommu<br>=0Afunctional=
ity to HVM guest, if we want assign ATS device to it. A new<br>=0Ahyperviso=
r mmio handler is added to intercept iommu mmio accesses from<br>=0Aguest."=
</div><div><br></div><div>Revision higher than 24492 will not succeed to<br=
></div><div><br></div><div>I tried a lot of solution but all revisions &gt;=
=3D 24492 fail.</div><div><br></div><div>I am not a Xen Expert but let me k=
now if I can help.</div><div><br></div><div>Regards.</div><div><br></div><d=
iv>David.<br></div><div><br></div><div><br></div><div><br></div><div><br></=
div></div></body></html>
---829503087-839712994-1326893722=:59174--


--===============5113492748609624983==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5113492748609624983==--


From xen-devel-bounces@lists.xensource.com Wed Jan 18 13:36:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 13:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnVfn-0006Nc-0z; Wed, 18 Jan 2012 13:35:31 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RnVfl-0006NS-CA
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 13:35:29 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326893722!4087384!1
X-Originating-IP: [77.238.189.203]
X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6567 invoked from network); 18 Jan 2012 13:35:23 -0000
Received: from nm8-vm0.bullet.mail.ird.yahoo.com (HELO
	nm8-vm0.bullet.mail.ird.yahoo.com) (77.238.189.203)
	by server-16.tower-182.messagelabs.com with SMTP;
	18 Jan 2012 13:35:23 -0000
Received: from [77.238.189.233] by nm8.bullet.mail.ird.yahoo.com with NNFMP;
	18 Jan 2012 13:35:22 -0000
Received: from [212.82.108.118] by tm14.bullet.mail.ird.yahoo.com with NNFMP;
	18 Jan 2012 13:35:22 -0000
Received: from [127.0.0.1] by omp1027.mail.ird.yahoo.com with NNFMP;
	18 Jan 2012 13:35:22 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 739190.54755.bm@omp1027.mail.ird.yahoo.com
Received: (qmail 69629 invoked by uid 60001); 18 Jan 2012 13:35:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1326893722; bh=biuEHf42auSjDroqb3e7cfEzWDcFxDUjtfI8lZ94zgA=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type;
	b=ZOg4Se53zdeP9F/oJjWX7tSqejCJBufMXga4UwsBYRS2woQ7zzkzdDe9FxqxO/7pEqXW13r1jGIuDPvvgB1MfDqkv3bmvFCM5HI2MCxlBxU2wMM+lOsxuxVvJ8RIFSHb3mEEjcOjhUm6cFaULPyw5+M5Ko54KxEXM6ZES5ZGGwk=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type;
	b=e+u+7pvutQE+eFLQAiQeUWbYfBp2DnMzxBom0sm7JPAKY1Hqiaanl3GtabZt25P6XUfyX+8ZGUgPzCzrINoIeR2XNbiUREzhIk4ERsgziwXbsckPRjVEMTr+2OUgZyfCJbhBFd5RI7OmU9I7dq7Hw8Ggot/e3wfh9K/LcneI/So=;
X-YMail-OSG: 0jCwXiUVM1l91Nlv41OT6iyjTkOljtHdzvJOdLpOPvmYb2B
	MP8kDn3OyEn81EIYTdTj4fliG0dK9UhqXhzU3vVKQzY6f77oIpbr5Xp7mSdX
	KI4PjNL50fUrSlWv_PH0zhCPLNJSNU0yoene8g2UNi07.GyUa7S8azCyl2FA
	lhRGPteZiTZfShWbagYJoVVyku0F3MJHa5VLy6qp8UqNxdAZFjWC.rwKCGdQ
	Fq54ydXD9933KXmjbfgYRE7wAn7vEI_5zSnysIchibRGs8CqoTwErFvYsQFC
	5AvHTwKd968aqV8vrXtNtP3wGkTktC0aYQY0It0tI5WxGDaWcKpnOFPjxfIR
	Qm7AEkoqd7hETtV9MARE0pyBKU0MjzwOswUFI16X9os5BXlKWFVxgJCJFgXA
	S.HfUehyw2nwaQt6vOyE-
Received: from [195.167.237.98] by web29803.mail.ird.yahoo.com via HTTP;
	Wed, 18 Jan 2012 13:35:22 GMT
X-Mailer: YahooMailWebService/0.8.115.331698
Message-ID: <1326893722.59174.YahooMailNeo@web29803.mail.ird.yahoo.com>
Date: Wed, 18 Jan 2012 13:35:22 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Xen <xen-users@lists.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen 4.2 VGA PassThrough Nvidia crash for revision
	24492:6c104b46ef89 and higher
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="===============5113492748609624983=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5113492748609624983==
Content-Type: multipart/alternative; boundary="-829503087-839712994-1326893722=:59174"

---829503087-839712994-1326893722=:59174
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi =0A=0A=0ABe informed that I tried to maintain VGA PassThrough for Xen 4.=
2.=0A=0ASince a few day, I notice that VGA PassThrough for Nvidia crash for=
 domU and dom0 for revision >=3D 24492.=0A=0ATo be more precised, HVM domU =
with VGA PassThrough patches crash for revision submitted by Wei Wang=0A=0A=
"ATS device driver that support PASID [1] and PRI [2] capabilites needs=0At=
o work with iommu driver in guest OS. We have to expose iommu=0Afunctionali=
ty to HVM guest, if we want assign ATS device to it. A new=0Ahypervisor mmi=
o handler is added to intercept iommu mmio accesses from=0Aguest."=0A=0ARev=
ision higher than 24492 will not succeed to=0A=0A=0AI tried a lot of soluti=
on but all revisions >=3D 24492 fail.=0A=0AI am not a Xen Expert but let me=
 know if I can help.=0A=0ARegards.=0A=0ADavid.
---829503087-839712994-1326893722=:59174
Content-Type: text/html; charset=utf-8
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>Hi <br></div><di=
v><br></div><div>Be informed that I tried to maintain VGA PassThrough for X=
en 4.2.</div><div><br></div><div>Since a few day, I notice that VGA PassThr=
ough for Nvidia crash for domU and dom0 for revision &gt;=3D 24492.</div><d=
iv><br></div><div>To be more precised, HVM domU with VGA PassThrough patche=
s crash for revision submitted by Wei Wang</div><div><br></div><div>"ATS de=
vice driver that support PASID [1] and PRI [2] capabilites needs<br>=0Ato w=
ork with iommu driver in guest OS. We have to expose iommu<br>=0Afunctional=
ity to HVM guest, if we want assign ATS device to it. A new<br>=0Ahyperviso=
r mmio handler is added to intercept iommu mmio accesses from<br>=0Aguest."=
</div><div><br></div><div>Revision higher than 24492 will not succeed to<br=
></div><div><br></div><div>I tried a lot of solution but all revisions &gt;=
=3D 24492 fail.</div><div><br></div><div>I am not a Xen Expert but let me k=
now if I can help.</div><div><br></div><div>Regards.</div><div><br></div><d=
iv>David.<br></div><div><br></div><div><br></div><div><br></div><div><br></=
div></div></body></html>
---829503087-839712994-1326893722=:59174--


--===============5113492748609624983==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5113492748609624983==--


From xen-devel-bounces@lists.xensource.com Wed Jan 18 13:52:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 13: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 1RnVvd-00073m-9i; Wed, 18 Jan 2012 13:51:53 +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 1RnVvb-00073Y-NR
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 13:51:52 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326894698!11543464!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 8949 invoked from network); 18 Jan 2012 13:51:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	18 Jan 2012 13:51:45 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74595055; Wed, 18 Jan 2012 14:51:35 +0100
Message-ID: <1326894667.5856.17.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Wei Wang <wei.wang2@amd.com>
Date: Wed, 18 Jan 2012 14:51:07 +0100
In-Reply-To: <4F16A186.4080303@amd.com>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
	<4F16A186.4080303@amd.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCHv3] 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="===============8938700861199708087=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8938700861199708087==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-NkwCTqGCk/O/BLPh1Wva"


--=-NkwCTqGCk/O/BLPh1Wva
Content-Type: multipart/mixed; boundary="=-umKgD1lrzkZzE1r/hOCO"


--=-umKgD1lrzkZzE1r/hOCO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Wei,

Here it is, and it seems to work for me, but of course I'm not testing
PPR. If you could give this a go and let me know... I'll repost in a
separate thread if it happens to be fine.

Thanks again,
Dario

--

Move IOMMU faults handling into softirq for AMD-Vi.
                 =20
Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-taskl=
et,
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 lo=
w
level IRQ handler and enabled back in the tasklet body. Notice that this ma=
y
cause the log to overflow, but none of the existing entry will be overwritt=
en.
                                =20
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 15ab61865ecb xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 17 12:40:52 2012 +00=
00
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Jan 18 13:01:23 2012 +01=
00
@@ -32,6 +32,8 @@
=20
 static int __initdata nr_amd_iommus;
=20
+static struct tasklet amd_iommu_irq_tasklet;
+
 unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
@@ -689,14 +691,48 @@ static void iommu_check_ppr_log(struct a
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
=20
+static void do_amd_iommu_irq(unsigned long data)
+{
+    struct amd_iommu *iommu;
+
+    if ( !iommu_found() )
+    {
+        AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n"=
);
+        return;
+    }
+
+    /*
+     * No matter from where the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMUs).
+     */
+    for_each_amd_iommu ( iommu ) {
+        iommu_check_event_log(iommu);
+
+        if ( iommu->ppr_log.buffer !=3D NULL )
+            iommu_check_ppr_log(iommu);
+    }
+}
+
 static void iommu_interrupt_handler(int irq, void *dev_id,
                                     struct cpu_user_regs *regs)
 {
+    u32 entry;
+    unsigned long flags;
     struct amd_iommu *iommu =3D dev_id;
-    iommu_check_event_log(iommu);
=20
-    if ( iommu->ppr_log.buffer !=3D NULL )
-        iommu_check_ppr_log(iommu);
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    /* Silence interrupts from both event and PPR logging */
+    entry =3D readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
+    iommu_clear_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
+    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    /* It is the tasklet that will clear the logs and re-enable interrupts=
 */
+    tasklet_schedule(&amd_iommu_irq_tasklet);
 }
=20
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
@@ -876,6 +912,8 @@ static int __init amd_iommu_init_one(str
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
=20
+    softirq_tasklet_init(&amd_iommu_irq_tasklet, do_amd_iommu_irq, 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)


--=-umKgD1lrzkZzE1r/hOCO
Content-Disposition: attachment; filename="iommu-fault-tasklet_amd.patch"
Content-Type: text/x-patch; name="iommu-fault-tasklet_amd.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE1YWI2MTg2NWVjYmQxNDZmNmNlNjVmYmVh
NWJmNDliZmQ5YzZjYjENCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgQU1ELVZpLg0KICAgICAgICAgICAgICAgICAgDQpEZWFsaW5nIHdpdGggaW50ZXJydXB0cyBm
cm9tIEFNRC1WaSBJT01NVShzKSBpcyBkZWZlcnJlZCB0byBhIHNvZnRpcnEtdGFza2xldCwNCnJh
aXNlZCBieSB0aGUgYWN0dWFsIElSUSBoYW5kbGVyLiBUbyBhdm9pZCBtb3JlIGludGVycnVwdHMg
YmVpbmcgZ2VuZXJhdGVkDQooYmVjYXVzZSBvZiBmdXJ0aGVyIGZhdWx0cyksIHRoZXkgbXVzdCBi
ZSBtYXNrZWQgaW4gdGhlIElPTU1VIHdpdGhpbiB0aGUgbG93DQpsZXZlbCBJUlEgaGFuZGxlciBh
bmQgZW5hYmxlZCBiYWNrIGluIHRoZSB0YXNrbGV0IGJvZHkuIE5vdGljZSB0aGF0IHRoaXMgbWF5
DQpjYXVzZSB0aGUgbG9nIHRvIG92ZXJmbG93LCBidXQgbm9uZSBvZiB0aGUgZXhpc3RpbmcgZW50
cnkgd2lsbCBiZSBvdmVyd3JpdHRlbi4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xpQGNpdHJpeC5j
b20+DQoNCmRpZmYgLXIgMTVhYjYxODY1ZWNiIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9p
b21tdV9pbml0LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbml0
LmMJVHVlIEphbiAxNyAxMjo0MDo1MiAyMDEyICswMDAwDQorKysgYi94ZW4vZHJpdmVycy9wYXNz
dGhyb3VnaC9hbWQvaW9tbXVfaW5pdC5jCVdlZCBKYW4gMTggMTM6MDE6MjMgMjAxMiArMDEwMA0K
QEAgLTMyLDYgKzMyLDggQEANCiANCiBzdGF0aWMgaW50IF9faW5pdGRhdGEgbnJfYW1kX2lvbW11
czsNCiANCitzdGF0aWMgc3RydWN0IHRhc2tsZXQgYW1kX2lvbW11X2lycV90YXNrbGV0Ow0KKw0K
IHVuc2lnbmVkIHNob3J0IGl2cnNfYmRmX2VudHJpZXM7DQogc3RhdGljIHN0cnVjdCByYWRpeF90
cmVlX3Jvb3QgaXZyc19tYXBzOw0KIHN0cnVjdCBsaXN0X2hlYWQgYW1kX2lvbW11X2hlYWQ7DQpA
QCAtNjg5LDE0ICs2OTEsNDggQEAgc3RhdGljIHZvaWQgaW9tbXVfY2hlY2tfcHByX2xvZyhzdHJ1
Y3QgYQ0KICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpb21tdS0+bG9jaywgZmxhZ3MpOw0K
IH0NCiANCitzdGF0aWMgdm9pZCBkb19hbWRfaW9tbXVfaXJxKHVuc2lnbmVkIGxvbmcgZGF0YSkN
Cit7DQorICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11Ow0KKw0KKyAgICBpZiAoICFpb21tdV9m
b3VuZCgpICkNCisgICAgew0KKyAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJubyBkZXZpY2UgZm91
bmQsIHNvbWV0aGluZyBtdXN0IGJlIHZlcnkgd3JvbmchXG4iKTsNCisgICAgICAgIHJldHVybjsN
CisgICAgfQ0KKw0KKyAgICAvKg0KKyAgICAgKiBObyBtYXR0ZXIgZnJvbSB3aGVyZSB0aGUgaW50
ZXJydXB0IGNhbWUgZnJvbSwgY2hlY2sgYWxsIHRoZQ0KKyAgICAgKiBJT01NVXMgcHJlc2VudCBp
biB0aGUgc3lzdGVtLiBUaGlzIGFsbG93cyBmb3IgaGF2aW5nIGp1c3Qgb25lDQorICAgICAqIHRh
c2tsZXQgKGluc3RlYWQgb2Ygb25lIHBlciBlYWNoIElPTU1VcykuDQorICAgICAqLw0KKyAgICBm
b3JfZWFjaF9hbWRfaW9tbXUgKCBpb21tdSApIHsNCisgICAgICAgIGlvbW11X2NoZWNrX2V2ZW50
X2xvZyhpb21tdSk7DQorDQorICAgICAgICBpZiAoIGlvbW11LT5wcHJfbG9nLmJ1ZmZlciAhPSBO
VUxMICkNCisgICAgICAgICAgICBpb21tdV9jaGVja19wcHJfbG9nKGlvbW11KTsNCisgICAgfQ0K
K30NCisNCiBzdGF0aWMgdm9pZCBpb21tdV9pbnRlcnJ1cHRfaGFuZGxlcihpbnQgaXJxLCB2b2lk
ICpkZXZfaWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGNw
dV91c2VyX3JlZ3MgKnJlZ3MpDQogew0KKyAgICB1MzIgZW50cnk7DQorICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7DQogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11ID0gZGV2X2lkOw0KLSAgICBp
b21tdV9jaGVja19ldmVudF9sb2coaW9tbXUpOw0KIA0KLSAgICBpZiAoIGlvbW11LT5wcHJfbG9n
LmJ1ZmZlciAhPSBOVUxMICkNCi0gICAgICAgIGlvbW11X2NoZWNrX3Bwcl9sb2coaW9tbXUpOw0K
KyAgICBzcGluX2xvY2tfaXJxc2F2ZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCisNCisgICAgLyog
U2lsZW5jZSBpbnRlcnJ1cHRzIGZyb20gYm90aCBldmVudCBhbmQgUFBSIGxvZ2dpbmcgKi8NCisg
ICAgZW50cnkgPSByZWFkbChpb21tdS0+bW1pb19iYXNlICsgSU9NTVVfU1RBVFVTX01NSU9fT0ZG
U0VUKTsNCisgICAgaW9tbXVfY2xlYXJfYml0KCZlbnRyeSwgSU9NTVVfU1RBVFVTX0VWRU5UX0xP
R19JTlRfU0hJRlQpOw0KKyAgICBpb21tdV9jbGVhcl9iaXQoJmVudHJ5LCBJT01NVV9TVEFUVVNf
UFBSX0xPR19JTlRfU0hJRlQpOw0KKyAgICB3cml0ZWwoZW50cnksIGlvbW11LT5tbWlvX2Jhc2Ur
SU9NTVVfU1RBVFVTX01NSU9fT0ZGU0VUKTsNCisNCisgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9y
ZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCisNCisgICAgLyogSXQgaXMgdGhlIHRhc2tsZXQgdGhh
dCB3aWxsIGNsZWFyIHRoZSBsb2dzIGFuZCByZS1lbmFibGUgaW50ZXJydXB0cyAqLw0KKyAgICB0
YXNrbGV0X3NjaGVkdWxlKCZhbWRfaW9tbXVfaXJxX3Rhc2tsZXQpOw0KIH0NCiANCiBzdGF0aWMg
aW50IF9faW5pdCBzZXRfaW9tbXVfaW50ZXJydXB0X2hhbmRsZXIoc3RydWN0IGFtZF9pb21tdSAq
aW9tbXUpDQpAQCAtODc2LDYgKzkxMiw4IEBAIHN0YXRpYyBpbnQgX19pbml0IGFtZF9pb21tdV9p
bml0X29uZShzdHINCiAgICAgcHJpbnRrKCJBTUQtVmk6IElPTU1VICVkIEVuYWJsZWQuXG4iLCBu
cl9hbWRfaW9tbXVzICk7DQogICAgIG5yX2FtZF9pb21tdXMrKzsNCiANCisgICAgc29mdGlycV90
YXNrbGV0X2luaXQoJmFtZF9pb21tdV9pcnFfdGFza2xldCwgZG9fYW1kX2lvbW11X2lycSwgMCk7
DQorDQogICAgIHJldHVybiAwOw0KIA0KIGVycm9yX291dDoNCg==


--=-umKgD1lrzkZzE1r/hOCO--

--=-NkwCTqGCk/O/BLPh1Wva
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)

iEYEABECAAYFAk8WzksACgkQk4XaBE3IOsRsggCgkKmnzMLRY4UTou8WXoQnB+2o
mQ4AmQFhFStPtsQJX+/r9zHMySW7VKey
=HUCe
-----END PGP SIGNATURE-----

--=-NkwCTqGCk/O/BLPh1Wva--



--===============8938700861199708087==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8938700861199708087==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 13:52:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 13: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 1RnVvd-00073m-9i; Wed, 18 Jan 2012 13:51:53 +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 1RnVvb-00073Y-NR
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 13:51:52 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326894698!11543464!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 8949 invoked from network); 18 Jan 2012 13:51:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	18 Jan 2012 13:51:45 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74595055; Wed, 18 Jan 2012 14:51:35 +0100
Message-ID: <1326894667.5856.17.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Wei Wang <wei.wang2@amd.com>
Date: Wed, 18 Jan 2012 14:51:07 +0100
In-Reply-To: <4F16A186.4080303@amd.com>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
	<4F16A186.4080303@amd.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCHv3] 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="===============8938700861199708087=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8938700861199708087==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-NkwCTqGCk/O/BLPh1Wva"


--=-NkwCTqGCk/O/BLPh1Wva
Content-Type: multipart/mixed; boundary="=-umKgD1lrzkZzE1r/hOCO"


--=-umKgD1lrzkZzE1r/hOCO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Wei,

Here it is, and it seems to work for me, but of course I'm not testing
PPR. If you could give this a go and let me know... I'll repost in a
separate thread if it happens to be fine.

Thanks again,
Dario

--

Move IOMMU faults handling into softirq for AMD-Vi.
                 =20
Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-taskl=
et,
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 lo=
w
level IRQ handler and enabled back in the tasklet body. Notice that this ma=
y
cause the log to overflow, but none of the existing entry will be overwritt=
en.
                                =20
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 15ab61865ecb xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 17 12:40:52 2012 +00=
00
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Jan 18 13:01:23 2012 +01=
00
@@ -32,6 +32,8 @@
=20
 static int __initdata nr_amd_iommus;
=20
+static struct tasklet amd_iommu_irq_tasklet;
+
 unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
@@ -689,14 +691,48 @@ static void iommu_check_ppr_log(struct a
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
=20
+static void do_amd_iommu_irq(unsigned long data)
+{
+    struct amd_iommu *iommu;
+
+    if ( !iommu_found() )
+    {
+        AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n"=
);
+        return;
+    }
+
+    /*
+     * No matter from where the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMUs).
+     */
+    for_each_amd_iommu ( iommu ) {
+        iommu_check_event_log(iommu);
+
+        if ( iommu->ppr_log.buffer !=3D NULL )
+            iommu_check_ppr_log(iommu);
+    }
+}
+
 static void iommu_interrupt_handler(int irq, void *dev_id,
                                     struct cpu_user_regs *regs)
 {
+    u32 entry;
+    unsigned long flags;
     struct amd_iommu *iommu =3D dev_id;
-    iommu_check_event_log(iommu);
=20
-    if ( iommu->ppr_log.buffer !=3D NULL )
-        iommu_check_ppr_log(iommu);
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    /* Silence interrupts from both event and PPR logging */
+    entry =3D readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
+    iommu_clear_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
+    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    /* It is the tasklet that will clear the logs and re-enable interrupts=
 */
+    tasklet_schedule(&amd_iommu_irq_tasklet);
 }
=20
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
@@ -876,6 +912,8 @@ static int __init amd_iommu_init_one(str
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
=20
+    softirq_tasklet_init(&amd_iommu_irq_tasklet, do_amd_iommu_irq, 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)


--=-umKgD1lrzkZzE1r/hOCO
Content-Disposition: attachment; filename="iommu-fault-tasklet_amd.patch"
Content-Type: text/x-patch; name="iommu-fault-tasklet_amd.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE1YWI2MTg2NWVjYmQxNDZmNmNlNjVmYmVh
NWJmNDliZmQ5YzZjYjENCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgQU1ELVZpLg0KICAgICAgICAgICAgICAgICAgDQpEZWFsaW5nIHdpdGggaW50ZXJydXB0cyBm
cm9tIEFNRC1WaSBJT01NVShzKSBpcyBkZWZlcnJlZCB0byBhIHNvZnRpcnEtdGFza2xldCwNCnJh
aXNlZCBieSB0aGUgYWN0dWFsIElSUSBoYW5kbGVyLiBUbyBhdm9pZCBtb3JlIGludGVycnVwdHMg
YmVpbmcgZ2VuZXJhdGVkDQooYmVjYXVzZSBvZiBmdXJ0aGVyIGZhdWx0cyksIHRoZXkgbXVzdCBi
ZSBtYXNrZWQgaW4gdGhlIElPTU1VIHdpdGhpbiB0aGUgbG93DQpsZXZlbCBJUlEgaGFuZGxlciBh
bmQgZW5hYmxlZCBiYWNrIGluIHRoZSB0YXNrbGV0IGJvZHkuIE5vdGljZSB0aGF0IHRoaXMgbWF5
DQpjYXVzZSB0aGUgbG9nIHRvIG92ZXJmbG93LCBidXQgbm9uZSBvZiB0aGUgZXhpc3RpbmcgZW50
cnkgd2lsbCBiZSBvdmVyd3JpdHRlbi4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xpQGNpdHJpeC5j
b20+DQoNCmRpZmYgLXIgMTVhYjYxODY1ZWNiIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9p
b21tdV9pbml0LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbml0
LmMJVHVlIEphbiAxNyAxMjo0MDo1MiAyMDEyICswMDAwDQorKysgYi94ZW4vZHJpdmVycy9wYXNz
dGhyb3VnaC9hbWQvaW9tbXVfaW5pdC5jCVdlZCBKYW4gMTggMTM6MDE6MjMgMjAxMiArMDEwMA0K
QEAgLTMyLDYgKzMyLDggQEANCiANCiBzdGF0aWMgaW50IF9faW5pdGRhdGEgbnJfYW1kX2lvbW11
czsNCiANCitzdGF0aWMgc3RydWN0IHRhc2tsZXQgYW1kX2lvbW11X2lycV90YXNrbGV0Ow0KKw0K
IHVuc2lnbmVkIHNob3J0IGl2cnNfYmRmX2VudHJpZXM7DQogc3RhdGljIHN0cnVjdCByYWRpeF90
cmVlX3Jvb3QgaXZyc19tYXBzOw0KIHN0cnVjdCBsaXN0X2hlYWQgYW1kX2lvbW11X2hlYWQ7DQpA
QCAtNjg5LDE0ICs2OTEsNDggQEAgc3RhdGljIHZvaWQgaW9tbXVfY2hlY2tfcHByX2xvZyhzdHJ1
Y3QgYQ0KICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpb21tdS0+bG9jaywgZmxhZ3MpOw0K
IH0NCiANCitzdGF0aWMgdm9pZCBkb19hbWRfaW9tbXVfaXJxKHVuc2lnbmVkIGxvbmcgZGF0YSkN
Cit7DQorICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11Ow0KKw0KKyAgICBpZiAoICFpb21tdV9m
b3VuZCgpICkNCisgICAgew0KKyAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJubyBkZXZpY2UgZm91
bmQsIHNvbWV0aGluZyBtdXN0IGJlIHZlcnkgd3JvbmchXG4iKTsNCisgICAgICAgIHJldHVybjsN
CisgICAgfQ0KKw0KKyAgICAvKg0KKyAgICAgKiBObyBtYXR0ZXIgZnJvbSB3aGVyZSB0aGUgaW50
ZXJydXB0IGNhbWUgZnJvbSwgY2hlY2sgYWxsIHRoZQ0KKyAgICAgKiBJT01NVXMgcHJlc2VudCBp
biB0aGUgc3lzdGVtLiBUaGlzIGFsbG93cyBmb3IgaGF2aW5nIGp1c3Qgb25lDQorICAgICAqIHRh
c2tsZXQgKGluc3RlYWQgb2Ygb25lIHBlciBlYWNoIElPTU1VcykuDQorICAgICAqLw0KKyAgICBm
b3JfZWFjaF9hbWRfaW9tbXUgKCBpb21tdSApIHsNCisgICAgICAgIGlvbW11X2NoZWNrX2V2ZW50
X2xvZyhpb21tdSk7DQorDQorICAgICAgICBpZiAoIGlvbW11LT5wcHJfbG9nLmJ1ZmZlciAhPSBO
VUxMICkNCisgICAgICAgICAgICBpb21tdV9jaGVja19wcHJfbG9nKGlvbW11KTsNCisgICAgfQ0K
K30NCisNCiBzdGF0aWMgdm9pZCBpb21tdV9pbnRlcnJ1cHRfaGFuZGxlcihpbnQgaXJxLCB2b2lk
ICpkZXZfaWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGNw
dV91c2VyX3JlZ3MgKnJlZ3MpDQogew0KKyAgICB1MzIgZW50cnk7DQorICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7DQogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11ID0gZGV2X2lkOw0KLSAgICBp
b21tdV9jaGVja19ldmVudF9sb2coaW9tbXUpOw0KIA0KLSAgICBpZiAoIGlvbW11LT5wcHJfbG9n
LmJ1ZmZlciAhPSBOVUxMICkNCi0gICAgICAgIGlvbW11X2NoZWNrX3Bwcl9sb2coaW9tbXUpOw0K
KyAgICBzcGluX2xvY2tfaXJxc2F2ZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCisNCisgICAgLyog
U2lsZW5jZSBpbnRlcnJ1cHRzIGZyb20gYm90aCBldmVudCBhbmQgUFBSIGxvZ2dpbmcgKi8NCisg
ICAgZW50cnkgPSByZWFkbChpb21tdS0+bW1pb19iYXNlICsgSU9NTVVfU1RBVFVTX01NSU9fT0ZG
U0VUKTsNCisgICAgaW9tbXVfY2xlYXJfYml0KCZlbnRyeSwgSU9NTVVfU1RBVFVTX0VWRU5UX0xP
R19JTlRfU0hJRlQpOw0KKyAgICBpb21tdV9jbGVhcl9iaXQoJmVudHJ5LCBJT01NVV9TVEFUVVNf
UFBSX0xPR19JTlRfU0hJRlQpOw0KKyAgICB3cml0ZWwoZW50cnksIGlvbW11LT5tbWlvX2Jhc2Ur
SU9NTVVfU1RBVFVTX01NSU9fT0ZGU0VUKTsNCisNCisgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9y
ZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCisNCisgICAgLyogSXQgaXMgdGhlIHRhc2tsZXQgdGhh
dCB3aWxsIGNsZWFyIHRoZSBsb2dzIGFuZCByZS1lbmFibGUgaW50ZXJydXB0cyAqLw0KKyAgICB0
YXNrbGV0X3NjaGVkdWxlKCZhbWRfaW9tbXVfaXJxX3Rhc2tsZXQpOw0KIH0NCiANCiBzdGF0aWMg
aW50IF9faW5pdCBzZXRfaW9tbXVfaW50ZXJydXB0X2hhbmRsZXIoc3RydWN0IGFtZF9pb21tdSAq
aW9tbXUpDQpAQCAtODc2LDYgKzkxMiw4IEBAIHN0YXRpYyBpbnQgX19pbml0IGFtZF9pb21tdV9p
bml0X29uZShzdHINCiAgICAgcHJpbnRrKCJBTUQtVmk6IElPTU1VICVkIEVuYWJsZWQuXG4iLCBu
cl9hbWRfaW9tbXVzICk7DQogICAgIG5yX2FtZF9pb21tdXMrKzsNCiANCisgICAgc29mdGlycV90
YXNrbGV0X2luaXQoJmFtZF9pb21tdV9pcnFfdGFza2xldCwgZG9fYW1kX2lvbW11X2lycSwgMCk7
DQorDQogICAgIHJldHVybiAwOw0KIA0KIGVycm9yX291dDoNCg==


--=-umKgD1lrzkZzE1r/hOCO--

--=-NkwCTqGCk/O/BLPh1Wva
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)

iEYEABECAAYFAk8WzksACgkQk4XaBE3IOsRsggCgkKmnzMLRY4UTou8WXoQnB+2o
mQ4AmQFhFStPtsQJX+/r9zHMySW7VKey
=HUCe
-----END PGP SIGNATURE-----

--=-NkwCTqGCk/O/BLPh1Wva--



--===============8938700861199708087==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8938700861199708087==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:04:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnW7H-0007eb-Kj; Wed, 18 Jan 2012 14:03:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnW7G-0007eW-0O
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:03:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326895427!11515825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28682 invoked from network); 18 Jan 2012 14:03:48 -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;
	18 Jan 2012 14:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10115919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:03:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 14:03:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 14:03:47 +0000
In-Reply-To: <1326482728-10733-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326895427.14689.227.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/9] ocaml, libxl: support "private" fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> The changeset
>   24378:b4365e2c2595  libxl: idl: support new "private" type attribute
> is not complete.  Actually using this feature does not work because
> the ocaml idl generator does not know about it.
> 
> So add that support.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/ocaml/libs/xl/genwrap.py |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
> index 5f8639a..61abecf 100644
> --- a/tools/ocaml/libs/xl/genwrap.py
> +++ b/tools/ocaml/libs/xl/genwrap.py
> @@ -91,6 +91,8 @@ def gen_ocaml_ml(ty, interface, indent=""):
>              s += "\t{\n"
>              
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              x = ocaml_instance_of(f.type, f.name)
>              x = x.replace("\n", "\n\t\t")
>              s += "\t\t" + x + ";\n"
> @@ -146,6 +148,8 @@ def c_val(ty, c, o, indent="", parent = None):
>      elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
>          n = 0
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
>              n = n + 1
>      else:
> @@ -210,6 +214,8 @@ def ocaml_Val(ty, o, c, indent="", parent = None):
>          
>          n = 0
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              s += "\n"
>              s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
>              s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
> @@ -288,6 +294,8 @@ if __name__ == '__main__':
>      cinc.write(autogen_header("/*", "*/"))
>  
>      for ty in types:
> +        if ty.private:
> +            continue
>          #sys.stdout.write(" TYPE    %-20s " % ty.rawname)
>          ml.write(gen_ocaml_ml(ty, False))
>          ml.write("\n")



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:04:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:04:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnW7H-0007eb-Kj; Wed, 18 Jan 2012 14:03:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnW7G-0007eW-0O
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:03:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326895427!11515825!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28682 invoked from network); 18 Jan 2012 14:03:48 -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;
	18 Jan 2012 14:03:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10115919"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:03:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 14:03:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 14:03:47 +0000
In-Reply-To: <1326482728-10733-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326895427.14689.227.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/9] ocaml, libxl: support "private" fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> The changeset
>   24378:b4365e2c2595  libxl: idl: support new "private" type attribute
> is not complete.  Actually using this feature does not work because
> the ocaml idl generator does not know about it.
> 
> So add that support.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/ocaml/libs/xl/genwrap.py |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
> index 5f8639a..61abecf 100644
> --- a/tools/ocaml/libs/xl/genwrap.py
> +++ b/tools/ocaml/libs/xl/genwrap.py
> @@ -91,6 +91,8 @@ def gen_ocaml_ml(ty, interface, indent=""):
>              s += "\t{\n"
>              
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              x = ocaml_instance_of(f.type, f.name)
>              x = x.replace("\n", "\n\t\t")
>              s += "\t\t" + x + ";\n"
> @@ -146,6 +148,8 @@ def c_val(ty, c, o, indent="", parent = None):
>      elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
>          n = 0
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
>              n = n + 1
>      else:
> @@ -210,6 +214,8 @@ def ocaml_Val(ty, o, c, indent="", parent = None):
>          
>          n = 0
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              s += "\n"
>              s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
>              s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
> @@ -288,6 +294,8 @@ if __name__ == '__main__':
>      cinc.write(autogen_header("/*", "*/"))
>  
>      for ty in types:
> +        if ty.private:
> +            continue
>          #sys.stdout.write(" TYPE    %-20s " % ty.rawname)
>          ml.write(gen_ocaml_ml(ty, False))
>          ml.write("\n")



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:05:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnW88-0007hN-7s; Wed, 18 Jan 2012 14:04: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 1RnW86-0007gd-G4
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:04:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326895480!9675072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6820 invoked from network); 18 Jan 2012 14:04:40 -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;
	18 Jan 2012 14:04:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10115942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:04:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 14:04:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 14:04:39 +0000
In-Reply-To: <1326482728-10733-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326895480.14689.228.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 7/9] libxl: New convenience macro
 CONTAINER_OF
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Provide a convenient and type-safe wrapper which does the correct
> dance to subtract offsetof.  This is very similar to the
> "container_of" macro in the Linux kernel, but it has an additional
> feature that instead of the type argument you may also pass an
> expression of that type; this makes initialising a variable with
> CONTAINER_OF easier.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 594b9fb..213b5f9 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1238,6 +1238,35 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
>   * Convenience macros.
>   */
>  
> +/*
> + * CONTAINER_OF work like this.  Given:
> + *    typedef struct {
> + *      ...
> + *      member_type member_name;
> + *      ...
> + *    } outer_type;
> + *    outer_type outer, *outer_var;
> + *    member_type *inner_ptr = &outer->member_name;
> + *
> + * Then, effectively:
> + *    outer_type *CONTAINER_OF(member_type *inner_ptr,
> + *                             *outer_var, // or type name for outer_type
> + *                             member_name);
> + *
> + * So that:
> + *    CONTAINER_OF(inner_ptr, *outer_var, member_name) == &outer
> + *    CONTAINER_OF(inner_ptr, outer_type, member_name) == &outer
> + */
> +#define CONTAINER_OF(inner_ptr, outer, member_name)                     \
> +    ({                                                                  \
> +        typeof(outer) *container_of_;                                   \
> +        container_of_ = (void*)((char*)(inner_ptr) -                    \
> +                                offsetof(typeof(outer), member_name));  \
> +        (void)(&container_of_->member_name ==                           \
> +               (typeof(inner_ptr))0) /* type check */;                  \
> +        container_of_;                                                  \
> +    })
> +
>  
>  /*
>   * All of these assume (or define)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:05:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:05:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnW88-0007hN-7s; Wed, 18 Jan 2012 14:04: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 1RnW86-0007gd-G4
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:04:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326895480!9675072!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6820 invoked from network); 18 Jan 2012 14:04:40 -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;
	18 Jan 2012 14:04:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10115942"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:04:40 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 14:04:40 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 14:04:39 +0000
In-Reply-To: <1326482728-10733-8-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-8-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326895480.14689.228.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 7/9] libxl: New convenience macro
 CONTAINER_OF
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Provide a convenient and type-safe wrapper which does the correct
> dance to subtract offsetof.  This is very similar to the
> "container_of" macro in the Linux kernel, but it has an additional
> feature that instead of the type argument you may also pass an
> expression of that type; this makes initialising a variable with
> CONTAINER_OF easier.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 594b9fb..213b5f9 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1238,6 +1238,35 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
>   * Convenience macros.
>   */
>  
> +/*
> + * CONTAINER_OF work like this.  Given:
> + *    typedef struct {
> + *      ...
> + *      member_type member_name;
> + *      ...
> + *    } outer_type;
> + *    outer_type outer, *outer_var;
> + *    member_type *inner_ptr = &outer->member_name;
> + *
> + * Then, effectively:
> + *    outer_type *CONTAINER_OF(member_type *inner_ptr,
> + *                             *outer_var, // or type name for outer_type
> + *                             member_name);
> + *
> + * So that:
> + *    CONTAINER_OF(inner_ptr, *outer_var, member_name) == &outer
> + *    CONTAINER_OF(inner_ptr, outer_type, member_name) == &outer
> + */
> +#define CONTAINER_OF(inner_ptr, outer, member_name)                     \
> +    ({                                                                  \
> +        typeof(outer) *container_of_;                                   \
> +        container_of_ = (void*)((char*)(inner_ptr) -                    \
> +                                offsetof(typeof(outer), member_name));  \
> +        (void)(&container_of_->member_name ==                           \
> +               (typeof(inner_ptr))0) /* type check */;                  \
> +        container_of_;                                                  \
> +    })
> +
>  
>  /*
>   * All of these assume (or define)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:07:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnW9h-0007ph-Od; Wed, 18 Jan 2012 14:06:25 +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 1RnW9g-0007pE-HA
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:06:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326895577!9671468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10551 invoked from network); 18 Jan 2012 14:06:18 -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;
	18 Jan 2012 14:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10115983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:06:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 14: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
	1RnW9Z-00054W-8m; Wed, 18 Jan 2012 14:06:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RnW9Z-0003ml-5u;
	Wed, 18 Jan 2012 14:06:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20246.53721.166769.941437@mariner.uk.xensource.com>
Date: Wed, 18 Jan 2012 14:06:17 +0000
To: Jan Beulich <jbeulich@suse.com>, Andres Lagar-Cavilla
	<andres@lagarcavilla.org>, Adin Scannell <adin@scannell.ca>, Tim Deegan
	<tim@xen.org>, Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir@xen.org>
In-Reply-To: <osstest-10867-mainreport@xen.org>
References: <osstest-10867-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Heads-up re Re: [xen-unstable test] 10867: regressions
	- FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10867: regressions - FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 10649

My bisector is working on this and so far it seems to have narrowed it
down to: 75b8e982eb7e is good; 6c104b46ef89 is bad.

That means that one these commits has probably broken HVM:
  amd iommu: Add iommu emulation for hvm guest
  amd iommu: Introduces new helper functions to simplify bitwise operations
  amd iommu: Refactoring iommu ring buffer definition
  move declarations of some required per-arch functions into common headers
  ia64: fix build (once again)
  x86/mm: Code style fixes in mem_sharing.c
  x86/mm: Disable paging_prep

The bisector is currently testing e71bd3.  Full revision log below.

Ian.


changeset:   24492:6c104b46ef89
user:        Wei Wang <wei.wang2@amd.com>
date:        Thu Jan 12 13:50:50 2012 +0100
files:       xen/arch/x86/hvm/intercept.c xen/drivers/passthrough/amd/Makefile xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_guest.c xen/drivers/passthrough/amd/iommu_map.c xen/drivers/passthrough/amd/pci_amd_iommu.c xen/include/asm-x86/amd-iommu.h xen/include/asm-x86/hvm/io.h xen/include/asm-x86/hvm/svm/amd-iommu-defs.h xen/include/asm-x86/hvm/svm/amd-iommu-proto.h xen/include/xen/hvm/iommu.h
description:
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 guest OS. We have to expose iommu
functionality to HVM guest, if we want assign ATS device to it. A new
hypervisor mmio handler is added to intercept iommu mmio accesses from
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
Committed-by: Jan Beulich <jbeulich@suse.com>


changeset:   24491:522d544f4031
user:        Wei Wang <wei.wang2@amd.com>
date:        Thu Jan 12 13:49:34 2012 +0100
files:       xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_init.c xen/include/asm-x86/hvm/svm/amd-iommu-defs.h xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
description:
amd iommu: Introduces new helper functions to simplify bitwise operations

Signed-off-by: Wei Wang <wei.wang2@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>


changeset:   24490:d59816959ac0
user:        Wei Wang <wei.wang2@amd.com>
date:        Thu Jan 12 13:48:57 2012 +0100
files:       xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_init.c xen/include/asm-x86/amd-iommu.h
description:
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>
Committed-by: Jan Beulich <jbeulich@suse.com>


changeset:   24489:8d2fa20dd3f3
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Jan 12 13:45:47 2012 +0100
files:       xen/arch/ia64/xen/dom0_ops.c xen/arch/ia64/xen/domain.c xen/arch/ia64/xen/xensetup.c xen/arch/x86/domain.c xen/arch/x86/x86_64/domain.c xen/common/kernel.c xen/include/asm-ia64/hypercall.h xen/include/asm-x86/hypercall.h xen/include/asm-x86/setup.h xen/include/xen/hypercall.h
description:
move declarations of some required per-arch functions into common headers

... since it is pointless to have each arch declare them on their own
(and now and the - see ia64 - forget to do so).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>


changeset:   24488:e71bd3a75f07
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Jan 12 13:44:51 2012 +0100
files:       xen/arch/ia64/xen/mm.c xen/include/asm-ia64/kexec.h
description:
ia64: fix build (once again)

24423:069c08b7de46 failed to add a necessary include, and for a long
time kexec.h suffered from a missing structure forward declaration.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>


changeset:   24487:32dd444700bd
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jan 12 11:02:18 2012 +0000
files:       xen/arch/x86/mm.c xen/arch/x86/mm/mem_sharing.c
description:
x86/mm: Code style fixes in mem_sharing.c

No functional changes, only code style issues.

One small diff in mem_sharing_gref_to_gfn() looks like a logic change,
but it's not.  The flow was confusing, so it's been clarified.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24486:f04dfb11dd61
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jan 12 10:52:30 2012 +0000
files:       xen/arch/x86/mm/p2m.c
description:
x86/mm: Disable paging_prep

The only way to page-in a page is now the safe paging_load domctl.
(Unless the page was never paged out in the first place)

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24485:75b8e982eb7e
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jan 12 10:52:30 2012 +0000
files:       xen/arch/x86/mm/p2m.c
description:
x86/mm: Allow a page in p2m_ram_paged_out state to be loaded

This removes the need for a page to be accessed in order to be pageable
again. A pager can now page-in pages at will with no need to map them
in a separate thread.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:07:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnW9h-0007ph-Od; Wed, 18 Jan 2012 14:06:25 +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 1RnW9g-0007pE-HA
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:06:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326895577!9671468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10551 invoked from network); 18 Jan 2012 14:06:18 -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;
	18 Jan 2012 14:06:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10115983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:06:17 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 14: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
	1RnW9Z-00054W-8m; Wed, 18 Jan 2012 14:06:17 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RnW9Z-0003ml-5u;
	Wed, 18 Jan 2012 14:06:17 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20246.53721.166769.941437@mariner.uk.xensource.com>
Date: Wed, 18 Jan 2012 14:06:17 +0000
To: Jan Beulich <jbeulich@suse.com>, Andres Lagar-Cavilla
	<andres@lagarcavilla.org>, Adin Scannell <adin@scannell.ca>, Tim Deegan
	<tim@xen.org>, Wei Wang <wei.wang2@amd.com>, Keir Fraser <keir@xen.org>
In-Reply-To: <osstest-10867-mainreport@xen.org>
References: <osstest-10867-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Heads-up re Re: [xen-unstable test] 10867: regressions
	- FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 10867: regressions - FAIL"):
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 10649

My bisector is working on this and so far it seems to have narrowed it
down to: 75b8e982eb7e is good; 6c104b46ef89 is bad.

That means that one these commits has probably broken HVM:
  amd iommu: Add iommu emulation for hvm guest
  amd iommu: Introduces new helper functions to simplify bitwise operations
  amd iommu: Refactoring iommu ring buffer definition
  move declarations of some required per-arch functions into common headers
  ia64: fix build (once again)
  x86/mm: Code style fixes in mem_sharing.c
  x86/mm: Disable paging_prep

The bisector is currently testing e71bd3.  Full revision log below.

Ian.


changeset:   24492:6c104b46ef89
user:        Wei Wang <wei.wang2@amd.com>
date:        Thu Jan 12 13:50:50 2012 +0100
files:       xen/arch/x86/hvm/intercept.c xen/drivers/passthrough/amd/Makefile xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_guest.c xen/drivers/passthrough/amd/iommu_map.c xen/drivers/passthrough/amd/pci_amd_iommu.c xen/include/asm-x86/amd-iommu.h xen/include/asm-x86/hvm/io.h xen/include/asm-x86/hvm/svm/amd-iommu-defs.h xen/include/asm-x86/hvm/svm/amd-iommu-proto.h xen/include/xen/hvm/iommu.h
description:
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 guest OS. We have to expose iommu
functionality to HVM guest, if we want assign ATS device to it. A new
hypervisor mmio handler is added to intercept iommu mmio accesses from
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
Committed-by: Jan Beulich <jbeulich@suse.com>


changeset:   24491:522d544f4031
user:        Wei Wang <wei.wang2@amd.com>
date:        Thu Jan 12 13:49:34 2012 +0100
files:       xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_init.c xen/include/asm-x86/hvm/svm/amd-iommu-defs.h xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
description:
amd iommu: Introduces new helper functions to simplify bitwise operations

Signed-off-by: Wei Wang <wei.wang2@amd.com>
Committed-by: Jan Beulich <jbeulich@suse.com>


changeset:   24490:d59816959ac0
user:        Wei Wang <wei.wang2@amd.com>
date:        Thu Jan 12 13:48:57 2012 +0100
files:       xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_init.c xen/include/asm-x86/amd-iommu.h
description:
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>
Committed-by: Jan Beulich <jbeulich@suse.com>


changeset:   24489:8d2fa20dd3f3
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Jan 12 13:45:47 2012 +0100
files:       xen/arch/ia64/xen/dom0_ops.c xen/arch/ia64/xen/domain.c xen/arch/ia64/xen/xensetup.c xen/arch/x86/domain.c xen/arch/x86/x86_64/domain.c xen/common/kernel.c xen/include/asm-ia64/hypercall.h xen/include/asm-x86/hypercall.h xen/include/asm-x86/setup.h xen/include/xen/hypercall.h
description:
move declarations of some required per-arch functions into common headers

... since it is pointless to have each arch declare them on their own
(and now and the - see ia64 - forget to do so).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>


changeset:   24488:e71bd3a75f07
user:        Jan Beulich <jbeulich@suse.com>
date:        Thu Jan 12 13:44:51 2012 +0100
files:       xen/arch/ia64/xen/mm.c xen/include/asm-ia64/kexec.h
description:
ia64: fix build (once again)

24423:069c08b7de46 failed to add a necessary include, and for a long
time kexec.h suffered from a missing structure forward declaration.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>


changeset:   24487:32dd444700bd
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jan 12 11:02:18 2012 +0000
files:       xen/arch/x86/mm.c xen/arch/x86/mm/mem_sharing.c
description:
x86/mm: Code style fixes in mem_sharing.c

No functional changes, only code style issues.

One small diff in mem_sharing_gref_to_gfn() looks like a logic change,
but it's not.  The flow was confusing, so it's been clarified.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24486:f04dfb11dd61
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jan 12 10:52:30 2012 +0000
files:       xen/arch/x86/mm/p2m.c
description:
x86/mm: Disable paging_prep

The only way to page-in a page is now the safe paging_load domctl.
(Unless the page was never paged out in the first place)

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24485:75b8e982eb7e
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Thu Jan 12 10:52:30 2012 +0000
files:       xen/arch/x86/mm/p2m.c
description:
x86/mm: Allow a page in p2m_ram_paged_out state to be loaded

This removes the need for a page to be accessed in order to be pageable
again. A pager can now page-in pages at will with no need to map them
in a separate thread.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:31:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnWWC-00009g-KJ; Wed, 18 Jan 2012 14:29:40 +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 1RnWWA-00009F-Fr
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:29:38 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326896970!9504138!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 13494 invoked from network); 18 Jan 2012 14:29:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jan 2012 14:29: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
	q0IETO21006261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 18 Jan 2012 09:29:24 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0IETN2g006259;
	Wed, 18 Jan 2012 09:29:23 -0500
Date: Wed, 18 Jan 2012 10:29:23 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120118142923.GA6052@andromeda.dapyr.net>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<4F16BC97020000780006D6D6@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F16BC97020000780006D6D6@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > The issue as I understand is that the DVB drivers allocate their buffers
> > from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> > 
> > While the pv-ops one ends up quite frequently doing the bounce-buffering, 
> > which
> > implies that the DVB drivers end up allocating their buffers above the 4GB.
> > This means we end up spending some CPU time (in the guest) copying the 
> > memory
> > from >4GB to 0-4GB region (And vice-versa).
> 
> This reminds me of something (not sure what XenoLinux you use for
> comparison) - how are they allocating that memory? Not vmalloc_32()

I was using the 2.6.18, then the one I saw on Google for Gentoo, and now
I am going to look at the 2.6.38 from OpenSuSE.

> by chance (I remember having seen numerous uses under - iirc -
> drivers/media/)?
> 
> Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
> what their (driver) callers might expect in a PV guest (including the
> contiguity assumption for the latter, recalling that you earlier said
> you were able to see the problem after several guest starts), and I
> had put into our kernels an adjustment to make vmalloc_32() actually
> behave as expected.

Aaah.. The plot thickens! Let me look in the sources! Thanks for the
pointer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:31:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnWWC-00009g-KJ; Wed, 18 Jan 2012 14:29:40 +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 1RnWWA-00009F-Fr
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:29:38 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326896970!9504138!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 13494 invoked from network); 18 Jan 2012 14:29:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jan 2012 14:29: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
	q0IETO21006261
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 18 Jan 2012 09:29:24 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0IETN2g006259;
	Wed, 18 Jan 2012 09:29:23 -0500
Date: Wed, 18 Jan 2012 10:29:23 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120118142923.GA6052@andromeda.dapyr.net>
References: <20111214220700.GA9926@phenom.dumpdata.com>
	<zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<4F16BC97020000780006D6D6@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F16BC97020000780006D6D6@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.9i
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > The issue as I understand is that the DVB drivers allocate their buffers
> > from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> > 
> > While the pv-ops one ends up quite frequently doing the bounce-buffering, 
> > which
> > implies that the DVB drivers end up allocating their buffers above the 4GB.
> > This means we end up spending some CPU time (in the guest) copying the 
> > memory
> > from >4GB to 0-4GB region (And vice-versa).
> 
> This reminds me of something (not sure what XenoLinux you use for
> comparison) - how are they allocating that memory? Not vmalloc_32()

I was using the 2.6.18, then the one I saw on Google for Gentoo, and now
I am going to look at the 2.6.38 from OpenSuSE.

> by chance (I remember having seen numerous uses under - iirc -
> drivers/media/)?
> 
> Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
> what their (driver) callers might expect in a PV guest (including the
> contiguity assumption for the latter, recalling that you earlier said
> you were able to see the problem after several guest starts), and I
> had put into our kernels an adjustment to make vmalloc_32() actually
> behave as expected.

Aaah.. The plot thickens! Let me look in the sources! Thanks for the
pointer.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:32:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnWYN-0000OM-07; Wed, 18 Jan 2012 14:31:55 +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 1RnWYL-0000NC-I1
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:31:53 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326897105!9679916!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 17695 invoked from network); 18 Jan 2012 14:31:47 -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; 18 Jan 2012 14:31:47 -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
	q0IEVfHa006463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 18 Jan 2012 09:31:41 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0IEVei7006461;
	Wed, 18 Jan 2012 09:31:40 -0500
Date: Wed, 18 Jan 2012 10:31:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: djmagee@mageenet.net
Message-ID: <20120118143140.GB6052@andromeda.dapyr.net>
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
	<1326809782.14689.114.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
	<20120117201245.GA25805@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451B0@mnetexch2.adamapps.host>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EECC125FCE18E740AF561189E12602851451B0@mnetexch2.adamapps.host>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

On Tue, Jan 17, 2012 at 05:02:08PM -0500, djmagee@mageenet.net wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > Sent: Tuesday, January 17, 2012 3:13 PM
> > To: djmagee@mageenet.net
> > Cc: Ian Campbell; xen-devel@lists.xensource.com; Ian Jackson; Stefano
> > Stabellini
> > Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
> > assignable before adding to the domain
> > 
> > On Tue, Jan 17, 2012 at 09:24:39AM -0500, djmagee@mageenet.net wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > Sent: Tuesday, January 17, 2012 9:16 AM
> > > > To: djmagee@mageenet.net
> > > > Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> > > > Subject: RE: [Xen-devel] [PATCH] libxl_pci: check that host device
> > is
> > > > assignable before adding to the domain
> > > >
> > > > Please don't top post.
> > > >
> > > > On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> > > > > That was my first thought, but this was also the first thing in
> > libxl
> > > > > I touched and wasn't sure what would happen if I ended up
> nesting
> > > > > GC_INITs.  If it's safe to do then I can call
> > > > > libxl_device_pci_list_assignable, otherwise I'd have to pull the
> > meat
> > > > > out and put it in another function.  What's the best way to do
> > it?
> > > >
> > > > You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get
> a
> > ctx
> > > > from a gc which you use to call an externally visible function
> from
> > > > within libxl -- it'll do the right thing (TM).
> > >
> > > Cool, I'll send an updated patch along today.
> > 
> > You might want to check for 'xen-pciback', 'pciback' and 'pci-stub'
> > as they are valid.
> 
> Agreed. I posted an updated patch that calls ..._list_assignable instead
> of looping through the directory itself.  I'll work on a separate patch
> to update that function to check all applicable places.
> 
> In the 3.2.1 kernel I'm using, the module name is xen-pcipack, but the
> sysfs directory is just pciback.  Is there an instance where the
> directory is called xen-pcipack?

Not yet. I was hoping that somebody would create a patch in the
toolstack for it so that I can rename it to 'xen-pciback'.

So more of the 'this will happen in Q2 2012'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:32:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnWYN-0000OM-07; Wed, 18 Jan 2012 14:31:55 +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 1RnWYL-0000NC-I1
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:31:53 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326897105!9679916!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 17695 invoked from network); 18 Jan 2012 14:31:47 -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; 18 Jan 2012 14:31:47 -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
	q0IEVfHa006463
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 18 Jan 2012 09:31:41 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0IEVei7006461;
	Wed, 18 Jan 2012 09:31:40 -0500
Date: Wed, 18 Jan 2012 10:31:40 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: djmagee@mageenet.net
Message-ID: <20120118143140.GB6052@andromeda.dapyr.net>
References: <301cc006677f645bf4cb.1326753363@mnetdjm4.mageenet.host>
	<1326793645.14689.75.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AB@mnetexch2.adamapps.host>
	<1326809782.14689.114.camel@zakaz.uk.xensource.com>
	<EECC125FCE18E740AF561189E12602851451AC@mnetexch2.adamapps.host>
	<20120117201245.GA25805@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451B0@mnetexch2.adamapps.host>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <EECC125FCE18E740AF561189E12602851451B0@mnetexch2.adamapps.host>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
	assignable before adding 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

On Tue, Jan 17, 2012 at 05:02:08PM -0500, djmagee@mageenet.net wrote:
> > -----Original Message-----
> > From: Konrad Rzeszutek Wilk [mailto:konrad@darnok.org]
> > Sent: Tuesday, January 17, 2012 3:13 PM
> > To: djmagee@mageenet.net
> > Cc: Ian Campbell; xen-devel@lists.xensource.com; Ian Jackson; Stefano
> > Stabellini
> > Subject: Re: [Xen-devel] [PATCH] libxl_pci: check that host device is
> > assignable before adding to the domain
> > 
> > On Tue, Jan 17, 2012 at 09:24:39AM -0500, djmagee@mageenet.net wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > > > Sent: Tuesday, January 17, 2012 9:16 AM
> > > > To: djmagee@mageenet.net
> > > > Cc: xen-devel@lists.xensource.com; Ian Jackson; Stefano Stabellini
> > > > Subject: RE: [Xen-devel] [PATCH] libxl_pci: check that host device
> > is
> > > > assignable before adding to the domain
> > > >
> > > > Please don't top post.
> > > >
> > > > On Tue, 2012-01-17 at 14:05 +0000, djmagee@mageenet.net wrote:
> > > > > That was my first thought, but this was also the first thing in
> > libxl
> > > > > I touched and wasn't sure what would happen if I ended up
> nesting
> > > > > GC_INITs.  If it's safe to do then I can call
> > > > > libxl_device_pci_list_assignable, otherwise I'd have to pull the
> > meat
> > > > > out and put it in another function.  What's the best way to do
> > it?
> > > >
> > > > You can use libxl__gc_owner(gc) (or the helpful CTX macro) to get
> a
> > ctx
> > > > from a gc which you use to call an externally visible function
> from
> > > > within libxl -- it'll do the right thing (TM).
> > >
> > > Cool, I'll send an updated patch along today.
> > 
> > You might want to check for 'xen-pciback', 'pciback' and 'pci-stub'
> > as they are valid.
> 
> Agreed. I posted an updated patch that calls ..._list_assignable instead
> of looping through the directory itself.  I'll work on a separate patch
> to update that function to check all applicable places.
> 
> In the 3.2.1 kernel I'm using, the module name is xen-pcipack, but the
> sysfs directory is just pciback.  Is there an instance where the
> directory is called xen-pcipack?

Not yet. I was hoping that somebody would create a patch in the
toolstack for it so that I can rename it to 'xen-pciback'.

So more of the 'this will happen in Q2 2012'

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:40:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14: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 1RnWfp-000159-U9; Wed, 18 Jan 2012 14:39: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 1RnWfo-00014v-93
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:39:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326897570!2317862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25736 invoked from network); 18 Jan 2012 14:39:30 -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;
	18 Jan 2012 14:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10116771"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:39: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, 18 Jan 2012 14:39: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 1RnWfh-0005Fj-RT;
	Wed, 18 Jan 2012 14:39:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnWfh-0001tS-Ms;
	Wed, 18 Jan 2012 14:39:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10875-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 14:39:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10875: 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 10875 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10875/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10867
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10867
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10867
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10867 pass in 10875

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10867 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 870 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 Jan 18 14:40:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14: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 1RnWfp-000159-U9; Wed, 18 Jan 2012 14:39: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 1RnWfo-00014v-93
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:39:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1326897570!2317862!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25736 invoked from network); 18 Jan 2012 14:39:30 -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;
	18 Jan 2012 14:39:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10116771"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:39: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, 18 Jan 2012 14:39: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 1RnWfh-0005Fj-RT;
	Wed, 18 Jan 2012 14:39:29 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnWfh-0001tS-Ms;
	Wed, 18 Jan 2012 14:39:29 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10875-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 14:39:29 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10875: 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 10875 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10875/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10867
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10867
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10867
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10867 pass in 10875

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10867 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 870 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 Jan 18 14:42:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnWi7-0001Gd-MG; Wed, 18 Jan 2012 14:41:59 +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 1RnWi6-0001GG-6E
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:41:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326897711!11552188!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 20515 invoked from network); 18 Jan 2012 14:41:51 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-216.messagelabs.com with SMTP;
	18 Jan 2012 14:41:51 -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
	q0IEfnwk021518; Wed, 18 Jan 2012 14:41:49 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 q0IEfnKc019242; 
	Wed, 18 Jan 2012 09:41:49 -0500
Message-ID: <4F16DA2C.7060002@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 09:41:48 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
	<1326887328.14689.216.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326887328.14689.216.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 17/18] xenstored: add --priv-domid 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

On 01/18/2012 06:48 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> This parameter identifies an alternative service domain which has
>> superuser access to the xenstore database, which is currently required
>> to set up a new domain's xenstore entries.
> 
> Is this equivalent to dom0 adding write permissions to various paths for
> that domain as it builds it or is there more to it than that.
> 
> I know that the determination of "various paths" is non-trivial, so I'm
> not actually suggesting that is a better approach.
> 

It's more: the domain builder needs to create entries owned by the new
domain, and similar to UNIX chown() can only be called by the superuser.
The domain builder also currently relies on the fact that new keys it
creates inherit the parent's ownership instead of being owned by dom0.
The introduce operation is also privileged.

>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/xenstored_core.c   |    5 +++++
>>  tools/xenstore/xenstored_core.h   |    1 +
>>  tools/xenstore/xenstored_domain.c |    2 +-
>>  3 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index eea5fd6..9d087de 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -1774,6 +1774,7 @@ static struct option options[] = {
>>  	{ "event", 1, NULL, 'e' },
>>  	{ "help", 0, NULL, 'H' },
>>  	{ "no-fork", 0, NULL, 'N' },
>> +	{ "priv-domid", 1, NULL, 'p' },
>>  	{ "output-pid", 0, NULL, 'P' },
>>  	{ "entry-size", 1, NULL, 'S' },
>>  	{ "trace-file", 1, NULL, 'T' },
>> @@ -1786,6 +1787,7 @@ static struct option options[] = {
>>  
>>  extern void dump_conn(struct connection *conn); 
>>  int dom0_event = 0;
>> +int priv_domid = 0;
>>  
>>  int main(int argc, char *argv[])
>>  {
>> @@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
>>  		case 'e':
>>  			dom0_event = strtol(optarg, NULL, 10);
>>  			break;
>> +		case 'p':
>> +			priv_domid = strtol(optarg, NULL, 10);
>> +			break;
>>  		}
>>  	}
>>  	if (optind != argc)
>> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
>> index d3040ba..03e2e48 100644
>> --- a/tools/xenstore/xenstored_core.h
>> +++ b/tools/xenstore/xenstored_core.h
>> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>>  
>>  extern int event_fd;
>>  extern int dom0_event;
>> +extern int priv_domid;
>>  
>>  /* Map the kernel's xenstore page. */
>>  void *xenbus_map(void);
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 5f4a09e..46bcf3e 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
>>  
>>  bool domain_is_unprivileged(struct connection *conn)
>>  {
>> -	return (conn && conn->domain && conn->domain->domid != 0);
>> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
>>  }
>>  
>>  bool domain_can_write(struct connection *conn)
> 


-- 
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 Wed Jan 18 14:42:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:42:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnWi7-0001Gd-MG; Wed, 18 Jan 2012 14:41:59 +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 1RnWi6-0001GG-6E
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:41:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-216.messagelabs.com!1326897711!11552188!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 20515 invoked from network); 18 Jan 2012 14:41:51 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-216.messagelabs.com with SMTP;
	18 Jan 2012 14:41:51 -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
	q0IEfnwk021518; Wed, 18 Jan 2012 14:41:49 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 q0IEfnKc019242; 
	Wed, 18 Jan 2012 09:41:49 -0500
Message-ID: <4F16DA2C.7060002@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 09:41:48 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
	<1326887328.14689.216.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326887328.14689.216.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 17/18] xenstored: add --priv-domid 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

On 01/18/2012 06:48 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> This parameter identifies an alternative service domain which has
>> superuser access to the xenstore database, which is currently required
>> to set up a new domain's xenstore entries.
> 
> Is this equivalent to dom0 adding write permissions to various paths for
> that domain as it builds it or is there more to it than that.
> 
> I know that the determination of "various paths" is non-trivial, so I'm
> not actually suggesting that is a better approach.
> 

It's more: the domain builder needs to create entries owned by the new
domain, and similar to UNIX chown() can only be called by the superuser.
The domain builder also currently relies on the fact that new keys it
creates inherit the parent's ownership instead of being owned by dom0.
The introduce operation is also privileged.

>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/xenstored_core.c   |    5 +++++
>>  tools/xenstore/xenstored_core.h   |    1 +
>>  tools/xenstore/xenstored_domain.c |    2 +-
>>  3 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index eea5fd6..9d087de 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -1774,6 +1774,7 @@ static struct option options[] = {
>>  	{ "event", 1, NULL, 'e' },
>>  	{ "help", 0, NULL, 'H' },
>>  	{ "no-fork", 0, NULL, 'N' },
>> +	{ "priv-domid", 1, NULL, 'p' },
>>  	{ "output-pid", 0, NULL, 'P' },
>>  	{ "entry-size", 1, NULL, 'S' },
>>  	{ "trace-file", 1, NULL, 'T' },
>> @@ -1786,6 +1787,7 @@ static struct option options[] = {
>>  
>>  extern void dump_conn(struct connection *conn); 
>>  int dom0_event = 0;
>> +int priv_domid = 0;
>>  
>>  int main(int argc, char *argv[])
>>  {
>> @@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
>>  		case 'e':
>>  			dom0_event = strtol(optarg, NULL, 10);
>>  			break;
>> +		case 'p':
>> +			priv_domid = strtol(optarg, NULL, 10);
>> +			break;
>>  		}
>>  	}
>>  	if (optind != argc)
>> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
>> index d3040ba..03e2e48 100644
>> --- a/tools/xenstore/xenstored_core.h
>> +++ b/tools/xenstore/xenstored_core.h
>> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>>  
>>  extern int event_fd;
>>  extern int dom0_event;
>> +extern int priv_domid;
>>  
>>  /* Map the kernel's xenstore page. */
>>  void *xenbus_map(void);
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 5f4a09e..46bcf3e 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
>>  
>>  bool domain_is_unprivileged(struct connection *conn)
>>  {
>> -	return (conn && conn->domain && conn->domain->domid != 0);
>> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
>>  }
>>  
>>  bool domain_can_write(struct connection *conn)
> 


-- 
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 Wed Jan 18 14:45:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14: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 1RnWka-0001TC-8L; Wed, 18 Jan 2012 14:44:32 +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 1RnWkY-0001Sf-Au
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:44:30 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326897863!11353780!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 17156 invoked from network); 18 Jan 2012 14:44:24 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-182.messagelabs.com with SMTP;
	18 Jan 2012 14:44:24 -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
	q0IEiMFK028131; Wed, 18 Jan 2012 14:44:22 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 q0IEiM9k019406; 
	Wed, 18 Jan 2012 09:44:22 -0500
Message-ID: <4F16DAC5.2030806@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 09:44:21 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326888429.14689.221.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326888429.14689.221.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 07:07 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:36 +0000, Daniel De Graaf wrote:
>> This adds an ioctl to the /dev/xen/xenbus_backend device allowing the
>> xenbus backend to be started after the kernel has booted. This is
>> intended to allow dom0 to start another domain to run xenstore.
> 
> Does this new ioctl need to be made oneshot? What happens if you call it
> twice?
> 
> Also it should be disabled once a local xenstored has connected
> shouldn't it?
> 
> Diego's original patch handled that sort of thing, any reason not to
> simply forward port it?
> 

My original patch was trying to be more flexible in allowing xenstored
to be created later (migrating watches), or restarted in a different
domain. However, since the current version lacks that ability the
oneshot safeguards from Diego's patch should probably be added.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:45:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14: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 1RnWka-0001TC-8L; Wed, 18 Jan 2012 14:44:32 +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 1RnWkY-0001Sf-Au
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:44:30 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-182.messagelabs.com!1326897863!11353780!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 17156 invoked from network); 18 Jan 2012 14:44:24 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-182.messagelabs.com with SMTP;
	18 Jan 2012 14:44:24 -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
	q0IEiMFK028131; Wed, 18 Jan 2012 14:44:22 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 q0IEiM9k019406; 
	Wed, 18 Jan 2012 09:44:22 -0500
Message-ID: <4F16DAC5.2030806@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 09:44:21 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411373-7971-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326888429.14689.221.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326888429.14689.221.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in
 stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 07:07 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:36 +0000, Daniel De Graaf wrote:
>> This adds an ioctl to the /dev/xen/xenbus_backend device allowing the
>> xenbus backend to be started after the kernel has booted. This is
>> intended to allow dom0 to start another domain to run xenstore.
> 
> Does this new ioctl need to be made oneshot? What happens if you call it
> twice?
> 
> Also it should be disabled once a local xenstored has connected
> shouldn't it?
> 
> Diego's original patch handled that sort of thing, any reason not to
> simply forward port it?
> 

My original patch was trying to be more flexible in allowing xenstored
to be created later (migrating watches), or restarted in a different
domain. However, since the current version lacks that ability the
oneshot safeguards from Diego's patch should probably be added.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14: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 1RnWns-0001he-Sn; Wed, 18 Jan 2012 14:47: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 1RnWnr-0001hH-M6
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:47:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326898069!11422857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16709 invoked from network); 18 Jan 2012 14:47:49 -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;
	18 Jan 2012 14:47:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10116957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:47: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, 18 Jan 2012 14:47:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 14:47:34 +0000
In-Reply-To: <4F16DA2C.7060002@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
	<1326887328.14689.216.camel@zakaz.uk.xensource.com>
	<4F16DA2C.7060002@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326898054.14689.236.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 17/18] xenstored: add --priv-domid 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

On Wed, 2012-01-18 at 14:41 +0000, Daniel De Graaf wrote:
> On 01/18/2012 06:48 AM, Ian Campbell wrote:
> > On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> >> This parameter identifies an alternative service domain which has
> >> superuser access to the xenstore database, which is currently required
> >> to set up a new domain's xenstore entries.
> > 
> > Is this equivalent to dom0 adding write permissions to various paths for
> > that domain as it builds it or is there more to it than that.
> > 
> > I know that the determination of "various paths" is non-trivial, so I'm
> > not actually suggesting that is a better approach.
> > 
> 
> It's more: the domain builder needs to create entries owned by the new
> domain, and similar to UNIX chown() can only be called by the superuser.
> The domain builder also currently relies on the fact that new keys it
> creates inherit the parent's ownership instead of being owned by dom0.
> The introduce operation is also privileged.

Thanks for explaining. I wonder if there is somewhere this can be
usefully written down so that "privileged" is well defined?

docs/misc/xenstore.txt seems to be more about the wire protocol than the
underlying semantics. Perhaps someone on list can suggest a suitable
place?

> 
> >>
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >> ---
> >>  tools/xenstore/xenstored_core.c   |    5 +++++
> >>  tools/xenstore/xenstored_core.h   |    1 +
> >>  tools/xenstore/xenstored_domain.c |    2 +-
> >>  3 files changed, 7 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> >> index eea5fd6..9d087de 100644
> >> --- a/tools/xenstore/xenstored_core.c
> >> +++ b/tools/xenstore/xenstored_core.c
> >> @@ -1774,6 +1774,7 @@ static struct option options[] = {
> >>  	{ "event", 1, NULL, 'e' },
> >>  	{ "help", 0, NULL, 'H' },
> >>  	{ "no-fork", 0, NULL, 'N' },
> >> +	{ "priv-domid", 1, NULL, 'p' },
> >>  	{ "output-pid", 0, NULL, 'P' },
> >>  	{ "entry-size", 1, NULL, 'S' },
> >>  	{ "trace-file", 1, NULL, 'T' },
> >> @@ -1786,6 +1787,7 @@ static struct option options[] = {
> >>  
> >>  extern void dump_conn(struct connection *conn); 
> >>  int dom0_event = 0;
> >> +int priv_domid = 0;
> >>  
> >>  int main(int argc, char *argv[])
> >>  {
> >> @@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
> >>  		case 'e':
> >>  			dom0_event = strtol(optarg, NULL, 10);
> >>  			break;
> >> +		case 'p':
> >> +			priv_domid = strtol(optarg, NULL, 10);
> >> +			break;
> >>  		}
> >>  	}
> >>  	if (optind != argc)
> >> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> >> index d3040ba..03e2e48 100644
> >> --- a/tools/xenstore/xenstored_core.h
> >> +++ b/tools/xenstore/xenstored_core.h
> >> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
> >>  
> >>  extern int event_fd;
> >>  extern int dom0_event;
> >> +extern int priv_domid;
> >>  
> >>  /* Map the kernel's xenstore page. */
> >>  void *xenbus_map(void);
> >> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> >> index 5f4a09e..46bcf3e 100644
> >> --- a/tools/xenstore/xenstored_domain.c
> >> +++ b/tools/xenstore/xenstored_domain.c
> >> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
> >>  
> >>  bool domain_is_unprivileged(struct connection *conn)
> >>  {
> >> -	return (conn && conn->domain && conn->domain->domid != 0);
> >> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
> >>  }
> >>  
> >>  bool domain_can_write(struct connection *conn)
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14: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 1RnWns-0001he-Sn; Wed, 18 Jan 2012 14:47: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 1RnWnr-0001hH-M6
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:47:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326898069!11422857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16709 invoked from network); 18 Jan 2012 14:47:49 -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;
	18 Jan 2012 14:47:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10116957"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 14:47: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, 18 Jan 2012 14:47:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 14:47:34 +0000
In-Reply-To: <4F16DA2C.7060002@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-18-git-send-email-dgdegra@tycho.nsa.gov>
	<1326887328.14689.216.camel@zakaz.uk.xensource.com>
	<4F16DA2C.7060002@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326898054.14689.236.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 17/18] xenstored: add --priv-domid 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

On Wed, 2012-01-18 at 14:41 +0000, Daniel De Graaf wrote:
> On 01/18/2012 06:48 AM, Ian Campbell wrote:
> > On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> >> This parameter identifies an alternative service domain which has
> >> superuser access to the xenstore database, which is currently required
> >> to set up a new domain's xenstore entries.
> > 
> > Is this equivalent to dom0 adding write permissions to various paths for
> > that domain as it builds it or is there more to it than that.
> > 
> > I know that the determination of "various paths" is non-trivial, so I'm
> > not actually suggesting that is a better approach.
> > 
> 
> It's more: the domain builder needs to create entries owned by the new
> domain, and similar to UNIX chown() can only be called by the superuser.
> The domain builder also currently relies on the fact that new keys it
> creates inherit the parent's ownership instead of being owned by dom0.
> The introduce operation is also privileged.

Thanks for explaining. I wonder if there is somewhere this can be
usefully written down so that "privileged" is well defined?

docs/misc/xenstore.txt seems to be more about the wire protocol than the
underlying semantics. Perhaps someone on list can suggest a suitable
place?

> 
> >>
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >> ---
> >>  tools/xenstore/xenstored_core.c   |    5 +++++
> >>  tools/xenstore/xenstored_core.h   |    1 +
> >>  tools/xenstore/xenstored_domain.c |    2 +-
> >>  3 files changed, 7 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> >> index eea5fd6..9d087de 100644
> >> --- a/tools/xenstore/xenstored_core.c
> >> +++ b/tools/xenstore/xenstored_core.c
> >> @@ -1774,6 +1774,7 @@ static struct option options[] = {
> >>  	{ "event", 1, NULL, 'e' },
> >>  	{ "help", 0, NULL, 'H' },
> >>  	{ "no-fork", 0, NULL, 'N' },
> >> +	{ "priv-domid", 1, NULL, 'p' },
> >>  	{ "output-pid", 0, NULL, 'P' },
> >>  	{ "entry-size", 1, NULL, 'S' },
> >>  	{ "trace-file", 1, NULL, 'T' },
> >> @@ -1786,6 +1787,7 @@ static struct option options[] = {
> >>  
> >>  extern void dump_conn(struct connection *conn); 
> >>  int dom0_event = 0;
> >> +int priv_domid = 0;
> >>  
> >>  int main(int argc, char *argv[])
> >>  {
> >> @@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
> >>  		case 'e':
> >>  			dom0_event = strtol(optarg, NULL, 10);
> >>  			break;
> >> +		case 'p':
> >> +			priv_domid = strtol(optarg, NULL, 10);
> >> +			break;
> >>  		}
> >>  	}
> >>  	if (optind != argc)
> >> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> >> index d3040ba..03e2e48 100644
> >> --- a/tools/xenstore/xenstored_core.h
> >> +++ b/tools/xenstore/xenstored_core.h
> >> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
> >>  
> >>  extern int event_fd;
> >>  extern int dom0_event;
> >> +extern int priv_domid;
> >>  
> >>  /* Map the kernel's xenstore page. */
> >>  void *xenbus_map(void);
> >> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> >> index 5f4a09e..46bcf3e 100644
> >> --- a/tools/xenstore/xenstored_domain.c
> >> +++ b/tools/xenstore/xenstored_domain.c
> >> @@ -241,7 +241,7 @@ bool domain_can_read(struct connection *conn)
> >>  
> >>  bool domain_is_unprivileged(struct connection *conn)
> >>  {
> >> -	return (conn && conn->domain && conn->domain->domid != 0);
> >> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
> >>  }
> >>  
> >>  bool domain_can_write(struct connection *conn)
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:57:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnWwC-00024D-U0; Wed, 18 Jan 2012 14:56: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 1RnWwB-000248-Cv
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:56:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326898551!48940738!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 19531 invoked from network); 18 Jan 2012 14:55:51 -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;
	18 Jan 2012 14:55:51 -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
	q0IEuOwk025536; Wed, 18 Jan 2012 14:56: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 q0IEuNYX020358; 
	Wed, 18 Jan 2012 09:56:23 -0500
Message-ID: <4F16DD96.6080304@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 09:56:22 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1326882968.14689.176.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326882968.14689.176.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On 01/18/2012 05:36 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>
>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>> which was removed in 19041:ee62aaafff46 because it was not used.
>>
>> However, is now needed in order to support xenstored stub domains.
>> The xenstored stub domain is not priviliged like dom0 and so cannot
>> unilaterally map the xenbus page of other guests into it's address
>> space.  Therefore, before creating a domU the domain builder needs to
>> seed its grant table with a grant ref allowing the xenstored stub
>> domain to access the new domU's xenbus page.
>>
>> At present domU's do not start with their grant table mapped.
>> Instead it gets mapped when the guest requests a grant table from
>> the hypervisor.
>>
>> In order to seed the grant table, the domain builder first needs to
>> map it into dom0 address space.  But the hypercall to do this
>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>> for HVM guests.  Therfore, in order to seed the grant table of an
>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>> "physical" address space.
>>
>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
> about ordering in xlat.lst)
> 
> BTW, since Alex and Diego have subsequently left Citrix you could take
> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
> no idea if that's necessary though, I expect not.
> 
> Ian.
> 

I'm not an expert in this area, but this is how I read it: the portion of
the path authored by Alex/Diego was already signed-off when they were posted,
so since the current patches are derived works from them the sign-off may
need to stay in order to allow me to sign off because I cannot claim copyright
on all of the content. Assuming Citrix actually owns the copyright on the
patches, your Ack may suffice to replace the sign-off for this purpose.

I guess my real question here would be: should the sign-off from Alex and
Diego remain on these patches in addition to your Ack?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 14:57:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 14:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnWwC-00024D-U0; Wed, 18 Jan 2012 14:56: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 1RnWwB-000248-Cv
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 14:56:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326898551!48940738!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 19531 invoked from network); 18 Jan 2012 14:55:51 -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;
	18 Jan 2012 14:55:51 -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
	q0IEuOwk025536; Wed, 18 Jan 2012 14:56: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 q0IEuNYX020358; 
	Wed, 18 Jan 2012 09:56:23 -0500
Message-ID: <4F16DD96.6080304@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 09:56:22 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1326882968.14689.176.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326882968.14689.176.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On 01/18/2012 05:36 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>
>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>> which was removed in 19041:ee62aaafff46 because it was not used.
>>
>> However, is now needed in order to support xenstored stub domains.
>> The xenstored stub domain is not priviliged like dom0 and so cannot
>> unilaterally map the xenbus page of other guests into it's address
>> space.  Therefore, before creating a domU the domain builder needs to
>> seed its grant table with a grant ref allowing the xenstored stub
>> domain to access the new domU's xenbus page.
>>
>> At present domU's do not start with their grant table mapped.
>> Instead it gets mapped when the guest requests a grant table from
>> the hypervisor.
>>
>> In order to seed the grant table, the domain builder first needs to
>> map it into dom0 address space.  But the hypercall to do this
>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>> for HVM guests.  Therfore, in order to seed the grant table of an
>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>> "physical" address space.
>>
>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
> about ordering in xlat.lst)
> 
> BTW, since Alex and Diego have subsequently left Citrix you could take
> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
> no idea if that's necessary though, I expect not.
> 
> Ian.
> 

I'm not an expert in this area, but this is how I read it: the portion of
the path authored by Alex/Diego was already signed-off when they were posted,
so since the current patches are derived works from them the sign-off may
need to stay in order to allow me to sign off because I cannot claim copyright
on all of the content. Assuming Citrix actually owns the copyright on the
patches, your Ack may suffice to replace the sign-off for this purpose.

I guess my real question here would be: should the sign-off from Alex and
Diego remain on these patches in addition to your Ack?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 15:41:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXcm-0002bu-I4; Wed, 18 Jan 2012 15:40:32 +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 1RnXck-0002bp-RW
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:40:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326901223!7811074!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTkyNTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1916 invoked from network); 18 Jan 2012 15:40:23 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-10.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 15:40:23 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 7BCEA76C07F;
	Wed, 18 Jan 2012 07:40: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=mRTH6dEZnGudc1hMHvi6AUhMZ8SZ3okGkqZMFg5f05Bf
	7w0ZQgRxda2Pzm+HISpyVQQ9MN76eVWgZ2Nf6ThYaGzcQWPTzQNXYe8ftn0yZUq9
	Z3j4pDII2Ax1dJ8y8ANwWee4+OZJgRKOqiTl2EZhYzSMPrGlrzJvPAqbfjL/vwM=
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=m3QZzlDoMIwLCZjlbv55idQccRo=; b=C+cLDNo+
	DjJ6qs+y33zK0eEbhZwyxgBGjmIqAJuQFgufD5gHa+rh2O0z3sTvaK8XQp5HeQS5
	ZyB+FV1nP938Yf0jyLHzj1DSXDMQ57Rhk/Vo8MD7ohlPlT5aNud+W3OtAtX3+Ia7
	5HA9SBOLkpng6gsjjh1Eaml/sLJRdOEPPAs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 8337076C07C; 
	Wed, 18 Jan 2012 07:40: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;
	Wed, 18 Jan 2012 07:40:22 -0800
Message-ID: <e1111841be4c16c1c4ebfbee4bc8ed03.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.700.1326883173.1471.xen-devel@lists.xensource.com>
References: <mailman.700.1326883173.1471.xen-devel@lists.xensource.com>
Date: Wed, 18 Jan 2012 07:40:22 -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: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Wed, 18 Jan 2012 10:36:07 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously
> 	unused XENMEM_remove_from_physmap hypercall
> Message-ID: <1326882968.14689.176.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>
>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>> which was removed in 19041:ee62aaafff46 because it was not used.
>>
>> However, is now needed in order to support xenstored stub domains.
>> The xenstored stub domain is not priviliged like dom0 and so cannot
>> unilaterally map the xenbus page of other guests into it's address
>> space.  Therefore, before creating a domU the domain builder needs to
>> seed its grant table with a grant ref allowing the xenstored stub
>> domain to access the new domU's xenbus page.
>>
>> At present domU's do not start with their grant table mapped.
>> Instead it gets mapped when the guest requests a grant table from
>> the hypervisor.
>>
>> In order to seed the grant table, the domain builder first needs to
>> map it into dom0 address space.  But the hypercall to do this
>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>> for HVM guests.  Therfore, in order to seed the grant table of an
>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>> "physical" address space.
>>
>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
> about ordering in xlat.lst)
>
> BTW, since Alex and Diego have subsequently left Citrix you could take
> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
> no idea if that's necessary though, I expect not.
>
> Ian.

Nacked-by-me for a couple of reasons, see inline below:

>
>> ---
>>  xen/arch/ia64/xen/mm.c          |   34
>> ++++++++++++++++++++++++++++++++++
>>  xen/arch/x86/mm.c               |   35
>> +++++++++++++++++++++++++++++++++++
>>  xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
>>  xen/include/public/memory.h     |   16 ++++++++++++++++
>>  xen/include/xlat.lst            |    1 +
>>  xen/include/xsm/xsm.h           |    6 ++++++
>>  xen/xsm/dummy.c                 |    6 ++++++
>>  xen/xsm/flask/hooks.c           |    6 ++++++
>>  8 files changed, 118 insertions(+), 0 deletions(-)
>>
>> diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
>> index 84f6a61..a40f96a 100644
>> --- a/xen/arch/ia64/xen/mm.c
>> +++ b/xen/arch/ia64/xen/mm.c
>> @@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void)
>> arg)
>>          break;
>>      }
>>
>> +    case XENMEM_remove_from_physmap:
>> +    {
>> +        struct xen_remove_from_physmap xrfp;
>> +        unsigned long mfn;
>> +        struct domain *d;
>> +
>> +        if ( copy_from_guest(&xrfp, arg, 1) )
>> +            return -EFAULT;
>> +
>> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
>> +        if ( rc != 0 )
>> +            return rc;
>> +
>> +        if ( xsm_remove_from_physmap(current->domain, d) )
>> +        {
>> +            rcu_unlock_domain(d);
>> +            return -EPERM;
>> +        }
>> +
>> +        domain_lock(d);
>> +
>> +        mfn = gmfn_to_mfn(d, xrfp.gpfn);

Compilation will fail. gmfn_to_mfn has been deprecated in x86. You need to
wrap with an ifdef (ia64 still uses gmfn_to_mfn), and in the x86 case use
get_gfn_untyped.

>> +
>> +        if ( mfn_valid(mfn) )
>> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
>> +
And, you need to invoke put_gfn on your way out (no ifdef, ia64 has the stub)

Thanks!
Andres
>> +        domain_unlock(d);
>> +
>> +        rcu_unlock_domain(d);
>> +
>> +        break;
>> +    }
>> +
>> +
>>      case XENMEM_machine_memory_map:
>>      {
>>          struct xen_memory_map memmap;
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 1f996e0..39cc3c0 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4871,6 +4871,41 @@ long arch_memory_op(int op,
>> XEN_GUEST_HANDLE(void) arg)
>>          return rc;
>>      }
>>
>> +    case XENMEM_remove_from_physmap:
>> +    {
>> +        struct xen_remove_from_physmap xrfp;
>> +        unsigned long mfn;
>> +        struct domain *d;
>> +
>> +        if ( copy_from_guest(&xrfp, arg, 1) )
>> +            return -EFAULT;
>> +
>> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
>> +        if ( rc != 0 )
>> +            return rc;
>> +
>> +        if ( xsm_remove_from_physmap(current->domain, d) )
>> +        {
>> +            rcu_unlock_domain(d);
>> +            return -EPERM;
>> +        }
>> +
>> +        domain_lock(d);
>> +
>> +        mfn = get_gfn_untyped(d, xrfp.gpfn);
>> +
>> +        if ( mfn_valid(mfn) )
>> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn,
>> PAGE_ORDER_4K);
>> +
>> +        put_gfn(d, xrfp.gpfn);
>> +
>> +        domain_unlock(d);
>> +
>> +        rcu_unlock_domain(d);
>> +
>> +        break;
>> +    }
>> +
>>      case XENMEM_set_memory_map:
>>      {
>>          struct xen_foreign_memory_map fmap;
>> diff --git a/xen/arch/x86/x86_64/compat/mm.c
>> b/xen/arch/x86/x86_64/compat/mm.c
>> index bea94fe..dde5430 100644
>> --- a/xen/arch/x86/x86_64/compat/mm.c
>> +++ b/xen/arch/x86/x86_64/compat/mm.c
>> @@ -82,6 +82,20 @@ int compat_arch_memory_op(int op,
>> XEN_GUEST_HANDLE(void) arg)
>>          break;
>>      }
>>
>> +    case XENMEM_remove_from_physmap:
>> +    {
>> +        struct compat_remove_from_physmap cmp;
>> +        struct xen_remove_from_physmap *nat = (void
>> *)COMPAT_ARG_XLAT_VIRT_BASE;
>> +
>> +        if ( copy_from_guest(&cmp, arg, 1) )
>> +            return -EFAULT;
>> +
>> +        XLAT_remove_from_physmap(nat, &cmp);
>> +        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
>> +
>> +        break;
>> +    }
>> +
>>      case XENMEM_set_memory_map:
>>      {
>>          struct compat_foreign_memory_map cmp;
>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> index c5b78a8..308deff 100644
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -229,6 +229,22 @@ struct xen_add_to_physmap {
>>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>>
>> +/*
>> + * Unmaps the page appearing at a particular GPFN from the specified
>> guest's
>> + * pseudophysical address space.
>> + * arg == addr of xen_remove_from_physmap_t.
>> + */
>> +#define XENMEM_remove_from_physmap      15
>> +struct xen_remove_from_physmap {
>> +    /* Which domain to change the mapping for. */
>> +    domid_t domid;
>> +
>> +    /* GPFN of the current mapping of the page. */
>> +    xen_pfn_t     gpfn;
>> +};
>> +typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
>> +
>>  /*** REMOVED ***/
>>  /*#define XENMEM_translate_gpfn_list  8*/
>>
>> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
>> index 3d92175..ee1772c 100644
>> --- a/xen/include/xlat.lst
>> +++ b/xen/include/xlat.lst
>> @@ -81,6 +81,7 @@
>>  !	processor_power			platform.h
>>  ?	processor_px			platform.h
>>  !	psd_package			platform.h
>> +!	remove_from_physmap		memory.h
>>  ?	xenpf_pcpuinfo			platform.h
>>  ?	xenpf_pcpu_version		platform.h
>>  !	sched_poll			sched.h
>> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
>> index df6cec2..566c808 100644
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -169,6 +169,7 @@ struct xsm_operations {
>>      int (*update_va_mapping) (struct domain *d, struct domain *f,
>>                                                              l1_pgentry_t
>> pte);
>>      int (*add_to_physmap) (struct domain *d1, struct domain *d2);
>> +    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>>      int (*sendtrigger) (struct domain *d);
>>      int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq
>> *bind);
>>      int (*unbind_pt_irq) (struct domain *d);
>> @@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain
>> *d1, struct domain *d2)
>>      return xsm_call(add_to_physmap(d1, d2));
>>  }
>>
>> +static inline int xsm_remove_from_physmap(struct domain *d1, struct
>> domain *d2)
>> +{
>> +    return xsm_call(remove_from_physmap(d1, d2));
>> +}
>> +
>>  static inline int xsm_sendtrigger(struct domain *d)
>>  {
>>      return xsm_call(sendtrigger(d));
>> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
>> index 4bbfbff..65daa4e 100644
>> --- a/xen/xsm/dummy.c
>> +++ b/xen/xsm/dummy.c
>> @@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1,
>> struct domain *d2)
>>      return 0;
>>  }
>>
>> +static int dummy_remove_from_physmap (struct domain *d1, struct domain
>> *d2)
>> +{
>> +    return 0;
>> +}
>> +
>>  static int dummy_sendtrigger (struct domain *d)
>>  {
>>      return 0;
>> @@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>>      set_to_dummy_if_null(ops, mmu_machphys_update);
>>      set_to_dummy_if_null(ops, update_va_mapping);
>>      set_to_dummy_if_null(ops, add_to_physmap);
>> +    set_to_dummy_if_null(ops, remove_from_physmap);
>>      set_to_dummy_if_null(ops, sendtrigger);
>>      set_to_dummy_if_null(ops, bind_pt_irq);
>>      set_to_dummy_if_null(ops, pin_mem_cacheattr);
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index 0d35767..a2020a9 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain
>> *d1, struct domain *d2)
>>      return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>>  }
>>
>> +static int flask_remove_from_physmap(struct domain *d1, struct domain
>> *d2)
>> +{
>> +    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>> +}
>> +
>>  static int flask_sendtrigger(struct domain *d)
>>  {
>>      return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
>> DOMAIN__TRIGGER);
>> @@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
>>      .mmu_machphys_update = flask_mmu_machphys_update,
>>      .update_va_mapping = flask_update_va_mapping,
>>      .add_to_physmap = flask_add_to_physmap,
>> +    .remove_from_physmap = flask_remove_from_physmap,
>>      .sendtrigger = flask_sendtrigger,
>>      .get_device_group = flask_get_device_group,
>>      .test_assign_device = flask_test_assign_device,
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 18 Jan 2012 11:40:06 +0100
> From: Wei Wang <wei.wang2@amd.com>
> To: Dario Faggioli <raistlin@linux.it>
> Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com"
> 	<allen.m.kay@intel.com>,	xen-devel@lists.xensource.com, Keir Fraser
> 	<keir@xen.org>,	Jan Beulich <JBeulich@suse.com>
> Subject: Re: [Xen-devel] [PATCHv2 2 of 2] Move IOMMU faults handling
> 	into softirq for AMD-Vi.
> Message-ID: <4F16A186.4080303@amd.com>
> Content-Type: text/plain; charset="UTF-8"; format=flowed
>
> On 01/18/2012 09:53 AM, Dario Faggioli wrote:
>> On Tue, 2012-01-17 at 11:17 +0000, Keir Fraser wrote:
>>>> Dealing with interrupts from AMD-Vi IOMMU(s) 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>
>>>
>>> This patch needs fixing to apply to xen-unstable tip. Please do that
>>> and
>>> resubmit.
>>>
>> I see. I can easily rebase the patch but there are functional changes
>> involved, so I'd like to know what you think it's best to do first.
>>
>> In particular, the clash is against Wei's patches introducing PPR. So
>> now the IOMMU interrupt handler checks both event log and ppr log.
>>
>> Question is, should I move _BOTH_ these checks into softirq or just
>> defer event log processing, and leave ppr log handling in hard-irq
>> context? Quickly looking at the new specs, it seems to me that deferring
>> both should be fine, but I'd really appreciate your thoughts...
>
> I think put both event log and ppr log into softirq is fine. If you
> could have a patch like this, I can do a quick test on my machine.
> Thanks,
> Wei
>
>> Wei, Jan, Tim?
>>
>> Thanks and regards,
>> Dario
>>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Jan 2012 10:39:01 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,	Diego
> 	Ongaro <diego.ongaro@citrix.com>
> Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers
> 	to be delegated to other domains
> Message-ID: <1326883141.14689.177.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>
>> +static void clear_global_virq_handlers(struct domain *d)
>> +{
>> +    uint32_t virq;
>> +    int put_count = 0;
>> +
>> +    spin_lock(&global_virq_handlers_lock);
>> +
>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>> +        if (global_virq_handlers[virq] == d) {
>> +            global_virq_handlers[virq] = NULL;
>
> I don't suppose we should rebind to dom0, should we?
>
> Seems like we are pretty hosed if this ever happens in a non-controlled
> manner anyway...
>
>> +            put_count++;
>> +        }
>> +    }
>> +
>> +    spin_unlock(&global_virq_handlers_lock);
>> +
>> +    while (put_count) {
>> +        put_domain(d);
>> +        put_count--;
>> +    }
>> +}
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 18 Jan 2012 11:39:22 +0100
> From: Juergen Gross <juergen.gross@ts.fujitsu.com>
> To: Keir Fraser <keir.xen@gmail.com>
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via
> 	nmi-ipi
> Message-ID: <4F16A15A.3040405@ts.fujitsu.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 01/18/2012 10:36 AM, Keir Fraser wrote:
>> On 18/01/2012 09:31, "Keir Fraser"<keir.xen@gmail.com>  wrote:
>>
>>> On 18/01/2012 09:07, "Juergen Gross"<juergen.gross@ts.fujitsu.com>
>>> wrote:
>>>
>>>> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>>>>> On a real machine a cpu disabled via hlt with interrupts disabled can
>>>>> be
>>>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm,
>>>>> too.
>>>>>
>>>>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>>>>
>>>>>
>>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
>>>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence.
>>>> It
>>>> works
>>>> on initial system boot when the target vcpu is activated the first
>>>> time. If I
>>>> deactivate a vcpu and try to activate it again it will start to run,
>>>> but it
>>>> is
>>>> not starting at the specified entry point (at least it isn't
>>>> performing the
>>>> first instruction there).
>>>> Is there some special initialization needed to make this work? Do I
>>>> have to
>>>> reset
>>>> something on the vcpu before deactivating it?
>>> No it should just work. Hvmloader wakes and then sleeps every AP, in
>>> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the
>>> guest OS
>>> is not the first, as hvmloader already did it once! So this path should
>>> be
>>> working and indeed tested on every HVM guest boot.
>> Bit more info: INIT-SIPI logic is complicated by needing to avoid
>> deadlocks
>> between two VCPUs attempting to pause and reset each other. But the core
>> dispatch logic is in vlapic_init_sipi_action(). You will see that on
>> INIT,
>> we should call vcpu_reset() which will de-initialise and VCPU_down the
>> vcpu.
>> And then on SIPI we call hvm_vcpu_reset_state(), which should
>> reinitialise
>> and wake the vcpu to start running at the specified CS:IP.
>>
>> So the above will be good places for you to add tracing and work out
>> what's
>> going on. :-)
>
> Yeah, thanks for the confirmation this should work.
> Printing some diagnostics helped me to spot the error in my code.
>
>
> 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
>
>
> End of Xen-devel Digest, Vol 83, Issue 277
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 15:41:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:41:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXcm-0002bu-I4; Wed, 18 Jan 2012 15:40:32 +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 1RnXck-0002bp-RW
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:40:31 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326901223!7811074!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTkyNTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1916 invoked from network); 18 Jan 2012 15:40:23 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.207) by server-10.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 15:40:23 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 7BCEA76C07F;
	Wed, 18 Jan 2012 07:40: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=mRTH6dEZnGudc1hMHvi6AUhMZ8SZ3okGkqZMFg5f05Bf
	7w0ZQgRxda2Pzm+HISpyVQQ9MN76eVWgZ2Nf6ThYaGzcQWPTzQNXYe8ftn0yZUq9
	Z3j4pDII2Ax1dJ8y8ANwWee4+OZJgRKOqiTl2EZhYzSMPrGlrzJvPAqbfjL/vwM=
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=m3QZzlDoMIwLCZjlbv55idQccRo=; b=C+cLDNo+
	DjJ6qs+y33zK0eEbhZwyxgBGjmIqAJuQFgufD5gHa+rh2O0z3sTvaK8XQp5HeQS5
	ZyB+FV1nP938Yf0jyLHzj1DSXDMQ57Rhk/Vo8MD7ohlPlT5aNud+W3OtAtX3+Ia7
	5HA9SBOLkpng6gsjjh1Eaml/sLJRdOEPPAs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 8337076C07C; 
	Wed, 18 Jan 2012 07:40: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;
	Wed, 18 Jan 2012 07:40:22 -0800
Message-ID: <e1111841be4c16c1c4ebfbee4bc8ed03.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.700.1326883173.1471.xen-devel@lists.xensource.com>
References: <mailman.700.1326883173.1471.xen-devel@lists.xensource.com>
Date: Wed, 18 Jan 2012 07:40:22 -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: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap hypercall
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Wed, 18 Jan 2012 10:36:07 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously
> 	unused XENMEM_remove_from_physmap hypercall
> Message-ID: <1326882968.14689.176.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>
>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>> which was removed in 19041:ee62aaafff46 because it was not used.
>>
>> However, is now needed in order to support xenstored stub domains.
>> The xenstored stub domain is not priviliged like dom0 and so cannot
>> unilaterally map the xenbus page of other guests into it's address
>> space.  Therefore, before creating a domU the domain builder needs to
>> seed its grant table with a grant ref allowing the xenstored stub
>> domain to access the new domU's xenbus page.
>>
>> At present domU's do not start with their grant table mapped.
>> Instead it gets mapped when the guest requests a grant table from
>> the hypervisor.
>>
>> In order to seed the grant table, the domain builder first needs to
>> map it into dom0 address space.  But the hypercall to do this
>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>> for HVM guests.  Therfore, in order to seed the grant table of an
>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>> "physical" address space.
>>
>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
> about ordering in xlat.lst)
>
> BTW, since Alex and Diego have subsequently left Citrix you could take
> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
> no idea if that's necessary though, I expect not.
>
> Ian.

Nacked-by-me for a couple of reasons, see inline below:

>
>> ---
>>  xen/arch/ia64/xen/mm.c          |   34
>> ++++++++++++++++++++++++++++++++++
>>  xen/arch/x86/mm.c               |   35
>> +++++++++++++++++++++++++++++++++++
>>  xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
>>  xen/include/public/memory.h     |   16 ++++++++++++++++
>>  xen/include/xlat.lst            |    1 +
>>  xen/include/xsm/xsm.h           |    6 ++++++
>>  xen/xsm/dummy.c                 |    6 ++++++
>>  xen/xsm/flask/hooks.c           |    6 ++++++
>>  8 files changed, 118 insertions(+), 0 deletions(-)
>>
>> diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
>> index 84f6a61..a40f96a 100644
>> --- a/xen/arch/ia64/xen/mm.c
>> +++ b/xen/arch/ia64/xen/mm.c
>> @@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void)
>> arg)
>>          break;
>>      }
>>
>> +    case XENMEM_remove_from_physmap:
>> +    {
>> +        struct xen_remove_from_physmap xrfp;
>> +        unsigned long mfn;
>> +        struct domain *d;
>> +
>> +        if ( copy_from_guest(&xrfp, arg, 1) )
>> +            return -EFAULT;
>> +
>> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
>> +        if ( rc != 0 )
>> +            return rc;
>> +
>> +        if ( xsm_remove_from_physmap(current->domain, d) )
>> +        {
>> +            rcu_unlock_domain(d);
>> +            return -EPERM;
>> +        }
>> +
>> +        domain_lock(d);
>> +
>> +        mfn = gmfn_to_mfn(d, xrfp.gpfn);

Compilation will fail. gmfn_to_mfn has been deprecated in x86. You need to
wrap with an ifdef (ia64 still uses gmfn_to_mfn), and in the x86 case use
get_gfn_untyped.

>> +
>> +        if ( mfn_valid(mfn) )
>> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
>> +
And, you need to invoke put_gfn on your way out (no ifdef, ia64 has the stub)

Thanks!
Andres
>> +        domain_unlock(d);
>> +
>> +        rcu_unlock_domain(d);
>> +
>> +        break;
>> +    }
>> +
>> +
>>      case XENMEM_machine_memory_map:
>>      {
>>          struct xen_memory_map memmap;
>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>> index 1f996e0..39cc3c0 100644
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4871,6 +4871,41 @@ long arch_memory_op(int op,
>> XEN_GUEST_HANDLE(void) arg)
>>          return rc;
>>      }
>>
>> +    case XENMEM_remove_from_physmap:
>> +    {
>> +        struct xen_remove_from_physmap xrfp;
>> +        unsigned long mfn;
>> +        struct domain *d;
>> +
>> +        if ( copy_from_guest(&xrfp, arg, 1) )
>> +            return -EFAULT;
>> +
>> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
>> +        if ( rc != 0 )
>> +            return rc;
>> +
>> +        if ( xsm_remove_from_physmap(current->domain, d) )
>> +        {
>> +            rcu_unlock_domain(d);
>> +            return -EPERM;
>> +        }
>> +
>> +        domain_lock(d);
>> +
>> +        mfn = get_gfn_untyped(d, xrfp.gpfn);
>> +
>> +        if ( mfn_valid(mfn) )
>> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn,
>> PAGE_ORDER_4K);
>> +
>> +        put_gfn(d, xrfp.gpfn);
>> +
>> +        domain_unlock(d);
>> +
>> +        rcu_unlock_domain(d);
>> +
>> +        break;
>> +    }
>> +
>>      case XENMEM_set_memory_map:
>>      {
>>          struct xen_foreign_memory_map fmap;
>> diff --git a/xen/arch/x86/x86_64/compat/mm.c
>> b/xen/arch/x86/x86_64/compat/mm.c
>> index bea94fe..dde5430 100644
>> --- a/xen/arch/x86/x86_64/compat/mm.c
>> +++ b/xen/arch/x86/x86_64/compat/mm.c
>> @@ -82,6 +82,20 @@ int compat_arch_memory_op(int op,
>> XEN_GUEST_HANDLE(void) arg)
>>          break;
>>      }
>>
>> +    case XENMEM_remove_from_physmap:
>> +    {
>> +        struct compat_remove_from_physmap cmp;
>> +        struct xen_remove_from_physmap *nat = (void
>> *)COMPAT_ARG_XLAT_VIRT_BASE;
>> +
>> +        if ( copy_from_guest(&cmp, arg, 1) )
>> +            return -EFAULT;
>> +
>> +        XLAT_remove_from_physmap(nat, &cmp);
>> +        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
>> +
>> +        break;
>> +    }
>> +
>>      case XENMEM_set_memory_map:
>>      {
>>          struct compat_foreign_memory_map cmp;
>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> index c5b78a8..308deff 100644
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -229,6 +229,22 @@ struct xen_add_to_physmap {
>>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>>
>> +/*
>> + * Unmaps the page appearing at a particular GPFN from the specified
>> guest's
>> + * pseudophysical address space.
>> + * arg == addr of xen_remove_from_physmap_t.
>> + */
>> +#define XENMEM_remove_from_physmap      15
>> +struct xen_remove_from_physmap {
>> +    /* Which domain to change the mapping for. */
>> +    domid_t domid;
>> +
>> +    /* GPFN of the current mapping of the page. */
>> +    xen_pfn_t     gpfn;
>> +};
>> +typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
>> +
>>  /*** REMOVED ***/
>>  /*#define XENMEM_translate_gpfn_list  8*/
>>
>> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
>> index 3d92175..ee1772c 100644
>> --- a/xen/include/xlat.lst
>> +++ b/xen/include/xlat.lst
>> @@ -81,6 +81,7 @@
>>  !	processor_power			platform.h
>>  ?	processor_px			platform.h
>>  !	psd_package			platform.h
>> +!	remove_from_physmap		memory.h
>>  ?	xenpf_pcpuinfo			platform.h
>>  ?	xenpf_pcpu_version		platform.h
>>  !	sched_poll			sched.h
>> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
>> index df6cec2..566c808 100644
>> --- a/xen/include/xsm/xsm.h
>> +++ b/xen/include/xsm/xsm.h
>> @@ -169,6 +169,7 @@ struct xsm_operations {
>>      int (*update_va_mapping) (struct domain *d, struct domain *f,
>>                                                              l1_pgentry_t
>> pte);
>>      int (*add_to_physmap) (struct domain *d1, struct domain *d2);
>> +    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>>      int (*sendtrigger) (struct domain *d);
>>      int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq
>> *bind);
>>      int (*unbind_pt_irq) (struct domain *d);
>> @@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain
>> *d1, struct domain *d2)
>>      return xsm_call(add_to_physmap(d1, d2));
>>  }
>>
>> +static inline int xsm_remove_from_physmap(struct domain *d1, struct
>> domain *d2)
>> +{
>> +    return xsm_call(remove_from_physmap(d1, d2));
>> +}
>> +
>>  static inline int xsm_sendtrigger(struct domain *d)
>>  {
>>      return xsm_call(sendtrigger(d));
>> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
>> index 4bbfbff..65daa4e 100644
>> --- a/xen/xsm/dummy.c
>> +++ b/xen/xsm/dummy.c
>> @@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1,
>> struct domain *d2)
>>      return 0;
>>  }
>>
>> +static int dummy_remove_from_physmap (struct domain *d1, struct domain
>> *d2)
>> +{
>> +    return 0;
>> +}
>> +
>>  static int dummy_sendtrigger (struct domain *d)
>>  {
>>      return 0;
>> @@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>>      set_to_dummy_if_null(ops, mmu_machphys_update);
>>      set_to_dummy_if_null(ops, update_va_mapping);
>>      set_to_dummy_if_null(ops, add_to_physmap);
>> +    set_to_dummy_if_null(ops, remove_from_physmap);
>>      set_to_dummy_if_null(ops, sendtrigger);
>>      set_to_dummy_if_null(ops, bind_pt_irq);
>>      set_to_dummy_if_null(ops, pin_mem_cacheattr);
>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>> index 0d35767..a2020a9 100644
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain
>> *d1, struct domain *d2)
>>      return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>>  }
>>
>> +static int flask_remove_from_physmap(struct domain *d1, struct domain
>> *d2)
>> +{
>> +    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>> +}
>> +
>>  static int flask_sendtrigger(struct domain *d)
>>  {
>>      return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
>> DOMAIN__TRIGGER);
>> @@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
>>      .mmu_machphys_update = flask_mmu_machphys_update,
>>      .update_va_mapping = flask_update_va_mapping,
>>      .add_to_physmap = flask_add_to_physmap,
>> +    .remove_from_physmap = flask_remove_from_physmap,
>>      .sendtrigger = flask_sendtrigger,
>>      .get_device_group = flask_get_device_group,
>>      .test_assign_device = flask_test_assign_device,
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 18 Jan 2012 11:40:06 +0100
> From: Wei Wang <wei.wang2@amd.com>
> To: Dario Faggioli <raistlin@linux.it>
> Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com"
> 	<allen.m.kay@intel.com>,	xen-devel@lists.xensource.com, Keir Fraser
> 	<keir@xen.org>,	Jan Beulich <JBeulich@suse.com>
> Subject: Re: [Xen-devel] [PATCHv2 2 of 2] Move IOMMU faults handling
> 	into softirq for AMD-Vi.
> Message-ID: <4F16A186.4080303@amd.com>
> Content-Type: text/plain; charset="UTF-8"; format=flowed
>
> On 01/18/2012 09:53 AM, Dario Faggioli wrote:
>> On Tue, 2012-01-17 at 11:17 +0000, Keir Fraser wrote:
>>>> Dealing with interrupts from AMD-Vi IOMMU(s) 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>
>>>
>>> This patch needs fixing to apply to xen-unstable tip. Please do that
>>> and
>>> resubmit.
>>>
>> I see. I can easily rebase the patch but there are functional changes
>> involved, so I'd like to know what you think it's best to do first.
>>
>> In particular, the clash is against Wei's patches introducing PPR. So
>> now the IOMMU interrupt handler checks both event log and ppr log.
>>
>> Question is, should I move _BOTH_ these checks into softirq or just
>> defer event log processing, and leave ppr log handling in hard-irq
>> context? Quickly looking at the new specs, it seems to me that deferring
>> both should be fine, but I'd really appreciate your thoughts...
>
> I think put both event log and ppr log into softirq is fine. If you
> could have a patch like this, I can do a quick test on my machine.
> Thanks,
> Wei
>
>> Wei, Jan, Tim?
>>
>> Thanks and regards,
>> Dario
>>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Jan 2012 10:39:01 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,	Diego
> 	Ongaro <diego.ongaro@citrix.com>
> Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers
> 	to be delegated to other domains
> Message-ID: <1326883141.14689.177.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>
>> +static void clear_global_virq_handlers(struct domain *d)
>> +{
>> +    uint32_t virq;
>> +    int put_count = 0;
>> +
>> +    spin_lock(&global_virq_handlers_lock);
>> +
>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>> +        if (global_virq_handlers[virq] == d) {
>> +            global_virq_handlers[virq] = NULL;
>
> I don't suppose we should rebind to dom0, should we?
>
> Seems like we are pretty hosed if this ever happens in a non-controlled
> manner anyway...
>
>> +            put_count++;
>> +        }
>> +    }
>> +
>> +    spin_unlock(&global_virq_handlers_lock);
>> +
>> +    while (put_count) {
>> +        put_domain(d);
>> +        put_count--;
>> +    }
>> +}
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 18 Jan 2012 11:39:22 +0100
> From: Juergen Gross <juergen.gross@ts.fujitsu.com>
> To: Keir Fraser <keir.xen@gmail.com>
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via
> 	nmi-ipi
> Message-ID: <4F16A15A.3040405@ts.fujitsu.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 01/18/2012 10:36 AM, Keir Fraser wrote:
>> On 18/01/2012 09:31, "Keir Fraser"<keir.xen@gmail.com>  wrote:
>>
>>> On 18/01/2012 09:07, "Juergen Gross"<juergen.gross@ts.fujitsu.com>
>>> wrote:
>>>
>>>> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>>>>> On a real machine a cpu disabled via hlt with interrupts disabled can
>>>>> be
>>>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm,
>>>>> too.
>>>>>
>>>>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>>>>
>>>>>
>>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
>>>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence.
>>>> It
>>>> works
>>>> on initial system boot when the target vcpu is activated the first
>>>> time. If I
>>>> deactivate a vcpu and try to activate it again it will start to run,
>>>> but it
>>>> is
>>>> not starting at the specified entry point (at least it isn't
>>>> performing the
>>>> first instruction there).
>>>> Is there some special initialization needed to make this work? Do I
>>>> have to
>>>> reset
>>>> something on the vcpu before deactivating it?
>>> No it should just work. Hvmloader wakes and then sleeps every AP, in
>>> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the
>>> guest OS
>>> is not the first, as hvmloader already did it once! So this path should
>>> be
>>> working and indeed tested on every HVM guest boot.
>> Bit more info: INIT-SIPI logic is complicated by needing to avoid
>> deadlocks
>> between two VCPUs attempting to pause and reset each other. But the core
>> dispatch logic is in vlapic_init_sipi_action(). You will see that on
>> INIT,
>> we should call vcpu_reset() which will de-initialise and VCPU_down the
>> vcpu.
>> And then on SIPI we call hvm_vcpu_reset_state(), which should
>> reinitialise
>> and wake the vcpu to start running at the specified CS:IP.
>>
>> So the above will be good places for you to add tracing and work out
>> what's
>> going on. :-)
>
> Yeah, thanks for the confirmation this should work.
> Printing some diagnostics helped me to spot the error in my code.
>
>
> 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
>
>
> End of Xen-devel Digest, Vol 83, Issue 277
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 15:48:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXjA-0002t4-Nv; Wed, 18 Jan 2012 15: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 1RnXj9-0002sv-5m
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:47:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326901590!48949252!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc3OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3589 invoked from network); 18 Jan 2012 15:46:30 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-12.tower-27.messagelabs.com with SMTP;
	18 Jan 2012 15:46:30 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id EF9FD4B0091;
	Wed, 18 Jan 2012 07:47:04 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=oqwg3xrKhEPBEKf/POmSM/IBQwIvaQEV99LXc111wkGw
	11PybsnAnfLkJxQ1WBcdF5Jf2YbwvBH18+Eup6fDRae98OtWlzfkkQ2eQxZN4W/x
	SELrxPPFmAHSfUoSIwwvyfXrMGp7JbYAwAv8Xeh8eK+FHJA8imf3ZbaSlvtKSKg=
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=AVI21m/Fd12If1Suo2i/vLm28pw=; b=jjowvkqH
	ewGSBtZot6V0H3Lr2gdDlEzEKXABDAys1IwLeMZRO5i4SAtaqXu0LD4gyF+0YXw8
	YcCFgdkGMA0BcHwmAADwR1X1AdY4uGZn7V3svnGluWCl4Z+nbECb2Q7iqUTiNntK
	dt+wOb6Y/cnU/hDpO2yvCkbd4E/Un0mPjEo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 8FC644B007C; 
	Wed, 18 Jan 2012 07:47:04 -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, 18 Jan 2012 07:47:04 -0800
Message-ID: <503c0720d596f2bd82a8c2f9012db0d7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.745.1326901231.1471.xen-devel@lists.xensource.com>
References: <mailman.745.1326901231.1471.xen-devel@lists.xensource.com>
Date: Wed, 18 Jan 2012 07:47:04 -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: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap hypercall
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

> Send Xen-devel mailing list submissions to
> 	xen-devel@lists.xensource.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.xensource.com/mailman/listinfo/xen-devel
> or, via email, send a message with subject or body 'help' to
> 	xen-devel-request@lists.xensource.com
>
> You can reach the person managing the list at
> 	xen-devel-owner@lists.xensource.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xen-devel digest..."
>
> Date: Wed, 18 Jan 2012 07:40:22 -0800
> From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> To: xen-devel@lists.xensource.com
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,	Alex Zeffertt
> 	<alex.zeffertt@eu.citrix.com>,	Ian Campbell <Ian.Campbell@citrix.com>
> Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously
> 	unused XENMEM_remove_from_physmap hypercall
> Message-ID:
> 	<e1111841be4c16c1c4ebfbee4bc8ed03.squirrel@webmail.lagarcavilla.org>
> Content-Type: text/plain;charset=iso-8859-1
>
>> Date: Wed, 18 Jan 2012 10:36:07 +0000
>> From: Ian Campbell <Ian.Campbell@citrix.com>
>> To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
>> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>> Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously
>> 	unused XENMEM_remove_from_physmap hypercall
>> Message-ID: <1326882968.14689.176.camel@zakaz.uk.xensource.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>>
>>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>>> which was removed in 19041:ee62aaafff46 because it was not used.
>>>
>>> However, is now needed in order to support xenstored stub domains.
>>> The xenstored stub domain is not priviliged like dom0 and so cannot
>>> unilaterally map the xenbus page of other guests into it's address
>>> space.  Therefore, before creating a domU the domain builder needs to
>>> seed its grant table with a grant ref allowing the xenstored stub
>>> domain to access the new domU's xenbus page.
>>>
>>> At present domU's do not start with their grant table mapped.
>>> Instead it gets mapped when the guest requests a grant table from
>>> the hypervisor.
>>>
>>> In order to seed the grant table, the domain builder first needs to
>>> map it into dom0 address space.  But the hypercall to do this
>>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>>> for HVM guests.  Therfore, in order to seed the grant table of an
>>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>>> "physical" address space.
>>>
>>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>>
>>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
>> about ordering in xlat.lst)
>>
>> BTW, since Alex and Diego have subsequently left Citrix you could take
>> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
>> no idea if that's necessary though, I expect not.
>>
>> Ian.
>
> Nacked-by-me for a couple of reasons, see inline below:

Oh wow, spoke way too soon. It's very much correct. Ignore my spam please.
Andres

>
>>
>>> ---
>>>  xen/arch/ia64/xen/mm.c          |   34
>>> ++++++++++++++++++++++++++++++++++
>>>  xen/arch/x86/mm.c               |   35
>>> +++++++++++++++++++++++++++++++++++
>>>  xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
>>>  xen/include/public/memory.h     |   16 ++++++++++++++++
>>>  xen/include/xlat.lst            |    1 +
>>>  xen/include/xsm/xsm.h           |    6 ++++++
>>>  xen/xsm/dummy.c                 |    6 ++++++
>>>  xen/xsm/flask/hooks.c           |    6 ++++++
>>>  8 files changed, 118 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
>>> index 84f6a61..a40f96a 100644
>>> --- a/xen/arch/ia64/xen/mm.c
>>> +++ b/xen/arch/ia64/xen/mm.c
>>> @@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void)
>>> arg)
>>>          break;
>>>      }
>>>
>>> +    case XENMEM_remove_from_physmap:
>>> +    {
>>> +        struct xen_remove_from_physmap xrfp;
>>> +        unsigned long mfn;
>>> +        struct domain *d;
>>> +
>>> +        if ( copy_from_guest(&xrfp, arg, 1) )
>>> +            return -EFAULT;
>>> +
>>> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
>>> +        if ( rc != 0 )
>>> +            return rc;
>>> +
>>> +        if ( xsm_remove_from_physmap(current->domain, d) )
>>> +        {
>>> +            rcu_unlock_domain(d);
>>> +            return -EPERM;
>>> +        }
>>> +
>>> +        domain_lock(d);
>>> +
>>> +        mfn = gmfn_to_mfn(d, xrfp.gpfn);
>
> Compilation will fail. gmfn_to_mfn has been deprecated in x86. You need to
> wrap with an ifdef (ia64 still uses gmfn_to_mfn), and in the x86 case use
> get_gfn_untyped.
>
>>> +
>>> +        if ( mfn_valid(mfn) )
>>> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
>>> +
> And, you need to invoke put_gfn on your way out (no ifdef, ia64 has the
> stub)
>
> Thanks!
> Andres
>>> +        domain_unlock(d);
>>> +
>>> +        rcu_unlock_domain(d);
>>> +
>>> +        break;
>>> +    }
>>> +
>>> +
>>>      case XENMEM_machine_memory_map:
>>>      {
>>>          struct xen_memory_map memmap;
>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>> index 1f996e0..39cc3c0 100644
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -4871,6 +4871,41 @@ long arch_memory_op(int op,
>>> XEN_GUEST_HANDLE(void) arg)
>>>          return rc;
>>>      }
>>>
>>> +    case XENMEM_remove_from_physmap:
>>> +    {
>>> +        struct xen_remove_from_physmap xrfp;
>>> +        unsigned long mfn;
>>> +        struct domain *d;
>>> +
>>> +        if ( copy_from_guest(&xrfp, arg, 1) )
>>> +            return -EFAULT;
>>> +
>>> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
>>> +        if ( rc != 0 )
>>> +            return rc;
>>> +
>>> +        if ( xsm_remove_from_physmap(current->domain, d) )
>>> +        {
>>> +            rcu_unlock_domain(d);
>>> +            return -EPERM;
>>> +        }
>>> +
>>> +        domain_lock(d);
>>> +
>>> +        mfn = get_gfn_untyped(d, xrfp.gpfn);
>>> +
>>> +        if ( mfn_valid(mfn) )
>>> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn,
>>> PAGE_ORDER_4K);
>>> +
>>> +        put_gfn(d, xrfp.gpfn);
>>> +
>>> +        domain_unlock(d);
>>> +
>>> +        rcu_unlock_domain(d);
>>> +
>>> +        break;
>>> +    }
>>> +
>>>      case XENMEM_set_memory_map:
>>>      {
>>>          struct xen_foreign_memory_map fmap;
>>> diff --git a/xen/arch/x86/x86_64/compat/mm.c
>>> b/xen/arch/x86/x86_64/compat/mm.c
>>> index bea94fe..dde5430 100644
>>> --- a/xen/arch/x86/x86_64/compat/mm.c
>>> +++ b/xen/arch/x86/x86_64/compat/mm.c
>>> @@ -82,6 +82,20 @@ int compat_arch_memory_op(int op,
>>> XEN_GUEST_HANDLE(void) arg)
>>>          break;
>>>      }
>>>
>>> +    case XENMEM_remove_from_physmap:
>>> +    {
>>> +        struct compat_remove_from_physmap cmp;
>>> +        struct xen_remove_from_physmap *nat = (void
>>> *)COMPAT_ARG_XLAT_VIRT_BASE;
>>> +
>>> +        if ( copy_from_guest(&cmp, arg, 1) )
>>> +            return -EFAULT;
>>> +
>>> +        XLAT_remove_from_physmap(nat, &cmp);
>>> +        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
>>> +
>>> +        break;
>>> +    }
>>> +
>>>      case XENMEM_set_memory_map:
>>>      {
>>>          struct compat_foreign_memory_map cmp;
>>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>>> index c5b78a8..308deff 100644
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -229,6 +229,22 @@ struct xen_add_to_physmap {
>>>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>>>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>>>
>>> +/*
>>> + * Unmaps the page appearing at a particular GPFN from the specified
>>> guest's
>>> + * pseudophysical address space.
>>> + * arg == addr of xen_remove_from_physmap_t.
>>> + */
>>> +#define XENMEM_remove_from_physmap      15
>>> +struct xen_remove_from_physmap {
>>> +    /* Which domain to change the mapping for. */
>>> +    domid_t domid;
>>> +
>>> +    /* GPFN of the current mapping of the page. */
>>> +    xen_pfn_t     gpfn;
>>> +};
>>> +typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
>>> +DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
>>> +
>>>  /*** REMOVED ***/
>>>  /*#define XENMEM_translate_gpfn_list  8*/
>>>
>>> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
>>> index 3d92175..ee1772c 100644
>>> --- a/xen/include/xlat.lst
>>> +++ b/xen/include/xlat.lst
>>> @@ -81,6 +81,7 @@
>>>  !	processor_power			platform.h
>>>  ?	processor_px			platform.h
>>>  !	psd_package			platform.h
>>> +!	remove_from_physmap		memory.h
>>>  ?	xenpf_pcpuinfo			platform.h
>>>  ?	xenpf_pcpu_version		platform.h
>>>  !	sched_poll			sched.h
>>> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
>>> index df6cec2..566c808 100644
>>> --- a/xen/include/xsm/xsm.h
>>> +++ b/xen/include/xsm/xsm.h
>>> @@ -169,6 +169,7 @@ struct xsm_operations {
>>>      int (*update_va_mapping) (struct domain *d, struct domain *f,
>>>                                                              l1_pgentry_t
>>> pte);
>>>      int (*add_to_physmap) (struct domain *d1, struct domain *d2);
>>> +    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>>>      int (*sendtrigger) (struct domain *d);
>>>      int (*bind_pt_irq) (struct domain *d, struct
>>> xen_domctl_bind_pt_irq
>>> *bind);
>>>      int (*unbind_pt_irq) (struct domain *d);
>>> @@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain
>>> *d1, struct domain *d2)
>>>      return xsm_call(add_to_physmap(d1, d2));
>>>  }
>>>
>>> +static inline int xsm_remove_from_physmap(struct domain *d1, struct
>>> domain *d2)
>>> +{
>>> +    return xsm_call(remove_from_physmap(d1, d2));
>>> +}
>>> +
>>>  static inline int xsm_sendtrigger(struct domain *d)
>>>  {
>>>      return xsm_call(sendtrigger(d));
>>> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
>>> index 4bbfbff..65daa4e 100644
>>> --- a/xen/xsm/dummy.c
>>> +++ b/xen/xsm/dummy.c
>>> @@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain
>>> *d1,
>>> struct domain *d2)
>>>      return 0;
>>>  }
>>>
>>> +static int dummy_remove_from_physmap (struct domain *d1, struct domain
>>> *d2)
>>> +{
>>> +    return 0;
>>> +}
>>> +
>>>  static int dummy_sendtrigger (struct domain *d)
>>>  {
>>>      return 0;
>>> @@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>>>      set_to_dummy_if_null(ops, mmu_machphys_update);
>>>      set_to_dummy_if_null(ops, update_va_mapping);
>>>      set_to_dummy_if_null(ops, add_to_physmap);
>>> +    set_to_dummy_if_null(ops, remove_from_physmap);
>>>      set_to_dummy_if_null(ops, sendtrigger);
>>>      set_to_dummy_if_null(ops, bind_pt_irq);
>>>      set_to_dummy_if_null(ops, pin_mem_cacheattr);
>>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>>> index 0d35767..a2020a9 100644
>>> --- a/xen/xsm/flask/hooks.c
>>> +++ b/xen/xsm/flask/hooks.c
>>> @@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain
>>> *d1, struct domain *d2)
>>>      return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>>>  }
>>>
>>> +static int flask_remove_from_physmap(struct domain *d1, struct domain
>>> *d2)
>>> +{
>>> +    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>>> +}
>>> +
>>>  static int flask_sendtrigger(struct domain *d)
>>>  {
>>>      return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
>>> DOMAIN__TRIGGER);
>>> @@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
>>>      .mmu_machphys_update = flask_mmu_machphys_update,
>>>      .update_va_mapping = flask_update_va_mapping,
>>>      .add_to_physmap = flask_add_to_physmap,
>>> +    .remove_from_physmap = flask_remove_from_physmap,
>>>      .sendtrigger = flask_sendtrigger,
>>>      .get_device_group = flask_get_device_group,
>>>      .test_assign_device = flask_test_assign_device,
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 18 Jan 2012 11:40:06 +0100
>> From: Wei Wang <wei.wang2@amd.com>
>> To: Dario Faggioli <raistlin@linux.it>
>> Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com"
>> 	<allen.m.kay@intel.com>,	xen-devel@lists.xensource.com, Keir Fraser
>> 	<keir@xen.org>,	Jan Beulich <JBeulich@suse.com>
>> Subject: Re: [Xen-devel] [PATCHv2 2 of 2] Move IOMMU faults handling
>> 	into softirq for AMD-Vi.
>> Message-ID: <4F16A186.4080303@amd.com>
>> Content-Type: text/plain; charset="UTF-8"; format=flowed
>>
>> On 01/18/2012 09:53 AM, Dario Faggioli wrote:
>>> On Tue, 2012-01-17 at 11:17 +0000, Keir Fraser wrote:
>>>>> Dealing with interrupts from AMD-Vi IOMMU(s) 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>
>>>>
>>>> This patch needs fixing to apply to xen-unstable tip. Please do that
>>>> and
>>>> resubmit.
>>>>
>>> I see. I can easily rebase the patch but there are functional changes
>>> involved, so I'd like to know what you think it's best to do first.
>>>
>>> In particular, the clash is against Wei's patches introducing PPR. So
>>> now the IOMMU interrupt handler checks both event log and ppr log.
>>>
>>> Question is, should I move _BOTH_ these checks into softirq or just
>>> defer event log processing, and leave ppr log handling in hard-irq
>>> context? Quickly looking at the new specs, it seems to me that
>>> deferring
>>> both should be fine, but I'd really appreciate your thoughts...
>>
>> I think put both event log and ppr log into softirq is fine. If you
>> could have a patch like this, I can do a quick test on my machine.
>> Thanks,
>> Wei
>>
>>> Wei, Jan, Tim?
>>>
>>> Thanks and regards,
>>> Dario
>>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 18 Jan 2012 10:39:01 +0000
>> From: Ian Campbell <Ian.Campbell@citrix.com>
>> To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
>> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,	Diego
>> 	Ongaro <diego.ongaro@citrix.com>
>> Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers
>> 	to be delegated to other domains
>> Message-ID: <1326883141.14689.177.camel@zakaz.uk.xensource.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>>
>>> +static void clear_global_virq_handlers(struct domain *d)
>>> +{
>>> +    uint32_t virq;
>>> +    int put_count = 0;
>>> +
>>> +    spin_lock(&global_virq_handlers_lock);
>>> +
>>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>>> +        if (global_virq_handlers[virq] == d) {
>>> +            global_virq_handlers[virq] = NULL;
>>
>> I don't suppose we should rebind to dom0, should we?
>>
>> Seems like we are pretty hosed if this ever happens in a non-controlled
>> manner anyway...
>>
>>> +            put_count++;
>>> +        }
>>> +    }
>>> +
>>> +    spin_unlock(&global_virq_handlers_lock);
>>> +
>>> +    while (put_count) {
>>> +        put_domain(d);
>>> +        put_count--;
>>> +    }
>>> +}
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 18 Jan 2012 11:39:22 +0100
>> From: Juergen Gross <juergen.gross@ts.fujitsu.com>
>> To: Keir Fraser <keir.xen@gmail.com>
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via
>> 	nmi-ipi
>> Message-ID: <4F16A15A.3040405@ts.fujitsu.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 01/18/2012 10:36 AM, Keir Fraser wrote:
>>> On 18/01/2012 09:31, "Keir Fraser"<keir.xen@gmail.com>  wrote:
>>>
>>>> On 18/01/2012 09:07, "Juergen Gross"<juergen.gross@ts.fujitsu.com>
>>>> wrote:
>>>>
>>>>> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>>>>>> On a real machine a cpu disabled via hlt with interrupts disabled
>>>>>> can
>>>>>> be
>>>>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm,
>>>>>> too.
>>>>>>
>>>>>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>>>>>
>>>>>>
>>>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
>>>>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence.
>>>>> It
>>>>> works
>>>>> on initial system boot when the target vcpu is activated the first
>>>>> time. If I
>>>>> deactivate a vcpu and try to activate it again it will start to run,
>>>>> but it
>>>>> is
>>>>> not starting at the specified entry point (at least it isn't
>>>>> performing the
>>>>> first instruction there).
>>>>> Is there some special initialization needed to make this work? Do I
>>>>> have to
>>>>> reset
>>>>> something on the vcpu before deactivating it?
>>>> No it should just work. Hvmloader wakes and then sleeps every AP, in
>>>> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the
>>>> guest OS
>>>> is not the first, as hvmloader already did it once! So this path
>>>> should
>>>> be
>>>> working and indeed tested on every HVM guest boot.
>>> Bit more info: INIT-SIPI logic is complicated by needing to avoid
>>> deadlocks
>>> between two VCPUs attempting to pause and reset each other. But the
>>> core
>>> dispatch logic is in vlapic_init_sipi_action(). You will see that on
>>> INIT,
>>> we should call vcpu_reset() which will de-initialise and VCPU_down the
>>> vcpu.
>>> And then on SIPI we call hvm_vcpu_reset_state(), which should
>>> reinitialise
>>> and wake the vcpu to start running at the specified CS:IP.
>>>
>>> So the above will be good places for you to add tracing and work out
>>> what's
>>> going on. :-)
>>
>> Yeah, thanks for the confirmation this should work.
>> Printing some diagnostics helped me to spot the error in my code.
>>
>>
>> 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
>>
>>
>> End of Xen-devel Digest, Vol 83, Issue 277
>> ******************************************
>>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 284
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 15:48:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:48:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXjA-0002t4-Nv; Wed, 18 Jan 2012 15: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 1RnXj9-0002sv-5m
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:47:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326901590!48949252!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc3OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3589 invoked from network); 18 Jan 2012 15:46:30 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-12.tower-27.messagelabs.com with SMTP;
	18 Jan 2012 15:46:30 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id EF9FD4B0091;
	Wed, 18 Jan 2012 07:47:04 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=oqwg3xrKhEPBEKf/POmSM/IBQwIvaQEV99LXc111wkGw
	11PybsnAnfLkJxQ1WBcdF5Jf2YbwvBH18+Eup6fDRae98OtWlzfkkQ2eQxZN4W/x
	SELrxPPFmAHSfUoSIwwvyfXrMGp7JbYAwAv8Xeh8eK+FHJA8imf3ZbaSlvtKSKg=
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=AVI21m/Fd12If1Suo2i/vLm28pw=; b=jjowvkqH
	ewGSBtZot6V0H3Lr2gdDlEzEKXABDAys1IwLeMZRO5i4SAtaqXu0LD4gyF+0YXw8
	YcCFgdkGMA0BcHwmAADwR1X1AdY4uGZn7V3svnGluWCl4Z+nbECb2Q7iqUTiNntK
	dt+wOb6Y/cnU/hDpO2yvCkbd4E/Un0mPjEo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 8FC644B007C; 
	Wed, 18 Jan 2012 07:47:04 -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, 18 Jan 2012 07:47:04 -0800
Message-ID: <503c0720d596f2bd82a8c2f9012db0d7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.745.1326901231.1471.xen-devel@lists.xensource.com>
References: <mailman.745.1326901231.1471.xen-devel@lists.xensource.com>
Date: Wed, 18 Jan 2012 07:47:04 -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: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap hypercall
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

> Send Xen-devel mailing list submissions to
> 	xen-devel@lists.xensource.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.xensource.com/mailman/listinfo/xen-devel
> or, via email, send a message with subject or body 'help' to
> 	xen-devel-request@lists.xensource.com
>
> You can reach the person managing the list at
> 	xen-devel-owner@lists.xensource.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xen-devel digest..."
>
> Date: Wed, 18 Jan 2012 07:40:22 -0800
> From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> To: xen-devel@lists.xensource.com
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,	Alex Zeffertt
> 	<alex.zeffertt@eu.citrix.com>,	Ian Campbell <Ian.Campbell@citrix.com>
> Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously
> 	unused XENMEM_remove_from_physmap hypercall
> Message-ID:
> 	<e1111841be4c16c1c4ebfbee4bc8ed03.squirrel@webmail.lagarcavilla.org>
> Content-Type: text/plain;charset=iso-8859-1
>
>> Date: Wed, 18 Jan 2012 10:36:07 +0000
>> From: Ian Campbell <Ian.Campbell@citrix.com>
>> To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
>> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
>> Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously
>> 	unused XENMEM_remove_from_physmap hypercall
>> Message-ID: <1326882968.14689.176.camel@zakaz.uk.xensource.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>>
>>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>>> which was removed in 19041:ee62aaafff46 because it was not used.
>>>
>>> However, is now needed in order to support xenstored stub domains.
>>> The xenstored stub domain is not priviliged like dom0 and so cannot
>>> unilaterally map the xenbus page of other guests into it's address
>>> space.  Therefore, before creating a domU the domain builder needs to
>>> seed its grant table with a grant ref allowing the xenstored stub
>>> domain to access the new domU's xenbus page.
>>>
>>> At present domU's do not start with their grant table mapped.
>>> Instead it gets mapped when the guest requests a grant table from
>>> the hypervisor.
>>>
>>> In order to seed the grant table, the domain builder first needs to
>>> map it into dom0 address space.  But the hypercall to do this
>>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>>> for HVM guests.  Therfore, in order to seed the grant table of an
>>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>>> "physical" address space.
>>>
>>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>>
>>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>
>> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
>> about ordering in xlat.lst)
>>
>> BTW, since Alex and Diego have subsequently left Citrix you could take
>> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
>> no idea if that's necessary though, I expect not.
>>
>> Ian.
>
> Nacked-by-me for a couple of reasons, see inline below:

Oh wow, spoke way too soon. It's very much correct. Ignore my spam please.
Andres

>
>>
>>> ---
>>>  xen/arch/ia64/xen/mm.c          |   34
>>> ++++++++++++++++++++++++++++++++++
>>>  xen/arch/x86/mm.c               |   35
>>> +++++++++++++++++++++++++++++++++++
>>>  xen/arch/x86/x86_64/compat/mm.c |   14 ++++++++++++++
>>>  xen/include/public/memory.h     |   16 ++++++++++++++++
>>>  xen/include/xlat.lst            |    1 +
>>>  xen/include/xsm/xsm.h           |    6 ++++++
>>>  xen/xsm/dummy.c                 |    6 ++++++
>>>  xen/xsm/flask/hooks.c           |    6 ++++++
>>>  8 files changed, 118 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/xen/arch/ia64/xen/mm.c b/xen/arch/ia64/xen/mm.c
>>> index 84f6a61..a40f96a 100644
>>> --- a/xen/arch/ia64/xen/mm.c
>>> +++ b/xen/arch/ia64/xen/mm.c
>>> @@ -3448,6 +3448,40 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(void)
>>> arg)
>>>          break;
>>>      }
>>>
>>> +    case XENMEM_remove_from_physmap:
>>> +    {
>>> +        struct xen_remove_from_physmap xrfp;
>>> +        unsigned long mfn;
>>> +        struct domain *d;
>>> +
>>> +        if ( copy_from_guest(&xrfp, arg, 1) )
>>> +            return -EFAULT;
>>> +
>>> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
>>> +        if ( rc != 0 )
>>> +            return rc;
>>> +
>>> +        if ( xsm_remove_from_physmap(current->domain, d) )
>>> +        {
>>> +            rcu_unlock_domain(d);
>>> +            return -EPERM;
>>> +        }
>>> +
>>> +        domain_lock(d);
>>> +
>>> +        mfn = gmfn_to_mfn(d, xrfp.gpfn);
>
> Compilation will fail. gmfn_to_mfn has been deprecated in x86. You need to
> wrap with an ifdef (ia64 still uses gmfn_to_mfn), and in the x86 case use
> get_gfn_untyped.
>
>>> +
>>> +        if ( mfn_valid(mfn) )
>>> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn, 0);
>>> +
> And, you need to invoke put_gfn on your way out (no ifdef, ia64 has the
> stub)
>
> Thanks!
> Andres
>>> +        domain_unlock(d);
>>> +
>>> +        rcu_unlock_domain(d);
>>> +
>>> +        break;
>>> +    }
>>> +
>>> +
>>>      case XENMEM_machine_memory_map:
>>>      {
>>>          struct xen_memory_map memmap;
>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
>>> index 1f996e0..39cc3c0 100644
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -4871,6 +4871,41 @@ long arch_memory_op(int op,
>>> XEN_GUEST_HANDLE(void) arg)
>>>          return rc;
>>>      }
>>>
>>> +    case XENMEM_remove_from_physmap:
>>> +    {
>>> +        struct xen_remove_from_physmap xrfp;
>>> +        unsigned long mfn;
>>> +        struct domain *d;
>>> +
>>> +        if ( copy_from_guest(&xrfp, arg, 1) )
>>> +            return -EFAULT;
>>> +
>>> +        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
>>> +        if ( rc != 0 )
>>> +            return rc;
>>> +
>>> +        if ( xsm_remove_from_physmap(current->domain, d) )
>>> +        {
>>> +            rcu_unlock_domain(d);
>>> +            return -EPERM;
>>> +        }
>>> +
>>> +        domain_lock(d);
>>> +
>>> +        mfn = get_gfn_untyped(d, xrfp.gpfn);
>>> +
>>> +        if ( mfn_valid(mfn) )
>>> +            guest_physmap_remove_page(d, xrfp.gpfn, mfn,
>>> PAGE_ORDER_4K);
>>> +
>>> +        put_gfn(d, xrfp.gpfn);
>>> +
>>> +        domain_unlock(d);
>>> +
>>> +        rcu_unlock_domain(d);
>>> +
>>> +        break;
>>> +    }
>>> +
>>>      case XENMEM_set_memory_map:
>>>      {
>>>          struct xen_foreign_memory_map fmap;
>>> diff --git a/xen/arch/x86/x86_64/compat/mm.c
>>> b/xen/arch/x86/x86_64/compat/mm.c
>>> index bea94fe..dde5430 100644
>>> --- a/xen/arch/x86/x86_64/compat/mm.c
>>> +++ b/xen/arch/x86/x86_64/compat/mm.c
>>> @@ -82,6 +82,20 @@ int compat_arch_memory_op(int op,
>>> XEN_GUEST_HANDLE(void) arg)
>>>          break;
>>>      }
>>>
>>> +    case XENMEM_remove_from_physmap:
>>> +    {
>>> +        struct compat_remove_from_physmap cmp;
>>> +        struct xen_remove_from_physmap *nat = (void
>>> *)COMPAT_ARG_XLAT_VIRT_BASE;
>>> +
>>> +        if ( copy_from_guest(&cmp, arg, 1) )
>>> +            return -EFAULT;
>>> +
>>> +        XLAT_remove_from_physmap(nat, &cmp);
>>> +        rc = arch_memory_op(op, guest_handle_from_ptr(nat, void));
>>> +
>>> +        break;
>>> +    }
>>> +
>>>      case XENMEM_set_memory_map:
>>>      {
>>>          struct compat_foreign_memory_map cmp;
>>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>>> index c5b78a8..308deff 100644
>>> --- a/xen/include/public/memory.h
>>> +++ b/xen/include/public/memory.h
>>> @@ -229,6 +229,22 @@ struct xen_add_to_physmap {
>>>  typedef struct xen_add_to_physmap xen_add_to_physmap_t;
>>>  DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
>>>
>>> +/*
>>> + * Unmaps the page appearing at a particular GPFN from the specified
>>> guest's
>>> + * pseudophysical address space.
>>> + * arg == addr of xen_remove_from_physmap_t.
>>> + */
>>> +#define XENMEM_remove_from_physmap      15
>>> +struct xen_remove_from_physmap {
>>> +    /* Which domain to change the mapping for. */
>>> +    domid_t domid;
>>> +
>>> +    /* GPFN of the current mapping of the page. */
>>> +    xen_pfn_t     gpfn;
>>> +};
>>> +typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
>>> +DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
>>> +
>>>  /*** REMOVED ***/
>>>  /*#define XENMEM_translate_gpfn_list  8*/
>>>
>>> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
>>> index 3d92175..ee1772c 100644
>>> --- a/xen/include/xlat.lst
>>> +++ b/xen/include/xlat.lst
>>> @@ -81,6 +81,7 @@
>>>  !	processor_power			platform.h
>>>  ?	processor_px			platform.h
>>>  !	psd_package			platform.h
>>> +!	remove_from_physmap		memory.h
>>>  ?	xenpf_pcpuinfo			platform.h
>>>  ?	xenpf_pcpu_version		platform.h
>>>  !	sched_poll			sched.h
>>> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
>>> index df6cec2..566c808 100644
>>> --- a/xen/include/xsm/xsm.h
>>> +++ b/xen/include/xsm/xsm.h
>>> @@ -169,6 +169,7 @@ struct xsm_operations {
>>>      int (*update_va_mapping) (struct domain *d, struct domain *f,
>>>                                                              l1_pgentry_t
>>> pte);
>>>      int (*add_to_physmap) (struct domain *d1, struct domain *d2);
>>> +    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
>>>      int (*sendtrigger) (struct domain *d);
>>>      int (*bind_pt_irq) (struct domain *d, struct
>>> xen_domctl_bind_pt_irq
>>> *bind);
>>>      int (*unbind_pt_irq) (struct domain *d);
>>> @@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain
>>> *d1, struct domain *d2)
>>>      return xsm_call(add_to_physmap(d1, d2));
>>>  }
>>>
>>> +static inline int xsm_remove_from_physmap(struct domain *d1, struct
>>> domain *d2)
>>> +{
>>> +    return xsm_call(remove_from_physmap(d1, d2));
>>> +}
>>> +
>>>  static inline int xsm_sendtrigger(struct domain *d)
>>>  {
>>>      return xsm_call(sendtrigger(d));
>>> diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
>>> index 4bbfbff..65daa4e 100644
>>> --- a/xen/xsm/dummy.c
>>> +++ b/xen/xsm/dummy.c
>>> @@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain
>>> *d1,
>>> struct domain *d2)
>>>      return 0;
>>>  }
>>>
>>> +static int dummy_remove_from_physmap (struct domain *d1, struct domain
>>> *d2)
>>> +{
>>> +    return 0;
>>> +}
>>> +
>>>  static int dummy_sendtrigger (struct domain *d)
>>>  {
>>>      return 0;
>>> @@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
>>>      set_to_dummy_if_null(ops, mmu_machphys_update);
>>>      set_to_dummy_if_null(ops, update_va_mapping);
>>>      set_to_dummy_if_null(ops, add_to_physmap);
>>> +    set_to_dummy_if_null(ops, remove_from_physmap);
>>>      set_to_dummy_if_null(ops, sendtrigger);
>>>      set_to_dummy_if_null(ops, bind_pt_irq);
>>>      set_to_dummy_if_null(ops, pin_mem_cacheattr);
>>> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
>>> index 0d35767..a2020a9 100644
>>> --- a/xen/xsm/flask/hooks.c
>>> +++ b/xen/xsm/flask/hooks.c
>>> @@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain
>>> *d1, struct domain *d2)
>>>      return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>>>  }
>>>
>>> +static int flask_remove_from_physmap(struct domain *d1, struct domain
>>> *d2)
>>> +{
>>> +    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>>> +}
>>> +
>>>  static int flask_sendtrigger(struct domain *d)
>>>  {
>>>      return domain_has_perm(current->domain, d, SECCLASS_DOMAIN,
>>> DOMAIN__TRIGGER);
>>> @@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
>>>      .mmu_machphys_update = flask_mmu_machphys_update,
>>>      .update_va_mapping = flask_update_va_mapping,
>>>      .add_to_physmap = flask_add_to_physmap,
>>> +    .remove_from_physmap = flask_remove_from_physmap,
>>>      .sendtrigger = flask_sendtrigger,
>>>      .get_device_group = flask_get_device_group,
>>>      .test_assign_device = flask_test_assign_device,
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 18 Jan 2012 11:40:06 +0100
>> From: Wei Wang <wei.wang2@amd.com>
>> To: Dario Faggioli <raistlin@linux.it>
>> Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com"
>> 	<allen.m.kay@intel.com>,	xen-devel@lists.xensource.com, Keir Fraser
>> 	<keir@xen.org>,	Jan Beulich <JBeulich@suse.com>
>> Subject: Re: [Xen-devel] [PATCHv2 2 of 2] Move IOMMU faults handling
>> 	into softirq for AMD-Vi.
>> Message-ID: <4F16A186.4080303@amd.com>
>> Content-Type: text/plain; charset="UTF-8"; format=flowed
>>
>> On 01/18/2012 09:53 AM, Dario Faggioli wrote:
>>> On Tue, 2012-01-17 at 11:17 +0000, Keir Fraser wrote:
>>>>> Dealing with interrupts from AMD-Vi IOMMU(s) 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>
>>>>
>>>> This patch needs fixing to apply to xen-unstable tip. Please do that
>>>> and
>>>> resubmit.
>>>>
>>> I see. I can easily rebase the patch but there are functional changes
>>> involved, so I'd like to know what you think it's best to do first.
>>>
>>> In particular, the clash is against Wei's patches introducing PPR. So
>>> now the IOMMU interrupt handler checks both event log and ppr log.
>>>
>>> Question is, should I move _BOTH_ these checks into softirq or just
>>> defer event log processing, and leave ppr log handling in hard-irq
>>> context? Quickly looking at the new specs, it seems to me that
>>> deferring
>>> both should be fine, but I'd really appreciate your thoughts...
>>
>> I think put both event log and ppr log into softirq is fine. If you
>> could have a patch like this, I can do a quick test on my machine.
>> Thanks,
>> Wei
>>
>>> Wei, Jan, Tim?
>>>
>>> Thanks and regards,
>>> Dario
>>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 18 Jan 2012 10:39:01 +0000
>> From: Ian Campbell <Ian.Campbell@citrix.com>
>> To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
>> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,	Diego
>> 	Ongaro <diego.ongaro@citrix.com>
>> Subject: Re: [Xen-devel] [PATCH 02/18] xen: allow global VIRQ handlers
>> 	to be delegated to other domains
>> Message-ID: <1326883141.14689.177.camel@zakaz.uk.xensource.com>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>>
>>> +static void clear_global_virq_handlers(struct domain *d)
>>> +{
>>> +    uint32_t virq;
>>> +    int put_count = 0;
>>> +
>>> +    spin_lock(&global_virq_handlers_lock);
>>> +
>>> +    for (virq = 0; virq < NR_VIRQS; virq++) {
>>> +        if (global_virq_handlers[virq] == d) {
>>> +            global_virq_handlers[virq] = NULL;
>>
>> I don't suppose we should rebind to dom0, should we?
>>
>> Seems like we are pretty hosed if this ever happens in a non-controlled
>> manner anyway...
>>
>>> +            put_count++;
>>> +        }
>>> +    }
>>> +
>>> +    spin_unlock(&global_virq_handlers_lock);
>>> +
>>> +    while (put_count) {
>>> +        put_domain(d);
>>> +        put_count--;
>>> +    }
>>> +}
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 18 Jan 2012 11:39:22 +0100
>> From: Juergen Gross <juergen.gross@ts.fujitsu.com>
>> To: Keir Fraser <keir.xen@gmail.com>
>> Cc: xen-devel@lists.xensource.com
>> Subject: Re: [Xen-devel] [PATCH] Allow wake up of offline vcpu via
>> 	nmi-ipi
>> Message-ID: <4F16A15A.3040405@ts.fujitsu.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 01/18/2012 10:36 AM, Keir Fraser wrote:
>>> On 18/01/2012 09:31, "Keir Fraser"<keir.xen@gmail.com>  wrote:
>>>
>>>> On 18/01/2012 09:07, "Juergen Gross"<juergen.gross@ts.fujitsu.com>
>>>> wrote:
>>>>
>>>>> On 01/18/2012 09:48 AM, Juergen Gross wrote:
>>>>>> On a real machine a cpu disabled via hlt with interrupts disabled
>>>>>> can
>>>>>> be
>>>>>> reactivated via a nmi ipi. Enable the hypervisor to do this for hvm,
>>>>>> too.
>>>>>>
>>>>>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>>>>>
>>>>>>
>>>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>>> xen/arch/x86/hvm/vlapic.c |    5 ++++-
>>>>> BTW: I was not able to reactivate a vcpu via INIT/SIPI/SIPI sequence.
>>>>> It
>>>>> works
>>>>> on initial system boot when the target vcpu is activated the first
>>>>> time. If I
>>>>> deactivate a vcpu and try to activate it again it will start to run,
>>>>> but it
>>>>> is
>>>>> not starting at the specified entry point (at least it isn't
>>>>> performing the
>>>>> first instruction there).
>>>>> Is there some special initialization needed to make this work? Do I
>>>>> have to
>>>>> reset
>>>>> something on the vcpu before deactivating it?
>>>> No it should just work. Hvmloader wakes and then sleeps every AP, in
>>>> hvmloader/smp.c. So even the first INIT-SIPI wakeup of an AP in the
>>>> guest OS
>>>> is not the first, as hvmloader already did it once! So this path
>>>> should
>>>> be
>>>> working and indeed tested on every HVM guest boot.
>>> Bit more info: INIT-SIPI logic is complicated by needing to avoid
>>> deadlocks
>>> between two VCPUs attempting to pause and reset each other. But the
>>> core
>>> dispatch logic is in vlapic_init_sipi_action(). You will see that on
>>> INIT,
>>> we should call vcpu_reset() which will de-initialise and VCPU_down the
>>> vcpu.
>>> And then on SIPI we call hvm_vcpu_reset_state(), which should
>>> reinitialise
>>> and wake the vcpu to start running at the specified CS:IP.
>>>
>>> So the above will be good places for you to add tracing and work out
>>> what's
>>> going on. :-)
>>
>> Yeah, thanks for the confirmation this should work.
>> Printing some diagnostics helped me to spot the error in my code.
>>
>>
>> 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
>>
>>
>> End of Xen-devel Digest, Vol 83, Issue 277
>> ******************************************
>>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 284
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 15:51:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXn4-0003bP-Dg; Wed, 18 Jan 2012 15:51:10 +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 1RnXn3-0003aw-0Y
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:51:09 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326901861!10893134!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 29762 invoked from network); 18 Jan 2012 15:51:02 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Jan 2012 15:51:02 -0000
Received: from mail5-tx2-R.bigfish.com (10.9.14.241) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 15:50:53 +0000
Received: from mail5-tx2 (localhost [127.0.0.1])	by mail5-tx2-R.bigfish.com
	(Postfix) with ESMTP id EEB50440538;
	Wed, 18 Jan 2012 15:51:00 +0000 (UTC)
X-SpamScore: -19
X-BigFish: VPS-19(zzbb2dI9371I1432N98dK4015L111aLzz1202hzz8275bhz2dhc1ahc1bh668h839h93fh61h)
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 mail5-tx2 (localhost.localdomain [127.0.0.1]) by mail5-tx2
	(MessageSwitch) id 1326901824118899_5963;
	Wed, 18 Jan 2012 15:50:24 +0000 (UTC)
Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.252])	by
	mail5-tx2.bigfish.com (Postfix) with ESMTP id 00F94280055;
	Wed, 18 Jan 2012 15:50:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 15:50:15 +0000
X-WSS-ID: 0LY03ZV-01-2IC-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 22F1D102806B;	Wed, 18 Jan 2012 09:50:19 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 18 Jan 2012 09:50:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 18 Jan 2012 09:50: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, 18 Jan 2012
	10:50:18 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4C60749C65A; Wed, 18 Jan 2012
	15:50:17 +0000 (GMT)
Message-ID: <4F16EAEC.5090102@amd.com>
Date: Wed, 18 Jan 2012 16:53:16 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
	<4F16A186.4080303@amd.com> <1326894667.5856.17.camel@Solace>
In-Reply-To: <1326894667.5856.17.camel@Solace>
X-OriginatorOrg: amd.com
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCHv3] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 02:51 PM, Dario Faggioli wrote:
> Hello Wei,
>
> Here it is, and it seems to work for me, but of course I'm not testing
> PPR. If you could give this a go and let me know... I'll repost in a
> separate thread if it happens to be fine.

Hi,
It works on my machine with PPR log enabled.
Thanks,
Wei

Tested-by: Wei Wang <wei.wang2@amd.com>

> Thanks again,
> Dario
>
> --
>
> Move IOMMU faults handling into softirq for AMD-Vi.
>
> Dealing with interrupts from AMD-Vi IOMMU(s) 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 15ab61865ecb xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Jan 18 13:01:23 2012 +0100
> @@ -32,6 +32,8 @@
>
>   static int __initdata nr_amd_iommus;
>
> +static struct tasklet amd_iommu_irq_tasklet;
> +
>   unsigned short ivrs_bdf_entries;
>   static struct radix_tree_root ivrs_maps;
>   struct list_head amd_iommu_head;
> @@ -689,14 +691,48 @@ static void iommu_check_ppr_log(struct a
>       spin_unlock_irqrestore(&iommu->lock, flags);
>   }
>
> +static void do_amd_iommu_irq(unsigned long data)
> +{
> +    struct amd_iommu *iommu;
> +
> +    if ( !iommu_found() )
> +    {
> +        AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n");
> +        return;
> +    }
> +
> +    /*
> +     * No matter from where the interrupt came from, check all the
> +     * IOMMUs present in the system. This allows for having just one
> +     * tasklet (instead of one per each IOMMUs).
> +     */
> +    for_each_amd_iommu ( iommu ) {
> +        iommu_check_event_log(iommu);
> +
> +        if ( iommu->ppr_log.buffer != NULL )
> +            iommu_check_ppr_log(iommu);
> +    }
> +}
> +
>   static void iommu_interrupt_handler(int irq, void *dev_id,
>                                       struct cpu_user_regs *regs)
>   {
> +    u32 entry;
> +    unsigned long flags;
>       struct amd_iommu *iommu = dev_id;
> -    iommu_check_event_log(iommu);
>
> -    if ( iommu->ppr_log.buffer != NULL )
> -        iommu_check_ppr_log(iommu);
> +    spin_lock_irqsave(&iommu->lock, flags);
> +
> +    /* Silence interrupts from both event and PPR logging */
> +    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
> +    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
> +    iommu_clear_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
> +    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
> +
> +    spin_unlock_irqrestore(&iommu->lock, flags);
> +
> +    /* It is the tasklet that will clear the logs and re-enable interrupts */
> +    tasklet_schedule(&amd_iommu_irq_tasklet);
>   }
>
>   static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
> @@ -876,6 +912,8 @@ static int __init amd_iommu_init_one(str
>       printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
>       nr_amd_iommus++;
>
> +    softirq_tasklet_init(&amd_iommu_irq_tasklet, do_amd_iommu_irq, 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 Wed Jan 18 15:51:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXn4-0003bP-Dg; Wed, 18 Jan 2012 15:51:10 +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 1RnXn3-0003aw-0Y
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:51:09 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326901861!10893134!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 29762 invoked from network); 18 Jan 2012 15:51:02 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-13.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Jan 2012 15:51:02 -0000
Received: from mail5-tx2-R.bigfish.com (10.9.14.241) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 15:50:53 +0000
Received: from mail5-tx2 (localhost [127.0.0.1])	by mail5-tx2-R.bigfish.com
	(Postfix) with ESMTP id EEB50440538;
	Wed, 18 Jan 2012 15:51:00 +0000 (UTC)
X-SpamScore: -19
X-BigFish: VPS-19(zzbb2dI9371I1432N98dK4015L111aLzz1202hzz8275bhz2dhc1ahc1bh668h839h93fh61h)
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 mail5-tx2 (localhost.localdomain [127.0.0.1]) by mail5-tx2
	(MessageSwitch) id 1326901824118899_5963;
	Wed, 18 Jan 2012 15:50:24 +0000 (UTC)
Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.252])	by
	mail5-tx2.bigfish.com (Postfix) with ESMTP id 00F94280055;
	Wed, 18 Jan 2012 15:50:24 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 15:50:15 +0000
X-WSS-ID: 0LY03ZV-01-2IC-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 22F1D102806B;	Wed, 18 Jan 2012 09:50:19 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep01.amd.com
	(163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Wed, 18 Jan 2012 09:50:31 -0600
Received: from storexhtp02.amd.com (172.24.4.4) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Wed, 18 Jan 2012 09:50: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, 18 Jan 2012
	10:50:18 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 4C60749C65A; Wed, 18 Jan 2012
	15:50:17 +0000 (GMT)
Message-ID: <4F16EAEC.5090102@amd.com>
Date: Wed, 18 Jan 2012 16:53:16 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Dario Faggioli <raistlin@linux.it>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
	<4F16A186.4080303@amd.com> <1326894667.5856.17.camel@Solace>
In-Reply-To: <1326894667.5856.17.camel@Solace>
X-OriginatorOrg: amd.com
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCHv3] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 02:51 PM, Dario Faggioli wrote:
> Hello Wei,
>
> Here it is, and it seems to work for me, but of course I'm not testing
> PPR. If you could give this a go and let me know... I'll repost in a
> separate thread if it happens to be fine.

Hi,
It works on my machine with PPR log enabled.
Thanks,
Wei

Tested-by: Wei Wang <wei.wang2@amd.com>

> Thanks again,
> Dario
>
> --
>
> Move IOMMU faults handling into softirq for AMD-Vi.
>
> Dealing with interrupts from AMD-Vi IOMMU(s) 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 15ab61865ecb xen/drivers/passthrough/amd/iommu_init.c
> --- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Jan 18 13:01:23 2012 +0100
> @@ -32,6 +32,8 @@
>
>   static int __initdata nr_amd_iommus;
>
> +static struct tasklet amd_iommu_irq_tasklet;
> +
>   unsigned short ivrs_bdf_entries;
>   static struct radix_tree_root ivrs_maps;
>   struct list_head amd_iommu_head;
> @@ -689,14 +691,48 @@ static void iommu_check_ppr_log(struct a
>       spin_unlock_irqrestore(&iommu->lock, flags);
>   }
>
> +static void do_amd_iommu_irq(unsigned long data)
> +{
> +    struct amd_iommu *iommu;
> +
> +    if ( !iommu_found() )
> +    {
> +        AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n");
> +        return;
> +    }
> +
> +    /*
> +     * No matter from where the interrupt came from, check all the
> +     * IOMMUs present in the system. This allows for having just one
> +     * tasklet (instead of one per each IOMMUs).
> +     */
> +    for_each_amd_iommu ( iommu ) {
> +        iommu_check_event_log(iommu);
> +
> +        if ( iommu->ppr_log.buffer != NULL )
> +            iommu_check_ppr_log(iommu);
> +    }
> +}
> +
>   static void iommu_interrupt_handler(int irq, void *dev_id,
>                                       struct cpu_user_regs *regs)
>   {
> +    u32 entry;
> +    unsigned long flags;
>       struct amd_iommu *iommu = dev_id;
> -    iommu_check_event_log(iommu);
>
> -    if ( iommu->ppr_log.buffer != NULL )
> -        iommu_check_ppr_log(iommu);
> +    spin_lock_irqsave(&iommu->lock, flags);
> +
> +    /* Silence interrupts from both event and PPR logging */
> +    entry = readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
> +    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
> +    iommu_clear_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
> +    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
> +
> +    spin_unlock_irqrestore(&iommu->lock, flags);
> +
> +    /* It is the tasklet that will clear the logs and re-enable interrupts */
> +    tasklet_schedule(&amd_iommu_irq_tasklet);
>   }
>
>   static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
> @@ -876,6 +912,8 @@ static int __init amd_iommu_init_one(str
>       printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
>       nr_amd_iommus++;
>
> +    softirq_tasklet_init(&amd_iommu_irq_tasklet, do_amd_iommu_irq, 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 Wed Jan 18 15:57:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXse-0003nJ-8e; Wed, 18 Jan 2012 15:56:56 +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 1RnXsc-0003n8-Bn
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:56:54 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326902207!12932595!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 22615 invoked from network); 18 Jan 2012 15:56:47 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-216.messagelabs.com with SMTP;
	18 Jan 2012 15:56:47 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74599257; Wed, 18 Jan 2012 16:56:46 +0100
Message-ID: <1326902181.5856.19.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Keir Fraser <keir@xen.org>
Date: Wed, 18 Jan 2012 16:56:21 +0100
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"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: [Xen-devel] [PATCHv3] 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="===============5030118704337303872=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5030118704337303872==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-6qpda0J42k3/VqT79iK9"


--=-6qpda0J42k3/VqT79iK9
Content-Type: multipart/mixed; boundary="=-ELDboK5eggB2H88FJXyb"


--=-ELDboK5eggB2H88FJXyb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-taskl=
et,
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 lo=
w
level IRQ handler and enabled back in the tasklet body. Notice that this ma=
y
cause the log to overflow, but none of the existing entry will be overwritt=
en.
                                =20
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 15ab61865ecb xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 17 12:40:52 2012 +00=
00
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Jan 18 13:01:23 2012 +01=
00
@@ -32,6 +32,8 @@
=20
 static int __initdata nr_amd_iommus;
=20
+static struct tasklet amd_iommu_irq_tasklet;
+
 unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
@@ -689,14 +691,48 @@ static void iommu_check_ppr_log(struct a
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
=20
+static void do_amd_iommu_irq(unsigned long data)
+{
+    struct amd_iommu *iommu;
+
+    if ( !iommu_found() )
+    {
+        AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n"=
);
+        return;
+    }
+
+    /*
+     * No matter from where the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMUs).
+     */
+    for_each_amd_iommu ( iommu ) {
+        iommu_check_event_log(iommu);
+
+        if ( iommu->ppr_log.buffer !=3D NULL )
+            iommu_check_ppr_log(iommu);
+    }
+}
+
 static void iommu_interrupt_handler(int irq, void *dev_id,
                                     struct cpu_user_regs *regs)
 {
+    u32 entry;
+    unsigned long flags;
     struct amd_iommu *iommu =3D dev_id;
-    iommu_check_event_log(iommu);
=20
-    if ( iommu->ppr_log.buffer !=3D NULL )
-        iommu_check_ppr_log(iommu);
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    /* Silence interrupts from both event and PPR logging */
+    entry =3D readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
+    iommu_clear_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
+    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    /* It is the tasklet that will clear the logs and re-enable interrupts=
 */
+    tasklet_schedule(&amd_iommu_irq_tasklet);
 }
=20
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
@@ -876,6 +912,8 @@ static int __init amd_iommu_init_one(str
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
=20
+    softirq_tasklet_init(&amd_iommu_irq_tasklet, do_amd_iommu_irq, 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)


--=-ELDboK5eggB2H88FJXyb
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"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE1YWI2MTg2NWVjYmQxNDZmNmNlNjVmYmVh
NWJmNDliZmQ5YzZjYjENCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgQU1ELVZpLg0KICAgICAgICAgICAgICAgICAgDQpEZWFsaW5nIHdpdGggaW50ZXJydXB0cyBm
cm9tIEFNRC1WaSBJT01NVShzKSBpcyBkZWZlcnJlZCB0byBhIHNvZnRpcnEtdGFza2xldCwNCnJh
aXNlZCBieSB0aGUgYWN0dWFsIElSUSBoYW5kbGVyLiBUbyBhdm9pZCBtb3JlIGludGVycnVwdHMg
YmVpbmcgZ2VuZXJhdGVkDQooYmVjYXVzZSBvZiBmdXJ0aGVyIGZhdWx0cyksIHRoZXkgbXVzdCBi
ZSBtYXNrZWQgaW4gdGhlIElPTU1VIHdpdGhpbiB0aGUgbG93DQpsZXZlbCBJUlEgaGFuZGxlciBh
bmQgZW5hYmxlZCBiYWNrIGluIHRoZSB0YXNrbGV0IGJvZHkuIE5vdGljZSB0aGF0IHRoaXMgbWF5
DQpjYXVzZSB0aGUgbG9nIHRvIG92ZXJmbG93LCBidXQgbm9uZSBvZiB0aGUgZXhpc3RpbmcgZW50
cnkgd2lsbCBiZSBvdmVyd3JpdHRlbi4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xpQGNpdHJpeC5j
b20+DQoNCmRpZmYgLXIgMTVhYjYxODY1ZWNiIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9p
b21tdV9pbml0LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbml0
LmMJVHVlIEphbiAxNyAxMjo0MDo1MiAyMDEyICswMDAwDQorKysgYi94ZW4vZHJpdmVycy9wYXNz
dGhyb3VnaC9hbWQvaW9tbXVfaW5pdC5jCVdlZCBKYW4gMTggMTM6MDE6MjMgMjAxMiArMDEwMA0K
QEAgLTMyLDYgKzMyLDggQEANCiANCiBzdGF0aWMgaW50IF9faW5pdGRhdGEgbnJfYW1kX2lvbW11
czsNCiANCitzdGF0aWMgc3RydWN0IHRhc2tsZXQgYW1kX2lvbW11X2lycV90YXNrbGV0Ow0KKw0K
IHVuc2lnbmVkIHNob3J0IGl2cnNfYmRmX2VudHJpZXM7DQogc3RhdGljIHN0cnVjdCByYWRpeF90
cmVlX3Jvb3QgaXZyc19tYXBzOw0KIHN0cnVjdCBsaXN0X2hlYWQgYW1kX2lvbW11X2hlYWQ7DQpA
QCAtNjg5LDE0ICs2OTEsNDggQEAgc3RhdGljIHZvaWQgaW9tbXVfY2hlY2tfcHByX2xvZyhzdHJ1
Y3QgYQ0KICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpb21tdS0+bG9jaywgZmxhZ3MpOw0K
IH0NCiANCitzdGF0aWMgdm9pZCBkb19hbWRfaW9tbXVfaXJxKHVuc2lnbmVkIGxvbmcgZGF0YSkN
Cit7DQorICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11Ow0KKw0KKyAgICBpZiAoICFpb21tdV9m
b3VuZCgpICkNCisgICAgew0KKyAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJubyBkZXZpY2UgZm91
bmQsIHNvbWV0aGluZyBtdXN0IGJlIHZlcnkgd3JvbmchXG4iKTsNCisgICAgICAgIHJldHVybjsN
CisgICAgfQ0KKw0KKyAgICAvKg0KKyAgICAgKiBObyBtYXR0ZXIgZnJvbSB3aGVyZSB0aGUgaW50
ZXJydXB0IGNhbWUgZnJvbSwgY2hlY2sgYWxsIHRoZQ0KKyAgICAgKiBJT01NVXMgcHJlc2VudCBp
biB0aGUgc3lzdGVtLiBUaGlzIGFsbG93cyBmb3IgaGF2aW5nIGp1c3Qgb25lDQorICAgICAqIHRh
c2tsZXQgKGluc3RlYWQgb2Ygb25lIHBlciBlYWNoIElPTU1VcykuDQorICAgICAqLw0KKyAgICBm
b3JfZWFjaF9hbWRfaW9tbXUgKCBpb21tdSApIHsNCisgICAgICAgIGlvbW11X2NoZWNrX2V2ZW50
X2xvZyhpb21tdSk7DQorDQorICAgICAgICBpZiAoIGlvbW11LT5wcHJfbG9nLmJ1ZmZlciAhPSBO
VUxMICkNCisgICAgICAgICAgICBpb21tdV9jaGVja19wcHJfbG9nKGlvbW11KTsNCisgICAgfQ0K
K30NCisNCiBzdGF0aWMgdm9pZCBpb21tdV9pbnRlcnJ1cHRfaGFuZGxlcihpbnQgaXJxLCB2b2lk
ICpkZXZfaWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGNw
dV91c2VyX3JlZ3MgKnJlZ3MpDQogew0KKyAgICB1MzIgZW50cnk7DQorICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7DQogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11ID0gZGV2X2lkOw0KLSAgICBp
b21tdV9jaGVja19ldmVudF9sb2coaW9tbXUpOw0KIA0KLSAgICBpZiAoIGlvbW11LT5wcHJfbG9n
LmJ1ZmZlciAhPSBOVUxMICkNCi0gICAgICAgIGlvbW11X2NoZWNrX3Bwcl9sb2coaW9tbXUpOw0K
KyAgICBzcGluX2xvY2tfaXJxc2F2ZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCisNCisgICAgLyog
U2lsZW5jZSBpbnRlcnJ1cHRzIGZyb20gYm90aCBldmVudCBhbmQgUFBSIGxvZ2dpbmcgKi8NCisg
ICAgZW50cnkgPSByZWFkbChpb21tdS0+bW1pb19iYXNlICsgSU9NTVVfU1RBVFVTX01NSU9fT0ZG
U0VUKTsNCisgICAgaW9tbXVfY2xlYXJfYml0KCZlbnRyeSwgSU9NTVVfU1RBVFVTX0VWRU5UX0xP
R19JTlRfU0hJRlQpOw0KKyAgICBpb21tdV9jbGVhcl9iaXQoJmVudHJ5LCBJT01NVV9TVEFUVVNf
UFBSX0xPR19JTlRfU0hJRlQpOw0KKyAgICB3cml0ZWwoZW50cnksIGlvbW11LT5tbWlvX2Jhc2Ur
SU9NTVVfU1RBVFVTX01NSU9fT0ZGU0VUKTsNCisNCisgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9y
ZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCisNCisgICAgLyogSXQgaXMgdGhlIHRhc2tsZXQgdGhh
dCB3aWxsIGNsZWFyIHRoZSBsb2dzIGFuZCByZS1lbmFibGUgaW50ZXJydXB0cyAqLw0KKyAgICB0
YXNrbGV0X3NjaGVkdWxlKCZhbWRfaW9tbXVfaXJxX3Rhc2tsZXQpOw0KIH0NCiANCiBzdGF0aWMg
aW50IF9faW5pdCBzZXRfaW9tbXVfaW50ZXJydXB0X2hhbmRsZXIoc3RydWN0IGFtZF9pb21tdSAq
aW9tbXUpDQpAQCAtODc2LDYgKzkxMiw4IEBAIHN0YXRpYyBpbnQgX19pbml0IGFtZF9pb21tdV9p
bml0X29uZShzdHINCiAgICAgcHJpbnRrKCJBTUQtVmk6IElPTU1VICVkIEVuYWJsZWQuXG4iLCBu
cl9hbWRfaW9tbXVzICk7DQogICAgIG5yX2FtZF9pb21tdXMrKzsNCiANCisgICAgc29mdGlycV90
YXNrbGV0X2luaXQoJmFtZF9pb21tdV9pcnFfdGFza2xldCwgZG9fYW1kX2lvbW11X2lycSwgMCk7
DQorDQogICAgIHJldHVybiAwOw0KIA0KIGVycm9yX291dDoNCg==


--=-ELDboK5eggB2H88FJXyb--

--=-6qpda0J42k3/VqT79iK9
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)

iEYEABECAAYFAk8W66UACgkQk4XaBE3IOsRMuwCaAyeXyLeQRO8an7HK+x3DdnQ7
c+sAnia136T0udjxhbientXncQahUARL
=bvqO
-----END PGP SIGNATURE-----

--=-6qpda0J42k3/VqT79iK9--



--===============5030118704337303872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5030118704337303872==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 15:57:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:57:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXse-0003nJ-8e; Wed, 18 Jan 2012 15:56:56 +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 1RnXsc-0003n8-Bn
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:56:54 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326902207!12932595!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 22615 invoked from network); 18 Jan 2012 15:56:47 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-2.tower-216.messagelabs.com with SMTP;
	18 Jan 2012 15:56:47 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74599257; Wed, 18 Jan 2012 16:56:46 +0100
Message-ID: <1326902181.5856.19.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Keir Fraser <keir@xen.org>
Date: Wed, 18 Jan 2012 16:56:21 +0100
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"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: [Xen-devel] [PATCHv3] 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="===============5030118704337303872=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5030118704337303872==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-6qpda0J42k3/VqT79iK9"


--=-6qpda0J42k3/VqT79iK9
Content-Type: multipart/mixed; boundary="=-ELDboK5eggB2H88FJXyb"


--=-ELDboK5eggB2H88FJXyb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dealing with interrupts from AMD-Vi IOMMU(s) is deferred to a softirq-taskl=
et,
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 lo=
w
level IRQ handler and enabled back in the tasklet body. Notice that this ma=
y
cause the log to overflow, but none of the existing entry will be overwritt=
en.
                                =20
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 15ab61865ecb xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 17 12:40:52 2012 +00=
00
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Wed Jan 18 13:01:23 2012 +01=
00
@@ -32,6 +32,8 @@
=20
 static int __initdata nr_amd_iommus;
=20
+static struct tasklet amd_iommu_irq_tasklet;
+
 unsigned short ivrs_bdf_entries;
 static struct radix_tree_root ivrs_maps;
 struct list_head amd_iommu_head;
@@ -689,14 +691,48 @@ static void iommu_check_ppr_log(struct a
     spin_unlock_irqrestore(&iommu->lock, flags);
 }
=20
+static void do_amd_iommu_irq(unsigned long data)
+{
+    struct amd_iommu *iommu;
+
+    if ( !iommu_found() )
+    {
+        AMD_IOMMU_DEBUG("no device found, something must be very wrong!\n"=
);
+        return;
+    }
+
+    /*
+     * No matter from where the interrupt came from, check all the
+     * IOMMUs present in the system. This allows for having just one
+     * tasklet (instead of one per each IOMMUs).
+     */
+    for_each_amd_iommu ( iommu ) {
+        iommu_check_event_log(iommu);
+
+        if ( iommu->ppr_log.buffer !=3D NULL )
+            iommu_check_ppr_log(iommu);
+    }
+}
+
 static void iommu_interrupt_handler(int irq, void *dev_id,
                                     struct cpu_user_regs *regs)
 {
+    u32 entry;
+    unsigned long flags;
     struct amd_iommu *iommu =3D dev_id;
-    iommu_check_event_log(iommu);
=20
-    if ( iommu->ppr_log.buffer !=3D NULL )
-        iommu_check_ppr_log(iommu);
+    spin_lock_irqsave(&iommu->lock, flags);
+
+    /* Silence interrupts from both event and PPR logging */
+    entry =3D readl(iommu->mmio_base + IOMMU_STATUS_MMIO_OFFSET);
+    iommu_clear_bit(&entry, IOMMU_STATUS_EVENT_LOG_INT_SHIFT);
+    iommu_clear_bit(&entry, IOMMU_STATUS_PPR_LOG_INT_SHIFT);
+    writel(entry, iommu->mmio_base+IOMMU_STATUS_MMIO_OFFSET);
+
+    spin_unlock_irqrestore(&iommu->lock, flags);
+
+    /* It is the tasklet that will clear the logs and re-enable interrupts=
 */
+    tasklet_schedule(&amd_iommu_irq_tasklet);
 }
=20
 static int __init set_iommu_interrupt_handler(struct amd_iommu *iommu)
@@ -876,6 +912,8 @@ static int __init amd_iommu_init_one(str
     printk("AMD-Vi: IOMMU %d Enabled.\n", nr_amd_iommus );
     nr_amd_iommus++;
=20
+    softirq_tasklet_init(&amd_iommu_irq_tasklet, do_amd_iommu_irq, 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)


--=-ELDboK5eggB2H88FJXyb
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"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE1YWI2MTg2NWVjYmQxNDZmNmNlNjVmYmVh
NWJmNDliZmQ5YzZjYjENCk1vdmUgSU9NTVUgZmF1bHRzIGhhbmRsaW5nIGludG8gc29mdGlycSBm
b3IgQU1ELVZpLg0KICAgICAgICAgICAgICAgICAgDQpEZWFsaW5nIHdpdGggaW50ZXJydXB0cyBm
cm9tIEFNRC1WaSBJT01NVShzKSBpcyBkZWZlcnJlZCB0byBhIHNvZnRpcnEtdGFza2xldCwNCnJh
aXNlZCBieSB0aGUgYWN0dWFsIElSUSBoYW5kbGVyLiBUbyBhdm9pZCBtb3JlIGludGVycnVwdHMg
YmVpbmcgZ2VuZXJhdGVkDQooYmVjYXVzZSBvZiBmdXJ0aGVyIGZhdWx0cyksIHRoZXkgbXVzdCBi
ZSBtYXNrZWQgaW4gdGhlIElPTU1VIHdpdGhpbiB0aGUgbG93DQpsZXZlbCBJUlEgaGFuZGxlciBh
bmQgZW5hYmxlZCBiYWNrIGluIHRoZSB0YXNrbGV0IGJvZHkuIE5vdGljZSB0aGF0IHRoaXMgbWF5
DQpjYXVzZSB0aGUgbG9nIHRvIG92ZXJmbG93LCBidXQgbm9uZSBvZiB0aGUgZXhpc3RpbmcgZW50
cnkgd2lsbCBiZSBvdmVyd3JpdHRlbi4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZhZ2dpb2xpQGNpdHJpeC5j
b20+DQoNCmRpZmYgLXIgMTVhYjYxODY1ZWNiIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9p
b21tdV9pbml0LmMNCi0tLSBhL3hlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL2FtZC9pb21tdV9pbml0
LmMJVHVlIEphbiAxNyAxMjo0MDo1MiAyMDEyICswMDAwDQorKysgYi94ZW4vZHJpdmVycy9wYXNz
dGhyb3VnaC9hbWQvaW9tbXVfaW5pdC5jCVdlZCBKYW4gMTggMTM6MDE6MjMgMjAxMiArMDEwMA0K
QEAgLTMyLDYgKzMyLDggQEANCiANCiBzdGF0aWMgaW50IF9faW5pdGRhdGEgbnJfYW1kX2lvbW11
czsNCiANCitzdGF0aWMgc3RydWN0IHRhc2tsZXQgYW1kX2lvbW11X2lycV90YXNrbGV0Ow0KKw0K
IHVuc2lnbmVkIHNob3J0IGl2cnNfYmRmX2VudHJpZXM7DQogc3RhdGljIHN0cnVjdCByYWRpeF90
cmVlX3Jvb3QgaXZyc19tYXBzOw0KIHN0cnVjdCBsaXN0X2hlYWQgYW1kX2lvbW11X2hlYWQ7DQpA
QCAtNjg5LDE0ICs2OTEsNDggQEAgc3RhdGljIHZvaWQgaW9tbXVfY2hlY2tfcHByX2xvZyhzdHJ1
Y3QgYQ0KICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZpb21tdS0+bG9jaywgZmxhZ3MpOw0K
IH0NCiANCitzdGF0aWMgdm9pZCBkb19hbWRfaW9tbXVfaXJxKHVuc2lnbmVkIGxvbmcgZGF0YSkN
Cit7DQorICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11Ow0KKw0KKyAgICBpZiAoICFpb21tdV9m
b3VuZCgpICkNCisgICAgew0KKyAgICAgICAgQU1EX0lPTU1VX0RFQlVHKCJubyBkZXZpY2UgZm91
bmQsIHNvbWV0aGluZyBtdXN0IGJlIHZlcnkgd3JvbmchXG4iKTsNCisgICAgICAgIHJldHVybjsN
CisgICAgfQ0KKw0KKyAgICAvKg0KKyAgICAgKiBObyBtYXR0ZXIgZnJvbSB3aGVyZSB0aGUgaW50
ZXJydXB0IGNhbWUgZnJvbSwgY2hlY2sgYWxsIHRoZQ0KKyAgICAgKiBJT01NVXMgcHJlc2VudCBp
biB0aGUgc3lzdGVtLiBUaGlzIGFsbG93cyBmb3IgaGF2aW5nIGp1c3Qgb25lDQorICAgICAqIHRh
c2tsZXQgKGluc3RlYWQgb2Ygb25lIHBlciBlYWNoIElPTU1VcykuDQorICAgICAqLw0KKyAgICBm
b3JfZWFjaF9hbWRfaW9tbXUgKCBpb21tdSApIHsNCisgICAgICAgIGlvbW11X2NoZWNrX2V2ZW50
X2xvZyhpb21tdSk7DQorDQorICAgICAgICBpZiAoIGlvbW11LT5wcHJfbG9nLmJ1ZmZlciAhPSBO
VUxMICkNCisgICAgICAgICAgICBpb21tdV9jaGVja19wcHJfbG9nKGlvbW11KTsNCisgICAgfQ0K
K30NCisNCiBzdGF0aWMgdm9pZCBpb21tdV9pbnRlcnJ1cHRfaGFuZGxlcihpbnQgaXJxLCB2b2lk
ICpkZXZfaWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RydWN0IGNw
dV91c2VyX3JlZ3MgKnJlZ3MpDQogew0KKyAgICB1MzIgZW50cnk7DQorICAgIHVuc2lnbmVkIGxv
bmcgZmxhZ3M7DQogICAgIHN0cnVjdCBhbWRfaW9tbXUgKmlvbW11ID0gZGV2X2lkOw0KLSAgICBp
b21tdV9jaGVja19ldmVudF9sb2coaW9tbXUpOw0KIA0KLSAgICBpZiAoIGlvbW11LT5wcHJfbG9n
LmJ1ZmZlciAhPSBOVUxMICkNCi0gICAgICAgIGlvbW11X2NoZWNrX3Bwcl9sb2coaW9tbXUpOw0K
KyAgICBzcGluX2xvY2tfaXJxc2F2ZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCisNCisgICAgLyog
U2lsZW5jZSBpbnRlcnJ1cHRzIGZyb20gYm90aCBldmVudCBhbmQgUFBSIGxvZ2dpbmcgKi8NCisg
ICAgZW50cnkgPSByZWFkbChpb21tdS0+bW1pb19iYXNlICsgSU9NTVVfU1RBVFVTX01NSU9fT0ZG
U0VUKTsNCisgICAgaW9tbXVfY2xlYXJfYml0KCZlbnRyeSwgSU9NTVVfU1RBVFVTX0VWRU5UX0xP
R19JTlRfU0hJRlQpOw0KKyAgICBpb21tdV9jbGVhcl9iaXQoJmVudHJ5LCBJT01NVV9TVEFUVVNf
UFBSX0xPR19JTlRfU0hJRlQpOw0KKyAgICB3cml0ZWwoZW50cnksIGlvbW11LT5tbWlvX2Jhc2Ur
SU9NTVVfU1RBVFVTX01NSU9fT0ZGU0VUKTsNCisNCisgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9y
ZSgmaW9tbXUtPmxvY2ssIGZsYWdzKTsNCisNCisgICAgLyogSXQgaXMgdGhlIHRhc2tsZXQgdGhh
dCB3aWxsIGNsZWFyIHRoZSBsb2dzIGFuZCByZS1lbmFibGUgaW50ZXJydXB0cyAqLw0KKyAgICB0
YXNrbGV0X3NjaGVkdWxlKCZhbWRfaW9tbXVfaXJxX3Rhc2tsZXQpOw0KIH0NCiANCiBzdGF0aWMg
aW50IF9faW5pdCBzZXRfaW9tbXVfaW50ZXJydXB0X2hhbmRsZXIoc3RydWN0IGFtZF9pb21tdSAq
aW9tbXUpDQpAQCAtODc2LDYgKzkxMiw4IEBAIHN0YXRpYyBpbnQgX19pbml0IGFtZF9pb21tdV9p
bml0X29uZShzdHINCiAgICAgcHJpbnRrKCJBTUQtVmk6IElPTU1VICVkIEVuYWJsZWQuXG4iLCBu
cl9hbWRfaW9tbXVzICk7DQogICAgIG5yX2FtZF9pb21tdXMrKzsNCiANCisgICAgc29mdGlycV90
YXNrbGV0X2luaXQoJmFtZF9pb21tdV9pcnFfdGFza2xldCwgZG9fYW1kX2lvbW11X2lycSwgMCk7
DQorDQogICAgIHJldHVybiAwOw0KIA0KIGVycm9yX291dDoNCg==


--=-ELDboK5eggB2H88FJXyb--

--=-6qpda0J42k3/VqT79iK9
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)

iEYEABECAAYFAk8W66UACgkQk4XaBE3IOsRMuwCaAyeXyLeQRO8an7HK+x3DdnQ7
c+sAnia136T0udjxhbientXncQahUARL
=bvqO
-----END PGP SIGNATURE-----

--=-6qpda0J42k3/VqT79iK9--



--===============5030118704337303872==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5030118704337303872==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 15:58:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXtU-0003r8-Sz; Wed, 18 Jan 2012 15:57:48 +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 1RnXtS-0003qT-PR
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:57:47 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326902260!9698887!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=2.1 required=7.0 tests=UNIQUE_WORDS
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31094 invoked from network); 18 Jan 2012 15:57:40 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 15:57:40 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74599284; Wed, 18 Jan 2012 16:57:40 +0100
Message-ID: <1326902236.5856.20.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Wei Wang <wei.wang2@amd.com>
Date: Wed, 18 Jan 2012 16:57:16 +0100
In-Reply-To: <4F16EAEC.5090102@amd.com>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
	<4F16A186.4080303@amd.com> <1326894667.5856.17.camel@Solace>
	<4F16EAEC.5090102@amd.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCHv3] 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="===============7700302729500167692=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7700302729500167692==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-zJUOIpJvqR4T1jp5jx26"


--=-zJUOIpJvqR4T1jp5jx26
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-18 at 16:53 +0100, Wei Wang wrote:
> Hi,
> It works on my machine with PPR log enabled.
>
Ok then, patch resent in a separate thread right now.

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)


--=-zJUOIpJvqR4T1jp5jx26
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)

iEYEABECAAYFAk8W69wACgkQk4XaBE3IOsTgMACfUO+XG+wjIBwNlBdGK92fvgbD
yz4AnA9UAZpd9fZeU7KusaPzcUYeU7F7
=svvP
-----END PGP SIGNATURE-----

--=-zJUOIpJvqR4T1jp5jx26--



--===============7700302729500167692==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7700302729500167692==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 15:58:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 15:58:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnXtU-0003r8-Sz; Wed, 18 Jan 2012 15:57:48 +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 1RnXtS-0003qT-PR
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 15:57:47 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326902260!9698887!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=2.1 required=7.0 tests=UNIQUE_WORDS
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31094 invoked from network); 18 Jan 2012 15:57:40 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 15:57:40 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74599284; Wed, 18 Jan 2012 16:57:40 +0100
Message-ID: <1326902236.5856.20.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Wei Wang <wei.wang2@amd.com>
Date: Wed, 18 Jan 2012 16:57:16 +0100
In-Reply-To: <4F16EAEC.5090102@amd.com>
References: <CB3B094F.379B1%keir@xen.org> <1326876800.2375.18.camel@Abyss>
	<4F16A186.4080303@amd.com> <1326894667.5856.17.camel@Solace>
	<4F16EAEC.5090102@amd.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: Tim Deegan <tim@xen.org>, "allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCHv3] 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="===============7700302729500167692=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7700302729500167692==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-zJUOIpJvqR4T1jp5jx26"


--=-zJUOIpJvqR4T1jp5jx26
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-18 at 16:53 +0100, Wei Wang wrote:
> Hi,
> It works on my machine with PPR log enabled.
>
Ok then, patch resent in a separate thread right now.

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)


--=-zJUOIpJvqR4T1jp5jx26
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)

iEYEABECAAYFAk8W69wACgkQk4XaBE3IOsTgMACfUO+XG+wjIBwNlBdGK92fvgbD
yz4AnA9UAZpd9fZeU7KusaPzcUYeU7F7
=svvP
-----END PGP SIGNATURE-----

--=-zJUOIpJvqR4T1jp5jx26--



--===============7700302729500167692==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7700302729500167692==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:07:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnY29-0004Xb-UM; Wed, 18 Jan 2012 16:06:45 +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 1RnY28-0004XW-FV
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:06:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326902795!11381462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28234 invoked from network); 18 Jan 2012 16:06:36 -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;
	18 Jan 2012 16:06:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10120279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 16:06: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, 18 Jan 2012 16:06:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 16:06:34 +0000
In-Reply-To: <4F16DD96.6080304@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1326882968.14689.176.camel@zakaz.uk.xensource.com>
	<4F16DD96.6080304@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326902794.14689.243.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On Wed, 2012-01-18 at 14:56 +0000, Daniel De Graaf wrote:
> On 01/18/2012 05:36 AM, Ian Campbell wrote:
> > On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> >> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >>
> >> This patch reinstates the XENMEM_remove_from_physmap hypercall
> >> which was removed in 19041:ee62aaafff46 because it was not used.
> >>
> >> However, is now needed in order to support xenstored stub domains.
> >> The xenstored stub domain is not priviliged like dom0 and so cannot
> >> unilaterally map the xenbus page of other guests into it's address
> >> space.  Therefore, before creating a domU the domain builder needs to
> >> seed its grant table with a grant ref allowing the xenstored stub
> >> domain to access the new domU's xenbus page.
> >>
> >> At present domU's do not start with their grant table mapped.
> >> Instead it gets mapped when the guest requests a grant table from
> >> the hypervisor.
> >>
> >> In order to seed the grant table, the domain builder first needs to
> >> map it into dom0 address space.  But the hypercall to do this
> >> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
> >> for HVM guests.  Therfore, in order to seed the grant table of an
> >> HVM guest, dom0 needs to *temporarily* map it into the guest's
> >> "physical" address space.
> >>
> >> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
> >>
> >> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
> > about ordering in xlat.lst)
> > 
> > BTW, since Alex and Diego have subsequently left Citrix you could take
> > my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
> > no idea if that's necessary though, I expect not.
> > 
> > Ian.
> > 
> 
> I'm not an expert in this area,

Me neither.

> but this is how I read it: the portion of
> the path authored by Alex/Diego was already signed-off when they were posted,
> so since the current patches are derived works from them the sign-off may
> need to stay in order to allow me to sign off because I cannot claim copyright
> on all of the content. Assuming Citrix actually owns the copyright on the
> patches, your Ack may suffice to replace the sign-off for this purpose.

I don't think an Ack conveys the same meaning (WRT the DCO) as a
Signed-off-by.

> I guess my real question here would be: should the sign-off from Alex and
> Diego remain on these patches in addition to your Ack?

I would suggest you keep any signed-off-by they provided and augment it
with my ack. 

I think I saw one or two which said "Originally-by" instead of
"Signed-of-by", I guess those were either missing a Signed-off-by in the
first place or have been heavily modified?

Ian.

> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:07:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnY29-0004Xb-UM; Wed, 18 Jan 2012 16:06:45 +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 1RnY28-0004XW-FV
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:06:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1326902795!11381462!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28234 invoked from network); 18 Jan 2012 16:06:36 -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;
	18 Jan 2012 16:06:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10120279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 16:06: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, 18 Jan 2012 16:06:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 16:06:34 +0000
In-Reply-To: <4F16DD96.6080304@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1326882968.14689.176.camel@zakaz.uk.xensource.com>
	<4F16DD96.6080304@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326902794.14689.243.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On Wed, 2012-01-18 at 14:56 +0000, Daniel De Graaf wrote:
> On 01/18/2012 05:36 AM, Ian Campbell wrote:
> > On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> >> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >>
> >> This patch reinstates the XENMEM_remove_from_physmap hypercall
> >> which was removed in 19041:ee62aaafff46 because it was not used.
> >>
> >> However, is now needed in order to support xenstored stub domains.
> >> The xenstored stub domain is not priviliged like dom0 and so cannot
> >> unilaterally map the xenbus page of other guests into it's address
> >> space.  Therefore, before creating a domU the domain builder needs to
> >> seed its grant table with a grant ref allowing the xenstored stub
> >> domain to access the new domU's xenbus page.
> >>
> >> At present domU's do not start with their grant table mapped.
> >> Instead it gets mapped when the guest requests a grant table from
> >> the hypervisor.
> >>
> >> In order to seed the grant table, the domain builder first needs to
> >> map it into dom0 address space.  But the hypercall to do this
> >> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
> >> for HVM guests.  Therfore, in order to seed the grant table of an
> >> HVM guest, dom0 needs to *temporarily* map it into the guest's
> >> "physical" address space.
> >>
> >> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
> >>
> >> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
> > about ordering in xlat.lst)
> > 
> > BTW, since Alex and Diego have subsequently left Citrix you could take
> > my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
> > no idea if that's necessary though, I expect not.
> > 
> > Ian.
> > 
> 
> I'm not an expert in this area,

Me neither.

> but this is how I read it: the portion of
> the path authored by Alex/Diego was already signed-off when they were posted,
> so since the current patches are derived works from them the sign-off may
> need to stay in order to allow me to sign off because I cannot claim copyright
> on all of the content. Assuming Citrix actually owns the copyright on the
> patches, your Ack may suffice to replace the sign-off for this purpose.

I don't think an Ack conveys the same meaning (WRT the DCO) as a
Signed-off-by.

> I guess my real question here would be: should the sign-off from Alex and
> Diego remain on these patches in addition to your Ack?

I would suggest you keep any signed-off-by they provided and augment it
with my ack. 

I think I saw one or two which said "Originally-by" instead of
"Signed-of-by", I guess those were either missing a Signed-off-by in the
first place or have been heavily modified?

Ian.

> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:14:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnY9M-0004tM-I5; Wed, 18 Jan 2012 16:14:12 +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 1RnY9L-0004sq-RX
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:14:12 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326903245!1597248!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 30004 invoked from network); 18 Jan 2012 16:14:05 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 16:14:05 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74599744; Wed, 18 Jan 2012 17:14:05 +0100
Message-ID: <1326903221.5856.33.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 18 Jan 2012 17:13:41 +0100
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 1] sched: rework locking for dump debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0388910624415426256=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0388910624415426256==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-QkZ/eKx2YFFGqeRxRBoZ"


--=-QkZ/eKx2YFFGqeRxRBoZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi George, everyone,

I noticed this issue while going through the scheduling code. Basically,
for the runq debugkey, locking happens in schedule.c (which we usually
don't want) and doesn't seem take credit2's runqs<-->CPUs mapping into
account.


I think this patch correctly deals with locking in this specific case,
but of course I'm happy to hear what you think! :-)
I tested the patch with all schedulers, but as you can imagine it's
quite hard to produce an actual race and see if it is being handled
properly...

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)


--=-QkZ/eKx2YFFGqeRxRBoZ
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)

iEYEABECAAYFAk8W77UACgkQk4XaBE3IOsRgSACfROQyGElqK48ZprLZhFveEuEy
bXsAoJGMcBMUd6pxJRPLDHbaX4qLimrN
=NT3q
-----END PGP SIGNATURE-----

--=-QkZ/eKx2YFFGqeRxRBoZ--



--===============0388910624415426256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0388910624415426256==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:14:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnY9M-0004tM-I5; Wed, 18 Jan 2012 16:14:12 +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 1RnY9L-0004sq-RX
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:14:12 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326903245!1597248!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 30004 invoked from network); 18 Jan 2012 16:14:05 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 16:14:05 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74599744; Wed, 18 Jan 2012 17:14:05 +0100
Message-ID: <1326903221.5856.33.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 18 Jan 2012 17:13:41 +0100
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: [Xen-devel] [PATCH 0 of 1] sched: rework locking for dump debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0388910624415426256=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0388910624415426256==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-QkZ/eKx2YFFGqeRxRBoZ"


--=-QkZ/eKx2YFFGqeRxRBoZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi George, everyone,

I noticed this issue while going through the scheduling code. Basically,
for the runq debugkey, locking happens in schedule.c (which we usually
don't want) and doesn't seem take credit2's runqs<-->CPUs mapping into
account.


I think this patch correctly deals with locking in this specific case,
but of course I'm happy to hear what you think! :-)
I tested the patch with all schedulers, but as you can imagine it's
quite hard to produce an actual race and see if it is being handled
properly...

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)


--=-QkZ/eKx2YFFGqeRxRBoZ
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)

iEYEABECAAYFAk8W77UACgkQk4XaBE3IOsRgSACfROQyGElqK48ZprLZhFveEuEy
bXsAoJGMcBMUd6pxJRPLDHbaX4qLimrN
=NT3q
-----END PGP SIGNATURE-----

--=-QkZ/eKx2YFFGqeRxRBoZ--



--===============0388910624415426256==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0388910624415426256==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:18:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnYCr-000570-6s; Wed, 18 Jan 2012 16:17:49 +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 1RnYCq-00056j-5D
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:17:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326903461!11459857!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 8519 invoked from network); 18 Jan 2012 16:17:41 -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; 18 Jan 2012 16:17:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 16:17:41 +0000
Message-Id: <4F16FEB2020000780006D812@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 16:17:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH] linux-2.6.18/gntdev: remove bogus and broken
 try_module_get()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Its return value wasn't checked, it wasn't undone in the error path,
and it was redundnant (the caller being responsible for doing this).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/gntdev/gntdev.c
+++ b/drivers/xen/gntdev/gntdev.c
@@ -427,8 +427,6 @@ static int gntdev_open(struct inode *ino
 {
 	gntdev_file_private_data_t *private_data;
 
-	try_module_get(THIS_MODULE);
-
 	/* Allocate space for the per-instance private data. */
 	private_data = kmalloc(sizeof(*private_data), GFP_KERNEL);
 	if (!private_data)
@@ -467,7 +465,6 @@ static int gntdev_release(struct inode *
 			kfree(private_data->free_list);
 		kfree(private_data);
 	}
-	module_put(THIS_MODULE);
 	return 0;
 }
 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:18:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnYCr-000570-6s; Wed, 18 Jan 2012 16:17:49 +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 1RnYCq-00056j-5D
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:17:48 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1326903461!11459857!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 8519 invoked from network); 18 Jan 2012 16:17:41 -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; 18 Jan 2012 16:17:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 16:17:41 +0000
Message-Id: <4F16FEB2020000780006D812@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 16:17:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Subject: [Xen-devel] [PATCH] linux-2.6.18/gntdev: remove bogus and broken
 try_module_get()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Its return value wasn't checked, it wasn't undone in the error path,
and it was redundnant (the caller being responsible for doing this).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/gntdev/gntdev.c
+++ b/drivers/xen/gntdev/gntdev.c
@@ -427,8 +427,6 @@ static int gntdev_open(struct inode *ino
 {
 	gntdev_file_private_data_t *private_data;
 
-	try_module_get(THIS_MODULE);
-
 	/* Allocate space for the per-instance private data. */
 	private_data = kmalloc(sizeof(*private_data), GFP_KERNEL);
 	if (!private_data)
@@ -467,7 +465,6 @@ static int gntdev_release(struct inode *
 			kfree(private_data->free_list);
 		kfree(private_data);
 	}
-	module_put(THIS_MODULE);
 	return 0;
 }
 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:22:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnYGk-0005ch-SC; Wed, 18 Jan 2012 16:21:50 +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 1RnYGi-0005cC-Rk
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:21:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326903702!9636345!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI3ODE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI3ODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20821 invoked from network); 18 Jan 2012 16:21:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 18 Jan 2012 16:21:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326903702; l=823;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=qum0xXWjQ0v0iDef1QxCDrIXfO8=;
	b=b0pkb8OuhdC5eJSVBw6ErAH/wWuOtPvtclaoFahRgcGLOzvcNtC4bRXMtRxOESZIbCt
	xRb5K+pB4Yyvjo3tVLaZakxufVvjmZPGRaiM055+lSds+GvmlEMUAXjri7zhHjIw/nPZu
	WUAe8bBodPGakWuMWyAv/LwRiHbqrD9V5Pw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0MF3Z/
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-248.pools.arcor-ip.net [88.65.73.248])
	by smtp.strato.de (klopstock mo46) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id D00788o0IGF6Kl
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 17:21:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3EE9818637; Wed, 18 Jan 2012 17:21:23 +0100 (CET)
Date: Wed, 18 Jan 2012 17:21:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120118162122.GA14232@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] ioctl handling in netbsd_privcmd_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


I was looking at the slightly broken error handling in the new
xc_mem_paging_load() function and stumbled over the ioctl() handling in
netbsd_privcmd_hypercall().

Is ioctl() on NetBSD special? I would have expected it returns -1 on
error and the caller can deal with errno if it actually wants to.
But instead it returns the negative errno value or what the hypervisor
returned.

static int netbsd_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h, privcmd_hypercall_t *hypercall)
{   
    int fd = (int)h;
    int error = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);

    if (error < 0)
        return -errno;
    else
        return hypercall->retval;
}

I think do_domctl() is supposed to return -1 on error and let the caller
decide what to do. At least thats how its appearently done on Linux and
Solaris.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:22:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnYGk-0005ch-SC; Wed, 18 Jan 2012 16:21:50 +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 1RnYGi-0005cC-Rk
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:21:49 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326903702!9636345!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI3ODE=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzNTI3ODE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20821 invoked from network); 18 Jan 2012 16:21:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 18 Jan 2012 16:21:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326903702; l=823;
	s=domk; d=aepfle.de;
	h=Content-Type:MIME-Version:Subject:To:From:Date:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=qum0xXWjQ0v0iDef1QxCDrIXfO8=;
	b=b0pkb8OuhdC5eJSVBw6ErAH/wWuOtPvtclaoFahRgcGLOzvcNtC4bRXMtRxOESZIbCt
	xRb5K+pB4Yyvjo3tVLaZakxufVvjmZPGRaiM055+lSds+GvmlEMUAXjri7zhHjIw/nPZu
	WUAe8bBodPGakWuMWyAv/LwRiHbqrD9V5Pw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0MF3Z/
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-248.pools.arcor-ip.net [88.65.73.248])
	by smtp.strato.de (klopstock mo46) (RZmta 27.4 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id D00788o0IGF6Kl
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 17:21:25 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3EE9818637; Wed, 18 Jan 2012 17:21:23 +0100 (CET)
Date: Wed, 18 Jan 2012 17:21:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Message-ID: <20120118162122.GA14232@aepfle.de>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Subject: [Xen-devel] ioctl handling in netbsd_privcmd_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


I was looking at the slightly broken error handling in the new
xc_mem_paging_load() function and stumbled over the ioctl() handling in
netbsd_privcmd_hypercall().

Is ioctl() on NetBSD special? I would have expected it returns -1 on
error and the caller can deal with errno if it actually wants to.
But instead it returns the negative errno value or what the hypervisor
returned.

static int netbsd_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h, privcmd_hypercall_t *hypercall)
{   
    int fd = (int)h;
    int error = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);

    if (error < 0)
        return -errno;
    else
        return hypercall->retval;
}

I think do_domctl() is supposed to return -1 on error and let the caller
decide what to do. At least thats how its appearently done on Linux and
Solaris.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:22:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYHH-0005f3-9k; Wed, 18 Jan 2012 16:22:23 +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 1RnYHF-0005eV-CW
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:22:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326903717!62998370!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 24448 invoked from network); 18 Jan 2012 16:21:57 -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; 18 Jan 2012 16:21:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 16:22:16 +0000
Message-Id: <4F16FFC5020000780006D81B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 16:22:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <raistlin@linux.it>
References: <1326903221.5856.33.camel@Solace>
In-Reply-To: <1326903221.5856.33.camel@Solace>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 1] sched: rework locking for dump
 debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 17:13, Dario Faggioli <raistlin@linux.it> wrote:
> Hi George, everyone,
> 
> I noticed this issue while going through the scheduling code. Basically,
> for the runq debugkey, locking happens in schedule.c (which we usually
> don't want) and doesn't seem take credit2's runqs<-->CPUs mapping into
> account.
> 
> 
> I think this patch correctly deals with locking in this specific case,
> but of course I'm happy to hear what you think! :-)

Forgot to include/attach the patch?

> I tested the patch with all schedulers, but as you can imagine it's
> quite hard to produce an actual race and see if it is being handled
> properly...
> 
> 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 (Italy)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:22:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYHH-0005f3-9k; Wed, 18 Jan 2012 16:22:23 +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 1RnYHF-0005eV-CW
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:22:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326903717!62998370!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 24448 invoked from network); 18 Jan 2012 16:21:57 -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; 18 Jan 2012 16:21:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 16:22:16 +0000
Message-Id: <4F16FFC5020000780006D81B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 16:22:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dario Faggioli" <raistlin@linux.it>
References: <1326903221.5856.33.camel@Solace>
In-Reply-To: <1326903221.5856.33.camel@Solace>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 1] sched: rework locking for dump
 debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 17:13, Dario Faggioli <raistlin@linux.it> wrote:
> Hi George, everyone,
> 
> I noticed this issue while going through the scheduling code. Basically,
> for the runq debugkey, locking happens in schedule.c (which we usually
> don't want) and doesn't seem take credit2's runqs<-->CPUs mapping into
> account.
> 
> 
> I think this patch correctly deals with locking in this specific case,
> but of course I'm happy to hear what you think! :-)

Forgot to include/attach the patch?

> I tested the patch with all schedulers, but as you can imagine it's
> quite hard to produce an actual race and see if it is being handled
> properly...
> 
> 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 (Italy)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:26:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16:26:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYKH-0005tk-Tg; Wed, 18 Jan 2012 16:25:29 +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 1RnYKG-0005tB-2z
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:25:28 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326903920!9522868!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 28536 invoked from network); 18 Jan 2012 16:25:20 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 16:25:20 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74599980; Wed, 18 Jan 2012 17:25:19 +0100
Message-ID: <1326903894.5856.35.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 18 Jan 2012 17:24:54 +0100
In-Reply-To: <1326903221.5856.33.camel@Solace>
References: <1326903221.5856.33.camel@Solace>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 1] sched: rework locking for dump debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6363075103574912662=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6363075103574912662==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ApW/FEYJ2HeKXZmm9mdH"


--=-ApW/FEYJ2HeKXZmm9mdH
Content-Type: multipart/mixed; boundary="=-Sn+NDJR3EWzB5LTDsO7k"


--=-Sn+NDJR3EWzB5LTDsO7k
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As in all other paths, locking should be dealt with in the
specific schedulers, not in schedule.c.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 15ab61865ecb xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/common/sched_credit.c	Wed Jan 18 15:02:30 2012 +0000
@@ -1451,11 +1451,16 @@ static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
     struct list_head *runq, *iter;
+    struct csched_private *prv =3D CSCHED_PRIV(ops);
     struct csched_pcpu *spc;
     struct csched_vcpu *svc;
+    unsigned long flags;
     int loop;
 #define cpustr keyhandler_scratch
=20
+    /* Domains' parameters are changed under csched_priv lock */
+    spin_lock_irqsave(&prv->lock, flags);
+
     spc =3D CSCHED_PCPU(cpu);
     runq =3D &spc->runq;
=20
@@ -1464,6 +1469,12 @@ csched_dump_pcpu(const struct scheduler=20
     cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu))=
;
     printk("core=3D%s\n", cpustr);
=20
+    /*
+     * We need runq lock as well, and as there's one runq per CPU,
+     * this is the correct one to take for this CPU/runq.
+     */
+    pcpu_schedule_lock(cpu);
+
     /* current VCPU */
     svc =3D CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
     if ( svc )
@@ -1482,6 +1493,9 @@ csched_dump_pcpu(const struct scheduler=20
             csched_dump_vcpu(svc);
         }
     }
+
+    pcpu_schedule_unlock(cpu);
+    spin_unlock_irqrestore(&prv->lock, flags);
 #undef cpustr
 }
=20
@@ -1493,7 +1507,7 @@ csched_dump(const struct scheduler *ops)
     int loop;
     unsigned long flags;
=20
-    spin_lock_irqsave(&(prv->lock), flags);
+    spin_lock_irqsave(&prv->lock, flags);
=20
 #define idlers_buf keyhandler_scratch
=20
@@ -1537,12 +1551,14 @@ csched_dump(const struct scheduler *ops)
             svc =3D list_entry(iter_svc, struct csched_vcpu, active_vcpu_e=
lem);
=20
             printk("\t%3d: ", ++loop);
+            vcpu_schedule_lock(svc->vcpu);
             csched_dump_vcpu(svc);
+            vcpu_schedule_unlock(svc->vcpu);
         }
     }
 #undef idlers_buf
=20
-    spin_unlock_irqrestore(&(prv->lock), flags);
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20
 static int
diff -r 15ab61865ecb xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/common/sched_credit2.c	Wed Jan 18 15:02:30 2012 +0000
@@ -53,8 +53,6 @@
  * credit2 wiki page:
  *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
  * TODO:
- * + Immediate bug-fixes
- *  - Do per-runqueue, grab proper lock for dump debugkey
  * + Multiple sockets
  *  - Detect cpu layout and make runqueue map, one per L2 (make_runq_map()=
)
  *  - Simple load balancer / runqueue assignment
@@ -1759,12 +1757,16 @@ csched_dump_vcpu(struct csched_vcpu *svc
 static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
+    struct csched_private *prv =3D CSCHED_PRIV(ops);
     struct list_head *runq, *iter;
     struct csched_vcpu *svc;
+    unsigned long flags;
+    spinlock_t *lock;
     int loop;
     char cpustr[100];
=20
-    /* FIXME: Do locking properly for access to runqueue structures */
+    /* Domains' parameters are changed under csched_priv lock */
+    spin_lock_irqsave(&prv->lock, flags);
=20
     runq =3D &RQD(ops, cpu)->runq;
=20
@@ -1773,6 +1775,13 @@ csched_dump_pcpu(const struct scheduler=20
     cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu))=
;
     printk("core=3D%s\n", cpustr);
=20
+    /*
+     * We need runq lock as well, and here's how we get to it
+     * for the requested cpu.
+     */
+    lock =3D per_cpu(schedule_data, cpu).schedule_lock;
+    spin_lock(lock);
+
     /* current VCPU */
     svc =3D CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
     if ( svc )
@@ -1791,6 +1800,9 @@ csched_dump_pcpu(const struct scheduler=20
             csched_dump_vcpu(svc);
         }
     }
+
+    spin_unlock(lock);
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20
 static void
@@ -1798,8 +1810,11 @@ csched_dump(const struct scheduler *ops)
 {
     struct list_head *iter_sdom, *iter_svc;
     struct csched_private *prv =3D CSCHED_PRIV(ops);
+    unsigned long flags;
     int i, loop;
=20
+    spin_lock_irqsave(&prv->lock, flags);
+
     printk("Active queues: %d\n"
            "\tdefault-weight     =3D %d\n",
            cpumask_weight(&prv->active_queues),
@@ -1822,7 +1837,6 @@ csched_dump(const struct scheduler *ops)
                fraction);
=20
     }
-    /* FIXME: Locking! */
=20
     printk("Domain info:\n");
     loop =3D 0;
@@ -1831,10 +1845,10 @@ csched_dump(const struct scheduler *ops)
         struct csched_dom *sdom;
         sdom =3D list_entry(iter_sdom, struct csched_dom, sdom_elem);
=20
-       printk("\tDomain: %d w %d v %d\n\t",=20
-              sdom->dom->domain_id,=20
-              sdom->weight,=20
-              sdom->nr_vcpus);
+        printk("\tDomain: %d w %d v %d\n\t",=20
+               sdom->dom->domain_id,=20
+               sdom->weight,=20
+               sdom->nr_vcpus);
=20
         list_for_each( iter_svc, &sdom->vcpu )
         {
@@ -1842,9 +1856,13 @@ csched_dump(const struct scheduler *ops)
             svc =3D list_entry(iter_svc, struct csched_vcpu, sdom_elem);
=20
             printk("\t%3d: ", ++loop);
+            vcpu_schedule_lock(svc->vcpu);
             csched_dump_vcpu(svc);
+            vcpu_schedule_unlock(svc->vcpu);
         }
     }
+
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20
 static void activate_runqueue(struct csched_private *prv, int rqi)
diff -r 15ab61865ecb xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/common/sched_sedf.c	Wed Jan 18 15:02:30 2012 +0000
@@ -1219,13 +1219,25 @@ static void sedf_dump_domain(struct vcpu
 /* Dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
     struct list_head      *list, *queue, *tmp;
     struct sedf_vcpu_info *d_inf;
     struct domain         *d;
     struct vcpu    *ed;
+    unsigned long flags;
     int loop =3D 0;
+
+    /* Domains' parameters are changed under scheduler lock */
+    spin_lock_irqsave(&prv->lock, flags);
 =20
     printk("now=3D%"PRIu64"\n",NOW());
+
+    /*
+     * We need runq lock as well, and as there's one runq per CPU,
+     * this is the correct one to take for this CPU/runq.
+     */
+    pcpu_schedule_lock(i);
+
     queue =3D RUNQ(i);
     printk("RUNQ rq %lx   n: %lx, p: %lx\n",  (unsigned long)queue,
            (unsigned long) queue->next, (unsigned long) queue->prev);
@@ -1288,6 +1300,9 @@ static void sedf_dump_cpu_state(const st
         }
     }
     rcu_read_unlock(&domlist_read_lock);
+
+    pcpu_schedule_unlock(i);
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20
=20
diff -r 15ab61865ecb xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/common/schedule.c	Wed Jan 18 15:02:30 2012 +0000
@@ -1417,6 +1417,7 @@ void schedule_dump(struct cpupool *c)
     struct scheduler *sched;
     cpumask_t        *cpus;
=20
+    /* Proper locking is provided by each scheduler */
     sched =3D (c =3D=3D NULL) ? &ops : c->sched;
     cpus =3D (c =3D=3D NULL) ? &cpupool_free_cpus : c->cpu_valid;
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
@@ -1424,10 +1425,8 @@ void schedule_dump(struct cpupool *c)
=20
     for_each_cpu (i, cpus)
     {
-        pcpu_schedule_lock(i);
         printk("CPU[%02d] ", i);
         SCHED_OP(sched, dump_cpu_state, i);
-        pcpu_schedule_unlock(i);
     }
 }
=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)


--=-Sn+NDJR3EWzB5LTDsO7k
Content-Disposition: attachment; filename="rework-locking-for-dump-status.patch"
Content-Type: text/x-patch; name="rework-locking-for-dump-status.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE1YWI2MTg2NWVjYmQxNDZmNmNlNjVmYmVh
NWJmNDliZmQ5YzZjYjENCnNjaGVkOiByZXdvcmsgbG9ja2luZyBmb3IgZHVtcCBkZWJ1Z2tleS4N
Cg0KQXMgaW4gYWxsIG90aGVyIHBhdGhzLCBsb2NraW5nIHNob3VsZCBiZSBkZWFsdCB3aXRoIGlu
IHRoZQ0Kc3BlY2lmaWMgc2NoZWR1bGVycywgbm90IGluIHNjaGVkdWxlLmMuDQoNClNpZ25lZC1v
ZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5mYWdnaW9saUBjaXRyaXguY29tPg0KDQpkaWZm
IC1yIDE1YWI2MTg2NWVjYiB4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jDQotLS0gYS94ZW4vY29t
bW9uL3NjaGVkX2NyZWRpdC5jCVR1ZSBKYW4gMTcgMTI6NDA6NTIgMjAxMiArMDAwMA0KKysrIGIv
eGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwlXZWQgSmFuIDE4IDE1OjAyOjMwIDIwMTIgKzAwMDAN
CkBAIC0xNDUxLDExICsxNDUxLDE2IEBAIHN0YXRpYyB2b2lkDQogY3NjaGVkX2R1bXBfcGNwdShj
b25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIGludCBjcHUpDQogew0KICAgICBzdHJ1Y3QgbGlz
dF9oZWFkICpydW5xLCAqaXRlcjsNCisgICAgc3RydWN0IGNzY2hlZF9wcml2YXRlICpwcnYgPSBD
U0NIRURfUFJJVihvcHMpOw0KICAgICBzdHJ1Y3QgY3NjaGVkX3BjcHUgKnNwYzsNCiAgICAgc3Ry
dWN0IGNzY2hlZF92Y3B1ICpzdmM7DQorICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQogICAgIGlu
dCBsb29wOw0KICNkZWZpbmUgY3B1c3RyIGtleWhhbmRsZXJfc2NyYXRjaA0KIA0KKyAgICAvKiBE
b21haW5zJyBwYXJhbWV0ZXJzIGFyZSBjaGFuZ2VkIHVuZGVyIGNzY2hlZF9wcml2IGxvY2sgKi8N
CisgICAgc3Bpbl9sb2NrX2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KKw0KICAgICBzcGMg
PSBDU0NIRURfUENQVShjcHUpOw0KICAgICBydW5xID0gJnNwYy0+cnVucTsNCiANCkBAIC0xNDY0
LDYgKzE0NjksMTIgQEAgY3NjaGVkX2R1bXBfcGNwdShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyIA0K
ICAgICBjcHVtYXNrX3NjbnByaW50ZihjcHVzdHIsIHNpemVvZihjcHVzdHIpLCBwZXJfY3B1KGNw
dV9jb3JlX21hc2ssIGNwdSkpOw0KICAgICBwcmludGsoImNvcmU9JXNcbiIsIGNwdXN0cik7DQog
DQorICAgIC8qDQorICAgICAqIFdlIG5lZWQgcnVucSBsb2NrIGFzIHdlbGwsIGFuZCBhcyB0aGVy
ZSdzIG9uZSBydW5xIHBlciBDUFUsDQorICAgICAqIHRoaXMgaXMgdGhlIGNvcnJlY3Qgb25lIHRv
IHRha2UgZm9yIHRoaXMgQ1BVL3J1bnEuDQorICAgICAqLw0KKyAgICBwY3B1X3NjaGVkdWxlX2xv
Y2soY3B1KTsNCisNCiAgICAgLyogY3VycmVudCBWQ1BVICovDQogICAgIHN2YyA9IENTQ0hFRF9W
Q1BVKHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwgY3B1KS5jdXJyKTsNCiAgICAgaWYgKCBzdmMgKQ0K
QEAgLTE0ODIsNiArMTQ5Myw5IEBAIGNzY2hlZF9kdW1wX3BjcHUoY29uc3Qgc3RydWN0IHNjaGVk
dWxlciANCiAgICAgICAgICAgICBjc2NoZWRfZHVtcF92Y3B1KHN2Yyk7DQogICAgICAgICB9DQog
ICAgIH0NCisNCisgICAgcGNwdV9zY2hlZHVsZV91bmxvY2soY3B1KTsNCisgICAgc3Bpbl91bmxv
Y2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQogI3VuZGVmIGNwdXN0cg0KIH0NCiAN
CkBAIC0xNDkzLDcgKzE1MDcsNyBAQCBjc2NoZWRfZHVtcChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVy
ICpvcHMpDQogICAgIGludCBsb29wOw0KICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KIA0KLSAg
ICBzcGluX2xvY2tfaXJxc2F2ZSgmKHBydi0+bG9jayksIGZsYWdzKTsNCisgICAgc3Bpbl9sb2Nr
X2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KIA0KICNkZWZpbmUgaWRsZXJzX2J1ZiBrZXlo
YW5kbGVyX3NjcmF0Y2gNCiANCkBAIC0xNTM3LDEyICsxNTUxLDE0IEBAIGNzY2hlZF9kdW1wKGNv
bnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcykNCiAgICAgICAgICAgICBzdmMgPSBsaXN0X2VudHJ5
KGl0ZXJfc3ZjLCBzdHJ1Y3QgY3NjaGVkX3ZjcHUsIGFjdGl2ZV92Y3B1X2VsZW0pOw0KIA0KICAg
ICAgICAgICAgIHByaW50aygiXHQlM2Q6ICIsICsrbG9vcCk7DQorICAgICAgICAgICAgdmNwdV9z
Y2hlZHVsZV9sb2NrKHN2Yy0+dmNwdSk7DQogICAgICAgICAgICAgY3NjaGVkX2R1bXBfdmNwdShz
dmMpOw0KKyAgICAgICAgICAgIHZjcHVfc2NoZWR1bGVfdW5sb2NrKHN2Yy0+dmNwdSk7DQogICAg
ICAgICB9DQogICAgIH0NCiAjdW5kZWYgaWRsZXJzX2J1Zg0KIA0KLSAgICBzcGluX3VubG9ja19p
cnFyZXN0b3JlKCYocHJ2LT5sb2NrKSwgZmxhZ3MpOw0KKyAgICBzcGluX3VubG9ja19pcnFyZXN0
b3JlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCiB9DQogDQogc3RhdGljIGludA0KZGlmZiAtciAxNWFi
NjE4NjVlY2IgeGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQyLmMNCi0tLSBhL3hlbi9jb21tb24vc2No
ZWRfY3JlZGl0Mi5jCVR1ZSBKYW4gMTcgMTI6NDA6NTIgMjAxMiArMDAwMA0KKysrIGIveGVuL2Nv
bW1vbi9zY2hlZF9jcmVkaXQyLmMJV2VkIEphbiAxOCAxNTowMjozMCAyMDEyICswMDAwDQpAQCAt
NTMsOCArNTMsNiBAQA0KICAqIGNyZWRpdDIgd2lraSBwYWdlOg0KICAqICBodHRwOi8vd2lraS54
ZW4ub3JnL3dpa2kvQ3JlZGl0Ml9TY2hlZHVsZXJfRGV2ZWxvcG1lbnQNCiAgKiBUT0RPOg0KLSAq
ICsgSW1tZWRpYXRlIGJ1Zy1maXhlcw0KLSAqICAtIERvIHBlci1ydW5xdWV1ZSwgZ3JhYiBwcm9w
ZXIgbG9jayBmb3IgZHVtcCBkZWJ1Z2tleQ0KICAqICsgTXVsdGlwbGUgc29ja2V0cw0KICAqICAt
IERldGVjdCBjcHUgbGF5b3V0IGFuZCBtYWtlIHJ1bnF1ZXVlIG1hcCwgb25lIHBlciBMMiAobWFr
ZV9ydW5xX21hcCgpKQ0KICAqICAtIFNpbXBsZSBsb2FkIGJhbGFuY2VyIC8gcnVucXVldWUgYXNz
aWdubWVudA0KQEAgLTE3NTksMTIgKzE3NTcsMTYgQEAgY3NjaGVkX2R1bXBfdmNwdShzdHJ1Y3Qg
Y3NjaGVkX3ZjcHUgKnN2Yw0KIHN0YXRpYyB2b2lkDQogY3NjaGVkX2R1bXBfcGNwdShjb25zdCBz
dHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIGludCBjcHUpDQogew0KKyAgICBzdHJ1Y3QgY3NjaGVkX3By
aXZhdGUgKnBydiA9IENTQ0hFRF9QUklWKG9wcyk7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgKnJ1
bnEsICppdGVyOw0KICAgICBzdHJ1Y3QgY3NjaGVkX3ZjcHUgKnN2YzsNCisgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsNCisgICAgc3BpbmxvY2tfdCAqbG9jazsNCiAgICAgaW50IGxvb3A7DQogICAg
IGNoYXIgY3B1c3RyWzEwMF07DQogDQotICAgIC8qIEZJWE1FOiBEbyBsb2NraW5nIHByb3Blcmx5
IGZvciBhY2Nlc3MgdG8gcnVucXVldWUgc3RydWN0dXJlcyAqLw0KKyAgICAvKiBEb21haW5zJyBw
YXJhbWV0ZXJzIGFyZSBjaGFuZ2VkIHVuZGVyIGNzY2hlZF9wcml2IGxvY2sgKi8NCisgICAgc3Bp
bl9sb2NrX2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KIA0KICAgICBydW5xID0gJlJRRChv
cHMsIGNwdSktPnJ1bnE7DQogDQpAQCAtMTc3Myw2ICsxNzc1LDEzIEBAIGNzY2hlZF9kdW1wX3Bj
cHUoY29uc3Qgc3RydWN0IHNjaGVkdWxlciANCiAgICAgY3B1bWFza19zY25wcmludGYoY3B1c3Ry
LCBzaXplb2YoY3B1c3RyKSwgcGVyX2NwdShjcHVfY29yZV9tYXNrLCBjcHUpKTsNCiAgICAgcHJp
bnRrKCJjb3JlPSVzXG4iLCBjcHVzdHIpOw0KIA0KKyAgICAvKg0KKyAgICAgKiBXZSBuZWVkIHJ1
bnEgbG9jayBhcyB3ZWxsLCBhbmQgaGVyZSdzIGhvdyB3ZSBnZXQgdG8gaXQNCisgICAgICogZm9y
IHRoZSByZXF1ZXN0ZWQgY3B1Lg0KKyAgICAgKi8NCisgICAgbG9jayA9IHBlcl9jcHUoc2NoZWR1
bGVfZGF0YSwgY3B1KS5zY2hlZHVsZV9sb2NrOw0KKyAgICBzcGluX2xvY2sobG9jayk7DQorDQog
ICAgIC8qIGN1cnJlbnQgVkNQVSAqLw0KICAgICBzdmMgPSBDU0NIRURfVkNQVShwZXJfY3B1KHNj
aGVkdWxlX2RhdGEsIGNwdSkuY3Vycik7DQogICAgIGlmICggc3ZjICkNCkBAIC0xNzkxLDYgKzE4
MDAsOSBAQCBjc2NoZWRfZHVtcF9wY3B1KGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgDQogICAgICAg
ICAgICAgY3NjaGVkX2R1bXBfdmNwdShzdmMpOw0KICAgICAgICAgfQ0KICAgICB9DQorDQorICAg
IHNwaW5fdW5sb2NrKGxvY2spOw0KKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwcnYtPmxv
Y2ssIGZsYWdzKTsNCiB9DQogDQogc3RhdGljIHZvaWQNCkBAIC0xNzk4LDggKzE4MTAsMTEgQEAg
Y3NjaGVkX2R1bXAoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzKQ0KIHsNCiAgICAgc3RydWN0
IGxpc3RfaGVhZCAqaXRlcl9zZG9tLCAqaXRlcl9zdmM7DQogICAgIHN0cnVjdCBjc2NoZWRfcHJp
dmF0ZSAqcHJ2ID0gQ1NDSEVEX1BSSVYob3BzKTsNCisgICAgdW5zaWduZWQgbG9uZyBmbGFnczsN
CiAgICAgaW50IGksIGxvb3A7DQogDQorICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwcnYtPmxvY2ss
IGZsYWdzKTsNCisNCiAgICAgcHJpbnRrKCJBY3RpdmUgcXVldWVzOiAlZFxuIg0KICAgICAgICAg
ICAgIlx0ZGVmYXVsdC13ZWlnaHQgICAgID0gJWRcbiIsDQogICAgICAgICAgICBjcHVtYXNrX3dl
aWdodCgmcHJ2LT5hY3RpdmVfcXVldWVzKSwNCkBAIC0xODIyLDcgKzE4MzcsNiBAQCBjc2NoZWRf
ZHVtcChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMpDQogICAgICAgICAgICAgICAgZnJhY3Rp
b24pOw0KIA0KICAgICB9DQotICAgIC8qIEZJWE1FOiBMb2NraW5nISAqLw0KIA0KICAgICBwcmlu
dGsoIkRvbWFpbiBpbmZvOlxuIik7DQogICAgIGxvb3AgPSAwOw0KQEAgLTE4MzEsMTAgKzE4NDUs
MTAgQEAgY3NjaGVkX2R1bXAoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzKQ0KICAgICAgICAg
c3RydWN0IGNzY2hlZF9kb20gKnNkb207DQogICAgICAgICBzZG9tID0gbGlzdF9lbnRyeShpdGVy
X3Nkb20sIHN0cnVjdCBjc2NoZWRfZG9tLCBzZG9tX2VsZW0pOw0KIA0KLSAgICAgICBwcmludGso
Ilx0RG9tYWluOiAlZCB3ICVkIHYgJWRcblx0IiwgDQotICAgICAgICAgICAgICBzZG9tLT5kb20t
PmRvbWFpbl9pZCwgDQotICAgICAgICAgICAgICBzZG9tLT53ZWlnaHQsIA0KLSAgICAgICAgICAg
ICAgc2RvbS0+bnJfdmNwdXMpOw0KKyAgICAgICAgcHJpbnRrKCJcdERvbWFpbjogJWQgdyAlZCB2
ICVkXG5cdCIsIA0KKyAgICAgICAgICAgICAgIHNkb20tPmRvbS0+ZG9tYWluX2lkLCANCisgICAg
ICAgICAgICAgICBzZG9tLT53ZWlnaHQsIA0KKyAgICAgICAgICAgICAgIHNkb20tPm5yX3ZjcHVz
KTsNCiANCiAgICAgICAgIGxpc3RfZm9yX2VhY2goIGl0ZXJfc3ZjLCAmc2RvbS0+dmNwdSApDQog
ICAgICAgICB7DQpAQCAtMTg0Miw5ICsxODU2LDEzIEBAIGNzY2hlZF9kdW1wKGNvbnN0IHN0cnVj
dCBzY2hlZHVsZXIgKm9wcykNCiAgICAgICAgICAgICBzdmMgPSBsaXN0X2VudHJ5KGl0ZXJfc3Zj
LCBzdHJ1Y3QgY3NjaGVkX3ZjcHUsIHNkb21fZWxlbSk7DQogDQogICAgICAgICAgICAgcHJpbnRr
KCJcdCUzZDogIiwgKytsb29wKTsNCisgICAgICAgICAgICB2Y3B1X3NjaGVkdWxlX2xvY2soc3Zj
LT52Y3B1KTsNCiAgICAgICAgICAgICBjc2NoZWRfZHVtcF92Y3B1KHN2Yyk7DQorICAgICAgICAg
ICAgdmNwdV9zY2hlZHVsZV91bmxvY2soc3ZjLT52Y3B1KTsNCiAgICAgICAgIH0NCiAgICAgfQ0K
Kw0KKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCiB9DQog
DQogc3RhdGljIHZvaWQgYWN0aXZhdGVfcnVucXVldWUoc3RydWN0IGNzY2hlZF9wcml2YXRlICpw
cnYsIGludCBycWkpDQpkaWZmIC1yIDE1YWI2MTg2NWVjYiB4ZW4vY29tbW9uL3NjaGVkX3NlZGYu
Yw0KLS0tIGEveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJVHVlIEphbiAxNyAxMjo0MDo1MiAyMDEy
ICswMDAwDQorKysgYi94ZW4vY29tbW9uL3NjaGVkX3NlZGYuYwlXZWQgSmFuIDE4IDE1OjAyOjMw
IDIwMTIgKzAwMDANCkBAIC0xMjE5LDEzICsxMjE5LDI1IEBAIHN0YXRpYyB2b2lkIHNlZGZfZHVt
cF9kb21haW4oc3RydWN0IHZjcHUNCiAvKiBEdW1wcyBhbGwgZG9tYWlucyBvbiB0aGUgc3BlY2lm
aWVkIGNwdSAqLw0KIHN0YXRpYyB2b2lkIHNlZGZfZHVtcF9jcHVfc3RhdGUoY29uc3Qgc3RydWN0
IHNjaGVkdWxlciAqb3BzLCBpbnQgaSkNCiB7DQorICAgIHN0cnVjdCBzZWRmX3ByaXZfaW5mbyAq
cHJ2ID0gU0VERl9QUklWKG9wcyk7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICAqbGlzdCwg
KnF1ZXVlLCAqdG1wOw0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gKmRfaW5mOw0KICAgICBz
dHJ1Y3QgZG9tYWluICAgICAgICAgKmQ7DQogICAgIHN0cnVjdCB2Y3B1ICAgICplZDsNCisgICAg
dW5zaWduZWQgbG9uZyBmbGFnczsNCiAgICAgaW50IGxvb3AgPSAwOw0KKw0KKyAgICAvKiBEb21h
aW5zJyBwYXJhbWV0ZXJzIGFyZSBjaGFuZ2VkIHVuZGVyIHNjaGVkdWxlciBsb2NrICovDQorICAg
IHNwaW5fbG9ja19pcnFzYXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCiAgDQogICAgIHByaW50aygi
bm93PSUiUFJJdTY0IlxuIixOT1coKSk7DQorDQorICAgIC8qDQorICAgICAqIFdlIG5lZWQgcnVu
cSBsb2NrIGFzIHdlbGwsIGFuZCBhcyB0aGVyZSdzIG9uZSBydW5xIHBlciBDUFUsDQorICAgICAq
IHRoaXMgaXMgdGhlIGNvcnJlY3Qgb25lIHRvIHRha2UgZm9yIHRoaXMgQ1BVL3J1bnEuDQorICAg
ICAqLw0KKyAgICBwY3B1X3NjaGVkdWxlX2xvY2soaSk7DQorDQogICAgIHF1ZXVlID0gUlVOUShp
KTsNCiAgICAgcHJpbnRrKCJSVU5RIHJxICVseCAgIG46ICVseCwgcDogJWx4XG4iLCAgKHVuc2ln
bmVkIGxvbmcpcXVldWUsDQogICAgICAgICAgICAodW5zaWduZWQgbG9uZykgcXVldWUtPm5leHQs
ICh1bnNpZ25lZCBsb25nKSBxdWV1ZS0+cHJldik7DQpAQCAtMTI4OCw2ICsxMzAwLDkgQEAgc3Rh
dGljIHZvaWQgc2VkZl9kdW1wX2NwdV9zdGF0ZShjb25zdCBzdA0KICAgICAgICAgfQ0KICAgICB9
DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KKw0KKyAgICBwY3B1
X3NjaGVkdWxlX3VubG9jayhpKTsNCisgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5s
b2NrLCBmbGFncyk7DQogfQ0KIA0KIA0KZGlmZiAtciAxNWFiNjE4NjVlY2IgeGVuL2NvbW1vbi9z
Y2hlZHVsZS5jDQotLS0gYS94ZW4vY29tbW9uL3NjaGVkdWxlLmMJVHVlIEphbiAxNyAxMjo0MDo1
MiAyMDEyICswMDAwDQorKysgYi94ZW4vY29tbW9uL3NjaGVkdWxlLmMJV2VkIEphbiAxOCAxNTow
MjozMCAyMDEyICswMDAwDQpAQCAtMTQxNyw2ICsxNDE3LDcgQEAgdm9pZCBzY2hlZHVsZV9kdW1w
KHN0cnVjdCBjcHVwb29sICpjKQ0KICAgICBzdHJ1Y3Qgc2NoZWR1bGVyICpzY2hlZDsNCiAgICAg
Y3B1bWFza190ICAgICAgICAqY3B1czsNCiANCisgICAgLyogUHJvcGVyIGxvY2tpbmcgaXMgcHJv
dmlkZWQgYnkgZWFjaCBzY2hlZHVsZXIgKi8NCiAgICAgc2NoZWQgPSAoYyA9PSBOVUxMKSA/ICZv
cHMgOiBjLT5zY2hlZDsNCiAgICAgY3B1cyA9IChjID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9j
cHVzIDogYy0+Y3B1X3ZhbGlkOw0KICAgICBwcmludGsoIlNjaGVkdWxlcjogJXMgKCVzKVxuIiwg
c2NoZWQtPm5hbWUsIHNjaGVkLT5vcHRfbmFtZSk7DQpAQCAtMTQyNCwxMCArMTQyNSw4IEBAIHZv
aWQgc2NoZWR1bGVfZHVtcChzdHJ1Y3QgY3B1cG9vbCAqYykNCiANCiAgICAgZm9yX2VhY2hfY3B1
IChpLCBjcHVzKQ0KICAgICB7DQotICAgICAgICBwY3B1X3NjaGVkdWxlX2xvY2soaSk7DQogICAg
ICAgICBwcmludGsoIkNQVVslMDJkXSAiLCBpKTsNCiAgICAgICAgIFNDSEVEX09QKHNjaGVkLCBk
dW1wX2NwdV9zdGF0ZSwgaSk7DQotICAgICAgICBwY3B1X3NjaGVkdWxlX3VubG9jayhpKTsNCiAg
ICAgfQ0KIH0NCiANCg==


--=-Sn+NDJR3EWzB5LTDsO7k--

--=-ApW/FEYJ2HeKXZmm9mdH
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)

iEYEABECAAYFAk8W8lYACgkQk4XaBE3IOsTCcwCfSpGD3WpfK5+Jh5cHvwInLWAV
frEAnjm6dykd9QSapwJcKL9cF2dMarti
=dxJj
-----END PGP SIGNATURE-----

--=-ApW/FEYJ2HeKXZmm9mdH--



--===============6363075103574912662==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6363075103574912662==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:26:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16:26:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYKH-0005tk-Tg; Wed, 18 Jan 2012 16:25:29 +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 1RnYKG-0005tB-2z
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:25:28 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326903920!9522868!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 28536 invoked from network); 18 Jan 2012 16:25:20 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 16:25:20 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74599980; Wed, 18 Jan 2012 17:25:19 +0100
Message-ID: <1326903894.5856.35.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Wed, 18 Jan 2012 17:24:54 +0100
In-Reply-To: <1326903221.5856.33.camel@Solace>
References: <1326903221.5856.33.camel@Solace>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: [Xen-devel] [PATCH 1 of 1] sched: rework locking for dump debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6363075103574912662=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============6363075103574912662==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ApW/FEYJ2HeKXZmm9mdH"


--=-ApW/FEYJ2HeKXZmm9mdH
Content-Type: multipart/mixed; boundary="=-Sn+NDJR3EWzB5LTDsO7k"


--=-Sn+NDJR3EWzB5LTDsO7k
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As in all other paths, locking should be dealt with in the
specific schedulers, not in schedule.c.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 15ab61865ecb xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/common/sched_credit.c	Wed Jan 18 15:02:30 2012 +0000
@@ -1451,11 +1451,16 @@ static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
     struct list_head *runq, *iter;
+    struct csched_private *prv =3D CSCHED_PRIV(ops);
     struct csched_pcpu *spc;
     struct csched_vcpu *svc;
+    unsigned long flags;
     int loop;
 #define cpustr keyhandler_scratch
=20
+    /* Domains' parameters are changed under csched_priv lock */
+    spin_lock_irqsave(&prv->lock, flags);
+
     spc =3D CSCHED_PCPU(cpu);
     runq =3D &spc->runq;
=20
@@ -1464,6 +1469,12 @@ csched_dump_pcpu(const struct scheduler=20
     cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu))=
;
     printk("core=3D%s\n", cpustr);
=20
+    /*
+     * We need runq lock as well, and as there's one runq per CPU,
+     * this is the correct one to take for this CPU/runq.
+     */
+    pcpu_schedule_lock(cpu);
+
     /* current VCPU */
     svc =3D CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
     if ( svc )
@@ -1482,6 +1493,9 @@ csched_dump_pcpu(const struct scheduler=20
             csched_dump_vcpu(svc);
         }
     }
+
+    pcpu_schedule_unlock(cpu);
+    spin_unlock_irqrestore(&prv->lock, flags);
 #undef cpustr
 }
=20
@@ -1493,7 +1507,7 @@ csched_dump(const struct scheduler *ops)
     int loop;
     unsigned long flags;
=20
-    spin_lock_irqsave(&(prv->lock), flags);
+    spin_lock_irqsave(&prv->lock, flags);
=20
 #define idlers_buf keyhandler_scratch
=20
@@ -1537,12 +1551,14 @@ csched_dump(const struct scheduler *ops)
             svc =3D list_entry(iter_svc, struct csched_vcpu, active_vcpu_e=
lem);
=20
             printk("\t%3d: ", ++loop);
+            vcpu_schedule_lock(svc->vcpu);
             csched_dump_vcpu(svc);
+            vcpu_schedule_unlock(svc->vcpu);
         }
     }
 #undef idlers_buf
=20
-    spin_unlock_irqrestore(&(prv->lock), flags);
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20
 static int
diff -r 15ab61865ecb xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/common/sched_credit2.c	Wed Jan 18 15:02:30 2012 +0000
@@ -53,8 +53,6 @@
  * credit2 wiki page:
  *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
  * TODO:
- * + Immediate bug-fixes
- *  - Do per-runqueue, grab proper lock for dump debugkey
  * + Multiple sockets
  *  - Detect cpu layout and make runqueue map, one per L2 (make_runq_map()=
)
  *  - Simple load balancer / runqueue assignment
@@ -1759,12 +1757,16 @@ csched_dump_vcpu(struct csched_vcpu *svc
 static void
 csched_dump_pcpu(const struct scheduler *ops, int cpu)
 {
+    struct csched_private *prv =3D CSCHED_PRIV(ops);
     struct list_head *runq, *iter;
     struct csched_vcpu *svc;
+    unsigned long flags;
+    spinlock_t *lock;
     int loop;
     char cpustr[100];
=20
-    /* FIXME: Do locking properly for access to runqueue structures */
+    /* Domains' parameters are changed under csched_priv lock */
+    spin_lock_irqsave(&prv->lock, flags);
=20
     runq =3D &RQD(ops, cpu)->runq;
=20
@@ -1773,6 +1775,13 @@ csched_dump_pcpu(const struct scheduler=20
     cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu))=
;
     printk("core=3D%s\n", cpustr);
=20
+    /*
+     * We need runq lock as well, and here's how we get to it
+     * for the requested cpu.
+     */
+    lock =3D per_cpu(schedule_data, cpu).schedule_lock;
+    spin_lock(lock);
+
     /* current VCPU */
     svc =3D CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
     if ( svc )
@@ -1791,6 +1800,9 @@ csched_dump_pcpu(const struct scheduler=20
             csched_dump_vcpu(svc);
         }
     }
+
+    spin_unlock(lock);
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20
 static void
@@ -1798,8 +1810,11 @@ csched_dump(const struct scheduler *ops)
 {
     struct list_head *iter_sdom, *iter_svc;
     struct csched_private *prv =3D CSCHED_PRIV(ops);
+    unsigned long flags;
     int i, loop;
=20
+    spin_lock_irqsave(&prv->lock, flags);
+
     printk("Active queues: %d\n"
            "\tdefault-weight     =3D %d\n",
            cpumask_weight(&prv->active_queues),
@@ -1822,7 +1837,6 @@ csched_dump(const struct scheduler *ops)
                fraction);
=20
     }
-    /* FIXME: Locking! */
=20
     printk("Domain info:\n");
     loop =3D 0;
@@ -1831,10 +1845,10 @@ csched_dump(const struct scheduler *ops)
         struct csched_dom *sdom;
         sdom =3D list_entry(iter_sdom, struct csched_dom, sdom_elem);
=20
-       printk("\tDomain: %d w %d v %d\n\t",=20
-              sdom->dom->domain_id,=20
-              sdom->weight,=20
-              sdom->nr_vcpus);
+        printk("\tDomain: %d w %d v %d\n\t",=20
+               sdom->dom->domain_id,=20
+               sdom->weight,=20
+               sdom->nr_vcpus);
=20
         list_for_each( iter_svc, &sdom->vcpu )
         {
@@ -1842,9 +1856,13 @@ csched_dump(const struct scheduler *ops)
             svc =3D list_entry(iter_svc, struct csched_vcpu, sdom_elem);
=20
             printk("\t%3d: ", ++loop);
+            vcpu_schedule_lock(svc->vcpu);
             csched_dump_vcpu(svc);
+            vcpu_schedule_unlock(svc->vcpu);
         }
     }
+
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20
 static void activate_runqueue(struct csched_private *prv, int rqi)
diff -r 15ab61865ecb xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/common/sched_sedf.c	Wed Jan 18 15:02:30 2012 +0000
@@ -1219,13 +1219,25 @@ static void sedf_dump_domain(struct vcpu
 /* Dumps all domains on the specified cpu */
 static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
 {
+    struct sedf_priv_info *prv =3D SEDF_PRIV(ops);
     struct list_head      *list, *queue, *tmp;
     struct sedf_vcpu_info *d_inf;
     struct domain         *d;
     struct vcpu    *ed;
+    unsigned long flags;
     int loop =3D 0;
+
+    /* Domains' parameters are changed under scheduler lock */
+    spin_lock_irqsave(&prv->lock, flags);
 =20
     printk("now=3D%"PRIu64"\n",NOW());
+
+    /*
+     * We need runq lock as well, and as there's one runq per CPU,
+     * this is the correct one to take for this CPU/runq.
+     */
+    pcpu_schedule_lock(i);
+
     queue =3D RUNQ(i);
     printk("RUNQ rq %lx   n: %lx, p: %lx\n",  (unsigned long)queue,
            (unsigned long) queue->next, (unsigned long) queue->prev);
@@ -1288,6 +1300,9 @@ static void sedf_dump_cpu_state(const st
         }
     }
     rcu_read_unlock(&domlist_read_lock);
+
+    pcpu_schedule_unlock(i);
+    spin_unlock_irqrestore(&prv->lock, flags);
 }
=20
=20
diff -r 15ab61865ecb xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Jan 17 12:40:52 2012 +0000
+++ b/xen/common/schedule.c	Wed Jan 18 15:02:30 2012 +0000
@@ -1417,6 +1417,7 @@ void schedule_dump(struct cpupool *c)
     struct scheduler *sched;
     cpumask_t        *cpus;
=20
+    /* Proper locking is provided by each scheduler */
     sched =3D (c =3D=3D NULL) ? &ops : c->sched;
     cpus =3D (c =3D=3D NULL) ? &cpupool_free_cpus : c->cpu_valid;
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
@@ -1424,10 +1425,8 @@ void schedule_dump(struct cpupool *c)
=20
     for_each_cpu (i, cpus)
     {
-        pcpu_schedule_lock(i);
         printk("CPU[%02d] ", i);
         SCHED_OP(sched, dump_cpu_state, i);
-        pcpu_schedule_unlock(i);
     }
 }
=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)


--=-Sn+NDJR3EWzB5LTDsO7k
Content-Disposition: attachment; filename="rework-locking-for-dump-status.patch"
Content-Type: text/x-patch; name="rework-locking-for-dump-status.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDE1YWI2MTg2NWVjYmQxNDZmNmNlNjVmYmVh
NWJmNDliZmQ5YzZjYjENCnNjaGVkOiByZXdvcmsgbG9ja2luZyBmb3IgZHVtcCBkZWJ1Z2tleS4N
Cg0KQXMgaW4gYWxsIG90aGVyIHBhdGhzLCBsb2NraW5nIHNob3VsZCBiZSBkZWFsdCB3aXRoIGlu
IHRoZQ0Kc3BlY2lmaWMgc2NoZWR1bGVycywgbm90IGluIHNjaGVkdWxlLmMuDQoNClNpZ25lZC1v
ZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5mYWdnaW9saUBjaXRyaXguY29tPg0KDQpkaWZm
IC1yIDE1YWI2MTg2NWVjYiB4ZW4vY29tbW9uL3NjaGVkX2NyZWRpdC5jDQotLS0gYS94ZW4vY29t
bW9uL3NjaGVkX2NyZWRpdC5jCVR1ZSBKYW4gMTcgMTI6NDA6NTIgMjAxMiArMDAwMA0KKysrIGIv
eGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQuYwlXZWQgSmFuIDE4IDE1OjAyOjMwIDIwMTIgKzAwMDAN
CkBAIC0xNDUxLDExICsxNDUxLDE2IEBAIHN0YXRpYyB2b2lkDQogY3NjaGVkX2R1bXBfcGNwdShj
b25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIGludCBjcHUpDQogew0KICAgICBzdHJ1Y3QgbGlz
dF9oZWFkICpydW5xLCAqaXRlcjsNCisgICAgc3RydWN0IGNzY2hlZF9wcml2YXRlICpwcnYgPSBD
U0NIRURfUFJJVihvcHMpOw0KICAgICBzdHJ1Y3QgY3NjaGVkX3BjcHUgKnNwYzsNCiAgICAgc3Ry
dWN0IGNzY2hlZF92Y3B1ICpzdmM7DQorICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7DQogICAgIGlu
dCBsb29wOw0KICNkZWZpbmUgY3B1c3RyIGtleWhhbmRsZXJfc2NyYXRjaA0KIA0KKyAgICAvKiBE
b21haW5zJyBwYXJhbWV0ZXJzIGFyZSBjaGFuZ2VkIHVuZGVyIGNzY2hlZF9wcml2IGxvY2sgKi8N
CisgICAgc3Bpbl9sb2NrX2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KKw0KICAgICBzcGMg
PSBDU0NIRURfUENQVShjcHUpOw0KICAgICBydW5xID0gJnNwYy0+cnVucTsNCiANCkBAIC0xNDY0
LDYgKzE0NjksMTIgQEAgY3NjaGVkX2R1bXBfcGNwdShjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyIA0K
ICAgICBjcHVtYXNrX3NjbnByaW50ZihjcHVzdHIsIHNpemVvZihjcHVzdHIpLCBwZXJfY3B1KGNw
dV9jb3JlX21hc2ssIGNwdSkpOw0KICAgICBwcmludGsoImNvcmU9JXNcbiIsIGNwdXN0cik7DQog
DQorICAgIC8qDQorICAgICAqIFdlIG5lZWQgcnVucSBsb2NrIGFzIHdlbGwsIGFuZCBhcyB0aGVy
ZSdzIG9uZSBydW5xIHBlciBDUFUsDQorICAgICAqIHRoaXMgaXMgdGhlIGNvcnJlY3Qgb25lIHRv
IHRha2UgZm9yIHRoaXMgQ1BVL3J1bnEuDQorICAgICAqLw0KKyAgICBwY3B1X3NjaGVkdWxlX2xv
Y2soY3B1KTsNCisNCiAgICAgLyogY3VycmVudCBWQ1BVICovDQogICAgIHN2YyA9IENTQ0hFRF9W
Q1BVKHBlcl9jcHUoc2NoZWR1bGVfZGF0YSwgY3B1KS5jdXJyKTsNCiAgICAgaWYgKCBzdmMgKQ0K
QEAgLTE0ODIsNiArMTQ5Myw5IEBAIGNzY2hlZF9kdW1wX3BjcHUoY29uc3Qgc3RydWN0IHNjaGVk
dWxlciANCiAgICAgICAgICAgICBjc2NoZWRfZHVtcF92Y3B1KHN2Yyk7DQogICAgICAgICB9DQog
ICAgIH0NCisNCisgICAgcGNwdV9zY2hlZHVsZV91bmxvY2soY3B1KTsNCisgICAgc3Bpbl91bmxv
Y2tfaXJxcmVzdG9yZSgmcHJ2LT5sb2NrLCBmbGFncyk7DQogI3VuZGVmIGNwdXN0cg0KIH0NCiAN
CkBAIC0xNDkzLDcgKzE1MDcsNyBAQCBjc2NoZWRfZHVtcChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVy
ICpvcHMpDQogICAgIGludCBsb29wOw0KICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KIA0KLSAg
ICBzcGluX2xvY2tfaXJxc2F2ZSgmKHBydi0+bG9jayksIGZsYWdzKTsNCisgICAgc3Bpbl9sb2Nr
X2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KIA0KICNkZWZpbmUgaWRsZXJzX2J1ZiBrZXlo
YW5kbGVyX3NjcmF0Y2gNCiANCkBAIC0xNTM3LDEyICsxNTUxLDE0IEBAIGNzY2hlZF9kdW1wKGNv
bnN0IHN0cnVjdCBzY2hlZHVsZXIgKm9wcykNCiAgICAgICAgICAgICBzdmMgPSBsaXN0X2VudHJ5
KGl0ZXJfc3ZjLCBzdHJ1Y3QgY3NjaGVkX3ZjcHUsIGFjdGl2ZV92Y3B1X2VsZW0pOw0KIA0KICAg
ICAgICAgICAgIHByaW50aygiXHQlM2Q6ICIsICsrbG9vcCk7DQorICAgICAgICAgICAgdmNwdV9z
Y2hlZHVsZV9sb2NrKHN2Yy0+dmNwdSk7DQogICAgICAgICAgICAgY3NjaGVkX2R1bXBfdmNwdShz
dmMpOw0KKyAgICAgICAgICAgIHZjcHVfc2NoZWR1bGVfdW5sb2NrKHN2Yy0+dmNwdSk7DQogICAg
ICAgICB9DQogICAgIH0NCiAjdW5kZWYgaWRsZXJzX2J1Zg0KIA0KLSAgICBzcGluX3VubG9ja19p
cnFyZXN0b3JlKCYocHJ2LT5sb2NrKSwgZmxhZ3MpOw0KKyAgICBzcGluX3VubG9ja19pcnFyZXN0
b3JlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCiB9DQogDQogc3RhdGljIGludA0KZGlmZiAtciAxNWFi
NjE4NjVlY2IgeGVuL2NvbW1vbi9zY2hlZF9jcmVkaXQyLmMNCi0tLSBhL3hlbi9jb21tb24vc2No
ZWRfY3JlZGl0Mi5jCVR1ZSBKYW4gMTcgMTI6NDA6NTIgMjAxMiArMDAwMA0KKysrIGIveGVuL2Nv
bW1vbi9zY2hlZF9jcmVkaXQyLmMJV2VkIEphbiAxOCAxNTowMjozMCAyMDEyICswMDAwDQpAQCAt
NTMsOCArNTMsNiBAQA0KICAqIGNyZWRpdDIgd2lraSBwYWdlOg0KICAqICBodHRwOi8vd2lraS54
ZW4ub3JnL3dpa2kvQ3JlZGl0Ml9TY2hlZHVsZXJfRGV2ZWxvcG1lbnQNCiAgKiBUT0RPOg0KLSAq
ICsgSW1tZWRpYXRlIGJ1Zy1maXhlcw0KLSAqICAtIERvIHBlci1ydW5xdWV1ZSwgZ3JhYiBwcm9w
ZXIgbG9jayBmb3IgZHVtcCBkZWJ1Z2tleQ0KICAqICsgTXVsdGlwbGUgc29ja2V0cw0KICAqICAt
IERldGVjdCBjcHUgbGF5b3V0IGFuZCBtYWtlIHJ1bnF1ZXVlIG1hcCwgb25lIHBlciBMMiAobWFr
ZV9ydW5xX21hcCgpKQ0KICAqICAtIFNpbXBsZSBsb2FkIGJhbGFuY2VyIC8gcnVucXVldWUgYXNz
aWdubWVudA0KQEAgLTE3NTksMTIgKzE3NTcsMTYgQEAgY3NjaGVkX2R1bXBfdmNwdShzdHJ1Y3Qg
Y3NjaGVkX3ZjcHUgKnN2Yw0KIHN0YXRpYyB2b2lkDQogY3NjaGVkX2R1bXBfcGNwdShjb25zdCBz
dHJ1Y3Qgc2NoZWR1bGVyICpvcHMsIGludCBjcHUpDQogew0KKyAgICBzdHJ1Y3QgY3NjaGVkX3By
aXZhdGUgKnBydiA9IENTQ0hFRF9QUklWKG9wcyk7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgKnJ1
bnEsICppdGVyOw0KICAgICBzdHJ1Y3QgY3NjaGVkX3ZjcHUgKnN2YzsNCisgICAgdW5zaWduZWQg
bG9uZyBmbGFnczsNCisgICAgc3BpbmxvY2tfdCAqbG9jazsNCiAgICAgaW50IGxvb3A7DQogICAg
IGNoYXIgY3B1c3RyWzEwMF07DQogDQotICAgIC8qIEZJWE1FOiBEbyBsb2NraW5nIHByb3Blcmx5
IGZvciBhY2Nlc3MgdG8gcnVucXVldWUgc3RydWN0dXJlcyAqLw0KKyAgICAvKiBEb21haW5zJyBw
YXJhbWV0ZXJzIGFyZSBjaGFuZ2VkIHVuZGVyIGNzY2hlZF9wcml2IGxvY2sgKi8NCisgICAgc3Bp
bl9sb2NrX2lycXNhdmUoJnBydi0+bG9jaywgZmxhZ3MpOw0KIA0KICAgICBydW5xID0gJlJRRChv
cHMsIGNwdSktPnJ1bnE7DQogDQpAQCAtMTc3Myw2ICsxNzc1LDEzIEBAIGNzY2hlZF9kdW1wX3Bj
cHUoY29uc3Qgc3RydWN0IHNjaGVkdWxlciANCiAgICAgY3B1bWFza19zY25wcmludGYoY3B1c3Ry
LCBzaXplb2YoY3B1c3RyKSwgcGVyX2NwdShjcHVfY29yZV9tYXNrLCBjcHUpKTsNCiAgICAgcHJp
bnRrKCJjb3JlPSVzXG4iLCBjcHVzdHIpOw0KIA0KKyAgICAvKg0KKyAgICAgKiBXZSBuZWVkIHJ1
bnEgbG9jayBhcyB3ZWxsLCBhbmQgaGVyZSdzIGhvdyB3ZSBnZXQgdG8gaXQNCisgICAgICogZm9y
IHRoZSByZXF1ZXN0ZWQgY3B1Lg0KKyAgICAgKi8NCisgICAgbG9jayA9IHBlcl9jcHUoc2NoZWR1
bGVfZGF0YSwgY3B1KS5zY2hlZHVsZV9sb2NrOw0KKyAgICBzcGluX2xvY2sobG9jayk7DQorDQog
ICAgIC8qIGN1cnJlbnQgVkNQVSAqLw0KICAgICBzdmMgPSBDU0NIRURfVkNQVShwZXJfY3B1KHNj
aGVkdWxlX2RhdGEsIGNwdSkuY3Vycik7DQogICAgIGlmICggc3ZjICkNCkBAIC0xNzkxLDYgKzE4
MDAsOSBAQCBjc2NoZWRfZHVtcF9wY3B1KGNvbnN0IHN0cnVjdCBzY2hlZHVsZXIgDQogICAgICAg
ICAgICAgY3NjaGVkX2R1bXBfdmNwdShzdmMpOw0KICAgICAgICAgfQ0KICAgICB9DQorDQorICAg
IHNwaW5fdW5sb2NrKGxvY2spOw0KKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwcnYtPmxv
Y2ssIGZsYWdzKTsNCiB9DQogDQogc3RhdGljIHZvaWQNCkBAIC0xNzk4LDggKzE4MTAsMTEgQEAg
Y3NjaGVkX2R1bXAoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzKQ0KIHsNCiAgICAgc3RydWN0
IGxpc3RfaGVhZCAqaXRlcl9zZG9tLCAqaXRlcl9zdmM7DQogICAgIHN0cnVjdCBjc2NoZWRfcHJp
dmF0ZSAqcHJ2ID0gQ1NDSEVEX1BSSVYob3BzKTsNCisgICAgdW5zaWduZWQgbG9uZyBmbGFnczsN
CiAgICAgaW50IGksIGxvb3A7DQogDQorICAgIHNwaW5fbG9ja19pcnFzYXZlKCZwcnYtPmxvY2ss
IGZsYWdzKTsNCisNCiAgICAgcHJpbnRrKCJBY3RpdmUgcXVldWVzOiAlZFxuIg0KICAgICAgICAg
ICAgIlx0ZGVmYXVsdC13ZWlnaHQgICAgID0gJWRcbiIsDQogICAgICAgICAgICBjcHVtYXNrX3dl
aWdodCgmcHJ2LT5hY3RpdmVfcXVldWVzKSwNCkBAIC0xODIyLDcgKzE4MzcsNiBAQCBjc2NoZWRf
ZHVtcChjb25zdCBzdHJ1Y3Qgc2NoZWR1bGVyICpvcHMpDQogICAgICAgICAgICAgICAgZnJhY3Rp
b24pOw0KIA0KICAgICB9DQotICAgIC8qIEZJWE1FOiBMb2NraW5nISAqLw0KIA0KICAgICBwcmlu
dGsoIkRvbWFpbiBpbmZvOlxuIik7DQogICAgIGxvb3AgPSAwOw0KQEAgLTE4MzEsMTAgKzE4NDUs
MTAgQEAgY3NjaGVkX2R1bXAoY29uc3Qgc3RydWN0IHNjaGVkdWxlciAqb3BzKQ0KICAgICAgICAg
c3RydWN0IGNzY2hlZF9kb20gKnNkb207DQogICAgICAgICBzZG9tID0gbGlzdF9lbnRyeShpdGVy
X3Nkb20sIHN0cnVjdCBjc2NoZWRfZG9tLCBzZG9tX2VsZW0pOw0KIA0KLSAgICAgICBwcmludGso
Ilx0RG9tYWluOiAlZCB3ICVkIHYgJWRcblx0IiwgDQotICAgICAgICAgICAgICBzZG9tLT5kb20t
PmRvbWFpbl9pZCwgDQotICAgICAgICAgICAgICBzZG9tLT53ZWlnaHQsIA0KLSAgICAgICAgICAg
ICAgc2RvbS0+bnJfdmNwdXMpOw0KKyAgICAgICAgcHJpbnRrKCJcdERvbWFpbjogJWQgdyAlZCB2
ICVkXG5cdCIsIA0KKyAgICAgICAgICAgICAgIHNkb20tPmRvbS0+ZG9tYWluX2lkLCANCisgICAg
ICAgICAgICAgICBzZG9tLT53ZWlnaHQsIA0KKyAgICAgICAgICAgICAgIHNkb20tPm5yX3ZjcHVz
KTsNCiANCiAgICAgICAgIGxpc3RfZm9yX2VhY2goIGl0ZXJfc3ZjLCAmc2RvbS0+dmNwdSApDQog
ICAgICAgICB7DQpAQCAtMTg0Miw5ICsxODU2LDEzIEBAIGNzY2hlZF9kdW1wKGNvbnN0IHN0cnVj
dCBzY2hlZHVsZXIgKm9wcykNCiAgICAgICAgICAgICBzdmMgPSBsaXN0X2VudHJ5KGl0ZXJfc3Zj
LCBzdHJ1Y3QgY3NjaGVkX3ZjcHUsIHNkb21fZWxlbSk7DQogDQogICAgICAgICAgICAgcHJpbnRr
KCJcdCUzZDogIiwgKytsb29wKTsNCisgICAgICAgICAgICB2Y3B1X3NjaGVkdWxlX2xvY2soc3Zj
LT52Y3B1KTsNCiAgICAgICAgICAgICBjc2NoZWRfZHVtcF92Y3B1KHN2Yyk7DQorICAgICAgICAg
ICAgdmNwdV9zY2hlZHVsZV91bmxvY2soc3ZjLT52Y3B1KTsNCiAgICAgICAgIH0NCiAgICAgfQ0K
Kw0KKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCiB9DQog
DQogc3RhdGljIHZvaWQgYWN0aXZhdGVfcnVucXVldWUoc3RydWN0IGNzY2hlZF9wcml2YXRlICpw
cnYsIGludCBycWkpDQpkaWZmIC1yIDE1YWI2MTg2NWVjYiB4ZW4vY29tbW9uL3NjaGVkX3NlZGYu
Yw0KLS0tIGEveGVuL2NvbW1vbi9zY2hlZF9zZWRmLmMJVHVlIEphbiAxNyAxMjo0MDo1MiAyMDEy
ICswMDAwDQorKysgYi94ZW4vY29tbW9uL3NjaGVkX3NlZGYuYwlXZWQgSmFuIDE4IDE1OjAyOjMw
IDIwMTIgKzAwMDANCkBAIC0xMjE5LDEzICsxMjE5LDI1IEBAIHN0YXRpYyB2b2lkIHNlZGZfZHVt
cF9kb21haW4oc3RydWN0IHZjcHUNCiAvKiBEdW1wcyBhbGwgZG9tYWlucyBvbiB0aGUgc3BlY2lm
aWVkIGNwdSAqLw0KIHN0YXRpYyB2b2lkIHNlZGZfZHVtcF9jcHVfc3RhdGUoY29uc3Qgc3RydWN0
IHNjaGVkdWxlciAqb3BzLCBpbnQgaSkNCiB7DQorICAgIHN0cnVjdCBzZWRmX3ByaXZfaW5mbyAq
cHJ2ID0gU0VERl9QUklWKG9wcyk7DQogICAgIHN0cnVjdCBsaXN0X2hlYWQgICAgICAqbGlzdCwg
KnF1ZXVlLCAqdG1wOw0KICAgICBzdHJ1Y3Qgc2VkZl92Y3B1X2luZm8gKmRfaW5mOw0KICAgICBz
dHJ1Y3QgZG9tYWluICAgICAgICAgKmQ7DQogICAgIHN0cnVjdCB2Y3B1ICAgICplZDsNCisgICAg
dW5zaWduZWQgbG9uZyBmbGFnczsNCiAgICAgaW50IGxvb3AgPSAwOw0KKw0KKyAgICAvKiBEb21h
aW5zJyBwYXJhbWV0ZXJzIGFyZSBjaGFuZ2VkIHVuZGVyIHNjaGVkdWxlciBsb2NrICovDQorICAg
IHNwaW5fbG9ja19pcnFzYXZlKCZwcnYtPmxvY2ssIGZsYWdzKTsNCiAgDQogICAgIHByaW50aygi
bm93PSUiUFJJdTY0IlxuIixOT1coKSk7DQorDQorICAgIC8qDQorICAgICAqIFdlIG5lZWQgcnVu
cSBsb2NrIGFzIHdlbGwsIGFuZCBhcyB0aGVyZSdzIG9uZSBydW5xIHBlciBDUFUsDQorICAgICAq
IHRoaXMgaXMgdGhlIGNvcnJlY3Qgb25lIHRvIHRha2UgZm9yIHRoaXMgQ1BVL3J1bnEuDQorICAg
ICAqLw0KKyAgICBwY3B1X3NjaGVkdWxlX2xvY2soaSk7DQorDQogICAgIHF1ZXVlID0gUlVOUShp
KTsNCiAgICAgcHJpbnRrKCJSVU5RIHJxICVseCAgIG46ICVseCwgcDogJWx4XG4iLCAgKHVuc2ln
bmVkIGxvbmcpcXVldWUsDQogICAgICAgICAgICAodW5zaWduZWQgbG9uZykgcXVldWUtPm5leHQs
ICh1bnNpZ25lZCBsb25nKSBxdWV1ZS0+cHJldik7DQpAQCAtMTI4OCw2ICsxMzAwLDkgQEAgc3Rh
dGljIHZvaWQgc2VkZl9kdW1wX2NwdV9zdGF0ZShjb25zdCBzdA0KICAgICAgICAgfQ0KICAgICB9
DQogICAgIHJjdV9yZWFkX3VubG9jaygmZG9tbGlzdF9yZWFkX2xvY2spOw0KKw0KKyAgICBwY3B1
X3NjaGVkdWxlX3VubG9jayhpKTsNCisgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmcHJ2LT5s
b2NrLCBmbGFncyk7DQogfQ0KIA0KIA0KZGlmZiAtciAxNWFiNjE4NjVlY2IgeGVuL2NvbW1vbi9z
Y2hlZHVsZS5jDQotLS0gYS94ZW4vY29tbW9uL3NjaGVkdWxlLmMJVHVlIEphbiAxNyAxMjo0MDo1
MiAyMDEyICswMDAwDQorKysgYi94ZW4vY29tbW9uL3NjaGVkdWxlLmMJV2VkIEphbiAxOCAxNTow
MjozMCAyMDEyICswMDAwDQpAQCAtMTQxNyw2ICsxNDE3LDcgQEAgdm9pZCBzY2hlZHVsZV9kdW1w
KHN0cnVjdCBjcHVwb29sICpjKQ0KICAgICBzdHJ1Y3Qgc2NoZWR1bGVyICpzY2hlZDsNCiAgICAg
Y3B1bWFza190ICAgICAgICAqY3B1czsNCiANCisgICAgLyogUHJvcGVyIGxvY2tpbmcgaXMgcHJv
dmlkZWQgYnkgZWFjaCBzY2hlZHVsZXIgKi8NCiAgICAgc2NoZWQgPSAoYyA9PSBOVUxMKSA/ICZv
cHMgOiBjLT5zY2hlZDsNCiAgICAgY3B1cyA9IChjID09IE5VTEwpID8gJmNwdXBvb2xfZnJlZV9j
cHVzIDogYy0+Y3B1X3ZhbGlkOw0KICAgICBwcmludGsoIlNjaGVkdWxlcjogJXMgKCVzKVxuIiwg
c2NoZWQtPm5hbWUsIHNjaGVkLT5vcHRfbmFtZSk7DQpAQCAtMTQyNCwxMCArMTQyNSw4IEBAIHZv
aWQgc2NoZWR1bGVfZHVtcChzdHJ1Y3QgY3B1cG9vbCAqYykNCiANCiAgICAgZm9yX2VhY2hfY3B1
IChpLCBjcHVzKQ0KICAgICB7DQotICAgICAgICBwY3B1X3NjaGVkdWxlX2xvY2soaSk7DQogICAg
ICAgICBwcmludGsoIkNQVVslMDJkXSAiLCBpKTsNCiAgICAgICAgIFNDSEVEX09QKHNjaGVkLCBk
dW1wX2NwdV9zdGF0ZSwgaSk7DQotICAgICAgICBwY3B1X3NjaGVkdWxlX3VubG9jayhpKTsNCiAg
ICAgfQ0KIH0NCiANCg==


--=-Sn+NDJR3EWzB5LTDsO7k--

--=-ApW/FEYJ2HeKXZmm9mdH
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)

iEYEABECAAYFAk8W8lYACgkQk4XaBE3IOsTCcwCfSpGD3WpfK5+Jh5cHvwInLWAV
frEAnjm6dykd9QSapwJcKL9cF2dMarti
=dxJj
-----END PGP SIGNATURE-----

--=-ApW/FEYJ2HeKXZmm9mdH--



--===============6363075103574912662==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6363075103574912662==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:29:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYNQ-00068n-Ez; Wed, 18 Jan 2012 16:28:44 +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 1RnYNP-00068B-04
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:28:43 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326904115!11589606!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 13234 invoked from network); 18 Jan 2012 16:28:36 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 16:28:36 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74600057; Wed, 18 Jan 2012 17:28:34 +0100
Message-ID: <1326904090.5856.38.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 18 Jan 2012 17:28:10 +0100
In-Reply-To: <4F16FFC5020000780006D81B@nat28.tlf.novell.com>
References: <1326903221.5856.33.camel@Solace>
	<4F16FFC5020000780006D81B@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 1] sched: rework locking for dump
 debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2188856745878072799=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2188856745878072799==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-g0S3QTMhboxGAWUkF+WZ"


--=-g0S3QTMhboxGAWUkF+WZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-18 at 16:22 +0000, Jan Beulich wrote:
> > I think this patch correctly deals with locking in this specific case,
> > but of course I'm happy to hear what you think! :-)
>=20
> Forgot to include/attach the patch?
>=20
No, it's coming but you're right, my "submission machinery" definitely
need some refinements! :-)

Will do that ASAP, as I expect to start submitting more complex series
in the coming period, and this method I'm using now does not scale.

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)


--=-g0S3QTMhboxGAWUkF+WZ
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)

iEYEABECAAYFAk8W8xoACgkQk4XaBE3IOsQm/QCfRsuF3DNBKa407Y5FlVFs+2Sr
+hAAoKRfkCLdquhyRUdpG9O6YRfKLh6m
=342Z
-----END PGP SIGNATURE-----

--=-g0S3QTMhboxGAWUkF+WZ--



--===============2188856745878072799==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2188856745878072799==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:29:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYNQ-00068n-Ez; Wed, 18 Jan 2012 16:28:44 +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 1RnYNP-00068B-04
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:28:43 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326904115!11589606!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 13234 invoked from network); 18 Jan 2012 16:28:36 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-14.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 16:28:36 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.40]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74600057; Wed, 18 Jan 2012 17:28:34 +0100
Message-ID: <1326904090.5856.38.camel@Solace>
From: Dario Faggioli <raistlin@linux.it>
To: Jan Beulich <JBeulich@suse.com>
Date: Wed, 18 Jan 2012 17:28:10 +0100
In-Reply-To: <4F16FFC5020000780006D81B@nat28.tlf.novell.com>
References: <1326903221.5856.33.camel@Solace>
	<4F16FFC5020000780006D81B@nat28.tlf.novell.com>
X-Mailer: Evolution 3.2.2-1 
Mime-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 0 of 1] sched: rework locking for dump
 debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2188856745878072799=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============2188856745878072799==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-g0S3QTMhboxGAWUkF+WZ"


--=-g0S3QTMhboxGAWUkF+WZ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-18 at 16:22 +0000, Jan Beulich wrote:
> > I think this patch correctly deals with locking in this specific case,
> > but of course I'm happy to hear what you think! :-)
>=20
> Forgot to include/attach the patch?
>=20
No, it's coming but you're right, my "submission machinery" definitely
need some refinements! :-)

Will do that ASAP, as I expect to start submitting more complex series
in the coming period, and this method I'm using now does not scale.

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)


--=-g0S3QTMhboxGAWUkF+WZ
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)

iEYEABECAAYFAk8W8xoACgkQk4XaBE3IOsQm/QCfRsuF3DNBKa407Y5FlVFs+2Sr
+hAAoKRfkCLdquhyRUdpG9O6YRfKLh6m
=342Z
-----END PGP SIGNATURE-----

--=-g0S3QTMhboxGAWUkF+WZ--



--===============2188856745878072799==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2188856745878072799==--



From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:29:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnYNr-0006CP-Ta; Wed, 18 Jan 2012 16:29: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 1RnYNq-0006BZ-6T
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:29:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326904142!1610943!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8318 invoked from network); 18 Jan 2012 16:29:02 -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;
	18 Jan 2012 16:29:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10121244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 16:29: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; Wed, 18 Jan 2012 16:29: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 1RnYNh-0005wO-Mx;
	Wed, 18 Jan 2012 16:29:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnYNh-0000wv-B5;
	Wed, 18 Jan 2012 16:29:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10877-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 16:29:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10877: 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 10877 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10877/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10870
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10870
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10870
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                    fail pass in 10859
 test-amd64-amd64-xl-win       5 xen-boot           fail in 10870 pass in 10877

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10769
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   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-xend-winxpsp3 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-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore    fail in 10870 never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore   fail in 10870 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10870 never pass
 test-amd64-i386-xl-credit2   15 guest-stop            fail in 10859 never pass
 test-amd64-amd64-xl-sedf     15 guest-stop            fail in 10859 never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 10859 never pass

version targeted for testing:
 xen                  271e30252c16
baseline version:
 xen                  d5b26918cd94

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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=271e30252c16
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 271e30252c16
+ branch=xen-4.0-testing
+ revision=271e30252c16
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 271e30252c16 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:29:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnYNr-0006CP-Ta; Wed, 18 Jan 2012 16:29: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 1RnYNq-0006BZ-6T
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:29:10 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326904142!1610943!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8318 invoked from network); 18 Jan 2012 16:29:02 -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;
	18 Jan 2012 16:29:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10121244"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 16:29: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; Wed, 18 Jan 2012 16:29: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 1RnYNh-0005wO-Mx;
	Wed, 18 Jan 2012 16:29:01 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnYNh-0000wv-B5;
	Wed, 18 Jan 2012 16:29:01 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10877-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 16:29:01 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.0-testing test] 10877: 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 10877 xen-4.0-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10877/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10870
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10870
 test-amd64-amd64-win         14 guest-start.2               fail pass in 10870
 test-amd64-amd64-xl-winxpsp3  5 xen-boot                    fail pass in 10859
 test-amd64-amd64-xl-win       5 xen-boot           fail in 10870 pass in 10877

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-credit2    5 xen-boot                     fail   like 10769
 test-amd64-amd64-xl-sedf      5 xen-boot                     fail   like 10769

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  8 debian-fixup                fail never pass
 test-amd64-i386-xl-multivcpu 15 guest-stop                   fail   never pass
 test-amd64-i386-xl           15 guest-stop                   fail   never pass
 test-amd64-amd64-xl-sedf-pin 15 guest-stop                   fail   never pass
 test-amd64-amd64-xl          15 guest-stop                   fail   never pass
 test-i386-i386-xl            15 guest-stop                   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-xend-winxpsp3 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-amd64-xl-win       7 windows-install              fail   never pass
 test-i386-i386-xl-win         7 windows-install              fail   never pass
 test-amd64-i386-xl-win-vcpus1  7 windows-install              fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install          fail never pass
 test-i386-i386-xl-winxpsp3    7 windows-install              fail   never pass
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore    fail in 10870 never pass
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore   fail in 10870 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 10870 never pass
 test-amd64-i386-xl-credit2   15 guest-stop            fail in 10859 never pass
 test-amd64-amd64-xl-sedf     15 guest-stop            fail in 10859 never pass
 test-amd64-amd64-xl-winxpsp3  7 windows-install       fail in 10859 never pass

version targeted for testing:
 xen                  271e30252c16
baseline version:
 xen                  d5b26918cd94

------------------------------------------------------------
People who touched revisions under test:
  Christoph Egger <Christoph.Egger@amd.com>
  David Vrabel <david.vrabel@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Yongan Liu<Liuyongan@huawei.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          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=271e30252c16
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 271e30252c16
+ branch=xen-4.0-testing
+ revision=271e30252c16
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 271e30252c16 ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.0-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:36:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16:36:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYUI-0006oO-0k; Wed, 18 Jan 2012 16:35: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 1RnYUH-0006oB-2f
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:35:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326904542!11021923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31848 invoked from network); 18 Jan 2012 16:35:43 -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;
	18 Jan 2012 16:35:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10121391"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 16:35: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;
	Wed, 18 Jan 2012 16:35:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 16:35:42 +0000
In-Reply-To: <1326482728-10733-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326904542.14689.258.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/9] 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, 2012-01-13 at 19:25 +0000, 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          |   30 ++
>  tools/libxl/libxl.h          |    6 +
>  tools/libxl/libxl_event.c    |  750 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_event.h    |  205 ++++++++++++
>  tools/libxl/libxl_internal.h |  277 +++++++++++++++-
>  6 files changed, 1267 insertions(+), 3 deletions(-)
>  create mode 100644 tools/libxl/libxl_event.c
>  create mode 100644 tools/libxl/libxl_event.h

[...]
> @@ -109,6 +110,71 @@ _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__egc libxl__egc;
> +
> +typedef struct libxl__ev_fd libxl__ev_fd;
> +typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents);
> +struct libxl__ev_fd {
> +    /* caller should include this in their own struct */
> +    /* read-only for caller, who may read only when registered: */
> +    int fd;
> +    short events;
> +    libxl__ev_fd_callback *func;

Are there actually cases where a caller would want to read these?

The most obvious case would be in the callback but it already gets given
all three there.

Not suggesting we disallow this I'm just curious.

> +    /* remainder is private for libxl__ev_fd... */
> +    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
> +    void *for_app_reg;
> +};
[...]

> + *   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

                                                        will

> + *      called by the event machinery in future.  FUNC will
> + *      not be called from within the call to _register.
> + *      FUNC will be called with the context locked (with CTX_LOCK).
[...]

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 Wed Jan 18 16:36:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16:36:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYUI-0006oO-0k; Wed, 18 Jan 2012 16:35: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 1RnYUH-0006oB-2f
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:35:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326904542!11021923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31848 invoked from network); 18 Jan 2012 16:35:43 -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;
	18 Jan 2012 16:35:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10121391"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 16:35: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;
	Wed, 18 Jan 2012 16:35:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 16:35:42 +0000
In-Reply-To: <1326482728-10733-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326904542.14689.258.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/9] 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, 2012-01-13 at 19:25 +0000, 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          |   30 ++
>  tools/libxl/libxl.h          |    6 +
>  tools/libxl/libxl_event.c    |  750 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_event.h    |  205 ++++++++++++
>  tools/libxl/libxl_internal.h |  277 +++++++++++++++-
>  6 files changed, 1267 insertions(+), 3 deletions(-)
>  create mode 100644 tools/libxl/libxl_event.c
>  create mode 100644 tools/libxl/libxl_event.h

[...]
> @@ -109,6 +110,71 @@ _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__egc libxl__egc;
> +
> +typedef struct libxl__ev_fd libxl__ev_fd;
> +typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
> +                                   int fd, short events, short revents);
> +struct libxl__ev_fd {
> +    /* caller should include this in their own struct */
> +    /* read-only for caller, who may read only when registered: */
> +    int fd;
> +    short events;
> +    libxl__ev_fd_callback *func;

Are there actually cases where a caller would want to read these?

The most obvious case would be in the callback but it already gets given
all three there.

Not suggesting we disallow this I'm just curious.

> +    /* remainder is private for libxl__ev_fd... */
> +    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
> +    void *for_app_reg;
> +};
[...]

> + *   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

                                                        will

> + *      called by the event machinery in future.  FUNC will
> + *      not be called from within the call to _register.
> + *      FUNC will be called with the context locked (with CTX_LOCK).
[...]

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 Wed Jan 18 16:44:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnYbl-00074i-0F; Wed, 18 Jan 2012 16:43:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RnYbj-00074c-Eb
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:43:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326905005!11540769!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 12663 invoked from network); 18 Jan 2012 16:43:25 -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; 18 Jan 2012 16:43:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 16:43:25 +0000
Message-Id: <4F1704BA020000780006D84A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 16:43:22 +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/i386: don't select X86_UP_{,
	IO}APIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 introduced while converting the Linux tree to sub-arch layout
(8706:fd9b2c1bb577), albeit that change was completely unrelated to the
subject of that c/s, and not explained either.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -108,8 +108,6 @@ config X86_XEN
 	bool "Xen-compatible"
 	select XEN
 	select X86_PAE
-	select X86_UP_APIC if !SMP && XEN_PRIVILEGED_GUEST
-	select X86_UP_IOAPIC if !SMP && XEN_PRIVILEGED_GUEST
 	select SWIOTLB
 	help
 	  Choose this option if you plan to run this kernel on top of the




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:44:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnYbl-00074i-0F; Wed, 18 Jan 2012 16:43:33 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RnYbj-00074c-Eb
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:43:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326905005!11540769!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 12663 invoked from network); 18 Jan 2012 16:43:25 -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; 18 Jan 2012 16:43:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 18 Jan 2012 16:43:25 +0000
Message-Id: <4F1704BA020000780006D84A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 18 Jan 2012 16:43:22 +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/i386: don't select X86_UP_{,
	IO}APIC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 introduced while converting the Linux tree to sub-arch layout
(8706:fd9b2c1bb577), albeit that change was completely unrelated to the
subject of that c/s, and not explained either.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -108,8 +108,6 @@ config X86_XEN
 	bool "Xen-compatible"
 	select XEN
 	select X86_PAE
-	select X86_UP_APIC if !SMP && XEN_PRIVILEGED_GUEST
-	select X86_UP_IOAPIC if !SMP && XEN_PRIVILEGED_GUEST
 	select SWIOTLB
 	help
 	  Choose this option if you plan to run this kernel on top of the




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:54:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnYlg-0007Pb-9s; Wed, 18 Jan 2012 16:53:48 +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 1RnYle-0007PT-GE
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:53:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326905618!9672334!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk4NTkw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16137 invoked from network); 18 Jan 2012 16:53:40 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 16:53:40 -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
	q0IGradj031435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Jan 2012 16:53:36 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
	q0IGrZ9O008264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Jan 2012 16:53:35 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
	q0IGrXOK029985; Wed, 18 Jan 2012 10:53:33 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 18 Jan 2012 08:53:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8911240307; Wed, 18 Jan 2012 11:51:30 -0500 (EST)
Date: Wed, 18 Jan 2012 11:51:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: david.vrabel@citrix.com, tom.goetz@virtualcomputer.com,
	xen-devel@lists.xensource.com
Message-ID: <20120118165130.GC24089@phenom.dumpdata.com>
References: <1CB9139E-4600-4DBD-8F96-9061675DE9C2@virtualcomputer.com>
	<20120117210904.GB23782@phenom.dumpdata.com>
	<6EF87F6D-AD48-4DA9-BAD8-2FCB2C980C04@virtualcomputer.com>
	<20120118163456.GA24089@phenom.dumpdata.com>
	<79E94C03-B65F-4882-A744-EE6F27AF6C0D@virtualcomputer.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <79E94C03-B65F-4882-A744-EE6F27AF6C0D@virtualcomputer.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.4F16F911.0032,ss=1,re=-2.300,fgs=0
Subject: Re: [Xen-devel] 3.2 PVOPs Intel Crash
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 18, 2012 at 11:41:22AM -0500, Tom Goetz wrote:

CC-ing xen-devel and David.

> We have dom0_mem=672MB for Xen and mem=672MB for linux.

Ok, if you don't have the mem=X and have the "('x86: use 'dom0_mem' to limit
the number of pages for dom0') (c/s 23790) in your hypervisor what happens?

And also have 'dom0_mem=max:672MB' do you get the same issue?

> 
> [ 0.000000] e820 remove range: 000000002a000000 - ffffffffffffffff (usable) 
> 
> appears to come from 
> 
> static int __init parse_memopt(char *p) 
> { 
>         u64 mem_size; 
> 
>         if (!p) 
>                 return -EINVAL; 
> 
>         if (!strcmp(p, "nopentium")) { 
> #ifdef CONFIG_X86_32 
>                 setup_clear_cpu_cap(X86_FEATURE_PSE); 
>                 return 0; 
> #else 
>                 printk(KERN_WARNING "mem=nopentium ignored! (only supported on x86_32)\n"); 
>                 return -EINVAL; 
> #endif 
>         } 
> 
>         userdef = 1; 
>         mem_size = memparse(p, &p); 
>         /* don't remove all of memory when handling "mem={invalid}" param */ 
>         if (mem_size == 0) 
>                 return -EINVAL; 
>         e820_remove_range(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1); <----------------------------- 
> 
>         return 0; 
> } 
> early_param("mem", parse_memopt); 
> 
> but we have the same mem opt for 2.6.38 and 3.2 and the mem code still has the e820_remove_range in 3.2. Dom0 is showing the right amount of mem when booted on other machines, so I don't think the mem= option is failing. 

The 'mem=X' argument I remember being a work-around. The original bug had been fixed in both
hypervisor and in the kernel.


> 
> I'm taking a break for lunch now and I'll did in further on the mem= option after.
> 
> On Jan 18, 2012, at 11:34 AM, Konrad Rzeszutek Wilk wrote:
> 
> > On Wed, Jan 18, 2012 at 11:02:48AM -0500, Tom Goetz wrote:
> >> The E820s are different:
> >> 
> >> Xen E820: 
> >> 
> >> (XEN) Xen-e820 RAM map: 
> >> (XEN) 0000000000000000 - 000000000009f000 (usable) 
> >> (XEN) 000000000009f000 - 00000000000a0000 (reserved) 
> >> (XEN) 0000000000100000 - 00000000bf65b800 (usable) 
> >> (XEN) 00000000bf65b800 - 00000000c0000000 (reserved) 
> >> (XEN) 00000000f8000000 - 00000000fc000000 (reserved) 
> >> (XEN) 00000000fec00000 - 00000000fec10000 (reserved) 
> >> (XEN) 00000000fed18000 - 00000000fed1c000 (reserved) 
> >> (XEN) 00000000fed20000 - 00000000fed90000 (reserved) 
> >> (XEN) 00000000feda0000 - 00000000feda6000 (reserved) 
> >> (XEN) 00000000fee00000 - 00000000fee10000 (reserved) 
> >> (XEN) 00000000ffe00000 - 0000000100000000 (reserved) 
> >> 
> >> 2.6.38 E820: 
> >> 
> >> [ 0.000000] BIOS-provided physical RAM map: 
> >> [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable) 
> >> [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved) 
> >> [ 0.000000] Xen: 0000000000100000 - 000000002a000000 (usable) 
> >> [ 0.000000] Xen: 000000002a000000 - 00000000bf65b000 (unusable) 
> > 
> > Good. That is correct.
> > 
> >> [ 0.000000] Xen: 00000000bf65b800 - 00000000c0000000 (reserved) 
> >> [ 0.000000] Xen: 00000000f8000000 - 00000000fc000000 (reserved) 
> >> [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved) 
> >> [ 0.000000] Xen: 00000000fed18000 - 00000000fed1c000 (reserved) 
> >> [ 0.000000] Xen: 00000000fed20000 - 00000000fed90000 (reserved) 
> >> [ 0.000000] Xen: 00000000feda0000 - 00000000feda6000 (reserved) 
> >> [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved) 
> >> [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) 
> >> [ 0.000000] Xen: 0000000100000000 - 000000019565b000 (usable) 
> >> [ 0.000000] e820 remove range: 000000002a000000 - ffffffffffffffff (usable) 
> >> [ 0.000000] NX (Execute Disable) protection: active 
> >> [ 0.000000] user-defined physical RAM map: 
> >> [ 0.000000] user: 0000000000000000 - 000000000009f000 (usable)       - 1
> >> [ 0.000000] user: 000000000009f000 - 0000000000100000 (reserved)    - 2
> >> [ 0.000000] user: 0000000000100000 - 000000002a000000 (usable)      - 3
> >> [ 0.000000] user: 000000002a000000 - 00000000bf65b000 (unusable)   - 4 <------------   This isn't in the Xen version either.
> > 
> > Yup, that is OK. We want that region to be mapped as 'unusable'.
> > 
> > That will make the intel-agp code _not_ use that region (which we
> > should not as that is a RAM region).
> > 
> >> [ 0.000000] user: 00000000bf65b800 - 00000000c0000000 (reserved)    - 5
> >> [ 0.000000] user: 00000000f8000000 - 00000000fc000000 (reserved)     - 6
> >> [ 0.000000] user: 00000000fec00000 - 00000000fec10000 (reserved)      - 7
> >> [ 0.000000] user: 00000000fed18000 - 00000000fed1c000 (reserved)     - 8 
> >> [ 0.000000] user: 00000000fed20000 - 00000000fed90000 (reserved)      - 9
> >> [ 0.000000] user: 00000000feda0000 - 00000000feda6000 (reserved)     - 10
> >> [ 0.000000] user: 00000000fee00000 - 00000000fee10000 (reserved)     - 11
> >> [ 0.000000] user: 00000000ffe00000 - 0000000100000000 (reserved)     - 12
> >> [ 0.000000] DMI 2.4 present. 
> >> [ 0.000000] DMI: Dell Inc. Latitude D830 /0HN341, BIOS A05 11/05/2007 
> >> [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)    <---- 3.2 is also missing these lines
> >> [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) 
> >> 
> >> 
> >> 3.2 E820: 
> >> 
> >> [ 0.000000] Set 264710 page(s) to 1-1 mapping 
> >> 
> >> [ 0.000000] BIOS-provided physical RAM map: 
> >> [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable) 
> >> [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved) 
> >> [ 0.000000] Xen: 0000000000100000 - 00000000bf65b000 (usable) 
> > 
> > So here, we should have had the
> > 
> > 2a000 -> bf65b marked as unsuable. 

On a second thought that is OK too. The 2a00->bf65b will
protect the region from being slurped up by the PCI as "gap" region.
> > 
> > You booted the kernel with the same dom0_mem=X argument right?
> > 
> >> [ 0.000000] Xen: 00000000bf65b800 - 00000000c0000000 (reserved) 
> >> [ 0.000000] Xen: 00000000f8000000 - 00000000fc000000 (reserved) 
> >> [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved) 
> >> [ 0.000000] Xen: 00000000fed18000 - 00000000fed1c000 (reserved) 
> >> [ 0.000000] Xen: 00000000fed20000 - 00000000fed90000 (reserved) 
> >> [ 0.000000] Xen: 00000000feda0000 - 00000000feda6000 (reserved) 
> >> [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved) 
> >> [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) 
> >> [ 0.000000] NX (Execute Disable) protection: active 
> >> 
> >> [ 0.000000] user-defined physical RAM map: 
> >> [ 0.000000] user: 0000000000000000 - 000000000009f000 (usable)        - 1
> >> [ 0.000000] user: 000000000009f000 - 0000000000100000 (reserved)    - 2
> >> [ 0.000000] user: 0000000000100000 - 000000002a000000 (usable)      - 3

Ah, and this now punches the E820 with 2a000->bf65b as a "gap" and
it ends up being used by the PCI subsystem.

That is the problem. So ... can you make sure you have that
hypervisor fix in and boot it without 'mem' and see what the E820 comes out as?

Thanks!
> >> [ 0.000000] user: 00000000bf65b800 - 00000000c0000000 (reserved)     - 5
> >> [ 0.000000] user: 00000000f8000000 - 00000000fc000000 (reserved)      - 6
> >> [ 0.000000] user: 00000000fec00000 - 00000000fec10000 (reserved)      - 7
> >> [ 0.000000] user: 00000000fed18000 - 00000000fed1c000 (reserved)      - 8
> >> [ 0.000000] user: 00000000fed20000 - 00000000fed90000 (reserved)      - 9
> >> [ 0.000000] user: 00000000feda0000 - 00000000feda6000 (reserved)     - 10
> >> [ 0.000000] user: 00000000fee00000 - 00000000fee10000 (reserved)     - 11
> >> [ 0.000000] user: 00000000ffe00000 - 0000000100000000 (reserved)     - 12
> >> 
> >> On Jan 17, 2012, at 4:09 PM, Konrad Rzeszutek Wilk wrote:
> >> 
> >>> On Tue, Jan 17, 2012 at 03:58:11PM -0500, Tom Goetz wrote:
> >>>> Konrad,
> >>>> 
> >>>> We're seeing a crash on an Intel video Core2Duo. The crash looks similar to this one: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726. The last comment gives a commit ID for a fix. I don't find that commit in any of our trees. Do you know anything about this?
> >>> 
> >>> Yes. It was 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
> >>> 
> >>> but that was a fix in 2.6.39 (I think) and you are using 3.2.
> >>> 
> >>> Which could be releated to the fact that in 3.2 the E820 code
> >>> (arch/x86/xen/setup.c) went through some surgery to make it easier.
> >>> 
> >>> But the code in it looks like it handles it correctly. Hm,
> >>> any chance you can see what the Xen E820 looks in 3.2 vs anything
> >>> before v3.2?
> >>> 
> >>>> 
> >>>> Thanks for any help,
> >>>> 
> >>>> Tom
> >>>> 
> >>>> Dom0 mem was restricted to 672MB. The machine has 3GB.
> >>>> 
> >>>> 
> >>>> [ 2.463600] agpgart-intel 0000:00:00.0: Intel 965GM Chipset^M 
> >>>> (XEN) mm.c:878:d0 Error getting mfn 30600 (pfn 5555555555555555) from L1 entry 8000000030600473 for l1e_owner=0, pg_owner=0 
> >>>> (XEN) mm.c:4664:d0 ptwr_emulate: could not get_page_from_l1e() 
> >>>> [ 2.463891] BUG: unable to handle kernel paging request at ffff880023f28c30^M 
> >>>> [ 2.463904] IP: [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M 
> >>>> [ 2.463921] PGD 1a06067 PUD 1a0a067 PMD 209d067 PTE 8010000023f28065^M 
> >>>> [ 2.463934] Oops: 0003 [#1] SMP ^M 
> >>>> [ 2.463943] CPU 1 ^M 
> >>>> [ 2.463946] Modules linked in: intel_agp(+) intel_gtt^M 
> >>>> [ 2.463957] ^M 
> >>>> [ 2.463961] Pid: 128, comm: modprobe Not tainted 3.2.1-orc #102 Dell Inc. Latitude D830 /0HN341^M 
> >>>> [ 2.463974] RIP: e030:[<ffffffff81008bee>] [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M 
> >>>> [ 2.463984] RSP: e02b:ffff880004b91ac8 EFLAGS: 00010297^M 
> >>>> [ 2.463990] RAX: 0000000000000000 RBX: 8000000030600473 RCX: 8000000030600473^M 
> >>>> [ 2.463996] RDX: 0000000000000000 RSI: ffffc90000186000 RDI: ffffffff81a38020^M 
> >>>> [ 2.464002] RBP: ffff880004b91b18 R08: ffff880004d87d80 R09: 00000000000000d0^M 
> >>>> [ 2.464009] R10: ffffe8ffffffffff R11: ffffc90000000000 R12: ffff880023f28c30^M 
> >>>> [ 2.464015] R13: 0000000000030600 R14: ffff880023f28c30 R15: ffffc90000187000^M 
> >>>> [ 2.464024] FS: 00007f11b34db720(0000) GS:ffff880029fd1000(0000) knlGS:0000000000000000^M 
> >>>> [ 2.464031] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b^M 
> >>>> [ 2.464037] CR2: ffff880023f28c30 CR3: 0000000004bf1000 CR4: 0000000000002660^M 
> >>>> [ 2.464044] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000^M 
> >>>> [ 2.464050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400^M 
> >>>> [ 2.464057] Process modprobe (pid: 128, threadinfo ffff880004b90000, task ffff880004ac96b0)^M 
> >>>> [ 2.464063] Stack:^M 
> >>>> [ 2.464067] ffffc90000186000 ffffffff81a38020 ffffffff810051ed ffffc90000000000^M 
> >>>> [ 2.464079] ffffe8ffffffffff ffffc90000186000 ffff880023f28c30 0000000000030600^M 
> >>>> [ 2.464091] 8000000000000573 ffffc90000187000 ffff880004b91bc8 ffffffff812b01e4^M 
> >>>> [ 2.464104] Call Trace:^M 
> >>>> [ 2.464111] [<ffffffff810051ed>] ? __raw_callee_save_xen_make_pte+0x11/0x1e^M 
> >>>> [ 2.464121] [<ffffffff812b01e4>] ioremap_page_range+0x214/0x2f0^M 
> >>>> [ 2.464130] [<ffffffff8113b6a2>] ? insert_vmalloc_vmlist+0x22/0x80^M 
> >>>> [ 2.464140] [<ffffffff8103dc43>] __ioremap_caller+0x283/0x390^M 
> >>>> [ 2.464149] [<ffffffffa000070a>] ? i9xx_setup+0x20a/0x2e0 [intel_gtt]^M 
> >>>> [ 2.464158] [<ffffffff81579cee>] ? _raw_spin_unlock_irqrestore+0x1e/0x30^M 
> >>>> [ 2.464166] [<ffffffff8103dda7>] ioremap_nocache+0x17/0x20^M 
> >>>> [ 2.464173] [<ffffffffa000070a>] i9xx_setup+0x20a/0x2e0 [intel_gtt]^M 
> >>>> [ 2.464181] [<ffffffffa0001739>] intel_gmch_probe+0x369/0xa08 [intel_gtt]^M 
> >>>> [ 2.464190] [<ffffffffa0009e8a>] agp_intel_probe+0x48/0x19f [intel_agp]^M 
> >>>> [ 2.464198] [<ffffffff812d794c>] local_pci_probe+0x5c/0xd0^M 
> >>>> [ 2.464205] [<ffffffff812d9201>] pci_device_probe+0x101/0x120^M 
> >>>> [ 2.464214] [<ffffffff81392f5e>] driver_probe_device+0x7e/0x1b0^M 
> >>>> [ 2.464222] [<ffffffff8139313b>] __driver_attach+0xab/0xb0^M 
> >>>> [ 2.464229] [<ffffffff81393090>] ? driver_probe_device+0x1b0/0x1b0^M 
> >>>> [ 2.464236] [<ffffffff81393090>] ? driver_probe_device+0x1b0/0x1b0^M 
> >>>> [ 2.464244] [<ffffffff81391f1c>] bus_for_each_dev+0x5c/0x90^M 
> >>>> [ 2.464252] [<ffffffff81392bee>] driver_attach+0x1e/0x20^M 
> >>>> [ 2.464259] [<ffffffff81392840>] bus_add_driver+0x1a0/0x270^M 
> >>>> [ 2.464266] [<ffffffffa000d000>] ? 0xffffffffa000cfff^M 
> >>>> [ 2.464273] [<ffffffff813936a6>] driver_register+0x76/0x140^M 
> >>>> [ 2.464280] [<ffffffff8157d89d>] ? notifier_call_chain+0x4d/0x70^M 
> >>>> [ 2.464287] [<ffffffffa000d000>] ? 0xffffffffa000cfff^M 
> >>>> [ 2.464294] [<ffffffff812d8ed5>] __pci_register_driver+0x55/0xd0^M 
> >>>> [ 2.464303] [<ffffffff81089173>] ? __blocking_notifier_call_chain+0x63/0x80^M 
> >>>> [ 2.464312] [<ffffffffa000d02c>] agp_intel_init+0x2c/0x2e [intel_agp]^M 
> >>>> [ 2.464320] [<ffffffff81002040>] do_one_initcall+0x40/0x180^M 
> >>>> [ 2.464328] [<ffffffff810a0561>] sys_init_module+0x91/0x200^M 
> >>>> [ 2.464336] [<ffffffff81581b02>] system_call_fastpath+0x16/0x1b^M 
> >>>> [ 2.464341] Code: e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 48 89 7d b8 48 89 75 b0 49 89 d6 48 89 cb 66 66 66 66 90 e8 57 1b 03 00 83 f8 01 74 75 <49> 89 1e 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0 4c 8b ^M 
> >>>> [ 2.464450] RIP [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M 
> >>>> [ 2.464459] RSP <ffff880004b91ac8>^M 
> >>>> [ 2.464463] CR2: ffff880023f28c30^M 
> >>>> [ 2.464469] ---[ end trace 5223388e4a422cb4 ]---^M 
> >>>> 
> >>>> 
> >>>> ---
> >>>> Tom Goetz
> >>>> tom.goetz@virtualcomputer.com
> >>>> 
> >>>> 
> >> 
> >> ---
> >> Tom Goetz
> >> tom.goetz@virtualcomputer.com
> >> 
> >> 
> >> 
> 
> ---
> Tom Goetz
> tom.goetz@virtualcomputer.com
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 16:54:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 16: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 1RnYlg-0007Pb-9s; Wed, 18 Jan 2012 16:53:48 +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 1RnYle-0007PT-GE
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 16:53:47 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326905618!9672334!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk4NTkw\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16137 invoked from network); 18 Jan 2012 16:53:40 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 16:53:40 -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
	q0IGradj031435
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Jan 2012 16:53:36 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
	q0IGrZ9O008264
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Jan 2012 16:53:35 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
	q0IGrXOK029985; Wed, 18 Jan 2012 10:53:33 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 18 Jan 2012 08:53:33 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8911240307; Wed, 18 Jan 2012 11:51:30 -0500 (EST)
Date: Wed, 18 Jan 2012 11:51:30 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: david.vrabel@citrix.com, tom.goetz@virtualcomputer.com,
	xen-devel@lists.xensource.com
Message-ID: <20120118165130.GC24089@phenom.dumpdata.com>
References: <1CB9139E-4600-4DBD-8F96-9061675DE9C2@virtualcomputer.com>
	<20120117210904.GB23782@phenom.dumpdata.com>
	<6EF87F6D-AD48-4DA9-BAD8-2FCB2C980C04@virtualcomputer.com>
	<20120118163456.GA24089@phenom.dumpdata.com>
	<79E94C03-B65F-4882-A744-EE6F27AF6C0D@virtualcomputer.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <79E94C03-B65F-4882-A744-EE6F27AF6C0D@virtualcomputer.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.4F16F911.0032,ss=1,re=-2.300,fgs=0
Subject: Re: [Xen-devel] 3.2 PVOPs Intel Crash
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 18, 2012 at 11:41:22AM -0500, Tom Goetz wrote:

CC-ing xen-devel and David.

> We have dom0_mem=672MB for Xen and mem=672MB for linux.

Ok, if you don't have the mem=X and have the "('x86: use 'dom0_mem' to limit
the number of pages for dom0') (c/s 23790) in your hypervisor what happens?

And also have 'dom0_mem=max:672MB' do you get the same issue?

> 
> [ 0.000000] e820 remove range: 000000002a000000 - ffffffffffffffff (usable) 
> 
> appears to come from 
> 
> static int __init parse_memopt(char *p) 
> { 
>         u64 mem_size; 
> 
>         if (!p) 
>                 return -EINVAL; 
> 
>         if (!strcmp(p, "nopentium")) { 
> #ifdef CONFIG_X86_32 
>                 setup_clear_cpu_cap(X86_FEATURE_PSE); 
>                 return 0; 
> #else 
>                 printk(KERN_WARNING "mem=nopentium ignored! (only supported on x86_32)\n"); 
>                 return -EINVAL; 
> #endif 
>         } 
> 
>         userdef = 1; 
>         mem_size = memparse(p, &p); 
>         /* don't remove all of memory when handling "mem={invalid}" param */ 
>         if (mem_size == 0) 
>                 return -EINVAL; 
>         e820_remove_range(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1); <----------------------------- 
> 
>         return 0; 
> } 
> early_param("mem", parse_memopt); 
> 
> but we have the same mem opt for 2.6.38 and 3.2 and the mem code still has the e820_remove_range in 3.2. Dom0 is showing the right amount of mem when booted on other machines, so I don't think the mem= option is failing. 

The 'mem=X' argument I remember being a work-around. The original bug had been fixed in both
hypervisor and in the kernel.


> 
> I'm taking a break for lunch now and I'll did in further on the mem= option after.
> 
> On Jan 18, 2012, at 11:34 AM, Konrad Rzeszutek Wilk wrote:
> 
> > On Wed, Jan 18, 2012 at 11:02:48AM -0500, Tom Goetz wrote:
> >> The E820s are different:
> >> 
> >> Xen E820: 
> >> 
> >> (XEN) Xen-e820 RAM map: 
> >> (XEN) 0000000000000000 - 000000000009f000 (usable) 
> >> (XEN) 000000000009f000 - 00000000000a0000 (reserved) 
> >> (XEN) 0000000000100000 - 00000000bf65b800 (usable) 
> >> (XEN) 00000000bf65b800 - 00000000c0000000 (reserved) 
> >> (XEN) 00000000f8000000 - 00000000fc000000 (reserved) 
> >> (XEN) 00000000fec00000 - 00000000fec10000 (reserved) 
> >> (XEN) 00000000fed18000 - 00000000fed1c000 (reserved) 
> >> (XEN) 00000000fed20000 - 00000000fed90000 (reserved) 
> >> (XEN) 00000000feda0000 - 00000000feda6000 (reserved) 
> >> (XEN) 00000000fee00000 - 00000000fee10000 (reserved) 
> >> (XEN) 00000000ffe00000 - 0000000100000000 (reserved) 
> >> 
> >> 2.6.38 E820: 
> >> 
> >> [ 0.000000] BIOS-provided physical RAM map: 
> >> [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable) 
> >> [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved) 
> >> [ 0.000000] Xen: 0000000000100000 - 000000002a000000 (usable) 
> >> [ 0.000000] Xen: 000000002a000000 - 00000000bf65b000 (unusable) 
> > 
> > Good. That is correct.
> > 
> >> [ 0.000000] Xen: 00000000bf65b800 - 00000000c0000000 (reserved) 
> >> [ 0.000000] Xen: 00000000f8000000 - 00000000fc000000 (reserved) 
> >> [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved) 
> >> [ 0.000000] Xen: 00000000fed18000 - 00000000fed1c000 (reserved) 
> >> [ 0.000000] Xen: 00000000fed20000 - 00000000fed90000 (reserved) 
> >> [ 0.000000] Xen: 00000000feda0000 - 00000000feda6000 (reserved) 
> >> [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved) 
> >> [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) 
> >> [ 0.000000] Xen: 0000000100000000 - 000000019565b000 (usable) 
> >> [ 0.000000] e820 remove range: 000000002a000000 - ffffffffffffffff (usable) 
> >> [ 0.000000] NX (Execute Disable) protection: active 
> >> [ 0.000000] user-defined physical RAM map: 
> >> [ 0.000000] user: 0000000000000000 - 000000000009f000 (usable)       - 1
> >> [ 0.000000] user: 000000000009f000 - 0000000000100000 (reserved)    - 2
> >> [ 0.000000] user: 0000000000100000 - 000000002a000000 (usable)      - 3
> >> [ 0.000000] user: 000000002a000000 - 00000000bf65b000 (unusable)   - 4 <------------   This isn't in the Xen version either.
> > 
> > Yup, that is OK. We want that region to be mapped as 'unusable'.
> > 
> > That will make the intel-agp code _not_ use that region (which we
> > should not as that is a RAM region).
> > 
> >> [ 0.000000] user: 00000000bf65b800 - 00000000c0000000 (reserved)    - 5
> >> [ 0.000000] user: 00000000f8000000 - 00000000fc000000 (reserved)     - 6
> >> [ 0.000000] user: 00000000fec00000 - 00000000fec10000 (reserved)      - 7
> >> [ 0.000000] user: 00000000fed18000 - 00000000fed1c000 (reserved)     - 8 
> >> [ 0.000000] user: 00000000fed20000 - 00000000fed90000 (reserved)      - 9
> >> [ 0.000000] user: 00000000feda0000 - 00000000feda6000 (reserved)     - 10
> >> [ 0.000000] user: 00000000fee00000 - 00000000fee10000 (reserved)     - 11
> >> [ 0.000000] user: 00000000ffe00000 - 0000000100000000 (reserved)     - 12
> >> [ 0.000000] DMI 2.4 present. 
> >> [ 0.000000] DMI: Dell Inc. Latitude D830 /0HN341, BIOS A05 11/05/2007 
> >> [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)    <---- 3.2 is also missing these lines
> >> [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable) 
> >> 
> >> 
> >> 3.2 E820: 
> >> 
> >> [ 0.000000] Set 264710 page(s) to 1-1 mapping 
> >> 
> >> [ 0.000000] BIOS-provided physical RAM map: 
> >> [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable) 
> >> [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved) 
> >> [ 0.000000] Xen: 0000000000100000 - 00000000bf65b000 (usable) 
> > 
> > So here, we should have had the
> > 
> > 2a000 -> bf65b marked as unsuable. 

On a second thought that is OK too. The 2a00->bf65b will
protect the region from being slurped up by the PCI as "gap" region.
> > 
> > You booted the kernel with the same dom0_mem=X argument right?
> > 
> >> [ 0.000000] Xen: 00000000bf65b800 - 00000000c0000000 (reserved) 
> >> [ 0.000000] Xen: 00000000f8000000 - 00000000fc000000 (reserved) 
> >> [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved) 
> >> [ 0.000000] Xen: 00000000fed18000 - 00000000fed1c000 (reserved) 
> >> [ 0.000000] Xen: 00000000fed20000 - 00000000fed90000 (reserved) 
> >> [ 0.000000] Xen: 00000000feda0000 - 00000000feda6000 (reserved) 
> >> [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved) 
> >> [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved) 
> >> [ 0.000000] NX (Execute Disable) protection: active 
> >> 
> >> [ 0.000000] user-defined physical RAM map: 
> >> [ 0.000000] user: 0000000000000000 - 000000000009f000 (usable)        - 1
> >> [ 0.000000] user: 000000000009f000 - 0000000000100000 (reserved)    - 2
> >> [ 0.000000] user: 0000000000100000 - 000000002a000000 (usable)      - 3

Ah, and this now punches the E820 with 2a000->bf65b as a "gap" and
it ends up being used by the PCI subsystem.

That is the problem. So ... can you make sure you have that
hypervisor fix in and boot it without 'mem' and see what the E820 comes out as?

Thanks!
> >> [ 0.000000] user: 00000000bf65b800 - 00000000c0000000 (reserved)     - 5
> >> [ 0.000000] user: 00000000f8000000 - 00000000fc000000 (reserved)      - 6
> >> [ 0.000000] user: 00000000fec00000 - 00000000fec10000 (reserved)      - 7
> >> [ 0.000000] user: 00000000fed18000 - 00000000fed1c000 (reserved)      - 8
> >> [ 0.000000] user: 00000000fed20000 - 00000000fed90000 (reserved)      - 9
> >> [ 0.000000] user: 00000000feda0000 - 00000000feda6000 (reserved)     - 10
> >> [ 0.000000] user: 00000000fee00000 - 00000000fee10000 (reserved)     - 11
> >> [ 0.000000] user: 00000000ffe00000 - 0000000100000000 (reserved)     - 12
> >> 
> >> On Jan 17, 2012, at 4:09 PM, Konrad Rzeszutek Wilk wrote:
> >> 
> >>> On Tue, Jan 17, 2012 at 03:58:11PM -0500, Tom Goetz wrote:
> >>>> Konrad,
> >>>> 
> >>>> We're seeing a crash on an Intel video Core2Duo. The crash looks similar to this one: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726. The last comment gives a commit ID for a fix. I don't find that commit in any of our trees. Do you know anything about this?
> >>> 
> >>> Yes. It was 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
> >>> 
> >>> but that was a fix in 2.6.39 (I think) and you are using 3.2.
> >>> 
> >>> Which could be releated to the fact that in 3.2 the E820 code
> >>> (arch/x86/xen/setup.c) went through some surgery to make it easier.
> >>> 
> >>> But the code in it looks like it handles it correctly. Hm,
> >>> any chance you can see what the Xen E820 looks in 3.2 vs anything
> >>> before v3.2?
> >>> 
> >>>> 
> >>>> Thanks for any help,
> >>>> 
> >>>> Tom
> >>>> 
> >>>> Dom0 mem was restricted to 672MB. The machine has 3GB.
> >>>> 
> >>>> 
> >>>> [ 2.463600] agpgart-intel 0000:00:00.0: Intel 965GM Chipset^M 
> >>>> (XEN) mm.c:878:d0 Error getting mfn 30600 (pfn 5555555555555555) from L1 entry 8000000030600473 for l1e_owner=0, pg_owner=0 
> >>>> (XEN) mm.c:4664:d0 ptwr_emulate: could not get_page_from_l1e() 
> >>>> [ 2.463891] BUG: unable to handle kernel paging request at ffff880023f28c30^M 
> >>>> [ 2.463904] IP: [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M 
> >>>> [ 2.463921] PGD 1a06067 PUD 1a0a067 PMD 209d067 PTE 8010000023f28065^M 
> >>>> [ 2.463934] Oops: 0003 [#1] SMP ^M 
> >>>> [ 2.463943] CPU 1 ^M 
> >>>> [ 2.463946] Modules linked in: intel_agp(+) intel_gtt^M 
> >>>> [ 2.463957] ^M 
> >>>> [ 2.463961] Pid: 128, comm: modprobe Not tainted 3.2.1-orc #102 Dell Inc. Latitude D830 /0HN341^M 
> >>>> [ 2.463974] RIP: e030:[<ffffffff81008bee>] [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M 
> >>>> [ 2.463984] RSP: e02b:ffff880004b91ac8 EFLAGS: 00010297^M 
> >>>> [ 2.463990] RAX: 0000000000000000 RBX: 8000000030600473 RCX: 8000000030600473^M 
> >>>> [ 2.463996] RDX: 0000000000000000 RSI: ffffc90000186000 RDI: ffffffff81a38020^M 
> >>>> [ 2.464002] RBP: ffff880004b91b18 R08: ffff880004d87d80 R09: 00000000000000d0^M 
> >>>> [ 2.464009] R10: ffffe8ffffffffff R11: ffffc90000000000 R12: ffff880023f28c30^M 
> >>>> [ 2.464015] R13: 0000000000030600 R14: ffff880023f28c30 R15: ffffc90000187000^M 
> >>>> [ 2.464024] FS: 00007f11b34db720(0000) GS:ffff880029fd1000(0000) knlGS:0000000000000000^M 
> >>>> [ 2.464031] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b^M 
> >>>> [ 2.464037] CR2: ffff880023f28c30 CR3: 0000000004bf1000 CR4: 0000000000002660^M 
> >>>> [ 2.464044] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000^M 
> >>>> [ 2.464050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400^M 
> >>>> [ 2.464057] Process modprobe (pid: 128, threadinfo ffff880004b90000, task ffff880004ac96b0)^M 
> >>>> [ 2.464063] Stack:^M 
> >>>> [ 2.464067] ffffc90000186000 ffffffff81a38020 ffffffff810051ed ffffc90000000000^M 
> >>>> [ 2.464079] ffffe8ffffffffff ffffc90000186000 ffff880023f28c30 0000000000030600^M 
> >>>> [ 2.464091] 8000000000000573 ffffc90000187000 ffff880004b91bc8 ffffffff812b01e4^M 
> >>>> [ 2.464104] Call Trace:^M 
> >>>> [ 2.464111] [<ffffffff810051ed>] ? __raw_callee_save_xen_make_pte+0x11/0x1e^M 
> >>>> [ 2.464121] [<ffffffff812b01e4>] ioremap_page_range+0x214/0x2f0^M 
> >>>> [ 2.464130] [<ffffffff8113b6a2>] ? insert_vmalloc_vmlist+0x22/0x80^M 
> >>>> [ 2.464140] [<ffffffff8103dc43>] __ioremap_caller+0x283/0x390^M 
> >>>> [ 2.464149] [<ffffffffa000070a>] ? i9xx_setup+0x20a/0x2e0 [intel_gtt]^M 
> >>>> [ 2.464158] [<ffffffff81579cee>] ? _raw_spin_unlock_irqrestore+0x1e/0x30^M 
> >>>> [ 2.464166] [<ffffffff8103dda7>] ioremap_nocache+0x17/0x20^M 
> >>>> [ 2.464173] [<ffffffffa000070a>] i9xx_setup+0x20a/0x2e0 [intel_gtt]^M 
> >>>> [ 2.464181] [<ffffffffa0001739>] intel_gmch_probe+0x369/0xa08 [intel_gtt]^M 
> >>>> [ 2.464190] [<ffffffffa0009e8a>] agp_intel_probe+0x48/0x19f [intel_agp]^M 
> >>>> [ 2.464198] [<ffffffff812d794c>] local_pci_probe+0x5c/0xd0^M 
> >>>> [ 2.464205] [<ffffffff812d9201>] pci_device_probe+0x101/0x120^M 
> >>>> [ 2.464214] [<ffffffff81392f5e>] driver_probe_device+0x7e/0x1b0^M 
> >>>> [ 2.464222] [<ffffffff8139313b>] __driver_attach+0xab/0xb0^M 
> >>>> [ 2.464229] [<ffffffff81393090>] ? driver_probe_device+0x1b0/0x1b0^M 
> >>>> [ 2.464236] [<ffffffff81393090>] ? driver_probe_device+0x1b0/0x1b0^M 
> >>>> [ 2.464244] [<ffffffff81391f1c>] bus_for_each_dev+0x5c/0x90^M 
> >>>> [ 2.464252] [<ffffffff81392bee>] driver_attach+0x1e/0x20^M 
> >>>> [ 2.464259] [<ffffffff81392840>] bus_add_driver+0x1a0/0x270^M 
> >>>> [ 2.464266] [<ffffffffa000d000>] ? 0xffffffffa000cfff^M 
> >>>> [ 2.464273] [<ffffffff813936a6>] driver_register+0x76/0x140^M 
> >>>> [ 2.464280] [<ffffffff8157d89d>] ? notifier_call_chain+0x4d/0x70^M 
> >>>> [ 2.464287] [<ffffffffa000d000>] ? 0xffffffffa000cfff^M 
> >>>> [ 2.464294] [<ffffffff812d8ed5>] __pci_register_driver+0x55/0xd0^M 
> >>>> [ 2.464303] [<ffffffff81089173>] ? __blocking_notifier_call_chain+0x63/0x80^M 
> >>>> [ 2.464312] [<ffffffffa000d02c>] agp_intel_init+0x2c/0x2e [intel_agp]^M 
> >>>> [ 2.464320] [<ffffffff81002040>] do_one_initcall+0x40/0x180^M 
> >>>> [ 2.464328] [<ffffffff810a0561>] sys_init_module+0x91/0x200^M 
> >>>> [ 2.464336] [<ffffffff81581b02>] system_call_fastpath+0x16/0x1b^M 
> >>>> [ 2.464341] Code: e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 48 89 7d b8 48 89 75 b0 49 89 d6 48 89 cb 66 66 66 66 90 e8 57 1b 03 00 83 f8 01 74 75 <49> 89 1e 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0 4c 8b ^M 
> >>>> [ 2.464450] RIP [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M 
> >>>> [ 2.464459] RSP <ffff880004b91ac8>^M 
> >>>> [ 2.464463] CR2: ffff880023f28c30^M 
> >>>> [ 2.464469] ---[ end trace 5223388e4a422cb4 ]---^M 
> >>>> 
> >>>> 
> >>>> ---
> >>>> Tom Goetz
> >>>> tom.goetz@virtualcomputer.com
> >>>> 
> >>>> 
> >> 
> >> ---
> >> Tom Goetz
> >> tom.goetz@virtualcomputer.com
> >> 
> >> 
> >> 
> 
> ---
> Tom Goetz
> tom.goetz@virtualcomputer.com
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYyG-0007v3-Qq; Wed, 18 Jan 2012 17:06: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 1RnYyE-0007uv-Pi
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:06:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326906400!1605617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24429 invoked from network); 18 Jan 2012 17:06:40 -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;
	18 Jan 2012 17:06:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10122659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 17:06:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 17:06: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
	1RnYy7-00069J-6J; Wed, 18 Jan 2012 17:06:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RnYy7-0003y3-4Z;
	Wed, 18 Jan 2012 17:06:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20246.64542.973936.843396@mariner.uk.xensource.com>
Date: Wed, 18 Jan 2012 17:06:38 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326904542.14689.258.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-2-git-send-email-ian.jackson@eu.citrix.com>
	<1326904542.14689.258.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/9] 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 1/9] libxl: New API for providing OS events to libxl"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > +struct libxl__ev_fd {
> > +    /* caller should include this in their own struct */
> > +    /* read-only for caller, who may read only when registered: */
> > +    int fd;
> > +    short events;
> > +    libxl__ev_fd_callback *func;
> 
> Are there actually cases where a caller would want to read these?
> 
> The most obvious case would be in the callback but it already gets given
> all three there.
> 
> Not suggesting we disallow this I'm just curious.

This is a change from my previous version of this series.  When
writing the device removal code I found myself wanting to read the
path member of a libxl__ev_xswatch:

+static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+               " timed out", ds->watch.path, ds->wanted);
                              ^^^^^^^^^^^^^^
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, ERROR_TIMEDOUT);
+}

So my options were:
 0. Not print the path, rendering the message almost useless
 1. Copy the path an extra time, pointlessly
 2. Relax the rules about the contents of libxl__ev_xswatch, making
    a special exception for this particular struct
 3. Relax the rules about the contents of libxl__ev_* generally
 4. Change the API of libxl__ev_* so that the caller always writes
    the fd, path, etc.

Of these 3 seemed best.  I considered 4.; but the result would be that
libxl__ev_KIND_register wouldn't take the arguments specifying what to
wait for, and that seemed a step too far.  Particularly since needing
to read inside the struct isn't all that common.

> Acked-by: Ian Campbell <ian.campbell@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 Wed Jan 18 17:07:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:07:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnYyG-0007v3-Qq; Wed, 18 Jan 2012 17:06: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 1RnYyE-0007uv-Pi
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:06:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326906400!1605617!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24429 invoked from network); 18 Jan 2012 17:06:40 -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;
	18 Jan 2012 17:06:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10122659"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 17:06:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 17:06: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
	1RnYy7-00069J-6J; Wed, 18 Jan 2012 17:06:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RnYy7-0003y3-4Z;
	Wed, 18 Jan 2012 17:06:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20246.64542.973936.843396@mariner.uk.xensource.com>
Date: Wed, 18 Jan 2012 17:06:38 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326904542.14689.258.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-2-git-send-email-ian.jackson@eu.citrix.com>
	<1326904542.14689.258.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/9] 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 1/9] libxl: New API for providing OS events to libxl"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > +struct libxl__ev_fd {
> > +    /* caller should include this in their own struct */
> > +    /* read-only for caller, who may read only when registered: */
> > +    int fd;
> > +    short events;
> > +    libxl__ev_fd_callback *func;
> 
> Are there actually cases where a caller would want to read these?
> 
> The most obvious case would be in the callback but it already gets given
> all three there.
> 
> Not suggesting we disallow this I'm just curious.

This is a change from my previous version of this series.  When
writing the device removal code I found myself wanting to read the
path member of a libxl__ev_xswatch:

+static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+               " timed out", ds->watch.path, ds->wanted);
                              ^^^^^^^^^^^^^^
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, ERROR_TIMEDOUT);
+}

So my options were:
 0. Not print the path, rendering the message almost useless
 1. Copy the path an extra time, pointlessly
 2. Relax the rules about the contents of libxl__ev_xswatch, making
    a special exception for this particular struct
 3. Relax the rules about the contents of libxl__ev_* generally
 4. Change the API of libxl__ev_* so that the caller always writes
    the fd, path, etc.

Of these 3 seemed best.  I considered 4.; but the result would be that
libxl__ev_KIND_register wouldn't take the arguments specifying what to
wait for, and that seemed a step too far.  Particularly since needing
to read inside the struct isn't all that common.

> Acked-by: Ian Campbell <ian.campbell@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 Wed Jan 18 17:11:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZ1r-00081U-HN; Wed, 18 Jan 2012 17:10:31 +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 1RnZ1q-00081L-M2
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:10:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326906579!50635027!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg2MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21929 invoked from network); 18 Jan 2012 17:09:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 17:09:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320642000"; d="scan'208";a="21018523"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 12:10: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; Wed, 18 Jan 2012
	12:10:24 -0500
Message-ID: <4F16FCFE.3000807@citrix.com>
Date: Wed, 18 Jan 2012 17:10:22 +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.wilk@oracle.com>
References: <1CB9139E-4600-4DBD-8F96-9061675DE9C2@virtualcomputer.com>
	<20120117210904.GB23782@phenom.dumpdata.com>
	<6EF87F6D-AD48-4DA9-BAD8-2FCB2C980C04@virtualcomputer.com>
	<20120118163456.GA24089@phenom.dumpdata.com>
	<79E94C03-B65F-4882-A744-EE6F27AF6C0D@virtualcomputer.com>
	<20120118165130.GC24089@phenom.dumpdata.com>
In-Reply-To: <20120118165130.GC24089@phenom.dumpdata.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"tom.goetz@virtualcomputer.com" <tom.goetz@virtualcomputer.com>
Subject: Re: [Xen-devel] 3.2 PVOPs Intel Crash
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/12 16:51, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 18, 2012 at 11:41:22AM -0500, Tom Goetz wrote:
> 
> CC-ing xen-devel and David.
> 
>> We have dom0_mem=672MB for Xen and mem=672MB for linux.
> 
> Ok, if you don't have the mem=X and have the "('x86: use 'dom0_mem' to limit
> the number of pages for dom0') (c/s 23790) in your hypervisor what happens?
> 
> And also have 'dom0_mem=max:672MB' do you get the same issue?

The kernel's mem option should be marking the extra memory as unusable
instead of just removing it from the E820.  I'll take a look at this --
it should be pretty straight-forward.

I would recommend what Konrad says above.  This ought to work.

David

>> [ 0.000000] e820 remove range: 000000002a000000 - ffffffffffffffff (usable)
>>
>> appears to come from
>>
>> static int __init parse_memopt(char *p)
>> {
>>         u64 mem_size;
>>
>>         if (!p)
>>                 return -EINVAL;
>>
>>         if (!strcmp(p, "nopentium")) {
>> #ifdef CONFIG_X86_32
>>                 setup_clear_cpu_cap(X86_FEATURE_PSE);
>>                 return 0;
>> #else
>>                 printk(KERN_WARNING "mem=nopentium ignored! (only supported on x86_32)\n");
>>                 return -EINVAL;
>> #endif
>>         }
>>
>>         userdef = 1;
>>         mem_size = memparse(p, &p);
>>         /* don't remove all of memory when handling "mem={invalid}" param */
>>         if (mem_size == 0)
>>                 return -EINVAL;
>>         e820_remove_range(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1); <-----------------------------
>>
>>         return 0;
>> }
>> early_param("mem", parse_memopt);
>>
>> but we have the same mem opt for 2.6.38 and 3.2 and the mem code still has the e820_remove_range in 3.2. Dom0 is showing the right amount of mem when booted on other machines, so I don't think the mem= option is failing.
> 
> The 'mem=X' argument I remember being a work-around. The original bug had been fixed in both
> hypervisor and in the kernel.
> 
> 
>>
>> I'm taking a break for lunch now and I'll did in further on the mem= option after.
>>
>> On Jan 18, 2012, at 11:34 AM, Konrad Rzeszutek Wilk wrote:
>>
>>> On Wed, Jan 18, 2012 at 11:02:48AM -0500, Tom Goetz wrote:
>>>> The E820s are different:
>>>>
>>>> Xen E820:
>>>>
>>>> (XEN) Xen-e820 RAM map:
>>>> (XEN) 0000000000000000 - 000000000009f000 (usable)
>>>> (XEN) 000000000009f000 - 00000000000a0000 (reserved)
>>>> (XEN) 0000000000100000 - 00000000bf65b800 (usable)
>>>> (XEN) 00000000bf65b800 - 00000000c0000000 (reserved)
>>>> (XEN) 00000000f8000000 - 00000000fc000000 (reserved)
>>>> (XEN) 00000000fec00000 - 00000000fec10000 (reserved)
>>>> (XEN) 00000000fed18000 - 00000000fed1c000 (reserved)
>>>> (XEN) 00000000fed20000 - 00000000fed90000 (reserved)
>>>> (XEN) 00000000feda0000 - 00000000feda6000 (reserved)
>>>> (XEN) 00000000fee00000 - 00000000fee10000 (reserved)
>>>> (XEN) 00000000ffe00000 - 0000000100000000 (reserved)
>>>>
>>>> 2.6.38 E820:
>>>>
>>>> [ 0.000000] BIOS-provided physical RAM map:
>>>> [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable)
>>>> [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved)
>>>> [ 0.000000] Xen: 0000000000100000 - 000000002a000000 (usable)
>>>> [ 0.000000] Xen: 000000002a000000 - 00000000bf65b000 (unusable)
>>>
>>> Good. That is correct.
>>>
>>>> [ 0.000000] Xen: 00000000bf65b800 - 00000000c0000000 (reserved)
>>>> [ 0.000000] Xen: 00000000f8000000 - 00000000fc000000 (reserved)
>>>> [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved)
>>>> [ 0.000000] Xen: 00000000fed18000 - 00000000fed1c000 (reserved)
>>>> [ 0.000000] Xen: 00000000fed20000 - 00000000fed90000 (reserved)
>>>> [ 0.000000] Xen: 00000000feda0000 - 00000000feda6000 (reserved)
>>>> [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved)
>>>> [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved)
>>>> [ 0.000000] Xen: 0000000100000000 - 000000019565b000 (usable)
>>>> [ 0.000000] e820 remove range: 000000002a000000 - ffffffffffffffff (usable)
>>>> [ 0.000000] NX (Execute Disable) protection: active
>>>> [ 0.000000] user-defined physical RAM map:
>>>> [ 0.000000] user: 0000000000000000 - 000000000009f000 (usable)       - 1
>>>> [ 0.000000] user: 000000000009f000 - 0000000000100000 (reserved)    - 2
>>>> [ 0.000000] user: 0000000000100000 - 000000002a000000 (usable)      - 3
>>>> [ 0.000000] user: 000000002a000000 - 00000000bf65b000 (unusable)   - 4 <------------   This isn't in the Xen version either.
>>>
>>> Yup, that is OK. We want that region to be mapped as 'unusable'.
>>>
>>> That will make the intel-agp code _not_ use that region (which we
>>> should not as that is a RAM region).
>>>
>>>> [ 0.000000] user: 00000000bf65b800 - 00000000c0000000 (reserved)    - 5
>>>> [ 0.000000] user: 00000000f8000000 - 00000000fc000000 (reserved)     - 6
>>>> [ 0.000000] user: 00000000fec00000 - 00000000fec10000 (reserved)      - 7
>>>> [ 0.000000] user: 00000000fed18000 - 00000000fed1c000 (reserved)     - 8
>>>> [ 0.000000] user: 00000000fed20000 - 00000000fed90000 (reserved)      - 9
>>>> [ 0.000000] user: 00000000feda0000 - 00000000feda6000 (reserved)     - 10
>>>> [ 0.000000] user: 00000000fee00000 - 00000000fee10000 (reserved)     - 11
>>>> [ 0.000000] user: 00000000ffe00000 - 0000000100000000 (reserved)     - 12
>>>> [ 0.000000] DMI 2.4 present.
>>>> [ 0.000000] DMI: Dell Inc. Latitude D830 /0HN341, BIOS A05 11/05/2007
>>>> [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)    <---- 3.2 is also missing these lines
>>>> [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
>>>>
>>>>
>>>> 3.2 E820:
>>>>
>>>> [ 0.000000] Set 264710 page(s) to 1-1 mapping
>>>>
>>>> [ 0.000000] BIOS-provided physical RAM map:
>>>> [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable)
>>>> [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved)
>>>> [ 0.000000] Xen: 0000000000100000 - 00000000bf65b000 (usable)
>>>
>>> So here, we should have had the
>>>
>>> 2a000 -> bf65b marked as unsuable.
> 
> On a second thought that is OK too. The 2a00->bf65b will
> protect the region from being slurped up by the PCI as "gap" region.
>>>
>>> You booted the kernel with the same dom0_mem=X argument right?
>>>
>>>> [ 0.000000] Xen: 00000000bf65b800 - 00000000c0000000 (reserved)
>>>> [ 0.000000] Xen: 00000000f8000000 - 00000000fc000000 (reserved)
>>>> [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved)
>>>> [ 0.000000] Xen: 00000000fed18000 - 00000000fed1c000 (reserved)
>>>> [ 0.000000] Xen: 00000000fed20000 - 00000000fed90000 (reserved)
>>>> [ 0.000000] Xen: 00000000feda0000 - 00000000feda6000 (reserved)
>>>> [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved)
>>>> [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved)
>>>> [ 0.000000] NX (Execute Disable) protection: active
>>>>
>>>> [ 0.000000] user-defined physical RAM map:
>>>> [ 0.000000] user: 0000000000000000 - 000000000009f000 (usable)        - 1
>>>> [ 0.000000] user: 000000000009f000 - 0000000000100000 (reserved)    - 2
>>>> [ 0.000000] user: 0000000000100000 - 000000002a000000 (usable)      - 3
> 
> Ah, and this now punches the E820 with 2a000->bf65b as a "gap" and
> it ends up being used by the PCI subsystem.
> 
> That is the problem. So ... can you make sure you have that
> hypervisor fix in and boot it without 'mem' and see what the E820 comes out as?
> 
> Thanks!
>>>> [ 0.000000] user: 00000000bf65b800 - 00000000c0000000 (reserved)     - 5
>>>> [ 0.000000] user: 00000000f8000000 - 00000000fc000000 (reserved)      - 6
>>>> [ 0.000000] user: 00000000fec00000 - 00000000fec10000 (reserved)      - 7
>>>> [ 0.000000] user: 00000000fed18000 - 00000000fed1c000 (reserved)      - 8
>>>> [ 0.000000] user: 00000000fed20000 - 00000000fed90000 (reserved)      - 9
>>>> [ 0.000000] user: 00000000feda0000 - 00000000feda6000 (reserved)     - 10
>>>> [ 0.000000] user: 00000000fee00000 - 00000000fee10000 (reserved)     - 11
>>>> [ 0.000000] user: 00000000ffe00000 - 0000000100000000 (reserved)     - 12
>>>>
>>>> On Jan 17, 2012, at 4:09 PM, Konrad Rzeszutek Wilk wrote:
>>>>
>>>>> On Tue, Jan 17, 2012 at 03:58:11PM -0500, Tom Goetz wrote:
>>>>>> Konrad,
>>>>>>
>>>>>> We're seeing a crash on an Intel video Core2Duo. The crash looks similar to this one: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726. The last comment gives a commit ID for a fix. I don't find that commit in any of our trees. Do you know anything about this?
>>>>>
>>>>> Yes. It was 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
>>>>>
>>>>> but that was a fix in 2.6.39 (I think) and you are using 3.2.
>>>>>
>>>>> Which could be releated to the fact that in 3.2 the E820 code
>>>>> (arch/x86/xen/setup.c) went through some surgery to make it easier.
>>>>>
>>>>> But the code in it looks like it handles it correctly. Hm,
>>>>> any chance you can see what the Xen E820 looks in 3.2 vs anything
>>>>> before v3.2?
>>>>>
>>>>>>
>>>>>> Thanks for any help,
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Dom0 mem was restricted to 672MB. The machine has 3GB.
>>>>>>
>>>>>>
>>>>>> [ 2.463600] agpgart-intel 0000:00:00.0: Intel 965GM Chipset^M
>>>>>> (XEN) mm.c:878:d0 Error getting mfn 30600 (pfn 5555555555555555) from L1 entry 8000000030600473 for l1e_owner=0, pg_owner=0
>>>>>> (XEN) mm.c:4664:d0 ptwr_emulate: could not get_page_from_l1e()
>>>>>> [ 2.463891] BUG: unable to handle kernel paging request at ffff880023f28c30^M
>>>>>> [ 2.463904] IP: [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M
>>>>>> [ 2.463921] PGD 1a06067 PUD 1a0a067 PMD 209d067 PTE 8010000023f28065^M
>>>>>> [ 2.463934] Oops: 0003 [#1] SMP ^M
>>>>>> [ 2.463943] CPU 1 ^M
>>>>>> [ 2.463946] Modules linked in: intel_agp(+) intel_gtt^M
>>>>>> [ 2.463957] ^M
>>>>>> [ 2.463961] Pid: 128, comm: modprobe Not tainted 3.2.1-orc #102 Dell Inc. Latitude D830 /0HN341^M
>>>>>> [ 2.463974] RIP: e030:[<ffffffff81008bee>] [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M
>>>>>> [ 2.463984] RSP: e02b:ffff880004b91ac8 EFLAGS: 00010297^M
>>>>>> [ 2.463990] RAX: 0000000000000000 RBX: 8000000030600473 RCX: 8000000030600473^M
>>>>>> [ 2.463996] RDX: 0000000000000000 RSI: ffffc90000186000 RDI: ffffffff81a38020^M
>>>>>> [ 2.464002] RBP: ffff880004b91b18 R08: ffff880004d87d80 R09: 00000000000000d0^M
>>>>>> [ 2.464009] R10: ffffe8ffffffffff R11: ffffc90000000000 R12: ffff880023f28c30^M
>>>>>> [ 2.464015] R13: 0000000000030600 R14: ffff880023f28c30 R15: ffffc90000187000^M
>>>>>> [ 2.464024] FS: 00007f11b34db720(0000) GS:ffff880029fd1000(0000) knlGS:0000000000000000^M
>>>>>> [ 2.464031] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b^M
>>>>>> [ 2.464037] CR2: ffff880023f28c30 CR3: 0000000004bf1000 CR4: 0000000000002660^M
>>>>>> [ 2.464044] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000^M
>>>>>> [ 2.464050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400^M
>>>>>> [ 2.464057] Process modprobe (pid: 128, threadinfo ffff880004b90000, task ffff880004ac96b0)^M
>>>>>> [ 2.464063] Stack:^M
>>>>>> [ 2.464067] ffffc90000186000 ffffffff81a38020 ffffffff810051ed ffffc90000000000^M
>>>>>> [ 2.464079] ffffe8ffffffffff ffffc90000186000 ffff880023f28c30 0000000000030600^M
>>>>>> [ 2.464091] 8000000000000573 ffffc90000187000 ffff880004b91bc8 ffffffff812b01e4^M
>>>>>> [ 2.464104] Call Trace:^M
>>>>>> [ 2.464111] [<ffffffff810051ed>] ? __raw_callee_save_xen_make_pte+0x11/0x1e^M
>>>>>> [ 2.464121] [<ffffffff812b01e4>] ioremap_page_range+0x214/0x2f0^M
>>>>>> [ 2.464130] [<ffffffff8113b6a2>] ? insert_vmalloc_vmlist+0x22/0x80^M
>>>>>> [ 2.464140] [<ffffffff8103dc43>] __ioremap_caller+0x283/0x390^M
>>>>>> [ 2.464149] [<ffffffffa000070a>] ? i9xx_setup+0x20a/0x2e0 [intel_gtt]^M
>>>>>> [ 2.464158] [<ffffffff81579cee>] ? _raw_spin_unlock_irqrestore+0x1e/0x30^M
>>>>>> [ 2.464166] [<ffffffff8103dda7>] ioremap_nocache+0x17/0x20^M
>>>>>> [ 2.464173] [<ffffffffa000070a>] i9xx_setup+0x20a/0x2e0 [intel_gtt]^M
>>>>>> [ 2.464181] [<ffffffffa0001739>] intel_gmch_probe+0x369/0xa08 [intel_gtt]^M
>>>>>> [ 2.464190] [<ffffffffa0009e8a>] agp_intel_probe+0x48/0x19f [intel_agp]^M
>>>>>> [ 2.464198] [<ffffffff812d794c>] local_pci_probe+0x5c/0xd0^M
>>>>>> [ 2.464205] [<ffffffff812d9201>] pci_device_probe+0x101/0x120^M
>>>>>> [ 2.464214] [<ffffffff81392f5e>] driver_probe_device+0x7e/0x1b0^M
>>>>>> [ 2.464222] [<ffffffff8139313b>] __driver_attach+0xab/0xb0^M
>>>>>> [ 2.464229] [<ffffffff81393090>] ? driver_probe_device+0x1b0/0x1b0^M
>>>>>> [ 2.464236] [<ffffffff81393090>] ? driver_probe_device+0x1b0/0x1b0^M
>>>>>> [ 2.464244] [<ffffffff81391f1c>] bus_for_each_dev+0x5c/0x90^M
>>>>>> [ 2.464252] [<ffffffff81392bee>] driver_attach+0x1e/0x20^M
>>>>>> [ 2.464259] [<ffffffff81392840>] bus_add_driver+0x1a0/0x270^M
>>>>>> [ 2.464266] [<ffffffffa000d000>] ? 0xffffffffa000cfff^M
>>>>>> [ 2.464273] [<ffffffff813936a6>] driver_register+0x76/0x140^M
>>>>>> [ 2.464280] [<ffffffff8157d89d>] ? notifier_call_chain+0x4d/0x70^M
>>>>>> [ 2.464287] [<ffffffffa000d000>] ? 0xffffffffa000cfff^M
>>>>>> [ 2.464294] [<ffffffff812d8ed5>] __pci_register_driver+0x55/0xd0^M
>>>>>> [ 2.464303] [<ffffffff81089173>] ? __blocking_notifier_call_chain+0x63/0x80^M
>>>>>> [ 2.464312] [<ffffffffa000d02c>] agp_intel_init+0x2c/0x2e [intel_agp]^M
>>>>>> [ 2.464320] [<ffffffff81002040>] do_one_initcall+0x40/0x180^M
>>>>>> [ 2.464328] [<ffffffff810a0561>] sys_init_module+0x91/0x200^M
>>>>>> [ 2.464336] [<ffffffff81581b02>] system_call_fastpath+0x16/0x1b^M
>>>>>> [ 2.464341] Code: e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 48 89 7d b8 48 89 75 b0 49 89 d6 48 89 cb 66 66 66 66 90 e8 57 1b 03 00 83 f8 01 74 75 <49> 89 1e 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0 4c 8b ^M
>>>>>> [ 2.464450] RIP [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M
>>>>>> [ 2.464459] RSP <ffff880004b91ac8>^M
>>>>>> [ 2.464463] CR2: ffff880023f28c30^M
>>>>>> [ 2.464469] ---[ end trace 5223388e4a422cb4 ]---^M
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Tom Goetz
>>>>>> tom.goetz@virtualcomputer.com
>>>>>>
>>>>>>
>>>>
>>>> ---
>>>> Tom Goetz
>>>> tom.goetz@virtualcomputer.com
>>>>
>>>>
>>>>
>>
>> ---
>> Tom Goetz
>> tom.goetz@virtualcomputer.com
>>
>>
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:11:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:11:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZ1r-00081U-HN; Wed, 18 Jan 2012 17:10:31 +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 1RnZ1q-00081L-M2
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:10:31 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326906579!50635027!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg2MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21929 invoked from network); 18 Jan 2012 17:09:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 17:09:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320642000"; d="scan'208";a="21018523"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 12:10: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; Wed, 18 Jan 2012
	12:10:24 -0500
Message-ID: <4F16FCFE.3000807@citrix.com>
Date: Wed, 18 Jan 2012 17:10:22 +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.wilk@oracle.com>
References: <1CB9139E-4600-4DBD-8F96-9061675DE9C2@virtualcomputer.com>
	<20120117210904.GB23782@phenom.dumpdata.com>
	<6EF87F6D-AD48-4DA9-BAD8-2FCB2C980C04@virtualcomputer.com>
	<20120118163456.GA24089@phenom.dumpdata.com>
	<79E94C03-B65F-4882-A744-EE6F27AF6C0D@virtualcomputer.com>
	<20120118165130.GC24089@phenom.dumpdata.com>
In-Reply-To: <20120118165130.GC24089@phenom.dumpdata.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"tom.goetz@virtualcomputer.com" <tom.goetz@virtualcomputer.com>
Subject: Re: [Xen-devel] 3.2 PVOPs Intel Crash
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/12 16:51, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 18, 2012 at 11:41:22AM -0500, Tom Goetz wrote:
> 
> CC-ing xen-devel and David.
> 
>> We have dom0_mem=672MB for Xen and mem=672MB for linux.
> 
> Ok, if you don't have the mem=X and have the "('x86: use 'dom0_mem' to limit
> the number of pages for dom0') (c/s 23790) in your hypervisor what happens?
> 
> And also have 'dom0_mem=max:672MB' do you get the same issue?

The kernel's mem option should be marking the extra memory as unusable
instead of just removing it from the E820.  I'll take a look at this --
it should be pretty straight-forward.

I would recommend what Konrad says above.  This ought to work.

David

>> [ 0.000000] e820 remove range: 000000002a000000 - ffffffffffffffff (usable)
>>
>> appears to come from
>>
>> static int __init parse_memopt(char *p)
>> {
>>         u64 mem_size;
>>
>>         if (!p)
>>                 return -EINVAL;
>>
>>         if (!strcmp(p, "nopentium")) {
>> #ifdef CONFIG_X86_32
>>                 setup_clear_cpu_cap(X86_FEATURE_PSE);
>>                 return 0;
>> #else
>>                 printk(KERN_WARNING "mem=nopentium ignored! (only supported on x86_32)\n");
>>                 return -EINVAL;
>> #endif
>>         }
>>
>>         userdef = 1;
>>         mem_size = memparse(p, &p);
>>         /* don't remove all of memory when handling "mem={invalid}" param */
>>         if (mem_size == 0)
>>                 return -EINVAL;
>>         e820_remove_range(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1); <-----------------------------
>>
>>         return 0;
>> }
>> early_param("mem", parse_memopt);
>>
>> but we have the same mem opt for 2.6.38 and 3.2 and the mem code still has the e820_remove_range in 3.2. Dom0 is showing the right amount of mem when booted on other machines, so I don't think the mem= option is failing.
> 
> The 'mem=X' argument I remember being a work-around. The original bug had been fixed in both
> hypervisor and in the kernel.
> 
> 
>>
>> I'm taking a break for lunch now and I'll did in further on the mem= option after.
>>
>> On Jan 18, 2012, at 11:34 AM, Konrad Rzeszutek Wilk wrote:
>>
>>> On Wed, Jan 18, 2012 at 11:02:48AM -0500, Tom Goetz wrote:
>>>> The E820s are different:
>>>>
>>>> Xen E820:
>>>>
>>>> (XEN) Xen-e820 RAM map:
>>>> (XEN) 0000000000000000 - 000000000009f000 (usable)
>>>> (XEN) 000000000009f000 - 00000000000a0000 (reserved)
>>>> (XEN) 0000000000100000 - 00000000bf65b800 (usable)
>>>> (XEN) 00000000bf65b800 - 00000000c0000000 (reserved)
>>>> (XEN) 00000000f8000000 - 00000000fc000000 (reserved)
>>>> (XEN) 00000000fec00000 - 00000000fec10000 (reserved)
>>>> (XEN) 00000000fed18000 - 00000000fed1c000 (reserved)
>>>> (XEN) 00000000fed20000 - 00000000fed90000 (reserved)
>>>> (XEN) 00000000feda0000 - 00000000feda6000 (reserved)
>>>> (XEN) 00000000fee00000 - 00000000fee10000 (reserved)
>>>> (XEN) 00000000ffe00000 - 0000000100000000 (reserved)
>>>>
>>>> 2.6.38 E820:
>>>>
>>>> [ 0.000000] BIOS-provided physical RAM map:
>>>> [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable)
>>>> [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved)
>>>> [ 0.000000] Xen: 0000000000100000 - 000000002a000000 (usable)
>>>> [ 0.000000] Xen: 000000002a000000 - 00000000bf65b000 (unusable)
>>>
>>> Good. That is correct.
>>>
>>>> [ 0.000000] Xen: 00000000bf65b800 - 00000000c0000000 (reserved)
>>>> [ 0.000000] Xen: 00000000f8000000 - 00000000fc000000 (reserved)
>>>> [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved)
>>>> [ 0.000000] Xen: 00000000fed18000 - 00000000fed1c000 (reserved)
>>>> [ 0.000000] Xen: 00000000fed20000 - 00000000fed90000 (reserved)
>>>> [ 0.000000] Xen: 00000000feda0000 - 00000000feda6000 (reserved)
>>>> [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved)
>>>> [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved)
>>>> [ 0.000000] Xen: 0000000100000000 - 000000019565b000 (usable)
>>>> [ 0.000000] e820 remove range: 000000002a000000 - ffffffffffffffff (usable)
>>>> [ 0.000000] NX (Execute Disable) protection: active
>>>> [ 0.000000] user-defined physical RAM map:
>>>> [ 0.000000] user: 0000000000000000 - 000000000009f000 (usable)       - 1
>>>> [ 0.000000] user: 000000000009f000 - 0000000000100000 (reserved)    - 2
>>>> [ 0.000000] user: 0000000000100000 - 000000002a000000 (usable)      - 3
>>>> [ 0.000000] user: 000000002a000000 - 00000000bf65b000 (unusable)   - 4 <------------   This isn't in the Xen version either.
>>>
>>> Yup, that is OK. We want that region to be mapped as 'unusable'.
>>>
>>> That will make the intel-agp code _not_ use that region (which we
>>> should not as that is a RAM region).
>>>
>>>> [ 0.000000] user: 00000000bf65b800 - 00000000c0000000 (reserved)    - 5
>>>> [ 0.000000] user: 00000000f8000000 - 00000000fc000000 (reserved)     - 6
>>>> [ 0.000000] user: 00000000fec00000 - 00000000fec10000 (reserved)      - 7
>>>> [ 0.000000] user: 00000000fed18000 - 00000000fed1c000 (reserved)     - 8
>>>> [ 0.000000] user: 00000000fed20000 - 00000000fed90000 (reserved)      - 9
>>>> [ 0.000000] user: 00000000feda0000 - 00000000feda6000 (reserved)     - 10
>>>> [ 0.000000] user: 00000000fee00000 - 00000000fee10000 (reserved)     - 11
>>>> [ 0.000000] user: 00000000ffe00000 - 0000000100000000 (reserved)     - 12
>>>> [ 0.000000] DMI 2.4 present.
>>>> [ 0.000000] DMI: Dell Inc. Latitude D830 /0HN341, BIOS A05 11/05/2007
>>>> [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)    <---- 3.2 is also missing these lines
>>>> [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
>>>>
>>>>
>>>> 3.2 E820:
>>>>
>>>> [ 0.000000] Set 264710 page(s) to 1-1 mapping
>>>>
>>>> [ 0.000000] BIOS-provided physical RAM map:
>>>> [ 0.000000] Xen: 0000000000000000 - 000000000009f000 (usable)
>>>> [ 0.000000] Xen: 000000000009f000 - 0000000000100000 (reserved)
>>>> [ 0.000000] Xen: 0000000000100000 - 00000000bf65b000 (usable)
>>>
>>> So here, we should have had the
>>>
>>> 2a000 -> bf65b marked as unsuable.
> 
> On a second thought that is OK too. The 2a00->bf65b will
> protect the region from being slurped up by the PCI as "gap" region.
>>>
>>> You booted the kernel with the same dom0_mem=X argument right?
>>>
>>>> [ 0.000000] Xen: 00000000bf65b800 - 00000000c0000000 (reserved)
>>>> [ 0.000000] Xen: 00000000f8000000 - 00000000fc000000 (reserved)
>>>> [ 0.000000] Xen: 00000000fec00000 - 00000000fec10000 (reserved)
>>>> [ 0.000000] Xen: 00000000fed18000 - 00000000fed1c000 (reserved)
>>>> [ 0.000000] Xen: 00000000fed20000 - 00000000fed90000 (reserved)
>>>> [ 0.000000] Xen: 00000000feda0000 - 00000000feda6000 (reserved)
>>>> [ 0.000000] Xen: 00000000fee00000 - 00000000fee10000 (reserved)
>>>> [ 0.000000] Xen: 00000000ffe00000 - 0000000100000000 (reserved)
>>>> [ 0.000000] NX (Execute Disable) protection: active
>>>>
>>>> [ 0.000000] user-defined physical RAM map:
>>>> [ 0.000000] user: 0000000000000000 - 000000000009f000 (usable)        - 1
>>>> [ 0.000000] user: 000000000009f000 - 0000000000100000 (reserved)    - 2
>>>> [ 0.000000] user: 0000000000100000 - 000000002a000000 (usable)      - 3
> 
> Ah, and this now punches the E820 with 2a000->bf65b as a "gap" and
> it ends up being used by the PCI subsystem.
> 
> That is the problem. So ... can you make sure you have that
> hypervisor fix in and boot it without 'mem' and see what the E820 comes out as?
> 
> Thanks!
>>>> [ 0.000000] user: 00000000bf65b800 - 00000000c0000000 (reserved)     - 5
>>>> [ 0.000000] user: 00000000f8000000 - 00000000fc000000 (reserved)      - 6
>>>> [ 0.000000] user: 00000000fec00000 - 00000000fec10000 (reserved)      - 7
>>>> [ 0.000000] user: 00000000fed18000 - 00000000fed1c000 (reserved)      - 8
>>>> [ 0.000000] user: 00000000fed20000 - 00000000fed90000 (reserved)      - 9
>>>> [ 0.000000] user: 00000000feda0000 - 00000000feda6000 (reserved)     - 10
>>>> [ 0.000000] user: 00000000fee00000 - 00000000fee10000 (reserved)     - 11
>>>> [ 0.000000] user: 00000000ffe00000 - 0000000100000000 (reserved)     - 12
>>>>
>>>> On Jan 17, 2012, at 4:09 PM, Konrad Rzeszutek Wilk wrote:
>>>>
>>>>> On Tue, Jan 17, 2012 at 03:58:11PM -0500, Tom Goetz wrote:
>>>>>> Konrad,
>>>>>>
>>>>>> We're seeing a crash on an Intel video Core2Duo. The crash looks similar to this one: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1726. The last comment gives a commit ID for a fix. I don't find that commit in any of our trees. Do you know anything about this?
>>>>>
>>>>> Yes. It was 2f14ddc3a7146ea4cd5a3d1ecd993f85f2e4f948
>>>>>
>>>>> but that was a fix in 2.6.39 (I think) and you are using 3.2.
>>>>>
>>>>> Which could be releated to the fact that in 3.2 the E820 code
>>>>> (arch/x86/xen/setup.c) went through some surgery to make it easier.
>>>>>
>>>>> But the code in it looks like it handles it correctly. Hm,
>>>>> any chance you can see what the Xen E820 looks in 3.2 vs anything
>>>>> before v3.2?
>>>>>
>>>>>>
>>>>>> Thanks for any help,
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>> Dom0 mem was restricted to 672MB. The machine has 3GB.
>>>>>>
>>>>>>
>>>>>> [ 2.463600] agpgart-intel 0000:00:00.0: Intel 965GM Chipset^M
>>>>>> (XEN) mm.c:878:d0 Error getting mfn 30600 (pfn 5555555555555555) from L1 entry 8000000030600473 for l1e_owner=0, pg_owner=0
>>>>>> (XEN) mm.c:4664:d0 ptwr_emulate: could not get_page_from_l1e()
>>>>>> [ 2.463891] BUG: unable to handle kernel paging request at ffff880023f28c30^M
>>>>>> [ 2.463904] IP: [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M
>>>>>> [ 2.463921] PGD 1a06067 PUD 1a0a067 PMD 209d067 PTE 8010000023f28065^M
>>>>>> [ 2.463934] Oops: 0003 [#1] SMP ^M
>>>>>> [ 2.463943] CPU 1 ^M
>>>>>> [ 2.463946] Modules linked in: intel_agp(+) intel_gtt^M
>>>>>> [ 2.463957] ^M
>>>>>> [ 2.463961] Pid: 128, comm: modprobe Not tainted 3.2.1-orc #102 Dell Inc. Latitude D830 /0HN341^M
>>>>>> [ 2.463974] RIP: e030:[<ffffffff81008bee>] [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M
>>>>>> [ 2.463984] RSP: e02b:ffff880004b91ac8 EFLAGS: 00010297^M
>>>>>> [ 2.463990] RAX: 0000000000000000 RBX: 8000000030600473 RCX: 8000000030600473^M
>>>>>> [ 2.463996] RDX: 0000000000000000 RSI: ffffc90000186000 RDI: ffffffff81a38020^M
>>>>>> [ 2.464002] RBP: ffff880004b91b18 R08: ffff880004d87d80 R09: 00000000000000d0^M
>>>>>> [ 2.464009] R10: ffffe8ffffffffff R11: ffffc90000000000 R12: ffff880023f28c30^M
>>>>>> [ 2.464015] R13: 0000000000030600 R14: ffff880023f28c30 R15: ffffc90000187000^M
>>>>>> [ 2.464024] FS: 00007f11b34db720(0000) GS:ffff880029fd1000(0000) knlGS:0000000000000000^M
>>>>>> [ 2.464031] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b^M
>>>>>> [ 2.464037] CR2: ffff880023f28c30 CR3: 0000000004bf1000 CR4: 0000000000002660^M
>>>>>> [ 2.464044] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000^M
>>>>>> [ 2.464050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400^M
>>>>>> [ 2.464057] Process modprobe (pid: 128, threadinfo ffff880004b90000, task ffff880004ac96b0)^M
>>>>>> [ 2.464063] Stack:^M
>>>>>> [ 2.464067] ffffc90000186000 ffffffff81a38020 ffffffff810051ed ffffc90000000000^M
>>>>>> [ 2.464079] ffffe8ffffffffff ffffc90000186000 ffff880023f28c30 0000000000030600^M
>>>>>> [ 2.464091] 8000000000000573 ffffc90000187000 ffff880004b91bc8 ffffffff812b01e4^M
>>>>>> [ 2.464104] Call Trace:^M
>>>>>> [ 2.464111] [<ffffffff810051ed>] ? __raw_callee_save_xen_make_pte+0x11/0x1e^M
>>>>>> [ 2.464121] [<ffffffff812b01e4>] ioremap_page_range+0x214/0x2f0^M
>>>>>> [ 2.464130] [<ffffffff8113b6a2>] ? insert_vmalloc_vmlist+0x22/0x80^M
>>>>>> [ 2.464140] [<ffffffff8103dc43>] __ioremap_caller+0x283/0x390^M
>>>>>> [ 2.464149] [<ffffffffa000070a>] ? i9xx_setup+0x20a/0x2e0 [intel_gtt]^M
>>>>>> [ 2.464158] [<ffffffff81579cee>] ? _raw_spin_unlock_irqrestore+0x1e/0x30^M
>>>>>> [ 2.464166] [<ffffffff8103dda7>] ioremap_nocache+0x17/0x20^M
>>>>>> [ 2.464173] [<ffffffffa000070a>] i9xx_setup+0x20a/0x2e0 [intel_gtt]^M
>>>>>> [ 2.464181] [<ffffffffa0001739>] intel_gmch_probe+0x369/0xa08 [intel_gtt]^M
>>>>>> [ 2.464190] [<ffffffffa0009e8a>] agp_intel_probe+0x48/0x19f [intel_agp]^M
>>>>>> [ 2.464198] [<ffffffff812d794c>] local_pci_probe+0x5c/0xd0^M
>>>>>> [ 2.464205] [<ffffffff812d9201>] pci_device_probe+0x101/0x120^M
>>>>>> [ 2.464214] [<ffffffff81392f5e>] driver_probe_device+0x7e/0x1b0^M
>>>>>> [ 2.464222] [<ffffffff8139313b>] __driver_attach+0xab/0xb0^M
>>>>>> [ 2.464229] [<ffffffff81393090>] ? driver_probe_device+0x1b0/0x1b0^M
>>>>>> [ 2.464236] [<ffffffff81393090>] ? driver_probe_device+0x1b0/0x1b0^M
>>>>>> [ 2.464244] [<ffffffff81391f1c>] bus_for_each_dev+0x5c/0x90^M
>>>>>> [ 2.464252] [<ffffffff81392bee>] driver_attach+0x1e/0x20^M
>>>>>> [ 2.464259] [<ffffffff81392840>] bus_add_driver+0x1a0/0x270^M
>>>>>> [ 2.464266] [<ffffffffa000d000>] ? 0xffffffffa000cfff^M
>>>>>> [ 2.464273] [<ffffffff813936a6>] driver_register+0x76/0x140^M
>>>>>> [ 2.464280] [<ffffffff8157d89d>] ? notifier_call_chain+0x4d/0x70^M
>>>>>> [ 2.464287] [<ffffffffa000d000>] ? 0xffffffffa000cfff^M
>>>>>> [ 2.464294] [<ffffffff812d8ed5>] __pci_register_driver+0x55/0xd0^M
>>>>>> [ 2.464303] [<ffffffff81089173>] ? __blocking_notifier_call_chain+0x63/0x80^M
>>>>>> [ 2.464312] [<ffffffffa000d02c>] agp_intel_init+0x2c/0x2e [intel_agp]^M
>>>>>> [ 2.464320] [<ffffffff81002040>] do_one_initcall+0x40/0x180^M
>>>>>> [ 2.464328] [<ffffffff810a0561>] sys_init_module+0x91/0x200^M
>>>>>> [ 2.464336] [<ffffffff81581b02>] system_call_fastpath+0x16/0x1b^M
>>>>>> [ 2.464341] Code: e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 48 89 7d b8 48 89 75 b0 49 89 d6 48 89 cb 66 66 66 66 90 e8 57 1b 03 00 83 f8 01 74 75 <49> 89 1e 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 f0 4c 8b ^M
>>>>>> [ 2.464450] RIP [<ffffffff81008bee>] xen_set_pte_at+0x3e/0x210^M
>>>>>> [ 2.464459] RSP <ffff880004b91ac8>^M
>>>>>> [ 2.464463] CR2: ffff880023f28c30^M
>>>>>> [ 2.464469] ---[ end trace 5223388e4a422cb4 ]---^M
>>>>>>
>>>>>>
>>>>>> ---
>>>>>> Tom Goetz
>>>>>> tom.goetz@virtualcomputer.com
>>>>>>
>>>>>>
>>>>
>>>> ---
>>>> Tom Goetz
>>>> tom.goetz@virtualcomputer.com
>>>>
>>>>
>>>>
>>
>> ---
>> Tom Goetz
>> tom.goetz@virtualcomputer.com
>>
>>
>>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:16:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17: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 1RnZ6w-0008MF-Vl; Wed, 18 Jan 2012 17:15:46 +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 1RnZ6u-0008La-RP
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:15:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326906938!9071074!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzMyMzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzMyMzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32691 invoked from network); 18 Jan 2012 17:15:38 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 17:15:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326906938; l=1487;
	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=CLCu9k6LKo1gCl1TBXEteZSR1wQ=;
	b=CLV8oLt1RQssSp3XImgu+2NfaMYZu8EhZ2v8UYypFrdBE7fopzfMSJtkLJhKW5NeKt4
	i5nurVYaV3U2IV58DmgN0ispiK9uKzCLFp1dq7+EO2ynj7PCl6cKm/K308Ab+6oxAIKx2
	HuZl150XL9/mXkRqGGcanrcSzeHu0eTEkOg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0MF3Z/
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-248.pools.arcor-ip.net [88.65.73.248])
	by smtp.strato.de (cohen mo7) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 606a5ao0IFg72D
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 18:15:28 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 46C8F18634
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 18:15:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1821b0e1ce16d0015542d4164505d97f130f09d7
Message-Id: <1821b0e1ce16d0015542.1326906924@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 18 Jan 2012 18:15:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: fix error handling in
	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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326906775 -3600
# Node ID 1821b0e1ce16d0015542d4164505d97f130f09d7
# Parent  15ab61865ecbd146f6ce65fbea5bf49bfd9c6cb1
tools/libxc: fix error handling in xc_mem_paging_load

xc_mem_paging_load() does not pass errors in errno and the actual errno
from xc_mem_event_control() is overwritten by munlock().
xenpaging_populate_page() needs to check errno, but with the switch to
xc_mem_paging_load() it could not receive ENOMEM anymore.

Update xc_mem_paging_load() to return -1 and preserve errno during
munlock().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 15ab61865ecb -r 1821b0e1ce16 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -68,23 +68,28 @@ int xc_mem_paging_prep(xc_interface *xch
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
                                 unsigned long gfn, void *buffer)
 {
-    int rc;
+    int rc, old_errno;
+
+    errno = -EINVAL;
 
     if ( !buffer )
-        return -EINVAL;
+        return -1;
 
     if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
-        return -EINVAL;
+        return -1;
 
     if ( mlock(buffer, XC_PAGE_SIZE) )
-        return -errno;
+        return -1;
         
     rc = xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
                                 buffer, NULL, gfn);
 
-    (void)munlock(buffer, XC_PAGE_SIZE);
+    old_errno = errno;
+    munlock(buffer, XC_PAGE_SIZE);
+    errno = old_errno;
+
     return rc;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:16:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17: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 1RnZ6w-0008MF-Vl; Wed, 18 Jan 2012 17:15:46 +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 1RnZ6u-0008La-RP
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:15:45 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326906938!9071074!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzMyMzk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMzMyMzk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32691 invoked from network); 18 Jan 2012 17:15:38 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 17:15:38 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326906938; l=1487;
	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=CLCu9k6LKo1gCl1TBXEteZSR1wQ=;
	b=CLV8oLt1RQssSp3XImgu+2NfaMYZu8EhZ2v8UYypFrdBE7fopzfMSJtkLJhKW5NeKt4
	i5nurVYaV3U2IV58DmgN0ispiK9uKzCLFp1dq7+EO2ynj7PCl6cKm/K308Ab+6oxAIKx2
	HuZl150XL9/mXkRqGGcanrcSzeHu0eTEkOg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0MF3Z/
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-248.pools.arcor-ip.net [88.65.73.248])
	by smtp.strato.de (cohen mo7) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 606a5ao0IFg72D
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 18:15:28 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 46C8F18634
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 18:15:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1821b0e1ce16d0015542d4164505d97f130f09d7
Message-Id: <1821b0e1ce16d0015542.1326906924@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Wed, 18 Jan 2012 18:15:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: fix error handling in
	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

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326906775 -3600
# Node ID 1821b0e1ce16d0015542d4164505d97f130f09d7
# Parent  15ab61865ecbd146f6ce65fbea5bf49bfd9c6cb1
tools/libxc: fix error handling in xc_mem_paging_load

xc_mem_paging_load() does not pass errors in errno and the actual errno
from xc_mem_event_control() is overwritten by munlock().
xenpaging_populate_page() needs to check errno, but with the switch to
xc_mem_paging_load() it could not receive ENOMEM anymore.

Update xc_mem_paging_load() to return -1 and preserve errno during
munlock().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 15ab61865ecb -r 1821b0e1ce16 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -68,23 +68,28 @@ int xc_mem_paging_prep(xc_interface *xch
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
                                 unsigned long gfn, void *buffer)
 {
-    int rc;
+    int rc, old_errno;
+
+    errno = -EINVAL;
 
     if ( !buffer )
-        return -EINVAL;
+        return -1;
 
     if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
-        return -EINVAL;
+        return -1;
 
     if ( mlock(buffer, XC_PAGE_SIZE) )
-        return -errno;
+        return -1;
         
     rc = xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
                                 buffer, NULL, gfn);
 
-    (void)munlock(buffer, XC_PAGE_SIZE);
+    old_errno = errno;
+    munlock(buffer, XC_PAGE_SIZE);
+    errno = old_errno;
+
     return rc;
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:31:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:31:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZL0-0000fJ-IA; Wed, 18 Jan 2012 17:30: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 1RnZKy-0000fE-OK
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:30:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326907810!5486723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12635 invoked from network); 18 Jan 2012 17:30:10 -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 Jan 2012 17:30:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10122992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 17:30: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, 18 Jan 2012 17:30: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
	1RnZ4l-0006Bf-OU; Wed, 18 Jan 2012 17:13:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RnZ4l-0003yg-NY;
	Wed, 18 Jan 2012 17:13:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20246.64955.717774.909586@mariner.uk.xensource.com>
Date: Wed, 18 Jan 2012 17:13:31 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326886420.14689.206.camel@zakaz.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1326886420.14689.206.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
 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 ("Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios stubdom"):
> One thing which might help is to provide nop versions of functions
> instead of idef'ing both the definition and callsite. e.g. 
>  static void write_pidfile(const char *pidfile)
> +#ifndef __MINIOS__
>      stuff
> +#else
> +    nothing
> +endif

I would normally prefer:

> +#ifndef __MINIOS__
>  static void write_pidfile(const char *pidfile)
>      stuff
>  }
> +#else
> +static void write_pidfile(const char *pidfile)
> +}
> +endif

I think this is fairly easy to read; the only hard part is figuring
out which version is being used, which can often be done by putting
the relevant bits in a separate file.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:31:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:31:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZL0-0000fJ-IA; Wed, 18 Jan 2012 17:30: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 1RnZKy-0000fE-OK
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:30:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1326907810!5486723!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12635 invoked from network); 18 Jan 2012 17:30:10 -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 Jan 2012 17:30:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10122992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 17:30: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, 18 Jan 2012 17:30: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
	1RnZ4l-0006Bf-OU; Wed, 18 Jan 2012 17:13:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RnZ4l-0003yg-NY;
	Wed, 18 Jan 2012 17:13:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20246.64955.717774.909586@mariner.uk.xensource.com>
Date: Wed, 18 Jan 2012 17:13:31 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1326886420.14689.206.camel@zakaz.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1326886420.14689.206.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
 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 ("Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios stubdom"):
> One thing which might help is to provide nop versions of functions
> instead of idef'ing both the definition and callsite. e.g. 
>  static void write_pidfile(const char *pidfile)
> +#ifndef __MINIOS__
>      stuff
> +#else
> +    nothing
> +endif

I would normally prefer:

> +#ifndef __MINIOS__
>  static void write_pidfile(const char *pidfile)
>      stuff
>  }
> +#else
> +static void write_pidfile(const char *pidfile)
> +}
> +endif

I think this is fairly easy to read; the only hard part is figuring
out which version is being used, which can often be done by putting
the relevant bits in a separate file.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:34:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17: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 1RnZO9-0000lc-5q; Wed, 18 Jan 2012 17:33:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnZO7-0000lV-An
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:33:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326908005!1609895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23866 invoked from network); 18 Jan 2012 17:33:25 -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;
	18 Jan 2012 17:33:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10123041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 17:33: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, 18 Jan 2012 17:33:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 17:33:24 +0000
In-Reply-To: <1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326908004.14689.296.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/9] 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, 2012-01-13 at 19:25 +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.
> 
> The new "libxl_event" structure is blacklisted in the ocaml bindings
> for two reasons:
>   - It has a field name "type" (which is a keyword in ocaml);
>     the ocaml idl generator should massage this field name on
>     output, to "type_" perhaps.
>   - The ocaml idl generator does not support KeyedUnion.
> 
> 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      |  236 ++++++++++++++++++++++++++---
>  tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
>  tools/libxl/libxl_internal.h   |   77 +++++++++-
>  tools/libxl/libxl_types.idl    |   34 ++++-
>  tools/libxl/xl_cmdimpl.c       |  270 +++++++++++++++++++--------------
>  tools/ocaml/libs/xl/genwrap.py |    1 +
>  8 files changed, 908 insertions(+), 277 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 413b684..19ff12c 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -95,6 +115,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);

Why a helper for deaths but not ejects?

[...]

> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index ec66340..621a7cc 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c

> 
>  /*
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 63ef65e..0e83800 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h

> +#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;

libxl_event_{wait,check} and LIBXL_EVENTMASK_ALL have an unsigned long
mask. Are they not the same set of bits?

[...]

> + * 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.

Does anything actually guarantee that sizeof(uint64_t) >
sizeof(intptr_t)? I'm sure it's true in practice and I'm happy to rely
on it. Just interested.

> + *[...]

> + * 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.  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.
> + */
[...]
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 574dec7..a6dac79 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
>      ("extratime", integer),
>      ("weight", integer),
>      ], dispose_fn=None)
> +
> +libxl_event_type = Enumeration("event_type", [
> +    (1, "DOMAIN_SHUTDOWN"),
> +    (2, "DOMAIN_DESTROY"),
> +    (3, "DISK_EJECT"),
> +    ])
> +
> +libxl_ev_user = UInt(64)

The other option here would be Builtin(...) and an entry in the builtin
table in the wrapper generator. 

Arguably the idl could be improved by causing Number() to have a width
field. Currently it has a signedness and width is a property of UInt but
the latter could be pushed up the hierarchy.

You'd still end up with 
	FOO = Number("FOO", width=X)
which isn't really much better.

Or the ocaml generate could handle Number as the biggest int.

Hrm. None of that seems all that much better than what you have. Chalk
it up to potential future work.

> +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
> +
> +libxl_event = Struct("event",[
> +    ("link",     libxl_ev_link,0),

This "0" == "const=False" which is the default. I don't think it is
necessary.

[...]
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 8c30de1..e292bfc 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c

> @@ -1702,92 +1729,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);

I didn't see this getting freed on the exit path.

> +        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;
> +    }

This is all (I think) safe for num_disks == 0 but why waste the effort?

Incidentally we have libxl_device_disk.removable which might be an
opportunity to optimise? Assuming it is meaningful in that way. I think
in reality only emulated CD-ROM devices ever generate this event but
perhaps exposing that in the API overcomplicates things.

[...]

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:34:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17: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 1RnZO9-0000lc-5q; Wed, 18 Jan 2012 17:33:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnZO7-0000lV-An
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:33:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1326908005!1609895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23866 invoked from network); 18 Jan 2012 17:33:25 -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;
	18 Jan 2012 17:33:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10123041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 17:33: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, 18 Jan 2012 17:33:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 17:33:24 +0000
In-Reply-To: <1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326908004.14689.296.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/9] 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, 2012-01-13 at 19:25 +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.
> 
> The new "libxl_event" structure is blacklisted in the ocaml bindings
> for two reasons:
>   - It has a field name "type" (which is a keyword in ocaml);
>     the ocaml idl generator should massage this field name on
>     output, to "type_" perhaps.
>   - The ocaml idl generator does not support KeyedUnion.
> 
> 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      |  236 ++++++++++++++++++++++++++---
>  tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
>  tools/libxl/libxl_internal.h   |   77 +++++++++-
>  tools/libxl/libxl_types.idl    |   34 ++++-
>  tools/libxl/xl_cmdimpl.c       |  270 +++++++++++++++++++--------------
>  tools/ocaml/libs/xl/genwrap.py |    1 +
>  8 files changed, 908 insertions(+), 277 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 413b684..19ff12c 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -95,6 +115,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);

Why a helper for deaths but not ejects?

[...]

> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index ec66340..621a7cc 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c

> 
>  /*
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 63ef65e..0e83800 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h

> +#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;

libxl_event_{wait,check} and LIBXL_EVENTMASK_ALL have an unsigned long
mask. Are they not the same set of bits?

[...]

> + * 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.

Does anything actually guarantee that sizeof(uint64_t) >
sizeof(intptr_t)? I'm sure it's true in practice and I'm happy to rely
on it. Just interested.

> + *[...]

> + * 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.  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.
> + */
[...]
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 574dec7..a6dac79 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
>      ("extratime", integer),
>      ("weight", integer),
>      ], dispose_fn=None)
> +
> +libxl_event_type = Enumeration("event_type", [
> +    (1, "DOMAIN_SHUTDOWN"),
> +    (2, "DOMAIN_DESTROY"),
> +    (3, "DISK_EJECT"),
> +    ])
> +
> +libxl_ev_user = UInt(64)

The other option here would be Builtin(...) and an entry in the builtin
table in the wrapper generator. 

Arguably the idl could be improved by causing Number() to have a width
field. Currently it has a signedness and width is a property of UInt but
the latter could be pushed up the hierarchy.

You'd still end up with 
	FOO = Number("FOO", width=X)
which isn't really much better.

Or the ocaml generate could handle Number as the biggest int.

Hrm. None of that seems all that much better than what you have. Chalk
it up to potential future work.

> +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
> +
> +libxl_event = Struct("event",[
> +    ("link",     libxl_ev_link,0),

This "0" == "const=False" which is the default. I don't think it is
necessary.

[...]
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 8c30de1..e292bfc 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c

> @@ -1702,92 +1729,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);

I didn't see this getting freed on the exit path.

> +        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;
> +    }

This is all (I think) safe for num_disks == 0 but why waste the effort?

Incidentally we have libxl_device_disk.removable which might be an
opportunity to optimise? Assuming it is meaningful in that way. I think
in reality only emulated CD-ROM devices ever generate this event but
perhaps exposing that in the API overcomplicates things.

[...]

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:36:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZPo-0000u8-U5; Wed, 18 Jan 2012 17:35:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnZPm-0000tG-Ep
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326908107!9682149!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25837 invoked from network); 18 Jan 2012 17:35:08 -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;
	18 Jan 2012 17:35:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10123069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 17:35: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, 18 Jan 2012 17:35:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 17:35:07 +0000
In-Reply-To: <20246.64955.717774.909586@mariner.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1326886420.14689.206.camel@zakaz.uk.xensource.com>
	<20246.64955.717774.909586@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326908107.14689.298.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-18 at 17:13 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios stubdom"):
> > One thing which might help is to provide nop versions of functions
> > instead of idef'ing both the definition and callsite. e.g. 
> >  static void write_pidfile(const char *pidfile)
> > +#ifndef __MINIOS__
> >      stuff
> > +#else
> > +    nothing
> > +endif
> 
> I would normally prefer:
> 
> > +#ifndef __MINIOS__
> >  static void write_pidfile(const char *pidfile)
> >      stuff
> >  }
> > +#else
> > +static void write_pidfile(const char *pidfile)
> > +}
> > +endif

Yes, I'd normally do it this way too, not sure why I wrote the other...

Only real difference is that it prevents the prototype getting out of
sync and bit-rotting the infrequently used case if there is one.

Ian.

> I think this is fairly easy to read; the only hard part is figuring
> out which version is being used, which can often be done by putting
> the relevant bits in a separate file.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:36:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:36:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZPo-0000u8-U5; Wed, 18 Jan 2012 17:35:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnZPm-0000tG-Ep
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:35:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326908107!9682149!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25837 invoked from network); 18 Jan 2012 17:35:08 -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;
	18 Jan 2012 17:35:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,529,1320624000"; d="scan'208";a="10123069"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 17:35: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, 18 Jan 2012 17:35:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 17:35:07 +0000
In-Reply-To: <20246.64955.717774.909586@mariner.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1326886420.14689.206.camel@zakaz.uk.xensource.com>
	<20246.64955.717774.909586@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326908107.14689.298.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-18 at 17:13 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios stubdom"):
> > One thing which might help is to provide nop versions of functions
> > instead of idef'ing both the definition and callsite. e.g. 
> >  static void write_pidfile(const char *pidfile)
> > +#ifndef __MINIOS__
> >      stuff
> > +#else
> > +    nothing
> > +endif
> 
> I would normally prefer:
> 
> > +#ifndef __MINIOS__
> >  static void write_pidfile(const char *pidfile)
> >      stuff
> >  }
> > +#else
> > +static void write_pidfile(const char *pidfile)
> > +}
> > +endif

Yes, I'd normally do it this way too, not sure why I wrote the other...

Only real difference is that it prevents the prototype getting out of
sync and bit-rotting the infrequently used case if there is one.

Ian.

> I think this is fairly easy to read; the only hard part is figuring
> out which version is being used, which can often be done by putting
> the relevant bits in a separate file.
> 
> Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:38:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:38:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZSG-00019o-D4; Wed, 18 Jan 2012 17:37: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 1RnZSF-000194-8o
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:37:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326908259!9700981!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 15635 invoked from network); 18 Jan 2012 17:37:41 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 17:37:41 -0000
Received: by pbcc6 with SMTP id c6so34167336pbc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 09:37: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=lk2ZM5eKr12pbu9/EA3TDxtT4ErzEuNLxix71ETdiec=;
	b=XfStK5radccOvmOgb78FyJr/NLZHKL7hTvE4Djg+dQ0tXLqe36j9t19rNoYH26cpHH
	7cLbdBTn8/2NlxIktsB6hERocARtBe3wWE6reaDKG+G+qhzHOGtEW4n43g77g2qGwT8f
	sJzOc4HTW9/4uWkqZy25BE8TUG4+zSfOJEHfU=
MIME-Version: 1.0
Received: by 10.68.211.104 with SMTP id nb8mr37691304pbc.39.1326908254296;
	Wed, 18 Jan 2012 09:37:34 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 18 Jan 2012 09:37:34 -0800 (PST)
In-Reply-To: <20120118162122.GA14232@aepfle.de>
References: <20120118162122.GA14232@aepfle.de>
Date: Wed, 18 Jan 2012 18:37:34 +0100
X-Google-Sender-Auth: mRzs-hp7SitXwTb4gNLrhM2rYjM
Message-ID: <CAPLaKK7aEG6jR-ABNo0jHsqK+56K0=1Nm_fsi7T-JW+HEa7wTA@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
Subject: Re: [Xen-devel] ioctl handling in netbsd_privcmd_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE4IE9sYWYgSGVyaW5nIDxvbGFmQGFlcGZsZS5kZT46Cj4KPiBJIHdhcyBsb29raW5n
IGF0IHRoZSBzbGlnaHRseSBicm9rZW4gZXJyb3IgaGFuZGxpbmcgaW4gdGhlIG5ldwo+IHhjX21l
bV9wYWdpbmdfbG9hZCgpIGZ1bmN0aW9uIGFuZCBzdHVtYmxlZCBvdmVyIHRoZSBpb2N0bCgpIGhh
bmRsaW5nIGluCj4gbmV0YnNkX3ByaXZjbWRfaHlwZXJjYWxsKCkuCj4KPiBJcyBpb2N0bCgpIG9u
IE5ldEJTRCBzcGVjaWFsPyBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgaXQgcmV0dXJucyAtMSBvbgo+
IGVycm9yIGFuZCB0aGUgY2FsbGVyIGNhbiBkZWFsIHdpdGggZXJybm8gaWYgaXQgYWN0dWFsbHkg
d2FudHMgdG8uCj4gQnV0IGluc3RlYWQgaXQgcmV0dXJucyB0aGUgbmVnYXRpdmUgZXJybm8gdmFs
dWUgb3Igd2hhdCB0aGUgaHlwZXJ2aXNvcgo+IHJldHVybmVkLgoKSSBoYXZlbid0IGRvbmUgdGhp
cyBjb2RlLCBzbyBJIGRvbid0IGtub3cgaWYgdGhlcmUgYXJlIHNvbWUgaGlkZGVuCnN1YnRsZXRp
ZXMgaGVyZSwgYnV0IGFjY29yZGluZyB0byBOZXRCU0QgaW9jdGwoMikgbWFuIHBhZ2VbMF0sIGl0
CnJldHVybnMgLTEgb24gZXJyb3IgYW5kIGVycm5vIGlzIHNldCB0byBpbmRpY2F0ZSB0aGUgZXJy
b3IuCgo+IHN0YXRpYyBpbnQgbmV0YnNkX3ByaXZjbWRfaHlwZXJjYWxsKHhjX2ludGVyZmFjZSAq
eGNoLCB4Y19vc2RlcF9oYW5kbGUgaCwgcHJpdmNtZF9oeXBlcmNhbGxfdCAqaHlwZXJjYWxsKQo+
IHsKPiDCoCDCoGludCBmZCA9IChpbnQpaDsKPiDCoCDCoGludCBlcnJvciA9IGlvY3RsKGZkLCBJ
T0NUTF9QUklWQ01EX0hZUEVSQ0FMTCwgaHlwZXJjYWxsKTsKPgo+IMKgIMKgaWYgKGVycm9yIDwg
MCkKPiDCoCDCoCDCoCDCoHJldHVybiAtZXJybm87Cj4gwqAgwqBlbHNlCj4gwqAgwqAgwqAgwqBy
ZXR1cm4gaHlwZXJjYWxsLT5yZXR2YWw7Cj4gfQo+Cj4gSSB0aGluayBkb19kb21jdGwoKSBpcyBz
dXBwb3NlZCB0byByZXR1cm4gLTEgb24gZXJyb3IgYW5kIGxldCB0aGUgY2FsbGVyCj4gZGVjaWRl
IHdoYXQgdG8gZG8uIEF0IGxlYXN0IHRoYXRzIGhvdyBpdHMgYXBwZWFyZW50bHkgZG9uZSBvbiBM
aW51eCBhbmQKPiBTb2xhcmlzLgoKWzBdIGh0dHA6Ly9uZXRic2QuZ3cuY29tL2NnaS1iaW4vbWFu
LWNnaT9pb2N0bCsuYW1kNjQrTmV0QlNELWN1cnJlbnQKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xensource.com Wed Jan 18 17:38:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 17:38:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZSG-00019o-D4; Wed, 18 Jan 2012 17:37: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 1RnZSF-000194-8o
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 17:37:47 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326908259!9700981!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 15635 invoked from network); 18 Jan 2012 17:37:41 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 17:37:41 -0000
Received: by pbcc6 with SMTP id c6so34167336pbc.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 09:37: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=lk2ZM5eKr12pbu9/EA3TDxtT4ErzEuNLxix71ETdiec=;
	b=XfStK5radccOvmOgb78FyJr/NLZHKL7hTvE4Djg+dQ0tXLqe36j9t19rNoYH26cpHH
	7cLbdBTn8/2NlxIktsB6hERocARtBe3wWE6reaDKG+G+qhzHOGtEW4n43g77g2qGwT8f
	sJzOc4HTW9/4uWkqZy25BE8TUG4+zSfOJEHfU=
MIME-Version: 1.0
Received: by 10.68.211.104 with SMTP id nb8mr37691304pbc.39.1326908254296;
	Wed, 18 Jan 2012 09:37:34 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Wed, 18 Jan 2012 09:37:34 -0800 (PST)
In-Reply-To: <20120118162122.GA14232@aepfle.de>
References: <20120118162122.GA14232@aepfle.de>
Date: Wed, 18 Jan 2012 18:37:34 +0100
X-Google-Sender-Auth: mRzs-hp7SitXwTb4gNLrhM2rYjM
Message-ID: <CAPLaKK7aEG6jR-ABNo0jHsqK+56K0=1Nm_fsi7T-JW+HEa7wTA@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
Subject: Re: [Xen-devel] ioctl handling in netbsd_privcmd_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE4IE9sYWYgSGVyaW5nIDxvbGFmQGFlcGZsZS5kZT46Cj4KPiBJIHdhcyBsb29raW5n
IGF0IHRoZSBzbGlnaHRseSBicm9rZW4gZXJyb3IgaGFuZGxpbmcgaW4gdGhlIG5ldwo+IHhjX21l
bV9wYWdpbmdfbG9hZCgpIGZ1bmN0aW9uIGFuZCBzdHVtYmxlZCBvdmVyIHRoZSBpb2N0bCgpIGhh
bmRsaW5nIGluCj4gbmV0YnNkX3ByaXZjbWRfaHlwZXJjYWxsKCkuCj4KPiBJcyBpb2N0bCgpIG9u
IE5ldEJTRCBzcGVjaWFsPyBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgaXQgcmV0dXJucyAtMSBvbgo+
IGVycm9yIGFuZCB0aGUgY2FsbGVyIGNhbiBkZWFsIHdpdGggZXJybm8gaWYgaXQgYWN0dWFsbHkg
d2FudHMgdG8uCj4gQnV0IGluc3RlYWQgaXQgcmV0dXJucyB0aGUgbmVnYXRpdmUgZXJybm8gdmFs
dWUgb3Igd2hhdCB0aGUgaHlwZXJ2aXNvcgo+IHJldHVybmVkLgoKSSBoYXZlbid0IGRvbmUgdGhp
cyBjb2RlLCBzbyBJIGRvbid0IGtub3cgaWYgdGhlcmUgYXJlIHNvbWUgaGlkZGVuCnN1YnRsZXRp
ZXMgaGVyZSwgYnV0IGFjY29yZGluZyB0byBOZXRCU0QgaW9jdGwoMikgbWFuIHBhZ2VbMF0sIGl0
CnJldHVybnMgLTEgb24gZXJyb3IgYW5kIGVycm5vIGlzIHNldCB0byBpbmRpY2F0ZSB0aGUgZXJy
b3IuCgo+IHN0YXRpYyBpbnQgbmV0YnNkX3ByaXZjbWRfaHlwZXJjYWxsKHhjX2ludGVyZmFjZSAq
eGNoLCB4Y19vc2RlcF9oYW5kbGUgaCwgcHJpdmNtZF9oeXBlcmNhbGxfdCAqaHlwZXJjYWxsKQo+
IHsKPiDCoCDCoGludCBmZCA9IChpbnQpaDsKPiDCoCDCoGludCBlcnJvciA9IGlvY3RsKGZkLCBJ
T0NUTF9QUklWQ01EX0hZUEVSQ0FMTCwgaHlwZXJjYWxsKTsKPgo+IMKgIMKgaWYgKGVycm9yIDwg
MCkKPiDCoCDCoCDCoCDCoHJldHVybiAtZXJybm87Cj4gwqAgwqBlbHNlCj4gwqAgwqAgwqAgwqBy
ZXR1cm4gaHlwZXJjYWxsLT5yZXR2YWw7Cj4gfQo+Cj4gSSB0aGluayBkb19kb21jdGwoKSBpcyBz
dXBwb3NlZCB0byByZXR1cm4gLTEgb24gZXJyb3IgYW5kIGxldCB0aGUgY2FsbGVyCj4gZGVjaWRl
IHdoYXQgdG8gZG8uIEF0IGxlYXN0IHRoYXRzIGhvdyBpdHMgYXBwZWFyZW50bHkgZG9uZSBvbiBM
aW51eCBhbmQKPiBTb2xhcmlzLgoKWzBdIGh0dHA6Ly9uZXRic2QuZ3cuY29tL2NnaS1iaW4vbWFu
LWNnaT9pb2N0bCsuYW1kNjQrTmV0QlNELWN1cnJlbnQKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVs
QGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVs
Cg==

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:02:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnZpb-0002tA-04; Wed, 18 Jan 2012 18:01:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RnZpa-0002sz-1S
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:01:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326909706!9240090!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjQwOTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjQwOTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9819 invoked from network); 18 Jan 2012 18:01:47 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 18:01:47 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326909706; l=1378;
	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=nRn9fp5hZvii1w/fsUz9kJHoevI=;
	b=Ya1VSpCSpeX5lWlcBRsDrWtxtt/+UBAgH8IUMokEyn9rDTMWvKpEaS3f6HT7aJPBACN
	wOQjT07H/fM6n/EM2WmDsRA1Oi0J1GuTSVg18hqfF73z4W04gYJienBJjw/4lEAlq2FlC
	IqYooLXbngPH/r6mfIlq5K1IOIPanyKAaqQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0MF3Z/
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-248.pools.arcor-ip.net [88.65.73.248])
	by smtp.strato.de (cohen mo36) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x05549o0IHoqQ1 ;
	Wed, 18 Jan 2012 19:01:27 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D2B0E18637; Wed, 18 Jan 2012 19:01:23 +0100 (CET)
Date: Wed, 18 Jan 2012 19:01:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@entel.upc.edu>
Message-ID: <20120118180123.GA7169@aepfle.de>
References: <20120118162122.GA14232@aepfle.de>
	<CAPLaKK7aEG6jR-ABNo0jHsqK+56K0=1Nm_fsi7T-JW+HEa7wTA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK7aEG6jR-ABNo0jHsqK+56K0=1Nm_fsi7T-JW+HEa7wTA@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] ioctl handling in netbsd_privcmd_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBKYW4gMTgsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cgo+IDIwMTIvMS8xOCBPbGFm
IEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+Ogo+ID4KPiA+IEkgd2FzIGxvb2tpbmcgYXQgdGhlIHNs
aWdodGx5IGJyb2tlbiBlcnJvciBoYW5kbGluZyBpbiB0aGUgbmV3Cj4gPiB4Y19tZW1fcGFnaW5n
X2xvYWQoKSBmdW5jdGlvbiBhbmQgc3R1bWJsZWQgb3ZlciB0aGUgaW9jdGwoKSBoYW5kbGluZyBp
bgo+ID4gbmV0YnNkX3ByaXZjbWRfaHlwZXJjYWxsKCkuCj4gPgo+ID4gSXMgaW9jdGwoKSBvbiBO
ZXRCU0Qgc3BlY2lhbD8gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIGl0IHJldHVybnMgLTEgb24KPiA+
IGVycm9yIGFuZCB0aGUgY2FsbGVyIGNhbiBkZWFsIHdpdGggZXJybm8gaWYgaXQgYWN0dWFsbHkg
d2FudHMgdG8uCj4gPiBCdXQgaW5zdGVhZCBpdCByZXR1cm5zIHRoZSBuZWdhdGl2ZSBlcnJubyB2
YWx1ZSBvciB3aGF0IHRoZSBoeXBlcnZpc29yCj4gPiByZXR1cm5lZC4KPiAKPiBJIGhhdmVuJ3Qg
ZG9uZSB0aGlzIGNvZGUsIHNvIEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBhcmUgc29tZSBoaWRkZW4K
PiBzdWJ0bGV0aWVzIGhlcmUsIGJ1dCBhY2NvcmRpbmcgdG8gTmV0QlNEIGlvY3RsKDIpIG1hbiBw
YWdlWzBdLCBpdAo+IHJldHVybnMgLTEgb24gZXJyb3IgYW5kIGVycm5vIGlzIHNldCB0byBpbmRp
Y2F0ZSB0aGUgZXJyb3IuCgpDb3VsZCB5b3UgY2hlY2sgd2V0aGVyIGEgInJldHVybiBpb2N0bCgu
Li4uKTsiIHdvcmtzIGFzIHdlbGw/CgpPbGFmCgo+ID4gc3RhdGljIGludCBuZXRic2RfcHJpdmNt
ZF9oeXBlcmNhbGwoeGNfaW50ZXJmYWNlICp4Y2gsIHhjX29zZGVwX2hhbmRsZSBoLCBwcml2Y21k
X2h5cGVyY2FsbF90ICpoeXBlcmNhbGwpCj4gPiB7Cj4gPiDCoCDCoGludCBmZCA9IChpbnQpaDsK
PiA+IMKgIMKgaW50IGVycm9yID0gaW9jdGwoZmQsIElPQ1RMX1BSSVZDTURfSFlQRVJDQUxMLCBo
eXBlcmNhbGwpOwo+ID4KPiA+IMKgIMKgaWYgKGVycm9yIDwgMCkKPiA+IMKgIMKgIMKgIMKgcmV0
dXJuIC1lcnJubzsKPiA+IMKgIMKgZWxzZQo+ID4gwqAgwqAgwqAgwqByZXR1cm4gaHlwZXJjYWxs
LT5yZXR2YWw7Cj4gPiB9Cj4gPgo+ID4gSSB0aGluayBkb19kb21jdGwoKSBpcyBzdXBwb3NlZCB0
byByZXR1cm4gLTEgb24gZXJyb3IgYW5kIGxldCB0aGUgY2FsbGVyCj4gPiBkZWNpZGUgd2hhdCB0
byBkby4gQXQgbGVhc3QgdGhhdHMgaG93IGl0cyBhcHBlYXJlbnRseSBkb25lIG9uIExpbnV4IGFu
ZAo+ID4gU29sYXJpcy4KPiAKPiBbMF0gaHR0cDovL25ldGJzZC5ndy5jb20vY2dpLWJpbi9tYW4t
Y2dpP2lvY3RsKy5hbWQ2NCtOZXRCU0QtY3VycmVudAoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:02:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 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 1RnZpb-0002tA-04; Wed, 18 Jan 2012 18:01:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RnZpa-0002sz-1S
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:01:54 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326909706!9240090!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjQwOTk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMjQwOTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9819 invoked from network); 18 Jan 2012 18:01:47 -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 DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 18:01:47 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326909706; l=1378;
	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=nRn9fp5hZvii1w/fsUz9kJHoevI=;
	b=Ya1VSpCSpeX5lWlcBRsDrWtxtt/+UBAgH8IUMokEyn9rDTMWvKpEaS3f6HT7aJPBACN
	wOQjT07H/fM6n/EM2WmDsRA1Oi0J1GuTSVg18hqfF73z4W04gYJienBJjw/4lEAlq2FlC
	IqYooLXbngPH/r6mfIlq5K1IOIPanyKAaqQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJjS0MF3Z/
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-073-248.pools.arcor-ip.net [88.65.73.248])
	by smtp.strato.de (cohen mo36) (RZmta 27.4 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id x05549o0IHoqQ1 ;
	Wed, 18 Jan 2012 19:01:27 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D2B0E18637; Wed, 18 Jan 2012 19:01:23 +0100 (CET)
Date: Wed, 18 Jan 2012 19:01:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Roger Pau =?utf-8?B?TW9ubsOp?= <roger.pau@entel.upc.edu>
Message-ID: <20120118180123.GA7169@aepfle.de>
References: <20120118162122.GA14232@aepfle.de>
	<CAPLaKK7aEG6jR-ABNo0jHsqK+56K0=1Nm_fsi7T-JW+HEa7wTA@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK7aEG6jR-ABNo0jHsqK+56K0=1Nm_fsi7T-JW+HEa7wTA@mail.gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] ioctl handling in netbsd_privcmd_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBKYW4gMTgsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cgo+IDIwMTIvMS8xOCBPbGFm
IEhlcmluZyA8b2xhZkBhZXBmbGUuZGU+Ogo+ID4KPiA+IEkgd2FzIGxvb2tpbmcgYXQgdGhlIHNs
aWdodGx5IGJyb2tlbiBlcnJvciBoYW5kbGluZyBpbiB0aGUgbmV3Cj4gPiB4Y19tZW1fcGFnaW5n
X2xvYWQoKSBmdW5jdGlvbiBhbmQgc3R1bWJsZWQgb3ZlciB0aGUgaW9jdGwoKSBoYW5kbGluZyBp
bgo+ID4gbmV0YnNkX3ByaXZjbWRfaHlwZXJjYWxsKCkuCj4gPgo+ID4gSXMgaW9jdGwoKSBvbiBO
ZXRCU0Qgc3BlY2lhbD8gSSB3b3VsZCBoYXZlIGV4cGVjdGVkIGl0IHJldHVybnMgLTEgb24KPiA+
IGVycm9yIGFuZCB0aGUgY2FsbGVyIGNhbiBkZWFsIHdpdGggZXJybm8gaWYgaXQgYWN0dWFsbHkg
d2FudHMgdG8uCj4gPiBCdXQgaW5zdGVhZCBpdCByZXR1cm5zIHRoZSBuZWdhdGl2ZSBlcnJubyB2
YWx1ZSBvciB3aGF0IHRoZSBoeXBlcnZpc29yCj4gPiByZXR1cm5lZC4KPiAKPiBJIGhhdmVuJ3Qg
ZG9uZSB0aGlzIGNvZGUsIHNvIEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBhcmUgc29tZSBoaWRkZW4K
PiBzdWJ0bGV0aWVzIGhlcmUsIGJ1dCBhY2NvcmRpbmcgdG8gTmV0QlNEIGlvY3RsKDIpIG1hbiBw
YWdlWzBdLCBpdAo+IHJldHVybnMgLTEgb24gZXJyb3IgYW5kIGVycm5vIGlzIHNldCB0byBpbmRp
Y2F0ZSB0aGUgZXJyb3IuCgpDb3VsZCB5b3UgY2hlY2sgd2V0aGVyIGEgInJldHVybiBpb2N0bCgu
Li4uKTsiIHdvcmtzIGFzIHdlbGw/CgpPbGFmCgo+ID4gc3RhdGljIGludCBuZXRic2RfcHJpdmNt
ZF9oeXBlcmNhbGwoeGNfaW50ZXJmYWNlICp4Y2gsIHhjX29zZGVwX2hhbmRsZSBoLCBwcml2Y21k
X2h5cGVyY2FsbF90ICpoeXBlcmNhbGwpCj4gPiB7Cj4gPiDCoCDCoGludCBmZCA9IChpbnQpaDsK
PiA+IMKgIMKgaW50IGVycm9yID0gaW9jdGwoZmQsIElPQ1RMX1BSSVZDTURfSFlQRVJDQUxMLCBo
eXBlcmNhbGwpOwo+ID4KPiA+IMKgIMKgaWYgKGVycm9yIDwgMCkKPiA+IMKgIMKgIMKgIMKgcmV0
dXJuIC1lcnJubzsKPiA+IMKgIMKgZWxzZQo+ID4gwqAgwqAgwqAgwqByZXR1cm4gaHlwZXJjYWxs
LT5yZXR2YWw7Cj4gPiB9Cj4gPgo+ID4gSSB0aGluayBkb19kb21jdGwoKSBpcyBzdXBwb3NlZCB0
byByZXR1cm4gLTEgb24gZXJyb3IgYW5kIGxldCB0aGUgY2FsbGVyCj4gPiBkZWNpZGUgd2hhdCB0
byBkby4gQXQgbGVhc3QgdGhhdHMgaG93IGl0cyBhcHBlYXJlbnRseSBkb25lIG9uIExpbnV4IGFu
ZAo+ID4gU29sYXJpcy4KPiAKPiBbMF0gaHR0cDovL25ldGJzZC5ndy5jb20vY2dpLWJpbi9tYW4t
Y2dpP2lvY3RsKy5hbWQ2NCtOZXRCU0QtY3VycmVudAoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxA
bGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:07:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZuF-00031z-OO; Wed, 18 Jan 2012 18:06:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tom.goetz@virtualcomputer.com>) id 1RnZuE-00031o-JM
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:06:42 +0000
X-Env-Sender: tom.goetz@virtualcomputer.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326909994!11583053!1
X-Originating-IP: [72.32.253.73]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMzIuMjUzLjczID0+IDE5MDMwMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15347 invoked from network); 18 Jan 2012 18:06:36 -0000
Received: from server514f.exghost.com (HELO server514.appriver.com)
	(72.32.253.73)
	by server-15.tower-216.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	18 Jan 2012 18:06:36 -0000
X-Note-AR-ScanTimeLocal: 1/18/2012 12:06:34 PM
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Primary: tom.goetz@virtualcomputer.com
X-Note: This Email was scanned by AppRiver SecureTide
X-ALLOW: @virtualcomputer.com ALLOWED
X-Virus-Scan: V-
X-Note: Spam Tests Failed: 
X-Country-Path: UNITED STATES->UNITED STATES->UNITED STATES->UNITED STATES
X-Note-Sending-IP: 72.32.253.65
X-Note-Reverse-DNS: 
X-Note-Return-Path: tom.goetz@virtualcomputer.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G211 G212 G213 G214 G218 G219 G230 G321 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: ALLOWEDSENDER
X-Note: Headers Injected
Received: from [72.32.253.65] (HELO FE06.exg4.exghost.com)
	by server514.appriver.com (CommuniGate Pro SMTP 5.4.3k)
	with ESMTP id 192374213; Wed, 18 Jan 2012 12:06:34 -0600
Received: from FE06.exg4.exghost.com ([72.32.253.161]) by
	FE06.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 18 Jan 2012 12:06:33 -0600
Received: from orion.oldroadcomputing.net ([67.192.118.157]) by
	FE06.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 18 Jan 2012 12:06:33 -0600
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Tom Goetz <tom.goetz@virtualcomputer.com>
In-Reply-To: <20120118165130.GC24089@phenom.dumpdata.com>
Date: Wed, 18 Jan 2012 13:06:40 -0500
Message-Id: <38E758A7-C816-42BF-9A32-1FAD9F545D18@virtualcomputer.com>
References: <1CB9139E-4600-4DBD-8F96-9061675DE9C2@virtualcomputer.com>
	<20120117210904.GB23782@phenom.dumpdata.com>
	<6EF87F6D-AD48-4DA9-BAD8-2FCB2C980C04@virtualcomputer.com>
	<20120118163456.GA24089@phenom.dumpdata.com>
	<79E94C03-B65F-4882-A744-EE6F27AF6C0D@virtualcomputer.com>
	<20120118165130.GC24089@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1251.1)
X-OriginalArrivalTime: 18 Jan 2012 18:06:33.0873 (UTC)
	FILETIME=[E994D010:01CCD60B]
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] 3.2 PVOPs Intel Crash
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Jan 18, 2012, at 11:51 AM, Konrad Rzeszutek Wilk wrote:

> On Wed, Jan 18, 2012 at 11:41:22AM -0500, Tom Goetz wrote:
> 
> CC-ing xen-devel and David.
> 
>> We have dom0_mem=672MB for Xen and mem=672MB for linux.
> 
> Ok, if you don't have the mem=X and have the "('x86: use 'dom0_mem' to limit
> the number of pages for dom0') (c/s 23790) in your hypervisor what happens?
> 
> And also have 'dom0_mem=max:672MB' do you get the same issue?

With dom0_mem= and no mem=, it boots fine.

>> 
>> but we have the same mem opt for 2.6.38 and 3.2 and the mem code still has the e820_remove_range in 3.2. Dom0 is showing the right amount of mem when booted on other machines, so I don't think the mem= option is failing. 
> 
> The 'mem=X' argument I remember being a work-around. The original bug had been fixed in both
> hypervisor and in the kernel.

I checked with the guy who added the mem= option and he doesn't remember why. I going to remove and go from there. Thanks!






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:07:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18:07:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnZuF-00031z-OO; Wed, 18 Jan 2012 18:06:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tom.goetz@virtualcomputer.com>) id 1RnZuE-00031o-JM
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:06:42 +0000
X-Env-Sender: tom.goetz@virtualcomputer.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326909994!11583053!1
X-Originating-IP: [72.32.253.73]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNzIuMzIuMjUzLjczID0+IDE5MDMwMg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15347 invoked from network); 18 Jan 2012 18:06:36 -0000
Received: from server514f.exghost.com (HELO server514.appriver.com)
	(72.32.253.73)
	by server-15.tower-216.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	18 Jan 2012 18:06:36 -0000
X-Note-AR-ScanTimeLocal: 1/18/2012 12:06:34 PM
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Policy: GLOBAL - virtualcomputer.com
X-Primary: tom.goetz@virtualcomputer.com
X-Note: This Email was scanned by AppRiver SecureTide
X-ALLOW: @virtualcomputer.com ALLOWED
X-Virus-Scan: V-
X-Note: Spam Tests Failed: 
X-Country-Path: UNITED STATES->UNITED STATES->UNITED STATES->UNITED STATES
X-Note-Sending-IP: 72.32.253.65
X-Note-Reverse-DNS: 
X-Note-Return-Path: tom.goetz@virtualcomputer.com
X-Note: User Rule Hits: 
X-Note: Global Rule Hits: G211 G212 G213 G214 G218 G219 G230 G321 
X-Note: Encrypt Rule Hits: 
X-Note: Mail Class: ALLOWEDSENDER
X-Note: Headers Injected
Received: from [72.32.253.65] (HELO FE06.exg4.exghost.com)
	by server514.appriver.com (CommuniGate Pro SMTP 5.4.3k)
	with ESMTP id 192374213; Wed, 18 Jan 2012 12:06:34 -0600
Received: from FE06.exg4.exghost.com ([72.32.253.161]) by
	FE06.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 18 Jan 2012 12:06:33 -0600
Received: from orion.oldroadcomputing.net ([67.192.118.157]) by
	FE06.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.4675); 
	Wed, 18 Jan 2012 12:06:33 -0600
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Tom Goetz <tom.goetz@virtualcomputer.com>
In-Reply-To: <20120118165130.GC24089@phenom.dumpdata.com>
Date: Wed, 18 Jan 2012 13:06:40 -0500
Message-Id: <38E758A7-C816-42BF-9A32-1FAD9F545D18@virtualcomputer.com>
References: <1CB9139E-4600-4DBD-8F96-9061675DE9C2@virtualcomputer.com>
	<20120117210904.GB23782@phenom.dumpdata.com>
	<6EF87F6D-AD48-4DA9-BAD8-2FCB2C980C04@virtualcomputer.com>
	<20120118163456.GA24089@phenom.dumpdata.com>
	<79E94C03-B65F-4882-A744-EE6F27AF6C0D@virtualcomputer.com>
	<20120118165130.GC24089@phenom.dumpdata.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
X-Mailer: Apple Mail (2.1251.1)
X-OriginalArrivalTime: 18 Jan 2012 18:06:33.0873 (UTC)
	FILETIME=[E994D010:01CCD60B]
Cc: xen-devel@lists.xensource.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] 3.2 PVOPs Intel Crash
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Jan 18, 2012, at 11:51 AM, Konrad Rzeszutek Wilk wrote:

> On Wed, Jan 18, 2012 at 11:41:22AM -0500, Tom Goetz wrote:
> 
> CC-ing xen-devel and David.
> 
>> We have dom0_mem=672MB for Xen and mem=672MB for linux.
> 
> Ok, if you don't have the mem=X and have the "('x86: use 'dom0_mem' to limit
> the number of pages for dom0') (c/s 23790) in your hypervisor what happens?
> 
> And also have 'dom0_mem=max:672MB' do you get the same issue?

With dom0_mem= and no mem=, it boots fine.

>> 
>> but we have the same mem opt for 2.6.38 and 3.2 and the mem code still has the e820_remove_range in 3.2. Dom0 is showing the right amount of mem when booted on other machines, so I don't think the mem= option is failing. 
> 
> The 'mem=X' argument I remember being a work-around. The original bug had been fixed in both
> hypervisor and in the kernel.

I checked with the guy who added the mem= option and he doesn't remember why. I going to remove and go from there. Thanks!






_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:19:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18: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 1Rna6E-0004Aj-C2; Wed, 18 Jan 2012 18:19:06 +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 1Rna6C-0004AQ-4u
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:19:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326910737!2778577!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 22267 invoked from network); 18 Jan 2012 18:18:57 -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;
	18 Jan 2012 18:18:57 -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
	q0IIIsTP029255; Wed, 18 Jan 2012 18:18:54 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 q0IIIsJq001726; 
	Wed, 18 Jan 2012 13:18:54 -0500
Message-ID: <4F170D0D.8030304@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 13:18:53 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-11-git-send-email-dgdegra@tycho.nsa.gov>
	<1326885330.14689.198.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326885330.14689.198.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/18] xenstored: use grant references
 instead of map_foreign_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 01/18/2012 06:15 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>
>> make xenstored use grantref rather than map_foreign_range (which can
>> only be used by privileged domains)
>>
>> This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
>> instead of xc_map_foreign_range where available.
>>
>> Previous versions of this patch have been sent to xen-devel. See
>> http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
>>
>> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/xenstored_domain.c |   45 ++++++++++++++++++++++++++++++++-----
>>  1 files changed, 39 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 443af82..0b8353b 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -32,8 +32,10 @@
>>  #include "xenstored_watch.h"
>>  
>>  #include <xenctrl.h>
>> +#include <xen/grant_table.h>
>>  
>>  static xc_interface **xc_handle;
>> +static xc_gnttab **xcg_handle;
>>  static evtchn_port_t virq_port;
>>  
>>  xc_evtchn *xce_handle = NULL;
>> @@ -174,8 +176,12 @@ static int destroy_domain(void *_domain)
>>  			eprintf("> Unbinding port %i failed!\n", domain->port);
>>  	}
>>  
>> -	if (domain->interface)
>> -		munmap(domain->interface, getpagesize());
>> +	if (domain->interface) {
>> +		if (*xcg_handle >= 0 && domain->domid != 0)
> 
> Why the special case for domid 0 here? There seems to be no equivalent
> for the map case, including the one you add in patch 15/18.
 
dom0 is mapped by dom0_init()/xenbus_map() and must be unmapped with munmap,
which is not guaranteed to be the same as xc_gnttab_munmap. The map case
doesn't need to handle that.

> I think the map and unmap logic could usefully be made into helper
> functions.
> 
> Ian.

-- 
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 Wed Jan 18 18:19:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18: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 1Rna6E-0004Aj-C2; Wed, 18 Jan 2012 18:19:06 +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 1Rna6C-0004AQ-4u
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:19:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-21.messagelabs.com!1326910737!2778577!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 22267 invoked from network); 18 Jan 2012 18:18:57 -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;
	18 Jan 2012 18:18:57 -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
	q0IIIsTP029255; Wed, 18 Jan 2012 18:18:54 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 q0IIIsJq001726; 
	Wed, 18 Jan 2012 13:18:54 -0500
Message-ID: <4F170D0D.8030304@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 13:18:53 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-11-git-send-email-dgdegra@tycho.nsa.gov>
	<1326885330.14689.198.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326885330.14689.198.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/18] xenstored: use grant references
 instead of map_foreign_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 01/18/2012 06:15 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>
>> make xenstored use grantref rather than map_foreign_range (which can
>> only be used by privileged domains)
>>
>> This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
>> instead of xc_map_foreign_range where available.
>>
>> Previous versions of this patch have been sent to xen-devel. See
>> http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
>>
>> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/xenstored_domain.c |   45 ++++++++++++++++++++++++++++++++-----
>>  1 files changed, 39 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 443af82..0b8353b 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -32,8 +32,10 @@
>>  #include "xenstored_watch.h"
>>  
>>  #include <xenctrl.h>
>> +#include <xen/grant_table.h>
>>  
>>  static xc_interface **xc_handle;
>> +static xc_gnttab **xcg_handle;
>>  static evtchn_port_t virq_port;
>>  
>>  xc_evtchn *xce_handle = NULL;
>> @@ -174,8 +176,12 @@ static int destroy_domain(void *_domain)
>>  			eprintf("> Unbinding port %i failed!\n", domain->port);
>>  	}
>>  
>> -	if (domain->interface)
>> -		munmap(domain->interface, getpagesize());
>> +	if (domain->interface) {
>> +		if (*xcg_handle >= 0 && domain->domid != 0)
> 
> Why the special case for domid 0 here? There seems to be no equivalent
> for the map case, including the one you add in patch 15/18.
 
dom0 is mapped by dom0_init()/xenbus_map() and must be unmapped with munmap,
which is not guaranteed to be the same as xc_gnttab_munmap. The map case
doesn't need to handle that.

> I think the map and unmap logic could usefully be made into helper
> functions.
> 
> Ian.

-- 
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 Wed Jan 18 18:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rna6T-0004Bo-PH; Wed, 18 Jan 2012 18:19: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 1Rna6S-0004BN-MH
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:19:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326910753!9710081!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13737 invoked from network); 18 Jan 2012 18:19:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 18:19:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,530,1320624000"; d="scan'208";a="10124336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 18:19: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; Wed, 18 Jan 2012 18:19: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 1Rna6H-0006aC-IG;
	Wed, 18 Jan 2012 18:19:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rna6H-0006RB-HS;
	Wed, 18 Jan 2012 18:19:09 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10882-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 18:19:09 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10882: 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 10882 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10882/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-rhel6hvm-intel  7 redhat-install fail in 10875 REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10875 REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install  fail in 10875 REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install  fail in 10875 REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install fail in 10875 REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install  fail in 10875 REGR. vs. 10649
 test-amd64-i386-win           7 windows-install  fail in 10875 REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10875 REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install  fail in 10875 REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 build-amd64                   4 xen-build                   fail pass in 10875
 build-amd64-oldkern           4 xen-build                   fail pass in 10875
 build-amd64-pvops             4 kernel-build                fail pass in 10875
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10875 pass in 10867
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10875 pass in 10867
 test-amd64-amd64-xl-win7-amd64  7 windows-install  fail in 10875 pass in 10867
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10867 pass in 10875

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           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-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-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-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 10875 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10875 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10867 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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 870 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 Jan 18 18:19:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18:19:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rna6T-0004Bo-PH; Wed, 18 Jan 2012 18:19: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 1Rna6S-0004BN-MH
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:19:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326910753!9710081!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTc0Nw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13737 invoked from network); 18 Jan 2012 18:19:13 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	18 Jan 2012 18:19:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,530,1320624000"; d="scan'208";a="10124336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 18:19: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; Wed, 18 Jan 2012 18:19: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 1Rna6H-0006aC-IG;
	Wed, 18 Jan 2012 18:19:09 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rna6H-0006RB-HS;
	Wed, 18 Jan 2012 18:19:09 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10882-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 18:19:09 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10882: 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 10882 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10882/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-rhel6hvm-intel  7 redhat-install fail in 10875 REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10875 REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install  fail in 10875 REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install  fail in 10875 REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install fail in 10875 REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install  fail in 10875 REGR. vs. 10649
 test-amd64-i386-win           7 windows-install  fail in 10875 REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10875 REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install  fail in 10875 REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 build-amd64                   4 xen-build                   fail pass in 10875
 build-amd64-oldkern           4 xen-build                   fail pass in 10875
 build-amd64-pvops             4 kernel-build                fail pass in 10875
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10875 pass in 10867
 test-amd64-i386-xl-win7-amd64  7 windows-install   fail in 10875 pass in 10867
 test-amd64-amd64-xl-win7-amd64  7 windows-install  fail in 10875 pass in 10867
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10867 pass in 10875

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          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-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           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-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-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-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 10875 never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2         fail in 10875 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10867 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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 870 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 Jan 18 18:24:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18:24:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnaAc-0004ZU-B2; Wed, 18 Jan 2012 18:23:38 +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 1RnaAb-0004Yz-34
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:23:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326911010!9080000!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc3OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5783 invoked from network); 18 Jan 2012 18:23:30 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-13.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 18:23:30 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id D1EF776C076;
	Wed, 18 Jan 2012 10:23:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=fpGsVUwAlrfMk20luS6K+/xLCBbCbWpdl1Mfag1u8eyw
	1FaLQ+j2x+h0+v5fqt5Gvn8Ym5e8MdBQX4R5RUnDyg61sUhwzW8Cs9txxcoabS+n
	WHQUsUdCHI9kZw3pW+wW82eubwZiVD/gRyI4CizU+iYvHDEphDXeG1p3f/AUEqU=
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=Ojvm47BbJ3sMoQzTklGgFSYipgY=; b=rePvFGPH
	quEL4tAonMYV0y9vudYN43tazagK9rZawHT6YUndCjTKtldiUibRFRtDpbl6w/3b
	zGtuLPbyn03yeCc57mXMzc9AjrdDlrild3ET8uOwchTAS09SQ5xoCj6vYLfoBymx
	ViENEMZ8dEaBm67xbrkbBpvICwBMcyiY3rU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 91D6676C072; 
	Wed, 18 Jan 2012 10:23:29 -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, 18 Jan 2012 10:23:29 -0800
Message-ID: <011df98ca1ee2962435d6df118f6267d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.761.1326908012.1471.xen-devel@lists.xensource.com>
References: <mailman.761.1326908012.1471.xen-devel@lists.xensource.com>
Date: Wed, 18 Jan 2012 10:23:29 -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] tools/libxc: fix error handling in
	xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Wed, 18 Jan 2012 18:15:24 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] tools/libxc: fix error handling in
> 	xc_mem_paging_load
> Message-ID: <1821b0e1ce16d0015542.1326906924@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1326906775 -3600
> # Node ID 1821b0e1ce16d0015542d4164505d97f130f09d7
> # Parent  15ab61865ecbd146f6ce65fbea5bf49bfd9c6cb1
> tools/libxc: fix error handling in xc_mem_paging_load
>
> xc_mem_paging_load() does not pass errors in errno and the actual errno
> from xc_mem_event_control() is overwritten by munlock().
> xenpaging_populate_page() needs to check errno, but with the switch to
> xc_mem_paging_load() it could not receive ENOMEM anymore.
>
> Update xc_mem_paging_load() to return -1 and preserve errno during
> munlock().
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

>
> diff -r 15ab61865ecb -r 1821b0e1ce16 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -68,23 +68,28 @@ int xc_mem_paging_prep(xc_interface *xch
>  int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
>                                  unsigned long gfn, void *buffer)
>  {
> -    int rc;
> +    int rc, old_errno;
> +
> +    errno = -EINVAL;
>
>      if ( !buffer )
> -        return -EINVAL;
> +        return -1;
>
>      if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
> -        return -EINVAL;
> +        return -1;
>
>      if ( mlock(buffer, XC_PAGE_SIZE) )
> -        return -errno;
> +        return -1;
>
>      rc = xc_mem_event_control(xch, domain_id,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>                                  buffer, NULL, gfn);
>
> -    (void)munlock(buffer, XC_PAGE_SIZE);
> +    old_errno = errno;
> +    munlock(buffer, XC_PAGE_SIZE);
> +    errno = old_errno;
> +
>      return rc;
>  }
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Jan 2012 17:13:31 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in
> 	minios stubdom
> Message-ID: <20246.64955.717774.909586@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/18] xenstored: support
> running in minios stubdom"):
>> One thing which might help is to provide nop versions of functions
>> instead of idef'ing both the definition and callsite. e.g.
>>  static void write_pidfile(const char *pidfile)
>> +#ifndef __MINIOS__
>>      stuff
>> +#else
>> +    nothing
>> +endif
>
> I would normally prefer:
>
>> +#ifndef __MINIOS__
>>  static void write_pidfile(const char *pidfile)
>>      stuff
>>  }
>> +#else
>> +static void write_pidfile(const char *pidfile)
>> +}
>> +endif
>
> I think this is fairly easy to read; the only hard part is figuring
> out which version is being used, which can often be done by putting
> the relevant bits in a separate file.
>
> Ian.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 18 Jan 2012 17:33:24 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 3/9] libxl: New event generation API
> Message-ID: <1326908004.14689.296.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 2012-01-13 at 19:25 +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.
>>
>> The new "libxl_event" structure is blacklisted in the ocaml bindings
>> for two reasons:
>>   - It has a field name "type" (which is a keyword in ocaml);
>>     the ocaml idl generator should massage this field name on
>>     output, to "type_" perhaps.
>>   - The ocaml idl generator does not support KeyedUnion.
>>
>> 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      |  236 ++++++++++++++++++++++++++---
>>  tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
>>  tools/libxl/libxl_internal.h   |   77 +++++++++-
>>  tools/libxl/libxl_types.idl    |   34 ++++-
>>  tools/libxl/xl_cmdimpl.c       |  270 +++++++++++++++++++--------------
>>  tools/ocaml/libs/xl/genwrap.py |    1 +
>>  8 files changed, 908 insertions(+), 277 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 413b684..19ff12c 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -95,6 +115,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);
>
> Why a helper for deaths but not ejects?
>
> [...]
>
>> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
>> index ec66340..621a7cc 100644
>> --- a/tools/libxl/libxl_event.c
>> +++ b/tools/libxl/libxl_event.c
>
>>
>>  /*
>> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
>> index 63ef65e..0e83800 100644
>> --- a/tools/libxl/libxl_event.h
>> +++ b/tools/libxl/libxl_event.h
>
>> +#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;
>
> libxl_event_{wait,check} and LIBXL_EVENTMASK_ALL have an unsigned long
> mask. Are they not the same set of bits?
>
> [...]
>
>> + * 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.
>
> Does anything actually guarantee that sizeof(uint64_t) >
> sizeof(intptr_t)? I'm sure it's true in practice and I'm happy to rely
> on it. Just interested.
>
>> + *[...]
>
>> + * 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.  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.
>> + */
> [...]
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index 574dec7..a6dac79 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
>>      ("extratime", integer),
>>      ("weight", integer),
>>      ], dispose_fn=None)
>> +
>> +libxl_event_type = Enumeration("event_type", [
>> +    (1, "DOMAIN_SHUTDOWN"),
>> +    (2, "DOMAIN_DESTROY"),
>> +    (3, "DISK_EJECT"),
>> +    ])
>> +
>> +libxl_ev_user = UInt(64)
>
> The other option here would be Builtin(...) and an entry in the builtin
> table in the wrapper generator.
>
> Arguably the idl could be improved by causing Number() to have a width
> field. Currently it has a signedness and width is a property of UInt but
> the latter could be pushed up the hierarchy.
>
> You'd still end up with
> 	FOO = Number("FOO", width=X)
> which isn't really much better.
>
> Or the ocaml generate could handle Number as the biggest int.
>
> Hrm. None of that seems all that much better than what you have. Chalk
> it up to potential future work.
>
>> +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE,
>> private=True)
>> +
>> +libxl_event = Struct("event",[
>> +    ("link",     libxl_ev_link,0),
>
> This "0" == "const=False" which is the default. I don't think it is
> necessary.
>
> [...]
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 8c30de1..e292bfc 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>
>> @@ -1702,92 +1729,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);
>
> I didn't see this getting freed on the exit path.
>
>> +        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;
>> +    }
>
> This is all (I think) safe for num_disks == 0 but why waste the effort?
>
> Incidentally we have libxl_device_disk.removable which might be an
> opportunity to optimise? Assuming it is meaningful in that way. I think
> in reality only emulated CD-ROM devices ever generate this event but
> perhaps exposing that in the API overcomplicates things.
>
> [...]
>
> Ian.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 288
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:24:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18:24:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnaAc-0004ZU-B2; Wed, 18 Jan 2012 18:23:38 +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 1RnaAb-0004Yz-34
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:23:37 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326911010!9080000!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc3OTA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5783 invoked from network); 18 Jan 2012 18:23:30 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.202) by server-13.tower-21.messagelabs.com with SMTP;
	18 Jan 2012 18:23:30 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id D1EF776C076;
	Wed, 18 Jan 2012 10:23:29 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=fpGsVUwAlrfMk20luS6K+/xLCBbCbWpdl1Mfag1u8eyw
	1FaLQ+j2x+h0+v5fqt5Gvn8Ym5e8MdBQX4R5RUnDyg61sUhwzW8Cs9txxcoabS+n
	WHQUsUdCHI9kZw3pW+wW82eubwZiVD/gRyI4CizU+iYvHDEphDXeG1p3f/AUEqU=
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=Ojvm47BbJ3sMoQzTklGgFSYipgY=; b=rePvFGPH
	quEL4tAonMYV0y9vudYN43tazagK9rZawHT6YUndCjTKtldiUibRFRtDpbl6w/3b
	zGtuLPbyn03yeCc57mXMzc9AjrdDlrild3ET8uOwchTAS09SQ5xoCj6vYLfoBymx
	ViENEMZ8dEaBm67xbrkbBpvICwBMcyiY3rU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 91D6676C072; 
	Wed, 18 Jan 2012 10:23:29 -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, 18 Jan 2012 10:23:29 -0800
Message-ID: <011df98ca1ee2962435d6df118f6267d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.761.1326908012.1471.xen-devel@lists.xensource.com>
References: <mailman.761.1326908012.1471.xen-devel@lists.xensource.com>
Date: Wed, 18 Jan 2012 10:23:29 -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] tools/libxc: fix error handling in
	xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Wed, 18 Jan 2012 18:15:24 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] tools/libxc: fix error handling in
> 	xc_mem_paging_load
> Message-ID: <1821b0e1ce16d0015542.1326906924@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1326906775 -3600
> # Node ID 1821b0e1ce16d0015542d4164505d97f130f09d7
> # Parent  15ab61865ecbd146f6ce65fbea5bf49bfd9c6cb1
> tools/libxc: fix error handling in xc_mem_paging_load
>
> xc_mem_paging_load() does not pass errors in errno and the actual errno
> from xc_mem_event_control() is overwritten by munlock().
> xenpaging_populate_page() needs to check errno, but with the switch to
> xc_mem_paging_load() it could not receive ENOMEM anymore.
>
> Update xc_mem_paging_load() to return -1 and preserve errno during
> munlock().
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

>
> diff -r 15ab61865ecb -r 1821b0e1ce16 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -68,23 +68,28 @@ int xc_mem_paging_prep(xc_interface *xch
>  int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
>                                  unsigned long gfn, void *buffer)
>  {
> -    int rc;
> +    int rc, old_errno;
> +
> +    errno = -EINVAL;
>
>      if ( !buffer )
> -        return -EINVAL;
> +        return -1;
>
>      if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
> -        return -EINVAL;
> +        return -1;
>
>      if ( mlock(buffer, XC_PAGE_SIZE) )
> -        return -errno;
> +        return -1;
>
>      rc = xc_mem_event_control(xch, domain_id,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>                                  buffer, NULL, gfn);
>
> -    (void)munlock(buffer, XC_PAGE_SIZE);
> +    old_errno = errno;
> +    munlock(buffer, XC_PAGE_SIZE);
> +    errno = old_errno;
> +
>      return rc;
>  }
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Jan 2012 17:13:31 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in
> 	minios stubdom
> Message-ID: <20246.64955.717774.909586@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/18] xenstored: support
> running in minios stubdom"):
>> One thing which might help is to provide nop versions of functions
>> instead of idef'ing both the definition and callsite. e.g.
>>  static void write_pidfile(const char *pidfile)
>> +#ifndef __MINIOS__
>>      stuff
>> +#else
>> +    nothing
>> +endif
>
> I would normally prefer:
>
>> +#ifndef __MINIOS__
>>  static void write_pidfile(const char *pidfile)
>>      stuff
>>  }
>> +#else
>> +static void write_pidfile(const char *pidfile)
>> +}
>> +endif
>
> I think this is fairly easy to read; the only hard part is figuring
> out which version is being used, which can often be done by putting
> the relevant bits in a separate file.
>
> Ian.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 18 Jan 2012 17:33:24 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 3/9] libxl: New event generation API
> Message-ID: <1326908004.14689.296.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 2012-01-13 at 19:25 +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.
>>
>> The new "libxl_event" structure is blacklisted in the ocaml bindings
>> for two reasons:
>>   - It has a field name "type" (which is a keyword in ocaml);
>>     the ocaml idl generator should massage this field name on
>>     output, to "type_" perhaps.
>>   - The ocaml idl generator does not support KeyedUnion.
>>
>> 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      |  236 ++++++++++++++++++++++++++---
>>  tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
>>  tools/libxl/libxl_internal.h   |   77 +++++++++-
>>  tools/libxl/libxl_types.idl    |   34 ++++-
>>  tools/libxl/xl_cmdimpl.c       |  270 +++++++++++++++++++--------------
>>  tools/ocaml/libs/xl/genwrap.py |    1 +
>>  8 files changed, 908 insertions(+), 277 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 413b684..19ff12c 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -95,6 +115,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);
>
> Why a helper for deaths but not ejects?
>
> [...]
>
>> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
>> index ec66340..621a7cc 100644
>> --- a/tools/libxl/libxl_event.c
>> +++ b/tools/libxl/libxl_event.c
>
>>
>>  /*
>> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
>> index 63ef65e..0e83800 100644
>> --- a/tools/libxl/libxl_event.h
>> +++ b/tools/libxl/libxl_event.h
>
>> +#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;
>
> libxl_event_{wait,check} and LIBXL_EVENTMASK_ALL have an unsigned long
> mask. Are they not the same set of bits?
>
> [...]
>
>> + * 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.
>
> Does anything actually guarantee that sizeof(uint64_t) >
> sizeof(intptr_t)? I'm sure it's true in practice and I'm happy to rely
> on it. Just interested.
>
>> + *[...]
>
>> + * 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.  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.
>> + */
> [...]
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index 574dec7..a6dac79 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
>>      ("extratime", integer),
>>      ("weight", integer),
>>      ], dispose_fn=None)
>> +
>> +libxl_event_type = Enumeration("event_type", [
>> +    (1, "DOMAIN_SHUTDOWN"),
>> +    (2, "DOMAIN_DESTROY"),
>> +    (3, "DISK_EJECT"),
>> +    ])
>> +
>> +libxl_ev_user = UInt(64)
>
> The other option here would be Builtin(...) and an entry in the builtin
> table in the wrapper generator.
>
> Arguably the idl could be improved by causing Number() to have a width
> field. Currently it has a signedness and width is a property of UInt but
> the latter could be pushed up the hierarchy.
>
> You'd still end up with
> 	FOO = Number("FOO", width=X)
> which isn't really much better.
>
> Or the ocaml generate could handle Number as the biggest int.
>
> Hrm. None of that seems all that much better than what you have. Chalk
> it up to potential future work.
>
>> +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE,
>> private=True)
>> +
>> +libxl_event = Struct("event",[
>> +    ("link",     libxl_ev_link,0),
>
> This "0" == "const=False" which is the default. I don't think it is
> necessary.
>
> [...]
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 8c30de1..e292bfc 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>
>> @@ -1702,92 +1729,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);
>
> I didn't see this getting freed on the exit path.
>
>> +        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;
>> +    }
>
> This is all (I think) safe for num_disks == 0 but why waste the effort?
>
> Incidentally we have libxl_device_disk.removable which might be an
> opportunity to optimise? Assuming it is meaningful in that way. I think
> in reality only emulated CD-ROM devices ever generate this event but
> perhaps exposing that in the API overcomplicates things.
>
> [...]
>
> Ian.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 288
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:26:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnaD5-0004ts-TT; Wed, 18 Jan 2012 18:26:11 +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 1RnaD4-0004tZ-BU
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:26:10 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326911101!61548347!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 11402 invoked from network); 18 Jan 2012 18:25:02 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-7.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Jan 2012 18:25:02 -0000
Received: from mail49-ch1-R.bigfish.com (10.43.68.241) by
	CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 18:26:01 +0000
Received: from mail49-ch1 (localhost [127.0.0.1])	by mail49-ch1-R.bigfish.com
	(Postfix) with ESMTP id 624F9C008A;
	Wed, 18 Jan 2012 18:26:07 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h61h)
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 mail49-ch1 (localhost.localdomain [127.0.0.1]) by mail49-ch1
	(MessageSwitch) id 1326911166961921_10378;
	Wed, 18 Jan 2012 18:26:06 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.251])	by mail49-ch1.bigfish.com (Postfix) with ESMTP id
	E3970200045;	Wed, 18 Jan 2012 18:26:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 18:26:04 +0000
X-WSS-ID: 0LY0B7E-01-GEM-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 2CDE51028073;	Wed, 18 Jan 2012 12:26: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;
	Wed, 18 Jan 2012 12:26:15 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 12:26:02 -0600
Message-ID: <4F170EBA.70101@amd.com>
Date: Wed, 18 Jan 2012 13:26:02 -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: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
	<4F16A402020000780006D571@nat28.tlf.novell.com>
In-Reply-To: <4F16A402020000780006D571@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/12 04:50, Jan Beulich wrote:
>>>> On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> On 01/17/12 03:26, Jan Beulich wrote:
>>>>>> On 16.01.12 at 22:11, Boris Ostrovsky<boris.ostrovsky@amd.com>   wrote:
>>>> --- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
>>>> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
>>>> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>>>>                        bitmaskof(X86_FEATURE_SSE4A) |
>>>>                        bitmaskof(X86_FEATURE_MISALIGNSSE) |
>>>>                        bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
>>>> +		    bitmaskof(X86_FEATURE_OSVW) |
>>>
>>> Indentation.
>>>
>>> Also, is this really meaningful to PV guests?
>>
>> Does amd_xc_cpuid_policy() get called for PV guests? I thought this is
>> HVM path only.
>
> In that case I simply misplaced the comment.
>
>> xc_cpuid_pv_policy() is where clear_bit(X86_FEATURE_OSVW, regs[2]) was
>> removed to handle PV.
>>
>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum
>> 400 as an example -- we don't need a Linux PV guest reading an MSR
>> before going to idle (in amd_e400_idle()).
>
> It is bogus in the first place if a pv guest does so - after all, not doing
> stuff like this is the nature of being pv.

It was actually a bad example --- the guest is not using amd_e400_idle() 
and so there are no extra MSR accesses.

However, without this change OSVW bit will not show up in the guest's 
CPUID and I think guests should be able to see it. One could argue 
whether or not we should mask off status bits for the two errata (400 
and 415) since they are not currently used; I'd mask them off just to be 
consistent with HVM, it won't affect anything.

>>>> +    vcpu->arch.amd.osvw.length = (osvw_length >= 3) ? (osvw_length) : 3
>>>> +    vcpu->arch.amd.osvw.status = osvw_status&   ~(6ULL);
>>>> +
>>>> +    /*
>>>> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
>>>> +     * all osvw.status bits inside that length, including bit 0 (which is
>>>> +     * reserved for erratum 298), are valid. However, if host processor's
>>>> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
>>>> +     * be conservative here and therefore we tell the guest that erratum
>> 298
>>>> +     * is present (because we really don't know).
>>>> +     */
>>>> +    if (osvw_length == 0&&   boot_cpu_data.x86 == 0x10)
>>>
>>> Why do you check the family here? If osvw_length can only ever be
>>> zero on Fam10, then the first check is sufficient. If osvw_length can
>>> be zero on other than Fam10 (no matter whether we bail early older
>>> CPUs), then the check is actually wrong.
>>
>> 10h is the only family affected by this erratum.
>
> What is "this erratum" here? My comment was to suggest that either
> of the two conditions can likely be eliminated for being redundant.

("This erratum" is erratum 298, which is bit 0)

If osvw_length!=0 then we don't need to do anything since bit 0 is 
already valid.

If osvw_length==0 then -- since we just made the guest's version of this 
register 3 and thus turned bit 0 from being invalid to valid -- we need 
to do something about bit 0. But the bit can only be set on family 10h, 
thus both checks.


Thanks.
-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:26:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18:26:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnaD5-0004ts-TT; Wed, 18 Jan 2012 18:26:11 +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 1RnaD4-0004tZ-BU
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:26:10 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326911101!61548347!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 11402 invoked from network); 18 Jan 2012 18:25:02 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-7.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	18 Jan 2012 18:25:02 -0000
Received: from mail49-ch1-R.bigfish.com (10.43.68.241) by
	CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 18:26:01 +0000
Received: from mail49-ch1 (localhost [127.0.0.1])	by mail49-ch1-R.bigfish.com
	(Postfix) with ESMTP id 624F9C008A;
	Wed, 18 Jan 2012 18:26:07 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h61h)
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 mail49-ch1 (localhost.localdomain [127.0.0.1]) by mail49-ch1
	(MessageSwitch) id 1326911166961921_10378;
	Wed, 18 Jan 2012 18:26:06 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.251])	by mail49-ch1.bigfish.com (Postfix) with ESMTP id
	E3970200045;	Wed, 18 Jan 2012 18:26:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server id
	14.1.225.23; Wed, 18 Jan 2012 18:26:04 +0000
X-WSS-ID: 0LY0B7E-01-GEM-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 2CDE51028073;	Wed, 18 Jan 2012 12:26: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;
	Wed, 18 Jan 2012 12:26:15 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp01.amd.com
	(163.181.3.165) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 18 Jan 2012 12:26:02 -0600
Message-ID: <4F170EBA.70101@amd.com>
Date: Wed, 18 Jan 2012 13:26:02 -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: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
	<4F16A402020000780006D571@nat28.tlf.novell.com>
In-Reply-To: <4F16A402020000780006D571@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/12 04:50, Jan Beulich wrote:
>>>> On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>> On 01/17/12 03:26, Jan Beulich wrote:
>>>>>> On 16.01.12 at 22:11, Boris Ostrovsky<boris.ostrovsky@amd.com>   wrote:
>>>> --- a/tools/libxc/xc_cpuid_x86.c	Mon Jan 09 16:01:44 2012 +0100
>>>> +++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 16 22:08:09 2012 +0100
>>>> @@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
>>>>                        bitmaskof(X86_FEATURE_SSE4A) |
>>>>                        bitmaskof(X86_FEATURE_MISALIGNSSE) |
>>>>                        bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
>>>> +		    bitmaskof(X86_FEATURE_OSVW) |
>>>
>>> Indentation.
>>>
>>> Also, is this really meaningful to PV guests?
>>
>> Does amd_xc_cpuid_policy() get called for PV guests? I thought this is
>> HVM path only.
>
> In that case I simply misplaced the comment.
>
>> xc_cpuid_pv_policy() is where clear_bit(X86_FEATURE_OSVW, regs[2]) was
>> removed to handle PV.
>>
>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum
>> 400 as an example -- we don't need a Linux PV guest reading an MSR
>> before going to idle (in amd_e400_idle()).
>
> It is bogus in the first place if a pv guest does so - after all, not doing
> stuff like this is the nature of being pv.

It was actually a bad example --- the guest is not using amd_e400_idle() 
and so there are no extra MSR accesses.

However, without this change OSVW bit will not show up in the guest's 
CPUID and I think guests should be able to see it. One could argue 
whether or not we should mask off status bits for the two errata (400 
and 415) since they are not currently used; I'd mask them off just to be 
consistent with HVM, it won't affect anything.

>>>> +    vcpu->arch.amd.osvw.length = (osvw_length >= 3) ? (osvw_length) : 3
>>>> +    vcpu->arch.amd.osvw.status = osvw_status&   ~(6ULL);
>>>> +
>>>> +    /*
>>>> +     * By increasing VCPU's osvw.length to 3 we are telling the guest that
>>>> +     * all osvw.status bits inside that length, including bit 0 (which is
>>>> +     * reserved for erratum 298), are valid. However, if host processor's
>>>> +     * osvw_len is 0 then osvw_status[0] carries no information. We need to
>>>> +     * be conservative here and therefore we tell the guest that erratum
>> 298
>>>> +     * is present (because we really don't know).
>>>> +     */
>>>> +    if (osvw_length == 0&&   boot_cpu_data.x86 == 0x10)
>>>
>>> Why do you check the family here? If osvw_length can only ever be
>>> zero on Fam10, then the first check is sufficient. If osvw_length can
>>> be zero on other than Fam10 (no matter whether we bail early older
>>> CPUs), then the check is actually wrong.
>>
>> 10h is the only family affected by this erratum.
>
> What is "this erratum" here? My comment was to suggest that either
> of the two conditions can likely be eliminated for being redundant.

("This erratum" is erratum 298, which is bit 0)

If osvw_length!=0 then we don't need to do anything since bit 0 is 
already valid.

If osvw_length==0 then -- since we just made the guest's version of this 
register 3 and thus turned bit 0 from being invalid to valid -- we need 
to do something about bit 0. But the bit can only be set on family 10h, 
thus both checks.


Thanks.
-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:32:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18: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 1RnaIG-0005CD-M7; Wed, 18 Jan 2012 18:31:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RnaIF-0005Bu-Am
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:31:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326911484!9715905!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 30607 invoked from network); 18 Jan 2012 18:31:24 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 18:31:24 -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
	q0IIVMVF000226; Wed, 18 Jan 2012 18:31:22 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 q0IIVM0V024834; 
	Wed, 18 Jan 2012 13:31:22 -0500
Message-ID: <4F170FF9.2010201@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 13:31:21 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-17-git-send-email-dgdegra@tycho.nsa.gov>
	<1326887077.14689.214.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326887077.14689.214.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 16/18] xenstored: use domain_is_unprivileged
 instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 06:44 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> This centralizes all the permission checking for privileged domains in
>> preparation for allowing domains other than dom0 to be privileged.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/xenstored_core.c   |    6 +++---
>>  tools/xenstore/xenstored_domain.c |    8 ++++----
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index 4ec63f1..eea5fd6 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -488,7 +488,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
>>  		mask &= ~XS_PERM_WRITE;
>>  
>>  	/* Owners and tools get it all... */
>> -	if (!conn->id || perms[0].id == conn->id
>> +	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
> 
> domain_is_unprivileged is:
>         conn && conn->domain && conn->domain->domid != 0
>         
> which isn't quite the same as the code being replaced. The difference
> appears to be the conn->id is valid for socket connections as well as
> domain connections whereas conn->domain is only present for domain
> connections.
> 
> Does this change not mean that, for the dom0-process xenstored
> configuration we now treat socket based connections as unprivileged
> where previously they would be unprivileged?

No. For dom0 socket connections, conn->domain is NULL so the connection
is not unprivileged (making it privileged). This is why sane people do not
make boolean functions test for "un" cases :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 18:32:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 18: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 1RnaIG-0005CD-M7; Wed, 18 Jan 2012 18:31:32 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RnaIF-0005Bu-Am
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 18:31:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-174.messagelabs.com!1326911484!9715905!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 30607 invoked from network); 18 Jan 2012 18:31:24 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 18:31:24 -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
	q0IIVMVF000226; Wed, 18 Jan 2012 18:31:22 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 q0IIVM0V024834; 
	Wed, 18 Jan 2012 13:31:22 -0500
Message-ID: <4F170FF9.2010201@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 13:31:21 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-17-git-send-email-dgdegra@tycho.nsa.gov>
	<1326887077.14689.214.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326887077.14689.214.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 16/18] xenstored: use domain_is_unprivileged
 instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/18/2012 06:44 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> This centralizes all the permission checking for privileged domains in
>> preparation for allowing domains other than dom0 to be privileged.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/xenstored_core.c   |    6 +++---
>>  tools/xenstore/xenstored_domain.c |    8 ++++----
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index 4ec63f1..eea5fd6 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -488,7 +488,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
>>  		mask &= ~XS_PERM_WRITE;
>>  
>>  	/* Owners and tools get it all... */
>> -	if (!conn->id || perms[0].id == conn->id
>> +	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
> 
> domain_is_unprivileged is:
>         conn && conn->domain && conn->domain->domid != 0
>         
> which isn't quite the same as the code being replaced. The difference
> appears to be the conn->id is valid for socket connections as well as
> domain connections whereas conn->domain is only present for domain
> connections.
> 
> Does this change not mean that, for the dom0-process xenstored
> configuration we now treat socket based connections as unprivileged
> where previously they would be unprivileged?

No. For dom0 socket connections, conn->domain is NULL so the connection
is not unprivileged (making it privileged). This is why sane people do not
make boolean functions test for "un" cases :)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 18 19:08:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 19:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnarP-0006fZ-01; Wed, 18 Jan 2012 19:07:51 +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 1RnarO-0006fH-FV
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 19:07:50 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326913662!11435424!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 24271 invoked from network); 18 Jan 2012 19:07:43 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-182.messagelabs.com with SMTP;
	18 Jan 2012 19:07:43 -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
	q0IJ7eTP013489; Wed, 18 Jan 2012 19:07:41 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 q0IJ7eo1030437; 
	Wed, 18 Jan 2012 14:07:40 -0500
Message-ID: <4F17187B.2050102@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 14:07:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1326882968.14689.176.camel@zakaz.uk.xensource.com>
	<4F16DD96.6080304@tycho.nsa.gov>
	<1326902794.14689.243.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326902794.14689.243.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On 01/18/2012 11:06 AM, Ian Campbell wrote:
> On Wed, 2012-01-18 at 14:56 +0000, Daniel De Graaf wrote:
>> On 01/18/2012 05:36 AM, Ian Campbell wrote:
>>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>>>
>>>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>>>> which was removed in 19041:ee62aaafff46 because it was not used.
>>>>
>>>> However, is now needed in order to support xenstored stub domains.
>>>> The xenstored stub domain is not priviliged like dom0 and so cannot
>>>> unilaterally map the xenbus page of other guests into it's address
>>>> space.  Therefore, before creating a domU the domain builder needs to
>>>> seed its grant table with a grant ref allowing the xenstored stub
>>>> domain to access the new domU's xenbus page.
>>>>
>>>> At present domU's do not start with their grant table mapped.
>>>> Instead it gets mapped when the guest requests a grant table from
>>>> the hypervisor.
>>>>
>>>> In order to seed the grant table, the domain builder first needs to
>>>> map it into dom0 address space.  But the hypercall to do this
>>>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>>>> for HVM guests.  Therfore, in order to seed the grant table of an
>>>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>>>> "physical" address space.
>>>>
>>>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>>>
>>>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
>>> about ordering in xlat.lst)
>>>
>>> BTW, since Alex and Diego have subsequently left Citrix you could take
>>> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
>>> no idea if that's necessary though, I expect not.
>>>
>>> Ian.
>>>
>>
>> I'm not an expert in this area,
> 
> Me neither.
> 
>> but this is how I read it: the portion of
>> the path authored by Alex/Diego was already signed-off when they were posted,
>> so since the current patches are derived works from them the sign-off may
>> need to stay in order to allow me to sign off because I cannot claim copyright
>> on all of the content. Assuming Citrix actually owns the copyright on the
>> patches, your Ack may suffice to replace the sign-off for this purpose.
> 
> I don't think an Ack conveys the same meaning (WRT the DCO) as a
> Signed-off-by.
> 
>> I guess my real question here would be: should the sign-off from Alex and
>> Diego remain on these patches in addition to your Ack?
> 
> I would suggest you keep any signed-off-by they provided and augment it
> with my ack. 
> 
> I think I saw one or two which said "Originally-by" instead of
> "Signed-of-by", I guess those were either missing a Signed-off-by in the
> first place or have been heavily modified?
> 
> Ian.
> 

I originally replaced all the signed-off-by lines with originally-by and
missed one when converting back. When looking at the Linux version of the
DCO, it implies (lower down when talking about subsystem maintainers) that
if I make changes I need to drop the sign-off and claim clause (b) unless
the original author is around to sign-off on the changed patch, or if it is
trivial and I note this above my sign-off (not applicable here). This makes
me lean toward changing back to "Originally-by" or similar tags. I did keep
the From tags for those patches that I did not mostly rewrite, which I assume
will be recognized when importing patches.

-- 
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 Wed Jan 18 19:08:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 19:08:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnarP-0006fZ-01; Wed, 18 Jan 2012 19:07:51 +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 1RnarO-0006fH-FV
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 19:07:50 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-182.messagelabs.com!1326913662!11435424!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 24271 invoked from network); 18 Jan 2012 19:07:43 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-182.messagelabs.com with SMTP;
	18 Jan 2012 19:07:43 -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
	q0IJ7eTP013489; Wed, 18 Jan 2012 19:07:41 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 q0IJ7eo1030437; 
	Wed, 18 Jan 2012 14:07:40 -0500
Message-ID: <4F17187B.2050102@tycho.nsa.gov>
Date: Wed, 18 Jan 2012 14:07:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1326882968.14689.176.camel@zakaz.uk.xensource.com>
	<4F16DD96.6080304@tycho.nsa.gov>
	<1326902794.14689.243.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326902794.14689.243.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On 01/18/2012 11:06 AM, Ian Campbell wrote:
> On Wed, 2012-01-18 at 14:56 +0000, Daniel De Graaf wrote:
>> On 01/18/2012 05:36 AM, Ian Campbell wrote:
>>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>>>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>>>
>>>> This patch reinstates the XENMEM_remove_from_physmap hypercall
>>>> which was removed in 19041:ee62aaafff46 because it was not used.
>>>>
>>>> However, is now needed in order to support xenstored stub domains.
>>>> The xenstored stub domain is not priviliged like dom0 and so cannot
>>>> unilaterally map the xenbus page of other guests into it's address
>>>> space.  Therefore, before creating a domU the domain builder needs to
>>>> seed its grant table with a grant ref allowing the xenstored stub
>>>> domain to access the new domU's xenbus page.
>>>>
>>>> At present domU's do not start with their grant table mapped.
>>>> Instead it gets mapped when the guest requests a grant table from
>>>> the hypervisor.
>>>>
>>>> In order to seed the grant table, the domain builder first needs to
>>>> map it into dom0 address space.  But the hypercall to do this
>>>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
>>>> for HVM guests.  Therfore, in order to seed the grant table of an
>>>> HVM guest, dom0 needs to *temporarily* map it into the guest's
>>>> "physical" address space.
>>>>
>>>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
>>>>
>>>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>>>
>>> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
>>> about ordering in xlat.lst)
>>>
>>> BTW, since Alex and Diego have subsequently left Citrix you could take
>>> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
>>> no idea if that's necessary though, I expect not.
>>>
>>> Ian.
>>>
>>
>> I'm not an expert in this area,
> 
> Me neither.
> 
>> but this is how I read it: the portion of
>> the path authored by Alex/Diego was already signed-off when they were posted,
>> so since the current patches are derived works from them the sign-off may
>> need to stay in order to allow me to sign off because I cannot claim copyright
>> on all of the content. Assuming Citrix actually owns the copyright on the
>> patches, your Ack may suffice to replace the sign-off for this purpose.
> 
> I don't think an Ack conveys the same meaning (WRT the DCO) as a
> Signed-off-by.
> 
>> I guess my real question here would be: should the sign-off from Alex and
>> Diego remain on these patches in addition to your Ack?
> 
> I would suggest you keep any signed-off-by they provided and augment it
> with my ack. 
> 
> I think I saw one or two which said "Originally-by" instead of
> "Signed-of-by", I guess those were either missing a Signed-off-by in the
> first place or have been heavily modified?
> 
> Ian.
> 

I originally replaced all the signed-off-by lines with originally-by and
missed one when converting back. When looking at the Linux version of the
DCO, it implies (lower down when talking about subsystem maintainers) that
if I make changes I need to drop the sign-off and claim clause (b) unless
the original author is around to sign-off on the changed patch, or if it is
trivial and I note this above my sign-off (not applicable here). This makes
me lean toward changing back to "Originally-by" or similar tags. I did keep
the From tags for those patches that I did not mostly rewrite, which I assume
will be recognized when importing patches.

-- 
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 Wed Jan 18 21:08:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 21: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 1RncjA-0001B9-5o; Wed, 18 Jan 2012 21:07:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tina.yang@oracle.com>) id 1Rncj8-0001B1-Gl
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 21:07:26 +0000
X-Env-Sender: tina.yang@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326920828!8849194!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAwMTIz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2993 invoked from network); 18 Jan 2012 21:07:10 -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; 18 Jan 2012 21:07:10 -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
	q0IL73jN004255
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Jan 2012 21:07:04 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
	q0IL70NB021302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Jan 2012 21:07:01 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0IL6wDV021178; Wed, 18 Jan 2012 15:06:59 -0600
Received: from [10.159.239.194] (/10.159.239.194)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 18 Jan 2012 13:06:58 -0800
Message-ID: <4F173467.90106@oracle.com>
Date: Wed, 18 Jan 2012 13:06:47 -0800
From: Tina Yang <tina.yang@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
	<4F160113.1030503@oracle.com>
	<1326877176.29475.37.camel@dagon.hellion.org.uk>
In-Reply-To: <1326877176.29475.37.camel@dagon.hellion.org.uk>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F173479.0074,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/18/2012 12:59 AM, Ian Campbell wrote:
> On Tue, 2012-01-17 at 23:15 +0000, Tina Yang wrote:
>> On 1/17/2012 1:51 PM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
>>>> On 1/13/2012 3:06 AM, Ian Campbell wrote:
>>>> Although netdump is now obsolete, I think it's always a good practice
>>>> to preserve caller's irq status as we had a very bad experience
>>>> chasing a similar problem caused by such a irq change in RDS
>>> Did you find the culprit of it? Was there a patch for that in the
>>> upstream kernel?
>> Yes.  It has nothing to do with net drivers but same cause
>> elsewhere in the kernel.
> I didn't think start_xmit could be called with interrupts disabled or
> from interrupt context but perhaps I am wrong about that or perhaps
> netconsole changes things?
Netdump does call it with interrupt disabled and hang because of
it in 2.6.9 as I remember it.  And you are right, netconsole has
undergone changes from time to time, which also can change
this specification.
>
> Right, Documentation/networking/netdevices.txt states that start_xmit
> can be called with interrupts disabled by netconsole and therefore using
> the irqsave/restore locking in this function is, AFAICT, correct.
>
>>>> in the not too long ago past.
>>> OK, it sounds like it was issues in the past but might not be the
>>> case anymore.
>>>
>>> Could please re-test it without that spinlock irqsave patch using
>>> the upstream kernel (or just UEK2 since it is an 3.0 type kernel).
>> Shouldn't be the case now, but don't know about the future.
>> The fact is as long as there is a new caller that has the expectation
>> of preserved irq status, it would be a problem.
> The question is not so much what may or may not be a problem in the
> future but what the requirements of this function are, in particular
> those imposed by the network stack for the start_xmit function.
Agreed.  It's not safe to assume it unless the API documentation states 
that it can
not be called with interrupt disabled explicitly.
>> As Ian said, some net drivers have been cautious in this regard already by
>> saving/restoring the status, but apparently not everyone.
> I was talking about the interrupt/poll handler here since I hadn't yet
> noticed that the locking change was also in start_xmit and not just the
> poll/interrupt paths (which was actually just code motion and not a
> locking change in any case).
I did look at the start_xmit of most of the net drivers myself when I 
hit the
netdump hang back in 2008, and some of them did save/restore already,
but others 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 Wed Jan 18 21:08:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 21: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 1RncjA-0001B9-5o; Wed, 18 Jan 2012 21:07:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tina.yang@oracle.com>) id 1Rncj8-0001B1-Gl
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 21:07:26 +0000
X-Env-Sender: tina.yang@oracle.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326920828!8849194!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAwMTIz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2993 invoked from network); 18 Jan 2012 21:07:10 -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; 18 Jan 2012 21:07:10 -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
	q0IL73jN004255
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 18 Jan 2012 21:07:04 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
	q0IL70NB021302
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 18 Jan 2012 21:07:01 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0IL6wDV021178; Wed, 18 Jan 2012 15:06:59 -0600
Received: from [10.159.239.194] (/10.159.239.194)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 18 Jan 2012 13:06:58 -0800
Message-ID: <4F173467.90106@oracle.com>
Date: Wed, 18 Jan 2012 13:06:47 -0800
From: Tina Yang <tina.yang@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
	<4F160113.1030503@oracle.com>
	<1326877176.29475.37.camel@dagon.hellion.org.uk>
In-Reply-To: <1326877176.29475.37.camel@dagon.hellion.org.uk>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4F173479.0074,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 1/18/2012 12:59 AM, Ian Campbell wrote:
> On Tue, 2012-01-17 at 23:15 +0000, Tina Yang wrote:
>> On 1/17/2012 1:51 PM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
>>>> On 1/13/2012 3:06 AM, Ian Campbell wrote:
>>>> Although netdump is now obsolete, I think it's always a good practice
>>>> to preserve caller's irq status as we had a very bad experience
>>>> chasing a similar problem caused by such a irq change in RDS
>>> Did you find the culprit of it? Was there a patch for that in the
>>> upstream kernel?
>> Yes.  It has nothing to do with net drivers but same cause
>> elsewhere in the kernel.
> I didn't think start_xmit could be called with interrupts disabled or
> from interrupt context but perhaps I am wrong about that or perhaps
> netconsole changes things?
Netdump does call it with interrupt disabled and hang because of
it in 2.6.9 as I remember it.  And you are right, netconsole has
undergone changes from time to time, which also can change
this specification.
>
> Right, Documentation/networking/netdevices.txt states that start_xmit
> can be called with interrupts disabled by netconsole and therefore using
> the irqsave/restore locking in this function is, AFAICT, correct.
>
>>>> in the not too long ago past.
>>> OK, it sounds like it was issues in the past but might not be the
>>> case anymore.
>>>
>>> Could please re-test it without that spinlock irqsave patch using
>>> the upstream kernel (or just UEK2 since it is an 3.0 type kernel).
>> Shouldn't be the case now, but don't know about the future.
>> The fact is as long as there is a new caller that has the expectation
>> of preserved irq status, it would be a problem.
> The question is not so much what may or may not be a problem in the
> future but what the requirements of this function are, in particular
> those imposed by the network stack for the start_xmit function.
Agreed.  It's not safe to assume it unless the API documentation states 
that it can
not be called with interrupt disabled explicitly.
>> As Ian said, some net drivers have been cautious in this regard already by
>> saving/restoring the status, but apparently not everyone.
> I was talking about the interrupt/poll handler here since I hadn't yet
> noticed that the locking change was also in start_xmit and not just the
> poll/interrupt paths (which was actually just code motion and not a
> locking change in any case).
I did look at the start_xmit of most of the net drivers myself when I 
hit the
netdump hang back in 2008, and some of them did save/restore already,
but others 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 Wed Jan 18 23:58:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 23:58:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnfNm-0004Jr-CU; Wed, 18 Jan 2012 23:57:34 +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 1RnfNk-0004Jm-Aj
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 23:57:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326931045!9748294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTgyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3059 invoked from network); 18 Jan 2012 23:57:25 -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;
	18 Jan 2012 23:57:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,532,1320624000"; d="scan'208";a="10127355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 23:57:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 23:57:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnfNO-0008Su-42;
	Wed, 18 Jan 2012 23:57:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnfNL-0006VO-C2;
	Wed, 18 Jan 2012 23:57:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10884-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 23:57:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10884: 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 10884 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10884/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2               fail pass in 10867
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10867
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10867 pass in 10884

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                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 in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 870 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 Jan 18 23:58:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 18 Jan 2012 23:58:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnfNm-0004Jr-CU; Wed, 18 Jan 2012 23:57:34 +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 1RnfNk-0004Jm-Aj
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 23:57:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326931045!9748294!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTgyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3059 invoked from network); 18 Jan 2012 23:57:25 -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;
	18 Jan 2012 23:57:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,532,1320624000"; d="scan'208";a="10127355"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	18 Jan 2012 23:57:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 18 Jan 2012 23:57:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnfNO-0008Su-42;
	Wed, 18 Jan 2012 23:57:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnfNL-0006VO-C2;
	Wed, 18 Jan 2012 23:57:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10884-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 18 Jan 2012 23:57:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10884: 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 10884 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10884/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install     fail REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2               fail pass in 10867
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10867
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10867 pass in 10884

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                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 in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 870 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 Jan 19 05:16:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 05:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnkLg-0005hd-I6; Thu, 19 Jan 2012 05:15:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.chander@gmail.com>) id 1RnkLe-0005h1-Ty
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 05:15:43 +0000
X-Env-Sender: vijay.chander@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326950134!9735918!1
X-Originating-IP: [209.85.210.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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28398 invoked from network); 19 Jan 2012 05:15:36 -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;
	19 Jan 2012 05:15:36 -0000
Received: by iahk25 with SMTP id k25so30731470iah.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 21:15: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
	:content-type; bh=KRLvtq/U8eGeVWu9O8DrNMsxz8qPNnDzVvr6XqYSjUM=;
	b=HTz1svNPEODeOVjPHefqTh1hVsdBGXzfWUAfWyS+6gLRpsdY9qbWGLexU5k8qEVUDq
	K5pmrxFO9fRU38YfU2JwWUTpEXOjuwXjBIMVWxNGaMPXRU51wruoc+U2q/ulobKhe0MM
	P7dmd/5rTUguvEeYCRUXGp9msEVz4RNvDoFhc=
MIME-Version: 1.0
Received: by 10.50.77.226 with SMTP id v2mr25450722igw.7.1326950134519; Wed,
	18 Jan 2012 21:15:34 -0800 (PST)
Received: by 10.231.152.12 with HTTP; Wed, 18 Jan 2012 21:15:34 -0800 (PST)
In-Reply-To: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>
References: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>
Date: Wed, 18 Jan 2012 21:15:34 -0800
Message-ID: <CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
From: Vijay Chander <vijay.chander@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen + openvswitch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5732826188408856083=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5732826188408856083==
Content-Type: multipart/alternative; boundary=e89a8f234f396718db04b6daa767

--e89a8f234f396718db04b6daa767
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander <vijay.chander@gmail.com>wrote:

> Has anyone seen performance issues with xen 4.1.0 (the one used in
> xencenter 6.0)
> using open vswitch as opposed to native linux bridge ?
>
> We are tussling with needing the support guest vlan tagging and
> performance.
>
> Guest VM vlan tagging works with open vswitch . Perf seems to be much
> better
> with native linux bridge.
>
> Any useful pointers will be very helpul.
>
> Thanks,
> -kvc
>

--e89a8f234f396718db04b6daa767
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Jan 18, 2012 at 9:14 PM, Vijay C=
hander <span dir=3D"ltr">&lt;<a href=3D"mailto:vijay.chander@gmail.com">vij=
ay.chander@gmail.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=
">
Has anyone seen performance issues with xen 4.1.0 (the one used in xencente=
r 6.0)=A0<div>using open vswitch as opposed to native linux bridge ?</div><=
div><br></div><div>We are tussling with needing the support guest vlan tagg=
ing and performance.</div>

<div><br></div><div>Guest VM vlan tagging works with open vswitch . Perf se=
ems to be much better</div><div>with native linux bridge.</div><div><br></d=
iv><div>Any useful pointers will be very helpul.</div><div><br></div><div>

Thanks,</div><div>-kvc=A0</div>
</blockquote></div><br>

--e89a8f234f396718db04b6daa767--


--===============5732826188408856083==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5732826188408856083==--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 05:16:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 05:16:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnkLg-0005hd-I6; Thu, 19 Jan 2012 05:15:44 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vijay.chander@gmail.com>) id 1RnkLe-0005h1-Ty
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 05:15:43 +0000
X-Env-Sender: vijay.chander@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1326950134!9735918!1
X-Originating-IP: [209.85.210.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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28398 invoked from network); 19 Jan 2012 05:15:36 -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;
	19 Jan 2012 05:15:36 -0000
Received: by iahk25 with SMTP id k25so30731470iah.30
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 21:15: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
	:content-type; bh=KRLvtq/U8eGeVWu9O8DrNMsxz8qPNnDzVvr6XqYSjUM=;
	b=HTz1svNPEODeOVjPHefqTh1hVsdBGXzfWUAfWyS+6gLRpsdY9qbWGLexU5k8qEVUDq
	K5pmrxFO9fRU38YfU2JwWUTpEXOjuwXjBIMVWxNGaMPXRU51wruoc+U2q/ulobKhe0MM
	P7dmd/5rTUguvEeYCRUXGp9msEVz4RNvDoFhc=
MIME-Version: 1.0
Received: by 10.50.77.226 with SMTP id v2mr25450722igw.7.1326950134519; Wed,
	18 Jan 2012 21:15:34 -0800 (PST)
Received: by 10.231.152.12 with HTTP; Wed, 18 Jan 2012 21:15:34 -0800 (PST)
In-Reply-To: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>
References: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>
Date: Wed, 18 Jan 2012 21:15:34 -0800
Message-ID: <CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
From: Vijay Chander <vijay.chander@gmail.com>
To: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen + openvswitch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5732826188408856083=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5732826188408856083==
Content-Type: multipart/alternative; boundary=e89a8f234f396718db04b6daa767

--e89a8f234f396718db04b6daa767
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander <vijay.chander@gmail.com>wrote:

> Has anyone seen performance issues with xen 4.1.0 (the one used in
> xencenter 6.0)
> using open vswitch as opposed to native linux bridge ?
>
> We are tussling with needing the support guest vlan tagging and
> performance.
>
> Guest VM vlan tagging works with open vswitch . Perf seems to be much
> better
> with native linux bridge.
>
> Any useful pointers will be very helpul.
>
> Thanks,
> -kvc
>

--e89a8f234f396718db04b6daa767
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Jan 18, 2012 at 9:14 PM, Vijay C=
hander <span dir=3D"ltr">&lt;<a href=3D"mailto:vijay.chander@gmail.com">vij=
ay.chander@gmail.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=
">
Has anyone seen performance issues with xen 4.1.0 (the one used in xencente=
r 6.0)=A0<div>using open vswitch as opposed to native linux bridge ?</div><=
div><br></div><div>We are tussling with needing the support guest vlan tagg=
ing and performance.</div>

<div><br></div><div>Guest VM vlan tagging works with open vswitch . Perf se=
ems to be much better</div><div>with native linux bridge.</div><div><br></d=
iv><div>Any useful pointers will be very helpul.</div><div><br></div><div>

Thanks,</div><div>-kvc=A0</div>
</blockquote></div><br>

--e89a8f234f396718db04b6daa767--


--===============5732826188408856083==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5732826188408856083==--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 05:26:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 05: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 1RnkUy-0006St-KN; Thu, 19 Jan 2012 05:25:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RnkUw-0006Sm-MT
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 05:25:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326950711!9700995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTgyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16689 invoked from network); 19 Jan 2012 05:25:11 -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;
	19 Jan 2012 05:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,534,1320624000"; d="scan'208";a="10129990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 05:25:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 05:25:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnkUo-0001pi-Ct;
	Thu, 19 Jan 2012 05:25:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnkUo-0003Qd-BP;
	Thu, 19 Jan 2012 05:25:10 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10888-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 05:25:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10888: 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 10888 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10888/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10884
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10884
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10884
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10867
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2      fail in 10884 pass in 10867
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10884 pass in 10888

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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 10884 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10884 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 870 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 Jan 19 05:26:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 05: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 1RnkUy-0006St-KN; Thu, 19 Jan 2012 05:25:20 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RnkUw-0006Sm-MT
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 05:25:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1326950711!9700995!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTgyNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16689 invoked from network); 19 Jan 2012 05:25:11 -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;
	19 Jan 2012 05:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,534,1320624000"; d="scan'208";a="10129990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 05:25:10 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 05:25:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RnkUo-0001pi-Ct;
	Thu, 19 Jan 2012 05:25:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnkUo-0003Qd-BP;
	Thu, 19 Jan 2012 05:25:10 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10888-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 05:25:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10888: 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 10888 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10888/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rhel6hvm-amd  7 redhat-install              fail pass in 10884
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10884
 test-amd64-amd64-xl-win7-amd64  7 windows-install           fail pass in 10884
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10867
 test-amd64-amd64-xl-sedf-pin 16 guest-start.2      fail in 10884 pass in 10867
 test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10884 pass in 10888

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 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 10884 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 10884 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 870 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 Jan 19 08:10:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 08: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 1Rnn4U-0000aD-4w; Thu, 19 Jan 2012 08:10: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 1Rnn4S-0000a8-Df
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 08:10:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326960583!63073329!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 21647 invoked from network); 19 Jan 2012 08:09:44 -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; 19 Jan 2012 08:09:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 08:10:03 +0000
Message-Id: <4F17DDE8020000780006D952@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 08:10:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
	<4F16A402020000780006D571@nat28.tlf.novell.com>
	<4F170EBA.70101@amd.com>
In-Reply-To: <4F170EBA.70101@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] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.01.12 at 19:26, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 01/18/12 04:50, Jan Beulich wrote:
>>>>> On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum
>>> 400 as an example -- we don't need a Linux PV guest reading an MSR
>>> before going to idle (in amd_e400_idle()).
>>
>> It is bogus in the first place if a pv guest does so - after all, not doing
>> stuff like this is the nature of being pv.
> 
> It was actually a bad example --- the guest is not using amd_e400_idle() 
> and so there are no extra MSR accesses.
> 
> However, without this change OSVW bit will not show up in the guest's 
> CPUID and I think guests should be able to see it. One could argue 
> whether or not we should mask off status bits for the two errata (400 
> and 415) since they are not currently used; I'd mask them off just to be 
> consistent with HVM, it won't affect anything.

I continue to think otherwise - knowing of and dealing with this is
supposed to be entirely hidden from PV guests, unless and until
you can provide a counter example. Therefore I am likely to nak
this part of future revisions of the patch (which Keir could
certainly override), up to and including ripping out the PV part (and
adjusting the rest accordingly) if I would go for committing it.

>>>>> +    if (osvw_length == 0&&   boot_cpu_data.x86 == 0x10)
>>>>
>>>> Why do you check the family here? If osvw_length can only ever be
>>>> zero on Fam10, then the first check is sufficient. If osvw_length can
>>>> be zero on other than Fam10 (no matter whether we bail early older
>>>> CPUs), then the check is actually wrong.
>>>
>>> 10h is the only family affected by this erratum.
>>
>> What is "this erratum" here? My comment was to suggest that either
>> of the two conditions can likely be eliminated for being redundant.
> 
> ("This erratum" is erratum 298, which is bit 0)
> 
> If osvw_length!=0 then we don't need to do anything since bit 0 is 
> already valid.
> 
> If osvw_length==0 then -- since we just made the guest's version of this 
> register 3 and thus turned bit 0 from being invalid to valid -- we need 
> to do something about bit 0. But the bit can only be set on family 10h, 
> thus both checks.

Okay, got you. However, the whole thing will become superfluous
anyway if you bail on family less than 0x10 right at the start of the
function.

Btw., one more comment on the change to init_amd(): You will likely
need to distinguish BP and AP cases here - on the BP you want to
plainly write the values read from the MSRs to the global variables,
but on APs (with possibly different settings) you need to work
towards a setting of the global variables that apply to all of the
CPUs. This is not just for the (theoretical only?) hotplug case, but
particularly the one of a soft-offlined CPU that had its microcode
updated already in a way affecting the OSVW bits and is
subsequently being brought back online.

Which reminds you and me that the patch is missing integration with
the microcode update loader (as that one may alter the OSVW bits
iiuc).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 08:10:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 08: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 1Rnn4U-0000aD-4w; Thu, 19 Jan 2012 08:10: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 1Rnn4S-0000a8-Df
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 08:10:08 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326960583!63073329!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 21647 invoked from network); 19 Jan 2012 08:09:44 -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; 19 Jan 2012 08:09:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 08:10:03 +0000
Message-Id: <4F17DDE8020000780006D952@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 08:10:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
	<4F16A402020000780006D571@nat28.tlf.novell.com>
	<4F170EBA.70101@amd.com>
In-Reply-To: <4F170EBA.70101@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] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 18.01.12 at 19:26, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 01/18/12 04:50, Jan Beulich wrote:
>>>>> On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum
>>> 400 as an example -- we don't need a Linux PV guest reading an MSR
>>> before going to idle (in amd_e400_idle()).
>>
>> It is bogus in the first place if a pv guest does so - after all, not doing
>> stuff like this is the nature of being pv.
> 
> It was actually a bad example --- the guest is not using amd_e400_idle() 
> and so there are no extra MSR accesses.
> 
> However, without this change OSVW bit will not show up in the guest's 
> CPUID and I think guests should be able to see it. One could argue 
> whether or not we should mask off status bits for the two errata (400 
> and 415) since they are not currently used; I'd mask them off just to be 
> consistent with HVM, it won't affect anything.

I continue to think otherwise - knowing of and dealing with this is
supposed to be entirely hidden from PV guests, unless and until
you can provide a counter example. Therefore I am likely to nak
this part of future revisions of the patch (which Keir could
certainly override), up to and including ripping out the PV part (and
adjusting the rest accordingly) if I would go for committing it.

>>>>> +    if (osvw_length == 0&&   boot_cpu_data.x86 == 0x10)
>>>>
>>>> Why do you check the family here? If osvw_length can only ever be
>>>> zero on Fam10, then the first check is sufficient. If osvw_length can
>>>> be zero on other than Fam10 (no matter whether we bail early older
>>>> CPUs), then the check is actually wrong.
>>>
>>> 10h is the only family affected by this erratum.
>>
>> What is "this erratum" here? My comment was to suggest that either
>> of the two conditions can likely be eliminated for being redundant.
> 
> ("This erratum" is erratum 298, which is bit 0)
> 
> If osvw_length!=0 then we don't need to do anything since bit 0 is 
> already valid.
> 
> If osvw_length==0 then -- since we just made the guest's version of this 
> register 3 and thus turned bit 0 from being invalid to valid -- we need 
> to do something about bit 0. But the bit can only be set on family 10h, 
> thus both checks.

Okay, got you. However, the whole thing will become superfluous
anyway if you bail on family less than 0x10 right at the start of the
function.

Btw., one more comment on the change to init_amd(): You will likely
need to distinguish BP and AP cases here - on the BP you want to
plainly write the values read from the MSRs to the global variables,
but on APs (with possibly different settings) you need to work
towards a setting of the global variables that apply to all of the
CPUs. This is not just for the (theoretical only?) hotplug case, but
particularly the one of a soft-offlined CPU that had its microcode
updated already in a way affecting the OSVW bits and is
subsequently being brought back online.

Which reminds you and me that the patch is missing integration with
the microcode update loader (as that one may alter the OSVW bits
iiuc).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 08:31:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 08:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnnOG-00013o-9z; Thu, 19 Jan 2012 08:30: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 1RnnOF-00013j-FJ
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 08:30:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326961828!13020475!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 19233 invoked from network); 19 Jan 2012 08:30:29 -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; 19 Jan 2012 08:30:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 08:30:28 +0000
Message-Id: <4F17E2B1020000780006D965@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 08:30:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <osstest-10882-mainreport@xen.org>
In-Reply-To: <osstest-10882-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 10882: 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 18.01.12 at 19:19, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 10882 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10882/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
>  test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Finally spotted an actual crash in the logs here, pointing at a relatively
obvious problem: guest_iommu_mmio_range() is apparently lacking a
NULL check. Was this code ever tested on an Intel system?

I'll add this, but will first check whether I can spot other functions
missing such.

Jan

>  test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
>  test-amd64-i386-rhel6hvm-intel  7 redhat-install fail in 10875 REGR. vs. 10649
>  test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10875 REGR. vs. 10649
>  test-amd64-amd64-win          7 windows-install  fail in 10875 REGR. vs. 10649
>  test-amd64-amd64-xl-win       7 windows-install  fail in 10875 REGR. vs. 10649
>  test-amd64-i386-xl-win-vcpus1  7 windows-install fail in 10875 REGR. vs. 10649
>  test-amd64-i386-win-vcpus1    7 windows-install  fail in 10875 REGR. vs. 10649
>  test-amd64-i386-win           7 windows-install  fail in 10875 REGR. vs. 10649
>  test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10875 REGR. vs. 10649
>  test-amd64-amd64-xl-winxpsp3  7 windows-install  fail in 10875 REGR. vs. 10649



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 08:31:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 08:31:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnnOG-00013o-9z; Thu, 19 Jan 2012 08:30: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 1RnnOF-00013j-FJ
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 08:30:35 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326961828!13020475!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 19233 invoked from network); 19 Jan 2012 08:30:29 -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; 19 Jan 2012 08:30:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 08:30:28 +0000
Message-Id: <4F17E2B1020000780006D965@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 08:30:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <osstest-10882-mainreport@xen.org>
In-Reply-To: <osstest-10882-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 10882: 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 18.01.12 at 19:19, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 10882 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10882/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
>  test-i386-i386-win            7 windows-install           fail REGR. vs. 10649

Finally spotted an actual crash in the logs here, pointing at a relatively
obvious problem: guest_iommu_mmio_range() is apparently lacking a
NULL check. Was this code ever tested on an Intel system?

I'll add this, but will first check whether I can spot other functions
missing such.

Jan

>  test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649
>  test-amd64-i386-rhel6hvm-intel  7 redhat-install fail in 10875 REGR. vs. 10649
>  test-amd64-i386-xend-winxpsp3  7 windows-install fail in 10875 REGR. vs. 10649
>  test-amd64-amd64-win          7 windows-install  fail in 10875 REGR. vs. 10649
>  test-amd64-amd64-xl-win       7 windows-install  fail in 10875 REGR. vs. 10649
>  test-amd64-i386-xl-win-vcpus1  7 windows-install fail in 10875 REGR. vs. 10649
>  test-amd64-i386-win-vcpus1    7 windows-install  fail in 10875 REGR. vs. 10649
>  test-amd64-i386-win           7 windows-install  fail in 10875 REGR. vs. 10649
>  test-amd64-i386-xl-winxpsp3-vcpus1 7 windows-install fail in 10875 REGR. vs. 10649
>  test-amd64-amd64-xl-winxpsp3  7 windows-install  fail in 10875 REGR. vs. 10649



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 08:47:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 08:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnndV-0001FD-RY; Thu, 19 Jan 2012 08:46:21 +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 1RnndU-0001F5-7h
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 08:46:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326962768!13022929!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11295 invoked from network); 19 Jan 2012 08:46:10 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 08:46:10 -0000
Received: by werh12 with SMTP id h12so6876737wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 00:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ikQnK7NA155FlHGkDJF9VfJYFNImOV1WnxQXHcxxvHc=;
	b=HLX0wj+4+S3nkPti1ycgI+7Fh9U1VtbgCCgqhkjxjDCqCdWNvtrS1n+2eXoBjINr6U
	2bWcQOSnhdeZ+39LZI63Fnf3SHMpS+WIPqX5uKJZ0LJMLQeP0atRNMTzvxMcddw7anrC
	3c8i50OinmwYxTBtUr6JtF3TIr3cBGX+hB0Ps=
Received: by 10.216.45.199 with SMTP id p49mr9449434web.42.1326962767665;
	Thu, 19 Jan 2012 00:46:07 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id t15sm22978339wiv.6.2012.01.19.00.46.05
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 00:46:06 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 08:46:04 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <CB3D88CC.291A9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
	in guests
Thread-Index: AczWhscHbc7hyFQXH0Oo0HvkoG8KuQ==
In-Reply-To: <4F17DDE8020000780006D952@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/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19/01/2012 08:10, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 18.01.12 at 19:26, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> On 01/18/12 04:50, Jan Beulich wrote:
>>>>>> On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum
>>>> 400 as an example -- we don't need a Linux PV guest reading an MSR
>>>> before going to idle (in amd_e400_idle()).
>>> 
>>> It is bogus in the first place if a pv guest does so - after all, not doing
>>> stuff like this is the nature of being pv.
>> 
>> It was actually a bad example --- the guest is not using amd_e400_idle()
>> and so there are no extra MSR accesses.
>> 
>> However, without this change OSVW bit will not show up in the guest's
>> CPUID and I think guests should be able to see it. One could argue
>> whether or not we should mask off status bits for the two errata (400
>> and 415) since they are not currently used; I'd mask them off just to be
>> consistent with HVM, it won't affect anything.
> 
> I continue to think otherwise - knowing of and dealing with this is
> supposed to be entirely hidden from PV guests, unless and until
> you can provide a counter example. Therefore I am likely to nak
> this part of future revisions of the patch (which Keir could
> certainly override), up to and including ripping out the PV part (and
> adjusting the rest accordingly) if I would go for committing it.

Well, the general principle of exposing OSVW to PV guests doesn't seem
terrible. It's just the current specific motivation for exposing to HVM
guests does not apply to PV guests.

Are *any* of the current OSVW defined bits at all useful or applicable to PV
guests?

 -- Keir

>>>>>> +    if (osvw_length == 0&&   boot_cpu_data.x86 == 0x10)
>>>>> 
>>>>> Why do you check the family here? If osvw_length can only ever be
>>>>> zero on Fam10, then the first check is sufficient. If osvw_length can
>>>>> be zero on other than Fam10 (no matter whether we bail early older
>>>>> CPUs), then the check is actually wrong.
>>>> 
>>>> 10h is the only family affected by this erratum.
>>> 
>>> What is "this erratum" here? My comment was to suggest that either
>>> of the two conditions can likely be eliminated for being redundant.
>> 
>> ("This erratum" is erratum 298, which is bit 0)
>> 
>> If osvw_length!=0 then we don't need to do anything since bit 0 is
>> already valid.
>> 
>> If osvw_length==0 then -- since we just made the guest's version of this
>> register 3 and thus turned bit 0 from being invalid to valid -- we need
>> to do something about bit 0. But the bit can only be set on family 10h,
>> thus both checks.
> 
> Okay, got you. However, the whole thing will become superfluous
> anyway if you bail on family less than 0x10 right at the start of the
> function.
> 
> Btw., one more comment on the change to init_amd(): You will likely
> need to distinguish BP and AP cases here - on the BP you want to
> plainly write the values read from the MSRs to the global variables,
> but on APs (with possibly different settings) you need to work
> towards a setting of the global variables that apply to all of the
> CPUs. This is not just for the (theoretical only?) hotplug case, but
> particularly the one of a soft-offlined CPU that had its microcode
> updated already in a way affecting the OSVW bits and is
> subsequently being brought back online.
> 
> Which reminds you and me that the patch is missing integration with
> the microcode update loader (as that one may alter the OSVW bits
> iiuc).
> 
> 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 Thu Jan 19 08:47:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 08:47:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnndV-0001FD-RY; Thu, 19 Jan 2012 08:46:21 +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 1RnndU-0001F5-7h
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 08:46:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326962768!13022929!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11295 invoked from network); 19 Jan 2012 08:46:10 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 08:46:10 -0000
Received: by werh12 with SMTP id h12so6876737wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 00:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=ikQnK7NA155FlHGkDJF9VfJYFNImOV1WnxQXHcxxvHc=;
	b=HLX0wj+4+S3nkPti1ycgI+7Fh9U1VtbgCCgqhkjxjDCqCdWNvtrS1n+2eXoBjINr6U
	2bWcQOSnhdeZ+39LZI63Fnf3SHMpS+WIPqX5uKJZ0LJMLQeP0atRNMTzvxMcddw7anrC
	3c8i50OinmwYxTBtUr6JtF3TIr3cBGX+hB0Ps=
Received: by 10.216.45.199 with SMTP id p49mr9449434web.42.1326962767665;
	Thu, 19 Jan 2012 00:46:07 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id t15sm22978339wiv.6.2012.01.19.00.46.05
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 00:46:06 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 08:46:04 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>, Boris Ostrovsky <boris.ostrovsky@amd.com>
Message-ID: <CB3D88CC.291A9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
	in guests
Thread-Index: AczWhscHbc7hyFQXH0Oo0HvkoG8KuQ==
In-Reply-To: <4F17DDE8020000780006D952@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/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19/01/2012 08:10, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> On 18.01.12 at 19:26, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
>> On 01/18/12 04:50, Jan Beulich wrote:
>>>>>> On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum
>>>> 400 as an example -- we don't need a Linux PV guest reading an MSR
>>>> before going to idle (in amd_e400_idle()).
>>> 
>>> It is bogus in the first place if a pv guest does so - after all, not doing
>>> stuff like this is the nature of being pv.
>> 
>> It was actually a bad example --- the guest is not using amd_e400_idle()
>> and so there are no extra MSR accesses.
>> 
>> However, without this change OSVW bit will not show up in the guest's
>> CPUID and I think guests should be able to see it. One could argue
>> whether or not we should mask off status bits for the two errata (400
>> and 415) since they are not currently used; I'd mask them off just to be
>> consistent with HVM, it won't affect anything.
> 
> I continue to think otherwise - knowing of and dealing with this is
> supposed to be entirely hidden from PV guests, unless and until
> you can provide a counter example. Therefore I am likely to nak
> this part of future revisions of the patch (which Keir could
> certainly override), up to and including ripping out the PV part (and
> adjusting the rest accordingly) if I would go for committing it.

Well, the general principle of exposing OSVW to PV guests doesn't seem
terrible. It's just the current specific motivation for exposing to HVM
guests does not apply to PV guests.

Are *any* of the current OSVW defined bits at all useful or applicable to PV
guests?

 -- Keir

>>>>>> +    if (osvw_length == 0&&   boot_cpu_data.x86 == 0x10)
>>>>> 
>>>>> Why do you check the family here? If osvw_length can only ever be
>>>>> zero on Fam10, then the first check is sufficient. If osvw_length can
>>>>> be zero on other than Fam10 (no matter whether we bail early older
>>>>> CPUs), then the check is actually wrong.
>>>> 
>>>> 10h is the only family affected by this erratum.
>>> 
>>> What is "this erratum" here? My comment was to suggest that either
>>> of the two conditions can likely be eliminated for being redundant.
>> 
>> ("This erratum" is erratum 298, which is bit 0)
>> 
>> If osvw_length!=0 then we don't need to do anything since bit 0 is
>> already valid.
>> 
>> If osvw_length==0 then -- since we just made the guest's version of this
>> register 3 and thus turned bit 0 from being invalid to valid -- we need
>> to do something about bit 0. But the bit can only be set on family 10h,
>> thus both checks.
> 
> Okay, got you. However, the whole thing will become superfluous
> anyway if you bail on family less than 0x10 right at the start of the
> function.
> 
> Btw., one more comment on the change to init_amd(): You will likely
> need to distinguish BP and AP cases here - on the BP you want to
> plainly write the values read from the MSRs to the global variables,
> but on APs (with possibly different settings) you need to work
> towards a setting of the global variables that apply to all of the
> CPUs. This is not just for the (theoretical only?) hotplug case, but
> particularly the one of a soft-offlined CPU that had its microcode
> updated already in a way affecting the OSVW bits and is
> subsequently being brought back online.
> 
> Which reminds you and me that the patch is missing integration with
> the microcode update loader (as that one may alter the OSVW bits
> iiuc).
> 
> 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 Thu Jan 19 09:03:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnntZ-0001tR-Lw; Thu, 19 Jan 2012 09:02:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RnntY-0001sy-79
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:02:56 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326963769!10970292!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 22399 invoked from network); 19 Jan 2012 09:02:50 -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;
	19 Jan 2012 09:02:50 -0000
Received: by wgbdr11 with SMTP id dr11so4446681wgb.24
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:02:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=ZjXy78Ex+kpIglWfnGegcaSsGOSq2EsfJIfgJeZwDos=;
	b=dC4JC1dOZ3bhEG8J/cBwGuwVvwbvesAfJpdFZ9FITA1UiHt6H4MDoSpkSTjDWv7rzU
	6rn/aDrmrAOnl5lXWI3t1w9FKgl8zBmnvc96vB2uQmeaTqmha5wEWAqQuX1x7+HKUPMY
	aRXv/wNh5Ydzyq9AgYmnKJiO+VyXeGWSr8Cms=
MIME-Version: 1.0
Received: by 10.180.91.201 with SMTP id cg9mr42503630wib.15.1326963769659;
	Thu, 19 Jan 2012 01:02:49 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Thu, 19 Jan 2012 01:02:49 -0800 (PST)
Date: Thu, 19 Jan 2012 17:02:49 +0800
Message-ID: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I see cpu_raise_softirq calls smp_send_event_check_mask after setting
softirq bit for target CPU if target CPU is not the current CPU. I
thought smp_send_event_check_mask will send IPI to target CPU and then
trigger target CPU to run pending irq, but seems
smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
the purpose of this function? Why do we need this function?

BTW, would someone gives me some knowledge when will the pending irqs
be triggered to run after setting up the pending bits? Seems normally
they are called asynchronously.

Thanks in advance!

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 09:03:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09:03:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnntZ-0001tR-Lw; Thu, 19 Jan 2012 09:02:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mail.kai.huang@gmail.com>) id 1RnntY-0001sy-79
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:02:56 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1326963769!10970292!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 22399 invoked from network); 19 Jan 2012 09:02:50 -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;
	19 Jan 2012 09:02:50 -0000
Received: by wgbdr11 with SMTP id dr11so4446681wgb.24
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:02:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=ZjXy78Ex+kpIglWfnGegcaSsGOSq2EsfJIfgJeZwDos=;
	b=dC4JC1dOZ3bhEG8J/cBwGuwVvwbvesAfJpdFZ9FITA1UiHt6H4MDoSpkSTjDWv7rzU
	6rn/aDrmrAOnl5lXWI3t1w9FKgl8zBmnvc96vB2uQmeaTqmha5wEWAqQuX1x7+HKUPMY
	aRXv/wNh5Ydzyq9AgYmnKJiO+VyXeGWSr8Cms=
MIME-Version: 1.0
Received: by 10.180.91.201 with SMTP id cg9mr42503630wib.15.1326963769659;
	Thu, 19 Jan 2012 01:02:49 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Thu, 19 Jan 2012 01:02:49 -0800 (PST)
Date: Thu, 19 Jan 2012 17:02:49 +0800
Message-ID: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Xen-devel@lists.xensource.com
Subject: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

I see cpu_raise_softirq calls smp_send_event_check_mask after setting
softirq bit for target CPU if target CPU is not the current CPU. I
thought smp_send_event_check_mask will send IPI to target CPU and then
trigger target CPU to run pending irq, but seems
smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
the purpose of this function? Why do we need this function?

BTW, would someone gives me some knowledge when will the pending irqs
be triggered to run after setting up the pending bits? Seems normally
they are called asynchronously.

Thanks in advance!

-cody

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 09:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnnx0-00025w-A4; Thu, 19 Jan 2012 09:06:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rnnwz-00025h-Pg
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:06:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326963983!7808945!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 10416 invoked from network); 19 Jan 2012 09:06:23 -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; 19 Jan 2012 09:06:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 09:06:22 +0000
Message-Id: <4F17EB1C020000780006D974@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 09:06:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <osstest-10882-mainreport@xen.org>
	<4F17E2B1020000780006D965@nat28.tlf.novell.com>
In-Reply-To: <4F17E2B1020000780006D965@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 10882: 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 19.01.12 at 09:30, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 18.01.12 at 19:19, xen.org <ian.jackson@eu.citrix.com> wrote:
>> flight 10882 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/10882/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
>>  test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
> 
> Finally spotted an actual crash in the logs here, pointing at a relatively
> obvious problem: guest_iommu_mmio_range() is apparently lacking a
> NULL check. Was this code ever tested on an Intel system?
> 
> I'll add this, but will first check whether I can spot other functions
> missing such.

Below the patch I'm going to commit.

Jan

add NULL checks in code added by 24492:6c104b46ef89 

Also a couple of missing is_hvm_domain() checks.

Further properly pass the PCI segment in a call to pci_get_pdev().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -182,7 +182,13 @@ void guest_iommu_add_ppr_log(struct doma
     ppr_entry_t *log, *log_base;
     struct guest_iommu *iommu;
 
+    if ( !is_hvm_domain(d) )
+        return;
+
     iommu = domain_iommu(d);
+    if ( !iommu )
+        return;
+
     tail = iommu_get_rb_pointer(iommu->ppr_log.reg_tail.lo);
     head = iommu_get_rb_pointer(iommu->ppr_log.reg_head.lo);
 
@@ -225,7 +231,13 @@ void guest_iommu_add_event_log(struct do
     event_entry_t *log, *log_base;
     struct guest_iommu *iommu;
 
+    if ( !is_hvm_domain(d) )
+        return;
+
     iommu = domain_iommu(d);
+    if ( !iommu )
+        return;
+
     tail = iommu_get_rb_pointer(iommu->event_log.reg_tail.lo);
     head = iommu_get_rb_pointer(iommu->event_log.reg_head.lo);
 
@@ -793,6 +805,9 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
+    if ( !iommu )
+        return -EACCES;
+
     iommu->mmio_base = base;
     base >>= PAGE_SHIFT;
 
@@ -882,6 +897,8 @@ void guest_iommu_destroy(struct domain *
         return;
 
     iommu = domain_iommu(d);
+    if ( !iommu )
+        return;
 
     tasklet_kill(&iommu->cmd_buffer_tasklet);
     xfree(iommu);
@@ -893,7 +910,7 @@ static int guest_iommu_mmio_range(struct
 {
     struct guest_iommu *iommu = vcpu_iommu(v);
 
-    return addr >= iommu->mmio_base &&
+    return iommu && addr >= iommu->mmio_base &&
            addr < iommu->mmio_base + IOMMU_MMIO_SIZE;
 }
 
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -651,7 +651,7 @@ void parse_ppr_log_entry(struct amd_iomm
     local_irq_enable();
 
     spin_lock(&pcidevs_lock);
-    pdev = pci_get_pdev(0, bus, devfn);
+    pdev = pci_get_pdev(iommu->seg, bus, devfn);
     spin_unlock(&pcidevs_lock);
 
     local_irq_disable();




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 09:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnnx0-00025w-A4; Thu, 19 Jan 2012 09:06:30 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rnnwz-00025h-Pg
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:06:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326963983!7808945!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 10416 invoked from network); 19 Jan 2012 09:06:23 -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; 19 Jan 2012 09:06:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 09:06:22 +0000
Message-Id: <4F17EB1C020000780006D974@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 09:06:20 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang2" <wei.wang2@amd.com>
References: <osstest-10882-mainreport@xen.org>
	<4F17E2B1020000780006D965@nat28.tlf.novell.com>
In-Reply-To: <4F17E2B1020000780006D965@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, ian.jackson@eu.citrix.com
Subject: Re: [Xen-devel] [xen-unstable test] 10882: 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 19.01.12 at 09:30, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 18.01.12 at 19:19, xen.org <ian.jackson@eu.citrix.com> wrote:
>> flight 10882 xen-unstable real [real]
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/10882/ 
>> 
>> Regressions :-(
>> 
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>  test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
>>  test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
> 
> Finally spotted an actual crash in the logs here, pointing at a relatively
> obvious problem: guest_iommu_mmio_range() is apparently lacking a
> NULL check. Was this code ever tested on an Intel system?
> 
> I'll add this, but will first check whether I can spot other functions
> missing such.

Below the patch I'm going to commit.

Jan

add NULL checks in code added by 24492:6c104b46ef89 

Also a couple of missing is_hvm_domain() checks.

Further properly pass the PCI segment in a call to pci_get_pdev().

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -182,7 +182,13 @@ void guest_iommu_add_ppr_log(struct doma
     ppr_entry_t *log, *log_base;
     struct guest_iommu *iommu;
 
+    if ( !is_hvm_domain(d) )
+        return;
+
     iommu = domain_iommu(d);
+    if ( !iommu )
+        return;
+
     tail = iommu_get_rb_pointer(iommu->ppr_log.reg_tail.lo);
     head = iommu_get_rb_pointer(iommu->ppr_log.reg_head.lo);
 
@@ -225,7 +231,13 @@ void guest_iommu_add_event_log(struct do
     event_entry_t *log, *log_base;
     struct guest_iommu *iommu;
 
+    if ( !is_hvm_domain(d) )
+        return;
+
     iommu = domain_iommu(d);
+    if ( !iommu )
+        return;
+
     tail = iommu_get_rb_pointer(iommu->event_log.reg_tail.lo);
     head = iommu_get_rb_pointer(iommu->event_log.reg_head.lo);
 
@@ -793,6 +805,9 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
+    if ( !iommu )
+        return -EACCES;
+
     iommu->mmio_base = base;
     base >>= PAGE_SHIFT;
 
@@ -882,6 +897,8 @@ void guest_iommu_destroy(struct domain *
         return;
 
     iommu = domain_iommu(d);
+    if ( !iommu )
+        return;
 
     tasklet_kill(&iommu->cmd_buffer_tasklet);
     xfree(iommu);
@@ -893,7 +910,7 @@ static int guest_iommu_mmio_range(struct
 {
     struct guest_iommu *iommu = vcpu_iommu(v);
 
-    return addr >= iommu->mmio_base &&
+    return iommu && addr >= iommu->mmio_base &&
            addr < iommu->mmio_base + IOMMU_MMIO_SIZE;
 }
 
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -651,7 +651,7 @@ void parse_ppr_log_entry(struct amd_iomm
     local_irq_enable();
 
     spin_lock(&pcidevs_lock);
-    pdev = pci_get_pdev(0, bus, devfn);
+    pdev = pci_get_pdev(iommu->seg, bus, devfn);
     spin_unlock(&pcidevs_lock);
 
     local_irq_disable();




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 09:14:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09: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 1Rno4U-0002OY-8j; Thu, 19 Jan 2012 09:14:14 +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 1Rno4S-0002OM-Pc
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:14:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326964446!11497276!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25909 invoked from network); 19 Jan 2012 09:14:06 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 09:14:06 -0000
Received: by wibhj8 with SMTP id hj8so17394493wib.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:14: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=HqXAcu69WG6842b0p8lmYtBgb4eNj2mqxDk6pewWXwk=;
	b=iEmizJSBts6vZPNZy9IjLyYlKFKEE+N4n62+sAS0I0Ky53G49w5BZYSGy+ad00CmpC
	bl2VfkhQwKNMMfoLGbEhDWLaCCM3w7lyo12bxyIKsFTfwMRn+R93cN7oybitAUgruz74
	3CtQuQrgXPHdma7VST9CZh1JNLFTXSAkaMldk=
Received: by 10.180.76.235 with SMTP id n11mr37322945wiw.11.1326964446623;
	Thu, 19 Jan 2012 01:14:06 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q7sm26948645wix.5.2012.01.19.01.14.05
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 01:14:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 09:14:04 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>,
	<Xen-devel@lists.xensource.com>
Message-ID: <CB3D8F5C.291AF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
Thread-Index: AczWirBifDZlwef2vEuJ7t4XrMv6ag==
In-Reply-To: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [question] what's the purpose of
 smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:

> Hi,
> 
> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
> softirq bit for target CPU if target CPU is not the current CPU. I
> thought smp_send_event_check_mask will send IPI to target CPU and then
> trigger target CPU to run pending irq, but seems
> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
> the purpose of this function? Why do we need this function?

Xen always checks softirqs on return from interrupt context to guest
context, and also in its idle loopon wakeup. Hence the event_check interrupt
handler itself doesn't need to do anything.

> BTW, would someone gives me some knowledge when will the pending irqs
> be triggered to run after setting up the pending bits? Seems normally
> they are called asynchronously.

Yes, of course it's asynchronous, the smp_send_event_check_mask interrupt is
just to make sure it happens "soon".

 -- Keir

> Thanks in advance!
> 
> -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 Jan 19 09:14:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09: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 1Rno4U-0002OY-8j; Thu, 19 Jan 2012 09:14:14 +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 1Rno4S-0002OM-Pc
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:14:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326964446!11497276!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25909 invoked from network); 19 Jan 2012 09:14:06 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 09:14:06 -0000
Received: by wibhj8 with SMTP id hj8so17394493wib.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:14: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=HqXAcu69WG6842b0p8lmYtBgb4eNj2mqxDk6pewWXwk=;
	b=iEmizJSBts6vZPNZy9IjLyYlKFKEE+N4n62+sAS0I0Ky53G49w5BZYSGy+ad00CmpC
	bl2VfkhQwKNMMfoLGbEhDWLaCCM3w7lyo12bxyIKsFTfwMRn+R93cN7oybitAUgruz74
	3CtQuQrgXPHdma7VST9CZh1JNLFTXSAkaMldk=
Received: by 10.180.76.235 with SMTP id n11mr37322945wiw.11.1326964446623;
	Thu, 19 Jan 2012 01:14:06 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q7sm26948645wix.5.2012.01.19.01.14.05
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 01:14:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 09:14:04 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Kai Huang <mail.kai.huang@gmail.com>,
	<Xen-devel@lists.xensource.com>
Message-ID: <CB3D8F5C.291AF%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
Thread-Index: AczWirBifDZlwef2vEuJ7t4XrMv6ag==
In-Reply-To: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [question] what's the purpose of
 smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:

> Hi,
> 
> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
> softirq bit for target CPU if target CPU is not the current CPU. I
> thought smp_send_event_check_mask will send IPI to target CPU and then
> trigger target CPU to run pending irq, but seems
> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
> the purpose of this function? Why do we need this function?

Xen always checks softirqs on return from interrupt context to guest
context, and also in its idle loopon wakeup. Hence the event_check interrupt
handler itself doesn't need to do anything.

> BTW, would someone gives me some knowledge when will the pending irqs
> be triggered to run after setting up the pending bits? Seems normally
> they are called asynchronously.

Yes, of course it's asynchronous, the smp_send_event_check_mask interrupt is
just to make sure it happens "soon".

 -- Keir

> Thanks in advance!
> 
> -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 Jan 19 09:19:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09: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 1Rno8u-0002iH-V5; Thu, 19 Jan 2012 09:18:48 +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 1Rno8t-0002i6-EO
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:18:47 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326964675!50716316!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16064 invoked from network); 19 Jan 2012 09:17:55 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 09:17:55 -0000
Received: by wibhj8 with SMTP id hj8so17403647wib.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:18:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=qDVGFGgTi9jeXE8KkThRaYVyPDbDpqMwaM+8khN9Mv8=;
	b=bWmakinUKtbckRt2D5tc5YFNrbJay8UaABlYG5KDjFw9lHRgMQ6Nd40IO1FkIWtAu9
	HbIIMsev16A4KUlXIZIZ0XohnXbhOmZtokK7BL2nFfv3PGyRzKH5uI0nkF83WzGmJSlQ
	zT/FhFHlq+BrjOevQX2Mw5XXLSC8mrW4Brm64=
MIME-Version: 1.0
Received: by 10.180.19.97 with SMTP id d1mr42359973wie.12.1326964721220; Thu,
	19 Jan 2012 01:18:41 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Thu, 19 Jan 2012 01:18:41 -0800 (PST)
In-Reply-To: <CB3D8F5C.291AF%keir.xen@gmail.com>
References: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
	<CB3D8F5C.291AF%keir.xen@gmail.com>
Date: Thu, 19 Jan 2012 17:18:41 +0800
Message-ID: <CANqQZNHMYN+Wnn3-2uGXkUGN8KMzB0de64cOavTuvEN4eGG_Yg@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, Jan 19, 2012 at 5:14 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>
> On 19/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:
>
>> Hi,
>>
>> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
>> softirq bit for target CPU if target CPU is not the current CPU. I
>> thought smp_send_event_check_mask will send IPI to target CPU and then
>> trigger target CPU to run pending irq, but seems
>> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
>> the purpose of this function? Why do we need this function?
>
> Xen always checks softirqs on return from interrupt context to guest
> context, and also in its idle loopon wakeup. Hence the event_check interr=
upt
> handler itself doesn't need to do anything.

Thanks. This makes sense.

-cody

>
>> BTW, would someone gives me some knowledge when will the pending irqs
>> be triggered to run after setting up the pending bits? Seems normally
>> they are called asynchronously.
>
> Yes, of course it's asynchronous, the smp_send_event_check_mask interrupt=
 is
> just to make sure it happens "soon".
>
> =A0-- Keir
>
>> Thanks in advance!
>>
>> -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 Jan 19 09:19:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09: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 1Rno8u-0002iH-V5; Thu, 19 Jan 2012 09:18:48 +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 1Rno8t-0002i6-EO
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:18:47 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326964675!50716316!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16064 invoked from network); 19 Jan 2012 09:17:55 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 09:17:55 -0000
Received: by wibhj8 with SMTP id hj8so17403647wib.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:18:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=qDVGFGgTi9jeXE8KkThRaYVyPDbDpqMwaM+8khN9Mv8=;
	b=bWmakinUKtbckRt2D5tc5YFNrbJay8UaABlYG5KDjFw9lHRgMQ6Nd40IO1FkIWtAu9
	HbIIMsev16A4KUlXIZIZ0XohnXbhOmZtokK7BL2nFfv3PGyRzKH5uI0nkF83WzGmJSlQ
	zT/FhFHlq+BrjOevQX2Mw5XXLSC8mrW4Brm64=
MIME-Version: 1.0
Received: by 10.180.19.97 with SMTP id d1mr42359973wie.12.1326964721220; Thu,
	19 Jan 2012 01:18:41 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Thu, 19 Jan 2012 01:18:41 -0800 (PST)
In-Reply-To: <CB3D8F5C.291AF%keir.xen@gmail.com>
References: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
	<CB3D8F5C.291AF%keir.xen@gmail.com>
Date: Thu, 19 Jan 2012 17:18:41 +0800
Message-ID: <CANqQZNHMYN+Wnn3-2uGXkUGN8KMzB0de64cOavTuvEN4eGG_Yg@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, Jan 19, 2012 at 5:14 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>
> On 19/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:
>
>> Hi,
>>
>> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
>> softirq bit for target CPU if target CPU is not the current CPU. I
>> thought smp_send_event_check_mask will send IPI to target CPU and then
>> trigger target CPU to run pending irq, but seems
>> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
>> the purpose of this function? Why do we need this function?
>
> Xen always checks softirqs on return from interrupt context to guest
> context, and also in its idle loopon wakeup. Hence the event_check interr=
upt
> handler itself doesn't need to do anything.

Thanks. This makes sense.

-cody

>
>> BTW, would someone gives me some knowledge when will the pending irqs
>> be triggered to run after setting up the pending bits? Seems normally
>> they are called asynchronously.
>
> Yes, of course it's asynchronous, the smp_send_event_check_mask interrupt=
 is
> just to make sure it happens "soon".
>
> =A0-- Keir
>
>> Thanks in advance!
>>
>> -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 Jan 19 09:26:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnoGS-0002tS-So; Thu, 19 Jan 2012 09:26:36 +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 1RnoGR-0002tN-C9
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:26:35 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326965187!7915297!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 15443 invoked from network); 19 Jan 2012 09:26:27 -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;
	19 Jan 2012 09:26:27 -0000
Received: by wgbdr11 with SMTP id dr11so4467402wgb.24
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:26: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:content-transfer-encoding;
	bh=uvtobjhdvdZSNnF3dXx7A/gGqVwaWwQJqCWo3u6rMu8=;
	b=nkEDAM/C52f/99AbKMo1nQyDfz8BTuZKGsi5pHzjO4lNtJKGysK8MzEoiFV5SjTg0D
	mlXh4XQDUrpGOREf8tfFv3eFPutVgKKk90nLk7gUrCJ1ETVhqEny02MRLU89ab+XUc3S
	kH0jNvs+QUXEman01XBzz3JyMt/p52VJC4ylI=
MIME-Version: 1.0
Received: by 10.180.91.201 with SMTP id cg9mr42638443wib.15.1326965186920;
	Thu, 19 Jan 2012 01:26:26 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Thu, 19 Jan 2012 01:26:26 -0800 (PST)
In-Reply-To: <CB3D8F5C.291AF%keir.xen@gmail.com>
References: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
	<CB3D8F5C.291AF%keir.xen@gmail.com>
Date: Thu, 19 Jan 2012 17:26:26 +0800
Message-ID: <CANqQZNG17CQEZH1a4E8f25=3RHXEDbW_FnjOsrNSs71Aew1SZw@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, Jan 19, 2012 at 5:14 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>
> On 19/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:
>
>> Hi,
>>
>> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
>> softirq bit for target CPU if target CPU is not the current CPU. I
>> thought smp_send_event_check_mask will send IPI to target CPU and then
>> trigger target CPU to run pending irq, but seems
>> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
>> the purpose of this function? Why do we need this function?
>
> Xen always checks softirqs on return from interrupt context to guest
> context, and also in its idle loopon wakeup. Hence the event_check interr=
upt
> handler itself doesn't need to do anything.

Does this mean if raising softirq for remote CPU, we don't need to
call do_softirq explicitly on target CPU?

-cody

>
>> BTW, would someone gives me some knowledge when will the pending irqs
>> be triggered to run after setting up the pending bits? Seems normally
>> they are called asynchronously.
>
> Yes, of course it's asynchronous, the smp_send_event_check_mask interrupt=
 is
> just to make sure it happens "soon".
>
> =A0-- Keir
>
>> Thanks in advance!
>>
>> -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 Jan 19 09:26:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09:26:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnoGS-0002tS-So; Thu, 19 Jan 2012 09:26:36 +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 1RnoGR-0002tN-C9
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:26:35 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1326965187!7915297!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 15443 invoked from network); 19 Jan 2012 09:26:27 -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;
	19 Jan 2012 09:26:27 -0000
Received: by wgbdr11 with SMTP id dr11so4467402wgb.24
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:26: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:content-transfer-encoding;
	bh=uvtobjhdvdZSNnF3dXx7A/gGqVwaWwQJqCWo3u6rMu8=;
	b=nkEDAM/C52f/99AbKMo1nQyDfz8BTuZKGsi5pHzjO4lNtJKGysK8MzEoiFV5SjTg0D
	mlXh4XQDUrpGOREf8tfFv3eFPutVgKKk90nLk7gUrCJ1ETVhqEny02MRLU89ab+XUc3S
	kH0jNvs+QUXEman01XBzz3JyMt/p52VJC4ylI=
MIME-Version: 1.0
Received: by 10.180.91.201 with SMTP id cg9mr42638443wib.15.1326965186920;
	Thu, 19 Jan 2012 01:26:26 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Thu, 19 Jan 2012 01:26:26 -0800 (PST)
In-Reply-To: <CB3D8F5C.291AF%keir.xen@gmail.com>
References: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
	<CB3D8F5C.291AF%keir.xen@gmail.com>
Date: Thu, 19 Jan 2012 17:26:26 +0800
Message-ID: <CANqQZNG17CQEZH1a4E8f25=3RHXEDbW_FnjOsrNSs71Aew1SZw@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, Jan 19, 2012 at 5:14 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>
> On 19/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:
>
>> Hi,
>>
>> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
>> softirq bit for target CPU if target CPU is not the current CPU. I
>> thought smp_send_event_check_mask will send IPI to target CPU and then
>> trigger target CPU to run pending irq, but seems
>> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
>> the purpose of this function? Why do we need this function?
>
> Xen always checks softirqs on return from interrupt context to guest
> context, and also in its idle loopon wakeup. Hence the event_check interr=
upt
> handler itself doesn't need to do anything.

Does this mean if raising softirq for remote CPU, we don't need to
call do_softirq explicitly on target CPU?

-cody

>
>> BTW, would someone gives me some knowledge when will the pending irqs
>> be triggered to run after setting up the pending bits? Seems normally
>> they are called asynchronously.
>
> Yes, of course it's asynchronous, the smp_send_event_check_mask interrupt=
 is
> just to make sure it happens "soon".
>
> =A0-- Keir
>
>> Thanks in advance!
>>
>> -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 Jan 19 09:50:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09: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 1Rnocv-0004Pz-2q; Thu, 19 Jan 2012 09:49:49 +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 1Rnoct-0004Pf-Gk
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:49:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326966581!9794780!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22058 invoked from network); 19 Jan 2012 09:49:41 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 09:49:41 -0000
Received: by werh12 with SMTP id h12so7003784wer.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:49: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GmPDTTRlrjmbAsT67tPy/afNOv3ssz+NwQ5+xvovFxg=;
	b=nhCU+lIIKEOM7PP2vKFJXyxtunJhbtedVC03mMAprBUT27mtaelvJCnuFE0Ju8uBJU
	pICYO7IPtT1lpY2IEmTlOFwmpRFfKF0+KPNL/BK4VUHAJq9OPhGrVz3k4hH1g33cvptV
	dAAWybo9R+IHUwag7QjOv0OkxhTbsDmeJhf9Q=
Received: by 10.216.139.204 with SMTP id c54mr10903428wej.13.1326966579451;
	Thu, 19 Jan 2012 01:49:39 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l2sm51988463wie.11.2012.01.19.01.49.38
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 01:49:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 09:49:35 +0000
From: Keir Fraser <keir@xen.org>
To: Kai Huang <mail.kai.huang@gmail.com>
Message-ID: <CB3D97AF.37BB9%keir@xen.org>
Thread-Topic: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
Thread-Index: AczWj6aPVsCRjiEvMUaqlB2QSCvsgg==
In-Reply-To: <CANqQZNG17CQEZH1a4E8f25=3RHXEDbW_FnjOsrNSs71Aew1SZw@mail.gmail.com>
Mime-version: 1.0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] what's the purpose of
 smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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/01/2012 09:26, "Kai Huang" <mail.kai.huang@gmail.com> wrote:

> On Thu, Jan 19, 2012 at 5:14 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> =

>> On 19/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:
>> =

>>> Hi,
>>> =

>>> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
>>> softirq bit for target CPU if target CPU is not the current CPU. I
>>> thought smp_send_event_check_mask will send IPI to target CPU and then
>>> trigger target CPU to run pending irq, but seems
>>> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
>>> the purpose of this function? Why do we need this function?
>> =

>> Xen always checks softirqs on return from interrupt context to guest
>> context, and also in its idle loopon wakeup. Hence the event_check inter=
rupt
>> handler itself doesn't need to do anything.
> =

> Does this mean if raising softirq for remote CPU, we don't need to
> call do_softirq explicitly on target CPU?

That's right, it's called automatically from various places, which you can
grep for.

 -- Keir

> -cody
> =

>> =

>>> BTW, would someone gives me some knowledge when will the pending irqs
>>> be triggered to run after setting up the pending bits? Seems normally
>>> they are called asynchronously.
>> =

>> Yes, of course it's asynchronous, the smp_send_event_check_mask interrup=
t is
>> just to make sure it happens "soon".
>> =

>> =A0-- Keir
>> =

>>> Thanks in advance!
>>> =

>>> -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 Jan 19 09:50:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09: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 1Rnocv-0004Pz-2q; Thu, 19 Jan 2012 09:49:49 +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 1Rnoct-0004Pf-Gk
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:49:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1326966581!9794780!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22058 invoked from network); 19 Jan 2012 09:49:41 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 09:49:41 -0000
Received: by werh12 with SMTP id h12so7003784wer.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:49: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=GmPDTTRlrjmbAsT67tPy/afNOv3ssz+NwQ5+xvovFxg=;
	b=nhCU+lIIKEOM7PP2vKFJXyxtunJhbtedVC03mMAprBUT27mtaelvJCnuFE0Ju8uBJU
	pICYO7IPtT1lpY2IEmTlOFwmpRFfKF0+KPNL/BK4VUHAJq9OPhGrVz3k4hH1g33cvptV
	dAAWybo9R+IHUwag7QjOv0OkxhTbsDmeJhf9Q=
Received: by 10.216.139.204 with SMTP id c54mr10903428wej.13.1326966579451;
	Thu, 19 Jan 2012 01:49:39 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l2sm51988463wie.11.2012.01.19.01.49.38
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 01:49:38 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 09:49:35 +0000
From: Keir Fraser <keir@xen.org>
To: Kai Huang <mail.kai.huang@gmail.com>
Message-ID: <CB3D97AF.37BB9%keir@xen.org>
Thread-Topic: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
Thread-Index: AczWj6aPVsCRjiEvMUaqlB2QSCvsgg==
In-Reply-To: <CANqQZNG17CQEZH1a4E8f25=3RHXEDbW_FnjOsrNSs71Aew1SZw@mail.gmail.com>
Mime-version: 1.0
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] what's the purpose of
 smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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/01/2012 09:26, "Kai Huang" <mail.kai.huang@gmail.com> wrote:

> On Thu, Jan 19, 2012 at 5:14 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> =

>> On 19/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:
>> =

>>> Hi,
>>> =

>>> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
>>> softirq bit for target CPU if target CPU is not the current CPU. I
>>> thought smp_send_event_check_mask will send IPI to target CPU and then
>>> trigger target CPU to run pending irq, but seems
>>> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
>>> the purpose of this function? Why do we need this function?
>> =

>> Xen always checks softirqs on return from interrupt context to guest
>> context, and also in its idle loopon wakeup. Hence the event_check inter=
rupt
>> handler itself doesn't need to do anything.
> =

> Does this mean if raising softirq for remote CPU, we don't need to
> call do_softirq explicitly on target CPU?

That's right, it's called automatically from various places, which you can
grep for.

 -- Keir

> -cody
> =

>> =

>>> BTW, would someone gives me some knowledge when will the pending irqs
>>> be triggered to run after setting up the pending bits? Seems normally
>>> they are called asynchronously.
>> =

>> Yes, of course it's asynchronous, the smp_send_event_check_mask interrup=
t is
>> just to make sure it happens "soon".
>> =

>> =A0-- Keir
>> =

>>> Thanks in advance!
>>> =

>>> -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 Jan 19 09:53:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09:53:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnofn-0004bW-Od; Thu, 19 Jan 2012 09:52:47 +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 1Rnofl-0004bN-QU
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:52:46 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326966698!61623569!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8204 invoked from network); 19 Jan 2012 09:51:38 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 09:51:38 -0000
Received: by wibhj8 with SMTP id hj8so17471839wib.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:52:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=tqGIOrIge39IR/J7j2GyCn/e1Iq4r2g30iFegoJKxv8=;
	b=hCtK0QDpt4SkWjG8S7PnX6lMKQoAoOB3BVKrwg+fJXZXDfwG06PZ3+Pj2rEyIrM3rQ
	aqUA4A9YXYkaNL++oskK18eH8Tj/LB+M8CyQpt0JnSFK4XTjKWNnF0Yo5gnRfenJQeRG
	oPh3MNX7UXfXCwSb3fXtjwlWxbqoPRx5ANMcs=
MIME-Version: 1.0
Received: by 10.181.13.208 with SMTP id fa16mr42997471wid.12.1326966764619;
	Thu, 19 Jan 2012 01:52:44 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Thu, 19 Jan 2012 01:52:44 -0800 (PST)
In-Reply-To: <CANqQZNG17CQEZH1a4E8f25=3RHXEDbW_FnjOsrNSs71Aew1SZw@mail.gmail.com>
References: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
	<CB3D8F5C.291AF%keir.xen@gmail.com>
	<CANqQZNG17CQEZH1a4E8f25=3RHXEDbW_FnjOsrNSs71Aew1SZw@mail.gmail.com>
Date: Thu, 19 Jan 2012 17:52:44 +0800
Message-ID: <CANqQZNEc=ijFB+_9wtXD1QOUxVY310fD3CLsW-nXKLAktrUh5w@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, Jan 19, 2012 at 5:26 PM, Kai Huang <mail.kai.huang@gmail.com> wrote:
> On Thu, Jan 19, 2012 at 5:14 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>>
>> On 19/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
>>> softirq bit for target CPU if target CPU is not the current CPU. I
>>> thought smp_send_event_check_mask will send IPI to target CPU and then
>>> trigger target CPU to run pending irq, but seems
>>> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
>>> the purpose of this function? Why do we need this function?
>>
>> Xen always checks softirqs on return from interrupt context to guest
>> context, and also in its idle loopon wakeup. Hence the event_check inter=
rupt
>> handler itself doesn't need to do anything.
>
> Does this mean if raising softirq for remote CPU, we don't need to
> call do_softirq explicitly on target CPU?
>

I think I understand now after looking at the code. When interrupt
returns, if there's any pending softirqs, the do_softirq will be
called. do_softirq will run handler for all pending bits and
additional call to do_softirq will have no harm as it just do nothing
if no bits are pending.

Thanks.

-cody

> -cody
>
>>
>>> BTW, would someone gives me some knowledge when will the pending irqs
>>> be triggered to run after setting up the pending bits? Seems normally
>>> they are called asynchronously.
>>
>> Yes, of course it's asynchronous, the smp_send_event_check_mask interrup=
t is
>> just to make sure it happens "soon".
>>
>> =A0-- Keir
>>
>>> Thanks in advance!
>>>
>>> -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 Jan 19 09:53:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 09:53:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnofn-0004bW-Od; Thu, 19 Jan 2012 09:52:47 +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 1Rnofl-0004bN-QU
	for Xen-devel@lists.xensource.com; Thu, 19 Jan 2012 09:52:46 +0000
X-Env-Sender: mail.kai.huang@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1326966698!61623569!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8204 invoked from network); 19 Jan 2012 09:51:38 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 09:51:38 -0000
Received: by wibhj8 with SMTP id hj8so17471839wib.30
	for <Xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 01:52:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=tqGIOrIge39IR/J7j2GyCn/e1Iq4r2g30iFegoJKxv8=;
	b=hCtK0QDpt4SkWjG8S7PnX6lMKQoAoOB3BVKrwg+fJXZXDfwG06PZ3+Pj2rEyIrM3rQ
	aqUA4A9YXYkaNL++oskK18eH8Tj/LB+M8CyQpt0JnSFK4XTjKWNnF0Yo5gnRfenJQeRG
	oPh3MNX7UXfXCwSb3fXtjwlWxbqoPRx5ANMcs=
MIME-Version: 1.0
Received: by 10.181.13.208 with SMTP id fa16mr42997471wid.12.1326966764619;
	Thu, 19 Jan 2012 01:52:44 -0800 (PST)
Received: by 10.227.2.84 with HTTP; Thu, 19 Jan 2012 01:52:44 -0800 (PST)
In-Reply-To: <CANqQZNG17CQEZH1a4E8f25=3RHXEDbW_FnjOsrNSs71Aew1SZw@mail.gmail.com>
References: <CANqQZNFTjKuskMBQKOBud_Jx7_HNqQ0AeLjPO-cOZ8N7vk==HQ@mail.gmail.com>
	<CB3D8F5C.291AF%keir.xen@gmail.com>
	<CANqQZNG17CQEZH1a4E8f25=3RHXEDbW_FnjOsrNSs71Aew1SZw@mail.gmail.com>
Date: Thu, 19 Jan 2012 17:52:44 +0800
Message-ID: <CANqQZNEc=ijFB+_9wtXD1QOUxVY310fD3CLsW-nXKLAktrUh5w@mail.gmail.com>
From: Kai Huang <mail.kai.huang@gmail.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [question] what's the purpose of
	smp_send_event_check_mask?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, Jan 19, 2012 at 5:26 PM, Kai Huang <mail.kai.huang@gmail.com> wrote:
> On Thu, Jan 19, 2012 at 5:14 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>>
>> On 19/01/2012 09:02, "Kai Huang" <mail.kai.huang@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I see cpu_raise_softirq calls smp_send_event_check_mask after setting
>>> softirq bit for target CPU if target CPU is not the current CPU. I
>>> thought smp_send_event_check_mask will send IPI to target CPU and then
>>> trigger target CPU to run pending irq, but seems
>>> smp_send_event_check_mask does nothing but jast ACK the IPI. So what's
>>> the purpose of this function? Why do we need this function?
>>
>> Xen always checks softirqs on return from interrupt context to guest
>> context, and also in its idle loopon wakeup. Hence the event_check inter=
rupt
>> handler itself doesn't need to do anything.
>
> Does this mean if raising softirq for remote CPU, we don't need to
> call do_softirq explicitly on target CPU?
>

I think I understand now after looking at the code. When interrupt
returns, if there's any pending softirqs, the do_softirq will be
called. do_softirq will run handler for all pending bits and
additional call to do_softirq will have no harm as it just do nothing
if no bits are pending.

Thanks.

-cody

> -cody
>
>>
>>> BTW, would someone gives me some knowledge when will the pending irqs
>>> be triggered to run after setting up the pending bits? Seems normally
>>> they are called asynchronously.
>>
>> Yes, of course it's asynchronous, the smp_send_event_check_mask interrup=
t is
>> just to make sure it happens "soon".
>>
>> =A0-- Keir
>>
>>> Thanks in advance!
>>>
>>> -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 Jan 19 10:02:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 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 1Rnool-0004uN-QG; Thu, 19 Jan 2012 10:02:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rnook-0004uI-SP
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:02:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326967316!13036268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13878 invoked from network); 19 Jan 2012 10:01:56 -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;
	19 Jan 2012 10:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10134609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:01:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 10:01:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 10:01:55 +0000
In-Reply-To: <1326482728-10733-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326967315.17599.29.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5/9] libxl: Permit multithreaded event
 waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Previously, the context would be locked whenever we were waiting in
> libxl's own call to poll (waiting for operating system events).
> 
> This would mean that multiple simultaneous calls to libxl_event_wait
> in different threads with different parameters would not work
> properly.
> 
> If we simply unlock the context, it would be possible for another
> thread to discover the occurrence of the event we were waiting for,
> without us even waking up, and we would remain in poll.  So we need a
> way to wake up other threads: a pipe, one for each thread in poll.
> 
> We also need to move some variables from globals in the ctx to be
> per-polling-thread.

I don't think this relates to this patch, just that the mention of
multithreaded waiting brought it to mind. What are the intended
semantics of two calls to libxl_event_wait with overlapping event masks?

Do we expect that the caller must have called the appropriate evenables
twice such that both waits get an event (possibly discriminate via the
predicate)?

Presumably we want to ensure that one of the waits doesn't sleep for
ever.

How does this interact with events generated via the hooks mechanism? Do
we always deliver to the explicit wait in preference?

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |   18 +++-
>  tools/libxl/libxl_event.c    |  196 ++++++++++++++++++++++++++++++++++--------
>  tools/libxl/libxl_internal.h |   50 ++++++++++-
>  3 files changed, 218 insertions(+), 46 deletions(-)
[...]
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 621a7cc..82889f6 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c

> @@ -542,30 +542,39 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
>                  maxfd = efd->fd + 1;
>          }
>          /* make sure our array is as big as *nfds_io */
> -        if (CTX->fd_rindex_allocd < maxfd) {
> +        if (poller->fd_rindex_allocd < maxfd) {
>              assert(maxfd < INT_MAX / sizeof(int) / 2);
> -            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
> +            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
>              if (!newarray) { rc = ERROR_NOMEM; goto out; }
> -            memset(newarray + CTX->fd_rindex_allocd, 0,
> -                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
> -            CTX->fd_rindex = newarray;
> -            CTX->fd_rindex_allocd = maxfd;
> +            memset(newarray + poller->fd_rindex_allocd, 0,
> +                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
> +            poller->fd_rindex = newarray;
> +            poller->fd_rindex_allocd = maxfd;
>          }
>      }
> 
>      int used = 0;
[...]
> +
> +#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
> +        if ((req_events)) {                                     \
> +            if (used < *nfds_io) {                              \
> +                fds[used].fd = (req_fd);                        \
> +                fds[used].events = (req_events);                \
> +                fds[used].revents = 0;                          \
> +                assert((req_fd) < poller->fd_rindex_allocd);    \
> +                poller->fd_rindex[(req_fd)] = used;             \
> +            }                                                   \
> +            used++;                                             \

Used is expected to be in the calling context? IOC -- this is defined
temporarily within a function, the diff context (which I've now trimmed)
confused me.

Does this actually add anything above doing
	LIBXL_LIST_FOREACH(...) {
		/* the body of require_fd */
	}
?

> +        }                                                       \
> +    }while(0)
> +
> +    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
> +        REQUIRE_FD(efd->fd, efd->events, efd);
> +
> +    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
> +
> +#undef REQUIRE_FD
> +
>      rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
> 
>      *nfds_io = used;
[...]
> @@ -630,22 +640,31 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
>      return revents;
>  }
> 
> -static void afterpoll_internal(libxl__egc *egc,
> +static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
>                                 int nfds, const struct pollfd *fds,
>                                 struct timeval now)
>  {
>      EGC_GC;
>      libxl__ev_fd *efd;
> 
> +
>      LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
>          if (!efd->events)
>              continue;
> 
> -        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
> +        int revents = afterpoll_check_fd(poller,fds,nfds, efd->fd,efd->events);
>          if (revents)
>              efd->func(egc, efd, efd->fd, efd->events, revents);
>      }
> 
> +    if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
> +        char buf[256];

Is it (theoretically) possible to have more than 256 events pending?

> +        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
> +        if (r < 0)
> +            if (errno != EINTR && errno != EWOULDBLOCK)
> +                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
> +    }
> +
>      for (;;) {
>          libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
>          if (!etime)
[...]
> @@ -858,7 +880,94 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
>      return rc;
>  }
> 
> -static int eventloop_iteration(libxl__egc *egc) {
> +/*
> + * Manipulation of pollers
> + */
> +
> +int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
> +{
> +    int r, rc;
> +    p->fd_polls = 0;
> +    p->fd_rindex = 0;
> +
> +    r = pipe(p->wakeup_pipe);
> +    if (r) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
> +    if (rc) goto out;
> +
> +    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
> +    if (rc) goto out;
> +
> +    return 0;
> +
> + out:
> +    libxl__poller_dispose(p);

The dispose function checks for fd > 0 before closing but if you take
the first goto out (pipe failed) then wake_pipe[{0,1}] are still
undefined?

> +    return rc;
> +}
> +
> +void libxl__poller_dispose(libxl__poller *p)
> +{
> +    if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
> +    if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);

Strictly speaking 0 is a valid value for an open fd.

I once saw a bug (in gzip iirc) where, because stdin had inadvertently
been closed, a dup() of some sort returned 0 but the subsequent checks
were for >0 rather than >=. Slightly unusual case but it took an age
(for someone else...) to debug.

> +    free(p->fd_polls);
> +    free(p->fd_rindex);
> +}
> +
> +libxl__poller *libxl__poller_get(libxl_ctx *ctx)
> +{
> +    /* must be called with ctx locked */
> +    int rc;
> +
> +    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
> +    if (p)
> +        return p;
> +
> +    p = malloc(sizeof(*p));
> +    if (!p) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
> +        return 0;
> +    }
> +    memset(p, 0, sizeof(*p));

Hrm, I guess this is where p->wakeup_pipe gets initialised. Likewise the
call to _init in ctx_alloc is preceded by a memset. Not entirely obvious
but I guess its ok. (initialising to -1 in _init would solve both this
and the 0-is-a-valid-fd)

> +
> +    rc = libxl__poller_init(ctx, p);
> +    if (rc) return NULL;
> +
> +    return p;
> +}
> +
> +void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
> +{
> +    LIBXL_LIST_INSERT_HEAD(&ctx->pollers_idle, p, entry);
> +}
> +
> +void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
> +{
> +    static const char buf[1] = "";
> +
> +    for (;;) {
> +        int r = write(p->wakeup_pipe[1], buf, 1);
> +        if (r==1) return;
> +        assert(r==-1);

There's no possibility of r == 0 here?

> +        if (errno == EINTR) continue;
> +        if (errno == EWOULDBLOCK) return;

write(2) says that both EWOULDBLOCK and EAGAIN are valid returns for a
non-blocking fd and may have different values so apps should check for
both.

> +        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
> +        return;
> +    }
> +}
> +
> +/*
> + * Main event loop iteration
> + */
> +
> +static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
> +    /* The CTX must be locked EXACTLY ONCE so that this function
> +     * can unlock it when it polls.
> +     */
>      EGC_GC;
>      int rc;
>      struct timeval now;
[...]
> @@ -900,7 +1013,8 @@ static int eventloop_iteration(libxl__egc *egc) {
>      rc = libxl__gettimeofday(gc, &now);
>      if (rc) goto out;
> 
> -    afterpoll_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
> +    afterpoll_internal(egc, poller,
> +                       poller->fd_polls_allocd, poller->fd_polls, now);

Can this function be simplified to take just (egc, poller, now)?
Likewise beforepoll_internal?

> 
>      CTX_UNLOCK;
> 

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index edb73eb..53d2462 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -205,6 +205,33 @@ struct libxl__evgen_disk_eject {
>  _hidden void
>  libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
> 
> +typedef struct libxl__poller libxl__poller;
> +struct libxl__poller {
> +    /*
> +     * These are used to allow other threads to wake up a thread which
> +     * may be stuck in poll, because whatever it was waiting for
> +     * hadn't happened yet.  Threads which generate events will write
> +     * a byte to each pipe.  A thread which is waiting will empty its
> +     * own pipe, and put its poller on the pollers_event list, before
> +     * releasing the ctx lock and going into poll; when it comes out
> +     * of poll it will take the poller off the pollers_event list.
> +     *
> +     * When a thread is done with a poller it should put it onto
> +     * pollers_idle, where it can be reused later.
> +     *
> +     * The "poller_app" is never idle, but is sometimes on
> +     * pollers_event.
> +     */
> +    LIBXL_LIST_ENTRY(libxl__poller) entry;
> +
> +    struct pollfd *fd_polls;
> +    int fd_polls_allocd;
> +
> +    int fd_rindex_allocd;
> +    int *fd_rindex; /* see libxl_osevent_beforepoll */
> +
> +    int wakeup_pipe[2]; /* 0 means no fd allocated */

Or does it ;-)
> +};
> 
>  struct libxl__ctx {
>      xentoollog_logger *lg;
> @@ -235,10 +262,9 @@ struct libxl__ctx {
>        /* 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_rindex_allocd;
> -    int *fd_rindex; /* see libxl_osevent_beforepoll */
> +    libxl__poller poller_app; /* libxl_osevent_beforepoll and _afterpoll */

This presumably means that an app can only use before/afterpoll from one
thread at a time. Hardly an onerous requirement but worth noting
perhaps?

Could also check that pooler_app.entry is not currently on a list?

> +    LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
> +
>      LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
>      LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
> 
> @@ -524,6 +550,22 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
>      libxl__event_disaster(egc, msg, errnoval, type, __FILE__,__LINE__,__func__)
> 
> 
> +/* Fills in, or disposes of, the resources held by, a poller whose

That third comma read weirdly to me.

> + * space the caller has allocated.  ctx must be locked. */

init doesn't appear to do anything which needs a lock?

> +int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
> +void libxl__poller_dispose(libxl__poller *p);
> +
> +/* Obtain a fresh poller from malloc or the idle list, and put it
> + * away again afterwards.  _get can fail, returning NULL.
> + * ctx must be locked. */
> +libxl__poller *libxl__poller_get(libxl_ctx *ctx);
> +void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
> +
> +/* Notifies whoever is polling using p that they should wake up.
> + * ctx must be locked. */
> +void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
> +

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:02:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 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 1Rnool-0004uN-QG; Thu, 19 Jan 2012 10:02:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rnook-0004uI-SP
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:02:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326967316!13036268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13878 invoked from network); 19 Jan 2012 10:01:56 -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;
	19 Jan 2012 10:01:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10134609"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:01:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 10:01:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 10:01:55 +0000
In-Reply-To: <1326482728-10733-6-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-6-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326967315.17599.29.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 5/9] libxl: Permit multithreaded event
 waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Previously, the context would be locked whenever we were waiting in
> libxl's own call to poll (waiting for operating system events).
> 
> This would mean that multiple simultaneous calls to libxl_event_wait
> in different threads with different parameters would not work
> properly.
> 
> If we simply unlock the context, it would be possible for another
> thread to discover the occurrence of the event we were waiting for,
> without us even waking up, and we would remain in poll.  So we need a
> way to wake up other threads: a pipe, one for each thread in poll.
> 
> We also need to move some variables from globals in the ctx to be
> per-polling-thread.

I don't think this relates to this patch, just that the mention of
multithreaded waiting brought it to mind. What are the intended
semantics of two calls to libxl_event_wait with overlapping event masks?

Do we expect that the caller must have called the appropriate evenables
twice such that both waits get an event (possibly discriminate via the
predicate)?

Presumably we want to ensure that one of the waits doesn't sleep for
ever.

How does this interact with events generated via the hooks mechanism? Do
we always deliver to the explicit wait in preference?

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |   18 +++-
>  tools/libxl/libxl_event.c    |  196 ++++++++++++++++++++++++++++++++++--------
>  tools/libxl/libxl_internal.h |   50 ++++++++++-
>  3 files changed, 218 insertions(+), 46 deletions(-)
[...]
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 621a7cc..82889f6 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c

> @@ -542,30 +542,39 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
>                  maxfd = efd->fd + 1;
>          }
>          /* make sure our array is as big as *nfds_io */
> -        if (CTX->fd_rindex_allocd < maxfd) {
> +        if (poller->fd_rindex_allocd < maxfd) {
>              assert(maxfd < INT_MAX / sizeof(int) / 2);
> -            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
> +            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
>              if (!newarray) { rc = ERROR_NOMEM; goto out; }
> -            memset(newarray + CTX->fd_rindex_allocd, 0,
> -                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
> -            CTX->fd_rindex = newarray;
> -            CTX->fd_rindex_allocd = maxfd;
> +            memset(newarray + poller->fd_rindex_allocd, 0,
> +                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
> +            poller->fd_rindex = newarray;
> +            poller->fd_rindex_allocd = maxfd;
>          }
>      }
> 
>      int used = 0;
[...]
> +
> +#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
> +        if ((req_events)) {                                     \
> +            if (used < *nfds_io) {                              \
> +                fds[used].fd = (req_fd);                        \
> +                fds[used].events = (req_events);                \
> +                fds[used].revents = 0;                          \
> +                assert((req_fd) < poller->fd_rindex_allocd);    \
> +                poller->fd_rindex[(req_fd)] = used;             \
> +            }                                                   \
> +            used++;                                             \

Used is expected to be in the calling context? IOC -- this is defined
temporarily within a function, the diff context (which I've now trimmed)
confused me.

Does this actually add anything above doing
	LIBXL_LIST_FOREACH(...) {
		/* the body of require_fd */
	}
?

> +        }                                                       \
> +    }while(0)
> +
> +    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
> +        REQUIRE_FD(efd->fd, efd->events, efd);
> +
> +    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
> +
> +#undef REQUIRE_FD
> +
>      rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
> 
>      *nfds_io = used;
[...]
> @@ -630,22 +640,31 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
>      return revents;
>  }
> 
> -static void afterpoll_internal(libxl__egc *egc,
> +static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
>                                 int nfds, const struct pollfd *fds,
>                                 struct timeval now)
>  {
>      EGC_GC;
>      libxl__ev_fd *efd;
> 
> +
>      LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
>          if (!efd->events)
>              continue;
> 
> -        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
> +        int revents = afterpoll_check_fd(poller,fds,nfds, efd->fd,efd->events);
>          if (revents)
>              efd->func(egc, efd, efd->fd, efd->events, revents);
>      }
> 
> +    if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
> +        char buf[256];

Is it (theoretically) possible to have more than 256 events pending?

> +        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
> +        if (r < 0)
> +            if (errno != EINTR && errno != EWOULDBLOCK)
> +                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
> +    }
> +
>      for (;;) {
>          libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
>          if (!etime)
[...]
> @@ -858,7 +880,94 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
>      return rc;
>  }
> 
> -static int eventloop_iteration(libxl__egc *egc) {
> +/*
> + * Manipulation of pollers
> + */
> +
> +int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
> +{
> +    int r, rc;
> +    p->fd_polls = 0;
> +    p->fd_rindex = 0;
> +
> +    r = pipe(p->wakeup_pipe);
> +    if (r) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
> +        rc = ERROR_FAIL;
> +        goto out;
> +    }
> +
> +    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
> +    if (rc) goto out;
> +
> +    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
> +    if (rc) goto out;
> +
> +    return 0;
> +
> + out:
> +    libxl__poller_dispose(p);

The dispose function checks for fd > 0 before closing but if you take
the first goto out (pipe failed) then wake_pipe[{0,1}] are still
undefined?

> +    return rc;
> +}
> +
> +void libxl__poller_dispose(libxl__poller *p)
> +{
> +    if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
> +    if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);

Strictly speaking 0 is a valid value for an open fd.

I once saw a bug (in gzip iirc) where, because stdin had inadvertently
been closed, a dup() of some sort returned 0 but the subsequent checks
were for >0 rather than >=. Slightly unusual case but it took an age
(for someone else...) to debug.

> +    free(p->fd_polls);
> +    free(p->fd_rindex);
> +}
> +
> +libxl__poller *libxl__poller_get(libxl_ctx *ctx)
> +{
> +    /* must be called with ctx locked */
> +    int rc;
> +
> +    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
> +    if (p)
> +        return p;
> +
> +    p = malloc(sizeof(*p));
> +    if (!p) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
> +        return 0;
> +    }
> +    memset(p, 0, sizeof(*p));

Hrm, I guess this is where p->wakeup_pipe gets initialised. Likewise the
call to _init in ctx_alloc is preceded by a memset. Not entirely obvious
but I guess its ok. (initialising to -1 in _init would solve both this
and the 0-is-a-valid-fd)

> +
> +    rc = libxl__poller_init(ctx, p);
> +    if (rc) return NULL;
> +
> +    return p;
> +}
> +
> +void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
> +{
> +    LIBXL_LIST_INSERT_HEAD(&ctx->pollers_idle, p, entry);
> +}
> +
> +void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
> +{
> +    static const char buf[1] = "";
> +
> +    for (;;) {
> +        int r = write(p->wakeup_pipe[1], buf, 1);
> +        if (r==1) return;
> +        assert(r==-1);

There's no possibility of r == 0 here?

> +        if (errno == EINTR) continue;
> +        if (errno == EWOULDBLOCK) return;

write(2) says that both EWOULDBLOCK and EAGAIN are valid returns for a
non-blocking fd and may have different values so apps should check for
both.

> +        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
> +        return;
> +    }
> +}
> +
> +/*
> + * Main event loop iteration
> + */
> +
> +static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
> +    /* The CTX must be locked EXACTLY ONCE so that this function
> +     * can unlock it when it polls.
> +     */
>      EGC_GC;
>      int rc;
>      struct timeval now;
[...]
> @@ -900,7 +1013,8 @@ static int eventloop_iteration(libxl__egc *egc) {
>      rc = libxl__gettimeofday(gc, &now);
>      if (rc) goto out;
> 
> -    afterpoll_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
> +    afterpoll_internal(egc, poller,
> +                       poller->fd_polls_allocd, poller->fd_polls, now);

Can this function be simplified to take just (egc, poller, now)?
Likewise beforepoll_internal?

> 
>      CTX_UNLOCK;
> 

> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index edb73eb..53d2462 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -205,6 +205,33 @@ struct libxl__evgen_disk_eject {
>  _hidden void
>  libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
> 
> +typedef struct libxl__poller libxl__poller;
> +struct libxl__poller {
> +    /*
> +     * These are used to allow other threads to wake up a thread which
> +     * may be stuck in poll, because whatever it was waiting for
> +     * hadn't happened yet.  Threads which generate events will write
> +     * a byte to each pipe.  A thread which is waiting will empty its
> +     * own pipe, and put its poller on the pollers_event list, before
> +     * releasing the ctx lock and going into poll; when it comes out
> +     * of poll it will take the poller off the pollers_event list.
> +     *
> +     * When a thread is done with a poller it should put it onto
> +     * pollers_idle, where it can be reused later.
> +     *
> +     * The "poller_app" is never idle, but is sometimes on
> +     * pollers_event.
> +     */
> +    LIBXL_LIST_ENTRY(libxl__poller) entry;
> +
> +    struct pollfd *fd_polls;
> +    int fd_polls_allocd;
> +
> +    int fd_rindex_allocd;
> +    int *fd_rindex; /* see libxl_osevent_beforepoll */
> +
> +    int wakeup_pipe[2]; /* 0 means no fd allocated */

Or does it ;-)
> +};
> 
>  struct libxl__ctx {
>      xentoollog_logger *lg;
> @@ -235,10 +262,9 @@ struct libxl__ctx {
>        /* 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_rindex_allocd;
> -    int *fd_rindex; /* see libxl_osevent_beforepoll */
> +    libxl__poller poller_app; /* libxl_osevent_beforepoll and _afterpoll */

This presumably means that an app can only use before/afterpoll from one
thread at a time. Hardly an onerous requirement but worth noting
perhaps?

Could also check that pooler_app.entry is not currently on a list?

> +    LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
> +
>      LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
>      LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
> 
> @@ -524,6 +550,22 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
>      libxl__event_disaster(egc, msg, errnoval, type, __FILE__,__LINE__,__func__)
> 
> 
> +/* Fills in, or disposes of, the resources held by, a poller whose

That third comma read weirdly to me.

> + * space the caller has allocated.  ctx must be locked. */

init doesn't appear to do anything which needs a lock?

> +int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
> +void libxl__poller_dispose(libxl__poller *p);
> +
> +/* Obtain a fresh poller from malloc or the idle list, and put it
> + * away again afterwards.  _get can fail, returning NULL.
> + * ctx must be locked. */
> +libxl__poller *libxl__poller_get(libxl_ctx *ctx);
> +void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
> +
> +/* Notifies whoever is polling using p that they should wake up.
> + * ctx must be locked. */
> +void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
> +

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:11:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnoxa-00056Z-S4; Thu, 19 Jan 2012 10:11:10 +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 1RnoxZ-00056U-HD
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:11:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326967861!11523279!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 26339 invoked from network); 19 Jan 2012 10:11:03 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:11:03 -0000
Received: by pbcc6 with SMTP id c6so37198966pbc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:11: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=0Lz09QU19J8xpWoUwTcnEGpfr7mi8yK5UQcA3PrpM/I=;
	b=d2MV1tvEbUzIA6sW5LpUXnCBQ/o0Z9c3m1RepgWrUgr+WNJVO5mCEJDmLXrlY/qdBe
	vMH524NqZMoSNlzjyU3Lbw0bG43QpCKo2F3iQHSZiqNwL5/IMnsM9AFL/5bnG9Kd02fH
	kZl83xgDAKuBf3FeQebeDXoSnoO/UjziPC/SU=
MIME-Version: 1.0
Received: by 10.68.120.72 with SMTP id la8mr51663040pbb.56.1326967861132; Thu,
	19 Jan 2012 02:11:01 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Thu, 19 Jan 2012 02:11:01 -0800 (PST)
In-Reply-To: <20120118180123.GA7169@aepfle.de>
References: <20120118162122.GA14232@aepfle.de>
	<CAPLaKK7aEG6jR-ABNo0jHsqK+56K0=1Nm_fsi7T-JW+HEa7wTA@mail.gmail.com>
	<20120118180123.GA7169@aepfle.de>
Date: Thu, 19 Jan 2012 11:11:01 +0100
X-Google-Sender-Auth: FYrkEpfOAeKT-4OmkbfOVtdwldI
Message-ID: <CAPLaKK6-jLiRfekYHpQCNUoXaU-fdjA2toHudnLr58uLzvqO0g@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
Subject: Re: [Xen-devel] ioctl handling in netbsd_privcmd_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE4IE9sYWYgSGVyaW5nIDxvbGFmQGFlcGZsZS5kZT46Cj4gT24gV2VkLCBKYW4gMTgs
IFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4KPj4gMjAxMi8xLzE4IE9sYWYgSGVyaW5nIDxvbGFm
QGFlcGZsZS5kZT46Cj4+ID4KPj4gPiBJIHdhcyBsb29raW5nIGF0IHRoZSBzbGlnaHRseSBicm9r
ZW4gZXJyb3IgaGFuZGxpbmcgaW4gdGhlIG5ldwo+PiA+IHhjX21lbV9wYWdpbmdfbG9hZCgpIGZ1
bmN0aW9uIGFuZCBzdHVtYmxlZCBvdmVyIHRoZSBpb2N0bCgpIGhhbmRsaW5nIGluCj4+ID4gbmV0
YnNkX3ByaXZjbWRfaHlwZXJjYWxsKCkuCj4+ID4KPj4gPiBJcyBpb2N0bCgpIG9uIE5ldEJTRCBz
cGVjaWFsPyBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgaXQgcmV0dXJucyAtMSBvbgo+PiA+IGVycm9y
IGFuZCB0aGUgY2FsbGVyIGNhbiBkZWFsIHdpdGggZXJybm8gaWYgaXQgYWN0dWFsbHkgd2FudHMg
dG8uCj4+ID4gQnV0IGluc3RlYWQgaXQgcmV0dXJucyB0aGUgbmVnYXRpdmUgZXJybm8gdmFsdWUg
b3Igd2hhdCB0aGUgaHlwZXJ2aXNvcgo+PiA+IHJldHVybmVkLgo+Pgo+PiBJIGhhdmVuJ3QgZG9u
ZSB0aGlzIGNvZGUsIHNvIEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBhcmUgc29tZSBoaWRkZW4KPj4g
c3VidGxldGllcyBoZXJlLCBidXQgYWNjb3JkaW5nIHRvIE5ldEJTRCBpb2N0bCgyKSBtYW4gcGFn
ZVswXSwgaXQKPj4gcmV0dXJucyAtMSBvbiBlcnJvciBhbmQgZXJybm8gaXMgc2V0IHRvIGluZGlj
YXRlIHRoZSBlcnJvci4KPgo+IENvdWxkIHlvdSBjaGVjayB3ZXRoZXIgYSAicmV0dXJuIGlvY3Rs
KC4uLi4pOyIgd29ya3MgYXMgd2VsbD8KCkkndmUgY2hlY2tlZCBpdCwgYW5kIHJlYWxpemVkIHdo
eSBOZXRCU0QgbmVlZHMgdG8gcmV0dXJuCmh5cGVyY2FsbC0+cmV0dmFsLCB0aGF0J3MgYmVjYXVz
ZSBMaW51eCBpb2N0bHMgcmV0dXJuIDwgMCBvbiBlcnJvciwKYW5kID49IDAgb24gc3VjY2VzcyAo
eW91IGNhbiByZXR1cm4gYSBtZWFuaW5nZnVsIHZhbHVlIGZyb20gaW9jdGxbMF0pLApidXQgTmV0
QlNEIGlvY3RscyBvbmx5IHJldHVybiA8IDAgb24gZXJyb3IsIG9yIDAgb24gc3VjY2Vzcy4gSSd2
ZQpzcG90dGVkIHRoYXQgbWVtb3J5IG9wZXJhdGlvbnMgcmV0dXJuIHRoZSBzaXplIG9mIHRoZSBt
ZW1vcnkgcmVnaW9uIG9uCnN1Y2Nlc3MsIHRoYXQncyB3aHkgTmV0QlNEIG5lZWRzIHRvIHJldHVy
biBoeXBlcmNhbGwtPnJldHZhbC4gV2hhdCBJCmRvbid0IGtub3cgaWYgd2h5IGl0IHJldHVybnMg
LWVycm5vIG9uIGVycm9yLCBpdCBzaG91bGQgcmV0dXJuIHRoZQpyZXR1cm4gdmFsdWUgb2YgdGhl
IGlvY3RsIGNhbGwgKGVycm9yIHZhcmlhYmxlKS4gSSB3aWxsIHN1Ym1pdCBhIHBhdGNoCmFkZGlu
ZyBhIGNvbW1lbnQgdG8gbmV0YnNkX3ByaXZjbWRfaHlwZXJjYWxsIGFuZCBhbm90aGVyIG9uZSB0
byByZXR1cm4KZXJyb3IgaW5zdGVhZCBvZiAtZXJybm8uCgpbMF0gaHR0cDovL2xpbnV4LmRpZS5u
ZXQvbWFuLzIvaW9jdGwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:11:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnoxa-00056Z-S4; Thu, 19 Jan 2012 10:11:10 +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 1RnoxZ-00056U-HD
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:11:09 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1326967861!11523279!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 26339 invoked from network); 19 Jan 2012 10:11:03 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:11:03 -0000
Received: by pbcc6 with SMTP id c6so37198966pbc.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:11: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=0Lz09QU19J8xpWoUwTcnEGpfr7mi8yK5UQcA3PrpM/I=;
	b=d2MV1tvEbUzIA6sW5LpUXnCBQ/o0Z9c3m1RepgWrUgr+WNJVO5mCEJDmLXrlY/qdBe
	vMH524NqZMoSNlzjyU3Lbw0bG43QpCKo2F3iQHSZiqNwL5/IMnsM9AFL/5bnG9Kd02fH
	kZl83xgDAKuBf3FeQebeDXoSnoO/UjziPC/SU=
MIME-Version: 1.0
Received: by 10.68.120.72 with SMTP id la8mr51663040pbb.56.1326967861132; Thu,
	19 Jan 2012 02:11:01 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Thu, 19 Jan 2012 02:11:01 -0800 (PST)
In-Reply-To: <20120118180123.GA7169@aepfle.de>
References: <20120118162122.GA14232@aepfle.de>
	<CAPLaKK7aEG6jR-ABNo0jHsqK+56K0=1Nm_fsi7T-JW+HEa7wTA@mail.gmail.com>
	<20120118180123.GA7169@aepfle.de>
Date: Thu, 19 Jan 2012 11:11:01 +0100
X-Google-Sender-Auth: FYrkEpfOAeKT-4OmkbfOVtdwldI
Message-ID: <CAPLaKK6-jLiRfekYHpQCNUoXaU-fdjA2toHudnLr58uLzvqO0g@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
Subject: Re: [Xen-devel] ioctl handling in netbsd_privcmd_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="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE4IE9sYWYgSGVyaW5nIDxvbGFmQGFlcGZsZS5kZT46Cj4gT24gV2VkLCBKYW4gMTgs
IFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4KPj4gMjAxMi8xLzE4IE9sYWYgSGVyaW5nIDxvbGFm
QGFlcGZsZS5kZT46Cj4+ID4KPj4gPiBJIHdhcyBsb29raW5nIGF0IHRoZSBzbGlnaHRseSBicm9r
ZW4gZXJyb3IgaGFuZGxpbmcgaW4gdGhlIG5ldwo+PiA+IHhjX21lbV9wYWdpbmdfbG9hZCgpIGZ1
bmN0aW9uIGFuZCBzdHVtYmxlZCBvdmVyIHRoZSBpb2N0bCgpIGhhbmRsaW5nIGluCj4+ID4gbmV0
YnNkX3ByaXZjbWRfaHlwZXJjYWxsKCkuCj4+ID4KPj4gPiBJcyBpb2N0bCgpIG9uIE5ldEJTRCBz
cGVjaWFsPyBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQgaXQgcmV0dXJucyAtMSBvbgo+PiA+IGVycm9y
IGFuZCB0aGUgY2FsbGVyIGNhbiBkZWFsIHdpdGggZXJybm8gaWYgaXQgYWN0dWFsbHkgd2FudHMg
dG8uCj4+ID4gQnV0IGluc3RlYWQgaXQgcmV0dXJucyB0aGUgbmVnYXRpdmUgZXJybm8gdmFsdWUg
b3Igd2hhdCB0aGUgaHlwZXJ2aXNvcgo+PiA+IHJldHVybmVkLgo+Pgo+PiBJIGhhdmVuJ3QgZG9u
ZSB0aGlzIGNvZGUsIHNvIEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBhcmUgc29tZSBoaWRkZW4KPj4g
c3VidGxldGllcyBoZXJlLCBidXQgYWNjb3JkaW5nIHRvIE5ldEJTRCBpb2N0bCgyKSBtYW4gcGFn
ZVswXSwgaXQKPj4gcmV0dXJucyAtMSBvbiBlcnJvciBhbmQgZXJybm8gaXMgc2V0IHRvIGluZGlj
YXRlIHRoZSBlcnJvci4KPgo+IENvdWxkIHlvdSBjaGVjayB3ZXRoZXIgYSAicmV0dXJuIGlvY3Rs
KC4uLi4pOyIgd29ya3MgYXMgd2VsbD8KCkkndmUgY2hlY2tlZCBpdCwgYW5kIHJlYWxpemVkIHdo
eSBOZXRCU0QgbmVlZHMgdG8gcmV0dXJuCmh5cGVyY2FsbC0+cmV0dmFsLCB0aGF0J3MgYmVjYXVz
ZSBMaW51eCBpb2N0bHMgcmV0dXJuIDwgMCBvbiBlcnJvciwKYW5kID49IDAgb24gc3VjY2VzcyAo
eW91IGNhbiByZXR1cm4gYSBtZWFuaW5nZnVsIHZhbHVlIGZyb20gaW9jdGxbMF0pLApidXQgTmV0
QlNEIGlvY3RscyBvbmx5IHJldHVybiA8IDAgb24gZXJyb3IsIG9yIDAgb24gc3VjY2Vzcy4gSSd2
ZQpzcG90dGVkIHRoYXQgbWVtb3J5IG9wZXJhdGlvbnMgcmV0dXJuIHRoZSBzaXplIG9mIHRoZSBt
ZW1vcnkgcmVnaW9uIG9uCnN1Y2Nlc3MsIHRoYXQncyB3aHkgTmV0QlNEIG5lZWRzIHRvIHJldHVy
biBoeXBlcmNhbGwtPnJldHZhbC4gV2hhdCBJCmRvbid0IGtub3cgaWYgd2h5IGl0IHJldHVybnMg
LWVycm5vIG9uIGVycm9yLCBpdCBzaG91bGQgcmV0dXJuIHRoZQpyZXR1cm4gdmFsdWUgb2YgdGhl
IGlvY3RsIGNhbGwgKGVycm9yIHZhcmlhYmxlKS4gSSB3aWxsIHN1Ym1pdCBhIHBhdGNoCmFkZGlu
ZyBhIGNvbW1lbnQgdG8gbmV0YnNkX3ByaXZjbWRfaHlwZXJjYWxsIGFuZCBhbm90aGVyIG9uZSB0
byByZXR1cm4KZXJyb3IgaW5zdGVhZCBvZiAtZXJybm8uCgpbMF0gaHR0cDovL2xpbnV4LmRpZS5u
ZXQvbWFuLzIvaW9jdGwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:25:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpAu-0005aD-7X; Thu, 19 Jan 2012 10:24:56 +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 1RnpAs-0005a7-KI
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:24:54 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326968688!11528040!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 12084 invoked from network); 19 Jan 2012 10:24:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:24:48 -0000
Received: by werh12 with SMTP id h12so7072195wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:24:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=4VqkV0BQ5ht9mrJm5dI0fRH5QSRCDcQU7MnhhcIInpU=;
	b=rzb6DBx/EBFHSagKI3Mb+fXzvV1xX9DaMk62YXIX0wIrN9qf49+grYIdynJwI7X1uB
	STMhgLk/xu2K871Nho29DUWTDRCkF9LFQ6+7K6zdYMKyPMkDqXptFCRmsUw2NVEP+O5A
	qvrLT+rWSdJ/SQB/SumS6bBPgI6nb66J37UuY=
Received: by 10.216.133.204 with SMTP id q54mr236551wei.2.1326968687899;
	Thu, 19 Jan 2012 02:24:47 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d9sm27244436wiy.2.2012.01.19.02.24.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 02:24:46 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326968579@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 19 Jan 2012 11:22:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] cosmetic fix to libxc 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

Just a cosmetic fix to NetBSD libxc hypercall and a comment explaining 
why we return hypercall->retval instead of the output from ioctl.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:25:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:25:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpAu-0005aD-7X; Thu, 19 Jan 2012 10:24:56 +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 1RnpAs-0005a7-KI
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:24:54 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326968688!11528040!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 12084 invoked from network); 19 Jan 2012 10:24:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:24:48 -0000
Received: by werh12 with SMTP id h12so7072195wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:24:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:message-id:user-agent:date:from:to;
	bh=4VqkV0BQ5ht9mrJm5dI0fRH5QSRCDcQU7MnhhcIInpU=;
	b=rzb6DBx/EBFHSagKI3Mb+fXzvV1xX9DaMk62YXIX0wIrN9qf49+grYIdynJwI7X1uB
	STMhgLk/xu2K871Nho29DUWTDRCkF9LFQ6+7K6zdYMKyPMkDqXptFCRmsUw2NVEP+O5A
	qvrLT+rWSdJ/SQB/SumS6bBPgI6nb66J37UuY=
Received: by 10.216.133.204 with SMTP id q54mr236551wei.2.1326968687899;
	Thu, 19 Jan 2012 02:24:47 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d9sm27244436wiy.2.2012.01.19.02.24.45
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 02:24:46 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1326968579@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 19 Jan 2012 11:22:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 2] cosmetic fix to libxc 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

Just a cosmetic fix to NetBSD libxc hypercall and a comment explaining 
why we return hypercall->retval instead of the output from ioctl.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:25:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpAv-0005ab-QC; Thu, 19 Jan 2012 10:24: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 1RnpAu-0005a8-76
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:24:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326968689!9811440!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 6766 invoked from network); 19 Jan 2012 10:24:50 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:24:50 -0000
Received: by wibhj8 with SMTP id hj8so17534543wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:24:49 -0800 (PST)
DKIM-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=pRbzHZTDAJZkYJneQKBvztKRH9sYi/eWs81CkK/3uZI=;
	b=kiOcYPIIuiIi8atdb6+AV1/Qv/QK0KMT8N/Pp2QSds9fMi0NDWScGxBqj8F8g3LdPq
	jc2uRQVkEHvlNTsCH2DmagOqki9pL0J0OWYC/IsvUvbft98vfKq5MW+5L/ztELJcSOqh
	Gx4KZEXxF+ZhoKCwaVfMEUVHpo3KGyMH+poXI=
Received: by 10.180.77.35 with SMTP id p3mr42787517wiw.11.1326968689765;
	Thu, 19 Jan 2012 02:24:49 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d9sm27244436wiy.2.2012.01.19.02.24.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 02:24:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d7d91b1eb79edf93230713d80ac6ac7738bdd71e
Message-Id: <d7d91b1eb79edf932307.1326968580@loki.upc.es>
In-Reply-To: <patchbomb.1326968579@loki.upc.es>
References: <patchbomb.1326968579@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 19 Jan 2012 11:23:00 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] libxc/NetBSD: return ioctl return value
	on 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326968255 -3600
# Node ID d7d91b1eb79edf93230713d80ac6ac7738bdd71e
# Parent  f14765a3013a27f9e3948ee97fbdb798b057db04
libxc/NetBSD: return ioctl return value on error

NetBSD libxc hypercall implementation was returning -errno on error,
instead of the actual error value from ioctl. Returning error is
easier to understand, and the caller can always check errno.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f14765a3013a -r d7d91b1eb79e tools/libxc/xc_netbsd.c
--- a/tools/libxc/xc_netbsd.c	Mon Jan 16 16:55:37 2012 +0100
+++ b/tools/libxc/xc_netbsd.c	Thu Jan 19 11:17:35 2012 +0100
@@ -97,7 +97,7 @@ static int netbsd_privcmd_hypercall(xc_i
     int error = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
 
     if (error < 0)
-        return -errno;
+        return error;
     else
         return hypercall->retval;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:25:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:25:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpAv-0005ab-QC; Thu, 19 Jan 2012 10:24: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 1RnpAu-0005a8-76
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:24:56 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1326968689!9811440!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 6766 invoked from network); 19 Jan 2012 10:24:50 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:24:50 -0000
Received: by wibhj8 with SMTP id hj8so17534543wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:24:49 -0800 (PST)
DKIM-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=pRbzHZTDAJZkYJneQKBvztKRH9sYi/eWs81CkK/3uZI=;
	b=kiOcYPIIuiIi8atdb6+AV1/Qv/QK0KMT8N/Pp2QSds9fMi0NDWScGxBqj8F8g3LdPq
	jc2uRQVkEHvlNTsCH2DmagOqki9pL0J0OWYC/IsvUvbft98vfKq5MW+5L/ztELJcSOqh
	Gx4KZEXxF+ZhoKCwaVfMEUVHpo3KGyMH+poXI=
Received: by 10.180.77.35 with SMTP id p3mr42787517wiw.11.1326968689765;
	Thu, 19 Jan 2012 02:24:49 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d9sm27244436wiy.2.2012.01.19.02.24.47
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 02:24:48 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d7d91b1eb79edf93230713d80ac6ac7738bdd71e
Message-Id: <d7d91b1eb79edf932307.1326968580@loki.upc.es>
In-Reply-To: <patchbomb.1326968579@loki.upc.es>
References: <patchbomb.1326968579@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 19 Jan 2012 11:23:00 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 2] libxc/NetBSD: return ioctl return value
	on 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

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1326968255 -3600
# Node ID d7d91b1eb79edf93230713d80ac6ac7738bdd71e
# Parent  f14765a3013a27f9e3948ee97fbdb798b057db04
libxc/NetBSD: return ioctl return value on error

NetBSD libxc hypercall implementation was returning -errno on error,
instead of the actual error value from ioctl. Returning error is
easier to understand, and the caller can always check errno.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f14765a3013a -r d7d91b1eb79e tools/libxc/xc_netbsd.c
--- a/tools/libxc/xc_netbsd.c	Mon Jan 16 16:55:37 2012 +0100
+++ b/tools/libxc/xc_netbsd.c	Thu Jan 19 11:17:35 2012 +0100
@@ -97,7 +97,7 @@ static int netbsd_privcmd_hypercall(xc_i
     int error = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
 
     if (error < 0)
-        return -errno;
+        return error;
     else
         return hypercall->retval;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:25:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10: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 1RnpB2-0005bZ-7E; Thu, 19 Jan 2012 10:25:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RnpAz-0005aI-Ru
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:25:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326968691!7822878!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 19758 invoked from network); 19 Jan 2012 10:24:52 -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;
	19 Jan 2012 10:24:52 -0000
Received: by wgbdr11 with SMTP id dr11so4520539wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:24:51 -0800 (PST)
DKIM-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=nozH5Vz9iNrfo1db0CKAF84rRNitVzPYuxaMz9WHRo0=;
	b=TRLJihijKj94u0osAjpYgshAeXqDoix7GUMNz7PRcF5LLhP32CTB24wOexUyUd6dVA
	dedVKJVeD2ruFtT0GPB2aFbt5+a9s4P9VZro1UQMaU4yEkRWRtGF0de3kuZw68GL8yRg
	dBMwe5tLpNeUWu6j+YDsgCKPoo2ew159JVpg8=
Received: by 10.180.97.37 with SMTP id dx5mr5684021wib.3.1326968691595;
	Thu, 19 Jan 2012 02:24:51 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d9sm27244436wiy.2.2012.01.19.02.24.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 02:24:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 484fb928e36c3150ed66cf102087565ded2769fd
Message-Id: <484fb928e36c3150ed66.1326968581@loki.upc.es>
In-Reply-To: <patchbomb.1326968579@loki.upc.es>
References: <patchbomb.1326968579@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 19 Jan 2012 11:23:01 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] libxc: add comment to why NetBSD return
 hypercall->retval
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326968470 -3600
# Node ID 484fb928e36c3150ed66cf102087565ded2769fd
# Parent  d7d91b1eb79edf93230713d80ac6ac7738bdd71e
libxc: add comment to why NetBSD return hypercall->retval

Added a comment that explains why NetBSD return hypercall->retval on
success.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d7d91b1eb79e -r 484fb928e36c tools/libxc/xc_netbsd.c
--- a/tools/libxc/xc_netbsd.c	Thu Jan 19 11:17:35 2012 +0100
+++ b/tools/libxc/xc_netbsd.c	Thu Jan 19 11:21:10 2012 +0100
@@ -96,6 +96,12 @@ static int netbsd_privcmd_hypercall(xc_i
     int fd = (int)h;
     int error = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
 
+    /*
+     * Since NetBSD ioctl can only return 0 on success or < 0 on
+     * error, if we want to return a value from ioctl we should
+     * do so by setting hypercall->retval, to mimic Linux ioctl
+     * implementation.
+     */
     if (error < 0)
         return error;
     else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:25:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10: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 1RnpB2-0005bZ-7E; Thu, 19 Jan 2012 10:25:04 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RnpAz-0005aI-Ru
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:25:02 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326968691!7822878!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 19758 invoked from network); 19 Jan 2012 10:24:52 -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;
	19 Jan 2012 10:24:52 -0000
Received: by wgbdr11 with SMTP id dr11so4520539wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:24:51 -0800 (PST)
DKIM-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=nozH5Vz9iNrfo1db0CKAF84rRNitVzPYuxaMz9WHRo0=;
	b=TRLJihijKj94u0osAjpYgshAeXqDoix7GUMNz7PRcF5LLhP32CTB24wOexUyUd6dVA
	dedVKJVeD2ruFtT0GPB2aFbt5+a9s4P9VZro1UQMaU4yEkRWRtGF0de3kuZw68GL8yRg
	dBMwe5tLpNeUWu6j+YDsgCKPoo2ew159JVpg8=
Received: by 10.180.97.37 with SMTP id dx5mr5684021wib.3.1326968691595;
	Thu, 19 Jan 2012 02:24:51 -0800 (PST)
Received: from loki.upc.es (queen.upc.es. [147.83.39.247])
	by mx.google.com with ESMTPS id d9sm27244436wiy.2.2012.01.19.02.24.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 02:24:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 484fb928e36c3150ed66cf102087565ded2769fd
Message-Id: <484fb928e36c3150ed66.1326968581@loki.upc.es>
In-Reply-To: <patchbomb.1326968579@loki.upc.es>
References: <patchbomb.1326968579@loki.upc.es>
User-Agent: Mercurial-patchbomb/1.9.2
Date: Thu, 19 Jan 2012 11:23:01 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 2] libxc: add comment to why NetBSD return
 hypercall->retval
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1326968470 -3600
# Node ID 484fb928e36c3150ed66cf102087565ded2769fd
# Parent  d7d91b1eb79edf93230713d80ac6ac7738bdd71e
libxc: add comment to why NetBSD return hypercall->retval

Added a comment that explains why NetBSD return hypercall->retval on
success.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r d7d91b1eb79e -r 484fb928e36c tools/libxc/xc_netbsd.c
--- a/tools/libxc/xc_netbsd.c	Thu Jan 19 11:17:35 2012 +0100
+++ b/tools/libxc/xc_netbsd.c	Thu Jan 19 11:21:10 2012 +0100
@@ -96,6 +96,12 @@ static int netbsd_privcmd_hypercall(xc_i
     int fd = (int)h;
     int error = ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
 
+    /*
+     * Since NetBSD ioctl can only return 0 on success or < 0 on
+     * error, if we want to return a value from ioctl we should
+     * do so by setting hypercall->retval, to mimic Linux ioctl
+     * implementation.
+     */
     if (error < 0)
         return error;
     else

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpDZ-0005tj-Rq; Thu, 19 Jan 2012 10:27:41 +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 1RnpDY-0005tD-9k
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:27:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326968852!11528608!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 28018 invoked from network); 19 Jan 2012 10:27:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:27:34 -0000
Received: by dadp15 with SMTP id p15so30862023dad.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:27: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=4FGpTypuPdz6vHNychPW3X6iimf85cMuGGtOTrnVaAs=;
	b=JSZbkt0hNOM9E37biduOTtU/QeizDZEWT0n0FH/kFN6MsZGrJjuMFt2xAPIZNkW/7W
	/m20uYe4IT/Vu+qvgrhh8zqkPaOejQ+HjNFOVVwXoVozo2MoZp9kwd3+maNVy0MnBxOf
	CWU4GXF9Mk++BcAemVRNe+Pr2wed8YsMTLJPM=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr51597136pbu.124.1326968851870; Thu,
	19 Jan 2012 02:27:31 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Thu, 19 Jan 2012 02:27:31 -0800 (PST)
In-Reply-To: <patchbomb.1326968579@loki.upc.es>
References: <patchbomb.1326968579@loki.upc.es>
Date: Thu, 19 Jan 2012 11:27:31 +0100
X-Google-Sender-Auth: qkIwmvS9uox8FKnQlB46TwLQids
Message-ID: <CAPLaKK4WWNEJwBz4mWkGt4n+3OO+tnoNsXEHqRrCA5LwuXRsNg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] [PATCH 0 of 2] cosmetic fix to libxc 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

I've forgot to add the Reported-by:... stuff, sorry, could someone add:

Reported-by: "Olaf Hering" <olaf@aepfle.de>

to both patches if they are to be committed to the repository?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpDZ-0005tj-Rq; Thu, 19 Jan 2012 10:27:41 +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 1RnpDY-0005tD-9k
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:27:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326968852!11528608!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 28018 invoked from network); 19 Jan 2012 10:27:34 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:27:34 -0000
Received: by dadp15 with SMTP id p15so30862023dad.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 02:27: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=4FGpTypuPdz6vHNychPW3X6iimf85cMuGGtOTrnVaAs=;
	b=JSZbkt0hNOM9E37biduOTtU/QeizDZEWT0n0FH/kFN6MsZGrJjuMFt2xAPIZNkW/7W
	/m20uYe4IT/Vu+qvgrhh8zqkPaOejQ+HjNFOVVwXoVozo2MoZp9kwd3+maNVy0MnBxOf
	CWU4GXF9Mk++BcAemVRNe+Pr2wed8YsMTLJPM=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr51597136pbu.124.1326968851870; Thu,
	19 Jan 2012 02:27:31 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Thu, 19 Jan 2012 02:27:31 -0800 (PST)
In-Reply-To: <patchbomb.1326968579@loki.upc.es>
References: <patchbomb.1326968579@loki.upc.es>
Date: Thu, 19 Jan 2012 11:27:31 +0100
X-Google-Sender-Auth: qkIwmvS9uox8FKnQlB46TwLQids
Message-ID: <CAPLaKK4WWNEJwBz4mWkGt4n+3OO+tnoNsXEHqRrCA5LwuXRsNg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: Olaf Hering <olaf@aepfle.de>
Subject: Re: [Xen-devel] [PATCH 0 of 2] cosmetic fix to libxc 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

I've forgot to add the Reported-by:... stuff, sorry, could someone add:

Reported-by: "Olaf Hering" <olaf@aepfle.de>

to both patches if they are to be committed to the repository?

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:33:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpIT-0006CK-Jg; Thu, 19 Jan 2012 10:32:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnpIS-0006CE-GT
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:32:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326969111!53203257!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16898 invoked from network); 19 Jan 2012 10:31:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:31:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10135638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:32:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 10:32:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 19 Jan 2012 10:32:28 +0000
In-Reply-To: <4F17187B.2050102@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1326882968.14689.176.camel@zakaz.uk.xensource.com>
	<4F16DD96.6080304@tycho.nsa.gov>
	<1326902794.14689.243.camel@zakaz.uk.xensource.com>
	<4F17187B.2050102@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326969148.17599.41.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 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On Wed, 2012-01-18 at 19:07 +0000, Daniel De Graaf wrote:
> On 01/18/2012 11:06 AM, Ian Campbell wrote:
> > On Wed, 2012-01-18 at 14:56 +0000, Daniel De Graaf wrote:
> >> On 01/18/2012 05:36 AM, Ian Campbell wrote:
> >>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> >>>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >>>>
> >>>> This patch reinstates the XENMEM_remove_from_physmap hypercall
> >>>> which was removed in 19041:ee62aaafff46 because it was not used.
> >>>>
> >>>> However, is now needed in order to support xenstored stub domains.
> >>>> The xenstored stub domain is not priviliged like dom0 and so cannot
> >>>> unilaterally map the xenbus page of other guests into it's address
> >>>> space.  Therefore, before creating a domU the domain builder needs to
> >>>> seed its grant table with a grant ref allowing the xenstored stub
> >>>> domain to access the new domU's xenbus page.
> >>>>
> >>>> At present domU's do not start with their grant table mapped.
> >>>> Instead it gets mapped when the guest requests a grant table from
> >>>> the hypervisor.
> >>>>
> >>>> In order to seed the grant table, the domain builder first needs to
> >>>> map it into dom0 address space.  But the hypercall to do this
> >>>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
> >>>> for HVM guests.  Therfore, in order to seed the grant table of an
> >>>> HVM guest, dom0 needs to *temporarily* map it into the guest's
> >>>> "physical" address space.
> >>>>
> >>>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
> >>>>
> >>>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>>
> >>> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
> >>> about ordering in xlat.lst)
> >>>
> >>> BTW, since Alex and Diego have subsequently left Citrix you could take
> >>> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
> >>> no idea if that's necessary though, I expect not.
> >>>
> >>> Ian.
> >>>
> >>
> >> I'm not an expert in this area,
> > 
> > Me neither.
> > 
> >> but this is how I read it: the portion of
> >> the path authored by Alex/Diego was already signed-off when they were posted,
> >> so since the current patches are derived works from them the sign-off may
> >> need to stay in order to allow me to sign off because I cannot claim copyright
> >> on all of the content. Assuming Citrix actually owns the copyright on the
> >> patches, your Ack may suffice to replace the sign-off for this purpose.
> > 
> > I don't think an Ack conveys the same meaning (WRT the DCO) as a
> > Signed-off-by.
> > 
> >> I guess my real question here would be: should the sign-off from Alex and
> >> Diego remain on these patches in addition to your Ack?
> > 
> > I would suggest you keep any signed-off-by they provided and augment it
> > with my ack. 
> > 
> > I think I saw one or two which said "Originally-by" instead of
> > "Signed-of-by", I guess those were either missing a Signed-off-by in the
> > first place or have been heavily modified?
> > 
> > Ian.
> > 
> 
> I originally replaced all the signed-off-by lines with originally-by and
> missed one when converting back. When looking at the Linux version of the
> DCO, it implies (lower down when talking about subsystem maintainers) that
> if I make changes I need to drop the sign-off and claim clause (b) unless
> the original author is around to sign-off on the changed patch, or if it is
> trivial and I note this above my sign-off (not applicable here). This makes
> me lean toward changing back to "Originally-by" or similar tags. I did keep
> the From tags for those patches that I did not mostly rewrite, which I assume
> will be recognized when importing patches.

The DCO itself isn't terribly specific about what to do with an existing
Signed-off-by if you modify the patch. Common practice appears to be to
include both the original and your own and to note what you have changed
unless you have done a wholesale rewrite in which case it is
"Based-on"/"Originally-by"/etc + your own S-o-b.

Ian.


> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:33:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:33:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpIT-0006CK-Jg; Thu, 19 Jan 2012 10:32:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnpIS-0006CE-GT
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:32:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326969111!53203257!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16898 invoked from network); 19 Jan 2012 10:31:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:31:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10135638"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:32:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 10:32:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Thu, 19 Jan 2012 10:32:28 +0000
In-Reply-To: <4F17187B.2050102@tycho.nsa.gov>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-2-git-send-email-dgdegra@tycho.nsa.gov>
	<1326882968.14689.176.camel@zakaz.uk.xensource.com>
	<4F16DD96.6080304@tycho.nsa.gov>
	<1326902794.14689.243.camel@zakaz.uk.xensource.com>
	<4F17187B.2050102@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326969148.17599.41.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 01/18] xen: reinstate previously unused
 XENMEM_remove_from_physmap 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

On Wed, 2012-01-18 at 19:07 +0000, Daniel De Graaf wrote:
> On 01/18/2012 11:06 AM, Ian Campbell wrote:
> > On Wed, 2012-01-18 at 14:56 +0000, Daniel De Graaf wrote:
> >> On 01/18/2012 05:36 AM, Ian Campbell wrote:
> >>> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
> >>>> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >>>>
> >>>> This patch reinstates the XENMEM_remove_from_physmap hypercall
> >>>> which was removed in 19041:ee62aaafff46 because it was not used.
> >>>>
> >>>> However, is now needed in order to support xenstored stub domains.
> >>>> The xenstored stub domain is not priviliged like dom0 and so cannot
> >>>> unilaterally map the xenbus page of other guests into it's address
> >>>> space.  Therefore, before creating a domU the domain builder needs to
> >>>> seed its grant table with a grant ref allowing the xenstored stub
> >>>> domain to access the new domU's xenbus page.
> >>>>
> >>>> At present domU's do not start with their grant table mapped.
> >>>> Instead it gets mapped when the guest requests a grant table from
> >>>> the hypervisor.
> >>>>
> >>>> In order to seed the grant table, the domain builder first needs to
> >>>> map it into dom0 address space.  But the hypercall to do this
> >>>> requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
> >>>> for HVM guests.  Therfore, in order to seed the grant table of an
> >>>> HVM guest, dom0 needs to *temporarily* map it into the guest's
> >>>> "physical" address space.
> >>>>
> >>>> Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.
> >>>>
> >>>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> >>>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >>>
> >>> Acked-by: Ian Campbell <ian.campbell@citrix.com> (modulo Jan's comment
> >>> about ordering in xlat.lst)
> >>>
> >>> BTW, since Alex and Diego have subsequently left Citrix you could take
> >>> my Acked-by's in this series as Signed-of-by on behalf of Citrix. I've
> >>> no idea if that's necessary though, I expect not.
> >>>
> >>> Ian.
> >>>
> >>
> >> I'm not an expert in this area,
> > 
> > Me neither.
> > 
> >> but this is how I read it: the portion of
> >> the path authored by Alex/Diego was already signed-off when they were posted,
> >> so since the current patches are derived works from them the sign-off may
> >> need to stay in order to allow me to sign off because I cannot claim copyright
> >> on all of the content. Assuming Citrix actually owns the copyright on the
> >> patches, your Ack may suffice to replace the sign-off for this purpose.
> > 
> > I don't think an Ack conveys the same meaning (WRT the DCO) as a
> > Signed-off-by.
> > 
> >> I guess my real question here would be: should the sign-off from Alex and
> >> Diego remain on these patches in addition to your Ack?
> > 
> > I would suggest you keep any signed-off-by they provided and augment it
> > with my ack. 
> > 
> > I think I saw one or two which said "Originally-by" instead of
> > "Signed-of-by", I guess those were either missing a Signed-off-by in the
> > first place or have been heavily modified?
> > 
> > Ian.
> > 
> 
> I originally replaced all the signed-off-by lines with originally-by and
> missed one when converting back. When looking at the Linux version of the
> DCO, it implies (lower down when talking about subsystem maintainers) that
> if I make changes I need to drop the sign-off and claim clause (b) unless
> the original author is around to sign-off on the changed patch, or if it is
> trivial and I note this above my sign-off (not applicable here). This makes
> me lean toward changing back to "Originally-by" or similar tags. I did keep
> the From tags for those patches that I did not mostly rewrite, which I assume
> will be recognized when importing patches.

The DCO itself isn't terribly specific about what to do with an existing
Signed-off-by if you modify the patch. Common practice appears to be to
include both the original and your own and to note what you have changed
unless you have done a wholesale rewrite in which case it is
"Based-on"/"Originally-by"/etc + your own S-o-b.

Ian.


> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:39:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpOk-0006Mv-Kj; Thu, 19 Jan 2012 10:39:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Tim.Deegan@citrix.com>) id 1RnpOj-0006Mn-HZ
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:39:13 +0000
X-Env-Sender: Tim.Deegan@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326969545!9629555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7507 invoked from network); 19 Jan 2012 10:39:06 -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;
	19 Jan 2012 10:39:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10135944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:39:04 +0000
Received: from whitby.uk.xensource.com (10.80.2.60) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 10:39:04 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <Tim.Deegan@citrix.com>)	id 1RnpOZ-0000FL-K4;
	Thu, 19 Jan 2012 10:39:03 +0000
Date: Thu, 19 Jan 2012 10:39:03 +0000
From: Tim Deegan <Tim.Deegan@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119103903.GA1378@whitby.uk.xensource.com>
References: <28c68de1ea253d7dbe34.1326728344@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <28c68de1ea253d7dbe34.1326728344@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	andres@gridcentric.ca, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 10:39 -0500 on 16 Jan (1326710344), Andres Lagar-Cavilla wrote:
> This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
> and our work.
> 
> It combines logic changes to simplify the memory event API, as well as
> leveraging wait queues to deal with extreme conditions in which too many events are
> generated by a guest vcpu.
> 
> In order to generate a new event, a slot in the ring is claimed. If a guest vcpu
> is generating the event and there is no space, it is put on a wait queue. If a
> foreign vcpu is generating the event and there is no space, the vcpu is expected
> to retry its operation. If an error happens later, the function returns the
> claimed slot via a cancel operation.
> 
> Thus, the API has only four calls: claim slot, cancel claimed slot, put request
> in the ring, consume the response.
> 
> With all these mechanisms, no guest events are lost.
> Our testing includes 1. ballooning down 512 MiBs; 2. using mem access n2rwx, 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.

Applied, thanks.  I made two changes, both suggested by Olaf: 
 - moved the lock init up in mem_event_enable(); and
 - reverted p2m_mem_paging_populate() to return void, as none of the 
   callers had been changed to care about its new return value. 

In general, the callers of p2m_mem_paging_populate() are still a bit of
a mess; that should all be happening behind the p2m interface.  But
that's for another time...

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:39:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:39:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpOk-0006Mv-Kj; Thu, 19 Jan 2012 10:39:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Tim.Deegan@citrix.com>) id 1RnpOj-0006Mn-HZ
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:39:13 +0000
X-Env-Sender: Tim.Deegan@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326969545!9629555!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7507 invoked from network); 19 Jan 2012 10:39:06 -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;
	19 Jan 2012 10:39:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10135944"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:39:04 +0000
Received: from whitby.uk.xensource.com (10.80.2.60) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 10:39:04 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <Tim.Deegan@citrix.com>)	id 1RnpOZ-0000FL-K4;
	Thu, 19 Jan 2012 10:39:03 +0000
Date: Thu, 19 Jan 2012 10:39:03 +0000
From: Tim Deegan <Tim.Deegan@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119103903.GA1378@whitby.uk.xensource.com>
References: <28c68de1ea253d7dbe34.1326728344@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <28c68de1ea253d7dbe34.1326728344@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, tim@xen.org,
	andres@gridcentric.ca, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] x86/mm: 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 10:39 -0500 on 16 Jan (1326710344), Andres Lagar-Cavilla wrote:
> This patch is an amalgamation of the work done by Olaf Hering <olaf@aepfle.de>
> and our work.
> 
> It combines logic changes to simplify the memory event API, as well as
> leveraging wait queues to deal with extreme conditions in which too many events are
> generated by a guest vcpu.
> 
> In order to generate a new event, a slot in the ring is claimed. If a guest vcpu
> is generating the event and there is no space, it is put on a wait queue. If a
> foreign vcpu is generating the event and there is no space, the vcpu is expected
> to retry its operation. If an error happens later, the function returns the
> claimed slot via a cancel operation.
> 
> Thus, the API has only four calls: claim slot, cancel claimed slot, put request
> in the ring, consume the response.
> 
> With all these mechanisms, no guest events are lost.
> Our testing includes 1. ballooning down 512 MiBs; 2. using mem access n2rwx, 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.

Applied, thanks.  I made two changes, both suggested by Olaf: 
 - moved the lock init up in mem_event_enable(); and
 - reverted p2m_mem_paging_populate() to return void, as none of the 
   callers had been changed to care about its new return value. 

In general, the callers of p2m_mem_paging_populate() are still a bit of
a mess; that should all be happening behind the p2m interface.  But
that's for another time...

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:44:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpTi-0006WE-Ea; Thu, 19 Jan 2012 10:44:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Tim.Deegan@citrix.com>) id 1RnpTg-0006VY-8e
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:44:20 +0000
X-Env-Sender: Tim.Deegan@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326969854!11701366!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16668 invoked from network); 19 Jan 2012 10:44:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:44:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10136103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:44:13 +0000
Received: from whitby.uk.xensource.com (10.80.2.60) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 10:44:13 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <Tim.Deegan@citrix.com>)	id 1RnpTY-0005Oa-T7;
	Thu, 19 Jan 2012 10:44:12 +0000
Date: Thu, 19 Jan 2012 10:44:12 +0000
From: Tim Deegan <Tim.Deegan@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119104412.GB1378@whitby.uk.xensource.com>
References: <patchbomb.1326432817@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1326432817@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Two p2m 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 00:33 -0500 on 13 Jan (1326414817), Andres Lagar-Cavilla wrote:
> - An assert for an invalid mfn was being triggered in 
>   guest_physmap_add_entry, even though the target gfn was paged out.
> 
> - Fix how gfn's are put when mapping grants.

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 Jan 19 10:44:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:44:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpTi-0006WE-Ea; Thu, 19 Jan 2012 10:44:22 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Tim.Deegan@citrix.com>) id 1RnpTg-0006VY-8e
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:44:20 +0000
X-Env-Sender: Tim.Deegan@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1326969854!11701366!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16668 invoked from network); 19 Jan 2012 10:44:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:44:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10136103"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:44:13 +0000
Received: from whitby.uk.xensource.com (10.80.2.60) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 10:44:13 +0000
Received: from tdeegan by whitby.uk.xensource.com with local (Exim 4.76)
	(envelope-from <Tim.Deegan@citrix.com>)	id 1RnpTY-0005Oa-T7;
	Thu, 19 Jan 2012 10:44:12 +0000
Date: Thu, 19 Jan 2012 10:44:12 +0000
From: Tim Deegan <Tim.Deegan@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119104412.GB1378@whitby.uk.xensource.com>
References: <patchbomb.1326432817@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1326432817@xdev.gridcentric.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 2] Two p2m 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 00:33 -0500 on 13 Jan (1326414817), Andres Lagar-Cavilla wrote:
> - An assert for an invalid mfn was being triggered in 
>   guest_physmap_add_entry, even though the target gfn was paged out.
> 
> - Fix how gfn's are put when mapping grants.

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 Jan 19 10:45:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpU6-0006Xx-Tz; Thu, 19 Jan 2012 10:44:46 +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 1RnpU4-0006XC-QX
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:44:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326969876!4206061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9315 invoked from network); 19 Jan 2012 10:44:37 -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;
	19 Jan 2012 10:44:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10136112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:44: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, 19 Jan 2012 10:44:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 10:44:35 +0000
In-Reply-To: <1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326969875.17599.50.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 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Provide a new set of machinery for writing public libxl functions
> which may take a long time.  The application gets to decide whether
> they want the function to be synchronous, or whether they'd prefer to
> get a callback, or an event, when the operation is complete.
> 
> User(s) of this machinery will be introduced in later patch(es).

You've done device removal, do you have a list of other things which
should use this? (perhaps with an associated list of people's names...)

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.h          |   50 ++++++++++++
>  tools/libxl/libxl_event.c    |  183 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |  112 ++++++++++++++++++++++++++
>  tools/libxl/libxl_types.idl  |    4 +
>  4 files changed, 349 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index e32881b..416d6e8 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -235,8 +235,58 @@ enum {
>      ERROR_NOT_READY = -11,
>      ERROR_OSEVENT_REG_FAIL = -12,
>      ERROR_BUFFERFULL = -13,
> +    ERROR_ASYNC_INPROGRESS = -14,
>  };
> 
> +
> +/*
> + * Some libxl operations can take a long time.  These functions take a
> + * parameter to control their concurrency:
> + *     libxl_asyncop_how *ao_how
> + *
> + * If ao_how==NULL, the function will be synchronous.
> + *
> + * If ao_how!=NULL, the function will set the operation going, and
> + * if this is successful will return ERROR_ASYNCH_INPROGRESS.

There's an extra H here compared with the actual symbol name (I think
the symbol is right).

Is there a possibility that libxl might decide that the operation isn't
actually going to take all the long and do things synchronously,
returning normal success (e.g. 0)? Is that the reason for the separate
return code for this "I did what you asked me" case?

Can we drop the ERROR_ prefix? I know that's inconsistent with the other
return codes but those actually are errors.

> + *
> + * If ao_how->callback!=NULL, the callback will be called when the
> + * operation completes.  The same rules as for libxl_event_hooks
> + * apply, including the reentrancy rules and the possibility of

           ^ (see above/below) -- depending on how these comments end up
relative to each other.

> + * "disaster", except that libxl calls ao_how->callback instead of
> + * libxl_event_hooks.event_occurs.
> + *
> + * If ao_how->callback==NULL, a libxl_event will be generated which
> + * can be obtained from libxl_event_wait or libxl_event_check.

Or be delivered via event_occurs?

>   The
> + * event will have type OPERATION_COMPLETE (which is not used
> + * elsewhere).
> + *
> + * Note that it is possible for an asynchronous operation which is to
> + * result in a callback to complete during its initiating function
> + * call.  In this case the initating function will return

                              initiating

> + * ERROR_ASYNCH_INPROGRESS, even though by the time it returns the

Another stray H.

> + * operation is complete and the callback has already happened.
> + *
> + * The application must set and use ao_how->for_event (which will be
> + * copied into libxl_event.for_user) or ao_how->for_callback (passed
> + * to the callback) to determine which operation finished, and it must
> + * of course check the rc value for errors.
> + *
> + * *ao_how does not need to remain valid after the initiating function
> + * returns.
> + *
> + * Callbacks may occur on any thread in which the application calls
> + * libxl.
> + */
> +
> +typedef struct {
> +    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
> +    union {
> +        libxl_ev_user for_event; /* used if callback==NULL */
> +        void *for_callback; /* passed to callback */

Why void * for one bit of "closure" but an explicit uint64_t for the
other. I nearly commented on the use of uint64_t previously -- void *,
or perhaps (u)intptr_t is more normal.

> +    } u;
> +} libxl_asyncop_how;
> +
> +
>  #define LIBXL_VERSION 0
> 
>  typedef struct {
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 82889f6..b99049a 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -771,10 +771,21 @@ static void egc_run_callbacks(libxl__egc *egc)
>  {
>      EGC_GC;
>      libxl_event *ev, *ev_tmp;
> +
>      LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
>          LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
>          CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
>      }
> +
> +    libxl__ao *ao, *ao_tmp;
> +    LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
> +                             entry_for_callback, ao_tmp) {
> +        LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
> +        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
> +        ao->notified = 1;
> +        if (!ao->in_initiator)
> +            libxl__ao__destroy(CTX, ao);
> +    }
>  }
> 
>  void libxl__egc_cleanup(libxl__egc *egc)
> @@ -1061,6 +1072,178 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
>      return rc;
>  }
> 
> +
> +
> +/*
> + * The two possible state flow of an ao:
> + *
> + * Completion before initiator return:
> + *
> + *     Initiator thread                       Possible other threads
> + *
> + *   * ao_create allocates memory and
> + *     initialises the struct
> + *
> + *   * the initiator function does its
> + *     work, setting up various internal
> + *     asynchronous operations -----------> * asynchronous operations
> + *                                            start to take place and
> + *                                            might cause ao completion
> + *                                                |
> + *   * initiator calls ao_complete:               |
> + *     - if synchronous, run event loop           |
> + *       until the ao completes                   |
> + *                              - ao completes on some thread
> + *                              - completing thread releases the lock
> + *                     <--------------'
> + *     - ao_complete takes the lock
> + *     - destroy the ao
> + *
> + *
> + * Completion after initiator return (asynch. only):
> + *
> + *
> + *     Initiator thread                       Possible other threads
> + *
> + *   * ao_create allocates memory and
> + *     initialises the struct
> + *
> + *   * the initiator function does its
> + *     work, setting up various internal
> + *     asynchronous operations -----------> * asynchronous operations
> + *                                            start to take place and
> + *                                            might cause ao completion
> + *                                                |
> + *   * initiator calls ao_complete:               |
> + *     - observes event not net done,             |
> + *     - returns to caller                        |
> + *                                                |
> + *                              - ao completes on some thread
> + *                              - generate the event or call the callback
> + *                              - destroy the ao

Where does ao_inprogress fit into these diagrams?

> + */
> +
> +void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao) {

CODING_STYLE wants these braces on the next line (a bunch more follow)

> +    if (!ao) return;
> +    if (ao->poller) libxl__poller_put(ctx, ao->poller);
> +    ao->magic = LIBXL__AO_MAGIC_DESTROYED;
> +    libxl__free_all(&ao->gc);
> +    free(ao);
> +}
> +
> +void libxl__ao_abort(libxl__ao *ao) {
> +    AO_GC;
> +    assert(ao->magic == LIBXL__AO_MAGIC);
> +    assert(ao->in_initiator);
> +    assert(!ao->complete);
> +    libxl__ao__destroy(CTX, ao);
> +}
> +
> +void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
> +    assert(ao->magic == LIBXL__AO_MAGIC);
> +    assert(!ao->complete);
> +    ao->complete = 1;
> +    ao->rc = rc;
> +
> +    if (ao->poller) {
> +        assert(ao->in_initiator);
> +        libxl__poller_wakeup(egc, ao->poller);
> +    } else if (ao->how.callback) {
> +        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
> +    } else {
> +        libxl_event *ev;
> +        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
> +        if (ev) {
> +            ev->for_user = ao->how.u.for_event;
> +            ev->u.operation_complete.rc = ao->rc;
> +            libxl__event_occurred(egc, ev);
> +        }
> +        ao->notified = 1;
> +    }
> +    if (!ao->in_initiator && ao->notified)
> +        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);

You added a helper for this libxl__gc_owner(&egc..) construct.

> +}
> +
> +libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
> +                            const libxl_asyncop_how *how) {
> +    libxl__ao *ao;
> +
> +    ao = calloc(sizeof(*ao),1);

calloc is actually (nmemb, size). I'm sure it doesn't really matter
though.


> +    if (!ao) goto out;
> +
> +    ao->magic = LIBXL__AO_MAGIC;
> +    ao->in_initiator = 1;
> +    ao->poller = 0;
> +    ao->domid = domid;
> +    LIBXL_INIT_GC(ao->gc, ctx);
> +
> +    if (how) {
> +        ao->how = *how;
> +    } else {
> +        ao->poller = libxl__poller_get(ctx);
> +        if (!ao->poller) goto out;
> +    }
> +    return ao;
> +
> + out:
> +    if (ao) libxl__ao__destroy(ctx, ao);
> +    return NULL;
> +}
> +
> +int libxl__ao_inprogress(libxl__ao *ao) {
> +    AO_GC;
> +    int rc;
> +
> +    assert(ao->magic == LIBXL__AO_MAGIC);
> +    assert(ao->in_initiator);
> +
> +    if (ao->poller) {
> +        /* Caller wants it done synchronously. */
> +        /* We use a fresh gc, so that we can free things
> +         * each time round the loop. */
> +        libxl__egc egc;
> +        LIBXL_INIT_EGC(egc,CTX);
> +
> +        for (;;) {
> +            assert(ao->magic == LIBXL__AO_MAGIC);
> +
> +            if (ao->complete) {
> +                rc = ao->rc;
> +                ao->notified = 1;
> +                break;
> +            }
> +
> +            rc = eventloop_iteration(&egc,ao->poller);
> +            if (rc) {
> +                /* Oh dear, this is quite unfortunate. */
> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
> +                           " event during long-running operation (rc=%d)", rc);
> +                sleep(1);
> +                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
> +                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
> +                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
> +                 * cancellation ability. */

Does this constitute a "disaster" (in the special hook sense)?

> +            }
> +
> +            CTX_UNLOCK;
> +            libxl__egc_cleanup(&egc);
> +            CTX_LOCK;
> +        }
> +    } else {
> +        rc = ERROR_ASYNC_INPROGRESS;
> +    }
> +
> +    ao->in_initiator = 0;
> +
> +    if (ao->notified) {
> +        assert(ao->complete);
> +        libxl__ao__destroy(CTX,ao);
> +    }
> +
> +    return rc;
> +}
> +
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 53d2462..594b9fb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
[...]
> @@ -1123,6 +1144,97 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
> 
> 
>  /*
> + * Machinery for asynchronous operations ("ao")
> + *
> + * All "slow" functions (includes anything that might block on a
> + * guest or an external script) need to use the asynchronous
> + * operation ("ao") machinery.  The function should take a parameter
> + * const libxl_asyncop_how *ao_how and must start with a call to
> + * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
> + * outside libxl, because they can cause reentrancy callbacks.
> + *
> + * No functions called internally within libxl should ever return
> + * ERROR_ASYNCH_INPROGRESS.

Aitch.

> + *
> + * Lifecycle of an ao:
> + *
> + * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
> + *
> + * - After creation, can be used by code which implements
> + *   the operation as follows:
> + *      - the ao's gc, for allocating memory for the lifetime
> + *        of the operation (possibly with the help of the AO_GC
> + *        macro to introduce the gc into scope)
> + *      - the ao itself may be passed about to sub-functions
> + *        so that they can stash it away etc.
> + *      - in particular, the ao pointer must be stashed in some
> + *        per-operation structure which is also passed as a user
> + *        pointer to the internal event generation request routines
> + *        libxl__evgen_FOO, so that at some point a CALLBACK will be
> + *        made when the operation is complete.
> + *
> + * - If initiation is successful, the initiating function needs
> + *   to run libxl__ao_inprogress right before unlocking and
> + *   returning, and return whatever it returns (AO_INPROGRESS macro).
> + *
> + * - If the initiation is unsuccessful, the initiating function must
> + *   call libxl__ao_abort before unlocking and returning whatever
> + *   error code is appropriate (AO_ABORT macro).
> + *
> + * - Later, some callback function, whose callback has been requested
> + *   directly or indirectly, should call libxl__ao_complete (with the
> + *   ctx locked, as it will generally already be in any event callback
> + *   function).  This must happen exactly once for each ao (and not if
> + *   the ao has been destroyed, obviously), and it may not happen
> + *   until libxl__ao_inprogress has been called on the ao.
> + *
> + * - Note that during callback functions, two gcs are available:
> + *    - The one in egc, whose lifetime is only this callback
> + *    - The one in ao, whose lifetime is the asynchronous operation
> + *   Usually callback function should use GET_CONTAINING_STRUCT

Now called CONTAINER_OF

> + *   to obtain its own structure, containing a pointer to the ao,
> + *   and then use the gc from that ao.
> + */
> +
> +#define AO_CREATE(ctx, domid, ao_how)                           \
> +    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
> +    if (!ao) return ERROR_NOMEM;                                \
> +    AO_GC;                                                      \
> +    CTX_LOCK;

Where does the unlock which balances this come from? The only unlock I
see in this patch is the temporary drop in libxl__ao_inprogress which is
matched by another lock.

> +
> +#define AO_INPROGRESS do{                                       \
> +        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> +        int ao__rc = libxl__ao_inprogress(ao);                  \
> +        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \

Is this supposed to be unlock answering my question above? Likewise in
ABORT?

> +        return ao__rc;                                          \
> +   }while(0)

Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
would become
	return AO_INPROGRESS;

Is the ({stuff,stuff,stuff,val}) syntax a gcc-ism?

> +
> +
> +#define AO_ABORT(rc) do{                                        \
> +        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> +        assert(rc);                                             \
> +        assert(rc != ERROR_ASYNC_INPROGRESS);                   \
> +        libxl__ao_abort(ao);                                    \
> +        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
> +        return (rc);                                            \
> +    }while(0)
> +
> +#define AO_GC                                   \
> +    libxl__gc *const gc = &ao->gc
> +
> +
> +/* All of these MUST be called with the ctx locked.

Except libxl__ao_create? at least according to the implementation of
AO_CREATE which takes the lock after.

> + * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
> +_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
> +                                    const libxl_asyncop_how*);
> +_hidden int libxl__ao_inprogress(libxl__ao *ao);
> +_hidden void libxl__ao_abort(libxl__ao *ao);
> +_hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
> +
> +/* For use by ao machinery ONLY */
> +_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
> +
> +/*
>   * Convenience macros.
>   */
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index a6dac79..325bb21 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -395,6 +395,7 @@ libxl_event_type = Enumeration("event_type", [
>      (1, "DOMAIN_SHUTDOWN"),
>      (2, "DOMAIN_DESTROY"),
>      (3, "DISK_EJECT"),
> +    (4, "OPERATION_COMPLETE"),
>      ])
> 
>  libxl_ev_user = UInt(64)
> @@ -418,4 +419,7 @@ libxl_event = Struct("event",[
>                                          ("vdev", string),
>                                          ("disk", libxl_device_disk),
>                                   ])),
> +           ("operation_complete", Struct(None, [
> +                                        ("rc", integer),
> +                                 ])),
>             ]))])
> --
> 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 Jan 19 10:45:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:45:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpU6-0006Xx-Tz; Thu, 19 Jan 2012 10:44:46 +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 1RnpU4-0006XC-QX
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:44:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326969876!4206061!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9315 invoked from network); 19 Jan 2012 10:44:37 -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;
	19 Jan 2012 10:44:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10136112"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:44: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, 19 Jan 2012 10:44:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 10:44:35 +0000
In-Reply-To: <1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326969875.17599.50.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 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Provide a new set of machinery for writing public libxl functions
> which may take a long time.  The application gets to decide whether
> they want the function to be synchronous, or whether they'd prefer to
> get a callback, or an event, when the operation is complete.
> 
> User(s) of this machinery will be introduced in later patch(es).

You've done device removal, do you have a list of other things which
should use this? (perhaps with an associated list of people's names...)

> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.h          |   50 ++++++++++++
>  tools/libxl/libxl_event.c    |  183 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |  112 ++++++++++++++++++++++++++
>  tools/libxl/libxl_types.idl  |    4 +
>  4 files changed, 349 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index e32881b..416d6e8 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -235,8 +235,58 @@ enum {
>      ERROR_NOT_READY = -11,
>      ERROR_OSEVENT_REG_FAIL = -12,
>      ERROR_BUFFERFULL = -13,
> +    ERROR_ASYNC_INPROGRESS = -14,
>  };
> 
> +
> +/*
> + * Some libxl operations can take a long time.  These functions take a
> + * parameter to control their concurrency:
> + *     libxl_asyncop_how *ao_how
> + *
> + * If ao_how==NULL, the function will be synchronous.
> + *
> + * If ao_how!=NULL, the function will set the operation going, and
> + * if this is successful will return ERROR_ASYNCH_INPROGRESS.

There's an extra H here compared with the actual symbol name (I think
the symbol is right).

Is there a possibility that libxl might decide that the operation isn't
actually going to take all the long and do things synchronously,
returning normal success (e.g. 0)? Is that the reason for the separate
return code for this "I did what you asked me" case?

Can we drop the ERROR_ prefix? I know that's inconsistent with the other
return codes but those actually are errors.

> + *
> + * If ao_how->callback!=NULL, the callback will be called when the
> + * operation completes.  The same rules as for libxl_event_hooks
> + * apply, including the reentrancy rules and the possibility of

           ^ (see above/below) -- depending on how these comments end up
relative to each other.

> + * "disaster", except that libxl calls ao_how->callback instead of
> + * libxl_event_hooks.event_occurs.
> + *
> + * If ao_how->callback==NULL, a libxl_event will be generated which
> + * can be obtained from libxl_event_wait or libxl_event_check.

Or be delivered via event_occurs?

>   The
> + * event will have type OPERATION_COMPLETE (which is not used
> + * elsewhere).
> + *
> + * Note that it is possible for an asynchronous operation which is to
> + * result in a callback to complete during its initiating function
> + * call.  In this case the initating function will return

                              initiating

> + * ERROR_ASYNCH_INPROGRESS, even though by the time it returns the

Another stray H.

> + * operation is complete and the callback has already happened.
> + *
> + * The application must set and use ao_how->for_event (which will be
> + * copied into libxl_event.for_user) or ao_how->for_callback (passed
> + * to the callback) to determine which operation finished, and it must
> + * of course check the rc value for errors.
> + *
> + * *ao_how does not need to remain valid after the initiating function
> + * returns.
> + *
> + * Callbacks may occur on any thread in which the application calls
> + * libxl.
> + */
> +
> +typedef struct {
> +    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
> +    union {
> +        libxl_ev_user for_event; /* used if callback==NULL */
> +        void *for_callback; /* passed to callback */

Why void * for one bit of "closure" but an explicit uint64_t for the
other. I nearly commented on the use of uint64_t previously -- void *,
or perhaps (u)intptr_t is more normal.

> +    } u;
> +} libxl_asyncop_how;
> +
> +
>  #define LIBXL_VERSION 0
> 
>  typedef struct {
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index 82889f6..b99049a 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -771,10 +771,21 @@ static void egc_run_callbacks(libxl__egc *egc)
>  {
>      EGC_GC;
>      libxl_event *ev, *ev_tmp;
> +
>      LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
>          LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
>          CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
>      }
> +
> +    libxl__ao *ao, *ao_tmp;
> +    LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
> +                             entry_for_callback, ao_tmp) {
> +        LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
> +        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
> +        ao->notified = 1;
> +        if (!ao->in_initiator)
> +            libxl__ao__destroy(CTX, ao);
> +    }
>  }
> 
>  void libxl__egc_cleanup(libxl__egc *egc)
> @@ -1061,6 +1072,178 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
>      return rc;
>  }
> 
> +
> +
> +/*
> + * The two possible state flow of an ao:
> + *
> + * Completion before initiator return:
> + *
> + *     Initiator thread                       Possible other threads
> + *
> + *   * ao_create allocates memory and
> + *     initialises the struct
> + *
> + *   * the initiator function does its
> + *     work, setting up various internal
> + *     asynchronous operations -----------> * asynchronous operations
> + *                                            start to take place and
> + *                                            might cause ao completion
> + *                                                |
> + *   * initiator calls ao_complete:               |
> + *     - if synchronous, run event loop           |
> + *       until the ao completes                   |
> + *                              - ao completes on some thread
> + *                              - completing thread releases the lock
> + *                     <--------------'
> + *     - ao_complete takes the lock
> + *     - destroy the ao
> + *
> + *
> + * Completion after initiator return (asynch. only):
> + *
> + *
> + *     Initiator thread                       Possible other threads
> + *
> + *   * ao_create allocates memory and
> + *     initialises the struct
> + *
> + *   * the initiator function does its
> + *     work, setting up various internal
> + *     asynchronous operations -----------> * asynchronous operations
> + *                                            start to take place and
> + *                                            might cause ao completion
> + *                                                |
> + *   * initiator calls ao_complete:               |
> + *     - observes event not net done,             |
> + *     - returns to caller                        |
> + *                                                |
> + *                              - ao completes on some thread
> + *                              - generate the event or call the callback
> + *                              - destroy the ao

Where does ao_inprogress fit into these diagrams?

> + */
> +
> +void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao) {

CODING_STYLE wants these braces on the next line (a bunch more follow)

> +    if (!ao) return;
> +    if (ao->poller) libxl__poller_put(ctx, ao->poller);
> +    ao->magic = LIBXL__AO_MAGIC_DESTROYED;
> +    libxl__free_all(&ao->gc);
> +    free(ao);
> +}
> +
> +void libxl__ao_abort(libxl__ao *ao) {
> +    AO_GC;
> +    assert(ao->magic == LIBXL__AO_MAGIC);
> +    assert(ao->in_initiator);
> +    assert(!ao->complete);
> +    libxl__ao__destroy(CTX, ao);
> +}
> +
> +void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
> +    assert(ao->magic == LIBXL__AO_MAGIC);
> +    assert(!ao->complete);
> +    ao->complete = 1;
> +    ao->rc = rc;
> +
> +    if (ao->poller) {
> +        assert(ao->in_initiator);
> +        libxl__poller_wakeup(egc, ao->poller);
> +    } else if (ao->how.callback) {
> +        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
> +    } else {
> +        libxl_event *ev;
> +        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
> +        if (ev) {
> +            ev->for_user = ao->how.u.for_event;
> +            ev->u.operation_complete.rc = ao->rc;
> +            libxl__event_occurred(egc, ev);
> +        }
> +        ao->notified = 1;
> +    }
> +    if (!ao->in_initiator && ao->notified)
> +        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);

You added a helper for this libxl__gc_owner(&egc..) construct.

> +}
> +
> +libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
> +                            const libxl_asyncop_how *how) {
> +    libxl__ao *ao;
> +
> +    ao = calloc(sizeof(*ao),1);

calloc is actually (nmemb, size). I'm sure it doesn't really matter
though.


> +    if (!ao) goto out;
> +
> +    ao->magic = LIBXL__AO_MAGIC;
> +    ao->in_initiator = 1;
> +    ao->poller = 0;
> +    ao->domid = domid;
> +    LIBXL_INIT_GC(ao->gc, ctx);
> +
> +    if (how) {
> +        ao->how = *how;
> +    } else {
> +        ao->poller = libxl__poller_get(ctx);
> +        if (!ao->poller) goto out;
> +    }
> +    return ao;
> +
> + out:
> +    if (ao) libxl__ao__destroy(ctx, ao);
> +    return NULL;
> +}
> +
> +int libxl__ao_inprogress(libxl__ao *ao) {
> +    AO_GC;
> +    int rc;
> +
> +    assert(ao->magic == LIBXL__AO_MAGIC);
> +    assert(ao->in_initiator);
> +
> +    if (ao->poller) {
> +        /* Caller wants it done synchronously. */
> +        /* We use a fresh gc, so that we can free things
> +         * each time round the loop. */
> +        libxl__egc egc;
> +        LIBXL_INIT_EGC(egc,CTX);
> +
> +        for (;;) {
> +            assert(ao->magic == LIBXL__AO_MAGIC);
> +
> +            if (ao->complete) {
> +                rc = ao->rc;
> +                ao->notified = 1;
> +                break;
> +            }
> +
> +            rc = eventloop_iteration(&egc,ao->poller);
> +            if (rc) {
> +                /* Oh dear, this is quite unfortunate. */
> +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
> +                           " event during long-running operation (rc=%d)", rc);
> +                sleep(1);
> +                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
> +                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
> +                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
> +                 * cancellation ability. */

Does this constitute a "disaster" (in the special hook sense)?

> +            }
> +
> +            CTX_UNLOCK;
> +            libxl__egc_cleanup(&egc);
> +            CTX_LOCK;
> +        }
> +    } else {
> +        rc = ERROR_ASYNC_INPROGRESS;
> +    }
> +
> +    ao->in_initiator = 0;
> +
> +    if (ao->notified) {
> +        assert(ao->complete);
> +        libxl__ao__destroy(CTX,ao);
> +    }
> +
> +    return rc;
> +}
> +
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 53d2462..594b9fb 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
[...]
> @@ -1123,6 +1144,97 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
> 
> 
>  /*
> + * Machinery for asynchronous operations ("ao")
> + *
> + * All "slow" functions (includes anything that might block on a
> + * guest or an external script) need to use the asynchronous
> + * operation ("ao") machinery.  The function should take a parameter
> + * const libxl_asyncop_how *ao_how and must start with a call to
> + * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
> + * outside libxl, because they can cause reentrancy callbacks.
> + *
> + * No functions called internally within libxl should ever return
> + * ERROR_ASYNCH_INPROGRESS.

Aitch.

> + *
> + * Lifecycle of an ao:
> + *
> + * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
> + *
> + * - After creation, can be used by code which implements
> + *   the operation as follows:
> + *      - the ao's gc, for allocating memory for the lifetime
> + *        of the operation (possibly with the help of the AO_GC
> + *        macro to introduce the gc into scope)
> + *      - the ao itself may be passed about to sub-functions
> + *        so that they can stash it away etc.
> + *      - in particular, the ao pointer must be stashed in some
> + *        per-operation structure which is also passed as a user
> + *        pointer to the internal event generation request routines
> + *        libxl__evgen_FOO, so that at some point a CALLBACK will be
> + *        made when the operation is complete.
> + *
> + * - If initiation is successful, the initiating function needs
> + *   to run libxl__ao_inprogress right before unlocking and
> + *   returning, and return whatever it returns (AO_INPROGRESS macro).
> + *
> + * - If the initiation is unsuccessful, the initiating function must
> + *   call libxl__ao_abort before unlocking and returning whatever
> + *   error code is appropriate (AO_ABORT macro).
> + *
> + * - Later, some callback function, whose callback has been requested
> + *   directly or indirectly, should call libxl__ao_complete (with the
> + *   ctx locked, as it will generally already be in any event callback
> + *   function).  This must happen exactly once for each ao (and not if
> + *   the ao has been destroyed, obviously), and it may not happen
> + *   until libxl__ao_inprogress has been called on the ao.
> + *
> + * - Note that during callback functions, two gcs are available:
> + *    - The one in egc, whose lifetime is only this callback
> + *    - The one in ao, whose lifetime is the asynchronous operation
> + *   Usually callback function should use GET_CONTAINING_STRUCT

Now called CONTAINER_OF

> + *   to obtain its own structure, containing a pointer to the ao,
> + *   and then use the gc from that ao.
> + */
> +
> +#define AO_CREATE(ctx, domid, ao_how)                           \
> +    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
> +    if (!ao) return ERROR_NOMEM;                                \
> +    AO_GC;                                                      \
> +    CTX_LOCK;

Where does the unlock which balances this come from? The only unlock I
see in this patch is the temporary drop in libxl__ao_inprogress which is
matched by another lock.

> +
> +#define AO_INPROGRESS do{                                       \
> +        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> +        int ao__rc = libxl__ao_inprogress(ao);                  \
> +        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \

Is this supposed to be unlock answering my question above? Likewise in
ABORT?

> +        return ao__rc;                                          \
> +   }while(0)

Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
would become
	return AO_INPROGRESS;

Is the ({stuff,stuff,stuff,val}) syntax a gcc-ism?

> +
> +
> +#define AO_ABORT(rc) do{                                        \
> +        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> +        assert(rc);                                             \
> +        assert(rc != ERROR_ASYNC_INPROGRESS);                   \
> +        libxl__ao_abort(ao);                                    \
> +        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
> +        return (rc);                                            \
> +    }while(0)
> +
> +#define AO_GC                                   \
> +    libxl__gc *const gc = &ao->gc
> +
> +
> +/* All of these MUST be called with the ctx locked.

Except libxl__ao_create? at least according to the implementation of
AO_CREATE which takes the lock after.

> + * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
> +_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
> +                                    const libxl_asyncop_how*);
> +_hidden int libxl__ao_inprogress(libxl__ao *ao);
> +_hidden void libxl__ao_abort(libxl__ao *ao);
> +_hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
> +
> +/* For use by ao machinery ONLY */
> +_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
> +
> +/*
>   * Convenience macros.
>   */
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index a6dac79..325bb21 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -395,6 +395,7 @@ libxl_event_type = Enumeration("event_type", [
>      (1, "DOMAIN_SHUTDOWN"),
>      (2, "DOMAIN_DESTROY"),
>      (3, "DISK_EJECT"),
> +    (4, "OPERATION_COMPLETE"),
>      ])
> 
>  libxl_ev_user = UInt(64)
> @@ -418,4 +419,7 @@ libxl_event = Struct("event",[
>                                          ("vdev", string),
>                                          ("disk", libxl_device_disk),
>                                   ])),
> +           ("operation_complete", Struct(None, [
> +                                        ("rc", integer),
> +                                 ])),
>             ]))])
> --
> 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 Jan 19 10:54:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpdF-00074m-7U; Thu, 19 Jan 2012 10:54:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnpdD-00074e-Px
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:54:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326970443!9750942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1795 invoked from network); 19 Jan 2012 10:54:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:54:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10136620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:54: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, 19 Jan 2012 10:54:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 10:54:02 +0000
In-Reply-To: <1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326970442.17599.53.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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Provide a new-style asynchronous facility for waiting for device
> states on xenbus.  This will replace libxl__wait_for_device_state,
> after the callers have been updated in later patches.

Is event-with-timeout likely to be a useful/common enough pattern to be
worth baking into the infrastructure/helpers rather than implementing
just for this one event type? (if yes then, "I will refactor for the
second user is a valid response").

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |   75 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   41 +++++++++++++++++++++++
>  2 files changed, 116 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index b99049a..1d271b8 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -507,6 +507,81 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
[...]
> +    libxl__ev_devstate_cancel(gc, ds);
> +    ds->callback(egc, ds, rc);
> +}
> +
> +static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
> +                             const struct timeval *requested_abs)
> +{
> +    EGC_GC;
> +    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
> +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
> +               " timed out", ds->watch.path, ds->wanted);
> +    libxl__ev_devstate_cancel(gc, ds);

What prevents racing here with the watch happening? Might the caller see
two callbacks?

> +    ds->callback(egc, ds, ERROR_TIMEDOUT);
> +}
> +


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:54:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpdF-00074m-7U; Thu, 19 Jan 2012 10:54:13 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnpdD-00074e-Px
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:54:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326970443!9750942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1795 invoked from network); 19 Jan 2012 10:54:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:54:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10136620"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:54: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, 19 Jan 2012 10:54:02 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 10:54:02 +0000
In-Reply-To: <1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326970442.17599.53.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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Provide a new-style asynchronous facility for waiting for device
> states on xenbus.  This will replace libxl__wait_for_device_state,
> after the callers have been updated in later patches.

Is event-with-timeout likely to be a useful/common enough pattern to be
worth baking into the infrastructure/helpers rather than implementing
just for this one event type? (if yes then, "I will refactor for the
second user is a valid response").

> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl_event.c    |   75 ++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/libxl_internal.h |   41 +++++++++++++++++++++++
>  2 files changed, 116 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
> index b99049a..1d271b8 100644
> --- a/tools/libxl/libxl_event.c
> +++ b/tools/libxl/libxl_event.c
> @@ -507,6 +507,81 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
[...]
> +    libxl__ev_devstate_cancel(gc, ds);
> +    ds->callback(egc, ds, rc);
> +}
> +
> +static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
> +                             const struct timeval *requested_abs)
> +{
> +    EGC_GC;
> +    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
> +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
> +               " timed out", ds->watch.path, ds->wanted);
> +    libxl__ev_devstate_cancel(gc, ds);

What prevents racing here with the watch happening? Might the caller see
two callbacks?

> +    ds->callback(egc, ds, ERROR_TIMEDOUT);
> +}
> +


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 10:58:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnpgy-0007Ib-SU; Thu, 19 Jan 2012 10:58:04 +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 1Rnpgw-0007ID-LY
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:58:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326970475!11490141!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11384 invoked from network); 19 Jan 2012 10:54:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10136654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:54:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 10:54:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rnpdb-0004eb-BW;
	Thu, 19 Jan 2012 10:54:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rnpdb-0001LZ-7j;
	Thu, 19 Jan 2012 10:54:35 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10891-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 10:54:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10891: 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 10891 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10891/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          18 leak-check/check            fail pass in 10888
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10867
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install       fail pass in 10888
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10888 pass in 10891
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10888 pass in 10891
 test-amd64-amd64-xl-win7-amd64  7 windows-install  fail in 10888 pass in 10891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10888 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                          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 870 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 Jan 19 10:58:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 10:58:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnpgy-0007Ib-SU; Thu, 19 Jan 2012 10:58:04 +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 1Rnpgw-0007ID-LY
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 10:58:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1326970475!11490141!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11384 invoked from network); 19 Jan 2012 10:54:35 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 10:54:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10136654"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:54:35 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 10:54:35 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rnpdb-0004eb-BW;
	Thu, 19 Jan 2012 10:54:35 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rnpdb-0001LZ-7j;
	Thu, 19 Jan 2012 10:54:35 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10891-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 10:54:35 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10891: 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 10891 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10891/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  7 redhat-install          fail REGR. vs. 10649
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-win       7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649
 test-i386-i386-win            7 windows-install           fail REGR. vs. 10649
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10649
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10649

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv          18 leak-check/check            fail pass in 10888
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 10867
 test-amd64-i386-xl-winxpsp3-vcpus1  7 windows-install       fail pass in 10888
 test-amd64-i386-rhel6hvm-amd  7 redhat-install     fail in 10888 pass in 10891
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 10888 pass in 10891
 test-amd64-amd64-xl-win7-amd64  7 windows-install  fail in 10888 pass in 10891

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10888 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 10867 never pass

version targeted for testing:
 xen                  15ab61865ecb
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                          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 870 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 Jan 19 11:02:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnpku-0007UK-JT; Thu, 19 Jan 2012 11:02:08 +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 1Rnpkt-0007UA-WA
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:02:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326970921!11095194!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 6611 invoked from network); 19 Jan 2012 11:02:01 -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; 19 Jan 2012 11:02:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnpkj-000HPT-HP; Thu, 19 Jan 2012 11:01:57 +0000
Date: Thu, 19 Jan 2012 11:01:56 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119110156.GA66164@ocelot.phlegethon.org>
References: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] EPT: refine epte_present test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 agree with the idea of this patch but: 

> +static inline bool_t is_epte_valid(ept_entry_t *e)
> +{
> +    ept_entry_t rights = { .epte = 0 };
> +
> +    /* Not valid if empty */
> +    if (e->epte == 0) return 0;
> +
> +    /* Not valid if mfn not valid */
> +    if ( !mfn_valid(e->mfn) ) return 0;
> +
> +    /* Not valid if rights different from those of 
> +     * its p2m type and access combination */
> +    ept_p2m_type_to_flags(&rights, e->sa_p2mt, e->access);
> +    if ( epte_permissions(&rights) != epte_permissions(e) )
> +        return 0;

This is a rather odd set of tests.  Since we construct EPT pagetables
ourselves, I think that we only need to test for uninitialised entries
and explicitly invalid entries.

Does this patch work for you?

diff -r f5b366c6c4c6 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Thu Jan 19 10:42:42 2012 +0000
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Jan 19 11:01:34 2012 +0000
@@ -41,6 +41,10 @@
 
 #define is_epte_present(ept_entry)      ((ept_entry)->epte & 0x7)
 #define is_epte_superpage(ept_entry)    ((ept_entry)->sp)
+static inline bool_t is_epte_valid(ept_entry_t *e)
+{
+    return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
+}
 
 /* Non-ept "lock-and-check" wrapper */
 static int ept_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
@@ -777,7 +781,7 @@ static void ept_change_entry_type_page(m
 
     for ( int i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
     {
-        if ( !is_epte_present(epte + i) )
+        if ( !is_epte_valid(epte + i) )
             continue;
 
         if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:02:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:02:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnpku-0007UK-JT; Thu, 19 Jan 2012 11:02:08 +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 1Rnpkt-0007UA-WA
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:02:08 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326970921!11095194!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 6611 invoked from network); 19 Jan 2012 11:02:01 -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; 19 Jan 2012 11:02:01 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnpkj-000HPT-HP; Thu, 19 Jan 2012 11:01:57 +0000
Date: Thu, 19 Jan 2012 11:01:56 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119110156.GA66164@ocelot.phlegethon.org>
References: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] EPT: refine epte_present test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 agree with the idea of this patch but: 

> +static inline bool_t is_epte_valid(ept_entry_t *e)
> +{
> +    ept_entry_t rights = { .epte = 0 };
> +
> +    /* Not valid if empty */
> +    if (e->epte == 0) return 0;
> +
> +    /* Not valid if mfn not valid */
> +    if ( !mfn_valid(e->mfn) ) return 0;
> +
> +    /* Not valid if rights different from those of 
> +     * its p2m type and access combination */
> +    ept_p2m_type_to_flags(&rights, e->sa_p2mt, e->access);
> +    if ( epte_permissions(&rights) != epte_permissions(e) )
> +        return 0;

This is a rather odd set of tests.  Since we construct EPT pagetables
ourselves, I think that we only need to test for uninitialised entries
and explicitly invalid entries.

Does this patch work for you?

diff -r f5b366c6c4c6 xen/arch/x86/mm/p2m-ept.c
--- a/xen/arch/x86/mm/p2m-ept.c	Thu Jan 19 10:42:42 2012 +0000
+++ b/xen/arch/x86/mm/p2m-ept.c	Thu Jan 19 11:01:34 2012 +0000
@@ -41,6 +41,10 @@
 
 #define is_epte_present(ept_entry)      ((ept_entry)->epte & 0x7)
 #define is_epte_superpage(ept_entry)    ((ept_entry)->sp)
+static inline bool_t is_epte_valid(ept_entry_t *e)
+{
+    return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
+}
 
 /* Non-ept "lock-and-check" wrapper */
 static int ept_pod_check_and_populate(struct p2m_domain *p2m, unsigned long gfn,
@@ -777,7 +781,7 @@ static void ept_change_entry_type_page(m
 
     for ( int i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
     {
-        if ( !is_epte_present(epte + i) )
+        if ( !is_epte_valid(epte + i) )
             continue;
 
         if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:07:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpqJ-0007fb-C3; Thu, 19 Jan 2012 11:07:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RnpqI-0007fT-9E
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:07:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326971255!9052785!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 30816 invoked from network); 19 Jan 2012 11:07:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 11:07:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnpq2-000HRD-Td; Thu, 19 Jan 2012 11:07:27 +0000
Date: Thu, 19 Jan 2012 11:07:26 +0000
From: Tim Deegan <tim@xen.org>
To: hxkhust <hxkhust@126.com>
Message-ID: <20120119110726.GB66164@ocelot.phlegethon.org>
References: <f11ec12.21ca.134d4904a11.Coremail.hxkhust@126.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f11ec12.21ca.134d4904a11.Coremail.hxkhust@126.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] A Problem with Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 
At 08:55 +0800 on 13 Jan (1326444953), hxkhust wrote:
> On a physical machine with xen virtualization platform installed ,VM
>  A,VM B are VM C's virtual disks are all image files,among which VM A
>  and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
>  format. And VM B and VM C's virtual disk image files are based on VM
>  A's virtual disk image file.Now these three VMs are running on the
>  same physical machine with xen installed. 
> 
>  In the process of running VM B get a page data from VM A's virtual
>  disk image file. After that ,VM C also need to get the same page data
>  as VM B got just now.Under this situation, does VMM copy the page
>  data from VM B's memory to VM C's memory or get the page data from VM
>  A's virtual disk image file in the physical disk again?

Since VM C's disk is not QCOW, reads will always come directly from VM
C's image -- never from VM A's image (since the tools wouldn't know how
to do that) and never by copying from VM B.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:07:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:07:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnpqJ-0007fb-C3; Thu, 19 Jan 2012 11:07:43 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RnpqI-0007fT-9E
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:07:42 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326971255!9052785!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 30816 invoked from network); 19 Jan 2012 11:07:36 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 11:07:36 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnpq2-000HRD-Td; Thu, 19 Jan 2012 11:07:27 +0000
Date: Thu, 19 Jan 2012 11:07:26 +0000
From: Tim Deegan <tim@xen.org>
To: hxkhust <hxkhust@126.com>
Message-ID: <20120119110726.GB66164@ocelot.phlegethon.org>
References: <f11ec12.21ca.134d4904a11.Coremail.hxkhust@126.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <f11ec12.21ca.134d4904a11.Coremail.hxkhust@126.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] A Problem with Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi, 
At 08:55 +0800 on 13 Jan (1326444953), hxkhust wrote:
> On a physical machine with xen virtualization platform installed ,VM
>  A,VM B are VM C's virtual disks are all image files,among which VM A
>  and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
>  format. And VM B and VM C's virtual disk image files are based on VM
>  A's virtual disk image file.Now these three VMs are running on the
>  same physical machine with xen installed. 
> 
>  In the process of running VM B get a page data from VM A's virtual
>  disk image file. After that ,VM C also need to get the same page data
>  as VM B got just now.Under this situation, does VMM copy the page
>  data from VM B's memory to VM C's memory or get the page data from VM
>  A's virtual disk image file in the physical disk again?

Since VM C's disk is not QCOW, reads will always come directly from VM
C's image -- never from VM A's image (since the tools wouldn't know how
to do that) and never by copying from VM B.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:40:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnqLC-0008WK-Qa; Thu, 19 Jan 2012 11:39:38 +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 1RnqLB-0008WF-Lr
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:39:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326973167!9819183!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 13756 invoked from network); 19 Jan 2012 11:39:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 11:39:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnqKv-000Haj-7M; Thu, 19 Jan 2012 11:39:21 +0000
Date: Thu, 19 Jan 2012 11:39:19 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119113919.GC66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<2a4112172e4497f29d03.1326682581@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2a4112172e4497f29d03.1326682581@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 12] 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

Hi, 

This seems basically fine; it's a logical progression from the interface
changes.  A few comments inline below.

One other thing I noticed, which is independent of this patch, really:
I'm not sure that having a domain ID in the gfn_info is the right
thing to do.  It seems like we could just carry a domain pointer.  


At 21:56 -0500 on 15 Jan (1326664581), Andres Lagar-Cavilla wrote:
> The hashtable mechanism used by the sharing code is a bit odd.  It seems
> unnecessary and adds complexity. 

I think that's a bit harsh, since you removed its main use yourself! :)

> 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 302a58874eb1 -r 2a4112172e44 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,30 @@
>  
>  #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);

Hmmm.  You haven't made any of the callers use this new return value. :(
Better to leave it as it was.

>  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;

Can you call this field 'sharing' instead?  'shared-info' makes me
think of the per-domain shared_info page, and tripped me up a few times
reading this patch. :)

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 Jan 19 11:40:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:40:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnqLC-0008WK-Qa; Thu, 19 Jan 2012 11:39:38 +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 1RnqLB-0008WF-Lr
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:39:37 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1326973167!9819183!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 13756 invoked from network); 19 Jan 2012 11:39:27 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 11:39:27 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnqKv-000Haj-7M; Thu, 19 Jan 2012 11:39:21 +0000
Date: Thu, 19 Jan 2012 11:39:19 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119113919.GC66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<2a4112172e4497f29d03.1326682581@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2a4112172e4497f29d03.1326682581@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 12] 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

Hi, 

This seems basically fine; it's a logical progression from the interface
changes.  A few comments inline below.

One other thing I noticed, which is independent of this patch, really:
I'm not sure that having a domain ID in the gfn_info is the right
thing to do.  It seems like we could just carry a domain pointer.  


At 21:56 -0500 on 15 Jan (1326664581), Andres Lagar-Cavilla wrote:
> The hashtable mechanism used by the sharing code is a bit odd.  It seems
> unnecessary and adds complexity. 

I think that's a bit harsh, since you removed its main use yourself! :)

> 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 302a58874eb1 -r 2a4112172e44 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,30 @@
>  
>  #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);

Hmmm.  You haven't made any of the callers use this new return value. :(
Better to leave it as it was.

>  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;

Can you call this field 'sharing' instead?  'shared-info' makes me
think of the per-domain shared_info page, and tripped me up a few times
reading this patch. :)

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 Jan 19 11:55:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11: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 1RnqZe-0000X7-CZ; Thu, 19 Jan 2012 11:54:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RnqZd-0000X2-EZ
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:54:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326974066!9791077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 19 Jan 2012 11:54:26 -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;
	19 Jan 2012 11:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10139691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 11:54:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 11:54:25 +0000
Date: Thu, 19 Jan 2012 11:55:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>, xen-devel@lists.xensource.com,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this is the third version of the Xen save/restore patch series.
We have been discussing this issue for quite a while on #qemu and
qemu-devel:


http://marc.info/?l=qemu-devel&m=132346828427314&w=2
http://marc.info/?l=qemu-devel&m=132377734605464&w=2


A few different approaches were proposed to achieve the goal
of a working save/restore with upstream Qemu on Xen, however after
prototyping some of them I came up with yet another solution, that I
think leads to the best results with the less amount of code
duplications and ugliness.
Far from saying that this patch series is an example of elegance and
simplicity, but it is closer to acceptable anything else I have seen so
far.

What's new is that Qemu is going to keep track of its own physmap on
xenstore, so that Xen can be fully aware of the changes Qemu makes to
the guest's memory map at any time.
This is all handled by Xen or Xen support in Qemu internally and can be
used to solve our save/restore framebuffer problem.

>From the Qemu common code POV, we still need to avoid saving the guest's
ram when running on Xen, and we need to avoid resetting the videoram on
restore (that is a benefit to the generic Qemu case too, because it
saves few cpu cycles).



This is the list of patches with a diffstat:

Anthony PERARD (4):
      vl.c: do not save the RAM state when Xen is enabled
      xen mapcache: check if memory region has moved.
      cirrus_vga: do not reset videoram on resume
      xen: change memory access behavior during migration.

Stefano Stabellini (2):
      Set runstate to INMIGRATE earlier
      xen: record physmap changes to xenstore

 hw/cirrus_vga.c |    9 ++++--
 vl.c            |    8 +++--
 xen-all.c       |   89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen-mapcache.c  |   22 ++++++++++++--
 xen-mapcache.h  |    9 ++++-
 5 files changed, 125 insertions(+), 12 deletions(-)


git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-3

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 Jan 19 11:55:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11: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 1RnqZe-0000X7-CZ; Thu, 19 Jan 2012 11:54:34 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RnqZd-0000X2-EZ
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:54:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1326974066!9791077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14561 invoked from network); 19 Jan 2012 11:54:26 -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;
	19 Jan 2012 11:54:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10139691"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 11:54:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 11:54:25 +0000
Date: Thu, 19 Jan 2012 11:55:05 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>, xen-devel@lists.xensource.com,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this is the third version of the Xen save/restore patch series.
We have been discussing this issue for quite a while on #qemu and
qemu-devel:


http://marc.info/?l=qemu-devel&m=132346828427314&w=2
http://marc.info/?l=qemu-devel&m=132377734605464&w=2


A few different approaches were proposed to achieve the goal
of a working save/restore with upstream Qemu on Xen, however after
prototyping some of them I came up with yet another solution, that I
think leads to the best results with the less amount of code
duplications and ugliness.
Far from saying that this patch series is an example of elegance and
simplicity, but it is closer to acceptable anything else I have seen so
far.

What's new is that Qemu is going to keep track of its own physmap on
xenstore, so that Xen can be fully aware of the changes Qemu makes to
the guest's memory map at any time.
This is all handled by Xen or Xen support in Qemu internally and can be
used to solve our save/restore framebuffer problem.

>From the Qemu common code POV, we still need to avoid saving the guest's
ram when running on Xen, and we need to avoid resetting the videoram on
restore (that is a benefit to the generic Qemu case too, because it
saves few cpu cycles).



This is the list of patches with a diffstat:

Anthony PERARD (4):
      vl.c: do not save the RAM state when Xen is enabled
      xen mapcache: check if memory region has moved.
      cirrus_vga: do not reset videoram on resume
      xen: change memory access behavior during migration.

Stefano Stabellini (2):
      Set runstate to INMIGRATE earlier
      xen: record physmap changes to xenstore

 hw/cirrus_vga.c |    9 ++++--
 vl.c            |    8 +++--
 xen-all.c       |   89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen-mapcache.c  |   22 ++++++++++++--
 xen-mapcache.h  |    9 ++++-
 5 files changed, 125 insertions(+), 12 deletions(-)


git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-3

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 Jan 19 11:55:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11: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 1RnqaS-0000ZF-RX; Thu, 19 Jan 2012 11:55:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnqaR-0000Ym-2V
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326974071!50909066!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19239 invoked from network); 19 Jan 2012 11:54:31 -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;
	19 Jan 2012 11:54:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10139714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 11:55: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, 19 Jan 2012 11:55:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 11:55:18 +0000
In-Reply-To: <1326482728-10733-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326974118.17599.72.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 9/9] libxl: Convert to asynchronous: device
 removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Convert libxl_FOO_device_remove, and the function which does the bulk
> of the work, libxl__device_remove, to the new async ops scheme.
> 
> Adjust all callers.
> 
> Also remove libxl__wait_for_device_state which is now obsolete.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |   60 +++++++++++++--------
>  tools/libxl/libxl.h          |   16 ++++--
>  tools/libxl/libxl_device.c   |  118 +++++++++++++-----------------------------
>  tools/libxl/libxl_internal.h |   30 ++---------
>  tools/libxl/xl_cmdimpl.c     |    4 +-
>  5 files changed, 93 insertions(+), 135 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 9890d79..d63da97 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1310,19 +1310,23 @@ out:
>  }
> 
>  int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
> -                             libxl_device_disk *disk)
> +                             libxl_device_disk *disk,
> +                             const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> +    AO_CREATE(ctx, domid, ao_how);
>      libxl__device device;
>      int rc;
> 
>      rc = libxl__device_from_disk(gc, domid, disk, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(gc, &device, 1);
> +    rc = libxl__initiate_device_remove(ao, &device);
> +    if (rc) goto out;
> +
> +    AO_INPROGRESS;
> +
>  out:
> -    GC_FREE;
> -    return rc;
> +    AO_ABORT(rc);
>  }

After all the internal complexity the actual usage is refreshingly
simple. Phew!

> 
>  int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
> @@ -1536,11 +1540,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
> 
>      ret = 0;
> 
> -    libxl_device_disk_remove(ctx, domid, disks + i);
> +    libxl_device_disk_remove(ctx, domid, disks + i, 0);
>      libxl_device_disk_add(ctx, domid, disk);
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
>      if (stubdomid) {
> -        libxl_device_disk_remove(ctx, stubdomid, disks + i);
> +        libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
>          libxl_device_disk_add(ctx, stubdomid, disk);
>      }
>  out:

The async capability here ought to be propagated to the
libxl_cdrom_insert interface too. I guess that would mean handling
compound asynchronous operations.

...in the fullness of time, of course.


> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 416d6e8..602bd01 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h

> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 5d05e90..e905133 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -357,85 +357,41 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
>      return -1;
>  }
> 
[...]
> +typedef struct {
> +    libxl__ao *ao;
> +    libxl__ev_devstate ds;
> +} libxl__ao_device_remove;
> +
> +static void device_remove_cleanup(libxl__gc *gc,
> +                                  libxl__ao_device_remove *aorm) {
> +    if (!aorm) return;
> +    libxl__ev_devstate_cancel(gc, &aorm->ds);
> +}
> 
[...]
> +static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
> +                                   int rc) {
> +    libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
> +    libxl__gc *gc = &aorm->ao->gc;
> +    libxl__ao_complete(egc, aorm->ao, rc);
> +    device_remove_cleanup(gc, aorm);
>  }
> 
[...]
> +int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
>  {
> +    /* Arranges that dev will be removed from its guest.  When
> +     * this is done, the ao will be completed.  An error
> +     * return from libxl__device_remove means that the ao
> +     * will _not_ be completed and the caller must do so.

Do you mean aborted or cancelled rather than completed here?

> +     */
> +    AO_GC;
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      xs_transaction_t t;
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *state_path = libxl__sprintf(gc, "%s/state", be_path);
>      char *state = libxl__xs_read(gc, XBT_NULL, state_path);
>      int rc = 0;
> +    libxl__ao_device_remove *aorm = 0;
> 
>      if (!state)
>          goto out;
> @@ -458,23 +414,21 @@ retry_transaction:
>          }
>      }
> 
[...]
>      libxl__device_destroy_tapdisk(gc, be_path);
> 
[...]
> +    aorm = libxl__zalloc(gc, sizeof(*aorm));
> +    aorm->ao = ao;
> +    libxl__ev_devstate_init(&aorm->ds);
> 
[...]
> +    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
> +                                 state_path, XenbusStateClosed,
> +                                 LIBXL_DESTROY_TIMEOUT * 1000);
> +    if (rc) goto out;
> +
> +    return 0;
> +
> + out:
> +    device_remove_cleanup(gc, aorm);
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index b7f0f54..9920fb9 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -653,35 +653,15 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
[...]
> +/* Arranges that dev will be removed from its guest.  When
> + * this is done, the ao will be completed.  An error
> + * return from libxl__device_remove means that the ao
> + * will _not_ be completed and the caller must do so. */

This is the same comment as at the head of the implementation so the
same comment re aborting applies. Do we need both comments?

> +_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
> 
>  /*
>   * libxl__ev_devstate - waits a given time for a device to
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index c2b7a1e..659a9e6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -4624,7 +4624,7 @@ int main_networkdetach(int argc, char **argv)
>              return 1;
>          }
>      }
> -    if (libxl_device_nic_remove(ctx, domid, &nic)) {
> +    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
>          fprintf(stderr, "libxl_device_nic_del failed.\n");
>          return 1;
>      }

There aren't actually any examples of a caller using the ao-ness in xl
are there?

I know that sync is for the most part ao+wait but I'm a bit concerned
that e.g. several of the paths in libxl__ao_complete probably haven't
been run and one of the flow-charts added to tools/libxl/libxl_event.c
in patch 6/8 has probably never happened either.

IMHO this isn't a blocker for this patch but since xl is, in addition to
being a toolstack, a testbed for libxl perhaps one or more "gratuitously
asynchronous" calls could be made? Perhaps the libxl_cdrom_insert case
would be an interesting one? In particular the case in the
create_domain() event loop (e.g. so that the response to a cdrom eject
does not block shutdown processing).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:55:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11: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 1RnqaS-0000ZF-RX; Thu, 19 Jan 2012 11:55:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnqaR-0000Ym-2V
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326974071!50909066!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19239 invoked from network); 19 Jan 2012 11:54:31 -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;
	19 Jan 2012 11:54:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10139714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 11:55: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, 19 Jan 2012 11:55:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 11:55:18 +0000
In-Reply-To: <1326482728-10733-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326974118.17599.72.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 9/9] libxl: Convert to asynchronous: device
 removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> Convert libxl_FOO_device_remove, and the function which does the bulk
> of the work, libxl__device_remove, to the new async ops scheme.
> 
> Adjust all callers.
> 
> Also remove libxl__wait_for_device_state which is now obsolete.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> ---
>  tools/libxl/libxl.c          |   60 +++++++++++++--------
>  tools/libxl/libxl.h          |   16 ++++--
>  tools/libxl/libxl_device.c   |  118 +++++++++++++-----------------------------
>  tools/libxl/libxl_internal.h |   30 ++---------
>  tools/libxl/xl_cmdimpl.c     |    4 +-
>  5 files changed, 93 insertions(+), 135 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 9890d79..d63da97 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1310,19 +1310,23 @@ out:
>  }
> 
>  int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
> -                             libxl_device_disk *disk)
> +                             libxl_device_disk *disk,
> +                             const libxl_asyncop_how *ao_how)
>  {
> -    GC_INIT(ctx);
> +    AO_CREATE(ctx, domid, ao_how);
>      libxl__device device;
>      int rc;
> 
>      rc = libxl__device_from_disk(gc, domid, disk, &device);
>      if (rc != 0) goto out;
> 
> -    rc = libxl__device_remove(gc, &device, 1);
> +    rc = libxl__initiate_device_remove(ao, &device);
> +    if (rc) goto out;
> +
> +    AO_INPROGRESS;
> +
>  out:
> -    GC_FREE;
> -    return rc;
> +    AO_ABORT(rc);
>  }

After all the internal complexity the actual usage is refreshingly
simple. Phew!

> 
>  int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
> @@ -1536,11 +1540,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
> 
>      ret = 0;
> 
> -    libxl_device_disk_remove(ctx, domid, disks + i);
> +    libxl_device_disk_remove(ctx, domid, disks + i, 0);
>      libxl_device_disk_add(ctx, domid, disk);
>      stubdomid = libxl_get_stubdom_id(ctx, domid);
>      if (stubdomid) {
> -        libxl_device_disk_remove(ctx, stubdomid, disks + i);
> +        libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
>          libxl_device_disk_add(ctx, stubdomid, disk);
>      }
>  out:

The async capability here ought to be propagated to the
libxl_cdrom_insert interface too. I guess that would mean handling
compound asynchronous operations.

...in the fullness of time, of course.


> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 416d6e8..602bd01 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h

> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 5d05e90..e905133 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -357,85 +357,41 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
>      return -1;
>  }
> 
[...]
> +typedef struct {
> +    libxl__ao *ao;
> +    libxl__ev_devstate ds;
> +} libxl__ao_device_remove;
> +
> +static void device_remove_cleanup(libxl__gc *gc,
> +                                  libxl__ao_device_remove *aorm) {
> +    if (!aorm) return;
> +    libxl__ev_devstate_cancel(gc, &aorm->ds);
> +}
> 
[...]
> +static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
> +                                   int rc) {
> +    libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
> +    libxl__gc *gc = &aorm->ao->gc;
> +    libxl__ao_complete(egc, aorm->ao, rc);
> +    device_remove_cleanup(gc, aorm);
>  }
> 
[...]
> +int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
>  {
> +    /* Arranges that dev will be removed from its guest.  When
> +     * this is done, the ao will be completed.  An error
> +     * return from libxl__device_remove means that the ao
> +     * will _not_ be completed and the caller must do so.

Do you mean aborted or cancelled rather than completed here?

> +     */
> +    AO_GC;
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      xs_transaction_t t;
>      char *be_path = libxl__device_backend_path(gc, dev);
>      char *state_path = libxl__sprintf(gc, "%s/state", be_path);
>      char *state = libxl__xs_read(gc, XBT_NULL, state_path);
>      int rc = 0;
> +    libxl__ao_device_remove *aorm = 0;
> 
>      if (!state)
>          goto out;
> @@ -458,23 +414,21 @@ retry_transaction:
>          }
>      }
> 
[...]
>      libxl__device_destroy_tapdisk(gc, be_path);
> 
[...]
> +    aorm = libxl__zalloc(gc, sizeof(*aorm));
> +    aorm->ao = ao;
> +    libxl__ev_devstate_init(&aorm->ds);
> 
[...]
> +    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
> +                                 state_path, XenbusStateClosed,
> +                                 LIBXL_DESTROY_TIMEOUT * 1000);
> +    if (rc) goto out;
> +
> +    return 0;
> +
> + out:
> +    device_remove_cleanup(gc, aorm);
>      return rc;
>  }
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index b7f0f54..9920fb9 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -653,35 +653,15 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
[...]
> +/* Arranges that dev will be removed from its guest.  When
> + * this is done, the ao will be completed.  An error
> + * return from libxl__device_remove means that the ao
> + * will _not_ be completed and the caller must do so. */

This is the same comment as at the head of the implementation so the
same comment re aborting applies. Do we need both comments?

> +_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
> 
>  /*
>   * libxl__ev_devstate - waits a given time for a device to
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index c2b7a1e..659a9e6 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -4624,7 +4624,7 @@ int main_networkdetach(int argc, char **argv)
>              return 1;
>          }
>      }
> -    if (libxl_device_nic_remove(ctx, domid, &nic)) {
> +    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
>          fprintf(stderr, "libxl_device_nic_del failed.\n");
>          return 1;
>      }

There aren't actually any examples of a caller using the ao-ness in xl
are there?

I know that sync is for the most part ao+wait but I'm a bit concerned
that e.g. several of the paths in libxl__ao_complete probably haven't
been run and one of the flow-charts added to tools/libxl/libxl_event.c
in patch 6/8 has probably never happened either.

IMHO this isn't a blocker for this patch but since xl is, in addition to
being a toolstack, a testbed for libxl perhaps one or more "gratuitously
asynchronous" calls could be made? Perhaps the libxl_cdrom_insert case
would be an interesting one? In particular the case in the
create_domain() event loop (e.g. so that the response to a cdrom eject
does not block shutdown processing).

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqao-0000bf-DN; Thu, 19 Jan 2012 11:55:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rnqan-0000b8-0N
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326974117!63115389!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10840 invoked from network); 19 Jan 2012 11:55:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21052856"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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; Thu, 19 Jan 2012 06:55: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 q0JBtRIw011858;
	Thu, 19 Jan 2012 03:55:28 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:16 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v3 1/6] vl.c: do not save the RAM state when Xen
	is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Anthony PERARD <anthony.perard@citrix.com>

In the 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>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index ba55b35..6f0435b 100644
--- a/vl.c
+++ b/vl.c
@@ -3270,8 +3270,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;
-- 
1.7.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 Jan 19 11:56:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqao-0000bf-DN; Thu, 19 Jan 2012 11:55:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rnqan-0000b8-0N
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326974117!63115389!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10840 invoked from network); 19 Jan 2012 11:55:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21052856"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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; Thu, 19 Jan 2012 06:55: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 q0JBtRIw011858;
	Thu, 19 Jan 2012 03:55:28 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:16 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v3 1/6] vl.c: do not save the RAM state when Xen
	is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Anthony PERARD <anthony.perard@citrix.com>

In the 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>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index ba55b35..6f0435b 100644
--- a/vl.c
+++ b/vl.c
@@ -3270,8 +3270,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;
-- 
1.7.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 Jan 19 11:56:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqav-0000cj-6t; Thu, 19 Jan 2012 11:55:53 +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 1Rnqat-0000bg-TM
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326974143!9812435!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17514 invoked from network); 19 Jan 2012 11:55:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178190244"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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; Thu, 19 Jan 2012 06:55: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 q0JBtRIx011858;
	Thu, 19 Jan 2012 03:55:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:17 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v3 2/6] xen mapcache: check if memory region 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

From: Anthony PERARD <anthony.perard@citrix.com>

This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index c86ebf4..507d93d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -964,7 +980,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 9fecc64..d9c995b 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)
 {
 }
 
-- 
1.7.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 Jan 19 11:56:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqav-0000cj-6t; Thu, 19 Jan 2012 11:55:53 +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 1Rnqat-0000bg-TM
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326974143!9812435!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17514 invoked from network); 19 Jan 2012 11:55:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178190244"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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; Thu, 19 Jan 2012 06:55: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 q0JBtRIx011858;
	Thu, 19 Jan 2012 03:55:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:17 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v3 2/6] xen mapcache: check if memory region 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

From: Anthony PERARD <anthony.perard@citrix.com>

This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index c86ebf4..507d93d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -964,7 +980,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 9fecc64..d9c995b 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)
 {
 }
 
-- 
1.7.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 Jan 19 11:56:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqay-0000du-Ce; Thu, 19 Jan 2012 11:55:56 +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 1Rnqav-0000by-Rr
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326974145!11523776!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19589 invoked from network); 19 Jan 2012 11:55:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21052861"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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, 19 Jan 2012 06:55: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 q0JBtRJ3011858;
	Thu, 19 Jan 2012 03:55:37 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:21 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v3 6/6] 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

From: Anthony PERARD <anthony.perard@citrix.com>

Do not allocate RAM during INMIGRATE runstate.
Do not actually "do" set_memory during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index c830cb1..bac06fd 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* RAM already populated in Xen */
+        return;
+    }
+
     if (mr == &ram_memory) {
         return;
     }
@@ -255,6 +260,10 @@ static int xen_add_to_physmap(XenIOState *state,
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
     char path[80], value[17];
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        return 0;
+    }
+
     if (get_physmapping(state, start_addr, size)) {
         return 0;
     }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqay-0000du-Ce; Thu, 19 Jan 2012 11:55:56 +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 1Rnqav-0000by-Rr
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326974145!11523776!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19589 invoked from network); 19 Jan 2012 11:55:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21052861"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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, 19 Jan 2012 06:55: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 q0JBtRJ3011858;
	Thu, 19 Jan 2012 03:55:37 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:21 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v3 6/6] 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

From: Anthony PERARD <anthony.perard@citrix.com>

Do not allocate RAM during INMIGRATE runstate.
Do not actually "do" set_memory during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index c830cb1..bac06fd 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,11 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* RAM already populated in Xen */
+        return;
+    }
+
     if (mr == &ram_memory) {
         return;
     }
@@ -255,6 +260,10 @@ static int xen_add_to_physmap(XenIOState *state,
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
     char path[80], value[17];
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        return 0;
+    }
+
     if (get_physmapping(state, start_addr, size)) {
         return 0;
     }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqax-0000dS-K1; Thu, 19 Jan 2012 11:55:55 +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 1Rnqav-0000bu-BR
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326974145!11523776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19501 invoked from network); 19 Jan 2012 11:55:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21052860"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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, 19 Jan 2012 06:55: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 q0JBtRJ0011858;
	Thu, 19 Jan 2012 03:55:33 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:18 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 3/6] Set runstate to INMIGRATE earlier
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 6f0435b..bb0139f 100644
--- a/vl.c
+++ b/vl.c
@@ -2972,6 +2972,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_INMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
@@ -3468,7 +3469,6 @@ int main(int argc, char **argv, char **envp)
     }
 
     if (incoming) {
-        runstate_set(RUN_STATE_INMIGRATE);
         int ret = qemu_start_incoming_migration(incoming);
         if (ret < 0) {
             fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqax-0000dS-K1; Thu, 19 Jan 2012 11:55:55 +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 1Rnqav-0000bu-BR
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326974145!11523776!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19501 invoked from network); 19 Jan 2012 11:55:46 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21052860"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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, 19 Jan 2012 06:55: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 q0JBtRJ0011858;
	Thu, 19 Jan 2012 03:55:33 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:18 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 3/6] Set runstate to INMIGRATE earlier
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 6f0435b..bb0139f 100644
--- a/vl.c
+++ b/vl.c
@@ -2972,6 +2972,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_INMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
@@ -3468,7 +3469,6 @@ int main(int argc, char **argv, char **envp)
     }
 
     if (incoming) {
-        runstate_set(RUN_STATE_INMIGRATE);
         int ret = qemu_start_incoming_migration(incoming);
         if (ret < 0) {
             fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqau-0000cZ-QW; Thu, 19 Jan 2012 11:55:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rnqat-0000bZ-8E
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326974143!9812435!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17491 invoked from network); 19 Jan 2012 11:55:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178190243"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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; Thu, 19 Jan 2012 06:55: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 q0JBtRJ2011858;
	Thu, 19 Jan 2012 03:55:36 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:20 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 507d93d..c830cb1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -253,6 +253,7 @@ static int xen_add_to_physmap(XenIOState *state,
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+    char path[80], value[17];
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -299,6 +300,22 @@ go_physmap:
                                    start_addr >> TARGET_PAGE_BITS,
                                    (start_addr + size) >> TARGET_PAGE_BITS,
                                    XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+
     return 0;
 }
 
@@ -926,6 +943,50 @@ int xen_init(void)
     return 0;
 }
 
+static void xen_read_physmap(XenIOState *state)
+{
+    XenPhysmap *physmap = NULL;
+    unsigned int len, num, i;
+    char path[80], *value = NULL;
+    char **entries = NULL;
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap", xen_domid);
+    entries = xs_directory(state->xenstore, 0, path, &num);
+    if (entries == NULL)
+        return;
+
+    for (i = 0; i < num; i++) {
+        physmap = g_malloc(sizeof (XenPhysmap));
+        physmap->phys_offset = strtoull(entries[i], NULL, 16);
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->start_addr = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/size",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->size = strtoull(value, NULL, 16);
+        free(value);
+
+        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+    }
+    free(entries);
+    return;
+}
+
 int xen_hvm_init(void)
 {
     int i, rc;
@@ -998,6 +1059,7 @@ int xen_hvm_init(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
+    xen_read_physmap(state);
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqau-0000cZ-QW; Thu, 19 Jan 2012 11:55:52 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rnqat-0000bZ-8E
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326974143!9812435!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17491 invoked from network); 19 Jan 2012 11:55:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178190243"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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; Thu, 19 Jan 2012 06:55: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 q0JBtRJ2011858;
	Thu, 19 Jan 2012 03:55:36 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:20 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 507d93d..c830cb1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -253,6 +253,7 @@ static int xen_add_to_physmap(XenIOState *state,
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+    char path[80], value[17];
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -299,6 +300,22 @@ go_physmap:
                                    start_addr >> TARGET_PAGE_BITS,
                                    (start_addr + size) >> TARGET_PAGE_BITS,
                                    XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+
     return 0;
 }
 
@@ -926,6 +943,50 @@ int xen_init(void)
     return 0;
 }
 
+static void xen_read_physmap(XenIOState *state)
+{
+    XenPhysmap *physmap = NULL;
+    unsigned int len, num, i;
+    char path[80], *value = NULL;
+    char **entries = NULL;
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap", xen_domid);
+    entries = xs_directory(state->xenstore, 0, path, &num);
+    if (entries == NULL)
+        return;
+
+    for (i = 0; i < num; i++) {
+        physmap = g_malloc(sizeof (XenPhysmap));
+        physmap->phys_offset = strtoull(entries[i], NULL, 16);
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->start_addr = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/size",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->size = strtoull(value, NULL, 16);
+        free(value);
+
+        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+    }
+    free(entries);
+    return;
+}
+
 int xen_hvm_init(void)
 {
     int i, rc;
@@ -998,6 +1059,7 @@ int xen_hvm_init(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
+    xen_read_physmap(state);
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqay-0000dd-01; Thu, 19 Jan 2012 11:55: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 1Rnqav-0000bv-Ha
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326974143!9812435!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17626 invoked from network); 19 Jan 2012 11:55:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178190248"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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; Thu, 19 Jan 2012 06:55: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 q0JBtRJ1011858;
	Thu, 19 Jan 2012 03:55:34 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:19 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v3 4/6] cirrus_vga: do not reset videoram on
	resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Anthony PERARD <anthony.perard@citrix.com>

When resuming we shouldn't set the videoram to 0xff considering that we
are about to read it from the savefile.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index f7b1d3d..eec2fc0 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:
@@ -2760,9 +2761,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_INMIGRATE)) {
+        /* Win2K seems to assume that the pattern buffer is at 0xff
+           initially ! */
+        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    }
 
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11:56:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqay-0000dd-01; Thu, 19 Jan 2012 11:55: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 1Rnqav-0000bv-Ha
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:55:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1326974143!9812435!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17626 invoked from network); 19 Jan 2012 11:55:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 11:55:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178190248"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 06:55: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; Thu, 19 Jan 2012 06:55: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 q0JBtRJ1011858;
	Thu, 19 Jan 2012 03:55:34 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Thu, 19 Jan 2012 11:56:19 +0000
Message-ID: <1326974181-32511-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.1201191134350.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v3 4/6] cirrus_vga: do not reset videoram on
	resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Anthony PERARD <anthony.perard@citrix.com>

When resuming we shouldn't set the videoram to 0xff considering that we
are about to read it from the savefile.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index f7b1d3d..eec2fc0 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:
@@ -2760,9 +2761,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_INMIGRATE)) {
+        /* Win2K seems to assume that the pattern buffer is at 0xff
+           initially ! */
+        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    }
 
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11: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 1RnqbS-0000rP-RM; Thu, 19 Jan 2012 11:56:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RnqbR-0000pG-6d
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:56:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326974177!9615173!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 7915 invoked from network); 19 Jan 2012 11:56:18 -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; 19 Jan 2012 11:56:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnqbG-000HgP-G9; Thu, 19 Jan 2012 11:56:14 +0000
Date: Thu, 19 Jan 2012 11:56:13 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119115613.GD66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<e0d8333e4725eec0ff4d.1326682582@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e0d8333e4725eec0ff4d.1326682582@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 12] 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 21:56 -0500 on 15 Jan (1326664582), Andres Lagar-Cavilla wrote:
> 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 provides a grant ref
> and a version. Update interface to handle this case.

I'm not sure I understand the motivation.  Is the idea that some HVM
domUs have granted memory to, let's call it domS, and domS then notices
that the contents are the same and tells Xen to share the original
frames?

In any case, the interface change should have some docuentation to match
it. :)

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 2a4112172e44 -r e0d8333e4725 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -733,18 +733,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 2a4112172e44 -r e0d8333e4725 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 11:56:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 11: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 1RnqbS-0000rP-RM; Thu, 19 Jan 2012 11:56:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RnqbR-0000pG-6d
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 11:56:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1326974177!9615173!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 7915 invoked from network); 19 Jan 2012 11:56:18 -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; 19 Jan 2012 11:56:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnqbG-000HgP-G9; Thu, 19 Jan 2012 11:56:14 +0000
Date: Thu, 19 Jan 2012 11:56:13 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119115613.GD66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<e0d8333e4725eec0ff4d.1326682582@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e0d8333e4725eec0ff4d.1326682582@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 12] 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 21:56 -0500 on 15 Jan (1326664582), Andres Lagar-Cavilla wrote:
> 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 provides a grant ref
> and a version. Update interface to handle this case.

I'm not sure I understand the motivation.  Is the idea that some HVM
domUs have granted memory to, let's call it domS, and domS then notices
that the contents are the same and tells Xen to share the original
frames?

In any case, the interface change should have some docuentation to match
it. :)

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> 
> diff -r 2a4112172e44 -r e0d8333e4725 xen/arch/x86/mm/mem_sharing.c
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -733,18 +733,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 2a4112172e44 -r e0d8333e4725 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:11:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqpr-0002NH-Me; Thu, 19 Jan 2012 12:11:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rnqpq-0002NB-2C
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:11:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326975036!56630374!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 919 invoked from network); 19 Jan 2012 12:10:37 -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 Jan 2012 12:10:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10140762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:11:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 12:11:12 +0000
Date: Thu, 19 Jan 2012 12:12:03 +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.1201191204370.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] libxl: save additional info to the qemu
	chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces an optional callback argument to
xc_domain_restore that can be used by toolstacks to restore the qemu
state (and whatever else is present in the qemu chunk) as they see fit.
The callback is used by libxl to restore some additional information
from the qemu chunk (saving the qemu chunk is already fully handled by
libxl).


Stefano Stabellini (3):
      libxc: add a callback to xc_domain_restore
      libxl: extract the qemu state file from the save image
      libxl: introduce QEMU_HEADER

 tools/libxc/xc_domain_restore.c |   19 ++++--
 tools/libxc/xenguest.h          |   17 ++++-
 tools/libxl/libxl_dm.c          |    5 ++
 tools/libxl/libxl_dom.c         |  142 +++++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h    |    2 +
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 175 insertions(+), 13 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:11:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:11:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqpr-0002NH-Me; Thu, 19 Jan 2012 12:11:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rnqpq-0002NB-2C
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:11:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1326975036!56630374!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 919 invoked from network); 19 Jan 2012 12:10:37 -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 Jan 2012 12:10:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10140762"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:11:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 12:11:12 +0000
Date: Thu, 19 Jan 2012 12:12:03 +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.1201191204370.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] libxl: save additional info to the qemu
	chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces an optional callback argument to
xc_domain_restore that can be used by toolstacks to restore the qemu
state (and whatever else is present in the qemu chunk) as they see fit.
The callback is used by libxl to restore some additional information
from the qemu chunk (saving the qemu chunk is already fully handled by
libxl).


Stefano Stabellini (3):
      libxc: add a callback to xc_domain_restore
      libxl: extract the qemu state file from the save image
      libxl: introduce QEMU_HEADER

 tools/libxc/xc_domain_restore.c |   19 ++++--
 tools/libxc/xenguest.h          |   17 ++++-
 tools/libxl/libxl_dm.c          |    5 ++
 tools/libxl/libxl_dom.c         |  142 +++++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h    |    2 +
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 175 insertions(+), 13 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:12:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqqy-0002S0-Ha; Thu, 19 Jan 2012 12:12: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 1Rnqqx-0002Rg-Bq
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326975123!49424948!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10293 invoked from network); 19 Jan 2012 12:12:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 12:12:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21053598"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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; Thu, 19 Jan 2012 07:12: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 q0JCC9DU012373;
	Thu, 19 Jan 2012 04:12:13 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:01 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: introduce QEMU_HEADER
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new QEMU_HEADER stored in the Qemu chunk right after the
QEMU_SIGNATURE and record length, before the Qemu state, to preserve the
physmap informations written by Qemu on xenstore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |  104 ++++++++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f33e572..0f3d0c3 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -359,9 +359,47 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
     libxl__gc *gc = (libxl__gc *)arg->gc;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     uint32_t domid = arg->domid;
-    int fd2 = -1, ret = 0;
+    int fd2 = -1, ret = 0, i = 0;
     const char *filename;
+    uint8_t *ptr = buf;
+    uint32_t count = 0;
+    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
+    uint32_t header_size = 0;
+
+    if (strncmp((char *)ptr, QEMU_HEADER, size))
+        goto no_header;
+
+    ptr += sizeof(QEMU_HEADER);
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+    header_size = sizeof(QEMU_HEADER) + sizeof(count) + count * sizeof(uint64_t) * 3;
+    size -= header_size;
+ 
+    for (i = 0; i < count; i++) {
+        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&size_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
+        if (ret) {
+            ptr = buf + header_size;
+            break;
+        }
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, phys_offset_v), "%"PRIx64, size_v);
+        if (ret) {
+            ptr = buf + header_size;
+            break;
+        }
+    }
 
+no_header:
     filename = libxl__device_model_restorefile(gc, domid);
     fd2 = open(filename, O_WRONLY|O_CREAT);
     if (fd2 < 0) {
@@ -370,7 +408,7 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
     }
 
     ret = libxl_write_exactly(
-            ctx, fd2, buf, size, "saved-state file", "qemu state");
+            ctx, fd2, ptr, size, "saved-state file", "qemu state");
     if (ret)
         goto out;
     ret = 0;
@@ -642,11 +680,61 @@ out:
     return rc;
 }
 
+static int libxl__domain_save_qemu_header(libxl__gc *gc, uint32_t domid,
+                                          int fd, char **buf)
+{
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL;
+    int len = 0, i = 0;
+    unsigned int num = 0;
+    uint32_t count = 0;
+    char *ptr = NULL, **entries = NULL;
+    uint64_t val = 0;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    len = sizeof(QEMU_HEADER) + sizeof(count) + count * (sizeof(val) * 3);
+    *buf = libxl__calloc(gc, 1, len);
+    ptr = *buf;
+
+    strcpy(ptr, QEMU_HEADER);
+    ptr += sizeof(QEMU_HEADER);
+
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return 0;
+
+        val = strtoll(phys_offset, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(start_addr, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(size, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+    }
+
+    return len;
+}
+
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
-    char buf[1024];
+    int ret, fd2 = -1, c, len;
+    char buf[1024], *buf2;
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
@@ -687,7 +775,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         goto out;
     }
 
-    qemu_state_len = st.st_size;
+    len = libxl__domain_save_qemu_header(gc, domid, fd, &buf2);
+    qemu_state_len = st.st_size + len;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
     ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
@@ -700,6 +789,11 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
     if (ret)
         goto out;
 
+    ret = libxl_write_exactly(ctx, fd, buf2, len,
+                            "saved-state file", "saved-state qemu header");
+    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");
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7f7578a..01f866f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -57,6 +57,7 @@
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
+#define QEMU_HEADER "DeviceModelHeader0001"
 #define STUBDOM_CONSOLE_LOGGING 0
 #define STUBDOM_CONSOLE_SAVE 1
 #define STUBDOM_CONSOLE_RESTORE 2
-- 
1.7.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 Jan 19 12:12:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqqy-0002S0-Ha; Thu, 19 Jan 2012 12:12: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 1Rnqqx-0002Rg-Bq
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326975123!49424948!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10293 invoked from network); 19 Jan 2012 12:12:04 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 12:12:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21053598"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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; Thu, 19 Jan 2012 07:12: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 q0JCC9DU012373;
	Thu, 19 Jan 2012 04:12:13 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:01 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: introduce QEMU_HEADER
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new QEMU_HEADER stored in the Qemu chunk right after the
QEMU_SIGNATURE and record length, before the Qemu state, to preserve the
physmap informations written by Qemu on xenstore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |  104 ++++++++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f33e572..0f3d0c3 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -359,9 +359,47 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
     libxl__gc *gc = (libxl__gc *)arg->gc;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     uint32_t domid = arg->domid;
-    int fd2 = -1, ret = 0;
+    int fd2 = -1, ret = 0, i = 0;
     const char *filename;
+    uint8_t *ptr = buf;
+    uint32_t count = 0;
+    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
+    uint32_t header_size = 0;
+
+    if (strncmp((char *)ptr, QEMU_HEADER, size))
+        goto no_header;
+
+    ptr += sizeof(QEMU_HEADER);
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+    header_size = sizeof(QEMU_HEADER) + sizeof(count) + count * sizeof(uint64_t) * 3;
+    size -= header_size;
+ 
+    for (i = 0; i < count; i++) {
+        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&size_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
+        if (ret) {
+            ptr = buf + header_size;
+            break;
+        }
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, phys_offset_v), "%"PRIx64, size_v);
+        if (ret) {
+            ptr = buf + header_size;
+            break;
+        }
+    }
 
+no_header:
     filename = libxl__device_model_restorefile(gc, domid);
     fd2 = open(filename, O_WRONLY|O_CREAT);
     if (fd2 < 0) {
@@ -370,7 +408,7 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
     }
 
     ret = libxl_write_exactly(
-            ctx, fd2, buf, size, "saved-state file", "qemu state");
+            ctx, fd2, ptr, size, "saved-state file", "qemu state");
     if (ret)
         goto out;
     ret = 0;
@@ -642,11 +680,61 @@ out:
     return rc;
 }
 
+static int libxl__domain_save_qemu_header(libxl__gc *gc, uint32_t domid,
+                                          int fd, char **buf)
+{
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL;
+    int len = 0, i = 0;
+    unsigned int num = 0;
+    uint32_t count = 0;
+    char *ptr = NULL, **entries = NULL;
+    uint64_t val = 0;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    len = sizeof(QEMU_HEADER) + sizeof(count) + count * (sizeof(val) * 3);
+    *buf = libxl__calloc(gc, 1, len);
+    ptr = *buf;
+
+    strcpy(ptr, QEMU_HEADER);
+    ptr += sizeof(QEMU_HEADER);
+
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return 0;
+
+        val = strtoll(phys_offset, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(start_addr, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(size, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+    }
+
+    return len;
+}
+
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
-    char buf[1024];
+    int ret, fd2 = -1, c, len;
+    char buf[1024], *buf2;
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
@@ -687,7 +775,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         goto out;
     }
 
-    qemu_state_len = st.st_size;
+    len = libxl__domain_save_qemu_header(gc, domid, fd, &buf2);
+    qemu_state_len = st.st_size + len;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
     ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
@@ -700,6 +789,11 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
     if (ret)
         goto out;
 
+    ret = libxl_write_exactly(ctx, fd, buf2, len,
+                            "saved-state file", "saved-state qemu header");
+    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");
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7f7578a..01f866f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -57,6 +57,7 @@
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
+#define QEMU_HEADER "DeviceModelHeader0001"
 #define STUBDOM_CONSOLE_LOGGING 0
 #define STUBDOM_CONSOLE_SAVE 1
 #define STUBDOM_CONSOLE_RESTORE 2
-- 
1.7.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 Jan 19 12:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqr4-0002Tw-U5; Thu, 19 Jan 2012 12:12: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 1Rnqr3-0002Rq-1w
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326975123!49424948!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10370 invoked from network); 19 Jan 2012 12:12:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 12:12:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21053599"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12:26 -0500
Received: from smtp01.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, 19 Jan 2012 07:12: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 q0JCC9DW012373;
	Thu, 19 Jan 2012 04:12:15 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:03 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl: extract the qemu state file from the
	save 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dm.c       |    5 +++++
 tools/libxl/libxl_dom.c      |   42 +++++++++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |    1 +
 3 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..3f19150 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -41,6 +41,11 @@ 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__device_model_restorefile(libxl__gc *gc, uint32_t domid)
+{
+    return libxl__sprintf(gc, "/var/lib/xen/qemu-resume.%d", domid);
+}
+
 const char *libxl__domain_device_model(libxl__gc *gc,
                                        libxl_device_model_info *info)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fd2b051..f33e572 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -347,6 +347,40 @@ out:
     return rc;
 }
 
+struct restore_callbacks_arg {
+    libxl__gc *gc;
+    uint32_t domid;
+};
+
+static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
+                                              void *data)
+{
+    struct restore_callbacks_arg *arg = data;
+    libxl__gc *gc = (libxl__gc *)arg->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    uint32_t domid = arg->domid;
+    int fd2 = -1, ret = 0;
+    const char *filename;
+
+    filename = libxl__device_model_restorefile(gc, domid);
+    fd2 = open(filename, O_WRONLY|O_CREAT);
+    if (fd2 < 0) {
+        ret = fd2;
+        goto out;
+    }
+
+    ret = libxl_write_exactly(
+            ctx, fd2, buf, size, "saved-state file", "qemu state");
+    if (ret)
+        goto out;
+    ret = 0;
+
+out:
+    if (fd2 > 0)
+        close(fd2);
+    return ret;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -356,11 +390,17 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
+    struct restore_callbacks_arg arg;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        arg.domid = domid;
+        arg.gc = gc;
+        callbacks.extract_qemu_savestate = libxl__domain_restore_device_model;
+        callbacks.data = &arg;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -373,7 +413,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages, NULL);
+                           hvm, pae, superpages, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa7fb16..7f7578a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -247,6 +247,7 @@ _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 const char *libxl__device_model_restorefile(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);
 
-- 
1.7.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 Jan 19 12:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqr4-0002Tw-U5; Thu, 19 Jan 2012 12:12: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 1Rnqr3-0002Rq-1w
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1326975123!49424948!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10370 invoked from network); 19 Jan 2012 12:12:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 12:12:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="21053599"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12:26 -0500
Received: from smtp01.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, 19 Jan 2012 07:12: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 q0JCC9DW012373;
	Thu, 19 Jan 2012 04:12:15 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:03 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl: extract the qemu state file from the
	save 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dm.c       |    5 +++++
 tools/libxl/libxl_dom.c      |   42 +++++++++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |    1 +
 3 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..3f19150 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -41,6 +41,11 @@ 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__device_model_restorefile(libxl__gc *gc, uint32_t domid)
+{
+    return libxl__sprintf(gc, "/var/lib/xen/qemu-resume.%d", domid);
+}
+
 const char *libxl__domain_device_model(libxl__gc *gc,
                                        libxl_device_model_info *info)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fd2b051..f33e572 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -347,6 +347,40 @@ out:
     return rc;
 }
 
+struct restore_callbacks_arg {
+    libxl__gc *gc;
+    uint32_t domid;
+};
+
+static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
+                                              void *data)
+{
+    struct restore_callbacks_arg *arg = data;
+    libxl__gc *gc = (libxl__gc *)arg->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    uint32_t domid = arg->domid;
+    int fd2 = -1, ret = 0;
+    const char *filename;
+
+    filename = libxl__device_model_restorefile(gc, domid);
+    fd2 = open(filename, O_WRONLY|O_CREAT);
+    if (fd2 < 0) {
+        ret = fd2;
+        goto out;
+    }
+
+    ret = libxl_write_exactly(
+            ctx, fd2, buf, size, "saved-state file", "qemu state");
+    if (ret)
+        goto out;
+    ret = 0;
+
+out:
+    if (fd2 > 0)
+        close(fd2);
+    return ret;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -356,11 +390,17 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
+    struct restore_callbacks_arg arg;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        arg.domid = domid;
+        arg.gc = gc;
+        callbacks.extract_qemu_savestate = libxl__domain_restore_device_model;
+        callbacks.data = &arg;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -373,7 +413,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages, NULL);
+                           hvm, pae, superpages, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa7fb16..7f7578a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -247,6 +247,7 @@ _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 const char *libxl__device_model_restorefile(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);
 
-- 
1.7.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 Jan 19 12:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqr3-0002TG-At; Thu, 19 Jan 2012 12:12: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 1Rnqr2-0002Ri-Be
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326975137!11556538!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9375 invoked from network); 19 Jan 2012 12:12:25 -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;
	19 Jan 2012 12:12:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178193283"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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, 19 Jan 2012 07:12:25 -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 q0JCC9DV012373;
	Thu, 19 Jan 2012 04:12:14 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:02 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxc: add a callback to xc_domain_restore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a callback argument to xc_domain_restore, so that the caller
can restore the Qemu state file by itself.
If the callback is NULL, libxc will take care of dumping the qemu
state file as usual.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   19 ++++++++++++++-----
 tools/libxc/xenguest.h          |   17 ++++++++++++++---
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    3 ++-
 4 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 14451d1..fdc3483 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1248,7 +1248,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 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,
+                      struct restore_callbacks* callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1976,10 +1977,18 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
-    /* Dump the QEMU state to a state file for QEMU to load */
-    if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
-        PERROR("Error dumping QEMU state to file");
-        goto out;
+    if (callbacks == NULL || callbacks->extract_qemu_savestate == NULL) {
+        /* Dump the QEMU state to a state file for QEMU to load */
+        if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
+            PERROR("Error dumping QEMU state to file");
+            goto out;
+        }
+    } else {
+        if ( callbacks->extract_qemu_savestate(tailbuf.u.hvm.qemubuf,
+                    tailbuf.u.hvm.qemubufsize, callbacks->data) ) {
+            PERROR("Error calling extract_qemu_savestate");
+            goto out;
+        }
     }
 
     /* These comms pages need to be zeroed at the start of day */
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 4475ee9..9447412 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -61,6 +61,15 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    struct save_callbacks* callbacks, int hvm);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to extract the qemu save state */
+    int (*extract_qemu_savestate)(uint8_t *buf, uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -72,15 +81,17 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @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 callbacks non-NULL to receive a callback to extract the qemu state
  * @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,
+                      struct restore_callbacks *callbacks);
 /**
- * xc_domain_restore writes a file to disk that contains the device
- * model saved state.
+ * If callbacks is NULL, xc_domain_restore writes a file to disk that
+ * contains the device model saved state.
  * The pathname of this file is XC_DEVICE_MODEL_RESTORE_FILE; The domid
  * of the new domain is automatically appended to the filename,
  * separated by a ".".
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..fd2b051 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -373,7 +373,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     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, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 985cbec..eb1d31c 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -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,
+                            NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqqx-0002Rj-4u; Thu, 19 Jan 2012 12:12:27 +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 1Rnqqv-0002RG-FG
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326975137!11556538!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8799 invoked from network); 19 Jan 2012 12:12:19 -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;
	19 Jan 2012 12:12:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178193265"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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, 19 Jan 2012 07:12: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 q0JCC9DS012373;
	Thu, 19 Jan 2012 04:12:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:12:59 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxc: add a callback to xc_domain_restore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a callback argument to xc_domain_restore, so that the caller
can restore the Qemu state file by itself.
If the callback is NULL, libxc will take care of dumping the qemu
state file as usual.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   19 ++++++++++++++-----
 tools/libxc/xenguest.h          |   17 ++++++++++++++---
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    3 ++-
 4 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 14451d1..fdc3483 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1248,7 +1248,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 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,
+                      struct restore_callbacks* callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1976,10 +1977,18 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
-    /* Dump the QEMU state to a state file for QEMU to load */
-    if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
-        PERROR("Error dumping QEMU state to file");
-        goto out;
+    if (callbacks == NULL || callbacks->extract_qemu_savestate == NULL) {
+        /* Dump the QEMU state to a state file for QEMU to load */
+        if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
+            PERROR("Error dumping QEMU state to file");
+            goto out;
+        }
+    } else {
+        if ( callbacks->extract_qemu_savestate(tailbuf.u.hvm.qemubuf,
+                    tailbuf.u.hvm.qemubufsize, callbacks->data) ) {
+            PERROR("Error calling extract_qemu_savestate");
+            goto out;
+        }
     }
 
     /* These comms pages need to be zeroed at the start of day */
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 4475ee9..9447412 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -61,6 +61,15 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    struct save_callbacks* callbacks, int hvm);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to extract the qemu save state */
+    int (*extract_qemu_savestate)(uint8_t *buf, uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -72,15 +81,17 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @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 callbacks non-NULL to receive a callback to extract the qemu state
  * @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,
+                      struct restore_callbacks *callbacks);
 /**
- * xc_domain_restore writes a file to disk that contains the device
- * model saved state.
+ * If callbacks is NULL, xc_domain_restore writes a file to disk that
+ * contains the device model saved state.
  * The pathname of this file is XC_DEVICE_MODEL_RESTORE_FILE; The domid
  * of the new domain is automatically appended to the filename,
  * separated by a ".".
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..fd2b051 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -373,7 +373,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     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, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 985cbec..eb1d31c 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -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,
+                            NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqr3-0002TG-At; Thu, 19 Jan 2012 12:12: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 1Rnqr2-0002Ri-Be
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326975137!11556538!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9375 invoked from network); 19 Jan 2012 12:12:25 -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;
	19 Jan 2012 12:12:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178193283"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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, 19 Jan 2012 07:12:25 -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 q0JCC9DV012373;
	Thu, 19 Jan 2012 04:12:14 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:02 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxc: add a callback to xc_domain_restore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a callback argument to xc_domain_restore, so that the caller
can restore the Qemu state file by itself.
If the callback is NULL, libxc will take care of dumping the qemu
state file as usual.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   19 ++++++++++++++-----
 tools/libxc/xenguest.h          |   17 ++++++++++++++---
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    3 ++-
 4 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 14451d1..fdc3483 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1248,7 +1248,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 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,
+                      struct restore_callbacks* callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1976,10 +1977,18 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
-    /* Dump the QEMU state to a state file for QEMU to load */
-    if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
-        PERROR("Error dumping QEMU state to file");
-        goto out;
+    if (callbacks == NULL || callbacks->extract_qemu_savestate == NULL) {
+        /* Dump the QEMU state to a state file for QEMU to load */
+        if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
+            PERROR("Error dumping QEMU state to file");
+            goto out;
+        }
+    } else {
+        if ( callbacks->extract_qemu_savestate(tailbuf.u.hvm.qemubuf,
+                    tailbuf.u.hvm.qemubufsize, callbacks->data) ) {
+            PERROR("Error calling extract_qemu_savestate");
+            goto out;
+        }
     }
 
     /* These comms pages need to be zeroed at the start of day */
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 4475ee9..9447412 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -61,6 +61,15 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    struct save_callbacks* callbacks, int hvm);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to extract the qemu save state */
+    int (*extract_qemu_savestate)(uint8_t *buf, uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -72,15 +81,17 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @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 callbacks non-NULL to receive a callback to extract the qemu state
  * @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,
+                      struct restore_callbacks *callbacks);
 /**
- * xc_domain_restore writes a file to disk that contains the device
- * model saved state.
+ * If callbacks is NULL, xc_domain_restore writes a file to disk that
+ * contains the device model saved state.
  * The pathname of this file is XC_DEVICE_MODEL_RESTORE_FILE; The domid
  * of the new domain is automatically appended to the filename,
  * separated by a ".".
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..fd2b051 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -373,7 +373,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     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, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 985cbec..eb1d31c 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -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,
+                            NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:12:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqqx-0002Rj-4u; Thu, 19 Jan 2012 12:12:27 +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 1Rnqqv-0002RG-FG
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326975137!11556538!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8799 invoked from network); 19 Jan 2012 12:12:19 -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;
	19 Jan 2012 12:12:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178193265"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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, 19 Jan 2012 07:12: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 q0JCC9DS012373;
	Thu, 19 Jan 2012 04:12:10 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:12:59 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] libxc: add a callback to xc_domain_restore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a callback argument to xc_domain_restore, so that the caller
can restore the Qemu state file by itself.
If the callback is NULL, libxc will take care of dumping the qemu
state file as usual.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   19 ++++++++++++++-----
 tools/libxc/xenguest.h          |   17 ++++++++++++++---
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    3 ++-
 4 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 14451d1..fdc3483 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1248,7 +1248,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 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,
+                      struct restore_callbacks* callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1976,10 +1977,18 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
-    /* Dump the QEMU state to a state file for QEMU to load */
-    if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
-        PERROR("Error dumping QEMU state to file");
-        goto out;
+    if (callbacks == NULL || callbacks->extract_qemu_savestate == NULL) {
+        /* Dump the QEMU state to a state file for QEMU to load */
+        if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
+            PERROR("Error dumping QEMU state to file");
+            goto out;
+        }
+    } else {
+        if ( callbacks->extract_qemu_savestate(tailbuf.u.hvm.qemubuf,
+                    tailbuf.u.hvm.qemubufsize, callbacks->data) ) {
+            PERROR("Error calling extract_qemu_savestate");
+            goto out;
+        }
     }
 
     /* These comms pages need to be zeroed at the start of day */
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 4475ee9..9447412 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -61,6 +61,15 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    struct save_callbacks* callbacks, int hvm);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to extract the qemu save state */
+    int (*extract_qemu_savestate)(uint8_t *buf, uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -72,15 +81,17 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @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 callbacks non-NULL to receive a callback to extract the qemu state
  * @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,
+                      struct restore_callbacks *callbacks);
 /**
- * xc_domain_restore writes a file to disk that contains the device
- * model saved state.
+ * If callbacks is NULL, xc_domain_restore writes a file to disk that
+ * contains the device model saved state.
  * The pathname of this file is XC_DEVICE_MODEL_RESTORE_FILE; The domid
  * of the new domain is automatically appended to the filename,
  * separated by a ".".
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..fd2b051 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -373,7 +373,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     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, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 985cbec..eb1d31c 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -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,
+                            NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:12:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqr5-0002UB-AK; Thu, 19 Jan 2012 12:12:35 +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 1Rnqr4-0002S6-Aj
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326975137!11556538!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9534 invoked from network); 19 Jan 2012 12:12:28 -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;
	19 Jan 2012 12:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178193289"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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; Thu, 19 Jan 2012 07:12: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 q0JCC9DX012373;
	Thu, 19 Jan 2012 04:12:16 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:04 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: introduce QEMU_HEADER
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new QEMU_HEADER stored in the Qemu chunk right after the
QEMU_SIGNATURE and record length, before the Qemu state, to preserve the
physmap informations written by Qemu on xenstore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |  104 ++++++++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f33e572..0f3d0c3 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -359,9 +359,47 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
     libxl__gc *gc = (libxl__gc *)arg->gc;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     uint32_t domid = arg->domid;
-    int fd2 = -1, ret = 0;
+    int fd2 = -1, ret = 0, i = 0;
     const char *filename;
+    uint8_t *ptr = buf;
+    uint32_t count = 0;
+    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
+    uint32_t header_size = 0;
+
+    if (strncmp((char *)ptr, QEMU_HEADER, size))
+        goto no_header;
+
+    ptr += sizeof(QEMU_HEADER);
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+    header_size = sizeof(QEMU_HEADER) + sizeof(count) + count * sizeof(uint64_t) * 3;
+    size -= header_size;
+ 
+    for (i = 0; i < count; i++) {
+        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&size_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
+        if (ret) {
+            ptr = buf + header_size;
+            break;
+        }
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, phys_offset_v), "%"PRIx64, size_v);
+        if (ret) {
+            ptr = buf + header_size;
+            break;
+        }
+    }
 
+no_header:
     filename = libxl__device_model_restorefile(gc, domid);
     fd2 = open(filename, O_WRONLY|O_CREAT);
     if (fd2 < 0) {
@@ -370,7 +408,7 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
     }
 
     ret = libxl_write_exactly(
-            ctx, fd2, buf, size, "saved-state file", "qemu state");
+            ctx, fd2, ptr, size, "saved-state file", "qemu state");
     if (ret)
         goto out;
     ret = 0;
@@ -642,11 +680,61 @@ out:
     return rc;
 }
 
+static int libxl__domain_save_qemu_header(libxl__gc *gc, uint32_t domid,
+                                          int fd, char **buf)
+{
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL;
+    int len = 0, i = 0;
+    unsigned int num = 0;
+    uint32_t count = 0;
+    char *ptr = NULL, **entries = NULL;
+    uint64_t val = 0;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    len = sizeof(QEMU_HEADER) + sizeof(count) + count * (sizeof(val) * 3);
+    *buf = libxl__calloc(gc, 1, len);
+    ptr = *buf;
+
+    strcpy(ptr, QEMU_HEADER);
+    ptr += sizeof(QEMU_HEADER);
+
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return 0;
+
+        val = strtoll(phys_offset, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(start_addr, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(size, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+    }
+
+    return len;
+}
+
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
-    char buf[1024];
+    int ret, fd2 = -1, c, len;
+    char buf[1024], *buf2;
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
@@ -687,7 +775,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         goto out;
     }
 
-    qemu_state_len = st.st_size;
+    len = libxl__domain_save_qemu_header(gc, domid, fd, &buf2);
+    qemu_state_len = st.st_size + len;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
     ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
@@ -700,6 +789,11 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
     if (ret)
         goto out;
 
+    ret = libxl_write_exactly(ctx, fd, buf2, len,
+                            "saved-state file", "saved-state qemu header");
+    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");
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7f7578a..01f866f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -57,6 +57,7 @@
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
+#define QEMU_HEADER "DeviceModelHeader0001"
 #define STUBDOM_CONSOLE_LOGGING 0
 #define STUBDOM_CONSOLE_SAVE 1
 #define STUBDOM_CONSOLE_RESTORE 2
-- 
1.7.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 Jan 19 12:12:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqr5-0002UB-AK; Thu, 19 Jan 2012 12:12:35 +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 1Rnqr4-0002S6-Aj
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326975137!11556538!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9534 invoked from network); 19 Jan 2012 12:12:28 -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;
	19 Jan 2012 12:12:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178193289"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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; Thu, 19 Jan 2012 07:12: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 q0JCC9DX012373;
	Thu, 19 Jan 2012 04:12:16 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:04 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] libxl: introduce QEMU_HEADER
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new QEMU_HEADER stored in the Qemu chunk right after the
QEMU_SIGNATURE and record length, before the Qemu state, to preserve the
physmap informations written by Qemu on xenstore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |  104 ++++++++++++++++++++++++++++++++++++++++--
 tools/libxl/libxl_internal.h |    1 +
 2 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index f33e572..0f3d0c3 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -359,9 +359,47 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
     libxl__gc *gc = (libxl__gc *)arg->gc;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     uint32_t domid = arg->domid;
-    int fd2 = -1, ret = 0;
+    int fd2 = -1, ret = 0, i = 0;
     const char *filename;
+    uint8_t *ptr = buf;
+    uint32_t count = 0;
+    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
+    uint32_t header_size = 0;
+
+    if (strncmp((char *)ptr, QEMU_HEADER, size))
+        goto no_header;
+
+    ptr += sizeof(QEMU_HEADER);
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+    header_size = sizeof(QEMU_HEADER) + sizeof(count) + count * sizeof(uint64_t) * 3;
+    size -= header_size;
+ 
+    for (i = 0; i < count; i++) {
+        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&size_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
+        if (ret) {
+            ptr = buf + header_size;
+            break;
+        }
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, phys_offset_v), "%"PRIx64, size_v);
+        if (ret) {
+            ptr = buf + header_size;
+            break;
+        }
+    }
 
+no_header:
     filename = libxl__device_model_restorefile(gc, domid);
     fd2 = open(filename, O_WRONLY|O_CREAT);
     if (fd2 < 0) {
@@ -370,7 +408,7 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
     }
 
     ret = libxl_write_exactly(
-            ctx, fd2, buf, size, "saved-state file", "qemu state");
+            ctx, fd2, ptr, size, "saved-state file", "qemu state");
     if (ret)
         goto out;
     ret = 0;
@@ -642,11 +680,61 @@ out:
     return rc;
 }
 
+static int libxl__domain_save_qemu_header(libxl__gc *gc, uint32_t domid,
+                                          int fd, char **buf)
+{
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL;
+    int len = 0, i = 0;
+    unsigned int num = 0;
+    uint32_t count = 0;
+    char *ptr = NULL, **entries = NULL;
+    uint64_t val = 0;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    len = sizeof(QEMU_HEADER) + sizeof(count) + count * (sizeof(val) * 3);
+    *buf = libxl__calloc(gc, 1, len);
+    ptr = *buf;
+
+    strcpy(ptr, QEMU_HEADER);
+    ptr += sizeof(QEMU_HEADER);
+
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return 0;
+
+        val = strtoll(phys_offset, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(start_addr, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(size, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+    }
+
+    return len;
+}
+
 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
-    int ret, fd2 = -1, c;
-    char buf[1024];
+    int ret, fd2 = -1, c, len;
+    char buf[1024], *buf2;
     const char *filename = libxl__device_model_savefile(gc, domid);
     struct stat st;
     uint32_t qemu_state_len;
@@ -687,7 +775,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
         goto out;
     }
 
-    qemu_state_len = st.st_size;
+    len = libxl__domain_save_qemu_header(gc, domid, fd, &buf2);
+    qemu_state_len = st.st_size + len;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
     ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
@@ -700,6 +789,11 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
     if (ret)
         goto out;
 
+    ret = libxl_write_exactly(ctx, fd, buf2, len,
+                            "saved-state file", "saved-state qemu header");
+    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");
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7f7578a..01f866f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -57,6 +57,7 @@
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
+#define QEMU_HEADER "DeviceModelHeader0001"
 #define STUBDOM_CONSOLE_LOGGING 0
 #define STUBDOM_CONSOLE_SAVE 1
 #define STUBDOM_CONSOLE_RESTORE 2
-- 
1.7.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 Jan 19 12:12:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqr1-0002Se-US; Thu, 19 Jan 2012 12:12:31 +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 1Rnqr0-0002RV-3c
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326975137!11556538!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9249 invoked from network); 19 Jan 2012 12:12:23 -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;
	19 Jan 2012 12:12:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178193280"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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, 19 Jan 2012 07:12:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0JCC9DT012373;
	Thu, 19 Jan 2012 04:12:12 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:00 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl: extract the qemu state file from the
	save 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dm.c       |    5 +++++
 tools/libxl/libxl_dom.c      |   42 +++++++++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |    1 +
 3 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..3f19150 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -41,6 +41,11 @@ 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__device_model_restorefile(libxl__gc *gc, uint32_t domid)
+{
+    return libxl__sprintf(gc, "/var/lib/xen/qemu-resume.%d", domid);
+}
+
 const char *libxl__domain_device_model(libxl__gc *gc,
                                        libxl_device_model_info *info)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fd2b051..f33e572 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -347,6 +347,40 @@ out:
     return rc;
 }
 
+struct restore_callbacks_arg {
+    libxl__gc *gc;
+    uint32_t domid;
+};
+
+static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
+                                              void *data)
+{
+    struct restore_callbacks_arg *arg = data;
+    libxl__gc *gc = (libxl__gc *)arg->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    uint32_t domid = arg->domid;
+    int fd2 = -1, ret = 0;
+    const char *filename;
+
+    filename = libxl__device_model_restorefile(gc, domid);
+    fd2 = open(filename, O_WRONLY|O_CREAT);
+    if (fd2 < 0) {
+        ret = fd2;
+        goto out;
+    }
+
+    ret = libxl_write_exactly(
+            ctx, fd2, buf, size, "saved-state file", "qemu state");
+    if (ret)
+        goto out;
+    ret = 0;
+
+out:
+    if (fd2 > 0)
+        close(fd2);
+    return ret;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -356,11 +390,17 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
+    struct restore_callbacks_arg arg;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        arg.domid = domid;
+        arg.gc = gc;
+        callbacks.extract_qemu_savestate = libxl__domain_restore_device_model;
+        callbacks.data = &arg;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -373,7 +413,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages, NULL);
+                           hvm, pae, superpages, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa7fb16..7f7578a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -247,6 +247,7 @@ _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 const char *libxl__device_model_restorefile(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);
 
-- 
1.7.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 Jan 19 12:12:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:12:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqr1-0002Se-US; Thu, 19 Jan 2012 12:12:31 +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 1Rnqr0-0002RV-3c
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:12:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326975137!11556538!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMzMyNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9249 invoked from network); 19 Jan 2012 12:12:23 -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;
	19 Jan 2012 12:12:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320642000"; d="scan'208";a="178193280"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 07:12: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, 19 Jan 2012 07:12:23 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0JCC9DT012373;
	Thu, 19 Jan 2012 04:12:12 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 12:13:00 +0000
Message-ID: <1326975184-458-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.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] libxl: extract the qemu state file from the
	save 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

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dm.c       |    5 +++++
 tools/libxl/libxl_dom.c      |   42 +++++++++++++++++++++++++++++++++++++++++-
 tools/libxl/libxl_internal.h |    1 +
 3 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 97d91b4..3f19150 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -41,6 +41,11 @@ 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__device_model_restorefile(libxl__gc *gc, uint32_t domid)
+{
+    return libxl__sprintf(gc, "/var/lib/xen/qemu-resume.%d", domid);
+}
+
 const char *libxl__domain_device_model(libxl__gc *gc,
                                        libxl_device_model_info *info)
 {
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fd2b051..f33e572 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -347,6 +347,40 @@ out:
     return rc;
 }
 
+struct restore_callbacks_arg {
+    libxl__gc *gc;
+    uint32_t domid;
+};
+
+static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
+                                              void *data)
+{
+    struct restore_callbacks_arg *arg = data;
+    libxl__gc *gc = (libxl__gc *)arg->gc;
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    uint32_t domid = arg->domid;
+    int fd2 = -1, ret = 0;
+    const char *filename;
+
+    filename = libxl__device_model_restorefile(gc, domid);
+    fd2 = open(filename, O_WRONLY|O_CREAT);
+    if (fd2 < 0) {
+        ret = fd2;
+        goto out;
+    }
+
+    ret = libxl_write_exactly(
+            ctx, fd2, buf, size, "saved-state file", "qemu state");
+    if (ret)
+        goto out;
+    ret = 0;
+
+out:
+    if (fd2 > 0)
+        close(fd2);
+    return ret;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -356,11 +390,17 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
+    struct restore_callbacks_arg arg;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        arg.domid = domid;
+        arg.gc = gc;
+        callbacks.extract_qemu_savestate = libxl__domain_restore_device_model;
+        callbacks.data = &arg;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -373,7 +413,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages, NULL);
+                           hvm, pae, superpages, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fa7fb16..7f7578a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -247,6 +247,7 @@ _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 const char *libxl__device_model_restorefile(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);
 
-- 
1.7.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 Jan 19 12:14:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12: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 1RnqsV-00031k-Um; Thu, 19 Jan 2012 12:14:03 +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 1RnqsU-000309-Jm
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:14:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326975236!9354840!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 32708 invoked from network); 19 Jan 2012 12:13:56 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 12:13:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnqsL-000HmX-9j; Thu, 19 Jan 2012 12:13:53 +0000
Date: Thu, 19 Jan 2012 12:13:53 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119121353.GE66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <11916fe20dd274ff370b.1326682583@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 12] 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

At 21:56 -0500 on 15 Jan (1326664583), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm.c             |   74 +-----------
>  xen/arch/x86/mm/mem_sharing.c |  257 ++++++++++++++++++++++++++++++++++++++---
>  xen/arch/x86/mm/mm-locks.h    |   15 +-
>  xen/include/asm-x86/mm.h      |   27 +++-
>  4 files changed, 275 insertions(+), 98 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.
> 
> The global lock remains for the benefit of the auditing code, and is
> thus enabled only as a compile-time option.

I think that having the audit-enabled config disable all the
fine-grained locking is asking for heisenbugs.  (But maybe that goes
away in your later RCU patch, which I've yet to read).

Otherwise, looks good.  Oh, and:

> +#if MEM_SHARING_AUDIT
>  /* Page-sharing lock (global) 
>   *
>   * A single global lock that protects the memory-sharing code's
>   * hash tables. */

This comment should probably have been updated in the patch that killed
the hash table. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:14:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12: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 1RnqsV-00031k-Um; Thu, 19 Jan 2012 12:14:03 +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 1RnqsU-000309-Jm
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:14:02 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1326975236!9354840!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 32708 invoked from network); 19 Jan 2012 12:13:56 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 12:13:56 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnqsL-000HmX-9j; Thu, 19 Jan 2012 12:13:53 +0000
Date: Thu, 19 Jan 2012 12:13:53 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119121353.GE66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <11916fe20dd274ff370b.1326682583@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 12] 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

At 21:56 -0500 on 15 Jan (1326664583), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm.c             |   74 +-----------
>  xen/arch/x86/mm/mem_sharing.c |  257 ++++++++++++++++++++++++++++++++++++++---
>  xen/arch/x86/mm/mm-locks.h    |   15 +-
>  xen/include/asm-x86/mm.h      |   27 +++-
>  4 files changed, 275 insertions(+), 98 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.
> 
> The global lock remains for the benefit of the auditing code, and is
> thus enabled only as a compile-time option.

I think that having the audit-enabled config disable all the
fine-grained locking is asking for heisenbugs.  (But maybe that goes
away in your later RCU patch, which I've yet to read).

Otherwise, looks good.  Oh, and:

> +#if MEM_SHARING_AUDIT
>  /* Page-sharing lock (global) 
>   *
>   * A single global lock that protects the memory-sharing code's
>   * hash tables. */

This comment should probably have been updated in the patch that killed
the hash table. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:14:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqse-00035A-D0; Thu, 19 Jan 2012 12:14: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 1Rnqsc-000329-92
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:14:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326975202!60895500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15558 invoked from network); 19 Jan 2012 12:13:22 -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;
	19 Jan 2012 12:13:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10140930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:14: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, 19 Jan 2012 12:14:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Thu, 19 Jan 2012 12:14:03 +0000
In-Reply-To: <6522ae36bc61cd461754.1326682591@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<6522ae36bc61cd461754.1326682591@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326975243.17599.74.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 11 of 12] 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 Mon, 2012-01-16 at 02:56 +0000, Andres Lagar-Cavilla wrote:
> docs/man/xl.pod.1           |  13 ++++++++
>  tools/libxl/libxl.c         |   2 +
>  tools/libxl/libxl_types.idl |   2 +
>  tools/libxl/xl.h            |   1 +
>  tools/libxl/xl_cmdimpl.c    |  66 +++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/xl_cmdtable.c   |   5 +++
>  6 files changed, 89 insertions(+), 0 deletions(-)
> 
> 
> Also add the global sharing statistics to the libxl physinfo.  This is a slight
> departure from libxc, but there's no reason libxl physinfo can't include extra
> bits of useful and relevant information.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r b596035ff0e2 -r 6522ae36bc61 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -410,6 +410,19 @@ Leave domain running after creating the 
>  
>  =back
>  
> +=item B<sharing> [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.
> +
> +=back
>  
>  =item B<shutdown> [I<OPTIONS>] I<domain-id>
>  
> diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2518,6 +2518,8 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
>      physinfo->total_pages = xcphysinfo.total_pages;
>      physinfo->free_pages = xcphysinfo.free_pages;
>      physinfo->scrub_pages = xcphysinfo.scrub_pages;
> +    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
> +    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
>      physinfo->nr_nodes = xcphysinfo.nr_nodes;
>      memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
>      physinfo->phys_cap = xcphysinfo.capabilities;
> diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -366,6 +366,8 @@ libxl_physinfo = Struct("physinfo", [
>      ("total_pages", uint64),
>      ("free_pages", uint64),
>      ("scrub_pages", uint64),
> +    ("sharing_freed_pages", uint64),
> +    ("sharing_used_frames", uint64),
>  
>      ("nr_nodes", uint32),
>      ("hw_cap", libxl_hwcap),
> diff -r b596035ff0e2 -r 6522ae36bc61 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 b596035ff0e2 -r 6522ae36bc61 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3693,6 +3693,8 @@ static void output_physinfo(void)
>          i = (1 << 20) / vinfo->pagesize;
>          printf("total_memory           : %"PRIu64"\n", info.total_pages / i);
>          printf("free_memory            : %"PRIu64"\n", info.free_pages / i);
> +        printf("sharing_freed_memory   : %"PRIu64"\n", info.sharing_freed_pages / i);
> +        printf("sharing_used_memory    : %"PRIu64"\n", info.sharing_used_frames / i);
>      }
>      if (!libxl_get_freecpus(ctx, &cpumap)) {
>          libxl_for_each_cpu(i, cpumap)
> @@ -3776,6 +3778,70 @@ int main_info(int argc, char **argv)
>      return 0;
>  }
>  
> +static void sharing(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);
> +    }
> +}
> +
> +int main_sharing(int argc, char **argv)
> +{
> +    int opt = 0;
> +    libxl_dominfo info_buf;
> +    libxl_dominfo *info, *info_free = NULL;
> +    int nb_domain, rc;
> +
> +    if ((opt = def_getopt(argc, argv, "", "sharing", 0)) != -1)
> +        return opt;
> +
> +    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(info, nb_domain);
> +
> +    if (info_free)
> +        free(info_free);
> +
> +    return 0;
> +}
> +
>  static int sched_credit_domain_get(
>      int domid, libxl_sched_credit *scinfo)
>  {
> diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -189,6 +189,11 @@ 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",
> +      "[Domain]", 
> +    },
>      { "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 Jan 19 12:14:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqse-00035A-D0; Thu, 19 Jan 2012 12:14: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 1Rnqsc-000329-92
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:14:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1326975202!60895500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15558 invoked from network); 19 Jan 2012 12:13:22 -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;
	19 Jan 2012 12:13:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10140930"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:14: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, 19 Jan 2012 12:14:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Thu, 19 Jan 2012 12:14:03 +0000
In-Reply-To: <6522ae36bc61cd461754.1326682591@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<6522ae36bc61cd461754.1326682591@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326975243.17599.74.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 11 of 12] 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 Mon, 2012-01-16 at 02:56 +0000, Andres Lagar-Cavilla wrote:
> docs/man/xl.pod.1           |  13 ++++++++
>  tools/libxl/libxl.c         |   2 +
>  tools/libxl/libxl_types.idl |   2 +
>  tools/libxl/xl.h            |   1 +
>  tools/libxl/xl_cmdimpl.c    |  66 +++++++++++++++++++++++++++++++++++++++++++++
>  tools/libxl/xl_cmdtable.c   |   5 +++
>  6 files changed, 89 insertions(+), 0 deletions(-)
> 
> 
> Also add the global sharing statistics to the libxl physinfo.  This is a slight
> departure from libxc, but there's no reason libxl physinfo can't include extra
> bits of useful and relevant information.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r b596035ff0e2 -r 6522ae36bc61 docs/man/xl.pod.1
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
> @@ -410,6 +410,19 @@ Leave domain running after creating the 
>  
>  =back
>  
> +=item B<sharing> [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.
> +
> +=back
>  
>  =item B<shutdown> [I<OPTIONS>] I<domain-id>
>  
> diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -2518,6 +2518,8 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
>      physinfo->total_pages = xcphysinfo.total_pages;
>      physinfo->free_pages = xcphysinfo.free_pages;
>      physinfo->scrub_pages = xcphysinfo.scrub_pages;
> +    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
> +    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
>      physinfo->nr_nodes = xcphysinfo.nr_nodes;
>      memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
>      physinfo->phys_cap = xcphysinfo.capabilities;
> diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -366,6 +366,8 @@ libxl_physinfo = Struct("physinfo", [
>      ("total_pages", uint64),
>      ("free_pages", uint64),
>      ("scrub_pages", uint64),
> +    ("sharing_freed_pages", uint64),
> +    ("sharing_used_frames", uint64),
>  
>      ("nr_nodes", uint32),
>      ("hw_cap", libxl_hwcap),
> diff -r b596035ff0e2 -r 6522ae36bc61 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 b596035ff0e2 -r 6522ae36bc61 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -3693,6 +3693,8 @@ static void output_physinfo(void)
>          i = (1 << 20) / vinfo->pagesize;
>          printf("total_memory           : %"PRIu64"\n", info.total_pages / i);
>          printf("free_memory            : %"PRIu64"\n", info.free_pages / i);
> +        printf("sharing_freed_memory   : %"PRIu64"\n", info.sharing_freed_pages / i);
> +        printf("sharing_used_memory    : %"PRIu64"\n", info.sharing_used_frames / i);
>      }
>      if (!libxl_get_freecpus(ctx, &cpumap)) {
>          libxl_for_each_cpu(i, cpumap)
> @@ -3776,6 +3778,70 @@ int main_info(int argc, char **argv)
>      return 0;
>  }
>  
> +static void sharing(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);
> +    }
> +}
> +
> +int main_sharing(int argc, char **argv)
> +{
> +    int opt = 0;
> +    libxl_dominfo info_buf;
> +    libxl_dominfo *info, *info_free = NULL;
> +    int nb_domain, rc;
> +
> +    if ((opt = def_getopt(argc, argv, "", "sharing", 0)) != -1)
> +        return opt;
> +
> +    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(info, nb_domain);
> +
> +    if (info_free)
> +        free(info_free);
> +
> +    return 0;
> +}
> +
>  static int sched_credit_domain_get(
>      int domid, libxl_sched_credit *scinfo)
>  {
> diff -r b596035ff0e2 -r 6522ae36bc61 tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c
> +++ b/tools/libxl/xl_cmdtable.c
> @@ -189,6 +189,11 @@ 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",
> +      "[Domain]", 
> +    },
>      { "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 Jan 19 12:18:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqwj-0003t2-8S; Thu, 19 Jan 2012 12:18:25 +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 1Rnqwh-0003so-Lf
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:18:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326975497!11527859!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 16460 invoked from network); 19 Jan 2012 12:18:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 12:18:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnqwa-000Ho8-Ht; Thu, 19 Jan 2012 12:18:16 +0000
Date: Thu, 19 Jan 2012 12:18:16 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119121816.GF66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<c906c616d5ace44de92d.1326682584@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c906c616d5ace44de92d.1326682584@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 12] x86/mm: Enforce lock ordering for
	sharing page locks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 21:56 -0500 on 15 Jan (1326664584), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  91 ++++++++++++++++++++++++++----------------
>  xen/arch/x86/mm/mm-locks.h    |  18 ++++++++-
>  xen/include/asm-x86/mm.h      |   3 +-
>  3 files changed, 76 insertions(+), 36 deletions(-)
> 
> 
> Use the ordering constructs in mm-locks.h to enforce an order
> for the p2m and page locks in the sharing code. Applies to either
> the global sharing lock (in audit mode) or the per page locks.

Good idea, though there'a rather a lot of passing stack pointers around
now.  Given that you should only ever be taking one of these paths at a
time, and you should never be waitq'd with a lock hels, maybe you could
just have a static per-pcpu pg_lock_data struct?

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 Jan 19 12:18:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:18:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnqwj-0003t2-8S; Thu, 19 Jan 2012 12:18:25 +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 1Rnqwh-0003so-Lf
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:18:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326975497!11527859!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 16460 invoked from network); 19 Jan 2012 12:18:17 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 12:18:17 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnqwa-000Ho8-Ht; Thu, 19 Jan 2012 12:18:16 +0000
Date: Thu, 19 Jan 2012 12:18:16 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119121816.GF66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<c906c616d5ace44de92d.1326682584@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <c906c616d5ace44de92d.1326682584@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 12] x86/mm: Enforce lock ordering for
	sharing page locks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 21:56 -0500 on 15 Jan (1326664584), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c |  91 ++++++++++++++++++++++++++----------------
>  xen/arch/x86/mm/mm-locks.h    |  18 ++++++++-
>  xen/include/asm-x86/mm.h      |   3 +-
>  3 files changed, 76 insertions(+), 36 deletions(-)
> 
> 
> Use the ordering constructs in mm-locks.h to enforce an order
> for the p2m and page locks in the sharing code. Applies to either
> the global sharing lock (in audit mode) or the per page locks.

Good idea, though there'a rather a lot of passing stack pointers around
now.  Given that you should only ever be taking one of these paths at a
time, and you should never be waitq'd with a lock hels, maybe you could
just have a static per-pcpu pg_lock_data struct?

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 Jan 19 12:25:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:25:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnr31-00049o-3d; Thu, 19 Jan 2012 12:24:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rnr2z-00049f-Kp
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:24:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326975887!11687784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31575 invoked from network); 19 Jan 2012 12:24:47 -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;
	19 Jan 2012 12:24:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10141379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12: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, 19 Jan 2012 12:24:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 12:24:47 +0000
In-Reply-To: <1326975184-458-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975184-458-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326975887.17599.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 3/3] libxl: introduce QEMU_HEADER
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 12:13 +0000, Stefano Stabellini wrote:
> Introduce a new QEMU_HEADER stored in the Qemu chunk right after the
> QEMU_SIGNATURE and record length, before the Qemu state, to preserve the
> physmap informations written by Qemu on xenstore.

I'm still of the opinion that this should be a new XC_SAVE_ID_*
(possibly from a new range reserved for toolstakc use) and
saved/restored via a separate callback from libxc.

The mess that is the tail of the save/restore protocol is pure
historical and for backwards compat, we should not be making it any
worse. An XC_SAVE_ID is exactly equivalent to adding something to the
tail but uses the extensibility mechanism which we have now built into
the protocol.

Ian.

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl_dom.c      |  104 ++++++++++++++++++++++++++++++++++++++++--
>  tools/libxl/libxl_internal.h |    1 +
>  2 files changed, 100 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index f33e572..0f3d0c3 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -359,9 +359,47 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
>      libxl__gc *gc = (libxl__gc *)arg->gc;
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      uint32_t domid = arg->domid;
> -    int fd2 = -1, ret = 0;
> +    int fd2 = -1, ret = 0, i = 0;
>      const char *filename;
> +    uint8_t *ptr = buf;
> +    uint32_t count = 0;
> +    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
> +    uint32_t header_size = 0;
> +
> +    if (strncmp((char *)ptr, QEMU_HEADER, size))
> +        goto no_header;
> +
> +    ptr += sizeof(QEMU_HEADER);
> +    memcpy(&count, ptr, sizeof(count));
> +    ptr += sizeof(count);
> +    header_size = sizeof(QEMU_HEADER) + sizeof(count) + count * sizeof(uint64_t) * 3;
> +    size -= header_size;
> + 
> +    for (i = 0; i < count; i++) {
> +        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +        memcpy(&size_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
> +                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
> +        if (ret) {
> +            ptr = buf + header_size;
> +            break;
> +        }
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +                    domid, phys_offset_v), "%"PRIx64, size_v);
> +        if (ret) {
> +            ptr = buf + header_size;
> +            break;
> +        }
> +    }
>  
> +no_header:
>      filename = libxl__device_model_restorefile(gc, domid);
>      fd2 = open(filename, O_WRONLY|O_CREAT);
>      if (fd2 < 0) {
> @@ -370,7 +408,7 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
>      }
>  
>      ret = libxl_write_exactly(
> -            ctx, fd2, buf, size, "saved-state file", "qemu state");
> +            ctx, fd2, ptr, size, "saved-state file", "qemu state");
>      if (ret)
>          goto out;
>      ret = 0;
> @@ -642,11 +680,61 @@ out:
>      return rc;
>  }
>  
> +static int libxl__domain_save_qemu_header(libxl__gc *gc, uint32_t domid,
> +                                          int fd, char **buf)
> +{
> +    char *start_addr = NULL, *size = NULL, *phys_offset = NULL;
> +    int len = 0, i = 0;
> +    unsigned int num = 0;
> +    uint32_t count = 0;
> +    char *ptr = NULL, **entries = NULL;
> +    uint64_t val = 0;
> +
> +    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
> +                "/local/domain/0/device-model/%d/physmap", domid), &num);
> +    count = num;
> +
> +    len = sizeof(QEMU_HEADER) + sizeof(count) + count * (sizeof(val) * 3);
> +    *buf = libxl__calloc(gc, 1, len);
> +    ptr = *buf;
> +
> +    strcpy(ptr, QEMU_HEADER);
> +    ptr += sizeof(QEMU_HEADER);
> +
> +    memcpy(ptr, &count, sizeof(count));
> +    ptr += sizeof(count);
> +
> +    for (i = 0; i < count; i++) {
> +        phys_offset = entries[i];
> +        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
> +                    domid, phys_offset));
> +        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/size",
> +                    domid, phys_offset));
> +
> +        if (start_addr == NULL || size == NULL || phys_offset == NULL)
> +            return 0;
> +
> +        val = strtoll(phys_offset, NULL, 16);
> +        memcpy(ptr, &val, sizeof(val));
> +        ptr += sizeof(val);
> +        val = strtoll(start_addr, NULL, 16);
> +        memcpy(ptr, &val, sizeof(val));
> +        ptr += sizeof(val);
> +        val = strtoll(size, NULL, 16);
> +        memcpy(ptr, &val, sizeof(val));
> +        ptr += sizeof(val);
> +    }
> +
> +    return len;
> +}
> +
>  int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> -    int ret, fd2 = -1, c;
> -    char buf[1024];
> +    int ret, fd2 = -1, c, len;
> +    char buf[1024], *buf2;
>      const char *filename = libxl__device_model_savefile(gc, domid);
>      struct stat st;
>      uint32_t qemu_state_len;
> @@ -687,7 +775,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>          goto out;
>      }
>  
> -    qemu_state_len = st.st_size;
> +    len = libxl__domain_save_qemu_header(gc, domid, fd, &buf2);
> +    qemu_state_len = st.st_size + len;
>      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
>  
>      ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
> @@ -700,6 +789,11 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>      if (ret)
>          goto out;
>  
> +    ret = libxl_write_exactly(ctx, fd, buf2, len,
> +                            "saved-state file", "saved-state qemu header");
> +    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");
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 7f7578a..01f866f 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -57,6 +57,7 @@
>  #define LIBXL_HVM_EXTRA_MEMORY 2048
>  #define LIBXL_MIN_DOM0_MEM (128*1024)
>  #define QEMU_SIGNATURE "DeviceModelRecord0002"
> +#define QEMU_HEADER "DeviceModelHeader0001"
>  #define STUBDOM_CONSOLE_LOGGING 0
>  #define STUBDOM_CONSOLE_SAVE 1
>  #define STUBDOM_CONSOLE_RESTORE 2



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:25:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:25:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnr31-00049o-3d; Thu, 19 Jan 2012 12:24:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rnr2z-00049f-Kp
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:24:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1326975887!11687784!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31575 invoked from network); 19 Jan 2012 12:24:47 -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;
	19 Jan 2012 12:24:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10141379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12: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, 19 Jan 2012 12:24:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 12:24:47 +0000
In-Reply-To: <1326975184-458-3-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975184-458-3-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326975887.17599.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 3/3] libxl: introduce QEMU_HEADER
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 12:13 +0000, Stefano Stabellini wrote:
> Introduce a new QEMU_HEADER stored in the Qemu chunk right after the
> QEMU_SIGNATURE and record length, before the Qemu state, to preserve the
> physmap informations written by Qemu on xenstore.

I'm still of the opinion that this should be a new XC_SAVE_ID_*
(possibly from a new range reserved for toolstakc use) and
saved/restored via a separate callback from libxc.

The mess that is the tail of the save/restore protocol is pure
historical and for backwards compat, we should not be making it any
worse. An XC_SAVE_ID is exactly equivalent to adding something to the
tail but uses the extensibility mechanism which we have now built into
the protocol.

Ian.

> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl_dom.c      |  104 ++++++++++++++++++++++++++++++++++++++++--
>  tools/libxl/libxl_internal.h |    1 +
>  2 files changed, 100 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index f33e572..0f3d0c3 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -359,9 +359,47 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
>      libxl__gc *gc = (libxl__gc *)arg->gc;
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      uint32_t domid = arg->domid;
> -    int fd2 = -1, ret = 0;
> +    int fd2 = -1, ret = 0, i = 0;
>      const char *filename;
> +    uint8_t *ptr = buf;
> +    uint32_t count = 0;
> +    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
> +    uint32_t header_size = 0;
> +
> +    if (strncmp((char *)ptr, QEMU_HEADER, size))
> +        goto no_header;
> +
> +    ptr += sizeof(QEMU_HEADER);
> +    memcpy(&count, ptr, sizeof(count));
> +    ptr += sizeof(count);
> +    header_size = sizeof(QEMU_HEADER) + sizeof(count) + count * sizeof(uint64_t) * 3;
> +    size -= header_size;
> + 
> +    for (i = 0; i < count; i++) {
> +        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +        memcpy(&size_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
> +                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
> +        if (ret) {
> +            ptr = buf + header_size;
> +            break;
> +        }
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +                    domid, phys_offset_v), "%"PRIx64, size_v);
> +        if (ret) {
> +            ptr = buf + header_size;
> +            break;
> +        }
> +    }
>  
> +no_header:
>      filename = libxl__device_model_restorefile(gc, domid);
>      fd2 = open(filename, O_WRONLY|O_CREAT);
>      if (fd2 < 0) {
> @@ -370,7 +408,7 @@ static int libxl__domain_restore_device_model(uint8_t *buf, uint32_t size,
>      }
>  
>      ret = libxl_write_exactly(
> -            ctx, fd2, buf, size, "saved-state file", "qemu state");
> +            ctx, fd2, ptr, size, "saved-state file", "qemu state");
>      if (ret)
>          goto out;
>      ret = 0;
> @@ -642,11 +680,61 @@ out:
>      return rc;
>  }
>  
> +static int libxl__domain_save_qemu_header(libxl__gc *gc, uint32_t domid,
> +                                          int fd, char **buf)
> +{
> +    char *start_addr = NULL, *size = NULL, *phys_offset = NULL;
> +    int len = 0, i = 0;
> +    unsigned int num = 0;
> +    uint32_t count = 0;
> +    char *ptr = NULL, **entries = NULL;
> +    uint64_t val = 0;
> +
> +    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
> +                "/local/domain/0/device-model/%d/physmap", domid), &num);
> +    count = num;
> +
> +    len = sizeof(QEMU_HEADER) + sizeof(count) + count * (sizeof(val) * 3);
> +    *buf = libxl__calloc(gc, 1, len);
> +    ptr = *buf;
> +
> +    strcpy(ptr, QEMU_HEADER);
> +    ptr += sizeof(QEMU_HEADER);
> +
> +    memcpy(ptr, &count, sizeof(count));
> +    ptr += sizeof(count);
> +
> +    for (i = 0; i < count; i++) {
> +        phys_offset = entries[i];
> +        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
> +                    domid, phys_offset));
> +        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%s/size",
> +                    domid, phys_offset));
> +
> +        if (start_addr == NULL || size == NULL || phys_offset == NULL)
> +            return 0;
> +
> +        val = strtoll(phys_offset, NULL, 16);
> +        memcpy(ptr, &val, sizeof(val));
> +        ptr += sizeof(val);
> +        val = strtoll(start_addr, NULL, 16);
> +        memcpy(ptr, &val, sizeof(val));
> +        ptr += sizeof(val);
> +        val = strtoll(size, NULL, 16);
> +        memcpy(ptr, &val, sizeof(val));
> +        ptr += sizeof(val);
> +    }
> +
> +    return len;
> +}
> +
>  int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
> -    int ret, fd2 = -1, c;
> -    char buf[1024];
> +    int ret, fd2 = -1, c, len;
> +    char buf[1024], *buf2;
>      const char *filename = libxl__device_model_savefile(gc, domid);
>      struct stat st;
>      uint32_t qemu_state_len;
> @@ -687,7 +775,8 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>          goto out;
>      }
>  
> -    qemu_state_len = st.st_size;
> +    len = libxl__domain_save_qemu_header(gc, domid, fd, &buf2);
> +    qemu_state_len = st.st_size + len;
>      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
>  
>      ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
> @@ -700,6 +789,11 @@ int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
>      if (ret)
>          goto out;
>  
> +    ret = libxl_write_exactly(ctx, fd, buf2, len,
> +                            "saved-state file", "saved-state qemu header");
> +    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");
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 7f7578a..01f866f 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -57,6 +57,7 @@
>  #define LIBXL_HVM_EXTRA_MEMORY 2048
>  #define LIBXL_MIN_DOM0_MEM (128*1024)
>  #define QEMU_SIGNATURE "DeviceModelRecord0002"
> +#define QEMU_HEADER "DeviceModelHeader0001"
>  #define STUBDOM_CONSOLE_LOGGING 0
>  #define STUBDOM_CONSOLE_SAVE 1
>  #define STUBDOM_CONSOLE_RESTORE 2



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:25:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 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 1Rnr3A-0004Au-M1; Thu, 19 Jan 2012 12:25: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 1Rnr39-0004AK-5h
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:25:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326975897!11694457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13216 invoked from network); 19 Jan 2012 12:24:57 -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;
	19 Jan 2012 12:24:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10141381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:24:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 12:24:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 12:24:56 +0000
In-Reply-To: <1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326975896.17599.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> Write to xenstore any physmap changes so that the hypervisor can be
> aware of them.

What is the structure of the xenstore values? Looks like 
	<domid>/physmap/<original-addr>/start_addr <new-addr>
? Who defines the meaning of original-addr, in particular what happens
if it the original-addr for a device changes in a N->N+1 migration? What
happens if things overlap or if a subsequent call only updates part of a
previously moved mapping?

> Read physmap changes from xenstore on boot.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen-all.c |   62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 62 insertions(+), 0 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index 507d93d..c830cb1 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -253,6 +253,7 @@ static int xen_add_to_physmap(XenIOState *state,
>      XenPhysmap *physmap = NULL;
>      target_phys_addr_t pfn, start_gpfn;
>      target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
> +    char path[80], value[17];
>  
>      if (get_physmapping(state, start_addr, size)) {
>          return 0;
> @@ -299,6 +300,22 @@ go_physmap:
>                                     start_addr >> TARGET_PAGE_BITS,
>                                     (start_addr + size) >> TARGET_PAGE_BITS,
>                                     XEN_DOMCTL_MEM_CACHEATTR_WB);
> +
> +    snprintf(path, sizeof(path),
> +            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
> +            xen_domid, (uint64_t)phys_offset);
> +    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
> +    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
> +        return -1;
> +    }
> +    snprintf(path, sizeof(path),
> +            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +            xen_domid, (uint64_t)phys_offset);
> +    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
> +    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
> +        return -1;
> +    }
> +
>      return 0;
>  }
>  
> @@ -926,6 +943,50 @@ int xen_init(void)
>      return 0;
>  }
>  
> +static void xen_read_physmap(XenIOState *state)
> +{
> +    XenPhysmap *physmap = NULL;
> +    unsigned int len, num, i;
> +    char path[80], *value = NULL;
> +    char **entries = NULL;
> +
> +    snprintf(path, sizeof(path),
> +            "/local/domain/0/device-model/%d/physmap", xen_domid);
> +    entries = xs_directory(state->xenstore, 0, path, &num);
> +    if (entries == NULL)
> +        return;
> +
> +    for (i = 0; i < num; i++) {
> +        physmap = g_malloc(sizeof (XenPhysmap));
> +        physmap->phys_offset = strtoull(entries[i], NULL, 16);
> +        snprintf(path, sizeof(path),
> +                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
> +                xen_domid, entries[i]);
> +        value = xs_read(state->xenstore, 0, path, &len);
> +        if (value == NULL) {
> +            free(physmap);
> +            continue;
> +        }
> +        physmap->start_addr = strtoull(value, NULL, 16);
> +        free(value);
> +
> +        snprintf(path, sizeof(path),
> +                "/local/domain/0/device-model/%d/physmap/%s/size",
> +                xen_domid, entries[i]);
> +        value = xs_read(state->xenstore, 0, path, &len);
> +        if (value == NULL) {
> +            free(physmap);
> +            continue;
> +        }
> +        physmap->size = strtoull(value, NULL, 16);
> +        free(value);
> +
> +        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
> +    }
> +    free(entries);
> +    return;
> +}
> +
>  int xen_hvm_init(void)
>  {
>      int i, rc;
> @@ -998,6 +1059,7 @@ int xen_hvm_init(void)
>      xen_be_register("console", &xen_console_ops);
>      xen_be_register("vkbd", &xen_kbdmouse_ops);
>      xen_be_register("qdisk", &xen_blkdev_ops);
> +    xen_read_physmap(state);
>  
>      return 0;
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:25:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 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 1Rnr3A-0004Au-M1; Thu, 19 Jan 2012 12:25: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 1Rnr39-0004AK-5h
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:25:03 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1326975897!11694457!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13216 invoked from network); 19 Jan 2012 12:24:57 -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;
	19 Jan 2012 12:24:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10141381"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:24:57 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 12:24:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 12:24:56 +0000
In-Reply-To: <1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326975896.17599.81.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> Write to xenstore any physmap changes so that the hypervisor can be
> aware of them.

What is the structure of the xenstore values? Looks like 
	<domid>/physmap/<original-addr>/start_addr <new-addr>
? Who defines the meaning of original-addr, in particular what happens
if it the original-addr for a device changes in a N->N+1 migration? What
happens if things overlap or if a subsequent call only updates part of a
previously moved mapping?

> Read physmap changes from xenstore on boot.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen-all.c |   62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 62 insertions(+), 0 deletions(-)
> 
> diff --git a/xen-all.c b/xen-all.c
> index 507d93d..c830cb1 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -253,6 +253,7 @@ static int xen_add_to_physmap(XenIOState *state,
>      XenPhysmap *physmap = NULL;
>      target_phys_addr_t pfn, start_gpfn;
>      target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
> +    char path[80], value[17];
>  
>      if (get_physmapping(state, start_addr, size)) {
>          return 0;
> @@ -299,6 +300,22 @@ go_physmap:
>                                     start_addr >> TARGET_PAGE_BITS,
>                                     (start_addr + size) >> TARGET_PAGE_BITS,
>                                     XEN_DOMCTL_MEM_CACHEATTR_WB);
> +
> +    snprintf(path, sizeof(path),
> +            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
> +            xen_domid, (uint64_t)phys_offset);
> +    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
> +    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
> +        return -1;
> +    }
> +    snprintf(path, sizeof(path),
> +            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +            xen_domid, (uint64_t)phys_offset);
> +    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
> +    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
> +        return -1;
> +    }
> +
>      return 0;
>  }
>  
> @@ -926,6 +943,50 @@ int xen_init(void)
>      return 0;
>  }
>  
> +static void xen_read_physmap(XenIOState *state)
> +{
> +    XenPhysmap *physmap = NULL;
> +    unsigned int len, num, i;
> +    char path[80], *value = NULL;
> +    char **entries = NULL;
> +
> +    snprintf(path, sizeof(path),
> +            "/local/domain/0/device-model/%d/physmap", xen_domid);
> +    entries = xs_directory(state->xenstore, 0, path, &num);
> +    if (entries == NULL)
> +        return;
> +
> +    for (i = 0; i < num; i++) {
> +        physmap = g_malloc(sizeof (XenPhysmap));
> +        physmap->phys_offset = strtoull(entries[i], NULL, 16);
> +        snprintf(path, sizeof(path),
> +                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
> +                xen_domid, entries[i]);
> +        value = xs_read(state->xenstore, 0, path, &len);
> +        if (value == NULL) {
> +            free(physmap);
> +            continue;
> +        }
> +        physmap->start_addr = strtoull(value, NULL, 16);
> +        free(value);
> +
> +        snprintf(path, sizeof(path),
> +                "/local/domain/0/device-model/%d/physmap/%s/size",
> +                xen_domid, entries[i]);
> +        value = xs_read(state->xenstore, 0, path, &len);
> +        if (value == NULL) {
> +            free(physmap);
> +            continue;
> +        }
> +        physmap->size = strtoull(value, NULL, 16);
> +        free(value);
> +
> +        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
> +    }
> +    free(entries);
> +    return;
> +}
> +
>  int xen_hvm_init(void)
>  {
>      int i, rc;
> @@ -998,6 +1059,7 @@ int xen_hvm_init(void)
>      xen_be_register("console", &xen_console_ops);
>      xen_be_register("vkbd", &xen_kbdmouse_ops);
>      xen_be_register("qdisk", &xen_blkdev_ops);
> +    xen_read_physmap(state);
>  
>      return 0;
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:26:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnr3y-0004HA-5p; Thu, 19 Jan 2012 12:25:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rnr3w-0004GL-0g
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:25:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326975945!9648085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24052 invoked from network); 19 Jan 2012 12:25:46 -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;
	19 Jan 2012 12:25:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10141394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:25: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, 19 Jan 2012 12:25:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 12:25:44 +0000
In-Reply-To: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326975944.17599.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 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:

> Stefano Stabellini (3):
>       libxc: add a callback to xc_domain_restore
>       libxl: extract the qemu state file from the save image
>       libxl: introduce QEMU_HEADER

Two sets of these followed. I've assumed they were identical.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:26:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:26:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnr3y-0004HA-5p; Thu, 19 Jan 2012 12:25:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rnr3w-0004GL-0g
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:25:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326975945!9648085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24052 invoked from network); 19 Jan 2012 12:25:46 -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;
	19 Jan 2012 12:25:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10141394"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:25: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, 19 Jan 2012 12:25:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 12:25:44 +0000
In-Reply-To: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326975944.17599.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 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:

> Stefano Stabellini (3):
>       libxc: add a callback to xc_domain_restore
>       libxl: extract the qemu state file from the save image
>       libxl: introduce QEMU_HEADER

Two sets of these followed. I've assumed they were identical.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:33:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnrAp-0004uS-3g; Thu, 19 Jan 2012 12:32:59 +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 1RnrAn-0004uN-On
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:32:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326976370!11718153!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 14866 invoked from network); 19 Jan 2012 12:32:50 -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 Jan 2012 12:32:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 12:32:50 +0000
Message-Id: <4F181BC2020000780006DA89@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 12:33: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="=__Part90BECAA2.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/gntdev: switch from char-dev to
	misc-dev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part90BECAA2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than consuming a major (using just a single minor under it)
register a dynamic-minor misc-dev (as has been the case in the pv-ops
code from the very beginning).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/gntdev/gntdev.c
+++ b/drivers/xen/gntdev/gntdev.c
@@ -21,7 +21,7 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/fs.h>
-#include <linux/device.h>
+#include <linux/miscdevice.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
 #include <asm/uaccess.h>
@@ -30,9 +30,6 @@
 #include <asm/hypervisor.h>
 #include <xen/balloon.h>
 #include <xen/evtchn.h>
-#include <xen/driver_util.h>
-
-#include <linux/types.h>
 #include <xen/public/gntdev.h>
=20
=20
@@ -156,11 +153,6 @@ static struct vm_operations_struct gntde
 	.zap_pte =3D gntdev_clear_pte
 };
=20
-/* Global variables. */
-
-/* The driver major number, for use when unregistering the driver. */
-static int gntdev_major;
-
 #define GNTDEV_NAME "gntdev"
=20
 /* Memory mapping functions
@@ -371,42 +363,27 @@ nomem_out:
=20
 /* Interface functions. */
=20
+static struct miscdevice gntdev_miscdev =3D {
+	.minor        =3D MISC_DYNAMIC_MINOR,
+	.name         =3D GNTDEV_NAME,
+	.fops         =3D &gntdev_fops,
+};
+
 /* Initialises the driver. Called when the module is loaded. */
 static int __init gntdev_init(void)
 {
-	struct class *class;
-	struct class_device *device;
+	int err;
=20
 	if (!is_running_on_xen()) {
 		printk(KERN_ERR "You must be running Xen to use gntdev\n");=

 		return -ENODEV;
 	}
=20
-	gntdev_major =3D register_chrdev(0, GNTDEV_NAME, &gntdev_fops);
-	if (gntdev_major < 0)
+	err =3D misc_register(&gntdev_miscdev);
+	if (err)
 	{
 		printk(KERN_ERR "Could not register gntdev device\n");
-		return -ENOMEM;
-	}
-
-	/* Note that if the sysfs code fails, we will still initialise the
-	 * device, and output the major number so that the device can be
-	 * created manually using mknod.
-	 */
-	if ((class =3D get_xen_class()) =3D=3D NULL) {
-		printk(KERN_ERR "Error setting up xen_class\n");
-		printk(KERN_ERR "gntdev created with major number =3D =
%d\n",=20
-		       gntdev_major);
-		return 0;
-	}
-
-	device =3D class_device_create(class, NULL, MKDEV(gntdev_major, =
0),
-				     NULL, GNTDEV_NAME);
-	if (IS_ERR(device)) {
-		printk(KERN_ERR "Error creating gntdev device in xen_class\=
n");
-		printk(KERN_ERR "gntdev created with major number =3D =
%d\n",
-		       gntdev_major);
-		return 0;
+		return err;
 	}
=20
 	return 0;
@@ -416,10 +393,7 @@ static int __init gntdev_init(void)
  */
 static void __exit gntdev_exit(void)
 {
-	struct class *class;
-	if ((class =3D get_xen_class()) !=3D NULL)
-		class_device_destroy(class, MKDEV(gntdev_major, 0));
-	unregister_chrdev(gntdev_major, GNTDEV_NAME);
+	misc_deregister(&gntdev_miscdev);
 }
=20
 /* Called when the device is opened. */




--=__Part90BECAA2.0__=
Content-Type: text/plain; name="xen-gntdev-miscdev.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-gntdev-miscdev.patch"

gntdev: switch from char-dev to misc-dev=0A=0ARather than consuming a =
major (using just a single minor under it)=0Aregister a dynamic-minor =
misc-dev (as has been the case in the pv-ops=0Acode from the very =
beginning).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntdev/gntdev.c=0A@@ =
-21,7 +21,7 @@=0A #include <linux/kernel.h>=0A #include <linux/init.h>=0A =
#include <linux/fs.h>=0A-#include <linux/device.h>=0A+#include <linux/miscd=
evice.h>=0A #include <linux/mm.h>=0A #include <linux/mman.h>=0A #include =
<asm/uaccess.h>=0A@@ -30,9 +30,6 @@=0A #include <asm/hypervisor.h>=0A =
#include <xen/balloon.h>=0A #include <xen/evtchn.h>=0A-#include <xen/driver=
_util.h>=0A-=0A-#include <linux/types.h>=0A #include <xen/public/gntdev.h>=
=0A =0A =0A@@ -156,11 +153,6 @@ static struct vm_operations_struct =
gntde=0A 	.zap_pte =3D gntdev_clear_pte=0A };=0A =0A-/* Global =
variables. */=0A-=0A-/* The driver major number, for use when unregistering=
 the driver. */=0A-static int gntdev_major;=0A-=0A #define GNTDEV_NAME =
"gntdev"=0A =0A /* Memory mapping functions=0A@@ -371,42 +363,27 @@ =
nomem_out:=0A =0A /* Interface functions. */=0A =0A+static struct =
miscdevice gntdev_miscdev =3D {=0A+	.minor        =3D MISC_DYNAMIC_MINO=
R,=0A+	.name         =3D GNTDEV_NAME,=0A+	.fops         =3D =
&gntdev_fops,=0A+};=0A+=0A /* Initialises the driver. Called when the =
module is loaded. */=0A static int __init gntdev_init(void)=0A {=0A-	=
struct class *class;=0A-	struct class_device *device;=0A+	=
int err;=0A =0A 	if (!is_running_on_xen()) {=0A 		printk(KERN=
_ERR "You must be running Xen to use gntdev\n");=0A 		return =
-ENODEV;=0A 	}=0A =0A-	gntdev_major =3D register_chrdev(0, =
GNTDEV_NAME, &gntdev_fops);=0A-	if (gntdev_major < 0)=0A+	err =3D =
misc_register(&gntdev_miscdev);=0A+	if (err)=0A 	{=0A 		=
printk(KERN_ERR "Could not register gntdev device\n");=0A-		=
return -ENOMEM;=0A-	}=0A-=0A-	/* Note that if the sysfs code =
fails, we will still initialise the=0A-	 * device, and output the major =
number so that the device can be=0A-	 * created manually using =
mknod.=0A-	 */=0A-	if ((class =3D get_xen_class()) =3D=3D NULL) {=0A-	=
	printk(KERN_ERR "Error setting up xen_class\n");=0A-		=
printk(KERN_ERR "gntdev created with major number =3D %d\n", =0A-		=
       gntdev_major);=0A-		return 0;=0A-	}=0A-=0A-	=
device =3D class_device_create(class, NULL, MKDEV(gntdev_major, 0),=0A-		=
		     NULL, GNTDEV_NAME);=0A-	if (IS_ERR(device)) {=0A-	=
	printk(KERN_ERR "Error creating gntdev device in xen_class\n");=0A-=
		printk(KERN_ERR "gntdev created with major number =3D =
%d\n",=0A-		       gntdev_major);=0A-		return =
0;=0A+		return err;=0A 	}=0A =0A 	return 0;=0A@@ -416,10 =
+393,7 @@ static int __init gntdev_init(void)=0A  */=0A static void __exit =
gntdev_exit(void)=0A {=0A-	struct class *class;=0A-	if ((class =
=3D get_xen_class()) !=3D NULL)=0A-		class_device_destroy(class,=
 MKDEV(gntdev_major, 0));=0A-	unregister_chrdev(gntdev_major, GNTDEV_NAME=
);=0A+	misc_deregister(&gntdev_miscdev);=0A }=0A =0A /* Called when the =
device is opened. */=0A
--=__Part90BECAA2.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

--=__Part90BECAA2.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:33:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:33:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnrAp-0004uS-3g; Thu, 19 Jan 2012 12:32:59 +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 1RnrAn-0004uN-On
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:32:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326976370!11718153!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 14866 invoked from network); 19 Jan 2012 12:32:50 -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 Jan 2012 12:32:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 12:32:50 +0000
Message-Id: <4F181BC2020000780006DA89@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 12:33: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="=__Part90BECAA2.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/gntdev: switch from char-dev to
	misc-dev
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part90BECAA2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Rather than consuming a major (using just a single minor under it)
register a dynamic-minor misc-dev (as has been the case in the pv-ops
code from the very beginning).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/gntdev/gntdev.c
+++ b/drivers/xen/gntdev/gntdev.c
@@ -21,7 +21,7 @@
 #include <linux/kernel.h>
 #include <linux/init.h>
 #include <linux/fs.h>
-#include <linux/device.h>
+#include <linux/miscdevice.h>
 #include <linux/mm.h>
 #include <linux/mman.h>
 #include <asm/uaccess.h>
@@ -30,9 +30,6 @@
 #include <asm/hypervisor.h>
 #include <xen/balloon.h>
 #include <xen/evtchn.h>
-#include <xen/driver_util.h>
-
-#include <linux/types.h>
 #include <xen/public/gntdev.h>
=20
=20
@@ -156,11 +153,6 @@ static struct vm_operations_struct gntde
 	.zap_pte =3D gntdev_clear_pte
 };
=20
-/* Global variables. */
-
-/* The driver major number, for use when unregistering the driver. */
-static int gntdev_major;
-
 #define GNTDEV_NAME "gntdev"
=20
 /* Memory mapping functions
@@ -371,42 +363,27 @@ nomem_out:
=20
 /* Interface functions. */
=20
+static struct miscdevice gntdev_miscdev =3D {
+	.minor        =3D MISC_DYNAMIC_MINOR,
+	.name         =3D GNTDEV_NAME,
+	.fops         =3D &gntdev_fops,
+};
+
 /* Initialises the driver. Called when the module is loaded. */
 static int __init gntdev_init(void)
 {
-	struct class *class;
-	struct class_device *device;
+	int err;
=20
 	if (!is_running_on_xen()) {
 		printk(KERN_ERR "You must be running Xen to use gntdev\n");=

 		return -ENODEV;
 	}
=20
-	gntdev_major =3D register_chrdev(0, GNTDEV_NAME, &gntdev_fops);
-	if (gntdev_major < 0)
+	err =3D misc_register(&gntdev_miscdev);
+	if (err)
 	{
 		printk(KERN_ERR "Could not register gntdev device\n");
-		return -ENOMEM;
-	}
-
-	/* Note that if the sysfs code fails, we will still initialise the
-	 * device, and output the major number so that the device can be
-	 * created manually using mknod.
-	 */
-	if ((class =3D get_xen_class()) =3D=3D NULL) {
-		printk(KERN_ERR "Error setting up xen_class\n");
-		printk(KERN_ERR "gntdev created with major number =3D =
%d\n",=20
-		       gntdev_major);
-		return 0;
-	}
-
-	device =3D class_device_create(class, NULL, MKDEV(gntdev_major, =
0),
-				     NULL, GNTDEV_NAME);
-	if (IS_ERR(device)) {
-		printk(KERN_ERR "Error creating gntdev device in xen_class\=
n");
-		printk(KERN_ERR "gntdev created with major number =3D =
%d\n",
-		       gntdev_major);
-		return 0;
+		return err;
 	}
=20
 	return 0;
@@ -416,10 +393,7 @@ static int __init gntdev_init(void)
  */
 static void __exit gntdev_exit(void)
 {
-	struct class *class;
-	if ((class =3D get_xen_class()) !=3D NULL)
-		class_device_destroy(class, MKDEV(gntdev_major, 0));
-	unregister_chrdev(gntdev_major, GNTDEV_NAME);
+	misc_deregister(&gntdev_miscdev);
 }
=20
 /* Called when the device is opened. */




--=__Part90BECAA2.0__=
Content-Type: text/plain; name="xen-gntdev-miscdev.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-gntdev-miscdev.patch"

gntdev: switch from char-dev to misc-dev=0A=0ARather than consuming a =
major (using just a single minor under it)=0Aregister a dynamic-minor =
misc-dev (as has been the case in the pv-ops=0Acode from the very =
beginning).=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gntdev/gntdev.c=0A@@ =
-21,7 +21,7 @@=0A #include <linux/kernel.h>=0A #include <linux/init.h>=0A =
#include <linux/fs.h>=0A-#include <linux/device.h>=0A+#include <linux/miscd=
evice.h>=0A #include <linux/mm.h>=0A #include <linux/mman.h>=0A #include =
<asm/uaccess.h>=0A@@ -30,9 +30,6 @@=0A #include <asm/hypervisor.h>=0A =
#include <xen/balloon.h>=0A #include <xen/evtchn.h>=0A-#include <xen/driver=
_util.h>=0A-=0A-#include <linux/types.h>=0A #include <xen/public/gntdev.h>=
=0A =0A =0A@@ -156,11 +153,6 @@ static struct vm_operations_struct =
gntde=0A 	.zap_pte =3D gntdev_clear_pte=0A };=0A =0A-/* Global =
variables. */=0A-=0A-/* The driver major number, for use when unregistering=
 the driver. */=0A-static int gntdev_major;=0A-=0A #define GNTDEV_NAME =
"gntdev"=0A =0A /* Memory mapping functions=0A@@ -371,42 +363,27 @@ =
nomem_out:=0A =0A /* Interface functions. */=0A =0A+static struct =
miscdevice gntdev_miscdev =3D {=0A+	.minor        =3D MISC_DYNAMIC_MINO=
R,=0A+	.name         =3D GNTDEV_NAME,=0A+	.fops         =3D =
&gntdev_fops,=0A+};=0A+=0A /* Initialises the driver. Called when the =
module is loaded. */=0A static int __init gntdev_init(void)=0A {=0A-	=
struct class *class;=0A-	struct class_device *device;=0A+	=
int err;=0A =0A 	if (!is_running_on_xen()) {=0A 		printk(KERN=
_ERR "You must be running Xen to use gntdev\n");=0A 		return =
-ENODEV;=0A 	}=0A =0A-	gntdev_major =3D register_chrdev(0, =
GNTDEV_NAME, &gntdev_fops);=0A-	if (gntdev_major < 0)=0A+	err =3D =
misc_register(&gntdev_miscdev);=0A+	if (err)=0A 	{=0A 		=
printk(KERN_ERR "Could not register gntdev device\n");=0A-		=
return -ENOMEM;=0A-	}=0A-=0A-	/* Note that if the sysfs code =
fails, we will still initialise the=0A-	 * device, and output the major =
number so that the device can be=0A-	 * created manually using =
mknod.=0A-	 */=0A-	if ((class =3D get_xen_class()) =3D=3D NULL) {=0A-	=
	printk(KERN_ERR "Error setting up xen_class\n");=0A-		=
printk(KERN_ERR "gntdev created with major number =3D %d\n", =0A-		=
       gntdev_major);=0A-		return 0;=0A-	}=0A-=0A-	=
device =3D class_device_create(class, NULL, MKDEV(gntdev_major, 0),=0A-		=
		     NULL, GNTDEV_NAME);=0A-	if (IS_ERR(device)) {=0A-	=
	printk(KERN_ERR "Error creating gntdev device in xen_class\n");=0A-=
		printk(KERN_ERR "gntdev created with major number =3D =
%d\n",=0A-		       gntdev_major);=0A-		return =
0;=0A+		return err;=0A 	}=0A =0A 	return 0;=0A@@ -416,10 =
+393,7 @@ static int __init gntdev_init(void)=0A  */=0A static void __exit =
gntdev_exit(void)=0A {=0A-	struct class *class;=0A-	if ((class =
=3D get_xen_class()) !=3D NULL)=0A-		class_device_destroy(class,=
 MKDEV(gntdev_major, 0));=0A-	unregister_chrdev(gntdev_major, GNTDEV_NAME=
);=0A+	misc_deregister(&gntdev_miscdev);=0A }=0A =0A /* Called when the =
device is opened. */=0A
--=__Part90BECAA2.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

--=__Part90BECAA2.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:48:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12: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 1RnrPn-0005Ab-Qi; Thu, 19 Jan 2012 12:48: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 1RnrPm-00059p-BW
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:48:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326977291!4226584!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 16220 invoked from network); 19 Jan 2012 12:48:11 -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; 19 Jan 2012 12:48:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 12:48:10 +0000
Message-Id: <4F181F5B020000780006DA95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 12:49:15 +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="=__Part755B2F5B.0__="
Subject: [Xen-devel] linux-2.6.18/drivers/xen/: remove stray inclusion of
 various 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.

--=__Part755B2F5B.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

More than once (perhaps through copy-and-paste) occurring were
- mman.h
- pagemap.h
- smp_lock.h
- vmalloc.h

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/balloon/balloon.c
+++ b/drivers/xen/balloon/balloon.c
@@ -36,13 +36,10 @@
 #include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/errno.h>
+#include <linux/list.h>
 #include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/smp_lock.h>
-#include <linux/pagemap.h>
 #include <linux/bootmem.h>
 #include <linux/highmem.h>
-#include <linux/vmalloc.h>
 #include <linux/mutex.h>
 #include <xen/xen_proc.h>
 #include <asm/hypervisor.h>
@@ -54,8 +50,6 @@
 #include <asm/pgtable.h>
 #include <asm/uaccess.h>
 #include <asm/tlb.h>
-#include <linux/highmem.h>
-#include <linux/list.h>
 #include <xen/xenbus.h>
 #include "common.h"
=20
--- a/drivers/xen/char/mem.c
+++ b/drivers/xen/char/mem.c
@@ -9,19 +9,10 @@
  */
=20
 #include <linux/mm.h>
-#include <linux/miscdevice.h>
-#include <linux/slab.h>
-#include <linux/vmalloc.h>
-#include <linux/mman.h>
-#include <linux/random.h>
 #include <linux/init.h>
-#include <linux/raw.h>
-#include <linux/tty.h>
+#include <linux/fs.h>
 #include <linux/capability.h>
-#include <linux/smp_lock.h>
 #include <linux/ptrace.h>
-#include <linux/device.h>
-#include <asm/pgalloc.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/hypervisor.h>
--- a/drivers/xen/core/smpboot.c
+++ b/drivers/xen/core/smpboot.c
@@ -11,9 +11,7 @@
 #include <linux/mm.h>
 #include <linux/sched.h>
 #include <linux/kernel_stat.h>
-#include <linux/smp_lock.h>
 #include <linux/irq.h>
-#include <linux/bootmem.h>
 #include <linux/notifier.h>
 #include <linux/cpu.h>
 #include <linux/percpu.h>
--- a/drivers/xen/gntdev/gntdev.c
+++ b/drivers/xen/gntdev/gntdev.c
@@ -23,7 +23,6 @@
 #include <linux/fs.h>
 #include <linux/miscdevice.h>
 #include <linux/mm.h>
-#include <linux/mman.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <xen/gnttab.h>
--- a/drivers/xen/pciback/xenbus.c
+++ b/drivers/xen/pciback/xenbus.c
@@ -6,7 +6,6 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/list.h>
-#include <linux/vmalloc.h>
 #include <xen/xenbus.h>
 #include <xen/evtchn.h>
 #include "pciback.h"
--- a/drivers/xen/privcmd/privcmd.c
+++ b/drivers/xen/privcmd/privcmd.c
@@ -12,12 +12,6 @@
 #include <linux/string.h>
 #include <linux/errno.h>
 #include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/swap.h>
-#include <linux/smp_lock.h>
-#include <linux/highmem.h>
-#include <linux/pagemap.h>
-#include <linux/seq_file.h>
 #include <asm/hypervisor.h>
=20
 #include <asm/pgalloc.h>
--- a/drivers/xen/scsiback/common.h
+++ b/drivers/xen/scsiback/common.h
@@ -34,7 +34,6 @@
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
-#include <linux/vmalloc.h>
 #include <linux/wait.h>
 #include <linux/sched.h>
 #include <linux/kthread.h>
--- a/drivers/xen/usbback/usbback.h
+++ b/drivers/xen/usbback/usbback.h
@@ -50,7 +50,6 @@
 #include <linux/interrupt.h>
 #include <linux/slab.h>
 #include <linux/usb.h>
-#include <linux/vmalloc.h>
 #include <linux/kthread.h>
 #include <linux/wait.h>
 #include <linux/list.h>




--=__Part755B2F5B.0__=
Content-Type: text/plain; name="xen-no-mman-h.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-no-mman-h.patch"

drivers/xen/: remove stray inclusion of various headers=0A=0AMore than =
once (perhaps through copy-and-paste) occurring were=0A- mman.h=0A- =
pagemap.h=0A- smp_lock.h=0A- vmalloc.h=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/drivers/xen/balloon/balloon.c=0A+++ =
b/drivers/xen/balloon/balloon.c=0A@@ -36,13 +36,10 @@=0A #include =
<linux/module.h>=0A #include <linux/sched.h>=0A #include <linux/errno.h>=0A=
+#include <linux/list.h>=0A #include <linux/mm.h>=0A-#include <linux/mman.h=
>=0A-#include <linux/smp_lock.h>=0A-#include <linux/pagemap.h>=0A #include =
<linux/bootmem.h>=0A #include <linux/highmem.h>=0A-#include <linux/vmalloc.=
h>=0A #include <linux/mutex.h>=0A #include <xen/xen_proc.h>=0A #include =
<asm/hypervisor.h>=0A@@ -54,8 +50,6 @@=0A #include <asm/pgtable.h>=0A =
#include <asm/uaccess.h>=0A #include <asm/tlb.h>=0A-#include <linux/highmem=
.h>=0A-#include <linux/list.h>=0A #include <xen/xenbus.h>=0A #include =
"common.h"=0A =0A--- a/drivers/xen/char/mem.c=0A+++ b/drivers/xen/char/mem.=
c=0A@@ -9,19 +9,10 @@=0A  */=0A =0A #include <linux/mm.h>=0A-#include =
<linux/miscdevice.h>=0A-#include <linux/slab.h>=0A-#include <linux/vmalloc.=
h>=0A-#include <linux/mman.h>=0A-#include <linux/random.h>=0A #include =
<linux/init.h>=0A-#include <linux/raw.h>=0A-#include <linux/tty.h>=0A+#incl=
ude <linux/fs.h>=0A #include <linux/capability.h>=0A-#include <linux/smp_lo=
ck.h>=0A #include <linux/ptrace.h>=0A-#include <linux/device.h>=0A-#include=
 <asm/pgalloc.h>=0A #include <asm/uaccess.h>=0A #include <asm/io.h>=0A =
#include <asm/hypervisor.h>=0A--- a/drivers/xen/core/smpboot.c=0A+++ =
b/drivers/xen/core/smpboot.c=0A@@ -11,9 +11,7 @@=0A #include <linux/mm.h>=
=0A #include <linux/sched.h>=0A #include <linux/kernel_stat.h>=0A-#include =
<linux/smp_lock.h>=0A #include <linux/irq.h>=0A-#include <linux/bootmem.h>=
=0A #include <linux/notifier.h>=0A #include <linux/cpu.h>=0A #include =
<linux/percpu.h>=0A--- a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gn=
tdev/gntdev.c=0A@@ -23,7 +23,6 @@=0A #include <linux/fs.h>=0A #include =
<linux/miscdevice.h>=0A #include <linux/mm.h>=0A-#include <linux/mman.h>=0A=
 #include <asm/uaccess.h>=0A #include <asm/io.h>=0A #include <xen/gnttab.h>=
=0A--- a/drivers/xen/pciback/xenbus.c=0A+++ b/drivers/xen/pciback/xenbus.c=
=0A@@ -6,7 +6,6 @@=0A #include <linux/module.h>=0A #include <linux/init.h>=
=0A #include <linux/list.h>=0A-#include <linux/vmalloc.h>=0A #include =
<xen/xenbus.h>=0A #include <xen/evtchn.h>=0A #include "pciback.h"=0A--- =
a/drivers/xen/privcmd/privcmd.c=0A+++ b/drivers/xen/privcmd/privcmd.c=0A@@ =
-12,12 +12,6 @@=0A #include <linux/string.h>=0A #include <linux/errno.h>=0A=
 #include <linux/mm.h>=0A-#include <linux/mman.h>=0A-#include <linux/swap.h=
>=0A-#include <linux/smp_lock.h>=0A-#include <linux/highmem.h>=0A-#include =
<linux/pagemap.h>=0A-#include <linux/seq_file.h>=0A #include <asm/hyperviso=
r.h>=0A =0A #include <asm/pgalloc.h>=0A--- a/drivers/xen/scsiback/common.h=
=0A+++ b/drivers/xen/scsiback/common.h=0A@@ -34,7 +34,6 @@=0A #include =
<linux/module.h>=0A #include <linux/interrupt.h>=0A #include <linux/slab.h>=
=0A-#include <linux/vmalloc.h>=0A #include <linux/wait.h>=0A #include =
<linux/sched.h>=0A #include <linux/kthread.h>=0A--- a/drivers/xen/usbback/u=
sbback.h=0A+++ b/drivers/xen/usbback/usbback.h=0A@@ -50,7 +50,6 @@=0A =
#include <linux/interrupt.h>=0A #include <linux/slab.h>=0A #include =
<linux/usb.h>=0A-#include <linux/vmalloc.h>=0A #include <linux/kthread.h>=
=0A #include <linux/wait.h>=0A #include <linux/list.h>=0A
--=__Part755B2F5B.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

--=__Part755B2F5B.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:48:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12: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 1RnrPn-0005Ab-Qi; Thu, 19 Jan 2012 12:48: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 1RnrPm-00059p-BW
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:48:26 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1326977291!4226584!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 16220 invoked from network); 19 Jan 2012 12:48:11 -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; 19 Jan 2012 12:48:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 12:48:10 +0000
Message-Id: <4F181F5B020000780006DA95@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 12:49:15 +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="=__Part755B2F5B.0__="
Subject: [Xen-devel] linux-2.6.18/drivers/xen/: remove stray inclusion of
 various 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.

--=__Part755B2F5B.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

More than once (perhaps through copy-and-paste) occurring were
- mman.h
- pagemap.h
- smp_lock.h
- vmalloc.h

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/balloon/balloon.c
+++ b/drivers/xen/balloon/balloon.c
@@ -36,13 +36,10 @@
 #include <linux/module.h>
 #include <linux/sched.h>
 #include <linux/errno.h>
+#include <linux/list.h>
 #include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/smp_lock.h>
-#include <linux/pagemap.h>
 #include <linux/bootmem.h>
 #include <linux/highmem.h>
-#include <linux/vmalloc.h>
 #include <linux/mutex.h>
 #include <xen/xen_proc.h>
 #include <asm/hypervisor.h>
@@ -54,8 +50,6 @@
 #include <asm/pgtable.h>
 #include <asm/uaccess.h>
 #include <asm/tlb.h>
-#include <linux/highmem.h>
-#include <linux/list.h>
 #include <xen/xenbus.h>
 #include "common.h"
=20
--- a/drivers/xen/char/mem.c
+++ b/drivers/xen/char/mem.c
@@ -9,19 +9,10 @@
  */
=20
 #include <linux/mm.h>
-#include <linux/miscdevice.h>
-#include <linux/slab.h>
-#include <linux/vmalloc.h>
-#include <linux/mman.h>
-#include <linux/random.h>
 #include <linux/init.h>
-#include <linux/raw.h>
-#include <linux/tty.h>
+#include <linux/fs.h>
 #include <linux/capability.h>
-#include <linux/smp_lock.h>
 #include <linux/ptrace.h>
-#include <linux/device.h>
-#include <asm/pgalloc.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <asm/hypervisor.h>
--- a/drivers/xen/core/smpboot.c
+++ b/drivers/xen/core/smpboot.c
@@ -11,9 +11,7 @@
 #include <linux/mm.h>
 #include <linux/sched.h>
 #include <linux/kernel_stat.h>
-#include <linux/smp_lock.h>
 #include <linux/irq.h>
-#include <linux/bootmem.h>
 #include <linux/notifier.h>
 #include <linux/cpu.h>
 #include <linux/percpu.h>
--- a/drivers/xen/gntdev/gntdev.c
+++ b/drivers/xen/gntdev/gntdev.c
@@ -23,7 +23,6 @@
 #include <linux/fs.h>
 #include <linux/miscdevice.h>
 #include <linux/mm.h>
-#include <linux/mman.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 #include <xen/gnttab.h>
--- a/drivers/xen/pciback/xenbus.c
+++ b/drivers/xen/pciback/xenbus.c
@@ -6,7 +6,6 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/list.h>
-#include <linux/vmalloc.h>
 #include <xen/xenbus.h>
 #include <xen/evtchn.h>
 #include "pciback.h"
--- a/drivers/xen/privcmd/privcmd.c
+++ b/drivers/xen/privcmd/privcmd.c
@@ -12,12 +12,6 @@
 #include <linux/string.h>
 #include <linux/errno.h>
 #include <linux/mm.h>
-#include <linux/mman.h>
-#include <linux/swap.h>
-#include <linux/smp_lock.h>
-#include <linux/highmem.h>
-#include <linux/pagemap.h>
-#include <linux/seq_file.h>
 #include <asm/hypervisor.h>
=20
 #include <asm/pgalloc.h>
--- a/drivers/xen/scsiback/common.h
+++ b/drivers/xen/scsiback/common.h
@@ -34,7 +34,6 @@
 #include <linux/module.h>
 #include <linux/interrupt.h>
 #include <linux/slab.h>
-#include <linux/vmalloc.h>
 #include <linux/wait.h>
 #include <linux/sched.h>
 #include <linux/kthread.h>
--- a/drivers/xen/usbback/usbback.h
+++ b/drivers/xen/usbback/usbback.h
@@ -50,7 +50,6 @@
 #include <linux/interrupt.h>
 #include <linux/slab.h>
 #include <linux/usb.h>
-#include <linux/vmalloc.h>
 #include <linux/kthread.h>
 #include <linux/wait.h>
 #include <linux/list.h>




--=__Part755B2F5B.0__=
Content-Type: text/plain; name="xen-no-mman-h.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-no-mman-h.patch"

drivers/xen/: remove stray inclusion of various headers=0A=0AMore than =
once (perhaps through copy-and-paste) occurring were=0A- mman.h=0A- =
pagemap.h=0A- smp_lock.h=0A- vmalloc.h=0A=0ASigned-off-by: Jan Beulich =
<jbeulich@suse.com>=0A=0A--- a/drivers/xen/balloon/balloon.c=0A+++ =
b/drivers/xen/balloon/balloon.c=0A@@ -36,13 +36,10 @@=0A #include =
<linux/module.h>=0A #include <linux/sched.h>=0A #include <linux/errno.h>=0A=
+#include <linux/list.h>=0A #include <linux/mm.h>=0A-#include <linux/mman.h=
>=0A-#include <linux/smp_lock.h>=0A-#include <linux/pagemap.h>=0A #include =
<linux/bootmem.h>=0A #include <linux/highmem.h>=0A-#include <linux/vmalloc.=
h>=0A #include <linux/mutex.h>=0A #include <xen/xen_proc.h>=0A #include =
<asm/hypervisor.h>=0A@@ -54,8 +50,6 @@=0A #include <asm/pgtable.h>=0A =
#include <asm/uaccess.h>=0A #include <asm/tlb.h>=0A-#include <linux/highmem=
.h>=0A-#include <linux/list.h>=0A #include <xen/xenbus.h>=0A #include =
"common.h"=0A =0A--- a/drivers/xen/char/mem.c=0A+++ b/drivers/xen/char/mem.=
c=0A@@ -9,19 +9,10 @@=0A  */=0A =0A #include <linux/mm.h>=0A-#include =
<linux/miscdevice.h>=0A-#include <linux/slab.h>=0A-#include <linux/vmalloc.=
h>=0A-#include <linux/mman.h>=0A-#include <linux/random.h>=0A #include =
<linux/init.h>=0A-#include <linux/raw.h>=0A-#include <linux/tty.h>=0A+#incl=
ude <linux/fs.h>=0A #include <linux/capability.h>=0A-#include <linux/smp_lo=
ck.h>=0A #include <linux/ptrace.h>=0A-#include <linux/device.h>=0A-#include=
 <asm/pgalloc.h>=0A #include <asm/uaccess.h>=0A #include <asm/io.h>=0A =
#include <asm/hypervisor.h>=0A--- a/drivers/xen/core/smpboot.c=0A+++ =
b/drivers/xen/core/smpboot.c=0A@@ -11,9 +11,7 @@=0A #include <linux/mm.h>=
=0A #include <linux/sched.h>=0A #include <linux/kernel_stat.h>=0A-#include =
<linux/smp_lock.h>=0A #include <linux/irq.h>=0A-#include <linux/bootmem.h>=
=0A #include <linux/notifier.h>=0A #include <linux/cpu.h>=0A #include =
<linux/percpu.h>=0A--- a/drivers/xen/gntdev/gntdev.c=0A+++ b/drivers/xen/gn=
tdev/gntdev.c=0A@@ -23,7 +23,6 @@=0A #include <linux/fs.h>=0A #include =
<linux/miscdevice.h>=0A #include <linux/mm.h>=0A-#include <linux/mman.h>=0A=
 #include <asm/uaccess.h>=0A #include <asm/io.h>=0A #include <xen/gnttab.h>=
=0A--- a/drivers/xen/pciback/xenbus.c=0A+++ b/drivers/xen/pciback/xenbus.c=
=0A@@ -6,7 +6,6 @@=0A #include <linux/module.h>=0A #include <linux/init.h>=
=0A #include <linux/list.h>=0A-#include <linux/vmalloc.h>=0A #include =
<xen/xenbus.h>=0A #include <xen/evtchn.h>=0A #include "pciback.h"=0A--- =
a/drivers/xen/privcmd/privcmd.c=0A+++ b/drivers/xen/privcmd/privcmd.c=0A@@ =
-12,12 +12,6 @@=0A #include <linux/string.h>=0A #include <linux/errno.h>=0A=
 #include <linux/mm.h>=0A-#include <linux/mman.h>=0A-#include <linux/swap.h=
>=0A-#include <linux/smp_lock.h>=0A-#include <linux/highmem.h>=0A-#include =
<linux/pagemap.h>=0A-#include <linux/seq_file.h>=0A #include <asm/hyperviso=
r.h>=0A =0A #include <asm/pgalloc.h>=0A--- a/drivers/xen/scsiback/common.h=
=0A+++ b/drivers/xen/scsiback/common.h=0A@@ -34,7 +34,6 @@=0A #include =
<linux/module.h>=0A #include <linux/interrupt.h>=0A #include <linux/slab.h>=
=0A-#include <linux/vmalloc.h>=0A #include <linux/wait.h>=0A #include =
<linux/sched.h>=0A #include <linux/kthread.h>=0A--- a/drivers/xen/usbback/u=
sbback.h=0A+++ b/drivers/xen/usbback/usbback.h=0A@@ -50,7 +50,6 @@=0A =
#include <linux/interrupt.h>=0A #include <linux/slab.h>=0A #include =
<linux/usb.h>=0A-#include <linux/vmalloc.h>=0A #include <linux/kthread.h>=
=0A #include <linux/wait.h>=0A #include <linux/list.h>=0A
--=__Part755B2F5B.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

--=__Part755B2F5B.0__=--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:53:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12: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 1RnrUd-0005VI-Lm; Thu, 19 Jan 2012 12:53: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 1RnrUc-0005V7-Pz
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:53:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326977600!11668179!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 24604 invoked from network); 19 Jan 2012 12:53:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 12:53:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnrUT-000Hta-Rw; Thu, 19 Jan 2012 12:53:17 +0000
Date: Thu, 19 Jan 2012 12:53:17 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119125317.GG66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<98cc0713476ff072635b.1326682587@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <98cc0713476ff072635b.1326682587@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 07 of 12] 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

At 21:56 -0500 on 15 Jan (1326664587), Andres Lagar-Cavilla wrote:
>  xen/arch/ia64/xen/mm.c  |   5 +++++
>  xen/arch/x86/mm.c       |  14 ++++++++++++++
>  xen/common/keyhandler.c |   7 +++++--
>  xen/include/xen/mm.h    |   3 +++
>  4 files changed, 27 insertions(+), 2 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:53:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12: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 1RnrUd-0005VI-Lm; Thu, 19 Jan 2012 12:53: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 1RnrUc-0005V7-Pz
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:53:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1326977600!11668179!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 24604 invoked from network); 19 Jan 2012 12:53:20 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 12:53:20 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnrUT-000Hta-Rw; Thu, 19 Jan 2012 12:53:17 +0000
Date: Thu, 19 Jan 2012 12:53:17 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119125317.GG66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<98cc0713476ff072635b.1326682587@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <98cc0713476ff072635b.1326682587@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 07 of 12] 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

At 21:56 -0500 on 15 Jan (1326664587), Andres Lagar-Cavilla wrote:
>  xen/arch/ia64/xen/mm.c  |   5 +++++
>  xen/arch/x86/mm.c       |  14 ++++++++++++++
>  xen/common/keyhandler.c |   7 +++++--
>  xen/include/xen/mm.h    |   3 +++
>  4 files changed, 27 insertions(+), 2 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Acked-by: Tim Deegan <tim@xen.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:58:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12: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 1RnrZJ-0005qj-2L; Thu, 19 Jan 2012 12:58:17 +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 1RnrZH-0005pl-CK
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:58:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326977888!9653878!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5NDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7247 invoked from network); 19 Jan 2012 12:58:09 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-16.tower-174.messagelabs.com with SMTP;
	19 Jan 2012 12:58:09 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 543674B0097;
	Thu, 19 Jan 2012 04:58: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=W/smABxJKBWaY8aauhrClXAL0WGeoNwtKcwiHGPkw6KF
	VPaG/Vm39ui8eWhGBKyw8MqGaU5hTiTtmSJsdVac7pLbhMtNsDatI1mhu57N/msW
	Z1zKXk/F+ifAF9MVIfdYFVWvGsHx5Wb4O9Cn6U0plIjpplOKeFM2WAUjPmWm1vo=
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=huBA6lSBssbH57d7zX/evukmrtw=; b=irV7RSOu
	Emcygshvdd/b9cJwBbTw56Q3JtoRr/dz93IWrDNN5OEUTBUPBhnqv6QVkvOtePs+
	iQ6+3Li3yFr3P6vBjRWe8F14JMAAsRYTaL44OuFJ+beq1vVvffoABeAAI0n+sSG7
	i7AxPg1tifpdq2H/Dk8Qu6j1Xzt/PuqPhcY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 097004B006D; 
	Thu, 19 Jan 2012 04:58:08 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 04:58:08 -0800
Message-ID: <0dbc3a25de46c81f6784cb4745137be6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119110156.GA66164@ocelot.phlegethon.org>
References: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
	<20120119110156.GA66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 04:58: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: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] EPT: refine epte_present test
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,
>
> I agree with the idea of this patch but:
>
>> +static inline bool_t is_epte_valid(ept_entry_t *e)
>> +{
>> +    ept_entry_t rights = { .epte = 0 };
>> +
>> +    /* Not valid if empty */
>> +    if (e->epte == 0) return 0;
>> +
>> +    /* Not valid if mfn not valid */
>> +    if ( !mfn_valid(e->mfn) ) return 0;
>> +
>> +    /* Not valid if rights different from those of
>> +     * its p2m type and access combination */
>> +    ept_p2m_type_to_flags(&rights, e->sa_p2mt, e->access);
>> +    if ( epte_permissions(&rights) != epte_permissions(e) )
>> +        return 0;
>
> This is a rather odd set of tests.  Since we construct EPT pagetables
> ourselves, I think that we only need to test for uninitialised entries
> and explicitly invalid entries.
>
> Does this patch work for you?

It will achieve the stated goal. I am curious as to whether we should
check for p2m_broken. In any case:
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

>
> diff -r f5b366c6c4c6 xen/arch/x86/mm/p2m-ept.c
> --- a/xen/arch/x86/mm/p2m-ept.c	Thu Jan 19 10:42:42 2012 +0000
> +++ b/xen/arch/x86/mm/p2m-ept.c	Thu Jan 19 11:01:34 2012 +0000
> @@ -41,6 +41,10 @@
>
>  #define is_epte_present(ept_entry)      ((ept_entry)->epte & 0x7)
>  #define is_epte_superpage(ept_entry)    ((ept_entry)->sp)
> +static inline bool_t is_epte_valid(ept_entry_t *e)
> +{
> +    return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
> +}
>
>  /* Non-ept "lock-and-check" wrapper */
>  static int ept_pod_check_and_populate(struct p2m_domain *p2m, unsigned
> long gfn,
> @@ -777,7 +781,7 @@ static void ept_change_entry_type_page(m
>
>      for ( int i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
>      {
> -        if ( !is_epte_present(epte + i) )
> +        if ( !is_epte_valid(epte + i) )
>              continue;
>
>          if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:58:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12: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 1RnrZJ-0005qj-2L; Thu, 19 Jan 2012 12:58:17 +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 1RnrZH-0005pl-CK
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:58:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326977888!9653878!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5NDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7247 invoked from network); 19 Jan 2012 12:58:09 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-16.tower-174.messagelabs.com with SMTP;
	19 Jan 2012 12:58:09 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 543674B0097;
	Thu, 19 Jan 2012 04:58: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=W/smABxJKBWaY8aauhrClXAL0WGeoNwtKcwiHGPkw6KF
	VPaG/Vm39ui8eWhGBKyw8MqGaU5hTiTtmSJsdVac7pLbhMtNsDatI1mhu57N/msW
	Z1zKXk/F+ifAF9MVIfdYFVWvGsHx5Wb4O9Cn6U0plIjpplOKeFM2WAUjPmWm1vo=
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=huBA6lSBssbH57d7zX/evukmrtw=; b=irV7RSOu
	Emcygshvdd/b9cJwBbTw56Q3JtoRr/dz93IWrDNN5OEUTBUPBhnqv6QVkvOtePs+
	iQ6+3Li3yFr3P6vBjRWe8F14JMAAsRYTaL44OuFJ+beq1vVvffoABeAAI0n+sSG7
	i7AxPg1tifpdq2H/Dk8Qu6j1Xzt/PuqPhcY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 097004B006D; 
	Thu, 19 Jan 2012 04:58:08 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 04:58:08 -0800
Message-ID: <0dbc3a25de46c81f6784cb4745137be6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119110156.GA66164@ocelot.phlegethon.org>
References: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
	<20120119110156.GA66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 04:58: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: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] EPT: refine epte_present test
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,
>
> I agree with the idea of this patch but:
>
>> +static inline bool_t is_epte_valid(ept_entry_t *e)
>> +{
>> +    ept_entry_t rights = { .epte = 0 };
>> +
>> +    /* Not valid if empty */
>> +    if (e->epte == 0) return 0;
>> +
>> +    /* Not valid if mfn not valid */
>> +    if ( !mfn_valid(e->mfn) ) return 0;
>> +
>> +    /* Not valid if rights different from those of
>> +     * its p2m type and access combination */
>> +    ept_p2m_type_to_flags(&rights, e->sa_p2mt, e->access);
>> +    if ( epte_permissions(&rights) != epte_permissions(e) )
>> +        return 0;
>
> This is a rather odd set of tests.  Since we construct EPT pagetables
> ourselves, I think that we only need to test for uninitialised entries
> and explicitly invalid entries.
>
> Does this patch work for you?

It will achieve the stated goal. I am curious as to whether we should
check for p2m_broken. In any case:
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

>
> diff -r f5b366c6c4c6 xen/arch/x86/mm/p2m-ept.c
> --- a/xen/arch/x86/mm/p2m-ept.c	Thu Jan 19 10:42:42 2012 +0000
> +++ b/xen/arch/x86/mm/p2m-ept.c	Thu Jan 19 11:01:34 2012 +0000
> @@ -41,6 +41,10 @@
>
>  #define is_epte_present(ept_entry)      ((ept_entry)->epte & 0x7)
>  #define is_epte_superpage(ept_entry)    ((ept_entry)->sp)
> +static inline bool_t is_epte_valid(ept_entry_t *e)
> +{
> +    return (e->epte != 0 && e->sa_p2mt != p2m_invalid);
> +}
>
>  /* Non-ept "lock-and-check" wrapper */
>  static int ept_pod_check_and_populate(struct p2m_domain *p2m, unsigned
> long gfn,
> @@ -777,7 +781,7 @@ static void ept_change_entry_type_page(m
>
>      for ( int i = 0; i < EPT_PAGETABLE_ENTRIES; i++ )
>      {
> -        if ( !is_epte_present(epte + i) )
> +        if ( !is_epte_valid(epte + i) )
>              continue;
>
>          if ( (ept_page_level > 0) && !is_epte_superpage(epte + i) )
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:59:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:59:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnraQ-00060E-NB; Thu, 19 Jan 2012 12:59:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RnraO-0005zQ-U6
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:59:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326977958!13066379!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 29747 invoked from network); 19 Jan 2012 12:59:18 -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; 19 Jan 2012 12:59:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnraH-000Hv1-DL; Thu, 19 Jan 2012 12:59:17 +0000
Date: Thu, 19 Jan 2012 12:59:17 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119125917.GH66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<288ac8cfea7f190a5822.1326682588@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <288ac8cfea7f190a5822.1326682588@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 08 of 12] 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

At 21:56 -0500 on 15 Jan (1326664588), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c     |  94 +++++++++++++++++---------------------
>  xen/arch/x86/mm/mm-locks.h        |  18 -------
>  xen/include/asm-x86/mem_sharing.h |   1 +
>  3 files changed, 43 insertions(+), 70 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

I suspect you'll get errors because this

> @@ -215,11 +215,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);
>  

is no longer protected by a lock, but since they're not fatal, that's
OK. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 12:59:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 12:59:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnraQ-00060E-NB; Thu, 19 Jan 2012 12:59:26 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RnraO-0005zQ-U6
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 12:59:25 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1326977958!13066379!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 29747 invoked from network); 19 Jan 2012 12:59:18 -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; 19 Jan 2012 12:59:18 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnraH-000Hv1-DL; Thu, 19 Jan 2012 12:59:17 +0000
Date: Thu, 19 Jan 2012 12:59:17 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119125917.GH66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<288ac8cfea7f190a5822.1326682588@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <288ac8cfea7f190a5822.1326682588@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 08 of 12] 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

At 21:56 -0500 on 15 Jan (1326664588), Andres Lagar-Cavilla wrote:
>  xen/arch/x86/mm/mem_sharing.c     |  94 +++++++++++++++++---------------------
>  xen/arch/x86/mm/mm-locks.h        |  18 -------
>  xen/include/asm-x86/mem_sharing.h |   1 +
>  3 files changed, 43 insertions(+), 70 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Acked-by: Tim Deegan <tim@xen.org>

I suspect you'll get errors because this

> @@ -215,11 +215,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);
>  

is no longer protected by a lock, but since they're not fatal, that's
OK. 

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:00:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrb2-000681-6v; Thu, 19 Jan 2012 13:00:04 +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 1Rnraz-00065R-JS
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:00:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326977950!50919496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19963 invoked from network); 19 Jan 2012 12:59:10 -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;
	19 Jan 2012 12:59:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10142682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:59: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, 19 Jan 2012 12:59:57 +0000
Date: Thu, 19 Jan 2012 13:00: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: <1326975887.17599.80.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191259250.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975184-458-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975887.17599.80.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: introduce QEMU_HEADER
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 12:13 +0000, Stefano Stabellini wrote:
> > Introduce a new QEMU_HEADER stored in the Qemu chunk right after the
> > QEMU_SIGNATURE and record length, before the Qemu state, to preserve the
> > physmap informations written by Qemu on xenstore.
> 
> I'm still of the opinion that this should be a new XC_SAVE_ID_*
> (possibly from a new range reserved for toolstakc use) and
> saved/restored via a separate callback from libxc.
> 
> The mess that is the tail of the save/restore protocol is pure
> historical and for backwards compat, we should not be making it any
> worse. An XC_SAVE_ID is exactly equivalent to adding something to the
> tail but uses the extensibility mechanism which we have now built into
> the protocol.

OK, I'll give it a look. I wasn't sure what was legacy and what was
not...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:00:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:00:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrb2-000681-6v; Thu, 19 Jan 2012 13:00:04 +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 1Rnraz-00065R-JS
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:00:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326977950!50919496!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19963 invoked from network); 19 Jan 2012 12:59:10 -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;
	19 Jan 2012 12:59:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10142682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 12:59: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, 19 Jan 2012 12:59:57 +0000
Date: Thu, 19 Jan 2012 13:00: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: <1326975887.17599.80.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191259250.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975184-458-3-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975887.17599.80.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] libxl: introduce QEMU_HEADER
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 12:13 +0000, Stefano Stabellini wrote:
> > Introduce a new QEMU_HEADER stored in the Qemu chunk right after the
> > QEMU_SIGNATURE and record length, before the Qemu state, to preserve the
> > physmap informations written by Qemu on xenstore.
> 
> I'm still of the opinion that this should be a new XC_SAVE_ID_*
> (possibly from a new range reserved for toolstakc use) and
> saved/restored via a separate callback from libxc.
> 
> The mess that is the tail of the save/restore protocol is pure
> historical and for backwards compat, we should not be making it any
> worse. An XC_SAVE_ID is exactly equivalent to adding something to the
> tail but uses the extensibility mechanism which we have now built into
> the protocol.

OK, I'll give it a look. I wasn't sure what was legacy and what was
not...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:02:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnrdV-0006PY-PV; Thu, 19 Jan 2012 13:02:37 +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 1RnrdU-0006Ou-L7
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:02:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326978150!11554534!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 10082 invoked from network); 19 Jan 2012 13:02:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 13:02:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnrdO-000HwU-6q; Thu, 19 Jan 2012 13:02:30 +0000
Date: Thu, 19 Jan 2012 13:02:30 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119130230.GI66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <11916fe20dd274ff370b.1326682583@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 12] 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

At 21:56 -0500 on 15 Jan (1326664583), Andres Lagar-Cavilla wrote:
> @@ -510,26 +684,63 @@ 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 )
> +    /* This tricky business is to avoid two callers deadlocking if 
> +     * grabbing pages in opposite client/source order */

I think you need to delete the XXX comment just above. :)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:02:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:02:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnrdV-0006PY-PV; Thu, 19 Jan 2012 13:02:37 +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 1RnrdU-0006Ou-L7
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:02:36 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1326978150!11554534!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 10082 invoked from network); 19 Jan 2012 13:02:30 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 13:02:30 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnrdO-000HwU-6q; Thu, 19 Jan 2012 13:02:30 +0000
Date: Thu, 19 Jan 2012 13:02:30 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119130230.GI66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <11916fe20dd274ff370b.1326682583@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 12] 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

At 21:56 -0500 on 15 Jan (1326664583), Andres Lagar-Cavilla wrote:
> @@ -510,26 +684,63 @@ 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 )
> +    /* This tricky business is to avoid two callers deadlocking if 
> +     * grabbing pages in opposite client/source order */

I think you need to delete the XXX comment just above. :)

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:03:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13: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 1RnreY-0006X8-8B; Thu, 19 Jan 2012 13:03:42 +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 1RnreW-0006WK-Jj
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:03:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326978214!11557144!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5NDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 954 invoked from network); 19 Jan 2012 13:03:34 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-182.messagelabs.com with SMTP;
	19 Jan 2012 13:03:34 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 90BF8300079;
	Thu, 19 Jan 2012 05:03: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=h/OlDCxof/L5N0E30E5P5Q3LSua29rWB9VVAyP8xcvnX
	XlSHksQC+HwoRYIIQFCabtOnriTcu3sZxMEQyNTFA60HcjR2DvA1goQY1wgXBemr
	ahfwHs6sJoCqDkmVxACBD0MimfHAfNSbjZ4kQVi9dJJyrtvZepqoS6ZTB4J+qYg=
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=Ba6aj/OZJmGnq5+2E2+Oz0c0D24=; b=FU/3WRV2
	33ZHJT2kSR//hNHOVfHy6F4C4K1Quk03/qT+6AuevR0sM6R2ewVlKFQFiGheBwoL
	hYSm0u4dSneSz/8J6FVhLemOSFytfc1eBnaroLwyk34mXpcX0mkQ9iOVEdmcMiok
	7c8PAxAWYK4EU0k3SCBhAaGtpa7bl8Qdxhc=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 1C35330006C; 
	Thu, 19 Jan 2012 05:03:33 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 05:03:33 -0800
Message-ID: <9bbf9dd4bff3aff3c64e03080c9cba9e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119125917.GH66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<288ac8cfea7f190a5822.1326682588@xdev.gridcentric.ca>
	<20120119125917.GH66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 05:03:33 -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 08 of 12] 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
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 21:56 -0500 on 15 Jan (1326664588), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c     |  94
>> +++++++++++++++++---------------------
>>  xen/arch/x86/mm/mm-locks.h        |  18 -------
>>  xen/include/asm-x86/mem_sharing.h |   1 +
>>  3 files changed, 43 insertions(+), 70 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Acked-by: Tim Deegan <tim@xen.org>
>
> I suspect you'll get errors because this
>
>> @@ -215,11 +215,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);
>>
>
> is no longer protected by a lock, but since they're not fatal, that's
> OK.
Absolutely. We can live with those, though, and the intent is mostly to
stare at that console and see if any of the more horrible conditions pop
up.

Once you're done with the series I'll try to address all/most of your
concerns and resend a batch update. Hopefully by 11am EST.

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 Thu Jan 19 13:03:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13: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 1RnreY-0006X8-8B; Thu, 19 Jan 2012 13:03:42 +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 1RnreW-0006WK-Jj
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:03:40 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1326978214!11557144!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc5NDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 954 invoked from network); 19 Jan 2012 13:03:34 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-182.messagelabs.com with SMTP;
	19 Jan 2012 13:03:34 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 90BF8300079;
	Thu, 19 Jan 2012 05:03: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=h/OlDCxof/L5N0E30E5P5Q3LSua29rWB9VVAyP8xcvnX
	XlSHksQC+HwoRYIIQFCabtOnriTcu3sZxMEQyNTFA60HcjR2DvA1goQY1wgXBemr
	ahfwHs6sJoCqDkmVxACBD0MimfHAfNSbjZ4kQVi9dJJyrtvZepqoS6ZTB4J+qYg=
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=Ba6aj/OZJmGnq5+2E2+Oz0c0D24=; b=FU/3WRV2
	33ZHJT2kSR//hNHOVfHy6F4C4K1Quk03/qT+6AuevR0sM6R2ewVlKFQFiGheBwoL
	hYSm0u4dSneSz/8J6FVhLemOSFytfc1eBnaroLwyk34mXpcX0mkQ9iOVEdmcMiok
	7c8PAxAWYK4EU0k3SCBhAaGtpa7bl8Qdxhc=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 1C35330006C; 
	Thu, 19 Jan 2012 05:03:33 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 05:03:33 -0800
Message-ID: <9bbf9dd4bff3aff3c64e03080c9cba9e.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119125917.GH66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<288ac8cfea7f190a5822.1326682588@xdev.gridcentric.ca>
	<20120119125917.GH66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 05:03:33 -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 08 of 12] 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
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 21:56 -0500 on 15 Jan (1326664588), Andres Lagar-Cavilla wrote:
>>  xen/arch/x86/mm/mem_sharing.c     |  94
>> +++++++++++++++++---------------------
>>  xen/arch/x86/mm/mm-locks.h        |  18 -------
>>  xen/include/asm-x86/mem_sharing.h |   1 +
>>  3 files changed, 43 insertions(+), 70 deletions(-)
>>
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Acked-by: Tim Deegan <tim@xen.org>
>
> I suspect you'll get errors because this
>
>> @@ -215,11 +215,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);
>>
>
> is no longer protected by a lock, but since they're not fatal, that's
> OK.
Absolutely. We can live with those, though, and the intent is mostly to
stare at that console and see if any of the more horrible conditions pop
up.

Once you're done with the series I'll try to address all/most of your
concerns and resend a batch update. Hopefully by 11am EST.

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 Thu Jan 19 13:05:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrfo-0006ex-Nz; Thu, 19 Jan 2012 13:05:00 +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 1Rnrfm-0006eF-Ri
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:04:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326978291!9073616!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 1323 invoked from network); 19 Jan 2012 13:04:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 13:04:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnrfe-000HxP-OE; Thu, 19 Jan 2012 13:04:50 +0000
Date: Thu, 19 Jan 2012 13:04:50 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119130450.GJ66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<da6576b82e1636f264b4.1326682586@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <da6576b82e1636f264b4.1326682586@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 06 of 12] 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

Hi, 

At 21:56 -0500 on 15 Jan (1326664586), Andres Lagar-Cavilla wrote:
> +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 */

You fixed this in the other case; please fix this one too. :)

Otherwise this looks OK.

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 Jan 19 13:05:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:05:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrfo-0006ex-Nz; Thu, 19 Jan 2012 13:05:00 +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 1Rnrfm-0006eF-Ri
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:04:59 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326978291!9073616!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 1323 invoked from network); 19 Jan 2012 13:04:52 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 13:04:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnrfe-000HxP-OE; Thu, 19 Jan 2012 13:04:50 +0000
Date: Thu, 19 Jan 2012 13:04:50 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119130450.GJ66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<da6576b82e1636f264b4.1326682586@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <da6576b82e1636f264b4.1326682586@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 06 of 12] 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

Hi, 

At 21:56 -0500 on 15 Jan (1326664586), Andres Lagar-Cavilla wrote:
> +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 */

You fixed this in the other case; please fix this one too. :)

Otherwise this looks OK.

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 Jan 19 13:06:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnrhA-0006oi-6t; Thu, 19 Jan 2012 13:06: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 1Rnrh8-0006nq-0h
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:06:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326978375!11737776!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODUxNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13477 invoked from network); 19 Jan 2012 13:06:15 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-216.messagelabs.com with SMTP;
	19 Jan 2012 13:06:15 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id B90B9714083;
	Thu, 19 Jan 2012 05:06: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=swy81RYjq7Mj0B3cWBvLZj/NtpUtc+by4qpv0jRbczbx
	qm6jWZz2UWwuhgvjr4wtJhXPo79OaCN4Q5UTtYWRRe3qws0Gfq76Q3V0KCvoiAf7
	YfyypkZw9u6vKLThtcUw+/pBbbelQb54FrQy0aP++Ai/F7aXRjH5zOnYzimdNJ0=
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=+X9Sh5NhUYBIvEphuGULLruRbAs=; b=BHwHg4eo
	3PHY7DZpuMRackezc6oWpyCu4Jbud/n9Qp2bX75G2t5RgU7sBhlmO1nXiY3HuPPS
	ldG2r3ldjE1BK8ZQkxOhcDO0RdOIfpsuHs8DNtbHP1cJHNdBwHR/v7nYTvOoHW3p
	/FABHxIooOUnlTDXPpKcRhU6ZHHx0pWguxQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 1DE29714075; 
	Thu, 19 Jan 2012 05:06:14 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 05:06:14 -0800
Message-ID: <300ebad65ef953dac0d27446195232d3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119130230.GI66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
	<20120119130230.GI66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 05:06:14 -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 03 of 12] 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

> At 21:56 -0500 on 15 Jan (1326664583), Andres Lagar-Cavilla wrote:
>> @@ -510,26 +684,63 @@ 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 )
>> +    /* This tricky business is to avoid two callers deadlocking if
>> +     * grabbing pages in opposite client/source order */
>
> I think you need to delete the XXX comment just above. :)
>
Well, that XXX comment applies if get_gfn locks the p2m, and then what
we're grabbing in mem_sharing_lookup are lock per mfn, essentially. To
prevent deadlock, we will want to sort those p2m locks by ascending
domain, and then by ascending gfn within the same domain, if and when the
p2m lock is broken into fine-grained bits.

That is surely a battle for another day, I hope!
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 Jan 19 13:06:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:06:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnrhA-0006oi-6t; Thu, 19 Jan 2012 13:06: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 1Rnrh8-0006nq-0h
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:06:22 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1326978375!11737776!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODUxNA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13477 invoked from network); 19 Jan 2012 13:06:15 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-5.tower-216.messagelabs.com with SMTP;
	19 Jan 2012 13:06:15 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id B90B9714083;
	Thu, 19 Jan 2012 05:06: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=swy81RYjq7Mj0B3cWBvLZj/NtpUtc+by4qpv0jRbczbx
	qm6jWZz2UWwuhgvjr4wtJhXPo79OaCN4Q5UTtYWRRe3qws0Gfq76Q3V0KCvoiAf7
	YfyypkZw9u6vKLThtcUw+/pBbbelQb54FrQy0aP++Ai/F7aXRjH5zOnYzimdNJ0=
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=+X9Sh5NhUYBIvEphuGULLruRbAs=; b=BHwHg4eo
	3PHY7DZpuMRackezc6oWpyCu4Jbud/n9Qp2bX75G2t5RgU7sBhlmO1nXiY3HuPPS
	ldG2r3ldjE1BK8ZQkxOhcDO0RdOIfpsuHs8DNtbHP1cJHNdBwHR/v7nYTvOoHW3p
	/FABHxIooOUnlTDXPpKcRhU6ZHHx0pWguxQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 1DE29714075; 
	Thu, 19 Jan 2012 05:06:14 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 05:06:14 -0800
Message-ID: <300ebad65ef953dac0d27446195232d3.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119130230.GI66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
	<20120119130230.GI66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 05:06:14 -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 03 of 12] 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

> At 21:56 -0500 on 15 Jan (1326664583), Andres Lagar-Cavilla wrote:
>> @@ -510,26 +684,63 @@ 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 )
>> +    /* This tricky business is to avoid two callers deadlocking if
>> +     * grabbing pages in opposite client/source order */
>
> I think you need to delete the XXX comment just above. :)
>
Well, that XXX comment applies if get_gfn locks the p2m, and then what
we're grabbing in mem_sharing_lookup are lock per mfn, essentially. To
prevent deadlock, we will want to sort those p2m locks by ascending
domain, and then by ascending gfn within the same domain, if and when the
p2m lock is broken into fine-grained bits.

That is surely a battle for another day, I hope!
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 Jan 19 13:07:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnriS-0006z5-Mc; Thu, 19 Jan 2012 13:07:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RnriR-0006yd-4c
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:07:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326978456!7852455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25855 invoked from network); 19 Jan 2012 13:07:37 -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;
	19 Jan 2012 13:07:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10143341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 13:07:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 13:07:20 +0000
Date: Thu, 19 Jan 2012 13:08:00 +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: <1326975896.17599.81.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.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>,
	"jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> > Write to xenstore any physmap changes so that the hypervisor can be
> > aware of them.
> 
> What is the structure of the xenstore values? Looks like 
> 	<domid>/physmap/<original-addr>/start_addr <new-addr>
> ?

Yep, that is the structure


> Who defines the meaning of original-addr, in particular what happens
> if it the original-addr for a device changes in a N->N+1 migration? What
> happens if things overlap or if a subsequent call only updates part of a
> previously moved mapping?

In practice it cannot happen because on restore Qemu is going to emulate
the same set of devices it was emulating before.
The original address is not going to change if the devices and the
amount of guest memory stay the same.

We could add some additional info to better identify the physmap entry,
probably the best we could use is the memory_region name.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:07:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:07:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnriS-0006z5-Mc; Thu, 19 Jan 2012 13:07:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RnriR-0006yd-4c
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:07:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1326978456!7852455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25855 invoked from network); 19 Jan 2012 13:07:37 -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;
	19 Jan 2012 13:07:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,535,1320624000"; d="scan'208";a="10143341"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 13:07:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 13:07:20 +0000
Date: Thu, 19 Jan 2012 13:08:00 +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: <1326975896.17599.81.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.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>,
	"jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> > Write to xenstore any physmap changes so that the hypervisor can be
> > aware of them.
> 
> What is the structure of the xenstore values? Looks like 
> 	<domid>/physmap/<original-addr>/start_addr <new-addr>
> ?

Yep, that is the structure


> Who defines the meaning of original-addr, in particular what happens
> if it the original-addr for a device changes in a N->N+1 migration? What
> happens if things overlap or if a subsequent call only updates part of a
> previously moved mapping?

In practice it cannot happen because on restore Qemu is going to emulate
the same set of devices it was emulating before.
The original address is not going to change if the devices and the
amount of guest memory stay the same.

We could add some additional info to better identify the physmap entry,
probably the best we could use is the memory_region name.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:09:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:09:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrjr-0007C6-6Y; Thu, 19 Jan 2012 13:09: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 1Rnrjp-0007BR-Lm
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:09:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326978542!1533383!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTkyOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1163 invoked from network); 19 Jan 2012 13:09:03 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-21.messagelabs.com with SMTP;
	19 Jan 2012 13:09:03 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 38DF571408D;
	Thu, 19 Jan 2012 05:09:02 -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=UIhPUjXviymGOy0J5PEqPLZk/UPmWMObPrqzbS5ziFtN
	2DHXfyl6Ft0lKhClqZ7IkOetGRp69jCRSBms6WI5ofL6VA+BwwY36u0rvyzny4/Z
	v2KkM22l+8BQ62Kt2vqf3l4Nx+hfOJdY5VfmdBbc+AWsx5tCQ2eOSUofmkS4qns=
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=xUv+6Xf2GGYrs6YXqg5RigxUk0M=; b=JUJxEe33
	krrEqSisfrckFL+bADFBhwT840EQgRcJ52LuZl2PY6ieOJom1eJXnHYBG5fPK0ge
	gcA7Xo3QdlBAR0/Ucn3Wuw+gagXzCJFG38G0HbBPdREZBB/bYN/P1epZXpUQX4sV
	EXj/Hksh0r739CzdQW87loR0StH1+Gr4QNI=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id AF48671408B; 
	Thu, 19 Jan 2012 05:09:01 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 05:09:02 -0800
Message-ID: <4c42a32b63b1308ecaf5617904bbe65d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119130450.GJ66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<da6576b82e1636f264b4.1326682586@xdev.gridcentric.ca>
	<20120119130450.GJ66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 05:09:02 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: 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 06 of 12] 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
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 21:56 -0500 on 15 Jan (1326664586), Andres Lagar-Cavilla wrote:
>> +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 */
>
> You fixed this in the other case; please fix this one too. :)
Maybe this stems from the same confusion as the previous one. We'd still
risk deadlocks on get_gfn. But the add to physmap call only needs to lock
a single mfn.

Andres
>
> Otherwise this looks OK.
>
> 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 Jan 19 13:09:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:09:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrjr-0007C6-6Y; Thu, 19 Jan 2012 13:09: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 1Rnrjp-0007BR-Lm
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:09:09 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326978542!1533383!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTkyOTg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1163 invoked from network); 19 Jan 2012 13:09:03 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.119) by server-9.tower-21.messagelabs.com with SMTP;
	19 Jan 2012 13:09:03 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 38DF571408D;
	Thu, 19 Jan 2012 05:09:02 -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=UIhPUjXviymGOy0J5PEqPLZk/UPmWMObPrqzbS5ziFtN
	2DHXfyl6Ft0lKhClqZ7IkOetGRp69jCRSBms6WI5ofL6VA+BwwY36u0rvyzny4/Z
	v2KkM22l+8BQ62Kt2vqf3l4Nx+hfOJdY5VfmdBbc+AWsx5tCQ2eOSUofmkS4qns=
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=xUv+6Xf2GGYrs6YXqg5RigxUk0M=; b=JUJxEe33
	krrEqSisfrckFL+bADFBhwT840EQgRcJ52LuZl2PY6ieOJom1eJXnHYBG5fPK0ge
	gcA7Xo3QdlBAR0/Ucn3Wuw+gagXzCJFG38G0HbBPdREZBB/bYN/P1epZXpUQX4sV
	EXj/Hksh0r739CzdQW87loR0StH1+Gr4QNI=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id AF48671408B; 
	Thu, 19 Jan 2012 05:09:01 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 05:09:02 -0800
Message-ID: <4c42a32b63b1308ecaf5617904bbe65d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119130450.GJ66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<da6576b82e1636f264b4.1326682586@xdev.gridcentric.ca>
	<20120119130450.GJ66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 05:09:02 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: 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 06 of 12] 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
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 21:56 -0500 on 15 Jan (1326664586), Andres Lagar-Cavilla wrote:
>> +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 */
>
> You fixed this in the other case; please fix this one too. :)
Maybe this stems from the same confusion as the previous one. We'd still
risk deadlocks on get_gfn. But the add to physmap call only needs to lock
a single mfn.

Andres
>
> Otherwise this looks OK.
>
> 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 Jan 19 13:11:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrlu-0007RT-DE; Thu, 19 Jan 2012 13:11: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 1Rnrlt-0007QX-53
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:11:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326978671!11607864!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 21367 invoked from network); 19 Jan 2012 13:11:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 13:11:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnrll-000Hza-Tk; Thu, 19 Jan 2012 13:11:09 +0000
Date: Thu, 19 Jan 2012 13:11:09 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119131109.GK66164@ocelot.phlegethon.org>
References: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
	<20120119110156.GA66164@ocelot.phlegethon.org>
	<0dbc3a25de46c81f6784cb4745137be6.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0dbc3a25de46c81f6784cb4745137be6.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] EPT: refine epte_present test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 04:58 -0800 on 19 Jan (1326949088), Andres Lagar-Cavilla wrote:
> > Hi,
> >
> > I agree with the idea of this patch but:
> >
> >> +static inline bool_t is_epte_valid(ept_entry_t *e)
> >> +{
> >> +    ept_entry_t rights = { .epte = 0 };
> >> +
> >> +    /* Not valid if empty */
> >> +    if (e->epte == 0) return 0;
> >> +
> >> +    /* Not valid if mfn not valid */
> >> +    if ( !mfn_valid(e->mfn) ) return 0;
> >> +
> >> +    /* Not valid if rights different from those of
> >> +     * its p2m type and access combination */
> >> +    ept_p2m_type_to_flags(&rights, e->sa_p2mt, e->access);
> >> +    if ( epte_permissions(&rights) != epte_permissions(e) )
> >> +        return 0;
> >
> > This is a rather odd set of tests.  Since we construct EPT pagetables
> > ourselves, I think that we only need to test for uninitialised entries
> > and explicitly invalid entries.
> >
> > Does this patch work for you?
> 
> It will achieve the stated goal. I am curious as to whether we should
> check for p2m_broken. In any case:
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks.  I've committed the patch as-is; I think in the current code
p2m_ram_broken doesn't need a special case.

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 Jan 19 13:11:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrlu-0007RT-DE; Thu, 19 Jan 2012 13:11: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 1Rnrlt-0007QX-53
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:11:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1326978671!11607864!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 21367 invoked from network); 19 Jan 2012 13:11:11 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 13:11:11 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnrll-000Hza-Tk; Thu, 19 Jan 2012 13:11:09 +0000
Date: Thu, 19 Jan 2012 13:11:09 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119131109.GK66164@ocelot.phlegethon.org>
References: <fa59531b6daa3b377b92.1326400288@xdev.gridcentric.ca>
	<20120119110156.GA66164@ocelot.phlegethon.org>
	<0dbc3a25de46c81f6784cb4745137be6.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <0dbc3a25de46c81f6784cb4745137be6.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] EPT: refine epte_present test
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 04:58 -0800 on 19 Jan (1326949088), Andres Lagar-Cavilla wrote:
> > Hi,
> >
> > I agree with the idea of this patch but:
> >
> >> +static inline bool_t is_epte_valid(ept_entry_t *e)
> >> +{
> >> +    ept_entry_t rights = { .epte = 0 };
> >> +
> >> +    /* Not valid if empty */
> >> +    if (e->epte == 0) return 0;
> >> +
> >> +    /* Not valid if mfn not valid */
> >> +    if ( !mfn_valid(e->mfn) ) return 0;
> >> +
> >> +    /* Not valid if rights different from those of
> >> +     * its p2m type and access combination */
> >> +    ept_p2m_type_to_flags(&rights, e->sa_p2mt, e->access);
> >> +    if ( epte_permissions(&rights) != epte_permissions(e) )
> >> +        return 0;
> >
> > This is a rather odd set of tests.  Since we construct EPT pagetables
> > ourselves, I think that we only need to test for uninitialised entries
> > and explicitly invalid entries.
> >
> > Does this patch work for you?
> 
> It will achieve the stated goal. I am curious as to whether we should
> check for p2m_broken. In any case:
> Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks.  I've committed the patch as-is; I think in the current code
p2m_ram_broken doesn't need a special case.

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 Jan 19 13:13:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13: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 1RnrnQ-0007kU-7s; Thu, 19 Jan 2012 13: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 1RnrnO-0007ip-3U
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:12:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326978763!11724643!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTg4MzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11826 invoked from network); 19 Jan 2012 13:12:43 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-8.tower-216.messagelabs.com with SMTP;
	19 Jan 2012 13:12:43 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id EFBF230008D;
	Thu, 19 Jan 2012 05:12: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=Vjgy93uk0KqBx4XAQ+Sroae/TGTMXu+v77wA6W1zJ115
	xHuqXlwmjI94eMrFlIueAL7QVm5faVXOnYiFtQTOCg+pPmfyB2n8I9kf3okk1oS3
	4KXWifFmDU3QFNAh64Qez8+fqdqH+HutoIYY1KamKt0C2mpHQ1jaEzB8Zf6y/jI=
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=wG1QFJFJr5dbghbot79UBBuMTDU=; b=HyFA/kDa
	djIOmbp//azgMC8s8WBhwJB2OufH95970Q5lO+b/+v0cjJWZ6tZqHIC/sQPoGdaw
	Gap2YjIqlx8lnwIubiMI4EumYdZXB45VJCpdCit3wKj0qTbiu2B2AtI02Cvr+6pM
	fcIo+7oqeKpTDo+f20ymVgaqz5govBM9LOQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 8BF36300080; 
	Thu, 19 Jan 2012 05:12:42 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 05:12:42 -0800
Message-ID: <e51f781e4758a5c845abfc5e1ee9aea7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119113919.GC66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<2a4112172e4497f29d03.1326682581@xdev.gridcentric.ca>
	<20120119113919.GC66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 05:12: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, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 01 of 12] 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
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 seems basically fine; it's a logical progression from the interface
> changes.  A few comments inline below.
>
> One other thing I noticed, which is independent of this patch, really:
> I'm not sure that having a domain ID in the gfn_info is the right
> thing to do.  It seems like we could just carry a domain pointer.
I was wary that accessing the pointer directly might be unsafe if the
domain is gone, and it was better to search the domain on a list when we
needed to.

Other stuff will fix
Andres

>
>
> At 21:56 -0500 on 15 Jan (1326664581), Andres Lagar-Cavilla wrote:
>> The hashtable mechanism used by the sharing code is a bit odd.  It seems
>> unnecessary and adds complexity.
>
> I think that's a bit harsh, since you removed its main use yourself! :)
>
>> 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 302a58874eb1 -r 2a4112172e44 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,30 @@
>>
>>  #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);
>
> Hmmm.  You haven't made any of the callers use this new return value. :(
> Better to leave it as it was.
>
>>  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;
>
> Can you call this field 'sharing' instead?  'shared-info' makes me
> think of the per-domain shared_info page, and tripped me up a few times
> reading this patch. :)
>
> 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 Jan 19 13:13:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13: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 1RnrnQ-0007kU-7s; Thu, 19 Jan 2012 13: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 1RnrnO-0007ip-3U
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:12:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-216.messagelabs.com!1326978763!11724643!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTg4MzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11826 invoked from network); 19 Jan 2012 13:12:43 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-8.tower-216.messagelabs.com with SMTP;
	19 Jan 2012 13:12:43 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id EFBF230008D;
	Thu, 19 Jan 2012 05:12: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=Vjgy93uk0KqBx4XAQ+Sroae/TGTMXu+v77wA6W1zJ115
	xHuqXlwmjI94eMrFlIueAL7QVm5faVXOnYiFtQTOCg+pPmfyB2n8I9kf3okk1oS3
	4KXWifFmDU3QFNAh64Qez8+fqdqH+HutoIYY1KamKt0C2mpHQ1jaEzB8Zf6y/jI=
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=wG1QFJFJr5dbghbot79UBBuMTDU=; b=HyFA/kDa
	djIOmbp//azgMC8s8WBhwJB2OufH95970Q5lO+b/+v0cjJWZ6tZqHIC/sQPoGdaw
	Gap2YjIqlx8lnwIubiMI4EumYdZXB45VJCpdCit3wKj0qTbiu2B2AtI02Cvr+6pM
	fcIo+7oqeKpTDo+f20ymVgaqz5govBM9LOQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 8BF36300080; 
	Thu, 19 Jan 2012 05:12:42 -0800 (PST)
Received: from 69.196.169.239 (proxying for 69.196.169.239)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 05:12:42 -0800
Message-ID: <e51f781e4758a5c845abfc5e1ee9aea7.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120119113919.GC66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<2a4112172e4497f29d03.1326682581@xdev.gridcentric.ca>
	<20120119113919.GC66164@ocelot.phlegethon.org>
Date: Thu, 19 Jan 2012 05:12: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, jbeulich@suse.com,
	ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 01 of 12] 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
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 seems basically fine; it's a logical progression from the interface
> changes.  A few comments inline below.
>
> One other thing I noticed, which is independent of this patch, really:
> I'm not sure that having a domain ID in the gfn_info is the right
> thing to do.  It seems like we could just carry a domain pointer.
I was wary that accessing the pointer directly might be unsafe if the
domain is gone, and it was better to search the domain on a list when we
needed to.

Other stuff will fix
Andres

>
>
> At 21:56 -0500 on 15 Jan (1326664581), Andres Lagar-Cavilla wrote:
>> The hashtable mechanism used by the sharing code is a bit odd.  It seems
>> unnecessary and adds complexity.
>
> I think that's a bit harsh, since you removed its main use yourself! :)
>
>> 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 302a58874eb1 -r 2a4112172e44 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,30 @@
>>
>>  #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);
>
> Hmmm.  You haven't made any of the callers use this new return value. :(
> Better to leave it as it was.
>
>>  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;
>
> Can you call this field 'sharing' instead?  'shared-info' makes me
> think of the per-domain shared_info page, and tripped me up a few times
> reading this patch. :)
>
> 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 Jan 19 13:13:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:13:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrnq-0007pT-MZ; Thu, 19 Jan 2012 13:13:18 +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 1Rnrnp-0007p4-Hb
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:13:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326978768!56385734!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 17331 invoked from network); 19 Jan 2012 13:12:49 -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; 19 Jan 2012 13:12:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnrnm-000I0P-PF; Thu, 19 Jan 2012 13:13:14 +0000
Date: Thu, 19 Jan 2012 13:13:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119131314.GL66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
	<20120119130230.GI66164@ocelot.phlegethon.org>
	<300ebad65ef953dac0d27446195232d3.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <300ebad65ef953dac0d27446195232d3.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 03 of 12] 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

At 05:06 -0800 on 19 Jan (1326949574), Andres Lagar-Cavilla wrote:
> > At 21:56 -0500 on 15 Jan (1326664583), Andres Lagar-Cavilla wrote:
> >> @@ -510,26 +684,63 @@ 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 )
> >> +    /* This tricky business is to avoid two callers deadlocking if
> >> +     * grabbing pages in opposite client/source order */
> >
> > I think you need to delete the XXX comment just above. :)
> >
> Well, that XXX comment applies if get_gfn locks the p2m, and then what
> we're grabbing in mem_sharing_lookup are lock per mfn, essentially. To

Oh, I see - wrong deadlock!. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:13:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:13:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnrnq-0007pT-MZ; Thu, 19 Jan 2012 13:13:18 +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 1Rnrnp-0007p4-Hb
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:13:17 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-27.messagelabs.com!1326978768!56385734!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 17331 invoked from network); 19 Jan 2012 13:12:49 -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; 19 Jan 2012 13:12:49 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnrnm-000I0P-PF; Thu, 19 Jan 2012 13:13:14 +0000
Date: Thu, 19 Jan 2012 13:13:14 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119131314.GL66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<11916fe20dd274ff370b.1326682583@xdev.gridcentric.ca>
	<20120119130230.GI66164@ocelot.phlegethon.org>
	<300ebad65ef953dac0d27446195232d3.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <300ebad65ef953dac0d27446195232d3.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 03 of 12] 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

At 05:06 -0800 on 19 Jan (1326949574), Andres Lagar-Cavilla wrote:
> > At 21:56 -0500 on 15 Jan (1326664583), Andres Lagar-Cavilla wrote:
> >> @@ -510,26 +684,63 @@ 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 )
> >> +    /* This tricky business is to avoid two callers deadlocking if
> >> +     * grabbing pages in opposite client/source order */
> >
> > I think you need to delete the XXX comment just above. :)
> >
> Well, that XXX comment applies if get_gfn locks the p2m, and then what
> we're grabbing in mem_sharing_lookup are lock per mfn, essentially. To

Oh, I see - wrong deadlock!. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:15:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13: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 1RnrpN-00085z-AS; Thu, 19 Jan 2012 13:14:53 +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 1RnrpL-00085f-QI
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:14:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326978774!60391845!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 8008 invoked from network); 19 Jan 2012 13:12:54 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 13:12:54 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnrpJ-000I0q-BZ; Thu, 19 Jan 2012 13:14:49 +0000
Date: Thu, 19 Jan 2012 13:14:49 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119131449.GM66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<288ac8cfea7f190a5822.1326682588@xdev.gridcentric.ca>
	<20120119125917.GH66164@ocelot.phlegethon.org>
	<9bbf9dd4bff3aff3c64e03080c9cba9e.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9bbf9dd4bff3aff3c64e03080c9cba9e.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 08 of 12] 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

At 05:03 -0800 on 19 Jan (1326949413), Andres Lagar-Cavilla wrote:
> > At 21:56 -0500 on 15 Jan (1326664588), Andres Lagar-Cavilla wrote:
> >>  xen/arch/x86/mm/mem_sharing.c     |  94
> >> +++++++++++++++++---------------------
> >>  xen/arch/x86/mm/mm-locks.h        |  18 -------
> >>  xen/include/asm-x86/mem_sharing.h |   1 +
> >>  3 files changed, 43 insertions(+), 70 deletions(-)
> >>
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > Acked-by: Tim Deegan <tim@xen.org>
> >
> > I suspect you'll get errors because this
> >
> >> @@ -215,11 +215,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);
> >>
> >
> > is no longer protected by a lock, but since they're not fatal, that's
> > OK.
> Absolutely. We can live with those, though, and the intent is mostly to
> stare at that console and see if any of the more horrible conditions pop
> up.
> 
> Once you're done with the series I'll try to address all/most of your
> concerns and resend a batch update. Hopefully by 11am EST.


I've said all I have to say for now; I'm unlikely to have time for a
second pass at it today, though. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:15:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13: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 1RnrpN-00085z-AS; Thu, 19 Jan 2012 13:14:53 +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 1RnrpL-00085f-QI
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:14:51 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1326978774!60391845!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 8008 invoked from network); 19 Jan 2012 13:12:54 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 13:12:54 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RnrpJ-000I0q-BZ; Thu, 19 Jan 2012 13:14:49 +0000
Date: Thu, 19 Jan 2012 13:14:49 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119131449.GM66164@ocelot.phlegethon.org>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<288ac8cfea7f190a5822.1326682588@xdev.gridcentric.ca>
	<20120119125917.GH66164@ocelot.phlegethon.org>
	<9bbf9dd4bff3aff3c64e03080c9cba9e.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9bbf9dd4bff3aff3c64e03080c9cba9e.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 08 of 12] 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

At 05:03 -0800 on 19 Jan (1326949413), Andres Lagar-Cavilla wrote:
> > At 21:56 -0500 on 15 Jan (1326664588), Andres Lagar-Cavilla wrote:
> >>  xen/arch/x86/mm/mem_sharing.c     |  94
> >> +++++++++++++++++---------------------
> >>  xen/arch/x86/mm/mm-locks.h        |  18 -------
> >>  xen/include/asm-x86/mem_sharing.h |   1 +
> >>  3 files changed, 43 insertions(+), 70 deletions(-)
> >>
> >>
> >> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> >
> > Acked-by: Tim Deegan <tim@xen.org>
> >
> > I suspect you'll get errors because this
> >
> >> @@ -215,11 +215,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);
> >>
> >
> > is no longer protected by a lock, but since they're not fatal, that's
> > OK.
> Absolutely. We can live with those, though, and the intent is mostly to
> stare at that console and see if any of the more horrible conditions pop
> up.
> 
> Once you're done with the series I'll try to address all/most of your
> concerns and resend a batch update. Hopefully by 11am EST.


I've said all I have to say for now; I'm unlikely to have time for a
second pass at it today, though. :)

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:54:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnsRL-0000qT-P9; Thu, 19 Jan 2012 13:54:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RnsRJ-0000qO-GM
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:54:05 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326981239!8431329!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2OTAyNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11480 invoked from network); 19 Jan 2012 13:53:59 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 13:53:59 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=oMokRXRiYQNsNhwl4HOzLwYihuWrj0U5sSQzNwE9AE5rrNj0VpR0PJTt
	fNbcq2abRBsYwq6dx9gZabTEN6lC7kXxSuBBYeU7LJN/vy3mZJ9px9ixu
	Y11CfeAMNNqgRelAtkyiqJxVJI0l4mFULBhpbGL/0ebbO7BPjg2erBLQM
	uF5Caz72DxAh9XeSenALOKOLVA9qqGd86Mxtl/UV1eK3zbKBJ1Z7AdUoK
	FK88WsmzgIynPs5l/7tORp7o2WBt+;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326981239; x=1358517239;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=zgXj8hgsQ8849tGiRZZtR+jQp+4I4Qo+fs3yY6WCwp4=;
	b=bGXHwRXyLhRqz5p2VumpypBMNdQwC0xvUdZavj2zNw4fn+ePZvciJEZn
	p78cW6eR+wesfoz06CqfQs8DlwhiM0PU4VdHTP2fNQiGcnxnWi1v45vxh
	MkjxA2jz6ULclHxFD/IPL+7aKw/pT230xZSAnznUcmuNFGxZWvQ84Jk4H
	nVyU5Yzt0gz5FrM88N01LsfBkTVAVWipd/hQm4Cbakm2h0Hd9tZlieb2H
	B1QfH404ihU7bidEP5UbOitwTs1lm;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="84012932"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 19 Jan 2012 14:53:58 +0100
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="127383119"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 19 Jan 2012 14:53:58 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id A640F95F1D8;
	Thu, 19 Jan 2012 14:53:58 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 19 Jan 2012 14:53:58 +0100
Message-ID: <3217040.8IcOzn4peW@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 0 of 2] vpmu:preparations for using BTS on intel
	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

Hi,

These 2 patches extends the vpmu implementation mainly for Intel cpus.
The aim is to get a base for using BTS (branch trace store) and possibly PEBS
(precise event-based sampling) facilities of newer Intel cpus in
HVM domUs following in later patches.

First the initialisiations of the PMU of the different architectures
are moved to the special architecture directories.

Second a new function to handle specical PMU cpuid flags is added.
The aim is, to let access the PMU cpuid flags via libxc-cpuid and
switch these of depending on the boot variable opt_vpmu_enabled and
the existing virtualisation of the feature.

Thanks,
Dietmar.


 xen/arch/x86/hvm/svm/vpmu.c       |  26 ++++++++++++++++++++++
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  31 ++++++++++++++++++++++++++
 xen/arch/x86/hvm/vpmu.c           |  45 +++++---------------------------------
 xen/include/asm-x86/hvm/vpmu.h    |   6 +++-
 tools/libxc/xc_cpuid_x86.c        |   1 +
 xen/arch/x86/hvm/vmx/vmx.c        |   2 +
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  38 +++++++++++++++++++++++++++++++-
 xen/arch/x86/hvm/vpmu.c           |  25 +++++++++++++++------
 xen/include/asm-x86/hvm/vpmu.h    |   6 +++++
 9 files changed, 130 insertions(+), 50 deletions(-)


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:54:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:54:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnsRL-0000qT-P9; Thu, 19 Jan 2012 13:54:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RnsRJ-0000qO-GM
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:54:05 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1326981239!8431329!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE2OTAyNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11480 invoked from network); 19 Jan 2012 13:53:59 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 13:53:59 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=oMokRXRiYQNsNhwl4HOzLwYihuWrj0U5sSQzNwE9AE5rrNj0VpR0PJTt
	fNbcq2abRBsYwq6dx9gZabTEN6lC7kXxSuBBYeU7LJN/vy3mZJ9px9ixu
	Y11CfeAMNNqgRelAtkyiqJxVJI0l4mFULBhpbGL/0ebbO7BPjg2erBLQM
	uF5Caz72DxAh9XeSenALOKOLVA9qqGd86Mxtl/UV1eK3zbKBJ1Z7AdUoK
	FK88WsmzgIynPs5l/7tORp7o2WBt+;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326981239; x=1358517239;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=zgXj8hgsQ8849tGiRZZtR+jQp+4I4Qo+fs3yY6WCwp4=;
	b=bGXHwRXyLhRqz5p2VumpypBMNdQwC0xvUdZavj2zNw4fn+ePZvciJEZn
	p78cW6eR+wesfoz06CqfQs8DlwhiM0PU4VdHTP2fNQiGcnxnWi1v45vxh
	MkjxA2jz6ULclHxFD/IPL+7aKw/pT230xZSAnznUcmuNFGxZWvQ84Jk4H
	nVyU5Yzt0gz5FrM88N01LsfBkTVAVWipd/hQm4Cbakm2h0Hd9tZlieb2H
	B1QfH404ihU7bidEP5UbOitwTs1lm;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="84012932"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 19 Jan 2012 14:53:58 +0100
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="127383119"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 19 Jan 2012 14:53:58 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id A640F95F1D8;
	Thu, 19 Jan 2012 14:53:58 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 19 Jan 2012 14:53:58 +0100
Message-ID: <3217040.8IcOzn4peW@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 0 of 2] vpmu:preparations for using BTS on intel
	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

Hi,

These 2 patches extends the vpmu implementation mainly for Intel cpus.
The aim is to get a base for using BTS (branch trace store) and possibly PEBS
(precise event-based sampling) facilities of newer Intel cpus in
HVM domUs following in later patches.

First the initialisiations of the PMU of the different architectures
are moved to the special architecture directories.

Second a new function to handle specical PMU cpuid flags is added.
The aim is, to let access the PMU cpuid flags via libxc-cpuid and
switch these of depending on the boot variable opt_vpmu_enabled and
the existing virtualisation of the feature.

Thanks,
Dietmar.


 xen/arch/x86/hvm/svm/vpmu.c       |  26 ++++++++++++++++++++++
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  31 ++++++++++++++++++++++++++
 xen/arch/x86/hvm/vpmu.c           |  45 +++++---------------------------------
 xen/include/asm-x86/hvm/vpmu.h    |   6 +++-
 tools/libxc/xc_cpuid_x86.c        |   1 +
 xen/arch/x86/hvm/vmx/vmx.c        |   2 +
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  38 +++++++++++++++++++++++++++++++-
 xen/arch/x86/hvm/vpmu.c           |  25 +++++++++++++++------
 xen/include/asm-x86/hvm/vpmu.h    |   6 +++++
 9 files changed, 130 insertions(+), 50 deletions(-)


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:54:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:54:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnsRW-0000r0-5Q; Thu, 19 Jan 2012 13:54:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RnsRU-0000qh-E3
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:54:16 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326981250!11561191!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMTM0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3070 invoked from network); 19 Jan 2012 13:54:10 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 13:54:10 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=n8K7qlSek5O8ExtvSr0jSVEua6BfmyFj9mc/5yHa4bsnbq4uCxNNG3E1
	B95CNZo66lKNc/heJbrYi5yQIrrvNYKMofYo1rR2xR8JotiU2WJrMUJ4+
	i2It8aq63cEJ5D2DvOsfJRe99houFnTT3hJZdDTCq8QyGitKE9wSLHt2O
	qKFumP1vkmRyLwVs/7Abd+osMlMVw4LULe/RgSH4rMTmKrf1zUaoZ8w5Z
	Q1D8NM1GMEbDLKQamQF2LqKvjrY5W;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326981250; x=1358517250;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=SM5XOfaqVClywsfoF/RaKXmnCw29oOHlU7ipxgAWhDo=;
	b=Q8t+KNcaTSsSJ8h89PNjPDwtcSYxFl2Iuwz73cse+Ty5tB6sBZ5xEThu
	bomediUrpavmk8bf/QD8qVkyKaDQ1tVJLuTQxJdaV60rKguccrpTi9e/a
	wnTDEe3jiXu8l09wuhu36/N1Fs2OA4LQg7asB5NOXz9okPnL7ZXcmsBoh
	ILXDgSqTnxrsZ51+sQst8e5tWhFIVtDeLxZYFfumQ+u6qxOvHbUYZWpZP
	G/96pXuQrpGiBpQlV4fZrqQaipp0W;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="99139124"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 19 Jan 2012 14:54:09 +0100
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="127383132"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 19 Jan 2012 14:54:09 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 9EECA95F1D8;
	Thu, 19 Jan 2012 14:54:09 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 14:54:09 +0100
Message-ID: <1612473.SfzFUhiOjP@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 1 of 2] vpmu: separate architecture specific PMU
	initialisation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


 xen/arch/x86/hvm/svm/vpmu.c       |  26 ++++++++++++++++++++++
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  31 ++++++++++++++++++++++++++
 xen/arch/x86/hvm/vpmu.c           |  45 ++++---------------------------------
 xen/include/asm-x86/hvm/vpmu.h    |   6 +++-
 4 files changed, 67 insertions(+), 41 deletions(-)


This patch moves the architecture specific initialisation of the PMU into
the archicture specific directory. Further the boot variable opt_vpmu_enabled
gets global accessible for using in other files.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r 5b2676ac1321 xen/arch/x86/hvm/svm/vpmu.c
--- a/xen/arch/x86/hvm/svm/vpmu.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vpmu.c	Thu Jan 19 13:14:02 2012 +0100
@@ -362,3 +362,29 @@ struct arch_vpmu_ops amd_vpmu_ops = {
     .arch_vpmu_save = amd_vpmu_save,
     .arch_vpmu_load = amd_vpmu_restore
 };
+
+int svm_vpmu_initialize(struct vcpu *v)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    __u8 family = current_cpu_data.x86;
+
+    if ( !opt_vpmu_enabled )
+        return -EINVAL;
+
+    switch ( family )
+    {
+    case 0x10:
+    case 0x12:
+    case 0x14:
+    case 0x15:
+        vpmu->arch_vpmu_ops = &amd_vpmu_ops;
+        break;
+    default:
+        printk("VPMU: Initialization failed. "
+               "AMD processor family %d has not "
+               "been supported\n", family);
+        return -EINVAL;
+    }
+    return 0;
+}
+
diff -r 5b2676ac1321 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Thu Jan 19 13:14:02 2012 +0100
@@ -607,3 +607,34 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .arch_vpmu_save = core2_vpmu_save,
     .arch_vpmu_load = core2_vpmu_load
 };
+
+int vmx_vpmu_initialize(struct vcpu *v)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    __u8 family = current_cpu_data.x86;
+    __u8 cpu_model = current_cpu_data.x86_model;
+
+    if ( !opt_vpmu_enabled )
+        return -EINVAL;
+
+    if ( family == 6 )
+    {
+        switch ( cpu_model )
+        {
+        case 15:
+        case 23:
+        case 26:
+        case 29:
+        case 42:
+        case 46:
+        case 47:
+            vpmu->arch_vpmu_ops = &core2_vpmu_ops;
+            return 0;
+        }
+    }
+    printk("VPMU: Initialization failed. "
+           "Intel processor family %d model %d has not "
+           "been supported\n", family, cpu_model);
+    return -EINVAL;
+}
+
diff -r 5b2676ac1321 xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/hvm/vpmu.c	Thu Jan 19 13:14:02 2012 +0100
@@ -32,7 +32,7 @@
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/vmcb.h>
 
-static bool_t __read_mostly opt_vpmu_enabled;
+bool_t __read_mostly opt_vpmu_enabled;
 boolean_param("vpmu", opt_vpmu_enabled);
 
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content)
@@ -82,11 +82,6 @@ void vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     __u8 vendor = current_cpu_data.x86_vendor;
-    __u8 family = current_cpu_data.x86;
-    __u8 cpu_model = current_cpu_data.x86_model;
-
-    if ( !opt_vpmu_enabled )
-        return;
 
     if ( vpmu->flags & VPMU_CONTEXT_ALLOCATED )
         vpmu_destroy(v);
@@ -94,47 +89,19 @@ void vpmu_initialise(struct vcpu *v)
     switch ( vendor )
     {
     case X86_VENDOR_AMD:
-        switch ( family )
-        {
-        case 0x10:
-        case 0x12:
-        case 0x14:
-        case 0x15:
-            vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-            break;
-        default:
-            printk("VPMU: Initialization failed. "
-                   "AMD processor family %d has not "
-                   "been supported\n", family);
-            return;
-        }
+        if ( svm_vpmu_initialize(v) )
+            opt_vpmu_enabled = 0;
         break;
 
     case X86_VENDOR_INTEL:
-        if ( family == 6 )
-        {
-            switch ( cpu_model )
-            {
-            case 15:
-            case 23:
-            case 26:
-            case 29:
-            case 42:
-            case 46:
-            case 47:
-                vpmu->arch_vpmu_ops = &core2_vpmu_ops;
-                break;
-            }
-        }
-        if ( vpmu->arch_vpmu_ops == NULL )
-            printk("VPMU: Initialization failed. "
-                   "Intel processor family %d model %d has not "
-                   "been supported\n", family, cpu_model);
+        if ( vmx_vpmu_initialize(v) )
+            opt_vpmu_enabled = 0;
         break;
 
     default:
         printk("VPMU: Initialization failed. "
                "Unknown CPU vendor %d\n", vendor);
+        opt_vpmu_enabled = 0;
         break;
     }
 
diff -r 5b2676ac1321 xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Thu Jan 19 13:14:02 2012 +0100
@@ -28,6 +28,8 @@
                                           arch.hvm_vcpu.vpmu))
 #define vpmu_domain(vpmu) (vpmu_vcpu(vpmu)->domain)
 
+extern bool_t opt_vpmu_enabled;
+
 #define MSR_TYPE_COUNTER            0
 #define MSR_TYPE_CTRL               1
 #define MSR_TYPE_GLOBAL             2
@@ -56,8 +58,8 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_load)(struct vcpu *v);
 };
 
-extern struct arch_vpmu_ops core2_vpmu_ops;
-extern struct arch_vpmu_ops amd_vpmu_ops;
+int vmx_vpmu_initialize(struct vcpu *v);
+int svm_vpmu_initialize(struct vcpu *v);
 
 struct vpmu_struct {
     u32 flags;

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:54:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:54:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnsRW-0000r0-5Q; Thu, 19 Jan 2012 13:54:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RnsRU-0000qh-E3
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:54:16 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326981250!11561191!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMTM0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3070 invoked from network); 19 Jan 2012 13:54:10 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 13:54:10 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=n8K7qlSek5O8ExtvSr0jSVEua6BfmyFj9mc/5yHa4bsnbq4uCxNNG3E1
	B95CNZo66lKNc/heJbrYi5yQIrrvNYKMofYo1rR2xR8JotiU2WJrMUJ4+
	i2It8aq63cEJ5D2DvOsfJRe99houFnTT3hJZdDTCq8QyGitKE9wSLHt2O
	qKFumP1vkmRyLwVs/7Abd+osMlMVw4LULe/RgSH4rMTmKrf1zUaoZ8w5Z
	Q1D8NM1GMEbDLKQamQF2LqKvjrY5W;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326981250; x=1358517250;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=SM5XOfaqVClywsfoF/RaKXmnCw29oOHlU7ipxgAWhDo=;
	b=Q8t+KNcaTSsSJ8h89PNjPDwtcSYxFl2Iuwz73cse+Ty5tB6sBZ5xEThu
	bomediUrpavmk8bf/QD8qVkyKaDQ1tVJLuTQxJdaV60rKguccrpTi9e/a
	wnTDEe3jiXu8l09wuhu36/N1Fs2OA4LQg7asB5NOXz9okPnL7ZXcmsBoh
	ILXDgSqTnxrsZ51+sQst8e5tWhFIVtDeLxZYFfumQ+u6qxOvHbUYZWpZP
	G/96pXuQrpGiBpQlV4fZrqQaipp0W;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="99139124"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 19 Jan 2012 14:54:09 +0100
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="127383132"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 19 Jan 2012 14:54:09 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 9EECA95F1D8;
	Thu, 19 Jan 2012 14:54:09 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Date: Thu, 19 Jan 2012 14:54:09 +0100
Message-ID: <1612473.SfzFUhiOjP@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 1 of 2] vpmu: separate architecture specific PMU
	initialisation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


 xen/arch/x86/hvm/svm/vpmu.c       |  26 ++++++++++++++++++++++
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  31 ++++++++++++++++++++++++++
 xen/arch/x86/hvm/vpmu.c           |  45 ++++---------------------------------
 xen/include/asm-x86/hvm/vpmu.h    |   6 +++-
 4 files changed, 67 insertions(+), 41 deletions(-)


This patch moves the architecture specific initialisation of the PMU into
the archicture specific directory. Further the boot variable opt_vpmu_enabled
gets global accessible for using in other files.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r 5b2676ac1321 xen/arch/x86/hvm/svm/vpmu.c
--- a/xen/arch/x86/hvm/svm/vpmu.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/hvm/svm/vpmu.c	Thu Jan 19 13:14:02 2012 +0100
@@ -362,3 +362,29 @@ struct arch_vpmu_ops amd_vpmu_ops = {
     .arch_vpmu_save = amd_vpmu_save,
     .arch_vpmu_load = amd_vpmu_restore
 };
+
+int svm_vpmu_initialize(struct vcpu *v)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    __u8 family = current_cpu_data.x86;
+
+    if ( !opt_vpmu_enabled )
+        return -EINVAL;
+
+    switch ( family )
+    {
+    case 0x10:
+    case 0x12:
+    case 0x14:
+    case 0x15:
+        vpmu->arch_vpmu_ops = &amd_vpmu_ops;
+        break;
+    default:
+        printk("VPMU: Initialization failed. "
+               "AMD processor family %d has not "
+               "been supported\n", family);
+        return -EINVAL;
+    }
+    return 0;
+}
+
diff -r 5b2676ac1321 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Thu Jan 19 13:14:02 2012 +0100
@@ -607,3 +607,34 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .arch_vpmu_save = core2_vpmu_save,
     .arch_vpmu_load = core2_vpmu_load
 };
+
+int vmx_vpmu_initialize(struct vcpu *v)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(v);
+    __u8 family = current_cpu_data.x86;
+    __u8 cpu_model = current_cpu_data.x86_model;
+
+    if ( !opt_vpmu_enabled )
+        return -EINVAL;
+
+    if ( family == 6 )
+    {
+        switch ( cpu_model )
+        {
+        case 15:
+        case 23:
+        case 26:
+        case 29:
+        case 42:
+        case 46:
+        case 47:
+            vpmu->arch_vpmu_ops = &core2_vpmu_ops;
+            return 0;
+        }
+    }
+    printk("VPMU: Initialization failed. "
+           "Intel processor family %d model %d has not "
+           "been supported\n", family, cpu_model);
+    return -EINVAL;
+}
+
diff -r 5b2676ac1321 xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/arch/x86/hvm/vpmu.c	Thu Jan 19 13:14:02 2012 +0100
@@ -32,7 +32,7 @@
 #include <asm/hvm/svm/svm.h>
 #include <asm/hvm/svm/vmcb.h>
 
-static bool_t __read_mostly opt_vpmu_enabled;
+bool_t __read_mostly opt_vpmu_enabled;
 boolean_param("vpmu", opt_vpmu_enabled);
 
 int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content)
@@ -82,11 +82,6 @@ void vpmu_initialise(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
     __u8 vendor = current_cpu_data.x86_vendor;
-    __u8 family = current_cpu_data.x86;
-    __u8 cpu_model = current_cpu_data.x86_model;
-
-    if ( !opt_vpmu_enabled )
-        return;
 
     if ( vpmu->flags & VPMU_CONTEXT_ALLOCATED )
         vpmu_destroy(v);
@@ -94,47 +89,19 @@ void vpmu_initialise(struct vcpu *v)
     switch ( vendor )
     {
     case X86_VENDOR_AMD:
-        switch ( family )
-        {
-        case 0x10:
-        case 0x12:
-        case 0x14:
-        case 0x15:
-            vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-            break;
-        default:
-            printk("VPMU: Initialization failed. "
-                   "AMD processor family %d has not "
-                   "been supported\n", family);
-            return;
-        }
+        if ( svm_vpmu_initialize(v) )
+            opt_vpmu_enabled = 0;
         break;
 
     case X86_VENDOR_INTEL:
-        if ( family == 6 )
-        {
-            switch ( cpu_model )
-            {
-            case 15:
-            case 23:
-            case 26:
-            case 29:
-            case 42:
-            case 46:
-            case 47:
-                vpmu->arch_vpmu_ops = &core2_vpmu_ops;
-                break;
-            }
-        }
-        if ( vpmu->arch_vpmu_ops == NULL )
-            printk("VPMU: Initialization failed. "
-                   "Intel processor family %d model %d has not "
-                   "been supported\n", family, cpu_model);
+        if ( vmx_vpmu_initialize(v) )
+            opt_vpmu_enabled = 0;
         break;
 
     default:
         printk("VPMU: Initialization failed. "
                "Unknown CPU vendor %d\n", vendor);
+        opt_vpmu_enabled = 0;
         break;
     }
 
diff -r 5b2676ac1321 xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Mon Jan 09 16:01:44 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Thu Jan 19 13:14:02 2012 +0100
@@ -28,6 +28,8 @@
                                           arch.hvm_vcpu.vpmu))
 #define vpmu_domain(vpmu) (vpmu_vcpu(vpmu)->domain)
 
+extern bool_t opt_vpmu_enabled;
+
 #define MSR_TYPE_COUNTER            0
 #define MSR_TYPE_CTRL               1
 #define MSR_TYPE_GLOBAL             2
@@ -56,8 +58,8 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_load)(struct vcpu *v);
 };
 
-extern struct arch_vpmu_ops core2_vpmu_ops;
-extern struct arch_vpmu_ops amd_vpmu_ops;
+int vmx_vpmu_initialize(struct vcpu *v);
+int svm_vpmu_initialize(struct vcpu *v);
 
 struct vpmu_struct {
     u32 flags;

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:55:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnsRx-0000tr-It; Thu, 19 Jan 2012 13:54:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RnsRw-0000t1-1k
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:54:44 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326981270!7887010!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMTM0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17598 invoked from network); 19 Jan 2012 13:54:31 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 13:54:31 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=S6fv6d7ObQWdzDw2Pd/JxQ8f304RA1nQGXjp+Ozl08P88wHzEwjgK3Tl
	20okKIVuvz5FMxtYytR5adkg1x0vrJpElS7HVcjBHRD+VS+CXikcoHthz
	lUe7nZbpQIAdKrt5O7WZNBlGtVH6hMEz0SX4EpeGjrLDY9uGe702iongP
	cWAG5w965hhBXIarCaFXTgFkkoNy1zpBEEJ6Bkglf65NNwcnx+fLlXvQG
	S+Bb9FV4kjitMKO/XQOlsxCHvNRRO;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326981272; x=1358517272;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=bwNZXSI0X3jO5zizCHkthv5MFSDY5r+gdE8IXoQfOu0=;
	b=YTrTtvh6mzSrhlkljRe7/kfIVY8cTzY6qUQRrzwt17mdlDIx1HNUHKSv
	/214AMa2QjcQQc421dJlw094sFodItQuLLXo/934CWqNnmH8IpJvIlRvT
	wEQdcBHBcLNo9AX/JeW4PT6z+oLrUHJvL5ktkH45JHkkaPDasYvfi91IY
	uL6mfOs5vvmbzKGSfj6aqV5kwFdhqti/mxJieVF6mh+ipomtLOzI9UhYv
	DFvrEnp8an+J0RZ8Ivf/GBDXCpIpu;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="99139186"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 19 Jan 2012 14:54:30 +0100
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="127383187"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 19 Jan 2012 14:54:29 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id E4F5795F1D8;
	Thu, 19 Jan 2012 14:54:29 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 19 Jan 2012 14:54:29 +0100
Message-ID: <331757089.MKuFJYUFjK@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


 tools/libxc/xc_cpuid_x86.c        |   1 +
 xen/arch/x86/hvm/vmx/vmx.c        |   2 ++
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  38 ++++++++++++++++++++++++++++++++++++--
 xen/arch/x86/hvm/vpmu.c           |  25 ++++++++++++++++++-------
 xen/include/asm-x86/hvm/vpmu.h    |   6 ++++++
 5 files changed, 63 insertions(+), 9 deletions(-)


The  "Debug Store" cpuid flag in the Intel processors gets enabled in the libxc.
A new function call arch_vpmu_cpuid is added to the struct arch_vpmu_ops and for
Intel processors the function core2_vpmu_cpuid() is added.
The aim is that always a "struct arch_vpmu_ops" is accessible at least with
a cpuid function to switch off special PMU cpuid flags dynamically depending on
the boot variable opt_vpmu_enabled.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r 7a82c2e2eb33 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 19 13:14:02 2012 +0100
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Jan 19 14:37:17 2012 +0100
@@ -343,6 +343,7 @@ static void xc_cpuid_hvm_policy(
                     bitmaskof(X86_FEATURE_CMOV) |
                     bitmaskof(X86_FEATURE_PAT) |
                     bitmaskof(X86_FEATURE_CLFLSH) |
+                    bitmaskof(X86_FEATURE_DS) |
                     bitmaskof(X86_FEATURE_PSE36) |
                     bitmaskof(X86_FEATURE_MMX) |
                     bitmaskof(X86_FEATURE_FXSR) |
diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 19 13:14:02 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 19 14:37:17 2012 +0100
@@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
             break;
     }
 
+    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
+
     HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Thu Jan 19 13:14:02 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Thu Jan 19 14:37:17 2012 +0100
@@ -598,6 +598,29 @@ static void core2_vpmu_destroy(struct vc
     vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
 }
 
+/**
+ * core2_vpmu_cpuid - prepare special vpmu cpuid bits
+ * If emulation of vpmu is switched off, some bits are swtiched off, currently:
+ * - EAX[0x1].EAX[Bits 0-7]: PMC revision id.
+ * - EAX[0xa].EDX[Bit 21]:   Debug Store
+ */
+#define bitmaskof(idx)  (1U << ((idx) & 31))
+static void core2_vpmu_cpuid(unsigned int input,
+                             unsigned int *eax, unsigned int *ebx,
+                             unsigned int *ecx, unsigned int *edx)
+{
+    switch ( input )
+    {
+    case 0x1:
+        *edx &= ~bitmaskof(X86_FEATURE_DS);    /* Debug Store not supported */
+        break;
+    case 0xa:
+        if ( !opt_vpmu_enabled )
+            *eax &= ~(unsigned int)0xff;       /* Clear pmc version id. */
+        break;
+    }
+}
+
 struct arch_vpmu_ops core2_vpmu_ops = {
     .do_wrmsr = core2_vpmu_do_wrmsr,
     .do_rdmsr = core2_vpmu_do_rdmsr,
@@ -605,7 +628,13 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .arch_vpmu_initialise = core2_vpmu_initialise,
     .arch_vpmu_destroy = core2_vpmu_destroy,
     .arch_vpmu_save = core2_vpmu_save,
-    .arch_vpmu_load = core2_vpmu_load
+    .arch_vpmu_load = core2_vpmu_load,
+    .arch_vpmu_cpuid = core2_vpmu_cpuid
+};
+
+/* Used if vpmu is disabled. */
+struct arch_vpmu_ops core2_vpmu_dis_ops = {
+    .arch_vpmu_cpuid = core2_vpmu_cpuid
 };
 
 int vmx_vpmu_initialize(struct vcpu *v)
@@ -615,7 +644,7 @@ int vmx_vpmu_initialize(struct vcpu *v)
     __u8 cpu_model = current_cpu_data.x86_model;
 
     if ( !opt_vpmu_enabled )
-        return -EINVAL;
+        goto func_out;
 
     if ( family == 6 )
     {
@@ -635,6 +664,11 @@ int vmx_vpmu_initialize(struct vcpu *v)
     printk("VPMU: Initialization failed. "
            "Intel processor family %d model %d has not "
            "been supported\n", family, cpu_model);
+
+func_out:
+
+    vpmu->arch_vpmu_ops = &core2_vpmu_dis_ops;
+
     return -EINVAL;
 }
 
diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Thu Jan 19 13:14:02 2012 +0100
+++ b/xen/arch/x86/hvm/vpmu.c	Thu Jan 19 14:37:17 2012 +0100
@@ -39,7 +39,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
         return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content);
     return 0;
 }
@@ -48,7 +48,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
         return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
     return 0;
 }
@@ -57,7 +57,7 @@ int vpmu_do_interrupt(struct cpu_user_re
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_interrupt )
         return vpmu->arch_vpmu_ops->do_interrupt(regs);
     return 0;
 }
@@ -66,7 +66,7 @@ void vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_save )
         vpmu->arch_vpmu_ops->arch_vpmu_save(v);
 }
 
@@ -74,7 +74,7 @@ void vpmu_load(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
         vpmu->arch_vpmu_ops->arch_vpmu_load(v);
 }
 
@@ -109,7 +109,8 @@ void vpmu_initialise(struct vcpu *v)
     {
         vpmu->flags = 0;
         vpmu->context = NULL;
-        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
+        if ( vpmu->arch_vpmu_ops->arch_vpmu_initialise )
+            vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
     }
 }
 
@@ -117,7 +118,17 @@ void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
 }
 
+void vpmu_do_cpuid(unsigned int input,
+                   unsigned int *eax, unsigned int *ebx,
+                   unsigned int *ecx, unsigned int *edx)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_cpuid)
+        vpmu->arch_vpmu_ops->arch_vpmu_cpuid(input, eax, ebx, ecx, edx);
+}
+
diff -r 7a82c2e2eb33 xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Thu Jan 19 13:14:02 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Thu Jan 19 14:37:17 2012 +0100
@@ -56,6 +56,9 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_destroy)(struct vcpu *v);
     void (*arch_vpmu_save)(struct vcpu *v);
     void (*arch_vpmu_load)(struct vcpu *v);
+    void (*arch_vpmu_cpuid)(unsigned int input,
+                            unsigned int *eax, unsigned int *ebx,
+                            unsigned int *ecx, unsigned int *edx);
 };
 
 int vmx_vpmu_initialize(struct vcpu *v);
@@ -78,6 +81,9 @@ void vpmu_initialise(struct vcpu *v);
 void vpmu_destroy(struct vcpu *v);
 void vpmu_save(struct vcpu *v);
 void vpmu_load(struct vcpu *v);
+void vpmu_do_cpuid(unsigned int input,
+                   unsigned int *eax, unsigned int *ebx,
+                   unsigned int *ecx, unsigned int *edx);
 
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 13:55:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 13:55:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnsRx-0000tr-It; Thu, 19 Jan 2012 13:54:45 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RnsRw-0000t1-1k
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:54:44 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1326981270!7887010!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIzMTM0NQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17598 invoked from network); 19 Jan 2012 13:54:31 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 13:54:31 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=S6fv6d7ObQWdzDw2Pd/JxQ8f304RA1nQGXjp+Ozl08P88wHzEwjgK3Tl
	20okKIVuvz5FMxtYytR5adkg1x0vrJpElS7HVcjBHRD+VS+CXikcoHthz
	lUe7nZbpQIAdKrt5O7WZNBlGtVH6hMEz0SX4EpeGjrLDY9uGe702iongP
	cWAG5w965hhBXIarCaFXTgFkkoNy1zpBEEJ6Bkglf65NNwcnx+fLlXvQG
	S+Bb9FV4kjitMKO/XQOlsxCHvNRRO;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1326981272; x=1358517272;
	h=from:to:cc:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=bwNZXSI0X3jO5zizCHkthv5MFSDY5r+gdE8IXoQfOu0=;
	b=YTrTtvh6mzSrhlkljRe7/kfIVY8cTzY6qUQRrzwt17mdlDIx1HNUHKSv
	/214AMa2QjcQQc421dJlw094sFodItQuLLXo/934CWqNnmH8IpJvIlRvT
	wEQdcBHBcLNo9AX/JeW4PT6z+oLrUHJvL5ktkH45JHkkaPDasYvfi91IY
	uL6mfOs5vvmbzKGSfj6aqV5kwFdhqti/mxJieVF6mh+ipomtLOzI9UhYv
	DFvrEnp8an+J0RZ8Ivf/GBDXCpIpu;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="99139186"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 19 Jan 2012 14:54:30 +0100
X-IronPort-AV: E=Sophos;i="4.71,535,1320620400"; d="scan'208";a="127383187"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 19 Jan 2012 14:54:29 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id E4F5795F1D8;
	Thu, 19 Jan 2012 14:54:29 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 19 Jan 2012 14:54:29 +0100
Message-ID: <331757089.MKuFJYUFjK@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


 tools/libxc/xc_cpuid_x86.c        |   1 +
 xen/arch/x86/hvm/vmx/vmx.c        |   2 ++
 xen/arch/x86/hvm/vmx/vpmu_core2.c |  38 ++++++++++++++++++++++++++++++++++++--
 xen/arch/x86/hvm/vpmu.c           |  25 ++++++++++++++++++-------
 xen/include/asm-x86/hvm/vpmu.h    |   6 ++++++
 5 files changed, 63 insertions(+), 9 deletions(-)


The  "Debug Store" cpuid flag in the Intel processors gets enabled in the libxc.
A new function call arch_vpmu_cpuid is added to the struct arch_vpmu_ops and for
Intel processors the function core2_vpmu_cpuid() is added.
The aim is that always a "struct arch_vpmu_ops" is accessible at least with
a cpuid function to switch off special PMU cpuid flags dynamically depending on
the boot variable opt_vpmu_enabled.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r 7a82c2e2eb33 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 19 13:14:02 2012 +0100
+++ b/tools/libxc/xc_cpuid_x86.c	Thu Jan 19 14:37:17 2012 +0100
@@ -343,6 +343,7 @@ static void xc_cpuid_hvm_policy(
                     bitmaskof(X86_FEATURE_CMOV) |
                     bitmaskof(X86_FEATURE_PAT) |
                     bitmaskof(X86_FEATURE_CLFLSH) |
+                    bitmaskof(X86_FEATURE_DS) |
                     bitmaskof(X86_FEATURE_PSE36) |
                     bitmaskof(X86_FEATURE_MMX) |
                     bitmaskof(X86_FEATURE_FXSR) |
diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 19 13:14:02 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 19 14:37:17 2012 +0100
@@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
             break;
     }
 
+    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
+
     HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
 }
 
diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vpmu_core2.c
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c	Thu Jan 19 13:14:02 2012 +0100
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c	Thu Jan 19 14:37:17 2012 +0100
@@ -598,6 +598,29 @@ static void core2_vpmu_destroy(struct vc
     vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
 }
 
+/**
+ * core2_vpmu_cpuid - prepare special vpmu cpuid bits
+ * If emulation of vpmu is switched off, some bits are swtiched off, currently:
+ * - EAX[0x1].EAX[Bits 0-7]: PMC revision id.
+ * - EAX[0xa].EDX[Bit 21]:   Debug Store
+ */
+#define bitmaskof(idx)  (1U << ((idx) & 31))
+static void core2_vpmu_cpuid(unsigned int input,
+                             unsigned int *eax, unsigned int *ebx,
+                             unsigned int *ecx, unsigned int *edx)
+{
+    switch ( input )
+    {
+    case 0x1:
+        *edx &= ~bitmaskof(X86_FEATURE_DS);    /* Debug Store not supported */
+        break;
+    case 0xa:
+        if ( !opt_vpmu_enabled )
+            *eax &= ~(unsigned int)0xff;       /* Clear pmc version id. */
+        break;
+    }
+}
+
 struct arch_vpmu_ops core2_vpmu_ops = {
     .do_wrmsr = core2_vpmu_do_wrmsr,
     .do_rdmsr = core2_vpmu_do_rdmsr,
@@ -605,7 +628,13 @@ struct arch_vpmu_ops core2_vpmu_ops = {
     .arch_vpmu_initialise = core2_vpmu_initialise,
     .arch_vpmu_destroy = core2_vpmu_destroy,
     .arch_vpmu_save = core2_vpmu_save,
-    .arch_vpmu_load = core2_vpmu_load
+    .arch_vpmu_load = core2_vpmu_load,
+    .arch_vpmu_cpuid = core2_vpmu_cpuid
+};
+
+/* Used if vpmu is disabled. */
+struct arch_vpmu_ops core2_vpmu_dis_ops = {
+    .arch_vpmu_cpuid = core2_vpmu_cpuid
 };
 
 int vmx_vpmu_initialize(struct vcpu *v)
@@ -615,7 +644,7 @@ int vmx_vpmu_initialize(struct vcpu *v)
     __u8 cpu_model = current_cpu_data.x86_model;
 
     if ( !opt_vpmu_enabled )
-        return -EINVAL;
+        goto func_out;
 
     if ( family == 6 )
     {
@@ -635,6 +664,11 @@ int vmx_vpmu_initialize(struct vcpu *v)
     printk("VPMU: Initialization failed. "
            "Intel processor family %d model %d has not "
            "been supported\n", family, cpu_model);
+
+func_out:
+
+    vpmu->arch_vpmu_ops = &core2_vpmu_dis_ops;
+
     return -EINVAL;
 }
 
diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vpmu.c
--- a/xen/arch/x86/hvm/vpmu.c	Thu Jan 19 13:14:02 2012 +0100
+++ b/xen/arch/x86/hvm/vpmu.c	Thu Jan 19 14:37:17 2012 +0100
@@ -39,7 +39,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
         return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content);
     return 0;
 }
@@ -48,7 +48,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
         return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
     return 0;
 }
@@ -57,7 +57,7 @@ int vpmu_do_interrupt(struct cpu_user_re
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(current);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_interrupt )
         return vpmu->arch_vpmu_ops->do_interrupt(regs);
     return 0;
 }
@@ -66,7 +66,7 @@ void vpmu_save(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_save )
         vpmu->arch_vpmu_ops->arch_vpmu_save(v);
 }
 
@@ -74,7 +74,7 @@ void vpmu_load(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
         vpmu->arch_vpmu_ops->arch_vpmu_load(v);
 }
 
@@ -109,7 +109,8 @@ void vpmu_initialise(struct vcpu *v)
     {
         vpmu->flags = 0;
         vpmu->context = NULL;
-        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
+        if ( vpmu->arch_vpmu_ops->arch_vpmu_initialise )
+            vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
     }
 }
 
@@ -117,7 +118,17 @@ void vpmu_destroy(struct vcpu *v)
 {
     struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
-    if ( vpmu->arch_vpmu_ops )
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
         vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
 }
 
+void vpmu_do_cpuid(unsigned int input,
+                   unsigned int *eax, unsigned int *ebx,
+                   unsigned int *ecx, unsigned int *edx)
+{
+    struct vpmu_struct *vpmu = vcpu_vpmu(current);
+
+    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_cpuid)
+        vpmu->arch_vpmu_ops->arch_vpmu_cpuid(input, eax, ebx, ecx, edx);
+}
+
diff -r 7a82c2e2eb33 xen/include/asm-x86/hvm/vpmu.h
--- a/xen/include/asm-x86/hvm/vpmu.h	Thu Jan 19 13:14:02 2012 +0100
+++ b/xen/include/asm-x86/hvm/vpmu.h	Thu Jan 19 14:37:17 2012 +0100
@@ -56,6 +56,9 @@ struct arch_vpmu_ops {
     void (*arch_vpmu_destroy)(struct vcpu *v);
     void (*arch_vpmu_save)(struct vcpu *v);
     void (*arch_vpmu_load)(struct vcpu *v);
+    void (*arch_vpmu_cpuid)(unsigned int input,
+                            unsigned int *eax, unsigned int *ebx,
+                            unsigned int *ecx, unsigned int *edx);
 };
 
 int vmx_vpmu_initialize(struct vcpu *v);
@@ -78,6 +81,9 @@ void vpmu_initialise(struct vcpu *v);
 void vpmu_destroy(struct vcpu *v);
 void vpmu_save(struct vcpu *v);
 void vpmu_load(struct vcpu *v);
+void vpmu_do_cpuid(unsigned int input,
+                   unsigned int *eax, unsigned int *ebx,
+                   unsigned int *ecx, unsigned int *edx);
 
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 14:00:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14: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 1RnsX1-0001G5-Hv; Thu, 19 Jan 2012 13:59:59 +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 1RnsX0-0001Fp-VL
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:59:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326981592!11549039!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23920 invoked from network); 19 Jan 2012 13:59:53 -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;
	19 Jan 2012 13:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10145966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 13:59: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; Thu, 19 Jan 2012 13:59:52 +0000
Date: Thu, 19 Jan 2012 14:00: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: <1326975944.17599.82.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975944.17599.82.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:
> 
> > Stefano Stabellini (3):
> >       libxc: add a callback to xc_domain_restore
> >       libxl: extract the qemu state file from the save image
> >       libxl: introduce QEMU_HEADER
> 
> Two sets of these followed. I've assumed they were identical.

Uhm.. I only executed git send-email once, I am not sure what is going
on..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 14:00:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14: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 1RnsX1-0001G5-Hv; Thu, 19 Jan 2012 13:59:59 +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 1RnsX0-0001Fp-VL
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:59:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1326981592!11549039!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23920 invoked from network); 19 Jan 2012 13:59:53 -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;
	19 Jan 2012 13:59:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10145966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 13:59: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; Thu, 19 Jan 2012 13:59:52 +0000
Date: Thu, 19 Jan 2012 14:00: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: <1326975944.17599.82.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975944.17599.82.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:
> 
> > Stefano Stabellini (3):
> >       libxc: add a callback to xc_domain_restore
> >       libxl: extract the qemu state file from the save image
> >       libxl: introduce QEMU_HEADER
> 
> Two sets of these followed. I've assumed they were identical.

Uhm.. I only executed git send-email once, I am not sure what is going
on..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 14:01:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnsXk-0001NF-0A; Thu, 19 Jan 2012 14:00: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 1RnsXi-0001Mk-Nw
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:00:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326981635!9783880!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12506 invoked from network); 19 Jan 2012 14:00:36 -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;
	19 Jan 2012 14:00:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10145979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:00:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 14:00:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Vijay Chander <vijay.chander@gmail.com>
Date: Thu, 19 Jan 2012 14:00:35 +0000
In-Reply-To: <CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
References: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>
	<CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326981635.17599.85.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 + openvswitch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 05:15 +0000, Vijay Chander wrote:
> 
> 
> On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander
> <vijay.chander@gmail.com> wrote:
>         Has anyone seen performance issues with xen 4.1.0 (the one
>         used in xencenter 6.0) 

Issues with XenServer should be reported either to XenServer support or
via the appropriate forum on forums.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 Jan 19 14:01:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnsXk-0001NF-0A; Thu, 19 Jan 2012 14:00: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 1RnsXi-0001Mk-Nw
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:00:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1326981635!9783880!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12506 invoked from network); 19 Jan 2012 14:00:36 -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;
	19 Jan 2012 14:00:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10145979"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:00:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 14:00:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Vijay Chander <vijay.chander@gmail.com>
Date: Thu, 19 Jan 2012 14:00:35 +0000
In-Reply-To: <CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
References: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>
	<CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326981635.17599.85.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 + openvswitch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 05:15 +0000, Vijay Chander wrote:
> 
> 
> On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander
> <vijay.chander@gmail.com> wrote:
>         Has anyone seen performance issues with xen 4.1.0 (the one
>         used in xencenter 6.0) 

Issues with XenServer should be reported either to XenServer support or
via the appropriate forum on forums.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 Jan 19 14:02:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14: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 1RnsZc-0001YT-HC; Thu, 19 Jan 2012 14:02:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnsZa-0001Y4-RB
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:02:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326981751!7765901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8238 invoked from network); 19 Jan 2012 14:02:32 -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;
	19 Jan 2012 14:02:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146015"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:01: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;
	Thu, 19 Jan 2012 14:01:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 14:01:55 +0000
In-Reply-To: <alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975944.17599.82.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326981715.17599.86.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 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 14:00 +0000, Stefano Stabellini wrote:
> On Thu, 19 Jan 2012, Ian Campbell wrote:
> > On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:
> > 
> > > Stefano Stabellini (3):
> > >       libxc: add a callback to xc_domain_restore
> > >       libxl: extract the qemu state file from the save image
> > >       libxl: introduce QEMU_HEADER
> > 
> > Two sets of these followed. I've assumed they were identical.
> 
> Uhm.. I only executed git send-email once, I am not sure what is going
> on..

Weird, the message IDs go from 1-6.

Do you have two copies of the patches in your dir + did you use a wild
card on your send-email 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 Jan 19 14:02:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14: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 1RnsZc-0001YT-HC; Thu, 19 Jan 2012 14:02:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnsZa-0001Y4-RB
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:02:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1326981751!7765901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8238 invoked from network); 19 Jan 2012 14:02:32 -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;
	19 Jan 2012 14:02:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146015"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:01: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;
	Thu, 19 Jan 2012 14:01:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 14:01:55 +0000
In-Reply-To: <alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975944.17599.82.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326981715.17599.86.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 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 14:00 +0000, Stefano Stabellini wrote:
> On Thu, 19 Jan 2012, Ian Campbell wrote:
> > On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:
> > 
> > > Stefano Stabellini (3):
> > >       libxc: add a callback to xc_domain_restore
> > >       libxl: extract the qemu state file from the save image
> > >       libxl: introduce QEMU_HEADER
> > 
> > Two sets of these followed. I've assumed they were identical.
> 
> Uhm.. I only executed git send-email once, I am not sure what is going
> on..

Weird, the message IDs go from 1-6.

Do you have two copies of the patches in your dir + did you use a wild
card on your send-email 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 Jan 19 14:04:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14: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 1RnsbK-0001gW-1h; Thu, 19 Jan 2012 14:04:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnsbI-0001gC-LE
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:04:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326981731!49245866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12348 invoked from network); 19 Jan 2012 14:02:11 -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 Jan 2012 14:02:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:04: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;
	Thu, 19 Jan 2012 14:04:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 14:04:19 +0000
In-Reply-To: <alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326981859.17599.87.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 13:08 +0000, Stefano Stabellini wrote:
> On Thu, 19 Jan 2012, Ian Campbell wrote:
> > On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> > > Write to xenstore any physmap changes so that the hypervisor can be
> > > aware of them.
> > 
> > What is the structure of the xenstore values? Looks like 
> > 	<domid>/physmap/<original-addr>/start_addr <new-addr>
> > ?
> 
> Yep, that is the structure
> 
> 
> > Who defines the meaning of original-addr, in particular what happens
> > if it the original-addr for a device changes in a N->N+1 migration? What
> > happens if things overlap or if a subsequent call only updates part of a
> > previously moved mapping?
> 
> In practice it cannot happen because on restore Qemu is going to emulate
> the same set of devices it was emulating before.
> The original address is not going to change if the devices and the
> amount of guest memory stay the same.

If you are migrating to a newer qemu then the <original-addr> could in
principal change, I think.

> We could add some additional info to better identify the physmap entry,
> probably the best we could use is the memory_region name.

And/Or the PCI BDF + BAR?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 14:04:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14: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 1RnsbK-0001gW-1h; Thu, 19 Jan 2012 14:04:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnsbI-0001gC-LE
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:04:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1326981731!49245866!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12348 invoked from network); 19 Jan 2012 14:02:11 -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 Jan 2012 14:02:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146090"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:04: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;
	Thu, 19 Jan 2012 14:04:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 14:04:19 +0000
In-Reply-To: <alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326981859.17599.87.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 13:08 +0000, Stefano Stabellini wrote:
> On Thu, 19 Jan 2012, Ian Campbell wrote:
> > On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> > > Write to xenstore any physmap changes so that the hypervisor can be
> > > aware of them.
> > 
> > What is the structure of the xenstore values? Looks like 
> > 	<domid>/physmap/<original-addr>/start_addr <new-addr>
> > ?
> 
> Yep, that is the structure
> 
> 
> > Who defines the meaning of original-addr, in particular what happens
> > if it the original-addr for a device changes in a N->N+1 migration? What
> > happens if things overlap or if a subsequent call only updates part of a
> > previously moved mapping?
> 
> In practice it cannot happen because on restore Qemu is going to emulate
> the same set of devices it was emulating before.
> The original address is not going to change if the devices and the
> amount of guest memory stay the same.

If you are migrating to a newer qemu then the <original-addr> could in
principal change, I think.

> We could add some additional info to better identify the physmap entry,
> probably the best we could use is the memory_region name.

And/Or the PCI BDF + BAR?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 14:06:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:06:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnscv-0001or-JT; Thu, 19 Jan 2012 14:06:05 +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 1Rnscu-0001oH-Ac
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:06:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326981957!4146696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31808 invoked from network); 19 Jan 2012 14:05:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 14:05:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:05: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, 19 Jan 2012 14:05:57 +0000
Date: Thu, 19 Jan 2012 14:06:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326981715.17599.86.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191403250.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975944.17599.82.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
	<1326981715.17599.86.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 14:00 +0000, Stefano Stabellini wrote:
> > On Thu, 19 Jan 2012, Ian Campbell wrote:
> > > On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:
> > > 
> > > > Stefano Stabellini (3):
> > > >       libxc: add a callback to xc_domain_restore
> > > >       libxl: extract the qemu state file from the save image
> > > >       libxl: introduce QEMU_HEADER
> > > 
> > > Two sets of these followed. I've assumed they were identical.
> > 
> > Uhm.. I only executed git send-email once, I am not sure what is going
> > on..
> 
> Weird, the message IDs go from 1-6.
> 
> Do you have two copies of the patches in your dir + did you use a wild
> card on your send-email maybe?

I think I passed the wild card to git send-email twice, my fault :/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 14:06:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:06:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnscv-0001or-JT; Thu, 19 Jan 2012 14:06:05 +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 1Rnscu-0001oH-Ac
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:06:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1326981957!4146696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31808 invoked from network); 19 Jan 2012 14:05:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 14:05:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146148"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:05: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, 19 Jan 2012 14:05:57 +0000
Date: Thu, 19 Jan 2012 14:06:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326981715.17599.86.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191403250.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975944.17599.82.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
	<1326981715.17599.86.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 14:00 +0000, Stefano Stabellini wrote:
> > On Thu, 19 Jan 2012, Ian Campbell wrote:
> > > On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:
> > > 
> > > > Stefano Stabellini (3):
> > > >       libxc: add a callback to xc_domain_restore
> > > >       libxl: extract the qemu state file from the save image
> > > >       libxl: introduce QEMU_HEADER
> > > 
> > > Two sets of these followed. I've assumed they were identical.
> > 
> > Uhm.. I only executed git send-email once, I am not sure what is going
> > on..
> 
> Weird, the message IDs go from 1-6.
> 
> Do you have two copies of the patches in your dir + did you use a wild
> card on your send-email maybe?

I think I passed the wild card to git send-email twice, my fault :/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 14:08:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnseT-0001zf-33; Thu, 19 Jan 2012 14:07:41 +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 1RnseR-0001yw-4f
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:07:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326982004!50932263!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6976 invoked from network); 19 Jan 2012 14:06:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 14:06:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320642000"; d="scan'208";a="21060445"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 09:07:31 -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, 19 Jan 2012
	09:07:31 -0500
Message-ID: <4F1823A2.9080003@citrix.com>
Date: Thu, 19 Jan 2012 14:07:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>	<CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
	<1326981635.17599.85.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326981635.17599.85.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] xen + openvswitch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/12 14:00, Ian Campbell wrote:
> On Thu, 2012-01-19 at 05:15 +0000, Vijay Chander wrote:
>>
>> On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander
>> <vijay.chander@gmail.com> wrote:
>>         Has anyone seen performance issues with xen 4.1.0 (the one
>>         used in xencenter 6.0) 
> Issues with XenServer should be reported either to XenServer support or
> via the appropriate forum on forums.citrix.com.
>
> Thanks.
> Ian.

However, in the interest of fixing your problem.

A Hotfix for this issue has already been released.  Please google for it
- it is not hard to find.

>
>
>
> _______________________________________________
> 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 Thu Jan 19 14:08:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnseT-0001zf-33; Thu, 19 Jan 2012 14:07:41 +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 1RnseR-0001yw-4f
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:07:39 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326982004!50932263!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6976 invoked from network); 19 Jan 2012 14:06:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 14:06:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320642000"; d="scan'208";a="21060445"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 09:07:31 -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, 19 Jan 2012
	09:07:31 -0500
Message-ID: <4F1823A2.9080003@citrix.com>
Date: Thu, 19 Jan 2012 14:07:30 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>	<CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
	<1326981635.17599.85.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326981635.17599.85.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] xen + openvswitch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/12 14:00, Ian Campbell wrote:
> On Thu, 2012-01-19 at 05:15 +0000, Vijay Chander wrote:
>>
>> On Wed, Jan 18, 2012 at 9:14 PM, Vijay Chander
>> <vijay.chander@gmail.com> wrote:
>>         Has anyone seen performance issues with xen 4.1.0 (the one
>>         used in xencenter 6.0) 
> Issues with XenServer should be reported either to XenServer support or
> via the appropriate forum on forums.citrix.com.
>
> Thanks.
> Ian.

However, in the interest of fixing your problem.

A Hotfix for this issue has already been released.  Please google for it
- it is not hard to find.

>
>
>
> _______________________________________________
> 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 Thu Jan 19 14:10:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:10:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnsga-0002BP-Mh; Thu, 19 Jan 2012 14:09:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnsgZ-0002Aq-1p
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:09:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326982185!11127808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3779 invoked from network); 19 Jan 2012 14:09:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 14:09:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14: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;
	Thu, 19 Jan 2012 14:09:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 14:09:44 +0000
In-Reply-To: <alpine.DEB.2.00.1201191403250.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975944.17599.82.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
	<1326981715.17599.86.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191403250.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326982184.17599.88.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 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 14:06 +0000, Stefano Stabellini wrote:
> On Thu, 19 Jan 2012, Ian Campbell wrote:
> > On Thu, 2012-01-19 at 14:00 +0000, Stefano Stabellini wrote:
> > > On Thu, 19 Jan 2012, Ian Campbell wrote:
> > > > On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:
> > > > 
> > > > > Stefano Stabellini (3):
> > > > >       libxc: add a callback to xc_domain_restore
> > > > >       libxl: extract the qemu state file from the save image
> > > > >       libxl: introduce QEMU_HEADER
> > > > 
> > > > Two sets of these followed. I've assumed they were identical.
> > > 
> > > Uhm.. I only executed git send-email once, I am not sure what is going
> > > on..
> > 
> > Weird, the message IDs go from 1-6.
> > 
> > Do you have two copies of the patches in your dir + did you use a wild
> > card on your send-email maybe?
> 
> I think I passed the wild card to git send-email twice, my fault :/

Easily done.

FWIW I usually do
	less $(git format-patch RANGE..RANGE)
	git send-email --to etc $(git format-patch RANGE..RANGE)
	etc
to avoid this sort of 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 Jan 19 14:10:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:10:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnsga-0002BP-Mh; Thu, 19 Jan 2012 14:09:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnsgZ-0002Aq-1p
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:09:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1326982185!11127808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3779 invoked from network); 19 Jan 2012 14:09:45 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 14:09:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146375"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14: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;
	Thu, 19 Jan 2012 14:09:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 19 Jan 2012 14:09:44 +0000
In-Reply-To: <alpine.DEB.2.00.1201191403250.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191204370.3150@kaball-desktop>
	<1326975944.17599.82.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191359430.3150@kaball-desktop>
	<1326981715.17599.86.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191403250.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326982184.17599.88.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 0/3] libxl: save additional info to the qemu
 chunk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 14:06 +0000, Stefano Stabellini wrote:
> On Thu, 19 Jan 2012, Ian Campbell wrote:
> > On Thu, 2012-01-19 at 14:00 +0000, Stefano Stabellini wrote:
> > > On Thu, 19 Jan 2012, Ian Campbell wrote:
> > > > On Thu, 2012-01-19 at 12:12 +0000, Stefano Stabellini wrote:
> > > > 
> > > > > Stefano Stabellini (3):
> > > > >       libxc: add a callback to xc_domain_restore
> > > > >       libxl: extract the qemu state file from the save image
> > > > >       libxl: introduce QEMU_HEADER
> > > > 
> > > > Two sets of these followed. I've assumed they were identical.
> > > 
> > > Uhm.. I only executed git send-email once, I am not sure what is going
> > > on..
> > 
> > Weird, the message IDs go from 1-6.
> > 
> > Do you have two copies of the patches in your dir + did you use a wild
> > card on your send-email maybe?
> 
> I think I passed the wild card to git send-email twice, my fault :/

Easily done.

FWIW I usually do
	less $(git format-patch RANGE..RANGE)
	git send-email --to etc $(git format-patch RANGE..RANGE)
	etc
to avoid this sort of 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 Jan 19 14:10:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnsgi-0002CN-48; Thu, 19 Jan 2012 14:10: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 1Rnsgg-0002BW-FL
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:09:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326982192!11726656!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12477 invoked from network); 19 Jan 2012 14:09:52 -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;
	19 Jan 2012 14:09:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:09: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, 19 Jan 2012 14:09: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 1RnsgZ-0006T1-V3;
	Thu, 19 Jan 2012 14:09:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnsgZ-0000D3-Sl;
	Thu, 19 Jan 2012 14:09:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10898-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 14:09:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10898: 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 10898 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10898/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-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-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  f5b366c6c4c6
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 943 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 Jan 19 14:10:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:10:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnsgi-0002CN-48; Thu, 19 Jan 2012 14:10: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 1Rnsgg-0002BW-FL
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:09:58 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1326982192!11726656!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12477 invoked from network); 19 Jan 2012 14:09:52 -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;
	19 Jan 2012 14:09:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:09: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, 19 Jan 2012 14:09: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 1RnsgZ-0006T1-V3;
	Thu, 19 Jan 2012 14:09:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnsgZ-0000D3-Sl;
	Thu, 19 Jan 2012 14:09:51 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10898-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 14:09:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10898: 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 10898 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10898/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10649
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10649

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 11 guest-localmigrate        fail REGR. vs. 10649
 test-amd64-i386-win-vcpus1    7 windows-install           fail REGR. vs. 10649

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-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-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  f5b366c6c4c6
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 943 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 Jan 19 14:15:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnsm9-0002c7-AO; Thu, 19 Jan 2012 14:15:37 +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 1Rnsm7-0002bz-Dy
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:15:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326982529!9837434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26895 invoked from network); 19 Jan 2012 14:15:29 -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;
	19 Jan 2012 14:15:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:15:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 14:15:29 +0000
Date: Thu, 19 Jan 2012 14:16: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: <1326981859.17599.87.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
	<1326981859.17599.87.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>,
	"jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 13:08 +0000, Stefano Stabellini wrote:
> > On Thu, 19 Jan 2012, Ian Campbell wrote:
> > > On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> > > > Write to xenstore any physmap changes so that the hypervisor can be
> > > > aware of them.
> > > 
> > > What is the structure of the xenstore values? Looks like 
> > > 	<domid>/physmap/<original-addr>/start_addr <new-addr>
> > > ?
> > 
> > Yep, that is the structure
> > 
> > 
> > > Who defines the meaning of original-addr, in particular what happens
> > > if it the original-addr for a device changes in a N->N+1 migration? What
> > > happens if things overlap or if a subsequent call only updates part of a
> > > previously moved mapping?
> > 
> > In practice it cannot happen because on restore Qemu is going to emulate
> > the same set of devices it was emulating before.
> > The original address is not going to change if the devices and the
> > amount of guest memory stay the same.
> 
> If you are migrating to a newer qemu then the <original-addr> could in
> principal change, I think.

Not unless the implementation of qemu_ram_alloc_from_ptr or
find_ram_offset change, but these are core qemu functions.
Or the device starts allocating more memory of course, but it wouldn't
be the same device anymore.
In any case, if we also match on the MemoryRegion name we cannot go
wrong.


> > We could add some additional info to better identify the physmap entry,
> > probably the best we could use is the memory_region name.
> 
> And/Or the PCI BDF + BAR?

I don't think we can get the PCI BDF from the Xen MemoryListener, but we
can get the MemoryRegion. The most identifying info in it I think is the
name, for example for vga would be "vga.vram".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 14:15:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 14:15:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnsm9-0002c7-AO; Thu, 19 Jan 2012 14:15:37 +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 1Rnsm7-0002bz-Dy
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 14:15:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1326982529!9837434!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26895 invoked from network); 19 Jan 2012 14:15:29 -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;
	19 Jan 2012 14:15:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320624000"; d="scan'208";a="10146961"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 14:15:29 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 19 Jan 2012 14:15:29 +0000
Date: Thu, 19 Jan 2012 14:16: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: <1326981859.17599.87.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
	<1326981859.17599.87.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>,
	"jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 19 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 13:08 +0000, Stefano Stabellini wrote:
> > On Thu, 19 Jan 2012, Ian Campbell wrote:
> > > On Thu, 2012-01-19 at 11:56 +0000, Stefano Stabellini wrote:
> > > > Write to xenstore any physmap changes so that the hypervisor can be
> > > > aware of them.
> > > 
> > > What is the structure of the xenstore values? Looks like 
> > > 	<domid>/physmap/<original-addr>/start_addr <new-addr>
> > > ?
> > 
> > Yep, that is the structure
> > 
> > 
> > > Who defines the meaning of original-addr, in particular what happens
> > > if it the original-addr for a device changes in a N->N+1 migration? What
> > > happens if things overlap or if a subsequent call only updates part of a
> > > previously moved mapping?
> > 
> > In practice it cannot happen because on restore Qemu is going to emulate
> > the same set of devices it was emulating before.
> > The original address is not going to change if the devices and the
> > amount of guest memory stay the same.
> 
> If you are migrating to a newer qemu then the <original-addr> could in
> principal change, I think.

Not unless the implementation of qemu_ram_alloc_from_ptr or
find_ram_offset change, but these are core qemu functions.
Or the device starts allocating more memory of course, but it wouldn't
be the same device anymore.
In any case, if we also match on the MemoryRegion name we cannot go
wrong.


> > We could add some additional info to better identify the physmap entry,
> > probably the best we could use is the memory_region name.
> 
> And/Or the PCI BDF + BAR?

I don't think we can get the PCI BDF from the Xen MemoryListener, but we
can get the MemoryRegion. The most identifying info in it I think is the
name, for example for vga would be "vga.vram".

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 15:23:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 15:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RntpT-0003xg-Fy; Thu, 19 Jan 2012 15:23:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RntpS-0003xb-2m
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 15:23:06 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326986578!9097465!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16677 invoked from network); 19 Jan 2012 15:23:00 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Jan 2012 15:23:00 -0000
Received: from mail23-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id
	14.1.225.23; Thu, 19 Jan 2012 15:22:57 +0000
Received: from mail23-ch1 (localhost [127.0.0.1])	by mail23-ch1-R.bigfish.com
	(Postfix) with ESMTP id 935885A01B7;
	Thu, 19 Jan 2012 15:22:57 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h)
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 mail23-ch1 (localhost.localdomain [127.0.0.1]) by mail23-ch1
	(MessageSwitch) id 1326986577485364_7560;
	Thu, 19 Jan 2012 15:22:57 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.254])	by mail23-ch1.bigfish.com (Postfix) with ESMTP id
	7004A4C0077;	Thu, 19 Jan 2012 15:22:57 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server id
	14.1.225.23; Thu, 19 Jan 2012 15:22:54 +0000
X-WSS-ID: 0LY1XE2-01-538-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 230F51028070;	Thu, 19 Jan 2012 09:22:50 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 19 Jan 2012 09:23:09 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 09:22:54 -0600
Message-ID: <4F18354D.2020908@amd.com>
Date: Thu, 19 Jan 2012 10:22:53 -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: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
	<4F16A402020000780006D571@nat28.tlf.novell.com>
	<4F170EBA.70101@amd.com> <4F17DDE8020000780006D952@nat28.tlf.novell
In-Reply-To: <4F17DDE8020000780006D952@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/19/12 03:10, Jan Beulich wrote:

>
> Btw., one more comment on the change to init_amd(): You will likely
> need to distinguish BP and AP cases here - on the BP you want to
> plainly write the values read from the MSRs to the global variables,
> but on APs (with possibly different settings) you need to work
> towards a setting of the global variables that apply to all of the
> CPUs. This is not just for the (theoretical only?) hotplug case, but
> particularly the one of a soft-offlined CPU that had its microcode
> updated already in a way affecting the OSVW bits and is
> subsequently being brought back online.


Not sure I follow you. There is no difference in how BIOS/microcode sets 
OSVW bits on AP or BP, that's based on silicon version (i.e. stepping) 
and not where that silicon is plugged in.

If a core is offlined that will presumably happen after it has already 
gone through init_amd() and therefore global versions of the registers 
already accounted for that processor's values. (The downside is that if 
the offlined processors has more bugs than the rest then everyone is 
considered as bad even though the bad processor is out of the action. 
But I think the positives of updating global variables after a cpu is 
offlined are not worth the complexity.)

>
> Which reminds you and me that the patch is missing integration with
> the microcode update loader (as that one may alter the OSVW bits
> iiuc).

That's a good point --- I should re-initialize the global variables 
after a patch is loaded.

Thanks.
-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 15:23:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 15:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RntpT-0003xg-Fy; Thu, 19 Jan 2012 15:23:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RntpS-0003xb-2m
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 15:23:06 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1326986578!9097465!1
X-Originating-IP: [216.32.181.183]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16677 invoked from network); 19 Jan 2012 15:23:00 -0000
Received: from ch1ehsobe003.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.183)
	by server-12.tower-21.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Jan 2012 15:23:00 -0000
Received: from mail23-ch1-R.bigfish.com (10.43.68.244) by
	CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id
	14.1.225.23; Thu, 19 Jan 2012 15:22:57 +0000
Received: from mail23-ch1 (localhost [127.0.0.1])	by mail23-ch1-R.bigfish.com
	(Postfix) with ESMTP id 935885A01B7;
	Thu, 19 Jan 2012 15:22:57 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h)
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 mail23-ch1 (localhost.localdomain [127.0.0.1]) by mail23-ch1
	(MessageSwitch) id 1326986577485364_7560;
	Thu, 19 Jan 2012 15:22:57 +0000 (UTC)
Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.254])	by mail23-ch1.bigfish.com (Postfix) with ESMTP id
	7004A4C0077;	Thu, 19 Jan 2012 15:22:57 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server id
	14.1.225.23; Thu, 19 Jan 2012 15:22:54 +0000
X-WSS-ID: 0LY1XE2-01-538-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 230F51028070;	Thu, 19 Jan 2012 09:22:50 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Thu, 19 Jan 2012 09:23:09 -0600
Received: from [10.234.222.67] (10.234.222.67) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 09:22:54 -0600
Message-ID: <4F18354D.2020908@amd.com>
Date: Thu, 19 Jan 2012 10:22:53 -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: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
	<4F16A402020000780006D571@nat28.tlf.novell.com>
	<4F170EBA.70101@amd.com> <4F17DDE8020000780006D952@nat28.tlf.novell
In-Reply-To: <4F17DDE8020000780006D952@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/19/12 03:10, Jan Beulich wrote:

>
> Btw., one more comment on the change to init_amd(): You will likely
> need to distinguish BP and AP cases here - on the BP you want to
> plainly write the values read from the MSRs to the global variables,
> but on APs (with possibly different settings) you need to work
> towards a setting of the global variables that apply to all of the
> CPUs. This is not just for the (theoretical only?) hotplug case, but
> particularly the one of a soft-offlined CPU that had its microcode
> updated already in a way affecting the OSVW bits and is
> subsequently being brought back online.


Not sure I follow you. There is no difference in how BIOS/microcode sets 
OSVW bits on AP or BP, that's based on silicon version (i.e. stepping) 
and not where that silicon is plugged in.

If a core is offlined that will presumably happen after it has already 
gone through init_amd() and therefore global versions of the registers 
already accounted for that processor's values. (The downside is that if 
the offlined processors has more bugs than the rest then everyone is 
considered as bad even though the bad processor is out of the action. 
But I think the positives of updating global variables after a cpu is 
offlined are not worth the complexity.)

>
> Which reminds you and me that the patch is missing integration with
> the microcode update loader (as that one may alter the OSVW bits
> iiuc).

That's a good point --- I should re-initialize the global variables 
after a patch is loaded.

Thanks.
-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 15:36:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 15:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnu1z-000481-Rf; Thu, 19 Jan 2012 15:36:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rnu1x-00047w-OL
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 15:36:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326987296!57622626!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29284 invoked from network); 19 Jan 2012 15:34:57 -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;
	19 Jan 2012 15:34:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320642000"; d="scan'208";a="21067156"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:35: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, 19 Jan 2012 10:35:53 -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 q0JFZpGg012752;	Thu, 19 Jan 2012 07:35:52 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 19 Jan 2012 15:35:22 +0000
Message-ID: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 read() return 0, the current code just tries again. But this leads to an
infinite loop if QEMU died too soon.

Also, retry select if a signal was caught.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl_qmp.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 1777e44..d3b1d53 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -385,18 +385,22 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
         FD_ZERO(&rfds);
         FD_SET(qmp->qmp_fd, &rfds);
 
+do_select_again:
         ret = select(qmp->qmp_fd + 1, &rfds, NULL, NULL, &timeout);
         if (ret == 0) {
             LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "timeout");
             return -1;
         } else if (ret < 0) {
+            if (errno == EINTR)
+                goto do_select_again;
             LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Select error");
             return -1;
         }
 
         rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE);
         if (rd == 0) {
-            continue;
+            LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Unexpected end of socket");
+            return -1;
         } else if (rd < 0) {
             LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Socket read error");
             return rd;
-- 
tg: (6674c38..) fix/qmp-end-of-socket (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 Thu Jan 19 15:36:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 15:36:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnu1z-000481-Rf; Thu, 19 Jan 2012 15:36:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony.perard@citrix.com>) id 1Rnu1x-00047w-OL
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 15:36:02 +0000
X-Env-Sender: anthony.perard@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1326987296!57622626!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTkwOTM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29284 invoked from network); 19 Jan 2012 15:34:57 -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;
	19 Jan 2012 15:34:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,536,1320642000"; d="scan'208";a="21067156"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 10:35: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, 19 Jan 2012 10:35:53 -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 q0JFZpGg012752;	Thu, 19 Jan 2012 07:35:52 -0800
From: Anthony PERARD <anthony.perard@citrix.com>
To: Xen Devel <xen-devel@lists.xensource.com>
Date: Thu, 19 Jan 2012 15:35:22 +0000
Message-ID: <1326987322-28007-1-git-send-email-anthony.perard@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl_qmp: Handle unexpected end-of-socket
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 read() return 0, the current code just tries again. But this leads to an
infinite loop if QEMU died too soon.

Also, retry select if a signal was caught.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>

---
 tools/libxl/libxl_qmp.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 1777e44..d3b1d53 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -385,18 +385,22 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
         FD_ZERO(&rfds);
         FD_SET(qmp->qmp_fd, &rfds);
 
+do_select_again:
         ret = select(qmp->qmp_fd + 1, &rfds, NULL, NULL, &timeout);
         if (ret == 0) {
             LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "timeout");
             return -1;
         } else if (ret < 0) {
+            if (errno == EINTR)
+                goto do_select_again;
             LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Select error");
             return -1;
         }
 
         rd = read(qmp->qmp_fd, qmp->buffer, QMP_RECEIVE_BUFFER_SIZE);
         if (rd == 0) {
-            continue;
+            LIBXL__LOG(qmp->ctx, LIBXL__LOG_ERROR, "Unexpected end of socket");
+            return -1;
         } else if (rd < 0) {
             LIBXL__LOG_ERRNO(qmp->ctx, LIBXL__LOG_ERROR, "Socket read error");
             return rd;
-- 
tg: (6674c38..) fix/qmp-end-of-socket (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 Thu Jan 19 15:58:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 15:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnuNB-0004ck-Sm; Thu, 19 Jan 2012 15:57:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RnuNA-0004cf-FL
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 15:57:56 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326988670!11185724!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 9722 invoked from network); 19 Jan 2012 15:57:50 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Jan 2012 15:57:50 -0000
Received: from mail79-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; Thu, 19 Jan 2012 15:57:49 +0000
Received: from mail79-am1 (localhost [127.0.0.1])	by mail79-am1-R.bigfish.com
	(Postfix) with ESMTP id 15E133004F6;
	Thu, 19 Jan 2012 15:57:49 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail79-am1 (localhost.localdomain [127.0.0.1]) by mail79-am1
	(MessageSwitch) id 1326988668848229_15223;
	Thu, 19 Jan 2012 15:57:48 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.245])	by
	mail79-am1.bigfish.com (Postfix) with ESMTP id BFEFB8003F;
	Thu, 19 Jan 2012 15:57:48 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server id
	14.1.225.23; Thu, 19 Jan 2012 15:57:47 +0000
X-WSS-ID: 0LY1Z0A-02-K54-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 2F989C80A1;	Thu, 19 Jan 2012 09:57: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, 19 Jan 2012 09:58:02 -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, 19 Jan 2012 09:57:46 -0600
Message-ID: <4F183D7A.5040206@amd.com>
Date: Thu, 19 Jan 2012 10:57:46 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CB3D88CC.291A9%keir.xen@gmail.com>
In-Reply-To: <CB3D88CC.291A9%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/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/19/12 03:46, Keir Fraser wrote:
> On 19/01/2012 08:10, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>>>> On 18.01.12 at 19:26, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> On 01/18/12 04:50, Jan Beulich wrote:
>>>>>>> On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@amd.com>   wrote:
>>>>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum
>>>>> 400 as an example -- we don't need a Linux PV guest reading an MSR
>>>>> before going to idle (in amd_e400_idle()).
>>>>
>>>> It is bogus in the first place if a pv guest does so - after all, not doing
>>>> stuff like this is the nature of being pv.
>>>
>>> It was actually a bad example --- the guest is not using amd_e400_idle()
>>> and so there are no extra MSR accesses.
>>>
>>> However, without this change OSVW bit will not show up in the guest's
>>> CPUID and I think guests should be able to see it. One could argue
>>> whether or not we should mask off status bits for the two errata (400
>>> and 415) since they are not currently used; I'd mask them off just to be
>>> consistent with HVM, it won't affect anything.
>>
>> I continue to think otherwise - knowing of and dealing with this is
>> supposed to be entirely hidden from PV guests, unless and until
>> you can provide a counter example. Therefore I am likely to nak
>> this part of future revisions of the patch (which Keir could
>> certainly override), up to and including ripping out the PV part (and
>> adjusting the rest accordingly) if I would go for committing it.
>
> Well, the general principle of exposing OSVW to PV guests doesn't seem
> terrible. It's just the current specific motivation for exposing to HVM
> guests does not apply to PV guests.
>
> Are *any* of the current OSVW defined bits at all useful or applicable to PV
> guests?
>

(Wrong "Reply" button)

Probably not with current bits, at least for Linux PV guests.

-boris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 15:58:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 15:58:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnuNB-0004ck-Sm; Thu, 19 Jan 2012 15:57:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RnuNA-0004cf-FL
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 15:57:56 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1326988670!11185724!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 9722 invoked from network); 19 Jan 2012 15:57:50 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE003.bigfish.com) (213.199.154.206)
	by server-14.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	19 Jan 2012 15:57:50 -0000
Received: from mail79-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; Thu, 19 Jan 2012 15:57:49 +0000
Received: from mail79-am1 (localhost [127.0.0.1])	by mail79-am1-R.bigfish.com
	(Postfix) with ESMTP id 15E133004F6;
	Thu, 19 Jan 2012 15:57:49 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail79-am1 (localhost.localdomain [127.0.0.1]) by mail79-am1
	(MessageSwitch) id 1326988668848229_15223;
	Thu, 19 Jan 2012 15:57:48 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.245])	by
	mail79-am1.bigfish.com (Postfix) with ESMTP id BFEFB8003F;
	Thu, 19 Jan 2012 15:57:48 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server id
	14.1.225.23; Thu, 19 Jan 2012 15:57:47 +0000
X-WSS-ID: 0LY1Z0A-02-K54-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 2F989C80A1;	Thu, 19 Jan 2012 09:57: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, 19 Jan 2012 09:58:02 -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, 19 Jan 2012 09:57:46 -0600
Message-ID: <4F183D7A.5040206@amd.com>
Date: Thu, 19 Jan 2012 10:57:46 -0500
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15
MIME-Version: 1.0
To: Keir Fraser <keir.xen@gmail.com>
References: <CB3D88CC.291A9%keir.xen@gmail.com>
In-Reply-To: <CB3D88CC.291A9%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/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/19/12 03:46, Keir Fraser wrote:
> On 19/01/2012 08:10, "Jan Beulich"<JBeulich@suse.com>  wrote:
>
>>>>> On 18.01.12 at 19:26, Boris Ostrovsky<boris.ostrovsky@amd.com>  wrote:
>>> On 01/18/12 04:50, Jan Beulich wrote:
>>>>>>> On 17.01.12 at 18:54, Boris Ostrovsky<boris.ostrovsky@amd.com>   wrote:
>>>>> I believe this (i.e. OSVW changes) is meaningful for PV. Taking erratum
>>>>> 400 as an example -- we don't need a Linux PV guest reading an MSR
>>>>> before going to idle (in amd_e400_idle()).
>>>>
>>>> It is bogus in the first place if a pv guest does so - after all, not doing
>>>> stuff like this is the nature of being pv.
>>>
>>> It was actually a bad example --- the guest is not using amd_e400_idle()
>>> and so there are no extra MSR accesses.
>>>
>>> However, without this change OSVW bit will not show up in the guest's
>>> CPUID and I think guests should be able to see it. One could argue
>>> whether or not we should mask off status bits for the two errata (400
>>> and 415) since they are not currently used; I'd mask them off just to be
>>> consistent with HVM, it won't affect anything.
>>
>> I continue to think otherwise - knowing of and dealing with this is
>> supposed to be entirely hidden from PV guests, unless and until
>> you can provide a counter example. Therefore I am likely to nak
>> this part of future revisions of the patch (which Keir could
>> certainly override), up to and including ripping out the PV part (and
>> adjusting the rest accordingly) if I would go for committing it.
>
> Well, the general principle of exposing OSVW to PV guests doesn't seem
> terrible. It's just the current specific motivation for exposing to HVM
> guests does not apply to PV guests.
>
> Are *any* of the current OSVW defined bits at all useful or applicable to PV
> guests?
>

(Wrong "Reply" button)

Probably not with current bits, at least for Linux PV guests.

-boris




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:17:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnufE-0005Ej-Os; Thu, 19 Jan 2012 16:16:36 +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 1RnufD-0005EV-Ng
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:16:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326989787!9688287!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 9835 invoked from network); 19 Jan 2012 16:16: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; 19 Jan 2012 16:16:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnuf4-000If0-T5; Thu, 19 Jan 2012 16:16:26 +0000
Date: Thu, 19 Jan 2012 16:16:26 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel <xen-devel@lists.xensource.com>
Message-ID: <20120119161626.GO66164@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Subject: [Xen-devel] RFC PATCH: bring OpenBSD stdarg in line with FreeBSD one
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Having an absolute path in a #include confuses distcc's pump mode.
Since AFAICS OpenBSD's stdarg handling uses the builtins, I think we
should just treat it like we do NetBSD.

I don't have an OpenBSD box to test on, though. :(  Any OpenBSD
enthusiasts care to comment?

Tim.

diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
index 57e2c0e..cb870ac 100644
--- a/xen/include/xen/stdarg.h
+++ b/xen/include/xen/stdarg.h
@@ -1,9 +1,7 @@
 #ifndef __XEN_STDARG_H__
 #define __XEN_STDARG_H__
 
-#if defined(__OpenBSD__)
-#  include "/usr/include/stdarg.h"
-#elif defined (__NetBSD__)
+#if defined(__OpenBSD__) || defined(__NetBSD__)
    typedef __builtin_va_list va_list;
 #  define va_start(ap, last)    __builtin_stdarg_start((ap), (last))
 #  define va_end(ap)            __builtin_va_end(ap)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:17:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnufE-0005Ej-Os; Thu, 19 Jan 2012 16:16:36 +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 1RnufD-0005EV-Ng
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:16:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326989787!9688287!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 9835 invoked from network); 19 Jan 2012 16:16: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; 19 Jan 2012 16:16:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rnuf4-000If0-T5; Thu, 19 Jan 2012 16:16:26 +0000
Date: Thu, 19 Jan 2012 16:16:26 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel <xen-devel@lists.xensource.com>
Message-ID: <20120119161626.GO66164@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Subject: [Xen-devel] RFC PATCH: bring OpenBSD stdarg in line with FreeBSD one
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Having an absolute path in a #include confuses distcc's pump mode.
Since AFAICS OpenBSD's stdarg handling uses the builtins, I think we
should just treat it like we do NetBSD.

I don't have an OpenBSD box to test on, though. :(  Any OpenBSD
enthusiasts care to comment?

Tim.

diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
index 57e2c0e..cb870ac 100644
--- a/xen/include/xen/stdarg.h
+++ b/xen/include/xen/stdarg.h
@@ -1,9 +1,7 @@
 #ifndef __XEN_STDARG_H__
 #define __XEN_STDARG_H__
 
-#if defined(__OpenBSD__)
-#  include "/usr/include/stdarg.h"
-#elif defined (__NetBSD__)
+#if defined(__OpenBSD__) || defined(__NetBSD__)
    typedef __builtin_va_list va_list;
 #  define va_start(ap, last)    __builtin_stdarg_start((ap), (last))
 #  define va_end(ap)            __builtin_va_end(ap)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:28:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnuqV-0005f7-Uz; Thu, 19 Jan 2012 16:28:15 +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 1RnuqU-0005ez-7n
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:28:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326990468!63163557!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 3052 invoked from network); 19 Jan 2012 16:27:49 -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; 19 Jan 2012 16:27:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 16:28:08 +0000
Message-Id: <4F1852E8020000780006DBC1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 16:29:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
	<4F16A402020000780006D571@nat28.tlf.novell.com>
	<4F170EBA.70101@amd.com>
	<4F17DDE8020000780006D952@nat28.tlf.novell<4F17DDE8020000780006D952@nat28.tlf.novell.com>
	<4F18354D.2020908@amd.com>
In-Reply-To: <4F18354D.2020908@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] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.01.12 at 16:22, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 01/19/12 03:10, Jan Beulich wrote:
> 
>>
>> Btw., one more comment on the change to init_amd(): You will likely
>> need to distinguish BP and AP cases here - on the BP you want to
>> plainly write the values read from the MSRs to the global variables,
>> but on APs (with possibly different settings) you need to work
>> towards a setting of the global variables that apply to all of the
>> CPUs. This is not just for the (theoretical only?) hotplug case, but
>> particularly the one of a soft-offlined CPU that had its microcode
>> updated already in a way affecting the OSVW bits and is
>> subsequently being brought back online.
> 
> 
> Not sure I follow you. There is no difference in how BIOS/microcode sets 
> OSVW bits on AP or BP, that's based on silicon version (i.e. stepping) 
> and not where that silicon is plugged in.

But mixed stepping systems could have values in an AP that are
different from what the BP (and earlier APs) had.

> If a core is offlined that will presumably happen after it has already 
> gone through init_amd() and therefore global versions of the registers 
> already accounted for that processor's values. (The downside is that if 
> the offlined processors has more bugs than the rest then everyone is 
> considered as bad even though the bad processor is out of the action. 
> But I think the positives of updating global variables after a cpu is 
> offlined are not worth the complexity.)

Yes, optimizing for this case is very unlikely to be necessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:28:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16:28:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnuqV-0005f7-Uz; Thu, 19 Jan 2012 16:28:15 +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 1RnuqU-0005ez-7n
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:28:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1326990468!63163557!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 3052 invoked from network); 19 Jan 2012 16:27:49 -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; 19 Jan 2012 16:27:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 16:28:08 +0000
Message-Id: <4F1852E8020000780006DBC1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 16:29:12 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <f157d40df95aa3b8becb.1326748277@wotan.osrc.amd.com>
	<4F153EBA020000780006D248@nat28.tlf.novell.com>
	<4F15B5C6.6070808@amd.com>
	<4F16A402020000780006D571@nat28.tlf.novell.com>
	<4F170EBA.70101@amd.com>
	<4F17DDE8020000780006D952@nat28.tlf.novell<4F17DDE8020000780006D952@nat28.tlf.novell.com>
	<4F18354D.2020908@amd.com>
In-Reply-To: <4F18354D.2020908@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] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 19.01.12 at 16:22, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> On 01/19/12 03:10, Jan Beulich wrote:
> 
>>
>> Btw., one more comment on the change to init_amd(): You will likely
>> need to distinguish BP and AP cases here - on the BP you want to
>> plainly write the values read from the MSRs to the global variables,
>> but on APs (with possibly different settings) you need to work
>> towards a setting of the global variables that apply to all of the
>> CPUs. This is not just for the (theoretical only?) hotplug case, but
>> particularly the one of a soft-offlined CPU that had its microcode
>> updated already in a way affecting the OSVW bits and is
>> subsequently being brought back online.
> 
> 
> Not sure I follow you. There is no difference in how BIOS/microcode sets 
> OSVW bits on AP or BP, that's based on silicon version (i.e. stepping) 
> and not where that silicon is plugged in.

But mixed stepping systems could have values in an AP that are
different from what the BP (and earlier APs) had.

> If a core is offlined that will presumably happen after it has already 
> gone through init_amd() and therefore global versions of the registers 
> already accounted for that processor's values. (The downside is that if 
> the offlined processors has more bugs than the rest then everyone is 
> considered as bad even though the bad processor is out of the action. 
> But I think the positives of updating global variables after a cpu is 
> offlined are not worth the complexity.)

Yes, optimizing for this case is very unlikely to be necessary.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:35:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16:35:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnuwt-0005qM-Uq; Thu, 19 Jan 2012 16:34:51 +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 1Rnuws-0005qE-9O
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:34:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326990841!50960604!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 8960 invoked from network); 19 Jan 2012 16:34:01 -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 Jan 2012 16:34:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 16:34:48 +0000
Message-Id: <4F185478020000780006DBD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 16:35:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xensource.com>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
In-Reply-To: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> > What are the outstanding things to do before we think we can start on
>>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>>> > 
>>> > hypervisor:
>>> > 
>>> >       * ??? - Keir, Tim, Jan?
>>> 
>>> Apart from a few small things that I have on my todo list, the only
>>> bigger one (at least from an possible impact perspective) is the
>>> round-up of the closing of the security hole in MSI-X passthrough
>>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
>>> table pages), which I intended to do only once the upstream qemu
>>> patch series also incorporates the respective recent qemu-xen
>>> change.
>> 
>> It sounds like this issue is a blocker for the release, whereas the
>> upstream qemu support for pci passthrough is not necessarily. Has your
>> precondition for inclusion been met yet or do we need to prod someone?
> 
> Just for reference, below the intended (trivial) change.

As unfortunate as it is - I just found that the security hole is all but
closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing
whatever the guest specified into the 3rd word of each MSI-X table
entry. There is also another hypervisor data corrupting flaw in that
code; I'm in the process of putting together a patch, but will (again)
need someone with suitable hardware to test this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:35:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16:35:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnuwt-0005qM-Uq; Thu, 19 Jan 2012 16:34:51 +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 1Rnuws-0005qE-9O
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:34:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1326990841!50960604!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 8960 invoked from network); 19 Jan 2012 16:34:01 -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 Jan 2012 16:34:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 16:34:48 +0000
Message-Id: <4F185478020000780006DBD9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 16:35:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xensource.com>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
In-Reply-To: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Donald D Dugger <donald.d.dugger@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>>> > What are the outstanding things to do before we think we can start on
>>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>>> > 
>>> > hypervisor:
>>> > 
>>> >       * ??? - Keir, Tim, Jan?
>>> 
>>> Apart from a few small things that I have on my todo list, the only
>>> bigger one (at least from an possible impact perspective) is the
>>> round-up of the closing of the security hole in MSI-X passthrough
>>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
>>> table pages), which I intended to do only once the upstream qemu
>>> patch series also incorporates the respective recent qemu-xen
>>> change.
>> 
>> It sounds like this issue is a blocker for the release, whereas the
>> upstream qemu support for pci passthrough is not necessarily. Has your
>> precondition for inclusion been met yet or do we need to prod someone?
> 
> Just for reference, below the intended (trivial) change.

As unfortunate as it is - I just found that the security hole is all but
closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing
whatever the guest specified into the 3rd word of each MSI-X table
entry. There is also another hypervisor data corrupting flaw in that
code; I'm in the process of putting together a patch, but will (again)
need someone with suitable hardware to test this.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:46:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnv7Z-00064F-4o; Thu, 19 Jan 2012 16:45:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rnv7Y-00064A-7D
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:45:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326991544!1571020!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 26663 invoked from network); 19 Jan 2012 16:45:45 -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; 19 Jan 2012 16:45:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 16:45:44 +0000
Message-Id: <4F185708020000780006DBEA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 16:46:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326298757-9846-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 v5 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

>>> On 11.01.12 at 17:18, <stefano.stabellini@eu.citrix.com> wrote:
> --- 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)
> +

As I wanted to use the clear_guest stuff you add here for some
cleanup/latent bug fix in x86's paging code, I pulled this patch into
my local tree. Unfortunately the ia64 bits don't build, as you omitted
the #define-s at the top of the file you took the code from.

Jan

> +/*
> + * 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)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:46:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16:46:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnv7Z-00064F-4o; Thu, 19 Jan 2012 16:45:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rnv7Y-00064A-7D
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:45:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1326991544!1571020!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 26663 invoked from network); 19 Jan 2012 16:45:45 -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; 19 Jan 2012 16:45:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 16:45:44 +0000
Message-Id: <4F185708020000780006DBEA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 16:46:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1326298757-9846-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 v5 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

>>> On 11.01.12 at 17:18, <stefano.stabellini@eu.citrix.com> wrote:
> --- 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)
> +

As I wanted to use the clear_guest stuff you add here for some
cleanup/latent bug fix in x86's paging code, I pulled this patch into
my local tree. Unfortunately the ia64 bits don't build, as you omitted
the #define-s at the top of the file you took the code from.

Jan

> +/*
> + * 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)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:56:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16: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 1RnvHq-0006mo-GE; Thu, 19 Jan 2012 16:56: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 1RnvHo-0006mW-RY
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:56:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326992132!53275193!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 6017 invoked from network); 19 Jan 2012 16:55:32 -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; 19 Jan 2012 16:55:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 16:56:23 +0000
Message-Id: <4F185986020000780006DBF9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 16:57:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
In-Reply-To: <4F185708020000780006DBEA@nat28.tlf.novell.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 v5 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

>>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
> As I wanted to use the clear_guest stuff you add here for some
> cleanup/latent bug fix in x86's paging code, I pulled this patch into
> my local tree. Unfortunately the ia64 bits don't build, as you omitted
> the #define-s at the top of the file you took the code from.

Further, the file you put this in is one that shouldn't be modified. The
correct way is to simply pull in Linux'es clear_user.S (see below).

Jan

--- a/xen/arch/ia64/linux/Makefile
+++ b/xen/arch/ia64/linux/Makefile
@@ -4,6 +4,7 @@ subdir-y += sn
 
 obj-y += bitop.o
 obj-y += clear_page.o
+obj-y += clear_user.o
 obj-y += copy_page_mck.o
 obj-y += efi_stub.o
 obj-y += extable.o
--- a/xen/arch/ia64/linux/README.origin
+++ b/xen/arch/ia64/linux/README.origin
@@ -15,6 +15,7 @@ pcdp.h			-> linux/drivers/firmware/pcdp.
 
 bitop.c			-> linux/arch/ia64/lib/bitop.c
 clear_page.S		-> linux/arch/ia64/lib/clear_page.S
+clear_user.S		-> linux/arch/ia64/lib/clear_user.S
 copy_page_mck.S		-> linux/arch/ia64/lib/copy_page_mck.S
 flush.S			-> linux/arch/ia64/lib/flush.S
 idiv32.S		-> linux/arch/ia64/lib/idiv32.S
--- /dev/null
+++ b/xen/arch/ia64/linux/clear_user.S
@@ -0,0 +1,209 @@
+/*
+ * This routine clears to zero a linear memory buffer in user space.
+ *
+ * Inputs:
+ *	in0:	address of buffer
+ *	in1:	length of buffer in bytes
+ * Outputs:
+ *	r8:	number of bytes that didn't get cleared due to a fault
+ *
+ * Copyright (C) 1998, 1999, 2001 Hewlett-Packard Co
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ */
+
+#include <asm/asmmacro.h>
+
+//
+// arguments
+//
+#define buf		r32
+#define len		r33
+
+//
+// local registers
+//
+#define cnt		r16
+#define buf2		r17
+#define saved_lc	r18
+#define saved_pfs	r19
+#define tmp		r20
+#define len2		r21
+#define len3		r22
+
+//
+// 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)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 16:56:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 16: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 1RnvHq-0006mo-GE; Thu, 19 Jan 2012 16:56: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 1RnvHo-0006mW-RY
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 16:56:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1326992132!53275193!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 6017 invoked from network); 19 Jan 2012 16:55:32 -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; 19 Jan 2012 16:55:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 19 Jan 2012 16:56:23 +0000
Message-Id: <4F185986020000780006DBF9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 19 Jan 2012 16:57:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
In-Reply-To: <4F185708020000780006DBEA@nat28.tlf.novell.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 v5 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

>>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
> As I wanted to use the clear_guest stuff you add here for some
> cleanup/latent bug fix in x86's paging code, I pulled this patch into
> my local tree. Unfortunately the ia64 bits don't build, as you omitted
> the #define-s at the top of the file you took the code from.

Further, the file you put this in is one that shouldn't be modified. The
correct way is to simply pull in Linux'es clear_user.S (see below).

Jan

--- a/xen/arch/ia64/linux/Makefile
+++ b/xen/arch/ia64/linux/Makefile
@@ -4,6 +4,7 @@ subdir-y += sn
 
 obj-y += bitop.o
 obj-y += clear_page.o
+obj-y += clear_user.o
 obj-y += copy_page_mck.o
 obj-y += efi_stub.o
 obj-y += extable.o
--- a/xen/arch/ia64/linux/README.origin
+++ b/xen/arch/ia64/linux/README.origin
@@ -15,6 +15,7 @@ pcdp.h			-> linux/drivers/firmware/pcdp.
 
 bitop.c			-> linux/arch/ia64/lib/bitop.c
 clear_page.S		-> linux/arch/ia64/lib/clear_page.S
+clear_user.S		-> linux/arch/ia64/lib/clear_user.S
 copy_page_mck.S		-> linux/arch/ia64/lib/copy_page_mck.S
 flush.S			-> linux/arch/ia64/lib/flush.S
 idiv32.S		-> linux/arch/ia64/lib/idiv32.S
--- /dev/null
+++ b/xen/arch/ia64/linux/clear_user.S
@@ -0,0 +1,209 @@
+/*
+ * This routine clears to zero a linear memory buffer in user space.
+ *
+ * Inputs:
+ *	in0:	address of buffer
+ *	in1:	length of buffer in bytes
+ * Outputs:
+ *	r8:	number of bytes that didn't get cleared due to a fault
+ *
+ * Copyright (C) 1998, 1999, 2001 Hewlett-Packard Co
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ */
+
+#include <asm/asmmacro.h>
+
+//
+// arguments
+//
+#define buf		r32
+#define len		r33
+
+//
+// local registers
+//
+#define cnt		r16
+#define buf2		r17
+#define saved_lc	r18
+#define saved_pfs	r19
+#define tmp		r20
+#define len2		r21
+#define len3		r22
+
+//
+// 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)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 17:37:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 17:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnvuq-0008SJ-8E; Thu, 19 Jan 2012 17:36:48 +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 1Rnvuo-0008SB-9x
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 17:36:46 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326994564!49129616!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15257 invoked from network); 19 Jan 2012 17:36:06 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jan 2012 17:36:06 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0JHaamT017969
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 19 Jan 2012 09:36:37 -0800
Received: by bkat2 with SMTP id t2so405728bka.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 09:36:35 -0800 (PST)
Received: by 10.204.152.20 with SMTP id e20mr10290912bkw.117.1326994595434;
	Thu, 19 Jan 2012 09:36:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Thu, 19 Jan 2012 09:35:53 -0800 (PST)
In-Reply-To: <4F185478020000780006DBD9@nat28.tlf.novell.com>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 09:35:53 -0800
Message-ID: <CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Cc: Brendan Cully <brendan@cs.ubc.ca>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============4996946601700555767=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4996946601700555767==
Content-Type: multipart/alternative; boundary=0015175df06e7ad0a904b6e501d1

--0015175df06e7ad0a904b6e501d1
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
> >>> > What are the outstanding things to do before we think we can start on
> >>> > the 4.2 -rc's? Does anyone have a timetable in mind?
> >>> >
> >>> > hypervisor:
> >>> >
> >>> >       * ??? - Keir, Tim, Jan?
> >>>
> >>> Apart from a few small things that I have on my todo list, the only
> >>> bigger one (at least from an possible impact perspective) is the
> >>> round-up of the closing of the security hole in MSI-X passthrough
> >>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
> >>> table pages), which I intended to do only once the upstream qemu
> >>> patch series also incorporates the respective recent qemu-xen
> >>> change.
> >>
> >> It sounds like this issue is a blocker for the release, whereas the
> >> upstream qemu support for pci passthrough is not necessarily. Has your
> >> precondition for inclusion been met yet or do we need to prod someone?
> >
> > Just for reference, below the intended (trivial) change.
>
> As unfortunate as it is - I just found that the security hole is all but
> closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing
> whatever the guest specified into the 3rd word of each MSI-X table
> entry. There is also another hypervisor data corrupting flaw in that
> code; I'm in the process of putting together a patch, but will (again)
> need someone with suitable hardware to test this.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


I do have a set of initial patches for xl remus. Since the "script=" support
doesnt exist for disk configurations (required to support both DRBD and
tapdisk backends).

So, currently I only have memory checkpointing functionality. No disk
buffering.
Will submit it in a day or so.

About network buffering:
a.  There is code to install and manipulate the network buffer via netlink
messages. And its
in python. While the "xl remus" control flow starts off from C. Either I
implement the C equivalent
of the python code or call the python code from C (this is C->python and
not the other way around).
Please correct me if I am wrong.

b. The kernel module (sch_plug):  Last I knew, the network
buffering module (sch_plug) was in the pvops tree (2.6.* series). When the
tree
moved to 3.0 series, it got axed off.

 While I am still, convincing the netdev folks into accepting this module
upstream,
I  have a link in the remus wiki, asking people to download/compile the
module.
(People do this only after shooting a couple of "Remus is not working"
emails to the
mailing list)

 As an alternative, I could pull it into the tools/remus/ folder (just like
the way it used to be before the pvops kernels) and compile it as part of
the
tools compilation process.

But as starters, people would be able to play with remus via xl (just
memory
checkpointing).
What do you folks think?

shriram

--0015175df06e7ad0a904b6e501d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">&gt;&gt;&gt; On 17.01.12 at 10:09, &quot;Jan Beulich&quot=
; &lt;<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:=
<br>
&gt;&gt;&gt;&gt; On 16.01.12 at 14:39, Ian Campbell &lt;<a href=3D"mailto:I=
an.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;&gt; On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:<br>
&gt;&gt;&gt; &gt;&gt;&gt; On 04.01.12 at 17:29, Ian Campbell &lt;<a href=3D=
"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt; What are the outstanding things to do before we think we =
can start on<br>
&gt;&gt;&gt; &gt; the 4.2 -rc&#39;s? Does anyone have a timetable in mind?<=
br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; hypervisor:<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; =A0 =A0 =A0 * ??? - Keir, Tim, Jan?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Apart from a few small things that I have on my todo list, the=
 only<br>
&gt;&gt;&gt; bigger one (at least from an possible impact perspective) is t=
he<br>
&gt;&gt;&gt; round-up of the closing of the security hole in MSI-X passthro=
ugh<br>
&gt;&gt;&gt; (uniformly - i.e. even for Dom0 - disallowing write access to =
MSI-X<br>
&gt;&gt;&gt; table pages), which I intended to do only once the upstream qe=
mu<br>
&gt;&gt;&gt; patch series also incorporates the respective recent qemu-xen<=
br>
&gt;&gt;&gt; change.<br>
&gt;&gt;<br>
&gt;&gt; It sounds like this issue is a blocker for the release, whereas th=
e<br>
&gt;&gt; upstream qemu support for pci passthrough is not necessarily. Has =
your<br>
&gt;&gt; precondition for inclusion been met yet or do we need to prod some=
one?<br>
&gt;<br>
&gt; Just for reference, below the intended (trivial) change.<br>
<br>
</div>As unfortunate as it is - I just found that the security hole is all =
but<br>
closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing<br>
whatever the guest specified into the 3rd word of each MSI-X table<br>
entry. There is also another hypervisor data corrupting flaw in that<br>
code; I&#39;m in the process of putting together a patch, but will (again)<=
br>
need someone with suitable hardware to test this.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><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><br>I do have a set of initial patches f=
or xl remus. Since the &quot;script=3D&quot; support<br>doesnt exist for di=
sk configurations (required to support both DRBD and tapdisk backends).<br>

<br>So, currently I only have memory checkpointing functionality. No disk b=
uffering.<br>Will submit it in a day or so.<br><br>About network buffering:=
<br>a.=A0 There is code to install and manipulate the network buffer via ne=
tlink messages. And its<br>

in python. While the &quot;xl remus&quot; control flow starts off from C. E=
ither I implement the C equivalent<br>of the python code or call the python=
 code from C (this is C-&gt;python and not the other way around).<br>Please=
 correct me if I am wrong.<br>

<br>b. The kernel module (sch_plug):=A0 Last I knew, the network<br>bufferi=
ng module (sch_plug) was in the pvops tree (2.6.* series). When the tree<br=
>moved to 3.0 series, it got axed off.<br><br>=A0While I am still, convinci=
ng the netdev folks into accepting this module upstream,<br>

I=A0 have a link in the remus wiki, asking people to download/compile the m=
odule.<br>(People do this only after shooting a couple of &quot;Remus is no=
t working&quot; emails to the<br>mailing list)<br><br>=A0As an alternative,=
 I could pull it into the tools/remus/ folder (just like<br>

the way it used to be before the pvops kernels) and compile it as part of t=
he<br>tools compilation process. <br><br>But as starters, people would be a=
ble to play with remus via xl (just memory <br>checkpointing).<br>What do y=
ou folks think?<br>

<br>shriram

--0015175df06e7ad0a904b6e501d1--


--===============4996946601700555767==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4996946601700555767==--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 17:37:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 17:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnvuq-0008SJ-8E; Thu, 19 Jan 2012 17:36:48 +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 1Rnvuo-0008SB-9x
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 17:36:46 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-27.messagelabs.com!1326994564!49129616!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15257 invoked from network); 19 Jan 2012 17:36:06 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jan 2012 17:36:06 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0JHaamT017969
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 19 Jan 2012 09:36:37 -0800
Received: by bkat2 with SMTP id t2so405728bka.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 09:36:35 -0800 (PST)
Received: by 10.204.152.20 with SMTP id e20mr10290912bkw.117.1326994595434;
	Thu, 19 Jan 2012 09:36:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Thu, 19 Jan 2012 09:35:53 -0800 (PST)
In-Reply-To: <4F185478020000780006DBD9@nat28.tlf.novell.com>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 09:35:53 -0800
Message-ID: <CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
To: xen-devel <xen-devel@lists.xensource.com>
Cc: Brendan Cully <brendan@cs.ubc.ca>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============4996946601700555767=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4996946601700555767==
Content-Type: multipart/alternative; boundary=0015175df06e7ad0a904b6e501d1

--0015175df06e7ad0a904b6e501d1
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 16.01.12 at 14:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
> >>> >>> On 04.01.12 at 17:29, Ian Campbell <Ian.Campbell@citrix.com>
> wrote:
> >>> > What are the outstanding things to do before we think we can start on
> >>> > the 4.2 -rc's? Does anyone have a timetable in mind?
> >>> >
> >>> > hypervisor:
> >>> >
> >>> >       * ??? - Keir, Tim, Jan?
> >>>
> >>> Apart from a few small things that I have on my todo list, the only
> >>> bigger one (at least from an possible impact perspective) is the
> >>> round-up of the closing of the security hole in MSI-X passthrough
> >>> (uniformly - i.e. even for Dom0 - disallowing write access to MSI-X
> >>> table pages), which I intended to do only once the upstream qemu
> >>> patch series also incorporates the respective recent qemu-xen
> >>> change.
> >>
> >> It sounds like this issue is a blocker for the release, whereas the
> >> upstream qemu support for pci passthrough is not necessarily. Has your
> >> precondition for inclusion been met yet or do we need to prod someone?
> >
> > Just for reference, below the intended (trivial) change.
>
> As unfortunate as it is - I just found that the security hole is all but
> closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing
> whatever the guest specified into the 3rd word of each MSI-X table
> entry. There is also another hypervisor data corrupting flaw in that
> code; I'm in the process of putting together a patch, but will (again)
> need someone with suitable hardware to test this.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


I do have a set of initial patches for xl remus. Since the "script=" support
doesnt exist for disk configurations (required to support both DRBD and
tapdisk backends).

So, currently I only have memory checkpointing functionality. No disk
buffering.
Will submit it in a day or so.

About network buffering:
a.  There is code to install and manipulate the network buffer via netlink
messages. And its
in python. While the "xl remus" control flow starts off from C. Either I
implement the C equivalent
of the python code or call the python code from C (this is C->python and
not the other way around).
Please correct me if I am wrong.

b. The kernel module (sch_plug):  Last I knew, the network
buffering module (sch_plug) was in the pvops tree (2.6.* series). When the
tree
moved to 3.0 series, it got axed off.

 While I am still, convincing the netdev folks into accepting this module
upstream,
I  have a link in the remus wiki, asking people to download/compile the
module.
(People do this only after shooting a couple of "Remus is not working"
emails to the
mailing list)

 As an alternative, I could pull it into the tools/remus/ folder (just like
the way it used to be before the pvops kernels) and compile it as part of
the
tools compilation process.

But as starters, people would be able to play with remus via xl (just
memory
checkpointing).
What do you folks think?

shriram

--0015175df06e7ad0a904b6e501d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">&gt;&gt;&gt; On 17.01.12 at 10:09, &quot;Jan Beulich&quot=
; &lt;<a href=3D"mailto:JBeulich@suse.com">JBeulich@suse.com</a>&gt; wrote:=
<br>
&gt;&gt;&gt;&gt; On 16.01.12 at 14:39, Ian Campbell &lt;<a href=3D"mailto:I=
an.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;&gt; On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:<br>
&gt;&gt;&gt; &gt;&gt;&gt; On 04.01.12 at 17:29, Ian Campbell &lt;<a href=3D=
"mailto:Ian.Campbell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt; What are the outstanding things to do before we think we =
can start on<br>
&gt;&gt;&gt; &gt; the 4.2 -rc&#39;s? Does anyone have a timetable in mind?<=
br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; hypervisor:<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; =A0 =A0 =A0 * ??? - Keir, Tim, Jan?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Apart from a few small things that I have on my todo list, the=
 only<br>
&gt;&gt;&gt; bigger one (at least from an possible impact perspective) is t=
he<br>
&gt;&gt;&gt; round-up of the closing of the security hole in MSI-X passthro=
ugh<br>
&gt;&gt;&gt; (uniformly - i.e. even for Dom0 - disallowing write access to =
MSI-X<br>
&gt;&gt;&gt; table pages), which I intended to do only once the upstream qe=
mu<br>
&gt;&gt;&gt; patch series also incorporates the respective recent qemu-xen<=
br>
&gt;&gt;&gt; change.<br>
&gt;&gt;<br>
&gt;&gt; It sounds like this issue is a blocker for the release, whereas th=
e<br>
&gt;&gt; upstream qemu support for pci passthrough is not necessarily. Has =
your<br>
&gt;&gt; precondition for inclusion been met yet or do we need to prod some=
one?<br>
&gt;<br>
&gt; Just for reference, below the intended (trivial) change.<br>
<br>
</div>As unfortunate as it is - I just found that the security hole is all =
but<br>
closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing<br>
whatever the guest specified into the 3rd word of each MSI-X table<br>
entry. There is also another hypervisor data corrupting flaw in that<br>
code; I&#39;m in the process of putting together a patch, but will (again)<=
br>
need someone with suitable hardware to test this.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><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><br>I do have a set of initial patches f=
or xl remus. Since the &quot;script=3D&quot; support<br>doesnt exist for di=
sk configurations (required to support both DRBD and tapdisk backends).<br>

<br>So, currently I only have memory checkpointing functionality. No disk b=
uffering.<br>Will submit it in a day or so.<br><br>About network buffering:=
<br>a.=A0 There is code to install and manipulate the network buffer via ne=
tlink messages. And its<br>

in python. While the &quot;xl remus&quot; control flow starts off from C. E=
ither I implement the C equivalent<br>of the python code or call the python=
 code from C (this is C-&gt;python and not the other way around).<br>Please=
 correct me if I am wrong.<br>

<br>b. The kernel module (sch_plug):=A0 Last I knew, the network<br>bufferi=
ng module (sch_plug) was in the pvops tree (2.6.* series). When the tree<br=
>moved to 3.0 series, it got axed off.<br><br>=A0While I am still, convinci=
ng the netdev folks into accepting this module upstream,<br>

I=A0 have a link in the remus wiki, asking people to download/compile the m=
odule.<br>(People do this only after shooting a couple of &quot;Remus is no=
t working&quot; emails to the<br>mailing list)<br><br>=A0As an alternative,=
 I could pull it into the tools/remus/ folder (just like<br>

the way it used to be before the pvops kernels) and compile it as part of t=
he<br>tools compilation process. <br><br>But as starters, people would be a=
ble to play with remus via xl (just memory <br>checkpointing).<br>What do y=
ou folks think?<br>

<br>shriram

--0015175df06e7ad0a904b6e501d1--


--===============4996946601700555767==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4996946601700555767==--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 17:47:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 17:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnw4L-00013V-Es; Thu, 19 Jan 2012 17:46:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rnw4J-0000yK-VV
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 17:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326995189!8023406!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 761 invoked from network); 19 Jan 2012 17:46:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 17:46:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10157803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 17:46:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 17:46:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 17:46:29 +0000
In-Reply-To: <CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326995189.17599.103.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <JBeulich@suse.com>
> wrote:
>         >>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com>
>         wrote:
>         >>>> On 16.01.12 at 14:39, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         >> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>         >>> >>> On 04.01.12 at 17:29, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         >>> > What are the outstanding things to do before we think we
>         can start on
>         >>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>         >>> >
>         >>> > hypervisor:
>         >>> >
>         >>> >       * ??? - Keir, Tim, Jan?
>         >>>
>         >>> Apart from a few small things that I have on my todo list,
>         the only
>         >>> bigger one (at least from an possible impact perspective)
>         is the
>         >>> round-up of the closing of the security hole in MSI-X
>         passthrough
>         >>> (uniformly - i.e. even for Dom0 - disallowing write access
>         to MSI-X
>         >>> table pages), which I intended to do only once the
>         upstream qemu
>         >>> patch series also incorporates the respective recent
>         qemu-xen
>         >>> change.
>         >>
>         >> It sounds like this issue is a blocker for the release,
>         whereas the
>         >> upstream qemu support for pci passthrough is not
>         necessarily. Has your
>         >> precondition for inclusion been met yet or do we need to
>         prod someone?
>         >
>         > Just for reference, below the intended (trivial) change.
>         
>         
>         As unfortunate as it is - I just found that the security hole
>         is all but
>         closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing
>         whatever the guest specified into the 3rd word of each MSI-X
>         table
>         entry. There is also another hypervisor data corrupting flaw
>         in that
>         code; I'm in the process of putting together a patch, but will
>         (again)
>         need someone with suitable hardware to test this.
>         
>         Jan
>         
>         
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@lists.xensource.com
>         http://lists.xensource.com/xen-devel
>         
> 
> 
> I do have a set of initial patches for xl remus. Since the "script="
> support doesnt exist for disk configurations (required to support both
> DRBD and tapdisk backends).
> 
> So, currently I only have memory checkpointing functionality. No disk
> buffering.
> Will submit it in a day or so.
> 
> About network buffering:
> a.  There is code to install and manipulate the network buffer via
> netlink messages. And its in python. While the "xl remus" control flow
> starts off from C. Either I implement the C equivalent
> of the python code or call the python code from C (this is C->python
> and not the other way around). Please correct me if I am wrong.

Wrong about what?

I don't think calling Python from C in libxl is a good idea. Forking a
process would be better but best would be to just implement the C
version. Is there a libnetlink which can help with this sort of thing?

> b. The kernel module (sch_plug):  Last I knew, the network
> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
> the tree moved to 3.0 series, it got axed off.

My understanding was that a competing module with similar/equivalent
functionality was the one which eventually made it upstream (I don't
know the names). Unfortunately this probably means that Remus needs to
switch over to the upstreamed thing.

There is no "Xen Linux tree" like there used to be and we wouldn't want
to carry a module which isn't ready for upstream in any case. (Your
module wasn't axed, it just wasn't/isn't upstream).

> While I am still, convincing the netdev folks into accepting this
> module upstream, I  have a link in the remus wiki, asking people to
> download/compile the module. (People do this only after shooting a
> couple of "Remus is not working" emails to the mailing list)

You can't detect this at runtime and print an error message? Do you not
get ENOSYS or something when you try and use the module?

>  As an alternative, I could pull it into the tools/remus/ folder (just
> like the way it used to be before the pvops kernels) and compile it as
> part of the tools compilation process. 

The build doesn't include building a kernel any more so I don't think
this will work.

> But as starters, people would be able to play with remus via xl (just
> memory checkpointing).
> What do you folks think?

I think it would be a good start to get just that bit in, as you say
people can play with it and it also lays the groundwork for the rest.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 17:47:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 17:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnw4L-00013V-Es; Thu, 19 Jan 2012 17:46:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rnw4J-0000yK-VV
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 17:46:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1326995189!8023406!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 761 invoked from network); 19 Jan 2012 17:46:29 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 17:46:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10157803"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 17:46:29 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 17:46:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 17:46:29 +0000
In-Reply-To: <CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1326995189.17599.103.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> On Thu, Jan 19, 2012 at 8:35 AM, Jan Beulich <JBeulich@suse.com>
> wrote:
>         >>> On 17.01.12 at 10:09, "Jan Beulich" <JBeulich@suse.com>
>         wrote:
>         >>>> On 16.01.12 at 14:39, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         >> On Wed, 2012-01-04 at 16:55 +0000, Jan Beulich wrote:
>         >>> >>> On 04.01.12 at 17:29, Ian Campbell
>         <Ian.Campbell@citrix.com> wrote:
>         >>> > What are the outstanding things to do before we think we
>         can start on
>         >>> > the 4.2 -rc's? Does anyone have a timetable in mind?
>         >>> >
>         >>> > hypervisor:
>         >>> >
>         >>> >       * ??? - Keir, Tim, Jan?
>         >>>
>         >>> Apart from a few small things that I have on my todo list,
>         the only
>         >>> bigger one (at least from an possible impact perspective)
>         is the
>         >>> round-up of the closing of the security hole in MSI-X
>         passthrough
>         >>> (uniformly - i.e. even for Dom0 - disallowing write access
>         to MSI-X
>         >>> table pages), which I intended to do only once the
>         upstream qemu
>         >>> patch series also incorporates the respective recent
>         qemu-xen
>         >>> change.
>         >>
>         >> It sounds like this issue is a blocker for the release,
>         whereas the
>         >> upstream qemu support for pci passthrough is not
>         necessarily. Has your
>         >> precondition for inclusion been met yet or do we need to
>         prod someone?
>         >
>         > Just for reference, below the intended (trivial) change.
>         
>         
>         As unfortunate as it is - I just found that the security hole
>         is all but
>         closed, due to xen/arch/x86/hvm/vmsi.c:msixtbl_write() writing
>         whatever the guest specified into the 3rd word of each MSI-X
>         table
>         entry. There is also another hypervisor data corrupting flaw
>         in that
>         code; I'm in the process of putting together a patch, but will
>         (again)
>         need someone with suitable hardware to test this.
>         
>         Jan
>         
>         
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@lists.xensource.com
>         http://lists.xensource.com/xen-devel
>         
> 
> 
> I do have a set of initial patches for xl remus. Since the "script="
> support doesnt exist for disk configurations (required to support both
> DRBD and tapdisk backends).
> 
> So, currently I only have memory checkpointing functionality. No disk
> buffering.
> Will submit it in a day or so.
> 
> About network buffering:
> a.  There is code to install and manipulate the network buffer via
> netlink messages. And its in python. While the "xl remus" control flow
> starts off from C. Either I implement the C equivalent
> of the python code or call the python code from C (this is C->python
> and not the other way around). Please correct me if I am wrong.

Wrong about what?

I don't think calling Python from C in libxl is a good idea. Forking a
process would be better but best would be to just implement the C
version. Is there a libnetlink which can help with this sort of thing?

> b. The kernel module (sch_plug):  Last I knew, the network
> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
> the tree moved to 3.0 series, it got axed off.

My understanding was that a competing module with similar/equivalent
functionality was the one which eventually made it upstream (I don't
know the names). Unfortunately this probably means that Remus needs to
switch over to the upstreamed thing.

There is no "Xen Linux tree" like there used to be and we wouldn't want
to carry a module which isn't ready for upstream in any case. (Your
module wasn't axed, it just wasn't/isn't upstream).

> While I am still, convincing the netdev folks into accepting this
> module upstream, I  have a link in the remus wiki, asking people to
> download/compile the module. (People do this only after shooting a
> couple of "Remus is not working" emails to the mailing list)

You can't detect this at runtime and print an error message? Do you not
get ENOSYS or something when you try and use the module?

>  As an alternative, I could pull it into the tools/remus/ folder (just
> like the way it used to be before the pvops kernels) and compile it as
> part of the tools compilation process. 

The build doesn't include building a kernel any more so I don't think
this will work.

> But as starters, people would be able to play with remus via xl (just
> memory checkpointing).
> What do you folks think?

I think it would be a good start to get just that bit in, as you say
people can play with it and it also lays the groundwork for the rest.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 18:18:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 18: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 1RnwYT-0002Cv-5t; Thu, 19 Jan 2012 18:17:45 +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 1RnwYR-0002CC-Jh
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 18:17:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326997057!11587284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19205 invoked from network); 19 Jan 2012 18:17:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 18:17:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10158678"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 18:17: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, 19 Jan 2012 18:17: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 1RnwXn-0007zV-Rw;
	Thu, 19 Jan 2012 18:17:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnwXn-0005vH-Qp;
	Thu, 19 Jan 2012 18:17:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10902-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 18:17:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10902: 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 10902 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10902/

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. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2273ef2083d4
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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 966 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 Jan 19 18:18:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 18: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 1RnwYT-0002Cv-5t; Thu, 19 Jan 2012 18:17:45 +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 1RnwYR-0002CC-Jh
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 18:17:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1326997057!11587284!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19205 invoked from network); 19 Jan 2012 18:17:37 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 18:17:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10158678"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 18:17: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, 19 Jan 2012 18:17: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 1RnwXn-0007zV-Rw;
	Thu, 19 Jan 2012 18:17:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnwXn-0005vH-Qp;
	Thu, 19 Jan 2012 18:17:03 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10902-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 18:17:03 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10902: 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 10902 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10902/

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. 10649
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 10649
 test-amd64-i386-win           7 windows-install           fail REGR. vs. 10649

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  2273ef2083d4
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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 966 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 Jan 19 19:01:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 19:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnxDw-0003MJ-FH; Thu, 19 Jan 2012 19:00:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RnxDu-0003M1-7c
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 19:00:34 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326999626!11617859!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 474 invoked from network); 19 Jan 2012 19:00:27 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 19:00:27 -0000
Received: by yhnn56 with SMTP id n56so2468504yhn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 11:00:25 -0800 (PST)
Received: by 10.236.124.68 with SMTP id w44mr37155892yhh.6.1326999625854;
	Thu, 19 Jan 2012 11:00:25 -0800 (PST)
Received: from [128.189.206.131] (host131-206.wifi.ubc.ca. [128.189.206.131])
	by mx.google.com with ESMTPS id p1sm618721anj.17.2012.01.19.11.00.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 11:00:24 -0800 (PST)
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326995189.17599.103.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0 (1.0)
Message-Id: <146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 11:00:19 -0800
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
>> 
>> 
>> I do have a set of initial patches for xl remus. Since the "script="
>> support doesnt exist for disk configurations (required to support both
>> DRBD and tapdisk backends).
>> 
>> So, currently I only have memory checkpointing functionality. No disk
>> buffering.
>> Will submit it in a day or so.
>> 
>> About network buffering:
>> a.  There is code to install and manipulate the network buffer via
>> netlink messages. And its in python. While the "xl remus" control flow
>> starts off from C. Either I implement the C equivalent
>> of the python code or call the python code from C (this is C->python
>> and not the other way around). Please correct me if I am wrong.
> 
> Wrong about what?
> 
> I don't think calling Python from C in libxl is a good idea. Forking a
> process would be better but best would be to just implement the C
> version. Is there a libnetlink which can help with this sort of thing?
> 

There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)

Just that it's bit cryptic and the netlink.py module makes things easy.
>> b. The kernel module (sch_plug):  Last I knew, the network
>> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
>> the tree moved to 3.0 series, it got axed off.
> 
> My understanding was that a competing module with similar/equivalent
> functionality was the one which eventually made it upstream (I don't
> know the names). Unfortunately this probably means that Remus needs to
> switch over to the upstreamed thing.
> 

I don't think so. When I submitted the patch for sch_plug to netdev, nobody (even the qdisc maintainer) mentioned anything about an equivalent module.


> There is no "Xen Linux tree" like there used to be and we wouldn't want
> to carry a module which isn't ready for upstream in any case. (Your
> module wasn't axed, it just wasn't/isn't upstream).
> 
>> While I am still, convincing the netdev folks into accepting this
>> module upstream, I  have a link in the remus wiki, asking people to
>> download/compile the module. (People do this only after shooting a
>> couple of "Remus is not working" emails to the mailing list)
> 
> You can't detect this at runtime and print an error message? Do you not
> get ENOSYS or something when you try and use the module?

I do. And the emails are despite that. 
> 
>> As an alternative, I could pull it into the tools/remus/ folder (just
>> like the way it used to be before the pvops kernels) and compile it as
>> part of the tools compilation process. 
> 
> The build doesn't include building a kernel any more so I don't think
> this will work.


But can we at least include the source, make file and a readme telling people to install the required packages needed to compile a module.

> 
>> But as starters, people would be able to play with remus via xl (just
>> memory checkpointing).
>> What do you folks think?
> 
> I think it would be a good start to get just that bit in, as you say
> people can play with it and it also lays the groundwork for the rest.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 19:01:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 19:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnxDw-0003MJ-FH; Thu, 19 Jan 2012 19:00:36 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RnxDu-0003M1-7c
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 19:00:34 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1326999626!11617859!1
X-Originating-IP: [209.85.213.43]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 474 invoked from network); 19 Jan 2012 19:00:27 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 19:00:27 -0000
Received: by yhnn56 with SMTP id n56so2468504yhn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 11:00:25 -0800 (PST)
Received: by 10.236.124.68 with SMTP id w44mr37155892yhh.6.1326999625854;
	Thu, 19 Jan 2012 11:00:25 -0800 (PST)
Received: from [128.189.206.131] (host131-206.wifi.ubc.ca. [128.189.206.131])
	by mx.google.com with ESMTPS id p1sm618721anj.17.2012.01.19.11.00.23
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 11:00:24 -0800 (PST)
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326995189.17599.103.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0 (1.0)
Message-Id: <146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 11:00:19 -0800
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
>> 
>> 
>> I do have a set of initial patches for xl remus. Since the "script="
>> support doesnt exist for disk configurations (required to support both
>> DRBD and tapdisk backends).
>> 
>> So, currently I only have memory checkpointing functionality. No disk
>> buffering.
>> Will submit it in a day or so.
>> 
>> About network buffering:
>> a.  There is code to install and manipulate the network buffer via
>> netlink messages. And its in python. While the "xl remus" control flow
>> starts off from C. Either I implement the C equivalent
>> of the python code or call the python code from C (this is C->python
>> and not the other way around). Please correct me if I am wrong.
> 
> Wrong about what?
> 
> I don't think calling Python from C in libxl is a good idea. Forking a
> process would be better but best would be to just implement the C
> version. Is there a libnetlink which can help with this sort of thing?
> 

There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)

Just that it's bit cryptic and the netlink.py module makes things easy.
>> b. The kernel module (sch_plug):  Last I knew, the network
>> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
>> the tree moved to 3.0 series, it got axed off.
> 
> My understanding was that a competing module with similar/equivalent
> functionality was the one which eventually made it upstream (I don't
> know the names). Unfortunately this probably means that Remus needs to
> switch over to the upstreamed thing.
> 

I don't think so. When I submitted the patch for sch_plug to netdev, nobody (even the qdisc maintainer) mentioned anything about an equivalent module.


> There is no "Xen Linux tree" like there used to be and we wouldn't want
> to carry a module which isn't ready for upstream in any case. (Your
> module wasn't axed, it just wasn't/isn't upstream).
> 
>> While I am still, convincing the netdev folks into accepting this
>> module upstream, I  have a link in the remus wiki, asking people to
>> download/compile the module. (People do this only after shooting a
>> couple of "Remus is not working" emails to the mailing list)
> 
> You can't detect this at runtime and print an error message? Do you not
> get ENOSYS or something when you try and use the module?

I do. And the emails are despite that. 
> 
>> As an alternative, I could pull it into the tools/remus/ folder (just
>> like the way it used to be before the pvops kernels) and compile it as
>> part of the tools compilation process. 
> 
> The build doesn't include building a kernel any more so I don't think
> this will work.


But can we at least include the source, make file and a readme telling people to install the required packages needed to compile a module.

> 
>> But as starters, people would be able to play with remus via xl (just
>> memory checkpointing).
>> What do you folks think?
> 
> I think it would be a good start to get just that bit in, as you say
> people can play with it and it also lays the groundwork for the rest.
> 
> Ian.
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 19:42:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 19:42:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnxrt-000409-T8; Thu, 19 Jan 2012 19:41:53 +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 1Rnxrs-000404-TU
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 19:41:53 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327002075!49141912!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3594 invoked from network); 19 Jan 2012 19:41:16 -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;
	19 Jan 2012 19:41:16 -0000
Received: by ggnk3 with SMTP id k3so1234149ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 11:41:50 -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=Rkaxnx+PtXLKbtc1saWgUL9rDDY0zBEo2g0WjxnV1qg=;
	b=b5QLxV7SrFA9AVmGf0Cz+t92ybZtnmlISwJxBWweY51EKg9cHjIeGZn6gxR4e5C/BF
	ZLeF0YtEkW7T6PTXshobXL60OQDaUnM7OsA5RO7TwrN7oXwJY2nHB6bgKZhpuVz4Kbd7
	ZbnU8x7V3shgvUWHqSapzVbKhT4t4XJXSxLEM=
Received: by 10.50.195.129 with SMTP id ie1mr28797790igc.29.1327002109982;
	Thu, 19 Jan 2012 11:41:49 -0800 (PST)
Received: from konrad-lan ([64.134.67.5])
	by mx.google.com with ESMTPS id lu10sm578579igc.0.2012.01.19.11.41.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 11:41:48 -0800 (PST)
Date: Thu, 19 Jan 2012 14:42:39 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <20120119194232.GA3728@konrad-lan>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EBA8FAA020000780005FD5F@nat28.tlf.novell.com>
	<4EBC125A.70300@goop.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EBC125A.70300@goop.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Jan Beulich <JBeulich@suse.com>, Laszlo Ersek <lersek@redhat.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 Thu, Nov 10, 2011 at 10:05:14AM -0800, Jeremy Fitzhardinge wrote:
> On 11/09/2011 05:35 AM, Jan Beulich wrote:
> >>>> 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).
> > After some more looking around I still think it's incorrect, albeit for
> > a different reason: What tick_nohz_restart_sched_tick() accounts
> > as idle time is *all* time that passed while in cpu_idle(). What gets
> > accounted in do_stolen_accounting() (without your patch) is
> > different:
> > - time the vCPU was in RUNSTATE_blocked gets accounted as idle
> > - time the vCPU was in RUNSTATE_runnable and RUNSTATE_offline
> >   gets accounted as stolen.
> >
> > That is, on an overcommitted system (and without your patch) I
> > would expect you to not see the (full) double idle increment for a not
> > fully idle and not fully loaded vCPU.
> >
> > Now we can of course say that for most purposes it's fine to
> > ignore the difference between idle and steal time, but there must
> > be a reason these have been getting accounted separately in Linux
> > without regard to Xen.
> >
> > So I really think that what needs to be suppressed to address this
> > is tick_nohz_restart_sched_tick()'s call to account_idle_ticks(). But
> > simply forcing CONFIG_VIRT_CPU_ACCOUNTING is not an immediate
> > option (not even when considering a Xen-only kernel), as that has
> > further implications. Instead I wonder whether under Xen we should
> > e.g. update per_cpu(tick_cpu_sched, cpu).idle_jiffies prior to calling
> > tick_nohz_restart_sched_tick() (possibly implicitly by doing the
> > update in do_stolen_accounting(), though that wouldn't work when
> > the wakeup is due to an interrupt other than the timer one).
> >
> > The alternative of accounting the negative of the steal time as
> > idle time in do_stolen_accounting() doesn't look correct either,
> > since not all stolen time was necessarily accounted as idle (some
> > would have got - also incorrectly - accounted as process or system
> > time).
> >
> > So my conclusion is that only the full implementation of what
> > CONFIG_VIRT_CPU_ACCOUNTING expects would actually get
> > things sorted out properly (but that would imply Xen *and* native
> > are willing to pay the performance price, or the enabling of this
> > can be made dynamic so that at least native could remain
> > unaffected).
> >
> > Or the negative stolen time should be accounted to the current
> > process, the system, or as idle, depending on the context which
> > do_stolen_accounting() runs in (just like timer_interrupt() did in
> > the XenoLinux kernels for positive accounting).
> 
> I was always suspicious of the timer-interrupt-based stolen time
> accounting code.  It's really a hold-over from when ticks were the main
> timekeeping mechanism, but with highres timers its massive overkill and
> probably a source of performance degradation.
> 
> Overall, the stolen time accounting isn't really very important.  The
> kernel doesn't use it at all internally - it doesn't affect scheduling
> decisions, for example.  It's only exported in /proc/stat, and some
> tools like top will display it if its non-zero.  It could be useful for
> diagnosing performance problems on a heavily loaded host system, but
> other tools like "xentop" would give you as much information.
> 
> So really, all this code is nice to have, but I'm not sure its worth a
> lot of time to fix, especially if it makes idle accounting hard (which
> *is* important).
> 
> However, that said, PeterZ recently added some code to the scheduler so
> that time "stolen" by interrupt handling isn't accounted against the
> task running at the time, and the design is specifically intended to
> also be useful for virtualization stolen time as well.  There are some
> KVM patches floating around to implement this, and we should look at

I finally got some time to look at them and I think they are these ones:

git log --oneline e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b255a4 
3c404b5 KVM guest: Add a pv_ops stub for steal time
c9aaa89 KVM: Steal time implementation
9ddabbe KVM: KVM Steal time guest/host interface
4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host interface

What is interesting is that they end up inserting a bunch of:

 
+       if (steal_account_process_tick())
+               return;
+

in irqtime_account_process_tick and in account_process_tick.

The steal_account_process_tick just makes a pv_time_ops.steal_clock
based on the asm goto of paravirt_steal_enabled key.

I think if we were to persue this we could rip out in the
'do_stolen_accounting' the call to 'accont_idle_tick' and
'account_idle_time' completly. In essence making that function
behave as a pv_time_ops.steal_clock implementation.

Also that would mean we could remove in the 'xen_timer_interrupt'
function the call to 'do_stolen_accounting'

I think this would mean we would account _only_ for the
RUNSTATE_runnable and RUNSTATE_offline as Laszlo's earlier patch
suggested?

And the RUNSTATE_blocked would be figured out by the existing
mechanism in the sched.c code?

> doing a Xen implementation.  That would be much more practically useful,
> since (I think) it allows the scheduler to be aware of stolen time and
> not penalize tasks for time they never got to use.  Or at the very least
> it could give you per-task stolen stats (maybe?) which would be useful.
> 
>     J
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 19 19:42:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 19:42:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnxrt-000409-T8; Thu, 19 Jan 2012 19:41:53 +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 1Rnxrs-000404-TU
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 19:41:53 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327002075!49141912!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3594 invoked from network); 19 Jan 2012 19:41:16 -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;
	19 Jan 2012 19:41:16 -0000
Received: by ggnk3 with SMTP id k3so1234149ggn.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 11:41:50 -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=Rkaxnx+PtXLKbtc1saWgUL9rDDY0zBEo2g0WjxnV1qg=;
	b=b5QLxV7SrFA9AVmGf0Cz+t92ybZtnmlISwJxBWweY51EKg9cHjIeGZn6gxR4e5C/BF
	ZLeF0YtEkW7T6PTXshobXL60OQDaUnM7OsA5RO7TwrN7oXwJY2nHB6bgKZhpuVz4Kbd7
	ZbnU8x7V3shgvUWHqSapzVbKhT4t4XJXSxLEM=
Received: by 10.50.195.129 with SMTP id ie1mr28797790igc.29.1327002109982;
	Thu, 19 Jan 2012 11:41:49 -0800 (PST)
Received: from konrad-lan ([64.134.67.5])
	by mx.google.com with ESMTPS id lu10sm578579igc.0.2012.01.19.11.41.44
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 11:41:48 -0800 (PST)
Date: Thu, 19 Jan 2012 14:42:39 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <20120119194232.GA3728@konrad-lan>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EBA8FAA020000780005FD5F@nat28.tlf.novell.com>
	<4EBC125A.70300@goop.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4EBC125A.70300@goop.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Jan Beulich <JBeulich@suse.com>, Laszlo Ersek <lersek@redhat.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 Thu, Nov 10, 2011 at 10:05:14AM -0800, Jeremy Fitzhardinge wrote:
> On 11/09/2011 05:35 AM, Jan Beulich wrote:
> >>>> 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).
> > After some more looking around I still think it's incorrect, albeit for
> > a different reason: What tick_nohz_restart_sched_tick() accounts
> > as idle time is *all* time that passed while in cpu_idle(). What gets
> > accounted in do_stolen_accounting() (without your patch) is
> > different:
> > - time the vCPU was in RUNSTATE_blocked gets accounted as idle
> > - time the vCPU was in RUNSTATE_runnable and RUNSTATE_offline
> >   gets accounted as stolen.
> >
> > That is, on an overcommitted system (and without your patch) I
> > would expect you to not see the (full) double idle increment for a not
> > fully idle and not fully loaded vCPU.
> >
> > Now we can of course say that for most purposes it's fine to
> > ignore the difference between idle and steal time, but there must
> > be a reason these have been getting accounted separately in Linux
> > without regard to Xen.
> >
> > So I really think that what needs to be suppressed to address this
> > is tick_nohz_restart_sched_tick()'s call to account_idle_ticks(). But
> > simply forcing CONFIG_VIRT_CPU_ACCOUNTING is not an immediate
> > option (not even when considering a Xen-only kernel), as that has
> > further implications. Instead I wonder whether under Xen we should
> > e.g. update per_cpu(tick_cpu_sched, cpu).idle_jiffies prior to calling
> > tick_nohz_restart_sched_tick() (possibly implicitly by doing the
> > update in do_stolen_accounting(), though that wouldn't work when
> > the wakeup is due to an interrupt other than the timer one).
> >
> > The alternative of accounting the negative of the steal time as
> > idle time in do_stolen_accounting() doesn't look correct either,
> > since not all stolen time was necessarily accounted as idle (some
> > would have got - also incorrectly - accounted as process or system
> > time).
> >
> > So my conclusion is that only the full implementation of what
> > CONFIG_VIRT_CPU_ACCOUNTING expects would actually get
> > things sorted out properly (but that would imply Xen *and* native
> > are willing to pay the performance price, or the enabling of this
> > can be made dynamic so that at least native could remain
> > unaffected).
> >
> > Or the negative stolen time should be accounted to the current
> > process, the system, or as idle, depending on the context which
> > do_stolen_accounting() runs in (just like timer_interrupt() did in
> > the XenoLinux kernels for positive accounting).
> 
> I was always suspicious of the timer-interrupt-based stolen time
> accounting code.  It's really a hold-over from when ticks were the main
> timekeeping mechanism, but with highres timers its massive overkill and
> probably a source of performance degradation.
> 
> Overall, the stolen time accounting isn't really very important.  The
> kernel doesn't use it at all internally - it doesn't affect scheduling
> decisions, for example.  It's only exported in /proc/stat, and some
> tools like top will display it if its non-zero.  It could be useful for
> diagnosing performance problems on a heavily loaded host system, but
> other tools like "xentop" would give you as much information.
> 
> So really, all this code is nice to have, but I'm not sure its worth a
> lot of time to fix, especially if it makes idle accounting hard (which
> *is* important).
> 
> However, that said, PeterZ recently added some code to the scheduler so
> that time "stolen" by interrupt handling isn't accounted against the
> task running at the time, and the design is specifically intended to
> also be useful for virtualization stolen time as well.  There are some
> KVM patches floating around to implement this, and we should look at

I finally got some time to look at them and I think they are these ones:

git log --oneline e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b255a4 
3c404b5 KVM guest: Add a pv_ops stub for steal time
c9aaa89 KVM: Steal time implementation
9ddabbe KVM: KVM Steal time guest/host interface
4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host interface

What is interesting is that they end up inserting a bunch of:

 
+       if (steal_account_process_tick())
+               return;
+

in irqtime_account_process_tick and in account_process_tick.

The steal_account_process_tick just makes a pv_time_ops.steal_clock
based on the asm goto of paravirt_steal_enabled key.

I think if we were to persue this we could rip out in the
'do_stolen_accounting' the call to 'accont_idle_tick' and
'account_idle_time' completly. In essence making that function
behave as a pv_time_ops.steal_clock implementation.

Also that would mean we could remove in the 'xen_timer_interrupt'
function the call to 'do_stolen_accounting'

I think this would mean we would account _only_ for the
RUNSTATE_runnable and RUNSTATE_offline as Laszlo's earlier patch
suggested?

And the RUNSTATE_blocked would be figured out by the existing
mechanism in the sched.c code?

> doing a Xen implementation.  That would be much more practically useful,
> since (I think) it allows the scheduler to be aware of stolen time and
> not penalize tasks for time they never got to use.  Or at the very least
> it could give you per-task stolen stats (maybe?) which would be useful.
> 
>     J
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 19 19:50:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 19:50:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnxzl-0004SH-SR; Thu, 19 Jan 2012 19:50:01 +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 1Rnxzk-0004SB-Dy
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 19:50:00 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327002593!11596764!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 4784 invoked from network); 19 Jan 2012 19:49:54 -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;
	19 Jan 2012 19:49:54 -0000
Received: by iahk25 with SMTP id k25so1884346iah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 11:49:52 -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=Q7zFbf91Dy7K16wNqp40vZd7m21NMac6pndSmn4RLYM=;
	b=GWlgAR6zp90dO399CsUMwbkfn+Hy0uRGryBD9FnqrjmNK1BOkSNe9k8wIxXUbsiTnc
	plBPy/rXkUQYjJejNJpEe4YgSqy/qNA9tQxHcUUjFl9e4DindbJrePAJY77e5hkux/iL
	17r7pMu8seehyGUbyQi36cwGi4IIkS0TFGokg=
Received: by 10.42.153.6 with SMTP id k6mr23351209icw.30.1327002592831;
	Thu, 19 Jan 2012 11:49:52 -0800 (PST)
Received: from konrad-lan ([64.134.67.5])
	by mx.google.com with ESMTPS id pb6sm561620igc.5.2012.01.19.11.49.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 11:49:51 -0800 (PST)
Date: Thu, 19 Jan 2012 14:50:49 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120119195046.GA3890@konrad-lan>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
	<CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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, Jan 18, 2012 at 01:16:10AM +0400, Vasiliy Tolstov wrote:
> 2012/1/18 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> > On Tue, Jan 17, 2012 at 12:58:14PM +0400, Vasiliy Tolstov wrote:
> >> Hello. Today i'm try to research, why most of our vm (pvm) not
> >> shutdown correctly (we use shutdown with timeout, then it arrives we
> >> destroy vm), and write simple test case to check that domU watches
> >
> > Which kernel version of DomU?
> 
> 2.6.32.26 from xen git tree and  2.6.18-194.26.1.el5xen

First order is to upgrade your kernel and see if the problem exists
with a newer 2.6.32.X tree. then also try 3.0 or 3.1 kernel.
> 
> 
> >
> > Play a bit with xenctx to get an idea where the guest is stuck at.
> >
> 
> Ok, nice. When i need to run xenctx and what i need to see in its output?

<sigh> Google for it. There should be tons of examples of how to use it
to figure out where the guest is stuck at.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 19:50:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 19:50:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnxzl-0004SH-SR; Thu, 19 Jan 2012 19:50:01 +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 1Rnxzk-0004SB-Dy
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 19:50:00 +0000
X-Env-Sender: konrad.r.wilk@gmail.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327002593!11596764!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 4784 invoked from network); 19 Jan 2012 19:49:54 -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;
	19 Jan 2012 19:49:54 -0000
Received: by iahk25 with SMTP id k25so1884346iah.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 11:49:52 -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=Q7zFbf91Dy7K16wNqp40vZd7m21NMac6pndSmn4RLYM=;
	b=GWlgAR6zp90dO399CsUMwbkfn+Hy0uRGryBD9FnqrjmNK1BOkSNe9k8wIxXUbsiTnc
	plBPy/rXkUQYjJejNJpEe4YgSqy/qNA9tQxHcUUjFl9e4DindbJrePAJY77e5hkux/iL
	17r7pMu8seehyGUbyQi36cwGi4IIkS0TFGokg=
Received: by 10.42.153.6 with SMTP id k6mr23351209icw.30.1327002592831;
	Thu, 19 Jan 2012 11:49:52 -0800 (PST)
Received: from konrad-lan ([64.134.67.5])
	by mx.google.com with ESMTPS id pb6sm561620igc.5.2012.01.19.11.49.50
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 19 Jan 2012 11:49:51 -0800 (PST)
Date: Thu, 19 Jan 2012 14:50:49 -0500
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Vasiliy Tolstov <v.tolstov@selfip.ru>
Message-ID: <20120119195046.GA3890@konrad-lan>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
	<CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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, Jan 18, 2012 at 01:16:10AM +0400, Vasiliy Tolstov wrote:
> 2012/1/18 Konrad Rzeszutek Wilk <konrad@darnok.org>:
> > On Tue, Jan 17, 2012 at 12:58:14PM +0400, Vasiliy Tolstov wrote:
> >> Hello. Today i'm try to research, why most of our vm (pvm) not
> >> shutdown correctly (we use shutdown with timeout, then it arrives we
> >> destroy vm), and write simple test case to check that domU watches
> >
> > Which kernel version of DomU?
> 
> 2.6.32.26 from xen git tree and  2.6.18-194.26.1.el5xen

First order is to upgrade your kernel and see if the problem exists
with a newer 2.6.32.X tree. then also try 3.0 or 3.1 kernel.
> 
> 
> >
> > Play a bit with xenctx to get an idea where the guest is stuck at.
> >
> 
> Ok, nice. When i need to run xenctx and what i need to see in its output?

<sigh> Google for it. There should be tons of examples of how to use it
to figure out where the guest is stuck at.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 20:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20: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 1Rnycr-00052Z-8S; Thu, 19 Jan 2012 20:30:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rnycp-00052U-HM
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:30:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327004892!49297511!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjAwODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32061 invoked from network); 19 Jan 2012 20:28:13 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-27.messagelabs.com with SMTP;
	19 Jan 2012 20:28:13 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id A44D95EC081;
	Thu, 19 Jan 2012 12:30:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:cc:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=jnAmzDwj
	7821WNwI0jopfu1ovYq/LFZT7k8/sqpC09yqtohH+HVz5waus7S3zS035RffYObB
	hnn6ueOehV69iPeQ1DsnkoIU91OO9cps4mPPr4WNRdyjCiMrZJzdXSLIepr1cqlr
	PW4ETOuiQLQ64j0HUa40RvYumRJv+RTNjcw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:cc:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	/0jdlz3CoXTnteTTRCSsz6vtojo=; b=ZpcKwGiXnH/xvpGN4KavvExhUZ5rbDOo
	kSzGfpcinGUZZzj1eST122mhrcWOq8GwSVEhMjKU93aAHcYEC0L+fN6UmJnXP6IC
	/TFoosZWLqnvlBZtI/QtyTeT5k/R6x2ueD06hCmDLG6n+LlOO84e7MAW8Ikzkk9r
	EI7AVK0qmoQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 7E1E35EC080; 
	Thu, 19 Jan 2012 12:30: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;
	Thu, 19 Jan 2012 12:30:21 -0800
Message-ID: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
Date: Thu, 19 Jan 2012 12:30:21 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] memop struct packing, 32/64 bits
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,
I had the following painful experience. I declared

struct xen_mem_event_op {
    uint8_t       op;           /* XENMEM_*_op_* */
    domid_t       domain;
    uint64_t buffer;
    uint64_t gfn;          /* IN:  gfn of page being operated on */
};
typedef struct xen_mem_event_op xen_mem_event_op_t;

to be passed as the argument of a memory op called form the toolstack. The
hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
simply:

    xen_mem_event_op_t meo;
... set fields ...
    return do_memory_op(xch, mode, &meo, sizeof(meo));

No joy because 32 bits was packing the struct differently than 64 bits.
Namely, both were adding a 1 byte pad between 'op' and 'domain', but when
compiled in 64 bits mode for the hypervisor, an additional 4 byte pad was
thrown between 'domain' and 'buffer'.

The first question is, what is the preferred way around this. Declare pads
inside the struct?

Exploring the include/public/memory.h declarations and toolstack code, I
see that no current declare includes __attribute__((aligned)) or
__attribute__((packed)), or explicit pads.

So how come things don't break more often for 32 bit toolstacks? pure
luck? Am I missing something?

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 Jan 19 20:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20: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 1Rnycr-00052Z-8S; Thu, 19 Jan 2012 20:30:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rnycp-00052U-HM
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:30:23 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327004892!49297511!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjAwODM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32061 invoked from network); 19 Jan 2012 20:28:13 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.145) by server-14.tower-27.messagelabs.com with SMTP;
	19 Jan 2012 20:28:13 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id A44D95EC081;
	Thu, 19 Jan 2012 12:30:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:date:subject:from:to:cc:reply-to:mime-version:content-type:
	content-transfer-encoding; q=dns; s=lagarcavilla.org; b=jnAmzDwj
	7821WNwI0jopfu1ovYq/LFZT7k8/sqpC09yqtohH+HVz5waus7S3zS035RffYObB
	hnn6ueOehV69iPeQ1DsnkoIU91OO9cps4mPPr4WNRdyjCiMrZJzdXSLIepr1cqlr
	PW4ETOuiQLQ64j0HUa40RvYumRJv+RTNjcw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	message-id:date:subject:from:to:cc:reply-to:mime-version
	:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=
	/0jdlz3CoXTnteTTRCSsz6vtojo=; b=ZpcKwGiXnH/xvpGN4KavvExhUZ5rbDOo
	kSzGfpcinGUZZzj1eST122mhrcWOq8GwSVEhMjKU93aAHcYEC0L+fN6UmJnXP6IC
	/TFoosZWLqnvlBZtI/QtyTeT5k/R6x2ueD06hCmDLG6n+LlOO84e7MAW8Ikzkk9r
	EI7AVK0qmoQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 7E1E35EC080; 
	Thu, 19 Jan 2012 12:30: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;
	Thu, 19 Jan 2012 12:30:21 -0800
Message-ID: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
Date: Thu, 19 Jan 2012 12:30:21 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] memop struct packing, 32/64 bits
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,
I had the following painful experience. I declared

struct xen_mem_event_op {
    uint8_t       op;           /* XENMEM_*_op_* */
    domid_t       domain;
    uint64_t buffer;
    uint64_t gfn;          /* IN:  gfn of page being operated on */
};
typedef struct xen_mem_event_op xen_mem_event_op_t;

to be passed as the argument of a memory op called form the toolstack. The
hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
simply:

    xen_mem_event_op_t meo;
... set fields ...
    return do_memory_op(xch, mode, &meo, sizeof(meo));

No joy because 32 bits was packing the struct differently than 64 bits.
Namely, both were adding a 1 byte pad between 'op' and 'domain', but when
compiled in 64 bits mode for the hypervisor, an additional 4 byte pad was
thrown between 'domain' and 'buffer'.

The first question is, what is the preferred way around this. Declare pads
inside the struct?

Exploring the include/public/memory.h declarations and toolstack code, I
see that no current declare includes __attribute__((aligned)) or
__attribute__((packed)), or explicit pads.

So how come things don't break more often for 32 bit toolstacks? pure
luck? Am I missing something?

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 Jan 19 20:43:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20: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 1Rnyoh-0005D3-KM; Thu, 19 Jan 2012 20:42: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 1Rnyog-0005Cy-9P
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:42:38 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327005713!60970188!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 19612 invoked from network); 19 Jan 2012 20:41:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 20:41: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
	q0JKgRw6003583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 19 Jan 2012 15:42:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0JKgRIF003581;
	Thu, 19 Jan 2012 15:42:27 -0500
Date: Thu, 19 Jan 2012 16:42:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Message-ID: <20120119204227.GA3360@andromeda.dapyr.net>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
User-Agent: Mutt/1.5.9i
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagopalan wrote:
> On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> >> 
> >> 
> >> I do have a set of initial patches for xl remus. Since the "script="
> >> support doesnt exist for disk configurations (required to support both
> >> DRBD and tapdisk backends).
> >> 
> >> So, currently I only have memory checkpointing functionality. No disk
> >> buffering.

Were the disk buffering implemented in kernel? As a dm-* device or
through blktap (which is not maintained)?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 20:43:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20: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 1Rnyoh-0005D3-KM; Thu, 19 Jan 2012 20:42: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 1Rnyog-0005Cy-9P
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:42:38 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327005713!60970188!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 19612 invoked from network); 19 Jan 2012 20:41:55 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 20:41: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
	q0JKgRw6003583
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 19 Jan 2012 15:42:27 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0JKgRIF003581;
	Thu, 19 Jan 2012 15:42:27 -0500
Date: Thu, 19 Jan 2012 16:42:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Message-ID: <20120119204227.GA3360@andromeda.dapyr.net>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
User-Agent: Mutt/1.5.9i
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagopalan wrote:
> On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> >> 
> >> 
> >> I do have a set of initial patches for xl remus. Since the "script="
> >> support doesnt exist for disk configurations (required to support both
> >> DRBD and tapdisk backends).
> >> 
> >> So, currently I only have memory checkpointing functionality. No disk
> >> buffering.

Were the disk buffering implemented in kernel? As a dm-* device or
through blktap (which is not maintained)?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 20:50:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnyvi-0005f9-TT; Thu, 19 Jan 2012 20:49:54 +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 1Rnyvh-0005et-GD
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:49:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327006142!49321242!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 5068 invoked from network); 19 Jan 2012 20:49:03 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 20:49:03 -0000
Received: by werb14 with SMTP id b14so347995wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 12:49:49 -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=03MUDyUwxI7E+UyvOg3TXX3DvqhCTkgthX3Axke/C0U=;
	b=DUrxZgoyjbsTIEKMF701CBOvUKn9gQeXqIohGgK0JXpmWTHP844ME7B12r/pjUF2KC
	y/X/bBWc0vQiZDlFFrj4s2CvEPFzyLiWS+jirDziZ+e+CpogeVFMfv8BNGKT//TTrl24
	nBVQ4Kvo/G6N9h9Llqkb7qMU8QqdBOtt5XYQ8=
Received: by 10.216.133.204 with SMTP id q54mr1306863wei.2.1327006189052;
	Thu, 19 Jan 2012 12:49:49 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id t15sm26224919wiv.6.2012.01.19.12.49.47
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 12:49:48 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 20:49:39 +0000
From: Keir Fraser <keir@xen.org>
To: <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3E3263.37CC2%keir@xen.org>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW69xiuNn0lwJ92E+OphrmiKmAng==
In-Reply-To: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
Mime-version: 1.0
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

> Hi,
> I had the following painful experience. I declared
> 
> struct xen_mem_event_op {
>     uint8_t       op;           /* XENMEM_*_op_* */
>     domid_t       domain;
>     uint64_t buffer;
>     uint64_t gfn;          /* IN:  gfn of page being operated on */
> };
> typedef struct xen_mem_event_op xen_mem_event_op_t;
> 
> to be passed as the argument of a memory op called form the toolstack. The
> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
> simply:
> 
>     xen_mem_event_op_t meo;
> ... set fields ...
>     return do_memory_op(xch, mode, &meo, sizeof(meo));
> 
> No joy because 32 bits was packing the struct differently than 64 bits.
> Namely, both were adding a 1 byte pad between 'op' and 'domain', but when
> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad was
> thrown between 'domain' and 'buffer'.
> 
> The first question is, what is the preferred way around this. Declare pads
> inside the struct?

Yes.

> Exploring the include/public/memory.h declarations and toolstack code, I
> see that no current declare includes __attribute__((aligned)) or
> __attribute__((packed)), or explicit pads.
> 
> So how come things don't break more often for 32 bit toolstacks? pure
> luck? Am I missing something?

Where older structs were not 32/64-bit invariant, compat shims were
implemented. See common/compat/memory.c, for example. Well worth avoiding
that!

 -- Keir

> Thanks!
> Andres
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 19 20:50:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20:50:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnyvi-0005f9-TT; Thu, 19 Jan 2012 20:49:54 +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 1Rnyvh-0005et-GD
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:49:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327006142!49321242!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 5068 invoked from network); 19 Jan 2012 20:49:03 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 20:49:03 -0000
Received: by werb14 with SMTP id b14so347995wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 12:49:49 -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=03MUDyUwxI7E+UyvOg3TXX3DvqhCTkgthX3Axke/C0U=;
	b=DUrxZgoyjbsTIEKMF701CBOvUKn9gQeXqIohGgK0JXpmWTHP844ME7B12r/pjUF2KC
	y/X/bBWc0vQiZDlFFrj4s2CvEPFzyLiWS+jirDziZ+e+CpogeVFMfv8BNGKT//TTrl24
	nBVQ4Kvo/G6N9h9Llqkb7qMU8QqdBOtt5XYQ8=
Received: by 10.216.133.204 with SMTP id q54mr1306863wei.2.1327006189052;
	Thu, 19 Jan 2012 12:49:49 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id t15sm26224919wiv.6.2012.01.19.12.49.47
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 12:49:48 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 20:49:39 +0000
From: Keir Fraser <keir@xen.org>
To: <andres@lagarcavilla.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB3E3263.37CC2%keir@xen.org>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW69xiuNn0lwJ92E+OphrmiKmAng==
In-Reply-To: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
Mime-version: 1.0
Cc: ian.jackson@citrix.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

> Hi,
> I had the following painful experience. I declared
> 
> struct xen_mem_event_op {
>     uint8_t       op;           /* XENMEM_*_op_* */
>     domid_t       domain;
>     uint64_t buffer;
>     uint64_t gfn;          /* IN:  gfn of page being operated on */
> };
> typedef struct xen_mem_event_op xen_mem_event_op_t;
> 
> to be passed as the argument of a memory op called form the toolstack. The
> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
> simply:
> 
>     xen_mem_event_op_t meo;
> ... set fields ...
>     return do_memory_op(xch, mode, &meo, sizeof(meo));
> 
> No joy because 32 bits was packing the struct differently than 64 bits.
> Namely, both were adding a 1 byte pad between 'op' and 'domain', but when
> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad was
> thrown between 'domain' and 'buffer'.
> 
> The first question is, what is the preferred way around this. Declare pads
> inside the struct?

Yes.

> Exploring the include/public/memory.h declarations and toolstack code, I
> see that no current declare includes __attribute__((aligned)) or
> __attribute__((packed)), or explicit pads.
> 
> So how come things don't break more often for 32 bit toolstacks? pure
> luck? Am I missing something?

Where older structs were not 32/64-bit invariant, compat shims were
implemented. See common/compat/memory.c, for example. Well worth avoiding
that!

 -- Keir

> Thanks!
> Andres
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 19 20:50:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnyvi-0005f2-Gy; Thu, 19 Jan 2012 20:49:54 +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 1Rnyvh-0005es-Eg
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:49:53 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327006185!9423672!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 18865 invoked from network); 19 Jan 2012 20:49:47 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 20:49:47 -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
	q0JKnf7S003839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 19 Jan 2012 15:49:41 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0JKnf0Z003837;
	Thu, 19 Jan 2012 15:49:41 -0500
Date: Thu, 19 Jan 2012 16:49:41 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119204941.GB3360@andromeda.dapyr.net>
References: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.9i
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 19, 2012 at 12:30:21PM -0800, Andres Lagar-Cavilla wrote:
> Hi,
> I had the following painful experience. I declared
> 
> struct xen_mem_event_op {
>     uint8_t       op;           /* XENMEM_*_op_* */
>     domid_t       domain;
>     uint64_t buffer;
>     uint64_t gfn;          /* IN:  gfn of page being operated on */
> };
> typedef struct xen_mem_event_op xen_mem_event_op_t;
> 
> to be passed as the argument of a memory op called form the toolstack. The
> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
> simply:
> 
>     xen_mem_event_op_t meo;
> ... set fields ...
>     return do_memory_op(xch, mode, &meo, sizeof(meo));
> 
> No joy because 32 bits was packing the struct differently than 64 bits.
> Namely, both were adding a 1 byte pad between 'op' and 'domain', but when
> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad was
> thrown between 'domain' and 'buffer'.
> 

> The first question is, what is the preferred way around this. Declare pads
> inside the struct?

Yes. And also use __attribute(__packed__); 
> 
> Exploring the include/public/memory.h declarations and toolstack code, I
> see that no current declare includes __attribute__((aligned)) or
> __attribute__((packed)), or explicit pads.

Sometimes they have #pragma(4), which will make the alignment be
32-bit (4-bytes) for 64-bit builds as well.
> 
> So how come things don't break more often for 32 bit toolstacks? pure
> luck? Am I missing something?

If you do not use 'memcpy' you can escape some of these misues.

> 
> Thanks!
> Andres
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 19 20:50:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20:50:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnyvi-0005f2-Gy; Thu, 19 Jan 2012 20:49:54 +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 1Rnyvh-0005es-Eg
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:49:53 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327006185!9423672!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 18865 invoked from network); 19 Jan 2012 20:49:47 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 19 Jan 2012 20:49:47 -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
	q0JKnf7S003839
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 19 Jan 2012 15:49:41 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0JKnf0Z003837;
	Thu, 19 Jan 2012 15:49:41 -0500
Date: Thu, 19 Jan 2012 16:49:41 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120119204941.GB3360@andromeda.dapyr.net>
References: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.9i
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 19, 2012 at 12:30:21PM -0800, Andres Lagar-Cavilla wrote:
> Hi,
> I had the following painful experience. I declared
> 
> struct xen_mem_event_op {
>     uint8_t       op;           /* XENMEM_*_op_* */
>     domid_t       domain;
>     uint64_t buffer;
>     uint64_t gfn;          /* IN:  gfn of page being operated on */
> };
> typedef struct xen_mem_event_op xen_mem_event_op_t;
> 
> to be passed as the argument of a memory op called form the toolstack. The
> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
> simply:
> 
>     xen_mem_event_op_t meo;
> ... set fields ...
>     return do_memory_op(xch, mode, &meo, sizeof(meo));
> 
> No joy because 32 bits was packing the struct differently than 64 bits.
> Namely, both were adding a 1 byte pad between 'op' and 'domain', but when
> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad was
> thrown between 'domain' and 'buffer'.
> 

> The first question is, what is the preferred way around this. Declare pads
> inside the struct?

Yes. And also use __attribute(__packed__); 
> 
> Exploring the include/public/memory.h declarations and toolstack code, I
> see that no current declare includes __attribute__((aligned)) or
> __attribute__((packed)), or explicit pads.

Sometimes they have #pragma(4), which will make the alignment be
32-bit (4-bytes) for 64-bit builds as well.
> 
> So how come things don't break more often for 32 bit toolstacks? pure
> luck? Am I missing something?

If you do not use 'memcpy' you can escape some of these misues.

> 
> Thanks!
> Andres
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 19 20:57:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20:57:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnz2p-0005zb-3b; Thu, 19 Jan 2012 20:57:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rnz2n-0005zW-Mv
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:57:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327006580!53298433!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTg4MzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26735 invoked from network); 19 Jan 2012 20:56:20 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-3.tower-27.messagelabs.com with SMTP;
	19 Jan 2012 20:56:20 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 94147300064;
	Thu, 19 Jan 2012 12:57:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=sESaZaQmPjkML3FLzwFBC201qKe3ZeG0uFhWNJyDY66u
	EDvz8Var66c9zm60KtWRDa8BHr0fBmI964NSvuM7q6sJT+r0eSgh0uXp7BoHyFDM
	uukGoegVe5n8uJlbc1LxnBnI1L0Fg6xoMI59yhTRUD9ENDSrf2iWmo9rld71yA8=
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=QZiVkQAXldQLU25DtzHkQPQ5H3Q=; b=BA7772XD
	j89aeNFO0OuR8wCKkHGu5Awko4Ficekl9OAe/3Xvw+8Vjo8IsSHvBDDURuyVWQnN
	qg6C16eaSdRpM8kmVUem1rtCW5OABqEZQp2WJwYXhTTstJzmTEIt31jmrOdu5+BD
	DVUXxObF3KsXvbZrRVRJ3NpVGLnM5LW0mYQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 3139F300061; 
	Thu, 19 Jan 2012 12:57:11 -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, 19 Jan 2012 12:57:11 -0800
Message-ID: <3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB3E3263.37CC2%keir@xen.org>
References: <CB3E3263.37CC2%keir@xen.org>
Date: Thu, 19 Jan 2012 12:57:11 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk" <konrad@darnok.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
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 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> wrote:
>
>> Hi,
>> I had the following painful experience. I declared
>>
>> struct xen_mem_event_op {
>>     uint8_t       op;           /* XENMEM_*_op_* */
>>     domid_t       domain;
>>     uint64_t buffer;
>>     uint64_t gfn;          /* IN:  gfn of page being operated on */
>> };
>> typedef struct xen_mem_event_op xen_mem_event_op_t;
>>
>> to be passed as the argument of a memory op called form the toolstack.
>> The
>> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
>> simply:
>>
>>     xen_mem_event_op_t meo;
>> ... set fields ...
>>     return do_memory_op(xch, mode, &meo, sizeof(meo));
>>
>> No joy because 32 bits was packing the struct differently than 64 bits.
>> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
>> when
>> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
>> was
>> thrown between 'domain' and 'buffer'.
>>
>> The first question is, what is the preferred way around this. Declare
>> pads
>> inside the struct?
>
> Yes.

Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
memory.h

Thanks!
Andres

>
>> Exploring the include/public/memory.h declarations and toolstack code, I
>> see that no current declare includes __attribute__((aligned)) or
>> __attribute__((packed)), or explicit pads.
>>
>> So how come things don't break more often for 32 bit toolstacks? pure
>> luck? Am I missing something?
>
> Where older structs were not 32/64-bit invariant, compat shims were
> implemented. See common/compat/memory.c, for example. Well worth avoiding
> that!
>
>  -- Keir
>
>> Thanks!
>> Andres
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/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 Jan 19 20:57:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 20:57:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnz2p-0005zb-3b; Thu, 19 Jan 2012 20:57:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rnz2n-0005zW-Mv
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 20:57:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327006580!53298433!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTg4MzU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26735 invoked from network); 19 Jan 2012 20:56:20 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.177) by server-3.tower-27.messagelabs.com with SMTP;
	19 Jan 2012 20:56:20 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 94147300064;
	Thu, 19 Jan 2012 12:57:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=sESaZaQmPjkML3FLzwFBC201qKe3ZeG0uFhWNJyDY66u
	EDvz8Var66c9zm60KtWRDa8BHr0fBmI964NSvuM7q6sJT+r0eSgh0uXp7BoHyFDM
	uukGoegVe5n8uJlbc1LxnBnI1L0Fg6xoMI59yhTRUD9ENDSrf2iWmo9rld71yA8=
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=QZiVkQAXldQLU25DtzHkQPQ5H3Q=; b=BA7772XD
	j89aeNFO0OuR8wCKkHGu5Awko4Ficekl9OAe/3Xvw+8Vjo8IsSHvBDDURuyVWQnN
	qg6C16eaSdRpM8kmVUem1rtCW5OABqEZQp2WJwYXhTTstJzmTEIt31jmrOdu5+BD
	DVUXxObF3KsXvbZrRVRJ3NpVGLnM5LW0mYQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 3139F300061; 
	Thu, 19 Jan 2012 12:57:11 -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, 19 Jan 2012 12:57:11 -0800
Message-ID: <3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB3E3263.37CC2%keir@xen.org>
References: <CB3E3263.37CC2%keir@xen.org>
Date: Thu, 19 Jan 2012 12:57:11 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir@xen.org>, "Konrad Rzeszutek Wilk" <konrad@darnok.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
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 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> wrote:
>
>> Hi,
>> I had the following painful experience. I declared
>>
>> struct xen_mem_event_op {
>>     uint8_t       op;           /* XENMEM_*_op_* */
>>     domid_t       domain;
>>     uint64_t buffer;
>>     uint64_t gfn;          /* IN:  gfn of page being operated on */
>> };
>> typedef struct xen_mem_event_op xen_mem_event_op_t;
>>
>> to be passed as the argument of a memory op called form the toolstack.
>> The
>> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
>> simply:
>>
>>     xen_mem_event_op_t meo;
>> ... set fields ...
>>     return do_memory_op(xch, mode, &meo, sizeof(meo));
>>
>> No joy because 32 bits was packing the struct differently than 64 bits.
>> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
>> when
>> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
>> was
>> thrown between 'domain' and 'buffer'.
>>
>> The first question is, what is the preferred way around this. Declare
>> pads
>> inside the struct?
>
> Yes.

Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
memory.h

Thanks!
Andres

>
>> Exploring the include/public/memory.h declarations and toolstack code, I
>> see that no current declare includes __attribute__((aligned)) or
>> __attribute__((packed)), or explicit pads.
>>
>> So how come things don't break more often for 32 bit toolstacks? pure
>> luck? Am I missing something?
>
> Where older structs were not 32/64-bit invariant, compat shims were
> implemented. See common/compat/memory.c, for example. Well worth avoiding
> that!
>
>  -- Keir
>
>> Thanks!
>> Andres
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/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 Jan 19 21:07:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzCd-0006Bo-8B; Thu, 19 Jan 2012 21:07:23 +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 1RnzCb-0006Bj-Gh
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:07:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327007234!9898736!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 27604 invoked from network); 19 Jan 2012 21:07:15 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:07:15 -0000
Received: by werb14 with SMTP id b14so397299wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:07: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=eOvcs+kUo1c1Et3F2bmxVZb9wczqAnbDWO6XKoZvJ4c=;
	b=p/BblCxBb4KOW5ozcDyphhjqBJre9Bm7pETFpFUKWonOjlF/RdOkD2sTbNnoY2t6i1
	K4tjpEsGSYrAG6Q2YR0jF6er9uNucwo5Wxq/Jvo/NRqcQV4nmEJUCGfFbtT9RiJmgsZm
	bjQdet6QapW+3MM6VMH3BMnjkdofqLNsiiFpg=
Received: by 10.216.140.223 with SMTP id e73mr1242419wej.54.1327007234828;
	Thu, 19 Jan 2012 13:07:14 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id hv1sm30151729wib.1.2012.01.19.13.07.11
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 13:07:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 21:07:05 +0000
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB3E3679.37CC8%keir@xen.org>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW7kvZMwWOW8AXoUSzvl9ZLRtTwQ==
In-Reply-To: <20120119204941.GB3360@andromeda.dapyr.net>
Mime-version: 1.0
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 20:49, "Konrad Rzeszutek Wilk" <konrad@darnok.org> wrote:

> On Thu, Jan 19, 2012 at 12:30:21PM -0800, Andres Lagar-Cavilla wrote:
>> Hi,
>> I had the following painful experience. I declared
>> 
>> struct xen_mem_event_op {
>>     uint8_t       op;           /* XENMEM_*_op_* */
>>     domid_t       domain;
>>     uint64_t buffer;
>>     uint64_t gfn;          /* IN:  gfn of page being operated on */
>> };
>> typedef struct xen_mem_event_op xen_mem_event_op_t;
>> 
>> to be passed as the argument of a memory op called form the toolstack. The
>> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
>> simply:
>> 
>>     xen_mem_event_op_t meo;
>> ... set fields ...
>>     return do_memory_op(xch, mode, &meo, sizeof(meo));
>> 
>> No joy because 32 bits was packing the struct differently than 64 bits.
>> Namely, both were adding a 1 byte pad between 'op' and 'domain', but when
>> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad was
>> thrown between 'domain' and 'buffer'.
>> 
> 
>> The first question is, what is the preferred way around this. Declare pads
>> inside the struct?
> 
> Yes. And also use __attribute(__packed__);

Not used in any public header files.

>> Exploring the include/public/memory.h declarations and toolstack code, I
>> see that no current declare includes __attribute__((aligned)) or
>> __attribute__((packed)), or explicit pads.
> 
> Sometimes they have #pragma(4), which will make the alignment be
> 32-bit (4-bytes) for 64-bit builds as well.

Not in any public header files. It's used in the auto-generated 32-on-64
compat headers, for the hypervisor's private use.

>> So how come things don't break more often for 32 bit toolstacks? pure
>> luck? Am I missing something?
> 
> If you do not use 'memcpy' you can escape some of these misues.

Mainly you just have to be careful.

 -- Keir

>> 
>> Thanks!
>> Andres
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Jan 19 21:07:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:07:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzCd-0006Bo-8B; Thu, 19 Jan 2012 21:07:23 +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 1RnzCb-0006Bj-Gh
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:07:21 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327007234!9898736!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 27604 invoked from network); 19 Jan 2012 21:07:15 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:07:15 -0000
Received: by werb14 with SMTP id b14so397299wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:07: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=eOvcs+kUo1c1Et3F2bmxVZb9wczqAnbDWO6XKoZvJ4c=;
	b=p/BblCxBb4KOW5ozcDyphhjqBJre9Bm7pETFpFUKWonOjlF/RdOkD2sTbNnoY2t6i1
	K4tjpEsGSYrAG6Q2YR0jF6er9uNucwo5Wxq/Jvo/NRqcQV4nmEJUCGfFbtT9RiJmgsZm
	bjQdet6QapW+3MM6VMH3BMnjkdofqLNsiiFpg=
Received: by 10.216.140.223 with SMTP id e73mr1242419wej.54.1327007234828;
	Thu, 19 Jan 2012 13:07:14 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id hv1sm30151729wib.1.2012.01.19.13.07.11
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 13:07:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 21:07:05 +0000
From: Keir Fraser <keir@xen.org>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB3E3679.37CC8%keir@xen.org>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW7kvZMwWOW8AXoUSzvl9ZLRtTwQ==
In-Reply-To: <20120119204941.GB3360@andromeda.dapyr.net>
Mime-version: 1.0
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 20:49, "Konrad Rzeszutek Wilk" <konrad@darnok.org> wrote:

> On Thu, Jan 19, 2012 at 12:30:21PM -0800, Andres Lagar-Cavilla wrote:
>> Hi,
>> I had the following painful experience. I declared
>> 
>> struct xen_mem_event_op {
>>     uint8_t       op;           /* XENMEM_*_op_* */
>>     domid_t       domain;
>>     uint64_t buffer;
>>     uint64_t gfn;          /* IN:  gfn of page being operated on */
>> };
>> typedef struct xen_mem_event_op xen_mem_event_op_t;
>> 
>> to be passed as the argument of a memory op called form the toolstack. The
>> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
>> simply:
>> 
>>     xen_mem_event_op_t meo;
>> ... set fields ...
>>     return do_memory_op(xch, mode, &meo, sizeof(meo));
>> 
>> No joy because 32 bits was packing the struct differently than 64 bits.
>> Namely, both were adding a 1 byte pad between 'op' and 'domain', but when
>> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad was
>> thrown between 'domain' and 'buffer'.
>> 
> 
>> The first question is, what is the preferred way around this. Declare pads
>> inside the struct?
> 
> Yes. And also use __attribute(__packed__);

Not used in any public header files.

>> Exploring the include/public/memory.h declarations and toolstack code, I
>> see that no current declare includes __attribute__((aligned)) or
>> __attribute__((packed)), or explicit pads.
> 
> Sometimes they have #pragma(4), which will make the alignment be
> 32-bit (4-bytes) for 64-bit builds as well.

Not in any public header files. It's used in the auto-generated 32-on-64
compat headers, for the hypervisor's private use.

>> So how come things don't break more often for 32 bit toolstacks? pure
>> luck? Am I missing something?
> 
> If you do not use 'memcpy' you can escape some of these misues.

Mainly you just have to be careful.

 -- Keir

>> 
>> Thanks!
>> Andres
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@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 Jan 19 21:10:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21: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 1RnzFg-0006IT-SR; Thu, 19 Jan 2012 21:10:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnzFf-0006IK-K5
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:10:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327007425!11799067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6131 invoked from network); 19 Jan 2012 21:10:25 -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;
	19 Jan 2012 21:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10162636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:10:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 21:10:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
Organization: Citrix Systems, Inc.
Date: Thu, 19 Jan 2012 21:10:24 +0000
Message-ID: <1327007424.21391.14.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wrote:
> On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> >> 
> >> 
> >> I do have a set of initial patches for xl remus. Since the "script="
> >> support doesnt exist for disk configurations (required to support both
> >> DRBD and tapdisk backends).
> >> 
> >> So, currently I only have memory checkpointing functionality. No disk
> >> buffering.
> >> Will submit it in a day or so.
> >> 
> >> About network buffering:
> >> a.  There is code to install and manipulate the network buffer via
> >> netlink messages. And its in python. While the "xl remus" control flow
> >> starts off from C. Either I implement the C equivalent
> >> of the python code or call the python code from C (this is C->python
> >> and not the other way around). Please correct me if I am wrong.
> > 
> > Wrong about what?
> > 
> > I don't think calling Python from C in libxl is a good idea. Forking a
> > process would be better but best would be to just implement the C
> > version. Is there a libnetlink which can help with this sort of thing?
> > 
> 
> There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)

I meant an existing generic netlink library, not something specific to
the Xen python bindings.

Debian has libnl{1,2,3} pacakges in it -- why not use them? 

There is no reason why this sort of generic library should be in the Xen
tree. (lets be honest, there's no reason why the python bindings to such
a library should be in Xen either)

> Just that it's bit cryptic and the netlink.py module makes things easy.

Calling into python from libxl is not acceptable.

> >> b. The kernel module (sch_plug):  Last I knew, the network
> >> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
> >> the tree moved to 3.0 series, it got axed off.
> > 
> > My understanding was that a competing module with similar/equivalent
> > functionality was the one which eventually made it upstream (I don't
> > know the names). Unfortunately this probably means that Remus needs to
> > switch over to the upstreamed thing.
> > 
> 
> I don't think so. When I submitted the patch for sch_plug to netdev,
> nobody (even the qdisc maintainer) mentioned anything about an
> equivalent module.

I must have been mistaken then. Why is your module not upstream?

> > There is no "Xen Linux tree" like there used to be and we wouldn't want
> > to carry a module which isn't ready for upstream in any case. (Your
> > module wasn't axed, it just wasn't/isn't upstream).
> > 
> >> While I am still, convincing the netdev folks into accepting this
> >> module upstream, I  have a link in the remus wiki, asking people to
> >> download/compile the module. (People do this only after shooting a
> >> couple of "Remus is not working" emails to the mailing list)
> > 
> > You can't detect this at runtime and print an error message? Do you not
> > get ENOSYS or something when you try and use the module?
> 
> I do. And the emails are despite that. 

It sounds like there would be no helping these people.
 
> >> As an alternative, I could pull it into the tools/remus/ folder (just
> >> like the way it used to be before the pvops kernels) and compile it as
> >> part of the tools compilation process. 
> > 
> > The build doesn't include building a kernel any more so I don't think
> > this will work.
> 
> 
> But can we at least include the source, make file and a readme telling
> people to install the required packages needed to compile a module.

We are trying to get out of the business of bundling every bit of
infrastructure which someone happens to want to use with Xen in the Xen
source repository, so, no, I don't think we can/should include the
source to this Linux kernel module in the Xen tree.

You could perhaps add a README or some Remus documentation directing
people to an external tarball with the module in it, but from what you
say above it doesn't sound like that will help very much (and neither
would having that tarball in the tree).

Of course the right solution is to get your module merged upstream.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:10:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21: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 1RnzFg-0006IT-SR; Thu, 19 Jan 2012 21:10:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnzFf-0006IK-K5
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:10:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327007425!11799067!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6131 invoked from network); 19 Jan 2012 21:10:25 -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;
	19 Jan 2012 21:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10162636"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:10:25 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 21:10:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
Organization: Citrix Systems, Inc.
Date: Thu, 19 Jan 2012 21:10:24 +0000
Message-ID: <1327007424.21391.14.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wrote:
> On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> 
> > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> >> 
> >> 
> >> I do have a set of initial patches for xl remus. Since the "script="
> >> support doesnt exist for disk configurations (required to support both
> >> DRBD and tapdisk backends).
> >> 
> >> So, currently I only have memory checkpointing functionality. No disk
> >> buffering.
> >> Will submit it in a day or so.
> >> 
> >> About network buffering:
> >> a.  There is code to install and manipulate the network buffer via
> >> netlink messages. And its in python. While the "xl remus" control flow
> >> starts off from C. Either I implement the C equivalent
> >> of the python code or call the python code from C (this is C->python
> >> and not the other way around). Please correct me if I am wrong.
> > 
> > Wrong about what?
> > 
> > I don't think calling Python from C in libxl is a good idea. Forking a
> > process would be better but best would be to just implement the C
> > version. Is there a libnetlink which can help with this sort of thing?
> > 
> 
> There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)

I meant an existing generic netlink library, not something specific to
the Xen python bindings.

Debian has libnl{1,2,3} pacakges in it -- why not use them? 

There is no reason why this sort of generic library should be in the Xen
tree. (lets be honest, there's no reason why the python bindings to such
a library should be in Xen either)

> Just that it's bit cryptic and the netlink.py module makes things easy.

Calling into python from libxl is not acceptable.

> >> b. The kernel module (sch_plug):  Last I knew, the network
> >> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
> >> the tree moved to 3.0 series, it got axed off.
> > 
> > My understanding was that a competing module with similar/equivalent
> > functionality was the one which eventually made it upstream (I don't
> > know the names). Unfortunately this probably means that Remus needs to
> > switch over to the upstreamed thing.
> > 
> 
> I don't think so. When I submitted the patch for sch_plug to netdev,
> nobody (even the qdisc maintainer) mentioned anything about an
> equivalent module.

I must have been mistaken then. Why is your module not upstream?

> > There is no "Xen Linux tree" like there used to be and we wouldn't want
> > to carry a module which isn't ready for upstream in any case. (Your
> > module wasn't axed, it just wasn't/isn't upstream).
> > 
> >> While I am still, convincing the netdev folks into accepting this
> >> module upstream, I  have a link in the remus wiki, asking people to
> >> download/compile the module. (People do this only after shooting a
> >> couple of "Remus is not working" emails to the mailing list)
> > 
> > You can't detect this at runtime and print an error message? Do you not
> > get ENOSYS or something when you try and use the module?
> 
> I do. And the emails are despite that. 

It sounds like there would be no helping these people.
 
> >> As an alternative, I could pull it into the tools/remus/ folder (just
> >> like the way it used to be before the pvops kernels) and compile it as
> >> part of the tools compilation process. 
> > 
> > The build doesn't include building a kernel any more so I don't think
> > this will work.
> 
> 
> But can we at least include the source, make file and a readme telling
> people to install the required packages needed to compile a module.

We are trying to get out of the business of bundling every bit of
infrastructure which someone happens to want to use with Xen in the Xen
source repository, so, no, I don't think we can/should include the
source to this Linux kernel module in the Xen tree.

You could perhaps add a README or some Remus documentation directing
people to an external tarball with the module in it, but from what you
say above it doesn't sound like that will help very much (and neither
would having that tarball in the tree).

Of course the right solution is to get your module merged upstream.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:12:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzGn-0006N5-80; Thu, 19 Jan 2012 21:11:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnzGl-0006Ml-1h
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:11:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327007492!9265916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18683 invoked from network); 19 Jan 2012 21:11:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:11:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10162655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:11:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 21:11:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
In-Reply-To: <3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
References: <CB3E3263.37CC2%keir@xen.org>
	<3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
Date: Thu, 19 Jan 2012 21:11:31 +0000
Message-ID: <1327007491.21391.15.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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote:
> > On 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> > wrote:
> >
> >> Hi,
> >> I had the following painful experience. I declared
> >>
> >> struct xen_mem_event_op {
> >>     uint8_t       op;           /* XENMEM_*_op_* */
> >>     domid_t       domain;
> >>     uint64_t buffer;
> >>     uint64_t gfn;          /* IN:  gfn of page being operated on */
> >> };
> >> typedef struct xen_mem_event_op xen_mem_event_op_t;
> >>
> >> to be passed as the argument of a memory op called form the toolstack.
> >> The
> >> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
> >> simply:
> >>
> >>     xen_mem_event_op_t meo;
> >> ... set fields ...
> >>     return do_memory_op(xch, mode, &meo, sizeof(meo));
> >>
> >> No joy because 32 bits was packing the struct differently than 64 bits.
> >> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
> >> when
> >> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
> >> was
> >> thrown between 'domain' and 'buffer'.
> >>
> >> The first question is, what is the preferred way around this. Declare
> >> pads
> >> inside the struct?
> >
> > Yes.
> 
> Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
> memory.h

I don't think gcc extensions such as this are allowed in
xen/include/public. You should explicitly pack the struct instead.

Ian.

> 
> Thanks!
> Andres
> 
> >
> >> Exploring the include/public/memory.h declarations and toolstack code, I
> >> see that no current declare includes __attribute__((aligned)) or
> >> __attribute__((packed)), or explicit pads.
> >>
> >> So how come things don't break more often for 32 bit toolstacks? pure
> >> luck? Am I missing something?
> >
> > Where older structs were not 32/64-bit invariant, compat shims were
> > implemented. See common/compat/memory.c, for example. Well worth avoiding
> > that!
> >
> >  -- Keir
> >
> >> Thanks!
> >> Andres
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/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 Jan 19 21:12:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzGn-0006N5-80; Thu, 19 Jan 2012 21:11:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnzGl-0006Ml-1h
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:11:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327007492!9265916!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18683 invoked from network); 19 Jan 2012 21:11:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:11:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10162655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:11:32 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 21:11:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "andres@lagarcavilla.org" <andres@lagarcavilla.org>
In-Reply-To: <3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
References: <CB3E3263.37CC2%keir@xen.org>
	<3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
Organization: Citrix Systems, Inc.
Date: Thu, 19 Jan 2012 21:11:31 +0000
Message-ID: <1327007491.21391.15.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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote:
> > On 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
> > wrote:
> >
> >> Hi,
> >> I had the following painful experience. I declared
> >>
> >> struct xen_mem_event_op {
> >>     uint8_t       op;           /* XENMEM_*_op_* */
> >>     domid_t       domain;
> >>     uint64_t buffer;
> >>     uint64_t gfn;          /* IN:  gfn of page being operated on */
> >> };
> >> typedef struct xen_mem_event_op xen_mem_event_op_t;
> >>
> >> to be passed as the argument of a memory op called form the toolstack.
> >> The
> >> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
> >> simply:
> >>
> >>     xen_mem_event_op_t meo;
> >> ... set fields ...
> >>     return do_memory_op(xch, mode, &meo, sizeof(meo));
> >>
> >> No joy because 32 bits was packing the struct differently than 64 bits.
> >> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
> >> when
> >> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
> >> was
> >> thrown between 'domain' and 'buffer'.
> >>
> >> The first question is, what is the preferred way around this. Declare
> >> pads
> >> inside the struct?
> >
> > Yes.
> 
> Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
> memory.h

I don't think gcc extensions such as this are allowed in
xen/include/public. You should explicitly pack the struct instead.

Ian.

> 
> Thanks!
> Andres
> 
> >
> >> Exploring the include/public/memory.h declarations and toolstack code, I
> >> see that no current declare includes __attribute__((aligned)) or
> >> __attribute__((packed)), or explicit pads.
> >>
> >> So how come things don't break more often for 32 bit toolstacks? pure
> >> luck? Am I missing something?
> >
> > Where older structs were not 32/64-bit invariant, compat shims were
> > implemented. See common/compat/memory.c, for example. Well worth avoiding
> > that!
> >
> >  -- Keir
> >
> >> Thanks!
> >> Andres
> >>
> >>
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@lists.xensource.com
> >> http://lists.xensource.com/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 Jan 19 21:13:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21: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 1RnzHt-0006U5-Tn; Thu, 19 Jan 2012 21:12:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnzHr-0006TE-Rc
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:12:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327007558!9137186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13169 invoked from network); 19 Jan 2012 21:12:38 -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;
	19 Jan 2012 21:12:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10162742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:12: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;
	Thu, 19 Jan 2012 21:12:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CB3E3679.37CC8%keir@xen.org>
References: <CB3E3679.37CC8%keir@xen.org>
Organization: Citrix Systems, Inc.
Date: Thu, 19 Jan 2012 21:12:30 +0000
Message-ID: <1327007550.21391.16.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 21:07 +0000, Keir Fraser wrote:
> > Yes. And also use __attribute(__packed__);
> 
> Not used in any public header files.

One seems to have crept into xen/include/public/arch-x86/hvm/save.h :-(

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:13:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21: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 1RnzHt-0006U5-Tn; Thu, 19 Jan 2012 21:12:49 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnzHr-0006TE-Rc
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:12:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327007558!9137186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13169 invoked from network); 19 Jan 2012 21:12:38 -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;
	19 Jan 2012 21:12:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="10162742"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:12: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;
	Thu, 19 Jan 2012 21:12:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CB3E3679.37CC8%keir@xen.org>
References: <CB3E3679.37CC8%keir@xen.org>
Organization: Citrix Systems, Inc.
Date: Thu, 19 Jan 2012 21:12:30 +0000
Message-ID: <1327007550.21391.16.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 21:07 +0000, Keir Fraser wrote:
> > Yes. And also use __attribute(__packed__);
> 
> Not used in any public header files.

One seems to have crept into xen/include/public/arch-x86/hvm/save.h :-(

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:14:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzJg-0006eT-JF; Thu, 19 Jan 2012 21:14:40 +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 1RnzJf-0006e9-IC
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:14:39 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327007673!11628213!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTcwODA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31405 invoked from network); 19 Jan 2012 21:14:33 -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; 19 Jan 2012 21:14:33 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id A4E1C21A2;
	Thu, 19 Jan 2012 23:14:30 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 756AB200B0; Thu, 19 Jan 2012 23:14:30 +0200 (EET)
Date: Thu, 19 Jan 2012 23:14:30 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120119211430.GT12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa
	memory	allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> 
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?
> 

Something that I just remembered:
http://wiki.xen.org/xenwiki/Xen4.1

"NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate equal amount of memory from every NUMA node for the VM. xm/xend allocates all the memory from the same NUMA node."

Is this something that should be looked at? Should the numa memory allocation be an option so it can be controlled per domain? 
The default libxl behaviour might cause unexpected performance issues on multi-socket systems? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:14:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:14:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzJg-0006eT-JF; Thu, 19 Jan 2012 21:14:40 +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 1RnzJf-0006e9-IC
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:14:39 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327007673!11628213!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MTcwODA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31405 invoked from network); 19 Jan 2012 21:14:33 -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; 19 Jan 2012 21:14:33 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id A4E1C21A2;
	Thu, 19 Jan 2012 23:14:30 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 756AB200B0; Thu, 19 Jan 2012 23:14:30 +0200 (EET)
Date: Thu, 19 Jan 2012 23:14:30 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120119211430.GT12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa
	memory	allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> 
> Has anybody got anything else? I'm sure I've missed stuff. Are there any
> must haves e.g. in the paging/sharing spaces?
> 

Something that I just remembered:
http://wiki.xen.org/xenwiki/Xen4.1

"NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate equal amount of memory from every NUMA node for the VM. xm/xend allocates all the memory from the same NUMA node."

Is this something that should be looked at? Should the numa memory allocation be an option so it can be controlled per domain? 
The default libxl behaviour might cause unexpected performance issues on multi-socket systems? 

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:21:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzQ2-0007F6-EN; Thu, 19 Jan 2012 21:21:14 +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 1RnzQ1-0007Ex-Bf
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:21:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327008066!9899781!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMTQy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMTQy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20182 invoked from network); 19 Jan 2012 21:21:06 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.81) by server-5.tower-174.messagelabs.com with SMTP;
	19 Jan 2012 21:21:06 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 7FD5776C072;
	Thu, 19 Jan 2012 13:21: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=Mf+RkITuFcySL1aXqTBn0lzXkLx1ZihgIITL4O99PAl1
	FVPWo4CYavrwiTvU/dyKKH6S5+V8mZrjbcvKyoBeBHHXq6rbZELwJNf8Jicmg6sK
	Vlw1W6Eyz0weziuHA2sMP9+2GRhoMtyHmz8+hmmwtQO7iDh6xxdVkL8gZ7yRJ30=
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=pzAlmue8d7Jc31FpYB7bI1Bed9Q=; b=rZHeP9am
	aMlMDAgxUC6kpxypPfVSO6D75ZgdgjrkR6z10cdm3hZGcho+VgdA/f9lmgtiVJTg
	EKt0d04GdtTY1+LOW9Hds0IA337noDBBmBk8gi3lSMswnZOsXThQaSev6dhfBUZi
	oby+BkRnLO4rRVicTUu7EtIE3mKXdFn6iUg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 0574676C06E; 
	Thu, 19 Jan 2012 13:21:05 -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, 19 Jan 2012 13:21:05 -0800
Message-ID: <d545b5925bcd7b1cbe62c371d2f68d8f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1327007491.21391.15.camel@dagon.hellion.org.uk>
References: <CB3E3263.37CC2%keir@xen.org>
	<3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
	<1327007491.21391.15.camel@dagon.hellion.org.uk>
Date: Thu, 19 Jan 2012 13:21:05 -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: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote:
>> > On 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>> > wrote:
>> >
>> >> Hi,
>> >> I had the following painful experience. I declared
>> >>
>> >> struct xen_mem_event_op {
>> >>     uint8_t       op;           /* XENMEM_*_op_* */
>> >>     domid_t       domain;
>> >>     uint64_t buffer;
>> >>     uint64_t gfn;          /* IN:  gfn of page being operated on */
>> >> };
>> >> typedef struct xen_mem_event_op xen_mem_event_op_t;
>> >>
>> >> to be passed as the argument of a memory op called form the
>> toolstack.
>> >> The
>> >> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
>> >> simply:
>> >>
>> >>     xen_mem_event_op_t meo;
>> >> ... set fields ...
>> >>     return do_memory_op(xch, mode, &meo, sizeof(meo));
>> >>
>> >> No joy because 32 bits was packing the struct differently than 64
>> bits.
>> >> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
>> >> when
>> >> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
>> >> was
>> >> thrown between 'domain' and 'buffer'.
>> >>
>> >> The first question is, what is the preferred way around this. Declare
>> >> pads
>> >> inside the struct?
>> >
>> > Yes.
>>
>> Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
>> memory.h
>
> I don't think gcc extensions such as this are allowed in
> xen/include/public. You should explicitly pack the struct instead.

Ok, I'll back off on 'packed'. It makes me uneasy though not being able to
control the layout exactly.

Thanks,
Andres
>
> Ian.
>
>>
>> Thanks!
>> Andres
>>
>> >
>> >> Exploring the include/public/memory.h declarations and toolstack
>> code, I
>> >> see that no current declare includes __attribute__((aligned)) or
>> >> __attribute__((packed)), or explicit pads.
>> >>
>> >> So how come things don't break more often for 32 bit toolstacks? pure
>> >> luck? Am I missing something?
>> >
>> > Where older structs were not 32/64-bit invariant, compat shims were
>> > implemented. See common/compat/memory.c, for example. Well worth
>> avoiding
>> > that!
>> >
>> >  -- Keir
>> >
>> >> Thanks!
>> >> Andres
>> >>
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/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 Jan 19 21:21:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:21:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzQ2-0007F6-EN; Thu, 19 Jan 2012 21:21:14 +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 1RnzQ1-0007Ex-Bf
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:21:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327008066!9899781!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMTQy\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMTQy\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20182 invoked from network); 19 Jan 2012 21:21:06 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.81) by server-5.tower-174.messagelabs.com with SMTP;
	19 Jan 2012 21:21:06 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 7FD5776C072;
	Thu, 19 Jan 2012 13:21: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=Mf+RkITuFcySL1aXqTBn0lzXkLx1ZihgIITL4O99PAl1
	FVPWo4CYavrwiTvU/dyKKH6S5+V8mZrjbcvKyoBeBHHXq6rbZELwJNf8Jicmg6sK
	Vlw1W6Eyz0weziuHA2sMP9+2GRhoMtyHmz8+hmmwtQO7iDh6xxdVkL8gZ7yRJ30=
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=pzAlmue8d7Jc31FpYB7bI1Bed9Q=; b=rZHeP9am
	aMlMDAgxUC6kpxypPfVSO6D75ZgdgjrkR6z10cdm3hZGcho+VgdA/f9lmgtiVJTg
	EKt0d04GdtTY1+LOW9Hds0IA337noDBBmBk8gi3lSMswnZOsXThQaSev6dhfBUZi
	oby+BkRnLO4rRVicTUu7EtIE3mKXdFn6iUg=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 0574676C06E; 
	Thu, 19 Jan 2012 13:21:05 -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, 19 Jan 2012 13:21:05 -0800
Message-ID: <d545b5925bcd7b1cbe62c371d2f68d8f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1327007491.21391.15.camel@dagon.hellion.org.uk>
References: <CB3E3263.37CC2%keir@xen.org>
	<3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
	<1327007491.21391.15.camel@dagon.hellion.org.uk>
Date: Thu, 19 Jan 2012 13:21:05 -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: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote:
>> > On 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>> > wrote:
>> >
>> >> Hi,
>> >> I had the following painful experience. I declared
>> >>
>> >> struct xen_mem_event_op {
>> >>     uint8_t       op;           /* XENMEM_*_op_* */
>> >>     domid_t       domain;
>> >>     uint64_t buffer;
>> >>     uint64_t gfn;          /* IN:  gfn of page being operated on */
>> >> };
>> >> typedef struct xen_mem_event_op xen_mem_event_op_t;
>> >>
>> >> to be passed as the argument of a memory op called form the
>> toolstack.
>> >> The
>> >> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
>> >> simply:
>> >>
>> >>     xen_mem_event_op_t meo;
>> >> ... set fields ...
>> >>     return do_memory_op(xch, mode, &meo, sizeof(meo));
>> >>
>> >> No joy because 32 bits was packing the struct differently than 64
>> bits.
>> >> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
>> >> when
>> >> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
>> >> was
>> >> thrown between 'domain' and 'buffer'.
>> >>
>> >> The first question is, what is the preferred way around this. Declare
>> >> pads
>> >> inside the struct?
>> >
>> > Yes.
>>
>> Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
>> memory.h
>
> I don't think gcc extensions such as this are allowed in
> xen/include/public. You should explicitly pack the struct instead.

Ok, I'll back off on 'packed'. It makes me uneasy though not being able to
control the layout exactly.

Thanks,
Andres
>
> Ian.
>
>>
>> Thanks!
>> Andres
>>
>> >
>> >> Exploring the include/public/memory.h declarations and toolstack
>> code, I
>> >> see that no current declare includes __attribute__((aligned)) or
>> >> __attribute__((packed)), or explicit pads.
>> >>
>> >> So how come things don't break more often for 32 bit toolstacks? pure
>> >> luck? Am I missing something?
>> >
>> > Where older structs were not 32/64-bit invariant, compat shims were
>> > implemented. See common/compat/memory.c, for example. Well worth
>> avoiding
>> > that!
>> >
>> >  -- Keir
>> >
>> >> Thanks!
>> >> Andres
>> >>
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/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 Jan 19 21:24:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzSj-0007Mz-7C; Thu, 19 Jan 2012 21:24: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 1RnzSg-0007Mo-Lv
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:23:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327008231!9872936!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk5MDk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30509 invoked from network); 19 Jan 2012 21:23:51 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-174.messagelabs.com with SMTP;
	19 Jan 2012 21:23:51 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 75413604079;
	Thu, 19 Jan 2012 13:23:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=BL2mBKEYmKcJKK69hw/rRonR+/ARDiPtLNRqhn6m/gv6
	CjqHr9/s3tnjoIMJykJKPTrHWx9hdU/BW1632qP1WZENN8v0+7uBg1juplvPUsw6
	XW1P0O3ma5YS9l8XJ7I1GXJxc5Gqc72Nks/MeIYuCls8yEILciMUZ7/+yupuqHM=
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=fVMU5eHVKvihrM2+i2yf2NvpdO4=; b=sFvZwGaY
	ew5WDoCT/NAyF0QJVN6tgF6+VYBW2+JtcamT86EX4oz4Aa5lMID5xFnC2bhonDON
	bt2fiK2cVw/qXKbR7CclfQQdj0UrRy2ptvUetfQtnDhxUHyXPWKwZBQ/6tgPu39P
	Jbj31mB/tzqQnbdEn1CWmxIUKVkvM1iaxw0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id AF49E60405D; 
	Thu, 19 Jan 2012 13:23:48 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 13:23:50 -0800
Message-ID: <f46a8328cddbf3a18195159cbd0a0955.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1327007491.21391.15.camel@dagon.hellion.org.uk>
References: <CB3E3263.37CC2%keir@xen.org>
	<3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
	<1327007491.21391.15.camel@dagon.hellion.org.uk>
Date: Thu, 19 Jan 2012 13:23:50 -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: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote:
>> > On 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>> > wrote:
>> >
>> >> Hi,
>> >> I had the following painful experience. I declared
>> >>
>> >> struct xen_mem_event_op {
>> >>     uint8_t       op;           /* XENMEM_*_op_* */
>> >>     domid_t       domain;
>> >>     uint64_t buffer;
>> >>     uint64_t gfn;          /* IN:  gfn of page being operated on */
>> >> };
>> >> typedef struct xen_mem_event_op xen_mem_event_op_t;
>> >>
>> >> to be passed as the argument of a memory op called form the
>> toolstack.
>> >> The
>> >> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
>> >> simply:
>> >>
>> >>     xen_mem_event_op_t meo;
>> >> ... set fields ...
>> >>     return do_memory_op(xch, mode, &meo, sizeof(meo));
>> >>
>> >> No joy because 32 bits was packing the struct differently than 64
>> bits.
>> >> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
>> >> when
>> >> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
>> >> was
>> >> thrown between 'domain' and 'buffer'.
>> >>
>> >> The first question is, what is the preferred way around this. Declare
>> >> pads
>> >> inside the struct?
>> >
>> > Yes.
>>
>> Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
>> memory.h
>
> I don't think gcc extensions such as this are allowed in
> xen/include/public. You should explicitly pack the struct instead.

domctl.h is in a way spared, because __attribute__((aligned(8))) is
allowed in 32 bits. And the header is spared the ansi test.

Is there a rationale to allowing this ABI file do 'aligned', but
preventing that other header file from using it?

I'm thinking uint64_aligned_t would solve my problem in memory.h.

Andres

>
> Ian.
>
>>
>> Thanks!
>> Andres
>>
>> >
>> >> Exploring the include/public/memory.h declarations and toolstack
>> code, I
>> >> see that no current declare includes __attribute__((aligned)) or
>> >> __attribute__((packed)), or explicit pads.
>> >>
>> >> So how come things don't break more often for 32 bit toolstacks? pure
>> >> luck? Am I missing something?
>> >
>> > Where older structs were not 32/64-bit invariant, compat shims were
>> > implemented. See common/compat/memory.c, for example. Well worth
>> avoiding
>> > that!
>> >
>> >  -- Keir
>> >
>> >> Thanks!
>> >> Andres
>> >>
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/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 Jan 19 21:24:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:24:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzSj-0007Mz-7C; Thu, 19 Jan 2012 21:24: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 1RnzSg-0007Mo-Lv
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:23:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327008231!9872936!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk5MDk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30509 invoked from network); 19 Jan 2012 21:23:51 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-174.messagelabs.com with SMTP;
	19 Jan 2012 21:23:51 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 75413604079;
	Thu, 19 Jan 2012 13:23:50 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=BL2mBKEYmKcJKK69hw/rRonR+/ARDiPtLNRqhn6m/gv6
	CjqHr9/s3tnjoIMJykJKPTrHWx9hdU/BW1632qP1WZENN8v0+7uBg1juplvPUsw6
	XW1P0O3ma5YS9l8XJ7I1GXJxc5Gqc72Nks/MeIYuCls8yEILciMUZ7/+yupuqHM=
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=fVMU5eHVKvihrM2+i2yf2NvpdO4=; b=sFvZwGaY
	ew5WDoCT/NAyF0QJVN6tgF6+VYBW2+JtcamT86EX4oz4Aa5lMID5xFnC2bhonDON
	bt2fiK2cVw/qXKbR7CclfQQdj0UrRy2ptvUetfQtnDhxUHyXPWKwZBQ/6tgPu39P
	Jbj31mB/tzqQnbdEn1CWmxIUKVkvM1iaxw0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id AF49E60405D; 
	Thu, 19 Jan 2012 13:23:48 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 13:23:50 -0800
Message-ID: <f46a8328cddbf3a18195159cbd0a0955.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <1327007491.21391.15.camel@dagon.hellion.org.uk>
References: <CB3E3263.37CC2%keir@xen.org>
	<3e4c46a531a37b348333e114ff6f775f.squirrel@webmail.lagarcavilla.org>
	<1327007491.21391.15.camel@dagon.hellion.org.uk>
Date: Thu, 19 Jan 2012 13:23:50 -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: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Thu, 2012-01-19 at 20:57 +0000, Andres Lagar-Cavilla wrote:
>> > On 19/01/2012 20:30, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>> > wrote:
>> >
>> >> Hi,
>> >> I had the following painful experience. I declared
>> >>
>> >> struct xen_mem_event_op {
>> >>     uint8_t       op;           /* XENMEM_*_op_* */
>> >>     domid_t       domain;
>> >>     uint64_t buffer;
>> >>     uint64_t gfn;          /* IN:  gfn of page being operated on */
>> >> };
>> >> typedef struct xen_mem_event_op xen_mem_event_op_t;
>> >>
>> >> to be passed as the argument of a memory op called form the
>> toolstack.
>> >> The
>> >> hypervisor is 64 bits and the toolstack is 32 bits. My toolstack code
>> >> simply:
>> >>
>> >>     xen_mem_event_op_t meo;
>> >> ... set fields ...
>> >>     return do_memory_op(xch, mode, &meo, sizeof(meo));
>> >>
>> >> No joy because 32 bits was packing the struct differently than 64
>> bits.
>> >> Namely, both were adding a 1 byte pad between 'op' and 'domain', but
>> >> when
>> >> compiled in 64 bits mode for the hypervisor, an additional 4 byte pad
>> >> was
>> >> thrown between 'domain' and 'buffer'.
>> >>
>> >> The first question is, what is the preferred way around this. Declare
>> >> pads
>> >> inside the struct?
>> >
>> > Yes.
>>
>> Ok. And as Konrad says, I'll add __attribute__((packed)). A first for
>> memory.h
>
> I don't think gcc extensions such as this are allowed in
> xen/include/public. You should explicitly pack the struct instead.

domctl.h is in a way spared, because __attribute__((aligned(8))) is
allowed in 32 bits. And the header is spared the ansi test.

Is there a rationale to allowing this ABI file do 'aligned', but
preventing that other header file from using it?

I'm thinking uint64_aligned_t would solve my problem in memory.h.

Andres

>
> Ian.
>
>>
>> Thanks!
>> Andres
>>
>> >
>> >> Exploring the include/public/memory.h declarations and toolstack
>> code, I
>> >> see that no current declare includes __attribute__((aligned)) or
>> >> __attribute__((packed)), or explicit pads.
>> >>
>> >> So how come things don't break more often for 32 bit toolstacks? pure
>> >> luck? Am I missing something?
>> >
>> > Where older structs were not 32/64-bit invariant, compat shims were
>> > implemented. See common/compat/memory.c, for example. Well worth
>> avoiding
>> > that!
>> >
>> >  -- Keir
>> >
>> >> Thanks!
>> >> Andres
>> >>
>> >>
>> >> _______________________________________________
>> >> Xen-devel mailing list
>> >> Xen-devel@lists.xensource.com
>> >> http://lists.xensource.com/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 Jan 19 21:27:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:27:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzVS-0007aI-FE; Thu, 19 Jan 2012 21:26:50 +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 1RnzVQ-0007ZP-80
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:26:48 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327008399!11614252!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28352 invoked from network); 19 Jan 2012 21:26:41 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jan 2012 21:26:41 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0JLQbDx019109
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 19 Jan 2012 13:26:38 -0800
Received: by bkat2 with SMTP id t2so897606bka.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:26:35 -0800 (PST)
Received: by 10.204.152.20 with SMTP id e20mr10528618bkw.117.1327008395367;
	Thu, 19 Jan 2012 13:26:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Thu, 19 Jan 2012 13:25:54 -0800 (PST)
In-Reply-To: <20120119204227.GA3360@andromeda.dapyr.net>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
	<20120119204227.GA3360@andromeda.dapyr.net>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 13:25:54 -0800
Message-ID: <CAP8mzPPrD3sbLEyr5dBrPUxF+5NQWJfuLJW6T23i_guMBiuWcg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
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="===============0150182212159477303=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0150182212159477303==
Content-Type: multipart/alternative; boundary=0015175df06e05165d04b6e83845

--0015175df06e05165d04b6e83845
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 19, 2012 at 12:42 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org>wrote:

> On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagopalan wrote:
> > On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> > >>
> > >>
> > >> I do have a set of initial patches for xl remus. Since the "script="
> > >> support doesnt exist for disk configurations (required to support both
> > >> DRBD and tapdisk backends).
> > >>
> > >> So, currently I only have memory checkpointing functionality. No disk
> > >> buffering.
>
> Were the disk buffering implemented in kernel? As a dm-* device or
> through blktap (which is not maintained)?
>
>
Blktap2 - userspace (block-remus.c driver). It just needs a hostname and
port
number to replicate disk writes to. The main remus control loop
communicates with it
via fifos.

DRBD - kernel module (separate source tree. not the mainline one). And
remus communicates
with it via ioctls (so easy in libxl).

The current xl disk specs dont support the script format or such
extensions, though which
such parameters could be accepted and supplied to the tapdisk2 module
(which in turn
loads block-remus driver).

The DRBD backend is also simple. The block-drbd script (in etc/xen/scripts)
does all the drbd vodoo stuff
of setting up the drbd resources.

In the worst case, one could simply use tap2:/dev/drbd1 (where /dev/drbd1
is the device exported
by drbd) and in the libxl code, i could strncmp(disk_name,"/dev/drbd",9)
and enable the disk buffering,
leaving the responsibility of manually setting up drbd to the user.

--0015175df06e05165d04b6e83845
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jan 19, 2012 at 12:42 PM, Konrad Rzeszut=
ek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@darnok.org">konrad@d=
arnok.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagop=
alan wrote:<br>
&gt; On 2012-01-19, at 9:46 AM, Ian Campbell &lt;<a href=3D"mailto:Ian.Camp=
bell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I do have a set of initial patches for xl remus. Since the &q=
uot;script=3D&quot;<br>
&gt; &gt;&gt; support doesnt exist for disk configurations (required to sup=
port both<br>
&gt; &gt;&gt; DRBD and tapdisk backends).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; So, currently I only have memory checkpointing functionality.=
 No disk<br>
&gt; &gt;&gt; buffering.<br>
<br>
</div>Were the disk buffering implemented in kernel? As a dm-* device or<br=
>
through blktap (which is not maintained)?<br>
<br></blockquote><div><br>Blktap2 - userspace (block-remus.c driver). It ju=
st needs a hostname and port<br>number to replicate disk writes to. The mai=
n remus control loop communicates with it<br>via fifos.<br><br>DRBD - kerne=
l module (separate source tree. not the mainline one). And remus communicat=
es<br>

with it via ioctls (so easy in libxl).<br><br>The current xl disk specs don=
t support the script format or such extensions, though which <br>such param=
eters could be accepted and supplied to the tapdisk2 module (which in turn<=
br>

loads block-remus driver).<br><br></div></div>The DRBD backend is also simp=
le. The block-drbd script (in etc/xen/scripts) does all the drbd vodoo stuf=
f<br>of setting up the drbd resources.<br><br>In the worst case, one could =
simply use tap2:/dev/drbd1 (where /dev/drbd1 is the device exported<br>

by drbd) and in the libxl code, i could strncmp(disk_name,&quot;/dev/drbd&q=
uot;,9) and enable the disk buffering,<br>leaving the responsibility of man=
ually setting up drbd to the user.<br><br>

--0015175df06e05165d04b6e83845--


--===============0150182212159477303==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0150182212159477303==--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:27:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:27:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzVS-0007aI-FE; Thu, 19 Jan 2012 21:26:50 +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 1RnzVQ-0007ZP-80
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:26:48 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327008399!11614252!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28352 invoked from network); 19 Jan 2012 21:26:41 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jan 2012 21:26:41 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0JLQbDx019109
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 19 Jan 2012 13:26:38 -0800
Received: by bkat2 with SMTP id t2so897606bka.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:26:35 -0800 (PST)
Received: by 10.204.152.20 with SMTP id e20mr10528618bkw.117.1327008395367;
	Thu, 19 Jan 2012 13:26:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Thu, 19 Jan 2012 13:25:54 -0800 (PST)
In-Reply-To: <20120119204227.GA3360@andromeda.dapyr.net>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
	<20120119204227.GA3360@andromeda.dapyr.net>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 13:25:54 -0800
Message-ID: <CAP8mzPPrD3sbLEyr5dBrPUxF+5NQWJfuLJW6T23i_guMBiuWcg@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
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="===============0150182212159477303=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0150182212159477303==
Content-Type: multipart/alternative; boundary=0015175df06e05165d04b6e83845

--0015175df06e05165d04b6e83845
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 19, 2012 at 12:42 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org>wrote:

> On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagopalan wrote:
> > On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> > >>
> > >>
> > >> I do have a set of initial patches for xl remus. Since the "script="
> > >> support doesnt exist for disk configurations (required to support both
> > >> DRBD and tapdisk backends).
> > >>
> > >> So, currently I only have memory checkpointing functionality. No disk
> > >> buffering.
>
> Were the disk buffering implemented in kernel? As a dm-* device or
> through blktap (which is not maintained)?
>
>
Blktap2 - userspace (block-remus.c driver). It just needs a hostname and
port
number to replicate disk writes to. The main remus control loop
communicates with it
via fifos.

DRBD - kernel module (separate source tree. not the mainline one). And
remus communicates
with it via ioctls (so easy in libxl).

The current xl disk specs dont support the script format or such
extensions, though which
such parameters could be accepted and supplied to the tapdisk2 module
(which in turn
loads block-remus driver).

The DRBD backend is also simple. The block-drbd script (in etc/xen/scripts)
does all the drbd vodoo stuff
of setting up the drbd resources.

In the worst case, one could simply use tap2:/dev/drbd1 (where /dev/drbd1
is the device exported
by drbd) and in the libxl code, i could strncmp(disk_name,"/dev/drbd",9)
and enable the disk buffering,
leaving the responsibility of manually setting up drbd to the user.

--0015175df06e05165d04b6e83845
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jan 19, 2012 at 12:42 PM, Konrad Rzeszut=
ek Wilk <span dir=3D"ltr">&lt;<a href=3D"mailto:konrad@darnok.org">konrad@d=
arnok.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Thu, Jan 19, 2012 at 11:00:19AM -0800, Shriram Rajagop=
alan wrote:<br>
&gt; On 2012-01-19, at 9:46 AM, Ian Campbell &lt;<a href=3D"mailto:Ian.Camp=
bell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I do have a set of initial patches for xl remus. Since the &q=
uot;script=3D&quot;<br>
&gt; &gt;&gt; support doesnt exist for disk configurations (required to sup=
port both<br>
&gt; &gt;&gt; DRBD and tapdisk backends).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; So, currently I only have memory checkpointing functionality.=
 No disk<br>
&gt; &gt;&gt; buffering.<br>
<br>
</div>Were the disk buffering implemented in kernel? As a dm-* device or<br=
>
through blktap (which is not maintained)?<br>
<br></blockquote><div><br>Blktap2 - userspace (block-remus.c driver). It ju=
st needs a hostname and port<br>number to replicate disk writes to. The mai=
n remus control loop communicates with it<br>via fifos.<br><br>DRBD - kerne=
l module (separate source tree. not the mainline one). And remus communicat=
es<br>

with it via ioctls (so easy in libxl).<br><br>The current xl disk specs don=
t support the script format or such extensions, though which <br>such param=
eters could be accepted and supplied to the tapdisk2 module (which in turn<=
br>

loads block-remus driver).<br><br></div></div>The DRBD backend is also simp=
le. The block-drbd script (in etc/xen/scripts) does all the drbd vodoo stuf=
f<br>of setting up the drbd resources.<br><br>In the worst case, one could =
simply use tap2:/dev/drbd1 (where /dev/drbd1 is the device exported<br>

by drbd) and in the libxl code, i could strncmp(disk_name,&quot;/dev/drbd&q=
uot;,9) and enable the disk buffering,<br>leaving the responsibility of man=
ually setting up drbd to the user.<br><br>

--0015175df06e05165d04b6e83845--


--===============0150182212159477303==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0150182212159477303==--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:31:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzZw-0007xP-6c; Thu, 19 Jan 2012 21:31:28 +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 1RnzZv-0007xK-9X
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:31:27 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327008616!61728276!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7418 invoked from network); 19 Jan 2012 21:30:18 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jan 2012 21:30:18 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0JLVKpt019930
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 19 Jan 2012 13:31:21 -0800
Received: by bkat2 with SMTP id t2so908180bka.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:31:19 -0800 (PST)
Received: by 10.204.152.20 with SMTP id e20mr10533557bkw.117.1327008679357;
	Thu, 19 Jan 2012 13:31:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Thu, 19 Jan 2012 13:30:38 -0800 (PST)
In-Reply-To: <1327007424.21391.14.camel@dagon.hellion.org.uk>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
	<1327007424.21391.14.camel@dagon.hellion.org.uk>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 13:30:38 -0800
Message-ID: <CAP8mzPNVJ32ypc65qVXBbkVFzXnEgfohYqj4S=zR_D-Y6BZLdw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============1881314970563125132=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1881314970563125132==
Content-Type: multipart/alternative; boundary=0015175df06ef26e1704b6e8480e

--0015175df06ef26e1704b6e8480e
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wrote:
> > On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> > >>
> > >>
> > >> I do have a set of initial patches for xl remus. Since the "script="
> > >> support doesnt exist for disk configurations (required to support both
> > >> DRBD and tapdisk backends).
> > >>
> > >> So, currently I only have memory checkpointing functionality. No disk
> > >> buffering.
> > >> Will submit it in a day or so.
> > >>
> > >> About network buffering:
> > >> a.  There is code to install and manipulate the network buffer via
> > >> netlink messages. And its in python. While the "xl remus" control flow
> > >> starts off from C. Either I implement the C equivalent
> > >> of the python code or call the python code from C (this is C->python
> > >> and not the other way around). Please correct me if I am wrong.
> > >
> > > Wrong about what?
> > >
> > > I don't think calling Python from C in libxl is a good idea. Forking a
> > > process would be better but best would be to just implement the C
> > > version. Is there a libnetlink which can help with this sort of thing?
> > >
> >
> > There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)
>
> I meant an existing generic netlink library, not something specific to
> the Xen python bindings.
>
> Debian has libnl{1,2,3} pacakges in it -- why not use them?
>
>
Yes I know. I have toyed with them. The qdisc names are hardcoded in their
libraries.
So, even if one installs sch_plug (qdisc name "plug"), the library wont
recognize it!
I do have my own version of the library (patched) but as you said, I dont
want to
bundle that stuff with xen.

There is no reason why this sort of generic library should be in the Xen
> tree. (lets be honest, there's no reason why the python bindings to such
> a library should be in Xen either)
>
> Just that it's bit cryptic and the netlink.py module makes things easy.
>
> Calling into python from libxl is not acceptable.
>
>
I understand. I wouldnt have done it either :)

 > >> b. The kernel module (sch_plug):  Last I knew, the network
> > >> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
> > >> the tree moved to 3.0 series, it got axed off.
> > >
> > > My understanding was that a competing module with similar/equivalent
> > > functionality was the one which eventually made it upstream (I don't
> > > know the names). Unfortunately this probably means that Remus needs to
> > > switch over to the upstreamed thing.
> > >
> >
> > I don't think so. When I submitted the patch for sch_plug to netdev,
> > nobody (even the qdisc maintainer) mentioned anything about an
> > equivalent module.
>
> I must have been mistaken then. Why is your module not upstream?
>
>
Beats me.


> > > There is no "Xen Linux tree" like there used to be and we wouldn't want
> > > to carry a module which isn't ready for upstream in any case. (Your
> > > module wasn't axed, it just wasn't/isn't upstream).
> > >
> > >> While I am still, convincing the netdev folks into accepting this
> > >> module upstream, I  have a link in the remus wiki, asking people to
> > >> download/compile the module. (People do this only after shooting a
> > >> couple of "Remus is not working" emails to the mailing list)
> > >
> > > You can't detect this at runtime and print an error message? Do you not
> > > get ENOSYS or something when you try and use the module?
> >
> > I do. And the emails are despite that.
>
> It sounds like there would be no helping these people.
>
> > >> As an alternative, I could pull it into the tools/remus/ folder (just
> > >> like the way it used to be before the pvops kernels) and compile it as
> > >> part of the tools compilation process.
> > >
> > > The build doesn't include building a kernel any more so I don't think
> > > this will work.
> >
> >
> > But can we at least include the source, make file and a readme telling
> > people to install the required packages needed to compile a module.
>
> We are trying to get out of the business of bundling every bit of
> infrastructure which someone happens to want to use with Xen in the Xen
> source repository, so, no, I don't think we can/should include the
> source to this Linux kernel module in the Xen tree.
>
> You could perhaps add a README or some Remus documentation directing
> people to an external tarball with the module in it, but from what you
> say above it doesn't sound like that will help very much (and neither
> would having that tarball in the tree).
>
> Of course the right solution is to get your module merged upstream.
>
> Ian.
>
>

--0015175df06ef26e1704b6e8480e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wr=
ote:<br>
&gt; On 2012-01-19, at 9:46 AM, Ian Campbell &lt;<a href=3D"mailto:Ian.Camp=
bell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I do have a set of initial patches for xl remus. Since the &q=
uot;script=3D&quot;<br>
&gt; &gt;&gt; support doesnt exist for disk configurations (required to sup=
port both<br>
&gt; &gt;&gt; DRBD and tapdisk backends).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; So, currently I only have memory checkpointing functionality.=
 No disk<br>
&gt; &gt;&gt; buffering.<br>
&gt; &gt;&gt; Will submit it in a day or so.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; About network buffering:<br>
&gt; &gt;&gt; a. =A0There is code to install and manipulate the network buf=
fer via<br>
&gt; &gt;&gt; netlink messages. And its in python. While the &quot;xl remus=
&quot; control flow<br>
&gt; &gt;&gt; starts off from C. Either I implement the C equivalent<br>
&gt; &gt;&gt; of the python code or call the python code from C (this is C-=
&gt;python<br>
&gt; &gt;&gt; and not the other way around). Please correct me if I am wron=
g.<br>
&gt; &gt;<br>
&gt; &gt; Wrong about what?<br>
&gt; &gt;<br>
&gt; &gt; I don&#39;t think calling Python from C in libxl is a good idea. =
Forking a<br>
&gt; &gt; process would be better but best would be to just implement the C=
<br>
&gt; &gt; version. Is there a libnetlink which can help with this sort of t=
hing?<br>
&gt; &gt;<br>
&gt;<br>
&gt; There is. And it&#39;s in the tools tree (tools/python/xen/lowlevel/ne=
tlink/)<br>
<br>
</div>I meant an existing generic netlink library, not something specific t=
o<br>
the Xen python bindings.<br>
<br>
Debian has libnl{1,2,3} pacakges in it -- why not use them?<br>
<br></blockquote><div><br>Yes I know. I have toyed with them. The qdisc nam=
es are hardcoded in their libraries.<br>So, even if one installs sch_plug (=
qdisc name &quot;plug&quot;), the library wont recognize it!<br>I do have m=
y own version of the library (patched) but as you said, I dont want to<br>

bundle that stuff with xen.<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
There is no reason why this sort of generic library should be in the Xen<br=
>
tree. (lets be honest, there&#39;s no reason why the python bindings to suc=
h<br>
a library should be in Xen either)<br></blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div class=3D"im">
&gt; Just that it&#39;s bit cryptic and the netlink.py module makes things =
easy.<br>
<br>
</div>Calling into python from libxl is not acceptable.<br>
<div class=3D"im"><br></div></blockquote><div>=A0</div><div>I understand. I=
 wouldnt have done it either :)<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">

<div class=3D"im">
&gt; &gt;&gt; b. The kernel module (sch_plug): =A0Last I knew, the network<=
br>
&gt; &gt;&gt; buffering module (sch_plug) was in the pvops tree (2.6.* seri=
es). When<br>
&gt; &gt;&gt; the tree moved to 3.0 series, it got axed off.<br>
&gt; &gt;<br>
&gt; &gt; My understanding was that a competing module with similar/equival=
ent<br>
&gt; &gt; functionality was the one which eventually made it upstream (I do=
n&#39;t<br>
&gt; &gt; know the names). Unfortunately this probably means that Remus nee=
ds to<br>
&gt; &gt; switch over to the upstreamed thing.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I don&#39;t think so. When I submitted the patch for sch_plug to netde=
v,<br>
&gt; nobody (even the qdisc maintainer) mentioned anything about an<br>
&gt; equivalent module.<br>
<br>
</div>I must have been mistaken then. Why is your module not upstream?<br>
<div class=3D"im"><br></div></blockquote><div><br>Beats me.<br>=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">
&gt; &gt; There is no &quot;Xen Linux tree&quot; like there used to be and =
we wouldn&#39;t want<br>
&gt; &gt; to carry a module which isn&#39;t ready for upstream in any case.=
 (Your<br>
&gt; &gt; module wasn&#39;t axed, it just wasn&#39;t/isn&#39;t upstream).<b=
r>
&gt; &gt;<br>
&gt; &gt;&gt; While I am still, convincing the netdev folks into accepting =
this<br>
&gt; &gt;&gt; module upstream, I =A0have a link in the remus wiki, asking p=
eople to<br>
&gt; &gt;&gt; download/compile the module. (People do this only after shoot=
ing a<br>
&gt; &gt;&gt; couple of &quot;Remus is not working&quot; emails to the mail=
ing list)<br>
&gt; &gt;<br>
&gt; &gt; You can&#39;t detect this at runtime and print an error message? =
Do you not<br>
&gt; &gt; get ENOSYS or something when you try and use the module?<br>
&gt;<br>
&gt; I do. And the emails are despite that.<br>
<br>
</div>It sounds like there would be no helping these people.<br>
<div class=3D"im"><br>
&gt; &gt;&gt; As an alternative, I could pull it into the tools/remus/ fold=
er (just<br>
&gt; &gt;&gt; like the way it used to be before the pvops kernels) and comp=
ile it as<br>
&gt; &gt;&gt; part of the tools compilation process.<br>
&gt; &gt;<br>
&gt; &gt; The build doesn&#39;t include building a kernel any more so I don=
&#39;t think<br>
&gt; &gt; this will work.<br>
&gt;<br>
&gt;<br>
&gt; But can we at least include the source, make file and a readme telling=
<br>
&gt; people to install the required packages needed to compile a module.<br=
>
<br>
</div>We are trying to get out of the business of bundling every bit of<br>
infrastructure which someone happens to want to use with Xen in the Xen<br>
source repository, so, no, I don&#39;t think we can/should include the<br>
source to this Linux kernel module in the Xen tree.<br>
<br>
You could perhaps add a README or some Remus documentation directing<br>
people to an external tarball with the module in it, but from what you<br>
say above it doesn&#39;t sound like that will help very much (and neither<b=
r>
would having that tarball in the tree).<br>
<br>
Of course the right solution is to get your module merged upstream.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br>

--0015175df06ef26e1704b6e8480e--


--===============1881314970563125132==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1881314970563125132==--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:31:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:31:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzZw-0007xP-6c; Thu, 19 Jan 2012 21:31:28 +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 1RnzZv-0007xK-9X
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:31:27 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327008616!61728276!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7418 invoked from network); 19 Jan 2012 21:30:18 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 19 Jan 2012 21:30:18 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0JLVKpt019930
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Thu, 19 Jan 2012 13:31:21 -0800
Received: by bkat2 with SMTP id t2so908180bka.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:31:19 -0800 (PST)
Received: by 10.204.152.20 with SMTP id e20mr10533557bkw.117.1327008679357;
	Thu, 19 Jan 2012 13:31:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Thu, 19 Jan 2012 13:30:38 -0800 (PST)
In-Reply-To: <1327007424.21391.14.camel@dagon.hellion.org.uk>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
	<1327007424.21391.14.camel@dagon.hellion.org.uk>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Thu, 19 Jan 2012 13:30:38 -0800
Message-ID: <CAP8mzPNVJ32ypc65qVXBbkVFzXnEgfohYqj4S=zR_D-Y6BZLdw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============1881314970563125132=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1881314970563125132==
Content-Type: multipart/alternative; boundary=0015175df06ef26e1704b6e8480e

--0015175df06ef26e1704b6e8480e
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wrote:
> > On 2012-01-19, at 9:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >
> > > On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:
> > >>
> > >>
> > >> I do have a set of initial patches for xl remus. Since the "script="
> > >> support doesnt exist for disk configurations (required to support both
> > >> DRBD and tapdisk backends).
> > >>
> > >> So, currently I only have memory checkpointing functionality. No disk
> > >> buffering.
> > >> Will submit it in a day or so.
> > >>
> > >> About network buffering:
> > >> a.  There is code to install and manipulate the network buffer via
> > >> netlink messages. And its in python. While the "xl remus" control flow
> > >> starts off from C. Either I implement the C equivalent
> > >> of the python code or call the python code from C (this is C->python
> > >> and not the other way around). Please correct me if I am wrong.
> > >
> > > Wrong about what?
> > >
> > > I don't think calling Python from C in libxl is a good idea. Forking a
> > > process would be better but best would be to just implement the C
> > > version. Is there a libnetlink which can help with this sort of thing?
> > >
> >
> > There is. And it's in the tools tree (tools/python/xen/lowlevel/netlink/)
>
> I meant an existing generic netlink library, not something specific to
> the Xen python bindings.
>
> Debian has libnl{1,2,3} pacakges in it -- why not use them?
>
>
Yes I know. I have toyed with them. The qdisc names are hardcoded in their
libraries.
So, even if one installs sch_plug (qdisc name "plug"), the library wont
recognize it!
I do have my own version of the library (patched) but as you said, I dont
want to
bundle that stuff with xen.

There is no reason why this sort of generic library should be in the Xen
> tree. (lets be honest, there's no reason why the python bindings to such
> a library should be in Xen either)
>
> Just that it's bit cryptic and the netlink.py module makes things easy.
>
> Calling into python from libxl is not acceptable.
>
>
I understand. I wouldnt have done it either :)

 > >> b. The kernel module (sch_plug):  Last I knew, the network
> > >> buffering module (sch_plug) was in the pvops tree (2.6.* series). When
> > >> the tree moved to 3.0 series, it got axed off.
> > >
> > > My understanding was that a competing module with similar/equivalent
> > > functionality was the one which eventually made it upstream (I don't
> > > know the names). Unfortunately this probably means that Remus needs to
> > > switch over to the upstreamed thing.
> > >
> >
> > I don't think so. When I submitted the patch for sch_plug to netdev,
> > nobody (even the qdisc maintainer) mentioned anything about an
> > equivalent module.
>
> I must have been mistaken then. Why is your module not upstream?
>
>
Beats me.


> > > There is no "Xen Linux tree" like there used to be and we wouldn't want
> > > to carry a module which isn't ready for upstream in any case. (Your
> > > module wasn't axed, it just wasn't/isn't upstream).
> > >
> > >> While I am still, convincing the netdev folks into accepting this
> > >> module upstream, I  have a link in the remus wiki, asking people to
> > >> download/compile the module. (People do this only after shooting a
> > >> couple of "Remus is not working" emails to the mailing list)
> > >
> > > You can't detect this at runtime and print an error message? Do you not
> > > get ENOSYS or something when you try and use the module?
> >
> > I do. And the emails are despite that.
>
> It sounds like there would be no helping these people.
>
> > >> As an alternative, I could pull it into the tools/remus/ folder (just
> > >> like the way it used to be before the pvops kernels) and compile it as
> > >> part of the tools compilation process.
> > >
> > > The build doesn't include building a kernel any more so I don't think
> > > this will work.
> >
> >
> > But can we at least include the source, make file and a readme telling
> > people to install the required packages needed to compile a module.
>
> We are trying to get out of the business of bundling every bit of
> infrastructure which someone happens to want to use with Xen in the Xen
> source repository, so, no, I don't think we can/should include the
> source to this Linux kernel module in the Xen tree.
>
> You could perhaps add a README or some Remus documentation directing
> people to an external tarball with the module in it, but from what you
> say above it doesn't sound like that will help very much (and neither
> would having that tarball in the tree).
>
> Of course the right solution is to get your module merged upstream.
>
> Ian.
>
>

--0015175df06ef26e1704b6e8480e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Thu, 2012-01-19 at 19:00 +0000, Shriram Rajagopalan wr=
ote:<br>
&gt; On 2012-01-19, at 9:46 AM, Ian Campbell &lt;<a href=3D"mailto:Ian.Camp=
bell@citrix.com">Ian.Campbell@citrix.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Thu, 2012-01-19 at 17:35 +0000, Shriram Rajagopalan wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I do have a set of initial patches for xl remus. Since the &q=
uot;script=3D&quot;<br>
&gt; &gt;&gt; support doesnt exist for disk configurations (required to sup=
port both<br>
&gt; &gt;&gt; DRBD and tapdisk backends).<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; So, currently I only have memory checkpointing functionality.=
 No disk<br>
&gt; &gt;&gt; buffering.<br>
&gt; &gt;&gt; Will submit it in a day or so.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; About network buffering:<br>
&gt; &gt;&gt; a. =A0There is code to install and manipulate the network buf=
fer via<br>
&gt; &gt;&gt; netlink messages. And its in python. While the &quot;xl remus=
&quot; control flow<br>
&gt; &gt;&gt; starts off from C. Either I implement the C equivalent<br>
&gt; &gt;&gt; of the python code or call the python code from C (this is C-=
&gt;python<br>
&gt; &gt;&gt; and not the other way around). Please correct me if I am wron=
g.<br>
&gt; &gt;<br>
&gt; &gt; Wrong about what?<br>
&gt; &gt;<br>
&gt; &gt; I don&#39;t think calling Python from C in libxl is a good idea. =
Forking a<br>
&gt; &gt; process would be better but best would be to just implement the C=
<br>
&gt; &gt; version. Is there a libnetlink which can help with this sort of t=
hing?<br>
&gt; &gt;<br>
&gt;<br>
&gt; There is. And it&#39;s in the tools tree (tools/python/xen/lowlevel/ne=
tlink/)<br>
<br>
</div>I meant an existing generic netlink library, not something specific t=
o<br>
the Xen python bindings.<br>
<br>
Debian has libnl{1,2,3} pacakges in it -- why not use them?<br>
<br></blockquote><div><br>Yes I know. I have toyed with them. The qdisc nam=
es are hardcoded in their libraries.<br>So, even if one installs sch_plug (=
qdisc name &quot;plug&quot;), the library wont recognize it!<br>I do have m=
y own version of the library (patched) but as you said, I dont want to<br>

bundle that stuff with xen.<br><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
There is no reason why this sort of generic library should be in the Xen<br=
>
tree. (lets be honest, there&#39;s no reason why the python bindings to suc=
h<br>
a library should be in Xen either)<br></blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div class=3D"im">
&gt; Just that it&#39;s bit cryptic and the netlink.py module makes things =
easy.<br>
<br>
</div>Calling into python from libxl is not acceptable.<br>
<div class=3D"im"><br></div></blockquote><div>=A0</div><div>I understand. I=
 wouldnt have done it either :)<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">

<div class=3D"im">
&gt; &gt;&gt; b. The kernel module (sch_plug): =A0Last I knew, the network<=
br>
&gt; &gt;&gt; buffering module (sch_plug) was in the pvops tree (2.6.* seri=
es). When<br>
&gt; &gt;&gt; the tree moved to 3.0 series, it got axed off.<br>
&gt; &gt;<br>
&gt; &gt; My understanding was that a competing module with similar/equival=
ent<br>
&gt; &gt; functionality was the one which eventually made it upstream (I do=
n&#39;t<br>
&gt; &gt; know the names). Unfortunately this probably means that Remus nee=
ds to<br>
&gt; &gt; switch over to the upstreamed thing.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I don&#39;t think so. When I submitted the patch for sch_plug to netde=
v,<br>
&gt; nobody (even the qdisc maintainer) mentioned anything about an<br>
&gt; equivalent module.<br>
<br>
</div>I must have been mistaken then. Why is your module not upstream?<br>
<div class=3D"im"><br></div></blockquote><div><br>Beats me.<br>=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">
&gt; &gt; There is no &quot;Xen Linux tree&quot; like there used to be and =
we wouldn&#39;t want<br>
&gt; &gt; to carry a module which isn&#39;t ready for upstream in any case.=
 (Your<br>
&gt; &gt; module wasn&#39;t axed, it just wasn&#39;t/isn&#39;t upstream).<b=
r>
&gt; &gt;<br>
&gt; &gt;&gt; While I am still, convincing the netdev folks into accepting =
this<br>
&gt; &gt;&gt; module upstream, I =A0have a link in the remus wiki, asking p=
eople to<br>
&gt; &gt;&gt; download/compile the module. (People do this only after shoot=
ing a<br>
&gt; &gt;&gt; couple of &quot;Remus is not working&quot; emails to the mail=
ing list)<br>
&gt; &gt;<br>
&gt; &gt; You can&#39;t detect this at runtime and print an error message? =
Do you not<br>
&gt; &gt; get ENOSYS or something when you try and use the module?<br>
&gt;<br>
&gt; I do. And the emails are despite that.<br>
<br>
</div>It sounds like there would be no helping these people.<br>
<div class=3D"im"><br>
&gt; &gt;&gt; As an alternative, I could pull it into the tools/remus/ fold=
er (just<br>
&gt; &gt;&gt; like the way it used to be before the pvops kernels) and comp=
ile it as<br>
&gt; &gt;&gt; part of the tools compilation process.<br>
&gt; &gt;<br>
&gt; &gt; The build doesn&#39;t include building a kernel any more so I don=
&#39;t think<br>
&gt; &gt; this will work.<br>
&gt;<br>
&gt;<br>
&gt; But can we at least include the source, make file and a readme telling=
<br>
&gt; people to install the required packages needed to compile a module.<br=
>
<br>
</div>We are trying to get out of the business of bundling every bit of<br>
infrastructure which someone happens to want to use with Xen in the Xen<br>
source repository, so, no, I don&#39;t think we can/should include the<br>
source to this Linux kernel module in the Xen tree.<br>
<br>
You could perhaps add a README or some Remus documentation directing<br>
people to an external tarball with the module in it, but from what you<br>
say above it doesn&#39;t sound like that will help very much (and neither<b=
r>
would having that tarball in the tree).<br>
<br>
Of course the right solution is to get your module merged upstream.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
</font></span></blockquote></div><br>

--0015175df06ef26e1704b6e8480e--


--===============1881314970563125132==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1881314970563125132==--


From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:39:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzhW-0008Cu-7s; Thu, 19 Jan 2012 21:39:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnzhU-0008Cn-TU
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:39:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327009111!60973737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14603 invoked from network); 19 Jan 2012 21:38:31 -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 Jan 2012 21:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,538,1320624000"; d="scan'208";a="10163897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:39:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 21:39:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPNVJ32ypc65qVXBbkVFzXnEgfohYqj4S=zR_D-Y6BZLdw@mail.gmail.com>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
	<1327007424.21391.14.camel@dagon.hellion.org.uk>
	<CAP8mzPNVJ32ypc65qVXBbkVFzXnEgfohYqj4S=zR_D-Y6BZLdw@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 19 Jan 2012 21:39:11 +0000
Message-ID: <1327009151.21391.21.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 21:30 +0000, Shriram Rajagopalan wrote:
> On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell 
>         Debian has libnl{1,2,3} pacakges in it -- why not use them?
>         
> 
> Yes I know. I have toyed with them. The qdisc names are hardcoded in
> their libraries. So, even if one installs sch_plug (qdisc name
> "plug"), the library wont recognize it! I do have my own version of
> the library (patched) but as you said, I dont want to bundle that
> stuff with xen.

Why don't you send said patch to the libnl upstream? I'm sure once the
kernel module is in they will be interested in such a patch.

>         I must have been mistaken then. Why is your module not
>         upstream?
>         
>         
> 
> Beats me.

Did you send it more than once?

According to http://patchwork.ozlabs.org/patch/132315/ it is in state
"changes requested". There is a longish thread attached to the posting
so I assume it is something in there.

Just like with submitting patches to Xen you need to address any review
comments and resend patches, ping people etc, it's not just a case of
firing and forgetting a patch on a mailing list.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:39:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:39:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RnzhW-0008Cu-7s; Thu, 19 Jan 2012 21:39:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RnzhU-0008Cn-TU
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:39:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327009111!60973737!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14603 invoked from network); 19 Jan 2012 21:38:31 -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 Jan 2012 21:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,538,1320624000"; d="scan'208";a="10163897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:39:12 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 19 Jan 2012 21:39:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPNVJ32ypc65qVXBbkVFzXnEgfohYqj4S=zR_D-Y6BZLdw@mail.gmail.com>
References: <4F1548D5020000780006D25E@nat28.tlf.novell.com>
	<4F185478020000780006DBD9@nat28.tlf.novell.com>
	<CAP8mzPPdnwhUjQTBRE+O=jzaK7HeEN5Q_J0Vgw9WAbMiLA-RzA@mail.gmail.com>
	<1326995189.17599.103.camel@zakaz.uk.xensource.com>
	<146BC0DC-6B03-4339-8172-A7C181E1AD06@cs.ubc.ca>
	<1327007424.21391.14.camel@dagon.hellion.org.uk>
	<CAP8mzPNVJ32ypc65qVXBbkVFzXnEgfohYqj4S=zR_D-Y6BZLdw@mail.gmail.com>
Organization: Citrix Systems, Inc.
Date: Thu, 19 Jan 2012 21:39:11 +0000
Message-ID: <1327009151.21391.21.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: Brendan Cully <brendan@cs.ubc.ca>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 21:30 +0000, Shriram Rajagopalan wrote:
> On Thu, Jan 19, 2012 at 1:10 PM, Ian Campbell 
>         Debian has libnl{1,2,3} pacakges in it -- why not use them?
>         
> 
> Yes I know. I have toyed with them. The qdisc names are hardcoded in
> their libraries. So, even if one installs sch_plug (qdisc name
> "plug"), the library wont recognize it! I do have my own version of
> the library (patched) but as you said, I dont want to bundle that
> stuff with xen.

Why don't you send said patch to the libnl upstream? I'm sure once the
kernel module is in they will be interested in such a patch.

>         I must have been mistaken then. Why is your module not
>         upstream?
>         
>         
> 
> Beats me.

Did you send it more than once?

According to http://patchwork.ozlabs.org/patch/132315/ it is in state
"changes requested". There is a longish thread attached to the posting
so I assume it is something in there.

Just like with submitting patches to Xen you need to address any review
comments and resend patches, ping people etc, it's not just a case of
firing and forgetting a patch on a mailing list.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:51:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnzsc-0000Oz-SS; Thu, 19 Jan 2012 21:50: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 1Rnzsb-0000Ou-TV
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:50:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327009799!50826226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 786 invoked from network); 19 Jan 2012 21:49:59 -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;
	19 Jan 2012 21:49:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,538,1320624000"; d="scan'208";a="10163991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:50: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, 19 Jan 2012 21:50: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 1RnzsZ-0000jA-NO;
	Thu, 19 Jan 2012 21:50:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnzsZ-0007Gr-Mn;
	Thu, 19 Jan 2012 21:50:43 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10906-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 21:50:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10906: 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 10906 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10906/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10902
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10902
 test-amd64-amd64-win          7 windows-install    fail in 10902 pass in 10906
 test-i386-i386-xl-win         7 windows-install    fail in 10902 pass in 10906
 test-amd64-i386-win           7 windows-install    fail in 10902 pass in 10906

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10902 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10902 never pass

version targeted for testing:
 xen                  2273ef2083d4
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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=2273ef2083d4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 2273ef2083d4
+ branch=xen-unstable
+ revision=2273ef2083d4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 2273ef2083d4 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 59 changesets with 229 changes to 181 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:51:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:51:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnzsc-0000Oz-SS; Thu, 19 Jan 2012 21:50: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 1Rnzsb-0000Ou-TV
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:50:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327009799!50826226!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA5MTkwMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 786 invoked from network); 19 Jan 2012 21:49:59 -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;
	19 Jan 2012 21:49:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,538,1320624000"; d="scan'208";a="10163991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	19 Jan 2012 21:50: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, 19 Jan 2012 21:50: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 1RnzsZ-0000jA-NO;
	Thu, 19 Jan 2012 21:50:43 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RnzsZ-0007Gr-Mn;
	Thu, 19 Jan 2012 21:50:43 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10906-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 19 Jan 2012 21:50:43 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10906: 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 10906 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10906/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-win       7 windows-install             fail pass in 10902
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10902
 test-amd64-amd64-win          7 windows-install    fail in 10902 pass in 10906
 test-i386-i386-xl-win         7 windows-install    fail in 10902 pass in 10906
 test-amd64-i386-win           7 windows-install    fail in 10902 pass in 10906

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 10902 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10902 never pass

version targeted for testing:
 xen                  2273ef2083d4
baseline version:
 xen                  5b2676ac1321

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Christoph Egger <Christoph.Egger@amd.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Gang Wei <gang.wei@intel.com>
  George Dunlap <george.dunlap@eu.citrix.com>
  Hui Lv <hui.lv@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>
  Joseph Cihula <joseph.cihula@intel.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Paul Durrant <paul.durrant@citrix.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Shane Wang <shane.wang@intel.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Wang <wei.wang2@amd.com>
  Wei, Gang <gang.wei@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=2273ef2083d4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 2273ef2083d4
+ branch=xen-unstable
+ revision=2273ef2083d4
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 2273ef2083d4 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 59 changesets with 229 changes to 181 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:56:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnzy6-0002Ey-7o; Thu, 19 Jan 2012 21:56: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 1Rnzy3-00029p-Du
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:56:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327010176!11734843!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 13854 invoked from network); 19 Jan 2012 21:56:17 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:56:17 -0000
Received: by wibhj8 with SMTP id hj8so1063346wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:56: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=MfPRxh09tY9ShooyWNpd+sKVmWxLoVONL3n+HG/bbMo=;
	b=Pas9+4sFccDu+ZJiAa4BRWX6fgD1nv+u2gRrARururazhEfAde/b7LVd484+imWCAm
	BGErgVz3NkjEAlzyq8U+xPvonqOmvJfJBrDbQWKMVZn+UmhNTsPKtl7Bz1rwhMh0jk2l
	QCYiiHulYWx/z3BsZLM0nVNgMMeDR43TmRUnk=
Received: by 10.180.101.35 with SMTP id fd3mr46991248wib.22.1327010176607;
	Thu, 19 Jan 2012 13:56:16 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id r1sm30318595wia.8.2012.01.19.13.56.15
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 13:56:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 21:56:14 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3E41FE.2925E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW9SmXa4nKO+sgfEKoDh9AfPIaMw==
In-Reply-To: <f46a8328cddbf3a18195159cbd0a0955.squirrel@webmail.lagarcavilla.org>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 21:23, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>> 
>> I don't think gcc extensions such as this are allowed in
>> xen/include/public. You should explicitly pack the struct instead.
> 
> domctl.h is in a way spared, because __attribute__((aligned(8))) is
> allowed in 32 bits. And the header is spared the ansi test.
> 
> Is there a rationale to allowing this ABI file do 'aligned', but
> preventing that other header file from using it?
> 
> I'm thinking uint64_aligned_t would solve my problem in memory.h.

Would like public headers to not be gcc specific. The toolstack is a more
specific special case, it contains lots of gcc-isms anyway. Hence its
sysctl/domctl hypercalls are allowed more leeway.

Frankly, rather than hauling the mem_event toolstack operations out of
domctl, you might be better just fixing the coarse-grained locking at least
for the particular commands you care about. The big domctl lock is not
needed for a quite a few of those domctl operations.

 -- Keir

> Andres
> 
>> 
>> Ian.
>> 
>>> 
>>> Thanks!
>>> Andres
>>> 
>>>> 
>>>>> Exploring the include/public/memory.h declarations and toolstack
>>> code, I
>>>>> see that no current declare includes __attribute__((aligned)) or
>>>>> __attribute__((packed)), or explicit pads.
>>>>> 
>>>>> So how come things don't break more often for 32 bit toolstacks? pure
>>>>> luck? Am I missing something?
>>>> 
>>>> Where older structs were not 32/64-bit invariant, compat shims were
>>>> implemented. See common/compat/memory.c, for example. Well worth
>>> avoiding
>>>> that!
>>>> 
>>>>  -- Keir
>>>> 
>>>>> Thanks!
>>>>> Andres
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/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 Jan 19 21:56:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:56:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnzy6-0002Ey-7o; Thu, 19 Jan 2012 21:56: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 1Rnzy3-00029p-Du
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:56:23 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327010176!11734843!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 13854 invoked from network); 19 Jan 2012 21:56:17 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:56:17 -0000
Received: by wibhj8 with SMTP id hj8so1063346wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:56: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=MfPRxh09tY9ShooyWNpd+sKVmWxLoVONL3n+HG/bbMo=;
	b=Pas9+4sFccDu+ZJiAa4BRWX6fgD1nv+u2gRrARururazhEfAde/b7LVd484+imWCAm
	BGErgVz3NkjEAlzyq8U+xPvonqOmvJfJBrDbQWKMVZn+UmhNTsPKtl7Bz1rwhMh0jk2l
	QCYiiHulYWx/z3BsZLM0nVNgMMeDR43TmRUnk=
Received: by 10.180.101.35 with SMTP id fd3mr46991248wib.22.1327010176607;
	Thu, 19 Jan 2012 13:56:16 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id r1sm30318595wia.8.2012.01.19.13.56.15
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 13:56:16 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 21:56:14 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3E41FE.2925E%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW9SmXa4nKO+sgfEKoDh9AfPIaMw==
In-Reply-To: <f46a8328cddbf3a18195159cbd0a0955.squirrel@webmail.lagarcavilla.org>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 21:23, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:

>> 
>> I don't think gcc extensions such as this are allowed in
>> xen/include/public. You should explicitly pack the struct instead.
> 
> domctl.h is in a way spared, because __attribute__((aligned(8))) is
> allowed in 32 bits. And the header is spared the ansi test.
> 
> Is there a rationale to allowing this ABI file do 'aligned', but
> preventing that other header file from using it?
> 
> I'm thinking uint64_aligned_t would solve my problem in memory.h.

Would like public headers to not be gcc specific. The toolstack is a more
specific special case, it contains lots of gcc-isms anyway. Hence its
sysctl/domctl hypercalls are allowed more leeway.

Frankly, rather than hauling the mem_event toolstack operations out of
domctl, you might be better just fixing the coarse-grained locking at least
for the particular commands you care about. The big domctl lock is not
needed for a quite a few of those domctl operations.

 -- Keir

> Andres
> 
>> 
>> Ian.
>> 
>>> 
>>> Thanks!
>>> Andres
>>> 
>>>> 
>>>>> Exploring the include/public/memory.h declarations and toolstack
>>> code, I
>>>>> see that no current declare includes __attribute__((aligned)) or
>>>>> __attribute__((packed)), or explicit pads.
>>>>> 
>>>>> So how come things don't break more often for 32 bit toolstacks? pure
>>>>> luck? Am I missing something?
>>>> 
>>>> Where older structs were not 32/64-bit invariant, compat shims were
>>>> implemented. See common/compat/memory.c, for example. Well worth
>>> avoiding
>>>> that!
>>>> 
>>>>  -- Keir
>>>> 
>>>>> Thanks!
>>>>> Andres
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
>>>>> http://lists.xensource.com/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 Jan 19 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnzyi-0002R8-Mh; Thu, 19 Jan 2012 21:57:04 +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 1Rnzyh-0002Ph-Fk
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:57:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327010217!11734887!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 14865 invoked from network); 19 Jan 2012 21:56:57 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:56:57 -0000
Received: by wgbdt11 with SMTP id dt11so401530wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:56:56 -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=D2oRqM5HoL/WXYxFA5Hn2ue5wM7zs8A0MSI5H9OwReA=;
	b=DDU9IF+cUUbS1trszMUyb34wVcq4UC30hsNQbE8+XXOL+gHR8JG4GJMECfa3qnjeL5
	JowOFs2CGD62flaXLP4esbX4QAP81fH9JNbWkb4PUKYe9W8LLrUpFLd25v53V5KB6Kks
	3zu+SDcz35WIK7xibvgxGOF59dKHwWoL73k+Q=
Received: by 10.180.95.131 with SMTP id dk3mr36209756wib.6.1327010216811;
	Thu, 19 Jan 2012 13:56:56 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l2sm2181667wie.11.2012.01.19.13.56.53
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 13:56:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 21:56:51 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3E4223.2925F%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW9T+k/VS3aPl4a0O8cva9jbJ05A==
In-Reply-To: <1327007550.21391.16.camel@dagon.hellion.org.uk>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 21:12, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-01-19 at 21:07 +0000, Keir Fraser wrote:
>>> Yes. And also use __attribute(__packed__);
>> 
>> Not used in any public header files.
> 
> One seems to have crept into xen/include/public/arch-x86/hvm/save.h :-(

Thanks, I'll get rid of it. It looks like it should have no effect on that
struct anyway.

 -- Keir

> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 21:57:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 21:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rnzyi-0002R8-Mh; Thu, 19 Jan 2012 21:57:04 +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 1Rnzyh-0002Ph-Fk
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 21:57:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327010217!11734887!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 14865 invoked from network); 19 Jan 2012 21:56:57 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:56:57 -0000
Received: by wgbdt11 with SMTP id dt11so401530wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 13:56:56 -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=D2oRqM5HoL/WXYxFA5Hn2ue5wM7zs8A0MSI5H9OwReA=;
	b=DDU9IF+cUUbS1trszMUyb34wVcq4UC30hsNQbE8+XXOL+gHR8JG4GJMECfa3qnjeL5
	JowOFs2CGD62flaXLP4esbX4QAP81fH9JNbWkb4PUKYe9W8LLrUpFLd25v53V5KB6Kks
	3zu+SDcz35WIK7xibvgxGOF59dKHwWoL73k+Q=
Received: by 10.180.95.131 with SMTP id dk3mr36209756wib.6.1327010216811;
	Thu, 19 Jan 2012 13:56:56 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l2sm2181667wie.11.2012.01.19.13.56.53
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 13:56:56 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 21:56:51 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3E4223.2925F%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW9T+k/VS3aPl4a0O8cva9jbJ05A==
In-Reply-To: <1327007550.21391.16.camel@dagon.hellion.org.uk>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 21:12, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Thu, 2012-01-19 at 21:07 +0000, Keir Fraser wrote:
>>> Yes. And also use __attribute(__packed__);
>> 
>> Not used in any public header files.
> 
> One seems to have crept into xen/include/public/arch-x86/hvm/save.h :-(

Thanks, I'll get rid of it. It looks like it should have no effect on that
struct anyway.

 -- Keir

> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 22:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 22:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro01m-0002lP-AV; Thu, 19 Jan 2012 22:00: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 1Ro01l-0002lI-BQ
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 22:00:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327010369!60975044!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 9005 invoked from network); 19 Jan 2012 21:59:29 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:59:29 -0000
Received: by wibhj8 with SMTP id hj8so1074110wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 14:00:11 -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=BPiLGbWkfZrGrD731eBhWbJTGfiWO+cNKfFCYzOfhgU=;
	b=fZMcRpW5DLVMvagC4tdjiJJwzTCUJwasnZVMHDQpWnbzN7j0I5HrLlnEg3OuJM7oI0
	6DCzk2SHTSLFQ9NnCtfR8b9HYJoLjSr3Kpsu8BM5TxKMNp/+KUnD/CWRt1ehnI5bziQ1
	Lq48y1MzAVnLuwld4qCfehyzC68bdbLwGk3bM=
Received: by 10.180.95.199 with SMTP id dm7mr47538738wib.9.1327010411236;
	Thu, 19 Jan 2012 14:00:11 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fd1sm30600001wib.0.2012.01.19.14.00.09
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 14:00:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 22:00:04 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3E42E4.29270%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW9SmXa4nKO+sgfEKoDh9AfPIaMwAAIkXp
In-Reply-To: <CB3E41FE.2925E%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 21:56, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 19/01/2012 21:23, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> 
>>> 
>>> I don't think gcc extensions such as this are allowed in
>>> xen/include/public. You should explicitly pack the struct instead.
>> 
>> domctl.h is in a way spared, because __attribute__((aligned(8))) is
>> allowed in 32 bits. And the header is spared the ansi test.
>> 
>> Is there a rationale to allowing this ABI file do 'aligned', but
>> preventing that other header file from using it?
>> 
>> I'm thinking uint64_aligned_t would solve my problem in memory.h.
> 
> Would like public headers to not be gcc specific. The toolstack is a more
> specific special case, it contains lots of gcc-isms anyway. Hence its
> sysctl/domctl hypercalls are allowed more leeway.
> 
> Frankly, rather than hauling the mem_event toolstack operations out of
> domctl, you might be better just fixing the coarse-grained locking at least
> for the particular commands you care about. The big domctl lock is not
> needed for a quite a few of those domctl operations.

As an alternative, you could declare a tools-only section for
public/memory.h. See public/hvm/hvm_op.h for example, which therefore gets
to use uint64_aligned_t in those sections.

If your struct is for general consumption by any guest then you're SOL and
have to do it the hard way.

 -- Keir

>  -- Keir
> 
>> Andres
>> 
>>> 
>>> Ian.
>>> 
>>>> 
>>>> Thanks!
>>>> Andres
>>>> 
>>>>> 
>>>>>> Exploring the include/public/memory.h declarations and toolstack
>>>> code, I
>>>>>> see that no current declare includes __attribute__((aligned)) or
>>>>>> __attribute__((packed)), or explicit pads.
>>>>>> 
>>>>>> So how come things don't break more often for 32 bit toolstacks? pure
>>>>>> luck? Am I missing something?
>>>>> 
>>>>> Where older structs were not 32/64-bit invariant, compat shims were
>>>>> implemented. See common/compat/memory.c, for example. Well worth
>>>> avoiding
>>>>> that!
>>>>> 
>>>>>  -- Keir
>>>>> 
>>>>>> Thanks!
>>>>>> Andres
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/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 Jan 19 22:00:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 22:00:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro01m-0002lP-AV; Thu, 19 Jan 2012 22:00: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 1Ro01l-0002lI-BQ
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 22:00:13 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327010369!60975044!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 9005 invoked from network); 19 Jan 2012 21:59:29 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 21:59:29 -0000
Received: by wibhj8 with SMTP id hj8so1074110wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 14:00:11 -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=BPiLGbWkfZrGrD731eBhWbJTGfiWO+cNKfFCYzOfhgU=;
	b=fZMcRpW5DLVMvagC4tdjiJJwzTCUJwasnZVMHDQpWnbzN7j0I5HrLlnEg3OuJM7oI0
	6DCzk2SHTSLFQ9NnCtfR8b9HYJoLjSr3Kpsu8BM5TxKMNp/+KUnD/CWRt1ehnI5bziQ1
	Lq48y1MzAVnLuwld4qCfehyzC68bdbLwGk3bM=
Received: by 10.180.95.199 with SMTP id dm7mr47538738wib.9.1327010411236;
	Thu, 19 Jan 2012 14:00:11 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fd1sm30600001wib.0.2012.01.19.14.00.09
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 14:00:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 22:00:04 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3E42E4.29270%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW9SmXa4nKO+sgfEKoDh9AfPIaMwAAIkXp
In-Reply-To: <CB3E41FE.2925E%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 21:56, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 19/01/2012 21:23, "Andres Lagar-Cavilla" <andres@lagarcavilla.org> wrote:
> 
>>> 
>>> I don't think gcc extensions such as this are allowed in
>>> xen/include/public. You should explicitly pack the struct instead.
>> 
>> domctl.h is in a way spared, because __attribute__((aligned(8))) is
>> allowed in 32 bits. And the header is spared the ansi test.
>> 
>> Is there a rationale to allowing this ABI file do 'aligned', but
>> preventing that other header file from using it?
>> 
>> I'm thinking uint64_aligned_t would solve my problem in memory.h.
> 
> Would like public headers to not be gcc specific. The toolstack is a more
> specific special case, it contains lots of gcc-isms anyway. Hence its
> sysctl/domctl hypercalls are allowed more leeway.
> 
> Frankly, rather than hauling the mem_event toolstack operations out of
> domctl, you might be better just fixing the coarse-grained locking at least
> for the particular commands you care about. The big domctl lock is not
> needed for a quite a few of those domctl operations.

As an alternative, you could declare a tools-only section for
public/memory.h. See public/hvm/hvm_op.h for example, which therefore gets
to use uint64_aligned_t in those sections.

If your struct is for general consumption by any guest then you're SOL and
have to do it the hard way.

 -- Keir

>  -- Keir
> 
>> Andres
>> 
>>> 
>>> Ian.
>>> 
>>>> 
>>>> Thanks!
>>>> Andres
>>>> 
>>>>> 
>>>>>> Exploring the include/public/memory.h declarations and toolstack
>>>> code, I
>>>>>> see that no current declare includes __attribute__((aligned)) or
>>>>>> __attribute__((packed)), or explicit pads.
>>>>>> 
>>>>>> So how come things don't break more often for 32 bit toolstacks? pure
>>>>>> luck? Am I missing something?
>>>>> 
>>>>> Where older structs were not 32/64-bit invariant, compat shims were
>>>>> implemented. See common/compat/memory.c, for example. Well worth
>>>> avoiding
>>>>> that!
>>>>> 
>>>>>  -- Keir
>>>>> 
>>>>>> Thanks!
>>>>>> Andres
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Xen-devel mailing list
>>>>>> Xen-devel@lists.xensource.com
>>>>>> http://lists.xensource.com/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 Jan 19 22:05:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 22:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro06c-0002yD-2g; Thu, 19 Jan 2012 22:05:14 +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 1Ro06a-0002xv-Gv
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 22:05:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327010705!11619892!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12412 invoked from network); 19 Jan 2012 22:05:06 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 22:05:06 -0000
Received: by werb14 with SMTP id b14so559755wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 14:05:05 -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=ip3tFnDORn31+KJz2SE171lfSY6RtpXuzK5610/aw/M=;
	b=QknwMZckqtF/NHpYOJXCnyIJ5M+vWt6r6/fNY6YA50J2qBHYBTS3Mog3R26pEpva9R
	VUASzXrMlKGnRFTKedyRGblYfOc8a8pYQRVJ1I368ThIWOJg9B1TPGzliqFGAcv6SSXj
	hjSuJP+/bAY9WRrxcz4fSB5+9uuBP1ljxHMfw=
Received: by 10.216.135.214 with SMTP id u64mr3469104wei.58.1327010705443;
	Thu, 19 Jan 2012 14:05:05 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dr5sm2370482wib.0.2012.01.19.14.05.03
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 14:05:04 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 22:04:59 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3E440B.29275%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW9SmXa4nKO+sgfEKoDh9AfPIaMwAAIkXpAAAr9hA=
In-Reply-To: <CB3E42E4.29270%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 22:00, "Keir Fraser" <keir.xen@gmail.com> wrote:

>> Would like public headers to not be gcc specific. The toolstack is a more
>> specific special case, it contains lots of gcc-isms anyway. Hence its
>> sysctl/domctl hypercalls are allowed more leeway.
>> 
>> Frankly, rather than hauling the mem_event toolstack operations out of
>> domctl, you might be better just fixing the coarse-grained locking at least
>> for the particular commands you care about. The big domctl lock is not
>> needed for a quite a few of those domctl operations.
> 
> As an alternative, you could declare a tools-only section for
> public/memory.h. See public/hvm/hvm_op.h for example, which therefore gets
> to use uint64_aligned_t in those sections.

Also, if you are adding toolstack commands to an existing general-purpose
hypercall, wrapping it in defined(__XEN_TOOLS__) is useful documentation.

 -- Keir

> If your struct is for general consumption by any guest then you're SOL and
> have to do it the hard way.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 22:05:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 22:05:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro06c-0002yD-2g; Thu, 19 Jan 2012 22:05:14 +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 1Ro06a-0002xv-Gv
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 22:05:12 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327010705!11619892!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12412 invoked from network); 19 Jan 2012 22:05:06 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	19 Jan 2012 22:05:06 -0000
Received: by werb14 with SMTP id b14so559755wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 14:05:05 -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=ip3tFnDORn31+KJz2SE171lfSY6RtpXuzK5610/aw/M=;
	b=QknwMZckqtF/NHpYOJXCnyIJ5M+vWt6r6/fNY6YA50J2qBHYBTS3Mog3R26pEpva9R
	VUASzXrMlKGnRFTKedyRGblYfOc8a8pYQRVJ1I368ThIWOJg9B1TPGzliqFGAcv6SSXj
	hjSuJP+/bAY9WRrxcz4fSB5+9uuBP1ljxHMfw=
Received: by 10.216.135.214 with SMTP id u64mr3469104wei.58.1327010705443;
	Thu, 19 Jan 2012 14:05:05 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dr5sm2370482wib.0.2012.01.19.14.05.03
	(version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 14:05:04 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 19 Jan 2012 22:04:59 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3E440B.29275%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczW9SmXa4nKO+sgfEKoDh9AfPIaMwAAIkXpAAAr9hA=
In-Reply-To: <CB3E42E4.29270%keir.xen@gmail.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 22:00, "Keir Fraser" <keir.xen@gmail.com> wrote:

>> Would like public headers to not be gcc specific. The toolstack is a more
>> specific special case, it contains lots of gcc-isms anyway. Hence its
>> sysctl/domctl hypercalls are allowed more leeway.
>> 
>> Frankly, rather than hauling the mem_event toolstack operations out of
>> domctl, you might be better just fixing the coarse-grained locking at least
>> for the particular commands you care about. The big domctl lock is not
>> needed for a quite a few of those domctl operations.
> 
> As an alternative, you could declare a tools-only section for
> public/memory.h. See public/hvm/hvm_op.h for example, which therefore gets
> to use uint64_aligned_t in those sections.

Also, if you are adding toolstack commands to an existing general-purpose
hypercall, wrapping it in defined(__XEN_TOOLS__) is useful documentation.

 -- Keir

> If your struct is for general consumption by any guest then you're SOL and
> have to do it the hard way.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 19 22:05:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 22: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 1Ro06h-0002yi-G7; Thu, 19 Jan 2012 22:05:19 +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 1Ro06f-0002y4-Jj
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 22:05:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327010708!9902800!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxODM5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16071 invoked from network); 19 Jan 2012 22:05:09 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-174.messagelabs.com with SMTP;
	19 Jan 2012 22:05:09 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 0AD6276C069;
	Thu, 19 Jan 2012 14:05:07 -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=mFyx8jAYrNtt/iFTNkYIbvrQ5LfCwva9yn8K5hDKbhVZ
	JRQAlSajXmPWFQFDkpMW4g4eBzOzT4NVEIjiSndfhPavD9fk1FjVQUIvLS/XS4WD
	WechyEcmuDDqI3Bu4xZNeKWFYyz4MujNV2L5oHteFQJDsZCn+N93NHpHdNMeH3E=
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=iP2ovR0NUfuZln62ArXEzXU4yzo=; b=GTmY5AEP
	ctZN+B3BWTZky1Orkbbjbbfvs/TcPXHodlz4ltNu8RrSxu4ecwErKlSab2wC1Snx
	QlcQ+V8LF6w5d/rDVi+kDrWm78/PK4CQscxnwfDTahEwshn2heQ67hWHVbdjAdQM
	ehPnEUqiOVCkA+kOVrrfRZjJfAe4GwAF8KU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id C0D5F76C065; 
	Thu, 19 Jan 2012 14:05:06 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 14:05:07 -0800
Message-ID: <01f5cfca681d747e5a27a345df6a8e60.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB3E42E4.29270%keir.xen@gmail.com>
References: <CB3E42E4.29270%keir.xen@gmail.com>
Date: Thu, 19 Jan 2012 14:05:07 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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] memop struct packing, 32/64 bits
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 19/01/2012 21:56, "Keir Fraser" <keir.xen@gmail.com> wrote:
>
>> On 19/01/2012 21:23, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>> wrote:
>>
>>>>
>>>> I don't think gcc extensions such as this are allowed in
>>>> xen/include/public. You should explicitly pack the struct instead.
>>>
>>> domctl.h is in a way spared, because __attribute__((aligned(8))) is
>>> allowed in 32 bits. And the header is spared the ansi test.
>>>
>>> Is there a rationale to allowing this ABI file do 'aligned', but
>>> preventing that other header file from using it?
>>>
>>> I'm thinking uint64_aligned_t would solve my problem in memory.h.
>>
>> Would like public headers to not be gcc specific. The toolstack is a
>> more
>> specific special case, it contains lots of gcc-isms anyway. Hence its
>> sysctl/domctl hypercalls are allowed more leeway.
>>
>> Frankly, rather than hauling the mem_event toolstack operations out of
>> domctl, you might be better just fixing the coarse-grained locking at
>> least
>> for the particular commands you care about. The big domctl lock is not
>> needed for a quite a few of those domctl operations.
>
> As an alternative, you could declare a tools-only section for
> public/memory.h. See public/hvm/hvm_op.h for example, which therefore gets
> to use uint64_aligned_t in those sections.

This sounds like the way to go. Luckily not for general consumption and
not SOL :)

Thanks!
Andres

>
> If your struct is for general consumption by any guest then you're SOL and
> have to do it the hard way.
>
>  -- Keir
>
>>  -- Keir
>>
>>> Andres
>>>
>>>>
>>>> Ian.
>>>>
>>>>>
>>>>> Thanks!
>>>>> Andres
>>>>>
>>>>>>
>>>>>>> Exploring the include/public/memory.h declarations and toolstack
>>>>> code, I
>>>>>>> see that no current declare includes __attribute__((aligned)) or
>>>>>>> __attribute__((packed)), or explicit pads.
>>>>>>>
>>>>>>> So how come things don't break more often for 32 bit toolstacks?
>>>>>>> pure
>>>>>>> luck? Am I missing something?
>>>>>>
>>>>>> Where older structs were not 32/64-bit invariant, compat shims were
>>>>>> implemented. See common/compat/memory.c, for example. Well worth
>>>>> avoiding
>>>>>> that!
>>>>>>
>>>>>>  -- Keir
>>>>>>
>>>>>>> Thanks!
>>>>>>> Andres
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xensource.com
>>>>>>> http://lists.xensource.com/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 Jan 19 22:05:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 19 Jan 2012 22: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 1Ro06h-0002yi-G7; Thu, 19 Jan 2012 22:05:19 +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 1Ro06f-0002y4-Jj
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 22:05:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327010708!9902800!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxODM5NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16071 invoked from network); 19 Jan 2012 22:05:09 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-174.messagelabs.com with SMTP;
	19 Jan 2012 22:05:09 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 0AD6276C069;
	Thu, 19 Jan 2012 14:05:07 -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=mFyx8jAYrNtt/iFTNkYIbvrQ5LfCwva9yn8K5hDKbhVZ
	JRQAlSajXmPWFQFDkpMW4g4eBzOzT4NVEIjiSndfhPavD9fk1FjVQUIvLS/XS4WD
	WechyEcmuDDqI3Bu4xZNeKWFYyz4MujNV2L5oHteFQJDsZCn+N93NHpHdNMeH3E=
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=iP2ovR0NUfuZln62ArXEzXU4yzo=; b=GTmY5AEP
	ctZN+B3BWTZky1Orkbbjbbfvs/TcPXHodlz4ltNu8RrSxu4ecwErKlSab2wC1Snx
	QlcQ+V8LF6w5d/rDVi+kDrWm78/PK4CQscxnwfDTahEwshn2heQ67hWHVbdjAdQM
	ehPnEUqiOVCkA+kOVrrfRZjJfAe4GwAF8KU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id C0D5F76C065; 
	Thu, 19 Jan 2012 14:05:06 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 19 Jan 2012 14:05:07 -0800
Message-ID: <01f5cfca681d747e5a27a345df6a8e60.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <CB3E42E4.29270%keir.xen@gmail.com>
References: <CB3E42E4.29270%keir.xen@gmail.com>
Date: Thu, 19 Jan 2012 14:05:07 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Keir Fraser" <keir.xen@gmail.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"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] memop struct packing, 32/64 bits
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 19/01/2012 21:56, "Keir Fraser" <keir.xen@gmail.com> wrote:
>
>> On 19/01/2012 21:23, "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
>> wrote:
>>
>>>>
>>>> I don't think gcc extensions such as this are allowed in
>>>> xen/include/public. You should explicitly pack the struct instead.
>>>
>>> domctl.h is in a way spared, because __attribute__((aligned(8))) is
>>> allowed in 32 bits. And the header is spared the ansi test.
>>>
>>> Is there a rationale to allowing this ABI file do 'aligned', but
>>> preventing that other header file from using it?
>>>
>>> I'm thinking uint64_aligned_t would solve my problem in memory.h.
>>
>> Would like public headers to not be gcc specific. The toolstack is a
>> more
>> specific special case, it contains lots of gcc-isms anyway. Hence its
>> sysctl/domctl hypercalls are allowed more leeway.
>>
>> Frankly, rather than hauling the mem_event toolstack operations out of
>> domctl, you might be better just fixing the coarse-grained locking at
>> least
>> for the particular commands you care about. The big domctl lock is not
>> needed for a quite a few of those domctl operations.
>
> As an alternative, you could declare a tools-only section for
> public/memory.h. See public/hvm/hvm_op.h for example, which therefore gets
> to use uint64_aligned_t in those sections.

This sounds like the way to go. Luckily not for general consumption and
not SOL :)

Thanks!
Andres

>
> If your struct is for general consumption by any guest then you're SOL and
> have to do it the hard way.
>
>  -- Keir
>
>>  -- Keir
>>
>>> Andres
>>>
>>>>
>>>> Ian.
>>>>
>>>>>
>>>>> Thanks!
>>>>> Andres
>>>>>
>>>>>>
>>>>>>> Exploring the include/public/memory.h declarations and toolstack
>>>>> code, I
>>>>>>> see that no current declare includes __attribute__((aligned)) or
>>>>>>> __attribute__((packed)), or explicit pads.
>>>>>>>
>>>>>>> So how come things don't break more often for 32 bit toolstacks?
>>>>>>> pure
>>>>>>> luck? Am I missing something?
>>>>>>
>>>>>> Where older structs were not 32/64-bit invariant, compat shims were
>>>>>> implemented. See common/compat/memory.c, for example. Well worth
>>>>> avoiding
>>>>>> that!
>>>>>>
>>>>>>  -- Keir
>>>>>>
>>>>>>> Thanks!
>>>>>>> Andres
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xen-devel mailing list
>>>>>>> Xen-devel@lists.xensource.com
>>>>>>> http://lists.xensource.com/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 Jan 20 05:26:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 05:26:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro6yT-00065J-Jf; Fri, 20 Jan 2012 05:25: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 1Ro6yS-00065B-4U
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 05:25:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327037109!9869054!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5612 invoked from network); 20 Jan 2012 05:25:09 -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;
	20 Jan 2012 05:25:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,540,1320624000"; d="scan'208";a="10169336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 05:25: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, 20 Jan 2012 05:25: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 1Ro6lZ-0003V4-Kk;
	Fri, 20 Jan 2012 05:11:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ro6lZ-0001Vz-As;
	Fri, 20 Jan 2012 05:11:57 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10913-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Jan 2012 05:11:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10913: 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 10913 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10913/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1 11 guest-localmigrate.2       fail pass in 10906
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 10906
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10906 pass in 10913

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-win          7 windows-install              fail   like 10902
 test-amd64-amd64-xl-win       7 windows-install              fail   like 10906
 test-amd64-i386-win           7 windows-install              fail   like 10902

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-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 in 10906 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10906 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10906 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10906 never pass

version targeted for testing:
 xen                  2273ef2083d4
baseline version:
 xen                  2273ef2083d4

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Fri Jan 20 05:26:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 05:26:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro6yT-00065J-Jf; Fri, 20 Jan 2012 05:25: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 1Ro6yS-00065B-4U
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 05:25:16 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327037109!9869054!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5612 invoked from network); 20 Jan 2012 05:25:09 -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;
	20 Jan 2012 05:25:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,540,1320624000"; d="scan'208";a="10169336"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 05:25: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, 20 Jan 2012 05:25: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 1Ro6lZ-0003V4-Kk;
	Fri, 20 Jan 2012 05:11:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Ro6lZ-0001Vz-As;
	Fri, 20 Jan 2012 05:11:57 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10913-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Jan 2012 05:11:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10913: 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 10913 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10913/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win-vcpus1 11 guest-localmigrate.2       fail pass in 10906
 test-amd64-i386-xl-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail pass in 10906
 test-amd64-i386-win-vcpus1    7 windows-install    fail in 10906 pass in 10913

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-win          7 windows-install              fail   like 10902
 test-amd64-amd64-xl-win       7 windows-install              fail   like 10906
 test-amd64-i386-win           7 windows-install              fail   like 10902

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-amd64-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 in 10906 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 10906 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 10906 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 10906 never pass

version targeted for testing:
 xen                  2273ef2083d4
baseline version:
 xen                  2273ef2083d4

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Fri Jan 20 07:42:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 07:42:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro96K-0000QM-1x; Fri, 20 Jan 2012 07:41:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1Ro96I-0000QH-Ih
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 07:41:31 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327045241!51024830!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_TEST_2,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7591 invoked from network); 20 Jan 2012 07:40:42 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 07:40:42 -0000
Received: by lago2 with SMTP id o2so400975lag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 23:41:28 -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
	:content-transfer-encoding;
	bh=IVETgznnZhWr1UTEFIQNQdqCVQiATt+qwvM3wcNInKQ=;
	b=KFhWspSInKzscGCXMUqhKk1tiw7MoOL4NzXQmcPVDWVF9NVMmVzsJ4Sn2o4MJXvxnk
	AzA+AxMckCd3RUS+DtkeTF7HaF4odmpQoxcfQ9jdem+Mdi6Y9/2KcC9zYgy6CCsKujx3
	Oos0zJz10OQIU5tcQAo4LO0xMpNzTQKOcBrlo=
Received: by 10.152.145.71 with SMTP id ss7mr14086895lab.28.1327045288380;
	Thu, 19 Jan 2012 23:41:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Thu, 19 Jan 2012 23:41:12 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <20120119195046.GA3890@konrad-lan>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
	<CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
	<20120119195046.GA3890@konrad-lan>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 20 Jan 2012 11:41:12 +0400
X-Google-Sender-Auth: xH_-EvQtZ0uIzORFRCaKgvkVxKo
Message-ID: <CACaajQuwjtFgHk3-2Tun3AiS+1hvi=LYSoQiynvgPRzE=sYEKw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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

MjAxMi8xLzE5IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkQGRhcm5vay5vcmc+Ogo+PiA+
Cj4+ID4gV2hpY2gga2VybmVsIHZlcnNpb24gb2YgRG9tVT8KPj4KPj4gMi42LjMyLjI2IGZyb20g
eGVuIGdpdCB0cmVlIGFuZCDCoDIuNi4xOC0xOTQuMjYuMS5lbDV4ZW4KPgo+IEZpcnN0IG9yZGVy
IGlzIHRvIHVwZ3JhZGUgeW91ciBrZXJuZWwgYW5kIHNlZSBpZiB0aGUgcHJvYmxlbSBleGlzdHMK
PiB3aXRoIGEgbmV3ZXIgMi42LjMyLlggdHJlZS4gdGhlbiBhbHNvIHRyeSAzLjAgb3IgMy4xIGtl
cm5lbC4KPj4KCgpUaGlzIGlzIHBvc3NpYmxlLCBidXQgbXkgcXVlc3Rpb24gaXMgLSB3aHkgb24g
c29tZSB2ZXJzaW9uIG9mIHRoZQprZXJuZWwgb24gc2FtZSBub2RlIHNvbWUgZGFtaW5zIGNvdWQg
bm90IHByb3Blcmx5IHdhdGNoIHhlbnN0b3JlPwoKPj4KPj4gPgo+PiA+IFBsYXkgYSBiaXQgd2l0
aCB4ZW5jdHggdG8gZ2V0IGFuIGlkZWEgd2hlcmUgdGhlIGd1ZXN0IGlzIHN0dWNrIGF0Lgo+PiA+
Cj4+Cj4+IE9rLCBuaWNlLiBXaGVuIGkgbmVlZCB0byBydW4geGVuY3R4IGFuZCB3aGF0IGkgbmVl
ZCB0byBzZWUgaW4gaXRzIG91dHB1dD8KPgo+IDxzaWdoPiBHb29nbGUgZm9yIGl0LiBUaGVyZSBz
aG91bGQgYmUgdG9ucyBvZiBleGFtcGxlcyBvZiBob3cgdG8gdXNlIGl0Cj4gdG8gZmlndXJlIG91
dCB3aGVyZSB0aGUgZ3Vlc3QgaXMgc3R1Y2sgYXQuCgpPay4gSSBjcmVhdGUgdHdvIGVxdWFsIGRv
bVUgd2l0aCBtZW1vcnk9NTEyTSBhbmQgbWF4bWVtb3J5ID0gNTEyTSwKY29weSBTeXN0ZW0ubWFw
IHRvIGRvbTAgYW5kIGNoZWNrIHhlbmN0eCBvdXRwdXQuIERvbWFpbnMgcnVucyBvbiBzYW1lCm5v
ZGUgYW5kIG9ubHkgZGlmZmVycyBpbiB1cHRpbWUuCkRvbWFpbiwgdGhhdCBjb3JyZWN0IHdvcmtz
IG9uIHhlbnN0b3JlIHdhdGNoZXM6CgovdXNyL2xpYjY0L3hlbi9iaW4veGVuY3R4IC1zIC9yb290
L1N5c3RlbS5tYXAtMi42LjMyLjI2IC0tc3RhY2stdHJhY2UgLWEgMTc4CnJpcDogZmZmZmZmZmY4
MTAwOTNhYSBoeXBlcmNhbGxfcGFnZSsweDNhYQpmbGFnczogMDAwMDEyNDYgaSB6IHAKcnNwOiBm
ZmZmZmZmZjgxNTM5ZjAwCnJheDogMDAwMDAwMDAwMDAwMDAwMAlyY3g6IGZmZmZmZmZmODEwMDkz
YWEJcmR4OiBmZmZmZmZmZjgxMDA5M2FhCnJieDogZmZmZmZmZmY4MTU5NWFjMAlyc2k6IDAwMDAw
MDAwMDAwMDAwMDAJcmRpOiAwMDAwMDAwMDAwMDAwMDAxCnJicDogZmZmZmZmZmY4MTUzOWYxOAkg
cjg6IDAwMDAwMDAwMDAwMDAwMDAJIHI5OiBmZmZmODgwMDAzMTMwMzk4CnIxMDogMDAwMDAwMDAw
MDAwMDAwMAlyMTE6IDAwMDAwMDAwMDAwMDAyNDYJcjEyOiA2ZGI2ZGI2ZGI2ZGI2ZGI3CnIxMzog
ZmZmZmZmZmY4MTVlMWNjMAlyMTQ6IGZmZmZmZmZmODE1ZTM3MjAJcjE1OiAwMDAwMDAwMDAwMDAw
MDAwCiBjczogZTAzMwkgc3M6IGUwMmIJIGRzOiAwMDAwCSBlczogMDAwMAogZnM6IDAwMDAgQCAw
MDAwN2Y0ZjUzNGJkNzQwCiBnczogMDAwMCBAIGZmZmY4ODAwMDMwY2QwMDAvMDAwMDAwMDAwMDAw
MDAwMAoKY3IwOiA4MDA1MDAzYgpjcjI6IDdmODQ5N2QyZDEzMApjcjM6IDg2NDRiZDAwMApjcjQ6
IDAwMDAyNjYwCgpkcjA6IDAwMDAwMDAwCmRyMTogMDAwMDAwMDAKZHIyOiAwMDAwMDAwMApkcjM6
IDAwMDAwMDAwCmRyNjogZmZmZjBmZjAKZHI3OiAwMDAwMDQwMApDb2RlIChpbnN0ciBhZGRyIGZm
ZmZmZmZmODEwMDkzYWEpCmNjIGNjIGNjIGNjIGNjIGNjIGNjIGNjIGNjIGNjIGNjIDUxIDQxIDUz
IGI4IDFkIDAwIDAwIDAwIDBmIDA1IDw0MT4gNWIKNTkgYzMgY2MgY2MgY2MgY2MgY2MgY2MgY2MK
CgpTdGFjazoKIGZmZmY4ODAwMDMwYzAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDBl
MTliIGZmZmZmZmZmODE1MzlmMjgKIGZmZmZmZmZmODEwMTgzNWMgZmZmZmZmZmY4MTUzOWY0OCBm
ZmZmZmZmZjgxMDEwMzIwIGZmZmZmZmZmODE1ZTM3MjAKIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MTUzOWY1OCBmZmZmZmZmZjgxM2QyYWIyIGZmZmZmZmZmODE1MzlmOTgKIGZmZmZmZmZmODE1
YWZkMzQgZmZmZmZmZmY4MTUzOWY5OCBmZmZmZmZmZjgxNWUzNzIwIDAwMDAwMDAwMDE2YzY4MTgK
ClN0YWNrIFRyYWNlOgoqIFs8ZmZmZmZmZmY4MTAwOTNhYT5dIGh5cGVyY2FsbF9wYWdlKzB4M2Fh
ICA8LS0KICAgIGZmZmY4ODAwMDMwYzAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICBbPGZmZmZm
ZmZmODEwMGUxOWI+XSB4ZW5fc2FmZV9oYWx0KzB4MTAKICAgIGZmZmZmZmZmODE1MzlmMjgKICBb
PGZmZmZmZmZmODEwMTgzNWM+XSBkZWZhdWx0X2lkbGUrMHgyNQogICAgZmZmZmZmZmY4MTUzOWY0
OAogIFs8ZmZmZmZmZmY4MTAxMDMyMD5dIGNwdV9pZGxlKzB4NTgKICAgIGZmZmZmZmZmODE1ZTM3
MjAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIGZmZmZmZmZmODE1MzlmNTgKICBbPGZmZmZmZmZm
ODEzZDJhYjI+XSByZXN0X2luaXQrMHg2NgogICAgZmZmZmZmZmY4MTUzOWY5OAogIFs8ZmZmZmZm
ZmY4MTVhZmQzND5dIHN0YXJ0X2tlcm5lbCsweDNhMgogICAgZmZmZmZmZmY4MTUzOWY5OAogICAg
ZmZmZmZmZmY4MTVlMzcyMAogICAgMDAwMDAwMDAwMTZjNjgxOAogICAgMDAwMDAwMDAwMDAwMDAw
MAogICAgMDAwMDAwMDAwMDAwMDAwMAogICAgMDAwMDAwMDAwMDAwMDAwMAogICAgZmZmZmZmZmY4
MTUzOWZiOAogIFs8ZmZmZmZmZmY4MTVhZjJjMz5dIHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMr
MHhhZQogICAgZmZmZmZmZmY4MTVhNjVhMAogICAgZmZmZmZmZmY4MTAwMTAwMAogICAgZmZmZmZm
ZmY4MTUzOWZmOAogIFs8ZmZmZmZmZmY4MTViMTc2Mj5dIHhlbl9zdGFydF9rZXJuZWwrMHg0MWQK
ICAgIDgwOTgyMjAxMWY4OTg5NzUKICAgIDAwMDEwNmE1MDAxMDA4MDAKICAgIDAwMDAwMDAwMDAw
MDAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIDAwMDAw
MDAwMDAwMDAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKCgpEb21haW4gdGhhdCBub3Qgbm90aWZp
ZWQgb24geGVuc3RvcmUgd2F0Y2hlczoKL3Vzci9saWI2NC94ZW4vYmluL3hlbmN0eCAtcyAvcm9v
dC9TeXN0ZW0ubWFwLTIuNi4zMi4yNiAtLXN0YWNrLXRyYWNlIC1hIDY3NgpyaXA6IGZmZmZmZmZm
ODEwMDkzYWEgaHlwZXJjYWxsX3BhZ2UrMHgzYWEKZmxhZ3M6IDAwMDAxMjQ2IGkgeiBwCnJzcDog
ZmZmZmZmZmY4MTUzOWYwMApyYXg6IDAwMDAwMDAwMDAwMDAwMDAJcmN4OiBmZmZmZmZmZjgxMDA5
M2FhCXJkeDogZmZmZmZmZmY4MTAwOTNhYQpyYng6IGZmZmZmZmZmODE1OTVhYzAJcnNpOiAwMDAw
MDAwMDAwMDAwMDAwCXJkaTogMDAwMDAwMDAwMDAwMDAwMQpyYnA6IGZmZmZmZmZmODE1MzlmMTgJ
IHI4OiAwMDAwMDAwMDAwMDAwMDAwCSByOTogZmZmZmZmZmY4MTY5MDM4MApyMTA6IDAwMDAwMDAx
MDIyOTllNjIJcjExOiAwMDAwMDAwMDAwMDAwMjQ2CXIxMjogNmRiNmRiNmRiNmRiNmRiNwpyMTM6
IGZmZmZmZmZmODE1ZTFjYzAJcjE0OiBmZmZmZmZmZjgxNWUzNzIwCXIxNTogMDAwMDAwMDAwMDAw
MDAwMAogY3M6IGUwMzMJIHNzOiBlMDJiCSBkczogMDAwMAkgZXM6IDAwMDAKIGZzOiAwMDAwIEAg
MDAwMDdmYTYwNzQ1NDcwMAogZ3M6IDAwMDAgQCBmZmZmODgwMDAyZjM2MDAwLzAwMDAwMDAwMDAw
MDAwMDAKCmNyMDogODAwNTAwM2IKY3IyOiA3ZjA3ZTdhNDgwYTAKY3IzOiBiM2MzN2YwMDAKY3I0
OiAwMDAwMjY2MAoKZHIwOiAwMDAwMDAwMApkcjE6IDAwMDAwMDAwCmRyMjogMDAwMDAwMDAKZHIz
OiAwMDAwMDAwMApkcjY6IGZmZmYwZmYwCmRyNzogMDAwMDA0MDAKQ29kZSAoaW5zdHIgYWRkciBm
ZmZmZmZmZjgxMDA5M2FhKQpjYyBjYyBjYyBjYyBjYyBjYyBjYyBjYyBjYyBjYyBjYyA1MSA0MSA1
MyBiOCAxZCAwMCAwMCAwMCAwZiAwNSA8NDE+IDViCjU5IGMzIGNjIGNjIGNjIGNjIGNjIGNjIGNj
CgoKU3RhY2s6CiBmZmZmODgwMDAyZjMwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MTAw
ZTE5YiBmZmZmZmZmZjgxNTM5ZjI4CiBmZmZmZmZmZjgxMDE4MzVjIGZmZmZmZmZmODE1MzlmNDgg
ZmZmZmZmZmY4MTAxMDMyMCBmZmZmZmZmZjgxNWUzNzIwCiAwMDAwMDAwMDAwMDAwMDAwIGZmZmZm
ZmZmODE1MzlmNTggZmZmZmZmZmY4MTNkMmFiMiBmZmZmZmZmZjgxNTM5Zjk4CiBmZmZmZmZmZjgx
NWFmZDM0IGZmZmZmZmZmODE1MzlmOTggZmZmZmZmZmY4MTVlMzcyMCAwMDAwMDAwMDAxNmM2ODE4
CgpTdGFjayBUcmFjZToKKiBbPGZmZmZmZmZmODEwMDkzYWE+XSBoeXBlcmNhbGxfcGFnZSsweDNh
YSAgPC0tCiAgICBmZmZmODgwMDAyZjMwMDAwCiAgICAwMDAwMDAwMDAwMDAwMDAwCiAgWzxmZmZm
ZmZmZjgxMDBlMTliPl0geGVuX3NhZmVfaGFsdCsweDEwCiAgICBmZmZmZmZmZjgxNTM5ZjI4CiAg
WzxmZmZmZmZmZjgxMDE4MzVjPl0gZGVmYXVsdF9pZGxlKzB4MjUKICAgIGZmZmZmZmZmODE1Mzlm
NDgKICBbPGZmZmZmZmZmODEwMTAzMjA+XSBjcHVfaWRsZSsweDU4CiAgICBmZmZmZmZmZjgxNWUz
NzIwCiAgICAwMDAwMDAwMDAwMDAwMDAwCiAgICBmZmZmZmZmZjgxNTM5ZjU4CiAgWzxmZmZmZmZm
ZjgxM2QyYWIyPl0gcmVzdF9pbml0KzB4NjYKICAgIGZmZmZmZmZmODE1MzlmOTgKICBbPGZmZmZm
ZmZmODE1YWZkMzQ+XSBzdGFydF9rZXJuZWwrMHgzYTIKICAgIGZmZmZmZmZmODE1MzlmOTgKICAg
IGZmZmZmZmZmODE1ZTM3MjAKICAgIDAwMDAwMDAwMDE2YzY4MTgKICAgIDAwMDAwMDAwMDAwMDAw
MDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIGZmZmZmZmZm
ODE1MzlmYjgKICBbPGZmZmZmZmZmODE1YWYyYzM+XSB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25z
KzB4YWUKICAgIGZmZmZmZmZmODE1YTY1YTAKICAgIGZmZmZmZmZmODEwMDEwMDAKICAgIGZmZmZm
ZmZmODE1MzlmZjgKICBbPGZmZmZmZmZmODE1YjE3NjI+XSB4ZW5fc3RhcnRfa2VybmVsKzB4NDFk
CiAgICA4MDk4MjIwMTFmODk4OTc1CiAgICAwMDAxMDZhNTAwMTAwODAwCiAgICAwMDAwMDAwMDAw
MDAwMDAwCiAgICAwMDAwMDAwMDAwMDAwMDAwCiAgICAwMDAwMDAwMDAwMDAwMDAwCiAgICAwMDAw
MDAwMDAwMDAwMDAwCiAgICAwMDAwMDAwMDAwMDAwMDAwCgoKLS0gClZhc2lsaXkgVG9sc3RvdiwK
Q2xvZG8ucnUKZS1tYWlsOiB2LnRvbHN0b3ZAc2VsZmlwLnJ1CmphYmJlcjogdmFzZUBzZWxmaXAu
cnUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Jan 20 07:42:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 07:42:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro96K-0000QM-1x; Fri, 20 Jan 2012 07:41:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1Ro96I-0000QH-Ih
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 07:41:31 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327045241!51024830!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_TEST_2,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7591 invoked from network); 20 Jan 2012 07:40:42 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 07:40:42 -0000
Received: by lago2 with SMTP id o2so400975lag.30
	for <xen-devel@lists.xensource.com>;
	Thu, 19 Jan 2012 23:41:28 -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
	:content-transfer-encoding;
	bh=IVETgznnZhWr1UTEFIQNQdqCVQiATt+qwvM3wcNInKQ=;
	b=KFhWspSInKzscGCXMUqhKk1tiw7MoOL4NzXQmcPVDWVF9NVMmVzsJ4Sn2o4MJXvxnk
	AzA+AxMckCd3RUS+DtkeTF7HaF4odmpQoxcfQ9jdem+Mdi6Y9/2KcC9zYgy6CCsKujx3
	Oos0zJz10OQIU5tcQAo4LO0xMpNzTQKOcBrlo=
Received: by 10.152.145.71 with SMTP id ss7mr14086895lab.28.1327045288380;
	Thu, 19 Jan 2012 23:41:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Thu, 19 Jan 2012 23:41:12 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <20120119195046.GA3890@konrad-lan>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
	<CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
	<20120119195046.GA3890@konrad-lan>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 20 Jan 2012 11:41:12 +0400
X-Google-Sender-Auth: xH_-EvQtZ0uIzORFRCaKgvkVxKo
Message-ID: <CACaajQuwjtFgHk3-2Tun3AiS+1hvi=LYSoQiynvgPRzE=sYEKw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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

MjAxMi8xLzE5IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkQGRhcm5vay5vcmc+Ogo+PiA+
Cj4+ID4gV2hpY2gga2VybmVsIHZlcnNpb24gb2YgRG9tVT8KPj4KPj4gMi42LjMyLjI2IGZyb20g
eGVuIGdpdCB0cmVlIGFuZCDCoDIuNi4xOC0xOTQuMjYuMS5lbDV4ZW4KPgo+IEZpcnN0IG9yZGVy
IGlzIHRvIHVwZ3JhZGUgeW91ciBrZXJuZWwgYW5kIHNlZSBpZiB0aGUgcHJvYmxlbSBleGlzdHMK
PiB3aXRoIGEgbmV3ZXIgMi42LjMyLlggdHJlZS4gdGhlbiBhbHNvIHRyeSAzLjAgb3IgMy4xIGtl
cm5lbC4KPj4KCgpUaGlzIGlzIHBvc3NpYmxlLCBidXQgbXkgcXVlc3Rpb24gaXMgLSB3aHkgb24g
c29tZSB2ZXJzaW9uIG9mIHRoZQprZXJuZWwgb24gc2FtZSBub2RlIHNvbWUgZGFtaW5zIGNvdWQg
bm90IHByb3Blcmx5IHdhdGNoIHhlbnN0b3JlPwoKPj4KPj4gPgo+PiA+IFBsYXkgYSBiaXQgd2l0
aCB4ZW5jdHggdG8gZ2V0IGFuIGlkZWEgd2hlcmUgdGhlIGd1ZXN0IGlzIHN0dWNrIGF0Lgo+PiA+
Cj4+Cj4+IE9rLCBuaWNlLiBXaGVuIGkgbmVlZCB0byBydW4geGVuY3R4IGFuZCB3aGF0IGkgbmVl
ZCB0byBzZWUgaW4gaXRzIG91dHB1dD8KPgo+IDxzaWdoPiBHb29nbGUgZm9yIGl0LiBUaGVyZSBz
aG91bGQgYmUgdG9ucyBvZiBleGFtcGxlcyBvZiBob3cgdG8gdXNlIGl0Cj4gdG8gZmlndXJlIG91
dCB3aGVyZSB0aGUgZ3Vlc3QgaXMgc3R1Y2sgYXQuCgpPay4gSSBjcmVhdGUgdHdvIGVxdWFsIGRv
bVUgd2l0aCBtZW1vcnk9NTEyTSBhbmQgbWF4bWVtb3J5ID0gNTEyTSwKY29weSBTeXN0ZW0ubWFw
IHRvIGRvbTAgYW5kIGNoZWNrIHhlbmN0eCBvdXRwdXQuIERvbWFpbnMgcnVucyBvbiBzYW1lCm5v
ZGUgYW5kIG9ubHkgZGlmZmVycyBpbiB1cHRpbWUuCkRvbWFpbiwgdGhhdCBjb3JyZWN0IHdvcmtz
IG9uIHhlbnN0b3JlIHdhdGNoZXM6CgovdXNyL2xpYjY0L3hlbi9iaW4veGVuY3R4IC1zIC9yb290
L1N5c3RlbS5tYXAtMi42LjMyLjI2IC0tc3RhY2stdHJhY2UgLWEgMTc4CnJpcDogZmZmZmZmZmY4
MTAwOTNhYSBoeXBlcmNhbGxfcGFnZSsweDNhYQpmbGFnczogMDAwMDEyNDYgaSB6IHAKcnNwOiBm
ZmZmZmZmZjgxNTM5ZjAwCnJheDogMDAwMDAwMDAwMDAwMDAwMAlyY3g6IGZmZmZmZmZmODEwMDkz
YWEJcmR4OiBmZmZmZmZmZjgxMDA5M2FhCnJieDogZmZmZmZmZmY4MTU5NWFjMAlyc2k6IDAwMDAw
MDAwMDAwMDAwMDAJcmRpOiAwMDAwMDAwMDAwMDAwMDAxCnJicDogZmZmZmZmZmY4MTUzOWYxOAkg
cjg6IDAwMDAwMDAwMDAwMDAwMDAJIHI5OiBmZmZmODgwMDAzMTMwMzk4CnIxMDogMDAwMDAwMDAw
MDAwMDAwMAlyMTE6IDAwMDAwMDAwMDAwMDAyNDYJcjEyOiA2ZGI2ZGI2ZGI2ZGI2ZGI3CnIxMzog
ZmZmZmZmZmY4MTVlMWNjMAlyMTQ6IGZmZmZmZmZmODE1ZTM3MjAJcjE1OiAwMDAwMDAwMDAwMDAw
MDAwCiBjczogZTAzMwkgc3M6IGUwMmIJIGRzOiAwMDAwCSBlczogMDAwMAogZnM6IDAwMDAgQCAw
MDAwN2Y0ZjUzNGJkNzQwCiBnczogMDAwMCBAIGZmZmY4ODAwMDMwY2QwMDAvMDAwMDAwMDAwMDAw
MDAwMAoKY3IwOiA4MDA1MDAzYgpjcjI6IDdmODQ5N2QyZDEzMApjcjM6IDg2NDRiZDAwMApjcjQ6
IDAwMDAyNjYwCgpkcjA6IDAwMDAwMDAwCmRyMTogMDAwMDAwMDAKZHIyOiAwMDAwMDAwMApkcjM6
IDAwMDAwMDAwCmRyNjogZmZmZjBmZjAKZHI3OiAwMDAwMDQwMApDb2RlIChpbnN0ciBhZGRyIGZm
ZmZmZmZmODEwMDkzYWEpCmNjIGNjIGNjIGNjIGNjIGNjIGNjIGNjIGNjIGNjIGNjIDUxIDQxIDUz
IGI4IDFkIDAwIDAwIDAwIDBmIDA1IDw0MT4gNWIKNTkgYzMgY2MgY2MgY2MgY2MgY2MgY2MgY2MK
CgpTdGFjazoKIGZmZmY4ODAwMDMwYzAwMDAgMDAwMDAwMDAwMDAwMDAwMCBmZmZmZmZmZjgxMDBl
MTliIGZmZmZmZmZmODE1MzlmMjgKIGZmZmZmZmZmODEwMTgzNWMgZmZmZmZmZmY4MTUzOWY0OCBm
ZmZmZmZmZjgxMDEwMzIwIGZmZmZmZmZmODE1ZTM3MjAKIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZm
ZmY4MTUzOWY1OCBmZmZmZmZmZjgxM2QyYWIyIGZmZmZmZmZmODE1MzlmOTgKIGZmZmZmZmZmODE1
YWZkMzQgZmZmZmZmZmY4MTUzOWY5OCBmZmZmZmZmZjgxNWUzNzIwIDAwMDAwMDAwMDE2YzY4MTgK
ClN0YWNrIFRyYWNlOgoqIFs8ZmZmZmZmZmY4MTAwOTNhYT5dIGh5cGVyY2FsbF9wYWdlKzB4M2Fh
ICA8LS0KICAgIGZmZmY4ODAwMDMwYzAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICBbPGZmZmZm
ZmZmODEwMGUxOWI+XSB4ZW5fc2FmZV9oYWx0KzB4MTAKICAgIGZmZmZmZmZmODE1MzlmMjgKICBb
PGZmZmZmZmZmODEwMTgzNWM+XSBkZWZhdWx0X2lkbGUrMHgyNQogICAgZmZmZmZmZmY4MTUzOWY0
OAogIFs8ZmZmZmZmZmY4MTAxMDMyMD5dIGNwdV9pZGxlKzB4NTgKICAgIGZmZmZmZmZmODE1ZTM3
MjAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIGZmZmZmZmZmODE1MzlmNTgKICBbPGZmZmZmZmZm
ODEzZDJhYjI+XSByZXN0X2luaXQrMHg2NgogICAgZmZmZmZmZmY4MTUzOWY5OAogIFs8ZmZmZmZm
ZmY4MTVhZmQzND5dIHN0YXJ0X2tlcm5lbCsweDNhMgogICAgZmZmZmZmZmY4MTUzOWY5OAogICAg
ZmZmZmZmZmY4MTVlMzcyMAogICAgMDAwMDAwMDAwMTZjNjgxOAogICAgMDAwMDAwMDAwMDAwMDAw
MAogICAgMDAwMDAwMDAwMDAwMDAwMAogICAgMDAwMDAwMDAwMDAwMDAwMAogICAgZmZmZmZmZmY4
MTUzOWZiOAogIFs8ZmZmZmZmZmY4MTVhZjJjMz5dIHg4Nl82NF9zdGFydF9yZXNlcnZhdGlvbnMr
MHhhZQogICAgZmZmZmZmZmY4MTVhNjVhMAogICAgZmZmZmZmZmY4MTAwMTAwMAogICAgZmZmZmZm
ZmY4MTUzOWZmOAogIFs8ZmZmZmZmZmY4MTViMTc2Mj5dIHhlbl9zdGFydF9rZXJuZWwrMHg0MWQK
ICAgIDgwOTgyMjAxMWY4OTg5NzUKICAgIDAwMDEwNmE1MDAxMDA4MDAKICAgIDAwMDAwMDAwMDAw
MDAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIDAwMDAw
MDAwMDAwMDAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKCgpEb21haW4gdGhhdCBub3Qgbm90aWZp
ZWQgb24geGVuc3RvcmUgd2F0Y2hlczoKL3Vzci9saWI2NC94ZW4vYmluL3hlbmN0eCAtcyAvcm9v
dC9TeXN0ZW0ubWFwLTIuNi4zMi4yNiAtLXN0YWNrLXRyYWNlIC1hIDY3NgpyaXA6IGZmZmZmZmZm
ODEwMDkzYWEgaHlwZXJjYWxsX3BhZ2UrMHgzYWEKZmxhZ3M6IDAwMDAxMjQ2IGkgeiBwCnJzcDog
ZmZmZmZmZmY4MTUzOWYwMApyYXg6IDAwMDAwMDAwMDAwMDAwMDAJcmN4OiBmZmZmZmZmZjgxMDA5
M2FhCXJkeDogZmZmZmZmZmY4MTAwOTNhYQpyYng6IGZmZmZmZmZmODE1OTVhYzAJcnNpOiAwMDAw
MDAwMDAwMDAwMDAwCXJkaTogMDAwMDAwMDAwMDAwMDAwMQpyYnA6IGZmZmZmZmZmODE1MzlmMTgJ
IHI4OiAwMDAwMDAwMDAwMDAwMDAwCSByOTogZmZmZmZmZmY4MTY5MDM4MApyMTA6IDAwMDAwMDAx
MDIyOTllNjIJcjExOiAwMDAwMDAwMDAwMDAwMjQ2CXIxMjogNmRiNmRiNmRiNmRiNmRiNwpyMTM6
IGZmZmZmZmZmODE1ZTFjYzAJcjE0OiBmZmZmZmZmZjgxNWUzNzIwCXIxNTogMDAwMDAwMDAwMDAw
MDAwMAogY3M6IGUwMzMJIHNzOiBlMDJiCSBkczogMDAwMAkgZXM6IDAwMDAKIGZzOiAwMDAwIEAg
MDAwMDdmYTYwNzQ1NDcwMAogZ3M6IDAwMDAgQCBmZmZmODgwMDAyZjM2MDAwLzAwMDAwMDAwMDAw
MDAwMDAKCmNyMDogODAwNTAwM2IKY3IyOiA3ZjA3ZTdhNDgwYTAKY3IzOiBiM2MzN2YwMDAKY3I0
OiAwMDAwMjY2MAoKZHIwOiAwMDAwMDAwMApkcjE6IDAwMDAwMDAwCmRyMjogMDAwMDAwMDAKZHIz
OiAwMDAwMDAwMApkcjY6IGZmZmYwZmYwCmRyNzogMDAwMDA0MDAKQ29kZSAoaW5zdHIgYWRkciBm
ZmZmZmZmZjgxMDA5M2FhKQpjYyBjYyBjYyBjYyBjYyBjYyBjYyBjYyBjYyBjYyBjYyA1MSA0MSA1
MyBiOCAxZCAwMCAwMCAwMCAwZiAwNSA8NDE+IDViCjU5IGMzIGNjIGNjIGNjIGNjIGNjIGNjIGNj
CgoKU3RhY2s6CiBmZmZmODgwMDAyZjMwMDAwIDAwMDAwMDAwMDAwMDAwMDAgZmZmZmZmZmY4MTAw
ZTE5YiBmZmZmZmZmZjgxNTM5ZjI4CiBmZmZmZmZmZjgxMDE4MzVjIGZmZmZmZmZmODE1MzlmNDgg
ZmZmZmZmZmY4MTAxMDMyMCBmZmZmZmZmZjgxNWUzNzIwCiAwMDAwMDAwMDAwMDAwMDAwIGZmZmZm
ZmZmODE1MzlmNTggZmZmZmZmZmY4MTNkMmFiMiBmZmZmZmZmZjgxNTM5Zjk4CiBmZmZmZmZmZjgx
NWFmZDM0IGZmZmZmZmZmODE1MzlmOTggZmZmZmZmZmY4MTVlMzcyMCAwMDAwMDAwMDAxNmM2ODE4
CgpTdGFjayBUcmFjZToKKiBbPGZmZmZmZmZmODEwMDkzYWE+XSBoeXBlcmNhbGxfcGFnZSsweDNh
YSAgPC0tCiAgICBmZmZmODgwMDAyZjMwMDAwCiAgICAwMDAwMDAwMDAwMDAwMDAwCiAgWzxmZmZm
ZmZmZjgxMDBlMTliPl0geGVuX3NhZmVfaGFsdCsweDEwCiAgICBmZmZmZmZmZjgxNTM5ZjI4CiAg
WzxmZmZmZmZmZjgxMDE4MzVjPl0gZGVmYXVsdF9pZGxlKzB4MjUKICAgIGZmZmZmZmZmODE1Mzlm
NDgKICBbPGZmZmZmZmZmODEwMTAzMjA+XSBjcHVfaWRsZSsweDU4CiAgICBmZmZmZmZmZjgxNWUz
NzIwCiAgICAwMDAwMDAwMDAwMDAwMDAwCiAgICBmZmZmZmZmZjgxNTM5ZjU4CiAgWzxmZmZmZmZm
ZjgxM2QyYWIyPl0gcmVzdF9pbml0KzB4NjYKICAgIGZmZmZmZmZmODE1MzlmOTgKICBbPGZmZmZm
ZmZmODE1YWZkMzQ+XSBzdGFydF9rZXJuZWwrMHgzYTIKICAgIGZmZmZmZmZmODE1MzlmOTgKICAg
IGZmZmZmZmZmODE1ZTM3MjAKICAgIDAwMDAwMDAwMDE2YzY4MTgKICAgIDAwMDAwMDAwMDAwMDAw
MDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIDAwMDAwMDAwMDAwMDAwMDAKICAgIGZmZmZmZmZm
ODE1MzlmYjgKICBbPGZmZmZmZmZmODE1YWYyYzM+XSB4ODZfNjRfc3RhcnRfcmVzZXJ2YXRpb25z
KzB4YWUKICAgIGZmZmZmZmZmODE1YTY1YTAKICAgIGZmZmZmZmZmODEwMDEwMDAKICAgIGZmZmZm
ZmZmODE1MzlmZjgKICBbPGZmZmZmZmZmODE1YjE3NjI+XSB4ZW5fc3RhcnRfa2VybmVsKzB4NDFk
CiAgICA4MDk4MjIwMTFmODk4OTc1CiAgICAwMDAxMDZhNTAwMTAwODAwCiAgICAwMDAwMDAwMDAw
MDAwMDAwCiAgICAwMDAwMDAwMDAwMDAwMDAwCiAgICAwMDAwMDAwMDAwMDAwMDAwCiAgICAwMDAw
MDAwMDAwMDAwMDAwCiAgICAwMDAwMDAwMDAwMDAwMDAwCgoKLS0gClZhc2lsaXkgVG9sc3RvdiwK
Q2xvZG8ucnUKZS1tYWlsOiB2LnRvbHN0b3ZAc2VsZmlwLnJ1CmphYmJlcjogdmFzZUBzZWxmaXAu
cnUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1k
ZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xp
c3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Jan 20 07:51:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 07: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 1Ro9FR-0000u5-5g; Fri, 20 Jan 2012 07:50:57 +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 1Ro9FP-0000tx-8x; Fri, 20 Jan 2012 07:50:55 +0000
X-Env-Sender: nupurghatnekar@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327045848!11797565!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12657 invoked from network); 20 Jan 2012 07:50:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 07:50:48 -0000
Received: by werb14 with SMTP id b14so1333040wer.30
	for <multiple recipients>; Thu, 19 Jan 2012 23:50:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=GEVtk8y2gpxvE0Z4joBcEyXOqT2pJsY/L2D0bvMiROQ=;
	b=oJd2dvZvWt6Y1RW+lv4uW7sNNu6C194MQwTuU/ajMqUADIeQAL36lqsiu1YL0rIT5P
	FHWVk/roAUM/qBZKP3lRVGtwcXyzyDf9q2JjGj/c5XPjHZE8NPIUMc5Dz7qaRGF2N92J
	pl1CqVRY4TiRQnf7Fi3kIAauEvXtwlwjYdesg=
MIME-Version: 1.0
Received: by 10.216.135.194 with SMTP id u44mr5603331wei.40.1327045848687;
	Thu, 19 Jan 2012 23:50:48 -0800 (PST)
Received: by 10.180.101.201 with HTTP; Thu, 19 Jan 2012 23:50:48 -0800 (PST)
Date: Fri, 20 Jan 2012 13:20:48 +0530
Message-ID: <CAO8_4VpeE=A-hMVqtS-F0W47tNrWMpoCqWen2_KeCJCFgCiRyQ@mail.gmail.com>
From: Nupur Ghatnekar <nupurghatnekar@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [Xen-devel] Upstream Qemu 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: multipart/mixed; boundary="===============4568466652076384350=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4568466652076384350==
Content-Type: multipart/alternative; boundary=0016e6d5637a69640404b6f0f0d2

--0016e6d5637a69640404b6f0f0d2
Content-Type: text/plain; charset=UTF-8

Hi,

I am trying to follow the steps given on the xenwiki page
http://wiki.xen.org/xenwiki/QEMUUpstream

I have a couple of doubts:

1) is there any change in the steps if stable xen is currently installed in
the system. I already have a functional xen installed.
2) I tried to follow the steps anyways. But there was no qemu in
/path/ot/qemu/i386-softmmu/ .

these are the contents
root@pratik-desktop:~/backup-virtio-qemu/qemu-upstream-unstable/i386-softmmu#
ls
9pfs                config-devices.mak.old  fpu  Makefile
config-devices.mak  config-target.mak       ide  tcg

Can someone help me out?

-- 

Nupur Ghatnekar

--0016e6d5637a69640404b6f0f0d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I am trying to follow the steps given on the xenwiki page <a hre=
f=3D"http://wiki.xen.org/xenwiki/QEMUUpstream">http://wiki.xen.org/xenwiki/=
QEMUUpstream</a><br><br>I have a couple of doubts:<br><br>1) is there any c=
hange in the steps if stable xen is currently installed in the system. I al=
ready have a functional xen installed.<br>
2) I tried to follow the steps anyways. But there was no qemu in=C2=A0 /pat=
h/ot/qemu/i386-softmmu/ .<br><br>these are the contents<br>root@pratik-desk=
top:~/backup-virtio-qemu/qemu-upstream-unstable/i386-softmmu# ls<br>9pfs=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 config-devices.mak.old=C2=A0 fpu=C2=A0 Makefile<br>
config-devices.mak=C2=A0 config-target.mak=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ide=C2=A0 tcg<br><br>Can someone help me out?<br clear=3D"all"><br>-- <=
br><br>Nupur Ghatnekar<br>

--0016e6d5637a69640404b6f0f0d2--


--===============4568466652076384350==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4568466652076384350==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 07:51:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 07: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 1Ro9FR-0000u5-5g; Fri, 20 Jan 2012 07:50:57 +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 1Ro9FP-0000tx-8x; Fri, 20 Jan 2012 07:50:55 +0000
X-Env-Sender: nupurghatnekar@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327045848!11797565!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12657 invoked from network); 20 Jan 2012 07:50:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 07:50:48 -0000
Received: by werb14 with SMTP id b14so1333040wer.30
	for <multiple recipients>; Thu, 19 Jan 2012 23:50:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=GEVtk8y2gpxvE0Z4joBcEyXOqT2pJsY/L2D0bvMiROQ=;
	b=oJd2dvZvWt6Y1RW+lv4uW7sNNu6C194MQwTuU/ajMqUADIeQAL36lqsiu1YL0rIT5P
	FHWVk/roAUM/qBZKP3lRVGtwcXyzyDf9q2JjGj/c5XPjHZE8NPIUMc5Dz7qaRGF2N92J
	pl1CqVRY4TiRQnf7Fi3kIAauEvXtwlwjYdesg=
MIME-Version: 1.0
Received: by 10.216.135.194 with SMTP id u44mr5603331wei.40.1327045848687;
	Thu, 19 Jan 2012 23:50:48 -0800 (PST)
Received: by 10.180.101.201 with HTTP; Thu, 19 Jan 2012 23:50:48 -0800 (PST)
Date: Fri, 20 Jan 2012 13:20:48 +0530
Message-ID: <CAO8_4VpeE=A-hMVqtS-F0W47tNrWMpoCqWen2_KeCJCFgCiRyQ@mail.gmail.com>
From: Nupur Ghatnekar <nupurghatnekar@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [Xen-devel] Upstream Qemu 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: multipart/mixed; boundary="===============4568466652076384350=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4568466652076384350==
Content-Type: multipart/alternative; boundary=0016e6d5637a69640404b6f0f0d2

--0016e6d5637a69640404b6f0f0d2
Content-Type: text/plain; charset=UTF-8

Hi,

I am trying to follow the steps given on the xenwiki page
http://wiki.xen.org/xenwiki/QEMUUpstream

I have a couple of doubts:

1) is there any change in the steps if stable xen is currently installed in
the system. I already have a functional xen installed.
2) I tried to follow the steps anyways. But there was no qemu in
/path/ot/qemu/i386-softmmu/ .

these are the contents
root@pratik-desktop:~/backup-virtio-qemu/qemu-upstream-unstable/i386-softmmu#
ls
9pfs                config-devices.mak.old  fpu  Makefile
config-devices.mak  config-target.mak       ide  tcg

Can someone help me out?

-- 

Nupur Ghatnekar

--0016e6d5637a69640404b6f0f0d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>I am trying to follow the steps given on the xenwiki page <a hre=
f=3D"http://wiki.xen.org/xenwiki/QEMUUpstream">http://wiki.xen.org/xenwiki/=
QEMUUpstream</a><br><br>I have a couple of doubts:<br><br>1) is there any c=
hange in the steps if stable xen is currently installed in the system. I al=
ready have a functional xen installed.<br>
2) I tried to follow the steps anyways. But there was no qemu in=C2=A0 /pat=
h/ot/qemu/i386-softmmu/ .<br><br>these are the contents<br>root@pratik-desk=
top:~/backup-virtio-qemu/qemu-upstream-unstable/i386-softmmu# ls<br>9pfs=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 config-devices.mak.old=C2=A0 fpu=C2=A0 Makefile<br>
config-devices.mak=C2=A0 config-target.mak=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ide=C2=A0 tcg<br><br>Can someone help me out?<br clear=3D"all"><br>-- <=
br><br>Nupur Ghatnekar<br>

--0016e6d5637a69640404b6f0f0d2--


--===============4568466652076384350==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4568466652076384350==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 08:00:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 08:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro9No-0001KT-RA; Fri, 20 Jan 2012 07:59:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ro9Nn-0001KL-Q4
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 07:59:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327046369!11710645!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9482 invoked from network); 20 Jan 2012 07:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 07:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10170370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:59: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;
	Fri, 20 Jan 2012 07:59:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20120119211430.GT12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
Organization: Citrix Systems, Inc.
Date: Fri, 20 Jan 2012 07:59:28 +0000
Message-ID: <1327046368.21391.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 21:14 +0000, Pasi K=E4rkk=E4inen wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > =

> > Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > must haves e.g. in the paging/sharing spaces?
> > =

> =

> Something that I just remembered:
> http://wiki.xen.org/xenwiki/Xen4.1
> =

> "NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate
> equal amount of memory from every NUMA node for the VM. xm/xend
> allocates all the memory from the same NUMA node."

I'm not that familiar with the NUMA support but my understanding was
that memory was allocated by libxc/the-hypervisor and not by the
toolstack and that the default was to allocate from the same numa nodes
as domains the processor's were pinned to i.e. if you pin the processors
appropriately the Right Thing just happens. Do you believe this is not
the case and/or not working right with xl?

CCing Juergen since he added the cpupool support and in particular the
cpupool-numa-split option so I'm hoping he knows something about NUMA
more generally.

> Is this something that should be looked at?
 =

Probably, but is anyone doing so?

> Should the numa memory allocation be an option so it can be controlled
> per domain? =


What options did xm provide in this regard?

Does xl's cpupool (with the cpupool-numa-split option) server the same
purpose?

> The default libxl behaviour might cause unexpected performance issues
> on multi-socket systems? =


I'm not convinced libxl is behaving any different to xend but perhaps
someone can show me the error of my ways.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 08:00:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 08:00:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro9No-0001KT-RA; Fri, 20 Jan 2012 07:59:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Ro9Nn-0001KL-Q4
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 07:59:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327046369!11710645!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9482 invoked from network); 20 Jan 2012 07:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 07:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10170370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:59: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;
	Fri, 20 Jan 2012 07:59:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
In-Reply-To: <20120119211430.GT12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
Organization: Citrix Systems, Inc.
Date: Fri, 20 Jan 2012 07:59:28 +0000
Message-ID: <1327046368.21391.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
X-Mailer: Evolution 2.32.3 
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-19 at 21:14 +0000, Pasi K=E4rkk=E4inen wrote:
> On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > =

> > Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > must haves e.g. in the paging/sharing spaces?
> > =

> =

> Something that I just remembered:
> http://wiki.xen.org/xenwiki/Xen4.1
> =

> "NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate
> equal amount of memory from every NUMA node for the VM. xm/xend
> allocates all the memory from the same NUMA node."

I'm not that familiar with the NUMA support but my understanding was
that memory was allocated by libxc/the-hypervisor and not by the
toolstack and that the default was to allocate from the same numa nodes
as domains the processor's were pinned to i.e. if you pin the processors
appropriately the Right Thing just happens. Do you believe this is not
the case and/or not working right with xl?

CCing Juergen since he added the cpupool support and in particular the
cpupool-numa-split option so I'm hoping he knows something about NUMA
more generally.

> Is this something that should be looked at?
 =

Probably, but is anyone doing so?

> Should the numa memory allocation be an option so it can be controlled
> per domain? =


What options did xm provide in this regard?

Does xl's cpupool (with the cpupool-numa-split option) server the same
purpose?

> The default libxl behaviour might cause unexpected performance issues
> on multi-socket systems? =


I'm not convinced libxl is behaving any different to xend but perhaps
someone can show me the error of my ways.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 08:16:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 08:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro9dL-00022E-2m; Fri, 20 Jan 2012 08:15: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 1Ro9dJ-000229-RI
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 08:15:38 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327047331!9936449!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDY3NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18246 invoked from network); 20 Jan 2012 08:15:31 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 08:15:31 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id E3A001161;
	Fri, 20 Jan 2012 10:15:29 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 718C0200B0; Fri, 20 Jan 2012 10:15:29 +0200 (EET)
Date: Fri, 20 Jan 2012 10:15:29 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120120081529.GU12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327046368.21391.29.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa
	memory	allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, Jan 20, 2012 at 07:59:28AM +0000, Ian Campbell wrote:
> On Thu, 2012-01-19 at 21:14 +0000, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > =

> > > Has anybody got anything else? I'm sure I've missed stuff. Are there =
any
> > > must haves e.g. in the paging/sharing spaces?
> > > =

> > =

> > Something that I just remembered:
> > http://wiki.xen.org/xenwiki/Xen4.1
> > =

> > "NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate
> > equal amount of memory from every NUMA node for the VM. xm/xend
> > allocates all the memory from the same NUMA node."
> =

> I'm not that familiar with the NUMA support but my understanding was
> that memory was allocated by libxc/the-hypervisor and not by the
> toolstack and that the default was to allocate from the same numa nodes
> as domains the processor's were pinned to i.e. if you pin the processors
> appropriately the Right Thing just happens. Do you believe this is not
> the case and/or not working right with xl?
> =

> CCing Juergen since he added the cpupool support and in particular the
> cpupool-numa-split option so I'm hoping he knows something about NUMA
> more generally.
> =

> > Is this something that should be looked at?
>  =

> Probably, but is anyone doing so?
> =

> > Should the numa memory allocation be an option so it can be controlled
> > per domain? =

> =

> What options did xm provide in this regard?
> =

> Does xl's cpupool (with the cpupool-numa-split option) server the same
> purpose?
> =

> > The default libxl behaviour might cause unexpected performance issues
> > on multi-socket systems? =

> =

> I'm not convinced libxl is behaving any different to xend but perhaps
> someone can show me the error of my ways.
> =



See this thread: =

http://old-list-archives.xen.org/archives/html/xen-devel/2011-07/msg01423.h=
tml

where Stefano wrote:
"I think we forgot about this feature but it is important and hopefully
somebody will write a patch for it before 4.2 is out."


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 08:16:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 08:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Ro9dL-00022E-2m; Fri, 20 Jan 2012 08:15: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 1Ro9dJ-000229-RI
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 08:15:38 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327047331!9936449!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiA0MDY3NTY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18246 invoked from network); 20 Jan 2012 08:15:31 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 08:15:31 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id E3A001161;
	Fri, 20 Jan 2012 10:15:29 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 718C0200B0; Fri, 20 Jan 2012 10:15:29 +0200 (EET)
Date: Fri, 20 Jan 2012 10:15:29 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120120081529.GU12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327046368.21391.29.camel@dagon.hellion.org.uk>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa
	memory	allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, Jan 20, 2012 at 07:59:28AM +0000, Ian Campbell wrote:
> On Thu, 2012-01-19 at 21:14 +0000, Pasi K=E4rkk=E4inen wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > =

> > > Has anybody got anything else? I'm sure I've missed stuff. Are there =
any
> > > must haves e.g. in the paging/sharing spaces?
> > > =

> > =

> > Something that I just remembered:
> > http://wiki.xen.org/xenwiki/Xen4.1
> > =

> > "NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate
> > equal amount of memory from every NUMA node for the VM. xm/xend
> > allocates all the memory from the same NUMA node."
> =

> I'm not that familiar with the NUMA support but my understanding was
> that memory was allocated by libxc/the-hypervisor and not by the
> toolstack and that the default was to allocate from the same numa nodes
> as domains the processor's were pinned to i.e. if you pin the processors
> appropriately the Right Thing just happens. Do you believe this is not
> the case and/or not working right with xl?
> =

> CCing Juergen since he added the cpupool support and in particular the
> cpupool-numa-split option so I'm hoping he knows something about NUMA
> more generally.
> =

> > Is this something that should be looked at?
>  =

> Probably, but is anyone doing so?
> =

> > Should the numa memory allocation be an option so it can be controlled
> > per domain? =

> =

> What options did xm provide in this regard?
> =

> Does xl's cpupool (with the cpupool-numa-split option) server the same
> purpose?
> =

> > The default libxl behaviour might cause unexpected performance issues
> > on multi-socket systems? =

> =

> I'm not convinced libxl is behaving any different to xend but perhaps
> someone can show me the error of my ways.
> =



See this thread: =

http://old-list-archives.xen.org/archives/html/xen-devel/2011-07/msg01423.h=
tml

where Stefano wrote:
"I think we forgot about this feature but it is important and hopefully
somebody will write a patch for it before 4.2 is out."


-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:02:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09: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 1RoAM8-0002xi-VL; Fri, 20 Jan 2012 09: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 1RoAM7-0002xd-Qq
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 09:01:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327050109!11666923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16719 invoked from network); 20 Jan 2012 09:01:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 09:01:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10171240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 09:01: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, 20 Jan 2012 09:01:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Fri, 20 Jan 2012 09:01:48 +0000
In-Reply-To: <20120120081529.GU12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<20120120081529.GU12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327050108.17599.113.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDEyLTAxLTIwIGF0IDA4OjE1ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBGcmksIEphbiAyMCwgMjAxMiBhdCAwNzo1OToyOEFNICswMDAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBPbiBUaHUsIDIwMTItMDEtMTkgYXQgMjE6MTQgKzAwMDAsIFBhc2kgS8Ok
cmtrw6RpbmVuIHdyb3RlOgo+ID4gPiBPbiBXZWQsIEphbiAwNCwgMjAxMiBhdCAwNDoyOToyMlBN
ICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gPiA+ID4gCj4gPiA+ID4gSGFzIGFueWJvZHkg
Z290IGFueXRoaW5nIGVsc2U/IEknbSBzdXJlIEkndmUgbWlzc2VkIHN0dWZmLiBBcmUgdGhlcmUg
YW55Cj4gPiA+ID4gbXVzdCBoYXZlcyBlLmcuIGluIHRoZSBwYWdpbmcvc2hhcmluZyBzcGFjZXM/
Cj4gPiA+ID4gCj4gPiA+IAo+ID4gPiBTb21ldGhpbmcgdGhhdCBJIGp1c3QgcmVtZW1iZXJlZDoK
PiA+ID4gaHR0cDovL3dpa2kueGVuLm9yZy94ZW53aWtpL1hlbjQuMQo+ID4gPiAKPiA+ID4gIk5V
TUEtYXdhcmUgbWVtb3J5IGFsbG9jYXRpb24gZm9yIFZNcy4geGwgaW4gWGVuIDQuMSB3aWxsIGFs
bG9jYXRlCj4gPiA+IGVxdWFsIGFtb3VudCBvZiBtZW1vcnkgZnJvbSBldmVyeSBOVU1BIG5vZGUg
Zm9yIHRoZSBWTS4geG0veGVuZAo+ID4gPiBhbGxvY2F0ZXMgYWxsIHRoZSBtZW1vcnkgZnJvbSB0
aGUgc2FtZSBOVU1BIG5vZGUuIgo+ID4gCj4gPiBJJ20gbm90IHRoYXQgZmFtaWxpYXIgd2l0aCB0
aGUgTlVNQSBzdXBwb3J0IGJ1dCBteSB1bmRlcnN0YW5kaW5nIHdhcwo+ID4gdGhhdCBtZW1vcnkg
d2FzIGFsbG9jYXRlZCBieSBsaWJ4Yy90aGUtaHlwZXJ2aXNvciBhbmQgbm90IGJ5IHRoZQo+ID4g
dG9vbHN0YWNrIGFuZCB0aGF0IHRoZSBkZWZhdWx0IHdhcyB0byBhbGxvY2F0ZSBmcm9tIHRoZSBz
YW1lIG51bWEgbm9kZXMKPiA+IGFzIGRvbWFpbnMgdGhlIHByb2Nlc3NvcidzIHdlcmUgcGlubmVk
IHRvIGkuZS4gaWYgeW91IHBpbiB0aGUgcHJvY2Vzc29ycwo+ID4gYXBwcm9wcmlhdGVseSB0aGUg
UmlnaHQgVGhpbmcganVzdCBoYXBwZW5zLiBEbyB5b3UgYmVsaWV2ZSB0aGlzIGlzIG5vdAo+ID4g
dGhlIGNhc2UgYW5kL29yIG5vdCB3b3JraW5nIHJpZ2h0IHdpdGggeGw/Cj4gPiAKPiA+IENDaW5n
IEp1ZXJnZW4gc2luY2UgaGUgYWRkZWQgdGhlIGNwdXBvb2wgc3VwcG9ydCBhbmQgaW4gcGFydGlj
dWxhciB0aGUKPiA+IGNwdXBvb2wtbnVtYS1zcGxpdCBvcHRpb24gc28gSSdtIGhvcGluZyBoZSBr
bm93cyBzb21ldGhpbmcgYWJvdXQgTlVNQQo+ID4gbW9yZSBnZW5lcmFsbHkuCj4gPiAKPiA+ID4g
SXMgdGhpcyBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgbG9va2VkIGF0Pwo+ID4gIAo+ID4gUHJv
YmFibHksIGJ1dCBpcyBhbnlvbmUgZG9pbmcgc28/Cj4gPiAKPiA+ID4gU2hvdWxkIHRoZSBudW1h
IG1lbW9yeSBhbGxvY2F0aW9uIGJlIGFuIG9wdGlvbiBzbyBpdCBjYW4gYmUgY29udHJvbGxlZAo+
ID4gPiBwZXIgZG9tYWluPyAKPiA+IAo+ID4gV2hhdCBvcHRpb25zIGRpZCB4bSBwcm92aWRlIGlu
IHRoaXMgcmVnYXJkPwo+ID4gCj4gPiBEb2VzIHhsJ3MgY3B1cG9vbCAod2l0aCB0aGUgY3B1cG9v
bC1udW1hLXNwbGl0IG9wdGlvbikgc2VydmVyIHRoZSBzYW1lCj4gPiBwdXJwb3NlPwo+ID4gCj4g
PiA+IFRoZSBkZWZhdWx0IGxpYnhsIGJlaGF2aW91ciBtaWdodCBjYXVzZSB1bmV4cGVjdGVkIHBl
cmZvcm1hbmNlIGlzc3Vlcwo+ID4gPiBvbiBtdWx0aS1zb2NrZXQgc3lzdGVtcz8gCj4gPiAKPiA+
IEknbSBub3QgY29udmluY2VkIGxpYnhsIGlzIGJlaGF2aW5nIGFueSBkaWZmZXJlbnQgdG8geGVu
ZCBidXQgcGVyaGFwcwo+ID4gc29tZW9uZSBjYW4gc2hvdyBtZSB0aGUgZXJyb3Igb2YgbXkgd2F5
cy4KPiA+IAo+IAo+IAo+IFNlZSB0aGlzIHRocmVhZDogCj4gaHR0cDovL29sZC1saXN0LWFyY2hp
dmVzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0wNy9tc2cwMTQyMy5odG1s
Cj4gCj4gd2hlcmUgU3RlZmFubyB3cm90ZToKPiAiSSB0aGluayB3ZSBmb3Jnb3QgYWJvdXQgdGhp
cyBmZWF0dXJlIGJ1dCBpdCBpcyBpbXBvcnRhbnQgYW5kIGhvcGVmdWxseQo+IHNvbWVib2R5IHdp
bGwgd3JpdGUgYSBwYXRjaCBmb3IgaXQgYmVmb3JlIDQuMiBpcyBvdXQuIgoKSXMgYW55b25lIGxv
b2tpbmcgaW50byB0aGlzPwoKRG9lcyBjcHVwb29sLW51bWEtc3BsaXQgc29sdmUgdGhpcyBzYW1l
IHByb2JsZW0/CgpJIHRoaW5rIEkgZm9yZ290IHRvIGFjdHVhbGx5IENDIEp1ZXJnZW4gd2hlbiBJ
IHNhaWQsIGRvaW5nIHRoYXQgbm93LgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:02:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09: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 1RoAM8-0002xi-VL; Fri, 20 Jan 2012 09: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 1RoAM7-0002xd-Qq
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 09:01:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327050109!11666923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4OTE4OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16719 invoked from network); 20 Jan 2012 09:01:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 09:01:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10171240"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 09:01: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, 20 Jan 2012 09:01:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Pasi =?ISO-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
Date: Fri, 20 Jan 2012 09:01:48 +0000
In-Reply-To: <20120120081529.GU12984@reaktio.net>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<20120120081529.GU12984@reaktio.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327050108.17599.113.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDEyLTAxLTIwIGF0IDA4OjE1ICswMDAwLCBQYXNpIEvDpHJra8OkaW5lbiB3cm90
ZToKPiBPbiBGcmksIEphbiAyMCwgMjAxMiBhdCAwNzo1OToyOEFNICswMDAwLCBJYW4gQ2FtcGJl
bGwgd3JvdGU6Cj4gPiBPbiBUaHUsIDIwMTItMDEtMTkgYXQgMjE6MTQgKzAwMDAsIFBhc2kgS8Ok
cmtrw6RpbmVuIHdyb3RlOgo+ID4gPiBPbiBXZWQsIEphbiAwNCwgMjAxMiBhdCAwNDoyOToyMlBN
ICswMDAwLCBJYW4gQ2FtcGJlbGwgd3JvdGU6Cj4gPiA+ID4gCj4gPiA+ID4gSGFzIGFueWJvZHkg
Z290IGFueXRoaW5nIGVsc2U/IEknbSBzdXJlIEkndmUgbWlzc2VkIHN0dWZmLiBBcmUgdGhlcmUg
YW55Cj4gPiA+ID4gbXVzdCBoYXZlcyBlLmcuIGluIHRoZSBwYWdpbmcvc2hhcmluZyBzcGFjZXM/
Cj4gPiA+ID4gCj4gPiA+IAo+ID4gPiBTb21ldGhpbmcgdGhhdCBJIGp1c3QgcmVtZW1iZXJlZDoK
PiA+ID4gaHR0cDovL3dpa2kueGVuLm9yZy94ZW53aWtpL1hlbjQuMQo+ID4gPiAKPiA+ID4gIk5V
TUEtYXdhcmUgbWVtb3J5IGFsbG9jYXRpb24gZm9yIFZNcy4geGwgaW4gWGVuIDQuMSB3aWxsIGFs
bG9jYXRlCj4gPiA+IGVxdWFsIGFtb3VudCBvZiBtZW1vcnkgZnJvbSBldmVyeSBOVU1BIG5vZGUg
Zm9yIHRoZSBWTS4geG0veGVuZAo+ID4gPiBhbGxvY2F0ZXMgYWxsIHRoZSBtZW1vcnkgZnJvbSB0
aGUgc2FtZSBOVU1BIG5vZGUuIgo+ID4gCj4gPiBJJ20gbm90IHRoYXQgZmFtaWxpYXIgd2l0aCB0
aGUgTlVNQSBzdXBwb3J0IGJ1dCBteSB1bmRlcnN0YW5kaW5nIHdhcwo+ID4gdGhhdCBtZW1vcnkg
d2FzIGFsbG9jYXRlZCBieSBsaWJ4Yy90aGUtaHlwZXJ2aXNvciBhbmQgbm90IGJ5IHRoZQo+ID4g
dG9vbHN0YWNrIGFuZCB0aGF0IHRoZSBkZWZhdWx0IHdhcyB0byBhbGxvY2F0ZSBmcm9tIHRoZSBz
YW1lIG51bWEgbm9kZXMKPiA+IGFzIGRvbWFpbnMgdGhlIHByb2Nlc3NvcidzIHdlcmUgcGlubmVk
IHRvIGkuZS4gaWYgeW91IHBpbiB0aGUgcHJvY2Vzc29ycwo+ID4gYXBwcm9wcmlhdGVseSB0aGUg
UmlnaHQgVGhpbmcganVzdCBoYXBwZW5zLiBEbyB5b3UgYmVsaWV2ZSB0aGlzIGlzIG5vdAo+ID4g
dGhlIGNhc2UgYW5kL29yIG5vdCB3b3JraW5nIHJpZ2h0IHdpdGggeGw/Cj4gPiAKPiA+IENDaW5n
IEp1ZXJnZW4gc2luY2UgaGUgYWRkZWQgdGhlIGNwdXBvb2wgc3VwcG9ydCBhbmQgaW4gcGFydGlj
dWxhciB0aGUKPiA+IGNwdXBvb2wtbnVtYS1zcGxpdCBvcHRpb24gc28gSSdtIGhvcGluZyBoZSBr
bm93cyBzb21ldGhpbmcgYWJvdXQgTlVNQQo+ID4gbW9yZSBnZW5lcmFsbHkuCj4gPiAKPiA+ID4g
SXMgdGhpcyBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUgbG9va2VkIGF0Pwo+ID4gIAo+ID4gUHJv
YmFibHksIGJ1dCBpcyBhbnlvbmUgZG9pbmcgc28/Cj4gPiAKPiA+ID4gU2hvdWxkIHRoZSBudW1h
IG1lbW9yeSBhbGxvY2F0aW9uIGJlIGFuIG9wdGlvbiBzbyBpdCBjYW4gYmUgY29udHJvbGxlZAo+
ID4gPiBwZXIgZG9tYWluPyAKPiA+IAo+ID4gV2hhdCBvcHRpb25zIGRpZCB4bSBwcm92aWRlIGlu
IHRoaXMgcmVnYXJkPwo+ID4gCj4gPiBEb2VzIHhsJ3MgY3B1cG9vbCAod2l0aCB0aGUgY3B1cG9v
bC1udW1hLXNwbGl0IG9wdGlvbikgc2VydmVyIHRoZSBzYW1lCj4gPiBwdXJwb3NlPwo+ID4gCj4g
PiA+IFRoZSBkZWZhdWx0IGxpYnhsIGJlaGF2aW91ciBtaWdodCBjYXVzZSB1bmV4cGVjdGVkIHBl
cmZvcm1hbmNlIGlzc3Vlcwo+ID4gPiBvbiBtdWx0aS1zb2NrZXQgc3lzdGVtcz8gCj4gPiAKPiA+
IEknbSBub3QgY29udmluY2VkIGxpYnhsIGlzIGJlaGF2aW5nIGFueSBkaWZmZXJlbnQgdG8geGVu
ZCBidXQgcGVyaGFwcwo+ID4gc29tZW9uZSBjYW4gc2hvdyBtZSB0aGUgZXJyb3Igb2YgbXkgd2F5
cy4KPiA+IAo+IAo+IAo+IFNlZSB0aGlzIHRocmVhZDogCj4gaHR0cDovL29sZC1saXN0LWFyY2hp
dmVzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMS0wNy9tc2cwMTQyMy5odG1s
Cj4gCj4gd2hlcmUgU3RlZmFubyB3cm90ZToKPiAiSSB0aGluayB3ZSBmb3Jnb3QgYWJvdXQgdGhp
cyBmZWF0dXJlIGJ1dCBpdCBpcyBpbXBvcnRhbnQgYW5kIGhvcGVmdWxseQo+IHNvbWVib2R5IHdp
bGwgd3JpdGUgYSBwYXRjaCBmb3IgaXQgYmVmb3JlIDQuMiBpcyBvdXQuIgoKSXMgYW55b25lIGxv
b2tpbmcgaW50byB0aGlzPwoKRG9lcyBjcHVwb29sLW51bWEtc3BsaXQgc29sdmUgdGhpcyBzYW1l
IHByb2JsZW0/CgpJIHRoaW5rIEkgZm9yZ290IHRvIGFjdHVhbGx5IENDIEp1ZXJnZW4gd2hlbiBJ
IHNhaWQsIGRvaW5nIHRoYXQgbm93LgoKSWFuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBs
aXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg2-0003Ua-0w; Fri, 20 Jan 2012 09:22:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnT4B-0006Vk-36
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:48:31 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326883657!50568009!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDQzNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6367 invoked from network); 18 Jan 2012 10:47:39 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 10:47:39 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 16:18:18 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 16:18:12 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0IAmA7T286940
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 16:18:12 +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
	q0IAm9Bn009761
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 16:18:10 +0530
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.124.26])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0IAm9r9009649; Wed, 18 Jan 2012 16:18:09 +0530
Message-ID: <4F16A36B.4050409@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 16:18:11 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>, Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
	<4F13E613.7090602@redhat.com> <4F14B9C7.9090709@goop.org>
In-Reply-To: <4F14B9C7.9090709@goop.org>
x-cbid: 12011810-4790-0000-0000-000000ED153A
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Cc: Greg Kroah-Hartman <gregkh@suse.de>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	Raghavendra <raghavendra.kt@linux.vnet.ibm.com>,
	"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>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 05:29 AM, Jeremy Fitzhardinge wrote:
> On 01/16/2012 07:55 PM, Avi Kivity wrote:
>> On 01/16/2012 08:40 AM, Jeremy Fitzhardinge wrote:
>>>> That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
>>>>
>>>> Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.
>>> I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.
>> The wakeup path is slower though.  The previous lock holder has to
>> hypercall, and the new lock holder has to be scheduled, and transition
>> from halted state to running (a vmentry).  So it's only a clear win if
>> we can do something with the cpu other than go into the idle loop.
>
> Not burning power is a win too.
>
> Actually what you want is something like "if you preempt a VCPU while
> its spinning in a lock, then push it into the slowpath and don't
> reschedule it without a kick".  But I think that interface would have a
> lot of fiddly corners.
>

Yes wakeup path is little slower but better than burning cpu. no?

Suppose we have  16 vcpu,
vcpu 1- lockholder (preempted).
vcpu 2-8 - in slowpath.

If scheduler schedules vcpu-1 that is most favourable for lock progress,
But if vcpu-9 - vcpu-16 OR something else scheduled, then  also it's a 
win right (we are doing some useful work), but yes lock progress is
again little slower though.

The optimization areas of interests are perhaps:
(1) suppose vcpu-1 is running and is about to release lock and next
vcpu in queue just goes to halt(). so this makes us to tune 
SPIN_THRESHOLD rightly and have a mechanism to determine if lock-holder 
is running and do continue spin. Identifying whether lock-holder is 
running would be easier task and can be next step of optimization.

(2) Much talked, identifying lockholder-preemption (vcpu) and do
yield_to().

But I am not sure how complicated is yield_to() implementation once we 
have identified the exact preempted vcpu (lock-holder).

>      J
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg2-0003Ua-0w; Fri, 20 Jan 2012 09:22:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raghavendra.kt@linux.vnet.ibm.com>)
	id 1RnT4B-0006Vk-36
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 10:48:31 +0000
X-Env-Sender: raghavendra.kt@linux.vnet.ibm.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1326883657!50568009!1
X-Originating-IP: [122.248.162.1]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTIyLjI0OC4xNjIuMSA9PiAyMDQzNDc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6367 invoked from network); 18 Jan 2012 10:47:39 -0000
Received: from e28smtp01.in.ibm.com (HELO e28smtp01.in.ibm.com) (122.248.162.1)
	by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 10:47:39 -0000
Received: from /spool/local
	by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use
	Only! Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from
	<raghavendra.kt@linux.vnet.ibm.com>; Wed, 18 Jan 2012 16:18:18 +0530
Received: from d28relay02.in.ibm.com (9.184.220.59)
	by e28smtp01.in.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 16:18:12 +0530
Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63])
	by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0IAmA7T286940
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 16:18:12 +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
	q0IAm9Bn009761
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 16:18:10 +0530
Received: from oc5400248562.ibm.com (oc5400248562.in.ibm.com [9.124.124.26])
	by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0IAm9r9009649; Wed, 18 Jan 2012 16:18:09 +0530
Message-ID: <4F16A36B.4050409@linux.vnet.ibm.com>
Date: Wed, 18 Jan 2012 16:18:11 +0530
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jeremy Fitzhardinge <jeremy@goop.org>, Avi Kivity <avi@redhat.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<3EC1B881-0724-49E3-B892-F40BEB07D15D@suse.de>
	<03D10A71-19F8-4278-B7A4-3F618ED6ECF0@goop.org>
	<4F13E613.7090602@redhat.com> <4F14B9C7.9090709@goop.org>
In-Reply-To: <4F14B9C7.9090709@goop.org>
x-cbid: 12011810-4790-0000-0000-000000ED153A
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Cc: Greg Kroah-Hartman <gregkh@suse.de>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	Raghavendra <raghavendra.kt@linux.vnet.ibm.com>,
	"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>,
	Rob Landley <rlandley@parallels.com>, X86 <x86@kernel.org>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>, Sedat Dilek <sedat.dilek@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	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>,
	Glauber Costa <glommer@redhat.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 0/5] kvm : Paravirt-spinlock support
	for KVM guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/17/2012 05:29 AM, Jeremy Fitzhardinge wrote:
> On 01/16/2012 07:55 PM, Avi Kivity wrote:
>> On 01/16/2012 08:40 AM, Jeremy Fitzhardinge wrote:
>>>> That means we're spinning for n cycles, then notify the spinlock holder that we'd like to get kicked and go sleeping. While I'm pretty sure that it improves the situation, it doesn't solve all of the issues we have.
>>>>
>>>> Imagine we have an idle host. All vcpus can freely run and everyone can fetch the lock as fast as on real machines. We don't need to / want to go to sleep here. Locks that take too long are bugs that need to be solved on real hw just as well, so all we do is possibly incur overhead.
>>> I'm not quite sure what your concern is.  The lock is under contention, so there's nothing to do except spin; all this patch adds is a variable decrement/test to the spin loop, but that's not going to waste any more CPU than the non-counting case.  And once it falls into the blocking path, its a win because the VCPU isn't burning CPU any more.
>> The wakeup path is slower though.  The previous lock holder has to
>> hypercall, and the new lock holder has to be scheduled, and transition
>> from halted state to running (a vmentry).  So it's only a clear win if
>> we can do something with the cpu other than go into the idle loop.
>
> Not burning power is a win too.
>
> Actually what you want is something like "if you preempt a VCPU while
> its spinning in a lock, then push it into the slowpath and don't
> reschedule it without a kick".  But I think that interface would have a
> lot of fiddly corners.
>

Yes wakeup path is little slower but better than burning cpu. no?

Suppose we have  16 vcpu,
vcpu 1- lockholder (preempted).
vcpu 2-8 - in slowpath.

If scheduler schedules vcpu-1 that is most favourable for lock progress,
But if vcpu-9 - vcpu-16 OR something else scheduled, then  also it's a 
win right (we are doing some useful work), but yes lock progress is
again little slower though.

The optimization areas of interests are perhaps:
(1) suppose vcpu-1 is running and is about to release lock and next
vcpu in queue just goes to halt(). so this makes us to tune 
SPIN_THRESHOLD rightly and have a mechanism to determine if lock-holder 
is running and do continue spin. Identifying whether lock-holder is 
running would be easier task and can be next step of optimization.

(2) Much talked, identifying lockholder-preemption (vcpu) and do
yield_to().

But I am not sure how complicated is yield_to() implementation once we 
have identified the exact preempted vcpu (lock-holder).

>      J
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg2-0003Uh-D0; Fri, 20 Jan 2012 09:22:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <norbert.marx@ckmn.de>) id 1RnUub-0005bt-7N
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 12:46:45 +0000
X-Env-Sender: norbert.marx@ckmn.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326890799!9634267!1
X-Originating-IP: [188.122.71.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8584 invoked from network); 18 Jan 2012 12:46:39 -0000
Received: from snl04.coani.net (HELO snl04.coani.net) (188.122.71.37)
	by server-8.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 12:46:39 -0000
Received: from localhost (localhost [127.0.0.1])
	by snl04.coani.net (Postfix) with ESMTP id 4DE1B13E
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 13:46:01 +0100 (CET)
X-Virus-Scanned: amavisd-new at coani.net
Received: from snl04.coani.net ([127.0.0.1])
	by localhost (snl02.coani.net [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id A-LsUDdF13Pd for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 13:45:55 +0100 (CET)
Received: from localhost (static-91-187-75-173.ad [91.187.75.173])
	by snl04.coani.net (Postfix) with ESMTPSA id 7D986125
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 13:45:55 +0100 (CET)
From: Norbert Marx <norbert.marx@ckmn.de>
To: xen-devel@lists.xensource.com
Date: Wed, 18 Jan 2012 13:46:29 +0100
Message-ID: <3163948.Ai5Fh6ZPuS@pc10>
Organization: privat
User-Agent: KMail/4.7.3 (Linux/3.1.7-gentoo-Dom0; KDE/4.7.3; x86_64; ; )
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Subject: Re: [Xen-devel] why do I get bad disk write performance in the
	kernel 3.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

Hello,

I have the same problem and filed a bug: 
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1801

[...]
> > I'm execute with file:/, but in xenstore-list, continue with qdisk.
> 
> Please try using losetup to bind your file to /dev/loopN and specifying
> phy:/dev/loopN in your config. That should get you blkback.
> 
> [...]
> > I try with "file://" and result was qdisk again. Do you think is LVM
> > test need?
> 
> That would also be interesting.

With this hints I modified libxl__try_phy_backend and the result was vbd now. 
But something es does not work with /etc/xen/scripts/block. All details can be 
find at http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1801.

regards,
Norbert

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg2-0003Uh-D0; Fri, 20 Jan 2012 09:22:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <norbert.marx@ckmn.de>) id 1RnUub-0005bt-7N
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 12:46:45 +0000
X-Env-Sender: norbert.marx@ckmn.de
X-Msg-Ref: server-8.tower-174.messagelabs.com!1326890799!9634267!1
X-Originating-IP: [188.122.71.37]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8584 invoked from network); 18 Jan 2012 12:46:39 -0000
Received: from snl04.coani.net (HELO snl04.coani.net) (188.122.71.37)
	by server-8.tower-174.messagelabs.com with SMTP;
	18 Jan 2012 12:46:39 -0000
Received: from localhost (localhost [127.0.0.1])
	by snl04.coani.net (Postfix) with ESMTP id 4DE1B13E
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 13:46:01 +0100 (CET)
X-Virus-Scanned: amavisd-new at coani.net
Received: from snl04.coani.net ([127.0.0.1])
	by localhost (snl02.coani.net [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id A-LsUDdF13Pd for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 13:45:55 +0100 (CET)
Received: from localhost (static-91-187-75-173.ad [91.187.75.173])
	by snl04.coani.net (Postfix) with ESMTPSA id 7D986125
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 13:45:55 +0100 (CET)
From: Norbert Marx <norbert.marx@ckmn.de>
To: xen-devel@lists.xensource.com
Date: Wed, 18 Jan 2012 13:46:29 +0100
Message-ID: <3163948.Ai5Fh6ZPuS@pc10>
Organization: privat
User-Agent: KMail/4.7.3 (Linux/3.1.7-gentoo-Dom0; KDE/4.7.3; x86_64; ; )
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Subject: Re: [Xen-devel] why do I get bad disk write performance in the
	kernel 3.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

Hello,

I have the same problem and filed a bug: 
http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1801

[...]
> > I'm execute with file:/, but in xenstore-list, continue with qdisk.
> 
> Please try using losetup to bind your file to /dev/loopN and specifying
> phy:/dev/loopN in your config. That should get you blkback.
> 
> [...]
> > I try with "file://" and result was qdisk again. Do you think is LVM
> > test need?
> 
> That would also be interesting.

With this hints I modified libxl__try_phy_backend and the result was vbd now. 
But something es does not work with /etc/xen/scripts/block. All details can be 
find at http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1801.

regards,
Norbert

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:22:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg3-0003Uv-4J; Fri, 20 Jan 2012 09:22:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RndQo-0001oF-CH
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 21:52:34 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326923546!9101279!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21373 invoked from network); 18 Jan 2012 21:52:28 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 21:52:28 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 5602994AE;
	Wed, 18 Jan 2012 13:52:24 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 56910203E4;
	Thu, 19 Jan 2012 08:52:15 +1100 (EST)
Message-ID: <4F173F0F.5020604@goop.org>
Date: Thu, 19 Jan 2012 08:52:15 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
	<4F1621B2.3020203@goop.org>
	<20120118135445.GB25711@linux.vnet.ibm.com>
In-Reply-To: <20120118135445.GB25711@linux.vnet.ibm.com>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Cc: X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/19/2012 12:54 AM, Srivatsa Vaddagiri wrote:
>
>> That logic relies on the "kick" being level triggered, so that "kick"
>> before "block" will cause the block to fall out immediately.  If you're
>> using "hlt" as the block and it has the usual edge-triggered behaviour,
>> what stops a "kick-before-hlt" from losing the kick?
> Hmm ..'hlt' should result in a check for kick request (in hypervisor
> context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
> will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check 
> before it puts vcpu0 to sleep because of trapped 'hlt' instruction.
>
> Won't that trap the 'kick-before-hlt' case? What am I missing here?

Nothing, that sounds fine.  It wasn't clear to me that your kick
operation left persistent state, and so has a level-triggered effect on hlt.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:22:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg3-0003Uv-4J; Fri, 20 Jan 2012 09:22:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RndQo-0001oF-CH
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 21:52:34 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-13.tower-21.messagelabs.com!1326923546!9101279!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21373 invoked from network); 18 Jan 2012 21:52:28 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 18 Jan 2012 21:52:28 -0000
Received: from saboo.goop.org (114-198-82-82.dyn.iinet.net.au [114.198.82.82])
	(Authenticated sender: smtp-saboo)
	by claw.goop.org (Postfix) with ESMTPSA id 5602994AE;
	Wed, 18 Jan 2012 13:52:24 -0800 (PST)
Received: from saboo.goop.org (localhost [IPv6:::1])
	by saboo.goop.org (Postfix) with ESMTP id 56910203E4;
	Thu, 19 Jan 2012 08:52:15 +1100 (EST)
Message-ID: <4F173F0F.5020604@goop.org>
Date: Thu, 19 Jan 2012 08:52:15 +1100
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
	<4F1621B2.3020203@goop.org>
	<20120118135445.GB25711@linux.vnet.ibm.com>
In-Reply-To: <20120118135445.GB25711@linux.vnet.ibm.com>
X-Enigmail-Version: 1.3.4
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Cc: X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/19/2012 12:54 AM, Srivatsa Vaddagiri wrote:
>
>> That logic relies on the "kick" being level triggered, so that "kick"
>> before "block" will cause the block to fall out immediately.  If you're
>> using "hlt" as the block and it has the usual edge-triggered behaviour,
>> what stops a "kick-before-hlt" from losing the kick?
> Hmm ..'hlt' should result in a check for kick request (in hypervisor
> context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
> will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check 
> before it puts vcpu0 to sleep because of trapped 'hlt' instruction.
>
> Won't that trap the 'kick-before-hlt' case? What am I missing here?

Nothing, that sounds fine.  It wasn't clear to me that your kick
operation left persistent state, and so has a level-triggered effect on hlt.

    J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:22:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg2-0003Uo-Oa; Fri, 20 Jan 2012 09:22:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RnVzB-0007Hi-SD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 13:55:34 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326894925!9497894!1
X-Originating-IP: [32.97.110.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MSA9PiAzNjkyODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32397 invoked from network); 18 Jan 2012 13:55:27 -0000
Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jan 2012 13:55:27 -0000
Received: from /spool/local
	by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Wed, 18 Jan 2012 06:55:25 -0700
Received: from d03dlp01.boulder.ibm.com (9.17.202.177)
	by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 06:54:59 -0700
Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147])
	by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 512FF1FF004F
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 06:54:57 -0700 (MST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0IDsv1X3203122
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 08:54:57 -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
	q0IDssKU022349
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 08:54:57 -0500
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.124.35.132])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0IDskxk021771; Wed, 18 Jan 2012 08:54:47 -0500
Date: Wed, 18 Jan 2012 19:24:46 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <20120118135445.GB25711@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
	<4F1621B2.3020203@goop.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1621B2.3020203@goop.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011813-2398-0000-0000-0000037C2882
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Cc: X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Jeremy Fitzhardinge <jeremy@goop.org> [2012-01-18 12:34:42]:

> >> What prevents a kick from being lost here, if say, the waiter is at
> >> local_irq_save in kvm_lock_spinning, before the lock/want assignments?
> > The waiter does check for lock becoming available before actually
> > sleeping:
> >
> > +	/*
> > +        * 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;
> > +	}
> 
> That logic relies on the "kick" being level triggered, so that "kick"
> before "block" will cause the block to fall out immediately.  If you're
> using "hlt" as the block and it has the usual edge-triggered behaviour,
> what stops a "kick-before-hlt" from losing the kick?

Hmm ..'hlt' should result in a check for kick request (in hypervisor
context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check 
before it puts vcpu0 to sleep because of trapped 'hlt' instruction.

Won't that trap the 'kick-before-hlt' case? What am I missing here?

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:22:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:22:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg2-0003Uo-Oa; Fri, 20 Jan 2012 09:22:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vatsa@linux.vnet.ibm.com>) id 1RnVzB-0007Hi-SD
	for xen-devel@lists.xensource.com; Wed, 18 Jan 2012 13:55:34 +0000
X-Env-Sender: vatsa@linux.vnet.ibm.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1326894925!9497894!1
X-Originating-IP: [32.97.110.151]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1MSA9PiAzNjkyODk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32397 invoked from network); 18 Jan 2012 13:55:27 -0000
Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 18 Jan 2012 13:55:27 -0000
Received: from /spool/local
	by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <vatsa@linux.vnet.ibm.com>;
	Wed, 18 Jan 2012 06:55:25 -0700
Received: from d03dlp01.boulder.ibm.com (9.17.202.177)
	by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Wed, 18 Jan 2012 06:54:59 -0700
Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147])
	by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 512FF1FF004F
	for <xen-devel@lists.xensource.com>;
	Wed, 18 Jan 2012 06:54:57 -0700 (MST)
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0IDsv1X3203122
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 08:54:57 -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
	q0IDssKU022349
	for <xen-devel@lists.xensource.com>; Wed, 18 Jan 2012 08:54:57 -0500
Received: from linux.vnet.ibm.com (snowy-tp.in.ibm.com [9.124.35.132])
	by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id
	q0IDskxk021771; Wed, 18 Jan 2012 08:54:47 -0500
Date: Wed, 18 Jan 2012 19:24:46 +0530
From: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Message-ID: <20120118135445.GB25711@linux.vnet.ibm.com>
References: <20120114182501.8604.68416.sendpatchset@oc5400248562.ibm.com>
	<20120114182645.8604.68884.sendpatchset@oc5400248562.ibm.com>
	<20120117110210.GA17420@amt.cnet>
	<20120117113312.GB30398@linux.vnet.ibm.com>
	<4F1621B2.3020203@goop.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1621B2.3020203@goop.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12011813-2398-0000-0000-0000037C2882
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Cc: X86 <x86@kernel.org>, Gleb Natapov <gleb@redhat.com>,
	linux-doc@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Randy Dunlap <rdunlap@xenotime.net>, Paul Mackerras <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Xen <xen-devel@lists.xensource.com>,
	Dave Jiang <dave.jiang@intel.com>, KVM <kvm@vger.kernel.org>,
	Glauber Costa <glommer@redhat.com>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Alexander Graf <agraf@suse.de>, Ingo Molnar <mingo@redhat.com>,
	Avi Kivity <avi@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Greg Kroah-Hartman <gregkh@suse.de>, Sasha Levin <levinsasha928@gmail.com>,
	Sedat Dilek <sedat.dilek@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
	Marcelo Tosatti <mtosatti@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	Suzuki Poulose <suzuki@linux.vnet.ibm.com>,
	Rob Landley <rlandley@parallels.com>
Subject: Re: [Xen-devel] [PATCH RFC V4 4/5] kvm : pv-ticketlocks support for
 linux guests running on KVM hypervisor
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* Jeremy Fitzhardinge <jeremy@goop.org> [2012-01-18 12:34:42]:

> >> What prevents a kick from being lost here, if say, the waiter is at
> >> local_irq_save in kvm_lock_spinning, before the lock/want assignments?
> > The waiter does check for lock becoming available before actually
> > sleeping:
> >
> > +	/*
> > +        * 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;
> > +	}
> 
> That logic relies on the "kick" being level triggered, so that "kick"
> before "block" will cause the block to fall out immediately.  If you're
> using "hlt" as the block and it has the usual edge-triggered behaviour,
> what stops a "kick-before-hlt" from losing the kick?

Hmm ..'hlt' should result in a check for kick request (in hypervisor
context) before vcpu is put to sleep. IOW vcpu1 that is attempting to kick vcpu0
will set a 'somebody_tried_kicking_vcpu0' flag, which hypervisor should check 
before it puts vcpu0 to sleep because of trapped 'hlt' instruction.

Won't that trap the 'kick-before-hlt' case? What am I missing here?

- vatsa


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:23:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg3-0003V2-GX; Fri, 20 Jan 2012 09:22:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <blp@cs.stanford.edu>) id 1RnkjS-0006iN-Uh
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 05:40:19 +0000
X-Env-Sender: blp@cs.stanford.edu
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326951612!11596593!1
X-Originating-IP: [62.13.148.154]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTMuMTQ4LjE1NCA9PiAxMjUzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24441 invoked from network); 19 Jan 2012 05:40:12 -0000
Received: from outmail148154.authsmtp.co.uk (HELO
	outmail148154.authsmtp.co.uk) (62.13.148.154)
	by server-11.tower-216.messagelabs.com with SMTP;
	19 Jan 2012 05:40:12 -0000
Received: from mail-c193.authsmtp.com (mail-c193.authsmtp.com [62.13.128.118])
	by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	q0J5eAk7079002; Thu, 19 Jan 2012 05:40:10 GMT
Received: from blp.benpfaff.org (76-14-48-202.sf-cable.astound.net
	[76.14.48.202] (may be forged)) (authenticated bits=0)
	by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id q0J5e6TT031834
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 19 Jan 2012 05:40:07 GMT
Received: from blp by blp.benpfaff.org with local (Exim 4.72)
	(envelope-from <blp@cs.stanford.edu>)
	id 1RnkeK-0004rl-1a; Wed, 18 Jan 2012 21:35:00 -0800
From: Ben Pfaff <blp@cs.stanford.edu>
To: Vijay Chander <vijay.chander@gmail.com>
References: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>
	<CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
Date: Wed, 18 Jan 2012 21:35:00 -0800
In-Reply-To: <CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
	(Vijay Chander's message of "Wed, 18 Jan 2012 21:15:34 -0800")
Message-ID: <87wr8o9rwb.fsf@blp.benpfaff.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
X-Server-Quench: 0bcd6216-4260-11e1-97bb-002264978518
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCdwYQ8QAVZfSBwy AThCFzNJTwsiPBEK DBMeOw5HJEYITQBc
	chwbOAMCd38VQxYD A2cJS1RRWllxU2N9 JQ1XcwRZfE5GQQdq
	UldLR1BXCwQmQBx7 A0sYNn1ydAROe3o+ ZENlVnMVXBYpIUB/
	Q0hJEW8AZXphaTUe TUlfJVFJcANIfBlB Y1d3UXIFLwdSbGoo
	Egl7fHg2JThZNj9K Qx0GLToA
X-Authentic-SMTP: 61633331373532.1014:706
X-AuthFastPath: 0 (Was 255)
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen + openvswitch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ben Pfaff <blp@cs.stanford.edu>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VmlqYXkgQ2hhbmRlciA8dmlqYXkuY2hhbmRlckBnbWFpbC5jb20+IHdyaXRlczoKCj4gT24gV2Vk
LCBKYW4gMTgsIDIwMTIgYXQgOToxNCBQTSwgVmlqYXkgQ2hhbmRlciA8dmlqYXkuY2hhbmRlckBn
bWFpbC5jb20+Cj4gd3JvdGU6Cj4KPiAgICAgSGFzIGFueW9uZSBzZWVuIHBlcmZvcm1hbmNlIGlz
c3VlcyB3aXRoIHhlbiA0LjEuMCAodGhlIG9uZSB1c2VkIGluCj4gICAgIHhlbmNlbnRlciA2LjAp
wqAKPiAgICAgdXNpbmcgb3BlbiB2c3dpdGNoIGFzIG9wcG9zZWQgdG8gbmF0aXZlIGxpbnV4IGJy
aWRnZSA/Cj4gICAgCj4gICAgIFdlIGFyZSB0dXNzbGluZyB3aXRoIG5lZWRpbmcgdGhlIHN1cHBv
cnQgZ3Vlc3QgdmxhbiB0YWdnaW5nIGFuZAo+ICAgICBwZXJmb3JtYW5jZS4KClhlblNlcnZlciA2
LjAuMCBzaGlwcGVkIHdpdGggYW4gT3BlbiB2U3dpdGNoIGJ1aWxkIHRoYXQgY29udGFpbmVkCmEg
c2VyaW91cyBWTEFOIHBlcmZvcm1hbmNlIGJ1Zy4gIEl0IGlzIGZpeGVkIG9uIHRoZSBPcGVuIHZT
d2l0Y2gKInZsYW4tbWFpbnQiIGJyYW5jaC4gIFRoZSBmaXggc2hvdWxkIGFsc28gYXBwZWFyIGlu
IHRoZSBuZXh0ClhlblNlcnZlciByZWxlYXNlLgoKSGVyZSBpcyB0aGUgT3BlbiB2U3dpdGNoIGNv
bW1pdCB0aGF0IGZpeGVkIHRoZSBwcm9ibGVtLgoKLS04PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tY3V0IGhlcmUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT44LS0KCkZyb206IEJlbiBQZmFm
ZiA8YmxwQG5pY2lyYS5jb20+CkRhdGU6IFdlZCwgMjMgTWFyIDIwMTEgMTA6MzQ6MzcgLTA3MDAK
U3ViamVjdDogW1BBVENIXSBkYXRhcGF0aDogQWRkIGNvbXBhdGliaWxpdHkgd2l0aCBza19idWZm
J3Mgdmxhbl90Y2kgYmVmb3JlIDIuNi4zMy4KCkJldHdlZW4gMi42LjI3IGFuZCAyLjYuMzIsIHRo
ZSB2bGFuX3RjaSBtZW1iZXIgb2Ygc3RydWN0IHNrX2J1ZmYgd2FzIHRoZQpyYXcgdmFsdWUgb2Yg
dGhlIDgwMi4xUSBoZWFkZXIncyBUQ0kgZmllbGQsIHdpdGhvdXQgdGhlIENGSSBiaXQgYmVpbmcg
c2V0LgpJbiAyLjYuMzMgYW5kIGxhdGVyLCB0aGUgQ0ZJIGJpdCBpcyBhbHdheXMgc2V0IGlmIGFu
IDgwMi4xUSBoZWFkZXIgaXMKcHJlc2VudCwgY29ycmVjdGluZyBhIGNvcm5lciBjYXNlLgoKVW50
aWwgbm93LCBPVlMgaGFzIG5vdCBjb25zaXN0ZW50bHkgZGVhbHQgd2l0aCB0aGlzLiAgSWYgYSBw
YWNrZXQgYXJyaXZlZAphdCBhIGRhdGFwYXRoIGZyb20gYSBuZXR3b3JrIGRldmljZSBkaXJlY3Rs
eSwgb3IgaWYgaXQgd2FzIHNldCB3aXRoIGFuCk9EUF9BQ1RJT05fQVRUUl9TRVRfRExfVENJIGFj
dGlvbiwgdGhlbiB0aGUgQ0ZJIGJpdCB3b3VsZCBub3QgYmUgc2V0IGluCnZsYW5fdGNpLiAgSW4g
Zmxvd19leHRyYWN0KCksIE9WUyBjb3BpZXMgdmxhbl90Y2kgZGlyZWN0bHkgdG8gZGxfdGNpIGlu
IHRoZQpmbG93IHN0cnVjdHVyZSAodmlhIHZsYW5fZ2V0X3RjaSgpKSwgc28gdGhlIENGSSBiaXQg
d291bGQgYWxzbyBub3QgYmUgc2V0CmluIGRsX3RjaS4gIEJ1dCBpZiBPVlMgaGFkIHRvIHNlbmQg
YSBwYWNrZXQgdXAgdG8gdXNlcnNwYWNlIChjb252ZXJ0aW5nIHRoZQp2bGFuX3RjaSBiYWNrIHRv
IGFuIDgwMi4xUSBoZWFkZXIgYWxvbmcgdGhlIHdheSkgYW5kIGdvdCBpdCBiYWNrLCB0aGVuIGl0
CndvdWxkIHNldCB0aGUgVkxBTiBDRkkgYml0IGluIGRsX3RjaSB3aGVuIGl0IHBhcnNlZCB0aGUg
ODAyLjFRIGhlYWRlciBpbgpwYXJzZV92bGFuKCkuICBUaGlzIGhhZCB0aGUgZWZmZWN0IHRoYXQg
YSBmbG93IHNldCB1cCBieSB1c2Vyc3BhY2UgKHdpdGgKdGhlIENGSSBiaXQgc2V0KSB3b3VsZCBu
ZXZlciBiZSBtYXRjaGVkIGJ5IGEgcGFja2V0IGFycml2aW5nIGZyb20gYSBuZXR3b3JrCmRldmlj
ZSwgYmVjYXVzZSB0aGV5IHdvdWxkIGhhdmUgZGlmZmVyZW50IGRsX3RjaSB2YWx1ZXMuCgpUaGlz
IGZpeGVzIHRoZSBwcm9ibGVtLCBieSBtYWtpbmcgdGhlIHZsYW5fZ2V0X3RjaSgpIGFuZCB2bGFu
X3NldF90Y2koKQppbnRlcmZhY2UgY29uc2lzdGVudCBhY3Jvc3Mga2VybmVsIHZlcnNpb25zLiAg
Tm93LCB0aGV5IGFsd2F5cyBhY2NlcHQgb3IKcmV0dXJuIGEgdmFsdWUgd2hlcmUgdGhlIFZMQU4g
Q0ZJIGJpdCBpcyBzZXQgaWYgYW4gODAyLjFRIGhlYWRlciBpcwpwcmVzZW50LgoKQnVpbGQtdGVz
dGVkIG9ubHkuCgpQcm9ibGVtIGlzb2xhdGVkIGJ5IEV0aGFuIEphY2tzb24gPGV0aGFuQG5pY2ly
YS5jb20+CgpTaWduZWQtb2ZmLWJ5OiBCZW4gUGZhZmYgPGJscEBuaWNpcmEuY29tPgpBY2tlZC1i
eTogSmVzc2UgR3Jvc3MgPGplc3NlQG5pY2lyYS5jb20+ClJlcG9ydGVkLWJ5OiBSYW0gSm90aGlr
dW1hciA8cmpvdGhpa3VtYXJAbmljaXJhLmNvbT4KQnVnICM0OTE1LgotLS0KIGRhdGFwYXRoL3Zs
YW4uaCB8ICAgMzAgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGVzIGNoYW5n
ZWQsIDMwIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZGF0YXBh
dGgvdmxhbi5oIGIvZGF0YXBhdGgvdmxhbi5oCmluZGV4IDAyYTYyOTAuLjdlMTA4NGUgMTAwNjQ0
Ci0tLSBhL2RhdGFwYXRoL3ZsYW4uaAorKysgYi9kYXRhcGF0aC92bGFuLmgKQEAgLTEzLDYgKzEz
LDI5IEBACiAjaW5jbHVkZSA8bGludXgvc2tidWZmLmg+CiAjaW5jbHVkZSA8bGludXgvdmVyc2lv
bi5oPgogCisvKioKKyAqIERPQzogVkxBTiB0YWcgbWFuaXB1bGF0aW9uLgorICoKKyAqICZzdHJ1
Y3Qgc2tfYnVmZiBoYW5kbGluZyBvZiBWTEFOIHRhZ3MgaGFzIGV2b2x2ZWQgb3ZlciB0aW1lOgor
ICoKKyAqIEluIDIuNi4yNiBhbmQgZWFybGllciwgVkxBTiB0YWdzIGRpZCBub3QgaGF2ZSBhbnkg
Z2VuZXJpYyByZXByZXNlbnRhdGlvbiBpbgorICogYW4gc2tiLCBvdGhlciB0aGFuIGFzIGEgcmF3
IDgwMi4xUSBoZWFkZXIgaW5zaWRlIHRoZSBwYWNrZXQgZGF0YS4KKyAqCisgKiBJbiAyLjYuMjcg
JnN0cnVjdCBza19idWZmIGFkZGVkIGEgQHZsYW5fdGNpIG1lbWJlci4gIEJldHdlZW4gMi42LjI3
IGFuZAorICogMi42LjMyLCBpdHMgdmFsdWUgd2FzIHRoZSByYXcgY29udGVudHMgb2YgdGhlIDgw
Mi4xUSBUQ0kgZmllbGQsIG9yIHplcm8gaWYKKyAqIG5vIDgwMi4xUSBoZWFkZXIgd2FzIHByZXNl
bnQuICBUaGlzIHdvcmtlZCBPSyBleGNlcHQgZm9yIHRoZSBjb3JuZXIgY2FzZSBvZgorICogYW4g
ODAyLjFRIGhlYWRlciB3aXRoIGFuIGFsbC0wLWJpdHMgVENJLCB3aGljaCBjb3VsZCBub3QgYmUg
cmVwcmVzZW50ZWQuCisgKgorICogSW4gMi42LjMzLCBAdmxhbl90Y2kgc2VtYW50aWNzIGNoYW5n
ZWQuICBOb3csIGlmIGFuIDgwMi4xUSBoZWFkZXIgaXMKKyAqIHByZXNlbnQsIHRoZW4gdGhlIFZM
QU5fVEFHX1BSRVNFTlQgYml0IGlzIGFsd2F5cyBzZXQuICBUaGlzIGZpeGVzIHRoZQorICogYWxs
LTAtYml0cyBUQ0kgY29ybmVyIGNhc2UuCisgKgorICogRm9yIGNvbXBhdGliaWxpdHkgd2UgZW11
bGF0ZSB0aGUgMi42LjMzKyBiZWhhdmlvciBvbiBlYXJsaWVyIGtlcm5lbAorICogdmVyc2lvbnMu
ICBUaGUgY2xpZW50IG11c3Qgbm90IGFjY2VzcyBAdmxhbl90Y2kgZGlyZWN0bHkuICBJbnN0ZWFk
LCB1c2UKKyAqIHZsYW5fZ2V0X3RjaSgpIHRvIHJlYWQgaXQgb3Igdmxhbl9zZXRfdGNpKCkgdG8g
d3JpdGUgaXQsIHdpdGggc2VtYW50aWNzCisgKiBlcXVpdmFsZW50IHRvIHRob3NlIG9uIDIuNi4z
MysuCisgKi8KKwogI2lmIExJTlVYX1ZFUlNJT05fQ09ERSA8IEtFUk5FTF9WRVJTSU9OKDIsNiwy
NykKICNkZWZpbmUgTkVFRF9WTEFOX0ZJRUxECiAjZW5kaWYKQEAgLTIyLDExICs0NSwxOCBAQCBz
dGF0aWMgaW5saW5lIHZvaWQgdmxhbl9jb3B5X3NrYl90Y2koc3RydWN0IHNrX2J1ZmYgKnNrYikg
eyB9CiAKIHN0YXRpYyBpbmxpbmUgdTE2IHZsYW5fZ2V0X3RjaShzdHJ1Y3Qgc2tfYnVmZiAqc2ti
KQogeworI2lmIExJTlVYX1ZFUlNJT05fQ09ERSA8IEtFUk5FTF9WRVJTSU9OKDIsNiwzMykKKwlp
ZiAoc2tiLT52bGFuX3RjaSkKKwkJcmV0dXJuIHNrYi0+dmxhbl90Y2kgfCBWTEFOX1RBR19QUkVT
RU5UOworI2VuZGlmCiAJcmV0dXJuIHNrYi0+dmxhbl90Y2k7CiB9CiAKIHN0YXRpYyBpbmxpbmUg
dm9pZCB2bGFuX3NldF90Y2koc3RydWN0IHNrX2J1ZmYgKnNrYiwgdTE2IHZsYW5fdGNpKQogewor
I2lmIExJTlVYX1ZFUlNJT05fQ09ERSA8IEtFUk5FTF9WRVJTSU9OKDIsNiwzMykKKwl2bGFuX3Rj
aSAmPSB+VkxBTl9UQUdfUFJFU0VOVDsKKyNlbmRpZgogCXNrYi0+dmxhbl90Y2kgPSB2bGFuX3Rj
aTsKIH0KICNlbHNlCi0tIAoxLjcuMi41CgoKLS0gCkJlbiBQZmFmZiAKaHR0cDovL2JlbnBmYWZm
Lm9yZwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8v
bGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:23:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:23:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoAg3-0003V2-GX; Fri, 20 Jan 2012 09:22:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <blp@cs.stanford.edu>) id 1RnkjS-0006iN-Uh
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 05:40:19 +0000
X-Env-Sender: blp@cs.stanford.edu
X-Msg-Ref: server-11.tower-216.messagelabs.com!1326951612!11596593!1
X-Originating-IP: [62.13.148.154]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMTMuMTQ4LjE1NCA9PiAxMjUzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24441 invoked from network); 19 Jan 2012 05:40:12 -0000
Received: from outmail148154.authsmtp.co.uk (HELO
	outmail148154.authsmtp.co.uk) (62.13.148.154)
	by server-11.tower-216.messagelabs.com with SMTP;
	19 Jan 2012 05:40:12 -0000
Received: from mail-c193.authsmtp.com (mail-c193.authsmtp.com [62.13.128.118])
	by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
	q0J5eAk7079002; Thu, 19 Jan 2012 05:40:10 GMT
Received: from blp.benpfaff.org (76-14-48-202.sf-cable.astound.net
	[76.14.48.202] (may be forged)) (authenticated bits=0)
	by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id q0J5e6TT031834
	(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO);
	Thu, 19 Jan 2012 05:40:07 GMT
Received: from blp by blp.benpfaff.org with local (Exim 4.72)
	(envelope-from <blp@cs.stanford.edu>)
	id 1RnkeK-0004rl-1a; Wed, 18 Jan 2012 21:35:00 -0800
From: Ben Pfaff <blp@cs.stanford.edu>
To: Vijay Chander <vijay.chander@gmail.com>
References: <CAJNqturNKt2meEyQS5DVC8TEukJ6dzftGHyTxDoMzBeb9g_m5A@mail.gmail.com>
	<CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
Date: Wed, 18 Jan 2012 21:35:00 -0800
In-Reply-To: <CAJNqtup=A-pPpct8isu0xdzcfp-r6yvu6q5+TeOQ+sUDkXP17Q@mail.gmail.com>
	(Vijay Chander's message of "Wed, 18 Jan 2012 21:15:34 -0800")
Message-ID: <87wr8o9rwb.fsf@blp.benpfaff.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
X-Server-Quench: 0bcd6216-4260-11e1-97bb-002264978518
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCdwYQ8QAVZfSBwy AThCFzNJTwsiPBEK DBMeOw5HJEYITQBc
	chwbOAMCd38VQxYD A2cJS1RRWllxU2N9 JQ1XcwRZfE5GQQdq
	UldLR1BXCwQmQBx7 A0sYNn1ydAROe3o+ ZENlVnMVXBYpIUB/
	Q0hJEW8AZXphaTUe TUlfJVFJcANIfBlB Y1d3UXIFLwdSbGoo
	Egl7fHg2JThZNj9K Qx0GLToA
X-Authentic-SMTP: 61633331373532.1014:706
X-AuthFastPath: 0 (Was 255)
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:28 +0000
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] xen + openvswitch
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Ben Pfaff <blp@cs.stanford.edu>
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

VmlqYXkgQ2hhbmRlciA8dmlqYXkuY2hhbmRlckBnbWFpbC5jb20+IHdyaXRlczoKCj4gT24gV2Vk
LCBKYW4gMTgsIDIwMTIgYXQgOToxNCBQTSwgVmlqYXkgQ2hhbmRlciA8dmlqYXkuY2hhbmRlckBn
bWFpbC5jb20+Cj4gd3JvdGU6Cj4KPiAgICAgSGFzIGFueW9uZSBzZWVuIHBlcmZvcm1hbmNlIGlz
c3VlcyB3aXRoIHhlbiA0LjEuMCAodGhlIG9uZSB1c2VkIGluCj4gICAgIHhlbmNlbnRlciA2LjAp
wqAKPiAgICAgdXNpbmcgb3BlbiB2c3dpdGNoIGFzIG9wcG9zZWQgdG8gbmF0aXZlIGxpbnV4IGJy
aWRnZSA/Cj4gICAgCj4gICAgIFdlIGFyZSB0dXNzbGluZyB3aXRoIG5lZWRpbmcgdGhlIHN1cHBv
cnQgZ3Vlc3QgdmxhbiB0YWdnaW5nIGFuZAo+ICAgICBwZXJmb3JtYW5jZS4KClhlblNlcnZlciA2
LjAuMCBzaGlwcGVkIHdpdGggYW4gT3BlbiB2U3dpdGNoIGJ1aWxkIHRoYXQgY29udGFpbmVkCmEg
c2VyaW91cyBWTEFOIHBlcmZvcm1hbmNlIGJ1Zy4gIEl0IGlzIGZpeGVkIG9uIHRoZSBPcGVuIHZT
d2l0Y2gKInZsYW4tbWFpbnQiIGJyYW5jaC4gIFRoZSBmaXggc2hvdWxkIGFsc28gYXBwZWFyIGlu
IHRoZSBuZXh0ClhlblNlcnZlciByZWxlYXNlLgoKSGVyZSBpcyB0aGUgT3BlbiB2U3dpdGNoIGNv
bW1pdCB0aGF0IGZpeGVkIHRoZSBwcm9ibGVtLgoKLS04PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tY3V0IGhlcmUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT44LS0KCkZyb206IEJlbiBQZmFm
ZiA8YmxwQG5pY2lyYS5jb20+CkRhdGU6IFdlZCwgMjMgTWFyIDIwMTEgMTA6MzQ6MzcgLTA3MDAK
U3ViamVjdDogW1BBVENIXSBkYXRhcGF0aDogQWRkIGNvbXBhdGliaWxpdHkgd2l0aCBza19idWZm
J3Mgdmxhbl90Y2kgYmVmb3JlIDIuNi4zMy4KCkJldHdlZW4gMi42LjI3IGFuZCAyLjYuMzIsIHRo
ZSB2bGFuX3RjaSBtZW1iZXIgb2Ygc3RydWN0IHNrX2J1ZmYgd2FzIHRoZQpyYXcgdmFsdWUgb2Yg
dGhlIDgwMi4xUSBoZWFkZXIncyBUQ0kgZmllbGQsIHdpdGhvdXQgdGhlIENGSSBiaXQgYmVpbmcg
c2V0LgpJbiAyLjYuMzMgYW5kIGxhdGVyLCB0aGUgQ0ZJIGJpdCBpcyBhbHdheXMgc2V0IGlmIGFu
IDgwMi4xUSBoZWFkZXIgaXMKcHJlc2VudCwgY29ycmVjdGluZyBhIGNvcm5lciBjYXNlLgoKVW50
aWwgbm93LCBPVlMgaGFzIG5vdCBjb25zaXN0ZW50bHkgZGVhbHQgd2l0aCB0aGlzLiAgSWYgYSBw
YWNrZXQgYXJyaXZlZAphdCBhIGRhdGFwYXRoIGZyb20gYSBuZXR3b3JrIGRldmljZSBkaXJlY3Rs
eSwgb3IgaWYgaXQgd2FzIHNldCB3aXRoIGFuCk9EUF9BQ1RJT05fQVRUUl9TRVRfRExfVENJIGFj
dGlvbiwgdGhlbiB0aGUgQ0ZJIGJpdCB3b3VsZCBub3QgYmUgc2V0IGluCnZsYW5fdGNpLiAgSW4g
Zmxvd19leHRyYWN0KCksIE9WUyBjb3BpZXMgdmxhbl90Y2kgZGlyZWN0bHkgdG8gZGxfdGNpIGlu
IHRoZQpmbG93IHN0cnVjdHVyZSAodmlhIHZsYW5fZ2V0X3RjaSgpKSwgc28gdGhlIENGSSBiaXQg
d291bGQgYWxzbyBub3QgYmUgc2V0CmluIGRsX3RjaS4gIEJ1dCBpZiBPVlMgaGFkIHRvIHNlbmQg
YSBwYWNrZXQgdXAgdG8gdXNlcnNwYWNlIChjb252ZXJ0aW5nIHRoZQp2bGFuX3RjaSBiYWNrIHRv
IGFuIDgwMi4xUSBoZWFkZXIgYWxvbmcgdGhlIHdheSkgYW5kIGdvdCBpdCBiYWNrLCB0aGVuIGl0
CndvdWxkIHNldCB0aGUgVkxBTiBDRkkgYml0IGluIGRsX3RjaSB3aGVuIGl0IHBhcnNlZCB0aGUg
ODAyLjFRIGhlYWRlciBpbgpwYXJzZV92bGFuKCkuICBUaGlzIGhhZCB0aGUgZWZmZWN0IHRoYXQg
YSBmbG93IHNldCB1cCBieSB1c2Vyc3BhY2UgKHdpdGgKdGhlIENGSSBiaXQgc2V0KSB3b3VsZCBu
ZXZlciBiZSBtYXRjaGVkIGJ5IGEgcGFja2V0IGFycml2aW5nIGZyb20gYSBuZXR3b3JrCmRldmlj
ZSwgYmVjYXVzZSB0aGV5IHdvdWxkIGhhdmUgZGlmZmVyZW50IGRsX3RjaSB2YWx1ZXMuCgpUaGlz
IGZpeGVzIHRoZSBwcm9ibGVtLCBieSBtYWtpbmcgdGhlIHZsYW5fZ2V0X3RjaSgpIGFuZCB2bGFu
X3NldF90Y2koKQppbnRlcmZhY2UgY29uc2lzdGVudCBhY3Jvc3Mga2VybmVsIHZlcnNpb25zLiAg
Tm93LCB0aGV5IGFsd2F5cyBhY2NlcHQgb3IKcmV0dXJuIGEgdmFsdWUgd2hlcmUgdGhlIFZMQU4g
Q0ZJIGJpdCBpcyBzZXQgaWYgYW4gODAyLjFRIGhlYWRlciBpcwpwcmVzZW50LgoKQnVpbGQtdGVz
dGVkIG9ubHkuCgpQcm9ibGVtIGlzb2xhdGVkIGJ5IEV0aGFuIEphY2tzb24gPGV0aGFuQG5pY2ly
YS5jb20+CgpTaWduZWQtb2ZmLWJ5OiBCZW4gUGZhZmYgPGJscEBuaWNpcmEuY29tPgpBY2tlZC1i
eTogSmVzc2UgR3Jvc3MgPGplc3NlQG5pY2lyYS5jb20+ClJlcG9ydGVkLWJ5OiBSYW0gSm90aGlr
dW1hciA8cmpvdGhpa3VtYXJAbmljaXJhLmNvbT4KQnVnICM0OTE1LgotLS0KIGRhdGFwYXRoL3Zs
YW4uaCB8ICAgMzAgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCiAxIGZpbGVzIGNoYW5n
ZWQsIDMwIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvZGF0YXBh
dGgvdmxhbi5oIGIvZGF0YXBhdGgvdmxhbi5oCmluZGV4IDAyYTYyOTAuLjdlMTA4NGUgMTAwNjQ0
Ci0tLSBhL2RhdGFwYXRoL3ZsYW4uaAorKysgYi9kYXRhcGF0aC92bGFuLmgKQEAgLTEzLDYgKzEz
LDI5IEBACiAjaW5jbHVkZSA8bGludXgvc2tidWZmLmg+CiAjaW5jbHVkZSA8bGludXgvdmVyc2lv
bi5oPgogCisvKioKKyAqIERPQzogVkxBTiB0YWcgbWFuaXB1bGF0aW9uLgorICoKKyAqICZzdHJ1
Y3Qgc2tfYnVmZiBoYW5kbGluZyBvZiBWTEFOIHRhZ3MgaGFzIGV2b2x2ZWQgb3ZlciB0aW1lOgor
ICoKKyAqIEluIDIuNi4yNiBhbmQgZWFybGllciwgVkxBTiB0YWdzIGRpZCBub3QgaGF2ZSBhbnkg
Z2VuZXJpYyByZXByZXNlbnRhdGlvbiBpbgorICogYW4gc2tiLCBvdGhlciB0aGFuIGFzIGEgcmF3
IDgwMi4xUSBoZWFkZXIgaW5zaWRlIHRoZSBwYWNrZXQgZGF0YS4KKyAqCisgKiBJbiAyLjYuMjcg
JnN0cnVjdCBza19idWZmIGFkZGVkIGEgQHZsYW5fdGNpIG1lbWJlci4gIEJldHdlZW4gMi42LjI3
IGFuZAorICogMi42LjMyLCBpdHMgdmFsdWUgd2FzIHRoZSByYXcgY29udGVudHMgb2YgdGhlIDgw
Mi4xUSBUQ0kgZmllbGQsIG9yIHplcm8gaWYKKyAqIG5vIDgwMi4xUSBoZWFkZXIgd2FzIHByZXNl
bnQuICBUaGlzIHdvcmtlZCBPSyBleGNlcHQgZm9yIHRoZSBjb3JuZXIgY2FzZSBvZgorICogYW4g
ODAyLjFRIGhlYWRlciB3aXRoIGFuIGFsbC0wLWJpdHMgVENJLCB3aGljaCBjb3VsZCBub3QgYmUg
cmVwcmVzZW50ZWQuCisgKgorICogSW4gMi42LjMzLCBAdmxhbl90Y2kgc2VtYW50aWNzIGNoYW5n
ZWQuICBOb3csIGlmIGFuIDgwMi4xUSBoZWFkZXIgaXMKKyAqIHByZXNlbnQsIHRoZW4gdGhlIFZM
QU5fVEFHX1BSRVNFTlQgYml0IGlzIGFsd2F5cyBzZXQuICBUaGlzIGZpeGVzIHRoZQorICogYWxs
LTAtYml0cyBUQ0kgY29ybmVyIGNhc2UuCisgKgorICogRm9yIGNvbXBhdGliaWxpdHkgd2UgZW11
bGF0ZSB0aGUgMi42LjMzKyBiZWhhdmlvciBvbiBlYXJsaWVyIGtlcm5lbAorICogdmVyc2lvbnMu
ICBUaGUgY2xpZW50IG11c3Qgbm90IGFjY2VzcyBAdmxhbl90Y2kgZGlyZWN0bHkuICBJbnN0ZWFk
LCB1c2UKKyAqIHZsYW5fZ2V0X3RjaSgpIHRvIHJlYWQgaXQgb3Igdmxhbl9zZXRfdGNpKCkgdG8g
d3JpdGUgaXQsIHdpdGggc2VtYW50aWNzCisgKiBlcXVpdmFsZW50IHRvIHRob3NlIG9uIDIuNi4z
MysuCisgKi8KKwogI2lmIExJTlVYX1ZFUlNJT05fQ09ERSA8IEtFUk5FTF9WRVJTSU9OKDIsNiwy
NykKICNkZWZpbmUgTkVFRF9WTEFOX0ZJRUxECiAjZW5kaWYKQEAgLTIyLDExICs0NSwxOCBAQCBz
dGF0aWMgaW5saW5lIHZvaWQgdmxhbl9jb3B5X3NrYl90Y2koc3RydWN0IHNrX2J1ZmYgKnNrYikg
eyB9CiAKIHN0YXRpYyBpbmxpbmUgdTE2IHZsYW5fZ2V0X3RjaShzdHJ1Y3Qgc2tfYnVmZiAqc2ti
KQogeworI2lmIExJTlVYX1ZFUlNJT05fQ09ERSA8IEtFUk5FTF9WRVJTSU9OKDIsNiwzMykKKwlp
ZiAoc2tiLT52bGFuX3RjaSkKKwkJcmV0dXJuIHNrYi0+dmxhbl90Y2kgfCBWTEFOX1RBR19QUkVT
RU5UOworI2VuZGlmCiAJcmV0dXJuIHNrYi0+dmxhbl90Y2k7CiB9CiAKIHN0YXRpYyBpbmxpbmUg
dm9pZCB2bGFuX3NldF90Y2koc3RydWN0IHNrX2J1ZmYgKnNrYiwgdTE2IHZsYW5fdGNpKQogewor
I2lmIExJTlVYX1ZFUlNJT05fQ09ERSA8IEtFUk5FTF9WRVJTSU9OKDIsNiwzMykKKwl2bGFuX3Rj
aSAmPSB+VkxBTl9UQUdfUFJFU0VOVDsKKyNlbmRpZgogCXNrYi0+dmxhbl90Y2kgPSB2bGFuX3Rj
aTsKIH0KICNlbHNlCi0tIAoxLjcuMi41CgoKLS0gCkJlbiBQZmFmZiAKaHR0cDovL2JlbnBmYWZm
Lm9yZwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8v
bGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:23:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09: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 1RoAgJ-0003YD-U9; Fri, 20 Jan 2012 09:22:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lcapitulino@redhat.com>) id 1Rnrtv-0000KS-Ab
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:19:35 +0000
X-Env-Sender: lcapitulino@redhat.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326979168!11555249!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA4Njc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24733 invoked from network); 19 Jan 2012 13:19:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	19 Jan 2012 13:19:28 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0JDJRgj004646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Jan 2012 08:19:27 -0500
Received: from doriath (ovpn-116-68.ams2.redhat.com [10.36.116.68])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0JDJOBZ024416; Thu, 19 Jan 2012 08:19:25 -0500
Date: Thu, 19 Jan 2012 11:19:23 -0200
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120119111923.0836eb14@doriath>
In-Reply-To: <1326737715-9867-4-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
	<1326737715-9867-4-git-send-email-kraxel@redhat.com>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:47 +0000
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 3/6] suspend: add wakeup
	monitor command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 16 Jan 2012 19:15:12 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

> This patch adds a wakeup monitor command which will simply wake up
> suspended guests.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hmp-commands.hx  |   14 ++++++++++++++
>  hmp.c            |    5 +++++
>  hmp.h            |    1 +
>  qapi-schema.json |   11 +++++++++++
>  qmp-commands.hx  |   21 +++++++++++++++++++++
>  qmp.c            |    5 +++++
>  6 files changed, 57 insertions(+), 0 deletions(-)
> 
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index a586498..c62871a 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -313,6 +313,20 @@ Resume emulation.
>  ETEXI
>  
>      {
> +        .name       = "wakeup",
> +        .args_type  = "",
> +        .params     = "",
> +        .help       = "wakeup guest from suspend",
> +        .mhandler.cmd = hmp_wakeup,
> +    },
> +
> +STEXI
> +@item wakeup
> +@findex wakeup
> +Wakeup guest from suspend.
> +ETEXI
> +
> +    {
>          .name       = "gdbserver",
>          .args_type  = "device:s?",
>          .params     = "[device]",
> diff --git a/hmp.c b/hmp.c
> index e7659d5..1a14684 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -594,6 +594,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
>      }
>  }
>  
> +void hmp_wakeup(Monitor *mon, const QDict *qdict)
> +{
> +    qmp_wakeup(NULL);
> +}
> +
>  void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
>  {
>      Error *errp = NULL;
> diff --git a/hmp.h b/hmp.h
> index 093242d..76eb3df 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -40,6 +40,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
>  void hmp_memsave(Monitor *mon, const QDict *qdict);
>  void hmp_pmemsave(Monitor *mon, const QDict *qdict);
>  void hmp_cont(Monitor *mon, const QDict *qdict);
> +void hmp_wakeup(Monitor *mon, const QDict *qdict);
>  void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
>  void hmp_set_link(Monitor *mon, const QDict *qdict);
>  void hmp_block_passwd(Monitor *mon, const QDict *qdict);
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 44cf764..75773d4 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -967,6 +967,17 @@
>  { 'command': 'cont' }
>  
>  ##
> +# @wakeup:
> +#
> +# Wakrup guest from suspend

s/Wakrup/Wakeup

Very nice series:

 Acked-by: Luiz Capitulino <lcapitulino@redhat.com>

> +#
> +# Since:  1.1
> +#
> +# Returns:  nothing.
> +##
> +{ 'command': 'wakeup' }
> +
> +##
>  # @inject-nmi:
>  #
>  # Injects an Non-Maskable Interrupt into all guest's VCPUs.
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 7e3f4b9..2c84a7a 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -218,6 +218,27 @@ Example:
>  EQMP
>  
>      {
> +        .name       = "wakeup",
> +        .args_type  = "",
> +        .mhandler.cmd_new = qmp_marshal_input_wakeup,
> +    },
> +
> +SQMP
> +wakeup
> +------
> +
> +Wakeup guest from suspend.
> +
> +Arguments: None.
> +
> +Example:
> +
> +-> { "execute": "wakeup" }
> +<- { "return": {} }
> +
> +EQMP
> +
> +    {
>          .name       = "system_reset",
>          .args_type  = "",
>          .mhandler.cmd_new = qmp_marshal_input_system_reset,
> diff --git a/qmp.c b/qmp.c
> index 5e09b41..f8b1dc7 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -158,6 +158,11 @@ void qmp_cont(Error **errp)
>      vm_start();
>  }
>  
> +void qmp_wakeup(Error **errp)
> +{
> +    qemu_system_wakeup_request();
> +}
> +
>  DevicePropertyInfoList *qmp_qom_list(const char *path, Error **errp)
>  {
>      DeviceState *dev;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:23:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09: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 1RoAgJ-0003YD-U9; Fri, 20 Jan 2012 09:22:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lcapitulino@redhat.com>) id 1Rnrtv-0000KS-Ab
	for xen-devel@lists.xensource.com; Thu, 19 Jan 2012 13:19:35 +0000
X-Env-Sender: lcapitulino@redhat.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1326979168!11555249!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTA4Njc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24733 invoked from network); 19 Jan 2012 13:19:28 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-182.messagelabs.com with SMTP;
	19 Jan 2012 13:19:28 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0JDJRgj004646
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 19 Jan 2012 08:19:27 -0500
Received: from doriath (ovpn-116-68.ams2.redhat.com [10.36.116.68])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0JDJOBZ024416; Thu, 19 Jan 2012 08:19:25 -0500
Date: Thu, 19 Jan 2012 11:19:23 -0200
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Message-ID: <20120119111923.0836eb14@doriath>
In-Reply-To: <1326737715-9867-4-git-send-email-kraxel@redhat.com>
References: <1326737715-9867-1-git-send-email-kraxel@redhat.com>
	<1326737715-9867-4-git-send-email-kraxel@redhat.com>
Organization: Red Hat
Mime-Version: 1.0
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Mailman-Approved-At: Fri, 20 Jan 2012 09:22:47 +0000
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 3/6] suspend: add wakeup
	monitor command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 16 Jan 2012 19:15:12 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

> This patch adds a wakeup monitor command which will simply wake up
> suspended guests.
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hmp-commands.hx  |   14 ++++++++++++++
>  hmp.c            |    5 +++++
>  hmp.h            |    1 +
>  qapi-schema.json |   11 +++++++++++
>  qmp-commands.hx  |   21 +++++++++++++++++++++
>  qmp.c            |    5 +++++
>  6 files changed, 57 insertions(+), 0 deletions(-)
> 
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index a586498..c62871a 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -313,6 +313,20 @@ Resume emulation.
>  ETEXI
>  
>      {
> +        .name       = "wakeup",
> +        .args_type  = "",
> +        .params     = "",
> +        .help       = "wakeup guest from suspend",
> +        .mhandler.cmd = hmp_wakeup,
> +    },
> +
> +STEXI
> +@item wakeup
> +@findex wakeup
> +Wakeup guest from suspend.
> +ETEXI
> +
> +    {
>          .name       = "gdbserver",
>          .args_type  = "device:s?",
>          .params     = "[device]",
> diff --git a/hmp.c b/hmp.c
> index e7659d5..1a14684 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -594,6 +594,11 @@ void hmp_cont(Monitor *mon, const QDict *qdict)
>      }
>  }
>  
> +void hmp_wakeup(Monitor *mon, const QDict *qdict)
> +{
> +    qmp_wakeup(NULL);
> +}
> +
>  void hmp_inject_nmi(Monitor *mon, const QDict *qdict)
>  {
>      Error *errp = NULL;
> diff --git a/hmp.h b/hmp.h
> index 093242d..76eb3df 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -40,6 +40,7 @@ void hmp_cpu(Monitor *mon, const QDict *qdict);
>  void hmp_memsave(Monitor *mon, const QDict *qdict);
>  void hmp_pmemsave(Monitor *mon, const QDict *qdict);
>  void hmp_cont(Monitor *mon, const QDict *qdict);
> +void hmp_wakeup(Monitor *mon, const QDict *qdict);
>  void hmp_inject_nmi(Monitor *mon, const QDict *qdict);
>  void hmp_set_link(Monitor *mon, const QDict *qdict);
>  void hmp_block_passwd(Monitor *mon, const QDict *qdict);
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 44cf764..75773d4 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -967,6 +967,17 @@
>  { 'command': 'cont' }
>  
>  ##
> +# @wakeup:
> +#
> +# Wakrup guest from suspend

s/Wakrup/Wakeup

Very nice series:

 Acked-by: Luiz Capitulino <lcapitulino@redhat.com>

> +#
> +# Since:  1.1
> +#
> +# Returns:  nothing.
> +##
> +{ 'command': 'wakeup' }
> +
> +##
>  # @inject-nmi:
>  #
>  # Injects an Non-Maskable Interrupt into all guest's VCPUs.
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 7e3f4b9..2c84a7a 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -218,6 +218,27 @@ Example:
>  EQMP
>  
>      {
> +        .name       = "wakeup",
> +        .args_type  = "",
> +        .mhandler.cmd_new = qmp_marshal_input_wakeup,
> +    },
> +
> +SQMP
> +wakeup
> +------
> +
> +Wakeup guest from suspend.
> +
> +Arguments: None.
> +
> +Example:
> +
> +-> { "execute": "wakeup" }
> +<- { "return": {} }
> +
> +EQMP
> +
> +    {
>          .name       = "system_reset",
>          .args_type  = "",
>          .mhandler.cmd_new = qmp_marshal_input_system_reset,
> diff --git a/qmp.c b/qmp.c
> index 5e09b41..f8b1dc7 100644
> --- a/qmp.c
> +++ b/qmp.c
> @@ -158,6 +158,11 @@ void qmp_cont(Error **errp)
>      vm_start();
>  }
>  
> +void qmp_wakeup(Error **errp)
> +{
> +    qemu_system_wakeup_request();
> +}
> +
>  DevicePropertyInfoList *qmp_qom_list(const char *path, Error **errp)
>  {
>      DeviceState *dev;


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:45:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09: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 1RoB24-0004ku-SU; Fri, 20 Jan 2012 09:45: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 1RoB23-0004kj-KM; Fri, 20 Jan 2012 09:45:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327052709!11726163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30038 invoked from network); 20 Jan 2012 09:45:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 09:45:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10172162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 09:45: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, 20 Jan 2012 09:45:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
Date: Fri, 20 Jan 2012 09:45:08 +0000
In-Reply-To: <CAO8_4VpeE=A-hMVqtS-F0W47tNrWMpoCqWen2_KeCJCFgCiRyQ@mail.gmail.com>
References: <CAO8_4VpeE=A-hMVqtS-F0W47tNrWMpoCqWen2_KeCJCFgCiRyQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327052708.17599.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Upstream Qemu 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

As mentioned on http://wiki.xen.org/wiki/AskingXenDevelQuestions please
do not cross post. xen-users moved to bcc since I guess this is a devel
question until we release a version of Xen which supports upstream qemu.

On Fri, 2012-01-20 at 07:50 +0000, Nupur Ghatnekar wrote:
> Hi,
> 
> I am trying to follow the steps given on the xenwiki page
> http://wiki.xen.org/xenwiki/QEMUUpstream
> 
> I have a couple of doubts:
> 
> 1) is there any change in the steps if stable xen is currently
> installed in the system. I already have a functional xen installed.

Upstream qemu is not supported by any released version of Xen. If you
want this then you will need to install xen-unstable. You should
probably remove any stable Xen packages before you do this.

> 2) I tried to follow the steps anyways. But there was no qemu
> in  /path/ot/qemu/i386-softmmu/ .
> 
> these are the contents
> root@pratik-desktop:~/backup-virtio-qemu/qemu-upstream-unstable/i386-softmmu# ls
> 9pfs                config-devices.mak.old  fpu  Makefile
> config-devices.mak  config-target.mak       ide  tcg

It appears that qemu has not built successfully (there should be many
more files). Were there any error messages when you tried to
configure/build qemu?

> Can someone help me out?

Please post the complete and exact steps you followed. Including the
output at various steps.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:45:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09: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 1RoB24-0004ku-SU; Fri, 20 Jan 2012 09:45: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 1RoB23-0004kj-KM; Fri, 20 Jan 2012 09:45:15 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327052709!11726163!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30038 invoked from network); 20 Jan 2012 09:45:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 09:45:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10172162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 09:45: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, 20 Jan 2012 09:45:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Nupur Ghatnekar <nupurghatnekar@gmail.com>
Date: Fri, 20 Jan 2012 09:45:08 +0000
In-Reply-To: <CAO8_4VpeE=A-hMVqtS-F0W47tNrWMpoCqWen2_KeCJCFgCiRyQ@mail.gmail.com>
References: <CAO8_4VpeE=A-hMVqtS-F0W47tNrWMpoCqWen2_KeCJCFgCiRyQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327052708.17599.127.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Upstream Qemu 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

As mentioned on http://wiki.xen.org/wiki/AskingXenDevelQuestions please
do not cross post. xen-users moved to bcc since I guess this is a devel
question until we release a version of Xen which supports upstream qemu.

On Fri, 2012-01-20 at 07:50 +0000, Nupur Ghatnekar wrote:
> Hi,
> 
> I am trying to follow the steps given on the xenwiki page
> http://wiki.xen.org/xenwiki/QEMUUpstream
> 
> I have a couple of doubts:
> 
> 1) is there any change in the steps if stable xen is currently
> installed in the system. I already have a functional xen installed.

Upstream qemu is not supported by any released version of Xen. If you
want this then you will need to install xen-unstable. You should
probably remove any stable Xen packages before you do this.

> 2) I tried to follow the steps anyways. But there was no qemu
> in  /path/ot/qemu/i386-softmmu/ .
> 
> these are the contents
> root@pratik-desktop:~/backup-virtio-qemu/qemu-upstream-unstable/i386-softmmu# ls
> 9pfs                config-devices.mak.old  fpu  Makefile
> config-devices.mak  config-target.mak       ide  tcg

It appears that qemu has not built successfully (there should be many
more files). Were there any error messages when you tried to
configure/build qemu?

> Can someone help me out?

Please post the complete and exact steps you followed. Including the
output at various steps.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:46:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09: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 1RoB2h-0004mu-Cf; Fri, 20 Jan 2012 09:45: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 1RoB2f-0004md-L4
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 09:45:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327052747!7878462!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 24961 invoked from network); 20 Jan 2012 09:45:47 -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; 20 Jan 2012 09:45:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 09:45:46 +0000
Message-Id: <4F19461C020000780006DD64@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 09:46:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-10906-mainreport@xen.org>
In-Reply-To: <osstest-10906-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang2 <wei.wang2@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 10906: 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

>>> On 19.01.12 at 22:50, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 10906 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10906/ 
> 
> Failures :-/ but no regressions.
> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-win       7 windows-install             fail pass in 10902
>  test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10902
>  test-amd64-amd64-win          7 windows-install    fail in 10902 pass in 10906
>  test-i386-i386-xl-win         7 windows-install    fail in 10902 pass in 10906
>  test-amd64-i386-win           7 windows-install    fail in 10902 pass in 10906

While I can't spot anything useful (to me) in the logs, I'm getting the
impression that we're once again/still having an AMD-only problem.
Could you run the bisector on an AMD system (suspecting the issue
to be in the IOMMU-v2 patches)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:46:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09: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 1RoB2h-0004mu-Cf; Fri, 20 Jan 2012 09:45: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 1RoB2f-0004md-L4
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 09:45:53 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327052747!7878462!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 24961 invoked from network); 20 Jan 2012 09:45:47 -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; 20 Jan 2012 09:45:47 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 09:45:46 +0000
Message-Id: <4F19461C020000780006DD64@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 09:46:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <ian.jackson@eu.citrix.com>
References: <osstest-10906-mainreport@xen.org>
In-Reply-To: <osstest-10906-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Wei Wang2 <wei.wang2@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [xen-unstable test] 10906: 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

>>> On 19.01.12 at 22:50, xen.org <ian.jackson@eu.citrix.com> wrote:
> flight 10906 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/10906/ 
> 
> Failures :-/ but no regressions.
> 
> Tests which are failing intermittently (not blocking):
>  test-amd64-amd64-xl-win       7 windows-install             fail pass in 10902
>  test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10902
>  test-amd64-amd64-win          7 windows-install    fail in 10902 pass in 10906
>  test-i386-i386-xl-win         7 windows-install    fail in 10902 pass in 10906
>  test-amd64-i386-win           7 windows-install    fail in 10902 pass in 10906

While I can't spot anything useful (to me) in the logs, I'm getting the
impression that we're once again/still having an AMD-only problem.
Could you run the bisector on an AMD system (suspecting the issue
to be in the IOMMU-v2 patches)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:56:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoBCa-0005Oe-Go; Fri, 20 Jan 2012 09:56:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RoBCY-0005OZ-GP
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 09:56:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327053360!11857204!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 8713 invoked from network); 20 Jan 2012 09:56:00 -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; 20 Jan 2012 09:56:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 09:55:59 +0000
Message-Id: <4F194880020000780006DD7F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 09:57:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EBA8FAA020000780005FD5F@nat28.tlf.novell.com>
	<4EBC125A.70300@goop.org> <20120119194232.GA3728@konrad-lan>
In-Reply-To: <20120119194232.GA3728@konrad-lan>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Laszlo Ersek <lersek@redhat.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 19.01.12 at 20:42, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> I finally got some time to look at them and I think they are these ones:
> 
> git log --oneline 
> e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b
> 255a4 
> 3c404b5 KVM guest: Add a pv_ops stub for steal time
> c9aaa89 KVM: Steal time implementation
> 9ddabbe KVM: KVM Steal time guest/host interface
> 4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host 
> interface
> 
> What is interesting is that they end up inserting a bunch of:
> 
>  
> +       if (steal_account_process_tick())
> +               return;
> +
> 
> in irqtime_account_process_tick and in account_process_tick.

And this (particularly the "return" part of it) is what I have a hard
time to understand: How can it be correct to not do any of the
other accounting? After all, the function calls only
account_steal_time(), but its certainly going to be common that
part of the time was stolen, and part was spent executing.

Further, it's being called only from the process tick accounting
functions, but clearly part of idle or interrupt time can also be
stolen.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 09:56:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 09:56:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoBCa-0005Oe-Go; Fri, 20 Jan 2012 09:56:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RoBCY-0005OZ-GP
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 09:56:06 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327053360!11857204!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 8713 invoked from network); 20 Jan 2012 09:56:00 -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; 20 Jan 2012 09:56:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 09:55:59 +0000
Message-Id: <4F194880020000780006DD7F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 09:57:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EBA8FAA020000780005FD5F@nat28.tlf.novell.com>
	<4EBC125A.70300@goop.org> <20120119194232.GA3728@konrad-lan>
In-Reply-To: <20120119194232.GA3728@konrad-lan>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Joe Jin <joe.jin@oracle.com>, Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Laszlo Ersek <lersek@redhat.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 19.01.12 at 20:42, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> I finally got some time to look at them and I think they are these ones:
> 
> git log --oneline 
> e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b
> 255a4 
> 3c404b5 KVM guest: Add a pv_ops stub for steal time
> c9aaa89 KVM: Steal time implementation
> 9ddabbe KVM: KVM Steal time guest/host interface
> 4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host 
> interface
> 
> What is interesting is that they end up inserting a bunch of:
> 
>  
> +       if (steal_account_process_tick())
> +               return;
> +
> 
> in irqtime_account_process_tick and in account_process_tick.

And this (particularly the "return" part of it) is what I have a hard
time to understand: How can it be correct to not do any of the
other accounting? After all, the function calls only
account_steal_time(), but its certainly going to be common that
part of the time was stolen, and part was spent executing.

Further, it's being called only from the process tick accounting
functions, but clearly part of idle or interrupt time can also be
stolen.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10: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 1RoBZB-00067j-6C; Fri, 20 Jan 2012 10:19: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 1RoBZ9-00062j-QY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:19:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327054256!11634039!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 13357 invoked from network); 20 Jan 2012 10:10:57 -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; 20 Jan 2012 10:10:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 10:10:56 +0000
Message-Id: <4F194C00020000780006DD9C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 10:12:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <1327007550.21391.16.camel@dagon.hellion.org.uk>
	<CB3E4223.2925F%keir.xen@gmail.com>
In-Reply-To: <CB3E4223.2925F%keir.xen@gmail.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 22:56, Keir Fraser <keir.xen@gmail.com> wrote:
> On 19/01/2012 21:12, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
>> On Thu, 2012-01-19 at 21:07 +0000, Keir Fraser wrote:
>>>> Yes. And also use __attribute(__packed__);
>>> 
>>> Not used in any public header files.
>> 
>> One seems to have crept into xen/include/public/arch-x86/hvm/save.h :-(
> 
> Thanks, I'll get rid of it. It looks like it should have no effect on that
> struct anyway.

While it indeed looks pointless there, all the hvm/save.h headers are
supposedly tools interface only anyway, so would generally be free
to use extensions (and are therefore excluded from the ANSI
correctness test).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:19:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10: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 1RoBZB-00067j-6C; Fri, 20 Jan 2012 10:19: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 1RoBZ9-00062j-QY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:19:28 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327054256!11634039!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 13357 invoked from network); 20 Jan 2012 10:10:57 -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; 20 Jan 2012 10:10:57 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 10:10:56 +0000
Message-Id: <4F194C00020000780006DD9C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 10:12:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Keir Fraser" <keir.xen@gmail.com>
References: <1327007550.21391.16.camel@dagon.hellion.org.uk>
	<CB3E4223.2925F%keir.xen@gmail.com>
In-Reply-To: <CB3E4223.2925F%keir.xen@gmail.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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 22:56, Keir Fraser <keir.xen@gmail.com> wrote:
> On 19/01/2012 21:12, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
>> On Thu, 2012-01-19 at 21:07 +0000, Keir Fraser wrote:
>>>> Yes. And also use __attribute(__packed__);
>>> 
>>> Not used in any public header files.
>> 
>> One seems to have crept into xen/include/public/arch-x86/hvm/save.h :-(
> 
> Thanks, I'll get rid of it. It looks like it should have no effect on that
> struct anyway.

While it indeed looks pointless there, all the hvm/save.h headers are
supposedly tools interface only anyway, so would generally be free
to use extensions (and are therefore excluded from the ANSI
correctness test).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:30:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoBjJ-0006YI-If; Fri, 20 Jan 2012 10:29:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RoBjH-0006YD-9R
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:29:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327055388!7877422!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 1686 invoked from network); 20 Jan 2012 10:29:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 10:29:48 -0000
Received: by werb14 with SMTP id b14so1755401wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 02:29: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=KxYS03Wm4HwI4jAPk+IpnxCF363L5I3spcggU1atc1w=;
	b=DZ7ug33aefXStl9pdlWGKSg3c4o+CuVO46J6EtuXTVSohuVlTgbLfGSJymzMLGmcpT
	SdFUvLeWQcWzLcyrI/6Q4fbQGzdt6qjBkVpTiw8qiJztxjYpW5cbgpwMxN5meh5JbGub
	MozGLZOODKNYx61t4fzfr4EpmLkHHDLfNirys=
Received: by 10.180.105.129 with SMTP id gm1mr3187732wib.1.1327055387819;
	Fri, 20 Jan 2012 02:29:47 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id di5sm7601716wib.3.2012.01.20.02.29.46
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:29:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 10:29:41 +0000
From: Keir Fraser <keir@xen.org>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB3EF295.37D36%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXXmsPJpwifHC+ckWBFE+sU7P7ZA==
In-Reply-To: <331757089.MKuFJYUFjK@amur>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19/01/2012 13:54, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:

> 
>  tools/libxc/xc_cpuid_x86.c        |   1 +
>  xen/arch/x86/hvm/vmx/vmx.c        |   2 ++
>  xen/arch/x86/hvm/vmx/vpmu_core2.c |  38
> ++++++++++++++++++++++++++++++++++++--
>  xen/arch/x86/hvm/vpmu.c           |  25 ++++++++++++++++++-------
>  xen/include/asm-x86/hvm/vpmu.h    |   6 ++++++
>  5 files changed, 63 insertions(+), 9 deletions(-)
> 
> 
> The  "Debug Store" cpuid flag in the Intel processors gets enabled in the
> libxc.
> A new function call arch_vpmu_cpuid is added to the struct arch_vpmu_ops and
> for
> Intel processors the function core2_vpmu_cpuid() is added.
> The aim is that always a "struct arch_vpmu_ops" is accessible at least with
> a cpuid function to switch off special PMU cpuid flags dynamically depending
> on
> the boot variable opt_vpmu_enabled.

Our CPUID configuration is done per-domain, and from
tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
hypervisor are generally not acceptable without very good reason.

 -- Keir

> Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> 
> diff -r 7a82c2e2eb33 tools/libxc/xc_cpuid_x86.c
> --- a/tools/libxc/xc_cpuid_x86.c Thu Jan 19 13:14:02 2012 +0100
> +++ b/tools/libxc/xc_cpuid_x86.c Thu Jan 19 14:37:17 2012 +0100
> @@ -343,6 +343,7 @@ static void xc_cpuid_hvm_policy(
>                      bitmaskof(X86_FEATURE_CMOV) |
>                      bitmaskof(X86_FEATURE_PAT) |
>                      bitmaskof(X86_FEATURE_CLFLSH) |
> +                    bitmaskof(X86_FEATURE_DS) |
>                      bitmaskof(X86_FEATURE_PSE36) |
>                      bitmaskof(X86_FEATURE_MMX) |
>                      bitmaskof(X86_FEATURE_FXSR) |
> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 13:14:02 2012 +0100
> +++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 14:37:17 2012 +0100
> @@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
>              break;
>      }
>  
> +    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
> +
>      HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
>  }
>  
> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vpmu_core2.c
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 13:14:02 2012 +0100
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 14:37:17 2012 +0100
> @@ -598,6 +598,29 @@ static void core2_vpmu_destroy(struct vc
>      vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
>  }
>  
> +/**
> + * core2_vpmu_cpuid - prepare special vpmu cpuid bits
> + * If emulation of vpmu is switched off, some bits are swtiched off,
> currently:
> + * - EAX[0x1].EAX[Bits 0-7]: PMC revision id.
> + * - EAX[0xa].EDX[Bit 21]:   Debug Store
> + */
> +#define bitmaskof(idx)  (1U << ((idx) & 31))
> +static void core2_vpmu_cpuid(unsigned int input,
> +                             unsigned int *eax, unsigned int *ebx,
> +                             unsigned int *ecx, unsigned int *edx)
> +{
> +    switch ( input )
> +    {
> +    case 0x1:
> +        *edx &= ~bitmaskof(X86_FEATURE_DS);    /* Debug Store not supported
> */
> +        break;
> +    case 0xa:
> +        if ( !opt_vpmu_enabled )
> +            *eax &= ~(unsigned int)0xff;       /* Clear pmc version id. */
> +        break;
> +    }
> +}
> +
>  struct arch_vpmu_ops core2_vpmu_ops = {
>      .do_wrmsr = core2_vpmu_do_wrmsr,
>      .do_rdmsr = core2_vpmu_do_rdmsr,
> @@ -605,7 +628,13 @@ struct arch_vpmu_ops core2_vpmu_ops = {
>      .arch_vpmu_initialise = core2_vpmu_initialise,
>      .arch_vpmu_destroy = core2_vpmu_destroy,
>      .arch_vpmu_save = core2_vpmu_save,
> -    .arch_vpmu_load = core2_vpmu_load
> +    .arch_vpmu_load = core2_vpmu_load,
> +    .arch_vpmu_cpuid = core2_vpmu_cpuid
> +};
> +
> +/* Used if vpmu is disabled. */
> +struct arch_vpmu_ops core2_vpmu_dis_ops = {
> +    .arch_vpmu_cpuid = core2_vpmu_cpuid
>  };
>  
>  int vmx_vpmu_initialize(struct vcpu *v)
> @@ -615,7 +644,7 @@ int vmx_vpmu_initialize(struct vcpu *v)
>      __u8 cpu_model = current_cpu_data.x86_model;
>  
>      if ( !opt_vpmu_enabled )
> -        return -EINVAL;
> +        goto func_out;
>  
>      if ( family == 6 )
>      {
> @@ -635,6 +664,11 @@ int vmx_vpmu_initialize(struct vcpu *v)
>      printk("VPMU: Initialization failed. "
>             "Intel processor family %d model %d has not "
>             "been supported\n", family, cpu_model);
> +
> +func_out:
> +
> +    vpmu->arch_vpmu_ops = &core2_vpmu_dis_ops;
> +
>      return -EINVAL;
>  }
>  
> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vpmu.c
> --- a/xen/arch/x86/hvm/vpmu.c Thu Jan 19 13:14:02 2012 +0100
> +++ b/xen/arch/x86/hvm/vpmu.c Thu Jan 19 14:37:17 2012 +0100
> @@ -39,7 +39,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
>          return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content);
>      return 0;
>  }
> @@ -48,7 +48,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
>          return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
>      return 0;
>  }
> @@ -57,7 +57,7 @@ int vpmu_do_interrupt(struct cpu_user_re
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_interrupt )
>          return vpmu->arch_vpmu_ops->do_interrupt(regs);
>      return 0;
>  }
> @@ -66,7 +66,7 @@ void vpmu_save(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_save )
>          vpmu->arch_vpmu_ops->arch_vpmu_save(v);
>  }
>  
> @@ -74,7 +74,7 @@ void vpmu_load(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
>          vpmu->arch_vpmu_ops->arch_vpmu_load(v);
>  }
>  
> @@ -109,7 +109,8 @@ void vpmu_initialise(struct vcpu *v)
>      {
>          vpmu->flags = 0;
>          vpmu->context = NULL;
> -        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
> +        if ( vpmu->arch_vpmu_ops->arch_vpmu_initialise )
> +            vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
>      }
>  }
>  
> @@ -117,7 +118,17 @@ void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>  }
>  
> +void vpmu_do_cpuid(unsigned int input,
> +                   unsigned int *eax, unsigned int *ebx,
> +                   unsigned int *ecx, unsigned int *edx)
> +{
> +    struct vpmu_struct *vpmu = vcpu_vpmu(current);
> +
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_cpuid)
> +        vpmu->arch_vpmu_ops->arch_vpmu_cpuid(input, eax, ebx, ecx, edx);
> +}
> +
> diff -r 7a82c2e2eb33 xen/include/asm-x86/hvm/vpmu.h
> --- a/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 13:14:02 2012 +0100
> +++ b/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 14:37:17 2012 +0100
> @@ -56,6 +56,9 @@ struct arch_vpmu_ops {
>      void (*arch_vpmu_destroy)(struct vcpu *v);
>      void (*arch_vpmu_save)(struct vcpu *v);
>      void (*arch_vpmu_load)(struct vcpu *v);
> +    void (*arch_vpmu_cpuid)(unsigned int input,
> +                            unsigned int *eax, unsigned int *ebx,
> +                            unsigned int *ecx, unsigned int *edx);
>  };
>  
>  int vmx_vpmu_initialize(struct vcpu *v);
> @@ -78,6 +81,9 @@ void vpmu_initialise(struct vcpu *v);
>  void vpmu_destroy(struct vcpu *v);
>  void vpmu_save(struct vcpu *v);
>  void vpmu_load(struct vcpu *v);
> +void vpmu_do_cpuid(unsigned int input,
> +                   unsigned int *eax, unsigned int *ebx,
> +                   unsigned int *ecx, unsigned int *edx);
>  
>  extern int acquire_pmu_ownership(int pmu_ownership);
>  extern void release_pmu_ownership(int pmu_ownership);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:30:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:30:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoBjJ-0006YI-If; Fri, 20 Jan 2012 10:29:57 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RoBjH-0006YD-9R
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:29:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327055388!7877422!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 1686 invoked from network); 20 Jan 2012 10:29:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 10:29:48 -0000
Received: by werb14 with SMTP id b14so1755401wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 02:29: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=KxYS03Wm4HwI4jAPk+IpnxCF363L5I3spcggU1atc1w=;
	b=DZ7ug33aefXStl9pdlWGKSg3c4o+CuVO46J6EtuXTVSohuVlTgbLfGSJymzMLGmcpT
	SdFUvLeWQcWzLcyrI/6Q4fbQGzdt6qjBkVpTiw8qiJztxjYpW5cbgpwMxN5meh5JbGub
	MozGLZOODKNYx61t4fzfr4EpmLkHHDLfNirys=
Received: by 10.180.105.129 with SMTP id gm1mr3187732wib.1.1327055387819;
	Fri, 20 Jan 2012 02:29:47 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id di5sm7601716wib.3.2012.01.20.02.29.46
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:29:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 10:29:41 +0000
From: Keir Fraser <keir@xen.org>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB3EF295.37D36%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXXmsPJpwifHC+ckWBFE+sU7P7ZA==
In-Reply-To: <331757089.MKuFJYUFjK@amur>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 19/01/2012 13:54, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:

> 
>  tools/libxc/xc_cpuid_x86.c        |   1 +
>  xen/arch/x86/hvm/vmx/vmx.c        |   2 ++
>  xen/arch/x86/hvm/vmx/vpmu_core2.c |  38
> ++++++++++++++++++++++++++++++++++++--
>  xen/arch/x86/hvm/vpmu.c           |  25 ++++++++++++++++++-------
>  xen/include/asm-x86/hvm/vpmu.h    |   6 ++++++
>  5 files changed, 63 insertions(+), 9 deletions(-)
> 
> 
> The  "Debug Store" cpuid flag in the Intel processors gets enabled in the
> libxc.
> A new function call arch_vpmu_cpuid is added to the struct arch_vpmu_ops and
> for
> Intel processors the function core2_vpmu_cpuid() is added.
> The aim is that always a "struct arch_vpmu_ops" is accessible at least with
> a cpuid function to switch off special PMU cpuid flags dynamically depending
> on
> the boot variable opt_vpmu_enabled.

Our CPUID configuration is done per-domain, and from
tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
hypervisor are generally not acceptable without very good reason.

 -- Keir

> Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> 
> diff -r 7a82c2e2eb33 tools/libxc/xc_cpuid_x86.c
> --- a/tools/libxc/xc_cpuid_x86.c Thu Jan 19 13:14:02 2012 +0100
> +++ b/tools/libxc/xc_cpuid_x86.c Thu Jan 19 14:37:17 2012 +0100
> @@ -343,6 +343,7 @@ static void xc_cpuid_hvm_policy(
>                      bitmaskof(X86_FEATURE_CMOV) |
>                      bitmaskof(X86_FEATURE_PAT) |
>                      bitmaskof(X86_FEATURE_CLFLSH) |
> +                    bitmaskof(X86_FEATURE_DS) |
>                      bitmaskof(X86_FEATURE_PSE36) |
>                      bitmaskof(X86_FEATURE_MMX) |
>                      bitmaskof(X86_FEATURE_FXSR) |
> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 13:14:02 2012 +0100
> +++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 14:37:17 2012 +0100
> @@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
>              break;
>      }
>  
> +    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
> +
>      HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
>  }
>  
> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vpmu_core2.c
> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 13:14:02 2012 +0100
> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 14:37:17 2012 +0100
> @@ -598,6 +598,29 @@ static void core2_vpmu_destroy(struct vc
>      vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
>  }
>  
> +/**
> + * core2_vpmu_cpuid - prepare special vpmu cpuid bits
> + * If emulation of vpmu is switched off, some bits are swtiched off,
> currently:
> + * - EAX[0x1].EAX[Bits 0-7]: PMC revision id.
> + * - EAX[0xa].EDX[Bit 21]:   Debug Store
> + */
> +#define bitmaskof(idx)  (1U << ((idx) & 31))
> +static void core2_vpmu_cpuid(unsigned int input,
> +                             unsigned int *eax, unsigned int *ebx,
> +                             unsigned int *ecx, unsigned int *edx)
> +{
> +    switch ( input )
> +    {
> +    case 0x1:
> +        *edx &= ~bitmaskof(X86_FEATURE_DS);    /* Debug Store not supported
> */
> +        break;
> +    case 0xa:
> +        if ( !opt_vpmu_enabled )
> +            *eax &= ~(unsigned int)0xff;       /* Clear pmc version id. */
> +        break;
> +    }
> +}
> +
>  struct arch_vpmu_ops core2_vpmu_ops = {
>      .do_wrmsr = core2_vpmu_do_wrmsr,
>      .do_rdmsr = core2_vpmu_do_rdmsr,
> @@ -605,7 +628,13 @@ struct arch_vpmu_ops core2_vpmu_ops = {
>      .arch_vpmu_initialise = core2_vpmu_initialise,
>      .arch_vpmu_destroy = core2_vpmu_destroy,
>      .arch_vpmu_save = core2_vpmu_save,
> -    .arch_vpmu_load = core2_vpmu_load
> +    .arch_vpmu_load = core2_vpmu_load,
> +    .arch_vpmu_cpuid = core2_vpmu_cpuid
> +};
> +
> +/* Used if vpmu is disabled. */
> +struct arch_vpmu_ops core2_vpmu_dis_ops = {
> +    .arch_vpmu_cpuid = core2_vpmu_cpuid
>  };
>  
>  int vmx_vpmu_initialize(struct vcpu *v)
> @@ -615,7 +644,7 @@ int vmx_vpmu_initialize(struct vcpu *v)
>      __u8 cpu_model = current_cpu_data.x86_model;
>  
>      if ( !opt_vpmu_enabled )
> -        return -EINVAL;
> +        goto func_out;
>  
>      if ( family == 6 )
>      {
> @@ -635,6 +664,11 @@ int vmx_vpmu_initialize(struct vcpu *v)
>      printk("VPMU: Initialization failed. "
>             "Intel processor family %d model %d has not "
>             "been supported\n", family, cpu_model);
> +
> +func_out:
> +
> +    vpmu->arch_vpmu_ops = &core2_vpmu_dis_ops;
> +
>      return -EINVAL;
>  }
>  
> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vpmu.c
> --- a/xen/arch/x86/hvm/vpmu.c Thu Jan 19 13:14:02 2012 +0100
> +++ b/xen/arch/x86/hvm/vpmu.c Thu Jan 19 14:37:17 2012 +0100
> @@ -39,7 +39,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
>          return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content);
>      return 0;
>  }
> @@ -48,7 +48,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
>          return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
>      return 0;
>  }
> @@ -57,7 +57,7 @@ int vpmu_do_interrupt(struct cpu_user_re
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_interrupt )
>          return vpmu->arch_vpmu_ops->do_interrupt(regs);
>      return 0;
>  }
> @@ -66,7 +66,7 @@ void vpmu_save(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_save )
>          vpmu->arch_vpmu_ops->arch_vpmu_save(v);
>  }
>  
> @@ -74,7 +74,7 @@ void vpmu_load(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
>          vpmu->arch_vpmu_ops->arch_vpmu_load(v);
>  }
>  
> @@ -109,7 +109,8 @@ void vpmu_initialise(struct vcpu *v)
>      {
>          vpmu->flags = 0;
>          vpmu->context = NULL;
> -        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
> +        if ( vpmu->arch_vpmu_ops->arch_vpmu_initialise )
> +            vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
>      }
>  }
>  
> @@ -117,7 +118,17 @@ void vpmu_destroy(struct vcpu *v)
>  {
>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>  
> -    if ( vpmu->arch_vpmu_ops )
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>  }
>  
> +void vpmu_do_cpuid(unsigned int input,
> +                   unsigned int *eax, unsigned int *ebx,
> +                   unsigned int *ecx, unsigned int *edx)
> +{
> +    struct vpmu_struct *vpmu = vcpu_vpmu(current);
> +
> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_cpuid)
> +        vpmu->arch_vpmu_ops->arch_vpmu_cpuid(input, eax, ebx, ecx, edx);
> +}
> +
> diff -r 7a82c2e2eb33 xen/include/asm-x86/hvm/vpmu.h
> --- a/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 13:14:02 2012 +0100
> +++ b/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 14:37:17 2012 +0100
> @@ -56,6 +56,9 @@ struct arch_vpmu_ops {
>      void (*arch_vpmu_destroy)(struct vcpu *v);
>      void (*arch_vpmu_save)(struct vcpu *v);
>      void (*arch_vpmu_load)(struct vcpu *v);
> +    void (*arch_vpmu_cpuid)(unsigned int input,
> +                            unsigned int *eax, unsigned int *ebx,
> +                            unsigned int *ecx, unsigned int *edx);
>  };
>  
>  int vmx_vpmu_initialize(struct vcpu *v);
> @@ -78,6 +81,9 @@ void vpmu_initialise(struct vcpu *v);
>  void vpmu_destroy(struct vcpu *v);
>  void vpmu_save(struct vcpu *v);
>  void vpmu_load(struct vcpu *v);
> +void vpmu_do_cpuid(unsigned int input,
> +                   unsigned int *eax, unsigned int *ebx,
> +                   unsigned int *ecx, unsigned int *edx);
>  
>  extern int acquire_pmu_ownership(int pmu_ownership);
>  extern void release_pmu_ownership(int pmu_ownership);



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:32:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoBlj-0006d8-4I; Fri, 20 Jan 2012 10:32: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 1RoBlh-0006cu-In
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:32:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327055538!11822236!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 26137 invoked from network); 20 Jan 2012 10:32:19 -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;
	20 Jan 2012 10:32:19 -0000
Received: by wgbdt11 with SMTP id dt11so344086wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 02:32: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=iMOebQ9XpzjAo0mT34NdQt1kzftZSZnQWxDwBR2pJTM=;
	b=HWwgU2iHCtyDax7ZV74hP5VMz4ZcZdfTeQArI2vHu60gjZU6XC5uVsw+Ihdi2HxE3C
	ZbkyRKuARyp/muMIZrrBnmBfAdgrxzyxOtZvKQXAXmhcO1yVO8cYCJkjDMLR940iknYl
	dO0mu4VGwj2ZOa++pkQmvCa35Ej8TR/F9n1NM=
Received: by 10.180.101.161 with SMTP id fh1mr39799061wib.0.1327055538518;
	Fri, 20 Jan 2012 02:32:18 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id d9sm32795935wiy.2.2012.01.20.02.32.17
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:32:17 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 10:32:14 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB3EF32E.37D38%keir@xen.org>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczXXsZB2GfFLXZUU0+dhU617kZcAA==
In-Reply-To: <4F194C00020000780006DD9C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 10:12, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> Not used in any public header files.
>>> 
>>> One seems to have crept into xen/include/public/arch-x86/hvm/save.h :-(
>> 
>> Thanks, I'll get rid of it. It looks like it should have no effect on that
>> struct anyway.
> 
> While it indeed looks pointless there, all the hvm/save.h headers are
> supposedly tools interface only anyway, so would generally be free
> to use extensions (and are therefore excluded from the ANSI
> correctness test).

True. But since it is not needed and is the only one in the whole public/
directory, I got rid of it anyway.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:32:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:32:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoBlj-0006d8-4I; Fri, 20 Jan 2012 10:32: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 1RoBlh-0006cu-In
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:32:25 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327055538!11822236!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 26137 invoked from network); 20 Jan 2012 10:32:19 -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;
	20 Jan 2012 10:32:19 -0000
Received: by wgbdt11 with SMTP id dt11so344086wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 02:32: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=iMOebQ9XpzjAo0mT34NdQt1kzftZSZnQWxDwBR2pJTM=;
	b=HWwgU2iHCtyDax7ZV74hP5VMz4ZcZdfTeQArI2vHu60gjZU6XC5uVsw+Ihdi2HxE3C
	ZbkyRKuARyp/muMIZrrBnmBfAdgrxzyxOtZvKQXAXmhcO1yVO8cYCJkjDMLR940iknYl
	dO0mu4VGwj2ZOa++pkQmvCa35Ej8TR/F9n1NM=
Received: by 10.180.101.161 with SMTP id fh1mr39799061wib.0.1327055538518;
	Fri, 20 Jan 2012 02:32:18 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id d9sm32795935wiy.2.2012.01.20.02.32.17
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:32:17 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 10:32:14 +0000
From: Keir Fraser <keir@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <CB3EF32E.37D38%keir@xen.org>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczXXsZB2GfFLXZUU0+dhU617kZcAA==
In-Reply-To: <4F194C00020000780006DD9C@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 10:12, "Jan Beulich" <JBeulich@suse.com> wrote:

>>>> Not used in any public header files.
>>> 
>>> One seems to have crept into xen/include/public/arch-x86/hvm/save.h :-(
>> 
>> Thanks, I'll get rid of it. It looks like it should have no effect on that
>> struct anyway.
> 
> While it indeed looks pointless there, all the hvm/save.h headers are
> supposedly tools interface only anyway, so would generally be free
> to use extensions (and are therefore excluded from the ANSI
> correctness test).

True. But since it is not needed and is the only one in the whole public/
directory, I got rid of it anyway.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:50:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoC2Z-0007EO-Uq; Fri, 20 Jan 2012 10:49:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RoC2Y-0007EG-UQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:49:51 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327056584!11794789!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNjEyNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 572 invoked from network); 20 Jan 2012 10:49:44 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 10:49:44 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=M/o72q0fBpp7qtQgqX1pmTR/HsUvCgfF2agr/zajSipjLMJ5ria2DicJ
	atDIJsGB8ew2KGXFj3rp7N7lzyvr+D7btijVAdCFTY5JGFiWJOMBG2O7y
	jDJw4tDuXAcK8wFX0+ib5JJFIUN2g8b9aaARnvVu9nG9+0hJAq/tP7L0s
	ChfohdJNI2tr8NGeR4QzU449Ja/1+Q2/0XmmVD2SmCLdmjNyL0aDmUKfk
	zY+grgkDBJ2HUq5ZQxatt552xku1i;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1327056585; x=1358592585;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=CfTNPLEmHsrQy8/ExEGNTAmd06HSAs70otqIHLzbFyY=;
	b=ZzA9B7L7mpmr+TXibS5v/HHWGwHkTKKsXxasrGm+ZKTascEjwbHMR1DB
	5JBqXkXhxw0HX5IfVpTmKZImctb+p9jRYk5NO68qfci0sj86qjhaOWttj
	V6Ta7wCQ6XECMyd1OvoAf2/T5QuC4priJzzUNI8GLit4Id6dc4xBqBnEq
	Q3iwkwvkEgIoW64h7CcGFdfniebRTGrLuXUAZWN1Nf4VOYpmJASsiiP6g
	M9CXLt9H+aiNMkfLbipEUW2lU/4+z;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="99227595"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 20 Jan 2012 11:49:43 +0100
X-IronPort-AV: E=Sophos;i="4.71,540,1320620400"; d="scan'208";a="127117700"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 20 Jan 2012 11:49:41 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 19C6F95F317;
	Fri, 20 Jan 2012 11:49:42 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Keir Fraser <keir@xen.org>
Date: Fri, 20 Jan 2012 11:49:41 +0100
Message-ID: <8568566.QXZZClQmLn@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CB3EF295.37D36%keir@xen.org>
References: <CB3EF295.37D36%keir@xen.org>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Freitag 20 Januar 2012, 10:29:41 schrieb Keir Fraser:
> On 19/01/2012 13:54, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> 
> > 
> >  tools/libxc/xc_cpuid_x86.c        |   1 +
> >  xen/arch/x86/hvm/vmx/vmx.c        |   2 ++
> >  xen/arch/x86/hvm/vmx/vpmu_core2.c |  38
> > ++++++++++++++++++++++++++++++++++++--
> >  xen/arch/x86/hvm/vpmu.c           |  25 ++++++++++++++++++-------
> >  xen/include/asm-x86/hvm/vpmu.h    |   6 ++++++
> >  5 files changed, 63 insertions(+), 9 deletions(-)
> > 
> > 
> > The  "Debug Store" cpuid flag in the Intel processors gets enabled in the
> > libxc.
> > A new function call arch_vpmu_cpuid is added to the struct arch_vpmu_ops and
> > for
> > Intel processors the function core2_vpmu_cpuid() is added.
> > The aim is that always a "struct arch_vpmu_ops" is accessible at least with
> > a cpuid function to switch off special PMU cpuid flags dynamically depending
> > on
> > the boot variable opt_vpmu_enabled.
> 
> Our CPUID configuration is done per-domain, and from
> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
> hypervisor are generally not acceptable without very good reason.

Then a way is needed to have access to the opt_vpmu_enabled variable within the
hypervisor from the tools to decide the enabling of the flag (is there such a
way?) or the mechanism with the boot variable must be changed.
The opt_vpmu_enabled boot variable was introduced because of a PMU problem in
the Nehalem cpus leading sometimes to hypervisor crashes. But with the done
quirk we never had a crash anymore.
So maybe we can always switch on the vpmu stuff in the hypervisor and add a
flag in the domain configuration when somebody wants to do some performance
tests?

Dietmar.

> 
>  -- Keir
> 
> > Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> > 
> > diff -r 7a82c2e2eb33 tools/libxc/xc_cpuid_x86.c
> > --- a/tools/libxc/xc_cpuid_x86.c Thu Jan 19 13:14:02 2012 +0100
> > +++ b/tools/libxc/xc_cpuid_x86.c Thu Jan 19 14:37:17 2012 +0100
> > @@ -343,6 +343,7 @@ static void xc_cpuid_hvm_policy(
> >                      bitmaskof(X86_FEATURE_CMOV) |
> >                      bitmaskof(X86_FEATURE_PAT) |
> >                      bitmaskof(X86_FEATURE_CLFLSH) |
> > +                    bitmaskof(X86_FEATURE_DS) |
> >                      bitmaskof(X86_FEATURE_PSE36) |
> >                      bitmaskof(X86_FEATURE_MMX) |
> >                      bitmaskof(X86_FEATURE_FXSR) |
> > diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vmx.c
> > --- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 13:14:02 2012 +0100
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 14:37:17 2012 +0100
> > @@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
> >              break;
> >      }
> >  
> > +    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
> > +
> >      HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
> >  }
> >  
> > diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vpmu_core2.c
> > --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 13:14:02 2012 +0100
> > +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 14:37:17 2012 +0100
> > @@ -598,6 +598,29 @@ static void core2_vpmu_destroy(struct vc
> >      vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
> >  }
> >  
> > +/**
> > + * core2_vpmu_cpuid - prepare special vpmu cpuid bits
> > + * If emulation of vpmu is switched off, some bits are swtiched off,
> > currently:
> > + * - EAX[0x1].EAX[Bits 0-7]: PMC revision id.
> > + * - EAX[0xa].EDX[Bit 21]:   Debug Store
> > + */
> > +#define bitmaskof(idx)  (1U << ((idx) & 31))
> > +static void core2_vpmu_cpuid(unsigned int input,
> > +                             unsigned int *eax, unsigned int *ebx,
> > +                             unsigned int *ecx, unsigned int *edx)
> > +{
> > +    switch ( input )
> > +    {
> > +    case 0x1:
> > +        *edx &= ~bitmaskof(X86_FEATURE_DS);    /* Debug Store not supported
> > */
> > +        break;
> > +    case 0xa:
> > +        if ( !opt_vpmu_enabled )
> > +            *eax &= ~(unsigned int)0xff;       /* Clear pmc version id. */
> > +        break;
> > +    }
> > +}
> > +
> >  struct arch_vpmu_ops core2_vpmu_ops = {
> >      .do_wrmsr = core2_vpmu_do_wrmsr,
> >      .do_rdmsr = core2_vpmu_do_rdmsr,
> > @@ -605,7 +628,13 @@ struct arch_vpmu_ops core2_vpmu_ops = {
> >      .arch_vpmu_initialise = core2_vpmu_initialise,
> >      .arch_vpmu_destroy = core2_vpmu_destroy,
> >      .arch_vpmu_save = core2_vpmu_save,
> > -    .arch_vpmu_load = core2_vpmu_load
> > +    .arch_vpmu_load = core2_vpmu_load,
> > +    .arch_vpmu_cpuid = core2_vpmu_cpuid
> > +};
> > +
> > +/* Used if vpmu is disabled. */
> > +struct arch_vpmu_ops core2_vpmu_dis_ops = {
> > +    .arch_vpmu_cpuid = core2_vpmu_cpuid
> >  };
> >  
> >  int vmx_vpmu_initialize(struct vcpu *v)
> > @@ -615,7 +644,7 @@ int vmx_vpmu_initialize(struct vcpu *v)
> >      __u8 cpu_model = current_cpu_data.x86_model;
> >  
> >      if ( !opt_vpmu_enabled )
> > -        return -EINVAL;
> > +        goto func_out;
> >  
> >      if ( family == 6 )
> >      {
> > @@ -635,6 +664,11 @@ int vmx_vpmu_initialize(struct vcpu *v)
> >      printk("VPMU: Initialization failed. "
> >             "Intel processor family %d model %d has not "
> >             "been supported\n", family, cpu_model);
> > +
> > +func_out:
> > +
> > +    vpmu->arch_vpmu_ops = &core2_vpmu_dis_ops;
> > +
> >      return -EINVAL;
> >  }
> >  
> > diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vpmu.c
> > --- a/xen/arch/x86/hvm/vpmu.c Thu Jan 19 13:14:02 2012 +0100
> > +++ b/xen/arch/x86/hvm/vpmu.c Thu Jan 19 14:37:17 2012 +0100
> > @@ -39,7 +39,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(current);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
> >          return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content);
> >      return 0;
> >  }
> > @@ -48,7 +48,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(current);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
> >          return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
> >      return 0;
> >  }
> > @@ -57,7 +57,7 @@ int vpmu_do_interrupt(struct cpu_user_re
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(current);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_interrupt )
> >          return vpmu->arch_vpmu_ops->do_interrupt(regs);
> >      return 0;
> >  }
> > @@ -66,7 +66,7 @@ void vpmu_save(struct vcpu *v)
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_save )
> >          vpmu->arch_vpmu_ops->arch_vpmu_save(v);
> >  }
> >  
> > @@ -74,7 +74,7 @@ void vpmu_load(struct vcpu *v)
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
> >          vpmu->arch_vpmu_ops->arch_vpmu_load(v);
> >  }
> >  
> > @@ -109,7 +109,8 @@ void vpmu_initialise(struct vcpu *v)
> >      {
> >          vpmu->flags = 0;
> >          vpmu->context = NULL;
> > -        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
> > +        if ( vpmu->arch_vpmu_ops->arch_vpmu_initialise )
> > +            vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
> >      }
> >  }
> >  
> > @@ -117,7 +118,17 @@ void vpmu_destroy(struct vcpu *v)
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
> >          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
> >  }
> >  
> > +void vpmu_do_cpuid(unsigned int input,
> > +                   unsigned int *eax, unsigned int *ebx,
> > +                   unsigned int *ecx, unsigned int *edx)
> > +{
> > +    struct vpmu_struct *vpmu = vcpu_vpmu(current);
> > +
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_cpuid)
> > +        vpmu->arch_vpmu_ops->arch_vpmu_cpuid(input, eax, ebx, ecx, edx);
> > +}
> > +
> > diff -r 7a82c2e2eb33 xen/include/asm-x86/hvm/vpmu.h
> > --- a/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 13:14:02 2012 +0100
> > +++ b/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 14:37:17 2012 +0100
> > @@ -56,6 +56,9 @@ struct arch_vpmu_ops {
> >      void (*arch_vpmu_destroy)(struct vcpu *v);
> >      void (*arch_vpmu_save)(struct vcpu *v);
> >      void (*arch_vpmu_load)(struct vcpu *v);
> > +    void (*arch_vpmu_cpuid)(unsigned int input,
> > +                            unsigned int *eax, unsigned int *ebx,
> > +                            unsigned int *ecx, unsigned int *edx);
> >  };
> >  
> >  int vmx_vpmu_initialize(struct vcpu *v);
> > @@ -78,6 +81,9 @@ void vpmu_initialise(struct vcpu *v);
> >  void vpmu_destroy(struct vcpu *v);
> >  void vpmu_save(struct vcpu *v);
> >  void vpmu_load(struct vcpu *v);
> > +void vpmu_do_cpuid(unsigned int input,
> > +                   unsigned int *eax, unsigned int *ebx,
> > +                   unsigned int *ecx, unsigned int *edx);
> >  
> >  extern int acquire_pmu_ownership(int pmu_ownership);
> >  extern void release_pmu_ownership(int pmu_ownership);
> 
> 
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:50:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoC2Z-0007EO-Uq; Fri, 20 Jan 2012 10:49:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RoC2Y-0007EG-UQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:49:51 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327056584!11794789!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNjEyNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 572 invoked from network); 20 Jan 2012 10:49:44 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 10:49:44 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=M/o72q0fBpp7qtQgqX1pmTR/HsUvCgfF2agr/zajSipjLMJ5ria2DicJ
	atDIJsGB8ew2KGXFj3rp7N7lzyvr+D7btijVAdCFTY5JGFiWJOMBG2O7y
	jDJw4tDuXAcK8wFX0+ib5JJFIUN2g8b9aaARnvVu9nG9+0hJAq/tP7L0s
	ChfohdJNI2tr8NGeR4QzU449Ja/1+Q2/0XmmVD2SmCLdmjNyL0aDmUKfk
	zY+grgkDBJ2HUq5ZQxatt552xku1i;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1327056585; x=1358592585;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=CfTNPLEmHsrQy8/ExEGNTAmd06HSAs70otqIHLzbFyY=;
	b=ZzA9B7L7mpmr+TXibS5v/HHWGwHkTKKsXxasrGm+ZKTascEjwbHMR1DB
	5JBqXkXhxw0HX5IfVpTmKZImctb+p9jRYk5NO68qfci0sj86qjhaOWttj
	V6Ta7wCQ6XECMyd1OvoAf2/T5QuC4priJzzUNI8GLit4Id6dc4xBqBnEq
	Q3iwkwvkEgIoW64h7CcGFdfniebRTGrLuXUAZWN1Nf4VOYpmJASsiiP6g
	M9CXLt9H+aiNMkfLbipEUW2lU/4+z;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="99227595"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 20 Jan 2012 11:49:43 +0100
X-IronPort-AV: E=Sophos;i="4.71,540,1320620400"; d="scan'208";a="127117700"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 20 Jan 2012 11:49:41 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 19C6F95F317;
	Fri, 20 Jan 2012 11:49:42 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Keir Fraser <keir@xen.org>
Date: Fri, 20 Jan 2012 11:49:41 +0100
Message-ID: <8568566.QXZZClQmLn@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CB3EF295.37D36%keir@xen.org>
References: <CB3EF295.37D36%keir@xen.org>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Freitag 20 Januar 2012, 10:29:41 schrieb Keir Fraser:
> On 19/01/2012 13:54, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> 
> > 
> >  tools/libxc/xc_cpuid_x86.c        |   1 +
> >  xen/arch/x86/hvm/vmx/vmx.c        |   2 ++
> >  xen/arch/x86/hvm/vmx/vpmu_core2.c |  38
> > ++++++++++++++++++++++++++++++++++++--
> >  xen/arch/x86/hvm/vpmu.c           |  25 ++++++++++++++++++-------
> >  xen/include/asm-x86/hvm/vpmu.h    |   6 ++++++
> >  5 files changed, 63 insertions(+), 9 deletions(-)
> > 
> > 
> > The  "Debug Store" cpuid flag in the Intel processors gets enabled in the
> > libxc.
> > A new function call arch_vpmu_cpuid is added to the struct arch_vpmu_ops and
> > for
> > Intel processors the function core2_vpmu_cpuid() is added.
> > The aim is that always a "struct arch_vpmu_ops" is accessible at least with
> > a cpuid function to switch off special PMU cpuid flags dynamically depending
> > on
> > the boot variable opt_vpmu_enabled.
> 
> Our CPUID configuration is done per-domain, and from
> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
> hypervisor are generally not acceptable without very good reason.

Then a way is needed to have access to the opt_vpmu_enabled variable within the
hypervisor from the tools to decide the enabling of the flag (is there such a
way?) or the mechanism with the boot variable must be changed.
The opt_vpmu_enabled boot variable was introduced because of a PMU problem in
the Nehalem cpus leading sometimes to hypervisor crashes. But with the done
quirk we never had a crash anymore.
So maybe we can always switch on the vpmu stuff in the hypervisor and add a
flag in the domain configuration when somebody wants to do some performance
tests?

Dietmar.

> 
>  -- Keir
> 
> > Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> > 
> > diff -r 7a82c2e2eb33 tools/libxc/xc_cpuid_x86.c
> > --- a/tools/libxc/xc_cpuid_x86.c Thu Jan 19 13:14:02 2012 +0100
> > +++ b/tools/libxc/xc_cpuid_x86.c Thu Jan 19 14:37:17 2012 +0100
> > @@ -343,6 +343,7 @@ static void xc_cpuid_hvm_policy(
> >                      bitmaskof(X86_FEATURE_CMOV) |
> >                      bitmaskof(X86_FEATURE_PAT) |
> >                      bitmaskof(X86_FEATURE_CLFLSH) |
> > +                    bitmaskof(X86_FEATURE_DS) |
> >                      bitmaskof(X86_FEATURE_PSE36) |
> >                      bitmaskof(X86_FEATURE_MMX) |
> >                      bitmaskof(X86_FEATURE_FXSR) |
> > diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vmx.c
> > --- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 13:14:02 2012 +0100
> > +++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 14:37:17 2012 +0100
> > @@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
> >              break;
> >      }
> >  
> > +    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
> > +
> >      HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
> >  }
> >  
> > diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vpmu_core2.c
> > --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 13:14:02 2012 +0100
> > +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 14:37:17 2012 +0100
> > @@ -598,6 +598,29 @@ static void core2_vpmu_destroy(struct vc
> >      vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
> >  }
> >  
> > +/**
> > + * core2_vpmu_cpuid - prepare special vpmu cpuid bits
> > + * If emulation of vpmu is switched off, some bits are swtiched off,
> > currently:
> > + * - EAX[0x1].EAX[Bits 0-7]: PMC revision id.
> > + * - EAX[0xa].EDX[Bit 21]:   Debug Store
> > + */
> > +#define bitmaskof(idx)  (1U << ((idx) & 31))
> > +static void core2_vpmu_cpuid(unsigned int input,
> > +                             unsigned int *eax, unsigned int *ebx,
> > +                             unsigned int *ecx, unsigned int *edx)
> > +{
> > +    switch ( input )
> > +    {
> > +    case 0x1:
> > +        *edx &= ~bitmaskof(X86_FEATURE_DS);    /* Debug Store not supported
> > */
> > +        break;
> > +    case 0xa:
> > +        if ( !opt_vpmu_enabled )
> > +            *eax &= ~(unsigned int)0xff;       /* Clear pmc version id. */
> > +        break;
> > +    }
> > +}
> > +
> >  struct arch_vpmu_ops core2_vpmu_ops = {
> >      .do_wrmsr = core2_vpmu_do_wrmsr,
> >      .do_rdmsr = core2_vpmu_do_rdmsr,
> > @@ -605,7 +628,13 @@ struct arch_vpmu_ops core2_vpmu_ops = {
> >      .arch_vpmu_initialise = core2_vpmu_initialise,
> >      .arch_vpmu_destroy = core2_vpmu_destroy,
> >      .arch_vpmu_save = core2_vpmu_save,
> > -    .arch_vpmu_load = core2_vpmu_load
> > +    .arch_vpmu_load = core2_vpmu_load,
> > +    .arch_vpmu_cpuid = core2_vpmu_cpuid
> > +};
> > +
> > +/* Used if vpmu is disabled. */
> > +struct arch_vpmu_ops core2_vpmu_dis_ops = {
> > +    .arch_vpmu_cpuid = core2_vpmu_cpuid
> >  };
> >  
> >  int vmx_vpmu_initialize(struct vcpu *v)
> > @@ -615,7 +644,7 @@ int vmx_vpmu_initialize(struct vcpu *v)
> >      __u8 cpu_model = current_cpu_data.x86_model;
> >  
> >      if ( !opt_vpmu_enabled )
> > -        return -EINVAL;
> > +        goto func_out;
> >  
> >      if ( family == 6 )
> >      {
> > @@ -635,6 +664,11 @@ int vmx_vpmu_initialize(struct vcpu *v)
> >      printk("VPMU: Initialization failed. "
> >             "Intel processor family %d model %d has not "
> >             "been supported\n", family, cpu_model);
> > +
> > +func_out:
> > +
> > +    vpmu->arch_vpmu_ops = &core2_vpmu_dis_ops;
> > +
> >      return -EINVAL;
> >  }
> >  
> > diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vpmu.c
> > --- a/xen/arch/x86/hvm/vpmu.c Thu Jan 19 13:14:02 2012 +0100
> > +++ b/xen/arch/x86/hvm/vpmu.c Thu Jan 19 14:37:17 2012 +0100
> > @@ -39,7 +39,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(current);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
> >          return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content);
> >      return 0;
> >  }
> > @@ -48,7 +48,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(current);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
> >          return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
> >      return 0;
> >  }
> > @@ -57,7 +57,7 @@ int vpmu_do_interrupt(struct cpu_user_re
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(current);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_interrupt )
> >          return vpmu->arch_vpmu_ops->do_interrupt(regs);
> >      return 0;
> >  }
> > @@ -66,7 +66,7 @@ void vpmu_save(struct vcpu *v)
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_save )
> >          vpmu->arch_vpmu_ops->arch_vpmu_save(v);
> >  }
> >  
> > @@ -74,7 +74,7 @@ void vpmu_load(struct vcpu *v)
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
> >          vpmu->arch_vpmu_ops->arch_vpmu_load(v);
> >  }
> >  
> > @@ -109,7 +109,8 @@ void vpmu_initialise(struct vcpu *v)
> >      {
> >          vpmu->flags = 0;
> >          vpmu->context = NULL;
> > -        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
> > +        if ( vpmu->arch_vpmu_ops->arch_vpmu_initialise )
> > +            vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
> >      }
> >  }
> >  
> > @@ -117,7 +118,17 @@ void vpmu_destroy(struct vcpu *v)
> >  {
> >      struct vpmu_struct *vpmu = vcpu_vpmu(v);
> >  
> > -    if ( vpmu->arch_vpmu_ops )
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
> >          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
> >  }
> >  
> > +void vpmu_do_cpuid(unsigned int input,
> > +                   unsigned int *eax, unsigned int *ebx,
> > +                   unsigned int *ecx, unsigned int *edx)
> > +{
> > +    struct vpmu_struct *vpmu = vcpu_vpmu(current);
> > +
> > +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_cpuid)
> > +        vpmu->arch_vpmu_ops->arch_vpmu_cpuid(input, eax, ebx, ecx, edx);
> > +}
> > +
> > diff -r 7a82c2e2eb33 xen/include/asm-x86/hvm/vpmu.h
> > --- a/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 13:14:02 2012 +0100
> > +++ b/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 14:37:17 2012 +0100
> > @@ -56,6 +56,9 @@ struct arch_vpmu_ops {
> >      void (*arch_vpmu_destroy)(struct vcpu *v);
> >      void (*arch_vpmu_save)(struct vcpu *v);
> >      void (*arch_vpmu_load)(struct vcpu *v);
> > +    void (*arch_vpmu_cpuid)(unsigned int input,
> > +                            unsigned int *eax, unsigned int *ebx,
> > +                            unsigned int *ecx, unsigned int *edx);
> >  };
> >  
> >  int vmx_vpmu_initialize(struct vcpu *v);
> > @@ -78,6 +81,9 @@ void vpmu_initialise(struct vcpu *v);
> >  void vpmu_destroy(struct vcpu *v);
> >  void vpmu_save(struct vcpu *v);
> >  void vpmu_load(struct vcpu *v);
> > +void vpmu_do_cpuid(unsigned int input,
> > +                   unsigned int *eax, unsigned int *ebx,
> > +                   unsigned int *ecx, unsigned int *edx);
> >  
> >  extern int acquire_pmu_ownership(int pmu_ownership);
> >  extern void release_pmu_ownership(int pmu_ownership);
> 
> 
> 
-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:51:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoC3z-0007JP-9q; Fri, 20 Jan 2012 10:51: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 1RoC3x-0007Iz-PC
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:51:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327056671!5747185!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 15207 invoked from network); 20 Jan 2012 10:51:11 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 10:51:11 -0000
Received: by wgbdt11 with SMTP id dt11so361916wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 02:51:11 -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=38i5RS/tgdTqYvmbxnpWjgjDvIH1YG0aFS/CrD3sLWs=;
	b=Db+EkJDph0ZcpZPSZIsQOs5nvm4EdPsM2L9xqARx8WPS6Br5C6l0badoU72Ym1Ehyn
	t9QWaxWjOrFiDtVbhDwMOQNr8tNdeCylwLHWWGZa/8Xvabag7LYFYs/+rBJEYlzgdtsv
	fgzkrouJCl8FJI14u1R9wW4/iQQEihVtWUj8g=
Received: by 10.180.87.100 with SMTP id w4mr24842201wiz.13.1327056671100;
	Fri, 20 Jan 2012 02:51:11 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id d9sm32882844wiy.2.2012.01.20.02.51.09
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:51:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 10:50:59 +0000
From: Keir Fraser <keir@xen.org>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB3EF793.37D52%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXXmsPJpwifHC+ckWBFE+sU7P7ZAAAvnA5
In-Reply-To: <CB3EF295.37D36%keir@xen.org>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 10:29, "Keir Fraser" <keir@xen.org> wrote:

>> The  "Debug Store" cpuid flag in the Intel processors gets enabled in the
>> libxc.
>> A new function call arch_vpmu_cpuid is added to the struct arch_vpmu_ops and
>> for
>> Intel processors the function core2_vpmu_cpuid() is added.
>> The aim is that always a "struct arch_vpmu_ops" is accessible at least with
>> a cpuid function to switch off special PMU cpuid flags dynamically depending
>> on
>> the boot variable opt_vpmu_enabled.
> 
> Our CPUID configuration is done per-domain, and from
> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
> hypervisor are generally not acceptable without very good reason.

I'll preempt you saying that you need to depend on opt_vpmu_enabled by
saying you should get rid of that hacky global configuration flag, and allow
VPMU to be properly enabled per domain, via the toolstack. Then
configuration via libxc/xc_cpuid_x86.c will fall naturally into place.
Perhaps you can allow configuration straightforwardly via the existing
libxl_cpuid.c mechanism, or perhaps you need a higher-level config option
than that, and then cook it down into CPUID fiddling from within libxl, or
libxc. One of the toolstack maintainers (Ian Jackson for example) may have
better ideas than me on that.

Also, there are AMD- and Intel-specific sections to xc_cpuid_x86.c for HVM
guests -- {amd,intel}_xc_cpuid_policy(). You can use those to set flags
differently for the two vendors.

>  -- Keir
> 
>> Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
>> 
>> diff -r 7a82c2e2eb33 tools/libxc/xc_cpuid_x86.c
>> --- a/tools/libxc/xc_cpuid_x86.c Thu Jan 19 13:14:02 2012 +0100
>> +++ b/tools/libxc/xc_cpuid_x86.c Thu Jan 19 14:37:17 2012 +0100
>> @@ -343,6 +343,7 @@ static void xc_cpuid_hvm_policy(
>>                      bitmaskof(X86_FEATURE_CMOV) |
>>                      bitmaskof(X86_FEATURE_PAT) |
>>                      bitmaskof(X86_FEATURE_CLFLSH) |
>> +                    bitmaskof(X86_FEATURE_DS) |
>>                      bitmaskof(X86_FEATURE_PSE36) |
>>                      bitmaskof(X86_FEATURE_MMX) |
>>                      bitmaskof(X86_FEATURE_FXSR) |
>> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vmx.c
>> --- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 13:14:02 2012 +0100
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 14:37:17 2012 +0100
>> @@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
>>              break;
>>      }
>>  
>> +    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
>> +
>>      HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
>>  }
>>  
>> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vpmu_core2.c
>> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 13:14:02 2012 +0100
>> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 14:37:17 2012 +0100
>> @@ -598,6 +598,29 @@ static void core2_vpmu_destroy(struct vc
>>      vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
>>  }
>>  
>> +/**
>> + * core2_vpmu_cpuid - prepare special vpmu cpuid bits
>> + * If emulation of vpmu is switched off, some bits are swtiched off,
>> currently:
>> + * - EAX[0x1].EAX[Bits 0-7]: PMC revision id.
>> + * - EAX[0xa].EDX[Bit 21]:   Debug Store
>> + */
>> +#define bitmaskof(idx)  (1U << ((idx) & 31))
>> +static void core2_vpmu_cpuid(unsigned int input,
>> +                             unsigned int *eax, unsigned int *ebx,
>> +                             unsigned int *ecx, unsigned int *edx)
>> +{
>> +    switch ( input )
>> +    {
>> +    case 0x1:
>> +        *edx &= ~bitmaskof(X86_FEATURE_DS);    /* Debug Store not supported
>> */
>> +        break;
>> +    case 0xa:
>> +        if ( !opt_vpmu_enabled )
>> +            *eax &= ~(unsigned int)0xff;       /* Clear pmc version id. */
>> +        break;
>> +    }
>> +}
>> +
>>  struct arch_vpmu_ops core2_vpmu_ops = {
>>      .do_wrmsr = core2_vpmu_do_wrmsr,
>>      .do_rdmsr = core2_vpmu_do_rdmsr,
>> @@ -605,7 +628,13 @@ struct arch_vpmu_ops core2_vpmu_ops = {
>>      .arch_vpmu_initialise = core2_vpmu_initialise,
>>      .arch_vpmu_destroy = core2_vpmu_destroy,
>>      .arch_vpmu_save = core2_vpmu_save,
>> -    .arch_vpmu_load = core2_vpmu_load
>> +    .arch_vpmu_load = core2_vpmu_load,
>> +    .arch_vpmu_cpuid = core2_vpmu_cpuid
>> +};
>> +
>> +/* Used if vpmu is disabled. */
>> +struct arch_vpmu_ops core2_vpmu_dis_ops = {
>> +    .arch_vpmu_cpuid = core2_vpmu_cpuid
>>  };
>>  
>>  int vmx_vpmu_initialize(struct vcpu *v)
>> @@ -615,7 +644,7 @@ int vmx_vpmu_initialize(struct vcpu *v)
>>      __u8 cpu_model = current_cpu_data.x86_model;
>>  
>>      if ( !opt_vpmu_enabled )
>> -        return -EINVAL;
>> +        goto func_out;
>>  
>>      if ( family == 6 )
>>      {
>> @@ -635,6 +664,11 @@ int vmx_vpmu_initialize(struct vcpu *v)
>>      printk("VPMU: Initialization failed. "
>>             "Intel processor family %d model %d has not "
>>             "been supported\n", family, cpu_model);
>> +
>> +func_out:
>> +
>> +    vpmu->arch_vpmu_ops = &core2_vpmu_dis_ops;
>> +
>>      return -EINVAL;
>>  }
>>  
>> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vpmu.c
>> --- a/xen/arch/x86/hvm/vpmu.c Thu Jan 19 13:14:02 2012 +0100
>> +++ b/xen/arch/x86/hvm/vpmu.c Thu Jan 19 14:37:17 2012 +0100
>> @@ -39,7 +39,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
>>          return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content);
>>      return 0;
>>  }
>> @@ -48,7 +48,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
>>          return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
>>      return 0;
>>  }
>> @@ -57,7 +57,7 @@ int vpmu_do_interrupt(struct cpu_user_re
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_interrupt )
>>          return vpmu->arch_vpmu_ops->do_interrupt(regs);
>>      return 0;
>>  }
>> @@ -66,7 +66,7 @@ void vpmu_save(struct vcpu *v)
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_save )
>>          vpmu->arch_vpmu_ops->arch_vpmu_save(v);
>>  }
>>  
>> @@ -74,7 +74,7 @@ void vpmu_load(struct vcpu *v)
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
>>          vpmu->arch_vpmu_ops->arch_vpmu_load(v);
>>  }
>>  
>> @@ -109,7 +109,8 @@ void vpmu_initialise(struct vcpu *v)
>>      {
>>          vpmu->flags = 0;
>>          vpmu->context = NULL;
>> -        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
>> +        if ( vpmu->arch_vpmu_ops->arch_vpmu_initialise )
>> +            vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
>>      }
>>  }
>>  
>> @@ -117,7 +118,17 @@ void vpmu_destroy(struct vcpu *v)
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>>  }
>>  
>> +void vpmu_do_cpuid(unsigned int input,
>> +                   unsigned int *eax, unsigned int *ebx,
>> +                   unsigned int *ecx, unsigned int *edx)
>> +{
>> +    struct vpmu_struct *vpmu = vcpu_vpmu(current);
>> +
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_cpuid)
>> +        vpmu->arch_vpmu_ops->arch_vpmu_cpuid(input, eax, ebx, ecx, edx);
>> +}
>> +
>> diff -r 7a82c2e2eb33 xen/include/asm-x86/hvm/vpmu.h
>> --- a/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 13:14:02 2012 +0100
>> +++ b/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 14:37:17 2012 +0100
>> @@ -56,6 +56,9 @@ struct arch_vpmu_ops {
>>      void (*arch_vpmu_destroy)(struct vcpu *v);
>>      void (*arch_vpmu_save)(struct vcpu *v);
>>      void (*arch_vpmu_load)(struct vcpu *v);
>> +    void (*arch_vpmu_cpuid)(unsigned int input,
>> +                            unsigned int *eax, unsigned int *ebx,
>> +                            unsigned int *ecx, unsigned int *edx);
>>  };
>>  
>>  int vmx_vpmu_initialize(struct vcpu *v);
>> @@ -78,6 +81,9 @@ void vpmu_initialise(struct vcpu *v);
>>  void vpmu_destroy(struct vcpu *v);
>>  void vpmu_save(struct vcpu *v);
>>  void vpmu_load(struct vcpu *v);
>> +void vpmu_do_cpuid(unsigned int input,
>> +                   unsigned int *eax, unsigned int *ebx,
>> +                   unsigned int *ecx, unsigned int *edx);
>>  
>>  extern int acquire_pmu_ownership(int pmu_ownership);
>>  extern void release_pmu_ownership(int pmu_ownership);
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:51:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:51:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoC3z-0007JP-9q; Fri, 20 Jan 2012 10:51: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 1RoC3x-0007Iz-PC
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:51:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327056671!5747185!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 15207 invoked from network); 20 Jan 2012 10:51:11 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 10:51:11 -0000
Received: by wgbdt11 with SMTP id dt11so361916wgb.24
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 02:51:11 -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=38i5RS/tgdTqYvmbxnpWjgjDvIH1YG0aFS/CrD3sLWs=;
	b=Db+EkJDph0ZcpZPSZIsQOs5nvm4EdPsM2L9xqARx8WPS6Br5C6l0badoU72Ym1Ehyn
	t9QWaxWjOrFiDtVbhDwMOQNr8tNdeCylwLHWWGZa/8Xvabag7LYFYs/+rBJEYlzgdtsv
	fgzkrouJCl8FJI14u1R9wW4/iQQEihVtWUj8g=
Received: by 10.180.87.100 with SMTP id w4mr24842201wiz.13.1327056671100;
	Fri, 20 Jan 2012 02:51:11 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id d9sm32882844wiy.2.2012.01.20.02.51.09
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:51:10 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 10:50:59 +0000
From: Keir Fraser <keir@xen.org>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB3EF793.37D52%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXXmsPJpwifHC+ckWBFE+sU7P7ZAAAvnA5
In-Reply-To: <CB3EF295.37D36%keir@xen.org>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 10:29, "Keir Fraser" <keir@xen.org> wrote:

>> The  "Debug Store" cpuid flag in the Intel processors gets enabled in the
>> libxc.
>> A new function call arch_vpmu_cpuid is added to the struct arch_vpmu_ops and
>> for
>> Intel processors the function core2_vpmu_cpuid() is added.
>> The aim is that always a "struct arch_vpmu_ops" is accessible at least with
>> a cpuid function to switch off special PMU cpuid flags dynamically depending
>> on
>> the boot variable opt_vpmu_enabled.
> 
> Our CPUID configuration is done per-domain, and from
> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
> hypervisor are generally not acceptable without very good reason.

I'll preempt you saying that you need to depend on opt_vpmu_enabled by
saying you should get rid of that hacky global configuration flag, and allow
VPMU to be properly enabled per domain, via the toolstack. Then
configuration via libxc/xc_cpuid_x86.c will fall naturally into place.
Perhaps you can allow configuration straightforwardly via the existing
libxl_cpuid.c mechanism, or perhaps you need a higher-level config option
than that, and then cook it down into CPUID fiddling from within libxl, or
libxc. One of the toolstack maintainers (Ian Jackson for example) may have
better ideas than me on that.

Also, there are AMD- and Intel-specific sections to xc_cpuid_x86.c for HVM
guests -- {amd,intel}_xc_cpuid_policy(). You can use those to set flags
differently for the two vendors.

>  -- Keir
> 
>> Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
>> 
>> diff -r 7a82c2e2eb33 tools/libxc/xc_cpuid_x86.c
>> --- a/tools/libxc/xc_cpuid_x86.c Thu Jan 19 13:14:02 2012 +0100
>> +++ b/tools/libxc/xc_cpuid_x86.c Thu Jan 19 14:37:17 2012 +0100
>> @@ -343,6 +343,7 @@ static void xc_cpuid_hvm_policy(
>>                      bitmaskof(X86_FEATURE_CMOV) |
>>                      bitmaskof(X86_FEATURE_PAT) |
>>                      bitmaskof(X86_FEATURE_CLFLSH) |
>> +                    bitmaskof(X86_FEATURE_DS) |
>>                      bitmaskof(X86_FEATURE_PSE36) |
>>                      bitmaskof(X86_FEATURE_MMX) |
>>                      bitmaskof(X86_FEATURE_FXSR) |
>> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vmx.c
>> --- a/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 13:14:02 2012 +0100
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c Thu Jan 19 14:37:17 2012 +0100
>> @@ -1603,6 +1603,8 @@ static void vmx_cpuid_intercept(
>>              break;
>>      }
>>  
>> +    vpmu_do_cpuid(input, eax, ebx, ecx, edx);
>> +
>>      HVMTRACE_5D (CPUID, input, *eax, *ebx, *ecx, *edx);
>>  }
>>  
>> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vmx/vpmu_core2.c
>> --- a/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 13:14:02 2012 +0100
>> +++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c Thu Jan 19 14:37:17 2012 +0100
>> @@ -598,6 +598,29 @@ static void core2_vpmu_destroy(struct vc
>>      vpmu->flags &= ~VPMU_CONTEXT_ALLOCATED;
>>  }
>>  
>> +/**
>> + * core2_vpmu_cpuid - prepare special vpmu cpuid bits
>> + * If emulation of vpmu is switched off, some bits are swtiched off,
>> currently:
>> + * - EAX[0x1].EAX[Bits 0-7]: PMC revision id.
>> + * - EAX[0xa].EDX[Bit 21]:   Debug Store
>> + */
>> +#define bitmaskof(idx)  (1U << ((idx) & 31))
>> +static void core2_vpmu_cpuid(unsigned int input,
>> +                             unsigned int *eax, unsigned int *ebx,
>> +                             unsigned int *ecx, unsigned int *edx)
>> +{
>> +    switch ( input )
>> +    {
>> +    case 0x1:
>> +        *edx &= ~bitmaskof(X86_FEATURE_DS);    /* Debug Store not supported
>> */
>> +        break;
>> +    case 0xa:
>> +        if ( !opt_vpmu_enabled )
>> +            *eax &= ~(unsigned int)0xff;       /* Clear pmc version id. */
>> +        break;
>> +    }
>> +}
>> +
>>  struct arch_vpmu_ops core2_vpmu_ops = {
>>      .do_wrmsr = core2_vpmu_do_wrmsr,
>>      .do_rdmsr = core2_vpmu_do_rdmsr,
>> @@ -605,7 +628,13 @@ struct arch_vpmu_ops core2_vpmu_ops = {
>>      .arch_vpmu_initialise = core2_vpmu_initialise,
>>      .arch_vpmu_destroy = core2_vpmu_destroy,
>>      .arch_vpmu_save = core2_vpmu_save,
>> -    .arch_vpmu_load = core2_vpmu_load
>> +    .arch_vpmu_load = core2_vpmu_load,
>> +    .arch_vpmu_cpuid = core2_vpmu_cpuid
>> +};
>> +
>> +/* Used if vpmu is disabled. */
>> +struct arch_vpmu_ops core2_vpmu_dis_ops = {
>> +    .arch_vpmu_cpuid = core2_vpmu_cpuid
>>  };
>>  
>>  int vmx_vpmu_initialize(struct vcpu *v)
>> @@ -615,7 +644,7 @@ int vmx_vpmu_initialize(struct vcpu *v)
>>      __u8 cpu_model = current_cpu_data.x86_model;
>>  
>>      if ( !opt_vpmu_enabled )
>> -        return -EINVAL;
>> +        goto func_out;
>>  
>>      if ( family == 6 )
>>      {
>> @@ -635,6 +664,11 @@ int vmx_vpmu_initialize(struct vcpu *v)
>>      printk("VPMU: Initialization failed. "
>>             "Intel processor family %d model %d has not "
>>             "been supported\n", family, cpu_model);
>> +
>> +func_out:
>> +
>> +    vpmu->arch_vpmu_ops = &core2_vpmu_dis_ops;
>> +
>>      return -EINVAL;
>>  }
>>  
>> diff -r 7a82c2e2eb33 xen/arch/x86/hvm/vpmu.c
>> --- a/xen/arch/x86/hvm/vpmu.c Thu Jan 19 13:14:02 2012 +0100
>> +++ b/xen/arch/x86/hvm/vpmu.c Thu Jan 19 14:37:17 2012 +0100
>> @@ -39,7 +39,7 @@ int vpmu_do_wrmsr(unsigned int msr, uint
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
>>          return vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content);
>>      return 0;
>>  }
>> @@ -48,7 +48,7 @@ int vpmu_do_rdmsr(unsigned int msr, uint
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
>>          return vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
>>      return 0;
>>  }
>> @@ -57,7 +57,7 @@ int vpmu_do_interrupt(struct cpu_user_re
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(current);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_interrupt )
>>          return vpmu->arch_vpmu_ops->do_interrupt(regs);
>>      return 0;
>>  }
>> @@ -66,7 +66,7 @@ void vpmu_save(struct vcpu *v)
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_save )
>>          vpmu->arch_vpmu_ops->arch_vpmu_save(v);
>>  }
>>  
>> @@ -74,7 +74,7 @@ void vpmu_load(struct vcpu *v)
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_load )
>>          vpmu->arch_vpmu_ops->arch_vpmu_load(v);
>>  }
>>  
>> @@ -109,7 +109,8 @@ void vpmu_initialise(struct vcpu *v)
>>      {
>>          vpmu->flags = 0;
>>          vpmu->context = NULL;
>> -        vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
>> +        if ( vpmu->arch_vpmu_ops->arch_vpmu_initialise )
>> +            vpmu->arch_vpmu_ops->arch_vpmu_initialise(v);
>>      }
>>  }
>>  
>> @@ -117,7 +118,17 @@ void vpmu_destroy(struct vcpu *v)
>>  {
>>      struct vpmu_struct *vpmu = vcpu_vpmu(v);
>>  
>> -    if ( vpmu->arch_vpmu_ops )
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>>          vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>>  }
>>  
>> +void vpmu_do_cpuid(unsigned int input,
>> +                   unsigned int *eax, unsigned int *ebx,
>> +                   unsigned int *ecx, unsigned int *edx)
>> +{
>> +    struct vpmu_struct *vpmu = vcpu_vpmu(current);
>> +
>> +    if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_cpuid)
>> +        vpmu->arch_vpmu_ops->arch_vpmu_cpuid(input, eax, ebx, ecx, edx);
>> +}
>> +
>> diff -r 7a82c2e2eb33 xen/include/asm-x86/hvm/vpmu.h
>> --- a/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 13:14:02 2012 +0100
>> +++ b/xen/include/asm-x86/hvm/vpmu.h Thu Jan 19 14:37:17 2012 +0100
>> @@ -56,6 +56,9 @@ struct arch_vpmu_ops {
>>      void (*arch_vpmu_destroy)(struct vcpu *v);
>>      void (*arch_vpmu_save)(struct vcpu *v);
>>      void (*arch_vpmu_load)(struct vcpu *v);
>> +    void (*arch_vpmu_cpuid)(unsigned int input,
>> +                            unsigned int *eax, unsigned int *ebx,
>> +                            unsigned int *ecx, unsigned int *edx);
>>  };
>>  
>>  int vmx_vpmu_initialize(struct vcpu *v);
>> @@ -78,6 +81,9 @@ void vpmu_initialise(struct vcpu *v);
>>  void vpmu_destroy(struct vcpu *v);
>>  void vpmu_save(struct vcpu *v);
>>  void vpmu_load(struct vcpu *v);
>> +void vpmu_do_cpuid(unsigned int input,
>> +                   unsigned int *eax, unsigned int *ebx,
>> +                   unsigned int *ecx, unsigned int *edx);
>>  
>>  extern int acquire_pmu_ownership(int pmu_ownership);
>>  extern void release_pmu_ownership(int pmu_ownership);
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:54:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoC76-0007UN-U7; Fri, 20 Jan 2012 10:54:32 +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 1RoC75-0007U6-0G
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:54:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327056864!11830660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31583 invoked from network); 20 Jan 2012 10:54:24 -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 Jan 2012 10:54:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10173842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 10:54:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 10:54:23 +0000
Date: Fri, 20 Jan 2012 10:55:07 +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: <1327046368.21391.29.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2017795904-1327056645=:3150"
Content-ID: <alpine.DEB.2.00.1201201051220.3150@kaball-desktop>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-2017795904-1327056645=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1201201051221.3150@kaball-desktop>

On Fri, 20 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 21:14 +0000, Pasi Kärkkäinen wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > 
> > > Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > > must haves e.g. in the paging/sharing spaces?
> > > 
> > 
> > Something that I just remembered:
> > http://wiki.xen.org/xenwiki/Xen4.1
> > 
> > "NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate
> > equal amount of memory from every NUMA node for the VM. xm/xend
> > allocates all the memory from the same NUMA node."
> 
> I'm not that familiar with the NUMA support but my understanding was
> that memory was allocated by libxc/the-hypervisor and not by the
> toolstack and that the default was to allocate from the same numa nodes
> as domains the processor's were pinned to i.e. if you pin the processors
> appropriately the Right Thing just happens. Do you believe this is not
> the case and/or not working right with xl?

It seems that xend is retrieving numa info about the platform, see
pyxc_numainfo, then using those info to pin vcpus to pcpus, see
_setCPUAffinity.
Still it seems to me more of an hack than the right way to solve the
problem.
--8323329-2017795904-1327056645=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-2017795904-1327056645=:3150--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:54:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoC76-0007UN-U7; Fri, 20 Jan 2012 10:54:32 +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 1RoC75-0007U6-0G
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:54:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327056864!11830660!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31583 invoked from network); 20 Jan 2012 10:54:24 -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 Jan 2012 10:54:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10173842"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 10:54:24 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 10:54:23 +0000
Date: Fri, 20 Jan 2012 10:55:07 +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: <1327046368.21391.29.camel@dagon.hellion.org.uk>
Message-ID: <alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2017795904-1327056645=:3150"
Content-ID: <alpine.DEB.2.00.1201201051220.3150@kaball-desktop>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-2017795904-1327056645=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1201201051221.3150@kaball-desktop>

On Fri, 20 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-19 at 21:14 +0000, Pasi Kärkkäinen wrote:
> > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > 
> > > Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > > must haves e.g. in the paging/sharing spaces?
> > > 
> > 
> > Something that I just remembered:
> > http://wiki.xen.org/xenwiki/Xen4.1
> > 
> > "NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate
> > equal amount of memory from every NUMA node for the VM. xm/xend
> > allocates all the memory from the same NUMA node."
> 
> I'm not that familiar with the NUMA support but my understanding was
> that memory was allocated by libxc/the-hypervisor and not by the
> toolstack and that the default was to allocate from the same numa nodes
> as domains the processor's were pinned to i.e. if you pin the processors
> appropriately the Right Thing just happens. Do you believe this is not
> the case and/or not working right with xl?

It seems that xend is retrieving numa info about the platform, see
pyxc_numainfo, then using those info to pin vcpus to pcpus, see
_setCPUAffinity.
Still it seems to me more of an hack than the right way to solve the
problem.
--8323329-2017795904-1327056645=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-2017795904-1327056645=:3150--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:55:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoC7W-0007Wn-BQ; Fri, 20 Jan 2012 10:54:58 +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 1RoC7V-0007WF-Mh
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:54:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327056891!11869379!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 28950 invoked from network); 20 Jan 2012 10:54:51 -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;
	20 Jan 2012 10:54:51 -0000
Received: by werb14 with SMTP id b14so1823990wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 02:54:50 -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=BZI3sF9Wc4rUCGLVy6W31OL/OLMPz56tnl76Bt8zDbw=;
	b=Qv8Iec4sAVsPQkaNH0+TY5MrQ9ALWtMq3d8n32+zrHnhEpHS1L6D4FtP8pDncpBuj+
	JA2S2ric3f2U4ySeSdqgA1SQ9kVUf1V6NDpxL8J88wPVVtdKv3zz7SJrtf9GVni3VJX7
	z3DTGkOSvgtOU0zmGd5nmZ/WNr1nmlhusQEo4=
Received: by 10.216.133.101 with SMTP id p79mr12701043wei.54.1327056890886;
	Fri, 20 Jan 2012 02:54:50 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id gy6sm32888619wib.11.2012.01.20.02.54.48
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:54:50 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 10:54:44 +0000
From: Keir Fraser <keir@xen.org>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Message-ID: <CB3EF874.37D58%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXYerrHvo3OV3zP0Oe9KU0+BTg2w==
In-Reply-To: <8568566.QXZZClQmLn@amur>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 10:49, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:

>> Our CPUID configuration is done per-domain, and from
>> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
>> hypervisor are generally not acceptable without very good reason.
> 
> Then a way is needed to have access to the opt_vpmu_enabled variable within
> the
> hypervisor from the tools to decide the enabling of the flag (is there such a
> way?) or the mechanism with the boot variable must be changed.
> The opt_vpmu_enabled boot variable was introduced because of a PMU problem in
> the Nehalem cpus leading sometimes to hypervisor crashes. But with the done
> quirk we never had a crash anymore.
> So maybe we can always switch on the vpmu stuff in the hypervisor and add a
> flag in the domain configuration when somebody wants to do some performance
> tests?

Yes!

It's obviously an option of fairly narrow interest. If someone tries to
enable the per-domain option on a CPU which has problems, you can fail the
domain creation, or print a warning in the hypervisor log, or whatever. Any
sensible option in that respect is fine by me!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 10:55:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 10:55:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoC7W-0007Wn-BQ; Fri, 20 Jan 2012 10:54:58 +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 1RoC7V-0007WF-Mh
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 10:54:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327056891!11869379!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 28950 invoked from network); 20 Jan 2012 10:54:51 -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;
	20 Jan 2012 10:54:51 -0000
Received: by werb14 with SMTP id b14so1823990wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 02:54:50 -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=BZI3sF9Wc4rUCGLVy6W31OL/OLMPz56tnl76Bt8zDbw=;
	b=Qv8Iec4sAVsPQkaNH0+TY5MrQ9ALWtMq3d8n32+zrHnhEpHS1L6D4FtP8pDncpBuj+
	JA2S2ric3f2U4ySeSdqgA1SQ9kVUf1V6NDpxL8J88wPVVtdKv3zz7SJrtf9GVni3VJX7
	z3DTGkOSvgtOU0zmGd5nmZ/WNr1nmlhusQEo4=
Received: by 10.216.133.101 with SMTP id p79mr12701043wei.54.1327056890886;
	Fri, 20 Jan 2012 02:54:50 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id gy6sm32888619wib.11.2012.01.20.02.54.48
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 02:54:50 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 10:54:44 +0000
From: Keir Fraser <keir@xen.org>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Message-ID: <CB3EF874.37D58%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXYerrHvo3OV3zP0Oe9KU0+BTg2w==
In-Reply-To: <8568566.QXZZClQmLn@amur>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 10:49, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:

>> Our CPUID configuration is done per-domain, and from
>> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
>> hypervisor are generally not acceptable without very good reason.
> 
> Then a way is needed to have access to the opt_vpmu_enabled variable within
> the
> hypervisor from the tools to decide the enabling of the flag (is there such a
> way?) or the mechanism with the boot variable must be changed.
> The opt_vpmu_enabled boot variable was introduced because of a PMU problem in
> the Nehalem cpus leading sometimes to hypervisor crashes. But with the done
> quirk we never had a crash anymore.
> So maybe we can always switch on the vpmu stuff in the hypervisor and add a
> flag in the domain configuration when somebody wants to do some performance
> tests?

Yes!

It's obviously an option of fairly narrow interest. If someone tries to
enable the per-domain option on a CPU which has problems, you can fail the
domain creation, or print a warning in the hypervisor log, or whatever. Any
sensible option in that respect is fine by me!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:03:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCFe-0007uL-Dw; Fri, 20 Jan 2012 11:03:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RoCFc-0007uG-Uh
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:03:21 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327057393!4272597!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13937 invoked from network); 20 Jan 2012 11:03:14 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:03:14 -0000
Received: by lago2 with SMTP id o2so599410lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 03:03:13 -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
	:content-transfer-encoding;
	bh=pRowv/MOIGPkPHE8izTJ19BBRlu+2FyB/nx1qZHu120=;
	b=Urkw8pTw1JD4KTC/eU6kq0+8WhCEPj/XDqvnEaqHagZ183cM6fG4vzMbk4cmbJO/HX
	FAZSZSjvIHMOPxORLZBt7qOlsOc1brGGmT24DPpxnQ0xjI9C0EIF3ueU97czBbYg38Sg
	uEKIG5ayahpGgx1VA2SqbnwRvEa/WPkQItLFk=
Received: by 10.152.131.202 with SMTP id oo10mr14397976lab.40.1327057392279;
	Fri, 20 Jan 2012 03:03:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Fri, 20 Jan 2012 03:02:56 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CACaajQuwjtFgHk3-2Tun3AiS+1hvi=LYSoQiynvgPRzE=sYEKw@mail.gmail.com>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
	<CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
	<20120119195046.GA3890@konrad-lan>
	<CACaajQuwjtFgHk3-2Tun3AiS+1hvi=LYSoQiynvgPRzE=sYEKw@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 20 Jan 2012 15:02:56 +0400
X-Google-Sender-Auth: Ui1kpydLkZWgzrHgBzio-U6bwn0
Message-ID: <CACaajQtqbqFDj2kHSp-2P1MqYWe_PLdcv_Q5UL7sxOWSCwModQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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

MjAxMi8xLzIwIFZhc2lsaXkgVG9sc3RvdiA8di50b2xzdG92QHNlbGZpcC5ydT46Cj4gMjAxMi8x
LzE5IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkQGRhcm5vay5vcmc+Ogo+Pj4gPgo+Pj4g
PiBXaGljaCBrZXJuZWwgdmVyc2lvbiBvZiBEb21VPwo+Pj4KPj4+IDIuNi4zMi4yNiBmcm9tIHhl
biBnaXQgdHJlZSBhbmQgwqAyLjYuMTgtMTk0LjI2LjEuZWw1eGVuCj4+Cj4+IEZpcnN0IG9yZGVy
IGlzIHRvIHVwZ3JhZGUgeW91ciBrZXJuZWwgYW5kIHNlZSBpZiB0aGUgcHJvYmxlbSBleGlzdHMK
Pj4gd2l0aCBhIG5ld2VyIDIuNi4zMi5YIHRyZWUuIHRoZW4gYWxzbyB0cnkgMy4wIG9yIDMuMSBr
ZXJuZWwuCj4+Pgo+Cj4KPiBUaGlzIGlzIHBvc3NpYmxlLCBidXQgbXkgcXVlc3Rpb24gaXMgLSB3
aHkgb24gc29tZSB2ZXJzaW9uIG9mIHRoZQo+IGtlcm5lbCBvbiBzYW1lIG5vZGUgc29tZSBkYW1p
bnMgY291ZCBub3QgcHJvcGVybHkgd2F0Y2ggeGVuc3RvcmU/Cj4KPj4+Cj4+PiA+Cj4+PiA+IFBs
YXkgYSBiaXQgd2l0aCB4ZW5jdHggdG8gZ2V0IGFuIGlkZWEgd2hlcmUgdGhlIGd1ZXN0IGlzIHN0
dWNrIGF0Lgo+Pj4gPgo+Pj4KPj4+IE9rLCBuaWNlLiBXaGVuIGkgbmVlZCB0byBydW4geGVuY3R4
IGFuZCB3aGF0IGkgbmVlZCB0byBzZWUgaW4gaXRzIG91dHB1dD8KPj4KPj4gPHNpZ2g+IEdvb2ds
ZSBmb3IgaXQuIFRoZXJlIHNob3VsZCBiZSB0b25zIG9mIGV4YW1wbGVzIG9mIGhvdyB0byB1c2Ug
aXQKPj4gdG8gZmlndXJlIG91dCB3aGVyZSB0aGUgZ3Vlc3QgaXMgc3R1Y2sgYXQuCj4KPiBPay4g
SSBjcmVhdGUgdHdvIGVxdWFsIGRvbVUgd2l0aCBtZW1vcnk9NTEyTSBhbmQgbWF4bWVtb3J5ID0g
NTEyTSwKPiBjb3B5IFN5c3RlbS5tYXAgdG8gZG9tMCBhbmQgY2hlY2sgeGVuY3R4IG91dHB1dC4g
RG9tYWlucyBydW5zIG9uIHNhbWUKPiBub2RlIGFuZCBvbmx5IGRpZmZlcnMgaW4gdXB0aW1lLgoK
ClNvbWUgbmV3IGRhdGEgaXMgYXJyaXZlZCAtIGluIGRvbVUgdGhhdCBjYW4ndCByZXNwb25kIHRv
IHdhdGNoZXMKeGVuc3RvcmUtcmVhZCBkYXRhIHByb2R1Y2UgcHJvY2VzcyBkZWFkbG9jayB3aXRo
IHNpbXBsZSB0cmFjZToKZG1lc2c6CklORk86IHRhc2sgeGVuc3RvcmUtcmVhZDoxOTU1NSBibG9j
a2VkIGZvciBtb3JlIHRoYW4gMTIwIHNlY29uZHMuCiJlY2hvIDAgPiAvcHJvYy9zeXMva2VybmVs
L2h1bmdfdGFza190aW1lb3V0X3NlY3MiIGRpc2FibGVzIHRoaXMgbWVzc2FnZS4KeGVuc3RvcmUt
cmVhZCBEIDAwMWQyZDI4OTFiYTMxZDAgwqAgwqAgMCAxOTU1NSDCoDE5NTI5IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIChOT1RMQikKwqBmZmZmODgwMDBlMzczZTI4IMKgMDAwMDAwMDAw
MDAwMDI4NiDCoGZmZmY4ODAwMGUzNzNlNjggwqBmZmZmZmZmZjgwMzFiNmU0CsKgMDAwMDAwMDAw
MDAwMDAwOCDCoGZmZmY4ODAwMGE2ZjU4MjAgwqBmZmZmZmZmZjgwNGY0YjAwIMKgMDAwMDAwMDAw
MDA5MDcxNQrCoGZmZmY4ODAwMGE2ZjVhMDggwqBmZmZmZmZmZjAwMDAwMDAwCkNhbGwgVHJhY2U6
CsKgWzxmZmZmZmZmZjgwMzFiNmU0Pl0gYXZjX2hhc19wZXJtKzB4NDYvMHg1OArCoFs8ZmZmZmZm
ZmY4MDMxYmZhND5dIGlub2RlX2hhc19wZXJtKzB4NTYvMHg2MwrCoFs8ZmZmZmZmZmY4MDI2M2E3
ZT5dIF9fbXV0ZXhfbG9ja19zbG93cGF0aCsweDYwLzB4OWIKwqBbPGZmZmZmZmZmODAzMWMwNDU+
XSBmaWxlX2hhc19wZXJtKzB4OTQvMHhhMwrCoFs8ZmZmZmZmZmY4MDI2M2FjOD5dIC50ZXh0Lmxv
Y2subXV0ZXgrMHhmLzB4MTQKwqBbPGZmZmZmZmZmODAzYjk0NmE+XSB4ZW5idXNfZGV2X3JlcXVl
c3RfYW5kX3JlcGx5KzB4MjYvMHg4MQrCoFs8ZmZmZmZmZmY4MDNiYjhlMz5dIHhlbmJ1c19kZXZf
d3JpdGUrMHhkMi8weDMwMQrCoFs8ZmZmZmZmZmY4MDIxNzM3Nz5dIHZmc193cml0ZSsweGNlLzB4
MTc0CsKgWzxmZmZmZmZmZjgwMjE3YmM0Pl0gc3lzX3dyaXRlKzB4NDUvMHg2ZQrCoFs8ZmZmZmZm
ZmY4MDI2MDJmOT5dIHRyYWNlc3lzKzB4YWIvMHhiNgoKCnN0cmFjZToKW3Jvb3RAMjEtNjgwIH5d
IyBzdHJhY2UgLWZmIC12IC1GIHhlbnN0b3JlLXJlYWQgY29udHJvbC9zaHV0ZG93bgpleGVjdmUo
Ii91c3IvYmluL3hlbnN0b3JlLXJlYWQiLCBbInhlbnN0b3JlLXJlYWQiLAoiY29udHJvbC9zaHV0
ZG93biJdLCBbIkhPU1ROQU1FPTIxLTY4MC5jbG9kby5ydSIsICJURVJNPXh0ZXJtIiwKIlNIRUxM
PS9iaW4vYmFzaCIsICJISVNUU0laRT0xMDAwIiwgIlNTSF9DTElFTlQ9ODUuMTQzLjE2MS4xOCA0
NDA1MwoyIiwgIlNTSF9UVFk9L2Rldi9wdHMvNCIsICJVU0VSPXJvb3QiLAoiTFNfQ09MT1JTPW5v
PTAwOmZpPTAwOmRpPTAwOzM0OmwiLCAiTUFJTD0vdmFyL3Nwb29sL21haWwvcm9vdCIsCiJQQVRI
PS91c3IvbG9jYWwvc2JpbjovdXNyL2xvY2FsLyIsICJJTlBVVFJDPS9ldGMvaW5wdXRyYyIsCiJQ
V0Q9L3Jvb3QiLCAiTEFORz1ydV9SVS51dGY4IiwgIlNITFZMPTEiLCAiSE9NRT0vcm9vdCIsCiJM
T0dOQU1FPXJvb3QiLCAiU1NIX0NPTk5FQ1RJT049ODUuMTQzLjE2MS4xOCA0NDAiLAoiTEVTU09Q
RU49fC91c3IvYmluL2xlc3NwaXBlLnNoICUiLCAiR19CUk9LRU5fRklMRU5BTUVTPTEiLAoiXz0v
dXNyL2Jpbi9zdHJhY2UiXSkgPSAwCmJyaygwKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA9IDB4ODQ2OTAwMAptbWFwKE5VTEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBN
QVBfUFJJVkFURXxNQVBfQU5PTllNT1VTLCAtMSwKMCkgPSAweDJiMjc1NWRkZDAwMAp1bmFtZSh7
c3lzbmFtZT0iTGludXgiLCBub2RlbmFtZT0iMjEtNjgwLmNsb2RvLnJ1IiwKcmVsZWFzZT0iMi42
LjE4LTE5NC4yNi4xLmVsNXhlbiIsIHZlcnNpb249IiMxIFNNUCBUdWUgTm92IDkgMTM6MzU6MzAK
RVNUIDIwMTAiLCBtYWNoaW5lPSJ4ODZfNjQifSkgPSAwCmFjY2VzcygiL2V0Yy9sZC5zby5wcmVs
b2FkIiwgUl9PSykgICAgICA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkK
b3BlbigiL2V0Yy9sZC5zby5jYWNoZSIsIE9fUkRPTkxZKSAgICAgID0gMwpmc3RhdCgzLCB7c3Rf
ZGV2PW1ha2VkZXYoMjAyLCAxKSwgc3RfaW5vPTMxNDU5NSwgc3RfbW9kZT1TX0lGUkVHfDA2NDQs
CnN0X25saW5rPTEsIHN0X3VpZD0wLCBzdF9naWQ9MCwgc3RfYmxrc2l6ZT00MDk2LCBzdF9ibG9j
a3M9NDAsCnN0X3NpemU9MjAzNDgsIHN0X2F0aW1lPTIwMTIvMDEvMjAtMTA6MTE6NTgsCnN0X210
aW1lPTIwMTIvMDEvMjAtMTA6MDM6MzAsIHN0X2N0aW1lPTIwMTIvMDEvMjAtMTA6MDM6MzB9KSA9
IDAKbW1hcChOVUxMLCAyMDM0OCwgUFJPVF9SRUFELCBNQVBfUFJJVkFURSwgMywgMCkgPSAweDJi
Mjc1NWRkZTAwMApjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwCm9w
ZW4oIi91c3IvbGliNjQvbGlieGVuc3RvcmUuc28uMy4wIiwgT19SRE9OTFkpID0gMwpyZWFkKDMs
ICJcMTc3RUxGXDJcMVwxXDBcMFwwXDBcMFwwXDBcMFwwXDNcMD5cMFwxXDBcMFwwClwzMVwwXDBc
MFwwXDBcMCIuLi4sIDgzMikgPSA4MzIKZnN0YXQoMywge3N0X2Rldj1tYWtlZGV2KDIwMiwgMSks
IHN0X2lubz0zMjI1NDIsIHN0X21vZGU9U19JRlJFR3wwNzU1LApzdF9ubGluaz0xLCBzdF91aWQ9
MCwgc3RfZ2lkPTAsIHN0X2Jsa3NpemU9NDA5Niwgc3RfYmxvY2tzPTQwLApzdF9zaXplPTE5NTQ0
LCBzdF9hdGltZT0yMDEyLzAxLzIwLTEwOjExOjU4LApzdF9tdGltZT0yMDExLzEwLzI0LTE3OjQ1
OjIzLCBzdF9jdGltZT0yMDEyLzAxLzExLTAwOjExOjE2fSkgPSAwCm1tYXAoTlVMTCwgNDA5Niwg
UFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklWQVRFfE1BUF9BTk9OWU1PVVMsIC0xLAowKSA9
IDB4MmIyNzU1ZGUzMDAwCm1tYXAoTlVMTCwgMjEyNzA0MCwgUFJPVF9SRUFEfFBST1RfRVhFQywg
TUFQX1BSSVZBVEV8TUFQX0RFTllXUklURSwgMywKMCkgPSAweDJiMjc1NWZkZjAwMAptcHJvdGVj
dCgweDJiMjc1NWZlMzAwMCwgMjA5NzE1MiwgUFJPVF9OT05FKSA9IDAKbW1hcCgweDJiMjc1NjFl
MzAwMCwgNDA5NiwgUFJPVF9SRUFEfFBST1RfV1JJVEUsCk1BUF9QUklWQVRFfE1BUF9GSVhFRHxN
QVBfREVOWVdSSVRFLCAzLCAweDQwMDApID0gMHgyYjI3NTYxZTMwMDAKbW1hcCgweDJiMjc1NjFl
NDAwMCwgOTQwOCwgUFJPVF9SRUFEfFBST1RfV1JJVEUsCk1BUF9QUklWQVRFfE1BUF9GSVhFRHxN
QVBfQU5PTllNT1VTLCAtMSwgMCkgPSAweDJiMjc1NjFlNDAwMApjbG9zZSgzKSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPSAwCm9wZW4oIi9saWI2NC9saWJjLnNvLjYiLCBPX1JET05M
WSkgICAgICA9IDMKcmVhZCgzLCAiXDE3N0VMRlwyXDFcMVwwXDBcMFwwXDBcMFwwXDBcMFwzXDA+
XDBcMVwwXDBcMFwyMjBcMzMyXDFcMFwwXDBcMFwwIi4uLiwKODMyKSA9IDgzMgpmc3RhdCgzLCB7
c3RfZGV2PW1ha2VkZXYoMjAyLCAxKSwgc3RfaW5vPTEwNjc4OCwgc3RfbW9kZT1TX0lGUkVHfDA3
NTUsCnN0X25saW5rPTEsIHN0X3VpZD0wLCBzdF9naWQ9MCwgc3RfYmxrc2l6ZT00MDk2LCBzdF9i
bG9ja3M9MzM2OCwKc3Rfc2l6ZT0xNzE2NzIwLCBzdF9hdGltZT0yMDEyLzAxLzIwLTEwOjExOjU4
LApzdF9tdGltZT0yMDExLzExLzI4LTE1OjQzOjQ4LCBzdF9jdGltZT0yMDEyLzAxLzExLTAwOjEw
OjM2fSkgPSAwCm1tYXAoTlVMTCwgMzUwMjQyNCwgUFJPVF9SRUFEfFBST1RfRVhFQywgTUFQX1BS
SVZBVEV8TUFQX0RFTllXUklURSwgMywKMCkgPSAweDJiMjc1NjFlNzAwMAptcHJvdGVjdCgweDJi
Mjc1NjMzNTAwMCwgMjA5NzE1MiwgUFJPVF9OT05FKSA9IDAKbW1hcCgweDJiMjc1NjUzNTAwMCwg
MjA0ODAsIFBST1RfUkVBRHxQUk9UX1dSSVRFLApNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX0RF
TllXUklURSwgMywgMHgxNGUwMDApID0gMHgyYjI3NTY1MzUwMDAKbW1hcCgweDJiMjc1NjUzYTAw
MCwgMTY3MjgsIFBST1RfUkVBRHxQUk9UX1dSSVRFLApNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQ
X0FOT05ZTU9VUywgLTEsIDApID0gMHgyYjI3NTY1M2EwMDAKY2xvc2UoMykgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgID0gMApvcGVuKCIvbGliNjQvbGlicHRocmVhZC5zby4wIiwgT19S
RE9OTFkpID0gMwpyZWFkKDMsICJcMTc3RUxGXDJcMVwxXDBcMFwwXDBcMFwwXDBcMFwwXDNcMD5c
MFwxXDBcMFwwXDI0MFdcMFwwXDBcMFwwXDAiLi4uLAo4MzIpID0gODMyCmZzdGF0KDMsIHtzdF9k
ZXY9bWFrZWRldigyMDIsIDEpLCBzdF9pbm89MTA2ODAxLCBzdF9tb2RlPVNfSUZSRUd8MDc1NSwK
c3Rfbmxpbms9MSwgc3RfdWlkPTAsIHN0X2dpZD0wLCBzdF9ibGtzaXplPTQwOTYsIHN0X2Jsb2Nr
cz0yODgsCnN0X3NpemU9MTQyNjk2LCBzdF9hdGltZT0yMDEyLzAxLzIwLTEwOjExOjU4LApzdF9t
dGltZT0yMDExLzExLzI4LTE1OjQzOjQ5LCBzdF9jdGltZT0yMDEyLzAxLzExLTAwOjEwOjM2fSkg
PSAwCm1tYXAoTlVMTCwgMjIwNDUyOCwgUFJPVF9SRUFEfFBST1RfRVhFQywgTUFQX1BSSVZBVEV8
TUFQX0RFTllXUklURSwgMywKMCkgPSAweDJiMjc1NjUzZjAwMAptcHJvdGVjdCgweDJiMjc1NjU1
NTAwMCwgMjA5MzA1NiwgUFJPVF9OT05FKSA9IDAKbW1hcCgweDJiMjc1Njc1NDAwMCwgODE5Miwg
UFJPVF9SRUFEfFBST1RfV1JJVEUsCk1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfREVOWVdSSVRF
LCAzLCAweDE1MDAwKSA9IDB4MmIyNzU2NzU0MDAwCm1tYXAoMHgyYjI3NTY3NTYwMDAsIDEzMTY4
LCBQUk9UX1JFQUR8UFJPVF9XUklURSwKTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9BTk9OWU1P
VVMsIC0xLCAwKSA9IDB4MmIyNzU2NzU2MDAwCmNsb3NlKDMpICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA9IDAKb3BlbigiL2xpYjY0L2xpYmdjY19zLnNvLjEiLCBPX1JET05MWSkgID0g
MwpyZWFkKDMsICJcMTc3RUxGXDJcMVwxXDBcMFwwXDBcMFwwXDBcMFwwXDNcMD5cMFwxXDBcMFww
UFwzNlwwXDBcMFwwXDBcMCIuLi4sCjgzMikgPSA4MzIKZnN0YXQoMywge3N0X2Rldj1tYWtlZGV2
KDIwMiwgMSksIHN0X2lubz0xMDY5ODMsIHN0X21vZGU9U19JRlJFR3wwNzU1LApzdF9ubGluaz0x
LCBzdF91aWQ9MCwgc3RfZ2lkPTAsIHN0X2Jsa3NpemU9NDA5Niwgc3RfYmxvY2tzPTEyMCwKc3Rf
c2l6ZT01NjA3Miwgc3RfYXRpbWU9MjAxMi8wMS8yMC0xMDoxMTo1OCwKc3RfbXRpbWU9MjAxMS8w
Ny8yMi0wOTowNjo0NCwgc3RfY3RpbWU9MjAxMi8wMS8xMC0yMzo1Njo0Nn0pID0gMAptbWFwKE5V
TEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfQU5PTllNT1VT
LCAtMSwKMCkgPSAweDJiMjc1Njc1YTAwMAptbWFwKE5VTEwsIDIxNTE3ODQsIFBST1RfUkVBRHxQ
Uk9UX0VYRUMsIE1BUF9QUklWQVRFfE1BUF9ERU5ZV1JJVEUsIDMsCjApID0gMHgyYjI3NTY3NWIw
MDAKbXByb3RlY3QoMHgyYjI3NTY3NjgwMDAsIDIwOTcxNTIsIFBST1RfTk9ORSkgPSAwCm1tYXAo
MHgyYjI3NTY5NjgwMDAsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLApNQVBfUFJJVkFURXxN
QVBfRklYRUR8TUFQX0RFTllXUklURSwgMywgMHhkMDAwKSA9IDB4MmIyNzU2OTY4MDAwCmNsb3Nl
KDMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAKbW1hcChOVUxMLCA0MDk2LCBQ
Uk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywgLTEsCjApID0g
MHgyYjI3NTY5NjkwMDAKYXJjaF9wcmN0bChBUkNIX1NFVF9GUywgMHgyYjI3NTY5Njk2ZTApID0g
MAptcHJvdGVjdCgweDJiMjc1Njc1NDAwMCwgNDA5NiwgUFJPVF9SRUFEKSA9IDAKbXByb3RlY3Qo
MHgyYjI3NTY1MzUwMDAsIDE2Mzg0LCBQUk9UX1JFQUQpID0gMAptcHJvdGVjdCgweDJiMjc1NWZk
ZDAwMCwgNDA5NiwgUFJPVF9SRUFEKSA9IDAKbXVubWFwKDB4MmIyNzU1ZGRlMDAwLCAyMDM0OCkg
ICAgICAgICAgID0gMApzZXRfdGlkX2FkZHJlc3MoMHgyYjI3NTY5Njk3NzApICAgICAgICAgPSAx
OTYwMwpzZXRfcm9idXN0X2xpc3QoMHgyYjI3NTY5Njk3ODAsIDB4MTgpICAgPSAwCmZ1dGV4KDB4
N2ZmZjgwYjgzOGRjLCBGVVRFWF9XQUtFX1BSSVZBVEUsIDEpID0gMApydF9zaWdhY3Rpb24oU0lH
UlRNSU4sIHsweDJiMjc1NjU0NDM4MCwgW10sIFNBX1JFU1RPUkVSfFNBX1NJR0lORk8sCjB4MmIy
NzU2NTRkYjcwfSwgTlVMTCwgOCkgPSAwCnJ0X3NpZ2FjdGlvbihTSUdSVF8xLCB7MHgyYjI3NTY1
NDQyYjAsIFtdLApTQV9SRVNUT1JFUnxTQV9SRVNUQVJUfFNBX1NJR0lORk8sIDB4MmIyNzU2NTRk
YjcwfSwgTlVMTCwgOCkgPSAwCnJ0X3NpZ3Byb2NtYXNrKFNJR19VTkJMT0NLLCBbUlRNSU4gUlRf
MV0sIE5VTEwsIDgpID0gMApnZXRybGltaXQoUkxJTUlUX1NUQUNLLCB7cmxpbV9jdXI9MTAyNDAq
MTAyNCwgcmxpbV9tYXg9UkxJTV9JTkZJTklUWX0pID0gMApzdGF0KCIvcHJvYy94ZW4veGVuYnVz
Iiwge3N0X2Rldj1tYWtlZGV2KDAsIDMpLCBzdF9pbm89NDAyNjUzNDY2NywKc3RfbW9kZT1TX0lG
UkVHfDA0MDAsIHN0X25saW5rPTEsIHN0X3VpZD0wLCBzdF9naWQ9MCwgc3RfYmxrc2l6ZT00MDk2
LApzdF9ibG9ja3M9MCwgc3Rfc2l6ZT0wLCBzdF9hdGltZT0yMDEyLzAxLzIwLTEwOjA0OjAzLApz
dF9tdGltZT0yMDEyLzAxLzIwLTEwOjA0OjAzLCBzdF9jdGltZT0yMDEyLzAxLzIwLTEwOjA0OjAz
fSkgPSAwCm9wZW4oIi9wcm9jL3hlbi94ZW5idXMiLCBPX1JEV1IpICAgICAgICA9IDMKYnJrKDAp
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMHg4NDY5MDAwCmJyaygweDg0OGEw
MDApICAgICAgICAgICAgICAgICAgICAgICAgICA9IDB4ODQ4YTAwMApydF9zaWdhY3Rpb24oU0lH
UElQRSwgezB4MSwgW10sIFNBX1JFU1RPUkVSLCAweDJiMjc1NjIxNzJkMH0sCntTSUdfREZMLCBb
XSwgMH0sIDgpID0gMAp3cml0ZSgzLCAiXDJcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDIxXDBcMFww
IiwgMTYpID0gMTYKd3JpdGUoMywgImNvbnRyb2wvc2h1dGRvd25cMCIsIDE3CgoKCgoKLS0gClZh
c2lsaXkgVG9sc3RvdiwKQ2xvZG8ucnUKZS1tYWlsOiB2LnRvbHN0b3ZAc2VsZmlwLnJ1CmphYmJl
cjogdmFzZUBzZWxmaXAucnUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:03:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:03:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCFe-0007uL-Dw; Fri, 20 Jan 2012 11:03:22 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RoCFc-0007uG-Uh
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:03:21 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327057393!4272597!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13937 invoked from network); 20 Jan 2012 11:03:14 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-8.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:03:14 -0000
Received: by lago2 with SMTP id o2so599410lag.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 03:03:13 -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
	:content-transfer-encoding;
	bh=pRowv/MOIGPkPHE8izTJ19BBRlu+2FyB/nx1qZHu120=;
	b=Urkw8pTw1JD4KTC/eU6kq0+8WhCEPj/XDqvnEaqHagZ183cM6fG4vzMbk4cmbJO/HX
	FAZSZSjvIHMOPxORLZBt7qOlsOc1brGGmT24DPpxnQ0xjI9C0EIF3ueU97czBbYg38Sg
	uEKIG5ayahpGgx1VA2SqbnwRvEa/WPkQItLFk=
Received: by 10.152.131.202 with SMTP id oo10mr14397976lab.40.1327057392279;
	Fri, 20 Jan 2012 03:03:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Fri, 20 Jan 2012 03:02:56 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CACaajQuwjtFgHk3-2Tun3AiS+1hvi=LYSoQiynvgPRzE=sYEKw@mail.gmail.com>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
	<CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
	<20120119195046.GA3890@konrad-lan>
	<CACaajQuwjtFgHk3-2Tun3AiS+1hvi=LYSoQiynvgPRzE=sYEKw@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Fri, 20 Jan 2012 15:02:56 +0400
X-Google-Sender-Auth: Ui1kpydLkZWgzrHgBzio-U6bwn0
Message-ID: <CACaajQtqbqFDj2kHSp-2P1MqYWe_PLdcv_Q5UL7sxOWSCwModQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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

MjAxMi8xLzIwIFZhc2lsaXkgVG9sc3RvdiA8di50b2xzdG92QHNlbGZpcC5ydT46Cj4gMjAxMi8x
LzE5IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkQGRhcm5vay5vcmc+Ogo+Pj4gPgo+Pj4g
PiBXaGljaCBrZXJuZWwgdmVyc2lvbiBvZiBEb21VPwo+Pj4KPj4+IDIuNi4zMi4yNiBmcm9tIHhl
biBnaXQgdHJlZSBhbmQgwqAyLjYuMTgtMTk0LjI2LjEuZWw1eGVuCj4+Cj4+IEZpcnN0IG9yZGVy
IGlzIHRvIHVwZ3JhZGUgeW91ciBrZXJuZWwgYW5kIHNlZSBpZiB0aGUgcHJvYmxlbSBleGlzdHMK
Pj4gd2l0aCBhIG5ld2VyIDIuNi4zMi5YIHRyZWUuIHRoZW4gYWxzbyB0cnkgMy4wIG9yIDMuMSBr
ZXJuZWwuCj4+Pgo+Cj4KPiBUaGlzIGlzIHBvc3NpYmxlLCBidXQgbXkgcXVlc3Rpb24gaXMgLSB3
aHkgb24gc29tZSB2ZXJzaW9uIG9mIHRoZQo+IGtlcm5lbCBvbiBzYW1lIG5vZGUgc29tZSBkYW1p
bnMgY291ZCBub3QgcHJvcGVybHkgd2F0Y2ggeGVuc3RvcmU/Cj4KPj4+Cj4+PiA+Cj4+PiA+IFBs
YXkgYSBiaXQgd2l0aCB4ZW5jdHggdG8gZ2V0IGFuIGlkZWEgd2hlcmUgdGhlIGd1ZXN0IGlzIHN0
dWNrIGF0Lgo+Pj4gPgo+Pj4KPj4+IE9rLCBuaWNlLiBXaGVuIGkgbmVlZCB0byBydW4geGVuY3R4
IGFuZCB3aGF0IGkgbmVlZCB0byBzZWUgaW4gaXRzIG91dHB1dD8KPj4KPj4gPHNpZ2g+IEdvb2ds
ZSBmb3IgaXQuIFRoZXJlIHNob3VsZCBiZSB0b25zIG9mIGV4YW1wbGVzIG9mIGhvdyB0byB1c2Ug
aXQKPj4gdG8gZmlndXJlIG91dCB3aGVyZSB0aGUgZ3Vlc3QgaXMgc3R1Y2sgYXQuCj4KPiBPay4g
SSBjcmVhdGUgdHdvIGVxdWFsIGRvbVUgd2l0aCBtZW1vcnk9NTEyTSBhbmQgbWF4bWVtb3J5ID0g
NTEyTSwKPiBjb3B5IFN5c3RlbS5tYXAgdG8gZG9tMCBhbmQgY2hlY2sgeGVuY3R4IG91dHB1dC4g
RG9tYWlucyBydW5zIG9uIHNhbWUKPiBub2RlIGFuZCBvbmx5IGRpZmZlcnMgaW4gdXB0aW1lLgoK
ClNvbWUgbmV3IGRhdGEgaXMgYXJyaXZlZCAtIGluIGRvbVUgdGhhdCBjYW4ndCByZXNwb25kIHRv
IHdhdGNoZXMKeGVuc3RvcmUtcmVhZCBkYXRhIHByb2R1Y2UgcHJvY2VzcyBkZWFkbG9jayB3aXRo
IHNpbXBsZSB0cmFjZToKZG1lc2c6CklORk86IHRhc2sgeGVuc3RvcmUtcmVhZDoxOTU1NSBibG9j
a2VkIGZvciBtb3JlIHRoYW4gMTIwIHNlY29uZHMuCiJlY2hvIDAgPiAvcHJvYy9zeXMva2VybmVs
L2h1bmdfdGFza190aW1lb3V0X3NlY3MiIGRpc2FibGVzIHRoaXMgbWVzc2FnZS4KeGVuc3RvcmUt
cmVhZCBEIDAwMWQyZDI4OTFiYTMxZDAgwqAgwqAgMCAxOTU1NSDCoDE5NTI5IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIChOT1RMQikKwqBmZmZmODgwMDBlMzczZTI4IMKgMDAwMDAwMDAw
MDAwMDI4NiDCoGZmZmY4ODAwMGUzNzNlNjggwqBmZmZmZmZmZjgwMzFiNmU0CsKgMDAwMDAwMDAw
MDAwMDAwOCDCoGZmZmY4ODAwMGE2ZjU4MjAgwqBmZmZmZmZmZjgwNGY0YjAwIMKgMDAwMDAwMDAw
MDA5MDcxNQrCoGZmZmY4ODAwMGE2ZjVhMDggwqBmZmZmZmZmZjAwMDAwMDAwCkNhbGwgVHJhY2U6
CsKgWzxmZmZmZmZmZjgwMzFiNmU0Pl0gYXZjX2hhc19wZXJtKzB4NDYvMHg1OArCoFs8ZmZmZmZm
ZmY4MDMxYmZhND5dIGlub2RlX2hhc19wZXJtKzB4NTYvMHg2MwrCoFs8ZmZmZmZmZmY4MDI2M2E3
ZT5dIF9fbXV0ZXhfbG9ja19zbG93cGF0aCsweDYwLzB4OWIKwqBbPGZmZmZmZmZmODAzMWMwNDU+
XSBmaWxlX2hhc19wZXJtKzB4OTQvMHhhMwrCoFs8ZmZmZmZmZmY4MDI2M2FjOD5dIC50ZXh0Lmxv
Y2subXV0ZXgrMHhmLzB4MTQKwqBbPGZmZmZmZmZmODAzYjk0NmE+XSB4ZW5idXNfZGV2X3JlcXVl
c3RfYW5kX3JlcGx5KzB4MjYvMHg4MQrCoFs8ZmZmZmZmZmY4MDNiYjhlMz5dIHhlbmJ1c19kZXZf
d3JpdGUrMHhkMi8weDMwMQrCoFs8ZmZmZmZmZmY4MDIxNzM3Nz5dIHZmc193cml0ZSsweGNlLzB4
MTc0CsKgWzxmZmZmZmZmZjgwMjE3YmM0Pl0gc3lzX3dyaXRlKzB4NDUvMHg2ZQrCoFs8ZmZmZmZm
ZmY4MDI2MDJmOT5dIHRyYWNlc3lzKzB4YWIvMHhiNgoKCnN0cmFjZToKW3Jvb3RAMjEtNjgwIH5d
IyBzdHJhY2UgLWZmIC12IC1GIHhlbnN0b3JlLXJlYWQgY29udHJvbC9zaHV0ZG93bgpleGVjdmUo
Ii91c3IvYmluL3hlbnN0b3JlLXJlYWQiLCBbInhlbnN0b3JlLXJlYWQiLAoiY29udHJvbC9zaHV0
ZG93biJdLCBbIkhPU1ROQU1FPTIxLTY4MC5jbG9kby5ydSIsICJURVJNPXh0ZXJtIiwKIlNIRUxM
PS9iaW4vYmFzaCIsICJISVNUU0laRT0xMDAwIiwgIlNTSF9DTElFTlQ9ODUuMTQzLjE2MS4xOCA0
NDA1MwoyIiwgIlNTSF9UVFk9L2Rldi9wdHMvNCIsICJVU0VSPXJvb3QiLAoiTFNfQ09MT1JTPW5v
PTAwOmZpPTAwOmRpPTAwOzM0OmwiLCAiTUFJTD0vdmFyL3Nwb29sL21haWwvcm9vdCIsCiJQQVRI
PS91c3IvbG9jYWwvc2JpbjovdXNyL2xvY2FsLyIsICJJTlBVVFJDPS9ldGMvaW5wdXRyYyIsCiJQ
V0Q9L3Jvb3QiLCAiTEFORz1ydV9SVS51dGY4IiwgIlNITFZMPTEiLCAiSE9NRT0vcm9vdCIsCiJM
T0dOQU1FPXJvb3QiLCAiU1NIX0NPTk5FQ1RJT049ODUuMTQzLjE2MS4xOCA0NDAiLAoiTEVTU09Q
RU49fC91c3IvYmluL2xlc3NwaXBlLnNoICUiLCAiR19CUk9LRU5fRklMRU5BTUVTPTEiLAoiXz0v
dXNyL2Jpbi9zdHJhY2UiXSkgPSAwCmJyaygwKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICA9IDB4ODQ2OTAwMAptbWFwKE5VTEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBN
QVBfUFJJVkFURXxNQVBfQU5PTllNT1VTLCAtMSwKMCkgPSAweDJiMjc1NWRkZDAwMAp1bmFtZSh7
c3lzbmFtZT0iTGludXgiLCBub2RlbmFtZT0iMjEtNjgwLmNsb2RvLnJ1IiwKcmVsZWFzZT0iMi42
LjE4LTE5NC4yNi4xLmVsNXhlbiIsIHZlcnNpb249IiMxIFNNUCBUdWUgTm92IDkgMTM6MzU6MzAK
RVNUIDIwMTAiLCBtYWNoaW5lPSJ4ODZfNjQifSkgPSAwCmFjY2VzcygiL2V0Yy9sZC5zby5wcmVs
b2FkIiwgUl9PSykgICAgICA9IC0xIEVOT0VOVCAoTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeSkK
b3BlbigiL2V0Yy9sZC5zby5jYWNoZSIsIE9fUkRPTkxZKSAgICAgID0gMwpmc3RhdCgzLCB7c3Rf
ZGV2PW1ha2VkZXYoMjAyLCAxKSwgc3RfaW5vPTMxNDU5NSwgc3RfbW9kZT1TX0lGUkVHfDA2NDQs
CnN0X25saW5rPTEsIHN0X3VpZD0wLCBzdF9naWQ9MCwgc3RfYmxrc2l6ZT00MDk2LCBzdF9ibG9j
a3M9NDAsCnN0X3NpemU9MjAzNDgsIHN0X2F0aW1lPTIwMTIvMDEvMjAtMTA6MTE6NTgsCnN0X210
aW1lPTIwMTIvMDEvMjAtMTA6MDM6MzAsIHN0X2N0aW1lPTIwMTIvMDEvMjAtMTA6MDM6MzB9KSA9
IDAKbW1hcChOVUxMLCAyMDM0OCwgUFJPVF9SRUFELCBNQVBfUFJJVkFURSwgMywgMCkgPSAweDJi
Mjc1NWRkZTAwMApjbG9zZSgzKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSAwCm9w
ZW4oIi91c3IvbGliNjQvbGlieGVuc3RvcmUuc28uMy4wIiwgT19SRE9OTFkpID0gMwpyZWFkKDMs
ICJcMTc3RUxGXDJcMVwxXDBcMFwwXDBcMFwwXDBcMFwwXDNcMD5cMFwxXDBcMFwwClwzMVwwXDBc
MFwwXDBcMCIuLi4sIDgzMikgPSA4MzIKZnN0YXQoMywge3N0X2Rldj1tYWtlZGV2KDIwMiwgMSks
IHN0X2lubz0zMjI1NDIsIHN0X21vZGU9U19JRlJFR3wwNzU1LApzdF9ubGluaz0xLCBzdF91aWQ9
MCwgc3RfZ2lkPTAsIHN0X2Jsa3NpemU9NDA5Niwgc3RfYmxvY2tzPTQwLApzdF9zaXplPTE5NTQ0
LCBzdF9hdGltZT0yMDEyLzAxLzIwLTEwOjExOjU4LApzdF9tdGltZT0yMDExLzEwLzI0LTE3OjQ1
OjIzLCBzdF9jdGltZT0yMDEyLzAxLzExLTAwOjExOjE2fSkgPSAwCm1tYXAoTlVMTCwgNDA5Niwg
UFJPVF9SRUFEfFBST1RfV1JJVEUsIE1BUF9QUklWQVRFfE1BUF9BTk9OWU1PVVMsIC0xLAowKSA9
IDB4MmIyNzU1ZGUzMDAwCm1tYXAoTlVMTCwgMjEyNzA0MCwgUFJPVF9SRUFEfFBST1RfRVhFQywg
TUFQX1BSSVZBVEV8TUFQX0RFTllXUklURSwgMywKMCkgPSAweDJiMjc1NWZkZjAwMAptcHJvdGVj
dCgweDJiMjc1NWZlMzAwMCwgMjA5NzE1MiwgUFJPVF9OT05FKSA9IDAKbW1hcCgweDJiMjc1NjFl
MzAwMCwgNDA5NiwgUFJPVF9SRUFEfFBST1RfV1JJVEUsCk1BUF9QUklWQVRFfE1BUF9GSVhFRHxN
QVBfREVOWVdSSVRFLCAzLCAweDQwMDApID0gMHgyYjI3NTYxZTMwMDAKbW1hcCgweDJiMjc1NjFl
NDAwMCwgOTQwOCwgUFJPVF9SRUFEfFBST1RfV1JJVEUsCk1BUF9QUklWQVRFfE1BUF9GSVhFRHxN
QVBfQU5PTllNT1VTLCAtMSwgMCkgPSAweDJiMjc1NjFlNDAwMApjbG9zZSgzKSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgPSAwCm9wZW4oIi9saWI2NC9saWJjLnNvLjYiLCBPX1JET05M
WSkgICAgICA9IDMKcmVhZCgzLCAiXDE3N0VMRlwyXDFcMVwwXDBcMFwwXDBcMFwwXDBcMFwzXDA+
XDBcMVwwXDBcMFwyMjBcMzMyXDFcMFwwXDBcMFwwIi4uLiwKODMyKSA9IDgzMgpmc3RhdCgzLCB7
c3RfZGV2PW1ha2VkZXYoMjAyLCAxKSwgc3RfaW5vPTEwNjc4OCwgc3RfbW9kZT1TX0lGUkVHfDA3
NTUsCnN0X25saW5rPTEsIHN0X3VpZD0wLCBzdF9naWQ9MCwgc3RfYmxrc2l6ZT00MDk2LCBzdF9i
bG9ja3M9MzM2OCwKc3Rfc2l6ZT0xNzE2NzIwLCBzdF9hdGltZT0yMDEyLzAxLzIwLTEwOjExOjU4
LApzdF9tdGltZT0yMDExLzExLzI4LTE1OjQzOjQ4LCBzdF9jdGltZT0yMDEyLzAxLzExLTAwOjEw
OjM2fSkgPSAwCm1tYXAoTlVMTCwgMzUwMjQyNCwgUFJPVF9SRUFEfFBST1RfRVhFQywgTUFQX1BS
SVZBVEV8TUFQX0RFTllXUklURSwgMywKMCkgPSAweDJiMjc1NjFlNzAwMAptcHJvdGVjdCgweDJi
Mjc1NjMzNTAwMCwgMjA5NzE1MiwgUFJPVF9OT05FKSA9IDAKbW1hcCgweDJiMjc1NjUzNTAwMCwg
MjA0ODAsIFBST1RfUkVBRHxQUk9UX1dSSVRFLApNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQX0RF
TllXUklURSwgMywgMHgxNGUwMDApID0gMHgyYjI3NTY1MzUwMDAKbW1hcCgweDJiMjc1NjUzYTAw
MCwgMTY3MjgsIFBST1RfUkVBRHxQUk9UX1dSSVRFLApNQVBfUFJJVkFURXxNQVBfRklYRUR8TUFQ
X0FOT05ZTU9VUywgLTEsIDApID0gMHgyYjI3NTY1M2EwMDAKY2xvc2UoMykgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgID0gMApvcGVuKCIvbGliNjQvbGlicHRocmVhZC5zby4wIiwgT19S
RE9OTFkpID0gMwpyZWFkKDMsICJcMTc3RUxGXDJcMVwxXDBcMFwwXDBcMFwwXDBcMFwwXDNcMD5c
MFwxXDBcMFwwXDI0MFdcMFwwXDBcMFwwXDAiLi4uLAo4MzIpID0gODMyCmZzdGF0KDMsIHtzdF9k
ZXY9bWFrZWRldigyMDIsIDEpLCBzdF9pbm89MTA2ODAxLCBzdF9tb2RlPVNfSUZSRUd8MDc1NSwK
c3Rfbmxpbms9MSwgc3RfdWlkPTAsIHN0X2dpZD0wLCBzdF9ibGtzaXplPTQwOTYsIHN0X2Jsb2Nr
cz0yODgsCnN0X3NpemU9MTQyNjk2LCBzdF9hdGltZT0yMDEyLzAxLzIwLTEwOjExOjU4LApzdF9t
dGltZT0yMDExLzExLzI4LTE1OjQzOjQ5LCBzdF9jdGltZT0yMDEyLzAxLzExLTAwOjEwOjM2fSkg
PSAwCm1tYXAoTlVMTCwgMjIwNDUyOCwgUFJPVF9SRUFEfFBST1RfRVhFQywgTUFQX1BSSVZBVEV8
TUFQX0RFTllXUklURSwgMywKMCkgPSAweDJiMjc1NjUzZjAwMAptcHJvdGVjdCgweDJiMjc1NjU1
NTAwMCwgMjA5MzA1NiwgUFJPVF9OT05FKSA9IDAKbW1hcCgweDJiMjc1Njc1NDAwMCwgODE5Miwg
UFJPVF9SRUFEfFBST1RfV1JJVEUsCk1BUF9QUklWQVRFfE1BUF9GSVhFRHxNQVBfREVOWVdSSVRF
LCAzLCAweDE1MDAwKSA9IDB4MmIyNzU2NzU0MDAwCm1tYXAoMHgyYjI3NTY3NTYwMDAsIDEzMTY4
LCBQUk9UX1JFQUR8UFJPVF9XUklURSwKTUFQX1BSSVZBVEV8TUFQX0ZJWEVEfE1BUF9BTk9OWU1P
VVMsIC0xLCAwKSA9IDB4MmIyNzU2NzU2MDAwCmNsb3NlKDMpICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICA9IDAKb3BlbigiL2xpYjY0L2xpYmdjY19zLnNvLjEiLCBPX1JET05MWSkgID0g
MwpyZWFkKDMsICJcMTc3RUxGXDJcMVwxXDBcMFwwXDBcMFwwXDBcMFwwXDNcMD5cMFwxXDBcMFww
UFwzNlwwXDBcMFwwXDBcMCIuLi4sCjgzMikgPSA4MzIKZnN0YXQoMywge3N0X2Rldj1tYWtlZGV2
KDIwMiwgMSksIHN0X2lubz0xMDY5ODMsIHN0X21vZGU9U19JRlJFR3wwNzU1LApzdF9ubGluaz0x
LCBzdF91aWQ9MCwgc3RfZ2lkPTAsIHN0X2Jsa3NpemU9NDA5Niwgc3RfYmxvY2tzPTEyMCwKc3Rf
c2l6ZT01NjA3Miwgc3RfYXRpbWU9MjAxMi8wMS8yMC0xMDoxMTo1OCwKc3RfbXRpbWU9MjAxMS8w
Ny8yMi0wOTowNjo0NCwgc3RfY3RpbWU9MjAxMi8wMS8xMC0yMzo1Njo0Nn0pID0gMAptbWFwKE5V
TEwsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLCBNQVBfUFJJVkFURXxNQVBfQU5PTllNT1VT
LCAtMSwKMCkgPSAweDJiMjc1Njc1YTAwMAptbWFwKE5VTEwsIDIxNTE3ODQsIFBST1RfUkVBRHxQ
Uk9UX0VYRUMsIE1BUF9QUklWQVRFfE1BUF9ERU5ZV1JJVEUsIDMsCjApID0gMHgyYjI3NTY3NWIw
MDAKbXByb3RlY3QoMHgyYjI3NTY3NjgwMDAsIDIwOTcxNTIsIFBST1RfTk9ORSkgPSAwCm1tYXAo
MHgyYjI3NTY5NjgwMDAsIDQwOTYsIFBST1RfUkVBRHxQUk9UX1dSSVRFLApNQVBfUFJJVkFURXxN
QVBfRklYRUR8TUFQX0RFTllXUklURSwgMywgMHhkMDAwKSA9IDB4MmIyNzU2OTY4MDAwCmNsb3Nl
KDMpICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IDAKbW1hcChOVUxMLCA0MDk2LCBQ
Uk9UX1JFQUR8UFJPVF9XUklURSwgTUFQX1BSSVZBVEV8TUFQX0FOT05ZTU9VUywgLTEsCjApID0g
MHgyYjI3NTY5NjkwMDAKYXJjaF9wcmN0bChBUkNIX1NFVF9GUywgMHgyYjI3NTY5Njk2ZTApID0g
MAptcHJvdGVjdCgweDJiMjc1Njc1NDAwMCwgNDA5NiwgUFJPVF9SRUFEKSA9IDAKbXByb3RlY3Qo
MHgyYjI3NTY1MzUwMDAsIDE2Mzg0LCBQUk9UX1JFQUQpID0gMAptcHJvdGVjdCgweDJiMjc1NWZk
ZDAwMCwgNDA5NiwgUFJPVF9SRUFEKSA9IDAKbXVubWFwKDB4MmIyNzU1ZGRlMDAwLCAyMDM0OCkg
ICAgICAgICAgID0gMApzZXRfdGlkX2FkZHJlc3MoMHgyYjI3NTY5Njk3NzApICAgICAgICAgPSAx
OTYwMwpzZXRfcm9idXN0X2xpc3QoMHgyYjI3NTY5Njk3ODAsIDB4MTgpICAgPSAwCmZ1dGV4KDB4
N2ZmZjgwYjgzOGRjLCBGVVRFWF9XQUtFX1BSSVZBVEUsIDEpID0gMApydF9zaWdhY3Rpb24oU0lH
UlRNSU4sIHsweDJiMjc1NjU0NDM4MCwgW10sIFNBX1JFU1RPUkVSfFNBX1NJR0lORk8sCjB4MmIy
NzU2NTRkYjcwfSwgTlVMTCwgOCkgPSAwCnJ0X3NpZ2FjdGlvbihTSUdSVF8xLCB7MHgyYjI3NTY1
NDQyYjAsIFtdLApTQV9SRVNUT1JFUnxTQV9SRVNUQVJUfFNBX1NJR0lORk8sIDB4MmIyNzU2NTRk
YjcwfSwgTlVMTCwgOCkgPSAwCnJ0X3NpZ3Byb2NtYXNrKFNJR19VTkJMT0NLLCBbUlRNSU4gUlRf
MV0sIE5VTEwsIDgpID0gMApnZXRybGltaXQoUkxJTUlUX1NUQUNLLCB7cmxpbV9jdXI9MTAyNDAq
MTAyNCwgcmxpbV9tYXg9UkxJTV9JTkZJTklUWX0pID0gMApzdGF0KCIvcHJvYy94ZW4veGVuYnVz
Iiwge3N0X2Rldj1tYWtlZGV2KDAsIDMpLCBzdF9pbm89NDAyNjUzNDY2NywKc3RfbW9kZT1TX0lG
UkVHfDA0MDAsIHN0X25saW5rPTEsIHN0X3VpZD0wLCBzdF9naWQ9MCwgc3RfYmxrc2l6ZT00MDk2
LApzdF9ibG9ja3M9MCwgc3Rfc2l6ZT0wLCBzdF9hdGltZT0yMDEyLzAxLzIwLTEwOjA0OjAzLApz
dF9tdGltZT0yMDEyLzAxLzIwLTEwOjA0OjAzLCBzdF9jdGltZT0yMDEyLzAxLzIwLTEwOjA0OjAz
fSkgPSAwCm9wZW4oIi9wcm9jL3hlbi94ZW5idXMiLCBPX1JEV1IpICAgICAgICA9IDMKYnJrKDAp
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID0gMHg4NDY5MDAwCmJyaygweDg0OGEw
MDApICAgICAgICAgICAgICAgICAgICAgICAgICA9IDB4ODQ4YTAwMApydF9zaWdhY3Rpb24oU0lH
UElQRSwgezB4MSwgW10sIFNBX1JFU1RPUkVSLCAweDJiMjc1NjIxNzJkMH0sCntTSUdfREZMLCBb
XSwgMH0sIDgpID0gMAp3cml0ZSgzLCAiXDJcMFwwXDBcMFwwXDBcMFwwXDBcMFwwXDIxXDBcMFww
IiwgMTYpID0gMTYKd3JpdGUoMywgImNvbnRyb2wvc2h1dGRvd25cMCIsIDE3CgoKCgoKLS0gClZh
c2lsaXkgVG9sc3RvdiwKQ2xvZG8ucnUKZS1tYWlsOiB2LnRvbHN0b3ZAc2VsZmlwLnJ1CmphYmJl
cjogdmFzZUBzZWxmaXAucnUKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:17:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCSL-000872-VR; Fri, 20 Jan 2012 11:16: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 1RoCSK-00086x-BJ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:16:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327058182!7989576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 835 invoked from network); 20 Jan 2012 11:16:22 -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;
	20 Jan 2012 11:16:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:16:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:16:21 +0000
Date: Fri, 20 Jan 2012 11:17:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

Stefano Stabellini (2):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap

 tools/libxc/xc_domain_restore.c |   66 ++++++++++++++------
 tools/libxc/xc_domain_save.c    |   16 +++++
 tools/libxc/xenguest.h          |   22 ++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  132 ++++++++++++++++++++++++++++++++++++++-
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 218 insertions(+), 22 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:17:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:17:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCSL-000872-VR; Fri, 20 Jan 2012 11:16: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 1RoCSK-00086x-BJ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:16:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327058182!7989576!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 835 invoked from network); 20 Jan 2012 11:16:22 -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;
	20 Jan 2012 11:16:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:16:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:16:21 +0000
Date: Fri, 20 Jan 2012 11:17:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.

Stefano Stabellini (2):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap

 tools/libxc/xc_domain_restore.c |   66 ++++++++++++++------
 tools/libxc/xc_domain_save.c    |   16 +++++
 tools/libxc/xenguest.h          |   22 ++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  132 ++++++++++++++++++++++++++++++++++++++-
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 218 insertions(+), 22 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:18:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoCTg-0008O6-GW; Fri, 20 Jan 2012 11:17: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 1RoCTe-0008Gx-KL
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:17:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327058263!3332308!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28994 invoked from network); 20 Jan 2012 11:17:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:17:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178399210"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 06:17: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, 20 Jan 2012 06:17: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 q0KBHZXn014916;
	Fri, 20 Jan 2012 03:17:36 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 11:18:31 +0000
Message-ID: <1327058312-19168-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.1201201106130.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   66 +++++++++++++++++++++++++++-----------
 tools/libxc/xc_domain_save.c    |   16 +++++++++
 tools/libxc/xenguest.h          |   22 ++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 88 insertions(+), 22 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 14451d1..72b6d5b 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -702,7 +702,8 @@ static void pagebuf_free(pagebuf_t* buf)
 }
 
 static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
-                           pagebuf_t* buf, int fd, uint32_t dom)
+                           pagebuf_t* buf, int fd, uint32_t dom,
+                           struct restore_callbacks* callbacks)
 {
     int count, countpages, oldcount, i;
     void* ptmp;
@@ -725,7 +726,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
     case XC_SAVE_ID_ENABLE_VERIFY_MODE:
         DPRINTF("Entering page verify mode\n");
         buf->verify = 1;
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_VCPU_INFO:
         buf->new_ctxt_format = 1;
@@ -736,7 +737,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("Max VCPU ID: %d, vcpumap: %llx\n", buf->max_vcpu_id, buf->vcpumap);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_IDENT_PT:
         /* Skip padding 4 bytes then read the EPT identity PT location. */
@@ -747,7 +748,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_VM86_TSS:
         /* Skip padding 4 bytes then read the vm86 TSS location. */
@@ -758,7 +759,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("VM86 TSS location: %llx\n", buf->vm86_tss);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TMEM:
         DPRINTF("xc_domain_restore start tmem\n");
@@ -766,14 +767,14 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tmem");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TMEM_EXTRA:
         if ( xc_tmem_restore_extra(xch, dom, fd) ) {
             PERROR("error reading/restoring tmem extra");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TSC_INFO:
     {
@@ -787,7 +788,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tsc info");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
     }
 
     case XC_SAVE_ID_HVM_CONSOLE_PFN :
@@ -799,12 +800,12 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("console pfn location: %llx\n", buf->console_pfn);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_LAST_CHECKPOINT:
         ctx->last_checkpoint = 1;
         // DPRINTF("last checkpoint indication received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -814,7 +815,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the acpi ioport location");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_VIRIDIAN:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -824,8 +825,33 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the viridian flag");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            uint32_t len;
+            uint8_t *buf2;
+            RDEXACT(fd, &len, sizeof(len));
+            buf2 = (uint8_t*) malloc(len);
+            if ( buf2 == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf2, len);
+            if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+            {
+                if ( callbacks->toolstack_restore(dom,
+                            buf2, len, callbacks->data) < 0 )
+                {
+                    PERROR("error calling toolstack_restore");
+                    free(buf2);
+                    return -1;
+                }
+            }
+            free(buf2);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
+        }
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -834,7 +860,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
          */
         ctx->compressing = 1;
         // DPRINTF("compression flag received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_COMPRESSED_DATA:
 
@@ -902,7 +928,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
      * following a <XC_SAVE_ID_COMPRESSED_DATA, compressedChunkSize> tuple.
      */
     if (buf->compressing)
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     oldcount = buf->nr_physpages;
     buf->nr_physpages += countpages;
@@ -927,7 +953,8 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
 }
 
 static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
-                       pagebuf_t* buf, int fd, uint32_t dom)
+                       pagebuf_t* buf, int fd, uint32_t dom,
+                       struct restore_callbacks *callbacks)
 {
     int rc;
 
@@ -935,7 +962,7 @@ static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
     buf->compbuf_pos = buf->compbuf_size = 0;
 
     do {
-        rc = pagebuf_get_one(xch, ctx, buf, fd, dom);
+        rc = pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
     } while (rc > 0);
 
     if (rc < 0)
@@ -1248,7 +1275,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 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,
+                      struct restore_callbacks* callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1427,7 +1455,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         if ( !ctx->completed ) {
             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
             pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
-            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
+            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom, callbacks) < 0 ) {
                 PERROR("Error when reading batch");
                 goto out;
             }
@@ -1542,7 +1570,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     // DPRINTF("Buffered checkpoint\n");
 
-    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
+    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom, callbacks) ) {
         PERROR("error when buffering batch, finishing");
         goto finish;
     }
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index a6bb894..3d11c39 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 4475ee9..8120715 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,13 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates and frees the buffer.
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -61,6 +68,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    struct save_callbacks* callbacks, int hvm);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -72,12 +89,15 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @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 callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       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,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index c5e0743..68feec5 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -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_TOOLSTACK          -14 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..fd2b051 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -373,7 +373,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     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, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 985cbec..eb1d31c 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -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,
+                            NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:18:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoCTg-0008O6-GW; Fri, 20 Jan 2012 11:17: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 1RoCTe-0008Gx-KL
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:17:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327058263!3332308!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28994 invoked from network); 20 Jan 2012 11:17:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:17:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178399210"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 06:17: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, 20 Jan 2012 06:17: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 q0KBHZXn014916;
	Fri, 20 Jan 2012 03:17:36 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 11:18:31 +0000
Message-ID: <1327058312-19168-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.1201201106130.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   66 +++++++++++++++++++++++++++-----------
 tools/libxc/xc_domain_save.c    |   16 +++++++++
 tools/libxc/xenguest.h          |   22 ++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 88 insertions(+), 22 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 14451d1..72b6d5b 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -702,7 +702,8 @@ static void pagebuf_free(pagebuf_t* buf)
 }
 
 static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
-                           pagebuf_t* buf, int fd, uint32_t dom)
+                           pagebuf_t* buf, int fd, uint32_t dom,
+                           struct restore_callbacks* callbacks)
 {
     int count, countpages, oldcount, i;
     void* ptmp;
@@ -725,7 +726,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
     case XC_SAVE_ID_ENABLE_VERIFY_MODE:
         DPRINTF("Entering page verify mode\n");
         buf->verify = 1;
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_VCPU_INFO:
         buf->new_ctxt_format = 1;
@@ -736,7 +737,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("Max VCPU ID: %d, vcpumap: %llx\n", buf->max_vcpu_id, buf->vcpumap);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_IDENT_PT:
         /* Skip padding 4 bytes then read the EPT identity PT location. */
@@ -747,7 +748,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_VM86_TSS:
         /* Skip padding 4 bytes then read the vm86 TSS location. */
@@ -758,7 +759,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("VM86 TSS location: %llx\n", buf->vm86_tss);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TMEM:
         DPRINTF("xc_domain_restore start tmem\n");
@@ -766,14 +767,14 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tmem");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TMEM_EXTRA:
         if ( xc_tmem_restore_extra(xch, dom, fd) ) {
             PERROR("error reading/restoring tmem extra");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TSC_INFO:
     {
@@ -787,7 +788,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tsc info");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
     }
 
     case XC_SAVE_ID_HVM_CONSOLE_PFN :
@@ -799,12 +800,12 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("console pfn location: %llx\n", buf->console_pfn);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_LAST_CHECKPOINT:
         ctx->last_checkpoint = 1;
         // DPRINTF("last checkpoint indication received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -814,7 +815,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the acpi ioport location");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_VIRIDIAN:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -824,8 +825,33 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the viridian flag");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            uint32_t len;
+            uint8_t *buf2;
+            RDEXACT(fd, &len, sizeof(len));
+            buf2 = (uint8_t*) malloc(len);
+            if ( buf2 == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf2, len);
+            if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+            {
+                if ( callbacks->toolstack_restore(dom,
+                            buf2, len, callbacks->data) < 0 )
+                {
+                    PERROR("error calling toolstack_restore");
+                    free(buf2);
+                    return -1;
+                }
+            }
+            free(buf2);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
+        }
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -834,7 +860,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
          */
         ctx->compressing = 1;
         // DPRINTF("compression flag received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_COMPRESSED_DATA:
 
@@ -902,7 +928,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
      * following a <XC_SAVE_ID_COMPRESSED_DATA, compressedChunkSize> tuple.
      */
     if (buf->compressing)
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     oldcount = buf->nr_physpages;
     buf->nr_physpages += countpages;
@@ -927,7 +953,8 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
 }
 
 static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
-                       pagebuf_t* buf, int fd, uint32_t dom)
+                       pagebuf_t* buf, int fd, uint32_t dom,
+                       struct restore_callbacks *callbacks)
 {
     int rc;
 
@@ -935,7 +962,7 @@ static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
     buf->compbuf_pos = buf->compbuf_size = 0;
 
     do {
-        rc = pagebuf_get_one(xch, ctx, buf, fd, dom);
+        rc = pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
     } while (rc > 0);
 
     if (rc < 0)
@@ -1248,7 +1275,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 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,
+                      struct restore_callbacks* callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1427,7 +1455,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         if ( !ctx->completed ) {
             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
             pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
-            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
+            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom, callbacks) < 0 ) {
                 PERROR("Error when reading batch");
                 goto out;
             }
@@ -1542,7 +1570,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     // DPRINTF("Buffered checkpoint\n");
 
-    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
+    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom, callbacks) ) {
         PERROR("error when buffering batch, finishing");
         goto finish;
     }
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index a6bb894..3d11c39 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 4475ee9..8120715 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,13 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates and frees the buffer.
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -61,6 +68,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    struct save_callbacks* callbacks, int hvm);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -72,12 +89,15 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @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 callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       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,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index c5e0743..68feec5 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -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_TOOLSTACK          -14 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..fd2b051 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -373,7 +373,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     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, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 985cbec..eb1d31c 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -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,
+                            NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:18:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCTl-0008U7-TX; Fri, 20 Jan 2012 11:17:57 +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 1RoCTk-0008M4-Hz
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:17:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327058268!11691606!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16125 invoked from network); 20 Jan 2012 11:17:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:17:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21103852"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 06:17: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, 20 Jan 2012 06:17: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 q0KBHZXo014916;
	Fri, 20 Jan 2012 03:17:37 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 11:18:32 +0000
Message-ID: <1327058312-19168-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.1201201106130.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fd2b051..3d60a35 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -347,6 +347,62 @@ out:
     return rc;
 }
 
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t namelen = 0;
+    char *name = NULL;
+    uint32_t count = 0;
+    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
+
+    if (size < sizeof(count))
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size <
+            sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        memcpy(&namelen, ptr, sizeof(namelen));
+        ptr += sizeof(namelen);
+        if (namelen > 0) {
+            name = (char *)ptr;
+            ptr += namelen;
+        }
+        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&size_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, phys_offset_v), "%"PRIx64, size_v);
+        if (ret)
+            return -1;
+        if (namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, phys_offset_v), "%s", name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -356,11 +412,14 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -373,7 +432,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages, NULL);
+                           hvm, pae, superpages, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -528,6 +587,76 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    int i = 0;
+    unsigned int num = 0;
+    uint32_t count = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    uint64_t val = 0;
+    uint32_t namelen = 0;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(count) + count * (sizeof(val) * 3 + sizeof(namelen));
+    *buf = libxl__calloc(gc, 1, *len);
+    ptr = *buf;
+
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL) {
+            namelen = 0;
+        } else {
+            unsigned long offset;
+            namelen = strlen(name) + 1;
+            *len += namelen;
+            offset = ptr - (*buf);
+            *buf = libxl__realloc(gc, *buf, *len);
+            ptr = (*buf) + offset;
+        }
+        memcpy(ptr, &namelen, sizeof(namelen));
+        ptr += sizeof(namelen);
+        if (namelen > 0) {
+            memcpy(ptr, name, namelen);
+            ptr += namelen;
+        }
+        val = strtoll(phys_offset, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(start_addr, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(size, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -579,6 +708,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
-- 
1.7.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 Jan 20 11:18:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:18:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCTl-0008U7-TX; Fri, 20 Jan 2012 11:17:57 +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 1RoCTk-0008M4-Hz
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:17:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327058268!11691606!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16125 invoked from network); 20 Jan 2012 11:17:50 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:17:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21103852"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 06:17: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, 20 Jan 2012 06:17: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 q0KBHZXo014916;
	Fri, 20 Jan 2012 03:17:37 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 11:18:32 +0000
Message-ID: <1327058312-19168-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.1201201106130.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fd2b051..3d60a35 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -347,6 +347,62 @@ out:
     return rc;
 }
 
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t namelen = 0;
+    char *name = NULL;
+    uint32_t count = 0;
+    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
+
+    if (size < sizeof(count))
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size <
+            sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        memcpy(&namelen, ptr, sizeof(namelen));
+        ptr += sizeof(namelen);
+        if (namelen > 0) {
+            name = (char *)ptr;
+            ptr += namelen;
+        }
+        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+        memcpy(&size_v, ptr, sizeof(uint64_t));
+        ptr += sizeof(uint64_t);
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, phys_offset_v), "%"PRIx64, size_v);
+        if (ret)
+            return -1;
+        if (namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, phys_offset_v), "%s", name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -356,11 +412,14 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -373,7 +432,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages, NULL);
+                           hvm, pae, superpages, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -528,6 +587,76 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    int i = 0;
+    unsigned int num = 0;
+    uint32_t count = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    uint64_t val = 0;
+    uint32_t namelen = 0;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(count) + count * (sizeof(val) * 3 + sizeof(namelen));
+    *buf = libxl__calloc(gc, 1, *len);
+    ptr = *buf;
+
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL) {
+            namelen = 0;
+        } else {
+            unsigned long offset;
+            namelen = strlen(name) + 1;
+            *len += namelen;
+            offset = ptr - (*buf);
+            *buf = libxl__realloc(gc, *buf, *len);
+            ptr = (*buf) + offset;
+        }
+        memcpy(ptr, &namelen, sizeof(namelen));
+        ptr += sizeof(namelen);
+        if (namelen > 0) {
+            memcpy(ptr, name, namelen);
+            ptr += namelen;
+        }
+        val = strtoll(phys_offset, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(start_addr, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+        val = strtoll(size, NULL, 16);
+        memcpy(ptr, &val, sizeof(val));
+        ptr += sizeof(val);
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -579,6 +708,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
-- 
1.7.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 Jan 20 11:23:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCYU-0000QL-Lb; Fri, 20 Jan 2012 11:22:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoCYT-0000Ps-1F
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:22:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327058563!8563165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27276 invoked from network); 20 Jan 2012 11:22:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:22: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, 20 Jan 2012 11:22:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 11:22:42 +0000
In-Reply-To: <alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327058562.17599.134.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDEyLTAxLTIwIGF0IDEwOjU1ICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gT24gRnJpLCAyMCBKYW4gMjAxMiwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gVGh1
LCAyMDEyLTAxLTE5IGF0IDIxOjE0ICswMDAwLCBQYXNpIEvDg8aSw4LGksOD4oCaw4LCpHJra8OD
xpLDgsaSw4PigJrDgsKkaW5lbiB3cm90ZToKPiA+ID4gT24gV2VkLCBKYW4gMDQsIDIwMTIgYXQg
MDQ6Mjk6MjJQTSArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gPiA+IAo+ID4gPiA+IEhh
cyBhbnlib2R5IGdvdCBhbnl0aGluZyBlbHNlPyBJJ20gc3VyZSBJJ3ZlIG1pc3NlZCBzdHVmZi4g
QXJlIHRoZXJlIGFueQo+ID4gPiA+IG11c3QgaGF2ZXMgZS5nLiBpbiB0aGUgcGFnaW5nL3NoYXJp
bmcgc3BhY2VzPwo+ID4gPiA+IAo+ID4gPiAKPiA+ID4gU29tZXRoaW5nIHRoYXQgSSBqdXN0IHJl
bWVtYmVyZWQ6Cj4gPiA+IGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9YZW40LjEKPiA+ID4g
Cj4gPiA+ICJOVU1BLWF3YXJlIG1lbW9yeSBhbGxvY2F0aW9uIGZvciBWTXMuIHhsIGluIFhlbiA0
LjEgd2lsbCBhbGxvY2F0ZQo+ID4gPiBlcXVhbCBhbW91bnQgb2YgbWVtb3J5IGZyb20gZXZlcnkg
TlVNQSBub2RlIGZvciB0aGUgVk0uIHhtL3hlbmQKPiA+ID4gYWxsb2NhdGVzIGFsbCB0aGUgbWVt
b3J5IGZyb20gdGhlIHNhbWUgTlVNQSBub2RlLiIKPiA+IAo+ID4gSSdtIG5vdCB0aGF0IGZhbWls
aWFyIHdpdGggdGhlIE5VTUEgc3VwcG9ydCBidXQgbXkgdW5kZXJzdGFuZGluZyB3YXMKPiA+IHRo
YXQgbWVtb3J5IHdhcyBhbGxvY2F0ZWQgYnkgbGlieGMvdGhlLWh5cGVydmlzb3IgYW5kIG5vdCBi
eSB0aGUKPiA+IHRvb2xzdGFjayBhbmQgdGhhdCB0aGUgZGVmYXVsdCB3YXMgdG8gYWxsb2NhdGUg
ZnJvbSB0aGUgc2FtZSBudW1hIG5vZGVzCj4gPiBhcyBkb21haW5zIHRoZSBwcm9jZXNzb3IncyB3
ZXJlIHBpbm5lZCB0byBpLmUuIGlmIHlvdSBwaW4gdGhlIHByb2Nlc3NvcnMKPiA+IGFwcHJvcHJp
YXRlbHkgdGhlIFJpZ2h0IFRoaW5nIGp1c3QgaGFwcGVucy4gRG8geW91IGJlbGlldmUgdGhpcyBp
cyBub3QKPiA+IHRoZSBjYXNlIGFuZC9vciBub3Qgd29ya2luZyByaWdodCB3aXRoIHhsPwo+IAo+
IEl0IHNlZW1zIHRoYXQgeGVuZCBpcyByZXRyaWV2aW5nIG51bWEgaW5mbyBhYm91dCB0aGUgcGxh
dGZvcm0sIHNlZQo+IHB5eGNfbnVtYWluZm8sIHRoZW4gdXNpbmcgdGhvc2UgaW5mbyB0byBwaW4g
dmNwdXMgdG8gcGNwdXMsIHNlZQo+IF9zZXRDUFVBZmZpbml0eS4KPiBTdGlsbCBpdCBzZWVtcyB0
byBtZSBtb3JlIG9mIGFuIGhhY2sgdGhhbiB0aGUgcmlnaHQgd2F5IHRvIHNvbHZlIHRoZQo+IHBy
b2JsZW0uCgpSaWdodCwgc28gaW4gdGhlIGFic2VuY2Ugb2YgYW55IGV4cGxpY2l0IGNvbmZpZ3Vy
YXRpb24gaXQgYmFzaWNhbGx5CnBpY2tzIGEgTlVNQSBub2RlICh2aWEgc29tZSBoZXVyaXN0aWMp
IGFuZCBhdXRvbWF0aWNhbGx5IHB1dHMgdGhlIGd1ZXN0CmludG8gaXQuCgpJdCBzZWVtcyB0byBt
ZSB0aGF0IHhsJ3MgYmVoYXZpb3VyIGlzbid0IHdyb25nIGFzIHN1Y2gsIGl0J3MganVzdApkaWZm
ZXJlbnQuCgpJIHRoaW5rIHRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB4bCBzaG91bGQgaG9u
b3VyIHVzZXIncyBleHBsaWNpdApyZXF1ZXN0cyB0byB1c2UgYSBwYXJ0aWN1bGFyIG5vZGUsIGVp
dGhlciB2aWEgdmNwdSBwaW5uaW5nIG9yIGNwdXBvb2xzCmV0Yy4KCklhbi4KCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:23:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:23:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCYU-0000QL-Lb; Fri, 20 Jan 2012 11:22:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoCYT-0000Ps-1F
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:22:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327058563!8563165!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27276 invoked from network); 20 Jan 2012 11:22:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174574"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:22: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, 20 Jan 2012 11:22:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 11:22:42 +0000
In-Reply-To: <alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327058562.17599.134.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCAyMDEyLTAxLTIwIGF0IDEwOjU1ICswMDAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv
dGU6Cj4gT24gRnJpLCAyMCBKYW4gMjAxMiwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gT24gVGh1
LCAyMDEyLTAxLTE5IGF0IDIxOjE0ICswMDAwLCBQYXNpIEvDg8aSw4LGksOD4oCaw4LCpHJra8OD
xpLDgsaSw4PigJrDgsKkaW5lbiB3cm90ZToKPiA+ID4gT24gV2VkLCBKYW4gMDQsIDIwMTIgYXQg
MDQ6Mjk6MjJQTSArMDAwMCwgSWFuIENhbXBiZWxsIHdyb3RlOgo+ID4gPiA+IAo+ID4gPiA+IEhh
cyBhbnlib2R5IGdvdCBhbnl0aGluZyBlbHNlPyBJJ20gc3VyZSBJJ3ZlIG1pc3NlZCBzdHVmZi4g
QXJlIHRoZXJlIGFueQo+ID4gPiA+IG11c3QgaGF2ZXMgZS5nLiBpbiB0aGUgcGFnaW5nL3NoYXJp
bmcgc3BhY2VzPwo+ID4gPiA+IAo+ID4gPiAKPiA+ID4gU29tZXRoaW5nIHRoYXQgSSBqdXN0IHJl
bWVtYmVyZWQ6Cj4gPiA+IGh0dHA6Ly93aWtpLnhlbi5vcmcveGVud2lraS9YZW40LjEKPiA+ID4g
Cj4gPiA+ICJOVU1BLWF3YXJlIG1lbW9yeSBhbGxvY2F0aW9uIGZvciBWTXMuIHhsIGluIFhlbiA0
LjEgd2lsbCBhbGxvY2F0ZQo+ID4gPiBlcXVhbCBhbW91bnQgb2YgbWVtb3J5IGZyb20gZXZlcnkg
TlVNQSBub2RlIGZvciB0aGUgVk0uIHhtL3hlbmQKPiA+ID4gYWxsb2NhdGVzIGFsbCB0aGUgbWVt
b3J5IGZyb20gdGhlIHNhbWUgTlVNQSBub2RlLiIKPiA+IAo+ID4gSSdtIG5vdCB0aGF0IGZhbWls
aWFyIHdpdGggdGhlIE5VTUEgc3VwcG9ydCBidXQgbXkgdW5kZXJzdGFuZGluZyB3YXMKPiA+IHRo
YXQgbWVtb3J5IHdhcyBhbGxvY2F0ZWQgYnkgbGlieGMvdGhlLWh5cGVydmlzb3IgYW5kIG5vdCBi
eSB0aGUKPiA+IHRvb2xzdGFjayBhbmQgdGhhdCB0aGUgZGVmYXVsdCB3YXMgdG8gYWxsb2NhdGUg
ZnJvbSB0aGUgc2FtZSBudW1hIG5vZGVzCj4gPiBhcyBkb21haW5zIHRoZSBwcm9jZXNzb3IncyB3
ZXJlIHBpbm5lZCB0byBpLmUuIGlmIHlvdSBwaW4gdGhlIHByb2Nlc3NvcnMKPiA+IGFwcHJvcHJp
YXRlbHkgdGhlIFJpZ2h0IFRoaW5nIGp1c3QgaGFwcGVucy4gRG8geW91IGJlbGlldmUgdGhpcyBp
cyBub3QKPiA+IHRoZSBjYXNlIGFuZC9vciBub3Qgd29ya2luZyByaWdodCB3aXRoIHhsPwo+IAo+
IEl0IHNlZW1zIHRoYXQgeGVuZCBpcyByZXRyaWV2aW5nIG51bWEgaW5mbyBhYm91dCB0aGUgcGxh
dGZvcm0sIHNlZQo+IHB5eGNfbnVtYWluZm8sIHRoZW4gdXNpbmcgdGhvc2UgaW5mbyB0byBwaW4g
dmNwdXMgdG8gcGNwdXMsIHNlZQo+IF9zZXRDUFVBZmZpbml0eS4KPiBTdGlsbCBpdCBzZWVtcyB0
byBtZSBtb3JlIG9mIGFuIGhhY2sgdGhhbiB0aGUgcmlnaHQgd2F5IHRvIHNvbHZlIHRoZQo+IHBy
b2JsZW0uCgpSaWdodCwgc28gaW4gdGhlIGFic2VuY2Ugb2YgYW55IGV4cGxpY2l0IGNvbmZpZ3Vy
YXRpb24gaXQgYmFzaWNhbGx5CnBpY2tzIGEgTlVNQSBub2RlICh2aWEgc29tZSBoZXVyaXN0aWMp
IGFuZCBhdXRvbWF0aWNhbGx5IHB1dHMgdGhlIGd1ZXN0CmludG8gaXQuCgpJdCBzZWVtcyB0byBt
ZSB0aGF0IHhsJ3MgYmVoYXZpb3VyIGlzbid0IHdyb25nIGFzIHN1Y2gsIGl0J3MganVzdApkaWZm
ZXJlbnQuCgpJIHRoaW5rIHRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB4bCBzaG91bGQgaG9u
b3VyIHVzZXIncyBleHBsaWNpdApyZXF1ZXN0cyB0byB1c2UgYSBwYXJ0aWN1bGFyIG5vZGUsIGVp
dGhlciB2aWEgdmNwdSBwaW5uaW5nIG9yIGNwdXBvb2xzCmV0Yy4KCklhbi4KCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:25:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:25:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCar-0000Zg-C2; Fri, 20 Jan 2012 11:25:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoCaq-0000ZH-PZ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:25:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327058710!3042544!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2147 invoked from network); 20 Jan 2012 11:25:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:25:10 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:25:10 +0000
Date: Fri, 20 Jan 2012 11:25:53 +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: <1327058562.17599.134.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201124420.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1836992929-1327058769=:3150"
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-1836992929-1327058769=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Fri, 20 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-20 at 10:55 +0000, Stefano Stabellini wrote:
> > On Fri, 20 Jan 2012, Ian Campbell wrote:
> > > On Thu, 2012-01-19 at 21:14 +0000, Pasi Kärkkäinen wrote:
> > > > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > > > 
> > > > > Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > > > > must haves e.g. in the paging/sharing spaces?
> > > > > 
> > > > 
> > > > Something that I just remembered:
> > > > http://wiki.xen.org/xenwiki/Xen4.1
> > > > 
> > > > "NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate
> > > > equal amount of memory from every NUMA node for the VM. xm/xend
> > > > allocates all the memory from the same NUMA node."
> > > 
> > > I'm not that familiar with the NUMA support but my understanding was
> > > that memory was allocated by libxc/the-hypervisor and not by the
> > > toolstack and that the default was to allocate from the same numa nodes
> > > as domains the processor's were pinned to i.e. if you pin the processors
> > > appropriately the Right Thing just happens. Do you believe this is not
> > > the case and/or not working right with xl?
> > 
> > It seems that xend is retrieving numa info about the platform, see
> > pyxc_numainfo, then using those info to pin vcpus to pcpus, see
> > _setCPUAffinity.
> > Still it seems to me more of an hack than the right way to solve the
> > problem.
> 
> Right, so in the absence of any explicit configuration it basically
> picks a NUMA node (via some heuristic) and automatically puts the guest
> into it.
> 
> It seems to me that xl's behaviour isn't wrong as such, it's just
> different.
> 
> I think the important thing is that xl should honour user's explicit
> requests to use a particular node, either via vcpu pinning or cpupools
> etc.
 
Indeed.
Moreover it should be a choice for the allocator and the scheduler to
make, not the toolstack.
Otherwise we end up with non-NUMA algorithms in Xen and NUMA algorithms
in the toolstack?
--8323329-1836992929-1327058769=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1836992929-1327058769=:3150--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:25:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:25:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCar-0000Zg-C2; Fri, 20 Jan 2012 11:25:17 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoCaq-0000ZH-PZ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:25:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327058710!3042544!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2147 invoked from network); 20 Jan 2012 11:25:10 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 11:25:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:25:10 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:25:10 +0000
Date: Fri, 20 Jan 2012 11:25:53 +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: <1327058562.17599.134.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201124420.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1836992929-1327058769=:3150"
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Dario Faggioli <dario.faggioli@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-1836992929-1327058769=:3150
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Fri, 20 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-20 at 10:55 +0000, Stefano Stabellini wrote:
> > On Fri, 20 Jan 2012, Ian Campbell wrote:
> > > On Thu, 2012-01-19 at 21:14 +0000, Pasi Kärkkäinen wrote:
> > > > On Wed, Jan 04, 2012 at 04:29:22PM +0000, Ian Campbell wrote:
> > > > > 
> > > > > Has anybody got anything else? I'm sure I've missed stuff. Are there any
> > > > > must haves e.g. in the paging/sharing spaces?
> > > > > 
> > > > 
> > > > Something that I just remembered:
> > > > http://wiki.xen.org/xenwiki/Xen4.1
> > > > 
> > > > "NUMA-aware memory allocation for VMs. xl in Xen 4.1 will allocate
> > > > equal amount of memory from every NUMA node for the VM. xm/xend
> > > > allocates all the memory from the same NUMA node."
> > > 
> > > I'm not that familiar with the NUMA support but my understanding was
> > > that memory was allocated by libxc/the-hypervisor and not by the
> > > toolstack and that the default was to allocate from the same numa nodes
> > > as domains the processor's were pinned to i.e. if you pin the processors
> > > appropriately the Right Thing just happens. Do you believe this is not
> > > the case and/or not working right with xl?
> > 
> > It seems that xend is retrieving numa info about the platform, see
> > pyxc_numainfo, then using those info to pin vcpus to pcpus, see
> > _setCPUAffinity.
> > Still it seems to me more of an hack than the right way to solve the
> > problem.
> 
> Right, so in the absence of any explicit configuration it basically
> picks a NUMA node (via some heuristic) and automatically puts the guest
> into it.
> 
> It seems to me that xl's behaviour isn't wrong as such, it's just
> different.
> 
> I think the important thing is that xl should honour user's explicit
> requests to use a particular node, either via vcpu pinning or cpupools
> etc.
 
Indeed.
Moreover it should be a choice for the allocator and the scheduler to
make, not the toolstack.
Otherwise we end up with non-NUMA algorithms in Xen and NUMA algorithms
in the toolstack?
--8323329-1836992929-1327058769=:3150
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 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-1836992929-1327058769=:3150--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:28:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoCdO-0000iV-Vu; Fri, 20 Jan 2012 11:27:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoCdO-0000iL-0W
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:27:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327058867!9916048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7162 invoked from network); 20 Jan 2012 11:27:47 -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 Jan 2012 11:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:27:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:27:46 +0000
Date: Fri, 20 Jan 2012 11:28:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F185986020000780006DBF9@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201201128030.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
	<4F185986020000780006DBF9@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 v5 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

On Thu, 19 Jan 2012, Jan Beulich wrote:
> >>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
> > As I wanted to use the clear_guest stuff you add here for some
> > cleanup/latent bug fix in x86's paging code, I pulled this patch into
> > my local tree. Unfortunately the ia64 bits don't build, as you omitted
> > the #define-s at the top of the file you took the code from.
> 
> Further, the file you put this in is one that shouldn't be modified. The
> correct way is to simply pull in Linux'es clear_user.S (see below).
> 

Yes, I think that you are correct.

 
> --- a/xen/arch/ia64/linux/Makefile
> +++ b/xen/arch/ia64/linux/Makefile
> @@ -4,6 +4,7 @@ subdir-y += sn
>  
>  obj-y += bitop.o
>  obj-y += clear_page.o
> +obj-y += clear_user.o
>  obj-y += copy_page_mck.o
>  obj-y += efi_stub.o
>  obj-y += extable.o
> --- a/xen/arch/ia64/linux/README.origin
> +++ b/xen/arch/ia64/linux/README.origin
> @@ -15,6 +15,7 @@ pcdp.h			-> linux/drivers/firmware/pcdp.
>  
>  bitop.c			-> linux/arch/ia64/lib/bitop.c
>  clear_page.S		-> linux/arch/ia64/lib/clear_page.S
> +clear_user.S		-> linux/arch/ia64/lib/clear_user.S
>  copy_page_mck.S		-> linux/arch/ia64/lib/copy_page_mck.S
>  flush.S			-> linux/arch/ia64/lib/flush.S
>  idiv32.S		-> linux/arch/ia64/lib/idiv32.S
> --- /dev/null
> +++ b/xen/arch/ia64/linux/clear_user.S
> @@ -0,0 +1,209 @@
> +/*
> + * This routine clears to zero a linear memory buffer in user space.
> + *
> + * Inputs:
> + *	in0:	address of buffer
> + *	in1:	length of buffer in bytes
> + * Outputs:
> + *	r8:	number of bytes that didn't get cleared due to a fault
> + *
> + * Copyright (C) 1998, 1999, 2001 Hewlett-Packard Co
> + *	Stephane Eranian <eranian@hpl.hp.com>
> + */
> +
> +#include <asm/asmmacro.h>
> +
> +//
> +// arguments
> +//
> +#define buf		r32
> +#define len		r33
> +
> +//
> +// local registers
> +//
> +#define cnt		r16
> +#define buf2		r17
> +#define saved_lc	r18
> +#define saved_pfs	r19
> +#define tmp		r20
> +#define len2		r21
> +#define len3		r22
> +
> +//
> +// 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)
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:28:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoCdO-0000iV-Vu; Fri, 20 Jan 2012 11:27:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoCdO-0000iL-0W
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:27:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327058867!9916048!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7162 invoked from network); 20 Jan 2012 11:27:47 -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 Jan 2012 11:27:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174692"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:27:46 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:27:46 +0000
Date: Fri, 20 Jan 2012 11:28:29 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F185986020000780006DBF9@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201201128030.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
	<4F185986020000780006DBF9@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 v5 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

On Thu, 19 Jan 2012, Jan Beulich wrote:
> >>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
> > As I wanted to use the clear_guest stuff you add here for some
> > cleanup/latent bug fix in x86's paging code, I pulled this patch into
> > my local tree. Unfortunately the ia64 bits don't build, as you omitted
> > the #define-s at the top of the file you took the code from.
> 
> Further, the file you put this in is one that shouldn't be modified. The
> correct way is to simply pull in Linux'es clear_user.S (see below).
> 

Yes, I think that you are correct.

 
> --- a/xen/arch/ia64/linux/Makefile
> +++ b/xen/arch/ia64/linux/Makefile
> @@ -4,6 +4,7 @@ subdir-y += sn
>  
>  obj-y += bitop.o
>  obj-y += clear_page.o
> +obj-y += clear_user.o
>  obj-y += copy_page_mck.o
>  obj-y += efi_stub.o
>  obj-y += extable.o
> --- a/xen/arch/ia64/linux/README.origin
> +++ b/xen/arch/ia64/linux/README.origin
> @@ -15,6 +15,7 @@ pcdp.h			-> linux/drivers/firmware/pcdp.
>  
>  bitop.c			-> linux/arch/ia64/lib/bitop.c
>  clear_page.S		-> linux/arch/ia64/lib/clear_page.S
> +clear_user.S		-> linux/arch/ia64/lib/clear_user.S
>  copy_page_mck.S		-> linux/arch/ia64/lib/copy_page_mck.S
>  flush.S			-> linux/arch/ia64/lib/flush.S
>  idiv32.S		-> linux/arch/ia64/lib/idiv32.S
> --- /dev/null
> +++ b/xen/arch/ia64/linux/clear_user.S
> @@ -0,0 +1,209 @@
> +/*
> + * This routine clears to zero a linear memory buffer in user space.
> + *
> + * Inputs:
> + *	in0:	address of buffer
> + *	in1:	length of buffer in bytes
> + * Outputs:
> + *	r8:	number of bytes that didn't get cleared due to a fault
> + *
> + * Copyright (C) 1998, 1999, 2001 Hewlett-Packard Co
> + *	Stephane Eranian <eranian@hpl.hp.com>
> + */
> +
> +#include <asm/asmmacro.h>
> +
> +//
> +// arguments
> +//
> +#define buf		r32
> +#define len		r33
> +
> +//
> +// local registers
> +//
> +#define cnt		r16
> +#define buf2		r17
> +#define saved_lc	r18
> +#define saved_pfs	r19
> +#define tmp		r20
> +#define len2		r21
> +#define len3		r22
> +
> +//
> +// 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)
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:33:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCio-0000vO-U3; Fri, 20 Jan 2012 11:33:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoCin-0000vE-1P
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:33:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327059202!9949395!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15281 invoked from network); 20 Jan 2012 11:33:22 -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 Jan 2012 11:33:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:33:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 11:33:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 11:33:22 +0000
In-Reply-To: <1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327059202.30054.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 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index a6bb894..3d11c39 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>          }
>      }
> 
> +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> +    {
> +        int id = XC_SAVE_ID_TOOLSTACK;
> +        uint8_t *buf;
> +        uint32_t len;
> +
> +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> +        {
> +            PERROR("Error calling toolstack_save");
> +            goto out;
> +        }
> +        wrexact(io_fd, &id, sizeof(id));
> +        wrexact(io_fd, &len, sizeof(len));
> +        wrexact(io_fd, buf, len);

Where is buf free'd? You say below "callee allocates and frees the
buffer" but there is no way that can be the case since the caller uses
the buffer after the callback.

I think it has to be callee-alloc, caller-free (perhaps callee-free on
error).

> +    }
> +
>      if ( !callbacks->checkpoint )
>      {
>          /*
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 4475ee9..8120715 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -44,6 +44,13 @@ struct save_callbacks {
>      /* Enable qemu-dm logging dirty pages to xen */
>      int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
> 
> +    /* Save toolstack specific data
> +     * @param buf the buffer with the data to be saved
> +     * @param len the length of the buffer
> +     * The callee allocates and frees the buffer.
> +     */
> +    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
> +
>      /* to be provided as the last argument to each callback function */
>      void* data;
>  };

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:33:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:33:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCio-0000vO-U3; Fri, 20 Jan 2012 11:33:30 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoCin-0000vE-1P
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:33:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327059202!9949395!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15281 invoked from network); 20 Jan 2012 11:33:22 -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 Jan 2012 11:33:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10174826"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:33:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 11:33:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 11:33:22 +0000
In-Reply-To: <1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327059202.30054.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 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index a6bb894..3d11c39 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
>          }
>      }
> 
> +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> +    {
> +        int id = XC_SAVE_ID_TOOLSTACK;
> +        uint8_t *buf;
> +        uint32_t len;
> +
> +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> +        {
> +            PERROR("Error calling toolstack_save");
> +            goto out;
> +        }
> +        wrexact(io_fd, &id, sizeof(id));
> +        wrexact(io_fd, &len, sizeof(len));
> +        wrexact(io_fd, buf, len);

Where is buf free'd? You say below "callee allocates and frees the
buffer" but there is no way that can be the case since the caller uses
the buffer after the callback.

I think it has to be callee-alloc, caller-free (perhaps callee-free on
error).

> +    }
> +
>      if ( !callbacks->checkpoint )
>      {
>          /*
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 4475ee9..8120715 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -44,6 +44,13 @@ struct save_callbacks {
>      /* Enable qemu-dm logging dirty pages to xen */
>      int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
> 
> +    /* Save toolstack specific data
> +     * @param buf the buffer with the data to be saved
> +     * @param len the length of the buffer
> +     * The callee allocates and frees the buffer.
> +     */
> +    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
> +
>      /* to be provided as the last argument to each callback function */
>      void* data;
>  };

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:37:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:37:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCmo-00014V-1W; Fri, 20 Jan 2012 11:37:38 +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 1RoCmm-000144-0l
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:37:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327059449!11876467!2
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 6175 invoked from network); 20 Jan 2012 11:37:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 11:37:29 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74866557; Fri, 20 Jan 2012 10:47:11 +0100
Message-ID: <1327052823.2337.5.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 10:47:03 +0100
In-Reply-To: <1327050108.17599.113.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<20120120081529.GU12984@reaktio.net>
	<1327050108.17599.113.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3411103588225465041=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3411103588225465041==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-fWEfLRRSJeTKP3ANoemI"


--=-fWEfLRRSJeTKP3ANoemI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 09:01 +0000, Ian Campbell wrote:=20
> > See this thread:=20
> > http://old-list-archives.xen.org/archives/html/xen-devel/2011-07/msg014=
23.html
> >=20
> > where Stefano wrote:
> > "I think we forgot about this feature but it is important and hopefully
> > somebody will write a patch for it before 4.2 is out."
>=20
> Is anyone looking into this?
>=20
Hi,

Actually, I'll be investigating how we could gradually introduce some
NUMA support in both the Xen scheduler and memory allocator!

I already have some ideas and I'm looking at the code to better
understand it and find out what's the best strategy and from where it's
better to start. I can give some more details, here or on separate
thread, in a few days, if you're interested.

The only thing is that I'm not sure how far I'll be able to get before
4.2. I really think I'll have _something_ but maybe not a full-fledged
NUMA-aware patchset! :-P

> Does cpupool-numa-split solve this same problem?
>=20
I'm looking right into that, and indeed I think it does a lot in this
direction. The idea was to try doing something similar in a sort of
automatic fashion, so that everyone can benefit from at least some
NUMA-awareness, even without having to bother with cpupools.

It that what you were asking?

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)



--=-fWEfLRRSJeTKP3ANoemI
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)

iEYEABECAAYFAk8ZOBcACgkQk4XaBE3IOsREngCfUHwYuAVy99ieTiPJ5ET5S1wP
BAgAn1Ci4M3BREWeTNHUMbOYGUT9Pl2G
=CwVH
-----END PGP SIGNATURE-----

--=-fWEfLRRSJeTKP3ANoemI--



--===============3411103588225465041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3411103588225465041==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:37:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:37:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCmo-00014V-1W; Fri, 20 Jan 2012 11:37:38 +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 1RoCmm-000144-0l
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:37:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327059449!11876467!2
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 6175 invoked from network); 20 Jan 2012 11:37:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 11:37:29 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74866557; Fri, 20 Jan 2012 10:47:11 +0100
Message-ID: <1327052823.2337.5.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 10:47:03 +0100
In-Reply-To: <1327050108.17599.113.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<20120120081529.GU12984@reaktio.net>
	<1327050108.17599.113.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3411103588225465041=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============3411103588225465041==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-fWEfLRRSJeTKP3ANoemI"


--=-fWEfLRRSJeTKP3ANoemI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 09:01 +0000, Ian Campbell wrote:=20
> > See this thread:=20
> > http://old-list-archives.xen.org/archives/html/xen-devel/2011-07/msg014=
23.html
> >=20
> > where Stefano wrote:
> > "I think we forgot about this feature but it is important and hopefully
> > somebody will write a patch for it before 4.2 is out."
>=20
> Is anyone looking into this?
>=20
Hi,

Actually, I'll be investigating how we could gradually introduce some
NUMA support in both the Xen scheduler and memory allocator!

I already have some ideas and I'm looking at the code to better
understand it and find out what's the best strategy and from where it's
better to start. I can give some more details, here or on separate
thread, in a few days, if you're interested.

The only thing is that I'm not sure how far I'll be able to get before
4.2. I really think I'll have _something_ but maybe not a full-fledged
NUMA-aware patchset! :-P

> Does cpupool-numa-split solve this same problem?
>=20
I'm looking right into that, and indeed I think it does a lot in this
direction. The idea was to try doing something similar in a sort of
automatic fashion, so that everyone can benefit from at least some
NUMA-awareness, even without having to bother with cpupools.

It that what you were asking?

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)



--=-fWEfLRRSJeTKP3ANoemI
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)

iEYEABECAAYFAk8ZOBcACgkQk4XaBE3IOsREngCfUHwYuAVy99ieTiPJ5ET5S1wP
BAgAn1Ci4M3BREWeTNHUMbOYGUT9Pl2G
=CwVH
-----END PGP SIGNATURE-----

--=-fWEfLRRSJeTKP3ANoemI--



--===============3411103588225465041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3411103588225465041==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:37:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:37:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCmn-00014O-LG; Fri, 20 Jan 2012 11:37:37 +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 1RoCml-000142-Nt
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:37:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327059449!11876467!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 6148 invoked from network); 20 Jan 2012 11:37:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 11:37:29 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74884428; Fri, 20 Jan 2012 12:26:39 +0100
Message-ID: <1327058792.2337.22.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 12:26:32 +0100
In-Reply-To: <alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5218700503627359178=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5218700503627359178==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-4cIuByXWoZUgwWBdSPVD"


--=-4cIuByXWoZUgwWBdSPVD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 10:55 +0000, Stefano Stabellini wrote:=20
> It seems that xend is retrieving numa info about the platform, see
> pyxc_numainfo, then using those info to pin vcpus to pcpus, see
> _setCPUAffinity.
> Still it seems to me more of an hack than the right way to solve the
> problem.
>
And it looks very much the same to me.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, PhD, Senior Software Engineer, Citrix Systems R&D Ltd.,
Cambridge (UK)



--=-4cIuByXWoZUgwWBdSPVD
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)

iEYEABECAAYFAk8ZT2gACgkQk4XaBE3IOsSSYACcDdAnsuAdFQzVLsviXa/9Ej4k
mB4AoIDnBbc/OMva3CXlJUHHKgXX7VPm
=qx4g
-----END PGP SIGNATURE-----

--=-4cIuByXWoZUgwWBdSPVD--



--===============5218700503627359178==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5218700503627359178==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:37:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:37:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoCmn-00014O-LG; Fri, 20 Jan 2012 11:37:37 +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 1RoCml-000142-Nt
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:37:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327059449!11876467!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 6148 invoked from network); 20 Jan 2012 11:37:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 11:37:29 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74884428; Fri, 20 Jan 2012 12:26:39 +0100
Message-ID: <1327058792.2337.22.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 12:26:32 +0100
In-Reply-To: <alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5218700503627359178=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5218700503627359178==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-4cIuByXWoZUgwWBdSPVD"


--=-4cIuByXWoZUgwWBdSPVD
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 10:55 +0000, Stefano Stabellini wrote:=20
> It seems that xend is retrieving numa info about the platform, see
> pyxc_numainfo, then using those info to pin vcpus to pcpus, see
> _setCPUAffinity.
> Still it seems to me more of an hack than the right way to solve the
> problem.
>
And it looks very much the same to me.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, PhD, Senior Software Engineer, Citrix Systems R&D Ltd.,
Cambridge (UK)



--=-4cIuByXWoZUgwWBdSPVD
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)

iEYEABECAAYFAk8ZT2gACgkQk4XaBE3IOsSSYACcDdAnsuAdFQzVLsviXa/9Ej4k
mB4AoIDnBbc/OMva3CXlJUHHKgXX7VPm
=qx4g
-----END PGP SIGNATURE-----

--=-4cIuByXWoZUgwWBdSPVD--



--===============5218700503627359178==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5218700503627359178==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:43:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11: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 1RoCrx-0001Pi-06; Fri, 20 Jan 2012 11:42:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoCrw-0001PP-2Z
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:42:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327059770!7994080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26537 invoked from network); 20 Jan 2012 11:42:50 -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;
	20 Jan 2012 11:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10175051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:42:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 11:42:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 11:42:49 +0000
In-Reply-To: <1327058312-19168-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327059769.30054.12.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/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> Read Qemu's physmap from xenstore and save it using toolstack_save.
> Restore Qemu's physmap using toolstack_restore.

Shall we have a version field now so we don't dig ourselves a hole we
can't get out of?

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 131 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index fd2b051..3d60a35 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -347,6 +347,62 @@ out:
>      return rc;
>  }
>  
> +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> +        uint32_t size, void *data)
> +{
> +    libxl__gc *gc = (libxl__gc *) data;
> +    int i, ret;
> +    uint8_t *ptr = buf;
> +    uint32_t namelen = 0;
> +    char *name = NULL;
> +    uint32_t count = 0;
> +    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
> +
> +    if (size < sizeof(count))
> +        return -1;
> +
> +    memcpy(&count, ptr, sizeof(count));
> +    ptr += sizeof(count);
> + 
> +    if (size <
> +            sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
> +        return -1;
> +
> +    for (i = 0; i < count; i++) {
> +        memcpy(&namelen, ptr, sizeof(namelen));
> +        ptr += sizeof(namelen);
> +        if (namelen > 0) {
> +            name = (char *)ptr;
> +            ptr += namelen;
> +        }
> +        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +        memcpy(&size_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);

Why not define a struct libxl__physmap_info for these three? You could
even do the trick with the "char name[]" at the end and incorporate
namelen too if you wanted.

The maximum size of the allocation is
	sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
here but in the save it is allocating:
	sizeof(count) + count * (sizeof(val) * 3 + sizeof(namelen));
these work out the same but it would be more obviously correct if it
were "count * sizeof(struct)"

Actually, hang on where is the space for name itself allocated? I see,
you are reallocing. If you have to do that anyway you may as well start
off with just sizeof(count) and realloc namelen + sizeof(struct) at each
stage.

> +
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
> +                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
> +        if (ret)
> +            return -1;
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +                    domid, phys_offset_v), "%"PRIx64, size_v);
> +        if (ret)
> +            return -1;
> +        if (namelen > 0) {
> +            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
> +                        domid, phys_offset_v), "%s", name);
> +            if (ret)
> +                return -1;
> +        }
> +    }
> +    return 0;
> +}
> +
>  int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
>                                   libxl_domain_build_info *info,
>                                   libxl__domain_build_state *state,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:43:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11: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 1RoCrx-0001Pi-06; Fri, 20 Jan 2012 11:42:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoCrw-0001PP-2Z
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:42:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327059770!7994080!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26537 invoked from network); 20 Jan 2012 11:42:50 -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;
	20 Jan 2012 11:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10175051"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:42:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 11:42:49 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 11:42:49 +0000
In-Reply-To: <1327058312-19168-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-2-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327059769.30054.12.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/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> Read Qemu's physmap from xenstore and save it using toolstack_save.
> Restore Qemu's physmap using toolstack_restore.

Shall we have a version field now so we don't dig ourselves a hole we
can't get out of?

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
>  1 files changed, 131 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index fd2b051..3d60a35 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -347,6 +347,62 @@ out:
>      return rc;
>  }
>  
> +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> +        uint32_t size, void *data)
> +{
> +    libxl__gc *gc = (libxl__gc *) data;
> +    int i, ret;
> +    uint8_t *ptr = buf;
> +    uint32_t namelen = 0;
> +    char *name = NULL;
> +    uint32_t count = 0;
> +    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
> +
> +    if (size < sizeof(count))
> +        return -1;
> +
> +    memcpy(&count, ptr, sizeof(count));
> +    ptr += sizeof(count);
> + 
> +    if (size <
> +            sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
> +        return -1;
> +
> +    for (i = 0; i < count; i++) {
> +        memcpy(&namelen, ptr, sizeof(namelen));
> +        ptr += sizeof(namelen);
> +        if (namelen > 0) {
> +            name = (char *)ptr;
> +            ptr += namelen;
> +        }
> +        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);
> +        memcpy(&size_v, ptr, sizeof(uint64_t));
> +        ptr += sizeof(uint64_t);

Why not define a struct libxl__physmap_info for these three? You could
even do the trick with the "char name[]" at the end and incorporate
namelen too if you wanted.

The maximum size of the allocation is
	sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
here but in the save it is allocating:
	sizeof(count) + count * (sizeof(val) * 3 + sizeof(namelen));
these work out the same but it would be more obviously correct if it
were "count * sizeof(struct)"

Actually, hang on where is the space for name itself allocated? I see,
you are reallocing. If you have to do that anyway you may as well start
off with just sizeof(count) and realloc namelen + sizeof(struct) at each
stage.

> +
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
> +                    domid, phys_offset_v), "%"PRIx64, start_addr_v);
> +        if (ret)
> +            return -1;
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +                    domid, phys_offset_v), "%"PRIx64, size_v);
> +        if (ret)
> +            return -1;
> +        if (namelen > 0) {
> +            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
> +                        domid, phys_offset_v), "%s", name);
> +            if (ret)
> +                return -1;
> +        }
> +    }
> +    return 0;
> +}
> +
>  int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
>                                   libxl_domain_build_info *info,
>                                   libxl__domain_build_state *state,



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:55:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoD3R-0001eJ-8k; Fri, 20 Jan 2012 11:54: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 1RoD3P-0001eB-MA
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:54:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327060481!5758772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21654 invoked from network); 20 Jan 2012 11:54:41 -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;
	20 Jan 2012 11:54:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10175292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:54: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;
	Fri, 20 Jan 2012 11:54:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 20 Jan 2012 11:54:40 +0000
In-Reply-To: <1327059874.2337.38.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327060480.30054.15.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 11:44 +0000, Dario Faggioli wrote:

> And I agree again, honouring explicit user requests is key point. I
> think the issue here is what should be dona, say by default, i.e., if
> the user doesn't say anything about CPU/memory allocation. My idea was
> to have Xen supporting a "NUMA-aware operational mode" where (and this
> will actually be the first step!) it does exactly what xend is doing
> right now --- that is, choosing a node and putting the new guest there,
> both memory and CPU-wise. However, having this logic in the hypervisor
> would allow Xen itself, for example, while investigating which node to
> use for a new guest, or during a sort of periodic load balancing or
> whatever, to change its mind and move a guest to a different node from
> where it was put in the first place, as well as a bunch of other things.
> I'm not sure the same can be done within the toolstack but I think I can
> say that if it can, it would be way more complex and probably less
> effective... Am I wrong?

This might be doable for HVM guests but for PV guests pretty much the
only way would be a kind of local migration which would need tool
support. For the PV case hybrid support would help (by introducing HAP
for PV guests). Not saying it's not worthwhile but might just be harder
than it sounds.

> Of course, even in such mode, if the user explicitly tells us what he
> wants, e.g., by means of cpupools, pinning, etc., we should still honour
> such request.

Do we get this right now?

> Then the question is whether or nod this mode would be the default, or
> would need to be explicitly requested (boot parameter or something), but
> that would become important only when we will have it up and
> running... :-)

Yeah, I think we can defer that decision ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:55:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:55:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoD3R-0001eJ-8k; Fri, 20 Jan 2012 11:54: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 1RoD3P-0001eB-MA
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:54:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327060481!5758772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21654 invoked from network); 20 Jan 2012 11:54:41 -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;
	20 Jan 2012 11:54:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10175292"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:54: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;
	Fri, 20 Jan 2012 11:54:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Date: Fri, 20 Jan 2012 11:54:40 +0000
In-Reply-To: <1327059874.2337.38.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327060480.30054.15.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 11:44 +0000, Dario Faggioli wrote:

> And I agree again, honouring explicit user requests is key point. I
> think the issue here is what should be dona, say by default, i.e., if
> the user doesn't say anything about CPU/memory allocation. My idea was
> to have Xen supporting a "NUMA-aware operational mode" where (and this
> will actually be the first step!) it does exactly what xend is doing
> right now --- that is, choosing a node and putting the new guest there,
> both memory and CPU-wise. However, having this logic in the hypervisor
> would allow Xen itself, for example, while investigating which node to
> use for a new guest, or during a sort of periodic load balancing or
> whatever, to change its mind and move a guest to a different node from
> where it was put in the first place, as well as a bunch of other things.
> I'm not sure the same can be done within the toolstack but I think I can
> say that if it can, it would be way more complex and probably less
> effective... Am I wrong?

This might be doable for HVM guests but for PV guests pretty much the
only way would be a kind of local migration which would need tool
support. For the PV case hybrid support would help (by introducing HAP
for PV guests). Not saying it's not worthwhile but might just be harder
than it sounds.

> Of course, even in such mode, if the user explicitly tells us what he
> wants, e.g., by means of cpupools, pinning, etc., we should still honour
> such request.

Do we get this right now?

> Then the question is whether or nod this mode would be the default, or
> would need to be explicitly requested (boot parameter or something), but
> that would become important only when we will have it up and
> running... :-)

Yeah, I think we can defer that decision ;-)

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 11:56:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoD4v-0001iN-Os; Fri, 20 Jan 2012 11:56: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 1RoD4t-0001i9-Sm
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:56:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327060573!11805104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26419 invoked from network); 20 Jan 2012 11:56:14 -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;
	20 Jan 2012 11:56:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10175331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:56:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 11:56:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 11:56:13 +0000
In-Reply-To: <1327052823.2337.5.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<20120120081529.GU12984@reaktio.net>
	<1327050108.17599.113.camel@zakaz.uk.xensource.com>
	<1327052823.2337.5.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327060573.30054.17.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 09:47 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 09:01 +0000, Ian Campbell wrote: 
> > > See this thread: 
> > > http://old-list-archives.xen.org/archives/html/xen-devel/2011-07/msg01423.html
> > > 
> > > where Stefano wrote:
> > > "I think we forgot about this feature but it is important and hopefully
> > > somebody will write a patch for it before 4.2 is out."
> > 
> > Is anyone looking into this?
> > 
> Hi,
> 
> Actually, I'll be investigating how we could gradually introduce some
> NUMA support in both the Xen scheduler and memory allocator!
> 
> I already have some ideas and I'm looking at the code to better
> understand it and find out what's the best strategy and from where it's
> better to start. I can give some more details, here or on separate
> thread, in a few days, if you're interested.
> 
> The only thing is that I'm not sure how far I'll be able to get before
> 4.2. I really think I'll have _something_ but maybe not a full-fledged
> NUMA-aware patchset! :-P

Sure, For 4.2 we should make sure that the toolstack does something
vaguely sensible.

> > Does cpupool-numa-split solve this same problem?
> > 
> I'm looking right into that, and indeed I think it does a lot in this
> direction. The idea was to try doing something similar in a sort of
> automatic fashion, so that everyone can benefit from at least some
> NUMA-awareness, even without having to bother with cpupools.
> 
> It that what you were asking?

Yes, 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 Jan 20 11:56:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 11:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoD4v-0001iN-Os; Fri, 20 Jan 2012 11:56: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 1RoD4t-0001i9-Sm
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 11:56:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327060573!11805104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26419 invoked from network); 20 Jan 2012 11:56:14 -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;
	20 Jan 2012 11:56:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10175331"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:56:13 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 11:56:13 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 11:56:13 +0000
In-Reply-To: <1327052823.2337.5.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<20120120081529.GU12984@reaktio.net>
	<1327050108.17599.113.camel@zakaz.uk.xensource.com>
	<1327052823.2337.5.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327060573.30054.17.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 09:47 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 09:01 +0000, Ian Campbell wrote: 
> > > See this thread: 
> > > http://old-list-archives.xen.org/archives/html/xen-devel/2011-07/msg01423.html
> > > 
> > > where Stefano wrote:
> > > "I think we forgot about this feature but it is important and hopefully
> > > somebody will write a patch for it before 4.2 is out."
> > 
> > Is anyone looking into this?
> > 
> Hi,
> 
> Actually, I'll be investigating how we could gradually introduce some
> NUMA support in both the Xen scheduler and memory allocator!
> 
> I already have some ideas and I'm looking at the code to better
> understand it and find out what's the best strategy and from where it's
> better to start. I can give some more details, here or on separate
> thread, in a few days, if you're interested.
> 
> The only thing is that I'm not sure how far I'll be able to get before
> 4.2. I really think I'll have _something_ but maybe not a full-fledged
> NUMA-aware patchset! :-P

Sure, For 4.2 we should make sure that the toolstack does something
vaguely sensible.

> > Does cpupool-numa-split solve this same problem?
> > 
> I'm looking right into that, and indeed I think it does a lot in this
> direction. The idea was to try doing something similar in a sort of
> automatic fashion, so that everyone can benefit from at least some
> NUMA-awareness, even without having to bother with cpupools.
> 
> It that what you were asking?

Yes, 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 Jan 20 12:04:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDCD-00025z-7C; Fri, 20 Jan 2012 12:03: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 1RoDCB-00025q-Sf
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:03:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327061025!11837329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17188 invoked from network); 20 Jan 2012 12:03:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:03:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10175587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:03: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, 20 Jan 2012 12:03:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 20 Jan 2012 12:03:45 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 00/12] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Defines a few stubs and disables some as yet unsupported core features.

Early on there's a couple of unrelated cleanups.

Patch against v5 posting (Stefano's arm-v5 branch) + David Vrables
zImage series.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:04:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDCD-00025z-7C; Fri, 20 Jan 2012 12:03: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 1RoDCB-00025q-Sf
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:03:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327061025!11837329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17188 invoked from network); 20 Jan 2012 12:03:46 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:03:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10175587"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:03: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, 20 Jan 2012 12:03:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Fri, 20 Jan 2012 12:03:45 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH 00/12] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Defines a few stubs and disables some as yet unsupported core features.

Early on there's a couple of unrelated cleanups.

Patch against v5 posting (Stefano's arm-v5 branch) + David Vrables
zImage series.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF7-0002Hc-7U; Fri, 20 Jan 2012 12:06: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 1RoDF4-0002F9-NY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 830 invoked from network); 20 Jan 2012 12:06:44 -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;
	20 Jan 2012 12:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105039"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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; Fri, 20 Jan 2012 07:06:44 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn4015488; Fri, 20 Jan 2012 04:06:43 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:31 +0000
Message-ID: <1327061198-29854-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/12] arm: Add stub functions instead of using
	DUMMY
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Adds stubs for arch domctl and sysctl plus vcpu_op and memory_op.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile |    3 +++
 xen/arch/arm/domain.c |    5 +++++
 xen/arch/arm/domctl.c |   27 +++++++++++++++++++++++++++
 xen/arch/arm/dummy.S  |    4 ----
 xen/arch/arm/mm.c     |    5 +++++
 xen/arch/arm/sysctl.c |   29 +++++++++++++++++++++++++++++
 6 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/domctl.c
 create mode 100644 xen/arch/arm/sysctl.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9bc2fc8..e6745f4 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,7 +2,10 @@ subdir-y += lib
 
 obj-y += dummy.o
 obj-y += entry.o
+obj-y += cache.o
 obj-y += domain.o
+obj-y += domctl.o
+obj-y += sysctl.o
 obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ada89af..5fe370b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -255,6 +255,11 @@ void arch_dump_domain_info(struct domain *d)
 {
 }
 
+long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+{
+    return -ENOSYS;
+}
+
 void arch_dump_vcpu_info(struct vcpu *v)
 {
 }
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
new file mode 100644
index 0000000..d957f21
--- /dev/null
+++ b/xen/arch/arm/domctl.c
@@ -0,0 +1,27 @@
+/******************************************************************************
+ * Arch-specific domctl.c
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/domctl.h>
+
+long arch_do_domctl(struct xen_domctl *domctl,
+                    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+{
+	return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index fff7d7e..1287e0b 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -8,12 +8,8 @@ x:	mov pc, lr
 	
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
-DUMMY(arch_do_domctl);
-DUMMY(arch_do_sysctl);
-DUMMY(arch_do_vcpu_op);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_get_xen_caps);
-DUMMY(arch_memory_op);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
 DUMMY(create_grant_host_mapping);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 613d084..45971cb 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -311,6 +311,11 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
 }
 
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+    return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
new file mode 100644
index 0000000..20a16f9
--- /dev/null
+++ b/xen/arch/arm/sysctl.c
@@ -0,0 +1,29 @@
+/******************************************************************************
+ * Arch-specific domctl.c
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/sysctl.h>
+
+long arch_do_sysctl(struct xen_sysctl *sysctl,
+		    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+{
+	return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF7-0002Hc-7U; Fri, 20 Jan 2012 12:06: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 1RoDF4-0002F9-NY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 830 invoked from network); 20 Jan 2012 12:06:44 -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;
	20 Jan 2012 12:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105039"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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; Fri, 20 Jan 2012 07:06:44 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn4015488; Fri, 20 Jan 2012 04:06:43 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:31 +0000
Message-ID: <1327061198-29854-5-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/12] arm: Add stub functions instead of using
	DUMMY
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Adds stubs for arch domctl and sysctl plus vcpu_op and memory_op.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/Makefile |    3 +++
 xen/arch/arm/domain.c |    5 +++++
 xen/arch/arm/domctl.c |   27 +++++++++++++++++++++++++++
 xen/arch/arm/dummy.S  |    4 ----
 xen/arch/arm/mm.c     |    5 +++++
 xen/arch/arm/sysctl.c |   29 +++++++++++++++++++++++++++++
 6 files changed, 69 insertions(+), 4 deletions(-)
 create mode 100644 xen/arch/arm/domctl.c
 create mode 100644 xen/arch/arm/sysctl.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9bc2fc8..e6745f4 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,7 +2,10 @@ subdir-y += lib
 
 obj-y += dummy.o
 obj-y += entry.o
+obj-y += cache.o
 obj-y += domain.o
+obj-y += domctl.o
+obj-y += sysctl.o
 obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index ada89af..5fe370b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -255,6 +255,11 @@ void arch_dump_domain_info(struct domain *d)
 {
 }
 
+long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE(void) arg)
+{
+    return -ENOSYS;
+}
+
 void arch_dump_vcpu_info(struct vcpu *v)
 {
 }
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
new file mode 100644
index 0000000..d957f21
--- /dev/null
+++ b/xen/arch/arm/domctl.c
@@ -0,0 +1,27 @@
+/******************************************************************************
+ * Arch-specific domctl.c
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/domctl.h>
+
+long arch_do_domctl(struct xen_domctl *domctl,
+                    XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
+{
+	return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index fff7d7e..1287e0b 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -8,12 +8,8 @@ x:	mov pc, lr
 	
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
-DUMMY(arch_do_domctl);
-DUMMY(arch_do_sysctl);
-DUMMY(arch_do_vcpu_op);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_get_xen_caps);
-DUMMY(arch_memory_op);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
 DUMMY(create_grant_host_mapping);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 613d084..45971cb 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -311,6 +311,11 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t pe)
     frametable_virt_end = FRAMETABLE_VIRT_START + (nr_pages * sizeof(struct page_info));
 }
 
+long arch_memory_op(int op, XEN_GUEST_HANDLE(void) arg)
+{
+    return -ENOSYS;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/sysctl.c b/xen/arch/arm/sysctl.c
new file mode 100644
index 0000000..20a16f9
--- /dev/null
+++ b/xen/arch/arm/sysctl.c
@@ -0,0 +1,29 @@
+/******************************************************************************
+ * Arch-specific domctl.c
+ *
+ * System management operations. For use by node control stack.
+ *
+ * Copyright (c) 2012, Citrix Systems
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <public/sysctl.h>
+
+long arch_do_sysctl(struct xen_sysctl *sysctl,
+		    XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
+{
+	return -ENOSYS;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF9-0002KT-PR; Fri, 20 Jan 2012 12:06: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 1RoDF8-0002Fn-Aw
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1038 invoked from network); 20 Jan 2012 12:06:48 -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;
	20 Jan 2012 12:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105041"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:47 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn8015488; Fri, 20 Jan 2012 04:06:46 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:35 +0000
Message-ID: <1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/12] xen: only map PV guest grants via iommu
	if HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/Rules.mk             |    1 +
 xen/arch/arm/dummy.S     |    2 --
 xen/common/grant_table.c |    6 ++++++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index e25e8d4..ce88316 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -52,6 +52,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
+CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 5010619..e858613 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
 DUMMY(gnttab_clear_flag);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
-DUMMY(iommu_map_page);
-DUMMY(iommu_unmap_page);
 DUMMY(is_iomem_page);
 DUMMY(max_page);
 DUMMY(node_online_map);
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index b024016..1798fcd 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -434,6 +434,7 @@ static int _set_status(unsigned gt_version,
         return _set_status_v2(domid, readonly, mapflag, shah, act, status);
 }
 
+#ifdef HAS_PASSTHROUGH
 static void mapcount(
     struct domain *ld, unsigned long mfn,
     unsigned int *wrc, unsigned int *rdc)
@@ -456,6 +457,7 @@ static void mapcount(
         rcu_unlock_domain(rd);
     }
 }
+#endif
 
 /*
  * Returns 0 if TLB flush / invalidate required by caller.
@@ -662,6 +664,7 @@ __gnttab_map_grant_ref(
         goto undo_out;
     }
 
+#ifdef HAS_PASSTHROUGH
     if ( !is_hvm_domain(ld) && need_iommu(ld) )
     {
         unsigned int wrc, rdc;
@@ -689,6 +692,7 @@ __gnttab_map_grant_ref(
             goto undo_out;
         }
     }
+#endif
 
     TRACE_1D(TRC_MEM_PAGE_GRANT_MAP, op->dom);
 
@@ -858,6 +862,7 @@ __gnttab_unmap_common(
             act->pin -= GNTPIN_hstw_inc;
     }
 
+#ifdef HAS_PASSTHROUGH
     if ( !is_hvm_domain(ld) && need_iommu(ld) )
     {
         unsigned int wrc, rdc;
@@ -874,6 +879,7 @@ __gnttab_unmap_common(
             goto unmap_out;
         }
     }
+#endif
 
     /* If just unmapped a writable mapping, mark as dirtied */
     if ( !(op->flags & GNTMAP_readonly) )
-- 
1.7.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 Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF9-0002KT-PR; Fri, 20 Jan 2012 12:06: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 1RoDF8-0002Fn-Aw
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1038 invoked from network); 20 Jan 2012 12:06:48 -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;
	20 Jan 2012 12:06:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105041"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:47 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn8015488; Fri, 20 Jan 2012 04:06:46 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:35 +0000
Message-ID: <1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 09/12] xen: only map PV guest grants via iommu
	if HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/Rules.mk             |    1 +
 xen/arch/arm/dummy.S     |    2 --
 xen/common/grant_table.c |    6 ++++++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index e25e8d4..ce88316 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -52,6 +52,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
+CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 5010619..e858613 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
 DUMMY(gnttab_clear_flag);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
-DUMMY(iommu_map_page);
-DUMMY(iommu_unmap_page);
 DUMMY(is_iomem_page);
 DUMMY(max_page);
 DUMMY(node_online_map);
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index b024016..1798fcd 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -434,6 +434,7 @@ static int _set_status(unsigned gt_version,
         return _set_status_v2(domid, readonly, mapflag, shah, act, status);
 }
 
+#ifdef HAS_PASSTHROUGH
 static void mapcount(
     struct domain *ld, unsigned long mfn,
     unsigned int *wrc, unsigned int *rdc)
@@ -456,6 +457,7 @@ static void mapcount(
         rcu_unlock_domain(rd);
     }
 }
+#endif
 
 /*
  * Returns 0 if TLB flush / invalidate required by caller.
@@ -662,6 +664,7 @@ __gnttab_map_grant_ref(
         goto undo_out;
     }
 
+#ifdef HAS_PASSTHROUGH
     if ( !is_hvm_domain(ld) && need_iommu(ld) )
     {
         unsigned int wrc, rdc;
@@ -689,6 +692,7 @@ __gnttab_map_grant_ref(
             goto undo_out;
         }
     }
+#endif
 
     TRACE_1D(TRC_MEM_PAGE_GRANT_MAP, op->dom);
 
@@ -858,6 +862,7 @@ __gnttab_unmap_common(
             act->pin -= GNTPIN_hstw_inc;
     }
 
+#ifdef HAS_PASSTHROUGH
     if ( !is_hvm_domain(ld) && need_iommu(ld) )
     {
         unsigned int wrc, rdc;
@@ -874,6 +879,7 @@ __gnttab_unmap_common(
             goto unmap_out;
         }
     }
+#endif
 
     /* If just unmapped a writable mapping, mark as dirtied */
     if ( !(op->flags & GNTMAP_readonly) )
-- 
1.7.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 Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF7-0002I8-KH; Fri, 20 Jan 2012 12:06:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoDF4-0002FA-Sn
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327061202!9983242!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13219 invoked from network); 20 Jan 2012 12:06:43 -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;
	20 Jan 2012 12:06:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403322"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:41 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn1015488; Fri, 20 Jan 2012 04:06:40 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:28 +0000
Message-ID: <1327061198-29854-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/12] arm: define some more cp15 registers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Complete the set of cache flush and add processor feature registers. Print the
latter on boot for debug.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c         |   17 +++++++++++++++++
 xen/include/asm-arm/cpregs.h |   18 ++++++++++++++++++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 51afb31..2433723 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -63,6 +63,20 @@ static void __init init_idle_domain(void)
         /* TODO: setup_idle_pagetable(); */
 }
 
+static void processor_id(void)
+{
+    printk("Processor Features: %08x %08x\n",
+           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
+    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
+    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
+    printk("Memory Model Features: %08x %08x %08x %08x\n",
+           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
+           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
+    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
+           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+}
+
 void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long arm_type,
                       unsigned long atag_paddr)
@@ -127,7 +141,10 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     WRITE_CP32(0x80002558, VTCR); isb();
 
+    processor_id();
+
     softirq_init();
+
     tasklet_subsys_init();
 
     init_IRQ();
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 3a4028d..d61ea88 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -93,6 +93,18 @@
 /* CP15 CR0: CPUID and Cache Type Registers */
 #define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
 #define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define ID_DFR0         p15,0,c0,c1,2   /* Debug Feature Register 0 */
+#define ID_AFR0         p15,0,c0,c1,3   /* Auxiliary Feature Register 0 */
+#define ID_MMFR0        p15,0,c0,c1,4   /* Memory Model Feature Register 0 */
+#define ID_MMFR1        p15,0,c0,c1,5   /* Memory Model Feature Register 1 */
+#define ID_MMFR2        p15,0,c0,c1,6   /* Memory Model Feature Register 2 */
+#define ID_MMFR3        p15,0,c0,c1,7   /* Memory Model Feature Register 3 */
+#define ID_ISAR0        p15,0,c0,c2,0   /* ISA Feature Register 0 */
+#define ID_ISAR1        p15,0,c0,c2,1   /* ISA Feature Register 1 */
+#define ID_ISAR2        p15,0,c0,c2,2   /* ISA Feature Register 2 */
+#define ID_ISAR3        p15,0,c0,c2,3   /* ISA Feature Register 3 */
+#define ID_ISAR4        p15,0,c0,c2,4   /* ISA Feature Register 4 */
+#define ID_ISAR5        p15,0,c0,c2,5   /* ISA Feature Register 5 */
 #define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
 #define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
 #define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
@@ -134,7 +146,11 @@
 #define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
 #define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
 #define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define ICIMVAU         p15,0,c7,c5,1   /* Invalidate instruction caches by MVA to PoU */
 #define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define BPIMVA          p15,0,c7,c5,7   /* Invalidate MVA from branch predictor array */
+#define DCIMVAC         p15,0,c7,c6,1   /* Invalidate data cache line by MVA to PoC */
+#define DCISW           p15,0,c7,c2,1   /* Invalidate data cache line by set/way */
 #define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
 #define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
 #define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
@@ -144,6 +160,8 @@
 #define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
 #define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
 #define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCSW           p15,0,c7,c10,2  /* Clean data cache line by set/way */
+#define DCCMVAU         p15,0,c7,c11,1  /* Clean data cache line by MVA to PoU */
 #define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
 #define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
 #define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF8-0002JH-D4; Fri, 20 Jan 2012 12:06: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 1RoDF6-0002FP-Hg
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 965 invoked from network); 20 Jan 2012 12:06:46 -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;
	20 Jan 2012 12:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105040"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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; Fri, 20 Jan 2012 07:06:45 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn6015488; Fri, 20 Jan 2012 04:06:44 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:33 +0000
Message-ID: <1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
	platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/Rules.mk               |    1 +
 xen/arch/arm/dummy.S       |    1 -
 xen/arch/ia64/Rules.mk     |    1 +
 xen/arch/x86/Rules.mk      |    1 +
 xen/common/Makefile        |    4 ++--
 xen/common/page_alloc.c    |    1 +
 xen/include/xen/tmem.h     |    9 +++++++++
 xen/include/xen/tmem_xen.h |    5 +++++
 8 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index b7b54f6..e25e8d4 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3bf5226..da0b906 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,7 +20,6 @@ DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
-DUMMY(donate_page);
 DUMMY(flush_tlb_mask);
 DUMMY(free_vcpu_guest_context);
 DUMMY(get_page);
diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
index 054b4de..6c8cf69 100644
--- a/xen/arch/ia64/Rules.mk
+++ b/xen/arch/ia64/Rules.mk
@@ -9,6 +9,7 @@ HAS_PCI := y
 HAS_PASSTHROUGH := y
 HAS_NS16550 := y
 HAS_KEXEC := y
+HAS_TMEM := y
 xenoprof := y
 no_warns ?= n
 vti_debug ?= n
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 1e48877..8802a69 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -8,6 +8,7 @@ HAS_PCI := y
 HAS_PASSTHROUGH := y
 HAS_NS16550 := y
 HAS_KEXEC := y
+HAS_TMEM := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9249845..68a2df1 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -38,8 +38,8 @@ obj-y += vsprintf.o
 obj-y += wait.o
 obj-y += xmalloc_tlsf.o
 obj-y += rcupdate.o
-obj-y += tmem.o
-obj-y += tmem_xen.o
+obj-$(HAS_TMEM) += tmem.o
+obj-$(HAS_TMEM) += tmem_xen.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += lzo.o
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 249bb35..3aac830 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -35,6 +35,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/errno.h>
 #include <xen/tmem.h>
 #include <xen/tmem_xen.h>
 #include <public/sysctl.h>
diff --git a/xen/include/xen/tmem.h b/xen/include/xen/tmem.h
index 5dbf9d5..2ebffb4 100644
--- a/xen/include/xen/tmem.h
+++ b/xen/include/xen/tmem.h
@@ -9,8 +9,17 @@
 #ifndef __XEN_TMEM_H__
 #define __XEN_TMEM_H__
 
+#ifdef HAS_TMEM
 extern void tmem_destroy(void *);
 extern void *tmem_relinquish_pages(unsigned int, unsigned int);
 extern unsigned long tmem_freeable_pages(void);
+#else
+static inline void tmem_destroy(void *v) {}
+static inline void *tmem_relinquish_pages(unsigned int order, unsigned int flags)
+{
+	return NULL;
+}
+static inline unsigned long tmem_freeable_pages(void) { return 0; }
+#endif
 
 #endif /* __XEN_TMEM_H__ */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index fdbeed1..a6c0672 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -9,6 +9,7 @@
 #ifndef __XEN_TMEM_XEN_H__
 #define __XEN_TMEM_XEN_H__
 
+#ifdef HAS_TMEM
 #include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
 #include <xen/pfn.h>
@@ -559,4 +560,8 @@ extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t
 #define RESET_CYC_COUNTER(x) do { } while (0)
 #endif
 
+#else /* HAS_TMEM */
+#define opt_tmem 0
+#endif
+
 #endif /* __XEN_TMEM_XEN_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 Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF8-0002Is-0T; Fri, 20 Jan 2012 12:06:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoDF5-0002FG-9O
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327061202!9983242!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13235 invoked from network); 20 Jan 2012 12:06:44 -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;
	20 Jan 2012 12:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403324"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:43 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn3015488; Fri, 20 Jan 2012 04:06:42 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:30 +0000
Message-ID: <1327061198-29854-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/12] arm: remove some unnecessary symbols from
	dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Correct the comment on the DUMMY macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 5bc4f21..fff7d7e 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -1,8 +1,6 @@
-/* Nothing is mapped at 1G, for the moment */
 #define DUMMY(x) \
 	.globl x; \
-x:	.word 0xe7f000f0
-/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+x:	.word 0xe7f000f0 /* Undefined instruction */
 
 #define  NOP(x) \
 	.globl x; \
@@ -35,15 +33,11 @@ DUMMY(get_page);
 DUMMY(get_page_type);
 DUMMY(gmfn_to_mfn);
 DUMMY(gnttab_clear_flag);
-DUMMY(gnttab_host_mapping_get_page_type);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
 DUMMY(iommu_map_page);
 DUMMY(iommu_unmap_page);
 DUMMY(is_iomem_page);
-DUMMY(local_event_delivery_enable);
-DUMMY(local_events_need_delivery);
-DUMMY(machine_to_phys_mapping_valid);
 DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF6-0002HN-Rx; Fri, 20 Jan 2012 12:06: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 1RoDF4-0002Fz-4Z
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327061153!53381942!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23243 invoked from network); 20 Jan 2012 12:05:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:05:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403333"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:48 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn9015488; Fri, 20 Jan 2012 04:06:47 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:36 +0000
Message-ID: <1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S      |    2 --
 xen/include/asm-arm/mm.h  |    8 ++++++--
 xen/include/asm-arm/p2m.h |   11 +++++++----
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index e858613..67edb35 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -31,8 +31,6 @@ DUMMY(is_iomem_page);
 DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
-DUMMY(p2m_pod_decrease_reservation);
-DUMMY(guest_physmap_mark_populate_on_demand);
 DUMMY(page_get_owner_and_reference);
 DUMMY(page_is_ram_type);
 DUMMY(per_cpu__cpu_core_mask);
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f721c54..ebe09cf 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -294,8 +294,12 @@ extern struct domain *dom_xen, *dom_io, *dom_cow;
 #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);
+/*
+ * int guest_physmap_mark_populate_on_demand(struct domain *d,
+ *                                           unsigned long gfn,
+ *                                           unsigned int order)
+ */
+#define guest_physmap_mark_populate_on_demand(d, gfn, order) -ENOSYS /* No PoD on ARM */
 
 extern void put_page_type(struct page_info *page);
 static inline void put_page_and_type(struct page_info *page)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index aec52f7..723518d 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -48,10 +48,13 @@ unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
 
 /* 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);
+ /* No PoD on ARM yet */
+/* int
+ * p2m_pod_decrease_reservation(struct domain *d,
+ *                              xen_pfn_t gpfn,
+ *                              unsigned int order);
+ */
+#define p2m_pod_decrease_reservation(d, gpfn, order) -ENOSYS
 
 /* Compatibility function exporting the old untyped interface */
 static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
-- 
1.7.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 Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF7-0002I8-KH; Fri, 20 Jan 2012 12:06:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoDF4-0002FA-Sn
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327061202!9983242!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13219 invoked from network); 20 Jan 2012 12:06:43 -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;
	20 Jan 2012 12:06:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403322"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:41 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn1015488; Fri, 20 Jan 2012 04:06:40 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:28 +0000
Message-ID: <1327061198-29854-2-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/12] arm: define some more cp15 registers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Complete the set of cache flush and add processor feature registers. Print the
latter on boot for debug.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/setup.c         |   17 +++++++++++++++++
 xen/include/asm-arm/cpregs.h |   18 ++++++++++++++++++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 51afb31..2433723 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -63,6 +63,20 @@ static void __init init_idle_domain(void)
         /* TODO: setup_idle_pagetable(); */
 }
 
+static void processor_id(void)
+{
+    printk("Processor Features: %08x %08x\n",
+           READ_CP32(ID_PFR0), READ_CP32(ID_PFR0));
+    printk("Debug Features: %08x\n", READ_CP32(ID_DFR0));
+    printk("Auxiliary Features: %08x\n", READ_CP32(ID_AFR0));
+    printk("Memory Model Features: %08x %08x %08x %08x\n",
+           READ_CP32(ID_MMFR0), READ_CP32(ID_MMFR1),
+           READ_CP32(ID_MMFR2), READ_CP32(ID_MMFR3));
+    printk("ISA Features: %08x %08x %08x %08x %08x %08x\n",
+           READ_CP32(ID_ISAR0), READ_CP32(ID_ISAR1), READ_CP32(ID_ISAR2),
+           READ_CP32(ID_ISAR3), READ_CP32(ID_ISAR4), READ_CP32(ID_ISAR5));
+}
+
 void __init start_xen(unsigned long boot_phys_offset,
                       unsigned long arm_type,
                       unsigned long atag_paddr)
@@ -127,7 +141,10 @@ void __init start_xen(unsigned long boot_phys_offset,
      */
     WRITE_CP32(0x80002558, VTCR); isb();
 
+    processor_id();
+
     softirq_init();
+
     tasklet_subsys_init();
 
     init_IRQ();
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 3a4028d..d61ea88 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -93,6 +93,18 @@
 /* CP15 CR0: CPUID and Cache Type Registers */
 #define ID_PFR0         p15,0,c0,c1,0   /* Processor Feature Register 0 */
 #define ID_PFR1         p15,0,c0,c1,1   /* Processor Feature Register 1 */
+#define ID_DFR0         p15,0,c0,c1,2   /* Debug Feature Register 0 */
+#define ID_AFR0         p15,0,c0,c1,3   /* Auxiliary Feature Register 0 */
+#define ID_MMFR0        p15,0,c0,c1,4   /* Memory Model Feature Register 0 */
+#define ID_MMFR1        p15,0,c0,c1,5   /* Memory Model Feature Register 1 */
+#define ID_MMFR2        p15,0,c0,c1,6   /* Memory Model Feature Register 2 */
+#define ID_MMFR3        p15,0,c0,c1,7   /* Memory Model Feature Register 3 */
+#define ID_ISAR0        p15,0,c0,c2,0   /* ISA Feature Register 0 */
+#define ID_ISAR1        p15,0,c0,c2,1   /* ISA Feature Register 1 */
+#define ID_ISAR2        p15,0,c0,c2,2   /* ISA Feature Register 2 */
+#define ID_ISAR3        p15,0,c0,c2,3   /* ISA Feature Register 3 */
+#define ID_ISAR4        p15,0,c0,c2,4   /* ISA Feature Register 4 */
+#define ID_ISAR5        p15,0,c0,c2,5   /* ISA Feature Register 5 */
 #define CCSIDR          p15,1,c0,c0,0   /* Cache Size ID Registers */
 #define CLIDR           p15,1,c0,c0,1   /* Cache Level ID Register */
 #define CSSELR          p15,2,c0,c0,0   /* Cache Size Selection Register */
@@ -134,7 +146,11 @@
 #define ICIALLUIS       p15,0,c7,c1,0   /* Invalidate all instruction caches to PoU inner shareable */
 #define BPIALLIS        p15,0,c7,c1,6   /* Invalidate entire branch predictor array inner shareable */
 #define ICIALLU         p15,0,c7,c5,0   /* Invalidate all instruction caches to PoU */
+#define ICIMVAU         p15,0,c7,c5,1   /* Invalidate instruction caches by MVA to PoU */
 #define BPIALL          p15,0,c7,c5,6   /* Invalidate entire branch predictor array */
+#define BPIMVA          p15,0,c7,c5,7   /* Invalidate MVA from branch predictor array */
+#define DCIMVAC         p15,0,c7,c6,1   /* Invalidate data cache line by MVA to PoC */
+#define DCISW           p15,0,c7,c2,1   /* Invalidate data cache line by set/way */
 #define ATS1CPR         p15,0,c7,c8,0   /* Address Translation Stage 1. Non-Secure Kernel Read */
 #define ATS1CPW         p15,0,c7,c8,1   /* Address Translation Stage 1. Non-Secure Kernel Write */
 #define ATS1CUR         p15,0,c7,c8,2   /* Address Translation Stage 1. Non-Secure User Read */
@@ -144,6 +160,8 @@
 #define ATS12NSOUR      p15,0,c7,c8,6   /* Address Translation Stage 1+2 Non-Secure User Read */
 #define ATS12NSOUW      p15,0,c7,c8,7   /* Address Translation Stage 1+2 Non-Secure User Write */
 #define DCCMVAC         p15,0,c7,c10,1  /* Clean data or unified cache line by MVA to PoC */
+#define DCCSW           p15,0,c7,c10,2  /* Clean data cache line by set/way */
+#define DCCMVAU         p15,0,c7,c11,1  /* Clean data cache line by MVA to PoU */
 #define DCCISW          p15,0,c7,c14,2  /* Clean and invalidate data cache line by set/way */
 #define ATS1HR          p15,4,c7,c8,0   /* Address Translation Stage 1 Hyp. Read */
 #define ATS1HW          p15,4,c7,c8,1   /* Address Translation Stage 1 Hyp. Write */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF4-0002GD-Pc; Fri, 20 Jan 2012 12:06:50 +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 1RoDF2-0002F5-Eq
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 704 invoked from network); 20 Jan 2012 12:06:42 -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;
	20 Jan 2012 12:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105037"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:40 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn0015488; Fri, 20 Jan 2012 04:06:39 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:27 +0000
Message-ID: <1327061198-29854-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/12] arm: add a missing local-vars comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/kernel.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index d4ffa4f..a1bcdbf 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -190,3 +190,12 @@ void kernel_load(struct kernel_info *info)
 {
     info->load(info);
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF8-0002JH-D4; Fri, 20 Jan 2012 12:06: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 1RoDF6-0002FP-Hg
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 965 invoked from network); 20 Jan 2012 12:06:46 -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;
	20 Jan 2012 12:06:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105040"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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; Fri, 20 Jan 2012 07:06:45 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn6015488; Fri, 20 Jan 2012 04:06:44 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:33 +0000
Message-ID: <1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
	platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/Rules.mk               |    1 +
 xen/arch/arm/dummy.S       |    1 -
 xen/arch/ia64/Rules.mk     |    1 +
 xen/arch/x86/Rules.mk      |    1 +
 xen/common/Makefile        |    4 ++--
 xen/common/page_alloc.c    |    1 +
 xen/include/xen/tmem.h     |    9 +++++++++
 xen/include/xen/tmem_xen.h |    5 +++++
 8 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index b7b54f6..e25e8d4 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
+CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 3bf5226..da0b906 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -20,7 +20,6 @@ DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
-DUMMY(donate_page);
 DUMMY(flush_tlb_mask);
 DUMMY(free_vcpu_guest_context);
 DUMMY(get_page);
diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
index 054b4de..6c8cf69 100644
--- a/xen/arch/ia64/Rules.mk
+++ b/xen/arch/ia64/Rules.mk
@@ -9,6 +9,7 @@ HAS_PCI := y
 HAS_PASSTHROUGH := y
 HAS_NS16550 := y
 HAS_KEXEC := y
+HAS_TMEM := y
 xenoprof := y
 no_warns ?= n
 vti_debug ?= n
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 1e48877..8802a69 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -8,6 +8,7 @@ HAS_PCI := y
 HAS_PASSTHROUGH := y
 HAS_NS16550 := y
 HAS_KEXEC := y
+HAS_TMEM := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 9249845..68a2df1 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -38,8 +38,8 @@ obj-y += vsprintf.o
 obj-y += wait.o
 obj-y += xmalloc_tlsf.o
 obj-y += rcupdate.o
-obj-y += tmem.o
-obj-y += tmem_xen.o
+obj-$(HAS_TMEM) += tmem.o
+obj-$(HAS_TMEM) += tmem_xen.o
 obj-y += radix-tree.o
 obj-y += rbtree.o
 obj-y += lzo.o
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 249bb35..3aac830 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -35,6 +35,7 @@
 #include <xen/perfc.h>
 #include <xen/numa.h>
 #include <xen/nodemask.h>
+#include <xen/errno.h>
 #include <xen/tmem.h>
 #include <xen/tmem_xen.h>
 #include <public/sysctl.h>
diff --git a/xen/include/xen/tmem.h b/xen/include/xen/tmem.h
index 5dbf9d5..2ebffb4 100644
--- a/xen/include/xen/tmem.h
+++ b/xen/include/xen/tmem.h
@@ -9,8 +9,17 @@
 #ifndef __XEN_TMEM_H__
 #define __XEN_TMEM_H__
 
+#ifdef HAS_TMEM
 extern void tmem_destroy(void *);
 extern void *tmem_relinquish_pages(unsigned int, unsigned int);
 extern unsigned long tmem_freeable_pages(void);
+#else
+static inline void tmem_destroy(void *v) {}
+static inline void *tmem_relinquish_pages(unsigned int order, unsigned int flags)
+{
+	return NULL;
+}
+static inline unsigned long tmem_freeable_pages(void) { return 0; }
+#endif
 
 #endif /* __XEN_TMEM_H__ */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index fdbeed1..a6c0672 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -9,6 +9,7 @@
 #ifndef __XEN_TMEM_XEN_H__
 #define __XEN_TMEM_XEN_H__
 
+#ifdef HAS_TMEM
 #include <xen/config.h>
 #include <xen/mm.h> /* heap alloc/free */
 #include <xen/pfn.h>
@@ -559,4 +560,8 @@ extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t
 #define RESET_CYC_COUNTER(x) do { } while (0)
 #endif
 
+#else /* HAS_TMEM */
+#define opt_tmem 0
+#endif
+
 #endif /* __XEN_TMEM_XEN_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 Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDFA-0002Kr-70; Fri, 20 Jan 2012 12:06: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 1RoDF8-0002Ga-PE
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327061153!53381942!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23426 invoked from network); 20 Jan 2012 12:05:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:05:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403334"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:50 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dnB015488; Fri, 20 Jan 2012 04:06:49 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:38 +0000
Message-ID: <1327061198-29854-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/12] arm: Group remaining dummy symbols
	somewhat according to functionality
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Makes it easier to see what needs to be done.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |   71 +++++++++++++++++++++++++++++--------------------
 1 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 295938e..1bf13a3 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -5,49 +5,62 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 #define  NOP(x) \
 	.globl x; \
 x:	mov pc, lr
-	
+
+/* SMP support */
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(node_online_map);
+DUMMY(smp_send_state_dump);
+DUMMY(__per_cpu_offset);
+
+/* PIRQ support */
 DUMMY(alloc_pirq_struct);
+DUMMY(nr_irqs_gsi);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+
+/* VCPU */
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
+DUMMY(free_vcpu_guest_context);
+DUMMY(sync_vcpu_execstate);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+
+/* Page Reference & Type Maintenance */
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(page_get_owner_and_reference);
+DUMMY(put_page);
+DUMMY(put_page_type);
+
+/* Grant Tables */
 DUMMY(create_grant_host_mapping);
-DUMMY(__cpu_die);
-DUMMY(__cpu_disable);
-DUMMY(__cpu_up);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_mark_dirty);
+DUMMY(is_iomem_page);
+DUMMY(replace_grant_host_mapping);
+DUMMY(steal_page);
+
+/* Page Offlining */
+DUMMY(page_is_ram_type);
+
+/* Other */
 DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
 DUMMY(flush_tlb_mask);
-DUMMY(free_vcpu_guest_context);
-DUMMY(get_page);
-DUMMY(get_page_type);
 DUMMY(gmfn_to_mfn);
-DUMMY(gnttab_clear_flag);
-DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
-DUMMY(is_iomem_page);
-DUMMY(node_online_map);
-DUMMY(nr_irqs_gsi);
-DUMMY(page_get_owner_and_reference);
-DUMMY(page_is_ram_type);
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
-DUMMY(__per_cpu_offset);
-DUMMY(pirq_guest_bind);
-DUMMY(pirq_guest_unbind);
-DUMMY(pirq_set_affinity);
-DUMMY(put_page);
-DUMMY(put_page_type);
-DUMMY(replace_grant_host_mapping);
 DUMMY(send_timer_event);
 DUMMY(share_xen_page_with_privileged_guests);
-DUMMY(smp_send_state_dump);
-DUMMY(steal_page);
-DUMMY(sync_vcpu_execstate);
 DUMMY(__udelay);
-NOP(update_vcpu_system_time);
-DUMMY(vcpu_mark_events_pending);
-DUMMY(vcpu_show_execution_state);
 DUMMY(wallclock_time);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF4-0002GD-Pc; Fri, 20 Jan 2012 12:06:50 +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 1RoDF2-0002F5-Eq
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 704 invoked from network); 20 Jan 2012 12:06:42 -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;
	20 Jan 2012 12:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105037"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:40 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn0015488; Fri, 20 Jan 2012 04:06:39 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:27 +0000
Message-ID: <1327061198-29854-1-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/12] arm: add a missing local-vars comment
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/kernel.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index d4ffa4f..a1bcdbf 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -190,3 +190,12 @@ void kernel_load(struct kernel_info *info)
 {
     info->load(info);
 }
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF8-0002Is-0T; Fri, 20 Jan 2012 12:06:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoDF5-0002FG-9O
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327061202!9983242!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13235 invoked from network); 20 Jan 2012 12:06:44 -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;
	20 Jan 2012 12:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403324"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:43 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn3015488; Fri, 20 Jan 2012 04:06:42 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:30 +0000
Message-ID: <1327061198-29854-4-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/12] arm: remove some unnecessary symbols from
	dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Correct the comment on the DUMMY macro.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    8 +-------
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 5bc4f21..fff7d7e 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -1,8 +1,6 @@
-/* Nothing is mapped at 1G, for the moment */
 #define DUMMY(x) \
 	.globl x; \
-x:	.word 0xe7f000f0
-/* x:	mov r0, #0x40000000 ; str r0, [r0]; b x */
+x:	.word 0xe7f000f0 /* Undefined instruction */
 
 #define  NOP(x) \
 	.globl x; \
@@ -35,15 +33,11 @@ DUMMY(get_page);
 DUMMY(get_page_type);
 DUMMY(gmfn_to_mfn);
 DUMMY(gnttab_clear_flag);
-DUMMY(gnttab_host_mapping_get_page_type);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
 DUMMY(iommu_map_page);
 DUMMY(iommu_unmap_page);
 DUMMY(is_iomem_page);
-DUMMY(local_event_delivery_enable);
-DUMMY(local_events_need_delivery);
-DUMMY(machine_to_phys_mapping_valid);
 DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF3-0002Ft-Bm; Fri, 20 Jan 2012 12:06: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 1RoDF1-0002FS-NY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327061153!53381942!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23064 invoked from network); 20 Jan 2012 12:05:54 -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;
	20 Jan 2012 12:05:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403326"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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; Fri, 20 Jan 2012 07:06:44 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn5015488; Fri, 20 Jan 2012 04:06:44 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:32 +0000
Message-ID: <1327061198-29854-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/12] PM: only include XEN_SYSCTL_{get_pmstat,
	pm_op} if HAVE_ACPI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These hypercalls are currently ACPI specific and implemented in
xen/drivers/acpi which is not implemented on ARM.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/Rules.mk         |    1 +
 xen/arch/arm/dummy.S |    2 --
 xen/common/sysctl.c  |    2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 59c7dd7..b7b54f6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -50,6 +50,7 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
+CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 1287e0b..3bf5226 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -16,13 +16,11 @@ DUMMY(create_grant_host_mapping);
 DUMMY(__cpu_die);
 DUMMY(__cpu_disable);
 DUMMY(__cpu_up);
-DUMMY(do_get_pm_info);
 DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
 DUMMY(donate_page);
-DUMMY(do_pm_op);
 DUMMY(flush_tlb_mask);
 DUMMY(free_vcpu_guest_context);
 DUMMY(get_page);
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index f8f7cf8..fef0589 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -224,6 +224,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     }
     break;
 
+#ifdef HAS_ACPI
     case XEN_SYSCTL_get_pmstat:
     {
         ret = xsm_get_pmstat();
@@ -259,6 +260,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
         }
     }
     break;
+#endif
 
     case XEN_SYSCTL_page_offline_op:
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF6-0002HN-Rx; Fri, 20 Jan 2012 12:06: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 1RoDF4-0002Fz-4Z
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327061153!53381942!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23243 invoked from network); 20 Jan 2012 12:05:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:05:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403333"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:48 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn9015488; Fri, 20 Jan 2012 04:06:47 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:36 +0000
Message-ID: <1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S      |    2 --
 xen/include/asm-arm/mm.h  |    8 ++++++--
 xen/include/asm-arm/p2m.h |   11 +++++++----
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index e858613..67edb35 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -31,8 +31,6 @@ DUMMY(is_iomem_page);
 DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
-DUMMY(p2m_pod_decrease_reservation);
-DUMMY(guest_physmap_mark_populate_on_demand);
 DUMMY(page_get_owner_and_reference);
 DUMMY(page_is_ram_type);
 DUMMY(per_cpu__cpu_core_mask);
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index f721c54..ebe09cf 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -294,8 +294,12 @@ extern struct domain *dom_xen, *dom_io, *dom_cow;
 #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);
+/*
+ * int guest_physmap_mark_populate_on_demand(struct domain *d,
+ *                                           unsigned long gfn,
+ *                                           unsigned int order)
+ */
+#define guest_physmap_mark_populate_on_demand(d, gfn, order) -ENOSYS /* No PoD on ARM */
 
 extern void put_page_type(struct page_info *page);
 static inline void put_page_and_type(struct page_info *page)
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index aec52f7..723518d 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -48,10 +48,13 @@ unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
 
 /* 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);
+ /* No PoD on ARM yet */
+/* int
+ * p2m_pod_decrease_reservation(struct domain *d,
+ *                              xen_pfn_t gpfn,
+ *                              unsigned int order);
+ */
+#define p2m_pod_decrease_reservation(d, gpfn, order) -ENOSYS
 
 /* Compatibility function exporting the old untyped interface */
 static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
-- 
1.7.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 Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF5-0002Gm-Ma; Fri, 20 Jan 2012 12:06: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 1RoDF3-0002F7-2P
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 736 invoked from network); 20 Jan 2012 12:06:42 -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;
	20 Jan 2012 12:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105038"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:42 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn2015488; Fri, 20 Jan 2012 04:06:41 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:29 +0000
Message-ID: <1327061198-29854-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/12] arm: align some register bit definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Probably got de-hard-tabbed at some point.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/processor.h |   80 +++++++++++++++++++-------------------
 1 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1f85d31..ec6fb48 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -17,12 +17,12 @@
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
-#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
-#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
-#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
-#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+#define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_N_MASK 0x07
@@ -35,56 +35,56 @@
 /* SCTLR System Control Register. */
 /* HSCTLR is a subset of this. */
 #define SCTLR_TE        (1<<30)
-#define SCTLR_AFE        (1<<29)
-#define SCTLR_TRE        (1<<28)
-#define SCTLR_NMFI        (1<<27)
+#define SCTLR_AFE       (1<<29)
+#define SCTLR_TRE       (1<<28)
+#define SCTLR_NMFI      (1<<27)
 #define SCTLR_EE        (1<<25)
 #define SCTLR_VE        (1<<24)
-#define SCTLR_U                (1<<22)
+#define SCTLR_U         (1<<22)
 #define SCTLR_FI        (1<<21)
-#define SCTLR_WXN        (1<<19)
+#define SCTLR_WXN       (1<<19)
 #define SCTLR_HA        (1<<17)
 #define SCTLR_RR        (1<<14)
-#define SCTLR_V                (1<<13)
-#define SCTLR_I                (1<<12)
-#define SCTLR_Z                (1<<11)
+#define SCTLR_V         (1<<13)
+#define SCTLR_I         (1<<12)
+#define SCTLR_Z         (1<<11)
 #define SCTLR_SW        (1<<10)
-#define SCTLR_B                (1<<7)
-#define SCTLR_C                (1<<2)
-#define SCTLR_A                (1<<1)
-#define SCTLR_M                (1<<0)
+#define SCTLR_B         (1<<7)
+#define SCTLR_C         (1<<2)
+#define SCTLR_A         (1<<1)
+#define SCTLR_M         (1<<0)
 
 #define SCTLR_BASE        0x00c50078
-#define HSCTLR_BASE        0x30c51878
+#define HSCTLR_BASE       0x30c51878
 
 /* HCR Hyp Configuration Register */
-#define HCR_TGE                (1<<27)
-#define HCR_TVM                (1<<26)
+#define HCR_TGE         (1<<27)
+#define HCR_TVM         (1<<26)
 #define HCR_TTLB        (1<<25)
-#define HCR_TPU                (1<<24)
-#define HCR_TPC                (1<<23)
-#define HCR_TSW                (1<<22)
-#define HCR_TAC                (1<<21)
-#define HCR_TIDCP        (1<<20)
-#define HCR_TSC                (1<<19)
+#define HCR_TPU         (1<<24)
+#define HCR_TPC         (1<<23)
+#define HCR_TSW         (1<<22)
+#define HCR_TAC         (1<<21)
+#define HCR_TIDCP       (1<<20)
+#define HCR_TSC         (1<<19)
 #define HCR_TID3        (1<<18)
 #define HCR_TID2        (1<<17)
 #define HCR_TID1        (1<<16)
 #define HCR_TID0        (1<<15)
-#define HCR_TWE                (1<<14)
-#define HCR_TWI                (1<<13)
-#define HCR_DC                (1<<12)
-#define HCR_BSU_MASK        (3<<10)
-#define HCR_FB                (1<<9)
-#define HCR_VA                (1<<8)
-#define HCR_VI                (1<<7)
-#define HCR_VF                (1<<6)
-#define HCR_AMO                (1<<5)
-#define HCR_IMO                (1<<4)
-#define HCR_FMO                (1<<3)
-#define HCR_PTW                (1<<2)
+#define HCR_TWE         (1<<14)
+#define HCR_TWI         (1<<13)
+#define HCR_DC          (1<<12)
+#define HCR_BSU_MASK    (3<<10)
+#define HCR_FB          (1<<9)
+#define HCR_VA          (1<<8)
+#define HCR_VI          (1<<7)
+#define HCR_VF          (1<<6)
+#define HCR_AMO         (1<<5)
+#define HCR_IMO         (1<<4)
+#define HCR_FMO         (1<<3)
+#define HCR_PTW         (1<<2)
 #define HCR_SWIO        (1<<1)
-#define HCR_VM                (1<<0)
+#define HCR_VM          (1<<0)
 
 #define HSR_EC_WFI_WFE              0x01
 #define HSR_EC_CP15_32              0x03
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDFA-0002Kr-70; Fri, 20 Jan 2012 12:06: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 1RoDF8-0002Ga-PE
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327061153!53381942!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23426 invoked from network); 20 Jan 2012 12:05:58 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:05:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403334"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:50 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dnB015488; Fri, 20 Jan 2012 04:06:49 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:38 +0000
Message-ID: <1327061198-29854-12-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 12/12] arm: Group remaining dummy symbols
	somewhat according to functionality
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Makes it easier to see what needs to be done.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |   71 +++++++++++++++++++++++++++++--------------------
 1 files changed, 42 insertions(+), 29 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 295938e..1bf13a3 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -5,49 +5,62 @@ x:	.word 0xe7f000f0 /* Undefined instruction */
 #define  NOP(x) \
 	.globl x; \
 x:	mov pc, lr
-	
+
+/* SMP support */
+DUMMY(__cpu_die);
+DUMMY(__cpu_disable);
+DUMMY(__cpu_up);
+DUMMY(per_cpu__cpu_core_mask);
+DUMMY(per_cpu__cpu_sibling_mask);
+DUMMY(node_online_map);
+DUMMY(smp_send_state_dump);
+DUMMY(__per_cpu_offset);
+
+/* PIRQ support */
 DUMMY(alloc_pirq_struct);
+DUMMY(nr_irqs_gsi);
+DUMMY(pirq_guest_bind);
+DUMMY(pirq_guest_unbind);
+DUMMY(pirq_set_affinity);
+
+/* VCPU */
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
+DUMMY(free_vcpu_guest_context);
+DUMMY(sync_vcpu_execstate);
+NOP(update_vcpu_system_time);
+DUMMY(vcpu_mark_events_pending);
+DUMMY(vcpu_show_execution_state);
+
+/* Page Reference & Type Maintenance */
+DUMMY(get_page);
+DUMMY(get_page_type);
+DUMMY(page_get_owner_and_reference);
+DUMMY(put_page);
+DUMMY(put_page_type);
+
+/* Grant Tables */
 DUMMY(create_grant_host_mapping);
-DUMMY(__cpu_die);
-DUMMY(__cpu_disable);
-DUMMY(__cpu_up);
+DUMMY(gnttab_clear_flag);
+DUMMY(gnttab_mark_dirty);
+DUMMY(is_iomem_page);
+DUMMY(replace_grant_host_mapping);
+DUMMY(steal_page);
+
+/* Page Offlining */
+DUMMY(page_is_ram_type);
+
+/* Other */
 DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
 DUMMY(flush_tlb_mask);
-DUMMY(free_vcpu_guest_context);
-DUMMY(get_page);
-DUMMY(get_page_type);
 DUMMY(gmfn_to_mfn);
-DUMMY(gnttab_clear_flag);
-DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
-DUMMY(is_iomem_page);
-DUMMY(node_online_map);
-DUMMY(nr_irqs_gsi);
-DUMMY(page_get_owner_and_reference);
-DUMMY(page_is_ram_type);
-DUMMY(per_cpu__cpu_core_mask);
-DUMMY(per_cpu__cpu_sibling_mask);
-DUMMY(__per_cpu_offset);
-DUMMY(pirq_guest_bind);
-DUMMY(pirq_guest_unbind);
-DUMMY(pirq_set_affinity);
-DUMMY(put_page);
-DUMMY(put_page_type);
-DUMMY(replace_grant_host_mapping);
 DUMMY(send_timer_event);
 DUMMY(share_xen_page_with_privileged_guests);
-DUMMY(smp_send_state_dump);
-DUMMY(steal_page);
-DUMMY(sync_vcpu_execstate);
 DUMMY(__udelay);
-NOP(update_vcpu_system_time);
-DUMMY(vcpu_mark_events_pending);
-DUMMY(vcpu_show_execution_state);
 DUMMY(wallclock_time);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF5-0002Gm-Ma; Fri, 20 Jan 2012 12:06: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 1RoDF3-0002F7-2P
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 736 invoked from network); 20 Jan 2012 12:06:42 -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;
	20 Jan 2012 12:06:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105038"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:42 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn2015488; Fri, 20 Jan 2012 04:06:41 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:29 +0000
Message-ID: <1327061198-29854-3-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 03/12] arm: align some register bit definitions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Probably got de-hard-tabbed at some point.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/asm-arm/processor.h |   80 +++++++++++++++++++-------------------
 1 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 1f85d31..ec6fb48 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -17,12 +17,12 @@
 #define PSR_MODE_UND 0x1b
 #define PSR_MODE_SYS 0x1f
 
-#define PSR_THUMB        (1<<5)        /* Thumb Mode enable */
-#define PSR_FIQ_MASK        (1<<6)        /* Fast Interrupt mask */
-#define PSR_IRQ_MASK        (1<<7)        /* Interrupt mask */
-#define PSR_ABT_MASK         (1<<8)        /* Asynchronous Abort mask */
-#define PSR_BIG_ENDIAN        (1<<9)        /* Big Endian Mode */
-#define PSR_JAZELLE        (1<<24)        /* Jazelle Mode */
+#define PSR_THUMB       (1<<5)        /* Thumb Mode enable */
+#define PSR_FIQ_MASK    (1<<6)        /* Fast Interrupt mask */
+#define PSR_IRQ_MASK    (1<<7)        /* Interrupt mask */
+#define PSR_ABT_MASK    (1<<8)        /* Asynchronous Abort mask */
+#define PSR_BIG_ENDIAN  (1<<9)        /* Big Endian Mode */
+#define PSR_JAZELLE     (1<<24)       /* Jazelle Mode */
 
 /* TTBCR Translation Table Base Control Register */
 #define TTBCR_N_MASK 0x07
@@ -35,56 +35,56 @@
 /* SCTLR System Control Register. */
 /* HSCTLR is a subset of this. */
 #define SCTLR_TE        (1<<30)
-#define SCTLR_AFE        (1<<29)
-#define SCTLR_TRE        (1<<28)
-#define SCTLR_NMFI        (1<<27)
+#define SCTLR_AFE       (1<<29)
+#define SCTLR_TRE       (1<<28)
+#define SCTLR_NMFI      (1<<27)
 #define SCTLR_EE        (1<<25)
 #define SCTLR_VE        (1<<24)
-#define SCTLR_U                (1<<22)
+#define SCTLR_U         (1<<22)
 #define SCTLR_FI        (1<<21)
-#define SCTLR_WXN        (1<<19)
+#define SCTLR_WXN       (1<<19)
 #define SCTLR_HA        (1<<17)
 #define SCTLR_RR        (1<<14)
-#define SCTLR_V                (1<<13)
-#define SCTLR_I                (1<<12)
-#define SCTLR_Z                (1<<11)
+#define SCTLR_V         (1<<13)
+#define SCTLR_I         (1<<12)
+#define SCTLR_Z         (1<<11)
 #define SCTLR_SW        (1<<10)
-#define SCTLR_B                (1<<7)
-#define SCTLR_C                (1<<2)
-#define SCTLR_A                (1<<1)
-#define SCTLR_M                (1<<0)
+#define SCTLR_B         (1<<7)
+#define SCTLR_C         (1<<2)
+#define SCTLR_A         (1<<1)
+#define SCTLR_M         (1<<0)
 
 #define SCTLR_BASE        0x00c50078
-#define HSCTLR_BASE        0x30c51878
+#define HSCTLR_BASE       0x30c51878
 
 /* HCR Hyp Configuration Register */
-#define HCR_TGE                (1<<27)
-#define HCR_TVM                (1<<26)
+#define HCR_TGE         (1<<27)
+#define HCR_TVM         (1<<26)
 #define HCR_TTLB        (1<<25)
-#define HCR_TPU                (1<<24)
-#define HCR_TPC                (1<<23)
-#define HCR_TSW                (1<<22)
-#define HCR_TAC                (1<<21)
-#define HCR_TIDCP        (1<<20)
-#define HCR_TSC                (1<<19)
+#define HCR_TPU         (1<<24)
+#define HCR_TPC         (1<<23)
+#define HCR_TSW         (1<<22)
+#define HCR_TAC         (1<<21)
+#define HCR_TIDCP       (1<<20)
+#define HCR_TSC         (1<<19)
 #define HCR_TID3        (1<<18)
 #define HCR_TID2        (1<<17)
 #define HCR_TID1        (1<<16)
 #define HCR_TID0        (1<<15)
-#define HCR_TWE                (1<<14)
-#define HCR_TWI                (1<<13)
-#define HCR_DC                (1<<12)
-#define HCR_BSU_MASK        (3<<10)
-#define HCR_FB                (1<<9)
-#define HCR_VA                (1<<8)
-#define HCR_VI                (1<<7)
-#define HCR_VF                (1<<6)
-#define HCR_AMO                (1<<5)
-#define HCR_IMO                (1<<4)
-#define HCR_FMO                (1<<3)
-#define HCR_PTW                (1<<2)
+#define HCR_TWE         (1<<14)
+#define HCR_TWI         (1<<13)
+#define HCR_DC          (1<<12)
+#define HCR_BSU_MASK    (3<<10)
+#define HCR_FB          (1<<9)
+#define HCR_VA          (1<<8)
+#define HCR_VI          (1<<7)
+#define HCR_VF          (1<<6)
+#define HCR_AMO         (1<<5)
+#define HCR_IMO         (1<<4)
+#define HCR_FMO         (1<<3)
+#define HCR_PTW         (1<<2)
 #define HCR_SWIO        (1<<1)
-#define HCR_VM                (1<<0)
+#define HCR_VM          (1<<0)
 
 #define HSR_EC_WFI_WFE              0x01
 #define HSR_EC_CP15_32              0x03
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF3-0002Ft-Bm; Fri, 20 Jan 2012 12:06: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 1RoDF1-0002FS-NY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327061153!53381942!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23064 invoked from network); 20 Jan 2012 12:05:54 -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;
	20 Jan 2012 12:05:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403326"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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; Fri, 20 Jan 2012 07:06:44 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn5015488; Fri, 20 Jan 2012 04:06:44 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:32 +0000
Message-ID: <1327061198-29854-6-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 06/12] PM: only include XEN_SYSCTL_{get_pmstat,
	pm_op} if HAVE_ACPI
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

These hypercalls are currently ACPI specific and implemented in
xen/drivers/acpi which is not implemented on ARM.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/Rules.mk         |    1 +
 xen/arch/arm/dummy.S |    2 --
 xen/common/sysctl.c  |    2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 59c7dd7..b7b54f6 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -50,6 +50,7 @@ CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc)         += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
+CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
 CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
 
 ifneq ($(max_phys_cpus),)
diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 1287e0b..3bf5226 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -16,13 +16,11 @@ DUMMY(create_grant_host_mapping);
 DUMMY(__cpu_die);
 DUMMY(__cpu_disable);
 DUMMY(__cpu_up);
-DUMMY(do_get_pm_info);
 DUMMY(domain_get_maximum_gpfn);
 DUMMY(domain_relinquish_resources);
 DUMMY(domain_set_time_offset);
 DUMMY(dom_cow);
 DUMMY(donate_page);
-DUMMY(do_pm_op);
 DUMMY(flush_tlb_mask);
 DUMMY(free_vcpu_guest_context);
 DUMMY(get_page);
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index f8f7cf8..fef0589 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -224,6 +224,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
     }
     break;
 
+#ifdef HAS_ACPI
     case XEN_SYSCTL_get_pmstat:
     {
         ret = xsm_get_pmstat();
@@ -259,6 +260,7 @@ long do_sysctl(XEN_GUEST_HANDLE(xen_sysctl_t) u_sysctl)
         }
     }
     break;
+#endif
 
     case XEN_SYSCTL_page_offline_op:
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDFB-0002Md-QO; Fri, 20 Jan 2012 12:06:57 +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 1RoDF9-0002G9-UN
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1155 invoked from network); 20 Jan 2012 12:06:49 -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;
	20 Jan 2012 12:06:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105042"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:49 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dnA015488; Fri, 20 Jan 2012 04:06:48 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:37 +0000
Message-ID: <1327061198-29854-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/12] arm: define max_page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    2 ++
 xen/arch/arm/setup.c |    2 ++
 3 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 67edb35..295938e 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -28,7 +28,6 @@ DUMMY(gnttab_clear_flag);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
 DUMMY(is_iomem_page);
-DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
 DUMMY(page_get_owner_and_reference);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 50c3634..4ec9788 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -41,6 +41,8 @@ unsigned long xenheap_virt_end;
 
 unsigned long frametable_virt_end;
 
+unsigned long max_page;
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2fcde24..b195813 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -31,6 +31,7 @@
 #include <xen/softirq.h>
 #include <xen/keyhandler.h>
 #include <xen/cpu.h>
+#include <xen/pfn.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/setup.h>
@@ -122,6 +123,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     /* TODO Need to find actual memory, for now use 4GB at 512GB */
     setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
+    max_page = PFN_DOWN(0x8100000000UL);
 
     /* Add xenheap memory */
     init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF0-0002FK-Ty; Fri, 20 Jan 2012 12:06:46 +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 1RoDEz-0002F4-6u
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:45 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327059877!1672531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28022 invoked from network); 20 Jan 2012 11:44:38 -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 Jan 2012 11:44:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; 
   d="scan'";a="10175088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:44:36 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 11:44:36 +0000
Message-ID: <1327059874.2337.38.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 12:44:34 +0100
In-Reply-To: <1327058562.17599.134.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8639657199683423197=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8639657199683423197==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-x3E40jczZXXTjW0U40lM"

--=-x3E40jczZXXTjW0U40lM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 11:22 +0000, Ian Campbell wrote:=20
> > It seems that xend is retrieving numa info about the platform, see
> > pyxc_numainfo, then using those info to pin vcpus to pcpus, see
> > _setCPUAffinity.
> > Still it seems to me more of an hack than the right way to solve the
> > problem.
>=20
> Right, so in the absence of any explicit configuration it basically
> picks a NUMA node (via some heuristic) and automatically puts the guest
> into it.
>=20
Seems so. As Stefano is saying I don't think this is something that
should be done at the toolstack level, or at least not at the xl-level
of the toolstack. :-)

> It seems to me that xl's behaviour isn't wrong as such, it's just
> different.
>=20
Indeed.

> I think the important thing is that xl should honour user's explicit
> requests to use a particular node, either via vcpu pinning or cpupools
> etc.
>=20
And I agree again, honouring explicit user requests is key point. I
think the issue here is what should be dona, say by default, i.e., if
the user doesn't say anything about CPU/memory allocation. My idea was
to have Xen supporting a "NUMA-aware operational mode" where (and this
will actually be the first step!) it does exactly what xend is doing
right now --- that is, choosing a node and putting the new guest there,
both memory and CPU-wise. However, having this logic in the hypervisor
would allow Xen itself, for example, while investigating which node to
use for a new guest, or during a sort of periodic load balancing or
whatever, to change its mind and move a guest to a different node from
where it was put in the first place, as well as a bunch of other things.
I'm not sure the same can be done within the toolstack but I think I can
say that if it can, it would be way more complex and probably less
effective... Am I wrong?

Of course, even in such mode, if the user explicitly tells us what he
wants, e.g., by means of cpupools, pinning, etc., we should still honour
such request.

Then the question is whether or nod this mode would be the default, or
would need to be explicitly requested (boot parameter or something), but
that would become important only when we will have it up and
running... :-)

What do you think? Does this look reasonable? As the topic has been
raised, I'd very much enjoy some early feedback! :-P

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, PhD, Senior Software Engineer, Citrix Systems R&D Ltd.,
Cambridge (UK)



--=-x3E40jczZXXTjW0U40lM
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)

iEYEABECAAYFAk8ZU6MACgkQk4XaBE3IOsQKNQCgknwYi+ceqzO0mVvoV+QgHYc3
ggYAn3ifcmHJjcLkZtEdRIKt/vtcm8Gh
=SsRw
-----END PGP SIGNATURE-----

--=-x3E40jczZXXTjW0U40lM--


--===============8639657199683423197==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8639657199683423197==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDFB-0002Md-QO; Fri, 20 Jan 2012 12:06:57 +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 1RoDF9-0002G9-UN
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327061201!4283485!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1155 invoked from network); 20 Jan 2012 12:06:49 -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;
	20 Jan 2012 12:06:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="21105042"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:49 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dnA015488; Fri, 20 Jan 2012 04:06:48 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:37 +0000
Message-ID: <1327061198-29854-11-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 11/12] arm: define max_page
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    2 ++
 xen/arch/arm/setup.c |    2 ++
 3 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index 67edb35..295938e 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -28,7 +28,6 @@ DUMMY(gnttab_clear_flag);
 DUMMY(gnttab_mark_dirty);
 DUMMY(hypercall_create_continuation);
 DUMMY(is_iomem_page);
-DUMMY(max_page);
 DUMMY(node_online_map);
 DUMMY(nr_irqs_gsi);
 DUMMY(page_get_owner_and_reference);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 50c3634..4ec9788 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -41,6 +41,8 @@ unsigned long xenheap_virt_end;
 
 unsigned long frametable_virt_end;
 
+unsigned long max_page;
+
 /* Map a 4k page in a fixmap entry */
 void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
 {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2fcde24..b195813 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -31,6 +31,7 @@
 #include <xen/softirq.h>
 #include <xen/keyhandler.h>
 #include <xen/cpu.h>
+#include <xen/pfn.h>
 #include <asm/page.h>
 #include <asm/current.h>
 #include <asm/setup.h>
@@ -122,6 +123,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
     /* TODO Need to find actual memory, for now use 4GB at 512GB */
     setup_frametable_mappings(0x8000000000ULL, 0x8100000000UL);
+    max_page = PFN_DOWN(0x8100000000UL);
 
     /* Add xenheap memory */
     init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start+1),
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF0-0002FK-Ty; Fri, 20 Jan 2012 12:06:46 +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 1RoDEz-0002F4-6u
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:45 +0000
X-Env-Sender: dario.faggioli@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327059877!1672531!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28022 invoked from network); 20 Jan 2012 11:44:38 -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 Jan 2012 11:44:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; 
   d="scan'";a="10175088"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:44:36 +0000
Received: from [IPv6:::1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 11:44:36 +0000
Message-ID: <1327059874.2337.38.camel@Abyss>
From: Dario Faggioli <dario.faggioli@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 12:44:34 +0100
In-Reply-To: <1327058562.17599.134.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, "Tim
	\(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8639657199683423197=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8639657199683423197==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-x3E40jczZXXTjW0U40lM"

--=-x3E40jczZXXTjW0U40lM
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 11:22 +0000, Ian Campbell wrote:=20
> > It seems that xend is retrieving numa info about the platform, see
> > pyxc_numainfo, then using those info to pin vcpus to pcpus, see
> > _setCPUAffinity.
> > Still it seems to me more of an hack than the right way to solve the
> > problem.
>=20
> Right, so in the absence of any explicit configuration it basically
> picks a NUMA node (via some heuristic) and automatically puts the guest
> into it.
>=20
Seems so. As Stefano is saying I don't think this is something that
should be done at the toolstack level, or at least not at the xl-level
of the toolstack. :-)

> It seems to me that xl's behaviour isn't wrong as such, it's just
> different.
>=20
Indeed.

> I think the important thing is that xl should honour user's explicit
> requests to use a particular node, either via vcpu pinning or cpupools
> etc.
>=20
And I agree again, honouring explicit user requests is key point. I
think the issue here is what should be dona, say by default, i.e., if
the user doesn't say anything about CPU/memory allocation. My idea was
to have Xen supporting a "NUMA-aware operational mode" where (and this
will actually be the first step!) it does exactly what xend is doing
right now --- that is, choosing a node and putting the new guest there,
both memory and CPU-wise. However, having this logic in the hypervisor
would allow Xen itself, for example, while investigating which node to
use for a new guest, or during a sort of periodic load balancing or
whatever, to change its mind and move a guest to a different node from
where it was put in the first place, as well as a bunch of other things.
I'm not sure the same can be done within the toolstack but I think I can
say that if it can, it would be way more complex and probably less
effective... Am I wrong?

Of course, even in such mode, if the user explicitly tells us what he
wants, e.g., by means of cpupools, pinning, etc., we should still honour
such request.

Then the question is whether or nod this mode would be the default, or
would need to be explicitly requested (boot parameter or something), but
that would become important only when we will have it up and
running... :-)

What do you think? Does this look reasonable? As the topic has been
raised, I'd very much enjoy some early feedback! :-P

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, PhD, Senior Software Engineer, Citrix Systems R&D Ltd.,
Cambridge (UK)



--=-x3E40jczZXXTjW0U40lM
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)

iEYEABECAAYFAk8ZU6MACgkQk4XaBE3IOsQKNQCgknwYi+ceqzO0mVvoV+QgHYc3
ggYAn3ifcmHJjcLkZtEdRIKt/vtcm8Gh
=SsRw
-----END PGP SIGNATURE-----

--=-x3E40jczZXXTjW0U40lM--


--===============8639657199683423197==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8639657199683423197==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF5-0002GT-6p; Fri, 20 Jan 2012 12:06: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 1RoDF2-0002FZ-Jl
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327061153!53381942!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23117 invoked from network); 20 Jan 2012 12:05:55 -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;
	20 Jan 2012 12:05:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403328"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:46 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn7015488; Fri, 20 Jan 2012 04:06:45 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:34 +0000
Message-ID: <1327061198-29854-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/12] arm: Implement arch_get_xen_caps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TBD: correct arch name for this string. Should be "xen-" / "hvm-" or something
else given the hybrid model we are using on ARM?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    1 +
 xen/arch/arm/setup.c |   12 ++++++++++++
 3 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index da0b906..5010619 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -9,7 +9,6 @@ x:	mov pc, lr
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_get_xen_caps);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
 DUMMY(create_grant_host_mapping);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 45971cb..50c3634 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -23,6 +23,7 @@
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
+#include <xen/errno.h>
 #include <asm/page.h>
 #include <asm/current.h>
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2433723..2fcde24 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -213,6 +213,18 @@ void __init start_xen(unsigned long boot_phys_offset,
     reset_stack_and_jump(init_done);
 }
 
+void arch_get_xen_caps(xen_capabilities_info_t *info)
+{
+    /* Interface name is always xen-3.0-* for Xen-3.x. */
+    int major = 3, minor = 0;
+    char s[32];
+
+    (*info)[0] = '\0';
+
+    snprintf(s, sizeof(s), "xen-%d.%d-armv7l ", major, minor);
+    safe_strcat(*info, s);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:07:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:07:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDF5-0002GT-6p; Fri, 20 Jan 2012 12:06: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 1RoDF2-0002FZ-Jl
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:06:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327061153!53381942!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23117 invoked from network); 20 Jan 2012 12:05:55 -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;
	20 Jan 2012 12:05:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320642000"; d="scan'208";a="178403328"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 07:06: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, 20 Jan 2012 07:06:46 -0500
Received: from drall.uk.xensource.com (drall.uk.xensource.com [10.80.227.107])
	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KC6dn7015488; Fri, 20 Jan 2012 04:06:45 -0800
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 12:06:34 +0000
Message-ID: <1327061198-29854-8-git-send-email-ian.campbell@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/12] arm: Implement arch_get_xen_caps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

TBD: correct arch name for this string. Should be "xen-" / "hvm-" or something
else given the hybrid model we are using on ARM?

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/arch/arm/dummy.S |    1 -
 xen/arch/arm/mm.c    |    1 +
 xen/arch/arm/setup.c |   12 ++++++++++++
 3 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
index da0b906..5010619 100644
--- a/xen/arch/arm/dummy.S
+++ b/xen/arch/arm/dummy.S
@@ -9,7 +9,6 @@ x:	mov pc, lr
 DUMMY(alloc_pirq_struct);
 DUMMY(alloc_vcpu_guest_context);
 DUMMY(arch_get_info_guest);
-DUMMY(arch_get_xen_caps);
 DUMMY(arch_set_info_guest);
 DUMMY(arch_vcpu_reset);
 DUMMY(create_grant_host_mapping);
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 45971cb..50c3634 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -23,6 +23,7 @@
 #include <xen/init.h>
 #include <xen/mm.h>
 #include <xen/preempt.h>
+#include <xen/errno.h>
 #include <asm/page.h>
 #include <asm/current.h>
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2433723..2fcde24 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -213,6 +213,18 @@ void __init start_xen(unsigned long boot_phys_offset,
     reset_stack_and_jump(init_done);
 }
 
+void arch_get_xen_caps(xen_capabilities_info_t *info)
+{
+    /* Interface name is always xen-3.0-* for Xen-3.x. */
+    int major = 3, minor = 0;
+    char s[32];
+
+    (*info)[0] = '\0';
+
+    snprintf(s, sizeof(s), "xen-%d.%d-armv7l ", major, minor);
+    safe_strcat(*info, s);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:08:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDGA-00035O-B0; Fri, 20 Jan 2012 12:07:58 +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 1RoDG8-00031h-Vy
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:07:57 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327061090!9804763!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 17690 invoked from network); 20 Jan 2012 12:06:19 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 12:06:19 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74892099; Fri, 20 Jan 2012 13:04:49 +0100
Message-ID: <1327061083.2337.42.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 13:04:43 +0100
In-Reply-To: <1327060480.30054.15.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1464181571590518562=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1464181571590518562==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-yQduLsB83ZT9H2OedbaA"


--=-yQduLsB83ZT9H2OedbaA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 11:54 +0000, Ian Campbell wrote:=20
> This might be doable for HVM guests but for PV guests pretty much the
> only way would be a kind of local migration which would need tool
> support. For the PV case hybrid support would help (by introducing HAP
> for PV guests). Not saying it's not worthwhile but might just be harder
> than it sounds.
>=20
That local migration analogy was exactly what came out when we were
trying to envision how to deal with the PV guest case. I still know too
few about all this to have a authoritative opinion, so, for now, thanks
for the warning! :-D

> > Of course, even in such mode, if the user explicitly tells us what he
> > wants, e.g., by means of cpupools, pinning, etc., we should still honou=
r
> > such request.
>=20
> Do we get this right now?
>=20
Sorry, not sure what you mean here...

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)



--=-yQduLsB83ZT9H2OedbaA
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)

iEYEABECAAYFAk8ZWFsACgkQk4XaBE3IOsTglQCgobKVAIjnd/KNP7t7ZdWl8XWa
Q8QAn1QyMO3eUy0zQqyvZlpkH0GGZ/IZ
=J81D
-----END PGP SIGNATURE-----

--=-yQduLsB83ZT9H2OedbaA--



--===============1464181571590518562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1464181571590518562==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:08:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:08:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDGA-00035O-B0; Fri, 20 Jan 2012 12:07:58 +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 1RoDG8-00031h-Vy
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:07:57 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327061090!9804763!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 17690 invoked from network); 20 Jan 2012 12:06:19 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 12:06:19 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74892099; Fri, 20 Jan 2012 13:04:49 +0100
Message-ID: <1327061083.2337.42.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 13:04:43 +0100
In-Reply-To: <1327060480.30054.15.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1464181571590518562=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1464181571590518562==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-yQduLsB83ZT9H2OedbaA"


--=-yQduLsB83ZT9H2OedbaA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 11:54 +0000, Ian Campbell wrote:=20
> This might be doable for HVM guests but for PV guests pretty much the
> only way would be a kind of local migration which would need tool
> support. For the PV case hybrid support would help (by introducing HAP
> for PV guests). Not saying it's not worthwhile but might just be harder
> than it sounds.
>=20
That local migration analogy was exactly what came out when we were
trying to envision how to deal with the PV guest case. I still know too
few about all this to have a authoritative opinion, so, for now, thanks
for the warning! :-D

> > Of course, even in such mode, if the user explicitly tells us what he
> > wants, e.g., by means of cpupools, pinning, etc., we should still honou=
r
> > such request.
>=20
> Do we get this right now?
>=20
Sorry, not sure what you mean here...

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)



--=-yQduLsB83ZT9H2OedbaA
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)

iEYEABECAAYFAk8ZWFsACgkQk4XaBE3IOsTglQCgobKVAIjnd/KNP7t7ZdWl8XWa
Q8QAn1QyMO3eUy0zQqyvZlpkH0GGZ/IZ
=J81D
-----END PGP SIGNATURE-----

--=-yQduLsB83ZT9H2OedbaA--



--===============1464181571590518562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1464181571590518562==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:19:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDR4-0004es-RF; Fri, 20 Jan 2012 12:19: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 1RoDR3-0004ec-BV
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:19:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327061947!11700455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8697 invoked from network); 20 Jan 2012 12:19:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:19:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:19:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:19:06 +0000
Date: Fri, 20 Jan 2012 12:19:02 +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: <1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Why do we need this?
I though that tmem compiled OK on ARM. Also I don't think there is any
architectural limitation that would prevent tmem from working on ARM,
right?
If the goal is to remove DUMMY(donate_page) maybe it is better to
introduce a stub function instead?

On Fri, 20 Jan 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/Rules.mk               |    1 +
>  xen/arch/arm/dummy.S       |    1 -
>  xen/arch/ia64/Rules.mk     |    1 +
>  xen/arch/x86/Rules.mk      |    1 +
>  xen/common/Makefile        |    4 ++--
>  xen/common/page_alloc.c    |    1 +
>  xen/include/xen/tmem.h     |    9 +++++++++
>  xen/include/xen/tmem_xen.h |    5 +++++
>  8 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index b7b54f6..e25e8d4 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> +CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
>  ifneq ($(max_phys_cpus),)
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 3bf5226..da0b906 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -20,7 +20,6 @@ DUMMY(domain_get_maximum_gpfn);
>  DUMMY(domain_relinquish_resources);
>  DUMMY(domain_set_time_offset);
>  DUMMY(dom_cow);
> -DUMMY(donate_page);
>  DUMMY(flush_tlb_mask);
>  DUMMY(free_vcpu_guest_context);
>  DUMMY(get_page);
> diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
> index 054b4de..6c8cf69 100644
> --- a/xen/arch/ia64/Rules.mk
> +++ b/xen/arch/ia64/Rules.mk
> @@ -9,6 +9,7 @@ HAS_PCI := y
>  HAS_PASSTHROUGH := y
>  HAS_NS16550 := y
>  HAS_KEXEC := y
> +HAS_TMEM := y
>  xenoprof := y
>  no_warns ?= n
>  vti_debug ?= n
> diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> index 1e48877..8802a69 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -8,6 +8,7 @@ HAS_PCI := y
>  HAS_PASSTHROUGH := y
>  HAS_NS16550 := y
>  HAS_KEXEC := y
> +HAS_TMEM := y
>  xenoprof := y
>  
>  #
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 9249845..68a2df1 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -38,8 +38,8 @@ obj-y += vsprintf.o
>  obj-y += wait.o
>  obj-y += xmalloc_tlsf.o
>  obj-y += rcupdate.o
> -obj-y += tmem.o
> -obj-y += tmem_xen.o
> +obj-$(HAS_TMEM) += tmem.o
> +obj-$(HAS_TMEM) += tmem_xen.o
>  obj-y += radix-tree.o
>  obj-y += rbtree.o
>  obj-y += lzo.o
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 249bb35..3aac830 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -35,6 +35,7 @@
>  #include <xen/perfc.h>
>  #include <xen/numa.h>
>  #include <xen/nodemask.h>
> +#include <xen/errno.h>
>  #include <xen/tmem.h>
>  #include <xen/tmem_xen.h>
>  #include <public/sysctl.h>
> diff --git a/xen/include/xen/tmem.h b/xen/include/xen/tmem.h
> index 5dbf9d5..2ebffb4 100644
> --- a/xen/include/xen/tmem.h
> +++ b/xen/include/xen/tmem.h
> @@ -9,8 +9,17 @@
>  #ifndef __XEN_TMEM_H__
>  #define __XEN_TMEM_H__
>  
> +#ifdef HAS_TMEM
>  extern void tmem_destroy(void *);
>  extern void *tmem_relinquish_pages(unsigned int, unsigned int);
>  extern unsigned long tmem_freeable_pages(void);
> +#else
> +static inline void tmem_destroy(void *v) {}
> +static inline void *tmem_relinquish_pages(unsigned int order, unsigned int flags)
> +{
> +	return NULL;
> +}
> +static inline unsigned long tmem_freeable_pages(void) { return 0; }
> +#endif
>  
>  #endif /* __XEN_TMEM_H__ */
> diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
> index fdbeed1..a6c0672 100644
> --- a/xen/include/xen/tmem_xen.h
> +++ b/xen/include/xen/tmem_xen.h
> @@ -9,6 +9,7 @@
>  #ifndef __XEN_TMEM_XEN_H__
>  #define __XEN_TMEM_XEN_H__
>  
> +#ifdef HAS_TMEM
>  #include <xen/config.h>
>  #include <xen/mm.h> /* heap alloc/free */
>  #include <xen/pfn.h>
> @@ -559,4 +560,8 @@ extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t
>  #define RESET_CYC_COUNTER(x) do { } while (0)
>  #endif
>  
> +#else /* HAS_TMEM */
> +#define opt_tmem 0
> +#endif
> +
>  #endif /* __XEN_TMEM_XEN_H__ */
> -- 
> 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 Jan 20 12:19:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDR4-0004es-RF; Fri, 20 Jan 2012 12:19: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 1RoDR3-0004ec-BV
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:19:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327061947!11700455!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8697 invoked from network); 20 Jan 2012 12:19:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:19:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:19:07 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:19:06 +0000
Date: Fri, 20 Jan 2012 12:19:02 +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: <1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Why do we need this?
I though that tmem compiled OK on ARM. Also I don't think there is any
architectural limitation that would prevent tmem from working on ARM,
right?
If the goal is to remove DUMMY(donate_page) maybe it is better to
introduce a stub function instead?

On Fri, 20 Jan 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/Rules.mk               |    1 +
>  xen/arch/arm/dummy.S       |    1 -
>  xen/arch/ia64/Rules.mk     |    1 +
>  xen/arch/x86/Rules.mk      |    1 +
>  xen/common/Makefile        |    4 ++--
>  xen/common/page_alloc.c    |    1 +
>  xen/include/xen/tmem.h     |    9 +++++++++
>  xen/include/xen/tmem_xen.h |    5 +++++
>  8 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index b7b54f6..e25e8d4 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> +CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
>  ifneq ($(max_phys_cpus),)
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 3bf5226..da0b906 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -20,7 +20,6 @@ DUMMY(domain_get_maximum_gpfn);
>  DUMMY(domain_relinquish_resources);
>  DUMMY(domain_set_time_offset);
>  DUMMY(dom_cow);
> -DUMMY(donate_page);
>  DUMMY(flush_tlb_mask);
>  DUMMY(free_vcpu_guest_context);
>  DUMMY(get_page);
> diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
> index 054b4de..6c8cf69 100644
> --- a/xen/arch/ia64/Rules.mk
> +++ b/xen/arch/ia64/Rules.mk
> @@ -9,6 +9,7 @@ HAS_PCI := y
>  HAS_PASSTHROUGH := y
>  HAS_NS16550 := y
>  HAS_KEXEC := y
> +HAS_TMEM := y
>  xenoprof := y
>  no_warns ?= n
>  vti_debug ?= n
> diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> index 1e48877..8802a69 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -8,6 +8,7 @@ HAS_PCI := y
>  HAS_PASSTHROUGH := y
>  HAS_NS16550 := y
>  HAS_KEXEC := y
> +HAS_TMEM := y
>  xenoprof := y
>  
>  #
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 9249845..68a2df1 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -38,8 +38,8 @@ obj-y += vsprintf.o
>  obj-y += wait.o
>  obj-y += xmalloc_tlsf.o
>  obj-y += rcupdate.o
> -obj-y += tmem.o
> -obj-y += tmem_xen.o
> +obj-$(HAS_TMEM) += tmem.o
> +obj-$(HAS_TMEM) += tmem_xen.o
>  obj-y += radix-tree.o
>  obj-y += rbtree.o
>  obj-y += lzo.o
> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> index 249bb35..3aac830 100644
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -35,6 +35,7 @@
>  #include <xen/perfc.h>
>  #include <xen/numa.h>
>  #include <xen/nodemask.h>
> +#include <xen/errno.h>
>  #include <xen/tmem.h>
>  #include <xen/tmem_xen.h>
>  #include <public/sysctl.h>
> diff --git a/xen/include/xen/tmem.h b/xen/include/xen/tmem.h
> index 5dbf9d5..2ebffb4 100644
> --- a/xen/include/xen/tmem.h
> +++ b/xen/include/xen/tmem.h
> @@ -9,8 +9,17 @@
>  #ifndef __XEN_TMEM_H__
>  #define __XEN_TMEM_H__
>  
> +#ifdef HAS_TMEM
>  extern void tmem_destroy(void *);
>  extern void *tmem_relinquish_pages(unsigned int, unsigned int);
>  extern unsigned long tmem_freeable_pages(void);
> +#else
> +static inline void tmem_destroy(void *v) {}
> +static inline void *tmem_relinquish_pages(unsigned int order, unsigned int flags)
> +{
> +	return NULL;
> +}
> +static inline unsigned long tmem_freeable_pages(void) { return 0; }
> +#endif
>  
>  #endif /* __XEN_TMEM_H__ */
> diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
> index fdbeed1..a6c0672 100644
> --- a/xen/include/xen/tmem_xen.h
> +++ b/xen/include/xen/tmem_xen.h
> @@ -9,6 +9,7 @@
>  #ifndef __XEN_TMEM_XEN_H__
>  #define __XEN_TMEM_XEN_H__
>  
> +#ifdef HAS_TMEM
>  #include <xen/config.h>
>  #include <xen/mm.h> /* heap alloc/free */
>  #include <xen/pfn.h>
> @@ -559,4 +560,8 @@ extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t
>  #define RESET_CYC_COUNTER(x) do { } while (0)
>  #endif
>  
> +#else /* HAS_TMEM */
> +#define opt_tmem 0
> +#endif
> +
>  #endif /* __XEN_TMEM_XEN_H__ */
> -- 
> 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 Jan 20 12:20:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDSG-0004pC-DL; Fri, 20 Jan 2012 12:20:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoDSF-0004nl-9I
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:20:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327062020!9926207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28277 invoked from network); 20 Jan 2012 12:20:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:20:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:20:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:20:20 +0000
Date: Fri, 20 Jan 2012 12:20: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: <1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Could we have a proper stub function or a static inline rather than an
#define?


On Fri, 20 Jan 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/dummy.S      |    2 --
>  xen/include/asm-arm/mm.h  |    8 ++++++--
>  xen/include/asm-arm/p2m.h |   11 +++++++----
>  3 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index e858613..67edb35 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -31,8 +31,6 @@ DUMMY(is_iomem_page);
>  DUMMY(max_page);
>  DUMMY(node_online_map);
>  DUMMY(nr_irqs_gsi);
> -DUMMY(p2m_pod_decrease_reservation);
> -DUMMY(guest_physmap_mark_populate_on_demand);
>  DUMMY(page_get_owner_and_reference);
>  DUMMY(page_is_ram_type);
>  DUMMY(per_cpu__cpu_core_mask);
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index f721c54..ebe09cf 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -294,8 +294,12 @@ extern struct domain *dom_xen, *dom_io, *dom_cow;
>  #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);
> +/*
> + * int guest_physmap_mark_populate_on_demand(struct domain *d,
> + *                                           unsigned long gfn,
> + *                                           unsigned int order)
> + */
> +#define guest_physmap_mark_populate_on_demand(d, gfn, order) -ENOSYS /* No PoD on ARM */
>  
>  extern void put_page_type(struct page_info *page);
>  static inline void put_page_and_type(struct page_info *page)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index aec52f7..723518d 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -48,10 +48,13 @@ unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
>  
>  /* 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);
> + /* No PoD on ARM yet */
> +/* int
> + * p2m_pod_decrease_reservation(struct domain *d,
> + *                              xen_pfn_t gpfn,
> + *                              unsigned int order);
> + */
> +#define p2m_pod_decrease_reservation(d, gpfn, order) -ENOSYS
>  
>  /* Compatibility function exporting the old untyped interface */
>  static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
> -- 
> 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 Jan 20 12:20:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDSG-0004pC-DL; Fri, 20 Jan 2012 12:20:28 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoDSF-0004nl-9I
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:20:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327062020!9926207!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28277 invoked from network); 20 Jan 2012 12:20:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:20:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176041"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:20:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:20:20 +0000
Date: Fri, 20 Jan 2012 12:20: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: <1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
Message-ID: <alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Could we have a proper stub function or a static inline rather than an
#define?


On Fri, 20 Jan 2012, Ian Campbell wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/arch/arm/dummy.S      |    2 --
>  xen/include/asm-arm/mm.h  |    8 ++++++--
>  xen/include/asm-arm/p2m.h |   11 +++++++----
>  3 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index e858613..67edb35 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -31,8 +31,6 @@ DUMMY(is_iomem_page);
>  DUMMY(max_page);
>  DUMMY(node_online_map);
>  DUMMY(nr_irqs_gsi);
> -DUMMY(p2m_pod_decrease_reservation);
> -DUMMY(guest_physmap_mark_populate_on_demand);
>  DUMMY(page_get_owner_and_reference);
>  DUMMY(page_is_ram_type);
>  DUMMY(per_cpu__cpu_core_mask);
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index f721c54..ebe09cf 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -294,8 +294,12 @@ extern struct domain *dom_xen, *dom_io, *dom_cow;
>  #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);
> +/*
> + * int guest_physmap_mark_populate_on_demand(struct domain *d,
> + *                                           unsigned long gfn,
> + *                                           unsigned int order)
> + */
> +#define guest_physmap_mark_populate_on_demand(d, gfn, order) -ENOSYS /* No PoD on ARM */
>  
>  extern void put_page_type(struct page_info *page);
>  static inline void put_page_and_type(struct page_info *page)
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index aec52f7..723518d 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -48,10 +48,13 @@ unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
>  
>  /* 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);
> + /* No PoD on ARM yet */
> +/* int
> + * p2m_pod_decrease_reservation(struct domain *d,
> + *                              xen_pfn_t gpfn,
> + *                              unsigned int order);
> + */
> +#define p2m_pod_decrease_reservation(d, gpfn, order) -ENOSYS
>  
>  /* Compatibility function exporting the old untyped interface */
>  static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
> -- 
> 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 Jan 20 12:20:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDSb-0004sF-1S; Fri, 20 Jan 2012 12:20:49 +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 1RoDSZ-0004rR-II
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:20:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327062041!11689178!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23866 invoked from network); 20 Jan 2012 12:20:41 -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;
	20 Jan 2012 12:20:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176047"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:20: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, 20 Jan 2012 12:20:41 +0000
Date: Fri, 20 Jan 2012 12:20:36 +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: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201220220.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/12] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Ian Campbell wrote:
> Defines a few stubs and disables some as yet unsupported core features.
> 
> Early on there's a couple of unrelated cleanups.
> 
> Patch against v5 posting (Stefano's arm-v5 branch) + David Vrables
> zImage series.

All fine by me but two comments.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:20:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:20:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDSb-0004sF-1S; Fri, 20 Jan 2012 12:20:49 +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 1RoDSZ-0004rR-II
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:20:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327062041!11689178!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23866 invoked from network); 20 Jan 2012 12:20:41 -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;
	20 Jan 2012 12:20:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176047"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:20: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, 20 Jan 2012 12:20:41 +0000
Date: Fri, 20 Jan 2012 12:20:36 +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: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201220220.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 00/12] ARM: Slim down dummy.S
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Ian Campbell wrote:
> Defines a few stubs and disables some as yet unsupported core features.
> 
> Early on there's a couple of unrelated cleanups.
> 
> Patch against v5 posting (Stefano's arm-v5 branch) + David Vrables
> zImage series.

All fine by me but two comments.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:25:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:25:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDX7-0005Fi-Oe; Fri, 20 Jan 2012 12:25: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 1RoDX5-0005FU-MQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:25:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327062321!9925794!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 32412 invoked from network); 20 Jan 2012 12:25:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 12:25:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RoDWv-000Pxu-O4; Fri, 20 Jan 2012 12:25:17 +0000
Date: Fri, 20 Jan 2012 12:25:17 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120120122517.GB97313@ocelot.phlegethon.org>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
	platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:19 +0000 on 20 Jan (1327061942), Stefano Stabellini wrote:
> Why do we need this?
> I though that tmem compiled OK on ARM. Also I don't think there is any
> architectural limitation that would prevent tmem from working on ARM,
> right?

It may compile but it surely won't work. :)  Does tmem work at all for
non-PV guests?

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:25:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:25:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDX7-0005Fi-Oe; Fri, 20 Jan 2012 12:25: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 1RoDX5-0005FU-MQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:25:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327062321!9925794!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 32412 invoked from network); 20 Jan 2012 12:25:21 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 12:25:21 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RoDWv-000Pxu-O4; Fri, 20 Jan 2012 12:25:17 +0000
Date: Fri, 20 Jan 2012 12:25:17 +0000
From: Tim Deegan <tim@xen.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120120122517.GB97313@ocelot.phlegethon.org>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
	platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:19 +0000 on 20 Jan (1327061942), Stefano Stabellini wrote:
> Why do we need this?
> I though that tmem compiled OK on ARM. Also I don't think there is any
> architectural limitation that would prevent tmem from working on ARM,
> right?

It may compile but it surely won't work. :)  Does tmem work at all for
non-PV guests?

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:26:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDXy-0005LD-7C; Fri, 20 Jan 2012 12:26:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoDXx-0005KZ-Eu
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:26:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327062276!11654132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18536 invoked from network); 20 Jan 2012 12:24:36 -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;
	20 Jan 2012 12:24:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:24: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; Fri, 20 Jan 2012 12:24:35 +0000
Date: Fri, 20 Jan 2012 12:24:30 +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: <1327059202.30054.3.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201221090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327059202.30054.3.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> > diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> > index a6bb894..3d11c39 100644
> > --- a/tools/libxc/xc_domain_save.c
> > +++ b/tools/libxc/xc_domain_save.c
> > @@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> >          }
> >      }
> > 
> > +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> > +    {
> > +        int id = XC_SAVE_ID_TOOLSTACK;
> > +        uint8_t *buf;
> > +        uint32_t len;
> > +
> > +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> > +        {
> > +            PERROR("Error calling toolstack_save");
> > +            goto out;
> > +        }
> > +        wrexact(io_fd, &id, sizeof(id));
> > +        wrexact(io_fd, &len, sizeof(len));
> > +        wrexact(io_fd, buf, len);
> 
> Where is buf free'd? You say below "callee allocates and frees the
> buffer" but there is no way that can be the case since the caller uses
> the buffer after the callback.

The callee can free the buffer after the completion of xc_domain_save.
So libxl allocates the buffer in toolstack_save and frees it after
xc_domain_save returns.


> I think it has to be callee-alloc, caller-free (perhaps callee-free on
> error).

I though that it is more straightforward if the callee does both, but if
you think that is actually more confusing, I'll change it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:26:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:26:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDXy-0005LD-7C; Fri, 20 Jan 2012 12:26:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoDXx-0005KZ-Eu
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:26:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327062276!11654132!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18536 invoked from network); 20 Jan 2012 12:24:36 -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;
	20 Jan 2012 12:24:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176125"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:24: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; Fri, 20 Jan 2012 12:24:35 +0000
Date: Fri, 20 Jan 2012 12:24:30 +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: <1327059202.30054.3.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201221090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327059202.30054.3.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> > diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> > index a6bb894..3d11c39 100644
> > --- a/tools/libxc/xc_domain_save.c
> > +++ b/tools/libxc/xc_domain_save.c
> > @@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> >          }
> >      }
> > 
> > +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> > +    {
> > +        int id = XC_SAVE_ID_TOOLSTACK;
> > +        uint8_t *buf;
> > +        uint32_t len;
> > +
> > +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> > +        {
> > +            PERROR("Error calling toolstack_save");
> > +            goto out;
> > +        }
> > +        wrexact(io_fd, &id, sizeof(id));
> > +        wrexact(io_fd, &len, sizeof(len));
> > +        wrexact(io_fd, buf, len);
> 
> Where is buf free'd? You say below "callee allocates and frees the
> buffer" but there is no way that can be the case since the caller uses
> the buffer after the callback.

The callee can free the buffer after the completion of xc_domain_save.
So libxl allocates the buffer in toolstack_save and frees it after
xc_domain_save returns.


> I think it has to be callee-alloc, caller-free (perhaps callee-free on
> error).

I though that it is more straightforward if the callee does both, but if
you think that is actually more confusing, I'll change it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:28:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDaI-0005Wk-Pe; Fri, 20 Jan 2012 12:28:46 +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 1RoDaH-0005WA-4O
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:28:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327062519!11167551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24668 invoked from network); 20 Jan 2012 12:28:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:28:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:28:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 12:28:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 12:28:38 +0000
In-Reply-To: <alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327062518.30054.26.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 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:19 +0000, Stefano Stabellini wrote:
> Why do we need this?
> I though that tmem compiled OK on ARM.

But it can't possibly work, as evidenced by the missing symbol in
dummy.S! There is no point in compiling something which cannot work.

>  Also I don't think there is any
> architectural limitation that would prevent tmem from working on ARM,
> right?

Not really an architectural thing but a "not yet implemented thing".
tmem is quite a long way down the list of things we need to do for ARM
right now. I'd be quite happy to have this patch reverted at some point
in the future but for now there is no point in pretending that tmem
works.

> If the goal is to remove DUMMY(donate_page) maybe it is better to
> introduce a stub function instead?

A stub would be no better than the dummy function in this case. It needs
to actually do things which we cannot do yet on ARM.

dummy.S is a total hack and we should be aiming to remove it ASAP.

Ian.

> 
> On Fri, 20 Jan 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/Rules.mk               |    1 +
> >  xen/arch/arm/dummy.S       |    1 -
> >  xen/arch/ia64/Rules.mk     |    1 +
> >  xen/arch/x86/Rules.mk      |    1 +
> >  xen/common/Makefile        |    4 ++--
> >  xen/common/page_alloc.c    |    1 +
> >  xen/include/xen/tmem.h     |    9 +++++++++
> >  xen/include/xen/tmem_xen.h |    5 +++++
> >  8 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index b7b54f6..e25e8d4 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
> >  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
> >  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> >  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> > +CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
> >  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
> >  
> >  ifneq ($(max_phys_cpus),)
> > diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> > index 3bf5226..da0b906 100644
> > --- a/xen/arch/arm/dummy.S
> > +++ b/xen/arch/arm/dummy.S
> > @@ -20,7 +20,6 @@ DUMMY(domain_get_maximum_gpfn);
> >  DUMMY(domain_relinquish_resources);
> >  DUMMY(domain_set_time_offset);
> >  DUMMY(dom_cow);
> > -DUMMY(donate_page);
> >  DUMMY(flush_tlb_mask);
> >  DUMMY(free_vcpu_guest_context);
> >  DUMMY(get_page);
> > diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
> > index 054b4de..6c8cf69 100644
> > --- a/xen/arch/ia64/Rules.mk
> > +++ b/xen/arch/ia64/Rules.mk
> > @@ -9,6 +9,7 @@ HAS_PCI := y
> >  HAS_PASSTHROUGH := y
> >  HAS_NS16550 := y
> >  HAS_KEXEC := y
> > +HAS_TMEM := y
> >  xenoprof := y
> >  no_warns ?= n
> >  vti_debug ?= n
> > diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> > index 1e48877..8802a69 100644
> > --- a/xen/arch/x86/Rules.mk
> > +++ b/xen/arch/x86/Rules.mk
> > @@ -8,6 +8,7 @@ HAS_PCI := y
> >  HAS_PASSTHROUGH := y
> >  HAS_NS16550 := y
> >  HAS_KEXEC := y
> > +HAS_TMEM := y
> >  xenoprof := y
> >  
> >  #
> > diff --git a/xen/common/Makefile b/xen/common/Makefile
> > index 9249845..68a2df1 100644
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -38,8 +38,8 @@ obj-y += vsprintf.o
> >  obj-y += wait.o
> >  obj-y += xmalloc_tlsf.o
> >  obj-y += rcupdate.o
> > -obj-y += tmem.o
> > -obj-y += tmem_xen.o
> > +obj-$(HAS_TMEM) += tmem.o
> > +obj-$(HAS_TMEM) += tmem_xen.o
> >  obj-y += radix-tree.o
> >  obj-y += rbtree.o
> >  obj-y += lzo.o
> > diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> > index 249bb35..3aac830 100644
> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -35,6 +35,7 @@
> >  #include <xen/perfc.h>
> >  #include <xen/numa.h>
> >  #include <xen/nodemask.h>
> > +#include <xen/errno.h>
> >  #include <xen/tmem.h>
> >  #include <xen/tmem_xen.h>
> >  #include <public/sysctl.h>
> > diff --git a/xen/include/xen/tmem.h b/xen/include/xen/tmem.h
> > index 5dbf9d5..2ebffb4 100644
> > --- a/xen/include/xen/tmem.h
> > +++ b/xen/include/xen/tmem.h
> > @@ -9,8 +9,17 @@
> >  #ifndef __XEN_TMEM_H__
> >  #define __XEN_TMEM_H__
> >  
> > +#ifdef HAS_TMEM
> >  extern void tmem_destroy(void *);
> >  extern void *tmem_relinquish_pages(unsigned int, unsigned int);
> >  extern unsigned long tmem_freeable_pages(void);
> > +#else
> > +static inline void tmem_destroy(void *v) {}
> > +static inline void *tmem_relinquish_pages(unsigned int order, unsigned int flags)
> > +{
> > +	return NULL;
> > +}
> > +static inline unsigned long tmem_freeable_pages(void) { return 0; }
> > +#endif
> >  
> >  #endif /* __XEN_TMEM_H__ */
> > diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
> > index fdbeed1..a6c0672 100644
> > --- a/xen/include/xen/tmem_xen.h
> > +++ b/xen/include/xen/tmem_xen.h
> > @@ -9,6 +9,7 @@
> >  #ifndef __XEN_TMEM_XEN_H__
> >  #define __XEN_TMEM_XEN_H__
> >  
> > +#ifdef HAS_TMEM
> >  #include <xen/config.h>
> >  #include <xen/mm.h> /* heap alloc/free */
> >  #include <xen/pfn.h>
> > @@ -559,4 +560,8 @@ extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t
> >  #define RESET_CYC_COUNTER(x) do { } while (0)
> >  #endif
> >  
> > +#else /* HAS_TMEM */
> > +#define opt_tmem 0
> > +#endif
> > +
> >  #endif /* __XEN_TMEM_XEN_H__ */
> > -- 
> > 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 Jan 20 12:28:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDaI-0005Wk-Pe; Fri, 20 Jan 2012 12:28:46 +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 1RoDaH-0005WA-4O
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:28:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327062519!11167551!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24668 invoked from network); 20 Jan 2012 12:28:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:28:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:28:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 12:28:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 12:28:38 +0000
In-Reply-To: <alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327062518.30054.26.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 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:19 +0000, Stefano Stabellini wrote:
> Why do we need this?
> I though that tmem compiled OK on ARM.

But it can't possibly work, as evidenced by the missing symbol in
dummy.S! There is no point in compiling something which cannot work.

>  Also I don't think there is any
> architectural limitation that would prevent tmem from working on ARM,
> right?

Not really an architectural thing but a "not yet implemented thing".
tmem is quite a long way down the list of things we need to do for ARM
right now. I'd be quite happy to have this patch reverted at some point
in the future but for now there is no point in pretending that tmem
works.

> If the goal is to remove DUMMY(donate_page) maybe it is better to
> introduce a stub function instead?

A stub would be no better than the dummy function in this case. It needs
to actually do things which we cannot do yet on ARM.

dummy.S is a total hack and we should be aiming to remove it ASAP.

Ian.

> 
> On Fri, 20 Jan 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/Rules.mk               |    1 +
> >  xen/arch/arm/dummy.S       |    1 -
> >  xen/arch/ia64/Rules.mk     |    1 +
> >  xen/arch/x86/Rules.mk      |    1 +
> >  xen/common/Makefile        |    4 ++--
> >  xen/common/page_alloc.c    |    1 +
> >  xen/include/xen/tmem.h     |    9 +++++++++
> >  xen/include/xen/tmem_xen.h |    5 +++++
> >  8 files changed, 20 insertions(+), 3 deletions(-)
> > 
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index b7b54f6..e25e8d4 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -51,6 +51,7 @@ CFLAGS-$(perfc)         += -DPERF_COUNTERS
> >  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
> >  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> >  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> > +CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
> >  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
> >  
> >  ifneq ($(max_phys_cpus),)
> > diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> > index 3bf5226..da0b906 100644
> > --- a/xen/arch/arm/dummy.S
> > +++ b/xen/arch/arm/dummy.S
> > @@ -20,7 +20,6 @@ DUMMY(domain_get_maximum_gpfn);
> >  DUMMY(domain_relinquish_resources);
> >  DUMMY(domain_set_time_offset);
> >  DUMMY(dom_cow);
> > -DUMMY(donate_page);
> >  DUMMY(flush_tlb_mask);
> >  DUMMY(free_vcpu_guest_context);
> >  DUMMY(get_page);
> > diff --git a/xen/arch/ia64/Rules.mk b/xen/arch/ia64/Rules.mk
> > index 054b4de..6c8cf69 100644
> > --- a/xen/arch/ia64/Rules.mk
> > +++ b/xen/arch/ia64/Rules.mk
> > @@ -9,6 +9,7 @@ HAS_PCI := y
> >  HAS_PASSTHROUGH := y
> >  HAS_NS16550 := y
> >  HAS_KEXEC := y
> > +HAS_TMEM := y
> >  xenoprof := y
> >  no_warns ?= n
> >  vti_debug ?= n
> > diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> > index 1e48877..8802a69 100644
> > --- a/xen/arch/x86/Rules.mk
> > +++ b/xen/arch/x86/Rules.mk
> > @@ -8,6 +8,7 @@ HAS_PCI := y
> >  HAS_PASSTHROUGH := y
> >  HAS_NS16550 := y
> >  HAS_KEXEC := y
> > +HAS_TMEM := y
> >  xenoprof := y
> >  
> >  #
> > diff --git a/xen/common/Makefile b/xen/common/Makefile
> > index 9249845..68a2df1 100644
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -38,8 +38,8 @@ obj-y += vsprintf.o
> >  obj-y += wait.o
> >  obj-y += xmalloc_tlsf.o
> >  obj-y += rcupdate.o
> > -obj-y += tmem.o
> > -obj-y += tmem_xen.o
> > +obj-$(HAS_TMEM) += tmem.o
> > +obj-$(HAS_TMEM) += tmem_xen.o
> >  obj-y += radix-tree.o
> >  obj-y += rbtree.o
> >  obj-y += lzo.o
> > diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> > index 249bb35..3aac830 100644
> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -35,6 +35,7 @@
> >  #include <xen/perfc.h>
> >  #include <xen/numa.h>
> >  #include <xen/nodemask.h>
> > +#include <xen/errno.h>
> >  #include <xen/tmem.h>
> >  #include <xen/tmem_xen.h>
> >  #include <public/sysctl.h>
> > diff --git a/xen/include/xen/tmem.h b/xen/include/xen/tmem.h
> > index 5dbf9d5..2ebffb4 100644
> > --- a/xen/include/xen/tmem.h
> > +++ b/xen/include/xen/tmem.h
> > @@ -9,8 +9,17 @@
> >  #ifndef __XEN_TMEM_H__
> >  #define __XEN_TMEM_H__
> >  
> > +#ifdef HAS_TMEM
> >  extern void tmem_destroy(void *);
> >  extern void *tmem_relinquish_pages(unsigned int, unsigned int);
> >  extern unsigned long tmem_freeable_pages(void);
> > +#else
> > +static inline void tmem_destroy(void *v) {}
> > +static inline void *tmem_relinquish_pages(unsigned int order, unsigned int flags)
> > +{
> > +	return NULL;
> > +}
> > +static inline unsigned long tmem_freeable_pages(void) { return 0; }
> > +#endif
> >  
> >  #endif /* __XEN_TMEM_H__ */
> > diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
> > index fdbeed1..a6c0672 100644
> > --- a/xen/include/xen/tmem_xen.h
> > +++ b/xen/include/xen/tmem_xen.h
> > @@ -9,6 +9,7 @@
> >  #ifndef __XEN_TMEM_XEN_H__
> >  #define __XEN_TMEM_XEN_H__
> >  
> > +#ifdef HAS_TMEM
> >  #include <xen/config.h>
> >  #include <xen/mm.h> /* heap alloc/free */
> >  #include <xen/pfn.h>
> > @@ -559,4 +560,8 @@ extern int tmh_copy_tze_to_client(tmem_cli_mfn_t cmfn, void *tmem_va, pagesize_t
> >  #define RESET_CYC_COUNTER(x) do { } while (0)
> >  #endif
> >  
> > +#else /* HAS_TMEM */
> > +#define opt_tmem 0
> > +#endif
> > +
> >  #endif /* __XEN_TMEM_XEN_H__ */
> > -- 
> > 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 Jan 20 12:30:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDbX-0005eC-9A; Fri, 20 Jan 2012 12:30: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 1RoDbV-0005dj-Gk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:30:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327062595!8575411!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5759 invoked from network); 20 Jan 2012 12:29:55 -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;
	20 Jan 2012 12:29:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:29: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, 20 Jan 2012 12:29:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 12:29:55 +0000
In-Reply-To: <alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327062595.30054.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 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:20 +0000, Stefano Stabellini wrote:
> Could we have a proper stub function or a static inline rather than an
> #define?

I tried that, it would require pulling in more headers etc. This is
really just a stop gap until we implement enough p2m to support pod
properly. I left the real prototypes in the comment for reference.

Ian.


> 
> 
> On Fri, 20 Jan 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/dummy.S      |    2 --
> >  xen/include/asm-arm/mm.h  |    8 ++++++--
> >  xen/include/asm-arm/p2m.h |   11 +++++++----
> >  3 files changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> > index e858613..67edb35 100644
> > --- a/xen/arch/arm/dummy.S
> > +++ b/xen/arch/arm/dummy.S
> > @@ -31,8 +31,6 @@ DUMMY(is_iomem_page);
> >  DUMMY(max_page);
> >  DUMMY(node_online_map);
> >  DUMMY(nr_irqs_gsi);
> > -DUMMY(p2m_pod_decrease_reservation);
> > -DUMMY(guest_physmap_mark_populate_on_demand);
> >  DUMMY(page_get_owner_and_reference);
> >  DUMMY(page_is_ram_type);
> >  DUMMY(per_cpu__cpu_core_mask);
> > diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> > index f721c54..ebe09cf 100644
> > --- a/xen/include/asm-arm/mm.h
> > +++ b/xen/include/asm-arm/mm.h
> > @@ -294,8 +294,12 @@ extern struct domain *dom_xen, *dom_io, *dom_cow;
> >  #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);
> > +/*
> > + * int guest_physmap_mark_populate_on_demand(struct domain *d,
> > + *                                           unsigned long gfn,
> > + *                                           unsigned int order)
> > + */
> > +#define guest_physmap_mark_populate_on_demand(d, gfn, order) -ENOSYS /* No PoD on ARM */
> >  
> >  extern void put_page_type(struct page_info *page);
> >  static inline void put_page_and_type(struct page_info *page)
> > diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> > index aec52f7..723518d 100644
> > --- a/xen/include/asm-arm/p2m.h
> > +++ b/xen/include/asm-arm/p2m.h
> > @@ -48,10 +48,13 @@ unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
> >  
> >  /* 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);
> > + /* No PoD on ARM yet */
> > +/* int
> > + * p2m_pod_decrease_reservation(struct domain *d,
> > + *                              xen_pfn_t gpfn,
> > + *                              unsigned int order);
> > + */
> > +#define p2m_pod_decrease_reservation(d, gpfn, order) -ENOSYS
> >  
> >  /* Compatibility function exporting the old untyped interface */
> >  static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
> > -- 
> > 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 Jan 20 12:30:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:30:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDbX-0005eC-9A; Fri, 20 Jan 2012 12:30: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 1RoDbV-0005dj-Gk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:30:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327062595!8575411!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5759 invoked from network); 20 Jan 2012 12:29:55 -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;
	20 Jan 2012 12:29:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176229"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:29: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, 20 Jan 2012 12:29:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 12:29:55 +0000
In-Reply-To: <alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327062595.30054.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 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:20 +0000, Stefano Stabellini wrote:
> Could we have a proper stub function or a static inline rather than an
> #define?

I tried that, it would require pulling in more headers etc. This is
really just a stop gap until we implement enough p2m to support pod
properly. I left the real prototypes in the comment for reference.

Ian.


> 
> 
> On Fri, 20 Jan 2012, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/arch/arm/dummy.S      |    2 --
> >  xen/include/asm-arm/mm.h  |    8 ++++++--
> >  xen/include/asm-arm/p2m.h |   11 +++++++----
> >  3 files changed, 13 insertions(+), 8 deletions(-)
> > 
> > diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> > index e858613..67edb35 100644
> > --- a/xen/arch/arm/dummy.S
> > +++ b/xen/arch/arm/dummy.S
> > @@ -31,8 +31,6 @@ DUMMY(is_iomem_page);
> >  DUMMY(max_page);
> >  DUMMY(node_online_map);
> >  DUMMY(nr_irqs_gsi);
> > -DUMMY(p2m_pod_decrease_reservation);
> > -DUMMY(guest_physmap_mark_populate_on_demand);
> >  DUMMY(page_get_owner_and_reference);
> >  DUMMY(page_is_ram_type);
> >  DUMMY(per_cpu__cpu_core_mask);
> > diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> > index f721c54..ebe09cf 100644
> > --- a/xen/include/asm-arm/mm.h
> > +++ b/xen/include/asm-arm/mm.h
> > @@ -294,8 +294,12 @@ extern struct domain *dom_xen, *dom_io, *dom_cow;
> >  #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);
> > +/*
> > + * int guest_physmap_mark_populate_on_demand(struct domain *d,
> > + *                                           unsigned long gfn,
> > + *                                           unsigned int order)
> > + */
> > +#define guest_physmap_mark_populate_on_demand(d, gfn, order) -ENOSYS /* No PoD on ARM */
> >  
> >  extern void put_page_type(struct page_info *page);
> >  static inline void put_page_and_type(struct page_info *page)
> > diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> > index aec52f7..723518d 100644
> > --- a/xen/include/asm-arm/p2m.h
> > +++ b/xen/include/asm-arm/p2m.h
> > @@ -48,10 +48,13 @@ unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
> >  
> >  /* 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);
> > + /* No PoD on ARM yet */
> > +/* int
> > + * p2m_pod_decrease_reservation(struct domain *d,
> > + *                              xen_pfn_t gpfn,
> > + *                              unsigned int order);
> > + */
> > +#define p2m_pod_decrease_reservation(d, gpfn, order) -ENOSYS
> >  
> >  /* Compatibility function exporting the old untyped interface */
> >  static inline unsigned long get_gfn_untyped(struct domain *d, unsigned long gpfn)
> > -- 
> > 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 Jan 20 12:32:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDeA-0005vM-Sm; Fri, 20 Jan 2012 12:32: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 1RoDe8-0005sy-MH
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:32:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327062757!11882964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15186 invoked from network); 20 Jan 2012 12:32:38 -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;
	20 Jan 2012 12:32:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:32:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 12:32:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 12:32:10 +0000
In-Reply-To: <alpine.DEB.2.00.1201201221090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327059202.30054.3.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201201221090.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327062730.30054.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/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:24 +0000, Stefano Stabellini wrote:
> On Fri, 20 Jan 2012, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> > > diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> > > index a6bb894..3d11c39 100644
> > > --- a/tools/libxc/xc_domain_save.c
> > > +++ b/tools/libxc/xc_domain_save.c
> > > @@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> > >          }
> > >      }
> > > 
> > > +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> > > +    {
> > > +        int id = XC_SAVE_ID_TOOLSTACK;
> > > +        uint8_t *buf;
> > > +        uint32_t len;
> > > +
> > > +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> > > +        {
> > > +            PERROR("Error calling toolstack_save");
> > > +            goto out;
> > > +        }
> > > +        wrexact(io_fd, &id, sizeof(id));
> > > +        wrexact(io_fd, &len, sizeof(len));
> > > +        wrexact(io_fd, buf, len);
> > 
> > Where is buf free'd? You say below "callee allocates and frees the
> > buffer" but there is no way that can be the case since the caller uses
> > the buffer after the callback.
> 
> The callee can free the buffer after the completion of xc_domain_save.
> So libxl allocates the buffer in toolstack_save and frees it after
> xc_domain_save returns.
> 
> 
> > I think it has to be callee-alloc, caller-free (perhaps callee-free on
> > error).
> 
> I though that it is more straightforward if the callee does both, but if
> you think that is actually more confusing, I'll change it.

Well, it enforces that the caller has some sort of infrastructure (like
gc) which they may not have. I suppose they could have a little struct
passed via the closure where they stash the allocation to free after
xc_domain_save but I'd contend that this is even weirder/more confusing
than doing caller-free -- you just don't see this because libxl's gc
hides it from you.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:32:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDeA-0005vM-Sm; Fri, 20 Jan 2012 12:32: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 1RoDe8-0005sy-MH
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:32:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327062757!11882964!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15186 invoked from network); 20 Jan 2012 12:32:38 -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;
	20 Jan 2012 12:32:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176276"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:32:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 12:32:10 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 20 Jan 2012 12:32:10 +0000
In-Reply-To: <alpine.DEB.2.00.1201201221090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327059202.30054.3.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201201221090.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327062730.30054.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/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:24 +0000, Stefano Stabellini wrote:
> On Fri, 20 Jan 2012, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> > > diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> > > index a6bb894..3d11c39 100644
> > > --- a/tools/libxc/xc_domain_save.c
> > > +++ b/tools/libxc/xc_domain_save.c
> > > @@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> > >          }
> > >      }
> > > 
> > > +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> > > +    {
> > > +        int id = XC_SAVE_ID_TOOLSTACK;
> > > +        uint8_t *buf;
> > > +        uint32_t len;
> > > +
> > > +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> > > +        {
> > > +            PERROR("Error calling toolstack_save");
> > > +            goto out;
> > > +        }
> > > +        wrexact(io_fd, &id, sizeof(id));
> > > +        wrexact(io_fd, &len, sizeof(len));
> > > +        wrexact(io_fd, buf, len);
> > 
> > Where is buf free'd? You say below "callee allocates and frees the
> > buffer" but there is no way that can be the case since the caller uses
> > the buffer after the callback.
> 
> The callee can free the buffer after the completion of xc_domain_save.
> So libxl allocates the buffer in toolstack_save and frees it after
> xc_domain_save returns.
> 
> 
> > I think it has to be callee-alloc, caller-free (perhaps callee-free on
> > error).
> 
> I though that it is more straightforward if the callee does both, but if
> you think that is actually more confusing, I'll change it.

Well, it enforces that the caller has some sort of infrastructure (like
gc) which they may not have. I suppose they could have a little struct
passed via the closure where they stash the allocation to free after
xc_domain_save but I'd contend that this is even weirder/more confusing
than doing caller-free -- you just don't see this because libxl's gc
hides it from you.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:33:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDeb-000612-9z; Fri, 20 Jan 2012 12:33: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 1RoDeZ-0005za-W2
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:33:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327062785!7898779!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 10882 invoked from network); 20 Jan 2012 12:33:06 -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; 20 Jan 2012 12:33:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:33:05 +0000
Message-Id: <4F196D53020000780006DEE9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:34:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <dan.magenheimer@oracle.com>,"Tim Deegan" <tim@xen.org>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<20120120122517.GB97313@ocelot.phlegethon.org>
In-Reply-To: <20120120122517.GB97313@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:25, Tim Deegan <tim@xen.org> wrote:
> At 12:19 +0000 on 20 Jan (1327061942), Stefano Stabellini wrote:
>> Why do we need this?
>> I though that tmem compiled OK on ARM. Also I don't think there is any
>> architectural limitation that would prevent tmem from working on ARM,
>> right?
> 
> It may compile but it surely won't work. :)  Does tmem work at all for
> non-PV guests?

Supposedly yes, otherwise it wouldn't be wired up in the HVM
hypercall tables. Dan?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:33:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:33:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDeb-000612-9z; Fri, 20 Jan 2012 12:33: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 1RoDeZ-0005za-W2
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:33:12 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327062785!7898779!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 10882 invoked from network); 20 Jan 2012 12:33:06 -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; 20 Jan 2012 12:33:06 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:33:05 +0000
Message-Id: <4F196D53020000780006DEE9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:34:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <dan.magenheimer@oracle.com>,"Tim Deegan" <tim@xen.org>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<20120120122517.GB97313@ocelot.phlegethon.org>
In-Reply-To: <20120120122517.GB97313@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:25, Tim Deegan <tim@xen.org> wrote:
> At 12:19 +0000 on 20 Jan (1327061942), Stefano Stabellini wrote:
>> Why do we need this?
>> I though that tmem compiled OK on ARM. Also I don't think there is any
>> architectural limitation that would prevent tmem from working on ARM,
>> right?
> 
> It may compile but it surely won't work. :)  Does tmem work at all for
> non-PV guests?

Supposedly yes, otherwise it wouldn't be wired up in the HVM
hypercall tables. Dan?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:33:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:33:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDeh-000632-SY; Fri, 20 Jan 2012 12:33: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 1RoDeg-000610-Bd
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:33:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327062792!11680324!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6188 invoked from network); 20 Jan 2012 12:33:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:33:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:33: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;
	Fri, 20 Jan 2012 12:33:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 12:33:07 +0000
In-Reply-To: <1327061083.2337.42.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327062788.30054.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:04 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 11:54 +0000, Ian Campbell wrote: 

> > > Of course, even in such mode, if the user explicitly tells us what he
> > > wants, e.g., by means of cpupools, pinning, etc., we should still honour
> > > such request.
> > 
> > Do we get this right now?
> > 
> Sorry, not sure what you mean here...

I meant is "if the user explicitly tells us what he wants, e.g., by
means of cpupools, pinning, etc." do we still honour such request?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:33:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:33:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDeh-000632-SY; Fri, 20 Jan 2012 12:33: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 1RoDeg-000610-Bd
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:33:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327062792!11680324!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6188 invoked from network); 20 Jan 2012 12:33:12 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:33:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176307"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:33: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;
	Fri, 20 Jan 2012 12:33:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 12:33:07 +0000
In-Reply-To: <1327061083.2337.42.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327062788.30054.31.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:04 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 11:54 +0000, Ian Campbell wrote: 

> > > Of course, even in such mode, if the user explicitly tells us what he
> > > wants, e.g., by means of cpupools, pinning, etc., we should still honour
> > > such request.
> > 
> > Do we get this right now?
> > 
> Sorry, not sure what you mean here...

I meant is "if the user explicitly tells us what he wants, e.g., by
means of cpupools, pinning, etc." do we still honour such request?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:36:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDhQ-0006wb-KD; Fri, 20 Jan 2012 12:36:08 +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 1RoDhO-0006vM-EY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:36:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327062960!11862701!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 22087 invoked from network); 20 Jan 2012 12:36:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 12:36:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RoDhG-000Q0a-Hx; Fri, 20 Jan 2012 12:35:58 +0000
Date: Fri, 20 Jan 2012 12:35:58 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120120123558.GC97313@ocelot.phlegethon.org>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
	<1327062595.30054.28.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327062595.30054.28.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:29 +0000 on 20 Jan (1327062595), Ian Campbell wrote:
> On Fri, 2012-01-20 at 12:20 +0000, Stefano Stabellini wrote:
> > Could we have a proper stub function or a static inline rather than an
> > #define?
> 
> I tried that, it would require pulling in more headers etc. This is
> really just a stop gap until we implement enough p2m to support pod
> properly. I left the real prototypes in the comment for reference.

We could just as easily have 

static inline int 
guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
                                      unsigned int order)
{
    return -ENOSYS;
}

&c, for no extra effort (and for the same effect).  A matter of style is
all. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:36:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDhQ-0006wb-KD; Fri, 20 Jan 2012 12:36:08 +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 1RoDhO-0006vM-EY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:36:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327062960!11862701!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 22087 invoked from network); 20 Jan 2012 12:36:00 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 12:36:00 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RoDhG-000Q0a-Hx; Fri, 20 Jan 2012 12:35:58 +0000
Date: Fri, 20 Jan 2012 12:35:58 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120120123558.GC97313@ocelot.phlegethon.org>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
	<1327062595.30054.28.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327062595.30054.28.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:29 +0000 on 20 Jan (1327062595), Ian Campbell wrote:
> On Fri, 2012-01-20 at 12:20 +0000, Stefano Stabellini wrote:
> > Could we have a proper stub function or a static inline rather than an
> > #define?
> 
> I tried that, it would require pulling in more headers etc. This is
> really just a stop gap until we implement enough p2m to support pod
> properly. I left the real prototypes in the comment for reference.

We could just as easily have 

static inline int 
guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
                                      unsigned int order)
{
    return -ENOSYS;
}

&c, for no extra effort (and for the same effect).  A matter of style is
all. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:36:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDhZ-0006yX-0P; Fri, 20 Jan 2012 12:36:17 +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 1RoDhX-0006wt-Gk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:36:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327062968!1890442!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 19115 invoked from network); 20 Jan 2012 12:36:09 -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; 20 Jan 2012 12:36:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:36:08 +0000
Message-Id: <4F196DDC020000780006DEEC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:36:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<1327062518.30054.26.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327062518.30054.26.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] [PATCH 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-01-20 at 12:19 +0000, Stefano Stabellini wrote:
>> Why do we need this?
>> I though that tmem compiled OK on ARM.
> 
> But it can't possibly work, as evidenced by the missing symbol in
> dummy.S! There is no point in compiling something which cannot work.

But introducing random HAS_xyz variables isn't that pretty either. The
more that the term 'has' seems wrong to me in this case.

By just not wiring up the hypercall you could achieve the same effect.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:36:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDhZ-0006yX-0P; Fri, 20 Jan 2012 12:36:17 +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 1RoDhX-0006wt-Gk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:36:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327062968!1890442!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 19115 invoked from network); 20 Jan 2012 12:36:09 -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; 20 Jan 2012 12:36:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:36:08 +0000
Message-Id: <4F196DDC020000780006DEEC@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:36:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<1327062518.30054.26.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327062518.30054.26.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] [PATCH 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-01-20 at 12:19 +0000, Stefano Stabellini wrote:
>> Why do we need this?
>> I though that tmem compiled OK on ARM.
> 
> But it can't possibly work, as evidenced by the missing symbol in
> dummy.S! There is no point in compiling something which cannot work.

But introducing random HAS_xyz variables isn't that pretty either. The
more that the term 'has' seems wrong to me in this case.

By just not wiring up the hypercall you could achieve the same effect.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:38:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDj7-0007Ae-GY; Fri, 20 Jan 2012 12:37:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RoDj6-0007A8-0J
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:37:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327063065!1890746!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 25231 invoked from network); 20 Jan 2012 12:37:45 -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; 20 Jan 2012 12:37:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:37:45 +0000
Message-Id: <4F196E6A020000780006DF19@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:38:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 09/12] xen: only map PV guest grants via
 iommu if HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:06, Ian Campbell <ian.campbell@citrix.com> wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/Rules.mk             |    1 +
>  xen/arch/arm/dummy.S     |    2 --
>  xen/common/grant_table.c |    6 ++++++
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index e25e8d4..ce88316 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -52,6 +52,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>  CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
> +CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
>  ifneq ($(max_phys_cpus),)
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 5010619..e858613 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
>  DUMMY(gnttab_clear_flag);
>  DUMMY(gnttab_mark_dirty);
>  DUMMY(hypercall_create_continuation);
> -DUMMY(iommu_map_page);
> -DUMMY(iommu_unmap_page);
>  DUMMY(is_iomem_page);
>  DUMMY(max_page);
>  DUMMY(node_online_map);
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index b024016..1798fcd 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -434,6 +434,7 @@ static int _set_status(unsigned gt_version,
>          return _set_status_v2(domid, readonly, mapflag, shah, act, status);
>  }
>  
> +#ifdef HAS_PASSTHROUGH
>  static void mapcount(
>      struct domain *ld, unsigned long mfn,
>      unsigned int *wrc, unsigned int *rdc)
> @@ -456,6 +457,7 @@ static void mapcount(
>          rcu_unlock_domain(rd);
>      }
>  }
> +#endif
>  
>  /*
>   * Returns 0 if TLB flush / invalidate required by caller.
> @@ -662,6 +664,7 @@ __gnttab_map_grant_ref(
>          goto undo_out;
>      }
>  
> +#ifdef HAS_PASSTHROUGH
>      if ( !is_hvm_domain(ld) && need_iommu(ld) )

Wouldn't #define-ing need_iommu() to 0 in the ARM headers achieve
the same effect, without cluttering common code?

Jan

>      {
>          unsigned int wrc, rdc;
> @@ -689,6 +692,7 @@ __gnttab_map_grant_ref(
>              goto undo_out;
>          }
>      }
> +#endif
>  
>      TRACE_1D(TRC_MEM_PAGE_GRANT_MAP, op->dom);
>  
> @@ -858,6 +862,7 @@ __gnttab_unmap_common(
>              act->pin -= GNTPIN_hstw_inc;
>      }
>  
> +#ifdef HAS_PASSTHROUGH
>      if ( !is_hvm_domain(ld) && need_iommu(ld) )
>      {
>          unsigned int wrc, rdc;
> @@ -874,6 +879,7 @@ __gnttab_unmap_common(
>              goto unmap_out;
>          }
>      }
> +#endif
>  
>      /* If just unmapped a writable mapping, mark as dirtied */
>      if ( !(op->flags & GNTMAP_readonly) )
> -- 
> 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 Jan 20 12:38:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDj7-0007Ae-GY; Fri, 20 Jan 2012 12:37:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RoDj6-0007A8-0J
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:37:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327063065!1890746!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 25231 invoked from network); 20 Jan 2012 12:37:45 -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; 20 Jan 2012 12:37:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:37:45 +0000
Message-Id: <4F196E6A020000780006DF19@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:38:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <ian.campbell@citrix.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
In-Reply-To: <1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 09/12] xen: only map PV guest grants via
 iommu if HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:06, Ian Campbell <ian.campbell@citrix.com> wrote:
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  xen/Rules.mk             |    1 +
>  xen/arch/arm/dummy.S     |    2 --
>  xen/common/grant_table.c |    6 ++++++
>  3 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index e25e8d4..ce88316 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -52,6 +52,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>  CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
> +CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>  
>  ifneq ($(max_phys_cpus),)
> diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> index 5010619..e858613 100644
> --- a/xen/arch/arm/dummy.S
> +++ b/xen/arch/arm/dummy.S
> @@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
>  DUMMY(gnttab_clear_flag);
>  DUMMY(gnttab_mark_dirty);
>  DUMMY(hypercall_create_continuation);
> -DUMMY(iommu_map_page);
> -DUMMY(iommu_unmap_page);
>  DUMMY(is_iomem_page);
>  DUMMY(max_page);
>  DUMMY(node_online_map);
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index b024016..1798fcd 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -434,6 +434,7 @@ static int _set_status(unsigned gt_version,
>          return _set_status_v2(domid, readonly, mapflag, shah, act, status);
>  }
>  
> +#ifdef HAS_PASSTHROUGH
>  static void mapcount(
>      struct domain *ld, unsigned long mfn,
>      unsigned int *wrc, unsigned int *rdc)
> @@ -456,6 +457,7 @@ static void mapcount(
>          rcu_unlock_domain(rd);
>      }
>  }
> +#endif
>  
>  /*
>   * Returns 0 if TLB flush / invalidate required by caller.
> @@ -662,6 +664,7 @@ __gnttab_map_grant_ref(
>          goto undo_out;
>      }
>  
> +#ifdef HAS_PASSTHROUGH
>      if ( !is_hvm_domain(ld) && need_iommu(ld) )

Wouldn't #define-ing need_iommu() to 0 in the ARM headers achieve
the same effect, without cluttering common code?

Jan

>      {
>          unsigned int wrc, rdc;
> @@ -689,6 +692,7 @@ __gnttab_map_grant_ref(
>              goto undo_out;
>          }
>      }
> +#endif
>  
>      TRACE_1D(TRC_MEM_PAGE_GRANT_MAP, op->dom);
>  
> @@ -858,6 +862,7 @@ __gnttab_unmap_common(
>              act->pin -= GNTPIN_hstw_inc;
>      }
>  
> +#ifdef HAS_PASSTHROUGH
>      if ( !is_hvm_domain(ld) && need_iommu(ld) )
>      {
>          unsigned int wrc, rdc;
> @@ -874,6 +879,7 @@ __gnttab_unmap_common(
>              goto unmap_out;
>          }
>      }
> +#endif
>  
>      /* If just unmapped a writable mapping, mark as dirtied */
>      if ( !(op->flags & GNTMAP_readonly) )
> -- 
> 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 Jan 20 12:39:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDkh-0007OQ-1L; Fri, 20 Jan 2012 12:39: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 1RoDkf-0007OD-HS
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:39:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327063140!56535268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14885 invoked from network); 20 Jan 2012 12:39:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:39:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:39: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;
	Fri, 20 Jan 2012 12:39:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 20 Jan 2012 12:39:24 +0000
In-Reply-To: <4F196DDC020000780006DEEC@nat28.tlf.novell.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<1327062518.30054.26.camel@zakaz.uk.xensource.com>
	<4F196DDC020000780006DEEC@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327063164.30054.32.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 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:36 +0000, Jan Beulich wrote:
> >>> On 20.01.12 at 13:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-01-20 at 12:19 +0000, Stefano Stabellini wrote:
> >> Why do we need this?
> >> I though that tmem compiled OK on ARM.
> > 
> > But it can't possibly work, as evidenced by the missing symbol in
> > dummy.S! There is no point in compiling something which cannot work.
> 
> But introducing random HAS_xyz variables isn't that pretty either. The
> more that the term 'has' seems wrong to me in this case.

yeah, I was copy the other similar variables. Probably ENABLE would be
better in this case.

> By just not wiring up the hypercall you could achieve the same effect.

Really? I'd still need to ifdef out the hypercall body or I'd get
unresolved symbols, wouldn't I?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:39:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:39:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDkh-0007OQ-1L; Fri, 20 Jan 2012 12:39: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 1RoDkf-0007OD-HS
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:39:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327063140!56535268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14885 invoked from network); 20 Jan 2012 12:39:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:39:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:39: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;
	Fri, 20 Jan 2012 12:39:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 20 Jan 2012 12:39:24 +0000
In-Reply-To: <4F196DDC020000780006DEEC@nat28.tlf.novell.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<1327062518.30054.26.camel@zakaz.uk.xensource.com>
	<4F196DDC020000780006DEEC@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327063164.30054.32.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 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:36 +0000, Jan Beulich wrote:
> >>> On 20.01.12 at 13:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Fri, 2012-01-20 at 12:19 +0000, Stefano Stabellini wrote:
> >> Why do we need this?
> >> I though that tmem compiled OK on ARM.
> > 
> > But it can't possibly work, as evidenced by the missing symbol in
> > dummy.S! There is no point in compiling something which cannot work.
> 
> But introducing random HAS_xyz variables isn't that pretty either. The
> more that the term 'has' seems wrong to me in this case.

yeah, I was copy the other similar variables. Probably ENABLE would be
better in this case.

> By just not wiring up the hypercall you could achieve the same effect.

Really? I'd still need to ifdef out the hypercall body or I'd get
unresolved symbols, wouldn't I?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:39:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDkj-0007Oz-Du; Fri, 20 Jan 2012 12:39:33 +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 1RoDki-0007Oa-0R
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:39:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327063124!49409139!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 1738 invoked from network); 20 Jan 2012 12:38:44 -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; 20 Jan 2012 12:38:44 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RoDkf-00002R-Qf; Fri, 20 Jan 2012 12:39:29 +0000
Date: Fri, 20 Jan 2012 12:39:29 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120120123929.GD97313@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327059202.30054.3.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201201221090.3196@kaball-desktop>
	<1327062730.30054.30.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327062730.30054.30.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:32 +0000 on 20 Jan (1327062730), Ian Campbell wrote:
> On Fri, 2012-01-20 at 12:24 +0000, Stefano Stabellini wrote:
> > On Fri, 20 Jan 2012, Ian Campbell wrote:
> > > On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> > > > diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> > > > index a6bb894..3d11c39 100644
> > > > --- a/tools/libxc/xc_domain_save.c
> > > > +++ b/tools/libxc/xc_domain_save.c
> > > > @@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> > > >          }
> > > >      }
> > > > 
> > > > +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> > > > +    {
> > > > +        int id = XC_SAVE_ID_TOOLSTACK;
> > > > +        uint8_t *buf;
> > > > +        uint32_t len;
> > > > +
> > > > +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> > > > +        {
> > > > +            PERROR("Error calling toolstack_save");
> > > > +            goto out;
> > > > +        }
> > > > +        wrexact(io_fd, &id, sizeof(id));
> > > > +        wrexact(io_fd, &len, sizeof(len));
> > > > +        wrexact(io_fd, buf, len);
> > > 
> > > Where is buf free'd? You say below "callee allocates and frees the
> > > buffer" but there is no way that can be the case since the caller uses
> > > the buffer after the callback.
> > 
> > The callee can free the buffer after the completion of xc_domain_save.
> > So libxl allocates the buffer in toolstack_save and frees it after
> > xc_domain_save returns.
> > 
> > 
> > > I think it has to be callee-alloc, caller-free (perhaps callee-free on
> > > error).
> > 
> > I though that it is more straightforward if the callee does both, but if
> > you think that is actually more confusing, I'll change it.
> 
> Well, it enforces that the caller has some sort of infrastructure (like
> gc) which they may not have. I suppose they could have a little struct
> passed via the closure where they stash the allocation to free after
> xc_domain_save but I'd contend that this is even weirder/more confusing
> than doing caller-free -- you just don't see this because libxl's gc
> hides it from you.

Other idioms for this sort of thing include having two callbacks, the
first of which returns the size (erk), or two callbacks, one just for
freeing the pointer (meh).  On *NIx, requring that the callback return a
pointer suitable for free()ing is OK, I think.  On Windows that kind of
thing can be a real PITA, trying to be sure that both sides have the
same heap.   But maybe that's a bridge better crossed when we come to
it. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:39:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:39:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDkj-0007Oz-Du; Fri, 20 Jan 2012 12:39:33 +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 1RoDki-0007Oa-0R
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:39:32 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327063124!49409139!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 1738 invoked from network); 20 Jan 2012 12:38:44 -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; 20 Jan 2012 12:38:44 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RoDkf-00002R-Qf; Fri, 20 Jan 2012 12:39:29 +0000
Date: Fri, 20 Jan 2012 12:39:29 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120120123929.GD97313@ocelot.phlegethon.org>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327059202.30054.3.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201201221090.3196@kaball-desktop>
	<1327062730.30054.30.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327062730.30054.30.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 12:32 +0000 on 20 Jan (1327062730), Ian Campbell wrote:
> On Fri, 2012-01-20 at 12:24 +0000, Stefano Stabellini wrote:
> > On Fri, 20 Jan 2012, Ian Campbell wrote:
> > > On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> > > > diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> > > > index a6bb894..3d11c39 100644
> > > > --- a/tools/libxc/xc_domain_save.c
> > > > +++ b/tools/libxc/xc_domain_save.c
> > > > @@ -1676,6 +1676,22 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
> > > >          }
> > > >      }
> > > > 
> > > > +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> > > > +    {
> > > > +        int id = XC_SAVE_ID_TOOLSTACK;
> > > > +        uint8_t *buf;
> > > > +        uint32_t len;
> > > > +
> > > > +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
> > > > +        {
> > > > +            PERROR("Error calling toolstack_save");
> > > > +            goto out;
> > > > +        }
> > > > +        wrexact(io_fd, &id, sizeof(id));
> > > > +        wrexact(io_fd, &len, sizeof(len));
> > > > +        wrexact(io_fd, buf, len);
> > > 
> > > Where is buf free'd? You say below "callee allocates and frees the
> > > buffer" but there is no way that can be the case since the caller uses
> > > the buffer after the callback.
> > 
> > The callee can free the buffer after the completion of xc_domain_save.
> > So libxl allocates the buffer in toolstack_save and frees it after
> > xc_domain_save returns.
> > 
> > 
> > > I think it has to be callee-alloc, caller-free (perhaps callee-free on
> > > error).
> > 
> > I though that it is more straightforward if the callee does both, but if
> > you think that is actually more confusing, I'll change it.
> 
> Well, it enforces that the caller has some sort of infrastructure (like
> gc) which they may not have. I suppose they could have a little struct
> passed via the closure where they stash the allocation to free after
> xc_domain_save but I'd contend that this is even weirder/more confusing
> than doing caller-free -- you just don't see this because libxl's gc
> hides it from you.

Other idioms for this sort of thing include having two callbacks, the
first of which returns the size (erk), or two callbacks, one just for
freeing the pointer (meh).  On *NIx, requring that the callback return a
pointer suitable for free()ing is OK, I think.  On Windows that kind of
thing can be a real PITA, trying to be sure that both sides have the
same heap.   But maybe that's a bridge better crossed when we come to
it. 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:40:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDlb-0007Zp-TY; Fri, 20 Jan 2012 12:40:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RoDla-0007Yc-B0
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:40:26 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327063219!9988124!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNjEyNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30174 invoked from network); 20 Jan 2012 12:40:20 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:40:20 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=UMDjL0CahaIuFUlNVNEYlCn1qikg6XxlTzB62IUGvJmQjMhjodyhlVJe
	/OxXO5sD9zZ131d8M6ef1/f4JU+QORWCJAVQ9ZhrHHa9BLxrud10OPGx0
	gIi1YNJEvljd2L08cy2C+KaTcIjFRW6mdmiVaUKHpQ2cDYx9mf/xS4iTl
	urCHPdXfZyzOI9/6onhASu7MifvAyL9tgu8GIcwPGQy7DOvNZ1idYIsf4
	dl7fhLzXziau/V5VATASSFONagG4G;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1327063220; x=1358599220;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=gU0PbRWDs8+Qe4WeL30Mz8X6aaNImOku52RlMfrdaIo=;
	b=M9kUW8QIzHfmLDKpydasYQwB0l9AFc4+92qnlurj9TN2MoVzOC5E+THz
	g/2V/2V0+t4T9FfO37nfMrmDUvMQYC68K7dDimG5pS7XejYXGqPYzYrR5
	xQv3rw4ndgo4TG4z9nR9sdRNLCfh2i5JarueuYj2Jj0gxnY6HpEdsXpBW
	tqSFdye1oj14Dox8IMdYGtjWexXxrK1RQ103vtvX31GqCeGx3NqLKrQWq
	KqCQcISxf3SLM/Mt8vpY80F7ZAN+p;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="99245392"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 20 Jan 2012 13:40:19 +0100
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="127459838"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 20 Jan 2012 13:40:20 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 4F71395FCE2;
	Fri, 20 Jan 2012 13:40:19 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 20 Jan 2012 13:40:19 +0100
Message-ID: <1375017.thPP8t1FNn@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CB3EF874.37D58%keir@xen.org>
References: <CB3EF874.37D58%keir@xen.org>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian,

Am Freitag 20 Januar 2012, 10:54:44 schrieb Keir Fraser:
> On 20/01/2012 10:49, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> 
> >> Our CPUID configuration is done per-domain, and from
> >> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
> >> hypervisor are generally not acceptable without very good reason.
> > 
> > Then a way is needed to have access to the opt_vpmu_enabled variable within
> > the
> > hypervisor from the tools to decide the enabling of the flag (is there such a
> > way?) or the mechanism with the boot variable must be changed.
> > The opt_vpmu_enabled boot variable was introduced because of a PMU problem in
> > the Nehalem cpus leading sometimes to hypervisor crashes. But with the done
> > quirk we never had a crash anymore.
> > So maybe we can always switch on the vpmu stuff in the hypervisor and add a
> > flag in the domain configuration when somebody wants to do some performance
> > tests?
> 
> Yes!
> 
> It's obviously an option of fairly narrow interest. If someone tries to
> enable the per-domain option on a CPU which has problems, you can fail the
> domain creation, or print a warning in the hypervisor log, or whatever. Any
> sensible option in that respect is fine by me!

What is the best solution for this?
A domain specific configuration option is needed (vpmu?) which is usable in
libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid command.
Can you point me to an proper example?
Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:40:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDlb-0007Zp-TY; Fri, 20 Jan 2012 12:40:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RoDla-0007Yc-B0
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:40:26 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327063219!9988124!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNjEyNw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30174 invoked from network); 20 Jan 2012 12:40:20 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:40:20 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=UMDjL0CahaIuFUlNVNEYlCn1qikg6XxlTzB62IUGvJmQjMhjodyhlVJe
	/OxXO5sD9zZ131d8M6ef1/f4JU+QORWCJAVQ9ZhrHHa9BLxrud10OPGx0
	gIi1YNJEvljd2L08cy2C+KaTcIjFRW6mdmiVaUKHpQ2cDYx9mf/xS4iTl
	urCHPdXfZyzOI9/6onhASu7MifvAyL9tgu8GIcwPGQy7DOvNZ1idYIsf4
	dl7fhLzXziau/V5VATASSFONagG4G;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1327063220; x=1358599220;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=gU0PbRWDs8+Qe4WeL30Mz8X6aaNImOku52RlMfrdaIo=;
	b=M9kUW8QIzHfmLDKpydasYQwB0l9AFc4+92qnlurj9TN2MoVzOC5E+THz
	g/2V/2V0+t4T9FfO37nfMrmDUvMQYC68K7dDimG5pS7XejYXGqPYzYrR5
	xQv3rw4ndgo4TG4z9nR9sdRNLCfh2i5JarueuYj2Jj0gxnY6HpEdsXpBW
	tqSFdye1oj14Dox8IMdYGtjWexXxrK1RQ103vtvX31GqCeGx3NqLKrQWq
	KqCQcISxf3SLM/Mt8vpY80F7ZAN+p;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="99245392"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 20 Jan 2012 13:40:19 +0100
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="127459838"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 20 Jan 2012 13:40:20 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 4F71395FCE2;
	Fri, 20 Jan 2012 13:40:19 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 20 Jan 2012 13:40:19 +0100
Message-ID: <1375017.thPP8t1FNn@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CB3EF874.37D58%keir@xen.org>
References: <CB3EF874.37D58%keir@xen.org>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian,

Am Freitag 20 Januar 2012, 10:54:44 schrieb Keir Fraser:
> On 20/01/2012 10:49, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> 
> >> Our CPUID configuration is done per-domain, and from
> >> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
> >> hypervisor are generally not acceptable without very good reason.
> > 
> > Then a way is needed to have access to the opt_vpmu_enabled variable within
> > the
> > hypervisor from the tools to decide the enabling of the flag (is there such a
> > way?) or the mechanism with the boot variable must be changed.
> > The opt_vpmu_enabled boot variable was introduced because of a PMU problem in
> > the Nehalem cpus leading sometimes to hypervisor crashes. But with the done
> > quirk we never had a crash anymore.
> > So maybe we can always switch on the vpmu stuff in the hypervisor and add a
> > flag in the domain configuration when somebody wants to do some performance
> > tests?
> 
> Yes!
> 
> It's obviously an option of fairly narrow interest. If someone tries to
> enable the per-domain option on a CPU which has problems, you can fail the
> domain creation, or print a warning in the hypervisor log, or whatever. Any
> sensible option in that respect is fine by me!

What is the best solution for this?
A domain specific configuration option is needed (vpmu?) which is usable in
libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid command.
Can you point me to an proper example?
Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:40:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDld-0007aC-9b; Fri, 20 Jan 2012 12: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 1RoDla-0007Yn-V6
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:40:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327063180!56790278!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 572 invoked from network); 20 Jan 2012 12:39:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:39:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176496"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:40:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 12:40:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 20 Jan 2012 12:40:20 +0000
In-Reply-To: <4F196E6A020000780006DF19@nat28.tlf.novell.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
	<4F196E6A020000780006DF19@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327063220.30054.33.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 09/12] xen: only map PV guest grants via
 iommu if HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:38 +0000, Jan Beulich wrote:
> >>> On 20.01.12 at 13:06, Ian Campbell <ian.campbell@citrix.com> wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/Rules.mk             |    1 +
> >  xen/arch/arm/dummy.S     |    2 --
> >  xen/common/grant_table.c |    6 ++++++
> >  3 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index e25e8d4..ce88316 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -52,6 +52,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
> >  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> >  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> >  CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
> > +CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
> >  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
> >  
> >  ifneq ($(max_phys_cpus),)
> > diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> > index 5010619..e858613 100644
> > --- a/xen/arch/arm/dummy.S
> > +++ b/xen/arch/arm/dummy.S
> > @@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
> >  DUMMY(gnttab_clear_flag);
> >  DUMMY(gnttab_mark_dirty);
> >  DUMMY(hypercall_create_continuation);
> > -DUMMY(iommu_map_page);
> > -DUMMY(iommu_unmap_page);
> >  DUMMY(is_iomem_page);
> >  DUMMY(max_page);
> >  DUMMY(node_online_map);
> > diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> > index b024016..1798fcd 100644
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -434,6 +434,7 @@ static int _set_status(unsigned gt_version,
> >          return _set_status_v2(domid, readonly, mapflag, shah, act, status);
> >  }
> >  
> > +#ifdef HAS_PASSTHROUGH
> >  static void mapcount(
> >      struct domain *ld, unsigned long mfn,
> >      unsigned int *wrc, unsigned int *rdc)
> > @@ -456,6 +457,7 @@ static void mapcount(
> >          rcu_unlock_domain(rd);
> >      }
> >  }
> > +#endif
> >  
> >  /*
> >   * Returns 0 if TLB flush / invalidate required by caller.
> > @@ -662,6 +664,7 @@ __gnttab_map_grant_ref(
> >          goto undo_out;
> >      }
> >  
> > +#ifdef HAS_PASSTHROUGH
> >      if ( !is_hvm_domain(ld) && need_iommu(ld) )
> 
> Wouldn't #define-ing need_iommu() to 0 in the ARM headers achieve
> the same effect, without cluttering common code?

Yes. I'd thought there were other uses of need_iommu but in fact they
are all in x86.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:40:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:40:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDld-0007aC-9b; Fri, 20 Jan 2012 12: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 1RoDla-0007Yn-V6
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:40:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327063180!56790278!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 572 invoked from network); 20 Jan 2012 12:39:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:39:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176496"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:40:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 12:40:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Fri, 20 Jan 2012 12:40:20 +0000
In-Reply-To: <4F196E6A020000780006DF19@nat28.tlf.novell.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
	<4F196E6A020000780006DF19@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327063220.30054.33.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 09/12] xen: only map PV guest grants via
 iommu if HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:38 +0000, Jan Beulich wrote:
> >>> On 20.01.12 at 13:06, Ian Campbell <ian.campbell@citrix.com> wrote:
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  xen/Rules.mk             |    1 +
> >  xen/arch/arm/dummy.S     |    2 --
> >  xen/common/grant_table.c |    6 ++++++
> >  3 files changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index e25e8d4..ce88316 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -52,6 +52,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
> >  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> >  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
> >  CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
> > +CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
> >  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
> >  
> >  ifneq ($(max_phys_cpus),)
> > diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
> > index 5010619..e858613 100644
> > --- a/xen/arch/arm/dummy.S
> > +++ b/xen/arch/arm/dummy.S
> > @@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
> >  DUMMY(gnttab_clear_flag);
> >  DUMMY(gnttab_mark_dirty);
> >  DUMMY(hypercall_create_continuation);
> > -DUMMY(iommu_map_page);
> > -DUMMY(iommu_unmap_page);
> >  DUMMY(is_iomem_page);
> >  DUMMY(max_page);
> >  DUMMY(node_online_map);
> > diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> > index b024016..1798fcd 100644
> > --- a/xen/common/grant_table.c
> > +++ b/xen/common/grant_table.c
> > @@ -434,6 +434,7 @@ static int _set_status(unsigned gt_version,
> >          return _set_status_v2(domid, readonly, mapflag, shah, act, status);
> >  }
> >  
> > +#ifdef HAS_PASSTHROUGH
> >  static void mapcount(
> >      struct domain *ld, unsigned long mfn,
> >      unsigned int *wrc, unsigned int *rdc)
> > @@ -456,6 +457,7 @@ static void mapcount(
> >          rcu_unlock_domain(rd);
> >      }
> >  }
> > +#endif
> >  
> >  /*
> >   * Returns 0 if TLB flush / invalidate required by caller.
> > @@ -662,6 +664,7 @@ __gnttab_map_grant_ref(
> >          goto undo_out;
> >      }
> >  
> > +#ifdef HAS_PASSTHROUGH
> >      if ( !is_hvm_domain(ld) && need_iommu(ld) )
> 
> Wouldn't #define-ing need_iommu() to 0 in the ARM headers achieve
> the same effect, without cluttering common code?

Yes. I'd thought there were other uses of need_iommu but in fact they
are all in x86.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:41:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDmA-0007j5-Tw; Fri, 20 Jan 2012 12:41:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoDm9-0007hx-0L
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:41:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327063236!63281901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10285 invoked from network); 20 Jan 2012 12:40:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:40: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, 20 Jan 2012 12:40:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 20 Jan 2012 12:40:56 +0000
In-Reply-To: <20120120123558.GC97313@ocelot.phlegethon.org>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
	<1327062595.30054.28.camel@zakaz.uk.xensource.com>
	<20120120123558.GC97313@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327063256.30054.34.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 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:35 +0000, Tim Deegan wrote:
> At 12:29 +0000 on 20 Jan (1327062595), Ian Campbell wrote:
> > On Fri, 2012-01-20 at 12:20 +0000, Stefano Stabellini wrote:
> > > Could we have a proper stub function or a static inline rather than an
> > > #define?
> > 
> > I tried that, it would require pulling in more headers etc. This is
> > really just a stop gap until we implement enough p2m to support pod
> > properly. I left the real prototypes in the comment for reference.
> 
> We could just as easily have 
> 
> static inline int 
> guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
>                                       unsigned int order)
> {
>     return -ENOSYS;
> }
> 
> &c, for no extra effort (and for the same effect).  A matter of style is
> all. 

That is exactly what required pulling in more 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 Jan 20 12:41:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12: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 1RoDmA-0007j5-Tw; Fri, 20 Jan 2012 12:41:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoDm9-0007hx-0L
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:41:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327063236!63281901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10285 invoked from network); 20 Jan 2012 12:40:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:40:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176512"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:40: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, 20 Jan 2012 12:40:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Fri, 20 Jan 2012 12:40:56 +0000
In-Reply-To: <20120120123558.GC97313@ocelot.phlegethon.org>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-10-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201219100.3196@kaball-desktop>
	<1327062595.30054.28.camel@zakaz.uk.xensource.com>
	<20120120123558.GC97313@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327063256.30054.34.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 10/12] arm: stub out PoD
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:35 +0000, Tim Deegan wrote:
> At 12:29 +0000 on 20 Jan (1327062595), Ian Campbell wrote:
> > On Fri, 2012-01-20 at 12:20 +0000, Stefano Stabellini wrote:
> > > Could we have a proper stub function or a static inline rather than an
> > > #define?
> > 
> > I tried that, it would require pulling in more headers etc. This is
> > really just a stop gap until we implement enough p2m to support pod
> > properly. I left the real prototypes in the comment for reference.
> 
> We could just as easily have 
> 
> static inline int 
> guest_physmap_mark_populate_on_demand(struct domain *d, unsigned long gfn,
>                                       unsigned int order)
> {
>     return -ENOSYS;
> }
> 
> &c, for no extra effort (and for the same effect).  A matter of style is
> all. 

That is exactly what required pulling in more 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 Jan 20 12:45:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDqa-0008S6-Da; Fri, 20 Jan 2012 12:45: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 1RoDqY-0008RP-Cu
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:45:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327063528!8031449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11714 invoked from network); 20 Jan 2012 12:45:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:45:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:45: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, 20 Jan 2012 12:45:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Date: Fri, 20 Jan 2012 12:45:27 +0000
In-Reply-To: <1375017.thPP8t1FNn@amur>
References: <CB3EF874.37D58%keir@xen.org> <1375017.thPP8t1FNn@amur>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327063527.30054.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:40 +0000, Dietmar Hahn wrote:
> Hi Ian,
> 
> Am Freitag 20 Januar 2012, 10:54:44 schrieb Keir Fraser:
> > On 20/01/2012 10:49, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> > 
> > >> Our CPUID configuration is done per-domain, and from
> > >> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
> > >> hypervisor are generally not acceptable without very good reason.
> > > 
> > > Then a way is needed to have access to the opt_vpmu_enabled variable within
> > > the
> > > hypervisor from the tools to decide the enabling of the flag (is there such a
> > > way?) or the mechanism with the boot variable must be changed.
> > > The opt_vpmu_enabled boot variable was introduced because of a PMU problem in
> > > the Nehalem cpus leading sometimes to hypervisor crashes. But with the done
> > > quirk we never had a crash anymore.
> > > So maybe we can always switch on the vpmu stuff in the hypervisor and add a
> > > flag in the domain configuration when somebody wants to do some performance
> > > tests?
> > 
> > Yes!
> > 
> > It's obviously an option of fairly narrow interest. If someone tries to
> > enable the per-domain option on a CPU which has problems, you can fail the
> > domain creation, or print a warning in the hypervisor log, or whatever. Any
> > sensible option in that respect is fine by me!
> 
> What is the best solution for this?
> A domain specific configuration option is needed (vpmu?) which is usable in
> libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid command.
> Can you point me to an proper example?

Can't this already be done via the cpuid domain option given the correct
runes? Maybe with an addition to the table in libxl_cpuid_parse_config?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:45:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:45:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDqa-0008S6-Da; Fri, 20 Jan 2012 12:45: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 1RoDqY-0008RP-Cu
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:45:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327063528!8031449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11714 invoked from network); 20 Jan 2012 12:45:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 12:45:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,541,1320624000"; d="scan'208";a="10176658"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:45: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, 20 Jan 2012 12:45:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Date: Fri, 20 Jan 2012 12:45:27 +0000
In-Reply-To: <1375017.thPP8t1FNn@amur>
References: <CB3EF874.37D58%keir@xen.org> <1375017.thPP8t1FNn@amur>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327063527.30054.37.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>, Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:40 +0000, Dietmar Hahn wrote:
> Hi Ian,
> 
> Am Freitag 20 Januar 2012, 10:54:44 schrieb Keir Fraser:
> > On 20/01/2012 10:49, "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com> wrote:
> > 
> > >> Our CPUID configuration is done per-domain, and from
> > >> tools/libxc/xc_cpuid_x86.c. CPUID adjustments implemented within the
> > >> hypervisor are generally not acceptable without very good reason.
> > > 
> > > Then a way is needed to have access to the opt_vpmu_enabled variable within
> > > the
> > > hypervisor from the tools to decide the enabling of the flag (is there such a
> > > way?) or the mechanism with the boot variable must be changed.
> > > The opt_vpmu_enabled boot variable was introduced because of a PMU problem in
> > > the Nehalem cpus leading sometimes to hypervisor crashes. But with the done
> > > quirk we never had a crash anymore.
> > > So maybe we can always switch on the vpmu stuff in the hypervisor and add a
> > > flag in the domain configuration when somebody wants to do some performance
> > > tests?
> > 
> > Yes!
> > 
> > It's obviously an option of fairly narrow interest. If someone tries to
> > enable the per-domain option on a CPU which has problems, you can fail the
> > domain creation, or print a warning in the hypervisor log, or whatever. Any
> > sensible option in that respect is fine by me!
> 
> What is the best solution for this?
> A domain specific configuration option is needed (vpmu?) which is usable in
> libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid command.
> Can you point me to an proper example?

Can't this already be done via the cpuid domain option given the correct
runes? Maybe with an addition to the table in libxl_cpuid_parse_config?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:50:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:50:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDvC-0000Kq-64; Fri, 20 Jan 2012 12:50: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 1RoDvA-0000Kg-O0
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:50:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327063814!7910626!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 28444 invoked from network); 20 Jan 2012 12:50:14 -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; 20 Jan 2012 12:50:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:50:13 +0000
Message-Id: <4F197155020000780006DF47@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:51:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<1327062518.30054.26.camel@zakaz.uk.xensource.com>
	<4F196DDC020000780006DEEC@nat28.tlf.novell.com>
	<1327063164.30054.32.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327063164.30054.32.camel@zakaz.uk.xensource.com>
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>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-01-20 at 12:36 +0000, Jan Beulich wrote:
>> >>> On 20.01.12 at 13:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2012-01-20 at 12:19 +0000, Stefano Stabellini wrote:
>> >> Why do we need this?
>> >> I though that tmem compiled OK on ARM.
>> > 
>> > But it can't possibly work, as evidenced by the missing symbol in
>> > dummy.S! There is no point in compiling something which cannot work.
>> 
>> But introducing random HAS_xyz variables isn't that pretty either. The
>> more that the term 'has' seems wrong to me in this case.
> 
> yeah, I was copy the other similar variables. Probably ENABLE would be
> better in this case.
> 
>> By just not wiring up the hypercall you could achieve the same effect.
> 
> Really? I'd still need to ifdef out the hypercall body or I'd get
> unresolved symbols, wouldn't I?

Perhaps, but stubbing out dead symbols in a new port seems
prettier to me than cluttering common code.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:50:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:50:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDvC-0000Kq-64; Fri, 20 Jan 2012 12:50: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 1RoDvA-0000Kg-O0
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:50:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327063814!7910626!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 28444 invoked from network); 20 Jan 2012 12:50:14 -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; 20 Jan 2012 12:50:14 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:50:13 +0000
Message-Id: <4F197155020000780006DF47@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:51:17 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<1327062518.30054.26.camel@zakaz.uk.xensource.com>
	<4F196DDC020000780006DEEC@nat28.tlf.novell.com>
	<1327063164.30054.32.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327063164.30054.32.camel@zakaz.uk.xensource.com>
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>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
 platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:39, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-01-20 at 12:36 +0000, Jan Beulich wrote:
>> >>> On 20.01.12 at 13:28, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Fri, 2012-01-20 at 12:19 +0000, Stefano Stabellini wrote:
>> >> Why do we need this?
>> >> I though that tmem compiled OK on ARM.
>> > 
>> > But it can't possibly work, as evidenced by the missing symbol in
>> > dummy.S! There is no point in compiling something which cannot work.
>> 
>> But introducing random HAS_xyz variables isn't that pretty either. The
>> more that the term 'has' seems wrong to me in this case.
> 
> yeah, I was copy the other similar variables. Probably ENABLE would be
> better in this case.
> 
>> By just not wiring up the hypercall you could achieve the same effect.
> 
> Really? I'd still need to ifdef out the hypercall body or I'd get
> unresolved symbols, wouldn't I?

Perhaps, but stubbing out dead symbols in a new port seems
prettier to me than cluttering common code.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:51:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDwB-0000Pl-LG; Fri, 20 Jan 2012 12:51:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RoDwA-0000PU-SM
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:51:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327063875!7902009!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 10317 invoked from network); 20 Jan 2012 12:51:16 -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; 20 Jan 2012 12:51:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:51:15 +0000
Message-Id: <4F197193020000780006DF4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:52:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
	<4F196E6A020000780006DF19@nat28.tlf.novell.com>
	<1327063220.30054.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327063220.30054.33.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] [PATCH 09/12] xen: only map PV guest grants via
 iommu if HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-01-20 at 12:38 +0000, Jan Beulich wrote:
>> >>> On 20.01.12 at 13:06, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> > ---
>> >  xen/Rules.mk             |    1 +
>> >  xen/arch/arm/dummy.S     |    2 --
>> >  xen/common/grant_table.c |    6 ++++++
>> >  3 files changed, 7 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/xen/Rules.mk b/xen/Rules.mk
>> > index e25e8d4..ce88316 100644
>> > --- a/xen/Rules.mk
>> > +++ b/xen/Rules.mk
>> > @@ -52,6 +52,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>> >  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>> >  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>> >  CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
>> > +CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>> >  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>> >  
>> >  ifneq ($(max_phys_cpus),)
>> > diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
>> > index 5010619..e858613 100644
>> > --- a/xen/arch/arm/dummy.S
>> > +++ b/xen/arch/arm/dummy.S
>> > @@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
>> >  DUMMY(gnttab_clear_flag);
>> >  DUMMY(gnttab_mark_dirty);
>> >  DUMMY(hypercall_create_continuation);
>> > -DUMMY(iommu_map_page);
>> > -DUMMY(iommu_unmap_page);
>> >  DUMMY(is_iomem_page);
>> >  DUMMY(max_page);
>> >  DUMMY(node_online_map);
>> > diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> > index b024016..1798fcd 100644
>> > --- a/xen/common/grant_table.c
>> > +++ b/xen/common/grant_table.c
>> > @@ -434,6 +434,7 @@ static int _set_status(unsigned gt_version,
>> >          return _set_status_v2(domid, readonly, mapflag, shah, act, 
> status);
>> >  }
>> >  
>> > +#ifdef HAS_PASSTHROUGH
>> >  static void mapcount(
>> >      struct domain *ld, unsigned long mfn,
>> >      unsigned int *wrc, unsigned int *rdc)
>> > @@ -456,6 +457,7 @@ static void mapcount(
>> >          rcu_unlock_domain(rd);
>> >      }
>> >  }
>> > +#endif
>> >  
>> >  /*
>> >   * Returns 0 if TLB flush / invalidate required by caller.
>> > @@ -662,6 +664,7 @@ __gnttab_map_grant_ref(
>> >          goto undo_out;
>> >      }
>> >  
>> > +#ifdef HAS_PASSTHROUGH
>> >      if ( !is_hvm_domain(ld) && need_iommu(ld) )
>> 
>> Wouldn't #define-ing need_iommu() to 0 in the ARM headers achieve
>> the same effect, without cluttering common code?
> 
> Yes. I'd thought there were other uses of need_iommu but in fact they
> are all in x86.

And even if there were, you'd want them to resolve to 0 too until you
have an IOMMU implementation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 12:51:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 12:51:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoDwB-0000Pl-LG; Fri, 20 Jan 2012 12:51:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RoDwA-0000PU-SM
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 12:51:23 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327063875!7902009!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 10317 invoked from network); 20 Jan 2012 12:51:16 -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; 20 Jan 2012 12:51:16 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 12:51:15 +0000
Message-Id: <4F197193020000780006DF4A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 12:52:19 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-9-git-send-email-ian.campbell@citrix.com>
	<4F196E6A020000780006DF19@nat28.tlf.novell.com>
	<1327063220.30054.33.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327063220.30054.33.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] [PATCH 09/12] xen: only map PV guest grants via
 iommu if HAS_PASSTHROUGH
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 13:40, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2012-01-20 at 12:38 +0000, Jan Beulich wrote:
>> >>> On 20.01.12 at 13:06, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> > ---
>> >  xen/Rules.mk             |    1 +
>> >  xen/arch/arm/dummy.S     |    2 --
>> >  xen/common/grant_table.c |    6 ++++++
>> >  3 files changed, 7 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/xen/Rules.mk b/xen/Rules.mk
>> > index e25e8d4..ce88316 100644
>> > --- a/xen/Rules.mk
>> > +++ b/xen/Rules.mk
>> > @@ -52,6 +52,7 @@ CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>> >  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
>> >  CFLAGS-$(HAS_ACPI)      += -DHAS_ACPI
>> >  CFLAGS-$(HAS_TMEM)      += -DHAS_TMEM
>> > +CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH
>> >  CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
>> >  
>> >  ifneq ($(max_phys_cpus),)
>> > diff --git a/xen/arch/arm/dummy.S b/xen/arch/arm/dummy.S
>> > index 5010619..e858613 100644
>> > --- a/xen/arch/arm/dummy.S
>> > +++ b/xen/arch/arm/dummy.S
>> > @@ -27,8 +27,6 @@ DUMMY(gmfn_to_mfn);
>> >  DUMMY(gnttab_clear_flag);
>> >  DUMMY(gnttab_mark_dirty);
>> >  DUMMY(hypercall_create_continuation);
>> > -DUMMY(iommu_map_page);
>> > -DUMMY(iommu_unmap_page);
>> >  DUMMY(is_iomem_page);
>> >  DUMMY(max_page);
>> >  DUMMY(node_online_map);
>> > diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> > index b024016..1798fcd 100644
>> > --- a/xen/common/grant_table.c
>> > +++ b/xen/common/grant_table.c
>> > @@ -434,6 +434,7 @@ static int _set_status(unsigned gt_version,
>> >          return _set_status_v2(domid, readonly, mapflag, shah, act, 
> status);
>> >  }
>> >  
>> > +#ifdef HAS_PASSTHROUGH
>> >  static void mapcount(
>> >      struct domain *ld, unsigned long mfn,
>> >      unsigned int *wrc, unsigned int *rdc)
>> > @@ -456,6 +457,7 @@ static void mapcount(
>> >          rcu_unlock_domain(rd);
>> >      }
>> >  }
>> > +#endif
>> >  
>> >  /*
>> >   * Returns 0 if TLB flush / invalidate required by caller.
>> > @@ -662,6 +664,7 @@ __gnttab_map_grant_ref(
>> >          goto undo_out;
>> >      }
>> >  
>> > +#ifdef HAS_PASSTHROUGH
>> >      if ( !is_hvm_domain(ld) && need_iommu(ld) )
>> 
>> Wouldn't #define-ing need_iommu() to 0 in the ARM headers achieve
>> the same effect, without cluttering common code?
> 
> Yes. I'd thought there were other uses of need_iommu but in fact they
> are all in x86.

And even if there were, you'd want them to resolve to 0 too until you
have an IOMMU implementation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 13:06:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoEAF-0000yX-3W; Fri, 20 Jan 2012 13:05:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RoEAD-0000yP-BX; Fri, 20 Jan 2012 13:05:53 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327064743!9814639!1
X-Originating-IP: [209.85.210.193]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21359 invoked from network); 20 Jan 2012 13:05:45 -0000
Received: from mail-iy0-f193.google.com (HELO mail-iy0-f193.google.com)
	(209.85.210.193)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 13:05:45 -0000
Received: by iabz21 with SMTP id z21so167388iab.0
	for <multiple recipients>; Fri, 20 Jan 2012 05:05:43 -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=eb6W22sJl4Kw59qIdH1Qr63C5gBGqL8wuIf7FnxgL1g=;
	b=p6602SxcG2yWeOmtJY86wvoxwXvOCkaES31fIRxhJdO5OpylJ/FcKrraLebzy+phZX
	GoymKqyVOQSQL9ZsSOuL4Loe5xqslNcZRBnPkWYvoaoz620O5Pz8DfwvNnykOQhfrn0E
	PPyrYjg/MGnpvKSrlRAFeULDe4mpgTl2Z+AtM=
MIME-Version: 1.0
Received: by 10.50.155.193 with SMTP id vy1mr6130088igb.14.1327064743457; Fri,
	20 Jan 2012 05:05:43 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Fri, 20 Jan 2012 05:05:43 -0800 (PST)
Date: Fri, 20 Jan 2012 14:05:43 +0100
Message-ID: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7664408006015573933=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7664408006015573933==
Content-Type: multipart/alternative; boundary=e89a8f3bafe5a0b23a04b6f556d2

--e89a8f3bafe5a0b23a04b6f556d2
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I have spent a lot of time trying to get gfx passthru working on my system
without success.

I looked onto my hardware capabilities again to make sure that it does
support VT-d and I am not too sure that it does fully.

My hardware is as follows:
- Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
- single Xeon X5650 CPU (which is listed as supporting VT-x, no mention of
VT-d at ark.intel.com)

Now, according to the VTdHowTo <http://wiki.xen.org/wiki/VTdHowTo>, the
motherboard BIOS, chipset AND CPU need to support VT-d.
What confuses me is, why is the 55x0 chipset listed there if none of the
CPU's supported, that I know of, dont have the VT-d feature option, only
VT-x.

Browsing around a bit, I read that the VT-d is a memory related feature
which was included in the chipsets because memory was interfaced via the
chipset, but now-a-days when the memory controller is in the CPU, VT-d
should be in the CPU. Why does the 5520 chipset support VT-d and the X5650
not?

Could anyone who has experience with a similar platform to mine (5520
chipset and Xeon CPU) please share their experiences with PCI passthu and
gfx passthru.

My setup quickly:
- onboard VGA (primary) used by dom0 (Debian with the 3.1.9 kernel)
- EVGA GTX 480 (secondary) passed thru to domU (Windows)

The only errors that I see are:

cat /var/log/xen/qemu-dm-winxp.log |grep -i er
xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error.
/vm/d04a58cf-037a-4219-80a1-73abe49b81ab/vncpasswd.
vcpu-set: watch node error.
xs_read(/local/domain/2/log-throttling): read error
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No
such file or directory: 0x3:0x0.0x0
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No
such file or directory: 0x3:0x0.0x1

I cant find much info about this error...

cat /var/log/xen/xl-winxp.log
Waiting for domain winxp (domid 1) to die [pid 3038]
Domain 1 is dead
Action for shutdown reason code 3 is restart
Domain 1 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.1
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->0000000000182bb4
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.1
Waiting for domain winxp (domid 2) to die [pid 3038]

dmesg |grep 03:00
[    0.000000] Command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    5.948984] Kernel command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    6.152642] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300
[    6.152663] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9ffffff]
[    6.152685] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0xdfffffff 64bit
pref]
[    6.152707] pci 0000:03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64bit
pref]
[    6.152723] pci 0000:03:00.0: reg 24: [io  0xdc00-0xdc7f]
[    6.152738] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaefffff pref]
[    6.152831] pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403
[    6.152851] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]
[    6.222176] vgaarb: device added:
PCI:0000:03:00.0,decodes=io+mem,owns=none,locks=none
[    6.222205] vgaarb: bridge control possible 0000:03:00.0
[    6.276478] pciback 0000:03:00.0: seizing device
[    6.276483] pciback 0000:03:00.1: seizing device
[    6.549901] pciback 0000:03:00.0: Signaling PME through PCIe PME
interrupt
[    6.549903] pciback 0000:03:00.1: Signaling PME through PCIe PME
interrupt
[    6.550408] pciback 0000:03:00.1: PCI INT B -> GSI 25 (level, low) ->
IRQ 25
[    6.550417] pciback 0000:03:00.1: PCI INT B disabled
[    6.550454] pciback 0000:03:00.0: enabling device (0146 -> 0147)
[    6.550470] pciback 0000:03:00.0: PCI INT A -> GSI 26 (level, low) ->
IRQ 26
[    6.550477] pciback 0000:03:00.0: PCI INT A disabled
[12048.241890] pciback 0000:03:00.0: device has been assigned to another
domain! Over-writting the ownership, but beware.
[12048.243009] pciback 0000:03:00.1: device has been assigned to another
domain! Over-writting the ownership, but beware.

PCI device 03:00.x is the GTX 480.

xl list
Name                                        ID   Mem VCPUs State Time(s)
Domain-0                                     0  1024    12     r-----
 1507.2
winxp                                        2  1015     1     r-----
212.2


When I create the winxp domain, my primary graphics goes blank...
(This confuses me the most).


And lastly, my xen cfg file...

cat /xen-vms/xenwinxp.cfg
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory =1024
# shadow_memory = 1024
name = "winxp"
vcpus='1'
# vif = [ 'bridge=eth0,mac=00:14:3e:00:8f:c2' ]
# disk =
['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/winxp.iso,hdc:cdrom,r']
disk = ['file:/xen-vms/winxp/xenwinxp.img,hda,w','phy:/dev/sr0,hdc:cdrom,r']
boot="cd"
sdl=0
# vnc=1
# vnclisten="0.0.0.0"
# vncconsole=1
# vncpasswd=''
acpi=1
apic=1
xen_extended_power_mgmt=1
pae=1
arch='x86_64'
hpet = 1
hap = 1
viridian = 1
monitor=1
serial='pty'
# keymap='fr'
# soundhw = "all"
# audio="on"
ne2000=0
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
xen_platform_pci=1
gfx_passthru=1
pci  = [ '03:00.0','03:00.1' ]
pci_msitranslate=0
pci_power_mgmt=0
acpi_s3 = 1
acpi_s4 = 1


If anyone has any ideas, or things I should check or try, please let me
know. Also, if there is a way for me to get more debug info from xen that
might help me figure out what I am doing wrong in my configuration, I
would appreciate that info too.

Sandi

--e89a8f3bafe5a0b23a04b6f556d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I have spent a lot of time trying to get gfx pass=
thru working on my system without success.</div><div><br></div><div>I looke=
d onto my hardware capabilities again to make sure that it does support VT-=
d and I am not too sure that it does fully.</div>
<div><br></div><div>My hardware is as follows:</div><div>- Supermicro=A0X8D=
TH-6F motherboard (5520 chipset which supports VT-d)</div><div>- single Xeo=
n X5650 CPU (which is listed as supporting VT-x, no mention of VT-d at <a h=
ref=3D"http://ark.intel.com">ark.intel.com</a>)</div>
<div><br></div><div>Now, according to the <a href=3D"http://wiki.xen.org/wi=
ki/VTdHowTo">VTdHowTo</a>, the motherboard BIOS, chipset AND CPU need to su=
pport VT-d.</div><div>What=A0confuses=A0me is, why is the 55x0 chipset list=
ed there if none of the CPU&#39;s supported, that I know of, dont have the =
VT-d feature option, only VT-x.</div>
<div><br></div><div>Browsing around a bit, I read that the VT-d is a memory=
 related feature which was included in the chipsets because memory was inte=
rfaced via the chipset, but now-a-days when the memory controller is in the=
 CPU, VT-d should be in the CPU. Why does the 5520 chipset support VT-d and=
 the X5650 not?</div>
<div><br></div><div>Could anyone who has experience with a similar platform=
 to mine (5520 chipset and Xeon CPU) please share their experiences with PC=
I passthu and gfx passthru.</div><div><br></div><div>My setup=A0quickly:</d=
iv>
<div>- onboard VGA (primary) used by dom0 (Debian with the 3.1.9 kernel)</d=
iv><div>- EVGA GTX 480 (secondary) passed thru to domU (Windows)</div><div>=
<br></div><div>The only errors that I see are:<br><div><br></div><div>cat /=
var/log/xen/qemu-dm-winxp.log |grep -i er</div>
<div>xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read =
error</div><div>xs_read(): vncpasswd get error. /vm/d04a58cf-037a-4219-80a1=
-73abe49b81ab/vncpasswd.</div><div>vcpu-set: watch node error.</div><div>
xs_read(/local/domain/2/log-throttling): read error</div><div><font color=
=3D"#ff0000">pt_iomul_init: Error: pt_iomul_init can&#39;t open file /dev/x=
en/pci_iomul: No such file or directory: 0x3:0x0.0x0</font></div><div><font=
 color=3D"#ff0000">pt_iomul_init: Error: pt_iomul_init can&#39;t open file =
/dev/xen/pci_iomul: No such file or directory: 0x3:0x0.0x1</font></div>
</div><div><br></div><div>I cant find much info about this error...</div><d=
iv><br></div><div><div>cat /var/log/xen/xl-winxp.log</div><div>Waiting for =
domain winxp (domid 1) to die [pid 3038]</div><div>Domain 1 is dead</div>
<div>Action for shutdown reason code 3 is restart</div><div>Domain 1 needs =
to be cleaned up: destroying the domain</div><div><span style=3D"background=
-color:rgb(255,255,255)"><font color=3D"#ff0000">libxl: error: libxl_pci.c:=
776:libxl__device_pci_reset: The kernel doesn&#39;t support reset from sysf=
s for PCI device 0000:03:00.0</font></span></div>
<div><span style=3D"background-color:rgb(255,255,255)"><font color=3D"#ff00=
00">libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn=
&#39;t support reset from sysfs for PCI device 0000:03:00.1</font></span></=
div>
<div>Done. Rebooting now</div><div>xc: info: VIRTUAL MEMORY ARRANGEMENT:</d=
iv><div>=A0 Loader: =A0 =A0 =A0 =A00000000000100000-&gt;0000000000182bb4</d=
iv><div>=A0 TOTAL: =A0 =A0 =A0 =A0 0000000000000000-&gt;000000003f800000</d=
iv><div>=A0 ENTRY ADDRESS: 0000000000100000</div>
<div>xc: info: PHYSICAL MEMORY ALLOCATION:</div><div>=A0 4KB PAGES: 0x00000=
00000000200</div><div>=A0 2MB PAGES: 0x00000000000001fb</div><div>=A0 1GB P=
AGES: 0x0000000000000000</div><div><font color=3D"#ff0000">libxl: error: li=
bxl_pci.c:776:libxl__device_pci_reset: The kernel doesn&#39;t support reset=
 from sysfs for PCI device 0000:03:00.0</font></div>
<div><font color=3D"#ff0000">libxl: error: libxl_pci.c:776:libxl__device_pc=
i_reset: The kernel doesn&#39;t support reset from sysfs for PCI device 000=
0:03:00.1</font></div><div>Waiting for domain winxp (domid 2) to die [pid 3=
038]</div>
</div><div><br></div><div>dmesg |grep 03:00</div><div><div>[ =A0 =A00.00000=
0] Command line: placeholder root=3DUUID=3Dd5f5207b-d2aa-4f19-b51d-bc2c727b=
9e8f ro nomodeset xen-pciback.passthrough=3D1 xen-pciback.permissive xen-pc=
iback.hide=3D(03:00.0)(03:00.1) quiet</div>
<div>[ =A0 =A05.948984] Kernel command line: placeholder root=3DUUID=3Dd5f5=
207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.passthrough=3D1 x=
en-pciback.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet</div><div=
>[ =A0 =A06.152642] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300</di=
v>
<div>[ =A0 =A06.152663] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9fffff=
f]</div><div>[ =A0 =A06.152685] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0=
xdfffffff 64bit pref]</div><div>[ =A0 =A06.152707] pci 0000:03:00.0: reg 1c=
: [mem 0xd4000000-0xd7ffffff 64bit pref]</div>
<div>[ =A0 =A06.152723] pci 0000:03:00.0: reg 24: [io =A00xdc00-0xdc7f]</di=
v><div>[ =A0 =A06.152738] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaeff=
fff pref]</div><div>[ =A0 =A06.152831] pci 0000:03:00.1: [10de:0be5] type 0=
 class 0x000403</div>
<div>[ =A0 =A06.152851] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7fff=
f]</div><div>[ =A0 =A06.222176] vgaarb: device added: PCI:0000:03:00.0,deco=
des=3Dio+mem,owns=3Dnone,locks=3Dnone</div><div>[ =A0 =A06.222205] vgaarb: =
bridge control possible 0000:03:00.0</div>
<div>[ =A0 =A06.276478] pciback 0000:03:00.0: seizing device</div><div>[ =
=A0 =A06.276483] pciback 0000:03:00.1: seizing device</div><div>[ =A0 =A06.=
549901] pciback 0000:03:00.0: Signaling PME through PCIe PME interrupt</div=
><div>[ =A0 =A06.549903] pciback 0000:03:00.1: Signaling PME through PCIe P=
ME interrupt</div>
<div>[ =A0 =A06.550408] pciback 0000:03:00.1: PCI INT B -&gt; GSI 25 (level=
, low) -&gt; IRQ 25</div><div>[ =A0 =A06.550417] pciback 0000:03:00.1: PCI =
INT B disabled</div><div>[ =A0 =A06.550454] pciback 0000:03:00.0: enabling =
device (0146 -&gt; 0147)</div>
<div>[ =A0 =A06.550470] pciback 0000:03:00.0: PCI INT A -&gt; GSI 26 (level=
, low) -&gt; IRQ 26</div><div>[ =A0 =A06.550477] pciback 0000:03:00.0: PCI =
INT A disabled</div><div>[12048.241890] pciback 0000:03:00.0: device has be=
en assigned to another domain! Over-writting the ownership, but beware.</di=
v>
<div>[12048.243009] pciback 0000:03:00.1: device has been assigned to anoth=
er domain! Over-writting the ownership, but beware.</div></div><div><br></d=
iv><div>PCI device 03:00.x is the GTX 480.</div><div><br></div><div><div>
xl list</div><div>Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0ID =A0 Mem VCPUs<span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">	</span>State<span class=3D"Apple-tab-span" style=
=3D"white-space:pre">	</span>Time(s)</div><div>
Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 0 =A01024 =A0 =A012 =A0 =A0 r----- =A0 =A01507.2</div><div>winxp =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A02 =A01015 =A0 =A0 1 =A0 =A0 r----- =A0 =A0 212.2</div></div><div><br></=
div><div><br></div><div>When I create the winxp domain, my primary graphics=
 goes blank... (This=A0confuses=A0me the most).</div>
<div><br></div><div><br></div><div>And lastly, my xen cfg file...</div><div=
><br></div><div><div>cat /xen-vms/xenwinxp.cfg=A0</div><div>kernel =3D &quo=
t;/usr/lib/xen/boot/hvmloader&quot;</div><div>builder=3D&#39;hvm&#39;</div>=
<div>
memory =3D1024=A0</div><div># shadow_memory =3D 1024</div><div>name =3D &qu=
ot;winxp&quot;</div><div>vcpus=3D&#39;1&#39;</div><div># vif =3D [ &#39;bri=
dge=3Deth0,mac=3D00:14:3e:00:8f:c2&#39; ]</div><div># disk =3D [&#39;file:/=
xen-vms/winxp/xenwinxp.img,hda,w&#39;,&#39;file:/xen-vms/isos/winxp.iso,hdc=
:cdrom,r&#39;]</div>
<div>disk =3D [&#39;file:/xen-vms/winxp/xenwinxp.img,hda,w&#39;,&#39;phy:/d=
ev/sr0,hdc:cdrom,r&#39;]</div><div>boot=3D&quot;cd&quot;</div><div>sdl=3D0<=
/div><div># vnc=3D1</div><div># vnclisten=3D&quot;0.0.0.0&quot;</div><div>#=
 vncconsole=3D1</div>
<div># vncpasswd=3D&#39;&#39;</div><div>acpi=3D1</div><div>apic=3D1</div><d=
iv>xen_extended_power_mgmt=3D1</div><div>pae=3D1</div><div>arch=3D&#39;x86_=
64&#39;</div><div>hpet =3D 1</div><div>hap =3D 1</div><div>viridian =3D 1</=
div><div>monitor=3D1</div>
<div>serial=3D&#39;pty&#39;</div><div># keymap=3D&#39;fr&#39;</div><div># s=
oundhw =3D &quot;all&quot;</div><div># audio=3D&quot;on&quot;</div><div>ne2=
000=3D0</div><div>on_poweroff =3D &#39;destroy&#39;</div><div>on_reboot =A0=
 =3D &#39;restart&#39;</div>
<div>on_crash =A0 =A0=3D &#39;restart&#39;</div><div>xen_platform_pci=3D1=
=A0</div><div>gfx_passthru=3D1</div><div>pci =A0=3D [ &#39;03:00.0&#39;,&#3=
9;03:00.1&#39; ]</div><div>pci_msitranslate=3D0</div><div>pci_power_mgmt=3D=
0</div><div>acpi_s3 =3D 1</div>
<div>acpi_s4 =3D 1</div></div><div><br></div><div><br></div><div>If anyone =
has any ideas, or things I should check or try, please let me know. Also, i=
f there is a way for me to get more debug info from xen that might help me =
figure out what I am doing wrong in my configuration, I would=A0appreciate=
=A0that info too.</div>
<div><br></div><div>Sandi</div>

--e89a8f3bafe5a0b23a04b6f556d2--


--===============7664408006015573933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7664408006015573933==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 13:06:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoEAF-0000yX-3W; Fri, 20 Jan 2012 13:05:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RoEAD-0000yP-BX; Fri, 20 Jan 2012 13:05:53 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327064743!9814639!1
X-Originating-IP: [209.85.210.193]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21359 invoked from network); 20 Jan 2012 13:05:45 -0000
Received: from mail-iy0-f193.google.com (HELO mail-iy0-f193.google.com)
	(209.85.210.193)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 13:05:45 -0000
Received: by iabz21 with SMTP id z21so167388iab.0
	for <multiple recipients>; Fri, 20 Jan 2012 05:05:43 -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=eb6W22sJl4Kw59qIdH1Qr63C5gBGqL8wuIf7FnxgL1g=;
	b=p6602SxcG2yWeOmtJY86wvoxwXvOCkaES31fIRxhJdO5OpylJ/FcKrraLebzy+phZX
	GoymKqyVOQSQL9ZsSOuL4Loe5xqslNcZRBnPkWYvoaoz620O5Pz8DfwvNnykOQhfrn0E
	PPyrYjg/MGnpvKSrlRAFeULDe4mpgTl2Z+AtM=
MIME-Version: 1.0
Received: by 10.50.155.193 with SMTP id vy1mr6130088igb.14.1327064743457; Fri,
	20 Jan 2012 05:05:43 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Fri, 20 Jan 2012 05:05:43 -0800 (PST)
Date: Fri, 20 Jan 2012 14:05:43 +0100
Message-ID: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7664408006015573933=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7664408006015573933==
Content-Type: multipart/alternative; boundary=e89a8f3bafe5a0b23a04b6f556d2

--e89a8f3bafe5a0b23a04b6f556d2
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I have spent a lot of time trying to get gfx passthru working on my system
without success.

I looked onto my hardware capabilities again to make sure that it does
support VT-d and I am not too sure that it does fully.

My hardware is as follows:
- Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
- single Xeon X5650 CPU (which is listed as supporting VT-x, no mention of
VT-d at ark.intel.com)

Now, according to the VTdHowTo <http://wiki.xen.org/wiki/VTdHowTo>, the
motherboard BIOS, chipset AND CPU need to support VT-d.
What confuses me is, why is the 55x0 chipset listed there if none of the
CPU's supported, that I know of, dont have the VT-d feature option, only
VT-x.

Browsing around a bit, I read that the VT-d is a memory related feature
which was included in the chipsets because memory was interfaced via the
chipset, but now-a-days when the memory controller is in the CPU, VT-d
should be in the CPU. Why does the 5520 chipset support VT-d and the X5650
not?

Could anyone who has experience with a similar platform to mine (5520
chipset and Xeon CPU) please share their experiences with PCI passthu and
gfx passthru.

My setup quickly:
- onboard VGA (primary) used by dom0 (Debian with the 3.1.9 kernel)
- EVGA GTX 480 (secondary) passed thru to domU (Windows)

The only errors that I see are:

cat /var/log/xen/qemu-dm-winxp.log |grep -i er
xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error.
/vm/d04a58cf-037a-4219-80a1-73abe49b81ab/vncpasswd.
vcpu-set: watch node error.
xs_read(/local/domain/2/log-throttling): read error
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No
such file or directory: 0x3:0x0.0x0
pt_iomul_init: Error: pt_iomul_init can't open file /dev/xen/pci_iomul: No
such file or directory: 0x3:0x0.0x1

I cant find much info about this error...

cat /var/log/xen/xl-winxp.log
Waiting for domain winxp (domid 1) to die [pid 3038]
Domain 1 is dead
Action for shutdown reason code 3 is restart
Domain 1 needs to be cleaned up: destroying the domain
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.1
Done. Rebooting now
xc: info: VIRTUAL MEMORY ARRANGEMENT:
  Loader:        0000000000100000->0000000000182bb4
  TOTAL:         0000000000000000->000000003f800000
  ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
  4KB PAGES: 0x0000000000000200
  2MB PAGES: 0x00000000000001fb
  1GB PAGES: 0x0000000000000000
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.0
libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn't
support reset from sysfs for PCI device 0000:03:00.1
Waiting for domain winxp (domid 2) to die [pid 3038]

dmesg |grep 03:00
[    0.000000] Command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    5.948984] Kernel command line: placeholder
root=UUID=d5f5207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset
xen-pciback.passthrough=1 xen-pciback.permissive
xen-pciback.hide=(03:00.0)(03:00.1) quiet
[    6.152642] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300
[    6.152663] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9ffffff]
[    6.152685] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0xdfffffff 64bit
pref]
[    6.152707] pci 0000:03:00.0: reg 1c: [mem 0xd4000000-0xd7ffffff 64bit
pref]
[    6.152723] pci 0000:03:00.0: reg 24: [io  0xdc00-0xdc7f]
[    6.152738] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaefffff pref]
[    6.152831] pci 0000:03:00.1: [10de:0be5] type 0 class 0x000403
[    6.152851] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7ffff]
[    6.222176] vgaarb: device added:
PCI:0000:03:00.0,decodes=io+mem,owns=none,locks=none
[    6.222205] vgaarb: bridge control possible 0000:03:00.0
[    6.276478] pciback 0000:03:00.0: seizing device
[    6.276483] pciback 0000:03:00.1: seizing device
[    6.549901] pciback 0000:03:00.0: Signaling PME through PCIe PME
interrupt
[    6.549903] pciback 0000:03:00.1: Signaling PME through PCIe PME
interrupt
[    6.550408] pciback 0000:03:00.1: PCI INT B -> GSI 25 (level, low) ->
IRQ 25
[    6.550417] pciback 0000:03:00.1: PCI INT B disabled
[    6.550454] pciback 0000:03:00.0: enabling device (0146 -> 0147)
[    6.550470] pciback 0000:03:00.0: PCI INT A -> GSI 26 (level, low) ->
IRQ 26
[    6.550477] pciback 0000:03:00.0: PCI INT A disabled
[12048.241890] pciback 0000:03:00.0: device has been assigned to another
domain! Over-writting the ownership, but beware.
[12048.243009] pciback 0000:03:00.1: device has been assigned to another
domain! Over-writting the ownership, but beware.

PCI device 03:00.x is the GTX 480.

xl list
Name                                        ID   Mem VCPUs State Time(s)
Domain-0                                     0  1024    12     r-----
 1507.2
winxp                                        2  1015     1     r-----
212.2


When I create the winxp domain, my primary graphics goes blank...
(This confuses me the most).


And lastly, my xen cfg file...

cat /xen-vms/xenwinxp.cfg
kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory =1024
# shadow_memory = 1024
name = "winxp"
vcpus='1'
# vif = [ 'bridge=eth0,mac=00:14:3e:00:8f:c2' ]
# disk =
['file:/xen-vms/winxp/xenwinxp.img,hda,w','file:/xen-vms/isos/winxp.iso,hdc:cdrom,r']
disk = ['file:/xen-vms/winxp/xenwinxp.img,hda,w','phy:/dev/sr0,hdc:cdrom,r']
boot="cd"
sdl=0
# vnc=1
# vnclisten="0.0.0.0"
# vncconsole=1
# vncpasswd=''
acpi=1
apic=1
xen_extended_power_mgmt=1
pae=1
arch='x86_64'
hpet = 1
hap = 1
viridian = 1
monitor=1
serial='pty'
# keymap='fr'
# soundhw = "all"
# audio="on"
ne2000=0
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'
xen_platform_pci=1
gfx_passthru=1
pci  = [ '03:00.0','03:00.1' ]
pci_msitranslate=0
pci_power_mgmt=0
acpi_s3 = 1
acpi_s4 = 1


If anyone has any ideas, or things I should check or try, please let me
know. Also, if there is a way for me to get more debug info from xen that
might help me figure out what I am doing wrong in my configuration, I
would appreciate that info too.

Sandi

--e89a8f3bafe5a0b23a04b6f556d2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I have spent a lot of time trying to get gfx pass=
thru working on my system without success.</div><div><br></div><div>I looke=
d onto my hardware capabilities again to make sure that it does support VT-=
d and I am not too sure that it does fully.</div>
<div><br></div><div>My hardware is as follows:</div><div>- Supermicro=A0X8D=
TH-6F motherboard (5520 chipset which supports VT-d)</div><div>- single Xeo=
n X5650 CPU (which is listed as supporting VT-x, no mention of VT-d at <a h=
ref=3D"http://ark.intel.com">ark.intel.com</a>)</div>
<div><br></div><div>Now, according to the <a href=3D"http://wiki.xen.org/wi=
ki/VTdHowTo">VTdHowTo</a>, the motherboard BIOS, chipset AND CPU need to su=
pport VT-d.</div><div>What=A0confuses=A0me is, why is the 55x0 chipset list=
ed there if none of the CPU&#39;s supported, that I know of, dont have the =
VT-d feature option, only VT-x.</div>
<div><br></div><div>Browsing around a bit, I read that the VT-d is a memory=
 related feature which was included in the chipsets because memory was inte=
rfaced via the chipset, but now-a-days when the memory controller is in the=
 CPU, VT-d should be in the CPU. Why does the 5520 chipset support VT-d and=
 the X5650 not?</div>
<div><br></div><div>Could anyone who has experience with a similar platform=
 to mine (5520 chipset and Xeon CPU) please share their experiences with PC=
I passthu and gfx passthru.</div><div><br></div><div>My setup=A0quickly:</d=
iv>
<div>- onboard VGA (primary) used by dom0 (Debian with the 3.1.9 kernel)</d=
iv><div>- EVGA GTX 480 (secondary) passed thru to domU (Windows)</div><div>=
<br></div><div>The only errors that I see are:<br><div><br></div><div>cat /=
var/log/xen/qemu-dm-winxp.log |grep -i er</div>
<div>xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read =
error</div><div>xs_read(): vncpasswd get error. /vm/d04a58cf-037a-4219-80a1=
-73abe49b81ab/vncpasswd.</div><div>vcpu-set: watch node error.</div><div>
xs_read(/local/domain/2/log-throttling): read error</div><div><font color=
=3D"#ff0000">pt_iomul_init: Error: pt_iomul_init can&#39;t open file /dev/x=
en/pci_iomul: No such file or directory: 0x3:0x0.0x0</font></div><div><font=
 color=3D"#ff0000">pt_iomul_init: Error: pt_iomul_init can&#39;t open file =
/dev/xen/pci_iomul: No such file or directory: 0x3:0x0.0x1</font></div>
</div><div><br></div><div>I cant find much info about this error...</div><d=
iv><br></div><div><div>cat /var/log/xen/xl-winxp.log</div><div>Waiting for =
domain winxp (domid 1) to die [pid 3038]</div><div>Domain 1 is dead</div>
<div>Action for shutdown reason code 3 is restart</div><div>Domain 1 needs =
to be cleaned up: destroying the domain</div><div><span style=3D"background=
-color:rgb(255,255,255)"><font color=3D"#ff0000">libxl: error: libxl_pci.c:=
776:libxl__device_pci_reset: The kernel doesn&#39;t support reset from sysf=
s for PCI device 0000:03:00.0</font></span></div>
<div><span style=3D"background-color:rgb(255,255,255)"><font color=3D"#ff00=
00">libxl: error: libxl_pci.c:776:libxl__device_pci_reset: The kernel doesn=
&#39;t support reset from sysfs for PCI device 0000:03:00.1</font></span></=
div>
<div>Done. Rebooting now</div><div>xc: info: VIRTUAL MEMORY ARRANGEMENT:</d=
iv><div>=A0 Loader: =A0 =A0 =A0 =A00000000000100000-&gt;0000000000182bb4</d=
iv><div>=A0 TOTAL: =A0 =A0 =A0 =A0 0000000000000000-&gt;000000003f800000</d=
iv><div>=A0 ENTRY ADDRESS: 0000000000100000</div>
<div>xc: info: PHYSICAL MEMORY ALLOCATION:</div><div>=A0 4KB PAGES: 0x00000=
00000000200</div><div>=A0 2MB PAGES: 0x00000000000001fb</div><div>=A0 1GB P=
AGES: 0x0000000000000000</div><div><font color=3D"#ff0000">libxl: error: li=
bxl_pci.c:776:libxl__device_pci_reset: The kernel doesn&#39;t support reset=
 from sysfs for PCI device 0000:03:00.0</font></div>
<div><font color=3D"#ff0000">libxl: error: libxl_pci.c:776:libxl__device_pc=
i_reset: The kernel doesn&#39;t support reset from sysfs for PCI device 000=
0:03:00.1</font></div><div>Waiting for domain winxp (domid 2) to die [pid 3=
038]</div>
</div><div><br></div><div>dmesg |grep 03:00</div><div><div>[ =A0 =A00.00000=
0] Command line: placeholder root=3DUUID=3Dd5f5207b-d2aa-4f19-b51d-bc2c727b=
9e8f ro nomodeset xen-pciback.passthrough=3D1 xen-pciback.permissive xen-pc=
iback.hide=3D(03:00.0)(03:00.1) quiet</div>
<div>[ =A0 =A05.948984] Kernel command line: placeholder root=3DUUID=3Dd5f5=
207b-d2aa-4f19-b51d-bc2c727b9e8f ro nomodeset xen-pciback.passthrough=3D1 x=
en-pciback.permissive xen-pciback.hide=3D(03:00.0)(03:00.1) quiet</div><div=
>[ =A0 =A06.152642] pci 0000:03:00.0: [10de:06c0] type 0 class 0x000300</di=
v>
<div>[ =A0 =A06.152663] pci 0000:03:00.0: reg 10: [mem 0xf8000000-0xf9fffff=
f]</div><div>[ =A0 =A06.152685] pci 0000:03:00.0: reg 14: [mem 0xd8000000-0=
xdfffffff 64bit pref]</div><div>[ =A0 =A06.152707] pci 0000:03:00.0: reg 1c=
: [mem 0xd4000000-0xd7ffffff 64bit pref]</div>
<div>[ =A0 =A06.152723] pci 0000:03:00.0: reg 24: [io =A00xdc00-0xdc7f]</di=
v><div>[ =A0 =A06.152738] pci 0000:03:00.0: reg 30: [mem 0xfae80000-0xfaeff=
fff pref]</div><div>[ =A0 =A06.152831] pci 0000:03:00.1: [10de:0be5] type 0=
 class 0x000403</div>
<div>[ =A0 =A06.152851] pci 0000:03:00.1: reg 10: [mem 0xfae7c000-0xfae7fff=
f]</div><div>[ =A0 =A06.222176] vgaarb: device added: PCI:0000:03:00.0,deco=
des=3Dio+mem,owns=3Dnone,locks=3Dnone</div><div>[ =A0 =A06.222205] vgaarb: =
bridge control possible 0000:03:00.0</div>
<div>[ =A0 =A06.276478] pciback 0000:03:00.0: seizing device</div><div>[ =
=A0 =A06.276483] pciback 0000:03:00.1: seizing device</div><div>[ =A0 =A06.=
549901] pciback 0000:03:00.0: Signaling PME through PCIe PME interrupt</div=
><div>[ =A0 =A06.549903] pciback 0000:03:00.1: Signaling PME through PCIe P=
ME interrupt</div>
<div>[ =A0 =A06.550408] pciback 0000:03:00.1: PCI INT B -&gt; GSI 25 (level=
, low) -&gt; IRQ 25</div><div>[ =A0 =A06.550417] pciback 0000:03:00.1: PCI =
INT B disabled</div><div>[ =A0 =A06.550454] pciback 0000:03:00.0: enabling =
device (0146 -&gt; 0147)</div>
<div>[ =A0 =A06.550470] pciback 0000:03:00.0: PCI INT A -&gt; GSI 26 (level=
, low) -&gt; IRQ 26</div><div>[ =A0 =A06.550477] pciback 0000:03:00.0: PCI =
INT A disabled</div><div>[12048.241890] pciback 0000:03:00.0: device has be=
en assigned to another domain! Over-writting the ownership, but beware.</di=
v>
<div>[12048.243009] pciback 0000:03:00.1: device has been assigned to anoth=
er domain! Over-writting the ownership, but beware.</div></div><div><br></d=
iv><div>PCI device 03:00.x is the GTX 480.</div><div><br></div><div><div>
xl list</div><div>Name =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0ID =A0 Mem VCPUs<span class=3D"Apple-tab-span" s=
tyle=3D"white-space:pre">	</span>State<span class=3D"Apple-tab-span" style=
=3D"white-space:pre">	</span>Time(s)</div><div>
Domain-0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 0 =A01024 =A0 =A012 =A0 =A0 r----- =A0 =A01507.2</div><div>winxp =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A02 =A01015 =A0 =A0 1 =A0 =A0 r----- =A0 =A0 212.2</div></div><div><br></=
div><div><br></div><div>When I create the winxp domain, my primary graphics=
 goes blank... (This=A0confuses=A0me the most).</div>
<div><br></div><div><br></div><div>And lastly, my xen cfg file...</div><div=
><br></div><div><div>cat /xen-vms/xenwinxp.cfg=A0</div><div>kernel =3D &quo=
t;/usr/lib/xen/boot/hvmloader&quot;</div><div>builder=3D&#39;hvm&#39;</div>=
<div>
memory =3D1024=A0</div><div># shadow_memory =3D 1024</div><div>name =3D &qu=
ot;winxp&quot;</div><div>vcpus=3D&#39;1&#39;</div><div># vif =3D [ &#39;bri=
dge=3Deth0,mac=3D00:14:3e:00:8f:c2&#39; ]</div><div># disk =3D [&#39;file:/=
xen-vms/winxp/xenwinxp.img,hda,w&#39;,&#39;file:/xen-vms/isos/winxp.iso,hdc=
:cdrom,r&#39;]</div>
<div>disk =3D [&#39;file:/xen-vms/winxp/xenwinxp.img,hda,w&#39;,&#39;phy:/d=
ev/sr0,hdc:cdrom,r&#39;]</div><div>boot=3D&quot;cd&quot;</div><div>sdl=3D0<=
/div><div># vnc=3D1</div><div># vnclisten=3D&quot;0.0.0.0&quot;</div><div>#=
 vncconsole=3D1</div>
<div># vncpasswd=3D&#39;&#39;</div><div>acpi=3D1</div><div>apic=3D1</div><d=
iv>xen_extended_power_mgmt=3D1</div><div>pae=3D1</div><div>arch=3D&#39;x86_=
64&#39;</div><div>hpet =3D 1</div><div>hap =3D 1</div><div>viridian =3D 1</=
div><div>monitor=3D1</div>
<div>serial=3D&#39;pty&#39;</div><div># keymap=3D&#39;fr&#39;</div><div># s=
oundhw =3D &quot;all&quot;</div><div># audio=3D&quot;on&quot;</div><div>ne2=
000=3D0</div><div>on_poweroff =3D &#39;destroy&#39;</div><div>on_reboot =A0=
 =3D &#39;restart&#39;</div>
<div>on_crash =A0 =A0=3D &#39;restart&#39;</div><div>xen_platform_pci=3D1=
=A0</div><div>gfx_passthru=3D1</div><div>pci =A0=3D [ &#39;03:00.0&#39;,&#3=
9;03:00.1&#39; ]</div><div>pci_msitranslate=3D0</div><div>pci_power_mgmt=3D=
0</div><div>acpi_s3 =3D 1</div>
<div>acpi_s4 =3D 1</div></div><div><br></div><div><br></div><div>If anyone =
has any ideas, or things I should check or try, please let me know. Also, i=
f there is a way for me to get more debug info from xen that might help me =
figure out what I am doing wrong in my configuration, I would=A0appreciate=
=A0that info too.</div>
<div><br></div><div>Sandi</div>

--e89a8f3bafe5a0b23a04b6f556d2--


--===============7664408006015573933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7664408006015573933==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 13:11:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13: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 1RoEFm-0001OL-Pt; Fri, 20 Jan 2012 13:11: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 1RoEFl-0001O4-Ba
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 13:11:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327065091!11853778!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31440 invoked from network); 20 Jan 2012 13:11:31 -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 Jan 2012 13:11:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10177246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:11:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 13:11:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 13:11:30 +0000
In-Reply-To: <1327062788.30054.31.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327065091.30054.43.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:33 +0000, Ian Campbell wrote:
> On Fri, 2012-01-20 at 12:04 +0000, Dario Faggioli wrote:
> > On Fri, 2012-01-20 at 11:54 +0000, Ian Campbell wrote: 
> 
> > > > Of course, even in such mode, if the user explicitly tells us what he
> > > > wants, e.g., by means of cpupools, pinning, etc., we should still honour
> > > > such request.
> > > 
> > > Do we get this right now?
> > > 
> > Sorry, not sure what you mean here...
> 
> I meant is "if the user explicitly tells us what he wants, e.g., by
> means of cpupools, pinning, etc." do we still honour such request?

It appears that with cpupools we do not. After running
cpupool-numa-split I started a guest with pool=Pool-node1 and got:
# xl cpupool-list 
Name               CPUs   Sched     Active   Domain count
Pool-node0           8    credit       y          1
Pool-node1           8    credit       y          1

(so dom0 on node0, guest on node 1) but:
(XEN) Memory location of each domain:
(XEN) Domain 0 (total: 131072):
(XEN)     Node 0: 61098
(XEN)     Node 1: 69974
(XEN) Domain 1 (total: 6290427):
(XEN)     Node 0: 3407101
(XEN)     Node 1: 2883326

With your patches to support vcpu pin and giving the guest vcpus="8-15"
I see effectively the same thing. (xl vcpu-list shows the affinity is
correct, so your patches seem correct in that regard).

Your patches do the affinity setting pretty early so I'm not sure what's
going 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 Jan 20 13:11:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13: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 1RoEFm-0001OL-Pt; Fri, 20 Jan 2012 13:11: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 1RoEFl-0001O4-Ba
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 13:11:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327065091!11853778!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31440 invoked from network); 20 Jan 2012 13:11:31 -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 Jan 2012 13:11:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10177246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:11:31 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 13:11:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 13:11:30 +0000
In-Reply-To: <1327062788.30054.31.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327065091.30054.43.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 12:33 +0000, Ian Campbell wrote:
> On Fri, 2012-01-20 at 12:04 +0000, Dario Faggioli wrote:
> > On Fri, 2012-01-20 at 11:54 +0000, Ian Campbell wrote: 
> 
> > > > Of course, even in such mode, if the user explicitly tells us what he
> > > > wants, e.g., by means of cpupools, pinning, etc., we should still honour
> > > > such request.
> > > 
> > > Do we get this right now?
> > > 
> > Sorry, not sure what you mean here...
> 
> I meant is "if the user explicitly tells us what he wants, e.g., by
> means of cpupools, pinning, etc." do we still honour such request?

It appears that with cpupools we do not. After running
cpupool-numa-split I started a guest with pool=Pool-node1 and got:
# xl cpupool-list 
Name               CPUs   Sched     Active   Domain count
Pool-node0           8    credit       y          1
Pool-node1           8    credit       y          1

(so dom0 on node0, guest on node 1) but:
(XEN) Memory location of each domain:
(XEN) Domain 0 (total: 131072):
(XEN)     Node 0: 61098
(XEN)     Node 1: 69974
(XEN) Domain 1 (total: 6290427):
(XEN)     Node 0: 3407101
(XEN)     Node 1: 2883326

With your patches to support vcpu pin and giving the guest vcpus="8-15"
I see effectively the same thing. (xl vcpu-list shows the affinity is
correct, so your patches seem correct in that regard).

Your patches do the affinity setting pretty early so I'm not sure what's
going 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 Jan 20 13:33:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoEai-00026e-V6; Fri, 20 Jan 2012 13:33: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 1RoEag-00026W-R7
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 13:33:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327066388!9819217!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29285 invoked from network); 20 Jan 2012 13:33:08 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 13:33:08 -0000
Received: by werb14 with SMTP id b14so2263356wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 05:33:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JQrp9CuCkmGCcTlrKA9CTor+22llBckqlxL5NJLD+Zo=;
	b=cF388vu8pmAd2aAMq/ld9hQFz0w7wx9uBdtQ0F+R3FLSXP6Q1tY0ZnovswgO9k8IV7
	QvKMURvB3q39GWPK994nnoGUcKbqA6WpPblC5CLfiFEs5QgI3cO0WuMKLx5FnjEleEHw
	SMJRz0vMpWqR9s8qHnthFVyVNA5YmWo+e/rxo=
Received: by 10.216.136.94 with SMTP id v72mr13386343wei.43.1327066388350;
	Fri, 20 Jan 2012 05:33:08 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id r1sm33637398wia.8.2012.01.20.05.33.07
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 05:33:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 13:33:05 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Message-ID: <CB3F1D91.293D7%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXeAn0N+2dBqT5/U6Bt3DFYQdx4A==
In-Reply-To: <1327063527.30054.37.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 12:45, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>> It's obviously an option of fairly narrow interest. If someone tries to
>>> enable the per-domain option on a CPU which has problems, you can fail the
>>> domain creation, or print a warning in the hypervisor log, or whatever. Any
>>> sensible option in that respect is fine by me!
>> 
>> What is the best solution for this?
>> A domain specific configuration option is needed (vpmu?) which is usable in
>> libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid
>> command.
>> Can you point me to an proper example?
> 
> Can't this already be done via the cpuid domain option given the correct
> runes? Maybe with an addition to the table in libxl_cpuid_parse_config?

Yes that's probably the way to do it. If the resulting required
configuration runes are too cryptic or vendor-specific, it may make sense to
have the libxl cpuid logic consume a 'vpmu' option which it then turns into
a set of lower-level cpuid settings to eventually pass down to the code in
libxc/xc_cpuid.

It's a trifle messy I will admit. Arguably the 'default policy' bits of
xc_cpuid_x86.c would better belong in libxl these days, where we would have
better access to a domain's configuration state. As it is, we may end up
with a spread of default policy across Xen (for dom0), libxc, and libxl.

 -- Keir 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 13:33:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoEai-00026e-V6; Fri, 20 Jan 2012 13:33: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 1RoEag-00026W-R7
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 13:33:15 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327066388!9819217!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29285 invoked from network); 20 Jan 2012 13:33:08 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 13:33:08 -0000
Received: by werb14 with SMTP id b14so2263356wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 05:33:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=JQrp9CuCkmGCcTlrKA9CTor+22llBckqlxL5NJLD+Zo=;
	b=cF388vu8pmAd2aAMq/ld9hQFz0w7wx9uBdtQ0F+R3FLSXP6Q1tY0ZnovswgO9k8IV7
	QvKMURvB3q39GWPK994nnoGUcKbqA6WpPblC5CLfiFEs5QgI3cO0WuMKLx5FnjEleEHw
	SMJRz0vMpWqR9s8qHnthFVyVNA5YmWo+e/rxo=
Received: by 10.216.136.94 with SMTP id v72mr13386343wei.43.1327066388350;
	Fri, 20 Jan 2012 05:33:08 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id r1sm33637398wia.8.2012.01.20.05.33.07
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 05:33:07 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 13:33:05 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Message-ID: <CB3F1D91.293D7%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXeAn0N+2dBqT5/U6Bt3DFYQdx4A==
In-Reply-To: <1327063527.30054.37.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 12:45, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>>> It's obviously an option of fairly narrow interest. If someone tries to
>>> enable the per-domain option on a CPU which has problems, you can fail the
>>> domain creation, or print a warning in the hypervisor log, or whatever. Any
>>> sensible option in that respect is fine by me!
>> 
>> What is the best solution for this?
>> A domain specific configuration option is needed (vpmu?) which is usable in
>> libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid
>> command.
>> Can you point me to an proper example?
> 
> Can't this already be done via the cpuid domain option given the correct
> runes? Maybe with an addition to the table in libxl_cpuid_parse_config?

Yes that's probably the way to do it. If the resulting required
configuration runes are too cryptic or vendor-specific, it may make sense to
have the libxl cpuid logic consume a 'vpmu' option which it then turns into
a set of lower-level cpuid settings to eventually pass down to the code in
libxc/xc_cpuid.

It's a trifle messy I will admit. Arguably the 'default policy' bits of
xc_cpuid_x86.c would better belong in libxl these days, where we would have
better access to a domain's configuration state. As it is, we may end up
with a spread of default policy across Xen (for dom0), libxc, and libxl.

 -- Keir 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 13:38:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13:38:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoEfA-0002Ee-Lg; Fri, 20 Jan 2012 13:37: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 1RoEf9-0002ET-P1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 13:37:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327066665!11712142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20704 invoked from network); 20 Jan 2012 13:37:45 -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;
	20 Jan 2012 13:37:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10177966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:37:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 13:37:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 20 Jan 2012 13:37:37 +0000
In-Reply-To: <CB3F1D91.293D7%keir.xen@gmail.com>
References: <CB3F1D91.293D7%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327066657.30054.45.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 13:33 +0000, Keir Fraser wrote:
> On 20/01/2012 12:45, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >>> It's obviously an option of fairly narrow interest. If someone tries to
> >>> enable the per-domain option on a CPU which has problems, you can fail the
> >>> domain creation, or print a warning in the hypervisor log, or whatever. Any
> >>> sensible option in that respect is fine by me!
> >> 
> >> What is the best solution for this?
> >> A domain specific configuration option is needed (vpmu?) which is usable in
> >> libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid
> >> command.
> >> Can you point me to an proper example?
> > 
> > Can't this already be done via the cpuid domain option given the correct
> > runes? Maybe with an addition to the table in libxl_cpuid_parse_config?
> 
> Yes that's probably the way to do it. If the resulting required
> configuration runes are too cryptic or vendor-specific, it may make sense to
> have the libxl cpuid logic consume a 'vpmu' option which it then turns into
> a set of lower-level cpuid settings to eventually pass down to the code in
> libxc/xc_cpuid.
> 
> It's a trifle messy I will admit. Arguably the 'default policy' bits of
> xc_cpuid_x86.c would better belong in libxl these days, where we would have
> better access to a domain's configuration state. As it is, we may end up
> with a spread of default policy across Xen (for dom0), libxc, and libxl.

Plus a bunch of ad-hoc stuff which predates the cpuid bit-fiddling
support but is reflected in the cpuid (pae, apic, acpi etc).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 13:38:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13:38:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoEfA-0002Ee-Lg; Fri, 20 Jan 2012 13:37: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 1RoEf9-0002ET-P1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 13:37:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327066665!11712142!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20704 invoked from network); 20 Jan 2012 13:37:45 -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;
	20 Jan 2012 13:37:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10177966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:37:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 13:37:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 20 Jan 2012 13:37:37 +0000
In-Reply-To: <CB3F1D91.293D7%keir.xen@gmail.com>
References: <CB3F1D91.293D7%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327066657.30054.45.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 13:33 +0000, Keir Fraser wrote:
> On 20/01/2012 12:45, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >>> It's obviously an option of fairly narrow interest. If someone tries to
> >>> enable the per-domain option on a CPU which has problems, you can fail the
> >>> domain creation, or print a warning in the hypervisor log, or whatever. Any
> >>> sensible option in that respect is fine by me!
> >> 
> >> What is the best solution for this?
> >> A domain specific configuration option is needed (vpmu?) which is usable in
> >> libxc/xc_cpuid_x86.c to select/deselect special vpmu bits in the cpuid
> >> command.
> >> Can you point me to an proper example?
> > 
> > Can't this already be done via the cpuid domain option given the correct
> > runes? Maybe with an addition to the table in libxl_cpuid_parse_config?
> 
> Yes that's probably the way to do it. If the resulting required
> configuration runes are too cryptic or vendor-specific, it may make sense to
> have the libxl cpuid logic consume a 'vpmu' option which it then turns into
> a set of lower-level cpuid settings to eventually pass down to the code in
> libxc/xc_cpuid.
> 
> It's a trifle messy I will admit. Arguably the 'default policy' bits of
> xc_cpuid_x86.c would better belong in libxl these days, where we would have
> better access to a domain's configuration state. As it is, we may end up
> with a spread of default policy across Xen (for dom0), libxc, and libxl.

Plus a bunch of ad-hoc stuff which predates the cpuid bit-fiddling
support but is reflected in the cpuid (pae, apic, acpi etc).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 13:47:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13:47:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoEoW-0002TO-SB; Fri, 20 Jan 2012 13:47:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RoEoV-0002TJ-2f
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 13:47:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327067214!49246797!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21688 invoked from network); 20 Jan 2012 13:46:54 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 13:46:54 -0000
Received: by werb14 with SMTP id b14so2303171wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 05:47:29 -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=bXJdYOq6a+RsoPHGaWl6pKDtgLf6G9gmCSot1ZJhShY=;
	b=avtigUgNblv2/n0P8QhtUuXUJgPc82rQ16nrsOuIqO0Mdu6W+R+e84SedspdV52bz/
	tNCtEO1gCsjbSek6uT2/+8y4R7Tg4D+FGIfkJwJE9MN9B6oUpv/yaWxM7yKmYBDfE/OY
	dzsmogtpc3/BQqXQuLGfpSrbOsVi6brgXRFR0=
Received: by 10.216.135.69 with SMTP id t47mr998415wei.42.1327067249492;
	Fri, 20 Jan 2012 05:47:29 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id g12sm9193492wiw.10.2012.01.20.05.47.28
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 05:47:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 13:47:24 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3F20EC.293DD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXegn1VVpNlRZaB0S19JSXgs90dQ==
In-Reply-To: <1327066657.30054.45.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> Yes that's probably the way to do it. If the resulting required
>> configuration runes are too cryptic or vendor-specific, it may make sense to
>> have the libxl cpuid logic consume a 'vpmu' option which it then turns into
>> a set of lower-level cpuid settings to eventually pass down to the code in
>> libxc/xc_cpuid.
>> 
>> It's a trifle messy I will admit. Arguably the 'default policy' bits of
>> xc_cpuid_x86.c would better belong in libxl these days, where we would have
>> better access to a domain's configuration state. As it is, we may end up
>> with a spread of default policy across Xen (for dom0), libxc, and libxl.
> 
> Plus a bunch of ad-hoc stuff which predates the cpuid bit-fiddling
> support but is reflected in the cpuid (pae, apic, acpi etc).

Well, this is done in libxc now, so I think I included it in my list. ;) But
it would be cleaner done in libxl.

I don't think anyone will be straining their arm to volunteer for this
cleanup, but we shouldn't be shy about putting new policy stuff in libxl if
it makes best sense to put it there.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 13:47:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 13:47:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoEoW-0002TO-SB; Fri, 20 Jan 2012 13:47:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RoEoV-0002TJ-2f
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 13:47:31 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327067214!49246797!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21688 invoked from network); 20 Jan 2012 13:46:54 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 13:46:54 -0000
Received: by werb14 with SMTP id b14so2303171wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 05:47:29 -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=bXJdYOq6a+RsoPHGaWl6pKDtgLf6G9gmCSot1ZJhShY=;
	b=avtigUgNblv2/n0P8QhtUuXUJgPc82rQ16nrsOuIqO0Mdu6W+R+e84SedspdV52bz/
	tNCtEO1gCsjbSek6uT2/+8y4R7Tg4D+FGIfkJwJE9MN9B6oUpv/yaWxM7yKmYBDfE/OY
	dzsmogtpc3/BQqXQuLGfpSrbOsVi6brgXRFR0=
Received: by 10.216.135.69 with SMTP id t47mr998415wei.42.1327067249492;
	Fri, 20 Jan 2012 05:47:29 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id g12sm9193492wiw.10.2012.01.20.05.47.28
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 05:47:28 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 13:47:24 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB3F20EC.293DD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
Thread-Index: AczXegn1VVpNlRZaB0S19JSXgs90dQ==
In-Reply-To: <1327066657.30054.45.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> Yes that's probably the way to do it. If the resulting required
>> configuration runes are too cryptic or vendor-specific, it may make sense to
>> have the libxl cpuid logic consume a 'vpmu' option which it then turns into
>> a set of lower-level cpuid settings to eventually pass down to the code in
>> libxc/xc_cpuid.
>> 
>> It's a trifle messy I will admit. Arguably the 'default policy' bits of
>> xc_cpuid_x86.c would better belong in libxl these days, where we would have
>> better access to a domain's configuration state. As it is, we may end up
>> with a spread of default policy across Xen (for dom0), libxc, and libxl.
> 
> Plus a bunch of ad-hoc stuff which predates the cpuid bit-fiddling
> support but is reflected in the cpuid (pae, apic, acpi etc).

Well, this is done in libxc now, so I think I included it in my list. ;) But
it would be cleaner done in libxl.

I don't think anyone will be straining their arm to volunteer for this
cleanup, but we shouldn't be shy about putting new policy stuff in libxl if
it makes best sense to put it there.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:06:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoF6p-0002tS-Lq; Fri, 20 Jan 2012 14:06:27 +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 1RoF6n-0002tN-JE
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:06:26 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327068372!13230504!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 6674 invoked from network); 20 Jan 2012 14:06:13 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 14:06:13 -0000
Received: from mail17-tx2-R.bigfish.com (10.9.14.236) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 14:06:09 +0000
Received: from mail17-tx2 (localhost [127.0.0.1])	by mail17-tx2-R.bigfish.com
	(Postfix) with ESMTP id AAD3D80702	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 14:06:09 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dhc1bhc31hc1ahc1bhc31hc1ah668h839h34h61h)
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,0,
Received: from mail17-tx2 (localhost.localdomain [127.0.0.1]) by mail17-tx2
	(MessageSwitch) id 132706832792561_1797; Fri, 20 Jan 2012 14:05:27 +0000
	(UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.247])	by
	mail17-tx2.bigfish.com (Postfix) with ESMTP id 0F1E16A004B	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 14:05:27 +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; Fri, 20 Jan 2012 14:05:27 +0000
X-WSS-ID: 0LY3OGX-01-8Z5-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 2EDDD1028071	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 08:05:20 -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, 20 Jan 2012 08:05:43 -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, 20 Jan 2012 08:05:24 -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; Fri, 20 Jan 2012
	09:05:23 -0500
Message-ID: <4F1974A2.10605@amd.com>
Date: Fri, 20 Jan 2012 15:05:22 +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="------------010601040506090405000508"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010601040506090405000508
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Kill __u*/__s* integer types and use c99 integer types instead.
Cleanup <asm-x86/types.h>

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010601040506090405000508
Content-Type: text/plain; name="xen_type.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_type.diff"
Content-Description: xen_type.diff

diff -r 87854d3bed93 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Jan 20 15:01:35 2012 +0100
@@ -189,25 +189,25 @@ static inline int mce_bank_msr(uint32_t 
 
 /* Fields are zero when not available */
 struct mce {
-    __u64 status;
-    __u64 misc;
-    __u64 addr;
-    __u64 mcgstatus;
-    __u64 ip;
-    __u64 tsc;      /* cpu time stamp counter */
-    __u64 time;     /* wall time_t when error was detected */
-    __u8  cpuvendor;        /* cpu vendor as encoded in system.h */
-    __u8  inject_flags;     /* software inject flags */
-    __u16  pad;
-    __u32 cpuid;    /* CPUID 1 EAX */
-    __u8  cs;               /* code segment */
-    __u8  bank;     /* machine check bank */
-    __u8  cpu;      /* cpu number; obsolete; use extcpu now */
-    __u8  finished;   /* entry is valid */
-    __u32 extcpu;   /* linux cpu number that detected the error */
-    __u32 socketid; /* CPU socket ID */
-    __u32 apicid;   /* CPU initial apic ID */
-    __u64 mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
+    uint64_t status;
+    uint64_t misc;
+    uint64_t addr;
+    uint64_t mcgstatus;
+    uint64_t ip;
+    uint64_t tsc;      /* cpu time stamp counter */
+    uint64_t time;     /* wall time_t when error was detected */
+    uint8_t  cpuvendor;        /* cpu vendor as encoded in system.h */
+    uint8_t  inject_flags;     /* software inject flags */
+    uint16_t  pad;
+    uint32_t cpuid;    /* CPUID 1 EAX */
+    uint8_t  cs;               /* code segment */
+    uint8_t  bank;     /* machine check bank */
+    uint8_t  cpu;      /* cpu number; obsolete; use extcpu now */
+    uint8_t  finished;   /* entry is valid */
+    uint32_t extcpu;   /* linux cpu number that detected the error */
+    uint32_t socketid; /* CPU socket ID */
+    uint32_t apicid;   /* CPU initial apic ID */
+    uint64_t mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
 };
 
 extern int apei_write_mce(struct mce *m);
diff -r 87854d3bed93 xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/arch/x86/oprofile/nmi_int.c	Fri Jan 20 15:01:35 2012 +0100
@@ -295,7 +295,7 @@ void nmi_stop(void)
 
 static int __init p4_init(char ** cpu_type)
 { 
-	__u8 cpu_model = current_cpu_data.x86_model;
+	uint8_t cpu_model = current_cpu_data.x86_model;
 
 	if ((cpu_model > 6) || (cpu_model == 5)) {
 		printk("xenoprof: Initialization failed. "
@@ -341,7 +341,7 @@ custom_param("cpu_type", force_cpu_type)
 
 static int __init ppro_init(char ** cpu_type)
 {
-	__u8 cpu_model = current_cpu_data.x86_model;
+	uint8_t cpu_model = current_cpu_data.x86_model;
 
 	if (force_arch_perfmon && cpu_has_arch_perfmon)
 		return 0;
@@ -399,9 +399,9 @@ static int __init arch_perfmon_init(char
 
 static int __init nmi_init(void)
 {
-	__u8 vendor = current_cpu_data.x86_vendor;
-	__u8 family = current_cpu_data.x86;
-	__u8 _model = current_cpu_data.x86_model;
+	uint8_t vendor = current_cpu_data.x86_vendor;
+	uint8_t family = current_cpu_data.x86;
+	uint8_t _model = current_cpu_data.x86_model;
  
 	if (!cpu_has_apic) {
 		printk("xenoprof: Initialization failed. No APIC\n");
diff -r 87854d3bed93 xen/include/asm-x86/byteorder.h
--- a/xen/include/asm-x86/byteorder.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/byteorder.h	Fri Jan 20 15:01:35 2012 +0100
@@ -4,17 +4,17 @@
 #include <asm/types.h>
 #include <xen/compiler.h>
 
-static inline __attribute_const__ __u32 ___arch__swab32(__u32 x)
+static inline __attribute_const__ uint32_t ___arch__swab32(uint32_t x)
 {
     asm("bswap %0" : "=r" (x) : "0" (x));
     return x;
 }
 
-static inline __attribute_const__ __u64 ___arch__swab64(__u64 val)
+static inline __attribute_const__ uint64_t ___arch__swab64(uint64_t val)
 { 
     union { 
-        struct { __u32 a,b; } s;
-        __u64 u;
+        struct { uint32_t a,b; } s;
+        uint64_t u;
     } v;
     v.u = val;
     asm("bswapl %0 ; bswapl %1 ; xchgl %0,%1" 
diff -r 87854d3bed93 xen/include/asm-x86/io_apic.h
--- a/xen/include/asm-x86/io_apic.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/io_apic.h	Fri Jan 20 15:01:35 2012 +0100
@@ -91,7 +91,7 @@ enum ioapic_irq_destination_types {
 };
 
 struct IO_APIC_route_entry {
-	__u32	vector		:  8,
+	uint32_t vector		:  8,
 		delivery_mode	:  3,	/* 000: FIXED
 					 * 001: lowest prio
 					 * 111: ExtINT
@@ -104,19 +104,19 @@ struct IO_APIC_route_entry {
 		mask		:  1,	/* 0: enabled, 1: disabled */
 		__reserved_2	: 15;
 
-	union {		struct { __u32
+	union {		struct { uint32_t
 					__reserved_1	: 24,
 					physical_dest	:  4,
 					__reserved_2	:  4;
 			} physical;
 
-			struct { __u32
+			struct { uint32_t
 					__reserved_1	: 24,
 					logical_dest	:  8;
 			} logical;
 
 			/* used when Interrupt Remapping with EIM is enabled */
-			__u32 dest32;
+			uint32_t dest32;
 	} dest;
 
 } __attribute__ ((packed));
diff -r 87854d3bed93 xen/include/asm-x86/msi.h
--- a/xen/include/asm-x86/msi.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/msi.h	Fri Jan 20 15:01:35 2012 +0100
@@ -90,12 +90,12 @@ extern unsigned int pci_msix_get_table_l
 
 struct msi_desc {
 	struct msi_attrib {
-		__u8	type	: 5; 	/* {0: unused, 5h:MSI, 11h:MSI-X} */
-		__u8	maskbit	: 1; 	/* mask-pending bit supported ?   */
-		__u8	masked	: 1;
-		__u8	is_64	: 1;	/* Address size: 0=32bit 1=64bit  */
-		__u8	pos;	 	/* Location of the msi capability */
-		__u16	entry_nr;    	/* specific enabled entry 	  */
+		uint8_t	type	: 5; 	/* {0: unused, 5h:MSI, 11h:MSI-X} */
+		uint8_t	maskbit	: 1; 	/* mask-pending bit supported ?   */
+		uint8_t	masked	: 1;
+		uint8_t	is_64	: 1;	/* Address size: 0=32bit 1=64bit  */
+		uint8_t	pos;	 	/* Location of the msi capability */
+		uint16_t entry_nr;    	/* specific enabled entry 	  */
 	} msi_attrib;
 
 	struct list_head list;
@@ -175,19 +175,19 @@ int msi_free_irq(struct msi_desc *entry)
 
 struct msg_data {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
-	__u32	vector		:  8;
-	__u32	delivery_mode	:  3;	/* 000b: FIXED | 001b: lowest prior */
-	__u32	reserved_1	:  3;
-	__u32	level		:  1;	/* 0: deassert | 1: assert */
-	__u32	trigger		:  1;	/* 0: edge | 1: level */
-	__u32	reserved_2	: 16;
+	uint32_t vector		:  8;
+	uint32_t delivery_mode	:  3;	/* 000b: FIXED | 001b: lowest prior */
+	uint32_t reserved_1	:  3;
+	uint32_t level		:  1;	/* 0: deassert | 1: assert */
+	uint32_t trigger		:  1;	/* 0: edge | 1: level */
+	uint32_t reserved_2	: 16;
 #elif defined(__BIG_ENDIAN_BITFIELD)
-	__u32	reserved_2	: 16;
-	__u32	trigger		:  1;	/* 0: edge | 1: level */
-	__u32	level		:  1;	/* 0: deassert | 1: assert */
-	__u32	reserved_1	:  3;
-	__u32	delivery_mode	:  3;	/* 000b: FIXED | 001b: lowest prior */
-	__u32	vector		:  8;
+	uint32_t reserved_2	: 16;
+	uint32_t trigger		:  1;	/* 0: edge | 1: level */
+	uint32_t level		:  1;	/* 0: deassert | 1: assert */
+	uint32_t reserved_1	:  3;
+	uint32_t delivery_mode	:  3;	/* 000b: FIXED | 001b: lowest prior */
+	uint32_t vector		:  8;
 #else
 #error "Bitfield endianness not defined! Check your byteorder.h"
 #endif
@@ -197,26 +197,26 @@ struct msg_address {
 	union {
 		struct {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
-			__u32	reserved_1	:  2;
-			__u32	dest_mode	:  1;	/*0:physic | 1:logic */
-			__u32	redirection_hint:  1;  	/*0: dedicated CPU
+			uint32_t reserved_1	:  2;
+			uint32_t dest_mode	:  1;	/*0:physic | 1:logic */
+			uint32_t redirection_hint:  1;  	/*0: dedicated CPU
 							  1: lowest priority */
-			__u32	reserved_2	:  4;
- 			__u32	dest_id		: 24;	/* Destination ID */
+			uint32_t reserved_2	:  4;
+ 			uint32_t dest_id	: 24;	/* Destination ID */
 #elif defined(__BIG_ENDIAN_BITFIELD)
- 			__u32	dest_id		: 24;	/* Destination ID */
-			__u32	reserved_2	:  4;
-			__u32	redirection_hint:  1;  	/*0: dedicated CPU
-							  1: lowest priority */
-			__u32	dest_mode	:  1;	/*0:physic | 1:logic */
-			__u32	reserved_1	:  2;
+ 			uint32_t dest_id	: 24;	/* Destination ID */
+			uint32_t reserved_2	:  4;
+			uint32_t redirection_hint:  1; 	/*0: dedicated CPU
+						  	  1: lowest priority */
+			uint32_t dest_mode	:  1;	/*0:physic | 1:logic */
+			uint32_t reserved_1	:  2;
 #else
 #error "Bitfield endianness not defined! Check your byteorder.h"
 #endif
       		}u;
-       		__u32  value;
+       		uint32_t value;
 	}lo_address;
-	__u32 	hi_address;
+	uint32_t hi_address;
 } __attribute__ ((packed));
 
 void msi_compose_msg(struct irq_desc *, struct msi_msg *);
diff -r 87854d3bed93 xen/include/asm-x86/msr.h
--- a/xen/include/asm-x86/msr.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/msr.h	Fri Jan 20 15:01:35 2012 +0100
@@ -27,11 +27,11 @@
 			  : /* no outputs */ \
 			  : "c" (msr), "a" (val1), "d" (val2))
 
-static inline void wrmsrl(unsigned int msr, __u64 val)
+static inline void wrmsrl(unsigned int msr, uint64_t val)
 {
-        __u32 lo, hi;
-        lo = (__u32)val;
-        hi = (__u32)(val >> 32);
+        uint32_t lo, hi;
+        lo = (uint32_t)val;
+        hi = (uint32_t)(val >> 32);
         wrmsr(msr, lo, hi);
 }
 
diff -r 87854d3bed93 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/processor.h	Fri Jan 20 15:01:35 2012 +0100
@@ -162,10 +162,10 @@ struct vcpu;
 #endif
 
 struct cpuinfo_x86 {
-    __u8 x86;            /* CPU family */
-    __u8 x86_vendor;     /* CPU vendor */
-    __u8 x86_model;
-    __u8 x86_mask;
+    uint8_t x86;            /* CPU family */
+    uint8_t x86_vendor;     /* CPU vendor */
+    uint8_t x86_model;
+    uint8_t x86_mask;
     int  cpuid_level;    /* Maximum supported CPUID level, -1=no CPUID */
     unsigned int x86_capability[NCAPINTS];
     char x86_vendor_id[16];
@@ -173,10 +173,10 @@ struct cpuinfo_x86 {
     int  x86_cache_size; /* in KB - valid for CPUS which support this call  */
     int  x86_cache_alignment;    /* In bytes */
     int  x86_power;
-    __u32 x86_max_cores; /* cpuid returned max cores value */
-    __u32 booted_cores;  /* number of cores as seen by OS */
-    __u32 x86_num_siblings; /* cpuid logical cpus per chip value */
-    __u32 apicid;
+    uint32_t x86_max_cores; /* cpuid returned max cores value */
+    uint32_t booted_cores;  /* number of cores as seen by OS */
+    uint32_t x86_num_siblings; /* cpuid logical cpus per chip value */
+    uint32_t apicid;
     int   phys_proc_id; /* package ID of each logical CPU */
     int   cpu_core_id; /* core ID of each logical CPU*/
     int   compute_unit_id; /* AMD compute unit ID of each logical CPU */
diff -r 87854d3bed93 xen/include/asm-x86/types.h
--- a/xen/include/asm-x86/types.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/types.h	Fri Jan 20 15:01:35 2012 +0100
@@ -5,53 +5,47 @@
 
 #include <xen/config.h>
 
-typedef __signed__ char __s8;
-typedef unsigned char __u8;
+typedef __signed__ char int8_t;
+typedef unsigned char uint8_t;
 
-typedef __signed__ short __s16;
-typedef unsigned short __u16;
+typedef __signed__ short int16_t;
+typedef unsigned short uint16_t;
 
-typedef __signed__ int __s32;
-typedef unsigned int __u32;
-
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
-#if defined(__i386__)
-typedef __signed__ long long __s64;
-typedef unsigned long long __u64;
-#elif defined(__x86_64__)
-typedef __signed__ long __s64;
-typedef unsigned long __u64;
-#endif
-#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__ int int32_t;
+typedef unsigned int uint32_t;
 
 #if defined(__i386__)
-typedef signed long long s64;
-typedef unsigned long long u64;
-typedef u64 paddr_t;
+typedef __signed__ long long int64_t;
+typedef unsigned long long uint64_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
 #elif defined(__x86_64__)
-typedef signed long s64;
-typedef unsigned long u64;
-typedef unsigned long paddr_t;
+typedef __signed__ long int64_t;
+typedef unsigned long uint64_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
 #endif
 
+typedef uint64_t paddr_t;
+
+/* Linux types */
+typedef int8_t s8;
+typedef uint8_t u8;
+
+typedef int16_t s16;
+typedef uint16_t u16;
+
+typedef int32_t s32;
+typedef uint32_t u32;
+
+typedef int64_t s64;
+typedef uint64_t u64;
+
 #if defined(__SIZE_TYPE__)
 typedef __SIZE_TYPE__ size_t;
 #elif defined(__i386__)
 typedef unsigned int size_t;
-#else
+#elif defined(__x86_64__)
 typedef unsigned long size_t;
 #endif
 
diff -r 87854d3bed93 xen/include/xen/bitops.h
--- a/xen/include/xen/bitops.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/bitops.h	Fri Jan 20 15:01:35 2012 +0100
@@ -77,9 +77,9 @@ static __inline__ int generic_fls(int x)
 #include <asm/bitops.h>
 
 
-static inline int generic_fls64(__u64 x)
+static inline int generic_fls64(uint64_t x)
 {
-    __u32 h = x >> 32;
+    uint32_t h = x >> 32;
     if (h)
         return fls(x) + 32;
     return fls(x);
@@ -132,7 +132,7 @@ static inline unsigned int generic_hweig
     return (res & 0x0F) + ((res >> 4) & 0x0F);
 }
 
-static inline unsigned long generic_hweight64(__u64 w)
+static inline unsigned long generic_hweight64(uint64_t w)
 {
 #if BITS_PER_LONG < 64
     return generic_hweight32((unsigned int)(w >> 32)) +
@@ -159,7 +159,7 @@ static inline unsigned long hweight_long
  * @word: value to rotate
  * @shift: bits to roll
  */
-static inline __u32 rol32(__u32 word, unsigned int shift)
+static inline uint32_t rol32(uint32_t word, unsigned int shift)
 {
     return (word << shift) | (word >> (32 - shift));
 }
@@ -170,7 +170,7 @@ static inline __u32 rol32(__u32 word, un
  * @word: value to rotate
  * @shift: bits to roll
  */
-static inline __u32 ror32(__u32 word, unsigned int shift)
+static inline uint32_t ror32(uint32_t word, unsigned int shift)
 {
     return (word >> shift) | (word << (32 - shift));
 }
diff -r 87854d3bed93 xen/include/xen/byteorder/little_endian.h
--- a/xen/include/xen/byteorder/little_endian.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/byteorder/little_endian.h	Fri Jan 20 15:01:35 2012 +0100
@@ -11,78 +11,78 @@
 #include <xen/types.h>
 #include <xen/byteorder/swab.h>
 
-#define __constant_cpu_to_le64(x) ((__force __le64)(__u64)(x))
-#define __constant_le64_to_cpu(x) ((__force __u64)(__le64)(x))
-#define __constant_cpu_to_le32(x) ((__force __le32)(__u32)(x))
-#define __constant_le32_to_cpu(x) ((__force __u32)(__le32)(x))
-#define __constant_cpu_to_le16(x) ((__force __le16)(__u16)(x))
-#define __constant_le16_to_cpu(x) ((__force __u16)(__le16)(x))
+#define __constant_cpu_to_le64(x) ((__force __le64)(uint64_t)(x))
+#define __constant_le64_to_cpu(x) ((__force uint64_t)(__le64)(x))
+#define __constant_cpu_to_le32(x) ((__force __le32)(uint32_t)(x))
+#define __constant_le32_to_cpu(x) ((__force uint32_t)(__le32)(x))
+#define __constant_cpu_to_le16(x) ((__force __le16)(uint16_t)(x))
+#define __constant_le16_to_cpu(x) ((__force uint16_t)(__le16)(x))
 #define __constant_cpu_to_be64(x) ((__force __be64)___constant_swab64((x)))
-#define __constant_be64_to_cpu(x) ___constant_swab64((__force __u64)(__be64)(x))
+#define __constant_be64_to_cpu(x) ___constant_swab64((__force uint64_t)(__be64)(x))
 #define __constant_cpu_to_be32(x) ((__force __be32)___constant_swab32((x)))
-#define __constant_be32_to_cpu(x) ___constant_swab32((__force __u32)(__be32)(x))
+#define __constant_be32_to_cpu(x) ___constant_swab32((__force uint32_t)(__be32)(x))
 #define __constant_cpu_to_be16(x) ((__force __be16)___constant_swab16((x)))
-#define __constant_be16_to_cpu(x) ___constant_swab16((__force __u16)(__be16)(x))
-#define __cpu_to_le64(x) ((__force __le64)(__u64)(x))
-#define __le64_to_cpu(x) ((__force __u64)(__le64)(x))
-#define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
-#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
-#define __cpu_to_le16(x) ((__force __le16)(__u16)(x))
-#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
+#define __constant_be16_to_cpu(x) ___constant_swab16((__force uint16_t)(__be16)(x))
+#define __cpu_to_le64(x) ((__force __le64)(uint64_t)(x))
+#define __le64_to_cpu(x) ((__force uint64_t)(__le64)(x))
+#define __cpu_to_le32(x) ((__force __le32)(uint32_t)(x))
+#define __le32_to_cpu(x) ((__force uint32_t)(__le32)(x))
+#define __cpu_to_le16(x) ((__force __le16)(uint16_t)(x))
+#define __le16_to_cpu(x) ((__force uint16_t)(__le16)(x))
 #define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
-#define __be64_to_cpu(x) __swab64((__force __u64)(__be64)(x))
+#define __be64_to_cpu(x) __swab64((__force uint64_t)(__be64)(x))
 #define __cpu_to_be32(x) ((__force __be32)__swab32((x)))
-#define __be32_to_cpu(x) __swab32((__force __u32)(__be32)(x))
+#define __be32_to_cpu(x) __swab32((__force uint32_t)(__be32)(x))
 #define __cpu_to_be16(x) ((__force __be16)__swab16((x)))
-#define __be16_to_cpu(x) __swab16((__force __u16)(__be16)(x))
+#define __be16_to_cpu(x) __swab16((__force uint16_t)(__be16)(x))
 
-static inline __le64 __cpu_to_le64p(const __u64 *p)
+static inline __le64 __cpu_to_le64p(const uint64_t *p)
 {
     return (__force __le64)*p;
 }
-static inline __u64 __le64_to_cpup(const __le64 *p)
+static inline uint64_t __le64_to_cpup(const __le64 *p)
 {
-    return (__force __u64)*p;
+    return (__force uint64_t)*p;
 }
-static inline __le32 __cpu_to_le32p(const __u32 *p)
+static inline __le32 __cpu_to_le32p(const uint32_t *p)
 {
     return (__force __le32)*p;
 }
-static inline __u32 __le32_to_cpup(const __le32 *p)
+static inline uint32_t __le32_to_cpup(const __le32 *p)
 {
-    return (__force __u32)*p;
+    return (__force uint32_t)*p;
 }
-static inline __le16 __cpu_to_le16p(const __u16 *p)
+static inline __le16 __cpu_to_le16p(const uint16_t *p)
 {
     return (__force __le16)*p;
 }
-static inline __u16 __le16_to_cpup(const __le16 *p)
+static inline uint16_t __le16_to_cpup(const __le16 *p)
 {
-    return (__force __u16)*p;
+    return (__force uint16_t)*p;
 }
-static inline __be64 __cpu_to_be64p(const __u64 *p)
+static inline __be64 __cpu_to_be64p(const uint64_t *p)
 {
     return (__force __be64)__swab64p(p);
 }
-static inline __u64 __be64_to_cpup(const __be64 *p)
+static inline uint64_t __be64_to_cpup(const __be64 *p)
 {
-    return __swab64p((__u64 *)p);
+    return __swab64p((uint64_t *)p);
 }
-static inline __be32 __cpu_to_be32p(const __u32 *p)
+static inline __be32 __cpu_to_be32p(const uint32_t *p)
 {
     return (__force __be32)__swab32p(p);
 }
-static inline __u32 __be32_to_cpup(const __be32 *p)
+static inline uint32_t __be32_to_cpup(const __be32 *p)
 {
-    return __swab32p((__u32 *)p);
+    return __swab32p((uint32_t *)p);
 }
-static inline __be16 __cpu_to_be16p(const __u16 *p)
+static inline __be16 __cpu_to_be16p(const uint16_t *p)
 {
     return (__force __be16)__swab16p(p);
 }
-static inline __u16 __be16_to_cpup(const __be16 *p)
+static inline uint16_t __be16_to_cpup(const __be16 *p)
 {
-    return __swab16p((__u16 *)p);
+    return __swab16p((uint16_t *)p);
 }
 #define __cpu_to_le64s(x) do {} while (0)
 #define __le64_to_cpus(x) do {} while (0)
diff -r 87854d3bed93 xen/include/xen/byteorder/swab.h
--- a/xen/include/xen/byteorder/swab.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/byteorder/swab.h	Fri Jan 20 15:01:35 2012 +0100
@@ -11,72 +11,73 @@
  */
 
 /* casts are necessary for constants, because we never know how for sure
- * how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable way.
+ * how U/UL/ULL map to uint16_t, uint32_t, uint64_t.
+ * At least not in a portable way.
  */
 #define ___swab16(x)                                    \
 ({                                                      \
-    __u16 __x = (x);                                    \
-    ((__u16)(                                           \
-        (((__u16)(__x) & (__u16)0x00ffU) << 8) |        \
-        (((__u16)(__x) & (__u16)0xff00U) >> 8) ));      \
+    uint16_t __x = (x);                                 \
+    ((uint16_t)(                                        \
+        (((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) |  \
+        (((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) ));\
 })
 
 #define ___swab32(x)                                            \
 ({                                                              \
-    __u32 __x = (x);                                            \
-    ((__u32)(                                                   \
-        (((__u32)(__x) & (__u32)0x000000ffUL) << 24) |          \
-        (((__u32)(__x) & (__u32)0x0000ff00UL) <<  8) |          \
-        (((__u32)(__x) & (__u32)0x00ff0000UL) >>  8) |          \
-        (((__u32)(__x) & (__u32)0xff000000UL) >> 24) ));        \
+    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 ___swab64(x)                                                       \
 ({                                                                         \
-    __u64 __x = (x);                                                       \
-    ((__u64)(                                                              \
-        (__u64)(((__u64)(__x) & (__u64)0x00000000000000ffULL) << 56) |     \
-        (__u64)(((__u64)(__x) & (__u64)0x000000000000ff00ULL) << 40) |     \
-        (__u64)(((__u64)(__x) & (__u64)0x0000000000ff0000ULL) << 24) |     \
-        (__u64)(((__u64)(__x) & (__u64)0x00000000ff000000ULL) <<  8) |     \
-            (__u64)(((__u64)(__x) & (__u64)0x000000ff00000000ULL) >>  8) | \
-        (__u64)(((__u64)(__x) & (__u64)0x0000ff0000000000ULL) >> 24) |     \
-        (__u64)(((__u64)(__x) & (__u64)0x00ff000000000000ULL) >> 40) |     \
-        (__u64)(((__u64)(__x) & (__u64)0xff00000000000000ULL) >> 56) ));   \
+    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) ));   \
 })
 
-#define ___constant_swab16(x)                   \
-    ((__u16)(                                   \
-        (((__u16)(x) & (__u16)0x00ffU) << 8) |  \
-        (((__u16)(x) & (__u16)0xff00U) >> 8) ))
-#define ___constant_swab32(x)                           \
-    ((__u32)(                                           \
-        (((__u32)(x) & (__u32)0x000000ffUL) << 24) |    \
-        (((__u32)(x) & (__u32)0x0000ff00UL) <<  8) |    \
-        (((__u32)(x) & (__u32)0x00ff0000UL) >>  8) |    \
-        (((__u32)(x) & (__u32)0xff000000UL) >> 24) ))
+#define ___constant_swab16(x)                           \
+    ((uint16_t)(                                        \
+        (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) |    \
+        (((uint16_t)(x) & (uint16_t)0xff00U) >> 8) ))
+#define ___constant_swab32(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 ___constant_swab64(x)                                            \
-    ((__u64)(                                                            \
-        (__u64)(((__u64)(x) & (__u64)0x00000000000000ffULL) << 56) |     \
-        (__u64)(((__u64)(x) & (__u64)0x000000000000ff00ULL) << 40) |     \
-        (__u64)(((__u64)(x) & (__u64)0x0000000000ff0000ULL) << 24) |     \
-        (__u64)(((__u64)(x) & (__u64)0x00000000ff000000ULL) <<  8) |     \
-            (__u64)(((__u64)(x) & (__u64)0x000000ff00000000ULL) >>  8) | \
-        (__u64)(((__u64)(x) & (__u64)0x0000ff0000000000ULL) >> 24) |     \
-        (__u64)(((__u64)(x) & (__u64)0x00ff000000000000ULL) >> 40) |     \
-        (__u64)(((__u64)(x) & (__u64)0xff00000000000000ULL) >> 56) ))
+    ((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) ))
 
 /*
  * provide defaults when no architecture-specific optimization is detected
  */
 #ifndef __arch__swab16
-#  define __arch__swab16(x) ({ __u16 __tmp = (x) ; ___swab16(__tmp); })
+#  define __arch__swab16(x) ({ uint16_t __tmp = (x) ; ___swab16(__tmp); })
 #endif
 #ifndef __arch__swab32
-#  define __arch__swab32(x) ({ __u32 __tmp = (x) ; ___swab32(__tmp); })
+#  define __arch__swab32(x) ({ uint32_t __tmp = (x) ; ___swab32(__tmp); })
 #endif
 #ifndef __arch__swab64
-#  define __arch__swab64(x) ({ __u64 __tmp = (x) ; ___swab64(__tmp); })
+#  define __arch__swab64(x) ({ uint64_t __tmp = (x) ; ___swab64(__tmp); })
 #endif
 
 #ifndef __arch__swab16p
@@ -105,15 +106,15 @@
  */
 #if defined(__GNUC__) && defined(__OPTIMIZE__)
 #  define __swab16(x) \
-(__builtin_constant_p((__u16)(x)) ? \
+(__builtin_constant_p((uint16_t)(x)) ? \
  ___swab16((x)) : \
  __fswab16((x)))
 #  define __swab32(x) \
-(__builtin_constant_p((__u32)(x)) ? \
+(__builtin_constant_p((uint32_t)(x)) ? \
  ___swab32((x)) : \
  __fswab32((x)))
 #  define __swab64(x) \
-(__builtin_constant_p((__u64)(x)) ? \
+(__builtin_constant_p((uint64_t)(x)) ? \
  ___swab64((x)) : \
  __fswab64((x)))
 #else
@@ -123,48 +124,48 @@
 #endif /* OPTIMIZE */
 
 
-static inline __attribute_const__ __u16 __fswab16(__u16 x)
+static inline __attribute_const__ uint16_t __fswab16(uint16_t x)
 {
     return __arch__swab16(x);
 }
-static inline __u16 __swab16p(const __u16 *x)
+static inline uint16_t __swab16p(const uint16_t *x)
 {
     return __arch__swab16p(x);
 }
-static inline void __swab16s(__u16 *addr)
+static inline void __swab16s(uint16_t *addr)
 {
     __arch__swab16s(addr);
 }
 
-static inline __attribute_const__ __u32 __fswab32(__u32 x)
+static inline __attribute_const__ uint32_t __fswab32(uint32_t x)
 {
     return __arch__swab32(x);
 }
-static inline __u32 __swab32p(const __u32 *x)
+static inline uint32_t __swab32p(const uint32_t *x)
 {
     return __arch__swab32p(x);
 }
-static inline void __swab32s(__u32 *addr)
+static inline void __swab32s(uint32_t *addr)
 {
     __arch__swab32s(addr);
 }
 
 #ifdef __BYTEORDER_HAS_U64__
-static inline __attribute_const__ __u64 __fswab64(__u64 x)
+static inline __attribute_const__ uint64_t __fswab64(uint64_t x)
 {
 #  ifdef __SWAB_64_THRU_32__
-    __u32 h = x >> 32;
-        __u32 l = x & ((1ULL<<32)-1);
-        return (((__u64)__swab32(l)) << 32) | ((__u64)(__swab32(h)));
+    uint32_t h = x >> 32;
+    uint32_t l = x & ((1ULL<<32)-1);
+    return (((uint64_t)__swab32(l)) << 32) | ((uint64_t)(__swab32(h)));
 #  else
     return __arch__swab64(x);
 #  endif
 }
-static inline __u64 __swab64p(const __u64 *x)
+static inline uint64_t __swab64p(const uint64_t *x)
 {
     return __arch__swab64p(x);
 }
-static inline void __swab64s(__u64 *addr)
+static inline void __swab64s(uint64_t *addr)
 {
     __arch__swab64s(addr);
 }
diff -r 87854d3bed93 xen/include/xen/cper.h
--- a/xen/include/xen/cper.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/cper.h	Fri Jan 20 15:01:35 2012 +0100
@@ -28,7 +28,7 @@
 extern unsigned long get_sec(void);
 
 typedef struct {
-	__u8 b[16];
+	uint8_t b[16];
 } uuid_le;
 
 static inline int uuid_le_cmp(const uuid_le u1, const uuid_le u2)
@@ -155,36 +155,36 @@ static inline u64 cper_next_record_id(vo
 
 struct cper_record_header {
 	char	signature[CPER_SIG_SIZE];	/* must be CPER_SIG_RECORD */
-	__u16	revision;			/* must be CPER_RECORD_REV */
-	__u32	signature_end;			/* must be CPER_SIG_END */
-	__u16	section_count;
-	__u32	error_severity;
-	__u32	validation_bits;
-	__u32	record_length;
-	__u64	timestamp;
+	uint16_t revision;			/* must be CPER_RECORD_REV */
+	uint32_t signature_end;			/* must be CPER_SIG_END */
+	uint16_t section_count;
+	uint32_t error_severity;
+	uint32_t validation_bits;
+	uint32_t record_length;
+	uint64_t timestamp;
 	uuid_le	platform_id;
 	uuid_le	partition_id;
 	uuid_le	creator_id;
 	uuid_le	notification_type;
-	__u64	record_id;
-	__u32	flags;
-	__u64	persistence_information;
-	__u8	reserved[12];			/* must be zero */
+	uint64_t record_id;
+	uint32_t flags;
+	uint64_t persistence_information;
+	uint8_t	reserved[12];			/* must be zero */
 };
 
 struct cper_section_descriptor {
-	__u32	section_offset;		/* Offset in bytes of the
+	uint32_t section_offset;	/* Offset in bytes of the
 					 *  section body from the base
 					 *  of the record header */
-	__u32	section_length;
-	__u16	revision;		/* must be CPER_RECORD_REV */
-	__u8	validation_bits;
-	__u8	reserved;		/* must be zero */
-	__u32	flags;
+	uint32_t section_length;
+	uint16_t revision;		/* must be CPER_RECORD_REV */
+	uint8_t	validation_bits;
+	uint8_t	reserved;		/* must be zero */
+	uint32_t flags;
 	uuid_le	section_type;
 	uuid_le	fru_id;
-	__u32	section_severity;
-	__u8	fru_text[20];
+	uint32_t section_severity;
+	uint8_t	fru_text[20];
 };
 
 /* Reset to default packing */
diff -r 87854d3bed93 xen/include/xen/types.h
--- a/xen/include/xen/types.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/types.h	Fri Jan 20 15:01:35 2012 +0100
@@ -31,30 +31,14 @@ typedef unsigned short          ushort;
 typedef unsigned int            uint;
 typedef unsigned long           ulong;
 
-typedef         __u8            uint8_t;
-typedef         __u8            u_int8_t;
-typedef         __s8            int8_t;
-
-typedef         __u16           uint16_t;
-typedef         __u16           u_int16_t;
-typedef         __s16           int16_t;
-
-typedef         __u32           uint32_t;
-typedef         __u32           u_int32_t;
-typedef         __s32           int32_t;
-
-typedef         __u64           uint64_t;
-typedef         __u64           u_int64_t;
-typedef         __s64           int64_t;
-
 struct domain;
 struct vcpu;
 
-typedef __u16 __le16;
-typedef __u16 __be16;
-typedef __u32 __le32;
-typedef __u32 __be32;
-typedef __u64 __le64;
-typedef __u64 __be64;
+typedef uint16_t __le16;
+typedef uint16_t __be16;
+typedef uint32_t __le32;
+typedef uint32_t __be32;
+typedef uint64_t __le64;
+typedef uint64_t __be64;
 
 #endif /* __TYPES_H__ */

--------------010601040506090405000508
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010601040506090405000508--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:06:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoF6p-0002tS-Lq; Fri, 20 Jan 2012 14:06:27 +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 1RoF6n-0002tN-JE
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:06:26 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327068372!13230504!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 6674 invoked from network); 20 Jan 2012 14:06:13 -0000
Received: from tx2ehsobe004.messaging.microsoft.com (HELO
	TX2EHSOBE007.bigfish.com) (65.55.88.14)
	by server-2.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 14:06:13 -0000
Received: from mail17-tx2-R.bigfish.com (10.9.14.236) by
	TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 14:06:09 +0000
Received: from mail17-tx2 (localhost [127.0.0.1])	by mail17-tx2-R.bigfish.com
	(Postfix) with ESMTP id AAD3D80702	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 14:06:09 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzc85dhzz1202hzz8275bhz2dhc1bhc31hc1ahc1bhc31hc1ah668h839h34h61h)
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,0,
Received: from mail17-tx2 (localhost.localdomain [127.0.0.1]) by mail17-tx2
	(MessageSwitch) id 132706832792561_1797; Fri, 20 Jan 2012 14:05:27 +0000
	(UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.247])	by
	mail17-tx2.bigfish.com (Postfix) with ESMTP id 0F1E16A004B	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 14:05:27 +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; Fri, 20 Jan 2012 14:05:27 +0000
X-WSS-ID: 0LY3OGX-01-8Z5-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 2EDDD1028071	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 08:05:20 -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, 20 Jan 2012 08:05:43 -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, 20 Jan 2012 08:05:24 -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; Fri, 20 Jan 2012
	09:05:23 -0500
Message-ID: <4F1974A2.10605@amd.com>
Date: Fri, 20 Jan 2012 15:05:22 +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="------------010601040506090405000508"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------010601040506090405000508
Content-Type: text/plain; charset="ISO-8859-15"; format=flowed
Content-Transfer-Encoding: 7bit


Kill __u*/__s* integer types and use c99 integer types instead.
Cleanup <asm-x86/types.h>

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

--------------010601040506090405000508
Content-Type: text/plain; name="xen_type.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xen_type.diff"
Content-Description: xen_type.diff

diff -r 87854d3bed93 xen/arch/x86/cpu/mcheck/mce.h
--- a/xen/arch/x86/cpu/mcheck/mce.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/arch/x86/cpu/mcheck/mce.h	Fri Jan 20 15:01:35 2012 +0100
@@ -189,25 +189,25 @@ static inline int mce_bank_msr(uint32_t 
 
 /* Fields are zero when not available */
 struct mce {
-    __u64 status;
-    __u64 misc;
-    __u64 addr;
-    __u64 mcgstatus;
-    __u64 ip;
-    __u64 tsc;      /* cpu time stamp counter */
-    __u64 time;     /* wall time_t when error was detected */
-    __u8  cpuvendor;        /* cpu vendor as encoded in system.h */
-    __u8  inject_flags;     /* software inject flags */
-    __u16  pad;
-    __u32 cpuid;    /* CPUID 1 EAX */
-    __u8  cs;               /* code segment */
-    __u8  bank;     /* machine check bank */
-    __u8  cpu;      /* cpu number; obsolete; use extcpu now */
-    __u8  finished;   /* entry is valid */
-    __u32 extcpu;   /* linux cpu number that detected the error */
-    __u32 socketid; /* CPU socket ID */
-    __u32 apicid;   /* CPU initial apic ID */
-    __u64 mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
+    uint64_t status;
+    uint64_t misc;
+    uint64_t addr;
+    uint64_t mcgstatus;
+    uint64_t ip;
+    uint64_t tsc;      /* cpu time stamp counter */
+    uint64_t time;     /* wall time_t when error was detected */
+    uint8_t  cpuvendor;        /* cpu vendor as encoded in system.h */
+    uint8_t  inject_flags;     /* software inject flags */
+    uint16_t  pad;
+    uint32_t cpuid;    /* CPUID 1 EAX */
+    uint8_t  cs;               /* code segment */
+    uint8_t  bank;     /* machine check bank */
+    uint8_t  cpu;      /* cpu number; obsolete; use extcpu now */
+    uint8_t  finished;   /* entry is valid */
+    uint32_t extcpu;   /* linux cpu number that detected the error */
+    uint32_t socketid; /* CPU socket ID */
+    uint32_t apicid;   /* CPU initial apic ID */
+    uint64_t mcgcap;   /* MCGCAP MSR: machine check capabilities of CPU */
 };
 
 extern int apei_write_mce(struct mce *m);
diff -r 87854d3bed93 xen/arch/x86/oprofile/nmi_int.c
--- a/xen/arch/x86/oprofile/nmi_int.c	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/arch/x86/oprofile/nmi_int.c	Fri Jan 20 15:01:35 2012 +0100
@@ -295,7 +295,7 @@ void nmi_stop(void)
 
 static int __init p4_init(char ** cpu_type)
 { 
-	__u8 cpu_model = current_cpu_data.x86_model;
+	uint8_t cpu_model = current_cpu_data.x86_model;
 
 	if ((cpu_model > 6) || (cpu_model == 5)) {
 		printk("xenoprof: Initialization failed. "
@@ -341,7 +341,7 @@ custom_param("cpu_type", force_cpu_type)
 
 static int __init ppro_init(char ** cpu_type)
 {
-	__u8 cpu_model = current_cpu_data.x86_model;
+	uint8_t cpu_model = current_cpu_data.x86_model;
 
 	if (force_arch_perfmon && cpu_has_arch_perfmon)
 		return 0;
@@ -399,9 +399,9 @@ static int __init arch_perfmon_init(char
 
 static int __init nmi_init(void)
 {
-	__u8 vendor = current_cpu_data.x86_vendor;
-	__u8 family = current_cpu_data.x86;
-	__u8 _model = current_cpu_data.x86_model;
+	uint8_t vendor = current_cpu_data.x86_vendor;
+	uint8_t family = current_cpu_data.x86;
+	uint8_t _model = current_cpu_data.x86_model;
  
 	if (!cpu_has_apic) {
 		printk("xenoprof: Initialization failed. No APIC\n");
diff -r 87854d3bed93 xen/include/asm-x86/byteorder.h
--- a/xen/include/asm-x86/byteorder.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/byteorder.h	Fri Jan 20 15:01:35 2012 +0100
@@ -4,17 +4,17 @@
 #include <asm/types.h>
 #include <xen/compiler.h>
 
-static inline __attribute_const__ __u32 ___arch__swab32(__u32 x)
+static inline __attribute_const__ uint32_t ___arch__swab32(uint32_t x)
 {
     asm("bswap %0" : "=r" (x) : "0" (x));
     return x;
 }
 
-static inline __attribute_const__ __u64 ___arch__swab64(__u64 val)
+static inline __attribute_const__ uint64_t ___arch__swab64(uint64_t val)
 { 
     union { 
-        struct { __u32 a,b; } s;
-        __u64 u;
+        struct { uint32_t a,b; } s;
+        uint64_t u;
     } v;
     v.u = val;
     asm("bswapl %0 ; bswapl %1 ; xchgl %0,%1" 
diff -r 87854d3bed93 xen/include/asm-x86/io_apic.h
--- a/xen/include/asm-x86/io_apic.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/io_apic.h	Fri Jan 20 15:01:35 2012 +0100
@@ -91,7 +91,7 @@ enum ioapic_irq_destination_types {
 };
 
 struct IO_APIC_route_entry {
-	__u32	vector		:  8,
+	uint32_t vector		:  8,
 		delivery_mode	:  3,	/* 000: FIXED
 					 * 001: lowest prio
 					 * 111: ExtINT
@@ -104,19 +104,19 @@ struct IO_APIC_route_entry {
 		mask		:  1,	/* 0: enabled, 1: disabled */
 		__reserved_2	: 15;
 
-	union {		struct { __u32
+	union {		struct { uint32_t
 					__reserved_1	: 24,
 					physical_dest	:  4,
 					__reserved_2	:  4;
 			} physical;
 
-			struct { __u32
+			struct { uint32_t
 					__reserved_1	: 24,
 					logical_dest	:  8;
 			} logical;
 
 			/* used when Interrupt Remapping with EIM is enabled */
-			__u32 dest32;
+			uint32_t dest32;
 	} dest;
 
 } __attribute__ ((packed));
diff -r 87854d3bed93 xen/include/asm-x86/msi.h
--- a/xen/include/asm-x86/msi.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/msi.h	Fri Jan 20 15:01:35 2012 +0100
@@ -90,12 +90,12 @@ extern unsigned int pci_msix_get_table_l
 
 struct msi_desc {
 	struct msi_attrib {
-		__u8	type	: 5; 	/* {0: unused, 5h:MSI, 11h:MSI-X} */
-		__u8	maskbit	: 1; 	/* mask-pending bit supported ?   */
-		__u8	masked	: 1;
-		__u8	is_64	: 1;	/* Address size: 0=32bit 1=64bit  */
-		__u8	pos;	 	/* Location of the msi capability */
-		__u16	entry_nr;    	/* specific enabled entry 	  */
+		uint8_t	type	: 5; 	/* {0: unused, 5h:MSI, 11h:MSI-X} */
+		uint8_t	maskbit	: 1; 	/* mask-pending bit supported ?   */
+		uint8_t	masked	: 1;
+		uint8_t	is_64	: 1;	/* Address size: 0=32bit 1=64bit  */
+		uint8_t	pos;	 	/* Location of the msi capability */
+		uint16_t entry_nr;    	/* specific enabled entry 	  */
 	} msi_attrib;
 
 	struct list_head list;
@@ -175,19 +175,19 @@ int msi_free_irq(struct msi_desc *entry)
 
 struct msg_data {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
-	__u32	vector		:  8;
-	__u32	delivery_mode	:  3;	/* 000b: FIXED | 001b: lowest prior */
-	__u32	reserved_1	:  3;
-	__u32	level		:  1;	/* 0: deassert | 1: assert */
-	__u32	trigger		:  1;	/* 0: edge | 1: level */
-	__u32	reserved_2	: 16;
+	uint32_t vector		:  8;
+	uint32_t delivery_mode	:  3;	/* 000b: FIXED | 001b: lowest prior */
+	uint32_t reserved_1	:  3;
+	uint32_t level		:  1;	/* 0: deassert | 1: assert */
+	uint32_t trigger		:  1;	/* 0: edge | 1: level */
+	uint32_t reserved_2	: 16;
 #elif defined(__BIG_ENDIAN_BITFIELD)
-	__u32	reserved_2	: 16;
-	__u32	trigger		:  1;	/* 0: edge | 1: level */
-	__u32	level		:  1;	/* 0: deassert | 1: assert */
-	__u32	reserved_1	:  3;
-	__u32	delivery_mode	:  3;	/* 000b: FIXED | 001b: lowest prior */
-	__u32	vector		:  8;
+	uint32_t reserved_2	: 16;
+	uint32_t trigger		:  1;	/* 0: edge | 1: level */
+	uint32_t level		:  1;	/* 0: deassert | 1: assert */
+	uint32_t reserved_1	:  3;
+	uint32_t delivery_mode	:  3;	/* 000b: FIXED | 001b: lowest prior */
+	uint32_t vector		:  8;
 #else
 #error "Bitfield endianness not defined! Check your byteorder.h"
 #endif
@@ -197,26 +197,26 @@ struct msg_address {
 	union {
 		struct {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
-			__u32	reserved_1	:  2;
-			__u32	dest_mode	:  1;	/*0:physic | 1:logic */
-			__u32	redirection_hint:  1;  	/*0: dedicated CPU
+			uint32_t reserved_1	:  2;
+			uint32_t dest_mode	:  1;	/*0:physic | 1:logic */
+			uint32_t redirection_hint:  1;  	/*0: dedicated CPU
 							  1: lowest priority */
-			__u32	reserved_2	:  4;
- 			__u32	dest_id		: 24;	/* Destination ID */
+			uint32_t reserved_2	:  4;
+ 			uint32_t dest_id	: 24;	/* Destination ID */
 #elif defined(__BIG_ENDIAN_BITFIELD)
- 			__u32	dest_id		: 24;	/* Destination ID */
-			__u32	reserved_2	:  4;
-			__u32	redirection_hint:  1;  	/*0: dedicated CPU
-							  1: lowest priority */
-			__u32	dest_mode	:  1;	/*0:physic | 1:logic */
-			__u32	reserved_1	:  2;
+ 			uint32_t dest_id	: 24;	/* Destination ID */
+			uint32_t reserved_2	:  4;
+			uint32_t redirection_hint:  1; 	/*0: dedicated CPU
+						  	  1: lowest priority */
+			uint32_t dest_mode	:  1;	/*0:physic | 1:logic */
+			uint32_t reserved_1	:  2;
 #else
 #error "Bitfield endianness not defined! Check your byteorder.h"
 #endif
       		}u;
-       		__u32  value;
+       		uint32_t value;
 	}lo_address;
-	__u32 	hi_address;
+	uint32_t hi_address;
 } __attribute__ ((packed));
 
 void msi_compose_msg(struct irq_desc *, struct msi_msg *);
diff -r 87854d3bed93 xen/include/asm-x86/msr.h
--- a/xen/include/asm-x86/msr.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/msr.h	Fri Jan 20 15:01:35 2012 +0100
@@ -27,11 +27,11 @@
 			  : /* no outputs */ \
 			  : "c" (msr), "a" (val1), "d" (val2))
 
-static inline void wrmsrl(unsigned int msr, __u64 val)
+static inline void wrmsrl(unsigned int msr, uint64_t val)
 {
-        __u32 lo, hi;
-        lo = (__u32)val;
-        hi = (__u32)(val >> 32);
+        uint32_t lo, hi;
+        lo = (uint32_t)val;
+        hi = (uint32_t)(val >> 32);
         wrmsr(msr, lo, hi);
 }
 
diff -r 87854d3bed93 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/processor.h	Fri Jan 20 15:01:35 2012 +0100
@@ -162,10 +162,10 @@ struct vcpu;
 #endif
 
 struct cpuinfo_x86 {
-    __u8 x86;            /* CPU family */
-    __u8 x86_vendor;     /* CPU vendor */
-    __u8 x86_model;
-    __u8 x86_mask;
+    uint8_t x86;            /* CPU family */
+    uint8_t x86_vendor;     /* CPU vendor */
+    uint8_t x86_model;
+    uint8_t x86_mask;
     int  cpuid_level;    /* Maximum supported CPUID level, -1=no CPUID */
     unsigned int x86_capability[NCAPINTS];
     char x86_vendor_id[16];
@@ -173,10 +173,10 @@ struct cpuinfo_x86 {
     int  x86_cache_size; /* in KB - valid for CPUS which support this call  */
     int  x86_cache_alignment;    /* In bytes */
     int  x86_power;
-    __u32 x86_max_cores; /* cpuid returned max cores value */
-    __u32 booted_cores;  /* number of cores as seen by OS */
-    __u32 x86_num_siblings; /* cpuid logical cpus per chip value */
-    __u32 apicid;
+    uint32_t x86_max_cores; /* cpuid returned max cores value */
+    uint32_t booted_cores;  /* number of cores as seen by OS */
+    uint32_t x86_num_siblings; /* cpuid logical cpus per chip value */
+    uint32_t apicid;
     int   phys_proc_id; /* package ID of each logical CPU */
     int   cpu_core_id; /* core ID of each logical CPU*/
     int   compute_unit_id; /* AMD compute unit ID of each logical CPU */
diff -r 87854d3bed93 xen/include/asm-x86/types.h
--- a/xen/include/asm-x86/types.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/asm-x86/types.h	Fri Jan 20 15:01:35 2012 +0100
@@ -5,53 +5,47 @@
 
 #include <xen/config.h>
 
-typedef __signed__ char __s8;
-typedef unsigned char __u8;
+typedef __signed__ char int8_t;
+typedef unsigned char uint8_t;
 
-typedef __signed__ short __s16;
-typedef unsigned short __u16;
+typedef __signed__ short int16_t;
+typedef unsigned short uint16_t;
 
-typedef __signed__ int __s32;
-typedef unsigned int __u32;
-
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
-#if defined(__i386__)
-typedef __signed__ long long __s64;
-typedef unsigned long long __u64;
-#elif defined(__x86_64__)
-typedef __signed__ long __s64;
-typedef unsigned long __u64;
-#endif
-#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__ int int32_t;
+typedef unsigned int uint32_t;
 
 #if defined(__i386__)
-typedef signed long long s64;
-typedef unsigned long long u64;
-typedef u64 paddr_t;
+typedef __signed__ long long int64_t;
+typedef unsigned long long uint64_t;
 #define INVALID_PADDR (~0ULL)
 #define PRIpaddr "016llx"
 #elif defined(__x86_64__)
-typedef signed long s64;
-typedef unsigned long u64;
-typedef unsigned long paddr_t;
+typedef __signed__ long int64_t;
+typedef unsigned long uint64_t;
 #define INVALID_PADDR (~0UL)
 #define PRIpaddr "016lx"
 #endif
 
+typedef uint64_t paddr_t;
+
+/* Linux types */
+typedef int8_t s8;
+typedef uint8_t u8;
+
+typedef int16_t s16;
+typedef uint16_t u16;
+
+typedef int32_t s32;
+typedef uint32_t u32;
+
+typedef int64_t s64;
+typedef uint64_t u64;
+
 #if defined(__SIZE_TYPE__)
 typedef __SIZE_TYPE__ size_t;
 #elif defined(__i386__)
 typedef unsigned int size_t;
-#else
+#elif defined(__x86_64__)
 typedef unsigned long size_t;
 #endif
 
diff -r 87854d3bed93 xen/include/xen/bitops.h
--- a/xen/include/xen/bitops.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/bitops.h	Fri Jan 20 15:01:35 2012 +0100
@@ -77,9 +77,9 @@ static __inline__ int generic_fls(int x)
 #include <asm/bitops.h>
 
 
-static inline int generic_fls64(__u64 x)
+static inline int generic_fls64(uint64_t x)
 {
-    __u32 h = x >> 32;
+    uint32_t h = x >> 32;
     if (h)
         return fls(x) + 32;
     return fls(x);
@@ -132,7 +132,7 @@ static inline unsigned int generic_hweig
     return (res & 0x0F) + ((res >> 4) & 0x0F);
 }
 
-static inline unsigned long generic_hweight64(__u64 w)
+static inline unsigned long generic_hweight64(uint64_t w)
 {
 #if BITS_PER_LONG < 64
     return generic_hweight32((unsigned int)(w >> 32)) +
@@ -159,7 +159,7 @@ static inline unsigned long hweight_long
  * @word: value to rotate
  * @shift: bits to roll
  */
-static inline __u32 rol32(__u32 word, unsigned int shift)
+static inline uint32_t rol32(uint32_t word, unsigned int shift)
 {
     return (word << shift) | (word >> (32 - shift));
 }
@@ -170,7 +170,7 @@ static inline __u32 rol32(__u32 word, un
  * @word: value to rotate
  * @shift: bits to roll
  */
-static inline __u32 ror32(__u32 word, unsigned int shift)
+static inline uint32_t ror32(uint32_t word, unsigned int shift)
 {
     return (word >> shift) | (word << (32 - shift));
 }
diff -r 87854d3bed93 xen/include/xen/byteorder/little_endian.h
--- a/xen/include/xen/byteorder/little_endian.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/byteorder/little_endian.h	Fri Jan 20 15:01:35 2012 +0100
@@ -11,78 +11,78 @@
 #include <xen/types.h>
 #include <xen/byteorder/swab.h>
 
-#define __constant_cpu_to_le64(x) ((__force __le64)(__u64)(x))
-#define __constant_le64_to_cpu(x) ((__force __u64)(__le64)(x))
-#define __constant_cpu_to_le32(x) ((__force __le32)(__u32)(x))
-#define __constant_le32_to_cpu(x) ((__force __u32)(__le32)(x))
-#define __constant_cpu_to_le16(x) ((__force __le16)(__u16)(x))
-#define __constant_le16_to_cpu(x) ((__force __u16)(__le16)(x))
+#define __constant_cpu_to_le64(x) ((__force __le64)(uint64_t)(x))
+#define __constant_le64_to_cpu(x) ((__force uint64_t)(__le64)(x))
+#define __constant_cpu_to_le32(x) ((__force __le32)(uint32_t)(x))
+#define __constant_le32_to_cpu(x) ((__force uint32_t)(__le32)(x))
+#define __constant_cpu_to_le16(x) ((__force __le16)(uint16_t)(x))
+#define __constant_le16_to_cpu(x) ((__force uint16_t)(__le16)(x))
 #define __constant_cpu_to_be64(x) ((__force __be64)___constant_swab64((x)))
-#define __constant_be64_to_cpu(x) ___constant_swab64((__force __u64)(__be64)(x))
+#define __constant_be64_to_cpu(x) ___constant_swab64((__force uint64_t)(__be64)(x))
 #define __constant_cpu_to_be32(x) ((__force __be32)___constant_swab32((x)))
-#define __constant_be32_to_cpu(x) ___constant_swab32((__force __u32)(__be32)(x))
+#define __constant_be32_to_cpu(x) ___constant_swab32((__force uint32_t)(__be32)(x))
 #define __constant_cpu_to_be16(x) ((__force __be16)___constant_swab16((x)))
-#define __constant_be16_to_cpu(x) ___constant_swab16((__force __u16)(__be16)(x))
-#define __cpu_to_le64(x) ((__force __le64)(__u64)(x))
-#define __le64_to_cpu(x) ((__force __u64)(__le64)(x))
-#define __cpu_to_le32(x) ((__force __le32)(__u32)(x))
-#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
-#define __cpu_to_le16(x) ((__force __le16)(__u16)(x))
-#define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
+#define __constant_be16_to_cpu(x) ___constant_swab16((__force uint16_t)(__be16)(x))
+#define __cpu_to_le64(x) ((__force __le64)(uint64_t)(x))
+#define __le64_to_cpu(x) ((__force uint64_t)(__le64)(x))
+#define __cpu_to_le32(x) ((__force __le32)(uint32_t)(x))
+#define __le32_to_cpu(x) ((__force uint32_t)(__le32)(x))
+#define __cpu_to_le16(x) ((__force __le16)(uint16_t)(x))
+#define __le16_to_cpu(x) ((__force uint16_t)(__le16)(x))
 #define __cpu_to_be64(x) ((__force __be64)__swab64((x)))
-#define __be64_to_cpu(x) __swab64((__force __u64)(__be64)(x))
+#define __be64_to_cpu(x) __swab64((__force uint64_t)(__be64)(x))
 #define __cpu_to_be32(x) ((__force __be32)__swab32((x)))
-#define __be32_to_cpu(x) __swab32((__force __u32)(__be32)(x))
+#define __be32_to_cpu(x) __swab32((__force uint32_t)(__be32)(x))
 #define __cpu_to_be16(x) ((__force __be16)__swab16((x)))
-#define __be16_to_cpu(x) __swab16((__force __u16)(__be16)(x))
+#define __be16_to_cpu(x) __swab16((__force uint16_t)(__be16)(x))
 
-static inline __le64 __cpu_to_le64p(const __u64 *p)
+static inline __le64 __cpu_to_le64p(const uint64_t *p)
 {
     return (__force __le64)*p;
 }
-static inline __u64 __le64_to_cpup(const __le64 *p)
+static inline uint64_t __le64_to_cpup(const __le64 *p)
 {
-    return (__force __u64)*p;
+    return (__force uint64_t)*p;
 }
-static inline __le32 __cpu_to_le32p(const __u32 *p)
+static inline __le32 __cpu_to_le32p(const uint32_t *p)
 {
     return (__force __le32)*p;
 }
-static inline __u32 __le32_to_cpup(const __le32 *p)
+static inline uint32_t __le32_to_cpup(const __le32 *p)
 {
-    return (__force __u32)*p;
+    return (__force uint32_t)*p;
 }
-static inline __le16 __cpu_to_le16p(const __u16 *p)
+static inline __le16 __cpu_to_le16p(const uint16_t *p)
 {
     return (__force __le16)*p;
 }
-static inline __u16 __le16_to_cpup(const __le16 *p)
+static inline uint16_t __le16_to_cpup(const __le16 *p)
 {
-    return (__force __u16)*p;
+    return (__force uint16_t)*p;
 }
-static inline __be64 __cpu_to_be64p(const __u64 *p)
+static inline __be64 __cpu_to_be64p(const uint64_t *p)
 {
     return (__force __be64)__swab64p(p);
 }
-static inline __u64 __be64_to_cpup(const __be64 *p)
+static inline uint64_t __be64_to_cpup(const __be64 *p)
 {
-    return __swab64p((__u64 *)p);
+    return __swab64p((uint64_t *)p);
 }
-static inline __be32 __cpu_to_be32p(const __u32 *p)
+static inline __be32 __cpu_to_be32p(const uint32_t *p)
 {
     return (__force __be32)__swab32p(p);
 }
-static inline __u32 __be32_to_cpup(const __be32 *p)
+static inline uint32_t __be32_to_cpup(const __be32 *p)
 {
-    return __swab32p((__u32 *)p);
+    return __swab32p((uint32_t *)p);
 }
-static inline __be16 __cpu_to_be16p(const __u16 *p)
+static inline __be16 __cpu_to_be16p(const uint16_t *p)
 {
     return (__force __be16)__swab16p(p);
 }
-static inline __u16 __be16_to_cpup(const __be16 *p)
+static inline uint16_t __be16_to_cpup(const __be16 *p)
 {
-    return __swab16p((__u16 *)p);
+    return __swab16p((uint16_t *)p);
 }
 #define __cpu_to_le64s(x) do {} while (0)
 #define __le64_to_cpus(x) do {} while (0)
diff -r 87854d3bed93 xen/include/xen/byteorder/swab.h
--- a/xen/include/xen/byteorder/swab.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/byteorder/swab.h	Fri Jan 20 15:01:35 2012 +0100
@@ -11,72 +11,73 @@
  */
 
 /* casts are necessary for constants, because we never know how for sure
- * how U/UL/ULL map to __u16, __u32, __u64. At least not in a portable way.
+ * how U/UL/ULL map to uint16_t, uint32_t, uint64_t.
+ * At least not in a portable way.
  */
 #define ___swab16(x)                                    \
 ({                                                      \
-    __u16 __x = (x);                                    \
-    ((__u16)(                                           \
-        (((__u16)(__x) & (__u16)0x00ffU) << 8) |        \
-        (((__u16)(__x) & (__u16)0xff00U) >> 8) ));      \
+    uint16_t __x = (x);                                 \
+    ((uint16_t)(                                        \
+        (((uint16_t)(__x) & (uint16_t)0x00ffU) << 8) |  \
+        (((uint16_t)(__x) & (uint16_t)0xff00U) >> 8) ));\
 })
 
 #define ___swab32(x)                                            \
 ({                                                              \
-    __u32 __x = (x);                                            \
-    ((__u32)(                                                   \
-        (((__u32)(__x) & (__u32)0x000000ffUL) << 24) |          \
-        (((__u32)(__x) & (__u32)0x0000ff00UL) <<  8) |          \
-        (((__u32)(__x) & (__u32)0x00ff0000UL) >>  8) |          \
-        (((__u32)(__x) & (__u32)0xff000000UL) >> 24) ));        \
+    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 ___swab64(x)                                                       \
 ({                                                                         \
-    __u64 __x = (x);                                                       \
-    ((__u64)(                                                              \
-        (__u64)(((__u64)(__x) & (__u64)0x00000000000000ffULL) << 56) |     \
-        (__u64)(((__u64)(__x) & (__u64)0x000000000000ff00ULL) << 40) |     \
-        (__u64)(((__u64)(__x) & (__u64)0x0000000000ff0000ULL) << 24) |     \
-        (__u64)(((__u64)(__x) & (__u64)0x00000000ff000000ULL) <<  8) |     \
-            (__u64)(((__u64)(__x) & (__u64)0x000000ff00000000ULL) >>  8) | \
-        (__u64)(((__u64)(__x) & (__u64)0x0000ff0000000000ULL) >> 24) |     \
-        (__u64)(((__u64)(__x) & (__u64)0x00ff000000000000ULL) >> 40) |     \
-        (__u64)(((__u64)(__x) & (__u64)0xff00000000000000ULL) >> 56) ));   \
+    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) ));   \
 })
 
-#define ___constant_swab16(x)                   \
-    ((__u16)(                                   \
-        (((__u16)(x) & (__u16)0x00ffU) << 8) |  \
-        (((__u16)(x) & (__u16)0xff00U) >> 8) ))
-#define ___constant_swab32(x)                           \
-    ((__u32)(                                           \
-        (((__u32)(x) & (__u32)0x000000ffUL) << 24) |    \
-        (((__u32)(x) & (__u32)0x0000ff00UL) <<  8) |    \
-        (((__u32)(x) & (__u32)0x00ff0000UL) >>  8) |    \
-        (((__u32)(x) & (__u32)0xff000000UL) >> 24) ))
+#define ___constant_swab16(x)                           \
+    ((uint16_t)(                                        \
+        (((uint16_t)(x) & (uint16_t)0x00ffU) << 8) |    \
+        (((uint16_t)(x) & (uint16_t)0xff00U) >> 8) ))
+#define ___constant_swab32(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 ___constant_swab64(x)                                            \
-    ((__u64)(                                                            \
-        (__u64)(((__u64)(x) & (__u64)0x00000000000000ffULL) << 56) |     \
-        (__u64)(((__u64)(x) & (__u64)0x000000000000ff00ULL) << 40) |     \
-        (__u64)(((__u64)(x) & (__u64)0x0000000000ff0000ULL) << 24) |     \
-        (__u64)(((__u64)(x) & (__u64)0x00000000ff000000ULL) <<  8) |     \
-            (__u64)(((__u64)(x) & (__u64)0x000000ff00000000ULL) >>  8) | \
-        (__u64)(((__u64)(x) & (__u64)0x0000ff0000000000ULL) >> 24) |     \
-        (__u64)(((__u64)(x) & (__u64)0x00ff000000000000ULL) >> 40) |     \
-        (__u64)(((__u64)(x) & (__u64)0xff00000000000000ULL) >> 56) ))
+    ((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) ))
 
 /*
  * provide defaults when no architecture-specific optimization is detected
  */
 #ifndef __arch__swab16
-#  define __arch__swab16(x) ({ __u16 __tmp = (x) ; ___swab16(__tmp); })
+#  define __arch__swab16(x) ({ uint16_t __tmp = (x) ; ___swab16(__tmp); })
 #endif
 #ifndef __arch__swab32
-#  define __arch__swab32(x) ({ __u32 __tmp = (x) ; ___swab32(__tmp); })
+#  define __arch__swab32(x) ({ uint32_t __tmp = (x) ; ___swab32(__tmp); })
 #endif
 #ifndef __arch__swab64
-#  define __arch__swab64(x) ({ __u64 __tmp = (x) ; ___swab64(__tmp); })
+#  define __arch__swab64(x) ({ uint64_t __tmp = (x) ; ___swab64(__tmp); })
 #endif
 
 #ifndef __arch__swab16p
@@ -105,15 +106,15 @@
  */
 #if defined(__GNUC__) && defined(__OPTIMIZE__)
 #  define __swab16(x) \
-(__builtin_constant_p((__u16)(x)) ? \
+(__builtin_constant_p((uint16_t)(x)) ? \
  ___swab16((x)) : \
  __fswab16((x)))
 #  define __swab32(x) \
-(__builtin_constant_p((__u32)(x)) ? \
+(__builtin_constant_p((uint32_t)(x)) ? \
  ___swab32((x)) : \
  __fswab32((x)))
 #  define __swab64(x) \
-(__builtin_constant_p((__u64)(x)) ? \
+(__builtin_constant_p((uint64_t)(x)) ? \
  ___swab64((x)) : \
  __fswab64((x)))
 #else
@@ -123,48 +124,48 @@
 #endif /* OPTIMIZE */
 
 
-static inline __attribute_const__ __u16 __fswab16(__u16 x)
+static inline __attribute_const__ uint16_t __fswab16(uint16_t x)
 {
     return __arch__swab16(x);
 }
-static inline __u16 __swab16p(const __u16 *x)
+static inline uint16_t __swab16p(const uint16_t *x)
 {
     return __arch__swab16p(x);
 }
-static inline void __swab16s(__u16 *addr)
+static inline void __swab16s(uint16_t *addr)
 {
     __arch__swab16s(addr);
 }
 
-static inline __attribute_const__ __u32 __fswab32(__u32 x)
+static inline __attribute_const__ uint32_t __fswab32(uint32_t x)
 {
     return __arch__swab32(x);
 }
-static inline __u32 __swab32p(const __u32 *x)
+static inline uint32_t __swab32p(const uint32_t *x)
 {
     return __arch__swab32p(x);
 }
-static inline void __swab32s(__u32 *addr)
+static inline void __swab32s(uint32_t *addr)
 {
     __arch__swab32s(addr);
 }
 
 #ifdef __BYTEORDER_HAS_U64__
-static inline __attribute_const__ __u64 __fswab64(__u64 x)
+static inline __attribute_const__ uint64_t __fswab64(uint64_t x)
 {
 #  ifdef __SWAB_64_THRU_32__
-    __u32 h = x >> 32;
-        __u32 l = x & ((1ULL<<32)-1);
-        return (((__u64)__swab32(l)) << 32) | ((__u64)(__swab32(h)));
+    uint32_t h = x >> 32;
+    uint32_t l = x & ((1ULL<<32)-1);
+    return (((uint64_t)__swab32(l)) << 32) | ((uint64_t)(__swab32(h)));
 #  else
     return __arch__swab64(x);
 #  endif
 }
-static inline __u64 __swab64p(const __u64 *x)
+static inline uint64_t __swab64p(const uint64_t *x)
 {
     return __arch__swab64p(x);
 }
-static inline void __swab64s(__u64 *addr)
+static inline void __swab64s(uint64_t *addr)
 {
     __arch__swab64s(addr);
 }
diff -r 87854d3bed93 xen/include/xen/cper.h
--- a/xen/include/xen/cper.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/cper.h	Fri Jan 20 15:01:35 2012 +0100
@@ -28,7 +28,7 @@
 extern unsigned long get_sec(void);
 
 typedef struct {
-	__u8 b[16];
+	uint8_t b[16];
 } uuid_le;
 
 static inline int uuid_le_cmp(const uuid_le u1, const uuid_le u2)
@@ -155,36 +155,36 @@ static inline u64 cper_next_record_id(vo
 
 struct cper_record_header {
 	char	signature[CPER_SIG_SIZE];	/* must be CPER_SIG_RECORD */
-	__u16	revision;			/* must be CPER_RECORD_REV */
-	__u32	signature_end;			/* must be CPER_SIG_END */
-	__u16	section_count;
-	__u32	error_severity;
-	__u32	validation_bits;
-	__u32	record_length;
-	__u64	timestamp;
+	uint16_t revision;			/* must be CPER_RECORD_REV */
+	uint32_t signature_end;			/* must be CPER_SIG_END */
+	uint16_t section_count;
+	uint32_t error_severity;
+	uint32_t validation_bits;
+	uint32_t record_length;
+	uint64_t timestamp;
 	uuid_le	platform_id;
 	uuid_le	partition_id;
 	uuid_le	creator_id;
 	uuid_le	notification_type;
-	__u64	record_id;
-	__u32	flags;
-	__u64	persistence_information;
-	__u8	reserved[12];			/* must be zero */
+	uint64_t record_id;
+	uint32_t flags;
+	uint64_t persistence_information;
+	uint8_t	reserved[12];			/* must be zero */
 };
 
 struct cper_section_descriptor {
-	__u32	section_offset;		/* Offset in bytes of the
+	uint32_t section_offset;	/* Offset in bytes of the
 					 *  section body from the base
 					 *  of the record header */
-	__u32	section_length;
-	__u16	revision;		/* must be CPER_RECORD_REV */
-	__u8	validation_bits;
-	__u8	reserved;		/* must be zero */
-	__u32	flags;
+	uint32_t section_length;
+	uint16_t revision;		/* must be CPER_RECORD_REV */
+	uint8_t	validation_bits;
+	uint8_t	reserved;		/* must be zero */
+	uint32_t flags;
 	uuid_le	section_type;
 	uuid_le	fru_id;
-	__u32	section_severity;
-	__u8	fru_text[20];
+	uint32_t section_severity;
+	uint8_t	fru_text[20];
 };
 
 /* Reset to default packing */
diff -r 87854d3bed93 xen/include/xen/types.h
--- a/xen/include/xen/types.h	Fri Jan 20 10:40:16 2012 +0000
+++ b/xen/include/xen/types.h	Fri Jan 20 15:01:35 2012 +0100
@@ -31,30 +31,14 @@ typedef unsigned short          ushort;
 typedef unsigned int            uint;
 typedef unsigned long           ulong;
 
-typedef         __u8            uint8_t;
-typedef         __u8            u_int8_t;
-typedef         __s8            int8_t;
-
-typedef         __u16           uint16_t;
-typedef         __u16           u_int16_t;
-typedef         __s16           int16_t;
-
-typedef         __u32           uint32_t;
-typedef         __u32           u_int32_t;
-typedef         __s32           int32_t;
-
-typedef         __u64           uint64_t;
-typedef         __u64           u_int64_t;
-typedef         __s64           int64_t;
-
 struct domain;
 struct vcpu;
 
-typedef __u16 __le16;
-typedef __u16 __be16;
-typedef __u32 __le32;
-typedef __u32 __be32;
-typedef __u64 __le64;
-typedef __u64 __be64;
+typedef uint16_t __le16;
+typedef uint16_t __be16;
+typedef uint32_t __le32;
+typedef uint32_t __be32;
+typedef uint64_t __le64;
+typedef uint64_t __be64;
 
 #endif /* __TYPES_H__ */

--------------010601040506090405000508
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------010601040506090405000508--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:13:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoFD3-00034Z-Tg; Fri, 20 Jan 2012 14:12:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RoFD2-00034Q-Hw
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:12:52 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327068483!11670673!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NjM3Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13665 invoked from network); 20 Jan 2012 14:08:03 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 14:08:03 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=BFZtr68ETrU40NMKGfdSeEXQamEu/ugohKYY1t7O4LQDY4RJ8gB4f3eC
	+4T3xwXhu45EyHt6xTTfiXqNGX6gu2CgPhefYsv0ZuQwEWcYxyksDzbrx
	2NPP0ZIcmxEWsrf37ZgUu76DN93EwtAI+Pi6GWOMveLfHNSgvjnJr8qPf
	nR4S5TlySRg8uwTiAYMoFDKy7lTJT0VlU4bsWoH/6af0iR4DWAWOuiefG
	fXERmevV+iKt8/4vghf5YwQkj3F42;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1327068483; x=1358604483;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=EU/zu5n+N8D3253UWzVFq2Xs/8vqX2GSlLkyru75GU8=;
	b=pEBJaDqm/Wt34TP3U4ozqmwb60h5BewSZXkzsMq2ilh1QZwyO0zc4KNz
	MootezrTei9tU1xPYXy43oDbbIBh8MrQmcJtzXhBcKuIKW1N49OgWGPwR
	kVwYcho70aKjVt0RWDOZlUdClZAvySJJYnHmvbRCTfFwUt/Kv2+1QGMbS
	Wv3OOmhTsaa8g64qiPV0VRNAT1D9KAkpZdohcIeATHT+3PD+BgEZjzH0T
	S3JBCbQ+4Y4yG9DZw+MpaaWSj5u46;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="84118246"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 20 Jan 2012 15:08:02 +0100
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="127136335"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 20 Jan 2012 15:08:02 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 6350C95F317;
	Fri, 20 Jan 2012 15:08:02 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 20 Jan 2012 15:08:02 +0100
Message-ID: <10623458.xWNmoTWpXQ@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CB3F20EC.293DD%keir.xen@gmail.com>
References: <CB3F20EC.293DD%keir.xen@gmail.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Freitag 20 Januar 2012, 13:47:24 schrieb Keir Fraser:
> On 20/01/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >> Yes that's probably the way to do it. If the resulting required
> >> configuration runes are too cryptic or vendor-specific, it may make sense to
> >> have the libxl cpuid logic consume a 'vpmu' option which it then turns into
> >> a set of lower-level cpuid settings to eventually pass down to the code in
> >> libxc/xc_cpuid.
> >> 
> >> It's a trifle messy I will admit. Arguably the 'default policy' bits of
> >> xc_cpuid_x86.c would better belong in libxl these days, where we would have
> >> better access to a domain's configuration state. As it is, we may end up
> >> with a spread of default policy across Xen (for dom0), libxc, and libxl.
> > 
> > Plus a bunch of ad-hoc stuff which predates the cpuid bit-fiddling
> > support but is reflected in the cpuid (pae, apic, acpi etc).
> 
> Well, this is done in libxc now, so I think I included it in my list. ;) But
> it would be cleaner done in libxl.
> 
> I don't think anyone will be straining their arm to volunteer for this
> cleanup, but we shouldn't be shy about putting new policy stuff in libxl if
> it makes best sense to put it there.

Thanks for the hints. For the first time I'll go through the source and try to
understand what you are talking about.

Dietmar.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:13:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoFD3-00034Z-Tg; Fri, 20 Jan 2012 14:12:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RoFD2-00034Q-Hw
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:12:52 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327068483!11670673!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NjM3Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13665 invoked from network); 20 Jan 2012 14:08:03 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 14:08:03 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Cc:Subject:Date:Message-ID:
	User-Agent:In-Reply-To:References:MIME-Version:
	Content-Transfer-Encoding:Content-Type;
	b=BFZtr68ETrU40NMKGfdSeEXQamEu/ugohKYY1t7O4LQDY4RJ8gB4f3eC
	+4T3xwXhu45EyHt6xTTfiXqNGX6gu2CgPhefYsv0ZuQwEWcYxyksDzbrx
	2NPP0ZIcmxEWsrf37ZgUu76DN93EwtAI+Pi6GWOMveLfHNSgvjnJr8qPf
	nR4S5TlySRg8uwTiAYMoFDKy7lTJT0VlU4bsWoH/6af0iR4DWAWOuiefG
	fXERmevV+iKt8/4vghf5YwQkj3F42;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1327068483; x=1358604483;
	h=from:to:cc:subject:date:message-id:in-reply-to:
	references:mime-version:content-transfer-encoding;
	bh=EU/zu5n+N8D3253UWzVFq2Xs/8vqX2GSlLkyru75GU8=;
	b=pEBJaDqm/Wt34TP3U4ozqmwb60h5BewSZXkzsMq2ilh1QZwyO0zc4KNz
	MootezrTei9tU1xPYXy43oDbbIBh8MrQmcJtzXhBcKuIKW1N49OgWGPwR
	kVwYcho70aKjVt0RWDOZlUdClZAvySJJYnHmvbRCTfFwUt/Kv2+1QGMbS
	Wv3OOmhTsaa8g64qiPV0VRNAT1D9KAkpZdohcIeATHT+3PD+BgEZjzH0T
	S3JBCbQ+4Y4yG9DZw+MpaaWSj5u46;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="84118246"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 20 Jan 2012 15:08:02 +0100
X-IronPort-AV: E=Sophos;i="4.71,541,1320620400"; d="scan'208";a="127136335"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 20 Jan 2012 15:08:02 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 6350C95F317;
	Fri, 20 Jan 2012 15:08:02 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Fri, 20 Jan 2012 15:08:02 +0100
Message-ID: <10623458.xWNmoTWpXQ@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
In-Reply-To: <CB3F20EC.293DD%keir.xen@gmail.com>
References: <CB3F20EC.293DD%keir.xen@gmail.com>
MIME-Version: 1.0
Cc: Wei Wang <wei.wang2@amd.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] vpmu: Add a vpmu cpuid function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Freitag 20 Januar 2012, 13:47:24 schrieb Keir Fraser:
> On 20/01/2012 13:37, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
> 
> >> Yes that's probably the way to do it. If the resulting required
> >> configuration runes are too cryptic or vendor-specific, it may make sense to
> >> have the libxl cpuid logic consume a 'vpmu' option which it then turns into
> >> a set of lower-level cpuid settings to eventually pass down to the code in
> >> libxc/xc_cpuid.
> >> 
> >> It's a trifle messy I will admit. Arguably the 'default policy' bits of
> >> xc_cpuid_x86.c would better belong in libxl these days, where we would have
> >> better access to a domain's configuration state. As it is, we may end up
> >> with a spread of default policy across Xen (for dom0), libxc, and libxl.
> > 
> > Plus a bunch of ad-hoc stuff which predates the cpuid bit-fiddling
> > support but is reflected in the cpuid (pae, apic, acpi etc).
> 
> Well, this is done in libxc now, so I think I included it in my list. ;) But
> it would be cleaner done in libxl.
> 
> I don't think anyone will be straining their arm to volunteer for this
> cleanup, but we shouldn't be shy about putting new policy stuff in libxl if
> it makes best sense to put it there.

Thanks for the hints. For the first time I'll go through the source and try to
understand what you are talking about.

Dietmar.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:30:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoFTO-0003Rt-Ga; Fri, 20 Jan 2012 14:29: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 1RoFTM-0003RR-K5
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:29:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327069778!9949087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28999 invoked from network); 20 Jan 2012 14:29:38 -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;
	20 Jan 2012 14:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10179195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 14:29:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 14:29:38 +0000
Date: Fri, 20 Jan 2012 14:29: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: <1327059769.30054.12.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201428030.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327059769.30054.12.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> > Read Qemu's physmap from xenstore and save it using toolstack_save.
> > Restore Qemu's physmap using toolstack_restore.
> 
> Shall we have a version field now so we don't dig ourselves a hole we
> can't get out of?

good idea

> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
> >  1 files changed, 131 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index fd2b051..3d60a35 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -347,6 +347,62 @@ out:
> >      return rc;
> >  }
> >  
> > +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> > +        uint32_t size, void *data)
> > +{
> > +    libxl__gc *gc = (libxl__gc *) data;
> > +    int i, ret;
> > +    uint8_t *ptr = buf;
> > +    uint32_t namelen = 0;
> > +    char *name = NULL;
> > +    uint32_t count = 0;
> > +    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
> > +
> > +    if (size < sizeof(count))
> > +        return -1;
> > +
> > +    memcpy(&count, ptr, sizeof(count));
> > +    ptr += sizeof(count);
> > + 
> > +    if (size <
> > +            sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
> > +        return -1;
> > +
> > +    for (i = 0; i < count; i++) {
> > +        memcpy(&namelen, ptr, sizeof(namelen));
> > +        ptr += sizeof(namelen);
> > +        if (namelen > 0) {
> > +            name = (char *)ptr;
> > +            ptr += namelen;
> > +        }
> > +        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
> > +        ptr += sizeof(uint64_t);
> > +        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
> > +        ptr += sizeof(uint64_t);
> > +        memcpy(&size_v, ptr, sizeof(uint64_t));
> > +        ptr += sizeof(uint64_t);
> 
> Why not define a struct libxl__physmap_info for these three? You could
> even do the trick with the "char name[]" at the end and incorporate
> namelen too if you wanted.
> 
> The maximum size of the allocation is
> 	sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
> here but in the save it is allocating:
> 	sizeof(count) + count * (sizeof(val) * 3 + sizeof(namelen));
> these work out the same but it would be more obviously correct if it
> were "count * sizeof(struct)"
> 
> Actually, hang on where is the space for name itself allocated? I see,
> you are reallocing. If you have to do that anyway you may as well start
> off with just sizeof(count) and realloc namelen + sizeof(struct) at each
> stage.

I played with the idea of the struct for a bit and it has improved the
code, especially on restore.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:30:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:30:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoFTO-0003Rt-Ga; Fri, 20 Jan 2012 14:29: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 1RoFTM-0003RR-K5
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:29:44 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327069778!9949087!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28999 invoked from network); 20 Jan 2012 14:29:38 -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;
	20 Jan 2012 14:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10179195"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 14:29:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 14:29:38 +0000
Date: Fri, 20 Jan 2012 14:29: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: <1327059769.30054.12.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201201428030.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201106130.3150@kaball-desktop>
	<1327058312-19168-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327059769.30054.12.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-20 at 11:18 +0000, Stefano Stabellini wrote:
> > Read Qemu's physmap from xenstore and save it using toolstack_save.
> > Restore Qemu's physmap using toolstack_restore.
> 
> Shall we have a version field now so we don't dig ourselves a hole we
> can't get out of?

good idea

> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
> >  1 files changed, 131 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index fd2b051..3d60a35 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -347,6 +347,62 @@ out:
> >      return rc;
> >  }
> >  
> > +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> > +        uint32_t size, void *data)
> > +{
> > +    libxl__gc *gc = (libxl__gc *) data;
> > +    int i, ret;
> > +    uint8_t *ptr = buf;
> > +    uint32_t namelen = 0;
> > +    char *name = NULL;
> > +    uint32_t count = 0;
> > +    uint64_t phys_offset_v = 0, start_addr_v = 0, size_v = 0;
> > +
> > +    if (size < sizeof(count))
> > +        return -1;
> > +
> > +    memcpy(&count, ptr, sizeof(count));
> > +    ptr += sizeof(count);
> > + 
> > +    if (size <
> > +            sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
> > +        return -1;
> > +
> > +    for (i = 0; i < count; i++) {
> > +        memcpy(&namelen, ptr, sizeof(namelen));
> > +        ptr += sizeof(namelen);
> > +        if (namelen > 0) {
> > +            name = (char *)ptr;
> > +            ptr += namelen;
> > +        }
> > +        memcpy(&phys_offset_v, ptr, sizeof(uint64_t));
> > +        ptr += sizeof(uint64_t);
> > +        memcpy(&start_addr_v, ptr, sizeof(uint64_t));
> > +        ptr += sizeof(uint64_t);
> > +        memcpy(&size_v, ptr, sizeof(uint64_t));
> > +        ptr += sizeof(uint64_t);
> 
> Why not define a struct libxl__physmap_info for these three? You could
> even do the trick with the "char name[]" at the end and incorporate
> namelen too if you wanted.
> 
> The maximum size of the allocation is
> 	sizeof(count) + count * (sizeof(uint64_t) * 3 + sizeof(uint32_t)))
> here but in the save it is allocating:
> 	sizeof(count) + count * (sizeof(val) * 3 + sizeof(namelen));
> these work out the same but it would be more obviously correct if it
> were "count * sizeof(struct)"
> 
> Actually, hang on where is the space for name itself allocated? I see,
> you are reallocing. If you have to do that anyway you may as well start
> off with just sizeof(count) and realloc namelen + sizeof(struct) at each
> stage.

I played with the idea of the struct for a bit and it has improved the
code, especially on restore.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:35:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14: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 1RoFYm-0003jk-GB; Fri, 20 Jan 2012 14:35:20 +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 1RoFYl-0003jb-Eh
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:35:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327070110!9799320!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 1275 invoked from network); 20 Jan 2012 14:35:11 -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; 20 Jan 2012 14:35:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 14:35:10 +0000
Message-Id: <4F1989EF020000780006DFB2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 14:36:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <4F1974A2.10605@amd.com>
In-Reply-To: <4F1974A2.10605@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] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 15:05, Christoph Egger <Christoph.Egger@amd.com> wrote:
> Kill __u*/__s* integer types and use c99 integer types instead.
> Cleanup <asm-x86/types.h>

Was this build-tested for ia64?

Jan

> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:35:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14: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 1RoFYm-0003jk-GB; Fri, 20 Jan 2012 14:35:20 +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 1RoFYl-0003jb-Eh
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:35:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327070110!9799320!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 1275 invoked from network); 20 Jan 2012 14:35:11 -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; 20 Jan 2012 14:35:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 14:35:10 +0000
Message-Id: <4F1989EF020000780006DFB2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 14:36:15 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <4F1974A2.10605@amd.com>
In-Reply-To: <4F1974A2.10605@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] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 15:05, Christoph Egger <Christoph.Egger@amd.com> wrote:
> Kill __u*/__s* integer types and use c99 integer types instead.
> Cleanup <asm-x86/types.h>

Was this build-tested for ia64?

Jan

> Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:51:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoFoA-00048H-DD; Fri, 20 Jan 2012 14:51:14 +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 1RoFo8-000480-KK
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:51:12 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327071065!11885680!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 12619 invoked from network); 20 Jan 2012 14:51:06 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE007.bigfish.com) (216.32.180.16)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 14:51:06 -0000
Received: from mail105-va3-R.bigfish.com (10.7.14.241) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 14:51:02 +0000
Received: from mail105-va3 (localhost [127.0.0.1])	by
	mail105-va3-R.bigfish.com (Postfix) with ESMTP id EB876A0212;
	Fri, 20 Jan 2012 14:51:02 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail105-va3 (localhost.localdomain [127.0.0.1]) by mail105-va3
	(MessageSwitch) id 1327071060718144_1396;
	Fri, 20 Jan 2012 14:51:00 +0000 (UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.245])	by
	mail105-va3.bigfish.com (Postfix) with ESMTP id A6FC2260045;
	Fri, 20 Jan 2012 14:51:00 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 14:50:59 +0000
X-WSS-ID: 0LY3QKV-02-BGL-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 2D6E9C80B9;	Fri, 20 Jan 2012 08:50:55 -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;
	Fri, 20 Jan 2012 08:51:18 -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;
	Fri, 20 Jan 2012 08:51:00 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Jan 2012
	09:50:59 -0500
Message-ID: <4F197F52.7040700@amd.com>
Date: Fri, 20 Jan 2012 15:50:58 +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: <4F1974A2.10605@amd.com>
	<4F1989EF020000780006DFB2@nat28.tlf.novell.com>
In-Reply-To: <4F1989EF020000780006DFB2@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/20/12 15:36, Jan Beulich wrote:
>>>> On 20.01.12 at 15:05, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>> Kill __u*/__s* integer types and use c99 integer types instead.
>> Cleanup<asm-x86/types.h>
>
> Was this build-tested for ia64?

No. I don't have such a machine.
Can you do that, please?

Christoph

>
> Jan
>
>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:51:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoFoA-00048H-DD; Fri, 20 Jan 2012 14:51:14 +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 1RoFo8-000480-KK
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:51:12 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327071065!11885680!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 12619 invoked from network); 20 Jan 2012 14:51:06 -0000
Received: from va3ehsobe006.messaging.microsoft.com (HELO
	VA3EHSOBE007.bigfish.com) (216.32.180.16)
	by server-12.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 14:51:06 -0000
Received: from mail105-va3-R.bigfish.com (10.7.14.241) by
	VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 14:51:02 +0000
Received: from mail105-va3 (localhost [127.0.0.1])	by
	mail105-va3-R.bigfish.com (Postfix) with ESMTP id EB876A0212;
	Fri, 20 Jan 2012 14:51:02 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail105-va3 (localhost.localdomain [127.0.0.1]) by mail105-va3
	(MessageSwitch) id 1327071060718144_1396;
	Fri, 20 Jan 2012 14:51:00 +0000 (UTC)
Received: from VA3EHSMHS024.bigfish.com (unknown [10.7.14.245])	by
	mail105-va3.bigfish.com (Postfix) with ESMTP id A6FC2260045;
	Fri, 20 Jan 2012 14:51:00 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS024.bigfish.com (10.7.99.34) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 14:50:59 +0000
X-WSS-ID: 0LY3QKV-02-BGL-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 2D6E9C80B9;	Fri, 20 Jan 2012 08:50:55 -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;
	Fri, 20 Jan 2012 08:51:18 -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;
	Fri, 20 Jan 2012 08:51:00 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Jan 2012
	09:50:59 -0500
Message-ID: <4F197F52.7040700@amd.com>
Date: Fri, 20 Jan 2012 15:50:58 +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: <4F1974A2.10605@amd.com>
	<4F1989EF020000780006DFB2@nat28.tlf.novell.com>
In-Reply-To: <4F1989EF020000780006DFB2@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/20/12 15:36, Jan Beulich wrote:
>>>> On 20.01.12 at 15:05, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>> Kill __u*/__s* integer types and use c99 integer types instead.
>> Cleanup<asm-x86/types.h>
>
> Was this build-tested for ia64?

No. I don't have such a machine.
Can you do that, please?

Christoph

>
> Jan
>
>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:57:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoFte-0004IC-7C; Fri, 20 Jan 2012 14:56:54 +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 1RoFtc-0004I1-0c
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:56:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327071384!49612057!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 32192 invoked from network); 20 Jan 2012 14:56:24 -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; 20 Jan 2012 14:56:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 14:56:45 +0000
Message-Id: <4F198EFE020000780006DFCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 14:57:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <4F1974A2.10605@amd.com>
	<4F1989EF020000780006DFB2@nat28.tlf.novell.com>
	<4F197F52.7040700@amd.com>
In-Reply-To: <4F197F52.7040700@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] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 15:50, Christoph Egger <Christoph.Egger@amd.com> wrote:
> On 01/20/12 15:36, Jan Beulich wrote:
>>>>> On 20.01.12 at 15:05, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>>> Kill __u*/__s* integer types and use c99 integer types instead.
>>> Cleanup<asm-x86/types.h>
>>
>> Was this build-tested for ia64?
> 
> No. I don't have such a machine.

And you don't need to. You can just use a cross tool chain.

> Can you do that, please?

I'm trying to avoid having to do (a perhaps massive) cleanup after
a patch like this.

If you can't/don't want to do the cross build (given that the ARM
bits are sort of ready to be committed, it might be a good idea to
check against those bits too), then please adjust the patch so
that it won't break the build for arches you don't test.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 14:57:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 14:57:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoFte-0004IC-7C; Fri, 20 Jan 2012 14:56:54 +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 1RoFtc-0004I1-0c
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 14:56:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327071384!49612057!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 32192 invoked from network); 20 Jan 2012 14:56:24 -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; 20 Jan 2012 14:56:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 14:56:45 +0000
Message-Id: <4F198EFE020000780006DFCD@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 14:57:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <4F1974A2.10605@amd.com>
	<4F1989EF020000780006DFB2@nat28.tlf.novell.com>
	<4F197F52.7040700@amd.com>
In-Reply-To: <4F197F52.7040700@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] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 15:50, Christoph Egger <Christoph.Egger@amd.com> wrote:
> On 01/20/12 15:36, Jan Beulich wrote:
>>>>> On 20.01.12 at 15:05, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>>> Kill __u*/__s* integer types and use c99 integer types instead.
>>> Cleanup<asm-x86/types.h>
>>
>> Was this build-tested for ia64?
> 
> No. I don't have such a machine.

And you don't need to. You can just use a cross tool chain.

> Can you do that, please?

I'm trying to avoid having to do (a perhaps massive) cleanup after
a patch like this.

If you can't/don't want to do the cross build (given that the ARM
bits are sort of ready to be committed, it might be a good idea to
check against those bits too), then please adjust the patch so
that it won't break the build for arches you don't test.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:06:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15: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 1RoG2r-0004Vh-8z; Fri, 20 Jan 2012 15:06:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoG2q-0004Vc-3l
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:06:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327071977!8133650!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30673 invoked from network); 20 Jan 2012 15:06:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10180272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 15:06: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, 20 Jan 2012 15:06:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 15:06:16 +0000
In-Reply-To: <1327065091.30054.43.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327071976.30054.55.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 13:11 +0000, Ian Campbell wrote:

> Your patches do the affinity setting pretty early so I'm not sure what's
> going on.

The cpu affinities are set and d->node_affinity is getting correctly
updated to only include one node before any memory is allocated to the
domain, yet memory appears to be being allocated on both nodes.

Strange.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:06:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15: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 1RoG2r-0004Vh-8z; Fri, 20 Jan 2012 15:06:25 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoG2q-0004Vc-3l
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:06:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327071977!8133650!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30673 invoked from network); 20 Jan 2012 15:06:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10180272"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 15:06: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, 20 Jan 2012 15:06:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 15:06:16 +0000
In-Reply-To: <1327065091.30054.43.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327071976.30054.55.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 13:11 +0000, Ian Campbell wrote:

> Your patches do the affinity setting pretty early so I'm not sure what's
> going on.

The cpu affinities are set and d->node_affinity is getting correctly
updated to only include one node before any memory is allocated to the
domain, yet memory appears to be being allocated on both nodes.

Strange.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:17:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoGD9-0004kx-Ij; Fri, 20 Jan 2012 15:17:03 +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 1RoGD8-0004ks-0u
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:17:02 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327072574!56816873!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25225 invoked from network); 20 Jan 2012 15:16:15 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	VA3EHSOBE005.bigfish.com) (216.32.180.31)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:16:15 -0000
Received: from mail87-va3-R.bigfish.com (10.7.14.254) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:16:51 +0000
Received: from mail87-va3 (localhost [127.0.0.1])	by mail87-va3-R.bigfish.com
	(Postfix) with ESMTP id 8151A400087;
	Fri, 20 Jan 2012 15:17:04 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3
	(MessageSwitch) id 132707262362062_18589;
	Fri, 20 Jan 2012 15:17:03 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.242])	by
	mail87-va3.bigfish.com (Postfix) with ESMTP id 0A2BF300049;
	Fri, 20 Jan 2012 15:17:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:16:50 +0000
X-WSS-ID: 0LY3RRY-01-DIY-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 2033E1028235;	Fri, 20 Jan 2012 09:16:45 -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;
	Fri, 20 Jan 2012 09:17:08 -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;
	Fri, 20 Jan 2012 09:16:49 -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; Fri, 20 Jan 2012
	10:16:48 -0500
Message-ID: <4F19855E.6010807@amd.com>
Date: Fri, 20 Jan 2012 16:16:46 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F1974A2.10605@amd.com>
	<4F1989EF020000780006DFB2@nat28.tlf.novell.com>
	<4F197F52.7040700@amd.com>
	<4F198EFE020000780006DFCD@nat28.tlf.novell.com>
In-Reply-To: <4F198EFE020000780006DFCD@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/20/12 15:57, Jan Beulich wrote:
>>>> On 20.01.12 at 15:50, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>> On 01/20/12 15:36, Jan Beulich wrote:
>>>>>> On 20.01.12 at 15:05, Christoph Egger<Christoph.Egger@amd.com>   wrote:
>>>> Kill __u*/__s* integer types and use c99 integer types instead.
>>>> Cleanup<asm-x86/types.h>
>>>
>>> Was this build-tested for ia64?
>>
>> No. I don't have such a machine.
>
> And you don't need to. You can just use a cross tool chain.
>
>> Can you do that, please?
>
> I'm trying to avoid having to do (a perhaps massive) cleanup after
> a patch like this.
>
> If you can't/don't want to do the cross build (given that the ARM
> bits are sort of ready to be committed, it might be a good idea to
> check against those bits too), then please adjust the patch so
> that it won't break the build for arches you don't test.


I just figured this out:

<xen/types.h> includes <asm/types.h> which doesn't exist on ia64.
So I guess ia64 doesn't build anyway...

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:17:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoGD9-0004kx-Ij; Fri, 20 Jan 2012 15:17:03 +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 1RoGD8-0004ks-0u
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:17:02 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327072574!56816873!1
X-Originating-IP: [216.32.180.31]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25225 invoked from network); 20 Jan 2012 15:16:15 -0000
Received: from va3ehsobe005.messaging.microsoft.com (HELO
	VA3EHSOBE005.bigfish.com) (216.32.180.31)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:16:15 -0000
Received: from mail87-va3-R.bigfish.com (10.7.14.254) by
	VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:16:51 +0000
Received: from mail87-va3 (localhost [127.0.0.1])	by mail87-va3-R.bigfish.com
	(Postfix) with ESMTP id 8151A400087;
	Fri, 20 Jan 2012 15:17:04 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3
	(MessageSwitch) id 132707262362062_18589;
	Fri, 20 Jan 2012 15:17:03 +0000 (UTC)
Received: from VA3EHSMHS008.bigfish.com (unknown [10.7.14.242])	by
	mail87-va3.bigfish.com (Postfix) with ESMTP id 0A2BF300049;
	Fri, 20 Jan 2012 15:17:03 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	VA3EHSMHS008.bigfish.com (10.7.99.18) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:16:50 +0000
X-WSS-ID: 0LY3RRY-01-DIY-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 2033E1028235;	Fri, 20 Jan 2012 09:16:45 -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;
	Fri, 20 Jan 2012 09:17:08 -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;
	Fri, 20 Jan 2012 09:16:49 -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; Fri, 20 Jan 2012
	10:16:48 -0500
Message-ID: <4F19855E.6010807@amd.com>
Date: Fri, 20 Jan 2012 16:16:46 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F1974A2.10605@amd.com>
	<4F1989EF020000780006DFB2@nat28.tlf.novell.com>
	<4F197F52.7040700@amd.com>
	<4F198EFE020000780006DFCD@nat28.tlf.novell.com>
In-Reply-To: <4F198EFE020000780006DFCD@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/20/12 15:57, Jan Beulich wrote:
>>>> On 20.01.12 at 15:50, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>> On 01/20/12 15:36, Jan Beulich wrote:
>>>>>> On 20.01.12 at 15:05, Christoph Egger<Christoph.Egger@amd.com>   wrote:
>>>> Kill __u*/__s* integer types and use c99 integer types instead.
>>>> Cleanup<asm-x86/types.h>
>>>
>>> Was this build-tested for ia64?
>>
>> No. I don't have such a machine.
>
> And you don't need to. You can just use a cross tool chain.
>
>> Can you do that, please?
>
> I'm trying to avoid having to do (a perhaps massive) cleanup after
> a patch like this.
>
> If you can't/don't want to do the cross build (given that the ARM
> bits are sort of ready to be committed, it might be a good idea to
> check against those bits too), then please adjust the patch so
> that it won't break the build for arches you don't test.


I just figured this out:

<xen/types.h> includes <asm/types.h> which doesn't exist on ia64.
So I guess ia64 doesn't build anyway...

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:20:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15: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 1RoGGa-0004rF-7H; Fri, 20 Jan 2012 15:20:36 +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 1RoGGY-0004r9-36
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:20:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327072823!11717160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20161 invoked from network); 20 Jan 2012 15:20:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10180831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 15:20:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 15:20:23 +0000
Date: Fri, 20 Jan 2012 15:20:09 +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.1201201128030.3150@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201201513080.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
	<4F185986020000780006DBF9@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201201128030.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 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

On Fri, 20 Jan 2012, Stefano Stabellini wrote:
> On Thu, 19 Jan 2012, Jan Beulich wrote:
> > >>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
> > > As I wanted to use the clear_guest stuff you add here for some
> > > cleanup/latent bug fix in x86's paging code, I pulled this patch into
> > > my local tree. Unfortunately the ia64 bits don't build, as you omitted
> > > the #define-s at the top of the file you took the code from.
> > 
> > Further, the file you put this in is one that shouldn't be modified. The
> > correct way is to simply pull in Linux'es clear_user.S (see below).
> > 
> 
> Yes, I think that you are correct.

Can I add your signed-off-by to this patch?
I have pulled your changes in and removed my changes to
xen/arch/ia64/linux/memcpy_mck.S.


---


Introduce clear_user and clear_guest

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 v6:

- pull Linux'es ia64 clear_user.S.


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>

diff --git a/xen/arch/ia64/linux/Makefile b/xen/arch/ia64/linux/Makefile
index 10ebbfc..6a3704b 100644
--- a/xen/arch/ia64/linux/Makefile
+++ b/xen/arch/ia64/linux/Makefile
@@ -4,6 +4,7 @@ subdir-y += sn
 
 obj-y += bitop.o
 obj-y += clear_page.o
+obj-y += clear_user.o
 obj-y += copy_page_mck.o
 obj-y += efi_stub.o
 obj-y += extable.o
diff --git a/xen/arch/ia64/linux/README.origin b/xen/arch/ia64/linux/README.origin
index 4dc96d3..3727fe5 100644
--- a/xen/arch/ia64/linux/README.origin
+++ b/xen/arch/ia64/linux/README.origin
@@ -15,6 +15,7 @@ pcdp.h			-> linux/drivers/firmware/pcdp.h
 
 bitop.c			-> linux/arch/ia64/lib/bitop.c
 clear_page.S		-> linux/arch/ia64/lib/clear_page.S
+clear_user.S		-> linux/arch/ia64/lib/clear_user.S
 copy_page_mck.S		-> linux/arch/ia64/lib/copy_page_mck.S
 flush.S			-> linux/arch/ia64/lib/flush.S
 idiv32.S		-> linux/arch/ia64/lib/idiv32.S
diff --git a/xen/arch/ia64/linux/clear_user.S b/xen/arch/ia64/linux/clear_user.S
new file mode 100644
index 0000000..eecd857
--- /dev/null
+++ b/xen/arch/ia64/linux/clear_user.S
@@ -0,0 +1,209 @@
+/*
+ * This routine clears to zero a linear memory buffer in user space.
+ *
+ * Inputs:
+ *	in0:	address of buffer
+ *	in1:	length of buffer in bytes
+ * Outputs:
+ *	r8:	number of bytes that didn't get cleared due to a fault
+ *
+ * Copyright (C) 1998, 1999, 2001 Hewlett-Packard Co
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ */
+
+#include <asm/asmmacro.h>
+
+//
+// arguments
+//
+#define buf		r32
+#define len		r33
+
+//
+// local registers
+//
+#define cnt		r16
+#define buf2		r17
+#define saved_lc	r18
+#define saved_pfs	r19
+#define tmp		r20
+#define len2		r21
+#define len3		r22
+
+//
+// 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 160a47f..de1a0ed 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2390,6 +2390,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)
 {
@@ -2476,6 +2566,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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:20:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15: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 1RoGGa-0004rF-7H; Fri, 20 Jan 2012 15:20:36 +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 1RoGGY-0004r9-36
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:20:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327072823!11717160!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20161 invoked from network); 20 Jan 2012 15:20:26 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:20:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208";a="10180831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 15:20:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 15:20:23 +0000
Date: Fri, 20 Jan 2012 15:20:09 +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.1201201128030.3150@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201201513080.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
	<4F185986020000780006DBF9@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201201128030.3150@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 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

On Fri, 20 Jan 2012, Stefano Stabellini wrote:
> On Thu, 19 Jan 2012, Jan Beulich wrote:
> > >>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
> > > As I wanted to use the clear_guest stuff you add here for some
> > > cleanup/latent bug fix in x86's paging code, I pulled this patch into
> > > my local tree. Unfortunately the ia64 bits don't build, as you omitted
> > > the #define-s at the top of the file you took the code from.
> > 
> > Further, the file you put this in is one that shouldn't be modified. The
> > correct way is to simply pull in Linux'es clear_user.S (see below).
> > 
> 
> Yes, I think that you are correct.

Can I add your signed-off-by to this patch?
I have pulled your changes in and removed my changes to
xen/arch/ia64/linux/memcpy_mck.S.


---


Introduce clear_user and clear_guest

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 v6:

- pull Linux'es ia64 clear_user.S.


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>

diff --git a/xen/arch/ia64/linux/Makefile b/xen/arch/ia64/linux/Makefile
index 10ebbfc..6a3704b 100644
--- a/xen/arch/ia64/linux/Makefile
+++ b/xen/arch/ia64/linux/Makefile
@@ -4,6 +4,7 @@ subdir-y += sn
 
 obj-y += bitop.o
 obj-y += clear_page.o
+obj-y += clear_user.o
 obj-y += copy_page_mck.o
 obj-y += efi_stub.o
 obj-y += extable.o
diff --git a/xen/arch/ia64/linux/README.origin b/xen/arch/ia64/linux/README.origin
index 4dc96d3..3727fe5 100644
--- a/xen/arch/ia64/linux/README.origin
+++ b/xen/arch/ia64/linux/README.origin
@@ -15,6 +15,7 @@ pcdp.h			-> linux/drivers/firmware/pcdp.h
 
 bitop.c			-> linux/arch/ia64/lib/bitop.c
 clear_page.S		-> linux/arch/ia64/lib/clear_page.S
+clear_user.S		-> linux/arch/ia64/lib/clear_user.S
 copy_page_mck.S		-> linux/arch/ia64/lib/copy_page_mck.S
 flush.S			-> linux/arch/ia64/lib/flush.S
 idiv32.S		-> linux/arch/ia64/lib/idiv32.S
diff --git a/xen/arch/ia64/linux/clear_user.S b/xen/arch/ia64/linux/clear_user.S
new file mode 100644
index 0000000..eecd857
--- /dev/null
+++ b/xen/arch/ia64/linux/clear_user.S
@@ -0,0 +1,209 @@
+/*
+ * This routine clears to zero a linear memory buffer in user space.
+ *
+ * Inputs:
+ *	in0:	address of buffer
+ *	in1:	length of buffer in bytes
+ * Outputs:
+ *	r8:	number of bytes that didn't get cleared due to a fault
+ *
+ * Copyright (C) 1998, 1999, 2001 Hewlett-Packard Co
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ */
+
+#include <asm/asmmacro.h>
+
+//
+// arguments
+//
+#define buf		r32
+#define len		r33
+
+//
+// local registers
+//
+#define cnt		r16
+#define buf2		r17
+#define saved_lc	r18
+#define saved_pfs	r19
+#define tmp		r20
+#define len2		r21
+#define len3		r22
+
+//
+// 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 160a47f..de1a0ed 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2390,6 +2390,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)
 {
@@ -2476,6 +2566,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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:22:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGHs-0004yM-7G; Fri, 20 Jan 2012 15:21: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 1RoGHq-0004xD-Fi
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:21:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327072908!11890704!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 27758 invoked from network); 20 Jan 2012 15:21:48 -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; 20 Jan 2012 15:21:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 15:21:47 +0000
Message-Id: <4F1994DA020000780006DFF6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 15:22:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <4F1974A2.10605@amd.com>
	<4F1989EF020000780006DFB2@nat28.tlf.novell.com>
	<4F197F52.7040700@amd.com>
	<4F198EFE020000780006DFCD@nat28.tlf.novell.com>
	<4F19855E.6010807@amd.com>
In-Reply-To: <4F19855E.6010807@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] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 16:16, Christoph Egger <Christoph.Egger@amd.com> wrote:
> On 01/20/12 15:57, Jan Beulich wrote:
>>>>> On 20.01.12 at 15:50, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>>> On 01/20/12 15:36, Jan Beulich wrote:
>>>>>>> On 20.01.12 at 15:05, Christoph Egger<Christoph.Egger@amd.com>   wrote:
>>>>> Kill __u*/__s* integer types and use c99 integer types instead.
>>>>> Cleanup<asm-x86/types.h>
>>>>
>>>> Was this build-tested for ia64?
>>>
>>> No. I don't have such a machine.
>>
>> And you don't need to. You can just use a cross tool chain.
>>
>>> Can you do that, please?
>>
>> I'm trying to avoid having to do (a perhaps massive) cleanup after
>> a patch like this.
>>
>> If you can't/don't want to do the cross build (given that the ARM
>> bits are sort of ready to be committed, it might be a good idea to
>> check against those bits too), then please adjust the patch so
>> that it won't break the build for arches you don't test.
> 
> 
> I just figured this out:
> 
> <xen/types.h> includes <asm/types.h> which doesn't exist on ia64.
> So I guess ia64 doesn't build anyway...

Which is obviously not the case. There are multiple places where you
need to look for such a header on ia64 - in this case, it's in
xen/include/asm-ia64/linux-xen/asm.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:22:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGHs-0004yM-7G; Fri, 20 Jan 2012 15:21: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 1RoGHq-0004xD-Fi
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:21:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327072908!11890704!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 27758 invoked from network); 20 Jan 2012 15:21:48 -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; 20 Jan 2012 15:21:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 15:21:47 +0000
Message-Id: <4F1994DA020000780006DFF6@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 15:22:50 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Christoph Egger" <Christoph.Egger@amd.com>
References: <4F1974A2.10605@amd.com>
	<4F1989EF020000780006DFB2@nat28.tlf.novell.com>
	<4F197F52.7040700@amd.com>
	<4F198EFE020000780006DFCD@nat28.tlf.novell.com>
	<4F19855E.6010807@amd.com>
In-Reply-To: <4F19855E.6010807@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] xen: kill __u*/__s* integer types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 16:16, Christoph Egger <Christoph.Egger@amd.com> wrote:
> On 01/20/12 15:57, Jan Beulich wrote:
>>>>> On 20.01.12 at 15:50, Christoph Egger<Christoph.Egger@amd.com>  wrote:
>>> On 01/20/12 15:36, Jan Beulich wrote:
>>>>>>> On 20.01.12 at 15:05, Christoph Egger<Christoph.Egger@amd.com>   wrote:
>>>>> Kill __u*/__s* integer types and use c99 integer types instead.
>>>>> Cleanup<asm-x86/types.h>
>>>>
>>>> Was this build-tested for ia64?
>>>
>>> No. I don't have such a machine.
>>
>> And you don't need to. You can just use a cross tool chain.
>>
>>> Can you do that, please?
>>
>> I'm trying to avoid having to do (a perhaps massive) cleanup after
>> a patch like this.
>>
>> If you can't/don't want to do the cross build (given that the ARM
>> bits are sort of ready to be committed, it might be a good idea to
>> check against those bits too), then please adjust the patch so
>> that it won't break the build for arches you don't test.
> 
> 
> I just figured this out:
> 
> <xen/types.h> includes <asm/types.h> which doesn't exist on ia64.
> So I guess ia64 doesn't build anyway...

Which is obviously not the case. There are multiple places where you
need to look for such a header on ia64 - in this case, it's in
xen/include/asm-ia64/linux-xen/asm.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:31:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGQP-0005Kj-D2; Fri, 20 Jan 2012 15:30:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RoGQO-0005Ke-58
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:30:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327073436!11915106!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5NDgzOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11697 invoked from network); 20 Jan 2012 15:30:37 -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; 20 Jan 2012 15:30:37 -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
	q0KFUTNq006075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 15:30:30 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
	q0KFUSJR017467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 15:30:29 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
	q0KFUROf017618; Fri, 20 Jan 2012 09:30:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 07:30:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1E7894032A; Fri, 20 Jan 2012 10:28:19 -0500 (EST)
Date: Fri, 20 Jan 2012 10:28:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Message-ID: <20120120152819.GA3959@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F198896.0111,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, akpm@linux-foundation.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 21, 2012 at 12:15:26AM +0900, Akinobu Mita wrote:
> Use bitmap_set and bitmap_clear rather than modifying individual bits
> in a memory region.
> 
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> ---
>  drivers/block/xen-blkfront.c |    7 +++----
>  1 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..619868d 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -43,6 +43,7 @@
>  #include <linux/slab.h>
>  #include <linux/mutex.h>
>  #include <linux/scatterlist.h>
> +#include <linux/bitmap.h>
>  
>  #include <xen/xen.h>
>  #include <xen/xenbus.h>
> @@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  
>  	spin_lock(&minor_lock);
>  	if (find_next_bit(minors, end, minor) >= end) {
> -		for (; minor < end; ++minor)
> -			__set_bit(minor, minors);
> +		bitmap_set(minors, minor, nr);

Hm, I would have thought the last argument should have been 'end'?

Did you test this patch with a large amount of minors?

>  		rc = 0;
>  	} else
>  		rc = -EBUSY;
> @@ -193,8 +193,7 @@ static void xlbd_release_minors(unsigned int minor, unsigned int nr)
>  
>  	BUG_ON(end > nr_minors);
>  	spin_lock(&minor_lock);
> -	for (; minor < end; ++minor)
> -		__clear_bit(minor, minors);
> +	bitmap_clear(minors,  minor, nr);

Ditto.
>  	spin_unlock(&minor_lock);
>  }
>  
> -- 
> 1.7.4.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  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 Jan 20 15:31:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGQP-0005Kj-D2; Fri, 20 Jan 2012 15:30:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RoGQO-0005Ke-58
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:30:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327073436!11915106!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5NDgzOA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11697 invoked from network); 20 Jan 2012 15:30:37 -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; 20 Jan 2012 15:30:37 -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
	q0KFUTNq006075
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 15:30:30 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
	q0KFUSJR017467
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 15:30:29 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
	q0KFUROf017618; Fri, 20 Jan 2012 09:30:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 07:30:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 1E7894032A; Fri, 20 Jan 2012 10:28:19 -0500 (EST)
Date: Fri, 20 Jan 2012 10:28:19 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Message-ID: <20120120152819.GA3959@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F198896.0111,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, akpm@linux-foundation.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 21, 2012 at 12:15:26AM +0900, Akinobu Mita wrote:
> Use bitmap_set and bitmap_clear rather than modifying individual bits
> in a memory region.
> 
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> ---
>  drivers/block/xen-blkfront.c |    7 +++----
>  1 files changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2f22874..619868d 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -43,6 +43,7 @@
>  #include <linux/slab.h>
>  #include <linux/mutex.h>
>  #include <linux/scatterlist.h>
> +#include <linux/bitmap.h>
>  
>  #include <xen/xen.h>
>  #include <xen/xenbus.h>
> @@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor, unsigned int nr)
>  
>  	spin_lock(&minor_lock);
>  	if (find_next_bit(minors, end, minor) >= end) {
> -		for (; minor < end; ++minor)
> -			__set_bit(minor, minors);
> +		bitmap_set(minors, minor, nr);

Hm, I would have thought the last argument should have been 'end'?

Did you test this patch with a large amount of minors?

>  		rc = 0;
>  	} else
>  		rc = -EBUSY;
> @@ -193,8 +193,7 @@ static void xlbd_release_minors(unsigned int minor, unsigned int nr)
>  
>  	BUG_ON(end > nr_minors);
>  	spin_lock(&minor_lock);
> -	for (; minor < end; ++minor)
> -		__clear_bit(minor, minors);
> +	bitmap_clear(minors,  minor, nr);

Ditto.
>  	spin_unlock(&minor_lock);
>  }
>  
> -- 
> 1.7.4.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  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 Jan 20 15:34:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:34:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGTo-0005VD-2f; Fri, 20 Jan 2012 15:34:16 +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 1RoGTm-0005UZ-33
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:34:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327073647!11684521!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 15708 invoked from network); 20 Jan 2012 15:34:07 -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; 20 Jan 2012 15:34:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 15:34:07 +0000
Message-Id: <4F1997BF020000780006E012@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 15:35:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
	<4F185986020000780006DBF9@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201201128030.3150@kaball-desktop>
	<alpine.DEB.2.00.1201201513080.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201201513080.3196@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 v5 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

>>> On 20.01.12 at 16:20, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 20 Jan 2012, Stefano Stabellini wrote:
>> On Thu, 19 Jan 2012, Jan Beulich wrote:
>> > >>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
>> > > As I wanted to use the clear_guest stuff you add here for some
>> > > cleanup/latent bug fix in x86's paging code, I pulled this patch into
>> > > my local tree. Unfortunately the ia64 bits don't build, as you omitted
>> > > the #define-s at the top of the file you took the code from.
>> > 
>> > Further, the file you put this in is one that shouldn't be modified. The
>> > correct way is to simply pull in Linux'es clear_user.S (see below).
>> > 
>> 
>> Yes, I think that you are correct.
> 
> Can I add your signed-off-by to this patch?
> I have pulled your changes in and removed my changes to
> xen/arch/ia64/linux/memcpy_mck.S.

S-O-B would seem too much (I didn't really write any code here, and
didn't touch the non-ia64 bits at all). An Acked-By would be okay, or
else you'd have to split the ia64 bits from the rest (and they could
really go in independently).

Btw., what's the take on getting at least the common code cleanup/
adjustment patches committed? I had recommended taking them
already after you had posted v5 (but now I'm glad they didn't get
committed without this ia64 issue addressed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:34:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:34:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGTo-0005VD-2f; Fri, 20 Jan 2012 15:34:16 +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 1RoGTm-0005UZ-33
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:34:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327073647!11684521!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 15708 invoked from network); 20 Jan 2012 15:34:07 -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; 20 Jan 2012 15:34:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 15:34:07 +0000
Message-Id: <4F1997BF020000780006E012@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 15:35:11 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
	<4F185986020000780006DBF9@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201201128030.3150@kaball-desktop>
	<alpine.DEB.2.00.1201201513080.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201201513080.3196@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 v5 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

>>> On 20.01.12 at 16:20, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 20 Jan 2012, Stefano Stabellini wrote:
>> On Thu, 19 Jan 2012, Jan Beulich wrote:
>> > >>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
>> > > As I wanted to use the clear_guest stuff you add here for some
>> > > cleanup/latent bug fix in x86's paging code, I pulled this patch into
>> > > my local tree. Unfortunately the ia64 bits don't build, as you omitted
>> > > the #define-s at the top of the file you took the code from.
>> > 
>> > Further, the file you put this in is one that shouldn't be modified. The
>> > correct way is to simply pull in Linux'es clear_user.S (see below).
>> > 
>> 
>> Yes, I think that you are correct.
> 
> Can I add your signed-off-by to this patch?
> I have pulled your changes in and removed my changes to
> xen/arch/ia64/linux/memcpy_mck.S.

S-O-B would seem too much (I didn't really write any code here, and
didn't touch the non-ia64 bits at all). An Acked-By would be okay, or
else you'd have to split the ia64 bits from the rest (and they could
really go in independently).

Btw., what's the take on getting at least the common code cleanup/
adjustment patches committed? I had recommended taking them
already after you had posted v5 (but now I'm glad they didn't get
committed without this ia64 issue addressed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:46:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGf5-0005q2-N0; Fri, 20 Jan 2012 15:45:55 +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 1RoGf4-0005pt-8H
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:45:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327074348!11873181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29332 invoked from network); 20 Jan 2012 15:45:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10181402"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 15:45: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, 20 Jan 2012 15:45: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 1RoGex-00084h-8Z;
	Fri, 20 Jan 2012 15:45:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoGex-0007kN-1M;
	Fri, 20 Jan 2012 15:45:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10914-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Jan 2012 15:45:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10914: 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 10914 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10914/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-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-i386-i386-xl-winxpsp3   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-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass

version targeted for testing:
 xen                  49bf114c23f5
baseline version:
 xen                  27e959546916

------------------------------------------------------------
People who touched revisions under test:
  James Carter <jwcart2@tycho.nsa.gov>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=49bf114c23f5
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 49bf114c23f5
+ branch=xen-4.1-testing
+ revision=49bf114c23f5
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 49bf114c23f5 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:46:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGf5-0005q2-N0; Fri, 20 Jan 2012 15:45:55 +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 1RoGf4-0005pt-8H
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:45:54 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327074348!11873181!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29332 invoked from network); 20 Jan 2012 15:45:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:45:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10181402"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 15:45: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, 20 Jan 2012 15:45: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 1RoGex-00084h-8Z;
	Fri, 20 Jan 2012 15:45:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoGex-0007kN-1M;
	Fri, 20 Jan 2012 15:45:47 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10914-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Jan 2012 15:45:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 10914: 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 10914 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10914/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-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-i386-i386-xl-winxpsp3   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-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass

version targeted for testing:
 xen                  49bf114c23f5
baseline version:
 xen                  27e959546916

------------------------------------------------------------
People who touched revisions under test:
  James Carter <jwcart2@tycho.nsa.gov>
  Jan Beulich <jbeulich@suse.com>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=49bf114c23f5
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 49bf114c23f5
+ branch=xen-4.1-testing
+ revision=49bf114c23f5
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 49bf114c23f5 ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-4.1-testing.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:47:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGfp-0005sW-50; Fri, 20 Jan 2012 15:46:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoGfn-0005sD-7u
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:46:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327074392!9386803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30326 invoked from network); 20 Jan 2012 15:46:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:46:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10181416"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 15:46: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, 20 Jan 2012 15:46:32 +0000
Date: Fri, 20 Jan 2012 15:46:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F1997BF020000780006E012@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201201545310.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
	<4F185986020000780006DBF9@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201201128030.3150@kaball-desktop>
	<alpine.DEB.2.00.1201201513080.3196@kaball-desktop>
	<4F1997BF020000780006E012@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>,
	Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 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

On Fri, 20 Jan 2012, Jan Beulich wrote:
> >>> On 20.01.12 at 16:20, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 20 Jan 2012, Stefano Stabellini wrote:
> >> On Thu, 19 Jan 2012, Jan Beulich wrote:
> >> > >>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> > > As I wanted to use the clear_guest stuff you add here for some
> >> > > cleanup/latent bug fix in x86's paging code, I pulled this patch into
> >> > > my local tree. Unfortunately the ia64 bits don't build, as you omitted
> >> > > the #define-s at the top of the file you took the code from.
> >> > 
> >> > Further, the file you put this in is one that shouldn't be modified. The
> >> > correct way is to simply pull in Linux'es clear_user.S (see below).
> >> > 
> >> 
> >> Yes, I think that you are correct.
> > 
> > Can I add your signed-off-by to this patch?
> > I have pulled your changes in and removed my changes to
> > xen/arch/ia64/linux/memcpy_mck.S.
> 
> S-O-B would seem too much (I didn't really write any code here, and
> didn't touch the non-ia64 bits at all). An Acked-By would be okay, or
> else you'd have to split the ia64 bits from the rest (and they could
> really go in independently).

OK, I'll resend the series.

> Btw., what's the take on getting at least the common code cleanup/
> adjustment patches committed? I had recommended taking them
> already after you had posted v5 (but now I'm glad they didn't get
> committed without this ia64 issue addressed).

My take is that they should go in :)
Keir?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:47:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:47:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGfp-0005sW-50; Fri, 20 Jan 2012 15:46:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoGfn-0005sD-7u
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:46:39 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327074392!9386803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30326 invoked from network); 20 Jan 2012 15:46:33 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 15:46:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10181416"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 15:46: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, 20 Jan 2012 15:46:32 +0000
Date: Fri, 20 Jan 2012 15:46:16 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F1997BF020000780006E012@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201201545310.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201101352430.3150@kaball-desktop>
	<1326298757-9846-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F185708020000780006DBEA@nat28.tlf.novell.com>
	<4F185986020000780006DBF9@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201201128030.3150@kaball-desktop>
	<alpine.DEB.2.00.1201201513080.3196@kaball-desktop>
	<4F1997BF020000780006E012@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>,
	Keir Fraser <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 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

On Fri, 20 Jan 2012, Jan Beulich wrote:
> >>> On 20.01.12 at 16:20, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 20 Jan 2012, Stefano Stabellini wrote:
> >> On Thu, 19 Jan 2012, Jan Beulich wrote:
> >> > >>> On 19.01.12 at 17:46, "Jan Beulich" <JBeulich@suse.com> wrote:
> >> > > As I wanted to use the clear_guest stuff you add here for some
> >> > > cleanup/latent bug fix in x86's paging code, I pulled this patch into
> >> > > my local tree. Unfortunately the ia64 bits don't build, as you omitted
> >> > > the #define-s at the top of the file you took the code from.
> >> > 
> >> > Further, the file you put this in is one that shouldn't be modified. The
> >> > correct way is to simply pull in Linux'es clear_user.S (see below).
> >> > 
> >> 
> >> Yes, I think that you are correct.
> > 
> > Can I add your signed-off-by to this patch?
> > I have pulled your changes in and removed my changes to
> > xen/arch/ia64/linux/memcpy_mck.S.
> 
> S-O-B would seem too much (I didn't really write any code here, and
> didn't touch the non-ia64 bits at all). An Acked-By would be okay, or
> else you'd have to split the ia64 bits from the rest (and they could
> really go in independently).

OK, I'll resend the series.

> Btw., what's the take on getting at least the common code cleanup/
> adjustment patches committed? I had recommended taking them
> already after you had posted v5 (but now I'm glad they didn't get
> committed without this ia64 issue addressed).

My take is that they should go in :)
Keir?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGh1-0005yX-LX; Fri, 20 Jan 2012 15:47: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 1RoGh0-0005xy-Lg; Fri, 20 Jan 2012 15:47:54 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327074467!11712758!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODkyMDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6024 invoked from network); 20 Jan 2012 15:47:48 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 15:47: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 4FF81281F;
	Fri, 20 Jan 2012 17:47:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2F836200B0; Fri, 20 Jan 2012 17:47:46 +0200 (EET)
Date: Fri, 20 Jan 2012 17:47:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120120154745.GV12984@reaktio.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>    Hello,
>    I have spent a lot of time trying to get gfx passthru working on my system
>    without success.
>    I looked onto my hardware capabilities again to make sure that it does
>    support VT-d and I am not too sure that it does fully.
>    My hardware is as follows:
>    - Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
>    - single Xeon X5650 CPU (which is listed as supporting VT-x, no mention of
>    VT-d at [1]ark.intel.com)
>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset AND CPU
>    need to support VT-d.
>    What confuses me is, why is the 55x0 chipset listed there if none of the
>    CPU's supported, that I know of, dont have the VT-d feature option, only
>    VT-x.
>

I've been using VT-d with Xen with Intel 5500 series chipset, and Xeon 5600 series CPU.
VT-d needs to be enabled in the BIOS.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:48:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:48:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGh1-0005yX-LX; Fri, 20 Jan 2012 15:47: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 1RoGh0-0005xy-Lg; Fri, 20 Jan 2012 15:47:54 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327074467!11712758!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODkyMDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6024 invoked from network); 20 Jan 2012 15:47:48 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 15:47: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 4FF81281F;
	Fri, 20 Jan 2012 17:47:46 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 2F836200B0; Fri, 20 Jan 2012 17:47:46 +0200 (EET)
Date: Fri, 20 Jan 2012 17:47:46 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120120154745.GV12984@reaktio.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>    Hello,
>    I have spent a lot of time trying to get gfx passthru working on my system
>    without success.
>    I looked onto my hardware capabilities again to make sure that it does
>    support VT-d and I am not too sure that it does fully.
>    My hardware is as follows:
>    - Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
>    - single Xeon X5650 CPU (which is listed as supporting VT-x, no mention of
>    VT-d at [1]ark.intel.com)
>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset AND CPU
>    need to support VT-d.
>    What confuses me is, why is the 55x0 chipset listed there if none of the
>    CPU's supported, that I know of, dont have the VT-d feature option, only
>    VT-x.
>

I've been using VT-d with Xen with Intel 5500 series chipset, and Xeon 5600 series CPU.
VT-d needs to be enabled in the BIOS.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:52:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGlV-0006Sc-3M; Fri, 20 Jan 2012 15:52:33 +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 1RoGlT-0006SP-N8
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:52:31 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327074701!51108593!1
X-Originating-IP: [65.55.88.13]
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 18567 invoked from network); 20 Jan 2012 15:51:42 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.13)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:51:42 -0000
Received: from mail16-tx2-R.bigfish.com (10.9.14.250) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:25 +0000
Received: from mail16-tx2 (localhost [127.0.0.1])	by mail16-tx2-R.bigfish.com
	(Postfix) with ESMTP id 5291044061C	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 15:52:26 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zz14ffO4015Lzz1202hzz8275bh8275dhz2dhc1bhc31hc1ah668h839h)
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-tx2 (localhost.localdomain [127.0.0.1]) by mail16-tx2
	(MessageSwitch) id 1327074745968440_17320;
	Fri, 20 Jan 2012 15:52:25 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.243])	by
	mail16-tx2.bigfish.com (Postfix) with ESMTP id D88C44C0072	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:23 +0000
X-WSS-ID: 0LY3TFD-01-G27-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 2E53B102808B	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:52:24 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Jan 2012 09:52:43 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 20 Jan 2012 09:52:24 -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, 20 Jan 2012
	10:51:12 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 978D649C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:51:10 +0000 (GMT)
Message-ID: <4F198E2C.3090703@amd.com>
Date: Fri, 20 Jan 2012 16:54:20 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <patchbomb.1327074280@gran.amd.com>
In-Reply-To: <patchbomb.1327074280@gran.amd.com>
X-Forwarded-Message-Id: <patchbomb.1327074280@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU passthru
 on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry forgot to CC xen-devel
Thanks,
Wei

Hi all, this is patch v4.
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 beenenabled in guest 
OS. This patch set adds initial
iommu emulation for hvm guests to support ATS device passthru.

This patch set should work together with following hw & sw systems:

* Host system with AMD trinity APU which has enhanced iommu(iommuv2).
* AMD Radeon HD 7900 series graphic card.
* Linux 3.3 or later which has included iommuv2 kernel driver.
* AMD catalyst or open source Radeon driver in guest that support HD7900.

Most of the works is done by hypervisor. a new guest config parameter
guest_iommu = {1,0} is introduced to en/disable iommu emulation.
3 hyper-calls are added to support communications among different xen 
components.

* iommu_set_msi: used by qemu to inform hypervisor iommu vector number 
in guest space. Hypervisor needs this vector to inject msi into guest 
after write PPR log entry into guest buffer.

* iommu_bind_bdf: used by xl to bind virtual bdf of passthru device to 
machine bdf. IOMMU emulator receives iommu cmd from guest OS and then 
forwards them  to host iommu. But virtual device id in cmds from guest 
should be converted into physical id before sending them to real hardware.

* guest_iommu_set_base: IOMMU MMIO base address is dynamically allocated 
by firmware. This hypercall allows hvmloader to notify hypervisor where 
the iommu mmio pages are.

I had a picture to explain this better, pls refer to the link.

http://www.amd64.org/pub/iommuv2.png

Thanks,
Wei

======================================================================

changes in v4:
* Only tools part in this version, since hypervisor patches have already 
been committed.
* rename guest config option from "iommu = {0,1}" to "guest_iommu = {0,1}"
* add description into docs/man/xl.cfg.pod.5


changes in v3:
* Use xenstore to receive guest iommu configuration instead of adding in 
a new field in hvm_info_table.
* Support pci segment in vbdf to mbdf bind.
* Make hypercalls visible for non-x86 platforms.
* A few code cleanups according to comments from Jan and Ian.

Changes in v2:
* Do not use linked list to access guest iommu tables.
* Do not parse iommu parameter in libxl_device_model_info again.
* Fix incorrect logical calculation in patch 11.
* Fix hypercall definition for non-x86 systems.

Thanks,
Wei
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:52:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:52:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGlV-0006Sc-3M; Fri, 20 Jan 2012 15:52:33 +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 1RoGlT-0006SP-N8
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:52:31 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327074701!51108593!1
X-Originating-IP: [65.55.88.13]
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 18567 invoked from network); 20 Jan 2012 15:51:42 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE005.bigfish.com) (65.55.88.13)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:51:42 -0000
Received: from mail16-tx2-R.bigfish.com (10.9.14.250) by
	TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:25 +0000
Received: from mail16-tx2 (localhost [127.0.0.1])	by mail16-tx2-R.bigfish.com
	(Postfix) with ESMTP id 5291044061C	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 15:52:26 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VPS-11(zz14ffO4015Lzz1202hzz8275bh8275dhz2dhc1bhc31hc1ah668h839h)
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-tx2 (localhost.localdomain [127.0.0.1]) by mail16-tx2
	(MessageSwitch) id 1327074745968440_17320;
	Fri, 20 Jan 2012 15:52:25 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.243])	by
	mail16-tx2.bigfish.com (Postfix) with ESMTP id D88C44C0072	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:25 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:23 +0000
X-WSS-ID: 0LY3TFD-01-G27-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 2E53B102808B	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:52:24 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Jan 2012 09:52:43 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 20 Jan 2012 09:52:24 -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, 20 Jan 2012
	10:51:12 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 978D649C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:51:10 +0000 (GMT)
Message-ID: <4F198E2C.3090703@amd.com>
Date: Fri, 20 Jan 2012 16:54:20 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <patchbomb.1327074280@gran.amd.com>
In-Reply-To: <patchbomb.1327074280@gran.amd.com>
X-Forwarded-Message-Id: <patchbomb.1327074280@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU passthru
 on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry forgot to CC xen-devel
Thanks,
Wei

Hi all, this is patch v4.
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 beenenabled in guest 
OS. This patch set adds initial
iommu emulation for hvm guests to support ATS device passthru.

This patch set should work together with following hw & sw systems:

* Host system with AMD trinity APU which has enhanced iommu(iommuv2).
* AMD Radeon HD 7900 series graphic card.
* Linux 3.3 or later which has included iommuv2 kernel driver.
* AMD catalyst or open source Radeon driver in guest that support HD7900.

Most of the works is done by hypervisor. a new guest config parameter
guest_iommu = {1,0} is introduced to en/disable iommu emulation.
3 hyper-calls are added to support communications among different xen 
components.

* iommu_set_msi: used by qemu to inform hypervisor iommu vector number 
in guest space. Hypervisor needs this vector to inject msi into guest 
after write PPR log entry into guest buffer.

* iommu_bind_bdf: used by xl to bind virtual bdf of passthru device to 
machine bdf. IOMMU emulator receives iommu cmd from guest OS and then 
forwards them  to host iommu. But virtual device id in cmds from guest 
should be converted into physical id before sending them to real hardware.

* guest_iommu_set_base: IOMMU MMIO base address is dynamically allocated 
by firmware. This hypercall allows hvmloader to notify hypervisor where 
the iommu mmio pages are.

I had a picture to explain this better, pls refer to the link.

http://www.amd64.org/pub/iommuv2.png

Thanks,
Wei

======================================================================

changes in v4:
* Only tools part in this version, since hypervisor patches have already 
been committed.
* rename guest config option from "iommu = {0,1}" to "guest_iommu = {0,1}"
* add description into docs/man/xl.cfg.pod.5


changes in v3:
* Use xenstore to receive guest iommu configuration instead of adding in 
a new field in hvm_info_table.
* Support pci segment in vbdf to mbdf bind.
* Make hypercalls visible for non-x86 platforms.
* A few code cleanups according to comments from Jan and Ian.

Changes in v2:
* Do not use linked list to access guest iommu tables.
* Do not parse iommu parameter in libxl_device_model_info again.
* Fix incorrect logical calculation in patch 11.
* Fix hypercall definition for non-x86 systems.

Thanks,
Wei
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:53:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGm2-0006Xp-Mq; Fri, 20 Jan 2012 15:53: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 1RoGm1-0006Wi-LF
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:53:05 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327074777!9992298!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 18872 invoked from network); 20 Jan 2012 15:52:58 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:52:58 -0000
Received: from mail142-tx2-R.bigfish.com (10.9.14.239) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:54 +0000
Received: from mail142-tx2 (localhost [127.0.0.1])	by
	mail142-tx2-R.bigfish.com (Postfix) with ESMTP id 86523520307	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
X-SpamScore: -1
X-BigFish: VPS-1(zf7Izzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h61h)
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 mail142-tx2 (localhost.localdomain [127.0.0.1]) by mail142-tx2
	(MessageSwitch) id 1327074774384600_13886;
	Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.239])	by
	mail142-tx2.bigfish.com (Postfix) with ESMTP id 5667D80042	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:50 +0000
X-WSS-ID: 0LY3TG4-01-G3S-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 2A0161028088	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:52:52 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Jan 2012 09:53:11 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 20 Jan 2012 09:52: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, 20 Jan 2012
	10:52:50 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2F91949C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:49 +0000 (GMT)
Message-ID: <4F198E8F.2020502@amd.com>
Date: Fri, 20 Jan 2012 16:55:59 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <c5cd29b41f2526bb4f93.1327074283@gran.amd.com>
In-Reply-To: <c5cd29b41f2526bb4f93.1327074283@gran.amd.com>
X-Forwarded-Message-Id: <c5cd29b41f2526bb4f93.1327074283@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Fwd: [osrc-patches] [PATCH 3 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066823 -3600
# Node ID c5cd29b41f2526bb4f93c76ceade924feac1f1c3
# Parent  ea3af8fa078c07d357de79931a102450b59156ea
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 ea3af8fa078c -r c5cd29b41f25 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Jan 20 14:40:20 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Fri Jan 20 14:40:23 2012 +0100
@@ -65,6 +65,7 @@
  #include <public/memory.h>
  #include <asm/mem_event.h>
  #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>

  bool_t __read_mostly hvm_enabled;

@@ -3673,6 +3674,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 ea3af8fa078c -r c5cd29b41f25 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Fri Jan 20 14:40:20 2012 +0100
+++ b/xen/include/public/hvm/params.h	Fri Jan 20 14:40:23 2012 +0100
@@ -141,7 +141,8 @@

  /* Boolean: Enable nestedhvm (hvm only) */
  #define HVM_PARAM_NESTEDHVM    24
+#define HVM_PARAM_IOMMU_BASE   27

-#define HVM_NR_PARAMS          27
+#define HVM_NR_PARAMS          28

  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:53:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:53:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGm2-0006Xp-Mq; Fri, 20 Jan 2012 15:53: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 1RoGm1-0006Wi-LF
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:53:05 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327074777!9992298!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 18872 invoked from network); 20 Jan 2012 15:52:58 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-8.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:52:58 -0000
Received: from mail142-tx2-R.bigfish.com (10.9.14.239) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:54 +0000
Received: from mail142-tx2 (localhost [127.0.0.1])	by
	mail142-tx2-R.bigfish.com (Postfix) with ESMTP id 86523520307	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
X-SpamScore: -1
X-BigFish: VPS-1(zf7Izzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h61h)
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 mail142-tx2 (localhost.localdomain [127.0.0.1]) by mail142-tx2
	(MessageSwitch) id 1327074774384600_13886;
	Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.239])	by
	mail142-tx2.bigfish.com (Postfix) with ESMTP id 5667D80042	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:50 +0000
X-WSS-ID: 0LY3TG4-01-G3S-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 2A0161028088	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:52:52 -0600 (CST)
Received: from SAUSEXDAG04.amd.com (163.181.55.4) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Fri, 20 Jan 2012 09:53:11 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 20 Jan 2012 09:52: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, 20 Jan 2012
	10:52:50 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2F91949C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:49 +0000 (GMT)
Message-ID: <4F198E8F.2020502@amd.com>
Date: Fri, 20 Jan 2012 16:55:59 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <c5cd29b41f2526bb4f93.1327074283@gran.amd.com>
In-Reply-To: <c5cd29b41f2526bb4f93.1327074283@gran.amd.com>
X-Forwarded-Message-Id: <c5cd29b41f2526bb4f93.1327074283@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Fwd: [osrc-patches] [PATCH 3 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066823 -3600
# Node ID c5cd29b41f2526bb4f93c76ceade924feac1f1c3
# Parent  ea3af8fa078c07d357de79931a102450b59156ea
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 ea3af8fa078c -r c5cd29b41f25 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Fri Jan 20 14:40:20 2012 +0100
+++ b/xen/arch/x86/hvm/hvm.c	Fri Jan 20 14:40:23 2012 +0100
@@ -65,6 +65,7 @@
  #include <public/memory.h>
  #include <asm/mem_event.h>
  #include <public/mem_event.h>
+#include <asm/hvm/svm/amd-iommu-proto.h>

  bool_t __read_mostly hvm_enabled;

@@ -3673,6 +3674,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 ea3af8fa078c -r c5cd29b41f25 xen/include/public/hvm/params.h
--- a/xen/include/public/hvm/params.h	Fri Jan 20 14:40:20 2012 +0100
+++ b/xen/include/public/hvm/params.h	Fri Jan 20 14:40:23 2012 +0100
@@ -141,7 +141,8 @@

  /* Boolean: Enable nestedhvm (hvm only) */
  #define HVM_PARAM_NESTEDHVM    24
+#define HVM_PARAM_IOMMU_BASE   27

-#define HVM_NR_PARAMS          27
+#define HVM_NR_PARAMS          28

  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:54:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:54:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGmj-0006fC-5z; Fri, 20 Jan 2012 15:53:49 +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 1RoGmh-0006eo-E3
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:53:47 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327074778!51108812!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 22382 invoked from network); 20 Jan 2012 15:52:59 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:52:59 -0000
Received: from mail39-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:53:43 +0000
Received: from mail39-am1 (localhost [127.0.0.1])	by mail39-am1-R.bigfish.com
	(Postfix) with ESMTP id DF4C5E02DF	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 15:53:42 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1
	(MessageSwitch) id 132707482165436_23785;
	Fri, 20 Jan 2012 15:53:41 +0000 (UTC)
Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.242])	by
	mail39-am1.bigfish.com (Postfix) with ESMTP id 0C2E9400045	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:41 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:53:41 +0000
X-WSS-ID: 0LY3THH-01-G7S-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 250971028238	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:53:40 -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;
	Fri, 20 Jan 2012 09:53:59 -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;
	Fri, 20 Jan 2012 09:53:40 -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, 20 Jan 2012
	10:53:39 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6B93749C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:38 +0000 (GMT)
Message-ID: <4F198EC0.6070302@amd.com>
Date: Fri, 20 Jan 2012 16:56:48 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <a768bb39d0bc64360055.1327074286@gran.amd.com>
In-Reply-To: <a768bb39d0bc64360055.1327074286@gran.amd.com>
X-Forwarded-Message-Id: <a768bb39d0bc64360055.1327074286@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 6 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066832 -3600
# Node ID a768bb39d0bc64360055e7fce0e890be71920e63
# Parent  423003c2a91fde16798b09ff2623b03467149b49
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 423003c2a91f -r a768bb39d0bc tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Jan 20 14:40:29 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Jan 20 14:40:32 2012 +0100
@@ -721,6 +721,13 @@ out:
              LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, 
"xc_assign_device failed");
              return ERROR_FAIL;
          }
+        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, 0, 
pcidev->vdevfn, pcidev->domain, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+                LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, 
"xc_domain_bind_pt_bdf failed");
+                return ERROR_FAIL;
+            }
+        }
      }

      if (!starting)
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:54:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:54:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGmj-0006fC-5z; Fri, 20 Jan 2012 15:53:49 +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 1RoGmh-0006eo-E3
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:53:47 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327074778!51108812!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 22382 invoked from network); 20 Jan 2012 15:52:59 -0000
Received: from am1ehsobe005.messaging.microsoft.com (HELO
	AM1EHSOBE005.bigfish.com) (213.199.154.208)
	by server-5.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:52:59 -0000
Received: from mail39-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:53:43 +0000
Received: from mail39-am1 (localhost [127.0.0.1])	by mail39-am1-R.bigfish.com
	(Postfix) with ESMTP id DF4C5E02DF	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 15:53:42 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail39-am1 (localhost.localdomain [127.0.0.1]) by mail39-am1
	(MessageSwitch) id 132707482165436_23785;
	Fri, 20 Jan 2012 15:53:41 +0000 (UTC)
Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.242])	by
	mail39-am1.bigfish.com (Postfix) with ESMTP id 0C2E9400045	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:41 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:53:41 +0000
X-WSS-ID: 0LY3THH-01-G7S-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 250971028238	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:53:40 -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;
	Fri, 20 Jan 2012 09:53:59 -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;
	Fri, 20 Jan 2012 09:53:40 -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, 20 Jan 2012
	10:53:39 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 6B93749C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:38 +0000 (GMT)
Message-ID: <4F198EC0.6070302@amd.com>
Date: Fri, 20 Jan 2012 16:56:48 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <a768bb39d0bc64360055.1327074286@gran.amd.com>
In-Reply-To: <a768bb39d0bc64360055.1327074286@gran.amd.com>
X-Forwarded-Message-Id: <a768bb39d0bc64360055.1327074286@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 6 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066832 -3600
# Node ID a768bb39d0bc64360055e7fce0e890be71920e63
# Parent  423003c2a91fde16798b09ff2623b03467149b49
libxl: bind virtual bdf to physical bdf after device assignment

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 423003c2a91f -r a768bb39d0bc tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Fri Jan 20 14:40:29 2012 +0100
+++ b/tools/libxl/libxl_pci.c	Fri Jan 20 14:40:32 2012 +0100
@@ -721,6 +721,13 @@ out:
              LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, 
"xc_assign_device failed");
              return ERROR_FAIL;
          }
+        if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+            rc = xc_domain_bind_pt_bdf(ctx->xch, domid, 0, 
pcidev->vdevfn, pcidev->domain, pcidev_encode_bdf(pcidev));
+            if ( rc ) {
+                LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, 
"xc_domain_bind_pt_bdf failed");
+                return ERROR_FAIL;
+            }
+        }
      }

      if (!starting)
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:54:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15: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 1RoGn1-0006iN-Jv; Fri, 20 Jan 2012 15:54:07 +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 1RoGmz-0006gq-UQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:54:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327074838!9948971!1
X-Originating-IP: [213.199.154.139]
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 5673 invoked from network); 20 Jan 2012 15:53:58 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:53:58 -0000
Received: from mail101-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; Fri, 20 Jan 2012 15:53:55 +0000
Received: from mail101-db3 (localhost [127.0.0.1])	by
	mail101-db3-R.bigfish.com (Postfix) with ESMTP id ADCE432045E	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:55 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail101-db3 (localhost.localdomain [127.0.0.1]) by mail101-db3
	(MessageSwitch) id 1327074835421299_15801;
	Fri, 20 Jan 2012 15:53:55 +0000 (UTC)
Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.246])	by
	mail101-db3.bigfish.com (Postfix) with ESMTP id 567F0200057	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:55 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:53:53 +0000
X-WSS-ID: 0LY3THU-01-G8C-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 29BCD1028088	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09: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, 20 Jan 2012 09:54:12 -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, 20 Jan 2012 09: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, 20 Jan 2012
	10:52:09 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E8C3949C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:07 +0000 (GMT)
Message-ID: <4F198E66.8020405@amd.com>
Date: Fri, 20 Jan 2012 16:55:18 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <978e61814be49ec54415.1327074281@gran.amd.com>
In-Reply-To: <978e61814be49ec54415.1327074281@gran.amd.com>
X-Forwarded-Message-Id: <978e61814be49ec54415.1327074281@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 1 of 7 V4] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1327066811 -3600
# Node ID 978e61814be49ec544151803be3e3b2717551316
# Parent  3d58058fc7a2ebda9c2add654c917b9f2c1b12e6
amd iommu: Add 2 hypercalls for libxc

iommu_set_msi: used by qemu to inform hypervisor iommu vector number in
guest space. Hypervisor needs this vector to inject msi into guest after
write PPR log entry into guest buffer.

iommu_bind_bdf: used by xl to bind virtual bdf of passthru device to 
machine bdf. IOMMU emulator receives iommu cmd from guest OS and then 
forwards them to host iommu. But virtual device id in cmds from guest 
should be converted into physical id before sending them to real hardware.

Signed -off-by: Wei Wang <wei.wang2@amd.com>

diff -r 3d58058fc7a2 -r 978e61814be4 
xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 10:26:57 2012 
+0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:11 2012 
+0100
@@ -48,14 +48,31 @@
          (reg)->hi = (val) >> 32; \
      } while (0)

-static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
+static unsigned int machine_bdf(struct domain *d, uint16_t guest_seg,
+                                uint16_t guest_bdf)
  {
-    return guest_bdf;
+    struct pci_dev *pdev;
+    uint16_t mbdf = 0;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->gbdf == guest_bdf) && (pdev->gseg == guest_seg) )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
  }

-static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_seg,
+                          uint16_t machine_bdf)
  {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, machine_seg, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
  }

  static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -207,7 +224,7 @@ void guest_iommu_add_ppr_log(struct doma
      log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));

      /* Convert physical device id back into virtual device id */
-    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    gdev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
      iommu_set_devid_to_cmd(&entry[0], gdev_id);

      memcpy(log, entry, sizeof(ppr_entry_t));
@@ -256,7 +273,7 @@ void guest_iommu_add_event_log(struct do
      log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));

      /* re-write physical device id into virtual device id */
-    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    dev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
      iommu_set_devid_to_cmd(&entry[0], dev_id);
      memcpy(log, entry, sizeof(event_entry_t));

@@ -278,7 +295,7 @@ static int do_complete_ppr_request(struc
      uint16_t dev_id;
      struct amd_iommu *iommu;

-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
      iommu = find_iommu_for_device(0, dev_id);

      if ( !iommu )
@@ -330,7 +347,7 @@ static int do_invalidate_iotlb_pages(str
      struct amd_iommu *iommu;
      uint16_t dev_id;

-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));

      iommu = find_iommu_for_device(0, dev_id);
      if ( !iommu )
@@ -409,7 +426,7 @@ static int do_invalidate_dte(struct doma

      g_iommu = domain_iommu(d);
      gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
-    mbdf = machine_bdf(d, gbdf);
+    mbdf = machine_bdf(d, 0, gbdf);

      /* Guest can only update DTEs for its passthru devices */
      if ( mbdf == 0 || gbdf == 0 )
@@ -919,3 +936,45 @@ const struct hvm_mmio_handler iommu_mmio
      .read_handler = guest_iommu_mmio_read,
      .write_handler = guest_iommu_mmio_write
  };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
+                   uint16_t mseg, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() )
+        return 0;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) ||
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gseg = gseg;
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode,
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu_found() )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r 3d58058fc7a2 -r 978e61814be4 xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Fri Jan 20 10:26:57 2012 +0000
+++ b/xen/drivers/passthrough/iommu.c	Fri Jan 20 14:40:11 2012 +0100
@@ -648,6 +648,40 @@ int iommu_do_domctl(
          put_domain(d);
          break;

+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() 
failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector,
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode,
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
+                                     guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_seg,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+
      default:
          ret = -ENOSYS;
          break;
diff -r 3d58058fc7a2 -r 978e61814be4 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Fri Jan 20 10:26:57 2012 +0000
+++ b/xen/include/public/domctl.h	Fri Jan 20 14:40:11 2012 +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);

+/* Support for guest iommu emulation */
+struct xen_domctl_guest_iommu_op {
+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
+    uint8_t op;
+    union {
+        struct iommu_msi {
+        uint8_t  vector;
+        uint8_t  dest;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind {
+            uint16_t            g_seg;
+            uint16_t            g_bdf;
+            uint16_t            m_seg;
+            uint16_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+
  struct xen_domctl {
      uint32_t cmd;
  #define XEN_DOMCTL_createdomain                   1
@@ -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
@@ -960,6 +986,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 3d58058fc7a2 -r 978e61814be4 xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Fri Jan 20 10:26:57 2012 +0000
+++ b/xen/include/xen/iommu.h	Fri Jan 20 14:40:11 2012 +0100
@@ -164,6 +164,12 @@ int iommu_do_domctl(struct xen_domctl *,
  void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned 
int page_count);
  void iommu_iotlb_flush_all(struct domain *d);

+/* Only used by AMD IOMMU so far */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode,
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
+                   uint16_t mseg, uint16_t mbdf);
  /*
   * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
   * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r 3d58058fc7a2 -r 978e61814be4 xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Fri Jan 20 10:26:57 2012 +0000
+++ b/xen/include/xen/pci.h	Fri Jan 20 14:40:11 2012 +0100
@@ -58,6 +58,11 @@ struct pci_dev {
      const u16 seg;
      const u8 bus;
      const u8 devfn;
+
+    /* Used by iommu to represent virtual seg and bdf value in guest 
space */
+    u16 gseg;
+    u16 gbdf;
+
      struct pci_dev_info info;
      struct arch_pci_dev arch;
      u64 vf_rlen[6];
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:54:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15: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 1RoGn1-0006iN-Jv; Fri, 20 Jan 2012 15:54:07 +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 1RoGmz-0006gq-UQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:54:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327074838!9948971!1
X-Originating-IP: [213.199.154.139]
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 5673 invoked from network); 20 Jan 2012 15:53:58 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:53:58 -0000
Received: from mail101-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; Fri, 20 Jan 2012 15:53:55 +0000
Received: from mail101-db3 (localhost [127.0.0.1])	by
	mail101-db3-R.bigfish.com (Postfix) with ESMTP id ADCE432045E	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:55 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail101-db3 (localhost.localdomain [127.0.0.1]) by mail101-db3
	(MessageSwitch) id 1327074835421299_15801;
	Fri, 20 Jan 2012 15:53:55 +0000 (UTC)
Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.246])	by
	mail101-db3.bigfish.com (Postfix) with ESMTP id 567F0200057	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:55 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:53:53 +0000
X-WSS-ID: 0LY3THU-01-G8C-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 29BCD1028088	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09: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, 20 Jan 2012 09:54:12 -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, 20 Jan 2012 09: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, 20 Jan 2012
	10:52:09 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id E8C3949C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:07 +0000 (GMT)
Message-ID: <4F198E66.8020405@amd.com>
Date: Fri, 20 Jan 2012 16:55:18 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <978e61814be49ec54415.1327074281@gran.amd.com>
In-Reply-To: <978e61814be49ec54415.1327074281@gran.amd.com>
X-Forwarded-Message-Id: <978e61814be49ec54415.1327074281@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 1 of 7 V4] amd iommu: Add 2 hypercalls for libxc
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Wei Wang <wei.wang2@amd.com>
# Date 1327066811 -3600
# Node ID 978e61814be49ec544151803be3e3b2717551316
# Parent  3d58058fc7a2ebda9c2add654c917b9f2c1b12e6
amd iommu: Add 2 hypercalls for libxc

iommu_set_msi: used by qemu to inform hypervisor iommu vector number in
guest space. Hypervisor needs this vector to inject msi into guest after
write PPR log entry into guest buffer.

iommu_bind_bdf: used by xl to bind virtual bdf of passthru device to 
machine bdf. IOMMU emulator receives iommu cmd from guest OS and then 
forwards them to host iommu. But virtual device id in cmds from guest 
should be converted into physical id before sending them to real hardware.

Signed -off-by: Wei Wang <wei.wang2@amd.com>

diff -r 3d58058fc7a2 -r 978e61814be4 
xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 10:26:57 2012 
+0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:11 2012 
+0100
@@ -48,14 +48,31 @@
          (reg)->hi = (val) >> 32; \
      } while (0)

-static unsigned int machine_bdf(struct domain *d, uint16_t guest_bdf)
+static unsigned int machine_bdf(struct domain *d, uint16_t guest_seg,
+                                uint16_t guest_bdf)
  {
-    return guest_bdf;
+    struct pci_dev *pdev;
+    uint16_t mbdf = 0;
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->gbdf == guest_bdf) && (pdev->gseg == guest_seg) )
+        {
+            mbdf = PCI_BDF2(pdev->bus, pdev->devfn);
+            break;
+        }
+    }
+    return mbdf;
  }

-static uint16_t guest_bdf(struct domain *d, uint16_t machine_bdf)
+static uint16_t guest_bdf(struct domain *d, uint16_t machine_seg,
+                          uint16_t machine_bdf)
  {
-    return machine_bdf;
+    struct pci_dev *pdev;
+
+    pdev = pci_get_pdev_by_domain(d, machine_seg, PCI_BUS(machine_bdf),
+                                  PCI_DEVFN2(machine_bdf));
+    return pdev->gbdf;
  }

  static inline struct guest_iommu *domain_iommu(struct domain *d)
@@ -207,7 +224,7 @@ void guest_iommu_add_ppr_log(struct doma
      log = log_base + tail % (PAGE_SIZE / sizeof(ppr_entry_t));

      /* Convert physical device id back into virtual device id */
-    gdev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    gdev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
      iommu_set_devid_to_cmd(&entry[0], gdev_id);

      memcpy(log, entry, sizeof(ppr_entry_t));
@@ -256,7 +273,7 @@ void guest_iommu_add_event_log(struct do
      log = log_base + tail % (PAGE_SIZE / sizeof(event_entry_t));

      /* re-write physical device id into virtual device id */
-    dev_id = guest_bdf(d, iommu_get_devid_from_cmd(entry[0]));
+    dev_id = guest_bdf(d, 0, iommu_get_devid_from_cmd(entry[0]));
      iommu_set_devid_to_cmd(&entry[0], dev_id);
      memcpy(log, entry, sizeof(event_entry_t));

@@ -278,7 +295,7 @@ static int do_complete_ppr_request(struc
      uint16_t dev_id;
      struct amd_iommu *iommu;

-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));
      iommu = find_iommu_for_device(0, dev_id);

      if ( !iommu )
@@ -330,7 +347,7 @@ static int do_invalidate_iotlb_pages(str
      struct amd_iommu *iommu;
      uint16_t dev_id;

-    dev_id = machine_bdf(d, iommu_get_devid_from_cmd(cmd->data[0]));
+    dev_id = machine_bdf(d, 0, iommu_get_devid_from_cmd(cmd->data[0]));

      iommu = find_iommu_for_device(0, dev_id);
      if ( !iommu )
@@ -409,7 +426,7 @@ static int do_invalidate_dte(struct doma

      g_iommu = domain_iommu(d);
      gbdf = iommu_get_devid_from_cmd(cmd->data[0]);
-    mbdf = machine_bdf(d, gbdf);
+    mbdf = machine_bdf(d, 0, gbdf);

      /* Guest can only update DTEs for its passthru devices */
      if ( mbdf == 0 || gbdf == 0 )
@@ -919,3 +936,45 @@ const struct hvm_mmio_handler iommu_mmio
      .read_handler = guest_iommu_mmio_read,
      .write_handler = guest_iommu_mmio_write
  };
+
+/* iommu hypercall handler */
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
+                   uint16_t mseg, uint16_t mbdf)
+{
+    struct pci_dev *pdev;
+    int ret = -ENODEV;
+
+    if ( !iommu_found() )
+        return 0;
+
+    spin_lock(&pcidevs_lock);
+
+    for_each_pdev( d, pdev )
+    {
+        if ( (pdev->seg != mseg) || (pdev->bus != PCI_BUS(mbdf) ) ||
+             (pdev->devfn != PCI_DEVFN2(mbdf)) )
+            continue;
+
+        pdev->gseg = gseg;
+        pdev->gbdf = gbdf;
+        ret = 0;
+    }
+
+    spin_unlock(&pcidevs_lock);
+    return ret;
+}
+
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode,
+                   uint16_t trig_mode)
+{
+    struct guest_iommu *iommu = domain_iommu(d);
+
+    if ( !iommu_found() )
+        return;
+
+    iommu->msi.vector = vector;
+    iommu->msi.dest = dest;
+    iommu->msi.dest_mode = dest_mode;
+    iommu->msi.trig_mode = trig_mode;
+}
diff -r 3d58058fc7a2 -r 978e61814be4 xen/drivers/passthrough/iommu.c
--- a/xen/drivers/passthrough/iommu.c	Fri Jan 20 10:26:57 2012 +0000
+++ b/xen/drivers/passthrough/iommu.c	Fri Jan 20 14:40:11 2012 +0100
@@ -648,6 +648,40 @@ int iommu_do_domctl(
          put_domain(d);
          break;

+    case XEN_DOMCTL_guest_iommu_op:
+    {
+        xen_domctl_guest_iommu_op_t * guest_op;
+
+        if ( unlikely((d = get_domain_by_id(domctl->domain)) == NULL) )
+        {
+            gdprintk(XENLOG_ERR,
+                    "XEN_DOMCTL_guest_iommu_op: get_domain_by_id() 
failed\n");
+            ret = -EINVAL;
+            break;
+        }
+
+        guest_op = &(domctl->u.guest_iommu_op);
+        switch ( guest_op->op )
+        {
+            case XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI:
+                iommu_set_msi(d, guest_op->u.msi.vector,
+                              guest_op->u.msi.dest,
+                              guest_op->u.msi.dest_mode,
+                              guest_op->u.msi.delivery_mode,
+                              guest_op->u.msi.trig_mode);
+                ret = 0;
+                break;
+            case XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF:
+                ret = iommu_bind_bdf(d, guest_op->u.bdf_bind.g_seg,
+                                     guest_op->u.bdf_bind.g_bdf,
+                                     guest_op->u.bdf_bind.m_seg,
+                                     guest_op->u.bdf_bind.m_bdf);
+                break;
+        }
+        put_domain(d);
+        break;
+    }
+
      default:
          ret = -ENOSYS;
          break;
diff -r 3d58058fc7a2 -r 978e61814be4 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h	Fri Jan 20 10:26:57 2012 +0000
+++ b/xen/include/public/domctl.h	Fri Jan 20 14:40:11 2012 +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);

+/* Support for guest iommu emulation */
+struct xen_domctl_guest_iommu_op {
+    /* XEN_DOMCTL_GUEST_IOMMU_OP_* */
+#define XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI               0
+#define XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF              1
+    uint8_t op;
+    union {
+        struct iommu_msi {
+        uint8_t  vector;
+        uint8_t  dest;
+        uint8_t  dest_mode;
+        uint8_t  delivery_mode;
+        uint8_t  trig_mode;
+        } msi;
+        struct bdf_bind {
+            uint16_t            g_seg;
+            uint16_t            g_bdf;
+            uint16_t            m_seg;
+            uint16_t            m_bdf;
+        } bdf_bind;
+    } u;
+};
+typedef struct xen_domctl_guest_iommu_op xen_domctl_guest_iommu_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_guest_iommu_op_t);
+
  struct xen_domctl {
      uint32_t cmd;
  #define XEN_DOMCTL_createdomain                   1
@@ -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
@@ -960,6 +986,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 3d58058fc7a2 -r 978e61814be4 xen/include/xen/iommu.h
--- a/xen/include/xen/iommu.h	Fri Jan 20 10:26:57 2012 +0000
+++ b/xen/include/xen/iommu.h	Fri Jan 20 14:40:11 2012 +0100
@@ -164,6 +164,12 @@ int iommu_do_domctl(struct xen_domctl *,
  void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned 
int page_count);
  void iommu_iotlb_flush_all(struct domain *d);

+/* Only used by AMD IOMMU so far */
+void iommu_set_msi(struct domain* d, uint16_t vector, uint16_t dest,
+                   uint16_t dest_mode, uint16_t delivery_mode,
+                   uint16_t trig_mode);
+int iommu_bind_bdf(struct domain* d, uint16_t gseg, uint16_t gbdf,
+                   uint16_t mseg, uint16_t mbdf);
  /*
   * The purpose of the iommu_dont_flush_iotlb optional cpu flag is to
   * avoid unecessary iotlb_flush in the low level IOMMU code.
diff -r 3d58058fc7a2 -r 978e61814be4 xen/include/xen/pci.h
--- a/xen/include/xen/pci.h	Fri Jan 20 10:26:57 2012 +0000
+++ b/xen/include/xen/pci.h	Fri Jan 20 14:40:11 2012 +0100
@@ -58,6 +58,11 @@ struct pci_dev {
      const u16 seg;
      const u8 bus;
      const u8 devfn;
+
+    /* Used by iommu to represent virtual seg and bdf value in guest 
space */
+    u16 gseg;
+    u16 gbdf;
+
      struct pci_dev_info info;
      struct arch_pci_dev arch;
      u64 vf_rlen[6];
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:54:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGnY-0006p6-2n; Fri, 20 Jan 2012 15:54:40 +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 1RoGnX-0006nz-3x
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:54:39 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327074872!11880008!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 16962 invoked from network); 20 Jan 2012 15:54:32 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:54:32 -0000
Received: from mail12-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, 20 Jan 2012 15:54:29 +0000
Received: from mail12-db3 (localhost [127.0.0.1])	by mail12-db3-R.bigfish.com
	(Postfix) with ESMTP id 3749D6C0652	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 15:54:30 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail12-db3 (localhost.localdomain [127.0.0.1]) by mail12-db3
	(MessageSwitch) id 1327074869962058_25439;
	Fri, 20 Jan 2012 15:54:29 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.246])	by
	mail12-db3.bigfish.com (Postfix) with ESMTP id DB2B034004D	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:54:29 +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, 20 Jan 2012 15:54:27 +0000
X-WSS-ID: 0LY3TIR-02-G47-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 25CE6C80B9	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:54:26 -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, 20 Jan 2012 09:54:46 -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, 20 Jan 2012 09:54:27 -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, 20 Jan 2012
	10:53:04 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 886F649C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:02 +0000 (GMT)
Message-ID: <4F198E9C.3080403@amd.com>
Date: Fri, 20 Jan 2012 16:56:12 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <17fdd00a4f66479bf232.1327074284@gran.amd.com>
In-Reply-To: <17fdd00a4f66479bf232.1327074284@gran.amd.com>
X-Forwarded-Message-Id: <17fdd00a4f66479bf232.1327074284@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 4 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066826 -3600
# Node ID 17fdd00a4f66479bf232ac698b962118ce3f2950
# Parent  c5cd29b41f2526bb4f93c76ceade924feac1f1c3
hvmloader: Build IVRS table.
Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r c5cd29b41f25 -r 17fdd00a4f66 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Jan 20 14:40:23 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Jan 20 14:40:26 2012 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
  #define ACPI_2_0_WAET_REVISION 0x01
  #define ACPI_1_0_FADT_REVISION 0x01

+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
  #pragma pack ()

  struct acpi_config {
diff -r c5cd29b41f25 -r 17fdd00a4f66 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Jan 20 14:40:23 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Jan 20 14:40:26 2012 +0100
@@ -23,6 +23,8 @@
  #include "ssdt_pm.h"
  #include "../config.h"
  #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>

  #define align16(sz)        (((sz) + 15) & ~15)
  #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,87 @@ static struct acpi_20_waet *construct_wa
      return waet;
  }

+extern uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+extern uint32_t ptdev_nr;
+extern uint32_t iommu_bdf;
+static struct acpi_40_ivrs* construct_ivrs(void)
+{
+    struct acpi_40_ivrs *ivrs;
+    uint64_t mmio;
+    struct ivrs_ivhd_block *ivhd;
+    struct ivrs_ivhd_device *dev_entry;
+    struct xen_hvm_param p;
+
+    if (ptdev_nr == 0) return NULL;
+
+    ivrs = mem_alloc(sizeof(*ivrs), 16);
+    if (!ivrs)
+    {
+        printf("unable to build IVRS tables: out of memory\n");
+        return NULL;
+    }
+    memset(ivrs, 0, sizeof(*ivrs));
+
+    /* initialize acpi header */
+    ivrs->header.signature = IVRS_SIGNATURE;
+    ivrs->header.revision = IVRS_REVISION;
+    fixed_strcpy(ivrs->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(ivrs->header.oem_table_id, ACPI_OEM_TABLE_ID);
+
+    ivrs->header.oem_revision = ACPI_OEM_REVISION;
+    ivrs->header.creator_id   = ACPI_CREATOR_ID;
+    ivrs->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    ivrs->header.length = sizeof(*ivrs);
+
+    /* initialize IVHD Block */
+    ivhd = &ivrs->ivhd_block;
+    ivrs->iv_info = (IVRS_VASIZE << 15) | (IVRS_PASIZE << 8) |
+                    (IVRS_GVASIZE << 5);
+
+    ivhd->type          = IVHD_BLOCK_TYPE;
+    ivhd->flags         = IVHD_FLAG_PPRSUP | IVHD_FLAG_IOTLBSUP;
+    ivhd->devid         = iommu_bdf;
+    ivhd->cap_offset    = IOMMU_CAP_OFFSET;
+
+    /*reserve 32K IOMMU MMIO space */
+    mmio = virt_to_phys(mem_alloc(0x8000, 0x1000));
+    if (!mmio)
+    {
+        printf("unable to reserve iommu mmio pages: out of memory\n");
+        return NULL;
+    }
+
+    p.domid = DOMID_SELF;
+    p.index = HVM_PARAM_IOMMU_BASE;
+    p.value = mmio;
+
+    /* Return non-zero if IOMMUv2 hardware is not avaliable */
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) )
+    {
+        printf("unable to set iommu mmio base address\n");
+        return NULL;
+    }
+
+    ivhd->iommu_base_addr = mmio;
+    ivhd->reserved = IVHD_EFR_IASUP | IVHD_EFR_GTSUP;
+
+    /* Build IVHD device entries */
+    dev_entry = ivrs->ivhd_device;
+    for ( int i = 0; i < ptdev_nr; i++ )
+    {
+        dev_entry[i].type   = IVHD_SELECT_4_BYTE;
+        dev_entry[i].dev_id = ptdev_bdf[i];
+        dev_entry[i].flags  = 0;
+    }
+
+    ivhd->length = sizeof(*ivhd) + sizeof(*dev_entry) * PT_DEV_MAX_NR;
+    set_checksum(ivrs, offsetof(struct acpi_header, checksum),
+                 ivrs->header.length);
+
+    return ivrs;
+}
+
  static int construct_secondary_tables(unsigned long *table_ptrs,
                                        struct acpi_info *info)
  {
@@ -206,6 +289,7 @@ static int construct_secondary_tables(un
      struct acpi_20_hpet *hpet;
      struct acpi_20_waet *waet;
      struct acpi_20_tcpa *tcpa;
+    struct acpi_40_ivrs *ivrs;
      unsigned char *ssdt;
      static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
      uint16_t *tis_hdr;
@@ -293,6 +377,13 @@ static int construct_secondary_tables(un
          }
      }

+    if ( !strncmp(xenstore_read("guest_iommu", "1"), "1", 1) )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
      table_ptrs[nr_tables] = 0;
      return nr_tables;
  }
diff -r c5cd29b41f25 -r 17fdd00a4f66 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Fri Jan 20 14:40:23 2012 +0100
+++ b/tools/firmware/hvmloader/pci.c	Fri Jan 20 14:40:26 2012 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
  enum virtual_vga virtual_vga = VGA_none;
  unsigned long igd_opregion_pgbase = 0;

+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf;
+
  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:
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:54:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:54:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGnY-0006p6-2n; Fri, 20 Jan 2012 15:54:40 +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 1RoGnX-0006nz-3x
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:54:39 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327074872!11880008!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 16962 invoked from network); 20 Jan 2012 15:54:32 -0000
Received: from db3ehsobe002.messaging.microsoft.com (HELO
	DB3EHSOBE002.bigfish.com) (213.199.154.140)
	by server-4.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:54:32 -0000
Received: from mail12-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, 20 Jan 2012 15:54:29 +0000
Received: from mail12-db3 (localhost [127.0.0.1])	by mail12-db3-R.bigfish.com
	(Postfix) with ESMTP id 3749D6C0652	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 15:54:30 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail12-db3 (localhost.localdomain [127.0.0.1]) by mail12-db3
	(MessageSwitch) id 1327074869962058_25439;
	Fri, 20 Jan 2012 15:54:29 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.246])	by
	mail12-db3.bigfish.com (Postfix) with ESMTP id DB2B034004D	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:54:29 +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, 20 Jan 2012 15:54:27 +0000
X-WSS-ID: 0LY3TIR-02-G47-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 25CE6C80B9	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:54:26 -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, 20 Jan 2012 09:54:46 -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, 20 Jan 2012 09:54:27 -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, 20 Jan 2012
	10:53:04 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 886F649C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:02 +0000 (GMT)
Message-ID: <4F198E9C.3080403@amd.com>
Date: Fri, 20 Jan 2012 16:56:12 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <17fdd00a4f66479bf232.1327074284@gran.amd.com>
In-Reply-To: <17fdd00a4f66479bf232.1327074284@gran.amd.com>
X-Forwarded-Message-Id: <17fdd00a4f66479bf232.1327074284@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 4 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066826 -3600
# Node ID 17fdd00a4f66479bf232ac698b962118ce3f2950
# Parent  c5cd29b41f2526bb4f93c76ceade924feac1f1c3
hvmloader: Build IVRS table.
Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r c5cd29b41f25 -r 17fdd00a4f66 tools/firmware/hvmloader/acpi/acpi2_0.h
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Jan 20 14:40:23 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h	Fri Jan 20 14:40:26 2012 +0100
@@ -389,6 +389,60 @@ struct acpi_20_madt_intsrcovr {
  #define ACPI_2_0_WAET_REVISION 0x01
  #define ACPI_1_0_FADT_REVISION 0x01

+#define IVRS_SIGNATURE ASCII32('I','V','R','S')
+#define IVRS_REVISION           1
+#define IVRS_VASIZE             64
+#define IVRS_PASIZE             52
+#define IVRS_GVASIZE            64
+
+#define IVHD_BLOCK_TYPE         0x10
+#define IVHD_FLAG_HTTUNEN       (1 << 0)
+#define IVHD_FLAG_PASSPW        (1 << 1)
+#define IVHD_FLAG_RESPASSPW     (1 << 2)
+#define IVHD_FLAG_ISOC          (1 << 3)
+#define IVHD_FLAG_IOTLBSUP      (1 << 4)
+#define IVHD_FLAG_COHERENT      (1 << 5)
+#define IVHD_FLAG_PREFSUP       (1 << 6)
+#define IVHD_FLAG_PPRSUP        (1 << 7)
+
+#define IVHD_EFR_GTSUP          (1 << 2)
+#define IVHD_EFR_IASUP          (1 << 5)
+
+#define IVHD_SELECT_4_BYTE      0x2
+
+struct ivrs_ivhd_block
+{
+    uint8_t    type;
+    uint8_t    flags;
+    uint16_t   length;
+    uint16_t   devid;
+    uint16_t   cap_offset;
+    uint64_t   iommu_base_addr;
+    uint16_t   pci_segment;
+    uint16_t   iommu_info;
+    uint32_t   reserved;
+};
+
+/* IVHD 4-byte device entries */
+struct ivrs_ivhd_device
+{
+   uint8_t  type;
+   uint16_t dev_id;
+   uint8_t  flags;
+};
+
+#define PT_DEV_MAX_NR           32
+#define IOMMU_CAP_OFFSET        0x40
+struct acpi_40_ivrs
+{
+    struct acpi_header                      header;
+    uint32_t                                iv_info;
+    uint32_t                                reserved[2];
+    struct ivrs_ivhd_block                  ivhd_block;
+    struct ivrs_ivhd_device                 ivhd_device[PT_DEV_MAX_NR];
+};
+
+
  #pragma pack ()

  struct acpi_config {
diff -r c5cd29b41f25 -r 17fdd00a4f66 tools/firmware/hvmloader/acpi/build.c
--- a/tools/firmware/hvmloader/acpi/build.c	Fri Jan 20 14:40:23 2012 +0100
+++ b/tools/firmware/hvmloader/acpi/build.c	Fri Jan 20 14:40:26 2012 +0100
@@ -23,6 +23,8 @@
  #include "ssdt_pm.h"
  #include "../config.h"
  #include "../util.h"
+#include "../hypercall.h"
+#include <xen/hvm/params.h>

  #define align16(sz)        (((sz) + 15) & ~15)
  #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
@@ -198,6 +200,87 @@ static struct acpi_20_waet *construct_wa
      return waet;
  }

+extern uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+extern uint32_t ptdev_nr;
+extern uint32_t iommu_bdf;
+static struct acpi_40_ivrs* construct_ivrs(void)
+{
+    struct acpi_40_ivrs *ivrs;
+    uint64_t mmio;
+    struct ivrs_ivhd_block *ivhd;
+    struct ivrs_ivhd_device *dev_entry;
+    struct xen_hvm_param p;
+
+    if (ptdev_nr == 0) return NULL;
+
+    ivrs = mem_alloc(sizeof(*ivrs), 16);
+    if (!ivrs)
+    {
+        printf("unable to build IVRS tables: out of memory\n");
+        return NULL;
+    }
+    memset(ivrs, 0, sizeof(*ivrs));
+
+    /* initialize acpi header */
+    ivrs->header.signature = IVRS_SIGNATURE;
+    ivrs->header.revision = IVRS_REVISION;
+    fixed_strcpy(ivrs->header.oem_id, ACPI_OEM_ID);
+    fixed_strcpy(ivrs->header.oem_table_id, ACPI_OEM_TABLE_ID);
+
+    ivrs->header.oem_revision = ACPI_OEM_REVISION;
+    ivrs->header.creator_id   = ACPI_CREATOR_ID;
+    ivrs->header.creator_revision = ACPI_CREATOR_REVISION;
+
+    ivrs->header.length = sizeof(*ivrs);
+
+    /* initialize IVHD Block */
+    ivhd = &ivrs->ivhd_block;
+    ivrs->iv_info = (IVRS_VASIZE << 15) | (IVRS_PASIZE << 8) |
+                    (IVRS_GVASIZE << 5);
+
+    ivhd->type          = IVHD_BLOCK_TYPE;
+    ivhd->flags         = IVHD_FLAG_PPRSUP | IVHD_FLAG_IOTLBSUP;
+    ivhd->devid         = iommu_bdf;
+    ivhd->cap_offset    = IOMMU_CAP_OFFSET;
+
+    /*reserve 32K IOMMU MMIO space */
+    mmio = virt_to_phys(mem_alloc(0x8000, 0x1000));
+    if (!mmio)
+    {
+        printf("unable to reserve iommu mmio pages: out of memory\n");
+        return NULL;
+    }
+
+    p.domid = DOMID_SELF;
+    p.index = HVM_PARAM_IOMMU_BASE;
+    p.value = mmio;
+
+    /* Return non-zero if IOMMUv2 hardware is not avaliable */
+    if ( hypercall_hvm_op(HVMOP_set_param, &p) )
+    {
+        printf("unable to set iommu mmio base address\n");
+        return NULL;
+    }
+
+    ivhd->iommu_base_addr = mmio;
+    ivhd->reserved = IVHD_EFR_IASUP | IVHD_EFR_GTSUP;
+
+    /* Build IVHD device entries */
+    dev_entry = ivrs->ivhd_device;
+    for ( int i = 0; i < ptdev_nr; i++ )
+    {
+        dev_entry[i].type   = IVHD_SELECT_4_BYTE;
+        dev_entry[i].dev_id = ptdev_bdf[i];
+        dev_entry[i].flags  = 0;
+    }
+
+    ivhd->length = sizeof(*ivhd) + sizeof(*dev_entry) * PT_DEV_MAX_NR;
+    set_checksum(ivrs, offsetof(struct acpi_header, checksum),
+                 ivrs->header.length);
+
+    return ivrs;
+}
+
  static int construct_secondary_tables(unsigned long *table_ptrs,
                                        struct acpi_info *info)
  {
@@ -206,6 +289,7 @@ static int construct_secondary_tables(un
      struct acpi_20_hpet *hpet;
      struct acpi_20_waet *waet;
      struct acpi_20_tcpa *tcpa;
+    struct acpi_40_ivrs *ivrs;
      unsigned char *ssdt;
      static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
      uint16_t *tis_hdr;
@@ -293,6 +377,13 @@ static int construct_secondary_tables(un
          }
      }

+    if ( !strncmp(xenstore_read("guest_iommu", "1"), "1", 1) )
+    {
+        ivrs = construct_ivrs();
+        if ( ivrs != NULL )
+            table_ptrs[nr_tables++] = (unsigned long)ivrs;
+    }
+
      table_ptrs[nr_tables] = 0;
      return nr_tables;
  }
diff -r c5cd29b41f25 -r 17fdd00a4f66 tools/firmware/hvmloader/pci.c
--- a/tools/firmware/hvmloader/pci.c	Fri Jan 20 14:40:23 2012 +0100
+++ b/tools/firmware/hvmloader/pci.c	Fri Jan 20 14:40:26 2012 +0100
@@ -34,11 +34,17 @@ unsigned long pci_mem_end = PCI_MEM_END;
  enum virtual_vga virtual_vga = VGA_none;
  unsigned long igd_opregion_pgbase = 0;

+/* support up to 32 passthrough devices */
+#define PT_DEV_MAX_NR           32
+uint32_t ptdev_bdf[PT_DEV_MAX_NR];
+uint32_t ptdev_nr;
+uint32_t iommu_bdf;
+
  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:
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:55:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGoC-0006yu-2m; Fri, 20 Jan 2012 15:55: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 1RoGoB-0006xQ-IP
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:55:19 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327074912!11667166!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 28619 invoked from network); 20 Jan 2012 15:55:13 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:55:13 -0000
Received: from mail119-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, 20 Jan 2012 15:55:09 +0000
Received: from mail119-db3 (localhost [127.0.0.1])	by
	mail119-db3-R.bigfish.com (Postfix) with ESMTP id 6AAFF140547	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:55:10 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail119-db3 (localhost.localdomain [127.0.0.1]) by mail119-db3
	(MessageSwitch) id 1327074870211511_18494;
	Fri, 20 Jan 2012 15:54:30 +0000 (UTC)
Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.240])	by
	mail119-db3.bigfish.com (Postfix) with ESMTP id 2AB9F24022E	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:54:30 +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; Fri, 20 Jan 2012 15:54:28 +0000
X-WSS-ID: 0LY3TIS-01-G9X-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 2C4A71028080	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:54:27 -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, 20 Jan 2012 09:54:46 -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, 20 Jan 2012 09:54:28 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Jan 2012
	10:53:23 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 02EC249C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:21 +0000 (GMT)
Message-ID: <4F198EB0.80409@amd.com>
Date: Fri, 20 Jan 2012 16:56:32 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <423003c2a91fde16798b.1327074285@gran.amd.com>
In-Reply-To: <423003c2a91fde16798b.1327074285@gran.amd.com>
X-Forwarded-Message-Id: <423003c2a91fde16798b.1327074285@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 5 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066829 -3600
# Node ID 423003c2a91fde16798b09ff2623b03467149b49
# Parent  17fdd00a4f66479bf232ac698b962118ce3f2950
libxc: add wrappers for new hypercalls

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 17fdd00a4f66 -r 423003c2a91f tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Fri Jan 20 14:40:26 2012 +0100
+++ b/tools/libxc/xc_domain.c	Fri Jan 20 14:40:29 2012 +0100
@@ -1352,6 +1352,59 @@ int xc_domain_bind_pt_isa_irq(
                                    PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
  }

+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+    uint32_t domid,
+    uint16_t gseg,
+    uint16_t gbdf,
+    uint16_t mseg,
+    uint16_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_seg = gseg;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_seg = mseg;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
  int xc_domain_memory_mapping(
      xc_interface *xch,
      uint32_t domid,
diff -r 17fdd00a4f66 -r 423003c2a91f tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Jan 20 14:40:26 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Jan 20 14:40:29 2012 +0100
@@ -1697,6 +1697,21 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                                uint32_t domid,
                                uint8_t machine_irq);

+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint16_t gseg,
+                          uint16_t gbdf,
+                          uint16_t mseg,
+                          uint16_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
  int xc_domain_set_machine_address_size(xc_interface *xch,
  				       uint32_t domid,
  				       unsigned int width);
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:55:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGoC-0006yu-2m; Fri, 20 Jan 2012 15:55: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 1RoGoB-0006xQ-IP
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:55:19 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327074912!11667166!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 28619 invoked from network); 20 Jan 2012 15:55:13 -0000
Received: from db3ehsobe006.messaging.microsoft.com (HELO
	DB3EHSOBE006.bigfish.com) (213.199.154.144)
	by server-7.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:55:13 -0000
Received: from mail119-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, 20 Jan 2012 15:55:09 +0000
Received: from mail119-db3 (localhost [127.0.0.1])	by
	mail119-db3-R.bigfish.com (Postfix) with ESMTP id 6AAFF140547	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:55:10 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail119-db3 (localhost.localdomain [127.0.0.1]) by mail119-db3
	(MessageSwitch) id 1327074870211511_18494;
	Fri, 20 Jan 2012 15:54:30 +0000 (UTC)
Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.240])	by
	mail119-db3.bigfish.com (Postfix) with ESMTP id 2AB9F24022E	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:54:30 +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; Fri, 20 Jan 2012 15:54:28 +0000
X-WSS-ID: 0LY3TIS-01-G9X-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 2C4A71028080	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:54:27 -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, 20 Jan 2012 09:54:46 -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, 20 Jan 2012 09:54:28 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 20 Jan 2012
	10:53:23 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 02EC249C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:21 +0000 (GMT)
Message-ID: <4F198EB0.80409@amd.com>
Date: Fri, 20 Jan 2012 16:56:32 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <423003c2a91fde16798b.1327074285@gran.amd.com>
In-Reply-To: <423003c2a91fde16798b.1327074285@gran.amd.com>
X-Forwarded-Message-Id: <423003c2a91fde16798b.1327074285@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 5 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066829 -3600
# Node ID 423003c2a91fde16798b09ff2623b03467149b49
# Parent  17fdd00a4f66479bf232ac698b962118ce3f2950
libxc: add wrappers for new hypercalls

Signed-off-by: Wei Wang <wei.wang2@amd.com>

diff -r 17fdd00a4f66 -r 423003c2a91f tools/libxc/xc_domain.c
--- a/tools/libxc/xc_domain.c	Fri Jan 20 14:40:26 2012 +0100
+++ b/tools/libxc/xc_domain.c	Fri Jan 20 14:40:29 2012 +0100
@@ -1352,6 +1352,59 @@ int xc_domain_bind_pt_isa_irq(
                                    PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
  }

+int xc_domain_update_iommu_msi(
+    xc_interface *xch,
+    uint32_t domid,
+    uint8_t vector,
+    uint8_t dest,
+    uint8_t dest_mode,
+    uint8_t delivery_mode,
+    uint8_t trig_mode)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * iommu_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    iommu_op = &(domctl.u.guest_iommu_op);
+    iommu_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_SET_MSI;
+    iommu_op->u.msi.vector = vector;
+    iommu_op->u.msi.dest = dest;
+    iommu_op->u.msi.dest_mode = dest_mode;
+    iommu_op->u.msi.delivery_mode = delivery_mode;
+    iommu_op->u.msi.trig_mode = trig_mode;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
+int xc_domain_bind_pt_bdf(xc_interface *xch,
+    uint32_t domid,
+    uint16_t gseg,
+    uint16_t gbdf,
+    uint16_t mseg,
+    uint16_t mbdf)
+{
+    int rc;
+    DECLARE_DOMCTL;
+    xen_domctl_guest_iommu_op_t * guest_op;
+
+    domctl.cmd = XEN_DOMCTL_guest_iommu_op;
+    domctl.domain = (domid_t)domid;
+
+    guest_op = &(domctl.u.guest_iommu_op);
+    guest_op->op = XEN_DOMCTL_GUEST_IOMMU_OP_BIND_BDF;
+    guest_op->u.bdf_bind.g_seg = gseg;
+    guest_op->u.bdf_bind.g_bdf = gbdf;
+    guest_op->u.bdf_bind.m_seg = mseg;
+    guest_op->u.bdf_bind.m_bdf = mbdf;
+
+    rc = do_domctl(xch, &domctl);
+    return rc;
+}
+
  int xc_domain_memory_mapping(
      xc_interface *xch,
      uint32_t domid,
diff -r 17fdd00a4f66 -r 423003c2a91f tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h	Fri Jan 20 14:40:26 2012 +0100
+++ b/tools/libxc/xenctrl.h	Fri Jan 20 14:40:29 2012 +0100
@@ -1697,6 +1697,21 @@ int xc_domain_bind_pt_isa_irq(xc_interfa
                                uint32_t domid,
                                uint8_t machine_irq);

+int xc_domain_bind_pt_bdf(xc_interface *xch,
+                          uint32_t domid,
+                          uint16_t gseg,
+                          uint16_t gbdf,
+                          uint16_t mseg,
+                          uint16_t mbdf);
+
+int xc_domain_update_iommu_msi(xc_interface *xch,
+                               uint32_t domid,
+                               uint8_t vector,
+                               uint8_t dest,
+                               uint8_t dest_mode,
+                               uint8_t delivery_mode,
+                               uint8_t trig_mode);
+
  int xc_domain_set_machine_address_size(xc_interface *xch,
  				       uint32_t domid,
  				       unsigned int width);
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:55:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGoB-0006yb-Mw; Fri, 20 Jan 2012 15:55:19 +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 1RoGo9-0006wz-LX
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:55:18 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327074909!9992428!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27552 invoked from network); 20 Jan 2012 15:55:10 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	VA3EHSOBE010.bigfish.com) (216.32.180.30)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:55:10 -0000
Received: from mail118-va3-R.bigfish.com (10.7.14.238) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Fri, 20 Jan 2012 15:55:06 +0000
Received: from mail118-va3 (localhost [127.0.0.1])	by
	mail118-va3-R.bigfish.com (Postfix) with ESMTP id A68242C0159	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:55:06 +0000 (UTC)
X-SpamScore: 3
X-BigFish: VPS3(zz853kzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail118-va3 (localhost.localdomain [127.0.0.1]) by mail118-va3
	(MessageSwitch) id 1327074903499687_18215;
	Fri, 20 Jan 2012 15:55:03 +0000 (UTC)
Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.252])	by
	mail118-va3.bigfish.com (Postfix) with ESMTP id 71F7E200049	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:55:03 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:55:02 +0000
X-WSS-ID: 0LY3TJQ-02-G67-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 21AAEC80B8	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:55:02 -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, 20 Jan 2012 09:55:21 -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, 20 Jan 2012 09:55:03 -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, 20 Jan 2012
	10:54:00 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2BEAB49C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:59 +0000 (GMT)
Message-ID: <4F198ED5.6090902@amd.com>
Date: Fri, 20 Jan 2012 16:57:09 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <e71836563bfabed56c01.1327074287@gran.amd.com>
In-Reply-To: <e71836563bfabed56c01.1327074287@gran.amd.com>
X-Forwarded-Message-Id: <e71836563bfabed56c01.1327074287@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 7 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327074009 -3600
# Node ID e71836563bfabed56c0140ad0bcaab517d82c894
# Parent  a768bb39d0bc64360055e7fce0e890be71920e63
libxl: Introduce a new guest config file parameter
Use guest_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 a768bb39d0bc -r e71836563bfa docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Jan 20 14:40:32 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Fri Jan 20 16:40:09 2012 +0100
@@ -820,6 +820,10 @@ certainly belong in a more appropriate s

  Enable graphics device PCI passthrough. XXX which device is passed 
through ?

+=item B<guest_iommu=BOOLEAN>
+
+Enable virtual iommu device for hvm guest. It should be enabled to 
passthrough AMD GPGPU.
+
  =item B<nomigrate=BOOLEAN>

  Disable migration of this domain.  This enables certain other features
diff -r a768bb39d0bc -r e71836563bfa tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 20 14:40:32 2012 +0100
+++ b/tools/libxl/libxl_create.c	Fri Jan 20 16:40:09 2012 +0100
@@ -93,6 +93,7 @@ int libxl_init_build_info(libxl_ctx *ctx
          b_info->u.hvm.timer_mode = 1;
          b_info->u.hvm.nested_hvm = 0;
          b_info->u.hvm.no_incr_generationid = 0;
+        b_info->u.hvm.guest_iommu = 0;
          break;
      case LIBXL_DOMAIN_TYPE_PV:
          b_info->u.pv.slack_memkb = 8 * 1024;
@@ -183,13 +184,15 @@ int libxl__domain_build(libxl__gc *gc,
          vments[4] = "start_time";
          vments[5] = libxl__sprintf(gc, "%lu.%02d", 
start_time.tv_sec,(int)start_time.tv_usec/10000);

-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
          localents[0] = "platform/acpi";
          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
          localents[2] = "platform/acpi_s3";
          localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
          localents[4] = "platform/acpi_s4";
          localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "guest_iommu";
+        localents[7] = (info->u.hvm.guest_iommu) ? "1" : "0";

          break;
      case LIBXL_DOMAIN_TYPE_PV:
diff -r a768bb39d0bc -r e71836563bfa tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 20 14:40:32 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Fri Jan 20 16:40:09 2012 +0100
@@ -185,6 +185,7 @@ libxl_domain_build_info = Struct("domain
                                         ("timer_mode", integer),
                                         ("nested_hvm", bool),
                                         ("no_incr_generationid", bool),
+                                       ("guest_iommu", bool),
                                         ])),
                   ("pv", Struct(None, [("kernel", libxl_file_reference),
                                        ("slack_memkb", uint32),
diff -r a768bb39d0bc -r e71836563bfa tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 20 14:40:32 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jan 20 16:40:09 2012 +0100
@@ -768,6 +768,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, "guest_iommu", &l, 0))
+            b_info->u.hvm.guest_iommu = l;
          break;
      case LIBXL_DOMAIN_TYPE_PV:
      {
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 15:55:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 15:55:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGoB-0006yb-Mw; Fri, 20 Jan 2012 15:55:19 +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 1RoGo9-0006wz-LX
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 15:55:18 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327074909!9992428!1
X-Originating-IP: [216.32.180.30]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27552 invoked from network); 20 Jan 2012 15:55:10 -0000
Received: from va3ehsobe010.messaging.microsoft.com (HELO
	VA3EHSOBE010.bigfish.com) (216.32.180.30)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:55:10 -0000
Received: from mail118-va3-R.bigfish.com (10.7.14.238) by
	VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id
	14.1.225.22; Fri, 20 Jan 2012 15:55:06 +0000
Received: from mail118-va3 (localhost [127.0.0.1])	by
	mail118-va3-R.bigfish.com (Postfix) with ESMTP id A68242C0159	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:55:06 +0000 (UTC)
X-SpamScore: 3
X-BigFish: VPS3(zz853kzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail118-va3 (localhost.localdomain [127.0.0.1]) by mail118-va3
	(MessageSwitch) id 1327074903499687_18215;
	Fri, 20 Jan 2012 15:55:03 +0000 (UTC)
Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.252])	by
	mail118-va3.bigfish.com (Postfix) with ESMTP id 71F7E200049	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:55:03 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:55:02 +0000
X-WSS-ID: 0LY3TJQ-02-G67-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 21AAEC80B8	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:55:02 -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, 20 Jan 2012 09:55:21 -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, 20 Jan 2012 09:55:03 -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, 20 Jan 2012
	10:54:00 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2BEAB49C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:59 +0000 (GMT)
Message-ID: <4F198ED5.6090902@amd.com>
Date: Fri, 20 Jan 2012 16:57:09 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <e71836563bfabed56c01.1327074287@gran.amd.com>
In-Reply-To: <e71836563bfabed56c01.1327074287@gran.amd.com>
X-Forwarded-Message-Id: <e71836563bfabed56c01.1327074287@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 7 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327074009 -3600
# Node ID e71836563bfabed56c0140ad0bcaab517d82c894
# Parent  a768bb39d0bc64360055e7fce0e890be71920e63
libxl: Introduce a new guest config file parameter
Use guest_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 a768bb39d0bc -r e71836563bfa docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5	Fri Jan 20 14:40:32 2012 +0100
+++ b/docs/man/xl.cfg.pod.5	Fri Jan 20 16:40:09 2012 +0100
@@ -820,6 +820,10 @@ certainly belong in a more appropriate s

  Enable graphics device PCI passthrough. XXX which device is passed 
through ?

+=item B<guest_iommu=BOOLEAN>
+
+Enable virtual iommu device for hvm guest. It should be enabled to 
passthrough AMD GPGPU.
+
  =item B<nomigrate=BOOLEAN>

  Disable migration of this domain.  This enables certain other features
diff -r a768bb39d0bc -r e71836563bfa tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 20 14:40:32 2012 +0100
+++ b/tools/libxl/libxl_create.c	Fri Jan 20 16:40:09 2012 +0100
@@ -93,6 +93,7 @@ int libxl_init_build_info(libxl_ctx *ctx
          b_info->u.hvm.timer_mode = 1;
          b_info->u.hvm.nested_hvm = 0;
          b_info->u.hvm.no_incr_generationid = 0;
+        b_info->u.hvm.guest_iommu = 0;
          break;
      case LIBXL_DOMAIN_TYPE_PV:
          b_info->u.pv.slack_memkb = 8 * 1024;
@@ -183,13 +184,15 @@ int libxl__domain_build(libxl__gc *gc,
          vments[4] = "start_time";
          vments[5] = libxl__sprintf(gc, "%lu.%02d", 
start_time.tv_sec,(int)start_time.tv_usec/10000);

-        localents = libxl__calloc(gc, 7, sizeof(char *));
+        localents = libxl__calloc(gc, 9, sizeof(char *));
          localents[0] = "platform/acpi";
          localents[1] = (info->u.hvm.acpi) ? "1" : "0";
          localents[2] = "platform/acpi_s3";
          localents[3] = (info->u.hvm.acpi_s3) ? "1" : "0";
          localents[4] = "platform/acpi_s4";
          localents[5] = (info->u.hvm.acpi_s4) ? "1" : "0";
+        localents[6] = "guest_iommu";
+        localents[7] = (info->u.hvm.guest_iommu) ? "1" : "0";

          break;
      case LIBXL_DOMAIN_TYPE_PV:
diff -r a768bb39d0bc -r e71836563bfa tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 20 14:40:32 2012 +0100
+++ b/tools/libxl/libxl_types.idl	Fri Jan 20 16:40:09 2012 +0100
@@ -185,6 +185,7 @@ libxl_domain_build_info = Struct("domain
                                         ("timer_mode", integer),
                                         ("nested_hvm", bool),
                                         ("no_incr_generationid", bool),
+                                       ("guest_iommu", bool),
                                         ])),
                   ("pv", Struct(None, [("kernel", libxl_file_reference),
                                        ("slack_memkb", uint32),
diff -r a768bb39d0bc -r e71836563bfa tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 20 14:40:32 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Fri Jan 20 16:40:09 2012 +0100
@@ -768,6 +768,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, "guest_iommu", &l, 0))
+            b_info->u.hvm.guest_iommu = l;
          break;
      case LIBXL_DOMAIN_TYPE_PV:
      {
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:02:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGv9-00089U-2m; Fri, 20 Jan 2012 16:02:31 +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 1RoGv7-00089I-J5
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:02:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327075342!11880958!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 4479 invoked from network); 20 Jan 2012 16:02:22 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 16:02:22 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74900714; Fri, 20 Jan 2012 17:02:21 +0100
Message-ID: <1327075340.2337.50.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 17:02:20 +0100
In-Reply-To: <1327071976.30054.55.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4693658317943147933=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4693658317943147933==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-BQ8G/mcnNYlt841zXYgA"


--=-BQ8G/mcnNYlt841zXYgA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 15:06 +0000, Ian Campbell wrote:=20
> On Fri, 2012-01-20 at 13:11 +0000, Ian Campbell wrote:
>=20
> > Your patches do the affinity setting pretty early so I'm not sure what'=
s
> > going on.
>=20
> The cpu affinities are set and d->node_affinity is getting correctly
> updated to only include one node before any memory is allocated to the
> domain, yet memory appears to be being allocated on both nodes.
>=20
I'm also looking into this and NOT finding an answer... Yet. Will keep
investigating and report back as soon as I get what's happening...

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)



--=-BQ8G/mcnNYlt841zXYgA
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)

iEYEABECAAYFAk8ZkAwACgkQk4XaBE3IOsSLigCcCKUWUVn7d3VMB6wbkKaCL1lm
9/wAnipGh/uDcmcTvcvoypXzCU4h5bQr
=SF4r
-----END PGP SIGNATURE-----

--=-BQ8G/mcnNYlt841zXYgA--



--===============4693658317943147933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4693658317943147933==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:02:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:02:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoGv9-00089U-2m; Fri, 20 Jan 2012 16:02:31 +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 1RoGv7-00089I-J5
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:02:29 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327075342!11880958!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 4479 invoked from network); 20 Jan 2012 16:02:22 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 16:02:22 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74900714; Fri, 20 Jan 2012 17:02:21 +0100
Message-ID: <1327075340.2337.50.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 17:02:20 +0100
In-Reply-To: <1327071976.30054.55.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4693658317943147933=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4693658317943147933==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-BQ8G/mcnNYlt841zXYgA"


--=-BQ8G/mcnNYlt841zXYgA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 15:06 +0000, Ian Campbell wrote:=20
> On Fri, 2012-01-20 at 13:11 +0000, Ian Campbell wrote:
>=20
> > Your patches do the affinity setting pretty early so I'm not sure what'=
s
> > going on.
>=20
> The cpu affinities are set and d->node_affinity is getting correctly
> updated to only include one node before any memory is allocated to the
> domain, yet memory appears to be being allocated on both nodes.
>=20
I'm also looking into this and NOT finding an answer... Yet. Will keep
investigating and report back as soon as I get what's happening...

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)



--=-BQ8G/mcnNYlt841zXYgA
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)

iEYEABECAAYFAk8ZkAwACgkQk4XaBE3IOsSLigCcCKUWUVn7d3VMB6wbkKaCL1lm
9/wAnipGh/uDcmcTvcvoypXzCU4h5bQr
=SF4r
-----END PGP SIGNATURE-----

--=-BQ8G/mcnNYlt841zXYgA--



--===============4693658317943147933==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4693658317943147933==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:04:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoGwg-0008Eu-Jo; Fri, 20 Jan 2012 16:04:06 +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 1RoGwe-0008Ec-Vk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:04:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327075436!11739381!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDkyNjc4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22680 invoked from network); 20 Jan 2012 16:03:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 16:03:58 -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
	q0KG32TZ019951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 16:03:03 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
	q0KG30D7008485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 16:03:01 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
	q0KG2w9m010755; Fri, 20 Jan 2012 10:02:59 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 08:02:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 55ED74032A; Fri, 20 Jan 2012 11:00:50 -0500 (EST)
Date: Fri, 20 Jan 2012 11:00:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120120160050.GB3959@phenom.dumpdata.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EBA8FAA020000780005FD5F@nat28.tlf.novell.com>
	<4EBC125A.70300@goop.org> <20120119194232.GA3728@konrad-lan>
	<4F194880020000780006DD7F@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F194880020000780006DD7F@nat28.tlf.novell.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.0A090208.4F199038.0042,ss=1,re=0.000,fgs=0
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@darnok.org>, Laszlo Ersek <lersek@redhat.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 Fri, Jan 20, 2012 at 09:57:04AM +0000, Jan Beulich wrote:
> >>> On 19.01.12 at 20:42, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > I finally got some time to look at them and I think they are these ones:
> > 
> > git log --oneline 
> > e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b
> > 255a4 
> > 3c404b5 KVM guest: Add a pv_ops stub for steal time
> > c9aaa89 KVM: Steal time implementation
> > 9ddabbe KVM: KVM Steal time guest/host interface
> > 4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host 
> > interface
> > 
> > What is interesting is that they end up inserting a bunch of:
> > 
> >  
> > +       if (steal_account_process_tick())
> > +               return;
> > +
> > 
> > in irqtime_account_process_tick and in account_process_tick.
> 
> And this (particularly the "return" part of it) is what I have a hard
> time to understand: How can it be correct to not do any of the
> other accounting? After all, the function calls only
> account_steal_time(), but its certainly going to be common that
> part of the time was stolen, and part was spent executing.
> 
> Further, it's being called only from the process tick accounting

Also from 'irqtime_account_idle_ticks' which is called from
account_idle_ticks (if tsc is part of the picture) which is called
from tick_nohz_idle_exit. So at the end of the idle loop the idle
time is accounted for.

> functions, but clearly part of idle or interrupt time can also be
> stolen.

It looks as if the other interrupt times: so the CPUTIME_SOFTIRQ and
CPUTIME_IRQ are completly skipped - but only if there is a "steal time".

The 'steal time' from the KVM is based on the host scheduler notion
of 'run_delay'. I think the 'run_delay' is based purely on block I/O
delay or swap I/O delay. So if the host is not running in any of those
issues, then the 'steal_account_process_tick' won't have any values.
And the 'if (..) return;' wont be taken and it will continue to attribute
the other 'time' slots with appropiate values.

If we have CPU intensive guests that are overcommitted, the guest /proc/schedstats
won't show the delay between the host putting it on a CPU as as 'steal' time
but rather as 'idle' time - I think?

That seems odd. I am probably misreading how 'run_delay' gets computed.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:04:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoGwg-0008Eu-Jo; Fri, 20 Jan 2012 16:04:06 +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 1RoGwe-0008Ec-Vk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:04:05 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327075436!11739381!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDkyNjc4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22680 invoked from network); 20 Jan 2012 16:03:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 16:03:58 -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
	q0KG32TZ019951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 16:03:03 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
	q0KG30D7008485
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 16:03:01 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
	q0KG2w9m010755; Fri, 20 Jan 2012 10:02:59 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 08:02:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 55ED74032A; Fri, 20 Jan 2012 11:00:50 -0500 (EST)
Date: Fri, 20 Jan 2012 11:00:50 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120120160050.GB3959@phenom.dumpdata.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EBA8FAA020000780005FD5F@nat28.tlf.novell.com>
	<4EBC125A.70300@goop.org> <20120119194232.GA3728@konrad-lan>
	<4F194880020000780006DD7F@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F194880020000780006DD7F@nat28.tlf.novell.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.0A090208.4F199038.0042,ss=1,re=0.000,fgs=0
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@darnok.org>, Laszlo Ersek <lersek@redhat.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 Fri, Jan 20, 2012 at 09:57:04AM +0000, Jan Beulich wrote:
> >>> On 19.01.12 at 20:42, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > I finally got some time to look at them and I think they are these ones:
> > 
> > git log --oneline 
> > e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b
> > 255a4 
> > 3c404b5 KVM guest: Add a pv_ops stub for steal time
> > c9aaa89 KVM: Steal time implementation
> > 9ddabbe KVM: KVM Steal time guest/host interface
> > 4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host 
> > interface
> > 
> > What is interesting is that they end up inserting a bunch of:
> > 
> >  
> > +       if (steal_account_process_tick())
> > +               return;
> > +
> > 
> > in irqtime_account_process_tick and in account_process_tick.
> 
> And this (particularly the "return" part of it) is what I have a hard
> time to understand: How can it be correct to not do any of the
> other accounting? After all, the function calls only
> account_steal_time(), but its certainly going to be common that
> part of the time was stolen, and part was spent executing.
> 
> Further, it's being called only from the process tick accounting

Also from 'irqtime_account_idle_ticks' which is called from
account_idle_ticks (if tsc is part of the picture) which is called
from tick_nohz_idle_exit. So at the end of the idle loop the idle
time is accounted for.

> functions, but clearly part of idle or interrupt time can also be
> stolen.

It looks as if the other interrupt times: so the CPUTIME_SOFTIRQ and
CPUTIME_IRQ are completly skipped - but only if there is a "steal time".

The 'steal time' from the KVM is based on the host scheduler notion
of 'run_delay'. I think the 'run_delay' is based purely on block I/O
delay or swap I/O delay. So if the host is not running in any of those
issues, then the 'steal_account_process_tick' won't have any values.
And the 'if (..) return;' wont be taken and it will continue to attribute
the other 'time' slots with appropiate values.

If we have CPU intensive guests that are overcommitted, the guest /proc/schedstats
won't show the delay between the host putting it on a CPU as as 'steal' time
but rather as 'idle' time - I think?

That seems odd. I am probably misreading how 'run_delay' gets computed.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:12:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoH4O-0008WK-Py; Fri, 20 Jan 2012 16:12:04 +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 1RoH4N-0008WF-D3
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:12:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327075915!11340110!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDkyNjc4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21522 invoked from network); 20 Jan 2012 16:11:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 16:11:56 -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
	q0KGBnth031574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 16:11:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0KGBmeF005177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 16:11:49 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0KGBlAt006523; Fri, 20 Jan 2012 10:11:47 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 08:11:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D59884032A; Fri, 20 Jan 2012 11:09:38 -0500 (EST)
Date: Fri, 20 Jan 2012 11:09:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Message-ID: <20120120160938.GC3959@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
	<CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F199247.0090,ss=1,re=0.000,fgs=0
Cc: akpm@linux-foundation.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 21, 2012 at 12:41:56AM +0900, Akinobu Mita wrote:
> 2012/1/21 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> > On Sat, Jan 21, 2012 at 12:15:26AM +0900, Akinobu Mita wrote:
> >> Use bitmap_set and bitmap_clear rather than modifying individual bits
> >> in a memory region.
> >>
> >> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> >> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> Cc: xen-devel@lists.xensource.com
> >> Cc: virtualization@lists.linux-foundation.org
> >> ---
> >> =A0drivers/block/xen-blkfront.c | =A0 =A07 +++----
> >> =A01 files changed, 3 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront=
.c
> >> index 2f22874..619868d 100644
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >> @@ -43,6 +43,7 @@
> >> =A0#include <linux/slab.h>
> >> =A0#include <linux/mutex.h>
> >> =A0#include <linux/scatterlist.h>
> >> +#include <linux/bitmap.h>
> >>
> >> =A0#include <xen/xen.h>
> >> =A0#include <xen/xenbus.h>
> >> @@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor,=
 unsigned int nr)
> >>
> >> =A0 =A0 =A0 spin_lock(&minor_lock);
> >> =A0 =A0 =A0 if (find_next_bit(minors, end, minor) >=3D end) {
> >> - =A0 =A0 =A0 =A0 =A0 =A0 for (; minor < end; ++minor)
> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __set_bit(minor, minors);
> >> + =A0 =A0 =A0 =A0 =A0 =A0 bitmap_set(minors, minor, nr);
> >
> > Hm, I would have thought the last argument should have been 'end'?
> =

> 'end' is the index of the last bit to clear.  But the last argument of
> bitmap_clear() is the number of bits to clear.  So I think 'nr' is correc=
t.

Ah, I see it.
> =

> > Did you test this patch with a large amount of minors?
> =

> Sorry I didn't do runtime test.

Please do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:12:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoH4O-0008WK-Py; Fri, 20 Jan 2012 16:12:04 +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 1RoH4N-0008WF-D3
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:12:03 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327075915!11340110!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDkyNjc4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21522 invoked from network); 20 Jan 2012 16:11:56 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 16:11:56 -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
	q0KGBnth031574
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 16:11:50 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0KGBmeF005177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 16:11:49 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0KGBlAt006523; Fri, 20 Jan 2012 10:11:47 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 08:11:47 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id D59884032A; Fri, 20 Jan 2012 11:09:38 -0500 (EST)
Date: Fri, 20 Jan 2012 11:09:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Akinobu Mita <akinobu.mita@gmail.com>
Message-ID: <20120120160938.GC3959@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
	<CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F199247.0090,ss=1,re=0.000,fgs=0
Cc: akpm@linux-foundation.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org,
	Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 21, 2012 at 12:41:56AM +0900, Akinobu Mita wrote:
> 2012/1/21 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> > On Sat, Jan 21, 2012 at 12:15:26AM +0900, Akinobu Mita wrote:
> >> Use bitmap_set and bitmap_clear rather than modifying individual bits
> >> in a memory region.
> >>
> >> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> >> Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> >> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> >> Cc: xen-devel@lists.xensource.com
> >> Cc: virtualization@lists.linux-foundation.org
> >> ---
> >> =A0drivers/block/xen-blkfront.c | =A0 =A07 +++----
> >> =A01 files changed, 3 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront=
.c
> >> index 2f22874..619868d 100644
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >> @@ -43,6 +43,7 @@
> >> =A0#include <linux/slab.h>
> >> =A0#include <linux/mutex.h>
> >> =A0#include <linux/scatterlist.h>
> >> +#include <linux/bitmap.h>
> >>
> >> =A0#include <xen/xen.h>
> >> =A0#include <xen/xenbus.h>
> >> @@ -177,8 +178,7 @@ static int xlbd_reserve_minors(unsigned int minor,=
 unsigned int nr)
> >>
> >> =A0 =A0 =A0 spin_lock(&minor_lock);
> >> =A0 =A0 =A0 if (find_next_bit(minors, end, minor) >=3D end) {
> >> - =A0 =A0 =A0 =A0 =A0 =A0 for (; minor < end; ++minor)
> >> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 __set_bit(minor, minors);
> >> + =A0 =A0 =A0 =A0 =A0 =A0 bitmap_set(minors, minor, nr);
> >
> > Hm, I would have thought the last argument should have been 'end'?
> =

> 'end' is the index of the last bit to clear.  But the last argument of
> bitmap_clear() is the number of bits to clear.  So I think 'nr' is correc=
t.

Ah, I see it.
> =

> > Did you test this patch with a large amount of minors?
> =

> Sorry I didn't do runtime test.

Please do.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:13:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoH5O-00007w-93; Fri, 20 Jan 2012 16:13:06 +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 1RoH5M-00007d-Kr
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:13:04 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327075977!11726477!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 15841 invoked from network); 20 Jan 2012 16:12:58 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 16:12:58 -0000
Received: from mail19-am1-R.bigfish.com (10.3.201.247) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 16:12:54 +0000
Received: from mail19-am1 (localhost [127.0.0.1])	by mail19-am1-R.bigfish.com
	(Postfix) with ESMTP id C1CA9800C8	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 16:12:53 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail19-am1 (localhost.localdomain [127.0.0.1]) by mail19-am1
	(MessageSwitch) id 132707597131641_15268;
	Fri, 20 Jan 2012 16:12:51 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.248])	by
	mail19-am1.bigfish.com (Postfix) with ESMTP id 01DEE4C0045	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 16:12:51 +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; Fri, 20 Jan 2012 16:12:51 +0000
X-WSS-ID: 0LY3UDF-02-HNB-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 22C07C80BA	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 10:12:51 -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;
	Fri, 20 Jan 2012 10:13:10 -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;
	Fri, 20 Jan 2012 10:12:51 -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, 20 Jan 2012
	11:12:51 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D210949C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 16:12:49 +0000 (GMT)
Message-ID: <4F199340.3050603@amd.com>
Date: Fri, 20 Jan 2012 17:16:00 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
In-Reply-To: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
X-Forwarded-Message-Id: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 2 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066820 -3600
# Node ID ea3af8fa078c07d357de79931a102450b59156ea
# Parent  978e61814be49ec544151803be3e3b2717551316
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 978e61814be4 -r ea3af8fa078c 
xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:11 2012 
+0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:20 2012 
+0100
@@ -825,6 +825,9 @@ int guest_iommu_set_base(struct domain *
      if ( !iommu )
          return -EACCES;

+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
+        return 1;
+
      iommu->mmio_base = base;
      base >>= PAGE_SHIFT;

@@ -884,7 +887,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);
@@ -916,6 +919,9 @@ void guest_iommu_destroy(struct domain *
      iommu = domain_iommu(d);
      if ( !iommu )
          return;
+
+    if ( !iommuv2_enabled )
+        return;

      tasklet_kill(&iommu->cmd_buffer_tasklet);
      xfree(iommu);
@@ -944,7 +950,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);
@@ -970,7 +976,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 978e61814be4 -r ea3af8fa078c 
xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Fri Jan 20 14:40:11 2012 
+0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Jan 20 14:40:20 2012 
+0100
@@ -38,6 +38,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)
  {
@@ -799,6 +800,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);

  }
diff -r 978e61814be4 -r ea3af8fa078c xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Fri Jan 20 14:40:11 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Fri Jan 20 14:40:20 2012 +0100
@@ -182,4 +182,6 @@ struct guest_iommu {
      struct guest_iommu_msi  msi;
  };

+extern bool_t iommuv2_enabled;
+
  #endif /* _ASM_X86_64_AMD_IOMMU_H */
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:13:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:13:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoH5O-00007w-93; Fri, 20 Jan 2012 16:13:06 +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 1RoH5M-00007d-Kr
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:13:04 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327075977!11726477!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 15841 invoked from network); 20 Jan 2012 16:12:58 -0000
Received: from am1ehsobe001.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.204)
	by server-14.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 16:12:58 -0000
Received: from mail19-am1-R.bigfish.com (10.3.201.247) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 16:12:54 +0000
Received: from mail19-am1 (localhost [127.0.0.1])	by mail19-am1-R.bigfish.com
	(Postfix) with ESMTP id C1CA9800C8	for
	<xen-devel@lists.xensource.com>; Fri,
	20 Jan 2012 16:12:53 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail19-am1 (localhost.localdomain [127.0.0.1]) by mail19-am1
	(MessageSwitch) id 132707597131641_15268;
	Fri, 20 Jan 2012 16:12:51 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.248])	by
	mail19-am1.bigfish.com (Postfix) with ESMTP id 01DEE4C0045	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 16:12:51 +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; Fri, 20 Jan 2012 16:12:51 +0000
X-WSS-ID: 0LY3UDF-02-HNB-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 22C07C80BA	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 10:12:51 -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;
	Fri, 20 Jan 2012 10:13:10 -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;
	Fri, 20 Jan 2012 10:12:51 -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, 20 Jan 2012
	11:12:51 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D210949C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 16:12:49 +0000 (GMT)
Message-ID: <4F199340.3050603@amd.com>
Date: Fri, 20 Jan 2012 17:16:00 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
In-Reply-To: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
X-Forwarded-Message-Id: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH 2 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066820 -3600
# Node ID ea3af8fa078c07d357de79931a102450b59156ea
# Parent  978e61814be49ec544151803be3e3b2717551316
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 978e61814be4 -r ea3af8fa078c 
xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:11 2012 
+0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:20 2012 
+0100
@@ -825,6 +825,9 @@ int guest_iommu_set_base(struct domain *
      if ( !iommu )
          return -EACCES;

+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
+        return 1;
+
      iommu->mmio_base = base;
      base >>= PAGE_SHIFT;

@@ -884,7 +887,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);
@@ -916,6 +919,9 @@ void guest_iommu_destroy(struct domain *
      iommu = domain_iommu(d);
      if ( !iommu )
          return;
+
+    if ( !iommuv2_enabled )
+        return;

      tasklet_kill(&iommu->cmd_buffer_tasklet);
      xfree(iommu);
@@ -944,7 +950,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);
@@ -970,7 +976,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 978e61814be4 -r ea3af8fa078c 
xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Fri Jan 20 14:40:11 2012 
+0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Jan 20 14:40:20 2012 
+0100
@@ -38,6 +38,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)
  {
@@ -799,6 +800,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);

  }
diff -r 978e61814be4 -r ea3af8fa078c xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Fri Jan 20 14:40:11 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Fri Jan 20 14:40:20 2012 +0100
@@ -182,4 +182,6 @@ struct guest_iommu {
      struct guest_iommu_msi  msi;
  };

+extern bool_t iommuv2_enabled;
+
  #endif /* _ASM_X86_64_AMD_IOMMU_H */
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:16:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoH7y-0000IK-Ri; Fri, 20 Jan 2012 16:15:46 +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 1RoH7x-0000I9-9s
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:15:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327076077!61849907!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 26521 invoked from network); 20 Jan 2012 16:14:37 -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; 20 Jan 2012 16:14:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:15:43 +0000
Message-Id: <4F19A180020000780006E0B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:16:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1327074280@gran.amd.com>
In-Reply-To: <patchbomb.1327074280@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 16:44, Wei Wang <wei.wang2@amd.com> wrote:
> Hi all, this is patch v4.

With the current apparent regression from the previous patch series,
can we ask you to first look into that problem before pushing in more
changes?

Thanks, Jan

> 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 beenenabled in guest OS. This patch set adds 
> initial 
> iommu emulation for hvm guests to support ATS device passthru. 
> 
> This patch set should work together with following hw & sw systems:
> 
> * Host system with AMD trinity APU which has enhanced iommu(iommuv2). 
> * AMD Radeon HD 7900 series graphic card.  
> * Linux 3.3 or later which has included iommuv2 kernel driver.
> * AMD catalyst or open source Radeon driver in guest that support HD7900. 
> 
> Most of the works is done by hypervisor. a new guest config parameter
> guest_iommu = {1,0} is introduced to en/disable iommu emulation. 
> 3 hyper-calls are added to support communications among different xen 
> components.
>  
> * iommu_set_msi: used by qemu to inform hypervisor iommu vector number in 
> guest 
> space. Hypervisor needs this vector to inject msi into guest after write PPR 
> log
> entry into guest buffer.
> 
> * iommu_bind_bdf: used by xl to bind virtual bdf of passthru device to 
> machine bdf. 
> IOMMU emulator receives iommu cmd from guest OS and then forwards them  to 
> host 
> iommu. But virtual device id in cmds from guest should be converted into 
> physical 
> id before sending them to real hardware.
> 
> * guest_iommu_set_base: IOMMU MMIO base address is dynamically allocated by
> firmware. This hypercall allows hvmloader to notify hypervisor where the 
> iommu
> mmio pages are.
> 
> I had a picture to explain this better, pls refer to the link.
> 
> http://www.amd64.org/pub/iommuv2.png 
> 
> Thanks,
> Wei
> 
> ======================================================================
> 
> changes in v4:
> * Only tool part in this version, since hypervisor patches have already been 
> committed.
> * rename guest config option from "iommu = {0,1}" to "guest_iommu = {0,1}" 
> * add description into docs/man/xl.cfg.pod.5
> 
> 
> changes in v3:
> * Use xenstore to receive guest iommu configuration instead of adding in a 
> new field in hvm_info_table.
> * Support pci segment in vbdf to mbdf bind.
> * Make hypercalls visible for non-x86 platforms.
> * A few code cleanups according to comments from Jan and Ian.
> 
> Changes in v2:
> * Do not use linked list to access guest iommu tables.
> * Do not parse iommu parameter in libxl_device_model_info again.
> * Fix incorrect logical calculation in patch 11.
> * Fix hypercall definition for non-x86 systems.
> 
> Thanks,
> Wei




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:16:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:16:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoH7y-0000IK-Ri; Fri, 20 Jan 2012 16:15:46 +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 1RoH7x-0000I9-9s
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:15:45 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327076077!61849907!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 26521 invoked from network); 20 Jan 2012 16:14:37 -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; 20 Jan 2012 16:14:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:15:43 +0000
Message-Id: <4F19A180020000780006E0B4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:16:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1327074280@gran.amd.com>
In-Reply-To: <patchbomb.1327074280@gran.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: keir@xen.org,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 16:44, Wei Wang <wei.wang2@amd.com> wrote:
> Hi all, this is patch v4.

With the current apparent regression from the previous patch series,
can we ask you to first look into that problem before pushing in more
changes?

Thanks, Jan

> 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 beenenabled in guest OS. This patch set adds 
> initial 
> iommu emulation for hvm guests to support ATS device passthru. 
> 
> This patch set should work together with following hw & sw systems:
> 
> * Host system with AMD trinity APU which has enhanced iommu(iommuv2). 
> * AMD Radeon HD 7900 series graphic card.  
> * Linux 3.3 or later which has included iommuv2 kernel driver.
> * AMD catalyst or open source Radeon driver in guest that support HD7900. 
> 
> Most of the works is done by hypervisor. a new guest config parameter
> guest_iommu = {1,0} is introduced to en/disable iommu emulation. 
> 3 hyper-calls are added to support communications among different xen 
> components.
>  
> * iommu_set_msi: used by qemu to inform hypervisor iommu vector number in 
> guest 
> space. Hypervisor needs this vector to inject msi into guest after write PPR 
> log
> entry into guest buffer.
> 
> * iommu_bind_bdf: used by xl to bind virtual bdf of passthru device to 
> machine bdf. 
> IOMMU emulator receives iommu cmd from guest OS and then forwards them  to 
> host 
> iommu. But virtual device id in cmds from guest should be converted into 
> physical 
> id before sending them to real hardware.
> 
> * guest_iommu_set_base: IOMMU MMIO base address is dynamically allocated by
> firmware. This hypercall allows hvmloader to notify hypervisor where the 
> iommu
> mmio pages are.
> 
> I had a picture to explain this better, pls refer to the link.
> 
> http://www.amd64.org/pub/iommuv2.png 
> 
> Thanks,
> Wei
> 
> ======================================================================
> 
> changes in v4:
> * Only tool part in this version, since hypervisor patches have already been 
> committed.
> * rename guest config option from "iommu = {0,1}" to "guest_iommu = {0,1}" 
> * add description into docs/man/xl.cfg.pod.5
> 
> 
> changes in v3:
> * Use xenstore to receive guest iommu configuration instead of adding in a 
> new field in hvm_info_table.
> * Support pci segment in vbdf to mbdf bind.
> * Make hypercalls visible for non-x86 platforms.
> * A few code cleanups according to comments from Jan and Ian.
> 
> Changes in v2:
> * Do not use linked list to access guest iommu tables.
> * Do not parse iommu parameter in libxl_device_model_info again.
> * Fix incorrect logical calculation in patch 11.
> * Fix hypercall definition for non-x86 systems.
> 
> Thanks,
> Wei




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:21:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHDe-0000dd-N1; Fri, 20 Jan 2012 16:21: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 1RoHDc-0000dY-JH
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:21:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327076449!50947716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2295 invoked from network); 20 Jan 2012 16:20:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:21: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, 20 Jan 2012 16:21:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 16:21:34 +0000
In-Reply-To: <1327075340.2337.50.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327076495.30054.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:02 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 15:06 +0000, Ian Campbell wrote: 
> > On Fri, 2012-01-20 at 13:11 +0000, Ian Campbell wrote:
> > 
> > > Your patches do the affinity setting pretty early so I'm not sure what's
> > > going on.
> > 
> > The cpu affinities are set and d->node_affinity is getting correctly
> > updated to only include one node before any memory is allocated to the
> > domain, yet memory appears to be being allocated on both nodes.
> > 
> I'm also looking into this and NOT finding an answer... Yet. Will keep
> investigating and report back as soon as I get what's happening...

I think I made the rather basic c*ckup of using a domain configured with
more memory than is in any single node.

/me dons the brown paper bag.

With your affinity patches and the domain restricted to a single node
via cpu affinity The Right Thing seems to happen.

cpupools don't seem to do this, I don't know if that is expected or not.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:21:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:21:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHDe-0000dd-N1; Fri, 20 Jan 2012 16:21: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 1RoHDc-0000dY-JH
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:21:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327076449!50947716!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2295 invoked from network); 20 Jan 2012 16:20:49 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:20:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:21: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, 20 Jan 2012 16:21:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 16:21:34 +0000
In-Reply-To: <1327075340.2337.50.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327076495.30054.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:02 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 15:06 +0000, Ian Campbell wrote: 
> > On Fri, 2012-01-20 at 13:11 +0000, Ian Campbell wrote:
> > 
> > > Your patches do the affinity setting pretty early so I'm not sure what's
> > > going on.
> > 
> > The cpu affinities are set and d->node_affinity is getting correctly
> > updated to only include one node before any memory is allocated to the
> > domain, yet memory appears to be being allocated on both nodes.
> > 
> I'm also looking into this and NOT finding an answer... Yet. Will keep
> investigating and report back as soon as I get what's happening...

I think I made the rather basic c*ckup of using a domain configured with
more memory than is in any single node.

/me dons the brown paper bag.

With your affinity patches and the domain restricted to a single node
via cpu affinity The Right Thing seems to happen.

cpupools don't seem to do this, I don't know if that is expected or not.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:25:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoHHO-0000qQ-Lu; Fri, 20 Jan 2012 16:25: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 1RoHHN-0000qH-Hn
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:25:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327076688!49273114!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 2661 invoked from network); 20 Jan 2012 16:24:48 -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; 20 Jan 2012 16:24:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:25:23 +0000
Message-Id: <4F19A3C2020000780006E0F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:26:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1327074280@gran.amd.com>
	<20249.37479.802666.184751@mariner.uk.xensource.com>
	<4F199485.4050304@amd.com>
In-Reply-To: <4F199485.4050304@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:21, Wei Wang <wei.wang2@amd.com> wrote:
> could you provide more info about your push test on amd machines? This 
> patch queue should not affect any amd machines that do not have iommuv2 
> hardware in it.

My suspicion is that the previous set still has something in it that breaks
if a system does not have a v2 IOMMU (or maybe no IOMMU at all). Did
you cross check the previous series this way (apparently you didn't
check on Intel systems, otherwise 24520:9a967990b4d2 wouldn't have
been necessary, which allowed for the fuzzy push Ian referred to)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:25:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoHHO-0000qQ-Lu; Fri, 20 Jan 2012 16:25: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 1RoHHN-0000qH-Hn
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:25:29 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327076688!49273114!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 2661 invoked from network); 20 Jan 2012 16:24:48 -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; 20 Jan 2012 16:24:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:25:23 +0000
Message-Id: <4F19A3C2020000780006E0F7@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:26:26 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1327074280@gran.amd.com>
	<20249.37479.802666.184751@mariner.uk.xensource.com>
	<4F199485.4050304@amd.com>
In-Reply-To: <4F199485.4050304@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:21, Wei Wang <wei.wang2@amd.com> wrote:
> could you provide more info about your push test on amd machines? This 
> patch queue should not affect any amd machines that do not have iommuv2 
> hardware in it.

My suspicion is that the previous set still has something in it that breaks
if a system does not have a v2 IOMMU (or maybe no IOMMU at all). Did
you cross check the previous series this way (apparently you didn't
check on Intel systems, otherwise 24520:9a967990b4d2 wouldn't have
been necessary, which allowed for the fuzzy push Ian referred to)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:29:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHKe-0000zZ-97; Fri, 20 Jan 2012 16:28: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 1RoHKc-0000zG-BB
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:28:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327076882!61098787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29151 invoked from network); 20 Jan 2012 16:28:02 -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;
	20 Jan 2012 16:28:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:28: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, 20 Jan 2012 16:28:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 16:28:43 +0000
In-Reply-To: <1327076495.30054.63.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327076924.30054.65.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> cpupools don't seem to do this, I don't know if that is expected or not.

Right, so cpupools do not appear to set the vcpu affinity, at least not
at the level where it effects memory allocation. However both
	pool="Pool-node0" cpus="0-7"
and
	pool="Pool-node1" cpus="8-15"
work as expected on a system with 8 cpus per node.

Should something be doing this pinning automatically?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:29:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:29:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHKe-0000zZ-97; Fri, 20 Jan 2012 16:28: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 1RoHKc-0000zG-BB
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:28:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327076882!61098787!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29151 invoked from network); 20 Jan 2012 16:28:02 -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;
	20 Jan 2012 16:28:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:28: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, 20 Jan 2012 16:28:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 16:28:43 +0000
In-Reply-To: <1327076495.30054.63.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327076924.30054.65.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> cpupools don't seem to do this, I don't know if that is expected or not.

Right, so cpupools do not appear to set the vcpu affinity, at least not
at the level where it effects memory allocation. However both
	pool="Pool-node0" cpus="0-7"
and
	pool="Pool-node1" cpus="8-15"
work as expected on a system with 8 cpus per node.

Should something be doing this pinning automatically?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:31:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHN5-0001A4-4Q; Fri, 20 Jan 2012 16:31:23 +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 1RoHN3-00019X-OD
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:31:21 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327077074!11900120!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1175 invoked from network); 20 Jan 2012 16:31:15 -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;
	20 Jan 2012 16:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178441316"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:31: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, 20 Jan 2012 11:31:13 -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 q0KGV9tD016102;
	Fri, 20 Jan 2012 08:31:09 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327076924.30054.65.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Jan 2012 16:31:08 +0000
Message-ID: <1327077068.23358.97.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > cpupools don't seem to do this, I don't know if that is expected or not.
> 
> Right, so cpupools do not appear to set the vcpu affinity, at least not
> at the level where it effects memory allocation. However both
> 	pool="Pool-node0" cpus="0-7"
> and
> 	pool="Pool-node1" cpus="8-15"
> work as expected on a system with 8 cpus per node.
> 
> Should something be doing this pinning automatically?

It seems like it would be useful; But then we have the issue of, if a vm
was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
what do you do?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:31:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:31:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHN5-0001A4-4Q; Fri, 20 Jan 2012 16:31:23 +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 1RoHN3-00019X-OD
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:31:21 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327077074!11900120!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1175 invoked from network); 20 Jan 2012 16:31:15 -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;
	20 Jan 2012 16:31:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178441316"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:31: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, 20 Jan 2012 11:31:13 -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 q0KGV9tD016102;
	Fri, 20 Jan 2012 08:31:09 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327076924.30054.65.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Jan 2012 16:31:08 +0000
Message-ID: <1327077068.23358.97.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > cpupools don't seem to do this, I don't know if that is expected or not.
> 
> Right, so cpupools do not appear to set the vcpu affinity, at least not
> at the level where it effects memory allocation. However both
> 	pool="Pool-node0" cpus="0-7"
> and
> 	pool="Pool-node1" cpus="8-15"
> work as expected on a system with 8 cpus per node.
> 
> Should something be doing this pinning automatically?

It seems like it would be useful; But then we have the issue of, if a vm
was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
what do you do?

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:32:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHOR-0001Iu-QQ; Fri, 20 Jan 2012 16:32:47 +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 1RoHOP-0001I4-NU
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:32:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327077158!11742049!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 32650 invoked from network); 20 Jan 2012 16:32:38 -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; 20 Jan 2012 16:32:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:32:38 +0000
Message-Id: <4F19A577020000780006E115@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:33: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="=__PartDEF08577.1__="
Cc: yuan.b.liu@intel.com, Eddie Dong <eddie.dong@intel.com>
Subject: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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.

--=__PartDEF08577.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This addresses a number of problems in msixtbl_{read,write}():
- address alignment was not checked, allowing for memory corruption in
  the hypervisor (write case) or returning of hypervisor private data
  to the guest (read case)
- the interrupt mask bit was permitted to be written by the guest
  (while Xen's interrupt flow control routines need to control it)
- MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
  numbers (making it unobvious why they have these values, and making
  the latter non-portable)
- MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
  non-zero table offset); this was also affecting host MSI-X code
- struct msixtbl_entry's table_flags[] was one element larger than
  necessary due to improper open-coding of BITS_TO_LONGS()
- msixtbl_read() unconditionally accessed the physical table, even
  though the data was only needed in a quarter of all cases
- various calculations were done unnecessarily for both of the rather
  distinct code paths in msixtbl_read()

Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
chosen to be 3.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -165,7 +165,7 @@ struct msixtbl_entry
     struct pci_dev *pdev;
     unsigned long gtable;       /* gpa of msix table */
     unsigned long table_len;
-    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + =
1];
+    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
 #define MAX_MSIX_ACC_ENTRIES 3
     struct {=20
         uint32_t msi_ad[3];	/* Shadow of address low, high and data */
@@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin
 static void __iomem *msixtbl_addr_to_virt(
     struct msixtbl_entry *entry, unsigned long addr)
 {
-    int idx, nr_page;
+    unsigned int idx, nr_page;
=20
-    if ( !entry )
+    if ( !entry || !entry->pdev )
         return NULL;
=20
     nr_page =3D (addr >> PAGE_SHIFT) -
               (entry->gtable >> PAGE_SHIFT);
=20
-    if ( !entry->pdev )
-        return NULL;
-
     idx =3D entry->pdev->msix_table_idx[nr_page];
     if ( !idx )
         return NULL;
@@ -215,37 +212,34 @@ static int msixtbl_read(
     struct vcpu *v, unsigned long address,
     unsigned long len, unsigned long *pval)
 {
-    unsigned long offset, val;
+    unsigned long offset;
     struct msixtbl_entry *entry;
     void *virt;
-    int nr_entry, index;
+    unsigned int nr_entry, index;
     int r =3D X86EMUL_UNHANDLEABLE;
=20
-    rcu_read_lock(&msixtbl_rcu_lock);
+    if ( len !=3D 4 || (address & 3) )
+        return r;
=20
-    if ( len !=3D 4 )
-        goto out;
+    rcu_read_lock(&msixtbl_rcu_lock);
=20
     entry =3D msixtbl_find_entry(v, address);
-    virt =3D msixtbl_addr_to_virt(entry, address);
-    if ( !virt )
-        goto out;
-
-    nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
     offset =3D address & (PCI_MSIX_ENTRY_SIZE - 1);
-    if ( nr_entry >=3D MAX_MSIX_ACC_ENTRIES &&=20
-         offset !=3D PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
-        goto out;
=20
-    val =3D readl(virt);
     if ( offset !=3D PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
     {
+        nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
+        if ( nr_entry >=3D MAX_MSIX_ACC_ENTRIES )
+            goto out;
         index =3D offset / sizeof(uint32_t);
         *pval =3D entry->gentries[nr_entry].msi_ad[index];
     }
     else=20
     {
-        *pval =3D val;
+        virt =3D msixtbl_addr_to_virt(entry, address);
+        if ( !virt )
+            goto out;
+        *pval =3D readl(virt);
     }
    =20
     r =3D X86EMUL_OKAY;
@@ -260,13 +254,13 @@ static int msixtbl_write(struct vcpu *v,
     unsigned long offset;
     struct msixtbl_entry *entry;
     void *virt;
-    int nr_entry, index;
+    unsigned int nr_entry, index;
     int r =3D X86EMUL_UNHANDLEABLE;
=20
-    rcu_read_lock(&msixtbl_rcu_lock);
+    if ( len !=3D 4 || (address & 3) )
+        return r;
=20
-    if ( len !=3D 4 )
-        goto out;
+    rcu_read_lock(&msixtbl_rcu_lock);
=20
     entry =3D msixtbl_find_entry(v, address);
     nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
@@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
     if ( !virt )
         goto out;
=20
+    /* Do not allow the mask bit to be changed. */
+#if 0 /* XXX
+       * As the mask bit is the only defined bit in the word, and as the
+       * host MSI-X code doesn't preserve the other bits anyway, doing
+       * this is pointless. So for now just discard the write (also
+       * saving us from having to determine the matching irq_desc).
+       */
+    spin_lock_irqsave(&desc->lock, flags);
+    orig =3D readl(virt);
+    val &=3D ~PCI_MSIX_VECTOR_BITMASK;
+    val |=3D orig & PCI_MSIX_VECTOR_BITMASK;
     writel(val, virt);
-    r =3D X86EMUL_OKAY;
+    spin_unlock_irqrestore(&desc->lock, flags);
+#endif
=20
+    r =3D X86EMUL_OKAY;
 out:
     rcu_read_unlock(&msixtbl_rcu_lock);
     return r;
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -122,12 +122,6 @@ int msi_free_irq(struct msi_desc *entry)
  */
 #define NR_HP_RESERVED_VECTORS 	20
=20
-#define PCI_MSIX_ENTRY_SIZE			16
-#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
-#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
-#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
-#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
-
 #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
 #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
 #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -11,6 +11,8 @@
 #include <xen/list.h>
 #include <xen/spinlock.h>
 #include <xen/irq.h>
+#include <xen/pci_regs.h>
+#include <xen/pfn.h>
 #include <asm/pci.h>
=20
 /*
@@ -30,8 +32,10 @@
 #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
 #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
=20
-#define MAX_MSIX_TABLE_ENTRIES  2048
-#define MAX_MSIX_TABLE_PAGES    8
+#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
+#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
+                                       PCI_MSIX_ENTRY_SIZE + \
+                                       (~PCI_MSIX_BIRMASK & (PAGE_SIZE - =
1)))
 struct pci_dev_info {
     bool_t is_extfn;
     bool_t is_virtfn;
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -305,6 +305,12 @@
 #define PCI_MSIX_PBA		8
 #define  PCI_MSIX_BIRMASK	(7 << 0)
=20
+#define PCI_MSIX_ENTRY_SIZE			16
+#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
+#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
+#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
+#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
+
 #define PCI_MSIX_VECTOR_BITMASK	(1 << 0)
=20
 /* CompactPCI Hotswap Register */



--=__PartDEF08577.1__=
Content-Type: text/plain; name="x86-vmsi-fixes.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmsi-fixes.patch"

x86/vMSI: miscellaneous fixes=0A=0AThis addresses a number of problems in =
msixtbl_{read,write}():=0A- address alignment was not checked, allowing =
for memory corruption in=0A  the hypervisor (write case) or returning of =
hypervisor private data=0A  to the guest (read case)=0A- the interrupt =
mask bit was permitted to be written by the guest=0A  (while Xen's =
interrupt flow control routines need to control it)=0A- MAX_MSIX_TABLE_{ENT=
RIES,PAGES} were pointlessly defined to plain=0A  numbers (making it =
unobvious why they have these values, and making=0A  the latter non-portabl=
e)=0A- MAX_MSIX_TABLE_PAGES was also off by one (failing to account for =
a=0A  non-zero table offset); this was also affecting host MSI-X code=0A- =
struct msixtbl_entry's table_flags[] was one element larger than=0A  =
necessary due to improper open-coding of BITS_TO_LONGS()=0A- msixtbl_read()=
 unconditionally accessed the physical table, even=0A  though the data was =
only needed in a quarter of all cases=0A- various calculations were done =
unnecessarily for both of the rather=0A  distinct code paths in msixtbl_rea=
d()=0A=0AAdditionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES =
was=0Achosen to be 3.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/hvm/vmsi.c=0A+++ b/xen/arch/x86/hvm/vmsi.c=0A@@ =
-165,7 +165,7 @@ struct msixtbl_entry=0A     struct pci_dev *pdev;=0A     =
unsigned long gtable;       /* gpa of msix table */=0A     unsigned long =
table_len;=0A-    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / =
BITS_PER_LONG + 1];=0A+    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX=
_TABLE_ENTRIES)];=0A #define MAX_MSIX_ACC_ENTRIES 3=0A     struct { =0A    =
     uint32_t msi_ad[3];	/* Shadow of address low, high and data =
*/=0A@@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin=0A =
static void __iomem *msixtbl_addr_to_virt(=0A     struct msixtbl_entry =
*entry, unsigned long addr)=0A {=0A-    int idx, nr_page;=0A+    unsigned =
int idx, nr_page;=0A =0A-    if ( !entry )=0A+    if ( !entry || !entry->pd=
ev )=0A         return NULL;=0A =0A     nr_page =3D (addr >> PAGE_SHIFT) =
-=0A               (entry->gtable >> PAGE_SHIFT);=0A =0A-    if ( =
!entry->pdev )=0A-        return NULL;=0A-=0A     idx =3D entry->pdev->msix=
_table_idx[nr_page];=0A     if ( !idx )=0A         return NULL;=0A@@ =
-215,37 +212,34 @@ static int msixtbl_read(=0A     struct vcpu *v, =
unsigned long address,=0A     unsigned long len, unsigned long *pval)=0A =
{=0A-    unsigned long offset, val;=0A+    unsigned long offset;=0A     =
struct msixtbl_entry *entry;=0A     void *virt;=0A-    int nr_entry, =
index;=0A+    unsigned int nr_entry, index;=0A     int r =3D X86EMUL_UNHAND=
LEABLE;=0A =0A-    rcu_read_lock(&msixtbl_rcu_lock);=0A+    if ( len !=3D =
4 || (address & 3) )=0A+        return r;=0A =0A-    if ( len !=3D 4 )=0A- =
       goto out;=0A+    rcu_read_lock(&msixtbl_rcu_lock);=0A =0A     entry =
=3D msixtbl_find_entry(v, address);=0A-    virt =3D msixtbl_addr_to_virt(en=
try, address);=0A-    if ( !virt )=0A-        goto out;=0A-=0A-    =
nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;=0A     =
offset =3D address & (PCI_MSIX_ENTRY_SIZE - 1);=0A-    if ( nr_entry >=3D =
MAX_MSIX_ACC_ENTRIES && =0A-         offset !=3D PCI_MSIX_ENTRY_VECTOR_CTRL=
_OFFSET )=0A-        goto out;=0A =0A-    val =3D readl(virt);=0A     if ( =
offset !=3D PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )=0A     {=0A+        =
nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;=0A+        =
if ( nr_entry >=3D MAX_MSIX_ACC_ENTRIES )=0A+            goto out;=0A      =
   index =3D offset / sizeof(uint32_t);=0A         *pval =3D entry->gentrie=
s[nr_entry].msi_ad[index];=0A     }=0A     else =0A     {=0A-        *pval =
=3D val;=0A+        virt =3D msixtbl_addr_to_virt(entry, address);=0A+     =
   if ( !virt )=0A+            goto out;=0A+        *pval =3D readl(virt);=
=0A     }=0A     =0A     r =3D X86EMUL_OKAY;=0A@@ -260,13 +254,13 @@ =
static int msixtbl_write(struct vcpu *v,=0A     unsigned long offset;=0A   =
  struct msixtbl_entry *entry;=0A     void *virt;=0A-    int nr_entry, =
index;=0A+    unsigned int nr_entry, index;=0A     int r =3D X86EMUL_UNHAND=
LEABLE;=0A =0A-    rcu_read_lock(&msixtbl_rcu_lock);=0A+    if ( len !=3D =
4 || (address & 3) )=0A+        return r;=0A =0A-    if ( len !=3D 4 )=0A- =
       goto out;=0A+    rcu_read_lock(&msixtbl_rcu_lock);=0A =0A     entry =
=3D msixtbl_find_entry(v, address);=0A     nr_entry =3D (address - =
entry->gtable) / PCI_MSIX_ENTRY_SIZE;=0A@@ -291,9 +285,22 @@ static int =
msixtbl_write(struct vcpu *v,=0A     if ( !virt )=0A         goto out;=0A =
=0A+    /* Do not allow the mask bit to be changed. */=0A+#if 0 /* XXX=0A+ =
      * As the mask bit is the only defined bit in the word, and as =
the=0A+       * host MSI-X code doesn't preserve the other bits anyway, =
doing=0A+       * this is pointless. So for now just discard the write =
(also=0A+       * saving us from having to determine the matching =
irq_desc).=0A+       */=0A+    spin_lock_irqsave(&desc->lock, flags);=0A+  =
  orig =3D readl(virt);=0A+    val &=3D ~PCI_MSIX_VECTOR_BITMASK;=0A+    =
val |=3D orig & PCI_MSIX_VECTOR_BITMASK;=0A     writel(val, virt);=0A-    =
r =3D X86EMUL_OKAY;=0A+    spin_unlock_irqrestore(&desc->lock, flags);=0A+#=
endif=0A =0A+    r =3D X86EMUL_OKAY;=0A out:=0A     rcu_read_unlock(&msixtb=
l_rcu_lock);=0A     return r;=0A--- a/xen/include/asm-x86/msi.h=0A+++ =
b/xen/include/asm-x86/msi.h=0A@@ -122,12 +122,6 @@ int msi_free_irq(struct =
msi_desc *entry)=0A  */=0A #define NR_HP_RESERVED_VECTORS 	20=0A =
=0A-#define PCI_MSIX_ENTRY_SIZE			16=0A-#define  PCI_MSIX_ENT=
RY_LOWER_ADDR_OFFSET	0=0A-#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	=
4=0A-#define  PCI_MSIX_ENTRY_DATA_OFFSET		8=0A-#define  =
PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12=0A-=0A #define msi_control_reg(b=
ase)		(base + PCI_MSI_FLAGS)=0A #define msi_lower_address_reg(bas=
e)	(base + PCI_MSI_ADDRESS_LO)=0A #define msi_upper_address_reg(base)	=
(base + PCI_MSI_ADDRESS_HI)=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/inclu=
de/xen/pci.h=0A@@ -11,6 +11,8 @@=0A #include <xen/list.h>=0A #include =
<xen/spinlock.h>=0A #include <xen/irq.h>=0A+#include <xen/pci_regs.h>=0A+#i=
nclude <xen/pfn.h>=0A #include <asm/pci.h>=0A =0A /*=0A@@ -30,8 +32,10 =
@@=0A #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))=0A =
#define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))=0A =0A-#defin=
e MAX_MSIX_TABLE_ENTRIES  2048=0A-#define MAX_MSIX_TABLE_PAGES    =
8=0A+#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)=0A+#define =
MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \=0A+              =
                         PCI_MSIX_ENTRY_SIZE + \=0A+                       =
                (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))=0A struct pci_dev_in=
fo {=0A     bool_t is_extfn;=0A     bool_t is_virtfn;=0A--- a/xen/include/x=
en/pci_regs.h=0A+++ b/xen/include/xen/pci_regs.h=0A@@ -305,6 +305,12 @@=0A =
#define PCI_MSIX_PBA		8=0A #define  PCI_MSIX_BIRMASK	(7 << =
0)=0A =0A+#define PCI_MSIX_ENTRY_SIZE			16=0A+#define  =
PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0=0A+#define  PCI_MSIX_ENTRY_UPPER_=
ADDR_OFFSET	4=0A+#define  PCI_MSIX_ENTRY_DATA_OFFSET		=
8=0A+#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12=0A+=0A #define =
PCI_MSIX_VECTOR_BITMASK	(1 << 0)=0A =0A /* CompactPCI Hotswap Register =
*/=0A
--=__PartDEF08577.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

--=__PartDEF08577.1__=--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:32:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHOR-0001Iu-QQ; Fri, 20 Jan 2012 16:32:47 +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 1RoHOP-0001I4-NU
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:32:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327077158!11742049!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 32650 invoked from network); 20 Jan 2012 16:32:38 -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; 20 Jan 2012 16:32:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:32:38 +0000
Message-Id: <4F19A577020000780006E115@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:33: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="=__PartDEF08577.1__="
Cc: yuan.b.liu@intel.com, Eddie Dong <eddie.dong@intel.com>
Subject: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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.

--=__PartDEF08577.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This addresses a number of problems in msixtbl_{read,write}():
- address alignment was not checked, allowing for memory corruption in
  the hypervisor (write case) or returning of hypervisor private data
  to the guest (read case)
- the interrupt mask bit was permitted to be written by the guest
  (while Xen's interrupt flow control routines need to control it)
- MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
  numbers (making it unobvious why they have these values, and making
  the latter non-portable)
- MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
  non-zero table offset); this was also affecting host MSI-X code
- struct msixtbl_entry's table_flags[] was one element larger than
  necessary due to improper open-coding of BITS_TO_LONGS()
- msixtbl_read() unconditionally accessed the physical table, even
  though the data was only needed in a quarter of all cases
- various calculations were done unnecessarily for both of the rather
  distinct code paths in msixtbl_read()

Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
chosen to be 3.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -165,7 +165,7 @@ struct msixtbl_entry
     struct pci_dev *pdev;
     unsigned long gtable;       /* gpa of msix table */
     unsigned long table_len;
-    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + =
1];
+    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
 #define MAX_MSIX_ACC_ENTRIES 3
     struct {=20
         uint32_t msi_ad[3];	/* Shadow of address low, high and data */
@@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin
 static void __iomem *msixtbl_addr_to_virt(
     struct msixtbl_entry *entry, unsigned long addr)
 {
-    int idx, nr_page;
+    unsigned int idx, nr_page;
=20
-    if ( !entry )
+    if ( !entry || !entry->pdev )
         return NULL;
=20
     nr_page =3D (addr >> PAGE_SHIFT) -
               (entry->gtable >> PAGE_SHIFT);
=20
-    if ( !entry->pdev )
-        return NULL;
-
     idx =3D entry->pdev->msix_table_idx[nr_page];
     if ( !idx )
         return NULL;
@@ -215,37 +212,34 @@ static int msixtbl_read(
     struct vcpu *v, unsigned long address,
     unsigned long len, unsigned long *pval)
 {
-    unsigned long offset, val;
+    unsigned long offset;
     struct msixtbl_entry *entry;
     void *virt;
-    int nr_entry, index;
+    unsigned int nr_entry, index;
     int r =3D X86EMUL_UNHANDLEABLE;
=20
-    rcu_read_lock(&msixtbl_rcu_lock);
+    if ( len !=3D 4 || (address & 3) )
+        return r;
=20
-    if ( len !=3D 4 )
-        goto out;
+    rcu_read_lock(&msixtbl_rcu_lock);
=20
     entry =3D msixtbl_find_entry(v, address);
-    virt =3D msixtbl_addr_to_virt(entry, address);
-    if ( !virt )
-        goto out;
-
-    nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
     offset =3D address & (PCI_MSIX_ENTRY_SIZE - 1);
-    if ( nr_entry >=3D MAX_MSIX_ACC_ENTRIES &&=20
-         offset !=3D PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
-        goto out;
=20
-    val =3D readl(virt);
     if ( offset !=3D PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
     {
+        nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
+        if ( nr_entry >=3D MAX_MSIX_ACC_ENTRIES )
+            goto out;
         index =3D offset / sizeof(uint32_t);
         *pval =3D entry->gentries[nr_entry].msi_ad[index];
     }
     else=20
     {
-        *pval =3D val;
+        virt =3D msixtbl_addr_to_virt(entry, address);
+        if ( !virt )
+            goto out;
+        *pval =3D readl(virt);
     }
    =20
     r =3D X86EMUL_OKAY;
@@ -260,13 +254,13 @@ static int msixtbl_write(struct vcpu *v,
     unsigned long offset;
     struct msixtbl_entry *entry;
     void *virt;
-    int nr_entry, index;
+    unsigned int nr_entry, index;
     int r =3D X86EMUL_UNHANDLEABLE;
=20
-    rcu_read_lock(&msixtbl_rcu_lock);
+    if ( len !=3D 4 || (address & 3) )
+        return r;
=20
-    if ( len !=3D 4 )
-        goto out;
+    rcu_read_lock(&msixtbl_rcu_lock);
=20
     entry =3D msixtbl_find_entry(v, address);
     nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
@@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
     if ( !virt )
         goto out;
=20
+    /* Do not allow the mask bit to be changed. */
+#if 0 /* XXX
+       * As the mask bit is the only defined bit in the word, and as the
+       * host MSI-X code doesn't preserve the other bits anyway, doing
+       * this is pointless. So for now just discard the write (also
+       * saving us from having to determine the matching irq_desc).
+       */
+    spin_lock_irqsave(&desc->lock, flags);
+    orig =3D readl(virt);
+    val &=3D ~PCI_MSIX_VECTOR_BITMASK;
+    val |=3D orig & PCI_MSIX_VECTOR_BITMASK;
     writel(val, virt);
-    r =3D X86EMUL_OKAY;
+    spin_unlock_irqrestore(&desc->lock, flags);
+#endif
=20
+    r =3D X86EMUL_OKAY;
 out:
     rcu_read_unlock(&msixtbl_rcu_lock);
     return r;
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -122,12 +122,6 @@ int msi_free_irq(struct msi_desc *entry)
  */
 #define NR_HP_RESERVED_VECTORS 	20
=20
-#define PCI_MSIX_ENTRY_SIZE			16
-#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
-#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
-#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
-#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
-
 #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
 #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
 #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -11,6 +11,8 @@
 #include <xen/list.h>
 #include <xen/spinlock.h>
 #include <xen/irq.h>
+#include <xen/pci_regs.h>
+#include <xen/pfn.h>
 #include <asm/pci.h>
=20
 /*
@@ -30,8 +32,10 @@
 #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
 #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
=20
-#define MAX_MSIX_TABLE_ENTRIES  2048
-#define MAX_MSIX_TABLE_PAGES    8
+#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
+#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
+                                       PCI_MSIX_ENTRY_SIZE + \
+                                       (~PCI_MSIX_BIRMASK & (PAGE_SIZE - =
1)))
 struct pci_dev_info {
     bool_t is_extfn;
     bool_t is_virtfn;
--- a/xen/include/xen/pci_regs.h
+++ b/xen/include/xen/pci_regs.h
@@ -305,6 +305,12 @@
 #define PCI_MSIX_PBA		8
 #define  PCI_MSIX_BIRMASK	(7 << 0)
=20
+#define PCI_MSIX_ENTRY_SIZE			16
+#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
+#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
+#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
+#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
+
 #define PCI_MSIX_VECTOR_BITMASK	(1 << 0)
=20
 /* CompactPCI Hotswap Register */



--=__PartDEF08577.1__=
Content-Type: text/plain; name="x86-vmsi-fixes.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmsi-fixes.patch"

x86/vMSI: miscellaneous fixes=0A=0AThis addresses a number of problems in =
msixtbl_{read,write}():=0A- address alignment was not checked, allowing =
for memory corruption in=0A  the hypervisor (write case) or returning of =
hypervisor private data=0A  to the guest (read case)=0A- the interrupt =
mask bit was permitted to be written by the guest=0A  (while Xen's =
interrupt flow control routines need to control it)=0A- MAX_MSIX_TABLE_{ENT=
RIES,PAGES} were pointlessly defined to plain=0A  numbers (making it =
unobvious why they have these values, and making=0A  the latter non-portabl=
e)=0A- MAX_MSIX_TABLE_PAGES was also off by one (failing to account for =
a=0A  non-zero table offset); this was also affecting host MSI-X code=0A- =
struct msixtbl_entry's table_flags[] was one element larger than=0A  =
necessary due to improper open-coding of BITS_TO_LONGS()=0A- msixtbl_read()=
 unconditionally accessed the physical table, even=0A  though the data was =
only needed in a quarter of all cases=0A- various calculations were done =
unnecessarily for both of the rather=0A  distinct code paths in msixtbl_rea=
d()=0A=0AAdditionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES =
was=0Achosen to be 3.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A--- a/xen/arch/x86/hvm/vmsi.c=0A+++ b/xen/arch/x86/hvm/vmsi.c=0A@@ =
-165,7 +165,7 @@ struct msixtbl_entry=0A     struct pci_dev *pdev;=0A     =
unsigned long gtable;       /* gpa of msix table */=0A     unsigned long =
table_len;=0A-    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / =
BITS_PER_LONG + 1];=0A+    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX=
_TABLE_ENTRIES)];=0A #define MAX_MSIX_ACC_ENTRIES 3=0A     struct { =0A    =
     uint32_t msi_ad[3];	/* Shadow of address low, high and data =
*/=0A@@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin=0A =
static void __iomem *msixtbl_addr_to_virt(=0A     struct msixtbl_entry =
*entry, unsigned long addr)=0A {=0A-    int idx, nr_page;=0A+    unsigned =
int idx, nr_page;=0A =0A-    if ( !entry )=0A+    if ( !entry || !entry->pd=
ev )=0A         return NULL;=0A =0A     nr_page =3D (addr >> PAGE_SHIFT) =
-=0A               (entry->gtable >> PAGE_SHIFT);=0A =0A-    if ( =
!entry->pdev )=0A-        return NULL;=0A-=0A     idx =3D entry->pdev->msix=
_table_idx[nr_page];=0A     if ( !idx )=0A         return NULL;=0A@@ =
-215,37 +212,34 @@ static int msixtbl_read(=0A     struct vcpu *v, =
unsigned long address,=0A     unsigned long len, unsigned long *pval)=0A =
{=0A-    unsigned long offset, val;=0A+    unsigned long offset;=0A     =
struct msixtbl_entry *entry;=0A     void *virt;=0A-    int nr_entry, =
index;=0A+    unsigned int nr_entry, index;=0A     int r =3D X86EMUL_UNHAND=
LEABLE;=0A =0A-    rcu_read_lock(&msixtbl_rcu_lock);=0A+    if ( len !=3D =
4 || (address & 3) )=0A+        return r;=0A =0A-    if ( len !=3D 4 )=0A- =
       goto out;=0A+    rcu_read_lock(&msixtbl_rcu_lock);=0A =0A     entry =
=3D msixtbl_find_entry(v, address);=0A-    virt =3D msixtbl_addr_to_virt(en=
try, address);=0A-    if ( !virt )=0A-        goto out;=0A-=0A-    =
nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;=0A     =
offset =3D address & (PCI_MSIX_ENTRY_SIZE - 1);=0A-    if ( nr_entry >=3D =
MAX_MSIX_ACC_ENTRIES && =0A-         offset !=3D PCI_MSIX_ENTRY_VECTOR_CTRL=
_OFFSET )=0A-        goto out;=0A =0A-    val =3D readl(virt);=0A     if ( =
offset !=3D PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )=0A     {=0A+        =
nr_entry =3D (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;=0A+        =
if ( nr_entry >=3D MAX_MSIX_ACC_ENTRIES )=0A+            goto out;=0A      =
   index =3D offset / sizeof(uint32_t);=0A         *pval =3D entry->gentrie=
s[nr_entry].msi_ad[index];=0A     }=0A     else =0A     {=0A-        *pval =
=3D val;=0A+        virt =3D msixtbl_addr_to_virt(entry, address);=0A+     =
   if ( !virt )=0A+            goto out;=0A+        *pval =3D readl(virt);=
=0A     }=0A     =0A     r =3D X86EMUL_OKAY;=0A@@ -260,13 +254,13 @@ =
static int msixtbl_write(struct vcpu *v,=0A     unsigned long offset;=0A   =
  struct msixtbl_entry *entry;=0A     void *virt;=0A-    int nr_entry, =
index;=0A+    unsigned int nr_entry, index;=0A     int r =3D X86EMUL_UNHAND=
LEABLE;=0A =0A-    rcu_read_lock(&msixtbl_rcu_lock);=0A+    if ( len !=3D =
4 || (address & 3) )=0A+        return r;=0A =0A-    if ( len !=3D 4 )=0A- =
       goto out;=0A+    rcu_read_lock(&msixtbl_rcu_lock);=0A =0A     entry =
=3D msixtbl_find_entry(v, address);=0A     nr_entry =3D (address - =
entry->gtable) / PCI_MSIX_ENTRY_SIZE;=0A@@ -291,9 +285,22 @@ static int =
msixtbl_write(struct vcpu *v,=0A     if ( !virt )=0A         goto out;=0A =
=0A+    /* Do not allow the mask bit to be changed. */=0A+#if 0 /* XXX=0A+ =
      * As the mask bit is the only defined bit in the word, and as =
the=0A+       * host MSI-X code doesn't preserve the other bits anyway, =
doing=0A+       * this is pointless. So for now just discard the write =
(also=0A+       * saving us from having to determine the matching =
irq_desc).=0A+       */=0A+    spin_lock_irqsave(&desc->lock, flags);=0A+  =
  orig =3D readl(virt);=0A+    val &=3D ~PCI_MSIX_VECTOR_BITMASK;=0A+    =
val |=3D orig & PCI_MSIX_VECTOR_BITMASK;=0A     writel(val, virt);=0A-    =
r =3D X86EMUL_OKAY;=0A+    spin_unlock_irqrestore(&desc->lock, flags);=0A+#=
endif=0A =0A+    r =3D X86EMUL_OKAY;=0A out:=0A     rcu_read_unlock(&msixtb=
l_rcu_lock);=0A     return r;=0A--- a/xen/include/asm-x86/msi.h=0A+++ =
b/xen/include/asm-x86/msi.h=0A@@ -122,12 +122,6 @@ int msi_free_irq(struct =
msi_desc *entry)=0A  */=0A #define NR_HP_RESERVED_VECTORS 	20=0A =
=0A-#define PCI_MSIX_ENTRY_SIZE			16=0A-#define  PCI_MSIX_ENT=
RY_LOWER_ADDR_OFFSET	0=0A-#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	=
4=0A-#define  PCI_MSIX_ENTRY_DATA_OFFSET		8=0A-#define  =
PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12=0A-=0A #define msi_control_reg(b=
ase)		(base + PCI_MSI_FLAGS)=0A #define msi_lower_address_reg(bas=
e)	(base + PCI_MSI_ADDRESS_LO)=0A #define msi_upper_address_reg(base)	=
(base + PCI_MSI_ADDRESS_HI)=0A--- a/xen/include/xen/pci.h=0A+++ b/xen/inclu=
de/xen/pci.h=0A@@ -11,6 +11,8 @@=0A #include <xen/list.h>=0A #include =
<xen/spinlock.h>=0A #include <xen/irq.h>=0A+#include <xen/pci_regs.h>=0A+#i=
nclude <xen/pfn.h>=0A #include <asm/pci.h>=0A =0A /*=0A@@ -30,8 +32,10 =
@@=0A #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))=0A =
#define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))=0A =0A-#defin=
e MAX_MSIX_TABLE_ENTRIES  2048=0A-#define MAX_MSIX_TABLE_PAGES    =
8=0A+#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)=0A+#define =
MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \=0A+              =
                         PCI_MSIX_ENTRY_SIZE + \=0A+                       =
                (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))=0A struct pci_dev_in=
fo {=0A     bool_t is_extfn;=0A     bool_t is_virtfn;=0A--- a/xen/include/x=
en/pci_regs.h=0A+++ b/xen/include/xen/pci_regs.h=0A@@ -305,6 +305,12 @@=0A =
#define PCI_MSIX_PBA		8=0A #define  PCI_MSIX_BIRMASK	(7 << =
0)=0A =0A+#define PCI_MSIX_ENTRY_SIZE			16=0A+#define  =
PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0=0A+#define  PCI_MSIX_ENTRY_UPPER_=
ADDR_OFFSET	4=0A+#define  PCI_MSIX_ENTRY_DATA_OFFSET		=
8=0A+#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12=0A+=0A #define =
PCI_MSIX_VECTOR_BITMASK	(1 << 0)=0A =0A /* CompactPCI Hotswap Register =
*/=0A
--=__PartDEF08577.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

--=__PartDEF08577.1__=--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:35:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHQY-0001XF-O7; Fri, 20 Jan 2012 16:34:58 +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 1RoHQX-0001Wn-FX
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:34:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327077254!56829471!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 22444 invoked from network); 20 Jan 2012 16:34:15 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 16:34:15 -0000
Received: from mail123-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 16:34:52 +0000
Received: from mail123-ch1 (localhost [127.0.0.1])	by
	mail123-ch1-R.bigfish.com (Postfix) with ESMTP id BEDC33C047D;
	Fri, 20 Jan 2012 16:34:52 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail123-ch1 (localhost.localdomain [127.0.0.1]) by mail123-ch1
	(MessageSwitch) id 1327077291401377_7030;
	Fri, 20 Jan 2012 16:34:51 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.253])	by mail123-ch1.bigfish.com (Postfix) with ESMTP id
	5C010500044;	Fri, 20 Jan 2012 16:34:51 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 16:34:49 +0000
X-WSS-ID: 0LY3VE2-01-JCU-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 23A7B1028238;	Fri, 20 Jan 2012 10:34:49 -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, 20 Jan 2012 10:35:09 -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, 20 Jan 2012 10:34:50 -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, 20 Jan 2012
	11:34:49 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C3ECF49C0F1; Fri, 20 Jan 2012
	16:34:47 +0000 (GMT)
Message-ID: <4F199866.9060208@amd.com>
Date: Fri, 20 Jan 2012 17:37:58 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1327074280@gran.amd.com>
	<20249.37479.802666.184751@mariner.uk.xensource.com>
	<4F199485.4050304@amd.com>
	<4F19A3C2020000780006E0F7@nat28.tlf.novell.com>
In-Reply-To: <4F19A3C2020000780006E0F7@nat28.tlf.novell.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/20/2012 05:26 PM, Jan Beulich wrote:
>>>> On 20.01.12 at 17:21, Wei Wang<wei.wang2@amd.com>  wrote:
>> could you provide more info about your push test on amd machines? This
>> patch queue should not affect any amd machines that do not have iommuv2
>> hardware in it.
>
> My suspicion is that the previous set still has something in it that breaks
> if a system does not have a v2 IOMMU (or maybe no IOMMU at all). Did
> you cross check the previous series this way (apparently you didn't
> check on Intel systems, otherwise 24520:9a967990b4d2 wouldn't have
> been necessary, which allowed for the fuzzy push Ian referred to)?
>
> Jan
>
>

Hi I had tested this on old iommu systems before submission. But I can 
re-test it again. Non-iommu system will also be tested. It might take 
some in setting up an Intel machine on my side. Could Ian confirm that 
it works on Intel or not?

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 Jan 20 16:35:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:35:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHQY-0001XF-O7; Fri, 20 Jan 2012 16:34:58 +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 1RoHQX-0001Wn-FX
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:34:57 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327077254!56829471!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 22444 invoked from network); 20 Jan 2012 16:34:15 -0000
Received: from ch1ehsobe004.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.184)
	by server-4.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 16:34:15 -0000
Received: from mail123-ch1-R.bigfish.com (10.43.68.243) by
	CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 16:34:52 +0000
Received: from mail123-ch1 (localhost [127.0.0.1])	by
	mail123-ch1-R.bigfish.com (Postfix) with ESMTP id BEDC33C047D;
	Fri, 20 Jan 2012 16:34:52 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VPS-15(zzbb2dI9371I1432N98dK4015Lzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h)
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 mail123-ch1 (localhost.localdomain [127.0.0.1]) by mail123-ch1
	(MessageSwitch) id 1327077291401377_7030;
	Fri, 20 Jan 2012 16:34:51 +0000 (UTC)
Received: from CH1EHSMHS001.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.253])	by mail123-ch1.bigfish.com (Postfix) with ESMTP id
	5C010500044;	Fri, 20 Jan 2012 16:34:51 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 16:34:49 +0000
X-WSS-ID: 0LY3VE2-01-JCU-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 23A7B1028238;	Fri, 20 Jan 2012 10:34:49 -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, 20 Jan 2012 10:35:09 -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, 20 Jan 2012 10:34:50 -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, 20 Jan 2012
	11:34:49 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id C3ECF49C0F1; Fri, 20 Jan 2012
	16:34:47 +0000 (GMT)
Message-ID: <4F199866.9060208@amd.com>
Date: Fri, 20 Jan 2012 17:37:58 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <patchbomb.1327074280@gran.amd.com>
	<20249.37479.802666.184751@mariner.uk.xensource.com>
	<4F199485.4050304@amd.com>
	<4F19A3C2020000780006E0F7@nat28.tlf.novell.com>
In-Reply-To: <4F19A3C2020000780006E0F7@nat28.tlf.novell.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>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/20/2012 05:26 PM, Jan Beulich wrote:
>>>> On 20.01.12 at 17:21, Wei Wang<wei.wang2@amd.com>  wrote:
>> could you provide more info about your push test on amd machines? This
>> patch queue should not affect any amd machines that do not have iommuv2
>> hardware in it.
>
> My suspicion is that the previous set still has something in it that breaks
> if a system does not have a v2 IOMMU (or maybe no IOMMU at all). Did
> you cross check the previous series this way (apparently you didn't
> check on Intel systems, otherwise 24520:9a967990b4d2 wouldn't have
> been necessary, which allowed for the fuzzy push Ian referred to)?
>
> Jan
>
>

Hi I had tested this on old iommu systems before submission. But I can 
re-test it again. Non-iommu system will also be tested. It might take 
some in setting up an Intel machine on my side. Could Ian confirm that 
it works on Intel or not?

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 Jan 20 16:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHRD-0001dL-Fy; Fri, 20 Jan 2012 16:35:39 +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 1RoHRB-0001cQ-Qr
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:35:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327077331!11921281!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11961 invoked from network); 20 Jan 2012 16:35:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:35:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182380"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:35: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; Fri, 20 Jan 2012 16:35:30 +0000
Date: Fri, 20 Jan 2012 16:35:17 +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.1201201605370.3196@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 v6 00/27] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,
this is the sixth version of the patch series that introduces ARMv7
with virtualization extensions support in Xen.
The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
Express simulator.
See the following announce email for more informations about what we
are trying to achieve, as well as the original git history:

See http://marc.info/?l=xen-devel&m=132257857628098&w=2


The first 7 patches affect generic Xen code and are not ARM specific;
often they fix real issues, hidden in the default X86 configuration.

The following 20 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 v6:

- fix compilation after rebase;

- pull Linux'es ia64 clear_user.S;

- add David Vrabel's "support zImage kernels for dom0" two patches at
the bottom of the series.


Changes in v5:

- fix compilation after rebase;

- route interrupt 34 (peripheral timer) to dom0;

- GICD_ICFGR ... GICD_ICFGRN return 1;

- expand tabs;

- keep the diff of arch/arm/lib with Linux's equivalents small;

- check the size of the arguments of elf_load_image;


Changes in v4:

- fix arm build after rebasing on xen-unstable
87c607efbfece009360f615b2bf98959f4ea48e8;

- use ABS() in __ldivmod_helper;

- return a negative integer in case of errors in elf_load_image.


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.


David Vrabel (2):
      ARM: support zImage format kernels for dom0
      ARM: copy DTB appended to zImage

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 +
 tools/libxc/xc_dom_elfloader.c         |    8 +-
 tools/libxc/xc_hvm_build.c             |    5 +-
 xen/arch/arm/Makefile                  |   77 ++++
 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            |  173 +++++++++
 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/kernel.c                  |  192 ++++++++++
 xen/arch/arm/kernel.h                  |   37 ++
 xen/arch/arm/lib/Makefile              |    5 +
 xen/arch/arm/lib/assembler.h           |   49 +++
 xen/arch/arm/lib/bitops.h              |   87 +++++
 xen/arch/arm/lib/changebit.S           |   18 +
 xen/arch/arm/lib/clearbit.S            |   19 +
 xen/arch/arm/lib/copy_template.S       |  267 ++++++++++++++
 xen/arch/arm/lib/div64.S               |  211 +++++++++++
 xen/arch/arm/lib/findbit.S             |  198 +++++++++++
 xen/arch/arm/lib/lib1funcs.S           |  389 ++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S              |   63 ++++
 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/Makefile           |    1 +
 xen/arch/ia64/linux/README.origin      |    1 +
 xen/arch/ia64/linux/clear_user.S       |  209 +++++++++++
 xen/arch/x86/Rules.mk                  |    5 +
 xen/arch/x86/domain_build.c            |    7 +-
 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/keyhandler.c                |    1 +
 xen/common/lib.c                       |   19 +
 xen/common/libelf/libelf-dominfo.c     |    6 +
 xen/common/libelf/libelf-loader.c      |   30 ++-
 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                  |    4 +-
 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           |  236 ++++++++++++
 xen/include/asm-arm/bitops.h           |  213 +++++++++++
 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           |  125 +++++++
 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        |   14 +
 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/pci.h              |    7 +
 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               |    4 +-
 xen/include/xen/list.h                 |    1 +
 xen/include/xen/paging.h               |    2 +-
 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 ++
 146 files changed, 11206 insertions(+), 61 deletions(-)

A git branch is available here, based on xen-unstable (git CS
63fa1cf01f1cfebe9b632b663127579b7aa9edc4):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v6


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 Jan 20 16:35:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHRD-0001dL-Fy; Fri, 20 Jan 2012 16:35:39 +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 1RoHRB-0001cQ-Qr
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:35:38 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327077331!11921281!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11961 invoked from network); 20 Jan 2012 16:35:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:35:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182380"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:35: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; Fri, 20 Jan 2012 16:35:30 +0000
Date: Fri, 20 Jan 2012 16:35:17 +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.1201201605370.3196@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 v6 00/27] xen: ARMv7 with virtualization
	extensions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello everyone,
this is the sixth version of the patch series that introduces ARMv7
with virtualization extensions support in Xen.
The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile
Express simulator.
See the following announce email for more informations about what we
are trying to achieve, as well as the original git history:

See http://marc.info/?l=xen-devel&m=132257857628098&w=2


The first 7 patches affect generic Xen code and are not ARM specific;
often they fix real issues, hidden in the default X86 configuration.

The following 20 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 v6:

- fix compilation after rebase;

- pull Linux'es ia64 clear_user.S;

- add David Vrabel's "support zImage kernels for dom0" two patches at
the bottom of the series.


Changes in v5:

- fix compilation after rebase;

- route interrupt 34 (peripheral timer) to dom0;

- GICD_ICFGR ... GICD_ICFGRN return 1;

- expand tabs;

- keep the diff of arch/arm/lib with Linux's equivalents small;

- check the size of the arguments of elf_load_image;


Changes in v4:

- fix arm build after rebasing on xen-unstable
87c607efbfece009360f615b2bf98959f4ea48e8;

- use ABS() in __ldivmod_helper;

- return a negative integer in case of errors in elf_load_image.


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.


David Vrabel (2):
      ARM: support zImage format kernels for dom0
      ARM: copy DTB appended to zImage

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 +
 tools/libxc/xc_dom_elfloader.c         |    8 +-
 tools/libxc/xc_hvm_build.c             |    5 +-
 xen/arch/arm/Makefile                  |   77 ++++
 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            |  173 +++++++++
 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/kernel.c                  |  192 ++++++++++
 xen/arch/arm/kernel.h                  |   37 ++
 xen/arch/arm/lib/Makefile              |    5 +
 xen/arch/arm/lib/assembler.h           |   49 +++
 xen/arch/arm/lib/bitops.h              |   87 +++++
 xen/arch/arm/lib/changebit.S           |   18 +
 xen/arch/arm/lib/clearbit.S            |   19 +
 xen/arch/arm/lib/copy_template.S       |  267 ++++++++++++++
 xen/arch/arm/lib/div64.S               |  211 +++++++++++
 xen/arch/arm/lib/findbit.S             |  198 +++++++++++
 xen/arch/arm/lib/lib1funcs.S           |  389 ++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S              |   63 ++++
 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/Makefile           |    1 +
 xen/arch/ia64/linux/README.origin      |    1 +
 xen/arch/ia64/linux/clear_user.S       |  209 +++++++++++
 xen/arch/x86/Rules.mk                  |    5 +
 xen/arch/x86/domain_build.c            |    7 +-
 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/keyhandler.c                |    1 +
 xen/common/lib.c                       |   19 +
 xen/common/libelf/libelf-dominfo.c     |    6 +
 xen/common/libelf/libelf-loader.c      |   30 ++-
 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                  |    4 +-
 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           |  236 ++++++++++++
 xen/include/asm-arm/bitops.h           |  213 +++++++++++
 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           |  125 +++++++
 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        |   14 +
 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/pci.h              |    7 +
 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               |    4 +-
 xen/include/xen/list.h                 |    1 +
 xen/include/xen/paging.h               |    2 +-
 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 ++
 146 files changed, 11206 insertions(+), 61 deletions(-)

A git branch is available here, based on xen-unstable (git CS
63fa1cf01f1cfebe9b632b663127579b7aa9edc4):

git://xenbits.xen.org/people/sstabellini/xen-unstable.git arm-v6


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 Jan 20 16:36:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHS4-0001mr-5u; Fri, 20 Jan 2012 16:36:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHS3-0001ma-95
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327077346!61099943!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22467 invoked from network); 20 Jan 2012 16:35:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:35:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442408"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0J016147;
	Fri, 20 Jan 2012 08:36:15 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:49 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 01/27] 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

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 52a63ef..1100517 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 c0b0f88..b1be8c1 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -60,6 +60,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 Jan 20 16:36:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHS4-0001mr-5u; Fri, 20 Jan 2012 16:36:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHS3-0001ma-95
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327077346!61099943!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22467 invoked from network); 20 Jan 2012 16:35:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:35:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442408"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0J016147;
	Fri, 20 Jan 2012 08:36:15 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:49 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 01/27] 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

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 52a63ef..1100517 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 c0b0f88..b1be8c1 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -60,6 +60,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 Jan 20 16:36:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSA-0001oJ-Jh; Fri, 20 Jan 2012 16:36: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 1RoHS8-0001nf-L1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327077346!61099943!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22733 invoked from network); 20 Jan 2012 16:35:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:35:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442428"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0N016147;
	Fri, 20 Jan 2012 08:36:22 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:53 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 05/27] 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

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 v6:

- pull Linux'es ia64 clear_user.S.


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>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 xen/arch/ia64/linux/Makefile           |    1 +
 xen/arch/ia64/linux/README.origin      |    1 +
 xen/arch/ia64/linux/clear_user.S       |  209 ++++++++++++++++++++++++++++++++
 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 ++++
 12 files changed, 527 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/ia64/linux/clear_user.S

diff --git a/xen/arch/ia64/linux/Makefile b/xen/arch/ia64/linux/Makefile
index 10ebbfc..6a3704b 100644
--- a/xen/arch/ia64/linux/Makefile
+++ b/xen/arch/ia64/linux/Makefile
@@ -4,6 +4,7 @@ subdir-y += sn
 
 obj-y += bitop.o
 obj-y += clear_page.o
+obj-y += clear_user.o
 obj-y += copy_page_mck.o
 obj-y += efi_stub.o
 obj-y += extable.o
diff --git a/xen/arch/ia64/linux/README.origin b/xen/arch/ia64/linux/README.origin
index 4dc96d3..3727fe5 100644
--- a/xen/arch/ia64/linux/README.origin
+++ b/xen/arch/ia64/linux/README.origin
@@ -15,6 +15,7 @@ pcdp.h			-> linux/drivers/firmware/pcdp.h
 
 bitop.c			-> linux/arch/ia64/lib/bitop.c
 clear_page.S		-> linux/arch/ia64/lib/clear_page.S
+clear_user.S		-> linux/arch/ia64/lib/clear_user.S
 copy_page_mck.S		-> linux/arch/ia64/lib/copy_page_mck.S
 flush.S			-> linux/arch/ia64/lib/flush.S
 idiv32.S		-> linux/arch/ia64/lib/idiv32.S
diff --git a/xen/arch/ia64/linux/clear_user.S b/xen/arch/ia64/linux/clear_user.S
new file mode 100644
index 0000000..eecd857
--- /dev/null
+++ b/xen/arch/ia64/linux/clear_user.S
@@ -0,0 +1,209 @@
+/*
+ * This routine clears to zero a linear memory buffer in user space.
+ *
+ * Inputs:
+ *	in0:	address of buffer
+ *	in1:	length of buffer in bytes
+ * Outputs:
+ *	r8:	number of bytes that didn't get cleared due to a fault
+ *
+ * Copyright (C) 1998, 1999, 2001 Hewlett-Packard Co
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ */
+
+#include <asm/asmmacro.h>
+
+//
+// arguments
+//
+#define buf		r32
+#define len		r33
+
+//
+// local registers
+//
+#define cnt		r16
+#define buf2		r17
+#define saved_lc	r18
+#define saved_pfs	r19
+#define tmp		r20
+#define len2		r21
+#define len3		r22
+
+//
+// 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 01c1411..ece312d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2390,6 +2390,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)
 {
@@ -2476,6 +2566,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 Fri Jan 20 16:36:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSA-0001oJ-Jh; Fri, 20 Jan 2012 16:36: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 1RoHS8-0001nf-L1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327077346!61099943!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22733 invoked from network); 20 Jan 2012 16:35:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:35:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442428"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0N016147;
	Fri, 20 Jan 2012 08:36:22 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:53 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 05/27] 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

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 v6:

- pull Linux'es ia64 clear_user.S.


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>
Acked-by: Jan Beulich <JBeulich@suse.com>
---
 xen/arch/ia64/linux/Makefile           |    1 +
 xen/arch/ia64/linux/README.origin      |    1 +
 xen/arch/ia64/linux/clear_user.S       |  209 ++++++++++++++++++++++++++++++++
 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 ++++
 12 files changed, 527 insertions(+), 0 deletions(-)
 create mode 100644 xen/arch/ia64/linux/clear_user.S

diff --git a/xen/arch/ia64/linux/Makefile b/xen/arch/ia64/linux/Makefile
index 10ebbfc..6a3704b 100644
--- a/xen/arch/ia64/linux/Makefile
+++ b/xen/arch/ia64/linux/Makefile
@@ -4,6 +4,7 @@ subdir-y += sn
 
 obj-y += bitop.o
 obj-y += clear_page.o
+obj-y += clear_user.o
 obj-y += copy_page_mck.o
 obj-y += efi_stub.o
 obj-y += extable.o
diff --git a/xen/arch/ia64/linux/README.origin b/xen/arch/ia64/linux/README.origin
index 4dc96d3..3727fe5 100644
--- a/xen/arch/ia64/linux/README.origin
+++ b/xen/arch/ia64/linux/README.origin
@@ -15,6 +15,7 @@ pcdp.h			-> linux/drivers/firmware/pcdp.h
 
 bitop.c			-> linux/arch/ia64/lib/bitop.c
 clear_page.S		-> linux/arch/ia64/lib/clear_page.S
+clear_user.S		-> linux/arch/ia64/lib/clear_user.S
 copy_page_mck.S		-> linux/arch/ia64/lib/copy_page_mck.S
 flush.S			-> linux/arch/ia64/lib/flush.S
 idiv32.S		-> linux/arch/ia64/lib/idiv32.S
diff --git a/xen/arch/ia64/linux/clear_user.S b/xen/arch/ia64/linux/clear_user.S
new file mode 100644
index 0000000..eecd857
--- /dev/null
+++ b/xen/arch/ia64/linux/clear_user.S
@@ -0,0 +1,209 @@
+/*
+ * This routine clears to zero a linear memory buffer in user space.
+ *
+ * Inputs:
+ *	in0:	address of buffer
+ *	in1:	length of buffer in bytes
+ * Outputs:
+ *	r8:	number of bytes that didn't get cleared due to a fault
+ *
+ * Copyright (C) 1998, 1999, 2001 Hewlett-Packard Co
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ */
+
+#include <asm/asmmacro.h>
+
+//
+// arguments
+//
+#define buf		r32
+#define len		r33
+
+//
+// local registers
+//
+#define cnt		r16
+#define buf2		r17
+#define saved_lc	r18
+#define saved_pfs	r19
+#define tmp		r20
+#define len2		r21
+#define len3		r22
+
+//
+// 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 01c1411..ece312d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2390,6 +2390,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)
 {
@@ -2476,6 +2566,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 Fri Jan 20 16:36:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSB-0001ok-5z; Fri, 20 Jan 2012 16:36: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 1RoHS9-0001nI-LT
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327077346!61099943!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22641 invoked from network); 20 Jan 2012 16:35:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:35:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442426"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:32 -0500
Received: from smtp01.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, 20 Jan 2012 11:36: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 q0KGaF0M016147;
	Fri, 20 Jan 2012 08:36:21 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:52 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 04/27] 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

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.


Changes in v4:

- use ABS().


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..e9d0637 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 = ABS(a);
+    ub = ABS(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 Jan 20 16:36:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSB-0001ok-5z; Fri, 20 Jan 2012 16:36: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 1RoHS9-0001nI-LT
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327077346!61099943!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22641 invoked from network); 20 Jan 2012 16:35:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:35:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442426"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:32 -0500
Received: from smtp01.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, 20 Jan 2012 11:36: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 q0KGaF0M016147;
	Fri, 20 Jan 2012 08:36:21 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:52 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 04/27] 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

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.


Changes in v4:

- use ABS().


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..e9d0637 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 = ABS(a);
+    ub = ABS(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 Jan 20 16:36:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSH-0001re-E8; Fri, 20 Jan 2012 16:36:45 +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 1RoHSF-0001oE-My
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16475 invoked from network); 20 Jan 2012 16:36:37 -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;
	20 Jan 2012 16:36:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114046"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0L016147;
	Fri, 20 Jan 2012 08:36:19 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:51 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 03/27] 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

- 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;

- guest_physmap_add_page should be ((void)0).


Changes in v4:

- fix guest_physmap_add_page;


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/paging.h      |    2 +-
 xen/include/xen/time.h        |    1 +
 7 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1100517..3c6c5af 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -635,7 +635,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
 
     xfree(d->mem_event);
 
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 65825b4..ac2be2a 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 e8f8211..18d0a05 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -48,6 +48,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/paging.h b/xen/include/xen/paging.h
index 213ece4..123cc58 100644
--- a/xen/include/xen/paging.h
+++ b/xen/include/xen/paging.h
@@ -18,7 +18,7 @@
 
 #define paging_mode_translate(d)              (0)
 #define paging_mode_external(d)               (0)
-#define guest_physmap_add_page(d, p, m, o)    (0)
+#define guest_physmap_add_page(d, p, m, o)    ((void)0)
 #define guest_physmap_remove_page(d, p, m, o) ((void)0)
 
 #endif
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 Jan 20 16:36:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSH-0001re-E8; Fri, 20 Jan 2012 16:36:45 +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 1RoHSF-0001oE-My
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16475 invoked from network); 20 Jan 2012 16:36:37 -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;
	20 Jan 2012 16:36:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114046"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0L016147;
	Fri, 20 Jan 2012 08:36:19 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:51 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 03/27] 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

- 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;

- guest_physmap_add_page should be ((void)0).


Changes in v4:

- fix guest_physmap_add_page;


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/paging.h      |    2 +-
 xen/include/xen/time.h        |    1 +
 7 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1100517..3c6c5af 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -635,7 +635,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
 
     xfree(d->mem_event);
 
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 65825b4..ac2be2a 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 e8f8211..18d0a05 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -48,6 +48,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/paging.h b/xen/include/xen/paging.h
index 213ece4..123cc58 100644
--- a/xen/include/xen/paging.h
+++ b/xen/include/xen/paging.h
@@ -18,7 +18,7 @@
 
 #define paging_mode_translate(d)              (0)
 #define paging_mode_external(d)               (0)
-#define guest_physmap_add_page(d, p, m, o)    (0)
+#define guest_physmap_add_page(d, p, m, o)    ((void)0)
 #define guest_physmap_remove_page(d, p, m, o) ((void)0)
 
 #endif
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 Jan 20 16:36:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSF-0001qV-KF; Fri, 20 Jan 2012 16:36:43 +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 1RoHSE-0001ns-DP
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16415 invoked from network); 20 Jan 2012 16:36:35 -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;
	20 Jan 2012 16:36:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114043"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0Q016147;
	Fri, 20 Jan 2012 08:36:27 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:56 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 08/27] 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

Include few missing header files; 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 |    4 +++-
 2 files changed, 5 insertions(+), 2 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 15f1806..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)
 {
-- 
1.7.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 Jan 20 16:36:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSF-0001qV-KF; Fri, 20 Jan 2012 16:36:43 +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 1RoHSE-0001ns-DP
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16415 invoked from network); 20 Jan 2012 16:36:35 -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;
	20 Jan 2012 16:36:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114043"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0Q016147;
	Fri, 20 Jan 2012 08:36:27 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:56 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 08/27] 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

Include few missing header files; 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 |    4 +++-
 2 files changed, 5 insertions(+), 2 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 15f1806..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)
 {
-- 
1.7.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 Jan 20 16:36:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSL-0001ua-Ql; Fri, 20 Jan 2012 16:36: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 1RoHSJ-0001q1-WC
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16786 invoked from network); 20 Jan 2012 16:36:41 -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;
	20 Jan 2012 16:36:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114048"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0O016147;
	Fri, 20 Jan 2012 08:36:23 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:54 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 06/27] 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

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 v5:

- check the size of the arguments of elf_load_image.


Changes in v4:

- return a negative integer in case of errors in elf_load_image;
propagate errors to elf_load_binary and further up the call chain.


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>
---
 tools/libxc/xc_dom_elfloader.c    |    8 +++++++-
 tools/libxc/xc_hvm_build.c        |    5 +++--
 xen/arch/x86/domain_build.c       |    7 ++++++-
 xen/common/libelf/libelf-loader.c |   30 +++++++++++++++++++++++++++---
 xen/include/xen/libelf.h          |    2 +-
 5 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 4d7b8e0..2e69559 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -310,9 +310,15 @@ static int xc_dom_parse_elf_kernel(struct xc_dom_image *dom)
 static int xc_dom_load_elf_kernel(struct xc_dom_image *dom)
 {
     struct elf_binary *elf = dom->private_loader;
+    int rc;
 
     elf->dest = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
-    elf_load_binary(elf);
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+    {
+        DOMPRINTF("%s: failed to load elf binary", __FUNCTION__);
+        return rc;
+    }
     if ( dom->parms.bsd_symtab )
         xc_dom_load_elf_symtab(dom, elf, 1);
     return 0;
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 9831bab..1fa5658 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -109,8 +109,9 @@ static int loadelfimage(
     elf->dest += elf->pstart & (PAGE_SIZE - 1);
 
     /* Load the initial elf image. */
-    elf_load_binary(elf);
-    rc = 0;
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
 
     munmap(elf->dest, pages << PAGE_SHIFT);
     elf->dest = NULL;
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 1b3818f..b3c5d4c 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -903,7 +903,12 @@ int __init construct_dom0(
 
     /* Copy the OS image and free temporary buffer. */
     elf.dest = (void*)vkern_start;
-    elf_load_binary(&elf);
+    rc = elf_load_binary(&elf);
+    if ( rc < 0 )
+    {
+        printk("Failed to load the kernel binary\n");
+        return rc;
+    }
     bootstrap_map(NULL);
 
     if ( UNSET_ADDR != parms.virt_hypercall )
diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..ab58b8b 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,34 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+    return 0;
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    int rc;
+    if ( filesz > ULONG_MAX || memsz > ULONG_MAX )
+        return -1;
+    rc = raw_copy_to_guest(dst, src, filesz);
+    if ( rc != 0 )
+        return -1;
+    rc = raw_clear_guest(dst + filesz, memsz - filesz);
+    if ( rc != 0 )
+        return -1;
+    return 0;
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -237,7 +260,7 @@ void elf_parse_binary(struct elf_binary *elf)
             __FUNCTION__, elf->pstart, elf->pend);
 }
 
-void elf_load_binary(struct elf_binary *elf)
+int elf_load_binary(struct elf_binary *elf)
 {
     const elf_phdr *phdr;
     uint64_t i, count, paddr, offset, filesz, memsz;
@@ -256,11 +279,12 @@ 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);
+        if ( elf_load_image(dest, elf->image + offset, filesz, memsz) != 0 )
+            return -1;
     }
 
     elf_load_bsdsyms(elf);
+    return 0;
 }
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d77bda6 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -198,7 +198,7 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback*,
 #endif
 
 void elf_parse_binary(struct elf_binary *elf);
-void elf_load_binary(struct elf_binary *elf);
+int elf_load_binary(struct elf_binary *elf);
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr);
 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 Fri Jan 20 16:36:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSL-0001ua-Ql; Fri, 20 Jan 2012 16:36: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 1RoHSJ-0001q1-WC
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16786 invoked from network); 20 Jan 2012 16:36:41 -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;
	20 Jan 2012 16:36:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114048"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0O016147;
	Fri, 20 Jan 2012 08:36:23 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:54 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 06/27] 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

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 v5:

- check the size of the arguments of elf_load_image.


Changes in v4:

- return a negative integer in case of errors in elf_load_image;
propagate errors to elf_load_binary and further up the call chain.


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>
---
 tools/libxc/xc_dom_elfloader.c    |    8 +++++++-
 tools/libxc/xc_hvm_build.c        |    5 +++--
 xen/arch/x86/domain_build.c       |    7 ++++++-
 xen/common/libelf/libelf-loader.c |   30 +++++++++++++++++++++++++++---
 xen/include/xen/libelf.h          |    2 +-
 5 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 4d7b8e0..2e69559 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -310,9 +310,15 @@ static int xc_dom_parse_elf_kernel(struct xc_dom_image *dom)
 static int xc_dom_load_elf_kernel(struct xc_dom_image *dom)
 {
     struct elf_binary *elf = dom->private_loader;
+    int rc;
 
     elf->dest = xc_dom_seg_to_ptr(dom, &dom->kernel_seg);
-    elf_load_binary(elf);
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+    {
+        DOMPRINTF("%s: failed to load elf binary", __FUNCTION__);
+        return rc;
+    }
     if ( dom->parms.bsd_symtab )
         xc_dom_load_elf_symtab(dom, elf, 1);
     return 0;
diff --git a/tools/libxc/xc_hvm_build.c b/tools/libxc/xc_hvm_build.c
index 9831bab..1fa5658 100644
--- a/tools/libxc/xc_hvm_build.c
+++ b/tools/libxc/xc_hvm_build.c
@@ -109,8 +109,9 @@ static int loadelfimage(
     elf->dest += elf->pstart & (PAGE_SIZE - 1);
 
     /* Load the initial elf image. */
-    elf_load_binary(elf);
-    rc = 0;
+    rc = elf_load_binary(elf);
+    if ( rc < 0 )
+        PERROR("Failed to load elf binary\n");
 
     munmap(elf->dest, pages << PAGE_SHIFT);
     elf->dest = NULL;
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 1b3818f..b3c5d4c 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -903,7 +903,12 @@ int __init construct_dom0(
 
     /* Copy the OS image and free temporary buffer. */
     elf.dest = (void*)vkern_start;
-    elf_load_binary(&elf);
+    rc = elf_load_binary(&elf);
+    if ( rc < 0 )
+    {
+        printk("Failed to load the kernel binary\n");
+        return rc;
+    }
     bootstrap_map(NULL);
 
     if ( UNSET_ADDR != parms.virt_hypercall )
diff --git a/xen/common/libelf/libelf-loader.c b/xen/common/libelf/libelf-loader.c
index 1ccf7d3..ab58b8b 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -107,11 +107,34 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback *log_callback,
     elf->log_caller_data = log_caller_data;
     elf->verbose = verbose;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    memcpy(dst, src, filesz);
+    memset(dst + filesz, 0, memsz - filesz);
+    return 0;
+}
 #else
+#include <asm/guest_access.h>
+
 void elf_set_verbose(struct elf_binary *elf)
 {
     elf->verbose = 1;
 }
+
+static int elf_load_image(void *dst, const void *src, uint64_t filesz, uint64_t memsz)
+{
+    int rc;
+    if ( filesz > ULONG_MAX || memsz > ULONG_MAX )
+        return -1;
+    rc = raw_copy_to_guest(dst, src, filesz);
+    if ( rc != 0 )
+        return -1;
+    rc = raw_clear_guest(dst + filesz, memsz - filesz);
+    if ( rc != 0 )
+        return -1;
+    return 0;
+}
 #endif
 
 /* Calculate the required additional kernel space for the elf image */
@@ -237,7 +260,7 @@ void elf_parse_binary(struct elf_binary *elf)
             __FUNCTION__, elf->pstart, elf->pend);
 }
 
-void elf_load_binary(struct elf_binary *elf)
+int elf_load_binary(struct elf_binary *elf)
 {
     const elf_phdr *phdr;
     uint64_t i, count, paddr, offset, filesz, memsz;
@@ -256,11 +279,12 @@ 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);
+        if ( elf_load_image(dest, elf->image + offset, filesz, memsz) != 0 )
+            return -1;
     }
 
     elf_load_bsdsyms(elf);
+    return 0;
 }
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr)
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 9de84eb..d77bda6 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -198,7 +198,7 @@ void elf_set_log(struct elf_binary *elf, elf_log_callback*,
 #endif
 
 void elf_parse_binary(struct elf_binary *elf);
-void elf_load_binary(struct elf_binary *elf);
+int elf_load_binary(struct elf_binary *elf);
 
 void *elf_get_ptr(struct elf_binary *elf, unsigned long addr);
 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 Fri Jan 20 16:36:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSH-0001rJ-1O; Fri, 20 Jan 2012 16:36:45 +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 1RoHSF-0001o6-3v
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16452 invoked from network); 20 Jan 2012 16:36:36 -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;
	20 Jan 2012 16:36:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114045"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36:34 -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 q0KGaF0K016147;
	Fri, 20 Jan 2012 08:36:17 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:50 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 02/27] 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

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/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 +
 13 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d6ae09b..14ab515 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 34a49db..58d5e1f 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/keyhandler.c b/xen/common/keyhandler.c
index f22fe05..1051a86 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 c796137..8d45439 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 2fb2309..92d1a4f 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 8081760..76c0b06 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -25,6 +25,7 @@
 #define __XEN_GRANT_TABLE_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 dbfb8b3..567cd36 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -13,6 +13,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 <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.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 5529b14..4a35760 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -10,6 +10,7 @@
 #define __XEN_TMEM_XEN_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 Jan 20 16:36:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSH-0001rJ-1O; Fri, 20 Jan 2012 16:36:45 +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 1RoHSF-0001o6-3v
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16452 invoked from network); 20 Jan 2012 16:36:36 -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;
	20 Jan 2012 16:36:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114045"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36:34 -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 q0KGaF0K016147;
	Fri, 20 Jan 2012 08:36:17 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:50 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 02/27] 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

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/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 +
 13 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d6ae09b..14ab515 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 34a49db..58d5e1f 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/keyhandler.c b/xen/common/keyhandler.c
index f22fe05..1051a86 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 c796137..8d45439 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 2fb2309..92d1a4f 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 8081760..76c0b06 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -25,6 +25,7 @@
 #define __XEN_GRANT_TABLE_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 dbfb8b3..567cd36 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -13,6 +13,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 <xen/wait.h>
 #include <public/xen.h>
 #include <public/domctl.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 5529b14..4a35760 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -10,6 +10,7 @@
 #define __XEN_TMEM_XEN_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 Jan 20 16:36:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSO-0001wz-Fx; Fri, 20 Jan 2012 16:36:52 +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 1RoHSM-0001rS-Nf
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26672 invoked from network); 20 Jan 2012 16:36:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442446"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0P016147;
	Fri, 20 Jan 2012 08:36:25 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:55 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 07/27] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

- 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 9fc6d42..65275af 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,11 @@
 
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1d85e65..9249845 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += grant_table.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
-obj-y += kexec.o
+obj-$(HAS_KEXEC) += kexec.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index e356e86..b18ef5d 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -6,7 +6,9 @@
 #include <xen/delay.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <public/sched.h>
 
@@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
     case SHUTDOWN_watchdog:
     {
         printk("Domain 0 shutdown: watchdog rebooting machine.\n");
+#ifdef CONFIG_KEXEC
         kexec_crash();
+#endif
         machine_restart(0);
         break; /* not reached */
     }
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb4fb61..7239375 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
-subdir-y += cpufreq
-subdir-y += pci
-subdir-y += passthrough
+subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(HAS_PCI) += pci
+subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ded9a94..19250c8 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,3 +1,3 @@
 obj-y += console.o
-obj-y += ns16550.o
+obj-$(HAS_NS16550) += ns16550.o
 obj-y += serial.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..19f021c 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -22,7 +22,9 @@
 #include <xen/guest_access.h>
 #include <xen/shutdown.h>
 #include <xen/vga.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <asm/div64.h>
 #include <xen/hypercall.h> /* for do_console_io */
@@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
+#ifdef CONFIG_KEXEC
     kexec_crash();
+#endif
 
     if ( opt_noreboot )
     {
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index 0173487..6e9fc98 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_KEXEC 1
 #define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 18d0a05..28f5e29 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -49,6 +49,7 @@
 #define CONFIG_HOTPLUG_CPU 1
 
 #define CONFIG_XENOPROF 1
+#define CONFIG_KEXEC 1
 
 #define HZ 100
 
-- 
1.7.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 Jan 20 16:36:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSO-0001wz-Fx; Fri, 20 Jan 2012 16:36:52 +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 1RoHSM-0001rS-Nf
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26672 invoked from network); 20 Jan 2012 16:36:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442446"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0P016147;
	Fri, 20 Jan 2012 08:36:25 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:55 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 07/27] xen/common/Makefile: introduce
	HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

- 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 9fc6d42..65275af 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -3,6 +3,11 @@
 
 HAS_ACPI := y
 HAS_VGA  := y
+HAS_CPUFREQ := y
+HAS_PCI := y
+HAS_PASSTHROUGH := y
+HAS_NS16550 := y
+HAS_KEXEC := y
 xenoprof := y
 
 #
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1d85e65..9249845 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,7 +8,7 @@ obj-y += grant_table.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += keyhandler.o
-obj-y += kexec.o
+obj-$(HAS_KEXEC) += kexec.o
 obj-y += lib.o
 obj-y += memory.o
 obj-y += multicall.o
diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
index e356e86..b18ef5d 100644
--- a/xen/common/shutdown.c
+++ b/xen/common/shutdown.c
@@ -6,7 +6,9 @@
 #include <xen/delay.h>
 #include <xen/shutdown.h>
 #include <xen/console.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <public/sched.h>
 
@@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
     case SHUTDOWN_watchdog:
     {
         printk("Domain 0 shutdown: watchdog rebooting machine.\n");
+#ifdef CONFIG_KEXEC
         kexec_crash();
+#endif
         machine_restart(0);
         break; /* not reached */
     }
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index eb4fb61..7239375 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -1,6 +1,6 @@
 subdir-y += char
-subdir-y += cpufreq
-subdir-y += pci
-subdir-y += passthrough
+subdir-$(HAS_CPUFREQ) += cpufreq
+subdir-$(HAS_PCI) += pci
+subdir-$(HAS_PASSTHROUGH) += passthrough
 subdir-$(HAS_ACPI) += acpi
 subdir-$(HAS_VGA) += video
diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
index ded9a94..19250c8 100644
--- a/xen/drivers/char/Makefile
+++ b/xen/drivers/char/Makefile
@@ -1,3 +1,3 @@
 obj-y += console.o
-obj-y += ns16550.o
+obj-$(HAS_NS16550) += ns16550.o
 obj-y += serial.o
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..19f021c 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -22,7 +22,9 @@
 #include <xen/guest_access.h>
 #include <xen/shutdown.h>
 #include <xen/vga.h>
+#ifdef CONFIG_KEXEC
 #include <xen/kexec.h>
+#endif
 #include <asm/debugger.h>
 #include <asm/div64.h>
 #include <xen/hypercall.h> /* for do_console_io */
@@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
 
     debugger_trap_immediate();
 
+#ifdef CONFIG_KEXEC
     kexec_crash();
+#endif
 
     if ( opt_noreboot )
     {
diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
index 0173487..6e9fc98 100644
--- a/xen/include/asm-ia64/config.h
+++ b/xen/include/asm-ia64/config.h
@@ -20,6 +20,7 @@
 #define CONFIG_EFI
 #define CONFIG_EFI_PCDP
 #define CONFIG_SERIAL_SGI_L1_CONSOLE
+#define CONFIG_KEXEC 1
 #define CONFIG_XENOPROF 1
 
 #define CONFIG_XEN_SMP
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 18d0a05..28f5e29 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -49,6 +49,7 @@
 #define CONFIG_HOTPLUG_CPU 1
 
 #define CONFIG_XENOPROF 1
+#define CONFIG_KEXEC 1
 
 #define HZ 100
 
-- 
1.7.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 Jan 20 16:36:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSO-0001xY-Uf; Fri, 20 Jan 2012 16:36:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSN-0001ry-8N
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16806 invoked from network); 20 Jan 2012 16:36:44 -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;
	20 Jan 2012 16:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114050"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0T016147;
	Fri, 20 Jan 2012 08:36:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:59 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 11/27] 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

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 Jan 20 16:36:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSO-0001xY-Uf; Fri, 20 Jan 2012 16:36:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSN-0001ry-8N
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16806 invoked from network); 20 Jan 2012 16:36:44 -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;
	20 Jan 2012 16:36:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114050"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0T016147;
	Fri, 20 Jan 2012 08:36:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:59 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 11/27] 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

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 Jan 20 16:36:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSQ-0001zX-Hz; Fri, 20 Jan 2012 16:36:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSO-0001sk-Fk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26681 invoked from network); 20 Jan 2012 16:36:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442450"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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; Fri, 20 Jan 2012 11:36: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 q0KGaF0U016147;
	Fri, 20 Jan 2012 08:36:33 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:00 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 12/27] 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

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..4bb54ca
--- /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 Jan 20 16:36:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:36:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSQ-0001zX-Hz; Fri, 20 Jan 2012 16:36:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSO-0001sk-Fk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26681 invoked from network); 20 Jan 2012 16:36:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442450"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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; Fri, 20 Jan 2012 11:36: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 q0KGaF0U016147;
	Fri, 20 Jan 2012 08:36:33 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:00 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 12/27] 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

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..4bb54ca
--- /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 Jan 20 16:37:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSS-00022Q-WD; Fri, 20 Jan 2012 16:36:57 +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 1RoHSQ-0001uA-HE
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26771 invoked from network); 20 Jan 2012 16:36:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442453"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0V016147;
	Fri, 20 Jan 2012 08:36:34 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:01 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 13/27] 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

Functions to build dom0: memory allocation, p2m construction, mappings
of the MMIO regions, ATAG setup.


Changes in v5:

- route interrupt 34 (peripheral timer) to dom0.

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>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c        |  213 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 4 files changed, 222 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..f73df85
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,213 @@
+#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, 34, "timer0");
+    /*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 d77bda6..0ff8b5b 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 Jan 20 16:37:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSS-00022Q-WD; Fri, 20 Jan 2012 16:36:57 +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 1RoHSQ-0001uA-HE
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26771 invoked from network); 20 Jan 2012 16:36:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442453"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0V016147;
	Fri, 20 Jan 2012 08:36:34 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:01 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 13/27] 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

Functions to build dom0: memory allocation, p2m construction, mappings
of the MMIO regions, ATAG setup.


Changes in v5:

- route interrupt 34 (peripheral timer) to dom0.

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>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/domain_build.c        |  213 ++++++++++++++++++++++++++++++++++++
 xen/common/libelf/libelf-dominfo.c |    6 +
 xen/include/asm-arm/setup.h        |    2 +
 xen/include/xen/libelf.h           |    2 +-
 4 files changed, 222 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..f73df85
--- /dev/null
+++ b/xen/arch/arm/domain_build.c
@@ -0,0 +1,213 @@
+#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, 34, "timer0");
+    /*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 d77bda6..0ff8b5b 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 Jan 20 16:37:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSU-00024l-IV; Fri, 20 Jan 2012 16:36: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 1RoHSS-0001va-C1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16918 invoked from network); 20 Jan 2012 16:36:49 -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;
	20 Jan 2012 16:36:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114052"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0S016147;
	Fri, 20 Jan 2012 08:36:30 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:58 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 10/27] 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

Bit manipulation, division and memcpy & friends implementations for the
ARM architecture, shamelessly taken from Linux.

Changes in v5:

- keep the diff with Linux small for this library.

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        |   87 +++++++++
 xen/arch/arm/lib/changebit.S     |   18 ++
 xen/arch/arm/lib/clearbit.S      |   19 ++
 xen/arch/arm/lib/copy_template.S |  267 ++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  211 +++++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  198 +++++++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  389 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   63 ++++++
 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/include/asm-arm/config.h     |    3 +
 18 files changed, 1837 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..689f2e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,87 @@
+#include <xen/config.h>
+
+#if __LINUX_ARM_ARCH__ >= 6
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
+#else
+	.macro	bitop, name, instr
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r2, r0, #31
+	mov	r0, r0, lsr #5
+	mov	r3, #1
+	mov	r3, r3, lsl r2
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]
+	\instr	r2, r2, r3
+	str	r2, [r1, r0, lsl #2]
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
+
+/**
+ * testop - implement a test_and_xxx_bit operation.
+ * @instr: operational instruction
+ * @store: store instruction
+ *
+ * Note: we can trivially conditionalise the store instruction
+ * to avoid dirtying the data cache.
+ */
+	.macro	testop, name, instr, store
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r3, r0, #31
+	mov	r0, r0, lsr #5
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]!
+	mov	r0, #1
+	tst	r2, r0, lsl r3
+	\instr	r2, r2, r0, lsl r3
+	\store	r2, [r1]
+	moveq	r0, #0
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
+#endif
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..805e3f8
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,267 @@
+/*
+ *  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..83a5f22
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,211 @@
+/*
+ *  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"
+	
+#ifdef __ARMEB__
+#define xh r0
+#define xl r1
+#define yh r2
+#define yl r3
+#else
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+#endif
+
+/*
+ * __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)
+UNWIND(.fnstart)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ 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.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+#else
+
+	mov	yl, r4
+	mov	ip, #1
+1:	cmp	yl, #0x80000000
+	cmpcc	yl, xh
+	movcc	yl, yl, lsl #1
+	movcc	ip, ip, lsl #1
+	bcc	1b
+
+#endif
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ 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.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+#else
+
+7:	movs	xl, xl, lsl #1
+	mov	ip, ip, lsr #1
+	bcc	7b
+
+#endif
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+#else
+
+	mov	yl, r4
+	cmp	r4, #(1 << 16)
+	mov	ip, #0
+	movhs	yl, yl, lsr #16
+	movhs	ip, #16
+
+	cmp	yl, #(1 << 8)
+	movhs	yl, yl, lsr #8
+	addhs	ip, ip, #8
+
+	cmp	yl, #(1 << 4)
+	movhs	yl, yl, lsr #4
+	addhs	ip, ip, #4
+
+	cmp	yl, #(1 << 2)
+	addhi	ip, ip, #3
+	addls	ip, ip, yl, lsr #1
+
+#endif
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+UNWIND(.fnend)
+
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+Ldiv0_64:
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+UNWIND(.fnend)
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..2fbcc82
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,198 @@
+/*
+ *  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_le)
+		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_le)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit_le)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit_le)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit_le)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+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_le)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit_le)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit_le)
+
+#ifdef __ARMEB__
+
+ENTRY(_find_first_zero_bit_be)
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit_be)
+
+ENTRY(_find_next_zero_bit_be)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit_be)
+
+ENTRY(_find_first_bit_be)
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit_be)
+
+ENTRY(_find_next_bit_be)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit_be)
+
+#endif
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+#if __LINUX_ARM_ARCH__ >= 5
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+#else
+		tst	r3, #0x0f
+		addeq	r2, r2, #4
+		movne	r3, r3, lsl #4
+		tst	r3, #0x30
+		addeq	r2, r2, #2
+		movne	r3, r3, lsl #2
+		tst	r3, #0x40
+		addeq	r2, r2, #1
+		mov	r0, r2
+#endif
+		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..95ee312
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,389 @@
+/*
+ * 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
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+#else
+
+	@ Initially shift the divisor left 3 bits if possible,
+	@ set curbit accordingly.  This allows for curbit to be located
+	@ at the left end of each 4 bit nibbles in the division loop
+	@ to save one loop in most cases.
+	tst	\divisor, #0xe0000000
+	moveq	\divisor, \divisor, lsl #3
+	moveq	\curbit, #8
+	movne	\curbit, #1
+
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	movlo	\curbit, \curbit, lsl #4
+	blo	1b
+
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	movlo	\curbit, \curbit, lsl #1
+	blo	1b
+
+	mov	\result, #0
+
+#endif
+
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+#else
+
+	cmp	\divisor, #(1 << 16)
+	movhs	\divisor, \divisor, lsr #16
+	movhs	\order, #16
+	movlo	\order, #0
+
+	cmp	\divisor, #(1 << 8)
+	movhs	\divisor, \divisor, lsr #8
+	addhs	\order, \order, #8
+
+	cmp	\divisor, #(1 << 4)
+	movhs	\divisor, \divisor, lsr #4
+	addhs	\order, \order, #4
+
+	cmp	\divisor, #(1 << 2)
+	addhi	\order, \order, #3
+	addls	\order, \order, \divisor, lsr #1
+
+#endif
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+#else
+
+	mov	\order, #0
+
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	addlo	\order, \order, #4
+	blo	1b
+
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	addlo	\order, \order, #1
+	blo	1b
+
+#endif
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+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)
+
+#ifdef CONFIG_AEABI
+
+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_ldivmod)
+#endif
+
+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..d1ab9fb
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,63 @@
+/*
+ *  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)
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 12285dd..9294f8f 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -30,6 +30,9 @@
 
 #define asmlinkage /* Nothing needed */
 
+#define __LINUX_ARM_ARCH__ 7
+#define CONFIG_AEABI
+
 /* Linkage for ARM */
 #define __ALIGN .align 2
 #define __ALIGN_STR ".align 2"
-- 
1.7.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 Jan 20 16:37:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSU-00024l-IV; Fri, 20 Jan 2012 16:36: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 1RoHSS-0001va-C1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16918 invoked from network); 20 Jan 2012 16:36:49 -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;
	20 Jan 2012 16:36:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114052"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0S016147;
	Fri, 20 Jan 2012 08:36:30 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:58 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 10/27] 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

Bit manipulation, division and memcpy & friends implementations for the
ARM architecture, shamelessly taken from Linux.

Changes in v5:

- keep the diff with Linux small for this library.

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        |   87 +++++++++
 xen/arch/arm/lib/changebit.S     |   18 ++
 xen/arch/arm/lib/clearbit.S      |   19 ++
 xen/arch/arm/lib/copy_template.S |  267 ++++++++++++++++++++++++++
 xen/arch/arm/lib/div64.S         |  211 +++++++++++++++++++++
 xen/arch/arm/lib/findbit.S       |  198 +++++++++++++++++++
 xen/arch/arm/lib/lib1funcs.S     |  389 ++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/lib/memcpy.S        |   63 ++++++
 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/include/asm-arm/config.h     |    3 +
 18 files changed, 1837 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..689f2e8
--- /dev/null
+++ b/xen/arch/arm/lib/bitops.h
@@ -0,0 +1,87 @@
+#include <xen/config.h>
+
+#if __LINUX_ARM_ARCH__ >= 6
+	.macro	bitop, instr
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3
+1:	ldrex	r2, [r1]
+	\instr	r2, r2, r3
+	strex	r0, r2, [r1]
+	cmp	r0, #0
+	bne	1b
+	bx	lr
+	.endm
+
+	.macro	testop, instr, store
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	mov	r2, #1
+	and	r3, r0, #31		@ Get bit offset
+	mov	r0, r0, lsr #5
+	add	r1, r1, r0, lsl #2	@ Get word offset
+	mov	r3, r2, lsl r3		@ create mask
+	smp_dmb
+1:	ldrex	r2, [r1]
+	ands	r0, r2, r3		@ save old value of bit
+	\instr	r2, r2, r3		@ toggle bit
+	strex	ip, r2, [r1]
+	cmp	ip, #0
+	bne	1b
+	smp_dmb
+	cmp	r0, #0
+	movne	r0, #1
+2:	bx	lr
+	.endm
+#else
+	.macro	bitop, name, instr
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r2, r0, #31
+	mov	r0, r0, lsr #5
+	mov	r3, #1
+	mov	r3, r3, lsl r2
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]
+	\instr	r2, r2, r3
+	str	r2, [r1, r0, lsl #2]
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
+
+/**
+ * testop - implement a test_and_xxx_bit operation.
+ * @instr: operational instruction
+ * @store: store instruction
+ *
+ * Note: we can trivially conditionalise the store instruction
+ * to avoid dirtying the data cache.
+ */
+	.macro	testop, name, instr, store
+ENTRY(	\name		)
+UNWIND(	.fnstart	)
+	ands	ip, r1, #3
+	strneb	r1, [ip]		@ assert word-aligned
+	and	r3, r0, #31
+	mov	r0, r0, lsr #5
+	save_and_disable_irqs ip
+	ldr	r2, [r1, r0, lsl #2]!
+	mov	r0, #1
+	tst	r2, r0, lsl r3
+	\instr	r2, r2, r0, lsl r3
+	\store	r2, [r1]
+	moveq	r0, #0
+	restore_irqs ip
+	mov	pc, lr
+UNWIND(	.fnend		)
+ENDPROC(\name		)
+	.endm
+#endif
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..805e3f8
--- /dev/null
+++ b/xen/arch/arm/lib/copy_template.S
@@ -0,0 +1,267 @@
+/*
+ *  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..83a5f22
--- /dev/null
+++ b/xen/arch/arm/lib/div64.S
@@ -0,0 +1,211 @@
+/*
+ *  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"
+	
+#ifdef __ARMEB__
+#define xh r0
+#define xl r1
+#define yh r2
+#define yl r3
+#else
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+#endif
+
+/*
+ * __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)
+UNWIND(.fnstart)
+
+	@ Test for easy paths first.
+	subs	ip, r4, #1
+	bls	9f			@ divisor is 0 or 1
+	tst	ip, r4
+	beq	8f			@ divisor is power of 2
+
+	@ 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.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	yl, r4
+	clz	ip, xh
+	sub	yl, yl, ip
+	mov	ip, #1
+	mov	ip, ip, lsl yl
+	mov	yl, r4, lsl yl
+
+#else
+
+	mov	yl, r4
+	mov	ip, #1
+1:	cmp	yl, #0x80000000
+	cmpcc	yl, xh
+	movcc	yl, yl, lsl #1
+	movcc	ip, ip, lsl #1
+	bcc	1b
+
+#endif
+
+	@ The division loop for needed upper bit positions.
+ 	@ Break out early if dividend reaches 0.
+2:	cmp	xh, yl
+	orrcs	yh, yh, ip
+	subcss	xh, xh, yl
+	movnes	ip, ip, lsr #1
+	mov	yl, yl, lsr #1
+	bne	2b
+
+	@ 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.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	xh, xl			@ we know xh is zero here so...
+	add	xh, xh, #1
+	mov	xl, xl, lsl xh
+	mov	ip, ip, lsr xh
+
+#else
+
+7:	movs	xl, xl, lsl #1
+	mov	ip, ip, lsr #1
+	bcc	7b
+
+#endif
+
+	@ Current remainder is now 1.  It is worthless to compare with
+	@ divisor at this point since divisor can not be smaller than 3 here.
+	@ If possible, branch for another shift in the division loop.
+	@ If no bit position left then we are done.
+	movs	ip, ip, lsr #1
+	mov	xh, #1
+	bne	4b
+	mov	pc, lr
+
+8:	@ Division by a power of 2: determine what that divisor order is
+	@ then simply shift values around
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	ip, r4
+	rsb	ip, ip, #31
+
+#else
+
+	mov	yl, r4
+	cmp	r4, #(1 << 16)
+	mov	ip, #0
+	movhs	yl, yl, lsr #16
+	movhs	ip, #16
+
+	cmp	yl, #(1 << 8)
+	movhs	yl, yl, lsr #8
+	addhs	ip, ip, #8
+
+	cmp	yl, #(1 << 4)
+	movhs	yl, yl, lsr #4
+	addhs	ip, ip, #4
+
+	cmp	yl, #(1 << 2)
+	addhi	ip, ip, #3
+	addls	ip, ip, yl, lsr #1
+
+#endif
+
+	mov	yh, xh, lsr ip
+	mov	yl, xl, lsr ip
+	rsb	ip, ip, #32
+ ARM(	orr	yl, yl, xh, lsl ip	)
+ THUMB(	lsl	xh, xh, ip		)
+ THUMB(	orr	yl, yl, xh		)
+	mov	xh, xl, lsl ip
+	mov	xh, xh, lsr ip
+	mov	pc, lr
+
+	@ eq -> division by 1: obvious enough...
+9:	moveq	yl, xl
+	moveq	yh, xh
+	moveq	xh, #0
+	moveq	pc, lr
+UNWIND(.fnend)
+
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+Ldiv0_64:
+	@ Division by 0:
+	str	lr, [sp, #-8]!
+	bl	__div0
+
+	@ as wrong as it could be...
+	mov	yl, #0
+	mov	yh, #0
+	mov	xh, #0
+	ldr	pc, [sp], #8
+
+UNWIND(.fnend)
+ENDPROC(__do_div64)
diff --git a/xen/arch/arm/lib/findbit.S b/xen/arch/arm/lib/findbit.S
new file mode 100644
index 0000000..2fbcc82
--- /dev/null
+++ b/xen/arch/arm/lib/findbit.S
@@ -0,0 +1,198 @@
+/*
+ *  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_le)
+		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_le)
+
+/*
+ * Purpose  : Find next 'zero' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_zero_bit_le)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit_le)
+
+/*
+ * Purpose  : Find a 'one' bit
+ * Prototype: int find_first_bit(const unsigned long *addr, unsigned int maxbit);
+ */
+ENTRY(_find_first_bit_le)
+		teq	r1, #0	
+		beq	3f
+		mov	r2, #0
+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_le)
+
+/*
+ * Purpose  : Find next 'one' bit
+ * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
+ */
+ENTRY(_find_next_bit_le)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+ ARM(		ldrb	r3, [r0, r2, lsr #3]	)
+ THUMB(		lsr	r3, r2, #3		)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit_le)
+
+#ifdef __ARMEB__
+
+ENTRY(_find_first_zero_bit_be)
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eors	r3, r3, #0xff		@ invert bits
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_zero_bit_be)
+
+ENTRY(_find_next_zero_bit_be)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		eor	r3, r3, #0xff		@ now looking for a 1 bit
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_zero_bit_be)
+
+ENTRY(_find_first_bit_be)
+		teq	r1, #0
+		beq	3f
+		mov	r2, #0
+1:		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3
+		bne	.L_found		@ any now set - found zero bit
+		add	r2, r2, #8		@ next bit pointer
+2:		cmp	r2, r1			@ any more?
+		blo	1b
+3:		mov	r0, r1			@ no free bits
+		mov	pc, lr
+ENDPROC(_find_first_bit_be)
+
+ENTRY(_find_next_bit_be)
+		teq	r1, #0
+		beq	3b
+		ands	ip, r2, #7
+		beq	1b			@ If new byte, goto old routine
+		eor	r3, r2, #0x18		@ big endian byte ordering
+ ARM(		ldrb	r3, [r0, r3, lsr #3]	)
+ THUMB(		lsr	r3, #3			)
+ THUMB(		ldrb	r3, [r0, r3]		)
+		movs	r3, r3, lsr ip		@ shift off unused bits
+		bne	.L_found
+		orr	r2, r2, #7		@ if zero, then no bits here
+		add	r2, r2, #1		@ align bit pointer
+		b	2b			@ loop for next bit
+ENDPROC(_find_next_bit_be)
+
+#endif
+
+/*
+ * One or more bits in the LSB of r3 are assumed to be set.
+ */
+.L_found:
+#if __LINUX_ARM_ARCH__ >= 5
+		rsb	r0, r3, #0
+		and	r3, r3, r0
+		clz	r3, r3
+		rsb	r3, r3, #31
+		add	r0, r2, r3
+#else
+		tst	r3, #0x0f
+		addeq	r2, r2, #4
+		movne	r3, r3, lsl #4
+		tst	r3, #0x30
+		addeq	r2, r2, #2
+		movne	r3, r3, lsl #2
+		tst	r3, #0x40
+		addeq	r2, r2, #1
+		mov	r0, r2
+#endif
+		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..95ee312
--- /dev/null
+++ b/xen/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,389 @@
+/*
+ * 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
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\curbit, \divisor
+	clz	\result, \dividend
+	sub	\result, \curbit, \result
+	mov	\curbit, #1
+	mov	\divisor, \divisor, lsl \result
+	mov	\curbit, \curbit, lsl \result
+	mov	\result, #0
+	
+#else
+
+	@ Initially shift the divisor left 3 bits if possible,
+	@ set curbit accordingly.  This allows for curbit to be located
+	@ at the left end of each 4 bit nibbles in the division loop
+	@ to save one loop in most cases.
+	tst	\divisor, #0xe0000000
+	moveq	\divisor, \divisor, lsl #3
+	moveq	\curbit, #8
+	movne	\curbit, #1
+
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	movlo	\curbit, \curbit, lsl #4
+	blo	1b
+
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	movlo	\curbit, \curbit, lsl #1
+	blo	1b
+
+	mov	\result, #0
+
+#endif
+
+	@ Division loop
+1:	cmp	\dividend, \divisor
+	subhs	\dividend, \dividend, \divisor
+	orrhs	\result,   \result,   \curbit
+	cmp	\dividend, \divisor,  lsr #1
+	subhs	\dividend, \dividend, \divisor, lsr #1
+	orrhs	\result,   \result,   \curbit,  lsr #1
+	cmp	\dividend, \divisor,  lsr #2
+	subhs	\dividend, \dividend, \divisor, lsr #2
+	orrhs	\result,   \result,   \curbit,  lsr #2
+	cmp	\dividend, \divisor,  lsr #3
+	subhs	\dividend, \dividend, \divisor, lsr #3
+	orrhs	\result,   \result,   \curbit,  lsr #3
+	cmp	\dividend, #0			@ Early termination?
+	movnes	\curbit,   \curbit,  lsr #4	@ No, any more bits to do?
+	movne	\divisor,  \divisor, lsr #4
+	bne	1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\order, \divisor
+	rsb	\order, \order, #31
+
+#else
+
+	cmp	\divisor, #(1 << 16)
+	movhs	\divisor, \divisor, lsr #16
+	movhs	\order, #16
+	movlo	\order, #0
+
+	cmp	\divisor, #(1 << 8)
+	movhs	\divisor, \divisor, lsr #8
+	addhs	\order, \order, #8
+
+	cmp	\divisor, #(1 << 4)
+	movhs	\divisor, \divisor, lsr #4
+	addhs	\order, \order, #4
+
+	cmp	\divisor, #(1 << 2)
+	addhi	\order, \order, #3
+	addls	\order, \order, \divisor, lsr #1
+
+#endif
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+	clz	\order, \divisor
+	clz	\spare, \dividend
+	sub	\order, \order, \spare
+	mov	\divisor, \divisor, lsl \order
+
+#else
+
+	mov	\order, #0
+
+	@ Unless the divisor is very big, shift it up in multiples of
+	@ four bits, since this is the amount of unwinding in the main
+	@ division loop.  Continue shifting until the divisor is 
+	@ larger than the dividend.
+1:	cmp	\divisor, #0x10000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #4
+	addlo	\order, \order, #4
+	blo	1b
+
+	@ For very big divisors, we must shift it a bit at a time, or
+	@ we will be in danger of overflowing.
+1:	cmp	\divisor, #0x80000000
+	cmplo	\divisor, \dividend
+	movlo	\divisor, \divisor, lsl #1
+	addlo	\order, \order, #1
+	blo	1b
+
+#endif
+
+	@ Perform all needed substractions to keep only the reminder.
+	@ Do comparisons in batch of 4 first.
+	subs	\order, \order, #3		@ yes, 3 is intended here
+	blt	2f
+
+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)
+
+#ifdef CONFIG_AEABI
+
+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_ldivmod)
+#endif
+
+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..d1ab9fb
--- /dev/null
+++ b/xen/arch/arm/lib/memcpy.S
@@ -0,0 +1,63 @@
+/*
+ *  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)
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 12285dd..9294f8f 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -30,6 +30,9 @@
 
 #define asmlinkage /* Nothing needed */
 
+#define __LINUX_ARM_ARCH__ 7
+#define CONFIG_AEABI
+
 /* Linkage for ARM */
 #define __ALIGN .align 2
 #define __ALIGN_STR ".align 2"
-- 
1.7.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 Jan 20 16:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHST-000239-HF; Fri, 20 Jan 2012 16:36: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 1RoHSR-0001uQ-0b
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16880 invoked from network); 20 Jan 2012 16:36:46 -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;
	20 Jan 2012 16:36:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114051"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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; Fri, 20 Jan 2012 11:36: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 q0KGaF0R016147;
	Fri, 20 Jan 2012 08:36:28 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:57 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 09/27] 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

A simple implementation of everything under asm-arm and arch-arm.h; some
of these files are shamelessly taken from Linux.


Changes in v6:

- remove arch_do_vcpu_op ansd arch_do_sysctl from asm-arm/hypercall.h;


Changes in v4:

- bring atomic access routines in line with upstream changes;

- fix build for -wunused-values;


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      |  236 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  213 +++++++++++++++++++++++++++++
 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   |   14 ++
 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/pci.h         |    7 +
 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 +
 40 files changed, 2459 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/pci.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..c7eadd6
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,236 @@
+/*
+ *  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(read_u8_atomic, "b", uint8_t, "=q")
+build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
+//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
+build_atomic_read(read_int_atomic, "", int, "=r")
+
+build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
+build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
+build_atomic_write(write_u32_atomic, "", uint32_t, "r")
+//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
+build_atomic_write(write_int_atomic, "", int, "r")
+
+void __bad_atomic_size(void);
+
+#define read_atomic(p) ({                                               \
+    typeof(*p) __x;                                                     \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: __x = (typeof(*p))read_u8_atomic((uint8_t *)p); break;      \
+    case 2: __x = (typeof(*p))read_u16_atomic((uint16_t *)p); break;    \
+    case 4: __x = (typeof(*p))read_u32_atomic((uint32_t *)p); break;    \
+    default: __x = 0; __bad_atomic_size(); break;                       \
+    }                                                                   \
+    __x;                                                                \
+})
+
+#define write_atomic(p, x) ({                                           \
+    typeof(*p) __x = (x);                                               \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: write_u8_atomic((uint8_t *)p, (uint8_t)__x); break;         \
+    case 2: write_u16_atomic((uint16_t *)p, (uint16_t)__x); break;      \
+    case 4: write_u32_atomic((uint32_t *)p, (uint32_t)__x); break;      \
+    default: __bad_atomic_size(); break;                                \
+    }                                                                   \
+    __x;                                                                \
+})
+
+/*
+ * 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..e5c1781
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,213 @@
+/*
+ * 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)));
+}
+
+/*
+ * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
+ */
+extern int _find_first_zero_bit_le(const void * p, unsigned size);
+extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+
+/*
+ * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
+ */
+extern int _find_first_zero_bit_be(const void * p, unsigned size);
+extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+
+#ifndef __ARMEB__
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
+
+#else
+/*
+ * These are the big endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
+
+#endif
+
+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..452613a
--- /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) ((void) 0)
+#define debugger_trap_immediate() ((void) 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..e49aa8d
--- /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) do {} while (0)
+#define gnttab_create_shared_page(d, t, i) do {} while (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..e840507
--- /dev/null
+++ b/xen/include/asm-arm/hypercall.h
@@ -0,0 +1,14 @@
+#ifndef __ASM_ARM_HYPERCALL_H__
+#define __ASM_ARM_HYPERCALL_H__
+
+#include <public/domctl.h> /* for arch_do_domctl */
+
+#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/pci.h b/xen/include/asm-arm/pci.h
new file mode 100644
index 0000000..de13359
--- /dev/null
+++ b/xen/include/asm-arm/pci.h
@@ -0,0 +1,7 @@
+#ifndef __X86_PCI_H__
+#define __X86_PCI_H__
+
+struct arch_pci_dev {
+};
+
+#endif /* __X86_PCI_H__ */
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..c430cf3
--- /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 41b14ea..68bce71 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 Jan 20 16:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHST-000239-HF; Fri, 20 Jan 2012 16:36: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 1RoHSR-0001uQ-0b
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:55 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327077394!11855974!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16880 invoked from network); 20 Jan 2012 16:36:46 -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;
	20 Jan 2012 16:36:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114051"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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; Fri, 20 Jan 2012 11:36: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 q0KGaF0R016147;
	Fri, 20 Jan 2012 08:36:28 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:35:57 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 09/27] 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

A simple implementation of everything under asm-arm and arch-arm.h; some
of these files are shamelessly taken from Linux.


Changes in v6:

- remove arch_do_vcpu_op ansd arch_do_sysctl from asm-arm/hypercall.h;


Changes in v4:

- bring atomic access routines in line with upstream changes;

- fix build for -wunused-values;


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      |  236 ++++++++++++++++++++++++++++++++
 xen/include/asm-arm/bitops.h      |  213 +++++++++++++++++++++++++++++
 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   |   14 ++
 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/pci.h         |    7 +
 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 +
 40 files changed, 2459 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/pci.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..c7eadd6
--- /dev/null
+++ b/xen/include/asm-arm/atomic.h
@@ -0,0 +1,236 @@
+/*
+ *  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(read_u8_atomic, "b", uint8_t, "=q")
+build_atomic_read(read_u16_atomic, "h", uint16_t, "=r")
+build_atomic_read(read_u32_atomic, "", uint32_t, "=r")
+//build_atomic_read(read_u64_atomic, "d", uint64_t, "=r")
+build_atomic_read(read_int_atomic, "", int, "=r")
+
+build_atomic_write(write_u8_atomic, "b", uint8_t, "q")
+build_atomic_write(write_u16_atomic, "h", uint16_t, "r")
+build_atomic_write(write_u32_atomic, "", uint32_t, "r")
+//build_atomic_write(write_u64_atomic, "d", uint64_t, "r")
+build_atomic_write(write_int_atomic, "", int, "r")
+
+void __bad_atomic_size(void);
+
+#define read_atomic(p) ({                                               \
+    typeof(*p) __x;                                                     \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: __x = (typeof(*p))read_u8_atomic((uint8_t *)p); break;      \
+    case 2: __x = (typeof(*p))read_u16_atomic((uint16_t *)p); break;    \
+    case 4: __x = (typeof(*p))read_u32_atomic((uint32_t *)p); break;    \
+    default: __x = 0; __bad_atomic_size(); break;                       \
+    }                                                                   \
+    __x;                                                                \
+})
+
+#define write_atomic(p, x) ({                                           \
+    typeof(*p) __x = (x);                                               \
+    switch ( sizeof(*p) ) {                                             \
+    case 1: write_u8_atomic((uint8_t *)p, (uint8_t)__x); break;         \
+    case 2: write_u16_atomic((uint16_t *)p, (uint16_t)__x); break;      \
+    case 4: write_u32_atomic((uint32_t *)p, (uint32_t)__x); break;      \
+    default: __bad_atomic_size(); break;                                \
+    }                                                                   \
+    __x;                                                                \
+})
+
+/*
+ * 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..e5c1781
--- /dev/null
+++ b/xen/include/asm-arm/bitops.h
@@ -0,0 +1,213 @@
+/*
+ * 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)));
+}
+
+/*
+ * Little endian assembly bitops.  nr = 0 -> byte 0 bit 0.
+ */
+extern int _find_first_zero_bit_le(const void * p, unsigned size);
+extern int _find_next_zero_bit_le(const void * p, int size, int offset);
+extern int _find_first_bit_le(const unsigned long *p, unsigned size);
+extern int _find_next_bit_le(const unsigned long *p, int size, int offset);
+
+/*
+ * Big endian assembly bitops.  nr = 0 -> byte 3 bit 0.
+ */
+extern int _find_first_zero_bit_be(const void * p, unsigned size);
+extern int _find_next_zero_bit_be(const void * p, int size, int offset);
+extern int _find_first_bit_be(const unsigned long *p, unsigned size);
+extern int _find_next_bit_be(const unsigned long *p, int size, int offset);
+
+#ifndef __ARMEB__
+/*
+ * These are the little endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_le(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_le(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_le(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_le(p,sz,off)
+
+#else
+/*
+ * These are the big endian, atomic definitions.
+ */
+#define find_first_zero_bit(p,sz)	_find_first_zero_bit_be(p,sz)
+#define find_next_zero_bit(p,sz,off)	_find_next_zero_bit_be(p,sz,off)
+#define find_first_bit(p,sz)		_find_first_bit_be(p,sz)
+#define find_next_bit(p,sz,off)		_find_next_bit_be(p,sz,off)
+
+#endif
+
+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..452613a
--- /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) ((void) 0)
+#define debugger_trap_immediate() ((void) 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..e49aa8d
--- /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) do {} while (0)
+#define gnttab_create_shared_page(d, t, i) do {} while (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..e840507
--- /dev/null
+++ b/xen/include/asm-arm/hypercall.h
@@ -0,0 +1,14 @@
+#ifndef __ASM_ARM_HYPERCALL_H__
+#define __ASM_ARM_HYPERCALL_H__
+
+#include <public/domctl.h> /* for arch_do_domctl */
+
+#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/pci.h b/xen/include/asm-arm/pci.h
new file mode 100644
index 0000000..de13359
--- /dev/null
+++ b/xen/include/asm-arm/pci.h
@@ -0,0 +1,7 @@
+#ifndef __X86_PCI_H__
+#define __X86_PCI_H__
+
+struct arch_pci_dev {
+};
+
+#endif /* __X86_PCI_H__ */
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..c430cf3
--- /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 41b14ea..68bce71 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 Jan 20 16:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSW-00026z-7f; Fri, 20 Jan 2012 16:37: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 1RoHSU-0001y3-Qw
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26988 invoked from network); 20 Jan 2012 16:36:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442465"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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; Fri, 20 Jan 2012 11:36:51 -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 q0KGaF0Y016147;
	Fri, 20 Jan 2012 08:36:39 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:04 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 16/27] 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

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..17c939c
--- /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 7afc64a..61a1559 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -106,6 +106,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 Jan 20 16:37:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSW-00026z-7f; Fri, 20 Jan 2012 16:37: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 1RoHSU-0001y3-Qw
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:36:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26988 invoked from network); 20 Jan 2012 16:36:52 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442465"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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; Fri, 20 Jan 2012 11:36:51 -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 q0KGaF0Y016147;
	Fri, 20 Jan 2012 08:36:39 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:04 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 16/27] 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

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..17c939c
--- /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 7afc64a..61a1559 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -106,6 +106,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 Jan 20 16:37:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoHSZ-0002C2-N7; Fri, 20 Jan 2012 16:37:03 +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 1RoHSY-00022J-An
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27080 invoked from network); 20 Jan 2012 16:36:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442476"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0Z016147;
	Fri, 20 Jan 2012 08:36:41 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:05 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 17/27] 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

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 v4:

- fix build for -wunused-values;


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 26f2d49..72034f3 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..f721c54
--- /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), (void)(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 Jan 20 16:37:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoHSZ-0002C2-N7; Fri, 20 Jan 2012 16:37:03 +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 1RoHSY-00022J-An
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27080 invoked from network); 20 Jan 2012 16:36:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442476"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0Z016147;
	Fri, 20 Jan 2012 08:36:41 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:05 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 17/27] 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

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 v4:

- fix build for -wunused-values;


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 26f2d49..72034f3 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..f721c54
--- /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), (void)(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 Jan 20 16:37:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSb-0002EG-CV; Fri, 20 Jan 2012 16:37:05 +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 1RoHSa-00024v-4I
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27143 invoked from network); 20 Jan 2012 16:36:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442490"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:36: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 q0KGaF0b016147;
	Fri, 20 Jan 2012 08:36:44 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:07 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 19/27] 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

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..51afb31
--- /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 Jan 20 16:37:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSb-0002EG-CV; Fri, 20 Jan 2012 16:37:05 +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 1RoHSa-00024v-4I
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27143 invoked from network); 20 Jan 2012 16:36:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442490"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:56 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:36: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 q0KGaF0b016147;
	Fri, 20 Jan 2012 08:36:44 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:07 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 19/27] 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

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..51afb31
--- /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 Jan 20 16:37:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSd-0002Hk-PZ; Fri, 20 Jan 2012 16:37: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 1RoHSb-00026k-Gl
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27212 invoked from network); 20 Jan 2012 16:36:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442499"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:36: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 q0KGaF0c016147;
	Fri, 20 Jan 2012 08:36:46 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:08 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 20/27] 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

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..cad84f5
--- /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 Jan 20 16:37:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSd-0002Hk-PZ; Fri, 20 Jan 2012 16:37: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 1RoHSb-00026k-Gl
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27212 invoked from network); 20 Jan 2012 16:36:59 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:36:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442499"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:36: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 q0KGaF0c016147;
	Fri, 20 Jan 2012 08:36:46 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:08 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 20/27] 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

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..cad84f5
--- /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 Jan 20 16:37:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSe-0002IS-7H; Fri, 20 Jan 2012 16:37:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSd-00029O-8e
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27283 invoked from network); 20 Jan 2012 16:37:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442503"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:36: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 q0KGaF0i016147;
	Fri, 20 Jan 2012 08:36:57 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:14 +0000
Message-ID: <1327077375-7623-26-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 26/27] ARM: support zImage format kernels 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

From: David Vrabel <david.vrabel@citrix.com>

Allow a zImage format kernel to be used for dom0.  zImages are (by
default) hardcoded with the RAM location so adjust the RAM in the
memory map to match the physical memory map (0x80000000).

Vmlinux ELF images are loaded using a hack to locate the RAM so the
IPA is the same as the kernel's VA so the elf loader does the right
thing.  If an ELF image is loaded the RAM will be located at
0xC0000000 (as before).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile       |    1 +
 xen/arch/arm/domain_build.c |   72 ++++--------------
 xen/arch/arm/kernel.c       |  167 +++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/kernel.h       |   37 ++++++++++
 4 files changed, 221 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/kernel.c
 create mode 100644 xen/arch/arm/kernel.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5a07ae7..9bc2fc8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
 obj-y += irq.o
+obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += guestcopy.o
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f73df85..cbbc0b9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -4,10 +4,10 @@
 #include <xen/mm.h>
 #include <xen/domain_page.h>
 #include <xen/sched.h>
-#include <xen/libelf.h>
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "kernel.h"
 
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
@@ -28,25 +28,6 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
 
 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);
@@ -84,21 +65,14 @@ static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
     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 kernel_info kinfo = {};
+    int rc;
 
     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);
@@ -106,31 +80,22 @@ int construct_dom0(struct domain *d)
 
     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");
+    /* 128M at 2G physical */
+    /* TODO size and location from DT. */
+    kinfo.ram_start = 0x80000000;
+    kinfo.ram_end   = 0x88000000;
 
-    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    rc = kernel_prepare(&kinfo);
+    if (rc < 0)
+        return rc;
 
     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("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
+    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
 
     printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
     map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
@@ -161,20 +126,15 @@ int construct_dom0(struct domain *d)
     /* 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);
+    kernel_load(&kinfo);
 
-    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
 
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
 
-    regs->pc = (uint32_t)parms.virt_entry;
+    regs->pc = (uint32_t)kinfo.entry;
 
     regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
@@ -191,7 +151,7 @@ int construct_dom0(struct domain *d)
 
     regs->r0 = 0; /* SBZ */
     regs->r1 = 2272; /* Machine NR: Versatile Express */
-    regs->r2 = 0xc0000100; /* ATAGS */
+    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
new file mode 100644
index 0000000..5fb2ba0
--- /dev/null
+++ b/xen/arch/arm/kernel.c
@@ -0,0 +1,167 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#include <xen/config.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+
+#include "kernel.h"
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+static void kernel_zimage_load(struct kernel_info *info)
+{
+    paddr_t load_addr = info->zimage.load_addr;
+    paddr_t len = info->zimage.len;
+    paddr_t flash = KERNEL_FLASH_ADDRESS;
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Loading %"PRIpaddr" byte zImage from flash %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
+           len, flash, load_addr, load_addr + len);
+    for ( offs = 0; offs < len; offs += PAGE_SIZE )
+    {
+        paddr_t ma = gvirt_to_maddr(load_addr + offs);
+        void *dst = map_domain_page(ma>>PAGE_SHIFT);
+
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst, src, PAGE_SIZE);
+        clear_fixmap(FIXMAP_MISC);
+
+        unmap_domain_page(dst);
+    }
+    printk("]\n");
+}
+
+/**
+ * Check the image is a zImage and return the load address and length
+ * (FIXME: including any appended DTB).
+ */
+static int kernel_try_zimage_prepare(struct kernel_info *info)
+{
+    uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    uint32_t start, end;
+
+    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+
+    if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
+        return -EINVAL;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    clear_fixmap(FIXMAP_MISC);
+
+    /* FIXME: get RAM location from appended DTB (if there is one)? */
+
+    /*
+     * If start is zero, the zImage is position independent -- load it
+     * at 32k from start of RAM.
+     */
+    if (start == 0)
+        info->zimage.load_addr = info->ram_start + 0x8000;
+    else
+        info->zimage.load_addr = start;
+    info->zimage.len = end - start;
+
+    info->entry = info->zimage.load_addr;
+    info->load = kernel_zimage_load;
+
+    return 0;
+}
+
+static void kernel_elf_load(struct kernel_info *info)
+{
+    printk("Loading ELF image into guest memory\n");
+    info->elf.elf.dest = (void*)(unsigned long)info->elf.parms.virt_kstart;
+    elf_load_binary(&info->elf.elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(info->kernel_img, info->kernel_order);
+}
+
+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 int kernel_try_elf_prepare(struct kernel_info *info)
+{
+    int rc;
+
+    info->kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    info->kernel_img = alloc_xenheap_pages(info->kernel_order, 0);
+    if ( info->kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;
+#ifdef VERBOSE
+    elf_set_verbose(&info->elf.elf);
+#endif
+    elf_parse_binary(&info->elf.elf);
+    if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
+        return rc;
+
+    /*
+     * FIXME: can the ELF header be used to find the physical address
+     * to load the image to?  Instead of making virt == phys by
+     * relocating the guest's RAM.
+     */
+    info->ram_start = 0xc0000000;
+    info->ram_end   = 0xc8000000;
+
+    info->entry = info->elf.parms.virt_entry;
+    info->load = kernel_elf_load;
+
+    return 0;
+}
+
+int kernel_prepare(struct kernel_info *info)
+{
+    int rc;
+
+    rc = kernel_try_zimage_prepare(info);
+    if (rc < 0)
+        rc = kernel_try_elf_prepare(info);
+
+    return rc;
+}
+
+void kernel_load(struct kernel_info *info)
+{
+    info->load(info);
+}
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
new file mode 100644
index 0000000..5caebe5
--- /dev/null
+++ b/xen/arch/arm/kernel.h
@@ -0,0 +1,37 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include <xen/libelf.h>
+
+struct kernel_info {
+    paddr_t entry;
+    paddr_t ram_start;
+    paddr_t ram_end;
+
+    void *kernel_img;
+    unsigned kernel_order;
+
+    union {
+        struct {
+            paddr_t load_addr;
+            paddr_t len;
+        } zimage;
+
+        struct {
+            struct elf_binary elf;
+            struct elf_dom_parms parms;
+        } elf;
+    };
+
+    void (*load)(struct kernel_info *info);
+};
+
+int kernel_prepare(struct kernel_info *info);
+void kernel_load(struct kernel_info *info);
+
+#endif /* #ifdef __ARCH_ARM_KERNEL_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 Jan 20 16:37:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSe-0002IS-7H; Fri, 20 Jan 2012 16:37:08 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSd-00029O-8e
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27283 invoked from network); 20 Jan 2012 16:37:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442503"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:36: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 q0KGaF0i016147;
	Fri, 20 Jan 2012 08:36:57 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:14 +0000
Message-ID: <1327077375-7623-26-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 26/27] ARM: support zImage format kernels 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

From: David Vrabel <david.vrabel@citrix.com>

Allow a zImage format kernel to be used for dom0.  zImages are (by
default) hardcoded with the RAM location so adjust the RAM in the
memory map to match the physical memory map (0x80000000).

Vmlinux ELF images are loaded using a hack to locate the RAM so the
IPA is the same as the kernel's VA so the elf loader does the right
thing.  If an ELF image is loaded the RAM will be located at
0xC0000000 (as before).

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/Makefile       |    1 +
 xen/arch/arm/domain_build.c |   72 ++++--------------
 xen/arch/arm/kernel.c       |  167 +++++++++++++++++++++++++++++++++++++++++++
 xen/arch/arm/kernel.h       |   37 ++++++++++
 4 files changed, 221 insertions(+), 56 deletions(-)
 create mode 100644 xen/arch/arm/kernel.c
 create mode 100644 xen/arch/arm/kernel.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5a07ae7..9bc2fc8 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ obj-y += domain_build.o
 obj-y += gic.o
 obj-y += io.o
 obj-y += irq.o
+obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += guestcopy.o
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f73df85..cbbc0b9 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -4,10 +4,10 @@
 #include <xen/mm.h>
 #include <xen/domain_page.h>
 #include <xen/sched.h>
-#include <xen/libelf.h>
 #include <asm/irq.h>
 
 #include "gic.h"
+#include "kernel.h"
 
 static unsigned int __initdata opt_dom0_max_vcpus;
 integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
@@ -28,25 +28,6 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
 
 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);
@@ -84,21 +65,14 @@ static void setup_linux_atag(paddr_t tags, paddr_t ram_s, paddr_t ram_e)
     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 kernel_info kinfo = {};
+    int rc;
 
     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);
@@ -106,31 +80,22 @@ int construct_dom0(struct domain *d)
 
     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");
+    /* 128M at 2G physical */
+    /* TODO size and location from DT. */
+    kinfo.ram_start = 0x80000000;
+    kinfo.ram_end   = 0x88000000;
 
-    copy_from_flash(kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+    rc = kernel_prepare(&kinfo);
+    if (rc < 0)
+        return rc;
 
     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("Populate P2M %#llx->%#llx\n", kinfo.ram_start, kinfo.ram_end);
+    p2m_populate_ram(d, kinfo.ram_start, kinfo.ram_end);
 
     printk("Map CS2 MMIO regions 1:1 in the P2M %#llx->%#llx\n", 0x18000000ULL, 0x1BFFFFFFULL);
     map_mmio_regions(d, 0x18000000, 0x1BFFFFFF, 0x18000000);
@@ -161,20 +126,15 @@ int construct_dom0(struct domain *d)
     /* 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);
+    kernel_load(&kinfo);
 
-    setup_linux_atag(0xc0000100ULL, 0xc0000000ULL, 0xc8000000ULL);
+    setup_linux_atag(kinfo.ram_start + 0x100, kinfo.ram_start, kinfo.ram_end);
 
     clear_bit(_VPF_down, &v->pause_flags);
 
     memset(regs, 0, sizeof(*regs));
 
-    regs->pc = (uint32_t)parms.virt_entry;
+    regs->pc = (uint32_t)kinfo.entry;
 
     regs->cpsr = PSR_ABT_MASK|PSR_FIQ_MASK|PSR_IRQ_MASK|PSR_MODE_SVC;
 
@@ -191,7 +151,7 @@ int construct_dom0(struct domain *d)
 
     regs->r0 = 0; /* SBZ */
     regs->r1 = 2272; /* Machine NR: Versatile Express */
-    regs->r2 = 0xc0000100; /* ATAGS */
+    regs->r2 = kinfo.ram_start + 0x100; /* ATAGS */
 
     WRITE_CP32(SCTLR_BASE, SCTLR);
 
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
new file mode 100644
index 0000000..5fb2ba0
--- /dev/null
+++ b/xen/arch/arm/kernel.c
@@ -0,0 +1,167 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#include <xen/config.h>
+#include <xen/errno.h>
+#include <xen/init.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/domain_page.h>
+#include <xen/sched.h>
+
+#include "kernel.h"
+
+/* Store kernel in first 8M of flash */
+#define KERNEL_FLASH_ADDRESS 0x00000000UL
+#define KERNEL_FLASH_SIZE    0x00800000UL
+
+#define ZIMAGE_MAGIC_OFFSET 0x24
+#define ZIMAGE_START_OFFSET 0x28
+#define ZIMAGE_END_OFFSET   0x2c
+
+#define ZIMAGE_MAGIC 0x016f2818
+
+static void kernel_zimage_load(struct kernel_info *info)
+{
+    paddr_t load_addr = info->zimage.load_addr;
+    paddr_t len = info->zimage.len;
+    paddr_t flash = KERNEL_FLASH_ADDRESS;
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    unsigned long offs;
+
+    printk("Loading %"PRIpaddr" byte zImage from flash %"PRIpaddr" to %"PRIpaddr"-%"PRIpaddr": [",
+           len, flash, load_addr, load_addr + len);
+    for ( offs = 0; offs < len; offs += PAGE_SIZE )
+    {
+        paddr_t ma = gvirt_to_maddr(load_addr + offs);
+        void *dst = map_domain_page(ma>>PAGE_SHIFT);
+
+        if ( ( offs % (1<<20) ) == 0 )
+            printk(".");
+
+        set_fixmap(FIXMAP_MISC, (flash+offs) >> PAGE_SHIFT, DEV_SHARED);
+        memcpy(dst, src, PAGE_SIZE);
+        clear_fixmap(FIXMAP_MISC);
+
+        unmap_domain_page(dst);
+    }
+    printk("]\n");
+}
+
+/**
+ * Check the image is a zImage and return the load address and length
+ * (FIXME: including any appended DTB).
+ */
+static int kernel_try_zimage_prepare(struct kernel_info *info)
+{
+    uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+    uint32_t start, end;
+
+    set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
+
+    if (zimage[ZIMAGE_MAGIC_OFFSET/4] != ZIMAGE_MAGIC)
+        return -EINVAL;
+
+    start = zimage[ZIMAGE_START_OFFSET/4];
+    end = zimage[ZIMAGE_END_OFFSET/4];
+
+    clear_fixmap(FIXMAP_MISC);
+
+    /* FIXME: get RAM location from appended DTB (if there is one)? */
+
+    /*
+     * If start is zero, the zImage is position independent -- load it
+     * at 32k from start of RAM.
+     */
+    if (start == 0)
+        info->zimage.load_addr = info->ram_start + 0x8000;
+    else
+        info->zimage.load_addr = start;
+    info->zimage.len = end - start;
+
+    info->entry = info->zimage.load_addr;
+    info->load = kernel_zimage_load;
+
+    return 0;
+}
+
+static void kernel_elf_load(struct kernel_info *info)
+{
+    printk("Loading ELF image into guest memory\n");
+    info->elf.elf.dest = (void*)(unsigned long)info->elf.parms.virt_kstart;
+    elf_load_binary(&info->elf.elf);
+
+    printk("Free temporary kernel buffer\n");
+    free_xenheap_pages(info->kernel_img, info->kernel_order);
+}
+
+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 int kernel_try_elf_prepare(struct kernel_info *info)
+{
+    int rc;
+
+    info->kernel_order = get_order_from_bytes(KERNEL_FLASH_SIZE);
+    info->kernel_img = alloc_xenheap_pages(info->kernel_order, 0);
+    if ( info->kernel_img == NULL )
+        panic("Cannot allocate temporary buffer for kernel.\n");
+
+    copy_from_flash(info->kernel_img, KERNEL_FLASH_ADDRESS, KERNEL_FLASH_SIZE);
+
+    if ( (rc = elf_init(&info->elf.elf, info->kernel_img, KERNEL_FLASH_SIZE )) != 0 )
+        return rc;
+#ifdef VERBOSE
+    elf_set_verbose(&info->elf.elf);
+#endif
+    elf_parse_binary(&info->elf.elf);
+    if ( (rc = elf_xen_parse(&info->elf.elf, &info->elf.parms)) != 0 )
+        return rc;
+
+    /*
+     * FIXME: can the ELF header be used to find the physical address
+     * to load the image to?  Instead of making virt == phys by
+     * relocating the guest's RAM.
+     */
+    info->ram_start = 0xc0000000;
+    info->ram_end   = 0xc8000000;
+
+    info->entry = info->elf.parms.virt_entry;
+    info->load = kernel_elf_load;
+
+    return 0;
+}
+
+int kernel_prepare(struct kernel_info *info)
+{
+    int rc;
+
+    rc = kernel_try_zimage_prepare(info);
+    if (rc < 0)
+        rc = kernel_try_elf_prepare(info);
+
+    return rc;
+}
+
+void kernel_load(struct kernel_info *info)
+{
+    info->load(info);
+}
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
new file mode 100644
index 0000000..5caebe5
--- /dev/null
+++ b/xen/arch/arm/kernel.h
@@ -0,0 +1,37 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include <xen/libelf.h>
+
+struct kernel_info {
+    paddr_t entry;
+    paddr_t ram_start;
+    paddr_t ram_end;
+
+    void *kernel_img;
+    unsigned kernel_order;
+
+    union {
+        struct {
+            paddr_t load_addr;
+            paddr_t len;
+        } zimage;
+
+        struct {
+            struct elf_binary elf;
+            struct elf_dom_parms parms;
+        } elf;
+    };
+
+    void (*load)(struct kernel_info *info);
+};
+
+int kernel_prepare(struct kernel_info *info);
+void kernel_load(struct kernel_info *info);
+
+#endif /* #ifdef __ARCH_ARM_KERNEL_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 Jan 20 16:37:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSl-0002SS-Mn; Fri, 20 Jan 2012 16:37:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSj-0002I8-E4
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!10
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27624 invoked from network); 20 Jan 2012 16:37:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442524"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0j016147;
	Fri, 20 Jan 2012 08:36:59 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:15 +0000
Message-ID: <1327077375-7623-27-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 27/27] ARM: copy DTB appended to zImage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

When copying a zImage from flash, also copy any appended device tree
blob.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c |   63 ++++++++++++++++++++++++++++++++++--------------
 1 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 5fb2ba0..d4ffa4f 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -10,6 +10,7 @@
 #include <xen/mm.h>
 #include <xen/domain_page.h>
 #include <xen/sched.h>
+#include <asm/byteorder.h>
 
 #include "kernel.h"
 
@@ -23,6 +24,40 @@
 
 #define ZIMAGE_MAGIC 0x016f2818
 
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p",
+           len, flash, dst);
+
+    while (len) {
+        paddr_t p;
+        unsigned long l, s;
+
+        p = flash >> PAGE_SHIFT;
+        s = flash & (PAGE_SIZE-1);
+        l = min(PAGE_SIZE - s, len);
+
+        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        memcpy(dst, src + s, l);
+
+        flash += l;
+        dst += l;
+        len -= l;
+    }
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
 static void kernel_zimage_load(struct kernel_info *info)
 {
     paddr_t load_addr = info->zimage.load_addr;
@@ -58,6 +93,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
 {
     uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
     uint32_t start, end;
+    struct minimal_dtb_header dtb_hdr;
 
     set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
 
@@ -69,6 +105,14 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
 
     clear_fixmap(FIXMAP_MISC);
 
+    /*
+     * Check for an appended DTB.
+     */
+    copy_from_flash(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
+        end += be32_to_cpu(dtb_hdr.total_size);
+    }
+
     /* FIXME: get RAM location from appended DTB (if there is one)? */
 
     /*
@@ -97,25 +141,6 @@ static void kernel_elf_load(struct kernel_info *info)
     free_xenheap_pages(info->kernel_img, info->kernel_order);
 }
 
-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 int kernel_try_elf_prepare(struct kernel_info *info)
 {
     int rc;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:37:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSl-0002SS-Mn; Fri, 20 Jan 2012 16:37:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSj-0002I8-E4
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!10
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27624 invoked from network); 20 Jan 2012 16:37:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442524"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0j016147;
	Fri, 20 Jan 2012 08:36:59 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:15 +0000
Message-ID: <1327077375-7623-27-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
In-Reply-To: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>, Stefano.Stabellini@eu.citrix.com,
	Ian.Campbell@citrix.com, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 27/27] ARM: copy DTB appended to zImage
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

When copying a zImage from flash, also copy any appended device tree
blob.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
---
 xen/arch/arm/kernel.c |   63 ++++++++++++++++++++++++++++++++++--------------
 1 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 5fb2ba0..d4ffa4f 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -10,6 +10,7 @@
 #include <xen/mm.h>
 #include <xen/domain_page.h>
 #include <xen/sched.h>
+#include <asm/byteorder.h>
 
 #include "kernel.h"
 
@@ -23,6 +24,40 @@
 
 #define ZIMAGE_MAGIC 0x016f2818
 
+struct minimal_dtb_header {
+    uint32_t magic;
+    uint32_t total_size;
+    /* There are other fields but we don't use them yet. */
+};
+
+#define DTB_MAGIC 0xd00dfeed
+
+static void copy_from_flash(void *dst, paddr_t flash, unsigned long len)
+{
+    void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
+
+    printk("Copying %#lx bytes from flash %"PRIpaddr" to %p",
+           len, flash, dst);
+
+    while (len) {
+        paddr_t p;
+        unsigned long l, s;
+
+        p = flash >> PAGE_SHIFT;
+        s = flash & (PAGE_SIZE-1);
+        l = min(PAGE_SIZE - s, len);
+
+        set_fixmap(FIXMAP_MISC, p, DEV_SHARED);
+        memcpy(dst, src + s, l);
+
+        flash += l;
+        dst += l;
+        len -= l;
+    }
+
+    clear_fixmap(FIXMAP_MISC);
+}
+
 static void kernel_zimage_load(struct kernel_info *info)
 {
     paddr_t load_addr = info->zimage.load_addr;
@@ -58,6 +93,7 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
 {
     uint32_t *zimage = (void *)FIXMAP_ADDR(FIXMAP_MISC);
     uint32_t start, end;
+    struct minimal_dtb_header dtb_hdr;
 
     set_fixmap(FIXMAP_MISC, KERNEL_FLASH_ADDRESS >> PAGE_SHIFT, DEV_SHARED);
 
@@ -69,6 +105,14 @@ static int kernel_try_zimage_prepare(struct kernel_info *info)
 
     clear_fixmap(FIXMAP_MISC);
 
+    /*
+     * Check for an appended DTB.
+     */
+    copy_from_flash(&dtb_hdr, KERNEL_FLASH_ADDRESS + end - start, sizeof(dtb_hdr));
+    if (be32_to_cpu(dtb_hdr.magic) == DTB_MAGIC) {
+        end += be32_to_cpu(dtb_hdr.total_size);
+    }
+
     /* FIXME: get RAM location from appended DTB (if there is one)? */
 
     /*
@@ -97,25 +141,6 @@ static void kernel_elf_load(struct kernel_info *info)
     free_xenheap_pages(info->kernel_img, info->kernel_order);
 }
 
-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 int kernel_try_elf_prepare(struct kernel_info *info)
 {
     int rc;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:37:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSk-0002Qn-Nd; Fri, 20 Jan 2012 16:37:14 +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 1RoHSi-0002GQ-CW
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327077424!9998677!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22272 invoked from network); 20 Jan 2012 16:37:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114068"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0e016147;
	Fri, 20 Jan 2012 08:36:49 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:10 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 22/27] 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

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 Jan 20 16:37:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSl-0002RV-6Y; Fri, 20 Jan 2012 16:37:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSi-0002HC-Re
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27577 invoked from network); 20 Jan 2012 16:37:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442521"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0d016147;
	Fri, 20 Jan 2012 08:36:47 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:09 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 21/27] 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

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 Jan 20 16:37:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSk-0002Qn-Nd; Fri, 20 Jan 2012 16:37:14 +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 1RoHSi-0002GQ-CW
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:12 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327077424!9998677!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22272 invoked from network); 20 Jan 2012 16:37:05 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114068"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0e016147;
	Fri, 20 Jan 2012 08:36:49 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:10 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 22/27] 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

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 Jan 20 16:37:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSl-0002RV-6Y; Fri, 20 Jan 2012 16:37:15 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSi-0002HC-Re
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327077402!10034714!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27577 invoked from network); 20 Jan 2012 16:37:06 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178442521"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0d016147;
	Fri, 20 Jan 2012 08:36:47 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:09 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 21/27] 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

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 Jan 20 16:37:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSm-0002T2-6B; Fri, 20 Jan 2012 16:37:16 +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 1RoHSj-0002Ir-SE
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327077425!9998717!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16933 invoked from network); 20 Jan 2012 16:37:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114070"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0g016147;
	Fri, 20 Jan 2012 08:36:54 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:12 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 24/27] 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

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 d33b692..ada89af 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..6b1152e
--- /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 Jan 20 16:37:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:37:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHSm-0002T2-6B; Fri, 20 Jan 2012 16:37:16 +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 1RoHSj-0002Ir-SE
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327077425!9998717!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16933 invoked from network); 20 Jan 2012 16:37:07 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114070"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0g016147;
	Fri, 20 Jan 2012 08:36:54 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:12 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 24/27] 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

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 d33b692..ada89af 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..6b1152e
--- /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 Jan 20 16:37:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSm-0002UX-VS; Fri, 20 Jan 2012 16:37:16 +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 1RoHSj-0002Ih-S9
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327077424!9998677!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22299 invoked from network); 20 Jan 2012 16:37:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114069"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0f016147;
	Fri, 20 Jan 2012 08:36:52 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:11 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 23/27] 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

- emulation of the GICD interface for the guest;

- interrupt injection into the guest;

- keep track of inflight irqs using a list, ordered by priority.


Changes in v5:

- GICD_ICFGR ... GICD_ICFGRN need to return 1.


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>
Signed-off-by: David Vrabel <david.vrabel@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 72034f3..d33b692 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 17c939c..f9d663b 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..584e682
--- /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 1;
+
+    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 Jan 20 16:37:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSn-0002VY-E7; Fri, 20 Jan 2012 16:37:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSk-0002KW-VD
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327077427!11848134!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13251 invoked from network); 20 Jan 2012 16:37:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114071"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37:07 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0KGaF0h016147;
	Fri, 20 Jan 2012 08:36:56 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:13 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 25/27] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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 Fri Jan 20 16:37:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSn-0002VY-E7; Fri, 20 Jan 2012 16:37:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoHSk-0002KW-VD
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:15 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327077427!11848134!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13251 invoked from network); 20 Jan 2012 16:37:08 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114071"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37:07 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0KGaF0h016147;
	Fri, 20 Jan 2012 08:36:56 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:13 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 25/27] arm: makefiles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

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 Fri Jan 20 16:37:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHSm-0002UX-VS; Fri, 20 Jan 2012 16:37:16 +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 1RoHSj-0002Ih-S9
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:37:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327077424!9998677!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22299 invoked from network); 20 Jan 2012 16:37:06 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:37:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114069"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:37: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; Fri, 20 Jan 2012 11:37: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 q0KGaF0f016147;
	Fri, 20 Jan 2012 08:36:52 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:11 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: David Vrabel <david.vrabel@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 23/27] 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

- emulation of the GICD interface for the guest;

- interrupt injection into the guest;

- keep track of inflight irqs using a list, ordered by priority.


Changes in v5:

- GICD_ICFGR ... GICD_ICFGRN need to return 1.


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>
Signed-off-by: David Vrabel <david.vrabel@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 72034f3..d33b692 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 17c939c..f9d663b 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..584e682
--- /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 1;
+
+    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 Jan 20 16:38:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHTY-0003Q4-W2; Fri, 20 Jan 2012 16:38:04 +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 1RoHTW-0003JF-Hk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:38:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327077475!11744404!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 8937 invoked from network); 20 Jan 2012 16:37:56 -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; 20 Jan 2012 16:37:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:37:54 +0000
Message-Id: <4F19A6B3020000780006E153@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:38:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1327074280@gran.amd.com>
	<20249.37479.802666.184751@mariner.uk.xensource.com>
	<4F199485.4050304@amd.com>
	<4F19A3C2020000780006E0F7@nat28.tlf.novell.com>
	<4F199866.9060208@amd.com>
In-Reply-To: <4F199866.9060208@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:37, Wei Wang <wei.wang2@amd.com> wrote:
> Hi I had tested this on old iommu systems before submission. But I can 
> re-test it again. Non-iommu system will also be tested. It might take 
> some in setting up an Intel machine on my side. Could Ian confirm that 
> it works on Intel or not?

According to the failure pattern of the stage tester this is now
apparently working okay on Intel, but failing on AMD.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:38:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:38:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHTY-0003Q4-W2; Fri, 20 Jan 2012 16:38:04 +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 1RoHTW-0003JF-Hk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:38:02 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327077475!11744404!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 8937 invoked from network); 20 Jan 2012 16:37:56 -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; 20 Jan 2012 16:37:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:37:54 +0000
Message-Id: <4F19A6B3020000780006E153@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:38:59 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Wang" <wei.wang2@amd.com>
References: <patchbomb.1327074280@gran.amd.com>
	<20249.37479.802666.184751@mariner.uk.xensource.com>
	<4F199485.4050304@amd.com>
	<4F19A3C2020000780006E0F7@nat28.tlf.novell.com>
	<4F199866.9060208@amd.com>
In-Reply-To: <4F199866.9060208@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 0 of 7 V4] amd iommu: support ATS/GPGPU
 passthru on IOMMUv2 systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:37, Wei Wang <wei.wang2@amd.com> wrote:
> Hi I had tested this on old iommu systems before submission. But I can 
> re-test it again. Non-iommu system will also be tested. It might take 
> some in setting up an Intel machine on my side. Could Ian confirm that 
> it works on Intel or not?

According to the failure pattern of the stage tester this is now
apparently working okay on Intel, but failing on AMD.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:39:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHUl-0004I9-EM; Fri, 20 Jan 2012 16:39:19 +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 1RoHUk-0004HV-KQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:39:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327077510!50950651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25646 invoked from network); 20 Jan 2012 16:38:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114136"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:39: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; Fri, 20 Jan 2012
	11:39:15 -0500
Message-ID: <4F1998B2.1070501@citrix.com>
Date: Fri, 20 Jan 2012 16:39: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
In-Reply-To: <4F19A577020000780006E115@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/12 16:33, Jan Beulich wrote:
> This addresses a number of problems in msixtbl_{read,write}():
> - address alignment was not checked, allowing for memory corruption in
>   the hypervisor (write case) or returning of hypervisor private data
>   to the guest (read case)
> - the interrupt mask bit was permitted to be written by the guest
>   (while Xen's interrupt flow control routines need to control it)
> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>   numbers (making it unobvious why they have these values, and making
>   the latter non-portable)
> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>   non-zero table offset); this was also affecting host MSI-X code
> - struct msixtbl_entry's table_flags[] was one element larger than
>   necessary due to improper open-coding of BITS_TO_LONGS()
> - msixtbl_read() unconditionally accessed the physical table, even
>   though the data was only needed in a quarter of all cases
> - various calculations were done unnecessarily for both of the rather
>   distinct code paths in msixtbl_read()
>
> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
> chosen to be 3.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -165,7 +165,7 @@ struct msixtbl_entry
>      struct pci_dev *pdev;
>      unsigned long gtable;       /* gpa of msix table */
>      unsigned long table_len;
> -    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + 1];
> +    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
>  #define MAX_MSIX_ACC_ENTRIES 3
>      struct { 
>          uint32_t msi_ad[3];	/* Shadow of address low, high and data */
> @@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin
>  static void __iomem *msixtbl_addr_to_virt(
>      struct msixtbl_entry *entry, unsigned long addr)
>  {
> -    int idx, nr_page;
> +    unsigned int idx, nr_page;
>  
> -    if ( !entry )
> +    if ( !entry || !entry->pdev )
>          return NULL;
>  
>      nr_page = (addr >> PAGE_SHIFT) -
>                (entry->gtable >> PAGE_SHIFT);
>  
> -    if ( !entry->pdev )
> -        return NULL;
> -
>      idx = entry->pdev->msix_table_idx[nr_page];
>      if ( !idx )
>          return NULL;
> @@ -215,37 +212,34 @@ static int msixtbl_read(
>      struct vcpu *v, unsigned long address,
>      unsigned long len, unsigned long *pval)
>  {
> -    unsigned long offset, val;
> +    unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
> -    virt = msixtbl_addr_to_virt(entry, address);
> -    if ( !virt )
> -        goto out;
> -
> -    nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
>      offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
> -    if ( nr_entry >= MAX_MSIX_ACC_ENTRIES && 
> -         offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
> -        goto out;
>  
> -    val = readl(virt);
>      if ( offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
>      {
> +        nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> +        if ( nr_entry >= MAX_MSIX_ACC_ENTRIES )
> +            goto out;
>          index = offset / sizeof(uint32_t);
>          *pval = entry->gentries[nr_entry].msi_ad[index];
>      }
>      else 
>      {
> -        *pval = val;
> +        virt = msixtbl_addr_to_virt(entry, address);
> +        if ( !virt )
> +            goto out;
> +        *pval = readl(virt);
>      }
>      
>      r = X86EMUL_OKAY;
> @@ -260,13 +254,13 @@ static int msixtbl_write(struct vcpu *v,
>      unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
>      nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>      if ( !virt )
>          goto out;
>  
> +    /* Do not allow the mask bit to be changed. */
> +#if 0 /* XXX

You appear to still have some debugging in this patch.

~Andrew

> +       * As the mask bit is the only defined bit in the word, and as the
> +       * host MSI-X code doesn't preserve the other bits anyway, doing
> +       * this is pointless. So for now just discard the write (also
> +       * saving us from having to determine the matching irq_desc).
> +       */
> +    spin_lock_irqsave(&desc->lock, flags);
> +    orig = readl(virt);
> +    val &= ~PCI_MSIX_VECTOR_BITMASK;
> +    val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
> -    r = X86EMUL_OKAY;
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +#endif
>  
> +    r = X86EMUL_OKAY;
>  out:
>      rcu_read_unlock(&msixtbl_rcu_lock);
>      return r;
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -122,12 +122,6 @@ int msi_free_irq(struct msi_desc *entry)
>   */
>  #define NR_HP_RESERVED_VECTORS 	20
>  
> -#define PCI_MSIX_ENTRY_SIZE			16
> -#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> -#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> -#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> -#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> -
>  #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>  #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>  #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -11,6 +11,8 @@
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
>  #include <xen/irq.h>
> +#include <xen/pci_regs.h>
> +#include <xen/pfn.h>
>  #include <asm/pci.h>
>  
>  /*
> @@ -30,8 +32,10 @@
>  #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
>  #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
>  
> -#define MAX_MSIX_TABLE_ENTRIES  2048
> -#define MAX_MSIX_TABLE_PAGES    8
> +#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
> +#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
> +                                       PCI_MSIX_ENTRY_SIZE + \
> +                                       (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))
>  struct pci_dev_info {
>      bool_t is_extfn;
>      bool_t is_virtfn;
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -305,6 +305,12 @@
>  #define PCI_MSIX_PBA		8
>  #define  PCI_MSIX_BIRMASK	(7 << 0)
>  
> +#define PCI_MSIX_ENTRY_SIZE			16
> +#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> +#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> +#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> +#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> +
>  #define PCI_MSIX_VECTOR_BITMASK	(1 << 0)
>  
>  /* CompactPCI Hotswap Register */
>
>

-- 
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 Jan 20 16:39:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:39:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHUl-0004I9-EM; Fri, 20 Jan 2012 16:39:19 +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 1RoHUk-0004HV-KQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:39:18 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327077510!50950651!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25646 invoked from network); 20 Jan 2012 16:38:31 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:38:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114136"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:39: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; Fri, 20 Jan 2012
	11:39:15 -0500
Message-ID: <4F1998B2.1070501@citrix.com>
Date: Fri, 20 Jan 2012 16:39: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
In-Reply-To: <4F19A577020000780006E115@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/12 16:33, Jan Beulich wrote:
> This addresses a number of problems in msixtbl_{read,write}():
> - address alignment was not checked, allowing for memory corruption in
>   the hypervisor (write case) or returning of hypervisor private data
>   to the guest (read case)
> - the interrupt mask bit was permitted to be written by the guest
>   (while Xen's interrupt flow control routines need to control it)
> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>   numbers (making it unobvious why they have these values, and making
>   the latter non-portable)
> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>   non-zero table offset); this was also affecting host MSI-X code
> - struct msixtbl_entry's table_flags[] was one element larger than
>   necessary due to improper open-coding of BITS_TO_LONGS()
> - msixtbl_read() unconditionally accessed the physical table, even
>   though the data was only needed in a quarter of all cases
> - various calculations were done unnecessarily for both of the rather
>   distinct code paths in msixtbl_read()
>
> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
> chosen to be 3.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -165,7 +165,7 @@ struct msixtbl_entry
>      struct pci_dev *pdev;
>      unsigned long gtable;       /* gpa of msix table */
>      unsigned long table_len;
> -    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + 1];
> +    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
>  #define MAX_MSIX_ACC_ENTRIES 3
>      struct { 
>          uint32_t msi_ad[3];	/* Shadow of address low, high and data */
> @@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin
>  static void __iomem *msixtbl_addr_to_virt(
>      struct msixtbl_entry *entry, unsigned long addr)
>  {
> -    int idx, nr_page;
> +    unsigned int idx, nr_page;
>  
> -    if ( !entry )
> +    if ( !entry || !entry->pdev )
>          return NULL;
>  
>      nr_page = (addr >> PAGE_SHIFT) -
>                (entry->gtable >> PAGE_SHIFT);
>  
> -    if ( !entry->pdev )
> -        return NULL;
> -
>      idx = entry->pdev->msix_table_idx[nr_page];
>      if ( !idx )
>          return NULL;
> @@ -215,37 +212,34 @@ static int msixtbl_read(
>      struct vcpu *v, unsigned long address,
>      unsigned long len, unsigned long *pval)
>  {
> -    unsigned long offset, val;
> +    unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
> -    virt = msixtbl_addr_to_virt(entry, address);
> -    if ( !virt )
> -        goto out;
> -
> -    nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
>      offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
> -    if ( nr_entry >= MAX_MSIX_ACC_ENTRIES && 
> -         offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
> -        goto out;
>  
> -    val = readl(virt);
>      if ( offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
>      {
> +        nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> +        if ( nr_entry >= MAX_MSIX_ACC_ENTRIES )
> +            goto out;
>          index = offset / sizeof(uint32_t);
>          *pval = entry->gentries[nr_entry].msi_ad[index];
>      }
>      else 
>      {
> -        *pval = val;
> +        virt = msixtbl_addr_to_virt(entry, address);
> +        if ( !virt )
> +            goto out;
> +        *pval = readl(virt);
>      }
>      
>      r = X86EMUL_OKAY;
> @@ -260,13 +254,13 @@ static int msixtbl_write(struct vcpu *v,
>      unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
>      nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>      if ( !virt )
>          goto out;
>  
> +    /* Do not allow the mask bit to be changed. */
> +#if 0 /* XXX

You appear to still have some debugging in this patch.

~Andrew

> +       * As the mask bit is the only defined bit in the word, and as the
> +       * host MSI-X code doesn't preserve the other bits anyway, doing
> +       * this is pointless. So for now just discard the write (also
> +       * saving us from having to determine the matching irq_desc).
> +       */
> +    spin_lock_irqsave(&desc->lock, flags);
> +    orig = readl(virt);
> +    val &= ~PCI_MSIX_VECTOR_BITMASK;
> +    val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
> -    r = X86EMUL_OKAY;
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +#endif
>  
> +    r = X86EMUL_OKAY;
>  out:
>      rcu_read_unlock(&msixtbl_rcu_lock);
>      return r;
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -122,12 +122,6 @@ int msi_free_irq(struct msi_desc *entry)
>   */
>  #define NR_HP_RESERVED_VECTORS 	20
>  
> -#define PCI_MSIX_ENTRY_SIZE			16
> -#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> -#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> -#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> -#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> -
>  #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>  #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>  #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -11,6 +11,8 @@
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
>  #include <xen/irq.h>
> +#include <xen/pci_regs.h>
> +#include <xen/pfn.h>
>  #include <asm/pci.h>
>  
>  /*
> @@ -30,8 +32,10 @@
>  #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
>  #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
>  
> -#define MAX_MSIX_TABLE_ENTRIES  2048
> -#define MAX_MSIX_TABLE_PAGES    8
> +#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
> +#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
> +                                       PCI_MSIX_ENTRY_SIZE + \
> +                                       (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))
>  struct pci_dev_info {
>      bool_t is_extfn;
>      bool_t is_virtfn;
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -305,6 +305,12 @@
>  #define PCI_MSIX_PBA		8
>  #define  PCI_MSIX_BIRMASK	(7 << 0)
>  
> +#define PCI_MSIX_ENTRY_SIZE			16
> +#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> +#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> +#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> +#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> +
>  #define PCI_MSIX_VECTOR_BITMASK	(1 << 0)
>  
>  /* CompactPCI Hotswap Register */
>
>

-- 
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 Jan 20 16:41:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHXD-0005jB-25; Fri, 20 Jan 2012 16:41:51 +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 1RoHXB-0005fs-Em
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:41:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327077702!11770523!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 9931 invoked from network); 20 Jan 2012 16:41:43 -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; 20 Jan 2012 16:41:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:41:42 +0000
Message-Id: <4F19A797020000780006E15B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:42:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
In-Reply-To: <4F19A577020000780006E115@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, yuan.b.liu@intel.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:33, "Jan Beulich" <JBeulich@suse.com> wrote:
> This addresses a number of problems in msixtbl_{read,write}():
> - address alignment was not checked, allowing for memory corruption in
>   the hypervisor (write case) or returning of hypervisor private data
>   to the guest (read case)
> - the interrupt mask bit was permitted to be written by the guest
>   (while Xen's interrupt flow control routines need to control it)
> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>   numbers (making it unobvious why they have these values, and making
>   the latter non-portable)
> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>   non-zero table offset); this was also affecting host MSI-X code
> - struct msixtbl_entry's table_flags[] was one element larger than
>   necessary due to improper open-coding of BITS_TO_LONGS()
> - msixtbl_read() unconditionally accessed the physical table, even
>   though the data was only needed in a quarter of all cases
> - various calculations were done unnecessarily for both of the rather
>   distinct code paths in msixtbl_read()

I should note (as done in the earlier response to the 4.2 todo thread)
that I have no way of actually testing this, so I'm relying on others
here. (Intel? Or, Ian, would the stage tester find issues with passed
through MSI-X capable devices?)

Jan

> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
> chosen to be 3.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -165,7 +165,7 @@ struct msixtbl_entry
>      struct pci_dev *pdev;
>      unsigned long gtable;       /* gpa of msix table */
>      unsigned long table_len;
> -    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + 1];
> +    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
>  #define MAX_MSIX_ACC_ENTRIES 3
>      struct { 
>          uint32_t msi_ad[3];	/* Shadow of address low, high and data */
> @@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin
>  static void __iomem *msixtbl_addr_to_virt(
>      struct msixtbl_entry *entry, unsigned long addr)
>  {
> -    int idx, nr_page;
> +    unsigned int idx, nr_page;
>  
> -    if ( !entry )
> +    if ( !entry || !entry->pdev )
>          return NULL;
>  
>      nr_page = (addr >> PAGE_SHIFT) -
>                (entry->gtable >> PAGE_SHIFT);
>  
> -    if ( !entry->pdev )
> -        return NULL;
> -
>      idx = entry->pdev->msix_table_idx[nr_page];
>      if ( !idx )
>          return NULL;
> @@ -215,37 +212,34 @@ static int msixtbl_read(
>      struct vcpu *v, unsigned long address,
>      unsigned long len, unsigned long *pval)
>  {
> -    unsigned long offset, val;
> +    unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
> -    virt = msixtbl_addr_to_virt(entry, address);
> -    if ( !virt )
> -        goto out;
> -
> -    nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
>      offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
> -    if ( nr_entry >= MAX_MSIX_ACC_ENTRIES && 
> -         offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
> -        goto out;
>  
> -    val = readl(virt);
>      if ( offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
>      {
> +        nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> +        if ( nr_entry >= MAX_MSIX_ACC_ENTRIES )
> +            goto out;
>          index = offset / sizeof(uint32_t);
>          *pval = entry->gentries[nr_entry].msi_ad[index];
>      }
>      else 
>      {
> -        *pval = val;
> +        virt = msixtbl_addr_to_virt(entry, address);
> +        if ( !virt )
> +            goto out;
> +        *pval = readl(virt);
>      }
>      
>      r = X86EMUL_OKAY;
> @@ -260,13 +254,13 @@ static int msixtbl_write(struct vcpu *v,
>      unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
>      nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>      if ( !virt )
>          goto out;
>  
> +    /* Do not allow the mask bit to be changed. */
> +#if 0 /* XXX
> +       * As the mask bit is the only defined bit in the word, and as the
> +       * host MSI-X code doesn't preserve the other bits anyway, doing
> +       * this is pointless. So for now just discard the write (also
> +       * saving us from having to determine the matching irq_desc).
> +       */
> +    spin_lock_irqsave(&desc->lock, flags);
> +    orig = readl(virt);
> +    val &= ~PCI_MSIX_VECTOR_BITMASK;
> +    val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
> -    r = X86EMUL_OKAY;
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +#endif
>  
> +    r = X86EMUL_OKAY;
>  out:
>      rcu_read_unlock(&msixtbl_rcu_lock);
>      return r;
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -122,12 +122,6 @@ int msi_free_irq(struct msi_desc *entry)
>   */
>  #define NR_HP_RESERVED_VECTORS 	20
>  
> -#define PCI_MSIX_ENTRY_SIZE			16
> -#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> -#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> -#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> -#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> -
>  #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>  #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>  #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -11,6 +11,8 @@
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
>  #include <xen/irq.h>
> +#include <xen/pci_regs.h>
> +#include <xen/pfn.h>
>  #include <asm/pci.h>
>  
>  /*
> @@ -30,8 +32,10 @@
>  #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
>  #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
>  
> -#define MAX_MSIX_TABLE_ENTRIES  2048
> -#define MAX_MSIX_TABLE_PAGES    8
> +#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
> +#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
> +                                       PCI_MSIX_ENTRY_SIZE + \
> +                                       (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))
>  struct pci_dev_info {
>      bool_t is_extfn;
>      bool_t is_virtfn;
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -305,6 +305,12 @@
>  #define PCI_MSIX_PBA		8
>  #define  PCI_MSIX_BIRMASK	(7 << 0)
>  
> +#define PCI_MSIX_ENTRY_SIZE			16
> +#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> +#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> +#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> +#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> +
>  #define PCI_MSIX_VECTOR_BITMASK	(1 << 0)
>  
>  /* CompactPCI Hotswap Register */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:41:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHXD-0005jB-25; Fri, 20 Jan 2012 16:41:51 +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 1RoHXB-0005fs-Em
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:41:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327077702!11770523!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 9931 invoked from network); 20 Jan 2012 16:41:43 -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; 20 Jan 2012 16:41:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:41:42 +0000
Message-Id: <4F19A797020000780006E15B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:42:47 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
In-Reply-To: <4F19A577020000780006E115@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Eddie Dong <eddie.dong@intel.com>, yuan.b.liu@intel.com,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:33, "Jan Beulich" <JBeulich@suse.com> wrote:
> This addresses a number of problems in msixtbl_{read,write}():
> - address alignment was not checked, allowing for memory corruption in
>   the hypervisor (write case) or returning of hypervisor private data
>   to the guest (read case)
> - the interrupt mask bit was permitted to be written by the guest
>   (while Xen's interrupt flow control routines need to control it)
> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>   numbers (making it unobvious why they have these values, and making
>   the latter non-portable)
> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>   non-zero table offset); this was also affecting host MSI-X code
> - struct msixtbl_entry's table_flags[] was one element larger than
>   necessary due to improper open-coding of BITS_TO_LONGS()
> - msixtbl_read() unconditionally accessed the physical table, even
>   though the data was only needed in a quarter of all cases
> - various calculations were done unnecessarily for both of the rather
>   distinct code paths in msixtbl_read()

I should note (as done in the earlier response to the 4.2 todo thread)
that I have no way of actually testing this, so I'm relying on others
here. (Intel? Or, Ian, would the stage tester find issues with passed
through MSI-X capable devices?)

Jan

> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
> chosen to be 3.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -165,7 +165,7 @@ struct msixtbl_entry
>      struct pci_dev *pdev;
>      unsigned long gtable;       /* gpa of msix table */
>      unsigned long table_len;
> -    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + 1];
> +    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
>  #define MAX_MSIX_ACC_ENTRIES 3
>      struct { 
>          uint32_t msi_ad[3];	/* Shadow of address low, high and data */
> @@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin
>  static void __iomem *msixtbl_addr_to_virt(
>      struct msixtbl_entry *entry, unsigned long addr)
>  {
> -    int idx, nr_page;
> +    unsigned int idx, nr_page;
>  
> -    if ( !entry )
> +    if ( !entry || !entry->pdev )
>          return NULL;
>  
>      nr_page = (addr >> PAGE_SHIFT) -
>                (entry->gtable >> PAGE_SHIFT);
>  
> -    if ( !entry->pdev )
> -        return NULL;
> -
>      idx = entry->pdev->msix_table_idx[nr_page];
>      if ( !idx )
>          return NULL;
> @@ -215,37 +212,34 @@ static int msixtbl_read(
>      struct vcpu *v, unsigned long address,
>      unsigned long len, unsigned long *pval)
>  {
> -    unsigned long offset, val;
> +    unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
> -    virt = msixtbl_addr_to_virt(entry, address);
> -    if ( !virt )
> -        goto out;
> -
> -    nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
>      offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
> -    if ( nr_entry >= MAX_MSIX_ACC_ENTRIES && 
> -         offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
> -        goto out;
>  
> -    val = readl(virt);
>      if ( offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
>      {
> +        nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> +        if ( nr_entry >= MAX_MSIX_ACC_ENTRIES )
> +            goto out;
>          index = offset / sizeof(uint32_t);
>          *pval = entry->gentries[nr_entry].msi_ad[index];
>      }
>      else 
>      {
> -        *pval = val;
> +        virt = msixtbl_addr_to_virt(entry, address);
> +        if ( !virt )
> +            goto out;
> +        *pval = readl(virt);
>      }
>      
>      r = X86EMUL_OKAY;
> @@ -260,13 +254,13 @@ static int msixtbl_write(struct vcpu *v,
>      unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
>      nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>      if ( !virt )
>          goto out;
>  
> +    /* Do not allow the mask bit to be changed. */
> +#if 0 /* XXX
> +       * As the mask bit is the only defined bit in the word, and as the
> +       * host MSI-X code doesn't preserve the other bits anyway, doing
> +       * this is pointless. So for now just discard the write (also
> +       * saving us from having to determine the matching irq_desc).
> +       */
> +    spin_lock_irqsave(&desc->lock, flags);
> +    orig = readl(virt);
> +    val &= ~PCI_MSIX_VECTOR_BITMASK;
> +    val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
> -    r = X86EMUL_OKAY;
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +#endif
>  
> +    r = X86EMUL_OKAY;
>  out:
>      rcu_read_unlock(&msixtbl_rcu_lock);
>      return r;
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -122,12 +122,6 @@ int msi_free_irq(struct msi_desc *entry)
>   */
>  #define NR_HP_RESERVED_VECTORS 	20
>  
> -#define PCI_MSIX_ENTRY_SIZE			16
> -#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> -#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> -#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> -#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> -
>  #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>  #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>  #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -11,6 +11,8 @@
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
>  #include <xen/irq.h>
> +#include <xen/pci_regs.h>
> +#include <xen/pfn.h>
>  #include <asm/pci.h>
>  
>  /*
> @@ -30,8 +32,10 @@
>  #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
>  #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
>  
> -#define MAX_MSIX_TABLE_ENTRIES  2048
> -#define MAX_MSIX_TABLE_PAGES    8
> +#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
> +#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
> +                                       PCI_MSIX_ENTRY_SIZE + \
> +                                       (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))
>  struct pci_dev_info {
>      bool_t is_extfn;
>      bool_t is_virtfn;
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -305,6 +305,12 @@
>  #define PCI_MSIX_PBA		8
>  #define  PCI_MSIX_BIRMASK	(7 << 0)
>  
> +#define PCI_MSIX_ENTRY_SIZE			16
> +#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> +#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> +#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> +#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> +
>  #define PCI_MSIX_VECTOR_BITMASK	(1 << 0)
>  
>  /* CompactPCI Hotswap Register */



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:43:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHYn-0006DA-Lo; Fri, 20 Jan 2012 16:43:29 +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 1RoHYm-0006CI-D5
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:43:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327077801!11849035!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5797 invoked from network); 20 Jan 2012 16:43:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114308"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:43:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:43:20 -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 q0KGhGXR016214;
	Fri, 20 Jan 2012 08:43:17 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327077590.30054.71.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Jan 2012 16:43:16 +0000
Message-ID: <1327077796.23358.98.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:39 +0000, Ian Campbell wrote:
> On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> > On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > > cpupools don't seem to do this, I don't know if that is expected or not.
> > > 
> > > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > > at the level where it effects memory allocation. However both
> > > 	pool="Pool-node0" cpus="0-7"
> > > and
> > > 	pool="Pool-node1" cpus="8-15"
> > > work as expected on a system with 8 cpus per node.
> > > 
> > > Should something be doing this pinning automatically?
> > 
> > It seems like it would be useful; But then we have the issue of, if a vm
> > was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> > what do you do?
> 
> I've no idea, it's not clear to me now what the semantics of cpupools
> are if they don't restrict the VCPU affinity like I previously assumed.

Well, it does restrict what cpus the VM will run on; the effective
affinity will be the union of the pool cpus and the vcpu affinity.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:43:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHYn-0006DA-Lo; Fri, 20 Jan 2012 16:43:29 +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 1RoHYm-0006CI-D5
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:43:28 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327077801!11849035!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5797 invoked from network); 20 Jan 2012 16:43:22 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114308"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:43:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:43:20 -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 q0KGhGXR016214;
	Fri, 20 Jan 2012 08:43:17 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327077590.30054.71.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Jan 2012 16:43:16 +0000
Message-ID: <1327077796.23358.98.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:39 +0000, Ian Campbell wrote:
> On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> > On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > > cpupools don't seem to do this, I don't know if that is expected or not.
> > > 
> > > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > > at the level where it effects memory allocation. However both
> > > 	pool="Pool-node0" cpus="0-7"
> > > and
> > > 	pool="Pool-node1" cpus="8-15"
> > > work as expected on a system with 8 cpus per node.
> > > 
> > > Should something be doing this pinning automatically?
> > 
> > It seems like it would be useful; But then we have the issue of, if a vm
> > was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> > what do you do?
> 
> I've no idea, it's not clear to me now what the semantics of cpupools
> are if they don't restrict the VCPU affinity like I previously assumed.

Well, it does restrict what cpus the VM will run on; the effective
affinity will be the union of the pool cpus and the vcpu affinity.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:43:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHZ1-0006Gg-8D; Fri, 20 Jan 2012 16:43: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 1RoHZ0-0006FF-Cd
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:43:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327077814!4420375!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 2633 invoked from network); 20 Jan 2012 16:43:35 -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; 20 Jan 2012 16:43:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:43:34 +0000
Message-Id: <4F19A806020000780006E1E5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:44:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1998B2.1070501@citrix.com>
In-Reply-To: <4F1998B2.1070501@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 20/01/12 16:33, Jan Beulich wrote:
>> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>>      if ( !virt )
>>          goto out;
>>  
>> +    /* Do not allow the mask bit to be changed. */
>> +#if 0 /* XXX
> 
> You appear to still have some debugging in this patch.

No - that's why the comment is there. I wanted to keep the unused
code to make clear what ought to be taking place here.

Jan

>> +       * As the mask bit is the only defined bit in the word, and as the
>> +       * host MSI-X code doesn't preserve the other bits anyway, doing
>> +       * this is pointless. So for now just discard the write (also
>> +       * saving us from having to determine the matching irq_desc).
>> +       */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:43:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:43:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHZ1-0006Gg-8D; Fri, 20 Jan 2012 16:43: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 1RoHZ0-0006FF-Cd
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:43:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327077814!4420375!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 2633 invoked from network); 20 Jan 2012 16:43:35 -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; 20 Jan 2012 16:43:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 16:43:34 +0000
Message-Id: <4F19A806020000780006E1E5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 16:44:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1998B2.1070501@citrix.com>
In-Reply-To: <4F1998B2.1070501@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 20/01/12 16:33, Jan Beulich wrote:
>> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>>      if ( !virt )
>>          goto out;
>>  
>> +    /* Do not allow the mask bit to be changed. */
>> +#if 0 /* XXX
> 
> You appear to still have some debugging in this patch.

No - that's why the comment is there. I wanted to keep the unused
code to make clear what ought to be taking place here.

Jan

>> +       * As the mask bit is the only defined bit in the word, and as the
>> +       * host MSI-X code doesn't preserve the other bits anyway, doing
>> +       * this is pointless. So for now just discard the write (also
>> +       * saving us from having to determine the matching irq_desc).
>> +       */




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:49:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHed-0006tW-5R; Fri, 20 Jan 2012 16:49:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RoHec-0006sU-1o; Fri, 20 Jan 2012 16:49:30 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327078162!8070684!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30038 invoked from network); 20 Jan 2012 16:49:23 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:49:23 -0000
Received: by iahk25 with SMTP id k25so6839161iah.30
	for <multiple recipients>; Fri, 20 Jan 2012 08:49: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=9EfCdhZ5aLt9EjLTSF5DM2i8kSL5PPcAsV0PxTq9fLA=;
	b=i+Su+e4GTs2qgH3EA+IDxjKzpThH4EtTyF1+NQN96rYCPSNHhaZLuGburXufAsNHQG
	uPWyYdEwozYXWG9bW1LG2D3umUwcmw1S8jUvnQzChHIEHgLKPg7w3rHNyFW/1B9Lpj7g
	4PljnT80N0EfsUT/OsT5Gd7VS5+8ezgjNA9KU=
MIME-Version: 1.0
Received: by 10.50.156.138 with SMTP id we10mr3261944igb.10.1327078160275;
	Fri, 20 Jan 2012 08:49:20 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Fri, 20 Jan 2012 08:49:20 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Fri, 20 Jan 2012 08:49:20 -0800 (PST)
In-Reply-To: <20120120154745.GV12984@reaktio.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
Date: Fri, 20 Jan 2012 17:49:20 +0100
Message-ID: <CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3528586843657246612=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3528586843657246612==
Content-Type: multipart/alternative; boundary=e89a8f234aad55176c04b6f87678

--e89a8f234aad55176c04b6f87678
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi,

I have that enabled in my BIOS, VT-d for the chipset and VT-x for the CPU.

Have you managed to pass your gpu through to the domU?

Regards

Sandi
On Jan 20, 2012 4:47 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:

> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> >    Hello,
> >    I have spent a lot of time trying to get gfx passthru working on my
> system
> >    without success.
> >    I looked onto my hardware capabilities again to make sure that it do=
es
> >    support VT-d and I am not too sure that it does fully.
> >    My hardware is as follows:
> >    - Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
> >    - single Xeon X5650 CPU (which is listed as supporting VT-x, no
> mention of
> >    VT-d at [1]ark.intel.com)
> >    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset AND
> CPU
> >    need to support VT-d.
> >    What confuses me is, why is the 55x0 chipset listed there if none of
> the
> >    CPU's supported, that I know of, dont have the VT-d feature option,
> only
> >    VT-x.
> >
>
> I've been using VT-d with Xen with Intel 5500 series chipset, and Xeon
> 5600 series CPU.
> VT-d needs to be enabled in the BIOS.
>
> -- Pasi
>
>

--e89a8f234aad55176c04b6f87678
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>Pasi,</p>
<p>I have that enabled in my BIOS, VT-d for the chipset and VT-x for the CP=
U.</p>
<p>Have you managed to pass your gpu through to the domU?</p>
<p>Regards</p>
<p>Sandi</p>
<div class=3D"gmail_quote">On Jan 20, 2012 4:47 PM, &quot;Pasi K=E4rkk=E4in=
en&quot; &lt;<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt; wrote:<br=
 type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
&gt; =A0 =A0Hello,<br>
&gt; =A0 =A0I have spent a lot of time trying to get gfx passthru working o=
n my system<br>
&gt; =A0 =A0without success.<br>
&gt; =A0 =A0I looked onto my hardware capabilities again to make sure that =
it does<br>
&gt; =A0 =A0support VT-d and I am not too sure that it does fully.<br>
&gt; =A0 =A0My hardware is as follows:<br>
&gt; =A0 =A0- Supermicro X8DTH-6F motherboard (5520 chipset which supports =
VT-d)<br>
&gt; =A0 =A0- single Xeon X5650 CPU (which is listed as supporting VT-x, no=
 mention of<br>
&gt; =A0 =A0VT-d at [1]<a href=3D"http://ark.intel.com" target=3D"_blank">a=
rk.intel.com</a>)<br>
&gt; =A0 =A0Now, according to the [2]VTdHowTo, the motherboard BIOS, chipse=
t AND CPU<br>
&gt; =A0 =A0need to support VT-d.<br>
&gt; =A0 =A0What confuses me is, why is the 55x0 chipset listed there if no=
ne of the<br>
&gt; =A0 =A0CPU&#39;s supported, that I know of, dont have the VT-d feature=
 option, only<br>
&gt; =A0 =A0VT-x.<br>
&gt;<br>
<br>
I&#39;ve been using VT-d with Xen with Intel 5500 series chipset, and Xeon =
5600 series CPU.<br>
VT-d needs to be enabled in the BIOS.<br>
<br>
-- Pasi<br>
<br>
</blockquote></div>

--e89a8f234aad55176c04b6f87678--


--===============3528586843657246612==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3528586843657246612==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:49:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHed-0006tW-5R; Fri, 20 Jan 2012 16:49:31 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RoHec-0006sU-1o; Fri, 20 Jan 2012 16:49:30 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327078162!8070684!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30038 invoked from network); 20 Jan 2012 16:49:23 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:49:23 -0000
Received: by iahk25 with SMTP id k25so6839161iah.30
	for <multiple recipients>; Fri, 20 Jan 2012 08:49: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=9EfCdhZ5aLt9EjLTSF5DM2i8kSL5PPcAsV0PxTq9fLA=;
	b=i+Su+e4GTs2qgH3EA+IDxjKzpThH4EtTyF1+NQN96rYCPSNHhaZLuGburXufAsNHQG
	uPWyYdEwozYXWG9bW1LG2D3umUwcmw1S8jUvnQzChHIEHgLKPg7w3rHNyFW/1B9Lpj7g
	4PljnT80N0EfsUT/OsT5Gd7VS5+8ezgjNA9KU=
MIME-Version: 1.0
Received: by 10.50.156.138 with SMTP id we10mr3261944igb.10.1327078160275;
	Fri, 20 Jan 2012 08:49:20 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Fri, 20 Jan 2012 08:49:20 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Fri, 20 Jan 2012 08:49:20 -0800 (PST)
In-Reply-To: <20120120154745.GV12984@reaktio.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
Date: Fri, 20 Jan 2012 17:49:20 +0100
Message-ID: <CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============3528586843657246612=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3528586843657246612==
Content-Type: multipart/alternative; boundary=e89a8f234aad55176c04b6f87678

--e89a8f234aad55176c04b6f87678
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi,

I have that enabled in my BIOS, VT-d for the chipset and VT-x for the CPU.

Have you managed to pass your gpu through to the domU?

Regards

Sandi
On Jan 20, 2012 4:47 PM, "Pasi K=E4rkk=E4inen" <pasik@iki.fi> wrote:

> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> >    Hello,
> >    I have spent a lot of time trying to get gfx passthru working on my
> system
> >    without success.
> >    I looked onto my hardware capabilities again to make sure that it do=
es
> >    support VT-d and I am not too sure that it does fully.
> >    My hardware is as follows:
> >    - Supermicro X8DTH-6F motherboard (5520 chipset which supports VT-d)
> >    - single Xeon X5650 CPU (which is listed as supporting VT-x, no
> mention of
> >    VT-d at [1]ark.intel.com)
> >    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset AND
> CPU
> >    need to support VT-d.
> >    What confuses me is, why is the 55x0 chipset listed there if none of
> the
> >    CPU's supported, that I know of, dont have the VT-d feature option,
> only
> >    VT-x.
> >
>
> I've been using VT-d with Xen with Intel 5500 series chipset, and Xeon
> 5600 series CPU.
> VT-d needs to be enabled in the BIOS.
>
> -- Pasi
>
>

--e89a8f234aad55176c04b6f87678
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>Pasi,</p>
<p>I have that enabled in my BIOS, VT-d for the chipset and VT-x for the CP=
U.</p>
<p>Have you managed to pass your gpu through to the domU?</p>
<p>Regards</p>
<p>Sandi</p>
<div class=3D"gmail_quote">On Jan 20, 2012 4:47 PM, &quot;Pasi K=E4rkk=E4in=
en&quot; &lt;<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt; wrote:<br=
 type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
&gt; =A0 =A0Hello,<br>
&gt; =A0 =A0I have spent a lot of time trying to get gfx passthru working o=
n my system<br>
&gt; =A0 =A0without success.<br>
&gt; =A0 =A0I looked onto my hardware capabilities again to make sure that =
it does<br>
&gt; =A0 =A0support VT-d and I am not too sure that it does fully.<br>
&gt; =A0 =A0My hardware is as follows:<br>
&gt; =A0 =A0- Supermicro X8DTH-6F motherboard (5520 chipset which supports =
VT-d)<br>
&gt; =A0 =A0- single Xeon X5650 CPU (which is listed as supporting VT-x, no=
 mention of<br>
&gt; =A0 =A0VT-d at [1]<a href=3D"http://ark.intel.com" target=3D"_blank">a=
rk.intel.com</a>)<br>
&gt; =A0 =A0Now, according to the [2]VTdHowTo, the motherboard BIOS, chipse=
t AND CPU<br>
&gt; =A0 =A0need to support VT-d.<br>
&gt; =A0 =A0What confuses me is, why is the 55x0 chipset listed there if no=
ne of the<br>
&gt; =A0 =A0CPU&#39;s supported, that I know of, dont have the VT-d feature=
 option, only<br>
&gt; =A0 =A0VT-x.<br>
&gt;<br>
<br>
I&#39;ve been using VT-d with Xen with Intel 5500 series chipset, and Xeon =
5600 series CPU.<br>
VT-d needs to be enabled in the BIOS.<br>
<br>
-- Pasi<br>
<br>
</blockquote></div>

--e89a8f234aad55176c04b6f87678--


--===============3528586843657246612==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3528586843657246612==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:52:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHgz-0007HT-T1; Fri, 20 Jan 2012 16:51: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 1RoHgy-0007GK-4X
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:51:56 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327078308!9190348!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30889 invoked from network); 20 Jan 2012 16:51:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178445305"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:51:00 -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, 20 Jan 2012
	11:50:59 -0500
Message-ID: <4F199B72.6030100@citrix.com>
Date: Fri, 20 Jan 2012 16:50: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1998B2.1070501@citrix.com>
	<4F19A806020000780006E1E5@nat28.tlf.novell.com>
In-Reply-To: <4F19A806020000780006E1E5@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 20/01/12 16:44, Jan Beulich wrote:
>>>> On 20.01.12 at 17:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 20/01/12 16:33, Jan Beulich wrote:
>>> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>>>      if ( !virt )
>>>          goto out;
>>>  
>>> +    /* Do not allow the mask bit to be changed. */
>>> +#if 0 /* XXX
>> You appear to still have some debugging in this patch.
> No - that's why the comment is there. I wanted to keep the unused
> code to make clear what ought to be taking place here.
>
> Jan

Ah - that makes a little more sense.  That was going to be my next query
for clarification.

I have some hardware at my disposal which can do SRIOV and PCI
passthrough with MSI-X capable network cards.

Any specific things you want testing, other than just a basic
passthrough and verify the cards are working?

~Andrew

>>> +       * As the mask bit is the only defined bit in the word, and as the
>>> +       * host MSI-X code doesn't preserve the other bits anyway, doing
>>> +       * this is pointless. So for now just discard the write (also
>>> +       * saving us from having to determine the matching irq_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 Jan 20 16:52:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:52:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHgz-0007HT-T1; Fri, 20 Jan 2012 16:51: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 1RoHgy-0007GK-4X
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:51:56 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327078308!9190348!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30889 invoked from network); 20 Jan 2012 16:51:50 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:51:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178445305"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:51:00 -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, 20 Jan 2012
	11:50:59 -0500
Message-ID: <4F199B72.6030100@citrix.com>
Date: Fri, 20 Jan 2012 16:50: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1998B2.1070501@citrix.com>
	<4F19A806020000780006E1E5@nat28.tlf.novell.com>
In-Reply-To: <4F19A806020000780006E1E5@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 20/01/12 16:44, Jan Beulich wrote:
>>>> On 20.01.12 at 17:39, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 20/01/12 16:33, Jan Beulich wrote:
>>> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>>>      if ( !virt )
>>>          goto out;
>>>  
>>> +    /* Do not allow the mask bit to be changed. */
>>> +#if 0 /* XXX
>> You appear to still have some debugging in this patch.
> No - that's why the comment is there. I wanted to keep the unused
> code to make clear what ought to be taking place here.
>
> Jan

Ah - that makes a little more sense.  That was going to be my next query
for clarification.

I have some hardware at my disposal which can do SRIOV and PCI
passthrough with MSI-X capable network cards.

Any specific things you want testing, other than just a basic
passthrough and verify the cards are working?

~Andrew

>>> +       * As the mask bit is the only defined bit in the word, and as the
>>> +       * host MSI-X code doesn't preserve the other bits anyway, doing
>>> +       * this is pointless. So for now just discard the write (also
>>> +       * saving us from having to determine the matching irq_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 Jan 20 16:55:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHkH-0007cc-Hr; Fri, 20 Jan 2012 16:55:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoHkG-0007cI-QT
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:55:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327078512!1933173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13934 invoked from network); 20 Jan 2012 16:55:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:55:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182968"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:55: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;
	Fri, 20 Jan 2012 16:55:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Fri, 20 Jan 2012 16:55:11 +0000
In-Reply-To: <1327077796.23358.98.camel@elijah>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327078511.30054.75.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:43 +0000, George Dunlap wrote:
> On Fri, 2012-01-20 at 16:39 +0000, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> > > On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > > > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > > > cpupools don't seem to do this, I don't know if that is expected or not.
> > > > 
> > > > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > > > at the level where it effects memory allocation. However both
> > > > 	pool="Pool-node0" cpus="0-7"
> > > > and
> > > > 	pool="Pool-node1" cpus="8-15"
> > > > work as expected on a system with 8 cpus per node.
> > > > 
> > > > Should something be doing this pinning automatically?
> > > 
> > > It seems like it would be useful; But then we have the issue of, if a vm
> > > was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> > > what do you do?
> > 
> > I've no idea, it's not clear to me now what the semantics of cpupools
> > are if they don't restrict the VCPU affinity like I previously assumed.
> 
> Well, it does restrict what cpus the VM will run on; the effective
> affinity will be the union of the pool cpus and the vcpu affinity.

Did you mean intersection?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:55:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHkH-0007cc-Hr; Fri, 20 Jan 2012 16:55:21 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoHkG-0007cI-QT
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:55:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327078512!1933173!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13934 invoked from network); 20 Jan 2012 16:55:12 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:55:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182968"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:55: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;
	Fri, 20 Jan 2012 16:55:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Fri, 20 Jan 2012 16:55:11 +0000
In-Reply-To: <1327077796.23358.98.camel@elijah>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327078511.30054.75.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:43 +0000, George Dunlap wrote:
> On Fri, 2012-01-20 at 16:39 +0000, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> > > On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > > > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > > > cpupools don't seem to do this, I don't know if that is expected or not.
> > > > 
> > > > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > > > at the level where it effects memory allocation. However both
> > > > 	pool="Pool-node0" cpus="0-7"
> > > > and
> > > > 	pool="Pool-node1" cpus="8-15"
> > > > work as expected on a system with 8 cpus per node.
> > > > 
> > > > Should something be doing this pinning automatically?
> > > 
> > > It seems like it would be useful; But then we have the issue of, if a vm
> > > was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> > > what do you do?
> > 
> > I've no idea, it's not clear to me now what the semantics of cpupools
> > are if they don't restrict the VCPU affinity like I previously assumed.
> 
> Well, it does restrict what cpus the VM will run on; the effective
> affinity will be the union of the pool cpus and the vcpu affinity.

Did you mean intersection?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:56:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHl1-0007gA-0Q; Fri, 20 Jan 2012 16:56: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 1RoHkz-0007fi-UN
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:56:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327078460!11694695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26307 invoked from network); 20 Jan 2012 16:54:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:54:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:54: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, 20 Jan 2012 16:54:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Fri, 20 Jan 2012 16:54:20 +0000
In-Reply-To: <1327077796.23358.98.camel@elijah>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327078460.30054.74.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:43 +0000, George Dunlap wrote:
> On Fri, 2012-01-20 at 16:39 +0000, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> > > On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > > > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > > > cpupools don't seem to do this, I don't know if that is expected or not.
> > > > 
> > > > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > > > at the level where it effects memory allocation. However both
> > > > 	pool="Pool-node0" cpus="0-7"
> > > > and
> > > > 	pool="Pool-node1" cpus="8-15"
> > > > work as expected on a system with 8 cpus per node.
> > > > 
> > > > Should something be doing this pinning automatically?
> > > 
> > > It seems like it would be useful; But then we have the issue of, if a vm
> > > was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> > > what do you do?
> > 
> > I've no idea, it's not clear to me now what the semantics of cpupools
> > are if they don't restrict the VCPU affinity like I previously assumed.
> 
> Well, it does restrict what cpus the VM will run on; the effective
> affinity will be the union of the pool cpus and the vcpu affinity.

Ah, right.

I confused myself into thinking that cpupools ~= NUMA because I've only
used cpupool-numa-split but I can see that you might also divide your
cpus up some other way.

Should that same union be used for d->node_affinity though? It seems
like it would make sense.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:56:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16: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 1RoHl1-0007gA-0Q; Fri, 20 Jan 2012 16:56: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 1RoHkz-0007fi-UN
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:56:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327078460!11694695!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26307 invoked from network); 20 Jan 2012 16:54:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:54:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182958"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:54: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, 20 Jan 2012 16:54:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Fri, 20 Jan 2012 16:54:20 +0000
In-Reply-To: <1327077796.23358.98.camel@elijah>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327078460.30054.74.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>, Ian
	Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:43 +0000, George Dunlap wrote:
> On Fri, 2012-01-20 at 16:39 +0000, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> > > On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > > > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > > > cpupools don't seem to do this, I don't know if that is expected or not.
> > > > 
> > > > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > > > at the level where it effects memory allocation. However both
> > > > 	pool="Pool-node0" cpus="0-7"
> > > > and
> > > > 	pool="Pool-node1" cpus="8-15"
> > > > work as expected on a system with 8 cpus per node.
> > > > 
> > > > Should something be doing this pinning automatically?
> > > 
> > > It seems like it would be useful; But then we have the issue of, if a vm
> > > was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> > > what do you do?
> > 
> > I've no idea, it's not clear to me now what the semantics of cpupools
> > are if they don't restrict the VCPU affinity like I previously assumed.
> 
> Well, it does restrict what cpus the VM will run on; the effective
> affinity will be the union of the pool cpus and the vcpu affinity.

Ah, right.

I confused myself into thinking that cpupools ~= NUMA because I've only
used cpupool-numa-split but I can see that you might also divide your
cpus up some other way.

Should that same union be used for d->node_affinity though? It seems
like it would make sense.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:59:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHnh-0007xH-Lw; Fri, 20 Jan 2012 16:58:53 +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 1RoHnf-0007wM-NA
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:58:52 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327078725!3098986!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 27444 invoked from network); 20 Jan 2012 16:58:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 16:58:45 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74902102; Fri, 20 Jan 2012 17:58:44 +0100
Message-ID: <1327078723.2337.56.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 17:58:43 +0100
In-Reply-To: <1327076495.30054.63.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0300536030400594491=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0300536030400594491==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Kid6RToKsq+SSlPA8iwJ"


--=-Kid6RToKsq+SSlPA8iwJ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:=20
> I think I made the rather basic c*ckup of using a domain configured with
> more memory than is in any single node.
>=20
Well, that is one of the most interesting use cases, indeed! :-)

Seriously, I really expect to have some very hard time when I'll come to
consider scenarios like that one...

> With your affinity patches and the domain restricted to a single node
> via cpu affinity The Right Thing seems to happen.
>=20
> cpupools don't seem to do this, I don't know if that is expected or not.
>=20
Glad to know my patches are (well, could be!) useful for something!
About cpupool, I think if a domain is created as part of the pool, the
very same behaviour you achieve with my patches should be expected.
However, as George is correctly pointing out, that might turn out to be
quite bad if the domain is then moved! :-(

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)



--=-Kid6RToKsq+SSlPA8iwJ
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)

iEYEABECAAYFAk8ZnUMACgkQk4XaBE3IOsRbAQCfVYj9vaZ1GQ8/emMg2ygi1SdE
HQEAn0RvXBvtiIbnWOwUWluwpk00KBia
=z86g
-----END PGP SIGNATURE-----

--=-Kid6RToKsq+SSlPA8iwJ--



--===============0300536030400594491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0300536030400594491==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:59:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 16:59:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHnh-0007xH-Lw; Fri, 20 Jan 2012 16:58:53 +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 1RoHnf-0007wM-NA
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:58:52 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327078725!3098986!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 27444 invoked from network); 20 Jan 2012 16:58:45 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 16:58:45 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74902102; Fri, 20 Jan 2012 17:58:44 +0100
Message-ID: <1327078723.2337.56.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 17:58:43 +0100
In-Reply-To: <1327076495.30054.63.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0300536030400594491=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0300536030400594491==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-Kid6RToKsq+SSlPA8iwJ"


--=-Kid6RToKsq+SSlPA8iwJ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:=20
> I think I made the rather basic c*ckup of using a domain configured with
> more memory than is in any single node.
>=20
Well, that is one of the most interesting use cases, indeed! :-)

Seriously, I really expect to have some very hard time when I'll come to
consider scenarios like that one...

> With your affinity patches and the domain restricted to a single node
> via cpu affinity The Right Thing seems to happen.
>=20
> cpupools don't seem to do this, I don't know if that is expected or not.
>=20
Glad to know my patches are (well, could be!) useful for something!
About cpupool, I think if a domain is created as part of the pool, the
very same behaviour you achieve with my patches should be expected.
However, as George is correctly pointing out, that might turn out to be
quite bad if the domain is then moved! :-(

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)



--=-Kid6RToKsq+SSlPA8iwJ
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)

iEYEABECAAYFAk8ZnUMACgkQk4XaBE3IOsRbAQCfVYj9vaZ1GQ8/emMg2ygi1SdE
HQEAn0RvXBvtiIbnWOwUWluwpk00KBia
=z86g
-----END PGP SIGNATURE-----

--=-Kid6RToKsq+SSlPA8iwJ--



--===============0300536030400594491==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0300536030400594491==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:59:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoHoG-00084O-AD; Fri, 20 Jan 2012 16:59:28 +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 1RoHoF-00083h-I1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:59:27 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327078703!57791732!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19638 invoked from network); 20 Jan 2012 16:58:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:58:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178446699"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:59:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:59:18 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0KGxEKb016263;
	Fri, 20 Jan 2012 08:59:14 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327078511.30054.75.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078511.30054.75.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Jan 2012 16:59:13 +0000
Message-ID: <1327078753.23358.100.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:55 +0000, Ian Campbell wrote:
> On Fri, 2012-01-20 at 16:43 +0000, George Dunlap wrote:
> > On Fri, 2012-01-20 at 16:39 +0000, Ian Campbell wrote:
> > > On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> > > > On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > > > > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > > > > cpupools don't seem to do this, I don't know if that is expected or not.
> > > > > 
> > > > > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > > > > at the level where it effects memory allocation. However both
> > > > > 	pool="Pool-node0" cpus="0-7"
> > > > > and
> > > > > 	pool="Pool-node1" cpus="8-15"
> > > > > work as expected on a system with 8 cpus per node.
> > > > > 
> > > > > Should something be doing this pinning automatically?
> > > > 
> > > > It seems like it would be useful; But then we have the issue of, if a vm
> > > > was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> > > > what do you do?
> > > 
> > > I've no idea, it's not clear to me now what the semantics of cpupools
> > > are if they don't restrict the VCPU affinity like I previously assumed.
> > 
> > Well, it does restrict what cpus the VM will run on; the effective
> > affinity will be the union of the pool cpus and the vcpu affinity.
> 
> Did you mean intersection?

Hmm, seems it's been too long since I used set theory. :-)  Yes,
intersection; (i.e., a vcpu will run on a cpu only if the cpu is in the
affinity mask and the cpu pool).

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 16:59:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 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 1RoHoG-00084O-AD; Fri, 20 Jan 2012 16:59:28 +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 1RoHoF-00083h-I1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 16:59:27 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327078703!57791732!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19638 invoked from network); 20 Jan 2012 16:58:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:58:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178446699"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:59:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:59:18 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0KGxEKb016263;
	Fri, 20 Jan 2012 08:59:14 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327078511.30054.75.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078511.30054.75.camel@zakaz.uk.xensource.com>
Date: Fri, 20 Jan 2012 16:59:13 +0000
Message-ID: <1327078753.23358.100.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: xen-devel <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:55 +0000, Ian Campbell wrote:
> On Fri, 2012-01-20 at 16:43 +0000, George Dunlap wrote:
> > On Fri, 2012-01-20 at 16:39 +0000, Ian Campbell wrote:
> > > On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> > > > On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > > > > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > > > > cpupools don't seem to do this, I don't know if that is expected or not.
> > > > > 
> > > > > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > > > > at the level where it effects memory allocation. However both
> > > > > 	pool="Pool-node0" cpus="0-7"
> > > > > and
> > > > > 	pool="Pool-node1" cpus="8-15"
> > > > > work as expected on a system with 8 cpus per node.
> > > > > 
> > > > > Should something be doing this pinning automatically?
> > > > 
> > > > It seems like it would be useful; But then we have the issue of, if a vm
> > > > was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> > > > what do you do?
> > > 
> > > I've no idea, it's not clear to me now what the semantics of cpupools
> > > are if they don't restrict the VCPU affinity like I previously assumed.
> > 
> > Well, it does restrict what cpus the VM will run on; the effective
> > affinity will be the union of the pool cpus and the vcpu affinity.
> 
> Did you mean intersection?

Hmm, seems it's been too long since I used set theory. :-)  Yes,
intersection; (i.e., a vcpu will run on a cpu only if the cpu is in the
affinity mask and the cpu pool).

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:02:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoHrD-0008QV-V9; Fri, 20 Jan 2012 17:02:31 +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 1RoHrC-0008Q3-V7
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:02:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327078837!1690295!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 32635 invoked from network); 20 Jan 2012 17:00:37 -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; 20 Jan 2012 17:00:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 17:00:36 +0000
Message-Id: <4F19AC06020000780006E255@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 17:01:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1998B2.1070501@citrix.com>
	<4F19A806020000780006E1E5@nat28.tlf.novell.com>
	<4F199B72.6030100@citrix.com>
In-Reply-To: <4F199B72.6030100@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:50, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> I have some hardware at my disposal which can do SRIOV and PCI
> passthrough with MSI-X capable network cards.
> 
> Any specific things you want testing, other than just a basic
> passthrough and verify the cards are working?

No, nothing specific. Thanks for taking on this!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:02:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoHrD-0008QV-V9; Fri, 20 Jan 2012 17:02:31 +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 1RoHrC-0008Q3-V7
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:02:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327078837!1690295!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 32635 invoked from network); 20 Jan 2012 17:00:37 -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; 20 Jan 2012 17:00:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Fri, 20 Jan 2012 17:00:36 +0000
Message-Id: <4F19AC06020000780006E255@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Fri, 20 Jan 2012 17:01:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1998B2.1070501@citrix.com>
	<4F19A806020000780006E1E5@nat28.tlf.novell.com>
	<4F199B72.6030100@citrix.com>
In-Reply-To: <4F199B72.6030100@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 17:50, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> I have some hardware at my disposal which can do SRIOV and PCI
> passthrough with MSI-X capable network cards.
> 
> Any specific things you want testing, other than just a basic
> passthrough and verify the cards are working?

No, nothing specific. Thanks for taking on this!

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:03:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHry-0008Vj-DH; Fri, 20 Jan 2012 17:03:18 +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 1RoHrw-0008Up-JN
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:03:16 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327078989!13256712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8820 invoked from network); 20 Jan 2012 17:03:10 -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;
	20 Jan 2012 17:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21115417"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:03:09 -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, 20 Jan 2012
	12:03:09 -0500
Message-ID: <4F199E4B.5000401@citrix.com>
Date: Fri, 20 Jan 2012 17:03:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1998B2.1070501@citrix.com>
	<4F19A806020000780006E1E5@nat28.tlf.novell.com>
	<4F199B72.6030100@citrix.com>
	<4F19AC06020000780006E255@nat28.tlf.novell.com>
In-Reply-To: <4F19AC06020000780006E255@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/12 17:01, Jan Beulich wrote:
>>>> On 20.01.12 at 17:50, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> I have some hardware at my disposal which can do SRIOV and PCI
>> passthrough with MSI-X capable network cards.
>>
>> Any specific things you want testing, other than just a basic
>> passthrough and verify the cards are working?
> No, nothing specific. Thanks for taking on this!
>
> Jan

No problem.  I will try to get the testing done early next week - I have
other hypervisior bugs I am currently working on right at the moment.

-- 
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 Jan 20 17:03:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoHry-0008Vj-DH; Fri, 20 Jan 2012 17:03:18 +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 1RoHrw-0008Up-JN
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:03:16 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327078989!13256712!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8820 invoked from network); 20 Jan 2012 17:03:10 -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;
	20 Jan 2012 17:03:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21115417"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:03:09 -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, 20 Jan 2012
	12:03:09 -0500
Message-ID: <4F199E4B.5000401@citrix.com>
Date: Fri, 20 Jan 2012 17:03:07 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1998B2.1070501@citrix.com>
	<4F19A806020000780006E1E5@nat28.tlf.novell.com>
	<4F199B72.6030100@citrix.com>
	<4F19AC06020000780006E255@nat28.tlf.novell.com>
In-Reply-To: <4F19AC06020000780006E255@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: "yuan.b.liu@intel.com" <yuan.b.liu@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Eddie Dong <eddie.dong@intel.com>
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/12 17:01, Jan Beulich wrote:
>>>> On 20.01.12 at 17:50, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> I have some hardware at my disposal which can do SRIOV and PCI
>> passthrough with MSI-X capable network cards.
>>
>> Any specific things you want testing, other than just a basic
>> passthrough and verify the cards are working?
> No, nothing specific. Thanks for taking on this!
>
> Jan

No problem.  I will try to get the testing done early next week - I have
other hypervisior bugs I am currently working on right at the moment.

-- 
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 Jan 20 17:21:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI96-0000jj-8E; Fri, 20 Jan 2012 17:21: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 1RoI94-0000jW-8W
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:20:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327080051!10030961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28791 invoked from network); 20 Jan 2012 17:20:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:20:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10183493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 17:20: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; Fri, 20 Jan 2012 17:20:50 +0000
Date: Fri, 20 Jan 2012 17:20:37 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this is the fourth version of the Xen save/restore patch series.
We have been discussing this issue for quite a while on #qemu and
qemu-devel:


http://marc.info/?l=qemu-devel&m=132346828427314&w=2
http://marc.info/?l=qemu-devel&m=132377734605464&w=2


A few different approaches were proposed to achieve the goal
of a working save/restore with upstream Qemu on Xen, however after
prototyping some of them I came up with yet another solution, that I
think leads to the best results with the less amount of code
duplications and ugliness.
Far from saying that this patch series is an example of elegance and
simplicity, but it is closer to acceptable anything else I have seen so
far.

What's new is that Qemu is going to keep track of its own physmap on
xenstore, so that Xen can be fully aware of the changes Qemu makes to
the guest's memory map at any time.
This is all handled by Xen or Xen support in Qemu internally and can be
used to solve our save/restore framebuffer problem.

>From the Qemu common code POV, we still need to avoid saving the guest's
ram when running on Xen, and we need to avoid resetting the videoram on
restore (that is a benefit to the generic Qemu case too, because it
saves few cpu cycles).


Changes in v4:

- keep a record of the MemoryRegion's name on xenstore;

- print a message when avoiding a memory allocation on restore.


This is the list of patches with a diffstat:

Anthony PERARD (4):
      vl.c: do not save the RAM state when Xen is enabled
      xen mapcache: check if memory region has moved.
      cirrus_vga: do not reset videoram on resume
      xen: change memory access behavior during migration.

Stefano Stabellini (2):
      Set runstate to INMIGRATE earlier
      xen: record physmap changes to xenstore

 hw/cirrus_vga.c |    9 +++-
 vl.c            |    8 ++-
 xen-all.c       |  112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen-mapcache.c  |   22 +++++++++-
 xen-mapcache.h  |    9 +++-
 5 files changed, 147 insertions(+), 13 deletions(-)


git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-4

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:21:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:21:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI96-0000jj-8E; Fri, 20 Jan 2012 17:21: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 1RoI94-0000jW-8W
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:20:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327080051!10030961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28791 invoked from network); 20 Jan 2012 17:20:51 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:20:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10183493"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 17:20: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; Fri, 20 Jan 2012 17:20:50 +0000
Date: Fri, 20 Jan 2012 17:20:37 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this is the fourth version of the Xen save/restore patch series.
We have been discussing this issue for quite a while on #qemu and
qemu-devel:


http://marc.info/?l=qemu-devel&m=132346828427314&w=2
http://marc.info/?l=qemu-devel&m=132377734605464&w=2


A few different approaches were proposed to achieve the goal
of a working save/restore with upstream Qemu on Xen, however after
prototyping some of them I came up with yet another solution, that I
think leads to the best results with the less amount of code
duplications and ugliness.
Far from saying that this patch series is an example of elegance and
simplicity, but it is closer to acceptable anything else I have seen so
far.

What's new is that Qemu is going to keep track of its own physmap on
xenstore, so that Xen can be fully aware of the changes Qemu makes to
the guest's memory map at any time.
This is all handled by Xen or Xen support in Qemu internally and can be
used to solve our save/restore framebuffer problem.

>From the Qemu common code POV, we still need to avoid saving the guest's
ram when running on Xen, and we need to avoid resetting the videoram on
restore (that is a benefit to the generic Qemu case too, because it
saves few cpu cycles).


Changes in v4:

- keep a record of the MemoryRegion's name on xenstore;

- print a message when avoiding a memory allocation on restore.


This is the list of patches with a diffstat:

Anthony PERARD (4):
      vl.c: do not save the RAM state when Xen is enabled
      xen mapcache: check if memory region has moved.
      cirrus_vga: do not reset videoram on resume
      xen: change memory access behavior during migration.

Stefano Stabellini (2):
      Set runstate to INMIGRATE earlier
      xen: record physmap changes to xenstore

 hw/cirrus_vga.c |    9 +++-
 vl.c            |    8 ++-
 xen-all.c       |  112 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen-mapcache.c  |   22 +++++++++-
 xen-mapcache.h  |    9 +++-
 5 files changed, 147 insertions(+), 13 deletions(-)


git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-4

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:21:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9m-0000mh-MK; Fri, 20 Jan 2012 17:21:42 +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 1RoI9l-0000mN-QQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327080094!4425088!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30958 invoked from network); 20 Jan 2012 17:21:35 -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;
	20 Jan 2012 17:21:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21116089"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21: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, 20 Jan 2012 12:21: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 q0KHLOUc016285;
	Fri, 20 Jan 2012 09:21:24 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:20 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 1/6] vl.c: do not save the RAM state when Xen
	is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Anthony PERARD <anthony.perard@citrix.com>

In the 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>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index ba55b35..6f0435b 100644
--- a/vl.c
+++ b/vl.c
@@ -3270,8 +3270,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;
-- 
1.7.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 Jan 20 17:21:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:21:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9m-0000mh-MK; Fri, 20 Jan 2012 17:21:42 +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 1RoI9l-0000mN-QQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327080094!4425088!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30958 invoked from network); 20 Jan 2012 17:21:35 -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;
	20 Jan 2012 17:21:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21116089"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21: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, 20 Jan 2012 12:21: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 q0KHLOUc016285;
	Fri, 20 Jan 2012 09:21:24 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:20 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 1/6] vl.c: do not save the RAM state when Xen
	is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Anthony PERARD <anthony.perard@citrix.com>

In the 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>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index ba55b35..6f0435b 100644
--- a/vl.c
+++ b/vl.c
@@ -3270,8 +3270,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;
-- 
1.7.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 Jan 20 17:21:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoI9s-0000nQ-3x; Fri, 20 Jan 2012 17:21:48 +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 1RoI9r-0000mZ-2F
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327080094!4425088!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31057 invoked from network); 20 Jan 2012 17:21:40 -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;
	20 Jan 2012 17:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21116091"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:21: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 q0KHLOUd016285;
	Fri, 20 Jan 2012 09:21:27 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:21 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 2/6] xen mapcache: check if memory region 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

From: Anthony PERARD <anthony.perard@citrix.com>

This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index c86ebf4..507d93d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -964,7 +980,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 9fecc64..d9c995b 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)
 {
 }
 
-- 
1.7.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 Jan 20 17:21:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoI9s-0000nQ-3x; Fri, 20 Jan 2012 17:21:48 +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 1RoI9r-0000mZ-2F
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327080094!4425088!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31057 invoked from network); 20 Jan 2012 17:21:40 -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;
	20 Jan 2012 17:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21116091"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:21: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 q0KHLOUd016285;
	Fri, 20 Jan 2012 09:21:27 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:21 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 2/6] xen mapcache: check if memory region 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

From: Anthony PERARD <anthony.perard@citrix.com>

This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index c86ebf4..507d93d 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -964,7 +980,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 9fecc64..d9c995b 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)
 {
 }
 
-- 
1.7.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 Jan 20 17:22:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9u-0000nr-Hc; Fri, 20 Jan 2012 17:21:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoI9t-0000mt-7D
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327080100!9824090!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2794 invoked from network); 20 Jan 2012 17:21:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178450574"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21: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, 20 Jan 2012 12:21: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 q0KHLOUe016285;
	Fri, 20 Jan 2012 09:21:29 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:22 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: qemu-devel@nongnu.org, jan.kiszka@siemens.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 3/6] Set runstate to INMIGRATE earlier
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 6f0435b..bb0139f 100644
--- a/vl.c
+++ b/vl.c
@@ -2972,6 +2972,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_INMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
@@ -3468,7 +3469,6 @@ int main(int argc, char **argv, char **envp)
     }
 
     if (incoming) {
-        runstate_set(RUN_STATE_INMIGRATE);
         int ret = qemu_start_incoming_migration(incoming);
         if (ret < 0) {
             fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:22:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9u-0000nr-Hc; Fri, 20 Jan 2012 17:21:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoI9t-0000mt-7D
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327080100!9824090!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2794 invoked from network); 20 Jan 2012 17:21:42 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178450574"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21: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, 20 Jan 2012 12:21: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 q0KHLOUe016285;
	Fri, 20 Jan 2012 09:21:29 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:22 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: qemu-devel@nongnu.org, jan.kiszka@siemens.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 3/6] Set runstate to INMIGRATE earlier
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index 6f0435b..bb0139f 100644
--- a/vl.c
+++ b/vl.c
@@ -2972,6 +2972,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_INMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
@@ -3468,7 +3469,6 @@ int main(int argc, char **argv, char **envp)
     }
 
     if (incoming) {
-        runstate_set(RUN_STATE_INMIGRATE);
         int ret = qemu_start_incoming_migration(incoming);
         if (ret < 0) {
             fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:22:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9v-0000oK-Ck; Fri, 20 Jan 2012 17:21:51 +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 1RoI9u-0000n1-Er
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327080100!9824090!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3106 invoked from network); 20 Jan 2012 17:21:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178450575"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21: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, 20 Jan 2012 12:21: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 q0KHLOUf016285;
	Fri, 20 Jan 2012 09:21:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:23 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 4/6] cirrus_vga: do not reset videoram on
	resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Anthony PERARD <anthony.perard@citrix.com>

When resuming we shouldn't set the videoram to 0xff considering that we
are about to read it from the savefile.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index f7b1d3d..eec2fc0 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:
@@ -2760,9 +2761,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_INMIGRATE)) {
+        /* Win2K seems to assume that the pattern buffer is at 0xff
+           initially ! */
+        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    }
 
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:22:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9v-0000oK-Ck; Fri, 20 Jan 2012 17:21:51 +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 1RoI9u-0000n1-Er
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327080100!9824090!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3106 invoked from network); 20 Jan 2012 17:21:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:21:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178450575"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21: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, 20 Jan 2012 12:21: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 q0KHLOUf016285;
	Fri, 20 Jan 2012 09:21:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:23 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 4/6] cirrus_vga: do not reset videoram on
	resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Anthony PERARD <anthony.perard@citrix.com>

When resuming we shouldn't set the videoram to 0xff considering that we
are about to read it from the savefile.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index f7b1d3d..eec2fc0 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:
@@ -2760,9 +2761,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_INMIGRATE)) {
+        /* Win2K seems to assume that the pattern buffer is at 0xff
+           initially ! */
+        memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
+    }
 
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:22:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9u-0000o3-UK; Fri, 20 Jan 2012 17:21:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoI9t-0000mn-82
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327080100!9824090!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2761 invoked from network); 20 Jan 2012 17:21:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:21:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178450569"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:21: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 q0KHLOUg016285;
	Fri, 20 Jan 2012 09:21:32 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:24 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: qemu-devel@nongnu.org, jan.kiszka@siemens.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 5/6] xen: record physmap changes to xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 507d93d..bb66c82 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -63,7 +63,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 typedef struct XenPhysmap {
     target_phys_addr_t start_addr;
     ram_addr_t size;
-    MemoryRegion *mr;
+    char *name;
     target_phys_addr_t phys_offset;
 
     QLIST_ENTRY(XenPhysmap) list;
@@ -253,6 +253,7 @@ static int xen_add_to_physmap(XenIOState *state,
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+    char path[80], value[17];
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -291,6 +292,7 @@ go_physmap:
 
     physmap->start_addr = start_addr;
     physmap->size = size;
+    physmap->name = (char *)mr->name;
     physmap->phys_offset = phys_offset;
 
     QLIST_INSERT_HEAD(&state->physmap, physmap, list);
@@ -299,6 +301,30 @@ go_physmap:
                                    start_addr >> TARGET_PAGE_BITS,
                                    (start_addr + size) >> TARGET_PAGE_BITS,
                                    XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    if (mr->name) {
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                xen_domid, (uint64_t)phys_offset);
+        if (!xs_write(state->xenstore, 0, path, mr->name, strlen(mr->name))) {
+            return -1;
+        }
+    }
+
     return 0;
 }
 
@@ -926,6 +952,55 @@ int xen_init(void)
     return 0;
 }
 
+static void xen_read_physmap(XenIOState *state)
+{
+    XenPhysmap *physmap = NULL;
+    unsigned int len, num, i;
+    char path[80], *value = NULL;
+    char **entries = NULL;
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap", xen_domid);
+    entries = xs_directory(state->xenstore, 0, path, &num);
+    if (entries == NULL)
+        return;
+
+    for (i = 0; i < num; i++) {
+        physmap = g_malloc(sizeof (XenPhysmap));
+        physmap->phys_offset = strtoull(entries[i], NULL, 16);
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->start_addr = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/size",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->size = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/name",
+                xen_domid, entries[i]);
+        physmap->name = xs_read(state->xenstore, 0, path, &len);
+
+        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+    }
+    free(entries);
+    return;
+}
+
 int xen_hvm_init(void)
 {
     int i, rc;
@@ -998,6 +1073,7 @@ int xen_hvm_init(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
+    xen_read_physmap(state);
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:22:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9u-0000o3-UK; Fri, 20 Jan 2012 17:21:50 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoI9t-0000mn-82
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327080100!9824090!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2761 invoked from network); 20 Jan 2012 17:21:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:21:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178450569"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:21: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 q0KHLOUg016285;
	Fri, 20 Jan 2012 09:21:32 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:24 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: qemu-devel@nongnu.org, jan.kiszka@siemens.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 5/6] xen: record physmap changes to xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 507d93d..bb66c82 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -63,7 +63,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 typedef struct XenPhysmap {
     target_phys_addr_t start_addr;
     ram_addr_t size;
-    MemoryRegion *mr;
+    char *name;
     target_phys_addr_t phys_offset;
 
     QLIST_ENTRY(XenPhysmap) list;
@@ -253,6 +253,7 @@ static int xen_add_to_physmap(XenIOState *state,
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+    char path[80], value[17];
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -291,6 +292,7 @@ go_physmap:
 
     physmap->start_addr = start_addr;
     physmap->size = size;
+    physmap->name = (char *)mr->name;
     physmap->phys_offset = phys_offset;
 
     QLIST_INSERT_HEAD(&state->physmap, physmap, list);
@@ -299,6 +301,30 @@ go_physmap:
                                    start_addr >> TARGET_PAGE_BITS,
                                    (start_addr + size) >> TARGET_PAGE_BITS,
                                    XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    if (mr->name) {
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                xen_domid, (uint64_t)phys_offset);
+        if (!xs_write(state->xenstore, 0, path, mr->name, strlen(mr->name))) {
+            return -1;
+        }
+    }
+
     return 0;
 }
 
@@ -926,6 +952,55 @@ int xen_init(void)
     return 0;
 }
 
+static void xen_read_physmap(XenIOState *state)
+{
+    XenPhysmap *physmap = NULL;
+    unsigned int len, num, i;
+    char path[80], *value = NULL;
+    char **entries = NULL;
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap", xen_domid);
+    entries = xs_directory(state->xenstore, 0, path, &num);
+    if (entries == NULL)
+        return;
+
+    for (i = 0; i < num; i++) {
+        physmap = g_malloc(sizeof (XenPhysmap));
+        physmap->phys_offset = strtoull(entries[i], NULL, 16);
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->start_addr = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/size",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->size = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/name",
+                xen_domid, entries[i]);
+        physmap->name = xs_read(state->xenstore, 0, path, &len);
+
+        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+    }
+    free(entries);
+    return;
+}
+
 int xen_hvm_init(void)
 {
     int i, rc;
@@ -998,6 +1073,7 @@ int xen_hvm_init(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
+    xen_read_physmap(state);
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:22:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9y-0000pn-V7; Fri, 20 Jan 2012 17:21:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoI9x-0000nP-Dt
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327080100!9824090!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3296 invoked from network); 20 Jan 2012 17:21:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:21:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178450587"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21: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; Fri, 20 Jan 2012 12:21: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 q0KHLOUh016285;
	Fri, 20 Jan 2012 09:21:34 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:25 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 6/6] 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

From: Anthony PERARD <anthony.perard@citrix.com>

Do not allocate RAM during INMIGRATE runstate.
Do not actually "do" set_memory during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bb66c82..9a80c30 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* RAM already populated in Xen */
+        fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
+                " bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
+                __func__, size, ram_addr); 
+        return;
+    }
+
     if (mr == &ram_memory) {
         return;
     }
@@ -255,6 +263,14 @@ static int xen_add_to_physmap(XenIOState *state,
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
     char path[80], value[17];
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        fprintf(stderr, "%s: do not add "RAM_ADDR_FMT
+                " bytes of ram to physmap at "RAM_ADDR_FMT
+                " when runstate is INMIGRATE\n",
+                __func__, size, start_addr); 
+        return 0;
+    }
+
     if (get_physmapping(state, start_addr, size)) {
         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 Jan 20 17:22:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoI9y-0000pn-V7; Fri, 20 Jan 2012 17:21:54 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoI9x-0000nP-Dt
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:21:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327080100!9824090!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU4MTc=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3296 invoked from network); 20 Jan 2012 17:21:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:21:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="178450587"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:21: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; Fri, 20 Jan 2012 12:21: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 q0KHLOUh016285;
	Fri, 20 Jan 2012 09:21:34 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:21:25 +0000
Message-ID: <1327080085-8673-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.1201201457040.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 6/6] 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

From: Anthony PERARD <anthony.perard@citrix.com>

Do not allocate RAM during INMIGRATE runstate.
Do not actually "do" set_memory during migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bb66c82..9a80c30 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* RAM already populated in Xen */
+        fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
+                " bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
+                __func__, size, ram_addr); 
+        return;
+    }
+
     if (mr == &ram_memory) {
         return;
     }
@@ -255,6 +263,14 @@ static int xen_add_to_physmap(XenIOState *state,
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
     char path[80], value[17];
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        fprintf(stderr, "%s: do not add "RAM_ADDR_FMT
+                " bytes of ram to physmap at "RAM_ADDR_FMT
+                " when runstate is INMIGRATE\n",
+                __func__, size, start_addr); 
+        return 0;
+    }
+
     if (get_physmapping(state, start_addr, size)) {
         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 Jan 20 17:22:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIAh-00018F-Er; Fri, 20 Jan 2012 17:22:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RoIAg-00017f-Dc
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:22:38 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327074748!53417896!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 7466 invoked from network); 20 Jan 2012 15:52:29 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.12)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:52:29 -0000
Received: from mail103-tx2-R.bigfish.com (10.9.14.254) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:53:17 +0000
Received: from mail103-tx2 (localhost [127.0.0.1])	by
	mail103-tx2-R.bigfish.com (Postfix) with ESMTP id 88BB41806BA	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:17 +0000 (UTC)
X-SpamScore: -1
X-BigFish: VPS-1(zf7Izzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h61h)
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 mail103-tx2 (localhost.localdomain [127.0.0.1]) by mail103-tx2
	(MessageSwitch) id 132707477467884_26208;
	Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.241])	by
	mail103-tx2.bigfish.com (Postfix) with ESMTP id 0AA99C01A0	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:54 +0000
X-WSS-ID: 0LY3TG3-02-FYR-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 2529BC80B8	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:52:51 -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, 20 Jan 2012 09:53:10 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 20 Jan 2012 09:52: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, 20 Jan 2012
	10:52:34 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D336F49C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:32 +0000 (GMT)
Message-ID: <4F198E7F.9040709@amd.com>
Date: Fri, 20 Jan 2012 16:55:43 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
In-Reply-To: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
X-Forwarded-Message-Id: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Fwd: [osrc-patches] [PATCH 2 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066820 -3600
# Node ID ea3af8fa078c07d357de79931a102450b59156ea
# Parent  978e61814be49ec544151803be3e3b2717551316
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 978e61814be4 -r ea3af8fa078c 
xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:11 2012 
+0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:20 2012 
+0100
@@ -825,6 +825,9 @@ int guest_iommu_set_base(struct domain *
      if ( !iommu )
          return -EACCES;

+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
+        return 1;
+
      iommu->mmio_base = base;
      base >>= PAGE_SHIFT;

@@ -884,7 +887,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);
@@ -916,6 +919,9 @@ void guest_iommu_destroy(struct domain *
      iommu = domain_iommu(d);
      if ( !iommu )
          return;
+
+    if ( !iommuv2_enabled )
+        return;

      tasklet_kill(&iommu->cmd_buffer_tasklet);
      xfree(iommu);
@@ -944,7 +950,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);
@@ -970,7 +976,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 978e61814be4 -r ea3af8fa078c 
xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Fri Jan 20 14:40:11 2012 
+0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Jan 20 14:40:20 2012 
+0100
@@ -38,6 +38,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)
  {
@@ -799,6 +800,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);

  }
diff -r 978e61814be4 -r ea3af8fa078c xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Fri Jan 20 14:40:11 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Fri Jan 20 14:40:20 2012 +0100
@@ -182,4 +182,6 @@ struct guest_iommu {
      struct guest_iommu_msi  msi;
  };

+extern bool_t iommuv2_enabled;
+
  #endif /* _ASM_X86_64_AMD_IOMMU_H */
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:22:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:22:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIAh-00018F-Er; Fri, 20 Jan 2012 17:22:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RoIAg-00017f-Dc
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:22:38 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327074748!53417896!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 7466 invoked from network); 20 Jan 2012 15:52:29 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE004.bigfish.com) (65.55.88.12)
	by server-3.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	20 Jan 2012 15:52:29 -0000
Received: from mail103-tx2-R.bigfish.com (10.9.14.254) by
	TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:53:17 +0000
Received: from mail103-tx2 (localhost [127.0.0.1])	by
	mail103-tx2-R.bigfish.com (Postfix) with ESMTP id 88BB41806BA	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:53:17 +0000 (UTC)
X-SpamScore: -1
X-BigFish: VPS-1(zf7Izzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h61h)
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 mail103-tx2 (localhost.localdomain [127.0.0.1]) by mail103-tx2
	(MessageSwitch) id 132707477467884_26208;
	Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.241])	by
	mail103-tx2.bigfish.com (Postfix) with ESMTP id 0AA99C01A0	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:54 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server id
	14.1.225.23; Fri, 20 Jan 2012 15:52:54 +0000
X-WSS-ID: 0LY3TG3-02-FYR-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 2529BC80B8	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:52:51 -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, 20 Jan 2012 09:53:10 -0600
Received: from storexhtp01.amd.com (172.24.4.3) by sausexdag04.amd.com
	(163.181.55.4) with Microsoft SMTP Server (TLS) id 14.1.289.1;
	Fri, 20 Jan 2012 09:52: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, 20 Jan 2012
	10:52:34 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id D336F49C0F1	for
	<xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:52:32 +0000 (GMT)
Message-ID: <4F198E7F.9040709@amd.com>
Date: Fri, 20 Jan 2012 16:55:43 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>
References: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
In-Reply-To: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
X-Forwarded-Message-Id: <ea3af8fa078c07d357de.1327074282@gran.amd.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] Fwd: [osrc-patches] [PATCH 2 of 7 V4] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
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 1327066820 -3600
# Node ID ea3af8fa078c07d357de79931a102450b59156ea
# Parent  978e61814be49ec544151803be3e3b2717551316
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 978e61814be4 -r ea3af8fa078c 
xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:11 2012 
+0100
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Fri Jan 20 14:40:20 2012 
+0100
@@ -825,6 +825,9 @@ int guest_iommu_set_base(struct domain *
      if ( !iommu )
          return -EACCES;

+    if ( !is_hvm_domain(d) || !iommuv2_enabled )
+        return 1;
+
      iommu->mmio_base = base;
      base >>= PAGE_SHIFT;

@@ -884,7 +887,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);
@@ -916,6 +919,9 @@ void guest_iommu_destroy(struct domain *
      iommu = domain_iommu(d);
      if ( !iommu )
          return;
+
+    if ( !iommuv2_enabled )
+        return;

      tasklet_kill(&iommu->cmd_buffer_tasklet);
      xfree(iommu);
@@ -944,7 +950,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);
@@ -970,7 +976,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 978e61814be4 -r ea3af8fa078c 
xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Fri Jan 20 14:40:11 2012 
+0100
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Fri Jan 20 14:40:20 2012 
+0100
@@ -38,6 +38,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)
  {
@@ -799,6 +800,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);

  }
diff -r 978e61814be4 -r ea3af8fa078c xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Fri Jan 20 14:40:11 2012 +0100
+++ b/xen/include/asm-x86/amd-iommu.h	Fri Jan 20 14:40:20 2012 +0100
@@ -182,4 +182,6 @@ struct guest_iommu {
      struct guest_iommu_msi  msi;
  };

+extern bool_t iommuv2_enabled;
+
  #endif /* _ASM_X86_64_AMD_IOMMU_H */
_______________________________________________
osrc-patches mailing list
osrc-patches@elbe.amd.com
https://elbe.amd.com/mailman/listinfo/osrc-patches


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:24:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:24:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIBt-0001VZ-Vj; Fri, 20 Jan 2012 17:23: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 1RoIBs-0001Us-66
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:23:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327080210!63327901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7076 invoked from network); 20 Jan 2012 17:23:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:23:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10183559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 17:23: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, 20 Jan 2012 17:23:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 17:23:50 +0000
In-Reply-To: <1327078723.2337.56.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327078723.2337.56.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327080230.30054.77.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:58 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote: 
> > With your affinity patches and the domain restricted to a single node
> > via cpu affinity The Right Thing seems to happen.
> > 
> > cpupools don't seem to do this, I don't know if that is expected or not.
> > 
> Glad to know my patches are (well, could be!) useful for something!
> About cpupool, I think if a domain is created as part of the pool, the
> very same behaviour you achieve with my patches should be expected.
> However, as George is correctly pointing out, that might turn out to be
> quite bad if the domain is then moved! :-(

It's no worse than starting a VM with CPUS pinned one way and then
changing it -- you might end up with CPUS with pessimal access to the
memory assigned to the guest.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:24:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:24:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIBt-0001VZ-Vj; Fri, 20 Jan 2012 17:23: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 1RoIBs-0001Us-66
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:23:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327080210!63327901!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7076 invoked from network); 20 Jan 2012 17:23:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:23:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10183559"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 17:23: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, 20 Jan 2012 17:23:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Fri, 20 Jan 2012 17:23:50 +0000
In-Reply-To: <1327078723.2337.56.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327078723.2337.56.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327080230.30054.77.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:58 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote: 
> > With your affinity patches and the domain restricted to a single node
> > via cpu affinity The Right Thing seems to happen.
> > 
> > cpupools don't seem to do this, I don't know if that is expected or not.
> > 
> Glad to know my patches are (well, could be!) useful for something!
> About cpupool, I think if a domain is created as part of the pool, the
> very same behaviour you achieve with my patches should be expected.
> However, as George is correctly pointing out, that might turn out to be
> quite bad if the domain is then moved! :-(

It's no worse than starting a VM with CPUS pinned one way and then
changing it -- you might end up with CPUS with pessimal access to the
memory assigned to the guest.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:24:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoIC2-0001Ym-CI; Fri, 20 Jan 2012 17:24:02 +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 1RoIC0-0001XY-5B
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:24:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327077362!53423780!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 513 invoked from network); 20 Jan 2012 16:36:03 -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;
	20 Jan 2012 16:36:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114057"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0W016147;
	Fri, 20 Jan 2012 08:36:36 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:02 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 14/27] 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

- 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 4bb54ca..26f2d49 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..adc10bb
--- /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 Jan 20 17:24:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoIC2-0001Ym-CI; Fri, 20 Jan 2012 17:24:02 +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 1RoIC0-0001XY-5B
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:24:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327077362!53423780!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 513 invoked from network); 20 Jan 2012 16:36:03 -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;
	20 Jan 2012 16:36:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114057"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36: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, 20 Jan 2012 11:36: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 q0KGaF0W016147;
	Fri, 20 Jan 2012 08:36:36 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:02 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 14/27] 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

- 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 4bb54ca..26f2d49 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..adc10bb
--- /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 Jan 20 17:24:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoICA-0001cd-2T; Fri, 20 Jan 2012 17:24:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoIC8-0001aG-AS
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:24:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327077539!53424188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13567 invoked from network); 20 Jan 2012 16:38:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:38:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:39:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 16:39:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Fri, 20 Jan 2012 16:39:50 +0000
In-Reply-To: <1327077068.23358.97.camel@elijah>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327077590.30054.71.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > cpupools don't seem to do this, I don't know if that is expected or not.
> > 
> > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > at the level where it effects memory allocation. However both
> > 	pool="Pool-node0" cpus="0-7"
> > and
> > 	pool="Pool-node1" cpus="8-15"
> > work as expected on a system with 8 cpus per node.
> > 
> > Should something be doing this pinning automatically?
> 
> It seems like it would be useful; But then we have the issue of, if a vm
> was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> what do you do?

I've no idea, it's not clear to me now what the semantics of cpupools
are if they don't restrict the VCPU affinity like I previously assumed.

I'm actually struggling to find what libxl does with the poolid or
poolname parameters in libxl_domain_create_info other than write the
latter to /local/domain/<D>/pool_name. I must be missing 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 Jan 20 17:24:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:24:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoICA-0001cd-2T; Fri, 20 Jan 2012 17:24:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RoIC8-0001aG-AS
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:24:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327077539!53424188!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13567 invoked from network); 20 Jan 2012 16:38:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 16:38:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10182525"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 16:39:50 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 20 Jan 2012 16:39:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Date: Fri, 20 Jan 2012 16:39:50 +0000
In-Reply-To: <1327077068.23358.97.camel@elijah>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327077590.30054.71.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Stefano
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Dario Faggioli <raistlin@linux.it>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:31 +0000, George Dunlap wrote:
> On Fri, 2012-01-20 at 16:28 +0000, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 16:21 +0000, Ian Campbell wrote:
> > > cpupools don't seem to do this, I don't know if that is expected or not.
> > 
> > Right, so cpupools do not appear to set the vcpu affinity, at least not
> > at the level where it effects memory allocation. However both
> > 	pool="Pool-node0" cpus="0-7"
> > and
> > 	pool="Pool-node1" cpus="8-15"
> > work as expected on a system with 8 cpus per node.
> > 
> > Should something be doing this pinning automatically?
> 
> It seems like it would be useful; But then we have the issue of, if a vm
> was pinned to cpus 0-3 of Pool-node0, and you move it to Pool-node1,
> what do you do?

I've no idea, it's not clear to me now what the semantics of cpupools
are if they don't restrict the VCPU affinity like I previously assumed.

I'm actually struggling to find what libxl does with the poolid or
poolname parameters in libxl_domain_create_info other than write the
latter to /local/domain/<D>/pool_name. I must be missing 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 Jan 20 17:24:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoICL-0001it-GL; Fri, 20 Jan 2012 17:24:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoICK-0001hx-4P
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:24:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327080231!56580591!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30153 invoked from network); 20 Jan 2012 17:23:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:23:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10183570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 17:24: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, 20 Jan 2012 17:24:19 +0000
Date: Fri, 20 Jan 2012 17:24:16 +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.1201201651210.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/2] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.


Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (2):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap

 tools/libxc/xc_domain_restore.c |   66 ++++++++++++++------
 tools/libxc/xc_domain_save.c    |   17 +++++
 tools/libxc/xenguest.h          |   23 +++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  132 ++++++++++++++++++++++++++++++++++++++-
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 220 insertions(+), 22 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:24:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:24:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoICL-0001it-GL; Fri, 20 Jan 2012 17:24:21 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoICK-0001hx-4P
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:24:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327080231!56580591!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30153 invoked from network); 20 Jan 2012 17:23:51 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:23:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10183570"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 17:24: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, 20 Jan 2012 17:24:19 +0000
Date: Fri, 20 Jan 2012 17:24:16 +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.1201201651210.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/2] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.


Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (2):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap

 tools/libxc/xc_domain_restore.c |   66 ++++++++++++++------
 tools/libxc/xc_domain_save.c    |   17 +++++
 tools/libxc/xenguest.h          |   23 +++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  132 ++++++++++++++++++++++++++++++++++++++-
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 220 insertions(+), 22 deletions(-)


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:25:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIDd-0002Bf-4I; Fri, 20 Jan 2012 17:25:41 +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 1RoIDb-0002BE-Mv
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:25:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327080295!61106375!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20118 invoked from network); 20 Jan 2012 17:24: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;
	20 Jan 2012 17:24:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21116340"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:25:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:25: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 q0KHPTGo016298;
	Fri, 20 Jan 2012 09:25:29 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:25:30 +0000
Message-ID: <1327080331-8931-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.1201201651210.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   66 +++++++++++++++++++++++++++-----------
 tools/libxc/xc_domain_save.c    |   17 ++++++++++
 tools/libxc/xenguest.h          |   23 +++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 90 insertions(+), 22 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 14451d1..72b6d5b 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -702,7 +702,8 @@ static void pagebuf_free(pagebuf_t* buf)
 }
 
 static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
-                           pagebuf_t* buf, int fd, uint32_t dom)
+                           pagebuf_t* buf, int fd, uint32_t dom,
+                           struct restore_callbacks* callbacks)
 {
     int count, countpages, oldcount, i;
     void* ptmp;
@@ -725,7 +726,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
     case XC_SAVE_ID_ENABLE_VERIFY_MODE:
         DPRINTF("Entering page verify mode\n");
         buf->verify = 1;
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_VCPU_INFO:
         buf->new_ctxt_format = 1;
@@ -736,7 +737,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("Max VCPU ID: %d, vcpumap: %llx\n", buf->max_vcpu_id, buf->vcpumap);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_IDENT_PT:
         /* Skip padding 4 bytes then read the EPT identity PT location. */
@@ -747,7 +748,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_VM86_TSS:
         /* Skip padding 4 bytes then read the vm86 TSS location. */
@@ -758,7 +759,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("VM86 TSS location: %llx\n", buf->vm86_tss);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TMEM:
         DPRINTF("xc_domain_restore start tmem\n");
@@ -766,14 +767,14 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tmem");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TMEM_EXTRA:
         if ( xc_tmem_restore_extra(xch, dom, fd) ) {
             PERROR("error reading/restoring tmem extra");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TSC_INFO:
     {
@@ -787,7 +788,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tsc info");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
     }
 
     case XC_SAVE_ID_HVM_CONSOLE_PFN :
@@ -799,12 +800,12 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("console pfn location: %llx\n", buf->console_pfn);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_LAST_CHECKPOINT:
         ctx->last_checkpoint = 1;
         // DPRINTF("last checkpoint indication received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -814,7 +815,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the acpi ioport location");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_VIRIDIAN:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -824,8 +825,33 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the viridian flag");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            uint32_t len;
+            uint8_t *buf2;
+            RDEXACT(fd, &len, sizeof(len));
+            buf2 = (uint8_t*) malloc(len);
+            if ( buf2 == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf2, len);
+            if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+            {
+                if ( callbacks->toolstack_restore(dom,
+                            buf2, len, callbacks->data) < 0 )
+                {
+                    PERROR("error calling toolstack_restore");
+                    free(buf2);
+                    return -1;
+                }
+            }
+            free(buf2);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
+        }
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -834,7 +860,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
          */
         ctx->compressing = 1;
         // DPRINTF("compression flag received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_COMPRESSED_DATA:
 
@@ -902,7 +928,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
      * following a <XC_SAVE_ID_COMPRESSED_DATA, compressedChunkSize> tuple.
      */
     if (buf->compressing)
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     oldcount = buf->nr_physpages;
     buf->nr_physpages += countpages;
@@ -927,7 +953,8 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
 }
 
 static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
-                       pagebuf_t* buf, int fd, uint32_t dom)
+                       pagebuf_t* buf, int fd, uint32_t dom,
+                       struct restore_callbacks *callbacks)
 {
     int rc;
 
@@ -935,7 +962,7 @@ static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
     buf->compbuf_pos = buf->compbuf_size = 0;
 
     do {
-        rc = pagebuf_get_one(xch, ctx, buf, fd, dom);
+        rc = pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
     } while (rc > 0);
 
     if (rc < 0)
@@ -1248,7 +1275,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 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,
+                      struct restore_callbacks* callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1427,7 +1455,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         if ( !ctx->completed ) {
             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
             pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
-            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
+            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom, callbacks) < 0 ) {
                 PERROR("Error when reading batch");
                 goto out;
             }
@@ -1542,7 +1570,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     // DPRINTF("Buffered checkpoint\n");
 
-    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
+    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom, callbacks) ) {
         PERROR("error when buffering batch, finishing");
         goto finish;
     }
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index a6bb894..67bcfe2 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1676,6 +1676,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 4475ee9..3cac30c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -61,6 +69,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    struct save_callbacks* callbacks, int hvm);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -72,12 +90,15 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @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 callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       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,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index c5e0743..68feec5 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -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_TOOLSTACK          -14 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..fd2b051 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -373,7 +373,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     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, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 985cbec..eb1d31c 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -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,
+                            NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:25:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:25:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIDd-0002Bf-4I; Fri, 20 Jan 2012 17:25:41 +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 1RoIDb-0002BE-Mv
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:25:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327080295!61106375!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20118 invoked from network); 20 Jan 2012 17:24: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;
	20 Jan 2012 17:24:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21116340"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:25:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:25: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 q0KHPTGo016298;
	Fri, 20 Jan 2012 09:25:29 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:25:30 +0000
Message-ID: <1327080331-8931-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.1201201651210.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   66 +++++++++++++++++++++++++++-----------
 tools/libxc/xc_domain_save.c    |   17 ++++++++++
 tools/libxc/xenguest.h          |   23 +++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    3 +-
 6 files changed, 90 insertions(+), 22 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 14451d1..72b6d5b 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -702,7 +702,8 @@ static void pagebuf_free(pagebuf_t* buf)
 }
 
 static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
-                           pagebuf_t* buf, int fd, uint32_t dom)
+                           pagebuf_t* buf, int fd, uint32_t dom,
+                           struct restore_callbacks* callbacks)
 {
     int count, countpages, oldcount, i;
     void* ptmp;
@@ -725,7 +726,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
     case XC_SAVE_ID_ENABLE_VERIFY_MODE:
         DPRINTF("Entering page verify mode\n");
         buf->verify = 1;
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_VCPU_INFO:
         buf->new_ctxt_format = 1;
@@ -736,7 +737,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("Max VCPU ID: %d, vcpumap: %llx\n", buf->max_vcpu_id, buf->vcpumap);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_IDENT_PT:
         /* Skip padding 4 bytes then read the EPT identity PT location. */
@@ -747,7 +748,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_VM86_TSS:
         /* Skip padding 4 bytes then read the vm86 TSS location. */
@@ -758,7 +759,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("VM86 TSS location: %llx\n", buf->vm86_tss);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TMEM:
         DPRINTF("xc_domain_restore start tmem\n");
@@ -766,14 +767,14 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tmem");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TMEM_EXTRA:
         if ( xc_tmem_restore_extra(xch, dom, fd) ) {
             PERROR("error reading/restoring tmem extra");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_TSC_INFO:
     {
@@ -787,7 +788,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tsc info");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
     }
 
     case XC_SAVE_ID_HVM_CONSOLE_PFN :
@@ -799,12 +800,12 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("console pfn location: %llx\n", buf->console_pfn);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_LAST_CHECKPOINT:
         ctx->last_checkpoint = 1;
         // DPRINTF("last checkpoint indication received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -814,7 +815,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the acpi ioport location");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_HVM_VIRIDIAN:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -824,8 +825,33 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the viridian flag");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            uint32_t len;
+            uint8_t *buf2;
+            RDEXACT(fd, &len, sizeof(len));
+            buf2 = (uint8_t*) malloc(len);
+            if ( buf2 == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, buf2, len);
+            if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+            {
+                if ( callbacks->toolstack_restore(dom,
+                            buf2, len, callbacks->data) < 0 )
+                {
+                    PERROR("error calling toolstack_restore");
+                    free(buf2);
+                    return -1;
+                }
+            }
+            free(buf2);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
+        }
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -834,7 +860,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
          */
         ctx->compressing = 1;
         // DPRINTF("compression flag received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     case XC_SAVE_ID_COMPRESSED_DATA:
 
@@ -902,7 +928,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
      * following a <XC_SAVE_ID_COMPRESSED_DATA, compressedChunkSize> tuple.
      */
     if (buf->compressing)
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
 
     oldcount = buf->nr_physpages;
     buf->nr_physpages += countpages;
@@ -927,7 +953,8 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
 }
 
 static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
-                       pagebuf_t* buf, int fd, uint32_t dom)
+                       pagebuf_t* buf, int fd, uint32_t dom,
+                       struct restore_callbacks *callbacks)
 {
     int rc;
 
@@ -935,7 +962,7 @@ static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
     buf->compbuf_pos = buf->compbuf_size = 0;
 
     do {
-        rc = pagebuf_get_one(xch, ctx, buf, fd, dom);
+        rc = pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
     } while (rc > 0);
 
     if (rc < 0)
@@ -1248,7 +1275,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 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,
+                      struct restore_callbacks* callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1427,7 +1455,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         if ( !ctx->completed ) {
             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
             pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
-            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
+            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom, callbacks) < 0 ) {
                 PERROR("Error when reading batch");
                 goto out;
             }
@@ -1542,7 +1570,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     // DPRINTF("Buffered checkpoint\n");
 
-    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
+    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom, callbacks) ) {
         PERROR("error when buffering batch, finishing");
         goto finish;
     }
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index a6bb894..67bcfe2 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1676,6 +1676,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 4475ee9..3cac30c 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -61,6 +69,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    struct save_callbacks* callbacks, int hvm);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -72,12 +90,15 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @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 callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       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,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index c5e0743..68feec5 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -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_TOOLSTACK          -14 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c898d89..fd2b051 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -373,7 +373,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     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, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 985cbec..eb1d31c 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -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,
+                            NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:25:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoIDk-0002En-H8; Fri, 20 Jan 2012 17:25:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoIDj-0002Ck-H4
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:25:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327080295!61106375!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20404 invoked from network); 20 Jan 2012 17:25:01 -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;
	20 Jan 2012 17:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21116354"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:25:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:25: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 q0KHPTGp016298;
	Fri, 20 Jan 2012 09:25:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:25:31 +0000
Message-ID: <1327080331-8931-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.1201201651210.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fd2b051..644d0d2 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -347,6 +347,66 @@ out:
     return rc;
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+
+    if (size < sizeof(version) + sizeof(count))
+        return -1;
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION)
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, pi->phys_offset), "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, pi->phys_offset), "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -356,11 +416,14 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -373,7 +436,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages, NULL);
+                           hvm, pae, superpages, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -528,6 +591,72 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -579,6 +708,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
-- 
1.7.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 Jan 20 17:25:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoIDk-0002En-H8; Fri, 20 Jan 2012 17:25:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RoIDj-0002Ck-H4
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:25:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327080295!61106375!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20404 invoked from network); 20 Jan 2012 17:25:01 -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;
	20 Jan 2012 17:25:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21116354"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 12:25:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 12:25: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 q0KHPTGp016298;
	Fri, 20 Jan 2012 09:25:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 17:25:31 +0000
Message-ID: <1327080331-8931-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.1201201651210.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fd2b051..644d0d2 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -347,6 +347,66 @@ out:
     return rc;
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+
+    if (size < sizeof(version) + sizeof(count))
+        return -1;
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION)
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, pi->phys_offset), "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, pi->phys_offset), "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -356,11 +416,14 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         hvm = 1;
         superpages = 1;
         pae = info->u.hvm.pae;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -373,7 +436,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
-                           hvm, pae, superpages, NULL);
+                           hvm, pae, superpages, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -528,6 +591,72 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -579,6 +708,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks, hvm);
-- 
1.7.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 Jan 20 17:29:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoIH1-0002yt-N9; Fri, 20 Jan 2012 17:29:11 +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 1RoIGz-0002yA-KC
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:29:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327080540!11919689!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 23248 invoked from network); 20 Jan 2012 17:29:00 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 17:29:00 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74902676; Fri, 20 Jan 2012 18:28:59 +0100
Message-ID: <1327080538.2337.62.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 18:28:58 +0100
In-Reply-To: <1327080230.30054.77.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327078723.2337.56.camel@Abyss>
	<1327080230.30054.77.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0223270325007295738=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0223270325007295738==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-b/7Bqd/TyS+hGSyUV+Yv"


--=-b/7Bqd/TyS+hGSyUV+Yv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 17:23 +0000, Ian Campbell wrote:=20
> It's no worse than starting a VM with CPUS pinned one way and then
> changing it -- you might end up with CPUS with pessimal access to the
> memory assigned to the guest.
>=20
It is exactly the same thing! What one can argue is that right now,
_without_ my xl-cpupin patches, you CAN'T really start a VM with CPUs
pinned (at least with xl, as it seems you can with xm/xend)... :-P

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)



--=-b/7Bqd/TyS+hGSyUV+Yv
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)

iEYEABECAAYFAk8ZpFoACgkQk4XaBE3IOsSinQCfYLFLApk72bZi07MLRc1h6qV0
EScAn1znVm4ND4u+FGNRSqLiqEd0T+LS
=EnIU
-----END PGP SIGNATURE-----

--=-b/7Bqd/TyS+hGSyUV+Yv--



--===============0223270325007295738==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0223270325007295738==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:29:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoIH1-0002yt-N9; Fri, 20 Jan 2012 17:29:11 +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 1RoIGz-0002yA-KC
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:29:09 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327080540!11919689!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 23248 invoked from network); 20 Jan 2012 17:29:00 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-8.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 17:29:00 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74902676; Fri, 20 Jan 2012 18:28:59 +0100
Message-ID: <1327080538.2337.62.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 18:28:58 +0100
In-Reply-To: <1327080230.30054.77.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327078723.2337.56.camel@Abyss>
	<1327080230.30054.77.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0223270325007295738=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0223270325007295738==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-b/7Bqd/TyS+hGSyUV+Yv"


--=-b/7Bqd/TyS+hGSyUV+Yv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 17:23 +0000, Ian Campbell wrote:=20
> It's no worse than starting a VM with CPUS pinned one way and then
> changing it -- you might end up with CPUS with pessimal access to the
> memory assigned to the guest.
>=20
It is exactly the same thing! What one can argue is that right now,
_without_ my xl-cpupin patches, you CAN'T really start a VM with CPUs
pinned (at least with xl, as it seems you can with xm/xend)... :-P

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)



--=-b/7Bqd/TyS+hGSyUV+Yv
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)

iEYEABECAAYFAk8ZpFoACgkQk4XaBE3IOsSinQCfYLFLApk72bZi07MLRc1h6qV0
EScAn1znVm4ND4u+FGNRSqLiqEd0T+LS
=EnIU
-----END PGP SIGNATURE-----

--=-b/7Bqd/TyS+hGSyUV+Yv--



--===============0223270325007295738==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0223270325007295738==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:29:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIHJ-000336-5b; Fri, 20 Jan 2012 17:29:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RoIHH-00032G-Ke
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:29:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327080560!9975505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1338 invoked from network); 20 Jan 2012 17:29:21 -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;
	20 Jan 2012 17:29:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10183664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 17:29:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 17:29: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 1RoIHA-0000C8-3k;
	Fri, 20 Jan 2012 17:29:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoIHA-0002GA-13;
	Fri, 20 Jan 2012 17:29:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10915-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Jan 2012 17:29:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10915: 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 10915 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10915/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore       fail REGR. vs. 10913
 test-amd64-i386-xend-winxpsp3  8 guest-saverestore        fail REGR. vs. 10913
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10902
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10913
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10906
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore        fail REGR. vs. 10913
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10913
 test-i386-i386-xl-winxpsp3    8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-xl-winxpsp3-vcpus1  8 guest-saverestore   fail REGR. vs. 10913

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-win          7 windows-install              fail   like 10913

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

version targeted for testing:
 xen                  87854d3bed93
baseline version:
 xen                  2273ef2083d4

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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:   24529:87854d3bed93
tag:         tip
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Fri Jan 20 10:40:16 2012 +0000
    
    vpmu: separate architecture specific PMU initialisation
    
    This patch moves the architecture specific initialisation of the PMU
    into the archicture specific directory.
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24528:3d58058fc7a2
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:26:57 2012 +0000
    
    x86/hvm: Remove unnecessary packed attribute from hvm_hw_cpu_xsave struct.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24527:028230eb2359
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Fri Jan 20 10:20:32 2012 +0000
    
    iommu: Move IOMMU faults handling into softirq for AMD-Vi.
    
    Dealing with interrupts from AMD-Vi IOMMU(s) 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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24526:d600a3d7faee
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Jan 20 10:17:12 2012 +0000
    
    x86/hvm: Allow wake up of offline vcpu via nmi-ipi
    
    On a real machine a cpu disabled via hlt with interrupts disabled can
    be reactivated via a nmi ipi. Enable the hypervisor to do this for
    hvm, too.
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24525:a3f67482c321
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:13:55 2012 +0000
    
    xen: Simplify callers of boot_vcpu(). In VCPUOP_up, check
    is_initialised under the per-domain lock.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24524:2273ef2083d4
user:        Tim Deegan <tim@xen.org>
date:        Thu Jan 19 13:09:23 2012 +0000
    
    x86/mm: refine epte_present test
    
    The current test for a present ept entry checks for a permission bit
    to be set.
    
    While this is valid in contexts in which we want to know whether an entry
    will fault, it is not correct when it comes to testing whether an entry is
    valid. Specifically, in the ept_change_entry_type_page function which is
    used to set entries to the log dirty type.
    
    In combination with a p2m access type like n or n2rwx, log dirty will not be
    set for ept entries for which it should.
    
    Reported-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Jan 20 17:29:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:29:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIHJ-000336-5b; Fri, 20 Jan 2012 17:29:29 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RoIHH-00032G-Ke
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:29:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327080560!9975505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1338 invoked from network); 20 Jan 2012 17:29:21 -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;
	20 Jan 2012 17:29:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320624000"; d="scan'208";a="10183664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 17:29:20 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 17:29: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 1RoIHA-0000C8-3k;
	Fri, 20 Jan 2012 17:29:20 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoIHA-0002GA-13;
	Fri, 20 Jan 2012 17:29:20 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10915-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Jan 2012 17:29:20 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10915: 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 10915 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10915/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore       fail REGR. vs. 10913
 test-amd64-i386-xend-winxpsp3  8 guest-saverestore        fail REGR. vs. 10913
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10902
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10913
 test-amd64-i386-win-vcpus1    8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10906
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore        fail REGR. vs. 10913
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 10913
 test-i386-i386-xl-winxpsp3    8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-xl-winxpsp3-vcpus1  8 guest-saverestore   fail REGR. vs. 10913

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-win          7 windows-install              fail   like 10913

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

version targeted for testing:
 xen                  87854d3bed93
baseline version:
 xen                  2273ef2083d4

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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:   24529:87854d3bed93
tag:         tip
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Fri Jan 20 10:40:16 2012 +0000
    
    vpmu: separate architecture specific PMU initialisation
    
    This patch moves the architecture specific initialisation of the PMU
    into the archicture specific directory.
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24528:3d58058fc7a2
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:26:57 2012 +0000
    
    x86/hvm: Remove unnecessary packed attribute from hvm_hw_cpu_xsave struct.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24527:028230eb2359
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Fri Jan 20 10:20:32 2012 +0000
    
    iommu: Move IOMMU faults handling into softirq for AMD-Vi.
    
    Dealing with interrupts from AMD-Vi IOMMU(s) 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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24526:d600a3d7faee
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Jan 20 10:17:12 2012 +0000
    
    x86/hvm: Allow wake up of offline vcpu via nmi-ipi
    
    On a real machine a cpu disabled via hlt with interrupts disabled can
    be reactivated via a nmi ipi. Enable the hypervisor to do this for
    hvm, too.
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24525:a3f67482c321
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:13:55 2012 +0000
    
    xen: Simplify callers of boot_vcpu(). In VCPUOP_up, check
    is_initialised under the per-domain lock.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24524:2273ef2083d4
user:        Tim Deegan <tim@xen.org>
date:        Thu Jan 19 13:09:23 2012 +0000
    
    x86/mm: refine epte_present test
    
    The current test for a present ept entry checks for a permission bit
    to be set.
    
    While this is valid in contexts in which we want to know whether an entry
    will fault, it is not correct when it comes to testing whether an entry is
    valid. Specifically, in the ept_change_entry_type_page function which is
    used to set entries to the log dirty type.
    
    In combination with a p2m access type like n or n2rwx, log dirty will not be
    set for ept entries for which it should.
    
    Reported-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Jan 20 17:35:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoINB-0003Vt-ID; Fri, 20 Jan 2012 17:35:33 +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 1RoIN9-0003VZ-Vk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:35:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327080769!9856960!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 21889 invoked from network); 20 Jan 2012 17:32:50 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 17:32:50 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74902766; Fri, 20 Jan 2012 18:32:49 +0100
Message-ID: <1327080768.2337.65.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 18:32:48 +0100
In-Reply-To: <1327078460.30054.74.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078460.30054.74.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7914952055398166999=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7914952055398166999==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-UWrnpNr439JFMAMhDRvw"


--=-UWrnpNr439JFMAMhDRvw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 16:54 +0000, Ian Campbell wrote:=20
> I confused myself into thinking that cpupools ~=3D NUMA because I've only
> used cpupool-numa-split but I can see that you might also divide your
> cpus up some other way.
>=20
Yeah, indeed, although the numa-split case looks like the most useful
one to me.

> Should that same union be used for d->node_affinity though? It seems
> like it would make sense.
>=20
According to me, it should. Then, at least right now, moving it would
probably kill its performances because all its memory will be far away,
while right now it's all more "stochastic".

Still, I think it should be done, as if you place a domain in a cpupool
at its creation, I think the case of moving it away from there would be
quite rare.

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)



--=-UWrnpNr439JFMAMhDRvw
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)

iEYEABECAAYFAk8ZpUAACgkQk4XaBE3IOsT0zQCfXIW1CYXk2evbh5IuRkDP19xI
V/0AnRHZzEVbTmsPjP4YMAhTkMiakXtZ
=fkwu
-----END PGP SIGNATURE-----

--=-UWrnpNr439JFMAMhDRvw--



--===============7914952055398166999==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7914952055398166999==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:35:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoINB-0003Vt-ID; Fri, 20 Jan 2012 17:35:33 +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 1RoIN9-0003VZ-Vk
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:35:32 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327080769!9856960!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 21889 invoked from network); 20 Jan 2012 17:32:50 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 17:32:50 -0000
Received: from [62.94.181.134] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74902766; Fri, 20 Jan 2012 18:32:49 +0100
Message-ID: <1327080768.2337.65.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Fri, 20 Jan 2012 18:32:48 +0100
In-Reply-To: <1327078460.30054.74.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078460.30054.74.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7914952055398166999=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7914952055398166999==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-UWrnpNr439JFMAMhDRvw"


--=-UWrnpNr439JFMAMhDRvw
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-01-20 at 16:54 +0000, Ian Campbell wrote:=20
> I confused myself into thinking that cpupools ~=3D NUMA because I've only
> used cpupool-numa-split but I can see that you might also divide your
> cpus up some other way.
>=20
Yeah, indeed, although the numa-split case looks like the most useful
one to me.

> Should that same union be used for d->node_affinity though? It seems
> like it would make sense.
>=20
According to me, it should. Then, at least right now, moving it would
probably kill its performances because all its memory will be far away,
while right now it's all more "stochastic".

Still, I think it should be done, as if you place a domain in a cpupool
at its creation, I think the case of moving it away from there would be
quite rare.

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)



--=-UWrnpNr439JFMAMhDRvw
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)

iEYEABECAAYFAk8ZpUAACgkQk4XaBE3IOsT0zQCfXIW1CYXk2evbh5IuRkDP19xI
V/0AnRHZzEVbTmsPjP4YMAhTkMiakXtZ
=fkwu
-----END PGP SIGNATURE-----

--=-UWrnpNr439JFMAMhDRvw--



--===============7914952055398166999==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7914952055398166999==--



From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:43:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoIUV-0003kB-Ul; Fri, 20 Jan 2012 17:43: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 1RoIUT-0003k6-Gw
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:43:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327077362!53423780!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2041 invoked from network); 20 Jan 2012 16:36:04 -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;
	20 Jan 2012 16:36:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114058"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:36: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 q0KGaF0X016147;
	Fri, 20 Jan 2012 08:36:38 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:03 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 15/27] 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

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 Jan 20 17:43:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17: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 1RoIUV-0003kB-Ul; Fri, 20 Jan 2012 17:43: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 1RoIUT-0003k6-Gw
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:43:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327077362!53423780!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2041 invoked from network); 20 Jan 2012 16:36:04 -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;
	20 Jan 2012 16:36:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,543,1320642000"; d="scan'208";a="21114058"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 11:36:55 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 11:36: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 q0KGaF0X016147;
	Fri, 20 Jan 2012 08:36:38 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 16:36:03 +0000
Message-ID: <1327077375-7623-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.1201201605370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>, Tim.Deegan@citrix.com
Subject: [Xen-devel] [PATCH v6 15/27] 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

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 Jan 20 17:51:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIc3-00048h-3E; Fri, 20 Jan 2012 17:50:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RoIc1-00048c-Ob
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:50:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327081847!11909532!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 23444 invoked from network); 20 Jan 2012 17:50:47 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:50:47 -0000
Received: by werb14 with SMTP id b14so2969729wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:50: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=40bdU7z1isfkuHrfckyTY6a3taECCCx5Dp6B1QmBtuo=;
	b=qi0Q/CTHDjAPEcC+65DezjSZdL3U5OaCa+jDc6JH/FiNPQTV2+RLDMYfvGkwDemZO+
	srz5X9I2/UQ3SfJBGhmdbwRkQv8EN6G+5TMg25tcktlfOcXV4Y+5DkDm9rVDAy5rVz0z
	Uqm+Gxw+u0jCTmrgDzpV/N8j1996jL1PQ9L9A=
Received: by 10.216.138.89 with SMTP id z67mr1424878wei.10.1327081847469;
	Fri, 20 Jan 2012 09:50:47 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id di5sm11355183wib.3.2012.01.20.09.50.46
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 09:50:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 17:50:43 +0000
From: Keir Fraser <keir@xen.org>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB3F59F3.37E57%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v5 05/25] Introduce clear_user and clear_guest
Thread-Index: AczXnAeka4sdmXq7RkaoynlMoObUjQ==
In-Reply-To: <alpine.DEB.2.00.1201201545310.3196@kaball-desktop>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 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

On 20/01/2012 15:46, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
wrote:

>> Btw., what's the take on getting at least the common code cleanup/
>> adjustment patches committed? I had recommended taking them
>> already after you had posted v5 (but now I'm glad they didn't get
>> committed without this ia64 issue addressed).
> 
> My take is that they should go in :)
> Keir?

Yep.

Acked-by: Keir Fraser <keir@xen.org>

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:51:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:51:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIc3-00048h-3E; Fri, 20 Jan 2012 17:50:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RoIc1-00048c-Ob
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:50:53 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327081847!11909532!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 23444 invoked from network); 20 Jan 2012 17:50:47 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 17:50:47 -0000
Received: by werb14 with SMTP id b14so2969729wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 20 Jan 2012 09:50: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=40bdU7z1isfkuHrfckyTY6a3taECCCx5Dp6B1QmBtuo=;
	b=qi0Q/CTHDjAPEcC+65DezjSZdL3U5OaCa+jDc6JH/FiNPQTV2+RLDMYfvGkwDemZO+
	srz5X9I2/UQ3SfJBGhmdbwRkQv8EN6G+5TMg25tcktlfOcXV4Y+5DkDm9rVDAy5rVz0z
	Uqm+Gxw+u0jCTmrgDzpV/N8j1996jL1PQ9L9A=
Received: by 10.216.138.89 with SMTP id z67mr1424878wei.10.1327081847469;
	Fri, 20 Jan 2012 09:50:47 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id di5sm11355183wib.3.2012.01.20.09.50.46
	(version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 09:50:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Fri, 20 Jan 2012 17:50:43 +0000
From: Keir Fraser <keir@xen.org>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB3F59F3.37E57%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH v5 05/25] Introduce clear_user and clear_guest
Thread-Index: AczXnAeka4sdmXq7RkaoynlMoObUjQ==
In-Reply-To: <alpine.DEB.2.00.1201201545310.3196@kaball-desktop>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v5 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

On 20/01/2012 15:46, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
wrote:

>> Btw., what's the take on getting at least the common code cleanup/
>> adjustment patches committed? I had recommended taking them
>> already after you had posted v5 (but now I'm glad they didn't get
>> committed without this ia64 issue addressed).
> 
> My take is that they should go in :)
> Keir?

Yep.

Acked-by: Keir Fraser <keir@xen.org>

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:59:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:59:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIk9-0004JQ-2c; Fri, 20 Jan 2012 17:59:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RoIk7-0004JI-CI
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:59:15 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327082349!11750082!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMwOTU4Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4603 invoked from network); 20 Jan 2012 17:59:09 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 17:59:09 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q0KHx44n019068;
	Fri, 20 Jan 2012 18:59:04 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0KHx2go022945;
	Fri, 20 Jan 2012 18:59:03 +0100
Message-ID: <4F19AB66.8060901@siemens.com>
Date: Fri, 20 Jan 2012 18:59:02 +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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-20 18:20, Stefano Stabellini wrote:
> Hi all,
> this is the fourth version of the Xen save/restore patch series.
> We have been discussing this issue for quite a while on #qemu and
> qemu-devel:
> 
> 
> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> 
> 
> A few different approaches were proposed to achieve the goal
> of a working save/restore with upstream Qemu on Xen, however after
> prototyping some of them I came up with yet another solution, that I
> think leads to the best results with the less amount of code
> duplications and ugliness.
> Far from saying that this patch series is an example of elegance and
> simplicity, but it is closer to acceptable anything else I have seen so
> far.
> 
> What's new is that Qemu is going to keep track of its own physmap on
> xenstore, so that Xen can be fully aware of the changes Qemu makes to
> the guest's memory map at any time.
> This is all handled by Xen or Xen support in Qemu internally and can be
> used to solve our save/restore framebuffer problem.
> 
>>From the Qemu common code POV, we still need to avoid saving the guest's
> ram when running on Xen, and we need to avoid resetting the videoram on
> restore (that is a benefit to the generic Qemu case too, because it
> saves few cpu cycles).

For my understanding: Refraining from the memset is required as the
already restored vram would then be overwritten? Or what is the ordering
of init, RAM restore, and initial device reset now?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 17:59:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 17:59:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoIk9-0004JQ-2c; Fri, 20 Jan 2012 17:59:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RoIk7-0004JI-CI
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 17:59:15 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327082349!11750082!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMwOTU4Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4603 invoked from network); 20 Jan 2012 17:59:09 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 17:59:09 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q0KHx44n019068;
	Fri, 20 Jan 2012 18:59:04 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0KHx2go022945;
	Fri, 20 Jan 2012 18:59:03 +0100
Message-ID: <4F19AB66.8060901@siemens.com>
Date: Fri, 20 Jan 2012 18:59:02 +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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-20 18:20, Stefano Stabellini wrote:
> Hi all,
> this is the fourth version of the Xen save/restore patch series.
> We have been discussing this issue for quite a while on #qemu and
> qemu-devel:
> 
> 
> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> 
> 
> A few different approaches were proposed to achieve the goal
> of a working save/restore with upstream Qemu on Xen, however after
> prototyping some of them I came up with yet another solution, that I
> think leads to the best results with the less amount of code
> duplications and ugliness.
> Far from saying that this patch series is an example of elegance and
> simplicity, but it is closer to acceptable anything else I have seen so
> far.
> 
> What's new is that Qemu is going to keep track of its own physmap on
> xenstore, so that Xen can be fully aware of the changes Qemu makes to
> the guest's memory map at any time.
> This is all handled by Xen or Xen support in Qemu internally and can be
> used to solve our save/restore framebuffer problem.
> 
>>From the Qemu common code POV, we still need to avoid saving the guest's
> ram when running on Xen, and we need to avoid resetting the videoram on
> restore (that is a benefit to the generic Qemu case too, because it
> saves few cpu cycles).

For my understanding: Refraining from the memset is required as the
already restored vram would then be overwritten? Or what is the ordering
of init, RAM restore, and initial device reset now?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 18:48:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 18:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoJVD-0005AH-Da; Fri, 20 Jan 2012 18:47:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1RoJVB-00058v-T3
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 18:47:54 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327085253!10039994!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13024 invoked from network); 20 Jan 2012 18:47:47 -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;
	20 Jan 2012 18:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; 
	d="diff'?scan'208";a="21119179"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:47:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 13:47:46 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KIlj1M016494;	Fri, 20 Jan 2012 10:47:45 -0800
Message-ID: <4F19B623.1060105@citrix.com>
Date: Fri, 20 Jan 2012 18:44:51 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------080408060606060303020307"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] xenoprof: Adjust indentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080408060606060303020307
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

xenoprof: Adjust indentation

Bring indentation into Xen hypervisor standard coding style.

No functional changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r 9cdcedc133e5 -r f6953e89913f xen/arch/x86/oprofile/backtrace.c
--- a/xen/arch/x86/oprofile/backtrace.c    Wed Jan 11 10:34:45 2012 +0100
+++ b/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:23:02 2012 +0000
@@ -16,48 +16,48 @@
  #include<asm/guest_access.h>

  struct frame_head {
-    struct frame_head * ebp;
-    unsigned long ret;
+    struct frame_head * ebp;
+    unsigned long ret;
  } __attribute__((packed));

  static struct frame_head *
  dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu,
                struct frame_head * head, int mode)
  {
-    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
-        return 0;
-
-    /* frame pointers should strictly progress back up the stack
-     * (towards higher addresses) */
-    if (head >= head->ebp)
-        return NULL;
-
-    return head->ebp;
+    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
+        return 0;
+
+    /* frame pointers should strictly progress back up the stack
+     * (towards higher addresses) */
+    if (head >= head->ebp)
+        return NULL;
+
+    return head->ebp;
  }

  static struct frame_head *
  dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
               struct frame_head * head, int mode)
  {
-    struct frame_head bufhead[2];
-    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
+    struct frame_head bufhead[2];
+    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);

-    /* Also check accessibility of one struct frame_head beyond */
-    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
-        return 0;
-    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
-        sizeof(bufhead)))
-        return 0;
-
-    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
-        return 0;
-
-    /* frame pointers should strictly progress back up the stack
-     * (towards higher addresses) */
-    if (head >= bufhead[0].ebp)
-        return NULL;
-
-    return bufhead[0].ebp;
+    /* Also check accessibility of one struct frame_head beyond */
+    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
+        return 0;
+    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
+                                 sizeof(bufhead)))
+        return 0;
+
+    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
+        return 0;
+
+    /* frame pointers should strictly progress back up the stack
+     * (towards higher addresses) */
+    if (head >= bufhead[0].ebp)
+        return NULL;
+
+    return bufhead[0].ebp;
  }

  /*
@@ -94,22 +94,22 @@ dump_guest_backtrace(struct domain *d, s
  static int valid_hypervisor_stack(struct frame_head * head,
                    struct cpu_user_regs * regs)
  {
-    unsigned long headaddr = (unsigned long)head;
+    unsigned long headaddr = (unsigned long)head;
  #ifdef CONFIG_X86_64
-    unsigned long stack = (unsigned long)regs->rsp;
+    unsigned long stack = (unsigned long)regs->rsp;
  #else
-    unsigned long stack = (unsigned long)regs;
+    unsigned long stack = (unsigned long)regs;
  #endif
-    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
+    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;

-    return headaddr > stack && headaddr < stack_base;
+    return headaddr > stack && headaddr < stack_base;
  }
  #else
  /* without fp, it's just junk */
  static int valid_hypervisor_stack(struct frame_head * head,
                    struct cpu_user_regs * regs)
  {
-    return 0;
+    return 0;
  }
  #endif

@@ -117,16 +117,16 @@ void xenoprof_backtrace(struct domain *d
              struct cpu_user_regs * const regs,
              unsigned long depth, int mode)
  {
-    struct frame_head *head;
+    struct frame_head *head;

-    head = (struct frame_head *)regs->ebp;
+    head = (struct frame_head *)regs->ebp;

-    if (mode > 1) {
-        while (depth-- && valid_hypervisor_stack(head, regs))
-            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
-        return;
-    }
+    if (mode > 1) {
+        while (depth-- && valid_hypervisor_stack(head, regs))
+            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
+        return;
+    }

-    while (depth-- && head)
-        head = dump_guest_backtrace(d, vcpu, head, mode);
+    while (depth-- && head)
+        head = dump_guest_backtrace(d, vcpu, head, mode);
  }


--------------080408060606060303020307
Content-Type: text/x-patch; name="xenoprof-indent-backtrace.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xenoprof-indent-backtrace.diff"

xenoprof: Adjust indentation

Bring indentation into Xen hypervisor standard coding style.

No functional changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r 9cdcedc133e5 -r f6953e89913f xen/arch/x86/oprofile/backtrace.c
--- a/xen/arch/x86/oprofile/backtrace.c	Wed Jan 11 10:34:45 2012 +0100
+++ b/xen/arch/x86/oprofile/backtrace.c	Wed Jan 18 17:23:02 2012 +0000
@@ -16,48 +16,48 @@
 #include<asm/guest_access.h>
 
 struct frame_head {
-	struct frame_head * ebp;
-	unsigned long ret;
+    struct frame_head * ebp;
+    unsigned long ret;
 } __attribute__((packed));
 
 static struct frame_head *
 dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu, 
 			  struct frame_head * head, int mode)
 {
-	if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
-		return 0;
-
-	/* frame pointers should strictly progress back up the stack
-	 * (towards higher addresses) */
-	if (head >= head->ebp)
-		return NULL;
-
-	return head->ebp;
+    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
+        return 0;
+    
+    /* frame pointers should strictly progress back up the stack
+     * (towards higher addresses) */
+    if (head >= head->ebp)
+        return NULL;
+    
+    return head->ebp;
 }
 
 static struct frame_head *
 dump_guest_backtrace(struct domain *d, struct vcpu *vcpu, 
 		     struct frame_head * head, int mode)
 {
-	struct frame_head bufhead[2];
-	XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
+    struct frame_head bufhead[2];
+    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
 	
-	/* Also check accessibility of one struct frame_head beyond */
-	if (!guest_handle_okay(guest_head, sizeof(bufhead)))
-		return 0;
-	if (__copy_from_guest_offset((char *)bufhead, guest_head, 0, 
-	    sizeof(bufhead)))
-		return 0;
-
-	if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
-	    return 0;
-
-	/* frame pointers should strictly progress back up the stack
-	 * (towards higher addresses) */
-	if (head >= bufhead[0].ebp)
-		return NULL;
-
-	return bufhead[0].ebp;
+    /* Also check accessibility of one struct frame_head beyond */
+    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
+        return 0;
+    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0, 
+                                 sizeof(bufhead)))
+        return 0;
+    
+    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
+        return 0;
+    
+    /* frame pointers should strictly progress back up the stack
+     * (towards higher addresses) */
+    if (head >= bufhead[0].ebp)
+        return NULL;
+    
+    return bufhead[0].ebp;
 }
 
 /*
@@ -94,22 +94,22 @@ dump_guest_backtrace(struct domain *d, s
 static int valid_hypervisor_stack(struct frame_head * head, 
 				  struct cpu_user_regs * regs)
 {
-	unsigned long headaddr = (unsigned long)head;
+    unsigned long headaddr = (unsigned long)head;
 #ifdef CONFIG_X86_64
-	unsigned long stack = (unsigned long)regs->rsp;
+    unsigned long stack = (unsigned long)regs->rsp;
 #else
-	unsigned long stack = (unsigned long)regs;
+    unsigned long stack = (unsigned long)regs;
 #endif
-	unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
+    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
 
-	return headaddr > stack && headaddr < stack_base;
+    return headaddr > stack && headaddr < stack_base;
 }
 #else
 /* without fp, it's just junk */
 static int valid_hypervisor_stack(struct frame_head * head, 
 				  struct cpu_user_regs * regs)
 {
-	return 0;
+    return 0;
 }
 #endif
 
@@ -117,16 +117,16 @@ void xenoprof_backtrace(struct domain *d
 			struct cpu_user_regs * const regs,
 			unsigned long depth, int mode)
 {
-	struct frame_head *head;
+    struct frame_head *head;
 
-	head = (struct frame_head *)regs->ebp;
+    head = (struct frame_head *)regs->ebp;
 
-	if (mode > 1) {
-		while (depth-- && valid_hypervisor_stack(head, regs))
-		    head = dump_hypervisor_backtrace(d, vcpu, head, mode);
-		return;
-	}
+    if (mode > 1) {
+        while (depth-- && valid_hypervisor_stack(head, regs))
+            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
+        return;
+    }
 
-	while (depth-- && head)
-	    head = dump_guest_backtrace(d, vcpu, head, mode);
+    while (depth-- && head)
+        head = dump_guest_backtrace(d, vcpu, head, mode);
 }

--------------080408060606060303020307
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------080408060606060303020307--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 18:48:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 18:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoJVD-0005AH-Da; Fri, 20 Jan 2012 18:47:55 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1RoJVB-00058v-T3
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 18:47:54 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327085253!10039994!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13024 invoked from network); 20 Jan 2012 18:47:47 -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;
	20 Jan 2012 18:47:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; 
	d="diff'?scan'208";a="21119179"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:47:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 13:47:46 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KIlj1M016494;	Fri, 20 Jan 2012 10:47:45 -0800
Message-ID: <4F19B623.1060105@citrix.com>
Date: Fri, 20 Jan 2012 18:44:51 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------080408060606060303020307"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/3] xenoprof: Adjust indentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------080408060606060303020307
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

xenoprof: Adjust indentation

Bring indentation into Xen hypervisor standard coding style.

No functional changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r 9cdcedc133e5 -r f6953e89913f xen/arch/x86/oprofile/backtrace.c
--- a/xen/arch/x86/oprofile/backtrace.c    Wed Jan 11 10:34:45 2012 +0100
+++ b/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:23:02 2012 +0000
@@ -16,48 +16,48 @@
  #include<asm/guest_access.h>

  struct frame_head {
-    struct frame_head * ebp;
-    unsigned long ret;
+    struct frame_head * ebp;
+    unsigned long ret;
  } __attribute__((packed));

  static struct frame_head *
  dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu,
                struct frame_head * head, int mode)
  {
-    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
-        return 0;
-
-    /* frame pointers should strictly progress back up the stack
-     * (towards higher addresses) */
-    if (head >= head->ebp)
-        return NULL;
-
-    return head->ebp;
+    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
+        return 0;
+
+    /* frame pointers should strictly progress back up the stack
+     * (towards higher addresses) */
+    if (head >= head->ebp)
+        return NULL;
+
+    return head->ebp;
  }

  static struct frame_head *
  dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
               struct frame_head * head, int mode)
  {
-    struct frame_head bufhead[2];
-    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
+    struct frame_head bufhead[2];
+    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);

-    /* Also check accessibility of one struct frame_head beyond */
-    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
-        return 0;
-    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
-        sizeof(bufhead)))
-        return 0;
-
-    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
-        return 0;
-
-    /* frame pointers should strictly progress back up the stack
-     * (towards higher addresses) */
-    if (head >= bufhead[0].ebp)
-        return NULL;
-
-    return bufhead[0].ebp;
+    /* Also check accessibility of one struct frame_head beyond */
+    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
+        return 0;
+    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
+                                 sizeof(bufhead)))
+        return 0;
+
+    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
+        return 0;
+
+    /* frame pointers should strictly progress back up the stack
+     * (towards higher addresses) */
+    if (head >= bufhead[0].ebp)
+        return NULL;
+
+    return bufhead[0].ebp;
  }

  /*
@@ -94,22 +94,22 @@ dump_guest_backtrace(struct domain *d, s
  static int valid_hypervisor_stack(struct frame_head * head,
                    struct cpu_user_regs * regs)
  {
-    unsigned long headaddr = (unsigned long)head;
+    unsigned long headaddr = (unsigned long)head;
  #ifdef CONFIG_X86_64
-    unsigned long stack = (unsigned long)regs->rsp;
+    unsigned long stack = (unsigned long)regs->rsp;
  #else
-    unsigned long stack = (unsigned long)regs;
+    unsigned long stack = (unsigned long)regs;
  #endif
-    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
+    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;

-    return headaddr > stack && headaddr < stack_base;
+    return headaddr > stack && headaddr < stack_base;
  }
  #else
  /* without fp, it's just junk */
  static int valid_hypervisor_stack(struct frame_head * head,
                    struct cpu_user_regs * regs)
  {
-    return 0;
+    return 0;
  }
  #endif

@@ -117,16 +117,16 @@ void xenoprof_backtrace(struct domain *d
              struct cpu_user_regs * const regs,
              unsigned long depth, int mode)
  {
-    struct frame_head *head;
+    struct frame_head *head;

-    head = (struct frame_head *)regs->ebp;
+    head = (struct frame_head *)regs->ebp;

-    if (mode > 1) {
-        while (depth-- && valid_hypervisor_stack(head, regs))
-            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
-        return;
-    }
+    if (mode > 1) {
+        while (depth-- && valid_hypervisor_stack(head, regs))
+            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
+        return;
+    }

-    while (depth-- && head)
-        head = dump_guest_backtrace(d, vcpu, head, mode);
+    while (depth-- && head)
+        head = dump_guest_backtrace(d, vcpu, head, mode);
  }


--------------080408060606060303020307
Content-Type: text/x-patch; name="xenoprof-indent-backtrace.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xenoprof-indent-backtrace.diff"

xenoprof: Adjust indentation

Bring indentation into Xen hypervisor standard coding style.

No functional changes.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r 9cdcedc133e5 -r f6953e89913f xen/arch/x86/oprofile/backtrace.c
--- a/xen/arch/x86/oprofile/backtrace.c	Wed Jan 11 10:34:45 2012 +0100
+++ b/xen/arch/x86/oprofile/backtrace.c	Wed Jan 18 17:23:02 2012 +0000
@@ -16,48 +16,48 @@
 #include<asm/guest_access.h>
 
 struct frame_head {
-	struct frame_head * ebp;
-	unsigned long ret;
+    struct frame_head * ebp;
+    unsigned long ret;
 } __attribute__((packed));
 
 static struct frame_head *
 dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu, 
 			  struct frame_head * head, int mode)
 {
-	if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
-		return 0;
-
-	/* frame pointers should strictly progress back up the stack
-	 * (towards higher addresses) */
-	if (head >= head->ebp)
-		return NULL;
-
-	return head->ebp;
+    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
+        return 0;
+    
+    /* frame pointers should strictly progress back up the stack
+     * (towards higher addresses) */
+    if (head >= head->ebp)
+        return NULL;
+    
+    return head->ebp;
 }
 
 static struct frame_head *
 dump_guest_backtrace(struct domain *d, struct vcpu *vcpu, 
 		     struct frame_head * head, int mode)
 {
-	struct frame_head bufhead[2];
-	XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
+    struct frame_head bufhead[2];
+    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
 	
-	/* Also check accessibility of one struct frame_head beyond */
-	if (!guest_handle_okay(guest_head, sizeof(bufhead)))
-		return 0;
-	if (__copy_from_guest_offset((char *)bufhead, guest_head, 0, 
-	    sizeof(bufhead)))
-		return 0;
-
-	if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
-	    return 0;
-
-	/* frame pointers should strictly progress back up the stack
-	 * (towards higher addresses) */
-	if (head >= bufhead[0].ebp)
-		return NULL;
-
-	return bufhead[0].ebp;
+    /* Also check accessibility of one struct frame_head beyond */
+    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
+        return 0;
+    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0, 
+                                 sizeof(bufhead)))
+        return 0;
+    
+    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
+        return 0;
+    
+    /* frame pointers should strictly progress back up the stack
+     * (towards higher addresses) */
+    if (head >= bufhead[0].ebp)
+        return NULL;
+    
+    return bufhead[0].ebp;
 }
 
 /*
@@ -94,22 +94,22 @@ dump_guest_backtrace(struct domain *d, s
 static int valid_hypervisor_stack(struct frame_head * head, 
 				  struct cpu_user_regs * regs)
 {
-	unsigned long headaddr = (unsigned long)head;
+    unsigned long headaddr = (unsigned long)head;
 #ifdef CONFIG_X86_64
-	unsigned long stack = (unsigned long)regs->rsp;
+    unsigned long stack = (unsigned long)regs->rsp;
 #else
-	unsigned long stack = (unsigned long)regs;
+    unsigned long stack = (unsigned long)regs;
 #endif
-	unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
+    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
 
-	return headaddr > stack && headaddr < stack_base;
+    return headaddr > stack && headaddr < stack_base;
 }
 #else
 /* without fp, it's just junk */
 static int valid_hypervisor_stack(struct frame_head * head, 
 				  struct cpu_user_regs * regs)
 {
-	return 0;
+    return 0;
 }
 #endif
 
@@ -117,16 +117,16 @@ void xenoprof_backtrace(struct domain *d
 			struct cpu_user_regs * const regs,
 			unsigned long depth, int mode)
 {
-	struct frame_head *head;
+    struct frame_head *head;
 
-	head = (struct frame_head *)regs->ebp;
+    head = (struct frame_head *)regs->ebp;
 
-	if (mode > 1) {
-		while (depth-- && valid_hypervisor_stack(head, regs))
-		    head = dump_hypervisor_backtrace(d, vcpu, head, mode);
-		return;
-	}
+    if (mode > 1) {
+        while (depth-- && valid_hypervisor_stack(head, regs))
+            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
+        return;
+    }
 
-	while (depth-- && head)
-	    head = dump_guest_backtrace(d, vcpu, head, mode);
+    while (depth-- && head)
+        head = dump_guest_backtrace(d, vcpu, head, mode);
 }

--------------080408060606060303020307
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------080408060606060303020307--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 18:48:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 18:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoJVB-0005A0-12; Fri, 20 Jan 2012 18:47:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1RoJV9-00058k-5x
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 18:47:51 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327085253!10039994!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12990 invoked from network); 20 Jan 2012 18:47:45 -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;
	20 Jan 2012 18:47:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; d="scan'208";a="21119176"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:47:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 13:47:33 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KIlVHG016491;	Fri, 20 Jan 2012 10:47:32 -0800
Message-ID: <4F19B616.8050603@citrix.com>
Date: Fri, 20 Jan 2012 18:44:38 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] xenoprof: improve handling of 32-bit guests
 on 64-bit 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-Transfer-Encoding: 7bit
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,
this patch series for xen fixes some xenoprofile type glitches between 
64-bit xen and 32-bit guests, enablingthe opcontrol callgraph option to 
walk the call stack in both 32-bit and 64-bit guests when they are 
running on 64-bit xen.

The escape-code patch (3/3) should be used with a corresponding patch in 
the guest kernel definition of XENOPROF_ESCAPE_CODE so that both ends 
agree on the same escape constant value.


A few comments from my tests with oprofile 0.9.6 in userspace:
- to obtain callgraphs of the xen code, you need to enable the 
CONFIG_FRAME_POINTER flag during compilation of the xen binary, eg. 
using "make" with "frame_pointer=y".
- if the oprofiled daemon is running in a 32-bit guest, it needs to 
receive the xen-range in 32-bits, eg. --xen-image=/boot/xen-syms-4.1.1 
--xen-range=80100000,801fe5ee

cheers,
Marcus

(1/3) xenoprof: Adjust indentation
(2/3) xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor
(3/3) xenoprof: Make the escape code consistent across 32 and 64-bit xen







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 18:48:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 18:48:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoJVB-0005A0-12; Fri, 20 Jan 2012 18:47:53 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1RoJV9-00058k-5x
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 18:47:51 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327085253!10039994!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12990 invoked from network); 20 Jan 2012 18:47:45 -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;
	20 Jan 2012 18:47:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; d="scan'208";a="21119176"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:47:33 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 13:47:33 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KIlVHG016491;	Fri, 20 Jan 2012 10:47:32 -0800
Message-ID: <4F19B616.8050603@citrix.com>
Date: Fri, 20 Jan 2012 18:44:38 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/3] xenoprof: improve handling of 32-bit guests
 on 64-bit 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-Transfer-Encoding: 7bit
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,
this patch series for xen fixes some xenoprofile type glitches between 
64-bit xen and 32-bit guests, enablingthe opcontrol callgraph option to 
walk the call stack in both 32-bit and 64-bit guests when they are 
running on 64-bit xen.

The escape-code patch (3/3) should be used with a corresponding patch in 
the guest kernel definition of XENOPROF_ESCAPE_CODE so that both ends 
agree on the same escape constant value.


A few comments from my tests with oprofile 0.9.6 in userspace:
- to obtain callgraphs of the xen code, you need to enable the 
CONFIG_FRAME_POINTER flag during compilation of the xen binary, eg. 
using "make" with "frame_pointer=y".
- if the oprofiled daemon is running in a 32-bit guest, it needs to 
receive the xen-range in 32-bits, eg. --xen-image=/boot/xen-syms-4.1.1 
--xen-range=80100000,801fe5ee

cheers,
Marcus

(1/3) xenoprof: Adjust indentation
(2/3) xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor
(3/3) xenoprof: Make the escape code consistent across 32 and 64-bit xen







_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 18:48:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 18:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoJVM-0005Bg-R3; Fri, 20 Jan 2012 18:48:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1RoJVK-0005Ac-SY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 18:48:03 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327085275!2684587!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16883 invoked from network); 20 Jan 2012 18:47:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 18:47:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; 
	d="diff'?scan'208";a="21119183"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:47:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 13:47:54 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KIlre9016497;	Fri, 20 Jan 2012 10:47:53 -0800
Message-ID: <4F19B62C.9020402@citrix.com>
Date: Fri, 20 Jan 2012 18:45:00 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------040609090309060107010004"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] xenoprof: Handle 32-bit guest stacks
 properly in a 64-bit 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------040609090309060107010004
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor

The dump_guest_backtrace() function attempted to walk the stack
based on the assumption that the guest and hypervisor pointer sizes
were the same; thus any 32-bit guest running under 64-bit hypervisor
would have unreliable results.

In 64-bit mode, read the 32-bit stack frame properly.

Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r f6953e89913f -r 21e7744a52b1 xen/arch/x86/oprofile/backtrace.c
--- a/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:23:02 2012 +0000
+++ b/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:35:06 2012 +0000
@@ -20,6 +20,13 @@ struct frame_head {
      unsigned long ret;
  } __attribute__((packed));

+#ifdef CONFIG_X86_64
+struct frame_head_32bit {
+    uint32_t ebp;
+    unsigned long ret;
+} __attribute__((packed));
+#endif
+
  static struct frame_head *
  dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu,
                struct frame_head * head, int mode)
@@ -35,19 +42,46 @@ dump_hypervisor_backtrace(struct domain
      return head->ebp;
  }

+#ifdef CONFIG_X86_64
+static inline int is_32bit_vcpu(struct vcpu *vcpu)
+{
+    if (is_hvm_vcpu(vcpu))
+        return !hvm_long_mode_enabled(vcpu);
+    else
+        return is_pv_32bit_vcpu(vcpu);
+}
+#endif
+
  static struct frame_head *
  dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
               struct frame_head * head, int mode)
  {
      struct frame_head bufhead[2];
      XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
-
-    /* Also check accessibility of one struct frame_head beyond */
-    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
-        return 0;
-    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
-                                 sizeof(bufhead)))
-        return 0;
+
+#ifdef CONFIG_X86_64
+    if ( is_32bit_vcpu(vcpu) )
+    {
+        struct frame_head_32bit bufhead32[2];
+        /* Also check accessibility of one struct frame_head beyond */
+        if (!guest_handle_okay(guest_head, sizeof(bufhead32)))
+            return 0;
+        if (__copy_from_guest_offset((char *)bufhead32, guest_head, 0,
+                                     sizeof(bufhead32)))
+            return 0;
+        bufhead[0].ebp=(struct frame_head *)(unsigned 
long)bufhead32[0].ebp;
+        bufhead[0].ret=bufhead32[0].ret;
+    }
+    else
+#endif
+    {
+        /* Also check accessibility of one struct frame_head beyond */
+        if (!guest_handle_okay(guest_head, sizeof(bufhead)))
+            return 0;
+        if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
+                                     sizeof(bufhead)))
+            return 0;
+    }

      if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
          return 0;


--------------040609090309060107010004
Content-Type: text/x-patch; name="xenoprof-handle-32-bit-guest-stacks.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="xenoprof-handle-32-bit-guest-stacks.diff"

xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor

The dump_guest_backtrace() function attempted to walk the stack
based on the assumption that the guest and hypervisor pointer sizes
were the same; thus any 32-bit guest running under 64-bit hypervisor
would have unreliable results.

In 64-bit mode, read the 32-bit stack frame properly.

Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r f6953e89913f -r 21e7744a52b1 xen/arch/x86/oprofile/backtrace.c
--- a/xen/arch/x86/oprofile/backtrace.c	Wed Jan 18 17:23:02 2012 +0000
+++ b/xen/arch/x86/oprofile/backtrace.c	Wed Jan 18 17:35:06 2012 +0000
@@ -20,6 +20,13 @@ struct frame_head {
     unsigned long ret;
 } __attribute__((packed));
 
+#ifdef CONFIG_X86_64
+struct frame_head_32bit {
+    uint32_t ebp;
+    unsigned long ret;
+} __attribute__((packed));
+#endif
+
 static struct frame_head *
 dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu, 
 			  struct frame_head * head, int mode)
@@ -35,19 +42,46 @@ dump_hypervisor_backtrace(struct domain 
     return head->ebp;
 }
 
+#ifdef CONFIG_X86_64
+static inline int is_32bit_vcpu(struct vcpu *vcpu)
+{
+    if (is_hvm_vcpu(vcpu))
+        return !hvm_long_mode_enabled(vcpu);
+    else
+        return is_pv_32bit_vcpu(vcpu);
+}
+#endif
+
 static struct frame_head *
 dump_guest_backtrace(struct domain *d, struct vcpu *vcpu, 
 		     struct frame_head * head, int mode)
 {
     struct frame_head bufhead[2];
     XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
-	
-    /* Also check accessibility of one struct frame_head beyond */
-    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
-        return 0;
-    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0, 
-                                 sizeof(bufhead)))
-        return 0;
+
+#ifdef CONFIG_X86_64
+    if ( is_32bit_vcpu(vcpu) )
+    {
+        struct frame_head_32bit bufhead32[2];
+        /* Also check accessibility of one struct frame_head beyond */
+        if (!guest_handle_okay(guest_head, sizeof(bufhead32)))
+            return 0;
+        if (__copy_from_guest_offset((char *)bufhead32, guest_head, 0, 
+                                     sizeof(bufhead32)))
+            return 0;
+        bufhead[0].ebp=(struct frame_head *)(unsigned long)bufhead32[0].ebp;
+        bufhead[0].ret=bufhead32[0].ret;
+    }
+    else
+#endif
+    {
+        /* Also check accessibility of one struct frame_head beyond */
+        if (!guest_handle_okay(guest_head, sizeof(bufhead)))
+            return 0;
+        if (__copy_from_guest_offset((char *)bufhead, guest_head, 0, 
+                                     sizeof(bufhead)))
+            return 0;
+    }
     
     if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
         return 0;

--------------040609090309060107010004
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040609090309060107010004--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 18:48:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 18:48:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoJVM-0005Bg-R3; Fri, 20 Jan 2012 18:48:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1RoJVK-0005Ac-SY
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 18:48:03 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327085275!2684587!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16883 invoked from network); 20 Jan 2012 18:47:56 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 18:47:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; 
	d="diff'?scan'208";a="21119183"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:47:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 13:47:54 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KIlre9016497;	Fri, 20 Jan 2012 10:47:53 -0800
Message-ID: <4F19B62C.9020402@citrix.com>
Date: Fri, 20 Jan 2012 18:45:00 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------040609090309060107010004"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/3] xenoprof: Handle 32-bit guest stacks
 properly in a 64-bit 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------040609090309060107010004
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor

The dump_guest_backtrace() function attempted to walk the stack
based on the assumption that the guest and hypervisor pointer sizes
were the same; thus any 32-bit guest running under 64-bit hypervisor
would have unreliable results.

In 64-bit mode, read the 32-bit stack frame properly.

Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r f6953e89913f -r 21e7744a52b1 xen/arch/x86/oprofile/backtrace.c
--- a/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:23:02 2012 +0000
+++ b/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:35:06 2012 +0000
@@ -20,6 +20,13 @@ struct frame_head {
      unsigned long ret;
  } __attribute__((packed));

+#ifdef CONFIG_X86_64
+struct frame_head_32bit {
+    uint32_t ebp;
+    unsigned long ret;
+} __attribute__((packed));
+#endif
+
  static struct frame_head *
  dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu,
                struct frame_head * head, int mode)
@@ -35,19 +42,46 @@ dump_hypervisor_backtrace(struct domain
      return head->ebp;
  }

+#ifdef CONFIG_X86_64
+static inline int is_32bit_vcpu(struct vcpu *vcpu)
+{
+    if (is_hvm_vcpu(vcpu))
+        return !hvm_long_mode_enabled(vcpu);
+    else
+        return is_pv_32bit_vcpu(vcpu);
+}
+#endif
+
  static struct frame_head *
  dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
               struct frame_head * head, int mode)
  {
      struct frame_head bufhead[2];
      XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
-
-    /* Also check accessibility of one struct frame_head beyond */
-    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
-        return 0;
-    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
-                                 sizeof(bufhead)))
-        return 0;
+
+#ifdef CONFIG_X86_64
+    if ( is_32bit_vcpu(vcpu) )
+    {
+        struct frame_head_32bit bufhead32[2];
+        /* Also check accessibility of one struct frame_head beyond */
+        if (!guest_handle_okay(guest_head, sizeof(bufhead32)))
+            return 0;
+        if (__copy_from_guest_offset((char *)bufhead32, guest_head, 0,
+                                     sizeof(bufhead32)))
+            return 0;
+        bufhead[0].ebp=(struct frame_head *)(unsigned 
long)bufhead32[0].ebp;
+        bufhead[0].ret=bufhead32[0].ret;
+    }
+    else
+#endif
+    {
+        /* Also check accessibility of one struct frame_head beyond */
+        if (!guest_handle_okay(guest_head, sizeof(bufhead)))
+            return 0;
+        if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
+                                     sizeof(bufhead)))
+            return 0;
+    }

      if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
          return 0;


--------------040609090309060107010004
Content-Type: text/x-patch; name="xenoprof-handle-32-bit-guest-stacks.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="xenoprof-handle-32-bit-guest-stacks.diff"

xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor

The dump_guest_backtrace() function attempted to walk the stack
based on the assumption that the guest and hypervisor pointer sizes
were the same; thus any 32-bit guest running under 64-bit hypervisor
would have unreliable results.

In 64-bit mode, read the 32-bit stack frame properly.

Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r f6953e89913f -r 21e7744a52b1 xen/arch/x86/oprofile/backtrace.c
--- a/xen/arch/x86/oprofile/backtrace.c	Wed Jan 18 17:23:02 2012 +0000
+++ b/xen/arch/x86/oprofile/backtrace.c	Wed Jan 18 17:35:06 2012 +0000
@@ -20,6 +20,13 @@ struct frame_head {
     unsigned long ret;
 } __attribute__((packed));
 
+#ifdef CONFIG_X86_64
+struct frame_head_32bit {
+    uint32_t ebp;
+    unsigned long ret;
+} __attribute__((packed));
+#endif
+
 static struct frame_head *
 dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu, 
 			  struct frame_head * head, int mode)
@@ -35,19 +42,46 @@ dump_hypervisor_backtrace(struct domain 
     return head->ebp;
 }
 
+#ifdef CONFIG_X86_64
+static inline int is_32bit_vcpu(struct vcpu *vcpu)
+{
+    if (is_hvm_vcpu(vcpu))
+        return !hvm_long_mode_enabled(vcpu);
+    else
+        return is_pv_32bit_vcpu(vcpu);
+}
+#endif
+
 static struct frame_head *
 dump_guest_backtrace(struct domain *d, struct vcpu *vcpu, 
 		     struct frame_head * head, int mode)
 {
     struct frame_head bufhead[2];
     XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
-	
-    /* Also check accessibility of one struct frame_head beyond */
-    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
-        return 0;
-    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0, 
-                                 sizeof(bufhead)))
-        return 0;
+
+#ifdef CONFIG_X86_64
+    if ( is_32bit_vcpu(vcpu) )
+    {
+        struct frame_head_32bit bufhead32[2];
+        /* Also check accessibility of one struct frame_head beyond */
+        if (!guest_handle_okay(guest_head, sizeof(bufhead32)))
+            return 0;
+        if (__copy_from_guest_offset((char *)bufhead32, guest_head, 0, 
+                                     sizeof(bufhead32)))
+            return 0;
+        bufhead[0].ebp=(struct frame_head *)(unsigned long)bufhead32[0].ebp;
+        bufhead[0].ret=bufhead32[0].ret;
+    }
+    else
+#endif
+    {
+        /* Also check accessibility of one struct frame_head beyond */
+        if (!guest_handle_okay(guest_head, sizeof(bufhead)))
+            return 0;
+        if (__copy_from_guest_offset((char *)bufhead, guest_head, 0, 
+                                     sizeof(bufhead)))
+            return 0;
+    }
     
     if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
         return 0;

--------------040609090309060107010004
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040609090309060107010004--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 18:48:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 18: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 1RoJVR-0005D2-EN; Fri, 20 Jan 2012 18:48:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1RoJVQ-0005BR-Fg
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 18:48:08 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327085275!2684587!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16993 invoked from network); 20 Jan 2012 18:48:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 18:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; 
	d="diff'?scan'208";a="21119185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:48:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 13:48:01 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KIm0kF016500;	Fri, 20 Jan 2012 10:48:00 -0800
Message-ID: <4F19B633.6090105@citrix.com>
Date: Fri, 20 Jan 2012 18:45:07 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------040303040105030707040505"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code consistent
 across 32 and 64-bit 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

--------------040303040105030707040505
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

xenoprof: Make the escape code consistent across 32 and 64-bit xen

At the moment, the xenoprof escape code is defined as "~0UL".
Unfortunately, this expands to 0xffffffff on 32-bit systems
and 0xffffffffffffffff on 64-bit systems; with the result that
while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
"compat mode") is broken.

This patch makes the definition consistent across architectures.
In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
but this was seen as an acceptable thing to do.

Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r 870db1ebc0df -r bcd2c4f0c502 xen/include/public/xenoprof.h
--- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
+++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
@@ -68,7 +68,7 @@ struct event_log {
  };

  /* PC value that indicates a special code */
-#define XENOPROF_ESCAPE_CODE ~0UL
+#define XENOPROF_ESCAPE_CODE (~0ULL)
  /* Transient events for the xenoprof->oprofile cpu buf */
  #define XENOPROF_TRACE_BEGIN 1



--------------040303040105030707040505
Content-Type: text/x-patch; name="xenoprof-64bit-escape-code.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xenoprof-64bit-escape-code.diff"

xenoprof: Make the escape code consistent across 32 and 64-bit xen

At the moment, the xenoprof escape code is defined as "~0UL".
Unfortunately, this expands to 0xffffffff on 32-bit systems
and 0xffffffffffffffff on 64-bit systems; with the result that
while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
"compat mode") is broken.

This patch makes the definition consistent across architectures.
In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
but this was seen as an acceptable thing to do.

Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r 870db1ebc0df -r bcd2c4f0c502 xen/include/public/xenoprof.h
--- a/xen/include/public/xenoprof.h	Wed Jan 18 17:39:19 2012 +0000
+++ b/xen/include/public/xenoprof.h	Wed Jan 18 17:46:28 2012 +0000
@@ -68,7 +68,7 @@ struct event_log {
 };
 
 /* PC value that indicates a special code */
-#define XENOPROF_ESCAPE_CODE ~0UL
+#define XENOPROF_ESCAPE_CODE (~0ULL)
 /* Transient events for the xenoprof->oprofile cpu buf */
 #define XENOPROF_TRACE_BEGIN 1
 

--------------040303040105030707040505
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040303040105030707040505--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 18:48:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 18: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 1RoJVR-0005D2-EN; Fri, 20 Jan 2012 18:48:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1RoJVQ-0005BR-Fg
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 18:48:08 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327085275!2684587!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY0MDY=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16993 invoked from network); 20 Jan 2012 18:48:02 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 18:48:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; 
	d="diff'?scan'208";a="21119185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 13:48:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 13:48:01 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0KIm0kF016500;	Fri, 20 Jan 2012 10:48:00 -0800
Message-ID: <4F19B633.6090105@citrix.com>
Date: Fri, 20 Jan 2012 18:45:07 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Content-Type: multipart/mixed; boundary="------------040303040105030707040505"
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code consistent
 across 32 and 64-bit 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

--------------040303040105030707040505
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

xenoprof: Make the escape code consistent across 32 and 64-bit xen

At the moment, the xenoprof escape code is defined as "~0UL".
Unfortunately, this expands to 0xffffffff on 32-bit systems
and 0xffffffffffffffff on 64-bit systems; with the result that
while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
"compat mode") is broken.

This patch makes the definition consistent across architectures.
In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
but this was seen as an acceptable thing to do.

Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r 870db1ebc0df -r bcd2c4f0c502 xen/include/public/xenoprof.h
--- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
+++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
@@ -68,7 +68,7 @@ struct event_log {
  };

  /* PC value that indicates a special code */
-#define XENOPROF_ESCAPE_CODE ~0UL
+#define XENOPROF_ESCAPE_CODE (~0ULL)
  /* Transient events for the xenoprof->oprofile cpu buf */
  #define XENOPROF_TRACE_BEGIN 1



--------------040303040105030707040505
Content-Type: text/x-patch; name="xenoprof-64bit-escape-code.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="xenoprof-64bit-escape-code.diff"

xenoprof: Make the escape code consistent across 32 and 64-bit xen

At the moment, the xenoprof escape code is defined as "~0UL".
Unfortunately, this expands to 0xffffffff on 32-bit systems
and 0xffffffffffffffff on 64-bit systems; with the result that
while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
"compat mode") is broken.

This patch makes the definition consistent across architectures.
In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
but this was seen as an acceptable thing to do.

Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>


diff -r 870db1ebc0df -r bcd2c4f0c502 xen/include/public/xenoprof.h
--- a/xen/include/public/xenoprof.h	Wed Jan 18 17:39:19 2012 +0000
+++ b/xen/include/public/xenoprof.h	Wed Jan 18 17:46:28 2012 +0000
@@ -68,7 +68,7 @@ struct event_log {
 };
 
 /* PC value that indicates a special code */
-#define XENOPROF_ESCAPE_CODE ~0UL
+#define XENOPROF_ESCAPE_CODE (~0ULL)
 /* Transient events for the xenoprof->oprofile cpu buf */
 #define XENOPROF_TRACE_BEGIN 1
 

--------------040303040105030707040505
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------040303040105030707040505--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 19:25:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 19: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 1RoK4t-0006gX-9I; Fri, 20 Jan 2012 19:24:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tknchris@gmail.com>)
	id 1RoK4s-0006gM-2I; Fri, 20 Jan 2012 19:24:46 +0000
X-Env-Sender: tknchris@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327087477!1948792!1
X-Originating-IP: [209.85.220.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 4168 invoked from network); 20 Jan 2012 19:24:38 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 19:24:38 -0000
Received: by vcbfo11 with SMTP id fo11so2350626vcb.30
	for <multiple recipients>; Fri, 20 Jan 2012 11:24:37 -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=sUUEPGABc7LWScbGYKiCtuQpIBwfgO8YLmMGtj7ywcY=;
	b=sSFXZRIjAOs6UdNgWvWwHrNPF5YSomGHjTDnBAEhfA5vFkvnKvQfoxmZ0dqUQuDNhM
	TdZ5AN0eRn9QNClei8CqUZgNxj4IkD5Wl+UX9oHvdsmYct9rAOIQPv8h2J8S6gPi2DI/
	IyvifSUdJnLjdrE33Wnw8h21+ZF4m7lptJwI0=
MIME-Version: 1.0
Received: by 10.52.93.77 with SMTP id cs13mr8183823vdb.71.1327087476891; Fri,
	20 Jan 2012 11:24:36 -0800 (PST)
Received: by 10.52.170.67 with HTTP; Fri, 20 Jan 2012 11:24:36 -0800 (PST)
In-Reply-To: <3B7B9131A63345CCB34B508E3E4F3507@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
Date: Fri, 20 Jan 2012 14:24:36 -0500
Message-ID: <CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
From: chris <tknchris@gmail.com>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0835712132847441970=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0835712132847441970==
Content-Type: multipart/alternative; boundary=bcaec501652fa5615104b6faa13f

--bcaec501652fa5615104b6faa13f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm really surprised this doesnt get more attention. For as long as I've
been on this list, this feature has been mentioned so many times I would
think that getting this working would be a huge feature that would make the
product even better. I have only seen the occasional success with
experimental patches etc, despite this being talked about for years.

On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander
<al@ohosting.org.ua>wrote:

> Please make a manual
> or let's together make
>
> =D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=
=B4=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=
=8F 2012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB=D0=B8:
>
> SR> Pasi,
>
> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
> SR> CPU.
>
> SR> Have you managed to pass your gpu through to the domU?
>
> SR> Regards
>
> SR> Sandi
> SR> On Jan 20, 2012 4:47 PM, "Pasi K=C3=A4rkk=C3=A4inen" <pasik@iki.fi> w=
rote:
>
> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> ??>>>    Hello,
> ??>>>    I have spent a lot of time trying to get gfx passthru working on
> ??>>> my
> ??>> system
> ??>>>    without success.
> ??>>>    I looked onto my hardware capabilities again to make sure that i=
t
> ??>>> does   support VT-d and I am not too sure that it does fully.   My
> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
> chipset
> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
> ??>>> supporting VT-x, no
> ??>> mention of
> ??>>>    VT-d at [1]ark.intel.com)
> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
> ??>>> AND
> ??>> CPU
> ??>>>    need to support VT-d.
> ??>>>    What confuses me is, why is the 55x0 chipset listed there if non=
e
> ??>>> of
> ??>> the
> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
> ??>>> option,
> ??>> only
> ??>>>    VT-x.
> ??>>>
>
>
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-use=
rs>

--bcaec501652fa5615104b6faa13f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I&#39;m really surprised this doesnt get more attention. For as long as I&#=
39;ve been on this list, this feature has been mentioned so many times I wo=
uld think that getting this working would be a huge feature that would make=
 the product even better. I have only seen the occasional success with expe=
rimental patches etc, despite this being talked about for years.<br>
<br><div class=3D"gmail_quote">On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov=
 Alexander <span dir=3D"ltr">&lt;<a href=3D"mailto:al@ohosting.org.ua">al@o=
hosting.org.ua</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please make a manual<br>
or let&#39;s together make<br>
<br>
=D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=B4=
=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2=
012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB=D0=B8:<br>
<br>
SR&gt; Pasi,<br>
<br>
SR&gt; I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e<br>
SR&gt; CPU.<br>
<br>
SR&gt; Have you managed to pass your gpu through to the domU?<br>
<br>
SR&gt; Regards<br>
<br>
SR&gt; Sandi<br>
SR&gt; On Jan 20, 2012 4:47 PM, &quot;Pasi K=C3=A4rkk=C3=A4inen&quot; &lt;<=
a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote=
:<br>
<br>
??&gt;&gt; On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Hello,<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I have spent a lot of time trying to get gfx pa=
ssthru working on<br>
??&gt;&gt;&gt; my<br>
??&gt;&gt; system<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0without success.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I looked onto my hardware capabilities again to=
 make sure that it<br>
??&gt;&gt;&gt; does =C2=A0 support VT-d and I am not too sure that it does =
fully. =C2=A0 My<br>
??&gt;&gt;&gt; hardware is as follows: =C2=A0 - Supermicro X8DTH-6F motherb=
oard (5520 chipset<br>
??&gt;&gt;&gt; which supports VT-d) =C2=A0 - single Xeon X5650 CPU (which i=
s listed as<br>
??&gt;&gt;&gt; supporting VT-x, no<br>
??&gt;&gt; mention of<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-d at [1]<a href=3D"http://ark.intel.com" tar=
get=3D"_blank">ark.intel.com</a>)<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Now, according to the [2]VTdHowTo, the motherbo=
ard BIOS, chipset<br>
??&gt;&gt;&gt; AND<br>
??&gt;&gt; CPU<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0need to support VT-d.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
??&gt;&gt;&gt; of<br>
??&gt;&gt; the<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature<br>
??&gt;&gt;&gt; option,<br>
??&gt;&gt; only<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-x.<br>
??&gt;&gt;&gt;<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xensource.com" target=3D"_blank">Xen-user=
s@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-users" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-users</a></blockquote></div><br>

--bcaec501652fa5615104b6faa13f--


--===============0835712132847441970==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0835712132847441970==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 19:25:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 19: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 1RoK4t-0006gX-9I; Fri, 20 Jan 2012 19:24:47 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tknchris@gmail.com>)
	id 1RoK4s-0006gM-2I; Fri, 20 Jan 2012 19:24:46 +0000
X-Env-Sender: tknchris@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327087477!1948792!1
X-Originating-IP: [209.85.220.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 4168 invoked from network); 20 Jan 2012 19:24:38 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 19:24:38 -0000
Received: by vcbfo11 with SMTP id fo11so2350626vcb.30
	for <multiple recipients>; Fri, 20 Jan 2012 11:24:37 -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=sUUEPGABc7LWScbGYKiCtuQpIBwfgO8YLmMGtj7ywcY=;
	b=sSFXZRIjAOs6UdNgWvWwHrNPF5YSomGHjTDnBAEhfA5vFkvnKvQfoxmZ0dqUQuDNhM
	TdZ5AN0eRn9QNClei8CqUZgNxj4IkD5Wl+UX9oHvdsmYct9rAOIQPv8h2J8S6gPi2DI/
	IyvifSUdJnLjdrE33Wnw8h21+ZF4m7lptJwI0=
MIME-Version: 1.0
Received: by 10.52.93.77 with SMTP id cs13mr8183823vdb.71.1327087476891; Fri,
	20 Jan 2012 11:24:36 -0800 (PST)
Received: by 10.52.170.67 with HTTP; Fri, 20 Jan 2012 11:24:36 -0800 (PST)
In-Reply-To: <3B7B9131A63345CCB34B508E3E4F3507@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
Date: Fri, 20 Jan 2012 14:24:36 -0500
Message-ID: <CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
From: chris <tknchris@gmail.com>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Cc: Sandi Romih <romihs.forums@gmail.com>, xen-devel@lists.xensource.com,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0835712132847441970=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0835712132847441970==
Content-Type: multipart/alternative; boundary=bcaec501652fa5615104b6faa13f

--bcaec501652fa5615104b6faa13f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm really surprised this doesnt get more attention. For as long as I've
been on this list, this feature has been mentioned so many times I would
think that getting this working would be a huge feature that would make the
product even better. I have only seen the occasional success with
experimental patches etc, despite this being talked about for years.

On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander
<al@ohosting.org.ua>wrote:

> Please make a manual
> or let's together make
>
> =D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=
=B4=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=
=8F 2012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB=D0=B8:
>
> SR> Pasi,
>
> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
> SR> CPU.
>
> SR> Have you managed to pass your gpu through to the domU?
>
> SR> Regards
>
> SR> Sandi
> SR> On Jan 20, 2012 4:47 PM, "Pasi K=C3=A4rkk=C3=A4inen" <pasik@iki.fi> w=
rote:
>
> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> ??>>>    Hello,
> ??>>>    I have spent a lot of time trying to get gfx passthru working on
> ??>>> my
> ??>> system
> ??>>>    without success.
> ??>>>    I looked onto my hardware capabilities again to make sure that i=
t
> ??>>> does   support VT-d and I am not too sure that it does fully.   My
> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
> chipset
> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
> ??>>> supporting VT-x, no
> ??>> mention of
> ??>>>    VT-d at [1]ark.intel.com)
> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
> ??>>> AND
> ??>> CPU
> ??>>>    need to support VT-d.
> ??>>>    What confuses me is, why is the 55x0 chipset listed there if non=
e
> ??>>> of
> ??>> the
> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
> ??>>> option,
> ??>> only
> ??>>>    VT-x.
> ??>>>
>
>
>
> ______________________________**_________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-use=
rs>

--bcaec501652fa5615104b6faa13f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I&#39;m really surprised this doesnt get more attention. For as long as I&#=
39;ve been on this list, this feature has been mentioned so many times I wo=
uld think that getting this working would be a huge feature that would make=
 the product even better. I have only seen the occasional success with expe=
rimental patches etc, despite this being talked about for years.<br>
<br><div class=3D"gmail_quote">On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov=
 Alexander <span dir=3D"ltr">&lt;<a href=3D"mailto:al@ohosting.org.ua">al@o=
hosting.org.ua</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please make a manual<br>
or let&#39;s together make<br>
<br>
=D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=B4=
=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2=
012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB=D0=B8:<br>
<br>
SR&gt; Pasi,<br>
<br>
SR&gt; I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e<br>
SR&gt; CPU.<br>
<br>
SR&gt; Have you managed to pass your gpu through to the domU?<br>
<br>
SR&gt; Regards<br>
<br>
SR&gt; Sandi<br>
SR&gt; On Jan 20, 2012 4:47 PM, &quot;Pasi K=C3=A4rkk=C3=A4inen&quot; &lt;<=
a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote=
:<br>
<br>
??&gt;&gt; On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Hello,<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I have spent a lot of time trying to get gfx pa=
ssthru working on<br>
??&gt;&gt;&gt; my<br>
??&gt;&gt; system<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0without success.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I looked onto my hardware capabilities again to=
 make sure that it<br>
??&gt;&gt;&gt; does =C2=A0 support VT-d and I am not too sure that it does =
fully. =C2=A0 My<br>
??&gt;&gt;&gt; hardware is as follows: =C2=A0 - Supermicro X8DTH-6F motherb=
oard (5520 chipset<br>
??&gt;&gt;&gt; which supports VT-d) =C2=A0 - single Xeon X5650 CPU (which i=
s listed as<br>
??&gt;&gt;&gt; supporting VT-x, no<br>
??&gt;&gt; mention of<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-d at [1]<a href=3D"http://ark.intel.com" tar=
get=3D"_blank">ark.intel.com</a>)<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Now, according to the [2]VTdHowTo, the motherbo=
ard BIOS, chipset<br>
??&gt;&gt;&gt; AND<br>
??&gt;&gt; CPU<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0need to support VT-d.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
??&gt;&gt;&gt; of<br>
??&gt;&gt; the<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature<br>
??&gt;&gt;&gt; option,<br>
??&gt;&gt; only<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-x.<br>
??&gt;&gt;&gt;<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xensource.com" target=3D"_blank">Xen-user=
s@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-users" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-users</a></blockquote></div><br>

--bcaec501652fa5615104b6faa13f--


--===============0835712132847441970==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0835712132847441970==--


From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:25:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoL1B-0000Y2-0f; Fri, 20 Jan 2012 20:25:01 +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 1RoL19-0000Xx-NQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:25:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327091077!63342190!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 3159 invoked from network); 20 Jan 2012 20:24:37 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-27.messagelabs.com with SMTP;
	20 Jan 2012 20:24:37 -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
	q0KKOtwW002493; Fri, 20 Jan 2012 20:24:55 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 q0KKOtHi020192; 
	Fri, 20 Jan 2012 15:24:55 -0500
Message-ID: <4F19CD96.9030008@tycho.nsa.gov>
Date: Fri, 20 Jan 2012 15:24:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326884714.14689.191.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326884714.14689.191.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 01/18/2012 06:05 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> @@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
>>      return rc;
>>  }
>>
>> +static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
>> +{
>> +    DECLARE_HYPERCALL;
>> +    gnttab_setup_table_t setup_table;
>> +    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
>> +    int rc;
>> +       unsigned long gmfn;
> 
> There's a bunch of weird alignment issues in this patch. Presumably some
> hard tabs have snuck in.
> 
>> +
>> +    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
>> +       if (gmfnp == NULL)
>> +               return -1;
> 
> Alignment.
> 
>> +
>> +    setup_table.dom = domid;
>> +    setup_table.nr_frames = 1;
>> +    set_xen_guest_handle(setup_table.frame_list, gmfnp);
>> +    setup_table.status = 0;
>> +
>> +    hypercall.op = __HYPERVISOR_grant_table_op;
>> +    hypercall.arg[0] = GNTTABOP_setup_table;
>> +    hypercall.arg[1] = (unsigned long) &setup_table;
>> +    hypercall.arg[2] = 1;
>> +
>> +    rc = do_xen_hypercall(xch, &hypercall);
>> +       gmfn = *gmfnp;
> 
> Alignment. I'm going to stop pointing these out, I guess grep will find
> them...
> 
> [...]
>> +int xc_dom_gnttab_init(struct xc_dom_image *dom)
>> +{
>> +    unsigned long console_gmfn;
>> +    unsigned long xenstore_gmfn;
>> +    int autotranslated;
>> +
>> +    autotranslated = xc_dom_feature_translated(dom);
>> +    console_gmfn = autotranslated ?
>> +           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
>> +    xenstore_gmfn = autotranslated ?
>> +           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
>> +
>> +    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
>> +                              console_gmfn, xenstore_gmfn,
>> +                              dom->console_domid, dom->xenstore_domid);
> 
> So on build we have can do the p2m lookup and hence use the PV version
> of gnttab_seed, whereas on restore we don't have a p2m and hence can't?
> 
> The internals of xc_domain_restore do have the p2m though, so in
> principal we could avoid the need for the hvm version and the
> reintroduction of the remove_from_physmap by making xc_domain_restore
> output the necessary mfns? I'm not sure it is worth it though.
> 

The reason for needing remove_from_physmap is to temporarily access the
grant table, which can be done differently in PV and is not related to
p2m translation.

> 
>> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
>> index 3fda6f8..8bee684 100644
>> --- a/tools/libxc/xc_domain_restore.c
>> +++ b/tools/libxc/xc_domain_restore.c
>> @@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
>>
>>  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,
>> +                      uint32_t store_domid, unsigned int console_evtchn,
>> +                      unsigned long *console_mfn, uint32_t console_domid,
>>                        unsigned int hvm, unsigned int pae, int superpages,
>>                        int no_incr_generationid,
>>                        unsigned long *vm_generationid_addr)
>> @@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
>>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
>>
>> +    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
>> +                            console_domid, store_domid);
>> +    if (rc != 0)
>> +    {
>> +        ERROR("error seeding grant table");
>> +        goto out;
>> +    }
>> +
>>      DPRINTF("Domain ready to be built.\n");
>>      rc = 0;
>>      goto out;
>> @@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>>          goto out;
>>      }
>>
>> +    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
>> +                                console_domid, store_domid);
> 
> Oh, we don't even need to return them from xc_domain_restore since we
> could just translate from gfn to mfn right here (since we have a p2m in
> hand) and call xc_dom_gnttab_seed. Or am I missing something?

For HVM, we still have to use guest frame numbers because that's what Xen
expects to find in the grant table.

Or are you talking about the fact xc_domain_restore returns the mfns? That
isn't added by this patch; they are just used to populate the grant table.
 
>> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
>> index 5e39595..04db22f 100644
>> --- a/tools/libxl/libxl_dom.c
>> +++ b/tools/libxl/libxl_dom.c
> [...]
>> @@ -305,6 +312,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
>>      xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
>>      xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
>>      xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
>> +
>> +    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
> 
> Didn't this already happen in xc_linux_build_internal which was called
> via xc_linux_build_mem?

No, xl doesn't call xc_linux_build_mem; that's only used by xm.

-- 
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 Jan 20 20:25:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoL1B-0000Y2-0f; Fri, 20 Jan 2012 20:25:01 +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 1RoL19-0000Xx-NQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:25:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327091077!63342190!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 3159 invoked from network); 20 Jan 2012 20:24:37 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-27.messagelabs.com with SMTP;
	20 Jan 2012 20:24:37 -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
	q0KKOtwW002493; Fri, 20 Jan 2012 20:24:55 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 q0KKOtHi020192; 
	Fri, 20 Jan 2012 15:24:55 -0500
Message-ID: <4F19CD96.9030008@tycho.nsa.gov>
Date: Fri, 20 Jan 2012 15:24:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-7-git-send-email-dgdegra@tycho.nsa.gov>
	<1326884714.14689.191.camel@zakaz.uk.xensource.com>
In-Reply-To: <1326884714.14689.191.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 06/18] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 01/18/2012 06:05 AM, Ian Campbell wrote:
> On Thu, 2012-01-12 at 23:35 +0000, Daniel De Graaf wrote:
>> @@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
>>      return rc;
>>  }
>>
>> +static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
>> +{
>> +    DECLARE_HYPERCALL;
>> +    gnttab_setup_table_t setup_table;
>> +    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
>> +    int rc;
>> +       unsigned long gmfn;
> 
> There's a bunch of weird alignment issues in this patch. Presumably some
> hard tabs have snuck in.
> 
>> +
>> +    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
>> +       if (gmfnp == NULL)
>> +               return -1;
> 
> Alignment.
> 
>> +
>> +    setup_table.dom = domid;
>> +    setup_table.nr_frames = 1;
>> +    set_xen_guest_handle(setup_table.frame_list, gmfnp);
>> +    setup_table.status = 0;
>> +
>> +    hypercall.op = __HYPERVISOR_grant_table_op;
>> +    hypercall.arg[0] = GNTTABOP_setup_table;
>> +    hypercall.arg[1] = (unsigned long) &setup_table;
>> +    hypercall.arg[2] = 1;
>> +
>> +    rc = do_xen_hypercall(xch, &hypercall);
>> +       gmfn = *gmfnp;
> 
> Alignment. I'm going to stop pointing these out, I guess grep will find
> them...
> 
> [...]
>> +int xc_dom_gnttab_init(struct xc_dom_image *dom)
>> +{
>> +    unsigned long console_gmfn;
>> +    unsigned long xenstore_gmfn;
>> +    int autotranslated;
>> +
>> +    autotranslated = xc_dom_feature_translated(dom);
>> +    console_gmfn = autotranslated ?
>> +           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
>> +    xenstore_gmfn = autotranslated ?
>> +           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
>> +
>> +    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
>> +                              console_gmfn, xenstore_gmfn,
>> +                              dom->console_domid, dom->xenstore_domid);
> 
> So on build we have can do the p2m lookup and hence use the PV version
> of gnttab_seed, whereas on restore we don't have a p2m and hence can't?
> 
> The internals of xc_domain_restore do have the p2m though, so in
> principal we could avoid the need for the hvm version and the
> reintroduction of the remove_from_physmap by making xc_domain_restore
> output the necessary mfns? I'm not sure it is worth it though.
> 

The reason for needing remove_from_physmap is to temporarily access the
grant table, which can be done differently in PV and is not related to
p2m translation.

> 
>> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
>> index 3fda6f8..8bee684 100644
>> --- a/tools/libxc/xc_domain_restore.c
>> +++ b/tools/libxc/xc_domain_restore.c
>> @@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
>>
>>  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,
>> +                      uint32_t store_domid, unsigned int console_evtchn,
>> +                      unsigned long *console_mfn, uint32_t console_domid,
>>                        unsigned int hvm, unsigned int pae, int superpages,
>>                        int no_incr_generationid,
>>                        unsigned long *vm_generationid_addr)
>> @@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>>          memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
>>      munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
>>
>> +    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
>> +                            console_domid, store_domid);
>> +    if (rc != 0)
>> +    {
>> +        ERROR("error seeding grant table");
>> +        goto out;
>> +    }
>> +
>>      DPRINTF("Domain ready to be built.\n");
>>      rc = 0;
>>      goto out;
>> @@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
>>          goto out;
>>      }
>>
>> +    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
>> +                                console_domid, store_domid);
> 
> Oh, we don't even need to return them from xc_domain_restore since we
> could just translate from gfn to mfn right here (since we have a p2m in
> hand) and call xc_dom_gnttab_seed. Or am I missing something?

For HVM, we still have to use guest frame numbers because that's what Xen
expects to find in the grant table.

Or are you talking about the fact xc_domain_restore returns the mfns? That
isn't added by this patch; they are just used to populate the grant table.
 
>> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
>> index 5e39595..04db22f 100644
>> --- a/tools/libxl/libxl_dom.c
>> +++ b/tools/libxl/libxl_dom.c
> [...]
>> @@ -305,6 +312,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
>>      xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
>>      xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
>>      xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
>> +
>> +    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
> 
> Didn't this already happen in xc_linux_build_internal which was called
> via xc_linux_build_mem?

No, xl doesn't call xc_linux_build_mem; that's only used by xm.

-- 
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 Jan 20 20:32:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoL89-0000mX-Tm; Fri, 20 Jan 2012 20:32:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RoL88-0000mG-MV; Fri, 20 Jan 2012 20:32:12 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327091526!11816651!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODkyMDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29378 invoked from network); 20 Jan 2012 20:32:06 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 20:32:06 -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 7214A2826;
	Fri, 20 Jan 2012 22:32:05 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 49D97200B0; Fri, 20 Jan 2012 22:32:05 +0200 (EET)
Date: Fri, 20 Jan 2012 22:32:05 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120120203205.GW12984@reaktio.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 20, 2012 at 05:49:20PM +0100, Sandi Romih wrote:
>    Pasi,
> =

>    I have that enabled in my BIOS, VT-d for the chipset and VT-x for the =
CPU.
>

Ok. And Xen enables IOMMU? Did you verify from Xen's dmesg ? =


http://wiki.xen.org/xenwiki/XenCommonProblems.html#head-2f76ed2d3c282003418=
d37fbbcda510cac266f89


 =

>    Have you managed to pass your gpu through to the domU?
> =


No, I haven't tried that yet. I've been planning to, but I haven't had time=
 for it yet.

There are many people who are using Xen VGA passthru with Intel, AMD/ATI an=
d Nvidia graphics cards.
Currently it needs a lot of understanding and some custom patching, but you=
 can make it work.

There are even businesses using Xen VGA passthru in production :)

-- Pasi

> =

>    Sandi
> =

>    On Jan 20, 2012 4:47 PM, "Pasi K=E4rkk=E4inen" <[1]pasik@iki.fi> wrote:
> =

>      On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>      >    Hello,
>      >    I have spent a lot of time trying to get gfx passthru working o=
n my
>      system
>      >    without success.
>      >    I looked onto my hardware capabilities again to make sure that =
it
>      does
>      >    support VT-d and I am not too sure that it does fully.
>      >    My hardware is as follows:
>      >    - Supermicro X8DTH-6F motherboard (5520 chipset which supports
>      VT-d)
>      >    - single Xeon X5650 CPU (which is listed as supporting VT-x, no
>      mention of
>      >    VT-d at [1][2]ark.intel.com)
>      >    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
>      AND CPU
>      >    need to support VT-d.
>      >    What confuses me is, why is the 55x0 chipset listed there if no=
ne
>      of the
>      >    CPU's supported, that I know of, dont have the VT-d feature opt=
ion,
>      only
>      >    VT-x.
>      >
> =

>      I've been using VT-d with Xen with Intel 5500 series chipset, and Xe=
on
>      5600 series CPU.
>      VT-d needs to be enabled in the BIOS.
> =

>      -- Pasi
> =

> References
> =

>    Visible links
>    1. mailto:pasik@iki.fi
>    2. http://ark.intel.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:32:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoL89-0000mX-Tm; Fri, 20 Jan 2012 20:32:13 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>)
	id 1RoL88-0000mG-MV; Fri, 20 Jan 2012 20:32:12 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327091526!11816651!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODkyMDU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29378 invoked from network); 20 Jan 2012 20:32:06 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 20 Jan 2012 20:32:06 -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 7214A2826;
	Fri, 20 Jan 2012 22:32:05 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id 49D97200B0; Fri, 20 Jan 2012 22:32:05 +0200 (EET)
Date: Fri, 20 Jan 2012 22:32:05 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120120203205.GW12984@reaktio.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 20, 2012 at 05:49:20PM +0100, Sandi Romih wrote:
>    Pasi,
> =

>    I have that enabled in my BIOS, VT-d for the chipset and VT-x for the =
CPU.
>

Ok. And Xen enables IOMMU? Did you verify from Xen's dmesg ? =


http://wiki.xen.org/xenwiki/XenCommonProblems.html#head-2f76ed2d3c282003418=
d37fbbcda510cac266f89


 =

>    Have you managed to pass your gpu through to the domU?
> =


No, I haven't tried that yet. I've been planning to, but I haven't had time=
 for it yet.

There are many people who are using Xen VGA passthru with Intel, AMD/ATI an=
d Nvidia graphics cards.
Currently it needs a lot of understanding and some custom patching, but you=
 can make it work.

There are even businesses using Xen VGA passthru in production :)

-- Pasi

> =

>    Sandi
> =

>    On Jan 20, 2012 4:47 PM, "Pasi K=E4rkk=E4inen" <[1]pasik@iki.fi> wrote:
> =

>      On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>      >    Hello,
>      >    I have spent a lot of time trying to get gfx passthru working o=
n my
>      system
>      >    without success.
>      >    I looked onto my hardware capabilities again to make sure that =
it
>      does
>      >    support VT-d and I am not too sure that it does fully.
>      >    My hardware is as follows:
>      >    - Supermicro X8DTH-6F motherboard (5520 chipset which supports
>      VT-d)
>      >    - single Xeon X5650 CPU (which is listed as supporting VT-x, no
>      mention of
>      >    VT-d at [1][2]ark.intel.com)
>      >    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
>      AND CPU
>      >    need to support VT-d.
>      >    What confuses me is, why is the 55x0 chipset listed there if no=
ne
>      of the
>      >    CPU's supported, that I know of, dont have the VT-d feature opt=
ion,
>      only
>      >    VT-x.
>      >
> =

>      I've been using VT-d with Xen with Intel 5500 series chipset, and Xe=
on
>      5600 series CPU.
>      VT-d needs to be enabled in the BIOS.
> =

>      -- Pasi
> =

> References
> =

>    Visible links
>    1. mailto:pasik@iki.fi
>    2. http://ark.intel.com/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNW-0001eJ-BY; Fri, 20 Jan 2012 20:48:06 +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 1RoLNR-0001WB-CO
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327092474!11871525!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 9179 invoked from network); 20 Jan 2012 20:47:54 -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;
	20 Jan 2012 20:47: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
	q0KKlpwW007479; Fri, 20 Jan 2012 20:47: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 q0KKlpKe021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:21 -0500
Message-Id: <1327092461-2701-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/21] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/compat/memory.c  |   14 ++++++++++++++
 xen/common/memory.c         |   37 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-ia64/mm.h   |    1 +
 xen/include/public/memory.h |   16 ++++++++++++++++
 xen/include/xlat.lst        |    1 +
 xen/include/xsm/xsm.h       |    6 ++++++
 xen/xsm/dummy.c             |    6 ++++++
 xen/xsm/flask/hooks.c       |    6 ++++++
 8 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 2402984..e7257cc 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -25,6 +25,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             XEN_GUEST_HANDLE(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
+            struct xen_remove_from_physmap *xrfp;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
@@ -179,6 +180,18 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             nat.hnd = compat;
             break;
 
+        case XENMEM_remove_from_physmap:
+        {
+            struct compat_remove_from_physmap cmp;
+
+            if ( copy_from_guest(&cmp, compat, 1) )
+                return -EFAULT;
+
+            XLAT_remove_from_physmap(nat.xrfp, &cmp);
+
+            break;
+        }
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -284,6 +297,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
         case XENMEM_current_reservation:
         case XENMEM_maximum_reservation:
         case XENMEM_maximum_gpfn:
+        case XENMEM_remove_from_physmap:
             break;
 
         default:
diff --git a/xen/common/memory.c b/xen/common/memory.c
index c796137..60b9e17 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -659,6 +659,43 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
 
         break;
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+        else
+            rc = -ENOENT;
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     default:
         rc = arch_memory_op(op, arg);
         break;
diff --git a/xen/include/asm-ia64/mm.h b/xen/include/asm-ia64/mm.h
index d09c363..a2bfc02 100644
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -550,6 +550,7 @@ extern u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__,
 #define gmfn_to_mfn(_d, gpfn)			\
     gmfn_to_mfn_foreign((_d), (gpfn))
 
+#define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
 #define put_gfn(d, g)   ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..5f94380 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -59,6 +59,7 @@
 !	memory_map			memory.h
 !	memory_reservation		memory.h
 !	pod_target			memory.h
+!	remove_from_physmap		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNW-0001eJ-BY; Fri, 20 Jan 2012 20:48:06 +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 1RoLNR-0001WB-CO
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327092474!11871525!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 9179 invoked from network); 20 Jan 2012 20:47:54 -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;
	20 Jan 2012 20:47: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
	q0KKlpwW007479; Fri, 20 Jan 2012 20:47: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 q0KKlpKe021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:21 -0500
Message-Id: <1327092461-2701-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/21] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/compat/memory.c  |   14 ++++++++++++++
 xen/common/memory.c         |   37 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-ia64/mm.h   |    1 +
 xen/include/public/memory.h |   16 ++++++++++++++++
 xen/include/xlat.lst        |    1 +
 xen/include/xsm/xsm.h       |    6 ++++++
 xen/xsm/dummy.c             |    6 ++++++
 xen/xsm/flask/hooks.c       |    6 ++++++
 8 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 2402984..e7257cc 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -25,6 +25,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             XEN_GUEST_HANDLE(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
+            struct xen_remove_from_physmap *xrfp;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
@@ -179,6 +180,18 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             nat.hnd = compat;
             break;
 
+        case XENMEM_remove_from_physmap:
+        {
+            struct compat_remove_from_physmap cmp;
+
+            if ( copy_from_guest(&cmp, compat, 1) )
+                return -EFAULT;
+
+            XLAT_remove_from_physmap(nat.xrfp, &cmp);
+
+            break;
+        }
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -284,6 +297,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
         case XENMEM_current_reservation:
         case XENMEM_maximum_reservation:
         case XENMEM_maximum_gpfn:
+        case XENMEM_remove_from_physmap:
             break;
 
         default:
diff --git a/xen/common/memory.c b/xen/common/memory.c
index c796137..60b9e17 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -659,6 +659,43 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
 
         break;
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+        else
+            rc = -ENOENT;
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     default:
         rc = arch_memory_op(op, arg);
         break;
diff --git a/xen/include/asm-ia64/mm.h b/xen/include/asm-ia64/mm.h
index d09c363..a2bfc02 100644
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -550,6 +550,7 @@ extern u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__,
 #define gmfn_to_mfn(_d, gpfn)			\
     gmfn_to_mfn_foreign((_d), (gpfn))
 
+#define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
 #define put_gfn(d, g)   ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..5f94380 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -59,6 +59,7 @@
 !	memory_map			memory.h
 !	memory_reservation		memory.h
 !	pod_target			memory.h
+!	remove_from_physmap		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNQ-0001YA-Sp; Fri, 20 Jan 2012 20:48:00 +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 1RoLNP-0001Vm-5x
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327092472!10048946!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 20856 invoked from network); 20 Jan 2012 20:47:52 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 20:47:52 -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
	q0KKlpwW007475
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47: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 q0KKlpKd021505
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:20 -0500
Message-Id: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
Subject: [Xen-devel] [PATCH v3 00/21] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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:
 - configuration support added to mini-os build system
 - add mini-os support for conditionally compiling frontends, xenbus
 - XENMEM_remove_from_physmap moved out of arch-specific code
 - use uint32_t for virqs
 - warn when dropping grant v2-only flags when switching versions
 - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
 - ioctl now returns -EEXIST if xenstored has already been connected
 - various cosmetic cleanups, shuffling

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

Other notes:

The console for xenstored is not set up by init-xenstore-domain. If the
hypervisor is compiled with VERBOSE or debug=y, it will be visible on
the hypervisor serial console (or ring buffer if enabled with
console_to_ring). The xenstore stub domain itself supports console
output, and init-xenstore-domain could be extended to daemonize and
spool this output to a log file. The normal xenconsole daemon cannot be
used here due to the possibility of a deadlock.

----

[PATCH 01/21] xen: reinstate previously unused
[PATCH 02/21] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/21] xen: change virq parameters from int to uint32_t
 - new in v3: cleanup as suggested by Jan Beulich
[PATCH 04/21] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 05/21] xen: Preserve reserved grant entries when switching

[PATCH 06/21] tools/libxl: pull xenstore/console domids from
[PATCH 07/21] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 08/21] mini-os: avoid crash if no console is provided
[PATCH 09/21] mini-os: remove per-fd evtchn limit
[PATCH 10/21] mini-os: create app-specific configuration
[PATCH 11/21] mini-os: make frontends and xenbus optional
[PATCH 12/21] mini-os: fix list.h include guard name
 - #10-12 are new in v3, replace v2's #8 and part of #13

[PATCH 13/21] xenstored: use grant references instead of
[PATCH 14/21] xenstored: add NO_SOCKETS compilation option
[PATCH 15/21] xenstored support for in-memory rather than FS based
[PATCH 16/21] xenstored: support running in minios stubdom
[PATCH 17/21] stubdom: enable xenstored build
[PATCH 18/21] xenstored: add --event parameter for bootstrapping
[PATCH 19/21] xenstored: use domain_is_unprivileged instead of
[PATCH 20/21] xenstored: add --priv-domid parameter
[PATCH 21/21] xenstored: Add stub domain builder

[PATCH] xenbus: Add support for xenbus backend in stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNR-0001Z9-T9; Fri, 20 Jan 2012 20:48:01 +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 1RoLNP-0001Vs-S1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327092472!11817504!1
X-Originating-IP: [63.239.65.39]
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 17819 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlq1P023861
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKn021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:30 -0500
Message-Id: <1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 10/21] mini-os: create app-specific configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile       |   15 +++++++++------
 extras/mini-os/apps/common.mk |   11 +++++++++++
 extras/mini-os/apps/grub.mk   |    2 ++
 extras/mini-os/apps/ioemu.mk  |    1 +
 extras/mini-os/files.mk       |   28 ++++++++++++++++++++++++++++
 extras/mini-os/main.c         |   16 ++++++++--------
 extras/mini-os/minios.mk      |    4 ++--
 stubdom/Makefile              |    8 ++++----
 8 files changed, 65 insertions(+), 20 deletions(-)
 create mode 100644 extras/mini-os/apps/common.mk
 create mode 100644 extras/mini-os/apps/grub.mk
 create mode 100644 extras/mini-os/apps/ioemu.mk
 create mode 100644 extras/mini-os/files.mk

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c2ee062..af7d0d4 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,7 +8,12 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(stubdom),y)
+-include apps/$(MINIOS_APP).mk
+include apps/common.mk
+EXTRA_DEPS += $(wildcard $(CURDIR)/apps/$(MINIOS_APP).mk)
+EXTRA_DEPS += $(CURDIR)/apps/common.mk
+else
 include Config.mk
 endif
 
@@ -34,13 +39,11 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+include files.mk
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/apps/common.mk b/extras/mini-os/apps/common.mk
new file mode 100644
index 0000000..12b686d
--- /dev/null
+++ b/extras/mini-os/apps/common.mk
@@ -0,0 +1,11 @@
+# Defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+
+# Export items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
diff --git a/extras/mini-os/apps/grub.mk b/extras/mini-os/apps/grub.mk
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/extras/mini-os/apps/grub.mk
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/extras/mini-os/apps/ioemu.mk b/extras/mini-os/apps/ioemu.mk
new file mode 100644
index 0000000..7ea1d2f
--- /dev/null
+++ b/extras/mini-os/apps/ioemu.mk
@@ -0,0 +1 @@
+CONFIG_QEMU_XS_ARGS=y
diff --git a/extras/mini-os/files.mk b/extras/mini-os/files.mk
new file mode 100644
index 0000000..5c1c6ef
--- /dev/null
+++ b/extras/mini-os/files.mk
@@ -0,0 +1,28 @@
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 3705059..7989f31 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=ioemu $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=caml $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=c $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=grub $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNU-0001cN-Pp; Fri, 20 Jan 2012 20:48:04 +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 1RoLNQ-0001W5-Qb
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327092473!11716249!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 24483 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:47: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
	q0KKlqwW007485
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKj021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:26 -0500
Message-Id: <1327092461-2701-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/21] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..3828c62 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -64,6 +64,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -95,9 +96,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 39e9e05..7e42a50 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -241,9 +241,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNR-0001Z9-T9; Fri, 20 Jan 2012 20:48:01 +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 1RoLNP-0001Vs-S1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327092472!11817504!1
X-Originating-IP: [63.239.65.39]
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 17819 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlq1P023861
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKn021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:30 -0500
Message-Id: <1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 10/21] mini-os: create app-specific configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile       |   15 +++++++++------
 extras/mini-os/apps/common.mk |   11 +++++++++++
 extras/mini-os/apps/grub.mk   |    2 ++
 extras/mini-os/apps/ioemu.mk  |    1 +
 extras/mini-os/files.mk       |   28 ++++++++++++++++++++++++++++
 extras/mini-os/main.c         |   16 ++++++++--------
 extras/mini-os/minios.mk      |    4 ++--
 stubdom/Makefile              |    8 ++++----
 8 files changed, 65 insertions(+), 20 deletions(-)
 create mode 100644 extras/mini-os/apps/common.mk
 create mode 100644 extras/mini-os/apps/grub.mk
 create mode 100644 extras/mini-os/apps/ioemu.mk
 create mode 100644 extras/mini-os/files.mk

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c2ee062..af7d0d4 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,7 +8,12 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(stubdom),y)
+-include apps/$(MINIOS_APP).mk
+include apps/common.mk
+EXTRA_DEPS += $(wildcard $(CURDIR)/apps/$(MINIOS_APP).mk)
+EXTRA_DEPS += $(CURDIR)/apps/common.mk
+else
 include Config.mk
 endif
 
@@ -34,13 +39,11 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+include files.mk
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/apps/common.mk b/extras/mini-os/apps/common.mk
new file mode 100644
index 0000000..12b686d
--- /dev/null
+++ b/extras/mini-os/apps/common.mk
@@ -0,0 +1,11 @@
+# Defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+
+# Export items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
diff --git a/extras/mini-os/apps/grub.mk b/extras/mini-os/apps/grub.mk
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/extras/mini-os/apps/grub.mk
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/extras/mini-os/apps/ioemu.mk b/extras/mini-os/apps/ioemu.mk
new file mode 100644
index 0000000..7ea1d2f
--- /dev/null
+++ b/extras/mini-os/apps/ioemu.mk
@@ -0,0 +1 @@
+CONFIG_QEMU_XS_ARGS=y
diff --git a/extras/mini-os/files.mk b/extras/mini-os/files.mk
new file mode 100644
index 0000000..5c1c6ef
--- /dev/null
+++ b/extras/mini-os/files.mk
@@ -0,0 +1,28 @@
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 3705059..7989f31 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=ioemu $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=caml $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=c $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=grub $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNQ-0001YA-Sp; Fri, 20 Jan 2012 20:48:00 +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 1RoLNP-0001Vm-5x
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327092472!10048946!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 20856 invoked from network); 20 Jan 2012 20:47:52 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 20:47:52 -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
	q0KKlpwW007475
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47: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 q0KKlpKd021505
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:20 -0500
Message-Id: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
Subject: [Xen-devel] [PATCH v3 00/21] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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:
 - configuration support added to mini-os build system
 - add mini-os support for conditionally compiling frontends, xenbus
 - XENMEM_remove_from_physmap moved out of arch-specific code
 - use uint32_t for virqs
 - warn when dropping grant v2-only flags when switching versions
 - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
 - ioctl now returns -EEXIST if xenstored has already been connected
 - various cosmetic cleanups, shuffling

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

Other notes:

The console for xenstored is not set up by init-xenstore-domain. If the
hypervisor is compiled with VERBOSE or debug=y, it will be visible on
the hypervisor serial console (or ring buffer if enabled with
console_to_ring). The xenstore stub domain itself supports console
output, and init-xenstore-domain could be extended to daemonize and
spool this output to a log file. The normal xenconsole daemon cannot be
used here due to the possibility of a deadlock.

----

[PATCH 01/21] xen: reinstate previously unused
[PATCH 02/21] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/21] xen: change virq parameters from int to uint32_t
 - new in v3: cleanup as suggested by Jan Beulich
[PATCH 04/21] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 05/21] xen: Preserve reserved grant entries when switching

[PATCH 06/21] tools/libxl: pull xenstore/console domids from
[PATCH 07/21] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 08/21] mini-os: avoid crash if no console is provided
[PATCH 09/21] mini-os: remove per-fd evtchn limit
[PATCH 10/21] mini-os: create app-specific configuration
[PATCH 11/21] mini-os: make frontends and xenbus optional
[PATCH 12/21] mini-os: fix list.h include guard name
 - #10-12 are new in v3, replace v2's #8 and part of #13

[PATCH 13/21] xenstored: use grant references instead of
[PATCH 14/21] xenstored: add NO_SOCKETS compilation option
[PATCH 15/21] xenstored support for in-memory rather than FS based
[PATCH 16/21] xenstored: support running in minios stubdom
[PATCH 17/21] stubdom: enable xenstored build
[PATCH 18/21] xenstored: add --event parameter for bootstrapping
[PATCH 19/21] xenstored: use domain_is_unprivileged instead of
[PATCH 20/21] xenstored: add --priv-domid parameter
[PATCH 21/21] xenstored: Add stub domain builder

[PATCH] xenbus: Add support for xenbus backend in stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNU-0001cN-Pp; Fri, 20 Jan 2012 20:48:04 +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 1RoLNQ-0001W5-Qb
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327092473!11716249!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 24483 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:47: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
	q0KKlqwW007485
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKj021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:26 -0500
Message-Id: <1327092461-2701-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/21] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..3828c62 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -64,6 +64,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -95,9 +96,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 39e9e05..7e42a50 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -241,9 +241,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNM-0001WH-4l; Fri, 20 Jan 2012 20:47:56 +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 1RoLNK-0001Vo-KR
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327092414!57810691!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 29356 invoked from network); 20 Jan 2012 20:46:55 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-27.messagelabs.com with SMTP;
	20 Jan 2012 20:46:55 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0KKlpwW007483
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKh021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:24 -0500
Message-Id: <1327092461-2701-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/21] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 97c7d53..e1bbc9a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index acf9c8a..d99f886 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNT-0001at-HD; Fri, 20 Jan 2012 20:48:03 +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 1RoLNQ-0001W3-Em
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327092473!11715082!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 24793 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlq1P023864
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKp021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:32 -0500
Message-Id: <1327092461-2701-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 12/21] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The symbol _LINUX_LIST_H collides with other header files.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNS-0001Zt-Q2; Fri, 20 Jan 2012 20:48:02 +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 1RoLNQ-0001Vz-DL
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327092473!1513196!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 22332 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlpwW007482
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47: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 q0KKlpKg021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:23 -0500
Message-Id: <1327092461-2701-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/21] xen: change virq parameters from int to
	uint32_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c   |   10 +++++-----
 xen/include/asm-ia64/event.h |    2 +-
 xen/include/asm-x86/event.h  |    2 +-
 xen/include/xen/event.h      |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43bd167..f784254 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,11 +104,11 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 
 static int evtchn_set_pending(struct vcpu *v, int port);
 
-static int virq_is_global(int virq)
+static int virq_is_global(uint32_t virq)
 {
     int rc;
 
-    ASSERT((virq >= 0) && (virq < NR_VIRQS));
+    ASSERT(virq < NR_VIRQS);
 
     switch ( virq )
     {
@@ -665,12 +665,12 @@ static int evtchn_set_pending(struct vcpu *v, int port)
     return 0;
 }
 
-int guest_enabled_event(struct vcpu *v, int virq)
+int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
 }
 
-void send_guest_vcpu_virq(struct vcpu *v, int virq)
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 {
     unsigned long flags;
     int port;
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
     unsigned long flags;
     int port;
diff --git a/xen/include/asm-ia64/event.h b/xen/include/asm-ia64/event.h
index c99babd..4463cb3 100644
--- a/xen/include/asm-ia64/event.h
+++ b/xen/include/asm-ia64/event.h
@@ -63,7 +63,7 @@ static inline void local_event_delivery_enable(void)
     current->vcpu_info->evtchn_upcall_mask = 0;
 }
 
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     int rc;
 
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index 606ec6d..06057c7 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -39,7 +39,7 @@ static inline void local_event_delivery_enable(void)
 }
 
 /* No arch specific virq definition now. Default to global. */
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     return 1;
 }
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 40b8a7a..22fc6a3 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,7 @@
  *  @v:        VCPU to which virtual IRQ should be sent
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_vcpu_virq(struct vcpu *v, int virq);
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
  * send_global_virq: Notify the domain handling a global VIRQ.
@@ -65,7 +65,7 @@ void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
 /* Query if event channel is in use by the guest */
-int guest_enabled_event(struct vcpu *v, int virq);
+int guest_enabled_event(struct vcpu *v, uint32_t virq);
 
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNP-0001XE-Fj; Fri, 20 Jan 2012 20:47:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RoLNO-0001Vx-Cu
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327092427!50973810!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 21072 invoked from network); 20 Jan 2012 20:47:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-27.messagelabs.com with SMTP;
	20 Jan 2012 20:47:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0KKlqwW007494
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKw021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:39 -0500
Message-Id: <1327092461-2701-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 19/21] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index aad0298..4897c97 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -492,7 +492,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -830,11 +830,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 6a0dbc2..d89528f 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -356,7 +356,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -420,7 +420,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -472,7 +472,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -509,7 +509,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNT-0001aR-5e; Fri, 20 Jan 2012 20:48:03 +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 1RoLNQ-0001W1-ER
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327092473!9841964!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 27025 invoked from network); 20 Jan 2012 20:47:54 -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;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023875
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKx021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:40 -0500
Message-Id: <1327092461-2701-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 20/21] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4897c97..7ad6db8 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1778,6 +1778,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1790,6 +1791,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index d89528f..8c215fb 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -261,7 +261,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNX-0001gW-Gx; Fri, 20 Jan 2012 20:48:07 +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 1RoLNR-0001WG-E8
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327092474!9212326!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 24823 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-11.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 20:47: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
	q0KKlqwW007489; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKm021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:29 -0500
Message-Id: <1327092461-2701-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/21] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This changes the minios evtchn implementation to use a list instead of
an array which ahis allows it to grow as necessary to support any number
of ports, only limited by Xen (NR_EVS is 1024, should be enough for now).

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNV-0001dM-If; Fri, 20 Jan 2012 20:48:05 +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 1RoLNR-0001W7-8D
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327092474!11325871!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 16888 invoked from network); 20 Jan 2012 20:47:54 -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;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023869; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKs021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:35 -0500
Message-Id: <1327092461-2701-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 15/21] xenstored: support for tdb_copy with
	TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
databases; this is required to run in mini-os which does not use a
filesystem.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/tdb.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..3ecd3fc 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,41 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+		return copy;
+intfail:
+		talloc_free(copy);
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNY-0001jg-Qm; Fri, 20 Jan 2012 20:48:08 +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 1RoLNS-0001WT-3x
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327092474!10043271!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 25452 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 20:47:54 -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
	q0KKlp1P023859; Fri, 20 Jan 2012 20:47: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 q0KKlpKf021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:22 -0500
Message-Id: <1327092461-2701-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/21] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   66 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 154 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 8b34769..8f3426f 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -747,6 +747,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52a63ef..f1a7ede 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -116,7 +116,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -492,7 +492,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -633,7 +633,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -690,7 +690,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d6ae09b..97c7d53 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -994,6 +994,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..43bd167 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,68 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++)
+    {
+        if (global_virq_handlers[virq] == d)
+        {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count)
+    {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1222,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..79b266f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -287,7 +287,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -314,7 +314,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 232d50e..40b8a7a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,11 +23,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..e3cae60 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..acf9c8a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..543dc77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNM-0001WH-4l; Fri, 20 Jan 2012 20:47:56 +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 1RoLNK-0001Vo-KR
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327092414!57810691!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 29356 invoked from network); 20 Jan 2012 20:46:55 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-27.messagelabs.com with SMTP;
	20 Jan 2012 20:46:55 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0KKlpwW007483
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKh021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:24 -0500
Message-Id: <1327092461-2701-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/21] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 97c7d53..e1bbc9a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -263,6 +263,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index acf9c8a..d99f886 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNS-0001Zt-Q2; Fri, 20 Jan 2012 20:48:02 +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 1RoLNQ-0001Vz-DL
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327092473!1513196!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 22332 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-9.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlpwW007482
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47: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 q0KKlpKg021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:23 -0500
Message-Id: <1327092461-2701-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/21] xen: change virq parameters from int to
	uint32_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c   |   10 +++++-----
 xen/include/asm-ia64/event.h |    2 +-
 xen/include/asm-x86/event.h  |    2 +-
 xen/include/xen/event.h      |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43bd167..f784254 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,11 +104,11 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 
 static int evtchn_set_pending(struct vcpu *v, int port);
 
-static int virq_is_global(int virq)
+static int virq_is_global(uint32_t virq)
 {
     int rc;
 
-    ASSERT((virq >= 0) && (virq < NR_VIRQS));
+    ASSERT(virq < NR_VIRQS);
 
     switch ( virq )
     {
@@ -665,12 +665,12 @@ static int evtchn_set_pending(struct vcpu *v, int port)
     return 0;
 }
 
-int guest_enabled_event(struct vcpu *v, int virq)
+int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
 }
 
-void send_guest_vcpu_virq(struct vcpu *v, int virq)
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 {
     unsigned long flags;
     int port;
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
     unsigned long flags;
     int port;
diff --git a/xen/include/asm-ia64/event.h b/xen/include/asm-ia64/event.h
index c99babd..4463cb3 100644
--- a/xen/include/asm-ia64/event.h
+++ b/xen/include/asm-ia64/event.h
@@ -63,7 +63,7 @@ static inline void local_event_delivery_enable(void)
     current->vcpu_info->evtchn_upcall_mask = 0;
 }
 
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     int rc;
 
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index 606ec6d..06057c7 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -39,7 +39,7 @@ static inline void local_event_delivery_enable(void)
 }
 
 /* No arch specific virq definition now. Default to global. */
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     return 1;
 }
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 40b8a7a..22fc6a3 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,7 @@
  *  @v:        VCPU to which virtual IRQ should be sent
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_vcpu_virq(struct vcpu *v, int virq);
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
  * send_global_virq: Notify the domain handling a global VIRQ.
@@ -65,7 +65,7 @@ void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
 /* Query if event channel is in use by the guest */
-int guest_enabled_event(struct vcpu *v, int virq);
+int guest_enabled_event(struct vcpu *v, uint32_t virq);
 
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNU-0001bt-Dd; Fri, 20 Jan 2012 20:48:04 +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 1RoLNQ-0001W6-Ln
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327092473!11325870!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 16856 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 20:47: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
	q0KKlqwW007502
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpL0021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:41 -0500
Message-Id: <1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 21/21] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   44 ++++++++++++++
 tools/xenstore/Makefile                  |    9 ++-
 tools/xenstore/init-xenstore-domain.c    |   94 ++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..bbee8c6
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,44 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 3a061d6..9b411a5 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
@@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..f6c31d0
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,94 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+	if (rv < 0) return rv;
+	snprintf(cmdline, 512, "--event %d", rv);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNP-0001XE-Fj; Fri, 20 Jan 2012 20:47:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RoLNO-0001Vx-Cu
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:58 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327092427!50973810!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 21072 invoked from network); 20 Jan 2012 20:47:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-27.messagelabs.com with SMTP;
	20 Jan 2012 20:47:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0KKlqwW007494
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKw021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:39 -0500
Message-Id: <1327092461-2701-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 19/21] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index aad0298..4897c97 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -492,7 +492,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -830,11 +830,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 6a0dbc2..d89528f 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -356,7 +356,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -420,7 +420,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -472,7 +472,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -509,7 +509,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNT-0001at-HD; Fri, 20 Jan 2012 20:48:03 +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 1RoLNQ-0001W3-Em
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-216.messagelabs.com!1327092473!11715082!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 24793 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlq1P023864
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKp021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:32 -0500
Message-Id: <1327092461-2701-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 12/21] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The symbol _LINUX_LIST_H collides with other header files.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNX-0001gW-Gx; Fri, 20 Jan 2012 20:48:07 +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 1RoLNR-0001WG-E8
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327092474!9212326!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 24823 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-11.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 20:47: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
	q0KKlqwW007489; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKm021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:29 -0500
Message-Id: <1327092461-2701-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/21] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This changes the minios evtchn implementation to use a list instead of
an array which ahis allows it to grow as necessary to support any number
of ports, only limited by Xen (NR_EVS is 1024, should be enough for now).

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNV-0001dM-If; Fri, 20 Jan 2012 20:48:05 +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 1RoLNR-0001W7-8D
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327092474!11325871!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 16888 invoked from network); 20 Jan 2012 20:47:54 -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;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023869; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKs021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:35 -0500
Message-Id: <1327092461-2701-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 15/21] xenstored: support for tdb_copy with
	TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
databases; this is required to run in mini-os which does not use a
filesystem.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/tdb.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..3ecd3fc 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,41 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+		return copy;
+intfail:
+		talloc_free(copy);
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNT-0001aR-5e; Fri, 20 Jan 2012 20:48:03 +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 1RoLNQ-0001W1-ER
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327092473!9841964!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 27025 invoked from network); 20 Jan 2012 20:47:54 -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;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023875
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKx021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:40 -0500
Message-Id: <1327092461-2701-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 20/21] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4897c97..7ad6db8 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1778,6 +1778,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1790,6 +1791,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1852,6 +1854,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index d89528f..8c215fb 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -261,7 +261,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNN-0001WU-HT; Fri, 20 Jan 2012 20:47:57 +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 1RoLNL-0001W4-Ol
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327092357!60608169!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 7854 invoked from network); 20 Jan 2012 20:45:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-27.messagelabs.com with SMTP;
	20 Jan 2012 20:45:58 -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
	q0KKlqwW007488
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKl021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:28 -0500
Message-Id: <1327092461-2701-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/21] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..af0afed 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+        if (!intf)
+            return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNY-0001jg-Qm; Fri, 20 Jan 2012 20:48:08 +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 1RoLNS-0001WT-3x
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327092474!10043271!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 25452 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 20:47:54 -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
	q0KKlp1P023859; Fri, 20 Jan 2012 20:47: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 q0KKlpKf021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:22 -0500
Message-Id: <1327092461-2701-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/21] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   66 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 154 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 8b34769..8f3426f 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -747,6 +747,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 52a63ef..f1a7ede 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -116,7 +116,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -492,7 +492,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -633,7 +633,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -690,7 +690,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index d6ae09b..97c7d53 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -994,6 +994,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..43bd167 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,68 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++)
+    {
+        if (global_virq_handlers[virq] == d)
+        {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count)
+    {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1222,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 8a4c684..79b266f 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -287,7 +287,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -314,7 +314,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 232d50e..40b8a7a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,11 +23,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..e3cae60 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..acf9c8a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..543dc77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNU-0001bt-Dd; Fri, 20 Jan 2012 20:48:04 +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 1RoLNQ-0001W6-Ln
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327092473!11325870!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 16856 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-216.messagelabs.com with SMTP;
	20 Jan 2012 20:47: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
	q0KKlqwW007502
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpL0021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:41 -0500
Message-Id: <1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 21/21] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   44 ++++++++++++++
 tools/xenstore/Makefile                  |    9 ++-
 tools/xenstore/init-xenstore-domain.c    |   94 ++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..bbee8c6
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,44 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 3a061d6..9b411a5 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
@@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..f6c31d0
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,94 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+	if (rv < 0) return rv;
+	snprintf(cmdline, 512, "--event %d", rv);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNS-0001ZV-C2; Fri, 20 Jan 2012 20:48:02 +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 1RoLNQ-0001W0-CG
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327092473!7971069!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 11927 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-15.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023874
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKv021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:38 -0500
Message-Id: <1327092461-2701-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/21] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   11 +++++++++++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 66ca555..aad0298 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1775,6 +1775,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1788,6 +1789,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1847,6 +1849,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 435f76a..6a0dbc2 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -602,6 +602,17 @@ void restore_existing_connections(void)
 #ifdef __MINIOS__
 static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNN-0001WU-HT; Fri, 20 Jan 2012 20:47:57 +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 1RoLNL-0001W4-Ol
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:55 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327092357!60608169!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 7854 invoked from network); 20 Jan 2012 20:45:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-27.messagelabs.com with SMTP;
	20 Jan 2012 20:45:58 -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
	q0KKlqwW007488
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKl021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:28 -0500
Message-Id: <1327092461-2701-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/21] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..af0afed 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+        if (!intf)
+            return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNX-0001fr-4K; Fri, 20 Jan 2012 20:48:07 +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 1RoLNR-0001W9-Ce
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327092474!8639992!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 20799 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023870; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKt021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:36 -0500
Message-Id: <1327092461-2701-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 16/21] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/Makefile                |    9 +++++-
 tools/xenstore/tdb.c                   |    6 ++--
 tools/xenstore/utils.h                 |    2 +
 tools/xenstore/xenstored_core.c        |   47 ++++++++++++++++++++++++++++++-
 tools/xenstore/xenstored_domain.c      |   11 +++++++
 tools/xenstore/xenstored_transaction.c |    2 +
 6 files changed, 71 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..3a061d6 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 3ecd3fc..cb66ea7 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 
 		/* Iterate through chain */
 		while( tlock->off) {
-			tdb_off current;
+			tdb_off mycurrent;
 			if (rec_read(tdb, tlock->off, rec) == -1)
 				goto fail;
 
@@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 			}
 
 			/* Try to clean dead ones from old traverses */
-			current = tlock->off;
+			mycurrent = tlock->off;
 			tlock->off = rec->next;
 			if (!tdb->read_only && 
-			    do_delete(tdb, current, rec) != 0)
+			    do_delete(tdb, mycurrent, rec) != 0)
 				goto fail;
 		}
 		tdb_unlock(tdb, tlock->hash, F_WRLCK);
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 631bfe4..66ca555 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -32,7 +32,9 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#ifndef NO_SYSLOG
 #include <syslog.h>
+#endif
 #include <string.h>
 #include <errno.h>
 #include <dirent.h>
@@ -61,13 +63,24 @@ LIST_HEAD(connections);
 static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
+#ifndef NO_REOPEN_LOG
 static int reopen_log_pipe[2];
+#endif
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
 
+#ifdef __MINIOS__
+#define lockf(...) (-ENOSYS)
+#endif
+
+#ifdef NO_SYSLOG
+#define openlog(...) ((void) 0)
+#define syslog(...)  ((void) 0)
+#endif
+
 #define log(...)							\
 	do {								\
 		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
@@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
+#ifndef __MINIOS__
 	if (rename(newname, xs_daemon_tdb()) != 0)
 		return false;
+#endif
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -195,6 +210,11 @@ void trace_destroy(const void *data, const char *type)
 	trace("DESTROY %s %p\n", type, data);
 }
 
+#ifdef NO_REOPEN_LOG
+static void reopen_log(void)
+{
+}
+#else
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
@@ -222,7 +242,7 @@ static void reopen_log(void)
 			trace("\n***\n");
 	}
 }
-
+#endif
 
 static bool write_messages(struct connection *conn)
 {
@@ -326,7 +346,9 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
 #endif
+#ifndef NO_REOPEN_LOG
 	set_fd(reopen_log_pipe[0], inset, &max);
+#endif
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1415,7 +1437,11 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
+#ifdef __MINIOS__
+#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
+#else
 #define TDB_FLAGS 0
+#endif
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1440,7 +1466,11 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
+#ifdef __MINIOS__
+	tdb_ctx = NULL;
+#else
 	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+#endif
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1666,6 +1696,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifndef __MINIOS__
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1712,7 +1743,7 @@ static void daemonize(void)
 	/* Discard our parent's old-fashioned umask prejudices. */
 	umask(0);
 }
-
+#endif
 
 static void usage(void)
 {
@@ -1823,6 +1854,7 @@ int main(int argc, char *argv[])
 
 	reopen_log();
 
+#ifndef __MINIOS__
 	/* make sure xenstored directory exists */
 	if (mkdir(xs_daemon_rundir(), 0755)) {
 		if (errno != EEXIST) {
@@ -1844,6 +1876,7 @@ int main(int argc, char *argv[])
 	}
 	if (pidfile)
 		write_pidfile(pidfile);
+#endif
 
 	/* Talloc leak reports go to stderr, which is closed if we fork. */
 	if (!dofork)
@@ -1890,9 +1923,11 @@ int main(int argc, char *argv[])
 		barf_perror("Could not listen on sockets");
 #endif
 
+#ifndef NO_REOPEN_LOG
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1909,6 +1944,7 @@ int main(int argc, char *argv[])
 		fflush(stdout);
 	}
 
+#ifndef __MINIOS__
 	/* redirect to /dev/null now we're ready to accept connections */
 	if (dofork) {
 		int devnull = open("/dev/null", O_RDWR);
@@ -1920,8 +1956,11 @@ int main(int argc, char *argv[])
 		close(devnull);
 		xprintf = trace;
 	}
+#endif
 
+#ifndef NO_REOPEN_LOG
 	signal(SIGHUP, trigger_reopen_log);
+#endif
 
 	if (xce_handle != NULL)
 		evtchn_fd = xc_evtchn_fd(xce_handle);
@@ -1929,8 +1968,10 @@ int main(int argc, char *argv[])
 	/* Get ready to listen to the tools. */
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1942,12 +1983,14 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
+#ifndef NO_REOPEN_LOG
 		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
 			reopen_log();
 		}
+#endif
 
 #ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 661d955..435f76a 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		unmap_interface(domain->interface);
+#else
 		if (domain->domid == 0)
 			munmap(domain->interface, getpagesize());
 		else
 			unmap_interface(domain->interface);
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
@@ -595,6 +599,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static int dom0_init(void)
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -618,6 +628,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
index 380c691..c59acfb 100644
--- a/tools/xenstore/xenstored_transaction.c
+++ b/tools/xenstore/xenstored_transaction.c
@@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
 	trace_destroy(trans, "transaction");
 	if (trans->tdb)
 		tdb_close(trans->tdb);
+#ifndef __MINIOS__
 	unlink(trans->tdb_name);
+#endif
 	return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNR-0001Ya-Aa; Fri, 20 Jan 2012 20:48:01 +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 1RoLNP-0001Vr-Oc
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327092472!11716247!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 24451 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlqwW007484
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKi021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:25 -0500
Message-Id: <1327092461-2701-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/21] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to preserve v2-only features such as sub-page grants will
produce a warning and invalidate the resulting v1 grant entry.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
 xen/include/public/grant_table.h |    7 +++++
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 34a49db..dd9f904 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2110,6 +2110,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2130,7 +2131,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2155,15 +2156,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1)
+    {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    }
+    else if (gt->gt_version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)
+            {
+                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
+                       d->domain_id, reserved_entries[i].flags, i);
+                reserved_entries[i].flags = GTF_invalid;
+            }
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1)
     {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    }
+    else if (gt->gt_version != 0 && op.version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..5604638 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,13 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* The first few grant table entries will be preserved across grant table
+ * version changes and may be pre-populated at domain creation by tools.
+ */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNO-0001Wk-2B; Fri, 20 Jan 2012 20:47:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RoLNM-0001WF-E1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:56 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327092446!56597077!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 27875 invoked from network); 20 Jan 2012 20:47:27 -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;
	20 Jan 2012 20:47:27 -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
	q0KKlq1P023867; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKr021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:34 -0500
Message-Id: <1327092461-2701-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 14/21] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

option for compiling xenstored without unix sockets to support running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c |   22 +++++++++++++++++++++-
 tools/xenstore/xs.c             |    2 ++
 tools/xenstore/xs_lib.c         |    4 ++++
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..631bfe4 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
+#ifndef NO_SOCKETS
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
+#endif
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -343,12 +347,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
+#ifndef NO_SOCKETS
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
 	close(*fd);
 	return 0;
 }
+#endif
 
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
@@ -1352,6 +1358,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifndef NO_SOCKETS
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1406,6 +1413,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1753,7 +1761,11 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
+#ifdef NO_SOCKETS
+	int minus_one = -1;
+#else
 	struct sockaddr_un addr;
+#endif
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,6 +1849,9 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
+#ifdef NO_SOCKETS
+	sock = ro_sock = &minus_one;
+#else
 	/* Create sockets for them to listen to. */
 	sock = talloc(talloc_autofree_context(), int);
 	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
@@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
 		barf_perror("Could not create socket");
 	talloc_set_destructor(sock, destroy_fd);
 	talloc_set_destructor(ro_sock, destroy_fd);
+#endif
 
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
+#ifndef NO_SOCKETS
 	/* FIXME: Be more sophisticated, don't mug running daemon. */
 	unlink(xs_daemon_socket());
 	unlink(xs_daemon_socket_ro());
@@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
 	if (listen(*sock, 1) != 0
 	    || listen(*ro_sock, 1) != 0)
 		barf_perror("Could not listen on sockets");
+#endif
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
@@ -1931,11 +1949,13 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
+#ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
 		if (FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
+#endif
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
 			handle_event();
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index 0a01675..60f2cee 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
 {
 	struct xs_handle *xsh = NULL;
 
+#ifndef NO_SOCKETS
 	if (flags & XS_OPEN_READONLY)
 		xsh = get_handle(xs_daemon_socket_ro());
 	else
 		xsh = get_handle(xs_daemon_socket());
+#endif
 
 	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
 		xsh = get_handle(xs_domain_dev());
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
index 03a9ee4..af3db6b 100644
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
 	return (s ? s : "/var/run/xenstored");
 }
 
+#ifndef NO_SOCKETS
 static const char *xs_daemon_path(void)
 {
 	static char buf[PATH_MAX];
@@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_daemon_tdb(void)
 {
@@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
 	return buf;
 }
 
+#ifndef NO_SOCKETS
 const char *xs_daemon_socket(void)
 {
 	return xs_daemon_path();
@@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_domain_dev(void)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNV-0001dt-VZ; Fri, 20 Jan 2012 20:48:05 +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 1RoLNR-0001W8-8o
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327092474!4351057!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 22880 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:47: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
	q0KKlqwW007491; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKq021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:33 -0500
Message-Id: <1327092461-2701-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 13/21] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_domain.c |   52 ++++++++++++++++++++++++++++++++----
 1 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..661d955 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
 	return len;
 }
 
+static void *map_interface(domid_t domid, unsigned long mfn)
+{
+	if (*xcg_handle >= 0) {
+		/* this is the preferred method */
+		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	} else {
+		return xc_map_foreign_range(*xc_handle, domid,
+			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+	}
+}
+
+static void unmap_interface(void *interface)
+{
+	if (*xcg_handle >= 0)
+		xc_gnttab_munmap(*xcg_handle, interface, 1);
+	else
+		munmap(interface, getpagesize());
+}
+
 static int destroy_domain(void *_domain)
 {
 	struct domain *domain = _domain;
@@ -174,8 +196,12 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		if (domain->domid == 0)
+			munmap(domain->interface, getpagesize());
+		else
+			unmap_interface(domain->interface);
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +370,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		interface = map_interface(domid, mfn);
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +378,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			unmap_interface(interface);
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +576,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +633,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNV-0001cq-6L; Fri, 20 Jan 2012 20:48:05 +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 1RoLNQ-0001W2-JS
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327092473!9992337!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 1400 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlqwW007490
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKo021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:31 -0500
Message-Id: <1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 11/21] mini-os: make frontends and xenbus
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds compile-time logic to disable certain frontends in mini-os:
 - pcifront is disabled by default, enabled for ioemu
 - blkfront, netfront, fbfront, and kbdfront are enabled by default
 - xenbus is required for any frontend, and is enabled by default

If all frontends and xenbus are disabled, mini-os will run without
needing to communicate with xenstore, making it suitable to run the
xenstore daemon.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile               |    5 +++-
 extras/mini-os/apps/common.mk         |   11 +++++++++
 extras/mini-os/apps/ioemu.mk          |    1 +
 extras/mini-os/console/xencons_ring.c |   15 ++++++++++--
 extras/mini-os/files.mk               |   12 +++++-----
 extras/mini-os/include/lib.h          |    2 +
 extras/mini-os/kernel.c               |   40 +++++++++++++++++++++++++++++++-
 extras/mini-os/lib/sys.c              |   28 +++++++++++++++++++++++
 extras/mini-os/main.c                 |    6 +++-
 9 files changed, 106 insertions(+), 14 deletions(-)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index af7d0d4..7419211 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -70,7 +70,10 @@ ifeq ($(lwip),y)
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
 LWO	:= $(patsubst %.c,%.o,$(LWC))
-LWO	+= $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
+LWO	+= $(OBJ_DIR)/lwip-arch.o
+ifeq ($(CONFIG_NETFRONT),y)
+LWO += $(OBJ_DIR)/lwip-net.o
+endif
 
 $(OBJ_DIR)/lwip.a: $(LWO)
 	$(RM) $@
diff --git a/extras/mini-os/apps/common.mk b/extras/mini-os/apps/common.mk
index 12b686d..1fd4c9f 100644
--- a/extras/mini-os/apps/common.mk
+++ b/extras/mini-os/apps/common.mk
@@ -1,11 +1,22 @@
 # Defaults
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
+CONFIG_BLKFRONT ?= y
+CONFIG_NETFRONT ?= y
+CONFIG_FBFRONT ?= y
+CONFIG_KBDFRONT ?= y
+CONFIG_XENBUS ?= y
 
 # Export items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
+flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
+flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
+flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
+flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 
 DEF_CFLAGS += $(flags-y)
 
diff --git a/extras/mini-os/apps/ioemu.mk b/extras/mini-os/apps/ioemu.mk
index 7ea1d2f..e3a96da 100644
--- a/extras/mini-os/apps/ioemu.mk
+++ b/extras/mini-os/apps/ioemu.mk
@@ -1 +1,2 @@
 CONFIG_QEMU_XS_ARGS=y
+CONFIG_PCIFRONT=y
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index af0afed..c3eba35 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -189,6 +189,7 @@ struct consfront_dev *xencons_ring_init(void)
 
 void free_consfront(struct consfront_dev *dev)
 {
+#ifdef CONFIG_XENBUS
     char* err = NULL;
     XenbusState state;
 
@@ -217,6 +218,7 @@ void free_consfront(struct consfront_dev *dev)
 close:
     if (err) free(err);
     xenbus_unwatch_path_token(XBT_NIL, path, path);
+#endif
 
     mask_evtchn(dev->evtchn);
     unbind_evtchn(dev->evtchn);
@@ -231,16 +233,18 @@ close:
 
 struct consfront_dev *init_consfront(char *_nodename)
 {
+    struct consfront_dev *dev;
+    char nodename[256];
+    static int consfrontends = 3;
+#ifdef CONFIG_XENBUS
     xenbus_transaction_t xbt;
     char* err;
     char* message=NULL;
     int retry=0;
     char* msg = NULL;
-    char nodename[256];
     char path[256];
-    static int consfrontends = 3;
-    struct consfront_dev *dev;
     int res;
+#endif
 
     if (!_nodename)
         snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
@@ -257,6 +261,7 @@ struct consfront_dev *init_consfront(char *_nodename)
     dev->fd = -1;
 #endif
 
+#ifdef CONFIG_XENBUS
     snprintf(path, sizeof(path), "%s/backend-id", nodename);
     if ((res = xenbus_read_integer(path)) < 0) 
         return NULL;
@@ -351,17 +356,21 @@ done:
             goto error;
         }
     }
+#endif
+
     unmask_evtchn(dev->evtchn);
 
     printk("**************************\n");
 
     return dev;
 
+#ifdef CONFIG_XENBUS
 error:
     free(msg);
     free(err);
     free_consfront(dev);
     return NULL;
+#endif
 }
 
 void xencons_resume(void)
diff --git a/extras/mini-os/files.mk b/extras/mini-os/files.mk
index 5c1c6ef..be37a8b 100644
--- a/extras/mini-os/files.mk
+++ b/extras/mini-os/files.mk
@@ -1,7 +1,7 @@
-src-y += blkfront.c
+src-$(CONFIG_BLKFRONT) += blkfront.c
 src-y += daytime.c
 src-y += events.c
-src-y += fbfront.c
+src-$(CONFIG_FBFRONT) += fbfront.c
 src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
@@ -9,8 +9,8 @@ src-y += kernel.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
-src-y += netfront.c
-src-y += pcifront.c
+src-$(CONFIG_NETFRONT) += netfront.c
+src-$(CONFIG_PCIFRONT) += pcifront.c
 src-y += sched.c
 
 src-y += lib/ctype.c
@@ -20,9 +20,9 @@ src-y += lib/stack_chk_fail.c
 src-y += lib/string.c
 src-y += lib/sys.c
 src-y += lib/xmalloc.c
-src-y += lib/xs.c
+src-$(CONFIG_XENBUS) += lib/xs.c
 
-src-y += xenbus/xenbus.c
+src-$(CONFIG_XENBUS) += xenbus/xenbus.c
 
 src-y += console/console.c
 src-y += console/xencons_ring.c
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 12070c3..9c69440 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -182,11 +182,13 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
              * FD.  */
             xenbus_event_queue events;
         } xenbus;
+#endif
     };
     int read;	/* maybe available for read */
 } files[];
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index 2875bf1..9e490d5 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -46,8 +46,6 @@
 #include <xen/features.h>
 #include <xen/version.h>
 
-static struct netfront_dev *net_dev;
-
 uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
 
 void setup_xen_features(void)
@@ -86,11 +84,16 @@ static void periodic_thread(void *p)
     }
 }
 
+#ifdef CONFIG_NETFRONT
+static struct netfront_dev *net_dev;
+
 static void netfront_thread(void *p)
 {
     net_dev = init_netfront(NULL, NULL, NULL, NULL);
 }
+#endif
 
+#ifdef CONFIG_BLKFRONT
 static struct blkfront_dev *blk_dev;
 static struct blkfront_info blk_info;
 static uint64_t blk_size_read;
@@ -255,6 +258,9 @@ static void blkfront_thread(void *p)
 #endif
     }
 }
+#endif
+
+#ifdef CONFIG_FBFRONT
 
 #define WIDTH 800
 #define HEIGHT 600
@@ -347,6 +353,9 @@ static void refresh_cursor(int new_x, int new_y)
     fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
     fbfront_update(fb_dev, new_x, new_y, 9, 9);
 }
+#endif
+
+#ifdef CONFIG_KBDFRONT
 
 static struct kbdfront_dev *kbd_dev;
 static void kbdfront_thread(void *p)
@@ -431,7 +440,9 @@ static void kbdfront_thread(void *p)
             schedule();
     }
 }
+#endif
 
+#ifdef CONFIG_PCIFRONT
 static struct pcifront_dev *pci_dev;
 
 static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
@@ -455,6 +466,7 @@ static void pcifront_thread(void *p)
     printk("PCI devices:\n");
     pcifront_scan(pci_dev, print_pcidev);
 }
+#endif
 
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
@@ -462,11 +474,21 @@ __attribute__((weak)) int app_main(start_info_t *si)
     printk("Dummy main: start_info=%p\n", si);
     create_thread("xenbus_tester", xenbus_tester, si);
     create_thread("periodic_thread", periodic_thread, si);
+#ifdef CONFIG_NETFRONT
     create_thread("netfront", netfront_thread, si);
+#endif
+#ifdef CONFIG_BLKFRONT
     create_thread("blkfront", blkfront_thread, si);
+#endif
+#ifdef CONFIG_FBFRONT
     create_thread("fbfront", fbfront_thread, si);
+#endif
+#ifdef CONFIG_KBDFRONT
     create_thread("kbdfront", kbdfront_thread, si);
+#endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_thread, si);
+#endif
     return 0;
 }
 
@@ -522,8 +544,10 @@ void start_kernel(start_info_t *si)
     /* Init scheduler. */
     init_sched();
  
+#ifdef CONFIG_XENBUS
     /* Init XenBus */
     init_xenbus();
+#endif
 
     /* Call (possibly overridden) app_main() */
     app_main(&start_info);
@@ -534,20 +558,30 @@ void start_kernel(start_info_t *si)
 
 void stop_kernel(void)
 {
+#ifdef CONFIG_NETFRONT
     if (net_dev)
         shutdown_netfront(net_dev);
+#endif
 
+#ifdef CONFIG_BLKFRONT
     if (blk_dev)
         shutdown_blkfront(blk_dev);
+#endif
 
+#ifdef CONFIG_FBFRONT
     if (fb_dev)
         shutdown_fbfront(fb_dev);
+#endif
 
+#ifdef CONFIG_KBDFRONT
     if (kbd_dev)
         shutdown_kbdfront(kbd_dev);
+#endif
 
+#ifdef CONFIG_PCIFRONT
     if (pci_dev)
         shutdown_pcifront(pci_dev);
+#endif
 
     /* TODO: fs import */
 
@@ -560,8 +594,10 @@ void stop_kernel(void)
     fini_console(NULL);
     /* TODO: record new ring mfn & event in start_info */
 
+#ifdef CONFIG_XENBUS
     /* Reset XenBus */
     fini_xenbus();
+#endif
 
     /* Reset timers */
     fini_time();
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index b7b3aff..14e7780 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -241,6 +241,7 @@ int read(int fd, void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_read(files[fd].socket.fd, buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP: {
 	    ssize_t ret;
 	    ret = netfront_receive(files[fd].tap.dev, buf, nbytes);
@@ -250,6 +251,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret;
 	}
+#endif
+#ifdef CONFIG_KBDFRONT
         case FTYPE_KBD: {
             int ret, n;
             n = nbytes / sizeof(union xenkbd_in_event);
@@ -260,6 +263,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenkbd_in_event);
         }
+#endif
+#ifdef CONFIG_FBFRONT
         case FTYPE_FB: {
             int ret, n;
             n = nbytes / sizeof(union xenfb_in_event);
@@ -270,6 +275,7 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenfb_in_event);
         }
+#endif
 	default:
 	    break;
     }
@@ -297,9 +303,11 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_write(files[fd].socket.fd, (void*) buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
+#endif
 	default:
 	    break;
     }
@@ -326,9 +334,11 @@ int close(int fd)
         default:
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
             xs_daemon_close((void*)(intptr_t) fd);
             return 0;
+#endif
 #ifdef HAVE_LWIP
 	case FTYPE_SOCKET: {
 	    int res = lwip_close(files[fd].socket.fd);
@@ -345,22 +355,30 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_BLKFRONT
 	case FTYPE_BLK:
             shutdown_blkfront(files[fd].blk.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_FBFRONT
 	case FTYPE_FB:
             shutdown_fbfront(files[fd].fb.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
         case FTYPE_SAVEFILE:
         case FTYPE_CONSOLE:
             fini_console(files[fd].cons.dev);
@@ -611,6 +629,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
                 n++;
 	    FD_CLR(i, exceptfds);
 	    break;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
 	    if (FD_ISSET(i, readfds)) {
                 if (files[i].xenbus.events)
@@ -621,6 +640,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
 	    FD_CLR(i, writefds);
 	    FD_CLR(i, exceptfds);
 	    break;
+#endif
 	case FTYPE_EVTCHN:
 	case FTYPE_TAP:
 	case FTYPE_BLK:
@@ -727,11 +747,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
+#ifdef CONFIG_NETFRONT
     add_waiter(w1, netfront_queue);
+#endif
     add_waiter(w2, event_queue);
+#ifdef CONFIG_BLKFRONT
     add_waiter(w3, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     add_waiter(w4, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     add_waiter(w5, kbdfront_queue);
+#endif
     add_waiter(w6, console_queue);
 
     if (readfds)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index aeda548..73eb6fb 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -63,10 +63,12 @@ static void call_main(void *p)
 #ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #endif
-#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK) && defined(CONFIG_NETFRONT)
     start_networking();
 #endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
@@ -169,7 +171,7 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
-#ifdef HAVE_LWIP
+#if defined(HAVE_LWIP) && defined(CONFIG_NETFRONT)
     stop_networking();
 #endif
     stop_kernel();
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNU-0001bO-0Z; Fri, 20 Jan 2012 20:48:04 +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 1RoLNQ-0001Vy-GQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327092473!4351056!1
X-Originating-IP: [63.239.65.39]
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 22856 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlq1P023873
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKu021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:37 -0500
Message-Id: <1327092461-2701-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 17/21] stubdom: enable xenstored 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>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/apps/xenstore.mk |    8 ++++++++
 stubdom/Makefile                |   29 ++++++++++++++++++++++++++---
 2 files changed, 34 insertions(+), 3 deletions(-)
 create mode 100644 extras/mini-os/apps/xenstore.mk

diff --git a/extras/mini-os/apps/xenstore.mk b/extras/mini-os/apps/xenstore.mk
new file mode 100644
index 0000000..26ff9a6
--- /dev/null
+++ b/extras/mini-os/apps/xenstore.mk
@@ -0,0 +1,8 @@
+CONFIG_BLKFRONT=n
+CONFIG_NETFRONT=n
+CONFIG_FBFRONT=n
+CONFIG_KBDFRONT=n
+CONFIG_XENBUS=n
+
+lwip=n
+DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS))
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 7989f31..0718e50 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=grub $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=xenstore $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20:48:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLNS-0001ZV-C2; Fri, 20 Jan 2012 20:48:02 +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 1RoLNQ-0001W0-CG
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327092473!7971069!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 11927 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-15.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023874
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKv021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:38 -0500
Message-Id: <1327092461-2701-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/21] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   11 +++++++++++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 66ca555..aad0298 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1775,6 +1775,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1788,6 +1789,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1847,6 +1849,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 435f76a..6a0dbc2 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -602,6 +602,17 @@ void restore_existing_connections(void)
 #ifdef __MINIOS__
 static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNY-0001i9-BC; Fri, 20 Jan 2012 20:48:08 +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 1RoLNS-0001WM-0j
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327092474!10048949!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 20893 invoked from network); 20 Jan 2012 20:47:54 -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;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023860; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKk021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:27 -0500
Message-Id: <1327092461-2701-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 07/21] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  164 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 216 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..1f139db 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    DECLARE_HYPERCALL;
+    gnttab_setup_table_t setup_table;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+    unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+    if (gmfnp == NULL)
+        return -1;
+
+    setup_table.dom = domid;
+    setup_table.nr_frames = 1;
+    set_xen_guest_handle(setup_table.frame_list, gmfnp);
+    setup_table.status = 0;
+
+    hypercall.op = __HYPERVISOR_grant_table_op;
+    hypercall.arg[0] = GNTTABOP_setup_table;
+    hypercall.arg[1] = (unsigned long) &setup_table;
+    hypercall.arg[2] = 1;
+
+    rc = do_xen_hypercall(xch, &hypercall);
+    gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup_table.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup_table.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0, /* TODO: what's this? */
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+    .domid = domid,
+    .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..8bee684 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..3bd5549 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3828c62..28646e0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -224,7 +224,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -250,6 +252,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -263,7 +269,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -296,6 +303,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -349,7 +358,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -387,7 +398,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNV-0001dt-VZ; Fri, 20 Jan 2012 20:48:05 +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 1RoLNR-0001W8-8o
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327092474!4351057!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 22880 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:47: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
	q0KKlqwW007491; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKq021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:33 -0500
Message-Id: <1327092461-2701-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 13/21] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_domain.c |   52 ++++++++++++++++++++++++++++++++----
 1 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..661d955 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
 	return len;
 }
 
+static void *map_interface(domid_t domid, unsigned long mfn)
+{
+	if (*xcg_handle >= 0) {
+		/* this is the preferred method */
+		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	} else {
+		return xc_map_foreign_range(*xc_handle, domid,
+			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+	}
+}
+
+static void unmap_interface(void *interface)
+{
+	if (*xcg_handle >= 0)
+		xc_gnttab_munmap(*xcg_handle, interface, 1);
+	else
+		munmap(interface, getpagesize());
+}
+
 static int destroy_domain(void *_domain)
 {
 	struct domain *domain = _domain;
@@ -174,8 +196,12 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		if (domain->domid == 0)
+			munmap(domain->interface, getpagesize());
+		else
+			unmap_interface(domain->interface);
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +370,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		interface = map_interface(domid, mfn);
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +378,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			unmap_interface(interface);
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +576,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +633,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNR-0001Ya-Aa; Fri, 20 Jan 2012 20:48:01 +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 1RoLNP-0001Vr-Oc
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327092472!11716247!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 24451 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlqwW007484
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKi021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:25 -0500
Message-Id: <1327092461-2701-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/21] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to preserve v2-only features such as sub-page grants will
produce a warning and invalidate the resulting v1 grant entry.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
 xen/include/public/grant_table.h |    7 +++++
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 34a49db..dd9f904 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2110,6 +2110,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2130,7 +2131,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2155,15 +2156,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1)
+    {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    }
+    else if (gt->gt_version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)
+            {
+                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
+                       d->domain_id, reserved_entries[i].flags, i);
+                reserved_entries[i].flags = GTF_invalid;
+            }
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1)
     {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    }
+    else if (gt->gt_version != 0 && op.version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..5604638 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,13 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* The first few grant table entries will be preserved across grant table
+ * version changes and may be pre-populated at domain creation by tools.
+ */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNX-0001fr-4K; Fri, 20 Jan 2012 20:48:07 +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 1RoLNR-0001W9-Ce
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327092474!8639992!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 20799 invoked from network); 20 Jan 2012 20:47:54 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023870; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKt021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:36 -0500
Message-Id: <1327092461-2701-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 16/21] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/Makefile                |    9 +++++-
 tools/xenstore/tdb.c                   |    6 ++--
 tools/xenstore/utils.h                 |    2 +
 tools/xenstore/xenstored_core.c        |   47 ++++++++++++++++++++++++++++++-
 tools/xenstore/xenstored_domain.c      |   11 +++++++
 tools/xenstore/xenstored_transaction.c |    2 +
 6 files changed, 71 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..3a061d6 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1 -DNO_LOCAL_XENBUS=1 -DNO_SYSLOG=1 -DNO_REOPEN_LOG=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 3ecd3fc..cb66ea7 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 
 		/* Iterate through chain */
 		while( tlock->off) {
-			tdb_off current;
+			tdb_off mycurrent;
 			if (rec_read(tdb, tlock->off, rec) == -1)
 				goto fail;
 
@@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 			}
 
 			/* Try to clean dead ones from old traverses */
-			current = tlock->off;
+			mycurrent = tlock->off;
 			tlock->off = rec->next;
 			if (!tdb->read_only && 
-			    do_delete(tdb, current, rec) != 0)
+			    do_delete(tdb, mycurrent, rec) != 0)
 				goto fail;
 		}
 		tdb_unlock(tdb, tlock->hash, F_WRLCK);
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 631bfe4..66ca555 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -32,7 +32,9 @@
 #include <stdio.h>
 #include <stdarg.h>
 #include <stdlib.h>
+#ifndef NO_SYSLOG
 #include <syslog.h>
+#endif
 #include <string.h>
 #include <errno.h>
 #include <dirent.h>
@@ -61,13 +63,24 @@ LIST_HEAD(connections);
 static int tracefd = -1;
 static bool recovery = true;
 static bool remove_local = true;
+#ifndef NO_REOPEN_LOG
 static int reopen_log_pipe[2];
+#endif
 static char *tracefile = NULL;
 static TDB_CONTEXT *tdb_ctx;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
 
+#ifdef __MINIOS__
+#define lockf(...) (-ENOSYS)
+#endif
+
+#ifdef NO_SYSLOG
+#define openlog(...) ((void) 0)
+#define syslog(...)  ((void) 0)
+#endif
+
 #define log(...)							\
 	do {								\
 		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
@@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
+#ifndef __MINIOS__
 	if (rename(newname, xs_daemon_tdb()) != 0)
 		return false;
+#endif
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -195,6 +210,11 @@ void trace_destroy(const void *data, const char *type)
 	trace("DESTROY %s %p\n", type, data);
 }
 
+#ifdef NO_REOPEN_LOG
+static void reopen_log(void)
+{
+}
+#else
 /**
  * Signal handler for SIGHUP, which requests that the trace log is reopened
  * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
@@ -222,7 +242,7 @@ static void reopen_log(void)
 			trace("\n***\n");
 	}
 }
-
+#endif
 
 static bool write_messages(struct connection *conn)
 {
@@ -326,7 +346,9 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
 #endif
+#ifndef NO_REOPEN_LOG
 	set_fd(reopen_log_pipe[0], inset, &max);
+#endif
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1415,7 +1437,11 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
+#ifdef __MINIOS__
+#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
+#else
 #define TDB_FLAGS 0
+#endif
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1440,7 +1466,11 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
+#ifdef __MINIOS__
+	tdb_ctx = NULL;
+#else
 	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+#endif
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1666,6 +1696,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifndef __MINIOS__
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1712,7 +1743,7 @@ static void daemonize(void)
 	/* Discard our parent's old-fashioned umask prejudices. */
 	umask(0);
 }
-
+#endif
 
 static void usage(void)
 {
@@ -1823,6 +1854,7 @@ int main(int argc, char *argv[])
 
 	reopen_log();
 
+#ifndef __MINIOS__
 	/* make sure xenstored directory exists */
 	if (mkdir(xs_daemon_rundir(), 0755)) {
 		if (errno != EEXIST) {
@@ -1844,6 +1876,7 @@ int main(int argc, char *argv[])
 	}
 	if (pidfile)
 		write_pidfile(pidfile);
+#endif
 
 	/* Talloc leak reports go to stderr, which is closed if we fork. */
 	if (!dofork)
@@ -1890,9 +1923,11 @@ int main(int argc, char *argv[])
 		barf_perror("Could not listen on sockets");
 #endif
 
+#ifndef NO_REOPEN_LOG
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1909,6 +1944,7 @@ int main(int argc, char *argv[])
 		fflush(stdout);
 	}
 
+#ifndef __MINIOS__
 	/* redirect to /dev/null now we're ready to accept connections */
 	if (dofork) {
 		int devnull = open("/dev/null", O_RDWR);
@@ -1920,8 +1956,11 @@ int main(int argc, char *argv[])
 		close(devnull);
 		xprintf = trace;
 	}
+#endif
 
+#ifndef NO_REOPEN_LOG
 	signal(SIGHUP, trigger_reopen_log);
+#endif
 
 	if (xce_handle != NULL)
 		evtchn_fd = xc_evtchn_fd(xce_handle);
@@ -1929,8 +1968,10 @@ int main(int argc, char *argv[])
 	/* Get ready to listen to the tools. */
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1942,12 +1983,14 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
+#ifndef NO_REOPEN_LOG
 		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
 			reopen_log();
 		}
+#endif
 
 #ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 661d955..435f76a 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		unmap_interface(domain->interface);
+#else
 		if (domain->domid == 0)
 			munmap(domain->interface, getpagesize());
 		else
 			unmap_interface(domain->interface);
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
@@ -595,6 +599,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static int dom0_init(void)
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -618,6 +628,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
index 380c691..c59acfb 100644
--- a/tools/xenstore/xenstored_transaction.c
+++ b/tools/xenstore/xenstored_transaction.c
@@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
 	trace_destroy(trans, "transaction");
 	if (trans->tdb)
 		tdb_close(trans->tdb);
+#ifndef __MINIOS__
 	unlink(trans->tdb_name);
+#endif
 	return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNO-0001Wk-2B; Fri, 20 Jan 2012 20:47:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RoLNM-0001WF-E1
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:47:56 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327092446!56597077!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 27875 invoked from network); 20 Jan 2012 20:47:27 -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;
	20 Jan 2012 20:47:27 -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
	q0KKlq1P023867; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKr021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:34 -0500
Message-Id: <1327092461-2701-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 14/21] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

option for compiling xenstored without unix sockets to support running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c |   22 +++++++++++++++++++++-
 tools/xenstore/xs.c             |    2 ++
 tools/xenstore/xs_lib.c         |    4 ++++
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..631bfe4 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
+#ifndef NO_SOCKETS
 	set_fd(sock,               inset, &max);
 	set_fd(ro_sock,            inset, &max);
+#endif
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -343,12 +347,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
+#ifndef NO_SOCKETS
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
 	close(*fd);
 	return 0;
 }
+#endif
 
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
@@ -1352,6 +1358,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifndef NO_SOCKETS
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1406,6 +1413,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1753,7 +1761,11 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
+#ifdef NO_SOCKETS
+	int minus_one = -1;
+#else
 	struct sockaddr_un addr;
+#endif
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,6 +1849,9 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
+#ifdef NO_SOCKETS
+	sock = ro_sock = &minus_one;
+#else
 	/* Create sockets for them to listen to. */
 	sock = talloc(talloc_autofree_context(), int);
 	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
@@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
 		barf_perror("Could not create socket");
 	talloc_set_destructor(sock, destroy_fd);
 	talloc_set_destructor(ro_sock, destroy_fd);
+#endif
 
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
+#ifndef NO_SOCKETS
 	/* FIXME: Be more sophisticated, don't mug running daemon. */
 	unlink(xs_daemon_socket());
 	unlink(xs_daemon_socket_ro());
@@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
 	if (listen(*sock, 1) != 0
 	    || listen(*ro_sock, 1) != 0)
 		barf_perror("Could not listen on sockets");
+#endif
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
@@ -1931,11 +1949,13 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
+#ifndef NO_SOCKETS
 		if (FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
 		if (FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
+#endif
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
 			handle_event();
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index 0a01675..60f2cee 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
 {
 	struct xs_handle *xsh = NULL;
 
+#ifndef NO_SOCKETS
 	if (flags & XS_OPEN_READONLY)
 		xsh = get_handle(xs_daemon_socket_ro());
 	else
 		xsh = get_handle(xs_daemon_socket());
+#endif
 
 	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
 		xsh = get_handle(xs_domain_dev());
diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
index 03a9ee4..af3db6b 100644
--- a/tools/xenstore/xs_lib.c
+++ b/tools/xenstore/xs_lib.c
@@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
 	return (s ? s : "/var/run/xenstored");
 }
 
+#ifndef NO_SOCKETS
 static const char *xs_daemon_path(void)
 {
 	static char buf[PATH_MAX];
@@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_daemon_tdb(void)
 {
@@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
 	return buf;
 }
 
+#ifndef NO_SOCKETS
 const char *xs_daemon_socket(void)
 {
 	return xs_daemon_path();
@@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
 		return NULL;
 	return buf;
 }
+#endif
 
 const char *xs_domain_dev(void)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNV-0001cq-6L; Fri, 20 Jan 2012 20:48:05 +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 1RoLNQ-0001W2-JS
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:01 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327092473!9992337!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 1400 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-174.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlqwW007490
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKo021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:31 -0500
Message-Id: <1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 11/21] mini-os: make frontends and xenbus
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds compile-time logic to disable certain frontends in mini-os:
 - pcifront is disabled by default, enabled for ioemu
 - blkfront, netfront, fbfront, and kbdfront are enabled by default
 - xenbus is required for any frontend, and is enabled by default

If all frontends and xenbus are disabled, mini-os will run without
needing to communicate with xenstore, making it suitable to run the
xenstore daemon.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile               |    5 +++-
 extras/mini-os/apps/common.mk         |   11 +++++++++
 extras/mini-os/apps/ioemu.mk          |    1 +
 extras/mini-os/console/xencons_ring.c |   15 ++++++++++--
 extras/mini-os/files.mk               |   12 +++++-----
 extras/mini-os/include/lib.h          |    2 +
 extras/mini-os/kernel.c               |   40 +++++++++++++++++++++++++++++++-
 extras/mini-os/lib/sys.c              |   28 +++++++++++++++++++++++
 extras/mini-os/main.c                 |    6 +++-
 9 files changed, 106 insertions(+), 14 deletions(-)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index af7d0d4..7419211 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -70,7 +70,10 @@ ifeq ($(lwip),y)
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
 LWO	:= $(patsubst %.c,%.o,$(LWC))
-LWO	+= $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
+LWO	+= $(OBJ_DIR)/lwip-arch.o
+ifeq ($(CONFIG_NETFRONT),y)
+LWO += $(OBJ_DIR)/lwip-net.o
+endif
 
 $(OBJ_DIR)/lwip.a: $(LWO)
 	$(RM) $@
diff --git a/extras/mini-os/apps/common.mk b/extras/mini-os/apps/common.mk
index 12b686d..1fd4c9f 100644
--- a/extras/mini-os/apps/common.mk
+++ b/extras/mini-os/apps/common.mk
@@ -1,11 +1,22 @@
 # Defaults
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
+CONFIG_BLKFRONT ?= y
+CONFIG_NETFRONT ?= y
+CONFIG_FBFRONT ?= y
+CONFIG_KBDFRONT ?= y
+CONFIG_XENBUS ?= y
 
 # Export items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
+flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
+flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
+flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
+flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 
 DEF_CFLAGS += $(flags-y)
 
diff --git a/extras/mini-os/apps/ioemu.mk b/extras/mini-os/apps/ioemu.mk
index 7ea1d2f..e3a96da 100644
--- a/extras/mini-os/apps/ioemu.mk
+++ b/extras/mini-os/apps/ioemu.mk
@@ -1 +1,2 @@
 CONFIG_QEMU_XS_ARGS=y
+CONFIG_PCIFRONT=y
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index af0afed..c3eba35 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -189,6 +189,7 @@ struct consfront_dev *xencons_ring_init(void)
 
 void free_consfront(struct consfront_dev *dev)
 {
+#ifdef CONFIG_XENBUS
     char* err = NULL;
     XenbusState state;
 
@@ -217,6 +218,7 @@ void free_consfront(struct consfront_dev *dev)
 close:
     if (err) free(err);
     xenbus_unwatch_path_token(XBT_NIL, path, path);
+#endif
 
     mask_evtchn(dev->evtchn);
     unbind_evtchn(dev->evtchn);
@@ -231,16 +233,18 @@ close:
 
 struct consfront_dev *init_consfront(char *_nodename)
 {
+    struct consfront_dev *dev;
+    char nodename[256];
+    static int consfrontends = 3;
+#ifdef CONFIG_XENBUS
     xenbus_transaction_t xbt;
     char* err;
     char* message=NULL;
     int retry=0;
     char* msg = NULL;
-    char nodename[256];
     char path[256];
-    static int consfrontends = 3;
-    struct consfront_dev *dev;
     int res;
+#endif
 
     if (!_nodename)
         snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
@@ -257,6 +261,7 @@ struct consfront_dev *init_consfront(char *_nodename)
     dev->fd = -1;
 #endif
 
+#ifdef CONFIG_XENBUS
     snprintf(path, sizeof(path), "%s/backend-id", nodename);
     if ((res = xenbus_read_integer(path)) < 0) 
         return NULL;
@@ -351,17 +356,21 @@ done:
             goto error;
         }
     }
+#endif
+
     unmask_evtchn(dev->evtchn);
 
     printk("**************************\n");
 
     return dev;
 
+#ifdef CONFIG_XENBUS
 error:
     free(msg);
     free(err);
     free_consfront(dev);
     return NULL;
+#endif
 }
 
 void xencons_resume(void)
diff --git a/extras/mini-os/files.mk b/extras/mini-os/files.mk
index 5c1c6ef..be37a8b 100644
--- a/extras/mini-os/files.mk
+++ b/extras/mini-os/files.mk
@@ -1,7 +1,7 @@
-src-y += blkfront.c
+src-$(CONFIG_BLKFRONT) += blkfront.c
 src-y += daytime.c
 src-y += events.c
-src-y += fbfront.c
+src-$(CONFIG_FBFRONT) += fbfront.c
 src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
@@ -9,8 +9,8 @@ src-y += kernel.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
-src-y += netfront.c
-src-y += pcifront.c
+src-$(CONFIG_NETFRONT) += netfront.c
+src-$(CONFIG_PCIFRONT) += pcifront.c
 src-y += sched.c
 
 src-y += lib/ctype.c
@@ -20,9 +20,9 @@ src-y += lib/stack_chk_fail.c
 src-y += lib/string.c
 src-y += lib/sys.c
 src-y += lib/xmalloc.c
-src-y += lib/xs.c
+src-$(CONFIG_XENBUS) += lib/xs.c
 
-src-y += xenbus/xenbus.c
+src-$(CONFIG_XENBUS) += xenbus/xenbus.c
 
 src-y += console/console.c
 src-y += console/xencons_ring.c
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 12070c3..9c69440 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -182,11 +182,13 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
              * FD.  */
             xenbus_event_queue events;
         } xenbus;
+#endif
     };
     int read;	/* maybe available for read */
 } files[];
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index 2875bf1..9e490d5 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -46,8 +46,6 @@
 #include <xen/features.h>
 #include <xen/version.h>
 
-static struct netfront_dev *net_dev;
-
 uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
 
 void setup_xen_features(void)
@@ -86,11 +84,16 @@ static void periodic_thread(void *p)
     }
 }
 
+#ifdef CONFIG_NETFRONT
+static struct netfront_dev *net_dev;
+
 static void netfront_thread(void *p)
 {
     net_dev = init_netfront(NULL, NULL, NULL, NULL);
 }
+#endif
 
+#ifdef CONFIG_BLKFRONT
 static struct blkfront_dev *blk_dev;
 static struct blkfront_info blk_info;
 static uint64_t blk_size_read;
@@ -255,6 +258,9 @@ static void blkfront_thread(void *p)
 #endif
     }
 }
+#endif
+
+#ifdef CONFIG_FBFRONT
 
 #define WIDTH 800
 #define HEIGHT 600
@@ -347,6 +353,9 @@ static void refresh_cursor(int new_x, int new_y)
     fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
     fbfront_update(fb_dev, new_x, new_y, 9, 9);
 }
+#endif
+
+#ifdef CONFIG_KBDFRONT
 
 static struct kbdfront_dev *kbd_dev;
 static void kbdfront_thread(void *p)
@@ -431,7 +440,9 @@ static void kbdfront_thread(void *p)
             schedule();
     }
 }
+#endif
 
+#ifdef CONFIG_PCIFRONT
 static struct pcifront_dev *pci_dev;
 
 static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
@@ -455,6 +466,7 @@ static void pcifront_thread(void *p)
     printk("PCI devices:\n");
     pcifront_scan(pci_dev, print_pcidev);
 }
+#endif
 
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
@@ -462,11 +474,21 @@ __attribute__((weak)) int app_main(start_info_t *si)
     printk("Dummy main: start_info=%p\n", si);
     create_thread("xenbus_tester", xenbus_tester, si);
     create_thread("periodic_thread", periodic_thread, si);
+#ifdef CONFIG_NETFRONT
     create_thread("netfront", netfront_thread, si);
+#endif
+#ifdef CONFIG_BLKFRONT
     create_thread("blkfront", blkfront_thread, si);
+#endif
+#ifdef CONFIG_FBFRONT
     create_thread("fbfront", fbfront_thread, si);
+#endif
+#ifdef CONFIG_KBDFRONT
     create_thread("kbdfront", kbdfront_thread, si);
+#endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_thread, si);
+#endif
     return 0;
 }
 
@@ -522,8 +544,10 @@ void start_kernel(start_info_t *si)
     /* Init scheduler. */
     init_sched();
  
+#ifdef CONFIG_XENBUS
     /* Init XenBus */
     init_xenbus();
+#endif
 
     /* Call (possibly overridden) app_main() */
     app_main(&start_info);
@@ -534,20 +558,30 @@ void start_kernel(start_info_t *si)
 
 void stop_kernel(void)
 {
+#ifdef CONFIG_NETFRONT
     if (net_dev)
         shutdown_netfront(net_dev);
+#endif
 
+#ifdef CONFIG_BLKFRONT
     if (blk_dev)
         shutdown_blkfront(blk_dev);
+#endif
 
+#ifdef CONFIG_FBFRONT
     if (fb_dev)
         shutdown_fbfront(fb_dev);
+#endif
 
+#ifdef CONFIG_KBDFRONT
     if (kbd_dev)
         shutdown_kbdfront(kbd_dev);
+#endif
 
+#ifdef CONFIG_PCIFRONT
     if (pci_dev)
         shutdown_pcifront(pci_dev);
+#endif
 
     /* TODO: fs import */
 
@@ -560,8 +594,10 @@ void stop_kernel(void)
     fini_console(NULL);
     /* TODO: record new ring mfn & event in start_info */
 
+#ifdef CONFIG_XENBUS
     /* Reset XenBus */
     fini_xenbus();
+#endif
 
     /* Reset timers */
     fini_time();
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index b7b3aff..14e7780 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -241,6 +241,7 @@ int read(int fd, void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_read(files[fd].socket.fd, buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP: {
 	    ssize_t ret;
 	    ret = netfront_receive(files[fd].tap.dev, buf, nbytes);
@@ -250,6 +251,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret;
 	}
+#endif
+#ifdef CONFIG_KBDFRONT
         case FTYPE_KBD: {
             int ret, n;
             n = nbytes / sizeof(union xenkbd_in_event);
@@ -260,6 +263,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenkbd_in_event);
         }
+#endif
+#ifdef CONFIG_FBFRONT
         case FTYPE_FB: {
             int ret, n;
             n = nbytes / sizeof(union xenfb_in_event);
@@ -270,6 +275,7 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenfb_in_event);
         }
+#endif
 	default:
 	    break;
     }
@@ -297,9 +303,11 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_write(files[fd].socket.fd, (void*) buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
+#endif
 	default:
 	    break;
     }
@@ -326,9 +334,11 @@ int close(int fd)
         default:
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
             xs_daemon_close((void*)(intptr_t) fd);
             return 0;
+#endif
 #ifdef HAVE_LWIP
 	case FTYPE_SOCKET: {
 	    int res = lwip_close(files[fd].socket.fd);
@@ -345,22 +355,30 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_BLKFRONT
 	case FTYPE_BLK:
             shutdown_blkfront(files[fd].blk.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_FBFRONT
 	case FTYPE_FB:
             shutdown_fbfront(files[fd].fb.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
         case FTYPE_SAVEFILE:
         case FTYPE_CONSOLE:
             fini_console(files[fd].cons.dev);
@@ -611,6 +629,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
                 n++;
 	    FD_CLR(i, exceptfds);
 	    break;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
 	    if (FD_ISSET(i, readfds)) {
                 if (files[i].xenbus.events)
@@ -621,6 +640,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
 	    FD_CLR(i, writefds);
 	    FD_CLR(i, exceptfds);
 	    break;
+#endif
 	case FTYPE_EVTCHN:
 	case FTYPE_TAP:
 	case FTYPE_BLK:
@@ -727,11 +747,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
+#ifdef CONFIG_NETFRONT
     add_waiter(w1, netfront_queue);
+#endif
     add_waiter(w2, event_queue);
+#ifdef CONFIG_BLKFRONT
     add_waiter(w3, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     add_waiter(w4, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     add_waiter(w5, kbdfront_queue);
+#endif
     add_waiter(w6, console_queue);
 
     if (readfds)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index aeda548..73eb6fb 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -63,10 +63,12 @@ static void call_main(void *p)
 #ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #endif
-#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK) && defined(CONFIG_NETFRONT)
     start_networking();
 #endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
@@ -169,7 +171,7 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
-#ifdef HAVE_LWIP
+#if defined(HAVE_LWIP) && defined(CONFIG_NETFRONT)
     stop_networking();
 #endif
     stop_kernel();
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNU-0001bO-0Z; Fri, 20 Jan 2012 20:48:04 +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 1RoLNQ-0001Vy-GQ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327092473!4351056!1
X-Originating-IP: [63.239.65.39]
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 22856 invoked from network); 20 Jan 2012 20:47:53 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:47:53 -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
	q0KKlq1P023873
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKu021505; 
	Fri, 20 Jan 2012 15:47:52 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:37 -0500
Message-Id: <1327092461-2701-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 17/21] stubdom: enable xenstored 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>
MIME-Version: 1.0
Content-Type: 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>
---
 extras/mini-os/apps/xenstore.mk |    8 ++++++++
 stubdom/Makefile                |   29 ++++++++++++++++++++++++++---
 2 files changed, 34 insertions(+), 3 deletions(-)
 create mode 100644 extras/mini-os/apps/xenstore.mk

diff --git a/extras/mini-os/apps/xenstore.mk b/extras/mini-os/apps/xenstore.mk
new file mode 100644
index 0000000..26ff9a6
--- /dev/null
+++ b/extras/mini-os/apps/xenstore.mk
@@ -0,0 +1,8 @@
+CONFIG_BLKFRONT=n
+CONFIG_NETFRONT=n
+CONFIG_FBFRONT=n
+CONFIG_KBDFRONT=n
+CONFIG_XENBUS=n
+
+lwip=n
+DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS))
diff --git a/stubdom/Makefile b/stubdom/Makefile
index 7989f31..0718e50 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=grub $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=xenstore $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNY-0001i9-BC; Fri, 20 Jan 2012 20:48:08 +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 1RoLNS-0001WM-0j
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327092474!10048949!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 20893 invoked from network); 20 Jan 2012 20:47:54 -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;
	20 Jan 2012 20:47:54 -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
	q0KKlq1P023860; Fri, 20 Jan 2012 20:47:52 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 q0KKlpKk021505; 
	Fri, 20 Jan 2012 15:47:51 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:27 -0500
Message-Id: <1327092461-2701-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 07/21] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  164 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 216 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..1f139db 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    DECLARE_HYPERCALL;
+    gnttab_setup_table_t setup_table;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+    unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+    if (gmfnp == NULL)
+        return -1;
+
+    setup_table.dom = domid;
+    setup_table.nr_frames = 1;
+    set_xen_guest_handle(setup_table.frame_list, gmfnp);
+    setup_table.status = 0;
+
+    hypercall.op = __HYPERVISOR_grant_table_op;
+    hypercall.arg[0] = GNTTABOP_setup_table;
+    hypercall.arg[1] = (unsigned long) &setup_table;
+    hypercall.arg[2] = 1;
+
+    rc = do_xen_hypercall(xch, &hypercall);
+    gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup_table.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup_table.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0, /* TODO: what's this? */
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+    .domid = domid,
+    .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..8bee684 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..3bd5549 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3828c62..28646e0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -224,7 +224,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -250,6 +252,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -263,7 +269,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -296,6 +303,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -349,7 +358,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -387,7 +398,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNh-0001zi-Ll; Fri, 20 Jan 2012 20:48:17 +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 1RoLNe-0001jm-9V
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327092487!11767125!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 31516 invoked from network); 20 Jan 2012 20:48:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:48:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0KKm6wW007547
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:48:06 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 q0KKm6Gt021668; 
	Fri, 20 Jan 2012 15:48:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:54 -0500
Message-Id: <1327092474-2743-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in stub
	domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds an ioctl to the /dev/xen/xenbus_backend device allowing the
xenbus backend to be started after the kernel has booted. This is
intended to allow dom0 to start another domain to run xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_comms.c       |    6 ++++
 drivers/xen/xenbus/xenbus_comms.h       |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   51 +++++++++++++++++++++++++++++++
 include/xen/grant_table.h               |    2 +
 include/xen/xenbus_dev.h                |    3 ++
 5 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 2eff7a6..52fe7ad 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -234,3 +234,9 @@ int xb_init_comms(void)
 
 	return 0;
 }
+
+void xb_deinit_comms(void)
+{
+	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
+	xenbus_irq = 0;
+}
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index 6e42800..c8abd3b 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -35,6 +35,7 @@
 
 int xs_init(void);
 int xb_init_comms(void);
+void xb_deinit_comms(void);
 
 /* Low level routines. */
 int xb_write(const void *data, unsigned len);
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index 3d3be78..be738c4 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -8,7 +8,11 @@
 
 #include <xen/xen.h>
 #include <xen/page.h>
+#include <xen/xenbus.h>
 #include <xen/xenbus_dev.h>
+#include <xen/grant_table.h>
+#include <xen/events.h>
+#include <asm/xen/hypervisor.h>
 
 #include "xenbus_comms.h"
 
@@ -22,6 +26,50 @@ static int xenbus_backend_open(struct inode *inode, struct file *filp)
 	return nonseekable_open(inode, filp);
 }
 
+static long xenbus_alloc(domid_t domid)
+{
+	struct evtchn_alloc_unbound arg;
+	int err = -EEXIST;
+
+	xs_suspend();
+
+	/* If xenstored_ready is nonzero, that means we have already talked to
+	 * xenstore and set up watches. These watches will be restored by
+	 * xs_resume, but that requires communication over the port established
+	 * below that is not visible to anyone until the ioctl returns.
+	 *
+	 * This can be resolved by splitting the ioctl into two parts
+	 * (postponing the resume until xenstored is active) but this is
+	 * unnecessarily complex for the intended use where xenstored is only
+	 * started once - so return -EEXIST if it's already running.
+	 */
+	if (xenstored_ready)
+		goto out_err;
+
+	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, domid,
+			virt_to_mfn(xen_store_interface), 0 /* writable */);
+
+	arg.dom = DOMID_SELF;
+	arg.remote_dom = domid;
+
+	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
+	if (err)
+		goto out_err;
+
+	if (xen_store_evtchn > 0)
+		xb_deinit_comms();
+
+	xen_store_evtchn = arg.port;
+
+	xs_resume();
+
+	return arg.port;
+
+ out_err:
+	xs_suspend_cancel();
+	return err;
+}
+
 static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
 {
 	if (!capable(CAP_SYS_ADMIN))
@@ -33,6 +81,9 @@ static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned l
 				return xen_store_evtchn;
 			return -ENODEV;
 
+		case IOCTL_XENBUS_BACKEND_SETUP:
+			return xenbus_alloc(data);
+
 		default:
 			return -ENOTTY;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 15f8a00..11e27c3 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -46,6 +46,8 @@
 
 #include <xen/features.h>
 
+#define GNTTAB_RESERVED_XENSTORE 1
+
 /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
 #define NR_GRANT_FRAMES 4
 
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
index ac5f0fe..bbee8c6 100644
--- a/include/xen/xenbus_dev.h
+++ b/include/xen/xenbus_dev.h
@@ -38,4 +38,7 @@
 #define IOCTL_XENBUS_BACKEND_EVTCHN			\
 	_IOC(_IOC_NONE, 'B', 0, 0)
 
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
 #endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 20:48:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 20: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 1RoLNh-0001zi-Ll; Fri, 20 Jan 2012 20:48:17 +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 1RoLNe-0001jm-9V
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 20:48:14 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327092487!11767125!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 31516 invoked from network); 20 Jan 2012 20:48:07 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-182.messagelabs.com with SMTP;
	20 Jan 2012 20:48:07 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0KKm6wW007547
	for <xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 20:48:06 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 q0KKm6Gt021668; 
	Fri, 20 Jan 2012 15:48:06 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 20 Jan 2012 15:47:54 -0500
Message-Id: <1327092474-2743-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in stub
	domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds an ioctl to the /dev/xen/xenbus_backend device allowing the
xenbus backend to be started after the kernel has booted. This is
intended to allow dom0 to start another domain to run xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 drivers/xen/xenbus/xenbus_comms.c       |    6 ++++
 drivers/xen/xenbus/xenbus_comms.h       |    1 +
 drivers/xen/xenbus/xenbus_dev_backend.c |   51 +++++++++++++++++++++++++++++++
 include/xen/grant_table.h               |    2 +
 include/xen/xenbus_dev.h                |    3 ++
 5 files changed, 63 insertions(+), 0 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_comms.c b/drivers/xen/xenbus/xenbus_comms.c
index 2eff7a6..52fe7ad 100644
--- a/drivers/xen/xenbus/xenbus_comms.c
+++ b/drivers/xen/xenbus/xenbus_comms.c
@@ -234,3 +234,9 @@ int xb_init_comms(void)
 
 	return 0;
 }
+
+void xb_deinit_comms(void)
+{
+	unbind_from_irqhandler(xenbus_irq, &xb_waitq);
+	xenbus_irq = 0;
+}
diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h
index 6e42800..c8abd3b 100644
--- a/drivers/xen/xenbus/xenbus_comms.h
+++ b/drivers/xen/xenbus/xenbus_comms.h
@@ -35,6 +35,7 @@
 
 int xs_init(void);
 int xb_init_comms(void);
+void xb_deinit_comms(void);
 
 /* Low level routines. */
 int xb_write(const void *data, unsigned len);
diff --git a/drivers/xen/xenbus/xenbus_dev_backend.c b/drivers/xen/xenbus/xenbus_dev_backend.c
index 3d3be78..be738c4 100644
--- a/drivers/xen/xenbus/xenbus_dev_backend.c
+++ b/drivers/xen/xenbus/xenbus_dev_backend.c
@@ -8,7 +8,11 @@
 
 #include <xen/xen.h>
 #include <xen/page.h>
+#include <xen/xenbus.h>
 #include <xen/xenbus_dev.h>
+#include <xen/grant_table.h>
+#include <xen/events.h>
+#include <asm/xen/hypervisor.h>
 
 #include "xenbus_comms.h"
 
@@ -22,6 +26,50 @@ static int xenbus_backend_open(struct inode *inode, struct file *filp)
 	return nonseekable_open(inode, filp);
 }
 
+static long xenbus_alloc(domid_t domid)
+{
+	struct evtchn_alloc_unbound arg;
+	int err = -EEXIST;
+
+	xs_suspend();
+
+	/* If xenstored_ready is nonzero, that means we have already talked to
+	 * xenstore and set up watches. These watches will be restored by
+	 * xs_resume, but that requires communication over the port established
+	 * below that is not visible to anyone until the ioctl returns.
+	 *
+	 * This can be resolved by splitting the ioctl into two parts
+	 * (postponing the resume until xenstored is active) but this is
+	 * unnecessarily complex for the intended use where xenstored is only
+	 * started once - so return -EEXIST if it's already running.
+	 */
+	if (xenstored_ready)
+		goto out_err;
+
+	gnttab_grant_foreign_access_ref(GNTTAB_RESERVED_XENSTORE, domid,
+			virt_to_mfn(xen_store_interface), 0 /* writable */);
+
+	arg.dom = DOMID_SELF;
+	arg.remote_dom = domid;
+
+	err = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, &arg);
+	if (err)
+		goto out_err;
+
+	if (xen_store_evtchn > 0)
+		xb_deinit_comms();
+
+	xen_store_evtchn = arg.port;
+
+	xs_resume();
+
+	return arg.port;
+
+ out_err:
+	xs_suspend_cancel();
+	return err;
+}
+
 static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned long data)
 {
 	if (!capable(CAP_SYS_ADMIN))
@@ -33,6 +81,9 @@ static long xenbus_backend_ioctl(struct file *file, unsigned int cmd, unsigned l
 				return xen_store_evtchn;
 			return -ENODEV;
 
+		case IOCTL_XENBUS_BACKEND_SETUP:
+			return xenbus_alloc(data);
+
 		default:
 			return -ENOTTY;
 	}
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 15f8a00..11e27c3 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -46,6 +46,8 @@
 
 #include <xen/features.h>
 
+#define GNTTAB_RESERVED_XENSTORE 1
+
 /* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
 #define NR_GRANT_FRAMES 4
 
diff --git a/include/xen/xenbus_dev.h b/include/xen/xenbus_dev.h
index ac5f0fe..bbee8c6 100644
--- a/include/xen/xenbus_dev.h
+++ b/include/xen/xenbus_dev.h
@@ -38,4 +38,7 @@
 #define IOCTL_XENBUS_BACKEND_EVTCHN			\
 	_IOC(_IOC_NONE, 'B', 0, 0)
 
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
 #endif /* __LINUX_XEN_XENBUS_DEV_H__ */
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 21:18:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 21:18:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLqz-0005YM-8A; Fri, 20 Jan 2012 21:18:33 +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 1RoLqx-0005Y7-4j
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 21:18:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327094302!7973010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26773 invoked from network); 20 Jan 2012 21:18:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 21:18:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,545,1320624000"; d="scan'208";a="10185946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 21:18:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 21:18: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 1RoLqn-0001VH-6H;
	Fri, 20 Jan 2012 21:18:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoLqn-0008Ie-5b;
	Fri, 20 Jan 2012 21:18:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10925-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Jan 2012 21:18:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10925: 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 10925 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10925/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore       fail REGR. vs. 10913
 test-amd64-i386-xend-winxpsp3  8 guest-saverestore        fail REGR. vs. 10913
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10902
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10913
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10906
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore        fail REGR. vs. 10913
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-amd64-xl-winxpsp3  8 guest-saverestore         fail REGR. vs. 10913
 test-i386-i386-xl-winxpsp3    8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-xl-winxpsp3-vcpus1  8 guest-saverestore   fail REGR. vs. 10913

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-win          7 windows-install              fail   like 10913
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 10906

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

version targeted for testing:
 xen                  87854d3bed93
baseline version:
 xen                  2273ef2083d4

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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:   24529:87854d3bed93
tag:         tip
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Fri Jan 20 10:40:16 2012 +0000
    
    vpmu: separate architecture specific PMU initialisation
    
    This patch moves the architecture specific initialisation of the PMU
    into the archicture specific directory.
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24528:3d58058fc7a2
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:26:57 2012 +0000
    
    x86/hvm: Remove unnecessary packed attribute from hvm_hw_cpu_xsave struct.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24527:028230eb2359
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Fri Jan 20 10:20:32 2012 +0000
    
    iommu: Move IOMMU faults handling into softirq for AMD-Vi.
    
    Dealing with interrupts from AMD-Vi IOMMU(s) 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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24526:d600a3d7faee
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Jan 20 10:17:12 2012 +0000
    
    x86/hvm: Allow wake up of offline vcpu via nmi-ipi
    
    On a real machine a cpu disabled via hlt with interrupts disabled can
    be reactivated via a nmi ipi. Enable the hypervisor to do this for
    hvm, too.
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24525:a3f67482c321
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:13:55 2012 +0000
    
    xen: Simplify callers of boot_vcpu(). In VCPUOP_up, check
    is_initialised under the per-domain lock.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24524:2273ef2083d4
user:        Tim Deegan <tim@xen.org>
date:        Thu Jan 19 13:09:23 2012 +0000
    
    x86/mm: refine epte_present test
    
    The current test for a present ept entry checks for a permission bit
    to be set.
    
    While this is valid in contexts in which we want to know whether an entry
    will fault, it is not correct when it comes to testing whether an entry is
    valid. Specifically, in the ept_change_entry_type_page function which is
    used to set entries to the log dirty type.
    
    In combination with a p2m access type like n or n2rwx, log dirty will not be
    set for ept entries for which it should.
    
    Reported-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Jan 20 21:18:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 21:18:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoLqz-0005YM-8A; Fri, 20 Jan 2012 21:18:33 +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 1RoLqx-0005Y7-4j
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 21:18:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327094302!7973010!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTAzNg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26773 invoked from network); 20 Jan 2012 21:18:25 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	20 Jan 2012 21:18:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,545,1320624000"; d="scan'208";a="10185946"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	20 Jan 2012 21:18:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 20 Jan 2012 21:18: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 1RoLqn-0001VH-6H;
	Fri, 20 Jan 2012 21:18:21 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoLqn-0008Ie-5b;
	Fri, 20 Jan 2012 21:18:21 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-10925-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 20 Jan 2012 21:18:21 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10925: 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 10925 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10925/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-win7-amd64  8 guest-saverestore       fail REGR. vs. 10913
 test-amd64-i386-xend-winxpsp3  8 guest-saverestore        fail REGR. vs. 10913
 test-amd64-amd64-xl-win       8 guest-saverestore         fail REGR. vs. 10902
 test-i386-i386-xl-win         8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-xl-win-vcpus1  8 guest-saverestore        fail REGR. vs. 10913
 test-amd64-i386-win           8 guest-saverestore         fail REGR. vs. 10906
 test-amd64-i386-xl-win7-amd64  8 guest-saverestore        fail REGR. vs. 10913
 test-i386-i386-win            8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-amd64-xl-winxpsp3  8 guest-saverestore         fail REGR. vs. 10913
 test-i386-i386-xl-winxpsp3    8 guest-saverestore         fail REGR. vs. 10913
 test-amd64-i386-xl-winxpsp3-vcpus1  8 guest-saverestore   fail REGR. vs. 10913

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-win          7 windows-install              fail   like 10913
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 10906

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

version targeted for testing:
 xen                  87854d3bed93
baseline version:
 xen                  2273ef2083d4

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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:   24529:87854d3bed93
tag:         tip
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Fri Jan 20 10:40:16 2012 +0000
    
    vpmu: separate architecture specific PMU initialisation
    
    This patch moves the architecture specific initialisation of the PMU
    into the archicture specific directory.
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24528:3d58058fc7a2
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:26:57 2012 +0000
    
    x86/hvm: Remove unnecessary packed attribute from hvm_hw_cpu_xsave struct.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24527:028230eb2359
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Fri Jan 20 10:20:32 2012 +0000
    
    iommu: Move IOMMU faults handling into softirq for AMD-Vi.
    
    Dealing with interrupts from AMD-Vi IOMMU(s) 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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24526:d600a3d7faee
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Jan 20 10:17:12 2012 +0000
    
    x86/hvm: Allow wake up of offline vcpu via nmi-ipi
    
    On a real machine a cpu disabled via hlt with interrupts disabled can
    be reactivated via a nmi ipi. Enable the hypervisor to do this for
    hvm, too.
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24525:a3f67482c321
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:13:55 2012 +0000
    
    xen: Simplify callers of boot_vcpu(). In VCPUOP_up, check
    is_initialised under the per-domain lock.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24524:2273ef2083d4
user:        Tim Deegan <tim@xen.org>
date:        Thu Jan 19 13:09:23 2012 +0000
    
    x86/mm: refine epte_present test
    
    The current test for a present ept entry checks for a permission bit
    to be set.
    
    While this is valid in contexts in which we want to know whether an entry
    will fault, it is not correct when it comes to testing whether an entry is
    valid. Specifically, in the ept_change_entry_type_page function which is
    used to set entries to the log dirty type.
    
    In combination with a p2m access type like n or n2rwx, log dirty will not be
    set for ept entries for which it should.
    
    Reported-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Jan 20 22:25:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 22: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 1RoMtO-0006Uj-20; Fri, 20 Jan 2012 22:25:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RoMtM-0006Ue-CS
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 22:25:04 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327098296!8646095!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDkyNjc4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1500 invoked from network); 20 Jan 2012 22:24:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 22:24:58 -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
	q0KMOjre020406
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 22:24:50 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
	q0KMOiCV025325
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 22:24:45 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0KMOiLJ014236; Fri, 20 Jan 2012 16:24:44 -0600
Received: from [192.168.6.237] (/24.43.226.170)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 14:24:43 -0800
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<20120120122517.GB97313@ocelot.phlegethon.org>
	<4F196D53020000780006DEE9@nat28.tlf.novell.com>
In-Reply-To: <4F196D53020000780006DEE9@nat28.tlf.novell.com>
Mime-Version: 1.0 (1.0)
Message-Id: <EC789543-8D2E-4884-8C96-1DAA3DF4E584@oracle.com>
X-Mailer: iPhone Mail (9A405)
From: "Dan M @ Oracle" <dan.magenheimer@oracle.com>
Date: Fri, 20 Jan 2012 12:24:42 -1000
To: Jan Beulich <JBeulich@suse.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F19E9B4.000C,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
	platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm away for a few days. HVM works fine. Everything should be portable to ARM though it's never been tested afaik so may need a tweak or two. If someone wants to try it I'd be happy to help after I return

Sent from my iPhone

On Jan 20, 2012, at 2:34 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 20.01.12 at 13:25, Tim Deegan <tim@xen.org> wrote:
>> At 12:19 +0000 on 20 Jan (1327061942), Stefano Stabellini wrote:
>>> Why do we need this?
>>> I though that tmem compiled OK on ARM. Also I don't think there is any
>>> architectural limitation that would prevent tmem from working on ARM,
>>> right?
>> 
>> It may compile but it surely won't work. :)  Does tmem work at all for
>> non-PV guests?
> 
> Supposedly yes, otherwise it wouldn't be wired up in the HVM
> hypercall tables. Dan?
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 22:25:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 22: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 1RoMtO-0006Uj-20; Fri, 20 Jan 2012 22:25:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dan.magenheimer@oracle.com>) id 1RoMtM-0006Ue-CS
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 22:25:04 +0000
X-Env-Sender: dan.magenheimer@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327098296!8646095!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDkyNjc4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1500 invoked from network); 20 Jan 2012 22:24:58 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 20 Jan 2012 22:24:58 -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
	q0KMOjre020406
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 22:24:50 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
	q0KMOiCV025325
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 22:24:45 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0KMOiLJ014236; Fri, 20 Jan 2012 16:24:44 -0600
Received: from [192.168.6.237] (/24.43.226.170)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 14:24:43 -0800
References: <1327061025.30054.21.camel@zakaz.uk.xensource.com>
	<1327061198-29854-7-git-send-email-ian.campbell@citrix.com>
	<alpine.DEB.2.00.1201201217110.3196@kaball-desktop>
	<20120120122517.GB97313@ocelot.phlegethon.org>
	<4F196D53020000780006DEE9@nat28.tlf.novell.com>
In-Reply-To: <4F196D53020000780006DEE9@nat28.tlf.novell.com>
Mime-Version: 1.0 (1.0)
Message-Id: <EC789543-8D2E-4884-8C96-1DAA3DF4E584@oracle.com>
X-Mailer: iPhone Mail (9A405)
From: "Dan M @ Oracle" <dan.magenheimer@oracle.com>
Date: Fri, 20 Jan 2012 12:24:42 -1000
To: Jan Beulich <JBeulich@suse.com>
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F19E9B4.000C,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/12] xen: allow tmem to be disabled on
	platforms which do not support it (ARM)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I'm away for a few days. HVM works fine. Everything should be portable to ARM though it's never been tested afaik so may need a tweak or two. If someone wants to try it I'd be happy to help after I return

Sent from my iPhone

On Jan 20, 2012, at 2:34 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 20.01.12 at 13:25, Tim Deegan <tim@xen.org> wrote:
>> At 12:19 +0000 on 20 Jan (1327061942), Stefano Stabellini wrote:
>>> Why do we need this?
>>> I though that tmem compiled OK on ARM. Also I don't think there is any
>>> architectural limitation that would prevent tmem from working on ARM,
>>> right?
>> 
>> It may compile but it surely won't work. :)  Does tmem work at all for
>> non-PV guests?
> 
> Supposedly yes, otherwise it wouldn't be wired up in the HVM
> hypercall tables. Dan?
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 23:12:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 23:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoNcn-0007NX-3L; Fri, 20 Jan 2012 23:12:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <akpm@linux-foundation.org>) id 1RoNcl-0007NS-CO
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 23:11:59 +0000
X-Env-Sender: akpm@linux-foundation.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327101112!11950162!1
X-Originating-IP: [140.211.169.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11686 invoked from network); 20 Jan 2012 23:11:52 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12) by server-14.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 23:11:52 -0000
Received: from akpm.mtv.corp.google.com (216-239-45-4.google.com
	[216.239.45.4])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id 26677588;
	Fri, 20 Jan 2012 23:11:50 +0000 (UTC)
Date: Fri, 20 Jan 2012 15:11:49 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-Id: <20120120151149.04352aac.akpm@linux-foundation.org>
In-Reply-To: <20120120160938.GC3959@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
	<CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
	<20120120160938.GC3959@phenom.dumpdata.com>
X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012 11:09:38 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> > 
> > > Did you test this patch with a large amount of minors?
> > 
> > Sorry I didn't do runtime test.
> 
> Please do.

The poor guy probably doesn't know how to test it and surely it would
be quite a lot of work for him to do so.

Overall, it would be much more efficient if the tester of this code is
someone who is set up to easily apply the patch and test it.  ie: the
code maintainer(s).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 23:12:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 23:12:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoNcn-0007NX-3L; Fri, 20 Jan 2012 23:12:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <akpm@linux-foundation.org>) id 1RoNcl-0007NS-CO
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 23:11:59 +0000
X-Env-Sender: akpm@linux-foundation.org
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327101112!11950162!1
X-Originating-IP: [140.211.169.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11686 invoked from network); 20 Jan 2012 23:11:52 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12) by server-14.tower-21.messagelabs.com with SMTP;
	20 Jan 2012 23:11:52 -0000
Received: from akpm.mtv.corp.google.com (216-239-45-4.google.com
	[216.239.45.4])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id 26677588;
	Fri, 20 Jan 2012 23:11:50 +0000 (UTC)
Date: Fri, 20 Jan 2012 15:11:49 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-Id: <20120120151149.04352aac.akpm@linux-foundation.org>
In-Reply-To: <20120120160938.GC3959@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
	<CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
	<20120120160938.GC3959@phenom.dumpdata.com>
X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012 11:09:38 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> > 
> > > Did you test this patch with a large amount of minors?
> > 
> > Sorry I didn't do runtime test.
> 
> Please do.

The poor guy probably doesn't know how to test it and surely it would
be quite a lot of work for him to do so.

Overall, it would be much more efficient if the tester of this code is
someone who is set up to easily apply the patch and test it.  ie: the
code maintainer(s).


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 23:58:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 23:58:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoOKn-00082x-Fy; Fri, 20 Jan 2012 23:57:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RoOKm-00082s-DZ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 23:57:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327103804!61133248!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5NDEzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22019 invoked from network); 20 Jan 2012 23:56:45 -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; 20 Jan 2012 23:56:45 -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
	q0KNvJn7009144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 23:57:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0KNvIYl003204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 23:57:18 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
	q0KNvGI4029074; Fri, 20 Jan 2012 17:57:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 15:57:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AF22A40435; Fri, 20 Jan 2012 18:55:08 -0500 (EST)
Date: Fri, 20 Jan 2012 18:55:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Message-ID: <20120120235508.GA17260@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
	<CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
	<20120120160938.GC3959@phenom.dumpdata.com>
	<20120120151149.04352aac.akpm@linux-foundation.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120120151149.04352aac.akpm@linux-foundation.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.0A090207.4F19FF61.004E,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 20, 2012 at 03:11:49PM -0800, Andrew Morton wrote:
> On Fri, 20 Jan 2012 11:09:38 -0500
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > > 
> > > > Did you test this patch with a large amount of minors?
> > > 
> > > Sorry I didn't do runtime test.
> > 
> > Please do.
> 
> The poor guy probably doesn't know how to test it and surely it would
> be quite a lot of work for him to do so.
> 
> Overall, it would be much more efficient if the tester of this code is
> someone who is set up to easily apply the patch and test it.  ie: the
> code maintainer(s).

<grins>

This patch aside - Andrew how do you deal with a large amount of patches
and make sure they are tested? Is there a weekly Test Tuesday where you 
kick off your automated tests and dilligently look for any variations?

Or is it more of compile the kernel with X features and run it for a week
doing normal (and abnormal!) things to see if it falls over?

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 20 23:58:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 20 Jan 2012 23:58:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoOKn-00082x-Fy; Fri, 20 Jan 2012 23:57:29 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RoOKm-00082s-DZ
	for xen-devel@lists.xensource.com; Fri, 20 Jan 2012 23:57:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327103804!61133248!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5NDEzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22019 invoked from network); 20 Jan 2012 23:56:45 -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; 20 Jan 2012 23:56:45 -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
	q0KNvJn7009144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 20 Jan 2012 23:57:20 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0KNvIYl003204
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 20 Jan 2012 23:57:18 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
	q0KNvGI4029074; Fri, 20 Jan 2012 17:57:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 15:57:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AF22A40435; Fri, 20 Jan 2012 18:55:08 -0500 (EST)
Date: Fri, 20 Jan 2012 18:55:08 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Message-ID: <20120120235508.GA17260@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
	<CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
	<20120120160938.GC3959@phenom.dumpdata.com>
	<20120120151149.04352aac.akpm@linux-foundation.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120120151149.04352aac.akpm@linux-foundation.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.0A090207.4F19FF61.004E,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 20, 2012 at 03:11:49PM -0800, Andrew Morton wrote:
> On Fri, 20 Jan 2012 11:09:38 -0500
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > > 
> > > > Did you test this patch with a large amount of minors?
> > > 
> > > Sorry I didn't do runtime test.
> > 
> > Please do.
> 
> The poor guy probably doesn't know how to test it and surely it would
> be quite a lot of work for him to do so.
> 
> Overall, it would be much more efficient if the tester of this code is
> someone who is set up to easily apply the patch and test it.  ie: the
> code maintainer(s).

<grins>

This patch aside - Andrew how do you deal with a large amount of patches
and make sure they are tested? Is there a weekly Test Tuesday where you 
kick off your automated tests and dilligently look for any variations?

Or is it more of compile the kernel with X features and run it for a week
doing normal (and abnormal!) things to see if it falls over?

Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 00:01:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 00: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 1RoOOf-00009c-5Y; Sat, 21 Jan 2012 00:01:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe@perches.com>) id 1RoOOd-00009J-6Y
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 00:01:27 +0000
X-Env-Sender: joe@perches.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327104078!9224449!1
X-Originating-IP: [206.117.179.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14680 invoked from network); 21 Jan 2012 00:01:20 -0000
Received: from perches-mx.perches.com (HELO labridge.com) (206.117.179.246)
	by server-11.tower-21.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	21 Jan 2012 00:01:20 -0000
Received: from [173.60.85.8] (account joe@perches.com HELO
	joe-laptop.perches.com) by labridge.com (CommuniGate Pro SMTP 5.0.14)
	with ESMTPA id 18680224; Fri, 20 Jan 2012 16:01:17 -0800
From: Joe Perches <joe@perches.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>, Andy Whitcroft <apw@canonical.com>
Date: Fri, 20 Jan 2012 16:01:12 -0800
Message-Id: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
X-Mailer: git-send-email 1.7.8.111.gad25c.dirty
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH] include/checkpatch: Prefer __scanf to
	__attribute__((format(scanf, ...)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 equivalent to __printf, so prefer __scanf.

Signed-off-by: Joe Perches <joe@perches.com>
---
 include/linux/compiler-gcc.h |    3 ++-
 include/linux/kernel.h       |    8 ++++----
 include/xen/xenbus.h         |    4 ++--
 scripts/checkpatch.pl        |    6 ++++++
 4 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 3fd17c2..e5834aa 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -87,7 +87,8 @@
  */
 #define __pure				__attribute__((pure))
 #define __aligned(x)			__attribute__((aligned(x)))
-#define __printf(a,b)			__attribute__((format(printf,a,b)))
+#define __printf(a, b)			__attribute__((format(printf, a, b)))
+#define __scanf(a, b)			__attribute__((format(scanf, a, b)))
 #define  noinline			__attribute__((noinline))
 #define __attribute_const__		__attribute__((__const__))
 #define __maybe_unused			__attribute__((unused))
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e834342..30f21ec 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -315,10 +315,10 @@ extern __printf(2, 3)
 char *kasprintf(gfp_t gfp, const char *fmt, ...);
 extern char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
 
-extern int sscanf(const char *, const char *, ...)
-	__attribute__ ((format (scanf, 2, 3)));
-extern int vsscanf(const char *, const char *, va_list)
-	__attribute__ ((format (scanf, 2, 0)));
+extern __scanf(2, 3)
+int sscanf(const char *, const char *, ...);
+extern __scanf(2, 0)
+int vsscanf(const char *, const char *, va_list);
 
 extern int get_option(char **str, int *pint);
 extern char *get_options(const char *str, int nints, int *ints);
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index e8c599b..0a7515c 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -139,9 +139,9 @@ int xenbus_transaction_start(struct xenbus_transaction *t);
 int xenbus_transaction_end(struct xenbus_transaction t, int abort);
 
 /* Single read and scanf: returns -errno or num scanned if > 0. */
+__scanf(4, 5)
 int xenbus_scanf(struct xenbus_transaction t,
-		 const char *dir, const char *node, const char *fmt, ...)
-	__attribute__((format(scanf, 4, 5)));
+		 const char *dir, const char *node, const char *fmt, ...);
 
 /* Single printf and write: returns -errno or 0. */
 __printf(4, 5)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3bfcbe..2b52aeb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3117,6 +3117,12 @@ sub process {
 			     "__printf(string-index, first-to-check) is preferred over __attribute__((format(printf, string-index, first-to-check)))\n" . $herecurr);
 		}
 
+# Check for __attribute__ format(scanf, prefer __scanf
+		if ($line =~ /\b__attribute__\s*\(\s*\(\s*format\s*\(\s*scanf\b/) {
+			WARN("PREFER_SCANF",
+			     "__scanf(string-index, first-to-check) is preferred over __attribute__((format(scanf, string-index, first-to-check)))\n" . $herecurr);
+		}
+
 # check for sizeof(&)
 		if ($line =~ /\bsizeof\s*\(\s*\&/) {
 			WARN("SIZEOF_ADDRESS",
-- 
1.7.8.111.gad25c.dirty


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 00:01:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 00: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 1RoOOf-00009c-5Y; Sat, 21 Jan 2012 00:01:29 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe@perches.com>) id 1RoOOd-00009J-6Y
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 00:01:27 +0000
X-Env-Sender: joe@perches.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327104078!9224449!1
X-Originating-IP: [206.117.179.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14680 invoked from network); 21 Jan 2012 00:01:20 -0000
Received: from perches-mx.perches.com (HELO labridge.com) (206.117.179.246)
	by server-11.tower-21.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	21 Jan 2012 00:01:20 -0000
Received: from [173.60.85.8] (account joe@perches.com HELO
	joe-laptop.perches.com) by labridge.com (CommuniGate Pro SMTP 5.0.14)
	with ESMTPA id 18680224; Fri, 20 Jan 2012 16:01:17 -0800
From: Joe Perches <joe@perches.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>, Andy Whitcroft <apw@canonical.com>
Date: Fri, 20 Jan 2012 16:01:12 -0800
Message-Id: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
X-Mailer: git-send-email 1.7.8.111.gad25c.dirty
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: [Xen-devel] [PATCH] include/checkpatch: Prefer __scanf to
	__attribute__((format(scanf, ...)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 equivalent to __printf, so prefer __scanf.

Signed-off-by: Joe Perches <joe@perches.com>
---
 include/linux/compiler-gcc.h |    3 ++-
 include/linux/kernel.h       |    8 ++++----
 include/xen/xenbus.h         |    4 ++--
 scripts/checkpatch.pl        |    6 ++++++
 4 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 3fd17c2..e5834aa 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -87,7 +87,8 @@
  */
 #define __pure				__attribute__((pure))
 #define __aligned(x)			__attribute__((aligned(x)))
-#define __printf(a,b)			__attribute__((format(printf,a,b)))
+#define __printf(a, b)			__attribute__((format(printf, a, b)))
+#define __scanf(a, b)			__attribute__((format(scanf, a, b)))
 #define  noinline			__attribute__((noinline))
 #define __attribute_const__		__attribute__((__const__))
 #define __maybe_unused			__attribute__((unused))
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e834342..30f21ec 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -315,10 +315,10 @@ extern __printf(2, 3)
 char *kasprintf(gfp_t gfp, const char *fmt, ...);
 extern char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
 
-extern int sscanf(const char *, const char *, ...)
-	__attribute__ ((format (scanf, 2, 3)));
-extern int vsscanf(const char *, const char *, va_list)
-	__attribute__ ((format (scanf, 2, 0)));
+extern __scanf(2, 3)
+int sscanf(const char *, const char *, ...);
+extern __scanf(2, 0)
+int vsscanf(const char *, const char *, va_list);
 
 extern int get_option(char **str, int *pint);
 extern char *get_options(const char *str, int nints, int *ints);
diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
index e8c599b..0a7515c 100644
--- a/include/xen/xenbus.h
+++ b/include/xen/xenbus.h
@@ -139,9 +139,9 @@ int xenbus_transaction_start(struct xenbus_transaction *t);
 int xenbus_transaction_end(struct xenbus_transaction t, int abort);
 
 /* Single read and scanf: returns -errno or num scanned if > 0. */
+__scanf(4, 5)
 int xenbus_scanf(struct xenbus_transaction t,
-		 const char *dir, const char *node, const char *fmt, ...)
-	__attribute__((format(scanf, 4, 5)));
+		 const char *dir, const char *node, const char *fmt, ...);
 
 /* Single printf and write: returns -errno or 0. */
 __printf(4, 5)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3bfcbe..2b52aeb 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3117,6 +3117,12 @@ sub process {
 			     "__printf(string-index, first-to-check) is preferred over __attribute__((format(printf, string-index, first-to-check)))\n" . $herecurr);
 		}
 
+# Check for __attribute__ format(scanf, prefer __scanf
+		if ($line =~ /\b__attribute__\s*\(\s*\(\s*format\s*\(\s*scanf\b/) {
+			WARN("PREFER_SCANF",
+			     "__scanf(string-index, first-to-check) is preferred over __attribute__((format(scanf, string-index, first-to-check)))\n" . $herecurr);
+		}
+
 # check for sizeof(&)
 		if ($line =~ /\bsizeof\s*\(\s*\&/) {
 			WARN("SIZEOF_ADDRESS",
-- 
1.7.8.111.gad25c.dirty


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 00:04:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 00: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 1RoORN-0000K9-UQ; Sat, 21 Jan 2012 00:04:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <akpm@linux-foundation.org>) id 1RoORM-0000Jo-Ga
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 00:04:16 +0000
X-Env-Sender: akpm@linux-foundation.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327104249!11727708!1
X-Originating-IP: [140.211.169.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27006 invoked from network); 21 Jan 2012 00:04:10 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12) by server-15.tower-182.messagelabs.com with SMTP;
	21 Jan 2012 00:04:10 -0000
Received: from akpm.mtv.corp.google.com (216-239-45-4.google.com
	[216.239.45.4])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id A6CF258D;
	Sat, 21 Jan 2012 00:04:08 +0000 (UTC)
Date: Fri, 20 Jan 2012 16:04:08 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-Id: <20120120160408.9aa3b5fd.akpm@linux-foundation.org>
In-Reply-To: <20120120235508.GA17260@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
	<CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
	<20120120160938.GC3959@phenom.dumpdata.com>
	<20120120151149.04352aac.akpm@linux-foundation.org>
	<20120120235508.GA17260@phenom.dumpdata.com>
X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012 18:55:08 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Fri, Jan 20, 2012 at 03:11:49PM -0800, Andrew Morton wrote:
> > On Fri, 20 Jan 2012 11:09:38 -0500
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > > 
> > > > > Did you test this patch with a large amount of minors?
> > > > 
> > > > Sorry I didn't do runtime test.
> > > 
> > > Please do.
> > 
> > The poor guy probably doesn't know how to test it and surely it would
> > be quite a lot of work for him to do so.
> > 
> > Overall, it would be much more efficient if the tester of this code is
> > someone who is set up to easily apply the patch and test it.  ie: the
> > code maintainer(s).
> 
> <grins>
> 
> This patch aside - Andrew how do you deal with a large amount of patches
> and make sure they are tested?

Not very well :(

> Is there a weekly Test Tuesday where you 
> kick off your automated tests and dilligently look for any variations?
> Or is it more of compile the kernel with X features and run it for a week
> doing normal (and abnormal!) things to see if it falls over?

I build all the patches I have along with all of linux-next and boot
the thing, then use the resulting kernel for a few hours compilation
testing, then shove it all into linux-next where I naively hope that
someone else is testing things.

The coverage which is obtained this way is pretty poor.  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 00:04:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 00: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 1RoORN-0000K9-UQ; Sat, 21 Jan 2012 00:04:17 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <akpm@linux-foundation.org>) id 1RoORM-0000Jo-Ga
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 00:04:16 +0000
X-Env-Sender: akpm@linux-foundation.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327104249!11727708!1
X-Originating-IP: [140.211.169.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27006 invoked from network); 21 Jan 2012 00:04:10 -0000
Received: from mail.linuxfoundation.org (HELO mail.linuxfoundation.org)
	(140.211.169.12) by server-15.tower-182.messagelabs.com with SMTP;
	21 Jan 2012 00:04:10 -0000
Received: from akpm.mtv.corp.google.com (216-239-45-4.google.com
	[216.239.45.4])
	by mail.linuxfoundation.org (Postfix) with ESMTPSA id A6CF258D;
	Sat, 21 Jan 2012 00:04:08 +0000 (UTC)
Date: Fri, 20 Jan 2012 16:04:08 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-Id: <20120120160408.9aa3b5fd.akpm@linux-foundation.org>
In-Reply-To: <20120120235508.GA17260@phenom.dumpdata.com>
References: <1327072528-8479-1-git-send-email-akinobu.mita@gmail.com>
	<1327072528-8479-4-git-send-email-akinobu.mita@gmail.com>
	<20120120152819.GA3959@phenom.dumpdata.com>
	<CAC5umyi9vuOh9Bx_HoB8ieXcVjZsisKOG6mCEM2ZGL7zXCrVTQ@mail.gmail.com>
	<20120120160938.GC3959@phenom.dumpdata.com>
	<20120120151149.04352aac.akpm@linux-foundation.org>
	<20120120235508.GA17260@phenom.dumpdata.com>
X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Cc: Jeremy Fitzhardinge Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, virtualization@lists.linux-foundation.org,
	Akinobu Mita <akinobu.mita@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen-blkfront: use bitmap_set() and
	bitmap_clear()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012 18:55:08 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Fri, Jan 20, 2012 at 03:11:49PM -0800, Andrew Morton wrote:
> > On Fri, 20 Jan 2012 11:09:38 -0500
> > Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > > 
> > > > > Did you test this patch with a large amount of minors?
> > > > 
> > > > Sorry I didn't do runtime test.
> > > 
> > > Please do.
> > 
> > The poor guy probably doesn't know how to test it and surely it would
> > be quite a lot of work for him to do so.
> > 
> > Overall, it would be much more efficient if the tester of this code is
> > someone who is set up to easily apply the patch and test it.  ie: the
> > code maintainer(s).
> 
> <grins>
> 
> This patch aside - Andrew how do you deal with a large amount of patches
> and make sure they are tested?

Not very well :(

> Is there a weekly Test Tuesday where you 
> kick off your automated tests and dilligently look for any variations?
> Or is it more of compile the kernel with X features and run it for a week
> doing normal (and abnormal!) things to see if it falls over?

I build all the patches I have along with all of linux-next and boot
the thing, then use the resulting kernel for a few hours compilation
testing, then shove it all into linux-next where I naively hope that
someone else is testing things.

The coverage which is obtained this way is pretty poor.  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 01:23:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 01:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoPfb-0004wR-1m; Sat, 21 Jan 2012 01:23: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 1RoPfZ-0004wM-Py
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 01:23:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327108974!11758895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19340 invoked from network); 21 Jan 2012 01:22:55 -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 Jan 2012 01:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,546,1320624000"; d="scan'208";a="10187217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jan 2012 01:22: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; Sat, 21 Jan 2012 01:22: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 1RoPfR-00034f-RJ;
	Sat, 21 Jan 2012 01:22:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoPfR-0002Uh-QC;
	Sat, 21 Jan 2012 01:22:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10932-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Jan 2012 01:22:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10932: 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 10932 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10932/

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. 10913
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10913
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10913

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-xl-win         7 windows-install              fail   like 10902

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 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-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  ef8374dfe9bf
baseline version:
 xen                  2273ef2083d4

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-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.

------------------------------------------------------------
changeset:   24530:ef8374dfe9bf
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 18:17:59 2012 +0000
    
    x86/hvm: Fix earlier hvm_load_cpu_ctxt() breakage.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24529:87854d3bed93
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Fri Jan 20 10:40:16 2012 +0000
    
    vpmu: separate architecture specific PMU initialisation
    
    This patch moves the architecture specific initialisation of the PMU
    into the archicture specific directory.
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24528:3d58058fc7a2
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:26:57 2012 +0000
    
    x86/hvm: Remove unnecessary packed attribute from hvm_hw_cpu_xsave struct.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24527:028230eb2359
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Fri Jan 20 10:20:32 2012 +0000
    
    iommu: Move IOMMU faults handling into softirq for AMD-Vi.
    
    Dealing with interrupts from AMD-Vi IOMMU(s) 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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24526:d600a3d7faee
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Jan 20 10:17:12 2012 +0000
    
    x86/hvm: Allow wake up of offline vcpu via nmi-ipi
    
    On a real machine a cpu disabled via hlt with interrupts disabled can
    be reactivated via a nmi ipi. Enable the hypervisor to do this for
    hvm, too.
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24525:a3f67482c321
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:13:55 2012 +0000
    
    xen: Simplify callers of boot_vcpu(). In VCPUOP_up, check
    is_initialised under the per-domain lock.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24524:2273ef2083d4
user:        Tim Deegan <tim@xen.org>
date:        Thu Jan 19 13:09:23 2012 +0000
    
    x86/mm: refine epte_present test
    
    The current test for a present ept entry checks for a permission bit
    to be set.
    
    While this is valid in contexts in which we want to know whether an entry
    will fault, it is not correct when it comes to testing whether an entry is
    valid. Specifically, in the ept_change_entry_type_page function which is
    used to set entries to the log dirty type.
    
    In combination with a p2m access type like n or n2rwx, log dirty will not be
    set for ept entries for which it should.
    
    Reported-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Sat Jan 21 01:23:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 01:23:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoPfb-0004wR-1m; Sat, 21 Jan 2012 01:23: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 1RoPfZ-0004wM-Py
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 01:23:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327108974!11758895!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19340 invoked from network); 21 Jan 2012 01:22:55 -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 Jan 2012 01:22:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,546,1320624000"; d="scan'208";a="10187217"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jan 2012 01:22: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; Sat, 21 Jan 2012 01:22: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 1RoPfR-00034f-RJ;
	Sat, 21 Jan 2012 01:22:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoPfR-0002Uh-QC;
	Sat, 21 Jan 2012 01:22:53 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10932-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Jan 2012 01:22:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10932: 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 10932 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10932/

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. 10913
 test-amd64-i386-xend-winxpsp3  7 windows-install          fail REGR. vs. 10913
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 10913

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-xl-win         7 windows-install              fail   like 10902

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 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-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  ef8374dfe9bf
baseline version:
 xen                  2273ef2083d4

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-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.

------------------------------------------------------------
changeset:   24530:ef8374dfe9bf
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 18:17:59 2012 +0000
    
    x86/hvm: Fix earlier hvm_load_cpu_ctxt() breakage.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24529:87854d3bed93
user:        Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date:        Fri Jan 20 10:40:16 2012 +0000
    
    vpmu: separate architecture specific PMU initialisation
    
    This patch moves the architecture specific initialisation of the PMU
    into the archicture specific directory.
    
    Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24528:3d58058fc7a2
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:26:57 2012 +0000
    
    x86/hvm: Remove unnecessary packed attribute from hvm_hw_cpu_xsave struct.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24527:028230eb2359
user:        Dario Faggioli <dario.faggioli@citrix.com>
date:        Fri Jan 20 10:20:32 2012 +0000
    
    iommu: Move IOMMU faults handling into softirq for AMD-Vi.
    
    Dealing with interrupts from AMD-Vi IOMMU(s) 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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24526:d600a3d7faee
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Fri Jan 20 10:17:12 2012 +0000
    
    x86/hvm: Allow wake up of offline vcpu via nmi-ipi
    
    On a real machine a cpu disabled via hlt with interrupts disabled can
    be reactivated via a nmi ipi. Enable the hypervisor to do this for
    hvm, too.
    
    Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
    Signed-off-by: Keir Fraser <keir@xen.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24525:a3f67482c321
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 10:13:55 2012 +0000
    
    xen: Simplify callers of boot_vcpu(). In VCPUOP_up, check
    is_initialised under the per-domain lock.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24524:2273ef2083d4
user:        Tim Deegan <tim@xen.org>
date:        Thu Jan 19 13:09:23 2012 +0000
    
    x86/mm: refine epte_present test
    
    The current test for a present ept entry checks for a permission bit
    to be set.
    
    While this is valid in contexts in which we want to know whether an entry
    will fault, it is not correct when it comes to testing whether an entry is
    valid. Specifically, in the ept_change_entry_type_page function which is
    used to set entries to the log dirty type.
    
    In combination with a p2m access type like n or n2rwx, log dirty will not be
    set for ept entries for which it should.
    
    Reported-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Signed-off-by: Tim Deegan <tim@xen.org>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Tim Deegan <tim@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Sat Jan 21 01:36:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 01:36:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoPrj-000572-B5; Sat, 21 Jan 2012 01:35:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RoPri-00056x-92
	for Xen-devel@lists.xensource.com; Sat, 21 Jan 2012 01:35:34 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327109309!61891017!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5NDEzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1987 invoked from network); 21 Jan 2012 01:28:30 -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; 21 Jan 2012 01:28:30 -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
	q0L1TZvr021827
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <Xen-devel@lists.xensource.com>; Sat, 21 Jan 2012 01:29:35 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
	q0L1TYEI019542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <Xen-devel@lists.xensource.com>; Sat, 21 Jan 2012 01:29:34 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
	q0L1TXET024378
	for <Xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 19:29:34 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 17:29:33 -0800
Date: Fri, 20 Jan 2012 17:29:32 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <20120120172932.3dd3f5ac@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.0A090202.4F1A14FF.008B,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [Ques]:xen_ident_map_ISA ant it's 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

Hi,

I am bit confused about the do_update_va_mapping call that dom0 makes in
xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The mfn belongs
to DOMID_IO. Before the mfn is mapped, the l1 entry is not empty:

0000000139d08500:  00100001380a0027

After the mapping:

0000000139d08500:  00100000000a0467  as expected.

However, the mfn 1380a0 still seems to belong to dom0. Shouldn't that
have been returned back to the xen heap? 

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 01:36:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 01:36:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoPrj-000572-B5; Sat, 21 Jan 2012 01:35:35 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RoPri-00056x-92
	for Xen-devel@lists.xensource.com; Sat, 21 Jan 2012 01:35:34 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327109309!61891017!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5NDEzNQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1987 invoked from network); 21 Jan 2012 01:28:30 -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; 21 Jan 2012 01:28:30 -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
	q0L1TZvr021827
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <Xen-devel@lists.xensource.com>; Sat, 21 Jan 2012 01:29:35 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
	q0L1TYEI019542
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <Xen-devel@lists.xensource.com>; Sat, 21 Jan 2012 01:29:34 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
	q0L1TXET024378
	for <Xen-devel@lists.xensource.com>; Fri, 20 Jan 2012 19:29:34 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 20 Jan 2012 17:29:33 -0800
Date: Fri, 20 Jan 2012 17:29:32 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Message-ID: <20120120172932.3dd3f5ac@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.0A090202.4F1A14FF.008B,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [Ques]:xen_ident_map_ISA ant it's 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

Hi,

I am bit confused about the do_update_va_mapping call that dom0 makes in
xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The mfn belongs
to DOMID_IO. Before the mfn is mapped, the l1 entry is not empty:

0000000139d08500:  00100001380a0027

After the mapping:

0000000139d08500:  00100000000a0467  as expected.

However, the mfn 1380a0 still seems to belong to dom0. Shouldn't that
have been returned back to the xen heap? 

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 05:39:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 05: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 1RoTfJ-000766-Oq; Sat, 21 Jan 2012 05:39:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RoTfI-000761-R5
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 05:39:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327124334!11354770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4227 invoked from network); 21 Jan 2012 05:38:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jan 2012 05:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,547,1320624000"; d="scan'208";a="10188385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jan 2012 05:38:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 21 Jan 2012 05:38: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 1RoTfC-0004Xu-1m;
	Sat, 21 Jan 2012 05:38:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoTfC-0005Ct-1J;
	Sat, 21 Jan 2012 05:38:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10976-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Jan 2012 05:38:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10976: 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 10976 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10976/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-win       7 windows-install              fail   like 10913
 test-amd64-i386-win           7 windows-install              fail   like 10913

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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-i386-xl-win7-amd64 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-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  ef8374dfe9bf
baseline version:
 xen                  2273ef2083d4

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=ef8374dfe9bf
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ef8374dfe9bf
+ branch=xen-unstable
+ revision=ef8374dfe9bf
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ef8374dfe9bf 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 11 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 05:39:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 05: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 1RoTfJ-000766-Oq; Sat, 21 Jan 2012 05:39:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RoTfI-000761-R5
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 05:39:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327124334!11354770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4227 invoked from network); 21 Jan 2012 05:38:54 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jan 2012 05:38:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,547,1320624000"; d="scan'208";a="10188385"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jan 2012 05:38:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 21 Jan 2012 05:38: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 1RoTfC-0004Xu-1m;
	Sat, 21 Jan 2012 05:38:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoTfC-0005Ct-1J;
	Sat, 21 Jan 2012 05:38:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-10976-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Jan 2012 05:38:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 10976: 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 10976 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/10976/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-win       7 windows-install              fail   like 10913
 test-amd64-i386-win           7 windows-install              fail   like 10913

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-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-i386-xl-win7-amd64 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-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  ef8374dfe9bf
baseline version:
 xen                  2273ef2083d4

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
  Jan Beulich <jbeulich@suse.com>
  Juergen Gross <juergen.gross@ts.fujitsu.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=ef8374dfe9bf
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ef8374dfe9bf
+ branch=xen-unstable
+ revision=ef8374dfe9bf
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 ef8374dfe9bf 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 11 changes to 10 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 09:11:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 09:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoWy5-0000OT-5g; Sat, 21 Jan 2012 09:10:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RoWy3-0000OO-N8
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 09:10:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327137028!10091511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25774 invoked from network); 21 Jan 2012 09:10:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jan 2012 09:10:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,547,1320624000"; d="scan'208";a="10189219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jan 2012 09: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; Sat, 21 Jan 2012 09:10: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 1RoWxv-0005lW-9F;
	Sat, 21 Jan 2012 09:10:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoWxv-0002qH-7z;
	Sat, 21 Jan 2012 09:10:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11028-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Jan 2012 09:10:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11028: 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 11028 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11028/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10976
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10976
 test-amd64-amd64-xl-win       7 windows-install    fail in 10976 pass in 11028

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10932
 test-amd64-i386-win           7 windows-install              fail   like 10976

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-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-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10976 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10976 never pass

version targeted for testing:
 xen                  ef8374dfe9bf
baseline version:
 xen                  ef8374dfe9bf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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


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 Jan 21 09:11:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 09:11:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoWy5-0000OT-5g; Sat, 21 Jan 2012 09:10:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RoWy3-0000OO-N8
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 09:10:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327137028!10091511!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzY5Mw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25774 invoked from network); 21 Jan 2012 09:10:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	21 Jan 2012 09:10:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,547,1320624000"; d="scan'208";a="10189219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jan 2012 09: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; Sat, 21 Jan 2012 09:10: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 1RoWxv-0005lW-9F;
	Sat, 21 Jan 2012 09:10:27 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RoWxv-0002qH-7z;
	Sat, 21 Jan 2012 09:10:27 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11028-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Jan 2012 09:10:27 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11028: 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 11028 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11028/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 10976
 test-amd64-i386-win-vcpus1    7 windows-install             fail pass in 10976
 test-amd64-amd64-xl-win       7 windows-install    fail in 10976 pass in 11028

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 10932
 test-amd64-i386-win           7 windows-install              fail   like 10976

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-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-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 10976 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 10976 never pass

version targeted for testing:
 xen                  ef8374dfe9bf
baseline version:
 xen                  ef8374dfe9bf

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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


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 Jan 21 11:38:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 11:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoZGe-0001AI-EH; Sat, 21 Jan 2012 11:37:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RoZGc-0001AD-2h
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 11:37:54 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327145867!11746885!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22420 invoked from network); 21 Jan 2012 11:37:48 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-7.tower-182.messagelabs.com with SMTP;
	21 Jan 2012 11:37:48 -0000
Received: (qmail 706 invoked from network); 21 Jan 2012 12:37:46 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	21 Jan 2012 12:37:46 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Sat, 21 Jan 2012 12:37:45 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201201171115.53993.pavel@netsafe.cz>
In-Reply-To: <201201171115.53993.pavel@netsafe.cz>
MIME-Version: 1.0
Message-Id: <201201211237.45781.pavel@netsafe.cz>
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi again,
I made some stupid mistakes in my build. The passthru is working of course.
You can add another working system to Wiki:
MB: ASUS Crosshair V Formula (BIOS 1102)
CPU: AMD FX-8150
VGA: ASUS HD7970
Since all 7970s have same BIOS they should all work.

There was just one small problem. I have both HD7970 and HD6850 in computer 
right now.
If you want to run Virtual machines with different cards you have to load righ 
BIOS for each one.
Because I can't find HD7970 BIOS to download yet I had to make it primary and 
copy BIOS from RAM while HD6850 got it from file.
I'll try to write patch which will tell XEN the VGA BIOS location per virtual 
server basis.
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 11:38:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 11:38:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RoZGe-0001AI-EH; Sat, 21 Jan 2012 11:37:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RoZGc-0001AD-2h
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 11:37:54 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327145867!11746885!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22420 invoked from network); 21 Jan 2012 11:37:48 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-7.tower-182.messagelabs.com with SMTP;
	21 Jan 2012 11:37:48 -0000
Received: (qmail 706 invoked from network); 21 Jan 2012 12:37:46 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	21 Jan 2012 12:37:46 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Sat, 21 Jan 2012 12:37:45 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201201171115.53993.pavel@netsafe.cz>
In-Reply-To: <201201171115.53993.pavel@netsafe.cz>
MIME-Version: 1.0
Message-Id: <201201211237.45781.pavel@netsafe.cz>
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi again,
I made some stupid mistakes in my build. The passthru is working of course.
You can add another working system to Wiki:
MB: ASUS Crosshair V Formula (BIOS 1102)
CPU: AMD FX-8150
VGA: ASUS HD7970
Since all 7970s have same BIOS they should all work.

There was just one small problem. I have both HD7970 and HD6850 in computer 
right now.
If you want to run Virtual machines with different cards you have to load righ 
BIOS for each one.
Because I can't find HD7970 BIOS to download yet I had to make it primary and 
copy BIOS from RAM while HD6850 got it from file.
I'll try to write patch which will tell XEN the VGA BIOS location per virtual 
server basis.
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 11:59:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 11: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 1RoZb5-0001Lp-Cg; Sat, 21 Jan 2012 11:59:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RoZb3-0001Lk-14
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 11:59:01 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327147134!11925615!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTAwNzM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2869 invoked from network); 21 Jan 2012 11:58:55 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Jan 2012 11:58:55 -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 280D61AC4;
	Sat, 21 Jan 2012 13:58:53 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B04BB200B0; Sat, 21 Jan 2012 13:58:53 +0200 (EET)
Date: Sat, 21 Jan 2012 13:58:53 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Pavel Mat??ja <pavel@netsafe.cz>
Message-ID: <20120121115853.GZ12984@reaktio.net>
References: <201201171115.53993.pavel@netsafe.cz>
	<201201211237.45781.pavel@netsafe.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201201211237.45781.pavel@netsafe.cz>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 21, 2012 at 12:37:45PM +0100, Pavel Mat??ja wrote:
> Hi again,
> I made some stupid mistakes in my build. The passthru is working of course.
> You can add another working system to Wiki:
> MB: ASUS Crosshair V Formula (BIOS 1102)
> CPU: AMD FX-8150
> VGA: ASUS HD7970
> Since all 7970s have same BIOS they should all work.
> 

Great!

> There was just one small problem. I have both HD7970 and HD6850 in computer 
> right now.
> If you want to run Virtual machines with different cards you have to load righ 
> BIOS for each one.
> Because I can't find HD7970 BIOS to download yet I had to make it primary and 
> copy BIOS from RAM while HD6850 got it from file.
> I'll try to write patch which will tell XEN the VGA BIOS location per virtual 
> server basis.

That would be much appreciated!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 11:59:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 11: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 1RoZb5-0001Lp-Cg; Sat, 21 Jan 2012 11:59:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1RoZb3-0001Lk-14
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 11:59:01 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327147134!11925615!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTAwNzM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2869 invoked from network); 21 Jan 2012 11:58:55 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Jan 2012 11:58:55 -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 280D61AC4;
	Sat, 21 Jan 2012 13:58:53 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B04BB200B0; Sat, 21 Jan 2012 13:58:53 +0200 (EET)
Date: Sat, 21 Jan 2012 13:58:53 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Pavel Mat??ja <pavel@netsafe.cz>
Message-ID: <20120121115853.GZ12984@reaktio.net>
References: <201201171115.53993.pavel@netsafe.cz>
	<201201211237.45781.pavel@netsafe.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201201211237.45781.pavel@netsafe.cz>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, Jan 21, 2012 at 12:37:45PM +0100, Pavel Mat??ja wrote:
> Hi again,
> I made some stupid mistakes in my build. The passthru is working of course.
> You can add another working system to Wiki:
> MB: ASUS Crosshair V Formula (BIOS 1102)
> CPU: AMD FX-8150
> VGA: ASUS HD7970
> Since all 7970s have same BIOS they should all work.
> 

Great!

> There was just one small problem. I have both HD7970 and HD6850 in computer 
> right now.
> If you want to run Virtual machines with different cards you have to load righ 
> BIOS for each one.
> Because I can't find HD7970 BIOS to download yet I had to make it primary and 
> copy BIOS from RAM while HD6850 got it from file.
> I'll try to write patch which will tell XEN the VGA BIOS location per virtual 
> server basis.

That would be much appreciated!

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 20:07:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 20: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 1RohDC-00060F-6G; Sat, 21 Jan 2012 20:06:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RohDA-00060A-AM
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 20:06:52 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327176390!63412605!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzYwNDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15627 invoked from network); 21 Jan 2012 20:06:30 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jan 2012 20:06:30 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1DE74207FF
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 15:06:50 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute6.internal (MEProxy); Sat, 21 Jan 2012 15:06:50 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:subject:date; s=mesmtp; bh=O0HPrz95Y67s458jae/KHWp
	yDJE=; b=XIPGevxBc733RzhArir3aljWFUJFIwwDwS/9C0+nHmIGhl5GWeJMdA7
	ppBpvFX9veWfEs39e7XUAkwSwuGkyhQwdBs3CQxqMoD/O0ajxZJU5M8oljiwWB9t
	a6lwlwVCwkFCSyPPhmwOjs7jlI6YtkP9c6DqbCpqRK4Q8dWqVm7I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:subject:date; s=smtpout;
	bh=O0HPrz95Y67s458jae/KHWpyDJE=; b=jW0Vbd7hlKxnG7k9rGnWcvCHXYnu
	Y1P6xRNpr05r8xZoGgUsJP63kjp6tCaeZl37NpdXu8kVuVn3ZXNclGco5u3zQvHO
	Iq9C9gMi05a0tUu0e8Cld7E7OG6R2AdNlPYZFOID6VH/BqTl4w1SvjjNWQoEKu7r
	cUG9768BvbrtHc4=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id EB3FEA00075; Sat, 21 Jan 2012 15:06:49 -0500 (EST)
Message-Id: <1327176409.25269.140661026313477@webmail.messagingengine.com>
X-Sasl-Enc: Lbsjac74NFS4vtWPPAZ7MgFY/zSB3kp3oP5+I0f1NKlh 1327176409
From: erin.balid@inoutbox.com
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Date: Sat, 21 Jan 2012 12:06:49 -0800
Subject: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGkgQWxsLgoKSSBwb3N0ZWQgdGhpcyBvdmVyIG9uIHRoZSBPcGVuU1VTRSBWaXJ0dWFsIG1haWxp
bmcgbGlzdCwgc2luY2UgSSB1c2UKdGhhdCBkaXN0cm8uICBCdXQgSSBmb3VuZCBvbiB0aGUgWGVu
IHdpa2kgc2l0ZSwKCiAgaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL01pZ3JhdGlvbkd1aWRlVG9Y
ZW40LjElMkIjVG9vbHN0YWNrX3VwZ3JhZGVfbm90ZXMKCnNvIEkgZ3Vlc3Mgd2Ugc2hvdWxkIHBv
c3QgeG0tPnhsIG1pZ3JhdGlvbiBjb25maWd1cmF0aW9uIHByb2JsZW1zIGhlcmUKdG9vLCBvciBp
bnN0ZWFkLgoKCkkgaW5oZXJpdGVkIGFuIE9wZW5TVVNFIFZlcnNpb24gMTEuNCBYZW4gaG9zdCBt
YWNoaW5lIGhlcmUgYXQgd29yay4KCldpdGhvdXQgdG9vIG11Y2ggdHJvdWJsZSBJIGZpbmlzaGVk
IHVwZ3JhZGluZyBpdCB0byBWZXJzaW9uIDEyLjEuCgpUaGUgb2xkIHNldHVwIHdhcyBydW5uaW5n
IHVzaW5nIHRoZSBYZW4gInhtIiB0b29sc3RhY2sgYW5kIHdvcmtzIGxpa2UKeW91J2QgZXhwZWN0
LiAgVGhlIG5ldyBzZXR1cCB3b3JrcyBvayBpZiBJIHVzZSB0aGUgInhtIiBzdGFjayBhcyB3ZWxs
LgoKSSBsZWFybmVkIHRoYXQgd2Ugc2hvdWxkIG1vdmUgdG8gdGhlICJ4bCIgdG9vbHN0YWNrLiAg
SSdtIHRyeWluZyB0byBkbwp0aGF0IG5vdyBhbmQgaGF2aW5nIHNvbWUgcHJvYmxlbXMgd2l0aCBu
ZXR3b3JraW5nLCBidXQgb25seSB3aXRoIHRoZSB4bAphcHByb2FjaC4KCkkndmUgYmVlbiBydW5u
aW5nIHVwIHRvIGRhdGUgWGVuIGZvciBhd2hpbGUuCgpycG0gLXFhIHwgZ3JlcCAtaSB4ZW4KIHhl
bi10b29scy00LjEuMl8xMS0xNjQuNS54ODZfNjQKIHhlbi1kb2MtaHRtbC00LjEuMl8xMS0xNjQu
NS54ODZfNjQKIHhlbi1saWJzLTQuMS4yXzExLTE2NC41Lng4Nl82NAogeGVuLTQuMS4yXzExLTE2
NC41Lng4Nl82NAogcGF0dGVybnMtb3BlblNVU0UteGVuX3NlcnZlci0xMi4xLTI1LjIxLjEueDg2
XzY0CiB4ZW4tZGV2ZWwtNC4xLjJfMTEtMTY0LjUueDg2XzY0CiB4ZW4tZG9jLXBkZi00LjEuMl8x
MS0xNjQuNS54ODZfNjQKIGtlcm5lbC14ZW4tZGV2ZWwtMy4xLjAtMS4yLjEueDg2XzY0CiBrZXJu
ZWwteGVuLTMuMS4wLTEuMi4xLng4Nl82NAoKSSBhbHJlYWR5IHNldHVwIHRoZSBuZXR3b3JraW5n
IG9uIHRoZSBIb3N0IHRvIHVzZSBPcGVuU1VTRQpjb25maWd1cmF0aW9uLgoKYnJjdGwgc2hvdwog
YnJpZGdlIG5hbWUgICAgIGJyaWRnZSBpZCAgICAgICAgICAgICAgIFNUUCBlbmFibGVkICAgICBp
bnRlcmZhY2VzCiBicjAgICAgICAgICAgICAgODAwMC4wMDUyMzUxZDUzMzcgICAgICAgbm8gICAg
ICAgICAgICAgIGV0aDAKCmNhdCAvZXRjL3N5c2NvbmZpZy9uZXR3b3JrL2lmY2ZnLWJyMCAgCiBT
VEFSVE1PREU9J2F1dG8nCiBCT09UUFJPVE89J3N0YXRpYycKIEJSSURHRT0neWVzJwogQlJJREdF
X1BPUlRTPSdldGgwJwogQlJJREdFX0ZPUldBUkRERUxBWT0nMCcKIEJSSURHRV9TVFA9J29mZicK
CiBOQU1FPSdNb3RoZXJib2FyZCcKIElQQUREUj0nMTkyLjE2OC4xLjMyLzI0JwogQlJPQURDQVNU
PScnCiBSRU1PVEVfSVBBRERSPScnCiBORVRXT1JLPScnCiBNVFU9JycKIEVUSFRPT0xfT1BUSU9O
Uz0nJwogVVNFUkNPTlRST0w9J25vJwogTk1fQ09OVFJPTExFRD0nbm8nCgpjYXQgL2V0Yy9zeXNj
b25maWcvbmV0d29yay9pZmNmZy1ldGgwCiBTVEFSVE1PREU9J21hbnVhbCcKIEJPT1RQUk9UTz0n
bm9uZScKIEJSSURHRT0nbm8nCgpUaGUgR3Vlc3QgY2ZnIGZpbGUgSSdtIHVzaW5nIGZvciB0ZXN0
aW5nIGlzOgoKY2F0IHRlc3QuY2ZnCiBuYW1lPSd0ZXN0JwogYnVpbGRlcj0nbGludXgnCiBib290
bG9hZGVyPScvdXNyL2Jpbi9weWdydWInCiBkaXNrPVsncGh5Oi9kZXYvWGVuVm9scy90ZXN0LHh2
ZGEsdyddCiB2aWY9W21hYz0wMDoxNjozZToxMjozNDowMSwgYnJpZGdlPWJyMCAgLCB2aWZuYW1l
PXZpZkJSJ10KIHZmYj1bICd0eXBlPXZuYywgdm5jZGlzcGxheT0xLCB2bmNsaXN0ZW49MTI3LjAu
MC4xJ10KIGV4dHJhPSd0ZXh0bW9kZT0xIHhlbmNvbnM9eHZjMCBub2lycWRlYnVnJwogb25fc2h1
dGRvd249J2Rlc3Ryb3knCiBvbl9yZWJvb3Q9J3Jlc3RhcnQnCiBvbl9jcmFzaD0nZGVzdHJveScK
IHZjcHVzPTIKIG1heG1lbT0yMDQ4CiBtZW1vcnk9MjA0OAoKV2l0aCBhIGNsZWFuLWJvb3RlZCBI
b3N0IGFuZCBubyBsYXVuY2hlZCBHdWVzdHMsCgp4bCBsaXN0CiBOYW1lICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIElEICAgTWVtIFZDUFVzICAgICAgU3RhdGUgIAogVGlt
ZShzKQogRG9tYWluLTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgMTAx
MCAgICAgNCAgICAgci0tLS0tICAKICAgIDg2LjMKCnhsIGNyZWF0ZSAtYyB0ZXN0LmNmZwoJICAg
IHB5R1JVQiAgdmVyc2lvbiAwLjYKCSDilIzilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilJAKCSDilIIgWGVuNCAxMi4xIERvbVUgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoJICAgICAgICAgIOKUggoJIOKUgiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCgkg
ICAgICAgICAg4pSCCgkg4pSCICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKCSAgICAgICAgICDilIIKCSDilIIgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoJICAgICAg
ICAgIOKUggoJIOKUgiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCgkgICAgICAgICAg4pSCCgkg4pSCICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKCSAgICAgICAgICDi
lIIKCSDilIIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAoJICAgICAgICAgIOKUggoJIOKUgiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCgkgICAgICAgICAg4pSCCgkg
4pSU4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSYCgkgICAg
IFVzZSB0aGUgXiBhbmQgdiBrZXlzIHRvIHNlbGVjdCB3aGljaCBlbnRyeSBpcyBoaWdobGlnaHRl
ZC4KCSAgICAgUHJlc3MgZW50ZXIgdG8gYm9vdCB0aGUgc2VsZWN0ZWQgT1MsICdlJyB0byBlZGl0
IHRoZQoJICAgICBjb21tYW5kcyBiZWZvcmUgYm9vdGluZywgJ2EnIHRvIG1vZGlmeSB0aGUga2Vy
bmVsIGFyZ3VtZW50cwoJICAgICBiZWZvcmUgYm9vdGluZywgb3IgJ2MnIGZvciBhIGNvbW1hbmQg
bGluZS4KCgkgICAgIFdpbGwgYm9vdCBzZWxlY3RlZCBlbnRyeSBpbiAgMSBzZWNvbmRzCgoKCURh
ZW1vbiBydW5uaW5nIHdpdGggUElEIDY3NzkKCkkgZ2V0IG5vIG90aGVyIG91dHB1dCBoZXJlICh3
aHkgbm90Pykgb24gdGhlIGNvbnNvbGUgZm9yIGFib3V0IDMwCnNlY29uZHMuIFRoZW4ganVzdCwK
CiBXZWxjb21lIHRvIG9wZW5TVVNFIDEyLjEgIkFzcGFyYWd1cyIgLSBLZXJuZWwgMy4xLjAtMS4y
LXhlbiAoeHZjMCkuCgogdGVzdHNlcnZlciBsb2dpbjoKCgpUaGUgb3V0cHV0IG9mICd0YWlsIC1m
IC92YXIvbG9nL21lc3NhZ2VzIC92YXIvbG9nL3hlbi8qbG9nJyBpcyBqdXN0CgoJPT0+IC92YXIv
bG9nL21lc3NhZ2VzIDw9PQoJSmFuIDIxIDEwOjQwOjM5IHRlc3RzZXJ2ZXIgbG9nZ2VyOiAvZXRj
L3hlbi9zY3JpcHRzL2Jsb2NrOiBhZGQKCVhFTkJVU19QQVRIPWJhY2tlbmQvdmJkLzUvNTE3MTIK
CUphbiAyMSAxMDo0MDozOSB0ZXN0c2VydmVyIGxvZ2dlcjogL2V0Yy94ZW4vc2NyaXB0cy9ibG9j
azogYWRkCglYRU5CVVNfUEFUSD1iYWNrZW5kL3ZiZC81LzUxNzI4CglKYW4gMjEgMTA6NDA6Mzkg
dGVzdHNlcnZlciBsb2dnZXI6IC9ldGMveGVuL3NjcmlwdHMvYmxvY2s6IGFkZAoJWEVOQlVTX1BB
VEg9YmFja2VuZC92YmQvNS81MTc0NAoJSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIgbG9nZ2Vy
OiAvZXRjL3hlbi9zY3JpcHRzL3ZpZi1icmlkZ2U6CglvbmxpbmUgdHlwZV9pZj12aWYgWEVOQlVT
X1BBVEg9YmFja2VuZC92aWYvNS8wCglKYW4gMjEgMTA6NDA6NDAgdGVzdHNlcnZlciBsb2dnZXI6
IC9ldGMveGVuL3NjcmlwdHMvdmlmLWJyaWRnZToKCU5vIGRldmljZSBkZXRhaWxzIGluIGJhY2tl
bmQvdmlmLzUvMCwgZXhpdGluZy4KCUphbiAyMSAxMDo0MDo0MCB0ZXN0c2VydmVyIGxvZ2dlcjog
L2V0Yy94ZW4vc2NyaXB0cy92aWYtYnJpZGdlOgoJb25saW5lIFhFTkJVU19QQVRIPWJhY2tlbmQv
dmlmLzUvMAoJSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIgbG9nZ2VyOiAvZXRjL3hlbi9zY3Jp
cHRzL3ZpZi1icmlkZ2U6CglObyBkZXZpY2UgZGV0YWlscyBpbiBiYWNrZW5kL3ZpZi81LzAsIGV4
aXRpbmcuCglKYW4gMjEgMTA6NDA6NDAgdGVzdHNlcnZlciBrZXJuZWw6IFsgMjcxMS45NTE4MjJd
IGJsa2JhY2s6CglyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEyLCBwcm90b2NvbCAxICh4ODZf
NjQtYWJpKQoJSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIga2VybmVsOiBbIDI3MTIuMDE1NzMx
XSBibGtiYWNrOgoJcmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxMywgcHJvdG9jb2wgMSAoeDg2
XzY0LWFiaSkKCUphbiAyMSAxMDo0MDo0MCB0ZXN0c2VydmVyIGtlcm5lbDogWyAyNzEyLjA2NjQ2
N10gYmxrYmFjazoKCXJpbmctcmVmIDEwLCBldmVudC1jaGFubmVsIDE0LCBwcm90b2NvbCAxICh4
ODZfNjQtYWJpKQoKCkkgY2FuIGxvZ2luIHRvIHRoZSBndWVzdCBhdCB0aGUgY29uc29sZSBhbmQg
dGhlIEd1ZXN0J3MgbmV0d29ya2luZyBsb29rcwpsaWtlIGl0J3MgcmVjb2duaXplZCBPSy4KCmRt
ZXNnIHwgZ3JlcCBldGgKWyAgICAwLjg5NjU5N10gbmV0ZnJvbnQ6IEluaXRpYWxpc2luZyB2aXJ0
dWFsIGV0aGVybmV0IGRyaXZlci4KCmh3aW5mbyAtLW5ldHdvcmsKMDU6IE5vbmUgMDAuMDogMTA3
MDAgTG9vcGJhY2sKICBbQ3JlYXRlZCBhdCBuZXQuMTI0XQogIFVuaXF1ZSBJRDogWnNCUy5HUU54
N0w0dVBOQQogIFN5c0ZTIElEOiAvY2xhc3MvbmV0L2xvCiAgSGFyZHdhcmUgQ2xhc3M6IG5ldHdv
cmsgaW50ZXJmYWNlCiAgTW9kZWw6ICJMb29wYmFjayBuZXR3b3JrIGludGVyZmFjZSIKICBEZXZp
Y2UgRmlsZTogbG8KICBMaW5rIGRldGVjdGVkOiB5ZXMKICBDb25maWcgU3RhdHVzOiBjZmc9bmV3
LCBhdmFpbD15ZXMsIG5lZWQ9bm8sIGFjdGl2ZT11bmtub3duCgowNjogTm9uZSAwMC4wOiAxMDcw
MSBFdGhlcm5ldAogIFtDcmVhdGVkIGF0IG5ldC4xMjRdCiAgVW5pcXVlIElEOiB1c0RXLm5kcGV1
Y2F4NlYxCiAgUGFyZW50IElEOiAranNnLlNkK3lrZnl2bEs0CiAgU3lzRlMgSUQ6IC9jbGFzcy9u
ZXQvZXRoMAogIFN5c0ZTIERldmljZSBMaW5rOiAvZGV2aWNlcy94ZW4vdmlmLTAKICBIYXJkd2Fy
ZSBDbGFzczogbmV0d29yayBpbnRlcmZhY2UKICBNb2RlbDogIkV0aGVybmV0IG5ldHdvcmsgaW50
ZXJmYWNlIgogIERyaXZlcjogInZpZiIKICBEcml2ZXIgTW9kdWxlczogInhlbm5ldCIKICBEZXZp
Y2UgRmlsZTogZXRoMAogIEhXIEFkZHJlc3M6IDAwOjE2OjNlOjEyOjM0OjAxCiAgTGluayBkZXRl
Y3RlZDogeWVzCiAgQ29uZmlnIFN0YXR1czogY2ZnPW5ldywgYXZhaWw9eWVzLCBuZWVkPW5vLCBh
Y3RpdmU9dW5rbm93bgogIEF0dGFjaGVkIHRvOiAjNCAoRXRoZXJuZXQgY29udHJvbGxlcikKClRo
ZSBHdWVzdCdzIG5ldHdvcmsgcm91dGVzIGxvb2sgT0suCgpyb3V0ZQpLZXJuZWwgSVAgcm91dGlu
ZyB0YWJsZQpEZXN0aW5hdGlvbiAgICAgR2F0ZXdheSAgICAgICAgIEdlbm1hc2sgICAgICAgICBG
bGFncyBNZXRyaWMgUmVmICAgIFVzZQpJZmFjZQpkZWZhdWx0ICAgICAgICAgMTkyLjE2OC4xLjEg
ICAgIDAuMC4wLjAgICAgICAgICBVRyAgICAwICAgICAgMCAgICAgICAgMApldGgwCmxvb3BiYWNr
ICAgICAgICAqICAgICAgICAgICAgICAgMjU1LjAuMC4wICAgICAgIFUgICAgIDAgICAgICAwICAg
ICAgICAwCmxvCmxpbmstbG9jYWwgICAgICAqICAgICAgICAgICAgICAgMjU1LjI1NS4wLjAgICAg
IFUgICAgIDAgICAgICAwICAgICAgICAwCmV0aDAKMTkyLjE2OC4xLjAgICAgICogICAgICAgICAg
ICAgICAyNTUuMjU1LjI1NS4wICAgVSAgICAgMCAgICAgIDAgICAgICAgIDAKZXRoMAoKQnV0IHdo
ZW4gSSB0cnkgdG8gcGluZyBhbnl3aGVyZSBvZmYgdGhlIEd1ZXN0IEkgZ2V0IEhvc3RVbnJlYWNo
YWJsZQplcnJvcnMuCgpwaW5nIDE5Mi4xNjguMS4xClBJTkcgMTkyLjE2OC4xLjEgKDE5Mi4xNjgu
MS4xKSA1Nig4NCkgYnl0ZXMgb2YgZGF0YS4KRnJvbSAxOTIuMTY4LjEuMzIgaWNtcF9zZXE9MSBE
ZXN0aW5hdGlvbiBIb3N0IFVucmVhY2hhYmxlCkZyb20gMTkyLjE2OC4xLjMyIGljbXBfc2VxPTIg
RGVzdGluYXRpb24gSG9zdCBVbnJlYWNoYWJsZQpGcm9tIDE5Mi4xNjguMS4zMiBpY21wX3NlcT0z
IERlc3RpbmF0aW9uIEhvc3QgVW5yZWFjaGFibGUKZXRjIGV0YwoKSXQgZmVlbHMgbGlrZSBJJ20g
cHJldHR5IGNsb3NlIHRvIGdldHRpbmcgdGhpcyB3b3JraW5nLiAgQW0gSSBzdGlsbAptaXNzaW5n
IHNvbWUgcGFydCBvZiB0aGUgY29uZmlndXJhdGlvbiBjaGFuZ2VzIG5lZWRlZCBmb3IgdXNpbmcg
dGhlIHhsCnRvb2xzdGFjaz8KClJlZ2FyZHMsCgpFcmluCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xensource.com Sat Jan 21 20:07:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 20: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 1RohDC-00060F-6G; Sat, 21 Jan 2012 20:06:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RohDA-00060A-AM
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 20:06:52 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327176390!63412605!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzYwNDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15627 invoked from network); 21 Jan 2012 20:06:30 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 21 Jan 2012 20:06:30 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1DE74207FF
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 15:06:50 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute6.internal (MEProxy); Sat, 21 Jan 2012 15:06:50 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:subject:date; s=mesmtp; bh=O0HPrz95Y67s458jae/KHWp
	yDJE=; b=XIPGevxBc733RzhArir3aljWFUJFIwwDwS/9C0+nHmIGhl5GWeJMdA7
	ppBpvFX9veWfEs39e7XUAkwSwuGkyhQwdBs3CQxqMoD/O0ajxZJU5M8oljiwWB9t
	a6lwlwVCwkFCSyPPhmwOjs7jlI6YtkP9c6DqbCpqRK4Q8dWqVm7I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:subject:date; s=smtpout;
	bh=O0HPrz95Y67s458jae/KHWpyDJE=; b=jW0Vbd7hlKxnG7k9rGnWcvCHXYnu
	Y1P6xRNpr05r8xZoGgUsJP63kjp6tCaeZl37NpdXu8kVuVn3ZXNclGco5u3zQvHO
	Iq9C9gMi05a0tUu0e8Cld7E7OG6R2AdNlPYZFOID6VH/BqTl4w1SvjjNWQoEKu7r
	cUG9768BvbrtHc4=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id EB3FEA00075; Sat, 21 Jan 2012 15:06:49 -0500 (EST)
Message-Id: <1327176409.25269.140661026313477@webmail.messagingengine.com>
X-Sasl-Enc: Lbsjac74NFS4vtWPPAZ7MgFY/zSB3kp3oP5+I0f1NKlh 1327176409
From: erin.balid@inoutbox.com
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Date: Sat, 21 Jan 2012 12:06:49 -0800
Subject: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGkgQWxsLgoKSSBwb3N0ZWQgdGhpcyBvdmVyIG9uIHRoZSBPcGVuU1VTRSBWaXJ0dWFsIG1haWxp
bmcgbGlzdCwgc2luY2UgSSB1c2UKdGhhdCBkaXN0cm8uICBCdXQgSSBmb3VuZCBvbiB0aGUgWGVu
IHdpa2kgc2l0ZSwKCiAgaHR0cDovL3dpa2kueGVuLm9yZy93aWtpL01pZ3JhdGlvbkd1aWRlVG9Y
ZW40LjElMkIjVG9vbHN0YWNrX3VwZ3JhZGVfbm90ZXMKCnNvIEkgZ3Vlc3Mgd2Ugc2hvdWxkIHBv
c3QgeG0tPnhsIG1pZ3JhdGlvbiBjb25maWd1cmF0aW9uIHByb2JsZW1zIGhlcmUKdG9vLCBvciBp
bnN0ZWFkLgoKCkkgaW5oZXJpdGVkIGFuIE9wZW5TVVNFIFZlcnNpb24gMTEuNCBYZW4gaG9zdCBt
YWNoaW5lIGhlcmUgYXQgd29yay4KCldpdGhvdXQgdG9vIG11Y2ggdHJvdWJsZSBJIGZpbmlzaGVk
IHVwZ3JhZGluZyBpdCB0byBWZXJzaW9uIDEyLjEuCgpUaGUgb2xkIHNldHVwIHdhcyBydW5uaW5n
IHVzaW5nIHRoZSBYZW4gInhtIiB0b29sc3RhY2sgYW5kIHdvcmtzIGxpa2UKeW91J2QgZXhwZWN0
LiAgVGhlIG5ldyBzZXR1cCB3b3JrcyBvayBpZiBJIHVzZSB0aGUgInhtIiBzdGFjayBhcyB3ZWxs
LgoKSSBsZWFybmVkIHRoYXQgd2Ugc2hvdWxkIG1vdmUgdG8gdGhlICJ4bCIgdG9vbHN0YWNrLiAg
SSdtIHRyeWluZyB0byBkbwp0aGF0IG5vdyBhbmQgaGF2aW5nIHNvbWUgcHJvYmxlbXMgd2l0aCBu
ZXR3b3JraW5nLCBidXQgb25seSB3aXRoIHRoZSB4bAphcHByb2FjaC4KCkkndmUgYmVlbiBydW5u
aW5nIHVwIHRvIGRhdGUgWGVuIGZvciBhd2hpbGUuCgpycG0gLXFhIHwgZ3JlcCAtaSB4ZW4KIHhl
bi10b29scy00LjEuMl8xMS0xNjQuNS54ODZfNjQKIHhlbi1kb2MtaHRtbC00LjEuMl8xMS0xNjQu
NS54ODZfNjQKIHhlbi1saWJzLTQuMS4yXzExLTE2NC41Lng4Nl82NAogeGVuLTQuMS4yXzExLTE2
NC41Lng4Nl82NAogcGF0dGVybnMtb3BlblNVU0UteGVuX3NlcnZlci0xMi4xLTI1LjIxLjEueDg2
XzY0CiB4ZW4tZGV2ZWwtNC4xLjJfMTEtMTY0LjUueDg2XzY0CiB4ZW4tZG9jLXBkZi00LjEuMl8x
MS0xNjQuNS54ODZfNjQKIGtlcm5lbC14ZW4tZGV2ZWwtMy4xLjAtMS4yLjEueDg2XzY0CiBrZXJu
ZWwteGVuLTMuMS4wLTEuMi4xLng4Nl82NAoKSSBhbHJlYWR5IHNldHVwIHRoZSBuZXR3b3JraW5n
IG9uIHRoZSBIb3N0IHRvIHVzZSBPcGVuU1VTRQpjb25maWd1cmF0aW9uLgoKYnJjdGwgc2hvdwog
YnJpZGdlIG5hbWUgICAgIGJyaWRnZSBpZCAgICAgICAgICAgICAgIFNUUCBlbmFibGVkICAgICBp
bnRlcmZhY2VzCiBicjAgICAgICAgICAgICAgODAwMC4wMDUyMzUxZDUzMzcgICAgICAgbm8gICAg
ICAgICAgICAgIGV0aDAKCmNhdCAvZXRjL3N5c2NvbmZpZy9uZXR3b3JrL2lmY2ZnLWJyMCAgCiBT
VEFSVE1PREU9J2F1dG8nCiBCT09UUFJPVE89J3N0YXRpYycKIEJSSURHRT0neWVzJwogQlJJREdF
X1BPUlRTPSdldGgwJwogQlJJREdFX0ZPUldBUkRERUxBWT0nMCcKIEJSSURHRV9TVFA9J29mZicK
CiBOQU1FPSdNb3RoZXJib2FyZCcKIElQQUREUj0nMTkyLjE2OC4xLjMyLzI0JwogQlJPQURDQVNU
PScnCiBSRU1PVEVfSVBBRERSPScnCiBORVRXT1JLPScnCiBNVFU9JycKIEVUSFRPT0xfT1BUSU9O
Uz0nJwogVVNFUkNPTlRST0w9J25vJwogTk1fQ09OVFJPTExFRD0nbm8nCgpjYXQgL2V0Yy9zeXNj
b25maWcvbmV0d29yay9pZmNmZy1ldGgwCiBTVEFSVE1PREU9J21hbnVhbCcKIEJPT1RQUk9UTz0n
bm9uZScKIEJSSURHRT0nbm8nCgpUaGUgR3Vlc3QgY2ZnIGZpbGUgSSdtIHVzaW5nIGZvciB0ZXN0
aW5nIGlzOgoKY2F0IHRlc3QuY2ZnCiBuYW1lPSd0ZXN0JwogYnVpbGRlcj0nbGludXgnCiBib290
bG9hZGVyPScvdXNyL2Jpbi9weWdydWInCiBkaXNrPVsncGh5Oi9kZXYvWGVuVm9scy90ZXN0LHh2
ZGEsdyddCiB2aWY9W21hYz0wMDoxNjozZToxMjozNDowMSwgYnJpZGdlPWJyMCAgLCB2aWZuYW1l
PXZpZkJSJ10KIHZmYj1bICd0eXBlPXZuYywgdm5jZGlzcGxheT0xLCB2bmNsaXN0ZW49MTI3LjAu
MC4xJ10KIGV4dHJhPSd0ZXh0bW9kZT0xIHhlbmNvbnM9eHZjMCBub2lycWRlYnVnJwogb25fc2h1
dGRvd249J2Rlc3Ryb3knCiBvbl9yZWJvb3Q9J3Jlc3RhcnQnCiBvbl9jcmFzaD0nZGVzdHJveScK
IHZjcHVzPTIKIG1heG1lbT0yMDQ4CiBtZW1vcnk9MjA0OAoKV2l0aCBhIGNsZWFuLWJvb3RlZCBI
b3N0IGFuZCBubyBsYXVuY2hlZCBHdWVzdHMsCgp4bCBsaXN0CiBOYW1lICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIElEICAgTWVtIFZDUFVzICAgICAgU3RhdGUgIAogVGlt
ZShzKQogRG9tYWluLTAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgMTAx
MCAgICAgNCAgICAgci0tLS0tICAKICAgIDg2LjMKCnhsIGNyZWF0ZSAtYyB0ZXN0LmNmZwoJICAg
IHB5R1JVQiAgdmVyc2lvbiAwLjYKCSDilIzilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilJAKCSDilIIgWGVuNCAxMi4xIERvbVUgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoJICAgICAgICAgIOKUggoJIOKUgiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCgkg
ICAgICAgICAg4pSCCgkg4pSCICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAKCSAgICAgICAgICDilIIKCSDilIIgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoJICAgICAg
ICAgIOKUggoJIOKUgiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgCgkgICAgICAgICAg4pSCCgkg4pSCICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKCSAgICAgICAgICDi
lIIKCSDilIIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIAoJICAgICAgICAgIOKUggoJIOKUgiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCgkgICAgICAgICAg4pSCCgkg
4pSU4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSYCgkgICAg
IFVzZSB0aGUgXiBhbmQgdiBrZXlzIHRvIHNlbGVjdCB3aGljaCBlbnRyeSBpcyBoaWdobGlnaHRl
ZC4KCSAgICAgUHJlc3MgZW50ZXIgdG8gYm9vdCB0aGUgc2VsZWN0ZWQgT1MsICdlJyB0byBlZGl0
IHRoZQoJICAgICBjb21tYW5kcyBiZWZvcmUgYm9vdGluZywgJ2EnIHRvIG1vZGlmeSB0aGUga2Vy
bmVsIGFyZ3VtZW50cwoJICAgICBiZWZvcmUgYm9vdGluZywgb3IgJ2MnIGZvciBhIGNvbW1hbmQg
bGluZS4KCgkgICAgIFdpbGwgYm9vdCBzZWxlY3RlZCBlbnRyeSBpbiAgMSBzZWNvbmRzCgoKCURh
ZW1vbiBydW5uaW5nIHdpdGggUElEIDY3NzkKCkkgZ2V0IG5vIG90aGVyIG91dHB1dCBoZXJlICh3
aHkgbm90Pykgb24gdGhlIGNvbnNvbGUgZm9yIGFib3V0IDMwCnNlY29uZHMuIFRoZW4ganVzdCwK
CiBXZWxjb21lIHRvIG9wZW5TVVNFIDEyLjEgIkFzcGFyYWd1cyIgLSBLZXJuZWwgMy4xLjAtMS4y
LXhlbiAoeHZjMCkuCgogdGVzdHNlcnZlciBsb2dpbjoKCgpUaGUgb3V0cHV0IG9mICd0YWlsIC1m
IC92YXIvbG9nL21lc3NhZ2VzIC92YXIvbG9nL3hlbi8qbG9nJyBpcyBqdXN0CgoJPT0+IC92YXIv
bG9nL21lc3NhZ2VzIDw9PQoJSmFuIDIxIDEwOjQwOjM5IHRlc3RzZXJ2ZXIgbG9nZ2VyOiAvZXRj
L3hlbi9zY3JpcHRzL2Jsb2NrOiBhZGQKCVhFTkJVU19QQVRIPWJhY2tlbmQvdmJkLzUvNTE3MTIK
CUphbiAyMSAxMDo0MDozOSB0ZXN0c2VydmVyIGxvZ2dlcjogL2V0Yy94ZW4vc2NyaXB0cy9ibG9j
azogYWRkCglYRU5CVVNfUEFUSD1iYWNrZW5kL3ZiZC81LzUxNzI4CglKYW4gMjEgMTA6NDA6Mzkg
dGVzdHNlcnZlciBsb2dnZXI6IC9ldGMveGVuL3NjcmlwdHMvYmxvY2s6IGFkZAoJWEVOQlVTX1BB
VEg9YmFja2VuZC92YmQvNS81MTc0NAoJSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIgbG9nZ2Vy
OiAvZXRjL3hlbi9zY3JpcHRzL3ZpZi1icmlkZ2U6CglvbmxpbmUgdHlwZV9pZj12aWYgWEVOQlVT
X1BBVEg9YmFja2VuZC92aWYvNS8wCglKYW4gMjEgMTA6NDA6NDAgdGVzdHNlcnZlciBsb2dnZXI6
IC9ldGMveGVuL3NjcmlwdHMvdmlmLWJyaWRnZToKCU5vIGRldmljZSBkZXRhaWxzIGluIGJhY2tl
bmQvdmlmLzUvMCwgZXhpdGluZy4KCUphbiAyMSAxMDo0MDo0MCB0ZXN0c2VydmVyIGxvZ2dlcjog
L2V0Yy94ZW4vc2NyaXB0cy92aWYtYnJpZGdlOgoJb25saW5lIFhFTkJVU19QQVRIPWJhY2tlbmQv
dmlmLzUvMAoJSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIgbG9nZ2VyOiAvZXRjL3hlbi9zY3Jp
cHRzL3ZpZi1icmlkZ2U6CglObyBkZXZpY2UgZGV0YWlscyBpbiBiYWNrZW5kL3ZpZi81LzAsIGV4
aXRpbmcuCglKYW4gMjEgMTA6NDA6NDAgdGVzdHNlcnZlciBrZXJuZWw6IFsgMjcxMS45NTE4MjJd
IGJsa2JhY2s6CglyaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEyLCBwcm90b2NvbCAxICh4ODZf
NjQtYWJpKQoJSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIga2VybmVsOiBbIDI3MTIuMDE1NzMx
XSBibGtiYWNrOgoJcmluZy1yZWYgOSwgZXZlbnQtY2hhbm5lbCAxMywgcHJvdG9jb2wgMSAoeDg2
XzY0LWFiaSkKCUphbiAyMSAxMDo0MDo0MCB0ZXN0c2VydmVyIGtlcm5lbDogWyAyNzEyLjA2NjQ2
N10gYmxrYmFjazoKCXJpbmctcmVmIDEwLCBldmVudC1jaGFubmVsIDE0LCBwcm90b2NvbCAxICh4
ODZfNjQtYWJpKQoKCkkgY2FuIGxvZ2luIHRvIHRoZSBndWVzdCBhdCB0aGUgY29uc29sZSBhbmQg
dGhlIEd1ZXN0J3MgbmV0d29ya2luZyBsb29rcwpsaWtlIGl0J3MgcmVjb2duaXplZCBPSy4KCmRt
ZXNnIHwgZ3JlcCBldGgKWyAgICAwLjg5NjU5N10gbmV0ZnJvbnQ6IEluaXRpYWxpc2luZyB2aXJ0
dWFsIGV0aGVybmV0IGRyaXZlci4KCmh3aW5mbyAtLW5ldHdvcmsKMDU6IE5vbmUgMDAuMDogMTA3
MDAgTG9vcGJhY2sKICBbQ3JlYXRlZCBhdCBuZXQuMTI0XQogIFVuaXF1ZSBJRDogWnNCUy5HUU54
N0w0dVBOQQogIFN5c0ZTIElEOiAvY2xhc3MvbmV0L2xvCiAgSGFyZHdhcmUgQ2xhc3M6IG5ldHdv
cmsgaW50ZXJmYWNlCiAgTW9kZWw6ICJMb29wYmFjayBuZXR3b3JrIGludGVyZmFjZSIKICBEZXZp
Y2UgRmlsZTogbG8KICBMaW5rIGRldGVjdGVkOiB5ZXMKICBDb25maWcgU3RhdHVzOiBjZmc9bmV3
LCBhdmFpbD15ZXMsIG5lZWQ9bm8sIGFjdGl2ZT11bmtub3duCgowNjogTm9uZSAwMC4wOiAxMDcw
MSBFdGhlcm5ldAogIFtDcmVhdGVkIGF0IG5ldC4xMjRdCiAgVW5pcXVlIElEOiB1c0RXLm5kcGV1
Y2F4NlYxCiAgUGFyZW50IElEOiAranNnLlNkK3lrZnl2bEs0CiAgU3lzRlMgSUQ6IC9jbGFzcy9u
ZXQvZXRoMAogIFN5c0ZTIERldmljZSBMaW5rOiAvZGV2aWNlcy94ZW4vdmlmLTAKICBIYXJkd2Fy
ZSBDbGFzczogbmV0d29yayBpbnRlcmZhY2UKICBNb2RlbDogIkV0aGVybmV0IG5ldHdvcmsgaW50
ZXJmYWNlIgogIERyaXZlcjogInZpZiIKICBEcml2ZXIgTW9kdWxlczogInhlbm5ldCIKICBEZXZp
Y2UgRmlsZTogZXRoMAogIEhXIEFkZHJlc3M6IDAwOjE2OjNlOjEyOjM0OjAxCiAgTGluayBkZXRl
Y3RlZDogeWVzCiAgQ29uZmlnIFN0YXR1czogY2ZnPW5ldywgYXZhaWw9eWVzLCBuZWVkPW5vLCBh
Y3RpdmU9dW5rbm93bgogIEF0dGFjaGVkIHRvOiAjNCAoRXRoZXJuZXQgY29udHJvbGxlcikKClRo
ZSBHdWVzdCdzIG5ldHdvcmsgcm91dGVzIGxvb2sgT0suCgpyb3V0ZQpLZXJuZWwgSVAgcm91dGlu
ZyB0YWJsZQpEZXN0aW5hdGlvbiAgICAgR2F0ZXdheSAgICAgICAgIEdlbm1hc2sgICAgICAgICBG
bGFncyBNZXRyaWMgUmVmICAgIFVzZQpJZmFjZQpkZWZhdWx0ICAgICAgICAgMTkyLjE2OC4xLjEg
ICAgIDAuMC4wLjAgICAgICAgICBVRyAgICAwICAgICAgMCAgICAgICAgMApldGgwCmxvb3BiYWNr
ICAgICAgICAqICAgICAgICAgICAgICAgMjU1LjAuMC4wICAgICAgIFUgICAgIDAgICAgICAwICAg
ICAgICAwCmxvCmxpbmstbG9jYWwgICAgICAqICAgICAgICAgICAgICAgMjU1LjI1NS4wLjAgICAg
IFUgICAgIDAgICAgICAwICAgICAgICAwCmV0aDAKMTkyLjE2OC4xLjAgICAgICogICAgICAgICAg
ICAgICAyNTUuMjU1LjI1NS4wICAgVSAgICAgMCAgICAgIDAgICAgICAgIDAKZXRoMAoKQnV0IHdo
ZW4gSSB0cnkgdG8gcGluZyBhbnl3aGVyZSBvZmYgdGhlIEd1ZXN0IEkgZ2V0IEhvc3RVbnJlYWNo
YWJsZQplcnJvcnMuCgpwaW5nIDE5Mi4xNjguMS4xClBJTkcgMTkyLjE2OC4xLjEgKDE5Mi4xNjgu
MS4xKSA1Nig4NCkgYnl0ZXMgb2YgZGF0YS4KRnJvbSAxOTIuMTY4LjEuMzIgaWNtcF9zZXE9MSBE
ZXN0aW5hdGlvbiBIb3N0IFVucmVhY2hhYmxlCkZyb20gMTkyLjE2OC4xLjMyIGljbXBfc2VxPTIg
RGVzdGluYXRpb24gSG9zdCBVbnJlYWNoYWJsZQpGcm9tIDE5Mi4xNjguMS4zMiBpY21wX3NlcT0z
IERlc3RpbmF0aW9uIEhvc3QgVW5yZWFjaGFibGUKZXRjIGV0YwoKSXQgZmVlbHMgbGlrZSBJJ20g
cHJldHR5IGNsb3NlIHRvIGdldHRpbmcgdGhpcyB3b3JraW5nLiAgQW0gSSBzdGlsbAptaXNzaW5n
IHNvbWUgcGFydCBvZiB0aGUgY29uZmlndXJhdGlvbiBjaGFuZ2VzIG5lZWRlZCBmb3IgdXNpbmcg
dGhlIHhsCnRvb2xzdGFjaz8KClJlZ2FyZHMsCgpFcmluCgpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZl
bEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZl
bAo=

From xen-devel-bounces@lists.xensource.com Sat Jan 21 22:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 22:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RojVz-0006cv-2B; Sat, 21 Jan 2012 22:34: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 1RojVx-0006cq-4l
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 22:34:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327185257!11847809!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzc5OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31967 invoked from network); 21 Jan 2012 22:34: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;
	21 Jan 2012 22:34:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,548,1320624000"; d="scan'208";a="10192625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jan 2012 22:34:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 21 Jan 2012 22:34: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 1RojVn-0001uG-7G;
	Sat, 21 Jan 2012 22:34:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RojVn-0007Bo-6W;
	Sat, 21 Jan 2012 22:34:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11164-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Jan 2012 22:34:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11164: 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 11164 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11164/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   12 guest-saverestore.2       fail REGR. vs. 11028
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 11028

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 11028
 test-i386-i386-xl-win         7 windows-install              fail   like 10932

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  80fdf2182bc6
baseline version:
 xen                  ef8374dfe9bf

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-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.

------------------------------------------------------------
changeset:   24533:80fdf2182bc6
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Jan 21 17:15:40 2012 +0000
    
    tools/libvchan: Beef up the CPU barriers in libvchan.
    
    Although they were sufficient for x86, they weren't safe more generally.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24532:475d73479663
user:        Keir Fraser <keir@xen.org>
date:        Sat Jan 21 17:14:37 2012 +0000
    
    libxc: Update rmb/wmb for x86.
    
    Only the compiler needs to see the barriers; not the CPU.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24531:7f71f0b4b8e6
user:        Keir Fraser <keir@xen.org>
date:        Sat Jan 21 16:47:00 2012 +0000
    
    libxl: libxl_qmp.c should use libxl's own list macros, since they
    exist. Also, older Linux versions do not have SIMPLEQ macros in
    sys/queue.h.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24530:ef8374dfe9bf
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 18:17:59 2012 +0000
    
    x86/hvm: Fix earlier hvm_load_cpu_ctxt() breakage.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Sat Jan 21 22:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 22:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RojVz-0006cv-2B; Sat, 21 Jan 2012 22:34: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 1RojVx-0006cq-4l
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 22:34:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327185257!11847809!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4Mzc5OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31967 invoked from network); 21 Jan 2012 22:34: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;
	21 Jan 2012 22:34:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,548,1320624000"; d="scan'208";a="10192625"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	21 Jan 2012 22:34:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 21 Jan 2012 22:34: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 1RojVn-0001uG-7G;
	Sat, 21 Jan 2012 22:34:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RojVn-0007Bo-6W;
	Sat, 21 Jan 2012 22:34:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11164-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 21 Jan 2012 22:34:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11164: 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 11164 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11164/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   12 guest-saverestore.2       fail REGR. vs. 11028
 test-amd64-amd64-xl-winxpsp3  7 windows-install           fail REGR. vs. 11028

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 11028
 test-i386-i386-xl-win         7 windows-install              fail   like 10932

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  80fdf2182bc6
baseline version:
 xen                  ef8374dfe9bf

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-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.

------------------------------------------------------------
changeset:   24533:80fdf2182bc6
tag:         tip
user:        Keir Fraser <keir@xen.org>
date:        Sat Jan 21 17:15:40 2012 +0000
    
    tools/libvchan: Beef up the CPU barriers in libvchan.
    
    Although they were sufficient for x86, they weren't safe more generally.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24532:475d73479663
user:        Keir Fraser <keir@xen.org>
date:        Sat Jan 21 17:14:37 2012 +0000
    
    libxc: Update rmb/wmb for x86.
    
    Only the compiler needs to see the barriers; not the CPU.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24531:7f71f0b4b8e6
user:        Keir Fraser <keir@xen.org>
date:        Sat Jan 21 16:47:00 2012 +0000
    
    libxl: libxl_qmp.c should use libxl's own list macros, since they
    exist. Also, older Linux versions do not have SIMPLEQ macros in
    sys/queue.h.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24530:ef8374dfe9bf
user:        Keir Fraser <keir@xen.org>
date:        Fri Jan 20 18:17:59 2012 +0000
    
    x86/hvm: Fix earlier hvm_load_cpu_ctxt() breakage.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Sat Jan 21 22:58:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 22:58:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RojsL-0006r5-6C; Sat, 21 Jan 2012 22:57: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 1RojsJ-0006r0-EE
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 22:57:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327186642!10110735!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 10976 invoked from network); 21 Jan 2012 22:57:24 -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 Jan 2012 22:57:24 -0000
Received: by pbdv4 with SMTP id v4so11119734pbd.30
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 14:57: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=qIY7rSdn4uWPNI/sK2CpSSDjEyS0n8jJsF/Og+8NCKs=;
	b=qE3d5edyk8p4O06eb087C+rK8Oku4696xPHDIjtLSNHBRKC8fDGoyFeYVPMU6BU4wr
	0HONQsqkthlcm/BvUAla9o6G6gokxOiW73zndCWk8hIo5YgKIOBMnzajcOhW19dLkr82
	lp1uy8IcdmL1mAx78i2ITNw9R8ayhaIMRytQ4=
MIME-Version: 1.0
Received: by 10.68.120.72 with SMTP id la8mr8309487pbb.56.1327186641985; Sat,
	21 Jan 2012 14:57:21 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Sat, 21 Jan 2012 14:57:21 -0800 (PST)
In-Reply-To: <1327176409.25269.140661026313477@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
Date: Sat, 21 Jan 2012 23:57:21 +0100
X-Google-Sender-Auth: fFrSPOWzYW0Fx5tb_GgrxPg5C9c
Message-ID: <CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: erin.balid@inoutbox.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzIxICA8ZXJpbi5iYWxpZEBpbm91dGJveC5jb20+Ogo+IEhpIEFsbC4KPgo+IEkgcG9z
dGVkIHRoaXMgb3ZlciBvbiB0aGUgT3BlblNVU0UgVmlydHVhbCBtYWlsaW5nIGxpc3QsIHNpbmNl
IEkgdXNlCj4gdGhhdCBkaXN0cm8uIMKgQnV0IEkgZm91bmQgb24gdGhlIFhlbiB3aWtpIHNpdGUs
Cj4KPiDCoGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9NaWdyYXRpb25HdWlkZVRvWGVuNC4xJTJC
I1Rvb2xzdGFja191cGdyYWRlX25vdGVzCj4KPiBzbyBJIGd1ZXNzIHdlIHNob3VsZCBwb3N0IHht
LT54bCBtaWdyYXRpb24gY29uZmlndXJhdGlvbiBwcm9ibGVtcyBoZXJlCj4gdG9vLCBvciBpbnN0
ZWFkLgo+Cj4KPiBJIGluaGVyaXRlZCBhbiBPcGVuU1VTRSBWZXJzaW9uIDExLjQgWGVuIGhvc3Qg
bWFjaGluZSBoZXJlIGF0IHdvcmsuCj4KPiBXaXRob3V0IHRvbyBtdWNoIHRyb3VibGUgSSBmaW5p
c2hlZCB1cGdyYWRpbmcgaXQgdG8gVmVyc2lvbiAxMi4xLgo+Cj4gVGhlIG9sZCBzZXR1cCB3YXMg
cnVubmluZyB1c2luZyB0aGUgWGVuICJ4bSIgdG9vbHN0YWNrIGFuZCB3b3JrcyBsaWtlCj4geW91
J2QgZXhwZWN0LiDCoFRoZSBuZXcgc2V0dXAgd29ya3Mgb2sgaWYgSSB1c2UgdGhlICJ4bSIgc3Rh
Y2sgYXMgd2VsbC4KPgo+IEkgbGVhcm5lZCB0aGF0IHdlIHNob3VsZCBtb3ZlIHRvIHRoZSAieGwi
IHRvb2xzdGFjay4gwqBJJ20gdHJ5aW5nIHRvIGRvCj4gdGhhdCBub3cgYW5kIGhhdmluZyBzb21l
IHByb2JsZW1zIHdpdGggbmV0d29ya2luZywgYnV0IG9ubHkgd2l0aCB0aGUgeGwKPiBhcHByb2Fj
aC4KPgo+IEkndmUgYmVlbiBydW5uaW5nIHVwIHRvIGRhdGUgWGVuIGZvciBhd2hpbGUuCj4KPiBy
cG0gLXFhIHwgZ3JlcCAtaSB4ZW4KPiDCoHhlbi10b29scy00LjEuMl8xMS0xNjQuNS54ODZfNjQK
PiDCoHhlbi1kb2MtaHRtbC00LjEuMl8xMS0xNjQuNS54ODZfNjQKPiDCoHhlbi1saWJzLTQuMS4y
XzExLTE2NC41Lng4Nl82NAo+IMKgeGVuLTQuMS4yXzExLTE2NC41Lng4Nl82NAo+IMKgcGF0dGVy
bnMtb3BlblNVU0UteGVuX3NlcnZlci0xMi4xLTI1LjIxLjEueDg2XzY0Cj4gwqB4ZW4tZGV2ZWwt
NC4xLjJfMTEtMTY0LjUueDg2XzY0Cj4gwqB4ZW4tZG9jLXBkZi00LjEuMl8xMS0xNjQuNS54ODZf
NjQKPiDCoGtlcm5lbC14ZW4tZGV2ZWwtMy4xLjAtMS4yLjEueDg2XzY0Cj4gwqBrZXJuZWwteGVu
LTMuMS4wLTEuMi4xLng4Nl82NAo+Cj4gSSBhbHJlYWR5IHNldHVwIHRoZSBuZXR3b3JraW5nIG9u
IHRoZSBIb3N0IHRvIHVzZSBPcGVuU1VTRQo+IGNvbmZpZ3VyYXRpb24uCj4KPiBicmN0bCBzaG93
Cj4gwqBicmlkZ2UgbmFtZSDCoCDCoCBicmlkZ2UgaWQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU1RQ
IGVuYWJsZWQgwqAgwqAgaW50ZXJmYWNlcwo+IMKgYnIwIMKgIMKgIMKgIMKgIMKgIMKgIDgwMDAu
MDA1MjM1MWQ1MzM3IMKgIMKgIMKgIG5vIMKgIMKgIMKgIMKgIMKgIMKgIMKgZXRoMAo+Cj4gY2F0
IC9ldGMvc3lzY29uZmlnL25ldHdvcmsvaWZjZmctYnIwCj4gwqBTVEFSVE1PREU9J2F1dG8nCj4g
wqBCT09UUFJPVE89J3N0YXRpYycKPiDCoEJSSURHRT0neWVzJwo+IMKgQlJJREdFX1BPUlRTPSdl
dGgwJwo+IMKgQlJJREdFX0ZPUldBUkRERUxBWT0nMCcKPiDCoEJSSURHRV9TVFA9J29mZicKPgo+
IMKgTkFNRT0nTW90aGVyYm9hcmQnCj4gwqBJUEFERFI9JzE5Mi4xNjguMS4zMi8yNCcKPiDCoEJS
T0FEQ0FTVD0nJwo+IMKgUkVNT1RFX0lQQUREUj0nJwo+IMKgTkVUV09SSz0nJwo+IMKgTVRVPScn
Cj4gwqBFVEhUT09MX09QVElPTlM9JycKPiDCoFVTRVJDT05UUk9MPSdubycKPiDCoE5NX0NPTlRS
T0xMRUQ9J25vJwo+Cj4gY2F0IC9ldGMvc3lzY29uZmlnL25ldHdvcmsvaWZjZmctZXRoMAo+IMKg
U1RBUlRNT0RFPSdtYW51YWwnCj4gwqBCT09UUFJPVE89J25vbmUnCj4gwqBCUklER0U9J25vJwo+
Cj4gVGhlIEd1ZXN0IGNmZyBmaWxlIEknbSB1c2luZyBmb3IgdGVzdGluZyBpczoKPgo+IGNhdCB0
ZXN0LmNmZwo+IMKgbmFtZT0ndGVzdCcKPiDCoGJ1aWxkZXI9J2xpbnV4Jwo+IMKgYm9vdGxvYWRl
cj0nL3Vzci9iaW4vcHlncnViJwo+IMKgZGlzaz1bJ3BoeTovZGV2L1hlblZvbHMvdGVzdCx4dmRh
LHcnXQo+IMKgdmlmPVttYWM9MDA6MTY6M2U6MTI6MzQ6MDEsIGJyaWRnZT1icjAgwqAsIHZpZm5h
bWU9dmlmQlInXQoKVGhlIHhsIHRvb2xzdGFjayBwcmVzZW50IGluIHZlcnNpb24gNC4xLjIgZG9l
c24ndCBzdXBwb3J0IHZpZm5hbWVbMF0KKG5ld2VyIHZlcnNpb25zIGRvKSwgc28gSSB0aGluayBp
ZiB5b3UgcmVtb3ZlIHRoYXQgaXQgc2hvdWxkIGJlIG9rLgoKWzBdIGh0dHA6Ly9saXN0cy54ZW4u
b3JnL2FyY2hpdmVzL2h0bWwveGVuLXVzZXJzLzIwMTEtMTIvbXNnMDAyMjUuaHRtbAoKPiDCoHZm
Yj1bICd0eXBlPXZuYywgdm5jZGlzcGxheT0xLCB2bmNsaXN0ZW49MTI3LjAuMC4xJ10KPiDCoGV4
dHJhPSd0ZXh0bW9kZT0xIHhlbmNvbnM9eHZjMCBub2lycWRlYnVnJwo+IMKgb25fc2h1dGRvd249
J2Rlc3Ryb3knCj4gwqBvbl9yZWJvb3Q9J3Jlc3RhcnQnCj4gwqBvbl9jcmFzaD0nZGVzdHJveScK
PiDCoHZjcHVzPTIKPiDCoG1heG1lbT0yMDQ4Cj4gwqBtZW1vcnk9MjA0OAo+Cj4gV2l0aCBhIGNs
ZWFuLWJvb3RlZCBIb3N0IGFuZCBubyBsYXVuY2hlZCBHdWVzdHMsCj4KPiB4bCBsaXN0Cj4gwqBO
YW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgSUQgwqAgTWVtIFZDUFVzIMKgIMKgIMKgU3RhdGUKPiDCoFRpbWUocykKPiDCoERvbWFp
bi0wIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IDAgwqAxMDEwIMKgIMKgIDQgwqAgwqAgci0tLS0tCj4gwqAgwqA4Ni4zCj4KPiB4bCBjcmVhdGUg
LWMgdGVzdC5jZmcKPiDCoCDCoCDCoCDCoCDCoCDCoHB5R1JVQiDCoHZlcnNpb24gMC42Cj4gwqAg
wqAgwqAgwqAg4pSM4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSQCj4gwqAgwqAgwqAgwqAg4pSCIFhlbjQgMTIuMSBEb21VCj4gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqDilIIKPiDCoCDCoCDCoCDCoCDilIIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oOKUggo+IMKgIMKgIMKgIMKgIOKUggo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg4pSCCj4g
wqAgwqAgwqAgwqAg4pSCCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDilIIKPiDCoCDCoCDC
oCDCoCDilIIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoOKUggo+IMKgIMKgIMKgIMKgIOKU
ggo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg4pSCCj4gwqAgwqAgwqAgwqAg4pSCCj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDilIIKPiDCoCDCoCDCoCDCoCDilIIKPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoOKUggo+IMKgIMKgIMKgIMKgIOKUlOKUgOKUgOKUgOKUgOKUgOKUgOKU
gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU
gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU
gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU
gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUmAo+IMKgIMKgIMKgIMKgIMKgIMKgIFVzZSB0aGUg
XiBhbmQgdiBrZXlzIHRvIHNlbGVjdCB3aGljaCBlbnRyeSBpcyBoaWdobGlnaHRlZC4KPiDCoCDC
oCDCoCDCoCDCoCDCoCBQcmVzcyBlbnRlciB0byBib290IHRoZSBzZWxlY3RlZCBPUywgJ2UnIHRv
IGVkaXQgdGhlCj4gwqAgwqAgwqAgwqAgwqAgwqAgY29tbWFuZHMgYmVmb3JlIGJvb3RpbmcsICdh
JyB0byBtb2RpZnkgdGhlIGtlcm5lbCBhcmd1bWVudHMKPiDCoCDCoCDCoCDCoCDCoCDCoCBiZWZv
cmUgYm9vdGluZywgb3IgJ2MnIGZvciBhIGNvbW1hbmQgbGluZS4KPgo+IMKgIMKgIMKgIMKgIMKg
IMKgIFdpbGwgYm9vdCBzZWxlY3RlZCBlbnRyeSBpbiDCoDEgc2Vjb25kcwo+Cj4KPiDCoCDCoCDC
oCDCoERhZW1vbiBydW5uaW5nIHdpdGggUElEIDY3NzkKPgo+IEkgZ2V0IG5vIG90aGVyIG91dHB1
dCBoZXJlICh3aHkgbm90Pykgb24gdGhlIGNvbnNvbGUgZm9yIGFib3V0IDMwCj4gc2Vjb25kcy4g
VGhlbiBqdXN0LAo+Cj4gwqBXZWxjb21lIHRvIG9wZW5TVVNFIDEyLjEgIkFzcGFyYWd1cyIgLSBL
ZXJuZWwgMy4xLjAtMS4yLXhlbiAoeHZjMCkuCj4KPiDCoHRlc3RzZXJ2ZXIgbG9naW46Cj4KPgo+
IFRoZSBvdXRwdXQgb2YgJ3RhaWwgLWYgL3Zhci9sb2cvbWVzc2FnZXMgL3Zhci9sb2cveGVuLyps
b2cnIGlzIGp1c3QKPgo+IMKgIMKgIMKgIMKgPT0+IC92YXIvbG9nL21lc3NhZ2VzIDw9PQo+IMKg
IMKgIMKgIMKgSmFuIDIxIDEwOjQwOjM5IHRlc3RzZXJ2ZXIgbG9nZ2VyOiAvZXRjL3hlbi9zY3Jp
cHRzL2Jsb2NrOiBhZGQKPiDCoCDCoCDCoCDCoFhFTkJVU19QQVRIPWJhY2tlbmQvdmJkLzUvNTE3
MTIKPiDCoCDCoCDCoCDCoEphbiAyMSAxMDo0MDozOSB0ZXN0c2VydmVyIGxvZ2dlcjogL2V0Yy94
ZW4vc2NyaXB0cy9ibG9jazogYWRkCj4gwqAgwqAgwqAgwqBYRU5CVVNfUEFUSD1iYWNrZW5kL3Zi
ZC81LzUxNzI4Cj4gwqAgwqAgwqAgwqBKYW4gMjEgMTA6NDA6MzkgdGVzdHNlcnZlciBsb2dnZXI6
IC9ldGMveGVuL3NjcmlwdHMvYmxvY2s6IGFkZAo+IMKgIMKgIMKgIMKgWEVOQlVTX1BBVEg9YmFj
a2VuZC92YmQvNS81MTc0NAo+IMKgIMKgIMKgIMKgSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIg
bG9nZ2VyOiAvZXRjL3hlbi9zY3JpcHRzL3ZpZi1icmlkZ2U6Cj4gwqAgwqAgwqAgwqBvbmxpbmUg
dHlwZV9pZj12aWYgWEVOQlVTX1BBVEg9YmFja2VuZC92aWYvNS8wCj4gwqAgwqAgwqAgwqBKYW4g
MjEgMTA6NDA6NDAgdGVzdHNlcnZlciBsb2dnZXI6IC9ldGMveGVuL3NjcmlwdHMvdmlmLWJyaWRn
ZToKPiDCoCDCoCDCoCDCoE5vIGRldmljZSBkZXRhaWxzIGluIGJhY2tlbmQvdmlmLzUvMCwgZXhp
dGluZy4KPiDCoCDCoCDCoCDCoEphbiAyMSAxMDo0MDo0MCB0ZXN0c2VydmVyIGxvZ2dlcjogL2V0
Yy94ZW4vc2NyaXB0cy92aWYtYnJpZGdlOgo+IMKgIMKgIMKgIMKgb25saW5lIFhFTkJVU19QQVRI
PWJhY2tlbmQvdmlmLzUvMAo+IMKgIMKgIMKgIMKgSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIg
bG9nZ2VyOiAvZXRjL3hlbi9zY3JpcHRzL3ZpZi1icmlkZ2U6Cj4gwqAgwqAgwqAgwqBObyBkZXZp
Y2UgZGV0YWlscyBpbiBiYWNrZW5kL3ZpZi81LzAsIGV4aXRpbmcuCj4gwqAgwqAgwqAgwqBKYW4g
MjEgMTA6NDA6NDAgdGVzdHNlcnZlciBrZXJuZWw6IFsgMjcxMS45NTE4MjJdIGJsa2JhY2s6Cj4g
wqAgwqAgwqAgwqByaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEyLCBwcm90b2NvbCAxICh4ODZf
NjQtYWJpKQo+IMKgIMKgIMKgIMKgSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIga2VybmVsOiBb
IDI3MTIuMDE1NzMxXSBibGtiYWNrOgo+IMKgIMKgIMKgIMKgcmluZy1yZWYgOSwgZXZlbnQtY2hh
bm5lbCAxMywgcHJvdG9jb2wgMSAoeDg2XzY0LWFiaSkKPiDCoCDCoCDCoCDCoEphbiAyMSAxMDo0
MDo0MCB0ZXN0c2VydmVyIGtlcm5lbDogWyAyNzEyLjA2NjQ2N10gYmxrYmFjazoKPiDCoCDCoCDC
oCDCoHJpbmctcmVmIDEwLCBldmVudC1jaGFubmVsIDE0LCBwcm90b2NvbCAxICh4ODZfNjQtYWJp
KQo+Cj4KPiBJIGNhbiBsb2dpbiB0byB0aGUgZ3Vlc3QgYXQgdGhlIGNvbnNvbGUgYW5kIHRoZSBH
dWVzdCdzIG5ldHdvcmtpbmcgbG9va3MKPiBsaWtlIGl0J3MgcmVjb2duaXplZCBPSy4KPgo+IGRt
ZXNnIHwgZ3JlcCBldGgKPiBbIMKgIMKgMC44OTY1OTddIG5ldGZyb250OiBJbml0aWFsaXNpbmcg
dmlydHVhbCBldGhlcm5ldCBkcml2ZXIuCj4KPiBod2luZm8gLS1uZXR3b3JrCj4gMDU6IE5vbmUg
MDAuMDogMTA3MDAgTG9vcGJhY2sKPiDCoFtDcmVhdGVkIGF0IG5ldC4xMjRdCj4gwqBVbmlxdWUg
SUQ6IFpzQlMuR1FOeDdMNHVQTkEKPiDCoFN5c0ZTIElEOiAvY2xhc3MvbmV0L2xvCj4gwqBIYXJk
d2FyZSBDbGFzczogbmV0d29yayBpbnRlcmZhY2UKPiDCoE1vZGVsOiAiTG9vcGJhY2sgbmV0d29y
ayBpbnRlcmZhY2UiCj4gwqBEZXZpY2UgRmlsZTogbG8KPiDCoExpbmsgZGV0ZWN0ZWQ6IHllcwo+
IMKgQ29uZmlnIFN0YXR1czogY2ZnPW5ldywgYXZhaWw9eWVzLCBuZWVkPW5vLCBhY3RpdmU9dW5r
bm93bgo+Cj4gMDY6IE5vbmUgMDAuMDogMTA3MDEgRXRoZXJuZXQKPiDCoFtDcmVhdGVkIGF0IG5l
dC4xMjRdCj4gwqBVbmlxdWUgSUQ6IHVzRFcubmRwZXVjYXg2VjEKPiDCoFBhcmVudCBJRDogK2pz
Zy5TZCt5a2Z5dmxLNAo+IMKgU3lzRlMgSUQ6IC9jbGFzcy9uZXQvZXRoMAo+IMKgU3lzRlMgRGV2
aWNlIExpbms6IC9kZXZpY2VzL3hlbi92aWYtMAo+IMKgSGFyZHdhcmUgQ2xhc3M6IG5ldHdvcmsg
aW50ZXJmYWNlCj4gwqBNb2RlbDogIkV0aGVybmV0IG5ldHdvcmsgaW50ZXJmYWNlIgo+IMKgRHJp
dmVyOiAidmlmIgo+IMKgRHJpdmVyIE1vZHVsZXM6ICJ4ZW5uZXQiCj4gwqBEZXZpY2UgRmlsZTog
ZXRoMAo+IMKgSFcgQWRkcmVzczogMDA6MTY6M2U6MTI6MzQ6MDEKPiDCoExpbmsgZGV0ZWN0ZWQ6
IHllcwo+IMKgQ29uZmlnIFN0YXR1czogY2ZnPW5ldywgYXZhaWw9eWVzLCBuZWVkPW5vLCBhY3Rp
dmU9dW5rbm93bgo+IMKgQXR0YWNoZWQgdG86ICM0IChFdGhlcm5ldCBjb250cm9sbGVyKQo+Cj4g
VGhlIEd1ZXN0J3MgbmV0d29yayByb3V0ZXMgbG9vayBPSy4KPgo+IHJvdXRlCj4gS2VybmVsIElQ
IHJvdXRpbmcgdGFibGUKPiBEZXN0aW5hdGlvbiDCoCDCoCBHYXRld2F5IMKgIMKgIMKgIMKgIEdl
bm1hc2sgwqAgwqAgwqAgwqAgRmxhZ3MgTWV0cmljIFJlZiDCoCDCoFVzZQo+IElmYWNlCj4gZGVm
YXVsdCDCoCDCoCDCoCDCoCAxOTIuMTY4LjEuMSDCoCDCoCAwLjAuMC4wIMKgIMKgIMKgIMKgIFVH
IMKgIMKgMCDCoCDCoCDCoDAgwqAgwqAgwqAgwqAwCj4gZXRoMAo+IGxvb3BiYWNrIMKgIMKgIMKg
IMKgKiDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyNTUuMC4wLjAgwqAgwqAgwqAgVSDCoCDCoCAwIMKg
IMKgIMKgMCDCoCDCoCDCoCDCoDAKPiBsbwo+IGxpbmstbG9jYWwgwqAgwqAgwqAqIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIDI1NS4yNTUuMC4wIMKgIMKgIFUgwqAgwqAgMCDCoCDCoCDCoDAgwqAgwqAg
wqAgwqAwCj4gZXRoMAo+IDE5Mi4xNjguMS4wIMKgIMKgICogwqAgwqAgwqAgwqAgwqAgwqAgwqAg
MjU1LjI1NS4yNTUuMCDCoCBVIMKgIMKgIDAgwqAgwqAgwqAwIMKgIMKgIMKgIMKgMAo+IGV0aDAK
Pgo+IEJ1dCB3aGVuIEkgdHJ5IHRvIHBpbmcgYW55d2hlcmUgb2ZmIHRoZSBHdWVzdCBJIGdldCBI
b3N0VW5yZWFjaGFibGUKPiBlcnJvcnMuCj4KPiBwaW5nIDE5Mi4xNjguMS4xCj4gUElORyAxOTIu
MTY4LjEuMSAoMTkyLjE2OC4xLjEpIDU2KDg0KSBieXRlcyBvZiBkYXRhLgo+IEZyb20gMTkyLjE2
OC4xLjMyIGljbXBfc2VxPTEgRGVzdGluYXRpb24gSG9zdCBVbnJlYWNoYWJsZQo+IEZyb20gMTky
LjE2OC4xLjMyIGljbXBfc2VxPTIgRGVzdGluYXRpb24gSG9zdCBVbnJlYWNoYWJsZQo+IEZyb20g
MTkyLjE2OC4xLjMyIGljbXBfc2VxPTMgRGVzdGluYXRpb24gSG9zdCBVbnJlYWNoYWJsZQo+IGV0
YyBldGMKPgo+IEl0IGZlZWxzIGxpa2UgSSdtIHByZXR0eSBjbG9zZSB0byBnZXR0aW5nIHRoaXMg
d29ya2luZy4gwqBBbSBJIHN0aWxsCj4gbWlzc2luZyBzb21lIHBhcnQgb2YgdGhlIGNvbmZpZ3Vy
YXRpb24gY2hhbmdlcyBuZWVkZWQgZm9yIHVzaW5nIHRoZSB4bAo+IHRvb2xzdGFjaz8KPgo+IFJl
Z2FyZHMsCj4KPiBFcmluCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbApfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Jan 21 22:58:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 22:58:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RojsL-0006r5-6C; Sat, 21 Jan 2012 22:57: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 1RojsJ-0006r0-EE
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 22:57:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327186642!10110735!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 10976 invoked from network); 21 Jan 2012 22:57:24 -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 Jan 2012 22:57:24 -0000
Received: by pbdv4 with SMTP id v4so11119734pbd.30
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 14:57: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=qIY7rSdn4uWPNI/sK2CpSSDjEyS0n8jJsF/Og+8NCKs=;
	b=qE3d5edyk8p4O06eb087C+rK8Oku4696xPHDIjtLSNHBRKC8fDGoyFeYVPMU6BU4wr
	0HONQsqkthlcm/BvUAla9o6G6gokxOiW73zndCWk8hIo5YgKIOBMnzajcOhW19dLkr82
	lp1uy8IcdmL1mAx78i2ITNw9R8ayhaIMRytQ4=
MIME-Version: 1.0
Received: by 10.68.120.72 with SMTP id la8mr8309487pbb.56.1327186641985; Sat,
	21 Jan 2012 14:57:21 -0800 (PST)
Received: by 10.142.178.12 with HTTP; Sat, 21 Jan 2012 14:57:21 -0800 (PST)
In-Reply-To: <1327176409.25269.140661026313477@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
Date: Sat, 21 Jan 2012 23:57:21 +0100
X-Google-Sender-Auth: fFrSPOWzYW0Fx5tb_GgrxPg5C9c
Message-ID: <CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: erin.balid@inoutbox.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzIxICA8ZXJpbi5iYWxpZEBpbm91dGJveC5jb20+Ogo+IEhpIEFsbC4KPgo+IEkgcG9z
dGVkIHRoaXMgb3ZlciBvbiB0aGUgT3BlblNVU0UgVmlydHVhbCBtYWlsaW5nIGxpc3QsIHNpbmNl
IEkgdXNlCj4gdGhhdCBkaXN0cm8uIMKgQnV0IEkgZm91bmQgb24gdGhlIFhlbiB3aWtpIHNpdGUs
Cj4KPiDCoGh0dHA6Ly93aWtpLnhlbi5vcmcvd2lraS9NaWdyYXRpb25HdWlkZVRvWGVuNC4xJTJC
I1Rvb2xzdGFja191cGdyYWRlX25vdGVzCj4KPiBzbyBJIGd1ZXNzIHdlIHNob3VsZCBwb3N0IHht
LT54bCBtaWdyYXRpb24gY29uZmlndXJhdGlvbiBwcm9ibGVtcyBoZXJlCj4gdG9vLCBvciBpbnN0
ZWFkLgo+Cj4KPiBJIGluaGVyaXRlZCBhbiBPcGVuU1VTRSBWZXJzaW9uIDExLjQgWGVuIGhvc3Qg
bWFjaGluZSBoZXJlIGF0IHdvcmsuCj4KPiBXaXRob3V0IHRvbyBtdWNoIHRyb3VibGUgSSBmaW5p
c2hlZCB1cGdyYWRpbmcgaXQgdG8gVmVyc2lvbiAxMi4xLgo+Cj4gVGhlIG9sZCBzZXR1cCB3YXMg
cnVubmluZyB1c2luZyB0aGUgWGVuICJ4bSIgdG9vbHN0YWNrIGFuZCB3b3JrcyBsaWtlCj4geW91
J2QgZXhwZWN0LiDCoFRoZSBuZXcgc2V0dXAgd29ya3Mgb2sgaWYgSSB1c2UgdGhlICJ4bSIgc3Rh
Y2sgYXMgd2VsbC4KPgo+IEkgbGVhcm5lZCB0aGF0IHdlIHNob3VsZCBtb3ZlIHRvIHRoZSAieGwi
IHRvb2xzdGFjay4gwqBJJ20gdHJ5aW5nIHRvIGRvCj4gdGhhdCBub3cgYW5kIGhhdmluZyBzb21l
IHByb2JsZW1zIHdpdGggbmV0d29ya2luZywgYnV0IG9ubHkgd2l0aCB0aGUgeGwKPiBhcHByb2Fj
aC4KPgo+IEkndmUgYmVlbiBydW5uaW5nIHVwIHRvIGRhdGUgWGVuIGZvciBhd2hpbGUuCj4KPiBy
cG0gLXFhIHwgZ3JlcCAtaSB4ZW4KPiDCoHhlbi10b29scy00LjEuMl8xMS0xNjQuNS54ODZfNjQK
PiDCoHhlbi1kb2MtaHRtbC00LjEuMl8xMS0xNjQuNS54ODZfNjQKPiDCoHhlbi1saWJzLTQuMS4y
XzExLTE2NC41Lng4Nl82NAo+IMKgeGVuLTQuMS4yXzExLTE2NC41Lng4Nl82NAo+IMKgcGF0dGVy
bnMtb3BlblNVU0UteGVuX3NlcnZlci0xMi4xLTI1LjIxLjEueDg2XzY0Cj4gwqB4ZW4tZGV2ZWwt
NC4xLjJfMTEtMTY0LjUueDg2XzY0Cj4gwqB4ZW4tZG9jLXBkZi00LjEuMl8xMS0xNjQuNS54ODZf
NjQKPiDCoGtlcm5lbC14ZW4tZGV2ZWwtMy4xLjAtMS4yLjEueDg2XzY0Cj4gwqBrZXJuZWwteGVu
LTMuMS4wLTEuMi4xLng4Nl82NAo+Cj4gSSBhbHJlYWR5IHNldHVwIHRoZSBuZXR3b3JraW5nIG9u
IHRoZSBIb3N0IHRvIHVzZSBPcGVuU1VTRQo+IGNvbmZpZ3VyYXRpb24uCj4KPiBicmN0bCBzaG93
Cj4gwqBicmlkZ2UgbmFtZSDCoCDCoCBicmlkZ2UgaWQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU1RQ
IGVuYWJsZWQgwqAgwqAgaW50ZXJmYWNlcwo+IMKgYnIwIMKgIMKgIMKgIMKgIMKgIMKgIDgwMDAu
MDA1MjM1MWQ1MzM3IMKgIMKgIMKgIG5vIMKgIMKgIMKgIMKgIMKgIMKgIMKgZXRoMAo+Cj4gY2F0
IC9ldGMvc3lzY29uZmlnL25ldHdvcmsvaWZjZmctYnIwCj4gwqBTVEFSVE1PREU9J2F1dG8nCj4g
wqBCT09UUFJPVE89J3N0YXRpYycKPiDCoEJSSURHRT0neWVzJwo+IMKgQlJJREdFX1BPUlRTPSdl
dGgwJwo+IMKgQlJJREdFX0ZPUldBUkRERUxBWT0nMCcKPiDCoEJSSURHRV9TVFA9J29mZicKPgo+
IMKgTkFNRT0nTW90aGVyYm9hcmQnCj4gwqBJUEFERFI9JzE5Mi4xNjguMS4zMi8yNCcKPiDCoEJS
T0FEQ0FTVD0nJwo+IMKgUkVNT1RFX0lQQUREUj0nJwo+IMKgTkVUV09SSz0nJwo+IMKgTVRVPScn
Cj4gwqBFVEhUT09MX09QVElPTlM9JycKPiDCoFVTRVJDT05UUk9MPSdubycKPiDCoE5NX0NPTlRS
T0xMRUQ9J25vJwo+Cj4gY2F0IC9ldGMvc3lzY29uZmlnL25ldHdvcmsvaWZjZmctZXRoMAo+IMKg
U1RBUlRNT0RFPSdtYW51YWwnCj4gwqBCT09UUFJPVE89J25vbmUnCj4gwqBCUklER0U9J25vJwo+
Cj4gVGhlIEd1ZXN0IGNmZyBmaWxlIEknbSB1c2luZyBmb3IgdGVzdGluZyBpczoKPgo+IGNhdCB0
ZXN0LmNmZwo+IMKgbmFtZT0ndGVzdCcKPiDCoGJ1aWxkZXI9J2xpbnV4Jwo+IMKgYm9vdGxvYWRl
cj0nL3Vzci9iaW4vcHlncnViJwo+IMKgZGlzaz1bJ3BoeTovZGV2L1hlblZvbHMvdGVzdCx4dmRh
LHcnXQo+IMKgdmlmPVttYWM9MDA6MTY6M2U6MTI6MzQ6MDEsIGJyaWRnZT1icjAgwqAsIHZpZm5h
bWU9dmlmQlInXQoKVGhlIHhsIHRvb2xzdGFjayBwcmVzZW50IGluIHZlcnNpb24gNC4xLjIgZG9l
c24ndCBzdXBwb3J0IHZpZm5hbWVbMF0KKG5ld2VyIHZlcnNpb25zIGRvKSwgc28gSSB0aGluayBp
ZiB5b3UgcmVtb3ZlIHRoYXQgaXQgc2hvdWxkIGJlIG9rLgoKWzBdIGh0dHA6Ly9saXN0cy54ZW4u
b3JnL2FyY2hpdmVzL2h0bWwveGVuLXVzZXJzLzIwMTEtMTIvbXNnMDAyMjUuaHRtbAoKPiDCoHZm
Yj1bICd0eXBlPXZuYywgdm5jZGlzcGxheT0xLCB2bmNsaXN0ZW49MTI3LjAuMC4xJ10KPiDCoGV4
dHJhPSd0ZXh0bW9kZT0xIHhlbmNvbnM9eHZjMCBub2lycWRlYnVnJwo+IMKgb25fc2h1dGRvd249
J2Rlc3Ryb3knCj4gwqBvbl9yZWJvb3Q9J3Jlc3RhcnQnCj4gwqBvbl9jcmFzaD0nZGVzdHJveScK
PiDCoHZjcHVzPTIKPiDCoG1heG1lbT0yMDQ4Cj4gwqBtZW1vcnk9MjA0OAo+Cj4gV2l0aCBhIGNs
ZWFuLWJvb3RlZCBIb3N0IGFuZCBubyBsYXVuY2hlZCBHdWVzdHMsCj4KPiB4bCBsaXN0Cj4gwqBO
YW1lIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgSUQgwqAgTWVtIFZDUFVzIMKgIMKgIMKgU3RhdGUKPiDCoFRpbWUocykKPiDCoERvbWFp
bi0wIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IDAgwqAxMDEwIMKgIMKgIDQgwqAgwqAgci0tLS0tCj4gwqAgwqA4Ni4zCj4KPiB4bCBjcmVhdGUg
LWMgdGVzdC5jZmcKPiDCoCDCoCDCoCDCoCDCoCDCoHB5R1JVQiDCoHZlcnNpb24gMC42Cj4gwqAg
wqAgwqAgwqAg4pSM4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSQCj4gwqAgwqAgwqAgwqAg4pSCIFhlbjQgMTIuMSBEb21VCj4gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqDilIIKPiDCoCDCoCDCoCDCoCDilIIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oOKUggo+IMKgIMKgIMKgIMKgIOKUggo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg4pSCCj4g
wqAgwqAgwqAgwqAg4pSCCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDilIIKPiDCoCDCoCDC
oCDCoCDilIIKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoOKUggo+IMKgIMKgIMKgIMKgIOKU
ggo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg4pSCCj4gwqAgwqAgwqAgwqAg4pSCCj4gwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDilIIKPiDCoCDCoCDCoCDCoCDilIIKPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoOKUggo+IMKgIMKgIMKgIMKgIOKUlOKUgOKUgOKUgOKUgOKUgOKUgOKU
gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU
gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU
gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKU
gOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUgOKUmAo+IMKgIMKgIMKgIMKgIMKgIMKgIFVzZSB0aGUg
XiBhbmQgdiBrZXlzIHRvIHNlbGVjdCB3aGljaCBlbnRyeSBpcyBoaWdobGlnaHRlZC4KPiDCoCDC
oCDCoCDCoCDCoCDCoCBQcmVzcyBlbnRlciB0byBib290IHRoZSBzZWxlY3RlZCBPUywgJ2UnIHRv
IGVkaXQgdGhlCj4gwqAgwqAgwqAgwqAgwqAgwqAgY29tbWFuZHMgYmVmb3JlIGJvb3RpbmcsICdh
JyB0byBtb2RpZnkgdGhlIGtlcm5lbCBhcmd1bWVudHMKPiDCoCDCoCDCoCDCoCDCoCDCoCBiZWZv
cmUgYm9vdGluZywgb3IgJ2MnIGZvciBhIGNvbW1hbmQgbGluZS4KPgo+IMKgIMKgIMKgIMKgIMKg
IMKgIFdpbGwgYm9vdCBzZWxlY3RlZCBlbnRyeSBpbiDCoDEgc2Vjb25kcwo+Cj4KPiDCoCDCoCDC
oCDCoERhZW1vbiBydW5uaW5nIHdpdGggUElEIDY3NzkKPgo+IEkgZ2V0IG5vIG90aGVyIG91dHB1
dCBoZXJlICh3aHkgbm90Pykgb24gdGhlIGNvbnNvbGUgZm9yIGFib3V0IDMwCj4gc2Vjb25kcy4g
VGhlbiBqdXN0LAo+Cj4gwqBXZWxjb21lIHRvIG9wZW5TVVNFIDEyLjEgIkFzcGFyYWd1cyIgLSBL
ZXJuZWwgMy4xLjAtMS4yLXhlbiAoeHZjMCkuCj4KPiDCoHRlc3RzZXJ2ZXIgbG9naW46Cj4KPgo+
IFRoZSBvdXRwdXQgb2YgJ3RhaWwgLWYgL3Zhci9sb2cvbWVzc2FnZXMgL3Zhci9sb2cveGVuLyps
b2cnIGlzIGp1c3QKPgo+IMKgIMKgIMKgIMKgPT0+IC92YXIvbG9nL21lc3NhZ2VzIDw9PQo+IMKg
IMKgIMKgIMKgSmFuIDIxIDEwOjQwOjM5IHRlc3RzZXJ2ZXIgbG9nZ2VyOiAvZXRjL3hlbi9zY3Jp
cHRzL2Jsb2NrOiBhZGQKPiDCoCDCoCDCoCDCoFhFTkJVU19QQVRIPWJhY2tlbmQvdmJkLzUvNTE3
MTIKPiDCoCDCoCDCoCDCoEphbiAyMSAxMDo0MDozOSB0ZXN0c2VydmVyIGxvZ2dlcjogL2V0Yy94
ZW4vc2NyaXB0cy9ibG9jazogYWRkCj4gwqAgwqAgwqAgwqBYRU5CVVNfUEFUSD1iYWNrZW5kL3Zi
ZC81LzUxNzI4Cj4gwqAgwqAgwqAgwqBKYW4gMjEgMTA6NDA6MzkgdGVzdHNlcnZlciBsb2dnZXI6
IC9ldGMveGVuL3NjcmlwdHMvYmxvY2s6IGFkZAo+IMKgIMKgIMKgIMKgWEVOQlVTX1BBVEg9YmFj
a2VuZC92YmQvNS81MTc0NAo+IMKgIMKgIMKgIMKgSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIg
bG9nZ2VyOiAvZXRjL3hlbi9zY3JpcHRzL3ZpZi1icmlkZ2U6Cj4gwqAgwqAgwqAgwqBvbmxpbmUg
dHlwZV9pZj12aWYgWEVOQlVTX1BBVEg9YmFja2VuZC92aWYvNS8wCj4gwqAgwqAgwqAgwqBKYW4g
MjEgMTA6NDA6NDAgdGVzdHNlcnZlciBsb2dnZXI6IC9ldGMveGVuL3NjcmlwdHMvdmlmLWJyaWRn
ZToKPiDCoCDCoCDCoCDCoE5vIGRldmljZSBkZXRhaWxzIGluIGJhY2tlbmQvdmlmLzUvMCwgZXhp
dGluZy4KPiDCoCDCoCDCoCDCoEphbiAyMSAxMDo0MDo0MCB0ZXN0c2VydmVyIGxvZ2dlcjogL2V0
Yy94ZW4vc2NyaXB0cy92aWYtYnJpZGdlOgo+IMKgIMKgIMKgIMKgb25saW5lIFhFTkJVU19QQVRI
PWJhY2tlbmQvdmlmLzUvMAo+IMKgIMKgIMKgIMKgSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIg
bG9nZ2VyOiAvZXRjL3hlbi9zY3JpcHRzL3ZpZi1icmlkZ2U6Cj4gwqAgwqAgwqAgwqBObyBkZXZp
Y2UgZGV0YWlscyBpbiBiYWNrZW5kL3ZpZi81LzAsIGV4aXRpbmcuCj4gwqAgwqAgwqAgwqBKYW4g
MjEgMTA6NDA6NDAgdGVzdHNlcnZlciBrZXJuZWw6IFsgMjcxMS45NTE4MjJdIGJsa2JhY2s6Cj4g
wqAgwqAgwqAgwqByaW5nLXJlZiA4LCBldmVudC1jaGFubmVsIDEyLCBwcm90b2NvbCAxICh4ODZf
NjQtYWJpKQo+IMKgIMKgIMKgIMKgSmFuIDIxIDEwOjQwOjQwIHRlc3RzZXJ2ZXIga2VybmVsOiBb
IDI3MTIuMDE1NzMxXSBibGtiYWNrOgo+IMKgIMKgIMKgIMKgcmluZy1yZWYgOSwgZXZlbnQtY2hh
bm5lbCAxMywgcHJvdG9jb2wgMSAoeDg2XzY0LWFiaSkKPiDCoCDCoCDCoCDCoEphbiAyMSAxMDo0
MDo0MCB0ZXN0c2VydmVyIGtlcm5lbDogWyAyNzEyLjA2NjQ2N10gYmxrYmFjazoKPiDCoCDCoCDC
oCDCoHJpbmctcmVmIDEwLCBldmVudC1jaGFubmVsIDE0LCBwcm90b2NvbCAxICh4ODZfNjQtYWJp
KQo+Cj4KPiBJIGNhbiBsb2dpbiB0byB0aGUgZ3Vlc3QgYXQgdGhlIGNvbnNvbGUgYW5kIHRoZSBH
dWVzdCdzIG5ldHdvcmtpbmcgbG9va3MKPiBsaWtlIGl0J3MgcmVjb2duaXplZCBPSy4KPgo+IGRt
ZXNnIHwgZ3JlcCBldGgKPiBbIMKgIMKgMC44OTY1OTddIG5ldGZyb250OiBJbml0aWFsaXNpbmcg
dmlydHVhbCBldGhlcm5ldCBkcml2ZXIuCj4KPiBod2luZm8gLS1uZXR3b3JrCj4gMDU6IE5vbmUg
MDAuMDogMTA3MDAgTG9vcGJhY2sKPiDCoFtDcmVhdGVkIGF0IG5ldC4xMjRdCj4gwqBVbmlxdWUg
SUQ6IFpzQlMuR1FOeDdMNHVQTkEKPiDCoFN5c0ZTIElEOiAvY2xhc3MvbmV0L2xvCj4gwqBIYXJk
d2FyZSBDbGFzczogbmV0d29yayBpbnRlcmZhY2UKPiDCoE1vZGVsOiAiTG9vcGJhY2sgbmV0d29y
ayBpbnRlcmZhY2UiCj4gwqBEZXZpY2UgRmlsZTogbG8KPiDCoExpbmsgZGV0ZWN0ZWQ6IHllcwo+
IMKgQ29uZmlnIFN0YXR1czogY2ZnPW5ldywgYXZhaWw9eWVzLCBuZWVkPW5vLCBhY3RpdmU9dW5r
bm93bgo+Cj4gMDY6IE5vbmUgMDAuMDogMTA3MDEgRXRoZXJuZXQKPiDCoFtDcmVhdGVkIGF0IG5l
dC4xMjRdCj4gwqBVbmlxdWUgSUQ6IHVzRFcubmRwZXVjYXg2VjEKPiDCoFBhcmVudCBJRDogK2pz
Zy5TZCt5a2Z5dmxLNAo+IMKgU3lzRlMgSUQ6IC9jbGFzcy9uZXQvZXRoMAo+IMKgU3lzRlMgRGV2
aWNlIExpbms6IC9kZXZpY2VzL3hlbi92aWYtMAo+IMKgSGFyZHdhcmUgQ2xhc3M6IG5ldHdvcmsg
aW50ZXJmYWNlCj4gwqBNb2RlbDogIkV0aGVybmV0IG5ldHdvcmsgaW50ZXJmYWNlIgo+IMKgRHJp
dmVyOiAidmlmIgo+IMKgRHJpdmVyIE1vZHVsZXM6ICJ4ZW5uZXQiCj4gwqBEZXZpY2UgRmlsZTog
ZXRoMAo+IMKgSFcgQWRkcmVzczogMDA6MTY6M2U6MTI6MzQ6MDEKPiDCoExpbmsgZGV0ZWN0ZWQ6
IHllcwo+IMKgQ29uZmlnIFN0YXR1czogY2ZnPW5ldywgYXZhaWw9eWVzLCBuZWVkPW5vLCBhY3Rp
dmU9dW5rbm93bgo+IMKgQXR0YWNoZWQgdG86ICM0IChFdGhlcm5ldCBjb250cm9sbGVyKQo+Cj4g
VGhlIEd1ZXN0J3MgbmV0d29yayByb3V0ZXMgbG9vayBPSy4KPgo+IHJvdXRlCj4gS2VybmVsIElQ
IHJvdXRpbmcgdGFibGUKPiBEZXN0aW5hdGlvbiDCoCDCoCBHYXRld2F5IMKgIMKgIMKgIMKgIEdl
bm1hc2sgwqAgwqAgwqAgwqAgRmxhZ3MgTWV0cmljIFJlZiDCoCDCoFVzZQo+IElmYWNlCj4gZGVm
YXVsdCDCoCDCoCDCoCDCoCAxOTIuMTY4LjEuMSDCoCDCoCAwLjAuMC4wIMKgIMKgIMKgIMKgIFVH
IMKgIMKgMCDCoCDCoCDCoDAgwqAgwqAgwqAgwqAwCj4gZXRoMAo+IGxvb3BiYWNrIMKgIMKgIMKg
IMKgKiDCoCDCoCDCoCDCoCDCoCDCoCDCoCAyNTUuMC4wLjAgwqAgwqAgwqAgVSDCoCDCoCAwIMKg
IMKgIMKgMCDCoCDCoCDCoCDCoDAKPiBsbwo+IGxpbmstbG9jYWwgwqAgwqAgwqAqIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIDI1NS4yNTUuMC4wIMKgIMKgIFUgwqAgwqAgMCDCoCDCoCDCoDAgwqAgwqAg
wqAgwqAwCj4gZXRoMAo+IDE5Mi4xNjguMS4wIMKgIMKgICogwqAgwqAgwqAgwqAgwqAgwqAgwqAg
MjU1LjI1NS4yNTUuMCDCoCBVIMKgIMKgIDAgwqAgwqAgwqAwIMKgIMKgIMKgIMKgMAo+IGV0aDAK
Pgo+IEJ1dCB3aGVuIEkgdHJ5IHRvIHBpbmcgYW55d2hlcmUgb2ZmIHRoZSBHdWVzdCBJIGdldCBI
b3N0VW5yZWFjaGFibGUKPiBlcnJvcnMuCj4KPiBwaW5nIDE5Mi4xNjguMS4xCj4gUElORyAxOTIu
MTY4LjEuMSAoMTkyLjE2OC4xLjEpIDU2KDg0KSBieXRlcyBvZiBkYXRhLgo+IEZyb20gMTkyLjE2
OC4xLjMyIGljbXBfc2VxPTEgRGVzdGluYXRpb24gSG9zdCBVbnJlYWNoYWJsZQo+IEZyb20gMTky
LjE2OC4xLjMyIGljbXBfc2VxPTIgRGVzdGluYXRpb24gSG9zdCBVbnJlYWNoYWJsZQo+IEZyb20g
MTkyLjE2OC4xLjMyIGljbXBfc2VxPTMgRGVzdGluYXRpb24gSG9zdCBVbnJlYWNoYWJsZQo+IGV0
YyBldGMKPgo+IEl0IGZlZWxzIGxpa2UgSSdtIHByZXR0eSBjbG9zZSB0byBnZXR0aW5nIHRoaXMg
d29ya2luZy4gwqBBbSBJIHN0aWxsCj4gbWlzc2luZyBzb21lIHBhcnQgb2YgdGhlIGNvbmZpZ3Vy
YXRpb24gY2hhbmdlcyBuZWVkZWQgZm9yIHVzaW5nIHRoZSB4bAo+IHRvb2xzdGFjaz8KPgo+IFJl
Z2FyZHMsCj4KPiBFcmluCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPiBYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbApfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Jan 21 23:04:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 23: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 1Rojyo-00073H-5H; Sat, 21 Jan 2012 23:04:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rojym-000736-Re
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 23:04:13 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327187043!8280629!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzYwNDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12371 invoked from network); 21 Jan 2012 23:04:06 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Jan 2012 23:04:06 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CBCB620B58
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 18:04:02 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute6.internal (MEProxy); Sat, 21 Jan 2012 18:04:02 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	Z2YSkvhXWJx0l+/ts1oYPar97K0=; b=sL1hFe9Uw1VgwE4hpV/Th03qwSCsoI7+
	XfZazjdwaLqSjWwFLgaewr1KI908SZEdIpvwAHUREkh8vikDlg3BbjE4OlMJXZ9t
	c51Rmm3ta6ds4hr+8pmBWEepKEnXwVh+UlxgkygjEoHnLrvbBF7q1xxA1VCdeSMP
	QnN16TT/Zhs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=Z2YSkvhXWJx0l+/ts1oYPar97K0=; b=
	EtrQtZ4CXA0dr6OWS8j/NPPZZWaXs5KB9gtKoSzWCJwybBQy5T1fQDjb1je3cc0C
	IL7UmSWu+5XWj1rdkiuh/X0iGY2zidzxYI1r3lwCacqrgFkni1krRpgBaTZf7siR
	m+VZWgohRjuJqF/+CQfVrvj97n0exb/LejYLXqqsKzk=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id A2035A00075; Sat, 21 Jan 2012 18:04:02 -0500 (EST)
Message-Id: <1327187042.28621.140661026352253@webmail.messagingengine.com>
X-Sasl-Enc: mjuRIB61+cf0EsKY7v66e9vf9L+RgVWWU/r0pwIKgjWH 1327187042
From: erin.balid@inoutbox.com
To: =?ISO-8859-1?Q?Roger=20Pau=20Monn=E9?= <roger.pau@entel.upc.edu>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
In-Reply-To: <CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
Date: Sat, 21 Jan 2012 15:04:02 -0800
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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 Roger,

On Sat, Jan 21, 2012, at 11:57 PM, Roger Pau Monn=E9 wrote:
> 2012/1/21  <erin.balid@inoutbox.com>:
> > =A0vif=3D[mac=3D00:16:3e:12:34:01, bridge=3Dbr0 =A0, vifname=3DvifBR']
> =

> The xl toolstack present in version 4.1.2 doesn't support vifname[0]
> (newer versions do), so I think if you remove that it should be ok.
> =

> [0] http://lists.xen.org/archives/html/xen-users/2011-12/msg00225.html

That looked hopeful.

I changed

 - vif=3D[mac=3D00:16:3e:12:34:01, bridge=3Dbr0  , vifname=3DvifBR']
 + vif=3D[mac=3D00:16:3e:12:34:01, bridge=3Dbr0']

and launched again.  I still ended up with no attached VIF interface.

brctl show
 bridge name     bridge id               STP enabled     interfaces
 br0             8000.0052351d5337       yes             eth0

xl list-vm template
 UUID                                  ID    name
 7d46ca9a-9d86-476e-948d-3eddf5d070e4  4    test

xl network-list template
 Idx BE Mac Addr.         handle state evt-ch   tx-/rx-ring-ref BE-path
 0   0  00:16:3e:12:34:01      0     4     15   768/769        =

 /local/domain/0/backend/vif/4/0

And, I still can't ping just like my orginal post.

:-(

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 21 23:04:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 21 Jan 2012 23: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 1Rojyo-00073H-5H; Sat, 21 Jan 2012 23:04:14 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rojym-000736-Re
	for xen-devel@lists.xensource.com; Sat, 21 Jan 2012 23:04:13 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327187043!8280629!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzYwNDg=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12371 invoked from network); 21 Jan 2012 23:04:06 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 21 Jan 2012 23:04:06 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CBCB620B58
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 18:04:02 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute6.internal (MEProxy); Sat, 21 Jan 2012 18:04:02 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	Z2YSkvhXWJx0l+/ts1oYPar97K0=; b=sL1hFe9Uw1VgwE4hpV/Th03qwSCsoI7+
	XfZazjdwaLqSjWwFLgaewr1KI908SZEdIpvwAHUREkh8vikDlg3BbjE4OlMJXZ9t
	c51Rmm3ta6ds4hr+8pmBWEepKEnXwVh+UlxgkygjEoHnLrvbBF7q1xxA1VCdeSMP
	QnN16TT/Zhs=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=Z2YSkvhXWJx0l+/ts1oYPar97K0=; b=
	EtrQtZ4CXA0dr6OWS8j/NPPZZWaXs5KB9gtKoSzWCJwybBQy5T1fQDjb1je3cc0C
	IL7UmSWu+5XWj1rdkiuh/X0iGY2zidzxYI1r3lwCacqrgFkni1krRpgBaTZf7siR
	m+VZWgohRjuJqF/+CQfVrvj97n0exb/LejYLXqqsKzk=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id A2035A00075; Sat, 21 Jan 2012 18:04:02 -0500 (EST)
Message-Id: <1327187042.28621.140661026352253@webmail.messagingengine.com>
X-Sasl-Enc: mjuRIB61+cf0EsKY7v66e9vf9L+RgVWWU/r0pwIKgjWH 1327187042
From: erin.balid@inoutbox.com
To: =?ISO-8859-1?Q?Roger=20Pau=20Monn=E9?= <roger.pau@entel.upc.edu>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
In-Reply-To: <CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
Date: Sat, 21 Jan 2012 15:04:02 -0800
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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 Roger,

On Sat, Jan 21, 2012, at 11:57 PM, Roger Pau Monn=E9 wrote:
> 2012/1/21  <erin.balid@inoutbox.com>:
> > =A0vif=3D[mac=3D00:16:3e:12:34:01, bridge=3Dbr0 =A0, vifname=3DvifBR']
> =

> The xl toolstack present in version 4.1.2 doesn't support vifname[0]
> (newer versions do), so I think if you remove that it should be ok.
> =

> [0] http://lists.xen.org/archives/html/xen-users/2011-12/msg00225.html

That looked hopeful.

I changed

 - vif=3D[mac=3D00:16:3e:12:34:01, bridge=3Dbr0  , vifname=3DvifBR']
 + vif=3D[mac=3D00:16:3e:12:34:01, bridge=3Dbr0']

and launched again.  I still ended up with no attached VIF interface.

brctl show
 bridge name     bridge id               STP enabled     interfaces
 br0             8000.0052351d5337       yes             eth0

xl list-vm template
 UUID                                  ID    name
 7d46ca9a-9d86-476e-948d-3eddf5d070e4  4    test

xl network-list template
 Idx BE Mac Addr.         handle state evt-ch   tx-/rx-ring-ref BE-path
 0   0  00:16:3e:12:34:01      0     4     15   768/769        =

 /local/domain/0/backend/vif/4/0

And, I still can't ping just like my orginal post.

:-(

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 00:55:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 00:55:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RolhW-00081E-Th; Sun, 22 Jan 2012 00:54:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RolhU-000819-Tm
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 00:54:29 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327193661!8191204!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzY0OTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27501 invoked from network); 22 Jan 2012 00:54:22 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jan 2012 00:54:22 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 75BF620185
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 19:54:21 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Sat, 21 Jan 2012 19:54:21 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	Bgr0kkxOJ3Ppw6+x/moPgUS4McY=; b=wSs1XWsWtY+1xnsPEV1OqtLxYbBnMcg9
	6aVT2nbDRGxcaGxzCQfnPlOuBu90I9u37+xeNAVnTpaVGFxNS42Q46wmIeq3sJUW
	T2NQ9KnT6awDDzd3bMWeqPiLX/eTaAVJojEwbFCg/eZjYZKlEBGMSwSQEn3wCCCs
	zizCkLKal4o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=Bgr0kkxOJ3Ppw6+x/moPgUS4McY=; b=u0q
	oz3vFsxiUs43edQFTG2SeDIjeb/WM98udkZLiz1T/RYW0gymvgjvpsfX9xZmv7Rf
	mCgf9+M7ubuwzYvAPxGJpDolHJRVZQvVF5tiGNYsNgTPjXEjOg+AfU+oMCMKZIXr
	5gQzHb1NPvJiQ1gk8sJhCH3JPHYuacr08YsSifRQ=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 4D6C5A00075; Sat, 21 Jan 2012 19:54:21 -0500 (EST)
Message-Id: <1327193661.16152.140661026376033@webmail.messagingengine.com>
X-Sasl-Enc: j6559Fhum4r47Eby2OLEfvI/tAxnqbahJgAjXX+7GVtj 1327193661
From: erin.balid@inoutbox.com
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <1327187042.28621.140661026352253@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
	<1327187042.28621.140661026352253@webmail.messagingengine.com>
Date: Sat, 21 Jan 2012 16:54:21 -0800
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi All.

I wanted to do an apples-to-apples comparison of "xm" and "xl".

Using a config file VIF of

	vif=['mac=00:16:3E:12:34:01,bridge=br0']

If I turn on  xend and start the Guest with 'xm create', networking at
the Guest is OK.
If I turn off xend and start the Guest with 'xl create', networking at
the Guest fails, I think because the Guest's VIF doesn't get assigned to
the Host bridge.


service xend start
	Starting xend                                                   
	                                         done

brctl show
	bridge name     bridge id               STP enabled    
	interfaces
	br0             8000.0052351d5337       yes             eth0

xm list
	Name                                        ID   Mem VCPUs     
	State   Time(s)
	Domain-0                                     0  1010     1    
	r-----    169.1

xm create /etc/xen/vm/tmpl_run.cfg

xm list
	Name                                        ID   Mem VCPUs     
	State   Time(s)
	Domain-0                                     0  1010     1    
	r-----    175.2
	test                                         6  1024     2    
	-b----      8.7

brctl show
	bridge name     bridge id               STP enabled    
	interfaces
	br0             8000.0052351d5337       yes             eth0
	                                                        vif6.0

xm console test    
	Welcome to openSUSE 12.1 "Asparagus" - Kernel 3.1.0-1.2-xen
	(xvc0).
	testserver login: test
	Password:
	Last login: Sat Jan 21 14:57:14 PST 2012 on xvc0
	You have new mail.
	Have a lot of fun...

ping -c 2 192.168.1.1
	PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
	64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.500 ms
	64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.388 ms
	--- 192.168.1.1 ping statistics ---
	2 packets transmitted, 2 received, 0% packet loss, time 999ms
	rtt min/avg/max/mdev = 0.388/0.444/0.500/0.056 ms

shutdown -h now
	The system is going down for system halt NOW! (Sat Jan 21
	16:34:48 2012):
	...
	[  147.792590] System halted.

service xend stop

brctl show
	bridge name     bridge id               STP enabled    
	interfaces
	br0             8000.0052351d5337       yes             eth0

xl list
	Name                                        ID   Mem VCPUs     
	State   Time(s)
	Domain-0                                     0  1010     1    
	r-----     182.8

xl create /etc/xen/vm/tmpl_run.cfg

xl list
	Name                                        ID   Mem VCPUs     
	State   Time(s)
	Domain-0                                     0  1010     1    
	r-----     186.6
	test                                         7  1024     2    
	-b----       6.9

brctl show
	bridge name     bridge id               STP enabled    
	interfaces
	br0             8000.0052351d5337       yes             eth0

xl console test    
	Welcome to openSUSE 12.1 "Asparagus" - Kernel 3.1.0-1.2-xen
	(xvc0).
	testserver login: test
	Password:
	Last login: Sat Jan 21 16:34:08 PST 2012 on xvc0
	You have new mail.
	Have a lot of fun...

ping -c 2 192.168.1.1
	PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
	From 192.168.1.32 icmp_seq=1 Destination Host Unreachable
	From 192.168.1.32 icmp_seq=2 Destination Host Unreachable
	--- 192.168.1.1 ping statistics ---
	2 packets transmitted, 0 received, +2 errors, 100% packet loss,
	time 1001ms
	pipe 2

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 00:55:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 00:55:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RolhW-00081E-Th; Sun, 22 Jan 2012 00:54:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RolhU-000819-Tm
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 00:54:29 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327193661!8191204!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzY0OTE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27501 invoked from network); 22 Jan 2012 00:54:22 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jan 2012 00:54:22 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 75BF620185
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 19:54:21 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Sat, 21 Jan 2012 19:54:21 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	Bgr0kkxOJ3Ppw6+x/moPgUS4McY=; b=wSs1XWsWtY+1xnsPEV1OqtLxYbBnMcg9
	6aVT2nbDRGxcaGxzCQfnPlOuBu90I9u37+xeNAVnTpaVGFxNS42Q46wmIeq3sJUW
	T2NQ9KnT6awDDzd3bMWeqPiLX/eTaAVJojEwbFCg/eZjYZKlEBGMSwSQEn3wCCCs
	zizCkLKal4o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=Bgr0kkxOJ3Ppw6+x/moPgUS4McY=; b=u0q
	oz3vFsxiUs43edQFTG2SeDIjeb/WM98udkZLiz1T/RYW0gymvgjvpsfX9xZmv7Rf
	mCgf9+M7ubuwzYvAPxGJpDolHJRVZQvVF5tiGNYsNgTPjXEjOg+AfU+oMCMKZIXr
	5gQzHb1NPvJiQ1gk8sJhCH3JPHYuacr08YsSifRQ=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 4D6C5A00075; Sat, 21 Jan 2012 19:54:21 -0500 (EST)
Message-Id: <1327193661.16152.140661026376033@webmail.messagingengine.com>
X-Sasl-Enc: j6559Fhum4r47Eby2OLEfvI/tAxnqbahJgAjXX+7GVtj 1327193661
From: erin.balid@inoutbox.com
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <1327187042.28621.140661026352253@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
	<1327187042.28621.140661026352253@webmail.messagingengine.com>
Date: Sat, 21 Jan 2012 16:54:21 -0800
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi All.

I wanted to do an apples-to-apples comparison of "xm" and "xl".

Using a config file VIF of

	vif=['mac=00:16:3E:12:34:01,bridge=br0']

If I turn on  xend and start the Guest with 'xm create', networking at
the Guest is OK.
If I turn off xend and start the Guest with 'xl create', networking at
the Guest fails, I think because the Guest's VIF doesn't get assigned to
the Host bridge.


service xend start
	Starting xend                                                   
	                                         done

brctl show
	bridge name     bridge id               STP enabled    
	interfaces
	br0             8000.0052351d5337       yes             eth0

xm list
	Name                                        ID   Mem VCPUs     
	State   Time(s)
	Domain-0                                     0  1010     1    
	r-----    169.1

xm create /etc/xen/vm/tmpl_run.cfg

xm list
	Name                                        ID   Mem VCPUs     
	State   Time(s)
	Domain-0                                     0  1010     1    
	r-----    175.2
	test                                         6  1024     2    
	-b----      8.7

brctl show
	bridge name     bridge id               STP enabled    
	interfaces
	br0             8000.0052351d5337       yes             eth0
	                                                        vif6.0

xm console test    
	Welcome to openSUSE 12.1 "Asparagus" - Kernel 3.1.0-1.2-xen
	(xvc0).
	testserver login: test
	Password:
	Last login: Sat Jan 21 14:57:14 PST 2012 on xvc0
	You have new mail.
	Have a lot of fun...

ping -c 2 192.168.1.1
	PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
	64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.500 ms
	64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.388 ms
	--- 192.168.1.1 ping statistics ---
	2 packets transmitted, 2 received, 0% packet loss, time 999ms
	rtt min/avg/max/mdev = 0.388/0.444/0.500/0.056 ms

shutdown -h now
	The system is going down for system halt NOW! (Sat Jan 21
	16:34:48 2012):
	...
	[  147.792590] System halted.

service xend stop

brctl show
	bridge name     bridge id               STP enabled    
	interfaces
	br0             8000.0052351d5337       yes             eth0

xl list
	Name                                        ID   Mem VCPUs     
	State   Time(s)
	Domain-0                                     0  1010     1    
	r-----     182.8

xl create /etc/xen/vm/tmpl_run.cfg

xl list
	Name                                        ID   Mem VCPUs     
	State   Time(s)
	Domain-0                                     0  1010     1    
	r-----     186.6
	test                                         7  1024     2    
	-b----       6.9

brctl show
	bridge name     bridge id               STP enabled    
	interfaces
	br0             8000.0052351d5337       yes             eth0

xl console test    
	Welcome to openSUSE 12.1 "Asparagus" - Kernel 3.1.0-1.2-xen
	(xvc0).
	testserver login: test
	Password:
	Last login: Sat Jan 21 16:34:08 PST 2012 on xvc0
	You have new mail.
	Have a lot of fun...

ping -c 2 192.168.1.1
	PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
	From 192.168.1.32 icmp_seq=1 Destination Host Unreachable
	From 192.168.1.32 icmp_seq=2 Destination Host Unreachable
	--- 192.168.1.1 ping statistics ---
	2 packets transmitted, 0 received, +2 errors, 100% packet loss,
	time 1001ms
	pipe 2

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 03:34:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 03:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RooBc-0004Fu-VE; Sun, 22 Jan 2012 03:33:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RooBa-0004FK-PG
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 03:33:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327203215!3225638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32125 invoked from network); 22 Jan 2012 03:33:35 -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;
	22 Jan 2012 03:33:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,549,1320624000"; d="scan'208";a="10193464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jan 2012 03:33:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 22 Jan 2012 03:33:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RooBS-0003Zy-4i;
	Sun, 22 Jan 2012 03:33:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RooBS-00085K-4F;
	Sun, 22 Jan 2012 03:33:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11217-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 22 Jan 2012 03:33:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11217: 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 11217 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11217/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-win          7 windows-install             fail pass in 11164
 test-amd64-i386-xl-credit2  12 guest-saverestore.2 fail in 11164 pass in 11217
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 11164 pass in 11217

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-win       7 windows-install              fail   like 10976
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 11028
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 11164 like 11028
 test-i386-i386-xl-win         7 windows-install       fail in 11164 like 10932

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11164 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11164 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11164 never pass

version targeted for testing:
 xen                  80fdf2182bc6
baseline version:
 xen                  ef8374dfe9bf

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=80fdf2182bc6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 80fdf2182bc6
+ branch=xen-unstable
+ revision=80fdf2182bc6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 80fdf2182bc6 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 03:34:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 03:34:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RooBc-0004Fu-VE; Sun, 22 Jan 2012 03:33:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RooBa-0004FK-PG
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 03:33:43 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327203215!3225638!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32125 invoked from network); 22 Jan 2012 03:33:35 -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;
	22 Jan 2012 03:33:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,549,1320624000"; d="scan'208";a="10193464"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jan 2012 03:33:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sun, 22 Jan 2012 03:33:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RooBS-0003Zy-4i;
	Sun, 22 Jan 2012 03:33:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RooBS-00085K-4F;
	Sun, 22 Jan 2012 03:33:34 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11217-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 22 Jan 2012 03:33:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11217: 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 11217 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11217/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-win          7 windows-install             fail pass in 11164
 test-amd64-i386-xl-credit2  12 guest-saverestore.2 fail in 11164 pass in 11217
 test-amd64-amd64-xl-winxpsp3  7 windows-install    fail in 11164 pass in 11217

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-win       7 windows-install              fail   like 10976
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 11028
 test-amd64-i386-xend-winxpsp3  7 windows-install      fail in 11164 like 11028
 test-i386-i386-xl-win         7 windows-install       fail in 11164 like 10932

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11164 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11164 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11164 never pass

version targeted for testing:
 xen                  80fdf2182bc6
baseline version:
 xen                  ef8374dfe9bf

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=80fdf2182bc6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 80fdf2182bc6
+ branch=xen-unstable
+ revision=80fdf2182bc6
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 80fdf2182bc6 ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 3 changesets with 3 changes to 3 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 06:33:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 06: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 1RoqzD-0005GX-GQ; Sun, 22 Jan 2012 06:33:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1RoqzC-0005GO-KN
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 06:33:06 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327213979!11886631!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 14626 invoked from network); 22 Jan 2012 06:33:00 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 06:33:00 -0000
Received: by yenr9 with SMTP id r9so28551437yen.30
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 22:32:58 -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=hy17T+d5KEE7zERC/mW1UeeoqqBkic9PAfuyKUNQyJk=;
	b=MNRyX2H1aqTp3wp800xzKDDoJbcr6PYwGwSPFPqytLvfAP8RBXfOHNIBgjxUR+a+9w
	lJmqGdT48mAIFIfReM7P2Jgi0gAT4wzbxh6rwGPKwudA8oFaGoN7XVO8tVrwuwsePnbR
	m+L1domKhuM1feqDJiyAUix8DfwxJ1fXT3I0A=
Received: by 10.236.80.65 with SMTP id j41mr3649869yhe.115.1327213978852; Sat,
	21 Jan 2012 22:32:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.157.136 with HTTP; Sat, 21 Jan 2012 22:32:37 -0800 (PST)
From: Eric Camachat <eric.camachat@gmail.com>
Date: Sat, 21 Jan 2012 22:32:37 -0800
Message-ID: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Got kernel BUG message while PCI pass-through to 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

Hi all,

I got kernel BUG message when PCI pass through to domU (xen-pv).
Is there any one seen this?

Eric

dom0 kernel config:
$ grep XEN_PCI linux-2.6.32.24/.config
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_PCIDEV_BACKEND=y
# CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
CONFIG_XEN_PCIDEV_BACKEND_PASS=y
# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
# CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
# CONFIG_XEN_PCIDEV_BE_DEBUG is not set


When start domU, got this error message in dom0:
BUG: sleeping function called from invalid context at mm/slab.c:3016
in_atomic(): 1, irqs_disabled(): 0, pid: 21, name: xenwatch
Pid: 21, comm: xenwatch Tainted: P           2.6.32.24-ws-symbol #1
Call Trace:
 [<ffffffff810365e4>] __might_sleep+0xf4/0x110
 [<ffffffff810ac478>] __kmalloc+0x118/0x140
 [<ffffffff811c1837>] kvasprintf+0x57/0x90
 [<ffffffff813fcd8a>] ? error_exit+0x2a/0x60
 [<ffffffff811c18d0>] kasprintf+0x60/0x70
 [<ffffffff810101c2>] ? check_events+0x12/0x20
 [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff810ab6a7>] ? kfree+0x87/0xd0
 [<ffffffff8123328a>] ? read_reply+0x13a/0x150
 [<ffffffff812337ae>] join+0x4e/0x60
 [<ffffffff8123396c>] xenbus_read+0x2c/0x70
 [<ffffffff8123402f>] xenbus_scanf+0x2f/0xa0
 [<ffffffff8100f82d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff810101c2>] ? check_events+0x12/0x20
 [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff810ab6a7>] ? kfree+0x87/0xd0
 [<ffffffff8123391c>] ? xenbus_printf+0xbc/0xe0
 [<ffffffff8100f82d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff8123a600>] pciback_publish_pci_root+0x40/0x1a0
 [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
nx4524-7AC4F0# [<ffffffff810ac53e>] ? kmem_cache_alloc+0x9e/0xf0
 [<ffffffff81010e26>] ? xen_register_device_domain_owner+0x86/0xc0
 [<ffffffff8123cc78>] pciback_publish_pci_roots+0x88/0xc0
 [<ffffffff8123a5c0>] ? pciback_publish_pci_root+0x0/0x1a0
 [<ffffffff8123aadd>] pciback_be_watch+0x1dd/0x290
 [<ffffffff81232d64>] ? xs_error+0x14/0x20
 [<ffffffff81233571>] ? xs_watch+0x51/0x60
 [<ffffffff81233b0d>] ? register_xenbus_watch+0xdd/0xf0
 [<ffffffff8123a900>] ? pciback_be_watch+0x0/0x290
 [<ffffffff8123b0a9>] pciback_xenbus_probe+0x139/0x140
 [<ffffffff81234f3a>] xenbus_dev_probe+0xaa/0x130
 [<ffffffff8127950b>] driver_probe_device+0x7b/0x160
 [<ffffffff812797e0>] ? __device_attach+0x0/0x50
 [<ffffffff8127981d>] __device_attach+0x3d/0x50
 [<ffffffff812785e8>] bus_for_each_drv+0x68/0x90
 [<ffffffff8127973b>] device_attach+0x7b/0x80
 [<ffffffff81278565>] bus_probe_device+0x25/0x40
 [<ffffffff81276ac3>] device_add+0x293/0x570
 [<ffffffff811b8da6>] ? kobject_init+0x36/0x80
 [<ffffffff81276db9>] device_register+0x19/0x20
 [<ffffffff81234780>] xenbus_probe_node+0x130/0x1b0
 [<ffffffff81234996>] xenbus_dev_changed+0x196/0x1a0
 [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff8103652b>] ? __might_sleep+0x3b/0x110
 [<ffffffff812350b6>] backend_changed+0x16/0x20
 [<ffffffff81233e4b>] xenwatch_thread+0x10b/0x150
 [<ffffffff81057d90>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff81233d40>] ? xenwatch_thread+0x0/0x150
 [<ffffffff81057c1e>] kthread+0x8e/0xa0
 [<ffffffff81014dfa>] child_rip+0xa/0x20
 [<ffffffff81013fa6>] ? int_ret_from_sys_call+0x7/0x1b

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 06:33:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 06: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 1RoqzD-0005GX-GQ; Sun, 22 Jan 2012 06:33:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1RoqzC-0005GO-KN
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 06:33:06 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327213979!11886631!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 14626 invoked from network); 22 Jan 2012 06:33:00 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 06:33:00 -0000
Received: by yenr9 with SMTP id r9so28551437yen.30
	for <xen-devel@lists.xensource.com>;
	Sat, 21 Jan 2012 22:32:58 -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=hy17T+d5KEE7zERC/mW1UeeoqqBkic9PAfuyKUNQyJk=;
	b=MNRyX2H1aqTp3wp800xzKDDoJbcr6PYwGwSPFPqytLvfAP8RBXfOHNIBgjxUR+a+9w
	lJmqGdT48mAIFIfReM7P2Jgi0gAT4wzbxh6rwGPKwudA8oFaGoN7XVO8tVrwuwsePnbR
	m+L1domKhuM1feqDJiyAUix8DfwxJ1fXT3I0A=
Received: by 10.236.80.65 with SMTP id j41mr3649869yhe.115.1327213978852; Sat,
	21 Jan 2012 22:32:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.157.136 with HTTP; Sat, 21 Jan 2012 22:32:37 -0800 (PST)
From: Eric Camachat <eric.camachat@gmail.com>
Date: Sat, 21 Jan 2012 22:32:37 -0800
Message-ID: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Got kernel BUG message while PCI pass-through to 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

Hi all,

I got kernel BUG message when PCI pass through to domU (xen-pv).
Is there any one seen this?

Eric

dom0 kernel config:
$ grep XEN_PCI linux-2.6.32.24/.config
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_PCIDEV_BACKEND=y
# CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
CONFIG_XEN_PCIDEV_BACKEND_PASS=y
# CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
# CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
# CONFIG_XEN_PCIDEV_BE_DEBUG is not set


When start domU, got this error message in dom0:
BUG: sleeping function called from invalid context at mm/slab.c:3016
in_atomic(): 1, irqs_disabled(): 0, pid: 21, name: xenwatch
Pid: 21, comm: xenwatch Tainted: P           2.6.32.24-ws-symbol #1
Call Trace:
 [<ffffffff810365e4>] __might_sleep+0xf4/0x110
 [<ffffffff810ac478>] __kmalloc+0x118/0x140
 [<ffffffff811c1837>] kvasprintf+0x57/0x90
 [<ffffffff813fcd8a>] ? error_exit+0x2a/0x60
 [<ffffffff811c18d0>] kasprintf+0x60/0x70
 [<ffffffff810101c2>] ? check_events+0x12/0x20
 [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff810ab6a7>] ? kfree+0x87/0xd0
 [<ffffffff8123328a>] ? read_reply+0x13a/0x150
 [<ffffffff812337ae>] join+0x4e/0x60
 [<ffffffff8123396c>] xenbus_read+0x2c/0x70
 [<ffffffff8123402f>] xenbus_scanf+0x2f/0xa0
 [<ffffffff8100f82d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff810101c2>] ? check_events+0x12/0x20
 [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff810ab6a7>] ? kfree+0x87/0xd0
 [<ffffffff8123391c>] ? xenbus_printf+0xbc/0xe0
 [<ffffffff8100f82d>] ? xen_force_evtchn_callback+0xd/0x10
 [<ffffffff8123a600>] pciback_publish_pci_root+0x40/0x1a0
 [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
nx4524-7AC4F0# [<ffffffff810ac53e>] ? kmem_cache_alloc+0x9e/0xf0
 [<ffffffff81010e26>] ? xen_register_device_domain_owner+0x86/0xc0
 [<ffffffff8123cc78>] pciback_publish_pci_roots+0x88/0xc0
 [<ffffffff8123a5c0>] ? pciback_publish_pci_root+0x0/0x1a0
 [<ffffffff8123aadd>] pciback_be_watch+0x1dd/0x290
 [<ffffffff81232d64>] ? xs_error+0x14/0x20
 [<ffffffff81233571>] ? xs_watch+0x51/0x60
 [<ffffffff81233b0d>] ? register_xenbus_watch+0xdd/0xf0
 [<ffffffff8123a900>] ? pciback_be_watch+0x0/0x290
 [<ffffffff8123b0a9>] pciback_xenbus_probe+0x139/0x140
 [<ffffffff81234f3a>] xenbus_dev_probe+0xaa/0x130
 [<ffffffff8127950b>] driver_probe_device+0x7b/0x160
 [<ffffffff812797e0>] ? __device_attach+0x0/0x50
 [<ffffffff8127981d>] __device_attach+0x3d/0x50
 [<ffffffff812785e8>] bus_for_each_drv+0x68/0x90
 [<ffffffff8127973b>] device_attach+0x7b/0x80
 [<ffffffff81278565>] bus_probe_device+0x25/0x40
 [<ffffffff81276ac3>] device_add+0x293/0x570
 [<ffffffff811b8da6>] ? kobject_init+0x36/0x80
 [<ffffffff81276db9>] device_register+0x19/0x20
 [<ffffffff81234780>] xenbus_probe_node+0x130/0x1b0
 [<ffffffff81234996>] xenbus_dev_changed+0x196/0x1a0
 [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff8103652b>] ? __might_sleep+0x3b/0x110
 [<ffffffff812350b6>] backend_changed+0x16/0x20
 [<ffffffff81233e4b>] xenwatch_thread+0x10b/0x150
 [<ffffffff81057d90>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff81233d40>] ? xenwatch_thread+0x0/0x150
 [<ffffffff81057c1e>] kthread+0x8e/0xa0
 [<ffffffff81014dfa>] child_rip+0xa/0x20
 [<ffffffff81013fa6>] ? int_ret_from_sys_call+0x7/0x1b

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 08:08:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 08:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RosT4-0006Gq-JW; Sun, 22 Jan 2012 08:08:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RosT3-0006Gl-8G
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 08:08:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327219675!12041969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3719 invoked from network); 22 Jan 2012 08:07:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 08:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,550,1320624000"; d="scan'208";a="10194363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jan 2012 08:07: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; Sun, 22 Jan 2012 08:07: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 1RosSw-00059f-1H;
	Sun, 22 Jan 2012 08:07:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RosSw-0007uC-0r;
	Sun, 22 Jan 2012 08:07:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11275-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 22 Jan 2012 08:07:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11275: 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 11275 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11275/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 11217
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 11217
 test-amd64-i386-win           7 windows-install             fail pass in 11217
 test-amd64-amd64-win          7 windows-install    fail in 11217 pass in 11275
 test-amd64-amd64-xl-win       7 windows-install    fail in 11217 pass in 11275

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 11217

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11217 never pass

version targeted for testing:
 xen                  80fdf2182bc6
baseline version:
 xen                  80fdf2182bc6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 Jan 22 08:08:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 08:08:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RosT4-0006Gq-JW; Sun, 22 Jan 2012 08:08:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RosT3-0006Gl-8G
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 08:08:01 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327219675!12041969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3719 invoked from network); 22 Jan 2012 08:07:55 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 08:07:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,550,1320624000"; d="scan'208";a="10194363"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	22 Jan 2012 08:07: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; Sun, 22 Jan 2012 08:07: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 1RosSw-00059f-1H;
	Sun, 22 Jan 2012 08:07:54 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RosSw-0007uC-0r;
	Sun, 22 Jan 2012 08:07:54 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11275-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 22 Jan 2012 08:07:54 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11275: 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 11275 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11275/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-credit2    7 debian-install              fail pass in 11217
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 11217
 test-amd64-i386-win           7 windows-install             fail pass in 11217
 test-amd64-amd64-win          7 windows-install    fail in 11217 pass in 11275
 test-amd64-amd64-xl-win       7 windows-install    fail in 11217 pass in 11275

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 11217

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-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  never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11217 never pass

version targeted for testing:
 xen                  80fdf2182bc6
baseline version:
 xen                  80fdf2182bc6

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 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 Jan 22 11:09:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 11:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RovHV-00072U-TK; Sun, 22 Jan 2012 11:08:17 +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 1RovHU-00072P-3D
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 11:08:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327230487!10106896!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 31285 invoked from network); 22 Jan 2012 11:08:09 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 11:08:09 -0000
Received: by pbdv4 with SMTP id v4so13350810pbd.30
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 03:08:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=8+psXNNjxhiLJ87N2hAviZ0+xGD0XCKIqby0PIBeFhQ=;
	b=cDvZFTkqkdwdnGhRdbrizZ2B8OTMp0teVkol1pvLha6zf+5HKZhNWCqXzT79CIxkVM
	3fDdS9/o7xjF6mm4WG+6EFKwPjoEf1CHm3aPxn19ZAAo20vIV//0udOnPHOFQ66n3Bbx
	DDrl/Ifveul46uDp8mBGTdOYiRRpuihPEFZrQ=
MIME-Version: 1.0
Received: by 10.68.118.136 with SMTP id km8mr12807774pbb.73.1327230485071;
	Sun, 22 Jan 2012 03:08:05 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Sun, 22 Jan 2012 03:08:04 -0800 (PST)
In-Reply-To: <1327187042.28621.140661026352253@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
	<1327187042.28621.140661026352253@webmail.messagingengine.com>
Date: Sun, 22 Jan 2012 12:08:04 +0100
X-Google-Sender-Auth: lHYRD5OshDpBi6DZIVEZfM3ZbC0
Message-ID: <CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: erin.balid@inoutbox.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzIyICA8ZXJpbi5iYWxpZEBpbm91dGJveC5jb20+Ogo+IEhpIFJvZ2VyLAo+Cj4gT24g
U2F0LCBKYW4gMjEsIDIwMTIsIGF0IDExOjU3IFBNLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+
PiAyMDEyLzEvMjEgwqA8ZXJpbi5iYWxpZEBpbm91dGJveC5jb20+Ogo+PiA+IMKgdmlmPVttYWM9
MDA6MTY6M2U6MTI6MzQ6MDEsIGJyaWRnZT1icjAgwqAsIHZpZm5hbWU9dmlmQlInXQo+Pgo+PiBU
aGUgeGwgdG9vbHN0YWNrIHByZXNlbnQgaW4gdmVyc2lvbiA0LjEuMiBkb2Vzbid0IHN1cHBvcnQg
dmlmbmFtZVswXQo+PiAobmV3ZXIgdmVyc2lvbnMgZG8pLCBzbyBJIHRoaW5rIGlmIHlvdSByZW1v
dmUgdGhhdCBpdCBzaG91bGQgYmUgb2suCj4+Cj4+IFswXSBodHRwOi8vbGlzdHMueGVuLm9yZy9h
cmNoaXZlcy9odG1sL3hlbi11c2Vycy8yMDExLTEyL21zZzAwMjI1Lmh0bWwKPgo+IFRoYXQgbG9v
a2VkIGhvcGVmdWwuCj4KPiBJIGNoYW5nZWQKPgo+IMKgLSB2aWY9W21hYz0wMDoxNjozZToxMjoz
NDowMSwgYnJpZGdlPWJyMCDCoCwgdmlmbmFtZT12aWZCUiddCj4gwqArIHZpZj1bbWFjPTAwOjE2
OjNlOjEyOjM0OjAxLCBicmlkZ2U9YnIwJ10KPgo+IGFuZCBsYXVuY2hlZCBhZ2Fpbi4gwqBJIHN0
aWxsIGVuZGVkIHVwIHdpdGggbm8gYXR0YWNoZWQgVklGIGludGVyZmFjZS4KPgo+IGJyY3RsIHNo
b3cKPiDCoGJyaWRnZSBuYW1lIMKgIMKgIGJyaWRnZSBpZCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBT
VFAgZW5hYmxlZCDCoCDCoCBpbnRlcmZhY2VzCj4gwqBicjAgwqAgwqAgwqAgwqAgwqAgwqAgODAw
MC4wMDUyMzUxZDUzMzcgwqAgwqAgwqAgeWVzIMKgIMKgIMKgIMKgIMKgIMKgIGV0aDAKPgo+IHhs
IGxpc3Qtdm0gdGVtcGxhdGUKPiDCoFVVSUQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqBJRCDCoCDCoG5hbWUKPiDCoDdkNDZjYTlhLTlkODYtNDc2ZS05
NDhkLTNlZGRmNWQwNzBlNCDCoDQgwqAgwqB0ZXN0Cj4KPiB4bCBuZXR3b3JrLWxpc3QgdGVtcGxh
dGUKPiDCoElkeCBCRSBNYWMgQWRkci4gwqAgwqAgwqAgwqAgaGFuZGxlIHN0YXRlIGV2dC1jaCDC
oCB0eC0vcngtcmluZy1yZWYgQkUtcGF0aAo+IMKgMCDCoCAwIMKgMDA6MTY6M2U6MTI6MzQ6MDEg
wqAgwqAgwqAwIMKgIMKgIDQgwqAgwqAgMTUgwqAgNzY4Lzc2OQo+IMKgL2xvY2FsL2RvbWFpbi8w
L2JhY2tlbmQvdmlmLzQvMAo+Cj4gQW5kLCBJIHN0aWxsIGNhbid0IHBpbmcganVzdCBsaWtlIG15
IG9yZ2luYWwgcG9zdC4KCkNhbiB5b3UgcG9zdCAiaWZjb25maWcgLWEiIG91dHB1dCBmcm9tIHRo
ZSBEb21VIHdoZW4gbGF1bmNoZWQgd2l0aCB4bC4KQWxzbyBwYXN0ZSB0aGUgb3V0cHV0IGZyb20g
InhlbnN0b3JlLWxzIC1mcCIgb24gdGhlIERvbTAgd2hlbiB0aGUgeGwKRG9tVSBpcyB1cCBhbmQg
cnVubmluZy4gRnJvbSB3aGF0IEkgc2F3IGFib3ZlIGluIC92YXIvbG9nL21lc3NhZ2VzIHRoZQpw
cm9ibGVtIHNlZW0gdG8gYmUgcmVsYXRlZCB0byBob3RwbHVnIHNjcmlwdHMuCgo+IDotKAo+Cj4g
UmVnYXJkcywKPgo+IEVyaW4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 22 11:09:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 11:09:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RovHV-00072U-TK; Sun, 22 Jan 2012 11:08:17 +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 1RovHU-00072P-3D
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 11:08:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327230487!10106896!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 31285 invoked from network); 22 Jan 2012 11:08:09 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 11:08:09 -0000
Received: by pbdv4 with SMTP id v4so13350810pbd.30
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 03:08:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=8+psXNNjxhiLJ87N2hAviZ0+xGD0XCKIqby0PIBeFhQ=;
	b=cDvZFTkqkdwdnGhRdbrizZ2B8OTMp0teVkol1pvLha6zf+5HKZhNWCqXzT79CIxkVM
	3fDdS9/o7xjF6mm4WG+6EFKwPjoEf1CHm3aPxn19ZAAo20vIV//0udOnPHOFQ66n3Bbx
	DDrl/Ifveul46uDp8mBGTdOYiRRpuihPEFZrQ=
MIME-Version: 1.0
Received: by 10.68.118.136 with SMTP id km8mr12807774pbb.73.1327230485071;
	Sun, 22 Jan 2012 03:08:05 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Sun, 22 Jan 2012 03:08:04 -0800 (PST)
In-Reply-To: <1327187042.28621.140661026352253@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
	<1327187042.28621.140661026352253@webmail.messagingengine.com>
Date: Sun, 22 Jan 2012 12:08:04 +0100
X-Google-Sender-Auth: lHYRD5OshDpBi6DZIVEZfM3ZbC0
Message-ID: <CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: erin.balid@inoutbox.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzIyICA8ZXJpbi5iYWxpZEBpbm91dGJveC5jb20+Ogo+IEhpIFJvZ2VyLAo+Cj4gT24g
U2F0LCBKYW4gMjEsIDIwMTIsIGF0IDExOjU3IFBNLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+
PiAyMDEyLzEvMjEgwqA8ZXJpbi5iYWxpZEBpbm91dGJveC5jb20+Ogo+PiA+IMKgdmlmPVttYWM9
MDA6MTY6M2U6MTI6MzQ6MDEsIGJyaWRnZT1icjAgwqAsIHZpZm5hbWU9dmlmQlInXQo+Pgo+PiBU
aGUgeGwgdG9vbHN0YWNrIHByZXNlbnQgaW4gdmVyc2lvbiA0LjEuMiBkb2Vzbid0IHN1cHBvcnQg
dmlmbmFtZVswXQo+PiAobmV3ZXIgdmVyc2lvbnMgZG8pLCBzbyBJIHRoaW5rIGlmIHlvdSByZW1v
dmUgdGhhdCBpdCBzaG91bGQgYmUgb2suCj4+Cj4+IFswXSBodHRwOi8vbGlzdHMueGVuLm9yZy9h
cmNoaXZlcy9odG1sL3hlbi11c2Vycy8yMDExLTEyL21zZzAwMjI1Lmh0bWwKPgo+IFRoYXQgbG9v
a2VkIGhvcGVmdWwuCj4KPiBJIGNoYW5nZWQKPgo+IMKgLSB2aWY9W21hYz0wMDoxNjozZToxMjoz
NDowMSwgYnJpZGdlPWJyMCDCoCwgdmlmbmFtZT12aWZCUiddCj4gwqArIHZpZj1bbWFjPTAwOjE2
OjNlOjEyOjM0OjAxLCBicmlkZ2U9YnIwJ10KPgo+IGFuZCBsYXVuY2hlZCBhZ2Fpbi4gwqBJIHN0
aWxsIGVuZGVkIHVwIHdpdGggbm8gYXR0YWNoZWQgVklGIGludGVyZmFjZS4KPgo+IGJyY3RsIHNo
b3cKPiDCoGJyaWRnZSBuYW1lIMKgIMKgIGJyaWRnZSBpZCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBT
VFAgZW5hYmxlZCDCoCDCoCBpbnRlcmZhY2VzCj4gwqBicjAgwqAgwqAgwqAgwqAgwqAgwqAgODAw
MC4wMDUyMzUxZDUzMzcgwqAgwqAgwqAgeWVzIMKgIMKgIMKgIMKgIMKgIMKgIGV0aDAKPgo+IHhs
IGxpc3Qtdm0gdGVtcGxhdGUKPiDCoFVVSUQgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqBJRCDCoCDCoG5hbWUKPiDCoDdkNDZjYTlhLTlkODYtNDc2ZS05
NDhkLTNlZGRmNWQwNzBlNCDCoDQgwqAgwqB0ZXN0Cj4KPiB4bCBuZXR3b3JrLWxpc3QgdGVtcGxh
dGUKPiDCoElkeCBCRSBNYWMgQWRkci4gwqAgwqAgwqAgwqAgaGFuZGxlIHN0YXRlIGV2dC1jaCDC
oCB0eC0vcngtcmluZy1yZWYgQkUtcGF0aAo+IMKgMCDCoCAwIMKgMDA6MTY6M2U6MTI6MzQ6MDEg
wqAgwqAgwqAwIMKgIMKgIDQgwqAgwqAgMTUgwqAgNzY4Lzc2OQo+IMKgL2xvY2FsL2RvbWFpbi8w
L2JhY2tlbmQvdmlmLzQvMAo+Cj4gQW5kLCBJIHN0aWxsIGNhbid0IHBpbmcganVzdCBsaWtlIG15
IG9yZ2luYWwgcG9zdC4KCkNhbiB5b3UgcG9zdCAiaWZjb25maWcgLWEiIG91dHB1dCBmcm9tIHRo
ZSBEb21VIHdoZW4gbGF1bmNoZWQgd2l0aCB4bC4KQWxzbyBwYXN0ZSB0aGUgb3V0cHV0IGZyb20g
InhlbnN0b3JlLWxzIC1mcCIgb24gdGhlIERvbTAgd2hlbiB0aGUgeGwKRG9tVSBpcyB1cCBhbmQg
cnVubmluZy4gRnJvbSB3aGF0IEkgc2F3IGFib3ZlIGluIC92YXIvbG9nL21lc3NhZ2VzIHRoZQpw
cm9ibGVtIHNlZW0gdG8gYmUgcmVsYXRlZCB0byBob3RwbHVnIHNjcmlwdHMuCgo+IDotKAo+Cj4g
UmVnYXJkcywKPgo+IEVyaW4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 22 15:50:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 15:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rozfz-0008TM-Rg; Sun, 22 Jan 2012 15:49:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rozfx-0008TH-Qf
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 15:49:50 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327247257!49580658!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10743 invoked from network); 22 Jan 2012 15:47:38 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jan 2012 15:47:38 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0MFnh4Q018168;
	Sun, 22 Jan 2012 10:49:44 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 22 Jan 2012 10:49:26 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451C5@mnetexch2.adamapps.host>
In-Reply-To: <1327176409.25269.140661026313477@webmail.messagingengine.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
Thread-Index: AczYeVZjimK0i1pTQWKOZpnNnU7lXAAo51vQ
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
From: <djmagee@mageenet.net>
To: <erin.balid@inoutbox.com>, <xen-devel@lists.xensource.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> cat test.cfg
>  name='test'
>  builder='linux'
>  bootloader='/usr/bin/pygrub'
>  disk=['phy:/dev/XenVols/test,xvda,w']
>  vif=[mac=00:16:3e:12:34:01, bridge=br0  , vifname=vifBR']

You're missing the opening single quote on your vif line.  I'm not sure how the guest started at all, when I try it this way I get a parse error on xl create.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 15:50:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 15:50:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rozfz-0008TM-Rg; Sun, 22 Jan 2012 15:49:51 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rozfx-0008TH-Qf
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 15:49:50 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327247257!49580658!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10743 invoked from network); 22 Jan 2012 15:47:38 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jan 2012 15:47:38 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0MFnh4Q018168;
	Sun, 22 Jan 2012 10:49:44 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sun, 22 Jan 2012 10:49:26 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451C5@mnetexch2.adamapps.host>
In-Reply-To: <1327176409.25269.140661026313477@webmail.messagingengine.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
Thread-Index: AczYeVZjimK0i1pTQWKOZpnNnU7lXAAo51vQ
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
From: <djmagee@mageenet.net>
To: <erin.balid@inoutbox.com>, <xen-devel@lists.xensource.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> cat test.cfg
>  name='test'
>  builder='linux'
>  bootloader='/usr/bin/pygrub'
>  disk=['phy:/dev/XenVols/test,xvda,w']
>  vif=[mac=00:16:3e:12:34:01, bridge=br0  , vifname=vifBR']

You're missing the opening single quote on your vif line.  I'm not sure how the guest started at all, when I try it this way I get a parse error on xl create.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 17:12:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 17:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp0ww-0000nS-6F; Sun, 22 Jan 2012 17:11:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rp0wu-0000nN-4r
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 17:11:24 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327252277!11896467!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzY4MDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13625 invoked from network); 22 Jan 2012 17:11:17 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jan 2012 17:11:17 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 123A42056C
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 12:11:17 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute5.internal (MEProxy); Sun, 22 Jan 2012 12:11:17 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	vy0g2hL3lYeUI20D7zyShKQV/uU=; b=ILdZ5USG+8SiDIu2EqIuJ4bvV8TZywcl
	dUrjAr9KyRXuQa0Yw56v8R0hxyka3ngZe3bjXT/7426aCNi/qOgrm9Lp50mgyxsF
	BmZJ/zIy337sMGahWiFgJFcHw3rjsPWceknP8eQQyfm2c+b1LxW5t8tJ7MA5A/Yv
	PdSX3wwJ55c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=vy0g2hL3lYeUI20D7zyShKQV/uU=; b=
	lclF5d3Zlt3yFBtySkrS+UMxsGZm958rQcrUTUqR5pZNlZ7ljFH8+MddFNEhQITw
	BhJdke/LkbkAzmlNECV5XgKTw8bqViBDvLh7+f4P5jgqv2PqDJJR8YE11b0HuzF4
	ngpwcRnCauGmSkbBHWs/I3F0xT0fC1EMcgk++fo/jz0=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id DE1F6A00082; Sun, 22 Jan 2012 12:11:16 -0500 (EST)
Message-Id: <1327252276.343.140661026559797@webmail.messagingengine.com>
X-Sasl-Enc: HB401DSIrVDw6yPymmIV9GasoXH4yEVtqamVO+J4hhAT 1327252276
From: erin.balid@inoutbox.com
To: =?ISO-8859-1?Q?Roger=20Pau=20Monn=E9?= <roger.pau@entel.upc.edu>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com>
	<CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com>
In-Reply-To: <CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com>
Date: Sun, 22 Jan 2012 09:11:16 -0800
Cc: xen-devel@lists.xensource.com, djmagee@mageenet.net
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Roger.

Here is "ifconfig -a" output from the DomU when launched with xm.

xm create test.cfg
xm list
 Name                                        ID   Mem VCPUs      State  
 Time(s)
 Domain-0                                     0  1010     1     r-----  
  913.4
 template                                     1  2048     2     -b----  
   86.0
xm console template
 ...
ifconfig -a
 eth0      Link encap:Ethernet  HWaddr 00:16:3E:12:34:01
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:38658 errors:0 dropped:24935 overruns:0 frame:0
           TX packets:11009 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:2621879 (2.5 Mb)  TX bytes:10432153 (9.9 Mb)
 
 eth0:1    Link encap:Ethernet  HWaddr 00:16:3E:12:34:01
           inet addr:192.168.1.32   Bcast:192.168.1.255 
           Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
 lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:7 errors:0 dropped:0 overruns:0 frame:0
           TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:563 (563.0 b)  TX bytes:563 (563.0 b)


And, "ifconfig -a" output from the DomU when launched with xl.

xl create test.cfg
xl list
 Name                                        ID   Mem VCPUs      State  
 Time(s)
 Domain-0                                     0  1010     1     r-----  
    66.8
 template                                     1  2048     2     -b----  
     6.8

ifconfig -a
 eth0      Link encap:Ethernet  HWaddr 00:16:3E:12:34:01
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:5241 (5.1 Kb)
 
 eth0:1    Link encap:Ethernet  HWaddr 00:16:3E:12:34:01
           inet addr:192.168.1.32   Bcast:192.168.1.255 
           Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
 lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:52 errors:0 dropped:0 overruns:0 frame:0
           TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:4431 (4.3 Kb)  TX bytes:4431 (4.3 Kb)

> Also paste the output from "xenstore-ls -fp" on the Dom0 when the xl
> DomU is up and running. From what I saw above in /var/log/messages the
> problem seem to be related to hotplug scripts.

Here is the paste of that output. ===> http://pastebin.com/s0e03VnW


On Sun, Jan 22, 2012, at 10:49 AM, djmagee@mageenet.net wrote:
> You're missing the opening single quote on your vif line.

That's just a copy/paste typo in the email.

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 17:12:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 17:12:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp0ww-0000nS-6F; Sun, 22 Jan 2012 17:11:26 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rp0wu-0000nN-4r
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 17:11:24 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327252277!11896467!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzY4MDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13625 invoked from network); 22 Jan 2012 17:11:17 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jan 2012 17:11:17 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 123A42056C
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 12:11:17 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute5.internal (MEProxy); Sun, 22 Jan 2012 12:11:17 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	vy0g2hL3lYeUI20D7zyShKQV/uU=; b=ILdZ5USG+8SiDIu2EqIuJ4bvV8TZywcl
	dUrjAr9KyRXuQa0Yw56v8R0hxyka3ngZe3bjXT/7426aCNi/qOgrm9Lp50mgyxsF
	BmZJ/zIy337sMGahWiFgJFcHw3rjsPWceknP8eQQyfm2c+b1LxW5t8tJ7MA5A/Yv
	PdSX3wwJ55c=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=vy0g2hL3lYeUI20D7zyShKQV/uU=; b=
	lclF5d3Zlt3yFBtySkrS+UMxsGZm958rQcrUTUqR5pZNlZ7ljFH8+MddFNEhQITw
	BhJdke/LkbkAzmlNECV5XgKTw8bqViBDvLh7+f4P5jgqv2PqDJJR8YE11b0HuzF4
	ngpwcRnCauGmSkbBHWs/I3F0xT0fC1EMcgk++fo/jz0=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id DE1F6A00082; Sun, 22 Jan 2012 12:11:16 -0500 (EST)
Message-Id: <1327252276.343.140661026559797@webmail.messagingengine.com>
X-Sasl-Enc: HB401DSIrVDw6yPymmIV9GasoXH4yEVtqamVO+J4hhAT 1327252276
From: erin.balid@inoutbox.com
To: =?ISO-8859-1?Q?Roger=20Pau=20Monn=E9?= <roger.pau@entel.upc.edu>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com>
	<CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com>
In-Reply-To: <CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com>
Date: Sun, 22 Jan 2012 09:11:16 -0800
Cc: xen-devel@lists.xensource.com, djmagee@mageenet.net
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Roger.

Here is "ifconfig -a" output from the DomU when launched with xm.

xm create test.cfg
xm list
 Name                                        ID   Mem VCPUs      State  
 Time(s)
 Domain-0                                     0  1010     1     r-----  
  913.4
 template                                     1  2048     2     -b----  
   86.0
xm console template
 ...
ifconfig -a
 eth0      Link encap:Ethernet  HWaddr 00:16:3E:12:34:01
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:38658 errors:0 dropped:24935 overruns:0 frame:0
           TX packets:11009 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:2621879 (2.5 Mb)  TX bytes:10432153 (9.9 Mb)
 
 eth0:1    Link encap:Ethernet  HWaddr 00:16:3E:12:34:01
           inet addr:192.168.1.32   Bcast:192.168.1.255 
           Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
 lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:7 errors:0 dropped:0 overruns:0 frame:0
           TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:563 (563.0 b)  TX bytes:563 (563.0 b)


And, "ifconfig -a" output from the DomU when launched with xl.

xl create test.cfg
xl list
 Name                                        ID   Mem VCPUs      State  
 Time(s)
 Domain-0                                     0  1010     1     r-----  
    66.8
 template                                     1  2048     2     -b----  
     6.8

ifconfig -a
 eth0      Link encap:Ethernet  HWaddr 00:16:3E:12:34:01
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:5241 (5.1 Kb)
 
 eth0:1    Link encap:Ethernet  HWaddr 00:16:3E:12:34:01
           inet addr:192.168.1.32   Bcast:192.168.1.255 
           Mask:255.255.255.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 
 lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:52 errors:0 dropped:0 overruns:0 frame:0
           TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:4431 (4.3 Kb)  TX bytes:4431 (4.3 Kb)

> Also paste the output from "xenstore-ls -fp" on the Dom0 when the xl
> DomU is up and running. From what I saw above in /var/log/messages the
> problem seem to be related to hotplug scripts.

Here is the paste of that output. ===> http://pastebin.com/s0e03VnW


On Sun, Jan 22, 2012, at 10:49 AM, djmagee@mageenet.net wrote:
> You're missing the opening single quote on your vif line.

That's just a copy/paste typo in the email.

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 17:29:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 17:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp1DU-0000zK-Q8; Sun, 22 Jan 2012 17:28: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 1Rp1DT-0000zF-89
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 17:28:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327253302!10200621!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 20943 invoked from network); 22 Jan 2012 17:28:24 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 17:28:24 -0000
Received: by dajs34 with SMTP id s34so14326207daj.30
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 09:28: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=5v+tGrRfhHdl0wUV8g2cDdAlmMOM1O22we0eDm7rFlY=;
	b=LGs+WvoUiL940Kczgvo/tt1jeDOYJNaNK1xo9QY10htIhe8Anq8ll+ZkHcEjXZ2xWj
	2JulvQCGM5u2ACUvAdx5evIwm5GmXqtHN1XJqLg0ZP6v4b2XYAdI7XaT4D8s58RmxGwy
	cyxrt5xgxnCzPw8vHjE0a8E/kzhwrihuWTm2A=
MIME-Version: 1.0
Received: by 10.68.74.132 with SMTP id t4mr15012756pbv.22.1327253300816; Sun,
	22 Jan 2012 09:28:20 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Sun, 22 Jan 2012 09:28:20 -0800 (PST)
In-Reply-To: <1327252276.343.140661026559797@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
	<1327187042.28621.140661026352253@webmail.messagingengine.com>
	<CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com>
	<1327252276.343.140661026559797@webmail.messagingengine.com>
Date: Sun, 22 Jan 2012 18:28:20 +0100
X-Google-Sender-Auth: fgPGjhrKy6qyKLZj8sm5aH-XVYw
Message-ID: <CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: erin.balid@inoutbox.com
Cc: xen-devel@lists.xensource.com, djmagee@mageenet.net
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzIyICA8ZXJpbi5iYWxpZEBpbm91dGJveC5jb20+Ogo+IEhpIFJvZ2VyLgo+Cj4gSGVy
ZSBpcyAiaWZjb25maWcgLWEiIG91dHB1dCBmcm9tIHRoZSBEb21VIHdoZW4gbGF1bmNoZWQgd2l0
aCB4bS4KPgo+IHhtIGNyZWF0ZSB0ZXN0LmNmZwo+IHhtIGxpc3QKPiDCoE5hbWUgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJRCDCoCBN
ZW0gVkNQVXMgwqAgwqAgwqBTdGF0ZQo+IMKgVGltZShzKQo+IMKgRG9tYWluLTAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMCDCoDEwMTAgwqAg
wqAgMSDCoCDCoCByLS0tLS0KPiDCoDkxMy40Cj4gwqB0ZW1wbGF0ZSDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAxIMKgMjA0OCDCoCDCoCAyIMKg
IMKgIC1iLS0tLQo+IMKgIDg2LjAKPiB4bSBjb25zb2xlIHRlbXBsYXRlCj4gwqAuLi4KPiBpZmNv
bmZpZyAtYQo+IMKgZXRoMCDCoCDCoCDCoExpbmsgZW5jYXA6RXRoZXJuZXQgwqBIV2FkZHIgMDA6
MTY6M0U6MTI6MzQ6MDEKPiDCoCDCoCDCoCDCoCDCoCBVUCBCUk9BRENBU1QgUlVOTklORyBNVUxU
SUNBU1QgwqBNVFU6MTUwMCDCoE1ldHJpYzoxCj4gwqAgwqAgwqAgwqAgwqAgUlggcGFja2V0czoz
ODY1OCBlcnJvcnM6MCBkcm9wcGVkOjI0OTM1IG92ZXJydW5zOjAgZnJhbWU6MAo+IMKgIMKgIMKg
IMKgIMKgIFRYIHBhY2tldHM6MTEwMDkgZXJyb3JzOjAgZHJvcHBlZDowIG92ZXJydW5zOjAgY2Fy
cmllcjowCj4gwqAgwqAgwqAgwqAgwqAgY29sbGlzaW9uczowIHR4cXVldWVsZW46MTAwMAo+IMKg
IMKgIMKgIMKgIMKgIFJYIGJ5dGVzOjI2MjE4NzkgKDIuNSBNYikgwqBUWCBieXRlczoxMDQzMjE1
MyAoOS45IE1iKQo+Cj4gwqBldGgwOjEgwqAgwqBMaW5rIGVuY2FwOkV0aGVybmV0IMKgSFdhZGRy
IDAwOjE2OjNFOjEyOjM0OjAxCj4gwqAgwqAgwqAgwqAgwqAgaW5ldCBhZGRyOjE5Mi4xNjguMS4z
MiDCoCBCY2FzdDoxOTIuMTY4LjEuMjU1Cj4gwqAgwqAgwqAgwqAgwqAgTWFzazoyNTUuMjU1LjI1
NS4wCj4gwqAgwqAgwqAgwqAgwqAgVVAgQlJPQURDQVNUIFJVTk5JTkcgTVVMVElDQVNUIMKgTVRV
OjE1MDAgwqBNZXRyaWM6MQo+Cj4gwqBsbyDCoCDCoCDCoCDCoExpbmsgZW5jYXA6TG9jYWwgTG9v
cGJhY2sKPiDCoCDCoCDCoCDCoCDCoCBpbmV0IGFkZHI6MTI3LjAuMC4xIMKgTWFzazoyNTUuMC4w
LjAKPiDCoCDCoCDCoCDCoCDCoCBVUCBMT09QQkFDSyBSVU5OSU5HIMKgTVRVOjE2NDM2IMKgTWV0
cmljOjEKPiDCoCDCoCDCoCDCoCDCoCBSWCBwYWNrZXRzOjcgZXJyb3JzOjAgZHJvcHBlZDowIG92
ZXJydW5zOjAgZnJhbWU6MAo+IMKgIMKgIMKgIMKgIMKgIFRYIHBhY2tldHM6NyBlcnJvcnM6MCBk
cm9wcGVkOjAgb3ZlcnJ1bnM6MCBjYXJyaWVyOjAKPiDCoCDCoCDCoCDCoCDCoCBjb2xsaXNpb25z
OjAgdHhxdWV1ZWxlbjowCj4gwqAgwqAgwqAgwqAgwqAgUlggYnl0ZXM6NTYzICg1NjMuMCBiKSDC
oFRYIGJ5dGVzOjU2MyAoNTYzLjAgYikKPgo+Cj4gQW5kLCAiaWZjb25maWcgLWEiIG91dHB1dCBm
cm9tIHRoZSBEb21VIHdoZW4gbGF1bmNoZWQgd2l0aCB4bC4KPgo+IHhsIGNyZWF0ZSB0ZXN0LmNm
Zwo+IHhsIGxpc3QKPiDCoE5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJRCDCoCBNZW0gVkNQVXMgwqAgwqAgwqBTdGF0ZQo+IMKg
VGltZShzKQo+IMKgRG9tYWluLTAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgMCDCoDEwMTAgwqAgwqAgMSDCoCDCoCByLS0tLS0KPiDCoCDCoDY2
LjgKPiDCoHRlbXBsYXRlIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIDEgwqAyMDQ4IMKgIMKgIDIgwqAgwqAgLWItLS0tCj4gwqAgwqAgNi44Cj4K
PiBpZmNvbmZpZyAtYQo+IMKgZXRoMCDCoCDCoCDCoExpbmsgZW5jYXA6RXRoZXJuZXQgwqBIV2Fk
ZHIgMDA6MTY6M0U6MTI6MzQ6MDEKPiDCoCDCoCDCoCDCoCDCoCBVUCBCUk9BRENBU1QgUlVOTklO
RyBNVUxUSUNBU1QgwqBNVFU6MTUwMCDCoE1ldHJpYzoxCj4gwqAgwqAgwqAgwqAgwqAgUlggcGFj
a2V0czowIGVycm9yczowIGRyb3BwZWQ6MCBvdmVycnVuczowIGZyYW1lOjAKPiDCoCDCoCDCoCDC
oCDCoCBUWCBwYWNrZXRzOjExNCBlcnJvcnM6MCBkcm9wcGVkOjAgb3ZlcnJ1bnM6MCBjYXJyaWVy
OjAKPiDCoCDCoCDCoCDCoCDCoCBjb2xsaXNpb25zOjAgdHhxdWV1ZWxlbjoxMDAwCj4gwqAgwqAg
wqAgwqAgwqAgUlggYnl0ZXM6MCAoMC4wIGIpIMKgVFggYnl0ZXM6NTI0MSAoNS4xIEtiKQo+Cj4g
wqBldGgwOjEgwqAgwqBMaW5rIGVuY2FwOkV0aGVybmV0IMKgSFdhZGRyIDAwOjE2OjNFOjEyOjM0
OjAxCj4gwqAgwqAgwqAgwqAgwqAgaW5ldCBhZGRyOjE5Mi4xNjguMS4zMiDCoCBCY2FzdDoxOTIu
MTY4LjEuMjU1Cj4gwqAgwqAgwqAgwqAgwqAgTWFzazoyNTUuMjU1LjI1NS4wCj4gwqAgwqAgwqAg
wqAgwqAgVVAgQlJPQURDQVNUIFJVTk5JTkcgTVVMVElDQVNUIMKgTVRVOjE1MDAgwqBNZXRyaWM6
MQo+Cj4gwqBsbyDCoCDCoCDCoCDCoExpbmsgZW5jYXA6TG9jYWwgTG9vcGJhY2sKPiDCoCDCoCDC
oCDCoCDCoCBpbmV0IGFkZHI6MTI3LjAuMC4xIMKgTWFzazoyNTUuMC4wLjAKPiDCoCDCoCDCoCDC
oCDCoCBVUCBMT09QQkFDSyBSVU5OSU5HIMKgTVRVOjE2NDM2IMKgTWV0cmljOjEKPiDCoCDCoCDC
oCDCoCDCoCBSWCBwYWNrZXRzOjUyIGVycm9yczowIGRyb3BwZWQ6MCBvdmVycnVuczowIGZyYW1l
OjAKPiDCoCDCoCDCoCDCoCDCoCBUWCBwYWNrZXRzOjUyIGVycm9yczowIGRyb3BwZWQ6MCBvdmVy
cnVuczowIGNhcnJpZXI6MAo+IMKgIMKgIMKgIMKgIMKgIGNvbGxpc2lvbnM6MCB0eHF1ZXVlbGVu
OjAKPiDCoCDCoCDCoCDCoCDCoCBSWCBieXRlczo0NDMxICg0LjMgS2IpIMKgVFggYnl0ZXM6NDQz
MSAoNC4zIEtiKQo+Cj4+IEFsc28gcGFzdGUgdGhlIG91dHB1dCBmcm9tICJ4ZW5zdG9yZS1scyAt
ZnAiIG9uIHRoZSBEb20wIHdoZW4gdGhlIHhsCj4+IERvbVUgaXMgdXAgYW5kIHJ1bm5pbmcuIEZy
b20gd2hhdCBJIHNhdyBhYm92ZSBpbiAvdmFyL2xvZy9tZXNzYWdlcyB0aGUKPj4gcHJvYmxlbSBz
ZWVtIHRvIGJlIHJlbGF0ZWQgdG8gaG90cGx1ZyBzY3JpcHRzLgo+Cj4gSGVyZSBpcyB0aGUgcGFz
dGUgb2YgdGhhdCBvdXRwdXQuID09PT4gaHR0cDovL3Bhc3RlYmluLmNvbS9zMGUwM1ZuVwoKCkFw
YXJ0IGZyb20gdGhlIGZhY3QgdGhhdCB5b3UgaGF2ZSBxdWl0ZSBhIGxvdCBvZiBqdW5rIGluIHhl
bnN0b3JlIEkKZG9uJ3Qgc2VlIGFueXRoaW5nIHN0cmFuZ2UsIGRldmljZXMgc2VlbSB0byBiZSBj
b25uZWN0ZWQgb2suIEkndmUKcmVhbGl6ZWQgdGhhdCB5b3UgaGF2ZSBpbnN0YWxsZWQKcGF0dGVy
bnMtb3BlblNVU0UteGVuX3NlcnZlci0xMi4xLTI1LjIxLjEueDg2XzY0LCB3aGF0J3MgdGhpcz8g
SSd2ZQpuZXZlciB1c2VkIFhlbiB3aXRoIE9wZW5TVVNFLCBidXQgdGhpcyBzZWVtcyByZWxhdGVk
IHRvIFhlblNlcnZlcgpjb21lcmNpYWwgdmVyc2lvbiwgbm90IG9wZW4gc291cmNlIFhlbi4gTWF5
YmUgc29tZW9uZSBmYW1pbGlhciB3aXRoClhlbiBvbiBPcGVuU1VTRSBjYW4gcHJvdmlkZSBtb3Jl
IGhlbHBmdWwgaW5mb3JtYXRpb24uCgpUaGUgb25seSBzdHJhbmdlIHRoaW5nIEkgc2VlIGFyZSB0
aGUgaG90cGx1ZyBlcnJvciBtZXNzYWdlcyBpbgovdmFyL2xvZy9tZXNzYWdlcywgYnV0IEkgZG9u
J3Qga25vdyB3aGF0IGNvdWxkIGNhdXNlIHRoZW0uIE1heWJlIG9sZAp1ZGV2IHJ1bGVzIG9yIGhv
dHBsdWcgc2NyaXB0cyB0aGF0IGRpZG4ndCBnZXQgY2xlYW5lZCB3aGVuIHVwZGF0aW5nPwoKPiBP
biBTdW4sIEphbiAyMiwgMjAxMiwgYXQgMTA6NDkgQU0sIGRqbWFnZWVAbWFnZWVuZXQubmV0IHdy
b3RlOgo+PiBZb3UncmUgbWlzc2luZyB0aGUgb3BlbmluZyBzaW5nbGUgcXVvdGUgb24geW91ciB2
aWYgbGluZS4KPgo+IFRoYXQncyBqdXN0IGEgY29weS9wYXN0ZSB0eXBvIGluIHRoZSBlbWFpbC4K
Pgo+IFJlZ2FyZHMsCj4KPiBFcmluCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 22 17:29:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 17:29:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp1DU-0000zK-Q8; Sun, 22 Jan 2012 17:28: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 1Rp1DT-0000zF-89
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 17:28:31 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327253302!10200621!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 20943 invoked from network); 22 Jan 2012 17:28:24 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 17:28:24 -0000
Received: by dajs34 with SMTP id s34so14326207daj.30
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 09:28: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=5v+tGrRfhHdl0wUV8g2cDdAlmMOM1O22we0eDm7rFlY=;
	b=LGs+WvoUiL940Kczgvo/tt1jeDOYJNaNK1xo9QY10htIhe8Anq8ll+ZkHcEjXZ2xWj
	2JulvQCGM5u2ACUvAdx5evIwm5GmXqtHN1XJqLg0ZP6v4b2XYAdI7XaT4D8s58RmxGwy
	cyxrt5xgxnCzPw8vHjE0a8E/kzhwrihuWTm2A=
MIME-Version: 1.0
Received: by 10.68.74.132 with SMTP id t4mr15012756pbv.22.1327253300816; Sun,
	22 Jan 2012 09:28:20 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Sun, 22 Jan 2012 09:28:20 -0800 (PST)
In-Reply-To: <1327252276.343.140661026559797@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com>
	<1327187042.28621.140661026352253@webmail.messagingengine.com>
	<CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com>
	<1327252276.343.140661026559797@webmail.messagingengine.com>
Date: Sun, 22 Jan 2012 18:28:20 +0100
X-Google-Sender-Auth: fgPGjhrKy6qyKLZj8sm5aH-XVYw
Message-ID: <CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: erin.balid@inoutbox.com
Cc: xen-devel@lists.xensource.com, djmagee@mageenet.net
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzIyICA8ZXJpbi5iYWxpZEBpbm91dGJveC5jb20+Ogo+IEhpIFJvZ2VyLgo+Cj4gSGVy
ZSBpcyAiaWZjb25maWcgLWEiIG91dHB1dCBmcm9tIHRoZSBEb21VIHdoZW4gbGF1bmNoZWQgd2l0
aCB4bS4KPgo+IHhtIGNyZWF0ZSB0ZXN0LmNmZwo+IHhtIGxpc3QKPiDCoE5hbWUgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJRCDCoCBN
ZW0gVkNQVXMgwqAgwqAgwqBTdGF0ZQo+IMKgVGltZShzKQo+IMKgRG9tYWluLTAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgMCDCoDEwMTAgwqAg
wqAgMSDCoCDCoCByLS0tLS0KPiDCoDkxMy40Cj4gwqB0ZW1wbGF0ZSDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAxIMKgMjA0OCDCoCDCoCAyIMKg
IMKgIC1iLS0tLQo+IMKgIDg2LjAKPiB4bSBjb25zb2xlIHRlbXBsYXRlCj4gwqAuLi4KPiBpZmNv
bmZpZyAtYQo+IMKgZXRoMCDCoCDCoCDCoExpbmsgZW5jYXA6RXRoZXJuZXQgwqBIV2FkZHIgMDA6
MTY6M0U6MTI6MzQ6MDEKPiDCoCDCoCDCoCDCoCDCoCBVUCBCUk9BRENBU1QgUlVOTklORyBNVUxU
SUNBU1QgwqBNVFU6MTUwMCDCoE1ldHJpYzoxCj4gwqAgwqAgwqAgwqAgwqAgUlggcGFja2V0czoz
ODY1OCBlcnJvcnM6MCBkcm9wcGVkOjI0OTM1IG92ZXJydW5zOjAgZnJhbWU6MAo+IMKgIMKgIMKg
IMKgIMKgIFRYIHBhY2tldHM6MTEwMDkgZXJyb3JzOjAgZHJvcHBlZDowIG92ZXJydW5zOjAgY2Fy
cmllcjowCj4gwqAgwqAgwqAgwqAgwqAgY29sbGlzaW9uczowIHR4cXVldWVsZW46MTAwMAo+IMKg
IMKgIMKgIMKgIMKgIFJYIGJ5dGVzOjI2MjE4NzkgKDIuNSBNYikgwqBUWCBieXRlczoxMDQzMjE1
MyAoOS45IE1iKQo+Cj4gwqBldGgwOjEgwqAgwqBMaW5rIGVuY2FwOkV0aGVybmV0IMKgSFdhZGRy
IDAwOjE2OjNFOjEyOjM0OjAxCj4gwqAgwqAgwqAgwqAgwqAgaW5ldCBhZGRyOjE5Mi4xNjguMS4z
MiDCoCBCY2FzdDoxOTIuMTY4LjEuMjU1Cj4gwqAgwqAgwqAgwqAgwqAgTWFzazoyNTUuMjU1LjI1
NS4wCj4gwqAgwqAgwqAgwqAgwqAgVVAgQlJPQURDQVNUIFJVTk5JTkcgTVVMVElDQVNUIMKgTVRV
OjE1MDAgwqBNZXRyaWM6MQo+Cj4gwqBsbyDCoCDCoCDCoCDCoExpbmsgZW5jYXA6TG9jYWwgTG9v
cGJhY2sKPiDCoCDCoCDCoCDCoCDCoCBpbmV0IGFkZHI6MTI3LjAuMC4xIMKgTWFzazoyNTUuMC4w
LjAKPiDCoCDCoCDCoCDCoCDCoCBVUCBMT09QQkFDSyBSVU5OSU5HIMKgTVRVOjE2NDM2IMKgTWV0
cmljOjEKPiDCoCDCoCDCoCDCoCDCoCBSWCBwYWNrZXRzOjcgZXJyb3JzOjAgZHJvcHBlZDowIG92
ZXJydW5zOjAgZnJhbWU6MAo+IMKgIMKgIMKgIMKgIMKgIFRYIHBhY2tldHM6NyBlcnJvcnM6MCBk
cm9wcGVkOjAgb3ZlcnJ1bnM6MCBjYXJyaWVyOjAKPiDCoCDCoCDCoCDCoCDCoCBjb2xsaXNpb25z
OjAgdHhxdWV1ZWxlbjowCj4gwqAgwqAgwqAgwqAgwqAgUlggYnl0ZXM6NTYzICg1NjMuMCBiKSDC
oFRYIGJ5dGVzOjU2MyAoNTYzLjAgYikKPgo+Cj4gQW5kLCAiaWZjb25maWcgLWEiIG91dHB1dCBm
cm9tIHRoZSBEb21VIHdoZW4gbGF1bmNoZWQgd2l0aCB4bC4KPgo+IHhsIGNyZWF0ZSB0ZXN0LmNm
Zwo+IHhsIGxpc3QKPiDCoE5hbWUgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBJRCDCoCBNZW0gVkNQVXMgwqAgwqAgwqBTdGF0ZQo+IMKg
VGltZShzKQo+IMKgRG9tYWluLTAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgMCDCoDEwMTAgwqAgwqAgMSDCoCDCoCByLS0tLS0KPiDCoCDCoDY2
LjgKPiDCoHRlbXBsYXRlIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIDEgwqAyMDQ4IMKgIMKgIDIgwqAgwqAgLWItLS0tCj4gwqAgwqAgNi44Cj4K
PiBpZmNvbmZpZyAtYQo+IMKgZXRoMCDCoCDCoCDCoExpbmsgZW5jYXA6RXRoZXJuZXQgwqBIV2Fk
ZHIgMDA6MTY6M0U6MTI6MzQ6MDEKPiDCoCDCoCDCoCDCoCDCoCBVUCBCUk9BRENBU1QgUlVOTklO
RyBNVUxUSUNBU1QgwqBNVFU6MTUwMCDCoE1ldHJpYzoxCj4gwqAgwqAgwqAgwqAgwqAgUlggcGFj
a2V0czowIGVycm9yczowIGRyb3BwZWQ6MCBvdmVycnVuczowIGZyYW1lOjAKPiDCoCDCoCDCoCDC
oCDCoCBUWCBwYWNrZXRzOjExNCBlcnJvcnM6MCBkcm9wcGVkOjAgb3ZlcnJ1bnM6MCBjYXJyaWVy
OjAKPiDCoCDCoCDCoCDCoCDCoCBjb2xsaXNpb25zOjAgdHhxdWV1ZWxlbjoxMDAwCj4gwqAgwqAg
wqAgwqAgwqAgUlggYnl0ZXM6MCAoMC4wIGIpIMKgVFggYnl0ZXM6NTI0MSAoNS4xIEtiKQo+Cj4g
wqBldGgwOjEgwqAgwqBMaW5rIGVuY2FwOkV0aGVybmV0IMKgSFdhZGRyIDAwOjE2OjNFOjEyOjM0
OjAxCj4gwqAgwqAgwqAgwqAgwqAgaW5ldCBhZGRyOjE5Mi4xNjguMS4zMiDCoCBCY2FzdDoxOTIu
MTY4LjEuMjU1Cj4gwqAgwqAgwqAgwqAgwqAgTWFzazoyNTUuMjU1LjI1NS4wCj4gwqAgwqAgwqAg
wqAgwqAgVVAgQlJPQURDQVNUIFJVTk5JTkcgTVVMVElDQVNUIMKgTVRVOjE1MDAgwqBNZXRyaWM6
MQo+Cj4gwqBsbyDCoCDCoCDCoCDCoExpbmsgZW5jYXA6TG9jYWwgTG9vcGJhY2sKPiDCoCDCoCDC
oCDCoCDCoCBpbmV0IGFkZHI6MTI3LjAuMC4xIMKgTWFzazoyNTUuMC4wLjAKPiDCoCDCoCDCoCDC
oCDCoCBVUCBMT09QQkFDSyBSVU5OSU5HIMKgTVRVOjE2NDM2IMKgTWV0cmljOjEKPiDCoCDCoCDC
oCDCoCDCoCBSWCBwYWNrZXRzOjUyIGVycm9yczowIGRyb3BwZWQ6MCBvdmVycnVuczowIGZyYW1l
OjAKPiDCoCDCoCDCoCDCoCDCoCBUWCBwYWNrZXRzOjUyIGVycm9yczowIGRyb3BwZWQ6MCBvdmVy
cnVuczowIGNhcnJpZXI6MAo+IMKgIMKgIMKgIMKgIMKgIGNvbGxpc2lvbnM6MCB0eHF1ZXVlbGVu
OjAKPiDCoCDCoCDCoCDCoCDCoCBSWCBieXRlczo0NDMxICg0LjMgS2IpIMKgVFggYnl0ZXM6NDQz
MSAoNC4zIEtiKQo+Cj4+IEFsc28gcGFzdGUgdGhlIG91dHB1dCBmcm9tICJ4ZW5zdG9yZS1scyAt
ZnAiIG9uIHRoZSBEb20wIHdoZW4gdGhlIHhsCj4+IERvbVUgaXMgdXAgYW5kIHJ1bm5pbmcuIEZy
b20gd2hhdCBJIHNhdyBhYm92ZSBpbiAvdmFyL2xvZy9tZXNzYWdlcyB0aGUKPj4gcHJvYmxlbSBz
ZWVtIHRvIGJlIHJlbGF0ZWQgdG8gaG90cGx1ZyBzY3JpcHRzLgo+Cj4gSGVyZSBpcyB0aGUgcGFz
dGUgb2YgdGhhdCBvdXRwdXQuID09PT4gaHR0cDovL3Bhc3RlYmluLmNvbS9zMGUwM1ZuVwoKCkFw
YXJ0IGZyb20gdGhlIGZhY3QgdGhhdCB5b3UgaGF2ZSBxdWl0ZSBhIGxvdCBvZiBqdW5rIGluIHhl
bnN0b3JlIEkKZG9uJ3Qgc2VlIGFueXRoaW5nIHN0cmFuZ2UsIGRldmljZXMgc2VlbSB0byBiZSBj
b25uZWN0ZWQgb2suIEkndmUKcmVhbGl6ZWQgdGhhdCB5b3UgaGF2ZSBpbnN0YWxsZWQKcGF0dGVy
bnMtb3BlblNVU0UteGVuX3NlcnZlci0xMi4xLTI1LjIxLjEueDg2XzY0LCB3aGF0J3MgdGhpcz8g
SSd2ZQpuZXZlciB1c2VkIFhlbiB3aXRoIE9wZW5TVVNFLCBidXQgdGhpcyBzZWVtcyByZWxhdGVk
IHRvIFhlblNlcnZlcgpjb21lcmNpYWwgdmVyc2lvbiwgbm90IG9wZW4gc291cmNlIFhlbi4gTWF5
YmUgc29tZW9uZSBmYW1pbGlhciB3aXRoClhlbiBvbiBPcGVuU1VTRSBjYW4gcHJvdmlkZSBtb3Jl
IGhlbHBmdWwgaW5mb3JtYXRpb24uCgpUaGUgb25seSBzdHJhbmdlIHRoaW5nIEkgc2VlIGFyZSB0
aGUgaG90cGx1ZyBlcnJvciBtZXNzYWdlcyBpbgovdmFyL2xvZy9tZXNzYWdlcywgYnV0IEkgZG9u
J3Qga25vdyB3aGF0IGNvdWxkIGNhdXNlIHRoZW0uIE1heWJlIG9sZAp1ZGV2IHJ1bGVzIG9yIGhv
dHBsdWcgc2NyaXB0cyB0aGF0IGRpZG4ndCBnZXQgY2xlYW5lZCB3aGVuIHVwZGF0aW5nPwoKPiBP
biBTdW4sIEphbiAyMiwgMjAxMiwgYXQgMTA6NDkgQU0sIGRqbWFnZWVAbWFnZWVuZXQubmV0IHdy
b3RlOgo+PiBZb3UncmUgbWlzc2luZyB0aGUgb3BlbmluZyBzaW5nbGUgcXVvdGUgb24geW91ciB2
aWYgbGluZS4KPgo+IFRoYXQncyBqdXN0IGEgY29weS9wYXN0ZSB0eXBvIGluIHRoZSBlbWFpbC4K
Pgo+IFJlZ2FyZHMsCj4KPiBFcmluCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sun Jan 22 17:54:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 17: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 1Rp1cW-0001B3-1f; Sun, 22 Jan 2012 17:54:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rp1cU-0001Ay-EG
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 17:54:22 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327254855!10130716!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzY4MDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16994 invoked from network); 22 Jan 2012 17:54:16 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jan 2012 17:54:16 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 72F6820D6A
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 12:54:14 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute5.internal (MEProxy); Sun, 22 Jan 2012 12:54:14 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	7zNjIXYo6P2XulP5OKIKE+k26fk=; b=ZoNv+f20DFBl/wUGLXylHfZhONI2NB4l
	EgVbPifLS38eDE+SpZMa5xSqumbDcmOX4TmG5hzwYVinz23JAcEu3Byd6bh7PsvH
	BiIJcrfe7dy7UO66JnlLP951MMkTp53KIEqn2NBNsGsXFONfZFuQazsE1HAu/5DN
	nKfEcZxmf5U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=7zNjIXYo6P2XulP5OKIKE+k26fk=; b=reN
	ZAFPRvUSs3bzerlCyqpVJDxRTZhzpNNdvCVoUkLCU9GWPOPNcYM7QNzY28K+YeBF
	UzhpPC8X/1EDjeB+ST5Q9NWd64z+w8A2CCdHQJYs+L+CzA9OnFpOLbDzqq8xHa+s
	hsE7c0RjPt05luwpv+4MdydnImOEsjQyAVpucNG8=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 46418A00082; Sun, 22 Jan 2012 12:54:14 -0500 (EST)
Message-Id: <1327254854.9185.140661026566721@webmail.messagingengine.com>
X-Sasl-Enc: ujPjlPiV8qxJJl7GUx9LB2GgBIVicroLRgSXNW+0mR7h 1327254854
From: erin.balid@inoutbox.com
To: =?ISO-8859-1?Q?Roger=20Pau=20Monn=E9?= <roger.pau@entel.upc.edu>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
Date: Sun, 22 Jan 2012 09:54:14 -0800
Cc: jfehlig@suse.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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 Roger.

On Sun, Jan 22, 2012, at 06:28 PM, Roger Pau Monn=E9 wrote:
> Apart from the fact that you have quite a lot of junk in xenstore I
> don't see anything strange, devices seem to be connected ok. I've
> realized that you have installed
> patterns-openSUSE-xen_server-12.1-25.21.1.x86_64, what's this? I've
> never used Xen with OpenSUSE, but this seems related to XenServer
> comercial version, not open source Xen. Maybe someone familiar with
> Xen on OpenSUSE can provide more helpful information.

That package is a meta-package for the xen_server package. 'patterns' on
OpenSuse are just functional collections of packages.

zypper info patterns-openSUSE-xen_server
	Information for package patterns-openSUSE-xen_server:

	Repository: OS12-oss
	Name: patterns-openSUSE-xen_server
	Version: 12.1-25.21.1
	Arch: x86_64
	Vendor: openSUSE
	Installed: Yes
	Status: up-to-date
	Installed Size: 1.0 KiB
	Summary: Meta package for pattern xen_server
	Description:
	This package is installed if a pattern is selected to have a
	working update path

zypper info -t pattern xen_server
	Information for pattern xen_server:

	Repository: OS12-oss
	Name: xen_server
	Version: 12.1-25.21.1
	Arch: x86_64
	Vendor: openSUSE
	Installed: Yes
	Summary: Xen Virtual Machine Host Server
	Description:
	Software to set up a server for configuring, managing, and
	monitoring virtual machines on a single physical machine.
	Contents:

	S | Name                         | Type    | Dependency
	--+------------------------------+---------+-----------
	i | kernel-xen                   | package |
	i | xen-tools                    | package |
	  | vm-install                   | package |
	i | yast2-vm                     | package |
	  | virt-manager                 | package |
	i | patterns-openSUSE-xen_server | package |
	i | bridge-utils                 | package |
	i | install-initrd               | package |
	  | virt-viewer                  | package |
	i | xterm                        | package |
	i | xen                          | package |
	i | xen-doc-html                 | package |
	i | xen-doc-pdf                  | package |
	i | xen-libs                     | package |

It has nothing to do with commercial Xen.

> The only strange thing I see are the hotplug error messages in
> /var/log/messages, but I don't know what could cause them. Maybe old
> udev rules or hotplug scripts that didn't get cleaned when updating?

I know this machine was originally installed with at least opensuse
11.4. I upgraded it from 11.4 =3D=3D> 12.1.  I don't know if it was
originally installed on 11.4, or sommthing even earlier and then
upgraded.

Short of reinstalling the machine from scratch, I don't know to clean
things up.  It sounds like it's more that just deleting the xenstore
database somehow.

I found this post from a year ago by an OpenSuse Xen developer -

http://lists.opensuse.org/opensuse-features/2011-03/msg00212.html

"Xen 4.1.0 (due February 2011) will be the first release in which thenew
xl/libxl (aka libxenlight [1]) toolstack will be the default,preferred
tool set. Although still included in the release, the legacyxm/xend
toolstack will be disabled and in process of deprecation."

That was for 4.1.0. The current version is 4.1.2.  The post reads then
like we already should be using xl in OpenSuse.  Looks like the author
posts on this list too.  I'll CC him directly on just this email. Maybe
he can participate here a bit and has some ideas.

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 17:54:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 17: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 1Rp1cW-0001B3-1f; Sun, 22 Jan 2012 17:54:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rp1cU-0001Ay-EG
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 17:54:22 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327254855!10130716!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzY4MDM=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16994 invoked from network); 22 Jan 2012 17:54:16 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 22 Jan 2012 17:54:16 -0000
Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 72F6820D6A
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 12:54:14 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute5.internal (MEProxy); Sun, 22 Jan 2012 12:54:14 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	7zNjIXYo6P2XulP5OKIKE+k26fk=; b=ZoNv+f20DFBl/wUGLXylHfZhONI2NB4l
	EgVbPifLS38eDE+SpZMa5xSqumbDcmOX4TmG5hzwYVinz23JAcEu3Byd6bh7PsvH
	BiIJcrfe7dy7UO66JnlLP951MMkTp53KIEqn2NBNsGsXFONfZFuQazsE1HAu/5DN
	nKfEcZxmf5U=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=7zNjIXYo6P2XulP5OKIKE+k26fk=; b=reN
	ZAFPRvUSs3bzerlCyqpVJDxRTZhzpNNdvCVoUkLCU9GWPOPNcYM7QNzY28K+YeBF
	UzhpPC8X/1EDjeB+ST5Q9NWd64z+w8A2CCdHQJYs+L+CzA9OnFpOLbDzqq8xHa+s
	hsE7c0RjPt05luwpv+4MdydnImOEsjQyAVpucNG8=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 46418A00082; Sun, 22 Jan 2012 12:54:14 -0500 (EST)
Message-Id: <1327254854.9185.140661026566721@webmail.messagingengine.com>
X-Sasl-Enc: ujPjlPiV8qxJJl7GUx9LB2GgBIVicroLRgSXNW+0mR7h 1327254854
From: erin.balid@inoutbox.com
To: =?ISO-8859-1?Q?Roger=20Pau=20Monn=E9?= <roger.pau@entel.upc.edu>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
Date: Sun, 22 Jan 2012 09:54:14 -0800
Cc: jfehlig@suse.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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 Roger.

On Sun, Jan 22, 2012, at 06:28 PM, Roger Pau Monn=E9 wrote:
> Apart from the fact that you have quite a lot of junk in xenstore I
> don't see anything strange, devices seem to be connected ok. I've
> realized that you have installed
> patterns-openSUSE-xen_server-12.1-25.21.1.x86_64, what's this? I've
> never used Xen with OpenSUSE, but this seems related to XenServer
> comercial version, not open source Xen. Maybe someone familiar with
> Xen on OpenSUSE can provide more helpful information.

That package is a meta-package for the xen_server package. 'patterns' on
OpenSuse are just functional collections of packages.

zypper info patterns-openSUSE-xen_server
	Information for package patterns-openSUSE-xen_server:

	Repository: OS12-oss
	Name: patterns-openSUSE-xen_server
	Version: 12.1-25.21.1
	Arch: x86_64
	Vendor: openSUSE
	Installed: Yes
	Status: up-to-date
	Installed Size: 1.0 KiB
	Summary: Meta package for pattern xen_server
	Description:
	This package is installed if a pattern is selected to have a
	working update path

zypper info -t pattern xen_server
	Information for pattern xen_server:

	Repository: OS12-oss
	Name: xen_server
	Version: 12.1-25.21.1
	Arch: x86_64
	Vendor: openSUSE
	Installed: Yes
	Summary: Xen Virtual Machine Host Server
	Description:
	Software to set up a server for configuring, managing, and
	monitoring virtual machines on a single physical machine.
	Contents:

	S | Name                         | Type    | Dependency
	--+------------------------------+---------+-----------
	i | kernel-xen                   | package |
	i | xen-tools                    | package |
	  | vm-install                   | package |
	i | yast2-vm                     | package |
	  | virt-manager                 | package |
	i | patterns-openSUSE-xen_server | package |
	i | bridge-utils                 | package |
	i | install-initrd               | package |
	  | virt-viewer                  | package |
	i | xterm                        | package |
	i | xen                          | package |
	i | xen-doc-html                 | package |
	i | xen-doc-pdf                  | package |
	i | xen-libs                     | package |

It has nothing to do with commercial Xen.

> The only strange thing I see are the hotplug error messages in
> /var/log/messages, but I don't know what could cause them. Maybe old
> udev rules or hotplug scripts that didn't get cleaned when updating?

I know this machine was originally installed with at least opensuse
11.4. I upgraded it from 11.4 =3D=3D> 12.1.  I don't know if it was
originally installed on 11.4, or sommthing even earlier and then
upgraded.

Short of reinstalling the machine from scratch, I don't know to clean
things up.  It sounds like it's more that just deleting the xenstore
database somehow.

I found this post from a year ago by an OpenSuse Xen developer -

http://lists.opensuse.org/opensuse-features/2011-03/msg00212.html

"Xen 4.1.0 (due February 2011) will be the first release in which thenew
xl/libxl (aka libxenlight [1]) toolstack will be the default,preferred
tool set. Although still included in the release, the legacyxm/xend
toolstack will be disabled and in process of deprecation."

That was for 4.1.0. The current version is 4.1.2.  The post reads then
like we already should be using xl in OpenSuse.  Looks like the author
posts on this list too.  I'll CC him directly on just this email. Maybe
he can participate here a bit and has some ideas.

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 20:24:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 20:24:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp3x6-0002So-Ss; Sun, 22 Jan 2012 20:23: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 1Rp3x6-0002Sd-09
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 20:23:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327263819!10139423!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 13693 invoked from network); 22 Jan 2012 20:23:41 -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; 22 Jan 2012 20:23: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
	q0MKNbhf030329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 22 Jan 2012 15:23:37 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0MKNbHk030327;
	Sun, 22 Jan 2012 15:23:37 -0500
Date: Sun, 22 Jan 2012 16:23:37 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Eric Camachat <eric.camachat@gmail.com>
Message-ID: <20120122202337.GA30288@andromeda.dapyr.net>
References: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Got kernel BUG message while PCI pass-through to
	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 Sat, Jan 21, 2012 at 10:32:37PM -0800, Eric Camachat wrote:
> Hi all,
> 
> I got kernel BUG message when PCI pass through to domU (xen-pv).
> Is there any one seen this?

Yes. The fix is in the upstream kernel. Please use 3.1.

> 
> Eric
> 
> dom0 kernel config:
> $ grep XEN_PCI linux-2.6.32.24/.config
> CONFIG_XEN_PCI_PASSTHROUGH=y
> CONFIG_XEN_PCIDEV_FRONTEND=y
> CONFIG_XEN_PCIDEV_BACKEND=y
> # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
> CONFIG_XEN_PCIDEV_BACKEND_PASS=y
> # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
> # CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
> # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
> 
> 
> When start domU, got this error message in dom0:
> BUG: sleeping function called from invalid context at mm/slab.c:3016
> in_atomic(): 1, irqs_disabled(): 0, pid: 21, name: xenwatch
> Pid: 21, comm: xenwatch Tainted: P           2.6.32.24-ws-symbol #1
> Call Trace:
>  [<ffffffff810365e4>] __might_sleep+0xf4/0x110
>  [<ffffffff810ac478>] __kmalloc+0x118/0x140
>  [<ffffffff811c1837>] kvasprintf+0x57/0x90
>  [<ffffffff813fcd8a>] ? error_exit+0x2a/0x60
>  [<ffffffff811c18d0>] kasprintf+0x60/0x70
>  [<ffffffff810101c2>] ? check_events+0x12/0x20
>  [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff810ab6a7>] ? kfree+0x87/0xd0
>  [<ffffffff8123328a>] ? read_reply+0x13a/0x150
>  [<ffffffff812337ae>] join+0x4e/0x60
>  [<ffffffff8123396c>] xenbus_read+0x2c/0x70
>  [<ffffffff8123402f>] xenbus_scanf+0x2f/0xa0
>  [<ffffffff8100f82d>] ? xen_force_evtchn_callback+0xd/0x10
>  [<ffffffff810101c2>] ? check_events+0x12/0x20
>  [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff810ab6a7>] ? kfree+0x87/0xd0
>  [<ffffffff8123391c>] ? xenbus_printf+0xbc/0xe0
>  [<ffffffff8100f82d>] ? xen_force_evtchn_callback+0xd/0x10
>  [<ffffffff8123a600>] pciback_publish_pci_root+0x40/0x1a0
>  [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
> nx4524-7AC4F0# [<ffffffff810ac53e>] ? kmem_cache_alloc+0x9e/0xf0
>  [<ffffffff81010e26>] ? xen_register_device_domain_owner+0x86/0xc0
>  [<ffffffff8123cc78>] pciback_publish_pci_roots+0x88/0xc0
>  [<ffffffff8123a5c0>] ? pciback_publish_pci_root+0x0/0x1a0
>  [<ffffffff8123aadd>] pciback_be_watch+0x1dd/0x290
>  [<ffffffff81232d64>] ? xs_error+0x14/0x20
>  [<ffffffff81233571>] ? xs_watch+0x51/0x60
>  [<ffffffff81233b0d>] ? register_xenbus_watch+0xdd/0xf0
>  [<ffffffff8123a900>] ? pciback_be_watch+0x0/0x290
>  [<ffffffff8123b0a9>] pciback_xenbus_probe+0x139/0x140
>  [<ffffffff81234f3a>] xenbus_dev_probe+0xaa/0x130
>  [<ffffffff8127950b>] driver_probe_device+0x7b/0x160
>  [<ffffffff812797e0>] ? __device_attach+0x0/0x50
>  [<ffffffff8127981d>] __device_attach+0x3d/0x50
>  [<ffffffff812785e8>] bus_for_each_drv+0x68/0x90
>  [<ffffffff8127973b>] device_attach+0x7b/0x80
>  [<ffffffff81278565>] bus_probe_device+0x25/0x40
>  [<ffffffff81276ac3>] device_add+0x293/0x570
>  [<ffffffff811b8da6>] ? kobject_init+0x36/0x80
>  [<ffffffff81276db9>] device_register+0x19/0x20
>  [<ffffffff81234780>] xenbus_probe_node+0x130/0x1b0
>  [<ffffffff81234996>] xenbus_dev_changed+0x196/0x1a0
>  [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff8103652b>] ? __might_sleep+0x3b/0x110
>  [<ffffffff812350b6>] backend_changed+0x16/0x20
>  [<ffffffff81233e4b>] xenwatch_thread+0x10b/0x150
>  [<ffffffff81057d90>] ? autoremove_wake_function+0x0/0x40
>  [<ffffffff81233d40>] ? xenwatch_thread+0x0/0x150
>  [<ffffffff81057c1e>] kthread+0x8e/0xa0
>  [<ffffffff81014dfa>] child_rip+0xa/0x20
>  [<ffffffff81013fa6>] ? int_ret_from_sys_call+0x7/0x1b
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 22 20:24:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 20:24:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp3x6-0002So-Ss; Sun, 22 Jan 2012 20:23: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 1Rp3x6-0002Sd-09
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 20:23:48 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327263819!10139423!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 13693 invoked from network); 22 Jan 2012 20:23:41 -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; 22 Jan 2012 20:23: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
	q0MKNbhf030329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 22 Jan 2012 15:23:37 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0MKNbHk030327;
	Sun, 22 Jan 2012 15:23:37 -0500
Date: Sun, 22 Jan 2012 16:23:37 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Eric Camachat <eric.camachat@gmail.com>
Message-ID: <20120122202337.GA30288@andromeda.dapyr.net>
References: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Got kernel BUG message while PCI pass-through to
	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 Sat, Jan 21, 2012 at 10:32:37PM -0800, Eric Camachat wrote:
> Hi all,
> 
> I got kernel BUG message when PCI pass through to domU (xen-pv).
> Is there any one seen this?

Yes. The fix is in the upstream kernel. Please use 3.1.

> 
> Eric
> 
> dom0 kernel config:
> $ grep XEN_PCI linux-2.6.32.24/.config
> CONFIG_XEN_PCI_PASSTHROUGH=y
> CONFIG_XEN_PCIDEV_FRONTEND=y
> CONFIG_XEN_PCIDEV_BACKEND=y
> # CONFIG_XEN_PCIDEV_BACKEND_VPCI is not set
> CONFIG_XEN_PCIDEV_BACKEND_PASS=y
> # CONFIG_XEN_PCIDEV_BACKEND_SLOT is not set
> # CONFIG_XEN_PCIDEV_BACKEND_CONTROLLER is not set
> # CONFIG_XEN_PCIDEV_BE_DEBUG is not set
> 
> 
> When start domU, got this error message in dom0:
> BUG: sleeping function called from invalid context at mm/slab.c:3016
> in_atomic(): 1, irqs_disabled(): 0, pid: 21, name: xenwatch
> Pid: 21, comm: xenwatch Tainted: P           2.6.32.24-ws-symbol #1
> Call Trace:
>  [<ffffffff810365e4>] __might_sleep+0xf4/0x110
>  [<ffffffff810ac478>] __kmalloc+0x118/0x140
>  [<ffffffff811c1837>] kvasprintf+0x57/0x90
>  [<ffffffff813fcd8a>] ? error_exit+0x2a/0x60
>  [<ffffffff811c18d0>] kasprintf+0x60/0x70
>  [<ffffffff810101c2>] ? check_events+0x12/0x20
>  [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff810ab6a7>] ? kfree+0x87/0xd0
>  [<ffffffff8123328a>] ? read_reply+0x13a/0x150
>  [<ffffffff812337ae>] join+0x4e/0x60
>  [<ffffffff8123396c>] xenbus_read+0x2c/0x70
>  [<ffffffff8123402f>] xenbus_scanf+0x2f/0xa0
>  [<ffffffff8100f82d>] ? xen_force_evtchn_callback+0xd/0x10
>  [<ffffffff810101c2>] ? check_events+0x12/0x20
>  [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff810ab6a7>] ? kfree+0x87/0xd0
>  [<ffffffff8123391c>] ? xenbus_printf+0xbc/0xe0
>  [<ffffffff8100f82d>] ? xen_force_evtchn_callback+0xd/0x10
>  [<ffffffff8123a600>] pciback_publish_pci_root+0x40/0x1a0
>  [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
> nx4524-7AC4F0# [<ffffffff810ac53e>] ? kmem_cache_alloc+0x9e/0xf0
>  [<ffffffff81010e26>] ? xen_register_device_domain_owner+0x86/0xc0
>  [<ffffffff8123cc78>] pciback_publish_pci_roots+0x88/0xc0
>  [<ffffffff8123a5c0>] ? pciback_publish_pci_root+0x0/0x1a0
>  [<ffffffff8123aadd>] pciback_be_watch+0x1dd/0x290
>  [<ffffffff81232d64>] ? xs_error+0x14/0x20
>  [<ffffffff81233571>] ? xs_watch+0x51/0x60
>  [<ffffffff81233b0d>] ? register_xenbus_watch+0xdd/0xf0
>  [<ffffffff8123a900>] ? pciback_be_watch+0x0/0x290
>  [<ffffffff8123b0a9>] pciback_xenbus_probe+0x139/0x140
>  [<ffffffff81234f3a>] xenbus_dev_probe+0xaa/0x130
>  [<ffffffff8127950b>] driver_probe_device+0x7b/0x160
>  [<ffffffff812797e0>] ? __device_attach+0x0/0x50
>  [<ffffffff8127981d>] __device_attach+0x3d/0x50
>  [<ffffffff812785e8>] bus_for_each_drv+0x68/0x90
>  [<ffffffff8127973b>] device_attach+0x7b/0x80
>  [<ffffffff81278565>] bus_probe_device+0x25/0x40
>  [<ffffffff81276ac3>] device_add+0x293/0x570
>  [<ffffffff811b8da6>] ? kobject_init+0x36/0x80
>  [<ffffffff81276db9>] device_register+0x19/0x20
>  [<ffffffff81234780>] xenbus_probe_node+0x130/0x1b0
>  [<ffffffff81234996>] xenbus_dev_changed+0x196/0x1a0
>  [<ffffffff810101af>] ? xen_restore_fl_direct_end+0x0/0x1
>  [<ffffffff8103652b>] ? __might_sleep+0x3b/0x110
>  [<ffffffff812350b6>] backend_changed+0x16/0x20
>  [<ffffffff81233e4b>] xenwatch_thread+0x10b/0x150
>  [<ffffffff81057d90>] ? autoremove_wake_function+0x0/0x40
>  [<ffffffff81233d40>] ? xenwatch_thread+0x0/0x150
>  [<ffffffff81057c1e>] kthread+0x8e/0xa0
>  [<ffffffff81014dfa>] child_rip+0xa/0x20
>  [<ffffffff81013fa6>] ? int_ret_from_sys_call+0x7/0x1b
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 22 20:38:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 20:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp4AM-0002l3-Ee; Sun, 22 Jan 2012 20:37:30 +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 1Rp4AK-0002ky-Ly
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 20:37:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327264639!12113998!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 24393 invoked from network); 22 Jan 2012 20:37:21 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Jan 2012 20:37: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
	q0MKbEWO030629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 22 Jan 2012 15:37:15 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0MKbEum030627;
	Sun, 22 Jan 2012 15:37:14 -0500
Date: Sun, 22 Jan 2012 16:37:14 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Keir Fraser <keir@xen.org>
Message-ID: <20120122203714.GB30288@andromeda.dapyr.net>
References: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
	<CB3E3263.37CC2%keir@xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy"
Content-Disposition: inline
In-Reply-To: <CB3E3263.37CC2%keir@xen.org>
User-Agent: Mutt/1.5.9i
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	andres@lagarcavilla.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> > luck? Am I missing something?
> 
> Where older structs were not 32/64-bit invariant, compat shims were
> implemented. See common/compat/memory.c, for example. Well worth avoiding
> that!

So for the "Fun" of it I tried to see if the 'struct
xen_processor_performance' has some 32/64-bit issues and was surprised
to find they do. What I am more surprised to find is that nobody seems
to have had any troubles with this as it seems to have been there since
it was initially implemented. The major issue would have been with the
'shared_type', 'domain_info' and the pointer to the 'states' being at
different offsets (So when running a 32-bit dom0 with a 64-bit
hypervisor).

The attached little C program has the identified issues and the
// FIX is my attempt at making the structs of the same size on 32 and 64
bit builds. Right now when built as 32-bit the struct is 96 bytes, while on
64-bit it is 104.

Was wondering what is the right fix? The thoughts I had was to either
leave them as be and the domain would have to figure out whether the hypervisor
is 32-bit or 64-bit and provide the _right_ structure.

Or perhaps fix it and provide a "version" hypercall, but that would not
be backwards compatible.

--KsGdsel6WgEHnImy
Content-Type: text/x-csrc; charset=us-ascii
Content-Disposition: attachment; filename="psd.c"


#include <stdio.h>
#include <stdint.h>
#include <stddef.h>

/* Turn this on/off to see how it would look like on 32 or 64 bit */
#define CONFIG_X86_64

#ifdef CONFIG_X86_64
#else
#pragma pack(4)
#endif

#define __DEFINE_GUEST_HANDLE(name, type) \
    typedef struct { type *p; } __guest_handle_ ## name

#define DEFINE_GUEST_HANDLE_STRUCT(name) \
	__DEFINE_GUEST_HANDLE(name, struct name)
#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
#define GUEST_HANDLE(name)        __guest_handle_ ## name

struct xen_power_register {
	uint32_t     space_id;
	uint32_t     bit_width;
	uint32_t     bit_offset;
	uint32_t     access_size;
	uint64_t     address;
};

struct xen_processor_csd {
	uint32_t    domain;      /* domain number of one dependent group */
	uint32_t    coord_type;  /* coordination type */
	uint32_t    num;         /* number of processors in same domain */
};
DEFINE_GUEST_HANDLE_STRUCT(xen_processor_csd);

struct xen_processor_cx {
	struct xen_power_register  reg; /* GAS for Cx trigger register */
	uint8_t     type;     /* cstate value, c0: 0, c1: 1, ... */
	// FIX: Mega pad. No 64/32 bit problems.
	uint8_t		_pad1[3];
	uint32_t    latency;  /* worst latency (ms) to enter/exit this cstate */
	uint32_t    power;    /* average power consumption(mW) */
	uint32_t    dpcnt;    /* number of dependency entries */
	GUEST_HANDLE(xen_processor_csd) dp; /* NULL if no dependency */
};
DEFINE_GUEST_HANDLE_STRUCT(xen_processor_cx);

struct xen_processor_flags {
	uint32_t bm_control:1;
	uint32_t bm_check:1;
	uint32_t has_cst:1;
	uint32_t power_setup_done:1;
	uint32_t bm_rld_set:1;
};

struct xen_processor_power {
	uint32_t count;  /* number of C state entries in array below */
	struct xen_processor_flags flags;  /* global flags of this processor */
	GUEST_HANDLE(xen_processor_cx) states; /* supported c states */
};

struct xen_pct_register {
	uint8_t  descriptor;
	// FIX: Do not memcpy the (acpi_pct_register) as its packing is different */
	uint8_t	_pad1; /* ARGH */
	uint16_t length;
	uint8_t  space_id;
	uint8_t  bit_width;
	uint8_t  bit_offset;
	uint8_t  reserved;
	uint64_t address;
} __attribute__((__packed__));

struct xen_processor_px {
	uint64_t core_frequency; /* megahertz */
	uint64_t power;      /* milliWatts */
	uint64_t transition_latency; /* microseconds */
	uint64_t bus_master_latency; /* microseconds */
	uint64_t control;        /* control value */
	uint64_t status;     /* success indicator */
};
DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px);

struct xen_psd_package {
	uint64_t num_entries;
	uint64_t revision;
	uint64_t domain;
	uint64_t coord_type;
	uint64_t num_processors;
}

struct xen_processor_performance {
	uint32_t flags;     /* flag for Px sub info type */
	uint32_t platform_limit;  /* Platform limitation on freq usage */
	struct xen_pct_register control_register;
	struct xen_pct_register status_register;
	uint32_t state_count;     /* total available performance states */
#ifndef CONFIG_X86_64
	// FIX
	uint32_t pad1;
#endif
	GUEST_HANDLE(xen_processor_px) states;
	struct xen_psd_package domain_info;
	uint32_t shared_type;     /* coordination type of this processor */
#ifndef CONFIG_X86_64
	// FIX
	uint32_t pad2;
#endif
};
int main(void) {
	printf("%d==104|96  %d==16  %d==40 %d==16 %d==48\n",
		sizeof(struct xen_processor_performance), /* 104 when 64, 96 when 32 */
		sizeof(struct xen_pct_register),
		sizeof(struct xen_psd_package),
		sizeof(struct xen_processor_power),
		sizeof(struct xen_processor_cx));

	printf("%d==0, %d==4, %d==10,%d==26 %d==40\n",
		offsetof(struct xen_processor_performance, flags),
		offsetof(struct xen_processor_performance, platform_limit),
		offsetof(struct xen_processor_performance, control_register.length),
		offsetof(struct xen_processor_performance, status_register.length),
		offsetof(struct xen_processor_performance, state_count));

	printf("%d==48|44, %d==56|52 %d==96|92\n",
		offsetof(struct xen_processor_performance, states),
		offsetof(struct xen_processor_performance, domain_info),
		offsetof(struct xen_processor_performance, shared_type));
	printf("%d==4, %d==8\n",
		offsetof(struct xen_processor_power, flags),
		offsetof(struct xen_processor_power, states));

	printf("%d==0 %d==0 %d==4 %d==16 %d==24 %d==28 %d==32 %d==36\n",
		offsetof(struct xen_processor_cx, reg),
		offsetof(struct xen_processor_cx, reg.space_id),
		offsetof(struct xen_processor_cx, reg.bit_width),
		offsetof(struct xen_processor_cx, reg.address),
		offsetof(struct xen_processor_cx, type), // 16
		offsetof(struct xen_processor_cx, latency), // 24
		offsetof(struct xen_processor_cx, power), // 28
		offsetof(struct xen_processor_cx, dpcnt), //32
		offsetof(struct xen_processor_cx, dp)); //36
	return 0;
}

--KsGdsel6WgEHnImy
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--KsGdsel6WgEHnImy--


From xen-devel-bounces@lists.xensource.com Sun Jan 22 20:38:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 20:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp4AM-0002l3-Ee; Sun, 22 Jan 2012 20:37:30 +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 1Rp4AK-0002ky-Ly
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 20:37:28 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327264639!12113998!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 24393 invoked from network); 22 Jan 2012 20:37:21 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-5.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 22 Jan 2012 20:37: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
	q0MKbEWO030629
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 22 Jan 2012 15:37:15 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0MKbEum030627;
	Sun, 22 Jan 2012 15:37:14 -0500
Date: Sun, 22 Jan 2012 16:37:14 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Keir Fraser <keir@xen.org>
Message-ID: <20120122203714.GB30288@andromeda.dapyr.net>
References: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
	<CB3E3263.37CC2%keir@xen.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="KsGdsel6WgEHnImy"
Content-Disposition: inline
In-Reply-To: <CB3E3263.37CC2%keir@xen.org>
User-Agent: Mutt/1.5.9i
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	andres@lagarcavilla.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

> > luck? Am I missing something?
> 
> Where older structs were not 32/64-bit invariant, compat shims were
> implemented. See common/compat/memory.c, for example. Well worth avoiding
> that!

So for the "Fun" of it I tried to see if the 'struct
xen_processor_performance' has some 32/64-bit issues and was surprised
to find they do. What I am more surprised to find is that nobody seems
to have had any troubles with this as it seems to have been there since
it was initially implemented. The major issue would have been with the
'shared_type', 'domain_info' and the pointer to the 'states' being at
different offsets (So when running a 32-bit dom0 with a 64-bit
hypervisor).

The attached little C program has the identified issues and the
// FIX is my attempt at making the structs of the same size on 32 and 64
bit builds. Right now when built as 32-bit the struct is 96 bytes, while on
64-bit it is 104.

Was wondering what is the right fix? The thoughts I had was to either
leave them as be and the domain would have to figure out whether the hypervisor
is 32-bit or 64-bit and provide the _right_ structure.

Or perhaps fix it and provide a "version" hypercall, but that would not
be backwards compatible.

--KsGdsel6WgEHnImy
Content-Type: text/x-csrc; charset=us-ascii
Content-Disposition: attachment; filename="psd.c"


#include <stdio.h>
#include <stdint.h>
#include <stddef.h>

/* Turn this on/off to see how it would look like on 32 or 64 bit */
#define CONFIG_X86_64

#ifdef CONFIG_X86_64
#else
#pragma pack(4)
#endif

#define __DEFINE_GUEST_HANDLE(name, type) \
    typedef struct { type *p; } __guest_handle_ ## name

#define DEFINE_GUEST_HANDLE_STRUCT(name) \
	__DEFINE_GUEST_HANDLE(name, struct name)
#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
#define GUEST_HANDLE(name)        __guest_handle_ ## name

struct xen_power_register {
	uint32_t     space_id;
	uint32_t     bit_width;
	uint32_t     bit_offset;
	uint32_t     access_size;
	uint64_t     address;
};

struct xen_processor_csd {
	uint32_t    domain;      /* domain number of one dependent group */
	uint32_t    coord_type;  /* coordination type */
	uint32_t    num;         /* number of processors in same domain */
};
DEFINE_GUEST_HANDLE_STRUCT(xen_processor_csd);

struct xen_processor_cx {
	struct xen_power_register  reg; /* GAS for Cx trigger register */
	uint8_t     type;     /* cstate value, c0: 0, c1: 1, ... */
	// FIX: Mega pad. No 64/32 bit problems.
	uint8_t		_pad1[3];
	uint32_t    latency;  /* worst latency (ms) to enter/exit this cstate */
	uint32_t    power;    /* average power consumption(mW) */
	uint32_t    dpcnt;    /* number of dependency entries */
	GUEST_HANDLE(xen_processor_csd) dp; /* NULL if no dependency */
};
DEFINE_GUEST_HANDLE_STRUCT(xen_processor_cx);

struct xen_processor_flags {
	uint32_t bm_control:1;
	uint32_t bm_check:1;
	uint32_t has_cst:1;
	uint32_t power_setup_done:1;
	uint32_t bm_rld_set:1;
};

struct xen_processor_power {
	uint32_t count;  /* number of C state entries in array below */
	struct xen_processor_flags flags;  /* global flags of this processor */
	GUEST_HANDLE(xen_processor_cx) states; /* supported c states */
};

struct xen_pct_register {
	uint8_t  descriptor;
	// FIX: Do not memcpy the (acpi_pct_register) as its packing is different */
	uint8_t	_pad1; /* ARGH */
	uint16_t length;
	uint8_t  space_id;
	uint8_t  bit_width;
	uint8_t  bit_offset;
	uint8_t  reserved;
	uint64_t address;
} __attribute__((__packed__));

struct xen_processor_px {
	uint64_t core_frequency; /* megahertz */
	uint64_t power;      /* milliWatts */
	uint64_t transition_latency; /* microseconds */
	uint64_t bus_master_latency; /* microseconds */
	uint64_t control;        /* control value */
	uint64_t status;     /* success indicator */
};
DEFINE_GUEST_HANDLE_STRUCT(xen_processor_px);

struct xen_psd_package {
	uint64_t num_entries;
	uint64_t revision;
	uint64_t domain;
	uint64_t coord_type;
	uint64_t num_processors;
}

struct xen_processor_performance {
	uint32_t flags;     /* flag for Px sub info type */
	uint32_t platform_limit;  /* Platform limitation on freq usage */
	struct xen_pct_register control_register;
	struct xen_pct_register status_register;
	uint32_t state_count;     /* total available performance states */
#ifndef CONFIG_X86_64
	// FIX
	uint32_t pad1;
#endif
	GUEST_HANDLE(xen_processor_px) states;
	struct xen_psd_package domain_info;
	uint32_t shared_type;     /* coordination type of this processor */
#ifndef CONFIG_X86_64
	// FIX
	uint32_t pad2;
#endif
};
int main(void) {
	printf("%d==104|96  %d==16  %d==40 %d==16 %d==48\n",
		sizeof(struct xen_processor_performance), /* 104 when 64, 96 when 32 */
		sizeof(struct xen_pct_register),
		sizeof(struct xen_psd_package),
		sizeof(struct xen_processor_power),
		sizeof(struct xen_processor_cx));

	printf("%d==0, %d==4, %d==10,%d==26 %d==40\n",
		offsetof(struct xen_processor_performance, flags),
		offsetof(struct xen_processor_performance, platform_limit),
		offsetof(struct xen_processor_performance, control_register.length),
		offsetof(struct xen_processor_performance, status_register.length),
		offsetof(struct xen_processor_performance, state_count));

	printf("%d==48|44, %d==56|52 %d==96|92\n",
		offsetof(struct xen_processor_performance, states),
		offsetof(struct xen_processor_performance, domain_info),
		offsetof(struct xen_processor_performance, shared_type));
	printf("%d==4, %d==8\n",
		offsetof(struct xen_processor_power, flags),
		offsetof(struct xen_processor_power, states));

	printf("%d==0 %d==0 %d==4 %d==16 %d==24 %d==28 %d==32 %d==36\n",
		offsetof(struct xen_processor_cx, reg),
		offsetof(struct xen_processor_cx, reg.space_id),
		offsetof(struct xen_processor_cx, reg.bit_width),
		offsetof(struct xen_processor_cx, reg.address),
		offsetof(struct xen_processor_cx, type), // 16
		offsetof(struct xen_processor_cx, latency), // 24
		offsetof(struct xen_processor_cx, power), // 28
		offsetof(struct xen_processor_cx, dpcnt), //32
		offsetof(struct xen_processor_cx, dp)); //36
	return 0;
}

--KsGdsel6WgEHnImy
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--KsGdsel6WgEHnImy--


From xen-devel-bounces@lists.xensource.com Sun Jan 22 20:43:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 20:43:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp4GB-00035U-VM; Sun, 22 Jan 2012 20:43: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 1Rp4GA-00035D-N2
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 20:43:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327265004!10140601!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16163 invoked from network); 22 Jan 2012 20:43:24 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 20:43:24 -0000
Received: by werb14 with SMTP id b14so7591820wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 12:43: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=SjOyK49rYUDZwfFY9YQEJTdQoj3a08Ep/ug6eIASMuU=;
	b=ZF3o2eQRmg5kXMlAH5xsSCG3mr1ITLe/Vv7d4AZl7JW1dEdC7TZkKH41e9PQTBcPoK
	Wd92l/dq64S53gbByraFr6q0P85xnNsO3bMjI+bgeXl7kdtVHh7HUDRK+QDtni6tKUoJ
	2xNs4J6UrZrxF8e7fRWpcn1NlYoqa0TC2zOOc=
Received: by 10.216.136.132 with SMTP id w4mr2249170wei.53.1327265003771;
	Sun, 22 Jan 2012 12:43:23 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id df2sm9423038wib.4.2012.01.22.12.43.21
	(version=SSLv3 cipher=OTHER); Sun, 22 Jan 2012 12:43:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 22 Jan 2012 20:43:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <CB422563.295C9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczZRna9Z/THGMvsgk+VS/vLaCPaiw==
In-Reply-To: <20120122203714.GB30288@andromeda.dapyr.net>
Mime-version: 1.0
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 20:37, "Konrad Rzeszutek Wilk" <konrad@darnok.org> wrote:

>>> luck? Am I missing something?
>> 
>> Where older structs were not 32/64-bit invariant, compat shims were
>> implemented. See common/compat/memory.c, for example. Well worth avoiding
>> that!
> 
> So for the "Fun" of it I tried to see if the 'struct
> xen_processor_performance' has some 32/64-bit issues and was surprised
> to find they do. What I am more surprised to find is that nobody seems
> to have had any troubles with this as it seems to have been there since
> it was initially implemented. The major issue would have been with the
> 'shared_type', 'domain_info' and the pointer to the 'states' being at
> different offsets (So when running a 32-bit dom0 with a 64-bit
> hypervisor).

It works because x86/64 Xen has a compat shim for that platform hypercall
command, which it uses when the caller is a 32-bit guest.

See xen/include/xlat.lst, xen/include/compat/platform.h (auto-generated),
xen/arch/x86/x86_64/platform_hypercall.c. For more details, ask Jan -- he
implemented most of it. ;-)

 -- Keir

> The attached little C program has the identified issues and the
> // FIX is my attempt at making the structs of the same size on 32 and 64
> bit builds. Right now when built as 32-bit the struct is 96 bytes, while on
> 64-bit it is 104.
> 
> Was wondering what is the right fix? The thoughts I had was to either
> leave them as be and the domain would have to figure out whether the
> hypervisor
> is 32-bit or 64-bit and provide the _right_ structure.
> 
> Or perhaps fix it and provide a "version" hypercall, but that would not
> be backwards compatible.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 22 20:43:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 22 Jan 2012 20:43:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rp4GB-00035U-VM; Sun, 22 Jan 2012 20:43: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 1Rp4GA-00035D-N2
	for xen-devel@lists.xensource.com; Sun, 22 Jan 2012 20:43:30 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327265004!10140601!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16163 invoked from network); 22 Jan 2012 20:43:24 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	22 Jan 2012 20:43:24 -0000
Received: by werb14 with SMTP id b14so7591820wer.30
	for <xen-devel@lists.xensource.com>;
	Sun, 22 Jan 2012 12:43: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=SjOyK49rYUDZwfFY9YQEJTdQoj3a08Ep/ug6eIASMuU=;
	b=ZF3o2eQRmg5kXMlAH5xsSCG3mr1ITLe/Vv7d4AZl7JW1dEdC7TZkKH41e9PQTBcPoK
	Wd92l/dq64S53gbByraFr6q0P85xnNsO3bMjI+bgeXl7kdtVHh7HUDRK+QDtni6tKUoJ
	2xNs4J6UrZrxF8e7fRWpcn1NlYoqa0TC2zOOc=
Received: by 10.216.136.132 with SMTP id w4mr2249170wei.53.1327265003771;
	Sun, 22 Jan 2012 12:43:23 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id df2sm9423038wib.4.2012.01.22.12.43.21
	(version=SSLv3 cipher=OTHER); Sun, 22 Jan 2012 12:43:22 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sun, 22 Jan 2012 20:43:15 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <CB422563.295C9%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] memop struct packing, 32/64 bits
Thread-Index: AczZRna9Z/THGMvsgk+VS/vLaCPaiw==
In-Reply-To: <20120122203714.GB30288@andromeda.dapyr.net>
Mime-version: 1.0
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>, ian.campbell@citrix.com
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 20:37, "Konrad Rzeszutek Wilk" <konrad@darnok.org> wrote:

>>> luck? Am I missing something?
>> 
>> Where older structs were not 32/64-bit invariant, compat shims were
>> implemented. See common/compat/memory.c, for example. Well worth avoiding
>> that!
> 
> So for the "Fun" of it I tried to see if the 'struct
> xen_processor_performance' has some 32/64-bit issues and was surprised
> to find they do. What I am more surprised to find is that nobody seems
> to have had any troubles with this as it seems to have been there since
> it was initially implemented. The major issue would have been with the
> 'shared_type', 'domain_info' and the pointer to the 'states' being at
> different offsets (So when running a 32-bit dom0 with a 64-bit
> hypervisor).

It works because x86/64 Xen has a compat shim for that platform hypercall
command, which it uses when the caller is a 32-bit guest.

See xen/include/xlat.lst, xen/include/compat/platform.h (auto-generated),
xen/arch/x86/x86_64/platform_hypercall.c. For more details, ask Jan -- he
implemented most of it. ;-)

 -- Keir

> The attached little C program has the identified issues and the
> // FIX is my attempt at making the structs of the same size on 32 and 64
> bit builds. Right now when built as 32-bit the struct is 96 bytes, while on
> 64-bit it is 104.
> 
> Was wondering what is the right fix? The thoughts I had was to either
> leave them as be and the domain would have to figure out whether the
> hypervisor
> is 32-bit or 64-bit and provide the _right_ structure.
> 
> Or perhaps fix it and provide a "version" hypercall, but that would not
> be backwards compatible.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 07:11:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 07:11:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpE2z-0002nu-Hh; Mon, 23 Jan 2012 07:10:33 +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 1RpE2x-0002np-35
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 07:10:31 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327302611!11969704!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDEzMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16268 invoked from network); 23 Jan 2012 07:10:23 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 07:10:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,554,1320624000"; d="scan'208,217";a="10048842"
Received: from banpmailmx01.citrite.net ([10.103.128.73])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 07:10:09 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by
	BANPMAILMX01.citrite.net ([10.103.128.73]) with mapi; Mon, 23 Jan 2012
	12:40:08 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 12:40:07 +0530
Thread-Topic: Re: Grant-table error messages in a crash log
Thread-Index: AczZnaW0Rp3k/h7xQmCWirW9KR1XUQ==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0@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] Grant-table error messages in a crash 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: multipart/mixed; boundary="===============2304280985412632429=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2304280985412632429==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

  Hi Team,

For a XenServer (5.6 sp2) crash I have got following  in the crash logs.  C=
an somebody tell me why I can see(grant_table.c:1408:d0 dest domain 40 dyin=
g)  this and how I can resolve it, if it is an issue.

(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to=
 DOM0)
  (XEN) Freed 128kB init memory.
  (XEN) __csched_vcpu_acct_start: setting dom 0 as the privileged domain
  (XEN) ioapic_guest_write: apic=3D0, pin=3D19, old_irq=3D-1, new_irq=3D-1
  (XEN) ioapic_guest_write: old_entry=3D00010a44, new_entry=3D0001a031
  (XEN) ioapic_guest_write: Special delivery mode 2 with non-zero vector 44
  (XEN) 'h' pressed -> showing installed handlers
  (XEN)  key '%' (ascii '25') =3D> Trap to xendbg
  (XEN)  key '*' (ascii '2a') =3D> print all diagnostics
  (XEN)  key '0' (ascii '30') =3D> dump Dom0 registers
  (XEN)  key 'C' (ascii '43') =3D> trigger a crashdump
  (XEN)  key 'H' (ascii '48') =3D> dump heap info
  (XEN)  key 'K' (ascii '4b') =3D> kick polling vcpus
  (XEN)  key 'N' (ascii '4e') =3D> NMI statistics
  (XEN)  key 'Q' (ascii '51') =3D> dump PCI devices
  (XEN)  key 'R' (ascii '52') =3D> reboot machine
  (XEN)  key 'a' (ascii '61') =3D> dump timer queues
  (XEN)  key 'c' (ascii '63') =3D> dump cx structures
  (XEN)  key 'd' (ascii '64') =3D> dump registers
  (XEN)  key 'e' (ascii '65') =3D> dump evtchn info
  (XEN)  key 'h' (ascii '68') =3D> show this message
  (XEN)  key 'i' (ascii '69') =3D> dump interrupt bindings
  (XEN)  key 'm' (ascii '6d') =3D> memory info
  (XEN)  key 'n' (ascii '6e') =3D> trigger an NMI
  (XEN)  key 'q' (ascii '71') =3D> dump domain (and guest debug) info
  (XEN)  key 'r' (ascii '72') =3D> dump run queues
  (XEN)  key 't' (ascii '74') =3D> display multi-cpu clock info
  (XEN)  key 'u' (ascii '75') =3D> dump numa info
  (XEN)  key 'v' (ascii '76') =3D> dump Intel's VMCS
  (XEN)  key 'z' (ascii '7a') =3D> print ioapic info
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 40 dying
  (XEN) grant_table.c:1408:d0 dest domain 40 dying
  (XEN) grant_table.c:1408:d0 dest domain 40 dying
  (XEN) grant_table.c:1408:d0 dest domain 40 dying

Any quick help will be really appreciated.

Thanks & Regards,
PANKAJ KUMAR BISWAS


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0BANPMAILBOX01_
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: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>&nbsp; Hi Team,<=
o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNorma=
l>For a XenServer (5.6 sp2) crash I have got following &nbsp;in the crash l=
ogs. &nbsp;Can somebody tell me why I can see(<b>grant_table.c:1408:d0 dest=
 domain 40 dying) </b>&nbsp;this and how I can resolve it, if it is an issu=
e.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNo=
rmal>(XEN) *** Serial input -&gt; Xen (type 'CTRL-a' three times to switch =
input to DOM0)<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN) Freed 128kB =
init memory.<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN) __csched_vcpu_=
acct_start: setting dom 0 as the privileged domain<o:p></o:p></p><p class=
=3DMsoNormal>&nbsp; (XEN) <b>ioapic_guest_write: apic=3D0, pin=3D19, old_ir=
q=3D-1, new_irq=3D-1</b><o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN) io=
apic_guest_write: old_entry=3D00010a44, new_entry=3D0001a031<o:p></o:p></p>=
<p class=3DMsoNormal>&nbsp; (XEN) ioapic_guest_write: Special delivery mode=
 2 with non-zero vector 44<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN) =
'h' pressed -&gt; showing installed handlers<o:p></o:p></p><p class=3DMsoNo=
rmal>&nbsp; (XEN)&nbsp; key '%' (ascii '25') =3D&gt; Trap to xendbg<o:p></o=
:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key '*' (ascii '2a') =3D&gt;=
 print all diagnostics<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp=
; key '0' (ascii '30') =3D&gt; dump Dom0 registers<o:p></o:p></p><p class=
=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'C' (ascii '43') =3D&gt; trigger a cras=
hdump<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'H' (ascii =
'48') =3D&gt; dump heap info<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN=
)&nbsp; key 'K' (ascii '4b') =3D&gt; kick polling vcpus<o:p></o:p></p><p cl=
ass=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'N' (ascii '4e') =3D&gt; NMI statist=
ics<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'Q' (ascii '5=
1') =3D&gt; dump PCI devices<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN=
)&nbsp; key 'R' (ascii '52') =3D&gt; reboot machine<o:p></o:p></p><p class=
=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'a' (ascii '61') =3D&gt; dump timer que=
ues<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'c' (ascii '6=
3') =3D&gt; dump cx structures<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (X=
EN)&nbsp; key 'd' (ascii '64') =3D&gt; dump registers<o:p></o:p></p><p clas=
s=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'e' (ascii '65') =3D&gt; dump evtchn i=
nfo<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'h' (ascii '6=
8') =3D&gt; show this message<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XE=
N)&nbsp; key 'i' (ascii '69') =3D&gt; dump interrupt bindings<o:p></o:p></p=
><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'm' (ascii '6d') =3D&gt; memor=
y info<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'n' (ascii=
 '6e') =3D&gt; trigger an NMI<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XE=
N)&nbsp; key 'q' (ascii '71') =3D&gt; dump domain (and guest debug) info<o:=
p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'r' (ascii '72') =
=3D&gt; dump run queues<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbs=
p; key 't' (ascii '74') =3D&gt; display multi-cpu clock info<o:p></o:p></p>=
<p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'u' (ascii '75') =3D&gt; dump n=
uma info<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'v' (asc=
ii '76') =3D&gt; dump Intel's VMCS<o:p></o:p></p><p class=3DMsoNormal>&nbsp=
; (XEN)&nbsp; key 'z' (ascii '7a') =3D&gt; print ioapic info<o:p></o:p></p>=
<p class=3DMsoNormal>&nbsp; <b>(XEN) grant_table.c:1408:d0 dest domain 29 d=
ying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1=
408:d0 dest domain 29 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp=
; (XEN) grant_table.c:1408:d0 dest domain 29 dying<o:p></o:p></b></p><p cla=
ss=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1408:d0 dest domain 29 dying<o=
:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1408:d0=
 dest domain 29 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN=
) grant_table.c:1408:d0 dest domain 29 dying<o:p></o:p></b></p><p class=3DM=
soNormal><b>&nbsp; (XEN) grant_table.c:1408:d0 dest domain 29 dying<o:p></o=
:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1408:d0 dest =
domain 29 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) gran=
t_table.c:1408:d0 dest domain 29 dying<o:p></o:p></b></p><p class=3DMsoNorm=
al><b>&nbsp; (XEN) grant_table.c:1408:d0 dest domain 40 dying<o:p></o:p></b=
></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1408:d0 dest domain=
 40 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_tabl=
e.c:1408:d0 dest domain 40 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>=
&nbsp; (XEN) grant_table.c:1408:d0 dest domain 40 dying<o:p></o:p></b></p><=
p class=3DMsoNormal><b><o:p>&nbsp;</o:p></b></p><p class=3DMsoNormal>Any qu=
ick help will be really appreciated.<o:p></o:p></p><p class=3DMsoNormal><o:=
p>&nbsp;</o:p></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambr=
ia","serif"'>Thanks &amp; Regards,<o:p></o:p></span></b></p><p class=3DMsoN=
ormal><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></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0BANPMAILBOX01_--


--===============2304280985412632429==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2304280985412632429==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 07:11:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 07:11:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpE2z-0002nu-Hh; Mon, 23 Jan 2012 07:10:33 +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 1RpE2x-0002np-35
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 07:10:31 +0000
X-Env-Sender: pankaj.kumarbiswas@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327302611!11969704!1
X-Originating-IP: [203.166.19.134]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjAzLjE2Ni4xOS4xMzQgPT4gNDEzMDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16268 invoked from network); 23 Jan 2012 07:10:23 -0000
Received: from smtp.citrix.com.au (HELO SMTP.CITRIX.COM.AU) (203.166.19.134)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 07:10:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,554,1320624000"; d="scan'208,217";a="10048842"
Received: from banpmailmx01.citrite.net ([10.103.128.73])
	by SYDPIPO01.CITRIX.COM.AU with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 07:10:09 +0000
Received: from BANPMAILBOX01.citrite.net ([10.103.128.72]) by
	BANPMAILMX01.citrite.net ([10.103.128.73]) with mapi; Mon, 23 Jan 2012
	12:40:08 +0530
From: Pankaj Kumar Biswas <pankaj.kumarbiswas@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 12:40:07 +0530
Thread-Topic: Re: Grant-table error messages in a crash log
Thread-Index: AczZnaW0Rp3k/h7xQmCWirW9KR1XUQ==
Message-ID: <64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0@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] Grant-table error messages in a crash 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: multipart/mixed; boundary="===============2304280985412632429=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2304280985412632429==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0BANPMAILBOX01_"

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0BANPMAILBOX01_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

  Hi Team,

For a XenServer (5.6 sp2) crash I have got following  in the crash logs.  C=
an somebody tell me why I can see(grant_table.c:1408:d0 dest domain 40 dyin=
g)  this and how I can resolve it, if it is an issue.

(XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to=
 DOM0)
  (XEN) Freed 128kB init memory.
  (XEN) __csched_vcpu_acct_start: setting dom 0 as the privileged domain
  (XEN) ioapic_guest_write: apic=3D0, pin=3D19, old_irq=3D-1, new_irq=3D-1
  (XEN) ioapic_guest_write: old_entry=3D00010a44, new_entry=3D0001a031
  (XEN) ioapic_guest_write: Special delivery mode 2 with non-zero vector 44
  (XEN) 'h' pressed -> showing installed handlers
  (XEN)  key '%' (ascii '25') =3D> Trap to xendbg
  (XEN)  key '*' (ascii '2a') =3D> print all diagnostics
  (XEN)  key '0' (ascii '30') =3D> dump Dom0 registers
  (XEN)  key 'C' (ascii '43') =3D> trigger a crashdump
  (XEN)  key 'H' (ascii '48') =3D> dump heap info
  (XEN)  key 'K' (ascii '4b') =3D> kick polling vcpus
  (XEN)  key 'N' (ascii '4e') =3D> NMI statistics
  (XEN)  key 'Q' (ascii '51') =3D> dump PCI devices
  (XEN)  key 'R' (ascii '52') =3D> reboot machine
  (XEN)  key 'a' (ascii '61') =3D> dump timer queues
  (XEN)  key 'c' (ascii '63') =3D> dump cx structures
  (XEN)  key 'd' (ascii '64') =3D> dump registers
  (XEN)  key 'e' (ascii '65') =3D> dump evtchn info
  (XEN)  key 'h' (ascii '68') =3D> show this message
  (XEN)  key 'i' (ascii '69') =3D> dump interrupt bindings
  (XEN)  key 'm' (ascii '6d') =3D> memory info
  (XEN)  key 'n' (ascii '6e') =3D> trigger an NMI
  (XEN)  key 'q' (ascii '71') =3D> dump domain (and guest debug) info
  (XEN)  key 'r' (ascii '72') =3D> dump run queues
  (XEN)  key 't' (ascii '74') =3D> display multi-cpu clock info
  (XEN)  key 'u' (ascii '75') =3D> dump numa info
  (XEN)  key 'v' (ascii '76') =3D> dump Intel's VMCS
  (XEN)  key 'z' (ascii '7a') =3D> print ioapic info
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 29 dying
  (XEN) grant_table.c:1408:d0 dest domain 40 dying
  (XEN) grant_table.c:1408:d0 dest domain 40 dying
  (XEN) grant_table.c:1408:d0 dest domain 40 dying
  (XEN) grant_table.c:1408:d0 dest domain 40 dying

Any quick help will be really appreciated.

Thanks & Regards,
PANKAJ KUMAR BISWAS


--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0BANPMAILBOX01_
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: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>&nbsp; Hi Team,<=
o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNorma=
l>For a XenServer (5.6 sp2) crash I have got following &nbsp;in the crash l=
ogs. &nbsp;Can somebody tell me why I can see(<b>grant_table.c:1408:d0 dest=
 domain 40 dying) </b>&nbsp;this and how I can resolve it, if it is an issu=
e.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNo=
rmal>(XEN) *** Serial input -&gt; Xen (type 'CTRL-a' three times to switch =
input to DOM0)<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN) Freed 128kB =
init memory.<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN) __csched_vcpu_=
acct_start: setting dom 0 as the privileged domain<o:p></o:p></p><p class=
=3DMsoNormal>&nbsp; (XEN) <b>ioapic_guest_write: apic=3D0, pin=3D19, old_ir=
q=3D-1, new_irq=3D-1</b><o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN) io=
apic_guest_write: old_entry=3D00010a44, new_entry=3D0001a031<o:p></o:p></p>=
<p class=3DMsoNormal>&nbsp; (XEN) ioapic_guest_write: Special delivery mode=
 2 with non-zero vector 44<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN) =
'h' pressed -&gt; showing installed handlers<o:p></o:p></p><p class=3DMsoNo=
rmal>&nbsp; (XEN)&nbsp; key '%' (ascii '25') =3D&gt; Trap to xendbg<o:p></o=
:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key '*' (ascii '2a') =3D&gt;=
 print all diagnostics<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp=
; key '0' (ascii '30') =3D&gt; dump Dom0 registers<o:p></o:p></p><p class=
=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'C' (ascii '43') =3D&gt; trigger a cras=
hdump<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'H' (ascii =
'48') =3D&gt; dump heap info<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN=
)&nbsp; key 'K' (ascii '4b') =3D&gt; kick polling vcpus<o:p></o:p></p><p cl=
ass=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'N' (ascii '4e') =3D&gt; NMI statist=
ics<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'Q' (ascii '5=
1') =3D&gt; dump PCI devices<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN=
)&nbsp; key 'R' (ascii '52') =3D&gt; reboot machine<o:p></o:p></p><p class=
=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'a' (ascii '61') =3D&gt; dump timer que=
ues<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'c' (ascii '6=
3') =3D&gt; dump cx structures<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (X=
EN)&nbsp; key 'd' (ascii '64') =3D&gt; dump registers<o:p></o:p></p><p clas=
s=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'e' (ascii '65') =3D&gt; dump evtchn i=
nfo<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'h' (ascii '6=
8') =3D&gt; show this message<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XE=
N)&nbsp; key 'i' (ascii '69') =3D&gt; dump interrupt bindings<o:p></o:p></p=
><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'm' (ascii '6d') =3D&gt; memor=
y info<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'n' (ascii=
 '6e') =3D&gt; trigger an NMI<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XE=
N)&nbsp; key 'q' (ascii '71') =3D&gt; dump domain (and guest debug) info<o:=
p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'r' (ascii '72') =
=3D&gt; dump run queues<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbs=
p; key 't' (ascii '74') =3D&gt; display multi-cpu clock info<o:p></o:p></p>=
<p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'u' (ascii '75') =3D&gt; dump n=
uma info<o:p></o:p></p><p class=3DMsoNormal>&nbsp; (XEN)&nbsp; key 'v' (asc=
ii '76') =3D&gt; dump Intel's VMCS<o:p></o:p></p><p class=3DMsoNormal>&nbsp=
; (XEN)&nbsp; key 'z' (ascii '7a') =3D&gt; print ioapic info<o:p></o:p></p>=
<p class=3DMsoNormal>&nbsp; <b>(XEN) grant_table.c:1408:d0 dest domain 29 d=
ying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1=
408:d0 dest domain 29 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp=
; (XEN) grant_table.c:1408:d0 dest domain 29 dying<o:p></o:p></b></p><p cla=
ss=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1408:d0 dest domain 29 dying<o=
:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1408:d0=
 dest domain 29 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN=
) grant_table.c:1408:d0 dest domain 29 dying<o:p></o:p></b></p><p class=3DM=
soNormal><b>&nbsp; (XEN) grant_table.c:1408:d0 dest domain 29 dying<o:p></o=
:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1408:d0 dest =
domain 29 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) gran=
t_table.c:1408:d0 dest domain 29 dying<o:p></o:p></b></p><p class=3DMsoNorm=
al><b>&nbsp; (XEN) grant_table.c:1408:d0 dest domain 40 dying<o:p></o:p></b=
></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_table.c:1408:d0 dest domain=
 40 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>&nbsp; (XEN) grant_tabl=
e.c:1408:d0 dest domain 40 dying<o:p></o:p></b></p><p class=3DMsoNormal><b>=
&nbsp; (XEN) grant_table.c:1408:d0 dest domain 40 dying<o:p></o:p></b></p><=
p class=3DMsoNormal><b><o:p>&nbsp;</o:p></b></p><p class=3DMsoNormal>Any qu=
ick help will be really appreciated.<o:p></o:p></p><p class=3DMsoNormal><o:=
p>&nbsp;</o:p></p><p class=3DMsoNormal><b><span style=3D'font-family:"Cambr=
ia","serif"'>Thanks &amp; Regards,<o:p></o:p></span></b></p><p class=3DMsoN=
ormal><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></html>=

--_000_64FB1554ABC9B44FAA773FBD6CB889C2F9138A0EF0BANPMAILBOX01_--


--===============2304280985412632429==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2304280985412632429==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:25:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpG8n-0004C8-Bh; Mon, 23 Jan 2012 09:24: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 1RpG8l-0004C3-9v
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:24:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327310672!10243575!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6099 invoked from network); 23 Jan 2012 09:24:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 09:24:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 09:24:32 +0000
Message-Id: <4F1D355D020000780006E4E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 09:24:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
	<CB3E3263.37CC2%keir@xen.org>
	<20120122203714.GB30288@andromeda.dapyr.net>
In-Reply-To: <20120122203714.GB30288@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	andres@lagarcavilla.org
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 21:37, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> So for the "Fun" of it I tried to see if the 'struct
> xen_processor_performance' has some 32/64-bit issues and was surprised
> to find they do. What I am more surprised to find is that nobody seems
> to have had any troubles with this as it seems to have been there since
> it was initially implemented. The major issue would have been with the
> 'shared_type', 'domain_info' and the pointer to the 'states' being at
> different offsets (So when running a 32-bit dom0 with a 64-bit
> hypervisor).

Are you having an actual problem with the layout differences, or
did you just observe them? As Keir said, this is being dealt with
inside the hypervisor - the (Dom0) kernel doesn't need to care at
all (which was the primary requirement when the 32-on-64
support got added).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:25:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09:25:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpG8n-0004C8-Bh; Mon, 23 Jan 2012 09:24: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 1RpG8l-0004C3-9v
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:24:39 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327310672!10243575!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6099 invoked from network); 23 Jan 2012 09:24:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 09:24:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 09:24:32 +0000
Message-Id: <4F1D355D020000780006E4E9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 09:24:29 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>
References: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
	<CB3E3263.37CC2%keir@xen.org>
	<20120122203714.GB30288@andromeda.dapyr.net>
In-Reply-To: <20120122203714.GB30288@andromeda.dapyr.net>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com,
	Keir Fraser <keir@xen.org>, ian.campbell@citrix.com,
	andres@lagarcavilla.org
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 21:37, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> So for the "Fun" of it I tried to see if the 'struct
> xen_processor_performance' has some 32/64-bit issues and was surprised
> to find they do. What I am more surprised to find is that nobody seems
> to have had any troubles with this as it seems to have been there since
> it was initially implemented. The major issue would have been with the
> 'shared_type', 'domain_info' and the pointer to the 'states' being at
> different offsets (So when running a 32-bit dom0 with a 64-bit
> hypervisor).

Are you having an actual problem with the layout differences, or
did you just observe them? As Keir said, this is being dealt with
inside the hypervisor - the (Dom0) kernel doesn't need to care at
all (which was the primary requirement when the 32-on-64
support got added).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:37:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpGKU-0004MB-J4; Mon, 23 Jan 2012 09:36:46 +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 1RpGKS-0004M3-Oa
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:36:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327311344!58012043!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6906 invoked from network); 23 Jan 2012 09:35:44 -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; 23 Jan 2012 09:35:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 09:36:45 +0000
Message-Id: <4F1D3838020000780006E4FA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 09:36:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Marcus Granado" <marcus.granado@citrix.com>
References: <4F19B623.1060105@citrix.com>
In-Reply-To: <4F19B623.1060105@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xenoprof: Adjust indentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 19:44, Marcus Granado <marcus.granado@citrix.com> wrote:
> xenoprof: Adjust indentation
> 
> Bring indentation into Xen hypervisor standard coding style.

If you fiddle with indentation, then the rest of the coding style should
really also be adjusted at once. Ending up with a hybrid between Linux
and Xen imo is worse than using one of the styles consistently.

Jan

> No functional changes.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> 
> diff -r 9cdcedc133e5 -r f6953e89913f xen/arch/x86/oprofile/backtrace.c
> --- a/xen/arch/x86/oprofile/backtrace.c    Wed Jan 11 10:34:45 2012 +0100
> +++ b/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:23:02 2012 +0000
> @@ -16,48 +16,48 @@
>   #include<asm/guest_access.h>
> 
>   struct frame_head {
> -    struct frame_head * ebp;
> -    unsigned long ret;
> +    struct frame_head * ebp;
> +    unsigned long ret;
>   } __attribute__((packed));
> 
>   static struct frame_head *
>   dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu,
>                 struct frame_head * head, int mode)
>   {
> -    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
> -        return 0;
> -
> -    /* frame pointers should strictly progress back up the stack
> -     * (towards higher addresses) */
> -    if (head >= head->ebp)
> -        return NULL;
> -
> -    return head->ebp;
> +    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
> +        return 0;
> +
> +    /* frame pointers should strictly progress back up the stack
> +     * (towards higher addresses) */
> +    if (head >= head->ebp)
> +        return NULL;
> +
> +    return head->ebp;
>   }
> 
>   static struct frame_head *
>   dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
>                struct frame_head * head, int mode)
>   {
> -    struct frame_head bufhead[2];
> -    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
> +    struct frame_head bufhead[2];
> +    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
> 
> -    /* Also check accessibility of one struct frame_head beyond */
> -    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
> -        return 0;
> -    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
> -        sizeof(bufhead)))
> -        return 0;
> -
> -    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
> -        return 0;
> -
> -    /* frame pointers should strictly progress back up the stack
> -     * (towards higher addresses) */
> -    if (head >= bufhead[0].ebp)
> -        return NULL;
> -
> -    return bufhead[0].ebp;
> +    /* Also check accessibility of one struct frame_head beyond */
> +    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
> +        return 0;
> +    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
> +                                 sizeof(bufhead)))
> +        return 0;
> +
> +    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
> +        return 0;
> +
> +    /* frame pointers should strictly progress back up the stack
> +     * (towards higher addresses) */
> +    if (head >= bufhead[0].ebp)
> +        return NULL;
> +
> +    return bufhead[0].ebp;
>   }
> 
>   /*
> @@ -94,22 +94,22 @@ dump_guest_backtrace(struct domain *d, s
>   static int valid_hypervisor_stack(struct frame_head * head,
>                     struct cpu_user_regs * regs)
>   {
> -    unsigned long headaddr = (unsigned long)head;
> +    unsigned long headaddr = (unsigned long)head;
>   #ifdef CONFIG_X86_64
> -    unsigned long stack = (unsigned long)regs->rsp;
> +    unsigned long stack = (unsigned long)regs->rsp;
>   #else
> -    unsigned long stack = (unsigned long)regs;
> +    unsigned long stack = (unsigned long)regs;
>   #endif
> -    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
> +    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
> 
> -    return headaddr > stack && headaddr < stack_base;
> +    return headaddr > stack && headaddr < stack_base;
>   }
>   #else
>   /* without fp, it's just junk */
>   static int valid_hypervisor_stack(struct frame_head * head,
>                     struct cpu_user_regs * regs)
>   {
> -    return 0;
> +    return 0;
>   }
>   #endif
> 
> @@ -117,16 +117,16 @@ void xenoprof_backtrace(struct domain *d
>               struct cpu_user_regs * const regs,
>               unsigned long depth, int mode)
>   {
> -    struct frame_head *head;
> +    struct frame_head *head;
> 
> -    head = (struct frame_head *)regs->ebp;
> +    head = (struct frame_head *)regs->ebp;
> 
> -    if (mode > 1) {
> -        while (depth-- && valid_hypervisor_stack(head, regs))
> -            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
> -        return;
> -    }
> +    if (mode > 1) {
> +        while (depth-- && valid_hypervisor_stack(head, regs))
> +            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
> +        return;
> +    }
> 
> -    while (depth-- && head)
> -        head = dump_guest_backtrace(d, vcpu, head, mode);
> +    while (depth-- && head)
> +        head = dump_guest_backtrace(d, vcpu, head, mode);
>   }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:37:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09:37:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpGKU-0004MB-J4; Mon, 23 Jan 2012 09:36:46 +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 1RpGKS-0004M3-Oa
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:36:44 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327311344!58012043!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6906 invoked from network); 23 Jan 2012 09:35:44 -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; 23 Jan 2012 09:35:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 09:36:45 +0000
Message-Id: <4F1D3838020000780006E4FA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 09:36:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Marcus Granado" <marcus.granado@citrix.com>
References: <4F19B623.1060105@citrix.com>
In-Reply-To: <4F19B623.1060105@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 1/3] xenoprof: Adjust indentation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 20.01.12 at 19:44, Marcus Granado <marcus.granado@citrix.com> wrote:
> xenoprof: Adjust indentation
> 
> Bring indentation into Xen hypervisor standard coding style.

If you fiddle with indentation, then the rest of the coding style should
really also be adjusted at once. Ending up with a hybrid between Linux
and Xen imo is worse than using one of the styles consistently.

Jan

> No functional changes.
> 
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> 
> diff -r 9cdcedc133e5 -r f6953e89913f xen/arch/x86/oprofile/backtrace.c
> --- a/xen/arch/x86/oprofile/backtrace.c    Wed Jan 11 10:34:45 2012 +0100
> +++ b/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:23:02 2012 +0000
> @@ -16,48 +16,48 @@
>   #include<asm/guest_access.h>
> 
>   struct frame_head {
> -    struct frame_head * ebp;
> -    unsigned long ret;
> +    struct frame_head * ebp;
> +    unsigned long ret;
>   } __attribute__((packed));
> 
>   static struct frame_head *
>   dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu,
>                 struct frame_head * head, int mode)
>   {
> -    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
> -        return 0;
> -
> -    /* frame pointers should strictly progress back up the stack
> -     * (towards higher addresses) */
> -    if (head >= head->ebp)
> -        return NULL;
> -
> -    return head->ebp;
> +    if (!xenoprof_add_trace(d, vcpu, head->ret, mode))
> +        return 0;
> +
> +    /* frame pointers should strictly progress back up the stack
> +     * (towards higher addresses) */
> +    if (head >= head->ebp)
> +        return NULL;
> +
> +    return head->ebp;
>   }
> 
>   static struct frame_head *
>   dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
>                struct frame_head * head, int mode)
>   {
> -    struct frame_head bufhead[2];
> -    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
> +    struct frame_head bufhead[2];
> +    XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
> 
> -    /* Also check accessibility of one struct frame_head beyond */
> -    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
> -        return 0;
> -    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
> -        sizeof(bufhead)))
> -        return 0;
> -
> -    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
> -        return 0;
> -
> -    /* frame pointers should strictly progress back up the stack
> -     * (towards higher addresses) */
> -    if (head >= bufhead[0].ebp)
> -        return NULL;
> -
> -    return bufhead[0].ebp;
> +    /* Also check accessibility of one struct frame_head beyond */
> +    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
> +        return 0;
> +    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
> +                                 sizeof(bufhead)))
> +        return 0;
> +
> +    if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
> +        return 0;
> +
> +    /* frame pointers should strictly progress back up the stack
> +     * (towards higher addresses) */
> +    if (head >= bufhead[0].ebp)
> +        return NULL;
> +
> +    return bufhead[0].ebp;
>   }
> 
>   /*
> @@ -94,22 +94,22 @@ dump_guest_backtrace(struct domain *d, s
>   static int valid_hypervisor_stack(struct frame_head * head,
>                     struct cpu_user_regs * regs)
>   {
> -    unsigned long headaddr = (unsigned long)head;
> +    unsigned long headaddr = (unsigned long)head;
>   #ifdef CONFIG_X86_64
> -    unsigned long stack = (unsigned long)regs->rsp;
> +    unsigned long stack = (unsigned long)regs->rsp;
>   #else
> -    unsigned long stack = (unsigned long)regs;
> +    unsigned long stack = (unsigned long)regs;
>   #endif
> -    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
> +    unsigned long stack_base = (stack & ~(STACK_SIZE - 1)) + STACK_SIZE;
> 
> -    return headaddr > stack && headaddr < stack_base;
> +    return headaddr > stack && headaddr < stack_base;
>   }
>   #else
>   /* without fp, it's just junk */
>   static int valid_hypervisor_stack(struct frame_head * head,
>                     struct cpu_user_regs * regs)
>   {
> -    return 0;
> +    return 0;
>   }
>   #endif
> 
> @@ -117,16 +117,16 @@ void xenoprof_backtrace(struct domain *d
>               struct cpu_user_regs * const regs,
>               unsigned long depth, int mode)
>   {
> -    struct frame_head *head;
> +    struct frame_head *head;
> 
> -    head = (struct frame_head *)regs->ebp;
> +    head = (struct frame_head *)regs->ebp;
> 
> -    if (mode > 1) {
> -        while (depth-- && valid_hypervisor_stack(head, regs))
> -            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
> -        return;
> -    }
> +    if (mode > 1) {
> +        while (depth-- && valid_hypervisor_stack(head, regs))
> +            head = dump_hypervisor_backtrace(d, vcpu, head, mode);
> +        return;
> +    }
> 
> -    while (depth-- && head)
> -        head = dump_guest_backtrace(d, vcpu, head, mode);
> +    while (depth-- && head)
> +        head = dump_guest_backtrace(d, vcpu, head, mode);
>   }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:51:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09:51:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpGY7-0004dB-HQ; Mon, 23 Jan 2012 09:50:51 +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 1RpGY6-0004d3-6L
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:50:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327312237!12043583!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 23792 invoked from network); 23 Jan 2012 09:50:44 -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; 23 Jan 2012 09:50:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 09:50:43 +0000
Message-Id: <4F1D3B79020000780006E509@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 09:50:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Marcus Granado" <marcus.granado@citrix.com>
References: <4F19B62C.9020402@citrix.com>
In-Reply-To: <4F19B62C.9020402@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xenoprof: Handle 32-bit guest stacks
 properly in a 64-bit 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 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
> xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor
> 
> The dump_guest_backtrace() function attempted to walk the stack
> based on the assumption that the guest and hypervisor pointer sizes
> were the same; thus any 32-bit guest running under 64-bit hypervisor
> would have unreliable results.
> 
> In 64-bit mode, read the 32-bit stack frame properly.
> 
> Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> 
> diff -r f6953e89913f -r 21e7744a52b1 xen/arch/x86/oprofile/backtrace.c
> --- a/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:23:02 2012 +0000
> +++ b/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:35:06 2012 +0000
> @@ -20,6 +20,13 @@ struct frame_head {
>       unsigned long ret;
>   } __attribute__((packed));
> 
> +#ifdef CONFIG_X86_64
> +struct frame_head_32bit {
> +    uint32_t ebp;
> +    unsigned long ret;

unsigned long (i.e. 64 bits)?

> +} __attribute__((packed));
> +#endif
> +
>   static struct frame_head *
>   dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu,
>                 struct frame_head * head, int mode)
> @@ -35,19 +42,46 @@ dump_hypervisor_backtrace(struct domain
>       return head->ebp;
>   }
> 
> +#ifdef CONFIG_X86_64
> +static inline int is_32bit_vcpu(struct vcpu *vcpu)
> +{
> +    if (is_hvm_vcpu(vcpu))
> +        return !hvm_long_mode_enabled(vcpu);
> +    else
> +        return is_pv_32bit_vcpu(vcpu);
> +}
> +#endif
> +
>   static struct frame_head *
>   dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
>                struct frame_head * head, int mode)
>   {
>       struct frame_head bufhead[2];
>       XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
> -
> -    /* Also check accessibility of one struct frame_head beyond */
> -    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
> -        return 0;
> -    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
> -                                 sizeof(bufhead)))
> -        return 0;
> +
> +#ifdef CONFIG_X86_64
> +    if ( is_32bit_vcpu(vcpu) )
> +    {
> +        struct frame_head_32bit bufhead32[2];
> +        /* Also check accessibility of one struct frame_head beyond */
> +        if (!guest_handle_okay(guest_head, sizeof(bufhead32)))
> +            return 0;
> +        if (__copy_from_guest_offset((char *)bufhead32, guest_head, 0,

If you're adding a compat mode guest case here, then you should
also use compat mode accessors (compat_handle_okay(),
__copy_from_compat_offset()), implying that you also have a local
handle variable of the appropriate type (and perhaps moving the
native one down into the 'else' body).

Also, as you're touching this code anyway, the
__copy_from_..._offset() here and below, as they're passing literal
zero for the offset, can be abbreviated by using __copy_from_...()
(i.e. without the offset).

Jan

> +                                     sizeof(bufhead32)))
> +            return 0;
> +        bufhead[0].ebp=(struct frame_head *)(unsigned long)bufhead32[0].ebp;
> +        bufhead[0].ret=bufhead32[0].ret;
> +    }
> +    else
> +#endif
> +    {
> +        /* Also check accessibility of one struct frame_head beyond */
> +        if (!guest_handle_okay(guest_head, sizeof(bufhead)))
> +            return 0;
> +        if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
> +                                     sizeof(bufhead)))
> +            return 0;
> +    }
> 
>       if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
>           return 0;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:51:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09:51:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpGY7-0004dB-HQ; Mon, 23 Jan 2012 09:50:51 +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 1RpGY6-0004d3-6L
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:50:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327312237!12043583!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 23792 invoked from network); 23 Jan 2012 09:50:44 -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; 23 Jan 2012 09:50:44 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 09:50:43 +0000
Message-Id: <4F1D3B79020000780006E509@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 09:50:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Marcus Granado" <marcus.granado@citrix.com>
References: <4F19B62C.9020402@citrix.com>
In-Reply-To: <4F19B62C.9020402@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xenoprof: Handle 32-bit guest stacks
 properly in a 64-bit 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 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
> xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor
> 
> The dump_guest_backtrace() function attempted to walk the stack
> based on the assumption that the guest and hypervisor pointer sizes
> were the same; thus any 32-bit guest running under 64-bit hypervisor
> would have unreliable results.
> 
> In 64-bit mode, read the 32-bit stack frame properly.
> 
> Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> 
> diff -r f6953e89913f -r 21e7744a52b1 xen/arch/x86/oprofile/backtrace.c
> --- a/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:23:02 2012 +0000
> +++ b/xen/arch/x86/oprofile/backtrace.c    Wed Jan 18 17:35:06 2012 +0000
> @@ -20,6 +20,13 @@ struct frame_head {
>       unsigned long ret;
>   } __attribute__((packed));
> 
> +#ifdef CONFIG_X86_64
> +struct frame_head_32bit {
> +    uint32_t ebp;
> +    unsigned long ret;

unsigned long (i.e. 64 bits)?

> +} __attribute__((packed));
> +#endif
> +
>   static struct frame_head *
>   dump_hypervisor_backtrace(struct domain *d, struct vcpu *vcpu,
>                 struct frame_head * head, int mode)
> @@ -35,19 +42,46 @@ dump_hypervisor_backtrace(struct domain
>       return head->ebp;
>   }
> 
> +#ifdef CONFIG_X86_64
> +static inline int is_32bit_vcpu(struct vcpu *vcpu)
> +{
> +    if (is_hvm_vcpu(vcpu))
> +        return !hvm_long_mode_enabled(vcpu);
> +    else
> +        return is_pv_32bit_vcpu(vcpu);
> +}
> +#endif
> +
>   static struct frame_head *
>   dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
>                struct frame_head * head, int mode)
>   {
>       struct frame_head bufhead[2];
>       XEN_GUEST_HANDLE(char) guest_head = guest_handle_from_ptr(head, char);
> -
> -    /* Also check accessibility of one struct frame_head beyond */
> -    if (!guest_handle_okay(guest_head, sizeof(bufhead)))
> -        return 0;
> -    if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
> -                                 sizeof(bufhead)))
> -        return 0;
> +
> +#ifdef CONFIG_X86_64
> +    if ( is_32bit_vcpu(vcpu) )
> +    {
> +        struct frame_head_32bit bufhead32[2];
> +        /* Also check accessibility of one struct frame_head beyond */
> +        if (!guest_handle_okay(guest_head, sizeof(bufhead32)))
> +            return 0;
> +        if (__copy_from_guest_offset((char *)bufhead32, guest_head, 0,

If you're adding a compat mode guest case here, then you should
also use compat mode accessors (compat_handle_okay(),
__copy_from_compat_offset()), implying that you also have a local
handle variable of the appropriate type (and perhaps moving the
native one down into the 'else' body).

Also, as you're touching this code anyway, the
__copy_from_..._offset() here and below, as they're passing literal
zero for the offset, can be abbreviated by using __copy_from_...()
(i.e. without the offset).

Jan

> +                                     sizeof(bufhead32)))
> +            return 0;
> +        bufhead[0].ebp=(struct frame_head *)(unsigned long)bufhead32[0].ebp;
> +        bufhead[0].ret=bufhead32[0].ret;
> +    }
> +    else
> +#endif
> +    {
> +        /* Also check accessibility of one struct frame_head beyond */
> +        if (!guest_handle_okay(guest_head, sizeof(bufhead)))
> +            return 0;
> +        if (__copy_from_guest_offset((char *)bufhead, guest_head, 0,
> +                                     sizeof(bufhead)))
> +            return 0;
> +    }
> 
>       if (!xenoprof_add_trace(d, vcpu, bufhead[0].ret, mode))
>           return 0;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:57:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpGe3-0004ms-D5; Mon, 23 Jan 2012 09:56:59 +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 1RpGe1-0004ml-S4
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:56:58 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327312611!2928503!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMzQzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8012 invoked from network); 23 Jan 2012 09:56:51 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 09:56: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:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=ukag/fioFCsFwFa5gwebECEPwkQiclbmGbb9QB4HWm13eQCzut8Y+AQB
	uf1UZhspWYobp7jER4hQcnIEtwfJHkIlCk0O3N18D+RlfhxVXyVc49VG+
	obRyAStzrCybcBaULGvvXl2E/1yTJy5hlEE+NS94ca0JtbrOEo3af2FVy
	HZPqDgm0WLw4rn/sDXpi6NjutHMlwc5+W1nnOroHa3BzsQygZe2LUibp5
	E/7ItMesYSi6iimDljGvuZwNntX5r;
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=1327312612; x=1358848612;
	h=mime-version:subject:message-id:date:from:to;
	bh=Lw4qpIfgOaMZyDxYDrrbrD4RuzZPcH0IJtw6EgTqh74=;
	b=nApmjsBHKZxpnwopyTQAG5Wq4Jp/o9HliplBqJg2zDy+X+cKKbfwfH01
	ej430jTJioiSft19AzyIF895il74WfuTaulwJW6IKkwoQbG6ZpJoKD/6w
	9VG+KjFhk2SLxhNcPHPiKuvDblTsm293cTMLGzAxTZIRWUCg3WkJza5AW
	+/vCbxape3tITaIHAlRK8bNRkl35SRzL3/l7sDi9e6PaDkgEi32Forb8C
	RDR5o+9z02qhZotb+pVdSrnGkVJ2K;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="99394088"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 23 Jan 2012 10:56:51 +0100
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="127565524"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 23 Jan 2012 10:56:51 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 44ABD960CFD;
	Mon, 23 Jan 2012 10:56:51 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============4197656787728731566=="
MIME-Version: 1.0
X-Mercurial-Node: cee17928d4eff5e7873f30276f424e16dca878ad
Message-Id: <cee17928d4eff5e7873f.1327312293@nehalem1>
Date: Mon, 23 Jan 2012 10:51:33 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4197656787728731566==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com


3 files changed, 20 insertions(+), 8 deletions(-)
xen/common/cpupool.c  |    9 +++++++++
xen/common/domain.c   |    9 ++++++++-
xen/common/schedule.c |   10 +++-------



--===============4197656787728731566==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327311901 -3600
# Node ID cee17928d4eff5e7873f30276f424e16dca878ad
# Parent  eca719b621a1201528bfec25fb1786ec21c0c9d3
Reflect cpupool in numa node affinity

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r eca719b621a1 -r cee17928d4ef xen/common/cpupool.c
--- a/xen/common/cpupool.c	Sun Jan 22 10:20:03 2012 +0000
+++ b/xen/common/cpupool.c	Mon Jan 23 10:45:01 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+    
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r eca719b621a1 -r cee17928d4ef xen/common/domain.c
--- a/xen/common/domain.c	Sun Jan 22 10:20:03 2012 +0000
+++ b/xen/common/domain.c	Mon Jan 23 10:45:01 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -365,15 +366,21 @@ void domain_update_node_affinity(struct 
 void domain_update_node_affinity(struct domain *d)
 {
     cpumask_t cpumask;
+    cpumask_t online_affinity;
+    cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
+    online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
     cpumask_clear(&cpumask);
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+    {
+        cpumask_and(&online_affinity, v->cpu_affinity, online);
+        cpumask_or(&cpumask, &cpumask, &online_affinity);
+    }
 
     for_each_online_node ( node )
         if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
diff -r eca719b621a1 -r cee17928d4ef xen/common/schedule.c
--- a/xen/common/schedule.c	Sun Jan 22 10:20:03 2012 +0000
+++ b/xen/common/schedule.c	Mon Jan 23 10:45:01 2012 +0100
@@ -282,11 +282,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -537,7 +538,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -545,8 +545,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -558,7 +556,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -582,8 +579,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;

--===============4197656787728731566==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4197656787728731566==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:57:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09:57:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpGe3-0004ms-D5; Mon, 23 Jan 2012 09:56:59 +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 1RpGe1-0004ml-S4
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:56:58 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327312611!2928503!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMzQzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8012 invoked from network); 23 Jan 2012 09:56:51 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 09:56: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:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=ukag/fioFCsFwFa5gwebECEPwkQiclbmGbb9QB4HWm13eQCzut8Y+AQB
	uf1UZhspWYobp7jER4hQcnIEtwfJHkIlCk0O3N18D+RlfhxVXyVc49VG+
	obRyAStzrCybcBaULGvvXl2E/1yTJy5hlEE+NS94ca0JtbrOEo3af2FVy
	HZPqDgm0WLw4rn/sDXpi6NjutHMlwc5+W1nnOroHa3BzsQygZe2LUibp5
	E/7ItMesYSi6iimDljGvuZwNntX5r;
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=1327312612; x=1358848612;
	h=mime-version:subject:message-id:date:from:to;
	bh=Lw4qpIfgOaMZyDxYDrrbrD4RuzZPcH0IJtw6EgTqh74=;
	b=nApmjsBHKZxpnwopyTQAG5Wq4Jp/o9HliplBqJg2zDy+X+cKKbfwfH01
	ej430jTJioiSft19AzyIF895il74WfuTaulwJW6IKkwoQbG6ZpJoKD/6w
	9VG+KjFhk2SLxhNcPHPiKuvDblTsm293cTMLGzAxTZIRWUCg3WkJza5AW
	+/vCbxape3tITaIHAlRK8bNRkl35SRzL3/l7sDi9e6PaDkgEi32Forb8C
	RDR5o+9z02qhZotb+pVdSrnGkVJ2K;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="99394088"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 23 Jan 2012 10:56:51 +0100
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="127565524"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 23 Jan 2012 10:56:51 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 44ABD960CFD;
	Mon, 23 Jan 2012 10:56:51 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============4197656787728731566=="
MIME-Version: 1.0
X-Mercurial-Node: cee17928d4eff5e7873f30276f424e16dca878ad
Message-Id: <cee17928d4eff5e7873f.1327312293@nehalem1>
Date: Mon, 23 Jan 2012 10:51:33 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4197656787728731566==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com


3 files changed, 20 insertions(+), 8 deletions(-)
xen/common/cpupool.c  |    9 +++++++++
xen/common/domain.c   |    9 ++++++++-
xen/common/schedule.c |   10 +++-------



--===============4197656787728731566==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327311901 -3600
# Node ID cee17928d4eff5e7873f30276f424e16dca878ad
# Parent  eca719b621a1201528bfec25fb1786ec21c0c9d3
Reflect cpupool in numa node affinity

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r eca719b621a1 -r cee17928d4ef xen/common/cpupool.c
--- a/xen/common/cpupool.c	Sun Jan 22 10:20:03 2012 +0000
+++ b/xen/common/cpupool.c	Mon Jan 23 10:45:01 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+    
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r eca719b621a1 -r cee17928d4ef xen/common/domain.c
--- a/xen/common/domain.c	Sun Jan 22 10:20:03 2012 +0000
+++ b/xen/common/domain.c	Mon Jan 23 10:45:01 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -365,15 +366,21 @@ void domain_update_node_affinity(struct 
 void domain_update_node_affinity(struct domain *d)
 {
     cpumask_t cpumask;
+    cpumask_t online_affinity;
+    cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
+    online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
     cpumask_clear(&cpumask);
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+    {
+        cpumask_and(&online_affinity, v->cpu_affinity, online);
+        cpumask_or(&cpumask, &cpumask, &online_affinity);
+    }
 
     for_each_online_node ( node )
         if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
diff -r eca719b621a1 -r cee17928d4ef xen/common/schedule.c
--- a/xen/common/schedule.c	Sun Jan 22 10:20:03 2012 +0000
+++ b/xen/common/schedule.c	Mon Jan 23 10:45:01 2012 +0100
@@ -282,11 +282,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -537,7 +538,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -545,8 +545,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -558,7 +556,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -582,8 +579,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;

--===============4197656787728731566==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4197656787728731566==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:58:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09: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 1RpGel-0004pd-Ra; Mon, 23 Jan 2012 09:57:43 +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 1RpGel-0004pB-4S
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:57:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327312657!11555361!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 20551 invoked from network); 23 Jan 2012 09:57:37 -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; 23 Jan 2012 09:57:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 09:57:45 +0000
Message-Id: <4F1D3D1D020000780006E514@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 09:57:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Marcus Granado" <marcus.granado@citrix.com>
References: <4F19B633.6090105@citrix.com>
In-Reply-To: <4F19B633.6090105@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
> xenoprof: Make the escape code consistent across 32 and 64-bit xen
> 
> At the moment, the xenoprof escape code is defined as "~0UL".
> Unfortunately, this expands to 0xffffffff on 32-bit systems
> and 0xffffffffffffffff on 64-bit systems; with the result that
> while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
> "compat mode") is broken.
> 
> This patch makes the definition consistent across architectures.
> In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
> but this was seen as an acceptable thing to do.
> 
> Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

NAK.

> diff -r 870db1ebc0df -r bcd2c4f0c502 xen/include/public/xenoprof.h
> --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
> +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
> @@ -68,7 +68,7 @@ struct event_log {
>   };
> 
>   /* PC value that indicates a special code */
> -#define XENOPROF_ESCAPE_CODE ~0UL
> +#define XENOPROF_ESCAPE_CODE (~0ULL)

You cannot just go and change a public definition, as the consuming
side will break. You need to introduce a new escape code, and
provide a mechanism to negotiate (between hypervisor and kernel)
which one to use.

I'd also be curious to see the kernel side change accompanying this
(if trivial, it might be a good idea to commit this to the old 2.6.18
tree for future reference).

Jan

>   /* Transient events for the xenoprof->oprofile cpu buf */
>   #define XENOPROF_TRACE_BEGIN 1




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 09:58:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 09: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 1RpGel-0004pd-Ra; Mon, 23 Jan 2012 09:57:43 +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 1RpGel-0004pB-4S
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:57:43 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327312657!11555361!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 20551 invoked from network); 23 Jan 2012 09:57:37 -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; 23 Jan 2012 09:57:37 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 09:57:45 +0000
Message-Id: <4F1D3D1D020000780006E514@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 09:57:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Marcus Granado" <marcus.granado@citrix.com>
References: <4F19B633.6090105@citrix.com>
In-Reply-To: <4F19B633.6090105@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
> xenoprof: Make the escape code consistent across 32 and 64-bit xen
> 
> At the moment, the xenoprof escape code is defined as "~0UL".
> Unfortunately, this expands to 0xffffffff on 32-bit systems
> and 0xffffffffffffffff on 64-bit systems; with the result that
> while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
> "compat mode") is broken.
> 
> This patch makes the definition consistent across architectures.
> In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
> but this was seen as an acceptable thing to do.
> 
> Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

NAK.

> diff -r 870db1ebc0df -r bcd2c4f0c502 xen/include/public/xenoprof.h
> --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
> +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
> @@ -68,7 +68,7 @@ struct event_log {
>   };
> 
>   /* PC value that indicates a special code */
> -#define XENOPROF_ESCAPE_CODE ~0UL
> +#define XENOPROF_ESCAPE_CODE (~0ULL)

You cannot just go and change a public definition, as the consuming
side will break. You need to introduce a new escape code, and
provide a mechanism to negotiate (between hypervisor and kernel)
which one to use.

I'd also be curious to see the kernel side change accompanying this
(if trivial, it might be a good idea to commit this to the old 2.6.18
tree for future reference).

Jan

>   /* Transient events for the xenoprof->oprofile cpu buf */
>   #define XENOPROF_TRACE_BEGIN 1




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:00:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10: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 1RpGgn-0004yZ-CK; Mon, 23 Jan 2012 09:59:49 +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 1RpGgl-0004yK-Ru
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:59:48 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327312781!10268071!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMzQzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32574 invoked from network); 23 Jan 2012 09:59:41 -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;
	23 Jan 2012 09:59:41 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=dIT1osvV0UhaUA36InNb2hCLygU3Fv/9i351Vkcm0Vy4oRCkmUeFHHkP
	oXVl4TVXSlaRKhi+D+HpsS8ajir6t3gDlt7gl/NydB7rrTpnWGM5vw0Qh
	QefAOb0dYz5z8dfkl3bHiAeGR9QqyesthhEnHzAt/8QW9SIVweBPmIVZj
	UBgIyHFPt269HuW4gssg90DtOLSyPmIv3V8gXjevWOMgraszx9Q5AJmZd
	AAKGjeanTuBB9dZelYAnknl7P3jZu;
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=1327312782; x=1358848782;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=7IGcrCigB1DbWHc9/wWy/bMdch7qMfKgtAEgqw12+fI=;
	b=uGPgbvp9Uku2Nzw39B19QIMrp//2L4on5cdiQRttlMwf0cnsBapnksUi
	vzb2xdk//hwueF93zU6qLMouNHywXaj2UUknj8BwgPzB9bgOY2Tq9pUWQ
	PAK2LpTACSz55Lx4PRiR7VeFo42bLHkpD9Z4p77vPsqhk7szwoSBRpWXn
	I2YnP0fcTC+1AMsUG68ZJp80jV7dcIgZlgdw1d/anggzYYgEvbqWldckH
	al/s9prYxlltbJTyH7a2cPdfPGvYB;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="99394709"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 23 Jan 2012 10:59:41 +0100
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="127239023"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 23 Jan 2012 10:59:41 +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 91CD8960CEA;
	Mon, 23 Jan 2012 10:59:40 +0100 (CET)
Message-ID: <4F1D2F8C.6040203@ts.fujitsu.com>
Date: Mon, 23 Jan 2012 10:59:40 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>	<20120119211430.GT12984@reaktio.net>	<1327046368.21391.29.camel@dagon.hellion.org.uk>	<20120120081529.GU12984@reaktio.net>
	<1327050108.17599.113.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327050108.17599.113.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?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

T24gMDEvMjAvMjAxMiAxMDowMSBBTSwgSWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIEZyaSwgMjAx
Mi0wMS0yMCBhdCAwODoxNSArMDAwMCwgUGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4+IE9uIEZy
aSwgSmFuIDIwLCAyMDEyIGF0IDA3OjU5OjI4QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToK
Pj4+IE9uIFRodSwgMjAxMi0wMS0xOSBhdCAyMToxNCArMDAwMCwgUGFzaSBLw6Rya2vDpGluZW4g
d3JvdGU6Cj4+Pj4gT24gV2VkLCBKYW4gMDQsIDIwMTIgYXQgMDQ6Mjk6MjJQTSArMDAwMCwgSWFu
IENhbXBiZWxsIHdyb3RlOgo+Pj4+PiBIYXMgYW55Ym9keSBnb3QgYW55dGhpbmcgZWxzZT8gSSdt
IHN1cmUgSSd2ZSBtaXNzZWQgc3R1ZmYuIEFyZSB0aGVyZSBhbnkKPj4+Pj4gbXVzdCBoYXZlcyBl
LmcuIGluIHRoZSBwYWdpbmcvc2hhcmluZyBzcGFjZXM/Cj4+Pj4+Cj4+Pj4gU29tZXRoaW5nIHRo
YXQgSSBqdXN0IHJlbWVtYmVyZWQ6Cj4+Pj4gaHR0cDovL3dpa2kueGVuLm9yZy94ZW53aWtpL1hl
bjQuMQo+Pj4+Cj4+Pj4gIk5VTUEtYXdhcmUgbWVtb3J5IGFsbG9jYXRpb24gZm9yIFZNcy4geGwg
aW4gWGVuIDQuMSB3aWxsIGFsbG9jYXRlCj4+Pj4gZXF1YWwgYW1vdW50IG9mIG1lbW9yeSBmcm9t
IGV2ZXJ5IE5VTUEgbm9kZSBmb3IgdGhlIFZNLiB4bS94ZW5kCj4+Pj4gYWxsb2NhdGVzIGFsbCB0
aGUgbWVtb3J5IGZyb20gdGhlIHNhbWUgTlVNQSBub2RlLiIKPj4+IEknbSBub3QgdGhhdCBmYW1p
bGlhciB3aXRoIHRoZSBOVU1BIHN1cHBvcnQgYnV0IG15IHVuZGVyc3RhbmRpbmcgd2FzCj4+PiB0
aGF0IG1lbW9yeSB3YXMgYWxsb2NhdGVkIGJ5IGxpYnhjL3RoZS1oeXBlcnZpc29yIGFuZCBub3Qg
YnkgdGhlCj4+PiB0b29sc3RhY2sgYW5kIHRoYXQgdGhlIGRlZmF1bHQgd2FzIHRvIGFsbG9jYXRl
IGZyb20gdGhlIHNhbWUgbnVtYSBub2Rlcwo+Pj4gYXMgZG9tYWlucyB0aGUgcHJvY2Vzc29yJ3Mg
d2VyZSBwaW5uZWQgdG8gaS5lLiBpZiB5b3UgcGluIHRoZSBwcm9jZXNzb3JzCj4+PiBhcHByb3By
aWF0ZWx5IHRoZSBSaWdodCBUaGluZyBqdXN0IGhhcHBlbnMuIERvIHlvdSBiZWxpZXZlIHRoaXMg
aXMgbm90Cj4+PiB0aGUgY2FzZSBhbmQvb3Igbm90IHdvcmtpbmcgcmlnaHQgd2l0aCB4bD8KPj4+
Cj4+PiBDQ2luZyBKdWVyZ2VuIHNpbmNlIGhlIGFkZGVkIHRoZSBjcHVwb29sIHN1cHBvcnQgYW5k
IGluIHBhcnRpY3VsYXIgdGhlCj4+PiBjcHVwb29sLW51bWEtc3BsaXQgb3B0aW9uIHNvIEknbSBo
b3BpbmcgaGUga25vd3Mgc29tZXRoaW5nIGFib3V0IE5VTUEKPj4+IG1vcmUgZ2VuZXJhbGx5Lgo+
Pj4KPj4+PiBJcyB0aGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBiZSBsb29rZWQgYXQ/Cj4+Pgo+
Pj4gUHJvYmFibHksIGJ1dCBpcyBhbnlvbmUgZG9pbmcgc28/Cj4+Pgo+Pj4+IFNob3VsZCB0aGUg
bnVtYSBtZW1vcnkgYWxsb2NhdGlvbiBiZSBhbiBvcHRpb24gc28gaXQgY2FuIGJlIGNvbnRyb2xs
ZWQKPj4+PiBwZXIgZG9tYWluPwo+Pj4gV2hhdCBvcHRpb25zIGRpZCB4bSBwcm92aWRlIGluIHRo
aXMgcmVnYXJkPwo+Pj4KPj4+IERvZXMgeGwncyBjcHVwb29sICh3aXRoIHRoZSBjcHVwb29sLW51
bWEtc3BsaXQgb3B0aW9uKSBzZXJ2ZXIgdGhlIHNhbWUKPj4+IHB1cnBvc2U/Cj4+Pgo+Pj4+IFRo
ZSBkZWZhdWx0IGxpYnhsIGJlaGF2aW91ciBtaWdodCBjYXVzZSB1bmV4cGVjdGVkIHBlcmZvcm1h
bmNlIGlzc3Vlcwo+Pj4+IG9uIG11bHRpLXNvY2tldCBzeXN0ZW1zPwo+Pj4gSSdtIG5vdCBjb252
aW5jZWQgbGlieGwgaXMgYmVoYXZpbmcgYW55IGRpZmZlcmVudCB0byB4ZW5kIGJ1dCBwZXJoYXBz
Cj4+PiBzb21lb25lIGNhbiBzaG93IG1lIHRoZSBlcnJvciBvZiBteSB3YXlzLgo+Pj4KPj4KPj4g
U2VlIHRoaXMgdGhyZWFkOgo+PiBodHRwOi8vb2xkLWxpc3QtYXJjaGl2ZXMueGVuLm9yZy9hcmNo
aXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTA3L21zZzAxNDIzLmh0bWwKPj4KPj4gd2hlcmUgU3Rl
ZmFubyB3cm90ZToKPj4gIkkgdGhpbmsgd2UgZm9yZ290IGFib3V0IHRoaXMgZmVhdHVyZSBidXQg
aXQgaXMgaW1wb3J0YW50IGFuZCBob3BlZnVsbHkKPj4gc29tZWJvZHkgd2lsbCB3cml0ZSBhIHBh
dGNoIGZvciBpdCBiZWZvcmUgNC4yIGlzIG91dC4iCj4gSXMgYW55b25lIGxvb2tpbmcgaW50byB0
aGlzPwo+Cj4gRG9lcyBjcHVwb29sLW51bWEtc3BsaXQgc29sdmUgdGhpcyBzYW1lIHByb2JsZW0/
Cj4KPiBJIHRoaW5rIEkgZm9yZ290IHRvIGFjdHVhbGx5IENDIEp1ZXJnZW4gd2hlbiBJIHNhaWQs
IGRvaW5nIHRoYXQgbm93LgoKSSd2ZSBqdXN0IHNlbnQgYSBwYXRjaCB3aGljaCBzaG91bGQgZG8g
dGhlIGpvYi4KSSBqdXN0IGhhdmUgbm8gTlVNQSBtYWNoaW5lIHRvIHRlc3QgaXQgb24sIEkganVz
dCB0ZXN0ZWQgdGhlIHBhdGNoCmRvZXNuJ3QgYnJlYWsgYm9vdGluZyBkb20wLi4uCgoKSnVlcmdl
bgoKLS0gCkp1ZXJnZW4gR3Jvc3MgICAgICAgICAgICAgICAgIFByaW5jaXBhbCBEZXZlbG9wZXIg
T3BlcmF0aW5nIFN5c3RlbXMKUERHIEVTJlMgU1dFIE9TNiAgICAgICAgICAgICAgICAgICAgICAg
VGVsZXBob25lOiArNDkgKDApIDg5IDMyMjIgMjk2NwpGdWppdHN1IFRlY2hub2xvZ3kgU29sdXRp
b25zICAgICAgICAgICAgICBlLW1haWw6IGp1ZXJnZW4uZ3Jvc3NAdHMuZnVqaXRzdS5jb20KRG9t
YWdrc3RyLiAyOCAgICAgICAgICAgICAgICAgICAgICAgICAgIEludGVybmV0OiB0cy5mdWppdHN1
LmNvbQpELTgwODA3IE11ZW5jaGVuICAgICAgICAgICAgICAgICBDb21wYW55IGRldGFpbHM6IHRz
LmZ1aml0c3UuY29tL2ltcHJpbnQuaHRtbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:00:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10: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 1RpGgn-0004yZ-CK; Mon, 23 Jan 2012 09:59:49 +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 1RpGgl-0004yK-Ru
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 09:59:48 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327312781!10268071!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMzQzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32574 invoked from network); 23 Jan 2012 09:59:41 -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;
	23 Jan 2012 09:59:41 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=dIT1osvV0UhaUA36InNb2hCLygU3Fv/9i351Vkcm0Vy4oRCkmUeFHHkP
	oXVl4TVXSlaRKhi+D+HpsS8ajir6t3gDlt7gl/NydB7rrTpnWGM5vw0Qh
	QefAOb0dYz5z8dfkl3bHiAeGR9QqyesthhEnHzAt/8QW9SIVweBPmIVZj
	UBgIyHFPt269HuW4gssg90DtOLSyPmIv3V8gXjevWOMgraszx9Q5AJmZd
	AAKGjeanTuBB9dZelYAnknl7P3jZu;
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=1327312782; x=1358848782;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=7IGcrCigB1DbWHc9/wWy/bMdch7qMfKgtAEgqw12+fI=;
	b=uGPgbvp9Uku2Nzw39B19QIMrp//2L4on5cdiQRttlMwf0cnsBapnksUi
	vzb2xdk//hwueF93zU6qLMouNHywXaj2UUknj8BwgPzB9bgOY2Tq9pUWQ
	PAK2LpTACSz55Lx4PRiR7VeFo42bLHkpD9Z4p77vPsqhk7szwoSBRpWXn
	I2YnP0fcTC+1AMsUG68ZJp80jV7dcIgZlgdw1d/anggzYYgEvbqWldckH
	al/s9prYxlltbJTyH7a2cPdfPGvYB;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="99394709"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 23 Jan 2012 10:59:41 +0100
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="127239023"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 23 Jan 2012 10:59:41 +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 91CD8960CEA;
	Mon, 23 Jan 2012 10:59:40 +0100 (CET)
Message-ID: <4F1D2F8C.6040203@ts.fujitsu.com>
Date: Mon, 23 Jan 2012 10:59:40 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>	<20120119211430.GT12984@reaktio.net>	<1327046368.21391.29.camel@dagon.hellion.org.uk>	<20120120081529.GU12984@reaktio.net>
	<1327050108.17599.113.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327050108.17599.113.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?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

T24gMDEvMjAvMjAxMiAxMDowMSBBTSwgSWFuIENhbXBiZWxsIHdyb3RlOgo+IE9uIEZyaSwgMjAx
Mi0wMS0yMCBhdCAwODoxNSArMDAwMCwgUGFzaSBLw6Rya2vDpGluZW4gd3JvdGU6Cj4+IE9uIEZy
aSwgSmFuIDIwLCAyMDEyIGF0IDA3OjU5OjI4QU0gKzAwMDAsIElhbiBDYW1wYmVsbCB3cm90ZToK
Pj4+IE9uIFRodSwgMjAxMi0wMS0xOSBhdCAyMToxNCArMDAwMCwgUGFzaSBLw6Rya2vDpGluZW4g
d3JvdGU6Cj4+Pj4gT24gV2VkLCBKYW4gMDQsIDIwMTIgYXQgMDQ6Mjk6MjJQTSArMDAwMCwgSWFu
IENhbXBiZWxsIHdyb3RlOgo+Pj4+PiBIYXMgYW55Ym9keSBnb3QgYW55dGhpbmcgZWxzZT8gSSdt
IHN1cmUgSSd2ZSBtaXNzZWQgc3R1ZmYuIEFyZSB0aGVyZSBhbnkKPj4+Pj4gbXVzdCBoYXZlcyBl
LmcuIGluIHRoZSBwYWdpbmcvc2hhcmluZyBzcGFjZXM/Cj4+Pj4+Cj4+Pj4gU29tZXRoaW5nIHRo
YXQgSSBqdXN0IHJlbWVtYmVyZWQ6Cj4+Pj4gaHR0cDovL3dpa2kueGVuLm9yZy94ZW53aWtpL1hl
bjQuMQo+Pj4+Cj4+Pj4gIk5VTUEtYXdhcmUgbWVtb3J5IGFsbG9jYXRpb24gZm9yIFZNcy4geGwg
aW4gWGVuIDQuMSB3aWxsIGFsbG9jYXRlCj4+Pj4gZXF1YWwgYW1vdW50IG9mIG1lbW9yeSBmcm9t
IGV2ZXJ5IE5VTUEgbm9kZSBmb3IgdGhlIFZNLiB4bS94ZW5kCj4+Pj4gYWxsb2NhdGVzIGFsbCB0
aGUgbWVtb3J5IGZyb20gdGhlIHNhbWUgTlVNQSBub2RlLiIKPj4+IEknbSBub3QgdGhhdCBmYW1p
bGlhciB3aXRoIHRoZSBOVU1BIHN1cHBvcnQgYnV0IG15IHVuZGVyc3RhbmRpbmcgd2FzCj4+PiB0
aGF0IG1lbW9yeSB3YXMgYWxsb2NhdGVkIGJ5IGxpYnhjL3RoZS1oeXBlcnZpc29yIGFuZCBub3Qg
YnkgdGhlCj4+PiB0b29sc3RhY2sgYW5kIHRoYXQgdGhlIGRlZmF1bHQgd2FzIHRvIGFsbG9jYXRl
IGZyb20gdGhlIHNhbWUgbnVtYSBub2Rlcwo+Pj4gYXMgZG9tYWlucyB0aGUgcHJvY2Vzc29yJ3Mg
d2VyZSBwaW5uZWQgdG8gaS5lLiBpZiB5b3UgcGluIHRoZSBwcm9jZXNzb3JzCj4+PiBhcHByb3By
aWF0ZWx5IHRoZSBSaWdodCBUaGluZyBqdXN0IGhhcHBlbnMuIERvIHlvdSBiZWxpZXZlIHRoaXMg
aXMgbm90Cj4+PiB0aGUgY2FzZSBhbmQvb3Igbm90IHdvcmtpbmcgcmlnaHQgd2l0aCB4bD8KPj4+
Cj4+PiBDQ2luZyBKdWVyZ2VuIHNpbmNlIGhlIGFkZGVkIHRoZSBjcHVwb29sIHN1cHBvcnQgYW5k
IGluIHBhcnRpY3VsYXIgdGhlCj4+PiBjcHVwb29sLW51bWEtc3BsaXQgb3B0aW9uIHNvIEknbSBo
b3BpbmcgaGUga25vd3Mgc29tZXRoaW5nIGFib3V0IE5VTUEKPj4+IG1vcmUgZ2VuZXJhbGx5Lgo+
Pj4KPj4+PiBJcyB0aGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBiZSBsb29rZWQgYXQ/Cj4+Pgo+
Pj4gUHJvYmFibHksIGJ1dCBpcyBhbnlvbmUgZG9pbmcgc28/Cj4+Pgo+Pj4+IFNob3VsZCB0aGUg
bnVtYSBtZW1vcnkgYWxsb2NhdGlvbiBiZSBhbiBvcHRpb24gc28gaXQgY2FuIGJlIGNvbnRyb2xs
ZWQKPj4+PiBwZXIgZG9tYWluPwo+Pj4gV2hhdCBvcHRpb25zIGRpZCB4bSBwcm92aWRlIGluIHRo
aXMgcmVnYXJkPwo+Pj4KPj4+IERvZXMgeGwncyBjcHVwb29sICh3aXRoIHRoZSBjcHVwb29sLW51
bWEtc3BsaXQgb3B0aW9uKSBzZXJ2ZXIgdGhlIHNhbWUKPj4+IHB1cnBvc2U/Cj4+Pgo+Pj4+IFRo
ZSBkZWZhdWx0IGxpYnhsIGJlaGF2aW91ciBtaWdodCBjYXVzZSB1bmV4cGVjdGVkIHBlcmZvcm1h
bmNlIGlzc3Vlcwo+Pj4+IG9uIG11bHRpLXNvY2tldCBzeXN0ZW1zPwo+Pj4gSSdtIG5vdCBjb252
aW5jZWQgbGlieGwgaXMgYmVoYXZpbmcgYW55IGRpZmZlcmVudCB0byB4ZW5kIGJ1dCBwZXJoYXBz
Cj4+PiBzb21lb25lIGNhbiBzaG93IG1lIHRoZSBlcnJvciBvZiBteSB3YXlzLgo+Pj4KPj4KPj4g
U2VlIHRoaXMgdGhyZWFkOgo+PiBodHRwOi8vb2xkLWxpc3QtYXJjaGl2ZXMueGVuLm9yZy9hcmNo
aXZlcy9odG1sL3hlbi1kZXZlbC8yMDExLTA3L21zZzAxNDIzLmh0bWwKPj4KPj4gd2hlcmUgU3Rl
ZmFubyB3cm90ZToKPj4gIkkgdGhpbmsgd2UgZm9yZ290IGFib3V0IHRoaXMgZmVhdHVyZSBidXQg
aXQgaXMgaW1wb3J0YW50IGFuZCBob3BlZnVsbHkKPj4gc29tZWJvZHkgd2lsbCB3cml0ZSBhIHBh
dGNoIGZvciBpdCBiZWZvcmUgNC4yIGlzIG91dC4iCj4gSXMgYW55b25lIGxvb2tpbmcgaW50byB0
aGlzPwo+Cj4gRG9lcyBjcHVwb29sLW51bWEtc3BsaXQgc29sdmUgdGhpcyBzYW1lIHByb2JsZW0/
Cj4KPiBJIHRoaW5rIEkgZm9yZ290IHRvIGFjdHVhbGx5IENDIEp1ZXJnZW4gd2hlbiBJIHNhaWQs
IGRvaW5nIHRoYXQgbm93LgoKSSd2ZSBqdXN0IHNlbnQgYSBwYXRjaCB3aGljaCBzaG91bGQgZG8g
dGhlIGpvYi4KSSBqdXN0IGhhdmUgbm8gTlVNQSBtYWNoaW5lIHRvIHRlc3QgaXQgb24sIEkganVz
dCB0ZXN0ZWQgdGhlIHBhdGNoCmRvZXNuJ3QgYnJlYWsgYm9vdGluZyBkb20wLi4uCgoKSnVlcmdl
bgoKLS0gCkp1ZXJnZW4gR3Jvc3MgICAgICAgICAgICAgICAgIFByaW5jaXBhbCBEZXZlbG9wZXIg
T3BlcmF0aW5nIFN5c3RlbXMKUERHIEVTJlMgU1dFIE9TNiAgICAgICAgICAgICAgICAgICAgICAg
VGVsZXBob25lOiArNDkgKDApIDg5IDMyMjIgMjk2NwpGdWppdHN1IFRlY2hub2xvZ3kgU29sdXRp
b25zICAgICAgICAgICAgICBlLW1haWw6IGp1ZXJnZW4uZ3Jvc3NAdHMuZnVqaXRzdS5jb20KRG9t
YWdrc3RyLiAyOCAgICAgICAgICAgICAgICAgICAgICAgICAgIEludGVybmV0OiB0cy5mdWppdHN1
LmNvbQpELTgwODA3IE11ZW5jaGVuICAgICAgICAgICAgICAgICBDb21wYW55IGRldGFpbHM6IHRz
LmZ1aml0c3UuY29tL2ltcHJpbnQuaHRtbAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3Rz
LnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:16:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10: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 1RpGwt-0005Ke-A0; Mon, 23 Jan 2012 10:16: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 1RpGwr-0005KS-8u
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:16:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327313779!9817972!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14191 invoked from network); 23 Jan 2012 10:16:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 10:16:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10206519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:16: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;
	Mon, 23 Jan 2012 10:16:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 23 Jan 2012 10:16:17 +0000
In-Reply-To: <4F1D3D1D020000780006E514@nat28.tlf.novell.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327313777.24561.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
> > xenoprof: Make the escape code consistent across 32 and 64-bit xen
> > 
> > At the moment, the xenoprof escape code is defined as "~0UL".
> > Unfortunately, this expands to 0xffffffff on 32-bit systems
> > and 0xffffffffffffffff on 64-bit systems; with the result that
> > while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
> > "compat mode") is broken.
> > 
> > This patch makes the definition consistent across architectures.
> > In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
> > but this was seen as an acceptable thing to do.
> > 
> > Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> NAK.
> 
> > diff -r 870db1ebc0df -r bcd2c4f0c502 xen/include/public/xenoprof.h
> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
> > @@ -68,7 +68,7 @@ struct event_log {
> >   };
> > 
> >   /* PC value that indicates a special code */
> > -#define XENOPROF_ESCAPE_CODE ~0UL
> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
> 
> You cannot just go and change a public definition, as the consuming
> side will break. You need to introduce a new escape code, and
> provide a mechanism to negotiate (between hypervisor and kernel)
> which one to use.

This seems more like a bug fix to me than an interface change, the fact
that both producer and consumer had the bug notwithstanding.

Since this is a developer oriented interface I think we can be a little
more relaxed than we would be for other interface changes. In this case
we are fixing 32on64 (quite common) at the expense of 32on32 (very
uncommon these days, especially for the suybset of developers wanting to
do profiling) and leaving 64on64 (quite common) as it is . That seems
like a worthwhile tradeoff to me.


Ian.

> I'd also be curious to see the kernel side change accompanying this
> (if trivial, it might be a good idea to commit this to the old 2.6.18
> tree for future reference).
> 
> Jan
> 
> >   /* Transient events for the xenoprof->oprofile cpu buf */
> >   #define XENOPROF_TRACE_BEGIN 1
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:16:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10: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 1RpGwt-0005Ke-A0; Mon, 23 Jan 2012 10:16: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 1RpGwr-0005KS-8u
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:16:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327313779!9817972!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14191 invoked from network); 23 Jan 2012 10:16:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 10:16:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10206519"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:16: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;
	Mon, 23 Jan 2012 10:16:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Mon, 23 Jan 2012 10:16:17 +0000
In-Reply-To: <4F1D3D1D020000780006E514@nat28.tlf.novell.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327313777.24561.9.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
> > xenoprof: Make the escape code consistent across 32 and 64-bit xen
> > 
> > At the moment, the xenoprof escape code is defined as "~0UL".
> > Unfortunately, this expands to 0xffffffff on 32-bit systems
> > and 0xffffffffffffffff on 64-bit systems; with the result that
> > while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
> > "compat mode") is broken.
> > 
> > This patch makes the definition consistent across architectures.
> > In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
> > but this was seen as an acceptable thing to do.
> > 
> > Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
> > Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
> 
> NAK.
> 
> > diff -r 870db1ebc0df -r bcd2c4f0c502 xen/include/public/xenoprof.h
> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
> > @@ -68,7 +68,7 @@ struct event_log {
> >   };
> > 
> >   /* PC value that indicates a special code */
> > -#define XENOPROF_ESCAPE_CODE ~0UL
> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
> 
> You cannot just go and change a public definition, as the consuming
> side will break. You need to introduce a new escape code, and
> provide a mechanism to negotiate (between hypervisor and kernel)
> which one to use.

This seems more like a bug fix to me than an interface change, the fact
that both producer and consumer had the bug notwithstanding.

Since this is a developer oriented interface I think we can be a little
more relaxed than we would be for other interface changes. In this case
we are fixing 32on64 (quite common) at the expense of 32on32 (very
uncommon these days, especially for the suybset of developers wanting to
do profiling) and leaving 64on64 (quite common) as it is . That seems
like a worthwhile tradeoff to me.


Ian.

> I'd also be curious to see the kernel side change accompanying this
> (if trivial, it might be a good idea to commit this to the old 2.6.18
> tree for future reference).
> 
> Jan
> 
> >   /* Transient events for the xenoprof->oprofile cpu buf */
> >   #define XENOPROF_TRACE_BEGIN 1
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:20:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:20:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpH0N-0005Rs-V5; Mon, 23 Jan 2012 10:20: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 1RpH0M-0005Ri-FK
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:20:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327313996!11559525!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31868 invoked from network); 23 Jan 2012 10:19:56 -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;
	23 Jan 2012 10:19:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10206971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:19:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 10:19:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Mon, 23 Jan 2012 10:19:55 +0000
In-Reply-To: <1327080768.2337.65.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078460.30054.74.camel@zakaz.uk.xensource.com>
	<1327080768.2337.65.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327313995.24561.13.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 17:32 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 16:54 +0000, Ian Campbell wrote: 
> > I confused myself into thinking that cpupools ~= NUMA because I've only
> > used cpupool-numa-split but I can see that you might also divide your
> > cpus up some other way.
> > 
> Yeah, indeed, although the numa-split case looks like the most useful
> one to me.
> 
> > Should that same union be used for d->node_affinity though? It seems
> > like it would make sense.
> > 
> According to me, it should.

I agree.

One idea I had over the weekend is that we could support a special
'cpus="pool"' syntax to mean "pin this guest to the node I configured it
to be in". I think this is a second best option to simply having
d->node_affinity reflect the pool though.

>  Then, at least right now, moving it would
> probably kill its performances because all its memory will be far away,
> while right now it's all more "stochastic".

Yes, in some sense the xend behaviour is best case good behaviour and
worse case bad behaviour, while xl has a more average/consistent
behaviour across the range. In practice however I suspect xend probably
hits the good cases more often than not.

> Still, I think it should be done, as if you place a domain in a cpupool
> at its creation, I think the case of moving it away from there would be
> quite rare.

Agreed.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:20:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:20:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpH0N-0005Rs-V5; Mon, 23 Jan 2012 10:20: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 1RpH0M-0005Ri-FK
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:20:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327313996!11559525!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31868 invoked from network); 23 Jan 2012 10:19:56 -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;
	23 Jan 2012 10:19:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10206971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:19:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 10:19:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Mon, 23 Jan 2012 10:19:55 +0000
In-Reply-To: <1327080768.2337.65.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078460.30054.74.camel@zakaz.uk.xensource.com>
	<1327080768.2337.65.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327313995.24561.13.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 17:32 +0000, Dario Faggioli wrote:
> On Fri, 2012-01-20 at 16:54 +0000, Ian Campbell wrote: 
> > I confused myself into thinking that cpupools ~= NUMA because I've only
> > used cpupool-numa-split but I can see that you might also divide your
> > cpus up some other way.
> > 
> Yeah, indeed, although the numa-split case looks like the most useful
> one to me.
> 
> > Should that same union be used for d->node_affinity though? It seems
> > like it would make sense.
> > 
> According to me, it should.

I agree.

One idea I had over the weekend is that we could support a special
'cpus="pool"' syntax to mean "pin this guest to the node I configured it
to be in". I think this is a second best option to simply having
d->node_affinity reflect the pool though.

>  Then, at least right now, moving it would
> probably kill its performances because all its memory will be far away,
> while right now it's all more "stochastic".

Yes, in some sense the xend behaviour is best case good behaviour and
worse case bad behaviour, while xl has a more average/consistent
behaviour across the range. In practice however I suspect xend probably
hits the good cases more often than not.

> Still, I think it should be done, as if you place a domain in a cpupool
> at its creation, I think the case of moving it away from there would be
> quite rare.

Agreed.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:21:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 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 1RpH1v-0005aY-Kg; Mon, 23 Jan 2012 10:21:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpH1u-0005aI-F8
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:21:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327314092!11559795!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9657 invoked from network); 23 Jan 2012 10:21:32 -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;
	23 Jan 2012 10:21:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10207056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:21: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, 23 Jan 2012 10:21:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 23 Jan 2012 10:21:32 +0000
In-Reply-To: <20240.24689.833215.133892@mariner.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss>	<1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.com>
	<1326473132.2397.6.camel@Abyss.citrite.net>
	<20240.24689.833215.133892@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327314092.24561.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 16:48 +0000, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for vcpu-pin."):
> > Ok, I'm not really a "string parsing guy" but I'm interested in getting
> > better. I can try restructuring this with strtok_r and strdup... Would
> > that be better or you where thinking to something more "radical"?
> 
> Personally I'm a fan of flex although it's probably overkill for
> this.  But you should use an approach your comfortable with.
> 
> What I care most about is that whatever approach you take doesn't make
> it too easy to make and hide :-) programming mistakes, since otherwise
> parsing code often turns out to be buggy.

Can we take the version which just moves the dodgy parsee now and worry
about reworking it later? I think we'd like to see vcpu pinning in 4.2.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:21:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 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 1RpH1v-0005aY-Kg; Mon, 23 Jan 2012 10:21:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpH1u-0005aI-F8
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:21:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327314092!11559795!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9657 invoked from network); 23 Jan 2012 10:21:32 -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;
	23 Jan 2012 10:21:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10207056"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:21: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, 23 Jan 2012 10:21:32 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 23 Jan 2012 10:21:32 +0000
In-Reply-To: <20240.24689.833215.133892@mariner.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss>	<1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.com>
	<1326473132.2397.6.camel@Abyss.citrite.net>
	<20240.24689.833215.133892@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327314092.24561.14.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Dario Faggioli <raistlin@linux.it>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-13 at 16:48 +0000, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification for vcpu-pin."):
> > Ok, I'm not really a "string parsing guy" but I'm interested in getting
> > better. I can try restructuring this with strtok_r and strdup... Would
> > that be better or you where thinking to something more "radical"?
> 
> Personally I'm a fan of flex although it's probably overkill for
> this.  But you should use an approach your comfortable with.
> 
> What I care most about is that whatever approach you take doesn't make
> it too easy to make and hide :-) programming mistakes, since otherwise
> parsing code often turns out to be buggy.

Can we take the version which just moves the dodgy parsee now and worry
about reworking it later? I think we'd like to see vcpu pinning in 4.2.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:27:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpH7L-0005wR-EB; Mon, 23 Jan 2012 10: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 1RpH7K-0005vx-NW
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:27:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327314427!11924348!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 32225 invoked from network); 23 Jan 2012 10:27:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 10:27:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 10:28:02 +0000
Message-Id: <4F1D4409020000780006E545@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 10:27:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <cee17928d4eff5e7873f.1327312293@nehalem1>
In-Reply-To: <cee17928d4eff5e7873f.1327312293@nehalem1>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 10:51, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
@@ -365,15 +366,21 @@ void domain_update_node_affinity(struct 
> void domain_update_node_affinity(struct domain *d)
> {
>     cpumask_t cpumask;
>+    cpumask_t online_affinity;

If at all possible, please don't introduce new automatic cpumask_t
variables. Allocating them will of course mean that the function can
fail, and that callers need to deal with the failure. (Probably a prior
patch should then first convert the 'cpumask' variable.)

>+    cpumask_t *online;

const.

>     nodemask_t nodemask = NODE_MASK_NONE;
>     struct vcpu *v;
>     unsigned int node;
> 
>+    online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;

This construct (together with its brother using 'cpupool_free_cpus')
meanwhile enjoys quite a number of instances - could it get abstracted
into a pair of inline functions or macros?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:27:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:27:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpH7L-0005wR-EB; Mon, 23 Jan 2012 10: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 1RpH7K-0005vx-NW
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:27:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327314427!11924348!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 32225 invoked from network); 23 Jan 2012 10:27:07 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 10:27:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 10:28:02 +0000
Message-Id: <4F1D4409020000780006E545@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 10:27:05 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <cee17928d4eff5e7873f.1327312293@nehalem1>
In-Reply-To: <cee17928d4eff5e7873f.1327312293@nehalem1>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 10:51, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
@@ -365,15 +366,21 @@ void domain_update_node_affinity(struct 
> void domain_update_node_affinity(struct domain *d)
> {
>     cpumask_t cpumask;
>+    cpumask_t online_affinity;

If at all possible, please don't introduce new automatic cpumask_t
variables. Allocating them will of course mean that the function can
fail, and that callers need to deal with the failure. (Probably a prior
patch should then first convert the 'cpumask' variable.)

>+    cpumask_t *online;

const.

>     nodemask_t nodemask = NODE_MASK_NONE;
>     struct vcpu *v;
>     unsigned int node;
> 
>+    online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;

This construct (together with its brother using 'cpupool_free_cpus')
meanwhile enjoys quite a number of instances - could it get abstracted
into a pair of inline functions or macros?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:28:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:28:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpH8B-00061Y-T6; Mon, 23 Jan 2012 10:28:07 +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 1RpH8A-00060y-LT
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:28:06 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327314480!11990896!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 27439 invoked from network); 23 Jan 2012 10:28:00 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Jan 2012 10:28:00 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74944550; Mon, 23 Jan 2012 11:27:59 +0100
Message-ID: <1327314471.2476.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 23 Jan 2012 11:27:51 +0100
In-Reply-To: <1327314092.24561.14.camel@zakaz.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss>	<1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.com>
	<1326473132.2397.6.camel@Abyss.citrite.net>
	<20240.24689.833215.133892@mariner.uk.xensource.com>
	<1327314092.24561.14.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0200532969343501456=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0200532969343501456==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-2dnSVVQCfI6rntaaeXCI"


--=-2dnSVVQCfI6rntaaeXCI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-01-23 at 10:21 +0000, Ian Campbell wrote:=20
> Can we take the version which just moves the dodgy parsee now and worry
> about reworking it later? I think we'd like to see vcpu pinning in 4.2.
>=20
Hey, sorry for being so late in resubmitting, I've been distrcted by
those (other) NUME issues... I'll send a new version of this in the
afternoon!

Sorry again,
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)



--=-2dnSVVQCfI6rntaaeXCI
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)

iEYEABECAAYFAk8dNicACgkQk4XaBE3IOsRFIQCgqz/zhJ1z5SQplXKSHlQLCESK
WwsAoIqMYnAkw++2IjcPpke45A47WxWA
=ufO6
-----END PGP SIGNATURE-----

--=-2dnSVVQCfI6rntaaeXCI--



--===============0200532969343501456==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0200532969343501456==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:28:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:28:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpH8B-00061Y-T6; Mon, 23 Jan 2012 10:28:07 +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 1RpH8A-00060y-LT
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:28:06 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327314480!11990896!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 27439 invoked from network); 23 Jan 2012 10:28:00 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Jan 2012 10:28:00 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74944550; Mon, 23 Jan 2012 11:27:59 +0100
Message-ID: <1327314471.2476.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 23 Jan 2012 11:27:51 +0100
In-Reply-To: <1327314092.24561.14.camel@zakaz.uk.xensource.com>
References: <1326304198.2401.6.camel@Abyss>	<1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.com>
	<1326473132.2397.6.camel@Abyss.citrite.net>
	<20240.24689.833215.133892@mariner.uk.xensource.com>
	<1327314092.24561.14.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0200532969343501456=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0200532969343501456==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-2dnSVVQCfI6rntaaeXCI"


--=-2dnSVVQCfI6rntaaeXCI
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-01-23 at 10:21 +0000, Ian Campbell wrote:=20
> Can we take the version which just moves the dodgy parsee now and worry
> about reworking it later? I think we'd like to see vcpu pinning in 4.2.
>=20
Hey, sorry for being so late in resubmitting, I've been distrcted by
those (other) NUME issues... I'll send a new version of this in the
afternoon!

Sorry again,
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)



--=-2dnSVVQCfI6rntaaeXCI
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)

iEYEABECAAYFAk8dNicACgkQk4XaBE3IOsRFIQCgqz/zhJ1z5SQplXKSHlQLCESK
WwsAoIqMYnAkw++2IjcPpke45A47WxWA
=ufO6
-----END PGP SIGNATURE-----

--=-2dnSVVQCfI6rntaaeXCI--



--===============0200532969343501456==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0200532969343501456==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:33:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHDI-0006OB-Mf; Mon, 23 Jan 2012 10:33: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 1RpHDH-0006Ny-42
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:33:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327314754!49683162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18635 invoked from network); 23 Jan 2012 10:32:35 -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;
	23 Jan 2012 10:32:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10207718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:33:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 10:33:21 +0000
Date: Mon, 23 Jan 2012 10:33:37 +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: <1327092461-2701-15-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201231022020.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-15-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/21] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> option for compiling xenstored without unix sockets to support running on mini-OS

The amount of ifdef's introduced by this patch is not ideal.

Do you think is possible to refactor the code to use structures with
function pointers, with a registration mechanism, so that in the dom0
case you would end up with two structs (one for each kind of
connections), while you would have only one on mini-OS?

We could have an initialize, a destroy and an accept_connection
functions.


> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/xenstore/xenstored_core.c |   22 +++++++++++++++++++++-
>  tools/xenstore/xs.c             |    2 ++
>  tools/xenstore/xs_lib.c         |    4 ++++
>  3 files changed, 27 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 9e6c2c7..631bfe4 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -19,9 +19,11 @@
>  
>  #include <sys/types.h>
>  #include <sys/stat.h>
> -#include <sys/socket.h>
>  #include <sys/select.h>
> +#ifndef NO_SOCKETS
> +#include <sys/socket.h>
>  #include <sys/un.h>
> +#endif
>  #include <sys/time.h>
>  #include <time.h>
>  #include <unistd.h>
> @@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	FD_ZERO(inset);
>  	FD_ZERO(outset);
>  
> +#ifndef NO_SOCKETS
>  	set_fd(sock,               inset, &max);
>  	set_fd(ro_sock,            inset, &max);
> +#endif
>  	set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
> @@ -343,12 +347,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	return max;
>  }
>  
> +#ifndef NO_SOCKETS
>  static int destroy_fd(void *_fd)
>  {
>  	int *fd = _fd;
>  	close(*fd);
>  	return 0;
>  }
> +#endif
>  
>  /* Is child a subnode of parent, or equal? */
>  bool is_child(const char *child, const char *parent)
> @@ -1352,6 +1358,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
>  	return new;
>  }
>  
> +#ifndef NO_SOCKETS
>  static int writefd(struct connection *conn, const void *data, unsigned int len)
>  {
>  	int rc;
> @@ -1406,6 +1413,7 @@ static void accept_connection(int sock, bool canwrite)
>  	} else
>  		close(fd);
>  }
> +#endif
>  
>  #define TDB_FLAGS 0
>  
> @@ -1753,7 +1761,11 @@ extern void dump_conn(struct connection *conn);
>  int main(int argc, char *argv[])
>  {
>  	int opt, *sock, *ro_sock, max;
> +#ifdef NO_SOCKETS
> +	int minus_one = -1;
> +#else
>  	struct sockaddr_un addr;
> +#endif
>  	fd_set inset, outset;
>  	bool dofork = true;
>  	bool outputpid = false;
> @@ -1837,6 +1849,9 @@ int main(int argc, char *argv[])
>  	if (!dofork)
>  		talloc_enable_leak_report_full();
>  
> +#ifdef NO_SOCKETS
> +	sock = ro_sock = &minus_one;
> +#else
>  	/* Create sockets for them to listen to. */
>  	sock = talloc(talloc_autofree_context(), int);
>  	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
> @@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
>  		barf_perror("Could not create socket");
>  	talloc_set_destructor(sock, destroy_fd);
>  	talloc_set_destructor(ro_sock, destroy_fd);
> +#endif
>  
>  	/* Don't kill us with SIGPIPE. */
>  	signal(SIGPIPE, SIG_IGN);
>  
> +#ifndef NO_SOCKETS
>  	/* FIXME: Be more sophisticated, don't mug running daemon. */
>  	unlink(xs_daemon_socket());
>  	unlink(xs_daemon_socket_ro());
> @@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
>  	if (listen(*sock, 1) != 0
>  	    || listen(*ro_sock, 1) != 0)
>  		barf_perror("Could not listen on sockets");
> +#endif
>  
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
> @@ -1931,11 +1949,13 @@ int main(int argc, char *argv[])
>  			reopen_log();
>  		}
>  
> +#ifndef NO_SOCKETS
>  		if (FD_ISSET(*sock, &inset))
>  			accept_connection(*sock, true);
>  
>  		if (FD_ISSET(*ro_sock, &inset))
>  			accept_connection(*ro_sock, false);
> +#endif
>  
>  		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
>  			handle_event();
> diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> index 0a01675..60f2cee 100644
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
>  {
>  	struct xs_handle *xsh = NULL;
>  
> +#ifndef NO_SOCKETS
>  	if (flags & XS_OPEN_READONLY)
>  		xsh = get_handle(xs_daemon_socket_ro());
>  	else
>  		xsh = get_handle(xs_daemon_socket());
> +#endif
>  
>  	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
>  		xsh = get_handle(xs_domain_dev());
> diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
> index 03a9ee4..af3db6b 100644
> --- a/tools/xenstore/xs_lib.c
> +++ b/tools/xenstore/xs_lib.c
> @@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
>  	return (s ? s : "/var/run/xenstored");
>  }
>  
> +#ifndef NO_SOCKETS
>  static const char *xs_daemon_path(void)
>  {
>  	static char buf[PATH_MAX];
> @@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
>  		return NULL;
>  	return buf;
>  }
> +#endif
>  
>  const char *xs_daemon_tdb(void)
>  {
> @@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
>  	return buf;
>  }
>  
> +#ifndef NO_SOCKETS
>  const char *xs_daemon_socket(void)
>  {
>  	return xs_daemon_path();
> @@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
>  		return NULL;
>  	return buf;
>  }
> +#endif
>  
>  const char *xs_domain_dev(void)
>  {
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:33:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHDI-0006OB-Mf; Mon, 23 Jan 2012 10:33: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 1RpHDH-0006Ny-42
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:33:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327314754!49683162!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18635 invoked from network); 23 Jan 2012 10:32:35 -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;
	23 Jan 2012 10:32:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10207718"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:33:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 10:33:21 +0000
Date: Mon, 23 Jan 2012 10:33:37 +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: <1327092461-2701-15-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201231022020.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-15-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/21] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> option for compiling xenstored without unix sockets to support running on mini-OS

The amount of ifdef's introduced by this patch is not ideal.

Do you think is possible to refactor the code to use structures with
function pointers, with a registration mechanism, so that in the dom0
case you would end up with two structs (one for each kind of
connections), while you would have only one on mini-OS?

We could have an initialize, a destroy and an accept_connection
functions.


> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/xenstore/xenstored_core.c |   22 +++++++++++++++++++++-
>  tools/xenstore/xs.c             |    2 ++
>  tools/xenstore/xs_lib.c         |    4 ++++
>  3 files changed, 27 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 9e6c2c7..631bfe4 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -19,9 +19,11 @@
>  
>  #include <sys/types.h>
>  #include <sys/stat.h>
> -#include <sys/socket.h>
>  #include <sys/select.h>
> +#ifndef NO_SOCKETS
> +#include <sys/socket.h>
>  #include <sys/un.h>
> +#endif
>  #include <sys/time.h>
>  #include <time.h>
>  #include <unistd.h>
> @@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	FD_ZERO(inset);
>  	FD_ZERO(outset);
>  
> +#ifndef NO_SOCKETS
>  	set_fd(sock,               inset, &max);
>  	set_fd(ro_sock,            inset, &max);
> +#endif
>  	set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
> @@ -343,12 +347,14 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	return max;
>  }
>  
> +#ifndef NO_SOCKETS
>  static int destroy_fd(void *_fd)
>  {
>  	int *fd = _fd;
>  	close(*fd);
>  	return 0;
>  }
> +#endif
>  
>  /* Is child a subnode of parent, or equal? */
>  bool is_child(const char *child, const char *parent)
> @@ -1352,6 +1358,7 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
>  	return new;
>  }
>  
> +#ifndef NO_SOCKETS
>  static int writefd(struct connection *conn, const void *data, unsigned int len)
>  {
>  	int rc;
> @@ -1406,6 +1413,7 @@ static void accept_connection(int sock, bool canwrite)
>  	} else
>  		close(fd);
>  }
> +#endif
>  
>  #define TDB_FLAGS 0
>  
> @@ -1753,7 +1761,11 @@ extern void dump_conn(struct connection *conn);
>  int main(int argc, char *argv[])
>  {
>  	int opt, *sock, *ro_sock, max;
> +#ifdef NO_SOCKETS
> +	int minus_one = -1;
> +#else
>  	struct sockaddr_un addr;
> +#endif
>  	fd_set inset, outset;
>  	bool dofork = true;
>  	bool outputpid = false;
> @@ -1837,6 +1849,9 @@ int main(int argc, char *argv[])
>  	if (!dofork)
>  		talloc_enable_leak_report_full();
>  
> +#ifdef NO_SOCKETS
> +	sock = ro_sock = &minus_one;
> +#else
>  	/* Create sockets for them to listen to. */
>  	sock = talloc(talloc_autofree_context(), int);
>  	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
> @@ -1848,10 +1863,12 @@ int main(int argc, char *argv[])
>  		barf_perror("Could not create socket");
>  	talloc_set_destructor(sock, destroy_fd);
>  	talloc_set_destructor(ro_sock, destroy_fd);
> +#endif
>  
>  	/* Don't kill us with SIGPIPE. */
>  	signal(SIGPIPE, SIG_IGN);
>  
> +#ifndef NO_SOCKETS
>  	/* FIXME: Be more sophisticated, don't mug running daemon. */
>  	unlink(xs_daemon_socket());
>  	unlink(xs_daemon_socket_ro());
> @@ -1871,6 +1888,7 @@ int main(int argc, char *argv[])
>  	if (listen(*sock, 1) != 0
>  	    || listen(*ro_sock, 1) != 0)
>  		barf_perror("Could not listen on sockets");
> +#endif
>  
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
> @@ -1931,11 +1949,13 @@ int main(int argc, char *argv[])
>  			reopen_log();
>  		}
>  
> +#ifndef NO_SOCKETS
>  		if (FD_ISSET(*sock, &inset))
>  			accept_connection(*sock, true);
>  
>  		if (FD_ISSET(*ro_sock, &inset))
>  			accept_connection(*ro_sock, false);
> +#endif
>  
>  		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
>  			handle_event();
> diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> index 0a01675..60f2cee 100644
> --- a/tools/xenstore/xs.c
> +++ b/tools/xenstore/xs.c
> @@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
>  {
>  	struct xs_handle *xsh = NULL;
>  
> +#ifndef NO_SOCKETS
>  	if (flags & XS_OPEN_READONLY)
>  		xsh = get_handle(xs_daemon_socket_ro());
>  	else
>  		xsh = get_handle(xs_daemon_socket());
> +#endif
>  
>  	if (!xsh && !(flags & XS_OPEN_SOCKETONLY))
>  		xsh = get_handle(xs_domain_dev());
> diff --git a/tools/xenstore/xs_lib.c b/tools/xenstore/xs_lib.c
> index 03a9ee4..af3db6b 100644
> --- a/tools/xenstore/xs_lib.c
> +++ b/tools/xenstore/xs_lib.c
> @@ -39,6 +39,7 @@ const char *xs_daemon_rundir(void)
>  	return (s ? s : "/var/run/xenstored");
>  }
>  
> +#ifndef NO_SOCKETS
>  static const char *xs_daemon_path(void)
>  {
>  	static char buf[PATH_MAX];
> @@ -50,6 +51,7 @@ static const char *xs_daemon_path(void)
>  		return NULL;
>  	return buf;
>  }
> +#endif
>  
>  const char *xs_daemon_tdb(void)
>  {
> @@ -58,6 +60,7 @@ const char *xs_daemon_tdb(void)
>  	return buf;
>  }
>  
> +#ifndef NO_SOCKETS
>  const char *xs_daemon_socket(void)
>  {
>  	return xs_daemon_path();
> @@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
>  		return NULL;
>  	return buf;
>  }
> +#endif
>  
>  const char *xs_domain_dev(void)
>  {
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHJE-0006am-Ip; Mon, 23 Jan 2012 10:39:32 +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 1RpHJD-0006aZ-CU
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:39:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327315165!11562770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10818 invoked from network); 23 Jan 2012 10:39: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;
	23 Jan 2012 10:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10208054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:39: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; Mon, 23 Jan 2012 10:39:25 +0000
Date: Mon, 23 Jan 2012 10:39:40 +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: <1327092461-2701-17-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201231034010.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-17-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 16/21] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---

> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 631bfe4..66ca555 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -32,7 +32,9 @@
>  #include <stdio.h>
>  #include <stdarg.h>
>  #include <stdlib.h>
> +#ifndef NO_SYSLOG
>  #include <syslog.h>
> +#endif
>  #include <string.h>
>  #include <errno.h>
>  #include <dirent.h>
> @@ -61,13 +63,24 @@ LIST_HEAD(connections);
>  static int tracefd = -1;
>  static bool recovery = true;
>  static bool remove_local = true;
> +#ifndef NO_REOPEN_LOG
>  static int reopen_log_pipe[2];
> +#endif
>  static char *tracefile = NULL;
>  static TDB_CONTEXT *tdb_ctx;
>  
>  static void corrupt(struct connection *conn, const char *fmt, ...);
>  static void check_store(void);
>  
> +#ifdef __MINIOS__
> +#define lockf(...) (-ENOSYS)
> +#endif

maybe it's better to change lockf in extras/mini-os/lib/sys.c from
unsupported_function_crash to unsupported_function_log



> +#ifdef NO_SYSLOG
> +#define openlog(...) ((void) 0)
> +#define syslog(...)  ((void) 0)
> +#endif

these ones are actually supposed to work, going through minios' first
console


>  #define log(...)							\
>  	do {								\
>  		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
> @@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
>  
>  bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
>  {
> +#ifndef __MINIOS__
>  	if (rename(newname, xs_daemon_tdb()) != 0)
>  		return false;
> +#endif
>  	tdb_close(tdb_ctx);
>  	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
>  	return true;
> @@ -195,6 +210,11 @@ void trace_destroy(const void *data, const char *type)
>  	trace("DESTROY %s %p\n", type, data);
>  }
>  
> +#ifdef NO_REOPEN_LOG
> +static void reopen_log(void)
> +{
> +}
> +#else
>  /**
>   * Signal handler for SIGHUP, which requests that the trace log is reopened
>   * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
> @@ -222,7 +242,7 @@ static void reopen_log(void)
>  			trace("\n***\n");
>  	}
>  }
> -
> +#endif
>  
>  static bool write_messages(struct connection *conn)
>  {
> @@ -326,7 +346,9 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	set_fd(sock,               inset, &max);
>  	set_fd(ro_sock,            inset, &max);
>  #endif
> +#ifndef NO_REOPEN_LOG
>  	set_fd(reopen_log_pipe[0], inset, &max);
> +#endif
>  
>  	if (xce_handle != NULL)
>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1415,7 +1437,11 @@ static void accept_connection(int sock, bool canwrite)
>  }
>  #endif
>  
> +#ifdef __MINIOS__
> +#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
> +#else
>  #define TDB_FLAGS 0
> +#endif
>  
>  /* We create initial nodes manually. */
>  static void manual_node(const char *name, const char *child)
> @@ -1440,7 +1466,11 @@ static void setup_structure(void)
>  {
>  	char *tdbname;
>  	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
> +#ifdef __MINIOS__
> +	tdb_ctx = NULL;
> +#else
>  	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
> +#endif
>  
>  	if (tdb_ctx) {
>  		/* XXX When we make xenstored able to restart, this will have
> @@ -1666,6 +1696,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
>  
>  
> +#ifndef __MINIOS__
>  static void write_pidfile(const char *pidfile)
>  {
>  	char buf[100];
> @@ -1712,7 +1743,7 @@ static void daemonize(void)
>  	/* Discard our parent's old-fashioned umask prejudices. */
>  	umask(0);
>  }
> -
> +#endif
>  
>  static void usage(void)
>  {
> @@ -1823,6 +1854,7 @@ int main(int argc, char *argv[])
>  
>  	reopen_log();
>  
> +#ifndef __MINIOS__
>  	/* make sure xenstored directory exists */
>  	if (mkdir(xs_daemon_rundir(), 0755)) {
>  		if (errno != EEXIST) {
> @@ -1844,6 +1876,7 @@ int main(int argc, char *argv[])
>  	}
>  	if (pidfile)
>  		write_pidfile(pidfile);
> +#endif
>  
>  	/* Talloc leak reports go to stderr, which is closed if we fork. */
>  	if (!dofork)
> @@ -1890,9 +1923,11 @@ int main(int argc, char *argv[])
>  		barf_perror("Could not listen on sockets");
>  #endif
>  
> +#ifndef NO_REOPEN_LOG
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
>  	}
> +#endif
>  
>  	/* Setup the database */
>  	setup_structure();
> @@ -1909,6 +1944,7 @@ int main(int argc, char *argv[])
>  		fflush(stdout);
>  	}
>  
> +#ifndef __MINIOS__
>  	/* redirect to /dev/null now we're ready to accept connections */
>  	if (dofork) {
>  		int devnull = open("/dev/null", O_RDWR);
> @@ -1920,8 +1956,11 @@ int main(int argc, char *argv[])
>  		close(devnull);
>  		xprintf = trace;
>  	}
> +#endif
>  
> +#ifndef NO_REOPEN_LOG
>  	signal(SIGHUP, trigger_reopen_log);
> +#endif
>  
>  	if (xce_handle != NULL)
>  		evtchn_fd = xc_evtchn_fd(xce_handle);
> @@ -1929,8 +1968,10 @@ int main(int argc, char *argv[])
>  	/* Get ready to listen to the tools. */
>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>  
> +#ifndef __MINIOS__
>  	/* Tell the kernel we're up and running. */
>  	xenbus_notify_running();
> +#endif
>  
>  	/* Main loop. */
>  	for (;;) {
> @@ -1942,12 +1983,14 @@ int main(int argc, char *argv[])
>  			barf_perror("Select failed");
>  		}
>  
> +#ifndef NO_REOPEN_LOG
>  		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
>  			char c;
>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>  				barf_perror("read failed");
>  			reopen_log();
>  		}
> +#endif
>  
>  #ifndef NO_SOCKETS
>  		if (FD_ISSET(*sock, &inset))
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 661d955..435f76a 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
>  	}
>  
>  	if (domain->interface) {
> +#ifdef __MINIOS__
> +		unmap_interface(domain->interface);
> +#else
>  		if (domain->domid == 0)
>  			munmap(domain->interface, getpagesize());
>  		else
>  			unmap_interface(domain->interface);
> +#endif
>  	}
>  
>  	fire_watches(NULL, "@releaseDomain", false);
> @@ -595,6 +599,12 @@ void restore_existing_connections(void)
>  {
>  }
>  
> +#ifdef __MINIOS__
> +static int dom0_init(void)
> +{
> +	return 0;
> +}
> +#else
>  static int dom0_init(void) 
>  { 
>  	evtchn_port_t port;
> @@ -618,6 +628,7 @@ static int dom0_init(void)
>  
>  	return 0; 
>  }
> +#endif
>  
>  void domain_init(void)
>  {
> diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
> index 380c691..c59acfb 100644
> --- a/tools/xenstore/xenstored_transaction.c
> +++ b/tools/xenstore/xenstored_transaction.c
> @@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
>  	trace_destroy(trans, "transaction");
>  	if (trans->tdb)
>  		tdb_close(trans->tdb);
> +#ifndef __MINIOS__
>  	unlink(trans->tdb_name);
> +#endif
>  	return 0;
>  }
>  

maybe we could reduce the amount of ifdef's using the same struct of
function pointers idea?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHJE-0006am-Ip; Mon, 23 Jan 2012 10:39:32 +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 1RpHJD-0006aZ-CU
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:39:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327315165!11562770!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10818 invoked from network); 23 Jan 2012 10:39: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;
	23 Jan 2012 10:39:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10208054"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:39: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; Mon, 23 Jan 2012 10:39:25 +0000
Date: Mon, 23 Jan 2012 10:39:40 +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: <1327092461-2701-17-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201231034010.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-17-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 16/21] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---

> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 631bfe4..66ca555 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -32,7 +32,9 @@
>  #include <stdio.h>
>  #include <stdarg.h>
>  #include <stdlib.h>
> +#ifndef NO_SYSLOG
>  #include <syslog.h>
> +#endif
>  #include <string.h>
>  #include <errno.h>
>  #include <dirent.h>
> @@ -61,13 +63,24 @@ LIST_HEAD(connections);
>  static int tracefd = -1;
>  static bool recovery = true;
>  static bool remove_local = true;
> +#ifndef NO_REOPEN_LOG
>  static int reopen_log_pipe[2];
> +#endif
>  static char *tracefile = NULL;
>  static TDB_CONTEXT *tdb_ctx;
>  
>  static void corrupt(struct connection *conn, const char *fmt, ...);
>  static void check_store(void);
>  
> +#ifdef __MINIOS__
> +#define lockf(...) (-ENOSYS)
> +#endif

maybe it's better to change lockf in extras/mini-os/lib/sys.c from
unsupported_function_crash to unsupported_function_log



> +#ifdef NO_SYSLOG
> +#define openlog(...) ((void) 0)
> +#define syslog(...)  ((void) 0)
> +#endif

these ones are actually supposed to work, going through minios' first
console


>  #define log(...)							\
>  	do {								\
>  		char *s = talloc_asprintf(NULL, __VA_ARGS__);		\
> @@ -92,8 +105,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
>  
>  bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
>  {
> +#ifndef __MINIOS__
>  	if (rename(newname, xs_daemon_tdb()) != 0)
>  		return false;
> +#endif
>  	tdb_close(tdb_ctx);
>  	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
>  	return true;
> @@ -195,6 +210,11 @@ void trace_destroy(const void *data, const char *type)
>  	trace("DESTROY %s %p\n", type, data);
>  }
>  
> +#ifdef NO_REOPEN_LOG
> +static void reopen_log(void)
> +{
> +}
> +#else
>  /**
>   * Signal handler for SIGHUP, which requests that the trace log is reopened
>   * (in the main loop).  A single byte is written to reopen_log_pipe, to awaken
> @@ -222,7 +242,7 @@ static void reopen_log(void)
>  			trace("\n***\n");
>  	}
>  }
> -
> +#endif
>  
>  static bool write_messages(struct connection *conn)
>  {
> @@ -326,7 +346,9 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	set_fd(sock,               inset, &max);
>  	set_fd(ro_sock,            inset, &max);
>  #endif
> +#ifndef NO_REOPEN_LOG
>  	set_fd(reopen_log_pipe[0], inset, &max);
> +#endif
>  
>  	if (xce_handle != NULL)
>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1415,7 +1437,11 @@ static void accept_connection(int sock, bool canwrite)
>  }
>  #endif
>  
> +#ifdef __MINIOS__
> +#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
> +#else
>  #define TDB_FLAGS 0
> +#endif
>  
>  /* We create initial nodes manually. */
>  static void manual_node(const char *name, const char *child)
> @@ -1440,7 +1466,11 @@ static void setup_structure(void)
>  {
>  	char *tdbname;
>  	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
> +#ifdef __MINIOS__
> +	tdb_ctx = NULL;
> +#else
>  	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
> +#endif
>  
>  	if (tdb_ctx) {
>  		/* XXX When we make xenstored able to restart, this will have
> @@ -1666,6 +1696,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
>  
>  
> +#ifndef __MINIOS__
>  static void write_pidfile(const char *pidfile)
>  {
>  	char buf[100];
> @@ -1712,7 +1743,7 @@ static void daemonize(void)
>  	/* Discard our parent's old-fashioned umask prejudices. */
>  	umask(0);
>  }
> -
> +#endif
>  
>  static void usage(void)
>  {
> @@ -1823,6 +1854,7 @@ int main(int argc, char *argv[])
>  
>  	reopen_log();
>  
> +#ifndef __MINIOS__
>  	/* make sure xenstored directory exists */
>  	if (mkdir(xs_daemon_rundir(), 0755)) {
>  		if (errno != EEXIST) {
> @@ -1844,6 +1876,7 @@ int main(int argc, char *argv[])
>  	}
>  	if (pidfile)
>  		write_pidfile(pidfile);
> +#endif
>  
>  	/* Talloc leak reports go to stderr, which is closed if we fork. */
>  	if (!dofork)
> @@ -1890,9 +1923,11 @@ int main(int argc, char *argv[])
>  		barf_perror("Could not listen on sockets");
>  #endif
>  
> +#ifndef NO_REOPEN_LOG
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
>  	}
> +#endif
>  
>  	/* Setup the database */
>  	setup_structure();
> @@ -1909,6 +1944,7 @@ int main(int argc, char *argv[])
>  		fflush(stdout);
>  	}
>  
> +#ifndef __MINIOS__
>  	/* redirect to /dev/null now we're ready to accept connections */
>  	if (dofork) {
>  		int devnull = open("/dev/null", O_RDWR);
> @@ -1920,8 +1956,11 @@ int main(int argc, char *argv[])
>  		close(devnull);
>  		xprintf = trace;
>  	}
> +#endif
>  
> +#ifndef NO_REOPEN_LOG
>  	signal(SIGHUP, trigger_reopen_log);
> +#endif
>  
>  	if (xce_handle != NULL)
>  		evtchn_fd = xc_evtchn_fd(xce_handle);
> @@ -1929,8 +1968,10 @@ int main(int argc, char *argv[])
>  	/* Get ready to listen to the tools. */
>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>  
> +#ifndef __MINIOS__
>  	/* Tell the kernel we're up and running. */
>  	xenbus_notify_running();
> +#endif
>  
>  	/* Main loop. */
>  	for (;;) {
> @@ -1942,12 +1983,14 @@ int main(int argc, char *argv[])
>  			barf_perror("Select failed");
>  		}
>  
> +#ifndef NO_REOPEN_LOG
>  		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
>  			char c;
>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>  				barf_perror("read failed");
>  			reopen_log();
>  		}
> +#endif
>  
>  #ifndef NO_SOCKETS
>  		if (FD_ISSET(*sock, &inset))
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 661d955..435f76a 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
>  	}
>  
>  	if (domain->interface) {
> +#ifdef __MINIOS__
> +		unmap_interface(domain->interface);
> +#else
>  		if (domain->domid == 0)
>  			munmap(domain->interface, getpagesize());
>  		else
>  			unmap_interface(domain->interface);
> +#endif
>  	}
>  
>  	fire_watches(NULL, "@releaseDomain", false);
> @@ -595,6 +599,12 @@ void restore_existing_connections(void)
>  {
>  }
>  
> +#ifdef __MINIOS__
> +static int dom0_init(void)
> +{
> +	return 0;
> +}
> +#else
>  static int dom0_init(void) 
>  { 
>  	evtchn_port_t port;
> @@ -618,6 +628,7 @@ static int dom0_init(void)
>  
>  	return 0; 
>  }
> +#endif
>  
>  void domain_init(void)
>  {
> diff --git a/tools/xenstore/xenstored_transaction.c b/tools/xenstore/xenstored_transaction.c
> index 380c691..c59acfb 100644
> --- a/tools/xenstore/xenstored_transaction.c
> +++ b/tools/xenstore/xenstored_transaction.c
> @@ -120,7 +120,9 @@ static int destroy_transaction(void *_transaction)
>  	trace_destroy(trans, "transaction");
>  	if (trans->tdb)
>  		tdb_close(trans->tdb);
> +#ifndef __MINIOS__
>  	unlink(trans->tdb_name);
> +#endif
>  	return 0;
>  }
>  

maybe we could reduce the amount of ifdef's using the same struct of
function pointers idea?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHP6-0006vQ-7k; Mon, 23 Jan 2012 10:45:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpHP5-0006uy-Ht
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:45:35 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327315528!11564134!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMzQzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8316 invoked from network); 23 Jan 2012 10:45:29 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 10:45:29 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=fXgDOp+ssRKX4CG+BTrjCD7kOI30EOkUFx7FqFX6up1PDekk+7bPWnf9
	yBVNAFtqMSCUZl3HNfrmCeDpCDiAhNjErKErSZotN94lNM9KuZRAtC+SK
	1Sran4Pi21JnIi/cD3/X3tFsisDf3yEM4J+rxshRo1ooMIM7DdTCLRqL2
	glmZTd8MbKyu/rnuXlU1R+DgdbcAj8fLl7JOEK2mabmk7UPuwi4qkqNrk
	jxPCGykk7erliNn3gMlnzrEzioSdx;
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=1327315529; x=1358851529;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=LDzZfwQC/NOcYuqBTPRMYwwltgm4e98KdDRPIGaJnuo=;
	b=r5MlsxVA67+qAepPIZkShnvj+s1umBRbvD1OCtiTaUsABlpEe1aCQIG3
	uRNzvwhVy01BSez1wCQxE++4bXoLeMolctdQqV12EJNcl53x6eMvoNvzi
	a4kYrCOcBGtt2MADIpgHReJ+4s79o2uH5dq6joWlX+Bzgl2Adcv1vIBNn
	yXfvEGU+39mqp1uc+Ehn+ZpkvTidF//uLL4wvxT/598t2D1DC3OiCHeB4
	Pf0GBkaOBXEOxQJcPcRoyt46SKhcC;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="99403114"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 23 Jan 2012 11:45:28 +0100
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="127569850"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 23 Jan 2012 11:45:28 +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 2A0D195F317;
	Mon, 23 Jan 2012 11:45:28 +0100 (CET)
Message-ID: <4F1D3A48.90809@ts.fujitsu.com>
Date: Mon, 23 Jan 2012 11:45:28 +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: Jan Beulich <JBeulich@suse.com>
References: <cee17928d4eff5e7873f.1327312293@nehalem1>
	<4F1D4409020000780006E545@nat28.tlf.novell.com>
In-Reply-To: <4F1D4409020000780006E545@nat28.tlf.novell.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 11:27 AM, Jan Beulich wrote:
>>>> On 23.01.12 at 10:51, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
> @@ -365,15 +366,21 @@ void domain_update_node_affinity(struct
>> void domain_update_node_affinity(struct domain *d)
>> {
>>      cpumask_t cpumask;
>> +    cpumask_t online_affinity;
> If at all possible, please don't introduce new automatic cpumask_t
> variables. Allocating them will of course mean that the function can
> fail, and that callers need to deal with the failure. (Probably a prior
> patch should then first convert the 'cpumask' variable.)

In this case I don't think it is very complicated.
Not doing anything in domain_update_node_affinity() will just produce a
lower performance. So doing a return in case of an allocation failure should
be fine.

>> +    cpumask_t *online;
> const.

Okay.

>>      nodemask_t nodemask = NODE_MASK_NONE;
>>      struct vcpu *v;
>>      unsigned int node;
>>
>> +    online = (d->cpupool == NULL) ?&cpu_online_map : d->cpupool->cpu_valid;
> This construct (together with its brother using 'cpupool_free_cpus')
> meanwhile enjoys quite a number of instances - could it get abstracted
> into a pair of inline functions or macros?

Okay.


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 Mon Jan 23 10:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHP6-0006vQ-7k; Mon, 23 Jan 2012 10:45:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpHP5-0006uy-Ht
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:45:35 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327315528!11564134!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMzQzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8316 invoked from network); 23 Jan 2012 10:45:29 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 10:45:29 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=fXgDOp+ssRKX4CG+BTrjCD7kOI30EOkUFx7FqFX6up1PDekk+7bPWnf9
	yBVNAFtqMSCUZl3HNfrmCeDpCDiAhNjErKErSZotN94lNM9KuZRAtC+SK
	1Sran4Pi21JnIi/cD3/X3tFsisDf3yEM4J+rxshRo1ooMIM7DdTCLRqL2
	glmZTd8MbKyu/rnuXlU1R+DgdbcAj8fLl7JOEK2mabmk7UPuwi4qkqNrk
	jxPCGykk7erliNn3gMlnzrEzioSdx;
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=1327315529; x=1358851529;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=LDzZfwQC/NOcYuqBTPRMYwwltgm4e98KdDRPIGaJnuo=;
	b=r5MlsxVA67+qAepPIZkShnvj+s1umBRbvD1OCtiTaUsABlpEe1aCQIG3
	uRNzvwhVy01BSez1wCQxE++4bXoLeMolctdQqV12EJNcl53x6eMvoNvzi
	a4kYrCOcBGtt2MADIpgHReJ+4s79o2uH5dq6joWlX+Bzgl2Adcv1vIBNn
	yXfvEGU+39mqp1uc+Ehn+ZpkvTidF//uLL4wvxT/598t2D1DC3OiCHeB4
	Pf0GBkaOBXEOxQJcPcRoyt46SKhcC;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="99403114"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 23 Jan 2012 11:45:28 +0100
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="127569850"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 23 Jan 2012 11:45:28 +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 2A0D195F317;
	Mon, 23 Jan 2012 11:45:28 +0100 (CET)
Message-ID: <4F1D3A48.90809@ts.fujitsu.com>
Date: Mon, 23 Jan 2012 11:45:28 +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: Jan Beulich <JBeulich@suse.com>
References: <cee17928d4eff5e7873f.1327312293@nehalem1>
	<4F1D4409020000780006E545@nat28.tlf.novell.com>
In-Reply-To: <4F1D4409020000780006E545@nat28.tlf.novell.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 11:27 AM, Jan Beulich wrote:
>>>> On 23.01.12 at 10:51, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
> @@ -365,15 +366,21 @@ void domain_update_node_affinity(struct
>> void domain_update_node_affinity(struct domain *d)
>> {
>>      cpumask_t cpumask;
>> +    cpumask_t online_affinity;
> If at all possible, please don't introduce new automatic cpumask_t
> variables. Allocating them will of course mean that the function can
> fail, and that callers need to deal with the failure. (Probably a prior
> patch should then first convert the 'cpumask' variable.)

In this case I don't think it is very complicated.
Not doing anything in domain_update_node_affinity() will just produce a
lower performance. So doing a return in case of an allocation failure should
be fine.

>> +    cpumask_t *online;
> const.

Okay.

>>      nodemask_t nodemask = NODE_MASK_NONE;
>>      struct vcpu *v;
>>      unsigned int node;
>>
>> +    online = (d->cpupool == NULL) ?&cpu_online_map : d->cpupool->cpu_valid;
> This construct (together with its brother using 'cpupool_free_cpus')
> meanwhile enjoys quite a number of instances - could it get abstracted
> into a pair of inline functions or macros?

Okay.


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 Mon Jan 23 10:47:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10: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 1RpHQh-00075K-Ns; Mon, 23 Jan 2012 10:47:15 +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 1RpHQg-00074h-7r
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:47:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327315627!11459403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5159 invoked from network); 23 Jan 2012 10:47:07 -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;
	23 Jan 2012 10:47:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10208249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:47:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 10:47:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 23 Jan 2012 10:47:06 +0000
In-Reply-To: <20227.16947.747976.735762@mariner.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327315626.24561.32.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

T24gVHVlLCAyMDEyLTAxLTAzIGF0IDE4OjAwICswMDAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBJ
YW4gQ2FtcGJlbGwgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIFtQQVRDSCB2Ml0gbGlieGw6IGFk
ZCBzdXBwb3J0IGZvciB5YWpsIDIueCIpOgo+ID4gT24gVGh1LCAyMDExLTEyLTIyIGF0IDE2OjQx
ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+ID4gPiBTb21lIGF1dG9nb28gc3R1ZmYg
d2lsbCBiZSBnb29kLCBhdCBsZWFzdCBmb3IgdGhlIHRvb2xzIGJ1aWxkLiBDYW4geW91Cj4gPiA+
IHNldCB1cCB0aGUgYmFzaWMgc3RydWN0dXJlIElhbj8KPiA+IAo+ID4gSSdtIG5vdCBnb2luZyB0
byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+ID4gCj4gPiBXb3VsZCBpdCBiZSBzdWZm
aWNpZW50IHRvIGhhdmUgdGhlIHN0dWZmIGluIHRvb2xzL2NoZWNrIGNyZWF0ZSBhCj4gPiBjb25m
aWcuaCBhcyB3ZWxsIGFzIGRvaW5nIHRoZSBjaGVja3M/IE1pZ2h0IG5lZWQgYSBiaXQgb2YgTWFr
ZWZpbGUgbWFnaWMKPiA+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+IAo+
IEZvciBub3csIEkgdGhpbmsgd2Ugc2hvdWxkIG5vdCBhZGQgbW9yZSBzdHVmZiB0byB0aGUgY3Jp
dGljYWwgcGF0aCBmb3IKPiBYZW4gNC4yLiAgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxkIHN3aXRj
aCB0byBhdXRvY29uZiBJIHRoaW5rLiAgKEkKPiBkb24ndCBhcHByb3ZlIG9mIGF1dG9tYWtlLikK
Ckl0IHNlZW1zIHRoYXQgeWFqbCAyLjAgc3VwcG9ydCBpcyBibG9ja2VkIG9uIHRoZSBhdXRvY29u
ZiBzdHVmZi4gQ2FuIHdlCmRpc2VudGFuZ2xlIHRoaW5ncyBzdWNoIHRoYXQgd2UgY2FuIHN1cHBv
cnQgeWFqbCAyLjAgaW4gWGVuIDQuMiBhbmQKc3dpdGNoIHRvIGF1dG9jb25mIGFmdGVyd2FyZHMg
b3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRjaCB0bwphdXRvY29uZiBmb3IgNC4y
PwoKSSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBhYm91dCBjcml0aWNhbCBwYXRoIGZvciA0LjIu
IEkgcHJlc3VtZQphdXRvY29uZiB3b3VsZCByZXF1aXJlIG1vcmUgdGhhbiBqdXN0IGNoZWNraW5n
IGluIHRoZSBwYXRjaGVzLApzcGVjaWZpY2FsbHkgSSdtIHRoaW5raW5nIG9mIHRoZSBhdXRvbWF0
ZWQgdGVzdCBzeXN0ZW0gdXBkYXRlIGFuZCBkb2NzLgoKT24gdGhlIG90aGVyIGhhbmQgUm9nZXIg
cG9zdGVkIHYzIG9mIGhpcyBhdXRvY29uZiBzdXBwb3J0IHBhdGNoIGFuZAphbHRob3VnaCBJIGhh
dmVuJ3QgZ290IHJvdW5kIHRvIHJldmlld2luZyBpdCB5ZXQgKHNvcnJ5KSB2MidzIHJldmlldyB3
YXMKZ2VuZXJhbGx5IHBvc2l0aXZlL21pbm9yIGxvb2tpbmcuCgpJYW4uCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:47:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10: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 1RpHQh-00075K-Ns; Mon, 23 Jan 2012 10:47:15 +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 1RpHQg-00074h-7r
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:47:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327315627!11459403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5159 invoked from network); 23 Jan 2012 10:47:07 -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;
	23 Jan 2012 10:47:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10208249"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:47:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 10:47:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 23 Jan 2012 10:47:06 +0000
In-Reply-To: <20227.16947.747976.735762@mariner.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327315626.24561.32.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

T24gVHVlLCAyMDEyLTAxLTAzIGF0IDE4OjAwICswMDAwLCBJYW4gSmFja3NvbiB3cm90ZToKPiBJ
YW4gQ2FtcGJlbGwgd3JpdGVzICgiUmU6IFtYZW4tZGV2ZWxdIFtQQVRDSCB2Ml0gbGlieGw6IGFk
ZCBzdXBwb3J0IGZvciB5YWpsIDIueCIpOgo+ID4gT24gVGh1LCAyMDExLTEyLTIyIGF0IDE2OjQx
ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+ID4gPiBTb21lIGF1dG9nb28gc3R1ZmYg
d2lsbCBiZSBnb29kLCBhdCBsZWFzdCBmb3IgdGhlIHRvb2xzIGJ1aWxkLiBDYW4geW91Cj4gPiA+
IHNldCB1cCB0aGUgYmFzaWMgc3RydWN0dXJlIElhbj8KPiA+IAo+ID4gSSdtIG5vdCBnb2luZyB0
byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+ID4gCj4gPiBXb3VsZCBpdCBiZSBzdWZm
aWNpZW50IHRvIGhhdmUgdGhlIHN0dWZmIGluIHRvb2xzL2NoZWNrIGNyZWF0ZSBhCj4gPiBjb25m
aWcuaCBhcyB3ZWxsIGFzIGRvaW5nIHRoZSBjaGVja3M/IE1pZ2h0IG5lZWQgYSBiaXQgb2YgTWFr
ZWZpbGUgbWFnaWMKPiA+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+IAo+
IEZvciBub3csIEkgdGhpbmsgd2Ugc2hvdWxkIG5vdCBhZGQgbW9yZSBzdHVmZiB0byB0aGUgY3Jp
dGljYWwgcGF0aCBmb3IKPiBYZW4gNC4yLiAgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxkIHN3aXRj
aCB0byBhdXRvY29uZiBJIHRoaW5rLiAgKEkKPiBkb24ndCBhcHByb3ZlIG9mIGF1dG9tYWtlLikK
Ckl0IHNlZW1zIHRoYXQgeWFqbCAyLjAgc3VwcG9ydCBpcyBibG9ja2VkIG9uIHRoZSBhdXRvY29u
ZiBzdHVmZi4gQ2FuIHdlCmRpc2VudGFuZ2xlIHRoaW5ncyBzdWNoIHRoYXQgd2UgY2FuIHN1cHBv
cnQgeWFqbCAyLjAgaW4gWGVuIDQuMiBhbmQKc3dpdGNoIHRvIGF1dG9jb25mIGFmdGVyd2FyZHMg
b3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRjaCB0bwphdXRvY29uZiBmb3IgNC4y
PwoKSSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBhYm91dCBjcml0aWNhbCBwYXRoIGZvciA0LjIu
IEkgcHJlc3VtZQphdXRvY29uZiB3b3VsZCByZXF1aXJlIG1vcmUgdGhhbiBqdXN0IGNoZWNraW5n
IGluIHRoZSBwYXRjaGVzLApzcGVjaWZpY2FsbHkgSSdtIHRoaW5raW5nIG9mIHRoZSBhdXRvbWF0
ZWQgdGVzdCBzeXN0ZW0gdXBkYXRlIGFuZCBkb2NzLgoKT24gdGhlIG90aGVyIGhhbmQgUm9nZXIg
cG9zdGVkIHYzIG9mIGhpcyBhdXRvY29uZiBzdXBwb3J0IHBhdGNoIGFuZAphbHRob3VnaCBJIGhh
dmVuJ3QgZ290IHJvdW5kIHRvIHJldmlld2luZyBpdCB5ZXQgKHNvcnJ5KSB2MidzIHJldmlldyB3
YXMKZ2VuZXJhbGx5IHBvc2l0aXZlL21pbm9yIGxvb2tpbmcuCgpJYW4uCgoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:47:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHQm-00075q-44; Mon, 23 Jan 2012 10:47:20 +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 1RpHQk-000756-6U
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:47:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327315630!13514722!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 22246 invoked from network); 23 Jan 2012 10:47:11 -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; 23 Jan 2012 10:47:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 10:48:47 +0000
Message-Id: <4F1D48BA020000780006E55F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 10:47:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327313777.24561.9.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 11:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
>> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
>> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
>> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
>> > @@ -68,7 +68,7 @@ struct event_log {
>> >   };
>> > 
>> >   /* PC value that indicates a special code */
>> > -#define XENOPROF_ESCAPE_CODE ~0UL
>> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
>> 
>> You cannot just go and change a public definition, as the consuming
>> side will break. You need to introduce a new escape code, and
>> provide a mechanism to negotiate (between hypervisor and kernel)
>> which one to use.
> 
> This seems more like a bug fix to me than an interface change, the fact
> that both producer and consumer had the bug notwithstanding.
> 
> Since this is a developer oriented interface I think we can be a little
> more relaxed than we would be for other interface changes. In this case
> we are fixing 32on64 (quite common) at the expense of 32on32 (very
> uncommon these days, especially for the suybset of developers wanting to
> do profiling) and leaving 64on64 (quite common) as it is . That seems
> like a worthwhile tradeoff to me.

I see your point. However, I'd still like to be careful with this - what
we think things ought to be used for doesn't necessarily cover all
cases that they are in reality.

Additionally, making as exception here (where the developer nature
of the change is deemed obvious) may get us to the question of
making a similar adjustment in not as clear a situation at some point
in the future.

As negotiation isn't really difficult to implement (e.g. a new ELF note)
I don't really see why we shouldn't remain on the safe side here. But
Keir would have the final word anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:47:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:47:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHQm-00075q-44; Mon, 23 Jan 2012 10:47:20 +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 1RpHQk-000756-6U
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:47:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327315630!13514722!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 22246 invoked from network); 23 Jan 2012 10:47:11 -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; 23 Jan 2012 10:47:11 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 10:48:47 +0000
Message-Id: <4F1D48BA020000780006E55F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 10:47:06 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327313777.24561.9.camel@zakaz.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 11:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Mon, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
>> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
>> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
>> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
>> > @@ -68,7 +68,7 @@ struct event_log {
>> >   };
>> > 
>> >   /* PC value that indicates a special code */
>> > -#define XENOPROF_ESCAPE_CODE ~0UL
>> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
>> 
>> You cannot just go and change a public definition, as the consuming
>> side will break. You need to introduce a new escape code, and
>> provide a mechanism to negotiate (between hypervisor and kernel)
>> which one to use.
> 
> This seems more like a bug fix to me than an interface change, the fact
> that both producer and consumer had the bug notwithstanding.
> 
> Since this is a developer oriented interface I think we can be a little
> more relaxed than we would be for other interface changes. In this case
> we are fixing 32on64 (quite common) at the expense of 32on32 (very
> uncommon these days, especially for the suybset of developers wanting to
> do profiling) and leaving 64on64 (quite common) as it is . That seems
> like a worthwhile tradeoff to me.

I see your point. However, I'd still like to be careful with this - what
we think things ought to be used for doesn't necessarily cover all
cases that they are in reality.

Additionally, making as exception here (where the developer nature
of the change is deemed obvious) may get us to the question of
making a similar adjustment in not as clear a situation at some point
in the future.

As negotiation isn't really difficult to implement (e.g. a new ELF note)
I don't really see why we shouldn't remain on the safe side here. But
Keir would have the final word anyway.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:47:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHQq-000775-Gk; Mon, 23 Jan 2012 10:47:24 +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 1RpHQo-00075Y-PR
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:47:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327315635!12175320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21984 invoked from network); 23 Jan 2012 10:47:16 -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;
	23 Jan 2012 10:47:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10208257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:47: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, 23 Jan 2012 10:47:14 +0000
Date: Mon, 23 Jan 2012 10:47:30 +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: <4F19AB66.8060901@siemens.com>
Message-ID: <alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Jan Kiszka wrote:
> On 2012-01-20 18:20, Stefano Stabellini wrote:
> > Hi all,
> > this is the fourth version of the Xen save/restore patch series.
> > We have been discussing this issue for quite a while on #qemu and
> > qemu-devel:
> > 
> > 
> > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> > http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> > 
> > 
> > A few different approaches were proposed to achieve the goal
> > of a working save/restore with upstream Qemu on Xen, however after
> > prototyping some of them I came up with yet another solution, that I
> > think leads to the best results with the less amount of code
> > duplications and ugliness.
> > Far from saying that this patch series is an example of elegance and
> > simplicity, but it is closer to acceptable anything else I have seen so
> > far.
> > 
> > What's new is that Qemu is going to keep track of its own physmap on
> > xenstore, so that Xen can be fully aware of the changes Qemu makes to
> > the guest's memory map at any time.
> > This is all handled by Xen or Xen support in Qemu internally and can be
> > used to solve our save/restore framebuffer problem.
> > 
> >>From the Qemu common code POV, we still need to avoid saving the guest's
> > ram when running on Xen, and we need to avoid resetting the videoram on
> > restore (that is a benefit to the generic Qemu case too, because it
> > saves few cpu cycles).
> 
> For my understanding: Refraining from the memset is required as the
> already restored vram would then be overwritten?

Yep

> Or what is the ordering
> of init, RAM restore, and initial device reset now?

RAM restore (done by Xen)

physmap rebuild (done by xen_hvm_init in qemu)
pc_init()
qemu_system_reset()
load_vmstate()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:47:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHQq-000775-Gk; Mon, 23 Jan 2012 10:47:24 +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 1RpHQo-00075Y-PR
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:47:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327315635!12175320!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21984 invoked from network); 23 Jan 2012 10:47:16 -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;
	23 Jan 2012 10:47:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10208257"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:47: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, 23 Jan 2012 10:47:14 +0000
Date: Mon, 23 Jan 2012 10:47:30 +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: <4F19AB66.8060901@siemens.com>
Message-ID: <alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 20 Jan 2012, Jan Kiszka wrote:
> On 2012-01-20 18:20, Stefano Stabellini wrote:
> > Hi all,
> > this is the fourth version of the Xen save/restore patch series.
> > We have been discussing this issue for quite a while on #qemu and
> > qemu-devel:
> > 
> > 
> > http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> > http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> > 
> > 
> > A few different approaches were proposed to achieve the goal
> > of a working save/restore with upstream Qemu on Xen, however after
> > prototyping some of them I came up with yet another solution, that I
> > think leads to the best results with the less amount of code
> > duplications and ugliness.
> > Far from saying that this patch series is an example of elegance and
> > simplicity, but it is closer to acceptable anything else I have seen so
> > far.
> > 
> > What's new is that Qemu is going to keep track of its own physmap on
> > xenstore, so that Xen can be fully aware of the changes Qemu makes to
> > the guest's memory map at any time.
> > This is all handled by Xen or Xen support in Qemu internally and can be
> > used to solve our save/restore framebuffer problem.
> > 
> >>From the Qemu common code POV, we still need to avoid saving the guest's
> > ram when running on Xen, and we need to avoid resetting the videoram on
> > restore (that is a benefit to the generic Qemu case too, because it
> > saves few cpu cycles).
> 
> For my understanding: Refraining from the memset is required as the
> already restored vram would then be overwritten?

Yep

> Or what is the ordering
> of init, RAM restore, and initial device reset now?

RAM restore (done by Xen)

physmap rebuild (done by xen_hvm_init in qemu)
pc_init()
qemu_system_reset()
load_vmstate()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:51:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10: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 1RpHUH-0007Zz-5T; Mon, 23 Jan 2012 10:50:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpHUF-0007Z3-W1
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:50:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327315846!11606706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27214 invoked from network); 23 Jan 2012 10:50:49 -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;
	23 Jan 2012 10:50:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10208399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:50: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, 23 Jan 2012 10:50:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Mon, 23 Jan 2012 10:50:45 +0000
In-Reply-To: <1327314471.2476.1.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>	<1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.com>
	<1326473132.2397.6.camel@Abyss.citrite.net>
	<20240.24689.833215.133892@mariner.uk.xensource.com>
	<1327314092.24561.14.camel@zakaz.uk.xensource.com>
	<1327314471.2476.1.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327315846.24561.36.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 10:27 +0000, Dario Faggioli wrote:
> On Mon, 2012-01-23 at 10:21 +0000, Ian Campbell wrote: 
> > Can we take the version which just moves the dodgy parsee now and worry
> > about reworking it later? I think we'd like to see vcpu pinning in 4.2.
> > 
> Hey, sorry for being so late in resubmitting, I've been distrcted by
> those (other) NUME issues... I'll send a new version of this in the
> afternoon!
> 
> Sorry again,

No need to apologise. I was just going over the 4.2 TODO list to repost
it. I've added "xl support for vcpu pinning" to the tools section and
"NUMA improvements (cpupool autopin?)" to the hypervisor (nice to have)
section

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 10:51:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 10: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 1RpHUH-0007Zz-5T; Mon, 23 Jan 2012 10:50:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpHUF-0007Z3-W1
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 10:50:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327315846!11606706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27214 invoked from network); 23 Jan 2012 10:50:49 -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;
	23 Jan 2012 10:50:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10208399"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 10:50: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, 23 Jan 2012 10:50:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Mon, 23 Jan 2012 10:50:45 +0000
In-Reply-To: <1327314471.2476.1.camel@Abyss>
References: <1326304198.2401.6.camel@Abyss>	<1326304739.12973.1.camel@Abyss>
	<20239.6553.110187.528841@mariner.uk.xensource.com>
	<1326409937.4494.22.camel@Abyss>
	<20240.13002.205604.969404@mariner.uk.xensource.com>
	<1326473132.2397.6.camel@Abyss.citrite.net>
	<20240.24689.833215.133892@mariner.uk.xensource.com>
	<1327314092.24561.14.camel@zakaz.uk.xensource.com>
	<1327314471.2476.1.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327315846.24561.36.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 10:27 +0000, Dario Faggioli wrote:
> On Mon, 2012-01-23 at 10:21 +0000, Ian Campbell wrote: 
> > Can we take the version which just moves the dodgy parsee now and worry
> > about reworking it later? I think we'd like to see vcpu pinning in 4.2.
> > 
> Hey, sorry for being so late in resubmitting, I've been distrcted by
> those (other) NUME issues... I'll send a new version of this in the
> afternoon!
> 
> Sorry again,

No need to apologise. I was just going over the 4.2 TODO list to repost
it. I've added "xl support for vcpu pinning" to the tools section and
"NUMA improvements (cpupool autopin?)" to the hypervisor (nice to have)
section

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:03:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHgK-0007xZ-4r; Mon, 23 Jan 2012 11:03: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 1RpHgJ-0007xO-AV
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:03:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327316596!10280529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8334 invoked from network); 23 Jan 2012 11:03:16 -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;
	23 Jan 2012 11:03:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10209120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:03: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, 23 Jan 2012 11:03:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Mon, 23 Jan 2012 11:03:15 +0000
In-Reply-To: <cee17928d4eff5e7873f.1327312293@nehalem1>
References: <cee17928d4eff5e7873f.1327312293@nehalem1>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327316595.24561.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] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 09:51 +0000, Juergen Gross wrote:
> @@ -365,15 +366,21 @@ void domain_update_node_affinity(struct 
>  void domain_update_node_affinity(struct domain *d)
>  {
>      cpumask_t cpumask;
> +    cpumask_t online_affinity;
> +    cpumask_t *online;
>      nodemask_t nodemask = NODE_MASK_NONE;
>      struct vcpu *v;
>      unsigned int node;
>  
> +    online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
>      cpumask_clear(&cpumask);
>      spin_lock(&d->node_affinity_lock);
>  
>      for_each_vcpu ( d, v )
> -        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
> +    {
> +        cpumask_and(&online_affinity, v->cpu_affinity, online);
> +        cpumask_or(&cpumask, &cpumask, &online_affinity);
> +    }
>  
>      for_each_online_node ( node )
>          if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) ) 

Is there any possibility that the addition of the cpumask_and clause
could result in the empty set?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:03:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:03:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHgK-0007xZ-4r; Mon, 23 Jan 2012 11:03: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 1RpHgJ-0007xO-AV
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:03:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327316596!10280529!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8334 invoked from network); 23 Jan 2012 11:03:16 -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;
	23 Jan 2012 11:03:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10209120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:03: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, 23 Jan 2012 11:03:15 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Mon, 23 Jan 2012 11:03:15 +0000
In-Reply-To: <cee17928d4eff5e7873f.1327312293@nehalem1>
References: <cee17928d4eff5e7873f.1327312293@nehalem1>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327316595.24561.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] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 09:51 +0000, Juergen Gross wrote:
> @@ -365,15 +366,21 @@ void domain_update_node_affinity(struct 
>  void domain_update_node_affinity(struct domain *d)
>  {
>      cpumask_t cpumask;
> +    cpumask_t online_affinity;
> +    cpumask_t *online;
>      nodemask_t nodemask = NODE_MASK_NONE;
>      struct vcpu *v;
>      unsigned int node;
>  
> +    online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
>      cpumask_clear(&cpumask);
>      spin_lock(&d->node_affinity_lock);
>  
>      for_each_vcpu ( d, v )
> -        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
> +    {
> +        cpumask_and(&online_affinity, v->cpu_affinity, online);
> +        cpumask_or(&cpumask, &cpumask, &online_affinity);
> +    }
>  
>      for_each_online_node ( node )
>          if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) ) 

Is there any possibility that the addition of the cpumask_and clause
could result in the empty set?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:09:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpHld-0008L6-Tl; Mon, 23 Jan 2012 11:08:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RpHlc-0008Kn-H4
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:08:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327316926!9462623!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 17958 invoked from network); 23 Jan 2012 11:08:46 -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; 23 Jan 2012 11:08:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 11:10:23 +0000
Message-Id: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 11:08:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

x86's vMCE implementation lets a guest know of as many MCE reporting
banks as there are in the host. While a PV guest could be expected to
deal with this number changing (particularly decreasing) during migration
(not currently handled anywhere afaict), for HVM guests this is certainly
wrong.

At least to me it isn't, however, clear how to properly handle this. The
easiest would appear to be to save and restore the number of banks
the guest was made believe it can access, making vmce_{rd,wr}msr()
silently tolerate accesses between the host and guest values.

Any thoughts appreciated,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:09:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpHld-0008L6-Tl; Mon, 23 Jan 2012 11:08:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RpHlc-0008Kn-H4
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:08:52 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327316926!9462623!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 17958 invoked from network); 23 Jan 2012 11:08:46 -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; 23 Jan 2012 11:08:46 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 11:10:23 +0000
Message-Id: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 11:08:45 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>
Subject: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

x86's vMCE implementation lets a guest know of as many MCE reporting
banks as there are in the host. While a PV guest could be expected to
deal with this number changing (particularly decreasing) during migration
(not currently handled anywhere afaict), for HVM guests this is certainly
wrong.

At least to me it isn't, however, clear how to properly handle this. The
easiest would appear to be to save and restore the number of banks
the guest was made believe it can access, making vmce_{rd,wr}msr()
silently tolerate accesses between the host and guest values.

Any thoughts appreciated,
Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:15:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHs2-00006u-Px; Mon, 23 Jan 2012 11:15:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RpHs1-00006i-AG; Mon, 23 Jan 2012 11:15:29 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327317196!49673384!1
X-Originating-IP: [209.85.210.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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 758 invoked from network); 23 Jan 2012 11:13:17 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:13:17 -0000
Received: by iaeh11 with SMTP id h11so19178876iae.30
	for <multiple recipients>; Mon, 23 Jan 2012 03:15: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=iovRpu8qE9e2+I+wIHiM8RfoDafK1/pRqeD8O+mnJsM=;
	b=B5yPEtzpyQJsA5wG84U5qo50DiKzcaObAdxX79Qt7uVydbdRXvDx3g00tvhvOLS750
	fsdMZvBk4EItX95hXpowWu+SVl1gK8DRw4gaaSrud/a5nSjPosVsj+XRLH65vQ1YRGQl
	xyy4W+MOTvwV/5eJMgrLP9WZH9Ttb3rvtJQRs=
MIME-Version: 1.0
Received: by 10.50.76.225 with SMTP id n1mr9494452igw.11.1327317325010; Mon,
	23 Jan 2012 03:15:25 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 23 Jan 2012 03:15:24 -0800 (PST)
In-Reply-To: <3B7B9131A63345CCB34B508E3E4F3507@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
Date: Mon, 23 Jan 2012 12:15:24 +0100
Message-ID: <CAFoWEVN2F3v_mXUs2wvnjxP1Qu9mSiVYAwgPOUoAjYDXf6iXaA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6710478925364209206=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6710478925364209206==
Content-Type: multipart/alternative; boundary=e89a8f3ba4e5a9574704b730253d

--e89a8f3ba4e5a9574704b730253d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Alexander,

I agree, a manual would be great.

It would make newcomers, like myself, a little bit more comfortable with
Xen.

I think that the first step would be that everyone who has had success with
VGA passthru should add their hardware setup and xen/kernel versions to
the  http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters wiki
page, or perhaps we start a new page in the wiki with information on how to
use particular graphics cards (i.e. how to patch xen to get them working),
and this page can list success stories.


Regards

Sandi




On Fri, Jan 20, 2012 at 7:53 PM, Likarpenkov Alexander
<al@ohosting.org.ua>wrote:

> Please make a manual
> or let's together make
>
> =D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=
=B4=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=
=8F 2012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB=D0=B8:
>
> SR> Pasi,
>
> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
> SR> CPU.
>
> SR> Have you managed to pass your gpu through to the domU?
>
> SR> Regards
>
> SR> Sandi
> SR> On Jan 20, 2012 4:47 PM, "Pasi K=C3=A4rkk=C3=A4inen" <pasik@iki.fi> w=
rote:
>
> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> ??>>>    Hello,
> ??>>>    I have spent a lot of time trying to get gfx passthru working on
> ??>>> my
> ??>> system
> ??>>>    without success.
> ??>>>    I looked onto my hardware capabilities again to make sure that i=
t
> ??>>> does   support VT-d and I am not too sure that it does fully.   My
> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
> chipset
> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
> ??>>> supporting VT-x, no
> ??>> mention of
> ??>>>    VT-d at [1]ark.intel.com)
> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
> ??>>> AND
> ??>> CPU
> ??>>>    need to support VT-d.
> ??>>>    What confuses me is, why is the 55x0 chipset listed there if non=
e
> ??>>> of
> ??>> the
> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
> ??>>> option,
> ??>> only
> ??>>>    VT-x.
> ??>>>
>
>
>

--e89a8f3ba4e5a9574704b730253d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Alexander,<div><br></div><div>I agree, a manual would be great.</div><div><=
br></div><div>It would make newcomers, like myself, a little bit more=C2=A0=
comfortable=C2=A0with Xen.</div><div><br></div><div>I think that the first =
step would be that everyone who has had success with VGA passthru should ad=
d their hardware setup and xen/kernel versions to the=C2=A0
<a href=3D"http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters">ht=
tp://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters</a>=C2=A0wiki pa=
ge, or perhaps we start a new page in the wiki with information on how to u=
se particular graphics cards (i.e. how to patch xen to get them working), a=
nd this page can list success stories.</div>
<div><br></div><div><br></div><div>Regards</div><div><br></div><div>Sandi</=
div><div><br></div><div><br></div><div><br><br><div class=3D"gmail_quote">O=
n Fri, Jan 20, 2012 at 7:53 PM, Likarpenkov Alexander <span dir=3D"ltr">&lt=
;<a href=3D"mailto:al@ohosting.org.ua">al@ohosting.org.ua</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Please make a manual<br>
or let&#39;s together make<br>
<br>
=D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=B4=
=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2=
012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB=D0=B8:<br>
<br>
SR&gt; Pasi,<br>
<br>
SR&gt; I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e<br>
SR&gt; CPU.<br>
<br>
SR&gt; Have you managed to pass your gpu through to the domU?<br>
<br>
SR&gt; Regards<br>
<br>
SR&gt; Sandi<br>
SR&gt; On Jan 20, 2012 4:47 PM, &quot;Pasi K=C3=A4rkk=C3=A4inen&quot; &lt;<=
a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote=
:<br>
<br>
??&gt;&gt; On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Hello,<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I have spent a lot of time trying to get gfx pa=
ssthru working on<br>
??&gt;&gt;&gt; my<br>
??&gt;&gt; system<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0without success.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I looked onto my hardware capabilities again to=
 make sure that it<br>
??&gt;&gt;&gt; does =C2=A0 support VT-d and I am not too sure that it does =
fully. =C2=A0 My<br>
??&gt;&gt;&gt; hardware is as follows: =C2=A0 - Supermicro X8DTH-6F motherb=
oard (5520 chipset<br>
??&gt;&gt;&gt; which supports VT-d) =C2=A0 - single Xeon X5650 CPU (which i=
s listed as<br>
??&gt;&gt;&gt; supporting VT-x, no<br>
??&gt;&gt; mention of<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-d at [1]<a href=3D"http://ark.intel.com" tar=
get=3D"_blank">ark.intel.com</a>)<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Now, according to the [2]VTdHowTo, the motherbo=
ard BIOS, chipset<br>
??&gt;&gt;&gt; AND<br>
??&gt;&gt; CPU<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0need to support VT-d.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
??&gt;&gt;&gt; of<br>
??&gt;&gt; the<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature<br>
??&gt;&gt;&gt; option,<br>
??&gt;&gt; only<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-x.<br>
??&gt;&gt;&gt;<br>
<br>
<br>
</blockquote></div><br></div>

--e89a8f3ba4e5a9574704b730253d--


--===============6710478925364209206==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6710478925364209206==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:15:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:15:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpHs2-00006u-Px; Mon, 23 Jan 2012 11:15:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RpHs1-00006i-AG; Mon, 23 Jan 2012 11:15:29 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327317196!49673384!1
X-Originating-IP: [209.85.210.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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 758 invoked from network); 23 Jan 2012 11:13:17 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:13:17 -0000
Received: by iaeh11 with SMTP id h11so19178876iae.30
	for <multiple recipients>; Mon, 23 Jan 2012 03:15: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=iovRpu8qE9e2+I+wIHiM8RfoDafK1/pRqeD8O+mnJsM=;
	b=B5yPEtzpyQJsA5wG84U5qo50DiKzcaObAdxX79Qt7uVydbdRXvDx3g00tvhvOLS750
	fsdMZvBk4EItX95hXpowWu+SVl1gK8DRw4gaaSrud/a5nSjPosVsj+XRLH65vQ1YRGQl
	xyy4W+MOTvwV/5eJMgrLP9WZH9Ttb3rvtJQRs=
MIME-Version: 1.0
Received: by 10.50.76.225 with SMTP id n1mr9494452igw.11.1327317325010; Mon,
	23 Jan 2012 03:15:25 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 23 Jan 2012 03:15:24 -0800 (PST)
In-Reply-To: <3B7B9131A63345CCB34B508E3E4F3507@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
Date: Mon, 23 Jan 2012 12:15:24 +0100
Message-ID: <CAFoWEVN2F3v_mXUs2wvnjxP1Qu9mSiVYAwgPOUoAjYDXf6iXaA@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6710478925364209206=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6710478925364209206==
Content-Type: multipart/alternative; boundary=e89a8f3ba4e5a9574704b730253d

--e89a8f3ba4e5a9574704b730253d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Alexander,

I agree, a manual would be great.

It would make newcomers, like myself, a little bit more comfortable with
Xen.

I think that the first step would be that everyone who has had success with
VGA passthru should add their hardware setup and xen/kernel versions to
the  http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters wiki
page, or perhaps we start a new page in the wiki with information on how to
use particular graphics cards (i.e. how to patch xen to get them working),
and this page can list success stories.


Regards

Sandi




On Fri, Jan 20, 2012 at 7:53 PM, Likarpenkov Alexander
<al@ohosting.org.ua>wrote:

> Please make a manual
> or let's together make
>
> =D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=
=B4=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=
=8F 2012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB=D0=B8:
>
> SR> Pasi,
>
> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for the
> SR> CPU.
>
> SR> Have you managed to pass your gpu through to the domU?
>
> SR> Regards
>
> SR> Sandi
> SR> On Jan 20, 2012 4:47 PM, "Pasi K=C3=A4rkk=C3=A4inen" <pasik@iki.fi> w=
rote:
>
> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> ??>>>    Hello,
> ??>>>    I have spent a lot of time trying to get gfx passthru working on
> ??>>> my
> ??>> system
> ??>>>    without success.
> ??>>>    I looked onto my hardware capabilities again to make sure that i=
t
> ??>>> does   support VT-d and I am not too sure that it does fully.   My
> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
> chipset
> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
> ??>>> supporting VT-x, no
> ??>> mention of
> ??>>>    VT-d at [1]ark.intel.com)
> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipset
> ??>>> AND
> ??>> CPU
> ??>>>    need to support VT-d.
> ??>>>    What confuses me is, why is the 55x0 chipset listed there if non=
e
> ??>>> of
> ??>> the
> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
> ??>>> option,
> ??>> only
> ??>>>    VT-x.
> ??>>>
>
>
>

--e89a8f3ba4e5a9574704b730253d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Alexander,<div><br></div><div>I agree, a manual would be great.</div><div><=
br></div><div>It would make newcomers, like myself, a little bit more=C2=A0=
comfortable=C2=A0with Xen.</div><div><br></div><div>I think that the first =
step would be that everyone who has had success with VGA passthru should ad=
d their hardware setup and xen/kernel versions to the=C2=A0
<a href=3D"http://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters">ht=
tp://wiki.xen.org/wiki/Xen_VGA_Passthrough_Tested_Adapters</a>=C2=A0wiki pa=
ge, or perhaps we start a new page in the wiki with information on how to u=
se particular graphics cards (i.e. how to patch xen to get them working), a=
nd this page can list success stories.</div>
<div><br></div><div><br></div><div>Regards</div><div><br></div><div>Sandi</=
div><div><br></div><div><br></div><div><br><br><div class=3D"gmail_quote">O=
n Fri, Jan 20, 2012 at 7:53 PM, Likarpenkov Alexander <span dir=3D"ltr">&lt=
;<a href=3D"mailto:al@ohosting.org.ua">al@ohosting.org.ua</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Please make a manual<br>
or let&#39;s together make<br>
<br>
=D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=B4=
=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2=
012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB=D0=B8:<br>
<br>
SR&gt; Pasi,<br>
<br>
SR&gt; I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e<br>
SR&gt; CPU.<br>
<br>
SR&gt; Have you managed to pass your gpu through to the domU?<br>
<br>
SR&gt; Regards<br>
<br>
SR&gt; Sandi<br>
SR&gt; On Jan 20, 2012 4:47 PM, &quot;Pasi K=C3=A4rkk=C3=A4inen&quot; &lt;<=
a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote=
:<br>
<br>
??&gt;&gt; On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Hello,<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I have spent a lot of time trying to get gfx pa=
ssthru working on<br>
??&gt;&gt;&gt; my<br>
??&gt;&gt; system<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0without success.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I looked onto my hardware capabilities again to=
 make sure that it<br>
??&gt;&gt;&gt; does =C2=A0 support VT-d and I am not too sure that it does =
fully. =C2=A0 My<br>
??&gt;&gt;&gt; hardware is as follows: =C2=A0 - Supermicro X8DTH-6F motherb=
oard (5520 chipset<br>
??&gt;&gt;&gt; which supports VT-d) =C2=A0 - single Xeon X5650 CPU (which i=
s listed as<br>
??&gt;&gt;&gt; supporting VT-x, no<br>
??&gt;&gt; mention of<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-d at [1]<a href=3D"http://ark.intel.com" tar=
get=3D"_blank">ark.intel.com</a>)<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Now, according to the [2]VTdHowTo, the motherbo=
ard BIOS, chipset<br>
??&gt;&gt;&gt; AND<br>
??&gt;&gt; CPU<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0need to support VT-d.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
??&gt;&gt;&gt; of<br>
??&gt;&gt; the<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature<br>
??&gt;&gt;&gt; option,<br>
??&gt;&gt; only<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-x.<br>
??&gt;&gt;&gt;<br>
<br>
<br>
</blockquote></div><br></div>

--e89a8f3ba4e5a9574704b730253d--


--===============6710478925364209206==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6710478925364209206==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:26:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpI27-0000iG-RR; Mon, 23 Jan 2012 11:25:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RpI26-0000i8-7P; Mon, 23 Jan 2012 11:25:54 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327317945!2204865!1
X-Originating-IP: [209.85.210.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 9073 invoked from network); 23 Jan 2012 11:25:47 -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;
	23 Jan 2012 11:25:47 -0000
Received: by iaeh11 with SMTP id h11so19220165iae.30
	for <multiple recipients>; Mon, 23 Jan 2012 03:25: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=/QaO0V7k7YAeOoepyhBhB74GxJU3jPl+XfEfOzWgLYQ=;
	b=qhMlOKqgaI8Nm+buHgLxXHN8A0U+9EP4T/Z8fyB5ANx7Fvb5uie9PTTWPpNnaAqTrP
	UIFrBXpnZjDWcN7nDhi/HOou2jeBtlMBMf9wXP/MR2vkQYP9L7iodn/IPRX6xY6YA/SO
	DpogpTiKkVor+2gjyUHeUbbjrrqtGpAL7fsHI=
MIME-Version: 1.0
Received: by 10.42.144.69 with SMTP id a5mr7594849icv.45.1327317945684; Mon,
	23 Jan 2012 03:25:45 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 23 Jan 2012 03:25:45 -0800 (PST)
In-Reply-To: <CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
Date: Mon, 23 Jan 2012 12:25:45 +0100
Message-ID: <CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: chris <tknchris@gmail.com>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7843549121169396749=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7843549121169396749==
Content-Type: multipart/alternative; boundary=90e6ba1efbaca8142c04b7304a05

--90e6ba1efbaca8142c04b7304a05
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Chris,

Yeah, I guess xen has generally been focused on the server end.

But I see some good uses for desktop virtualization too. I personally want
this so that I can have a file server (zfs based) and a Windows desktop (as
all the tools I use in my job are mostly only supported in MS OS) in one
machine. Saves me money and space.

Regards

Sandi

On Fri, Jan 20, 2012 at 8:24 PM, chris <tknchris@gmail.com> wrote:

> I'm really surprised this doesnt get more attention. For as long as I've
> been on this list, this feature has been mentioned so many times I would
> think that getting this working would be a huge feature that would make t=
he
> product even better. I have only seen the occasional success with
> experimental patches etc, despite this being talked about for years.
>
> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander <al@ohosting.org.u=
a
> > wrote:
>
>> Please make a manual
>> or let's together make
>>
>> =D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=
=B4=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=
=8F 2012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB=D0=B8:
>>
>> SR> Pasi,
>>
>> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e
>> SR> CPU.
>>
>> SR> Have you managed to pass your gpu through to the domU?
>>
>> SR> Regards
>>
>> SR> Sandi
>> SR> On Jan 20, 2012 4:47 PM, "Pasi K=C3=A4rkk=C3=A4inen" <pasik@iki.fi> =
wrote:
>>
>> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>> ??>>>    Hello,
>> ??>>>    I have spent a lot of time trying to get gfx passthru working o=
n
>> ??>>> my
>> ??>> system
>> ??>>>    without success.
>> ??>>>    I looked onto my hardware capabilities again to make sure that =
it
>> ??>>> does   support VT-d and I am not too sure that it does fully.   My
>> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
>> chipset
>> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
>> ??>>> supporting VT-x, no
>> ??>> mention of
>> ??>>>    VT-d at [1]ark.intel.com)
>> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipse=
t
>> ??>>> AND
>> ??>> CPU
>> ??>>>    need to support VT-d.
>> ??>>>    What confuses me is, why is the 55x0 chipset listed there if no=
ne
>> ??>>> of
>> ??>> the
>> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
>> ??>>> option,
>> ??>> only
>> ??>>>    VT-x.
>> ??>>>
>>
>>
>>
>> ______________________________**_________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-us=
ers>
>
>
>

--90e6ba1efbaca8142c04b7304a05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Chris,<div><br></div><div>Yeah, I guess xen has generally been focused on t=
he server end.</div><div><br></div><div>But I see some good uses for deskto=
p virtualization too. I personally want this so that I can have a file serv=
er (zfs based) and a Windows desktop (as all the tools I use in my job are =
mostly only supported in MS OS) in one machine. Saves me money and space.</=
div>
<div><br></div><div>Regards<br><br>Sandi<br><br><div class=3D"gmail_quote">=
On Fri, Jan 20, 2012 at 8:24 PM, chris <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tknchris@gmail.com">tknchris@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
I&#39;m really surprised this doesnt get more attention. For as long as I&#=
39;ve been on this list, this feature has been mentioned so many times I wo=
uld think that getting this working would be a huge feature that would make=
 the product even better. I have only seen the occasional success with expe=
rimental patches etc, despite this being talked about for years.<br>

<br><div class=3D"gmail_quote"><div><div class=3D"h5">On Fri, Jan 20, 2012 =
at 1:53 PM, Likarpenkov Alexander <span dir=3D"ltr">&lt;<a href=3D"mailto:a=
l@ohosting.org.ua" target=3D"_blank">al@ohosting.org.ua</a>&gt;</span> wrot=
e:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">
Please make a manual<br>
or let&#39;s together make<br>
<br>
=D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=B4=
=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2=
012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB=D0=B8:<br>
<br>
SR&gt; Pasi,<br>
<br>
SR&gt; I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e<br>
SR&gt; CPU.<br>
<br>
SR&gt; Have you managed to pass your gpu through to the domU?<br>
<br>
SR&gt; Regards<br>
<br>
SR&gt; Sandi<br>
SR&gt; On Jan 20, 2012 4:47 PM, &quot;Pasi K=C3=A4rkk=C3=A4inen&quot; &lt;<=
a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote=
:<br>
<br>
??&gt;&gt; On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Hello,<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I have spent a lot of time trying to get gfx pa=
ssthru working on<br>
??&gt;&gt;&gt; my<br>
??&gt;&gt; system<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0without success.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I looked onto my hardware capabilities again to=
 make sure that it<br>
??&gt;&gt;&gt; does =C2=A0 support VT-d and I am not too sure that it does =
fully. =C2=A0 My<br>
??&gt;&gt;&gt; hardware is as follows: =C2=A0 - Supermicro X8DTH-6F motherb=
oard (5520 chipset<br>
??&gt;&gt;&gt; which supports VT-d) =C2=A0 - single Xeon X5650 CPU (which i=
s listed as<br>
??&gt;&gt;&gt; supporting VT-x, no<br>
??&gt;&gt; mention of<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-d at [1]<a href=3D"http://ark.intel.com" tar=
get=3D"_blank">ark.intel.com</a>)<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Now, according to the [2]VTdHowTo, the motherbo=
ard BIOS, chipset<br>
??&gt;&gt;&gt; AND<br>
??&gt;&gt; CPU<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0need to support VT-d.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
??&gt;&gt;&gt; of<br>
??&gt;&gt; the<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature<br>
??&gt;&gt;&gt; option,<br>
??&gt;&gt; only<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-x.<br>
??&gt;&gt;&gt;<br>
<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xensource.com" target=3D"_blank">Xen-user=
s@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-users" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-users</a></blockquote></div><br>
</blockquote></div><br></div>

--90e6ba1efbaca8142c04b7304a05--


--===============7843549121169396749==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7843549121169396749==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:26:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpI27-0000iG-RR; Mon, 23 Jan 2012 11:25:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RpI26-0000i8-7P; Mon, 23 Jan 2012 11:25:54 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327317945!2204865!1
X-Originating-IP: [209.85.210.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 9073 invoked from network); 23 Jan 2012 11:25:47 -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;
	23 Jan 2012 11:25:47 -0000
Received: by iaeh11 with SMTP id h11so19220165iae.30
	for <multiple recipients>; Mon, 23 Jan 2012 03:25: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=/QaO0V7k7YAeOoepyhBhB74GxJU3jPl+XfEfOzWgLYQ=;
	b=qhMlOKqgaI8Nm+buHgLxXHN8A0U+9EP4T/Z8fyB5ANx7Fvb5uie9PTTWPpNnaAqTrP
	UIFrBXpnZjDWcN7nDhi/HOou2jeBtlMBMf9wXP/MR2vkQYP9L7iodn/IPRX6xY6YA/SO
	DpogpTiKkVor+2gjyUHeUbbjrrqtGpAL7fsHI=
MIME-Version: 1.0
Received: by 10.42.144.69 with SMTP id a5mr7594849icv.45.1327317945684; Mon,
	23 Jan 2012 03:25:45 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 23 Jan 2012 03:25:45 -0800 (PST)
In-Reply-To: <CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
Date: Mon, 23 Jan 2012 12:25:45 +0100
Message-ID: <CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: chris <tknchris@gmail.com>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7843549121169396749=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7843549121169396749==
Content-Type: multipart/alternative; boundary=90e6ba1efbaca8142c04b7304a05

--90e6ba1efbaca8142c04b7304a05
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Chris,

Yeah, I guess xen has generally been focused on the server end.

But I see some good uses for desktop virtualization too. I personally want
this so that I can have a file server (zfs based) and a Windows desktop (as
all the tools I use in my job are mostly only supported in MS OS) in one
machine. Saves me money and space.

Regards

Sandi

On Fri, Jan 20, 2012 at 8:24 PM, chris <tknchris@gmail.com> wrote:

> I'm really surprised this doesnt get more attention. For as long as I've
> been on this list, this feature has been mentioned so many times I would
> think that getting this working would be a huge feature that would make t=
he
> product even better. I have only seen the occasional success with
> experimental patches etc, despite this being talked about for years.
>
> On Fri, Jan 20, 2012 at 1:53 PM, Likarpenkov Alexander <al@ohosting.org.u=
a
> > wrote:
>
>> Please make a manual
>> or let's together make
>>
>> =D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=
=B4=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=
=8F 2012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=
=B8=D1=81=D0=B0=D0=BB=D0=B8:
>>
>> SR> Pasi,
>>
>> SR> I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e
>> SR> CPU.
>>
>> SR> Have you managed to pass your gpu through to the domU?
>>
>> SR> Regards
>>
>> SR> Sandi
>> SR> On Jan 20, 2012 4:47 PM, "Pasi K=C3=A4rkk=C3=A4inen" <pasik@iki.fi> =
wrote:
>>
>> ??>> On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
>> ??>>>    Hello,
>> ??>>>    I have spent a lot of time trying to get gfx passthru working o=
n
>> ??>>> my
>> ??>> system
>> ??>>>    without success.
>> ??>>>    I looked onto my hardware capabilities again to make sure that =
it
>> ??>>> does   support VT-d and I am not too sure that it does fully.   My
>> ??>>> hardware is as follows:   - Supermicro X8DTH-6F motherboard (5520
>> chipset
>> ??>>> which supports VT-d)   - single Xeon X5650 CPU (which is listed as
>> ??>>> supporting VT-x, no
>> ??>> mention of
>> ??>>>    VT-d at [1]ark.intel.com)
>> ??>>>    Now, according to the [2]VTdHowTo, the motherboard BIOS, chipse=
t
>> ??>>> AND
>> ??>> CPU
>> ??>>>    need to support VT-d.
>> ??>>>    What confuses me is, why is the 55x0 chipset listed there if no=
ne
>> ??>>> of
>> ??>> the
>> ??>>>    CPU's supported, that I know of, dont have the VT-d feature
>> ??>>> option,
>> ??>> only
>> ??>>>    VT-x.
>> ??>>>
>>
>>
>>
>> ______________________________**_________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/**xen-users<http://lists.xensource.com/xen-us=
ers>
>
>
>

--90e6ba1efbaca8142c04b7304a05
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Chris,<div><br></div><div>Yeah, I guess xen has generally been focused on t=
he server end.</div><div><br></div><div>But I see some good uses for deskto=
p virtualization too. I personally want this so that I can have a file serv=
er (zfs based) and a Windows desktop (as all the tools I use in my job are =
mostly only supported in MS OS) in one machine. Saves me money and space.</=
div>
<div><br></div><div>Regards<br><br>Sandi<br><br><div class=3D"gmail_quote">=
On Fri, Jan 20, 2012 at 8:24 PM, chris <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:tknchris@gmail.com">tknchris@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
I&#39;m really surprised this doesnt get more attention. For as long as I&#=
39;ve been on this list, this feature has been mentioned so many times I wo=
uld think that getting this working would be a huge feature that would make=
 the product even better. I have only seen the occasional success with expe=
rimental patches etc, despite this being talked about for years.<br>

<br><div class=3D"gmail_quote"><div><div class=3D"h5">On Fri, Jan 20, 2012 =
at 1:53 PM, Likarpenkov Alexander <span dir=3D"ltr">&lt;<a href=3D"mailto:a=
l@ohosting.org.ua" target=3D"_blank">al@ohosting.org.ua</a>&gt;</span> wrot=
e:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">
Please make a manual<br>
or let&#39;s together make<br>
<br>
=D0=92 =D0=BF=D1=8F=D1=82=D0=BD=D0=B8=D1=86=D1=83, =D0=B4=D0=B2=D0=B0=D0=B4=
=D1=86=D0=B0=D1=82=D0=BE=D0=B3=D0=BE =D1=8F=D0=BD=D0=B2=D0=B0=D1=80=D1=8F 2=
012 =D0=B3=D0=BE=D0=B4=D0=B0, =D0=B2 18:49:20 =D0=92=D1=8B =D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB=D0=B8:<br>
<br>
SR&gt; Pasi,<br>
<br>
SR&gt; I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e<br>
SR&gt; CPU.<br>
<br>
SR&gt; Have you managed to pass your gpu through to the domU?<br>
<br>
SR&gt; Regards<br>
<br>
SR&gt; Sandi<br>
SR&gt; On Jan 20, 2012 4:47 PM, &quot;Pasi K=C3=A4rkk=C3=A4inen&quot; &lt;<=
a href=3D"mailto:pasik@iki.fi" target=3D"_blank">pasik@iki.fi</a>&gt; wrote=
:<br>
<br>
??&gt;&gt; On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Hello,<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I have spent a lot of time trying to get gfx pa=
ssthru working on<br>
??&gt;&gt;&gt; my<br>
??&gt;&gt; system<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0without success.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0I looked onto my hardware capabilities again to=
 make sure that it<br>
??&gt;&gt;&gt; does =C2=A0 support VT-d and I am not too sure that it does =
fully. =C2=A0 My<br>
??&gt;&gt;&gt; hardware is as follows: =C2=A0 - Supermicro X8DTH-6F motherb=
oard (5520 chipset<br>
??&gt;&gt;&gt; which supports VT-d) =C2=A0 - single Xeon X5650 CPU (which i=
s listed as<br>
??&gt;&gt;&gt; supporting VT-x, no<br>
??&gt;&gt; mention of<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-d at [1]<a href=3D"http://ark.intel.com" tar=
get=3D"_blank">ark.intel.com</a>)<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0Now, according to the [2]VTdHowTo, the motherbo=
ard BIOS, chipset<br>
??&gt;&gt;&gt; AND<br>
??&gt;&gt; CPU<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0need to support VT-d.<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
??&gt;&gt;&gt; of<br>
??&gt;&gt; the<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature<br>
??&gt;&gt;&gt; option,<br>
??&gt;&gt; only<br>
??&gt;&gt;&gt; =C2=A0 =C2=A0VT-x.<br>
??&gt;&gt;&gt;<br>
<br>
<br>
<br></div></div>
______________________________<u></u>_________________<br>
Xen-users mailing list<br>
<a href=3D"mailto:Xen-users@lists.xensource.com" target=3D"_blank">Xen-user=
s@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-users" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-users</a></blockquote></div><br>
</blockquote></div><br></div>

--90e6ba1efbaca8142c04b7304a05--


--===============7843549121169396749==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7843549121169396749==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:28:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:28:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpI4G-0000y1-33; Mon, 23 Jan 2012 11:28: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 1RpI4E-0000xN-Kb
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:28:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327318080!6071771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22515 invoked from network); 23 Jan 2012 11:28:00 -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;
	23 Jan 2012 11:28:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10210382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:27:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 11:27:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Mon, 23 Jan 2012 11:27:56 +0000
In-Reply-To: <1327176409.25269.140661026313477@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327318076.24561.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-01-21 at 20:06 +0000, erin.balid@inoutbox.com wrote:
> The Guest cfg file I'm using for testing is:
> 
> cat test.cfg
>  name='test'
>  builder='linux'
>  bootloader='/usr/bin/pygrub'
>  disk=['phy:/dev/XenVols/test,xvda,w']
>  vif=[mac=00:16:3e:12:34:01, bridge=br0  , vifname=vifBR']

ISTRT xl had a bug at one point where it would fail to strip whitespace
in the network KVP lists. i.e. the above ended up expecting to find a
bridge named "br0  ". Can you try without the spaces please?

(hmm, I wonder if that was ever fixed. I appear to have the following
tucked away in my queue. I suspect I got sidetracked with never getting
round to fixing it properly instead of pushing the bandaid)

8<--------------------------------------------------

xl: strip whitespace from vif key/values when parsing

Otherwise we can end up with bridge = "br0   " etc which is usually not
what is desired.

This whole parser could do with a rewrite (perhaps a generic KVP parser
in flex would be useful) but this quick fix appears to suffice for now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


diff -r 3c6eaf62996d -r 31eee4e06a20 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 10 07:56:40 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 10 08:04:16 2011 +0000
@@ -515,6 +515,20 @@ static void parse_disk_config(XLU_Config
     parse_disk_config_multistring(config, 1, &spec, disk);
 }
 
+/*
+ * Duplicate s stripping leading and trailing whitespace.
+ * Destroys contents of s.
+ */
+static char *strdup_ws(char *s)
+{
+    char *e = s + strlen(s) - 1;
+    while (*s == ' ')
+        s++;
+    while (*e == ' ')
+        *(e--) = '\0';
+    return strndup(s, e-s+1);
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -758,7 +772,7 @@ static void parse_config_data(const char
         while ((buf = xlu_cfg_get_listitem (nics, d_config->num_vifs)) != NULL) {
             libxl_device_nic *nic;
             char *buf2 = strdup(buf);
-            char *p, *p2;
+            char *p, *p2, *p3;
 
             d_config->vifs = (libxl_device_nic *) realloc(d_config->vifs, sizeof (libxl_device_nic) * (d_config->num_vifs+1));
             nic = d_config->vifs + d_config->num_vifs;
@@ -779,6 +793,9 @@ static void parse_config_data(const char
                 if ((p2 = strchr(p, '=')) == NULL)
                     break;
                 *p2 = '\0';
+                p3 = p2 - 1;
+                while (*p3 == ' ' && p3 > p)
+                    *(p3--) = '\0';
                 if (!strcmp(p, "model")) {
                     free(nic->model);
                     nic->model = strdup(p2 + 1);
@@ -802,8 +820,8 @@ static void parse_config_data(const char
                     *(p3 + 2) = '\0';
                     nic->mac[5] = strtol(p3, NULL, 16);
                 } else if (!strcmp(p, "bridge")) {
                     free(nic->bridge);
-                    nic->bridge = strdup(p2 + 1);
+                    nic->bridge = strdup_ws(p2 + 1);
                 } else if (!strcmp(p, "type")) {
                     if (!strcmp(p2 + 1, "ioemu"))
                         nic->nictype = LIBXL_NIC_TYPE_IOEMU;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:28:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:28:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpI4G-0000y1-33; Mon, 23 Jan 2012 11:28: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 1RpI4E-0000xN-Kb
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:28:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327318080!6071771!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22515 invoked from network); 23 Jan 2012 11:28:00 -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;
	23 Jan 2012 11:28:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10210382"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:27:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 11:27:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Mon, 23 Jan 2012 11:27:56 +0000
In-Reply-To: <1327176409.25269.140661026313477@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327318076.24561.63.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-01-21 at 20:06 +0000, erin.balid@inoutbox.com wrote:
> The Guest cfg file I'm using for testing is:
> 
> cat test.cfg
>  name='test'
>  builder='linux'
>  bootloader='/usr/bin/pygrub'
>  disk=['phy:/dev/XenVols/test,xvda,w']
>  vif=[mac=00:16:3e:12:34:01, bridge=br0  , vifname=vifBR']

ISTRT xl had a bug at one point where it would fail to strip whitespace
in the network KVP lists. i.e. the above ended up expecting to find a
bridge named "br0  ". Can you try without the spaces please?

(hmm, I wonder if that was ever fixed. I appear to have the following
tucked away in my queue. I suspect I got sidetracked with never getting
round to fixing it properly instead of pushing the bandaid)

8<--------------------------------------------------

xl: strip whitespace from vif key/values when parsing

Otherwise we can end up with bridge = "br0   " etc which is usually not
what is desired.

This whole parser could do with a rewrite (perhaps a generic KVP parser
in flex would be useful) but this quick fix appears to suffice for now.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>


diff -r 3c6eaf62996d -r 31eee4e06a20 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Thu Nov 10 07:56:40 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Nov 10 08:04:16 2011 +0000
@@ -515,6 +515,20 @@ static void parse_disk_config(XLU_Config
     parse_disk_config_multistring(config, 1, &spec, disk);
 }
 
+/*
+ * Duplicate s stripping leading and trailing whitespace.
+ * Destroys contents of s.
+ */
+static char *strdup_ws(char *s)
+{
+    char *e = s + strlen(s) - 1;
+    while (*s == ' ')
+        s++;
+    while (*e == ' ')
+        *(e--) = '\0';
+    return strndup(s, e-s+1);
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -758,7 +772,7 @@ static void parse_config_data(const char
         while ((buf = xlu_cfg_get_listitem (nics, d_config->num_vifs)) != NULL) {
             libxl_device_nic *nic;
             char *buf2 = strdup(buf);
-            char *p, *p2;
+            char *p, *p2, *p3;
 
             d_config->vifs = (libxl_device_nic *) realloc(d_config->vifs, sizeof (libxl_device_nic) * (d_config->num_vifs+1));
             nic = d_config->vifs + d_config->num_vifs;
@@ -779,6 +793,9 @@ static void parse_config_data(const char
                 if ((p2 = strchr(p, '=')) == NULL)
                     break;
                 *p2 = '\0';
+                p3 = p2 - 1;
+                while (*p3 == ' ' && p3 > p)
+                    *(p3--) = '\0';
                 if (!strcmp(p, "model")) {
                     free(nic->model);
                     nic->model = strdup(p2 + 1);
@@ -802,8 +820,8 @@ static void parse_config_data(const char
                     *(p3 + 2) = '\0';
                     nic->mac[5] = strtol(p3, NULL, 16);
                 } else if (!strcmp(p, "bridge")) {
                     free(nic->bridge);
-                    nic->bridge = strdup(p2 + 1);
+                    nic->bridge = strdup_ws(p2 + 1);
                 } else if (!strcmp(p, "type")) {
                     if (!strcmp(p2 + 1, "ioemu"))
                         nic->nictype = LIBXL_NIC_TYPE_IOEMU;




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:30:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpI6X-0001EH-MM; Mon, 23 Jan 2012 11:30:29 +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 1RpI6V-0001Dm-Nb
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:30:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327318213!11956588!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 23394 invoked from network); 23 Jan 2012 11:30:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:30:21 -0000
Received: by pbdx13 with SMTP id x13so2445986pbd.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 03:30: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=LCMPJsIfsjBUYycMyabgH2Z39tu+dgEwt8Bp4pJuUHY=;
	b=IqaHqu3UAKPhXDtImg6IsdJYyHkYNvh+4k7sHMAbUAxg5H4ODXd3hfKhk0DecnmZSo
	GnxmW1HkOox2L5pJ1bdvdfYjH5a5Q0RDXWpCzvKbWAjCfqsjgaU67gJMbOnGTC2Gy12u
	+CIuUI2PwMf9WPUVL/bsXUOivc5PVykG0eF5Y=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr21440432pbu.124.1327318207443; Mon,
	23 Jan 2012 03:30:07 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Mon, 23 Jan 2012 03:30:07 -0800 (PST)
In-Reply-To: <1327315626.24561.32.camel@zakaz.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 12:30:07 +0100
X-Google-Sender-Auth: bAq9Ma9Ek96wFxldmBOdh6RFxE8
Message-ID: <CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@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 \(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 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

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFR1
ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+IElhbiBD
YW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDogYWRkIHN1
cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+ID4gT24gVGh1LCAyMDExLTEyLTIyIGF0IDE2OjQxICsw
MDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiA+ID4gU29tZSBhdXRvZ29vIHN0dWZmIHdp
bGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRoZSB0b29scyBidWlsZC4gQ2FuIHlvdQo+PiA+ID4g
c2V0IHVwIHRoZSBiYXNpYyBzdHJ1Y3R1cmUgSWFuPwo+PiA+Cj4+ID4gSSdtIG5vdCBnb2luZyB0
byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+PiA+Cj4+ID4gV291bGQgaXQgYmUgc3Vm
ZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0b29scy9jaGVjayBjcmVhdGUgYQo+PiA+IGNv
bmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNrcz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBN
YWtlZmlsZSBtYWdpYwo+PiA+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+
Pgo+PiBGb3Igbm93LCBJIHRoaW5rIHdlIHNob3VsZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhl
IGNyaXRpY2FsIHBhdGggZm9yCj4+IFhlbiA0LjIuIMKgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxk
IHN3aXRjaCB0byBhdXRvY29uZiBJIHRoaW5rLiDCoChJCj4+IGRvbid0IGFwcHJvdmUgb2YgYXV0
b21ha2UuKQo+Cj4gSXQgc2VlbXMgdGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24g
dGhlIGF1dG9jb25mIHN0dWZmLiBDYW4gd2UKPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0
IHdlIGNhbiBzdXBwb3J0IHlhamwgMi4wIGluIFhlbiA0LjIgYW5kCj4gc3dpdGNoIHRvIGF1dG9j
b25mIGFmdGVyd2FyZHMgb3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRjaCB0bwo+
IGF1dG9jb25mIGZvciA0LjI/CgpUaGUgcHJvcG9zZWQgYXV0b2NvbmYgcGF0Y2ggaXMganVzdCBh
IGNvbnZlbmllbnQgcmVwbGFjZW1lbnQgZm9yCnRvb2xzL2NoZWNrIHNjcmlwdHMsIHdoaWNoIGFs
bG93cyB1cyB0byBnZW5lcmF0ZSBhIG1ha2VmaWxlIGFuZCBhCmhlYWRlciB3ZSBjYW4gaW5jbHVk
ZSB0byBrbm93IHRoZSBzeXN0ZW0gY2FwYWJpbGl0aWVzLCBub3RoaW5nIG1vcmUKd2FzIGFkZGVk
LgoKPiBJIGFwcHJlY2lhdGUgdGhlIGNvbmNlcm5zIGFib3V0IGNyaXRpY2FsIHBhdGggZm9yIDQu
Mi4gSSBwcmVzdW1lCj4gYXV0b2NvbmYgd291bGQgcmVxdWlyZSBtb3JlIHRoYW4ganVzdCBjaGVj
a2luZyBpbiB0aGUgcGF0Y2hlcywKPiBzcGVjaWZpY2FsbHkgSSdtIHRoaW5raW5nIG9mIHRoZSBh
dXRvbWF0ZWQgdGVzdCBzeXN0ZW0gdXBkYXRlIGFuZCBkb2NzLgoKRG9uJ3Qga25vdyBob3cgZGlm
ZmljdWx0IGl0IGlzIHRvIHVwZGF0ZSB0aGUgdGVzdCBiZWQgdG8gdXNlIHRoZSBuZXcKY29uZmln
dXJlIHNjcmlwdCwgaWRlYWxseSBpdCBzaG91bGQgb25seSByZXF1aXJlIGFkZGluZyAiLi9jb25m
aWd1cmUiCmJlZm9yZSBwZXJmb3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtu
b3cgaG93IHRoZSB0ZXN0IGJlZAp3b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mg
c29tZSBvcHRpb25zIHRvIGNvbmZpZ3VyZQpleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1lIHJl
c3VsdC4KCj4gT24gdGhlIG90aGVyIGhhbmQgUm9nZXIgcG9zdGVkIHYzIG9mIGhpcyBhdXRvY29u
ZiBzdXBwb3J0IHBhdGNoIGFuZAo+IGFsdGhvdWdoIEkgaGF2ZW4ndCBnb3Qgcm91bmQgdG8gcmV2
aWV3aW5nIGl0IHlldCAoc29ycnkpIHYyJ3MgcmV2aWV3IHdhcwo+IGdlbmVyYWxseSBwb3NpdGl2
ZS9taW5vciBsb29raW5nLgoKdjMgaXMgYmFzaWNhbGx5IGEgdjIgd2l0aCBhbGwgdGhlIG1lbnRp
b25lZCBmaXhlcyBhbmQgdGhlIG91dHB1dCBmcm9tCmF1dG9jb25mICYgYXV0b21ha2UsIHNvIHdl
IGNhbiB1c2UgdGhlIGNvbmZpZ3VyZSBzY3JpcHQgc3RyYWlnaHQgYXdheS4KCkFueXdheSwgdGhp
cyBwYXRjaCBmb3IgYWRkaW5nIHN1cHBvcnQgb2YgeWFqbCAyLjAgbmVlZHMgc29tZSByZXdvcmss
CmFjY29yZGluZyB0byB0aGUgY29tbWVudHMgbWFkZSBieSBJYW4gSmFja3Nvbiwgd2hpY2ggSSB3
aWxsIHRyeSB0byBkbwpiZWZvcmUgdGhlIGVuZCBvZiB0aGUgd2VlayAoc29ycnkgZm9yIHRoZSBk
ZWxheSwgYnV0IEknbSBxdWl0ZSBidXN5CnRoaXMgZGF5cykuCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:30:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:30:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpI6X-0001EH-MM; Mon, 23 Jan 2012 11:30:29 +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 1RpI6V-0001Dm-Nb
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:30:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327318213!11956588!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 23394 invoked from network); 23 Jan 2012 11:30:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:30:21 -0000
Received: by pbdx13 with SMTP id x13so2445986pbd.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 03:30: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=LCMPJsIfsjBUYycMyabgH2Z39tu+dgEwt8Bp4pJuUHY=;
	b=IqaHqu3UAKPhXDtImg6IsdJYyHkYNvh+4k7sHMAbUAxg5H4ODXd3hfKhk0DecnmZSo
	GnxmW1HkOox2L5pJ1bdvdfYjH5a5Q0RDXWpCzvKbWAjCfqsjgaU67gJMbOnGTC2Gy12u
	+CIuUI2PwMf9WPUVL/bsXUOivc5PVykG0eF5Y=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr21440432pbu.124.1327318207443; Mon,
	23 Jan 2012 03:30:07 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Mon, 23 Jan 2012 03:30:07 -0800 (PST)
In-Reply-To: <1327315626.24561.32.camel@zakaz.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 12:30:07 +0100
X-Google-Sender-Auth: bAq9Ma9Ek96wFxldmBOdh6RFxE8
Message-ID: <CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@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 \(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 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

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFR1
ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+IElhbiBD
YW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDogYWRkIHN1
cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+ID4gT24gVGh1LCAyMDExLTEyLTIyIGF0IDE2OjQxICsw
MDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiA+ID4gU29tZSBhdXRvZ29vIHN0dWZmIHdp
bGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRoZSB0b29scyBidWlsZC4gQ2FuIHlvdQo+PiA+ID4g
c2V0IHVwIHRoZSBiYXNpYyBzdHJ1Y3R1cmUgSWFuPwo+PiA+Cj4+ID4gSSdtIG5vdCBnb2luZyB0
byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+PiA+Cj4+ID4gV291bGQgaXQgYmUgc3Vm
ZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0b29scy9jaGVjayBjcmVhdGUgYQo+PiA+IGNv
bmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNrcz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBN
YWtlZmlsZSBtYWdpYwo+PiA+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+
Pgo+PiBGb3Igbm93LCBJIHRoaW5rIHdlIHNob3VsZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhl
IGNyaXRpY2FsIHBhdGggZm9yCj4+IFhlbiA0LjIuIMKgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxk
IHN3aXRjaCB0byBhdXRvY29uZiBJIHRoaW5rLiDCoChJCj4+IGRvbid0IGFwcHJvdmUgb2YgYXV0
b21ha2UuKQo+Cj4gSXQgc2VlbXMgdGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24g
dGhlIGF1dG9jb25mIHN0dWZmLiBDYW4gd2UKPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0
IHdlIGNhbiBzdXBwb3J0IHlhamwgMi4wIGluIFhlbiA0LjIgYW5kCj4gc3dpdGNoIHRvIGF1dG9j
b25mIGFmdGVyd2FyZHMgb3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRjaCB0bwo+
IGF1dG9jb25mIGZvciA0LjI/CgpUaGUgcHJvcG9zZWQgYXV0b2NvbmYgcGF0Y2ggaXMganVzdCBh
IGNvbnZlbmllbnQgcmVwbGFjZW1lbnQgZm9yCnRvb2xzL2NoZWNrIHNjcmlwdHMsIHdoaWNoIGFs
bG93cyB1cyB0byBnZW5lcmF0ZSBhIG1ha2VmaWxlIGFuZCBhCmhlYWRlciB3ZSBjYW4gaW5jbHVk
ZSB0byBrbm93IHRoZSBzeXN0ZW0gY2FwYWJpbGl0aWVzLCBub3RoaW5nIG1vcmUKd2FzIGFkZGVk
LgoKPiBJIGFwcHJlY2lhdGUgdGhlIGNvbmNlcm5zIGFib3V0IGNyaXRpY2FsIHBhdGggZm9yIDQu
Mi4gSSBwcmVzdW1lCj4gYXV0b2NvbmYgd291bGQgcmVxdWlyZSBtb3JlIHRoYW4ganVzdCBjaGVj
a2luZyBpbiB0aGUgcGF0Y2hlcywKPiBzcGVjaWZpY2FsbHkgSSdtIHRoaW5raW5nIG9mIHRoZSBh
dXRvbWF0ZWQgdGVzdCBzeXN0ZW0gdXBkYXRlIGFuZCBkb2NzLgoKRG9uJ3Qga25vdyBob3cgZGlm
ZmljdWx0IGl0IGlzIHRvIHVwZGF0ZSB0aGUgdGVzdCBiZWQgdG8gdXNlIHRoZSBuZXcKY29uZmln
dXJlIHNjcmlwdCwgaWRlYWxseSBpdCBzaG91bGQgb25seSByZXF1aXJlIGFkZGluZyAiLi9jb25m
aWd1cmUiCmJlZm9yZSBwZXJmb3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtu
b3cgaG93IHRoZSB0ZXN0IGJlZAp3b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mg
c29tZSBvcHRpb25zIHRvIGNvbmZpZ3VyZQpleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1lIHJl
c3VsdC4KCj4gT24gdGhlIG90aGVyIGhhbmQgUm9nZXIgcG9zdGVkIHYzIG9mIGhpcyBhdXRvY29u
ZiBzdXBwb3J0IHBhdGNoIGFuZAo+IGFsdGhvdWdoIEkgaGF2ZW4ndCBnb3Qgcm91bmQgdG8gcmV2
aWV3aW5nIGl0IHlldCAoc29ycnkpIHYyJ3MgcmV2aWV3IHdhcwo+IGdlbmVyYWxseSBwb3NpdGl2
ZS9taW5vciBsb29raW5nLgoKdjMgaXMgYmFzaWNhbGx5IGEgdjIgd2l0aCBhbGwgdGhlIG1lbnRp
b25lZCBmaXhlcyBhbmQgdGhlIG91dHB1dCBmcm9tCmF1dG9jb25mICYgYXV0b21ha2UsIHNvIHdl
IGNhbiB1c2UgdGhlIGNvbmZpZ3VyZSBzY3JpcHQgc3RyYWlnaHQgYXdheS4KCkFueXdheSwgdGhp
cyBwYXRjaCBmb3IgYWRkaW5nIHN1cHBvcnQgb2YgeWFqbCAyLjAgbmVlZHMgc29tZSByZXdvcmss
CmFjY29yZGluZyB0byB0aGUgY29tbWVudHMgbWFkZSBieSBJYW4gSmFja3Nvbiwgd2hpY2ggSSB3
aWxsIHRyeSB0byBkbwpiZWZvcmUgdGhlIGVuZCBvZiB0aGUgd2VlayAoc29ycnkgZm9yIHRoZSBk
ZWxheSwgYnV0IEknbSBxdWl0ZSBidXN5CnRoaXMgZGF5cykuCgpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1k
ZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:31:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpI7P-0001KG-4J; Mon, 23 Jan 2012 11:31:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpI7O-0001JU-CX
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:31:22 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327318275!11956772!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDE1OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28348 invoked from network); 23 Jan 2012 11:31:16 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:31:16 -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=vv5ubeSMwsIoN3DqCfk8zoMKWO3mgWKhYz4h5CrmC3ijwPgQwcvN90ux
	tKkl3VVoT+1G8pcw6Oi4+AI2HvRhNu1QDZHCmGaM3iGx0WHf4AgxsP8Pg
	7RW5vIhQd9GXD8ybkRtiRNy7V8uf+xHgoyNWPAKrXRoj/r4LtH8U8HQwY
	vKnbk1Vc7QvPyAgD1AZ3yweCcRkQhstOgTVeWxldzINTPuZSj0yCymDpj
	xmr8Mjtzx1B17YIbbY4L0JQ5xHKn1;
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=1327318276; x=1358854276;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=krO7VeTd3Gw2cFmjLyiwTGIlhw0XLGJWH7uBmMSzyJA=;
	b=hcFyJvCcovnw+yPmQnsM0n7KmEE9kF0XDwIj4tru4lULqW6EjjoUAMgB
	WwwaVC35xXtQufp8RFtd1UQEuQ7ls3wsbW3imJxrtgRPsnRXisIjN8+yt
	l7BVsWA4EkWO4qMtMzyjoPD+HR444kVhDW4CBp/lTVY5cQu1RsI/h+ifO
	srpdPHae5FveKVy1dwyMr/BrNmkkx4+pn3lynDqd21NTr9LX0ACa1HVwu
	hsXarTbLRX0DtTrkDsTFMDhs7x87/;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="84251293"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 23 Jan 2012 12:31:16 +0100
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="127574514"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 23 Jan 2012 12:31:15 +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 4FAB1960CFE;
	Mon, 23 Jan 2012 12:31:13 +0100 (CET)
Message-ID: <4F1D4501.8060608@ts.fujitsu.com>
Date: Mon, 23 Jan 2012 12:31:13 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <cee17928d4eff5e7873f.1327312293@nehalem1>
	<1327316595.24561.44.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327316595.24561.44.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 12:03 PM, Ian Campbell wrote:
> On Mon, 2012-01-23 at 09:51 +0000, Juergen Gross wrote:
>> @@ -365,15 +366,21 @@ void domain_update_node_affinity(struct
>>   void domain_update_node_affinity(struct domain *d)
>>   {
>>       cpumask_t cpumask;
>> +    cpumask_t online_affinity;
>> +    cpumask_t *online;
>>       nodemask_t nodemask = NODE_MASK_NONE;
>>       struct vcpu *v;
>>       unsigned int node;
>>
>> +    online = (d->cpupool == NULL) ?&cpu_online_map : d->cpupool->cpu_valid;
>>       cpumask_clear(&cpumask);
>>       spin_lock(&d->node_affinity_lock);
>>
>>       for_each_vcpu ( d, v )
>> -        cpumask_or(&cpumask,&cpumask, v->cpu_affinity);
>> +    {
>> +        cpumask_and(&online_affinity, v->cpu_affinity, online);
>> +        cpumask_or(&cpumask,&cpumask,&online_affinity);
>> +    }
>>
>>       for_each_online_node ( node )
>>           if ( cpumask_intersects(&node_to_cpumask(node),&cpumask) )
> Is there any possibility that the addition of the cpumask_and clause
> could result in the empty set?

No. v->cpu_affinity is set to all ones if:
- the domain is moved to another cpupool
- the last cpu which is set in v->cpu_affinity is removed from the cpupool the
   domain is assigned to


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 Mon Jan 23 11:31:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:31:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpI7P-0001KG-4J; Mon, 23 Jan 2012 11:31:23 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpI7O-0001JU-CX
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:31:22 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327318275!11956772!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDE1OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28348 invoked from network); 23 Jan 2012 11:31:16 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:31:16 -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=vv5ubeSMwsIoN3DqCfk8zoMKWO3mgWKhYz4h5CrmC3ijwPgQwcvN90ux
	tKkl3VVoT+1G8pcw6Oi4+AI2HvRhNu1QDZHCmGaM3iGx0WHf4AgxsP8Pg
	7RW5vIhQd9GXD8ybkRtiRNy7V8uf+xHgoyNWPAKrXRoj/r4LtH8U8HQwY
	vKnbk1Vc7QvPyAgD1AZ3yweCcRkQhstOgTVeWxldzINTPuZSj0yCymDpj
	xmr8Mjtzx1B17YIbbY4L0JQ5xHKn1;
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=1327318276; x=1358854276;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=krO7VeTd3Gw2cFmjLyiwTGIlhw0XLGJWH7uBmMSzyJA=;
	b=hcFyJvCcovnw+yPmQnsM0n7KmEE9kF0XDwIj4tru4lULqW6EjjoUAMgB
	WwwaVC35xXtQufp8RFtd1UQEuQ7ls3wsbW3imJxrtgRPsnRXisIjN8+yt
	l7BVsWA4EkWO4qMtMzyjoPD+HR444kVhDW4CBp/lTVY5cQu1RsI/h+ifO
	srpdPHae5FveKVy1dwyMr/BrNmkkx4+pn3lynDqd21NTr9LX0ACa1HVwu
	hsXarTbLRX0DtTrkDsTFMDhs7x87/;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="84251293"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 23 Jan 2012 12:31:16 +0100
X-IronPort-AV: E=Sophos;i="4.71,554,1320620400"; d="scan'208";a="127574514"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 23 Jan 2012 12:31:15 +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 4FAB1960CFE;
	Mon, 23 Jan 2012 12:31:13 +0100 (CET)
Message-ID: <4F1D4501.8060608@ts.fujitsu.com>
Date: Mon, 23 Jan 2012 12:31:13 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <cee17928d4eff5e7873f.1327312293@nehalem1>
	<1327316595.24561.44.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327316595.24561.44.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 12:03 PM, Ian Campbell wrote:
> On Mon, 2012-01-23 at 09:51 +0000, Juergen Gross wrote:
>> @@ -365,15 +366,21 @@ void domain_update_node_affinity(struct
>>   void domain_update_node_affinity(struct domain *d)
>>   {
>>       cpumask_t cpumask;
>> +    cpumask_t online_affinity;
>> +    cpumask_t *online;
>>       nodemask_t nodemask = NODE_MASK_NONE;
>>       struct vcpu *v;
>>       unsigned int node;
>>
>> +    online = (d->cpupool == NULL) ?&cpu_online_map : d->cpupool->cpu_valid;
>>       cpumask_clear(&cpumask);
>>       spin_lock(&d->node_affinity_lock);
>>
>>       for_each_vcpu ( d, v )
>> -        cpumask_or(&cpumask,&cpumask, v->cpu_affinity);
>> +    {
>> +        cpumask_and(&online_affinity, v->cpu_affinity, online);
>> +        cpumask_or(&cpumask,&cpumask,&online_affinity);
>> +    }
>>
>>       for_each_online_node ( node )
>>           if ( cpumask_intersects(&node_to_cpumask(node),&cpumask) )
> Is there any possibility that the addition of the cpumask_and clause
> could result in the empty set?

No. v->cpu_affinity is set to all ones if:
- the domain is moved to another cpupool
- the last cpu which is set in v->cpu_affinity is removed from the cpupool the
   domain is assigned to


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 Mon Jan 23 11:39:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIFE-0001xW-Rb; Mon, 23 Jan 2012 11:39: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 1RpIFC-0001x9-RI
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:39:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327318760!11982918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9585 invoked from network); 23 Jan 2012 11:39:21 -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;
	23 Jan 2012 11:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10211105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:39: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;
	Mon, 23 Jan 2012 11:39:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 23 Jan 2012 11:39:20 +0000
In-Reply-To: <CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327318760.24561.73.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 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

T24gTW9uLCAyMDEyLTAxLTIzIGF0IDExOjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8yMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFR1ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4g
Pj4gSWFuIENhbXBiZWxsIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggdjJdIGxpYnhs
OiBhZGQgc3VwcG9ydCBmb3IgeWFqbCAyLngiKToKPiA+PiA+IE9uIFRodSwgMjAxMS0xMi0yMiBh
dCAxNjo0MSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPiA+PiA+ID4gU29tZSBhdXRv
Z29vIHN0dWZmIHdpbGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRoZSB0b29scyBidWlsZC4gQ2Fu
IHlvdQo+ID4+ID4gPiBzZXQgdXAgdGhlIGJhc2ljIHN0cnVjdHVyZSBJYW4/Cj4gPj4gPgo+ID4+
ID4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+ID4+ID4K
PiA+PiA+IFdvdWxkIGl0IGJlIHN1ZmZpY2llbnQgdG8gaGF2ZSB0aGUgc3R1ZmYgaW4gdG9vbHMv
Y2hlY2sgY3JlYXRlIGEKPiA+PiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNr
cz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+ID4+ID4gdG8gYmUgc3VyZSB0
aGF0IGNoZWNrIGlzIGFsd2F5cyBydW4/Cj4gPj4KPiA+PiBGb3Igbm93LCBJIHRoaW5rIHdlIHNo
b3VsZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhlIGNyaXRpY2FsIHBhdGggZm9yCj4gPj4gWGVu
IDQuMi4gIEJ1dCBhZnRlciB0aGVuIHdlIHNob3VsZCBzd2l0Y2ggdG8gYXV0b2NvbmYgSSB0aGlu
ay4gIChJCj4gPj4gZG9uJ3QgYXBwcm92ZSBvZiBhdXRvbWFrZS4pCj4gPgo+ID4gSXQgc2VlbXMg
dGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24gdGhlIGF1dG9jb25mIHN0dWZmLiBD
YW4gd2UKPiA+IGRpc2VudGFuZ2xlIHRoaW5ncyBzdWNoIHRoYXQgd2UgY2FuIHN1cHBvcnQgeWFq
bCAyLjAgaW4gWGVuIDQuMiBhbmQKPiA+IHN3aXRjaCB0byBhdXRvY29uZiBhZnRlcndhcmRzIG9y
IGRvIHdlIGhhdmUvd2FudCB0byBtYWtlIHRoZSBzd2l0Y2ggdG8KPiA+IGF1dG9jb25mIGZvciA0
LjI/Cj4gCj4gVGhlIHByb3Bvc2VkIGF1dG9jb25mIHBhdGNoIGlzIGp1c3QgYSBjb252ZW5pZW50
IHJlcGxhY2VtZW50IGZvcgo+IHRvb2xzL2NoZWNrIHNjcmlwdHMsIHdoaWNoIGFsbG93cyB1cyB0
byBnZW5lcmF0ZSBhIG1ha2VmaWxlIGFuZCBhCj4gaGVhZGVyIHdlIGNhbiBpbmNsdWRlIHRvIGtu
b3cgdGhlIHN5c3RlbSBjYXBhYmlsaXRpZXMsIG5vdGhpbmcgbW9yZQo+IHdhcyBhZGRlZC4KPiAK
PiA+IEkgYXBwcmVjaWF0ZSB0aGUgY29uY2VybnMgYWJvdXQgY3JpdGljYWwgcGF0aCBmb3IgNC4y
LiBJIHByZXN1bWUKPiA+IGF1dG9jb25mIHdvdWxkIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgY2hl
Y2tpbmcgaW4gdGhlIHBhdGNoZXMsCj4gPiBzcGVjaWZpY2FsbHkgSSdtIHRoaW5raW5nIG9mIHRo
ZSBhdXRvbWF0ZWQgdGVzdCBzeXN0ZW0gdXBkYXRlIGFuZCBkb2NzLgo+IAo+IERvbid0IGtub3cg
aG93IGRpZmZpY3VsdCBpdCBpcyB0byB1cGRhdGUgdGhlIHRlc3QgYmVkIHRvIHVzZSB0aGUgbmV3
Cj4gY29uZmlndXJlIHNjcmlwdCwgaWRlYWxseSBpdCBzaG91bGQgb25seSByZXF1aXJlIGFkZGlu
ZyAiLi9jb25maWd1cmUiCj4gYmVmb3JlIHBlcmZvcm1pbmcgYSAibWFrZSB0b29scyIuIFNpbmNl
IEkgZG9uJ3Qga25vdyBob3cgdGhlIHRlc3QgYmVkCj4gd29ya3MsIGl0IG1pZ2h0IGJlIG5lY2Vz
c2FyeSB0byBwYXNzIHNvbWUgb3B0aW9ucyB0byBjb25maWd1cmUKPiBleGVjdXRpb24gdG8gb2J0
YWluIHRoZSBzYW1lIHJlc3VsdC4KCklhbiBKIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHRoYXQgb25l
LiBIb3BlZnVsbHkganVzdCBydW5uaW5nIC4vY29uZmlndXJlCndpbGwgZ2V0IHVzIGFzIGNsb3Nl
IGFzIHBvc3NpYmxlIHRvIHRoZSBleGlzdGluZyBzZXR1cC4KCkZXSVcgdGhlIHRlc3RlciBjb2Rl
IGlzIGF2YWlsYWJsZSBhdCBhIGdpdCB1cmwgd2hpY2ggaXMgaW4gZXZlcnkgcG9zdGVkCnNldCBv
ZiByZXN1bHRzLiBQcm9iYWJseSBsb29raW5nIGZvciBhbnl3aGVyZSB0aGF0IHdyaXRlcyB0byAu
Y29uZmlnCndvdWxkIGJlIGEgZ29vZCBzdGFydCBmb3IgZGVjaWRpbmcgaG93IGZhciBmcm9tIHRo
ZSBkZWZhdWx0cyBpdCBkZXZpYXRlcwoobm90IGZhciwgSSBleHBlY3QpLgoKPiA+IE9uIHRoZSBv
dGhlciBoYW5kIFJvZ2VyIHBvc3RlZCB2MyBvZiBoaXMgYXV0b2NvbmYgc3VwcG9ydCBwYXRjaCBh
bmQKPiA+IGFsdGhvdWdoIEkgaGF2ZW4ndCBnb3Qgcm91bmQgdG8gcmV2aWV3aW5nIGl0IHlldCAo
c29ycnkpIHYyJ3MgcmV2aWV3IHdhcwo+ID4gZ2VuZXJhbGx5IHBvc2l0aXZlL21pbm9yIGxvb2tp
bmcuCj4gCj4gdjMgaXMgYmFzaWNhbGx5IGEgdjIgd2l0aCBhbGwgdGhlIG1lbnRpb25lZCBmaXhl
cyBhbmQgdGhlIG91dHB1dCBmcm9tCj4gYXV0b2NvbmYgJiBhdXRvbWFrZSwgc28gd2UgY2FuIHVz
ZSB0aGUgY29uZmlndXJlIHNjcmlwdCBzdHJhaWdodCBhd2F5LgoKYXV0b21ha2U/IEkgdGhvdWdo
dCB3ZSBhZ3JlZWQgbm90IHRvIHVzZSB0aGF0PwoKPiBBbnl3YXksIHRoaXMgcGF0Y2ggZm9yIGFk
ZGluZyBzdXBwb3J0IG9mIHlhamwgMi4wIG5lZWRzIHNvbWUgcmV3b3JrLAo+IGFjY29yZGluZyB0
byB0aGUgY29tbWVudHMgbWFkZSBieSBJYW4gSmFja3Nvbiwgd2hpY2ggSSB3aWxsIHRyeSB0byBk
bwo+IGJlZm9yZSB0aGUgZW5kIG9mIHRoZSB3ZWVrIChzb3JyeSBmb3IgdGhlIGRlbGF5LCBidXQg
SSdtIHF1aXRlIGJ1c3kKPiB0aGlzIGRheXMpLgoKU3VyZSwgbm8gcHJvYmxlbS4gSSBoYXZlIHB1
dCB5YWpsMiBzdXBwb3J0IGluIHRoZSAibmljZSB0byBoYXZlIGNvbHVtbiIKYW5kIGF1dG9jb25m
IGluIGEgbmV3ICJuZWVkIHRvIGRlY2lkZSBpZiB0aGlzIGlzIDQuMiBvciA0LjMgbWF0ZXJpYWwi
CmNvbHVtbi4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:39:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:39:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIFE-0001xW-Rb; Mon, 23 Jan 2012 11:39: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 1RpIFC-0001x9-RI
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:39:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327318760!11982918!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9585 invoked from network); 23 Jan 2012 11:39:21 -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;
	23 Jan 2012 11:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10211105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:39: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;
	Mon, 23 Jan 2012 11:39:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 23 Jan 2012 11:39:20 +0000
In-Reply-To: <CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327318760.24561.73.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 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

T24gTW9uLCAyMDEyLTAxLTIzIGF0IDExOjMwICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8yMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFR1ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4g
Pj4gSWFuIENhbXBiZWxsIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggdjJdIGxpYnhs
OiBhZGQgc3VwcG9ydCBmb3IgeWFqbCAyLngiKToKPiA+PiA+IE9uIFRodSwgMjAxMS0xMi0yMiBh
dCAxNjo0MSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPiA+PiA+ID4gU29tZSBhdXRv
Z29vIHN0dWZmIHdpbGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRoZSB0b29scyBidWlsZC4gQ2Fu
IHlvdQo+ID4+ID4gPiBzZXQgdXAgdGhlIGJhc2ljIHN0cnVjdHVyZSBJYW4/Cj4gPj4gPgo+ID4+
ID4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+ID4+ID4K
PiA+PiA+IFdvdWxkIGl0IGJlIHN1ZmZpY2llbnQgdG8gaGF2ZSB0aGUgc3R1ZmYgaW4gdG9vbHMv
Y2hlY2sgY3JlYXRlIGEKPiA+PiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNr
cz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+ID4+ID4gdG8gYmUgc3VyZSB0
aGF0IGNoZWNrIGlzIGFsd2F5cyBydW4/Cj4gPj4KPiA+PiBGb3Igbm93LCBJIHRoaW5rIHdlIHNo
b3VsZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhlIGNyaXRpY2FsIHBhdGggZm9yCj4gPj4gWGVu
IDQuMi4gIEJ1dCBhZnRlciB0aGVuIHdlIHNob3VsZCBzd2l0Y2ggdG8gYXV0b2NvbmYgSSB0aGlu
ay4gIChJCj4gPj4gZG9uJ3QgYXBwcm92ZSBvZiBhdXRvbWFrZS4pCj4gPgo+ID4gSXQgc2VlbXMg
dGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24gdGhlIGF1dG9jb25mIHN0dWZmLiBD
YW4gd2UKPiA+IGRpc2VudGFuZ2xlIHRoaW5ncyBzdWNoIHRoYXQgd2UgY2FuIHN1cHBvcnQgeWFq
bCAyLjAgaW4gWGVuIDQuMiBhbmQKPiA+IHN3aXRjaCB0byBhdXRvY29uZiBhZnRlcndhcmRzIG9y
IGRvIHdlIGhhdmUvd2FudCB0byBtYWtlIHRoZSBzd2l0Y2ggdG8KPiA+IGF1dG9jb25mIGZvciA0
LjI/Cj4gCj4gVGhlIHByb3Bvc2VkIGF1dG9jb25mIHBhdGNoIGlzIGp1c3QgYSBjb252ZW5pZW50
IHJlcGxhY2VtZW50IGZvcgo+IHRvb2xzL2NoZWNrIHNjcmlwdHMsIHdoaWNoIGFsbG93cyB1cyB0
byBnZW5lcmF0ZSBhIG1ha2VmaWxlIGFuZCBhCj4gaGVhZGVyIHdlIGNhbiBpbmNsdWRlIHRvIGtu
b3cgdGhlIHN5c3RlbSBjYXBhYmlsaXRpZXMsIG5vdGhpbmcgbW9yZQo+IHdhcyBhZGRlZC4KPiAK
PiA+IEkgYXBwcmVjaWF0ZSB0aGUgY29uY2VybnMgYWJvdXQgY3JpdGljYWwgcGF0aCBmb3IgNC4y
LiBJIHByZXN1bWUKPiA+IGF1dG9jb25mIHdvdWxkIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgY2hl
Y2tpbmcgaW4gdGhlIHBhdGNoZXMsCj4gPiBzcGVjaWZpY2FsbHkgSSdtIHRoaW5raW5nIG9mIHRo
ZSBhdXRvbWF0ZWQgdGVzdCBzeXN0ZW0gdXBkYXRlIGFuZCBkb2NzLgo+IAo+IERvbid0IGtub3cg
aG93IGRpZmZpY3VsdCBpdCBpcyB0byB1cGRhdGUgdGhlIHRlc3QgYmVkIHRvIHVzZSB0aGUgbmV3
Cj4gY29uZmlndXJlIHNjcmlwdCwgaWRlYWxseSBpdCBzaG91bGQgb25seSByZXF1aXJlIGFkZGlu
ZyAiLi9jb25maWd1cmUiCj4gYmVmb3JlIHBlcmZvcm1pbmcgYSAibWFrZSB0b29scyIuIFNpbmNl
IEkgZG9uJ3Qga25vdyBob3cgdGhlIHRlc3QgYmVkCj4gd29ya3MsIGl0IG1pZ2h0IGJlIG5lY2Vz
c2FyeSB0byBwYXNzIHNvbWUgb3B0aW9ucyB0byBjb25maWd1cmUKPiBleGVjdXRpb24gdG8gb2J0
YWluIHRoZSBzYW1lIHJlc3VsdC4KCklhbiBKIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHRoYXQgb25l
LiBIb3BlZnVsbHkganVzdCBydW5uaW5nIC4vY29uZmlndXJlCndpbGwgZ2V0IHVzIGFzIGNsb3Nl
IGFzIHBvc3NpYmxlIHRvIHRoZSBleGlzdGluZyBzZXR1cC4KCkZXSVcgdGhlIHRlc3RlciBjb2Rl
IGlzIGF2YWlsYWJsZSBhdCBhIGdpdCB1cmwgd2hpY2ggaXMgaW4gZXZlcnkgcG9zdGVkCnNldCBv
ZiByZXN1bHRzLiBQcm9iYWJseSBsb29raW5nIGZvciBhbnl3aGVyZSB0aGF0IHdyaXRlcyB0byAu
Y29uZmlnCndvdWxkIGJlIGEgZ29vZCBzdGFydCBmb3IgZGVjaWRpbmcgaG93IGZhciBmcm9tIHRo
ZSBkZWZhdWx0cyBpdCBkZXZpYXRlcwoobm90IGZhciwgSSBleHBlY3QpLgoKPiA+IE9uIHRoZSBv
dGhlciBoYW5kIFJvZ2VyIHBvc3RlZCB2MyBvZiBoaXMgYXV0b2NvbmYgc3VwcG9ydCBwYXRjaCBh
bmQKPiA+IGFsdGhvdWdoIEkgaGF2ZW4ndCBnb3Qgcm91bmQgdG8gcmV2aWV3aW5nIGl0IHlldCAo
c29ycnkpIHYyJ3MgcmV2aWV3IHdhcwo+ID4gZ2VuZXJhbGx5IHBvc2l0aXZlL21pbm9yIGxvb2tp
bmcuCj4gCj4gdjMgaXMgYmFzaWNhbGx5IGEgdjIgd2l0aCBhbGwgdGhlIG1lbnRpb25lZCBmaXhl
cyBhbmQgdGhlIG91dHB1dCBmcm9tCj4gYXV0b2NvbmYgJiBhdXRvbWFrZSwgc28gd2UgY2FuIHVz
ZSB0aGUgY29uZmlndXJlIHNjcmlwdCBzdHJhaWdodCBhd2F5LgoKYXV0b21ha2U/IEkgdGhvdWdo
dCB3ZSBhZ3JlZWQgbm90IHRvIHVzZSB0aGF0PwoKPiBBbnl3YXksIHRoaXMgcGF0Y2ggZm9yIGFk
ZGluZyBzdXBwb3J0IG9mIHlhamwgMi4wIG5lZWRzIHNvbWUgcmV3b3JrLAo+IGFjY29yZGluZyB0
byB0aGUgY29tbWVudHMgbWFkZSBieSBJYW4gSmFja3Nvbiwgd2hpY2ggSSB3aWxsIHRyeSB0byBk
bwo+IGJlZm9yZSB0aGUgZW5kIG9mIHRoZSB3ZWVrIChzb3JyeSBmb3IgdGhlIGRlbGF5LCBidXQg
SSdtIHF1aXRlIGJ1c3kKPiB0aGlzIGRheXMpLgoKU3VyZSwgbm8gcHJvYmxlbS4gSSBoYXZlIHB1
dCB5YWpsMiBzdXBwb3J0IGluIHRoZSAibmljZSB0byBoYXZlIGNvbHVtbiIKYW5kIGF1dG9jb25m
IGluIGEgbmV3ICJuZWVkIHRvIGRlY2lkZSBpZiB0aGlzIGlzIDQuMiBvciA0LjMgbWF0ZXJpYWwi
CmNvbHVtbi4KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNl
LmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:40:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpIFY-000209-Dz; Mon, 23 Jan 2012 11:39: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 1RpIFW-0001zO-MA; Mon, 23 Jan 2012 11:39:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327318779!3373268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16865 invoked from network); 23 Jan 2012 11:39:39 -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;
	23 Jan 2012 11:39:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10211118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:39: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, 23 Jan 2012 11:39:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Mon, 23 Jan 2012 11:39:38 +0000
In-Reply-To: <CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327318778.24561.74.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	chris <tknchris@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please do not a) top-post or b) cross-post. The latter being aimed at
whoever started this thread.

On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:

> Yeah, I guess xen has generally been focused on the server end.

Xen is focused on whatever people submit patches to do. Many of the core
developers are not currently looking at VGA passthrough, we have plenty
of stuff on our plates, but we are more than happy to review and accept
patches to implement/improve/fix this feature if only those people who
are interested in it would take the time to submit them per
http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
going to go out hunting for patches on the Internet.

David Techer recently offered to do this but perhaps he would be
interested in some help from you?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:40:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpIFY-000209-Dz; Mon, 23 Jan 2012 11:39: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 1RpIFW-0001zO-MA; Mon, 23 Jan 2012 11:39:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327318779!3373268!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16865 invoked from network); 23 Jan 2012 11:39:39 -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;
	23 Jan 2012 11:39:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10211118"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:39: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, 23 Jan 2012 11:39:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Sandi Romih <romihs.forums@gmail.com>
Date: Mon, 23 Jan 2012 11:39:38 +0000
In-Reply-To: <CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327318778.24561.74.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	chris <tknchris@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please do not a) top-post or b) cross-post. The latter being aimed at
whoever started this thread.

On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:

> Yeah, I guess xen has generally been focused on the server end.

Xen is focused on whatever people submit patches to do. Many of the core
developers are not currently looking at VGA passthrough, we have plenty
of stuff on our plates, but we are more than happy to review and accept
patches to implement/improve/fix this feature if only those people who
are interested in it would take the time to submit them per
http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
going to go out hunting for patches on the Internet.

David Techer recently offered to do this but perhaps he would be
interested in some help from you?

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpIG2-000269-MP; Mon, 23 Jan 2012 11:40:18 +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 1RpIG1-00024s-RK
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:40:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327318809!10295276!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16857 invoked from network); 23 Jan 2012 11:40:11 -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 Jan 2012 11:40:11 -0000
Received: by dajs34 with SMTP id s34so18088648daj.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 03:40: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=4v3hmzILHKJsrELY2Z2DSvSFIaeHUaBD9Tc0FQT1KSA=;
	b=WwTJsl+iOatevTWQdZ+yPlgntWnwbNkS8IlLfvxSRACaI1MMoxxHDWsDqzOVczKLhI
	FwVoUJfTd8/leqVQj0P+NNfSqSi10eXmJMoX/9YbeRV7X5xZhdqbL+4GSsX1AsVGpgNr
	a1E07fyFMw9MSomsHmMkz7xuaSK9zb1/G3xjE=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr21491143pbu.124.1327318808676; Mon,
	23 Jan 2012 03:40:08 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Mon, 23 Jan 2012 03:40:08 -0800 (PST)
In-Reply-To: <1326796747.14689.93.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 12:40:08 +0100
X-Google-Sender-Auth: 1uaiKsVzFWKHkeFzR2cDQX8ro_w
Message-ID: <CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFR1
ZSwgMjAxMi0wMS0xNyBhdCAxMDowMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IFR1ZSwgMjAxMi0wMS0xNyBhdCAwOTo0MCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToK
Pj4gPj4gMjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+
PiA+PiA+IEhvd2V2ZXIgeGVuZCBzaG91bGQgbm90IGJlIHRyYW5zaXRpb24gdG8gdGhpcyBuZXcg
c2NoZW1lIGJ1dCBzaG91bGQKPj4gPj4gPiBjb250aW51ZSB0byB1c2UgaXRzIGV4aXN0aW5nIHNj
cmlwdHMgaW4gdGhlIGN1cnJlbnQgbWFubmVyLgo+PiA+PiA+Cj4+ID4+ID4gVGhlcmUgd2FzIGEg
Y29udmVyc2F0aW9uIGxhc3QgeWVhclswXSBhYm91dCBob3cgYSB0b29sc3RhY2sgY291bGQKPj4g
Pj4gPiBvcHQtaW4vb3V0IG9mIHRoZSB1c2Ugb2YgdGhlIGhvdHBsdWcgc2NyaXB0cy4gV2UgZGVj
aWRlZCB0aGF0IHRvb2xzdGFja3MKPj4gPj4gPiBzaG91bGQgaGF2ZSB0byBvcHQgaW50byB0aGUg
dXNlIG9mIHRoZXNlIHNjcmlwdHMsIGJ5IHRvdWNoaW5nIGEgc3RhbXAKPj4gPj4gPiBmaWxlLgo+
PiA+PiA+Cj4+ID4+ID4gQWx0aG91Z2ggdGhpcyB3YXNuJ3QgaW1wbGVtZW50ZWQgeWV0ICh1bmxl
c3MgSSBtaXNzZWQgaXQpIEkgZ3Vlc3MgdGhlCj4+ID4+ID4gc2FtZSBzY2hlbWUgd291bGQgYXBw
bHkgdG8gdGhpcyB3b3JrIGlmIHRoYXQgc29ydCBvZiB0aGluZyB0dXJucyBvdXQgdG8KPj4gPj4g
PiBiZSBuZWNlc3NhcnkuCj4+ID4+Cj4+ID4+IFNvcnJ5IGZvciByZXBseWluZyBzbyBtYW55IHRp
bWVzLCB0aGlzIGlzIGEgYmlnIG1heWJlLCBhbmQgcG9zc2libHkKPj4gPj4gaXQncyB0b28gZHJh
c3RpYywgYnV0IGFmdGVyIHRoaXMgY2hhbmdlcyB4bCBhbmQgeGVuZCB3aWxsIG5vdCBiZQo+PiA+
PiBjb21wYXRpYmxlIGFueW1vcmUsIHNvIHdoeSBkb24ndCB3ZSBkaXNhYmxlIHhlbmQgYnkgZGVm
YXVsdCwgYW5kIG9ubHkKPj4gPj4gYnVpbGQgeGw/Cj4+ID4KPj4gPiBJIGRvbid0IHRoaW5rIHRo
ZXkgYXJlIGNvbXBhdGlibGUgbm93LCBhcmUgdGhleT8gSSd2ZSBjZXJ0YWlubHkgc2VlbiBvZGQK
Pj4gPiBiZWhhdmlvdXIgd2hlbiB1c2luZyB4bCB3aXRoIHhlbmQgKGFjY2lkZW50YWxseSkgcnVu
bmluZywgdXN1YWxseSB4ZW5kCj4+ID4gcmVhcHMgdGhlIGRvbWFpbiBJJ3ZlIGp1c3Qgc3RhcnRl
ZC4uLgo+PiA+Cj4+ID4gSSdtIGFsbCBmb3IgZGlzYWJsaW5nIHRoZSBidWlsZCBvZiB4ZW5kIGJ5
IGRlZmF1bHQgYnV0IEkgaGFkIGFzc3VtZWQKPj4gPiB0aGF0IG90aGVycyB3b3VsZCB0aGluayA0
LjIgd2FzIHJhdGhlciBhbiBhZ2dyZXNzaXZlIHRpbWVsaW5lIGZvciB0aGF0Lgo+PiA+Cj4+ID4+
IFdoZW4gdGhlIG5ldyBjb25maWd1cmUgc2NyaXB0IGlzIGluLCBpdCB3aWxsIGJlIHRyaXZpYWwg
dG8gc2VsZWN0IGlmCj4+ID4+IHlvdSB3YW50IHhsIG9yIHhlbmQsIGFuZCBvbmx5IGluc3RhbGwg
b25lIG9mIHRob3NlLiBBZGRpbmcgdGhlIG9wdGlvbgo+PiA+PiAtLWVuYWJsZS14ZW5kIHNob3Vs
ZCBkaXNhYmxlIHhsIGFuZCBvbmx5IGJ1aWxkIGFuZCBpbnN0YWxsIHhlbmQKPj4gPj4gKHByaW50
aW5nIGEgdmVyeSBiaWcgd2FybmluZyB0aGF0IHhlbmQgaXMgZGVwcmVjYXRlZCkuCj4+ID4KPj4g
PiBJIGRvbid0IHRoaW5rIC0tZW5hYmxlLXhlbmQgc2hvdWxkIGV2ZXIgZGlzYWJsZSB4bCAob3Ig
dmljZSB2ZXJzYSkuIE1hbnkKPj4gPiBmb2xrcyAoZS5nLiBkaXN0cm9zKSB3aWxsIHdhbnQgdG8g
YnVpbGQgYm90aCwgcGVyaGFwcyB0byBwYWNrYWdlIHRoZW0gaW4KPj4gPiB0d28gZGlmZmVyZW50
IGJpbmFyeSBwYWNrYWdlcywgYnV0IGNlcnRhaW5seSB0byBvZmZlciB0aGVpciB1c2VycyB0aGUK
Pj4gPiBjaG9pY2UsIGF0IGxlYXN0IGZvciB0aGUgdGltZSBiZWluZy4KPj4KPj4gTXkgbWFpbiBj
b25jZXJuIHdpdGggdGhpcyBpcyB0aGF0IHhlbmQgYW5kIHhsIHdpbGwgc3RhcnQgdG8gdXNlCj4+
IGRpZmZlcmVudCB1ZGV2IHJ1bGVzICh3ZWxsLCB4ZW5kIHdpbGwgY29udGludWUgdG8gdXNlIHRo
ZSBleGlzdGluZwo+PiBvbmVzLCB3aGlsZSB4bCB3aWxsIG9ubHkgdXNlIGEgc3Vic2V0IG9mIHRo
b3NlKS4gU28gd2UgaGF2ZSB0byBkZWNpZGUKPj4gd2hpY2ggdWRldiBydWxlcyBmaWxlIHRvIGlu
c3RhbGwsIGJlY2F1c2Ugd2UgY2FuJ3QgaGF2ZSBib3RoIGluc3RhbGxlZAo+PiBhdCB0aGUgc2Ft
ZSB0aW1lLgo+Cj4gU3VyZSB3ZSBjYW4uIFBlcmhhcHMgdGhleSBuZWVkIHRvIGhhdmUgYW4gImlm
ICRUT09MU1RBQ0siIGNoZWNrIChlLmcuIGlmCj4gWyAtZiAvdmFyL3J1bi94ZW5kLmhvdHBsdWcg
XSkgYWRkZWQgdG8gdGhlIHRvcCwgdGhhdCBpcyBhbGwuCj4KPj4gQW5vdGhlciBvcHRpb24gaXMg
dG8gaW5zdGFsbCB4bCB1ZGV2IHJ1bGVzIGJ5IGRlZmF1bHQsIGFuZCBtYWtlIHhlbmQKPj4gbW92
ZSBpdCdzIG93biBydWxlcyBpbiB0aGUgaW5pdCBzY3JpcHQuCj4KPiBJIGRvbid0IHRoaW5rIGlu
aXRzY3JpcHRzIHNob3VsZCBiZSBtZXNzaW5nIHdpdGggdWRldiBydWxlcy4KPgo+IFBlcmhhcHMg
dGhlIG9wdC1pbiBuZWVkcyB0byBiZSBtb3JlIGZpbmUgZ3JhaW5lZCBlLmcuIG9wdC1pbiB0byB2
aWYgYnV0Cj4gbm90IGJsb2NrIHNjcmlwdHMgb3Igd2hhdGV2ZXIgZGlzdGluY3Rpb24geW91IHRo
aW5rIGlzIG5lY2Vzc2FyeSBpbnN0ZWFkCj4gb2YganV0IGEgZ2xvYmFsIG9wdCBpbiwgaXQncyBq
dXN0IGEgZGlmZmVyZW50IG5hbWluZyBjb252ZW50aW9uIGZvciB0aGUKPiBzdGFtcCBmaWxlLiBU
aGlzIGF2b2lkcyByZWNvbmZpZ3VyYXRpb24gYW5kIHRoZSBuZWVkIHRvIGluc3RhbGwgc3Vic2V0
cwo+IG9mIHRoZSBzY3JpcHRzIGV0Yy4KPgo+PiDCoFNpbmNlIHhsIGRvZXNuJ3QgdXNlIGEgZGFl
bW9uLAo+PiB4bCBzaG91bGQgYWx3YXlzIGNoZWNrIGlmIHhlbmQgaXMgcnVubmluZyBiZWZvcmUg
ZG9pbmcgYW55dGhpbmcgYW5kCj4+IGZhaWwgaWYgeGVuZCBpcyBmb3VuZC4KPgo+IEkgdGhpbmsg
dGhhdCBpcyBhIHNlcGFyYXRlIHF1ZXN0aW9uL2lzc3VlIHRvIHRoZSBvbmUgb2YgaG90cGx1ZyBz
Y3JpcHRzLgoKSSd2ZSBwb3N0ZWQgYSBXSVAgdGhlIG90aGVyIHdlZWsgYWJvdXQgY2FsbGluZyBo
b3RwbHVnIHNjcml0cHMgZnJvbQpsaWJ4bCwgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsgb3IgdGhl
IGJlZ2lubmluZyBvZiB0aGUgZm9sbG93aW5nIEkKd2lsbCB0cnkgdG8gcG9zdCB0aGUgZmluaXNo
ZWQgZHJpdmVyIGRvbWFpbiBzZXJpZXMsIGFuZCB0aGVuIHdlIGNhbgpkZWNpZGUgaG93IHRvIGZp
eCB4ZW5kIHRvIHByZXNlcnZlIGNvbXBhdGliaWxpdHkuCgpXaXRoIGFsbCB0aGlzLCBpcyB0aGVy
ZSBhIGRlYWRsaW5lIGZvciA0LjI/IEkgd2lsbCByZWFsbHkgbGlrZSB0byBoYXZlCmRyaXZlciBk
b21haW5zIGFkZGVkIHRvIDQuMi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpIG2-000269-MP; Mon, 23 Jan 2012 11:40:18 +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 1RpIG1-00024s-RK
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:40:18 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327318809!10295276!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16857 invoked from network); 23 Jan 2012 11:40:11 -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 Jan 2012 11:40:11 -0000
Received: by dajs34 with SMTP id s34so18088648daj.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 03:40: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=4v3hmzILHKJsrELY2Z2DSvSFIaeHUaBD9Tc0FQT1KSA=;
	b=WwTJsl+iOatevTWQdZ+yPlgntWnwbNkS8IlLfvxSRACaI1MMoxxHDWsDqzOVczKLhI
	FwVoUJfTd8/leqVQj0P+NNfSqSi10eXmJMoX/9YbeRV7X5xZhdqbL+4GSsX1AsVGpgNr
	a1E07fyFMw9MSomsHmMkz7xuaSK9zb1/G3xjE=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr21491143pbu.124.1327318808676; Mon,
	23 Jan 2012 03:40:08 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Mon, 23 Jan 2012 03:40:08 -0800 (PST)
In-Reply-To: <1326796747.14689.93.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 12:40:08 +0100
X-Google-Sender-Auth: 1uaiKsVzFWKHkeFzR2cDQX8ro_w
Message-ID: <CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFR1
ZSwgMjAxMi0wMS0xNyBhdCAxMDowMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IFR1ZSwgMjAxMi0wMS0xNyBhdCAwOTo0MCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToK
Pj4gPj4gMjAxMi8xLzE3IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+
PiA+PiA+IEhvd2V2ZXIgeGVuZCBzaG91bGQgbm90IGJlIHRyYW5zaXRpb24gdG8gdGhpcyBuZXcg
c2NoZW1lIGJ1dCBzaG91bGQKPj4gPj4gPiBjb250aW51ZSB0byB1c2UgaXRzIGV4aXN0aW5nIHNj
cmlwdHMgaW4gdGhlIGN1cnJlbnQgbWFubmVyLgo+PiA+PiA+Cj4+ID4+ID4gVGhlcmUgd2FzIGEg
Y29udmVyc2F0aW9uIGxhc3QgeWVhclswXSBhYm91dCBob3cgYSB0b29sc3RhY2sgY291bGQKPj4g
Pj4gPiBvcHQtaW4vb3V0IG9mIHRoZSB1c2Ugb2YgdGhlIGhvdHBsdWcgc2NyaXB0cy4gV2UgZGVj
aWRlZCB0aGF0IHRvb2xzdGFja3MKPj4gPj4gPiBzaG91bGQgaGF2ZSB0byBvcHQgaW50byB0aGUg
dXNlIG9mIHRoZXNlIHNjcmlwdHMsIGJ5IHRvdWNoaW5nIGEgc3RhbXAKPj4gPj4gPiBmaWxlLgo+
PiA+PiA+Cj4+ID4+ID4gQWx0aG91Z2ggdGhpcyB3YXNuJ3QgaW1wbGVtZW50ZWQgeWV0ICh1bmxl
c3MgSSBtaXNzZWQgaXQpIEkgZ3Vlc3MgdGhlCj4+ID4+ID4gc2FtZSBzY2hlbWUgd291bGQgYXBw
bHkgdG8gdGhpcyB3b3JrIGlmIHRoYXQgc29ydCBvZiB0aGluZyB0dXJucyBvdXQgdG8KPj4gPj4g
PiBiZSBuZWNlc3NhcnkuCj4+ID4+Cj4+ID4+IFNvcnJ5IGZvciByZXBseWluZyBzbyBtYW55IHRp
bWVzLCB0aGlzIGlzIGEgYmlnIG1heWJlLCBhbmQgcG9zc2libHkKPj4gPj4gaXQncyB0b28gZHJh
c3RpYywgYnV0IGFmdGVyIHRoaXMgY2hhbmdlcyB4bCBhbmQgeGVuZCB3aWxsIG5vdCBiZQo+PiA+
PiBjb21wYXRpYmxlIGFueW1vcmUsIHNvIHdoeSBkb24ndCB3ZSBkaXNhYmxlIHhlbmQgYnkgZGVm
YXVsdCwgYW5kIG9ubHkKPj4gPj4gYnVpbGQgeGw/Cj4+ID4KPj4gPiBJIGRvbid0IHRoaW5rIHRo
ZXkgYXJlIGNvbXBhdGlibGUgbm93LCBhcmUgdGhleT8gSSd2ZSBjZXJ0YWlubHkgc2VlbiBvZGQK
Pj4gPiBiZWhhdmlvdXIgd2hlbiB1c2luZyB4bCB3aXRoIHhlbmQgKGFjY2lkZW50YWxseSkgcnVu
bmluZywgdXN1YWxseSB4ZW5kCj4+ID4gcmVhcHMgdGhlIGRvbWFpbiBJJ3ZlIGp1c3Qgc3RhcnRl
ZC4uLgo+PiA+Cj4+ID4gSSdtIGFsbCBmb3IgZGlzYWJsaW5nIHRoZSBidWlsZCBvZiB4ZW5kIGJ5
IGRlZmF1bHQgYnV0IEkgaGFkIGFzc3VtZWQKPj4gPiB0aGF0IG90aGVycyB3b3VsZCB0aGluayA0
LjIgd2FzIHJhdGhlciBhbiBhZ2dyZXNzaXZlIHRpbWVsaW5lIGZvciB0aGF0Lgo+PiA+Cj4+ID4+
IFdoZW4gdGhlIG5ldyBjb25maWd1cmUgc2NyaXB0IGlzIGluLCBpdCB3aWxsIGJlIHRyaXZpYWwg
dG8gc2VsZWN0IGlmCj4+ID4+IHlvdSB3YW50IHhsIG9yIHhlbmQsIGFuZCBvbmx5IGluc3RhbGwg
b25lIG9mIHRob3NlLiBBZGRpbmcgdGhlIG9wdGlvbgo+PiA+PiAtLWVuYWJsZS14ZW5kIHNob3Vs
ZCBkaXNhYmxlIHhsIGFuZCBvbmx5IGJ1aWxkIGFuZCBpbnN0YWxsIHhlbmQKPj4gPj4gKHByaW50
aW5nIGEgdmVyeSBiaWcgd2FybmluZyB0aGF0IHhlbmQgaXMgZGVwcmVjYXRlZCkuCj4+ID4KPj4g
PiBJIGRvbid0IHRoaW5rIC0tZW5hYmxlLXhlbmQgc2hvdWxkIGV2ZXIgZGlzYWJsZSB4bCAob3Ig
dmljZSB2ZXJzYSkuIE1hbnkKPj4gPiBmb2xrcyAoZS5nLiBkaXN0cm9zKSB3aWxsIHdhbnQgdG8g
YnVpbGQgYm90aCwgcGVyaGFwcyB0byBwYWNrYWdlIHRoZW0gaW4KPj4gPiB0d28gZGlmZmVyZW50
IGJpbmFyeSBwYWNrYWdlcywgYnV0IGNlcnRhaW5seSB0byBvZmZlciB0aGVpciB1c2VycyB0aGUK
Pj4gPiBjaG9pY2UsIGF0IGxlYXN0IGZvciB0aGUgdGltZSBiZWluZy4KPj4KPj4gTXkgbWFpbiBj
b25jZXJuIHdpdGggdGhpcyBpcyB0aGF0IHhlbmQgYW5kIHhsIHdpbGwgc3RhcnQgdG8gdXNlCj4+
IGRpZmZlcmVudCB1ZGV2IHJ1bGVzICh3ZWxsLCB4ZW5kIHdpbGwgY29udGludWUgdG8gdXNlIHRo
ZSBleGlzdGluZwo+PiBvbmVzLCB3aGlsZSB4bCB3aWxsIG9ubHkgdXNlIGEgc3Vic2V0IG9mIHRo
b3NlKS4gU28gd2UgaGF2ZSB0byBkZWNpZGUKPj4gd2hpY2ggdWRldiBydWxlcyBmaWxlIHRvIGlu
c3RhbGwsIGJlY2F1c2Ugd2UgY2FuJ3QgaGF2ZSBib3RoIGluc3RhbGxlZAo+PiBhdCB0aGUgc2Ft
ZSB0aW1lLgo+Cj4gU3VyZSB3ZSBjYW4uIFBlcmhhcHMgdGhleSBuZWVkIHRvIGhhdmUgYW4gImlm
ICRUT09MU1RBQ0siIGNoZWNrIChlLmcuIGlmCj4gWyAtZiAvdmFyL3J1bi94ZW5kLmhvdHBsdWcg
XSkgYWRkZWQgdG8gdGhlIHRvcCwgdGhhdCBpcyBhbGwuCj4KPj4gQW5vdGhlciBvcHRpb24gaXMg
dG8gaW5zdGFsbCB4bCB1ZGV2IHJ1bGVzIGJ5IGRlZmF1bHQsIGFuZCBtYWtlIHhlbmQKPj4gbW92
ZSBpdCdzIG93biBydWxlcyBpbiB0aGUgaW5pdCBzY3JpcHQuCj4KPiBJIGRvbid0IHRoaW5rIGlu
aXRzY3JpcHRzIHNob3VsZCBiZSBtZXNzaW5nIHdpdGggdWRldiBydWxlcy4KPgo+IFBlcmhhcHMg
dGhlIG9wdC1pbiBuZWVkcyB0byBiZSBtb3JlIGZpbmUgZ3JhaW5lZCBlLmcuIG9wdC1pbiB0byB2
aWYgYnV0Cj4gbm90IGJsb2NrIHNjcmlwdHMgb3Igd2hhdGV2ZXIgZGlzdGluY3Rpb24geW91IHRo
aW5rIGlzIG5lY2Vzc2FyeSBpbnN0ZWFkCj4gb2YganV0IGEgZ2xvYmFsIG9wdCBpbiwgaXQncyBq
dXN0IGEgZGlmZmVyZW50IG5hbWluZyBjb252ZW50aW9uIGZvciB0aGUKPiBzdGFtcCBmaWxlLiBU
aGlzIGF2b2lkcyByZWNvbmZpZ3VyYXRpb24gYW5kIHRoZSBuZWVkIHRvIGluc3RhbGwgc3Vic2V0
cwo+IG9mIHRoZSBzY3JpcHRzIGV0Yy4KPgo+PiDCoFNpbmNlIHhsIGRvZXNuJ3QgdXNlIGEgZGFl
bW9uLAo+PiB4bCBzaG91bGQgYWx3YXlzIGNoZWNrIGlmIHhlbmQgaXMgcnVubmluZyBiZWZvcmUg
ZG9pbmcgYW55dGhpbmcgYW5kCj4+IGZhaWwgaWYgeGVuZCBpcyBmb3VuZC4KPgo+IEkgdGhpbmsg
dGhhdCBpcyBhIHNlcGFyYXRlIHF1ZXN0aW9uL2lzc3VlIHRvIHRoZSBvbmUgb2YgaG90cGx1ZyBz
Y3JpcHRzLgoKSSd2ZSBwb3N0ZWQgYSBXSVAgdGhlIG90aGVyIHdlZWsgYWJvdXQgY2FsbGluZyBo
b3RwbHVnIHNjcml0cHMgZnJvbQpsaWJ4bCwgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsgb3IgdGhl
IGJlZ2lubmluZyBvZiB0aGUgZm9sbG93aW5nIEkKd2lsbCB0cnkgdG8gcG9zdCB0aGUgZmluaXNo
ZWQgZHJpdmVyIGRvbWFpbiBzZXJpZXMsIGFuZCB0aGVuIHdlIGNhbgpkZWNpZGUgaG93IHRvIGZp
eCB4ZW5kIHRvIHByZXNlcnZlIGNvbXBhdGliaWxpdHkuCgpXaXRoIGFsbCB0aGlzLCBpcyB0aGVy
ZSBhIGRlYWRsaW5lIGZvciA0LjI/IEkgd2lsbCByZWFsbHkgbGlrZSB0byBoYXZlCmRyaXZlciBk
b21haW5zIGFkZGVkIHRvIDQuMi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNv
dXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:45:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIKq-0002pf-7x; Mon, 23 Jan 2012 11:45:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RpIKo-0002oZ-SX; Mon, 23 Jan 2012 11:45:15 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327319105!12193022!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7314 invoked from network); 23 Jan 2012 11:45:07 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:45:07 -0000
Received: by iaeh11 with SMTP id h11so19295759iae.30
	for <multiple recipients>; Mon, 23 Jan 2012 03:45: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
	:cc:content-type;
	bh=sA9eOOLpFudplzu1YPkigy5IFLA+5ys85lS7xy5sYLM=;
	b=hypPn92bxVMKz9/iF9iLbutmbCYuDybItU37o/jVgvtGL4lH31Q3Oa8s5wghmTF13l
	Mfc6McBdqR9NO0mjHrrOxuvP1scrW5d1+xL7PxEBW0Pvx8FapZLo12xzL7qgZKfqFNvD
	U7QzzrRftZdK8C3xUmoavorh0VORYQdDW7WN8=
MIME-Version: 1.0
Received: by 10.50.76.225 with SMTP id n1mr9599023igw.11.1327319105596; Mon,
	23 Jan 2012 03:45:05 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 23 Jan 2012 03:45:05 -0800 (PST)
In-Reply-To: <CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
Date: Mon, 23 Jan 2012 12:45:05 +0100
Message-ID: <CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: John Sherwood <jrs@vt.edu>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0378095392514391591=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0378095392514391591==
Content-Type: multipart/alternative; boundary=e89a8f3ba4e5caeb0804b7308f0b

--e89a8f3ba4e5caeb0804b7308f0b
Content-Type: text/plain; charset=ISO-8859-1

Hi John,

I am trying to pass my secondary graphics card through to the VM. My dom0
runs with the primary card (an onboard GPU).

What happens with me is that the secondary card (GTX480) is relinquished to
pciback and according to the logs, it looks like the card is passed through
successfully to the domU.
What happens though is a bit puzzling (with gfx_passthru=1):
1) When I start the domU, my dom0 screen goes blank (which is using a
different graphics card than is assigned to the domU)
2) The domain does not boot; i.e. the CDROM does not spin up.
3) If I connect to the domain via vnc, I see only the qemu console.

With gfx_passthru=0, the following happens:
a) The domain boots fine (the CDROM spins up).
b) I can connect to the OS in the domain via vnc.
c) The Windows OS installs fine and functions fine afterwards too.
d) I can see the GFX480 card in the device manager, but I can not use the
device (even if I install the correct drivers for it)

Check out the details of my problem
here<http://lists.xen.org/archives/html/xen-devel/2012-01/msg01626.html>.
I have marked the things that concern me in red. I am obviously missing
something...

Regards

Sandi






On Fri, Jan 20, 2012 at 8:46 PM, John Sherwood <jrs@vt.edu> wrote:

> Most people run Xen for headless virtual machines, and VGA passthrough
> requires VT-d support in both the CPU and motherboard.  VGA passthrough is
> also somewhat dependent on the card you're using it with, so it's a hard
> thing to test.  If you want it to get more love, then you're the best
> situated person to do it :)
>
> However, on the topic of Sandi's issue:
> If your monitor goes black, that's a GOOD sign - it's indicative that the
> dom0 is relinquishing control of the graphics card, so at least that's
> working.  In my experience using graphics passthrough, this problem is
> related to your card not being fully supported; essentially, Xen can't pass
> your card through to the VM during boot.  If you leave the `gfx_passthru`
> option *disabled*, you'll have the emulated cirrus card (by default) and it
> will at least boot successfully.  Here's some step by step
> suggestions/instructions:
>
>
>    - disable gfx_passthru in config (delete the option or set it to 0)
>    - enable VNC, listening on all interfaces
>    - start the VM - your screen should still go black
>    - From another machine (what with your screen being black), connect in
>    via VNC and fire up the device manager in XP.  I don't have any XP boxes
>    left, but in Windows 7, you should see a device in an error state under
>    'Display adapters'.
>    - Check its PCI slot under 'details' - "Location Paths" should help.
>    Compare that to `xm pci-list [domain name]` to see if it matches up with
>    the graphics card.
>    - Install the driver for that device
>    - Reboot.  You won't see the BIOS on the monitor, but it should use it
>    once Windows takes over.
>
> If something in there doesn't work, hopefully I can help you debug - I
> went through a lot of this a while back.
>
>
>

--e89a8f3ba4e5caeb0804b7308f0b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi John,<div><br></div><div>I am trying to pass my secondary graphics card =
through to the VM. My dom0 runs with the primary card (an onboard GPU).</di=
v><div><br></div><div>What happens with me is that the secondary card (GTX4=
80) is relinquished to pciback and according to the logs, it looks like the=
 card is passed through successfully to the domU.</div>
<div>What happens though is a bit=A0puzzling (with gfx_passthru=3D1):</div>=
<div>1) When I start the domU, my dom0 screen goes blank (which is using a =
different graphics card than is assigned to the domU)</div><div>2) The doma=
in does not boot; i.e. the CDROM does not spin up.</div>
<div>3) If I connect to the domain via vnc, I see only the qemu console.</d=
iv><div><br></div><div>With gfx_passthru=3D0, the following happens:</div><=
div>a) The domain boots fine (the CDROM spins up).</div><div>b) I can conne=
ct to the OS in the domain via vnc.</div>
<div>c) The Windows OS installs fine and functions fine afterwards too.</di=
v><div>d) I can see the GFX480 card in the device manager, but I can not us=
e the device (even if I install the correct drivers for it)</div><div><br>
</div><div>Check out the details of my problem <a href=3D"http://lists.xen.=
org/archives/html/xen-devel/2012-01/msg01626.html">here</a>. I have marked =
the things that concern me in red. I am obviously missing something...</div=
>
<div><br></div><div>Regards</div><div><br></div><div>Sandi</div><div><br></=
div><div><br></div><div><br></div><div><br></div><div><br><br><div class=3D=
"gmail_quote">On Fri, Jan 20, 2012 at 8:46 PM, John Sherwood <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jrs@vt.edu">jrs@vt.edu</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">Most people run Xen for headless virtual mac=
hines, and VGA passthrough requires VT-d support in both the CPU and mother=
board.=A0 VGA passthrough is also somewhat dependent on the card you&#39;re=
 using it with, so it&#39;s a hard thing to test.=A0 If you want it to get =
more love, then you&#39;re the best situated person to do it :)<br>

<br>However, on the topic of Sandi&#39;s issue:<br>If your monitor goes bla=
ck, that&#39;s a GOOD sign - it&#39;s indicative that the dom0 is relinquis=
hing control of the graphics card, so at least that&#39;s working.=A0 In my=
 experience using graphics passthrough, this problem is related to your car=
d not being fully supported; essentially, Xen can&#39;t pass your card thro=
ugh to the VM during boot.=A0 If you leave the `gfx_passthru` option *disab=
led*, you&#39;ll have the emulated cirrus card (by default) and it will at =
least boot successfully.=A0 Here&#39;s some step by step suggestions/instru=
ctions:<br>

<br><ul><li>disable gfx_passthru in config (delete the option or set it to =
0)<br></li><li>enable VNC, listening on all interfaces</li><li>start the VM=
 - your screen should still go black</li><li>From another machine (what wit=
h your screen being black), connect in via VNC and fire up the device manag=
er in XP.=A0 I don&#39;t have any XP boxes left, but in Windows 7, you shou=
ld see a device in an error state under &#39;Display adapters&#39;.</li>

<li>Check its PCI slot under &#39;details&#39; - &quot;Location Paths&quot;=
 should help.=A0 Compare that to `xm pci-list [domain name]` to see if it m=
atches up with the graphics card.</li><li>Install the driver for that devic=
e</li>

<li>Reboot.=A0 You won&#39;t see the BIOS on the monitor, but it should use=
 it once Windows takes over.</li></ul><p>If something in there doesn&#39;t =
work, hopefully I can help you debug - I went through a lot of this a while=
 back.<br>

</p><div class=3D"HOEnZb"><div class=3D"h5"><br><div class=3D"gmail_quote">=
<br></div></div></div></blockquote></div></div>

--e89a8f3ba4e5caeb0804b7308f0b--


--===============0378095392514391591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0378095392514391591==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:45:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIKq-0002pf-7x; Mon, 23 Jan 2012 11:45:16 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RpIKo-0002oZ-SX; Mon, 23 Jan 2012 11:45:15 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327319105!12193022!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7314 invoked from network); 23 Jan 2012 11:45:07 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:45:07 -0000
Received: by iaeh11 with SMTP id h11so19295759iae.30
	for <multiple recipients>; Mon, 23 Jan 2012 03:45: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
	:cc:content-type;
	bh=sA9eOOLpFudplzu1YPkigy5IFLA+5ys85lS7xy5sYLM=;
	b=hypPn92bxVMKz9/iF9iLbutmbCYuDybItU37o/jVgvtGL4lH31Q3Oa8s5wghmTF13l
	Mfc6McBdqR9NO0mjHrrOxuvP1scrW5d1+xL7PxEBW0Pvx8FapZLo12xzL7qgZKfqFNvD
	U7QzzrRftZdK8C3xUmoavorh0VORYQdDW7WN8=
MIME-Version: 1.0
Received: by 10.50.76.225 with SMTP id n1mr9599023igw.11.1327319105596; Mon,
	23 Jan 2012 03:45:05 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 23 Jan 2012 03:45:05 -0800 (PST)
In-Reply-To: <CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
Date: Mon, 23 Jan 2012 12:45:05 +0100
Message-ID: <CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: John Sherwood <jrs@vt.edu>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0378095392514391591=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0378095392514391591==
Content-Type: multipart/alternative; boundary=e89a8f3ba4e5caeb0804b7308f0b

--e89a8f3ba4e5caeb0804b7308f0b
Content-Type: text/plain; charset=ISO-8859-1

Hi John,

I am trying to pass my secondary graphics card through to the VM. My dom0
runs with the primary card (an onboard GPU).

What happens with me is that the secondary card (GTX480) is relinquished to
pciback and according to the logs, it looks like the card is passed through
successfully to the domU.
What happens though is a bit puzzling (with gfx_passthru=1):
1) When I start the domU, my dom0 screen goes blank (which is using a
different graphics card than is assigned to the domU)
2) The domain does not boot; i.e. the CDROM does not spin up.
3) If I connect to the domain via vnc, I see only the qemu console.

With gfx_passthru=0, the following happens:
a) The domain boots fine (the CDROM spins up).
b) I can connect to the OS in the domain via vnc.
c) The Windows OS installs fine and functions fine afterwards too.
d) I can see the GFX480 card in the device manager, but I can not use the
device (even if I install the correct drivers for it)

Check out the details of my problem
here<http://lists.xen.org/archives/html/xen-devel/2012-01/msg01626.html>.
I have marked the things that concern me in red. I am obviously missing
something...

Regards

Sandi






On Fri, Jan 20, 2012 at 8:46 PM, John Sherwood <jrs@vt.edu> wrote:

> Most people run Xen for headless virtual machines, and VGA passthrough
> requires VT-d support in both the CPU and motherboard.  VGA passthrough is
> also somewhat dependent on the card you're using it with, so it's a hard
> thing to test.  If you want it to get more love, then you're the best
> situated person to do it :)
>
> However, on the topic of Sandi's issue:
> If your monitor goes black, that's a GOOD sign - it's indicative that the
> dom0 is relinquishing control of the graphics card, so at least that's
> working.  In my experience using graphics passthrough, this problem is
> related to your card not being fully supported; essentially, Xen can't pass
> your card through to the VM during boot.  If you leave the `gfx_passthru`
> option *disabled*, you'll have the emulated cirrus card (by default) and it
> will at least boot successfully.  Here's some step by step
> suggestions/instructions:
>
>
>    - disable gfx_passthru in config (delete the option or set it to 0)
>    - enable VNC, listening on all interfaces
>    - start the VM - your screen should still go black
>    - From another machine (what with your screen being black), connect in
>    via VNC and fire up the device manager in XP.  I don't have any XP boxes
>    left, but in Windows 7, you should see a device in an error state under
>    'Display adapters'.
>    - Check its PCI slot under 'details' - "Location Paths" should help.
>    Compare that to `xm pci-list [domain name]` to see if it matches up with
>    the graphics card.
>    - Install the driver for that device
>    - Reboot.  You won't see the BIOS on the monitor, but it should use it
>    once Windows takes over.
>
> If something in there doesn't work, hopefully I can help you debug - I
> went through a lot of this a while back.
>
>
>

--e89a8f3ba4e5caeb0804b7308f0b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi John,<div><br></div><div>I am trying to pass my secondary graphics card =
through to the VM. My dom0 runs with the primary card (an onboard GPU).</di=
v><div><br></div><div>What happens with me is that the secondary card (GTX4=
80) is relinquished to pciback and according to the logs, it looks like the=
 card is passed through successfully to the domU.</div>
<div>What happens though is a bit=A0puzzling (with gfx_passthru=3D1):</div>=
<div>1) When I start the domU, my dom0 screen goes blank (which is using a =
different graphics card than is assigned to the domU)</div><div>2) The doma=
in does not boot; i.e. the CDROM does not spin up.</div>
<div>3) If I connect to the domain via vnc, I see only the qemu console.</d=
iv><div><br></div><div>With gfx_passthru=3D0, the following happens:</div><=
div>a) The domain boots fine (the CDROM spins up).</div><div>b) I can conne=
ct to the OS in the domain via vnc.</div>
<div>c) The Windows OS installs fine and functions fine afterwards too.</di=
v><div>d) I can see the GFX480 card in the device manager, but I can not us=
e the device (even if I install the correct drivers for it)</div><div><br>
</div><div>Check out the details of my problem <a href=3D"http://lists.xen.=
org/archives/html/xen-devel/2012-01/msg01626.html">here</a>. I have marked =
the things that concern me in red. I am obviously missing something...</div=
>
<div><br></div><div>Regards</div><div><br></div><div>Sandi</div><div><br></=
div><div><br></div><div><br></div><div><br></div><div><br><br><div class=3D=
"gmail_quote">On Fri, Jan 20, 2012 at 8:46 PM, John Sherwood <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jrs@vt.edu">jrs@vt.edu</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">Most people run Xen for headless virtual mac=
hines, and VGA passthrough requires VT-d support in both the CPU and mother=
board.=A0 VGA passthrough is also somewhat dependent on the card you&#39;re=
 using it with, so it&#39;s a hard thing to test.=A0 If you want it to get =
more love, then you&#39;re the best situated person to do it :)<br>

<br>However, on the topic of Sandi&#39;s issue:<br>If your monitor goes bla=
ck, that&#39;s a GOOD sign - it&#39;s indicative that the dom0 is relinquis=
hing control of the graphics card, so at least that&#39;s working.=A0 In my=
 experience using graphics passthrough, this problem is related to your car=
d not being fully supported; essentially, Xen can&#39;t pass your card thro=
ugh to the VM during boot.=A0 If you leave the `gfx_passthru` option *disab=
led*, you&#39;ll have the emulated cirrus card (by default) and it will at =
least boot successfully.=A0 Here&#39;s some step by step suggestions/instru=
ctions:<br>

<br><ul><li>disable gfx_passthru in config (delete the option or set it to =
0)<br></li><li>enable VNC, listening on all interfaces</li><li>start the VM=
 - your screen should still go black</li><li>From another machine (what wit=
h your screen being black), connect in via VNC and fire up the device manag=
er in XP.=A0 I don&#39;t have any XP boxes left, but in Windows 7, you shou=
ld see a device in an error state under &#39;Display adapters&#39;.</li>

<li>Check its PCI slot under &#39;details&#39; - &quot;Location Paths&quot;=
 should help.=A0 Compare that to `xm pci-list [domain name]` to see if it m=
atches up with the graphics card.</li><li>Install the driver for that devic=
e</li>

<li>Reboot.=A0 You won&#39;t see the BIOS on the monitor, but it should use=
 it once Windows takes over.</li></ul><p>If something in there doesn&#39;t =
work, hopefully I can help you debug - I went through a lot of this a while=
 back.<br>

</p><div class=3D"HOEnZb"><div class=3D"h5"><br><div class=3D"gmail_quote">=
<br></div></div></div></blockquote></div></div>

--e89a8f3ba4e5caeb0804b7308f0b--


--===============0378095392514391591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0378095392514391591==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:50:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIPu-0003rG-9S; Mon, 23 Jan 2012 11:50:30 +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 1RpIPs-0003q8-Rv
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:50:29 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327319422!12063971!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzE0NzA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16373 invoked from network); 23 Jan 2012 11:50:22 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 11:50:22 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q0NBoGsc015054;
	Mon, 23 Jan 2012 12:50:16 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NBoC7P017298;
	Mon, 23 Jan 2012 12:50:12 +0100
Message-ID: <4F1D4974.4090003@siemens.com>
Date: Mon, 23 Jan 2012 12:50:12 +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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 11:47, Stefano Stabellini wrote:
> On Fri, 20 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-20 18:20, Stefano Stabellini wrote:
>>> Hi all,
>>> this is the fourth version of the Xen save/restore patch series.
>>> We have been discussing this issue for quite a while on #qemu and
>>> qemu-devel:
>>>
>>>
>>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
>>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
>>>
>>>
>>> A few different approaches were proposed to achieve the goal
>>> of a working save/restore with upstream Qemu on Xen, however after
>>> prototyping some of them I came up with yet another solution, that I
>>> think leads to the best results with the less amount of code
>>> duplications and ugliness.
>>> Far from saying that this patch series is an example of elegance and
>>> simplicity, but it is closer to acceptable anything else I have seen so
>>> far.
>>>
>>> What's new is that Qemu is going to keep track of its own physmap on
>>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
>>> the guest's memory map at any time.
>>> This is all handled by Xen or Xen support in Qemu internally and can be
>>> used to solve our save/restore framebuffer problem.
>>>
>>> >From the Qemu common code POV, we still need to avoid saving the guest's
>>> ram when running on Xen, and we need to avoid resetting the videoram on
>>> restore (that is a benefit to the generic Qemu case too, because it
>>> saves few cpu cycles).
>>
>> For my understanding: Refraining from the memset is required as the
>> already restored vram would then be overwritten?
> 
> Yep
> 
>> Or what is the ordering
>> of init, RAM restore, and initial device reset now?
> 
> RAM restore (done by Xen)
> 
> physmap rebuild (done by xen_hvm_init in qemu)
> pc_init()
> qemu_system_reset()
> load_vmstate()

Hmm, are you sure that this is the only case where a device init or
reset handler writes to already restored guest memory? Preloading the
RAM this way is a non-standard scenario for QEMU, thus conceptually
fragile. Does restoring happen before QEMU is even started, or can this
point be controlled from QEMU?

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 Jan 23 11:50:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:50:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIPu-0003rG-9S; Mon, 23 Jan 2012 11:50:30 +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 1RpIPs-0003q8-Rv
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:50:29 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327319422!12063971!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzE0NzA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16373 invoked from network); 23 Jan 2012 11:50:22 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 11:50:22 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q0NBoGsc015054;
	Mon, 23 Jan 2012 12:50:16 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NBoC7P017298;
	Mon, 23 Jan 2012 12:50:12 +0100
Message-ID: <4F1D4974.4090003@siemens.com>
Date: Mon, 23 Jan 2012 12:50:12 +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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 11:47, Stefano Stabellini wrote:
> On Fri, 20 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-20 18:20, Stefano Stabellini wrote:
>>> Hi all,
>>> this is the fourth version of the Xen save/restore patch series.
>>> We have been discussing this issue for quite a while on #qemu and
>>> qemu-devel:
>>>
>>>
>>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
>>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
>>>
>>>
>>> A few different approaches were proposed to achieve the goal
>>> of a working save/restore with upstream Qemu on Xen, however after
>>> prototyping some of them I came up with yet another solution, that I
>>> think leads to the best results with the less amount of code
>>> duplications and ugliness.
>>> Far from saying that this patch series is an example of elegance and
>>> simplicity, but it is closer to acceptable anything else I have seen so
>>> far.
>>>
>>> What's new is that Qemu is going to keep track of its own physmap on
>>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
>>> the guest's memory map at any time.
>>> This is all handled by Xen or Xen support in Qemu internally and can be
>>> used to solve our save/restore framebuffer problem.
>>>
>>> >From the Qemu common code POV, we still need to avoid saving the guest's
>>> ram when running on Xen, and we need to avoid resetting the videoram on
>>> restore (that is a benefit to the generic Qemu case too, because it
>>> saves few cpu cycles).
>>
>> For my understanding: Refraining from the memset is required as the
>> already restored vram would then be overwritten?
> 
> Yep
> 
>> Or what is the ordering
>> of init, RAM restore, and initial device reset now?
> 
> RAM restore (done by Xen)
> 
> physmap rebuild (done by xen_hvm_init in qemu)
> pc_init()
> qemu_system_reset()
> load_vmstate()

Hmm, are you sure that this is the only case where a device init or
reset handler writes to already restored guest memory? Preloading the
RAM this way is a non-standard scenario for QEMU, thus conceptually
fragile. Does restoring happen before QEMU is even started, or can this
point be controlled from QEMU?

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 Jan 23 11:51:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpIR9-00045T-Pi; Mon, 23 Jan 2012 11:51:47 +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 1RpIR7-00044L-Uf
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:51:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327319498!10297312!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2710 invoked from network); 23 Jan 2012 11:51:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:51:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320642000"; d="scan'208";a="178638243"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 06:51: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; Mon, 23 Jan 2012 06:51:36 -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 q0NBpYnC031016;
	Mon, 23 Jan 2012 03:51:35 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 23 Jan 2012 11:51:15 +0000
Message-ID: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two grant
	references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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>
---
 xen/arch/x86/hvm/hvm.c           |    1 +
 xen/common/grant_table.c         |   86 ++++++++++++++++++++++++++++++++++++++
 xen/include/public/grant_table.h |   18 +++++++-
 xen/include/xlat.lst             |    1 +
 4 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b3d9ac0..c46bd3e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int cmd)
     case GNTTABOP_copy:
     case GNTTABOP_map_grant_ref:
     case GNTTABOP_unmap_grant_ref:
+    case GNTTABOP_swap_grant_ref:
         return 1;
     default:
         /* all other commands need auditing */
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 34a49db..1147a3b 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2282,6 +2282,78 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     return 0;
 }
 
+static s16
+__gnttab_swap_grant_ref(unsigned long ref_a, unsigned long ref_b)
+{
+    struct domain *d;
+    struct active_grant_entry *act;
+    s16 rc = GNTST_okay;
+
+    d = rcu_lock_current_domain();
+
+    spin_lock(&d->grant_table->lock);
+
+    act = &active_entry(d->grant_table, ref_a);
+    if ( act->pin )
+        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_a);
+
+    act = &active_entry(d->grant_table, ref_b);
+    if ( act->pin )
+        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_b);
+
+    if ( d->grant_table->gt_version == 1 ) {
+        grant_entry_v1_t shared;
+
+        shared = shared_entry_v1(d->grant_table, ref_a);
+
+        shared_entry_v1(d->grant_table, ref_a) =
+            shared_entry_v1(d->grant_table, ref_b);
+
+        shared_entry_v1(d->grant_table, ref_b) = shared;
+    } else {
+        grant_entry_v2_t shared;
+        grant_status_t status;
+
+        shared = shared_entry_v2(d->grant_table, ref_a);
+        status = status_entry(d->grant_table, ref_a);
+
+        shared_entry_v2(d->grant_table, ref_a) =
+            shared_entry_v2(d->grant_table, ref_b);
+        status_entry(d->grant_table, ref_a) =
+            status_entry(d->grant_table, ref_b);
+
+        shared_entry_v2(d->grant_table, ref_b) = shared;
+        status_entry(d->grant_table, ref_b) = status;
+    }
+
+out:
+    spin_unlock(&d->grant_table->lock);
+
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+static long
+gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
+                      unsigned int count)
+{
+    int i;
+    gnttab_swap_grant_ref_t op;
+
+    for ( i = 0; i < count; i++ )
+    {
+        if ( i && hypercall_preempt_check() )
+            return i;
+        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
+            return -EFAULT;
+        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
+        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
+            return -EFAULT;
+    }
+    return 0;
+}
+
 long
 do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
@@ -2400,6 +2472,20 @@ do_grant_table_op(
         rc = gnttab_get_version(guest_handle_cast(uop, gnttab_get_version_t));
         break;
     }
+    case GNTTABOP_swap_grant_ref:
+    {
+        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
+            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
+        if ( unlikely(!guest_handle_okay(swap, count)) )
+            goto out;
+        rc = gnttab_swap_grant_ref(swap, count);
+        if ( rc > 0 )
+        {
+            guest_handle_add_offset(swap, rc);
+            uop = guest_handle_cast(swap, void);
+        }
+        break;
+    }
     default:
         rc = -ENOSYS;
         break;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..54d9551 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -511,6 +511,20 @@ struct gnttab_get_version {
 typedef struct gnttab_get_version gnttab_get_version_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
 
+/* 
+ * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
+ */
+#define GNTTABOP_swap_grant_ref	      11
+struct gnttab_swap_grant_ref {
+    /* IN parameters */
+    grant_ref_t ref_a;
+    grant_ref_t ref_b;
+    /* OUT parameters */
+    int16_t status;             /* GNTST_* */
+};
+typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
+DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
+
 #endif /* __XEN_INTERFACE_VERSION__ */
 
 /*
@@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
 #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 GNTST_eagain          (-12) /* Operation not done; try again.        */
 
 #define GNTTABOP_error_msgs {                   \
     "okay",                                     \
@@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
     "bad page",                                 \
     "copy arguments cross page boundary",       \
     "page address size too large",              \
-    "could not map at the moment, retry"        \
+    "operation not done; try again"             \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..f602155 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -50,6 +50,7 @@
 ?	grant_entry_v1			grant_table.h
 ?       grant_entry_header              grant_table.h
 ?	grant_entry_v2			grant_table.h
+?	gnttab_swap_grant_ref		grant_table.h
 ?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
 !	kexec_range			kexec.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 Jan 23 11:51:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11: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 1RpIR9-00045T-Pi; Mon, 23 Jan 2012 11:51:47 +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 1RpIR7-00044L-Uf
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:51:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327319498!10297312!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2710 invoked from network); 23 Jan 2012 11:51:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:51:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320642000"; d="scan'208";a="178638243"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 06:51: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; Mon, 23 Jan 2012 06:51:36 -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 q0NBpYnC031016;
	Mon, 23 Jan 2012 03:51:35 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 23 Jan 2012 11:51:15 +0000
Message-ID: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: paul.durrant@citrix.com, Wei Liu <wei.liu2@citrix.com>
Subject: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two grant
	references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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>
---
 xen/arch/x86/hvm/hvm.c           |    1 +
 xen/common/grant_table.c         |   86 ++++++++++++++++++++++++++++++++++++++
 xen/include/public/grant_table.h |   18 +++++++-
 xen/include/xlat.lst             |    1 +
 4 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b3d9ac0..c46bd3e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int cmd)
     case GNTTABOP_copy:
     case GNTTABOP_map_grant_ref:
     case GNTTABOP_unmap_grant_ref:
+    case GNTTABOP_swap_grant_ref:
         return 1;
     default:
         /* all other commands need auditing */
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 34a49db..1147a3b 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2282,6 +2282,78 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     return 0;
 }
 
+static s16
+__gnttab_swap_grant_ref(unsigned long ref_a, unsigned long ref_b)
+{
+    struct domain *d;
+    struct active_grant_entry *act;
+    s16 rc = GNTST_okay;
+
+    d = rcu_lock_current_domain();
+
+    spin_lock(&d->grant_table->lock);
+
+    act = &active_entry(d->grant_table, ref_a);
+    if ( act->pin )
+        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_a);
+
+    act = &active_entry(d->grant_table, ref_b);
+    if ( act->pin )
+        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_b);
+
+    if ( d->grant_table->gt_version == 1 ) {
+        grant_entry_v1_t shared;
+
+        shared = shared_entry_v1(d->grant_table, ref_a);
+
+        shared_entry_v1(d->grant_table, ref_a) =
+            shared_entry_v1(d->grant_table, ref_b);
+
+        shared_entry_v1(d->grant_table, ref_b) = shared;
+    } else {
+        grant_entry_v2_t shared;
+        grant_status_t status;
+
+        shared = shared_entry_v2(d->grant_table, ref_a);
+        status = status_entry(d->grant_table, ref_a);
+
+        shared_entry_v2(d->grant_table, ref_a) =
+            shared_entry_v2(d->grant_table, ref_b);
+        status_entry(d->grant_table, ref_a) =
+            status_entry(d->grant_table, ref_b);
+
+        shared_entry_v2(d->grant_table, ref_b) = shared;
+        status_entry(d->grant_table, ref_b) = status;
+    }
+
+out:
+    spin_unlock(&d->grant_table->lock);
+
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+static long
+gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
+                      unsigned int count)
+{
+    int i;
+    gnttab_swap_grant_ref_t op;
+
+    for ( i = 0; i < count; i++ )
+    {
+        if ( i && hypercall_preempt_check() )
+            return i;
+        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
+            return -EFAULT;
+        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
+        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
+            return -EFAULT;
+    }
+    return 0;
+}
+
 long
 do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
@@ -2400,6 +2472,20 @@ do_grant_table_op(
         rc = gnttab_get_version(guest_handle_cast(uop, gnttab_get_version_t));
         break;
     }
+    case GNTTABOP_swap_grant_ref:
+    {
+        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
+            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
+        if ( unlikely(!guest_handle_okay(swap, count)) )
+            goto out;
+        rc = gnttab_swap_grant_ref(swap, count);
+        if ( rc > 0 )
+        {
+            guest_handle_add_offset(swap, rc);
+            uop = guest_handle_cast(swap, void);
+        }
+        break;
+    }
     default:
         rc = -ENOSYS;
         break;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..54d9551 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -511,6 +511,20 @@ struct gnttab_get_version {
 typedef struct gnttab_get_version gnttab_get_version_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
 
+/* 
+ * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
+ */
+#define GNTTABOP_swap_grant_ref	      11
+struct gnttab_swap_grant_ref {
+    /* IN parameters */
+    grant_ref_t ref_a;
+    grant_ref_t ref_b;
+    /* OUT parameters */
+    int16_t status;             /* GNTST_* */
+};
+typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
+DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
+
 #endif /* __XEN_INTERFACE_VERSION__ */
 
 /*
@@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
 #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 GNTST_eagain          (-12) /* Operation not done; try again.        */
 
 #define GNTTABOP_error_msgs {                   \
     "okay",                                     \
@@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
     "bad page",                                 \
     "copy arguments cross page boundary",       \
     "page address size too large",              \
-    "could not map at the moment, retry"        \
+    "operation not done; try again"             \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..f602155 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -50,6 +50,7 @@
 ?	grant_entry_v1			grant_table.h
 ?       grant_entry_header              grant_table.h
 ?	grant_entry_v2			grant_table.h
+?	gnttab_swap_grant_ref		grant_table.h
 ?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
 !	kexec_range			kexec.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 Jan 23 11:53:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpITA-0004QT-IG; Mon, 23 Jan 2012 11:53:52 +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 1RpIT9-0004PQ-ML
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:53:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327319625!10297696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12525 invoked from network); 23 Jan 2012 11:53:45 -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;
	23 Jan 2012 11:53:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10211967"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:53:45 +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;
	Mon, 23 Jan 2012 11:53:44 +0000
Message-ID: <1327319588.3921.7.camel@liuw-workstation>
From: Wei Liu <wei.liu2@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 11:53:08 +0000
In-Reply-To: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Paul

Can you please sign this off as well since you're the original author.

I only did a few space changes.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:53:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:53:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpITA-0004QT-IG; Mon, 23 Jan 2012 11:53:52 +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 1RpIT9-0004PQ-ML
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:53:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327319625!10297696!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12525 invoked from network); 23 Jan 2012 11:53:45 -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;
	23 Jan 2012 11:53:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10211967"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:53:45 +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;
	Mon, 23 Jan 2012 11:53:44 +0000
Message-ID: <1327319588.3921.7.camel@liuw-workstation>
From: Wei Liu <wei.liu2@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 11:53:08 +0000
In-Reply-To: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Paul

Can you please sign this off as well since you're the original author.

I only did a few space changes.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:54:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:54:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpITJ-0004Sb-1H; Mon, 23 Jan 2012 11:54:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RpITH-0004Ql-Bp; Mon, 23 Jan 2012 11:53:59 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327319631!8225304!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23481 invoked from network); 23 Jan 2012 11:53:52 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:53:52 -0000
Received: by iaeh11 with SMTP id h11so19329363iae.30
	for <multiple recipients>; Mon, 23 Jan 2012 03:53: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
	:cc:content-type;
	bh=kI1qLRhP0KyP63AmNZGvRdqHKPupEEJLe3F+Fkk3kxc=;
	b=BL6tolj8bTTPFuOxRcujY28A9iOr553RsP/xqALB8kYPNxHop7DT4eawOhrDPf9w3B
	QMi1uRh3QFTRvO421+B8ugyhtmZTUdaJreURVnFl7ov0Ohl5oFznRDn6MocqbOxHYHpt
	6clr0a2PXSa/LF7bixUjjxN6BmSMVibahdJeE=
MIME-Version: 1.0
Received: by 10.50.17.195 with SMTP id q3mr9644484igd.11.1327319631029; Mon,
	23 Jan 2012 03:53:51 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 23 Jan 2012 03:53:50 -0800 (PST)
In-Reply-To: <20120120203205.GW12984@reaktio.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<20120120203205.GW12984@reaktio.net>
Date: Mon, 23 Jan 2012 12:53:50 +0100
Message-ID: <CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2339769327084611573=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2339769327084611573==
Content-Type: multipart/alternative; boundary=14dae93410ef1c641104b730af36

--14dae93410ef1c641104b730af36
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi,

Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:

(XEN) I/O virtualisation enabled

(XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
supported.(XEN) Intel VT-d Interrupt Remapping not supported.

But I dont think I have this message (I am not near my system now, so I can
not confirm)

(XEN) I/O virtualisation for PV guests enabled


I believe that many have managed to get VGA passthru working, but they
generally dont post their stories. one only finds the problems they are
encountering when searching about this. That is why it would be nice to put
together a kind of manual in the wiki which would have all this info
together in one location.

Thanks for the help

Regards

Sandi


On Fri, Jan 20, 2012 at 9:32 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Fri, Jan 20, 2012 at 05:49:20PM +0100, Sandi Romih wrote:
> >    Pasi,
> >
> >    I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e
> CPU.
> >
>
> Ok. And Xen enables IOMMU? Did you verify from Xen's dmesg ?
>
>
> http://wiki.xen.org/xenwiki/XenCommonProblems.html#head-2f76ed2d3c2820034=
18d37fbbcda510cac266f89
>
>
>
> >    Have you managed to pass your gpu through to the domU?
> >
>
> No, I haven't tried that yet. I've been planning to, but I haven't had
> time for it yet.
>
> There are many people who are using Xen VGA passthru with Intel, AMD/ATI
> and Nvidia graphics cards.
> Currently it needs a lot of understanding and some custom patching, but
> you can make it work.
>
> There are even businesses using Xen VGA passthru in production :)
>
> -- Pasi
>
> >
> >    Sandi
> >
> >    On Jan 20, 2012 4:47 PM, "Pasi K=E4rkk=E4inen" <[1]pasik@iki.fi> wro=
te:
> >
> >      On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> >      >    Hello,
> >      >    I have spent a lot of time trying to get gfx passthru working
> on my
> >      system
> >      >    without success.
> >      >    I looked onto my hardware capabilities again to make sure tha=
t
> it
> >      does
> >      >    support VT-d and I am not too sure that it does fully.
> >      >    My hardware is as follows:
> >      >    - Supermicro X8DTH-6F motherboard (5520 chipset which support=
s
> >      VT-d)
> >      >    - single Xeon X5650 CPU (which is listed as supporting VT-x, =
no
> >      mention of
> >      >    VT-d at [1][2]ark.intel.com)
> >      >    Now, according to the [2]VTdHowTo, the motherboard BIOS,
> chipset
> >      AND CPU
> >      >    need to support VT-d.
> >      >    What confuses me is, why is the 55x0 chipset listed there if
> none
> >      of the
> >      >    CPU's supported, that I know of, dont have the VT-d feature
> option,
> >      only
> >      >    VT-x.
> >      >
> >
> >      I've been using VT-d with Xen with Intel 5500 series chipset, and
> Xeon
> >      5600 series CPU.
> >      VT-d needs to be enabled in the BIOS.
> >
> >      -- Pasi
> >
> > References
> >
> >    Visible links
> >    1. mailto:pasik@iki.fi
> >    2. http://ark.intel.com/
>

--14dae93410ef1c641104b730af36
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi,<div><br></div><div>Yes, I did verify that IOMMU is enabled. I get thi=
s in my xm dmesg:</div><div><pre style=3D"border-top-width:1pt;border-right=
-width:1pt;border-bottom-width:1pt;border-left-width:1pt;border-top-style:s=
olid;border-right-style:solid;border-bottom-style:solid;border-left-style:s=
olid;border-top-color:rgb(174,189,204);border-right-color:rgb(174,189,204);=
border-bottom-color:rgb(174,189,204);border-left-color:rgb(174,189,204);bac=
kground-color:rgb(255,255,255);padding-top:5pt;padding-right:5pt;padding-bo=
ttom:5pt;padding-left:5pt;font-family:courier,monospace;white-space:pre-wra=
p;word-wrap:break-word;color:rgb(51,51,51);font-size:12px">
(XEN) I/O virtualisation enabled
<span class=3D"anchor" id=3D"line-141"></span></pre><span class=3D"anchor" =
id=3D"line-142" style=3D"color:rgb(51,51,51);font-family:Verdana,Arial,Helv=
etica,sans-serif;font-size:12px;background-color:rgb(255,255,255)"></span><=
pre style=3D"border-top-width:1pt;border-right-width:1pt;border-bottom-widt=
h:1pt;border-left-width:1pt;border-top-style:solid;border-right-style:solid=
;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(174=
,189,204);border-right-color:rgb(174,189,204);border-bottom-color:rgb(174,1=
89,204);border-left-color:rgb(174,189,204);background-color:rgb(255,255,255=
);padding-top:5pt;padding-right:5pt;padding-bottom:5pt;padding-left:5pt;fon=
t-family:courier,monospace;white-space:pre-wrap;word-wrap:break-word;color:=
rgb(51,51,51);font-size:12px">
(XEN) Intel VT-d Snoop Control supported.
<span class=3D"anchor" id=3D"line-151"></span>(XEN) Intel VT-d DMA Passthro=
ugh not supported.
<span class=3D"anchor" id=3D"line-152"></span>(XEN) Intel VT-d Queued Inval=
idation supported.
<span class=3D"anchor" id=3D"line-153"></span>(XEN) Intel VT-d Interrupt Re=
mapping not supported.
<span class=3D"anchor" id=3D"line-154"></span></pre><span class=3D"anchor" =
id=3D"line-155" style=3D"color:rgb(51,51,51);font-family:Verdana,Arial,Helv=
etica,sans-serif;font-size:12px;background-color:rgb(255,255,255)"></span><=
p class=3D"line874" style=3D"margin-top:1.12em!important;margin-right:0px!i=
mportant;margin-bottom:1.12em!important;margin-left:0px!important;padding-t=
op:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;font-size:12px=
;color:rgb(51,51,51);font-family:Verdana,Arial,Helvetica,sans-serif;backgro=
und-color:rgb(255,255,255)">
But I dont think I have this message (I am not near my system now, so I can=
 not confirm)<span class=3D"anchor" id=3D"line-157"></span></p><p class=3D"=
line867" style=3D"margin-top:1.12em!important;margin-right:0px!important;ma=
rgin-bottom:1.12em!important;margin-left:0px!important;padding-top:0px;padd=
ing-right:0px;padding-bottom:0px;padding-left:0px;font-size:12px;color:rgb(=
51,51,51);font-family:Verdana,Arial,Helvetica,sans-serif;background-color:r=
gb(255,255,255)">
<span class=3D"anchor" id=3D"line-158"></span></p><pre style=3D"border-top-=
width:1pt;border-right-width:1pt;border-bottom-width:1pt;border-left-width:=
1pt;border-top-style:solid;border-right-style:solid;border-bottom-style:sol=
id;border-left-style:solid;border-top-color:rgb(174,189,204);border-right-c=
olor:rgb(174,189,204);border-bottom-color:rgb(174,189,204);border-left-colo=
r:rgb(174,189,204);background-color:rgb(255,255,255);padding-top:5pt;paddin=
g-right:5pt;padding-bottom:5pt;padding-left:5pt;font-family:courier,monospa=
ce;white-space:pre-wrap;word-wrap:break-word;color:rgb(51,51,51);font-size:=
12px">
(XEN) I/O virtualisation for PV guests enabled</pre><div><br></div><div>I b=
elieve that many have=A0managed=A0to get VGA passthru working, but they gen=
erally dont post their stories. one only finds the problems they are encoun=
tering when searching about this. That is why it would be nice to put toget=
her a kind of manual in the wiki which would have all this info together in=
 one location.</div>
<div><br></div><div>Thanks for the help</div><div><br></div><div>Regards<br=
><br>Sandi</div><div><br></div><br><div class=3D"gmail_quote">On Fri, Jan 2=
0, 2012 at 9:32 PM, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:pasik@iki.fi">pasik@iki.fi</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Fri, Jan 20, 2012 at 05=
:49:20PM +0100, Sandi Romih wrote:<br>
&gt; =A0 =A0Pasi,<br>
&gt;<br>
&gt; =A0 =A0I have that enabled in my BIOS, VT-d for the chipset and VT-x f=
or the CPU.<br>
&gt;<br>
<br>
</div>Ok. And Xen enables IOMMU? Did you verify from Xen&#39;s dmesg ?<br>
<br>
<a href=3D"http://wiki.xen.org/xenwiki/XenCommonProblems.html#head-2f76ed2d=
3c282003418d37fbbcda510cac266f89" target=3D"_blank">http://wiki.xen.org/xen=
wiki/XenCommonProblems.html#head-2f76ed2d3c282003418d37fbbcda510cac266f89</=
a><br>

<div class=3D"im"><br>
<br>
<br>
&gt; =A0 =A0Have you managed to pass your gpu through to the domU?<br>
&gt;<br>
<br>
</div>No, I haven&#39;t tried that yet. I&#39;ve been planning to, but I ha=
ven&#39;t had time for it yet.<br>
<br>
There are many people who are using Xen VGA passthru with Intel, AMD/ATI an=
d Nvidia graphics cards.<br>
Currently it needs a lot of understanding and some custom patching, but you=
 can make it work.<br>
<br>
There are even businesses using Xen VGA passthru in production :)<br>
<br>
-- Pasi<br>
<br>
&gt;<br>
&gt; =A0 =A0Sandi<br>
<div class=3D"im">&gt;<br>
&gt; =A0 =A0On Jan 20, 2012 4:47 PM, &quot;Pasi K=E4rkk=E4inen&quot; &lt;[1=
]<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt; wrote:<br>
&gt;<br>
&gt; =A0 =A0 =A0On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote=
:<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Hello,<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I have spent a lot of time trying to get gfx pa=
ssthru working on my<br>
&gt; =A0 =A0 =A0system<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0without success.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I looked onto my hardware capabilities again to=
 make sure that it<br>
&gt; =A0 =A0 =A0does<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0support VT-d and I am not too sure that it does=
 fully.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0My hardware is as follows:<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0- Supermicro X8DTH-6F motherboard (5520 chipset=
 which supports<br>
&gt; =A0 =A0 =A0VT-d)<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0- single Xeon X5650 CPU (which is listed as sup=
porting VT-x, no<br>
&gt; =A0 =A0 =A0mention of<br>
</div>&gt; =A0 =A0 =A0&gt; =A0 =A0VT-d at [1][2]<a href=3D"http://ark.intel=
.com" target=3D"_blank">ark.intel.com</a>)<br>
<div class=3D"im">&gt; =A0 =A0 =A0&gt; =A0 =A0Now, according to the [2]VTdH=
owTo, the motherboard BIOS, chipset<br>
&gt; =A0 =A0 =A0AND CPU<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0need to support VT-d.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
&gt; =A0 =A0 =A0of the<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature option,<br>
&gt; =A0 =A0 =A0only<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0VT-x.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0I&#39;ve been using VT-d with Xen with Intel 5500 series ch=
ipset, and Xeon<br>
&gt; =A0 =A0 =A05600 series CPU.<br>
&gt; =A0 =A0 =A0VT-d needs to be enabled in the BIOS.<br>
&gt;<br>
&gt; =A0 =A0 =A0-- Pasi<br>
&gt;<br>
</div>&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. mailto:<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a><br>
&gt; =A0 =A02. <a href=3D"http://ark.intel.com/" target=3D"_blank">http://a=
rk.intel.com/</a><br>
</blockquote></div><br></div>

--14dae93410ef1c641104b730af36--


--===============2339769327084611573==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2339769327084611573==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:54:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:54:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpITJ-0004Sb-1H; Mon, 23 Jan 2012 11:54:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>)
	id 1RpITH-0004Ql-Bp; Mon, 23 Jan 2012 11:53:59 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327319631!8225304!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23481 invoked from network); 23 Jan 2012 11:53:52 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 11:53:52 -0000
Received: by iaeh11 with SMTP id h11so19329363iae.30
	for <multiple recipients>; Mon, 23 Jan 2012 03:53: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
	:cc:content-type;
	bh=kI1qLRhP0KyP63AmNZGvRdqHKPupEEJLe3F+Fkk3kxc=;
	b=BL6tolj8bTTPFuOxRcujY28A9iOr553RsP/xqALB8kYPNxHop7DT4eawOhrDPf9w3B
	QMi1uRh3QFTRvO421+B8ugyhtmZTUdaJreURVnFl7ov0Ohl5oFznRDn6MocqbOxHYHpt
	6clr0a2PXSa/LF7bixUjjxN6BmSMVibahdJeE=
MIME-Version: 1.0
Received: by 10.50.17.195 with SMTP id q3mr9644484igd.11.1327319631029; Mon,
	23 Jan 2012 03:53:51 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 23 Jan 2012 03:53:50 -0800 (PST)
In-Reply-To: <20120120203205.GW12984@reaktio.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<20120120203205.GW12984@reaktio.net>
Date: Mon, 23 Jan 2012 12:53:50 +0100
Message-ID: <CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= <pasik@iki.fi>
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2339769327084611573=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2339769327084611573==
Content-Type: multipart/alternative; boundary=14dae93410ef1c641104b730af36

--14dae93410ef1c641104b730af36
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi,

Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:

(XEN) I/O virtualisation enabled

(XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
supported.(XEN) Intel VT-d Interrupt Remapping not supported.

But I dont think I have this message (I am not near my system now, so I can
not confirm)

(XEN) I/O virtualisation for PV guests enabled


I believe that many have managed to get VGA passthru working, but they
generally dont post their stories. one only finds the problems they are
encountering when searching about this. That is why it would be nice to put
together a kind of manual in the wiki which would have all this info
together in one location.

Thanks for the help

Regards

Sandi


On Fri, Jan 20, 2012 at 9:32 PM, Pasi K=E4rkk=E4inen <pasik@iki.fi> wrote:

> On Fri, Jan 20, 2012 at 05:49:20PM +0100, Sandi Romih wrote:
> >    Pasi,
> >
> >    I have that enabled in my BIOS, VT-d for the chipset and VT-x for th=
e
> CPU.
> >
>
> Ok. And Xen enables IOMMU? Did you verify from Xen's dmesg ?
>
>
> http://wiki.xen.org/xenwiki/XenCommonProblems.html#head-2f76ed2d3c2820034=
18d37fbbcda510cac266f89
>
>
>
> >    Have you managed to pass your gpu through to the domU?
> >
>
> No, I haven't tried that yet. I've been planning to, but I haven't had
> time for it yet.
>
> There are many people who are using Xen VGA passthru with Intel, AMD/ATI
> and Nvidia graphics cards.
> Currently it needs a lot of understanding and some custom patching, but
> you can make it work.
>
> There are even businesses using Xen VGA passthru in production :)
>
> -- Pasi
>
> >
> >    Sandi
> >
> >    On Jan 20, 2012 4:47 PM, "Pasi K=E4rkk=E4inen" <[1]pasik@iki.fi> wro=
te:
> >
> >      On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote:
> >      >    Hello,
> >      >    I have spent a lot of time trying to get gfx passthru working
> on my
> >      system
> >      >    without success.
> >      >    I looked onto my hardware capabilities again to make sure tha=
t
> it
> >      does
> >      >    support VT-d and I am not too sure that it does fully.
> >      >    My hardware is as follows:
> >      >    - Supermicro X8DTH-6F motherboard (5520 chipset which support=
s
> >      VT-d)
> >      >    - single Xeon X5650 CPU (which is listed as supporting VT-x, =
no
> >      mention of
> >      >    VT-d at [1][2]ark.intel.com)
> >      >    Now, according to the [2]VTdHowTo, the motherboard BIOS,
> chipset
> >      AND CPU
> >      >    need to support VT-d.
> >      >    What confuses me is, why is the 55x0 chipset listed there if
> none
> >      of the
> >      >    CPU's supported, that I know of, dont have the VT-d feature
> option,
> >      only
> >      >    VT-x.
> >      >
> >
> >      I've been using VT-d with Xen with Intel 5500 series chipset, and
> Xeon
> >      5600 series CPU.
> >      VT-d needs to be enabled in the BIOS.
> >
> >      -- Pasi
> >
> > References
> >
> >    Visible links
> >    1. mailto:pasik@iki.fi
> >    2. http://ark.intel.com/
>

--14dae93410ef1c641104b730af36
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Pasi,<div><br></div><div>Yes, I did verify that IOMMU is enabled. I get thi=
s in my xm dmesg:</div><div><pre style=3D"border-top-width:1pt;border-right=
-width:1pt;border-bottom-width:1pt;border-left-width:1pt;border-top-style:s=
olid;border-right-style:solid;border-bottom-style:solid;border-left-style:s=
olid;border-top-color:rgb(174,189,204);border-right-color:rgb(174,189,204);=
border-bottom-color:rgb(174,189,204);border-left-color:rgb(174,189,204);bac=
kground-color:rgb(255,255,255);padding-top:5pt;padding-right:5pt;padding-bo=
ttom:5pt;padding-left:5pt;font-family:courier,monospace;white-space:pre-wra=
p;word-wrap:break-word;color:rgb(51,51,51);font-size:12px">
(XEN) I/O virtualisation enabled
<span class=3D"anchor" id=3D"line-141"></span></pre><span class=3D"anchor" =
id=3D"line-142" style=3D"color:rgb(51,51,51);font-family:Verdana,Arial,Helv=
etica,sans-serif;font-size:12px;background-color:rgb(255,255,255)"></span><=
pre style=3D"border-top-width:1pt;border-right-width:1pt;border-bottom-widt=
h:1pt;border-left-width:1pt;border-top-style:solid;border-right-style:solid=
;border-bottom-style:solid;border-left-style:solid;border-top-color:rgb(174=
,189,204);border-right-color:rgb(174,189,204);border-bottom-color:rgb(174,1=
89,204);border-left-color:rgb(174,189,204);background-color:rgb(255,255,255=
);padding-top:5pt;padding-right:5pt;padding-bottom:5pt;padding-left:5pt;fon=
t-family:courier,monospace;white-space:pre-wrap;word-wrap:break-word;color:=
rgb(51,51,51);font-size:12px">
(XEN) Intel VT-d Snoop Control supported.
<span class=3D"anchor" id=3D"line-151"></span>(XEN) Intel VT-d DMA Passthro=
ugh not supported.
<span class=3D"anchor" id=3D"line-152"></span>(XEN) Intel VT-d Queued Inval=
idation supported.
<span class=3D"anchor" id=3D"line-153"></span>(XEN) Intel VT-d Interrupt Re=
mapping not supported.
<span class=3D"anchor" id=3D"line-154"></span></pre><span class=3D"anchor" =
id=3D"line-155" style=3D"color:rgb(51,51,51);font-family:Verdana,Arial,Helv=
etica,sans-serif;font-size:12px;background-color:rgb(255,255,255)"></span><=
p class=3D"line874" style=3D"margin-top:1.12em!important;margin-right:0px!i=
mportant;margin-bottom:1.12em!important;margin-left:0px!important;padding-t=
op:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;font-size:12px=
;color:rgb(51,51,51);font-family:Verdana,Arial,Helvetica,sans-serif;backgro=
und-color:rgb(255,255,255)">
But I dont think I have this message (I am not near my system now, so I can=
 not confirm)<span class=3D"anchor" id=3D"line-157"></span></p><p class=3D"=
line867" style=3D"margin-top:1.12em!important;margin-right:0px!important;ma=
rgin-bottom:1.12em!important;margin-left:0px!important;padding-top:0px;padd=
ing-right:0px;padding-bottom:0px;padding-left:0px;font-size:12px;color:rgb(=
51,51,51);font-family:Verdana,Arial,Helvetica,sans-serif;background-color:r=
gb(255,255,255)">
<span class=3D"anchor" id=3D"line-158"></span></p><pre style=3D"border-top-=
width:1pt;border-right-width:1pt;border-bottom-width:1pt;border-left-width:=
1pt;border-top-style:solid;border-right-style:solid;border-bottom-style:sol=
id;border-left-style:solid;border-top-color:rgb(174,189,204);border-right-c=
olor:rgb(174,189,204);border-bottom-color:rgb(174,189,204);border-left-colo=
r:rgb(174,189,204);background-color:rgb(255,255,255);padding-top:5pt;paddin=
g-right:5pt;padding-bottom:5pt;padding-left:5pt;font-family:courier,monospa=
ce;white-space:pre-wrap;word-wrap:break-word;color:rgb(51,51,51);font-size:=
12px">
(XEN) I/O virtualisation for PV guests enabled</pre><div><br></div><div>I b=
elieve that many have=A0managed=A0to get VGA passthru working, but they gen=
erally dont post their stories. one only finds the problems they are encoun=
tering when searching about this. That is why it would be nice to put toget=
her a kind of manual in the wiki which would have all this info together in=
 one location.</div>
<div><br></div><div>Thanks for the help</div><div><br></div><div>Regards<br=
><br>Sandi</div><div><br></div><br><div class=3D"gmail_quote">On Fri, Jan 2=
0, 2012 at 9:32 PM, Pasi K=E4rkk=E4inen <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:pasik@iki.fi">pasik@iki.fi</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Fri, Jan 20, 2012 at 05=
:49:20PM +0100, Sandi Romih wrote:<br>
&gt; =A0 =A0Pasi,<br>
&gt;<br>
&gt; =A0 =A0I have that enabled in my BIOS, VT-d for the chipset and VT-x f=
or the CPU.<br>
&gt;<br>
<br>
</div>Ok. And Xen enables IOMMU? Did you verify from Xen&#39;s dmesg ?<br>
<br>
<a href=3D"http://wiki.xen.org/xenwiki/XenCommonProblems.html#head-2f76ed2d=
3c282003418d37fbbcda510cac266f89" target=3D"_blank">http://wiki.xen.org/xen=
wiki/XenCommonProblems.html#head-2f76ed2d3c282003418d37fbbcda510cac266f89</=
a><br>

<div class=3D"im"><br>
<br>
<br>
&gt; =A0 =A0Have you managed to pass your gpu through to the domU?<br>
&gt;<br>
<br>
</div>No, I haven&#39;t tried that yet. I&#39;ve been planning to, but I ha=
ven&#39;t had time for it yet.<br>
<br>
There are many people who are using Xen VGA passthru with Intel, AMD/ATI an=
d Nvidia graphics cards.<br>
Currently it needs a lot of understanding and some custom patching, but you=
 can make it work.<br>
<br>
There are even businesses using Xen VGA passthru in production :)<br>
<br>
-- Pasi<br>
<br>
&gt;<br>
&gt; =A0 =A0Sandi<br>
<div class=3D"im">&gt;<br>
&gt; =A0 =A0On Jan 20, 2012 4:47 PM, &quot;Pasi K=E4rkk=E4inen&quot; &lt;[1=
]<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a>&gt; wrote:<br>
&gt;<br>
&gt; =A0 =A0 =A0On Fri, Jan 20, 2012 at 02:05:43PM +0100, Sandi Romih wrote=
:<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0Hello,<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I have spent a lot of time trying to get gfx pa=
ssthru working on my<br>
&gt; =A0 =A0 =A0system<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0without success.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0I looked onto my hardware capabilities again to=
 make sure that it<br>
&gt; =A0 =A0 =A0does<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0support VT-d and I am not too sure that it does=
 fully.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0My hardware is as follows:<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0- Supermicro X8DTH-6F motherboard (5520 chipset=
 which supports<br>
&gt; =A0 =A0 =A0VT-d)<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0- single Xeon X5650 CPU (which is listed as sup=
porting VT-x, no<br>
&gt; =A0 =A0 =A0mention of<br>
</div>&gt; =A0 =A0 =A0&gt; =A0 =A0VT-d at [1][2]<a href=3D"http://ark.intel=
.com" target=3D"_blank">ark.intel.com</a>)<br>
<div class=3D"im">&gt; =A0 =A0 =A0&gt; =A0 =A0Now, according to the [2]VTdH=
owTo, the motherboard BIOS, chipset<br>
&gt; =A0 =A0 =A0AND CPU<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0need to support VT-d.<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0What confuses me is, why is the 55x0 chipset li=
sted there if none<br>
&gt; =A0 =A0 =A0of the<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0CPU&#39;s supported, that I know of, dont have =
the VT-d feature option,<br>
&gt; =A0 =A0 =A0only<br>
&gt; =A0 =A0 =A0&gt; =A0 =A0VT-x.<br>
&gt; =A0 =A0 =A0&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0I&#39;ve been using VT-d with Xen with Intel 5500 series ch=
ipset, and Xeon<br>
&gt; =A0 =A0 =A05600 series CPU.<br>
&gt; =A0 =A0 =A0VT-d needs to be enabled in the BIOS.<br>
&gt;<br>
&gt; =A0 =A0 =A0-- Pasi<br>
&gt;<br>
</div>&gt; References<br>
&gt;<br>
&gt; =A0 =A0Visible links<br>
&gt; =A0 =A01. mailto:<a href=3D"mailto:pasik@iki.fi">pasik@iki.fi</a><br>
&gt; =A0 =A02. <a href=3D"http://ark.intel.com/" target=3D"_blank">http://a=
rk.intel.com/</a><br>
</blockquote></div><br></div>

--14dae93410ef1c641104b730af36--


--===============2339769327084611573==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2339769327084611573==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:59:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:59:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIYf-0005LN-Bh; Mon, 23 Jan 2012 11:59: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 1RpIYe-0005L2-5H
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:59:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327319966!8219134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2654 invoked from network); 23 Jan 2012 11:59:26 -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;
	23 Jan 2012 11:59:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10212219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:59:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:59:25 +0000
Date: Mon, 23 Jan 2012 11:59:42 +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: <4F1D4974.4090003@siemens.com>
Message-ID: <alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >> Or what is the ordering
> >> of init, RAM restore, and initial device reset now?
> > 
> > RAM restore (done by Xen)
> > 
> > physmap rebuild (done by xen_hvm_init in qemu)
> > pc_init()
> > qemu_system_reset()
> > load_vmstate()
> 
> Hmm, are you sure that this is the only case where a device init or
> reset handler writes to already restored guest memory? Preloading the
> RAM this way is a non-standard scenario for QEMU, thus conceptually
> fragile. Does restoring happen before QEMU is even started, or can this
> point be controlled from QEMU?

Consider that this only happens with non-MMIO device memory, in practice
only videoram.
Vmware VGA does not memset the videoram in the reset handler, while QXL
already has the following:

    /* pre loadvm reset must not touch QXLRam.  This lives in
     * device memory, is migrated together with RAM and thus
     * already loaded at this point */
    if (!loadvm) {
        qxl_reset_state(d);
    }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:59:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:59:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIYf-0005LN-Bh; Mon, 23 Jan 2012 11:59: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 1RpIYe-0005L2-5H
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:59:32 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327319966!8219134!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2654 invoked from network); 23 Jan 2012 11:59:26 -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;
	23 Jan 2012 11:59:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10212219"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:59:26 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:59:25 +0000
Date: Mon, 23 Jan 2012 11:59:42 +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: <4F1D4974.4090003@siemens.com>
Message-ID: <alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >> Or what is the ordering
> >> of init, RAM restore, and initial device reset now?
> > 
> > RAM restore (done by Xen)
> > 
> > physmap rebuild (done by xen_hvm_init in qemu)
> > pc_init()
> > qemu_system_reset()
> > load_vmstate()
> 
> Hmm, are you sure that this is the only case where a device init or
> reset handler writes to already restored guest memory? Preloading the
> RAM this way is a non-standard scenario for QEMU, thus conceptually
> fragile. Does restoring happen before QEMU is even started, or can this
> point be controlled from QEMU?

Consider that this only happens with non-MMIO device memory, in practice
only videoram.
Vmware VGA does not memset the videoram in the reset handler, while QXL
already has the following:

    /* pre loadvm reset must not touch QXLRam.  This lives in
     * device memory, is migrated together with RAM and thus
     * already loaded at this point */
    if (!loadvm) {
        qxl_reset_state(d);
    }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:59:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:59:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIYp-0005Mo-Od; Mon, 23 Jan 2012 11:59:43 +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 1RpIYn-0005Ll-Tb
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:59:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327319973!12194740!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 14727 invoked from network); 23 Jan 2012 11:59:35 -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;
	23 Jan 2012 11:59:35 -0000
Received: by dajs34 with SMTP id s34so18152201daj.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 03: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=IjreePfk4z5+PjMqL+CKk5KZyj2GHoLqwOaiq69QcR4=;
	b=oyo8QpGNx+JPeB2JVtVYSm8aDgz6ueX9hQltVHdsDtrl/Vzb7ZtsYiHHEvNwtbRQGw
	SCCncmZ8xWAqhSvIrbeC+CjZXktTm/HAjhD0FKohVnmfugAbPaSao6leq1zF6lipO7FT
	OmIIZpX+KcdBOqL3Zj6U3tmClc0LKjumF+RI4=
MIME-Version: 1.0
Received: by 10.68.74.132 with SMTP id t4mr21957674pbv.22.1327319973599; Mon,
	23 Jan 2012 03:59:33 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Mon, 23 Jan 2012 03:59:33 -0800 (PST)
In-Reply-To: <1327318760.24561.73.camel@zakaz.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 12:59:33 +0100
X-Google-Sender-Auth: 8BAah9Wzf2VXBgB_1Cs1jaIVOwI
Message-ID: <CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@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 \(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 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

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMS0yMyBhdCAxMTozMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IFR1ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+ID4+
IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDog
YWRkIHN1cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+ID4+ID4gT24gVGh1LCAyMDExLTEyLTIyIGF0
IDE2OjQxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiA+PiA+ID4gU29tZSBhdXRv
Z29vIHN0dWZmIHdpbGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRoZSB0b29scyBidWlsZC4gQ2Fu
IHlvdQo+PiA+PiA+ID4gc2V0IHVwIHRoZSBiYXNpYyBzdHJ1Y3R1cmUgSWFuPwo+PiA+PiA+Cj4+
ID4+ID4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+PiA+
PiA+Cj4+ID4+ID4gV291bGQgaXQgYmUgc3VmZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0
b29scy9jaGVjayBjcmVhdGUgYQo+PiA+PiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhl
IGNoZWNrcz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+PiA+PiA+IHRvIGJl
IHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+PiA+Pgo+PiA+PiBGb3Igbm93LCBJIHRo
aW5rIHdlIHNob3VsZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhlIGNyaXRpY2FsIHBhdGggZm9y
Cj4+ID4+IFhlbiA0LjIuIMKgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxkIHN3aXRjaCB0byBhdXRv
Y29uZiBJIHRoaW5rLiDCoChJCj4+ID4+IGRvbid0IGFwcHJvdmUgb2YgYXV0b21ha2UuKQo+PiA+
Cj4+ID4gSXQgc2VlbXMgdGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24gdGhlIGF1
dG9jb25mIHN0dWZmLiBDYW4gd2UKPj4gPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0IHdl
IGNhbiBzdXBwb3J0IHlhamwgMi4wIGluIFhlbiA0LjIgYW5kCj4+ID4gc3dpdGNoIHRvIGF1dG9j
b25mIGFmdGVyd2FyZHMgb3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRjaCB0bwo+
PiA+IGF1dG9jb25mIGZvciA0LjI/Cj4+Cj4+IFRoZSBwcm9wb3NlZCBhdXRvY29uZiBwYXRjaCBp
cyBqdXN0IGEgY29udmVuaWVudCByZXBsYWNlbWVudCBmb3IKPj4gdG9vbHMvY2hlY2sgc2NyaXB0
cywgd2hpY2ggYWxsb3dzIHVzIHRvIGdlbmVyYXRlIGEgbWFrZWZpbGUgYW5kIGEKPj4gaGVhZGVy
IHdlIGNhbiBpbmNsdWRlIHRvIGtub3cgdGhlIHN5c3RlbSBjYXBhYmlsaXRpZXMsIG5vdGhpbmcg
bW9yZQo+PiB3YXMgYWRkZWQuCj4+Cj4+ID4gSSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBhYm91
dCBjcml0aWNhbCBwYXRoIGZvciA0LjIuIEkgcHJlc3VtZQo+PiA+IGF1dG9jb25mIHdvdWxkIHJl
cXVpcmUgbW9yZSB0aGFuIGp1c3QgY2hlY2tpbmcgaW4gdGhlIHBhdGNoZXMsCj4+ID4gc3BlY2lm
aWNhbGx5IEknbSB0aGlua2luZyBvZiB0aGUgYXV0b21hdGVkIHRlc3Qgc3lzdGVtIHVwZGF0ZSBh
bmQgZG9jcy4KPj4KPj4gRG9uJ3Qga25vdyBob3cgZGlmZmljdWx0IGl0IGlzIHRvIHVwZGF0ZSB0
aGUgdGVzdCBiZWQgdG8gdXNlIHRoZSBuZXcKPj4gY29uZmlndXJlIHNjcmlwdCwgaWRlYWxseSBp
dCBzaG91bGQgb25seSByZXF1aXJlIGFkZGluZyAiLi9jb25maWd1cmUiCj4+IGJlZm9yZSBwZXJm
b3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cgaG93IHRoZSB0ZXN0IGJl
ZAo+PiB3b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mgc29tZSBvcHRpb25zIHRv
IGNvbmZpZ3VyZQo+PiBleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1lIHJlc3VsdC4KPgo+IElh
biBKIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHRoYXQgb25lLiBIb3BlZnVsbHkganVzdCBydW5uaW5n
IC4vY29uZmlndXJlCj4gd2lsbCBnZXQgdXMgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8gdGhlIGV4
aXN0aW5nIHNldHVwLgo+Cj4gRldJVyB0aGUgdGVzdGVyIGNvZGUgaXMgYXZhaWxhYmxlIGF0IGEg
Z2l0IHVybCB3aGljaCBpcyBpbiBldmVyeSBwb3N0ZWQKPiBzZXQgb2YgcmVzdWx0cy4gUHJvYmFi
bHkgbG9va2luZyBmb3IgYW55d2hlcmUgdGhhdCB3cml0ZXMgdG8gLmNvbmZpZwo+IHdvdWxkIGJl
IGEgZ29vZCBzdGFydCBmb3IgZGVjaWRpbmcgaG93IGZhciBmcm9tIHRoZSBkZWZhdWx0cyBpdCBk
ZXZpYXRlcwo+IChub3QgZmFyLCBJIGV4cGVjdCkuCj4KPj4gPiBPbiB0aGUgb3RoZXIgaGFuZCBS
b2dlciBwb3N0ZWQgdjMgb2YgaGlzIGF1dG9jb25mIHN1cHBvcnQgcGF0Y2ggYW5kCj4+ID4gYWx0
aG91Z2ggSSBoYXZlbid0IGdvdCByb3VuZCB0byByZXZpZXdpbmcgaXQgeWV0IChzb3JyeSkgdjIn
cyByZXZpZXcgd2FzCj4+ID4gZ2VuZXJhbGx5IHBvc2l0aXZlL21pbm9yIGxvb2tpbmcuCj4+Cj4+
IHYzIGlzIGJhc2ljYWxseSBhIHYyIHdpdGggYWxsIHRoZSBtZW50aW9uZWQgZml4ZXMgYW5kIHRo
ZSBvdXRwdXQgZnJvbQo+PiBhdXRvY29uZiAmIGF1dG9tYWtlLCBzbyB3ZSBjYW4gdXNlIHRoZSBj
b25maWd1cmUgc2NyaXB0IHN0cmFpZ2h0IGF3YXkuCj4KPiBhdXRvbWFrZT8gSSB0aG91Z2h0IHdl
IGFncmVlZCBub3QgdG8gdXNlIHRoYXQ/CgpBdXRvdG9vbHMgaW4gZ2VuZXJhbCBpcyBxdWl0ZSBh
IG1lc3MsIHdlIGRvbid0IHVzZSBhdXRvbWFrZSwgYnV0IHdlCm5lZWQgaXQgdG8gZ2VuZXJhdGUg
Y29uZmlnLnN1YiBhbmQgY29uZmlnLmd1ZXNzICh5ZXMsIEkga25vdyBJIGNhbgphbHNvIGNvcHkg
dGhlbSkuIFRoYXQncyBhbGwgd2UgbmVlZCBhdXRvbWFrZSBmb3IgKGRvbid0IGtub3cgd2h5CmF1
dG9jb25mIGNhbid0IGRvIHRoaXMgYXV0b21hdGljYWxseS4uLikKCj4+IEFueXdheSwgdGhpcyBw
YXRjaCBmb3IgYWRkaW5nIHN1cHBvcnQgb2YgeWFqbCAyLjAgbmVlZHMgc29tZSByZXdvcmssCj4+
IGFjY29yZGluZyB0byB0aGUgY29tbWVudHMgbWFkZSBieSBJYW4gSmFja3Nvbiwgd2hpY2ggSSB3
aWxsIHRyeSB0byBkbwo+PiBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgd2VlayAoc29ycnkgZm9yIHRo
ZSBkZWxheSwgYnV0IEknbSBxdWl0ZSBidXN5Cj4+IHRoaXMgZGF5cykuCj4KPiBTdXJlLCBubyBw
cm9ibGVtLiBJIGhhdmUgcHV0IHlhamwyIHN1cHBvcnQgaW4gdGhlICJuaWNlIHRvIGhhdmUgY29s
dW1uIgo+IGFuZCBhdXRvY29uZiBpbiBhIG5ldyAibmVlZCB0byBkZWNpZGUgaWYgdGhpcyBpcyA0
LjIgb3IgNC4zIG1hdGVyaWFsIgo+IGNvbHVtbi4KClRoYW5rcywgSSdtIHN1cmUgeWFqbCAyLjAg
c3VwcG9ydCB3aWxsIGdldCBpbnRvIDQuMiA6KQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 23 11:59:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 11:59:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIYp-0005Mo-Od; Mon, 23 Jan 2012 11:59:43 +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 1RpIYn-0005Ll-Tb
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 11:59:42 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327319973!12194740!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 14727 invoked from network); 23 Jan 2012 11:59:35 -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;
	23 Jan 2012 11:59:35 -0000
Received: by dajs34 with SMTP id s34so18152201daj.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 03: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=IjreePfk4z5+PjMqL+CKk5KZyj2GHoLqwOaiq69QcR4=;
	b=oyo8QpGNx+JPeB2JVtVYSm8aDgz6ueX9hQltVHdsDtrl/Vzb7ZtsYiHHEvNwtbRQGw
	SCCncmZ8xWAqhSvIrbeC+CjZXktTm/HAjhD0FKohVnmfugAbPaSao6leq1zF6lipO7FT
	OmIIZpX+KcdBOqL3Zj6U3tmClc0LKjumF+RI4=
MIME-Version: 1.0
Received: by 10.68.74.132 with SMTP id t4mr21957674pbv.22.1327319973599; Mon,
	23 Jan 2012 03:59:33 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Mon, 23 Jan 2012 03:59:33 -0800 (PST)
In-Reply-To: <1327318760.24561.73.camel@zakaz.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 12:59:33 +0100
X-Google-Sender-Auth: 8BAah9Wzf2VXBgB_1Cs1jaIVOwI
Message-ID: <CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@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 \(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 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

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMS0yMyBhdCAxMTozMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IFR1ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+ID4+
IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDog
YWRkIHN1cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+ID4+ID4gT24gVGh1LCAyMDExLTEyLTIyIGF0
IDE2OjQxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiA+PiA+ID4gU29tZSBhdXRv
Z29vIHN0dWZmIHdpbGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRoZSB0b29scyBidWlsZC4gQ2Fu
IHlvdQo+PiA+PiA+ID4gc2V0IHVwIHRoZSBiYXNpYyBzdHJ1Y3R1cmUgSWFuPwo+PiA+PiA+Cj4+
ID4+ID4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+PiA+
PiA+Cj4+ID4+ID4gV291bGQgaXQgYmUgc3VmZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0
b29scy9jaGVjayBjcmVhdGUgYQo+PiA+PiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhl
IGNoZWNrcz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+PiA+PiA+IHRvIGJl
IHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+PiA+Pgo+PiA+PiBGb3Igbm93LCBJIHRo
aW5rIHdlIHNob3VsZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhlIGNyaXRpY2FsIHBhdGggZm9y
Cj4+ID4+IFhlbiA0LjIuIMKgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxkIHN3aXRjaCB0byBhdXRv
Y29uZiBJIHRoaW5rLiDCoChJCj4+ID4+IGRvbid0IGFwcHJvdmUgb2YgYXV0b21ha2UuKQo+PiA+
Cj4+ID4gSXQgc2VlbXMgdGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24gdGhlIGF1
dG9jb25mIHN0dWZmLiBDYW4gd2UKPj4gPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0IHdl
IGNhbiBzdXBwb3J0IHlhamwgMi4wIGluIFhlbiA0LjIgYW5kCj4+ID4gc3dpdGNoIHRvIGF1dG9j
b25mIGFmdGVyd2FyZHMgb3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRjaCB0bwo+
PiA+IGF1dG9jb25mIGZvciA0LjI/Cj4+Cj4+IFRoZSBwcm9wb3NlZCBhdXRvY29uZiBwYXRjaCBp
cyBqdXN0IGEgY29udmVuaWVudCByZXBsYWNlbWVudCBmb3IKPj4gdG9vbHMvY2hlY2sgc2NyaXB0
cywgd2hpY2ggYWxsb3dzIHVzIHRvIGdlbmVyYXRlIGEgbWFrZWZpbGUgYW5kIGEKPj4gaGVhZGVy
IHdlIGNhbiBpbmNsdWRlIHRvIGtub3cgdGhlIHN5c3RlbSBjYXBhYmlsaXRpZXMsIG5vdGhpbmcg
bW9yZQo+PiB3YXMgYWRkZWQuCj4+Cj4+ID4gSSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBhYm91
dCBjcml0aWNhbCBwYXRoIGZvciA0LjIuIEkgcHJlc3VtZQo+PiA+IGF1dG9jb25mIHdvdWxkIHJl
cXVpcmUgbW9yZSB0aGFuIGp1c3QgY2hlY2tpbmcgaW4gdGhlIHBhdGNoZXMsCj4+ID4gc3BlY2lm
aWNhbGx5IEknbSB0aGlua2luZyBvZiB0aGUgYXV0b21hdGVkIHRlc3Qgc3lzdGVtIHVwZGF0ZSBh
bmQgZG9jcy4KPj4KPj4gRG9uJ3Qga25vdyBob3cgZGlmZmljdWx0IGl0IGlzIHRvIHVwZGF0ZSB0
aGUgdGVzdCBiZWQgdG8gdXNlIHRoZSBuZXcKPj4gY29uZmlndXJlIHNjcmlwdCwgaWRlYWxseSBp
dCBzaG91bGQgb25seSByZXF1aXJlIGFkZGluZyAiLi9jb25maWd1cmUiCj4+IGJlZm9yZSBwZXJm
b3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cgaG93IHRoZSB0ZXN0IGJl
ZAo+PiB3b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mgc29tZSBvcHRpb25zIHRv
IGNvbmZpZ3VyZQo+PiBleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1lIHJlc3VsdC4KPgo+IElh
biBKIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHRoYXQgb25lLiBIb3BlZnVsbHkganVzdCBydW5uaW5n
IC4vY29uZmlndXJlCj4gd2lsbCBnZXQgdXMgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8gdGhlIGV4
aXN0aW5nIHNldHVwLgo+Cj4gRldJVyB0aGUgdGVzdGVyIGNvZGUgaXMgYXZhaWxhYmxlIGF0IGEg
Z2l0IHVybCB3aGljaCBpcyBpbiBldmVyeSBwb3N0ZWQKPiBzZXQgb2YgcmVzdWx0cy4gUHJvYmFi
bHkgbG9va2luZyBmb3IgYW55d2hlcmUgdGhhdCB3cml0ZXMgdG8gLmNvbmZpZwo+IHdvdWxkIGJl
IGEgZ29vZCBzdGFydCBmb3IgZGVjaWRpbmcgaG93IGZhciBmcm9tIHRoZSBkZWZhdWx0cyBpdCBk
ZXZpYXRlcwo+IChub3QgZmFyLCBJIGV4cGVjdCkuCj4KPj4gPiBPbiB0aGUgb3RoZXIgaGFuZCBS
b2dlciBwb3N0ZWQgdjMgb2YgaGlzIGF1dG9jb25mIHN1cHBvcnQgcGF0Y2ggYW5kCj4+ID4gYWx0
aG91Z2ggSSBoYXZlbid0IGdvdCByb3VuZCB0byByZXZpZXdpbmcgaXQgeWV0IChzb3JyeSkgdjIn
cyByZXZpZXcgd2FzCj4+ID4gZ2VuZXJhbGx5IHBvc2l0aXZlL21pbm9yIGxvb2tpbmcuCj4+Cj4+
IHYzIGlzIGJhc2ljYWxseSBhIHYyIHdpdGggYWxsIHRoZSBtZW50aW9uZWQgZml4ZXMgYW5kIHRo
ZSBvdXRwdXQgZnJvbQo+PiBhdXRvY29uZiAmIGF1dG9tYWtlLCBzbyB3ZSBjYW4gdXNlIHRoZSBj
b25maWd1cmUgc2NyaXB0IHN0cmFpZ2h0IGF3YXkuCj4KPiBhdXRvbWFrZT8gSSB0aG91Z2h0IHdl
IGFncmVlZCBub3QgdG8gdXNlIHRoYXQ/CgpBdXRvdG9vbHMgaW4gZ2VuZXJhbCBpcyBxdWl0ZSBh
IG1lc3MsIHdlIGRvbid0IHVzZSBhdXRvbWFrZSwgYnV0IHdlCm5lZWQgaXQgdG8gZ2VuZXJhdGUg
Y29uZmlnLnN1YiBhbmQgY29uZmlnLmd1ZXNzICh5ZXMsIEkga25vdyBJIGNhbgphbHNvIGNvcHkg
dGhlbSkuIFRoYXQncyBhbGwgd2UgbmVlZCBhdXRvbWFrZSBmb3IgKGRvbid0IGtub3cgd2h5CmF1
dG9jb25mIGNhbid0IGRvIHRoaXMgYXV0b21hdGljYWxseS4uLikKCj4+IEFueXdheSwgdGhpcyBw
YXRjaCBmb3IgYWRkaW5nIHN1cHBvcnQgb2YgeWFqbCAyLjAgbmVlZHMgc29tZSByZXdvcmssCj4+
IGFjY29yZGluZyB0byB0aGUgY29tbWVudHMgbWFkZSBieSBJYW4gSmFja3Nvbiwgd2hpY2ggSSB3
aWxsIHRyeSB0byBkbwo+PiBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgd2VlayAoc29ycnkgZm9yIHRo
ZSBkZWxheSwgYnV0IEknbSBxdWl0ZSBidXN5Cj4+IHRoaXMgZGF5cykuCj4KPiBTdXJlLCBubyBw
cm9ibGVtLiBJIGhhdmUgcHV0IHlhamwyIHN1cHBvcnQgaW4gdGhlICJuaWNlIHRvIGhhdmUgY29s
dW1uIgo+IGFuZCBhdXRvY29uZiBpbiBhIG5ldyAibmVlZCB0byBkZWNpZGUgaWYgdGhpcyBpcyA0
LjIgb3IgNC4zIG1hdGVyaWFsIgo+IGNvbHVtbi4KClRoYW5rcywgSSdtIHN1cmUgeWFqbCAyLjAg
c3VwcG9ydCB3aWxsIGdldCBpbnRvIDQuMiA6KQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:11:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIjf-0006KS-4b; Mon, 23 Jan 2012 12:10:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RpIjd-0006KJ-OV
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:10:53 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327320647!1773667!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzE0NzA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32733 invoked from network); 23 Jan 2012 12:10:47 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 12:10:47 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q0NCAiWg018129;
	Mon, 23 Jan 2012 13:10:44 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NCAhVf024550;
	Mon, 23 Jan 2012 13:10:43 +0100
Message-ID: <4F1D4E43.7000501@siemens.com>
Date: Mon, 23 Jan 2012 13:10: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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 12:59, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>> Or what is the ordering
>>>> of init, RAM restore, and initial device reset now?
>>>
>>> RAM restore (done by Xen)
>>>
>>> physmap rebuild (done by xen_hvm_init in qemu)
>>> pc_init()
>>> qemu_system_reset()
>>> load_vmstate()
>>
>> Hmm, are you sure that this is the only case where a device init or
>> reset handler writes to already restored guest memory? Preloading the
>> RAM this way is a non-standard scenario for QEMU, thus conceptually
>> fragile. Does restoring happen before QEMU is even started, or can this
>> point be controlled from QEMU?
> 
> Consider that this only happens with non-MMIO device memory, in practice
> only videoram.
> Vmware VGA does not memset the videoram in the reset handler, while QXL
> already has the following:
> 
>     /* pre loadvm reset must not touch QXLRam.  This lives in
>      * device memory, is migrated together with RAM and thus
>      * already loaded at this point */
>     if (!loadvm) {
>         qxl_reset_state(d);
>     }

Yes, but QEMU restores the RAM _after_ device reset, not before it.
That's the problem with the Xen way - it is against the current QEMU
standard.

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 Jan 23 12:11:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:11:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIjf-0006KS-4b; Mon, 23 Jan 2012 12:10:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RpIjd-0006KJ-OV
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:10:53 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327320647!1773667!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzE0NzA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32733 invoked from network); 23 Jan 2012 12:10:47 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-9.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 12:10:47 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q0NCAiWg018129;
	Mon, 23 Jan 2012 13:10:44 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NCAhVf024550;
	Mon, 23 Jan 2012 13:10:43 +0100
Message-ID: <4F1D4E43.7000501@siemens.com>
Date: Mon, 23 Jan 2012 13:10: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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 12:59, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>> Or what is the ordering
>>>> of init, RAM restore, and initial device reset now?
>>>
>>> RAM restore (done by Xen)
>>>
>>> physmap rebuild (done by xen_hvm_init in qemu)
>>> pc_init()
>>> qemu_system_reset()
>>> load_vmstate()
>>
>> Hmm, are you sure that this is the only case where a device init or
>> reset handler writes to already restored guest memory? Preloading the
>> RAM this way is a non-standard scenario for QEMU, thus conceptually
>> fragile. Does restoring happen before QEMU is even started, or can this
>> point be controlled from QEMU?
> 
> Consider that this only happens with non-MMIO device memory, in practice
> only videoram.
> Vmware VGA does not memset the videoram in the reset handler, while QXL
> already has the following:
> 
>     /* pre loadvm reset must not touch QXLRam.  This lives in
>      * device memory, is migrated together with RAM and thus
>      * already loaded at this point */
>     if (!loadvm) {
>         qxl_reset_state(d);
>     }

Yes, but QEMU restores the RAM _after_ device reset, not before it.
That's the problem with the Xen way - it is against the current QEMU
standard.

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 Jan 23 12:17:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:17:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIq3-0006Yy-Am; Mon, 23 Jan 2012 12:17:31 +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 1RpIq1-0006Yt-H8
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:17:30 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327321042!8229059!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMzQzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15938 invoked from network); 23 Jan 2012 12:17:23 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 12:17:23 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=pAcmJmRV4G1gZnHIZS2ZkFAC0ZobHyZSgMl5qcuehH025GZf7N52WK5R
	xPMfaEgq38NR/hnphTJiEnkWnb8KYdjhCFCfAaO8RlN1ujd0GvEOxqaxT
	WX5OYDu+KJ78azDmFfAnED9rN/DVYstWH1JvI2XFXR47/QOpf1ppQwr0S
	rtRc81EnZVu7Qw7Xmp7EZjjcZ6DCadBA9AEq64KaqCe4nHfLeCf4KUTLo
	bgjh9tsDL0aV3iCBiDYybIhvSuEwQ;
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=1327321043; x=1358857043;
	h=mime-version:subject:message-id:date:from:to;
	bh=qA33ARWfU0+S1DdP+sg9MjrEkV+XlnFJSXFNRGQiG70=;
	b=WpeMZX/Kk2Jh0E5VQW0s05m5RVaAfBKbPTxdawUmdWSsl6Cic4wMuc2E
	CgwFAYP6zQOBiDWai6p+JD+0f0TxUisrvYbU1r5NJYk95Xxo0J6ZpNJVQ
	KyQ7Z3o3cPjTEp1+FAJ+3aJznlG18otnLAMrtjUGdATXqAI3Q3zvqY3BU
	f1RV3uEfpLM5JWUPhl4odX2SIQRjvZRkx3oZnyFsZw8b7CGpEgEf98I4d
	htYCA82ba9MypWjNZx8qd2xI4NTkZ;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="99418940"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 23 Jan 2012 13:17:23 +0100
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="127253008"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 23 Jan 2012 13:17:22 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id ABF6E95AB6B;
	Mon, 23 Jan 2012 13:17:22 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============4551744071193210468=="
MIME-Version: 1.0
X-Mercurial-Node: 5cf2063db3b5f6abe8c0b5dac09d07fe90920304
Message-Id: <5cf2063db3b5f6abe8c0.1327320737@nehalem1>
Date: Mon, 23 Jan 2012 13:12:17 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity (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

--===============4551744071193210468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.
Changes since v1:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

Signed-off-by: juergen.gross@ts.fujitsu.com


8 files changed, 44 insertions(+), 27 deletions(-)
xen/common/cpupool.c       |    9 +++++++++
xen/common/domain.c        |   24 ++++++++++++++++++++----
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |   16 +++++-----------
xen/include/xen/sched-if.h |    4 ++++



--===============4551744071193210468==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327320724 -3600
# Node ID 5cf2063db3b5f6abe8c0b5dac09d07fe90920304
# Parent  137c16a83e4084b717a8a5685371800aeb313233
Reflect cpupool in numa node affinity (v2)

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.
Changes since v1:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/cpupool.c
--- a/xen/common/cpupool.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/cpupool.c	Mon Jan 23 13:12:04 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+    
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/domain.c
--- a/xen/common/domain.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/domain.c	Mon Jan 23 13:12:04 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -333,23 +334,38 @@ struct domain *domain_create(
 
 void domain_update_node_affinity(struct domain *d)
 {
-    cpumask_t cpumask;
+    cpumask_var_t cpumask;
+    cpumask_var_t online_affinity;
+    const cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
-    cpumask_clear(&cpumask);
+    if (!zalloc_cpumask_var(&cpumask))
+        return;
+    if (!alloc_cpumask_var(&online_affinity))
+    {
+        free_cpumask_var(cpumask);
+        return;
+    }
+
+    online = cpupool_online_cpumask(d->cpupool);
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+    {
+        cpumask_and(online_affinity, v->cpu_affinity, online);
+        cpumask_or(cpumask, cpumask, online_affinity);
+    }
 
     for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
+
+    free_cpumask_var(cpumask);
 }
 
 
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/domctl.c
--- a/xen/common/domctl.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/domctl.c	Mon Jan 23 13:12:04 2012 +0100
@@ -518,7 +518,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             goto maxvcpu_out;
 
         ret = -ENOMEM;
-        online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
+        online = cpupool_online_cpumask(d->cpupool);
         if ( max > d->max_vcpus )
         {
             struct vcpu **vcpus;
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_credit.c	Mon Jan 23 13:12:04 2012 +0100
@@ -72,8 +72,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 
 /*
@@ -471,7 +469,7 @@ _csched_cpu_pick(const struct scheduler 
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
      */
-    online = CSCHED_CPUONLINE(vc->domain->cpupool);
+    online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
     cpu = cpumask_test_cpu(vc->processor, &cpus)
             ? vc->processor
@@ -1230,7 +1228,7 @@ csched_load_balance(struct csched_privat
     int peer_cpu;
 
     BUG_ON( cpu != snext->vcpu->processor );
-    online = CSCHED_CPUONLINE(per_cpu(cpupool, cpu));
+    online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
 
     /* If this CPU is going offline we shouldn't steal work. */
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_credit2.c	Mon Jan 23 13:12:04 2012 +0100
@@ -169,8 +169,6 @@ integer_param("sched_credit2_migrate_res
     ((struct csched_private *)((_ops)->sched_data))
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 /* CPU to runq_id macro */
 #define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_sedf.c	Mon Jan 23 13:12:04 2012 +0100
@@ -12,9 +12,6 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
-
-#define SEDF_CPUONLINE(_pool)                                             \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 #ifndef NDEBUG
 #define SEDF_STATS
@@ -397,7 +394,7 @@ static int sedf_pick_cpu(const struct sc
     cpumask_t online_affinity;
     cpumask_t *online;
 
-    online = SEDF_CPUONLINE(v->domain->cpupool);
+    online = cpupool_scheduler_cpumask(v->domain->cpupool);
     cpumask_and(&online_affinity, v->cpu_affinity, online);
     return cpumask_first(&online_affinity);
 }
@@ -801,7 +798,8 @@ static struct task_slice sedf_do_schedul
      */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
-         unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, cpu)))) )
+         unlikely(!cpumask_test_cpu(cpu,
+                   cpupool_scheduler_cpumask(per_cpu(cpupool, cpu)))) )
     {
         ret.task = IDLETASK(cpu);
         ret.time = SECONDS(1);
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/schedule.c
--- a/xen/common/schedule.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/schedule.c	Mon Jan 23 13:12:04 2012 +0100
@@ -77,9 +77,7 @@ static struct scheduler __read_mostly op
 
 #define DOM2OP(_d)    (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched))
 #define VCPU2OP(_v)   (DOM2OP((_v)->domain))
-#define VCPU2ONLINE(_v)                                                    \
-         (((_v)->domain->cpupool == NULL) ? &cpu_online_map                \
-         : (_v)->domain->cpupool->cpu_valid)
+#define VCPU2ONLINE(_v) cpupool_online_cpumask((_v)->domain->cpupool)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)
 {
@@ -282,11 +280,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -537,7 +536,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -545,8 +543,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -558,7 +554,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -582,8 +577,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;
@@ -1418,7 +1412,7 @@ void schedule_dump(struct cpupool *c)
     cpumask_t        *cpus;
 
     sched = (c == NULL) ? &ops : c->sched;
-    cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
+    cpus = cpupool_scheduler_cpumask(c);
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
     SCHED_OP(sched, dump_settings);
 
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/include/xen/sched-if.h	Mon Jan 23 13:12:04 2012 +0100
@@ -204,4 +204,8 @@ struct cpupool
     atomic_t         refcnt;
 };
 
+#define cpupool_scheduler_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
+#define cpupool_online_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpu_online_map : (_pool)->cpu_valid)
 #endif /* __XEN_SCHED_IF_H__ */

--===============4551744071193210468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4551744071193210468==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:17:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:17:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIq3-0006Yy-Am; Mon, 23 Jan 2012 12:17:31 +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 1RpIq1-0006Yt-H8
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:17:30 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327321042!8229059!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxMzQzMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15938 invoked from network); 23 Jan 2012 12:17:23 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 12:17:23 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=pAcmJmRV4G1gZnHIZS2ZkFAC0ZobHyZSgMl5qcuehH025GZf7N52WK5R
	xPMfaEgq38NR/hnphTJiEnkWnb8KYdjhCFCfAaO8RlN1ujd0GvEOxqaxT
	WX5OYDu+KJ78azDmFfAnED9rN/DVYstWH1JvI2XFXR47/QOpf1ppQwr0S
	rtRc81EnZVu7Qw7Xmp7EZjjcZ6DCadBA9AEq64KaqCe4nHfLeCf4KUTLo
	bgjh9tsDL0aV3iCBiDYybIhvSuEwQ;
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=1327321043; x=1358857043;
	h=mime-version:subject:message-id:date:from:to;
	bh=qA33ARWfU0+S1DdP+sg9MjrEkV+XlnFJSXFNRGQiG70=;
	b=WpeMZX/Kk2Jh0E5VQW0s05m5RVaAfBKbPTxdawUmdWSsl6Cic4wMuc2E
	CgwFAYP6zQOBiDWai6p+JD+0f0TxUisrvYbU1r5NJYk95Xxo0J6ZpNJVQ
	KyQ7Z3o3cPjTEp1+FAJ+3aJznlG18otnLAMrtjUGdATXqAI3Q3zvqY3BU
	f1RV3uEfpLM5JWUPhl4odX2SIQRjvZRkx3oZnyFsZw8b7CGpEgEf98I4d
	htYCA82ba9MypWjNZx8qd2xI4NTkZ;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="99418940"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 23 Jan 2012 13:17:23 +0100
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="127253008"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 23 Jan 2012 13:17:22 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id ABF6E95AB6B;
	Mon, 23 Jan 2012 13:17:22 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============4551744071193210468=="
MIME-Version: 1.0
X-Mercurial-Node: 5cf2063db3b5f6abe8c0b5dac09d07fe90920304
Message-Id: <5cf2063db3b5f6abe8c0.1327320737@nehalem1>
Date: Mon, 23 Jan 2012 13:12:17 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity (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

--===============4551744071193210468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.
Changes since v1:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

Signed-off-by: juergen.gross@ts.fujitsu.com


8 files changed, 44 insertions(+), 27 deletions(-)
xen/common/cpupool.c       |    9 +++++++++
xen/common/domain.c        |   24 ++++++++++++++++++++----
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |   16 +++++-----------
xen/include/xen/sched-if.h |    4 ++++



--===============4551744071193210468==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327320724 -3600
# Node ID 5cf2063db3b5f6abe8c0b5dac09d07fe90920304
# Parent  137c16a83e4084b717a8a5685371800aeb313233
Reflect cpupool in numa node affinity (v2)

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.
Changes since v1:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/cpupool.c
--- a/xen/common/cpupool.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/cpupool.c	Mon Jan 23 13:12:04 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+    
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/domain.c
--- a/xen/common/domain.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/domain.c	Mon Jan 23 13:12:04 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -333,23 +334,38 @@ struct domain *domain_create(
 
 void domain_update_node_affinity(struct domain *d)
 {
-    cpumask_t cpumask;
+    cpumask_var_t cpumask;
+    cpumask_var_t online_affinity;
+    const cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
-    cpumask_clear(&cpumask);
+    if (!zalloc_cpumask_var(&cpumask))
+        return;
+    if (!alloc_cpumask_var(&online_affinity))
+    {
+        free_cpumask_var(cpumask);
+        return;
+    }
+
+    online = cpupool_online_cpumask(d->cpupool);
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+    {
+        cpumask_and(online_affinity, v->cpu_affinity, online);
+        cpumask_or(cpumask, cpumask, online_affinity);
+    }
 
     for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
+
+    free_cpumask_var(cpumask);
 }
 
 
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/domctl.c
--- a/xen/common/domctl.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/domctl.c	Mon Jan 23 13:12:04 2012 +0100
@@ -518,7 +518,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             goto maxvcpu_out;
 
         ret = -ENOMEM;
-        online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
+        online = cpupool_online_cpumask(d->cpupool);
         if ( max > d->max_vcpus )
         {
             struct vcpu **vcpus;
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_credit.c	Mon Jan 23 13:12:04 2012 +0100
@@ -72,8 +72,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 
 /*
@@ -471,7 +469,7 @@ _csched_cpu_pick(const struct scheduler 
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
      */
-    online = CSCHED_CPUONLINE(vc->domain->cpupool);
+    online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
     cpu = cpumask_test_cpu(vc->processor, &cpus)
             ? vc->processor
@@ -1230,7 +1228,7 @@ csched_load_balance(struct csched_privat
     int peer_cpu;
 
     BUG_ON( cpu != snext->vcpu->processor );
-    online = CSCHED_CPUONLINE(per_cpu(cpupool, cpu));
+    online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
 
     /* If this CPU is going offline we shouldn't steal work. */
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_credit2.c	Mon Jan 23 13:12:04 2012 +0100
@@ -169,8 +169,6 @@ integer_param("sched_credit2_migrate_res
     ((struct csched_private *)((_ops)->sched_data))
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 /* CPU to runq_id macro */
 #define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_sedf.c	Mon Jan 23 13:12:04 2012 +0100
@@ -12,9 +12,6 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
-
-#define SEDF_CPUONLINE(_pool)                                             \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 #ifndef NDEBUG
 #define SEDF_STATS
@@ -397,7 +394,7 @@ static int sedf_pick_cpu(const struct sc
     cpumask_t online_affinity;
     cpumask_t *online;
 
-    online = SEDF_CPUONLINE(v->domain->cpupool);
+    online = cpupool_scheduler_cpumask(v->domain->cpupool);
     cpumask_and(&online_affinity, v->cpu_affinity, online);
     return cpumask_first(&online_affinity);
 }
@@ -801,7 +798,8 @@ static struct task_slice sedf_do_schedul
      */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
-         unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, cpu)))) )
+         unlikely(!cpumask_test_cpu(cpu,
+                   cpupool_scheduler_cpumask(per_cpu(cpupool, cpu)))) )
     {
         ret.task = IDLETASK(cpu);
         ret.time = SECONDS(1);
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/common/schedule.c
--- a/xen/common/schedule.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/schedule.c	Mon Jan 23 13:12:04 2012 +0100
@@ -77,9 +77,7 @@ static struct scheduler __read_mostly op
 
 #define DOM2OP(_d)    (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched))
 #define VCPU2OP(_v)   (DOM2OP((_v)->domain))
-#define VCPU2ONLINE(_v)                                                    \
-         (((_v)->domain->cpupool == NULL) ? &cpu_online_map                \
-         : (_v)->domain->cpupool->cpu_valid)
+#define VCPU2ONLINE(_v) cpupool_online_cpumask((_v)->domain->cpupool)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)
 {
@@ -282,11 +280,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -537,7 +536,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -545,8 +543,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -558,7 +554,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -582,8 +577,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;
@@ -1418,7 +1412,7 @@ void schedule_dump(struct cpupool *c)
     cpumask_t        *cpus;
 
     sched = (c == NULL) ? &ops : c->sched;
-    cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
+    cpus = cpupool_scheduler_cpumask(c);
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
     SCHED_OP(sched, dump_settings);
 
diff -r 137c16a83e40 -r 5cf2063db3b5 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/include/xen/sched-if.h	Mon Jan 23 13:12:04 2012 +0100
@@ -204,4 +204,8 @@ struct cpupool
     atomic_t         refcnt;
 };
 
+#define cpupool_scheduler_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
+#define cpupool_online_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpu_online_map : (_pool)->cpu_valid)
 #endif /* __XEN_SCHED_IF_H__ */

--===============4551744071193210468==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4551744071193210468==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:26:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIyR-0006nN-C1; Mon, 23 Jan 2012 12:26:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpIyP-0006nI-3z
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:26:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327321561!8900618!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30763 invoked from network); 23 Jan 2012 12:26:02 -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;
	23 Jan 2012 12:26:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10213089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 12:26:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 12:26:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 12:26:01 +0000
In-Reply-To: <1327092461-2701-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-8-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327321561.24561.91.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/21] lib{xc,
 xl}: Seed grant tables with xenstore and console 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

> @@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
>      return rc;
>  }
> 
> +static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
> +{
> +    DECLARE_HYPERCALL;
> +    gnttab_setup_table_t setup_table;

This memory needs to be a hypercall buffer. The easiest way to achieve
this would be to use xc_gnttab_op() which will bounce it for you.

> +    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
> +    int rc;
> +    unsigned long gmfn;
> +
> +    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
> +    if (gmfnp == NULL)
> +        return -1;
> +
> +    setup_table.dom = domid;
> +    setup_table.nr_frames = 1;
> +    set_xen_guest_handle(setup_table.frame_list, gmfnp);
> +    setup_table.status = 0;
> +
> +    hypercall.op = __HYPERVISOR_grant_table_op;
> +    hypercall.arg[0] = GNTTABOP_setup_table;
> +    hypercall.arg[1] = (unsigned long) &setup_table;
> +    hypercall.arg[2] = 1;
> +
> +    rc = do_xen_hypercall(xch, &hypercall);
> +    gmfn = *gmfnp;
> +    xc_hypercall_buffer_free(xch, gmfnp);
> +
> +    if ( rc != 0 || setup_table.status != GNTST_okay )
> +    {
> +        xc_dom_panic(xch, XC_INTERNAL_ERROR,
> +                     "%s: failed to setup domU grant table "
> +                     "[errno=%d, status=%" PRId16 "]\n",
> +                     __FUNCTION__, rc != 0 ? errno : 0, setup_table.status);
> +        return -1;
> +    }
> +
> +    return gmfn;
> +}
[...]
> +int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
> +                           unsigned long console_gpfn,
> +                           unsigned long xenstore_gpfn,
> +                           uint32_t console_domid,
> +                           uint32_t xenstore_domid)
> +{
> +#define SCRATCH_PFN_GNTTAB 0xFFFFE

Do we need to reserve this address? Even if not should we do so anyway?
Certainly I think hiding it away in this file is a bit too secret...

hvmloader reserves from hvm_info->reserved_mem_pgstart to the 4GB limit
in the guest's e820. reserved_mem_pgstart starts at special_pfn(0) and
is reduced by mem_alloc in hvmloader.

#define NR_SPECIAL_PAGES     5
#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))

So we end up reserving from 0xFEFFB000 to the end. So we are at least
hiding this address from the guest, so that's ok, but I think we need to
document this somewhere -- I'm just not sure where we can put it -- Keir
any ideas?

There's a list of SPECIALPAGE_* in xc_hvm_build but that's not exactly
the height of discoverable either.

> +
> +    int rc;
> +    struct xen_add_to_physmap xatp = {
> +        .domid = domid,
> +        .space = XENMAPSPACE_grant_table,
> +        .idx   = 0, /* TODO: what's this? */

"Index into source mapping space". Since you want the first page of the
grant table 0 seems to be correct.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:26:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpIyR-0006nN-C1; Mon, 23 Jan 2012 12:26:11 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpIyP-0006nI-3z
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:26:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327321561!8900618!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30763 invoked from network); 23 Jan 2012 12:26:02 -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;
	23 Jan 2012 12:26:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10213089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 12:26:01 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 12:26:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 12:26:01 +0000
In-Reply-To: <1327092461-2701-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-8-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327321561.24561.91.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/21] lib{xc,
 xl}: Seed grant tables with xenstore and console 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

> @@ -275,6 +276,169 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
>      return rc;
>  }
> 
> +static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
> +{
> +    DECLARE_HYPERCALL;
> +    gnttab_setup_table_t setup_table;

This memory needs to be a hypercall buffer. The easiest way to achieve
this would be to use xc_gnttab_op() which will bounce it for you.

> +    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
> +    int rc;
> +    unsigned long gmfn;
> +
> +    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
> +    if (gmfnp == NULL)
> +        return -1;
> +
> +    setup_table.dom = domid;
> +    setup_table.nr_frames = 1;
> +    set_xen_guest_handle(setup_table.frame_list, gmfnp);
> +    setup_table.status = 0;
> +
> +    hypercall.op = __HYPERVISOR_grant_table_op;
> +    hypercall.arg[0] = GNTTABOP_setup_table;
> +    hypercall.arg[1] = (unsigned long) &setup_table;
> +    hypercall.arg[2] = 1;
> +
> +    rc = do_xen_hypercall(xch, &hypercall);
> +    gmfn = *gmfnp;
> +    xc_hypercall_buffer_free(xch, gmfnp);
> +
> +    if ( rc != 0 || setup_table.status != GNTST_okay )
> +    {
> +        xc_dom_panic(xch, XC_INTERNAL_ERROR,
> +                     "%s: failed to setup domU grant table "
> +                     "[errno=%d, status=%" PRId16 "]\n",
> +                     __FUNCTION__, rc != 0 ? errno : 0, setup_table.status);
> +        return -1;
> +    }
> +
> +    return gmfn;
> +}
[...]
> +int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
> +                           unsigned long console_gpfn,
> +                           unsigned long xenstore_gpfn,
> +                           uint32_t console_domid,
> +                           uint32_t xenstore_domid)
> +{
> +#define SCRATCH_PFN_GNTTAB 0xFFFFE

Do we need to reserve this address? Even if not should we do so anyway?
Certainly I think hiding it away in this file is a bit too secret...

hvmloader reserves from hvm_info->reserved_mem_pgstart to the 4GB limit
in the guest's e820. reserved_mem_pgstart starts at special_pfn(0) and
is reduced by mem_alloc in hvmloader.

#define NR_SPECIAL_PAGES     5
#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))

So we end up reserving from 0xFEFFB000 to the end. So we are at least
hiding this address from the guest, so that's ok, but I think we need to
document this somewhere -- I'm just not sure where we can put it -- Keir
any ideas?

There's a list of SPECIALPAGE_* in xc_hvm_build but that's not exactly
the height of discoverable either.

> +
> +    int rc;
> +    struct xen_add_to_physmap xatp = {
> +        .domid = domid,
> +        .space = XENMAPSPACE_grant_table,
> +        .idx   = 0, /* TODO: what's this? */

"Index into source mapping space". Since you want the first page of the
grant table 0 seems to be correct.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:41:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12: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 1RpJCt-00075R-QE; Mon, 23 Jan 2012 12:41: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 1RpJCs-00075M-FT
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:41:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327322418!51209282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9460 invoked from network); 23 Jan 2012 12:40:18 -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;
	23 Jan 2012 12:40:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10213506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 12:41:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 12:41:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 12:41:04 +0000
In-Reply-To: <1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327322464.24561.101.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 10/21] mini-os: create app-specific
 configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
> code, create CONFIG_ items for features and use application-specific
> configuration files to enable or disable the features.
> 
> The configuration flags are currently added to the compiler command
> line; as the number of flags grows this may need to move to a header.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/Makefile       |   15 +++++++++------
>  extras/mini-os/apps/common.mk |   11 +++++++++++
>  extras/mini-os/apps/grub.mk   |    2 ++
>  extras/mini-os/apps/ioemu.mk  |    1 +

I think these should go under stubdom/xxx. You can simply pass in
MINIOS_CONFIG as an absolute path and included it
ifneq($(MINIOS_CONFIG),) instead of the ifeq($(stubdom),y) change you
made.


>  extras/mini-os/files.mk       |   28 ++++++++++++++++++++++++++++
>  extras/mini-os/main.c         |   16 ++++++++--------
>  extras/mini-os/minios.mk      |    4 ++--
>  stubdom/Makefile              |    8 ++++----
>  8 files changed, 65 insertions(+), 20 deletions(-)
>  create mode 100644 extras/mini-os/apps/common.mk
>  create mode 100644 extras/mini-os/apps/grub.mk
>  create mode 100644 extras/mini-os/apps/ioemu.mk
>  create mode 100644 extras/mini-os/files.mk
> 
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index c2ee062..af7d0d4 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -8,7 +8,12 @@ export XEN_ROOT = $(CURDIR)/../..
>  include $(XEN_ROOT)/Config.mk
>  OBJ_DIR ?= $(CURDIR)
>  
> -ifneq ($(stubdom),y)
> +ifeq ($(stubdom),y)
> +-include apps/$(MINIOS_APP).mk

If you do as I suggest above this can become an unconditional include.

> +include apps/common.mk

Probably the app-specific mk should include this if it wants it, or just
inline in each app config since I think the contents being common is
more a coincidence than anything else.

> +EXTRA_DEPS += $(wildcard $(CURDIR)/apps/$(MINIOS_APP).mk)
> +EXTRA_DEPS += $(CURDIR)/apps/common.mk
> +else
>  include Config.mk
>  endif
>  
> @@ -34,13 +39,11 @@ TARGET := mini-os
>  # Subdirectories common to mini-os
>  SUBDIRS := lib xenbus console
>  
> +include files.mk

I don't think moving this out of line is necessary, the pattern in moast
of our makefiles is to have the obj-(YN) stuff inline in the Makefiles.

> +
>  # The common mini-os objects to build.
>  APP_OBJS :=
> -OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
> -
> +OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
>  
>  .PHONY: default
>  default: $(OBJ_DIR)/$(TARGET)
> diff --git a/extras/mini-os/apps/common.mk b/extras/mini-os/apps/common.mk
> new file mode 100644
> index 0000000..12b686d
> --- /dev/null
> +++ b/extras/mini-os/apps/common.mk
> @@ -0,0 +1,11 @@
> +# Defaults
> +CONFIG_START_NETWORK ?= y
> +CONFIG_SPARSE_BSS ?= y
> +
> +# Export items as compiler directives
> +flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
> +flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
> +flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
> +
> +DEF_CFLAGS += $(flags-y)

I'd be inclined to put the CFLAGS stuff in the main makefile. It's not
really "config" as such but part of the config system scaffolding.

[...]
> diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
> index b95b889..aeda548 100644
> --- a/extras/mini-os/main.c
> +++ b/extras/mini-os/main.c
> @@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
>  static void call_main(void *p)
>  {
>      char *c, quote;
> -#ifdef CONFIG_QEMU
> +#ifdef CONFIG_QEMU_XS_ARGS
>      char *domargs, *msg;
>  #endif
>      int argc;
>      char **argv;
>      char *envp[] = { NULL };
> -#ifdef CONFIG_QEMU
> +#ifdef CONFIG_QEMU_XS_ARGS

If you allow for the "%s/image/dmargs" (not shown in the patch context)
to come from a CONFIG_MUMBLE then this is no longer QEMU specific.

>      char *vm;
>      char path[128];
>      int domid;
> @@ -60,15 +60,15 @@ static void call_main(void *p)
>       * crashing. */
>      //sleep(1);
>  
> -#ifndef CONFIG_GRUB
> +#ifdef CONFIG_SPARSE_BSS
>      sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
> -#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
> -    start_networking();
>  #endif
> +#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)

In grub.mk (which I've already trimmed, oops) you have
CONFIG_START_NETWORK=n
which will pass that half of the test, which isn't what I think you
wanted.

I've just noticed the same with the SPARSE_BSS option. Oh, and common.mk
actually ends up unconditionally setting some vars too (using ?=).

I think a Linux style "# CONFIG_FOO is not set" would be better if you
think it is necessary to explicitly list options we are not enabling.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:41:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12: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 1RpJCt-00075R-QE; Mon, 23 Jan 2012 12:41: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 1RpJCs-00075M-FT
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:41:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327322418!51209282!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9460 invoked from network); 23 Jan 2012 12:40:18 -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;
	23 Jan 2012 12:40:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="10213506"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 12:41:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 12:41:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 12:41:04 +0000
In-Reply-To: <1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327322464.24561.101.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 10/21] mini-os: create app-specific
 configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
> code, create CONFIG_ items for features and use application-specific
> configuration files to enable or disable the features.
> 
> The configuration flags are currently added to the compiler command
> line; as the number of flags grows this may need to move to a header.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/Makefile       |   15 +++++++++------
>  extras/mini-os/apps/common.mk |   11 +++++++++++
>  extras/mini-os/apps/grub.mk   |    2 ++
>  extras/mini-os/apps/ioemu.mk  |    1 +

I think these should go under stubdom/xxx. You can simply pass in
MINIOS_CONFIG as an absolute path and included it
ifneq($(MINIOS_CONFIG),) instead of the ifeq($(stubdom),y) change you
made.


>  extras/mini-os/files.mk       |   28 ++++++++++++++++++++++++++++
>  extras/mini-os/main.c         |   16 ++++++++--------
>  extras/mini-os/minios.mk      |    4 ++--
>  stubdom/Makefile              |    8 ++++----
>  8 files changed, 65 insertions(+), 20 deletions(-)
>  create mode 100644 extras/mini-os/apps/common.mk
>  create mode 100644 extras/mini-os/apps/grub.mk
>  create mode 100644 extras/mini-os/apps/ioemu.mk
>  create mode 100644 extras/mini-os/files.mk
> 
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index c2ee062..af7d0d4 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -8,7 +8,12 @@ export XEN_ROOT = $(CURDIR)/../..
>  include $(XEN_ROOT)/Config.mk
>  OBJ_DIR ?= $(CURDIR)
>  
> -ifneq ($(stubdom),y)
> +ifeq ($(stubdom),y)
> +-include apps/$(MINIOS_APP).mk

If you do as I suggest above this can become an unconditional include.

> +include apps/common.mk

Probably the app-specific mk should include this if it wants it, or just
inline in each app config since I think the contents being common is
more a coincidence than anything else.

> +EXTRA_DEPS += $(wildcard $(CURDIR)/apps/$(MINIOS_APP).mk)
> +EXTRA_DEPS += $(CURDIR)/apps/common.mk
> +else
>  include Config.mk
>  endif
>  
> @@ -34,13 +39,11 @@ TARGET := mini-os
>  # Subdirectories common to mini-os
>  SUBDIRS := lib xenbus console
>  
> +include files.mk

I don't think moving this out of line is necessary, the pattern in moast
of our makefiles is to have the obj-(YN) stuff inline in the Makefiles.

> +
>  # The common mini-os objects to build.
>  APP_OBJS :=
> -OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
> -
> +OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
>  
>  .PHONY: default
>  default: $(OBJ_DIR)/$(TARGET)
> diff --git a/extras/mini-os/apps/common.mk b/extras/mini-os/apps/common.mk
> new file mode 100644
> index 0000000..12b686d
> --- /dev/null
> +++ b/extras/mini-os/apps/common.mk
> @@ -0,0 +1,11 @@
> +# Defaults
> +CONFIG_START_NETWORK ?= y
> +CONFIG_SPARSE_BSS ?= y
> +
> +# Export items as compiler directives
> +flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
> +flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
> +flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
> +
> +DEF_CFLAGS += $(flags-y)

I'd be inclined to put the CFLAGS stuff in the main makefile. It's not
really "config" as such but part of the config system scaffolding.

[...]
> diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
> index b95b889..aeda548 100644
> --- a/extras/mini-os/main.c
> +++ b/extras/mini-os/main.c
> @@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
>  static void call_main(void *p)
>  {
>      char *c, quote;
> -#ifdef CONFIG_QEMU
> +#ifdef CONFIG_QEMU_XS_ARGS
>      char *domargs, *msg;
>  #endif
>      int argc;
>      char **argv;
>      char *envp[] = { NULL };
> -#ifdef CONFIG_QEMU
> +#ifdef CONFIG_QEMU_XS_ARGS

If you allow for the "%s/image/dmargs" (not shown in the patch context)
to come from a CONFIG_MUMBLE then this is no longer QEMU specific.

>      char *vm;
>      char path[128];
>      int domid;
> @@ -60,15 +60,15 @@ static void call_main(void *p)
>       * crashing. */
>      //sleep(1);
>  
> -#ifndef CONFIG_GRUB
> +#ifdef CONFIG_SPARSE_BSS
>      sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
> -#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
> -    start_networking();
>  #endif
> +#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)

In grub.mk (which I've already trimmed, oops) you have
CONFIG_START_NETWORK=n
which will pass that half of the test, which isn't what I think you
wanted.

I've just noticed the same with the SPARSE_BSS option. Oh, and common.mk
actually ends up unconditionally setting some vars too (using ?=).

I think a Linux style "# CONFIG_FOO is not set" would be better if you
think it is necessary to explicitly list options we are not enabling.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:47:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:47:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJII-0007Hs-Qr; Mon, 23 Jan 2012 12:46:42 +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 1RpJIG-0007HN-Q3
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:46:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327322794!12045700!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 7004 invoked from network); 23 Jan 2012 12:46:34 -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; 23 Jan 2012 12:46:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 12:46:33 +0000
Message-Id: <4F1D64B7020000780006E619@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 12:46:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: paul.durrant@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 12:51, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2282,6 +2282,78 @@ 
> gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
>      return 0;
>  }
>  
> +static s16
> +__gnttab_swap_grant_ref(unsigned long ref_a, unsigned long ref_b)

unsigned long?

> +{
> +    struct domain *d;
> +    struct active_grant_entry *act;
> +    s16 rc = GNTST_okay;
> +
> +    d = rcu_lock_current_domain();
> +
> +    spin_lock(&d->grant_table->lock);
> +
> +    act = &active_entry(d->grant_table, ref_a);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_a);
> +
> +    act = &active_entry(d->grant_table, ref_b);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_b);

As these two messages are (I think) intended to help developers, you
will want to make them distinct (so one knows which one it was that
failed).

> +
> +    if ( d->grant_table->gt_version == 1 ) {

Formatting ({ on the next line).

> +        grant_entry_v1_t shared;
> +
> +        shared = shared_entry_v1(d->grant_table, ref_a);
> +
> +        shared_entry_v1(d->grant_table, ref_a) =
> +            shared_entry_v1(d->grant_table, ref_b);
> +
> +        shared_entry_v1(d->grant_table, ref_b) = shared;
> +    } else {

    }
    else
    {

> +        grant_entry_v2_t shared;
> +        grant_status_t status;
> +
> +        shared = shared_entry_v2(d->grant_table, ref_a);
> +        status = status_entry(d->grant_table, ref_a);
> +
> +        shared_entry_v2(d->grant_table, ref_a) =
> +            shared_entry_v2(d->grant_table, ref_b);
> +        status_entry(d->grant_table, ref_a) =
> +            status_entry(d->grant_table, ref_b);
> +
> +        shared_entry_v2(d->grant_table, ref_b) = shared;
> +        status_entry(d->grant_table, ref_b) = status;
> +    }
> +
> +out:
> +    spin_unlock(&d->grant_table->lock);
> +
> +    rcu_unlock_domain(d);
> +
> +    return rc;
> +}
> +
> +static long
> +gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
> +                      unsigned int count)
> +{
> +    int i;
> +    gnttab_swap_grant_ref_t op;
> +
> +    for ( i = 0; i < count; i++ )
> +    {
> +        if ( i && hypercall_preempt_check() )
> +            return i;
> +        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
> +            return -EFAULT;
> +        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
> +            return -EFAULT;
> +    }
> +    return 0;
> +}
> +
>  long
>  do_grant_table_op(
>      unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -50,6 +50,7 @@
>  ?	grant_entry_v1			grant_table.h
>  ?       grant_entry_header              grant_table.h
>  ?	grant_entry_v2			grant_table.h
> +?	gnttab_swap_grant_ref		grant_table.h

Adding this here isn't enough - you also need to invoke
CHECK_gnttab_swap_grant_ref in xen/common/compat/grant_table.c,
and you should add a stub CASE() at the top of
compat_grant_table_op() (to keep the set complete there).

Jan

>  ?	kexec_exec			kexec.h
>  !	kexec_image			kexec.h
>  !	kexec_range			kexec.h



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:47:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:47:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJII-0007Hs-Qr; Mon, 23 Jan 2012 12:46:42 +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 1RpJIG-0007HN-Q3
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:46:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327322794!12045700!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 7004 invoked from network); 23 Jan 2012 12:46:34 -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; 23 Jan 2012 12:46:34 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 12:46:33 +0000
Message-Id: <4F1D64B7020000780006E619@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 12:46:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: paul.durrant@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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.01.12 at 12:51, Wei Liu <wei.liu2@citrix.com> wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2282,6 +2282,78 @@ 
> gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
>      return 0;
>  }
>  
> +static s16
> +__gnttab_swap_grant_ref(unsigned long ref_a, unsigned long ref_b)

unsigned long?

> +{
> +    struct domain *d;
> +    struct active_grant_entry *act;
> +    s16 rc = GNTST_okay;
> +
> +    d = rcu_lock_current_domain();
> +
> +    spin_lock(&d->grant_table->lock);
> +
> +    act = &active_entry(d->grant_table, ref_a);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_a);
> +
> +    act = &active_entry(d->grant_table, ref_b);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_b);

As these two messages are (I think) intended to help developers, you
will want to make them distinct (so one knows which one it was that
failed).

> +
> +    if ( d->grant_table->gt_version == 1 ) {

Formatting ({ on the next line).

> +        grant_entry_v1_t shared;
> +
> +        shared = shared_entry_v1(d->grant_table, ref_a);
> +
> +        shared_entry_v1(d->grant_table, ref_a) =
> +            shared_entry_v1(d->grant_table, ref_b);
> +
> +        shared_entry_v1(d->grant_table, ref_b) = shared;
> +    } else {

    }
    else
    {

> +        grant_entry_v2_t shared;
> +        grant_status_t status;
> +
> +        shared = shared_entry_v2(d->grant_table, ref_a);
> +        status = status_entry(d->grant_table, ref_a);
> +
> +        shared_entry_v2(d->grant_table, ref_a) =
> +            shared_entry_v2(d->grant_table, ref_b);
> +        status_entry(d->grant_table, ref_a) =
> +            status_entry(d->grant_table, ref_b);
> +
> +        shared_entry_v2(d->grant_table, ref_b) = shared;
> +        status_entry(d->grant_table, ref_b) = status;
> +    }
> +
> +out:
> +    spin_unlock(&d->grant_table->lock);
> +
> +    rcu_unlock_domain(d);
> +
> +    return rc;
> +}
> +
> +static long
> +gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
> +                      unsigned int count)
> +{
> +    int i;
> +    gnttab_swap_grant_ref_t op;
> +
> +    for ( i = 0; i < count; i++ )
> +    {
> +        if ( i && hypercall_preempt_check() )
> +            return i;
> +        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
> +            return -EFAULT;
> +        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
> +            return -EFAULT;
> +    }
> +    return 0;
> +}
> +
>  long
>  do_grant_table_op(
>      unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -50,6 +50,7 @@
>  ?	grant_entry_v1			grant_table.h
>  ?       grant_entry_header              grant_table.h
>  ?	grant_entry_v2			grant_table.h
> +?	gnttab_swap_grant_ref		grant_table.h

Adding this here isn't enough - you also need to invoke
CHECK_gnttab_swap_grant_ref in xen/common/compat/grant_table.c,
and you should add a stub CASE() at the top of
compat_grant_table_op() (to keep the set complete there).

Jan

>  ?	kexec_exec			kexec.h
>  !	kexec_image			kexec.h
>  !	kexec_range			kexec.h



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:51:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJMt-0007RC-HW; Mon, 23 Jan 2012 12:51: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 1RpJMs-0007Qk-4T
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:51:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327323035!49707703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20692 invoked from network); 23 Jan 2012 12:50:35 -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;
	23 Jan 2012 12:50:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10214055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 12:51:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 12:51:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 12:51:21 +0000
In-Reply-To: <1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327323081.24561.108.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> This adds compile-time logic to disable certain frontends in mini-os:
>  - pcifront is disabled by default, enabled for ioemu
>  - blkfront, netfront, fbfront, and kbdfront are enabled by default
>  - xenbus is required for any frontend, and is enabled by default
> 
> If all frontends and xenbus are disabled, mini-os will run without
> needing to communicate with xenstore, making it suitable to run the
> xenstore daemon.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/Makefile               |    5 +++-
>  extras/mini-os/apps/common.mk         |   11 +++++++++
>  extras/mini-os/apps/ioemu.mk          |    1 +
>  extras/mini-os/console/xencons_ring.c |   15 ++++++++++--
>  extras/mini-os/files.mk               |   12 +++++-----
>  extras/mini-os/include/lib.h          |    2 +
>  extras/mini-os/kernel.c               |   40 +++++++++++++++++++++++++++++++-
>  extras/mini-os/lib/sys.c              |   28 +++++++++++++++++++++++
>  extras/mini-os/main.c                 |    6 +++-
>  9 files changed, 106 insertions(+), 14 deletions(-)
> 
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index af7d0d4..7419211 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -70,7 +70,10 @@ ifeq ($(lwip),y)
>  LWC    := $(shell find $(LWIPDIR)/ -type f -name '*.c')
>  LWC    := $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
>  LWO    := $(patsubst %.c,%.o,$(LWC))
> -LWO    += $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
> +LWO    += $(OBJ_DIR)/lwip-arch.o
> +ifeq ($(CONFIG_NETFRONT),y)
> +LWO += $(OBJ_DIR)/lwip-net.o
> +endif

Without lwip-net.o is there any point in having the rest of LWO? Or does
the linker optimise it all away anyway?

[...]

> diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
> index af0afed..c3eba35 100644
> --- a/extras/mini-os/console/xencons_ring.c
> +++ b/extras/mini-os/console/xencons_ring.c
> @@ -189,6 +189,7 @@ struct consfront_dev *xencons_ring_init(void)
> 
>  void free_consfront(struct consfront_dev *dev)
>  {
> +#ifdef CONFIG_XENBUS
>      char* err = NULL;
>      XenbusState state;
> 
> @@ -217,6 +218,7 @@ void free_consfront(struct consfront_dev *dev)
>  close:
>      if (err) free(err);
>      xenbus_unwatch_path_token(XBT_NIL, path, path);
> +#endif
> 
>      mask_evtchn(dev->evtchn);
>      unbind_evtchn(dev->evtchn);
> @@ -231,16 +233,18 @@ close:
> 
>  struct consfront_dev *init_consfront(char *_nodename)
>  {
> +    struct consfront_dev *dev;
> +    char nodename[256];
> +    static int consfrontends = 3;
> +#ifdef CONFIG_XENBUS
>      xenbus_transaction_t xbt;
>      char* err;
>      char* message=NULL;
>      int retry=0;
>      char* msg = NULL;
> -    char nodename[256];
>      char path[256];
> -    static int consfrontends = 3;
> -    struct consfront_dev *dev;
>      int res;
> +#endif
> 
>      if (!_nodename)
>          snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
> @@ -257,6 +261,7 @@ struct consfront_dev *init_consfront(char *_nodename)
>      dev->fd = -1;
>  #endif
> 
> +#ifdef CONFIG_XENBUS
>      snprintf(path, sizeof(path), "%s/backend-id", nodename);
>      if ((res = xenbus_read_integer(path)) < 0)
>          return NULL;
> @@ -351,17 +356,21 @@ done:
>              goto error;
>          }
>      }
> +#endif

Haven't you ifdef'd out everything which would have set dev->evtchn?

I'm not sure that the CONFIG_XENBUS is worthwhile, at least at the
moment, and it seems to add an awful lot of ifdefery.

[...]
> diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
> index 2875bf1..9e490d5 100644
> --- a/extras/mini-os/kernel.c
> +++ b/extras/mini-os/kernel.c
> [...]
> @@ -462,11 +474,21 @@ __attribute__((weak)) int app_main(start_info_t *si)
>      printk("Dummy main: start_info=%p\n", si);
>      create_thread("xenbus_tester", xenbus_tester, si);
>      create_thread("periodic_thread", periodic_thread, si);
> +#ifdef CONFIG_NETFRONT
>      create_thread("netfront", netfront_thread, si);
> +#endif

Better to define init_FOOfront for each of these and have it be a nop in
the ifndef case and avoid the ifdefs in the code itself.

Likewise the ifdef's in the teardown. Ideally the actual meat in the
ifdef cases would be moved into the files you aren't compiling (e.g.
netfront_thread goes into netfront.c) and only the stubs remain in some
header somewhere.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:51:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJMt-0007RC-HW; Mon, 23 Jan 2012 12:51: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 1RpJMs-0007Qk-4T
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:51:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327323035!49707703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20692 invoked from network); 23 Jan 2012 12:50:35 -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;
	23 Jan 2012 12:50:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10214055"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 12:51:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 12:51:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 12:51:21 +0000
In-Reply-To: <1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327323081.24561.108.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> This adds compile-time logic to disable certain frontends in mini-os:
>  - pcifront is disabled by default, enabled for ioemu
>  - blkfront, netfront, fbfront, and kbdfront are enabled by default
>  - xenbus is required for any frontend, and is enabled by default
> 
> If all frontends and xenbus are disabled, mini-os will run without
> needing to communicate with xenstore, making it suitable to run the
> xenstore daemon.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/Makefile               |    5 +++-
>  extras/mini-os/apps/common.mk         |   11 +++++++++
>  extras/mini-os/apps/ioemu.mk          |    1 +
>  extras/mini-os/console/xencons_ring.c |   15 ++++++++++--
>  extras/mini-os/files.mk               |   12 +++++-----
>  extras/mini-os/include/lib.h          |    2 +
>  extras/mini-os/kernel.c               |   40 +++++++++++++++++++++++++++++++-
>  extras/mini-os/lib/sys.c              |   28 +++++++++++++++++++++++
>  extras/mini-os/main.c                 |    6 +++-
>  9 files changed, 106 insertions(+), 14 deletions(-)
> 
> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
> index af7d0d4..7419211 100644
> --- a/extras/mini-os/Makefile
> +++ b/extras/mini-os/Makefile
> @@ -70,7 +70,10 @@ ifeq ($(lwip),y)
>  LWC    := $(shell find $(LWIPDIR)/ -type f -name '*.c')
>  LWC    := $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
>  LWO    := $(patsubst %.c,%.o,$(LWC))
> -LWO    += $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
> +LWO    += $(OBJ_DIR)/lwip-arch.o
> +ifeq ($(CONFIG_NETFRONT),y)
> +LWO += $(OBJ_DIR)/lwip-net.o
> +endif

Without lwip-net.o is there any point in having the rest of LWO? Or does
the linker optimise it all away anyway?

[...]

> diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
> index af0afed..c3eba35 100644
> --- a/extras/mini-os/console/xencons_ring.c
> +++ b/extras/mini-os/console/xencons_ring.c
> @@ -189,6 +189,7 @@ struct consfront_dev *xencons_ring_init(void)
> 
>  void free_consfront(struct consfront_dev *dev)
>  {
> +#ifdef CONFIG_XENBUS
>      char* err = NULL;
>      XenbusState state;
> 
> @@ -217,6 +218,7 @@ void free_consfront(struct consfront_dev *dev)
>  close:
>      if (err) free(err);
>      xenbus_unwatch_path_token(XBT_NIL, path, path);
> +#endif
> 
>      mask_evtchn(dev->evtchn);
>      unbind_evtchn(dev->evtchn);
> @@ -231,16 +233,18 @@ close:
> 
>  struct consfront_dev *init_consfront(char *_nodename)
>  {
> +    struct consfront_dev *dev;
> +    char nodename[256];
> +    static int consfrontends = 3;
> +#ifdef CONFIG_XENBUS
>      xenbus_transaction_t xbt;
>      char* err;
>      char* message=NULL;
>      int retry=0;
>      char* msg = NULL;
> -    char nodename[256];
>      char path[256];
> -    static int consfrontends = 3;
> -    struct consfront_dev *dev;
>      int res;
> +#endif
> 
>      if (!_nodename)
>          snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
> @@ -257,6 +261,7 @@ struct consfront_dev *init_consfront(char *_nodename)
>      dev->fd = -1;
>  #endif
> 
> +#ifdef CONFIG_XENBUS
>      snprintf(path, sizeof(path), "%s/backend-id", nodename);
>      if ((res = xenbus_read_integer(path)) < 0)
>          return NULL;
> @@ -351,17 +356,21 @@ done:
>              goto error;
>          }
>      }
> +#endif

Haven't you ifdef'd out everything which would have set dev->evtchn?

I'm not sure that the CONFIG_XENBUS is worthwhile, at least at the
moment, and it seems to add an awful lot of ifdefery.

[...]
> diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
> index 2875bf1..9e490d5 100644
> --- a/extras/mini-os/kernel.c
> +++ b/extras/mini-os/kernel.c
> [...]
> @@ -462,11 +474,21 @@ __attribute__((weak)) int app_main(start_info_t *si)
>      printk("Dummy main: start_info=%p\n", si);
>      create_thread("xenbus_tester", xenbus_tester, si);
>      create_thread("periodic_thread", periodic_thread, si);
> +#ifdef CONFIG_NETFRONT
>      create_thread("netfront", netfront_thread, si);
> +#endif

Better to define init_FOOfront for each of these and have it be a nop in
the ifndef case and avoid the ifdefs in the code itself.

Likewise the ifdef's in the teardown. Ideally the actual meat in the
ifdef cases would be moved into the files you aren't compiling (e.g.
netfront_thread goes into netfront.c) and only the stubs remain in some
header somewhere.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:56:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12: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 1RpJR1-0007bw-8S; Mon, 23 Jan 2012 12:55: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 1RpJR0-0007bp-Cl
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:55:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327323334!12021090!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 31027 invoked from network); 23 Jan 2012 12:55:35 -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; 23 Jan 2012 12:55:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 12:55:33 +0000
Message-Id: <4F1D66D3020000780006E627@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 12:55:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <5cf2063db3b5f6abe8c0.1327320737@nehalem1>
In-Reply-To: <5cf2063db3b5f6abe8c0.1327320737@nehalem1>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity (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.01.12 at 13:12, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> - introduce and use common macros for selecting cpupool based cpumasks

I had hoped that you would do this as a separate prerequisite patch,
but that it's in here I think there's no need to break it up.

>@@ -333,23 +334,38 @@ struct domain *domain_create(
> 
> void domain_update_node_affinity(struct domain *d)
> {
>-    cpumask_t cpumask;
>+    cpumask_var_t cpumask;
>+    cpumask_var_t online_affinity;
>+    const cpumask_t *online;
>     nodemask_t nodemask = NODE_MASK_NONE;
>     struct vcpu *v;
>     unsigned int node;
> 
>-    cpumask_clear(&cpumask);
>+    if (!zalloc_cpumask_var(&cpumask))
>+        return;
>+    if (!alloc_cpumask_var(&online_affinity))

This doesn't get freed at the end of the function. Also, with the rest
of the function being formatted properly, you ought to insert spaces
after the initial and before the final parentheses of the if-s.

Jan

>+    {
>+        free_cpumask_var(cpumask);
>+        return;
>+    }
>+
>+    online = cpupool_online_cpumask(d->cpupool);
>     spin_lock(&d->node_affinity_lock);
> 
>     for_each_vcpu ( d, v )
>-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
>+    {
>+        cpumask_and(online_affinity, v->cpu_affinity, online);
>+        cpumask_or(cpumask, cpumask, online_affinity);
>+    }
> 
>     for_each_online_node ( node )
>-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
>+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
>             node_set(node, nodemask);
> 
>     d->node_affinity = nodemask;
>     spin_unlock(&d->node_affinity_lock);
>+
>+    free_cpumask_var(cpumask);
> }
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 12:56:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 12: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 1RpJR1-0007bw-8S; Mon, 23 Jan 2012 12:55: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 1RpJR0-0007bp-Cl
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 12:55:42 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327323334!12021090!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 31027 invoked from network); 23 Jan 2012 12:55:35 -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; 23 Jan 2012 12:55:35 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 12:55:33 +0000
Message-Id: <4F1D66D3020000780006E627@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 12:55:31 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <5cf2063db3b5f6abe8c0.1327320737@nehalem1>
In-Reply-To: <5cf2063db3b5f6abe8c0.1327320737@nehalem1>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity (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.01.12 at 13:12, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> - introduce and use common macros for selecting cpupool based cpumasks

I had hoped that you would do this as a separate prerequisite patch,
but that it's in here I think there's no need to break it up.

>@@ -333,23 +334,38 @@ struct domain *domain_create(
> 
> void domain_update_node_affinity(struct domain *d)
> {
>-    cpumask_t cpumask;
>+    cpumask_var_t cpumask;
>+    cpumask_var_t online_affinity;
>+    const cpumask_t *online;
>     nodemask_t nodemask = NODE_MASK_NONE;
>     struct vcpu *v;
>     unsigned int node;
> 
>-    cpumask_clear(&cpumask);
>+    if (!zalloc_cpumask_var(&cpumask))
>+        return;
>+    if (!alloc_cpumask_var(&online_affinity))

This doesn't get freed at the end of the function. Also, with the rest
of the function being formatted properly, you ought to insert spaces
after the initial and before the final parentheses of the if-s.

Jan

>+    {
>+        free_cpumask_var(cpumask);
>+        return;
>+    }
>+
>+    online = cpupool_online_cpumask(d->cpupool);
>     spin_lock(&d->node_affinity_lock);
> 
>     for_each_vcpu ( d, v )
>-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
>+    {
>+        cpumask_and(online_affinity, v->cpu_affinity, online);
>+        cpumask_or(cpumask, cpumask, online_affinity);
>+    }
> 
>     for_each_online_node ( node )
>-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
>+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
>             node_set(node, nodemask);
> 
>     d->node_affinity = nodemask;
>     spin_unlock(&d->node_affinity_lock);
>+
>+    free_cpumask_var(cpumask);
> }
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:02:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJXL-0007op-4Y; Mon, 23 Jan 2012 13:02:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpJXI-0007oc-W2
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:02:13 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327323725!9846899!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDE1OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21755 invoked from network); 23 Jan 2012 13:02:06 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:02:06 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=hGYUoAopbjPJrXiZVgEraGzkfleo/nftfS9l4zgcvHG3oY/ZNFOp1UD7
	YCAx6rYNxXTSihyS0YEbcz2q8tIv5lpkV318gqgQU6x16a4kdqC46zluW
	V0YI4YM+H20kYZvn7Nha5jU63ynJdCzwEgDJSyRZTGUEiQMRoBmgAK5Gz
	Tc15W5oRCi+vLMND1b1NpTApP/THSmtL2pJWGaPMn6qvpdUSV+iB6/TPF
	TdQ0yQgF2jfDs90s7p8pg9DqxGyxL;
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=1327323726; x=1358859726;
	h=mime-version:subject:message-id:date:from:to;
	bh=JyFpn+oSmbJk6l9A9bdLAUZhlUQpihsoyFCP2MwZu+s=;
	b=VsM4x4x02Iq8hhWt/R0VB9xoCztyER/7YkpYY81DZA/WN3fhOc3f1YjH
	AzRbGP4SqOo4uYNQMjtJ/wbcVZQNd2o0aj1CvojePzbyx3jEhO7JySn87
	3OyAKg+Lw2E3ci9WXQBV2IHd0OCy8Q5l6PuF+E42RF8nTzLC+W+dx15dx
	90sfCmddImBoVeDyMcNbWHuMqGhs3QXK3W9z5MAFQJYkevIg4+iBcuosD
	W4IeKQK1pASa18OcM9AMFwtl76rQy;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="84263962"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 23 Jan 2012 14:02:06 +0100
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="127258510"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 23 Jan 2012 14:02:05 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 8BADA96089C;
	Mon, 23 Jan 2012 14:02:05 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============2442099013237358024=="
MIME-Version: 1.0
X-Mercurial-Node: 560e958a0ba6d01de470c5bab493c506643596cf
Message-Id: <560e958a0ba6d01de470.1327323421@nehalem1>
Date: Mon, 23 Jan 2012 13:57:01 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity (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

--===============2442099013237358024==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Changes in v3:
- formatting
- avoid memory leak

Changes in v2:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

Signed-off-by: juergen.gross@ts.fujitsu.com


8 files changed, 45 insertions(+), 27 deletions(-)
xen/common/cpupool.c       |    9 +++++++++
xen/common/domain.c        |   25 +++++++++++++++++++++----
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |   16 +++++-----------
xen/include/xen/sched-if.h |    4 ++++



--===============2442099013237358024==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327323410 -3600
# Node ID 560e958a0ba6d01de470c5bab493c506643596cf
# Parent  137c16a83e4084b717a8a5685371800aeb313233
Reflect cpupool in numa node affinity (v3)

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Changes in v3:
- formatting
- avoid memory leak

Changes in v2:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/cpupool.c
--- a/xen/common/cpupool.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/cpupool.c	Mon Jan 23 13:56:50 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+    
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/domain.c
--- a/xen/common/domain.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/domain.c	Mon Jan 23 13:56:50 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -333,23 +334,39 @@ struct domain *domain_create(
 
 void domain_update_node_affinity(struct domain *d)
 {
-    cpumask_t cpumask;
+    cpumask_var_t cpumask;
+    cpumask_var_t online_affinity;
+    const cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
-    cpumask_clear(&cpumask);
+    if ( !zalloc_cpumask_var(&cpumask) )
+        return;
+    if ( !alloc_cpumask_var(&online_affinity) )
+    {
+        free_cpumask_var(cpumask);
+        return;
+    }
+
+    online = cpupool_online_cpumask(d->cpupool);
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+    {
+        cpumask_and(online_affinity, v->cpu_affinity, online);
+        cpumask_or(cpumask, cpumask, online_affinity);
+    }
 
     for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
+
+    free_cpumask_var(online_affinity);
+    free_cpumask_var(cpumask);
 }
 
 
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/domctl.c
--- a/xen/common/domctl.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/domctl.c	Mon Jan 23 13:56:50 2012 +0100
@@ -518,7 +518,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             goto maxvcpu_out;
 
         ret = -ENOMEM;
-        online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
+        online = cpupool_online_cpumask(d->cpupool);
         if ( max > d->max_vcpus )
         {
             struct vcpu **vcpus;
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_credit.c	Mon Jan 23 13:56:50 2012 +0100
@@ -72,8 +72,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 
 /*
@@ -471,7 +469,7 @@ _csched_cpu_pick(const struct scheduler 
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
      */
-    online = CSCHED_CPUONLINE(vc->domain->cpupool);
+    online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
     cpu = cpumask_test_cpu(vc->processor, &cpus)
             ? vc->processor
@@ -1230,7 +1228,7 @@ csched_load_balance(struct csched_privat
     int peer_cpu;
 
     BUG_ON( cpu != snext->vcpu->processor );
-    online = CSCHED_CPUONLINE(per_cpu(cpupool, cpu));
+    online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
 
     /* If this CPU is going offline we shouldn't steal work. */
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_credit2.c	Mon Jan 23 13:56:50 2012 +0100
@@ -169,8 +169,6 @@ integer_param("sched_credit2_migrate_res
     ((struct csched_private *)((_ops)->sched_data))
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 /* CPU to runq_id macro */
 #define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_sedf.c	Mon Jan 23 13:56:50 2012 +0100
@@ -12,9 +12,6 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
-
-#define SEDF_CPUONLINE(_pool)                                             \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 #ifndef NDEBUG
 #define SEDF_STATS
@@ -397,7 +394,7 @@ static int sedf_pick_cpu(const struct sc
     cpumask_t online_affinity;
     cpumask_t *online;
 
-    online = SEDF_CPUONLINE(v->domain->cpupool);
+    online = cpupool_scheduler_cpumask(v->domain->cpupool);
     cpumask_and(&online_affinity, v->cpu_affinity, online);
     return cpumask_first(&online_affinity);
 }
@@ -801,7 +798,8 @@ static struct task_slice sedf_do_schedul
      */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
-         unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, cpu)))) )
+         unlikely(!cpumask_test_cpu(cpu,
+                   cpupool_scheduler_cpumask(per_cpu(cpupool, cpu)))) )
     {
         ret.task = IDLETASK(cpu);
         ret.time = SECONDS(1);
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/schedule.c
--- a/xen/common/schedule.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/schedule.c	Mon Jan 23 13:56:50 2012 +0100
@@ -77,9 +77,7 @@ static struct scheduler __read_mostly op
 
 #define DOM2OP(_d)    (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched))
 #define VCPU2OP(_v)   (DOM2OP((_v)->domain))
-#define VCPU2ONLINE(_v)                                                    \
-         (((_v)->domain->cpupool == NULL) ? &cpu_online_map                \
-         : (_v)->domain->cpupool->cpu_valid)
+#define VCPU2ONLINE(_v) cpupool_online_cpumask((_v)->domain->cpupool)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)
 {
@@ -282,11 +280,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -537,7 +536,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -545,8 +543,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -558,7 +554,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -582,8 +577,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;
@@ -1418,7 +1412,7 @@ void schedule_dump(struct cpupool *c)
     cpumask_t        *cpus;
 
     sched = (c == NULL) ? &ops : c->sched;
-    cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
+    cpus = cpupool_scheduler_cpumask(c);
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
     SCHED_OP(sched, dump_settings);
 
diff -r 137c16a83e40 -r 560e958a0ba6 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/include/xen/sched-if.h	Mon Jan 23 13:56:50 2012 +0100
@@ -204,4 +204,8 @@ struct cpupool
     atomic_t         refcnt;
 };
 
+#define cpupool_scheduler_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
+#define cpupool_online_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpu_online_map : (_pool)->cpu_valid)
 #endif /* __XEN_SCHED_IF_H__ */

--===============2442099013237358024==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2442099013237358024==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:02:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:02:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJXL-0007op-4Y; Mon, 23 Jan 2012 13:02:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpJXI-0007oc-W2
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:02:13 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327323725!9846899!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDE1OQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21755 invoked from network); 23 Jan 2012 13:02:06 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:02:06 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:Date:From:To;
	b=hGYUoAopbjPJrXiZVgEraGzkfleo/nftfS9l4zgcvHG3oY/ZNFOp1UD7
	YCAx6rYNxXTSihyS0YEbcz2q8tIv5lpkV318gqgQU6x16a4kdqC46zluW
	V0YI4YM+H20kYZvn7Nha5jU63ynJdCzwEgDJSyRZTGUEiQMRoBmgAK5Gz
	Tc15W5oRCi+vLMND1b1NpTApP/THSmtL2pJWGaPMn6qvpdUSV+iB6/TPF
	TdQ0yQgF2jfDs90s7p8pg9DqxGyxL;
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=1327323726; x=1358859726;
	h=mime-version:subject:message-id:date:from:to;
	bh=JyFpn+oSmbJk6l9A9bdLAUZhlUQpihsoyFCP2MwZu+s=;
	b=VsM4x4x02Iq8hhWt/R0VB9xoCztyER/7YkpYY81DZA/WN3fhOc3f1YjH
	AzRbGP4SqOo4uYNQMjtJ/wbcVZQNd2o0aj1CvojePzbyx3jEhO7JySn87
	3OyAKg+Lw2E3ci9WXQBV2IHd0OCy8Q5l6PuF+E42RF8nTzLC+W+dx15dx
	90sfCmddImBoVeDyMcNbWHuMqGhs3QXK3W9z5MAFQJYkevIg4+iBcuosD
	W4IeKQK1pASa18OcM9AMFwtl76rQy;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="84263962"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 23 Jan 2012 14:02:06 +0100
X-IronPort-AV: E=Sophos;i="4.71,555,1320620400"; d="scan'208";a="127258510"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 23 Jan 2012 14:02:05 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 8BADA96089C;
	Mon, 23 Jan 2012 14:02:05 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============2442099013237358024=="
MIME-Version: 1.0
X-Mercurial-Node: 560e958a0ba6d01de470c5bab493c506643596cf
Message-Id: <560e958a0ba6d01de470.1327323421@nehalem1>
Date: Mon, 23 Jan 2012 13:57:01 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity (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

--===============2442099013237358024==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Changes in v3:
- formatting
- avoid memory leak

Changes in v2:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

Signed-off-by: juergen.gross@ts.fujitsu.com


8 files changed, 45 insertions(+), 27 deletions(-)
xen/common/cpupool.c       |    9 +++++++++
xen/common/domain.c        |   25 +++++++++++++++++++++----
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |   16 +++++-----------
xen/include/xen/sched-if.h |    4 ++++



--===============2442099013237358024==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327323410 -3600
# Node ID 560e958a0ba6d01de470c5bab493c506643596cf
# Parent  137c16a83e4084b717a8a5685371800aeb313233
Reflect cpupool in numa node affinity (v3)

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Changes in v3:
- formatting
- avoid memory leak

Changes in v2:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/cpupool.c
--- a/xen/common/cpupool.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/cpupool.c	Mon Jan 23 13:56:50 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+    
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/domain.c
--- a/xen/common/domain.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/domain.c	Mon Jan 23 13:56:50 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -333,23 +334,39 @@ struct domain *domain_create(
 
 void domain_update_node_affinity(struct domain *d)
 {
-    cpumask_t cpumask;
+    cpumask_var_t cpumask;
+    cpumask_var_t online_affinity;
+    const cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
-    cpumask_clear(&cpumask);
+    if ( !zalloc_cpumask_var(&cpumask) )
+        return;
+    if ( !alloc_cpumask_var(&online_affinity) )
+    {
+        free_cpumask_var(cpumask);
+        return;
+    }
+
+    online = cpupool_online_cpumask(d->cpupool);
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+    {
+        cpumask_and(online_affinity, v->cpu_affinity, online);
+        cpumask_or(cpumask, cpumask, online_affinity);
+    }
 
     for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
+
+    free_cpumask_var(online_affinity);
+    free_cpumask_var(cpumask);
 }
 
 
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/domctl.c
--- a/xen/common/domctl.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/domctl.c	Mon Jan 23 13:56:50 2012 +0100
@@ -518,7 +518,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             goto maxvcpu_out;
 
         ret = -ENOMEM;
-        online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
+        online = cpupool_online_cpumask(d->cpupool);
         if ( max > d->max_vcpus )
         {
             struct vcpu **vcpus;
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_credit.c	Mon Jan 23 13:56:50 2012 +0100
@@ -72,8 +72,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 
 /*
@@ -471,7 +469,7 @@ _csched_cpu_pick(const struct scheduler 
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
      */
-    online = CSCHED_CPUONLINE(vc->domain->cpupool);
+    online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
     cpu = cpumask_test_cpu(vc->processor, &cpus)
             ? vc->processor
@@ -1230,7 +1228,7 @@ csched_load_balance(struct csched_privat
     int peer_cpu;
 
     BUG_ON( cpu != snext->vcpu->processor );
-    online = CSCHED_CPUONLINE(per_cpu(cpupool, cpu));
+    online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
 
     /* If this CPU is going offline we shouldn't steal work. */
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_credit2.c	Mon Jan 23 13:56:50 2012 +0100
@@ -169,8 +169,6 @@ integer_param("sched_credit2_migrate_res
     ((struct csched_private *)((_ops)->sched_data))
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 /* CPU to runq_id macro */
 #define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/sched_sedf.c	Mon Jan 23 13:56:50 2012 +0100
@@ -12,9 +12,6 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
-
-#define SEDF_CPUONLINE(_pool)                                             \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 #ifndef NDEBUG
 #define SEDF_STATS
@@ -397,7 +394,7 @@ static int sedf_pick_cpu(const struct sc
     cpumask_t online_affinity;
     cpumask_t *online;
 
-    online = SEDF_CPUONLINE(v->domain->cpupool);
+    online = cpupool_scheduler_cpumask(v->domain->cpupool);
     cpumask_and(&online_affinity, v->cpu_affinity, online);
     return cpumask_first(&online_affinity);
 }
@@ -801,7 +798,8 @@ static struct task_slice sedf_do_schedul
      */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
-         unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, cpu)))) )
+         unlikely(!cpumask_test_cpu(cpu,
+                   cpupool_scheduler_cpumask(per_cpu(cpupool, cpu)))) )
     {
         ret.task = IDLETASK(cpu);
         ret.time = SECONDS(1);
diff -r 137c16a83e40 -r 560e958a0ba6 xen/common/schedule.c
--- a/xen/common/schedule.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/schedule.c	Mon Jan 23 13:56:50 2012 +0100
@@ -77,9 +77,7 @@ static struct scheduler __read_mostly op
 
 #define DOM2OP(_d)    (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched))
 #define VCPU2OP(_v)   (DOM2OP((_v)->domain))
-#define VCPU2ONLINE(_v)                                                    \
-         (((_v)->domain->cpupool == NULL) ? &cpu_online_map                \
-         : (_v)->domain->cpupool->cpu_valid)
+#define VCPU2ONLINE(_v) cpupool_online_cpumask((_v)->domain->cpupool)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)
 {
@@ -282,11 +280,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -537,7 +536,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -545,8 +543,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -558,7 +554,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -582,8 +577,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;
@@ -1418,7 +1412,7 @@ void schedule_dump(struct cpupool *c)
     cpumask_t        *cpus;
 
     sched = (c == NULL) ? &ops : c->sched;
-    cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
+    cpus = cpupool_scheduler_cpumask(c);
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
     SCHED_OP(sched, dump_settings);
 
diff -r 137c16a83e40 -r 560e958a0ba6 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/include/xen/sched-if.h	Mon Jan 23 13:56:50 2012 +0100
@@ -204,4 +204,8 @@ struct cpupool
     atomic_t         refcnt;
 };
 
+#define cpupool_scheduler_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
+#define cpupool_online_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpu_online_map : (_pool)->cpu_valid)
 #endif /* __XEN_SCHED_IF_H__ */

--===============2442099013237358024==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2442099013237358024==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:06:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJbN-0007wR-Rp; Mon, 23 Jan 2012 13:06: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 1RpJbL-0007w6-Sg
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:06:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327323931!51213285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32437 invoked from network); 23 Jan 2012 13:05: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;
	23 Jan 2012 13:05:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10214878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:06: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;
	Mon, 23 Jan 2012 13:06:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:06:17 +0000
In-Reply-To: <1327092461-2701-14-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-14-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327323977.24561.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 13/21] xenstored: use grant references
 instead of map_foreign_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 Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> make xenstored use grantref rather than map_foreign_range (which can
> only be used by privileged domains)
> 
> This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
> instead of xc_map_foreign_range where available.
> 
> Previous versions of this patch have been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_domain.c |   52 ++++++++++++++++++++++++++++++++----
>  1 files changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 443af82..661d955 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -32,8 +32,10 @@
>  #include "xenstored_watch.h"
>  
>  #include <xenctrl.h>
> +#include <xen/grant_table.h>
>  
>  static xc_interface **xc_handle;
> +static xc_gnttab **xcg_handle;
>  static evtchn_port_t virq_port;
>  
>  xc_evtchn *xce_handle = NULL;
> @@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
>  	return len;
>  }
>  
> +static void *map_interface(domid_t domid, unsigned long mfn)
> +{
> +	if (*xcg_handle >= 0) {
> +		/* this is the preferred method */
> +		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
> +			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
> +	} else {
> +		return xc_map_foreign_range(*xc_handle, domid,
> +			getpagesize(), PROT_READ|PROT_WRITE, mfn);
> +	}
> +}
> +
> +static void unmap_interface(void *interface)
> +{
> +	if (*xcg_handle >= 0)
> +		xc_gnttab_munmap(*xcg_handle, interface, 1);
> +	else
> +		munmap(interface, getpagesize());
> +}
> +
>  static int destroy_domain(void *_domain)
>  {
>  	struct domain *domain = _domain;
> @@ -174,8 +196,12 @@ static int destroy_domain(void *_domain)
>  			eprintf("> Unbinding port %i failed!\n", domain->port);
>  	}
>  
> -	if (domain->interface)
> -		munmap(domain->interface, getpagesize());
> +	if (domain->interface) {
> +		if (domain->domid == 0)
> +			munmap(domain->interface, getpagesize());
> +		else
> +			unmap_interface(domain->interface);
> +	}
>  
>  	fire_watches(NULL, "@releaseDomain", false);
>  
> @@ -344,9 +370,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
>  	domain = find_domain_by_domid(domid);
>  
>  	if (domain == NULL) {
> -		interface = xc_map_foreign_range(
> -			*xc_handle, domid,
> -			getpagesize(), PROT_READ|PROT_WRITE, mfn);
> +		interface = map_interface(domid, mfn);
>  		if (!interface) {
>  			send_error(conn, errno);
>  			return;
> @@ -354,7 +378,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
>  		/* Hang domain off "in" until we're finished. */
>  		domain = new_domain(in, domid, port);
>  		if (!domain) {
> -			munmap(interface, getpagesize());
> +			unmap_interface(interface);
>  			send_error(conn, errno);
>  			return;
>  		}
> @@ -552,6 +576,12 @@ static int close_xc_handle(void *_handle)
>  	return 0;
>  }
>  
> +static int close_xcg_handle(void *_handle)
> +{
> +	xc_gnttab_close(*(xc_gnttab **)_handle);
> +	return 0;
> +}
> +
>  /* Returns the implicit path of a connection (only domains have this) */
>  const char *get_implicit_path(const struct connection *conn)
>  {
> @@ -603,6 +633,16 @@ void domain_init(void)
>  
>  	talloc_set_destructor(xc_handle, close_xc_handle);
>  
> +	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
> +	if (!xcg_handle)
> +		barf_perror("Failed to allocate domain gnttab handle");
> +
> +	*xcg_handle = xc_gnttab_open(NULL, 0);
> +	if (*xcg_handle < 0)
> +		xprintf("WARNING: Failed to open connection to gnttab\n");
> +	else
> +		talloc_set_destructor(xcg_handle, close_xcg_handle);
> +
>  	xce_handle = xc_evtchn_open(NULL, 0);
>  
>  	if (xce_handle == NULL)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:06:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJbN-0007wR-Rp; Mon, 23 Jan 2012 13:06: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 1RpJbL-0007w6-Sg
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:06:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327323931!51213285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32437 invoked from network); 23 Jan 2012 13:05: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;
	23 Jan 2012 13:05:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10214878"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:06: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;
	Mon, 23 Jan 2012 13:06:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:06:17 +0000
In-Reply-To: <1327092461-2701-14-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-14-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327323977.24561.115.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 13/21] xenstored: use grant references
 instead of map_foreign_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 Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> make xenstored use grantref rather than map_foreign_range (which can
> only be used by privileged domains)
> 
> This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
> instead of xc_map_foreign_range where available.
> 
> Previous versions of this patch have been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_domain.c |   52 ++++++++++++++++++++++++++++++++----
>  1 files changed, 46 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 443af82..661d955 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -32,8 +32,10 @@
>  #include "xenstored_watch.h"
>  
>  #include <xenctrl.h>
> +#include <xen/grant_table.h>
>  
>  static xc_interface **xc_handle;
> +static xc_gnttab **xcg_handle;
>  static evtchn_port_t virq_port;
>  
>  xc_evtchn *xce_handle = NULL;
> @@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
>  	return len;
>  }
>  
> +static void *map_interface(domid_t domid, unsigned long mfn)
> +{
> +	if (*xcg_handle >= 0) {
> +		/* this is the preferred method */
> +		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
> +			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
> +	} else {
> +		return xc_map_foreign_range(*xc_handle, domid,
> +			getpagesize(), PROT_READ|PROT_WRITE, mfn);
> +	}
> +}
> +
> +static void unmap_interface(void *interface)
> +{
> +	if (*xcg_handle >= 0)
> +		xc_gnttab_munmap(*xcg_handle, interface, 1);
> +	else
> +		munmap(interface, getpagesize());
> +}
> +
>  static int destroy_domain(void *_domain)
>  {
>  	struct domain *domain = _domain;
> @@ -174,8 +196,12 @@ static int destroy_domain(void *_domain)
>  			eprintf("> Unbinding port %i failed!\n", domain->port);
>  	}
>  
> -	if (domain->interface)
> -		munmap(domain->interface, getpagesize());
> +	if (domain->interface) {
> +		if (domain->domid == 0)
> +			munmap(domain->interface, getpagesize());
> +		else
> +			unmap_interface(domain->interface);
> +	}
>  
>  	fire_watches(NULL, "@releaseDomain", false);
>  
> @@ -344,9 +370,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
>  	domain = find_domain_by_domid(domid);
>  
>  	if (domain == NULL) {
> -		interface = xc_map_foreign_range(
> -			*xc_handle, domid,
> -			getpagesize(), PROT_READ|PROT_WRITE, mfn);
> +		interface = map_interface(domid, mfn);
>  		if (!interface) {
>  			send_error(conn, errno);
>  			return;
> @@ -354,7 +378,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
>  		/* Hang domain off "in" until we're finished. */
>  		domain = new_domain(in, domid, port);
>  		if (!domain) {
> -			munmap(interface, getpagesize());
> +			unmap_interface(interface);
>  			send_error(conn, errno);
>  			return;
>  		}
> @@ -552,6 +576,12 @@ static int close_xc_handle(void *_handle)
>  	return 0;
>  }
>  
> +static int close_xcg_handle(void *_handle)
> +{
> +	xc_gnttab_close(*(xc_gnttab **)_handle);
> +	return 0;
> +}
> +
>  /* Returns the implicit path of a connection (only domains have this) */
>  const char *get_implicit_path(const struct connection *conn)
>  {
> @@ -603,6 +633,16 @@ void domain_init(void)
>  
>  	talloc_set_destructor(xc_handle, close_xc_handle);
>  
> +	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
> +	if (!xcg_handle)
> +		barf_perror("Failed to allocate domain gnttab handle");
> +
> +	*xcg_handle = xc_gnttab_open(NULL, 0);
> +	if (*xcg_handle < 0)
> +		xprintf("WARNING: Failed to open connection to gnttab\n");
> +	else
> +		talloc_set_destructor(xcg_handle, close_xcg_handle);
> +
>  	xce_handle = xc_evtchn_open(NULL, 0);
>  
>  	if (xce_handle == NULL)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:12:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:12:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJh6-0008EQ-Rr; Mon, 23 Jan 2012 13:12:20 +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 1RpJh5-0008EK-8W
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:12:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327324333!12018843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14631 invoked from network); 23 Jan 2012 13:12:13 -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;
	23 Jan 2012 13:12:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:12: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, 23 Jan 2012 13:12:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 23 Jan 2012 13:12:10 +0000
In-Reply-To: <alpine.DEB.2.00.1201231022020.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-15-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201231022020.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324332.24561.119.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/21] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 10:33 +0000, Stefano Stabellini wrote:
> On Fri, 20 Jan 2012, Daniel De Graaf wrote:
> > From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> > 
> > option for compiling xenstored without unix sockets to support running on mini-OS
> 
> The amount of ifdef's introduced by this patch is not ideal.
> 
> Do you think is possible to refactor the code to use structures with
> function pointers, with a registration mechanism, so that in the dom0
> case you would end up with two structs (one for each kind of
> connections), while you would have only one on mini-OS?
> 
> We could have an initialize, a destroy and an accept_connection
> functions.

I suggested earlier that sprinkling checks for fd == -1 around instead
of ifdefs might end up more palatable -- e.g. for the changes in
initialize_set, destroy_fd, write_fd, the FD_ISSET test etc. Factoring
the setup code from main() into a function which can have an ifdef
nopped case would help too.

> > Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> > Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
[...]
> > diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> > index 0a01675..60f2cee 100644
> > --- a/tools/xenstore/xs.c
> > +++ b/tools/xenstore/xs.c
> > @@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
> >  {
> >  	struct xs_handle *xsh = NULL;
> >  
> > +#ifndef NO_SOCKETS
> >  	if (flags & XS_OPEN_READONLY)
> >  		xsh = get_handle(xs_daemon_socket_ro());
> >  	else
> >  		xsh = get_handle(xs_daemon_socket());
> > +#endif

I think tools/xenstore/xs.c is only used by the client library -- does
this change actual cause anything to happen?

[...]
> > +#ifndef NO_SOCKETS
> >  const char *xs_daemon_socket(void)
> >  {
> >  	return xs_daemon_path();
> > @@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
> >  		return NULL;
> >  	return buf;
> >  }
> > +#endif

If this returned NULL in the NO_SOCKETS case that might also help.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:12:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:12:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJh6-0008EQ-Rr; Mon, 23 Jan 2012 13:12:20 +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 1RpJh5-0008EK-8W
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:12:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327324333!12018843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14631 invoked from network); 23 Jan 2012 13:12:13 -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;
	23 Jan 2012 13:12:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:12: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, 23 Jan 2012 13:12:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Mon, 23 Jan 2012 13:12:10 +0000
In-Reply-To: <alpine.DEB.2.00.1201231022020.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-15-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201231022020.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324332.24561.119.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 14/21] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 10:33 +0000, Stefano Stabellini wrote:
> On Fri, 20 Jan 2012, Daniel De Graaf wrote:
> > From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> > 
> > option for compiling xenstored without unix sockets to support running on mini-OS
> 
> The amount of ifdef's introduced by this patch is not ideal.
> 
> Do you think is possible to refactor the code to use structures with
> function pointers, with a registration mechanism, so that in the dom0
> case you would end up with two structs (one for each kind of
> connections), while you would have only one on mini-OS?
> 
> We could have an initialize, a destroy and an accept_connection
> functions.

I suggested earlier that sprinkling checks for fd == -1 around instead
of ifdefs might end up more palatable -- e.g. for the changes in
initialize_set, destroy_fd, write_fd, the FD_ISSET test etc. Factoring
the setup code from main() into a function which can have an ifdef
nopped case would help too.

> > Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> > Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> > Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
[...]
> > diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
> > index 0a01675..60f2cee 100644
> > --- a/tools/xenstore/xs.c
> > +++ b/tools/xenstore/xs.c
> > @@ -271,10 +271,12 @@ struct xs_handle *xs_open(unsigned long flags)
> >  {
> >  	struct xs_handle *xsh = NULL;
> >  
> > +#ifndef NO_SOCKETS
> >  	if (flags & XS_OPEN_READONLY)
> >  		xsh = get_handle(xs_daemon_socket_ro());
> >  	else
> >  		xsh = get_handle(xs_daemon_socket());
> > +#endif

I think tools/xenstore/xs.c is only used by the client library -- does
this change actual cause anything to happen?

[...]
> > +#ifndef NO_SOCKETS
> >  const char *xs_daemon_socket(void)
> >  {
> >  	return xs_daemon_path();
> > @@ -73,6 +76,7 @@ const char *xs_daemon_socket_ro(void)
> >  		return NULL;
> >  	return buf;
> >  }
> > +#endif

If this returned NULL in the NO_SOCKETS case that might also help.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:15:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJjS-0008K4-De; Mon, 23 Jan 2012 13:14: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 1RpJjQ-0008Jt-C7
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:14:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327324447!49534805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17778 invoked from network); 23 Jan 2012 13:14:07 -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;
	23 Jan 2012 13:14:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:14: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, 23 Jan 2012 13:14:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 23 Jan 2012 13:14:42 +0000
In-Reply-To: <CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324482.24561.121.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 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

T24gTW9uLCAyMDEyLTAxLTIzIGF0IDExOjU5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8yMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIE1vbiwgMjAxMi0wMS0yMyBhdCAxMTozMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90
ZToKPiA+PiAyMDEyLzEvMjMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46
Cj4gPj4gPiBPbiBUdWUsIDIwMTItMDEtMDMgYXQgMTg6MDAgKzAwMDAsIElhbiBKYWNrc29uIHdy
b3RlOgo+ID4+ID4+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENI
IHYyXSBsaWJ4bDogYWRkIHN1cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4gPj4gPj4gPiBPbiBUaHUs
IDIwMTEtMTItMjIgYXQgMTY6NDEgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gPj4g
Pj4gPiA+IFNvbWUgYXV0b2dvbyBzdHVmZiB3aWxsIGJlIGdvb2QsIGF0IGxlYXN0IGZvciB0aGUg
dG9vbHMgYnVpbGQuIENhbiB5b3UKPiA+PiA+PiA+ID4gc2V0IHVwIHRoZSBiYXNpYyBzdHJ1Y3R1
cmUgSWFuPwo+ID4+ID4+ID4KPiA+PiA+PiA+IEknbSBub3QgZ29pbmcgdG8gaGF2ZSB0aW1lIGlu
IHRoZSBuZWFyIGZ1dHVyZS4KPiA+PiA+PiA+Cj4gPj4gPj4gPiBXb3VsZCBpdCBiZSBzdWZmaWNp
ZW50IHRvIGhhdmUgdGhlIHN0dWZmIGluIHRvb2xzL2NoZWNrIGNyZWF0ZSBhCj4gPj4gPj4gPiBj
b25maWcuaCBhcyB3ZWxsIGFzIGRvaW5nIHRoZSBjaGVja3M/IE1pZ2h0IG5lZWQgYSBiaXQgb2Yg
TWFrZWZpbGUgbWFnaWMKPiA+PiA+PiA+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMg
cnVuPwo+ID4+ID4+Cj4gPj4gPj4gRm9yIG5vdywgSSB0aGluayB3ZSBzaG91bGQgbm90IGFkZCBt
b3JlIHN0dWZmIHRvIHRoZSBjcml0aWNhbCBwYXRoIGZvcgo+ID4+ID4+IFhlbiA0LjIuICBCdXQg
YWZ0ZXIgdGhlbiB3ZSBzaG91bGQgc3dpdGNoIHRvIGF1dG9jb25mIEkgdGhpbmsuICAoSQo+ID4+
ID4+IGRvbid0IGFwcHJvdmUgb2YgYXV0b21ha2UuKQo+ID4+ID4KPiA+PiA+IEl0IHNlZW1zIHRo
YXQgeWFqbCAyLjAgc3VwcG9ydCBpcyBibG9ja2VkIG9uIHRoZSBhdXRvY29uZiBzdHVmZi4gQ2Fu
IHdlCj4gPj4gPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0IHdlIGNhbiBzdXBwb3J0IHlh
amwgMi4wIGluIFhlbiA0LjIgYW5kCj4gPj4gPiBzd2l0Y2ggdG8gYXV0b2NvbmYgYWZ0ZXJ3YXJk
cyBvciBkbyB3ZSBoYXZlL3dhbnQgdG8gbWFrZSB0aGUgc3dpdGNoIHRvCj4gPj4gPiBhdXRvY29u
ZiBmb3IgNC4yPwo+ID4+Cj4gPj4gVGhlIHByb3Bvc2VkIGF1dG9jb25mIHBhdGNoIGlzIGp1c3Qg
YSBjb252ZW5pZW50IHJlcGxhY2VtZW50IGZvcgo+ID4+IHRvb2xzL2NoZWNrIHNjcmlwdHMsIHdo
aWNoIGFsbG93cyB1cyB0byBnZW5lcmF0ZSBhIG1ha2VmaWxlIGFuZCBhCj4gPj4gaGVhZGVyIHdl
IGNhbiBpbmNsdWRlIHRvIGtub3cgdGhlIHN5c3RlbSBjYXBhYmlsaXRpZXMsIG5vdGhpbmcgbW9y
ZQo+ID4+IHdhcyBhZGRlZC4KPiA+Pgo+ID4+ID4gSSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBh
Ym91dCBjcml0aWNhbCBwYXRoIGZvciA0LjIuIEkgcHJlc3VtZQo+ID4+ID4gYXV0b2NvbmYgd291
bGQgcmVxdWlyZSBtb3JlIHRoYW4ganVzdCBjaGVja2luZyBpbiB0aGUgcGF0Y2hlcywKPiA+PiA+
IHNwZWNpZmljYWxseSBJJ20gdGhpbmtpbmcgb2YgdGhlIGF1dG9tYXRlZCB0ZXN0IHN5c3RlbSB1
cGRhdGUgYW5kIGRvY3MuCj4gPj4KPiA+PiBEb24ndCBrbm93IGhvdyBkaWZmaWN1bHQgaXQgaXMg
dG8gdXBkYXRlIHRoZSB0ZXN0IGJlZCB0byB1c2UgdGhlIG5ldwo+ID4+IGNvbmZpZ3VyZSBzY3Jp
cHQsIGlkZWFsbHkgaXQgc2hvdWxkIG9ubHkgcmVxdWlyZSBhZGRpbmcgIi4vY29uZmlndXJlIgo+
ID4+IGJlZm9yZSBwZXJmb3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cg
aG93IHRoZSB0ZXN0IGJlZAo+ID4+IHdvcmtzLCBpdCBtaWdodCBiZSBuZWNlc3NhcnkgdG8gcGFz
cyBzb21lIG9wdGlvbnMgdG8gY29uZmlndXJlCj4gPj4gZXhlY3V0aW9uIHRvIG9idGFpbiB0aGUg
c2FtZSByZXN1bHQuCj4gPgo+ID4gSWFuIEogd291bGQgaGF2ZSB0byBhbnN3ZXIgdGhhdCBvbmUu
IEhvcGVmdWxseSBqdXN0IHJ1bm5pbmcgLi9jb25maWd1cmUKPiA+IHdpbGwgZ2V0IHVzIGFzIGNs
b3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBleGlzdGluZyBzZXR1cC4KPiA+Cj4gPiBGV0lXIHRoZSB0
ZXN0ZXIgY29kZSBpcyBhdmFpbGFibGUgYXQgYSBnaXQgdXJsIHdoaWNoIGlzIGluIGV2ZXJ5IHBv
c3RlZAo+ID4gc2V0IG9mIHJlc3VsdHMuIFByb2JhYmx5IGxvb2tpbmcgZm9yIGFueXdoZXJlIHRo
YXQgd3JpdGVzIHRvIC5jb25maWcKPiA+IHdvdWxkIGJlIGEgZ29vZCBzdGFydCBmb3IgZGVjaWRp
bmcgaG93IGZhciBmcm9tIHRoZSBkZWZhdWx0cyBpdCBkZXZpYXRlcwo+ID4gKG5vdCBmYXIsIEkg
ZXhwZWN0KS4KPiA+Cj4gPj4gPiBPbiB0aGUgb3RoZXIgaGFuZCBSb2dlciBwb3N0ZWQgdjMgb2Yg
aGlzIGF1dG9jb25mIHN1cHBvcnQgcGF0Y2ggYW5kCj4gPj4gPiBhbHRob3VnaCBJIGhhdmVuJ3Qg
Z290IHJvdW5kIHRvIHJldmlld2luZyBpdCB5ZXQgKHNvcnJ5KSB2MidzIHJldmlldyB3YXMKPiA+
PiA+IGdlbmVyYWxseSBwb3NpdGl2ZS9taW5vciBsb29raW5nLgo+ID4+Cj4gPj4gdjMgaXMgYmFz
aWNhbGx5IGEgdjIgd2l0aCBhbGwgdGhlIG1lbnRpb25lZCBmaXhlcyBhbmQgdGhlIG91dHB1dCBm
cm9tCj4gPj4gYXV0b2NvbmYgJiBhdXRvbWFrZSwgc28gd2UgY2FuIHVzZSB0aGUgY29uZmlndXJl
IHNjcmlwdCBzdHJhaWdodCBhd2F5Lgo+ID4KPiA+IGF1dG9tYWtlPyBJIHRob3VnaHQgd2UgYWdy
ZWVkIG5vdCB0byB1c2UgdGhhdD8KPiAKPiBBdXRvdG9vbHMgaW4gZ2VuZXJhbCBpcyBxdWl0ZSBh
IG1lc3MsIHdlIGRvbid0IHVzZSBhdXRvbWFrZSwgYnV0IHdlCj4gbmVlZCBpdCB0byBnZW5lcmF0
ZSBjb25maWcuc3ViIGFuZCBjb25maWcuZ3Vlc3MgKHllcywgSSBrbm93IEkgY2FuCj4gYWxzbyBj
b3B5IHRoZW0pLiBUaGF0J3MgYWxsIHdlIG5lZWQgYXV0b21ha2UgZm9yIChkb24ndCBrbm93IHdo
eQo+IGF1dG9jb25mIGNhbid0IGRvIHRoaXMgYXV0b21hdGljYWxseS4uLikKCkFzIElhbkogKEkg
dGhpbmspIHNhaWQgd2Ugc2hvdWxkIGp1c3QgY29weSBhbmQgY29tbWl0IHRoZW0uCgo+ID4+IEFu
eXdheSwgdGhpcyBwYXRjaCBmb3IgYWRkaW5nIHN1cHBvcnQgb2YgeWFqbCAyLjAgbmVlZHMgc29t
ZSByZXdvcmssCj4gPj4gYWNjb3JkaW5nIHRvIHRoZSBjb21tZW50cyBtYWRlIGJ5IElhbiBKYWNr
c29uLCB3aGljaCBJIHdpbGwgdHJ5IHRvIGRvCj4gPj4gYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHdl
ZWsgKHNvcnJ5IGZvciB0aGUgZGVsYXksIGJ1dCBJJ20gcXVpdGUgYnVzeQo+ID4+IHRoaXMgZGF5
cykuCj4gPgo+ID4gU3VyZSwgbm8gcHJvYmxlbS4gSSBoYXZlIHB1dCB5YWpsMiBzdXBwb3J0IGlu
IHRoZSAibmljZSB0byBoYXZlIGNvbHVtbiIKPiA+IGFuZCBhdXRvY29uZiBpbiBhIG5ldyAibmVl
ZCB0byBkZWNpZGUgaWYgdGhpcyBpcyA0LjIgb3IgNC4zIG1hdGVyaWFsIgo+ID4gY29sdW1uLgo+
IAo+IFRoYW5rcywgSSdtIHN1cmUgeWFqbCAyLjAgc3VwcG9ydCB3aWxsIGdldCBpbnRvIDQuMiA6
KQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:15:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJjS-0008K4-De; Mon, 23 Jan 2012 13:14: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 1RpJjQ-0008Jt-C7
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:14:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327324447!49534805!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17778 invoked from network); 23 Jan 2012 13:14:07 -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;
	23 Jan 2012 13:14:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:14: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, 23 Jan 2012 13:14:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Mon, 23 Jan 2012 13:14:42 +0000
In-Reply-To: <CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324482.24561.121.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 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

T24gTW9uLCAyMDEyLTAxLTIzIGF0IDExOjU5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8yMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIE1vbiwgMjAxMi0wMS0yMyBhdCAxMTozMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90
ZToKPiA+PiAyMDEyLzEvMjMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46
Cj4gPj4gPiBPbiBUdWUsIDIwMTItMDEtMDMgYXQgMTg6MDAgKzAwMDAsIElhbiBKYWNrc29uIHdy
b3RlOgo+ID4+ID4+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENI
IHYyXSBsaWJ4bDogYWRkIHN1cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4gPj4gPj4gPiBPbiBUaHUs
IDIwMTEtMTItMjIgYXQgMTY6NDEgKzAwMDAsIFJvZ2VyIFBhdSBNb25uw6kgd3JvdGU6Cj4gPj4g
Pj4gPiA+IFNvbWUgYXV0b2dvbyBzdHVmZiB3aWxsIGJlIGdvb2QsIGF0IGxlYXN0IGZvciB0aGUg
dG9vbHMgYnVpbGQuIENhbiB5b3UKPiA+PiA+PiA+ID4gc2V0IHVwIHRoZSBiYXNpYyBzdHJ1Y3R1
cmUgSWFuPwo+ID4+ID4+ID4KPiA+PiA+PiA+IEknbSBub3QgZ29pbmcgdG8gaGF2ZSB0aW1lIGlu
IHRoZSBuZWFyIGZ1dHVyZS4KPiA+PiA+PiA+Cj4gPj4gPj4gPiBXb3VsZCBpdCBiZSBzdWZmaWNp
ZW50IHRvIGhhdmUgdGhlIHN0dWZmIGluIHRvb2xzL2NoZWNrIGNyZWF0ZSBhCj4gPj4gPj4gPiBj
b25maWcuaCBhcyB3ZWxsIGFzIGRvaW5nIHRoZSBjaGVja3M/IE1pZ2h0IG5lZWQgYSBiaXQgb2Yg
TWFrZWZpbGUgbWFnaWMKPiA+PiA+PiA+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMg
cnVuPwo+ID4+ID4+Cj4gPj4gPj4gRm9yIG5vdywgSSB0aGluayB3ZSBzaG91bGQgbm90IGFkZCBt
b3JlIHN0dWZmIHRvIHRoZSBjcml0aWNhbCBwYXRoIGZvcgo+ID4+ID4+IFhlbiA0LjIuICBCdXQg
YWZ0ZXIgdGhlbiB3ZSBzaG91bGQgc3dpdGNoIHRvIGF1dG9jb25mIEkgdGhpbmsuICAoSQo+ID4+
ID4+IGRvbid0IGFwcHJvdmUgb2YgYXV0b21ha2UuKQo+ID4+ID4KPiA+PiA+IEl0IHNlZW1zIHRo
YXQgeWFqbCAyLjAgc3VwcG9ydCBpcyBibG9ja2VkIG9uIHRoZSBhdXRvY29uZiBzdHVmZi4gQ2Fu
IHdlCj4gPj4gPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0IHdlIGNhbiBzdXBwb3J0IHlh
amwgMi4wIGluIFhlbiA0LjIgYW5kCj4gPj4gPiBzd2l0Y2ggdG8gYXV0b2NvbmYgYWZ0ZXJ3YXJk
cyBvciBkbyB3ZSBoYXZlL3dhbnQgdG8gbWFrZSB0aGUgc3dpdGNoIHRvCj4gPj4gPiBhdXRvY29u
ZiBmb3IgNC4yPwo+ID4+Cj4gPj4gVGhlIHByb3Bvc2VkIGF1dG9jb25mIHBhdGNoIGlzIGp1c3Qg
YSBjb252ZW5pZW50IHJlcGxhY2VtZW50IGZvcgo+ID4+IHRvb2xzL2NoZWNrIHNjcmlwdHMsIHdo
aWNoIGFsbG93cyB1cyB0byBnZW5lcmF0ZSBhIG1ha2VmaWxlIGFuZCBhCj4gPj4gaGVhZGVyIHdl
IGNhbiBpbmNsdWRlIHRvIGtub3cgdGhlIHN5c3RlbSBjYXBhYmlsaXRpZXMsIG5vdGhpbmcgbW9y
ZQo+ID4+IHdhcyBhZGRlZC4KPiA+Pgo+ID4+ID4gSSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBh
Ym91dCBjcml0aWNhbCBwYXRoIGZvciA0LjIuIEkgcHJlc3VtZQo+ID4+ID4gYXV0b2NvbmYgd291
bGQgcmVxdWlyZSBtb3JlIHRoYW4ganVzdCBjaGVja2luZyBpbiB0aGUgcGF0Y2hlcywKPiA+PiA+
IHNwZWNpZmljYWxseSBJJ20gdGhpbmtpbmcgb2YgdGhlIGF1dG9tYXRlZCB0ZXN0IHN5c3RlbSB1
cGRhdGUgYW5kIGRvY3MuCj4gPj4KPiA+PiBEb24ndCBrbm93IGhvdyBkaWZmaWN1bHQgaXQgaXMg
dG8gdXBkYXRlIHRoZSB0ZXN0IGJlZCB0byB1c2UgdGhlIG5ldwo+ID4+IGNvbmZpZ3VyZSBzY3Jp
cHQsIGlkZWFsbHkgaXQgc2hvdWxkIG9ubHkgcmVxdWlyZSBhZGRpbmcgIi4vY29uZmlndXJlIgo+
ID4+IGJlZm9yZSBwZXJmb3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cg
aG93IHRoZSB0ZXN0IGJlZAo+ID4+IHdvcmtzLCBpdCBtaWdodCBiZSBuZWNlc3NhcnkgdG8gcGFz
cyBzb21lIG9wdGlvbnMgdG8gY29uZmlndXJlCj4gPj4gZXhlY3V0aW9uIHRvIG9idGFpbiB0aGUg
c2FtZSByZXN1bHQuCj4gPgo+ID4gSWFuIEogd291bGQgaGF2ZSB0byBhbnN3ZXIgdGhhdCBvbmUu
IEhvcGVmdWxseSBqdXN0IHJ1bm5pbmcgLi9jb25maWd1cmUKPiA+IHdpbGwgZ2V0IHVzIGFzIGNs
b3NlIGFzIHBvc3NpYmxlIHRvIHRoZSBleGlzdGluZyBzZXR1cC4KPiA+Cj4gPiBGV0lXIHRoZSB0
ZXN0ZXIgY29kZSBpcyBhdmFpbGFibGUgYXQgYSBnaXQgdXJsIHdoaWNoIGlzIGluIGV2ZXJ5IHBv
c3RlZAo+ID4gc2V0IG9mIHJlc3VsdHMuIFByb2JhYmx5IGxvb2tpbmcgZm9yIGFueXdoZXJlIHRo
YXQgd3JpdGVzIHRvIC5jb25maWcKPiA+IHdvdWxkIGJlIGEgZ29vZCBzdGFydCBmb3IgZGVjaWRp
bmcgaG93IGZhciBmcm9tIHRoZSBkZWZhdWx0cyBpdCBkZXZpYXRlcwo+ID4gKG5vdCBmYXIsIEkg
ZXhwZWN0KS4KPiA+Cj4gPj4gPiBPbiB0aGUgb3RoZXIgaGFuZCBSb2dlciBwb3N0ZWQgdjMgb2Yg
aGlzIGF1dG9jb25mIHN1cHBvcnQgcGF0Y2ggYW5kCj4gPj4gPiBhbHRob3VnaCBJIGhhdmVuJ3Qg
Z290IHJvdW5kIHRvIHJldmlld2luZyBpdCB5ZXQgKHNvcnJ5KSB2MidzIHJldmlldyB3YXMKPiA+
PiA+IGdlbmVyYWxseSBwb3NpdGl2ZS9taW5vciBsb29raW5nLgo+ID4+Cj4gPj4gdjMgaXMgYmFz
aWNhbGx5IGEgdjIgd2l0aCBhbGwgdGhlIG1lbnRpb25lZCBmaXhlcyBhbmQgdGhlIG91dHB1dCBm
cm9tCj4gPj4gYXV0b2NvbmYgJiBhdXRvbWFrZSwgc28gd2UgY2FuIHVzZSB0aGUgY29uZmlndXJl
IHNjcmlwdCBzdHJhaWdodCBhd2F5Lgo+ID4KPiA+IGF1dG9tYWtlPyBJIHRob3VnaHQgd2UgYWdy
ZWVkIG5vdCB0byB1c2UgdGhhdD8KPiAKPiBBdXRvdG9vbHMgaW4gZ2VuZXJhbCBpcyBxdWl0ZSBh
IG1lc3MsIHdlIGRvbid0IHVzZSBhdXRvbWFrZSwgYnV0IHdlCj4gbmVlZCBpdCB0byBnZW5lcmF0
ZSBjb25maWcuc3ViIGFuZCBjb25maWcuZ3Vlc3MgKHllcywgSSBrbm93IEkgY2FuCj4gYWxzbyBj
b3B5IHRoZW0pLiBUaGF0J3MgYWxsIHdlIG5lZWQgYXV0b21ha2UgZm9yIChkb24ndCBrbm93IHdo
eQo+IGF1dG9jb25mIGNhbid0IGRvIHRoaXMgYXV0b21hdGljYWxseS4uLikKCkFzIElhbkogKEkg
dGhpbmspIHNhaWQgd2Ugc2hvdWxkIGp1c3QgY29weSBhbmQgY29tbWl0IHRoZW0uCgo+ID4+IEFu
eXdheSwgdGhpcyBwYXRjaCBmb3IgYWRkaW5nIHN1cHBvcnQgb2YgeWFqbCAyLjAgbmVlZHMgc29t
ZSByZXdvcmssCj4gPj4gYWNjb3JkaW5nIHRvIHRoZSBjb21tZW50cyBtYWRlIGJ5IElhbiBKYWNr
c29uLCB3aGljaCBJIHdpbGwgdHJ5IHRvIGRvCj4gPj4gYmVmb3JlIHRoZSBlbmQgb2YgdGhlIHdl
ZWsgKHNvcnJ5IGZvciB0aGUgZGVsYXksIGJ1dCBJJ20gcXVpdGUgYnVzeQo+ID4+IHRoaXMgZGF5
cykuCj4gPgo+ID4gU3VyZSwgbm8gcHJvYmxlbS4gSSBoYXZlIHB1dCB5YWpsMiBzdXBwb3J0IGlu
IHRoZSAibmljZSB0byBoYXZlIGNvbHVtbiIKPiA+IGFuZCBhdXRvY29uZiBpbiBhIG5ldyAibmVl
ZCB0byBkZWNpZGUgaWYgdGhpcyBpcyA0LjIgb3IgNC4zIG1hdGVyaWFsIgo+ID4gY29sdW1uLgo+
IAo+IFRoYW5rcywgSSdtIHN1cmUgeWFqbCAyLjAgc3VwcG9ydCB3aWxsIGdldCBpbnRvIDQuMiA6
KQoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4t
ZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9s
aXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:15:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJjZ-0008Kl-Qg; Mon, 23 Jan 2012 13:14:53 +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 1RpJjY-0008KF-KG
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:14:52 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327324439!51214938!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31400 invoked from network); 23 Jan 2012 13:13:59 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	23 Jan 2012 13:13:59 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74950324; Mon, 23 Jan 2012 14:14:43 +0100
Message-ID: <1327324455.2476.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 23 Jan 2012 14:14:15 +0100
In-Reply-To: <1327313995.24561.13.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078460.30054.74.camel@zakaz.uk.xensource.com>
	<1327080768.2337.65.camel@Abyss>
	<1327313995.24561.13.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9089661589145720289=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============9089661589145720289==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-U3pxmLH2fvW++9EIS874"


--=-U3pxmLH2fvW++9EIS874
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-01-23 at 10:19 +0000, Ian Campbell wrote:=20
> > According to me, it should.
>=20
> I agree.
>=20
> One idea I had over the weekend is that we could support a special
> 'cpus=3D"pool"' syntax to mean "pin this guest to the node I configured i=
t
> to be in". I think this is a second best option to simply having
> d->node_affinity reflect the pool though.
>=20
Which is exactly what Juergen is doing, right? Or you meant something
else?

> >  Then, at least right now, moving it would
> > probably kill its performances because all its memory will be far away,
> > while right now it's all more "stochastic".
>=20
> Yes, in some sense the xend behaviour is best case good behaviour and
> worse case bad behaviour, while xl has a more average/consistent
> behaviour across the range. In practice however I suspect xend probably
> hits the good cases more often than not.
>=20
Me too. I'm thinking how/working to get to something even better! :-)

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)



--=-U3pxmLH2fvW++9EIS874
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)

iEYEABECAAYFAk8dXScACgkQk4XaBE3IOsSOzwCfT0BnOaAmv49woxGTunDNA1qg
0iAAoKye9x/fJbYeaO208UIvISRZuQC5
=jU1W
-----END PGP SIGNATURE-----

--=-U3pxmLH2fvW++9EIS874--



--===============9089661589145720289==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9089661589145720289==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:15:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:15:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJjZ-0008Kl-Qg; Mon, 23 Jan 2012 13:14:53 +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 1RpJjY-0008KF-KG
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:14:52 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327324439!51214938!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31400 invoked from network); 23 Jan 2012 13:13:59 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-27.messagelabs.com with SMTP;
	23 Jan 2012 13:13:59 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74950324; Mon, 23 Jan 2012 14:14:43 +0100
Message-ID: <1327324455.2476.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 23 Jan 2012 14:14:15 +0100
In-Reply-To: <1327313995.24561.13.camel@zakaz.uk.xensource.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078460.30054.74.camel@zakaz.uk.xensource.com>
	<1327080768.2337.65.camel@Abyss>
	<1327313995.24561.13.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9089661589145720289=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============9089661589145720289==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-U3pxmLH2fvW++9EIS874"


--=-U3pxmLH2fvW++9EIS874
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-01-23 at 10:19 +0000, Ian Campbell wrote:=20
> > According to me, it should.
>=20
> I agree.
>=20
> One idea I had over the weekend is that we could support a special
> 'cpus=3D"pool"' syntax to mean "pin this guest to the node I configured i=
t
> to be in". I think this is a second best option to simply having
> d->node_affinity reflect the pool though.
>=20
Which is exactly what Juergen is doing, right? Or you meant something
else?

> >  Then, at least right now, moving it would
> > probably kill its performances because all its memory will be far away,
> > while right now it's all more "stochastic".
>=20
> Yes, in some sense the xend behaviour is best case good behaviour and
> worse case bad behaviour, while xl has a more average/consistent
> behaviour across the range. In practice however I suspect xend probably
> hits the good cases more often than not.
>=20
Me too. I'm thinking how/working to get to something even better! :-)

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)



--=-U3pxmLH2fvW++9EIS874
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)

iEYEABECAAYFAk8dXScACgkQk4XaBE3IOsSOzwCfT0BnOaAmv49woxGTunDNA1qg
0iAAoKye9x/fJbYeaO208UIvISRZuQC5
=jU1W
-----END PGP SIGNATURE-----

--=-U3pxmLH2fvW++9EIS874--



--===============9089661589145720289==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9089661589145720289==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:15:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJkB-0008PM-8p; Mon, 23 Jan 2012 13:15: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 1RpJk9-0008Ob-G8
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327324502!63567639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 625 invoked from network); 23 Jan 2012 13:15:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:14:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 13:14:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:14:59 +0000
In-Reply-To: <1327092461-2701-16-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-16-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324499.24561.122.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/21] xenstored: support for tdb_copy with
 TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
> databases; this is required to run in mini-os which does not use a
> filesystem.
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:15:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:15:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJkB-0008PM-8p; Mon, 23 Jan 2012 13:15: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 1RpJk9-0008Ob-G8
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:15:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327324502!63567639!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 625 invoked from network); 23 Jan 2012 13:15:03 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:15:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215308"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:14:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 13:14:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:14:59 +0000
In-Reply-To: <1327092461-2701-16-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-16-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324499.24561.122.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 15/21] xenstored: support for tdb_copy with
 TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
> databases; this is required to run in mini-os which does not use a
> filesystem.
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:18:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJmV-0000Kg-Rc; Mon, 23 Jan 2012 13:17:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1RpJmU-0000K4-0C; Mon, 23 Jan 2012 13:17:54 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327324611!58052546!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3185 invoked from network); 23 Jan 2012 13:16:51 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-27.messagelabs.com with SMTP;
	23 Jan 2012 13:16:51 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 648BBD347C3;
	Mon, 23 Jan 2012 14:17:49 +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 g7ylZct34pih; Mon, 23 Jan 2012 14:17:46 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 03322D347C4;
	Mon, 23 Jan 2012 14:17:44 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Mon, 23 Jan 2012 14:17:42 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327318778.24561.74.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201201231417.43018.tobias.geiger@vido.info>
Cc: Sandi Romih <romihs.forums@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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!

The thing is, you either dont need patches at all to get it to work (ATI), or 
you need to customize patches reflecting your individual setup (NVIDIA);

To be more specific:
I can confirm that passing through a ATI Card works "out of the box" - either 
to Windows 7 or Windows XP;
In the past i had a setup running with a NVIDIA card, it only worked with 
special patches (the ones David packed together and offers as tarball) and - as 
far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you 
have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then the 
passed through Card worked only with Windows XP - NOT with Windows 7;

Both setup have the "flaw" that they only work once - meaning you can't reboot 
your DomU , cause after the reboot the passed-through Card doesnt have correct 
3D-Accelleration any more (was/is the case with NVIDIA and ATI, Windows XP and 
Windows7 )

So - to summarize: It works easiest and most featureful with a ATI Card; 
                            It may work with patches and only with WindowsXP 
with an NVIDIA card

To me it seems that unless someone finds an general approach to runtime-detect 
the NVIDIA-Secific stuff , submitting any patches may be to early, as it arouses 
expectations which only in some cases will be met.

That said - i gladly can forward-port these old patches, if you think they are 
helping in any way.

Greetings!
Tobias

Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
> Please do not a) top-post or b) cross-post. The latter being aimed at
> whoever started this thread.
> 
> On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
> > Yeah, I guess xen has generally been focused on the server end.
> 
> Xen is focused on whatever people submit patches to do. Many of the core
> developers are not currently looking at VGA passthrough, we have plenty
> of stuff on our plates, but we are more than happy to review and accept
> patches to implement/improve/fix this feature if only those people who
> are interested in it would take the time to submit them per
> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
> going to go out hunting for patches on the Internet.
> 
> David Techer recently offered to do this but perhaps he would be
> interested in some help from you?
> 
> 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 Jan 23 13:18:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJmV-0000Kg-Rc; Mon, 23 Jan 2012 13:17:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1RpJmU-0000K4-0C; Mon, 23 Jan 2012 13:17:54 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327324611!58052546!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3185 invoked from network); 23 Jan 2012 13:16:51 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-27.messagelabs.com with SMTP;
	23 Jan 2012 13:16:51 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 648BBD347C3;
	Mon, 23 Jan 2012 14:17:49 +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 g7ylZct34pih; Mon, 23 Jan 2012 14:17:46 +0100 (CET)
Received: from lxgeigert.localnet (et-1-10.gw-nat.bs.kae.de.oneandone.net
	[212.227.35.74])
	by mail.vido.info (Postfix) with ESMTPSA id 03322D347C4;
	Mon, 23 Jan 2012 14:17:44 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: xen-devel@lists.xensource.com
Date: Mon, 23 Jan 2012 14:17:42 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327318778.24561.74.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Message-Id: <201201231417.43018.tobias.geiger@vido.info>
Cc: Sandi Romih <romihs.forums@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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!

The thing is, you either dont need patches at all to get it to work (ATI), or 
you need to customize patches reflecting your individual setup (NVIDIA);

To be more specific:
I can confirm that passing through a ATI Card works "out of the box" - either 
to Windows 7 or Windows XP;
In the past i had a setup running with a NVIDIA card, it only worked with 
special patches (the ones David packed together and offers as tarball) and - as 
far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you 
have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then the 
passed through Card worked only with Windows XP - NOT with Windows 7;

Both setup have the "flaw" that they only work once - meaning you can't reboot 
your DomU , cause after the reboot the passed-through Card doesnt have correct 
3D-Accelleration any more (was/is the case with NVIDIA and ATI, Windows XP and 
Windows7 )

So - to summarize: It works easiest and most featureful with a ATI Card; 
                            It may work with patches and only with WindowsXP 
with an NVIDIA card

To me it seems that unless someone finds an general approach to runtime-detect 
the NVIDIA-Secific stuff , submitting any patches may be to early, as it arouses 
expectations which only in some cases will be met.

That said - i gladly can forward-port these old patches, if you think they are 
helping in any way.

Greetings!
Tobias

Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
> Please do not a) top-post or b) cross-post. The latter being aimed at
> whoever started this thread.
> 
> On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
> > Yeah, I guess xen has generally been focused on the server end.
> 
> Xen is focused on whatever people submit patches to do. Many of the core
> developers are not currently looking at VGA passthrough, we have plenty
> of stuff on our plates, but we are more than happy to review and accept
> patches to implement/improve/fix this feature if only those people who
> are interested in it would take the time to submit them per
> http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
> going to go out hunting for patches on the Internet.
> 
> David Techer recently offered to do this but perhaps he would be
> interested in some help from you?
> 
> 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 Jan 23 13:18:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:18:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJmd-0000MV-3L; Mon, 23 Jan 2012 13:18:03 +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 1RpJmb-0000Kk-BS
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:18:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327324675!4698228!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5994 invoked from network); 23 Jan 2012 13:17:55 -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 Jan 2012 13:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:17:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 13:17:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:17:29 +0000
In-Reply-To: <1327092461-2701-18-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-18-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324649.24561.123.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 17/21] stubdom: enable xenstored 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

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/apps/xenstore.mk |    8 ++++++++
>  stubdom/Makefile                |   29 ++++++++++++++++++++++++++---
>  2 files changed, 34 insertions(+), 3 deletions(-)
>  create mode 100644 extras/mini-os/apps/xenstore.mk
> 
> diff --git a/extras/mini-os/apps/xenstore.mk b/extras/mini-os/apps/xenstore.mk
> new file mode 100644
> index 0000000..26ff9a6
> --- /dev/null
> +++ b/extras/mini-os/apps/xenstore.mk
> @@ -0,0 +1,8 @@
> +CONFIG_BLKFRONT=n
> +CONFIG_NETFRONT=n
> +CONFIG_FBFRONT=n
> +CONFIG_KBDFRONT=n
> +CONFIG_XENBUS=n

I see now why you added this possibility.

> +
> +lwip=n
> +DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS))
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 7989f31..0718e50 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
>  
>  TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
>  
> -TARGETS=ioemu c caml grub
> +TARGETS=ioemu c caml grub xenstore
>  
>  CROSS_MAKE := $(MAKE) DESTDIR=
>  
>  .PHONY: all
>  all: build
>  ifeq ($(STUBDOM_SUPPORTED),1)
> -build: genpath ioemu-stubdom c-stubdom pv-grub
> +build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
>  else
>  build: genpath
>  endif
> @@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
>  	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
>  	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
>  	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
> +	mkdir -p xenstore
> +	[ -h xenstore/Makefile ] || ( cd xenstore && \
> +	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
> +	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
> +	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
>  	$(CROSS_MAKE) -C $(MINI_OS) links
>  	touch mk-headers-$(XEN_TARGET_ARCH)
>  
> @@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
>  	mkdir -p grub-$(XEN_TARGET_ARCH)
>  	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
>  
> +##########
> +# xenstore
> +##########
> +
> +.PHONY: xenstore
> +xenstore: $(CROSS_ROOT)
> +	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
> +
>  ########
>  # minios
>  ########
> @@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
>  pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
>  	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=grub $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
>  
> +.PHONY: xenstore-stubdom
> +xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
> +	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=xenstore $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
> +
>  #########
>  # install
>  #########
>  
>  ifeq ($(STUBDOM_SUPPORTED),1)
> -install: genpath install-readme install-ioemu install-grub
> +install: genpath install-readme install-ioemu install-grub install-xenstore
>  else
>  install: genpath
>  endif
> @@ -379,6 +396,10 @@ install-grub: pv-grub
>  	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
>  	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
>  
> +install-xenstore: xenstore-stubdom
> +	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
> +	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
> +
>  #######
>  # clean
>  #######
> @@ -390,12 +411,14 @@ clean:
>  	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
>  	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
>  	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
> +	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
>  	$(CROSS_MAKE) -C caml clean
>  	$(CROSS_MAKE) -C c clean
>  	rm -fr grub-$(XEN_TARGET_ARCH)
>  	rm -f $(STUBDOMPATH)
>  	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
>  	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
> +	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
>  
>  # clean the cross-compilation result
>  .PHONY: crossclean



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:18:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:18:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJmd-0000MV-3L; Mon, 23 Jan 2012 13:18:03 +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 1RpJmb-0000Kk-BS
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:18:01 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327324675!4698228!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5994 invoked from network); 23 Jan 2012 13:17:55 -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 Jan 2012 13:17:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:17:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 13:17:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:17:29 +0000
In-Reply-To: <1327092461-2701-18-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-18-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324649.24561.123.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 17/21] stubdom: enable xenstored 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

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  extras/mini-os/apps/xenstore.mk |    8 ++++++++
>  stubdom/Makefile                |   29 ++++++++++++++++++++++++++---
>  2 files changed, 34 insertions(+), 3 deletions(-)
>  create mode 100644 extras/mini-os/apps/xenstore.mk
> 
> diff --git a/extras/mini-os/apps/xenstore.mk b/extras/mini-os/apps/xenstore.mk
> new file mode 100644
> index 0000000..26ff9a6
> --- /dev/null
> +++ b/extras/mini-os/apps/xenstore.mk
> @@ -0,0 +1,8 @@
> +CONFIG_BLKFRONT=n
> +CONFIG_NETFRONT=n
> +CONFIG_FBFRONT=n
> +CONFIG_KBDFRONT=n
> +CONFIG_XENBUS=n

I see now why you added this possibility.

> +
> +lwip=n
> +DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS))
> diff --git a/stubdom/Makefile b/stubdom/Makefile
> index 7989f31..0718e50 100644
> --- a/stubdom/Makefile
> +++ b/stubdom/Makefile
> @@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
>  
>  TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
>  
> -TARGETS=ioemu c caml grub
> +TARGETS=ioemu c caml grub xenstore
>  
>  CROSS_MAKE := $(MAKE) DESTDIR=
>  
>  .PHONY: all
>  all: build
>  ifeq ($(STUBDOM_SUPPORTED),1)
> -build: genpath ioemu-stubdom c-stubdom pv-grub
> +build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
>  else
>  build: genpath
>  endif
> @@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
>  	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
>  	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
>  	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
> +	mkdir -p xenstore
> +	[ -h xenstore/Makefile ] || ( cd xenstore && \
> +	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
> +	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
> +	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
>  	$(CROSS_MAKE) -C $(MINI_OS) links
>  	touch mk-headers-$(XEN_TARGET_ARCH)
>  
> @@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
>  	mkdir -p grub-$(XEN_TARGET_ARCH)
>  	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
>  
> +##########
> +# xenstore
> +##########
> +
> +.PHONY: xenstore
> +xenstore: $(CROSS_ROOT)
> +	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
> +
>  ########
>  # minios
>  ########
> @@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
>  pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
>  	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=grub $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
>  
> +.PHONY: xenstore-stubdom
> +xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
> +	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_APP=xenstore $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
> +
>  #########
>  # install
>  #########
>  
>  ifeq ($(STUBDOM_SUPPORTED),1)
> -install: genpath install-readme install-ioemu install-grub
> +install: genpath install-readme install-ioemu install-grub install-xenstore
>  else
>  install: genpath
>  endif
> @@ -379,6 +396,10 @@ install-grub: pv-grub
>  	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
>  	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
>  
> +install-xenstore: xenstore-stubdom
> +	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
> +	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
> +
>  #######
>  # clean
>  #######
> @@ -390,12 +411,14 @@ clean:
>  	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
>  	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
>  	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
> +	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
>  	$(CROSS_MAKE) -C caml clean
>  	$(CROSS_MAKE) -C c clean
>  	rm -fr grub-$(XEN_TARGET_ARCH)
>  	rm -f $(STUBDOMPATH)
>  	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
>  	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
> +	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
>  
>  # clean the cross-compilation result
>  .PHONY: crossclean



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:19:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJnj-0000dY-LL; Mon, 23 Jan 2012 13:19: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 1RpJni-0000ci-6T
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:19:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327324703!61365109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10983 invoked from network); 23 Jan 2012 13:18:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:18:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:19:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 13:19:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 13:19:05 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 TODO List 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

Newly updated list follows. Please send me corrections (especially
"done"). I've stopped CCing everyone, since I guess it is mostly spam to
the majority. 

hypervisor, blockers:

      * round-up of the closing of the security hole in MSI-X
        passthrough (uniformly - i.e. even for Dom0 - disallowing write
        access to MSI-X table pages). (Jan Beulich -- more fixes
        required than first thought, patches posted)
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice and schedule rate. (George Dunlap)
      * get the interface changes for sharing/paging/mem-events done and
        dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
        Andres Lagar-Cavilla et al)
              * mem event ring management posted, seems close to going
                in.
              * sharing patches posted

tools, blockers:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (Ian Jackson, posted several rounds,
                nearing completion?)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate) (Ian Campbell, first RFC sent)
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                first RFC sent)
              * topologyinfo datastructure should be a list of tuples,
                not a tuple of lists. (nobody currently looking at this,
                not 100% sure this makes sense, could possibly defer and
                change after 4.2 in a compatible way)
      * xl to use json for machine readable output instead of sexp by
        default (Ian Campbell to revisit existing patch)
      * xl support for vcpu pinning (Dario Faggioli)
      * xl feature parity with xend wrt driver domain support (George
        Dunlap)
      * Integrate qemu+seabios upstream into the build (patches
        reposted, pending). No change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

hypervisor, nice to have:

      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al)
      * A long standing issue is a fully synchronized p2m (locking
        lookups) (Andres Lagar-Cavilla)
      * NUMA improvement: domain affinity consistent with cpupool
        membership (Dario Faggioli, Jeurgen Gross -- patch posted)

tools, nice to have:

      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms. (discussion on-going)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monet)
      * libyajl v2 support (patch posted by Roger Pau Monet, blocked on
        autoconf?)
      * Configure/control paging via xl/libxl (Olaf Herring)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard)
              * Upstream qemu save restore (Anthony Perard)
      * Nested-virtualisation (currently should be marked
        experimental,likely to release that way? Consider nested-svm
        separate to nested-vmx. Nested-svm is in better shape)

Tools, need to decide if pre- or post-4.2 feature:

      * Autoconf (Roger Pau Monet posted a patch)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:19:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpJnj-0000dY-LL; Mon, 23 Jan 2012 13:19: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 1RpJni-0000ci-6T
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:19:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327324703!61365109!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10983 invoked from network); 23 Jan 2012 13:18:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:18:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:19:06 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 13:19:06 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 13:19:05 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 TODO List 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

Newly updated list follows. Please send me corrections (especially
"done"). I've stopped CCing everyone, since I guess it is mostly spam to
the majority. 

hypervisor, blockers:

      * round-up of the closing of the security hole in MSI-X
        passthrough (uniformly - i.e. even for Dom0 - disallowing write
        access to MSI-X table pages). (Jan Beulich -- more fixes
        required than first thought, patches posted)
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice and schedule rate. (George Dunlap)
      * get the interface changes for sharing/paging/mem-events done and
        dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
        Andres Lagar-Cavilla et al)
              * mem event ring management posted, seems close to going
                in.
              * sharing patches posted

tools, blockers:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (Ian Jackson, posted several rounds,
                nearing completion?)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate) (Ian Campbell, first RFC sent)
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                first RFC sent)
              * topologyinfo datastructure should be a list of tuples,
                not a tuple of lists. (nobody currently looking at this,
                not 100% sure this makes sense, could possibly defer and
                change after 4.2 in a compatible way)
      * xl to use json for machine readable output instead of sexp by
        default (Ian Campbell to revisit existing patch)
      * xl support for vcpu pinning (Dario Faggioli)
      * xl feature parity with xend wrt driver domain support (George
        Dunlap)
      * Integrate qemu+seabios upstream into the build (patches
        reposted, pending). No change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

hypervisor, nice to have:

      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al)
      * A long standing issue is a fully synchronized p2m (locking
        lookups) (Andres Lagar-Cavilla)
      * NUMA improvement: domain affinity consistent with cpupool
        membership (Dario Faggioli, Jeurgen Gross -- patch posted)

tools, nice to have:

      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms. (discussion on-going)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monet)
      * libyajl v2 support (patch posted by Roger Pau Monet, blocked on
        autoconf?)
      * Configure/control paging via xl/libxl (Olaf Herring)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard)
              * Upstream qemu save restore (Anthony Perard)
      * Nested-virtualisation (currently should be marked
        experimental,likely to release that way? Consider nested-svm
        separate to nested-vmx. Nested-svm is in better shape)

Tools, need to decide if pre- or post-4.2 feature:

      * Autoconf (Roger Pau Monet posted a patch)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJpA-0000ue-78; Mon, 23 Jan 2012 13:20:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpJp8-0000tp-He
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:20:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327324832!10312629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32181 invoked from network); 23 Jan 2012 13:20:32 -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;
	23 Jan 2012 13:20:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215833"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:20: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, 23 Jan 2012 13:20:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Mon, 23 Jan 2012 13:20:31 +0000
In-Reply-To: <1327324455.2476.4.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078460.30054.74.camel@zakaz.uk.xensource.com>
	<1327080768.2337.65.camel@Abyss>
	<1327313995.24561.13.camel@zakaz.uk.xensource.com>
	<1327324455.2476.4.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324831.24561.125.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 13:14 +0000, Dario Faggioli wrote:
> On Mon, 2012-01-23 at 10:19 +0000, Ian Campbell wrote: 
> > > According to me, it should.
> > 
> > I agree.
> > 
> > One idea I had over the weekend is that we could support a special
> > 'cpus="pool"' syntax to mean "pin this guest to the node I configured it
> > to be in". I think this is a second best option to simply having
> > d->node_affinity reflect the pool though.
> > 
> Which is exactly what Juergen is doing, right? Or you meant something
> else?

I meant what Jeurgen is doing, I just hadn't seen that mail yet.

> > >  Then, at least right now, moving it would
> > > probably kill its performances because all its memory will be far away,
> > > while right now it's all more "stochastic".
> > 
> > Yes, in some sense the xend behaviour is best case good behaviour and
> > worse case bad behaviour, while xl has a more average/consistent
> > behaviour across the range. In practice however I suspect xend probably
> > hits the good cases more often than not.
> > 
> Me too. I'm thinking how/working to get to something even better! :-)

Great.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:20:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJpA-0000ue-78; Mon, 23 Jan 2012 13:20:40 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpJp8-0000tp-He
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:20:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327324832!10312629!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32181 invoked from network); 23 Jan 2012 13:20:32 -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;
	23 Jan 2012 13:20:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10215833"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:20: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, 23 Jan 2012 13:20:31 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Mon, 23 Jan 2012 13:20:31 +0000
In-Reply-To: <1327324455.2476.4.camel@Abyss>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20120119211430.GT12984@reaktio.net>
	<1327046368.21391.29.camel@dagon.hellion.org.uk>
	<alpine.DEB.2.00.1201201048460.3150@kaball-desktop>
	<1327058562.17599.134.camel@zakaz.uk.xensource.com>
	<1327059874.2337.38.camel@Abyss>
	<1327060480.30054.15.camel@zakaz.uk.xensource.com>
	<1327061083.2337.42.camel@Abyss>
	<1327062788.30054.31.camel@zakaz.uk.xensource.com>
	<1327065091.30054.43.camel@zakaz.uk.xensource.com>
	<1327071976.30054.55.camel@zakaz.uk.xensource.com>
	<1327075340.2337.50.camel@Abyss>
	<1327076495.30054.63.camel@zakaz.uk.xensource.com>
	<1327076924.30054.65.camel@zakaz.uk.xensource.com>
	<1327077068.23358.97.camel@elijah>
	<1327077590.30054.71.camel@zakaz.uk.xensource.com>
	<1327077796.23358.98.camel@elijah>
	<1327078460.30054.74.camel@zakaz.uk.xensource.com>
	<1327080768.2337.65.camel@Abyss>
	<1327313995.24561.13.camel@zakaz.uk.xensource.com>
	<1327324455.2476.4.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327324831.24561.125.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	"Tim \(Xen.org\)" <tim@xen.org>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] RFC: Still TODO for 4.2? xl domain numa memory
 allocation vs xm/xend
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 13:14 +0000, Dario Faggioli wrote:
> On Mon, 2012-01-23 at 10:19 +0000, Ian Campbell wrote: 
> > > According to me, it should.
> > 
> > I agree.
> > 
> > One idea I had over the weekend is that we could support a special
> > 'cpus="pool"' syntax to mean "pin this guest to the node I configured it
> > to be in". I think this is a second best option to simply having
> > d->node_affinity reflect the pool though.
> > 
> Which is exactly what Juergen is doing, right? Or you meant something
> else?

I meant what Jeurgen is doing, I just hadn't seen that mail yet.

> > >  Then, at least right now, moving it would
> > > probably kill its performances because all its memory will be far away,
> > > while right now it's all more "stochastic".
> > 
> > Yes, in some sense the xend behaviour is best case good behaviour and
> > worse case bad behaviour, while xl has a more average/consistent
> > behaviour across the range. In practice however I suspect xend probably
> > hits the good cases more often than not.
> > 
> Me too. I'm thinking how/working to get to something even better! :-)

Great.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:21:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJpk-000119-L7; Mon, 23 Jan 2012 13:21: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 1RpJpi-0000zX-N7
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:21:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327324866!10283779!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20838 invoked from network); 23 Jan 2012 13:21:08 -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;
	23 Jan 2012 13:21:08 -0000
Received: by pbdx13 with SMTP id x13so2800034pbd.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 05:21: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=sV2pLl+0jUjl9NqSY82kDrMJcZZgguEBpIRLIyBtWto=;
	b=gQk+B4xVCEuRu7MdfWopezA1CDzDF2HK/8m/pLIzNj9vT+b1HUBPaZJEvBegOUo6lc
	KQq6jDNDlotIUi5zrwPoXqsZvf6zG4xg1LM9FLUCTVutIo5N5MlLcX7PpgL7IT/1wtHD
	qp8w+c3+tmM518ttpQuJdbYa4xtorjdz1h2gM=
MIME-Version: 1.0
Received: by 10.68.120.72 with SMTP id la8mr22258157pbb.56.1327324866106; Mon,
	23 Jan 2012 05:21:06 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Mon, 23 Jan 2012 05:21:06 -0800 (PST)
In-Reply-To: <1327324482.24561.121.camel@zakaz.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@mail.gmail.com>
	<1327324482.24561.121.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 14:21:06 +0100
X-Google-Sender-Auth: h_gjggGOeQW-LO-xIy8BfBpuzn4
Message-ID: <CAPLaKK5iTFknGbf0BbNwya9pNUkf+Cnu8hpZ4osSrKv1BBt_AQ@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 \(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 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

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMS0yMyBhdCAxMTo1OSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IE1vbiwgMjAxMi0wMS0yMyBhdCAxMTozMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToK
Pj4gPj4gMjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+
PiA+PiA+IE9uIFR1ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3Jv
dGU6Cj4+ID4+ID4+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENI
IHYyXSBsaWJ4bDogYWRkIHN1cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+ID4+ID4+ID4gT24gVGh1
LCAyMDExLTEyLTIyIGF0IDE2OjQxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiA+
PiA+PiA+ID4gU29tZSBhdXRvZ29vIHN0dWZmIHdpbGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRo
ZSB0b29scyBidWlsZC4gQ2FuIHlvdQo+PiA+PiA+PiA+ID4gc2V0IHVwIHRoZSBiYXNpYyBzdHJ1
Y3R1cmUgSWFuPwo+PiA+PiA+PiA+Cj4+ID4+ID4+ID4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRp
bWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+PiA+PiA+PiA+Cj4+ID4+ID4+ID4gV291bGQgaXQgYmUg
c3VmZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0b29scy9jaGVjayBjcmVhdGUgYQo+PiA+
PiA+PiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNrcz8gTWlnaHQgbmVlZCBh
IGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+PiA+PiA+PiA+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBp
cyBhbHdheXMgcnVuPwo+PiA+PiA+Pgo+PiA+PiA+PiBGb3Igbm93LCBJIHRoaW5rIHdlIHNob3Vs
ZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhlIGNyaXRpY2FsIHBhdGggZm9yCj4+ID4+ID4+IFhl
biA0LjIuIMKgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxkIHN3aXRjaCB0byBhdXRvY29uZiBJIHRo
aW5rLiDCoChJCj4+ID4+ID4+IGRvbid0IGFwcHJvdmUgb2YgYXV0b21ha2UuKQo+PiA+PiA+Cj4+
ID4+ID4gSXQgc2VlbXMgdGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24gdGhlIGF1
dG9jb25mIHN0dWZmLiBDYW4gd2UKPj4gPj4gPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0
IHdlIGNhbiBzdXBwb3J0IHlhamwgMi4wIGluIFhlbiA0LjIgYW5kCj4+ID4+ID4gc3dpdGNoIHRv
IGF1dG9jb25mIGFmdGVyd2FyZHMgb3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRj
aCB0bwo+PiA+PiA+IGF1dG9jb25mIGZvciA0LjI/Cj4+ID4+Cj4+ID4+IFRoZSBwcm9wb3NlZCBh
dXRvY29uZiBwYXRjaCBpcyBqdXN0IGEgY29udmVuaWVudCByZXBsYWNlbWVudCBmb3IKPj4gPj4g
dG9vbHMvY2hlY2sgc2NyaXB0cywgd2hpY2ggYWxsb3dzIHVzIHRvIGdlbmVyYXRlIGEgbWFrZWZp
bGUgYW5kIGEKPj4gPj4gaGVhZGVyIHdlIGNhbiBpbmNsdWRlIHRvIGtub3cgdGhlIHN5c3RlbSBj
YXBhYmlsaXRpZXMsIG5vdGhpbmcgbW9yZQo+PiA+PiB3YXMgYWRkZWQuCj4+ID4+Cj4+ID4+ID4g
SSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBhYm91dCBjcml0aWNhbCBwYXRoIGZvciA0LjIuIEkg
cHJlc3VtZQo+PiA+PiA+IGF1dG9jb25mIHdvdWxkIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgY2hl
Y2tpbmcgaW4gdGhlIHBhdGNoZXMsCj4+ID4+ID4gc3BlY2lmaWNhbGx5IEknbSB0aGlua2luZyBv
ZiB0aGUgYXV0b21hdGVkIHRlc3Qgc3lzdGVtIHVwZGF0ZSBhbmQgZG9jcy4KPj4gPj4KPj4gPj4g
RG9uJ3Qga25vdyBob3cgZGlmZmljdWx0IGl0IGlzIHRvIHVwZGF0ZSB0aGUgdGVzdCBiZWQgdG8g
dXNlIHRoZSBuZXcKPj4gPj4gY29uZmlndXJlIHNjcmlwdCwgaWRlYWxseSBpdCBzaG91bGQgb25s
eSByZXF1aXJlIGFkZGluZyAiLi9jb25maWd1cmUiCj4+ID4+IGJlZm9yZSBwZXJmb3JtaW5nIGEg
Im1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cgaG93IHRoZSB0ZXN0IGJlZAo+PiA+PiB3
b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mgc29tZSBvcHRpb25zIHRvIGNvbmZp
Z3VyZQo+PiA+PiBleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1lIHJlc3VsdC4KPj4gPgo+PiA+
IElhbiBKIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHRoYXQgb25lLiBIb3BlZnVsbHkganVzdCBydW5u
aW5nIC4vY29uZmlndXJlCj4+ID4gd2lsbCBnZXQgdXMgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8g
dGhlIGV4aXN0aW5nIHNldHVwLgo+PiA+Cj4+ID4gRldJVyB0aGUgdGVzdGVyIGNvZGUgaXMgYXZh
aWxhYmxlIGF0IGEgZ2l0IHVybCB3aGljaCBpcyBpbiBldmVyeSBwb3N0ZWQKPj4gPiBzZXQgb2Yg
cmVzdWx0cy4gUHJvYmFibHkgbG9va2luZyBmb3IgYW55d2hlcmUgdGhhdCB3cml0ZXMgdG8gLmNv
bmZpZwo+PiA+IHdvdWxkIGJlIGEgZ29vZCBzdGFydCBmb3IgZGVjaWRpbmcgaG93IGZhciBmcm9t
IHRoZSBkZWZhdWx0cyBpdCBkZXZpYXRlcwo+PiA+IChub3QgZmFyLCBJIGV4cGVjdCkuCj4+ID4K
Pj4gPj4gPiBPbiB0aGUgb3RoZXIgaGFuZCBSb2dlciBwb3N0ZWQgdjMgb2YgaGlzIGF1dG9jb25m
IHN1cHBvcnQgcGF0Y2ggYW5kCj4+ID4+ID4gYWx0aG91Z2ggSSBoYXZlbid0IGdvdCByb3VuZCB0
byByZXZpZXdpbmcgaXQgeWV0IChzb3JyeSkgdjIncyByZXZpZXcgd2FzCj4+ID4+ID4gZ2VuZXJh
bGx5IHBvc2l0aXZlL21pbm9yIGxvb2tpbmcuCj4+ID4+Cj4+ID4+IHYzIGlzIGJhc2ljYWxseSBh
IHYyIHdpdGggYWxsIHRoZSBtZW50aW9uZWQgZml4ZXMgYW5kIHRoZSBvdXRwdXQgZnJvbQo+PiA+
PiBhdXRvY29uZiAmIGF1dG9tYWtlLCBzbyB3ZSBjYW4gdXNlIHRoZSBjb25maWd1cmUgc2NyaXB0
IHN0cmFpZ2h0IGF3YXkuCj4+ID4KPj4gPiBhdXRvbWFrZT8gSSB0aG91Z2h0IHdlIGFncmVlZCBu
b3QgdG8gdXNlIHRoYXQ/Cj4+Cj4+IEF1dG90b29scyBpbiBnZW5lcmFsIGlzIHF1aXRlIGEgbWVz
cywgd2UgZG9uJ3QgdXNlIGF1dG9tYWtlLCBidXQgd2UKPj4gbmVlZCBpdCB0byBnZW5lcmF0ZSBj
b25maWcuc3ViIGFuZCBjb25maWcuZ3Vlc3MgKHllcywgSSBrbm93IEkgY2FuCj4+IGFsc28gY29w
eSB0aGVtKS4gVGhhdCdzIGFsbCB3ZSBuZWVkIGF1dG9tYWtlIGZvciAoZG9uJ3Qga25vdyB3aHkK
Pj4gYXV0b2NvbmYgY2FuJ3QgZG8gdGhpcyBhdXRvbWF0aWNhbGx5Li4uKQo+Cj4gQXMgSWFuSiAo
SSB0aGluaykgc2FpZCB3ZSBzaG91bGQganVzdCBjb3B5IGFuZCBjb21taXQgdGhlbS4KClRoYXQn
cyB3aGF0IGF1dG9tYWtlIGRvZXMsIGl0IGp1c3QgY29waWVzIHRoZW0gaW50byB0aGUgY3VycmVu
dApmb2xkZXIsIGFueXdheSBmb3JnZXQgYWJvdXQgdGhlIGF1dG9tYWtlIHN0dWZmLCBJIGp1c3Qg
dXNlZCBpdCB0byBjb3B5CmNvbmZpZy5zdWIgYW5kIGNvbmZpZy5ndWVzcyBiZWNhdXNlIEkgZGlk
bid0IGtub3cgZXhhY3RseSB3aGVyZSB0aGV5CndoZXJlIChJIGd1ZXNzIC91c3Ivc2hhcmUuLi4p
IGFuZCBJIGRpZG4ndCB3YW50IHRvIHdhc3RlIHRpbWUKc2VhcmNoaW5nIGZvciB0aGVtLgoKPj4g
Pj4gQW55d2F5LCB0aGlzIHBhdGNoIGZvciBhZGRpbmcgc3VwcG9ydCBvZiB5YWpsIDIuMCBuZWVk
cyBzb21lIHJld29yaywKPj4gPj4gYWNjb3JkaW5nIHRvIHRoZSBjb21tZW50cyBtYWRlIGJ5IElh
biBKYWNrc29uLCB3aGljaCBJIHdpbGwgdHJ5IHRvIGRvCj4+ID4+IGJlZm9yZSB0aGUgZW5kIG9m
IHRoZSB3ZWVrIChzb3JyeSBmb3IgdGhlIGRlbGF5LCBidXQgSSdtIHF1aXRlIGJ1c3kKPj4gPj4g
dGhpcyBkYXlzKS4KPj4gPgo+PiA+IFN1cmUsIG5vIHByb2JsZW0uIEkgaGF2ZSBwdXQgeWFqbDIg
c3VwcG9ydCBpbiB0aGUgIm5pY2UgdG8gaGF2ZSBjb2x1bW4iCj4+ID4gYW5kIGF1dG9jb25mIGlu
IGEgbmV3ICJuZWVkIHRvIGRlY2lkZSBpZiB0aGlzIGlzIDQuMiBvciA0LjMgbWF0ZXJpYWwiCj4+
ID4gY29sdW1uLgo+Pgo+PiBUaGFua3MsIEknbSBzdXJlIHlhamwgMi4wIHN1cHBvcnQgd2lsbCBn
ZXQgaW50byA0LjIgOikKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:21:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJpk-000119-L7; Mon, 23 Jan 2012 13:21: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 1RpJpi-0000zX-N7
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:21:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327324866!10283779!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20838 invoked from network); 23 Jan 2012 13:21:08 -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;
	23 Jan 2012 13:21:08 -0000
Received: by pbdx13 with SMTP id x13so2800034pbd.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 05:21: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=sV2pLl+0jUjl9NqSY82kDrMJcZZgguEBpIRLIyBtWto=;
	b=gQk+B4xVCEuRu7MdfWopezA1CDzDF2HK/8m/pLIzNj9vT+b1HUBPaZJEvBegOUo6lc
	KQq6jDNDlotIUi5zrwPoXqsZvf6zG4xg1LM9FLUCTVutIo5N5MlLcX7PpgL7IT/1wtHD
	qp8w+c3+tmM518ttpQuJdbYa4xtorjdz1h2gM=
MIME-Version: 1.0
Received: by 10.68.120.72 with SMTP id la8mr22258157pbb.56.1327324866106; Mon,
	23 Jan 2012 05:21:06 -0800 (PST)
Received: by 10.142.139.4 with HTTP; Mon, 23 Jan 2012 05:21:06 -0800 (PST)
In-Reply-To: <1327324482.24561.121.camel@zakaz.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@mail.gmail.com>
	<1327324482.24561.121.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 14:21:06 +0100
X-Google-Sender-Auth: h_gjggGOeQW-LO-xIy8BfBpuzn4
Message-ID: <CAPLaKK5iTFknGbf0BbNwya9pNUkf+Cnu8hpZ4osSrKv1BBt_AQ@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 \(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 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

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMS0yMyBhdCAxMTo1OSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IE1vbiwgMjAxMi0wMS0yMyBhdCAxMTozMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToK
Pj4gPj4gMjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+
PiA+PiA+IE9uIFR1ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3Jv
dGU6Cj4+ID4+ID4+IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENI
IHYyXSBsaWJ4bDogYWRkIHN1cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+ID4+ID4+ID4gT24gVGh1
LCAyMDExLTEyLTIyIGF0IDE2OjQxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiA+
PiA+PiA+ID4gU29tZSBhdXRvZ29vIHN0dWZmIHdpbGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRo
ZSB0b29scyBidWlsZC4gQ2FuIHlvdQo+PiA+PiA+PiA+ID4gc2V0IHVwIHRoZSBiYXNpYyBzdHJ1
Y3R1cmUgSWFuPwo+PiA+PiA+PiA+Cj4+ID4+ID4+ID4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRp
bWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+PiA+PiA+PiA+Cj4+ID4+ID4+ID4gV291bGQgaXQgYmUg
c3VmZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0b29scy9jaGVjayBjcmVhdGUgYQo+PiA+
PiA+PiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhlIGNoZWNrcz8gTWlnaHQgbmVlZCBh
IGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+PiA+PiA+PiA+IHRvIGJlIHN1cmUgdGhhdCBjaGVjayBp
cyBhbHdheXMgcnVuPwo+PiA+PiA+Pgo+PiA+PiA+PiBGb3Igbm93LCBJIHRoaW5rIHdlIHNob3Vs
ZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhlIGNyaXRpY2FsIHBhdGggZm9yCj4+ID4+ID4+IFhl
biA0LjIuIMKgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxkIHN3aXRjaCB0byBhdXRvY29uZiBJIHRo
aW5rLiDCoChJCj4+ID4+ID4+IGRvbid0IGFwcHJvdmUgb2YgYXV0b21ha2UuKQo+PiA+PiA+Cj4+
ID4+ID4gSXQgc2VlbXMgdGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24gdGhlIGF1
dG9jb25mIHN0dWZmLiBDYW4gd2UKPj4gPj4gPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0
IHdlIGNhbiBzdXBwb3J0IHlhamwgMi4wIGluIFhlbiA0LjIgYW5kCj4+ID4+ID4gc3dpdGNoIHRv
IGF1dG9jb25mIGFmdGVyd2FyZHMgb3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRj
aCB0bwo+PiA+PiA+IGF1dG9jb25mIGZvciA0LjI/Cj4+ID4+Cj4+ID4+IFRoZSBwcm9wb3NlZCBh
dXRvY29uZiBwYXRjaCBpcyBqdXN0IGEgY29udmVuaWVudCByZXBsYWNlbWVudCBmb3IKPj4gPj4g
dG9vbHMvY2hlY2sgc2NyaXB0cywgd2hpY2ggYWxsb3dzIHVzIHRvIGdlbmVyYXRlIGEgbWFrZWZp
bGUgYW5kIGEKPj4gPj4gaGVhZGVyIHdlIGNhbiBpbmNsdWRlIHRvIGtub3cgdGhlIHN5c3RlbSBj
YXBhYmlsaXRpZXMsIG5vdGhpbmcgbW9yZQo+PiA+PiB3YXMgYWRkZWQuCj4+ID4+Cj4+ID4+ID4g
SSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBhYm91dCBjcml0aWNhbCBwYXRoIGZvciA0LjIuIEkg
cHJlc3VtZQo+PiA+PiA+IGF1dG9jb25mIHdvdWxkIHJlcXVpcmUgbW9yZSB0aGFuIGp1c3QgY2hl
Y2tpbmcgaW4gdGhlIHBhdGNoZXMsCj4+ID4+ID4gc3BlY2lmaWNhbGx5IEknbSB0aGlua2luZyBv
ZiB0aGUgYXV0b21hdGVkIHRlc3Qgc3lzdGVtIHVwZGF0ZSBhbmQgZG9jcy4KPj4gPj4KPj4gPj4g
RG9uJ3Qga25vdyBob3cgZGlmZmljdWx0IGl0IGlzIHRvIHVwZGF0ZSB0aGUgdGVzdCBiZWQgdG8g
dXNlIHRoZSBuZXcKPj4gPj4gY29uZmlndXJlIHNjcmlwdCwgaWRlYWxseSBpdCBzaG91bGQgb25s
eSByZXF1aXJlIGFkZGluZyAiLi9jb25maWd1cmUiCj4+ID4+IGJlZm9yZSBwZXJmb3JtaW5nIGEg
Im1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cgaG93IHRoZSB0ZXN0IGJlZAo+PiA+PiB3
b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mgc29tZSBvcHRpb25zIHRvIGNvbmZp
Z3VyZQo+PiA+PiBleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1lIHJlc3VsdC4KPj4gPgo+PiA+
IElhbiBKIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHRoYXQgb25lLiBIb3BlZnVsbHkganVzdCBydW5u
aW5nIC4vY29uZmlndXJlCj4+ID4gd2lsbCBnZXQgdXMgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8g
dGhlIGV4aXN0aW5nIHNldHVwLgo+PiA+Cj4+ID4gRldJVyB0aGUgdGVzdGVyIGNvZGUgaXMgYXZh
aWxhYmxlIGF0IGEgZ2l0IHVybCB3aGljaCBpcyBpbiBldmVyeSBwb3N0ZWQKPj4gPiBzZXQgb2Yg
cmVzdWx0cy4gUHJvYmFibHkgbG9va2luZyBmb3IgYW55d2hlcmUgdGhhdCB3cml0ZXMgdG8gLmNv
bmZpZwo+PiA+IHdvdWxkIGJlIGEgZ29vZCBzdGFydCBmb3IgZGVjaWRpbmcgaG93IGZhciBmcm9t
IHRoZSBkZWZhdWx0cyBpdCBkZXZpYXRlcwo+PiA+IChub3QgZmFyLCBJIGV4cGVjdCkuCj4+ID4K
Pj4gPj4gPiBPbiB0aGUgb3RoZXIgaGFuZCBSb2dlciBwb3N0ZWQgdjMgb2YgaGlzIGF1dG9jb25m
IHN1cHBvcnQgcGF0Y2ggYW5kCj4+ID4+ID4gYWx0aG91Z2ggSSBoYXZlbid0IGdvdCByb3VuZCB0
byByZXZpZXdpbmcgaXQgeWV0IChzb3JyeSkgdjIncyByZXZpZXcgd2FzCj4+ID4+ID4gZ2VuZXJh
bGx5IHBvc2l0aXZlL21pbm9yIGxvb2tpbmcuCj4+ID4+Cj4+ID4+IHYzIGlzIGJhc2ljYWxseSBh
IHYyIHdpdGggYWxsIHRoZSBtZW50aW9uZWQgZml4ZXMgYW5kIHRoZSBvdXRwdXQgZnJvbQo+PiA+
PiBhdXRvY29uZiAmIGF1dG9tYWtlLCBzbyB3ZSBjYW4gdXNlIHRoZSBjb25maWd1cmUgc2NyaXB0
IHN0cmFpZ2h0IGF3YXkuCj4+ID4KPj4gPiBhdXRvbWFrZT8gSSB0aG91Z2h0IHdlIGFncmVlZCBu
b3QgdG8gdXNlIHRoYXQ/Cj4+Cj4+IEF1dG90b29scyBpbiBnZW5lcmFsIGlzIHF1aXRlIGEgbWVz
cywgd2UgZG9uJ3QgdXNlIGF1dG9tYWtlLCBidXQgd2UKPj4gbmVlZCBpdCB0byBnZW5lcmF0ZSBj
b25maWcuc3ViIGFuZCBjb25maWcuZ3Vlc3MgKHllcywgSSBrbm93IEkgY2FuCj4+IGFsc28gY29w
eSB0aGVtKS4gVGhhdCdzIGFsbCB3ZSBuZWVkIGF1dG9tYWtlIGZvciAoZG9uJ3Qga25vdyB3aHkK
Pj4gYXV0b2NvbmYgY2FuJ3QgZG8gdGhpcyBhdXRvbWF0aWNhbGx5Li4uKQo+Cj4gQXMgSWFuSiAo
SSB0aGluaykgc2FpZCB3ZSBzaG91bGQganVzdCBjb3B5IGFuZCBjb21taXQgdGhlbS4KClRoYXQn
cyB3aGF0IGF1dG9tYWtlIGRvZXMsIGl0IGp1c3QgY29waWVzIHRoZW0gaW50byB0aGUgY3VycmVu
dApmb2xkZXIsIGFueXdheSBmb3JnZXQgYWJvdXQgdGhlIGF1dG9tYWtlIHN0dWZmLCBJIGp1c3Qg
dXNlZCBpdCB0byBjb3B5CmNvbmZpZy5zdWIgYW5kIGNvbmZpZy5ndWVzcyBiZWNhdXNlIEkgZGlk
bid0IGtub3cgZXhhY3RseSB3aGVyZSB0aGV5CndoZXJlIChJIGd1ZXNzIC91c3Ivc2hhcmUuLi4p
IGFuZCBJIGRpZG4ndCB3YW50IHRvIHdhc3RlIHRpbWUKc2VhcmNoaW5nIGZvciB0aGVtLgoKPj4g
Pj4gQW55d2F5LCB0aGlzIHBhdGNoIGZvciBhZGRpbmcgc3VwcG9ydCBvZiB5YWpsIDIuMCBuZWVk
cyBzb21lIHJld29yaywKPj4gPj4gYWNjb3JkaW5nIHRvIHRoZSBjb21tZW50cyBtYWRlIGJ5IElh
biBKYWNrc29uLCB3aGljaCBJIHdpbGwgdHJ5IHRvIGRvCj4+ID4+IGJlZm9yZSB0aGUgZW5kIG9m
IHRoZSB3ZWVrIChzb3JyeSBmb3IgdGhlIGRlbGF5LCBidXQgSSdtIHF1aXRlIGJ1c3kKPj4gPj4g
dGhpcyBkYXlzKS4KPj4gPgo+PiA+IFN1cmUsIG5vIHByb2JsZW0uIEkgaGF2ZSBwdXQgeWFqbDIg
c3VwcG9ydCBpbiB0aGUgIm5pY2UgdG8gaGF2ZSBjb2x1bW4iCj4+ID4gYW5kIGF1dG9jb25mIGlu
IGEgbmV3ICJuZWVkIHRvIGRlY2lkZSBpZiB0aGlzIGlzIDQuMiBvciA0LjMgbWF0ZXJpYWwiCj4+
ID4gY29sdW1uLgo+Pgo+PiBUaGFua3MsIEknbSBzdXJlIHlhamwgMi4wIHN1cHBvcnQgd2lsbCBn
ZXQgaW50byA0LjIgOikKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5j
b20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 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 1RpJuf-0001Ui-DX; Mon, 23 Jan 2012 13:26: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 1RpJud-0001UW-6m
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:26:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327325172!12030154!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 21064 invoked from network); 23 Jan 2012 13:26:12 -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 Jan 2012 13:26:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 13:26:12 +0000
Message-Id: <4F1D6E02020000780006E684@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 13:26: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="=__Part87A9D8E2.0__="
Cc: s.hauer@pengutronix.de
Subject: [Xen-devel] [PATCH] unlzo: fix input buffer free
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part87A9D8E2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

unlzo modifies the pointer to in_buf, so we have to free the original
buffer, not the modified pointer.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/unlzo.c
+++ b/xen/common/unlzo.c
@@ -254,7 +254,7 @@ STATIC int INIT unlzo(u8 *input, unsigne
 	ret =3D 0;
 exit_2:
 	if (!input)
-		free(in_buf);
+		free(in_buf_save);
 exit_1:
 	if (!output)
 		free(out_buf);




--=__Part87A9D8E2.0__=
Content-Type: text/plain; name="unlzo-free-input-buffer.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="unlzo-free-input-buffer.patch"

unlzo: fix input buffer free=0A=0Aunlzo modifies the pointer to in_buf, so =
we have to free the original=0Abuffer, not the modified pointer.=0A=0ASigne=
d-off-by: Sascha Hauer <s.hauer@pengutronix.de>=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/unlzo.c=0A+++ b/xen/commo=
n/unlzo.c=0A@@ -254,7 +254,7 @@ STATIC int INIT unlzo(u8 *input, unsigne=0A=
 	ret =3D 0;=0A exit_2:=0A 	if (!input)=0A-		free(in_buf=
);=0A+		free(in_buf_save);=0A exit_1:=0A 	if (!output)=0A 	=
	free(out_buf);=0A
--=__Part87A9D8E2.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

--=__Part87A9D8E2.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:26:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 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 1RpJuf-0001Ui-DX; Mon, 23 Jan 2012 13:26: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 1RpJud-0001UW-6m
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:26:19 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327325172!12030154!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 21064 invoked from network); 23 Jan 2012 13:26:12 -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 Jan 2012 13:26:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 13:26:12 +0000
Message-Id: <4F1D6E02020000780006E684@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 13:26: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="=__Part87A9D8E2.0__="
Cc: s.hauer@pengutronix.de
Subject: [Xen-devel] [PATCH] unlzo: fix input buffer free
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part87A9D8E2.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

unlzo modifies the pointer to in_buf, so we have to free the original
buffer, not the modified pointer.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/unlzo.c
+++ b/xen/common/unlzo.c
@@ -254,7 +254,7 @@ STATIC int INIT unlzo(u8 *input, unsigne
 	ret =3D 0;
 exit_2:
 	if (!input)
-		free(in_buf);
+		free(in_buf_save);
 exit_1:
 	if (!output)
 		free(out_buf);




--=__Part87A9D8E2.0__=
Content-Type: text/plain; name="unlzo-free-input-buffer.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="unlzo-free-input-buffer.patch"

unlzo: fix input buffer free=0A=0Aunlzo modifies the pointer to in_buf, so =
we have to free the original=0Abuffer, not the modified pointer.=0A=0ASigne=
d-off-by: Sascha Hauer <s.hauer@pengutronix.de>=0ASigned-off-by: Jan =
Beulich <jbeulich@suse.com>=0A=0A--- a/xen/common/unlzo.c=0A+++ b/xen/commo=
n/unlzo.c=0A@@ -254,7 +254,7 @@ STATIC int INIT unlzo(u8 *input, unsigne=0A=
 	ret =3D 0;=0A exit_2:=0A 	if (!input)=0A-		free(in_buf=
);=0A+		free(in_buf_save);=0A exit_1:=0A 	if (!output)=0A 	=
	free(out_buf);=0A
--=__Part87A9D8E2.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

--=__Part87A9D8E2.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:27:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJvQ-0001Xs-Ra; Mon, 23 Jan 2012 13:27:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RpJvP-0001XK-Cg
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:27:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327325220!12004470!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 4549 invoked from network); 23 Jan 2012 13:27:01 -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; 23 Jan 2012 13:27:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 13:27:00 +0000
Message-Id: <4F1D6E32020000780006E688@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 13:26: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="=__Part68463732.0__="
Cc: pebolle@tiscali.nl
Subject: [Xen-devel] [PATCH] decompressors: fix string typo 'bufer'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part68463732.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/bunzip2.c
+++ b/xen/common/bunzip2.c
@@ -680,7 +680,7 @@ STATIC int INIT bunzip2(unsigned char *b
 		outbuf =3D malloc(BZIP2_IOBUF_SIZE);
=20
 	if (!outbuf) {
-		error("Could not allocate output bufer");
+		error("Could not allocate output buffer");
 		return RETVAL_OUT_OF_MEMORY;
 	}
 	if (buf)
@@ -688,7 +688,7 @@ STATIC int INIT bunzip2(unsigned char *b
 	else
 		inbuf =3D malloc(BZIP2_IOBUF_SIZE);
 	if (!inbuf) {
-		error("Could not allocate input bufer");
+		error("Could not allocate input buffer");
 		i =3D RETVAL_OUT_OF_MEMORY;
 		goto exit_0;
 	}
--- a/xen/common/unlzma.c
+++ b/xen/common/unlzma.c
@@ -556,7 +556,7 @@ STATIC int INIT unlzma(unsigned char *bu
 	else
 		inbuf =3D malloc(LZMA_IOBUF_SIZE);
 	if (!inbuf) {
-		error("Could not allocate input bufer");
+		error("Could not allocate input buffer");
 		goto exit_0;
 	}
=20




--=__Part68463732.0__=
Content-Type: text/plain; name="decompress-typos.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="decompress-typos.patch"

decompressors: fix string typo 'bufer'=0A=0ASigned-off-by: Paul Bolle =
<pebolle@tiscali.nl>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/common/bunzip2.c=0A+++ b/xen/common/bunzip2.c=0A@@ -680,7 +680,7 =
@@ STATIC int INIT bunzip2(unsigned char *b=0A 		outbuf =3D =
malloc(BZIP2_IOBUF_SIZE);=0A =0A 	if (!outbuf) {=0A-		=
error("Could not allocate output bufer");=0A+		error("Could not =
allocate output buffer");=0A 		return RETVAL_OUT_OF_MEMORY;=0A 	=
}=0A 	if (buf)=0A@@ -688,7 +688,7 @@ STATIC int INIT bunzip2(unsigned =
char *b=0A 	else=0A 		inbuf =3D malloc(BZIP2_IOBUF_SIZE);=
=0A 	if (!inbuf) {=0A-		error("Could not allocate input =
bufer");=0A+		error("Could not allocate input buffer");=0A 		=
i =3D RETVAL_OUT_OF_MEMORY;=0A 		goto exit_0;=0A 	}=0A--- =
a/xen/common/unlzma.c=0A+++ b/xen/common/unlzma.c=0A@@ -556,7 +556,7 @@ =
STATIC int INIT unlzma(unsigned char *bu=0A 	else=0A 		=
inbuf =3D malloc(LZMA_IOBUF_SIZE);=0A 	if (!inbuf) {=0A-		=
error("Could not allocate input bufer");=0A+		error("Could not =
allocate input buffer");=0A 		goto exit_0;=0A 	}=0A =0A
--=__Part68463732.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

--=__Part68463732.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:27:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJvQ-0001Xs-Ra; Mon, 23 Jan 2012 13:27:08 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RpJvP-0001XK-Cg
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:27:07 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327325220!12004470!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 4549 invoked from network); 23 Jan 2012 13:27:01 -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; 23 Jan 2012 13:27:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 13:27:00 +0000
Message-Id: <4F1D6E32020000780006E688@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 13:26: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="=__Part68463732.0__="
Cc: pebolle@tiscali.nl
Subject: [Xen-devel] [PATCH] decompressors: fix string typo 'bufer'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__Part68463732.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/common/bunzip2.c
+++ b/xen/common/bunzip2.c
@@ -680,7 +680,7 @@ STATIC int INIT bunzip2(unsigned char *b
 		outbuf =3D malloc(BZIP2_IOBUF_SIZE);
=20
 	if (!outbuf) {
-		error("Could not allocate output bufer");
+		error("Could not allocate output buffer");
 		return RETVAL_OUT_OF_MEMORY;
 	}
 	if (buf)
@@ -688,7 +688,7 @@ STATIC int INIT bunzip2(unsigned char *b
 	else
 		inbuf =3D malloc(BZIP2_IOBUF_SIZE);
 	if (!inbuf) {
-		error("Could not allocate input bufer");
+		error("Could not allocate input buffer");
 		i =3D RETVAL_OUT_OF_MEMORY;
 		goto exit_0;
 	}
--- a/xen/common/unlzma.c
+++ b/xen/common/unlzma.c
@@ -556,7 +556,7 @@ STATIC int INIT unlzma(unsigned char *bu
 	else
 		inbuf =3D malloc(LZMA_IOBUF_SIZE);
 	if (!inbuf) {
-		error("Could not allocate input bufer");
+		error("Could not allocate input buffer");
 		goto exit_0;
 	}
=20




--=__Part68463732.0__=
Content-Type: text/plain; name="decompress-typos.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="decompress-typos.patch"

decompressors: fix string typo 'bufer'=0A=0ASigned-off-by: Paul Bolle =
<pebolle@tiscali.nl>=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A=
--- a/xen/common/bunzip2.c=0A+++ b/xen/common/bunzip2.c=0A@@ -680,7 +680,7 =
@@ STATIC int INIT bunzip2(unsigned char *b=0A 		outbuf =3D =
malloc(BZIP2_IOBUF_SIZE);=0A =0A 	if (!outbuf) {=0A-		=
error("Could not allocate output bufer");=0A+		error("Could not =
allocate output buffer");=0A 		return RETVAL_OUT_OF_MEMORY;=0A 	=
}=0A 	if (buf)=0A@@ -688,7 +688,7 @@ STATIC int INIT bunzip2(unsigned =
char *b=0A 	else=0A 		inbuf =3D malloc(BZIP2_IOBUF_SIZE);=
=0A 	if (!inbuf) {=0A-		error("Could not allocate input =
bufer");=0A+		error("Could not allocate input buffer");=0A 		=
i =3D RETVAL_OUT_OF_MEMORY;=0A 		goto exit_0;=0A 	}=0A--- =
a/xen/common/unlzma.c=0A+++ b/xen/common/unlzma.c=0A@@ -556,7 +556,7 @@ =
STATIC int INIT unlzma(unsigned char *bu=0A 	else=0A 		=
inbuf =3D malloc(LZMA_IOBUF_SIZE);=0A 	if (!inbuf) {=0A-		=
error("Could not allocate input bufer");=0A+		error("Could not =
allocate input buffer");=0A 		goto exit_0;=0A 	}=0A =0A
--=__Part68463732.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

--=__Part68463732.0__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:29:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJxn-0001kq-Kd; Mon, 23 Jan 2012 13:29:35 +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 1RpJxm-0001kN-G1
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:29:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327325368!4700174!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17631 invoked from network); 23 Jan 2012 13:29:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:29:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10216344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:29:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 13:29:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:29:28 +0000
In-Reply-To: <1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327325368.24561.130.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 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> This adds compile-time logic to disable certain frontends in mini-os:
>  - pcifront is disabled by default, enabled for ioemu
>  - blkfront, netfront, fbfront, and kbdfront are enabled by default
>  - xenbus is required for any frontend, and is enabled by default
> 
> If all frontends and xenbus are disabled, mini-os will run without
> needing to communicate with xenstore, making it suitable to run the
> xenstore daemon.

I should've read this properly first time, then it wouldn't have taken
me until 17/21 to figure it out.

I think would be worthwhile to refactor the xenstore driver "extra"
consoles from the single console provided via start info and to make the
former a configurable option in line with the other front end drivers.
That would, I think, tidy up the changes to xencons_ring. I think
free_consfront and init_consfront only apply to the extra console case
so the ifdefs you add within them would instead surround the whole
functions (or even consfront.o if you decide that works).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:29:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpJxn-0001kq-Kd; Mon, 23 Jan 2012 13:29:35 +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 1RpJxm-0001kN-G1
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:29:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327325368!4700174!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17631 invoked from network); 23 Jan 2012 13:29:28 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:29:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10216344"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:29:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 13:29:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:29:28 +0000
In-Reply-To: <1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327325368.24561.130.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 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> This adds compile-time logic to disable certain frontends in mini-os:
>  - pcifront is disabled by default, enabled for ioemu
>  - blkfront, netfront, fbfront, and kbdfront are enabled by default
>  - xenbus is required for any frontend, and is enabled by default
> 
> If all frontends and xenbus are disabled, mini-os will run without
> needing to communicate with xenstore, making it suitable to run the
> xenstore daemon.

I should've read this properly first time, then it wouldn't have taken
me until 17/21 to figure it out.

I think would be worthwhile to refactor the xenstore driver "extra"
consoles from the single console provided via start info and to make the
former a configurable option in line with the other front end drivers.
That would, I think, tidy up the changes to xencons_ring. I think
free_consfront and init_consfront only apply to the extra console case
so the ifdefs you add within them would instead surround the whole
functions (or even consfront.o if you decide that works).

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:38:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:38:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpK6c-0002Dg-Es; Mon, 23 Jan 2012 13:38:42 +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 1RpK6b-0002Cs-8w
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:38:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327325914!10324687!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31847 invoked from network); 23 Jan 2012 13:38:34 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:38:34 -0000
Received: by wgbdt11 with SMTP id dt11so2568758wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 05:38: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=zDyZVuSzNDsz5OkMdcgSq8wBDyc4zuvppqwNokjLu1c=;
	b=j9clPsBsehYbEm0jn5sNakYfb/4rzh3SzULZikmameGTWUJBYXFWnKtqaAWIu2Bv21
	gFUy62/a/HWSsVEKa9t3/Aqnw1vqrAxS1dsUxbsLUsU2l7T01NpCu7SGH5kzYvmxmu8o
	kSVI/6TvgBw3wR+SWUrUp/fzNjU1HdCHNuasA=
Received: by 10.180.8.103 with SMTP id q7mr13519726wia.1.1327325913024;
	Mon, 23 Jan 2012 05:38:33 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id u12sm12972578wiv.10.2012.01.23.05.38.31
	(version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 05:38:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Jan 2012 13:38:18 +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: <CB43134A.37F36%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] unlzo: fix input buffer free
Thread-Index: AczZ1EPCQMeG2HoyaUqohkN/2wMpDA==
In-Reply-To: <4F1D6E02020000780006E684@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: s.hauer@pengutronix.de
Subject: Re: [Xen-devel] [PATCH] unlzo: fix input buffer free
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:26, "Jan Beulich" <JBeulich@suse.com> wrote:

> unlzo modifies the pointer to in_buf, so we have to free the original
> buffer, not the modified pointer.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/unlzo.c
> +++ b/xen/common/unlzo.c
> @@ -254,7 +254,7 @@ STATIC int INIT unlzo(u8 *input, unsigne
> ret = 0;
>  exit_2:
> if (!input)
> -  free(in_buf);
> +  free(in_buf_save);
>  exit_1:
> if (!output)
> free(out_buf);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 23 13:38:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:38:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpK6c-0002Dg-Es; Mon, 23 Jan 2012 13:38:42 +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 1RpK6b-0002Cs-8w
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:38:41 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327325914!10324687!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31847 invoked from network); 23 Jan 2012 13:38:34 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:38:34 -0000
Received: by wgbdt11 with SMTP id dt11so2568758wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 05:38: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=zDyZVuSzNDsz5OkMdcgSq8wBDyc4zuvppqwNokjLu1c=;
	b=j9clPsBsehYbEm0jn5sNakYfb/4rzh3SzULZikmameGTWUJBYXFWnKtqaAWIu2Bv21
	gFUy62/a/HWSsVEKa9t3/Aqnw1vqrAxS1dsUxbsLUsU2l7T01NpCu7SGH5kzYvmxmu8o
	kSVI/6TvgBw3wR+SWUrUp/fzNjU1HdCHNuasA=
Received: by 10.180.8.103 with SMTP id q7mr13519726wia.1.1327325913024;
	Mon, 23 Jan 2012 05:38:33 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id u12sm12972578wiv.10.2012.01.23.05.38.31
	(version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 05:38:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Jan 2012 13:38:18 +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: <CB43134A.37F36%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] unlzo: fix input buffer free
Thread-Index: AczZ1EPCQMeG2HoyaUqohkN/2wMpDA==
In-Reply-To: <4F1D6E02020000780006E684@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: s.hauer@pengutronix.de
Subject: Re: [Xen-devel] [PATCH] unlzo: fix input buffer free
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:26, "Jan Beulich" <JBeulich@suse.com> wrote:

> unlzo modifies the pointer to in_buf, so we have to free the original
> buffer, not the modified pointer.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/unlzo.c
> +++ b/xen/common/unlzo.c
> @@ -254,7 +254,7 @@ STATIC int INIT unlzo(u8 *input, unsigne
> ret = 0;
>  exit_2:
> if (!input)
> -  free(in_buf);
> +  free(in_buf_save);
>  exit_1:
> if (!output)
> free(out_buf);
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 23 13:38:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpK6f-0002E9-2b; Mon, 23 Jan 2012 13:38:45 +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 1RpK6d-0002D5-CX
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:38:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327325914!10324687!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32239 invoked from network); 23 Jan 2012 13:38:37 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:38:37 -0000
Received: by mail-ww0-f43.google.com with SMTP id dt11so2568758wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 05:38:37 -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=P5A/paKwNNP0IUfLt9ToadOk6jSYTYp0hZL1ZuXGOX4=;
	b=IWk33aB7ZvcqUVF1aQTUxlKSRJHk4KgCiX6H98J4wOhUf3Glu4Jw37d/5iKVVBSw/I
	ECfPq801DG9aP7nG8vMcOfRbSGVOj8M2JQ4hUVAcDNdppICL592EEgDVNVZxikSBbtnz
	lWgi0DMtdbZDc0Z4EQkCjmP6x8COFT+JAoaBo=
Received: by 10.180.95.1 with SMTP id dg1mr5542756wib.21.1327325916962;
	Mon, 23 Jan 2012 05:38:36 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id u12sm12972578wiv.10.2012.01.23.05.38.34
	(version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 05:38:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Jan 2012 13:38:33 +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: <CB431359.37F37%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] decompressors: fix string typo 'bufer'
Thread-Index: AczZ1EyzAu3GraC7IkqMvgjrCtKqKw==
In-Reply-To: <4F1D6E32020000780006E688@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: pebolle@tiscali.nl
Subject: Re: [Xen-devel] [PATCH] decompressors: fix string typo 'bufer'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:26, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/bunzip2.c
> +++ b/xen/common/bunzip2.c
> @@ -680,7 +680,7 @@ STATIC int INIT bunzip2(unsigned char *b
> outbuf = malloc(BZIP2_IOBUF_SIZE);
>  
> if (!outbuf) {
> -  error("Could not allocate output bufer");
> +  error("Could not allocate output buffer");
> return RETVAL_OUT_OF_MEMORY;
> }
> if (buf)
> @@ -688,7 +688,7 @@ STATIC int INIT bunzip2(unsigned char *b
> else
> inbuf = malloc(BZIP2_IOBUF_SIZE);
> if (!inbuf) {
> -  error("Could not allocate input bufer");
> +  error("Could not allocate input buffer");
> i = RETVAL_OUT_OF_MEMORY;
> goto exit_0;
> }
> --- a/xen/common/unlzma.c
> +++ b/xen/common/unlzma.c
> @@ -556,7 +556,7 @@ STATIC int INIT unlzma(unsigned char *bu
> else
> inbuf = malloc(LZMA_IOBUF_SIZE);
> if (!inbuf) {
> -  error("Could not allocate input bufer");
> +  error("Could not allocate input buffer");
> goto exit_0;
> }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:38:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:38:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpK6f-0002E9-2b; Mon, 23 Jan 2012 13:38:45 +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 1RpK6d-0002D5-CX
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:38:43 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327325914!10324687!2
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32239 invoked from network); 23 Jan 2012 13:38:37 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:38:37 -0000
Received: by mail-ww0-f43.google.com with SMTP id dt11so2568758wgb.24
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 05:38:37 -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=P5A/paKwNNP0IUfLt9ToadOk6jSYTYp0hZL1ZuXGOX4=;
	b=IWk33aB7ZvcqUVF1aQTUxlKSRJHk4KgCiX6H98J4wOhUf3Glu4Jw37d/5iKVVBSw/I
	ECfPq801DG9aP7nG8vMcOfRbSGVOj8M2JQ4hUVAcDNdppICL592EEgDVNVZxikSBbtnz
	lWgi0DMtdbZDc0Z4EQkCjmP6x8COFT+JAoaBo=
Received: by 10.180.95.1 with SMTP id dg1mr5542756wib.21.1327325916962;
	Mon, 23 Jan 2012 05:38:36 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id u12sm12972578wiv.10.2012.01.23.05.38.34
	(version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 05:38:36 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Jan 2012 13:38:33 +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: <CB431359.37F37%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] decompressors: fix string typo 'bufer'
Thread-Index: AczZ1EyzAu3GraC7IkqMvgjrCtKqKw==
In-Reply-To: <4F1D6E32020000780006E688@nat28.tlf.novell.com>
Mime-version: 1.0
Cc: pebolle@tiscali.nl
Subject: Re: [Xen-devel] [PATCH] decompressors: fix string typo 'bufer'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:26, "Jan Beulich" <JBeulich@suse.com> wrote:

> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Keir Fraser <keir@xen.org>

> --- a/xen/common/bunzip2.c
> +++ b/xen/common/bunzip2.c
> @@ -680,7 +680,7 @@ STATIC int INIT bunzip2(unsigned char *b
> outbuf = malloc(BZIP2_IOBUF_SIZE);
>  
> if (!outbuf) {
> -  error("Could not allocate output bufer");
> +  error("Could not allocate output buffer");
> return RETVAL_OUT_OF_MEMORY;
> }
> if (buf)
> @@ -688,7 +688,7 @@ STATIC int INIT bunzip2(unsigned char *b
> else
> inbuf = malloc(BZIP2_IOBUF_SIZE);
> if (!inbuf) {
> -  error("Could not allocate input bufer");
> +  error("Could not allocate input buffer");
> i = RETVAL_OUT_OF_MEMORY;
> goto exit_0;
> }
> --- a/xen/common/unlzma.c
> +++ b/xen/common/unlzma.c
> @@ -556,7 +556,7 @@ STATIC int INIT unlzma(unsigned char *bu
> else
> inbuf = malloc(LZMA_IOBUF_SIZE);
> if (!inbuf) {
> -  error("Could not allocate input bufer");
> +  error("Could not allocate input buffer");
> goto exit_0;
> }
>  
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpKHs-0002vP-Ce; Mon, 23 Jan 2012 13:50:20 +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 1RpKHq-0002vC-QA
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:50:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327326566!51221787!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTc1OTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTc1OTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27398 invoked from network); 23 Jan 2012 13:49:26 -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; 23 Jan 2012 13:49:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327326612; l=1029;
	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=vm0KSvYYyW5KZ10tFQEv9rP/FVo=;
	b=t18wfUyHQ/bX9l8KEE2gUKM6EsFwSR+Iun1EkTaFxk+L7evErKUN6yx0FfvljC+PUSK
	qxvczhPFUK/FJFVgGI6atd5+UcSzcPC1L+6+rT23B1F+4KP/+tmrmbKRF8QtPOHNoI9gs
	WuWxckcpxOvxrqlLCubhIyRI7CYueG2MMaY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJhi0MFWU=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-078-026.pools.arcor-ip.net [88.65.78.26])
	by post.strato.de (mrclete mo28) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 300f68o0NCp98S
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 14:49:59 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 468E918634
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 14:50:01 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 88bddf1f0bafade6431651c5257bd02780596579
Message-Id: <88bddf1f0bafade64316.1327326599@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 23 Jan 2012 14:49:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327325262 -3600
# Node ID 88bddf1f0bafade6431651c5257bd02780596579
# Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
pv drivers: wrap xen_cpuid_base()

Allow compilation of PVonHVM drivers with forward-ported xenlinux
sources in openSuSE 12.1.  xen_cpuid_base() is now in mainline, the copy
in the xen tree leads to a compilation error.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 80fdf2182bc6 -r 88bddf1f0baf unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
@@ -118,6 +118,7 @@ unsigned long alloc_xen_mmio(unsigned lo
 
 #ifndef __ia64__
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
 static uint32_t xen_cpuid_base(void)
 {
 	uint32_t base, eax, ebx, ecx, edx;
@@ -136,6 +137,7 @@ static uint32_t xen_cpuid_base(void)
 
 	return 0;
 }
+#endif
 
 static int init_hypercall_stubs(void)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:50:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:50:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpKHs-0002vP-Ce; Mon, 23 Jan 2012 13:50:20 +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 1RpKHq-0002vC-QA
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:50:19 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327326566!51221787!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTc1OTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTc1OTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27398 invoked from network); 23 Jan 2012 13:49:26 -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; 23 Jan 2012 13:49:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327326612; l=1029;
	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=vm0KSvYYyW5KZ10tFQEv9rP/FVo=;
	b=t18wfUyHQ/bX9l8KEE2gUKM6EsFwSR+Iun1EkTaFxk+L7evErKUN6yx0FfvljC+PUSK
	qxvczhPFUK/FJFVgGI6atd5+UcSzcPC1L+6+rT23B1F+4KP/+tmrmbKRF8QtPOHNoI9gs
	WuWxckcpxOvxrqlLCubhIyRI7CYueG2MMaY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJhi0MFWU=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-078-026.pools.arcor-ip.net [88.65.78.26])
	by post.strato.de (mrclete mo28) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 300f68o0NCp98S
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 14:49:59 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 468E918634
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 14:50:01 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 88bddf1f0bafade6431651c5257bd02780596579
Message-Id: <88bddf1f0bafade64316.1327326599@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 23 Jan 2012 14:49:59 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327325262 -3600
# Node ID 88bddf1f0bafade6431651c5257bd02780596579
# Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
pv drivers: wrap xen_cpuid_base()

Allow compilation of PVonHVM drivers with forward-ported xenlinux
sources in openSuSE 12.1.  xen_cpuid_base() is now in mainline, the copy
in the xen tree leads to a compilation error.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 80fdf2182bc6 -r 88bddf1f0baf unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
--- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
+++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
@@ -118,6 +118,7 @@ unsigned long alloc_xen_mmio(unsigned lo
 
 #ifndef __ia64__
 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
 static uint32_t xen_cpuid_base(void)
 {
 	uint32_t base, eax, ebx, ecx, edx;
@@ -136,6 +137,7 @@ static uint32_t xen_cpuid_base(void)
 
 	return 0;
 }
+#endif
 
 static int init_hypercall_stubs(void)
 {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:53:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpKKX-00031v-Uz; Mon, 23 Jan 2012 13:53: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 1RpKKW-00031k-N2
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:53:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327326732!51222330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5215 invoked from network); 23 Jan 2012 13:52:12 -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;
	23 Jan 2012 13:52:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10217372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:52: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, 23 Jan 2012 13:52:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:52:50 +0000
In-Reply-To: <1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327326770.24561.137.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 21/21] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> +int main(int argc, char** argv)
> +{
> +	xc_interface *xch;
> +	struct xs_handle *xsh;
> +	char buf[16];
> +	int rv;
> +
> +	if (argc != 4) {
> +		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
> +		return 2;
> +	}
> +
> +	xch = xc_interface_open(NULL, NULL, 0);
> +	if (!xch) return 1;
> +
> +	rv = build(xch, argv);
> +
> +	xc_interface_close(xch);
> +
> +	if (rv) return 1;

Did you consider forking a daemon at this point to sit and drain the
domains console ring into a log file? (instead of/as well as your patch
08/21).

The following bit would remain in the existing process so there would be
no risk of deadlock AFAICT.

> +
> +	xsh = xs_open(0);
> +	rv = snprintf(buf, 16, "%d", domid);
> +	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
> +	xs_daemon_close(xsh);
> +
> +	return 0;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:53:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpKKX-00031v-Uz; Mon, 23 Jan 2012 13:53: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 1RpKKW-00031k-N2
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:53:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327326732!51222330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5215 invoked from network); 23 Jan 2012 13:52:12 -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;
	23 Jan 2012 13:52:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10217372"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:52: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, 23 Jan 2012 13:52:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 13:52:50 +0000
In-Reply-To: <1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327326770.24561.137.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 21/21] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> +int main(int argc, char** argv)
> +{
> +	xc_interface *xch;
> +	struct xs_handle *xsh;
> +	char buf[16];
> +	int rv;
> +
> +	if (argc != 4) {
> +		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
> +		return 2;
> +	}
> +
> +	xch = xc_interface_open(NULL, NULL, 0);
> +	if (!xch) return 1;
> +
> +	rv = build(xch, argv);
> +
> +	xc_interface_close(xch);
> +
> +	if (rv) return 1;

Did you consider forking a daemon at this point to sit and drain the
domains console ring into a log file? (instead of/as well as your patch
08/21).

The following bit would remain in the existing process so there would be
no risk of deadlock AFAICT.

> +
> +	xsh = xs_open(0);
> +	rv = snprintf(buf, 16, "%d", domid);
> +	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
> +	xs_daemon_close(xsh);
> +
> +	return 0;
> +}



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:57:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpKOP-0003Dd-MI; Mon, 23 Jan 2012 13:57:05 +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 1RpKOO-0003DO-5c
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:57:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327327018!8245050!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9783 invoked from network); 23 Jan 2012 13:56:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10217500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:56:58 +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;
	Mon, 23 Jan 2012 13:56:58 +0000
Message-ID: <1327326980.3921.12.camel@liuw-workstation>
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 13:56:20 +0000
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>, wei.liu2@citrix.com,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH V2] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Fix issues commented by Jan - coding style, stubs and variable types.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/hvm/hvm.c           |    1 +
 xen/common/compat/grant_table.c  |    8 +++
 xen/common/grant_table.c         |   89 ++++++++++++++++++++++++++++++++++++++
 xen/include/public/grant_table.h |   18 +++++++-
 xen/include/xlat.lst             |    1 +
 5 files changed, 115 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b3d9ac0..c46bd3e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int cmd)
     case GNTTABOP_copy:
     case GNTTABOP_map_grant_ref:
     case GNTTABOP_unmap_grant_ref:
+    case GNTTABOP_swap_grant_ref:
         return 1;
     default:
         /* all other commands need auditing */
diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
index ca60395..edd20c6 100644
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -47,6 +47,10 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_status_frames_compat_t);
 CHECK_gnttab_get_version;
 #undef xen_gnttab_get_version
 
+#define xen_gnttab_swap_grant_ref gnttab_swap_grant_ref
+CHECK_gnttab_swap_grant_ref;
+#undef xen_gnttab_swap_grant_ref
+
 int compat_grant_table_op(unsigned int cmd,
                           XEN_GUEST_HANDLE(void) cmp_uop,
                           unsigned int count)
@@ -98,6 +102,10 @@ int compat_grant_table_op(unsigned int cmd,
     CASE(get_status_frames);
 #endif
 
+#ifndef CHECK_gnttab_swap_grant_ref
+    CASE(swap_grant_ref);
+#endif
+
 #undef CASE
     default:
         return do_grant_table_op(cmd, cmp_uop, count);
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 34a49db..2683324 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2282,6 +2282,81 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     return 0;
 }
 
+static s16
+__gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
+{
+    struct domain *d;
+    struct active_grant_entry *act;
+    s16 rc = GNTST_okay;
+
+    d = rcu_lock_current_domain();
+
+    spin_lock(&d->grant_table->lock);
+
+    act = &active_entry(d->grant_table, ref_a);
+    if ( act->pin )
+        PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
+
+    act = &active_entry(d->grant_table, ref_b);
+    if ( act->pin )
+        PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
+
+    if ( d->grant_table->gt_version == 1 )
+    {
+        grant_entry_v1_t shared;
+
+        shared = shared_entry_v1(d->grant_table, ref_a);
+
+        shared_entry_v1(d->grant_table, ref_a) =
+            shared_entry_v1(d->grant_table, ref_b);
+
+        shared_entry_v1(d->grant_table, ref_b) = shared;
+    }
+    else
+    {
+        grant_entry_v2_t shared;
+        grant_status_t status;
+
+        shared = shared_entry_v2(d->grant_table, ref_a);
+        status = status_entry(d->grant_table, ref_a);
+
+        shared_entry_v2(d->grant_table, ref_a) =
+            shared_entry_v2(d->grant_table, ref_b);
+        status_entry(d->grant_table, ref_a) =
+            status_entry(d->grant_table, ref_b);
+
+        shared_entry_v2(d->grant_table, ref_b) = shared;
+        status_entry(d->grant_table, ref_b) = status;
+    }
+
+out:
+    spin_unlock(&d->grant_table->lock);
+
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+static long
+gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
+                      unsigned int count)
+{
+    int i;
+    gnttab_swap_grant_ref_t op;
+
+    for ( i = 0; i < count; i++ )
+    {
+        if ( i && hypercall_preempt_check() )
+            return i;
+        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
+            return -EFAULT;
+        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
+        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
+            return -EFAULT;
+    }
+    return 0;
+}
+
 long
 do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
@@ -2400,6 +2475,20 @@ do_grant_table_op(
         rc = gnttab_get_version(guest_handle_cast(uop, gnttab_get_version_t));
         break;
     }
+    case GNTTABOP_swap_grant_ref:
+    {
+        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
+            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
+        if ( unlikely(!guest_handle_okay(swap, count)) )
+            goto out;
+        rc = gnttab_swap_grant_ref(swap, count);
+        if ( rc > 0 )
+        {
+            guest_handle_add_offset(swap, rc);
+            uop = guest_handle_cast(swap, void);
+        }
+        break;
+    }
     default:
         rc = -ENOSYS;
         break;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..54d9551 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -511,6 +511,20 @@ struct gnttab_get_version {
 typedef struct gnttab_get_version gnttab_get_version_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
 
+/* 
+ * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
+ */
+#define GNTTABOP_swap_grant_ref	      11
+struct gnttab_swap_grant_ref {
+    /* IN parameters */
+    grant_ref_t ref_a;
+    grant_ref_t ref_b;
+    /* OUT parameters */
+    int16_t status;             /* GNTST_* */
+};
+typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
+DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
+
 #endif /* __XEN_INTERFACE_VERSION__ */
 
 /*
@@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
 #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 GNTST_eagain          (-12) /* Operation not done; try again.        */
 
 #define GNTTABOP_error_msgs {                   \
     "okay",                                     \
@@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
     "bad page",                                 \
     "copy arguments cross page boundary",       \
     "page address size too large",              \
-    "could not map at the moment, retry"        \
+    "operation not done; try again"             \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..f602155 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -50,6 +50,7 @@
 ?	grant_entry_v1			grant_table.h
 ?       grant_entry_header              grant_table.h
 ?	grant_entry_v2			grant_table.h
+?	gnttab_swap_grant_ref		grant_table.h
 ?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
 !	kexec_range			kexec.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 Jan 23 13:57:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13: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 1RpKOP-0003Dd-MI; Mon, 23 Jan 2012 13:57:05 +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 1RpKOO-0003DO-5c
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:57:04 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327327018!8245050!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9783 invoked from network); 23 Jan 2012 13:56:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 13:56:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10217500"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13:56:58 +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;
	Mon, 23 Jan 2012 13:56:58 +0000
Message-ID: <1327326980.3921.12.camel@liuw-workstation>
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 13:56:20 +0000
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>, wei.liu2@citrix.com,
	Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH V2] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Fix issues commented by Jan - coding style, stubs and variable types.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/hvm/hvm.c           |    1 +
 xen/common/compat/grant_table.c  |    8 +++
 xen/common/grant_table.c         |   89 ++++++++++++++++++++++++++++++++++++++
 xen/include/public/grant_table.h |   18 +++++++-
 xen/include/xlat.lst             |    1 +
 5 files changed, 115 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b3d9ac0..c46bd3e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int cmd)
     case GNTTABOP_copy:
     case GNTTABOP_map_grant_ref:
     case GNTTABOP_unmap_grant_ref:
+    case GNTTABOP_swap_grant_ref:
         return 1;
     default:
         /* all other commands need auditing */
diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
index ca60395..edd20c6 100644
--- a/xen/common/compat/grant_table.c
+++ b/xen/common/compat/grant_table.c
@@ -47,6 +47,10 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_status_frames_compat_t);
 CHECK_gnttab_get_version;
 #undef xen_gnttab_get_version
 
+#define xen_gnttab_swap_grant_ref gnttab_swap_grant_ref
+CHECK_gnttab_swap_grant_ref;
+#undef xen_gnttab_swap_grant_ref
+
 int compat_grant_table_op(unsigned int cmd,
                           XEN_GUEST_HANDLE(void) cmp_uop,
                           unsigned int count)
@@ -98,6 +102,10 @@ int compat_grant_table_op(unsigned int cmd,
     CASE(get_status_frames);
 #endif
 
+#ifndef CHECK_gnttab_swap_grant_ref
+    CASE(swap_grant_ref);
+#endif
+
 #undef CASE
     default:
         return do_grant_table_op(cmd, cmp_uop, count);
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 34a49db..2683324 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2282,6 +2282,81 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
     return 0;
 }
 
+static s16
+__gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
+{
+    struct domain *d;
+    struct active_grant_entry *act;
+    s16 rc = GNTST_okay;
+
+    d = rcu_lock_current_domain();
+
+    spin_lock(&d->grant_table->lock);
+
+    act = &active_entry(d->grant_table, ref_a);
+    if ( act->pin )
+        PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
+
+    act = &active_entry(d->grant_table, ref_b);
+    if ( act->pin )
+        PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
+
+    if ( d->grant_table->gt_version == 1 )
+    {
+        grant_entry_v1_t shared;
+
+        shared = shared_entry_v1(d->grant_table, ref_a);
+
+        shared_entry_v1(d->grant_table, ref_a) =
+            shared_entry_v1(d->grant_table, ref_b);
+
+        shared_entry_v1(d->grant_table, ref_b) = shared;
+    }
+    else
+    {
+        grant_entry_v2_t shared;
+        grant_status_t status;
+
+        shared = shared_entry_v2(d->grant_table, ref_a);
+        status = status_entry(d->grant_table, ref_a);
+
+        shared_entry_v2(d->grant_table, ref_a) =
+            shared_entry_v2(d->grant_table, ref_b);
+        status_entry(d->grant_table, ref_a) =
+            status_entry(d->grant_table, ref_b);
+
+        shared_entry_v2(d->grant_table, ref_b) = shared;
+        status_entry(d->grant_table, ref_b) = status;
+    }
+
+out:
+    spin_unlock(&d->grant_table->lock);
+
+    rcu_unlock_domain(d);
+
+    return rc;
+}
+
+static long
+gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
+                      unsigned int count)
+{
+    int i;
+    gnttab_swap_grant_ref_t op;
+
+    for ( i = 0; i < count; i++ )
+    {
+        if ( i && hypercall_preempt_check() )
+            return i;
+        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
+            return -EFAULT;
+        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
+        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
+            return -EFAULT;
+    }
+    return 0;
+}
+
 long
 do_grant_table_op(
     unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
@@ -2400,6 +2475,20 @@ do_grant_table_op(
         rc = gnttab_get_version(guest_handle_cast(uop, gnttab_get_version_t));
         break;
     }
+    case GNTTABOP_swap_grant_ref:
+    {
+        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
+            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
+        if ( unlikely(!guest_handle_okay(swap, count)) )
+            goto out;
+        rc = gnttab_swap_grant_ref(swap, count);
+        if ( rc > 0 )
+        {
+            guest_handle_add_offset(swap, rc);
+            uop = guest_handle_cast(swap, void);
+        }
+        break;
+    }
     default:
         rc = -ENOSYS;
         break;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 0bf20bc..54d9551 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -511,6 +511,20 @@ struct gnttab_get_version {
 typedef struct gnttab_get_version gnttab_get_version_t;
 DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
 
+/* 
+ * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
+ */
+#define GNTTABOP_swap_grant_ref	      11
+struct gnttab_swap_grant_ref {
+    /* IN parameters */
+    grant_ref_t ref_a;
+    grant_ref_t ref_b;
+    /* OUT parameters */
+    int16_t status;             /* GNTST_* */
+};
+typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
+DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
+
 #endif /* __XEN_INTERFACE_VERSION__ */
 
 /*
@@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
 #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 GNTST_eagain          (-12) /* Operation not done; try again.        */
 
 #define GNTTABOP_error_msgs {                   \
     "okay",                                     \
@@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
     "bad page",                                 \
     "copy arguments cross page boundary",       \
     "page address size too large",              \
-    "could not map at the moment, retry"        \
+    "operation not done; try again"             \
 }
 
 #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index 3d92175..f602155 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -50,6 +50,7 @@
 ?	grant_entry_v1			grant_table.h
 ?       grant_entry_header              grant_table.h
 ?	grant_entry_v2			grant_table.h
+?	gnttab_swap_grant_ref		grant_table.h
 ?	kexec_exec			kexec.h
 !	kexec_image			kexec.h
 !	kexec_range			kexec.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 Jan 23 13:59:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpKQz-0003Kj-8o; Mon, 23 Jan 2012 13:59:45 +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 1RpKQx-0003Kc-Sm
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:59:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327327177!12085016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27256 invoked from network); 23 Jan 2012 13:59:38 -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;
	23 Jan 2012 13:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10217664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13: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, 23 Jan 2012 13:59: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
	1RpKQr-0007wB-H3; Mon, 23 Jan 2012 13:59:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpKQr-0003dU-Dy;
	Mon, 23 Jan 2012 13:59:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20253.26569.194982.392106@mariner.uk.xensource.com>
Date: Mon, 23 Jan 2012 13:59:37 +0000
To: Wei Wang2 <wei.wang2@amd.com>
In-Reply-To: <201201111120.05565.wei.wang2@amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<20227.9862.11432.52937@mariner.uk.xensource.com>
	<20236.29029.997206.496297@mariner.uk.xensource.com>
	<201201111120.05565.wei.wang2@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest
 config file parameter [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

Wei Wang2 writes ("Re: [PATCH 15 of 16] libxl: Introduce a new guest config file parameter [and 1 more messages]"):
> How about guest_iommu = {1, 0} or ats_passthru = {1, 0}?

I think "guest_iommu" is more likely to be something people have heard
of.  Personally I'm afraid I have no idea what (an) "ATS" is ...

>  Actually the idea of> the whole patch queue is to enable passthru
> for sophisticated ats devices (e.g. Tahiti the latest AMD
> gfx/gpgpu), so that we utilize the device to do general-purpose
> computations in guest.

Right.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 13:59:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 13:59:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpKQz-0003Kj-8o; Mon, 23 Jan 2012 13:59:45 +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 1RpKQx-0003Kc-Sm
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 13:59:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327327177!12085016!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27256 invoked from network); 23 Jan 2012 13:59:38 -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;
	23 Jan 2012 13:59:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10217664"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 13: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, 23 Jan 2012 13:59: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
	1RpKQr-0007wB-H3; Mon, 23 Jan 2012 13:59:37 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpKQr-0003dU-Dy;
	Mon, 23 Jan 2012 13:59:37 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20253.26569.194982.392106@mariner.uk.xensource.com>
Date: Mon, 23 Jan 2012 13:59:37 +0000
To: Wei Wang2 <wei.wang2@amd.com>
In-Reply-To: <201201111120.05565.wei.wang2@amd.com>
References: <patchbomb.1326215226@gran.amd.com>
	<20227.9862.11432.52937@mariner.uk.xensource.com>
	<20236.29029.997206.496297@mariner.uk.xensource.com>
	<201201111120.05565.wei.wang2@amd.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 15 of 16] libxl: Introduce a new guest
 config file parameter [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

Wei Wang2 writes ("Re: [PATCH 15 of 16] libxl: Introduce a new guest config file parameter [and 1 more messages]"):
> How about guest_iommu = {1, 0} or ats_passthru = {1, 0}?

I think "guest_iommu" is more likely to be something people have heard
of.  Personally I'm afraid I have no idea what (an) "ATS" is ...

>  Actually the idea of> the whole patch queue is to enable passthru
> for sophisticated ats devices (e.g. Tahiti the latest AMD
> gfx/gpgpu), so that we utilize the device to do general-purpose
> computations in guest.

Right.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:03:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpKUf-0003bc-BK; Mon, 23 Jan 2012 14:03:33 +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 1RpKUd-0003bK-Sk
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:03:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327327405!12044249!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 30351 invoked from network); 23 Jan 2012 14:03:25 -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 Jan 2012 14:03:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 14:03:25 +0000
Message-Id: <4F1D7702020000780006E6C2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 14:04:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Marcus Granado" <Marcus.Granado@eu.citrix.com>,
	"Keir Fraser" <keir@xen.org>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
In-Reply-To: <4F1D48BA020000780006E55F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 11:47, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 23.01.12 at 11:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Mon, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
>>> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
>>> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
>>> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
>>> > @@ -68,7 +68,7 @@ struct event_log {
>>> >   };
>>> > 
>>> >   /* PC value that indicates a special code */
>>> > -#define XENOPROF_ESCAPE_CODE ~0UL
>>> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
>>> 
>>> You cannot just go and change a public definition, as the consuming
>>> side will break. You need to introduce a new escape code, and
>>> provide a mechanism to negotiate (between hypervisor and kernel)
>>> which one to use.
>> 
>> This seems more like a bug fix to me than an interface change, the fact
>> that both producer and consumer had the bug notwithstanding.
>> 
>> Since this is a developer oriented interface I think we can be a little
>> more relaxed than we would be for other interface changes. In this case
>> we are fixing 32on64 (quite common) at the expense of 32on32 (very
>> uncommon these days, especially for the suybset of developers wanting to
>> do profiling) and leaving 64on64 (quite common) as it is . That seems
>> like a worthwhile tradeoff to me.
> 
> I see your point. However, I'd still like to be careful with this - what
> we think things ought to be used for doesn't necessarily cover all
> cases that they are in reality.

I see that it got applied unchanged. It introduces two warnings in
the 32-bit build, which not only fails that build, but also indicates
that the situation likely wasn't fully analyzed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:03:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:03:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpKUf-0003bc-BK; Mon, 23 Jan 2012 14:03:33 +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 1RpKUd-0003bK-Sk
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:03:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327327405!12044249!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 30351 invoked from network); 23 Jan 2012 14:03:25 -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 Jan 2012 14:03:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 14:03:25 +0000
Message-Id: <4F1D7702020000780006E6C2@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 14:04:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>,
	"George Dunlap" <George.Dunlap@eu.citrix.com>,
	"Marcus Granado" <Marcus.Granado@eu.citrix.com>,
	"Keir Fraser" <keir@xen.org>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
In-Reply-To: <4F1D48BA020000780006E55F@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 11:47, "Jan Beulich" <JBeulich@suse.com> wrote:
>>>> On 23.01.12 at 11:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> On Mon, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
>>> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
>>> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
>>> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
>>> > @@ -68,7 +68,7 @@ struct event_log {
>>> >   };
>>> > 
>>> >   /* PC value that indicates a special code */
>>> > -#define XENOPROF_ESCAPE_CODE ~0UL
>>> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
>>> 
>>> You cannot just go and change a public definition, as the consuming
>>> side will break. You need to introduce a new escape code, and
>>> provide a mechanism to negotiate (between hypervisor and kernel)
>>> which one to use.
>> 
>> This seems more like a bug fix to me than an interface change, the fact
>> that both producer and consumer had the bug notwithstanding.
>> 
>> Since this is a developer oriented interface I think we can be a little
>> more relaxed than we would be for other interface changes. In this case
>> we are fixing 32on64 (quite common) at the expense of 32on32 (very
>> uncommon these days, especially for the suybset of developers wanting to
>> do profiling) and leaving 64on64 (quite common) as it is . That seems
>> like a worthwhile tradeoff to me.
> 
> I see your point. However, I'd still like to be careful with this - what
> we think things ought to be used for doesn't necessarily cover all
> cases that they are in reality.

I see that it got applied unchanged. It introduces two warnings in
the 32-bit build, which not only fails that build, but also indicates
that the situation likely wasn't fully analyzed.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:09:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpKaT-0003m4-5Z; Mon, 23 Jan 2012 14:09:33 +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 1RpKaS-0003lx-61
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:09:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327327764!10320335!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28259 invoked from network); 23 Jan 2012 14:09:25 -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; 23 Jan 2012 14:09:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 14:09:24 +0000
Message-Id: <4F1D786A020000780006E6D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 14:10:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
In-Reply-To: <88bddf1f0bafade64316.1327326599@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.01.12 at 14:49, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327325262 -3600
> # Node ID 88bddf1f0bafade6431651c5257bd02780596579
> # Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
> pv drivers: wrap xen_cpuid_base()
> 
> Allow compilation of PVonHVM drivers with forward-ported xenlinux
> sources in openSuSE 12.1.  xen_cpuid_base() is now in mainline, the copy
> in the xen tree leads to a compilation error.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 80fdf2182bc6 -r 88bddf1f0baf 
> unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
> --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
> +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
> @@ -118,6 +118,7 @@ unsigned long alloc_xen_mmio(unsigned lo
>  
>  #ifndef __ia64__
>  
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)

Given that the PV drivers must be building fine for SLE11 SP2, which
is 3.0-based, I wonder if this really is the correct fix (and doesn't
rather break the build). The first thing coming to mind is that
arch/x86/include/asm/xen/hypervisor.h shouldn't get included here
(and hence there shouldn't be any conflict). Are you perhaps trying
to build the PV drivers against a pv-ops-enabled configuration (which
is a wrong to try afaict)?

Jan

>  static uint32_t xen_cpuid_base(void)
>  {
>  	uint32_t base, eax, ebx, ecx, edx;
> @@ -136,6 +137,7 @@ static uint32_t xen_cpuid_base(void)
>  
>  	return 0;
>  }
> +#endif
>  
>  static int init_hypercall_stubs(void)
>  {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:09:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpKaT-0003m4-5Z; Mon, 23 Jan 2012 14:09:33 +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 1RpKaS-0003lx-61
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:09:32 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327327764!10320335!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28259 invoked from network); 23 Jan 2012 14:09:25 -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; 23 Jan 2012 14:09:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 14:09:24 +0000
Message-Id: <4F1D786A020000780006E6D1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 14:10:34 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
In-Reply-To: <88bddf1f0bafade64316.1327326599@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.01.12 at 14:49, Olaf Hering <olaf@aepfle.de> wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327325262 -3600
> # Node ID 88bddf1f0bafade6431651c5257bd02780596579
> # Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
> pv drivers: wrap xen_cpuid_base()
> 
> Allow compilation of PVonHVM drivers with forward-ported xenlinux
> sources in openSuSE 12.1.  xen_cpuid_base() is now in mainline, the copy
> in the xen tree leads to a compilation error.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 80fdf2182bc6 -r 88bddf1f0baf 
> unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
> --- a/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
> +++ b/unmodified_drivers/linux-2.6/platform-pci/platform-pci.c
> @@ -118,6 +118,7 @@ unsigned long alloc_xen_mmio(unsigned lo
>  
>  #ifndef __ia64__
>  
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)

Given that the PV drivers must be building fine for SLE11 SP2, which
is 3.0-based, I wonder if this really is the correct fix (and doesn't
rather break the build). The first thing coming to mind is that
arch/x86/include/asm/xen/hypervisor.h shouldn't get included here
(and hence there shouldn't be any conflict). Are you perhaps trying
to build the PV drivers against a pv-ops-enabled configuration (which
is a wrong to try afaict)?

Jan

>  static uint32_t xen_cpuid_base(void)
>  {
>  	uint32_t base, eax, ebx, ecx, edx;
> @@ -136,6 +137,7 @@ static uint32_t xen_cpuid_base(void)
>  
>  	return 0;
>  }
> +#endif
>  
>  static int init_hypercall_stubs(void)
>  {
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:23:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpKnQ-0003zh-JN; Mon, 23 Jan 2012 14:22: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 1RpKnP-0003zc-9J
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:22:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327328565!3400127!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTc1OTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTc1OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8274 invoked from network); 23 Jan 2012 14:22:49 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Jan 2012 14:22:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327328565; l=755;
	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=59bP1BphBVW7MslCA69FhDMSvfs=;
	b=dvMSdC+yWuyW+6KdRUzbTlVtcVZ2FAd7c7rRvn0i6H8q+CmiH/+1FykgMjfVDfy7+EC
	Uyyf7mOfZq35MIgBb8rTyPv8SMKfBkn/qFaioVC5WPL8V3ogjwQyd0W93tHC81NTVlpyT
	OVjPoMpgA9THQtZWHhYaBPdGLFh9O/Olh2E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJhi0MFWU=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-078-026.pools.arcor-ip.net [88.65.78.26])
	by post.strato.de (mrclete mo62) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v023eco0NCXa6T ;
	Mon, 23 Jan 2012 15:22:30 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A2B9918637; Mon, 23 Jan 2012 15:22:32 +0100 (CET)
Date: Mon, 23 Jan 2012 15:22:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120123142232.GA8983@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
	<4F1D786A020000780006E6D1@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1D786A020000780006E6D1@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, Jan Beulich wrote:

> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
> 
> Given that the PV drivers must be building fine for SLE11 SP2, which
> is 3.0-based, I wonder if this really is the correct fix (and doesn't
> rather break the build). The first thing coming to mind is that
> arch/x86/include/asm/xen/hypervisor.h shouldn't get included here
> (and hence there shouldn't be any conflict). Are you perhaps trying
> to build the PV drivers against a pv-ops-enabled configuration (which
> is a wrong to try afaict)?

Its an ordinary kernel-source tree.

git describe d9b8ca8474fd4fdd43ba6d97a4fee8b49b978067
v2.6.37-rc5-2-gd9b8ca8

The function appears in 2.6.38, so I think the version number is correct.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:23:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:23:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpKnQ-0003zh-JN; Mon, 23 Jan 2012 14:22: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 1RpKnP-0003zc-9J
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:22:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327328565!3400127!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTc1OTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMTc1OTI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8274 invoked from network); 23 Jan 2012 14:22:49 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 23 Jan 2012 14:22:49 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327328565; l=755;
	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=59bP1BphBVW7MslCA69FhDMSvfs=;
	b=dvMSdC+yWuyW+6KdRUzbTlVtcVZ2FAd7c7rRvn0i6H8q+CmiH/+1FykgMjfVDfy7+EC
	Uyyf7mOfZq35MIgBb8rTyPv8SMKfBkn/qFaioVC5WPL8V3ogjwQyd0W93tHC81NTVlpyT
	OVjPoMpgA9THQtZWHhYaBPdGLFh9O/Olh2E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFJhi0MFWU=
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-078-026.pools.arcor-ip.net [88.65.78.26])
	by post.strato.de (mrclete mo62) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id v023eco0NCXa6T ;
	Mon, 23 Jan 2012 15:22:30 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id A2B9918637; Mon, 23 Jan 2012 15:22:32 +0100 (CET)
Date: Mon, 23 Jan 2012 15:22:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120123142232.GA8983@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
	<4F1D786A020000780006E6D1@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1D786A020000780006E6D1@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, Jan Beulich wrote:

> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
> 
> Given that the PV drivers must be building fine for SLE11 SP2, which
> is 3.0-based, I wonder if this really is the correct fix (and doesn't
> rather break the build). The first thing coming to mind is that
> arch/x86/include/asm/xen/hypervisor.h shouldn't get included here
> (and hence there shouldn't be any conflict). Are you perhaps trying
> to build the PV drivers against a pv-ops-enabled configuration (which
> is a wrong to try afaict)?

Its an ordinary kernel-source tree.

git describe d9b8ca8474fd4fdd43ba6d97a4fee8b49b978067
v2.6.37-rc5-2-gd9b8ca8

The function appears in 2.6.38, so I think the version number is correct.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:26:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpKqW-00045i-6W; Mon, 23 Jan 2012 14:26: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 1RpKqU-00045X-UD
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:26:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327328761!12178857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21943 invoked from network); 23 Jan 2012 14:26:01 -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;
	23 Jan 2012 14:26:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10219111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 14:26: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, 23 Jan 2012 14:26:01 +0000
Date: Mon, 23 Jan 2012 14:26:18 +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: <1327326770.24561.137.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201231400320.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
	<1327326770.24561.137.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 21/21] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 23 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> > +int main(int argc, char** argv)
> > +{
> > +	xc_interface *xch;
> > +	struct xs_handle *xsh;
> > +	char buf[16];
> > +	int rv;
> > +
> > +	if (argc != 4) {
> > +		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
> > +		return 2;
> > +	}
> > +
> > +	xch = xc_interface_open(NULL, NULL, 0);
> > +	if (!xch) return 1;
> > +
> > +	rv = build(xch, argv);
> > +
> > +	xc_interface_close(xch);
> > +
> > +	if (rv) return 1;
> 
> Did you consider forking a daemon at this point to sit and drain the
> domains console ring into a log file? (instead of/as well as your patch
> 08/21).

I don't know if there are any benefits in basing this stub domain builder
on libxl but if it was based on libxl you could just add a pv console
device with consback = LIBXL_CONSOLE_BACKEND_IOEMU and then set output =
"file:/path/to/file", and you would have your logging going to that
file.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:26:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpKqW-00045i-6W; Mon, 23 Jan 2012 14:26: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 1RpKqU-00045X-UD
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:26:07 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327328761!12178857!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21943 invoked from network); 23 Jan 2012 14:26:01 -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;
	23 Jan 2012 14:26:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10219111"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 14:26: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, 23 Jan 2012 14:26:01 +0000
Date: Mon, 23 Jan 2012 14:26:18 +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: <1327326770.24561.137.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201231400320.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
	<1327326770.24561.137.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 21/21] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 23 Jan 2012, Ian Campbell wrote:
> On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> > +int main(int argc, char** argv)
> > +{
> > +	xc_interface *xch;
> > +	struct xs_handle *xsh;
> > +	char buf[16];
> > +	int rv;
> > +
> > +	if (argc != 4) {
> > +		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
> > +		return 2;
> > +	}
> > +
> > +	xch = xc_interface_open(NULL, NULL, 0);
> > +	if (!xch) return 1;
> > +
> > +	rv = build(xch, argv);
> > +
> > +	xc_interface_close(xch);
> > +
> > +	if (rv) return 1;
> 
> Did you consider forking a daemon at this point to sit and drain the
> domains console ring into a log file? (instead of/as well as your patch
> 08/21).

I don't know if there are any benefits in basing this stub domain builder
on libxl but if it was based on libxl you could just add a pv console
device with consback = LIBXL_CONSOLE_BACKEND_IOEMU and then set output =
"file:/path/to/file", and you would have your logging going to that
file.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:32:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 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 1RpKwI-0004QA-18; Mon, 23 Jan 2012 14:32:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpKwH-0004Q5-G5
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:32:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327329119!10333452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25486 invoked from network); 23 Jan 2012 14:31:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:31:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10219537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 14:31:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 14:31:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 23 Jan 2012 14:31:58 +0000
In-Reply-To: <alpine.DEB.2.00.1201231400320.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
	<1327326770.24561.137.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201231400320.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327329119.24561.143.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 21/21] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 14:26 +0000, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> > > +int main(int argc, char** argv)
> > > +{
> > > +	xc_interface *xch;
> > > +	struct xs_handle *xsh;
> > > +	char buf[16];
> > > +	int rv;
> > > +
> > > +	if (argc != 4) {
> > > +		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
> > > +		return 2;
> > > +	}
> > > +
> > > +	xch = xc_interface_open(NULL, NULL, 0);
> > > +	if (!xch) return 1;
> > > +
> > > +	rv = build(xch, argv);
> > > +
> > > +	xc_interface_close(xch);
> > > +
> > > +	if (rv) return 1;
> > 
> > Did you consider forking a daemon at this point to sit and drain the
> > domains console ring into a log file? (instead of/as well as your patch
> > 08/21).
> 
> I don't know if there are any benefits in basing this stub domain builder
> on libxl but if it was based on libxl you could just add a pv console
> device with consback = LIBXL_CONSOLE_BACKEND_IOEMU and then set output =
> "file:/path/to/file", and you would have your logging going to that
> file.

This builder cannot use xenstore and therefore cannot use xenconsoled
(which would block waiting for xenstored) either.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:32:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 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 1RpKwI-0004QA-18; Mon, 23 Jan 2012 14:32:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpKwH-0004Q5-G5
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:32:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327329119!10333452!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25486 invoked from network); 23 Jan 2012 14:31:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:31:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10219537"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 14:31:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 14:31:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Mon, 23 Jan 2012 14:31:58 +0000
In-Reply-To: <alpine.DEB.2.00.1201231400320.3196@kaball-desktop>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-22-git-send-email-dgdegra@tycho.nsa.gov>
	<1327326770.24561.137.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201231400320.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327329119.24561.143.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 21/21] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 14:26 +0000, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> > > +int main(int argc, char** argv)
> > > +{
> > > +	xc_interface *xch;
> > > +	struct xs_handle *xsh;
> > > +	char buf[16];
> > > +	int rv;
> > > +
> > > +	if (argc != 4) {
> > > +		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
> > > +		return 2;
> > > +	}
> > > +
> > > +	xch = xc_interface_open(NULL, NULL, 0);
> > > +	if (!xch) return 1;
> > > +
> > > +	rv = build(xch, argv);
> > > +
> > > +	xc_interface_close(xch);
> > > +
> > > +	if (rv) return 1;
> > 
> > Did you consider forking a daemon at this point to sit and drain the
> > domains console ring into a log file? (instead of/as well as your patch
> > 08/21).
> 
> I don't know if there are any benefits in basing this stub domain builder
> on libxl but if it was based on libxl you could just add a pv console
> device with consback = LIBXL_CONSOLE_BACKEND_IOEMU and then set output =
> "file:/path/to/file", and you would have your logging going to that
> file.

This builder cannot use xenstore and therefore cannot use xenconsoled
(which would block waiting for xenstored) either.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:43:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpL7A-0004cU-86; Mon, 23 Jan 2012 14:43:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpL79-0004c9-16
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:43:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327329791!9699925!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27169 invoked from network); 23 Jan 2012 14:43:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:43:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21174809"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 09:43:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 09:43: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
	q0NEh823031760;	Mon, 23 Jan 2012 06:43:09 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327329788@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 14:43:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, juergen.gross@ts.fujitsu.com
Subject: [Xen-devel] [PATCH 0 of 3] libxl: tweak the cpupool interface
	slightly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Just a few changes I noticed while playing with cpupools on Friday.

There is no need for both poolid and poolname in the libxl API. Remove
poolname.

Use libxl_cpupool_create not libxl_create_cpupool for consistency with
other functions.

Do not write "pool_name" to xenstore. I couldn't find any reader of
this node but I left it till last so it can easily be dropped if
necessary.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:43:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpL7A-0004cU-86; Mon, 23 Jan 2012 14:43:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpL79-0004c9-16
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:43:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327329791!9699925!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27169 invoked from network); 23 Jan 2012 14:43:12 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:43:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21174809"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 09:43:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 09:43: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
	q0NEh823031760;	Mon, 23 Jan 2012 06:43:09 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327329788@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 14:43:08 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, juergen.gross@ts.fujitsu.com
Subject: [Xen-devel] [PATCH 0 of 3] libxl: tweak the cpupool interface
	slightly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Just a few changes I noticed while playing with cpupools on Friday.

There is no need for both poolid and poolname in the libxl API. Remove
poolname.

Use libxl_cpupool_create not libxl_create_cpupool for consistency with
other functions.

Do not write "pool_name" to xenstore. I couldn't find any reader of
this node but I left it till last so it can easily be dropped if
necessary.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:43:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpL7B-0004cj-LS; Mon, 23 Jan 2012 14:43: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 1RpL79-0004cA-JR
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:43:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327329792!12092385!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3428 invoked from network); 23 Jan 2012 14:43:13 -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;
	23 Jan 2012 14:43:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178669597"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 09:43:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 09:43: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
	q0NEh824031760;	Mon, 23 Jan 2012 06:43:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: c91bee33280debdfe602d28e48318c03ddf0f4c9
Message-ID: <c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327329788@cosworth.uk.xensource.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 14:43:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, juergen.gross@ts.fujitsu.com
Subject: [Xen-devel] [PATCH 1 of 3] libxl: remove
	libxl_domain_create_info.poolname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327329346 0
# Node ID c91bee33280debdfe602d28e48318c03ddf0f4c9
# Parent  4bb2b6a04ec02c3502c1825e2736df54870229e5
libxl: remove libxl_domain_create_info.poolname

It is redundant with poolid and allowing the user to specify both
opens up the possibility of a disconnect.

Also default c_info->poolid to -1 (no pool) instead of defaulting to 0 in the
library and overriding in the toolstack.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 20 17:12:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 14:35:46 2012 +0000
@@ -60,7 +60,7 @@ int libxl_init_create_info(libxl_ctx *ct
     c_info->type = LIBXL_DOMAIN_TYPE_HVM;
     c_info->oos = 1;
     c_info->ssidref = 0;
-    c_info->poolid = 0;
+    c_info->poolid = -1;
     return 0;
 }
 
@@ -438,8 +438,9 @@ retry_transaction:
 
     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));
-    if (info->poolname)
-        xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/pool_name", vm_path), info->poolname, strlen(info->poolname));
+    if (info->poolid != -1)
+        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
+                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
 
     libxl__xs_writev(gc, t, dom_path, info->xsdata);
     libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 20 17:12:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 14:35:46 2012 +0000
@@ -156,7 +156,6 @@ libxl_domain_create_info = Struct("domai
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
-    ("poolname",     string),
     ])
 
 libxl_domain_build_info = Struct("domain_build_info",[
diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 20 17:12:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:46 2012 +0000
@@ -315,7 +315,7 @@ static void printf_info(int domid,
         printf("\t(uuid <unknown>)\n");
     }
 
-    printf("\t(cpupool %s)\n", c_info->poolname);
+    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
     if (c_info->xsdata)
         printf("\t(xsdata contains data)\n");
     else
@@ -640,11 +640,9 @@ static void parse_config_data(const char
         c_info->oos = l;
 
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
-        c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
-    c_info->poolname = libxl_cpupoolid_to_name(ctx, c_info->poolid);
-    if (!c_info->poolname) {
+    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
         fprintf(stderr, "Illegal pool specified\n");
         exit(1);
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:43:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpL7B-0004cj-LS; Mon, 23 Jan 2012 14:43: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 1RpL79-0004cA-JR
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:43:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327329792!12092385!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3428 invoked from network); 23 Jan 2012 14:43:13 -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;
	23 Jan 2012 14:43:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178669597"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 09:43:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 09:43: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
	q0NEh824031760;	Mon, 23 Jan 2012 06:43:10 -0800
MIME-Version: 1.0
X-Mercurial-Node: c91bee33280debdfe602d28e48318c03ddf0f4c9
Message-ID: <c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327329788@cosworth.uk.xensource.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 14:43:09 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, juergen.gross@ts.fujitsu.com
Subject: [Xen-devel] [PATCH 1 of 3] libxl: remove
	libxl_domain_create_info.poolname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327329346 0
# Node ID c91bee33280debdfe602d28e48318c03ddf0f4c9
# Parent  4bb2b6a04ec02c3502c1825e2736df54870229e5
libxl: remove libxl_domain_create_info.poolname

It is redundant with poolid and allowing the user to specify both
opens up the possibility of a disconnect.

Also default c_info->poolid to -1 (no pool) instead of defaulting to 0 in the
library and overriding in the toolstack.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Fri Jan 20 17:12:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 14:35:46 2012 +0000
@@ -60,7 +60,7 @@ int libxl_init_create_info(libxl_ctx *ct
     c_info->type = LIBXL_DOMAIN_TYPE_HVM;
     c_info->oos = 1;
     c_info->ssidref = 0;
-    c_info->poolid = 0;
+    c_info->poolid = -1;
     return 0;
 }
 
@@ -438,8 +438,9 @@ retry_transaction:
 
     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));
-    if (info->poolname)
-        xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/pool_name", vm_path), info->poolname, strlen(info->poolname));
+    if (info->poolid != -1)
+        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
+                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
 
     libxl__xs_writev(gc, t, dom_path, info->xsdata);
     libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Fri Jan 20 17:12:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 14:35:46 2012 +0000
@@ -156,7 +156,6 @@ libxl_domain_create_info = Struct("domai
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
-    ("poolname",     string),
     ])
 
 libxl_domain_build_info = Struct("domain_build_info",[
diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Fri Jan 20 17:12:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:46 2012 +0000
@@ -315,7 +315,7 @@ static void printf_info(int domid,
         printf("\t(uuid <unknown>)\n");
     }
 
-    printf("\t(cpupool %s)\n", c_info->poolname);
+    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
     if (c_info->xsdata)
         printf("\t(xsdata contains data)\n");
     else
@@ -640,11 +640,9 @@ static void parse_config_data(const char
         c_info->oos = l;
 
     if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
-        c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
-    c_info->poolname = libxl_cpupoolid_to_name(ctx, c_info->poolid);
-    if (!c_info->poolname) {
+    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
         fprintf(stderr, "Illegal pool specified\n");
         exit(1);
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:43:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:43:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpL7C-0004cq-1R; Mon, 23 Jan 2012 14:43: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 1RpL7A-0004cB-2h
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:43:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327329791!9699925!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27229 invoked from network); 23 Jan 2012 14:43:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:43:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21174811"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 09:43:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 09:43: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
	q0NEh825031760;	Mon, 23 Jan 2012 06:43:11 -0800
MIME-Version: 1.0
X-Mercurial-Node: 10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
Message-ID: <10f5656caaaa2bdfd6a7.1327329790@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327329788@cosworth.uk.xensource.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 14:43:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, juergen.gross@ts.fujitsu.com
Subject: [Xen-devel] [PATCH 2 of 3] libxl: name libxl_create_cpupool
 consistent with other functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327329347 0
# Node ID 10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
# Parent  c91bee33280debdfe602d28e48318c03ddf0f4c9
libxl: name libxl_create_cpupool consistent with other functions.

The pattern for the other cpupool functions is libxl_cpupool_<ACTION>
and in general we use libxl_<THING>_<ACTION>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c91bee33280d -r 10f5656caaaa tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 14:35:46 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:35:47 2012 +0000
@@ -3172,7 +3172,7 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
diff -r c91bee33280d -r 10f5656caaaa tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 14:35:46 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Jan 23 14:35:47 2012 +0000
@@ -605,7 +605,7 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
 int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid);
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
diff -r c91bee33280d -r 10f5656caaaa tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:46 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:47 2012 +0000
@@ -5332,7 +5332,7 @@ int main_cpupoolcreate(int argc, char **
         return 0;
 
     poolid = 0;
-    if (libxl_create_cpupool(ctx, name, schedid, cpumap, &uuid, &poolid)) {
+    if (libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid)) {
         fprintf(stderr, "error on creating cpupool\n");
         return -ERROR_FAIL;
     }
@@ -5706,7 +5706,7 @@ int main_cpupoolnumasplit(int argc, char
         snprintf(name, 15, "Pool-node%d", node);
         libxl_uuid_generate(&uuid);
         poolid = 0;
-        ret = -libxl_create_cpupool(ctx, name, schedid, cpumap, &uuid, &poolid);
+        ret = -libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid);
         if (ret) {
             fprintf(stderr, "error on creating cpupool\n");
             goto out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:43:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:43:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpL7C-0004cq-1R; Mon, 23 Jan 2012 14:43: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 1RpL7A-0004cB-2h
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:43:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327329791!9699925!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27229 invoked from network); 23 Jan 2012 14:43:13 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:43:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21174811"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 09:43:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 09:43: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
	q0NEh825031760;	Mon, 23 Jan 2012 06:43:11 -0800
MIME-Version: 1.0
X-Mercurial-Node: 10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
Message-ID: <10f5656caaaa2bdfd6a7.1327329790@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327329788@cosworth.uk.xensource.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 14:43:10 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, juergen.gross@ts.fujitsu.com
Subject: [Xen-devel] [PATCH 2 of 3] libxl: name libxl_create_cpupool
 consistent with other functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327329347 0
# Node ID 10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
# Parent  c91bee33280debdfe602d28e48318c03ddf0f4c9
libxl: name libxl_create_cpupool consistent with other functions.

The pattern for the other cpupool functions is libxl_cpupool_<ACTION>
and in general we use libxl_<THING>_<ACTION>

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c91bee33280d -r 10f5656caaaa tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 14:35:46 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:35:47 2012 +0000
@@ -3172,7 +3172,7 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid)
 {
diff -r c91bee33280d -r 10f5656caaaa tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 14:35:46 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Jan 23 14:35:47 2012 +0000
@@ -605,7 +605,7 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
 int libxl_tmem_freeable(libxl_ctx *ctx);
 
 int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
-int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
+int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
                          libxl_cpumap cpumap, libxl_uuid *uuid,
                          uint32_t *poolid);
 int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
diff -r c91bee33280d -r 10f5656caaaa tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:46 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:47 2012 +0000
@@ -5332,7 +5332,7 @@ int main_cpupoolcreate(int argc, char **
         return 0;
 
     poolid = 0;
-    if (libxl_create_cpupool(ctx, name, schedid, cpumap, &uuid, &poolid)) {
+    if (libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid)) {
         fprintf(stderr, "error on creating cpupool\n");
         return -ERROR_FAIL;
     }
@@ -5706,7 +5706,7 @@ int main_cpupoolnumasplit(int argc, char
         snprintf(name, 15, "Pool-node%d", node);
         libxl_uuid_generate(&uuid);
         poolid = 0;
-        ret = -libxl_create_cpupool(ctx, name, schedid, cpumap, &uuid, &poolid);
+        ret = -libxl_cpupool_create(ctx, name, schedid, cpumap, &uuid, &poolid);
         if (ret) {
             fprintf(stderr, "error on creating cpupool\n");
             goto out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:43:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:43:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpL7C-0004dC-KF; Mon, 23 Jan 2012 14:43: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 1RpL7B-0004cC-9U
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:43:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327329791!9699925!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27322 invoked from network); 23 Jan 2012 14:43:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:43:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21174812"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 09:43:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 09:43:13 -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
	q0NEh826031760;	Mon, 23 Jan 2012 06:43:12 -0800
MIME-Version: 1.0
X-Mercurial-Node: d8efdb16b1ef06013061da1f47c2dbce4b042992
Message-ID: <d8efdb16b1ef06013061.1327329791@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327329788@cosworth.uk.xensource.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 14:43:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, juergen.gross@ts.fujitsu.com
Subject: [Xen-devel] [PATCH 3 of 3] libxl: do not write/maintain "pool_name"
	in XenStore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327329565 0
# Node ID d8efdb16b1ef06013061da1f47c2dbce4b042992
# Parent  10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
libxl: do not write/maintain "pool_name" in XenStore

Nothing that I can find ever reads this key.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 10f5656caaaa -r d8efdb16b1ef tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 14:35:47 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:39:25 2012 +0000
@@ -3434,16 +3434,6 @@ int libxl_cpupool_movedomain(libxl_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);
-    if (!dom_path) {
-        GC_FREE;
-        return ERROR_FAIL;
-    }
 
     rc = xc_cpupool_movedomain(ctx->xch, poolid, domid);
     if (rc) {
@@ -3453,21 +3443,6 @@ int libxl_cpupool_movedomain(libxl_ctx *
         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));
-        if (!vm_path)
-            break;
-
-        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;
-    }
-
     GC_FREE;
     return 0;
 }
diff -r 10f5656caaaa -r d8efdb16b1ef tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 14:35:47 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 14:39:25 2012 +0000
@@ -438,9 +438,6 @@ retry_transaction:
 
     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));
-    if (info->poolid != -1)
-        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
-                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
 
     libxl__xs_writev(gc, t, dom_path, info->xsdata);
     libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:43:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:43:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpL7C-0004dC-KF; Mon, 23 Jan 2012 14:43: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 1RpL7B-0004cC-9U
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:43:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327329791!9699925!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27322 invoked from network); 23 Jan 2012 14:43:14 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:43:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21174812"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 09:43:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 09:43:13 -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
	q0NEh826031760;	Mon, 23 Jan 2012 06:43:12 -0800
MIME-Version: 1.0
X-Mercurial-Node: d8efdb16b1ef06013061da1f47c2dbce4b042992
Message-ID: <d8efdb16b1ef06013061.1327329791@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327329788@cosworth.uk.xensource.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 14:43:11 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, juergen.gross@ts.fujitsu.com
Subject: [Xen-devel] [PATCH 3 of 3] libxl: do not write/maintain "pool_name"
	in XenStore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327329565 0
# Node ID d8efdb16b1ef06013061da1f47c2dbce4b042992
# Parent  10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
libxl: do not write/maintain "pool_name" in XenStore

Nothing that I can find ever reads this key.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 10f5656caaaa -r d8efdb16b1ef tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 14:35:47 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:39:25 2012 +0000
@@ -3434,16 +3434,6 @@ int libxl_cpupool_movedomain(libxl_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);
-    if (!dom_path) {
-        GC_FREE;
-        return ERROR_FAIL;
-    }
 
     rc = xc_cpupool_movedomain(ctx->xch, poolid, domid);
     if (rc) {
@@ -3453,21 +3443,6 @@ int libxl_cpupool_movedomain(libxl_ctx *
         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));
-        if (!vm_path)
-            break;
-
-        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;
-    }
-
     GC_FREE;
     return 0;
 }
diff -r 10f5656caaaa -r d8efdb16b1ef tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 14:35:47 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 14:39:25 2012 +0000
@@ -438,9 +438,6 @@ retry_transaction:
 
     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));
-    if (info->poolid != -1)
-        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
-                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
 
     libxl__xs_writev(gc, t, dom_path, info->xsdata);
     libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:46:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpL9s-00053A-9l; Mon, 23 Jan 2012 14:46: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 1RpL9q-00052t-80
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:46:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327329959!12188245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17285 invoked from network); 23 Jan 2012 14:45:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:45:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10219951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 14:45:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 14:45:59 +0000
Date: Mon, 23 Jan 2012 14:46:16 +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: <4F1D4E43.7000501@siemens.com>
Message-ID: <alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Jan Kiszka wrote:
> On 2012-01-23 12:59, Stefano Stabellini wrote:
> > On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >>>> Or what is the ordering
> >>>> of init, RAM restore, and initial device reset now?
> >>>
> >>> RAM restore (done by Xen)
> >>>
> >>> physmap rebuild (done by xen_hvm_init in qemu)
> >>> pc_init()
> >>> qemu_system_reset()
> >>> load_vmstate()
> >>
> >> Hmm, are you sure that this is the only case where a device init or
> >> reset handler writes to already restored guest memory? Preloading the
> >> RAM this way is a non-standard scenario for QEMU, thus conceptually
> >> fragile. Does restoring happen before QEMU is even started, or can this
> >> point be controlled from QEMU?
> > 
> > Consider that this only happens with non-MMIO device memory, in practice
> > only videoram.
> > Vmware VGA does not memset the videoram in the reset handler, while QXL
> > already has the following:
> > 
> >     /* pre loadvm reset must not touch QXLRam.  This lives in
> >      * device memory, is migrated together with RAM and thus
> >      * already loaded at this point */
> >     if (!loadvm) {
> >         qxl_reset_state(d);
> >     }
> 
> Yes, but QEMU restores the RAM _after_ device reset, not before it.
> That's the problem with the Xen way - it is against the current QEMU
> standard.

QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.

To reply to your previous question more clearly: at restore time Qemu on
Xen would run in a non-standard scenario; the restore of the RAM happens
before QEMU is even started.

That is unfortunate but it would be very hard to change (I can give you
more details if you are interested in the reasons why it would be so
difficult).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:46:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:46:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpL9s-00053A-9l; Mon, 23 Jan 2012 14:46: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 1RpL9q-00052t-80
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:46:06 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327329959!12188245!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17285 invoked from network); 23 Jan 2012 14:45:59 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:45:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10219951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 14:45:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 14:45:59 +0000
Date: Mon, 23 Jan 2012 14:46:16 +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: <4F1D4E43.7000501@siemens.com>
Message-ID: <alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Jan Kiszka wrote:
> On 2012-01-23 12:59, Stefano Stabellini wrote:
> > On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >>>> Or what is the ordering
> >>>> of init, RAM restore, and initial device reset now?
> >>>
> >>> RAM restore (done by Xen)
> >>>
> >>> physmap rebuild (done by xen_hvm_init in qemu)
> >>> pc_init()
> >>> qemu_system_reset()
> >>> load_vmstate()
> >>
> >> Hmm, are you sure that this is the only case where a device init or
> >> reset handler writes to already restored guest memory? Preloading the
> >> RAM this way is a non-standard scenario for QEMU, thus conceptually
> >> fragile. Does restoring happen before QEMU is even started, or can this
> >> point be controlled from QEMU?
> > 
> > Consider that this only happens with non-MMIO device memory, in practice
> > only videoram.
> > Vmware VGA does not memset the videoram in the reset handler, while QXL
> > already has the following:
> > 
> >     /* pre loadvm reset must not touch QXLRam.  This lives in
> >      * device memory, is migrated together with RAM and thus
> >      * already loaded at this point */
> >     if (!loadvm) {
> >         qxl_reset_state(d);
> >     }
> 
> Yes, but QEMU restores the RAM _after_ device reset, not before it.
> That's the problem with the Xen way - it is against the current QEMU
> standard.

QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.

To reply to your previous question more clearly: at restore time Qemu on
Xen would run in a non-standard scenario; the restore of the RAM happens
before QEMU is even started.

That is unfortunate but it would be very hard to change (I can give you
more details if you are interested in the reasons why it would be so
difficult).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:46:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLAA-00057D-NA; Mon, 23 Jan 2012 14:46:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RpLA9-000558-E9
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:46:25 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327329978!10149745!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28458 invoked from network); 23 Jan 2012 14:46:19 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:46:19 -0000
Received: by lago2 with SMTP id o2so3570452lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 06:46:18 -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
	:x-gm-message-state:content-type:content-transfer-encoding;
	bh=tmMdX4HuNw+uNy99IAPib6DlWvgjW8n8iGIee3JQOVM=;
	b=FOQWQVfCSzux+aSesPj7Juc+tOlk/WY/TRFhIyNYq46TvfVhqqQ9MgBYvu9U1juSF/
	Bf8F/O4w5b6RUXdBBWQQUb+W5YirK0fXA8qAViptARudRPCUIz8xa4eoYLuEDhcgwNTa
	Kmns2WhA6h5STe6G9b4Ls/9Xg7NC20nx0J8H4=
Received: by 10.112.24.196 with SMTP id w4mr2189445lbf.62.1327329978299; Mon,
	23 Jan 2012 06:46:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Mon, 23 Jan 2012 06:46:02 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CACaajQtqbqFDj2kHSp-2P1MqYWe_PLdcv_Q5UL7sxOWSCwModQ@mail.gmail.com>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
	<CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
	<20120119195046.GA3890@konrad-lan>
	<CACaajQuwjtFgHk3-2Tun3AiS+1hvi=LYSoQiynvgPRzE=sYEKw@mail.gmail.com>
	<CACaajQtqbqFDj2kHSp-2P1MqYWe_PLdcv_Q5UL7sxOWSCwModQ@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Mon, 23 Jan 2012 18:46:02 +0400
X-Google-Sender-Auth: 3pAqqu_2EX4isbCHasm7zkgLxsY
Message-ID: <CACaajQtYyGpOZQsqeKUb4ewt04Wm7_yueK7miadwgx3DAj1smw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
X-Gm-Message-State: ALoCoQlq2zQg71P38b58H7UhzQyWJ0vI9UIPMclUpI/uwvSGlhRUMTtcSpliZd35I8MBmpv05x3G
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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

MjAxMi8xLzIwIFZhc2lsaXkgVG9sc3RvdiA8di50b2xzdG92QHNlbGZpcC5ydT46Cj4gMjAxMi8x
LzIwIFZhc2lsaXkgVG9sc3RvdiA8di50b2xzdG92QHNlbGZpcC5ydT46Cj4+IDIwMTIvMS8xOSBL
b25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZEBkYXJub2sub3JnPjoKPj4+PiA+Cj4+Pj4gPiBX
aGljaCBrZXJuZWwgdmVyc2lvbiBvZiBEb21VPwo+Pj4+Cj4+Pj4gMi42LjMyLjI2IGZyb20geGVu
IGdpdCB0cmVlIGFuZCDCoDIuNi4xOC0xOTQuMjYuMS5lbDV4ZW4KPj4+Cj4+PiBGaXJzdCBvcmRl
ciBpcyB0byB1cGdyYWRlIHlvdXIga2VybmVsIGFuZCBzZWUgaWYgdGhlIHByb2JsZW0gZXhpc3Rz
Cj4+PiB3aXRoIGEgbmV3ZXIgMi42LjMyLlggdHJlZS4gdGhlbiBhbHNvIHRyeSAzLjAgb3IgMy4x
IGtlcm5lbC4KPj4+PgoKSSdtIGZpbmFsbHkgZmluZCB0aGUgcHJvYmxlbS4gSWYgZG9tVSB3cml0
ZSB0byB4ZW5zdG9yZSBzb21lCmluY29tcGxldGUgY29tbWFuZCBieSB3cml0aW4gYmluYXJ5IGRh
dGEgdG8gL3Byb2MveGVuL3hlbmJ1cwooZm9yIGV4YW1wbGUgIlwyXDBcMFwwXDBcMFwwXDBcMFww
XDBcMFwyMVwwXDBcMCIpIGFuZCBleGlzdHMsIHdhdGNoZXMKc3RvcCB3b3JraW5nIGFuZCBzZWNv
bmQgYXR0ZW1wIHRvIHJlYWQvd3JpdGUgc29tZSBmcm9tIGRvbVUgdG8KeGVuc3RvcmUgZmFpbGVk
IHdpdGggcHJvY2VzcyBsb2NrICB0aGF0IHRyaWVzIHRvIHdyaXRlIG1lc3NhZ2UuLi4KCkNhbiB0
aGlzIGJlIHNvbHZlZCAob3Igc29sdmVkIGFscmVhZHkgaW4gc29tZSB2ZXJzaW9uIG9mIHhlbmJ1
cyBkcml2ZXIgY29kZT8pLgoKLS0gClZhc2lsaXkgVG9sc3RvdiwKQ2xvZG8ucnUKZS1tYWlsOiB2
LnRvbHN0b3ZAc2VsZmlwLnJ1CmphYmJlcjogdmFzZUBzZWxmaXAucnUKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20v
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:46:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14:46:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLAA-00057D-NA; Mon, 23 Jan 2012 14:46:26 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RpLA9-000558-E9
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:46:25 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327329978!10149745!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28458 invoked from network); 23 Jan 2012 14:46:19 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 14:46:19 -0000
Received: by lago2 with SMTP id o2so3570452lag.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 06:46:18 -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
	:x-gm-message-state:content-type:content-transfer-encoding;
	bh=tmMdX4HuNw+uNy99IAPib6DlWvgjW8n8iGIee3JQOVM=;
	b=FOQWQVfCSzux+aSesPj7Juc+tOlk/WY/TRFhIyNYq46TvfVhqqQ9MgBYvu9U1juSF/
	Bf8F/O4w5b6RUXdBBWQQUb+W5YirK0fXA8qAViptARudRPCUIz8xa4eoYLuEDhcgwNTa
	Kmns2WhA6h5STe6G9b4Ls/9Xg7NC20nx0J8H4=
Received: by 10.112.24.196 with SMTP id w4mr2189445lbf.62.1327329978299; Mon,
	23 Jan 2012 06:46:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.83.36 with HTTP; Mon, 23 Jan 2012 06:46:02 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CACaajQtqbqFDj2kHSp-2P1MqYWe_PLdcv_Q5UL7sxOWSCwModQ@mail.gmail.com>
References: <CACaajQtfVSfaUrviZ+AczEhujj3Jy9igH9Cho0mskHTB2iaKbQ@mail.gmail.com>
	<20120117201525.GB25805@andromeda.dapyr.net>
	<CACaajQt=xO3aRKM2HvdXTcHmToED-DmnWa62EQwMTLgnrJVd8A@mail.gmail.com>
	<20120119195046.GA3890@konrad-lan>
	<CACaajQuwjtFgHk3-2Tun3AiS+1hvi=LYSoQiynvgPRzE=sYEKw@mail.gmail.com>
	<CACaajQtqbqFDj2kHSp-2P1MqYWe_PLdcv_Q5UL7sxOWSCwModQ@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Mon, 23 Jan 2012 18:46:02 +0400
X-Google-Sender-Auth: 3pAqqu_2EX4isbCHasm7zkgLxsY
Message-ID: <CACaajQtYyGpOZQsqeKUb4ewt04Wm7_yueK7miadwgx3DAj1smw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
X-Gm-Message-State: ALoCoQlq2zQg71P38b58H7UhzQyWJ0vI9UIPMclUpI/uwvSGlhRUMTtcSpliZd35I8MBmpv05x3G
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] shutdown/migration stop working on paravirt 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

MjAxMi8xLzIwIFZhc2lsaXkgVG9sc3RvdiA8di50b2xzdG92QHNlbGZpcC5ydT46Cj4gMjAxMi8x
LzIwIFZhc2lsaXkgVG9sc3RvdiA8di50b2xzdG92QHNlbGZpcC5ydT46Cj4+IDIwMTIvMS8xOSBL
b25yYWQgUnplc3p1dGVrIFdpbGsgPGtvbnJhZEBkYXJub2sub3JnPjoKPj4+PiA+Cj4+Pj4gPiBX
aGljaCBrZXJuZWwgdmVyc2lvbiBvZiBEb21VPwo+Pj4+Cj4+Pj4gMi42LjMyLjI2IGZyb20geGVu
IGdpdCB0cmVlIGFuZCDCoDIuNi4xOC0xOTQuMjYuMS5lbDV4ZW4KPj4+Cj4+PiBGaXJzdCBvcmRl
ciBpcyB0byB1cGdyYWRlIHlvdXIga2VybmVsIGFuZCBzZWUgaWYgdGhlIHByb2JsZW0gZXhpc3Rz
Cj4+PiB3aXRoIGEgbmV3ZXIgMi42LjMyLlggdHJlZS4gdGhlbiBhbHNvIHRyeSAzLjAgb3IgMy4x
IGtlcm5lbC4KPj4+PgoKSSdtIGZpbmFsbHkgZmluZCB0aGUgcHJvYmxlbS4gSWYgZG9tVSB3cml0
ZSB0byB4ZW5zdG9yZSBzb21lCmluY29tcGxldGUgY29tbWFuZCBieSB3cml0aW4gYmluYXJ5IGRh
dGEgdG8gL3Byb2MveGVuL3hlbmJ1cwooZm9yIGV4YW1wbGUgIlwyXDBcMFwwXDBcMFwwXDBcMFww
XDBcMFwyMVwwXDBcMCIpIGFuZCBleGlzdHMsIHdhdGNoZXMKc3RvcCB3b3JraW5nIGFuZCBzZWNv
bmQgYXR0ZW1wIHRvIHJlYWQvd3JpdGUgc29tZSBmcm9tIGRvbVUgdG8KeGVuc3RvcmUgZmFpbGVk
IHdpdGggcHJvY2VzcyBsb2NrICB0aGF0IHRyaWVzIHRvIHdyaXRlIG1lc3NhZ2UuLi4KCkNhbiB0
aGlzIGJlIHNvbHZlZCAob3Igc29sdmVkIGFscmVhZHkgaW4gc29tZSB2ZXJzaW9uIG9mIHhlbmJ1
cyBkcml2ZXIgY29kZT8pLgoKLS0gClZhc2lsaXkgVG9sc3RvdiwKQ2xvZG8ucnUKZS1tYWlsOiB2
LnRvbHN0b3ZAc2VsZmlwLnJ1CmphYmJlcjogdmFzZUBzZWxmaXAucnUKCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
WGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20v
eGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:47:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpLAv-0005J6-5s; Mon, 23 Jan 2012 14:47:13 +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 1RpLAt-0005Ig-C4
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:47:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327329900!49711049!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28133 invoked from network); 23 Jan 2012 14:45:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 14:45:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 14:47:09 +0000
Message-Id: <4F1D8145020000780006E70C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 14:48:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
	<4F1D786A020000780006E6D1@nat28.tlf.novell.com>
	<20120123142232.GA8983@aepfle.de>
In-Reply-To: <20120123142232.GA8983@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.01.12 at 15:22, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jan 23, Jan Beulich wrote:
> 
>> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
>> 
>> Given that the PV drivers must be building fine for SLE11 SP2, which
>> is 3.0-based, I wonder if this really is the correct fix (and doesn't
>> rather break the build). The first thing coming to mind is that
>> arch/x86/include/asm/xen/hypervisor.h shouldn't get included here
>> (and hence there shouldn't be any conflict). Are you perhaps trying
>> to build the PV drivers against a pv-ops-enabled configuration (which
>> is a wrong to try afaict)?
> 
> Its an ordinary kernel-source tree.

That's not the question - it matters what your .config is set to.

> git describe d9b8ca8474fd4fdd43ba6d97a4fee8b49b978067
> v2.6.37-rc5-2-gd9b8ca8

How is 2.6.37-rc5 related to this?

> The function appears in 2.6.38, so I think the version number is correct.

The version number appears to be correct (in 2.6.36 and 2.6.37 the
function existed, but was static in arch/x86/xen/enlighten.c), but
again that wasn't my point. Instead you will want to point out how
you ended up including the declaring header. (I'm running the PV
driver build every once in a while, and I know it had worked fine for
SLE11 SP2 sources a while back. Let me see how things look right
now:

master (3.2): getting an unrelated error apparently due to a missing
header inclusion, platform-pci/platform-pci.c building fine

sle11sp2 (3.0): building fine.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 14:47:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 14: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 1RpLAv-0005J6-5s; Mon, 23 Jan 2012 14:47:13 +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 1RpLAt-0005Ig-C4
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 14:47:11 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327329900!49711049!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28133 invoked from network); 23 Jan 2012 14:45:00 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 14:45:00 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 14:47:09 +0000
Message-Id: <4F1D8145020000780006E70C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 14:48:21 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
	<4F1D786A020000780006E6D1@nat28.tlf.novell.com>
	<20120123142232.GA8983@aepfle.de>
In-Reply-To: <20120123142232.GA8983@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 23.01.12 at 15:22, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jan 23, Jan Beulich wrote:
> 
>> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,38)
>> 
>> Given that the PV drivers must be building fine for SLE11 SP2, which
>> is 3.0-based, I wonder if this really is the correct fix (and doesn't
>> rather break the build). The first thing coming to mind is that
>> arch/x86/include/asm/xen/hypervisor.h shouldn't get included here
>> (and hence there shouldn't be any conflict). Are you perhaps trying
>> to build the PV drivers against a pv-ops-enabled configuration (which
>> is a wrong to try afaict)?
> 
> Its an ordinary kernel-source tree.

That's not the question - it matters what your .config is set to.

> git describe d9b8ca8474fd4fdd43ba6d97a4fee8b49b978067
> v2.6.37-rc5-2-gd9b8ca8

How is 2.6.37-rc5 related to this?

> The function appears in 2.6.38, so I think the version number is correct.

The version number appears to be correct (in 2.6.36 and 2.6.37 the
function existed, but was static in arch/x86/xen/enlighten.c), but
again that wasn't my point. Instead you will want to point out how
you ended up including the declaring header. (I'm running the PV
driver build every once in a while, and I know it had worked fine for
SLE11 SP2 sources a while back. Let me see how things look right
now:

master (3.2): getting an unrelated error apparently due to a missing
header inclusion, platform-pci/platform-pci.c building fine

sle11sp2 (3.0): building fine.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:03:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:03:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLQX-0005sK-RE; Mon, 23 Jan 2012 15:03:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RpLQV-0005sF-JE
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:03:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327330990!12095616!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkyNTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21438 invoked from network); 23 Jan 2012 15:03:11 -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;
	23 Jan 2012 15:03:11 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4F17B7EC076;
	Mon, 23 Jan 2012 07:03: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=XbxfgK0mlHmYRwVgueZT8mjnvoUyxOslD1wZXwcszLlR
	Wu0cuI+xDhVp79usJKRLsvyJxHz9xGhGpy4cC7dgKMLICdA9QY2sgAGKLjjbE1Le
	+If1SUtQ0PX0H1tEodXIVtS0PBh0OuwzjJxAXQrlaOHAJJ8pCdnPUE7ZWEcMKKs=
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=fIyRLbmU+vCELYAXXmRccgpR6B8=; b=BimvDmn8
	lnEGwgH7KPtkqXwLds1ORDPiyBbemkub8lwCxxiHEHtdEKJORNOGt0TbXndIMpht
	2wryBeiTltBrkrc607KjwYOMU6sD+i6aHzJGWHd/mTIzfW6M29BTx3muXr/spPHn
	+33nqsvm4QceZzV2UOYbgnX2mbAQNywBWLQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id F22117EC064; 
	Mon, 23 Jan 2012 07:03:08 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 23 Jan 2012 07:03:09 -0800
Message-ID: <2354ea8a6f50d7f7703369aac0ed80a2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1214.1327325228.1471.xen-devel@lists.xensource.com>
References: <mailman.1214.1327325228.1471.xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 07:03:09 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.campbell@citrix.com
Subject: Re: [Xen-devel] Xen 4.2 TODO List
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, 23 Jan 2012 13:19:05 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: xen-devel <xen-devel@lists.xensource.com>
> Subject: [Xen-devel] Xen 4.2 TODO List Update
> Message-ID: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Newly updated list follows. Please send me corrections (especially
> "done"). I've stopped CCing everyone, since I guess it is mostly spam to
> the majority.
>
> hypervisor, blockers:
>
>       * round-up of the closing of the security hole in MSI-X
>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>         access to MSI-X table pages). (Jan Beulich -- more fixes
>         required than first thought, patches posted)
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap)
>       * get the interface changes for sharing/paging/mem-events done and
>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>         Andres Lagar-Cavilla et al)
>               * mem event ring management posted, seems close to going
>                 in.
Mem event ring management has gone in, so you can chalk it off the list.

>               * sharing patches posted
A repost of the sharing queue Wed evening, after the last round of
comments. Any feedback from tools maintainers on "[PATCH 09 of 12] Update
memshr API and tools"?

Thanks
Andres

>
> tools, blockers:
>
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * event handling (Ian Jackson, posted several rounds,
>                 nearing completion?)
>               * drop libxl_device_model_info (move bits to build_info or
>                 elsewhere as appropriate) (Ian Campbell, first RFC sent)
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>                 first RFC sent)
>               * topologyinfo datastructure should be a list of tuples,
>                 not a tuple of lists. (nobody currently looking at this,
>                 not 100% sure this makes sense, could possibly defer and
>                 change after 4.2 in a compatible way)
>       * xl to use json for machine readable output instead of sexp by
>         default (Ian Campbell to revisit existing patch)
>       * xl support for vcpu pinning (Dario Faggioli)
>       * xl feature parity with xend wrt driver domain support (George
>         Dunlap)
>       * Integrate qemu+seabios upstream into the build (patches
>         reposted, pending). No change in default qemu for 4.2.
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
>
> hypervisor, nice to have:
>
>       * solid implementation of sharing/paging/mem-events (using work
>         queues) (Tim Deegan, Olaf Herring et al)
>       * A long standing issue is a fully synchronized p2m (locking
>         lookups) (Andres Lagar-Cavilla)
>       * NUMA improvement: domain affinity consistent with cpupool
>         membership (Dario Faggioli, Jeurgen Gross -- patch posted)
>
> tools, nice to have:
>
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? Roger Pau Monet was looking at this but its looking
>         like a big can-o-worms. (discussion on-going)
>       * Block script support -- follows on from hotplug script (Roger
>         Pau Monet)
>       * libyajl v2 support (patch posted by Roger Pau Monet, blocked on
>         autoconf?)
>       * Configure/control paging via xl/libxl (Olaf Herring)
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard)
>               * Upstream qemu save restore (Anthony Perard)
>       * Nested-virtualisation (currently should be marked
>         experimental,likely to release that way? Consider nested-svm
>         separate to nested-vmx. Nested-svm is in better shape)
>
> Tools, need to decide if pre- or post-4.2 feature:
>
>       * Autoconf (Roger Pau Monet posted a patch)
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:03:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:03:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLQX-0005sK-RE; Mon, 23 Jan 2012 15:03:21 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RpLQV-0005sF-JE
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:03:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327330990!12095616!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTkyNTk=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21438 invoked from network); 23 Jan 2012 15:03:11 -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;
	23 Jan 2012 15:03:11 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4F17B7EC076;
	Mon, 23 Jan 2012 07:03: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=XbxfgK0mlHmYRwVgueZT8mjnvoUyxOslD1wZXwcszLlR
	Wu0cuI+xDhVp79usJKRLsvyJxHz9xGhGpy4cC7dgKMLICdA9QY2sgAGKLjjbE1Le
	+If1SUtQ0PX0H1tEodXIVtS0PBh0OuwzjJxAXQrlaOHAJJ8pCdnPUE7ZWEcMKKs=
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=fIyRLbmU+vCELYAXXmRccgpR6B8=; b=BimvDmn8
	lnEGwgH7KPtkqXwLds1ORDPiyBbemkub8lwCxxiHEHtdEKJORNOGt0TbXndIMpht
	2wryBeiTltBrkrc607KjwYOMU6sD+i6aHzJGWHd/mTIzfW6M29BTx3muXr/spPHn
	+33nqsvm4QceZzV2UOYbgnX2mbAQNywBWLQ=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id F22117EC064; 
	Mon, 23 Jan 2012 07:03:08 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 23 Jan 2012 07:03:09 -0800
Message-ID: <2354ea8a6f50d7f7703369aac0ed80a2.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1214.1327325228.1471.xen-devel@lists.xensource.com>
References: <mailman.1214.1327325228.1471.xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 07:03:09 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: ian.campbell@citrix.com
Subject: Re: [Xen-devel] Xen 4.2 TODO List
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, 23 Jan 2012 13:19:05 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: xen-devel <xen-devel@lists.xensource.com>
> Subject: [Xen-devel] Xen 4.2 TODO List Update
> Message-ID: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Newly updated list follows. Please send me corrections (especially
> "done"). I've stopped CCing everyone, since I guess it is mostly spam to
> the majority.
>
> hypervisor, blockers:
>
>       * round-up of the closing of the security hole in MSI-X
>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>         access to MSI-X table pages). (Jan Beulich -- more fixes
>         required than first thought, patches posted)
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap)
>       * get the interface changes for sharing/paging/mem-events done and
>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>         Andres Lagar-Cavilla et al)
>               * mem event ring management posted, seems close to going
>                 in.
Mem event ring management has gone in, so you can chalk it off the list.

>               * sharing patches posted
A repost of the sharing queue Wed evening, after the last round of
comments. Any feedback from tools maintainers on "[PATCH 09 of 12] Update
memshr API and tools"?

Thanks
Andres

>
> tools, blockers:
>
>       * libxl stable API -- we would like 4.2 to define a stable API
>         which downstream's can start to rely on not changing. Aspects of
>         this are:
>               * event handling (Ian Jackson, posted several rounds,
>                 nearing completion?)
>               * drop libxl_device_model_info (move bits to build_info or
>                 elsewhere as appropriate) (Ian Campbell, first RFC sent)
>               * add libxl_defbool and generally try and arrange that
>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>                 first RFC sent)
>               * topologyinfo datastructure should be a list of tuples,
>                 not a tuple of lists. (nobody currently looking at this,
>                 not 100% sure this makes sense, could possibly defer and
>                 change after 4.2 in a compatible way)
>       * xl to use json for machine readable output instead of sexp by
>         default (Ian Campbell to revisit existing patch)
>       * xl support for vcpu pinning (Dario Faggioli)
>       * xl feature parity with xend wrt driver domain support (George
>         Dunlap)
>       * Integrate qemu+seabios upstream into the build (patches
>         reposted, pending). No change in default qemu for 4.2.
>       * More formally deprecate xm/xend. Manpage patches already in
>         tree. Needs release noting and communication around -rc1 to
>         remind people to test xl.
>
> hypervisor, nice to have:
>
>       * solid implementation of sharing/paging/mem-events (using work
>         queues) (Tim Deegan, Olaf Herring et al)
>       * A long standing issue is a fully synchronized p2m (locking
>         lookups) (Andres Lagar-Cavilla)
>       * NUMA improvement: domain affinity consistent with cpupool
>         membership (Dario Faggioli, Jeurgen Gross -- patch posted)
>
> tools, nice to have:
>
>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>         didn't put this under stable API above) but still good to have
>         for 4.2? Roger Pau Monet was looking at this but its looking
>         like a big can-o-worms. (discussion on-going)
>       * Block script support -- follows on from hotplug script (Roger
>         Pau Monet)
>       * libyajl v2 support (patch posted by Roger Pau Monet, blocked on
>         autoconf?)
>       * Configure/control paging via xl/libxl (Olaf Herring)
>       * Upstream qemu feature patches:
>               * Upstream qemu PCI passthrough support (Anthony Perard)
>               * Upstream qemu save restore (Anthony Perard)
>       * Nested-virtualisation (currently should be marked
>         experimental,likely to release that way? Consider nested-svm
>         separate to nested-vmx. Nested-svm is in better shape)
>
> Tools, need to decide if pre- or post-4.2 feature:
>
>       * Autoconf (Roger Pau Monet posted a patch)
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:05:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLSd-0005zU-Cn; Mon, 23 Jan 2012 15:05:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpLSc-0005z8-CC
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:05:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327331121!12185714!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21076 invoked from network); 23 Jan 2012 15:05:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 15:05:23 -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
	q0NF4Kc4025012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 15:04:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0NF4IB1003742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 15:04:18 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
	q0NF4Gjr003987; Mon, 23 Jan 2012 09:04:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 07:04:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 85ACF40077; Mon, 23 Jan 2012 10:02:01 -0500 (EST)
Date: Mon, 23 Jan 2012 10:02:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120123150201.GA11441@phenom.dumpdata.com>
References: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
	<CB3E3263.37CC2%keir@xen.org>
	<20120122203714.GB30288@andromeda.dapyr.net>
	<4F1D355D020000780006E4E9@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1D355D020000780006E4E9@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F1D76F6.00BE,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	ian.campbell@citrix.com, andres@lagarcavilla.org, ian.jackson@citrix.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 09:24:29AM +0000, Jan Beulich wrote:
> >>> On 22.01.12 at 21:37, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > So for the "Fun" of it I tried to see if the 'struct
> > xen_processor_performance' has some 32/64-bit issues and was surprised
> > to find they do. What I am more surprised to find is that nobody seems
> > to have had any troubles with this as it seems to have been there since
> > it was initially implemented. The major issue would have been with the
> > 'shared_type', 'domain_info' and the pointer to the 'states' being at
> > different offsets (So when running a 32-bit dom0 with a 64-bit
> > hypervisor).
> 
> Are you having an actual problem with the layout differences, or
> did you just observe them? As Keir said, this is being dealt with
> inside the hypervisor - the (Dom0) kernel doesn't need to care at
> all (which was the primary requirement when the 32-on-64
> support got added).

I just observed them when I was trying to use memcpy on the Linux<->Xen
structs and saw some padding issues. The further I looked the more
I saw of it and was wondering why nobody had tripped over it.

But the compat layer that Keir pointed to me does fix the 32/64 bit
issue I observed - so wheew, no bugs!

Thanks!
> 
> 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 Mon Jan 23 15:05:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLSd-0005zU-Cn; Mon, 23 Jan 2012 15:05:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpLSc-0005z8-CC
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:05:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327331121!12185714!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21076 invoked from network); 23 Jan 2012 15:05:23 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 15:05:23 -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
	q0NF4Kc4025012
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 15:04:21 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0NF4IB1003742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 15:04:18 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
	q0NF4Gjr003987; Mon, 23 Jan 2012 09:04:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 07:04:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 85ACF40077; Mon, 23 Jan 2012 10:02:01 -0500 (EST)
Date: Mon, 23 Jan 2012 10:02:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120123150201.GA11441@phenom.dumpdata.com>
References: <e8528eebbd67c74ea6898c39f572c846.squirrel@webmail.lagarcavilla.org>
	<CB3E3263.37CC2%keir@xen.org>
	<20120122203714.GB30288@andromeda.dapyr.net>
	<4F1D355D020000780006E4E9@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1D355D020000780006E4E9@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F1D76F6.00BE,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Keir Fraser <keir@xen.org>,
	ian.campbell@citrix.com, andres@lagarcavilla.org, ian.jackson@citrix.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Subject: Re: [Xen-devel] memop struct packing, 32/64 bits
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 09:24:29AM +0000, Jan Beulich wrote:
> >>> On 22.01.12 at 21:37, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > So for the "Fun" of it I tried to see if the 'struct
> > xen_processor_performance' has some 32/64-bit issues and was surprised
> > to find they do. What I am more surprised to find is that nobody seems
> > to have had any troubles with this as it seems to have been there since
> > it was initially implemented. The major issue would have been with the
> > 'shared_type', 'domain_info' and the pointer to the 'states' being at
> > different offsets (So when running a 32-bit dom0 with a 64-bit
> > hypervisor).
> 
> Are you having an actual problem with the layout differences, or
> did you just observe them? As Keir said, this is being dealt with
> inside the hypervisor - the (Dom0) kernel doesn't need to care at
> all (which was the primary requirement when the 32-on-64
> support got added).

I just observed them when I was trying to use memcpy on the Linux<->Xen
structs and saw some padding issues. The further I looked the more
I saw of it and was wondering why nobody had tripped over it.

But the compat layer that Keir pointed to me does fix the 32/64 bit
issue I observed - so wheew, no bugs!

Thanks!
> 
> 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 Mon Jan 23 15:15:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15: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 1RpLbX-0006DS-Ey; Mon, 23 Jan 2012 15:14:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpLbW-0006DN-DK
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:14:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327331634!49733122!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19077 invoked from network); 23 Jan 2012 15:13:54 -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;
	23 Jan 2012 15:13:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10220913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 15:14: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, 23 Jan 2012 15:14:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 23 Jan 2012 15:14:40 +0000
In-Reply-To: <2d6a14ce5b0eda6cc26c.1326682589@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<2d6a14ce5b0eda6cc26c.1326682589@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327331681.24561.147.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 09 of 12] Update memshr API and tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 02:56 +0000, Andres Lagar-Cavilla wrote:
> tools/blktap2/drivers/tapdisk-vbd.c |   6 +-
>  tools/blktap2/drivers/tapdisk.h     |   2 +-
>  tools/libxc/xc_memshr.c             |  63 ++++++++++++++++++++++++++++++++++--
>  tools/libxc/xenctrl.h               |  19 ++++++++++-
>  tools/memshr/bidir-daemon.c         |  34 ++++++++++++++-----
>  tools/memshr/bidir-hash.h           |  12 ++++--
>  tools/memshr/interface.c            |  30 ++++++++++-------
>  tools/memshr/memshr.h               |  11 +++++-
>  8 files changed, 139 insertions(+), 38 deletions(-)
> 
> 
> This patch is the folded version of API updates, along with the associated tool
> changes to ensure that the build is always consistent.
> 
> API updates:
> - The source domain in the sharing calls is no longer assumed to be dom0.
> - Previously, 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 and tools need to be updated to recall the share
>   functions with the information needed to fetch the page (which they readily
>   have).
> 
> Tool updates:
> The only (in-tree, that we know of) consumer of the mem sharing API is the
> memshr tool. This is updated to use the new API.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com> at least as far  as the
libxc bits go. I don't know much about the memshr/blktap side of things
but the changes look sane to me.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:15:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15: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 1RpLbX-0006DS-Ey; Mon, 23 Jan 2012 15:14:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpLbW-0006DN-DK
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:14:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327331634!49733122!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19077 invoked from network); 23 Jan 2012 15:13:54 -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;
	23 Jan 2012 15:13:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10220913"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 15:14: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, 23 Jan 2012 15:14:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Date: Mon, 23 Jan 2012 15:14:40 +0000
In-Reply-To: <2d6a14ce5b0eda6cc26c.1326682589@xdev.gridcentric.ca>
References: <patchbomb.1326682580@xdev.gridcentric.ca>
	<2d6a14ce5b0eda6cc26c.1326682589@xdev.gridcentric.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327331681.24561.147.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 09 of 12] Update memshr API and tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-16 at 02:56 +0000, Andres Lagar-Cavilla wrote:
> tools/blktap2/drivers/tapdisk-vbd.c |   6 +-
>  tools/blktap2/drivers/tapdisk.h     |   2 +-
>  tools/libxc/xc_memshr.c             |  63 ++++++++++++++++++++++++++++++++++--
>  tools/libxc/xenctrl.h               |  19 ++++++++++-
>  tools/memshr/bidir-daemon.c         |  34 ++++++++++++++-----
>  tools/memshr/bidir-hash.h           |  12 ++++--
>  tools/memshr/interface.c            |  30 ++++++++++-------
>  tools/memshr/memshr.h               |  11 +++++-
>  8 files changed, 139 insertions(+), 38 deletions(-)
> 
> 
> This patch is the folded version of API updates, along with the associated tool
> changes to ensure that the build is always consistent.
> 
> API updates:
> - The source domain in the sharing calls is no longer assumed to be dom0.
> - Previously, 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 and tools need to be updated to recall the share
>   functions with the information needed to fetch the page (which they readily
>   have).
> 
> Tool updates:
> The only (in-tree, that we know of) consumer of the mem sharing API is the
> memshr tool. This is updated to use the new API.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell <adin@scannell.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com> at least as far  as the
libxc bits go. I don't know much about the memshr/blktap side of things
but the changes look sane to me.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:29:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLp6-0006UF-6P; Mon, 23 Jan 2012 15:28:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RpLp4-0006UA-J8
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:28:42 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327332473!57113998!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzc3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1996 invoked from network); 23 Jan 2012 15:27:54 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 15:27:54 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6B3F621082
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 10:28:34 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute4.internal (MEProxy); Mon, 23 Jan 2012 10:28:34 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	WX/+qx4/Eqnv2/7K6cdWSsbRYHs=; b=SDtIRVy0DblFAsPM8Zk9KXAtHptaGesy
	IJds3x4Of7BTkP6pGA8MXrK6g7CAsoVhIVnVy6XGHXtGJCE6dplyuF04/7hKzYBB
	qu3k5HB+O2rdFBt+VCJ/ACk4k5jGHAlVJRyvsvSBq7Sh28aFjR5bnxBnei+dudE/
	K+4m6ABA8Rw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=WX/+qx4/Eqnv2/7K6cdWSsbRYHs=; b=
	ITLwaGHHL4O3ylzSrkY3YxROvGoKM4eGm4k6YRYsILk7rvTfB6RK1zykCOhC9Up7
	F2l8Xx4Q7aLdoHlGTfaMaBCEupe6JudStUUsvDh2SWTx1rj5QMnOSb025C+hQZe6
	4cd1mmAXD/Q3qy8w6e4QgVW/Wo3bGr0LfFKpwDmxag0=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 42901A00079; Mon, 23 Jan 2012 10:28:34 -0500 (EST)
Message-Id: <1327332514.25697.140661026919117@webmail.messagingengine.com>
X-Sasl-Enc: dsnfqNDROxkWMuKc/qyL2dOHmrsWHpgRVeoWrNNdBGrG 1327332514
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327318076.24561.63.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 07:28:34 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

On Mon, Jan 23, 2012, at 11:27 AM, Ian Campbell wrote:
> ISTRT xl had a bug at one point where it would fail to strip whitespace
> in the network KVP lists. i.e. the above ended up expecting to find a
> bridge named "br0  ". Can you try without the spaces please?

Edit the configuration file.

 - vif          = [ 'mac=00:16:3E:12:34:01, bridge=br0' ]
 + vif=['mac=00:16:3E:12:34:01,bridge=br0']             

xl create test.cfg
xl list
Name                            ID   Mem VCPUs      State   Time(s)
 Domain-0                        0  1010     1     r-----    1072.3
 test                            6  2048     2     -b----       2.2

Looks like it didn't make any difference :-(

brctl show
 bridge name     bridge id               STP enabled     interfaces
 br0             8000.0052351d5337       yes             eth0

xl console test
login
ping -c 2 192.168.1.1
 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 From 192.168.1.32 icmp_seq=1 Destination Host Unreachable
 From 192.168.1.32 icmp_seq=2 Destination Host Unreachable
 
 --- 192.168.1.1 ping statistics ---
 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time
 1000ms
 pipe 2

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:29:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:29:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLp6-0006UF-6P; Mon, 23 Jan 2012 15:28:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RpLp4-0006UA-J8
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:28:42 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327332473!57113998!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gMzc3Mzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1996 invoked from network); 23 Jan 2012 15:27:54 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 15:27:54 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6B3F621082
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 10:28:34 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute4.internal (MEProxy); Mon, 23 Jan 2012 10:28:34 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	WX/+qx4/Eqnv2/7K6cdWSsbRYHs=; b=SDtIRVy0DblFAsPM8Zk9KXAtHptaGesy
	IJds3x4Of7BTkP6pGA8MXrK6g7CAsoVhIVnVy6XGHXtGJCE6dplyuF04/7hKzYBB
	qu3k5HB+O2rdFBt+VCJ/ACk4k5jGHAlVJRyvsvSBq7Sh28aFjR5bnxBnei+dudE/
	K+4m6ABA8Rw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=WX/+qx4/Eqnv2/7K6cdWSsbRYHs=; b=
	ITLwaGHHL4O3ylzSrkY3YxROvGoKM4eGm4k6YRYsILk7rvTfB6RK1zykCOhC9Up7
	F2l8Xx4Q7aLdoHlGTfaMaBCEupe6JudStUUsvDh2SWTx1rj5QMnOSb025C+hQZe6
	4cd1mmAXD/Q3qy8w6e4QgVW/Wo3bGr0LfFKpwDmxag0=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 42901A00079; Mon, 23 Jan 2012 10:28:34 -0500 (EST)
Message-Id: <1327332514.25697.140661026919117@webmail.messagingengine.com>
X-Sasl-Enc: dsnfqNDROxkWMuKc/qyL2dOHmrsWHpgRVeoWrNNdBGrG 1327332514
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327318076.24561.63.camel@zakaz.uk.xensource.com>
Date: Mon, 23 Jan 2012 07:28:34 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

On Mon, Jan 23, 2012, at 11:27 AM, Ian Campbell wrote:
> ISTRT xl had a bug at one point where it would fail to strip whitespace
> in the network KVP lists. i.e. the above ended up expecting to find a
> bridge named "br0  ". Can you try without the spaces please?

Edit the configuration file.

 - vif          = [ 'mac=00:16:3E:12:34:01, bridge=br0' ]
 + vif=['mac=00:16:3E:12:34:01,bridge=br0']             

xl create test.cfg
xl list
Name                            ID   Mem VCPUs      State   Time(s)
 Domain-0                        0  1010     1     r-----    1072.3
 test                            6  2048     2     -b----       2.2

Looks like it didn't make any difference :-(

brctl show
 bridge name     bridge id               STP enabled     interfaces
 br0             8000.0052351d5337       yes             eth0

xl console test
login
ping -c 2 192.168.1.1
 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
 From 192.168.1.32 icmp_seq=1 Destination Host Unreachable
 From 192.168.1.32 icmp_seq=2 Destination Host Unreachable
 
 --- 192.168.1.1 ping statistics ---
 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time
 1000ms
 pipe 2

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:31:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLrI-0006bc-OV; Mon, 23 Jan 2012 15:31:00 +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 1RpLrH-0006bS-3Y
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:30:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327332630!49917988!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31197 invoked from network); 23 Jan 2012 15:30:31 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.13)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Jan 2012 15:30:31 -0000
Received: from mail117-tx2-R.bigfish.com (10.9.14.251) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Mon, 23 Jan 2012 15:30:43 +0000
Received: from mail117-tx2 (localhost [127.0.0.1])	by
	mail117-tx2-R.bigfish.com (Postfix) with ESMTP id 58D4F42008A;
	Mon, 23 Jan 2012 15:30:40 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N4015Lzz1202hzz8275bh8275dh5eeeKz2dhc1bhc31hc1ah668h839h)
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 mail117-tx2 (localhost.localdomain [127.0.0.1]) by mail117-tx2
	(MessageSwitch) id 1327332639812319_20317;
	Mon, 23 Jan 2012 15:30:39 +0000 (UTC)
Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.243])	by
	mail117-tx2.bigfish.com (Postfix) with ESMTP id BEFF510004D;
	Mon, 23 Jan 2012 15:30:39 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server id
	14.1.225.23; Mon, 23 Jan 2012 15:30:41 +0000
X-WSS-ID: 0LY9CFB-02-A66-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 2A3DEC80CE;	Mon, 23 Jan 2012 09:30:46 -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;
	Mon, 23 Jan 2012 09:30:51 -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;
	Mon, 23 Jan 2012 09:30:46 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Mon, 23 Jan 2012
	10:30:45 -0500
Received: from [165.204.15.179] (antimon.osrc.amd.com [165.204.15.179])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DBF4449C2B0; Mon, 23 Jan 2012
	15:30:43 +0000 (GMT)
Message-ID: <4F1D7D20.3080009@amd.com>
Date: Mon, 23 Jan 2012 16:30:40 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <osstest-10867-mainreport@xen.org>
	<20246.53721.166769.941437@mariner.uk.xensource.com>
In-Reply-To: <20246.53721.166769.941437@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <jbeulich@suse.com>, Adin Scannell <adin@scannell.ca>
Subject: Re: [Xen-devel] Heads-up re Re: [xen-unstable test] 10867:
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am 18.01.2012 15:06, schrieb Ian Jackson:
> xen.org writes ("[xen-unstable test] 10867: regressions - FAIL"):
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>   test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 10649
>
> My bisector is working on this and so far it seems to have narrowed it
> down to: 75b8e982eb7e is good; 6c104b46ef89 is bad.

Hi Ian,

What symptoms have you seen when windows install failed? I tested 
windows xpsp3 installation manually with tip. The first stage of 
installation seem to pass but I got BSOD when guest tries to reboot for 
the first time.

I traced back to c/s 24465 and saw the same result. I also tried c/s 
24300 blindly and this c/s seemed to work for me. But I got a lot of 
compilation error between 24465 and 24300, so could not bisect further.

Maybe we are not talking the issue here... But actually, the 2nd patch 
of my v4 patch queue will introduce a flag to disable all iommuv2 
emulation codes from being running on old or non-iommu systems. This 
will help to isolate iommuv2 part from the rest parts of Xen. This patch 
was originally on top of the new hypercalls. But maybe I could drop a 
new patch to let this patch applicable on tip?

Thanks,

Wei


> That means that one these commits has probably broken HVM:
>    amd iommu: Add iommu emulation for hvm guest
>    amd iommu: Introduces new helper functions to simplify bitwise operations
>    amd iommu: Refactoring iommu ring buffer definition
>    move declarations of some required per-arch functions into common headers
>    ia64: fix build (once again)
>    x86/mm: Code style fixes in mem_sharing.c
>    x86/mm: Disable paging_prep
>
> The bisector is currently testing e71bd3.  Full revision log below.
>
> Ian.
>
>
> changeset:   24492:6c104b46ef89
> user:        Wei Wang<wei.wang2@amd.com>
> date:        Thu Jan 12 13:50:50 2012 +0100
> files:       xen/arch/x86/hvm/intercept.c xen/drivers/passthrough/amd/Makefile xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_guest.c xen/drivers/passthrough/amd/iommu_map.c xen/drivers/passthrough/amd/pci_amd_iommu.c xen/include/asm-x86/amd-iommu.h xen/include/asm-x86/hvm/io.h xen/include/asm-x86/hvm/svm/amd-iommu-defs.h xen/include/asm-x86/hvm/svm/amd-iommu-proto.h xen/include/xen/hvm/iommu.h
> description:
> 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 guest OS. We have to expose iommu
> functionality to HVM guest, if we want assign ATS device to it. A new
> hypervisor mmio handler is added to intercept iommu mmio accesses from
> 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
> Committed-by: Jan Beulich<jbeulich@suse.com>
>
>
> changeset:   24491:522d544f4031
> user:        Wei Wang<wei.wang2@amd.com>
> date:        Thu Jan 12 13:49:34 2012 +0100
> files:       xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_init.c xen/include/asm-x86/hvm/svm/amd-iommu-defs.h xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
> description:
> amd iommu: Introduces new helper functions to simplify bitwise operations
>
> Signed-off-by: Wei Wang<wei.wang2@amd.com>
> Committed-by: Jan Beulich<jbeulich@suse.com>
>
>
> changeset:   24490:d59816959ac0
> user:        Wei Wang<wei.wang2@amd.com>
> date:        Thu Jan 12 13:48:57 2012 +0100
> files:       xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_init.c xen/include/asm-x86/amd-iommu.h
> description:
> 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>
> Committed-by: Jan Beulich<jbeulich@suse.com>
>
>
> changeset:   24489:8d2fa20dd3f3
> user:        Jan Beulich<jbeulich@suse.com>
> date:        Thu Jan 12 13:45:47 2012 +0100
> files:       xen/arch/ia64/xen/dom0_ops.c xen/arch/ia64/xen/domain.c xen/arch/ia64/xen/xensetup.c xen/arch/x86/domain.c xen/arch/x86/x86_64/domain.c xen/common/kernel.c xen/include/asm-ia64/hypercall.h xen/include/asm-x86/hypercall.h xen/include/asm-x86/setup.h xen/include/xen/hypercall.h
> description:
> move declarations of some required per-arch functions into common headers
>
> ... since it is pointless to have each arch declare them on their own
> (and now and the - see ia64 - forget to do so).
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
> Acked-by: Keir Fraser<keir@xen.org>
>
>
> changeset:   24488:e71bd3a75f07
> user:        Jan Beulich<jbeulich@suse.com>
> date:        Thu Jan 12 13:44:51 2012 +0100
> files:       xen/arch/ia64/xen/mm.c xen/include/asm-ia64/kexec.h
> description:
> ia64: fix build (once again)
>
> 24423:069c08b7de46 failed to add a necessary include, and for a long
> time kexec.h suffered from a missing structure forward declaration.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
> Acked-by: Keir Fraser<keir@xen.org>
>
>
> changeset:   24487:32dd444700bd
> user:        Andres Lagar-Cavilla<andres@lagarcavilla.org>
> date:        Thu Jan 12 11:02:18 2012 +0000
> files:       xen/arch/x86/mm.c xen/arch/x86/mm/mem_sharing.c
> description:
> x86/mm: Code style fixes in mem_sharing.c
>
> No functional changes, only code style issues.
>
> One small diff in mem_sharing_gref_to_gfn() looks like a logic change,
> but it's not.  The flow was confusing, so it's been clarified.
>
> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell<adin@scannell.ca>
> Acked-by: Tim Deegan<tim@xen.org>
> Committed-by: Tim Deegan<tim@xen.org>
>
>
> changeset:   24486:f04dfb11dd61
> user:        Andres Lagar-Cavilla<andres@lagarcavilla.org>
> date:        Thu Jan 12 10:52:30 2012 +0000
> files:       xen/arch/x86/mm/p2m.c
> description:
> x86/mm: Disable paging_prep
>
> The only way to page-in a page is now the safe paging_load domctl.
> (Unless the page was never paged out in the first place)
>
> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> Acked-by: Tim Deegan<tim@xen.org>
> Committed-by: Tim Deegan<tim@xen.org>
>
>
> changeset:   24485:75b8e982eb7e
> user:        Andres Lagar-Cavilla<andres@lagarcavilla.org>
> date:        Thu Jan 12 10:52:30 2012 +0000
> files:       xen/arch/x86/mm/p2m.c
> description:
> x86/mm: Allow a page in p2m_ram_paged_out state to be loaded
>
> This removes the need for a page to be accessed in order to be pageable
> again. A pager can now page-in pages at will with no need to map them
> in a separate thread.
>
> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> Acked-by: Tim Deegan<tim@xen.org>
> Committed-by: Tim Deegan<tim@xen.org>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:31:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:31:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLrI-0006bc-OV; Mon, 23 Jan 2012 15:31:00 +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 1RpLrH-0006bS-3Y
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:30:59 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327332630!49917988!1
X-Originating-IP: [65.55.88.13]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31197 invoked from network); 23 Jan 2012 15:30:31 -0000
Received: from tx2ehsobe003.messaging.microsoft.com (HELO
	TX2EHSOBE006.bigfish.com) (65.55.88.13)
	by server-11.tower-27.messagelabs.com with AES128-SHA encrypted SMTP;
	23 Jan 2012 15:30:31 -0000
Received: from mail117-tx2-R.bigfish.com (10.9.14.251) by
	TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id
	14.1.225.23; Mon, 23 Jan 2012 15:30:43 +0000
Received: from mail117-tx2 (localhost [127.0.0.1])	by
	mail117-tx2-R.bigfish.com (Postfix) with ESMTP id 58D4F42008A;
	Mon, 23 Jan 2012 15:30:40 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zz1432N4015Lzz1202hzz8275bh8275dh5eeeKz2dhc1bhc31hc1ah668h839h)
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 mail117-tx2 (localhost.localdomain [127.0.0.1]) by mail117-tx2
	(MessageSwitch) id 1327332639812319_20317;
	Mon, 23 Jan 2012 15:30:39 +0000 (UTC)
Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.243])	by
	mail117-tx2.bigfish.com (Postfix) with ESMTP id BEFF510004D;
	Mon, 23 Jan 2012 15:30:39 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server id
	14.1.225.23; Mon, 23 Jan 2012 15:30:41 +0000
X-WSS-ID: 0LY9CFB-02-A66-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 2A3DEC80CE;	Mon, 23 Jan 2012 09:30:46 -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;
	Mon, 23 Jan 2012 09:30:51 -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;
	Mon, 23 Jan 2012 09:30:46 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Mon, 23 Jan 2012
	10:30:45 -0500
Received: from [165.204.15.179] (antimon.osrc.amd.com [165.204.15.179])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id DBF4449C2B0; Mon, 23 Jan 2012
	15:30:43 +0000 (GMT)
Message-ID: <4F1D7D20.3080009@amd.com>
Date: Mon, 23 Jan 2012 16:30:40 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
References: <osstest-10867-mainreport@xen.org>
	<20246.53721.166769.941437@mariner.uk.xensource.com>
In-Reply-To: <20246.53721.166769.941437@mariner.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Jan Beulich <jbeulich@suse.com>, Adin Scannell <adin@scannell.ca>
Subject: Re: [Xen-devel] Heads-up re Re: [xen-unstable test] 10867:
	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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am 18.01.2012 15:06, schrieb Ian Jackson:
> xen.org writes ("[xen-unstable test] 10867: regressions - FAIL"):
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>>   test-amd64-i386-rhel6hvm-intel  7 redhat-install       fail REGR. vs. 10649
>
> My bisector is working on this and so far it seems to have narrowed it
> down to: 75b8e982eb7e is good; 6c104b46ef89 is bad.

Hi Ian,

What symptoms have you seen when windows install failed? I tested 
windows xpsp3 installation manually with tip. The first stage of 
installation seem to pass but I got BSOD when guest tries to reboot for 
the first time.

I traced back to c/s 24465 and saw the same result. I also tried c/s 
24300 blindly and this c/s seemed to work for me. But I got a lot of 
compilation error between 24465 and 24300, so could not bisect further.

Maybe we are not talking the issue here... But actually, the 2nd patch 
of my v4 patch queue will introduce a flag to disable all iommuv2 
emulation codes from being running on old or non-iommu systems. This 
will help to isolate iommuv2 part from the rest parts of Xen. This patch 
was originally on top of the new hypercalls. But maybe I could drop a 
new patch to let this patch applicable on tip?

Thanks,

Wei


> That means that one these commits has probably broken HVM:
>    amd iommu: Add iommu emulation for hvm guest
>    amd iommu: Introduces new helper functions to simplify bitwise operations
>    amd iommu: Refactoring iommu ring buffer definition
>    move declarations of some required per-arch functions into common headers
>    ia64: fix build (once again)
>    x86/mm: Code style fixes in mem_sharing.c
>    x86/mm: Disable paging_prep
>
> The bisector is currently testing e71bd3.  Full revision log below.
>
> Ian.
>
>
> changeset:   24492:6c104b46ef89
> user:        Wei Wang<wei.wang2@amd.com>
> date:        Thu Jan 12 13:50:50 2012 +0100
> files:       xen/arch/x86/hvm/intercept.c xen/drivers/passthrough/amd/Makefile xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_guest.c xen/drivers/passthrough/amd/iommu_map.c xen/drivers/passthrough/amd/pci_amd_iommu.c xen/include/asm-x86/amd-iommu.h xen/include/asm-x86/hvm/io.h xen/include/asm-x86/hvm/svm/amd-iommu-defs.h xen/include/asm-x86/hvm/svm/amd-iommu-proto.h xen/include/xen/hvm/iommu.h
> description:
> 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 guest OS. We have to expose iommu
> functionality to HVM guest, if we want assign ATS device to it. A new
> hypervisor mmio handler is added to intercept iommu mmio accesses from
> 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
> Committed-by: Jan Beulich<jbeulich@suse.com>
>
>
> changeset:   24491:522d544f4031
> user:        Wei Wang<wei.wang2@amd.com>
> date:        Thu Jan 12 13:49:34 2012 +0100
> files:       xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_init.c xen/include/asm-x86/hvm/svm/amd-iommu-defs.h xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
> description:
> amd iommu: Introduces new helper functions to simplify bitwise operations
>
> Signed-off-by: Wei Wang<wei.wang2@amd.com>
> Committed-by: Jan Beulich<jbeulich@suse.com>
>
>
> changeset:   24490:d59816959ac0
> user:        Wei Wang<wei.wang2@amd.com>
> date:        Thu Jan 12 13:48:57 2012 +0100
> files:       xen/drivers/passthrough/amd/iommu_cmd.c xen/drivers/passthrough/amd/iommu_init.c xen/include/asm-x86/amd-iommu.h
> description:
> 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>
> Committed-by: Jan Beulich<jbeulich@suse.com>
>
>
> changeset:   24489:8d2fa20dd3f3
> user:        Jan Beulich<jbeulich@suse.com>
> date:        Thu Jan 12 13:45:47 2012 +0100
> files:       xen/arch/ia64/xen/dom0_ops.c xen/arch/ia64/xen/domain.c xen/arch/ia64/xen/xensetup.c xen/arch/x86/domain.c xen/arch/x86/x86_64/domain.c xen/common/kernel.c xen/include/asm-ia64/hypercall.h xen/include/asm-x86/hypercall.h xen/include/asm-x86/setup.h xen/include/xen/hypercall.h
> description:
> move declarations of some required per-arch functions into common headers
>
> ... since it is pointless to have each arch declare them on their own
> (and now and the - see ia64 - forget to do so).
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
> Acked-by: Keir Fraser<keir@xen.org>
>
>
> changeset:   24488:e71bd3a75f07
> user:        Jan Beulich<jbeulich@suse.com>
> date:        Thu Jan 12 13:44:51 2012 +0100
> files:       xen/arch/ia64/xen/mm.c xen/include/asm-ia64/kexec.h
> description:
> ia64: fix build (once again)
>
> 24423:069c08b7de46 failed to add a necessary include, and for a long
> time kexec.h suffered from a missing structure forward declaration.
>
> Signed-off-by: Jan Beulich<jbeulich@suse.com>
> Acked-by: Keir Fraser<keir@xen.org>
>
>
> changeset:   24487:32dd444700bd
> user:        Andres Lagar-Cavilla<andres@lagarcavilla.org>
> date:        Thu Jan 12 11:02:18 2012 +0000
> files:       xen/arch/x86/mm.c xen/arch/x86/mm/mem_sharing.c
> description:
> x86/mm: Code style fixes in mem_sharing.c
>
> No functional changes, only code style issues.
>
> One small diff in mem_sharing_gref_to_gfn() looks like a logic change,
> but it's not.  The flow was confusing, so it's been clarified.
>
> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> Signed-off-by: Adin Scannell<adin@scannell.ca>
> Acked-by: Tim Deegan<tim@xen.org>
> Committed-by: Tim Deegan<tim@xen.org>
>
>
> changeset:   24486:f04dfb11dd61
> user:        Andres Lagar-Cavilla<andres@lagarcavilla.org>
> date:        Thu Jan 12 10:52:30 2012 +0000
> files:       xen/arch/x86/mm/p2m.c
> description:
> x86/mm: Disable paging_prep
>
> The only way to page-in a page is now the safe paging_load domctl.
> (Unless the page was never paged out in the first place)
>
> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> Acked-by: Tim Deegan<tim@xen.org>
> Committed-by: Tim Deegan<tim@xen.org>
>
>
> changeset:   24485:75b8e982eb7e
> user:        Andres Lagar-Cavilla<andres@lagarcavilla.org>
> date:        Thu Jan 12 10:52:30 2012 +0000
> files:       xen/arch/x86/mm/p2m.c
> description:
> x86/mm: Allow a page in p2m_ram_paged_out state to be loaded
>
> This removes the need for a page to be accessed in order to be pageable
> again. A pager can now page-in pages at will with no need to map them
> in a separate thread.
>
> Signed-off-by: Andres Lagar-Cavilla<andres@lagarcavilla.org>
> Acked-by: Tim Deegan<tim@xen.org>
> Committed-by: Tim Deegan<tim@xen.org>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:39:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:39:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLz3-0006rx-Qq; Mon, 23 Jan 2012 15:39:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpLz1-0006rZ-Ol
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:39:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327333133!12209133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20099 invoked from network); 23 Jan 2012 15:38:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 15:38:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10221745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 15:38:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 15:38: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 1RpLyu-0008UE-Mp;
	Mon, 23 Jan 2012 15:38:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RpLyu-00050c-MD;
	Mon, 23 Jan 2012 15:38:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11558-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 23 Jan 2012 15:38:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11558: 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 11558 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11558/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 11275
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 11275
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 11275
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11275
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 11275
 build-i386                    4 xen-build                 fail REGR. vs. 11275
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 11275
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 11275
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 11275
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 11275

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-win          7 windows-install              fail   like 11217

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  137c16a83e40
baseline version:
 xen                  80fdf2182bc6

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Marcus Granado <marcus.granado@eu.citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <Tim.Deegan@citrix.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.

------------------------------------------------------------
changeset:   24544:137c16a83e40
tag:         tip
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:42:12 2012 +0000
    
    libelf-loader: introduce elf_load_image
    
    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.
    
    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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24543:d6cdbc4fe078
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:41:27 2012 +0000
    
    Introduce clear_user and clear_guest
    
    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.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Jan Beulich <JBeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24542:37eefb79503c
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:40:35 2012 +0000
    
    xen: implement an signed 64 bit division helper function
    
    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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24541:96e071fbefd7
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:39:58 2012 +0000
    
    A collection of fixes to Xen common files
    
    - 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;
    - guest_physmap_add_page should be ((void)0).
    - fix guest_physmap_add_page;
    - 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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24540:ab0eab766edb
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:39:11 2012 +0000
    
    Include some header files that are not automatically included on all archs
    
    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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24539:95e07258d189
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:38:34 2012 +0000
    
    Move cpufreq option parsing to cpufreq.c
    
    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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24538:5bb22a6871f6
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Mon Jan 23 09:36:54 2012 +0000
    
    xenoprof: Make the escape code consistent across 32 and 64-bit xen
    
    At the moment, the xenoprof escape code is defined as "~0UL".
    Unfortunately, this expands to 0xffffffff on 32-bit systems
    and 0xffffffffffffffff on 64-bit systems; with the result that
    while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
    "compat mode") is broken.
    
    This patch makes the definition consistent across architectures.
    In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
    but this was seen as an acceptable thing to do.
    
    Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24537:3c0a533d3af0
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Mon Jan 23 09:36:29 2012 +0000
    
    xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor
    
    The dump_guest_backtrace() function attempted to walk the stack
    based on the assumption that the guest and hypervisor pointer sizes
    were the same; thus any 32-bit guest running under 64-bit hypervisor
    would have unreliable results.
    
    In 64-bit mode, read the 32-bit stack frame properly.
    
    Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24536:212cf37d50e1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Mon Jan 23 09:36:01 2012 +0000
    
    xenoprof: Adjust indentation
    
    Bring indentation into Xen hypervisor standard coding style.
    
    No functional changes.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24535:fb81b807c154
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 23 09:35:17 2012 +0000
    
    x86/vMSI: miscellaneous fixes
    
    This addresses a number of problems in msixtbl_{read,write}():
    - address alignment was not checked, allowing for memory corruption in
      the hypervisor (write case) or returning of hypervisor private data
      to the guest (read case)
    - the interrupt mask bit was permitted to be written by the guest
      (while Xen's interrupt flow control routines need to control it)
    - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
      numbers (making it unobvious why they have these values, and making
      the latter non-portable)
    - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
      non-zero table offset); this was also affecting host MSI-X code
    - struct msixtbl_entry's table_flags[] was one element larger than
      necessary due to improper open-coding of BITS_TO_LONGS()
    - msixtbl_read() unconditionally accessed the physical table, even
      though the data was only needed in a quarter of all cases
    - various calculations were done unnecessarily for both of the rather
      distinct code paths in msixtbl_read()
    
    Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
    chosen to be 3.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24534:eca719b621a1
user:        Keir Fraser <keir@xen.org>
date:        Sun Jan 22 10:20:03 2012 +0000
    
    x86/hvm: No need to arch_set_info_guest() before restoring per-vcpu HVM state.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24533:80fdf2182bc6
user:        Keir Fraser <keir@xen.org>
date:        Sat Jan 21 17:15:40 2012 +0000
    
    tools/libvchan: Beef up the CPU barriers in libvchan.
    
    Although they were sufficient for x86, they weren't safe more generally.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Mon Jan 23 15:39:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:39:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpLz3-0006rx-Qq; Mon, 23 Jan 2012 15:39:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpLz1-0006rZ-Ol
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:39:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327333133!12209133!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20099 invoked from network); 23 Jan 2012 15:38:53 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 15:38:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10221745"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 15:38:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 15:38: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 1RpLyu-0008UE-Mp;
	Mon, 23 Jan 2012 15:38:52 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RpLyu-00050c-MD;
	Mon, 23 Jan 2012 15:38:52 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11558-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 23 Jan 2012 15:38:52 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11558: 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 11558 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11558/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-intel  4 xen-install             fail REGR. vs. 11275
 test-amd64-i386-xl-multivcpu  4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-pv            4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-xl-credit2    4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-rhel6hvm-amd  4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-pair          6 xen-install/dst_host      fail REGR. vs. 11275
 test-amd64-i386-pair          5 xen-install/src_host      fail REGR. vs. 11275
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11275
 test-amd64-i386-xl            4 xen-install               fail REGR. vs. 11275
 build-i386                    4 xen-build                 fail REGR. vs. 11275
 test-amd64-i386-xend-winxpsp3  4 xen-install              fail REGR. vs. 11275
 test-amd64-i386-xl-win-vcpus1  4 xen-install              fail REGR. vs. 11275
 test-amd64-i386-win-vcpus1    4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-win           4 xen-install               fail REGR. vs. 11275
 test-amd64-i386-xl-win7-amd64  4 xen-install              fail REGR. vs. 11275
 test-amd64-i386-xl-winxpsp3-vcpus1  4 xen-install         fail REGR. vs. 11275

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-win          7 windows-install              fail   like 11217

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  137c16a83e40
baseline version:
 xen                  80fdf2182bc6

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Marcus Granado <marcus.granado@eu.citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <Tim.Deegan@citrix.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.

------------------------------------------------------------
changeset:   24544:137c16a83e40
tag:         tip
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:42:12 2012 +0000
    
    libelf-loader: introduce elf_load_image
    
    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.
    
    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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24543:d6cdbc4fe078
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:41:27 2012 +0000
    
    Introduce clear_user and clear_guest
    
    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.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Jan Beulich <JBeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24542:37eefb79503c
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:40:35 2012 +0000
    
    xen: implement an signed 64 bit division helper function
    
    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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24541:96e071fbefd7
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:39:58 2012 +0000
    
    A collection of fixes to Xen common files
    
    - 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;
    - guest_physmap_add_page should be ((void)0).
    - fix guest_physmap_add_page;
    - 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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24540:ab0eab766edb
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:39:11 2012 +0000
    
    Include some header files that are not automatically included on all archs
    
    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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24539:95e07258d189
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Mon Jan 23 09:38:34 2012 +0000
    
    Move cpufreq option parsing to cpufreq.c
    
    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>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24538:5bb22a6871f6
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Mon Jan 23 09:36:54 2012 +0000
    
    xenoprof: Make the escape code consistent across 32 and 64-bit xen
    
    At the moment, the xenoprof escape code is defined as "~0UL".
    Unfortunately, this expands to 0xffffffff on 32-bit systems
    and 0xffffffffffffffff on 64-bit systems; with the result that
    while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
    "compat mode") is broken.
    
    This patch makes the definition consistent across architectures.
    In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
    but this was seen as an acceptable thing to do.
    
    Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24537:3c0a533d3af0
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Mon Jan 23 09:36:29 2012 +0000
    
    xenoprof: Handle 32-bit guest stacks properly in a 64-bit hypervisor
    
    The dump_guest_backtrace() function attempted to walk the stack
    based on the assumption that the guest and hypervisor pointer sizes
    were the same; thus any 32-bit guest running under 64-bit hypervisor
    would have unreliable results.
    
    In 64-bit mode, read the 32-bit stack frame properly.
    
    Signed-off-by: Marcus Granado <marcus.granado@eu.citrix.com>
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24536:212cf37d50e1
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Mon Jan 23 09:36:01 2012 +0000
    
    xenoprof: Adjust indentation
    
    Bring indentation into Xen hypervisor standard coding style.
    
    No functional changes.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24535:fb81b807c154
user:        Jan Beulich <jbeulich@suse.com>
date:        Mon Jan 23 09:35:17 2012 +0000
    
    x86/vMSI: miscellaneous fixes
    
    This addresses a number of problems in msixtbl_{read,write}():
    - address alignment was not checked, allowing for memory corruption in
      the hypervisor (write case) or returning of hypervisor private data
      to the guest (read case)
    - the interrupt mask bit was permitted to be written by the guest
      (while Xen's interrupt flow control routines need to control it)
    - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
      numbers (making it unobvious why they have these values, and making
      the latter non-portable)
    - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
      non-zero table offset); this was also affecting host MSI-X code
    - struct msixtbl_entry's table_flags[] was one element larger than
      necessary due to improper open-coding of BITS_TO_LONGS()
    - msixtbl_read() unconditionally accessed the physical table, even
      though the data was only needed in a quarter of all cases
    - various calculations were done unnecessarily for both of the rather
      distinct code paths in msixtbl_read()
    
    Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
    chosen to be 3.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24534:eca719b621a1
user:        Keir Fraser <keir@xen.org>
date:        Sun Jan 22 10:20:03 2012 +0000
    
    x86/hvm: No need to arch_set_info_guest() before restoring per-vcpu HVM state.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24533:80fdf2182bc6
user:        Keir Fraser <keir@xen.org>
date:        Sat Jan 21 17:15:40 2012 +0000
    
    tools/libvchan: Beef up the CPU barriers in libvchan.
    
    Although they were sufficient for x86, they weren't safe more generally.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Mon Jan 23 15:42:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15: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 1RpM1o-000741-K4; Mon, 23 Jan 2012 15:41:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RpM1n-00073h-8f
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:41:51 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327333304!8387135!1
X-Originating-IP: [212.82.109.208]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	INFO_TLD,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 17903 invoked from network); 23 Jan 2012 15:41:44 -0000
Received: from nm25-vm7.bullet.mail.ird.yahoo.com (HELO
	nm25-vm7.bullet.mail.ird.yahoo.com) (212.82.109.208)
	by server-3.tower-21.messagelabs.com with SMTP;
	23 Jan 2012 15:41:44 -0000
Received: from [77.238.189.48] by nm25.bullet.mail.ird.yahoo.com with NNFMP;
	23 Jan 2012 15:41:44 -0000
Received: from [212.82.108.247] by tm1.bullet.mail.ird.yahoo.com with NNFMP;
	23 Jan 2012 15:41:44 -0000
Received: from [127.0.0.1] by omp1012.mail.ird.yahoo.com with NNFMP;
	23 Jan 2012 15:41:44 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 373198.21559.bm@omp1012.mail.ird.yahoo.com
Received: (qmail 13095 invoked by uid 60001); 23 Jan 2012 15:43:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1327333409; bh=KHAHeSsomT58bDqEAvI+9iiT387O5BnMxFeCpo7DpHs=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=ntw7nKRIwhF1TGGR3b6V+OuY7DRdtD1E9/P4X/XzSUMhhScp814wQME7ZLSDlGehj5j/Bkvqkovx8sP+qzpv46/9Tpgfw8UA8DaTKmWx3dABRN2a6reWSr4ybp7kDw0x0lvDnO3L3qBZF3aTL7EYHKpXsinmGrtHmwpdYGE18dY=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=gZvpwu7rpFVkghWTIVBrJpA0OfX5lLu+idn3okhszw73nwDxAhMgHQFkfySQ1EEwfOYRgLktsvXxjEjp9u0Nk+/l3BG1q87a1MHgc/GyPWo5Pnb7RBV5I4FR5zzSAKeMM+LilOGrwbEtSPH65/rPc0+IRaWp3BWva4q9itAsifs=;
X-YMail-OSG: F6WFUVEVM1k6FYcpOCFpXpugxy1nKG74A4ibk85fr3t74p9
	uZYUgUD.Y3WtB_XTD7uiB4F5z6exYG5qLzYf358FcPAKnH0omkPmlLIg0aPE
	cAiQrBPVOiRitCPC2QXGhwWhoqcIMWKw.0AGS5EpZ9WctqATQ85MKlAbVYCa
	9oDgGMldbEJ5SB3GA4YEh0_GDhhNMI18OUEgcOo9ovWayY_uT6csm5buzn1R
	BIYa2i1.LD8Qvu.9yQUW.iJk7pc5Lfb3UEpjh.zDK0xl9nEhKNU54TiZwNFM
	zMJtkvSMPmEKS9hOcbwxu5GSkBiRLnPdwTQW_ENOwvEgpLWOdo.0kgKuvfPD
	Xe_0fB0.hw9xyF4EK1Q3Z99XcVgnaUCx7YVOgxwzXK_BaARETxZAe8fiQbsU
	Xgcv49sKA2lmdN21e.TKL.BUWZM53Xhnqc11aRhCDfocuuLmNix7Dkk4U1v5
	pdkIjFuUCCBuCDZ7Rbxitphyc1Gs2k345D1lnu2_LcY63Fs0U0t81qUA8GkV
	KTSGXEYSmY6MWas03ebwdjMM-
Received: from [195.167.237.98] by web29811.mail.ird.yahoo.com via HTTP;
	Mon, 23 Jan 2012 15:43:29 GMT
X-Mailer: YahooMailWebService/0.8.116.331537
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
Message-ID: <1327333409.8800.YahooMailNeo@web29811.mail.ird.yahoo.com>
Date: Mon, 23 Jan 2012 15:43:29 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <201201231417.43018.tobias.geiger@vido.info>
MIME-Version: 1.0
Cc: Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Re :  [Xen-users]  VGA passthough still not working
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="===============4389060528686486254=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4389060528686486254==
Content-Type: multipart/alternative; boundary="437598848-1604741253-1327333409=:8800"

--437598848-1604741253-1327333409=:8800
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

To be more precised=0A=0A- Using ATI is much easier........................=
...................I agree even if I haven't yet tested it. My new ATI card=
 is sleeping in my room=0A=0A=0A- NVIDIA + domU HVM Windows XP don't reboot=
...I agree except that=A0 restarting will work only once if - for the first=
 shutdown - you use 'shutdown -s -t 00'.=0A=0A=0A- NVIDIA + domU HVM Linux =
+ PVHVMonLinux drivers can be rebooted several times=A0 but this domU has t=
o be the first domU rebooted since the start of the dom0.=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=0A=0A________________________________=0A De=A0: Tobias Geig=
er <tobias.geiger@vido.info>=0A=C0=A0: xen-devel@lists.xensource.com =0ACc=
=A0: Sandi Romih <romihs.forums@gmail.com>; "xen-users@lists.xensource.com"=
 <xen-users@lists.xensource.com>; Ian Campbell <Ian.Campbell@citrix.com>; c=
hris <tknchris@gmail.com> =0AEnvoy=E9 le : Lundi 23 janvier 2012 14h17=0AOb=
jet=A0: Re: [Xen-devel] [Xen-users]  VGA passthough still not working=0A =
=0AHello!=0A=0AThe thing is, you either dont need patches at all to get it =
to work (ATI), or =0Ayou need to customize patches reflecting your individu=
al setup (NVIDIA);=0A=0ATo be more specific:=0AI can confirm that passing t=
hrough a ATI Card works "out of the box" - either =0Ato Windows 7 or Window=
s XP;=0AIn the past i had a setup running with a NVIDIA card, it only worke=
d with =0Aspecial patches (the ones David packed together and offers as tar=
ball) and - as =0Afar as i can tell - are not generaly working for all NVID=
IA Cards, i.e. you =0Ahave to adjust Memory-Adresses in the acpi.dst (iirc)=
. - and even then the =0Apassed through Card worked only with Windows XP - =
NOT with Windows 7;=0A=0ABoth setup have the "flaw" that they only work onc=
e - meaning you can't reboot =0Ayour DomU , cause after the reboot the pass=
ed-through Card doesnt have correct =0A3D-Accelleration any more (was/is th=
e case with NVIDIA and ATI, Windows XP and =0AWindows7 )=0A=0ASo - to summa=
rize: It works easiest and most featureful with a ATI Card; =0A=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It may work with patches and on=
ly with WindowsXP =0Awith an NVIDIA card=0A=0ATo me it seems that unless so=
meone finds an general approach to runtime-detect =0Athe NVIDIA-Secific stu=
ff , submitting any patches may be to early, as it arouses =0Aexpectations =
which only in some cases will be met.=0A=0AThat said - i gladly can forward=
-port these old patches, if you think they are =0Ahelping in any way.=0A=0A=
Greetings!=0ATobias=0A=0AAm Montag, 23. Januar 2012, 12:39:38 schrieb Ian C=
ampbell:=0A> Please do not a) top-post or b) cross-post. The latter being a=
imed at=0A> whoever started this thread.=0A> =0A> On Mon, 2012-01-23 at 11:=
25 +0000, Sandi Romih wrote:=0A> > Yeah, I guess xen has generally been foc=
used on the server end.=0A> =0A> Xen is focused on whatever people submit p=
atches to do. Many of the core=0A> developers are not currently looking at =
VGA passthrough, we have plenty=0A> of stuff on our plates, but we are more=
 than happy to review and accept=0A> patches to implement/improve/fix this =
feature if only those people who=0A> are interested in it would take the ti=
me to submit them per=0A> http://wiki.xen.org/wiki/SubmittingXenPatches . I=
'm afraid we are not=0A> going to go out hunting for patches on the Interne=
t.=0A> =0A> David Techer recently offered to do this but perhaps he would b=
e=0A> interested in some help from you?=0A> =0A> Ian.=0A> =0A> =0A> =0A> =
=0A> _______________________________________________=0A> Xen-devel mailing =
list=0A> Xen-devel@lists.xensource.com=0A> http://lists.xensource.com/xen-d=
evel=0A=0A=0A_______________________________________________=0AXen-devel ma=
iling list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensource.com/xen=
-devel
--437598848-1604741253-1327333409=:8800
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>To be more=
 precised</span></div><div><br><span></span></div><div><span>- U</span><spa=
n>sing ATI is much easier...........................................I agree=
 even if I haven't yet tested it. My new ATI card is sleeping in my room<br=
></span></div><div><span><br></span></div><div><span>- NVIDIA + domU HVM Wi=
ndows XP don't reboot...I agree except that&nbsp; restarting will work only=
 once if - for the first shutdown - you use 'shutdown -s -t 00'.<br></span>=
</div><div><span><br></span></div><div><span>- NVIDIA + domU HVM Linux + PV=
HVMonLinux drivers can be rebooted several times&nbsp; but this domU has to=
 be the first domU rebooted since the start of the
 dom0.</span></div><div><br><span></span></div><div><span><br></span></div>=
<div><br><span></span></div><div><span><br></span></div><div><br><span></sp=
an></div><div><span><br></span></div><div><br><span></span></div><div><span=
><br></span></div><div><br><span></span></div><div><span><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, times, serif; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2" =
face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nb=
sp;:</span></b> Tobias Geiger &lt;tobias.geiger@vido.info&gt;<br> <b><span =
style=3D"font-weight: bold;">=C0&nbsp;:</span></b> xen-devel@lists.xensourc=
e.com <br><b><span style=3D"font-weight: bold;">Cc&nbsp;:</span></b> Sandi =
Romih &lt;romihs.forums@gmail.com&gt;; "xen-users@lists.xensource.com" &lt;=
xen-users@lists.xensource.com&gt;; Ian Campbell &lt;Ian.Campbell@citrix.com=
&gt;; chris
 &lt;tknchris@gmail.com&gt; <br> <b><span style=3D"font-weight: bold;">Envo=
y=E9 le :</span></b> Lundi 23 janvier 2012 14h17<br> <b><span style=3D"font=
-weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] [Xen-users]  VGA pa=
ssthough still not working<br> </font> </div> <br>Hello!<br><br>The thing i=
s, you either dont need patches at all to get it to work (ATI), or <br>you =
need to customize patches reflecting your individual setup (NVIDIA);<br><br=
>To be more specific:<br>I can confirm that passing through a ATI Card work=
s "out of the box" - either <br>to Windows 7 or Windows XP;<br>In the past =
i had a setup running with a NVIDIA card, it only worked with <br>special p=
atches (the ones David packed together and offers as tarball) and - as <br>=
far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you=
 <br>have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then=
 the <br>passed through Card worked only with Windows XP - NOT with
 Windows 7;<br><br>Both setup have the "flaw" that they only work once - me=
aning you can't reboot <br>your DomU , cause after the reboot the passed-th=
rough Card doesnt have correct <br>3D-Accelleration any more (was/is the ca=
se with NVIDIA and ATI, Windows XP and <br>Windows7 )<br><br>So - to summar=
ize: It works easiest and most featureful with a ATI Card; <br>&nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; It may work with patches and only with WindowsXP <br>with an NVI=
DIA card<br><br>To me it seems that unless someone finds an general approac=
h to runtime-detect <br>the NVIDIA-Secific stuff , submitting any patches m=
ay be to early, as it arouses <br>expectations which only in some cases wil=
l be met.<br><br>That said - i gladly can forward-port these old patches, i=
f you think they are <br>helping in any way.<br><br>Greetings!<br>Tobias<br=
><br>Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian
 Campbell:<br>&gt; Please do not a) top-post or b) cross-post. The latter b=
eing aimed at<br>&gt; whoever started this thread.<br>&gt; <br>&gt; On Mon,=
 2012-01-23 at 11:25 +0000, Sandi Romih wrote:<br>&gt; &gt; Yeah, I guess x=
en has generally been focused on the server end.<br>&gt; <br>&gt; Xen is fo=
cused on whatever people submit patches to do. Many of the core<br>&gt; dev=
elopers are not currently looking at VGA passthrough, we have plenty<br>&gt=
; of stuff on our plates, but we are more than happy to review and accept<b=
r>&gt; patches to implement/improve/fix this feature if only those people w=
ho<br>&gt; are interested in it would take the time to submit them per<br>&=
gt; <a href=3D"http://wiki.xen.org/wiki/SubmittingXenPatches" target=3D"_bl=
ank">http://wiki.xen.org/wiki/SubmittingXenPatches</a> . I'm afraid we are =
not<br>&gt; going to go out hunting for patches on the Internet.<br>&gt; <b=
r>&gt; David Techer recently offered to do this but perhaps he would
 be<br>&gt; interested in some help from you?<br>&gt; <br>&gt; Ian.<br>&gt;=
 <br>&gt; <br>&gt; <br>&gt; <br>&gt; ______________________________________=
_________<br>&gt; Xen-devel mailing list<br>&gt; <a ymailto=3D"mailto:Xen-d=
evel@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xensource.com">Xen=
-devel@lists.xensource.com</a><br>&gt; <a href=3D"http://lists.xensource.co=
m/xen-devel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br>=
<br><br>_______________________________________________<br>Xen-devel mailin=
g list<br><a ymailto=3D"mailto:Xen-devel@lists.xensource.com" href=3D"mailt=
o:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br><a hr=
ef=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://lists.=
xensource.com/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
--437598848-1604741253-1327333409=:8800--


--===============4389060528686486254==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4389060528686486254==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:42:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15: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 1RpM1o-000741-K4; Mon, 23 Jan 2012 15:41:52 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <davidtecher@yahoo.fr>) id 1RpM1n-00073h-8f
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:41:51 +0000
X-Env-Sender: davidtecher@yahoo.fr
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327333304!8387135!1
X-Originating-IP: [212.82.109.208]
X-SpamReason: No, hits=1.5 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	INFO_TLD,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 17903 invoked from network); 23 Jan 2012 15:41:44 -0000
Received: from nm25-vm7.bullet.mail.ird.yahoo.com (HELO
	nm25-vm7.bullet.mail.ird.yahoo.com) (212.82.109.208)
	by server-3.tower-21.messagelabs.com with SMTP;
	23 Jan 2012 15:41:44 -0000
Received: from [77.238.189.48] by nm25.bullet.mail.ird.yahoo.com with NNFMP;
	23 Jan 2012 15:41:44 -0000
Received: from [212.82.108.247] by tm1.bullet.mail.ird.yahoo.com with NNFMP;
	23 Jan 2012 15:41:44 -0000
Received: from [127.0.0.1] by omp1012.mail.ird.yahoo.com with NNFMP;
	23 Jan 2012 15:41:44 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 373198.21559.bm@omp1012.mail.ird.yahoo.com
Received: (qmail 13095 invoked by uid 60001); 23 Jan 2012 15:43:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024;
	t=1327333409; bh=KHAHeSsomT58bDqEAvI+9iiT387O5BnMxFeCpo7DpHs=;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=ntw7nKRIwhF1TGGR3b6V+OuY7DRdtD1E9/P4X/XzSUMhhScp814wQME7ZLSDlGehj5j/Bkvqkovx8sP+qzpv46/9Tpgfw8UA8DaTKmWx3dABRN2a6reWSr4ybp7kDw0x0lvDnO3L3qBZF3aTL7EYHKpXsinmGrtHmwpdYGE18dY=
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:Cc:In-Reply-To:MIME-Version:Content-Type;
	b=gZvpwu7rpFVkghWTIVBrJpA0OfX5lLu+idn3okhszw73nwDxAhMgHQFkfySQ1EEwfOYRgLktsvXxjEjp9u0Nk+/l3BG1q87a1MHgc/GyPWo5Pnb7RBV5I4FR5zzSAKeMM+LilOGrwbEtSPH65/rPc0+IRaWp3BWva4q9itAsifs=;
X-YMail-OSG: F6WFUVEVM1k6FYcpOCFpXpugxy1nKG74A4ibk85fr3t74p9
	uZYUgUD.Y3WtB_XTD7uiB4F5z6exYG5qLzYf358FcPAKnH0omkPmlLIg0aPE
	cAiQrBPVOiRitCPC2QXGhwWhoqcIMWKw.0AGS5EpZ9WctqATQ85MKlAbVYCa
	9oDgGMldbEJ5SB3GA4YEh0_GDhhNMI18OUEgcOo9ovWayY_uT6csm5buzn1R
	BIYa2i1.LD8Qvu.9yQUW.iJk7pc5Lfb3UEpjh.zDK0xl9nEhKNU54TiZwNFM
	zMJtkvSMPmEKS9hOcbwxu5GSkBiRLnPdwTQW_ENOwvEgpLWOdo.0kgKuvfPD
	Xe_0fB0.hw9xyF4EK1Q3Z99XcVgnaUCx7YVOgxwzXK_BaARETxZAe8fiQbsU
	Xgcv49sKA2lmdN21e.TKL.BUWZM53Xhnqc11aRhCDfocuuLmNix7Dkk4U1v5
	pdkIjFuUCCBuCDZ7Rbxitphyc1Gs2k345D1lnu2_LcY63Fs0U0t81qUA8GkV
	KTSGXEYSmY6MWas03ebwdjMM-
Received: from [195.167.237.98] by web29811.mail.ird.yahoo.com via HTTP;
	Mon, 23 Jan 2012 15:43:29 GMT
X-Mailer: YahooMailWebService/0.8.116.331537
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
Message-ID: <1327333409.8800.YahooMailNeo@web29811.mail.ird.yahoo.com>
Date: Mon, 23 Jan 2012 15:43:29 +0000 (GMT)
From: David TECHER <davidtecher@yahoo.fr>
To: Tobias Geiger <tobias.geiger@vido.info>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <201201231417.43018.tobias.geiger@vido.info>
MIME-Version: 1.0
Cc: Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: [Xen-devel] Re :  [Xen-users]  VGA passthough still not working
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="===============4389060528686486254=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4389060528686486254==
Content-Type: multipart/alternative; boundary="437598848-1604741253-1327333409=:8800"

--437598848-1604741253-1327333409=:8800
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

To be more precised=0A=0A- Using ATI is much easier........................=
...................I agree even if I haven't yet tested it. My new ATI card=
 is sleeping in my room=0A=0A=0A- NVIDIA + domU HVM Windows XP don't reboot=
...I agree except that=A0 restarting will work only once if - for the first=
 shutdown - you use 'shutdown -s -t 00'.=0A=0A=0A- NVIDIA + domU HVM Linux =
+ PVHVMonLinux drivers can be rebooted several times=A0 but this domU has t=
o be the first domU rebooted since the start of the dom0.=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A=0A=0A=0A________________________________=0A De=A0: Tobias Geig=
er <tobias.geiger@vido.info>=0A=C0=A0: xen-devel@lists.xensource.com =0ACc=
=A0: Sandi Romih <romihs.forums@gmail.com>; "xen-users@lists.xensource.com"=
 <xen-users@lists.xensource.com>; Ian Campbell <Ian.Campbell@citrix.com>; c=
hris <tknchris@gmail.com> =0AEnvoy=E9 le : Lundi 23 janvier 2012 14h17=0AOb=
jet=A0: Re: [Xen-devel] [Xen-users]  VGA passthough still not working=0A =
=0AHello!=0A=0AThe thing is, you either dont need patches at all to get it =
to work (ATI), or =0Ayou need to customize patches reflecting your individu=
al setup (NVIDIA);=0A=0ATo be more specific:=0AI can confirm that passing t=
hrough a ATI Card works "out of the box" - either =0Ato Windows 7 or Window=
s XP;=0AIn the past i had a setup running with a NVIDIA card, it only worke=
d with =0Aspecial patches (the ones David packed together and offers as tar=
ball) and - as =0Afar as i can tell - are not generaly working for all NVID=
IA Cards, i.e. you =0Ahave to adjust Memory-Adresses in the acpi.dst (iirc)=
. - and even then the =0Apassed through Card worked only with Windows XP - =
NOT with Windows 7;=0A=0ABoth setup have the "flaw" that they only work onc=
e - meaning you can't reboot =0Ayour DomU , cause after the reboot the pass=
ed-through Card doesnt have correct =0A3D-Accelleration any more (was/is th=
e case with NVIDIA and ATI, Windows XP and =0AWindows7 )=0A=0ASo - to summa=
rize: It works easiest and most featureful with a ATI Card; =0A=A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It may work with patches and on=
ly with WindowsXP =0Awith an NVIDIA card=0A=0ATo me it seems that unless so=
meone finds an general approach to runtime-detect =0Athe NVIDIA-Secific stu=
ff , submitting any patches may be to early, as it arouses =0Aexpectations =
which only in some cases will be met.=0A=0AThat said - i gladly can forward=
-port these old patches, if you think they are =0Ahelping in any way.=0A=0A=
Greetings!=0ATobias=0A=0AAm Montag, 23. Januar 2012, 12:39:38 schrieb Ian C=
ampbell:=0A> Please do not a) top-post or b) cross-post. The latter being a=
imed at=0A> whoever started this thread.=0A> =0A> On Mon, 2012-01-23 at 11:=
25 +0000, Sandi Romih wrote:=0A> > Yeah, I guess xen has generally been foc=
used on the server end.=0A> =0A> Xen is focused on whatever people submit p=
atches to do. Many of the core=0A> developers are not currently looking at =
VGA passthrough, we have plenty=0A> of stuff on our plates, but we are more=
 than happy to review and accept=0A> patches to implement/improve/fix this =
feature if only those people who=0A> are interested in it would take the ti=
me to submit them per=0A> http://wiki.xen.org/wiki/SubmittingXenPatches . I=
'm afraid we are not=0A> going to go out hunting for patches on the Interne=
t.=0A> =0A> David Techer recently offered to do this but perhaps he would b=
e=0A> interested in some help from you?=0A> =0A> Ian.=0A> =0A> =0A> =0A> =
=0A> _______________________________________________=0A> Xen-devel mailing =
list=0A> Xen-devel@lists.xensource.com=0A> http://lists.xensource.com/xen-d=
evel=0A=0A=0A_______________________________________________=0AXen-devel ma=
iling list=0AXen-devel@lists.xensource.com=0Ahttp://lists.xensource.com/xen=
-devel
--437598848-1604741253-1327333409=:8800
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>To be more=
 precised</span></div><div><br><span></span></div><div><span>- U</span><spa=
n>sing ATI is much easier...........................................I agree=
 even if I haven't yet tested it. My new ATI card is sleeping in my room<br=
></span></div><div><span><br></span></div><div><span>- NVIDIA + domU HVM Wi=
ndows XP don't reboot...I agree except that&nbsp; restarting will work only=
 once if - for the first shutdown - you use 'shutdown -s -t 00'.<br></span>=
</div><div><span><br></span></div><div><span>- NVIDIA + domU HVM Linux + PV=
HVMonLinux drivers can be rebooted several times&nbsp; but this domU has to=
 be the first domU rebooted since the start of the
 dom0.</span></div><div><br><span></span></div><div><span><br></span></div>=
<div><br><span></span></div><div><span><br></span></div><div><br><span></sp=
an></div><div><span><br></span></div><div><br><span></span></div><div><span=
><br></span></div><div><br><span></span></div><div><span><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, times, serif; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2" =
face=3D"Arial"> <hr size=3D"1">  <b><span style=3D"font-weight:bold;">De&nb=
sp;:</span></b> Tobias Geiger &lt;tobias.geiger@vido.info&gt;<br> <b><span =
style=3D"font-weight: bold;">=C0&nbsp;:</span></b> xen-devel@lists.xensourc=
e.com <br><b><span style=3D"font-weight: bold;">Cc&nbsp;:</span></b> Sandi =
Romih &lt;romihs.forums@gmail.com&gt;; "xen-users@lists.xensource.com" &lt;=
xen-users@lists.xensource.com&gt;; Ian Campbell &lt;Ian.Campbell@citrix.com=
&gt;; chris
 &lt;tknchris@gmail.com&gt; <br> <b><span style=3D"font-weight: bold;">Envo=
y=E9 le :</span></b> Lundi 23 janvier 2012 14h17<br> <b><span style=3D"font=
-weight: bold;">Objet&nbsp;:</span></b> Re: [Xen-devel] [Xen-users]  VGA pa=
ssthough still not working<br> </font> </div> <br>Hello!<br><br>The thing i=
s, you either dont need patches at all to get it to work (ATI), or <br>you =
need to customize patches reflecting your individual setup (NVIDIA);<br><br=
>To be more specific:<br>I can confirm that passing through a ATI Card work=
s "out of the box" - either <br>to Windows 7 or Windows XP;<br>In the past =
i had a setup running with a NVIDIA card, it only worked with <br>special p=
atches (the ones David packed together and offers as tarball) and - as <br>=
far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you=
 <br>have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then=
 the <br>passed through Card worked only with Windows XP - NOT with
 Windows 7;<br><br>Both setup have the "flaw" that they only work once - me=
aning you can't reboot <br>your DomU , cause after the reboot the passed-th=
rough Card doesnt have correct <br>3D-Accelleration any more (was/is the ca=
se with NVIDIA and ATI, Windows XP and <br>Windows7 )<br><br>So - to summar=
ize: It works easiest and most featureful with a ATI Card; <br>&nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; It may work with patches and only with WindowsXP <br>with an NVI=
DIA card<br><br>To me it seems that unless someone finds an general approac=
h to runtime-detect <br>the NVIDIA-Secific stuff , submitting any patches m=
ay be to early, as it arouses <br>expectations which only in some cases wil=
l be met.<br><br>That said - i gladly can forward-port these old patches, i=
f you think they are <br>helping in any way.<br><br>Greetings!<br>Tobias<br=
><br>Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian
 Campbell:<br>&gt; Please do not a) top-post or b) cross-post. The latter b=
eing aimed at<br>&gt; whoever started this thread.<br>&gt; <br>&gt; On Mon,=
 2012-01-23 at 11:25 +0000, Sandi Romih wrote:<br>&gt; &gt; Yeah, I guess x=
en has generally been focused on the server end.<br>&gt; <br>&gt; Xen is fo=
cused on whatever people submit patches to do. Many of the core<br>&gt; dev=
elopers are not currently looking at VGA passthrough, we have plenty<br>&gt=
; of stuff on our plates, but we are more than happy to review and accept<b=
r>&gt; patches to implement/improve/fix this feature if only those people w=
ho<br>&gt; are interested in it would take the time to submit them per<br>&=
gt; <a href=3D"http://wiki.xen.org/wiki/SubmittingXenPatches" target=3D"_bl=
ank">http://wiki.xen.org/wiki/SubmittingXenPatches</a> . I'm afraid we are =
not<br>&gt; going to go out hunting for patches on the Internet.<br>&gt; <b=
r>&gt; David Techer recently offered to do this but perhaps he would
 be<br>&gt; interested in some help from you?<br>&gt; <br>&gt; Ian.<br>&gt;=
 <br>&gt; <br>&gt; <br>&gt; <br>&gt; ______________________________________=
_________<br>&gt; Xen-devel mailing list<br>&gt; <a ymailto=3D"mailto:Xen-d=
evel@lists.xensource.com" href=3D"mailto:Xen-devel@lists.xensource.com">Xen=
-devel@lists.xensource.com</a><br>&gt; <a href=3D"http://lists.xensource.co=
m/xen-devel" target=3D"_blank">http://lists.xensource.com/xen-devel</a><br>=
<br><br>_______________________________________________<br>Xen-devel mailin=
g list<br><a ymailto=3D"mailto:Xen-devel@lists.xensource.com" href=3D"mailt=
o:Xen-devel@lists.xensource.com">Xen-devel@lists.xensource.com</a><br><a hr=
ef=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://lists.=
xensource.com/xen-devel</a><br><br><br> </div> </div>  </div></body></html>
--437598848-1604741253-1327333409=:8800--


--===============4389060528686486254==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4389060528686486254==--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 15:46:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpM66-0007Qm-1c; Mon, 23 Jan 2012 15:46:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RpM64-0007QO-L9
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:46:16 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327333569!8263500!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMwODI0Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19085 invoked from network); 23 Jan 2012 15:46:10 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 15:46:10 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q0NFk4AP013919;
	Mon, 23 Jan 2012 16:46:04 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NFk2Lt026513;
	Mon, 23 Jan 2012 16:46:02 +0100
Message-ID: <4F1D80BA.1040504@siemens.com>
Date: Mon, 23 Jan 2012 16:46:02 +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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 15:46, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-23 12:59, Stefano Stabellini wrote:
>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>>>> Or what is the ordering
>>>>>> of init, RAM restore, and initial device reset now?
>>>>>
>>>>> RAM restore (done by Xen)
>>>>>
>>>>> physmap rebuild (done by xen_hvm_init in qemu)
>>>>> pc_init()
>>>>> qemu_system_reset()
>>>>> load_vmstate()
>>>>
>>>> Hmm, are you sure that this is the only case where a device init or
>>>> reset handler writes to already restored guest memory? Preloading the
>>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
>>>> fragile. Does restoring happen before QEMU is even started, or can this
>>>> point be controlled from QEMU?
>>>
>>> Consider that this only happens with non-MMIO device memory, in practice
>>> only videoram.
>>> Vmware VGA does not memset the videoram in the reset handler, while QXL
>>> already has the following:
>>>
>>>     /* pre loadvm reset must not touch QXLRam.  This lives in
>>>      * device memory, is migrated together with RAM and thus
>>>      * already loaded at this point */
>>>     if (!loadvm) {
>>>         qxl_reset_state(d);
>>>     }
>>
>> Yes, but QEMU restores the RAM _after_ device reset, not before it.
>> That's the problem with the Xen way - it is against the current QEMU
>> standard.
> 
> QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.

But it does otherwise, and that's the scenario the code you cited was
written for. It won't work as is under Xen.

> 
> To reply to your previous question more clearly: at restore time Qemu on
> Xen would run in a non-standard scenario; the restore of the RAM happens
> before QEMU is even started.
> 
> That is unfortunate but it would be very hard to change (I can give you
> more details if you are interested in the reasons why it would be so
> difficult).

If you can't change this, you need to properly introduce this new
scenario - pre-initialized RAM - to the QEMU device model. Or you will
see breakage outside cirrus sooner or later as well. So it might be good
to explain the reason why it can't be changed under Xen when motivating
this concept extension to QEMU.

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 Jan 23 15:46:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:46:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpM66-0007Qm-1c; Mon, 23 Jan 2012 15:46:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RpM64-0007QO-L9
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:46:16 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327333569!8263500!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMwODI0Ng==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19085 invoked from network); 23 Jan 2012 15:46:10 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 15:46:10 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q0NFk4AP013919;
	Mon, 23 Jan 2012 16:46:04 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NFk2Lt026513;
	Mon, 23 Jan 2012 16:46:02 +0100
Message-ID: <4F1D80BA.1040504@siemens.com>
Date: Mon, 23 Jan 2012 16:46:02 +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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 15:46, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-23 12:59, Stefano Stabellini wrote:
>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>>>> Or what is the ordering
>>>>>> of init, RAM restore, and initial device reset now?
>>>>>
>>>>> RAM restore (done by Xen)
>>>>>
>>>>> physmap rebuild (done by xen_hvm_init in qemu)
>>>>> pc_init()
>>>>> qemu_system_reset()
>>>>> load_vmstate()
>>>>
>>>> Hmm, are you sure that this is the only case where a device init or
>>>> reset handler writes to already restored guest memory? Preloading the
>>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
>>>> fragile. Does restoring happen before QEMU is even started, or can this
>>>> point be controlled from QEMU?
>>>
>>> Consider that this only happens with non-MMIO device memory, in practice
>>> only videoram.
>>> Vmware VGA does not memset the videoram in the reset handler, while QXL
>>> already has the following:
>>>
>>>     /* pre loadvm reset must not touch QXLRam.  This lives in
>>>      * device memory, is migrated together with RAM and thus
>>>      * already loaded at this point */
>>>     if (!loadvm) {
>>>         qxl_reset_state(d);
>>>     }
>>
>> Yes, but QEMU restores the RAM _after_ device reset, not before it.
>> That's the problem with the Xen way - it is against the current QEMU
>> standard.
> 
> QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.

But it does otherwise, and that's the scenario the code you cited was
written for. It won't work as is under Xen.

> 
> To reply to your previous question more clearly: at restore time Qemu on
> Xen would run in a non-standard scenario; the restore of the RAM happens
> before QEMU is even started.
> 
> That is unfortunate but it would be very hard to change (I can give you
> more details if you are interested in the reasons why it would be so
> difficult).

If you can't change this, you need to properly introduce this new
scenario - pre-initialized RAM - to the QEMU device model. Or you will
see breakage outside cirrus sooner or later as well. So it might be good
to explain the reason why it can't be changed under Xen when motivating
this concept extension to QEMU.

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 Jan 23 15:59:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMIT-0007nG-IU; Mon, 23 Jan 2012 15:59:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RpMIS-0007n9-7K
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:59:04 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327334336!10348347!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24196 invoked from network); 23 Jan 2012 15:58:57 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 15:58:57 -0000
Received: by ghbf1 with SMTP id f1so43574992ghb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 07:58:56 -0800 (PST)
Received: by 10.50.170.35 with SMTP id aj3mr10483313igc.2.1327334335859;
	Mon, 23 Jan 2012 07:58: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 f8sm48295770ibl.6.2012.01.23.07.58.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 07:58:54 -0800 (PST)
Message-ID: <4F1D83BB.8070209@codemonkey.ws>
Date: Mon, 23 Jan 2012 09:58:51 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<1327080085-8673-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327080085-8673-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQkh8qNLzSdPfLXlO4KbKuJ3ezZbQn/G125Bb3GE1ItUDmEavDYcrply/WRJgz16mq20GAIH
Cc: Anthony PERARD <anthony.perard@citrix.com>, jan.kiszka@siemens.com,
	xen-devel@lists.xensource.com, avi@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v4 1/6] vl.c: do not save the RAM state when
	Xen is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/20/2012 11:21 AM, Stefano Stabellini wrote:
> From: Anthony PERARD<anthony.perard@citrix.com>
>
> In the 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>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   vl.c |    6 ++++--
>   1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index ba55b35..6f0435b 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3270,8 +3270,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 not introduce new Xen specific commands like I suggested on IRC?

This sort of change is extremely non-intuitive.  We should do as much as we can 
to avoid magic #ifdefs like this.

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 Mon Jan 23 15:59:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 15:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMIT-0007nG-IU; Mon, 23 Jan 2012 15:59:05 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RpMIS-0007n9-7K
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 15:59:04 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327334336!10348347!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24196 invoked from network); 23 Jan 2012 15:58:57 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 15:58:57 -0000
Received: by ghbf1 with SMTP id f1so43574992ghb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 07:58:56 -0800 (PST)
Received: by 10.50.170.35 with SMTP id aj3mr10483313igc.2.1327334335859;
	Mon, 23 Jan 2012 07:58: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 f8sm48295770ibl.6.2012.01.23.07.58.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 07:58:54 -0800 (PST)
Message-ID: <4F1D83BB.8070209@codemonkey.ws>
Date: Mon, 23 Jan 2012 09:58:51 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<1327080085-8673-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327080085-8673-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Gm-Message-State: ALoCoQkh8qNLzSdPfLXlO4KbKuJ3ezZbQn/G125Bb3GE1ItUDmEavDYcrply/WRJgz16mq20GAIH
Cc: Anthony PERARD <anthony.perard@citrix.com>, jan.kiszka@siemens.com,
	xen-devel@lists.xensource.com, avi@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v4 1/6] vl.c: do not save the RAM state when
	Xen is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/20/2012 11:21 AM, Stefano Stabellini wrote:
> From: Anthony PERARD<anthony.perard@citrix.com>
>
> In the 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>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   vl.c |    6 ++++--
>   1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index ba55b35..6f0435b 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3270,8 +3270,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 not introduce new Xen specific commands like I suggested on IRC?

This sort of change is extremely non-intuitive.  We should do as much as we can 
to avoid magic #ifdefs like this.

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 Mon Jan 23 16:01:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMKA-0008Gz-4H; Mon, 23 Jan 2012 16:00:50 +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 1RpMK8-0008Gp-VJ
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:00:49 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327334441!12000914!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28519 invoked from network); 23 Jan 2012 16:00:42 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:00:42 -0000
Received: by iaeh11 with SMTP id h11so20153884iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 08:00:41 -0800 (PST)
Received: by 10.50.196.228 with SMTP id ip4mr10411344igc.28.1327334440917;
	Mon, 23 Jan 2012 08:00:40 -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 kh9sm5190990igc.1.2012.01.23.08.00.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 08:00:39 -0800 (PST)
Message-ID: <4F1D8423.2090603@codemonkey.ws>
Date: Mon, 23 Jan 2012 10:00:35 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
X-Gm-Message-State: ALoCoQkqvfKEzlRIUsdlKep/RLNiwmUyeYrSfuXvL5AD34DKZy+/ruhq+1XnEtXkv8Cvi9xSo2mi
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 04:47 AM, Stefano Stabellini wrote:
> On Fri, 20 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-20 18:20, Stefano Stabellini wrote:
>>> Hi all,
>>> this is the fourth version of the Xen save/restore patch series.
>>> We have been discussing this issue for quite a while on #qemu and
>>> qemu-devel:
>>>
>>>
>>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
>>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
>>>
>>>
>>> A few different approaches were proposed to achieve the goal
>>> of a working save/restore with upstream Qemu on Xen, however after
>>> prototyping some of them I came up with yet another solution, that I
>>> think leads to the best results with the less amount of code
>>> duplications and ugliness.
>>> Far from saying that this patch series is an example of elegance and
>>> simplicity, but it is closer to acceptable anything else I have seen so
>>> far.
>>>
>>> What's new is that Qemu is going to keep track of its own physmap on
>>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
>>> the guest's memory map at any time.
>>> This is all handled by Xen or Xen support in Qemu internally and can be
>>> used to solve our save/restore framebuffer problem.
>>>
>>> > From the Qemu common code POV, we still need to avoid saving the guest's
>>> ram when running on Xen, and we need to avoid resetting the videoram on
>>> restore (that is a benefit to the generic Qemu case too, because it
>>> saves few cpu cycles).
>>
>> For my understanding: Refraining from the memset is required as the
>> already restored vram would then be overwritten?
>
> Yep
>
>> Or what is the ordering
>> of init, RAM restore, and initial device reset now?
>
> RAM restore (done by Xen)
>
> physmap rebuild (done by xen_hvm_init in qemu)
> pc_init()
> qemu_system_reset()
> load_vmstate()

That's your problem.  You don't want to do load_vmstate().  You just want to 
load the device model, not RAM.

You should have a separate load_device_state() function and mark anything that 
is RAM as RAM when doing savevm registration.  Better yet, mark devices as 
devices since that's what you really care about.

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 Jan 23 16:01:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:01:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMKA-0008Gz-4H; Mon, 23 Jan 2012 16:00:50 +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 1RpMK8-0008Gp-VJ
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:00:49 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327334441!12000914!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28519 invoked from network); 23 Jan 2012 16:00:42 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:00:42 -0000
Received: by iaeh11 with SMTP id h11so20153884iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 08:00:41 -0800 (PST)
Received: by 10.50.196.228 with SMTP id ip4mr10411344igc.28.1327334440917;
	Mon, 23 Jan 2012 08:00:40 -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 kh9sm5190990igc.1.2012.01.23.08.00.38
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 08:00:39 -0800 (PST)
Message-ID: <4F1D8423.2090603@codemonkey.ws>
Date: Mon, 23 Jan 2012 10:00:35 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
X-Gm-Message-State: ALoCoQkqvfKEzlRIUsdlKep/RLNiwmUyeYrSfuXvL5AD34DKZy+/ruhq+1XnEtXkv8Cvi9xSo2mi
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 04:47 AM, Stefano Stabellini wrote:
> On Fri, 20 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-20 18:20, Stefano Stabellini wrote:
>>> Hi all,
>>> this is the fourth version of the Xen save/restore patch series.
>>> We have been discussing this issue for quite a while on #qemu and
>>> qemu-devel:
>>>
>>>
>>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
>>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
>>>
>>>
>>> A few different approaches were proposed to achieve the goal
>>> of a working save/restore with upstream Qemu on Xen, however after
>>> prototyping some of them I came up with yet another solution, that I
>>> think leads to the best results with the less amount of code
>>> duplications and ugliness.
>>> Far from saying that this patch series is an example of elegance and
>>> simplicity, but it is closer to acceptable anything else I have seen so
>>> far.
>>>
>>> What's new is that Qemu is going to keep track of its own physmap on
>>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
>>> the guest's memory map at any time.
>>> This is all handled by Xen or Xen support in Qemu internally and can be
>>> used to solve our save/restore framebuffer problem.
>>>
>>> > From the Qemu common code POV, we still need to avoid saving the guest's
>>> ram when running on Xen, and we need to avoid resetting the videoram on
>>> restore (that is a benefit to the generic Qemu case too, because it
>>> saves few cpu cycles).
>>
>> For my understanding: Refraining from the memset is required as the
>> already restored vram would then be overwritten?
>
> Yep
>
>> Or what is the ordering
>> of init, RAM restore, and initial device reset now?
>
> RAM restore (done by Xen)
>
> physmap rebuild (done by xen_hvm_init in qemu)
> pc_init()
> qemu_system_reset()
> load_vmstate()

That's your problem.  You don't want to do load_vmstate().  You just want to 
load the device model, not RAM.

You should have a separate load_device_state() function and mark anything that 
is RAM as RAM when doing savevm registration.  Better yet, mark devices as 
devices since that's what you really care about.

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 Jan 23 16:02:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpMLK-0008MR-Px; Mon, 23 Jan 2012 16:02:02 +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 1RpMLH-0008Lo-FW
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:01:59 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327334511!12195206!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14680 invoked from network); 23 Jan 2012 16:01:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:01:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; 
	d="diff'?scan'208";a="21179406"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:01:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:01:27 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0NG1O0g031945;
	Mon, 23 Jan 2012 08:01:25 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F1D7702020000780006E6C2@nat28.tlf.novell.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
	<4F1D7702020000780006E6C2@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="=-6/O2dNGlmLiyevdn29Z7"
Date: Mon, 23 Jan 2012 16:01:22 +0000
Message-ID: <1327334483.26455.260.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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

--=-6/O2dNGlmLiyevdn29Z7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Mon, 2012-01-23 at 14:04 +0000, Jan Beulich wrote:
> >>> On 23.01.12 at 11:47, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 23.01.12 at 11:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> On Mon, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
> >>> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
> >>> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
> >>> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
> >>> > @@ -68,7 +68,7 @@ struct event_log {
> >>> >   };
> >>> > 
> >>> >   /* PC value that indicates a special code */
> >>> > -#define XENOPROF_ESCAPE_CODE ~0UL
> >>> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
> >>> 
> >>> You cannot just go and change a public definition, as the consuming
> >>> side will break. You need to introduce a new escape code, and
> >>> provide a mechanism to negotiate (between hypervisor and kernel)
> >>> which one to use.
> >> 
> >> This seems more like a bug fix to me than an interface change, the fact
> >> that both producer and consumer had the bug notwithstanding.
> >> 
> >> Since this is a developer oriented interface I think we can be a little
> >> more relaxed than we would be for other interface changes. In this case
> >> we are fixing 32on64 (quite common) at the expense of 32on32 (very
> >> uncommon these days, especially for the suybset of developers wanting to
> >> do profiling) and leaving 64on64 (quite common) as it is . That seems
> >> like a worthwhile tradeoff to me.
> > 
> > I see your point. However, I'd still like to be careful with this - what
> > we think things ought to be used for doesn't necessarily cover all
> > cases that they are in reality.
> 
> I see that it got applied unchanged. It introduces two warnings in
> the 32-bit build, which not only fails that build, but also indicates
> that the situation likely wasn't fully analyzed.

The attached patch fixes the build (with the original patch un-reverted
of course), by making the internal calls explicitly take 64-bit values
for eip, rather than "unsigned long".  Will that suffice?

 -George

--=-6/O2dNGlmLiyevdn29Z7
Content-Disposition: attachment; filename="xenoprof-explicit-u64.diff"
Content-Type: text/x-patch; name="xenoprof-explicit-u64.diff";
	charset="UTF-8"
Content-Transfer-Encoding: 7bit

xenoprof: Use uint64_t explicitly for internal calls

A recent changeset to make XENOPROF_ESCAPE_CODE consistent across
32- and 64-bit builds caused a build failure, because values were
passed through functions as "unsigned long".  Replace these with
uint64_t explicitly.

Also remove redundant function prototype from perfmon.c, now that
it's in a header file.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 137c16a83e40 xen/arch/ia64/xen/oprofile/perfmon.c
--- a/xen/arch/ia64/xen/oprofile/perfmon.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/arch/ia64/xen/oprofile/perfmon.c	Mon Jan 23 15:58:36 2012 +0000
@@ -38,8 +38,6 @@
 #include <asm/vmx.h>    /* for vmx_user_mode() */
 
 // XXX move them to an appropriate header file
-extern void xenoprof_log_event(struct vcpu *vcpu, struct pt_regs * regs,
-                               unsigned long eip, int mode, int event);
 extern int is_active(struct domain *d);
 
 static int allow_virq;
diff -r 137c16a83e40 xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/xenoprof.c	Mon Jan 23 15:58:36 2012 +0000
@@ -475,7 +475,7 @@ static int xenoprof_buf_space(struct dom
 
 /* Check for space and add a sample. Return 1 if successful, 0 otherwise. */
 static int xenoprof_add_sample(struct domain *d, xenoprof_buf_t *buf,
-                               unsigned long eip, int mode, int event)
+                               uint64_t eip, int mode, int event)
 {
     int head, tail, size;
 
@@ -512,7 +512,7 @@ static int xenoprof_add_sample(struct do
 }
 
 int xenoprof_add_trace(struct domain *d, struct vcpu *vcpu,
-                       unsigned long eip, int mode)
+                       uint64_t eip, int mode)
 {
     xenoprof_buf_t *buf = d->xenoprof->vcpu[vcpu->vcpu_id].buffer;
 
@@ -527,7 +527,7 @@ int xenoprof_add_trace(struct domain *d,
 }
 
 void xenoprof_log_event(struct vcpu *vcpu, 
-                        struct cpu_user_regs * regs, unsigned long eip, 
+                        struct cpu_user_regs * regs, uint64_t eip, 
                         int mode, int event)
 {
     struct domain *d = vcpu->domain;
diff -r 137c16a83e40 xen/include/xen/xenoprof.h
--- a/xen/include/xen/xenoprof.h	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/include/xen/xenoprof.h	Mon Jan 23 15:58:36 2012 +0000
@@ -69,7 +69,7 @@ int is_passive(struct domain *d);
 void free_xenoprof_pages(struct domain *d);
 
 int xenoprof_add_trace(struct domain *d, struct vcpu *v, 
-                       unsigned long eip, int mode);
+                       uint64_t eip, int mode);
 
 #define PMU_OWNER_NONE          0
 #define PMU_OWNER_XENOPROF      1
@@ -78,7 +78,7 @@ int acquire_pmu_ownship(int pmu_ownershi
 void release_pmu_ownship(int pmu_ownership);
 
 void xenoprof_log_event(struct vcpu *vcpu,
-                        struct cpu_user_regs * regs, unsigned long eip,
+                        struct cpu_user_regs * regs, uint64_t eip,
                         int mode, int event);
 
 #endif  /* __XEN__XENOPROF_H__ */

--=-6/O2dNGlmLiyevdn29Z7
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=-6/O2dNGlmLiyevdn29Z7--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:02:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpMLK-0008MR-Px; Mon, 23 Jan 2012 16:02:02 +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 1RpMLH-0008Lo-FW
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:01:59 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327334511!12195206!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14680 invoked from network); 23 Jan 2012 16:01:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:01:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; 
	d="diff'?scan'208";a="21179406"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:01:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:01:27 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0NG1O0g031945;
	Mon, 23 Jan 2012 08:01:25 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F1D7702020000780006E6C2@nat28.tlf.novell.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
	<4F1D7702020000780006E6C2@nat28.tlf.novell.com>
Content-Type: multipart/mixed; boundary="=-6/O2dNGlmLiyevdn29Z7"
Date: Mon, 23 Jan 2012 16:01:22 +0000
Message-ID: <1327334483.26455.260.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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

--=-6/O2dNGlmLiyevdn29Z7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On Mon, 2012-01-23 at 14:04 +0000, Jan Beulich wrote:
> >>> On 23.01.12 at 11:47, "Jan Beulich" <JBeulich@suse.com> wrote:
> >>>> On 23.01.12 at 11:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> On Mon, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
> >>> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
> >>> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
> >>> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
> >>> > @@ -68,7 +68,7 @@ struct event_log {
> >>> >   };
> >>> > 
> >>> >   /* PC value that indicates a special code */
> >>> > -#define XENOPROF_ESCAPE_CODE ~0UL
> >>> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
> >>> 
> >>> You cannot just go and change a public definition, as the consuming
> >>> side will break. You need to introduce a new escape code, and
> >>> provide a mechanism to negotiate (between hypervisor and kernel)
> >>> which one to use.
> >> 
> >> This seems more like a bug fix to me than an interface change, the fact
> >> that both producer and consumer had the bug notwithstanding.
> >> 
> >> Since this is a developer oriented interface I think we can be a little
> >> more relaxed than we would be for other interface changes. In this case
> >> we are fixing 32on64 (quite common) at the expense of 32on32 (very
> >> uncommon these days, especially for the suybset of developers wanting to
> >> do profiling) and leaving 64on64 (quite common) as it is . That seems
> >> like a worthwhile tradeoff to me.
> > 
> > I see your point. However, I'd still like to be careful with this - what
> > we think things ought to be used for doesn't necessarily cover all
> > cases that they are in reality.
> 
> I see that it got applied unchanged. It introduces two warnings in
> the 32-bit build, which not only fails that build, but also indicates
> that the situation likely wasn't fully analyzed.

The attached patch fixes the build (with the original patch un-reverted
of course), by making the internal calls explicitly take 64-bit values
for eip, rather than "unsigned long".  Will that suffice?

 -George

--=-6/O2dNGlmLiyevdn29Z7
Content-Disposition: attachment; filename="xenoprof-explicit-u64.diff"
Content-Type: text/x-patch; name="xenoprof-explicit-u64.diff";
	charset="UTF-8"
Content-Transfer-Encoding: 7bit

xenoprof: Use uint64_t explicitly for internal calls

A recent changeset to make XENOPROF_ESCAPE_CODE consistent across
32- and 64-bit builds caused a build failure, because values were
passed through functions as "unsigned long".  Replace these with
uint64_t explicitly.

Also remove redundant function prototype from perfmon.c, now that
it's in a header file.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 137c16a83e40 xen/arch/ia64/xen/oprofile/perfmon.c
--- a/xen/arch/ia64/xen/oprofile/perfmon.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/arch/ia64/xen/oprofile/perfmon.c	Mon Jan 23 15:58:36 2012 +0000
@@ -38,8 +38,6 @@
 #include <asm/vmx.h>    /* for vmx_user_mode() */
 
 // XXX move them to an appropriate header file
-extern void xenoprof_log_event(struct vcpu *vcpu, struct pt_regs * regs,
-                               unsigned long eip, int mode, int event);
 extern int is_active(struct domain *d);
 
 static int allow_virq;
diff -r 137c16a83e40 xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/common/xenoprof.c	Mon Jan 23 15:58:36 2012 +0000
@@ -475,7 +475,7 @@ static int xenoprof_buf_space(struct dom
 
 /* Check for space and add a sample. Return 1 if successful, 0 otherwise. */
 static int xenoprof_add_sample(struct domain *d, xenoprof_buf_t *buf,
-                               unsigned long eip, int mode, int event)
+                               uint64_t eip, int mode, int event)
 {
     int head, tail, size;
 
@@ -512,7 +512,7 @@ static int xenoprof_add_sample(struct do
 }
 
 int xenoprof_add_trace(struct domain *d, struct vcpu *vcpu,
-                       unsigned long eip, int mode)
+                       uint64_t eip, int mode)
 {
     xenoprof_buf_t *buf = d->xenoprof->vcpu[vcpu->vcpu_id].buffer;
 
@@ -527,7 +527,7 @@ int xenoprof_add_trace(struct domain *d,
 }
 
 void xenoprof_log_event(struct vcpu *vcpu, 
-                        struct cpu_user_regs * regs, unsigned long eip, 
+                        struct cpu_user_regs * regs, uint64_t eip, 
                         int mode, int event)
 {
     struct domain *d = vcpu->domain;
diff -r 137c16a83e40 xen/include/xen/xenoprof.h
--- a/xen/include/xen/xenoprof.h	Mon Jan 23 09:42:12 2012 +0000
+++ b/xen/include/xen/xenoprof.h	Mon Jan 23 15:58:36 2012 +0000
@@ -69,7 +69,7 @@ int is_passive(struct domain *d);
 void free_xenoprof_pages(struct domain *d);
 
 int xenoprof_add_trace(struct domain *d, struct vcpu *v, 
-                       unsigned long eip, int mode);
+                       uint64_t eip, int mode);
 
 #define PMU_OWNER_NONE          0
 #define PMU_OWNER_XENOPROF      1
@@ -78,7 +78,7 @@ int acquire_pmu_ownship(int pmu_ownershi
 void release_pmu_ownship(int pmu_ownership);
 
 void xenoprof_log_event(struct vcpu *vcpu,
-                        struct cpu_user_regs * regs, unsigned long eip,
+                        struct cpu_user_regs * regs, uint64_t eip,
                         int mode, int event);
 
 #endif  /* __XEN__XENOPROF_H__ */

--=-6/O2dNGlmLiyevdn29Z7
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=-6/O2dNGlmLiyevdn29Z7--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:05:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMOl-0000BJ-K3; Mon, 23 Jan 2012 16:05:35 +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 1RpMOj-0000At-OY
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:05:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327334726!8482054!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25231 invoked from network); 23 Jan 2012 16:05:27 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-15.tower-174.messagelabs.com with SMTP;
	23 Jan 2012 16:05:27 -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
	q0NG5OfV024610; Mon, 23 Jan 2012 16:05: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 q0NG5OnO000514; 
	Mon, 23 Jan 2012 11:05:24 -0500
Message-ID: <4F1D8544.8050102@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 11:05:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
	<1327322464.24561.101.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327322464.24561.101.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/21] mini-os: create app-specific
	configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/23/2012 07:41 AM, Ian Campbell wrote:
> On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
>> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
>> code, create CONFIG_ items for features and use application-specific
>> configuration files to enable or disable the features.
>>
>> The configuration flags are currently added to the compiler command
>> line; as the number of flags grows this may need to move to a header.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  extras/mini-os/Makefile       |   15 +++++++++------
>>  extras/mini-os/apps/common.mk |   11 +++++++++++
>>  extras/mini-os/apps/grub.mk   |    2 ++
>>  extras/mini-os/apps/ioemu.mk  |    1 +
> 
> I think these should go under stubdom/xxx. You can simply pass in
> MINIOS_CONFIG as an absolute path and included it
> ifneq($(MINIOS_CONFIG),) instead of the ifeq($(stubdom),y) change you
> made.
> 

That location also looks nicer, but it will make it more likely that some
config file will be missed if the defaults are updated. Shouldn't be too
much of a problem, though - we only have 5 stubdom configs at the moment.

> 
>>  extras/mini-os/files.mk       |   28 ++++++++++++++++++++++++++++
>>  extras/mini-os/main.c         |   16 ++++++++--------
>>  extras/mini-os/minios.mk      |    4 ++--
>>  stubdom/Makefile              |    8 ++++----
>>  8 files changed, 65 insertions(+), 20 deletions(-)
>>  create mode 100644 extras/mini-os/apps/common.mk
>>  create mode 100644 extras/mini-os/apps/grub.mk
>>  create mode 100644 extras/mini-os/apps/ioemu.mk
>>  create mode 100644 extras/mini-os/files.mk
>>
>> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
>> index c2ee062..af7d0d4 100644
>> --- a/extras/mini-os/Makefile
>> +++ b/extras/mini-os/Makefile
>> @@ -8,7 +8,12 @@ export XEN_ROOT = $(CURDIR)/../..
>>  include $(XEN_ROOT)/Config.mk
>>  OBJ_DIR ?= $(CURDIR)
>>  
>> -ifneq ($(stubdom),y)
>> +ifeq ($(stubdom),y)
>> +-include apps/$(MINIOS_APP).mk
> 
> If you do as I suggest above this can become an unconditional include.
> 
>> +include apps/common.mk
> 
> Probably the app-specific mk should include this if it wants it, or just
> inline in each app config since I think the contents being common is
> more a coincidence than anything else.
> 
>> +EXTRA_DEPS += $(wildcard $(CURDIR)/apps/$(MINIOS_APP).mk)
>> +EXTRA_DEPS += $(CURDIR)/apps/common.mk
>> +else
>>  include Config.mk
>>  endif
>>  
>> @@ -34,13 +39,11 @@ TARGET := mini-os
>>  # Subdirectories common to mini-os
>>  SUBDIRS := lib xenbus console
>>  
>> +include files.mk
> 
> I don't think moving this out of line is necessary, the pattern in moast
> of our makefiles is to have the obj-(YN) stuff inline in the Makefiles.

OK, I wasn't sure how this Makefile was intended split up (it has some logic
in minios.mk that seemed related).
 
>> +
>>  # The common mini-os objects to build.
>>  APP_OBJS :=
>> -OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
>> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
>> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
>> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
>> -
>> +OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
>>  
>>  .PHONY: default
>>  default: $(OBJ_DIR)/$(TARGET)
>> diff --git a/extras/mini-os/apps/common.mk b/extras/mini-os/apps/common.mk
>> new file mode 100644
>> index 0000000..12b686d
>> --- /dev/null
>> +++ b/extras/mini-os/apps/common.mk
>> @@ -0,0 +1,11 @@
>> +# Defaults
>> +CONFIG_START_NETWORK ?= y
>> +CONFIG_SPARSE_BSS ?= y
>> +
>> +# Export items as compiler directives
>> +flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
>> +flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
>> +flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
>> +
>> +DEF_CFLAGS += $(flags-y)
> 
> I'd be inclined to put the CFLAGS stuff in the main makefile. It's not
> really "config" as such but part of the config system scaffolding.

Doing this would mostly eliminate common.mk - which sounds fine.

> [...]
>> diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
>> index b95b889..aeda548 100644
>> --- a/extras/mini-os/main.c
>> +++ b/extras/mini-os/main.c
>> @@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
>>  static void call_main(void *p)
>>  {
>>      char *c, quote;
>> -#ifdef CONFIG_QEMU
>> +#ifdef CONFIG_QEMU_XS_ARGS
>>      char *domargs, *msg;
>>  #endif
>>      int argc;
>>      char **argv;
>>      char *envp[] = { NULL };
>> -#ifdef CONFIG_QEMU
>> +#ifdef CONFIG_QEMU_XS_ARGS
> 
> If you allow for the "%s/image/dmargs" (not shown in the patch context)
> to come from a CONFIG_MUMBLE then this is no longer QEMU specific.

It's still mostly ioemu-specific, since we start by looking up a target
domain ID, convert it to a VM path, and then look for a path under there.
Making only the final path of /vm/UUID/image/dmargs configurable doesn't
sound as useful for a general case, and making the intermediate steps
configurable would be a mess.

>>      char *vm;
>>      char path[128];
>>      int domid;
>> @@ -60,15 +60,15 @@ static void call_main(void *p)
>>       * crashing. */
>>      //sleep(1);
>>  
>> -#ifndef CONFIG_GRUB
>> +#ifdef CONFIG_SPARSE_BSS
>>      sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
>> -#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
>> -    start_networking();
>>  #endif
>> +#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
> 
> In grub.mk (which I've already trimmed, oops) you have
> CONFIG_START_NETWORK=n
> which will pass that half of the test, which isn't what I think you
> wanted.
> 
> I've just noticed the same with the SPARSE_BSS option. Oh, and common.mk
> actually ends up unconditionally setting some vars too (using ?=).
> 
> I think a Linux style "# CONFIG_FOO is not set" would be better if you
> think it is necessary to explicitly list options we are not enabling.
> 
> Ian.
 
Actually, =n will result in the C symbol being undefined; the Makefile symbol
can't be undefined or the ?= used to set defaults will override it.

The other way I thought of doing it is to discard the defaults and add them to
each stubdom's configuration, but this seemed more prone to getting out of sync
when adding new configuration items.

-- 
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 Mon Jan 23 16:05:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:05:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMOl-0000BJ-K3; Mon, 23 Jan 2012 16:05:35 +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 1RpMOj-0000At-OY
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:05:34 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327334726!8482054!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25231 invoked from network); 23 Jan 2012 16:05:27 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-15.tower-174.messagelabs.com with SMTP;
	23 Jan 2012 16:05:27 -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
	q0NG5OfV024610; Mon, 23 Jan 2012 16:05: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 q0NG5OnO000514; 
	Mon, 23 Jan 2012 11:05:24 -0500
Message-ID: <4F1D8544.8050102@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 11:05:24 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
	<1327322464.24561.101.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327322464.24561.101.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/21] mini-os: create app-specific
	configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/23/2012 07:41 AM, Ian Campbell wrote:
> On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
>> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
>> code, create CONFIG_ items for features and use application-specific
>> configuration files to enable or disable the features.
>>
>> The configuration flags are currently added to the compiler command
>> line; as the number of flags grows this may need to move to a header.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  extras/mini-os/Makefile       |   15 +++++++++------
>>  extras/mini-os/apps/common.mk |   11 +++++++++++
>>  extras/mini-os/apps/grub.mk   |    2 ++
>>  extras/mini-os/apps/ioemu.mk  |    1 +
> 
> I think these should go under stubdom/xxx. You can simply pass in
> MINIOS_CONFIG as an absolute path and included it
> ifneq($(MINIOS_CONFIG),) instead of the ifeq($(stubdom),y) change you
> made.
> 

That location also looks nicer, but it will make it more likely that some
config file will be missed if the defaults are updated. Shouldn't be too
much of a problem, though - we only have 5 stubdom configs at the moment.

> 
>>  extras/mini-os/files.mk       |   28 ++++++++++++++++++++++++++++
>>  extras/mini-os/main.c         |   16 ++++++++--------
>>  extras/mini-os/minios.mk      |    4 ++--
>>  stubdom/Makefile              |    8 ++++----
>>  8 files changed, 65 insertions(+), 20 deletions(-)
>>  create mode 100644 extras/mini-os/apps/common.mk
>>  create mode 100644 extras/mini-os/apps/grub.mk
>>  create mode 100644 extras/mini-os/apps/ioemu.mk
>>  create mode 100644 extras/mini-os/files.mk
>>
>> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
>> index c2ee062..af7d0d4 100644
>> --- a/extras/mini-os/Makefile
>> +++ b/extras/mini-os/Makefile
>> @@ -8,7 +8,12 @@ export XEN_ROOT = $(CURDIR)/../..
>>  include $(XEN_ROOT)/Config.mk
>>  OBJ_DIR ?= $(CURDIR)
>>  
>> -ifneq ($(stubdom),y)
>> +ifeq ($(stubdom),y)
>> +-include apps/$(MINIOS_APP).mk
> 
> If you do as I suggest above this can become an unconditional include.
> 
>> +include apps/common.mk
> 
> Probably the app-specific mk should include this if it wants it, or just
> inline in each app config since I think the contents being common is
> more a coincidence than anything else.
> 
>> +EXTRA_DEPS += $(wildcard $(CURDIR)/apps/$(MINIOS_APP).mk)
>> +EXTRA_DEPS += $(CURDIR)/apps/common.mk
>> +else
>>  include Config.mk
>>  endif
>>  
>> @@ -34,13 +39,11 @@ TARGET := mini-os
>>  # Subdirectories common to mini-os
>>  SUBDIRS := lib xenbus console
>>  
>> +include files.mk
> 
> I don't think moving this out of line is necessary, the pattern in moast
> of our makefiles is to have the obj-(YN) stuff inline in the Makefiles.

OK, I wasn't sure how this Makefile was intended split up (it has some logic
in minios.mk that seemed related).
 
>> +
>>  # The common mini-os objects to build.
>>  APP_OBJS :=
>> -OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
>> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
>> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
>> -OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
>> -
>> +OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
>>  
>>  .PHONY: default
>>  default: $(OBJ_DIR)/$(TARGET)
>> diff --git a/extras/mini-os/apps/common.mk b/extras/mini-os/apps/common.mk
>> new file mode 100644
>> index 0000000..12b686d
>> --- /dev/null
>> +++ b/extras/mini-os/apps/common.mk
>> @@ -0,0 +1,11 @@
>> +# Defaults
>> +CONFIG_START_NETWORK ?= y
>> +CONFIG_SPARSE_BSS ?= y
>> +
>> +# Export items as compiler directives
>> +flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
>> +flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
>> +flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
>> +
>> +DEF_CFLAGS += $(flags-y)
> 
> I'd be inclined to put the CFLAGS stuff in the main makefile. It's not
> really "config" as such but part of the config system scaffolding.

Doing this would mostly eliminate common.mk - which sounds fine.

> [...]
>> diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
>> index b95b889..aeda548 100644
>> --- a/extras/mini-os/main.c
>> +++ b/extras/mini-os/main.c
>> @@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
>>  static void call_main(void *p)
>>  {
>>      char *c, quote;
>> -#ifdef CONFIG_QEMU
>> +#ifdef CONFIG_QEMU_XS_ARGS
>>      char *domargs, *msg;
>>  #endif
>>      int argc;
>>      char **argv;
>>      char *envp[] = { NULL };
>> -#ifdef CONFIG_QEMU
>> +#ifdef CONFIG_QEMU_XS_ARGS
> 
> If you allow for the "%s/image/dmargs" (not shown in the patch context)
> to come from a CONFIG_MUMBLE then this is no longer QEMU specific.

It's still mostly ioemu-specific, since we start by looking up a target
domain ID, convert it to a VM path, and then look for a path under there.
Making only the final path of /vm/UUID/image/dmargs configurable doesn't
sound as useful for a general case, and making the intermediate steps
configurable would be a mess.

>>      char *vm;
>>      char path[128];
>>      int domid;
>> @@ -60,15 +60,15 @@ static void call_main(void *p)
>>       * crashing. */
>>      //sleep(1);
>>  
>> -#ifndef CONFIG_GRUB
>> +#ifdef CONFIG_SPARSE_BSS
>>      sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
>> -#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
>> -    start_networking();
>>  #endif
>> +#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
> 
> In grub.mk (which I've already trimmed, oops) you have
> CONFIG_START_NETWORK=n
> which will pass that half of the test, which isn't what I think you
> wanted.
> 
> I've just noticed the same with the SPARSE_BSS option. Oh, and common.mk
> actually ends up unconditionally setting some vars too (using ?=).
> 
> I think a Linux style "# CONFIG_FOO is not set" would be better if you
> think it is necessary to explicitly list options we are not enabling.
> 
> Ian.
 
Actually, =n will result in the C symbol being undefined; the Makefile symbol
can't be undefined or the ?= used to set defaults will override it.

The other way I thought of doing it is to discard the defaults and add them to
each stubdom's configuration, but this seemed more prone to getting out of sync
when adding new configuration items.

-- 
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 Mon Jan 23 16:07:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:07:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMQM-0000K5-4C; Mon, 23 Jan 2012 16:07: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 1RpMQJ-0000JR-TG
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:07:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327334825!12002035!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19961 invoked from network); 23 Jan 2012 16:07:06 -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;
	23 Jan 2012 16:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10222725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:07: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, 23 Jan 2012 16:07:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 23 Jan 2012 16:07:05 +0000
In-Reply-To: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327334825.24561.150.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 13:19 +0000, Ian Campbell wrote:
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap)

I mistakenly thought the schedule rate fix had been committed. This
should be it's own top-level blocker IMHO.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:07:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:07:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMQM-0000K5-4C; Mon, 23 Jan 2012 16:07: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 1RpMQJ-0000JR-TG
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:07:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327334825!12002035!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19961 invoked from network); 23 Jan 2012 16:07:06 -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;
	23 Jan 2012 16:07:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10222725"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:07: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, 23 Jan 2012 16:07:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>, George Dunlap
	<George.Dunlap@eu.citrix.com>
Date: Mon, 23 Jan 2012 16:07:05 +0000
In-Reply-To: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327334825.24561.150.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 13:19 +0000, Ian Campbell wrote:
>       * domctls / sysctls set up to modify scheduler parameters, like
>         the credit1 timeslice and schedule rate. (George Dunlap)

I mistakenly thought the schedule rate fix had been committed. This
should be it's own top-level blocker IMHO.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMRu-0000Se-Kj; Mon, 23 Jan 2012 16:08:50 +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 1RpMRt-0000S8-U1
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:08:50 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327334922!12214405!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 10432 invoked from network); 23 Jan 2012 16:08:43 -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;
	23 Jan 2012 16:08:43 -0000
Received: by iaeh11 with SMTP id h11so20174970iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 08:08:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=opa3K8BN6JpFBX5ZBbedTi+Z1fdqZHm7I82WXbZi2RM=;
	b=UBnUodsx7Q6ek42SqEt503vOWojME+SQKAZZDRal0EnoNsThjgVcalGNqyi/It6pj0
	NQ3aR8HGpLjBIHRPEKFfEuNIU7hp6MXy46b2PqVoft0UXoX+j4ChJd4LU0/f7JyEihbW
	+0M0IJIn6FL9IpGOhtnRWg1bO8QSLg2sBn+HY=
MIME-Version: 1.0
Received: by 10.42.171.136 with SMTP id j8mr8433453icz.1.1327334922357; Mon,
	23 Jan 2012 08:08:42 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Mon, 23 Jan 2012 08:08:42 -0800 (PST)
In-Reply-To: <4F1D66D3020000780006E627@nat28.tlf.novell.com>
References: <5cf2063db3b5f6abe8c0.1327320737@nehalem1>
	<4F1D66D3020000780006E627@nat28.tlf.novell.com>
Date: Mon, 23 Jan 2012 16:08:42 +0000
X-Google-Sender-Auth: mSfPjDRs6uYO4FyBQhFt6pBbU2k
Message-ID: <CAFLBxZZYZgmGWHLQ_CPhAULAt8sjDmOo+yb7r7+3e-t0aWtQ2Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity (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="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, Jan 23, 2012 at 12:55 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.01.12 at 13:12, Juergen Gross <juergen.gross@ts.fujitsu.com> wro=
te:
>> - introduce and use common macros for selecting cpupool based cpumasks
>
> I had hoped that you would do this as a separate prerequisite patch,
> but that it's in here I think there's no need to break it up.

But it would be a lot easier to check the logic if the two patches
were separate; both now, and when someone in the future tries is doing
archaeology to figure out what's going on.  I won't NACK a patch that
has them together, but I would strongly encourage you make them two
patches. :-)

 -George

>
>>@@ -333,23 +334,38 @@ struct domain *domain_create(
>>
>> void domain_update_node_affinity(struct domain *d)
>> {
>>- =A0 =A0cpumask_t cpumask;
>>+ =A0 =A0cpumask_var_t cpumask;
>>+ =A0 =A0cpumask_var_t online_affinity;
>>+ =A0 =A0const cpumask_t *online;
>> =A0 =A0 nodemask_t nodemask =3D NODE_MASK_NONE;
>> =A0 =A0 struct vcpu *v;
>> =A0 =A0 unsigned int node;
>>
>>- =A0 =A0cpumask_clear(&cpumask);
>>+ =A0 =A0if (!zalloc_cpumask_var(&cpumask))
>>+ =A0 =A0 =A0 =A0return;
>>+ =A0 =A0if (!alloc_cpumask_var(&online_affinity))
>
> This doesn't get freed at the end of the function. Also, with the rest
> of the function being formatted properly, you ought to insert spaces
> after the initial and before the final parentheses of the if-s.
>
> Jan
>
>>+ =A0 =A0{
>>+ =A0 =A0 =A0 =A0free_cpumask_var(cpumask);
>>+ =A0 =A0 =A0 =A0return;
>>+ =A0 =A0}
>>+
>>+ =A0 =A0online =3D cpupool_online_cpumask(d->cpupool);
>> =A0 =A0 spin_lock(&d->node_affinity_lock);
>>
>> =A0 =A0 for_each_vcpu ( d, v )
>>- =A0 =A0 =A0 =A0cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
>>+ =A0 =A0{
>>+ =A0 =A0 =A0 =A0cpumask_and(online_affinity, v->cpu_affinity, online);
>>+ =A0 =A0 =A0 =A0cpumask_or(cpumask, cpumask, online_affinity);
>>+ =A0 =A0}
>>
>> =A0 =A0 for_each_online_node ( node )
>>- =A0 =A0 =A0 =A0if ( cpumask_intersects(&node_to_cpumask(node), &cpumask=
) )
>>+ =A0 =A0 =A0 =A0if ( cpumask_intersects(&node_to_cpumask(node), cpumask)=
 )
>> =A0 =A0 =A0 =A0 =A0 =A0 node_set(node, nodemask);
>>
>> =A0 =A0 d->node_affinity =3D nodemask;
>> =A0 =A0 spin_unlock(&d->node_affinity_lock);
>>+
>>+ =A0 =A0free_cpumask_var(cpumask);
>> }
>>
>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 23 16:09:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:09:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMRu-0000Se-Kj; Mon, 23 Jan 2012 16:08:50 +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 1RpMRt-0000S8-U1
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:08:50 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327334922!12214405!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 10432 invoked from network); 23 Jan 2012 16:08:43 -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;
	23 Jan 2012 16:08:43 -0000
Received: by iaeh11 with SMTP id h11so20174970iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 08:08:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=opa3K8BN6JpFBX5ZBbedTi+Z1fdqZHm7I82WXbZi2RM=;
	b=UBnUodsx7Q6ek42SqEt503vOWojME+SQKAZZDRal0EnoNsThjgVcalGNqyi/It6pj0
	NQ3aR8HGpLjBIHRPEKFfEuNIU7hp6MXy46b2PqVoft0UXoX+j4ChJd4LU0/f7JyEihbW
	+0M0IJIn6FL9IpGOhtnRWg1bO8QSLg2sBn+HY=
MIME-Version: 1.0
Received: by 10.42.171.136 with SMTP id j8mr8433453icz.1.1327334922357; Mon,
	23 Jan 2012 08:08:42 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Mon, 23 Jan 2012 08:08:42 -0800 (PST)
In-Reply-To: <4F1D66D3020000780006E627@nat28.tlf.novell.com>
References: <5cf2063db3b5f6abe8c0.1327320737@nehalem1>
	<4F1D66D3020000780006E627@nat28.tlf.novell.com>
Date: Mon, 23 Jan 2012 16:08:42 +0000
X-Google-Sender-Auth: mSfPjDRs6uYO4FyBQhFt6pBbU2k
Message-ID: <CAFLBxZZYZgmGWHLQ_CPhAULAt8sjDmOo+yb7r7+3e-t0aWtQ2Q@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Reflect cpupool in numa node affinity (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="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, Jan 23, 2012 at 12:55 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.01.12 at 13:12, Juergen Gross <juergen.gross@ts.fujitsu.com> wro=
te:
>> - introduce and use common macros for selecting cpupool based cpumasks
>
> I had hoped that you would do this as a separate prerequisite patch,
> but that it's in here I think there's no need to break it up.

But it would be a lot easier to check the logic if the two patches
were separate; both now, and when someone in the future tries is doing
archaeology to figure out what's going on.  I won't NACK a patch that
has them together, but I would strongly encourage you make them two
patches. :-)

 -George

>
>>@@ -333,23 +334,38 @@ struct domain *domain_create(
>>
>> void domain_update_node_affinity(struct domain *d)
>> {
>>- =A0 =A0cpumask_t cpumask;
>>+ =A0 =A0cpumask_var_t cpumask;
>>+ =A0 =A0cpumask_var_t online_affinity;
>>+ =A0 =A0const cpumask_t *online;
>> =A0 =A0 nodemask_t nodemask =3D NODE_MASK_NONE;
>> =A0 =A0 struct vcpu *v;
>> =A0 =A0 unsigned int node;
>>
>>- =A0 =A0cpumask_clear(&cpumask);
>>+ =A0 =A0if (!zalloc_cpumask_var(&cpumask))
>>+ =A0 =A0 =A0 =A0return;
>>+ =A0 =A0if (!alloc_cpumask_var(&online_affinity))
>
> This doesn't get freed at the end of the function. Also, with the rest
> of the function being formatted properly, you ought to insert spaces
> after the initial and before the final parentheses of the if-s.
>
> Jan
>
>>+ =A0 =A0{
>>+ =A0 =A0 =A0 =A0free_cpumask_var(cpumask);
>>+ =A0 =A0 =A0 =A0return;
>>+ =A0 =A0}
>>+
>>+ =A0 =A0online =3D cpupool_online_cpumask(d->cpupool);
>> =A0 =A0 spin_lock(&d->node_affinity_lock);
>>
>> =A0 =A0 for_each_vcpu ( d, v )
>>- =A0 =A0 =A0 =A0cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
>>+ =A0 =A0{
>>+ =A0 =A0 =A0 =A0cpumask_and(online_affinity, v->cpu_affinity, online);
>>+ =A0 =A0 =A0 =A0cpumask_or(cpumask, cpumask, online_affinity);
>>+ =A0 =A0}
>>
>> =A0 =A0 for_each_online_node ( node )
>>- =A0 =A0 =A0 =A0if ( cpumask_intersects(&node_to_cpumask(node), &cpumask=
) )
>>+ =A0 =A0 =A0 =A0if ( cpumask_intersects(&node_to_cpumask(node), cpumask)=
 )
>> =A0 =A0 =A0 =A0 =A0 =A0 node_set(node, nodemask);
>>
>> =A0 =A0 d->node_affinity =3D nodemask;
>> =A0 =A0 spin_unlock(&d->node_affinity_lock);
>>+
>>+ =A0 =A0free_cpumask_var(cpumask);
>> }
>>
>>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 23 16:16:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMYl-0000lL-IS; Mon, 23 Jan 2012 16:15: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 1RpMYk-0000lG-3Y
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:15:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327335295!53717412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31036 invoked from network); 23 Jan 2012 16:14: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;
	23 Jan 2012 16:14:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10222978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:15: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; Mon, 23 Jan 2012 16:15:48 +0000
Date: Mon, 23 Jan 2012 16:16:06 +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: <4F1D80BA.1040504@siemens.com>
Message-ID: <alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Jan Kiszka wrote:
> On 2012-01-23 15:46, Stefano Stabellini wrote:
> > On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >> On 2012-01-23 12:59, Stefano Stabellini wrote:
> >>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >>>>>> Or what is the ordering
> >>>>>> of init, RAM restore, and initial device reset now?
> >>>>>
> >>>>> RAM restore (done by Xen)
> >>>>>
> >>>>> physmap rebuild (done by xen_hvm_init in qemu)
> >>>>> pc_init()
> >>>>> qemu_system_reset()
> >>>>> load_vmstate()
> >>>>
> >>>> Hmm, are you sure that this is the only case where a device init or
> >>>> reset handler writes to already restored guest memory? Preloading the
> >>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
> >>>> fragile. Does restoring happen before QEMU is even started, or can this
> >>>> point be controlled from QEMU?
> >>>
> >>> Consider that this only happens with non-MMIO device memory, in practice
> >>> only videoram.
> >>> Vmware VGA does not memset the videoram in the reset handler, while QXL
> >>> already has the following:
> >>>
> >>>     /* pre loadvm reset must not touch QXLRam.  This lives in
> >>>      * device memory, is migrated together with RAM and thus
> >>>      * already loaded at this point */ if (!loadvm) {
> >>>      qxl_reset_state(d); }
> >>
> >> Yes, but QEMU restores the RAM _after_ device reset, not before it.
> >> That's the problem with the Xen way - it is against the current
> >> QEMU standard.
> > 
> > QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.
> 
> But it does otherwise, and that's the scenario the code you cited was
> written for. It won't work as is under Xen.

Ah, I see your point now.
In that regard, is the comment above even correct?
I am referring to "migrated together with RAM and thus already loaded at
this point"?


> > To reply to your previous question more clearly: at restore time Qemu on
> > Xen would run in a non-standard scenario; the restore of the RAM happens
> > before QEMU is even started.
> > 
> > That is unfortunate but it would be very hard to change (I can give you
> > more details if you are interested in the reasons why it would be so
> > difficult).
> 
> If you can't change this, you need to properly introduce this new
> scenario - pre-initialized RAM - to the QEMU device model. Or you will
> see breakage outside cirrus sooner or later as well. So it might be good
> to explain the reason why it can't be changed under Xen when motivating
> this concept extension to QEMU.
 
OK.
Are you thinking about introducing this concept as a new runstate?
This special runstate could be set at restore time only on Xen.


BTW the main reasons for having Xen saving the RAM are:

- the need to support PV guests, that often run without Qemu;
- the current save format, that is built around the fact that Xen saves the memory;
- the fact that Qemu might be running in a very limited stub-domain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:16:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:16:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMYl-0000lL-IS; Mon, 23 Jan 2012 16:15: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 1RpMYk-0000lG-3Y
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:15:54 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327335295!53717412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31036 invoked from network); 23 Jan 2012 16:14: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;
	23 Jan 2012 16:14:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10222978"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:15: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; Mon, 23 Jan 2012 16:15:48 +0000
Date: Mon, 23 Jan 2012 16:16:06 +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: <4F1D80BA.1040504@siemens.com>
Message-ID: <alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Jan Kiszka wrote:
> On 2012-01-23 15:46, Stefano Stabellini wrote:
> > On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >> On 2012-01-23 12:59, Stefano Stabellini wrote:
> >>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
> >>>>>> Or what is the ordering
> >>>>>> of init, RAM restore, and initial device reset now?
> >>>>>
> >>>>> RAM restore (done by Xen)
> >>>>>
> >>>>> physmap rebuild (done by xen_hvm_init in qemu)
> >>>>> pc_init()
> >>>>> qemu_system_reset()
> >>>>> load_vmstate()
> >>>>
> >>>> Hmm, are you sure that this is the only case where a device init or
> >>>> reset handler writes to already restored guest memory? Preloading the
> >>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
> >>>> fragile. Does restoring happen before QEMU is even started, or can this
> >>>> point be controlled from QEMU?
> >>>
> >>> Consider that this only happens with non-MMIO device memory, in practice
> >>> only videoram.
> >>> Vmware VGA does not memset the videoram in the reset handler, while QXL
> >>> already has the following:
> >>>
> >>>     /* pre loadvm reset must not touch QXLRam.  This lives in
> >>>      * device memory, is migrated together with RAM and thus
> >>>      * already loaded at this point */ if (!loadvm) {
> >>>      qxl_reset_state(d); }
> >>
> >> Yes, but QEMU restores the RAM _after_ device reset, not before it.
> >> That's the problem with the Xen way - it is against the current
> >> QEMU standard.
> > 
> > QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.
> 
> But it does otherwise, and that's the scenario the code you cited was
> written for. It won't work as is under Xen.

Ah, I see your point now.
In that regard, is the comment above even correct?
I am referring to "migrated together with RAM and thus already loaded at
this point"?


> > To reply to your previous question more clearly: at restore time Qemu on
> > Xen would run in a non-standard scenario; the restore of the RAM happens
> > before QEMU is even started.
> > 
> > That is unfortunate but it would be very hard to change (I can give you
> > more details if you are interested in the reasons why it would be so
> > difficult).
> 
> If you can't change this, you need to properly introduce this new
> scenario - pre-initialized RAM - to the QEMU device model. Or you will
> see breakage outside cirrus sooner or later as well. So it might be good
> to explain the reason why it can't be changed under Xen when motivating
> this concept extension to QEMU.
 
OK.
Are you thinking about introducing this concept as a new runstate?
This special runstate could be set at restore time only on Xen.


BTW the main reasons for having Xen saving the RAM are:

- the need to support PV guests, that often run without Qemu;
- the current save format, that is built around the fact that Xen saves the memory;
- the fact that Qemu might be running in a very limited stub-domain.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:22:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpMeX-00018f-HP; Mon, 23 Jan 2012 16:21: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 1RpMeV-00018R-Id
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:21:51 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327335704!10280523!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21975 invoked from network); 23 Jan 2012 16:21:44 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-174.messagelabs.com with SMTP;
	23 Jan 2012 16:21:44 -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
	q0NGLg3U006888; Mon, 23 Jan 2012 16:21:42 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 q0NGLgWQ001885; 
	Mon, 23 Jan 2012 11:21:42 -0500
Message-ID: <4F1D8916.3050409@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 11:21:42 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
	<1327323081.24561.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327323081.24561.108.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 07:51 AM, Ian Campbell wrote:
> On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
>> This adds compile-time logic to disable certain frontends in mini-os:
>>  - pcifront is disabled by default, enabled for ioemu
>>  - blkfront, netfront, fbfront, and kbdfront are enabled by default
>>  - xenbus is required for any frontend, and is enabled by default
>>
>> If all frontends and xenbus are disabled, mini-os will run without
>> needing to communicate with xenstore, making it suitable to run the
>> xenstore daemon.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  extras/mini-os/Makefile               |    5 +++-
>>  extras/mini-os/apps/common.mk         |   11 +++++++++
>>  extras/mini-os/apps/ioemu.mk          |    1 +
>>  extras/mini-os/console/xencons_ring.c |   15 ++++++++++--
>>  extras/mini-os/files.mk               |   12 +++++-----
>>  extras/mini-os/include/lib.h          |    2 +
>>  extras/mini-os/kernel.c               |   40 +++++++++++++++++++++++++++++++-
>>  extras/mini-os/lib/sys.c              |   28 +++++++++++++++++++++++
>>  extras/mini-os/main.c                 |    6 +++-
>>  9 files changed, 106 insertions(+), 14 deletions(-)
>>
>> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
>> index af7d0d4..7419211 100644
>> --- a/extras/mini-os/Makefile
>> +++ b/extras/mini-os/Makefile
>> @@ -70,7 +70,10 @@ ifeq ($(lwip),y)
>>  LWC    := $(shell find $(LWIPDIR)/ -type f -name '*.c')
>>  LWC    := $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
>>  LWO    := $(patsubst %.c,%.o,$(LWC))
>> -LWO    += $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
>> +LWO    += $(OBJ_DIR)/lwip-arch.o
>> +ifeq ($(CONFIG_NETFRONT),y)
>> +LWO += $(OBJ_DIR)/lwip-net.o
>> +endif
> 
> Without lwip-net.o is there any point in having the rest of LWO? Or does
> the linker optimise it all away anyway?
> 

Some of the other parts of LWO may be useful on their own, depending on the
application run under minios. The xenstored configuration disables all of
LWO, so this doesn't matter there; the vTPM stub domains (from patches sent
by Matthew Fioravante in March 2011) do use parts of LWO without needing 
netfront support, which prompted this configuration test.

> [...]
> 
>> diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
>> index af0afed..c3eba35 100644
>> --- a/extras/mini-os/console/xencons_ring.c
>> +++ b/extras/mini-os/console/xencons_ring.c
>> @@ -189,6 +189,7 @@ struct consfront_dev *xencons_ring_init(void)
>>
>>  void free_consfront(struct consfront_dev *dev)
>>  {
>> +#ifdef CONFIG_XENBUS
>>      char* err = NULL;
>>      XenbusState state;
>>
>> @@ -217,6 +218,7 @@ void free_consfront(struct consfront_dev *dev)
>>  close:
>>      if (err) free(err);
>>      xenbus_unwatch_path_token(XBT_NIL, path, path);
>> +#endif
>>
>>      mask_evtchn(dev->evtchn);
>>      unbind_evtchn(dev->evtchn);
>> @@ -231,16 +233,18 @@ close:
>>
>>  struct consfront_dev *init_consfront(char *_nodename)
>>  {
>> +    struct consfront_dev *dev;
>> +    char nodename[256];
>> +    static int consfrontends = 3;
>> +#ifdef CONFIG_XENBUS
>>      xenbus_transaction_t xbt;
>>      char* err;
>>      char* message=NULL;
>>      int retry=0;
>>      char* msg = NULL;
>> -    char nodename[256];
>>      char path[256];
>> -    static int consfrontends = 3;
>> -    struct consfront_dev *dev;
>>      int res;
>> +#endif
>>
>>      if (!_nodename)
>>          snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
>> @@ -257,6 +261,7 @@ struct consfront_dev *init_consfront(char *_nodename)
>>      dev->fd = -1;
>>  #endif
>>
>> +#ifdef CONFIG_XENBUS
>>      snprintf(path, sizeof(path), "%s/backend-id", nodename);
>>      if ((res = xenbus_read_integer(path)) < 0)
>>          return NULL;
>> @@ -351,17 +356,21 @@ done:
>>              goto error;
>>          }
>>      }
>> +#endif
> 
> Haven't you ifdef'd out everything which would have set dev->evtchn?

Hmm, I might have. Will address it in the cleanup from the second mail.

> 
> I'm not sure that the CONFIG_XENBUS is worthwhile, at least at the
> moment, and it seems to add an awful lot of ifdefery.
> 
> [...]
>> diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
>> index 2875bf1..9e490d5 100644
>> --- a/extras/mini-os/kernel.c
>> +++ b/extras/mini-os/kernel.c
>> [...]
>> @@ -462,11 +474,21 @@ __attribute__((weak)) int app_main(start_info_t *si)
>>      printk("Dummy main: start_info=%p\n", si);
>>      create_thread("xenbus_tester", xenbus_tester, si);
>>      create_thread("periodic_thread", periodic_thread, si);
>> +#ifdef CONFIG_NETFRONT
>>      create_thread("netfront", netfront_thread, si);
>> +#endif
> 
> Better to define init_FOOfront for each of these and have it be a nop in
> the ifndef case and avoid the ifdefs in the code itself.
> 
> Likewise the ifdef's in the teardown. Ideally the actual meat in the
> ifdef cases would be moved into the files you aren't compiling (e.g.
> netfront_thread goes into netfront.c) and only the stubs remain in some
> header somewhere.
> 
> Ian.
> 

The majority of kernel.c seems to be test code intended to be overridden
by the application; see the comment above app_main:

/* This should be overridden by the application we are linked against. */
__attribute__((weak)) int app_main(start_info_t *si)

As such, maybe all of this code should be moved out of kernel.c and into
test.c, and have a better noop app_main in kernel.c.

-- 
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 Mon Jan 23 16:22:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpMeX-00018f-HP; Mon, 23 Jan 2012 16:21: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 1RpMeV-00018R-Id
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:21:51 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327335704!10280523!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21975 invoked from network); 23 Jan 2012 16:21:44 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-174.messagelabs.com with SMTP;
	23 Jan 2012 16:21:44 -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
	q0NGLg3U006888; Mon, 23 Jan 2012 16:21:42 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 q0NGLgWQ001885; 
	Mon, 23 Jan 2012 11:21:42 -0500
Message-ID: <4F1D8916.3050409@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 11:21:42 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
	<1327323081.24561.108.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327323081.24561.108.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 07:51 AM, Ian Campbell wrote:
> On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
>> This adds compile-time logic to disable certain frontends in mini-os:
>>  - pcifront is disabled by default, enabled for ioemu
>>  - blkfront, netfront, fbfront, and kbdfront are enabled by default
>>  - xenbus is required for any frontend, and is enabled by default
>>
>> If all frontends and xenbus are disabled, mini-os will run without
>> needing to communicate with xenstore, making it suitable to run the
>> xenstore daemon.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  extras/mini-os/Makefile               |    5 +++-
>>  extras/mini-os/apps/common.mk         |   11 +++++++++
>>  extras/mini-os/apps/ioemu.mk          |    1 +
>>  extras/mini-os/console/xencons_ring.c |   15 ++++++++++--
>>  extras/mini-os/files.mk               |   12 +++++-----
>>  extras/mini-os/include/lib.h          |    2 +
>>  extras/mini-os/kernel.c               |   40 +++++++++++++++++++++++++++++++-
>>  extras/mini-os/lib/sys.c              |   28 +++++++++++++++++++++++
>>  extras/mini-os/main.c                 |    6 +++-
>>  9 files changed, 106 insertions(+), 14 deletions(-)
>>
>> diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
>> index af7d0d4..7419211 100644
>> --- a/extras/mini-os/Makefile
>> +++ b/extras/mini-os/Makefile
>> @@ -70,7 +70,10 @@ ifeq ($(lwip),y)
>>  LWC    := $(shell find $(LWIPDIR)/ -type f -name '*.c')
>>  LWC    := $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
>>  LWO    := $(patsubst %.c,%.o,$(LWC))
>> -LWO    += $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
>> +LWO    += $(OBJ_DIR)/lwip-arch.o
>> +ifeq ($(CONFIG_NETFRONT),y)
>> +LWO += $(OBJ_DIR)/lwip-net.o
>> +endif
> 
> Without lwip-net.o is there any point in having the rest of LWO? Or does
> the linker optimise it all away anyway?
> 

Some of the other parts of LWO may be useful on their own, depending on the
application run under minios. The xenstored configuration disables all of
LWO, so this doesn't matter there; the vTPM stub domains (from patches sent
by Matthew Fioravante in March 2011) do use parts of LWO without needing 
netfront support, which prompted this configuration test.

> [...]
> 
>> diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
>> index af0afed..c3eba35 100644
>> --- a/extras/mini-os/console/xencons_ring.c
>> +++ b/extras/mini-os/console/xencons_ring.c
>> @@ -189,6 +189,7 @@ struct consfront_dev *xencons_ring_init(void)
>>
>>  void free_consfront(struct consfront_dev *dev)
>>  {
>> +#ifdef CONFIG_XENBUS
>>      char* err = NULL;
>>      XenbusState state;
>>
>> @@ -217,6 +218,7 @@ void free_consfront(struct consfront_dev *dev)
>>  close:
>>      if (err) free(err);
>>      xenbus_unwatch_path_token(XBT_NIL, path, path);
>> +#endif
>>
>>      mask_evtchn(dev->evtchn);
>>      unbind_evtchn(dev->evtchn);
>> @@ -231,16 +233,18 @@ close:
>>
>>  struct consfront_dev *init_consfront(char *_nodename)
>>  {
>> +    struct consfront_dev *dev;
>> +    char nodename[256];
>> +    static int consfrontends = 3;
>> +#ifdef CONFIG_XENBUS
>>      xenbus_transaction_t xbt;
>>      char* err;
>>      char* message=NULL;
>>      int retry=0;
>>      char* msg = NULL;
>> -    char nodename[256];
>>      char path[256];
>> -    static int consfrontends = 3;
>> -    struct consfront_dev *dev;
>>      int res;
>> +#endif
>>
>>      if (!_nodename)
>>          snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
>> @@ -257,6 +261,7 @@ struct consfront_dev *init_consfront(char *_nodename)
>>      dev->fd = -1;
>>  #endif
>>
>> +#ifdef CONFIG_XENBUS
>>      snprintf(path, sizeof(path), "%s/backend-id", nodename);
>>      if ((res = xenbus_read_integer(path)) < 0)
>>          return NULL;
>> @@ -351,17 +356,21 @@ done:
>>              goto error;
>>          }
>>      }
>> +#endif
> 
> Haven't you ifdef'd out everything which would have set dev->evtchn?

Hmm, I might have. Will address it in the cleanup from the second mail.

> 
> I'm not sure that the CONFIG_XENBUS is worthwhile, at least at the
> moment, and it seems to add an awful lot of ifdefery.
> 
> [...]
>> diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
>> index 2875bf1..9e490d5 100644
>> --- a/extras/mini-os/kernel.c
>> +++ b/extras/mini-os/kernel.c
>> [...]
>> @@ -462,11 +474,21 @@ __attribute__((weak)) int app_main(start_info_t *si)
>>      printk("Dummy main: start_info=%p\n", si);
>>      create_thread("xenbus_tester", xenbus_tester, si);
>>      create_thread("periodic_thread", periodic_thread, si);
>> +#ifdef CONFIG_NETFRONT
>>      create_thread("netfront", netfront_thread, si);
>> +#endif
> 
> Better to define init_FOOfront for each of these and have it be a nop in
> the ifndef case and avoid the ifdefs in the code itself.
> 
> Likewise the ifdef's in the teardown. Ideally the actual meat in the
> ifdef cases would be moved into the files you aren't compiling (e.g.
> netfront_thread goes into netfront.c) and only the stubs remain in some
> header somewhere.
> 
> Ian.
> 

The majority of kernel.c seems to be test code intended to be overridden
by the application; see the comment above app_main:

/* This should be overridden by the application we are linked against. */
__attribute__((weak)) int app_main(start_info_t *si)

As such, maybe all of this code should be moved out of kernel.c and into
test.c, and have a better noop app_main in kernel.c.

-- 
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 Mon Jan 23 16:22:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMeb-00018y-Un; Mon, 23 Jan 2012 16:21:57 +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 1RpMea-00018Z-HC
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:21:56 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327335709!12173692!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 12950 invoked from network); 23 Jan 2012 16:21:50 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-216.messagelabs.com with SMTP;
	23 Jan 2012 16:21:50 -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
	q0NGLm3U006917; Mon, 23 Jan 2012 16:21:48 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 q0NGLmNs001963; 
	Mon, 23 Jan 2012 11:21:48 -0500
Message-ID: <4F1D891C.4050508@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 11:21:48 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
	<1327325368.24561.130.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327325368.24561.130.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 08:29 AM, Ian Campbell wrote:
> On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
>> This adds compile-time logic to disable certain frontends in mini-os:
>>  - pcifront is disabled by default, enabled for ioemu
>>  - blkfront, netfront, fbfront, and kbdfront are enabled by default
>>  - xenbus is required for any frontend, and is enabled by default
>>
>> If all frontends and xenbus are disabled, mini-os will run without
>> needing to communicate with xenstore, making it suitable to run the
>> xenstore daemon.
> 
> I should've read this properly first time, then it wouldn't have taken
> me until 17/21 to figure it out.
> 
> I think would be worthwhile to refactor the xenstore driver "extra"
> consoles from the single console provided via start info and to make the
> former a configurable option in line with the other front end drivers.
> That would, I think, tidy up the changes to xencons_ring. I think
> free_consfront and init_consfront only apply to the extra console case
> so the ifdefs you add within them would instead surround the whole
> functions (or even consfront.o if you decide that works).
> 
> Ian.
> 

Ah, I hadn't noticed that minios supported multiple consoles; that
explains a lot of the xenstore dependencies here. In that case, I think
it'd be useful to add CONFIG_CONSFRONT to allow dropping that support
(possibly refactoring into multiple files).

-- 
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 Mon Jan 23 16:22:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:22:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMeb-00018y-Un; Mon, 23 Jan 2012 16:21:57 +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 1RpMea-00018Z-HC
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:21:56 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327335709!12173692!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 12950 invoked from network); 23 Jan 2012 16:21:50 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-216.messagelabs.com with SMTP;
	23 Jan 2012 16:21:50 -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
	q0NGLm3U006917; Mon, 23 Jan 2012 16:21:48 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 q0NGLmNs001963; 
	Mon, 23 Jan 2012 11:21:48 -0500
Message-ID: <4F1D891C.4050508@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 11:21:48 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
	<1327325368.24561.130.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327325368.24561.130.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 08:29 AM, Ian Campbell wrote:
> On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
>> This adds compile-time logic to disable certain frontends in mini-os:
>>  - pcifront is disabled by default, enabled for ioemu
>>  - blkfront, netfront, fbfront, and kbdfront are enabled by default
>>  - xenbus is required for any frontend, and is enabled by default
>>
>> If all frontends and xenbus are disabled, mini-os will run without
>> needing to communicate with xenstore, making it suitable to run the
>> xenstore daemon.
> 
> I should've read this properly first time, then it wouldn't have taken
> me until 17/21 to figure it out.
> 
> I think would be worthwhile to refactor the xenstore driver "extra"
> consoles from the single console provided via start info and to make the
> former a configurable option in line with the other front end drivers.
> That would, I think, tidy up the changes to xencons_ring. I think
> free_consfront and init_consfront only apply to the extra console case
> so the ifdefs you add within them would instead surround the whole
> functions (or even consfront.o if you decide that works).
> 
> Ian.
> 

Ah, I hadn't noticed that minios supported multiple consoles; that
explains a lot of the xenstore dependencies here. In that case, I think
it'd be useful to add CONFIG_CONSFRONT to allow dropping that support
(possibly refactoring into multiple files).

-- 
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 Mon Jan 23 16:22:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMfL-0001Ez-K0; Mon, 23 Jan 2012 16:22:43 +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 1RpMfK-0001Ej-EY
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:22:42 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327335724!49567012!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25676 invoked from network); 23 Jan 2012 16:22:05 -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;
	23 Jan 2012 16:22:05 -0000
Received: by ggnk3 with SMTP id k3so38751147ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 08:22:40 -0800 (PST)
Received: by 10.50.178.70 with SMTP id cw6mr13541786igc.4.1327335759885;
	Mon, 23 Jan 2012 08:22:39 -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 pb6sm24415977igc.5.2012.01.23.08.22.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 08:22:37 -0800 (PST)
Message-ID: <4F1D8949.4080608@codemonkey.ws>
Date: Mon, 23 Jan 2012 10:22:33 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 10:16 AM, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-23 15:46, Stefano Stabellini wrote:
>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>> On 2012-01-23 12:59, Stefano Stabellini wrote:
>>>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>>>>>> Or what is the ordering
>>>>>>>> of init, RAM restore, and initial device reset now?
>>>>>>>
>>>>>>> RAM restore (done by Xen)
>>>>>>>
>>>>>>> physmap rebuild (done by xen_hvm_init in qemu)
>>>>>>> pc_init()
>>>>>>> qemu_system_reset()
>>>>>>> load_vmstate()
>>>>>>
>>>>>> Hmm, are you sure that this is the only case where a device init or
>>>>>> reset handler writes to already restored guest memory? Preloading the
>>>>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
>>>>>> fragile. Does restoring happen before QEMU is even started, or can this
>>>>>> point be controlled from QEMU?
>>>>>
>>>>> Consider that this only happens with non-MMIO device memory, in practice
>>>>> only videoram.
>>>>> Vmware VGA does not memset the videoram in the reset handler, while QXL
>>>>> already has the following:
>>>>>
>>>>>      /* pre loadvm reset must not touch QXLRam.  This lives in
>>>>>       * device memory, is migrated together with RAM and thus
>>>>>       * already loaded at this point */ if (!loadvm) {
>>>>>       qxl_reset_state(d); }
>>>>
>>>> Yes, but QEMU restores the RAM _after_ device reset, not before it.
>>>> That's the problem with the Xen way - it is against the current
>>>> QEMU standard.
>>>
>>> QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.
>>
>> But it does otherwise, and that's the scenario the code you cited was
>> written for. It won't work as is under Xen.
>
> Ah, I see your point now.
> In that regard, is the comment above even correct?
> I am referring to "migrated together with RAM and thus already loaded at
> this point"?
>
>
>>> To reply to your previous question more clearly: at restore time Qemu on
>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>> before QEMU is even started.
>>>
>>> That is unfortunate but it would be very hard to change (I can give you
>>> more details if you are interested in the reasons why it would be so
>>> difficult).
>>
>> If you can't change this, you need to properly introduce this new
>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>> see breakage outside cirrus sooner or later as well. So it might be good
>> to explain the reason why it can't be changed under Xen when motivating
>> this concept extension to QEMU.
>
> OK.
> Are you thinking about introducing this concept as a new runstate?
> This special runstate could be set at restore time only on Xen.

A runstate is not the right approach.  Don't abuse existing commands/protocols 
to make them have a different function on Xen.

Just introduce a new command that has the behavior you want.

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 Jan 23 16:22:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:22:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMfL-0001Ez-K0; Mon, 23 Jan 2012 16:22:43 +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 1RpMfK-0001Ej-EY
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:22:42 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327335724!49567012!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25676 invoked from network); 23 Jan 2012 16:22:05 -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;
	23 Jan 2012 16:22:05 -0000
Received: by ggnk3 with SMTP id k3so38751147ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 08:22:40 -0800 (PST)
Received: by 10.50.178.70 with SMTP id cw6mr13541786igc.4.1327335759885;
	Mon, 23 Jan 2012 08:22:39 -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 pb6sm24415977igc.5.2012.01.23.08.22.35
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 08:22:37 -0800 (PST)
Message-ID: <4F1D8949.4080608@codemonkey.ws>
Date: Mon, 23 Jan 2012 10:22:33 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 10:16 AM, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-23 15:46, Stefano Stabellini wrote:
>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>> On 2012-01-23 12:59, Stefano Stabellini wrote:
>>>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>>>>>> Or what is the ordering
>>>>>>>> of init, RAM restore, and initial device reset now?
>>>>>>>
>>>>>>> RAM restore (done by Xen)
>>>>>>>
>>>>>>> physmap rebuild (done by xen_hvm_init in qemu)
>>>>>>> pc_init()
>>>>>>> qemu_system_reset()
>>>>>>> load_vmstate()
>>>>>>
>>>>>> Hmm, are you sure that this is the only case where a device init or
>>>>>> reset handler writes to already restored guest memory? Preloading the
>>>>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
>>>>>> fragile. Does restoring happen before QEMU is even started, or can this
>>>>>> point be controlled from QEMU?
>>>>>
>>>>> Consider that this only happens with non-MMIO device memory, in practice
>>>>> only videoram.
>>>>> Vmware VGA does not memset the videoram in the reset handler, while QXL
>>>>> already has the following:
>>>>>
>>>>>      /* pre loadvm reset must not touch QXLRam.  This lives in
>>>>>       * device memory, is migrated together with RAM and thus
>>>>>       * already loaded at this point */ if (!loadvm) {
>>>>>       qxl_reset_state(d); }
>>>>
>>>> Yes, but QEMU restores the RAM _after_ device reset, not before it.
>>>> That's the problem with the Xen way - it is against the current
>>>> QEMU standard.
>>>
>>> QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.
>>
>> But it does otherwise, and that's the scenario the code you cited was
>> written for. It won't work as is under Xen.
>
> Ah, I see your point now.
> In that regard, is the comment above even correct?
> I am referring to "migrated together with RAM and thus already loaded at
> this point"?
>
>
>>> To reply to your previous question more clearly: at restore time Qemu on
>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>> before QEMU is even started.
>>>
>>> That is unfortunate but it would be very hard to change (I can give you
>>> more details if you are interested in the reasons why it would be so
>>> difficult).
>>
>> If you can't change this, you need to properly introduce this new
>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>> see breakage outside cirrus sooner or later as well. So it might be good
>> to explain the reason why it can't be changed under Xen when motivating
>> this concept extension to QEMU.
>
> OK.
> Are you thinking about introducing this concept as a new runstate?
> This special runstate could be set at restore time only on Xen.

A runstate is not the right approach.  Don't abuse existing commands/protocols 
to make them have a different function on Xen.

Just introduce a new command that has the behavior you want.

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 Jan 23 16:23:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMgD-0001MA-3t; Mon, 23 Jan 2012 16:23:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpMgB-0001LY-DT
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:23:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327335808!10268593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13041 invoked from network); 23 Jan 2012 16:23:28 -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;
	23 Jan 2012 16:23:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10223225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:23:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 16:23:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 16:23:27 +0000
In-Reply-To: <4F1D8544.8050102@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
	<1327322464.24561.101.camel@zakaz.uk.xensource.com>
	<4F1D8544.8050102@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327335807.24561.158.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 10/21] mini-os: create app-specific
 configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 16:05 +0000, Daniel De Graaf wrote:
> On 01/23/2012 07:41 AM, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> >> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
> >> code, create CONFIG_ items for features and use application-specific
> >> configuration files to enable or disable the features.
> >>
> >> The configuration flags are currently added to the compiler command
> >> line; as the number of flags grows this may need to move to a header.
> >>
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >> ---
> >>  extras/mini-os/Makefile       |   15 +++++++++------
> >>  extras/mini-os/apps/common.mk |   11 +++++++++++
> >>  extras/mini-os/apps/grub.mk   |    2 ++
> >>  extras/mini-os/apps/ioemu.mk  |    1 +
> > 
> > I think these should go under stubdom/xxx. You can simply pass in
> > MINIOS_CONFIG as an absolute path and included it
> > ifneq($(MINIOS_CONFIG),) instead of the ifeq($(stubdom),y) change you
> > made.
> > 
> 
> That location also looks nicer, but it will make it more likely that some
> config file will be missed if the defaults are updated. Shouldn't be too
> much of a problem, though - we only have 5 stubdom configs at the moment.

Perhaps a comment directing people to look in stubdoms/... too?

> >> @@ -34,13 +39,11 @@ TARGET := mini-os
> >>  # Subdirectories common to mini-os
> >>  SUBDIRS := lib xenbus console
> >>  
> >> +include files.mk
> > 
> > I don't think moving this out of line is necessary, the pattern in moast
> > of our makefiles is to have the obj-(YN) stuff inline in the Makefiles.
> 
> OK, I wasn't sure how this Makefile was intended split up (it has some logic
> in minios.mk that seemed related).

minios.mk looks like general rules for building bits of mini-os itself,
it's included from submakefiles too (we'd normally call that Rules.mk
these days).

> > [...]
> >> diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
> >> index b95b889..aeda548 100644
> >> --- a/extras/mini-os/main.c
> >> +++ b/extras/mini-os/main.c
> >> @@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
> >>  static void call_main(void *p)
> >>  {
> >>      char *c, quote;
> >> -#ifdef CONFIG_QEMU
> >> +#ifdef CONFIG_QEMU_XS_ARGS
> >>      char *domargs, *msg;
> >>  #endif
> >>      int argc;
> >>      char **argv;
> >>      char *envp[] = { NULL };
> >> -#ifdef CONFIG_QEMU
> >> +#ifdef CONFIG_QEMU_XS_ARGS
> > 
> > If you allow for the "%s/image/dmargs" (not shown in the patch context)
> > to come from a CONFIG_MUMBLE then this is no longer QEMU specific.
> 
> It's still mostly ioemu-specific, since we start by looking up a target
> domain ID, convert it to a VM path, and then look for a path under there.
> Making only the final path of /vm/UUID/image/dmargs configurable doesn't
> sound as useful for a general case, and making the intermediate steps
> configurable would be a mess.

Oh, I hadn't realised it was reading from the target VM and not the stub
VM -- as you say that does make it somewhat more convoluted.

Maybe just refactoring into a function of it's own would help. I was
going to suggest CONFIG_HAS_ARGS_PARSER surrounding a call to
parse_the_args which was supplied from under stubdoms but I don't see
anywhere convenient to put it.

[...] 
> Actually, =n will result in the C symbol being undefined; the Makefile symbol
> can't be undefined or the ?= used to set defaults will override it.

Oh right, this is the CPP symbol not the make one which is done with
CFLAGS-$(XXX) += -D$(XXX) -- so that does indeed work.

> The other way I thought of doing it is to discard the defaults and add them to
> each stubdom's configuration, but this seemed more prone to getting out of sync
> when adding new configuration items.

Sure.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:23:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMgD-0001MA-3t; Mon, 23 Jan 2012 16:23:37 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpMgB-0001LY-DT
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:23:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327335808!10268593!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13041 invoked from network); 23 Jan 2012 16:23:28 -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;
	23 Jan 2012 16:23:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10223225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:23:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 16:23:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 16:23:27 +0000
In-Reply-To: <4F1D8544.8050102@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-11-git-send-email-dgdegra@tycho.nsa.gov>
	<1327322464.24561.101.camel@zakaz.uk.xensource.com>
	<4F1D8544.8050102@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327335807.24561.158.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 10/21] mini-os: create app-specific
 configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 16:05 +0000, Daniel De Graaf wrote:
> On 01/23/2012 07:41 AM, Ian Campbell wrote:
> > On Fri, 2012-01-20 at 20:47 +0000, Daniel De Graaf wrote:
> >> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
> >> code, create CONFIG_ items for features and use application-specific
> >> configuration files to enable or disable the features.
> >>
> >> The configuration flags are currently added to the compiler command
> >> line; as the number of flags grows this may need to move to a header.
> >>
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >> ---
> >>  extras/mini-os/Makefile       |   15 +++++++++------
> >>  extras/mini-os/apps/common.mk |   11 +++++++++++
> >>  extras/mini-os/apps/grub.mk   |    2 ++
> >>  extras/mini-os/apps/ioemu.mk  |    1 +
> > 
> > I think these should go under stubdom/xxx. You can simply pass in
> > MINIOS_CONFIG as an absolute path and included it
> > ifneq($(MINIOS_CONFIG),) instead of the ifeq($(stubdom),y) change you
> > made.
> > 
> 
> That location also looks nicer, but it will make it more likely that some
> config file will be missed if the defaults are updated. Shouldn't be too
> much of a problem, though - we only have 5 stubdom configs at the moment.

Perhaps a comment directing people to look in stubdoms/... too?

> >> @@ -34,13 +39,11 @@ TARGET := mini-os
> >>  # Subdirectories common to mini-os
> >>  SUBDIRS := lib xenbus console
> >>  
> >> +include files.mk
> > 
> > I don't think moving this out of line is necessary, the pattern in moast
> > of our makefiles is to have the obj-(YN) stuff inline in the Makefiles.
> 
> OK, I wasn't sure how this Makefile was intended split up (it has some logic
> in minios.mk that seemed related).

minios.mk looks like general rules for building bits of mini-os itself,
it's included from submakefiles too (we'd normally call that Rules.mk
these days).

> > [...]
> >> diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
> >> index b95b889..aeda548 100644
> >> --- a/extras/mini-os/main.c
> >> +++ b/extras/mini-os/main.c
> >> @@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
> >>  static void call_main(void *p)
> >>  {
> >>      char *c, quote;
> >> -#ifdef CONFIG_QEMU
> >> +#ifdef CONFIG_QEMU_XS_ARGS
> >>      char *domargs, *msg;
> >>  #endif
> >>      int argc;
> >>      char **argv;
> >>      char *envp[] = { NULL };
> >> -#ifdef CONFIG_QEMU
> >> +#ifdef CONFIG_QEMU_XS_ARGS
> > 
> > If you allow for the "%s/image/dmargs" (not shown in the patch context)
> > to come from a CONFIG_MUMBLE then this is no longer QEMU specific.
> 
> It's still mostly ioemu-specific, since we start by looking up a target
> domain ID, convert it to a VM path, and then look for a path under there.
> Making only the final path of /vm/UUID/image/dmargs configurable doesn't
> sound as useful for a general case, and making the intermediate steps
> configurable would be a mess.

Oh, I hadn't realised it was reading from the target VM and not the stub
VM -- as you say that does make it somewhat more convoluted.

Maybe just refactoring into a function of it's own would help. I was
going to suggest CONFIG_HAS_ARGS_PARSER surrounding a call to
parse_the_args which was supplied from under stubdoms but I don't see
anywhere convenient to put it.

[...] 
> Actually, =n will result in the C symbol being undefined; the Makefile symbol
> can't be undefined or the ?= used to set defaults will override it.

Oh right, this is the CPP symbol not the make one which is done with
CFLAGS-$(XXX) += -D$(XXX) -- so that does indeed work.

> The other way I thought of doing it is to discard the defaults and add them to
> each stubdom's configuration, but this seemed more prone to getting out of sync
> when adding new configuration items.

Sure.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:24:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMhB-0001UI-KI; Mon, 23 Jan 2012 16:24:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpMh9-0001TM-Ur
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:24:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327335870!12216917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8377 invoked from network); 23 Jan 2012 16:24:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10223246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:24:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 16:24:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 16:24:29 +0000
In-Reply-To: <4F1D8916.3050409@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
	<1327323081.24561.108.camel@zakaz.uk.xensource.com>
	<4F1D8916.3050409@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327335869.24561.159.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 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 16:21 +0000, Daniel De Graaf wrote:
> On 01/23/2012 07:51 AM, Ian Campbell wrote:
> > Better to define init_FOOfront for each of these and have it be a nop in
> > the ifndef case and avoid the ifdefs in the code itself.
> > 
> > Likewise the ifdef's in the teardown. Ideally the actual meat in the
> > ifdef cases would be moved into the files you aren't compiling (e.g.
> > netfront_thread goes into netfront.c) and only the stubs remain in some
> > header somewhere.
> > 
> > Ian.
> > 
> 
> The majority of kernel.c seems to be test code intended to be overridden
> by the application; see the comment above app_main:
> 
> /* This should be overridden by the application we are linked against. */
> __attribute__((weak)) int app_main(start_info_t *si)
> 
> As such, maybe all of this code should be moved out of kernel.c and into
> test.c, and have a better noop app_main in kernel.c.

That sounds reasonable to me.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:24:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:24:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMhB-0001UI-KI; Mon, 23 Jan 2012 16:24:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpMh9-0001TM-Ur
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:24:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327335870!12216917!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8377 invoked from network); 23 Jan 2012 16:24:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:24:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10223246"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:24:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 16:24:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Mon, 23 Jan 2012 16:24:29 +0000
In-Reply-To: <4F1D8916.3050409@tycho.nsa.gov>
References: <1327092461-2701-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327092461-2701-12-git-send-email-dgdegra@tycho.nsa.gov>
	<1327323081.24561.108.camel@zakaz.uk.xensource.com>
	<4F1D8916.3050409@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327335869.24561.159.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 11/21] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 16:21 +0000, Daniel De Graaf wrote:
> On 01/23/2012 07:51 AM, Ian Campbell wrote:
> > Better to define init_FOOfront for each of these and have it be a nop in
> > the ifndef case and avoid the ifdefs in the code itself.
> > 
> > Likewise the ifdef's in the teardown. Ideally the actual meat in the
> > ifdef cases would be moved into the files you aren't compiling (e.g.
> > netfront_thread goes into netfront.c) and only the stubs remain in some
> > header somewhere.
> > 
> > Ian.
> > 
> 
> The majority of kernel.c seems to be test code intended to be overridden
> by the application; see the comment above app_main:
> 
> /* This should be overridden by the application we are linked against. */
> __attribute__((weak)) int app_main(start_info_t *si)
> 
> As such, maybe all of this code should be moved out of kernel.c and into
> test.c, and have a better noop app_main in kernel.c.

That sounds reasonable to me.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:29:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpMlQ-0001su-BT; Mon, 23 Jan 2012 16:29: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 1RpMlO-0001sc-Kq
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:28:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327336131!12067448!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 10129 invoked from network); 23 Jan 2012 16:28:51 -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 Jan 2012 16:28:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 16:28:50 +0000
Message-Id: <4F1D991A020000780006E74E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 16:30:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
	<4F1D7702020000780006E6C2@nat28.tlf.novell.com>
	<1327334483.26455.260.camel@elijah>
In-Reply-To: <1327334483.26455.260.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 17:01, George Dunlap <george.dunlap@citrix.com> wrote:
> On Mon, 2012-01-23 at 14:04 +0000, Jan Beulich wrote:
>> >>> On 23.01.12 at 11:47, "Jan Beulich" <JBeulich@suse.com> wrote:
>> >>>> On 23.01.12 at 11:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> On Mon, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
>> >>> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
>> >>> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
>> >>> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
>> >>> > @@ -68,7 +68,7 @@ struct event_log {
>> >>> >   };
>> >>> > 
>> >>> >   /* PC value that indicates a special code */
>> >>> > -#define XENOPROF_ESCAPE_CODE ~0UL
>> >>> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
>> >>> 
>> >>> You cannot just go and change a public definition, as the consuming
>> >>> side will break. You need to introduce a new escape code, and
>> >>> provide a mechanism to negotiate (between hypervisor and kernel)
>> >>> which one to use.
>> >> 
>> >> This seems more like a bug fix to me than an interface change, the fact
>> >> that both producer and consumer had the bug notwithstanding.
>> >> 
>> >> Since this is a developer oriented interface I think we can be a little
>> >> more relaxed than we would be for other interface changes. In this case
>> >> we are fixing 32on64 (quite common) at the expense of 32on32 (very
>> >> uncommon these days, especially for the suybset of developers wanting to
>> >> do profiling) and leaving 64on64 (quite common) as it is . That seems
>> >> like a worthwhile tradeoff to me.
>> > 
>> > I see your point. However, I'd still like to be careful with this - what
>> > we think things ought to be used for doesn't necessarily cover all
>> > cases that they are in reality.
>> 
>> I see that it got applied unchanged. It introduces two warnings in
>> the 32-bit build, which not only fails that build, but also indicates
>> that the situation likely wasn't fully analyzed.
> 
> The attached patch fixes the build (with the original patch un-reverted
> of course), by making the internal calls explicitly take 64-bit values
> for eip, rather than "unsigned long".  Will that suffice?

Looks correct and sufficient, but with the original patch already
reverted folding the changes here into the original and re-submitting
would probably the best route to go.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:29:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpMlQ-0001su-BT; Mon, 23 Jan 2012 16:29: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 1RpMlO-0001sc-Kq
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:28:58 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327336131!12067448!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 10129 invoked from network); 23 Jan 2012 16:28:51 -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 Jan 2012 16:28:51 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 16:28:50 +0000
Message-Id: <4F1D991A020000780006E74E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 16:30:02 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
	<4F1D7702020000780006E6C2@nat28.tlf.novell.com>
	<1327334483.26455.260.camel@elijah>
In-Reply-To: <1327334483.26455.260.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 17:01, George Dunlap <george.dunlap@citrix.com> wrote:
> On Mon, 2012-01-23 at 14:04 +0000, Jan Beulich wrote:
>> >>> On 23.01.12 at 11:47, "Jan Beulich" <JBeulich@suse.com> wrote:
>> >>>> On 23.01.12 at 11:16, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> >> On Mon, 2012-01-23 at 09:57 +0000, Jan Beulich wrote:
>> >>> >>> On 20.01.12 at 19:45, Marcus Granado <marcus.granado@citrix.com> wrote:
>> >>> > --- a/xen/include/public/xenoprof.h    Wed Jan 18 17:39:19 2012 +0000
>> >>> > +++ b/xen/include/public/xenoprof.h    Wed Jan 18 17:46:28 2012 +0000
>> >>> > @@ -68,7 +68,7 @@ struct event_log {
>> >>> >   };
>> >>> > 
>> >>> >   /* PC value that indicates a special code */
>> >>> > -#define XENOPROF_ESCAPE_CODE ~0UL
>> >>> > +#define XENOPROF_ESCAPE_CODE (~0ULL)
>> >>> 
>> >>> You cannot just go and change a public definition, as the consuming
>> >>> side will break. You need to introduce a new escape code, and
>> >>> provide a mechanism to negotiate (between hypervisor and kernel)
>> >>> which one to use.
>> >> 
>> >> This seems more like a bug fix to me than an interface change, the fact
>> >> that both producer and consumer had the bug notwithstanding.
>> >> 
>> >> Since this is a developer oriented interface I think we can be a little
>> >> more relaxed than we would be for other interface changes. In this case
>> >> we are fixing 32on64 (quite common) at the expense of 32on32 (very
>> >> uncommon these days, especially for the suybset of developers wanting to
>> >> do profiling) and leaving 64on64 (quite common) as it is . That seems
>> >> like a worthwhile tradeoff to me.
>> > 
>> > I see your point. However, I'd still like to be careful with this - what
>> > we think things ought to be used for doesn't necessarily cover all
>> > cases that they are in reality.
>> 
>> I see that it got applied unchanged. It introduces two warnings in
>> the 32-bit build, which not only fails that build, but also indicates
>> that the situation likely wasn't fully analyzed.
> 
> The attached patch fixes the build (with the original patch un-reverted
> of course), by making the internal calls explicitly take 64-bit values
> for eip, rather than "unsigned long".  Will that suffice?

Looks correct and sufficient, but with the original patch already
reverted folding the changes here into the original and re-submitting
would probably the best route to go.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:33:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMpk-00021a-1v; Mon, 23 Jan 2012 16:33:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RpMph-00021O-Pa
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:33:25 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327336378!63600780!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27260 invoked from network); 23 Jan 2012 16:32:59 -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; 23 Jan 2012 16: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
	q0NGXHC4023857
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 23 Jan 2012 16:33: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
	q0NGXGS7004175
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 23 Jan 2012 16:33:17 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
	q0NGXG8B025231
	for <xen-devel@lists.xensource.com>; Mon, 23 Jan 2012 10:33:16 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 08:33:16 -0800
MIME-Version: 1.0
X-Mercurial-Node: 35c926c69a1397dd7360eacf2c6864ad12d9da02
Message-Id: <35c926c69a1397dd7360.1327336398@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Mon, 23 Jan 2012 11:33:18 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel@lists.xensource.com
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F1D8BCE.0021,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [PATCH] xl: remove duplicate line
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1327336349 18000
# Node ID 35c926c69a1397dd7360eacf2c6864ad12d9da02
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
xl: remove duplicate line

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r 5b2676ac1321 -r 35c926c69a13 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 11:32:29 2012 -0500
@@ -774,8 +774,6 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
 
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
-
         xlu_cfg_get_string (config, "root", &root, 0);
         xlu_cfg_get_string (config, "extra", &extra, 0);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:33:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:33:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMpk-00021a-1v; Mon, 23 Jan 2012 16:33:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RpMph-00021O-Pa
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:33:25 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327336378!63600780!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27260 invoked from network); 23 Jan 2012 16:32:59 -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; 23 Jan 2012 16: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
	q0NGXHC4023857
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Mon, 23 Jan 2012 16:33: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
	q0NGXGS7004175
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Mon, 23 Jan 2012 16:33:17 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
	q0NGXG8B025231
	for <xen-devel@lists.xensource.com>; Mon, 23 Jan 2012 10:33:16 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 08:33:16 -0800
MIME-Version: 1.0
X-Mercurial-Node: 35c926c69a1397dd7360eacf2c6864ad12d9da02
Message-Id: <35c926c69a1397dd7360.1327336398@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Mon, 23 Jan 2012 11:33:18 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel@lists.xensource.com
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090207.4F1D8BCE.0021,ss=1,re=0.000,fgs=0
Subject: [Xen-devel] [PATCH] xl: remove duplicate line
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1327336349 18000
# Node ID 35c926c69a1397dd7360eacf2c6864ad12d9da02
# Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
xl: remove duplicate line

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r 5b2676ac1321 -r 35c926c69a13 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 09 16:01:44 2012 +0100
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 11:32:29 2012 -0500
@@ -774,8 +774,6 @@ static void parse_config_data(const char
 
         xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
 
-        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
-
         xlu_cfg_get_string (config, "root", &root, 0);
         xlu_cfg_get_string (config, "extra", &extra, 0);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:34:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMqq-000260-HJ; Mon, 23 Jan 2012 16:34: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 1RpMqp-00025h-7y
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:34:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327336467!12067985!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19700 invoked from network); 23 Jan 2012 16:34:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:34:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181097"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:34:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:34: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
	q0NGYPbG032028;	Mon, 23 Jan 2012 08:34:26 -0800
MIME-Version: 1.0
X-Mercurial-Node: 37f76bfff488a2cbf8545c1baad83586bd5c6114
Message-ID: <37f76bfff488a2cbf854.1327336465@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:34:25 +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 _libxl_json_internal.h from
	libxl_json.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 Ian Campbell <ian.campbell@citrix.com>
# Date 1327330134 0
# Node ID 37f76bfff488a2cbf8545c1baad83586bd5c6114
# Parent  d8efdb16b1ef06013061da1f47c2dbce4b042992
libxl: remove _libxl_json_internal.h from libxl_json.h

libxl_json.h is intended as a user-includable header for applications which
would like to use libyajl directly with libxl types. It should not expose libxl
internals.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d8efdb16b1ef -r 37f76bfff488 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 14:39:25 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 14:48:54 2012 +0000
@@ -61,8 +61,10 @@
 #include "flexarray.h"
 #include "libxl_utils.h"
 
+#include "libxl_json.h"
+
 #include "_libxl_types_internal.h"
-#include "libxl_json.h"
+#include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
diff -r d8efdb16b1ef -r 37f76bfff488 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Mon Jan 23 14:39:25 2012 +0000
+++ b/tools/libxl/libxl_json.h	Mon Jan 23 14:48:54 2012 +0000
@@ -18,6 +18,5 @@
 #include <yajl/yajl_gen.h>
 
 #include <_libxl_types_json.h>
-#include <_libxl_types_internal_json.h>
 
 #endif /* LIBXL_JSON_H */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:34:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMqq-000260-HJ; Mon, 23 Jan 2012 16:34: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 1RpMqp-00025h-7y
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:34:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327336467!12067985!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19700 invoked from network); 23 Jan 2012 16:34:29 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:34:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181097"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:34:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:34: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
	q0NGYPbG032028;	Mon, 23 Jan 2012 08:34:26 -0800
MIME-Version: 1.0
X-Mercurial-Node: 37f76bfff488a2cbf8545c1baad83586bd5c6114
Message-ID: <37f76bfff488a2cbf854.1327336465@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:34:25 +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 _libxl_json_internal.h from
	libxl_json.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 Ian Campbell <ian.campbell@citrix.com>
# Date 1327330134 0
# Node ID 37f76bfff488a2cbf8545c1baad83586bd5c6114
# Parent  d8efdb16b1ef06013061da1f47c2dbce4b042992
libxl: remove _libxl_json_internal.h from libxl_json.h

libxl_json.h is intended as a user-includable header for applications which
would like to use libyajl directly with libxl types. It should not expose libxl
internals.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r d8efdb16b1ef -r 37f76bfff488 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 14:39:25 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 14:48:54 2012 +0000
@@ -61,8 +61,10 @@
 #include "flexarray.h"
 #include "libxl_utils.h"
 
+#include "libxl_json.h"
+
 #include "_libxl_types_internal.h"
-#include "libxl_json.h"
+#include "_libxl_types_internal_json.h"
 
 #define LIBXL_DESTROY_TIMEOUT 10
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 10
diff -r d8efdb16b1ef -r 37f76bfff488 tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Mon Jan 23 14:39:25 2012 +0000
+++ b/tools/libxl/libxl_json.h	Mon Jan 23 14:48:54 2012 +0000
@@ -18,6 +18,5 @@
 #include <yajl/yajl_gen.h>
 
 #include <_libxl_types_json.h>
-#include <_libxl_types_internal_json.h>
 
 #endif /* LIBXL_JSON_H */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:38:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMuE-0002ML-7l; Mon, 23 Jan 2012 16:38:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpMuD-0002Lt-2h
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:38:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327336678!10345200!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23263 invoked from network); 23 Jan 2012 16:37:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:37:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10223888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:37:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 16:37:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Mon, 23 Jan 2012 16:37:27 +0000
In-Reply-To: <35c926c69a1397dd7360.1327336398@zhigang.us.oracle.com>
References: <35c926c69a1397dd7360.1327336398@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327336647.24561.160.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: remove duplicate line
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 16:33 +0000, Zhigang Wang wrote:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1327336349 18000
> # Node ID 35c926c69a1397dd7360eacf2c6864ad12d9da02
> # Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
> xl: remove duplicate line

Oops, fortunately harmless.

> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>


> diff -r 5b2676ac1321 -r 35c926c69a13 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 11:32:29 2012 -0500
> @@ -774,8 +774,6 @@ static void parse_config_data(const char
>  
>          xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
>  
> -        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
> -
>          xlu_cfg_get_string (config, "root", &root, 0);
>          xlu_cfg_get_string (config, "extra", &extra, 0);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:38:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpMuE-0002ML-7l; Mon, 23 Jan 2012 16:38:06 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpMuD-0002Lt-2h
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:38:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327336678!10345200!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23263 invoked from network); 23 Jan 2012 16:37:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:37:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10223888"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:37:27 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 23 Jan 2012 16:37:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Mon, 23 Jan 2012 16:37:27 +0000
In-Reply-To: <35c926c69a1397dd7360.1327336398@zhigang.us.oracle.com>
References: <35c926c69a1397dd7360.1327336398@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327336647.24561.160.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xl: remove duplicate line
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 16:33 +0000, Zhigang Wang wrote:
> # HG changeset patch
> # User Zhigang Wang <zhigang.x.wang@oracle.com>
> # Date 1327336349 18000
> # Node ID 35c926c69a1397dd7360eacf2c6864ad12d9da02
> # Parent  5b2676ac13218951698c49fa0350f2ac48220f3d
> xl: remove duplicate line

Oops, fortunately harmless.

> Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>


> diff -r 5b2676ac1321 -r 35c926c69a13 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 09 16:01:44 2012 +0100
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 11:32:29 2012 -0500
> @@ -774,8 +774,6 @@ static void parse_config_data(const char
>  
>          xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
>  
> -        xlu_cfg_replace_string (config, "kernel", &b_info->u.pv.kernel.path, 0);
> -
>          xlu_cfg_get_string (config, "root", &root, 0);
>          xlu_cfg_get_string (config, "extra", &extra, 0);
>  
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:43:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpMzJ-0002h1-UA; Mon, 23 Jan 2012 16:43:21 +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 1RpMzI-0002gq-B9
	for Xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:43:20 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327336950!49747870!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9986 invoked from network); 23 Jan 2012 16:42:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 16:42: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
	q0NGhHO6022844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 11:43:17 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0NGhHYw022841;
	Mon, 23 Jan 2012 11:43:17 -0500
Date: Mon, 23 Jan 2012 12:43:17 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>, \
Message-ID: <20120123164316.GA22488@andromeda.dapyr.net>
References: <20120120172932.3dd3f5ac@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120120172932.3dd3f5ac@mantra.us.oracle.com>
User-Agent: Mutt/1.5.9i
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Ques]:xen_ident_map_ISA ant it's 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

On Fri, Jan 20, 2012 at 05:29:32PM -0800, Mukesh Rathor wrote:
> Hi,
> 
> I am bit confused about the do_update_va_mapping call that dom0 makes in
> xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The mfn belongs
> to DOMID_IO. Before the mfn is mapped, the l1 entry is not empty:
> 
> 0000000139d08500:  00100001380a0027
> 
> After the mapping:
> 
> 0000000139d08500:  00100000000a0467  as expected.
> 
> However, the mfn 1380a0 still seems to belong to dom0. Shouldn't that
> have been returned back to the xen heap? 

It should if dom0 had returned it back. The setup.c code you where
it returns the swatches of memory has a check where it decides to return
only memory above 1M. The <1MB is left unused.

In other words, we make all the PTE's to the look as if PFN are
1:1 to MFN. But if you do a MFN lookup to PFN (mfn_to_pfn) for the regions below
1MB, you end up getting PFNs that are _not_ in the 1MB region.
Instead they are just normal memory.

There is a good reason for this, which if I remeber right is to allow
fixmap to work correctly, but if you are using ioremap it would return
empty RAM so that most of the PnP devices (like RTC) would not load.

hmm, I think so . I remember thinking to remove that once (so allow the
<1MB region to be freed), and I hit some pretty big problems.

Is there a particular reason you want to "Free" that memory?

> 
> thanks,
> Mukesh
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 23 16:43:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpMzJ-0002h1-UA; Mon, 23 Jan 2012 16:43:21 +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 1RpMzI-0002gq-B9
	for Xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:43:20 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327336950!49747870!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9986 invoked from network); 23 Jan 2012 16:42:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 16:42: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
	q0NGhHO6022844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 11:43:17 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0NGhHYw022841;
	Mon, 23 Jan 2012 11:43:17 -0500
Date: Mon, 23 Jan 2012 12:43:17 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Mukesh Rathor <mukesh.rathor@oracle.com>, \
Message-ID: <20120123164316.GA22488@andromeda.dapyr.net>
References: <20120120172932.3dd3f5ac@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120120172932.3dd3f5ac@mantra.us.oracle.com>
User-Agent: Mutt/1.5.9i
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Ques]:xen_ident_map_ISA ant it's 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

On Fri, Jan 20, 2012 at 05:29:32PM -0800, Mukesh Rathor wrote:
> Hi,
> 
> I am bit confused about the do_update_va_mapping call that dom0 makes in
> xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The mfn belongs
> to DOMID_IO. Before the mfn is mapped, the l1 entry is not empty:
> 
> 0000000139d08500:  00100001380a0027
> 
> After the mapping:
> 
> 0000000139d08500:  00100000000a0467  as expected.
> 
> However, the mfn 1380a0 still seems to belong to dom0. Shouldn't that
> have been returned back to the xen heap? 

It should if dom0 had returned it back. The setup.c code you where
it returns the swatches of memory has a check where it decides to return
only memory above 1M. The <1MB is left unused.

In other words, we make all the PTE's to the look as if PFN are
1:1 to MFN. But if you do a MFN lookup to PFN (mfn_to_pfn) for the regions below
1MB, you end up getting PFNs that are _not_ in the 1MB region.
Instead they are just normal memory.

There is a good reason for this, which if I remeber right is to allow
fixmap to work correctly, but if you are using ioremap it would return
empty RAM so that most of the PnP devices (like RTC) would not load.

hmm, I think so . I remember thinking to remove that once (so allow the
<1MB region to be freed), and I hit some pretty big problems.

Is there a particular reason you want to "Free" that memory?

> 
> thanks,
> Mukesh
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 23 16:45:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN1W-0002su-Hq; Mon, 23 Jan 2012 16:45: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 1RpN1U-0002s8-DL
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11195 invoked from network); 23 Jan 2012 16:43:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:43:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181748"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPK7032031;	Mon, 23 Jan 2012 08:45:27 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7a22673b930e5cc9dce8a1b43df4c4ca8daf49aa
Message-ID: <7a22673b930e5cc9dce8.1327337125@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:25 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 20] libxl: use keyword arguments for field
 definitions in aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID 7a22673b930e5cc9dce8a1b43df4c4ca8daf49aa
# Parent  63146f3cd17e526c53496adeeddf5da90f13d2bc
libxl: use keyword arguments for field definitions in aggregate types.

The original code is not so bad now that the comments are gone but this is
still a bit cleaner.

No change in the generated code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 63146f3cd17e -r 7a22673b930e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -196,7 +196,7 @@ libxl_domain_build_info = Struct("domain
                                       ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
-                                      ("features", string, True),
+                                      ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", bool),
                                       ])),
diff -r 63146f3cd17e -r 7a22673b930e tools/libxl/libxltypes.py
--- a/tools/libxl/libxltypes.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxltypes.py	Mon Jan 23 16:38:17 2012 +0000
@@ -154,17 +154,17 @@ class Aggregate(Type):
 
         self.fields = []
         for f in fields:
-            # (name, type[, const=False])
+            # (name, type[, {kw args}])
             if len(f) == 2:
                 n,t = f
-                const = False
+                kw = {}
             elif len(f) == 3:
-                n,t,const = f
+                n,t,kw = f
             else:
                 raise ValueError
             if n is None:
                 raise ValueError
-            self.fields.append(Field(t,n,const=const))
+            self.fields.append(Field(t,n,**kw))
 
     # Returns a tuple (stem, field-expr)
     #

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN1W-0002su-Hq; Mon, 23 Jan 2012 16:45: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 1RpN1U-0002s8-DL
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11195 invoked from network); 23 Jan 2012 16:43:20 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:43:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181748"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPK7032031;	Mon, 23 Jan 2012 08:45:27 -0800
MIME-Version: 1.0
X-Mercurial-Node: 7a22673b930e5cc9dce8a1b43df4c4ca8daf49aa
Message-ID: <7a22673b930e5cc9dce8.1327337125@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:25 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 02 of 20] libxl: use keyword arguments for field
 definitions in aggregate types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID 7a22673b930e5cc9dce8a1b43df4c4ca8daf49aa
# Parent  63146f3cd17e526c53496adeeddf5da90f13d2bc
libxl: use keyword arguments for field definitions in aggregate types.

The original code is not so bad now that the comments are gone but this is
still a bit cleaner.

No change in the generated code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 63146f3cd17e -r 7a22673b930e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -196,7 +196,7 @@ libxl_domain_build_info = Struct("domain
                                       ("bootloader_args", libxl_string_list),
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
-                                      ("features", string, True),
+                                      ("features", string, {'const': True}),
                                       # Use host's E820 for PCI passthrough.
                                       ("e820_host", bool),
                                       ])),
diff -r 63146f3cd17e -r 7a22673b930e tools/libxl/libxltypes.py
--- a/tools/libxl/libxltypes.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxltypes.py	Mon Jan 23 16:38:17 2012 +0000
@@ -154,17 +154,17 @@ class Aggregate(Type):
 
         self.fields = []
         for f in fields:
-            # (name, type[, const=False])
+            # (name, type[, {kw args}])
             if len(f) == 2:
                 n,t = f
-                const = False
+                kw = {}
             elif len(f) == 3:
-                n,t,const = f
+                n,t,kw = f
             else:
                 raise ValueError
             if n is None:
                 raise ValueError
-            self.fields.append(Field(t,n,const=const))
+            self.fields.append(Field(t,n,**kw))
 
     # Returns a tuple (stem, field-expr)
     #

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN1X-0002tB-B4; Mon, 23 Jan 2012 16:45:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN1V-0002sC-1q
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11231 invoked from network); 23 Jan 2012 16:43:21 -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;
	23 Jan 2012 16:43:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181750"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPK8032031;	Mon, 23 Jan 2012 08:45:28 -0800
MIME-Version: 1.0
X-Mercurial-Node: a44bd706400238c6f5e309c3925fa90718b80576
Message-ID: <a44bd706400238c6f5e3.1327337126@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 20] ocaml: use libxl IDL type helpers for
 C argument passing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID a44bd706400238c6f5e309c3925fa90718b80576
# Parent  7a22673b930e5cc9dce8a1b43df4c4ca8daf49aa
ocaml: use libxl IDL type helpers for C argument passing

Makes handling of nested structs more correct.

Only change to the generated code right now is that the FOO_Val
(C->ocamlC) function for Enumeration types now takes the C argument by
value instead of reference.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7a22673b930e -r a44bd7064002 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Mon Jan 23 16:38:17 2012 +0000
@@ -112,11 +112,6 @@ def gen_ocaml_ml(ty, interface, indent="
     return s.replace("\n", "\n%s" % indent)
 
 def c_val(ty, c, o, indent="", parent = None):
-    if ty.passby == libxltypes.PASS_BY_REFERENCE:
-        makeref = ""
-    else:
-        makeref = "&"
-
     s = indent
     if isinstance(ty,libxltypes.UInt):
         if ty.width in [8, 16]:
@@ -148,17 +143,18 @@ def c_val(ty, c, o, indent="", parent = 
     elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
-            s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
+            (nparent,fexpr) = ty.member(c, f, parent is None)
+            s += "%s\n" % c_val(f.type, fexpr, "Field(%s, %d)" % (o,n), parent=nparent)
             n = n + 1
     else:
-        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, makeref + c, o)
+        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, ty.pass_arg(c, parent is None, passby=libxltypes.PASS_BY_REFERENCE), o)
     
     return s.replace("\n", "\n%s" % indent)
 
 def gen_c_val(ty, indent=""):
     s = "/* Convert caml value to %s */\n" % ty.rawname
     
-    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s *c_val, value v)\n" % (ty.rawname, ty.typename)
+    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s, value v)\n" % (ty.rawname, ty.make_arg("c_val", passby=libxltypes.PASS_BY_REFERENCE))
     s += "{\n"
     s += "\tCAMLparam1(v);\n"
     s += "\n"
@@ -171,11 +167,6 @@ def gen_c_val(ty, indent=""):
     return s.replace("\n", "\n%s" % indent)
 
 def ocaml_Val(ty, o, c, indent="", parent = None):
-    if ty.passby == libxltypes.PASS_BY_REFERENCE:
-        makeref = ""
-    else:
-        makeref = "&"
-    
     s = indent
     if isinstance(ty,libxltypes.UInt):
         if ty.width in [8, 16]:
@@ -198,7 +189,7 @@ def ocaml_Val(ty, o, c, indent="", paren
         s += "%s = %s;" % (o, fn % { "c": c })
     elif isinstance(ty,libxltypes.Enumeration) and (parent is None):
         n = 0
-        s += "switch(*%s) {\n" % c
+        s += "switch(%s) {\n" % c
         for e in ty.values:
             s += "    case %s: %s = Int_val(%d); break;\n" % (e.name, o, n)
             n += 1
@@ -212,20 +203,22 @@ def ocaml_Val(ty, o, c, indent="", paren
         
         n = 0
         for f in ty.fields:
+            (nparent,fexpr) = ty.member(c, f, parent is None)
+
             s += "\n"
-            s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
+            s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, ty.pass_arg(fexpr, c), parent=nparent)
             s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
             n = n + 1
         s += "}"
     else:
-        s += "%s = Val_%s(gc, lg, %s);" % (o, ty.rawname, makeref + c)
+        s += "%s = Val_%s(gc, lg, %s);" % (o, ty.rawname, ty.pass_arg(c, parent is None))
     
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
 def gen_Val_ocaml(ty, indent=""):
     s = "/* Convert %s to a caml value */\n" % ty.rawname
 
-    s += "static value Val_%s (caml_gc *gc, struct caml_logger *lg, %s *%s_c)\n" % (ty.rawname, ty.typename, ty.rawname)
+    s += "static value Val_%s (caml_gc *gc, struct caml_logger *lg, %s)\n" % (ty.rawname, ty.make_arg(ty.rawname+"_c"))
     s += "{\n"
     s += "\tCAMLparam0();\n"
     s += "\tCAMLlocal1(%s_ocaml);\n" % ty.rawname

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN1X-0002tB-B4; Mon, 23 Jan 2012 16:45:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN1V-0002sC-1q
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11231 invoked from network); 23 Jan 2012 16:43:21 -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;
	23 Jan 2012 16:43:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181750"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:29 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPK8032031;	Mon, 23 Jan 2012 08:45:28 -0800
MIME-Version: 1.0
X-Mercurial-Node: a44bd706400238c6f5e309c3925fa90718b80576
Message-ID: <a44bd706400238c6f5e3.1327337126@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:26 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 03 of 20] ocaml: use libxl IDL type helpers for
 C argument passing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID a44bd706400238c6f5e309c3925fa90718b80576
# Parent  7a22673b930e5cc9dce8a1b43df4c4ca8daf49aa
ocaml: use libxl IDL type helpers for C argument passing

Makes handling of nested structs more correct.

Only change to the generated code right now is that the FOO_Val
(C->ocamlC) function for Enumeration types now takes the C argument by
value instead of reference.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 7a22673b930e -r a44bd7064002 tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Mon Jan 23 16:38:17 2012 +0000
@@ -112,11 +112,6 @@ def gen_ocaml_ml(ty, interface, indent="
     return s.replace("\n", "\n%s" % indent)
 
 def c_val(ty, c, o, indent="", parent = None):
-    if ty.passby == libxltypes.PASS_BY_REFERENCE:
-        makeref = ""
-    else:
-        makeref = "&"
-
     s = indent
     if isinstance(ty,libxltypes.UInt):
         if ty.width in [8, 16]:
@@ -148,17 +143,18 @@ def c_val(ty, c, o, indent="", parent = 
     elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
-            s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
+            (nparent,fexpr) = ty.member(c, f, parent is None)
+            s += "%s\n" % c_val(f.type, fexpr, "Field(%s, %d)" % (o,n), parent=nparent)
             n = n + 1
     else:
-        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, makeref + c, o)
+        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, ty.pass_arg(c, parent is None, passby=libxltypes.PASS_BY_REFERENCE), o)
     
     return s.replace("\n", "\n%s" % indent)
 
 def gen_c_val(ty, indent=""):
     s = "/* Convert caml value to %s */\n" % ty.rawname
     
-    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s *c_val, value v)\n" % (ty.rawname, ty.typename)
+    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s, value v)\n" % (ty.rawname, ty.make_arg("c_val", passby=libxltypes.PASS_BY_REFERENCE))
     s += "{\n"
     s += "\tCAMLparam1(v);\n"
     s += "\n"
@@ -171,11 +167,6 @@ def gen_c_val(ty, indent=""):
     return s.replace("\n", "\n%s" % indent)
 
 def ocaml_Val(ty, o, c, indent="", parent = None):
-    if ty.passby == libxltypes.PASS_BY_REFERENCE:
-        makeref = ""
-    else:
-        makeref = "&"
-    
     s = indent
     if isinstance(ty,libxltypes.UInt):
         if ty.width in [8, 16]:
@@ -198,7 +189,7 @@ def ocaml_Val(ty, o, c, indent="", paren
         s += "%s = %s;" % (o, fn % { "c": c })
     elif isinstance(ty,libxltypes.Enumeration) and (parent is None):
         n = 0
-        s += "switch(*%s) {\n" % c
+        s += "switch(%s) {\n" % c
         for e in ty.values:
             s += "    case %s: %s = Int_val(%d); break;\n" % (e.name, o, n)
             n += 1
@@ -212,20 +203,22 @@ def ocaml_Val(ty, o, c, indent="", paren
         
         n = 0
         for f in ty.fields:
+            (nparent,fexpr) = ty.member(c, f, parent is None)
+
             s += "\n"
-            s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
+            s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, ty.pass_arg(fexpr, c), parent=nparent)
             s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
             n = n + 1
         s += "}"
     else:
-        s += "%s = Val_%s(gc, lg, %s);" % (o, ty.rawname, makeref + c)
+        s += "%s = Val_%s(gc, lg, %s);" % (o, ty.rawname, ty.pass_arg(c, parent is None))
     
     return s.replace("\n", "\n%s" % indent).rstrip(indent)
 
 def gen_Val_ocaml(ty, indent=""):
     s = "/* Convert %s to a caml value */\n" % ty.rawname
 
-    s += "static value Val_%s (caml_gc *gc, struct caml_logger *lg, %s *%s_c)\n" % (ty.rawname, ty.typename, ty.rawname)
+    s += "static value Val_%s (caml_gc *gc, struct caml_logger *lg, %s)\n" % (ty.rawname, ty.make_arg(ty.rawname+"_c"))
     s += "{\n"
     s += "\tCAMLparam0();\n"
     s += "\tCAMLlocal1(%s_ocaml);\n" % ty.rawname

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1W-0002t2-Ti; Mon, 23 Jan 2012 16:45: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 1RpN1U-0002sN-7A
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11442 invoked from network); 23 Jan 2012 16:43:25 -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;
	23 Jan 2012 16:43:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181756"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:33 -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
	q0NGjPKD032031;	Mon, 23 Jan 2012 08:45:33 -0800
MIME-Version: 1.0
X-Mercurial-Node: e6287c6308bd2ef1fb6440ee2be4f0d5492566f9
Message-ID: <e6287c6308bd2ef1fb64.1327337131@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:31 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 20] libxl: now that dm creation takes
 domain_config stop passing down 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336697 0
# Node ID e6287c6308bd2ef1fb6440ee2be4f0d5492566f9
# Parent  c03b3c71a923216fe50882770a72b3cc9f433a85
libxl: now that dm creation takes domain_config stop passing down devices.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c03b3c71a923 -r e6287c6308bd tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
@@ -569,8 +569,6 @@ static int do_domain_create(libxl__gc *g
 
         dm_info->domid = domid;
         ret = libxl__create_device_model(gc, d_config, dm_info,
-                                        d_config->disks, d_config->num_disks,
-                                        d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -616,8 +614,7 @@ static int do_domain_create(libxl__gc *g
             xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
             libxl__create_xenpv_qemu(gc, domid,
-                                     d_config, &xenpv_dm_info,
-                                     d_config->vfbs, &dm_starting);
+                                     d_config, &xenpv_dm_info, &dm_starting);
         }
         break;
     }
diff -r c03b3c71a923 -r e6287c6308bd tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -76,10 +76,10 @@ static const char *libxl__domain_bios(li
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
+    const libxl_device_nic *vifs = guest_config->vifs;
+    const int num_vifs = guest_config->num_vifs;
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -231,11 +231,13 @@ static const char *qemu_disk_format_stri
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_device_disk *disks = guest_config->disks;
+    const libxl_device_nic *vifs = guest_config->vifs;
+    const int num_disks = guest_config->num_disks;
+    const int num_vifs = guest_config->num_vifs;
     flexarray_t *dm_args;
     int i;
 
@@ -496,21 +498,15 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (info->device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info,
-                                                  disks, num_disks,
-                                                  vifs, num_vifs);
+        return libxl__build_device_model_args_old(gc, dm, guest_config, info);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info,
-                                                  disks, num_disks,
-                                                  vifs, num_vifs);
+        return libxl__build_device_model_args_new(gc, dm, guest_config, info);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          info->device_model_version);
@@ -588,16 +584,14 @@ retry_transaction:
 static int libxl__create_stubdom(libxl__gc *gc,
                                  libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
-                                 libxl_device_disk *disks, int num_disks,
-                                 libxl_device_nic *vifs, int num_vifs,
-                                 libxl_device_vfb *vfb,
-                                 libxl_device_vkb *vkb,
                                  libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl_device_console *console;
     libxl_domain_config dm_config;
+    libxl_device_vfb vfb;
+    libxl_device_vkb vkb;
     libxl__domain_build_state state;
     uint32_t domid;
     char **args;
@@ -629,6 +623,19 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
+    dm_config.disks = guest_config->disks;
+    dm_config.num_disks = guest_config->num_disks;
+
+    dm_config.vifs = guest_config->vifs;
+    dm_config.num_vifs = guest_config->num_vifs;
+
+    libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
+
+    dm_config.vfbs = &vfb;
+    dm_config.num_vfbs = 1;
+    dm_config.vkbs = &vkb;
+    dm_config.num_vkbs = 1;
+
     /* fixme: this function can leak the stubdom if it fails */
     domid = 0;
     ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
@@ -639,9 +646,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
 
     args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info,
-                                          disks, num_disks,
-                                          vifs, num_vifs);
+                                          guest_config, info);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
@@ -674,20 +679,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &disks[i]);
+    for (i = 0; i < dm_config.num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, domid, &dm_config.disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &vifs[i]);
+    for (i = 0; i < dm_config.num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, domid, &dm_config.vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, domid, vfb);
+    ret = libxl_device_vfb_add(ctx, domid, &dm_config.vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, domid, vkb);
+    ret = libxl_device_vkb_add(ctx, domid, &dm_config.vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -745,7 +750,7 @@ retry_transaction:
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
                                  &xenpv_dm_info,
-                                 vfb, &dm_starting) < 0) {
+                                 &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -775,8 +780,6 @@ out:
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disks, int num_disks,
-                              libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -791,14 +794,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (info->device_model_stubdomain) {
-        libxl_device_vfb vfb;
-        libxl_device_vkb vkb;
-
-        libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-        rc = libxl__create_stubdom(gc, guest_config, info,
-                                   disks, num_disks,
-                                   vifs, num_vifs,
-                                   &vfb, &vkb, starting_r);
+        rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
         goto out;
     }
 
@@ -813,9 +809,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info,
-                                          disks, num_disks,
-                                          vifs, num_vifs);
+    args = libxl__build_device_model_args(gc, dm, guest_config, info);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
@@ -1036,11 +1030,10 @@ out:
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
-                             libxl_device_vfb *vfb,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, vfb, info);
-    libxl__create_device_model(gc, guest_config, info, NULL, 0, NULL, 0, starting_r);
+    libxl__build_xenpv_qemu_args(gc, domid, &guest_config->vfbs[0], info);
+    libxl__create_device_model(gc, guest_config, info, starting_r);
     return 0;
 }
 
diff -r c03b3c71a923 -r e6287c6308bd tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:17 2012 +0000
@@ -495,13 +495,10 @@ _hidden const char *libxl__domain_device
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disks, int num_disks,
-                              libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
-                              libxl_device_vfb *vfb,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1W-0002t2-Ti; Mon, 23 Jan 2012 16:45: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 1RpN1U-0002sN-7A
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11442 invoked from network); 23 Jan 2012 16:43:25 -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;
	23 Jan 2012 16:43:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181756"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:34 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:33 -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
	q0NGjPKD032031;	Mon, 23 Jan 2012 08:45:33 -0800
MIME-Version: 1.0
X-Mercurial-Node: e6287c6308bd2ef1fb6440ee2be4f0d5492566f9
Message-ID: <e6287c6308bd2ef1fb64.1327337131@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:31 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 08 of 20] libxl: now that dm creation takes
 domain_config stop passing down 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336697 0
# Node ID e6287c6308bd2ef1fb6440ee2be4f0d5492566f9
# Parent  c03b3c71a923216fe50882770a72b3cc9f433a85
libxl: now that dm creation takes domain_config stop passing down devices.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r c03b3c71a923 -r e6287c6308bd tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
@@ -569,8 +569,6 @@ static int do_domain_create(libxl__gc *g
 
         dm_info->domid = domid;
         ret = libxl__create_device_model(gc, d_config, dm_info,
-                                        d_config->disks, d_config->num_disks,
-                                        d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -616,8 +614,7 @@ static int do_domain_create(libxl__gc *g
             xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
             libxl__create_xenpv_qemu(gc, domid,
-                                     d_config, &xenpv_dm_info,
-                                     d_config->vfbs, &dm_starting);
+                                     d_config, &xenpv_dm_info, &dm_starting);
         }
         break;
     }
diff -r c03b3c71a923 -r e6287c6308bd tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -76,10 +76,10 @@ static const char *libxl__domain_bios(li
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
+    const libxl_device_nic *vifs = guest_config->vifs;
+    const int num_vifs = guest_config->num_vifs;
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -231,11 +231,13 @@ static const char *qemu_disk_format_stri
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_device_disk *disks = guest_config->disks;
+    const libxl_device_nic *vifs = guest_config->vifs;
+    const int num_disks = guest_config->num_disks;
+    const int num_vifs = guest_config->num_vifs;
     flexarray_t *dm_args;
     int i;
 
@@ -496,21 +498,15 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
-                                        const libxl_device_disk *disks, int num_disks,
-                                        const libxl_device_nic *vifs, int num_vifs)
+                                        const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (info->device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info,
-                                                  disks, num_disks,
-                                                  vifs, num_vifs);
+        return libxl__build_device_model_args_old(gc, dm, guest_config, info);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info,
-                                                  disks, num_disks,
-                                                  vifs, num_vifs);
+        return libxl__build_device_model_args_new(gc, dm, guest_config, info);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          info->device_model_version);
@@ -588,16 +584,14 @@ retry_transaction:
 static int libxl__create_stubdom(libxl__gc *gc,
                                  libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
-                                 libxl_device_disk *disks, int num_disks,
-                                 libxl_device_nic *vifs, int num_vifs,
-                                 libxl_device_vfb *vfb,
-                                 libxl_device_vkb *vkb,
                                  libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl_device_console *console;
     libxl_domain_config dm_config;
+    libxl_device_vfb vfb;
+    libxl_device_vkb vkb;
     libxl__domain_build_state state;
     uint32_t domid;
     char **args;
@@ -629,6 +623,19 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
+    dm_config.disks = guest_config->disks;
+    dm_config.num_disks = guest_config->num_disks;
+
+    dm_config.vifs = guest_config->vifs;
+    dm_config.num_vifs = guest_config->num_vifs;
+
+    libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
+
+    dm_config.vfbs = &vfb;
+    dm_config.num_vfbs = 1;
+    dm_config.vkbs = &vkb;
+    dm_config.num_vkbs = 1;
+
     /* fixme: this function can leak the stubdom if it fails */
     domid = 0;
     ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
@@ -639,9 +646,7 @@ static int libxl__create_stubdom(libxl__
         goto out;
 
     args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info,
-                                          disks, num_disks,
-                                          vifs, num_vifs);
+                                          guest_config, info);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
@@ -674,20 +679,20 @@ retry_transaction:
         if (errno == EAGAIN)
             goto retry_transaction;
 
-    for (i = 0; i < num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &disks[i]);
+    for (i = 0; i < dm_config.num_disks; i++) {
+        ret = libxl_device_disk_add(ctx, domid, &dm_config.disks[i]);
         if (ret)
             goto out_free;
     }
-    for (i = 0; i < num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &vifs[i]);
+    for (i = 0; i < dm_config.num_vifs; i++) {
+        ret = libxl_device_nic_add(ctx, domid, &dm_config.vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, domid, vfb);
+    ret = libxl_device_vfb_add(ctx, domid, &dm_config.vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, domid, vkb);
+    ret = libxl_device_vkb_add(ctx, domid, &dm_config.vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -745,7 +750,7 @@ retry_transaction:
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
                                  &xenpv_dm_info,
-                                 vfb, &dm_starting) < 0) {
+                                 &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -775,8 +780,6 @@ out:
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disks, int num_disks,
-                              libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -791,14 +794,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (info->device_model_stubdomain) {
-        libxl_device_vfb vfb;
-        libxl_device_vkb vkb;
-
-        libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-        rc = libxl__create_stubdom(gc, guest_config, info,
-                                   disks, num_disks,
-                                   vifs, num_vifs,
-                                   &vfb, &vkb, starting_r);
+        rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
         goto out;
     }
 
@@ -813,9 +809,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info,
-                                          disks, num_disks,
-                                          vifs, num_vifs);
+    args = libxl__build_device_model_args(gc, dm, guest_config, info);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
@@ -1036,11 +1030,10 @@ out:
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
-                             libxl_device_vfb *vfb,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, vfb, info);
-    libxl__create_device_model(gc, guest_config, info, NULL, 0, NULL, 0, starting_r);
+    libxl__build_xenpv_qemu_args(gc, domid, &guest_config->vfbs[0], info);
+    libxl__create_device_model(gc, guest_config, info, starting_r);
     return 0;
 }
 
diff -r c03b3c71a923 -r e6287c6308bd tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:17 2012 +0000
@@ -495,13 +495,10 @@ _hidden const char *libxl__domain_device
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disks, int num_disks,
-                              libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
-                              libxl_device_vfb *vfb,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1Y-0002tv-Cb; Mon, 23 Jan 2012 16:45: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 1RpN1X-0002sy-45
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11631 invoked from network); 23 Jan 2012 16:43:27 -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;
	23 Jan 2012 16:43:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181762"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:36 -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
	q0NGjPKG032031;	Mon, 23 Jan 2012 08:45:35 -0800
MIME-Version: 1.0
X-Mercurial-Node: d3882dfe0aa93b5be6ce1ae85cf9e07f4146b620
Message-ID: <d3882dfe0aa93b5be6ce.1327337134@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:34 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 20] libxl: use vfb[0] directly for xenpv
	device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID d3882dfe0aa93b5be6ce1ae85cf9e07f4146b620
# Parent  e5bc9888a14f19b625489b6b2cd7206c9f3be262
libxl: use vfb[0] directly for xenpv device model

Rather than laundering it via dm info.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e5bc9888a14f -r d3882dfe0aa9 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -73,6 +73,30 @@ static const char *libxl__domain_bios(li
     }
 }
 
+static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config,
+                                    const libxl_device_model_info *info)
+{
+    const libxl_vnc_info *vnc = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        vnc = &info->vnc;
+    } else if (guest_config->num_vfbs > 0) {
+        vnc = &guest_config->vfbs[0].vnc;
+    }
+    return vnc && vnc->enable ? vnc : NULL;
+}
+
+static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config,
+                                    const libxl_device_model_info *info)
+{
+    const libxl_sdl_info *sdl = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        sdl = &info->sdl;
+    } else if (guest_config->num_vfbs > 0) {
+        sdl = &guest_config->vfbs[0].sdl;
+    }
+    return sdl && sdl->enable ? sdl : NULL;
+}
+
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -81,6 +105,8 @@ static char ** libxl__build_device_model
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     const int num_vifs = guest_config->num_vifs;
     int i;
     flexarray_t *dm_args;
@@ -95,45 +121,45 @@ static char ** libxl__build_device_model
     if (c_info->name)
         flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
 
-    if (info->vnc.enable) {
+    if (vnc) {
         char *vncarg;
-        if (info->vnc.display) {
-            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
+        if (vnc->display) {
+            if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
                 vncarg = libxl__sprintf(gc, "%s:%d",
-                                  info->vnc.listen,
-                                  info->vnc.display);
+                                  vnc->listen,
+                                  vnc->display);
             } else {
-                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vnc.display);
+                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", vnc->display);
             }
-        } else if (info->vnc.listen) {
-            if (strchr(info->vnc.listen, ':') != NULL) {
-                vncarg = info->vnc.listen;
+        } else if (vnc->listen) {
+            if (strchr(vnc->listen, ':') != NULL) {
+                vncarg = vnc->listen;
             } else {
-                vncarg = libxl__sprintf(gc, "%s:0", info->vnc.listen);
+                vncarg = libxl__sprintf(gc, "%s:0", vnc->listen);
             }
         } else {
             vncarg = "127.0.0.1:0";
         }
-        if (info->vnc.passwd && (info->vnc.passwd[0] != '\0'))
+        if (vnc->passwd && (vnc->passwd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (info->vnc.findunused) {
+        if (vnc->findunused) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
-    if (info->sdl.enable) {
+    if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!info->sdl.opengl) {
+        if (!sdl->opengl) {
             flexarray_append(dm_args, "-disable-opengl");
         }
-        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
+        /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
+    if (info->nographic && (!sdl && !vnc)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -246,6 +272,8 @@ static char ** libxl__build_device_model
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     flexarray_t *dm_args;
     int i;
 
@@ -273,36 +301,36 @@ static char ** libxl__build_device_model
     if (c_info->name) {
         flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
-    if (info->vnc.enable) {
+    if (vnc) {
         int display = 0;
         const char *listen = "127.0.0.1";
 
-        if (info->vnc.passwd && info->vnc.passwd[0]) {
+        if (vnc->passwd && vnc->passwd[0]) {
             assert(!"missing code for supplying vnc password to qemu");
         }
         flexarray_append(dm_args, "-vnc");
 
-        if (info->vnc.display) {
-            display = info->vnc.display;
-            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
-                listen = info->vnc.listen;
+        if (vnc->display) {
+            display = vnc->display;
+            if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
+                listen = vnc->listen;
             }
-        } else if (info->vnc.listen) {
-            listen = info->vnc.listen;
+        } else if (vnc->listen) {
+            listen = vnc->listen;
         }
 
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        info->vnc.findunused ? ",to=99" : ""));
+                        vnc->findunused ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vnc.findunused ? ",to=99" : ""));
+                        vnc->findunused ? ",to=99" : ""));
     }
-    if (info->sdl.enable) {
+    if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
+        /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->spice.enable) {
         char *spiceoptions = NULL;
@@ -349,7 +377,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
+    if (info->nographic && (!sdl && !vnc)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -795,8 +823,9 @@ int libxl__create_device_model(libxl__gc
                               libxl_device_model_info *info,
                               libxl__spawner_starting **starting_r)
 {
+    libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
@@ -865,7 +894,7 @@ int libxl__create_device_model(libxl__gc
         goto out_close;
     }
 
-    if (info->vnc.passwd) {
+    if (vnc && vnc->passwd) {
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
@@ -874,7 +903,7 @@ retry_transaction:
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
             pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = info->vnc.passwd;
+            pass_stuff[1] = vnc->passwd;
             libxl__xs_writev(gc,t,vm_path,pass_stuff);
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
@@ -983,22 +1012,8 @@ out:
 
 static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
                                         uint32_t domid,
-                                        libxl_device_vfb *vfb,
                                         libxl_device_model_info *info)
 {
-    if (vfb != NULL) {
-        info->vnc.enable = vfb->vnc.enable;
-        if (vfb->vnc.listen)
-            info->vnc.listen = libxl__strdup(gc, vfb->vnc.listen);
-        info->vnc.display = vfb->vnc.display;
-        info->vnc.findunused = vfb->vnc.findunused;
-        if (vfb->vnc.passwd)
-            info->vnc.passwd = vfb->vnc.passwd;
-        if (vfb->keymap)
-            info->keymap = libxl__strdup(gc, vfb->keymap);
-        info->sdl = vfb->sdl;
-    } else
-        info->nographic = 1;
     info->domid = domid;
     return 0;
 }
@@ -1045,7 +1060,7 @@ int libxl__create_xenpv_qemu(libxl__gc *
                              libxl_device_model_info *info,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, &guest_config->vfbs[0], info);
+    libxl__build_xenpv_qemu_args(gc, domid, info);
     libxl__create_device_model(gc, guest_config, info, starting_r);
     return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1Y-0002tv-Cb; Mon, 23 Jan 2012 16:45: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 1RpN1X-0002sy-45
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11631 invoked from network); 23 Jan 2012 16:43:27 -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;
	23 Jan 2012 16:43:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181762"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:36 -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
	q0NGjPKG032031;	Mon, 23 Jan 2012 08:45:35 -0800
MIME-Version: 1.0
X-Mercurial-Node: d3882dfe0aa93b5be6ce1ae85cf9e07f4146b620
Message-ID: <d3882dfe0aa93b5be6ce.1327337134@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:34 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 11 of 20] libxl: use vfb[0] directly for xenpv
	device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID d3882dfe0aa93b5be6ce1ae85cf9e07f4146b620
# Parent  e5bc9888a14f19b625489b6b2cd7206c9f3be262
libxl: use vfb[0] directly for xenpv device model

Rather than laundering it via dm info.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e5bc9888a14f -r d3882dfe0aa9 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -73,6 +73,30 @@ static const char *libxl__domain_bios(li
     }
 }
 
+static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config,
+                                    const libxl_device_model_info *info)
+{
+    const libxl_vnc_info *vnc = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        vnc = &info->vnc;
+    } else if (guest_config->num_vfbs > 0) {
+        vnc = &guest_config->vfbs[0].vnc;
+    }
+    return vnc && vnc->enable ? vnc : NULL;
+}
+
+static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config,
+                                    const libxl_device_model_info *info)
+{
+    const libxl_sdl_info *sdl = NULL;
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        sdl = &info->sdl;
+    } else if (guest_config->num_vfbs > 0) {
+        sdl = &guest_config->vfbs[0].sdl;
+    }
+    return sdl && sdl->enable ? sdl : NULL;
+}
+
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -81,6 +105,8 @@ static char ** libxl__build_device_model
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     const int num_vifs = guest_config->num_vifs;
     int i;
     flexarray_t *dm_args;
@@ -95,45 +121,45 @@ static char ** libxl__build_device_model
     if (c_info->name)
         flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
 
-    if (info->vnc.enable) {
+    if (vnc) {
         char *vncarg;
-        if (info->vnc.display) {
-            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
+        if (vnc->display) {
+            if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
                 vncarg = libxl__sprintf(gc, "%s:%d",
-                                  info->vnc.listen,
-                                  info->vnc.display);
+                                  vnc->listen,
+                                  vnc->display);
             } else {
-                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vnc.display);
+                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", vnc->display);
             }
-        } else if (info->vnc.listen) {
-            if (strchr(info->vnc.listen, ':') != NULL) {
-                vncarg = info->vnc.listen;
+        } else if (vnc->listen) {
+            if (strchr(vnc->listen, ':') != NULL) {
+                vncarg = vnc->listen;
             } else {
-                vncarg = libxl__sprintf(gc, "%s:0", info->vnc.listen);
+                vncarg = libxl__sprintf(gc, "%s:0", vnc->listen);
             }
         } else {
             vncarg = "127.0.0.1:0";
         }
-        if (info->vnc.passwd && (info->vnc.passwd[0] != '\0'))
+        if (vnc->passwd && (vnc->passwd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (info->vnc.findunused) {
+        if (vnc->findunused) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
-    if (info->sdl.enable) {
+    if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        if (!info->sdl.opengl) {
+        if (!sdl->opengl) {
             flexarray_append(dm_args, "-disable-opengl");
         }
-        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
+        /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
+    if (info->nographic && (!sdl && !vnc)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -246,6 +272,8 @@ static char ** libxl__build_device_model
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     flexarray_t *dm_args;
     int i;
 
@@ -273,36 +301,36 @@ static char ** libxl__build_device_model
     if (c_info->name) {
         flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
-    if (info->vnc.enable) {
+    if (vnc) {
         int display = 0;
         const char *listen = "127.0.0.1";
 
-        if (info->vnc.passwd && info->vnc.passwd[0]) {
+        if (vnc->passwd && vnc->passwd[0]) {
             assert(!"missing code for supplying vnc password to qemu");
         }
         flexarray_append(dm_args, "-vnc");
 
-        if (info->vnc.display) {
-            display = info->vnc.display;
-            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
-                listen = info->vnc.listen;
+        if (vnc->display) {
+            display = vnc->display;
+            if (vnc->listen && strchr(vnc->listen, ':') == NULL) {
+                listen = vnc->listen;
             }
-        } else if (info->vnc.listen) {
-            listen = info->vnc.listen;
+        } else if (vnc->listen) {
+            listen = vnc->listen;
         }
 
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        info->vnc.findunused ? ",to=99" : ""));
+                        vnc->findunused ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vnc.findunused ? ",to=99" : ""));
+                        vnc->findunused ? ",to=99" : ""));
     }
-    if (info->sdl.enable) {
+    if (sdl) {
         flexarray_append(dm_args, "-sdl");
-        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
+        /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->spice.enable) {
         char *spiceoptions = NULL;
@@ -349,7 +377,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
+    if (info->nographic && (!sdl && !vnc)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -795,8 +823,9 @@ int libxl__create_device_model(libxl__gc
                               libxl_device_model_info *info,
                               libxl__spawner_starting **starting_r)
 {
+    libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
-    libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
@@ -865,7 +894,7 @@ int libxl__create_device_model(libxl__gc
         goto out_close;
     }
 
-    if (info->vnc.passwd) {
+    if (vnc && vnc->passwd) {
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
@@ -874,7 +903,7 @@ retry_transaction:
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
             pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = info->vnc.passwd;
+            pass_stuff[1] = vnc->passwd;
             libxl__xs_writev(gc,t,vm_path,pass_stuff);
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
@@ -983,22 +1012,8 @@ out:
 
 static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
                                         uint32_t domid,
-                                        libxl_device_vfb *vfb,
                                         libxl_device_model_info *info)
 {
-    if (vfb != NULL) {
-        info->vnc.enable = vfb->vnc.enable;
-        if (vfb->vnc.listen)
-            info->vnc.listen = libxl__strdup(gc, vfb->vnc.listen);
-        info->vnc.display = vfb->vnc.display;
-        info->vnc.findunused = vfb->vnc.findunused;
-        if (vfb->vnc.passwd)
-            info->vnc.passwd = vfb->vnc.passwd;
-        if (vfb->keymap)
-            info->keymap = libxl__strdup(gc, vfb->keymap);
-        info->sdl = vfb->sdl;
-    } else
-        info->nographic = 1;
     info->domid = domid;
     return 0;
 }
@@ -1045,7 +1060,7 @@ int libxl__create_xenpv_qemu(libxl__gc *
                              libxl_device_model_info *info,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, &guest_config->vfbs[0], info);
+    libxl__build_xenpv_qemu_args(gc, domid, info);
     libxl__create_device_model(gc, guest_config, info, starting_r);
     return 0;
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1X-0002tQ-Nv; Mon, 23 Jan 2012 16:45:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN1V-0002sK-Ui
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11354 invoked from network); 23 Jan 2012 16:43:23 -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;
	23 Jan 2012 16:43:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181753"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPKB032031;	Mon, 23 Jan 2012 08:45:31 -0800
MIME-Version: 1.0
X-Mercurial-Node: 16d23a64e9c79955405c44c07f2e39cfb0ad238a
Message-ID: <16d23a64e9c79955405c.1327337129@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:29 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 20] libxl: define libxl_sdl_info to hold
 all info about the SDL config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID 16d23a64e9c79955405c44c07f2e39cfb0ad238a
# Parent  e241db296cbfa86557cd5cfaf7bb870e455dedad
libxl: define libxl_sdl_info to hold all info about the SDL config

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -1941,16 +1941,16 @@ out:
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->display = NULL;
-    vfb->xauthority = NULL;
     vfb->vnc.enable = 1;
     vfb->vnc.passwd = NULL;
     vfb->vnc.listen = strdup("127.0.0.1");
     vfb->vnc.display = 0;
     vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
-    vfb->sdl = 0;
-    vfb->opengl = 0;
+    vfb->sdl.enable = 0;
+    vfb->sdl.opengl = 0;
+    vfb->sdl.display = NULL;
+    vfb->sdl.xauthority = NULL;
     return 0;
 }
 
@@ -2001,16 +2001,19 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
                           libxl__sprintf(gc, "%d", vfb->vnc.findunused));
-    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);
+    flexarray_append_pair(back, "sdl",
+                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+    flexarray_append_pair(back, "opengl",
+                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+    if (vfb->sdl.xauthority) {
+        flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
-    if (vfb->display) {
-        flexarray_append_pair(back, "display", vfb->display);
+    if (vfb->sdl.display) {
+        flexarray_append_pair(back, "display", vfb->sdl.display);
     }
 
-    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
+    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,
diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
@@ -131,8 +131,8 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->vnc.display = 0;
     dm_info->vnc.findunused = 1;
     dm_info->keymap = NULL;
-    dm_info->sdl = 0;
-    dm_info->opengl = 0;
+    dm_info->sdl.enable = 0;
+    dm_info->sdl.opengl = 0;
     dm_info->nographic = 0;
     dm_info->serial = NULL;
     dm_info->boot = strdup("cda");
diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -120,16 +120,17 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-vncunused");
         }
     }
-    if (info->sdl) {
+    if (info->sdl.enable) {
         flexarray_append(dm_args, "-sdl");
-        if (!info->opengl) {
+        if (!info->sdl.opengl) {
             flexarray_append(dm_args, "-disable-opengl");
         }
+        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
+    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -287,8 +288,9 @@ static char ** libxl__build_device_model
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
                         info->vnc.findunused ? ",to=99" : ""));
     }
-    if (info->sdl) {
+    if (info->sdl.enable) {
         flexarray_append(dm_args, "-sdl");
+        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->spice.enable) {
         char *spiceoptions = NULL;
@@ -335,7 +337,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
+    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -526,7 +528,6 @@ static int libxl__vfb_and_vkb_from_devic
     vfb->vnc = info->vnc;
     vfb->keymap = info->keymap;
     vfb->sdl = info->sdl;
-    vfb->opengl = info->opengl;
 
     vkb->backend_domid = 0;
     vkb->devid = 0;
@@ -981,7 +982,6 @@ static int libxl__build_xenpv_qemu_args(
         if (vfb->keymap)
             info->keymap = libxl__strdup(gc, vfb->keymap);
         info->sdl = vfb->sdl;
-        info->opengl = vfb->opengl;
     } else
         info->nographic = 1;
     info->domid = domid;
diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -255,8 +255,7 @@ libxl_device_model_info = Struct("device
     ("vnc",              libxl_vnc_info),
     # keyboard layout, default is en-us keyboard
     ("keymap",           string),
-    ("sdl",              bool),
-    ("opengl",           bool), # (requires sdl enabled)
+    ("sdl",              libxl_sdl_info),
     ("spice",            libxl_spice_info),
     ("nographic",        bool),
     ("gfx_passthru",     bool),
@@ -283,12 +282,9 @@ libxl_device_vfb = Struct("device_vfb", 
     ("backend_domid", libxl_domid),
     ("devid",         integer),
     ("vnc",           libxl_vnc_info),
+    ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
     ("keymap",        string),
-    ("sdl",           bool),
-    ("opengl",        bool), # (if enabled requires sdl enabled)
-    ("display",       string),
-    ("xauthority",    string),
     ])
 
 libxl_device_vkb = Struct("device_vkb", [
diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -371,9 +371,9 @@ static void printf_info(int domid,
         printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
         printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
         printf("\t\t\t(keymap %s)\n", dm_info->keymap);
-        printf("\t\t\t(sdl %d)\n", dm_info->sdl);
+        printf("\t\t\t(sdl %d)\n", dm_info->sdl.enable);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(opengl %d)\n", dm_info->opengl);
+        printf("\t\t\t(opengl %d)\n", dm_info->sdl.opengl);
         printf("\t\t\t(nographic %d)\n", dm_info->nographic);
         printf("\t\t\t(serial %s)\n", dm_info->serial);
         printf("\t\t\t(boot %s)\n", dm_info->boot);
@@ -461,10 +461,10 @@ static void printf_info(int domid,
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
         printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].opengl);
-        printf("\t\t\t(display %s)\n", d_config->vfbs[i].display);
-        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].xauthority);
+        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
+        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
+        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");
         printf("\t)\n");
     }
@@ -976,15 +976,15 @@ skip:
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl = atoi(p2 + 1);
+                    vfb->sdl.enable = atoi(p2 + 1);
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->opengl = atoi(p2 + 1);
+                    vfb->sdl.opengl = atoi(p2 + 1);
                 } else if (!strcmp(p, "display")) {
-                    free(vfb->display);
-                    vfb->display = strdup(p2 + 1);
+                    free(vfb->sdl.display);
+                    vfb->sdl.display = strdup(p2 + 1);
                 } else if (!strcmp(p, "xauthority")) {
-                    free(vfb->xauthority);
-                    vfb->xauthority = strdup(p2 + 1);
+                    free(vfb->sdl.xauthority);
+                    vfb->sdl.xauthority = strdup(p2 + 1);
                 }
             } while ((p = strtok(NULL, ",")) != NULL);
 skip_vfb:
@@ -1187,9 +1187,9 @@ skip_vfb:
             dm_info->vnc.findunused = l;
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            dm_info->sdl = l;
+            dm_info->sdl.enable = l;
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            dm_info->opengl = l;
+            dm_info->sdl.opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1X-0002tQ-Nv; Mon, 23 Jan 2012 16:45:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN1V-0002sK-Ui
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:38 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11354 invoked from network); 23 Jan 2012 16:43:23 -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;
	23 Jan 2012 16:43:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181753"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPKB032031;	Mon, 23 Jan 2012 08:45:31 -0800
MIME-Version: 1.0
X-Mercurial-Node: 16d23a64e9c79955405c44c07f2e39cfb0ad238a
Message-ID: <16d23a64e9c79955405c.1327337129@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:29 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 06 of 20] libxl: define libxl_sdl_info to hold
 all info about the SDL config
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID 16d23a64e9c79955405c44c07f2e39cfb0ad238a
# Parent  e241db296cbfa86557cd5cfaf7bb870e455dedad
libxl: define libxl_sdl_info to hold all info about the SDL config

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -1941,16 +1941,16 @@ out:
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
-    vfb->display = NULL;
-    vfb->xauthority = NULL;
     vfb->vnc.enable = 1;
     vfb->vnc.passwd = NULL;
     vfb->vnc.listen = strdup("127.0.0.1");
     vfb->vnc.display = 0;
     vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
-    vfb->sdl = 0;
-    vfb->opengl = 0;
+    vfb->sdl.enable = 0;
+    vfb->sdl.opengl = 0;
+    vfb->sdl.display = NULL;
+    vfb->sdl.xauthority = NULL;
     return 0;
 }
 
@@ -2001,16 +2001,19 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
                           libxl__sprintf(gc, "%d", vfb->vnc.display));
     flexarray_append_pair(back, "vncunused",
                           libxl__sprintf(gc, "%d", vfb->vnc.findunused));
-    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);
+    flexarray_append_pair(back, "sdl",
+                          libxl__sprintf(gc, "%d", vfb->sdl.enable));
+    flexarray_append_pair(back, "opengl",
+                          libxl__sprintf(gc, "%d", vfb->sdl.opengl));
+    if (vfb->sdl.xauthority) {
+        flexarray_append_pair(back, "xauthority", vfb->sdl.xauthority);
     }
-    if (vfb->display) {
-        flexarray_append_pair(back, "display", vfb->display);
+    if (vfb->sdl.display) {
+        flexarray_append_pair(back, "display", vfb->sdl.display);
     }
 
-    flexarray_append_pair(front, "backend-id", libxl__sprintf(gc, "%d", vfb->backend_domid));
+    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,
diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
@@ -131,8 +131,8 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->vnc.display = 0;
     dm_info->vnc.findunused = 1;
     dm_info->keymap = NULL;
-    dm_info->sdl = 0;
-    dm_info->opengl = 0;
+    dm_info->sdl.enable = 0;
+    dm_info->sdl.opengl = 0;
     dm_info->nographic = 0;
     dm_info->serial = NULL;
     dm_info->boot = strdup("cda");
diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -120,16 +120,17 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-vncunused");
         }
     }
-    if (info->sdl) {
+    if (info->sdl.enable) {
         flexarray_append(dm_args, "-sdl");
-        if (!info->opengl) {
+        if (!info->sdl.opengl) {
             flexarray_append(dm_args, "-disable-opengl");
         }
+        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
+    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -287,8 +288,9 @@ static char ** libxl__build_device_model
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
                         info->vnc.findunused ? ",to=99" : ""));
     }
-    if (info->sdl) {
+    if (info->sdl.enable) {
         flexarray_append(dm_args, "-sdl");
+        /* XXX info->sdl.{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
     if (info->spice.enable) {
         char *spiceoptions = NULL;
@@ -335,7 +337,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
+    if (info->nographic && (!info->sdl.enable && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -526,7 +528,6 @@ static int libxl__vfb_and_vkb_from_devic
     vfb->vnc = info->vnc;
     vfb->keymap = info->keymap;
     vfb->sdl = info->sdl;
-    vfb->opengl = info->opengl;
 
     vkb->backend_domid = 0;
     vkb->devid = 0;
@@ -981,7 +982,6 @@ static int libxl__build_xenpv_qemu_args(
         if (vfb->keymap)
             info->keymap = libxl__strdup(gc, vfb->keymap);
         info->sdl = vfb->sdl;
-        info->opengl = vfb->opengl;
     } else
         info->nographic = 1;
     info->domid = domid;
diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -255,8 +255,7 @@ libxl_device_model_info = Struct("device
     ("vnc",              libxl_vnc_info),
     # keyboard layout, default is en-us keyboard
     ("keymap",           string),
-    ("sdl",              bool),
-    ("opengl",           bool), # (requires sdl enabled)
+    ("sdl",              libxl_sdl_info),
     ("spice",            libxl_spice_info),
     ("nographic",        bool),
     ("gfx_passthru",     bool),
@@ -283,12 +282,9 @@ libxl_device_vfb = Struct("device_vfb", 
     ("backend_domid", libxl_domid),
     ("devid",         integer),
     ("vnc",           libxl_vnc_info),
+    ("sdl",           libxl_sdl_info),
     # set keyboard layout, default is en-us keyboard
     ("keymap",        string),
-    ("sdl",           bool),
-    ("opengl",        bool), # (if enabled requires sdl enabled)
-    ("display",       string),
-    ("xauthority",    string),
     ])
 
 libxl_device_vkb = Struct("device_vkb", [
diff -r e241db296cbf -r 16d23a64e9c7 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -371,9 +371,9 @@ static void printf_info(int domid,
         printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
         printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
         printf("\t\t\t(keymap %s)\n", dm_info->keymap);
-        printf("\t\t\t(sdl %d)\n", dm_info->sdl);
+        printf("\t\t\t(sdl %d)\n", dm_info->sdl.enable);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(opengl %d)\n", dm_info->opengl);
+        printf("\t\t\t(opengl %d)\n", dm_info->sdl.opengl);
         printf("\t\t\t(nographic %d)\n", dm_info->nographic);
         printf("\t\t\t(serial %s)\n", dm_info->serial);
         printf("\t\t\t(boot %s)\n", dm_info->boot);
@@ -461,10 +461,10 @@ static void printf_info(int domid,
         printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
         printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].opengl);
-        printf("\t\t\t(display %s)\n", d_config->vfbs[i].display);
-        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].xauthority);
+        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
+        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
+        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
         printf("\t\t)\n");
         printf("\t)\n");
     }
@@ -976,15 +976,15 @@ skip:
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
                 } else if (!strcmp(p, "sdl")) {
-                    vfb->sdl = atoi(p2 + 1);
+                    vfb->sdl.enable = atoi(p2 + 1);
                 } else if (!strcmp(p, "opengl")) {
-                    vfb->opengl = atoi(p2 + 1);
+                    vfb->sdl.opengl = atoi(p2 + 1);
                 } else if (!strcmp(p, "display")) {
-                    free(vfb->display);
-                    vfb->display = strdup(p2 + 1);
+                    free(vfb->sdl.display);
+                    vfb->sdl.display = strdup(p2 + 1);
                 } else if (!strcmp(p, "xauthority")) {
-                    free(vfb->xauthority);
-                    vfb->xauthority = strdup(p2 + 1);
+                    free(vfb->sdl.xauthority);
+                    vfb->sdl.xauthority = strdup(p2 + 1);
                 }
             } while ((p = strtok(NULL, ",")) != NULL);
 skip_vfb:
@@ -1187,9 +1187,9 @@ skip_vfb:
             dm_info->vnc.findunused = l;
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            dm_info->sdl = l;
+            dm_info->sdl.enable = l;
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            dm_info->opengl = l;
+            dm_info->sdl.opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
             dm_info->spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN1e-0002x3-Pi; Mon, 23 Jan 2012 16:45: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 1RpN1c-0002tO-W4
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11717 invoked from network); 23 Jan 2012 16:43:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:43:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181764"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:37 -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
	q0NGjPKH032031;	Mon, 23 Jan 2012 08:45:36 -0800
MIME-Version: 1.0
X-Mercurial-Node: 188443bf7392231d675ee195e2e72314c8568f8a
Message-ID: <188443bf7392231d675e.1327337135@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:35 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 20] libxl: move HVM emulated GFX support
 into b_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 188443bf7392231d675ee195e2e72314c8568f8a
# Parent  d3882dfe0aa93b5be6ce1ae85cf9e07f4146b620
libxl: move HVM emulated GFX support into b_info->u.hvm

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r d3882dfe0aa9 -r 188443bf7392 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -93,6 +93,16 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
+
+        b_info->u.hvm.stdvga = 0;
+        b_info->u.hvm.vnc.enable = 1;
+        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
+        b_info->u.hvm.vnc.display = 0;
+        b_info->u.hvm.vnc.findunused = 1;
+        b_info->u.hvm.keymap = NULL;
+        b_info->u.hvm.sdl.enable = 0;
+        b_info->u.hvm.sdl.opengl = 0;
+        b_info->u.hvm.nographic = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -118,17 +128,7 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
-    dm_info->videoram = libxl__sizekb_to_mb(b_info->video_memkb);
 
-    dm_info->stdvga = 0;
-    dm_info->vnc.enable = 1;
-    dm_info->vnc.listen = strdup("127.0.0.1");
-    dm_info->vnc.display = 0;
-    dm_info->vnc.findunused = 1;
-    dm_info->keymap = NULL;
-    dm_info->sdl.enable = 0;
-    dm_info->sdl.opengl = 0;
-    dm_info->nographic = 0;
     dm_info->serial = NULL;
     dm_info->boot = strdup("cda");
     dm_info->usb = 0;
diff -r d3882dfe0aa9 -r 188443bf7392 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -78,7 +78,7 @@ static const libxl_vnc_info *dm_vnc(cons
 {
     const libxl_vnc_info *vnc = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        vnc = &info->vnc;
+        vnc = &guest_config->b_info.u.hvm.vnc;
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
@@ -90,13 +90,24 @@ static const libxl_sdl_info *dm_sdl(cons
 {
     const libxl_sdl_info *sdl = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        sdl = &info->sdl;
+        sdl = &guest_config->b_info.u.hvm.sdl;
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
     return sdl && sdl->enable ? sdl : NULL;
 }
 
+static const char *dm_keymap(const libxl_domain_config *guest_config,
+                             const libxl_device_model_info *info)
+{
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        return guest_config->b_info.u.hvm.keymap;
+    } else if (guest_config->num_vfbs > 0) {
+        return guest_config->vfbs[0].keymap;
+    } else
+        return NULL;
+}
+
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -108,6 +119,7 @@ static char ** libxl__build_device_model
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     const int num_vifs = guest_config->num_vifs;
+    const char *keymap = dm_keymap(guest_config, info);
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -156,11 +168,8 @@ static char ** libxl__build_device_model
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
-    if (info->keymap) {
-        flexarray_vappend(dm_args, "-k", info->keymap, NULL);
-    }
-    if (info->nographic && (!sdl && !vnc)) {
-        flexarray_append(dm_args, "-nographic");
+    if (keymap) {
+        flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
     if (info->serial) {
         flexarray_vappend(dm_args, "-serial", info->serial, NULL);
@@ -168,10 +177,17 @@ static char ** libxl__build_device_model
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
-        if (info->videoram) {
-            flexarray_vappend(dm_args, "-videoram", libxl__sprintf(gc, "%d", info->videoram), NULL);
+        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+            flexarray_append(dm_args, "-nographic");
         }
-        if (info->stdvga) {
+
+        if (b_info->video_memkb) {
+            flexarray_vappend(dm_args, "-videoram",
+                    libxl__sprintf(gc, "%d",
+                                   libxl__sizekb_to_mb(b_info->video_memkb)),
+                    NULL);
+        }
+        if (b_info->u.hvm.stdvga) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -225,7 +241,11 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+    } else {
+        if (!sdl && !vnc)
+            flexarray_append(dm_args, "-nographic");
     }
+
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
     }
@@ -260,6 +280,42 @@ static const char *qemu_disk_format_stri
     }
 }
 
+static char *dm_spice_options(libxl__gc *gc,
+                                    const libxl_spice_info *spice)
+{
+    char *opt;
+
+    if (!spice->port && !spice->tls_port) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "at least one of the spiceport or tls_port must be provided");
+        return NULL;
+    }
+
+    if (!spice->disable_ticketing) {
+        if (!spice->passwd) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "spice ticketing is enabled but missing password");
+            return NULL;
+        }
+        else if (!spice->passwd[0]) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                               "spice password can't be empty");
+            return NULL;
+        }
+    }
+    opt = libxl__sprintf(gc, "port=%d,tls-port=%d",
+                         spice->port, spice->tls_port);
+    if (spice->host)
+        opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
+    if (spice->disable_ticketing)
+        opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
+    else
+        opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
+    opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
+                         spice->agent_mouse ? "on" : "off");
+    return opt;
+}
+
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -274,6 +330,7 @@ static char ** libxl__build_device_model
     const int num_vifs = guest_config->num_vifs;
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
+    const char *keymap = dm_keymap(guest_config, info);
     flexarray_t *dm_args;
     int i;
 
@@ -332,61 +389,36 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-sdl");
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
-    if (info->spice.enable) {
-        char *spiceoptions = NULL;
-        if (!info->spice.port && !info->spice.tls_port) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                "at least one of the spiceport or tls_port must be provided");
-            return NULL;
-        }
 
-        if (!info->spice.disable_ticketing) {
-            if (!info->spice.passwd) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                    "spice ticketing is enabled but missing password");
-                return NULL;
-            }
-            else if (!info->spice.passwd[0]) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                    "spice password can't be empty");
-                return NULL;
-            }
-        }
-        spiceoptions = libxl__sprintf(gc, "port=%d,tls-port=%d",
-                                      info->spice.port, info->spice.tls_port);
-        if (info->spice.host)
-            spiceoptions = libxl__sprintf(gc,
-                    "%s,addr=%s", spiceoptions, info->spice.host);
-        if (info->spice.disable_ticketing)
-            spiceoptions = libxl__sprintf(gc, "%s,disable-ticketing",
-                                               spiceoptions);
-        else
-            spiceoptions = libxl__sprintf(gc,
-                    "%s,password=%s", spiceoptions, info->spice.passwd);
-        spiceoptions = libxl__sprintf(gc, "%s,agent-mouse=%s", spiceoptions,
-                                      info->spice.agent_mouse ? "on" : "off");
+    /*if (info->type == LIBXL_DOMAIN_TYPE_PV && !b_info->nographic) {
+        flexarray_vappend(dm_args, "-vga", "xenfb", NULL);
+      } never was possible?*/
 
-        flexarray_append(dm_args, "-spice");
-        flexarray_append(dm_args, spiceoptions);
+    if (keymap) {
+        flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->type == LIBXL_DOMAIN_TYPE_PV && !info->nographic) {
-        flexarray_vappend(dm_args, "-vga", "xenfb", NULL);
-    }
-
-    if (info->keymap) {
-        flexarray_vappend(dm_args, "-k", info->keymap, NULL);
-    }
-    if (info->nographic && (!sdl && !vnc)) {
-        flexarray_append(dm_args, "-nographic");
-    }
     if (info->serial) {
         flexarray_vappend(dm_args, "-serial", info->serial, NULL);
     }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
-        if (info->stdvga) {
+        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+            flexarray_append(dm_args, "-nographic");
+        }
+
+        if (b_info->u.hvm.spice.enable) {
+            const libxl_spice_info *spice = &b_info->u.hvm.spice;
+            char *spiceoptions = dm_spice_options(gc, spice);
+            if (!spiceoptions)
+                return NULL;
+
+            flexarray_append(dm_args, "-spice");
+            flexarray_append(dm_args, spiceoptions);
+        }
+
+        if (b_info->u.hvm.stdvga) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -446,7 +478,12 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+    } else {
+        if (!sdl && !vnc) {
+            flexarray_append(dm_args, "-nographic");
+        }
     }
+
     if (info->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
         int migration_fd = open(info->saved_state, O_RDONLY);
@@ -555,19 +592,24 @@ static char ** libxl__build_device_model
     }
 }
 
-static int libxl__vfb_and_vkb_from_device_model_info(libxl__gc *gc,
-                                        const libxl_device_model_info *info,
+static int libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc *gc,
+                                        const libxl_domain_config *guest_config,
                                         libxl_device_vfb *vfb,
                                         libxl_device_vkb *vkb)
 {
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
+
+    if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
-    vfb->vnc = info->vnc;
-    vfb->keymap = info->keymap;
-    vfb->sdl = info->sdl;
+    vfb->vnc = b_info->u.hvm.vnc;
+    vfb->keymap = b_info->u.hvm.keymap;
+    vfb->sdl = b_info->u.hvm.sdl;
 
     vkb->backend_domid = 0;
     vkb->devid = 0;
@@ -670,8 +712,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
-    libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-
+    libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
     dm_config.vkbs = &vkb;
diff -r d3882dfe0aa9 -r 188443bf7392 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -219,6 +219,13 @@ libxl_domain_build_info = Struct("domain
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
                                        ("no_incr_generationid", bool),
+                                       ("nographic",        bool),
+                                       ("stdvga",           bool),
+                                       ("vnc",              libxl_vnc_info),
+                                       # keyboard layout, default is en-us keyboard
+                                       ("keymap",           string),
+                                       ("sdl",              libxl_sdl_info),
+                                       ("spice",            libxl_spice_info),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -247,15 +254,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    # size of the videoram in MB
-    ("videoram",         integer), 
-    ("stdvga",           bool),
-    ("vnc",              libxl_vnc_info),
-    # keyboard layout, default is en-us keyboard
-    ("keymap",           string),
-    ("sdl",              libxl_sdl_info),
-    ("spice",            libxl_spice_info),
-    ("nographic",        bool),
     ("gfx_passthru",     bool),
     ("serial",           string),
     ("boot",             string),
diff -r d3882dfe0aa9 -r 188443bf7392 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -363,29 +363,29 @@ static void printf_info(int domid,
         printf("\t\t\t(no_incr_generationid %d)\n",
                     b_info->u.hvm.no_incr_generationid);
 
+        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
+        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
+        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
+        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
+        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
+        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
+        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
+        printf("\t\t\t(spicedisable_ticketing %d)\n",
+                    b_info->u.hvm.spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
-        printf("\t\t\t(videoram %d)\n", dm_info->videoram);
-        printf("\t\t\t(stdvga %d)\n", dm_info->stdvga);
-        printf("\t\t\t(vnc %d)\n", dm_info->vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", dm_info->vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
-        printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", dm_info->keymap);
-        printf("\t\t\t(sdl %d)\n", dm_info->sdl.enable);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(opengl %d)\n", dm_info->sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", dm_info->nographic);
         printf("\t\t\t(serial %s)\n", dm_info->serial);
         printf("\t\t\t(boot %s)\n", dm_info->boot);
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
-        printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
-        printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
-        printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);
-        printf("\t\t\t(spicehost %s)\n", dm_info->spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    dm_info->spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spice.agent_mouse);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1175,37 +1175,38 @@ skip_vfb:
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            dm_info->stdvga = l;
+            b_info->u.hvm.stdvga = l;
         if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            dm_info->vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vnc.passwd, 0);
+            b_info->u.hvm.vnc.enable = l;
+        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
-            dm_info->vnc.display = l;
+            b_info->u.hvm.vnc.display = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            dm_info->vnc.findunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            dm_info->sdl.enable = l;
+            b_info->u.hvm.sdl.enable = l;
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            dm_info->sdl.opengl = l;
+            b_info->u.hvm.sdl.opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            dm_info->spice.enable = l;
+            b_info->u.hvm.spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
-            dm_info->spice.port = l;
+            b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
-            dm_info->spice.tls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spice.host, 0);
+            b_info->u.hvm.spice.tls_port = l;
+        xlu_cfg_replace_string (config, "spicehost",
+                                &b_info->u.hvm.spice.host, 0);
         if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            dm_info->spice.disable_ticketing = l;
+            b_info->u.hvm.spice.disable_ticketing = l;
         xlu_cfg_replace_string (config, "spicepasswd",
-                                &dm_info->spice.passwd, 0);
+                                &b_info->u.hvm.spice.passwd, 0);
         if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            dm_info->spice.agent_mouse = l;
+            b_info->u.hvm.spice.agent_mouse = l;
         else
-            dm_info->spice.agent_mouse = 1;
+            b_info->u.hvm.spice.agent_mouse = 1;
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            dm_info->nographic = l;
+            b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN1e-0002x3-Pi; Mon, 23 Jan 2012 16:45: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 1RpN1c-0002tO-W4
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:45 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!6
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11717 invoked from network); 23 Jan 2012 16:43:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:43:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181764"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:37 -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
	q0NGjPKH032031;	Mon, 23 Jan 2012 08:45:36 -0800
MIME-Version: 1.0
X-Mercurial-Node: 188443bf7392231d675ee195e2e72314c8568f8a
Message-ID: <188443bf7392231d675e.1327337135@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:35 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 12 of 20] libxl: move HVM emulated GFX support
 into b_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 188443bf7392231d675ee195e2e72314c8568f8a
# Parent  d3882dfe0aa93b5be6ce1ae85cf9e07f4146b620
libxl: move HVM emulated GFX support into b_info->u.hvm

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r d3882dfe0aa9 -r 188443bf7392 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -93,6 +93,16 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.timer_mode = 1;
         b_info->u.hvm.nested_hvm = 0;
         b_info->u.hvm.no_incr_generationid = 0;
+
+        b_info->u.hvm.stdvga = 0;
+        b_info->u.hvm.vnc.enable = 1;
+        b_info->u.hvm.vnc.listen = strdup("127.0.0.1");
+        b_info->u.hvm.vnc.display = 0;
+        b_info->u.hvm.vnc.findunused = 1;
+        b_info->u.hvm.keymap = NULL;
+        b_info->u.hvm.sdl.enable = 0;
+        b_info->u.hvm.sdl.opengl = 0;
+        b_info->u.hvm.nographic = 0;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -118,17 +128,7 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
-    dm_info->videoram = libxl__sizekb_to_mb(b_info->video_memkb);
 
-    dm_info->stdvga = 0;
-    dm_info->vnc.enable = 1;
-    dm_info->vnc.listen = strdup("127.0.0.1");
-    dm_info->vnc.display = 0;
-    dm_info->vnc.findunused = 1;
-    dm_info->keymap = NULL;
-    dm_info->sdl.enable = 0;
-    dm_info->sdl.opengl = 0;
-    dm_info->nographic = 0;
     dm_info->serial = NULL;
     dm_info->boot = strdup("cda");
     dm_info->usb = 0;
diff -r d3882dfe0aa9 -r 188443bf7392 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -78,7 +78,7 @@ static const libxl_vnc_info *dm_vnc(cons
 {
     const libxl_vnc_info *vnc = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        vnc = &info->vnc;
+        vnc = &guest_config->b_info.u.hvm.vnc;
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
     }
@@ -90,13 +90,24 @@ static const libxl_sdl_info *dm_sdl(cons
 {
     const libxl_sdl_info *sdl = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        sdl = &info->sdl;
+        sdl = &guest_config->b_info.u.hvm.sdl;
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
     }
     return sdl && sdl->enable ? sdl : NULL;
 }
 
+static const char *dm_keymap(const libxl_domain_config *guest_config,
+                             const libxl_device_model_info *info)
+{
+    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+        return guest_config->b_info.u.hvm.keymap;
+    } else if (guest_config->num_vfbs > 0) {
+        return guest_config->vfbs[0].keymap;
+    } else
+        return NULL;
+}
+
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -108,6 +119,7 @@ static char ** libxl__build_device_model
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
     const int num_vifs = guest_config->num_vifs;
+    const char *keymap = dm_keymap(guest_config, info);
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -156,11 +168,8 @@ static char ** libxl__build_device_model
         }
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
-    if (info->keymap) {
-        flexarray_vappend(dm_args, "-k", info->keymap, NULL);
-    }
-    if (info->nographic && (!sdl && !vnc)) {
-        flexarray_append(dm_args, "-nographic");
+    if (keymap) {
+        flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
     if (info->serial) {
         flexarray_vappend(dm_args, "-serial", info->serial, NULL);
@@ -168,10 +177,17 @@ static char ** libxl__build_device_model
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
-        if (info->videoram) {
-            flexarray_vappend(dm_args, "-videoram", libxl__sprintf(gc, "%d", info->videoram), NULL);
+        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+            flexarray_append(dm_args, "-nographic");
         }
-        if (info->stdvga) {
+
+        if (b_info->video_memkb) {
+            flexarray_vappend(dm_args, "-videoram",
+                    libxl__sprintf(gc, "%d",
+                                   libxl__sizekb_to_mb(b_info->video_memkb)),
+                    NULL);
+        }
+        if (b_info->u.hvm.stdvga) {
             flexarray_append(dm_args, "-std-vga");
         }
 
@@ -225,7 +241,11 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+    } else {
+        if (!sdl && !vnc)
+            flexarray_append(dm_args, "-nographic");
     }
+
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
     }
@@ -260,6 +280,42 @@ static const char *qemu_disk_format_stri
     }
 }
 
+static char *dm_spice_options(libxl__gc *gc,
+                                    const libxl_spice_info *spice)
+{
+    char *opt;
+
+    if (!spice->port && !spice->tls_port) {
+        LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                   "at least one of the spiceport or tls_port must be provided");
+        return NULL;
+    }
+
+    if (!spice->disable_ticketing) {
+        if (!spice->passwd) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                       "spice ticketing is enabled but missing password");
+            return NULL;
+        }
+        else if (!spice->passwd[0]) {
+            LIBXL__LOG(CTX, LIBXL__LOG_ERROR,
+                               "spice password can't be empty");
+            return NULL;
+        }
+    }
+    opt = libxl__sprintf(gc, "port=%d,tls-port=%d",
+                         spice->port, spice->tls_port);
+    if (spice->host)
+        opt = libxl__sprintf(gc, "%s,addr=%s", opt, spice->host);
+    if (spice->disable_ticketing)
+        opt = libxl__sprintf(gc, "%s,disable-ticketing", opt);
+    else
+        opt = libxl__sprintf(gc, "%s,password=%s", opt, spice->passwd);
+    opt = libxl__sprintf(gc, "%s,agent-mouse=%s", opt,
+                         spice->agent_mouse ? "on" : "off");
+    return opt;
+}
+
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
@@ -274,6 +330,7 @@ static char ** libxl__build_device_model
     const int num_vifs = guest_config->num_vifs;
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
+    const char *keymap = dm_keymap(guest_config, info);
     flexarray_t *dm_args;
     int i;
 
@@ -332,61 +389,36 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-sdl");
         /* XXX sdl->{display,xauthority} into $DISPLAY/$XAUTHORITY */
     }
-    if (info->spice.enable) {
-        char *spiceoptions = NULL;
-        if (!info->spice.port && !info->spice.tls_port) {
-            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                "at least one of the spiceport or tls_port must be provided");
-            return NULL;
-        }
 
-        if (!info->spice.disable_ticketing) {
-            if (!info->spice.passwd) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                    "spice ticketing is enabled but missing password");
-                return NULL;
-            }
-            else if (!info->spice.passwd[0]) {
-                LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-                    "spice password can't be empty");
-                return NULL;
-            }
-        }
-        spiceoptions = libxl__sprintf(gc, "port=%d,tls-port=%d",
-                                      info->spice.port, info->spice.tls_port);
-        if (info->spice.host)
-            spiceoptions = libxl__sprintf(gc,
-                    "%s,addr=%s", spiceoptions, info->spice.host);
-        if (info->spice.disable_ticketing)
-            spiceoptions = libxl__sprintf(gc, "%s,disable-ticketing",
-                                               spiceoptions);
-        else
-            spiceoptions = libxl__sprintf(gc,
-                    "%s,password=%s", spiceoptions, info->spice.passwd);
-        spiceoptions = libxl__sprintf(gc, "%s,agent-mouse=%s", spiceoptions,
-                                      info->spice.agent_mouse ? "on" : "off");
+    /*if (info->type == LIBXL_DOMAIN_TYPE_PV && !b_info->nographic) {
+        flexarray_vappend(dm_args, "-vga", "xenfb", NULL);
+      } never was possible?*/
 
-        flexarray_append(dm_args, "-spice");
-        flexarray_append(dm_args, spiceoptions);
+    if (keymap) {
+        flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->type == LIBXL_DOMAIN_TYPE_PV && !info->nographic) {
-        flexarray_vappend(dm_args, "-vga", "xenfb", NULL);
-    }
-
-    if (info->keymap) {
-        flexarray_vappend(dm_args, "-k", info->keymap, NULL);
-    }
-    if (info->nographic && (!sdl && !vnc)) {
-        flexarray_append(dm_args, "-nographic");
-    }
     if (info->serial) {
         flexarray_vappend(dm_args, "-serial", info->serial, NULL);
     }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
-        if (info->stdvga) {
+        if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
+            flexarray_append(dm_args, "-nographic");
+        }
+
+        if (b_info->u.hvm.spice.enable) {
+            const libxl_spice_info *spice = &b_info->u.hvm.spice;
+            char *spiceoptions = dm_spice_options(gc, spice);
+            if (!spiceoptions)
+                return NULL;
+
+            flexarray_append(dm_args, "-spice");
+            flexarray_append(dm_args, spiceoptions);
+        }
+
+        if (b_info->u.hvm.stdvga) {
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
@@ -446,7 +478,12 @@ static char ** libxl__build_device_model
         if (info->gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
+    } else {
+        if (!sdl && !vnc) {
+            flexarray_append(dm_args, "-nographic");
+        }
     }
+
     if (info->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
         int migration_fd = open(info->saved_state, O_RDONLY);
@@ -555,19 +592,24 @@ static char ** libxl__build_device_model
     }
 }
 
-static int libxl__vfb_and_vkb_from_device_model_info(libxl__gc *gc,
-                                        const libxl_device_model_info *info,
+static int libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc *gc,
+                                        const libxl_domain_config *guest_config,
                                         libxl_device_vfb *vfb,
                                         libxl_device_vkb *vkb)
 {
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
+
+    if (b_info->type != LIBXL_DOMAIN_TYPE_HVM)
+        return ERROR_INVAL;
+
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
 
     vfb->backend_domid = 0;
     vfb->devid = 0;
-    vfb->vnc = info->vnc;
-    vfb->keymap = info->keymap;
-    vfb->sdl = info->sdl;
+    vfb->vnc = b_info->u.hvm.vnc;
+    vfb->keymap = b_info->u.hvm.keymap;
+    vfb->sdl = b_info->u.hvm.sdl;
 
     vkb->backend_domid = 0;
     vkb->devid = 0;
@@ -670,8 +712,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.vifs = guest_config->vifs;
     dm_config.num_vifs = guest_config->num_vifs;
 
-    libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-
+    libxl__vfb_and_vkb_from_hvm_guest_config(gc, guest_config, &vfb, &vkb);
     dm_config.vfbs = &vfb;
     dm_config.num_vfbs = 1;
     dm_config.vkbs = &vkb;
diff -r d3882dfe0aa9 -r 188443bf7392 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -219,6 +219,13 @@ libxl_domain_build_info = Struct("domain
                                        ("timer_mode", integer),
                                        ("nested_hvm", bool),
                                        ("no_incr_generationid", bool),
+                                       ("nographic",        bool),
+                                       ("stdvga",           bool),
+                                       ("vnc",              libxl_vnc_info),
+                                       # keyboard layout, default is en-us keyboard
+                                       ("keymap",           string),
+                                       ("sdl",              libxl_sdl_info),
+                                       ("spice",            libxl_spice_info),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -247,15 +254,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    # size of the videoram in MB
-    ("videoram",         integer), 
-    ("stdvga",           bool),
-    ("vnc",              libxl_vnc_info),
-    # keyboard layout, default is en-us keyboard
-    ("keymap",           string),
-    ("sdl",              libxl_sdl_info),
-    ("spice",            libxl_spice_info),
-    ("nographic",        bool),
     ("gfx_passthru",     bool),
     ("serial",           string),
     ("boot",             string),
diff -r d3882dfe0aa9 -r 188443bf7392 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -363,29 +363,29 @@ static void printf_info(int domid,
         printf("\t\t\t(no_incr_generationid %d)\n",
                     b_info->u.hvm.no_incr_generationid);
 
+        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
+        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
+        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
+        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
+        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
+        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
+        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
+        printf("\t\t\t(spicedisable_ticketing %d)\n",
+                    b_info->u.hvm.spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
-        printf("\t\t\t(videoram %d)\n", dm_info->videoram);
-        printf("\t\t\t(stdvga %d)\n", dm_info->stdvga);
-        printf("\t\t\t(vnc %d)\n", dm_info->vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", dm_info->vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
-        printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", dm_info->keymap);
-        printf("\t\t\t(sdl %d)\n", dm_info->sdl.enable);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(opengl %d)\n", dm_info->sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", dm_info->nographic);
         printf("\t\t\t(serial %s)\n", dm_info->serial);
         printf("\t\t\t(boot %s)\n", dm_info->boot);
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
-        printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
-        printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
-        printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);
-        printf("\t\t\t(spicehost %s)\n", dm_info->spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    dm_info->spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spice.agent_mouse);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1175,37 +1175,38 @@ skip_vfb:
 
     if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
-            dm_info->stdvga = l;
+            b_info->u.hvm.stdvga = l;
         if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            dm_info->vnc.enable = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnc.listen, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vnc.passwd, 0);
+            b_info->u.hvm.vnc.enable = l;
+        xlu_cfg_replace_string (config, "vnclisten", &b_info->u.hvm.vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &b_info->u.hvm.vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
-            dm_info->vnc.display = l;
+            b_info->u.hvm.vnc.display = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            dm_info->vnc.findunused = l;
-        xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
+            b_info->u.hvm.vnc.findunused = l;
+        xlu_cfg_replace_string (config, "keymap", &b_info->u.hvm.keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
-            dm_info->sdl.enable = l;
+            b_info->u.hvm.sdl.enable = l;
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
-            dm_info->sdl.opengl = l;
+            b_info->u.hvm.sdl.opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            dm_info->spice.enable = l;
+            b_info->u.hvm.spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
-            dm_info->spice.port = l;
+            b_info->u.hvm.spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
-            dm_info->spice.tls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spice.host, 0);
+            b_info->u.hvm.spice.tls_port = l;
+        xlu_cfg_replace_string (config, "spicehost",
+                                &b_info->u.hvm.spice.host, 0);
         if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            dm_info->spice.disable_ticketing = l;
+            b_info->u.hvm.spice.disable_ticketing = l;
         xlu_cfg_replace_string (config, "spicepasswd",
-                                &dm_info->spice.passwd, 0);
+                                &b_info->u.hvm.spice.passwd, 0);
         if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            dm_info->spice.agent_mouse = l;
+            b_info->u.hvm.spice.agent_mouse = l;
         else
-            dm_info->spice.agent_mouse = 1;
+            b_info->u.hvm.spice.agent_mouse = 1;
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
-            dm_info->nographic = l;
+            b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1g-0002ys-Rr; Mon, 23 Jan 2012 16:45:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN1f-0002uU-5D
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!8
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11905 invoked from network); 23 Jan 2012 16:43:31 -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;
	23 Jan 2012 16:43:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181768"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:40 -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
	q0NGjPKK032031;	Mon, 23 Jan 2012 08:45:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: e5f62c6ec77ce933d4f5f92758e7d4aa5a7a6369
Message-ID: <e5f62c6ec77ce933d4f5.1327337138@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 20] libxl: Remove
	libxl_device_model_info.type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID e5f62c6ec77ce933d4f5f92758e7d4aa5a7a6369
# Parent  b8a133e35c9100d301a19c217ee275b0a01ae55c
libxl: Remove libxl_device_model_info.type.

This is the type of the target guest which is part of the guest config.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r b8a133e35c91 -r e5f62c6ec77c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -602,7 +602,6 @@ static int do_domain_create(libxl__gc *g
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
             xenpv_dm_info.device_model_version =
                 d_config->dm_info.device_model_version;
-            xenpv_dm_info.type = d_config->dm_info.type;
             xenpv_dm_info.device_model = d_config->dm_info.device_model;
             xenpv_dm_info.extra = d_config->dm_info.extra;
             xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
diff -r b8a133e35c91 -r e5f62c6ec77c tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -77,7 +77,7 @@ static const libxl_vnc_info *dm_vnc(cons
                                     const libxl_device_model_info *info)
 {
     const libxl_vnc_info *vnc = NULL;
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         vnc = &guest_config->b_info.u.hvm.vnc;
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
@@ -89,7 +89,7 @@ static const libxl_sdl_info *dm_sdl(cons
                                     const libxl_device_model_info *info)
 {
     const libxl_sdl_info *sdl = NULL;
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         sdl = &guest_config->b_info.u.hvm.sdl;
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
@@ -100,7 +100,7 @@ static const libxl_sdl_info *dm_sdl(cons
 static const char *dm_keymap(const libxl_domain_config *guest_config,
                              const libxl_device_model_info *info)
 {
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         return guest_config->b_info.u.hvm.keymap;
     } else if (guest_config->num_vfbs > 0) {
         return guest_config->vfbs[0].keymap;
@@ -171,7 +171,7 @@ static char ** libxl__build_device_model
     if (keymap) {
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
         if (b_info->u.hvm.serial) {
@@ -254,7 +254,7 @@ static char ** libxl__build_device_model
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
     flexarray_append(dm_args, "-M");
-    switch (info->type) {
+    switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
         for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
@@ -353,7 +353,7 @@ static char ** libxl__build_device_model
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
 
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
         flexarray_append(dm_args, "-xen-attach");
     }
 
@@ -400,7 +400,7 @@ static char ** libxl__build_device_model
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
         if (b_info->u.hvm.serial) {
@@ -498,7 +498,7 @@ static char ** libxl__build_device_model
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
     flexarray_append(dm_args, "-M");
-    switch (info->type) {
+    switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
         for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
@@ -517,7 +517,7 @@ static char ** libxl__build_device_model
                      libxl__sprintf(gc, "%d",
                                     libxl__sizekb_to_mb(b_info->target_memkb)));
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         for (i = 0; i < num_disks; i++) {
             int disk, part;
             int dev_number =
@@ -700,6 +700,7 @@ static int libxl__create_stubdom(libxl__
     libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
 
     memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    dm_config.b_info.type = dm_config.c_info.type;
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
@@ -828,7 +829,6 @@ retry_transaction:
 
     memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
     xenpv_dm_info.device_model_version = info->device_model_version;
-    xenpv_dm_info.type = LIBXL_DOMAIN_TYPE_PV;
     xenpv_dm_info.device_model = info->device_model;
     xenpv_dm_info.extra = info->extra;
     xenpv_dm_info.extra_pv = info->extra_pv;
diff -r b8a133e35c91 -r e5f62c6ec77c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -265,7 +265,6 @@ libxl_device_model_info = Struct("device
     # you set device_model you must set device_model_version too
     ("device_model",     string),
     ("saved_state",      string),
-    ("type",             libxl_domain_type),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r b8a133e35c91 -r e5f62c6ec77c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -1216,8 +1216,6 @@ skip_vfb:
             b_info->u.hvm.xen_platform_pci = l;
     }
 
-    dm_info->type = c_info->type;
-
     xlu_cfg_destroy(config);
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1g-0002ys-Rr; Mon, 23 Jan 2012 16:45:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN1f-0002uU-5D
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:47 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!8
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11905 invoked from network); 23 Jan 2012 16:43:31 -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;
	23 Jan 2012 16:43:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181768"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:40 -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
	q0NGjPKK032031;	Mon, 23 Jan 2012 08:45:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: e5f62c6ec77ce933d4f5f92758e7d4aa5a7a6369
Message-ID: <e5f62c6ec77ce933d4f5.1327337138@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:38 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 15 of 20] libxl: Remove
	libxl_device_model_info.type
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID e5f62c6ec77ce933d4f5f92758e7d4aa5a7a6369
# Parent  b8a133e35c9100d301a19c217ee275b0a01ae55c
libxl: Remove libxl_device_model_info.type.

This is the type of the target guest which is part of the guest config.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r b8a133e35c91 -r e5f62c6ec77c tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -602,7 +602,6 @@ static int do_domain_create(libxl__gc *g
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
             xenpv_dm_info.device_model_version =
                 d_config->dm_info.device_model_version;
-            xenpv_dm_info.type = d_config->dm_info.type;
             xenpv_dm_info.device_model = d_config->dm_info.device_model;
             xenpv_dm_info.extra = d_config->dm_info.extra;
             xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
diff -r b8a133e35c91 -r e5f62c6ec77c tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -77,7 +77,7 @@ static const libxl_vnc_info *dm_vnc(cons
                                     const libxl_device_model_info *info)
 {
     const libxl_vnc_info *vnc = NULL;
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         vnc = &guest_config->b_info.u.hvm.vnc;
     } else if (guest_config->num_vfbs > 0) {
         vnc = &guest_config->vfbs[0].vnc;
@@ -89,7 +89,7 @@ static const libxl_sdl_info *dm_sdl(cons
                                     const libxl_device_model_info *info)
 {
     const libxl_sdl_info *sdl = NULL;
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         sdl = &guest_config->b_info.u.hvm.sdl;
     } else if (guest_config->num_vfbs > 0) {
         sdl = &guest_config->vfbs[0].sdl;
@@ -100,7 +100,7 @@ static const libxl_sdl_info *dm_sdl(cons
 static const char *dm_keymap(const libxl_domain_config *guest_config,
                              const libxl_device_model_info *info)
 {
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         return guest_config->b_info.u.hvm.keymap;
     } else if (guest_config->num_vfbs > 0) {
         return guest_config->vfbs[0].keymap;
@@ -171,7 +171,7 @@ static char ** libxl__build_device_model
     if (keymap) {
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
         if (b_info->u.hvm.serial) {
@@ -254,7 +254,7 @@ static char ** libxl__build_device_model
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
     flexarray_append(dm_args, "-M");
-    switch (info->type) {
+    switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
         for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
@@ -353,7 +353,7 @@ static char ** libxl__build_device_model
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
 
-    if (info->type == LIBXL_DOMAIN_TYPE_PV) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
         flexarray_append(dm_args, "-xen-attach");
     }
 
@@ -400,7 +400,7 @@ static char ** libxl__build_device_model
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
         if (b_info->u.hvm.serial) {
@@ -498,7 +498,7 @@ static char ** libxl__build_device_model
     for (i = 0; info->extra && info->extra[i] != NULL; i++)
         flexarray_append(dm_args, info->extra[i]);
     flexarray_append(dm_args, "-M");
-    switch (info->type) {
+    switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
         for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
@@ -517,7 +517,7 @@ static char ** libxl__build_device_model
                      libxl__sprintf(gc, "%d",
                                     libxl__sizekb_to_mb(b_info->target_memkb)));
 
-    if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM) {
         for (i = 0; i < num_disks; i++) {
             int disk, part;
             int dev_number =
@@ -700,6 +700,7 @@ static int libxl__create_stubdom(libxl__
     libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
 
     memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    dm_config.b_info.type = dm_config.c_info.type;
     dm_config.b_info.max_vcpus = 1;
     dm_config.b_info.max_memkb = 32 * 1024;
     dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
@@ -828,7 +829,6 @@ retry_transaction:
 
     memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
     xenpv_dm_info.device_model_version = info->device_model_version;
-    xenpv_dm_info.type = LIBXL_DOMAIN_TYPE_PV;
     xenpv_dm_info.device_model = info->device_model;
     xenpv_dm_info.extra = info->extra;
     xenpv_dm_info.extra_pv = info->extra_pv;
diff -r b8a133e35c91 -r e5f62c6ec77c tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -265,7 +265,6 @@ libxl_device_model_info = Struct("device
     # you set device_model you must set device_model_version too
     ("device_model",     string),
     ("saved_state",      string),
-    ("type",             libxl_domain_type),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r b8a133e35c91 -r e5f62c6ec77c tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -1216,8 +1216,6 @@ skip_vfb:
             b_info->u.hvm.xen_platform_pci = l;
     }
 
-    dm_info->type = c_info->type;
-
     xlu_cfg_destroy(config);
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1i-00030g-Be; Mon, 23 Jan 2012 16:45: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 1RpN1f-0002vV-QW
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!9
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12048 invoked from network); 23 Jan 2012 16:43:33 -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;
	23 Jan 2012 16:43:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181771"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:42 -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
	q0NGjPKM032031;	Mon, 23 Jan 2012 08:45:41 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3101b9483229b61afe4945949832c04abe323a59
Message-ID: <3101b9483229b61afe49.1327337140@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:40 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 17 of 20] libxl: move device model selection
 variables to b_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 3101b9483229b61afe4945949832c04abe323a59
# Parent  1f5af57bd77645f1e2e235b4cf786025aae4c73f
libxl: move device model selection variables to b_info.

Currently we have one set of device model version (and associated) variables.
However we can actually have two device models (stub device model + non-stub PV
device model) which need not necessarily be the same version. Perhaps this
needs more thought.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -2378,7 +2378,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (dm_info->device_model_stubdomain)
+        if (b_info->device_model_stubdomain)
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -77,6 +77,12 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->cpuid = NULL;
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
+
+    b_info->device_model_version =
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+    b_info->device_model_stubdomain = false;
+    b_info->device_model = NULL;
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
@@ -128,9 +134,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 {
     memset(dm_info, '\0', sizeof(*dm_info));
 
-    dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-    dm_info->device_model_stubdomain = false;
-    dm_info->device_model = NULL;
 
     return 0;
 }
@@ -456,14 +459,14 @@ retry_transaction:
 }
 
 static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
-                             libxl_device_model_info *dm_info)
+                             libxl_domain_build_info *b_info)
 {
     char *path = NULL;
 
     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_device_model_version_to_string(dm_info->device_model_version));
+        libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
@@ -522,7 +525,7 @@ static int do_domain_create(libxl__gc *g
         goto error_out;
     }
 
-    store_libxl_entry(gc, domid, dm_info);
+    store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
@@ -598,12 +601,6 @@ static int do_domain_create(libxl__gc *g
         if (need_qemu) {
             /* only copy those useful configs */
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-            xenpv_dm_info.device_model_version =
-                d_config->dm_info.device_model_version;
-            xenpv_dm_info.device_model = d_config->dm_info.device_model;
-            xenpv_dm_info.extra = d_config->dm_info.extra;
-            xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
-            xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
             libxl__create_xenpv_qemu(gc, domid,
                                      d_config, &xenpv_dm_info, &dm_starting);
@@ -616,7 +613,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (dm_starting) {
-        if (dm_info->device_model_version
+        if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(ctx, domid);
         }
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -34,7 +34,7 @@ const char *libxl__device_model_savefile
 }
 
 const char *libxl__domain_device_model(libxl__gc *gc,
-                                       libxl_device_model_info *info)
+                                       const libxl_domain_build_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
@@ -64,7 +64,7 @@ const char *libxl__domain_device_model(l
 }
 
 static const char *libxl__domain_bios(libxl__gc *gc,
-                                libxl_device_model_info *info)
+                                const libxl_domain_build_info *info)
 {
     switch (info->device_model_version) {
     case 1: return "rombios";
@@ -251,19 +251,19 @@ static char ** libxl__build_device_model
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
     }
-    for (i = 0; info->extra && info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, info->extra[i]);
+    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
+        flexarray_append(dm_args, b_info->extra[i]);
     flexarray_append(dm_args, "-M");
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
-        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_pv[i]);
+        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_pv[i]);
         break;
     case LIBXL_DOMAIN_TYPE_HVM:
         flexarray_append(dm_args, "xenfv");
-        for (i = 0; info->extra_hvm && info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_hvm[i]);
+        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
     }
     flexarray_append(dm_args, NULL);
@@ -495,19 +495,19 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-incoming");
         flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
-    for (i = 0; info->extra && info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, info->extra[i]);
+    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
+        flexarray_append(dm_args, b_info->extra[i]);
     flexarray_append(dm_args, "-M");
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
-        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_pv[i]);
+        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_pv[i]);
         break;
     case LIBXL_DOMAIN_TYPE_HVM:
         flexarray_append(dm_args, "xenfv");
-        for (i = 0; info->extra_hvm && info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_hvm[i]);
+        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
     }
 
@@ -585,14 +585,14 @@ static char ** libxl__build_device_model
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
-    switch (info->device_model_version) {
+    switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
         return libxl__build_device_model_args_old(gc, dm, guest_config, info);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         return libxl__build_device_model_args_new(gc, dm, guest_config, info);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
-                         info->device_model_version);
+                         guest_config->b_info.device_model_version);
         return NULL;
     }
 }
@@ -688,7 +688,8 @@ static int libxl__create_stubdom(libxl__
     libxl__spawner_starting *dm_starting = 0;
     libxl_device_model_info xenpv_dm_info;
 
-    if (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
+    if (guest_config->b_info.device_model_version !=
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
         ret = ERROR_INVAL;
         goto out;
     }
@@ -712,6 +713,14 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
+    dm_config.b_info.device_model_version =
+        guest_config->b_info.device_model_version;
+    dm_config.b_info.device_model =
+        guest_config->b_info.device_model;
+    dm_config.b_info.extra = guest_config->b_info.extra;
+    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+
     dm_config.disks = guest_config->disks;
     dm_config.num_disks = guest_config->num_disks;
 
@@ -828,11 +837,6 @@ retry_transaction:
     }
 
     memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-    xenpv_dm_info.device_model_version = info->device_model_version;
-    xenpv_dm_info.device_model = info->device_model;
-    xenpv_dm_info.extra = info->extra;
-    xenpv_dm_info.extra_pv = info->extra_pv;
-    xenpv_dm_info.extra_hvm = info->extra_hvm;
 
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
@@ -871,6 +875,7 @@ int libxl__create_device_model(libxl__gc
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     char *path, *logfile;
     int logfile_w, null;
@@ -882,12 +887,12 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (info->device_model_stubdomain) {
+    if (b_info->device_model_stubdomain) {
         rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
         goto out;
     }
 
-    dm = libxl__domain_device_model(gc, info);
+    dm = libxl__domain_device_model(gc, b_info);
     if (!dm) {
         rc = ERROR_FAIL;
         goto out;
@@ -906,13 +911,13 @@ int libxl__create_device_model(libxl__gc
 
     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));
+                    "%s", libxl__domain_bios(gc, b_info));
     free(path);
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                    "%d", !guest_config->b_info.u.hvm.xen_platform_pci);
+                    "%d", !b_info->u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 16:38:18 2012 +0000
@@ -299,7 +299,7 @@ static const char *libxl__domain_firmwar
     if (info->u.hvm.firmware)
         firmware = info->u.hvm.firmware;
     else {
-        switch (dm_info->device_model_version)
+        switch (info->device_model_version)
         {
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
             firmware = "hvmloader";
@@ -309,7 +309,7 @@ static const char *libxl__domain_firmwar
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model version %d",
-                       dm_info->device_model_version);
+                       info->device_model_version);
             return NULL;
             break;
         }
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
@@ -491,7 +491,7 @@ _hidden int libxl__domain_build(libxl__g
 
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
-                                               libxl_device_model_info *info);
+                                        const libxl_domain_build_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -204,6 +204,19 @@ libxl_domain_build_info = Struct("domain
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
+    
+    ("device_model_version", libxl_device_model_version),
+    ("device_model_stubdomain", bool),
+    # you set device_model you must set device_model_version too
+    ("device_model",     string),
+
+    # extra parameters pass directly to qemu, NULL terminated
+    ("extra",            libxl_string_list),
+    # extra parameters pass directly to qemu for PV guest, NULL terminated
+    ("extra_pv",         libxl_string_list),
+    # extra parameters pass directly to qemu for HVM guest, NULL terminated
+    ("extra_hvm",        libxl_string_list),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
                                        ("pae", bool),
@@ -257,17 +270,7 @@ libxl_domain_build_info = Struct("domain
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
     
-    ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
-    ("device_model",     string),
     ("saved_state",      string),
-    # extra parameters pass directly to qemu, NULL terminated
-    ("extra",            libxl_string_list),
-    # extra parameters pass directly to qemu for PV guest, NULL terminated
-    ("extra_pv",         libxl_string_list),
-    # extra parameters pass directly to qemu for HVM guest, NULL terminated
-    ("extra_hvm",        libxl_string_list),
     ],
 )
 
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -380,7 +380,7 @@ static void printf_info(int domid,
                     b_info->u.hvm.spice.disable_ticketing);
         printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
 
-        printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
+        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
@@ -1133,27 +1133,27 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model, 0);
+                            &b_info->device_model, 0);
     if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
-            dm_info->device_model_version
+            b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
         } else if (!strcmp(buf, "qemu-xen")) {
-            dm_info->device_model_version
+            b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
         } else {
             fprintf(stderr,
                     "Unknown device_model_version \"%s\" specified\n", buf);
             exit(1);
         }
-    } else if (dm_info->device_model)
+    } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        dm_info->device_model_stubdomain = l;
+        b_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
-                                    &dm_info->extra##type, 0);            \
+                                    &b_info->extra##type, 0);            \
     if (e && e != ESRCH) {                                                \
         fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
         exit(-ERROR_FAIL);                                                \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1i-00030g-Be; Mon, 23 Jan 2012 16:45: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 1RpN1f-0002vV-QW
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!9
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12048 invoked from network); 23 Jan 2012 16:43:33 -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;
	23 Jan 2012 16:43:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181771"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:42 -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
	q0NGjPKM032031;	Mon, 23 Jan 2012 08:45:41 -0800
MIME-Version: 1.0
X-Mercurial-Node: 3101b9483229b61afe4945949832c04abe323a59
Message-ID: <3101b9483229b61afe49.1327337140@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:40 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 17 of 20] libxl: move device model selection
 variables to b_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 3101b9483229b61afe4945949832c04abe323a59
# Parent  1f5af57bd77645f1e2e235b4cf786025aae4c73f
libxl: move device model selection variables to b_info.

Currently we have one set of device model version (and associated) variables.
However we can actually have two device models (stub device model + non-stub PV
device model) which need not necessarily be the same version. Perhaps this
needs more thought.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -2378,7 +2378,7 @@ int libxl_domain_need_memory(libxl_ctx *
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         *need_memkb += b_info->shadow_memkb + LIBXL_HVM_EXTRA_MEMORY;
-        if (dm_info->device_model_stubdomain)
+        if (b_info->device_model_stubdomain)
             *need_memkb += 32 * 1024;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -77,6 +77,12 @@ int libxl_init_build_info(libxl_ctx *ctx
     b_info->cpuid = NULL;
     b_info->shadow_memkb = 0;
     b_info->type = c_info->type;
+
+    b_info->device_model_version =
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
+    b_info->device_model_stubdomain = false;
+    b_info->device_model = NULL;
+
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         b_info->video_memkb = 8 * 1024;
@@ -128,9 +134,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 {
     memset(dm_info, '\0', sizeof(*dm_info));
 
-    dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
-    dm_info->device_model_stubdomain = false;
-    dm_info->device_model = NULL;
 
     return 0;
 }
@@ -456,14 +459,14 @@ retry_transaction:
 }
 
 static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
-                             libxl_device_model_info *dm_info)
+                             libxl_domain_build_info *b_info)
 {
     char *path = NULL;
 
     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_device_model_version_to_string(dm_info->device_model_version));
+        libxl_device_model_version_to_string(b_info->device_model_version));
 }
 
 static int do_domain_create(libxl__gc *gc, libxl_domain_config *d_config,
@@ -522,7 +525,7 @@ static int do_domain_create(libxl__gc *g
         goto error_out;
     }
 
-    store_libxl_entry(gc, domid, dm_info);
+    store_libxl_entry(gc, domid, &d_config->b_info);
 
     for (i = 0; i < d_config->num_disks; i++) {
         ret = libxl_device_disk_add(ctx, domid, &d_config->disks[i]);
@@ -598,12 +601,6 @@ static int do_domain_create(libxl__gc *g
         if (need_qemu) {
             /* only copy those useful configs */
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-            xenpv_dm_info.device_model_version =
-                d_config->dm_info.device_model_version;
-            xenpv_dm_info.device_model = d_config->dm_info.device_model;
-            xenpv_dm_info.extra = d_config->dm_info.extra;
-            xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
-            xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
             libxl__create_xenpv_qemu(gc, domid,
                                      d_config, &xenpv_dm_info, &dm_starting);
@@ -616,7 +613,7 @@ static int do_domain_create(libxl__gc *g
     }
 
     if (dm_starting) {
-        if (dm_info->device_model_version
+        if (d_config->b_info.device_model_version
             == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
             libxl__qmp_initializations(ctx, domid);
         }
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -34,7 +34,7 @@ const char *libxl__device_model_savefile
 }
 
 const char *libxl__domain_device_model(libxl__gc *gc,
-                                       libxl_device_model_info *info)
+                                       const libxl_domain_build_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *dm;
@@ -64,7 +64,7 @@ const char *libxl__domain_device_model(l
 }
 
 static const char *libxl__domain_bios(libxl__gc *gc,
-                                libxl_device_model_info *info)
+                                const libxl_domain_build_info *info)
 {
     switch (info->device_model_version) {
     case 1: return "rombios";
@@ -251,19 +251,19 @@ static char ** libxl__build_device_model
     if (info->saved_state) {
         flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
     }
-    for (i = 0; info->extra && info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, info->extra[i]);
+    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
+        flexarray_append(dm_args, b_info->extra[i]);
     flexarray_append(dm_args, "-M");
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
-        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_pv[i]);
+        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_pv[i]);
         break;
     case LIBXL_DOMAIN_TYPE_HVM:
         flexarray_append(dm_args, "xenfv");
-        for (i = 0; info->extra_hvm && info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_hvm[i]);
+        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
     }
     flexarray_append(dm_args, NULL);
@@ -495,19 +495,19 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-incoming");
         flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
-    for (i = 0; info->extra && info->extra[i] != NULL; i++)
-        flexarray_append(dm_args, info->extra[i]);
+    for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
+        flexarray_append(dm_args, b_info->extra[i]);
     flexarray_append(dm_args, "-M");
     switch (b_info->type) {
     case LIBXL_DOMAIN_TYPE_PV:
         flexarray_append(dm_args, "xenpv");
-        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_pv[i]);
+        for (i = 0; b_info->extra_pv && b_info->extra_pv[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_pv[i]);
         break;
     case LIBXL_DOMAIN_TYPE_HVM:
         flexarray_append(dm_args, "xenfv");
-        for (i = 0; info->extra_hvm && info->extra_hvm[i] != NULL; i++)
-            flexarray_append(dm_args, info->extra_hvm[i]);
+        for (i = 0; b_info->extra_hvm && b_info->extra_hvm[i] != NULL; i++)
+            flexarray_append(dm_args, b_info->extra_hvm[i]);
         break;
     }
 
@@ -585,14 +585,14 @@ static char ** libxl__build_device_model
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
-    switch (info->device_model_version) {
+    switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
         return libxl__build_device_model_args_old(gc, dm, guest_config, info);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
         return libxl__build_device_model_args_new(gc, dm, guest_config, info);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
-                         info->device_model_version);
+                         guest_config->b_info.device_model_version);
         return NULL;
     }
 }
@@ -688,7 +688,8 @@ static int libxl__create_stubdom(libxl__
     libxl__spawner_starting *dm_starting = 0;
     libxl_device_model_info xenpv_dm_info;
 
-    if (info->device_model_version != LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
+    if (guest_config->b_info.device_model_version !=
+        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
         ret = ERROR_INVAL;
         goto out;
     }
@@ -712,6 +713,14 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
+    dm_config.b_info.device_model_version =
+        guest_config->b_info.device_model_version;
+    dm_config.b_info.device_model =
+        guest_config->b_info.device_model;
+    dm_config.b_info.extra = guest_config->b_info.extra;
+    dm_config.b_info.extra_pv = guest_config->b_info.extra_pv;
+    dm_config.b_info.extra_hvm = guest_config->b_info.extra_hvm;
+
     dm_config.disks = guest_config->disks;
     dm_config.num_disks = guest_config->num_disks;
 
@@ -828,11 +837,6 @@ retry_transaction:
     }
 
     memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-    xenpv_dm_info.device_model_version = info->device_model_version;
-    xenpv_dm_info.device_model = info->device_model;
-    xenpv_dm_info.extra = info->extra;
-    xenpv_dm_info.extra_pv = info->extra_pv;
-    xenpv_dm_info.extra_hvm = info->extra_hvm;
 
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
@@ -871,6 +875,7 @@ int libxl__create_device_model(libxl__gc
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
     char *path, *logfile;
     int logfile_w, null;
@@ -882,12 +887,12 @@ int libxl__create_device_model(libxl__gc
     char **pass_stuff;
     const char *dm;
 
-    if (info->device_model_stubdomain) {
+    if (b_info->device_model_stubdomain) {
         rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
         goto out;
     }
 
-    dm = libxl__domain_device_model(gc, info);
+    dm = libxl__domain_device_model(gc, b_info);
     if (!dm) {
         rc = ERROR_FAIL;
         goto out;
@@ -906,13 +911,13 @@ int libxl__create_device_model(libxl__gc
 
     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));
+                    "%s", libxl__domain_bios(gc, b_info));
     free(path);
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                    "%d", !guest_config->b_info.u.hvm.xen_platform_pci);
+                    "%d", !b_info->u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 16:38:18 2012 +0000
@@ -299,7 +299,7 @@ static const char *libxl__domain_firmwar
     if (info->u.hvm.firmware)
         firmware = info->u.hvm.firmware;
     else {
-        switch (dm_info->device_model_version)
+        switch (info->device_model_version)
         {
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
             firmware = "hvmloader";
@@ -309,7 +309,7 @@ static const char *libxl__domain_firmwar
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "invalid device model version %d",
-                       dm_info->device_model_version);
+                       info->device_model_version);
             return NULL;
             break;
         }
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
@@ -491,7 +491,7 @@ _hidden int libxl__domain_build(libxl__g
 
 /* for device model creation */
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
-                                               libxl_device_model_info *info);
+                                        const libxl_domain_build_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -204,6 +204,19 @@ libxl_domain_build_info = Struct("domain
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
     ("type",            libxl_domain_type),
+    
+    ("device_model_version", libxl_device_model_version),
+    ("device_model_stubdomain", bool),
+    # you set device_model you must set device_model_version too
+    ("device_model",     string),
+
+    # extra parameters pass directly to qemu, NULL terminated
+    ("extra",            libxl_string_list),
+    # extra parameters pass directly to qemu for PV guest, NULL terminated
+    ("extra_pv",         libxl_string_list),
+    # extra parameters pass directly to qemu for HVM guest, NULL terminated
+    ("extra_hvm",        libxl_string_list),
+
     ("u", KeyedUnion(None, libxl_domain_type, "type",
                 [("hvm", Struct(None, [("firmware", string),
                                        ("pae", bool),
@@ -257,17 +270,7 @@ libxl_domain_build_info = Struct("domain
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
     
-    ("device_model_version", libxl_device_model_version),
-    ("device_model_stubdomain", bool),
-    # you set device_model you must set device_model_version too
-    ("device_model",     string),
     ("saved_state",      string),
-    # extra parameters pass directly to qemu, NULL terminated
-    ("extra",            libxl_string_list),
-    # extra parameters pass directly to qemu for PV guest, NULL terminated
-    ("extra_pv",         libxl_string_list),
-    # extra parameters pass directly to qemu for HVM guest, NULL terminated
-    ("extra_hvm",        libxl_string_list),
     ],
 )
 
diff -r 1f5af57bd776 -r 3101b9483229 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -380,7 +380,7 @@ static void printf_info(int domid,
                     b_info->u.hvm.spice.disable_ticketing);
         printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
 
-        printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
+        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
         printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
@@ -1133,27 +1133,27 @@ skip_vfb:
 
 
     xlu_cfg_replace_string (config, "device_model_override",
-                            &dm_info->device_model, 0);
+                            &b_info->device_model, 0);
     if (!xlu_cfg_get_string (config, "device_model_version", &buf, 0)) {
         if (!strcmp(buf, "qemu-xen-traditional")) {
-            dm_info->device_model_version
+            b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
         } else if (!strcmp(buf, "qemu-xen")) {
-            dm_info->device_model_version
+            b_info->device_model_version
                 = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN;
         } else {
             fprintf(stderr,
                     "Unknown device_model_version \"%s\" specified\n", buf);
             exit(1);
         }
-    } else if (dm_info->device_model)
+    } else if (b_info->device_model)
         fprintf(stderr, "WARNING: device model override given without specific DM version\n");
     if (!xlu_cfg_get_long (config, "device_model_stubdomain_override", &l, 0))
-        dm_info->device_model_stubdomain = l;
+        b_info->device_model_stubdomain = l;
 
 #define parse_extra_args(type)                                            \
     e = xlu_cfg_get_list_as_string_list(config, "device_model_args"#type, \
-                                    &dm_info->extra##type, 0);            \
+                                    &b_info->extra##type, 0);            \
     if (e && e != ESRCH) {                                                \
         fprintf(stderr,"xl: Unable to parse device_model_args"#type".\n");\
         exit(-ERROR_FAIL);                                                \

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN1f-0002xa-Dh; Mon, 23 Jan 2012 16:45: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 1RpN1d-0002tp-LS
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 23 Jan 2012 16:43:29 -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;
	23 Jan 2012 16:43:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181766"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:38 -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
	q0NGjPKI032031;	Mon, 23 Jan 2012 08:45:37 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6caa4c9b20e176884050310999c5a5eb4c555a41
Message-ID: <6caa4c9b20e176884050.1327337136@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 20] libxl: HVM device configuration info
 build_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 6caa4c9b20e176884050310999c5a5eb4c555a41
# Parent  188443bf7392231d675ee195e2e72314c8568f8a
libxl: HVM device configuration info build_info->u.hvm

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 188443bf7392 -r 6caa4c9b20e1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -103,6 +103,11 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.sdl.enable = 0;
         b_info->u.hvm.sdl.opengl = 0;
         b_info->u.hvm.nographic = 0;
+        b_info->u.hvm.serial = NULL;
+        b_info->u.hvm.boot = strdup("cda");
+        b_info->u.hvm.usb = 0;
+        b_info->u.hvm.usbdevice = NULL;
+        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -129,11 +134,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
 
-    dm_info->serial = NULL;
-    dm_info->boot = strdup("cda");
-    dm_info->usb = 0;
-    dm_info->usbdevice = NULL;
-    dm_info->xen_platform_pci = 1;
     return 0;
 }
 
diff -r 188443bf7392 -r 6caa4c9b20e1 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -171,12 +171,13 @@ static char ** libxl__build_device_model
     if (keymap) {
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
-    if (info->serial) {
-        flexarray_vappend(dm_args, "-serial", info->serial, NULL);
-    }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
+        if (b_info->u.hvm.serial) {
+            flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
+        }
+
         if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
@@ -191,17 +192,18 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-std-vga");
         }
 
-        if (info->boot) {
-            flexarray_vappend(dm_args, "-boot", info->boot, NULL);
+        if (b_info->u.hvm.boot) {
+            flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (info->usb || info->usbdevice) {
+        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
-            if (info->usbdevice) {
-                flexarray_vappend(dm_args, "-usbdevice", info->usbdevice, NULL);
+            if (b_info->u.hvm.usbdevice) {
+                flexarray_vappend(dm_args,
+                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
             }
         }
-        if (info->soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
+        if (b_info->u.hvm.soundhw) {
+            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
         if (b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-acpi");
@@ -398,12 +400,13 @@ static char ** libxl__build_device_model
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->serial) {
-        flexarray_vappend(dm_args, "-serial", info->serial, NULL);
-    }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
+        if (b_info->u.hvm.serial) {
+            flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
+        }
+
         if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
@@ -422,17 +425,19 @@ static char ** libxl__build_device_model
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
-        if (info->boot) {
-            flexarray_vappend(dm_args, "-boot", libxl__sprintf(gc, "order=%s", info->boot), NULL);
+        if (b_info->u.hvm.boot) {
+            flexarray_vappend(dm_args, "-boot",
+                    libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (info->usb || info->usbdevice) {
+        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
-            if (info->usbdevice) {
-                flexarray_vappend(dm_args, "-usbdevice", info->usbdevice, NULL);
+            if (b_info->u.hvm.usbdevice) {
+                flexarray_vappend(dm_args,
+                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
             }
         }
-        if (info->soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
+        if (b_info->u.hvm.soundhw) {
+            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
         if (!b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-no-acpi");
@@ -778,7 +783,7 @@ retry_transaction:
     if (ret)
         goto out_free;
 
-    if (info->serial)
+    if (guest_config->b_info.u.hvm.serial)
         num_console++;
 
     console = libxl__calloc(gc, num_console, sizeof(libxl_device_console));
@@ -906,7 +911,8 @@ int libxl__create_device_model(libxl__gc
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
+                    "%d", !guest_config->b_info.u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 188443bf7392 -r 6caa4c9b20e1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -226,6 +226,16 @@ libxl_domain_build_info = Struct("domain
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
+                                       
+                                       ("serial",           string),
+                                       ("boot",             string),
+                                       ("usb",              bool),
+                                       # usbdevice:
+                                       # - "tablet" for absolute mouse,
+                                       # - "mouse" for PS/2 protocol relative mouse
+                                       ("usbdevice",        string),
+                                       ("soundhw",          string),
+                                       ("xen_platform_pci", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -255,13 +265,6 @@ libxl_device_model_info = Struct("device
     ("saved_state",      string),
     ("type",             libxl_domain_type),
     ("gfx_passthru",     bool),
-    ("serial",           string),
-    ("boot",             string),
-    ("usb",              bool),
-    # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
-    ("usbdevice",        string),
-    ("soundhw",          string),
-    ("xen_platform_pci", bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 188443bf7392 -r 6caa4c9b20e1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -382,10 +382,10 @@ static void printf_info(int domid,
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(serial %s)\n", dm_info->serial);
-        printf("\t\t\t(boot %s)\n", dm_info->boot);
-        printf("\t\t\t(usb %d)\n", dm_info->usb);
-        printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
+        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
+        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
+        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1209,14 +1209,14 @@ skip_vfb:
             b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
+        xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+            b_info->u.hvm.usb = l;
+        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
         if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            dm_info->xen_platform_pci = l;
+            b_info->u.hvm.xen_platform_pci = 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 Mon Jan 23 16:45:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN1f-0002xa-Dh; Mon, 23 Jan 2012 16:45: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 1RpN1d-0002tp-LS
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!7
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11794 invoked from network); 23 Jan 2012 16:43:29 -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;
	23 Jan 2012 16:43:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181766"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:38 -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
	q0NGjPKI032031;	Mon, 23 Jan 2012 08:45:37 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6caa4c9b20e176884050310999c5a5eb4c555a41
Message-ID: <6caa4c9b20e176884050.1327337136@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:36 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 13 of 20] libxl: HVM device configuration info
 build_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 6caa4c9b20e176884050310999c5a5eb4c555a41
# Parent  188443bf7392231d675ee195e2e72314c8568f8a
libxl: HVM device configuration info build_info->u.hvm

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 188443bf7392 -r 6caa4c9b20e1 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -103,6 +103,11 @@ int libxl_init_build_info(libxl_ctx *ctx
         b_info->u.hvm.sdl.enable = 0;
         b_info->u.hvm.sdl.opengl = 0;
         b_info->u.hvm.nographic = 0;
+        b_info->u.hvm.serial = NULL;
+        b_info->u.hvm.boot = strdup("cda");
+        b_info->u.hvm.usb = 0;
+        b_info->u.hvm.usbdevice = NULL;
+        b_info->u.hvm.xen_platform_pci = 1;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         b_info->u.pv.slack_memkb = 8 * 1024;
@@ -129,11 +134,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
 
-    dm_info->serial = NULL;
-    dm_info->boot = strdup("cda");
-    dm_info->usb = 0;
-    dm_info->usbdevice = NULL;
-    dm_info->xen_platform_pci = 1;
     return 0;
 }
 
diff -r 188443bf7392 -r 6caa4c9b20e1 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -171,12 +171,13 @@ static char ** libxl__build_device_model
     if (keymap) {
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
-    if (info->serial) {
-        flexarray_vappend(dm_args, "-serial", info->serial, NULL);
-    }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
+        if (b_info->u.hvm.serial) {
+            flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
+        }
+
         if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
@@ -191,17 +192,18 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-std-vga");
         }
 
-        if (info->boot) {
-            flexarray_vappend(dm_args, "-boot", info->boot, NULL);
+        if (b_info->u.hvm.boot) {
+            flexarray_vappend(dm_args, "-boot", b_info->u.hvm.boot, NULL);
         }
-        if (info->usb || info->usbdevice) {
+        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
-            if (info->usbdevice) {
-                flexarray_vappend(dm_args, "-usbdevice", info->usbdevice, NULL);
+            if (b_info->u.hvm.usbdevice) {
+                flexarray_vappend(dm_args,
+                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
             }
         }
-        if (info->soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
+        if (b_info->u.hvm.soundhw) {
+            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
         if (b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-acpi");
@@ -398,12 +400,13 @@ static char ** libxl__build_device_model
         flexarray_vappend(dm_args, "-k", keymap, NULL);
     }
 
-    if (info->serial) {
-        flexarray_vappend(dm_args, "-serial", info->serial, NULL);
-    }
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         int ioemu_vifs = 0;
 
+        if (b_info->u.hvm.serial) {
+            flexarray_vappend(dm_args, "-serial", b_info->u.hvm.serial, NULL);
+        }
+
         if (b_info->u.hvm.nographic && (!sdl && !vnc)) {
             flexarray_append(dm_args, "-nographic");
         }
@@ -422,17 +425,19 @@ static char ** libxl__build_device_model
                 flexarray_vappend(dm_args, "-vga", "std", NULL);
         }
 
-        if (info->boot) {
-            flexarray_vappend(dm_args, "-boot", libxl__sprintf(gc, "order=%s", info->boot), NULL);
+        if (b_info->u.hvm.boot) {
+            flexarray_vappend(dm_args, "-boot",
+                    libxl__sprintf(gc, "order=%s", b_info->u.hvm.boot), NULL);
         }
-        if (info->usb || info->usbdevice) {
+        if (b_info->u.hvm.usb || b_info->u.hvm.usbdevice) {
             flexarray_append(dm_args, "-usb");
-            if (info->usbdevice) {
-                flexarray_vappend(dm_args, "-usbdevice", info->usbdevice, NULL);
+            if (b_info->u.hvm.usbdevice) {
+                flexarray_vappend(dm_args,
+                                  "-usbdevice", b_info->u.hvm.usbdevice, NULL);
             }
         }
-        if (info->soundhw) {
-            flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
+        if (b_info->u.hvm.soundhw) {
+            flexarray_vappend(dm_args, "-soundhw", b_info->u.hvm.soundhw, NULL);
         }
         if (!b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-no-acpi");
@@ -778,7 +783,7 @@ retry_transaction:
     if (ret)
         goto out_free;
 
-    if (info->serial)
+    if (guest_config->b_info.u.hvm.serial)
         num_console++;
 
     console = libxl__calloc(gc, num_console, sizeof(libxl_device_console));
@@ -906,7 +911,8 @@ int libxl__create_device_model(libxl__gc
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
+    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
+                    "%d", !guest_config->b_info.u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
diff -r 188443bf7392 -r 6caa4c9b20e1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -226,6 +226,16 @@ libxl_domain_build_info = Struct("domain
                                        ("keymap",           string),
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
+                                       
+                                       ("serial",           string),
+                                       ("boot",             string),
+                                       ("usb",              bool),
+                                       # usbdevice:
+                                       # - "tablet" for absolute mouse,
+                                       # - "mouse" for PS/2 protocol relative mouse
+                                       ("usbdevice",        string),
+                                       ("soundhw",          string),
+                                       ("xen_platform_pci", bool),
                                        ])),
                  ("pv", Struct(None, [("kernel", libxl_file_reference),
                                       ("slack_memkb", uint32),
@@ -255,13 +265,6 @@ libxl_device_model_info = Struct("device
     ("saved_state",      string),
     ("type",             libxl_domain_type),
     ("gfx_passthru",     bool),
-    ("serial",           string),
-    ("boot",             string),
-    ("usb",              bool),
-    # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
-    ("usbdevice",        string),
-    ("soundhw",          string),
-    ("xen_platform_pci", bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 188443bf7392 -r 6caa4c9b20e1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -382,10 +382,10 @@ static void printf_info(int domid,
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
-        printf("\t\t\t(serial %s)\n", dm_info->serial);
-        printf("\t\t\t(boot %s)\n", dm_info->boot);
-        printf("\t\t\t(usb %d)\n", dm_info->usb);
-        printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
+        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
+        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
+        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1209,14 +1209,14 @@ skip_vfb:
             b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
             dm_info->gfx_passthru = l;
-        xlu_cfg_replace_string (config, "serial", &dm_info->serial, 0);
-        xlu_cfg_replace_string (config, "boot", &dm_info->boot, 0);
+        xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
+        xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         if (!xlu_cfg_get_long (config, "usb", &l, 0))
-            dm_info->usb = l;
-        xlu_cfg_replace_string (config, "usbdevice", &dm_info->usbdevice, 0);
-        xlu_cfg_replace_string (config, "soundhw", &dm_info->soundhw, 0);
+            b_info->u.hvm.usb = l;
+        xlu_cfg_replace_string (config, "usbdevice", &b_info->u.hvm.usbdevice, 0);
+        xlu_cfg_replace_string (config, "soundhw", &b_info->u.hvm.soundhw, 0);
         if (!xlu_cfg_get_long (config, "xen_platform_pci", &l, 0))
-            dm_info->xen_platform_pci = l;
+            b_info->u.hvm.xen_platform_pci = 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 Mon Jan 23 16:45:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1l-00033q-1G; Mon, 23 Jan 2012 16:45: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 1RpN1j-0002wl-Gh
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!10
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12242 invoked from network); 23 Jan 2012 16:43:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:43:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181775"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:44 -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
	q0NGjPKP032031;	Mon, 23 Jan 2012 08:45:43 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5f20c5ddd4e42242bfb32b85652c5957c40ba320
Message-ID: <5f20c5ddd4e42242bfb3.1327337143@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 20 of 20] libxl: only write "disable_pf" key to
 xenstore when it makes sense
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336698 0
# Node ID 5f20c5ddd4e42242bfb32b85652c5957c40ba320
# Parent  62bffbc5495b3e897d6fbb654453f2335556e06e
libxl: only write "disable_pf" key to xenstore when it makes sense

This key is only used by the traditional qemu-dm when servicing an HVM domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 62bffbc5495b -r 5f20c5ddd4e4 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -929,8 +929,12 @@ int libxl__create_device_model(libxl__gc
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                    "%d", !b_info->u.hvm.xen_platform_pci);
+
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        b_info->device_model_version
+        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
+        libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
+                        "%d", !b_info->u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:45:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:45:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN1l-00033q-1G; Mon, 23 Jan 2012 16:45: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 1RpN1j-0002wl-Gh
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:45:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327336999!49731178!10
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12242 invoked from network); 23 Jan 2012 16:43:35 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:43:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181775"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:44 -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
	q0NGjPKP032031;	Mon, 23 Jan 2012 08:45:43 -0800
MIME-Version: 1.0
X-Mercurial-Node: 5f20c5ddd4e42242bfb32b85652c5957c40ba320
Message-ID: <5f20c5ddd4e42242bfb3.1327337143@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:43 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 20 of 20] libxl: only write "disable_pf" key to
 xenstore when it makes sense
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336698 0
# Node ID 5f20c5ddd4e42242bfb32b85652c5957c40ba320
# Parent  62bffbc5495b3e897d6fbb654453f2335556e06e
libxl: only write "disable_pf" key to xenstore when it makes sense

This key is only used by the traditional qemu-dm when servicing an HVM domain.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 62bffbc5495b -r 5f20c5ddd4e4 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -929,8 +929,12 @@ int libxl__create_device_model(libxl__gc
 
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
-    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
-                    "%d", !b_info->u.hvm.xen_platform_pci);
+
+    if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+        b_info->device_model_version
+        == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL)
+        libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
+                        "%d", !b_info->u.hvm.xen_platform_pci);
 
     libxl_create_logfile(ctx,
                          libxl__sprintf(gc, "qemu-dm-%s", c_info->name),

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN20-0003FC-Ga; Mon, 23 Jan 2012 16:46: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 1RpN1y-0003AI-P0
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8474 invoked from network); 23 Jan 2012 16:46:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695398"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:26 -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
	q0NGjPK5032031;	Mon, 23 Jan 2012 08:45:25 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 20] libxl: drop device_model_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is the first portion of my previous "libxl: drop
device_model_info, better defaults support, stubdoms by default"
series. Specifically it is the "drop device_model_info" bit (plus some
incidental bits & bobs).

I've split it to make it all a bit more manageable and to allow it to
be reviewed while I address some other concerns with the latter bits
of the other series.

This comes after "libxl: tweak the cpupool interface slightly" which I
sent this morning in my queue but I think the only relation is a tiny
bit of overlap of the context in patch #2. It also comes after "libxl:
remove _libxl_json_internal.h from libxl_json.h" but I beleive there
is no overlap there.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN20-0003FC-Ga; Mon, 23 Jan 2012 16:46: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 1RpN1y-0003AI-P0
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8474 invoked from network); 23 Jan 2012 16:46:00 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695398"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:27 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:26 -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
	q0NGjPK5032031;	Mon, 23 Jan 2012 08:45:25 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:23 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 00 of 20] libxl: drop device_model_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is the first portion of my previous "libxl: drop
device_model_info, better defaults support, stubdoms by default"
series. Specifically it is the "drop device_model_info" bit (plus some
incidental bits & bobs).

I've split it to make it all a bit more manageable and to allow it to
be reviewed while I address some other concerns with the latter bits
of the other series.

This comes after "libxl: tweak the cpupool interface slightly" which I
sent this morning in my queue but I think the only relation is a tiny
bit of overlap of the context in patch #2. It also comes after "libxl:
remove _libxl_json_internal.h from libxl_json.h" but I beleive there
is no overlap there.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN21-0003Gd-J1; Mon, 23 Jan 2012 16:46: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 1RpN20-0003C5-3E
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327337093!62158059!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11589 invoked from network); 23 Jan 2012 16:44:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:44:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695421"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:33 -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, 23 Jan 2012 11:45:33 -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
	q0NGjPKC032031;	Mon, 23 Jan 2012 08:45:32 -0800
MIME-Version: 1.0
X-Mercurial-Node: c03b3c71a923216fe50882770a72b3cc9f433a85
Message-ID: <c03b3c71a923216fe508.1327337130@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:30 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 20] libxl: plumb libxl_domain_config down
 into device model 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 Ian Campbell <ian.campbell@citrix.com>
# Date 1327336697 0
# Node ID c03b3c71a923216fe50882770a72b3cc9f433a85
# Parent  16d23a64e9c79955405c44c07f2e39cfb0ad238a
libxl: plumb libxl_domain_config down into device model creation.

Creating the device model derives lots of bits from the guest configuration.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
@@ -568,7 +568,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, d_config, dm_info,
                                         d_config->disks, d_config->num_disks,
                                         d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
@@ -615,7 +615,8 @@ static int do_domain_create(libxl__gc *g
             xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
             xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
-            libxl__create_xenpv_qemu(gc, domid, &xenpv_dm_info,
+            libxl__create_xenpv_qemu(gc, domid,
+                                     d_config, &xenpv_dm_info,
                                      d_config->vfbs, &dm_starting);
         }
         break;
diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -74,10 +74,11 @@ 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_device_disk *disks, int num_disks,
-                                                  libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     int i;
     flexarray_t *dm_args;
@@ -228,10 +229,11 @@ 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_device_disk *disks, int num_disks,
-                                                  libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     flexarray_t *dm_args;
@@ -492,20 +494,21 @@ 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_device_disk *disks, int num_disks,
-                                              libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     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, guest_config, 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, guest_config, info,
                                                   disks, num_disks,
                                                   vifs, num_vifs);
     default:
@@ -516,9 +519,9 @@ static char ** libxl__build_device_model
 }
 
 static int libxl__vfb_and_vkb_from_device_model_info(libxl__gc *gc,
-                                                     libxl_device_model_info *info,
-                                                     libxl_device_vfb *vfb,
-                                                     libxl_device_vkb *vkb)
+                                        const libxl_device_model_info *info,
+                                        libxl_device_vfb *vfb,
+                                        libxl_device_vkb *vkb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
@@ -583,6 +586,7 @@ retry_transaction:
 }
 
 static int libxl__create_stubdom(libxl__gc *gc,
+                                 libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
                                  libxl_device_disk *disks, int num_disks,
                                  libxl_device_nic *vifs, int num_vifs,
@@ -593,8 +597,7 @@ static int libxl__create_stubdom(libxl__
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl_device_console *console;
-    libxl_domain_create_info c_info;
-    libxl_domain_build_info b_info;
+    libxl_domain_config dm_config;
     libxl__domain_build_state state;
     uint32_t domid;
     char **args;
@@ -608,7 +611,35 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm", info,
+    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
+
+    libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
+
+    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    dm_config.b_info.max_vcpus = 1;
+    dm_config.b_info.max_memkb = 32 * 1024;
+    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+
+    dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+                                              libxl_xenfirmwaredir_path());
+    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
+    dm_config.b_info.u.pv.ramdisk.path = "";
+    dm_config.b_info.u.pv.features = "";
+
+    /* fixme: this function can leak the stubdom if it fails */
+    domid = 0;
+    ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
+    if (ret)
+        goto out;
+    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &state);
+    if (ret)
+        goto out;
+
+    args = libxl__build_device_model_args(gc, "stubdom-dm",
+                                          guest_config, info,
                                           disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
@@ -616,33 +647,6 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&c_info, 0x00, sizeof(libxl_domain_create_info));
-    c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
-
-    libxl_uuid_copy(&c_info.uuid, &info->uuid);
-
-    memset(&b_info, 0x00, sizeof(libxl_domain_build_info));
-    b_info.max_vcpus = 1;
-    b_info.max_memkb = 32 * 1024;
-    b_info.target_memkb = b_info.max_memkb;
-
-    b_info.type = LIBXL_DOMAIN_TYPE_PV;
-    b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
-                                              libxl_xenfirmwaredir_path());
-    b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
-    b_info.u.pv.ramdisk.path = "";
-    b_info.u.pv.features = "";
-
-    /* fixme: this function can leak the stubdom if it fails */
-    domid = 0;
-    ret = libxl__domain_make(gc, &c_info, &domid);
-    if (ret)
-        goto out_free;
-    ret = libxl__domain_build(gc, &b_info, info, domid, &state);
-    if (ret)
-        goto out_free;
-
     libxl__write_dmargs(gc, domid, info->domid, args);
     libxl__xs_write(gc, XBT_NULL,
                    libxl__sprintf(gc, "%s/image/device-model-domid", libxl__xs_get_dompath(gc, info->domid)),
@@ -739,6 +743,7 @@ retry_transaction:
     xenpv_dm_info.extra_hvm = info->extra_hvm;
 
     if (libxl__create_xenpv_qemu(gc, domid,
+                                 &dm_config,
                                  &xenpv_dm_info,
                                  vfb, &dm_starting) < 0) {
         ret = ERROR_FAIL;
@@ -768,6 +773,7 @@ out:
 }
 
 int libxl__create_device_model(libxl__gc *gc,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
                               libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
@@ -789,7 +795,7 @@ int libxl__create_device_model(libxl__gc
         libxl_device_vkb vkb;
 
         libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-        rc = libxl__create_stubdom(gc, info,
+        rc = libxl__create_stubdom(gc, guest_config, info,
                                    disks, num_disks,
                                    vifs, num_vifs,
                                    &vfb, &vkb, starting_r);
@@ -807,7 +813,8 @@ 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, guest_config, info,
+                                          disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
         rc = ERROR_FAIL;
@@ -1027,12 +1034,13 @@ out:
 }
 
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
+                             libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
                              libxl_device_vfb *vfb,
                              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, guest_config, info, NULL, 0, NULL, 0, starting_r);
     return 0;
 }
 
diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:17 2012 +0000
@@ -493,11 +493,13 @@ _hidden int libxl__domain_build(libxl__g
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                                libxl_device_model_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disk, int num_disks,
+                              libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
                               libxl_device_vfb *vfb,
                               libxl__spawner_starting **starting_r);
diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_uuid.c
--- a/tools/libxl/libxl_uuid.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_uuid.c	Mon Jan 23 16:38:17 2012 +0000
@@ -35,7 +35,7 @@ int libxl_uuid_from_string(libxl_uuid *u
      return uuid_parse(in, uuid->uuid);
 }
 
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src)
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
 {
      uuid_copy(dst->uuid, src->uuid);
 }
@@ -82,7 +82,7 @@ int libxl_uuid_from_string(libxl_uuid *u
 }
 #undef LIBXL__UUID_PTRS
 
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src)
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
 {
      memcpy(dst->uuid, src->uuid, sizeof(dst->uuid));
 }
diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_uuid.h
--- a/tools/libxl/libxl_uuid.h	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_uuid.h	Mon Jan 23 16:38:17 2012 +0000
@@ -56,7 +56,7 @@ typedef struct {
 int libxl_uuid_is_nil(libxl_uuid *uuid);
 void libxl_uuid_generate(libxl_uuid *uuid);
 int libxl_uuid_from_string(libxl_uuid *uuid, const char *in);
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src);
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src);
 void libxl_uuid_clear(libxl_uuid *uuid);
 int libxl_uuid_compare(libxl_uuid *uuid1, libxl_uuid *uuid2);
 uint8_t *libxl_uuid_bytearray(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 Mon Jan 23 16:46:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN21-0003Gd-J1; Mon, 23 Jan 2012 16:46: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 1RpN20-0003C5-3E
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327337093!62158059!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11589 invoked from network); 23 Jan 2012 16:44:56 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:44:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695421"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:33 -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, 23 Jan 2012 11:45:33 -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
	q0NGjPKC032031;	Mon, 23 Jan 2012 08:45:32 -0800
MIME-Version: 1.0
X-Mercurial-Node: c03b3c71a923216fe50882770a72b3cc9f433a85
Message-ID: <c03b3c71a923216fe508.1327337130@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:30 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 07 of 20] libxl: plumb libxl_domain_config down
 into device model 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 Ian Campbell <ian.campbell@citrix.com>
# Date 1327336697 0
# Node ID c03b3c71a923216fe50882770a72b3cc9f433a85
# Parent  16d23a64e9c79955405c44c07f2e39cfb0ad238a
libxl: plumb libxl_domain_config down into device model creation.

Creating the device model derives lots of bits from the guest configuration.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
@@ -568,7 +568,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, d_config, dm_info,
                                         d_config->disks, d_config->num_disks,
                                         d_config->vifs, d_config->num_vifs,
                                         &dm_starting);
@@ -615,7 +615,8 @@ static int do_domain_create(libxl__gc *g
             xenpv_dm_info.extra_pv = d_config->dm_info.extra_pv;
             xenpv_dm_info.extra_hvm = d_config->dm_info.extra_hvm;
 
-            libxl__create_xenpv_qemu(gc, domid, &xenpv_dm_info,
+            libxl__create_xenpv_qemu(gc, domid,
+                                     d_config, &xenpv_dm_info,
                                      d_config->vfbs, &dm_starting);
         }
         break;
diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -74,10 +74,11 @@ 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_device_disk *disks, int num_disks,
-                                                  libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     int i;
     flexarray_t *dm_args;
@@ -228,10 +229,11 @@ 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_device_disk *disks, int num_disks,
-                                                  libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     flexarray_t *dm_args;
@@ -492,20 +494,21 @@ 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_device_disk *disks, int num_disks,
-                                              libxl_device_nic *vifs, int num_vifs)
+                                        const char *dm,
+                                        const libxl_domain_config *guest_config,
+                                        const libxl_device_model_info *info,
+                                        const libxl_device_disk *disks, int num_disks,
+                                        const libxl_device_nic *vifs, int num_vifs)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     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, guest_config, 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, guest_config, info,
                                                   disks, num_disks,
                                                   vifs, num_vifs);
     default:
@@ -516,9 +519,9 @@ static char ** libxl__build_device_model
 }
 
 static int libxl__vfb_and_vkb_from_device_model_info(libxl__gc *gc,
-                                                     libxl_device_model_info *info,
-                                                     libxl_device_vfb *vfb,
-                                                     libxl_device_vkb *vkb)
+                                        const libxl_device_model_info *info,
+                                        libxl_device_vfb *vfb,
+                                        libxl_device_vkb *vkb)
 {
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     memset(vkb, 0x00, sizeof(libxl_device_vkb));
@@ -583,6 +586,7 @@ retry_transaction:
 }
 
 static int libxl__create_stubdom(libxl__gc *gc,
+                                 libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
                                  libxl_device_disk *disks, int num_disks,
                                  libxl_device_nic *vifs, int num_vifs,
@@ -593,8 +597,7 @@ static int libxl__create_stubdom(libxl__
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i, num_console = STUBDOM_SPECIAL_CONSOLES, ret;
     libxl_device_console *console;
-    libxl_domain_create_info c_info;
-    libxl_domain_build_info b_info;
+    libxl_domain_config dm_config;
     libxl__domain_build_state state;
     uint32_t domid;
     char **args;
@@ -608,7 +611,35 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm", info,
+    memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
+    dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
+
+    libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
+
+    memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
+    dm_config.b_info.max_vcpus = 1;
+    dm_config.b_info.max_memkb = 32 * 1024;
+    dm_config.b_info.target_memkb = dm_config.b_info.max_memkb;
+
+    dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
+    dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
+                                              libxl_xenfirmwaredir_path());
+    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
+    dm_config.b_info.u.pv.ramdisk.path = "";
+    dm_config.b_info.u.pv.features = "";
+
+    /* fixme: this function can leak the stubdom if it fails */
+    domid = 0;
+    ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
+    if (ret)
+        goto out;
+    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &state);
+    if (ret)
+        goto out;
+
+    args = libxl__build_device_model_args(gc, "stubdom-dm",
+                                          guest_config, info,
                                           disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
@@ -616,33 +647,6 @@ static int libxl__create_stubdom(libxl__
         goto out;
     }
 
-    memset(&c_info, 0x00, sizeof(libxl_domain_create_info));
-    c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
-
-    libxl_uuid_copy(&c_info.uuid, &info->uuid);
-
-    memset(&b_info, 0x00, sizeof(libxl_domain_build_info));
-    b_info.max_vcpus = 1;
-    b_info.max_memkb = 32 * 1024;
-    b_info.target_memkb = b_info.max_memkb;
-
-    b_info.type = LIBXL_DOMAIN_TYPE_PV;
-    b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
-                                              libxl_xenfirmwaredir_path());
-    b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
-    b_info.u.pv.ramdisk.path = "";
-    b_info.u.pv.features = "";
-
-    /* fixme: this function can leak the stubdom if it fails */
-    domid = 0;
-    ret = libxl__domain_make(gc, &c_info, &domid);
-    if (ret)
-        goto out_free;
-    ret = libxl__domain_build(gc, &b_info, info, domid, &state);
-    if (ret)
-        goto out_free;
-
     libxl__write_dmargs(gc, domid, info->domid, args);
     libxl__xs_write(gc, XBT_NULL,
                    libxl__sprintf(gc, "%s/image/device-model-domid", libxl__xs_get_dompath(gc, info->domid)),
@@ -739,6 +743,7 @@ retry_transaction:
     xenpv_dm_info.extra_hvm = info->extra_hvm;
 
     if (libxl__create_xenpv_qemu(gc, domid,
+                                 &dm_config,
                                  &xenpv_dm_info,
                                  vfb, &dm_starting) < 0) {
         ret = ERROR_FAIL;
@@ -768,6 +773,7 @@ out:
 }
 
 int libxl__create_device_model(libxl__gc *gc,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
                               libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
@@ -789,7 +795,7 @@ int libxl__create_device_model(libxl__gc
         libxl_device_vkb vkb;
 
         libxl__vfb_and_vkb_from_device_model_info(gc, info, &vfb, &vkb);
-        rc = libxl__create_stubdom(gc, info,
+        rc = libxl__create_stubdom(gc, guest_config, info,
                                    disks, num_disks,
                                    vifs, num_vifs,
                                    &vfb, &vkb, starting_r);
@@ -807,7 +813,8 @@ 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, guest_config, info,
+                                          disks, num_disks,
                                           vifs, num_vifs);
     if (!args) {
         rc = ERROR_FAIL;
@@ -1027,12 +1034,13 @@ out:
 }
 
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
+                             libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
                              libxl_device_vfb *vfb,
                              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, guest_config, info, NULL, 0, NULL, 0, starting_r);
     return 0;
 }
 
diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:17 2012 +0000
@@ -493,11 +493,13 @@ _hidden int libxl__domain_build(libxl__g
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                                libxl_device_model_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
-                              libxl_device_disk *disk, int num_disks,
+                              libxl_device_disk *disks, int num_disks,
                               libxl_device_nic *vifs, int num_vifs,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
+                              libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
                               libxl_device_vfb *vfb,
                               libxl__spawner_starting **starting_r);
diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_uuid.c
--- a/tools/libxl/libxl_uuid.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_uuid.c	Mon Jan 23 16:38:17 2012 +0000
@@ -35,7 +35,7 @@ int libxl_uuid_from_string(libxl_uuid *u
      return uuid_parse(in, uuid->uuid);
 }
 
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src)
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
 {
      uuid_copy(dst->uuid, src->uuid);
 }
@@ -82,7 +82,7 @@ int libxl_uuid_from_string(libxl_uuid *u
 }
 #undef LIBXL__UUID_PTRS
 
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src)
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src)
 {
      memcpy(dst->uuid, src->uuid, sizeof(dst->uuid));
 }
diff -r 16d23a64e9c7 -r c03b3c71a923 tools/libxl/libxl_uuid.h
--- a/tools/libxl/libxl_uuid.h	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_uuid.h	Mon Jan 23 16:38:17 2012 +0000
@@ -56,7 +56,7 @@ typedef struct {
 int libxl_uuid_is_nil(libxl_uuid *uuid);
 void libxl_uuid_generate(libxl_uuid *uuid);
 int libxl_uuid_from_string(libxl_uuid *uuid, const char *in);
-void libxl_uuid_copy(libxl_uuid *dst, libxl_uuid *src);
+void libxl_uuid_copy(libxl_uuid *dst, const libxl_uuid *src);
 void libxl_uuid_clear(libxl_uuid *uuid);
 int libxl_uuid_compare(libxl_uuid *uuid1, libxl_uuid *uuid2);
 uint8_t *libxl_uuid_bytearray(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 Mon Jan 23 16:46:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN22-0003Hd-Fy; Mon, 23 Jan 2012 16:46:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN21-0003BP-2C
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327337093!62158059!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11564 invoked from network); 23 Jan 2012 16:44:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:44:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695413"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:30 -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
	q0NGjPK9032031;	Mon, 23 Jan 2012 08:45:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: 83418dbcfc0ab05da8dc1774e66deeb421eae003
Message-ID: <83418dbcfc0ab05da8dc.1327337127@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 20] libxl: define libxl_vnc_info to hold
 all info about the vnc info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336697 0
# Node ID 83418dbcfc0ab05da8dc1774e66deeb421eae003
# Parent  a44bd706400238c6f5e309c3925fa90718b80576
libxl: define libxl_vnc_info to hold all info about the vnc info

Reduces duplication in libxl_vfb and libxl_device_model.

Updated bindings but the python ones in particular are unlikely to be useful
until a user presents itself and fixes them up.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -1943,11 +1943,11 @@ int libxl_device_vfb_init(libxl_ctx *ctx
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     vfb->display = NULL;
     vfb->xauthority = NULL;
-    vfb->vnc = 1;
-    vfb->vncpasswd = NULL;
-    vfb->vnclisten = strdup("127.0.0.1");
-    vfb->vncdisplay = 0;
-    vfb->vncunused = 1;
+    vfb->vnc.enable = 1;
+    vfb->vnc.passwd = NULL;
+    vfb->vnc.listen = strdup("127.0.0.1");
+    vfb->vnc.display = 0;
+    vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
     vfb->sdl = 0;
     vfb->opengl = 0;
@@ -1993,11 +1993,14 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     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, "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, "vnc",
+                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+    flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
+    flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
+    flexarray_append_pair(back, "vncdisplay",
+                          libxl__sprintf(gc, "%d", vfb->vnc.display));
+    flexarray_append_pair(back, "vncunused",
+                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
     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) {
diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
@@ -126,10 +126,10 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->vcpu_avail = b_info->cur_vcpus;
 
     dm_info->stdvga = 0;
-    dm_info->vnc = 1;
-    dm_info->vnclisten = strdup("127.0.0.1");
-    dm_info->vncdisplay = 0;
-    dm_info->vncunused = 1;
+    dm_info->vnc.enable = 1;
+    dm_info->vnc.listen = strdup("127.0.0.1");
+    dm_info->vnc.display = 0;
+    dm_info->vnc.findunused = 1;
     dm_info->keymap = NULL;
     dm_info->sdl = 0;
     dm_info->opengl = 0;
diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -92,31 +92,31 @@ static char ** libxl__build_device_model
     if (info->dom_name)
         flexarray_vappend(dm_args, "-domain-name", info->dom_name, NULL);
 
-    if (info->vnc) {
+    if (info->vnc.enable) {
         char *vncarg;
-        if (info->vncdisplay) {
-            if (info->vnclisten && strchr(info->vnclisten, ':') == NULL) {
+        if (info->vnc.display) {
+            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
                 vncarg = libxl__sprintf(gc, "%s:%d",
-                                  info->vnclisten,
-                                  info->vncdisplay);
+                                  info->vnc.listen,
+                                  info->vnc.display);
             } else {
-                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vncdisplay);
+                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vnc.display);
             }
-        } else if (info->vnclisten) {
-            if (strchr(info->vnclisten, ':') != NULL) {
-                vncarg = info->vnclisten;
+        } else if (info->vnc.listen) {
+            if (strchr(info->vnc.listen, ':') != NULL) {
+                vncarg = info->vnc.listen;
             } else {
-                vncarg = libxl__sprintf(gc, "%s:0", info->vnclisten);
+                vncarg = libxl__sprintf(gc, "%s:0", info->vnc.listen);
             }
         } else {
             vncarg = "127.0.0.1:0";
         }
-        if (info->vncpasswd && (info->vncpasswd[0] != '\0'))
+        if (info->vnc.passwd && (info->vnc.passwd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (info->vncunused) {
+        if (info->vnc.findunused) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
@@ -129,7 +129,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc)) {
+    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -260,32 +260,32 @@ static char ** libxl__build_device_model
     if (info->dom_name) {
         flexarray_vappend(dm_args, "-name", info->dom_name, NULL);
     }
-    if (info->vnc) {
+    if (info->vnc.enable) {
         int display = 0;
         const char *listen = "127.0.0.1";
 
-        if (info->vncpasswd && info->vncpasswd[0]) {
+        if (info->vnc.passwd && info->vnc.passwd[0]) {
             assert(!"missing code for supplying vnc password to qemu");
         }
         flexarray_append(dm_args, "-vnc");
 
-        if (info->vncdisplay) {
-            display = info->vncdisplay;
-            if (info->vnclisten && strchr(info->vnclisten, ':') == NULL) {
-                listen = info->vnclisten;
+        if (info->vnc.display) {
+            display = info->vnc.display;
+            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
+                listen = info->vnc.listen;
             }
-        } else if (info->vnclisten) {
-            listen = info->vnclisten;
+        } else if (info->vnc.listen) {
+            listen = info->vnc.listen;
         }
 
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        info->vncunused ? ",to=99" : ""));
+                        info->vnc.findunused ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vncunused ? ",to=99" : ""));
+                        info->vnc.findunused ? ",to=99" : ""));
     }
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -335,7 +335,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc)) {
+    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -524,10 +524,6 @@ static int libxl__vfb_and_vkb_from_devic
     vfb->backend_domid = 0;
     vfb->devid = 0;
     vfb->vnc = info->vnc;
-    vfb->vnclisten = info->vnclisten;
-    vfb->vncdisplay = info->vncdisplay;
-    vfb->vncunused = info->vncunused;
-    vfb->vncpasswd = info->vncpasswd;
     vfb->keymap = info->keymap;
     vfb->sdl = info->sdl;
     vfb->opengl = info->opengl;
@@ -851,7 +847,7 @@ int libxl__create_device_model(libxl__gc
         goto out_close;
     }
 
-    if (info->vncpasswd) {
+    if (info->vnc.passwd) {
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
@@ -860,7 +856,7 @@ retry_transaction:
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
             pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = info->vncpasswd;
+            pass_stuff[1] = info->vnc.passwd;
             libxl__xs_writev(gc,t,vm_path,pass_stuff);
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
@@ -975,13 +971,13 @@ static int libxl__build_xenpv_qemu_args(
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     if (vfb != NULL) {
-        info->vnc = vfb->vnc;
-        if (vfb->vnclisten)
-            info->vnclisten = libxl__strdup(gc, vfb->vnclisten);
-        info->vncdisplay = vfb->vncdisplay;
-        info->vncunused = vfb->vncunused;
-        if (vfb->vncpasswd)
-            info->vncpasswd = vfb->vncpasswd;
+        info->vnc.enable = vfb->vnc.enable;
+        if (vfb->vnc.listen)
+            info->vnc.listen = libxl__strdup(gc, vfb->vnc.listen);
+        info->vnc.display = vfb->vnc.display;
+        info->vnc.findunused = vfb->vnc.findunused;
+        if (vfb->vnc.passwd)
+            info->vnc.passwd = vfb->vnc.passwd;
         if (vfb->keymap)
             info->keymap = libxl__strdup(gc, vfb->keymap);
         info->sdl = vfb->sdl;
diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -95,6 +95,16 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 #
 # Complex libxl types
 #
+libxl_vnc_info = Struct("vnc_info", [
+    ("enable",        bool),
+    # "address:port" that should be listened on
+    ("listen",        string),
+    ("passwd",        string),
+    ("display",       integer),
+    # If set then try to find an unused port
+    ("findunused",    bool),
+    ])
+
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
@@ -222,14 +232,7 @@ libxl_device_model_info = Struct("device
     # size of the videoram in MB
     ("videoram",         integer), 
     ("stdvga",           bool),
-    ("vnc",              bool),
-    # "address:port" that should be listened on for the VNC server
-    ("vnclisten",        string),
-    ("vncpasswd",        string),
-    # VNC display number
-    ("vncdisplay",       integer),
-    # If set then try to find an unused port for the VNC server
-    ("vncunused",        bool),
+    ("vnc",              libxl_vnc_info),
     # keyboard layout, default is en-us keyboard
     ("keymap",           string),
     ("sdl",              bool),
@@ -268,12 +271,7 @@ libxl_device_model_info = Struct("device
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
-    ("vnc",           bool),
-    # address:port that should be listened on for the VNC server if vnc is set
-    ("vnclisten",     string),
-    ("vncpasswd",     string),
-    ("vncdisplay",    integer),
-    ("vncunused",     bool),
+    ("vnc",           libxl_vnc_info),
     # set keyboard layout, default is en-us keyboard
     ("keymap",        string),
     ("sdl",           bool),
diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -366,10 +366,10 @@ static void printf_info(int domid,
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
         printf("\t\t\t(stdvga %d)\n", dm_info->stdvga);
-        printf("\t\t\t(vnc %d)\n", dm_info->vnc);
-        printf("\t\t\t(vnclisten %s)\n", dm_info->vnclisten);
-        printf("\t\t\t(vncdisplay %d)\n", dm_info->vncdisplay);
-        printf("\t\t\t(vncunused %d)\n", dm_info->vncunused);
+        printf("\t\t\t(vnc %d)\n", dm_info->vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", dm_info->vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
+        printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
         printf("\t\t\t(keymap %s)\n", dm_info->keymap);
         printf("\t\t\t(sdl %d)\n", dm_info->sdl);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
@@ -456,10 +456,10 @@ static void printf_info(int domid,
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc);
-        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnclisten);
-        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vncdisplay);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vncunused);
+        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
+        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
         printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl);
         printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].opengl);
@@ -961,17 +961,17 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc = atoi(p2 + 1);
+                    vfb->vnc.enable = atoi(p2 + 1);
                 } else if (!strcmp(p, "vnclisten")) {
-                    free(vfb->vnclisten);
-                    vfb->vnclisten = strdup(p2 + 1);
+                    free(vfb->vnc.listen);
+                    vfb->vnc.listen = strdup(p2 + 1);
                 } else if (!strcmp(p, "vncpasswd")) {
-                    free(vfb->vncpasswd);
-                    vfb->vncpasswd = strdup(p2 + 1);
+                    free(vfb->vnc.passwd);
+                    vfb->vnc.passwd = strdup(p2 + 1);
                 } else if (!strcmp(p, "vncdisplay")) {
-                    vfb->vncdisplay = atoi(p2 + 1);
+                    vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vncunused = atoi(p2 + 1);
+                    vfb->vnc.findunused = atoi(p2 + 1);
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
@@ -1178,13 +1178,13 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
         if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+            dm_info->vnc.enable = l;
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
-            dm_info->vncdisplay = l;
+            dm_info->vnc.display = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            dm_info->vncunused = l;
+            dm_info->vnc.findunused = l;
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
diff -r a44bd7064002 -r 83418dbcfc0a tools/python/genwrap.py
--- a/tools/python/genwrap.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/python/genwrap.py	Mon Jan 23 16:38:17 2012 +0000
@@ -4,7 +4,7 @@ import sys,os
 
 import libxltypes
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING) = range(4)
+(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
 
 def py_type(ty):
     if ty == libxltypes.bool:
@@ -16,6 +16,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, libxltypes.Aggregate):
+        return TYPE_AGGREGATE
     if ty == libxltypes.string:
         return TYPE_STRING
     return None
@@ -66,6 +68,9 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
+    elif t == TYPE_AGGREGATE:
+        l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
+        l.append('    return NULL;')
     else:
         tn = f.type.typename
         l.append('    return attrib__%s_get((%s *)&self->obj.%s);'%(fsanitize(tn), tn, f.name))
@@ -92,6 +97,9 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
+    elif t == TYPE_AGGREGATE:
+        l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
+        l.append('    return -1;')
     else:
         tn = f.type.typename
         l.append('    return attrib__%s_set(v, (%s *)&self->obj.%s);'%(fsanitize(tn), tn, f.name))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN22-0003H6-1G; Mon, 23 Jan 2012 16:46: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 1RpN20-0003Az-BR
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8547 invoked from network); 23 Jan 2012 16:46:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695416"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPKA032031;	Mon, 23 Jan 2012 08:45:30 -0800
MIME-Version: 1.0
X-Mercurial-Node: e241db296cbfa86557cd5cfaf7bb870e455dedad
Message-ID: <e241db296cbfa86557cd.1327337128@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:28 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 20] libxl: define libxl_spice_info to hold
 all info about the spice server
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID e241db296cbfa86557cd5cfaf7bb870e455dedad
# Parent  83418dbcfc0ab05da8dc1774e66deeb421eae003
libxl: define libxl_spice_info to hold all info about the spice server

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 83418dbcfc0a -r e241db296cbf tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -290,39 +290,39 @@ static char ** libxl__build_device_model
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
     }
-    if (info->spice) {
+    if (info->spice.enable) {
         char *spiceoptions = NULL;
-        if (!info->spiceport && !info->spicetls_port) {
+        if (!info->spice.port && !info->spice.tls_port) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "at least one of the spiceport or tls_port must be provided");
             return NULL;
         }
 
-        if (!info->spicedisable_ticketing) {
-            if (!info->spicepasswd) {
+        if (!info->spice.disable_ticketing) {
+            if (!info->spice.passwd) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                     "spice ticketing is enabled but missing password");
                 return NULL;
             }
-            else if (!info->spicepasswd[0]) {
+            else if (!info->spice.passwd[0]) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                     "spice password can't be empty");
                 return NULL;
             }
         }
         spiceoptions = libxl__sprintf(gc, "port=%d,tls-port=%d",
-                       info->spiceport, info->spicetls_port);
-        if (info->spicehost)
+                                      info->spice.port, info->spice.tls_port);
+        if (info->spice.host)
             spiceoptions = libxl__sprintf(gc,
-                    "%s,addr=%s", spiceoptions, info->spicehost);
-        if (info->spicedisable_ticketing)
+                    "%s,addr=%s", spiceoptions, info->spice.host);
+        if (info->spice.disable_ticketing)
             spiceoptions = libxl__sprintf(gc, "%s,disable-ticketing",
                                                spiceoptions);
         else
             spiceoptions = libxl__sprintf(gc,
-                    "%s,password=%s", spiceoptions, info->spicepasswd);
+                    "%s,password=%s", spiceoptions, info->spice.passwd);
         spiceoptions = libxl__sprintf(gc, "%s,agent-mouse=%s", spiceoptions,
-                                      info->spiceagent_mouse ? "on" : "off");
+                                      info->spice.agent_mouse ? "on" : "off");
 
         flexarray_append(dm_args, "-spice");
         flexarray_append(dm_args, spiceoptions);
diff -r 83418dbcfc0a -r e241db296cbf tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -105,6 +105,26 @@ libxl_vnc_info = Struct("vnc_info", [
     ("findunused",    bool),
     ])
 
+libxl_spice_info = Struct("spice_info", [
+    ("enable",            bool),
+    # At least one of spice port or spicetls_post must be given
+    ("port",        integer),
+    ("tls_port",    integer),
+    # Interface to bind to
+    ("host",        string),
+    # enable client connection with no password
+    ("disable_ticketing", bool),
+    ("passwd",      string),
+    ("agent_mouse", bool),
+    ])
+
+libxl_sdl_info = Struct("sdl_info", [
+    ("enable",        bool),
+    ("opengl",        bool),
+    ("display",       string),
+    ("xauthority",    string),
+    ])
+
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
@@ -237,16 +257,7 @@ libxl_device_model_info = Struct("device
     ("keymap",           string),
     ("sdl",              bool),
     ("opengl",           bool), # (requires sdl enabled)
-    ("spice",            bool),
-    # At least one of spice port or spicetls_post must be given
-    ("spiceport",        integer),
-    ("spicetls_port",    integer),
-    # Interface to bind to
-    ("spicehost",        string),
-    # enable client connection with no password
-    ("spicedisable_ticketing", bool),
-    ("spicepasswd",      string),
-    ("spiceagent_mouse", bool),
+    ("spice",            libxl_spice_info),
     ("nographic",        bool),
     ("gfx_passthru",     bool),
     ("serial",           string),
diff -r 83418dbcfc0a -r e241db296cbf tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -380,13 +380,13 @@ static void printf_info(int domid,
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
         printf("\t\t\t(acpi %d)\n", dm_info->acpi);
-        printf("\t\t\t(spice %d)\n", dm_info->spice);
-        printf("\t\t\t(spiceport %d)\n", dm_info->spiceport);
-        printf("\t\t\t(spicetls_port %d)\n", dm_info->spicetls_port);
-        printf("\t\t\t(spicehost %s)\n", dm_info->spicehost);
+        printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
+        printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", dm_info->spice.host);
         printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    dm_info->spicedisable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spiceagent_mouse);
+                    dm_info->spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spice.agent_mouse);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1191,19 +1191,20 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            dm_info->spice = l;
+            dm_info->spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
-            dm_info->spiceport = l;
+            dm_info->spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
-            dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+            dm_info->spice.tls_port = l;
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spice.host, 0);
         if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+            dm_info->spice.disable_ticketing = l;
+        xlu_cfg_replace_string (config, "spicepasswd",
+                                &dm_info->spice.passwd, 0);
         if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            dm_info->spiceagent_mouse = l;
+            dm_info->spice.agent_mouse = l;
         else
-            dm_info->spiceagent_mouse = 1;
+            dm_info->spice.agent_mouse = 1;
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN22-0003Hd-Fy; Mon, 23 Jan 2012 16:46:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN21-0003BP-2C
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327337093!62158059!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11564 invoked from network); 23 Jan 2012 16:44:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:44:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695413"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:30 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:30 -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
	q0NGjPK9032031;	Mon, 23 Jan 2012 08:45:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: 83418dbcfc0ab05da8dc1774e66deeb421eae003
Message-ID: <83418dbcfc0ab05da8dc.1327337127@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:27 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 04 of 20] libxl: define libxl_vnc_info to hold
 all info about the vnc info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336697 0
# Node ID 83418dbcfc0ab05da8dc1774e66deeb421eae003
# Parent  a44bd706400238c6f5e309c3925fa90718b80576
libxl: define libxl_vnc_info to hold all info about the vnc info

Reduces duplication in libxl_vfb and libxl_device_model.

Updated bindings but the python ones in particular are unlikely to be useful
until a user presents itself and fixes them up.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -1943,11 +1943,11 @@ int libxl_device_vfb_init(libxl_ctx *ctx
     memset(vfb, 0x00, sizeof(libxl_device_vfb));
     vfb->display = NULL;
     vfb->xauthority = NULL;
-    vfb->vnc = 1;
-    vfb->vncpasswd = NULL;
-    vfb->vnclisten = strdup("127.0.0.1");
-    vfb->vncdisplay = 0;
-    vfb->vncunused = 1;
+    vfb->vnc.enable = 1;
+    vfb->vnc.passwd = NULL;
+    vfb->vnc.listen = strdup("127.0.0.1");
+    vfb->vnc.display = 0;
+    vfb->vnc.findunused = 1;
     vfb->keymap = NULL;
     vfb->sdl = 0;
     vfb->opengl = 0;
@@ -1993,11 +1993,14 @@ int libxl_device_vfb_add(libxl_ctx *ctx,
     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, "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, "vnc",
+                          libxl__sprintf(gc, "%d", vfb->vnc.enable));
+    flexarray_append_pair(back, "vnclisten", vfb->vnc.listen);
+    flexarray_append_pair(back, "vncpasswd", vfb->vnc.passwd);
+    flexarray_append_pair(back, "vncdisplay",
+                          libxl__sprintf(gc, "%d", vfb->vnc.display));
+    flexarray_append_pair(back, "vncunused",
+                          libxl__sprintf(gc, "%d", vfb->vnc.findunused));
     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) {
diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
@@ -126,10 +126,10 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->vcpu_avail = b_info->cur_vcpus;
 
     dm_info->stdvga = 0;
-    dm_info->vnc = 1;
-    dm_info->vnclisten = strdup("127.0.0.1");
-    dm_info->vncdisplay = 0;
-    dm_info->vncunused = 1;
+    dm_info->vnc.enable = 1;
+    dm_info->vnc.listen = strdup("127.0.0.1");
+    dm_info->vnc.display = 0;
+    dm_info->vnc.findunused = 1;
     dm_info->keymap = NULL;
     dm_info->sdl = 0;
     dm_info->opengl = 0;
diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -92,31 +92,31 @@ static char ** libxl__build_device_model
     if (info->dom_name)
         flexarray_vappend(dm_args, "-domain-name", info->dom_name, NULL);
 
-    if (info->vnc) {
+    if (info->vnc.enable) {
         char *vncarg;
-        if (info->vncdisplay) {
-            if (info->vnclisten && strchr(info->vnclisten, ':') == NULL) {
+        if (info->vnc.display) {
+            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
                 vncarg = libxl__sprintf(gc, "%s:%d",
-                                  info->vnclisten,
-                                  info->vncdisplay);
+                                  info->vnc.listen,
+                                  info->vnc.display);
             } else {
-                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vncdisplay);
+                vncarg = libxl__sprintf(gc, "127.0.0.1:%d", info->vnc.display);
             }
-        } else if (info->vnclisten) {
-            if (strchr(info->vnclisten, ':') != NULL) {
-                vncarg = info->vnclisten;
+        } else if (info->vnc.listen) {
+            if (strchr(info->vnc.listen, ':') != NULL) {
+                vncarg = info->vnc.listen;
             } else {
-                vncarg = libxl__sprintf(gc, "%s:0", info->vnclisten);
+                vncarg = libxl__sprintf(gc, "%s:0", info->vnc.listen);
             }
         } else {
             vncarg = "127.0.0.1:0";
         }
-        if (info->vncpasswd && (info->vncpasswd[0] != '\0'))
+        if (info->vnc.passwd && (info->vnc.passwd[0] != '\0'))
             vncarg = libxl__sprintf(gc, "%s,password", vncarg);
         flexarray_append(dm_args, "-vnc");
         flexarray_append(dm_args, vncarg);
 
-        if (info->vncunused) {
+        if (info->vnc.findunused) {
             flexarray_append(dm_args, "-vncunused");
         }
     }
@@ -129,7 +129,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc)) {
+    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -260,32 +260,32 @@ static char ** libxl__build_device_model
     if (info->dom_name) {
         flexarray_vappend(dm_args, "-name", info->dom_name, NULL);
     }
-    if (info->vnc) {
+    if (info->vnc.enable) {
         int display = 0;
         const char *listen = "127.0.0.1";
 
-        if (info->vncpasswd && info->vncpasswd[0]) {
+        if (info->vnc.passwd && info->vnc.passwd[0]) {
             assert(!"missing code for supplying vnc password to qemu");
         }
         flexarray_append(dm_args, "-vnc");
 
-        if (info->vncdisplay) {
-            display = info->vncdisplay;
-            if (info->vnclisten && strchr(info->vnclisten, ':') == NULL) {
-                listen = info->vnclisten;
+        if (info->vnc.display) {
+            display = info->vnc.display;
+            if (info->vnc.listen && strchr(info->vnc.listen, ':') == NULL) {
+                listen = info->vnc.listen;
             }
-        } else if (info->vnclisten) {
-            listen = info->vnclisten;
+        } else if (info->vnc.listen) {
+            listen = info->vnc.listen;
         }
 
         if (strchr(listen, ':') != NULL)
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s%s", listen,
-                        info->vncunused ? ",to=99" : ""));
+                        info->vnc.findunused ? ",to=99" : ""));
         else
             flexarray_append(dm_args,
                     libxl__sprintf(gc, "%s:%d%s", listen, display,
-                        info->vncunused ? ",to=99" : ""));
+                        info->vnc.findunused ? ",to=99" : ""));
     }
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
@@ -335,7 +335,7 @@ static char ** libxl__build_device_model
     if (info->keymap) {
         flexarray_vappend(dm_args, "-k", info->keymap, NULL);
     }
-    if (info->nographic && (!info->sdl && !info->vnc)) {
+    if (info->nographic && (!info->sdl && !info->vnc.enable)) {
         flexarray_append(dm_args, "-nographic");
     }
     if (info->serial) {
@@ -524,10 +524,6 @@ static int libxl__vfb_and_vkb_from_devic
     vfb->backend_domid = 0;
     vfb->devid = 0;
     vfb->vnc = info->vnc;
-    vfb->vnclisten = info->vnclisten;
-    vfb->vncdisplay = info->vncdisplay;
-    vfb->vncunused = info->vncunused;
-    vfb->vncpasswd = info->vncpasswd;
     vfb->keymap = info->keymap;
     vfb->sdl = info->sdl;
     vfb->opengl = info->opengl;
@@ -851,7 +847,7 @@ int libxl__create_device_model(libxl__gc
         goto out_close;
     }
 
-    if (info->vncpasswd) {
+    if (info->vnc.passwd) {
 retry_transaction:
         /* Find uuid and the write the vnc password to xenstore for qemu. */
         t = xs_transaction_start(ctx->xsh);
@@ -860,7 +856,7 @@ retry_transaction:
             /* Now write the vncpassword into it. */
             pass_stuff = libxl__calloc(gc, 3, sizeof(char *));
             pass_stuff[0] = "vncpasswd";
-            pass_stuff[1] = info->vncpasswd;
+            pass_stuff[1] = info->vnc.passwd;
             libxl__xs_writev(gc,t,vm_path,pass_stuff);
             if (!xs_transaction_end(ctx->xsh, t, 0))
                 if (errno == EAGAIN)
@@ -975,13 +971,13 @@ static int libxl__build_xenpv_qemu_args(
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     if (vfb != NULL) {
-        info->vnc = vfb->vnc;
-        if (vfb->vnclisten)
-            info->vnclisten = libxl__strdup(gc, vfb->vnclisten);
-        info->vncdisplay = vfb->vncdisplay;
-        info->vncunused = vfb->vncunused;
-        if (vfb->vncpasswd)
-            info->vncpasswd = vfb->vncpasswd;
+        info->vnc.enable = vfb->vnc.enable;
+        if (vfb->vnc.listen)
+            info->vnc.listen = libxl__strdup(gc, vfb->vnc.listen);
+        info->vnc.display = vfb->vnc.display;
+        info->vnc.findunused = vfb->vnc.findunused;
+        if (vfb->vnc.passwd)
+            info->vnc.passwd = vfb->vnc.passwd;
         if (vfb->keymap)
             info->keymap = libxl__strdup(gc, vfb->keymap);
         info->sdl = vfb->sdl;
diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -95,6 +95,16 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 #
 # Complex libxl types
 #
+libxl_vnc_info = Struct("vnc_info", [
+    ("enable",        bool),
+    # "address:port" that should be listened on
+    ("listen",        string),
+    ("passwd",        string),
+    ("display",       integer),
+    # If set then try to find an unused port
+    ("findunused",    bool),
+    ])
+
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
@@ -222,14 +232,7 @@ libxl_device_model_info = Struct("device
     # size of the videoram in MB
     ("videoram",         integer), 
     ("stdvga",           bool),
-    ("vnc",              bool),
-    # "address:port" that should be listened on for the VNC server
-    ("vnclisten",        string),
-    ("vncpasswd",        string),
-    # VNC display number
-    ("vncdisplay",       integer),
-    # If set then try to find an unused port for the VNC server
-    ("vncunused",        bool),
+    ("vnc",              libxl_vnc_info),
     # keyboard layout, default is en-us keyboard
     ("keymap",           string),
     ("sdl",              bool),
@@ -268,12 +271,7 @@ libxl_device_model_info = Struct("device
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
-    ("vnc",           bool),
-    # address:port that should be listened on for the VNC server if vnc is set
-    ("vnclisten",     string),
-    ("vncpasswd",     string),
-    ("vncdisplay",    integer),
-    ("vncunused",     bool),
+    ("vnc",           libxl_vnc_info),
     # set keyboard layout, default is en-us keyboard
     ("keymap",        string),
     ("sdl",           bool),
diff -r a44bd7064002 -r 83418dbcfc0a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -366,10 +366,10 @@ static void printf_info(int domid,
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
         printf("\t\t\t(videoram %d)\n", dm_info->videoram);
         printf("\t\t\t(stdvga %d)\n", dm_info->stdvga);
-        printf("\t\t\t(vnc %d)\n", dm_info->vnc);
-        printf("\t\t\t(vnclisten %s)\n", dm_info->vnclisten);
-        printf("\t\t\t(vncdisplay %d)\n", dm_info->vncdisplay);
-        printf("\t\t\t(vncunused %d)\n", dm_info->vncunused);
+        printf("\t\t\t(vnc %d)\n", dm_info->vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", dm_info->vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", dm_info->vnc.display);
+        printf("\t\t\t(vncunused %d)\n", dm_info->vnc.findunused);
         printf("\t\t\t(keymap %s)\n", dm_info->keymap);
         printf("\t\t\t(sdl %d)\n", dm_info->sdl);
         printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
@@ -456,10 +456,10 @@ static void printf_info(int domid,
         printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
         printf("\t\t\t(frontend_domid %d)\n", domid);
         printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc);
-        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnclisten);
-        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vncdisplay);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vncunused);
+        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
+        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
         printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
         printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl);
         printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].opengl);
@@ -961,17 +961,17 @@ skip:
                     break;
                 *p2 = '\0';
                 if (!strcmp(p, "vnc")) {
-                    vfb->vnc = atoi(p2 + 1);
+                    vfb->vnc.enable = atoi(p2 + 1);
                 } else if (!strcmp(p, "vnclisten")) {
-                    free(vfb->vnclisten);
-                    vfb->vnclisten = strdup(p2 + 1);
+                    free(vfb->vnc.listen);
+                    vfb->vnc.listen = strdup(p2 + 1);
                 } else if (!strcmp(p, "vncpasswd")) {
-                    free(vfb->vncpasswd);
-                    vfb->vncpasswd = strdup(p2 + 1);
+                    free(vfb->vnc.passwd);
+                    vfb->vnc.passwd = strdup(p2 + 1);
                 } else if (!strcmp(p, "vncdisplay")) {
-                    vfb->vncdisplay = atoi(p2 + 1);
+                    vfb->vnc.display = atoi(p2 + 1);
                 } else if (!strcmp(p, "vncunused")) {
-                    vfb->vncunused = atoi(p2 + 1);
+                    vfb->vnc.findunused = atoi(p2 + 1);
                 } else if (!strcmp(p, "keymap")) {
                     free(vfb->keymap);
                     vfb->keymap = strdup(p2 + 1);
@@ -1178,13 +1178,13 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
             dm_info->stdvga = l;
         if (!xlu_cfg_get_long (config, "vnc", &l, 0))
-            dm_info->vnc = l;
-        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnclisten, 0);
-        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vncpasswd, 0);
+            dm_info->vnc.enable = l;
+        xlu_cfg_replace_string (config, "vnclisten", &dm_info->vnc.listen, 0);
+        xlu_cfg_replace_string (config, "vncpasswd", &dm_info->vnc.passwd, 0);
         if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
-            dm_info->vncdisplay = l;
+            dm_info->vnc.display = l;
         if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
-            dm_info->vncunused = l;
+            dm_info->vnc.findunused = l;
         xlu_cfg_replace_string (config, "keymap", &dm_info->keymap, 0);
         if (!xlu_cfg_get_long (config, "sdl", &l, 0))
             dm_info->sdl = l;
diff -r a44bd7064002 -r 83418dbcfc0a tools/python/genwrap.py
--- a/tools/python/genwrap.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/python/genwrap.py	Mon Jan 23 16:38:17 2012 +0000
@@ -4,7 +4,7 @@ import sys,os
 
 import libxltypes
 
-(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING) = range(4)
+(TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
 
 def py_type(ty):
     if ty == libxltypes.bool:
@@ -16,6 +16,8 @@ def py_type(ty):
             return TYPE_INT
         else:
             return TYPE_UINT
+    if isinstance(ty, libxltypes.Aggregate):
+        return TYPE_AGGREGATE
     if ty == libxltypes.string:
         return TYPE_STRING
     return None
@@ -66,6 +68,9 @@ def py_attrib_get(ty, f):
         l.append('    return genwrap__ull_get(self->obj.%s);'%f.name)
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_get(&self->obj.%s);'%f.name)
+    elif t == TYPE_AGGREGATE:
+        l.append('    PyErr_SetString(PyExc_NotImplementedError, "Getting %s");'%ty.typename)
+        l.append('    return NULL;')
     else:
         tn = f.type.typename
         l.append('    return attrib__%s_get((%s *)&self->obj.%s);'%(fsanitize(tn), tn, f.name))
@@ -92,6 +97,9 @@ def py_attrib_set(ty, f):
         l.append('    return ret;')
     elif t == TYPE_STRING:
         l.append('    return genwrap__string_set(v, &self->obj.%s);'%f.name)
+    elif t == TYPE_AGGREGATE:
+        l.append('    PyErr_SetString(PyExc_NotImplementedError, "Setting %s");'%ty.typename)
+        l.append('    return -1;')
     else:
         tn = f.type.typename
         l.append('    return attrib__%s_set(v, (%s *)&self->obj.%s);'%(fsanitize(tn), tn, f.name))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN22-0003H6-1G; Mon, 23 Jan 2012 16:46: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 1RpN20-0003Az-BR
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8547 invoked from network); 23 Jan 2012 16:46:01 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695416"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:31 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPKA032031;	Mon, 23 Jan 2012 08:45:30 -0800
MIME-Version: 1.0
X-Mercurial-Node: e241db296cbfa86557cd5cfaf7bb870e455dedad
Message-ID: <e241db296cbfa86557cd.1327337128@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:28 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 05 of 20] libxl: define libxl_spice_info to hold
 all info about the spice server
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID e241db296cbfa86557cd5cfaf7bb870e455dedad
# Parent  83418dbcfc0ab05da8dc1774e66deeb421eae003
libxl: define libxl_spice_info to hold all info about the spice server

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 83418dbcfc0a -r e241db296cbf tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
@@ -290,39 +290,39 @@ static char ** libxl__build_device_model
     if (info->sdl) {
         flexarray_append(dm_args, "-sdl");
     }
-    if (info->spice) {
+    if (info->spice.enable) {
         char *spiceoptions = NULL;
-        if (!info->spiceport && !info->spicetls_port) {
+        if (!info->spice.port && !info->spice.tls_port) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                 "at least one of the spiceport or tls_port must be provided");
             return NULL;
         }
 
-        if (!info->spicedisable_ticketing) {
-            if (!info->spicepasswd) {
+        if (!info->spice.disable_ticketing) {
+            if (!info->spice.passwd) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                     "spice ticketing is enabled but missing password");
                 return NULL;
             }
-            else if (!info->spicepasswd[0]) {
+            else if (!info->spice.passwd[0]) {
                 LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                     "spice password can't be empty");
                 return NULL;
             }
         }
         spiceoptions = libxl__sprintf(gc, "port=%d,tls-port=%d",
-                       info->spiceport, info->spicetls_port);
-        if (info->spicehost)
+                                      info->spice.port, info->spice.tls_port);
+        if (info->spice.host)
             spiceoptions = libxl__sprintf(gc,
-                    "%s,addr=%s", spiceoptions, info->spicehost);
-        if (info->spicedisable_ticketing)
+                    "%s,addr=%s", spiceoptions, info->spice.host);
+        if (info->spice.disable_ticketing)
             spiceoptions = libxl__sprintf(gc, "%s,disable-ticketing",
                                                spiceoptions);
         else
             spiceoptions = libxl__sprintf(gc,
-                    "%s,password=%s", spiceoptions, info->spicepasswd);
+                    "%s,password=%s", spiceoptions, info->spice.passwd);
         spiceoptions = libxl__sprintf(gc, "%s,agent-mouse=%s", spiceoptions,
-                                      info->spiceagent_mouse ? "on" : "off");
+                                      info->spice.agent_mouse ? "on" : "off");
 
         flexarray_append(dm_args, "-spice");
         flexarray_append(dm_args, spiceoptions);
diff -r 83418dbcfc0a -r e241db296cbf tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -105,6 +105,26 @@ libxl_vnc_info = Struct("vnc_info", [
     ("findunused",    bool),
     ])
 
+libxl_spice_info = Struct("spice_info", [
+    ("enable",            bool),
+    # At least one of spice port or spicetls_post must be given
+    ("port",        integer),
+    ("tls_port",    integer),
+    # Interface to bind to
+    ("host",        string),
+    # enable client connection with no password
+    ("disable_ticketing", bool),
+    ("passwd",      string),
+    ("agent_mouse", bool),
+    ])
+
+libxl_sdl_info = Struct("sdl_info", [
+    ("enable",        bool),
+    ("opengl",        bool),
+    ("display",       string),
+    ("xauthority",    string),
+    ])
+
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
@@ -237,16 +257,7 @@ libxl_device_model_info = Struct("device
     ("keymap",           string),
     ("sdl",              bool),
     ("opengl",           bool), # (requires sdl enabled)
-    ("spice",            bool),
-    # At least one of spice port or spicetls_post must be given
-    ("spiceport",        integer),
-    ("spicetls_port",    integer),
-    # Interface to bind to
-    ("spicehost",        string),
-    # enable client connection with no password
-    ("spicedisable_ticketing", bool),
-    ("spicepasswd",      string),
-    ("spiceagent_mouse", bool),
+    ("spice",            libxl_spice_info),
     ("nographic",        bool),
     ("gfx_passthru",     bool),
     ("serial",           string),
diff -r 83418dbcfc0a -r e241db296cbf tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
@@ -380,13 +380,13 @@ static void printf_info(int domid,
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
         printf("\t\t\t(acpi %d)\n", dm_info->acpi);
-        printf("\t\t\t(spice %d)\n", dm_info->spice);
-        printf("\t\t\t(spiceport %d)\n", dm_info->spiceport);
-        printf("\t\t\t(spicetls_port %d)\n", dm_info->spicetls_port);
-        printf("\t\t\t(spicehost %s)\n", dm_info->spicehost);
+        printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
+        printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", dm_info->spice.host);
         printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    dm_info->spicedisable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spiceagent_mouse);
+                    dm_info->spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", dm_info->spice.agent_mouse);
         printf("\t\t)\n");
         break;
     case LIBXL_DOMAIN_TYPE_PV:
@@ -1191,19 +1191,20 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "opengl", &l, 0))
             dm_info->opengl = l;
         if (!xlu_cfg_get_long (config, "spice", &l, 0))
-            dm_info->spice = l;
+            dm_info->spice.enable = l;
         if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
-            dm_info->spiceport = l;
+            dm_info->spice.port = l;
         if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
-            dm_info->spicetls_port = l;
-        xlu_cfg_replace_string (config, "spicehost", &dm_info->spicehost, 0);
+            dm_info->spice.tls_port = l;
+        xlu_cfg_replace_string (config, "spicehost", &dm_info->spice.host, 0);
         if (!xlu_cfg_get_long (config, "spicedisable_ticketing", &l, 0))
-            dm_info->spicedisable_ticketing = l;
-        xlu_cfg_replace_string (config, "spicepasswd", &dm_info->spicepasswd, 0);
+            dm_info->spice.disable_ticketing = l;
+        xlu_cfg_replace_string (config, "spicepasswd",
+                                &dm_info->spice.passwd, 0);
         if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l, 0))
-            dm_info->spiceagent_mouse = l;
+            dm_info->spice.agent_mouse = l;
         else
-            dm_info->spiceagent_mouse = 1;
+            dm_info->spice.agent_mouse = 1;
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             dm_info->nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN23-0003Jd-UJ; Mon, 23 Jan 2012 16:46: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 1RpN21-0003Bo-Ih
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8643 invoked from network); 23 Jan 2012 16:46:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695402"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPK6032031;	Mon, 23 Jan 2012 08:45:26 -0800
MIME-Version: 1.0
X-Mercurial-Node: 63146f3cd17e526c53496adeeddf5da90f13d2bc
Message-ID: <63146f3cd17e526c5349.1327337124@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:24 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 20] libxl: remove comment support from IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID 63146f3cd17e526c53496adeeddf5da90f13d2bc
# Parent  80c94293e87d80c7f375ac330d46333c65d0005d
libxl: remove comment support from IDL

People typically don't look for comments in generated source and the syntax for
specifying them in the IDL makes things harder to follow.

Instead just use source code comments in the IDL itself.

I dropped a bunch of "foo bool # enable or disable foo" type comments. A lot of
the remainder still aren't terribly useful though.

No change to the generate code other than the comments being removed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 80c94293e87d -r 63146f3cd17e tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/gentypes.py	Mon Jan 23 16:38:17 2012 +0000
@@ -5,19 +5,6 @@ import re
 
 import libxltypes
 
-def format_comment(level, comment):
-    indent = reduce(lambda x,y: x + " ", range(level), "")
-    s  = "%s/*\n" % indent
-    s += "%s * " % indent
-    comment = comment.replace("\n", "\n%s * " % indent)
-    x = re.compile(r'^%s \* $' % indent, re.MULTILINE)
-    comment = x.sub("%s *" % indent, comment)
-    s += comment
-    s += "\n"
-    s += "%s */" % indent
-    s += "\n"
-    return s
-
 def libxl_C_instance_of(ty, instancename):
     if isinstance(ty, libxltypes.Aggregate) and ty.typename is None:
         if instancename is None:
@@ -30,17 +17,12 @@ def libxl_C_instance_of(ty, instancename
 def libxl_C_type_define(ty, indent = ""):
     s = ""
     if isinstance(ty, libxltypes.Enumeration):
-        if ty.comment is not None:
-            s += format_comment(0, ty.comment)
-
         if ty.typename is None:
             s += "enum {\n"
         else:
             s += "typedef enum %s {\n" % ty.typename
 
         for v in ty.values:
-            if v.comment is not None:
-                s += format_comment(4, v.comment)
             x = "%s = %d" % (v.name, v.value)
             x = x.replace("\n", "\n    ")
             s += "    " + x + ",\n"
@@ -50,17 +32,12 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, libxltypes.Aggregate):
-        if ty.comment is not None:
-            s += format_comment(0, ty.comment)
-
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
             s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
-            if f.comment is not None:
-                s += format_comment(4, f.comment)
             x = libxl_C_instance_of(f.type, f.name)
             if f.const:
                 x = "const " + x
diff -r 80c94293e87d -r 63146f3cd17e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -28,8 +28,8 @@ libxl_domain_type = Enumeration("domain_
     ])
 
 libxl_device_model_version = Enumeration("device_model_version", [
-    (1, "QEMU_XEN_TRADITIONAL", "Historical qemu-xen device model (qemu-dm)"),
-    (2, "QEMU_XEN", "Upstream based qemu-xen device model"),
+    (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm)
+    (2, "QEMU_XEN"),             # Upstream based qemu-xen device model
     ])
 
 libxl_console_type = Enumeration("console_type", [
@@ -98,18 +98,18 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
-    ("ssidref",      uint32),
+    ("ssidref",     uint32),
     ("running",     bool),
     ("blocked",     bool),
     ("paused",      bool),
     ("shutdown",    bool),
     ("dying",       bool),
 
-    ("shutdown_reason", uint8, False,
-"""Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
-
-Otherwise set to a value guaranteed not to clash with any valid
-SHUTDOWN_* constant."""),
+    # Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
+    #
+    # Otherwise set to a value guaranteed not to clash with any valid
+    # SHUTDOWN_* constant.
+    ("shutdown_reason", uint8),
     ("current_memkb",   uint64),
     ("shared_memkb", uint64),
     ("max_memkb",   uint64),
@@ -158,6 +158,11 @@ libxl_domain_create_info = Struct("domai
     ("poolid",       uint32),
     ])
 
+# Instances of libxl_file_reference contained in this struct which
+# have been mapped (with libxl_file_reference_map) will be unmapped
+# by libxl_domain_build/restore. If either of these are never called
+# then the user is responsible for calling
+# libxl_file_reference_unmap.
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
@@ -192,84 +197,87 @@ libxl_domain_build_info = Struct("domain
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
-                                      ("e820_host", bool, False, "Use host's E820 for PCI passthrough."),
+                                      # Use host's E820 for PCI passthrough.
+                                      ("e820_host", bool),
                                       ])),
                  ])),
     ],
-    comment =
-"""Instances of libxl_file_reference contained in this struct which
-have been mapped (with libxl_file_reference_map) will be unmapped
-by libxl_domain_build/restore. If either of these are never called
-then the user is responsible for calling
-libxl_file_reference_unmap.""")
+)
 
+# Device Model Information
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
-    ("uuid",             libxl_uuid,  False, "this is use only with stubdom, and must be different from the domain uuid"),
+    
+    # uuid is used only with stubdom, and must be different from the
+    # domain uuid
+    ("uuid",             libxl_uuid),
     ("dom_name",         string),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
-    ("device_model",     string, False, "if you set this you must set device_model_version too"),
+    # you set device_model you must set device_model_version too
+    ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
     ("target_ram",       uint32),
-    ("videoram",         integer,           False, "size of the videoram in MB"),
-    ("stdvga",           bool,              False, "stdvga enabled or disabled"),
-    ("vnc",              bool,              False, "vnc enabled or disabled"),
-    ("vnclisten",        string,            False, "address:port that should be listened on for the VNC server if vnc is set"),
-    ("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"),
-    ("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)"),
-    ("spice",            bool,              False,
-    "spice enabled or disabled"),
-    ("spiceport",        integer,           False,
-    "the port that should be listened on for the spice server"),
-    ("spicetls_port",    integer,           False, """the tls port
-that should be listened on for the spice server,
-at least one of the port or tls port must be given"""),
-    ("spicehost",        string,            False, """the interface
-that should be listened on if given otherwise any interface"""),
-    ("spicedisable_ticketing", bool,        False,
-    "enable client connection with no password"),
-    ("spicepasswd",      string,            False, """set ticket password
-witch must be used by a client for connection.
-The password never expires"""),
-    ("spiceagent_mouse", bool,              False,
-    "Whether spice agent is used for client mouse mode(default is on)"),
-    ("nographic",        bool,              False, "no graphics, use serial port"),
-    ("gfx_passthru",     bool,              False, "graphics passthrough enabled or disabled"),
-    ("serial",           string,            False, "serial port re-direct to pty deivce"),
-    ("boot",             string,            False, "boot order, for example dca"),
-    ("usb",              bool,              False, "usb support enabled or disabled"),
-    ("usbdevice",        string,            False, "enable usb mouse: tablet for absolute mouse, mouse for PS/2 protocol relative mouse"),
-    ("soundhw",          string,            False, "enable sound hardware"),
-    ("acpi",             bool,              False, "acpi enabled or disabled"),
-    ("vcpus",            integer,           False, "max number of vcpus"),
-    ("vcpu_avail",       integer,           False, "vcpus actually available"),
-    ("xen_platform_pci", bool,              False, "enable/disable the xen platform pci device"),
-    ("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"),
+    # size of the videoram in MB
+    ("videoram",         integer), 
+    ("stdvga",           bool),
+    ("vnc",              bool),
+    # "address:port" that should be listened on for the VNC server
+    ("vnclisten",        string),
+    ("vncpasswd",        string),
+    # VNC display number
+    ("vncdisplay",       integer),
+    # If set then try to find an unused port for the VNC server
+    ("vncunused",        bool),
+    # keyboard layout, default is en-us keyboard
+    ("keymap",           string),
+    ("sdl",              bool),
+    ("opengl",           bool), # (requires sdl enabled)
+    ("spice",            bool),
+    # At least one of spice port or spicetls_post must be given
+    ("spiceport",        integer),
+    ("spicetls_port",    integer),
+    # Interface to bind to
+    ("spicehost",        string),
+    # enable client connection with no password
+    ("spicedisable_ticketing", bool),
+    ("spicepasswd",      string),
+    ("spiceagent_mouse", bool),
+    ("nographic",        bool),
+    ("gfx_passthru",     bool),
+    ("serial",           string),
+    ("boot",             string),
+    ("usb",              bool),
+    # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
+    ("usbdevice",        string),
+    ("soundhw",          string),
+    ("acpi",             bool),
+    ("vcpus",            integer), # max number of vcpus
+    ("vcpu_avail",       integer), # vcpus actually available
+    ("xen_platform_pci", bool),
+    # extra parameters pass directly to qemu, NULL terminated
+    ("extra",            libxl_string_list),
+    # extra parameters pass directly to qemu for PV guest, NULL terminated
+    ("extra_pv",         libxl_string_list),
+    # extra parameters pass directly to qemu for HVM guest, NULL terminated
+    ("extra_hvm",        libxl_string_list),
     ],
-    comment=
-"""Device Model information.
-
-Network is missing""")
+)
 
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
-    ("vnc",           bool,     False, "vnc enabled or disabled"),
-    ("vnclisten",     string,   False, "address:port that should be listened on for the VNC server if vnc is set"),
-    ("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"),
-    ("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)"),
+    ("vnc",           bool),
+    # address:port that should be listened on for the VNC server if vnc is set
+    ("vnclisten",     string),
+    ("vncpasswd",     string),
+    ("vncdisplay",    integer),
+    ("vncunused",     bool),
+    # set keyboard layout, default is en-us keyboard
+    ("keymap",        string),
+    ("sdl",           bool),
+    ("opengl",        bool), # (if enabled requires sdl enabled)
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -346,13 +354,13 @@ libxl_nicinfo = Struct("nicinfo", [
     ])
 
 libxl_vcpuinfo = Struct("vcpuinfo", [
-    ("vcpuid", uint32,              False, "vcpu's id"),
-    ("cpu", uint32,                 False, "current mapping"),
-    ("online", bool,                False, "currently online (not hotplugged)?"),
-    ("blocked", bool,               False, "blocked waiting for an event?"),
-    ("running", bool,               False, "currently scheduled on its CPU?"),
-    ("vcpu_time", uint64,           False, "total vcpu time ran (ns)"),
-    ("cpumap", libxl_cpumap,        False, "current cpu's affinities"),
+    ("vcpuid", uint32),
+    ("cpu", uint32),
+    ("online", bool),
+    ("blocked", bool),
+    ("running", bool),
+    ("vcpu_time", uint64), # total vcpu time ran (ns)
+    ("cpumap", libxl_cpumap), # current cpu's affinities
     ])
 
 libxl_physinfo = Struct("physinfo", [
@@ -373,9 +381,9 @@ libxl_physinfo = Struct("physinfo", [
     ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_topologyinfo = Struct("topologyinfo", [
-    ("coremap", libxl_cpuarray,   False, "cpu to core map"),
-    ("socketmap", libxl_cpuarray, False, "cpu to socket map"),
-    ("nodemap", libxl_cpuarray,   False, "cpu to node map"),
+    ("coremap", libxl_cpuarray),   # cpu to core map
+    ("socketmap", libxl_cpuarray), # cpu to socket map
+    ("nodemap", libxl_cpuarray),   # cpu to node map
     ])
 
 libxl_sched_credit = Struct("sched_credit", [
diff -r 80c94293e87d -r 63146f3cd17e tools/libxl/libxltypes.py
--- a/tools/libxl/libxltypes.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxltypes.py	Mon Jan 23 16:38:17 2012 +0000
@@ -22,7 +22,6 @@ def _get_default_namespace():
 
 class Type(object):
     def __init__(self, typename, **kwargs):
-        self.comment = kwargs.setdefault('comment', None)
         self.namespace = kwargs.setdefault('namespace',
                 _get_default_namespace())
         self.dir = kwargs.setdefault('dir', DIR_BOTH)
@@ -120,7 +119,6 @@ class EnumerationValue(object):
         self.rawname = str.upper(enum.rawname) + "_" + self.valuename
         self.name = str.upper(enum.namespace) + self.rawname
         self.value = value
-        self.comment = kwargs.setdefault("comment", None)
 
 class Enumeration(Type):
     def __init__(self, typename, values, **kwargs):
@@ -129,16 +127,9 @@ class Enumeration(Type):
 
         self.values = []
         for v in values:
-            # (value, name[, comment=None])
-            if len(v) == 2:
-                (num,name) = v
-                comment = None
-            elif len(v) == 3:
-                num,name,comment = v
-            else:
-                raise ""
+            # (value, name)
+            (num,name) = v
             self.values.append(EnumerationValue(self, num, name,
-                                                comment=comment,
                                                 typename=self.rawname))
     def lookup(self, name):
         for v in self.values:
@@ -152,7 +143,6 @@ class Field(object):
         self.type = type
         self.name = name
         self.const = kwargs.setdefault('const', False)
-        self.comment = kwargs.setdefault('comment', None)
         self.enumname = kwargs.setdefault('enumname', None)
 
 class Aggregate(Type):
@@ -164,19 +154,17 @@ class Aggregate(Type):
 
         self.fields = []
         for f in fields:
-            # (name, type[, const=False[, comment=None]])
+            # (name, type[, const=False])
             if len(f) == 2:
                 n,t = f
                 const = False
-                comment = None
             elif len(f) == 3:
                 n,t,const = f
-                comment = None
             else:
-                n,t,const,comment = f
+                raise ValueError
             if n is None:
                 raise ValueError
-            self.fields.append(Field(t,n,const=const,comment=comment))
+            self.fields.append(Field(t,n,const=const))
 
     # Returns a tuple (stem, field-expr)
     #

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN23-0003Jd-UJ; Mon, 23 Jan 2012 16:46: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 1RpN21-0003Bo-Ih
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8643 invoked from network); 23 Jan 2012 16:46:02 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695402"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:28 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPK6032031;	Mon, 23 Jan 2012 08:45:26 -0800
MIME-Version: 1.0
X-Mercurial-Node: 63146f3cd17e526c53496adeeddf5da90f13d2bc
Message-ID: <63146f3cd17e526c5349.1327337124@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:24 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 01 of 20] libxl: remove comment support from IDL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336697 0
# Node ID 63146f3cd17e526c53496adeeddf5da90f13d2bc
# Parent  80c94293e87d80c7f375ac330d46333c65d0005d
libxl: remove comment support from IDL

People typically don't look for comments in generated source and the syntax for
specifying them in the IDL makes things harder to follow.

Instead just use source code comments in the IDL itself.

I dropped a bunch of "foo bool # enable or disable foo" type comments. A lot of
the remainder still aren't terribly useful though.

No change to the generate code other than the comments being removed.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 80c94293e87d -r 63146f3cd17e tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/gentypes.py	Mon Jan 23 16:38:17 2012 +0000
@@ -5,19 +5,6 @@ import re
 
 import libxltypes
 
-def format_comment(level, comment):
-    indent = reduce(lambda x,y: x + " ", range(level), "")
-    s  = "%s/*\n" % indent
-    s += "%s * " % indent
-    comment = comment.replace("\n", "\n%s * " % indent)
-    x = re.compile(r'^%s \* $' % indent, re.MULTILINE)
-    comment = x.sub("%s *" % indent, comment)
-    s += comment
-    s += "\n"
-    s += "%s */" % indent
-    s += "\n"
-    return s
-
 def libxl_C_instance_of(ty, instancename):
     if isinstance(ty, libxltypes.Aggregate) and ty.typename is None:
         if instancename is None:
@@ -30,17 +17,12 @@ def libxl_C_instance_of(ty, instancename
 def libxl_C_type_define(ty, indent = ""):
     s = ""
     if isinstance(ty, libxltypes.Enumeration):
-        if ty.comment is not None:
-            s += format_comment(0, ty.comment)
-
         if ty.typename is None:
             s += "enum {\n"
         else:
             s += "typedef enum %s {\n" % ty.typename
 
         for v in ty.values:
-            if v.comment is not None:
-                s += format_comment(4, v.comment)
             x = "%s = %d" % (v.name, v.value)
             x = x.replace("\n", "\n    ")
             s += "    " + x + ",\n"
@@ -50,17 +32,12 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, libxltypes.Aggregate):
-        if ty.comment is not None:
-            s += format_comment(0, ty.comment)
-
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
             s += "typedef %s %s {\n" % (ty.kind, ty.typename)
 
         for f in ty.fields:
-            if f.comment is not None:
-                s += format_comment(4, f.comment)
             x = libxl_C_instance_of(f.type, f.name)
             if f.const:
                 x = "const " + x
diff -r 80c94293e87d -r 63146f3cd17e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
@@ -28,8 +28,8 @@ libxl_domain_type = Enumeration("domain_
     ])
 
 libxl_device_model_version = Enumeration("device_model_version", [
-    (1, "QEMU_XEN_TRADITIONAL", "Historical qemu-xen device model (qemu-dm)"),
-    (2, "QEMU_XEN", "Upstream based qemu-xen device model"),
+    (1, "QEMU_XEN_TRADITIONAL"), # Historical qemu-xen device model (qemu-dm)
+    (2, "QEMU_XEN"),             # Upstream based qemu-xen device model
     ])
 
 libxl_console_type = Enumeration("console_type", [
@@ -98,18 +98,18 @@ libxl_tsc_mode = Enumeration("tsc_mode",
 libxl_dominfo = Struct("dominfo",[
     ("uuid",        libxl_uuid),
     ("domid",       libxl_domid),
-    ("ssidref",      uint32),
+    ("ssidref",     uint32),
     ("running",     bool),
     ("blocked",     bool),
     ("paused",      bool),
     ("shutdown",    bool),
     ("dying",       bool),
 
-    ("shutdown_reason", uint8, False,
-"""Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
-
-Otherwise set to a value guaranteed not to clash with any valid
-SHUTDOWN_* constant."""),
+    # Valid SHUTDOWN_* value from xen/sched.h iff (shutdown||dying).
+    #
+    # Otherwise set to a value guaranteed not to clash with any valid
+    # SHUTDOWN_* constant.
+    ("shutdown_reason", uint8),
     ("current_memkb",   uint64),
     ("shared_memkb", uint64),
     ("max_memkb",   uint64),
@@ -158,6 +158,11 @@ libxl_domain_create_info = Struct("domai
     ("poolid",       uint32),
     ])
 
+# Instances of libxl_file_reference contained in this struct which
+# have been mapped (with libxl_file_reference_map) will be unmapped
+# by libxl_domain_build/restore. If either of these are never called
+# then the user is responsible for calling
+# libxl_file_reference_unmap.
 libxl_domain_build_info = Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
@@ -192,84 +197,87 @@ libxl_domain_build_info = Struct("domain
                                       ("cmdline", string),
                                       ("ramdisk", libxl_file_reference),
                                       ("features", string, True),
-                                      ("e820_host", bool, False, "Use host's E820 for PCI passthrough."),
+                                      # Use host's E820 for PCI passthrough.
+                                      ("e820_host", bool),
                                       ])),
                  ])),
     ],
-    comment =
-"""Instances of libxl_file_reference contained in this struct which
-have been mapped (with libxl_file_reference_map) will be unmapped
-by libxl_domain_build/restore. If either of these are never called
-then the user is responsible for calling
-libxl_file_reference_unmap.""")
+)
 
+# Device Model Information
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
-    ("uuid",             libxl_uuid,  False, "this is use only with stubdom, and must be different from the domain uuid"),
+    
+    # uuid is used only with stubdom, and must be different from the
+    # domain uuid
+    ("uuid",             libxl_uuid),
     ("dom_name",         string),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
-    ("device_model",     string, False, "if you set this you must set device_model_version too"),
+    # you set device_model you must set device_model_version too
+    ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
     ("target_ram",       uint32),
-    ("videoram",         integer,           False, "size of the videoram in MB"),
-    ("stdvga",           bool,              False, "stdvga enabled or disabled"),
-    ("vnc",              bool,              False, "vnc enabled or disabled"),
-    ("vnclisten",        string,            False, "address:port that should be listened on for the VNC server if vnc is set"),
-    ("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"),
-    ("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)"),
-    ("spice",            bool,              False,
-    "spice enabled or disabled"),
-    ("spiceport",        integer,           False,
-    "the port that should be listened on for the spice server"),
-    ("spicetls_port",    integer,           False, """the tls port
-that should be listened on for the spice server,
-at least one of the port or tls port must be given"""),
-    ("spicehost",        string,            False, """the interface
-that should be listened on if given otherwise any interface"""),
-    ("spicedisable_ticketing", bool,        False,
-    "enable client connection with no password"),
-    ("spicepasswd",      string,            False, """set ticket password
-witch must be used by a client for connection.
-The password never expires"""),
-    ("spiceagent_mouse", bool,              False,
-    "Whether spice agent is used for client mouse mode(default is on)"),
-    ("nographic",        bool,              False, "no graphics, use serial port"),
-    ("gfx_passthru",     bool,              False, "graphics passthrough enabled or disabled"),
-    ("serial",           string,            False, "serial port re-direct to pty deivce"),
-    ("boot",             string,            False, "boot order, for example dca"),
-    ("usb",              bool,              False, "usb support enabled or disabled"),
-    ("usbdevice",        string,            False, "enable usb mouse: tablet for absolute mouse, mouse for PS/2 protocol relative mouse"),
-    ("soundhw",          string,            False, "enable sound hardware"),
-    ("acpi",             bool,              False, "acpi enabled or disabled"),
-    ("vcpus",            integer,           False, "max number of vcpus"),
-    ("vcpu_avail",       integer,           False, "vcpus actually available"),
-    ("xen_platform_pci", bool,              False, "enable/disable the xen platform pci device"),
-    ("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"),
+    # size of the videoram in MB
+    ("videoram",         integer), 
+    ("stdvga",           bool),
+    ("vnc",              bool),
+    # "address:port" that should be listened on for the VNC server
+    ("vnclisten",        string),
+    ("vncpasswd",        string),
+    # VNC display number
+    ("vncdisplay",       integer),
+    # If set then try to find an unused port for the VNC server
+    ("vncunused",        bool),
+    # keyboard layout, default is en-us keyboard
+    ("keymap",           string),
+    ("sdl",              bool),
+    ("opengl",           bool), # (requires sdl enabled)
+    ("spice",            bool),
+    # At least one of spice port or spicetls_post must be given
+    ("spiceport",        integer),
+    ("spicetls_port",    integer),
+    # Interface to bind to
+    ("spicehost",        string),
+    # enable client connection with no password
+    ("spicedisable_ticketing", bool),
+    ("spicepasswd",      string),
+    ("spiceagent_mouse", bool),
+    ("nographic",        bool),
+    ("gfx_passthru",     bool),
+    ("serial",           string),
+    ("boot",             string),
+    ("usb",              bool),
+    # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
+    ("usbdevice",        string),
+    ("soundhw",          string),
+    ("acpi",             bool),
+    ("vcpus",            integer), # max number of vcpus
+    ("vcpu_avail",       integer), # vcpus actually available
+    ("xen_platform_pci", bool),
+    # extra parameters pass directly to qemu, NULL terminated
+    ("extra",            libxl_string_list),
+    # extra parameters pass directly to qemu for PV guest, NULL terminated
+    ("extra_pv",         libxl_string_list),
+    # extra parameters pass directly to qemu for HVM guest, NULL terminated
+    ("extra_hvm",        libxl_string_list),
     ],
-    comment=
-"""Device Model information.
-
-Network is missing""")
+)
 
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
-    ("vnc",           bool,     False, "vnc enabled or disabled"),
-    ("vnclisten",     string,   False, "address:port that should be listened on for the VNC server if vnc is set"),
-    ("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"),
-    ("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)"),
+    ("vnc",           bool),
+    # address:port that should be listened on for the VNC server if vnc is set
+    ("vnclisten",     string),
+    ("vncpasswd",     string),
+    ("vncdisplay",    integer),
+    ("vncunused",     bool),
+    # set keyboard layout, default is en-us keyboard
+    ("keymap",        string),
+    ("sdl",           bool),
+    ("opengl",        bool), # (if enabled requires sdl enabled)
     ("display",       string),
     ("xauthority",    string),
     ])
@@ -346,13 +354,13 @@ libxl_nicinfo = Struct("nicinfo", [
     ])
 
 libxl_vcpuinfo = Struct("vcpuinfo", [
-    ("vcpuid", uint32,              False, "vcpu's id"),
-    ("cpu", uint32,                 False, "current mapping"),
-    ("online", bool,                False, "currently online (not hotplugged)?"),
-    ("blocked", bool,               False, "blocked waiting for an event?"),
-    ("running", bool,               False, "currently scheduled on its CPU?"),
-    ("vcpu_time", uint64,           False, "total vcpu time ran (ns)"),
-    ("cpumap", libxl_cpumap,        False, "current cpu's affinities"),
+    ("vcpuid", uint32),
+    ("cpu", uint32),
+    ("online", bool),
+    ("blocked", bool),
+    ("running", bool),
+    ("vcpu_time", uint64), # total vcpu time ran (ns)
+    ("cpumap", libxl_cpumap), # current cpu's affinities
     ])
 
 libxl_physinfo = Struct("physinfo", [
@@ -373,9 +381,9 @@ libxl_physinfo = Struct("physinfo", [
     ], dispose_fn=None, dir=DIR_OUT)
 
 libxl_topologyinfo = Struct("topologyinfo", [
-    ("coremap", libxl_cpuarray,   False, "cpu to core map"),
-    ("socketmap", libxl_cpuarray, False, "cpu to socket map"),
-    ("nodemap", libxl_cpuarray,   False, "cpu to node map"),
+    ("coremap", libxl_cpuarray),   # cpu to core map
+    ("socketmap", libxl_cpuarray), # cpu to socket map
+    ("nodemap", libxl_cpuarray),   # cpu to node map
     ])
 
 libxl_sched_credit = Struct("sched_credit", [
diff -r 80c94293e87d -r 63146f3cd17e tools/libxl/libxltypes.py
--- a/tools/libxl/libxltypes.py	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxltypes.py	Mon Jan 23 16:38:17 2012 +0000
@@ -22,7 +22,6 @@ def _get_default_namespace():
 
 class Type(object):
     def __init__(self, typename, **kwargs):
-        self.comment = kwargs.setdefault('comment', None)
         self.namespace = kwargs.setdefault('namespace',
                 _get_default_namespace())
         self.dir = kwargs.setdefault('dir', DIR_BOTH)
@@ -120,7 +119,6 @@ class EnumerationValue(object):
         self.rawname = str.upper(enum.rawname) + "_" + self.valuename
         self.name = str.upper(enum.namespace) + self.rawname
         self.value = value
-        self.comment = kwargs.setdefault("comment", None)
 
 class Enumeration(Type):
     def __init__(self, typename, values, **kwargs):
@@ -129,16 +127,9 @@ class Enumeration(Type):
 
         self.values = []
         for v in values:
-            # (value, name[, comment=None])
-            if len(v) == 2:
-                (num,name) = v
-                comment = None
-            elif len(v) == 3:
-                num,name,comment = v
-            else:
-                raise ""
+            # (value, name)
+            (num,name) = v
             self.values.append(EnumerationValue(self, num, name,
-                                                comment=comment,
                                                 typename=self.rawname))
     def lookup(self, name):
         for v in self.values:
@@ -152,7 +143,6 @@ class Field(object):
         self.type = type
         self.name = name
         self.const = kwargs.setdefault('const', False)
-        self.comment = kwargs.setdefault('comment', None)
         self.enumname = kwargs.setdefault('enumname', None)
 
 class Aggregate(Type):
@@ -164,19 +154,17 @@ class Aggregate(Type):
 
         self.fields = []
         for f in fields:
-            # (name, type[, const=False[, comment=None]])
+            # (name, type[, const=False])
             if len(f) == 2:
                 n,t = f
                 const = False
-                comment = None
             elif len(f) == 3:
                 n,t,const = f
-                comment = None
             else:
-                n,t,const,comment = f
+                raise ValueError
             if n is None:
                 raise ValueError
-            self.fields.append(Field(t,n,const=const,comment=comment))
+            self.fields.append(Field(t,n,const=const))
 
     # Returns a tuple (stem, field-expr)
     #

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN20-0003Fm-Vf; Mon, 23 Jan 2012 16:46:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN1y-0003DY-RE
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327337093!62158059!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11626 invoked from network); 23 Jan 2012 16:44:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695451"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:44 -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, 23 Jan 2012 11:45:43 -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
	q0NGjPKO032031;	Mon, 23 Jan 2012 08:45:42 -0800
MIME-Version: 1.0
X-Mercurial-Node: 62bffbc5495b3e897d6fbb654453f2335556e06e
Message-ID: <62bffbc5495b3e897d6f.1327337142@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:42 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 19 of 20] libxl: remove libxl_device_model_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 62bffbc5495b3e897d6fbb654453f2335556e06e
# Parent  4ef7e58d38791a1bbcb982e6f948ab1f0c805d5f
libxl: remove libxl_device_model_info.

All that is left here is the target domain's domid which we can pass around as
a parameter.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -2370,7 +2370,7 @@ out:
 }
 
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
-        libxl_device_model_info *dm_info, uint32_t *need_memkb)
+                             uint32_t *need_memkb)
 {
     GC_INIT(ctx);
     int rc = ERROR_INVAL;
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Jan 23 16:38:18 2012 +0000
@@ -230,7 +230,6 @@ enum {
 typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
-    libxl_device_model_info dm_info;
 
     int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
 
@@ -258,10 +257,6 @@ int libxl_init_create_info(libxl_ctx *ct
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
                           libxl_domain_create_info *c_info);
-int libxl_init_dm_info(libxl_ctx *ctx,
-                       libxl_device_model_info *dm_info,
-                       libxl_domain_create_info *c_info,
-                       libxl_domain_build_info *b_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
@@ -359,7 +354,7 @@ int libxl_set_memory_target(libxl_ctx *c
 int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target);
 /* how much free memory in the system a domain needs to be built */
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
-        libxl_device_model_info *dm_info, uint32_t *need_memkb);
+                             uint32_t *need_memkb);
 /* how much free memory is available in the system */
 int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb);
 /* wait for a given amount of memory to be free in the system */
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -48,7 +48,6 @@ void libxl_domain_config_dispose(libxl_d
 
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
-    libxl_device_model_info_dispose(&d_config->dm_info);
 }
 
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
@@ -127,17 +126,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     return 0;
 }
 
-int libxl_init_dm_info(libxl_ctx *ctx,
-                       libxl_device_model_info *dm_info,
-                       libxl_domain_create_info *c_info,
-                       libxl_domain_build_info *b_info)
-{
-    memset(dm_info, '\0', sizeof(*dm_info));
-
-
-    return 0;
-}
-
 static int init_console_info(libxl_device_console *console, int dev_num)
 {
     memset(console, 0x00, sizeof(libxl_device_console));
@@ -151,7 +139,6 @@ static int init_console_info(libxl_devic
 
 int libxl__domain_build(libxl__gc *gc,
                         libxl_domain_build_info *info,
-                        libxl_device_model_info *dm_info,
                         uint32_t domid,
                         libxl__domain_build_state *state)
 {
@@ -167,7 +154,7 @@ int libxl__domain_build(libxl__gc *gc,
 
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        ret = libxl__build_hvm(gc, domid, info, dm_info, state);
+        ret = libxl__build_hvm(gc, domid, info, state);
         if (ret)
             goto out;
 
@@ -221,8 +208,7 @@ out:
 
 static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
                           uint32_t domid, int fd,
-                          libxl__domain_build_state *state,
-                          libxl_device_model_info *dm_info)
+                          libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
@@ -474,7 +460,6 @@ static int do_domain_create(libxl__gc *g
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl_device_model_info *dm_info = &d_config->dm_info;
     libxl__domain_build_state state;
     uint32_t domid;
     int i, ret;
@@ -511,9 +496,9 @@ static int do_domain_create(libxl__gc *g
     memset(&state, 0, sizeof(state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state, dm_info);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, dm_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
     }
 
     if (ret) {
@@ -560,8 +545,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        dm_info->domid = domid;
-        ret = libxl__create_device_model(gc, d_config, dm_info,
+        ret = libxl__create_device_model(gc, domid, d_config,
                                          &state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -574,7 +558,6 @@ static int do_domain_create(libxl__gc *g
     {
         int need_qemu = 0;
         libxl_device_console console;
-        libxl_device_model_info xenpv_dm_info;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
             libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
@@ -596,11 +579,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_console_dispose(&console);
 
         if (need_qemu) {
-            /* only copy those useful configs */
-            memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-
-            libxl__create_xenpv_qemu(gc, domid, d_config,
-                                     &xenpv_dm_info, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
         }
         break;
     }
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -73,8 +73,7 @@ static const char *libxl__domain_bios(li
     }
 }
 
-static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config,
-                                    const libxl_device_model_info *info)
+static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config)
 {
     const libxl_vnc_info *vnc = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -85,8 +84,7 @@ static const libxl_vnc_info *dm_vnc(cons
     return vnc && vnc->enable ? vnc : NULL;
 }
 
-static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config,
-                                    const libxl_device_model_info *info)
+static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
 {
     const libxl_sdl_info *sdl = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -97,8 +95,7 @@ static const libxl_sdl_info *dm_sdl(cons
     return sdl && sdl->enable ? sdl : NULL;
 }
 
-static const char *dm_keymap(const libxl_domain_config *guest_config,
-                             const libxl_device_model_info *info)
+static const char *dm_keymap(const libxl_domain_config *guest_config)
 {
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         return guest_config->b_info.u.hvm.keymap;
@@ -109,18 +106,17 @@ static const char *dm_keymap(const libxl
 }
 
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const int num_vifs = guest_config->num_vifs;
-    const char *keymap = dm_keymap(guest_config, info);
+    const char *keymap = dm_keymap(guest_config);
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -129,7 +125,7 @@ static char ** libxl__build_device_model
         return NULL;
 
     flexarray_vappend(dm_args, dm,
-                      "-d", libxl__sprintf(gc, "%d", info->domid), NULL);
+                      "-d", libxl__sprintf(gc, "%d", domid), NULL);
 
     if (c_info->name)
         flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
@@ -225,7 +221,8 @@ static char ** libxl__build_device_model
                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname)
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc,
+                                            "tap%d.%d", domid, vifs[i].devid);
                 else
                     ifname = vifs[i].ifname;
                 flexarray_vappend(dm_args,
@@ -320,9 +317,8 @@ static char *dm_spice_options(libxl__gc 
 }
 
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int guest_domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -332,9 +328,9 @@ static char ** libxl__build_device_model
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
-    const char *keymap = dm_keymap(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config);
+    const char *keymap = dm_keymap(guest_config);
     flexarray_t *dm_args;
     int i;
 
@@ -343,14 +339,14 @@ static char ** libxl__build_device_model
         return NULL;
 
     flexarray_vappend(dm_args, dm,
-                      "-xen-domid", libxl__sprintf(gc, "%d", info->domid), NULL);
+                      "-xen-domid",
+                      libxl__sprintf(gc, "%d", guest_domid), NULL);
 
     flexarray_append(dm_args, "-chardev");
     flexarray_append(dm_args,
                      libxl__sprintf(gc, "socket,id=libxl-cmd,"
                                     "path=%s/qmp-libxl-%d,server,nowait",
-                                    libxl_run_dir_path(),
-                                    info->domid));
+                                    libxl_run_dir_path(), guest_domid));
 
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
@@ -460,7 +456,8 @@ static char ** libxl__build_device_model
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc, "tap%d.%d",
+                                            guest_domid, vifs[i].devid);
                 } else {
                     ifname = vifs[i].ifname;
                 }
@@ -581,18 +578,21 @@ static char ** libxl__build_device_model
 }
 
 static char ** libxl__build_device_model_args(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int guest_domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info, state);
+        return libxl__build_device_model_args_old(gc, dm,
+                                                  guest_domid, guest_config,
+                                                  state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info, state);
+        return libxl__build_device_model_args_new(gc, dm,
+                                                  guest_domid, guest_config,
+                                                  state);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          guest_config->b_info.device_model_version);
@@ -624,7 +624,9 @@ static int libxl__vfb_and_vkb_from_hvm_g
     return 0;
 }
 
-static int libxl__write_dmargs(libxl__gc *gc, int domid, int guest_domid, char **args)
+static int libxl__write_stub_dmargs(libxl__gc *gc,
+                                    int dm_domid, int guest_domid,
+                                    char **args)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i;
@@ -636,7 +638,7 @@ static int libxl__write_dmargs(libxl__gc
 
     roperm[0].id = 0;
     roperm[0].perms = XS_PERM_NONE;
-    roperm[1].id = domid;
+    roperm[1].id = dm_domid;
     roperm[1].perms = XS_PERM_READ;
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/vm", guest_domid));
@@ -673,8 +675,8 @@ retry_transaction:
 }
 
 static int libxl__create_stubdom(libxl__gc *gc,
+                                 int guest_domid,
                                  libxl_domain_config *guest_config,
-                                 libxl_device_model_info *info,
                                  libxl__domain_build_state *d_state,
                                  libxl__spawner_starting **starting_r)
 {
@@ -685,12 +687,11 @@ static int libxl__create_stubdom(libxl__
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
     libxl__domain_build_state stubdom_state;
-    uint32_t domid;
+    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
     libxl__spawner_starting *dm_starting = 0;
-    libxl_device_model_info xenpv_dm_info;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -700,7 +701,8 @@ static int libxl__create_stubdom(libxl__
 
     memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
+    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+                                    libxl__domid_to_name(gc, guest_domid));
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
@@ -713,7 +715,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
+    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
@@ -738,62 +740,69 @@ static int libxl__create_stubdom(libxl__
     dm_config.num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
+    dm_domid = 0;
+    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
     if (ret)
         goto out;
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info, d_state);
+    args = libxl__build_device_model_args(gc, "stubdom-dm", guest_domid,
+                                          guest_config, d_state);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
     }
 
-    libxl__write_dmargs(gc, domid, info->domid, args);
+    libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
     libxl__xs_write(gc, XBT_NULL,
-                   libxl__sprintf(gc, "%s/image/device-model-domid", libxl__xs_get_dompath(gc, info->domid)),
-                   "%d", domid);
+                   libxl__sprintf(gc, "%s/image/device-model-domid",
+                                  libxl__xs_get_dompath(gc, guest_domid)),
+                   "%d", dm_domid);
     libxl__xs_write(gc, XBT_NULL,
-                   libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)),
-                   "%d", info->domid);
-    ret = xc_domain_set_target(ctx->xch, domid, info->domid);
+                   libxl__sprintf(gc, "%s/target",
+                                  libxl__xs_get_dompath(gc, dm_domid)),
+                   "%d", guest_domid);
+    ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
     if (ret<0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting target domain %d -> %d", domid, info->domid);
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "setting target domain %d -> %d",
+                         dm_domid, guest_domid);
         ret = ERROR_FAIL;
         goto out_free;
     }
-    xs_set_target(ctx->xsh, domid, info->domid);
+    xs_set_target(ctx->xsh, dm_domid, guest_domid);
 
-    perm[0].id = domid;
+    perm[0].id = dm_domid;
     perm[0].perms = XS_PERM_NONE;
-    perm[1].id = info->domid;
+    perm[1].id = guest_domid;
     perm[1].perms = XS_PERM_READ;
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
-    xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid));
-    xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid), perm, ARRAY_SIZE(perm));
+    xs_mkdir(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid));
+    xs_set_permissions(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid),
+                       perm, ARRAY_SIZE(perm));
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
         if (ret)
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -818,14 +827,14 @@ retry_transaction:
             char *name;
             case STUBDOM_CONSOLE_LOGGING:
                 name = libxl__sprintf(gc, "qemu-dm-%s",
-                                      libxl_domid_to_name(ctx, info->domid));
+                                      libxl_domid_to_name(ctx, guest_domid));
                 libxl_create_logfile(ctx, name, &filename);
                 console[i].output = libxl__sprintf(gc, "file:%s", filename);
                 free(filename);
                 break;
             case STUBDOM_CONSOLE_SAVE:
                 console[i].output = libxl__sprintf(gc, "file:%s",
-                                libxl__device_model_savefile(gc, info->domid));
+                                libxl__device_model_savefile(gc, guest_domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
                 if (d_state->saved_state)
@@ -836,17 +845,14 @@ retry_transaction:
                 console[i].output = "pty";
                 break;
         }
-        ret = libxl__device_console_add(gc, domid, &console[i],
+        ret = libxl__device_console_add(gc, dm_domid, &console[i],
                         i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
-    memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-
-    if (libxl__create_xenpv_qemu(gc, domid,
+    if (libxl__create_xenpv_qemu(gc, dm_domid,
                                  &dm_config,
-                                 &xenpv_dm_info,
                                  &stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
@@ -857,12 +863,12 @@ retry_transaction:
         goto out_free;
     }
 
-    libxl_domain_unpause(ctx, domid);
+    libxl_domain_unpause(ctx, dm_domid);
 
     if (starting_r) {
         *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = info->domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, info->domid);
+        (*starting_r)->domid = guest_domid;
+        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
         (*starting_r)->for_spawn = NULL;
     }
 
@@ -875,15 +881,15 @@ out:
 }
 
 int libxl__create_device_model(libxl__gc *gc,
+                              int domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
@@ -895,7 +901,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (b_info->device_model_stubdomain) {
-        rc = libxl__create_stubdom(gc, guest_config, info, state, starting_r);
+        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
 
@@ -910,18 +916,18 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info, state);
+    args = libxl__build_device_model_args(gc, dm, domid, guest_config, state);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
     }
 
-    path = xs_get_domain_path(ctx->xsh, info->domid);
+    path = xs_get_domain_path(ctx->xsh, domid);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/hvmloader/bios", path),
                     "%s", libxl__domain_bios(gc, b_info));
     free(path);
 
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
                     "%d", !b_info->u.hvm.xen_platform_pci);
@@ -945,8 +951,8 @@ int libxl__create_device_model(libxl__gc
         p->for_spawn = NULL;
     }
 
-    p->domid = info->domid;
-    p->dom_path = libxl__xs_get_dompath(gc, info->domid);
+    p->domid = domid;
+    p->dom_path = libxl__xs_get_dompath(gc, domid);
     p->pid_path = "image/device-model-pid";
     if (!p->dom_path) {
         rc = ERROR_FAIL;
@@ -1068,14 +1074,6 @@ out:
     return ret;
 }
 
-static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
-                                        uint32_t domid,
-                                        libxl_device_model_info *info)
-{
-    info->domid = domid;
-    return 0;
-}
-
 int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1115,12 +1113,10 @@ out:
 
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
-                             libxl_device_model_info *info,
                              libxl__domain_build_state *state,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, info);
-    libxl__create_device_model(gc, guest_config, info, state, starting_r);
+    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
     return 0;
 }
 
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 16:38:18 2012 +0000
@@ -290,8 +290,7 @@ static int hvm_build_set_params(xc_inter
 }
 
 static const char *libxl__domain_firmware(libxl__gc *gc,
-                                          libxl_domain_build_info *info,
-                                          libxl_device_model_info *dm_info)
+                                          libxl_domain_build_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *firmware;
@@ -319,12 +318,11 @@ static const char *libxl__domain_firmwar
 
 int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info,
-              libxl_device_model_info *dm_info,
               libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret, rc = ERROR_FAIL;
-    const char *firmware = libxl__domain_firmware(gc, info, dm_info);
+    const char *firmware = libxl__domain_firmware(gc, info);
 
     if (!firmware)
         goto out;
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
@@ -263,7 +263,6 @@ _hidden int libxl__build_pv(libxl__gc *g
              libxl_domain_build_info *info, libxl__domain_build_state *state);
 _hidden int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info,
-              libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
@@ -485,10 +484,11 @@ _hidden void libxl__exec(int stdinfd, in
                const char *arg0, char **args); // logs errors, never returns
 
 /* from xl_create */
-_hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
+_hidden int libxl__domain_make(libxl__gc *gc,
+                               libxl_domain_create_info *info,
+                               uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,
                                 libxl_domain_build_info *info,
-                                libxl_device_model_info *dm_info,
                                 uint32_t domid,
                                 libxl__domain_build_state *state);
 
@@ -496,13 +496,12 @@ _hidden int libxl__domain_build(libxl__g
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
+                              int domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *dm_info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -266,12 +266,6 @@ libxl_domain_build_info = Struct("domain
     ],
 )
 
-# Device Model Information
-libxl_device_model_info = Struct("device_model_info",[
-    ("domid",            libxl_domid),
-    ],
-)
-
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -289,8 +289,7 @@ static void dolog(const char *file, int 
 }
 
 static void printf_info(int domid,
-                        libxl_domain_config *d_config,
-                        libxl_device_model_info *dm_info)
+                        libxl_domain_config *d_config)
 {
     int i;
     libxl_dominfo info;
@@ -571,8 +570,7 @@ static void split_string_into_string_lis
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
-                              libxl_domain_config *d_config,
-                              libxl_device_model_info *dm_info)
+                              libxl_domain_config *d_config)
 {
     const char *buf;
     long l;
@@ -1110,9 +1108,6 @@ skip_vfb:
         break;
     }
 
-    /* init dm from c and b */
-    if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
-        exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
     if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
@@ -1363,7 +1358,7 @@ struct domain_create {
     int no_incr_generationid;
 };
 
-static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
+static int freemem(libxl_domain_build_info *b_info)
 {
     int rc, retries = 3;
     uint32_t need_memkb, free_memkb;
@@ -1371,7 +1366,7 @@ static int freemem(libxl_domain_build_in
     if (!autoballoon)
         return 0;
 
-    rc = libxl_domain_need_memory(ctx, b_info, dm_info, &need_memkb);
+    rc = libxl_domain_need_memory(ctx, b_info, &need_memkb);
     if (rc < 0)
         return rc;
 
@@ -1554,7 +1549,7 @@ static int create_domain(struct domain_c
     if (!dom_info->quiet)
         printf("Parsing config file %s\n", config_file);
 
-    parse_config_data(config_file, config_data, config_len, &d_config, &d_config.dm_info);
+    parse_config_data(config_file, config_data, config_len, &d_config);
 
     if (migrate_fd >= 0) {
         if (d_config.c_info.name) {
@@ -1579,7 +1574,7 @@ static int create_domain(struct domain_c
             dom_info->no_incr_generationid;
 
     if (debug || dom_info->dryrun)
-        printf_info(-1, &d_config, &d_config.dm_info);
+        printf_info(-1, &d_config);
 
     ret = 0;
     if (dom_info->dryrun)
@@ -1592,7 +1587,7 @@ start:
     if (rc < 0)
         goto error_out;
 
-    ret = freemem(&d_config.b_info, &d_config.dm_info);
+    ret = freemem(&d_config.b_info);
     if (ret < 0) {
         fprintf(stderr, "failed to free memory for the domain\n");
         ret = ERROR_FAIL;
@@ -2336,7 +2331,6 @@ static void list_domains_details(const l
     char *config_file;
     uint8_t *data;
     int i, len, rc;
-    libxl_device_model_info dm_info;
 
     for (i = 0; i < nb_domain; i++) {
         /* no detailed info available on dom0 */
@@ -2347,8 +2341,8 @@ static void list_domains_details(const l
             continue;
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
-        parse_config_data(config_file, (char *)data, len, &d_config, &dm_info);
-        printf_info(info[i].domid, &d_config, &dm_info);
+        parse_config_data(config_file, (char *)data, len, &d_config);
+        printf_info(info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_file);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN24-0003Kc-Ic; Mon, 23 Jan 2012 16:46:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN22-0003Cf-Lt
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8736 invoked from network); 23 Jan 2012 16:46:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695428"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPKE032031;	Mon, 23 Jan 2012 08:45:33 -0800
MIME-Version: 1.0
X-Mercurial-Node: ceec8103098f611789c4fe6405b7f681d8b21f0e
Message-ID: <ceec8103098f611789c4.1327337132@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:32 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 20] libxl: remove redundant info from dm
	info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID ceec8103098f611789c4fe6405b7f681d8b21f0e
# Parent  e6287c6308bd2ef1fb6440ee2be4f0d5492566f9
libxl: remove redundant info from dm info.

Remove "target_ram", "acpi", "vcpus" and "vcpu_avail" from device model info
and use domain_build_info instead. These must all be consistently specified to
both the domain and the device model, there is no need (and a great deal of
danger) in exposing a way for a user of libxl to set them differently.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e6287c6308bd -r ceec8103098f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -119,11 +119,7 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
-    dm_info->target_ram = libxl__sizekb_to_mb(b_info->target_memkb);
     dm_info->videoram = libxl__sizekb_to_mb(b_info->video_memkb);
-    dm_info->acpi = b_info->u.hvm.acpi;
-    dm_info->vcpus = b_info->max_vcpus;
-    dm_info->vcpu_avail = b_info->cur_vcpus;
 
     dm_info->stdvga = 0;
     dm_info->vnc.enable = 1;
diff -r e6287c6308bd -r ceec8103098f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -78,6 +78,7 @@ static char ** libxl__build_device_model
                                         const libxl_domain_config *guest_config,
                                         const libxl_device_model_info *info)
 {
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_vifs = guest_config->num_vifs;
     int i;
@@ -159,14 +160,18 @@ static char ** libxl__build_device_model
         if (info->soundhw) {
             flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
         }
-        if (info->acpi) {
+        if (b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-acpi");
         }
-        if (info->vcpus > 1) {
-            flexarray_vappend(dm_args, "-vcpus", libxl__sprintf(gc, "%d", info->vcpus), NULL);
+        if (b_info->max_vcpus > 1) {
+            flexarray_vappend(dm_args, "-vcpus",
+                              libxl__sprintf(gc, "%d", b_info->max_vcpus),
+                              NULL);
         }
-        if (info->vcpu_avail) {
-            flexarray_vappend(dm_args, "-vcpu_avail", libxl__sprintf(gc, "0x%x", info->vcpu_avail), NULL);
+        if (b_info->cur_vcpus) {
+            flexarray_vappend(dm_args, "-vcpu_avail",
+                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
+                              NULL);
         }
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
@@ -234,6 +239,7 @@ static char ** libxl__build_device_model
                                         const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_disk *disks = guest_config->disks;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
@@ -366,15 +372,18 @@ static char ** libxl__build_device_model
         if (info->soundhw) {
             flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
         }
-        if (!info->acpi) {
+        if (!b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-no-acpi");
         }
-        if (info->vcpus > 1) {
+        if (b_info->max_vcpus > 1) {
             flexarray_append(dm_args, "-smp");
-            if (info->vcpu_avail)
-                flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d", info->vcpus, info->vcpu_avail));
+            if (b_info->cur_vcpus)
+                flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d",
+                                                         b_info->max_vcpus,
+                                                         b_info->cur_vcpus));
             else
-                flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->vcpus));
+                flexarray_append(dm_args, libxl__sprintf(gc, "%d",
+                                                         b_info->max_vcpus));
         }
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
@@ -432,7 +441,9 @@ static char ** libxl__build_device_model
 
     /* RAM Size */
     flexarray_append(dm_args, "-m");
-    flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->target_ram));
+    flexarray_append(dm_args,
+                     libxl__sprintf(gc, "%d",
+                                    libxl__sizekb_to_mb(b_info->target_memkb)));
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         for (i = 0; i < num_disks; i++) {
diff -r e6287c6308bd -r ceec8103098f tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -248,7 +248,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    ("target_ram",       uint32),
     # size of the videoram in MB
     ("videoram",         integer), 
     ("stdvga",           bool),
@@ -265,9 +264,6 @@ libxl_device_model_info = Struct("device
     # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
     ("usbdevice",        string),
     ("soundhw",          string),
-    ("acpi",             bool),
-    ("vcpus",            integer), # max number of vcpus
-    ("vcpu_avail",       integer), # vcpus actually available
     ("xen_platform_pci", bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
diff -r e6287c6308bd -r ceec8103098f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -379,7 +379,6 @@ static void printf_info(int domid,
         printf("\t\t\t(boot %s)\n", dm_info->boot);
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
-        printf("\t\t\t(acpi %d)\n", dm_info->acpi);
         printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
         printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
         printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN20-0003Fm-Vf; Mon, 23 Jan 2012 16:46:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN1y-0003DY-RE
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327337093!62158059!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11626 invoked from network); 23 Jan 2012 16:44:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695451"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:44 -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, 23 Jan 2012 11:45:43 -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
	q0NGjPKO032031;	Mon, 23 Jan 2012 08:45:42 -0800
MIME-Version: 1.0
X-Mercurial-Node: 62bffbc5495b3e897d6fbb654453f2335556e06e
Message-ID: <62bffbc5495b3e897d6f.1327337142@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:42 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 19 of 20] libxl: remove libxl_device_model_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 62bffbc5495b3e897d6fbb654453f2335556e06e
# Parent  4ef7e58d38791a1bbcb982e6f948ab1f0c805d5f
libxl: remove libxl_device_model_info.

All that is left here is the target domain's domid which we can pass around as
a parameter.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -2370,7 +2370,7 @@ out:
 }
 
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
-        libxl_device_model_info *dm_info, uint32_t *need_memkb)
+                             uint32_t *need_memkb)
 {
     GC_INIT(ctx);
     int rc = ERROR_INVAL;
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Jan 23 16:38:18 2012 +0000
@@ -230,7 +230,6 @@ enum {
 typedef struct {
     libxl_domain_create_info c_info;
     libxl_domain_build_info b_info;
-    libxl_device_model_info dm_info;
 
     int num_disks, num_vifs, num_pcidevs, num_vfbs, num_vkbs;
 
@@ -258,10 +257,6 @@ int libxl_init_create_info(libxl_ctx *ct
 int libxl_init_build_info(libxl_ctx *ctx,
                           libxl_domain_build_info *b_info,
                           libxl_domain_create_info *c_info);
-int libxl_init_dm_info(libxl_ctx *ctx,
-                       libxl_device_model_info *dm_info,
-                       libxl_domain_create_info *c_info,
-                       libxl_domain_build_info *b_info);
 typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void *priv);
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
@@ -359,7 +354,7 @@ int libxl_set_memory_target(libxl_ctx *c
 int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t *out_target);
 /* how much free memory in the system a domain needs to be built */
 int libxl_domain_need_memory(libxl_ctx *ctx, libxl_domain_build_info *b_info,
-        libxl_device_model_info *dm_info, uint32_t *need_memkb);
+                             uint32_t *need_memkb);
 /* how much free memory is available in the system */
 int libxl_get_free_memory(libxl_ctx *ctx, uint32_t *memkb);
 /* wait for a given amount of memory to be free in the system */
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -48,7 +48,6 @@ void libxl_domain_config_dispose(libxl_d
 
     libxl_domain_create_info_dispose(&d_config->c_info);
     libxl_domain_build_info_dispose(&d_config->b_info);
-    libxl_device_model_info_dispose(&d_config->dm_info);
 }
 
 int libxl_init_create_info(libxl_ctx *ctx, libxl_domain_create_info *c_info)
@@ -127,17 +126,6 @@ int libxl_init_build_info(libxl_ctx *ctx
     return 0;
 }
 
-int libxl_init_dm_info(libxl_ctx *ctx,
-                       libxl_device_model_info *dm_info,
-                       libxl_domain_create_info *c_info,
-                       libxl_domain_build_info *b_info)
-{
-    memset(dm_info, '\0', sizeof(*dm_info));
-
-
-    return 0;
-}
-
 static int init_console_info(libxl_device_console *console, int dev_num)
 {
     memset(console, 0x00, sizeof(libxl_device_console));
@@ -151,7 +139,6 @@ static int init_console_info(libxl_devic
 
 int libxl__domain_build(libxl__gc *gc,
                         libxl_domain_build_info *info,
-                        libxl_device_model_info *dm_info,
                         uint32_t domid,
                         libxl__domain_build_state *state)
 {
@@ -167,7 +154,7 @@ int libxl__domain_build(libxl__gc *gc,
 
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
-        ret = libxl__build_hvm(gc, domid, info, dm_info, state);
+        ret = libxl__build_hvm(gc, domid, info, state);
         if (ret)
             goto out;
 
@@ -221,8 +208,7 @@ out:
 
 static int domain_restore(libxl__gc *gc, libxl_domain_build_info *info,
                           uint32_t domid, int fd,
-                          libxl__domain_build_state *state,
-                          libxl_device_model_info *dm_info)
+                          libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char **vments = NULL, **localents = NULL;
@@ -474,7 +460,6 @@ static int do_domain_create(libxl__gc *g
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     libxl__spawner_starting *dm_starting = 0;
-    libxl_device_model_info *dm_info = &d_config->dm_info;
     libxl__domain_build_state state;
     uint32_t domid;
     int i, ret;
@@ -511,9 +496,9 @@ static int do_domain_create(libxl__gc *g
     memset(&state, 0, sizeof(state));
 
     if ( restore_fd >= 0 ) {
-        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state, dm_info);
+        ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state);
     } else {
-        ret = libxl__domain_build(gc, &d_config->b_info, dm_info, domid, &state);
+        ret = libxl__domain_build(gc, &d_config->b_info, domid, &state);
     }
 
     if (ret) {
@@ -560,8 +545,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_vkb_add(ctx, domid, &vkb);
         libxl_device_vkb_dispose(&vkb);
 
-        dm_info->domid = domid;
-        ret = libxl__create_device_model(gc, d_config, dm_info,
+        ret = libxl__create_device_model(gc, domid, d_config,
                                          &state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
@@ -574,7 +558,6 @@ static int do_domain_create(libxl__gc *g
     {
         int need_qemu = 0;
         libxl_device_console console;
-        libxl_device_model_info xenpv_dm_info;
 
         for (i = 0; i < d_config->num_vfbs; i++) {
             libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
@@ -596,11 +579,7 @@ static int do_domain_create(libxl__gc *g
         libxl_device_console_dispose(&console);
 
         if (need_qemu) {
-            /* only copy those useful configs */
-            memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-
-            libxl__create_xenpv_qemu(gc, domid, d_config,
-                                     &xenpv_dm_info, &state, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config, &state, &dm_starting);
         }
         break;
     }
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -73,8 +73,7 @@ static const char *libxl__domain_bios(li
     }
 }
 
-static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config,
-                                    const libxl_device_model_info *info)
+static const libxl_vnc_info *dm_vnc(const libxl_domain_config *guest_config)
 {
     const libxl_vnc_info *vnc = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -85,8 +84,7 @@ static const libxl_vnc_info *dm_vnc(cons
     return vnc && vnc->enable ? vnc : NULL;
 }
 
-static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config,
-                                    const libxl_device_model_info *info)
+static const libxl_sdl_info *dm_sdl(const libxl_domain_config *guest_config)
 {
     const libxl_sdl_info *sdl = NULL;
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
@@ -97,8 +95,7 @@ static const libxl_sdl_info *dm_sdl(cons
     return sdl && sdl->enable ? sdl : NULL;
 }
 
-static const char *dm_keymap(const libxl_domain_config *guest_config,
-                             const libxl_device_model_info *info)
+static const char *dm_keymap(const libxl_domain_config *guest_config)
 {
     if (guest_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) {
         return guest_config->b_info.u.hvm.keymap;
@@ -109,18 +106,17 @@ static const char *dm_keymap(const libxl
 }
 
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config);
     const int num_vifs = guest_config->num_vifs;
-    const char *keymap = dm_keymap(guest_config, info);
+    const char *keymap = dm_keymap(guest_config);
     int i;
     flexarray_t *dm_args;
     dm_args = flexarray_make(16, 1);
@@ -129,7 +125,7 @@ static char ** libxl__build_device_model
         return NULL;
 
     flexarray_vappend(dm_args, dm,
-                      "-d", libxl__sprintf(gc, "%d", info->domid), NULL);
+                      "-d", libxl__sprintf(gc, "%d", domid), NULL);
 
     if (c_info->name)
         flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
@@ -225,7 +221,8 @@ static char ** libxl__build_device_model
                                    LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname)
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc,
+                                            "tap%d.%d", domid, vifs[i].devid);
                 else
                     ifname = vifs[i].ifname;
                 flexarray_vappend(dm_args,
@@ -320,9 +317,8 @@ static char *dm_spice_options(libxl__gc 
 }
 
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int guest_domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -332,9 +328,9 @@ static char ** libxl__build_device_model
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
     const int num_vifs = guest_config->num_vifs;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
-    const libxl_sdl_info *sdl = dm_sdl(guest_config, info);
-    const char *keymap = dm_keymap(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
+    const libxl_sdl_info *sdl = dm_sdl(guest_config);
+    const char *keymap = dm_keymap(guest_config);
     flexarray_t *dm_args;
     int i;
 
@@ -343,14 +339,14 @@ static char ** libxl__build_device_model
         return NULL;
 
     flexarray_vappend(dm_args, dm,
-                      "-xen-domid", libxl__sprintf(gc, "%d", info->domid), NULL);
+                      "-xen-domid",
+                      libxl__sprintf(gc, "%d", guest_domid), NULL);
 
     flexarray_append(dm_args, "-chardev");
     flexarray_append(dm_args,
                      libxl__sprintf(gc, "socket,id=libxl-cmd,"
                                     "path=%s/qmp-libxl-%d,server,nowait",
-                                    libxl_run_dir_path(),
-                                    info->domid));
+                                    libxl_run_dir_path(), guest_domid));
 
     flexarray_append(dm_args, "-mon");
     flexarray_append(dm_args, "chardev=libxl-cmd,mode=control");
@@ -460,7 +456,8 @@ static char ** libxl__build_device_model
                                 LIBXL_MAC_FMT, LIBXL_MAC_BYTES(vifs[i].mac));
                 char *ifname;
                 if (!vifs[i].ifname) {
-                    ifname = libxl__sprintf(gc, "tap%d.%d", info->domid, vifs[i].devid);
+                    ifname = libxl__sprintf(gc, "tap%d.%d",
+                                            guest_domid, vifs[i].devid);
                 } else {
                     ifname = vifs[i].ifname;
                 }
@@ -581,18 +578,21 @@ static char ** libxl__build_device_model
 }
 
 static char ** libxl__build_device_model_args(libxl__gc *gc,
-                                        const char *dm,
+                                        const char *dm, int guest_domid,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info,
                                         const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info, state);
+        return libxl__build_device_model_args_old(gc, dm,
+                                                  guest_domid, guest_config,
+                                                  state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info, state);
+        return libxl__build_device_model_args_new(gc, dm,
+                                                  guest_domid, guest_config,
+                                                  state);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          guest_config->b_info.device_model_version);
@@ -624,7 +624,9 @@ static int libxl__vfb_and_vkb_from_hvm_g
     return 0;
 }
 
-static int libxl__write_dmargs(libxl__gc *gc, int domid, int guest_domid, char **args)
+static int libxl__write_stub_dmargs(libxl__gc *gc,
+                                    int dm_domid, int guest_domid,
+                                    char **args)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int i;
@@ -636,7 +638,7 @@ static int libxl__write_dmargs(libxl__gc
 
     roperm[0].id = 0;
     roperm[0].perms = XS_PERM_NONE;
-    roperm[1].id = domid;
+    roperm[1].id = dm_domid;
     roperm[1].perms = XS_PERM_READ;
 
     vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/vm", guest_domid));
@@ -673,8 +675,8 @@ retry_transaction:
 }
 
 static int libxl__create_stubdom(libxl__gc *gc,
+                                 int guest_domid,
                                  libxl_domain_config *guest_config,
-                                 libxl_device_model_info *info,
                                  libxl__domain_build_state *d_state,
                                  libxl__spawner_starting **starting_r)
 {
@@ -685,12 +687,11 @@ static int libxl__create_stubdom(libxl__
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
     libxl__domain_build_state stubdom_state;
-    uint32_t domid;
+    uint32_t dm_domid;
     char **args;
     struct xs_permissions perm[2];
     xs_transaction_t t;
     libxl__spawner_starting *dm_starting = 0;
-    libxl_device_model_info xenpv_dm_info;
 
     if (guest_config->b_info.device_model_version !=
         LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
@@ -700,7 +701,8 @@ static int libxl__create_stubdom(libxl__
 
     memset(&dm_config.c_info, 0x00, sizeof(libxl_domain_create_info));
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
-    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
+    dm_config.c_info.name = libxl__sprintf(gc, "%s-dm",
+                                    libxl__domid_to_name(gc, guest_domid));
 
     libxl_uuid_generate(&dm_config.c_info.uuid);
 
@@ -713,7 +715,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.b_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.b_info.u.pv.kernel.path = libxl__abs_path(gc, "ioemu-stubdom.gz",
                                               libxl_xenfirmwaredir_path());
-    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", info->domid);
+    dm_config.b_info.u.pv.cmdline = libxl__sprintf(gc, " -d %d", guest_domid);
     dm_config.b_info.u.pv.ramdisk.path = "";
     dm_config.b_info.u.pv.features = "";
 
@@ -738,62 +740,69 @@ static int libxl__create_stubdom(libxl__
     dm_config.num_vkbs = 1;
 
     /* fixme: this function can leak the stubdom if it fails */
-    domid = 0;
-    ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
+    dm_domid = 0;
+    ret = libxl__domain_make(gc, &dm_config.c_info, &dm_domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &stubdom_state);
+    ret = libxl__domain_build(gc, &dm_config.b_info, dm_domid, &stubdom_state);
     if (ret)
         goto out;
 
-    args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info, d_state);
+    args = libxl__build_device_model_args(gc, "stubdom-dm", guest_domid,
+                                          guest_config, d_state);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
     }
 
-    libxl__write_dmargs(gc, domid, info->domid, args);
+    libxl__write_stub_dmargs(gc, dm_domid, guest_domid, args);
     libxl__xs_write(gc, XBT_NULL,
-                   libxl__sprintf(gc, "%s/image/device-model-domid", libxl__xs_get_dompath(gc, info->domid)),
-                   "%d", domid);
+                   libxl__sprintf(gc, "%s/image/device-model-domid",
+                                  libxl__xs_get_dompath(gc, guest_domid)),
+                   "%d", dm_domid);
     libxl__xs_write(gc, XBT_NULL,
-                   libxl__sprintf(gc, "%s/target", libxl__xs_get_dompath(gc, domid)),
-                   "%d", info->domid);
-    ret = xc_domain_set_target(ctx->xch, domid, info->domid);
+                   libxl__sprintf(gc, "%s/target",
+                                  libxl__xs_get_dompath(gc, dm_domid)),
+                   "%d", guest_domid);
+    ret = xc_domain_set_target(ctx->xch, dm_domid, guest_domid);
     if (ret<0) {
-        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "setting target domain %d -> %d", domid, info->domid);
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                         "setting target domain %d -> %d",
+                         dm_domid, guest_domid);
         ret = ERROR_FAIL;
         goto out_free;
     }
-    xs_set_target(ctx->xsh, domid, info->domid);
+    xs_set_target(ctx->xsh, dm_domid, guest_domid);
 
-    perm[0].id = domid;
+    perm[0].id = dm_domid;
     perm[0].perms = XS_PERM_NONE;
-    perm[1].id = info->domid;
+    perm[1].id = guest_domid;
     perm[1].perms = XS_PERM_READ;
 retry_transaction:
     t = xs_transaction_start(ctx->xsh);
-    xs_mkdir(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid));
-    xs_set_permissions(ctx->xsh, t, libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid), perm, ARRAY_SIZE(perm));
+    xs_mkdir(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid));
+    xs_set_permissions(ctx->xsh, t,
+        libxl__sprintf(gc, "/local/domain/0/device-model/%d", guest_domid),
+                       perm, ARRAY_SIZE(perm));
     if (!xs_transaction_end(ctx->xsh, t, 0))
         if (errno == EAGAIN)
             goto retry_transaction;
 
     for (i = 0; i < dm_config.num_disks; i++) {
-        ret = libxl_device_disk_add(ctx, domid, &dm_config.disks[i]);
+        ret = libxl_device_disk_add(ctx, dm_domid, &dm_config.disks[i]);
         if (ret)
             goto out_free;
     }
     for (i = 0; i < dm_config.num_vifs; i++) {
-        ret = libxl_device_nic_add(ctx, domid, &dm_config.vifs[i]);
+        ret = libxl_device_nic_add(ctx, dm_domid, &dm_config.vifs[i]);
         if (ret)
             goto out_free;
     }
-    ret = libxl_device_vfb_add(ctx, domid, &dm_config.vfbs[0]);
+    ret = libxl_device_vfb_add(ctx, dm_domid, &dm_config.vfbs[0]);
     if (ret)
         goto out_free;
-    ret = libxl_device_vkb_add(ctx, domid, &dm_config.vkbs[0]);
+    ret = libxl_device_vkb_add(ctx, dm_domid, &dm_config.vkbs[0]);
     if (ret)
         goto out_free;
 
@@ -818,14 +827,14 @@ retry_transaction:
             char *name;
             case STUBDOM_CONSOLE_LOGGING:
                 name = libxl__sprintf(gc, "qemu-dm-%s",
-                                      libxl_domid_to_name(ctx, info->domid));
+                                      libxl_domid_to_name(ctx, guest_domid));
                 libxl_create_logfile(ctx, name, &filename);
                 console[i].output = libxl__sprintf(gc, "file:%s", filename);
                 free(filename);
                 break;
             case STUBDOM_CONSOLE_SAVE:
                 console[i].output = libxl__sprintf(gc, "file:%s",
-                                libxl__device_model_savefile(gc, info->domid));
+                                libxl__device_model_savefile(gc, guest_domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
                 if (d_state->saved_state)
@@ -836,17 +845,14 @@ retry_transaction:
                 console[i].output = "pty";
                 break;
         }
-        ret = libxl__device_console_add(gc, domid, &console[i],
+        ret = libxl__device_console_add(gc, dm_domid, &console[i],
                         i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
 
-    memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
-
-    if (libxl__create_xenpv_qemu(gc, domid,
+    if (libxl__create_xenpv_qemu(gc, dm_domid,
                                  &dm_config,
-                                 &xenpv_dm_info,
                                  &stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
@@ -857,12 +863,12 @@ retry_transaction:
         goto out_free;
     }
 
-    libxl_domain_unpause(ctx, domid);
+    libxl_domain_unpause(ctx, dm_domid);
 
     if (starting_r) {
         *starting_r = calloc(1, sizeof(libxl__spawner_starting));
-        (*starting_r)->domid = info->domid;
-        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, info->domid);
+        (*starting_r)->domid = guest_domid;
+        (*starting_r)->dom_path = libxl__xs_get_dompath(gc, guest_domid);
         (*starting_r)->for_spawn = NULL;
     }
 
@@ -875,15 +881,15 @@ out:
 }
 
 int libxl__create_device_model(libxl__gc *gc,
+                              int domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
-    const libxl_vnc_info *vnc = dm_vnc(guest_config, info);
+    const libxl_vnc_info *vnc = dm_vnc(guest_config);
     char *path, *logfile;
     int logfile_w, null;
     int rc;
@@ -895,7 +901,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (b_info->device_model_stubdomain) {
-        rc = libxl__create_stubdom(gc, guest_config, info, state, starting_r);
+        rc = libxl__create_stubdom(gc, domid, guest_config, state, starting_r);
         goto out;
     }
 
@@ -910,18 +916,18 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info, state);
+    args = libxl__build_device_model_args(gc, dm, domid, guest_config, state);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
     }
 
-    path = xs_get_domain_path(ctx->xsh, info->domid);
+    path = xs_get_domain_path(ctx->xsh, domid);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/hvmloader/bios", path),
                     "%s", libxl__domain_bios(gc, b_info));
     free(path);
 
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", domid);
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path),
                     "%d", !b_info->u.hvm.xen_platform_pci);
@@ -945,8 +951,8 @@ int libxl__create_device_model(libxl__gc
         p->for_spawn = NULL;
     }
 
-    p->domid = info->domid;
-    p->dom_path = libxl__xs_get_dompath(gc, info->domid);
+    p->domid = domid;
+    p->dom_path = libxl__xs_get_dompath(gc, domid);
     p->pid_path = "image/device-model-pid";
     if (!p->dom_path) {
         rc = ERROR_FAIL;
@@ -1068,14 +1074,6 @@ out:
     return ret;
 }
 
-static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
-                                        uint32_t domid,
-                                        libxl_device_model_info *info)
-{
-    info->domid = domid;
-    return 0;
-}
-
 int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,
         int nr_vfbs, libxl_device_vfb *vfbs,
@@ -1115,12 +1113,10 @@ out:
 
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
-                             libxl_device_model_info *info,
                              libxl__domain_build_state *state,
                              libxl__spawner_starting **starting_r)
 {
-    libxl__build_xenpv_qemu_args(gc, domid, info);
-    libxl__create_device_model(gc, guest_config, info, state, starting_r);
+    libxl__create_device_model(gc, domid, guest_config, state, starting_r);
     return 0;
 }
 
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 16:38:18 2012 +0000
@@ -290,8 +290,7 @@ static int hvm_build_set_params(xc_inter
 }
 
 static const char *libxl__domain_firmware(libxl__gc *gc,
-                                          libxl_domain_build_info *info,
-                                          libxl_device_model_info *dm_info)
+                                          libxl_domain_build_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const char *firmware;
@@ -319,12 +318,11 @@ static const char *libxl__domain_firmwar
 
 int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info,
-              libxl_device_model_info *dm_info,
               libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret, rc = ERROR_FAIL;
-    const char *firmware = libxl__domain_firmware(gc, info, dm_info);
+    const char *firmware = libxl__domain_firmware(gc, info);
 
     if (!firmware)
         goto out;
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
@@ -263,7 +263,6 @@ _hidden int libxl__build_pv(libxl__gc *g
              libxl_domain_build_info *info, libxl__domain_build_state *state);
 _hidden int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
               libxl_domain_build_info *info,
-              libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
@@ -485,10 +484,11 @@ _hidden void libxl__exec(int stdinfd, in
                const char *arg0, char **args); // logs errors, never returns
 
 /* from xl_create */
-_hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_create_info *info, uint32_t *domid);
+_hidden int libxl__domain_make(libxl__gc *gc,
+                               libxl_domain_create_info *info,
+                               uint32_t *domid);
 _hidden int libxl__domain_build(libxl__gc *gc,
                                 libxl_domain_build_info *info,
-                                libxl_device_model_info *dm_info,
                                 uint32_t domid,
                                 libxl__domain_build_state *state);
 
@@ -496,13 +496,12 @@ _hidden int libxl__domain_build(libxl__g
 _hidden const char *libxl__domain_device_model(libxl__gc *gc,
                                         const libxl_domain_build_info *info);
 _hidden int libxl__create_device_model(libxl__gc *gc,
+                              int domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
-                              libxl_device_model_info *dm_info,
                               libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -266,12 +266,6 @@ libxl_domain_build_info = Struct("domain
     ],
 )
 
-# Device Model Information
-libxl_device_model_info = Struct("device_model_info",[
-    ("domid",            libxl_domid),
-    ],
-)
-
 libxl_device_vfb = Struct("device_vfb", [
     ("backend_domid", libxl_domid),
     ("devid",         integer),
diff -r 4ef7e58d3879 -r 62bffbc5495b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -289,8 +289,7 @@ static void dolog(const char *file, int 
 }
 
 static void printf_info(int domid,
-                        libxl_domain_config *d_config,
-                        libxl_device_model_info *dm_info)
+                        libxl_domain_config *d_config)
 {
     int i;
     libxl_dominfo info;
@@ -571,8 +570,7 @@ static void split_string_into_string_lis
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
-                              libxl_domain_config *d_config,
-                              libxl_device_model_info *dm_info)
+                              libxl_domain_config *d_config)
 {
     const char *buf;
     long l;
@@ -1110,9 +1108,6 @@ skip_vfb:
         break;
     }
 
-    /* init dm from c and b */
-    if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
-        exit(1);
     /* parse device model arguments, this works for pv, hvm and stubdom */
     if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
         fprintf(stderr,
@@ -1363,7 +1358,7 @@ struct domain_create {
     int no_incr_generationid;
 };
 
-static int freemem(libxl_domain_build_info *b_info, libxl_device_model_info *dm_info)
+static int freemem(libxl_domain_build_info *b_info)
 {
     int rc, retries = 3;
     uint32_t need_memkb, free_memkb;
@@ -1371,7 +1366,7 @@ static int freemem(libxl_domain_build_in
     if (!autoballoon)
         return 0;
 
-    rc = libxl_domain_need_memory(ctx, b_info, dm_info, &need_memkb);
+    rc = libxl_domain_need_memory(ctx, b_info, &need_memkb);
     if (rc < 0)
         return rc;
 
@@ -1554,7 +1549,7 @@ static int create_domain(struct domain_c
     if (!dom_info->quiet)
         printf("Parsing config file %s\n", config_file);
 
-    parse_config_data(config_file, config_data, config_len, &d_config, &d_config.dm_info);
+    parse_config_data(config_file, config_data, config_len, &d_config);
 
     if (migrate_fd >= 0) {
         if (d_config.c_info.name) {
@@ -1579,7 +1574,7 @@ static int create_domain(struct domain_c
             dom_info->no_incr_generationid;
 
     if (debug || dom_info->dryrun)
-        printf_info(-1, &d_config, &d_config.dm_info);
+        printf_info(-1, &d_config);
 
     ret = 0;
     if (dom_info->dryrun)
@@ -1592,7 +1587,7 @@ start:
     if (rc < 0)
         goto error_out;
 
-    ret = freemem(&d_config.b_info, &d_config.dm_info);
+    ret = freemem(&d_config.b_info);
     if (ret < 0) {
         fprintf(stderr, "failed to free memory for the domain\n");
         ret = ERROR_FAIL;
@@ -2336,7 +2331,6 @@ static void list_domains_details(const l
     char *config_file;
     uint8_t *data;
     int i, len, rc;
-    libxl_device_model_info dm_info;
 
     for (i = 0; i < nb_domain; i++) {
         /* no detailed info available on dom0 */
@@ -2347,8 +2341,8 @@ static void list_domains_details(const l
             continue;
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
-        parse_config_data(config_file, (char *)data, len, &d_config, &dm_info);
-        printf_info(info[i].domid, &d_config, &dm_info);
+        parse_config_data(config_file, (char *)data, len, &d_config);
+        printf_info(info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_file);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN24-0003Kc-Ic; Mon, 23 Jan 2012 16:46:12 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN22-0003Cf-Lt
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8736 invoked from network); 23 Jan 2012 16:46:03 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695428"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:35 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPKE032031;	Mon, 23 Jan 2012 08:45:33 -0800
MIME-Version: 1.0
X-Mercurial-Node: ceec8103098f611789c4fe6405b7f681d8b21f0e
Message-ID: <ceec8103098f611789c4.1327337132@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:32 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 09 of 20] libxl: remove redundant info from dm
	info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID ceec8103098f611789c4fe6405b7f681d8b21f0e
# Parent  e6287c6308bd2ef1fb6440ee2be4f0d5492566f9
libxl: remove redundant info from dm info.

Remove "target_ram", "acpi", "vcpus" and "vcpu_avail" from device model info
and use domain_build_info instead. These must all be consistently specified to
both the domain and the device model, there is no need (and a great deal of
danger) in exposing a way for a user of libxl to set them differently.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e6287c6308bd -r ceec8103098f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -119,11 +119,7 @@ int libxl_init_dm_info(libxl_ctx *ctx,
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
-    dm_info->target_ram = libxl__sizekb_to_mb(b_info->target_memkb);
     dm_info->videoram = libxl__sizekb_to_mb(b_info->video_memkb);
-    dm_info->acpi = b_info->u.hvm.acpi;
-    dm_info->vcpus = b_info->max_vcpus;
-    dm_info->vcpu_avail = b_info->cur_vcpus;
 
     dm_info->stdvga = 0;
     dm_info->vnc.enable = 1;
diff -r e6287c6308bd -r ceec8103098f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -78,6 +78,7 @@ static char ** libxl__build_device_model
                                         const libxl_domain_config *guest_config,
                                         const libxl_device_model_info *info)
 {
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_vifs = guest_config->num_vifs;
     int i;
@@ -159,14 +160,18 @@ static char ** libxl__build_device_model
         if (info->soundhw) {
             flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
         }
-        if (info->acpi) {
+        if (b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-acpi");
         }
-        if (info->vcpus > 1) {
-            flexarray_vappend(dm_args, "-vcpus", libxl__sprintf(gc, "%d", info->vcpus), NULL);
+        if (b_info->max_vcpus > 1) {
+            flexarray_vappend(dm_args, "-vcpus",
+                              libxl__sprintf(gc, "%d", b_info->max_vcpus),
+                              NULL);
         }
-        if (info->vcpu_avail) {
-            flexarray_vappend(dm_args, "-vcpu_avail", libxl__sprintf(gc, "0x%x", info->vcpu_avail), NULL);
+        if (b_info->cur_vcpus) {
+            flexarray_vappend(dm_args, "-vcpu_avail",
+                              libxl__sprintf(gc, "0x%x", b_info->cur_vcpus),
+                              NULL);
         }
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
@@ -234,6 +239,7 @@ static char ** libxl__build_device_model
                                         const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_disk *disks = guest_config->disks;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_disks = guest_config->num_disks;
@@ -366,15 +372,18 @@ static char ** libxl__build_device_model
         if (info->soundhw) {
             flexarray_vappend(dm_args, "-soundhw", info->soundhw, NULL);
         }
-        if (!info->acpi) {
+        if (!b_info->u.hvm.acpi) {
             flexarray_append(dm_args, "-no-acpi");
         }
-        if (info->vcpus > 1) {
+        if (b_info->max_vcpus > 1) {
             flexarray_append(dm_args, "-smp");
-            if (info->vcpu_avail)
-                flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d", info->vcpus, info->vcpu_avail));
+            if (b_info->cur_vcpus)
+                flexarray_append(dm_args, libxl__sprintf(gc, "%d,maxcpus=%d",
+                                                         b_info->max_vcpus,
+                                                         b_info->cur_vcpus));
             else
-                flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->vcpus));
+                flexarray_append(dm_args, libxl__sprintf(gc, "%d",
+                                                         b_info->max_vcpus));
         }
         for (i = 0; i < num_vifs; i++) {
             if (vifs[i].nictype == LIBXL_NIC_TYPE_IOEMU) {
@@ -432,7 +441,9 @@ static char ** libxl__build_device_model
 
     /* RAM Size */
     flexarray_append(dm_args, "-m");
-    flexarray_append(dm_args, libxl__sprintf(gc, "%d", info->target_ram));
+    flexarray_append(dm_args,
+                     libxl__sprintf(gc, "%d",
+                                    libxl__sizekb_to_mb(b_info->target_memkb)));
 
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
         for (i = 0; i < num_disks; i++) {
diff -r e6287c6308bd -r ceec8103098f tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -248,7 +248,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    ("target_ram",       uint32),
     # size of the videoram in MB
     ("videoram",         integer), 
     ("stdvga",           bool),
@@ -265,9 +264,6 @@ libxl_device_model_info = Struct("device
     # usbdevice: "tablet" for absolute mouse, "mouse" for PS/2 protocol relative mouse
     ("usbdevice",        string),
     ("soundhw",          string),
-    ("acpi",             bool),
-    ("vcpus",            integer), # max number of vcpus
-    ("vcpu_avail",       integer), # vcpus actually available
     ("xen_platform_pci", bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
diff -r e6287c6308bd -r ceec8103098f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -379,7 +379,6 @@ static void printf_info(int domid,
         printf("\t\t\t(boot %s)\n", dm_info->boot);
         printf("\t\t\t(usb %d)\n", dm_info->usb);
         printf("\t\t\t(usbdevice %s)\n", dm_info->usbdevice);
-        printf("\t\t\t(acpi %d)\n", dm_info->acpi);
         printf("\t\t\t(spice %d)\n", dm_info->spice.enable);
         printf("\t\t\t(spiceport %d)\n", dm_info->spice.port);
         printf("\t\t\t(spicetls_port %d)\n", dm_info->spice.tls_port);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN25-0003MF-Ac; Mon, 23 Jan 2012 16:46:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN23-0003Cx-3X
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327337162!8943874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7851 invoked from network); 23 Jan 2012 16:46:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695432"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPKF032031;	Mon, 23 Jan 2012 08:45:34 -0800
MIME-Version: 1.0
X-Mercurial-Node: e5bc9888a14f19b625489b6b2cd7206c9f3be262
Message-ID: <e5bc9888a14f19b62548.1327337133@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:33 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 20] libxl: drop dm_info.dom_name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336698 0
# Node ID e5bc9888a14f19b625489b6b2cd7206c9f3be262
# Parent  ceec8103098f611789c4fe6405b7f681d8b21f0e
libxl: drop dm_info.dom_name

This is always the same as the c_info name which we now have available.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r ceec8103098f -r e5bc9888a14f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -115,7 +115,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 
     libxl_uuid_generate(&dm_info->uuid);
 
-    dm_info->dom_name = strdup(c_info->name);
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
diff -r ceec8103098f -r e5bc9888a14f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -78,6 +78,7 @@ static char ** libxl__build_device_model
                                         const libxl_domain_config *guest_config,
                                         const libxl_device_model_info *info)
 {
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_vifs = guest_config->num_vifs;
@@ -91,8 +92,8 @@ static char ** libxl__build_device_model
     flexarray_vappend(dm_args, dm,
                       "-d", libxl__sprintf(gc, "%d", info->domid), NULL);
 
-    if (info->dom_name)
-        flexarray_vappend(dm_args, "-domain-name", info->dom_name, NULL);
+    if (c_info->name)
+        flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
 
     if (info->vnc.enable) {
         char *vncarg;
@@ -239,6 +240,7 @@ static char ** libxl__build_device_model
                                         const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_disk *disks = guest_config->disks;
     const libxl_device_nic *vifs = guest_config->vifs;
@@ -268,8 +270,8 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-xen-attach");
     }
 
-    if (info->dom_name) {
-        flexarray_vappend(dm_args, "-name", info->dom_name, NULL);
+    if (c_info->name) {
+        flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
     if (info->vnc.enable) {
         int display = 0;
@@ -793,6 +795,7 @@ int libxl__create_device_model(libxl__gc
                               libxl_device_model_info *info,
                               libxl__spawner_starting **starting_r)
 {
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path, *logfile;
     int logfile_w, null;
@@ -835,7 +838,9 @@ int libxl__create_device_model(libxl__gc
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
 
-    libxl_create_logfile(ctx, libxl__sprintf(gc, "qemu-dm-%s", info->dom_name), &logfile);
+    libxl_create_logfile(ctx,
+                         libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
+                         &logfile);
     logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
     free(logfile);
     null = open("/dev/null", O_RDONLY);
@@ -981,8 +986,6 @@ static int libxl__build_xenpv_qemu_args(
                                         libxl_device_vfb *vfb,
                                         libxl_device_model_info *info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-
     if (vfb != NULL) {
         info->vnc.enable = vfb->vnc.enable;
         if (vfb->vnc.listen)
@@ -997,7 +1000,6 @@ static int libxl__build_xenpv_qemu_args(
     } else
         info->nographic = 1;
     info->domid = domid;
-    info->dom_name = libxl_domid_to_name(ctx, domid);
     return 0;
 }
 
diff -r ceec8103098f -r e5bc9888a14f tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -241,7 +241,6 @@ libxl_device_model_info = Struct("device
     # uuid is used only with stubdom, and must be different from the
     # domain uuid
     ("uuid",             libxl_uuid),
-    ("dom_name",         string),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN25-0003MF-Ac; Mon, 23 Jan 2012 16:46:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN23-0003Cx-3X
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327337162!8943874!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7851 invoked from network); 23 Jan 2012 16:46:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695432"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45: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
	q0NGjPKF032031;	Mon, 23 Jan 2012 08:45:34 -0800
MIME-Version: 1.0
X-Mercurial-Node: e5bc9888a14f19b625489b6b2cd7206c9f3be262
Message-ID: <e5bc9888a14f19b62548.1327337133@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:33 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 10 of 20] libxl: drop dm_info.dom_name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327336698 0
# Node ID e5bc9888a14f19b625489b6b2cd7206c9f3be262
# Parent  ceec8103098f611789c4fe6405b7f681d8b21f0e
libxl: drop dm_info.dom_name

This is always the same as the c_info name which we now have available.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r ceec8103098f -r e5bc9888a14f tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -115,7 +115,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 
     libxl_uuid_generate(&dm_info->uuid);
 
-    dm_info->dom_name = strdup(c_info->name);
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
diff -r ceec8103098f -r e5bc9888a14f tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -78,6 +78,7 @@ static char ** libxl__build_device_model
                                         const libxl_domain_config *guest_config,
                                         const libxl_device_model_info *info)
 {
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_nic *vifs = guest_config->vifs;
     const int num_vifs = guest_config->num_vifs;
@@ -91,8 +92,8 @@ static char ** libxl__build_device_model
     flexarray_vappend(dm_args, dm,
                       "-d", libxl__sprintf(gc, "%d", info->domid), NULL);
 
-    if (info->dom_name)
-        flexarray_vappend(dm_args, "-domain-name", info->dom_name, NULL);
+    if (c_info->name)
+        flexarray_vappend(dm_args, "-domain-name", c_info->name, NULL);
 
     if (info->vnc.enable) {
         char *vncarg;
@@ -239,6 +240,7 @@ static char ** libxl__build_device_model
                                         const libxl_device_model_info *info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
     const libxl_device_disk *disks = guest_config->disks;
     const libxl_device_nic *vifs = guest_config->vifs;
@@ -268,8 +270,8 @@ static char ** libxl__build_device_model
         flexarray_append(dm_args, "-xen-attach");
     }
 
-    if (info->dom_name) {
-        flexarray_vappend(dm_args, "-name", info->dom_name, NULL);
+    if (c_info->name) {
+        flexarray_vappend(dm_args, "-name", c_info->name, NULL);
     }
     if (info->vnc.enable) {
         int display = 0;
@@ -793,6 +795,7 @@ int libxl__create_device_model(libxl__gc
                               libxl_device_model_info *info,
                               libxl__spawner_starting **starting_r)
 {
+    const libxl_domain_create_info *c_info = &guest_config->c_info;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path, *logfile;
     int logfile_w, null;
@@ -835,7 +838,9 @@ int libxl__create_device_model(libxl__gc
     xs_mkdir(ctx->xsh, XBT_NULL, path);
     libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/disable_pf", path), "%d", !info->xen_platform_pci);
 
-    libxl_create_logfile(ctx, libxl__sprintf(gc, "qemu-dm-%s", info->dom_name), &logfile);
+    libxl_create_logfile(ctx,
+                         libxl__sprintf(gc, "qemu-dm-%s", c_info->name),
+                         &logfile);
     logfile_w = open(logfile, O_WRONLY|O_CREAT|O_APPEND, 0644);
     free(logfile);
     null = open("/dev/null", O_RDONLY);
@@ -981,8 +986,6 @@ static int libxl__build_xenpv_qemu_args(
                                         libxl_device_vfb *vfb,
                                         libxl_device_model_info *info)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
-
     if (vfb != NULL) {
         info->vnc.enable = vfb->vnc.enable;
         if (vfb->vnc.listen)
@@ -997,7 +1000,6 @@ static int libxl__build_xenpv_qemu_args(
     } else
         info->nographic = 1;
     info->domid = domid;
-    info->dom_name = libxl_domid_to_name(ctx, domid);
     return 0;
 }
 
diff -r ceec8103098f -r e5bc9888a14f tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -241,7 +241,6 @@ libxl_device_model_info = Struct("device
     # uuid is used only with stubdom, and must be different from the
     # domain uuid
     ("uuid",             libxl_uuid),
-    ("dom_name",         string),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN26-0003Ov-Hn; Mon, 23 Jan 2012 16:46: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 1RpN23-0003DH-F6
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8847 invoked from network); 23 Jan 2012 16:46:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695444"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45: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, 23 Jan 2012 11:45:41 -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
	q0NGjPKL032031;	Mon, 23 Jan 2012 08:45:40 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1f5af57bd77645f1e2e235b4cf786025aae4c73f
Message-ID: <1f5af57bd77645f1e2e2.1327337139@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:39 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 16 of 20] libxl: remove uuid from device model
	info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 1f5af57bd77645f1e2e235b4cf786025aae4c73f
# Parent  e5f62c6ec77ce933d4f5f92758e7d4aa5a7a6369
libxl: remove uuid from device model info.

This should be managed by libxl and need not be exposed to the user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e5f62c6ec77c -r 1f5af57bd776 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -128,8 +128,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 {
     memset(dm_info, '\0', sizeof(*dm_info));
 
-    libxl_uuid_generate(&dm_info->uuid);
-
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
diff -r e5f62c6ec77c -r 1f5af57bd776 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -697,7 +697,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
 
-    libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
+    libxl_uuid_generate(&dm_config.c_info.uuid);
 
     memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
     dm_config.b_info.type = dm_config.c_info.type;
diff -r e5f62c6ec77c -r 1f5af57bd776 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -257,9 +257,6 @@ libxl_domain_build_info = Struct("domain
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
     
-    # uuid is used only with stubdom, and must be different from the
-    # domain uuid
-    ("uuid",             libxl_uuid),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN26-0003Ov-Hn; Mon, 23 Jan 2012 16:46: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 1RpN23-0003DH-F6
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8847 invoked from network); 23 Jan 2012 16:46:04 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695444"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45: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, 23 Jan 2012 11:45:41 -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
	q0NGjPKL032031;	Mon, 23 Jan 2012 08:45:40 -0800
MIME-Version: 1.0
X-Mercurial-Node: 1f5af57bd77645f1e2e235b4cf786025aae4c73f
Message-ID: <1f5af57bd77645f1e2e2.1327337139@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:39 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 16 of 20] libxl: remove uuid from device model
	info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID 1f5af57bd77645f1e2e235b4cf786025aae4c73f
# Parent  e5f62c6ec77ce933d4f5f92758e7d4aa5a7a6369
libxl: remove uuid from device model info.

This should be managed by libxl and need not be exposed to the user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r e5f62c6ec77c -r 1f5af57bd776 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -128,8 +128,6 @@ int libxl_init_dm_info(libxl_ctx *ctx,
 {
     memset(dm_info, '\0', sizeof(*dm_info));
 
-    libxl_uuid_generate(&dm_info->uuid);
-
     dm_info->device_model_version = LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
     dm_info->device_model_stubdomain = false;
     dm_info->device_model = NULL;
diff -r e5f62c6ec77c -r 1f5af57bd776 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -697,7 +697,7 @@ static int libxl__create_stubdom(libxl__
     dm_config.c_info.type = LIBXL_DOMAIN_TYPE_PV;
     dm_config.c_info.name = libxl__sprintf(gc, "%s-dm", libxl__domid_to_name(gc, info->domid));
 
-    libxl_uuid_copy(&dm_config.c_info.uuid, &info->uuid);
+    libxl_uuid_generate(&dm_config.c_info.uuid);
 
     memset(&dm_config.b_info, 0x00, sizeof(libxl_domain_build_info));
     dm_config.b_info.type = dm_config.c_info.type;
diff -r e5f62c6ec77c -r 1f5af57bd776 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -257,9 +257,6 @@ libxl_domain_build_info = Struct("domain
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
     
-    # uuid is used only with stubdom, and must be different from the
-    # domain uuid
-    ("uuid",             libxl_uuid),
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
     # you set device_model you must set device_model_version too

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN27-0003QW-8o; Mon, 23 Jan 2012 16:46:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN23-0003DV-M7
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327337162!8943874!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7911 invoked from network); 23 Jan 2012 16:46:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695438"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:39 -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
	q0NGjPKJ032031;	Mon, 23 Jan 2012 08:45:38 -0800
MIME-Version: 1.0
X-Mercurial-Node: b8a133e35c9100d301a19c217ee275b0a01ae55c
Message-ID: <b8a133e35c9100d301a1.1327337137@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:37 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 20] libxl: move gfx_passthru setting to
	b_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID b8a133e35c9100d301a19c217ee275b0a01ae55c
# Parent  6caa4c9b20e176884050310999c5a5eb4c555a41
libxl: move gfx_passthru setting to b_info->u.hvm

Although xl parsed this value for both PV and HVM domains (and then a second
time for HVM domains) inside libxl it only impacts HVM guests so I think this
is the right place for it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 6caa4c9b20e1 -r b8a133e35c91 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -240,7 +240,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (info->gfx_passthru) {
+        if (b_info->u.hvm.gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -480,7 +480,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (info->gfx_passthru) {
+        if (b_info->u.hvm.gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 6caa4c9b20e1 -r b8a133e35c91 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -227,6 +227,8 @@ libxl_domain_build_info = Struct("domain
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
+                                       ("gfx_passthru",     bool),
+                                       
                                        ("serial",           string),
                                        ("boot",             string),
                                        ("usb",              bool),
@@ -264,7 +266,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    ("gfx_passthru",     bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 6caa4c9b20e1 -r b8a133e35c91 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -381,7 +381,7 @@ static void printf_info(int domid,
         printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
+        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
@@ -732,9 +732,6 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-        dm_info->gfx_passthru = l;
-
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
@@ -1208,7 +1205,7 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            dm_info->gfx_passthru = l;
+            b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         if (!xlu_cfg_get_long (config, "usb", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN27-0003QW-8o; Mon, 23 Jan 2012 16:46:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN23-0003DV-M7
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327337162!8943874!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7911 invoked from network); 23 Jan 2012 16:46:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695438"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 11:45:39 -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
	q0NGjPKJ032031;	Mon, 23 Jan 2012 08:45:38 -0800
MIME-Version: 1.0
X-Mercurial-Node: b8a133e35c9100d301a19c217ee275b0a01ae55c
Message-ID: <b8a133e35c9100d301a1.1327337137@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:37 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 14 of 20] libxl: move gfx_passthru setting to
	b_info->u.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327336698 0
# Node ID b8a133e35c9100d301a19c217ee275b0a01ae55c
# Parent  6caa4c9b20e176884050310999c5a5eb4c555a41
libxl: move gfx_passthru setting to b_info->u.hvm

Although xl parsed this value for both PV and HVM domains (and then a second
time for HVM domains) inside libxl it only impacts HVM guests so I think this
is the right place for it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 6caa4c9b20e1 -r b8a133e35c91 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -240,7 +240,7 @@ static char ** libxl__build_device_model
         if ( ioemu_vifs == 0 ) {
             flexarray_vappend(dm_args, "-net", "none", NULL);
         }
-        if (info->gfx_passthru) {
+        if (b_info->u.hvm.gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
@@ -480,7 +480,7 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-net");
             flexarray_append(dm_args, "none");
         }
-        if (info->gfx_passthru) {
+        if (b_info->u.hvm.gfx_passthru) {
             flexarray_append(dm_args, "-gfx_passthru");
         }
     } else {
diff -r 6caa4c9b20e1 -r b8a133e35c91 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -227,6 +227,8 @@ libxl_domain_build_info = Struct("domain
                                        ("sdl",              libxl_sdl_info),
                                        ("spice",            libxl_spice_info),
                                        
+                                       ("gfx_passthru",     bool),
+                                       
                                        ("serial",           string),
                                        ("boot",             string),
                                        ("usb",              bool),
@@ -264,7 +266,6 @@ libxl_device_model_info = Struct("device
     ("device_model",     string),
     ("saved_state",      string),
     ("type",             libxl_domain_type),
-    ("gfx_passthru",     bool),
     # extra parameters pass directly to qemu, NULL terminated
     ("extra",            libxl_string_list),
     # extra parameters pass directly to qemu for PV guest, NULL terminated
diff -r 6caa4c9b20e1 -r b8a133e35c91 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 16:38:18 2012 +0000
@@ -381,7 +381,7 @@ static void printf_info(int domid,
         printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
 
         printf("\t\t\t(device_model %s)\n", dm_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", dm_info->gfx_passthru);
+        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
         printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
         printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
         printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
@@ -732,9 +732,6 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "videoram", &l, 0))
         b_info->video_memkb = l * 1024;
 
-    if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-        dm_info->gfx_passthru = l;
-
     switch(c_info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
         if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
@@ -1208,7 +1205,7 @@ skip_vfb:
         if (!xlu_cfg_get_long (config, "nographic", &l, 0))
             b_info->u.hvm.nographic = l;
         if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
-            dm_info->gfx_passthru = l;
+            b_info->u.hvm.gfx_passthru = l;
         xlu_cfg_replace_string (config, "serial", &b_info->u.hvm.serial, 0);
         xlu_cfg_replace_string (config, "boot", &b_info->u.hvm.boot, 0);
         if (!xlu_cfg_get_long (config, "usb", &l, 0))

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN28-0003Ro-0G; Mon, 23 Jan 2012 16:46:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN24-0003EY-Ub
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8874 invoked from network); 23 Jan 2012 16:46:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695448"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:43 -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, 23 Jan 2012 11:45:42 -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
	q0NGjPKN032031;	Mon, 23 Jan 2012 08:45:42 -0800
MIME-Version: 1.0
X-Mercurial-Node: 4ef7e58d38791a1bbcb982e6f948ab1f0c805d5f
Message-ID: <4ef7e58d38791a1bbcb9.1327337141@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:41 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 18 of 20] libxl: move "saved_state" to
 libxl__domain_build_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 1327336698 0
# Node ID 4ef7e58d38791a1bbcb982e6f948ab1f0c805d5f
# Parent  3101b9483229b61afe4945949832c04abe323a59
libxl: move "saved_state" to libxl__domain_build_state.

This is internal to the library and need not be exposed to the user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3101b9483229 -r 4ef7e58d3879 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -275,9 +275,8 @@ static int domain_restore(libxl__gc *gc,
     if (ret)
         goto out;
 
-    dm_info->saved_state = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&dm_info->saved_state,
+        ret = asprintf(&state->saved_state,
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
         ret = (ret < 0) ? ERROR_FAIL : 0;
     }
@@ -509,13 +508,11 @@ static int do_domain_create(libxl__gc *g
         }
     }
 
+    memset(&state, 0, sizeof(state));
+
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state, dm_info);
     } else {
-        if (dm_info->saved_state) {
-            free(dm_info->saved_state);
-            dm_info->saved_state = NULL;
-        }
         ret = libxl__domain_build(gc, &d_config->b_info, dm_info, domid, &state);
     }
 
@@ -565,7 +562,7 @@ static int do_domain_create(libxl__gc *g
 
         dm_info->domid = domid;
         ret = libxl__create_device_model(gc, d_config, dm_info,
-                                        &dm_starting);
+                                         &state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -602,8 +599,8 @@ static int do_domain_create(libxl__gc *g
             /* only copy those useful configs */
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
 
-            libxl__create_xenpv_qemu(gc, domid,
-                                     d_config, &xenpv_dm_info, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config,
+                                     &xenpv_dm_info, &state, &dm_starting);
         }
         break;
     }
@@ -617,7 +614,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_info, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff -r 3101b9483229 -r 4ef7e58d3879 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -111,7 +111,8 @@ static const char *dm_keymap(const libxl
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
@@ -248,8 +249,8 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-nographic");
     }
 
-    if (info->saved_state) {
-        flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
+    if (state->saved_state) {
+        flexarray_vappend(dm_args, "-loadvm", state->saved_state, NULL);
     }
     for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
         flexarray_append(dm_args, b_info->extra[i]);
@@ -321,7 +322,8 @@ static char *dm_spice_options(libxl__gc 
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
@@ -489,9 +491,9 @@ static char ** libxl__build_device_model
         }
     }
 
-    if (info->saved_state) {
+    if (state->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
-        int migration_fd = open(info->saved_state, O_RDONLY);
+        int migration_fd = open(state->saved_state, O_RDONLY);
         flexarray_append(dm_args, "-incoming");
         flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
@@ -581,15 +583,16 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info);
+        return libxl__build_device_model_args_old(gc, dm, guest_config, info, state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info);
+        return libxl__build_device_model_args_new(gc, dm, guest_config, info, state);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          guest_config->b_info.device_model_version);
@@ -672,6 +675,7 @@ retry_transaction:
 static int libxl__create_stubdom(libxl__gc *gc,
                                  libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
+                                 libxl__domain_build_state *d_state,
                                  libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -680,7 +684,7 @@ static int libxl__create_stubdom(libxl__
     libxl_domain_config dm_config;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state state;
+    libxl__domain_build_state stubdom_state;
     uint32_t domid;
     char **args;
     struct xs_permissions perm[2];
@@ -738,12 +742,12 @@ static int libxl__create_stubdom(libxl__
     ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &state);
+    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &stubdom_state);
     if (ret)
         goto out;
 
     args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info);
+                                          guest_config, info, d_state);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
@@ -813,7 +817,8 @@ retry_transaction:
             char *filename;
             char *name;
             case STUBDOM_CONSOLE_LOGGING:
-                name = libxl__sprintf(gc, "qemu-dm-%s", libxl_domid_to_name(ctx, info->domid));
+                name = libxl__sprintf(gc, "qemu-dm-%s",
+                                      libxl_domid_to_name(ctx, info->domid));
                 libxl_create_logfile(ctx, name, &filename);
                 console[i].output = libxl__sprintf(gc, "file:%s", filename);
                 free(filename);
@@ -823,15 +828,16 @@ retry_transaction:
                                 libxl__device_model_savefile(gc, info->domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
-                if (info->saved_state)
-                    console[i].output = libxl__sprintf(gc, "pipe:%s", info->saved_state);
+                if (d_state->saved_state)
+                    console[i].output =
+                        libxl__sprintf(gc, "pipe:%s", d_state->saved_state);
                 break;
             default:
                 console[i].output = "pty";
                 break;
         }
         ret = libxl__device_console_add(gc, domid, &console[i],
-                                    i == STUBDOM_CONSOLE_LOGGING ? &state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
@@ -841,12 +847,12 @@ retry_transaction:
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
                                  &xenpv_dm_info,
+                                 &stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
-    if (libxl__confirm_device_model_startup(gc, &xenpv_dm_info,
-                                            dm_starting) < 0) {
+    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -871,6 +877,7 @@ out:
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -888,7 +895,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (b_info->device_model_stubdomain) {
-        rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
+        rc = libxl__create_stubdom(gc, guest_config, info, state, starting_r);
         goto out;
     }
 
@@ -903,7 +910,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info);
+    args = libxl__build_device_model_args(gc, dm, guest_config, info, state);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
@@ -984,10 +991,9 @@ out:
 
 
 int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl_device_model_info *dm_info,
+                                libxl__domain_build_state *state,
                                 libxl__spawner_starting *starting)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     int domid = starting->domid;
     int ret, ret2;
@@ -995,11 +1001,11 @@ int libxl__confirm_device_model_startup(
     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,
+    if (state->saved_state) {
+        ret2 = unlink(state->saved_state);
+        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
                                    "failed to remove device-model state %s\n",
-                                   dm_info->saved_state);
+                                   state->saved_state);
         /* Do not clobber spawn_confirm error code with unlink error code. */
         if (!ret) ret = ret2;
     }
@@ -1110,10 +1116,11 @@ out:
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
+                             libxl__domain_build_state *state,
                              libxl__spawner_starting **starting_r)
 {
     libxl__build_xenpv_qemu_args(gc, domid, info);
-    libxl__create_device_model(gc, guest_config, info, starting_r);
+    libxl__create_device_model(gc, guest_config, info, state, starting_r);
     return 0;
 }
 
diff -r 3101b9483229 -r 4ef7e58d3879 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
@@ -247,7 +247,10 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+
     unsigned long vm_generationid_addr;
+
+    char *saved_state;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
@@ -495,10 +498,12 @@ _hidden const char *libxl__domain_device
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,
@@ -508,7 +513,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__domain_build_state *state,
                               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,
diff -r 3101b9483229 -r 4ef7e58d3879 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -269,8 +269,6 @@ libxl_domain_build_info = Struct("domain
 # Device Model Information
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
-    
-    ("saved_state",      string),
     ],
 )
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16: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 1RpN28-0003Ro-0G; Mon, 23 Jan 2012 16:46:16 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpN24-0003EY-Ub
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327337157!6123890!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8874 invoked from network); 23 Jan 2012 16:46:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="178695448"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:45:43 -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, 23 Jan 2012 11:45:42 -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
	q0NGjPKN032031;	Mon, 23 Jan 2012 08:45:42 -0800
MIME-Version: 1.0
X-Mercurial-Node: 4ef7e58d38791a1bbcb982e6f948ab1f0c805d5f
Message-ID: <4ef7e58d38791a1bbcb9.1327337141@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327337123@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Mon, 23 Jan 2012 16:45:41 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 18 of 20] libxl: move "saved_state" to
 libxl__domain_build_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 1327336698 0
# Node ID 4ef7e58d38791a1bbcb982e6f948ab1f0c805d5f
# Parent  3101b9483229b61afe4945949832c04abe323a59
libxl: move "saved_state" to libxl__domain_build_state.

This is internal to the library and need not be exposed to the user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

diff -r 3101b9483229 -r 4ef7e58d3879 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 16:38:18 2012 +0000
@@ -275,9 +275,8 @@ static int domain_restore(libxl__gc *gc,
     if (ret)
         goto out;
 
-    dm_info->saved_state = NULL;
     if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
-        ret = asprintf(&dm_info->saved_state,
+        ret = asprintf(&state->saved_state,
                        XC_DEVICE_MODEL_RESTORE_FILE".%d", domid);
         ret = (ret < 0) ? ERROR_FAIL : 0;
     }
@@ -509,13 +508,11 @@ static int do_domain_create(libxl__gc *g
         }
     }
 
+    memset(&state, 0, sizeof(state));
+
     if ( restore_fd >= 0 ) {
         ret = domain_restore(gc, &d_config->b_info, domid, restore_fd, &state, dm_info);
     } else {
-        if (dm_info->saved_state) {
-            free(dm_info->saved_state);
-            dm_info->saved_state = NULL;
-        }
         ret = libxl__domain_build(gc, &d_config->b_info, dm_info, domid, &state);
     }
 
@@ -565,7 +562,7 @@ static int do_domain_create(libxl__gc *g
 
         dm_info->domid = domid;
         ret = libxl__create_device_model(gc, d_config, dm_info,
-                                        &dm_starting);
+                                         &state, &dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "failed to create device model: %d", ret);
@@ -602,8 +599,8 @@ static int do_domain_create(libxl__gc *g
             /* only copy those useful configs */
             memset((void*)&xenpv_dm_info, 0, sizeof(libxl_device_model_info));
 
-            libxl__create_xenpv_qemu(gc, domid,
-                                     d_config, &xenpv_dm_info, &dm_starting);
+            libxl__create_xenpv_qemu(gc, domid, d_config,
+                                     &xenpv_dm_info, &state, &dm_starting);
         }
         break;
     }
@@ -617,7 +614,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_info, dm_starting);
+        ret = libxl__confirm_device_model_startup(gc, &state, dm_starting);
         if (ret < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
                        "device model did not start: %d", ret);
diff -r 3101b9483229 -r 4ef7e58d3879 tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Mon Jan 23 16:38:18 2012 +0000
@@ -111,7 +111,8 @@ static const char *dm_keymap(const libxl
 static char ** libxl__build_device_model_args_old(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     const libxl_domain_create_info *c_info = &guest_config->c_info;
     const libxl_domain_build_info *b_info = &guest_config->b_info;
@@ -248,8 +249,8 @@ static char ** libxl__build_device_model
             flexarray_append(dm_args, "-nographic");
     }
 
-    if (info->saved_state) {
-        flexarray_vappend(dm_args, "-loadvm", info->saved_state, NULL);
+    if (state->saved_state) {
+        flexarray_vappend(dm_args, "-loadvm", state->saved_state, NULL);
     }
     for (i = 0; b_info->extra && b_info->extra[i] != NULL; i++)
         flexarray_append(dm_args, b_info->extra[i]);
@@ -321,7 +322,8 @@ static char *dm_spice_options(libxl__gc 
 static char ** libxl__build_device_model_args_new(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     const libxl_domain_create_info *c_info = &guest_config->c_info;
@@ -489,9 +491,9 @@ static char ** libxl__build_device_model
         }
     }
 
-    if (info->saved_state) {
+    if (state->saved_state) {
         /* This file descriptor is meant to be used by QEMU */
-        int migration_fd = open(info->saved_state, O_RDONLY);
+        int migration_fd = open(state->saved_state, O_RDONLY);
         flexarray_append(dm_args, "-incoming");
         flexarray_append(dm_args, libxl__sprintf(gc, "fd:%d", migration_fd));
     }
@@ -581,15 +583,16 @@ static char ** libxl__build_device_model
 static char ** libxl__build_device_model_args(libxl__gc *gc,
                                         const char *dm,
                                         const libxl_domain_config *guest_config,
-                                        const libxl_device_model_info *info)
+                                        const libxl_device_model_info *info,
+                                        const libxl__domain_build_state *state)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
 
     switch (guest_config->b_info.device_model_version) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-        return libxl__build_device_model_args_old(gc, dm, guest_config, info);
+        return libxl__build_device_model_args_old(gc, dm, guest_config, info, state);
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        return libxl__build_device_model_args_new(gc, dm, guest_config, info);
+        return libxl__build_device_model_args_new(gc, dm, guest_config, info, state);
     default:
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "unknown device model version %d",
                          guest_config->b_info.device_model_version);
@@ -672,6 +675,7 @@ retry_transaction:
 static int libxl__create_stubdom(libxl__gc *gc,
                                  libxl_domain_config *guest_config,
                                  libxl_device_model_info *info,
+                                 libxl__domain_build_state *d_state,
                                  libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -680,7 +684,7 @@ static int libxl__create_stubdom(libxl__
     libxl_domain_config dm_config;
     libxl_device_vfb vfb;
     libxl_device_vkb vkb;
-    libxl__domain_build_state state;
+    libxl__domain_build_state stubdom_state;
     uint32_t domid;
     char **args;
     struct xs_permissions perm[2];
@@ -738,12 +742,12 @@ static int libxl__create_stubdom(libxl__
     ret = libxl__domain_make(gc, &dm_config.c_info, &domid);
     if (ret)
         goto out;
-    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &state);
+    ret = libxl__domain_build(gc, &dm_config.b_info, info, domid, &stubdom_state);
     if (ret)
         goto out;
 
     args = libxl__build_device_model_args(gc, "stubdom-dm",
-                                          guest_config, info);
+                                          guest_config, info, d_state);
     if (!args) {
         ret = ERROR_FAIL;
         goto out;
@@ -813,7 +817,8 @@ retry_transaction:
             char *filename;
             char *name;
             case STUBDOM_CONSOLE_LOGGING:
-                name = libxl__sprintf(gc, "qemu-dm-%s", libxl_domid_to_name(ctx, info->domid));
+                name = libxl__sprintf(gc, "qemu-dm-%s",
+                                      libxl_domid_to_name(ctx, info->domid));
                 libxl_create_logfile(ctx, name, &filename);
                 console[i].output = libxl__sprintf(gc, "file:%s", filename);
                 free(filename);
@@ -823,15 +828,16 @@ retry_transaction:
                                 libxl__device_model_savefile(gc, info->domid));
                 break;
             case STUBDOM_CONSOLE_RESTORE:
-                if (info->saved_state)
-                    console[i].output = libxl__sprintf(gc, "pipe:%s", info->saved_state);
+                if (d_state->saved_state)
+                    console[i].output =
+                        libxl__sprintf(gc, "pipe:%s", d_state->saved_state);
                 break;
             default:
                 console[i].output = "pty";
                 break;
         }
         ret = libxl__device_console_add(gc, domid, &console[i],
-                                    i == STUBDOM_CONSOLE_LOGGING ? &state : NULL);
+                        i == STUBDOM_CONSOLE_LOGGING ? &stubdom_state : NULL);
         if (ret)
             goto out_free;
     }
@@ -841,12 +847,12 @@ retry_transaction:
     if (libxl__create_xenpv_qemu(gc, domid,
                                  &dm_config,
                                  &xenpv_dm_info,
+                                 &stubdom_state,
                                  &dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
-    if (libxl__confirm_device_model_startup(gc, &xenpv_dm_info,
-                                            dm_starting) < 0) {
+    if (libxl__confirm_device_model_startup(gc, d_state, dm_starting) < 0) {
         ret = ERROR_FAIL;
         goto out_free;
     }
@@ -871,6 +877,7 @@ out:
 int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -888,7 +895,7 @@ int libxl__create_device_model(libxl__gc
     const char *dm;
 
     if (b_info->device_model_stubdomain) {
-        rc = libxl__create_stubdom(gc, guest_config, info, starting_r);
+        rc = libxl__create_stubdom(gc, guest_config, info, state, starting_r);
         goto out;
     }
 
@@ -903,7 +910,7 @@ int libxl__create_device_model(libxl__gc
         rc = ERROR_FAIL;
         goto out;
     }
-    args = libxl__build_device_model_args(gc, dm, guest_config, info);
+    args = libxl__build_device_model_args(gc, dm, guest_config, info, state);
     if (!args) {
         rc = ERROR_FAIL;
         goto out;
@@ -984,10 +991,9 @@ out:
 
 
 int libxl__confirm_device_model_startup(libxl__gc *gc,
-                                libxl_device_model_info *dm_info,
+                                libxl__domain_build_state *state,
                                 libxl__spawner_starting *starting)
 {
-    libxl_ctx *ctx = libxl__gc_owner(gc);
     char *path;
     int domid = starting->domid;
     int ret, ret2;
@@ -995,11 +1001,11 @@ int libxl__confirm_device_model_startup(
     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,
+    if (state->saved_state) {
+        ret2 = unlink(state->saved_state);
+        if (ret2) LIBXL__LOG_ERRNO(CTX, XTL_ERROR,
                                    "failed to remove device-model state %s\n",
-                                   dm_info->saved_state);
+                                   state->saved_state);
         /* Do not clobber spawn_confirm error code with unlink error code. */
         if (!ret) ret = ret2;
     }
@@ -1110,10 +1116,11 @@ out:
 int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                              libxl_domain_config *guest_config,
                              libxl_device_model_info *info,
+                             libxl__domain_build_state *state,
                              libxl__spawner_starting **starting_r)
 {
     libxl__build_xenpv_qemu_args(gc, domid, info);
-    libxl__create_device_model(gc, guest_config, info, starting_r);
+    libxl__create_device_model(gc, guest_config, info, state, starting_r);
     return 0;
 }
 
diff -r 3101b9483229 -r 4ef7e58d3879 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 16:38:18 2012 +0000
@@ -247,7 +247,10 @@ typedef struct {
 
     uint32_t console_port;
     unsigned long console_mfn;
+
     unsigned long vm_generationid_addr;
+
+    char *saved_state;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
@@ -495,10 +498,12 @@ _hidden const char *libxl__domain_device
 _hidden int libxl__create_device_model(libxl__gc *gc,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__create_xenpv_qemu(libxl__gc *gc, uint32_t domid,
                               libxl_domain_config *guest_config,
                               libxl_device_model_info *dm_info,
+                              libxl__domain_build_state *state,
                               libxl__spawner_starting **starting_r);
 _hidden int libxl__need_xenpv_qemu(libxl__gc *gc,
         int nr_consoles, libxl_device_console *consoles,
@@ -508,7 +513,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__domain_build_state *state,
                               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,
diff -r 3101b9483229 -r 4ef7e58d3879 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 16:38:18 2012 +0000
@@ -269,8 +269,6 @@ libxl_domain_build_info = Struct("domain
 # Device Model Information
 libxl_device_model_info = Struct("device_model_info",[
     ("domid",            libxl_domid),
-    
-    ("saved_state",      string),
     ],
 )
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN2M-0003ku-Gq; Mon, 23 Jan 2012 16:46:30 +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 1RpN2L-0003eV-7k
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327337183!12220241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12386 invoked from network); 23 Jan 2012 16:46:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10224098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:46:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 16:46:23 +0000
Date: Mon, 23 Jan 2012 16:46:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <4F1D8423.2090603@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D8423.2090603@codemonkey.ws>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Anthony Liguori wrote:
> On 01/23/2012 04:47 AM, Stefano Stabellini wrote:
> > On Fri, 20 Jan 2012, Jan Kiszka wrote:
> >> On 2012-01-20 18:20, Stefano Stabellini wrote:
> >>> Hi all,
> >>> this is the fourth version of the Xen save/restore patch series.
> >>> We have been discussing this issue for quite a while on #qemu and
> >>> qemu-devel:
> >>>
> >>>
> >>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> >>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> >>>
> >>>
> >>> A few different approaches were proposed to achieve the goal
> >>> of a working save/restore with upstream Qemu on Xen, however after
> >>> prototyping some of them I came up with yet another solution, that I
> >>> think leads to the best results with the less amount of code
> >>> duplications and ugliness.
> >>> Far from saying that this patch series is an example of elegance and
> >>> simplicity, but it is closer to acceptable anything else I have seen so
> >>> far.
> >>>
> >>> What's new is that Qemu is going to keep track of its own physmap on
> >>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
> >>> the guest's memory map at any time.
> >>> This is all handled by Xen or Xen support in Qemu internally and can be
> >>> used to solve our save/restore framebuffer problem.
> >>>
> >>> > From the Qemu common code POV, we still need to avoid saving the guest's
> >>> ram when running on Xen, and we need to avoid resetting the videoram on
> >>> restore (that is a benefit to the generic Qemu case too, because it
> >>> saves few cpu cycles).
> >>
> >> For my understanding: Refraining from the memset is required as the
> >> already restored vram would then be overwritten?
> >
> > Yep
> >
> >> Or what is the ordering
> >> of init, RAM restore, and initial device reset now?
> >
> > RAM restore (done by Xen)
> >
> > physmap rebuild (done by xen_hvm_init in qemu)
> > pc_init()
> > qemu_system_reset()
> > load_vmstate()
> 
> That's your problem.  You don't want to do load_vmstate().  You just want to 
> load the device model, not RAM.

True


> Why not introduce new Xen specific commands like I suggested on IRC?

Introducing a Xen specific command is not an issue, but I didn't want to
duplicate all the functionalities currently in savevm.c.


> You should have a separate load_device_state() function and mark anything that 
> is RAM as RAM when doing savevm registration.  Better yet, mark devices as 
> devices since that's what you really care about.

I dropped this approach because I thought it causes too much code
duplication.
However, following your suggestion, if I add a generic "device" flag in
SaveStateEntry and implement a generic qemu_save_device_state in
savevm.c, I believe that the duplication of code would be small.
And patch #1 could go away.


However the issue of patch #4, "do not reset videoram on resume", still
remains: no matter what parameter I pass to Qemu, if qemu_system_reset
is called on resume the videoram is going to be overwritten by 0xff.
In this regard, don't you think it would be advantageous to Qemu in
general not to reset the videram in resume? It can be pretty large, so
it is a significant waste of a memset.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:46:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:46:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN2M-0003ku-Gq; Mon, 23 Jan 2012 16:46:30 +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 1RpN2L-0003eV-7k
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:46:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327337183!12220241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12386 invoked from network); 23 Jan 2012 16:46:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:46:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10224098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 16:46:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 16:46:23 +0000
Date: Mon, 23 Jan 2012 16:46:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <4F1D8423.2090603@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D8423.2090603@codemonkey.ws>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Anthony Liguori wrote:
> On 01/23/2012 04:47 AM, Stefano Stabellini wrote:
> > On Fri, 20 Jan 2012, Jan Kiszka wrote:
> >> On 2012-01-20 18:20, Stefano Stabellini wrote:
> >>> Hi all,
> >>> this is the fourth version of the Xen save/restore patch series.
> >>> We have been discussing this issue for quite a while on #qemu and
> >>> qemu-devel:
> >>>
> >>>
> >>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> >>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> >>>
> >>>
> >>> A few different approaches were proposed to achieve the goal
> >>> of a working save/restore with upstream Qemu on Xen, however after
> >>> prototyping some of them I came up with yet another solution, that I
> >>> think leads to the best results with the less amount of code
> >>> duplications and ugliness.
> >>> Far from saying that this patch series is an example of elegance and
> >>> simplicity, but it is closer to acceptable anything else I have seen so
> >>> far.
> >>>
> >>> What's new is that Qemu is going to keep track of its own physmap on
> >>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
> >>> the guest's memory map at any time.
> >>> This is all handled by Xen or Xen support in Qemu internally and can be
> >>> used to solve our save/restore framebuffer problem.
> >>>
> >>> > From the Qemu common code POV, we still need to avoid saving the guest's
> >>> ram when running on Xen, and we need to avoid resetting the videoram on
> >>> restore (that is a benefit to the generic Qemu case too, because it
> >>> saves few cpu cycles).
> >>
> >> For my understanding: Refraining from the memset is required as the
> >> already restored vram would then be overwritten?
> >
> > Yep
> >
> >> Or what is the ordering
> >> of init, RAM restore, and initial device reset now?
> >
> > RAM restore (done by Xen)
> >
> > physmap rebuild (done by xen_hvm_init in qemu)
> > pc_init()
> > qemu_system_reset()
> > load_vmstate()
> 
> That's your problem.  You don't want to do load_vmstate().  You just want to 
> load the device model, not RAM.

True


> Why not introduce new Xen specific commands like I suggested on IRC?

Introducing a Xen specific command is not an issue, but I didn't want to
duplicate all the functionalities currently in savevm.c.


> You should have a separate load_device_state() function and mark anything that 
> is RAM as RAM when doing savevm registration.  Better yet, mark devices as 
> devices since that's what you really care about.

I dropped this approach because I thought it causes too much code
duplication.
However, following your suggestion, if I add a generic "device" flag in
SaveStateEntry and implement a generic qemu_save_device_state in
savevm.c, I believe that the duplication of code would be small.
And patch #1 could go away.


However the issue of patch #4, "do not reset videoram on resume", still
remains: no matter what parameter I pass to Qemu, if qemu_system_reset
is called on resume the videoram is going to be overwritten by 0xff.
In this regard, don't you think it would be advantageous to Qemu in
general not to reset the videram in resume? It can be pretty large, so
it is a significant waste of a memset.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:52:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN7c-0006ZM-U9; Mon, 23 Jan 2012 16:51:56 +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 1RpN7b-0006Yk-Nn
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:51:55 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327337508!12170586!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18120 invoked from network); 23 Jan 2012 16:51:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:51:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181960"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:51: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; Mon, 23 Jan 2012 11:51:47 -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 q0NGpioY032074;
	Mon, 23 Jan 2012 08:51:45 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F1D991A020000780006E74E@nat28.tlf.novell.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
	<4F1D7702020000780006E6C2@nat28.tlf.novell.com>
	<1327334483.26455.260.camel@elijah>
	<4F1D991A020000780006E74E@nat28.tlf.novell.com>
Date: Mon, 23 Jan 2012 16:51:43 +0000
Message-ID: <1327337503.26455.314.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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, 2012-01-23 at 16:30 +0000, Jan Beulich wrote:
> > The attached patch fixes the build (with the original patch un-reverted
> > of course), by making the internal calls explicitly take 64-bit values
> > for eip, rather than "unsigned long".  Will that suffice?
> 
> Looks correct and sufficient, but with the original patch already
> reverted folding the changes here into the original and re-submitting
> would probably the best route to go.

I really prefer to keep patches with no functional change separate from
those with a pretty major functional change; even if the major
functional change is only one line. :-)

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:52:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:52:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpN7c-0006ZM-U9; Mon, 23 Jan 2012 16:51:56 +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 1RpN7b-0006Yk-Nn
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:51:55 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327337508!12170586!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18120 invoked from network); 23 Jan 2012 16:51:49 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:51:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="21181960"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 11:51: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; Mon, 23 Jan 2012 11:51:47 -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 q0NGpioY032074;
	Mon, 23 Jan 2012 08:51:45 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F1D991A020000780006E74E@nat28.tlf.novell.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
	<4F1D7702020000780006E6C2@nat28.tlf.novell.com>
	<1327334483.26455.260.camel@elijah>
	<4F1D991A020000780006E74E@nat28.tlf.novell.com>
Date: Mon, 23 Jan 2012 16:51:43 +0000
Message-ID: <1327337503.26455.314.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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, 2012-01-23 at 16:30 +0000, Jan Beulich wrote:
> > The attached patch fixes the build (with the original patch un-reverted
> > of course), by making the internal calls explicitly take 64-bit values
> > for eip, rather than "unsigned long".  Will that suffice?
> 
> Looks correct and sufficient, but with the original patch already
> reverted folding the changes here into the original and re-submitting
> would probably the best route to go.

I really prefer to keep patches with no functional change separate from
those with a pretty major functional change; even if the major
functional change is only one line. :-)

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:54:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNA5-0006m4-H7; Mon, 23 Jan 2012 16:54:29 +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 1RpNA4-0006ld-7Q
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:54:28 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327337660!8398213!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13200 invoked from network); 23 Jan 2012 16:54:21 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:54:21 -0000
Received: by ggnk3 with SMTP id k3so38811741ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 08:54:20 -0800 (PST)
Received: by 10.50.6.194 with SMTP id d2mr10635313iga.24.1327337659832;
	Mon, 23 Jan 2012 08:54:19 -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 va6sm24531167igc.6.2012.01.23.08.54.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 08:54:18 -0800 (PST)
Message-ID: <4F1D90B7.4060202@codemonkey.ws>
Date: Mon, 23 Jan 2012 10:54:15 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D8423.2090603@codemonkey.ws>
	<alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
X-Gm-Message-State: ALoCoQlYKSMGCi8V/6fhQLsgaGgnxQDpsCtC2XpvtNjmjmGiITfVxJJYTwXriwdxsigjkQN0GcP7
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 10:46 AM, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Anthony Liguori wrote:
>> On 01/23/2012 04:47 AM, Stefano Stabellini wrote:
>>> On Fri, 20 Jan 2012, Jan Kiszka wrote:
>>>> On 2012-01-20 18:20, Stefano Stabellini wrote:
>>>>> Hi all,
>>>>> this is the fourth version of the Xen save/restore patch series.
>>>>> We have been discussing this issue for quite a while on #qemu and
>>>>> qemu-devel:
>>>>>
>>>>>
>>>>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
>>>>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
>>>>>
>>>>>
>>>>> A few different approaches were proposed to achieve the goal
>>>>> of a working save/restore with upstream Qemu on Xen, however after
>>>>> prototyping some of them I came up with yet another solution, that I
>>>>> think leads to the best results with the less amount of code
>>>>> duplications and ugliness.
>>>>> Far from saying that this patch series is an example of elegance and
>>>>> simplicity, but it is closer to acceptable anything else I have seen so
>>>>> far.
>>>>>
>>>>> What's new is that Qemu is going to keep track of its own physmap on
>>>>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
>>>>> the guest's memory map at any time.
>>>>> This is all handled by Xen or Xen support in Qemu internally and can be
>>>>> used to solve our save/restore framebuffer problem.
>>>>>
>>>>>>  From the Qemu common code POV, we still need to avoid saving the guest's
>>>>> ram when running on Xen, and we need to avoid resetting the videoram on
>>>>> restore (that is a benefit to the generic Qemu case too, because it
>>>>> saves few cpu cycles).
>>>>
>>>> For my understanding: Refraining from the memset is required as the
>>>> already restored vram would then be overwritten?
>>>
>>> Yep
>>>
>>>> Or what is the ordering
>>>> of init, RAM restore, and initial device reset now?
>>>
>>> RAM restore (done by Xen)
>>>
>>> physmap rebuild (done by xen_hvm_init in qemu)
>>> pc_init()
>>> qemu_system_reset()
>>> load_vmstate()
>>
>> That's your problem.  You don't want to do load_vmstate().  You just want to
>> load the device model, not RAM.
>
> True
>
>
>> Why not introduce new Xen specific commands like I suggested on IRC?
>
> Introducing a Xen specific command is not an issue, but I didn't want to
> duplicate all the functionalities currently in savevm.c.

The code is fairly reusable since live migration and savevm use the same 
internal bits.  I think you would just need another version of 
qemu_loadvm_state().  That function is only a hundred lines or so so you 
shouldn't be duplicating much at all.

>> You should have a separate load_device_state() function and mark anything that
>> is RAM as RAM when doing savevm registration.  Better yet, mark devices as
>> devices since that's what you really care about.
>
> I dropped this approach because I thought it causes too much code
> duplication.

Then you're doing it wrong :-)

But even if there is, just refactor out the common code.

> However, following your suggestion, if I add a generic "device" flag in
> SaveStateEntry and implement a generic qemu_save_device_state in
> savevm.c, I believe that the duplication of code would be small.
> And patch #1 could go away.

Yup.

>
>
> However the issue of patch #4, "do not reset videoram on resume", still
> remains: no matter what parameter I pass to Qemu, if qemu_system_reset
> is called on resume the videoram is going to be overwritten by 0xff.

The memset(0xff) looks dubious to me.  My guess is that this could be moved to 
the vgabios-cirrus which would solve your problem.

> In this regard, don't you think it would be advantageous to Qemu in
> general not to reset the videram in resume? It can be pretty large, so
> it is a significant waste of a memset.

It claims to fix a real bug.  Moving the memset to vgabios would do what you 
want to do in a more robust way I think.

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 Jan 23 16:54:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:54:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNA5-0006m4-H7; Mon, 23 Jan 2012 16:54:29 +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 1RpNA4-0006ld-7Q
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:54:28 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327337660!8398213!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=1.7 required=7.0 tests=INFO_TLD,RCVD_BY_IP
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13200 invoked from network); 23 Jan 2012 16:54:21 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 16:54:21 -0000
Received: by ggnk3 with SMTP id k3so38811741ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 08:54:20 -0800 (PST)
Received: by 10.50.6.194 with SMTP id d2mr10635313iga.24.1327337659832;
	Mon, 23 Jan 2012 08:54:19 -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 va6sm24531167igc.6.2012.01.23.08.54.17
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 08:54:18 -0800 (PST)
Message-ID: <4F1D90B7.4060202@codemonkey.ws>
Date: Mon, 23 Jan 2012 10:54:15 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D8423.2090603@codemonkey.ws>
	<alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
X-Gm-Message-State: ALoCoQlYKSMGCi8V/6fhQLsgaGgnxQDpsCtC2XpvtNjmjmGiITfVxJJYTwXriwdxsigjkQN0GcP7
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 10:46 AM, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Anthony Liguori wrote:
>> On 01/23/2012 04:47 AM, Stefano Stabellini wrote:
>>> On Fri, 20 Jan 2012, Jan Kiszka wrote:
>>>> On 2012-01-20 18:20, Stefano Stabellini wrote:
>>>>> Hi all,
>>>>> this is the fourth version of the Xen save/restore patch series.
>>>>> We have been discussing this issue for quite a while on #qemu and
>>>>> qemu-devel:
>>>>>
>>>>>
>>>>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
>>>>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
>>>>>
>>>>>
>>>>> A few different approaches were proposed to achieve the goal
>>>>> of a working save/restore with upstream Qemu on Xen, however after
>>>>> prototyping some of them I came up with yet another solution, that I
>>>>> think leads to the best results with the less amount of code
>>>>> duplications and ugliness.
>>>>> Far from saying that this patch series is an example of elegance and
>>>>> simplicity, but it is closer to acceptable anything else I have seen so
>>>>> far.
>>>>>
>>>>> What's new is that Qemu is going to keep track of its own physmap on
>>>>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
>>>>> the guest's memory map at any time.
>>>>> This is all handled by Xen or Xen support in Qemu internally and can be
>>>>> used to solve our save/restore framebuffer problem.
>>>>>
>>>>>>  From the Qemu common code POV, we still need to avoid saving the guest's
>>>>> ram when running on Xen, and we need to avoid resetting the videoram on
>>>>> restore (that is a benefit to the generic Qemu case too, because it
>>>>> saves few cpu cycles).
>>>>
>>>> For my understanding: Refraining from the memset is required as the
>>>> already restored vram would then be overwritten?
>>>
>>> Yep
>>>
>>>> Or what is the ordering
>>>> of init, RAM restore, and initial device reset now?
>>>
>>> RAM restore (done by Xen)
>>>
>>> physmap rebuild (done by xen_hvm_init in qemu)
>>> pc_init()
>>> qemu_system_reset()
>>> load_vmstate()
>>
>> That's your problem.  You don't want to do load_vmstate().  You just want to
>> load the device model, not RAM.
>
> True
>
>
>> Why not introduce new Xen specific commands like I suggested on IRC?
>
> Introducing a Xen specific command is not an issue, but I didn't want to
> duplicate all the functionalities currently in savevm.c.

The code is fairly reusable since live migration and savevm use the same 
internal bits.  I think you would just need another version of 
qemu_loadvm_state().  That function is only a hundred lines or so so you 
shouldn't be duplicating much at all.

>> You should have a separate load_device_state() function and mark anything that
>> is RAM as RAM when doing savevm registration.  Better yet, mark devices as
>> devices since that's what you really care about.
>
> I dropped this approach because I thought it causes too much code
> duplication.

Then you're doing it wrong :-)

But even if there is, just refactor out the common code.

> However, following your suggestion, if I add a generic "device" flag in
> SaveStateEntry and implement a generic qemu_save_device_state in
> savevm.c, I believe that the duplication of code would be small.
> And patch #1 could go away.

Yup.

>
>
> However the issue of patch #4, "do not reset videoram on resume", still
> remains: no matter what parameter I pass to Qemu, if qemu_system_reset
> is called on resume the videoram is going to be overwritten by 0xff.

The memset(0xff) looks dubious to me.  My guess is that this could be moved to 
the vgabios-cirrus which would solve your problem.

> In this regard, don't you think it would be advantageous to Qemu in
> general not to reset the videram in resume? It can be pretty large, so
> it is a significant waste of a memset.

It claims to fix a real bug.  Moving the memset to vgabios would do what you 
want to do in a more robust way I think.

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 Jan 23 16:57:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNCX-0006wK-31; Mon, 23 Jan 2012 16:57:01 +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 1RpNCU-0006wB-PM
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:56:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327337810!2259275!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16564 invoked from network); 23 Jan 2012 16:56:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 16:56: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
	q0NGtjJL026114
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 16:55:46 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
	q0NGthm6017212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 16:55:44 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
	q0NGtf6G006595; Mon, 23 Jan 2012 10:55:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 08:55:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B64F540104; Mon, 23 Jan 2012 11:53:25 -0500 (EST)
Date: Mon, 23 Jan 2012 11:53:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120123165325.GB5599@phenom.dumpdata.com>
References: <20111220153145.GB13253@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
	<20111223030103.GA7218@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
	<20120113222451.GA6922@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
	<20120117171314.GB5494@phenom.dumpdata.com>
	<20120117181922.GA12900@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
In-Reply-To: <20120117181922.GA12900@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F1D9114.0047,ss=1,re=-2.300,fgs=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@kernel.org" <konrad@kernel.org>, "Nakajima,
	Jun" <jun.nakajima@intel.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 <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jan 17, 2012 at 01:19:22PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2012 at 12:13:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > I was trying to figure out how difficult it would be to just bring Pxx states to
> > > > the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
> > > > all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
> > > > be enabled in the hypercall to make this work), it demonstrates what I had in
> > > > mind. 
> > 
> > .. snip..
> > > > 	/* TODO: Under Xen, the C-states information is not present.
> > > >  	 * Figure out why. */
> > > 
> > > it's possible related to this long thread:
> > > 
> > > http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html
> > > 
> > > IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
> > > Final solution is to have a para-virtualized PDC call for that.
> > 
> > Aaah. Let me play with that a bit. Thanks for the pointer.

Found out the reason. It was that the hypervisor did not expose the MWAIT
bit and that dom0 was setting boot_option_idle...

The #1 patch has the fix for that.

.. snip.
> > > which in current form may add some negative impact, e.g. dom0 will try to control
> > > Px/Cx to conflict with Xen. So some tweaks may be required in that part.
> > 
> > Yup. Hadn't even looked at the cpufreq tries to do yet.
> > > 
> > > given our purpose now, is to come up a cleaner approach which tolerate some
> > > assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
> > > trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
> > > xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
> > > mainly two roles:
> > > 	- a dummy driver to prevent dom0 touching actual Px/Cx

This is still TODO - I hadn't really looked to see what dom0 does and
if the hypervisor ignores the dom0 (I sure it does so!). 

But interestigly enough, the cpuidle driver is not doing anything
b/c the cpuidle_disable() call which inhibits it from running.
So we might not a dummy driver for cpuidle. Not so sure about cpufreq.

> > > 	- parse ACPI Cx/Px information to Xen, in a similar way you did above

The attached #2 patch does that - and it works at least on Intel machines.
I hadn't done any extensive testing, like doing 'xl vcpu-set 0 X' as that
seems to crash on 3.3 - irregardless of these patches :-)

But 'xenpm' and running some guests seems to work just fine so I am
hopefull.

There are still some TODOs with this:
 - which is how to make the module be autoloaded after the processor.ko
   (or rather acpi_cpufreq_cpu_init) has been loaded. As right now you
   have to manually load the driver.
 - make it work under AMD. I think that requires trapping the MSR call.
 - check the cpufreq notification calls.
 - double check that cpuidle is indeed not called.
 - play with dom0_max_vcpus= or 'xl vcpu-set 0 1'


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-xen-setup-pm-acpi-Remove-the-call-to-boot_option_idl.patch"

>From da1c22723b17b4250a81126afa97b5710cede030 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 10:53:57 -0500
Subject: [PATCH 1/2] xen/setup/pm/acpi: Remove the call to
 boot_option_idle_override.

We needed that call in the past to force the kernel to use
default_idle (which called safe_halt, which called xen_safe_halt).

But set_pm_idle_to_default() does now that, so there is no need
to use this boot option operand.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e03c636..1236623 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -420,7 +420,6 @@ void __init xen_arch_setup(void)
 	boot_cpu_data.hlt_works_ok = 1;
 #endif
 	disable_cpuidle();
-	boot_option_idle_override = IDLE_HALT;
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
 }
-- 
1.7.7.5


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-xen-acpi-Provide-a-ACPI-driver-that-sends-processor-.patch"

>From b3dfedc6a77c324a4fb5a7171903a5d91056282d Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 11:05:02 -0500
Subject: [PATCH 2/2] xen/acpi: Provide a ACPI driver that sends "processor"
 data to the hypervisor.

The ACPI processor processes the _Pxx and the _Cx state information
which are populated in the 'processor' per-cpu structure. We read
the contents of that structure and pipe it up the Xen hypervisor.

We assume that the ACPI processor is smart and did all the filtering
work so that the contents is correct. After we are done parsing
the information, we unload ourselves and let the hypervisor deal
with cpufreq, cpuidle states and such.

Note: This only works right now under Intel CPUs, b/c the Xen hypervisor
does not properly process the AMD MSR_PSTATE_CUR_LIMIT and the hypervisor
should pass in the MWAIT CPU attribute:

http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00511.html

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Kconfig         |    5 +
 drivers/xen/Makefile        |    2 +-
 drivers/xen/acpi_xen_sink.c |  265 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 271 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/acpi_xen_sink.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a1ced52..747ef17 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -178,4 +178,9 @@ config XEN_PRIVCMD
 	depends on XEN
 	default m
 
+config XEN_ACPI_SINK
+	tristate
+	depends on XEN && ACPI_PROCESSOR && CPU_FREQ
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..1585b35 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-
+obj-$(CONFIG_XEN_ACPI_SINK)		+= acpi_xen_sink.o
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
diff --git a/drivers/xen/acpi_xen_sink.c b/drivers/xen/acpi_xen_sink.c
new file mode 100644
index 0000000..78771ca
--- /dev/null
+++ b/drivers/xen/acpi_xen_sink.c
@@ -0,0 +1,265 @@
+
+#define DEBUG 1
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+#include <linux/cpumask.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define DRV_NAME	"ACPI_Xen_Sink"
+MODULE_AUTHOR("Konrad Rzeszutek Wilk");
+MODULE_DESCRIPTION("ACPI Power Management driver to send data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+static int __init push_cxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_CX,
+	};
+	struct xen_processor_cx *xen_cx, *xen_cx_states = NULL;
+	struct acpi_processor_cx *cx;
+	int i, ok, ret = 0;
+
+	if (!_pr->flags.power_setup_done)
+		return -ENODEV;
+
+	xen_cx_states = kcalloc(_pr->power.count,
+				sizeof(struct xen_processor_cx), GFP_KERNEL);
+	if (!xen_cx_states)
+		return -ENOMEM;
+
+	for (ok = 0, i = 1; i <= _pr->power.count; i++) {
+		cx = &_pr->power.states[i];
+		if (!cx->valid)
+			continue;
+
+		xen_cx = &(xen_cx_states[ok++]);
+
+		xen_cx->reg.space_id = ACPI_ADR_SPACE_SYSTEM_IO;
+		if (cx->entry_method == ACPI_CSTATE_SYSTEMIO) {
+			/* TODO: double check whether anybody cares about it */
+			xen_cx->reg.bit_width = 8;
+			xen_cx->reg.bit_offset = 0;
+		} else {
+			xen_cx->reg.space_id = ACPI_ADR_SPACE_FIXED_HARDWARE;
+			if (cx->entry_method == ACPI_CSTATE_FFH) {
+				/* NATIVE_CSTATE_BEYOND_HALT */
+				xen_cx->reg.bit_offset = 2;
+				xen_cx->reg.bit_width = 1; /* VENDOR_INTEL */
+			}
+		}
+		xen_cx->reg.access_size = 0;
+		xen_cx->reg.address = cx->address;
+
+		xen_cx->type = cx->type;
+		xen_cx->latency = cx->latency;
+		xen_cx->power = cx->power;
+
+		xen_cx->dpcnt = 0;
+		set_xen_guest_handle(xen_cx->dp, NULL);
+
+		pr_debug("\t_CX: ID:%d [C%d:%s]\n", _pr->acpi_id, i, cx->desc);
+	}
+	if (!ok) {
+		pr_err("No available Cx info for cpu %d\n", _pr->acpi_id);
+		kfree(xen_cx_states);
+		return -EINVAL;
+	}
+	op.u.set_pminfo.power.count = ok;
+	op.u.set_pminfo.power.flags.bm_control = _pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check = _pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst = _pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =
+		_pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, xen_cx_states);
+
+	if (xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	kfree(xen_cx_states);
+
+	return ret;
+}
+
+
+
+static struct xen_processor_px *
+__init xen_copy_pss_data(struct acpi_processor *_pr,
+			 struct xen_processor_performance *xen_perf)
+{
+	struct xen_processor_px *xen_states = NULL;
+	int i;
+
+	xen_states = kcalloc(_pr->performance->state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+	if (!xen_states)
+		return ERR_PTR(-ENOMEM);
+
+	xen_perf->state_count = _pr->performance->state_count;
+
+	BUILD_BUG_ON(sizeof(struct xen_processor_px) !=
+		     sizeof(struct acpi_processor_px));
+	for (i = 0; i < _pr->performance->state_count; i++) {
+
+		/* Fortunatly for us, they both have the same size */
+		memcpy(&(xen_states[i]), &(_pr->performance->states[i]),
+		       sizeof(struct acpi_processor_px));
+#ifdef DEBUG
+		{
+			struct xen_processor_px *_px;
+			_px = &(xen_states[i]);
+			pr_debug("\t_PSS: [%2d]: %d, %d, %d, %d, %d, %d\n", i,
+				(u32)_px->core_frequency, (u32)_px->power,
+				(u32)_px->transition_latency,
+				(u32)_px->bus_master_latency, (u32)_px->control,
+				(u32)_px->status);
+		}
+#endif
+	}
+	return xen_states;
+}
+static int __init xen_copy_psd_data(struct acpi_processor *_pr,
+				    struct xen_processor_performance *xen_perf)
+{
+	xen_perf->shared_type = _pr->performance->shared_type;
+
+	BUILD_BUG_ON(sizeof(struct xen_psd_package) !=
+		     sizeof(struct acpi_psd_package));
+	memcpy(&(xen_perf->domain_info), &(_pr->performance->domain_info),
+	       sizeof(struct acpi_psd_package));
+
+#if DEBUG
+	{
+		struct xen_psd_package *_psd;
+		_psd = &(xen_perf->domain_info);
+		pr_debug("\t_PSD: num_entries:%d rev=%d domain=%d coord_type=%d, "
+			 "num_processers=%d\n", (u32)_psd->num_entries,
+			 (u32)_psd->revision, (u32)_psd->domain,
+			 (u32)_psd->coord_type, (u32)_psd->num_processors);
+	}
+#endif
+	return 0;
+}
+static int __init xen_copy_pct_data(struct acpi_pct_register *pct,
+				    struct xen_pct_register *_pct)
+{
+	/* It would be nice if you could just do 'memcpy(pct, _pct') but
+	 * sadly the Xen structure did not have the proper padding
+	 * so the descriptor field takes two (_pct) bytes instead of one (pct).
+	 */
+	_pct->descriptor = pct->descriptor;
+	_pct->length = pct->length;
+	_pct->space_id = pct->space_id;
+	_pct->bit_width = pct->bit_width;
+	_pct->bit_offset = pct->bit_offset;
+	_pct->reserved = pct->reserved;
+	_pct->address = pct->address;
+#ifdef DEBUG
+	pr_debug("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
+		 "bit_width=%d, bit_offset=%d), reserved=%d, address=0x%x\n",
+		 _pct->descriptor, _pct->length, _pct->space_id,
+		 _pct->bit_width, _pct->bit_offset, _pct->reserved,
+		 (u32)_pct->address);
+#endif
+	return 0;
+}
+static int __init push_pxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	int ret = -EINVAL;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+	struct xen_processor_performance *xen_perf;
+	struct xen_processor_px *xen_states = NULL;
+
+	if (!_pr->performance)
+		return -ENODEV;
+
+	xen_perf = &op.u.set_pminfo.perf;
+
+	/* PPC */
+	xen_perf->platform_limit = _pr->performance_platform_limit;
+	xen_perf->flags |= XEN_PX_PPC;
+	/* PCT */
+	xen_copy_pct_data(&(_pr->performance->control_register),
+			  &xen_perf->control_register);
+	xen_copy_pct_data(&(_pr->performance->status_register),
+			  &xen_perf->status_register);
+	xen_perf->flags |= XEN_PX_PCT;
+	/* PSS */
+	xen_states = xen_copy_pss_data(_pr, xen_perf);
+	if (!IS_ERR_OR_NULL(xen_states)) {
+		set_xen_guest_handle(xen_perf->states, xen_states);
+		xen_perf->flags |= XEN_PX_PSS;
+	}
+	/* PSD */
+	if (!xen_copy_psd_data(_pr, xen_perf))
+		xen_perf->flags |= XEN_PX_PSD;
+
+	if (xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	if (!IS_ERR_OR_NULL(xen_states))
+		kfree(xen_states);
+	return ret;
+}
+
+static int __init acpi_xen_sink_init(void)
+{
+	int cpu;
+	int err = -ENODEV;
+	struct acpi_processor *_pr;
+	struct cpuinfo_x86 *c = &cpu_data(0);
+
+	/* TODO: Under AMD, the information is populated
+	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
+	 * MSR which returns the wrong value (under Xen) so the population
+	 * of 'processors' has bogus data. So only run this under
+	 * Intel for right now. */
+	if (!cpu_has(c, X86_FEATURE_EST)) {
+		pr_err("AMD platform is not supported (yet)\n");
+		return -ENODEV;
+	}
+	/*
+	 * It is imperative that we get called _after_ acpi_processor has
+	 * loaded. Otherwise the _pr might be bogus.
+	*/
+	if (request_module("processor")) {
+		pr_err("Unable to load ACPI processor module!\n");
+		return -ENODEV;
+	}
+	for_each_possible_cpu(cpu) {
+		_pr = per_cpu(processors, cpu);
+		if (!_pr)
+			continue;
+
+		if (_pr->flags.power)
+			err = push_cxx_to_hypervisor(_pr);
+
+		if (_pr->performance->states)
+			err |= push_pxx_to_hypervisor(_pr);
+		if (err)
+			break;
+	}
+	return -ENODEV; /* force it to unload */
+}
+static void __exit acpi_xen_sink_exit(void)
+{
+}
+module_init(acpi_xen_sink_init);
+module_exit(acpi_xen_sink_exit);
-- 
1.7.7.5


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--cWoXeonUoKmBZSoM--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 16:57:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 16:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNCX-0006wK-31; Mon, 23 Jan 2012 16:57:01 +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 1RpNCU-0006wB-PM
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 16:56:59 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327337810!2259275!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16564 invoked from network); 23 Jan 2012 16:56:51 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 16:56: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
	q0NGtjJL026114
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 16:55:46 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
	q0NGthm6017212
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 16:55:44 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
	q0NGtf6G006595; Mon, 23 Jan 2012 10:55:41 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 08:55:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B64F540104; Mon, 23 Jan 2012 11:53:25 -0500 (EST)
Date: Mon, 23 Jan 2012 11:53:25 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Message-ID: <20120123165325.GB5599@phenom.dumpdata.com>
References: <20111220153145.GB13253@andromeda.dapyr.net>
	<625BA99ED14B2D499DC4E29D8138F1506E01AAC469@shsmsx502.ccr.corp.intel.com>
	<20111223030103.GA7218@andromeda.dapyr.net>
	<AADFC41AFE54684AB9EE6CBC0274A5D10145B9@SHSMSX102.ccr.corp.intel.com>
	<20120103205925.GI17472@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D102D62B@SHSMSX102.ccr.corp.intel.com>
	<20120113222451.GA6922@phenom.dumpdata.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D10FCD37A9@SHSMSX102.ccr.corp.intel.com>
	<20120117171314.GB5494@phenom.dumpdata.com>
	<20120117181922.GA12900@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline
In-Reply-To: <20120117181922.GA12900@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090206.4F1D9114.0047,ss=1,re=-2.300,fgs=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@kernel.org" <konrad@kernel.org>, "Nakajima,
	Jun" <jun.nakajima@intel.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 <liang.tang@oracle.com>, "Yu, Ke" <ke.yu@intel.com>,
	Konrad Rzeszutek Wilk <konrad@darnok.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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Jan 17, 2012 at 01:19:22PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2012 at 12:13:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > I was trying to figure out how difficult it would be to just bring Pxx states to
> > > > the Xen hypervisor using the existing ACPI interfaces. And while it did not pass
> > > > all the _Pxx states (seems that all the _PCT, _PSS, _PSD, _PPC flags need to
> > > > be enabled in the hypercall to make this work), it demonstrates what I had in
> > > > mind. 
> > 
> > .. snip..
> > > > 	/* TODO: Under Xen, the C-states information is not present.
> > > >  	 * Figure out why. */
> > > 
> > > it's possible related to this long thread:
> > > 
> > > http://lists.xen.org/archives/html/xen-devel/2011-08/msg00511.html
> > > 
> > > IOW, Xen doesn't export mwait capability to dom0, which impacts _PDC setting.
> > > Final solution is to have a para-virtualized PDC call for that.
> > 
> > Aaah. Let me play with that a bit. Thanks for the pointer.

Found out the reason. It was that the hypervisor did not expose the MWAIT
bit and that dom0 was setting boot_option_idle...

The #1 patch has the fix for that.

.. snip.
> > > which in current form may add some negative impact, e.g. dom0 will try to control
> > > Px/Cx to conflict with Xen. So some tweaks may be required in that part.
> > 
> > Yup. Hadn't even looked at the cpufreq tries to do yet.
> > > 
> > > given our purpose now, is to come up a cleaner approach which tolerate some
> > > assumptions (e.g. #VCPU of dom0 == #PCPU), there's another option following this
> > > trend (perhaps compensate your idea). We can register a Xen-cpuidle and 
> > > xen-cpufreq driver to current Linux cpuidle and cpufreq framework, which plays 
> > > mainly two roles:
> > > 	- a dummy driver to prevent dom0 touching actual Px/Cx

This is still TODO - I hadn't really looked to see what dom0 does and
if the hypervisor ignores the dom0 (I sure it does so!). 

But interestigly enough, the cpuidle driver is not doing anything
b/c the cpuidle_disable() call which inhibits it from running.
So we might not a dummy driver for cpuidle. Not so sure about cpufreq.

> > > 	- parse ACPI Cx/Px information to Xen, in a similar way you did above

The attached #2 patch does that - and it works at least on Intel machines.
I hadn't done any extensive testing, like doing 'xl vcpu-set 0 X' as that
seems to crash on 3.3 - irregardless of these patches :-)

But 'xenpm' and running some guests seems to work just fine so I am
hopefull.

There are still some TODOs with this:
 - which is how to make the module be autoloaded after the processor.ko
   (or rather acpi_cpufreq_cpu_init) has been loaded. As right now you
   have to manually load the driver.
 - make it work under AMD. I think that requires trapping the MSR call.
 - check the cpufreq notification calls.
 - double check that cpuidle is indeed not called.
 - play with dom0_max_vcpus= or 'xl vcpu-set 0 1'


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0001-xen-setup-pm-acpi-Remove-the-call-to-boot_option_idl.patch"

>From da1c22723b17b4250a81126afa97b5710cede030 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 10:53:57 -0500
Subject: [PATCH 1/2] xen/setup/pm/acpi: Remove the call to
 boot_option_idle_override.

We needed that call in the past to force the kernel to use
default_idle (which called safe_halt, which called xen_safe_halt).

But set_pm_idle_to_default() does now that, so there is no need
to use this boot option operand.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/xen/setup.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index e03c636..1236623 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -420,7 +420,6 @@ void __init xen_arch_setup(void)
 	boot_cpu_data.hlt_works_ok = 1;
 #endif
 	disable_cpuidle();
-	boot_option_idle_override = IDLE_HALT;
 	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
 }
-- 
1.7.7.5


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="0002-xen-acpi-Provide-a-ACPI-driver-that-sends-processor-.patch"

>From b3dfedc6a77c324a4fb5a7171903a5d91056282d Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 11:05:02 -0500
Subject: [PATCH 2/2] xen/acpi: Provide a ACPI driver that sends "processor"
 data to the hypervisor.

The ACPI processor processes the _Pxx and the _Cx state information
which are populated in the 'processor' per-cpu structure. We read
the contents of that structure and pipe it up the Xen hypervisor.

We assume that the ACPI processor is smart and did all the filtering
work so that the contents is correct. After we are done parsing
the information, we unload ourselves and let the hypervisor deal
with cpufreq, cpuidle states and such.

Note: This only works right now under Intel CPUs, b/c the Xen hypervisor
does not properly process the AMD MSR_PSTATE_CUR_LIMIT and the hypervisor
should pass in the MWAIT CPU attribute:

http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00511.html

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Kconfig         |    5 +
 drivers/xen/Makefile        |    2 +-
 drivers/xen/acpi_xen_sink.c |  265 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 271 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/acpi_xen_sink.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a1ced52..747ef17 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -178,4 +178,9 @@ config XEN_PRIVCMD
 	depends on XEN
 	default m
 
+config XEN_ACPI_SINK
+	tristate
+	depends on XEN && ACPI_PROCESSOR && CPU_FREQ
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..1585b35 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-
+obj-$(CONFIG_XEN_ACPI_SINK)		+= acpi_xen_sink.o
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
diff --git a/drivers/xen/acpi_xen_sink.c b/drivers/xen/acpi_xen_sink.c
new file mode 100644
index 0000000..78771ca
--- /dev/null
+++ b/drivers/xen/acpi_xen_sink.c
@@ -0,0 +1,265 @@
+
+#define DEBUG 1
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+#include <linux/cpumask.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define DRV_NAME	"ACPI_Xen_Sink"
+MODULE_AUTHOR("Konrad Rzeszutek Wilk");
+MODULE_DESCRIPTION("ACPI Power Management driver to send data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+static int __init push_cxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_CX,
+	};
+	struct xen_processor_cx *xen_cx, *xen_cx_states = NULL;
+	struct acpi_processor_cx *cx;
+	int i, ok, ret = 0;
+
+	if (!_pr->flags.power_setup_done)
+		return -ENODEV;
+
+	xen_cx_states = kcalloc(_pr->power.count,
+				sizeof(struct xen_processor_cx), GFP_KERNEL);
+	if (!xen_cx_states)
+		return -ENOMEM;
+
+	for (ok = 0, i = 1; i <= _pr->power.count; i++) {
+		cx = &_pr->power.states[i];
+		if (!cx->valid)
+			continue;
+
+		xen_cx = &(xen_cx_states[ok++]);
+
+		xen_cx->reg.space_id = ACPI_ADR_SPACE_SYSTEM_IO;
+		if (cx->entry_method == ACPI_CSTATE_SYSTEMIO) {
+			/* TODO: double check whether anybody cares about it */
+			xen_cx->reg.bit_width = 8;
+			xen_cx->reg.bit_offset = 0;
+		} else {
+			xen_cx->reg.space_id = ACPI_ADR_SPACE_FIXED_HARDWARE;
+			if (cx->entry_method == ACPI_CSTATE_FFH) {
+				/* NATIVE_CSTATE_BEYOND_HALT */
+				xen_cx->reg.bit_offset = 2;
+				xen_cx->reg.bit_width = 1; /* VENDOR_INTEL */
+			}
+		}
+		xen_cx->reg.access_size = 0;
+		xen_cx->reg.address = cx->address;
+
+		xen_cx->type = cx->type;
+		xen_cx->latency = cx->latency;
+		xen_cx->power = cx->power;
+
+		xen_cx->dpcnt = 0;
+		set_xen_guest_handle(xen_cx->dp, NULL);
+
+		pr_debug("\t_CX: ID:%d [C%d:%s]\n", _pr->acpi_id, i, cx->desc);
+	}
+	if (!ok) {
+		pr_err("No available Cx info for cpu %d\n", _pr->acpi_id);
+		kfree(xen_cx_states);
+		return -EINVAL;
+	}
+	op.u.set_pminfo.power.count = ok;
+	op.u.set_pminfo.power.flags.bm_control = _pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check = _pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst = _pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =
+		_pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, xen_cx_states);
+
+	if (xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	kfree(xen_cx_states);
+
+	return ret;
+}
+
+
+
+static struct xen_processor_px *
+__init xen_copy_pss_data(struct acpi_processor *_pr,
+			 struct xen_processor_performance *xen_perf)
+{
+	struct xen_processor_px *xen_states = NULL;
+	int i;
+
+	xen_states = kcalloc(_pr->performance->state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+	if (!xen_states)
+		return ERR_PTR(-ENOMEM);
+
+	xen_perf->state_count = _pr->performance->state_count;
+
+	BUILD_BUG_ON(sizeof(struct xen_processor_px) !=
+		     sizeof(struct acpi_processor_px));
+	for (i = 0; i < _pr->performance->state_count; i++) {
+
+		/* Fortunatly for us, they both have the same size */
+		memcpy(&(xen_states[i]), &(_pr->performance->states[i]),
+		       sizeof(struct acpi_processor_px));
+#ifdef DEBUG
+		{
+			struct xen_processor_px *_px;
+			_px = &(xen_states[i]);
+			pr_debug("\t_PSS: [%2d]: %d, %d, %d, %d, %d, %d\n", i,
+				(u32)_px->core_frequency, (u32)_px->power,
+				(u32)_px->transition_latency,
+				(u32)_px->bus_master_latency, (u32)_px->control,
+				(u32)_px->status);
+		}
+#endif
+	}
+	return xen_states;
+}
+static int __init xen_copy_psd_data(struct acpi_processor *_pr,
+				    struct xen_processor_performance *xen_perf)
+{
+	xen_perf->shared_type = _pr->performance->shared_type;
+
+	BUILD_BUG_ON(sizeof(struct xen_psd_package) !=
+		     sizeof(struct acpi_psd_package));
+	memcpy(&(xen_perf->domain_info), &(_pr->performance->domain_info),
+	       sizeof(struct acpi_psd_package));
+
+#if DEBUG
+	{
+		struct xen_psd_package *_psd;
+		_psd = &(xen_perf->domain_info);
+		pr_debug("\t_PSD: num_entries:%d rev=%d domain=%d coord_type=%d, "
+			 "num_processers=%d\n", (u32)_psd->num_entries,
+			 (u32)_psd->revision, (u32)_psd->domain,
+			 (u32)_psd->coord_type, (u32)_psd->num_processors);
+	}
+#endif
+	return 0;
+}
+static int __init xen_copy_pct_data(struct acpi_pct_register *pct,
+				    struct xen_pct_register *_pct)
+{
+	/* It would be nice if you could just do 'memcpy(pct, _pct') but
+	 * sadly the Xen structure did not have the proper padding
+	 * so the descriptor field takes two (_pct) bytes instead of one (pct).
+	 */
+	_pct->descriptor = pct->descriptor;
+	_pct->length = pct->length;
+	_pct->space_id = pct->space_id;
+	_pct->bit_width = pct->bit_width;
+	_pct->bit_offset = pct->bit_offset;
+	_pct->reserved = pct->reserved;
+	_pct->address = pct->address;
+#ifdef DEBUG
+	pr_debug("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
+		 "bit_width=%d, bit_offset=%d), reserved=%d, address=0x%x\n",
+		 _pct->descriptor, _pct->length, _pct->space_id,
+		 _pct->bit_width, _pct->bit_offset, _pct->reserved,
+		 (u32)_pct->address);
+#endif
+	return 0;
+}
+static int __init push_pxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	int ret = -EINVAL;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+	struct xen_processor_performance *xen_perf;
+	struct xen_processor_px *xen_states = NULL;
+
+	if (!_pr->performance)
+		return -ENODEV;
+
+	xen_perf = &op.u.set_pminfo.perf;
+
+	/* PPC */
+	xen_perf->platform_limit = _pr->performance_platform_limit;
+	xen_perf->flags |= XEN_PX_PPC;
+	/* PCT */
+	xen_copy_pct_data(&(_pr->performance->control_register),
+			  &xen_perf->control_register);
+	xen_copy_pct_data(&(_pr->performance->status_register),
+			  &xen_perf->status_register);
+	xen_perf->flags |= XEN_PX_PCT;
+	/* PSS */
+	xen_states = xen_copy_pss_data(_pr, xen_perf);
+	if (!IS_ERR_OR_NULL(xen_states)) {
+		set_xen_guest_handle(xen_perf->states, xen_states);
+		xen_perf->flags |= XEN_PX_PSS;
+	}
+	/* PSD */
+	if (!xen_copy_psd_data(_pr, xen_perf))
+		xen_perf->flags |= XEN_PX_PSD;
+
+	if (xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	if (!IS_ERR_OR_NULL(xen_states))
+		kfree(xen_states);
+	return ret;
+}
+
+static int __init acpi_xen_sink_init(void)
+{
+	int cpu;
+	int err = -ENODEV;
+	struct acpi_processor *_pr;
+	struct cpuinfo_x86 *c = &cpu_data(0);
+
+	/* TODO: Under AMD, the information is populated
+	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
+	 * MSR which returns the wrong value (under Xen) so the population
+	 * of 'processors' has bogus data. So only run this under
+	 * Intel for right now. */
+	if (!cpu_has(c, X86_FEATURE_EST)) {
+		pr_err("AMD platform is not supported (yet)\n");
+		return -ENODEV;
+	}
+	/*
+	 * It is imperative that we get called _after_ acpi_processor has
+	 * loaded. Otherwise the _pr might be bogus.
+	*/
+	if (request_module("processor")) {
+		pr_err("Unable to load ACPI processor module!\n");
+		return -ENODEV;
+	}
+	for_each_possible_cpu(cpu) {
+		_pr = per_cpu(processors, cpu);
+		if (!_pr)
+			continue;
+
+		if (_pr->flags.power)
+			err = push_cxx_to_hypervisor(_pr);
+
+		if (_pr->performance->states)
+			err |= push_pxx_to_hypervisor(_pr);
+		if (err)
+			break;
+	}
+	return -ENODEV; /* force it to unload */
+}
+static void __exit acpi_xen_sink_exit(void)
+{
+}
+module_init(acpi_xen_sink_init);
+module_exit(acpi_xen_sink_exit);
-- 
1.7.7.5


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--cWoXeonUoKmBZSoM--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:00:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNFj-00078K-8A; Mon, 23 Jan 2012 17:00:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RpNFi-00078C-Ez
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:00:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327338012!12203980!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 19452 invoked from network); 23 Jan 2012 17:00:12 -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; 23 Jan 2012 17:00:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 17:00:11 +0000
Message-Id: <4F1DA072020000780006E765@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 17:01:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
	<4F1D7702020000780006E6C2@nat28.tlf.novell.com>
	<1327334483.26455.260.camel@elijah>
	<4F1D991A020000780006E74E@nat28.tlf.novell.com>
	<1327337503.26455.314.camel@elijah>
In-Reply-To: <1327337503.26455.314.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 17:51, George Dunlap <george.dunlap@citrix.com> wrote:
> On Mon, 2012-01-23 at 16:30 +0000, Jan Beulich wrote:
>> > The attached patch fixes the build (with the original patch un-reverted
>> > of course), by making the internal calls explicitly take 64-bit values
>> > for eip, rather than "unsigned long".  Will that suffice?
>> 
>> Looks correct and sufficient, but with the original patch already
>> reverted folding the changes here into the original and re-submitting
>> would probably the best route to go.
> 
> I really prefer to keep patches with no functional change separate from
> those with a pretty major functional change; even if the major
> functional change is only one line. :-)

Not sure I follow - the (now reverted) patch was buggy, so why not
fix the patch and re-submit? And besides - the fixup patch is certainly
not "no functional change", at least not on 32-bits.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:00:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNFj-00078K-8A; Mon, 23 Jan 2012 17:00:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RpNFi-00078C-Ez
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:00:18 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327338012!12203980!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 19452 invoked from network); 23 Jan 2012 17:00:12 -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; 23 Jan 2012 17:00:12 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 23 Jan 2012 17:00:11 +0000
Message-Id: <4F1DA072020000780006E765@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 23 Jan 2012 17:01:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F19B633.6090105@citrix.com>
	<4F1D3D1D020000780006E514@nat28.tlf.novell.com>
	<1327313777.24561.9.camel@zakaz.uk.xensource.com>
	<4F1D48BA020000780006E55F@nat28.tlf.novell.com>
	<4F1D7702020000780006E6C2@nat28.tlf.novell.com>
	<1327334483.26455.260.camel@elijah>
	<4F1D991A020000780006E74E@nat28.tlf.novell.com>
	<1327337503.26455.314.camel@elijah>
In-Reply-To: <1327337503.26455.314.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 17:51, George Dunlap <george.dunlap@citrix.com> wrote:
> On Mon, 2012-01-23 at 16:30 +0000, Jan Beulich wrote:
>> > The attached patch fixes the build (with the original patch un-reverted
>> > of course), by making the internal calls explicitly take 64-bit values
>> > for eip, rather than "unsigned long".  Will that suffice?
>> 
>> Looks correct and sufficient, but with the original patch already
>> reverted folding the changes here into the original and re-submitting
>> would probably the best route to go.
> 
> I really prefer to keep patches with no functional change separate from
> those with a pretty major functional change; even if the major
> functional change is only one line. :-)

Not sure I follow - the (now reverted) patch was buggy, so why not
fix the patch and re-submit? And besides - the fixup patch is certainly
not "no functional change", at least not on 32-bits.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNKX-0007LY-8N; Mon, 23 Jan 2012 17:05:17 +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 1RpNKW-0007LQ-4M
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:05:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327338309!10338772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22655 invoked from network); 23 Jan 2012 17:05:09 -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;
	23 Jan 2012 17:05:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10224933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 17:05: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; Mon, 23 Jan 2012 17:05:09 +0000
Date: Mon, 23 Jan 2012 17:05:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <4F1D90B7.4060202@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1201231700072.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D8423.2090603@codemonkey.ws>
	<alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
	<4F1D90B7.4060202@codemonkey.ws>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Anthony Liguori wrote:
> On 01/23/2012 10:46 AM, Stefano Stabellini wrote:
> > On Mon, 23 Jan 2012, Anthony Liguori wrote:
> >> On 01/23/2012 04:47 AM, Stefano Stabellini wrote:
> >>> On Fri, 20 Jan 2012, Jan Kiszka wrote:
> >>>> On 2012-01-20 18:20, Stefano Stabellini wrote:
> >>>>> Hi all,
> >>>>> this is the fourth version of the Xen save/restore patch series.
> >>>>> We have been discussing this issue for quite a while on #qemu and
> >>>>> qemu-devel:
> >>>>>
> >>>>>
> >>>>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> >>>>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> >>>>>
> >>>>>
> >>>>> A few different approaches were proposed to achieve the goal
> >>>>> of a working save/restore with upstream Qemu on Xen, however after
> >>>>> prototyping some of them I came up with yet another solution, that I
> >>>>> think leads to the best results with the less amount of code
> >>>>> duplications and ugliness.
> >>>>> Far from saying that this patch series is an example of elegance and
> >>>>> simplicity, but it is closer to acceptable anything else I have seen so
> >>>>> far.
> >>>>>
> >>>>> What's new is that Qemu is going to keep track of its own physmap on
> >>>>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
> >>>>> the guest's memory map at any time.
> >>>>> This is all handled by Xen or Xen support in Qemu internally and can be
> >>>>> used to solve our save/restore framebuffer problem.
> >>>>>
> >>>>>>  From the Qemu common code POV, we still need to avoid saving the guest's
> >>>>> ram when running on Xen, and we need to avoid resetting the videoram on
> >>>>> restore (that is a benefit to the generic Qemu case too, because it
> >>>>> saves few cpu cycles).
> >>>>
> >>>> For my understanding: Refraining from the memset is required as the
> >>>> already restored vram would then be overwritten?
> >>>
> >>> Yep
> >>>
> >>>> Or what is the ordering
> >>>> of init, RAM restore, and initial device reset now?
> >>>
> >>> RAM restore (done by Xen)
> >>>
> >>> physmap rebuild (done by xen_hvm_init in qemu)
> >>> pc_init()
> >>> qemu_system_reset()
> >>> load_vmstate()
> >>
> >> That's your problem.  You don't want to do load_vmstate().  You just want to
> >> load the device model, not RAM.
> >
> > True
> >
> >
> >> Why not introduce new Xen specific commands like I suggested on IRC?
> >
> > Introducing a Xen specific command is not an issue, but I didn't want to
> > duplicate all the functionalities currently in savevm.c.
> 
> The code is fairly reusable since live migration and savevm use the same 
> internal bits.  I think you would just need another version of 
> qemu_loadvm_state().  That function is only a hundred lines or so so you 
> shouldn't be duplicating much at all.
> 
> >> You should have a separate load_device_state() function and mark anything that
> >> is RAM as RAM when doing savevm registration.  Better yet, mark devices as
> >> devices since that's what you really care about.
> >
> > I dropped this approach because I thought it causes too much code
> > duplication.
> 
> Then you're doing it wrong :-)
> 
> But even if there is, just refactor out the common code.
> 
> > However, following your suggestion, if I add a generic "device" flag in
> > SaveStateEntry and implement a generic qemu_save_device_state in
> > savevm.c, I believe that the duplication of code would be small.
> > And patch #1 could go away.
> 
> Yup.
> 
> >
> >
> > However the issue of patch #4, "do not reset videoram on resume", still
> > remains: no matter what parameter I pass to Qemu, if qemu_system_reset
> > is called on resume the videoram is going to be overwritten by 0xff.
> 
> The memset(0xff) looks dubious to me.  My guess is that this could be moved to 
> the vgabios-cirrus which would solve your problem.
>
> > In this regard, don't you think it would be advantageous to Qemu in
> > general not to reset the videram in resume? It can be pretty large, so
> > it is a significant waste of a memset.
> 
> It claims to fix a real bug.  Moving the memset to vgabios would do what you 
> want to do in a more robust way I think.
 
I think it does fix a bug (Win2K expects RAM to be 0xff at boot, or so a
comment on qemu-xen claims) but certainly it is not supposed to run at
restore time.
I agree that moving the memset to vgabios should be a better way to fix
the problem, I'll give it a look.
Unfortutely it means finding a Win2K install CD to repro the bug, sigh.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNKX-0007LY-8N; Mon, 23 Jan 2012 17:05:17 +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 1RpNKW-0007LQ-4M
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:05:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327338309!10338772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22655 invoked from network); 23 Jan 2012 17:05:09 -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;
	23 Jan 2012 17:05:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,556,1320624000"; d="scan'208";a="10224933"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 17:05: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; Mon, 23 Jan 2012 17:05:09 +0000
Date: Mon, 23 Jan 2012 17:05:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Anthony Liguori <anthony@codemonkey.ws>
In-Reply-To: <4F1D90B7.4060202@codemonkey.ws>
Message-ID: <alpine.DEB.2.00.1201231700072.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D8423.2090603@codemonkey.ws>
	<alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
	<4F1D90B7.4060202@codemonkey.ws>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 23 Jan 2012, Anthony Liguori wrote:
> On 01/23/2012 10:46 AM, Stefano Stabellini wrote:
> > On Mon, 23 Jan 2012, Anthony Liguori wrote:
> >> On 01/23/2012 04:47 AM, Stefano Stabellini wrote:
> >>> On Fri, 20 Jan 2012, Jan Kiszka wrote:
> >>>> On 2012-01-20 18:20, Stefano Stabellini wrote:
> >>>>> Hi all,
> >>>>> this is the fourth version of the Xen save/restore patch series.
> >>>>> We have been discussing this issue for quite a while on #qemu and
> >>>>> qemu-devel:
> >>>>>
> >>>>>
> >>>>> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> >>>>> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> >>>>>
> >>>>>
> >>>>> A few different approaches were proposed to achieve the goal
> >>>>> of a working save/restore with upstream Qemu on Xen, however after
> >>>>> prototyping some of them I came up with yet another solution, that I
> >>>>> think leads to the best results with the less amount of code
> >>>>> duplications and ugliness.
> >>>>> Far from saying that this patch series is an example of elegance and
> >>>>> simplicity, but it is closer to acceptable anything else I have seen so
> >>>>> far.
> >>>>>
> >>>>> What's new is that Qemu is going to keep track of its own physmap on
> >>>>> xenstore, so that Xen can be fully aware of the changes Qemu makes to
> >>>>> the guest's memory map at any time.
> >>>>> This is all handled by Xen or Xen support in Qemu internally and can be
> >>>>> used to solve our save/restore framebuffer problem.
> >>>>>
> >>>>>>  From the Qemu common code POV, we still need to avoid saving the guest's
> >>>>> ram when running on Xen, and we need to avoid resetting the videoram on
> >>>>> restore (that is a benefit to the generic Qemu case too, because it
> >>>>> saves few cpu cycles).
> >>>>
> >>>> For my understanding: Refraining from the memset is required as the
> >>>> already restored vram would then be overwritten?
> >>>
> >>> Yep
> >>>
> >>>> Or what is the ordering
> >>>> of init, RAM restore, and initial device reset now?
> >>>
> >>> RAM restore (done by Xen)
> >>>
> >>> physmap rebuild (done by xen_hvm_init in qemu)
> >>> pc_init()
> >>> qemu_system_reset()
> >>> load_vmstate()
> >>
> >> That's your problem.  You don't want to do load_vmstate().  You just want to
> >> load the device model, not RAM.
> >
> > True
> >
> >
> >> Why not introduce new Xen specific commands like I suggested on IRC?
> >
> > Introducing a Xen specific command is not an issue, but I didn't want to
> > duplicate all the functionalities currently in savevm.c.
> 
> The code is fairly reusable since live migration and savevm use the same 
> internal bits.  I think you would just need another version of 
> qemu_loadvm_state().  That function is only a hundred lines or so so you 
> shouldn't be duplicating much at all.
> 
> >> You should have a separate load_device_state() function and mark anything that
> >> is RAM as RAM when doing savevm registration.  Better yet, mark devices as
> >> devices since that's what you really care about.
> >
> > I dropped this approach because I thought it causes too much code
> > duplication.
> 
> Then you're doing it wrong :-)
> 
> But even if there is, just refactor out the common code.
> 
> > However, following your suggestion, if I add a generic "device" flag in
> > SaveStateEntry and implement a generic qemu_save_device_state in
> > savevm.c, I believe that the duplication of code would be small.
> > And patch #1 could go away.
> 
> Yup.
> 
> >
> >
> > However the issue of patch #4, "do not reset videoram on resume", still
> > remains: no matter what parameter I pass to Qemu, if qemu_system_reset
> > is called on resume the videoram is going to be overwritten by 0xff.
> 
> The memset(0xff) looks dubious to me.  My guess is that this could be moved to 
> the vgabios-cirrus which would solve your problem.
>
> > In this regard, don't you think it would be advantageous to Qemu in
> > general not to reset the videram in resume? It can be pretty large, so
> > it is a significant waste of a memset.
> 
> It claims to fix a real bug.  Moving the memset to vgabios would do what you 
> want to do in a more robust way I think.
 
I think it does fix a bug (Win2K expects RAM to be 0xff at boot, or so a
comment on qemu-xen claims) but certainly it is not supposed to run at
restore time.
I agree that moving the memset to vgabios should be a better way to fix
the problem, I'll give it a look.
Unfortutely it means finding a Win2K install CD to repro the bug, sigh.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:08:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNNA-0007Vg-Rr; Mon, 23 Jan 2012 17:08:00 +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 1RpNN8-0007VL-HX
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:07:58 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327338471!12057272!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 20804 invoked from network); 23 Jan 2012 17:07:52 -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;
	23 Jan 2012 17:07:52 -0000
Received: by iaeh11 with SMTP id h11so20338812iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 09:07:50 -0800 (PST)
Received: by 10.42.117.193 with SMTP id u1mr8593909icq.24.1327338470846;
	Mon, 23 Jan 2012 09:07:50 -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 r18sm48878332ibh.4.2012.01.23.09.07.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 09:07:49 -0800 (PST)
Message-ID: <4F1D93E2.8050203@codemonkey.ws>
Date: Mon, 23 Jan 2012 11:07:46 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D8423.2090603@codemonkey.ws>
	<alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
	<4F1D90B7.4060202@codemonkey.ws>
	<alpine.DEB.2.00.1201231700072.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231700072.3196@kaball-desktop>
X-Gm-Message-State: ALoCoQm16hEeAUWWOWwmdHmmir/Ze+rtipRof3G1KK8/d3MJa6GxZOxRKY6P7HaLrmGtOLEGUxlq
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 11:05 AM, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Anthony Liguori wrote:
>>> However the issue of patch #4, "do not reset videoram on resume", still
>>> remains: no matter what parameter I pass to Qemu, if qemu_system_reset
>>> is called on resume the videoram is going to be overwritten by 0xff.
>>
>> The memset(0xff) looks dubious to me.  My guess is that this could be moved to
>> the vgabios-cirrus which would solve your problem.
>>
>>> In this regard, don't you think it would be advantageous to Qemu in
>>> general not to reset the videram in resume? It can be pretty large, so
>>> it is a significant waste of a memset.
>>
>> It claims to fix a real bug.  Moving the memset to vgabios would do what you
>> want to do in a more robust way I think.
>
> I think it does fix a bug (Win2K expects RAM to be 0xff at boot, or so a
> comment on qemu-xen claims) but certainly it is not supposed to run at
> restore time.
> I agree that moving the memset to vgabios should be a better way to fix
> the problem, I'll give it a look.
> Unfortutely it means finding a Win2K install CD to repro the bug, sigh.

Right, it's a bit annoying, but a much nicer solution :-)

Thanks,

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 Jan 23 17:08:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNNA-0007Vg-Rr; Mon, 23 Jan 2012 17:08:00 +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 1RpNN8-0007VL-HX
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:07:58 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327338471!12057272!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 20804 invoked from network); 23 Jan 2012 17:07:52 -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;
	23 Jan 2012 17:07:52 -0000
Received: by iaeh11 with SMTP id h11so20338812iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 09:07:50 -0800 (PST)
Received: by 10.42.117.193 with SMTP id u1mr8593909icq.24.1327338470846;
	Mon, 23 Jan 2012 09:07:50 -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 r18sm48878332ibh.4.2012.01.23.09.07.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 09:07:49 -0800 (PST)
Message-ID: <4F1D93E2.8050203@codemonkey.ws>
Date: Mon, 23 Jan 2012 11:07:46 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D8423.2090603@codemonkey.ws>
	<alpine.DEB.2.00.1201231623340.3196@kaball-desktop>
	<4F1D90B7.4060202@codemonkey.ws>
	<alpine.DEB.2.00.1201231700072.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231700072.3196@kaball-desktop>
X-Gm-Message-State: ALoCoQm16hEeAUWWOWwmdHmmir/Ze+rtipRof3G1KK8/d3MJa6GxZOxRKY6P7HaLrmGtOLEGUxlq
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 11:05 AM, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Anthony Liguori wrote:
>>> However the issue of patch #4, "do not reset videoram on resume", still
>>> remains: no matter what parameter I pass to Qemu, if qemu_system_reset
>>> is called on resume the videoram is going to be overwritten by 0xff.
>>
>> The memset(0xff) looks dubious to me.  My guess is that this could be moved to
>> the vgabios-cirrus which would solve your problem.
>>
>>> In this regard, don't you think it would be advantageous to Qemu in
>>> general not to reset the videram in resume? It can be pretty large, so
>>> it is a significant waste of a memset.
>>
>> It claims to fix a real bug.  Moving the memset to vgabios would do what you
>> want to do in a more robust way I think.
>
> I think it does fix a bug (Win2K expects RAM to be 0xff at boot, or so a
> comment on qemu-xen claims) but certainly it is not supposed to run at
> restore time.
> I agree that moving the memset to vgabios should be a better way to fix
> the problem, I'll give it a look.
> Unfortutely it means finding a Win2K install CD to repro the bug, sigh.

Right, it's a bit annoying, but a much nicer solution :-)

Thanks,

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 Jan 23 17:14:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNSt-0007nr-Mu; Mon, 23 Jan 2012 17:13:55 +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 1RpNSs-0007ni-R6
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:13:55 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327338828!12210884!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzE0NzA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32178 invoked from network); 23 Jan 2012 17:13:49 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 17:13:49 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q0NHDhiF022467;
	Mon, 23 Jan 2012 18:13:43 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NHDgN9021331;
	Mon, 23 Jan 2012 18:13:42 +0100
Message-ID: <4F1D9546.4040801@siemens.com>
Date: Mon, 23 Jan 2012 18:13:42 +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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 17:16, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-23 15:46, Stefano Stabellini wrote:
>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>> On 2012-01-23 12:59, Stefano Stabellini wrote:
>>>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>>>>>> Or what is the ordering
>>>>>>>> of init, RAM restore, and initial device reset now?
>>>>>>>
>>>>>>> RAM restore (done by Xen)
>>>>>>>
>>>>>>> physmap rebuild (done by xen_hvm_init in qemu)
>>>>>>> pc_init()
>>>>>>> qemu_system_reset()
>>>>>>> load_vmstate()
>>>>>>
>>>>>> Hmm, are you sure that this is the only case where a device init or
>>>>>> reset handler writes to already restored guest memory? Preloading the
>>>>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
>>>>>> fragile. Does restoring happen before QEMU is even started, or can this
>>>>>> point be controlled from QEMU?
>>>>>
>>>>> Consider that this only happens with non-MMIO device memory, in practice
>>>>> only videoram.
>>>>> Vmware VGA does not memset the videoram in the reset handler, while QXL
>>>>> already has the following:
>>>>>
>>>>>     /* pre loadvm reset must not touch QXLRam.  This lives in
>>>>>      * device memory, is migrated together with RAM and thus
>>>>>      * already loaded at this point */ if (!loadvm) {
>>>>>      qxl_reset_state(d); }
>>>>
>>>> Yes, but QEMU restores the RAM _after_ device reset, not before it.
>>>> That's the problem with the Xen way - it is against the current
>>>> QEMU standard.
>>>
>>> QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.
>>
>> But it does otherwise, and that's the scenario the code you cited was
>> written for. It won't work as is under Xen.
> 
> Ah, I see your point now.
> In that regard, is the comment above even correct?
> I am referring to "migrated together with RAM and thus already loaded at
> this point"?

The comment is correct. It refers to the invocation of the function from
the vmload handler. Here, a flag is passed that says "don't overwrite".

> 
> 
>>> To reply to your previous question more clearly: at restore time Qemu on
>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>> before QEMU is even started.
>>>
>>> That is unfortunate but it would be very hard to change (I can give you
>>> more details if you are interested in the reasons why it would be so
>>> difficult).
>>
>> If you can't change this, you need to properly introduce this new
>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>> see breakage outside cirrus sooner or later as well. So it might be good
>> to explain the reason why it can't be changed under Xen when motivating
>> this concept extension to QEMU.
>  
> OK.
> Are you thinking about introducing this concept as a new runstate?
> This special runstate could be set at restore time only on Xen.
> 
> 
> BTW the main reasons for having Xen saving the RAM are:
> 
> - the need to support PV guests, that often run without Qemu;
> - the current save format, that is built around the fact that Xen saves the memory;
> - the fact that Qemu might be running in a very limited stub-domain.

Your problem is not the fact that guest RAM is restored by an external
component. Your problem is that QEMU has no control over the when. If
you fix this, you could coordinate the restoring with the initial device
reset and would solve all potential current and future issues, not only
this single cirrus related one.

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 Jan 23 17:14:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNSt-0007nr-Mu; Mon, 23 Jan 2012 17:13:55 +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 1RpNSs-0007ni-R6
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:13:55 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327338828!12210884!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzE0NzA4\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32178 invoked from network); 23 Jan 2012 17:13:49 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 17:13:49 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q0NHDhiF022467;
	Mon, 23 Jan 2012 18:13:43 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NHDgN9021331;
	Mon, 23 Jan 2012 18:13:42 +0100
Message-ID: <4F1D9546.4040801@siemens.com>
Date: Mon, 23 Jan 2012 18:13:42 +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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 17:16, Stefano Stabellini wrote:
> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-23 15:46, Stefano Stabellini wrote:
>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>> On 2012-01-23 12:59, Stefano Stabellini wrote:
>>>>> On Mon, 23 Jan 2012, Jan Kiszka wrote:
>>>>>>>> Or what is the ordering
>>>>>>>> of init, RAM restore, and initial device reset now?
>>>>>>>
>>>>>>> RAM restore (done by Xen)
>>>>>>>
>>>>>>> physmap rebuild (done by xen_hvm_init in qemu)
>>>>>>> pc_init()
>>>>>>> qemu_system_reset()
>>>>>>> load_vmstate()
>>>>>>
>>>>>> Hmm, are you sure that this is the only case where a device init or
>>>>>> reset handler writes to already restored guest memory? Preloading the
>>>>>> RAM this way is a non-standard scenario for QEMU, thus conceptually
>>>>>> fragile. Does restoring happen before QEMU is even started, or can this
>>>>>> point be controlled from QEMU?
>>>>>
>>>>> Consider that this only happens with non-MMIO device memory, in practice
>>>>> only videoram.
>>>>> Vmware VGA does not memset the videoram in the reset handler, while QXL
>>>>> already has the following:
>>>>>
>>>>>     /* pre loadvm reset must not touch QXLRam.  This lives in
>>>>>      * device memory, is migrated together with RAM and thus
>>>>>      * already loaded at this point */ if (!loadvm) {
>>>>>      qxl_reset_state(d); }
>>>>
>>>> Yes, but QEMU restores the RAM _after_ device reset, not before it.
>>>> That's the problem with the Xen way - it is against the current
>>>> QEMU standard.
>>>
>>> QEMU doesn't save/restore the RAM (and the videoram) at all on Xen.
>>
>> But it does otherwise, and that's the scenario the code you cited was
>> written for. It won't work as is under Xen.
> 
> Ah, I see your point now.
> In that regard, is the comment above even correct?
> I am referring to "migrated together with RAM and thus already loaded at
> this point"?

The comment is correct. It refers to the invocation of the function from
the vmload handler. Here, a flag is passed that says "don't overwrite".

> 
> 
>>> To reply to your previous question more clearly: at restore time Qemu on
>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>> before QEMU is even started.
>>>
>>> That is unfortunate but it would be very hard to change (I can give you
>>> more details if you are interested in the reasons why it would be so
>>> difficult).
>>
>> If you can't change this, you need to properly introduce this new
>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>> see breakage outside cirrus sooner or later as well. So it might be good
>> to explain the reason why it can't be changed under Xen when motivating
>> this concept extension to QEMU.
>  
> OK.
> Are you thinking about introducing this concept as a new runstate?
> This special runstate could be set at restore time only on Xen.
> 
> 
> BTW the main reasons for having Xen saving the RAM are:
> 
> - the need to support PV guests, that often run without Qemu;
> - the current save format, that is built around the fact that Xen saves the memory;
> - the fact that Qemu might be running in a very limited stub-domain.

Your problem is not the fact that guest RAM is restored by an external
component. Your problem is that QEMU has no control over the when. If
you fix this, you could coordinate the restoring with the initial device
reset and would solve all potential current and future issues, not only
this single cirrus related one.

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 Jan 23 17:18:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNX5-0008FH-3C; Mon, 23 Jan 2012 17:18:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RpNX4-0008Ei-3s
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:18:14 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327339087!1823591!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28038 invoked from network); 23 Jan 2012 17:18:08 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 17:18:08 -0000
Received: by ggnk3 with SMTP id k3so38853476ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 09:18:06 -0800 (PST)
Received: by 10.50.15.131 with SMTP id x3mr4311748igc.13.1327339086666;
	Mon, 23 Jan 2012 09:18:06 -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 xu6sm24620014igb.7.2012.01.23.09.18.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 09:18:05 -0800 (PST)
Message-ID: <4F1D9649.1000102@codemonkey.ws>
Date: Mon, 23 Jan 2012 11:18:01 -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: Jan Kiszka <jan.kiszka@siemens.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com>
In-Reply-To: <4F1D9546.4040801@siemens.com>
X-Gm-Message-State: ALoCoQkR2rAb7Qm6Jbc5by0QyMODZKhyik7fSOMeOwUxpruR4XjL8xK7R0EtGksEcfo5+ww5HMUo
Cc: Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 11:13 AM, Jan Kiszka wrote:
>>>> To reply to your previous question more clearly: at restore time Qemu on
>>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>>> before QEMU is even started.
>>>>
>>>> That is unfortunate but it would be very hard to change (I can give you
>>>> more details if you are interested in the reasons why it would be so
>>>> difficult).
>>>
>>> If you can't change this, you need to properly introduce this new
>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>>> see breakage outside cirrus sooner or later as well. So it might be good
>>> to explain the reason why it can't be changed under Xen when motivating
>>> this concept extension to QEMU.
>>
>> OK.
>> Are you thinking about introducing this concept as a new runstate?
>> This special runstate could be set at restore time only on Xen.
>>
>>
>> BTW the main reasons for having Xen saving the RAM are:
>>
>> - the need to support PV guests, that often run without Qemu;
>> - the current save format, that is built around the fact that Xen saves the memory;
>> - the fact that Qemu might be running in a very limited stub-domain.
>
> Your problem is not the fact that guest RAM is restored by an external
> component. Your problem is that QEMU has no control over the when. If
> you fix this, you could coordinate the restoring with the initial device
> reset and would solve all potential current and future issues, not only
> this single cirrus related one.

Generally speaking, RAM is an independent device in most useful cases.  Onboard 
RAM is a very special case because it's extremely unusual.

But since some video cards can make use of dedicated external RAM, I don't think 
any video card really depends on initial RAM state.

What's most likely here is that the VGA BIOS of a Cirrus card sets an initial 
RAM state during device initialization.

We really should view RAM as just another device so I don't like the idea of 
propagating a global concept of "when RAM is restored" because that treats it 
specially compared to other devices.

But viewing RAM as just another device, having Xen only restore a subset of 
devices should be a reasonable thing to do moving forward.  The main problem 
here I believe is that we have part of the VGA Bios functionality in the 
hardware emulation.

Regards,

Anthony Liguori

>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:18:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:18:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNX5-0008FH-3C; Mon, 23 Jan 2012 17:18:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1RpNX4-0008Ei-3s
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:18:14 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327339087!1823591!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.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28038 invoked from network); 23 Jan 2012 17:18:08 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 17:18:08 -0000
Received: by ggnk3 with SMTP id k3so38853476ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 09:18:06 -0800 (PST)
Received: by 10.50.15.131 with SMTP id x3mr4311748igc.13.1327339086666;
	Mon, 23 Jan 2012 09:18:06 -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 xu6sm24620014igb.7.2012.01.23.09.18.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 09:18:05 -0800 (PST)
Message-ID: <4F1D9649.1000102@codemonkey.ws>
Date: Mon, 23 Jan 2012 11:18:01 -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: Jan Kiszka <jan.kiszka@siemens.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com>
In-Reply-To: <4F1D9546.4040801@siemens.com>
X-Gm-Message-State: ALoCoQkR2rAb7Qm6Jbc5by0QyMODZKhyik7fSOMeOwUxpruR4XjL8xK7R0EtGksEcfo5+ww5HMUo
Cc: Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 11:13 AM, Jan Kiszka wrote:
>>>> To reply to your previous question more clearly: at restore time Qemu on
>>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>>> before QEMU is even started.
>>>>
>>>> That is unfortunate but it would be very hard to change (I can give you
>>>> more details if you are interested in the reasons why it would be so
>>>> difficult).
>>>
>>> If you can't change this, you need to properly introduce this new
>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>>> see breakage outside cirrus sooner or later as well. So it might be good
>>> to explain the reason why it can't be changed under Xen when motivating
>>> this concept extension to QEMU.
>>
>> OK.
>> Are you thinking about introducing this concept as a new runstate?
>> This special runstate could be set at restore time only on Xen.
>>
>>
>> BTW the main reasons for having Xen saving the RAM are:
>>
>> - the need to support PV guests, that often run without Qemu;
>> - the current save format, that is built around the fact that Xen saves the memory;
>> - the fact that Qemu might be running in a very limited stub-domain.
>
> Your problem is not the fact that guest RAM is restored by an external
> component. Your problem is that QEMU has no control over the when. If
> you fix this, you could coordinate the restoring with the initial device
> reset and would solve all potential current and future issues, not only
> this single cirrus related one.

Generally speaking, RAM is an independent device in most useful cases.  Onboard 
RAM is a very special case because it's extremely unusual.

But since some video cards can make use of dedicated external RAM, I don't think 
any video card really depends on initial RAM state.

What's most likely here is that the VGA BIOS of a Cirrus card sets an initial 
RAM state during device initialization.

We really should view RAM as just another device so I don't like the idea of 
propagating a global concept of "when RAM is restored" because that treats it 
specially compared to other devices.

But viewing RAM as just another device, having Xen only restore a subset of 
devices should be a reasonable thing to do moving forward.  The main problem 
here I believe is that we have part of the VGA Bios functionality in the 
hardware emulation.

Regards,

Anthony Liguori

>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:31:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNjg-0000FV-DK; Mon, 23 Jan 2012 17:31:16 +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 1RpNjf-0000FM-2q
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:31:15 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327339741!49737402!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDMxMzQxMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30312 invoked from network); 23 Jan 2012 17:29:01 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 17:29:01 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q0NHV7qQ009607;
	Mon, 23 Jan 2012 18:31:08 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NHV625007769;
	Mon, 23 Jan 2012 18:31:06 +0100
Message-ID: <4F1D995A.4020604@siemens.com>
Date: Mon, 23 Jan 2012 18:31:06 +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: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
In-Reply-To: <4F1D9649.1000102@codemonkey.ws>
Cc: Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 18:18, Anthony Liguori wrote:
> On 01/23/2012 11:13 AM, Jan Kiszka wrote:
>>>>> To reply to your previous question more clearly: at restore time Qemu on
>>>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>>>> before QEMU is even started.
>>>>>
>>>>> That is unfortunate but it would be very hard to change (I can give you
>>>>> more details if you are interested in the reasons why it would be so
>>>>> difficult).
>>>>
>>>> If you can't change this, you need to properly introduce this new
>>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>>>> see breakage outside cirrus sooner or later as well. So it might be good
>>>> to explain the reason why it can't be changed under Xen when motivating
>>>> this concept extension to QEMU.
>>>
>>> OK.
>>> Are you thinking about introducing this concept as a new runstate?
>>> This special runstate could be set at restore time only on Xen.
>>>
>>>
>>> BTW the main reasons for having Xen saving the RAM are:
>>>
>>> - the need to support PV guests, that often run without Qemu;
>>> - the current save format, that is built around the fact that Xen saves the memory;
>>> - the fact that Qemu might be running in a very limited stub-domain.
>>
>> Your problem is not the fact that guest RAM is restored by an external
>> component. Your problem is that QEMU has no control over the when. If
>> you fix this, you could coordinate the restoring with the initial device
>> reset and would solve all potential current and future issues, not only
>> this single cirrus related one.
> 
> Generally speaking, RAM is an independent device in most useful cases.  Onboard 
> RAM is a very special case because it's extremely unusual.
> 
> But since some video cards can make use of dedicated external RAM, I don't think 
> any video card really depends on initial RAM state.
> 
> What's most likely here is that the VGA BIOS of a Cirrus card sets an initial 
> RAM state during device initialization.
> 
> We really should view RAM as just another device so I don't like the idea of 
> propagating a global concept of "when RAM is restored" because that treats it 
> specially compared to other devices.
> 
> But viewing RAM as just another device, having Xen only restore a subset of 
> devices should be a reasonable thing to do moving forward.  The main problem 
> here I believe is that we have part of the VGA Bios functionality in the 
> hardware emulation.

To my understanding, QXL will break identically on Xen for the same
reason: the reset handler assumes it can deal with the VRAM as it likes.

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 Jan 23 17:31:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17: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 1RpNjg-0000FV-DK; Mon, 23 Jan 2012 17:31:16 +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 1RpNjf-0000FM-2q
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:31:15 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327339741!49737402!1
X-Originating-IP: [192.35.17.14]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjE0ID0+IDMxMzQxMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30312 invoked from network); 23 Jan 2012 17:29:01 -0000
Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 17:29:01 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by david.siemens.de (8.13.6/8.13.6) with ESMTP id q0NHV7qQ009607;
	Mon, 23 Jan 2012 18:31:08 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0NHV625007769;
	Mon, 23 Jan 2012 18:31:06 +0100
Message-ID: <4F1D995A.4020604@siemens.com>
Date: Mon, 23 Jan 2012 18:31:06 +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: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
In-Reply-To: <4F1D9649.1000102@codemonkey.ws>
Cc: Avi Kivity <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-23 18:18, Anthony Liguori wrote:
> On 01/23/2012 11:13 AM, Jan Kiszka wrote:
>>>>> To reply to your previous question more clearly: at restore time Qemu on
>>>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>>>> before QEMU is even started.
>>>>>
>>>>> That is unfortunate but it would be very hard to change (I can give you
>>>>> more details if you are interested in the reasons why it would be so
>>>>> difficult).
>>>>
>>>> If you can't change this, you need to properly introduce this new
>>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>>>> see breakage outside cirrus sooner or later as well. So it might be good
>>>> to explain the reason why it can't be changed under Xen when motivating
>>>> this concept extension to QEMU.
>>>
>>> OK.
>>> Are you thinking about introducing this concept as a new runstate?
>>> This special runstate could be set at restore time only on Xen.
>>>
>>>
>>> BTW the main reasons for having Xen saving the RAM are:
>>>
>>> - the need to support PV guests, that often run without Qemu;
>>> - the current save format, that is built around the fact that Xen saves the memory;
>>> - the fact that Qemu might be running in a very limited stub-domain.
>>
>> Your problem is not the fact that guest RAM is restored by an external
>> component. Your problem is that QEMU has no control over the when. If
>> you fix this, you could coordinate the restoring with the initial device
>> reset and would solve all potential current and future issues, not only
>> this single cirrus related one.
> 
> Generally speaking, RAM is an independent device in most useful cases.  Onboard 
> RAM is a very special case because it's extremely unusual.
> 
> But since some video cards can make use of dedicated external RAM, I don't think 
> any video card really depends on initial RAM state.
> 
> What's most likely here is that the VGA BIOS of a Cirrus card sets an initial 
> RAM state during device initialization.
> 
> We really should view RAM as just another device so I don't like the idea of 
> propagating a global concept of "when RAM is restored" because that treats it 
> specially compared to other devices.
> 
> But viewing RAM as just another device, having Xen only restore a subset of 
> devices should be a reasonable thing to do moving forward.  The main problem 
> here I believe is that we have part of the VGA Bios functionality in the 
> hardware emulation.

To my understanding, QXL will break identically on Xen for the same
reason: the reset handler assumes it can deal with the VRAM as it likes.

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 Jan 23 17:31:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNk4-0000Hw-Qq; Mon, 23 Jan 2012 17:31:40 +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 1RpNk3-0000HK-KF
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:31:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327339893!10354393!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15840 invoked from network); 23 Jan 2012 17:31:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 17:31:33 -0000
Received: by werb14 with SMTP id b14so9127002wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 09:31: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=fEDHh7VZkm2lIvxXii7/BWxlMSOGtfmZpMJoaCAhTQs=;
	b=kXVoseN+tGW657Nmh2alCvf+1yljE8MFGZ68ahYz5XbjmZ4+EFGicmuA3AYYEr4c1x
	Hhz0Q1p52X6dt25x8ofuYB+HS4L1t768pzjJfXDFjmMpsj3w/9tHp5RjF5FCKWahkezC
	YOarKqvCI6ZtAYh/45q5bY7L/LqO/vez8Yzps=
Received: by 10.216.133.132 with SMTP id q4mr3154706wei.12.1327339893079;
	Mon, 23 Jan 2012 09:31:33 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fv6sm43211415wib.8.2012.01.23.09.31.30
	(version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 09:31:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Jan 2012 17:31:28 +0000
From: Keir Fraser <keir@xen.org>
To: George Dunlap <george.dunlap@citrix.com>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CB4349F0.37FDB%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
	consistent across 32 and 64-bit xen
Thread-Index: AczZ9NZyAlrRpv3QVk6PO1Z8A5V+0w==
In-Reply-To: <1327337503.26455.314.camel@elijah>
Mime-version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23/01/2012 16:51, "George Dunlap" <george.dunlap@citrix.com> wrote:

> On Mon, 2012-01-23 at 16:30 +0000, Jan Beulich wrote:
>>> The attached patch fixes the build (with the original patch un-reverted
>>> of course), by making the internal calls explicitly take 64-bit values
>>> for eip, rather than "unsigned long".  Will that suffice?
>> 
>> Looks correct and sufficient, but with the original patch already
>> reverted folding the changes here into the original and re-submitting
>> would probably the best route to go.
> 
> I really prefer to keep patches with no functional change separate from
> those with a pretty major functional change; even if the major
> functional change is only one line. :-)

The one-line major functional change didn't work. Obviously the other
changes to make it build must be part of the same logical patch.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:31:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:31:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNk4-0000Hw-Qq; Mon, 23 Jan 2012 17:31:40 +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 1RpNk3-0000HK-KF
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:31:39 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327339893!10354393!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15840 invoked from network); 23 Jan 2012 17:31:33 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 17:31:33 -0000
Received: by werb14 with SMTP id b14so9127002wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 09:31: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=fEDHh7VZkm2lIvxXii7/BWxlMSOGtfmZpMJoaCAhTQs=;
	b=kXVoseN+tGW657Nmh2alCvf+1yljE8MFGZ68ahYz5XbjmZ4+EFGicmuA3AYYEr4c1x
	Hhz0Q1p52X6dt25x8ofuYB+HS4L1t768pzjJfXDFjmMpsj3w/9tHp5RjF5FCKWahkezC
	YOarKqvCI6ZtAYh/45q5bY7L/LqO/vez8Yzps=
Received: by 10.216.133.132 with SMTP id q4mr3154706wei.12.1327339893079;
	Mon, 23 Jan 2012 09:31:33 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fv6sm43211415wib.8.2012.01.23.09.31.30
	(version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 09:31:32 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 23 Jan 2012 17:31:28 +0000
From: Keir Fraser <keir@xen.org>
To: George Dunlap <george.dunlap@citrix.com>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CB4349F0.37FDB%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
	consistent across 32 and 64-bit xen
Thread-Index: AczZ9NZyAlrRpv3QVk6PO1Z8A5V+0w==
In-Reply-To: <1327337503.26455.314.camel@elijah>
Mime-version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23/01/2012 16:51, "George Dunlap" <george.dunlap@citrix.com> wrote:

> On Mon, 2012-01-23 at 16:30 +0000, Jan Beulich wrote:
>>> The attached patch fixes the build (with the original patch un-reverted
>>> of course), by making the internal calls explicitly take 64-bit values
>>> for eip, rather than "unsigned long".  Will that suffice?
>> 
>> Looks correct and sufficient, but with the original patch already
>> reverted folding the changes here into the original and re-submitting
>> would probably the best route to go.
> 
> I really prefer to keep patches with no functional change separate from
> those with a pretty major functional change; even if the major
> functional change is only one line. :-)

The one-line major functional change didn't work. Obviously the other
changes to make it build must be part of the same logical patch.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:36:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNoj-0000dA-NW; Mon, 23 Jan 2012 17:36:29 +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 1RpNoi-0000cM-Ll
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:36:28 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327340180!9726117!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 15426 invoked from network); 23 Jan 2012 17:36:21 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 17:36:21 -0000
Received: by iaeh11 with SMTP id h11so20420079iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 09:36:19 -0800 (PST)
Received: by 10.50.214.73 with SMTP id ny9mr10954296igc.1.1327340178979;
	Mon, 23 Jan 2012 09:36:18 -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 pb6sm24700606igc.5.2012.01.23.09.36.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 09:36:18 -0800 (PST)
Message-ID: <4F1D9A8E.1080102@codemonkey.ws>
Date: Mon, 23 Jan 2012 11:36:14 -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: Jan Kiszka <jan.kiszka@siemens.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>
	<4F1D9649.1000102@codemonkey.ws> <4F1D995A.4020604@siemens.com>
In-Reply-To: <4F1D995A.4020604@siemens.com>
X-Gm-Message-State: ALoCoQkCGfwDFYWV0dFCJ7912fmYp7dmqcPLnrXbwk8mk3TNprxelWFWE63zZJd3ecBice88kX3f
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 11:31 AM, Jan Kiszka wrote:
> On 2012-01-23 18:18, Anthony Liguori wrote:
>> On 01/23/2012 11:13 AM, Jan Kiszka wrote:
>>>>>> To reply to your previous question more clearly: at restore time Qemu on
>>>>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>>>>> before QEMU is even started.
>>>>>>
>>>>>> That is unfortunate but it would be very hard to change (I can give you
>>>>>> more details if you are interested in the reasons why it would be so
>>>>>> difficult).
>>>>>
>>>>> If you can't change this, you need to properly introduce this new
>>>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>>>>> see breakage outside cirrus sooner or later as well. So it might be good
>>>>> to explain the reason why it can't be changed under Xen when motivating
>>>>> this concept extension to QEMU.
>>>>
>>>> OK.
>>>> Are you thinking about introducing this concept as a new runstate?
>>>> This special runstate could be set at restore time only on Xen.
>>>>
>>>>
>>>> BTW the main reasons for having Xen saving the RAM are:
>>>>
>>>> - the need to support PV guests, that often run without Qemu;
>>>> - the current save format, that is built around the fact that Xen saves the memory;
>>>> - the fact that Qemu might be running in a very limited stub-domain.
>>>
>>> Your problem is not the fact that guest RAM is restored by an external
>>> component. Your problem is that QEMU has no control over the when. If
>>> you fix this, you could coordinate the restoring with the initial device
>>> reset and would solve all potential current and future issues, not only
>>> this single cirrus related one.
>>
>> Generally speaking, RAM is an independent device in most useful cases.  Onboard
>> RAM is a very special case because it's extremely unusual.
>>
>> But since some video cards can make use of dedicated external RAM, I don't think
>> any video card really depends on initial RAM state.
>>
>> What's most likely here is that the VGA BIOS of a Cirrus card sets an initial
>> RAM state during device initialization.
>>
>> We really should view RAM as just another device so I don't like the idea of
>> propagating a global concept of "when RAM is restored" because that treats it
>> specially compared to other devices.
>>
>> But viewing RAM as just another device, having Xen only restore a subset of
>> devices should be a reasonable thing to do moving forward.  The main problem
>> here I believe is that we have part of the VGA Bios functionality in the
>> hardware emulation.
>
> To my understanding, QXL will break identically on Xen for the same
> reason: the reset handler assumes it can deal with the VRAM as it likes.

QXL also has a VGA BIOS that it could use to initialize VRAM.  A similar change 
could be made for it.

In general, devices shouldn't make assumptions about the state of other devices 
during reset.  Writing to RAM assumes that RAM has been fully initialized.  We 
don't express reset dependencies right now and it's not clear to me that this is 
something that we should be modeling.

Regards,

Anthony Liguori

>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:36:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:36:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNoj-0000dA-NW; Mon, 23 Jan 2012 17:36:29 +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 1RpNoi-0000cM-Ll
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:36:28 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327340180!9726117!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 15426 invoked from network); 23 Jan 2012 17:36:21 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 17:36:21 -0000
Received: by iaeh11 with SMTP id h11so20420079iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 09:36:19 -0800 (PST)
Received: by 10.50.214.73 with SMTP id ny9mr10954296igc.1.1327340178979;
	Mon, 23 Jan 2012 09:36:18 -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 pb6sm24700606igc.5.2012.01.23.09.36.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 23 Jan 2012 09:36:18 -0800 (PST)
Message-ID: <4F1D9A8E.1080102@codemonkey.ws>
Date: Mon, 23 Jan 2012 11:36:14 -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: Jan Kiszka <jan.kiszka@siemens.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>
	<4F1D9649.1000102@codemonkey.ws> <4F1D995A.4020604@siemens.com>
In-Reply-To: <4F1D995A.4020604@siemens.com>
X-Gm-Message-State: ALoCoQkCGfwDFYWV0dFCJ7912fmYp7dmqcPLnrXbwk8mk3TNprxelWFWE63zZJd3ecBice88kX3f
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 11:31 AM, Jan Kiszka wrote:
> On 2012-01-23 18:18, Anthony Liguori wrote:
>> On 01/23/2012 11:13 AM, Jan Kiszka wrote:
>>>>>> To reply to your previous question more clearly: at restore time Qemu on
>>>>>> Xen would run in a non-standard scenario; the restore of the RAM happens
>>>>>> before QEMU is even started.
>>>>>>
>>>>>> That is unfortunate but it would be very hard to change (I can give you
>>>>>> more details if you are interested in the reasons why it would be so
>>>>>> difficult).
>>>>>
>>>>> If you can't change this, you need to properly introduce this new
>>>>> scenario - pre-initialized RAM - to the QEMU device model. Or you will
>>>>> see breakage outside cirrus sooner or later as well. So it might be good
>>>>> to explain the reason why it can't be changed under Xen when motivating
>>>>> this concept extension to QEMU.
>>>>
>>>> OK.
>>>> Are you thinking about introducing this concept as a new runstate?
>>>> This special runstate could be set at restore time only on Xen.
>>>>
>>>>
>>>> BTW the main reasons for having Xen saving the RAM are:
>>>>
>>>> - the need to support PV guests, that often run without Qemu;
>>>> - the current save format, that is built around the fact that Xen saves the memory;
>>>> - the fact that Qemu might be running in a very limited stub-domain.
>>>
>>> Your problem is not the fact that guest RAM is restored by an external
>>> component. Your problem is that QEMU has no control over the when. If
>>> you fix this, you could coordinate the restoring with the initial device
>>> reset and would solve all potential current and future issues, not only
>>> this single cirrus related one.
>>
>> Generally speaking, RAM is an independent device in most useful cases.  Onboard
>> RAM is a very special case because it's extremely unusual.
>>
>> But since some video cards can make use of dedicated external RAM, I don't think
>> any video card really depends on initial RAM state.
>>
>> What's most likely here is that the VGA BIOS of a Cirrus card sets an initial
>> RAM state during device initialization.
>>
>> We really should view RAM as just another device so I don't like the idea of
>> propagating a global concept of "when RAM is restored" because that treats it
>> specially compared to other devices.
>>
>> But viewing RAM as just another device, having Xen only restore a subset of
>> devices should be a reasonable thing to do moving forward.  The main problem
>> here I believe is that we have part of the VGA Bios functionality in the
>> hardware emulation.
>
> To my understanding, QXL will break identically on Xen for the same
> reason: the reset handler assumes it can deal with the VRAM as it likes.

QXL also has a VGA BIOS that it could use to initialize VRAM.  A similar change 
could be made for it.

In general, devices shouldn't make assumptions about the state of other devices 
during reset.  Writing to RAM assumes that RAM has been fully initialized.  We 
don't express reset dependencies right now and it's not clear to me that this is 
something that we should be modeling.

Regards,

Anthony Liguori

>
> Jan
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:40:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNsm-0000vq-IE; Mon, 23 Jan 2012 17:40:40 +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 1RpNsl-0000vg-Fr
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:40:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327340384!53729356!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14366 invoked from network); 23 Jan 2012 17:39:46 -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;
	23 Jan 2012 17:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,557,1320642000"; d="scan'208";a="21184790"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 12:40:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 12:40:36 -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 q0NHeXXe032169;
	Mon, 23 Jan 2012 09:40:34 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CB4349F0.37FDB%keir@xen.org>
References: <CB4349F0.37FDB%keir@xen.org>
Date: Mon, 23 Jan 2012 17:40:33 +0000
Message-ID: <1327340433.26455.338.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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, 2012-01-23 at 17:31 +0000, Keir Fraser wrote:
> > I really prefer to keep patches with no functional change separate from
> > those with a pretty major functional change; even if the major
> > functional change is only one line. :-)
> 
> The one-line major functional change didn't work. Obviously the other
> changes to make it build must be part of the same logical patch.

Perhaps "functional" change isn't what I meant, so much as
"guest-visible behavior change".

If I were writing this patch series from the beginning, I'd have one
patch which "fixed" the various internal functions to use 64-bits for
EIP, since even in 32-bit that value in the struct can be 64-bit.  That
patch by itself could have a bug in it, and so as a reviewer /
archaeologist, *I* would have preferred it did just that one thing, so I
didn't have to figure out what each individual line was supposed to be
doing.  Then the guest-visible functional change would have been its own
patch.

In any case, I'll send a combined patch tomorrow, since that seems
preferred.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:40:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:40:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpNsm-0000vq-IE; Mon, 23 Jan 2012 17:40:40 +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 1RpNsl-0000vg-Fr
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:40:39 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327340384!53729356!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTYxODI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14366 invoked from network); 23 Jan 2012 17:39:46 -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;
	23 Jan 2012 17:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,557,1320642000"; d="scan'208";a="21184790"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 12:40:36 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 23 Jan 2012 12:40:36 -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 q0NHeXXe032169;
	Mon, 23 Jan 2012 09:40:34 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CB4349F0.37FDB%keir@xen.org>
References: <CB4349F0.37FDB%keir@xen.org>
Date: Mon, 23 Jan 2012 17:40:33 +0000
Message-ID: <1327340433.26455.338.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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, 2012-01-23 at 17:31 +0000, Keir Fraser wrote:
> > I really prefer to keep patches with no functional change separate from
> > those with a pretty major functional change; even if the major
> > functional change is only one line. :-)
> 
> The one-line major functional change didn't work. Obviously the other
> changes to make it build must be part of the same logical patch.

Perhaps "functional" change isn't what I meant, so much as
"guest-visible behavior change".

If I were writing this patch series from the beginning, I'd have one
patch which "fixed" the various internal functions to use 64-bits for
EIP, since even in 32-bit that value in the struct can be 64-bit.  That
patch by itself could have a bug in it, and so as a reviewer /
archaeologist, *I* would have preferred it did just that one thing, so I
didn't have to figure out what each individual line was supposed to be
doing.  Then the guest-visible functional change would have been its own
patch.

In any case, I'll send a combined patch tomorrow, since that seems
preferred.

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:56:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:56:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpO7z-0001OI-6K; Mon, 23 Jan 2012 17:56:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RpO7x-0001OD-6X
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:56:21 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327341372!12229429!1
X-Originating-IP: [220.181.15.23]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjIzID0+IDczMTg=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjIzID0+IDczMTg=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17727 invoked from network); 23 Jan 2012 17:56:13 -0000
Received: from m15-23.126.com (HELO m15-23.126.com) (220.181.15.23)
	by server-12.tower-216.messagelabs.com with SMTP;
	23 Jan 2012 17:56:13 -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=IDVx3e0ITJwVFj7
	bCWaHE5h8QxMFYVHgs7f9wutIvoo=; b=EhmoHCea+/fvyjI4h4aOYT+o/Nby5k8
	KlpfTxociB+pQ4ex3dwpRjSY88qWeCnZt6Mr7OTzMDztppAUShGj7brugEmPRXLs
	iHg7RWI/yBpVIkJt6QKp3IqlkYN8U+4UXpbFxinDCH3RWjwVVmZYTSj1hugVmEoR
	2SSbu/ybSDzI=
Received: from hxkhust ( [111.172.53.94] ) by ajax-webmail-wmsvr23
	(Coremail) ; Tue, 24 Jan 2012 01:56:10 +0800 (CST)
Date: Tue, 24 Jan 2012 01:56:10 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: "Tim Deegan" <tim@xen.org>
Message-ID: <21ab2d2d.22ed.1350bb5fdad.Coremail.hxkhust@126.com>
In-Reply-To: <20120119110726.GB66164@ocelot.phlegethon.org>
References: <20120119110726.GB66164@ocelot.phlegethon.org>
	<f11ec12.21ca.134d4904a11.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [111.172.53.94]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: Ky6BHGZvb3Rlcl9odG09MzMwMjo4MQ==
X-CM-TRANSID: F8qowGCJL0E7nx1PIE4DAA--.16922W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbi4xs+BU3LhqPMOwAAsX
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] A Problem with Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8294801733167030195=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8294801733167030195==
Content-Type: multipart/alternative; 
	boundary="----=_Part_23460_835926944.1327341370797"

------=_Part_23460_835926944.1327341370797
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

I am terribly sorry for the mistake that i made in my last latter.I express my question incorrectly.
The following is the correct one:
 
On a physical machine with xen virtualization platform installed ,VM A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM A and VM B's virtual disk image files are based on VM C's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM A get a page data from VM C's virtual disk image file. After that ,VM B also need to get the same page data as VM A got just now.Under this situation, does VMM copy the page data from VM A's memory to VM B's memory or get the page data from VM C's virtual disk image file in the physical disk again? 

At 2012-01-19 19:07:38,"Tim Deegan" <tim@xen.org> wrote:
>Hi, 
>At 08:55 +0800 on 13 Jan (1326444953), hxkhust wrote:
>> On a physical machine with xen virtualization platform installed ,VM
>>  A,VM B are VM C's virtual disks are all image files,among which VM A
>>  and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
>>  format. And VM B and VM C's virtual disk image files are based on VM
>>  A's virtual disk image file.Now these three VMs are running on the
>>  same physical machine with xen installed. 
>> 
>>  In the process of running VM B get a page data from VM A's virtual
>>  disk image file. After that ,VM C also need to get the same page data
>>  as VM B got just now.Under this situation, does VMM copy the page
>>  data from VM B's memory to VM C's memory or get the page data from VM
>>  A's virtual disk image file in the physical disk again?
>
>Since VM C's disk is not QCOW, reads will always come directly from VM
>C's image -- never from VM A's image (since the tools wouldn't know how
>to do that) and never by copying from VM B.
>
>Tim.

------=_Part_23460_835926944.1327341370797
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>I am terribly sorry for the mistake that i made in my last latter.I express my question incorrectly.</DIV>
<DIV>The&nbsp;following is the correct one:</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>On a physical machine&nbsp;with xen virtualization platform&nbsp;installed ,VM&nbsp;A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM&nbsp;A and VM B's virtual disk image files are based on VM C's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM&nbsp;A get a page data from VM C's virtual disk image file. After that ,VM&nbsp;B also need to get the same page data as VM&nbsp;A got just now.Under this situation, does VMM copy the page data from VM A's memory to VM B's memory or get the page data from&nbsp;VM C's virtual disk image file in the physical disk again?&nbsp;</DIV></DIV>
<DIV><BR>At&nbsp;2012-01-19&nbsp;19:07:38,"Tim&nbsp;Deegan"&nbsp;&lt;tim@xen.org&gt;&nbsp;wrote:<BR>&gt;Hi,&nbsp;<BR>&gt;At&nbsp;08:55&nbsp;+0800&nbsp;on&nbsp;13&nbsp;Jan&nbsp;(1326444953),&nbsp;hxkhust&nbsp;wrote:<BR>&gt;&gt;&nbsp;On&nbsp;a&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;virtualization&nbsp;platform&nbsp;installed&nbsp;,VM<BR>&gt;&gt;&nbsp;&nbsp;A,VM&nbsp;B&nbsp;are&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;all&nbsp;image&nbsp;files,among&nbsp;which&nbsp;VM&nbsp;A<BR>&gt;&gt;&nbsp;&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;QCOW2&nbsp;format&nbsp;and&nbsp;VM&nbsp;C's&nbsp;disk&nbsp;is&nbsp;RAW<BR>&gt;&gt;&nbsp;&nbsp;format.&nbsp;And&nbsp;VM&nbsp;B&nbsp;and&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;files&nbsp;are&nbsp;based&nbsp;on&nbsp;VM<BR>&gt;&gt;&nbsp;&nbsp;A's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file.Now&nbsp;these&nbsp;three&nbsp;VMs&nbsp;are&nbsp;running&nbsp;on&nbsp;the<BR>&gt;&gt;&nbsp;&nbsp;same&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;installed.&nbsp;<BR>&gt;&gt;&nbsp;<BR>&gt;&gt;&nbsp;&nbsp;In&nbsp;the&nbsp;process&nbsp;of&nbsp;running&nbsp;VM&nbsp;B&nbsp;get&nbsp;a&nbsp;page&nbsp;data&nbsp;from&nbsp;VM&nbsp;A's&nbsp;virtual<BR>&gt;&gt;&nbsp;&nbsp;disk&nbsp;image&nbsp;file.&nbsp;After&nbsp;that&nbsp;,VM&nbsp;C&nbsp;also&nbsp;need&nbsp;to&nbsp;get&nbsp;the&nbsp;same&nbsp;page&nbsp;data<BR>&gt;&gt;&nbsp;&nbsp;as&nbsp;VM&nbsp;B&nbsp;got&nbsp;just&nbsp;now.Under&nbsp;this&nbsp;situation,&nbsp;does&nbsp;VMM&nbsp;copy&nbsp;the&nbsp;page<BR>&gt;&gt;&nbsp;&nbsp;data&nbsp;from&nbsp;VM&nbsp;B's&nbsp;memory&nbsp;to&nbsp;VM&nbsp;C's&nbsp;memory&nbsp;or&nbsp;get&nbsp;the&nbsp;page&nbsp;data&nbsp;from&nbsp;VM<BR>&gt;&gt;&nbsp;&nbsp;A's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file&nbsp;in&nbsp;the&nbsp;physical&nbsp;disk&nbsp;again?<BR>&gt;<BR>&gt;Since&nbsp;VM&nbsp;C's&nbsp;disk&nbsp;is&nbsp;not&nbsp;QCOW,&nbsp;reads&nbsp;will&nbsp;always&nbsp;come&nbsp;directly&nbsp;from&nbsp;VM<BR>&gt;C's&nbsp;image&nbsp;--&nbsp;never&nbsp;from&nbsp;VM&nbsp;A's&nbsp;image&nbsp;(since&nbsp;the&nbsp;tools&nbsp;wouldn't&nbsp;know&nbsp;how<BR>&gt;to&nbsp;do&nbsp;that)&nbsp;and&nbsp;never&nbsp;by&nbsp;copying&nbsp;from&nbsp;VM&nbsp;B.<BR>&gt;<BR>&gt;Tim.<BR></DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_23460_835926944.1327341370797--



--===============8294801733167030195==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8294801733167030195==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 17:56:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 17:56:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpO7z-0001OI-6K; Mon, 23 Jan 2012 17:56:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RpO7x-0001OD-6X
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 17:56:21 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327341372!12229429!1
X-Originating-IP: [220.181.15.23]
X-SpamReason: No, hits=0.6 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjIzID0+IDczMTg=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjIzID0+IDczMTg=\n,HTML_40_50,HTML_MESSAGE
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17727 invoked from network); 23 Jan 2012 17:56:13 -0000
Received: from m15-23.126.com (HELO m15-23.126.com) (220.181.15.23)
	by server-12.tower-216.messagelabs.com with SMTP;
	23 Jan 2012 17:56:13 -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=IDVx3e0ITJwVFj7
	bCWaHE5h8QxMFYVHgs7f9wutIvoo=; b=EhmoHCea+/fvyjI4h4aOYT+o/Nby5k8
	KlpfTxociB+pQ4ex3dwpRjSY88qWeCnZt6Mr7OTzMDztppAUShGj7brugEmPRXLs
	iHg7RWI/yBpVIkJt6QKp3IqlkYN8U+4UXpbFxinDCH3RWjwVVmZYTSj1hugVmEoR
	2SSbu/ybSDzI=
Received: from hxkhust ( [111.172.53.94] ) by ajax-webmail-wmsvr23
	(Coremail) ; Tue, 24 Jan 2012 01:56:10 +0800 (CST)
Date: Tue, 24 Jan 2012 01:56:10 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: "Tim Deegan" <tim@xen.org>
Message-ID: <21ab2d2d.22ed.1350bb5fdad.Coremail.hxkhust@126.com>
In-Reply-To: <20120119110726.GB66164@ocelot.phlegethon.org>
References: <20120119110726.GB66164@ocelot.phlegethon.org>
	<f11ec12.21ca.134d4904a11.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [111.172.53.94]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: Ky6BHGZvb3Rlcl9odG09MzMwMjo4MQ==
X-CM-TRANSID: F8qowGCJL0E7nx1PIE4DAA--.16922W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbi4xs+BU3LhqPMOwAAsX
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] A Problem with Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8294801733167030195=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8294801733167030195==
Content-Type: multipart/alternative; 
	boundary="----=_Part_23460_835926944.1327341370797"

------=_Part_23460_835926944.1327341370797
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

I am terribly sorry for the mistake that i made in my last latter.I express my question incorrectly.
The following is the correct one:
 
On a physical machine with xen virtualization platform installed ,VM A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM A and VM B's virtual disk image files are based on VM C's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM A get a page data from VM C's virtual disk image file. After that ,VM B also need to get the same page data as VM A got just now.Under this situation, does VMM copy the page data from VM A's memory to VM B's memory or get the page data from VM C's virtual disk image file in the physical disk again? 

At 2012-01-19 19:07:38,"Tim Deegan" <tim@xen.org> wrote:
>Hi, 
>At 08:55 +0800 on 13 Jan (1326444953), hxkhust wrote:
>> On a physical machine with xen virtualization platform installed ,VM
>>  A,VM B are VM C's virtual disks are all image files,among which VM A
>>  and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
>>  format. And VM B and VM C's virtual disk image files are based on VM
>>  A's virtual disk image file.Now these three VMs are running on the
>>  same physical machine with xen installed. 
>> 
>>  In the process of running VM B get a page data from VM A's virtual
>>  disk image file. After that ,VM C also need to get the same page data
>>  as VM B got just now.Under this situation, does VMM copy the page
>>  data from VM B's memory to VM C's memory or get the page data from VM
>>  A's virtual disk image file in the physical disk again?
>
>Since VM C's disk is not QCOW, reads will always come directly from VM
>C's image -- never from VM A's image (since the tools wouldn't know how
>to do that) and never by copying from VM B.
>
>Tim.

------=_Part_23460_835926944.1327341370797
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>I am terribly sorry for the mistake that i made in my last latter.I express my question incorrectly.</DIV>
<DIV>The&nbsp;following is the correct one:</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>On a physical machine&nbsp;with xen virtualization platform&nbsp;installed ,VM&nbsp;A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM&nbsp;A and VM B's virtual disk image files are based on VM C's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM&nbsp;A get a page data from VM C's virtual disk image file. After that ,VM&nbsp;B also need to get the same page data as VM&nbsp;A got just now.Under this situation, does VMM copy the page data from VM A's memory to VM B's memory or get the page data from&nbsp;VM C's virtual disk image file in the physical disk again?&nbsp;</DIV></DIV>
<DIV><BR>At&nbsp;2012-01-19&nbsp;19:07:38,"Tim&nbsp;Deegan"&nbsp;&lt;tim@xen.org&gt;&nbsp;wrote:<BR>&gt;Hi,&nbsp;<BR>&gt;At&nbsp;08:55&nbsp;+0800&nbsp;on&nbsp;13&nbsp;Jan&nbsp;(1326444953),&nbsp;hxkhust&nbsp;wrote:<BR>&gt;&gt;&nbsp;On&nbsp;a&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;virtualization&nbsp;platform&nbsp;installed&nbsp;,VM<BR>&gt;&gt;&nbsp;&nbsp;A,VM&nbsp;B&nbsp;are&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;all&nbsp;image&nbsp;files,among&nbsp;which&nbsp;VM&nbsp;A<BR>&gt;&gt;&nbsp;&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;QCOW2&nbsp;format&nbsp;and&nbsp;VM&nbsp;C's&nbsp;disk&nbsp;is&nbsp;RAW<BR>&gt;&gt;&nbsp;&nbsp;format.&nbsp;And&nbsp;VM&nbsp;B&nbsp;and&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;files&nbsp;are&nbsp;based&nbsp;on&nbsp;VM<BR>&gt;&gt;&nbsp;&nbsp;A's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file.Now&nbsp;these&nbsp;three&nbsp;VMs&nbsp;are&nbsp;running&nbsp;on&nbsp;the<BR>&gt;&gt;&nbsp;&nbsp;same&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;installed.&nbsp;<BR>&gt;&gt;&nbsp;<BR>&gt;&gt;&nbsp;&nbsp;In&nbsp;the&nbsp;process&nbsp;of&nbsp;running&nbsp;VM&nbsp;B&nbsp;get&nbsp;a&nbsp;page&nbsp;data&nbsp;from&nbsp;VM&nbsp;A's&nbsp;virtual<BR>&gt;&gt;&nbsp;&nbsp;disk&nbsp;image&nbsp;file.&nbsp;After&nbsp;that&nbsp;,VM&nbsp;C&nbsp;also&nbsp;need&nbsp;to&nbsp;get&nbsp;the&nbsp;same&nbsp;page&nbsp;data<BR>&gt;&gt;&nbsp;&nbsp;as&nbsp;VM&nbsp;B&nbsp;got&nbsp;just&nbsp;now.Under&nbsp;this&nbsp;situation,&nbsp;does&nbsp;VMM&nbsp;copy&nbsp;the&nbsp;page<BR>&gt;&gt;&nbsp;&nbsp;data&nbsp;from&nbsp;VM&nbsp;B's&nbsp;memory&nbsp;to&nbsp;VM&nbsp;C's&nbsp;memory&nbsp;or&nbsp;get&nbsp;the&nbsp;page&nbsp;data&nbsp;from&nbsp;VM<BR>&gt;&gt;&nbsp;&nbsp;A's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file&nbsp;in&nbsp;the&nbsp;physical&nbsp;disk&nbsp;again?<BR>&gt;<BR>&gt;Since&nbsp;VM&nbsp;C's&nbsp;disk&nbsp;is&nbsp;not&nbsp;QCOW,&nbsp;reads&nbsp;will&nbsp;always&nbsp;come&nbsp;directly&nbsp;from&nbsp;VM<BR>&gt;C's&nbsp;image&nbsp;--&nbsp;never&nbsp;from&nbsp;VM&nbsp;A's&nbsp;image&nbsp;(since&nbsp;the&nbsp;tools&nbsp;wouldn't&nbsp;know&nbsp;how<BR>&gt;to&nbsp;do&nbsp;that)&nbsp;and&nbsp;never&nbsp;by&nbsp;copying&nbsp;from&nbsp;VM&nbsp;B.<BR>&gt;<BR>&gt;Tim.<BR></DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_23460_835926944.1327341370797--



--===============8294801733167030195==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8294801733167030195==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:09:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOKN-0001ik-G2; Mon, 23 Jan 2012 18:09:11 +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 1RpOKM-0001if-GD
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:09:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327342142!10293516!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28893 invoked from network); 23 Jan 2012 18:09:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 18:09:03 -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
	q0NI8JP7031877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:08:20 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
	q0NI8H7T017031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:08:17 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
	q0NI8Gbn003215; Mon, 23 Jan 2012 12:08:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:08:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A5ACC40157; Mon, 23 Jan 2012 13:06:01 -0500 (EST)
Date: Mon, 23 Jan 2012 13:06:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>, gregkh@suse.de,
	linux-kernel@vger.kernel.org, kay.sievers@vrfy.org, bp@amd64.org,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org,
	lenb@kernel.org
Message-ID: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F1DA214.00D3,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When I bring a CPU down in a guest (which should be the same as bringing a
CPU down using the ACPI framework), I get this:

[   14.484206] SMP alternatives: switching to UP code
[   14.514287] ------------[ cut here ]------------
[   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
[   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
[   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
[   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
[   14.514586] Call Trace:
[   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
[   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
[   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
[   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
[   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
[   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
[   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
[   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
[   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
[   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
[   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
[   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
[   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
[   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
[   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
[   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
[   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
[   14.515094] ---[ end trace 8f70af51a2e2611f ]---

Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Mon Jan 16 14:40:28 2012 -0800

    mce: fix warning messages about static struct mce_device
"

it looks like the corret fix is to make the 'cpu_devices' in
arch/x86/kernel/topology.c to be changed to be more dynamic
(or perhaps have an empty release function)?

Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
the privilige of being the first? Oh, I hadn't done a full bisection
but v3.2 does not have this.

The guest config is quite simple:
extra="console=hvc0 debug earlyprintk=xen memblock=debug"
kernel="/mnt/lab/bootstrap-x86_64/vmlinuz"
ramdisk="/mnt/lab/bootstrap-x86_64/initramfs.cpio.gz"
memory=1024
maxmem=2048
vcpus=2
name="bootstrap-x86_64"
on_crash="preserve"
vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:09:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:09:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOKN-0001ik-G2; Mon, 23 Jan 2012 18:09:11 +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 1RpOKM-0001if-GD
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:09:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327342142!10293516!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28893 invoked from network); 23 Jan 2012 18:09:03 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 18:09:03 -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
	q0NI8JP7031877
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:08:20 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
	q0NI8H7T017031
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:08:17 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
	q0NI8Gbn003215; Mon, 23 Jan 2012 12:08:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:08:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id A5ACC40157; Mon, 23 Jan 2012 13:06:01 -0500 (EST)
Date: Mon, 23 Jan 2012 13:06:01 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>, gregkh@suse.de,
	linux-kernel@vger.kernel.org, kay.sievers@vrfy.org, bp@amd64.org,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org,
	lenb@kernel.org
Message-ID: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F1DA214.00D3,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When I bring a CPU down in a guest (which should be the same as bringing a
CPU down using the ACPI framework), I get this:

[   14.484206] SMP alternatives: switching to UP code
[   14.514287] ------------[ cut here ]------------
[   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
[   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
[   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
[   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
[   14.514586] Call Trace:
[   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
[   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
[   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
[   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
[   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
[   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
[   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
[   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
[   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
[   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
[   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
[   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
[   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
[   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
[   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
[   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
[   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
[   14.515094] ---[ end trace 8f70af51a2e2611f ]---

Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
Author: Greg Kroah-Hartman <gregkh@suse.de>
Date:   Mon Jan 16 14:40:28 2012 -0800

    mce: fix warning messages about static struct mce_device
"

it looks like the corret fix is to make the 'cpu_devices' in
arch/x86/kernel/topology.c to be changed to be more dynamic
(or perhaps have an empty release function)?

Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
the privilige of being the first? Oh, I hadn't done a full bisection
but v3.2 does not have this.

The guest config is quite simple:
extra="console=hvc0 debug earlyprintk=xen memblock=debug"
kernel="/mnt/lab/bootstrap-x86_64/vmlinuz"
ramdisk="/mnt/lab/bootstrap-x86_64/initramfs.cpio.gz"
memory=1024
maxmem=2048
vcpus=2
name="bootstrap-x86_64"
on_crash="preserve"
vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:11:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOLs-0001mY-08; Mon, 23 Jan 2012 18:10:44 +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 1RpOLq-0001mF-9q
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:10:42 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327342223!8032818!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 12556 invoked from network); 23 Jan 2012 18:10:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	23 Jan 2012 18:10:27 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74960281; Mon, 23 Jan 2012 19:10:21 +0100
Message-ID: <1327342219.2476.9.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 19:10:19 +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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv2 0 of 2] libxl: Extend CPU affinity
 specification and enable it in config 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: multipart/mixed; boundary="===============8160091719787046191=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8160091719787046191==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ewGwehvUI1EPEsxt+4Xs"


--=-ewGwehvUI1EPEsxt+4Xs
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Everyone,

This series slightly extends the current support for specifying CPU
affinity, basically adding the support for "^<cpuid>" kind of entries
(i.e., "^6", meaning "not on CPU#6), and enables doing so in a VM's
config file, like it (probably?) was possible with `xm'.

With respect to v1:
* Reworked (hopefully improved) the parsing of the cpu-pin string
* Removed forward declarations (as asked during review)
* Added some helper functions (as asked during review)
* Put a saner default for cpu-pinning for libxl (as asked during review)

Thanks and Regards,
Dario

--
generalize-vcpupin-parsig.patch
support-cpus-par-in-config-file.patch
--=20
tools/libxl/libxl.c         |   14 +++++++++
 tools/libxl/libxl.h         |    2 +
 tools/libxl/libxl_create.c  |    3 +
 tools/libxl/libxl_dom.c     |    1 +
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/libxl_utils.h   |   14 +++++++++
 tools/libxl/xl_cmdimpl.c    |  235 +++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------=
----------------------------------------
 7 files changed, 190 insertions(+), 80 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-ewGwehvUI1EPEsxt+4Xs
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)

iEYEABECAAYFAk8doowACgkQk4XaBE3IOsSiYwCfatex0mR/hoJYraChwBdMQSDh
MqkAnirU1sQeXGZ3EATkqv/nv0ZyJZlN
=uk3T
-----END PGP SIGNATURE-----

--=-ewGwehvUI1EPEsxt+4Xs--



--===============8160091719787046191==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8160091719787046191==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:11:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:11:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOLs-0001mY-08; Mon, 23 Jan 2012 18:10:44 +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 1RpOLq-0001mF-9q
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:10:42 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327342223!8032818!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 12556 invoked from network); 23 Jan 2012 18:10:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-10.tower-21.messagelabs.com with SMTP;
	23 Jan 2012 18:10:27 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74960281; Mon, 23 Jan 2012 19:10:21 +0100
Message-ID: <1327342219.2476.9.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 19:10:19 +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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv2 0 of 2] libxl: Extend CPU affinity
 specification and enable it in config 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: multipart/mixed; boundary="===============8160091719787046191=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============8160091719787046191==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-ewGwehvUI1EPEsxt+4Xs"


--=-ewGwehvUI1EPEsxt+4Xs
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Everyone,

This series slightly extends the current support for specifying CPU
affinity, basically adding the support for "^<cpuid>" kind of entries
(i.e., "^6", meaning "not on CPU#6), and enables doing so in a VM's
config file, like it (probably?) was possible with `xm'.

With respect to v1:
* Reworked (hopefully improved) the parsing of the cpu-pin string
* Removed forward declarations (as asked during review)
* Added some helper functions (as asked during review)
* Put a saner default for cpu-pinning for libxl (as asked during review)

Thanks and Regards,
Dario

--
generalize-vcpupin-parsig.patch
support-cpus-par-in-config-file.patch
--=20
tools/libxl/libxl.c         |   14 +++++++++
 tools/libxl/libxl.h         |    2 +
 tools/libxl/libxl_create.c  |    3 +
 tools/libxl/libxl_dom.c     |    1 +
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/libxl_utils.h   |   14 +++++++++
 tools/libxl/xl_cmdimpl.c    |  235 +++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------=
----------------------------------------
 7 files changed, 190 insertions(+), 80 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-ewGwehvUI1EPEsxt+4Xs
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)

iEYEABECAAYFAk8doowACgkQk4XaBE3IOsSiYwCfatex0mR/hoJYraChwBdMQSDh
MqkAnirU1sQeXGZ3EATkqv/nv0ZyJZlN
=uk3T
-----END PGP SIGNATURE-----

--=-ewGwehvUI1EPEsxt+4Xs--



--===============8160091719787046191==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8160091719787046191==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:15:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOPp-000220-0U; Mon, 23 Jan 2012 18:14:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@suse.de>) id 1RpOPm-00021g-Qo
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:14:47 +0000
X-Env-Sender: gregkh@suse.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327342479!10356748!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24400 invoked from network); 23 Jan 2012 18:14:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 18:14:40 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 2E16B8FA98;
	Mon, 23 Jan 2012 19:14:38 +0100 (CET)
Date: Mon, 23 Jan 2012 10:13:57 -0800
From: Greg KH <gregkh@suse.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120123181357.GA27538@suse.de>
References: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: x86@kernel.org, kay.sievers@vrfy.org, linux-kernel@vger.kernel.org,
	bp@amd64.org, mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
> 
> [   14.484206] SMP alternatives: switching to UP code
> [   14.514287] ------------[ cut here ]------------
> [   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [   14.514586] Call Trace:
> [   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
> [   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
> [   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
> [   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
> [   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
> [   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [   14.515094] ---[ end trace 8f70af51a2e2611f ]---
> 
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date:   Mon Jan 16 14:40:28 2012 -0800
> 
>     mce: fix warning messages about static struct mce_device
> "
> 
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?

{sigh}

Yes, that's the correct fix, I'll do the same type of change I did for
the MCE code here as well.

Sorry we missed this one previously.

I'll get this fixed soon.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:15:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:15:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOPp-000220-0U; Mon, 23 Jan 2012 18:14:49 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@suse.de>) id 1RpOPm-00021g-Qo
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:14:47 +0000
X-Env-Sender: gregkh@suse.de
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327342479!10356748!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24400 invoked from network); 23 Jan 2012 18:14:40 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 18:14:40 -0000
Received: from relay1.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 2E16B8FA98;
	Mon, 23 Jan 2012 19:14:38 +0100 (CET)
Date: Mon, 23 Jan 2012 10:13:57 -0800
From: Greg KH <gregkh@suse.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120123181357.GA27538@suse.de>
References: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: x86@kernel.org, kay.sievers@vrfy.org, linux-kernel@vger.kernel.org,
	bp@amd64.org, mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>,
	xen-devel@lists.xensource.com, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
> 
> [   14.484206] SMP alternatives: switching to UP code
> [   14.514287] ------------[ cut here ]------------
> [   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [   14.514586] Call Trace:
> [   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
> [   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
> [   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
> [   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
> [   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
> [   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [   14.515094] ---[ end trace 8f70af51a2e2611f ]---
> 
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date:   Mon Jan 16 14:40:28 2012 -0800
> 
>     mce: fix warning messages about static struct mce_device
> "
> 
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?

{sigh}

Yes, that's the correct fix, I'll do the same type of change I did for
the MCE code here as well.

Sorry we missed this one previously.

I'll get this fixed soon.

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:21:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18: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 1RpOW9-0002Qe-S5; Mon, 23 Jan 2012 18:21:21 +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 1RpOW7-0002QK-VA
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:21:20 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327342872!12095312!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 24764 invoked from network); 23 Jan 2012 18:21:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-182.messagelabs.com with SMTP;
	23 Jan 2012 18:21:13 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74960474; Mon, 23 Jan 2012 19:21:12 +0100
Message-ID: <1327342871.2476.14.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 19:21:11 +0100
In-Reply-To: <1327342219.2476.9.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv2 1 of 2] libxl: extend pCPUs specification for
	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0333325683652929383=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0333325683652929383==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HSJ4rRTmFqKvjNgQmyFS"


--=-HSJ4rRTmFqKvjNgQmyFS
Content-Type: multipart/mixed; boundary="=-uCoRyQsJyRl6p9yJMpZ+"


--=-uCoRyQsJyRl6p9yJMpZ+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Allow for "^<cpuid>" syntax while specifying the pCPUs list
during a vcpu-pin. This enables doing the following:

 xl vcpu-pin 1 1 0-4,^2

and achieving:

 xl vcpu-list
 Name                                ID  VCPU   CPU State   Time(s) CPU Aff=
inity
 ...
 Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
 ...

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 370924e204dc tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Mon Jan 23 15:10:43 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Mon Jan 23 18:02:41 2012 +0000
@@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
+#define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
+                                             if (libxl_cpumap_test(&(m), v=
))
=20
 int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
=20
diff -r 370924e204dc tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:41 2012 +0000
@@ -3503,13 +3503,77 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb, *saveptr =3D NULL;
+    int i, ret =3D 0;
+
+    if (!strcmp(cpu, "all")) {
+        memset(cpumap->map, -1, cpumap->size);
+        return 0;
+    }
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+        return ENOMEM;
+    }
+
+    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
+         toka =3D strtok_r(NULL, ",", &saveptr)) {
+        if (*toka =3D=3D '^') {
+            /* Add the cpu to the removal list */
+            toka++;
+            cpuida =3D strtoul(toka, &endptr, 10);
+            if (toka =3D=3D endptr) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                ret =3D EINVAL;
+                goto vcpp_out;
+            }
+            libxl_cpumap_set(&exclude_cpumap, cpuida);
+        } else {
+            /* Valid (range of) cpu(s) */
+            cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
+            if (endptr =3D=3D toka) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                ret =3D EINVAL;
+                goto vcpp_out;
+            }
+            if (*endptr =3D=3D '-') {
+                tokb =3D endptr + 1;
+                cpuidb =3D strtoul(tokb, &endptr, 10);
+                if (endptr =3D=3D tokb || cpuida > cpuidb) {
+                    fprintf(stderr, "Error: Invalid argument.\n");
+                    ret =3D EINVAL;
+                    goto vcpp_out;
+                }
+            }
+            while (cpuida <=3D cpuidb) {
+                libxl_cpumap_set(cpumap, cpuida);
+                cpuida++;
+            }
+        }
+    }
+
+    /* Clear all the cpus from the removal list */
+    libxl_for_each_set_cpu(i, exclude_cpumap) {
+        libxl_cpumap_reset(cpumap, i);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return ret;
+}
+
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_cpumap cpumap;
=20
-    uint32_t vcpuid, cpuida, cpuidb;
-    char *endptr, *toka, *tokb;
+    uint32_t vcpuid;
+    char *endptr;
     int i, nb_vcpu;
=20
     vcpuid =3D strtoul(vcpu, &endptr, 10);
@@ -3526,32 +3590,9 @@ static void vcpupin(const char *d, const
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
-    if (strcmp(cpu, "all")) {
-        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
-            cpuida =3D strtoul(toka, &endptr, 10);
-            if (toka =3D=3D endptr) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                goto vcpupin_out1;
-            }
-            if (*endptr =3D=3D '-') {
-                tokb =3D endptr + 1;
-                cpuidb =3D strtoul(tokb, &endptr, 10);
-                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
-                    fprintf(stderr, "Error: Invalid argument.\n");
-                    goto vcpupin_out1;
-                }
-                while (cpuida <=3D cpuidb) {
-                    libxl_cpumap_set(&cpumap, cpuida);
-                    ++cpuida;
-                }
-            } else {
-                libxl_cpumap_set(&cpumap, cpuida);
-            }
-        }
-    }
-    else {
-        memset(cpumap.map, -1, cpumap.size);
-    }
+
+    if (vcpupin_parse(cpu, &cpumap))
+        goto vcpupin_out1;
=20
     if (vcpuid !=3D -1) {
         if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) =3D=3D -1)=
 {

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-uCoRyQsJyRl6p9yJMpZ+
Content-Disposition: attachment; filename="generalize-vcpupin-parsig.patch"
Content-Type: text/x-patch; name="generalize-vcpupin-parsig.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDM3MDkyNGUyMDRkYzI5ZTEyY2Q4MDdkZDcz
MDk3NGQ2YjJiYzUzZDMNCmxpYnhsOiBleHRlbmQgcENQVXMgc3BlY2lmaWNhdGlvbiBmb3IgdmNw
dS1waW4uDQoNCkFsbG93IGZvciAiXjxjcHVpZD4iIHN5bnRheCB3aGlsZSBzcGVjaWZ5aW5nIHRo
ZSBwQ1BVcyBsaXN0DQpkdXJpbmcgYSB2Y3B1LXBpbi4gVGhpcyBlbmFibGVzIGRvaW5nIHRoZSBm
b2xsb3dpbmc6DQoNCiB4bCB2Y3B1LXBpbiAxIDEgMC00LF4yDQoNCmFuZCBhY2hpZXZpbmc6DQoN
CiB4bCB2Y3B1LWxpc3QNCiBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAg
VkNQVSAgIENQVSBTdGF0ZSAgIFRpbWUocykgQ1BVIEFmZmluaXR5DQogLi4uDQogU3F1ZWV6ZV9w
diAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgIDEgICAgMyAgIC1iLSAgICAgICAyLjQg
IDAtMSwzLTQNCiAuLi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZh
Z2dpb2xpQGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgMzcwOTI0ZTIwNGRjIHRvb2xzL2xpYnhsL2xp
YnhsX3V0aWxzLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgJTW9uIEphbiAyMyAx
NToxMDo0MyAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF91dGlscy5oCU1vbiBK
YW4gMjMgMTg6MDI6NDEgMjAxMiArMDAwMA0KQEAgLTcxLDYgKzcxLDggQEAgaW50IGxpYnhsX2Nw
dW1hcF90ZXN0KGxpYnhsX2NwdW1hcCAqY3B1bQ0KIHZvaWQgbGlieGxfY3B1bWFwX3NldChsaWJ4
bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4bF9jcHVtYXBfcmVzZXQobGli
eGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KICNkZWZpbmUgbGlieGxfZm9yX2VhY2hfY3B1
KHZhciwgbWFwKSBmb3IgKHZhciA9IDA7IHZhciA8IChtYXApLnNpemUgKiA4OyB2YXIrKykNCisj
ZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUodiwgbSkgZm9yICh2ID0gMDsgdiA8IChtKS5z
aXplICogODsgdisrKSBcDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKGxpYnhsX2NwdW1hcF90ZXN0KCYobSksIHYpKQ0KIA0KIGludCBsaWJ4bF9jcHVh
cnJheV9hbGxvYyhsaWJ4bF9jdHggKmN0eCwgbGlieGxfY3B1YXJyYXkgKmNwdWFycmF5KTsNCiAN
CmRpZmYgLXIgMzcwOTI0ZTIwNGRjIHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYw0KLS0tIGEvdG9v
bHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBKYW4gMjMgMTU6MTA6NDMgMjAxMiArMDAwMA0KKysr
IGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBKYW4gMjMgMTg6MDI6NDEgMjAxMiArMDAw
MA0KQEAgLTM1MDMsMTMgKzM1MDMsNzcgQEAgaW50IG1haW5fdmNwdWxpc3QoaW50IGFyZ2MsIGNo
YXIgKiphcmd2KQ0KICAgICByZXR1cm4gMDsNCiB9DQogDQorc3RhdGljIGludCB2Y3B1cGluX3Bh
cnNlKGNoYXIgKmNwdSwgbGlieGxfY3B1bWFwICpjcHVtYXApDQorew0KKyAgICBsaWJ4bF9jcHVt
YXAgZXhjbHVkZV9jcHVtYXA7DQorICAgIHVpbnQzMl90IGNwdWlkYSwgY3B1aWRiOw0KKyAgICBj
aGFyICplbmRwdHIsICp0b2thLCAqdG9rYiwgKnNhdmVwdHIgPSBOVUxMOw0KKyAgICBpbnQgaSwg
cmV0ID0gMDsNCisNCisgICAgaWYgKCFzdHJjbXAoY3B1LCAiYWxsIikpIHsNCisgICAgICAgIG1l
bXNldChjcHVtYXAtPm1hcCwgLTEsIGNwdW1hcC0+c2l6ZSk7DQorICAgICAgICByZXR1cm4gMDsN
CisgICAgfQ0KKw0KKyAgICBpZiAobGlieGxfY3B1bWFwX2FsbG9jKGN0eCwgJmV4Y2x1ZGVfY3B1
bWFwKSkgew0KKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogRmFpbGVkIHRvIGFsbG9j
YXRlIGNwdW1hcC5cbiIpOw0KKyAgICAgICAgcmV0dXJuIEVOT01FTTsNCisgICAgfQ0KKw0KKyAg
ICBmb3IgKHRva2EgPSBzdHJ0b2tfcihjcHUsICIsIiwgJnNhdmVwdHIpOyB0b2thOw0KKyAgICAg
ICAgIHRva2EgPSBzdHJ0b2tfcihOVUxMLCAiLCIsICZzYXZlcHRyKSkgew0KKyAgICAgICAgaWYg
KCp0b2thID09ICdeJykgew0KKyAgICAgICAgICAgIC8qIEFkZCB0aGUgY3B1IHRvIHRoZSByZW1v
dmFsIGxpc3QgKi8NCisgICAgICAgICAgICB0b2thKys7DQorICAgICAgICAgICAgY3B1aWRhID0g
c3RydG91bCh0b2thLCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAgaWYgKHRva2EgPT0gZW5k
cHRyKSB7DQorICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFsaWQg
YXJndW1lbnQuXG4iKTsNCisgICAgICAgICAgICAgICAgcmV0ID0gRUlOVkFMOw0KKyAgICAgICAg
ICAgICAgICBnb3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgICAgIH0NCisgICAgICAgICAgICBsaWJ4
bF9jcHVtYXBfc2V0KCZleGNsdWRlX2NwdW1hcCwgY3B1aWRhKTsNCisgICAgICAgIH0gZWxzZSB7
DQorICAgICAgICAgICAgLyogVmFsaWQgKHJhbmdlIG9mKSBjcHUocykgKi8NCisgICAgICAgICAg
ICBjcHVpZGEgPSBjcHVpZGIgPSBzdHJ0b3VsKHRva2EsICZlbmRwdHIsIDEwKTsNCisgICAgICAg
ICAgICBpZiAoZW5kcHRyID09IHRva2EpIHsNCisgICAgICAgICAgICAgICAgZnByaW50ZihzdGRl
cnIsICJFcnJvcjogSW52YWxpZCBhcmd1bWVudC5cbiIpOw0KKyAgICAgICAgICAgICAgICByZXQg
PSBFSU5WQUw7DQorICAgICAgICAgICAgICAgIGdvdG8gdmNwcF9vdXQ7DQorICAgICAgICAgICAg
fQ0KKyAgICAgICAgICAgIGlmICgqZW5kcHRyID09ICctJykgew0KKyAgICAgICAgICAgICAgICB0
b2tiID0gZW5kcHRyICsgMTsNCisgICAgICAgICAgICAgICAgY3B1aWRiID0gc3RydG91bCh0b2ti
LCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAgICAgIGlmIChlbmRwdHIgPT0gdG9rYiB8fCBj
cHVpZGEgPiBjcHVpZGIpIHsNCisgICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAi
RXJyb3I6IEludmFsaWQgYXJndW1lbnQuXG4iKTsNCisgICAgICAgICAgICAgICAgICAgIHJldCA9
IEVJTlZBTDsNCisgICAgICAgICAgICAgICAgICAgIGdvdG8gdmNwcF9vdXQ7DQorICAgICAgICAg
ICAgICAgIH0NCisgICAgICAgICAgICB9DQorICAgICAgICAgICAgd2hpbGUgKGNwdWlkYSA8PSBj
cHVpZGIpIHsNCisgICAgICAgICAgICAgICAgbGlieGxfY3B1bWFwX3NldChjcHVtYXAsIGNwdWlk
YSk7DQorICAgICAgICAgICAgICAgIGNwdWlkYSsrOw0KKyAgICAgICAgICAgIH0NCisgICAgICAg
IH0NCisgICAgfQ0KKw0KKyAgICAvKiBDbGVhciBhbGwgdGhlIGNwdXMgZnJvbSB0aGUgcmVtb3Zh
bCBsaXN0ICovDQorICAgIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUoaSwgZXhjbHVkZV9jcHVtYXAp
IHsNCisgICAgICAgIGxpYnhsX2NwdW1hcF9yZXNldChjcHVtYXAsIGkpOw0KKyAgICB9DQorDQor
dmNwcF9vdXQ6DQorICAgIGxpYnhsX2NwdW1hcF9kaXNwb3NlKCZleGNsdWRlX2NwdW1hcCk7DQor
DQorICAgIHJldHVybiByZXQ7DQorfQ0KKw0KIHN0YXRpYyB2b2lkIHZjcHVwaW4oY29uc3QgY2hh
ciAqZCwgY29uc3QgY2hhciAqdmNwdSwgY2hhciAqY3B1KQ0KIHsNCiAgICAgbGlieGxfdmNwdWlu
Zm8gKnZjcHVpbmZvOw0KICAgICBsaWJ4bF9jcHVtYXAgY3B1bWFwOw0KIA0KLSAgICB1aW50MzJf
dCB2Y3B1aWQsIGNwdWlkYSwgY3B1aWRiOw0KLSAgICBjaGFyICplbmRwdHIsICp0b2thLCAqdG9r
YjsNCisgICAgdWludDMyX3QgdmNwdWlkOw0KKyAgICBjaGFyICplbmRwdHI7DQogICAgIGludCBp
LCBuYl92Y3B1Ow0KIA0KICAgICB2Y3B1aWQgPSBzdHJ0b3VsKHZjcHUsICZlbmRwdHIsIDEwKTsN
CkBAIC0zNTI2LDMyICszNTkwLDkgQEAgc3RhdGljIHZvaWQgdmNwdXBpbihjb25zdCBjaGFyICpk
LCBjb25zdA0KICAgICBpZiAobGlieGxfY3B1bWFwX2FsbG9jKGN0eCwgJmNwdW1hcCkpIHsNCiAg
ICAgICAgIGdvdG8gdmNwdXBpbl9vdXQ7DQogICAgIH0NCi0gICAgaWYgKHN0cmNtcChjcHUsICJh
bGwiKSkgew0KLSAgICAgICAgZm9yICh0b2thID0gc3RydG9rKGNwdSwgIiwiKSwgaSA9IDA7IHRv
a2E7IHRva2EgPSBzdHJ0b2soTlVMTCwgIiwiKSwgKytpKSB7DQotICAgICAgICAgICAgY3B1aWRh
ID0gc3RydG91bCh0b2thLCAmZW5kcHRyLCAxMCk7DQotICAgICAgICAgICAgaWYgKHRva2EgPT0g
ZW5kcHRyKSB7DQotICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFs
aWQgYXJndW1lbnQuXG4iKTsNCi0gICAgICAgICAgICAgICAgZ290byB2Y3B1cGluX291dDE7DQot
ICAgICAgICAgICAgfQ0KLSAgICAgICAgICAgIGlmICgqZW5kcHRyID09ICctJykgew0KLSAgICAg
ICAgICAgICAgICB0b2tiID0gZW5kcHRyICsgMTsNCi0gICAgICAgICAgICAgICAgY3B1aWRiID0g
c3RydG91bCh0b2tiLCAmZW5kcHRyLCAxMCk7DQotICAgICAgICAgICAgICAgIGlmICgodG9rYiA9
PSBlbmRwdHIpIHx8IChjcHVpZGEgPiBjcHVpZGIpKSB7DQotICAgICAgICAgICAgICAgICAgICBm
cHJpbnRmKHN0ZGVyciwgIkVycm9yOiBJbnZhbGlkIGFyZ3VtZW50LlxuIik7DQotICAgICAgICAg
ICAgICAgICAgICBnb3RvIHZjcHVwaW5fb3V0MTsNCi0gICAgICAgICAgICAgICAgfQ0KLSAgICAg
ICAgICAgICAgICB3aGlsZSAoY3B1aWRhIDw9IGNwdWlkYikgew0KLSAgICAgICAgICAgICAgICAg
ICAgbGlieGxfY3B1bWFwX3NldCgmY3B1bWFwLCBjcHVpZGEpOw0KLSAgICAgICAgICAgICAgICAg
ICAgKytjcHVpZGE7DQotICAgICAgICAgICAgICAgIH0NCi0gICAgICAgICAgICB9IGVsc2Ugew0K
LSAgICAgICAgICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0KCZjcHVtYXAsIGNwdWlkYSk7DQotICAg
ICAgICAgICAgfQ0KLSAgICAgICAgfQ0KLSAgICB9DQotICAgIGVsc2Ugew0KLSAgICAgICAgbWVt
c2V0KGNwdW1hcC5tYXAsIC0xLCBjcHVtYXAuc2l6ZSk7DQotICAgIH0NCisNCisgICAgaWYgKHZj
cHVwaW5fcGFyc2UoY3B1LCAmY3B1bWFwKSkNCisgICAgICAgIGdvdG8gdmNwdXBpbl9vdXQxOw0K
IA0KICAgICBpZiAodmNwdWlkICE9IC0xKSB7DQogICAgICAgICBpZiAobGlieGxfc2V0X3ZjcHVh
ZmZpbml0eShjdHgsIGRvbWlkLCB2Y3B1aWQsICZjcHVtYXApID09IC0xKSB7DQo=


--=-uCoRyQsJyRl6p9yJMpZ+--

--=-HSJ4rRTmFqKvjNgQmyFS
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)

iEYEABECAAYFAk8dpRcACgkQk4XaBE3IOsTtBgCfTPTmZxlAcq2C8O3QDs26GTbZ
QrYAnAi61uScwF0fdN8L1d1wPNgIQIbC
=lNcC
-----END PGP SIGNATURE-----

--=-HSJ4rRTmFqKvjNgQmyFS--



--===============0333325683652929383==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0333325683652929383==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:21:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18: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 1RpOW9-0002Qe-S5; Mon, 23 Jan 2012 18:21:21 +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 1RpOW7-0002QK-VA
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:21:20 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327342872!12095312!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 24764 invoked from network); 23 Jan 2012 18:21:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-5.tower-182.messagelabs.com with SMTP;
	23 Jan 2012 18:21:13 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74960474; Mon, 23 Jan 2012 19:21:12 +0100
Message-ID: <1327342871.2476.14.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 19:21:11 +0100
In-Reply-To: <1327342219.2476.9.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv2 1 of 2] libxl: extend pCPUs specification for
	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0333325683652929383=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0333325683652929383==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-HSJ4rRTmFqKvjNgQmyFS"


--=-HSJ4rRTmFqKvjNgQmyFS
Content-Type: multipart/mixed; boundary="=-uCoRyQsJyRl6p9yJMpZ+"


--=-uCoRyQsJyRl6p9yJMpZ+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Allow for "^<cpuid>" syntax while specifying the pCPUs list
during a vcpu-pin. This enables doing the following:

 xl vcpu-pin 1 1 0-4,^2

and achieving:

 xl vcpu-list
 Name                                ID  VCPU   CPU State   Time(s) CPU Aff=
inity
 ...
 Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
 ...

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r 370924e204dc tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Mon Jan 23 15:10:43 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Mon Jan 23 18:02:41 2012 +0000
@@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
+#define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
+                                             if (libxl_cpumap_test(&(m), v=
))
=20
 int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
=20
diff -r 370924e204dc tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:41 2012 +0000
@@ -3503,13 +3503,77 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb, *saveptr =3D NULL;
+    int i, ret =3D 0;
+
+    if (!strcmp(cpu, "all")) {
+        memset(cpumap->map, -1, cpumap->size);
+        return 0;
+    }
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+        return ENOMEM;
+    }
+
+    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
+         toka =3D strtok_r(NULL, ",", &saveptr)) {
+        if (*toka =3D=3D '^') {
+            /* Add the cpu to the removal list */
+            toka++;
+            cpuida =3D strtoul(toka, &endptr, 10);
+            if (toka =3D=3D endptr) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                ret =3D EINVAL;
+                goto vcpp_out;
+            }
+            libxl_cpumap_set(&exclude_cpumap, cpuida);
+        } else {
+            /* Valid (range of) cpu(s) */
+            cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
+            if (endptr =3D=3D toka) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                ret =3D EINVAL;
+                goto vcpp_out;
+            }
+            if (*endptr =3D=3D '-') {
+                tokb =3D endptr + 1;
+                cpuidb =3D strtoul(tokb, &endptr, 10);
+                if (endptr =3D=3D tokb || cpuida > cpuidb) {
+                    fprintf(stderr, "Error: Invalid argument.\n");
+                    ret =3D EINVAL;
+                    goto vcpp_out;
+                }
+            }
+            while (cpuida <=3D cpuidb) {
+                libxl_cpumap_set(cpumap, cpuida);
+                cpuida++;
+            }
+        }
+    }
+
+    /* Clear all the cpus from the removal list */
+    libxl_for_each_set_cpu(i, exclude_cpumap) {
+        libxl_cpumap_reset(cpumap, i);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return ret;
+}
+
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_cpumap cpumap;
=20
-    uint32_t vcpuid, cpuida, cpuidb;
-    char *endptr, *toka, *tokb;
+    uint32_t vcpuid;
+    char *endptr;
     int i, nb_vcpu;
=20
     vcpuid =3D strtoul(vcpu, &endptr, 10);
@@ -3526,32 +3590,9 @@ static void vcpupin(const char *d, const
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
-    if (strcmp(cpu, "all")) {
-        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
-            cpuida =3D strtoul(toka, &endptr, 10);
-            if (toka =3D=3D endptr) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                goto vcpupin_out1;
-            }
-            if (*endptr =3D=3D '-') {
-                tokb =3D endptr + 1;
-                cpuidb =3D strtoul(tokb, &endptr, 10);
-                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
-                    fprintf(stderr, "Error: Invalid argument.\n");
-                    goto vcpupin_out1;
-                }
-                while (cpuida <=3D cpuidb) {
-                    libxl_cpumap_set(&cpumap, cpuida);
-                    ++cpuida;
-                }
-            } else {
-                libxl_cpumap_set(&cpumap, cpuida);
-            }
-        }
-    }
-    else {
-        memset(cpumap.map, -1, cpumap.size);
-    }
+
+    if (vcpupin_parse(cpu, &cpumap))
+        goto vcpupin_out1;
=20
     if (vcpuid !=3D -1) {
         if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) =3D=3D -1)=
 {

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-uCoRyQsJyRl6p9yJMpZ+
Content-Disposition: attachment; filename="generalize-vcpupin-parsig.patch"
Content-Type: text/x-patch; name="generalize-vcpupin-parsig.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IDM3MDkyNGUyMDRkYzI5ZTEyY2Q4MDdkZDcz
MDk3NGQ2YjJiYzUzZDMNCmxpYnhsOiBleHRlbmQgcENQVXMgc3BlY2lmaWNhdGlvbiBmb3IgdmNw
dS1waW4uDQoNCkFsbG93IGZvciAiXjxjcHVpZD4iIHN5bnRheCB3aGlsZSBzcGVjaWZ5aW5nIHRo
ZSBwQ1BVcyBsaXN0DQpkdXJpbmcgYSB2Y3B1LXBpbi4gVGhpcyBlbmFibGVzIGRvaW5nIHRoZSBm
b2xsb3dpbmc6DQoNCiB4bCB2Y3B1LXBpbiAxIDEgMC00LF4yDQoNCmFuZCBhY2hpZXZpbmc6DQoN
CiB4bCB2Y3B1LWxpc3QNCiBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAg
VkNQVSAgIENQVSBTdGF0ZSAgIFRpbWUocykgQ1BVIEFmZmluaXR5DQogLi4uDQogU3F1ZWV6ZV9w
diAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgIDEgICAgMyAgIC1iLSAgICAgICAyLjQg
IDAtMSwzLTQNCiAuLi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZh
Z2dpb2xpQGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgMzcwOTI0ZTIwNGRjIHRvb2xzL2xpYnhsL2xp
YnhsX3V0aWxzLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgJTW9uIEphbiAyMyAx
NToxMDo0MyAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF91dGlscy5oCU1vbiBK
YW4gMjMgMTg6MDI6NDEgMjAxMiArMDAwMA0KQEAgLTcxLDYgKzcxLDggQEAgaW50IGxpYnhsX2Nw
dW1hcF90ZXN0KGxpYnhsX2NwdW1hcCAqY3B1bQ0KIHZvaWQgbGlieGxfY3B1bWFwX3NldChsaWJ4
bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4bF9jcHVtYXBfcmVzZXQobGli
eGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KICNkZWZpbmUgbGlieGxfZm9yX2VhY2hfY3B1
KHZhciwgbWFwKSBmb3IgKHZhciA9IDA7IHZhciA8IChtYXApLnNpemUgKiA4OyB2YXIrKykNCisj
ZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUodiwgbSkgZm9yICh2ID0gMDsgdiA8IChtKS5z
aXplICogODsgdisrKSBcDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKGxpYnhsX2NwdW1hcF90ZXN0KCYobSksIHYpKQ0KIA0KIGludCBsaWJ4bF9jcHVh
cnJheV9hbGxvYyhsaWJ4bF9jdHggKmN0eCwgbGlieGxfY3B1YXJyYXkgKmNwdWFycmF5KTsNCiAN
CmRpZmYgLXIgMzcwOTI0ZTIwNGRjIHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYw0KLS0tIGEvdG9v
bHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBKYW4gMjMgMTU6MTA6NDMgMjAxMiArMDAwMA0KKysr
IGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBKYW4gMjMgMTg6MDI6NDEgMjAxMiArMDAw
MA0KQEAgLTM1MDMsMTMgKzM1MDMsNzcgQEAgaW50IG1haW5fdmNwdWxpc3QoaW50IGFyZ2MsIGNo
YXIgKiphcmd2KQ0KICAgICByZXR1cm4gMDsNCiB9DQogDQorc3RhdGljIGludCB2Y3B1cGluX3Bh
cnNlKGNoYXIgKmNwdSwgbGlieGxfY3B1bWFwICpjcHVtYXApDQorew0KKyAgICBsaWJ4bF9jcHVt
YXAgZXhjbHVkZV9jcHVtYXA7DQorICAgIHVpbnQzMl90IGNwdWlkYSwgY3B1aWRiOw0KKyAgICBj
aGFyICplbmRwdHIsICp0b2thLCAqdG9rYiwgKnNhdmVwdHIgPSBOVUxMOw0KKyAgICBpbnQgaSwg
cmV0ID0gMDsNCisNCisgICAgaWYgKCFzdHJjbXAoY3B1LCAiYWxsIikpIHsNCisgICAgICAgIG1l
bXNldChjcHVtYXAtPm1hcCwgLTEsIGNwdW1hcC0+c2l6ZSk7DQorICAgICAgICByZXR1cm4gMDsN
CisgICAgfQ0KKw0KKyAgICBpZiAobGlieGxfY3B1bWFwX2FsbG9jKGN0eCwgJmV4Y2x1ZGVfY3B1
bWFwKSkgew0KKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogRmFpbGVkIHRvIGFsbG9j
YXRlIGNwdW1hcC5cbiIpOw0KKyAgICAgICAgcmV0dXJuIEVOT01FTTsNCisgICAgfQ0KKw0KKyAg
ICBmb3IgKHRva2EgPSBzdHJ0b2tfcihjcHUsICIsIiwgJnNhdmVwdHIpOyB0b2thOw0KKyAgICAg
ICAgIHRva2EgPSBzdHJ0b2tfcihOVUxMLCAiLCIsICZzYXZlcHRyKSkgew0KKyAgICAgICAgaWYg
KCp0b2thID09ICdeJykgew0KKyAgICAgICAgICAgIC8qIEFkZCB0aGUgY3B1IHRvIHRoZSByZW1v
dmFsIGxpc3QgKi8NCisgICAgICAgICAgICB0b2thKys7DQorICAgICAgICAgICAgY3B1aWRhID0g
c3RydG91bCh0b2thLCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAgaWYgKHRva2EgPT0gZW5k
cHRyKSB7DQorICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFsaWQg
YXJndW1lbnQuXG4iKTsNCisgICAgICAgICAgICAgICAgcmV0ID0gRUlOVkFMOw0KKyAgICAgICAg
ICAgICAgICBnb3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgICAgIH0NCisgICAgICAgICAgICBsaWJ4
bF9jcHVtYXBfc2V0KCZleGNsdWRlX2NwdW1hcCwgY3B1aWRhKTsNCisgICAgICAgIH0gZWxzZSB7
DQorICAgICAgICAgICAgLyogVmFsaWQgKHJhbmdlIG9mKSBjcHUocykgKi8NCisgICAgICAgICAg
ICBjcHVpZGEgPSBjcHVpZGIgPSBzdHJ0b3VsKHRva2EsICZlbmRwdHIsIDEwKTsNCisgICAgICAg
ICAgICBpZiAoZW5kcHRyID09IHRva2EpIHsNCisgICAgICAgICAgICAgICAgZnByaW50ZihzdGRl
cnIsICJFcnJvcjogSW52YWxpZCBhcmd1bWVudC5cbiIpOw0KKyAgICAgICAgICAgICAgICByZXQg
PSBFSU5WQUw7DQorICAgICAgICAgICAgICAgIGdvdG8gdmNwcF9vdXQ7DQorICAgICAgICAgICAg
fQ0KKyAgICAgICAgICAgIGlmICgqZW5kcHRyID09ICctJykgew0KKyAgICAgICAgICAgICAgICB0
b2tiID0gZW5kcHRyICsgMTsNCisgICAgICAgICAgICAgICAgY3B1aWRiID0gc3RydG91bCh0b2ti
LCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAgICAgIGlmIChlbmRwdHIgPT0gdG9rYiB8fCBj
cHVpZGEgPiBjcHVpZGIpIHsNCisgICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAi
RXJyb3I6IEludmFsaWQgYXJndW1lbnQuXG4iKTsNCisgICAgICAgICAgICAgICAgICAgIHJldCA9
IEVJTlZBTDsNCisgICAgICAgICAgICAgICAgICAgIGdvdG8gdmNwcF9vdXQ7DQorICAgICAgICAg
ICAgICAgIH0NCisgICAgICAgICAgICB9DQorICAgICAgICAgICAgd2hpbGUgKGNwdWlkYSA8PSBj
cHVpZGIpIHsNCisgICAgICAgICAgICAgICAgbGlieGxfY3B1bWFwX3NldChjcHVtYXAsIGNwdWlk
YSk7DQorICAgICAgICAgICAgICAgIGNwdWlkYSsrOw0KKyAgICAgICAgICAgIH0NCisgICAgICAg
IH0NCisgICAgfQ0KKw0KKyAgICAvKiBDbGVhciBhbGwgdGhlIGNwdXMgZnJvbSB0aGUgcmVtb3Zh
bCBsaXN0ICovDQorICAgIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUoaSwgZXhjbHVkZV9jcHVtYXAp
IHsNCisgICAgICAgIGxpYnhsX2NwdW1hcF9yZXNldChjcHVtYXAsIGkpOw0KKyAgICB9DQorDQor
dmNwcF9vdXQ6DQorICAgIGxpYnhsX2NwdW1hcF9kaXNwb3NlKCZleGNsdWRlX2NwdW1hcCk7DQor
DQorICAgIHJldHVybiByZXQ7DQorfQ0KKw0KIHN0YXRpYyB2b2lkIHZjcHVwaW4oY29uc3QgY2hh
ciAqZCwgY29uc3QgY2hhciAqdmNwdSwgY2hhciAqY3B1KQ0KIHsNCiAgICAgbGlieGxfdmNwdWlu
Zm8gKnZjcHVpbmZvOw0KICAgICBsaWJ4bF9jcHVtYXAgY3B1bWFwOw0KIA0KLSAgICB1aW50MzJf
dCB2Y3B1aWQsIGNwdWlkYSwgY3B1aWRiOw0KLSAgICBjaGFyICplbmRwdHIsICp0b2thLCAqdG9r
YjsNCisgICAgdWludDMyX3QgdmNwdWlkOw0KKyAgICBjaGFyICplbmRwdHI7DQogICAgIGludCBp
LCBuYl92Y3B1Ow0KIA0KICAgICB2Y3B1aWQgPSBzdHJ0b3VsKHZjcHUsICZlbmRwdHIsIDEwKTsN
CkBAIC0zNTI2LDMyICszNTkwLDkgQEAgc3RhdGljIHZvaWQgdmNwdXBpbihjb25zdCBjaGFyICpk
LCBjb25zdA0KICAgICBpZiAobGlieGxfY3B1bWFwX2FsbG9jKGN0eCwgJmNwdW1hcCkpIHsNCiAg
ICAgICAgIGdvdG8gdmNwdXBpbl9vdXQ7DQogICAgIH0NCi0gICAgaWYgKHN0cmNtcChjcHUsICJh
bGwiKSkgew0KLSAgICAgICAgZm9yICh0b2thID0gc3RydG9rKGNwdSwgIiwiKSwgaSA9IDA7IHRv
a2E7IHRva2EgPSBzdHJ0b2soTlVMTCwgIiwiKSwgKytpKSB7DQotICAgICAgICAgICAgY3B1aWRh
ID0gc3RydG91bCh0b2thLCAmZW5kcHRyLCAxMCk7DQotICAgICAgICAgICAgaWYgKHRva2EgPT0g
ZW5kcHRyKSB7DQotICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFs
aWQgYXJndW1lbnQuXG4iKTsNCi0gICAgICAgICAgICAgICAgZ290byB2Y3B1cGluX291dDE7DQot
ICAgICAgICAgICAgfQ0KLSAgICAgICAgICAgIGlmICgqZW5kcHRyID09ICctJykgew0KLSAgICAg
ICAgICAgICAgICB0b2tiID0gZW5kcHRyICsgMTsNCi0gICAgICAgICAgICAgICAgY3B1aWRiID0g
c3RydG91bCh0b2tiLCAmZW5kcHRyLCAxMCk7DQotICAgICAgICAgICAgICAgIGlmICgodG9rYiA9
PSBlbmRwdHIpIHx8IChjcHVpZGEgPiBjcHVpZGIpKSB7DQotICAgICAgICAgICAgICAgICAgICBm
cHJpbnRmKHN0ZGVyciwgIkVycm9yOiBJbnZhbGlkIGFyZ3VtZW50LlxuIik7DQotICAgICAgICAg
ICAgICAgICAgICBnb3RvIHZjcHVwaW5fb3V0MTsNCi0gICAgICAgICAgICAgICAgfQ0KLSAgICAg
ICAgICAgICAgICB3aGlsZSAoY3B1aWRhIDw9IGNwdWlkYikgew0KLSAgICAgICAgICAgICAgICAg
ICAgbGlieGxfY3B1bWFwX3NldCgmY3B1bWFwLCBjcHVpZGEpOw0KLSAgICAgICAgICAgICAgICAg
ICAgKytjcHVpZGE7DQotICAgICAgICAgICAgICAgIH0NCi0gICAgICAgICAgICB9IGVsc2Ugew0K
LSAgICAgICAgICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0KCZjcHVtYXAsIGNwdWlkYSk7DQotICAg
ICAgICAgICAgfQ0KLSAgICAgICAgfQ0KLSAgICB9DQotICAgIGVsc2Ugew0KLSAgICAgICAgbWVt
c2V0KGNwdW1hcC5tYXAsIC0xLCBjcHVtYXAuc2l6ZSk7DQotICAgIH0NCisNCisgICAgaWYgKHZj
cHVwaW5fcGFyc2UoY3B1LCAmY3B1bWFwKSkNCisgICAgICAgIGdvdG8gdmNwdXBpbl9vdXQxOw0K
IA0KICAgICBpZiAodmNwdWlkICE9IC0xKSB7DQogICAgICAgICBpZiAobGlieGxfc2V0X3ZjcHVh
ZmZpbml0eShjdHgsIGRvbWlkLCB2Y3B1aWQsICZjcHVtYXApID09IC0xKSB7DQo=


--=-uCoRyQsJyRl6p9yJMpZ+--

--=-HSJ4rRTmFqKvjNgQmyFS
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)

iEYEABECAAYFAk8dpRcACgkQk4XaBE3IOsTtBgCfTPTmZxlAcq2C8O3QDs26GTbZ
QrYAnAi61uScwF0fdN8L1d1wPNgIQIbC
=lNcC
-----END PGP SIGNATURE-----

--=-HSJ4rRTmFqKvjNgQmyFS--



--===============0333325683652929383==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0333325683652929383==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:23:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:23:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOXU-0002Vj-Jn; Mon, 23 Jan 2012 18:22:44 +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 1RpOXS-0002VH-AQ
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:22:42 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327342955!12064402!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 12679 invoked from network); 23 Jan 2012 18:22:35 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Jan 2012 18:22:35 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74960500; Mon, 23 Jan 2012 19:22:23 +0100
Message-ID: <1327342942.2476.16.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 23 Jan 2012 19:22:22 +0100
In-Reply-To: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List 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: multipart/mixed; boundary="===============0108054919591421808=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0108054919591421808==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-MZpDTSOQ1PqbT2GIBu5i"


--=-MZpDTSOQ1PqbT2GIBu5i
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-01-23 at 13:19 +0000, Ian Campbell wrote:=20
> tools, blockers:
>=20
> [..]=20
>       * xl support for vcpu pinning (Dario Faggioli)
Patch sent, just right now.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-MZpDTSOQ1PqbT2GIBu5i
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)

iEYEABECAAYFAk8dpV4ACgkQk4XaBE3IOsRmgwCcDfa3PcmzpkF240U14iKB0eyE
Db8AoImeB1yu9MsVoP42j3Bl1Dgu0beA
=esEG
-----END PGP SIGNATURE-----

--=-MZpDTSOQ1PqbT2GIBu5i--



--===============0108054919591421808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0108054919591421808==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:23:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:23:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOXU-0002Vj-Jn; Mon, 23 Jan 2012 18:22:44 +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 1RpOXS-0002VH-AQ
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:22:42 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327342955!12064402!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 12679 invoked from network); 23 Jan 2012 18:22:35 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-4.tower-182.messagelabs.com with SMTP;
	23 Jan 2012 18:22:35 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74960500; Mon, 23 Jan 2012 19:22:23 +0100
Message-ID: <1327342942.2476.16.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Mon, 23 Jan 2012 19:22:22 +0100
In-Reply-To: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.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: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List 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: multipart/mixed; boundary="===============0108054919591421808=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0108054919591421808==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-MZpDTSOQ1PqbT2GIBu5i"


--=-MZpDTSOQ1PqbT2GIBu5i
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2012-01-23 at 13:19 +0000, Ian Campbell wrote:=20
> tools, blockers:
>=20
> [..]=20
>       * xl support for vcpu pinning (Dario Faggioli)
Patch sent, just right now.

Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-MZpDTSOQ1PqbT2GIBu5i
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)

iEYEABECAAYFAk8dpV4ACgkQk4XaBE3IOsRmgwCcDfa3PcmzpkF240U14iKB0eyE
Db8AoImeB1yu9MsVoP42j3Bl1Dgu0beA
=esEG
-----END PGP SIGNATURE-----

--=-MZpDTSOQ1PqbT2GIBu5i--



--===============0108054919591421808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0108054919591421808==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:23:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:23:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOY4-0002b1-Dx; Mon, 23 Jan 2012 18:23:20 +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 1RpOY2-0002Zz-Bm
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:23:18 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327342933!5199491!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20582 invoked from network); 23 Jan 2012 18:22:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	23 Jan 2012 18:22:13 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74960493; Mon, 23 Jan 2012 19:22:12 +0100
Message-ID: <1327342932.2476.15.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 19:22:12 +0100
In-Reply-To: <1327342219.2476.9.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv2 2 of 2] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============5201230328339749710=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5201230328339749710==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-rWAN+8NqY296F6OOQ8N3"


--=-rWAN+8NqY296F6OOQ8N3
Content-Type: multipart/mixed; boundary="=-1nQzzaDXmGx+98o0WDTe"


--=-1nQzzaDXmGx+98o0WDTe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Enable CPU affinity specification in a VM's config file with the
exact syntax `xl vcpu-pin' provides.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r d76603510485 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 18:02:47 2012 +0000
@@ -2663,6 +2663,20 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
     return 0;
 }
=20
+int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
+                               unsigned int max_vcpus, libxl_cpumap *cpuma=
p)
+{
+    int i, rc =3D 0;
+
+    for (i =3D 0; i < max_vcpus; i++) {
+        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
+            LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "no affinity for cpu %d", =
i);
+            rc =3D ERROR_FAIL;
+        }
+    }
+    return rc;
+}
+
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpu=
map)
 {
     GC_INIT(ctx);
diff -r d76603510485 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Jan 23 18:02:47 2012 +0000
@@ -560,6 +560,8 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
                                        int *nb_vcpu, int *nrcpus);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid=
,
                            libxl_cpumap *cpumap);
+int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
+                               unsigned int max_vcpus, libxl_cpumap *cpuma=
p);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpu=
map);
=20
 int libxl_get_sched_id(libxl_ctx *ctx);
diff -r d76603510485 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 18:02:47 2012 +0000
@@ -71,6 +71,9 @@ int libxl_init_build_info(libxl_ctx *ctx
     memset(b_info, '\0', sizeof(*b_info));
     b_info->max_vcpus =3D 1;
     b_info->cur_vcpus =3D 1;
+    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
+        return ERROR_NOMEM;
+    libxl_cpumap_set_any(&b_info->cpumap);
     b_info->max_memkb =3D 32 * 1024;
     b_info->target_memkb =3D b_info->max_memkb;
     b_info->disable_migrate =3D 0;
diff -r d76603510485 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 18:02:47 2012 +0000
@@ -65,6 +65,7 @@ int libxl__build_pre(libxl__gc *gc, uint
     libxl_ctx *ctx =3D libxl__gc_owner(gc);
     int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
+    libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap)=
;
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM=
_CONSTANT);
     if (info->type =3D=3D LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
diff -r d76603510485 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 18:02:47 2012 +0000
@@ -162,6 +162,7 @@ libxl_domain_create_info =3D Struct("domai
 libxl_domain_build_info =3D Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
+    ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
diff -r d76603510485 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Mon Jan 23 18:02:47 2012 +0000
@@ -70,6 +70,18 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
+{
+    memset(cpumap->map, -1, cpumap->size);
+}
+static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
+{
+    memset(cpumap->map, 0, cpumap->size);
+}
+static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
+{
+    return cpu >=3D 0 && cpu < (cpumap->size * 8);
+}
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
 #define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
                                              if (libxl_cpumap_test(&(m), v=
))
diff -r d76603510485 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:47 2012 +0000
@@ -288,16 +288,72 @@ static void dolog(const char *file, int=20
         libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
 }
=20
+static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
+{
+    int i;
+    uint8_t pmap =3D 0, bitmask =3D 0;
+    int firstset =3D 0, state =3D 0;
+
+    for (i =3D 0; i < maplen; i++) {
+        if (i % 8 =3D=3D 0) {
+            pmap =3D *map++;
+            bitmask =3D 1;
+        } else bitmask <<=3D 1;
+
+        switch (state) {
+        case 0:
+        case 2:
+            if ((pmap & bitmask) !=3D 0) {
+                firstset =3D i;
+                state++;
+            }
+            continue;
+        case 1:
+        case 3:
+            if ((pmap & bitmask) =3D=3D 0) {
+                fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
+                if (i - 1 > firstset)
+                    fprintf(stream, "-%d", i - 1);
+                state =3D 2;
+            }
+            continue;
+        }
+    }
+    switch (state) {
+        case 0:
+            fprintf(stream, "none");
+            break;
+        case 2:
+            break;
+        case 1:
+            if (firstset =3D=3D 0) {
+                fprintf(stream, "any cpu");
+                break;
+            }
+        case 3:
+            fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
+            if (i - 1 > firstset)
+                fprintf(stream, "-%d", i - 1);
+            break;
+    }
+}
+
 static void printf_info(int domid,
                         libxl_domain_config *d_config,
                         libxl_device_model_info *dm_info)
 {
-    int i;
+    int i, nr_cpus =3D -1;
     libxl_dominfo info;
+    libxl_physinfo physinfo;
=20
     libxl_domain_create_info *c_info =3D &d_config->c_info;
     libxl_domain_build_info *b_info =3D &d_config->b_info;
=20
+    if (libxl_get_physinfo(ctx, &physinfo) =3D=3D 0)
+        nr_cpus =3D physinfo.nr_cpus;
+    else
+        fprintf(stderr, "libxl_physinfo failed.\n");
+
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM);
@@ -328,6 +384,9 @@ static void printf_info(int domid,
=20
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
+    printf("\t(CPU affinity ");
+    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);
+    printf(")\n");
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode)=
);
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
@@ -569,6 +628,8 @@ static void split_string_into_string_lis
     free(s);
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -578,7 +639,7 @@ static void parse_config_data(const char
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int e;
@@ -661,6 +722,29 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus =3D l;
=20
+    if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
+        int i, n_cpus =3D 0;
+
+        libxl_cpumap_set_none(&b_info->cpumap);
+        while ((buf =3D xlu_cfg_get_listitem(cpus, n_cpus)) !=3D NULL) {
+            i =3D atoi(buf);
+            if (!libxl_cpumap_cpu_valid(&b_info->cpumap, i)) {
+                fprintf(stderr, "cpu %d illegal\n", i);
+                exit(1);
+            }
+            libxl_cpumap_set(&b_info->cpumap, i);
+            n_cpus++;
+        }
+    }
+    else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
+        char *buf2 =3D strdup(buf);
+
+        libxl_cpumap_set_none(&b_info->cpumap);
+        if (vcpupin_parse(buf2, &b_info->cpumap))
+            exit(1);
+        free(buf2);
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb =3D l * 1024;
         b_info->target_memkb =3D b_info->max_memkb;
@@ -3357,56 +3441,6 @@ int main_button_press(int argc, char **a
     return 0;
 }
=20
-static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
-{
-    int i;
-    uint8_t pmap =3D 0, bitmask =3D 0;
-    int firstset =3D 0, state =3D 0;
-
-    for (i =3D 0; i < maplen; i++) {
-        if (i % 8 =3D=3D 0) {
-            pmap =3D *map++;
-            bitmask =3D 1;
-        } else bitmask <<=3D 1;
-
-        switch (state) {
-        case 0:
-        case 2:
-            if ((pmap & bitmask) !=3D 0) {
-                firstset =3D i;
-                state++;
-            }
-            continue;
-        case 1:
-        case 3:
-            if ((pmap & bitmask) =3D=3D 0) {
-                fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
-                if (i - 1 > firstset)
-                    fprintf(stream, "-%d", i - 1);
-                state =3D 2;
-            }
-            continue;
-        }
-    }
-    switch (state) {
-        case 0:
-            fprintf(stream, "none");
-            break;
-        case 2:
-            break;
-        case 1:
-            if (firstset =3D=3D 0) {
-                fprintf(stream, "any cpu");
-                break;
-            }
-        case 3:
-            fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
-            if (i - 1 > firstset)
-                fprintf(stream, "-%d", i - 1);
-            break;
-    }
-}
-
 static void print_vcpuinfo(uint32_t tdomid,
                            const libxl_vcpuinfo *vcpuinfo,
                            uint32_t nr_cpus)
@@ -3511,7 +3545,7 @@ static int vcpupin_parse(char *cpu, libx
     int i, ret =3D 0;
=20
     if (!strcmp(cpu, "all")) {
-        memset(cpumap->map, -1, cpumap->size);
+        libxl_cpumap_set_any(cpumap);
         return 0;
     }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-1nQzzaDXmGx+98o0WDTe
Content-Disposition: attachment; filename="support-cpus-par-in-config-file.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="support-cpus-par-in-config-file.patch";
	charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGQ3NjYwMzUxMDQ4NWJiZDY5YjMwOTA1NTk5
ZjI4ODNiYzBmYjliNjcNCmxpYnhsOiBhbGxvdyBmb3Igc3BlY2lmeWluZyB0aGUgQ1BVIGFmZmlu
aXR5IGluIHRoZSBjb25maWcgZmlsZS4NCg0KRW5hYmxlIENQVSBhZmZpbml0eSBzcGVjaWZpY2F0
aW9uIGluIGEgVk0ncyBjb25maWcgZmlsZSB3aXRoIHRoZQ0KZXhhY3Qgc3ludGF4IGB4bCB2Y3B1
LXBpbicgcHJvdmlkZXMuDQoNClNpZ25lZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5m
YWdnaW9saUBjaXRyaXguY29tPg0KDQpkaWZmIC1yIGQ3NjYwMzUxMDQ4NSB0b29scy9saWJ4bC9s
aWJ4bC5jDQotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCU1vbiBKYW4gMjMgMTg6MDI6NDIgMjAx
MiArMDAwMA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYwlNb24gSmFuIDIzIDE4OjAyOjQ3IDIw
MTIgKzAwMDANCkBAIC0yNjYzLDYgKzI2NjMsMjAgQEAgaW50IGxpYnhsX3NldF92Y3B1YWZmaW5p
dHkobGlieGxfY3R4ICpjdA0KICAgICByZXR1cm4gMDsNCiB9DQogDQoraW50IGxpYnhsX3NldF92
Y3B1YWZmaW5pdHlfYWxsKGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IG1heF92Y3B1cywgbGlieGxfY3B1
bWFwICpjcHVtYXApDQorew0KKyAgICBpbnQgaSwgcmMgPSAwOw0KKw0KKyAgICBmb3IgKGkgPSAw
OyBpIDwgbWF4X3ZjcHVzOyBpKyspIHsNCisgICAgICAgIGlmIChsaWJ4bF9zZXRfdmNwdWFmZmlu
aXR5KGN0eCwgZG9taWQsIGksIGNwdW1hcCkpIHsNCisgICAgICAgICAgICBMSUJYTF9fTE9HKGN0
eCwgTElCWExfX0xPR19XQVJOSU5HLCAibm8gYWZmaW5pdHkgZm9yIGNwdSAlZCIsIGkpOw0KKyAg
ICAgICAgICAgIHJjID0gRVJST1JfRkFJTDsNCisgICAgICAgIH0NCisgICAgfQ0KKyAgICByZXR1
cm4gcmM7DQorfQ0KKw0KIGludCBsaWJ4bF9zZXRfdmNwdW9ubGluZShsaWJ4bF9jdHggKmN0eCwg
dWludDMyX3QgZG9taWQsIGxpYnhsX2NwdW1hcCAqY3B1bWFwKQ0KIHsNCiAgICAgR0NfSU5JVChj
dHgpOw0KZGlmZiAtciBkNzY2MDM1MTA0ODUgdG9vbHMvbGlieGwvbGlieGwuaA0KLS0tIGEvdG9v
bHMvbGlieGwvbGlieGwuaAlNb24gSmFuIDIzIDE4OjAyOjQyIDIwMTIgKzAwMDANCisrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsLmgJTW9uIEphbiAyMyAxODowMjo0NyAyMDEyICswMDAwDQpAQCAtNTYw
LDYgKzU2MCw4IEBAIGxpYnhsX3ZjcHVpbmZvICpsaWJ4bF9saXN0X3ZjcHUobGlieGxfY3QNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgKm5iX3ZjcHUsIGludCAq
bnJjcHVzKTsNCiBpbnQgbGlieGxfc2V0X3ZjcHVhZmZpbml0eShsaWJ4bF9jdHggKmN0eCwgdWlu
dDMyX3QgZG9taWQsIHVpbnQzMl90IHZjcHVpZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBsaWJ4bF9jcHVtYXAgKmNwdW1hcCk7DQoraW50IGxpYnhsX3NldF92Y3B1YWZmaW5pdHlfYWxs
KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdW5zaWduZWQgaW50IG1heF92Y3B1cywgbGlieGxfY3B1bWFwICpjcHVtYXApOw0K
IGludCBsaWJ4bF9zZXRfdmNwdW9ubGluZShsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQs
IGxpYnhsX2NwdW1hcCAqY3B1bWFwKTsNCiANCiBpbnQgbGlieGxfZ2V0X3NjaGVkX2lkKGxpYnhs
X2N0eCAqY3R4KTsNCmRpZmYgLXIgZDc2NjAzNTEwNDg1IHRvb2xzL2xpYnhsL2xpYnhsX2NyZWF0
ZS5jDQotLS0gYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlNb24gSmFuIDIzIDE4OjAyOjQy
IDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCU1vbiBKYW4gMjMg
MTg6MDI6NDcgMjAxMiArMDAwMA0KQEAgLTcxLDYgKzcxLDkgQEAgaW50IGxpYnhsX2luaXRfYnVp
bGRfaW5mbyhsaWJ4bF9jdHggKmN0eA0KICAgICBtZW1zZXQoYl9pbmZvLCAnXDAnLCBzaXplb2Yo
KmJfaW5mbykpOw0KICAgICBiX2luZm8tPm1heF92Y3B1cyA9IDE7DQogICAgIGJfaW5mby0+Y3Vy
X3ZjcHVzID0gMTsNCisgICAgaWYgKGxpYnhsX2NwdW1hcF9hbGxvYyhjdHgsICZiX2luZm8tPmNw
dW1hcCkpDQorICAgICAgICByZXR1cm4gRVJST1JfTk9NRU07DQorICAgIGxpYnhsX2NwdW1hcF9z
ZXRfYW55KCZiX2luZm8tPmNwdW1hcCk7DQogICAgIGJfaW5mby0+bWF4X21lbWtiID0gMzIgKiAx
MDI0Ow0KICAgICBiX2luZm8tPnRhcmdldF9tZW1rYiA9IGJfaW5mby0+bWF4X21lbWtiOw0KICAg
ICBiX2luZm8tPmRpc2FibGVfbWlncmF0ZSA9IDA7DQpkaWZmIC1yIGQ3NjYwMzUxMDQ4NSB0b29s
cy9saWJ4bC9saWJ4bF9kb20uYw0KLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG9tLmMJTW9uIEph
biAyMyAxODowMjo0MiAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF9kb20uYwlN
b24gSmFuIDIzIDE4OjAyOjQ3IDIwMTIgKzAwMDANCkBAIC02NSw2ICs2NSw3IEBAIGludCBsaWJ4
bF9fYnVpbGRfcHJlKGxpYnhsX19nYyAqZ2MsIHVpbnQNCiAgICAgbGlieGxfY3R4ICpjdHggPSBs
aWJ4bF9fZ2Nfb3duZXIoZ2MpOw0KICAgICBpbnQgdHNjX21vZGU7DQogICAgIHhjX2RvbWFpbl9t
YXhfdmNwdXMoY3R4LT54Y2gsIGRvbWlkLCBpbmZvLT5tYXhfdmNwdXMpOw0KKyAgICBsaWJ4bF9z
ZXRfdmNwdWFmZmluaXR5X2FsbChjdHgsIGRvbWlkLCBpbmZvLT5tYXhfdmNwdXMsICZpbmZvLT5j
cHVtYXApOw0KICAgICB4Y19kb21haW5fc2V0bWF4bWVtKGN0eC0+eGNoLCBkb21pZCwgaW5mby0+
dGFyZ2V0X21lbWtiICsgTElCWExfTUFYTUVNX0NPTlNUQU5UKTsNCiAgICAgaWYgKGluZm8tPnR5
cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfUFYpDQogICAgICAgICB4Y19kb21haW5fc2V0X21lbW1h
cF9saW1pdChjdHgtPnhjaCwgZG9taWQsDQpkaWZmIC1yIGQ3NjYwMzUxMDQ4NSB0b29scy9saWJ4
bC9saWJ4bF90eXBlcy5pZGwNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlNb24g
SmFuIDIzIDE4OjAyOjQyIDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVz
LmlkbAlNb24gSmFuIDIzIDE4OjAyOjQ3IDIwMTIgKzAwMDANCkBAIC0xNjIsNiArMTYyLDcgQEAg
bGlieGxfZG9tYWluX2NyZWF0ZV9pbmZvID0gU3RydWN0KCJkb21haQ0KIGxpYnhsX2RvbWFpbl9i
dWlsZF9pbmZvID0gU3RydWN0KCJkb21haW5fYnVpbGRfaW5mbyIsWw0KICAgICAoIm1heF92Y3B1
cyIsICAgICAgIGludGVnZXIpLA0KICAgICAoImN1cl92Y3B1cyIsICAgICAgIGludGVnZXIpLA0K
KyAgICAoImNwdW1hcCIsICAgICAgICAgIGxpYnhsX2NwdW1hcCksDQogICAgICgidHNjX21vZGUi
LCAgICAgICAgbGlieGxfdHNjX21vZGUpLA0KICAgICAoIm1heF9tZW1rYiIsICAgICAgIHVpbnQz
MiksDQogICAgICgidGFyZ2V0X21lbWtiIiwgICAgdWludDMyKSwNCmRpZmYgLXIgZDc2NjAzNTEw
NDg1IHRvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3V0
aWxzLmgJTW9uIEphbiAyMyAxODowMjo0MiAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9s
aWJ4bF91dGlscy5oCU1vbiBKYW4gMjMgMTg6MDI6NDcgMjAxMiArMDAwMA0KQEAgLTcwLDYgKzcw
LDE4IEBAIGludCBsaWJ4bF9jcHVtYXBfYWxsb2MobGlieGxfY3R4ICpjdHgsIGwNCiBpbnQgbGli
eGxfY3B1bWFwX3Rlc3QobGlieGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KIHZvaWQgbGli
eGxfY3B1bWFwX3NldChsaWJ4bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4
bF9jcHVtYXBfcmVzZXQobGlieGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KK3N0YXRpYyBp
bmxpbmUgdm9pZCBsaWJ4bF9jcHVtYXBfc2V0X2FueShsaWJ4bF9jcHVtYXAgKmNwdW1hcCkNCit7
DQorICAgIG1lbXNldChjcHVtYXAtPm1hcCwgLTEsIGNwdW1hcC0+c2l6ZSk7DQorfQ0KK3N0YXRp
YyBpbmxpbmUgdm9pZCBsaWJ4bF9jcHVtYXBfc2V0X25vbmUobGlieGxfY3B1bWFwICpjcHVtYXAp
DQorew0KKyAgICBtZW1zZXQoY3B1bWFwLT5tYXAsIDAsIGNwdW1hcC0+c2l6ZSk7DQorfQ0KK3N0
YXRpYyBpbmxpbmUgaW50IGxpYnhsX2NwdW1hcF9jcHVfdmFsaWQobGlieGxfY3B1bWFwICpjcHVt
YXAsIGludCBjcHUpDQorew0KKyAgICByZXR1cm4gY3B1ID49IDAgJiYgY3B1IDwgKGNwdW1hcC0+
c2l6ZSAqIDgpOw0KK30NCiAjZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX2NwdSh2YXIsIG1hcCkgZm9y
ICh2YXIgPSAwOyB2YXIgPCAobWFwKS5zaXplICogODsgdmFyKyspDQogI2RlZmluZSBsaWJ4bF9m
b3JfZWFjaF9zZXRfY3B1KHYsIG0pIGZvciAodiA9IDA7IHYgPCAobSkuc2l6ZSAqIDg7IHYrKykg
XA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIChsaWJ4
bF9jcHVtYXBfdGVzdCgmKG0pLCB2KSkNCmRpZmYgLXIgZDc2NjAzNTEwNDg1IHRvb2xzL2xpYnhs
L3hsX2NtZGltcGwuYw0KLS0tIGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBKYW4gMjMg
MTg6MDI6NDIgMjAxMiArMDAwMA0KKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBK
YW4gMjMgMTg6MDI6NDcgMjAxMiArMDAwMA0KQEAgLTI4OCwxNiArMjg4LDcyIEBAIHN0YXRpYyB2
b2lkIGRvbG9nKGNvbnN0IGNoYXIgKmZpbGUsIGludCANCiAgICAgICAgIGxpYnhsX3dyaXRlX2V4
YWN0bHkoTlVMTCwgbG9nZmlsZSwgcywgcmMsIE5VTEwsIE5VTEwpOw0KIH0NCiANCitzdGF0aWMg
dm9pZCBwcmludF9iaXRtYXAodWludDhfdCAqbWFwLCBpbnQgbWFwbGVuLCBGSUxFICpzdHJlYW0p
DQorew0KKyAgICBpbnQgaTsNCisgICAgdWludDhfdCBwbWFwID0gMCwgYml0bWFzayA9IDA7DQor
ICAgIGludCBmaXJzdHNldCA9IDAsIHN0YXRlID0gMDsNCisNCisgICAgZm9yIChpID0gMDsgaSA8
IG1hcGxlbjsgaSsrKSB7DQorICAgICAgICBpZiAoaSAlIDggPT0gMCkgew0KKyAgICAgICAgICAg
IHBtYXAgPSAqbWFwKys7DQorICAgICAgICAgICAgYml0bWFzayA9IDE7DQorICAgICAgICB9IGVs
c2UgYml0bWFzayA8PD0gMTsNCisNCisgICAgICAgIHN3aXRjaCAoc3RhdGUpIHsNCisgICAgICAg
IGNhc2UgMDoNCisgICAgICAgIGNhc2UgMjoNCisgICAgICAgICAgICBpZiAoKHBtYXAgJiBiaXRt
YXNrKSAhPSAwKSB7DQorICAgICAgICAgICAgICAgIGZpcnN0c2V0ID0gaTsNCisgICAgICAgICAg
ICAgICAgc3RhdGUrKzsNCisgICAgICAgICAgICB9DQorICAgICAgICAgICAgY29udGludWU7DQor
ICAgICAgICBjYXNlIDE6DQorICAgICAgICBjYXNlIDM6DQorICAgICAgICAgICAgaWYgKChwbWFw
ICYgYml0bWFzaykgPT0gMCkgew0KKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0cmVhbSwgIiVz
JWQiLCBzdGF0ZSA+IDEgPyAiLCIgOiAiIiwgZmlyc3RzZXQpOw0KKyAgICAgICAgICAgICAgICBp
ZiAoaSAtIDEgPiBmaXJzdHNldCkNCisgICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RyZWFt
LCAiLSVkIiwgaSAtIDEpOw0KKyAgICAgICAgICAgICAgICBzdGF0ZSA9IDI7DQorICAgICAgICAg
ICAgfQ0KKyAgICAgICAgICAgIGNvbnRpbnVlOw0KKyAgICAgICAgfQ0KKyAgICB9DQorICAgIHN3
aXRjaCAoc3RhdGUpIHsNCisgICAgICAgIGNhc2UgMDoNCisgICAgICAgICAgICBmcHJpbnRmKHN0
cmVhbSwgIm5vbmUiKTsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgMjoNCisg
ICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgMToNCisgICAgICAgICAgICBpZiAoZmly
c3RzZXQgPT0gMCkgew0KKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0cmVhbSwgImFueSBjcHUi
KTsNCisgICAgICAgICAgICAgICAgYnJlYWs7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAgY2Fz
ZSAzOg0KKyAgICAgICAgICAgIGZwcmludGYoc3RyZWFtLCAiJXMlZCIsIHN0YXRlID4gMSA/ICIs
IiA6ICIiLCBmaXJzdHNldCk7DQorICAgICAgICAgICAgaWYgKGkgLSAxID4gZmlyc3RzZXQpDQor
ICAgICAgICAgICAgICAgIGZwcmludGYoc3RyZWFtLCAiLSVkIiwgaSAtIDEpOw0KKyAgICAgICAg
ICAgIGJyZWFrOw0KKyAgICB9DQorfQ0KKw0KIHN0YXRpYyB2b2lkIHByaW50Zl9pbmZvKGludCBk
b21pZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kb21haW5fY29uZmlnICpkX2Nv
bmZpZywNCiAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZXZpY2VfbW9kZWxfaW5mbyAq
ZG1faW5mbykNCiB7DQotICAgIGludCBpOw0KKyAgICBpbnQgaSwgbnJfY3B1cyA9IC0xOw0KICAg
ICBsaWJ4bF9kb21pbmZvIGluZm87DQorICAgIGxpYnhsX3BoeXNpbmZvIHBoeXNpbmZvOw0KIA0K
ICAgICBsaWJ4bF9kb21haW5fY3JlYXRlX2luZm8gKmNfaW5mbyA9ICZkX2NvbmZpZy0+Y19pbmZv
Ow0KICAgICBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyAqYl9pbmZvID0gJmRfY29uZmlnLT5iX2lu
Zm87DQogDQorICAgIGlmIChsaWJ4bF9nZXRfcGh5c2luZm8oY3R4LCAmcGh5c2luZm8pID09IDAp
DQorICAgICAgICBucl9jcHVzID0gcGh5c2luZm8ubnJfY3B1czsNCisgICAgZWxzZQ0KKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJsaWJ4bF9waHlzaW5mbyBmYWlsZWQuXG4iKTsNCisNCiAgICAg
cHJpbnRmKCIoZG9tYWluXG5cdChkb21pZCAlZClcbiIsIGRvbWlkKTsNCiAgICAgcHJpbnRmKCJc
dChjcmVhdGVfaW5mbylcbiIpOw0KICAgICBwcmludGYoIlx0KGh2bSAlZClcbiIsIGNfaW5mby0+
dHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9IVk0pOw0KQEAgLTMyOCw2ICszODQsOSBAQCBzdGF0
aWMgdm9pZCBwcmludGZfaW5mbyhpbnQgZG9taWQsDQogDQogICAgIHByaW50ZigiXHQoYnVpbGRf
aW5mbylcbiIpOw0KICAgICBwcmludGYoIlx0KG1heF92Y3B1cyAlZClcbiIsIGJfaW5mby0+bWF4
X3ZjcHVzKTsNCisgICAgcHJpbnRmKCJcdChDUFUgYWZmaW5pdHkgIik7DQorICAgIHByaW50X2Jp
dG1hcChiX2luZm8tPmNwdW1hcC5tYXAsIG5yX2NwdXMsIHN0ZG91dCk7DQorICAgIHByaW50Zigi
KVxuIik7DQogICAgIHByaW50ZigiXHQodHNjX21vZGUgJXMpXG4iLCBsaWJ4bF90c2NfbW9kZV90
b19zdHJpbmcoYl9pbmZvLT50c2NfbW9kZSkpOw0KICAgICBwcmludGYoIlx0KG1heF9tZW1rYiAl
ZClcbiIsIGJfaW5mby0+bWF4X21lbWtiKTsNCiAgICAgcHJpbnRmKCJcdCh0YXJnZXRfbWVta2Ig
JWQpXG4iLCBiX2luZm8tPnRhcmdldF9tZW1rYik7DQpAQCAtNTY5LDYgKzYyOCw4IEBAIHN0YXRp
YyB2b2lkIHNwbGl0X3N0cmluZ19pbnRvX3N0cmluZ19saXMNCiAgICAgZnJlZShzKTsNCiB9DQog
DQorc3RhdGljIGludCB2Y3B1cGluX3BhcnNlKGNoYXIgKmNwdSwgbGlieGxfY3B1bWFwICpjcHVt
YXApOw0KKw0KIHN0YXRpYyB2b2lkIHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXIgKmNvbmZp
Z2ZpbGVfZmlsZW5hbWVfcmVwb3J0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv
bnN0IGNoYXIgKmNvbmZpZ2ZpbGVfZGF0YSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBpbnQgY29uZmlnZmlsZV9sZW4sDQpAQCAtNTc4LDcgKzYzOSw3IEBAIHN0YXRpYyB2b2lkIHBh
cnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXINCiAgICAgY29uc3QgY2hhciAqYnVmOw0KICAgICBs
b25nIGw7DQogICAgIFhMVV9Db25maWcgKmNvbmZpZzsNCi0gICAgWExVX0NvbmZpZ0xpc3QgKnZi
ZHMsICpuaWNzLCAqcGNpcywgKmN2ZmJzLCAqY3B1aWRzOw0KKyAgICBYTFVfQ29uZmlnTGlzdCAq
Y3B1cywgKnZiZHMsICpuaWNzLCAqcGNpcywgKmN2ZmJzLCAqY3B1aWRzOw0KICAgICBpbnQgcGNp
X3Bvd2VyX21nbXQgPSAwOw0KICAgICBpbnQgcGNpX21zaXRyYW5zbGF0ZSA9IDE7DQogICAgIGlu
dCBlOw0KQEAgLTY2MSw2ICs3MjIsMjkgQEAgc3RhdGljIHZvaWQgcGFyc2VfY29uZmlnX2RhdGEo
Y29uc3QgY2hhcg0KICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcgKGNvbmZpZywgIm1heHZjcHVz
IiwgJmwsIDApKQ0KICAgICAgICAgYl9pbmZvLT5tYXhfdmNwdXMgPSBsOw0KIA0KKyAgICBpZiAo
IXhsdV9jZmdfZ2V0X2xpc3QgKGNvbmZpZywgImNwdXMiLCAmY3B1cywgMCwgMSkpIHsNCisgICAg
ICAgIGludCBpLCBuX2NwdXMgPSAwOw0KKw0KKyAgICAgICAgbGlieGxfY3B1bWFwX3NldF9ub25l
KCZiX2luZm8tPmNwdW1hcCk7DQorICAgICAgICB3aGlsZSAoKGJ1ZiA9IHhsdV9jZmdfZ2V0X2xp
c3RpdGVtKGNwdXMsIG5fY3B1cykpICE9IE5VTEwpIHsNCisgICAgICAgICAgICBpID0gYXRvaShi
dWYpOw0KKyAgICAgICAgICAgIGlmICghbGlieGxfY3B1bWFwX2NwdV92YWxpZCgmYl9pbmZvLT5j
cHVtYXAsIGkpKSB7DQorICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiY3B1ICVkIGls
bGVnYWxcbiIsIGkpOw0KKyAgICAgICAgICAgICAgICBleGl0KDEpOw0KKyAgICAgICAgICAgIH0N
CisgICAgICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0KCZiX2luZm8tPmNwdW1hcCwgaSk7DQorICAg
ICAgICAgICAgbl9jcHVzKys7DQorICAgICAgICB9DQorICAgIH0NCisgICAgZWxzZSBpZiAoIXhs
dV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAiY3B1cyIsICZidWYsIDApKSB7DQorICAgICAgICBj
aGFyICpidWYyID0gc3RyZHVwKGJ1Zik7DQorDQorICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0X25v
bmUoJmJfaW5mby0+Y3B1bWFwKTsNCisgICAgICAgIGlmICh2Y3B1cGluX3BhcnNlKGJ1ZjIsICZi
X2luZm8tPmNwdW1hcCkpDQorICAgICAgICAgICAgZXhpdCgxKTsNCisgICAgICAgIGZyZWUoYnVm
Mik7DQorICAgIH0NCisNCiAgICAgaWYgKCF4bHVfY2ZnX2dldF9sb25nIChjb25maWcsICJtZW1v
cnkiLCAmbCwgMCkpIHsNCiAgICAgICAgIGJfaW5mby0+bWF4X21lbWtiID0gbCAqIDEwMjQ7DQog
ICAgICAgICBiX2luZm8tPnRhcmdldF9tZW1rYiA9IGJfaW5mby0+bWF4X21lbWtiOw0KQEAgLTMz
NTcsNTYgKzM0NDEsNiBAQCBpbnQgbWFpbl9idXR0b25fcHJlc3MoaW50IGFyZ2MsIGNoYXIgKiph
DQogICAgIHJldHVybiAwOw0KIH0NCiANCi1zdGF0aWMgdm9pZCBwcmludF9iaXRtYXAodWludDhf
dCAqbWFwLCBpbnQgbWFwbGVuLCBGSUxFICpzdHJlYW0pDQotew0KLSAgICBpbnQgaTsNCi0gICAg
dWludDhfdCBwbWFwID0gMCwgYml0bWFzayA9IDA7DQotICAgIGludCBmaXJzdHNldCA9IDAsIHN0
YXRlID0gMDsNCi0NCi0gICAgZm9yIChpID0gMDsgaSA8IG1hcGxlbjsgaSsrKSB7DQotICAgICAg
ICBpZiAoaSAlIDggPT0gMCkgew0KLSAgICAgICAgICAgIHBtYXAgPSAqbWFwKys7DQotICAgICAg
ICAgICAgYml0bWFzayA9IDE7DQotICAgICAgICB9IGVsc2UgYml0bWFzayA8PD0gMTsNCi0NCi0g
ICAgICAgIHN3aXRjaCAoc3RhdGUpIHsNCi0gICAgICAgIGNhc2UgMDoNCi0gICAgICAgIGNhc2Ug
MjoNCi0gICAgICAgICAgICBpZiAoKHBtYXAgJiBiaXRtYXNrKSAhPSAwKSB7DQotICAgICAgICAg
ICAgICAgIGZpcnN0c2V0ID0gaTsNCi0gICAgICAgICAgICAgICAgc3RhdGUrKzsNCi0gICAgICAg
ICAgICB9DQotICAgICAgICAgICAgY29udGludWU7DQotICAgICAgICBjYXNlIDE6DQotICAgICAg
ICBjYXNlIDM6DQotICAgICAgICAgICAgaWYgKChwbWFwICYgYml0bWFzaykgPT0gMCkgew0KLSAg
ICAgICAgICAgICAgICBmcHJpbnRmKHN0cmVhbSwgIiVzJWQiLCBzdGF0ZSA+IDEgPyAiLCIgOiAi
IiwgZmlyc3RzZXQpOw0KLSAgICAgICAgICAgICAgICBpZiAoaSAtIDEgPiBmaXJzdHNldCkNCi0g
ICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RyZWFtLCAiLSVkIiwgaSAtIDEpOw0KLSAgICAg
ICAgICAgICAgICBzdGF0ZSA9IDI7DQotICAgICAgICAgICAgfQ0KLSAgICAgICAgICAgIGNvbnRp
bnVlOw0KLSAgICAgICAgfQ0KLSAgICB9DQotICAgIHN3aXRjaCAoc3RhdGUpIHsNCi0gICAgICAg
IGNhc2UgMDoNCi0gICAgICAgICAgICBmcHJpbnRmKHN0cmVhbSwgIm5vbmUiKTsNCi0gICAgICAg
ICAgICBicmVhazsNCi0gICAgICAgIGNhc2UgMjoNCi0gICAgICAgICAgICBicmVhazsNCi0gICAg
ICAgIGNhc2UgMToNCi0gICAgICAgICAgICBpZiAoZmlyc3RzZXQgPT0gMCkgew0KLSAgICAgICAg
ICAgICAgICBmcHJpbnRmKHN0cmVhbSwgImFueSBjcHUiKTsNCi0gICAgICAgICAgICAgICAgYnJl
YWs7DQotICAgICAgICAgICAgfQ0KLSAgICAgICAgY2FzZSAzOg0KLSAgICAgICAgICAgIGZwcmlu
dGYoc3RyZWFtLCAiJXMlZCIsIHN0YXRlID4gMSA/ICIsIiA6ICIiLCBmaXJzdHNldCk7DQotICAg
ICAgICAgICAgaWYgKGkgLSAxID4gZmlyc3RzZXQpDQotICAgICAgICAgICAgICAgIGZwcmludGYo
c3RyZWFtLCAiLSVkIiwgaSAtIDEpOw0KLSAgICAgICAgICAgIGJyZWFrOw0KLSAgICB9DQotfQ0K
LQ0KIHN0YXRpYyB2b2lkIHByaW50X3ZjcHVpbmZvKHVpbnQzMl90IHRkb21pZCwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBjb25zdCBsaWJ4bF92Y3B1aW5mbyAqdmNwdWluZm8sDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgbnJfY3B1cykNCkBAIC0zNTExLDcgKzM1
NDUsNyBAQCBzdGF0aWMgaW50IHZjcHVwaW5fcGFyc2UoY2hhciAqY3B1LCBsaWJ4DQogICAgIGlu
dCBpLCByZXQgPSAwOw0KIA0KICAgICBpZiAoIXN0cmNtcChjcHUsICJhbGwiKSkgew0KLSAgICAg
ICAgbWVtc2V0KGNwdW1hcC0+bWFwLCAtMSwgY3B1bWFwLT5zaXplKTsNCisgICAgICAgIGxpYnhs
X2NwdW1hcF9zZXRfYW55KGNwdW1hcCk7DQogICAgICAgICByZXR1cm4gMDsNCiAgICAgfQ0KIA0K



--=-1nQzzaDXmGx+98o0WDTe--

--=-rWAN+8NqY296F6OOQ8N3
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)

iEYEABECAAYFAk8dpVQACgkQk4XaBE3IOsTtBACgrLQy/A8ygYKA9s9zyN3cZla9
CcwAn04lHYqy9z8hdGLb9FGBn2fcF+rf
=f7Ma
-----END PGP SIGNATURE-----

--=-rWAN+8NqY296F6OOQ8N3--



--===============5201230328339749710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5201230328339749710==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:23:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:23:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOY4-0002b1-Dx; Mon, 23 Jan 2012 18:23:20 +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 1RpOY2-0002Zz-Bm
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:23:18 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327342933!5199491!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20582 invoked from network); 23 Jan 2012 18:22:13 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-174.messagelabs.com with SMTP;
	23 Jan 2012 18:22:13 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 74960493; Mon, 23 Jan 2012 19:22:12 +0100
Message-ID: <1327342932.2476.15.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 19:22:12 +0100
In-Reply-To: <1327342219.2476.9.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv2 2 of 2] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============5201230328339749710=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5201230328339749710==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-rWAN+8NqY296F6OOQ8N3"


--=-rWAN+8NqY296F6OOQ8N3
Content-Type: multipart/mixed; boundary="=-1nQzzaDXmGx+98o0WDTe"


--=-1nQzzaDXmGx+98o0WDTe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Enable CPU affinity specification in a VM's config file with the
exact syntax `xl vcpu-pin' provides.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r d76603510485 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 18:02:47 2012 +0000
@@ -2663,6 +2663,20 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
     return 0;
 }
=20
+int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
+                               unsigned int max_vcpus, libxl_cpumap *cpuma=
p)
+{
+    int i, rc =3D 0;
+
+    for (i =3D 0; i < max_vcpus; i++) {
+        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
+            LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "no affinity for cpu %d", =
i);
+            rc =3D ERROR_FAIL;
+        }
+    }
+    return rc;
+}
+
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpu=
map)
 {
     GC_INIT(ctx);
diff -r d76603510485 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl.h	Mon Jan 23 18:02:47 2012 +0000
@@ -560,6 +560,8 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
                                        int *nb_vcpu, int *nrcpus);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid=
,
                            libxl_cpumap *cpumap);
+int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
+                               unsigned int max_vcpus, libxl_cpumap *cpuma=
p);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpu=
map);
=20
 int libxl_get_sched_id(libxl_ctx *ctx);
diff -r d76603510485 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl_create.c	Mon Jan 23 18:02:47 2012 +0000
@@ -71,6 +71,9 @@ int libxl_init_build_info(libxl_ctx *ctx
     memset(b_info, '\0', sizeof(*b_info));
     b_info->max_vcpus =3D 1;
     b_info->cur_vcpus =3D 1;
+    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
+        return ERROR_NOMEM;
+    libxl_cpumap_set_any(&b_info->cpumap);
     b_info->max_memkb =3D 32 * 1024;
     b_info->target_memkb =3D b_info->max_memkb;
     b_info->disable_migrate =3D 0;
diff -r d76603510485 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 18:02:47 2012 +0000
@@ -65,6 +65,7 @@ int libxl__build_pre(libxl__gc *gc, uint
     libxl_ctx *ctx =3D libxl__gc_owner(gc);
     int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
+    libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap)=
;
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM=
_CONSTANT);
     if (info->type =3D=3D LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
diff -r d76603510485 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Mon Jan 23 18:02:47 2012 +0000
@@ -162,6 +162,7 @@ libxl_domain_create_info =3D Struct("domai
 libxl_domain_build_info =3D Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
+    ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
diff -r d76603510485 tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Mon Jan 23 18:02:47 2012 +0000
@@ -70,6 +70,18 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
+{
+    memset(cpumap->map, -1, cpumap->size);
+}
+static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
+{
+    memset(cpumap->map, 0, cpumap->size);
+}
+static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
+{
+    return cpu >=3D 0 && cpu < (cpumap->size * 8);
+}
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
 #define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
                                              if (libxl_cpumap_test(&(m), v=
))
diff -r d76603510485 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:42 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:47 2012 +0000
@@ -288,16 +288,72 @@ static void dolog(const char *file, int=20
         libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
 }
=20
+static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
+{
+    int i;
+    uint8_t pmap =3D 0, bitmask =3D 0;
+    int firstset =3D 0, state =3D 0;
+
+    for (i =3D 0; i < maplen; i++) {
+        if (i % 8 =3D=3D 0) {
+            pmap =3D *map++;
+            bitmask =3D 1;
+        } else bitmask <<=3D 1;
+
+        switch (state) {
+        case 0:
+        case 2:
+            if ((pmap & bitmask) !=3D 0) {
+                firstset =3D i;
+                state++;
+            }
+            continue;
+        case 1:
+        case 3:
+            if ((pmap & bitmask) =3D=3D 0) {
+                fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
+                if (i - 1 > firstset)
+                    fprintf(stream, "-%d", i - 1);
+                state =3D 2;
+            }
+            continue;
+        }
+    }
+    switch (state) {
+        case 0:
+            fprintf(stream, "none");
+            break;
+        case 2:
+            break;
+        case 1:
+            if (firstset =3D=3D 0) {
+                fprintf(stream, "any cpu");
+                break;
+            }
+        case 3:
+            fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
+            if (i - 1 > firstset)
+                fprintf(stream, "-%d", i - 1);
+            break;
+    }
+}
+
 static void printf_info(int domid,
                         libxl_domain_config *d_config,
                         libxl_device_model_info *dm_info)
 {
-    int i;
+    int i, nr_cpus =3D -1;
     libxl_dominfo info;
+    libxl_physinfo physinfo;
=20
     libxl_domain_create_info *c_info =3D &d_config->c_info;
     libxl_domain_build_info *b_info =3D &d_config->b_info;
=20
+    if (libxl_get_physinfo(ctx, &physinfo) =3D=3D 0)
+        nr_cpus =3D physinfo.nr_cpus;
+    else
+        fprintf(stderr, "libxl_physinfo failed.\n");
+
     printf("(domain\n\t(domid %d)\n", domid);
     printf("\t(create_info)\n");
     printf("\t(hvm %d)\n", c_info->type =3D=3D LIBXL_DOMAIN_TYPE_HVM);
@@ -328,6 +384,9 @@ static void printf_info(int domid,
=20
     printf("\t(build_info)\n");
     printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
+    printf("\t(CPU affinity ");
+    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);
+    printf(")\n");
     printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode)=
);
     printf("\t(max_memkb %d)\n", b_info->max_memkb);
     printf("\t(target_memkb %d)\n", b_info->target_memkb);
@@ -569,6 +628,8 @@ static void split_string_into_string_lis
     free(s);
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -578,7 +639,7 @@ static void parse_config_data(const char
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int e;
@@ -661,6 +722,29 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus =3D l;
=20
+    if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
+        int i, n_cpus =3D 0;
+
+        libxl_cpumap_set_none(&b_info->cpumap);
+        while ((buf =3D xlu_cfg_get_listitem(cpus, n_cpus)) !=3D NULL) {
+            i =3D atoi(buf);
+            if (!libxl_cpumap_cpu_valid(&b_info->cpumap, i)) {
+                fprintf(stderr, "cpu %d illegal\n", i);
+                exit(1);
+            }
+            libxl_cpumap_set(&b_info->cpumap, i);
+            n_cpus++;
+        }
+    }
+    else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
+        char *buf2 =3D strdup(buf);
+
+        libxl_cpumap_set_none(&b_info->cpumap);
+        if (vcpupin_parse(buf2, &b_info->cpumap))
+            exit(1);
+        free(buf2);
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb =3D l * 1024;
         b_info->target_memkb =3D b_info->max_memkb;
@@ -3357,56 +3441,6 @@ int main_button_press(int argc, char **a
     return 0;
 }
=20
-static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
-{
-    int i;
-    uint8_t pmap =3D 0, bitmask =3D 0;
-    int firstset =3D 0, state =3D 0;
-
-    for (i =3D 0; i < maplen; i++) {
-        if (i % 8 =3D=3D 0) {
-            pmap =3D *map++;
-            bitmask =3D 1;
-        } else bitmask <<=3D 1;
-
-        switch (state) {
-        case 0:
-        case 2:
-            if ((pmap & bitmask) !=3D 0) {
-                firstset =3D i;
-                state++;
-            }
-            continue;
-        case 1:
-        case 3:
-            if ((pmap & bitmask) =3D=3D 0) {
-                fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
-                if (i - 1 > firstset)
-                    fprintf(stream, "-%d", i - 1);
-                state =3D 2;
-            }
-            continue;
-        }
-    }
-    switch (state) {
-        case 0:
-            fprintf(stream, "none");
-            break;
-        case 2:
-            break;
-        case 1:
-            if (firstset =3D=3D 0) {
-                fprintf(stream, "any cpu");
-                break;
-            }
-        case 3:
-            fprintf(stream, "%s%d", state > 1 ? "," : "", firstset);
-            if (i - 1 > firstset)
-                fprintf(stream, "-%d", i - 1);
-            break;
-    }
-}
-
 static void print_vcpuinfo(uint32_t tdomid,
                            const libxl_vcpuinfo *vcpuinfo,
                            uint32_t nr_cpus)
@@ -3511,7 +3545,7 @@ static int vcpupin_parse(char *cpu, libx
     int i, ret =3D 0;
=20
     if (!strcmp(cpu, "all")) {
-        memset(cpumap->map, -1, cpumap->size);
+        libxl_cpumap_set_any(cpumap);
         return 0;
     }
=20

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-1nQzzaDXmGx+98o0WDTe
Content-Disposition: attachment; filename="support-cpus-par-in-config-file.patch"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="support-cpus-par-in-config-file.patch";
	charset="UTF-8"

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGQ3NjYwMzUxMDQ4NWJiZDY5YjMwOTA1NTk5
ZjI4ODNiYzBmYjliNjcNCmxpYnhsOiBhbGxvdyBmb3Igc3BlY2lmeWluZyB0aGUgQ1BVIGFmZmlu
aXR5IGluIHRoZSBjb25maWcgZmlsZS4NCg0KRW5hYmxlIENQVSBhZmZpbml0eSBzcGVjaWZpY2F0
aW9uIGluIGEgVk0ncyBjb25maWcgZmlsZSB3aXRoIHRoZQ0KZXhhY3Qgc3ludGF4IGB4bCB2Y3B1
LXBpbicgcHJvdmlkZXMuDQoNClNpZ25lZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5m
YWdnaW9saUBjaXRyaXguY29tPg0KDQpkaWZmIC1yIGQ3NjYwMzUxMDQ4NSB0b29scy9saWJ4bC9s
aWJ4bC5jDQotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCU1vbiBKYW4gMjMgMTg6MDI6NDIgMjAx
MiArMDAwMA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYwlNb24gSmFuIDIzIDE4OjAyOjQ3IDIw
MTIgKzAwMDANCkBAIC0yNjYzLDYgKzI2NjMsMjAgQEAgaW50IGxpYnhsX3NldF92Y3B1YWZmaW5p
dHkobGlieGxfY3R4ICpjdA0KICAgICByZXR1cm4gMDsNCiB9DQogDQoraW50IGxpYnhsX3NldF92
Y3B1YWZmaW5pdHlfYWxsKGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IG1heF92Y3B1cywgbGlieGxfY3B1
bWFwICpjcHVtYXApDQorew0KKyAgICBpbnQgaSwgcmMgPSAwOw0KKw0KKyAgICBmb3IgKGkgPSAw
OyBpIDwgbWF4X3ZjcHVzOyBpKyspIHsNCisgICAgICAgIGlmIChsaWJ4bF9zZXRfdmNwdWFmZmlu
aXR5KGN0eCwgZG9taWQsIGksIGNwdW1hcCkpIHsNCisgICAgICAgICAgICBMSUJYTF9fTE9HKGN0
eCwgTElCWExfX0xPR19XQVJOSU5HLCAibm8gYWZmaW5pdHkgZm9yIGNwdSAlZCIsIGkpOw0KKyAg
ICAgICAgICAgIHJjID0gRVJST1JfRkFJTDsNCisgICAgICAgIH0NCisgICAgfQ0KKyAgICByZXR1
cm4gcmM7DQorfQ0KKw0KIGludCBsaWJ4bF9zZXRfdmNwdW9ubGluZShsaWJ4bF9jdHggKmN0eCwg
dWludDMyX3QgZG9taWQsIGxpYnhsX2NwdW1hcCAqY3B1bWFwKQ0KIHsNCiAgICAgR0NfSU5JVChj
dHgpOw0KZGlmZiAtciBkNzY2MDM1MTA0ODUgdG9vbHMvbGlieGwvbGlieGwuaA0KLS0tIGEvdG9v
bHMvbGlieGwvbGlieGwuaAlNb24gSmFuIDIzIDE4OjAyOjQyIDIwMTIgKzAwMDANCisrKyBiL3Rv
b2xzL2xpYnhsL2xpYnhsLmgJTW9uIEphbiAyMyAxODowMjo0NyAyMDEyICswMDAwDQpAQCAtNTYw
LDYgKzU2MCw4IEBAIGxpYnhsX3ZjcHVpbmZvICpsaWJ4bF9saXN0X3ZjcHUobGlieGxfY3QNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpbnQgKm5iX3ZjcHUsIGludCAq
bnJjcHVzKTsNCiBpbnQgbGlieGxfc2V0X3ZjcHVhZmZpbml0eShsaWJ4bF9jdHggKmN0eCwgdWlu
dDMyX3QgZG9taWQsIHVpbnQzMl90IHZjcHVpZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBsaWJ4bF9jcHVtYXAgKmNwdW1hcCk7DQoraW50IGxpYnhsX3NldF92Y3B1YWZmaW5pdHlfYWxs
KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgdW5zaWduZWQgaW50IG1heF92Y3B1cywgbGlieGxfY3B1bWFwICpjcHVtYXApOw0K
IGludCBsaWJ4bF9zZXRfdmNwdW9ubGluZShsaWJ4bF9jdHggKmN0eCwgdWludDMyX3QgZG9taWQs
IGxpYnhsX2NwdW1hcCAqY3B1bWFwKTsNCiANCiBpbnQgbGlieGxfZ2V0X3NjaGVkX2lkKGxpYnhs
X2N0eCAqY3R4KTsNCmRpZmYgLXIgZDc2NjAzNTEwNDg1IHRvb2xzL2xpYnhsL2xpYnhsX2NyZWF0
ZS5jDQotLS0gYS90b29scy9saWJ4bC9saWJ4bF9jcmVhdGUuYwlNb24gSmFuIDIzIDE4OjAyOjQy
IDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2NyZWF0ZS5jCU1vbiBKYW4gMjMg
MTg6MDI6NDcgMjAxMiArMDAwMA0KQEAgLTcxLDYgKzcxLDkgQEAgaW50IGxpYnhsX2luaXRfYnVp
bGRfaW5mbyhsaWJ4bF9jdHggKmN0eA0KICAgICBtZW1zZXQoYl9pbmZvLCAnXDAnLCBzaXplb2Yo
KmJfaW5mbykpOw0KICAgICBiX2luZm8tPm1heF92Y3B1cyA9IDE7DQogICAgIGJfaW5mby0+Y3Vy
X3ZjcHVzID0gMTsNCisgICAgaWYgKGxpYnhsX2NwdW1hcF9hbGxvYyhjdHgsICZiX2luZm8tPmNw
dW1hcCkpDQorICAgICAgICByZXR1cm4gRVJST1JfTk9NRU07DQorICAgIGxpYnhsX2NwdW1hcF9z
ZXRfYW55KCZiX2luZm8tPmNwdW1hcCk7DQogICAgIGJfaW5mby0+bWF4X21lbWtiID0gMzIgKiAx
MDI0Ow0KICAgICBiX2luZm8tPnRhcmdldF9tZW1rYiA9IGJfaW5mby0+bWF4X21lbWtiOw0KICAg
ICBiX2luZm8tPmRpc2FibGVfbWlncmF0ZSA9IDA7DQpkaWZmIC1yIGQ3NjYwMzUxMDQ4NSB0b29s
cy9saWJ4bC9saWJ4bF9kb20uYw0KLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfZG9tLmMJTW9uIEph
biAyMyAxODowMjo0MiAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF9kb20uYwlN
b24gSmFuIDIzIDE4OjAyOjQ3IDIwMTIgKzAwMDANCkBAIC02NSw2ICs2NSw3IEBAIGludCBsaWJ4
bF9fYnVpbGRfcHJlKGxpYnhsX19nYyAqZ2MsIHVpbnQNCiAgICAgbGlieGxfY3R4ICpjdHggPSBs
aWJ4bF9fZ2Nfb3duZXIoZ2MpOw0KICAgICBpbnQgdHNjX21vZGU7DQogICAgIHhjX2RvbWFpbl9t
YXhfdmNwdXMoY3R4LT54Y2gsIGRvbWlkLCBpbmZvLT5tYXhfdmNwdXMpOw0KKyAgICBsaWJ4bF9z
ZXRfdmNwdWFmZmluaXR5X2FsbChjdHgsIGRvbWlkLCBpbmZvLT5tYXhfdmNwdXMsICZpbmZvLT5j
cHVtYXApOw0KICAgICB4Y19kb21haW5fc2V0bWF4bWVtKGN0eC0+eGNoLCBkb21pZCwgaW5mby0+
dGFyZ2V0X21lbWtiICsgTElCWExfTUFYTUVNX0NPTlNUQU5UKTsNCiAgICAgaWYgKGluZm8tPnR5
cGUgPT0gTElCWExfRE9NQUlOX1RZUEVfUFYpDQogICAgICAgICB4Y19kb21haW5fc2V0X21lbW1h
cF9saW1pdChjdHgtPnhjaCwgZG9taWQsDQpkaWZmIC1yIGQ3NjYwMzUxMDQ4NSB0b29scy9saWJ4
bC9saWJ4bF90eXBlcy5pZGwNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbAlNb24g
SmFuIDIzIDE4OjAyOjQyIDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3R5cGVz
LmlkbAlNb24gSmFuIDIzIDE4OjAyOjQ3IDIwMTIgKzAwMDANCkBAIC0xNjIsNiArMTYyLDcgQEAg
bGlieGxfZG9tYWluX2NyZWF0ZV9pbmZvID0gU3RydWN0KCJkb21haQ0KIGxpYnhsX2RvbWFpbl9i
dWlsZF9pbmZvID0gU3RydWN0KCJkb21haW5fYnVpbGRfaW5mbyIsWw0KICAgICAoIm1heF92Y3B1
cyIsICAgICAgIGludGVnZXIpLA0KICAgICAoImN1cl92Y3B1cyIsICAgICAgIGludGVnZXIpLA0K
KyAgICAoImNwdW1hcCIsICAgICAgICAgIGxpYnhsX2NwdW1hcCksDQogICAgICgidHNjX21vZGUi
LCAgICAgICAgbGlieGxfdHNjX21vZGUpLA0KICAgICAoIm1heF9tZW1rYiIsICAgICAgIHVpbnQz
MiksDQogICAgICgidGFyZ2V0X21lbWtiIiwgICAgdWludDMyKSwNCmRpZmYgLXIgZDc2NjAzNTEw
NDg1IHRvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3V0
aWxzLmgJTW9uIEphbiAyMyAxODowMjo0MiAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9s
aWJ4bF91dGlscy5oCU1vbiBKYW4gMjMgMTg6MDI6NDcgMjAxMiArMDAwMA0KQEAgLTcwLDYgKzcw
LDE4IEBAIGludCBsaWJ4bF9jcHVtYXBfYWxsb2MobGlieGxfY3R4ICpjdHgsIGwNCiBpbnQgbGli
eGxfY3B1bWFwX3Rlc3QobGlieGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KIHZvaWQgbGli
eGxfY3B1bWFwX3NldChsaWJ4bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4
bF9jcHVtYXBfcmVzZXQobGlieGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KK3N0YXRpYyBp
bmxpbmUgdm9pZCBsaWJ4bF9jcHVtYXBfc2V0X2FueShsaWJ4bF9jcHVtYXAgKmNwdW1hcCkNCit7
DQorICAgIG1lbXNldChjcHVtYXAtPm1hcCwgLTEsIGNwdW1hcC0+c2l6ZSk7DQorfQ0KK3N0YXRp
YyBpbmxpbmUgdm9pZCBsaWJ4bF9jcHVtYXBfc2V0X25vbmUobGlieGxfY3B1bWFwICpjcHVtYXAp
DQorew0KKyAgICBtZW1zZXQoY3B1bWFwLT5tYXAsIDAsIGNwdW1hcC0+c2l6ZSk7DQorfQ0KK3N0
YXRpYyBpbmxpbmUgaW50IGxpYnhsX2NwdW1hcF9jcHVfdmFsaWQobGlieGxfY3B1bWFwICpjcHVt
YXAsIGludCBjcHUpDQorew0KKyAgICByZXR1cm4gY3B1ID49IDAgJiYgY3B1IDwgKGNwdW1hcC0+
c2l6ZSAqIDgpOw0KK30NCiAjZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX2NwdSh2YXIsIG1hcCkgZm9y
ICh2YXIgPSAwOyB2YXIgPCAobWFwKS5zaXplICogODsgdmFyKyspDQogI2RlZmluZSBsaWJ4bF9m
b3JfZWFjaF9zZXRfY3B1KHYsIG0pIGZvciAodiA9IDA7IHYgPCAobSkuc2l6ZSAqIDg7IHYrKykg
XA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIChsaWJ4
bF9jcHVtYXBfdGVzdCgmKG0pLCB2KSkNCmRpZmYgLXIgZDc2NjAzNTEwNDg1IHRvb2xzL2xpYnhs
L3hsX2NtZGltcGwuYw0KLS0tIGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBKYW4gMjMg
MTg6MDI6NDIgMjAxMiArMDAwMA0KKysrIGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCU1vbiBK
YW4gMjMgMTg6MDI6NDcgMjAxMiArMDAwMA0KQEAgLTI4OCwxNiArMjg4LDcyIEBAIHN0YXRpYyB2
b2lkIGRvbG9nKGNvbnN0IGNoYXIgKmZpbGUsIGludCANCiAgICAgICAgIGxpYnhsX3dyaXRlX2V4
YWN0bHkoTlVMTCwgbG9nZmlsZSwgcywgcmMsIE5VTEwsIE5VTEwpOw0KIH0NCiANCitzdGF0aWMg
dm9pZCBwcmludF9iaXRtYXAodWludDhfdCAqbWFwLCBpbnQgbWFwbGVuLCBGSUxFICpzdHJlYW0p
DQorew0KKyAgICBpbnQgaTsNCisgICAgdWludDhfdCBwbWFwID0gMCwgYml0bWFzayA9IDA7DQor
ICAgIGludCBmaXJzdHNldCA9IDAsIHN0YXRlID0gMDsNCisNCisgICAgZm9yIChpID0gMDsgaSA8
IG1hcGxlbjsgaSsrKSB7DQorICAgICAgICBpZiAoaSAlIDggPT0gMCkgew0KKyAgICAgICAgICAg
IHBtYXAgPSAqbWFwKys7DQorICAgICAgICAgICAgYml0bWFzayA9IDE7DQorICAgICAgICB9IGVs
c2UgYml0bWFzayA8PD0gMTsNCisNCisgICAgICAgIHN3aXRjaCAoc3RhdGUpIHsNCisgICAgICAg
IGNhc2UgMDoNCisgICAgICAgIGNhc2UgMjoNCisgICAgICAgICAgICBpZiAoKHBtYXAgJiBiaXRt
YXNrKSAhPSAwKSB7DQorICAgICAgICAgICAgICAgIGZpcnN0c2V0ID0gaTsNCisgICAgICAgICAg
ICAgICAgc3RhdGUrKzsNCisgICAgICAgICAgICB9DQorICAgICAgICAgICAgY29udGludWU7DQor
ICAgICAgICBjYXNlIDE6DQorICAgICAgICBjYXNlIDM6DQorICAgICAgICAgICAgaWYgKChwbWFw
ICYgYml0bWFzaykgPT0gMCkgew0KKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0cmVhbSwgIiVz
JWQiLCBzdGF0ZSA+IDEgPyAiLCIgOiAiIiwgZmlyc3RzZXQpOw0KKyAgICAgICAgICAgICAgICBp
ZiAoaSAtIDEgPiBmaXJzdHNldCkNCisgICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RyZWFt
LCAiLSVkIiwgaSAtIDEpOw0KKyAgICAgICAgICAgICAgICBzdGF0ZSA9IDI7DQorICAgICAgICAg
ICAgfQ0KKyAgICAgICAgICAgIGNvbnRpbnVlOw0KKyAgICAgICAgfQ0KKyAgICB9DQorICAgIHN3
aXRjaCAoc3RhdGUpIHsNCisgICAgICAgIGNhc2UgMDoNCisgICAgICAgICAgICBmcHJpbnRmKHN0
cmVhbSwgIm5vbmUiKTsNCisgICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgMjoNCisg
ICAgICAgICAgICBicmVhazsNCisgICAgICAgIGNhc2UgMToNCisgICAgICAgICAgICBpZiAoZmly
c3RzZXQgPT0gMCkgew0KKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0cmVhbSwgImFueSBjcHUi
KTsNCisgICAgICAgICAgICAgICAgYnJlYWs7DQorICAgICAgICAgICAgfQ0KKyAgICAgICAgY2Fz
ZSAzOg0KKyAgICAgICAgICAgIGZwcmludGYoc3RyZWFtLCAiJXMlZCIsIHN0YXRlID4gMSA/ICIs
IiA6ICIiLCBmaXJzdHNldCk7DQorICAgICAgICAgICAgaWYgKGkgLSAxID4gZmlyc3RzZXQpDQor
ICAgICAgICAgICAgICAgIGZwcmludGYoc3RyZWFtLCAiLSVkIiwgaSAtIDEpOw0KKyAgICAgICAg
ICAgIGJyZWFrOw0KKyAgICB9DQorfQ0KKw0KIHN0YXRpYyB2b2lkIHByaW50Zl9pbmZvKGludCBk
b21pZCwNCiAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kb21haW5fY29uZmlnICpkX2Nv
bmZpZywNCiAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9kZXZpY2VfbW9kZWxfaW5mbyAq
ZG1faW5mbykNCiB7DQotICAgIGludCBpOw0KKyAgICBpbnQgaSwgbnJfY3B1cyA9IC0xOw0KICAg
ICBsaWJ4bF9kb21pbmZvIGluZm87DQorICAgIGxpYnhsX3BoeXNpbmZvIHBoeXNpbmZvOw0KIA0K
ICAgICBsaWJ4bF9kb21haW5fY3JlYXRlX2luZm8gKmNfaW5mbyA9ICZkX2NvbmZpZy0+Y19pbmZv
Ow0KICAgICBsaWJ4bF9kb21haW5fYnVpbGRfaW5mbyAqYl9pbmZvID0gJmRfY29uZmlnLT5iX2lu
Zm87DQogDQorICAgIGlmIChsaWJ4bF9nZXRfcGh5c2luZm8oY3R4LCAmcGh5c2luZm8pID09IDAp
DQorICAgICAgICBucl9jcHVzID0gcGh5c2luZm8ubnJfY3B1czsNCisgICAgZWxzZQ0KKyAgICAg
ICAgZnByaW50ZihzdGRlcnIsICJsaWJ4bF9waHlzaW5mbyBmYWlsZWQuXG4iKTsNCisNCiAgICAg
cHJpbnRmKCIoZG9tYWluXG5cdChkb21pZCAlZClcbiIsIGRvbWlkKTsNCiAgICAgcHJpbnRmKCJc
dChjcmVhdGVfaW5mbylcbiIpOw0KICAgICBwcmludGYoIlx0KGh2bSAlZClcbiIsIGNfaW5mby0+
dHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9IVk0pOw0KQEAgLTMyOCw2ICszODQsOSBAQCBzdGF0
aWMgdm9pZCBwcmludGZfaW5mbyhpbnQgZG9taWQsDQogDQogICAgIHByaW50ZigiXHQoYnVpbGRf
aW5mbylcbiIpOw0KICAgICBwcmludGYoIlx0KG1heF92Y3B1cyAlZClcbiIsIGJfaW5mby0+bWF4
X3ZjcHVzKTsNCisgICAgcHJpbnRmKCJcdChDUFUgYWZmaW5pdHkgIik7DQorICAgIHByaW50X2Jp
dG1hcChiX2luZm8tPmNwdW1hcC5tYXAsIG5yX2NwdXMsIHN0ZG91dCk7DQorICAgIHByaW50Zigi
KVxuIik7DQogICAgIHByaW50ZigiXHQodHNjX21vZGUgJXMpXG4iLCBsaWJ4bF90c2NfbW9kZV90
b19zdHJpbmcoYl9pbmZvLT50c2NfbW9kZSkpOw0KICAgICBwcmludGYoIlx0KG1heF9tZW1rYiAl
ZClcbiIsIGJfaW5mby0+bWF4X21lbWtiKTsNCiAgICAgcHJpbnRmKCJcdCh0YXJnZXRfbWVta2Ig
JWQpXG4iLCBiX2luZm8tPnRhcmdldF9tZW1rYik7DQpAQCAtNTY5LDYgKzYyOCw4IEBAIHN0YXRp
YyB2b2lkIHNwbGl0X3N0cmluZ19pbnRvX3N0cmluZ19saXMNCiAgICAgZnJlZShzKTsNCiB9DQog
DQorc3RhdGljIGludCB2Y3B1cGluX3BhcnNlKGNoYXIgKmNwdSwgbGlieGxfY3B1bWFwICpjcHVt
YXApOw0KKw0KIHN0YXRpYyB2b2lkIHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXIgKmNvbmZp
Z2ZpbGVfZmlsZW5hbWVfcmVwb3J0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv
bnN0IGNoYXIgKmNvbmZpZ2ZpbGVfZGF0YSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBpbnQgY29uZmlnZmlsZV9sZW4sDQpAQCAtNTc4LDcgKzYzOSw3IEBAIHN0YXRpYyB2b2lkIHBh
cnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXINCiAgICAgY29uc3QgY2hhciAqYnVmOw0KICAgICBs
b25nIGw7DQogICAgIFhMVV9Db25maWcgKmNvbmZpZzsNCi0gICAgWExVX0NvbmZpZ0xpc3QgKnZi
ZHMsICpuaWNzLCAqcGNpcywgKmN2ZmJzLCAqY3B1aWRzOw0KKyAgICBYTFVfQ29uZmlnTGlzdCAq
Y3B1cywgKnZiZHMsICpuaWNzLCAqcGNpcywgKmN2ZmJzLCAqY3B1aWRzOw0KICAgICBpbnQgcGNp
X3Bvd2VyX21nbXQgPSAwOw0KICAgICBpbnQgcGNpX21zaXRyYW5zbGF0ZSA9IDE7DQogICAgIGlu
dCBlOw0KQEAgLTY2MSw2ICs3MjIsMjkgQEAgc3RhdGljIHZvaWQgcGFyc2VfY29uZmlnX2RhdGEo
Y29uc3QgY2hhcg0KICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcgKGNvbmZpZywgIm1heHZjcHVz
IiwgJmwsIDApKQ0KICAgICAgICAgYl9pbmZvLT5tYXhfdmNwdXMgPSBsOw0KIA0KKyAgICBpZiAo
IXhsdV9jZmdfZ2V0X2xpc3QgKGNvbmZpZywgImNwdXMiLCAmY3B1cywgMCwgMSkpIHsNCisgICAg
ICAgIGludCBpLCBuX2NwdXMgPSAwOw0KKw0KKyAgICAgICAgbGlieGxfY3B1bWFwX3NldF9ub25l
KCZiX2luZm8tPmNwdW1hcCk7DQorICAgICAgICB3aGlsZSAoKGJ1ZiA9IHhsdV9jZmdfZ2V0X2xp
c3RpdGVtKGNwdXMsIG5fY3B1cykpICE9IE5VTEwpIHsNCisgICAgICAgICAgICBpID0gYXRvaShi
dWYpOw0KKyAgICAgICAgICAgIGlmICghbGlieGxfY3B1bWFwX2NwdV92YWxpZCgmYl9pbmZvLT5j
cHVtYXAsIGkpKSB7DQorICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiY3B1ICVkIGls
bGVnYWxcbiIsIGkpOw0KKyAgICAgICAgICAgICAgICBleGl0KDEpOw0KKyAgICAgICAgICAgIH0N
CisgICAgICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0KCZiX2luZm8tPmNwdW1hcCwgaSk7DQorICAg
ICAgICAgICAgbl9jcHVzKys7DQorICAgICAgICB9DQorICAgIH0NCisgICAgZWxzZSBpZiAoIXhs
dV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAiY3B1cyIsICZidWYsIDApKSB7DQorICAgICAgICBj
aGFyICpidWYyID0gc3RyZHVwKGJ1Zik7DQorDQorICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0X25v
bmUoJmJfaW5mby0+Y3B1bWFwKTsNCisgICAgICAgIGlmICh2Y3B1cGluX3BhcnNlKGJ1ZjIsICZi
X2luZm8tPmNwdW1hcCkpDQorICAgICAgICAgICAgZXhpdCgxKTsNCisgICAgICAgIGZyZWUoYnVm
Mik7DQorICAgIH0NCisNCiAgICAgaWYgKCF4bHVfY2ZnX2dldF9sb25nIChjb25maWcsICJtZW1v
cnkiLCAmbCwgMCkpIHsNCiAgICAgICAgIGJfaW5mby0+bWF4X21lbWtiID0gbCAqIDEwMjQ7DQog
ICAgICAgICBiX2luZm8tPnRhcmdldF9tZW1rYiA9IGJfaW5mby0+bWF4X21lbWtiOw0KQEAgLTMz
NTcsNTYgKzM0NDEsNiBAQCBpbnQgbWFpbl9idXR0b25fcHJlc3MoaW50IGFyZ2MsIGNoYXIgKiph
DQogICAgIHJldHVybiAwOw0KIH0NCiANCi1zdGF0aWMgdm9pZCBwcmludF9iaXRtYXAodWludDhf
dCAqbWFwLCBpbnQgbWFwbGVuLCBGSUxFICpzdHJlYW0pDQotew0KLSAgICBpbnQgaTsNCi0gICAg
dWludDhfdCBwbWFwID0gMCwgYml0bWFzayA9IDA7DQotICAgIGludCBmaXJzdHNldCA9IDAsIHN0
YXRlID0gMDsNCi0NCi0gICAgZm9yIChpID0gMDsgaSA8IG1hcGxlbjsgaSsrKSB7DQotICAgICAg
ICBpZiAoaSAlIDggPT0gMCkgew0KLSAgICAgICAgICAgIHBtYXAgPSAqbWFwKys7DQotICAgICAg
ICAgICAgYml0bWFzayA9IDE7DQotICAgICAgICB9IGVsc2UgYml0bWFzayA8PD0gMTsNCi0NCi0g
ICAgICAgIHN3aXRjaCAoc3RhdGUpIHsNCi0gICAgICAgIGNhc2UgMDoNCi0gICAgICAgIGNhc2Ug
MjoNCi0gICAgICAgICAgICBpZiAoKHBtYXAgJiBiaXRtYXNrKSAhPSAwKSB7DQotICAgICAgICAg
ICAgICAgIGZpcnN0c2V0ID0gaTsNCi0gICAgICAgICAgICAgICAgc3RhdGUrKzsNCi0gICAgICAg
ICAgICB9DQotICAgICAgICAgICAgY29udGludWU7DQotICAgICAgICBjYXNlIDE6DQotICAgICAg
ICBjYXNlIDM6DQotICAgICAgICAgICAgaWYgKChwbWFwICYgYml0bWFzaykgPT0gMCkgew0KLSAg
ICAgICAgICAgICAgICBmcHJpbnRmKHN0cmVhbSwgIiVzJWQiLCBzdGF0ZSA+IDEgPyAiLCIgOiAi
IiwgZmlyc3RzZXQpOw0KLSAgICAgICAgICAgICAgICBpZiAoaSAtIDEgPiBmaXJzdHNldCkNCi0g
ICAgICAgICAgICAgICAgICAgIGZwcmludGYoc3RyZWFtLCAiLSVkIiwgaSAtIDEpOw0KLSAgICAg
ICAgICAgICAgICBzdGF0ZSA9IDI7DQotICAgICAgICAgICAgfQ0KLSAgICAgICAgICAgIGNvbnRp
bnVlOw0KLSAgICAgICAgfQ0KLSAgICB9DQotICAgIHN3aXRjaCAoc3RhdGUpIHsNCi0gICAgICAg
IGNhc2UgMDoNCi0gICAgICAgICAgICBmcHJpbnRmKHN0cmVhbSwgIm5vbmUiKTsNCi0gICAgICAg
ICAgICBicmVhazsNCi0gICAgICAgIGNhc2UgMjoNCi0gICAgICAgICAgICBicmVhazsNCi0gICAg
ICAgIGNhc2UgMToNCi0gICAgICAgICAgICBpZiAoZmlyc3RzZXQgPT0gMCkgew0KLSAgICAgICAg
ICAgICAgICBmcHJpbnRmKHN0cmVhbSwgImFueSBjcHUiKTsNCi0gICAgICAgICAgICAgICAgYnJl
YWs7DQotICAgICAgICAgICAgfQ0KLSAgICAgICAgY2FzZSAzOg0KLSAgICAgICAgICAgIGZwcmlu
dGYoc3RyZWFtLCAiJXMlZCIsIHN0YXRlID4gMSA/ICIsIiA6ICIiLCBmaXJzdHNldCk7DQotICAg
ICAgICAgICAgaWYgKGkgLSAxID4gZmlyc3RzZXQpDQotICAgICAgICAgICAgICAgIGZwcmludGYo
c3RyZWFtLCAiLSVkIiwgaSAtIDEpOw0KLSAgICAgICAgICAgIGJyZWFrOw0KLSAgICB9DQotfQ0K
LQ0KIHN0YXRpYyB2b2lkIHByaW50X3ZjcHVpbmZvKHVpbnQzMl90IHRkb21pZCwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICBjb25zdCBsaWJ4bF92Y3B1aW5mbyAqdmNwdWluZm8sDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgbnJfY3B1cykNCkBAIC0zNTExLDcgKzM1
NDUsNyBAQCBzdGF0aWMgaW50IHZjcHVwaW5fcGFyc2UoY2hhciAqY3B1LCBsaWJ4DQogICAgIGlu
dCBpLCByZXQgPSAwOw0KIA0KICAgICBpZiAoIXN0cmNtcChjcHUsICJhbGwiKSkgew0KLSAgICAg
ICAgbWVtc2V0KGNwdW1hcC0+bWFwLCAtMSwgY3B1bWFwLT5zaXplKTsNCisgICAgICAgIGxpYnhs
X2NwdW1hcF9zZXRfYW55KGNwdW1hcCk7DQogICAgICAgICByZXR1cm4gMDsNCiAgICAgfQ0KIA0K



--=-1nQzzaDXmGx+98o0WDTe--

--=-rWAN+8NqY296F6OOQ8N3
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)

iEYEABECAAYFAk8dpVQACgkQk4XaBE3IOsTtBACgrLQy/A8ygYKA9s9zyN3cZla9
CcwAn04lHYqy9z8hdGLb9FGBn2fcF+rf
=f7Ma
-----END PGP SIGNATURE-----

--=-rWAN+8NqY296F6OOQ8N3--



--===============5201230328339749710==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5201230328339749710==--



From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:27:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpObt-0002w1-BP; Mon, 23 Jan 2012 18:27:17 +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 1RpObs-0002va-HI
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:27:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327343228!10283226!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17523 invoked from network); 23 Jan 2012 18:27:10 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 18:27:10 -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
	q0NIR2E1024414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:27:03 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
	q0NIR0la008771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:27:01 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
	q0NIQwMr012760; Mon, 23 Jan 2012 12:26:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:26:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4EDAF40157; Mon, 23 Jan 2012 13:24:43 -0500 (EST)
Date: Mon, 23 Jan 2012 13:24:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tina Yang <tina.yang@oracle.com>, davem@davemloft.net
Message-ID: <20120123182443.GA22963@phenom.dumpdata.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
	<4F160113.1030503@oracle.com>
	<1326877176.29475.37.camel@dagon.hellion.org.uk>
	<4F173467.90106@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F173467.90106@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.0A090207.4F1DA679.0071,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 18, 2012 at 01:06:47PM -0800, Tina Yang wrote:
> On 1/18/2012 12:59 AM, Ian Campbell wrote:
> >On Tue, 2012-01-17 at 23:15 +0000, Tina Yang wrote:
> >>On 1/17/2012 1:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
> >>>>On 1/13/2012 3:06 AM, Ian Campbell wrote:
> >>>>Although netdump is now obsolete, I think it's always a good practice
> >>>>to preserve caller's irq status as we had a very bad experience
> >>>>chasing a similar problem caused by such a irq change in RDS
> >>>Did you find the culprit of it? Was there a patch for that in the
> >>>upstream kernel?
> >>Yes.  It has nothing to do with net drivers but same cause
> >>elsewhere in the kernel.
> >I didn't think start_xmit could be called with interrupts disabled or
> >from interrupt context but perhaps I am wrong about that or perhaps
> >netconsole changes things?
> Netdump does call it with interrupt disabled and hang because of
> it in 2.6.9 as I remember it.  And you are right, netconsole has
> undergone changes from time to time, which also can change
> this specification.
> >
> >Right, Documentation/networking/netdevices.txt states that start_xmit
> >can be called with interrupts disabled by netconsole and therefore using
> >the irqsave/restore locking in this function is, AFAICT, correct.

Ok, so let me update the git commit description to include this.

I am listed as the maintainer but I would have thought that it should
go through David?

David, should it go through you or should I stick it in my tree? Here
is the patch with a better git description.

>From 1c265b7946f222ab6a5aac5245a0ab84618772c8 Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date: Thu, 12 Jan 2012 10:18:29 +0800
Subject: [PATCH] xen/netfront: add netconsole support.

add polling interface to xen-netfront device to support netconsole

This patch also alters the spin_lock usage to use irqsave variant.
Documentation/networking/netdevices.txt states that start_xmit
can be called with interrupts disabled by netconsole and therefore using
the irqsave/restore locking in this function is looks correct.

Signed-off-by: Tina.Yang <tina.yang@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
Tested-by: gurudas.pai <gurudas.pai@oracle.com>
[v1: Copy-n-pasted Ian Campbell comments]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
 1 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d29365a..5a4b5df 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -478,6 +478,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	int frags = skb_shinfo(skb)->nr_frags;
 	unsigned int offset = offset_in_page(data);
 	unsigned int len = skb_headlen(skb);
+	unsigned long flags;
 
 	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
 	if (unlikely(frags > MAX_SKB_FRAGS + 1)) {
@@ -487,12 +488,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 	}
 
-	spin_lock_irq(&np->tx_lock);
+	spin_lock_irqsave(&np->tx_lock, flags);
 
 	if (unlikely(!netif_carrier_ok(dev) ||
 		     (frags > 1 && !xennet_can_sg(dev)) ||
 		     netif_needs_gso(skb, netif_skb_features(skb)))) {
-		spin_unlock_irq(&np->tx_lock);
+		spin_unlock_irqrestore(&np->tx_lock, flags);
 		goto drop;
 	}
 
@@ -561,7 +562,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	if (!netfront_tx_slot_available(np))
 		netif_stop_queue(dev);
 
-	spin_unlock_irq(&np->tx_lock);
+	spin_unlock_irqrestore(&np->tx_lock, flags);
 
 	return NETDEV_TX_OK;
 
@@ -1176,6 +1177,33 @@ static int xennet_set_features(struct net_device *dev, u32 features)
 	return 0;
 }
 
+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+{
+	struct net_device *dev = dev_id;
+	struct netfront_info *np = netdev_priv(dev);
+	unsigned long flags;
+
+	spin_lock_irqsave(&np->tx_lock, flags);
+
+	if (likely(netif_carrier_ok(dev))) {
+		xennet_tx_buf_gc(dev);
+		/* Under tx_lock: protects access to rx shared-ring indexes. */
+		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
+			napi_schedule(&np->napi);
+	}
+
+	spin_unlock_irqrestore(&np->tx_lock, flags);
+
+	return IRQ_HANDLED;
+}
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void xennet_poll_controller(struct net_device *dev)
+{
+	xennet_interrupt(0, dev);
+}
+#endif
+
 static const struct net_device_ops xennet_netdev_ops = {
 	.ndo_open            = xennet_open,
 	.ndo_uninit          = xennet_uninit,
@@ -1186,6 +1214,9 @@ static const struct net_device_ops xennet_netdev_ops = {
 	.ndo_validate_addr   = eth_validate_addr,
 	.ndo_fix_features    = xennet_fix_features,
 	.ndo_set_features    = xennet_set_features,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+	.ndo_poll_controller = xennet_poll_controller,
+#endif
 };
 
 static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
@@ -1388,26 +1419,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
 	return 0;
 }
 
-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
-{
-	struct net_device *dev = dev_id;
-	struct netfront_info *np = netdev_priv(dev);
-	unsigned long flags;
-
-	spin_lock_irqsave(&np->tx_lock, flags);
-
-	if (likely(netif_carrier_ok(dev))) {
-		xennet_tx_buf_gc(dev);
-		/* Under tx_lock: protects access to rx shared-ring indexes. */
-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
-			napi_schedule(&np->napi);
-	}
-
-	spin_unlock_irqrestore(&np->tx_lock, flags);
-
-	return IRQ_HANDLED;
-}
-
 static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 {
 	struct xen_netif_tx_sring *txs;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:27:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:27:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpObt-0002w1-BP; Mon, 23 Jan 2012 18:27:17 +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 1RpObs-0002va-HI
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:27:16 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327343228!10283226!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17523 invoked from network); 23 Jan 2012 18:27:10 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 18:27:10 -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
	q0NIR2E1024414
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:27:03 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
	q0NIR0la008771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:27:01 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
	q0NIQwMr012760; Mon, 23 Jan 2012 12:26:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:26:58 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4EDAF40157; Mon, 23 Jan 2012 13:24:43 -0500 (EST)
Date: Mon, 23 Jan 2012 13:24:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Tina Yang <tina.yang@oracle.com>, davem@davemloft.net
Message-ID: <20120123182443.GA22963@phenom.dumpdata.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
	<4F160113.1030503@oracle.com>
	<1326877176.29475.37.camel@dagon.hellion.org.uk>
	<4F173467.90106@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F173467.90106@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.0A090207.4F1DA679.0071,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 18, 2012 at 01:06:47PM -0800, Tina Yang wrote:
> On 1/18/2012 12:59 AM, Ian Campbell wrote:
> >On Tue, 2012-01-17 at 23:15 +0000, Tina Yang wrote:
> >>On 1/17/2012 1:51 PM, Konrad Rzeszutek Wilk wrote:
> >>>On Tue, Jan 17, 2012 at 01:42:22PM -0800, Tina Yang wrote:
> >>>>On 1/13/2012 3:06 AM, Ian Campbell wrote:
> >>>>Although netdump is now obsolete, I think it's always a good practice
> >>>>to preserve caller's irq status as we had a very bad experience
> >>>>chasing a similar problem caused by such a irq change in RDS
> >>>Did you find the culprit of it? Was there a patch for that in the
> >>>upstream kernel?
> >>Yes.  It has nothing to do with net drivers but same cause
> >>elsewhere in the kernel.
> >I didn't think start_xmit could be called with interrupts disabled or
> >from interrupt context but perhaps I am wrong about that or perhaps
> >netconsole changes things?
> Netdump does call it with interrupt disabled and hang because of
> it in 2.6.9 as I remember it.  And you are right, netconsole has
> undergone changes from time to time, which also can change
> this specification.
> >
> >Right, Documentation/networking/netdevices.txt states that start_xmit
> >can be called with interrupts disabled by netconsole and therefore using
> >the irqsave/restore locking in this function is, AFAICT, correct.

Ok, so let me update the git commit description to include this.

I am listed as the maintainer but I would have thought that it should
go through David?

David, should it go through you or should I stick it in my tree? Here
is the patch with a better git description.

>From 1c265b7946f222ab6a5aac5245a0ab84618772c8 Mon Sep 17 00:00:00 2001
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date: Thu, 12 Jan 2012 10:18:29 +0800
Subject: [PATCH] xen/netfront: add netconsole support.

add polling interface to xen-netfront device to support netconsole

This patch also alters the spin_lock usage to use irqsave variant.
Documentation/networking/netdevices.txt states that start_xmit
can be called with interrupts disabled by netconsole and therefore using
the irqsave/restore locking in this function is looks correct.

Signed-off-by: Tina.Yang <tina.yang@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
Tested-by: gurudas.pai <gurudas.pai@oracle.com>
[v1: Copy-n-pasted Ian Campbell comments]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/net/xen-netfront.c |   57 ++++++++++++++++++++++++++-----------------
 1 files changed, 34 insertions(+), 23 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d29365a..5a4b5df 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -478,6 +478,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	int frags = skb_shinfo(skb)->nr_frags;
 	unsigned int offset = offset_in_page(data);
 	unsigned int len = skb_headlen(skb);
+	unsigned long flags;
 
 	frags += DIV_ROUND_UP(offset + len, PAGE_SIZE);
 	if (unlikely(frags > MAX_SKB_FRAGS + 1)) {
@@ -487,12 +488,12 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 	}
 
-	spin_lock_irq(&np->tx_lock);
+	spin_lock_irqsave(&np->tx_lock, flags);
 
 	if (unlikely(!netif_carrier_ok(dev) ||
 		     (frags > 1 && !xennet_can_sg(dev)) ||
 		     netif_needs_gso(skb, netif_skb_features(skb)))) {
-		spin_unlock_irq(&np->tx_lock);
+		spin_unlock_irqrestore(&np->tx_lock, flags);
 		goto drop;
 	}
 
@@ -561,7 +562,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	if (!netfront_tx_slot_available(np))
 		netif_stop_queue(dev);
 
-	spin_unlock_irq(&np->tx_lock);
+	spin_unlock_irqrestore(&np->tx_lock, flags);
 
 	return NETDEV_TX_OK;
 
@@ -1176,6 +1177,33 @@ static int xennet_set_features(struct net_device *dev, u32 features)
 	return 0;
 }
 
+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+{
+	struct net_device *dev = dev_id;
+	struct netfront_info *np = netdev_priv(dev);
+	unsigned long flags;
+
+	spin_lock_irqsave(&np->tx_lock, flags);
+
+	if (likely(netif_carrier_ok(dev))) {
+		xennet_tx_buf_gc(dev);
+		/* Under tx_lock: protects access to rx shared-ring indexes. */
+		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
+			napi_schedule(&np->napi);
+	}
+
+	spin_unlock_irqrestore(&np->tx_lock, flags);
+
+	return IRQ_HANDLED;
+}
+
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void xennet_poll_controller(struct net_device *dev)
+{
+	xennet_interrupt(0, dev);
+}
+#endif
+
 static const struct net_device_ops xennet_netdev_ops = {
 	.ndo_open            = xennet_open,
 	.ndo_uninit          = xennet_uninit,
@@ -1186,6 +1214,9 @@ static const struct net_device_ops xennet_netdev_ops = {
 	.ndo_validate_addr   = eth_validate_addr,
 	.ndo_fix_features    = xennet_fix_features,
 	.ndo_set_features    = xennet_set_features,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+	.ndo_poll_controller = xennet_poll_controller,
+#endif
 };
 
 static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev)
@@ -1388,26 +1419,6 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 mac[])
 	return 0;
 }
 
-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
-{
-	struct net_device *dev = dev_id;
-	struct netfront_info *np = netdev_priv(dev);
-	unsigned long flags;
-
-	spin_lock_irqsave(&np->tx_lock, flags);
-
-	if (likely(netif_carrier_ok(dev))) {
-		xennet_tx_buf_gc(dev);
-		/* Under tx_lock: protects access to rx shared-ring indexes. */
-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
-			napi_schedule(&np->napi);
-	}
-
-	spin_unlock_irqrestore(&np->tx_lock, flags);
-
-	return IRQ_HANDLED;
-}
-
 static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 {
 	struct xen_netif_tx_sring *txs;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:37:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18: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 1RpOlh-0003DM-L0; Mon, 23 Jan 2012 18:37: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 1RpOlg-0003DH-Mf
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:37:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327343837!9605875!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26376 invoked from network); 23 Jan 2012 18:37:18 -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; 23 Jan 2012 18:37:18 -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
	q0NIbCuM006052
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:37:13 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
	q0NIbAQ5004313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:37:11 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
	q0NIb9Yg025300; Mon, 23 Jan 2012 12:37:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:37:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DA3DF40157; Mon, 23 Jan 2012 13:34:54 -0500 (EST)
Date: Mon, 23 Jan 2012 13:34:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120123183454.GA12542@phenom.dumpdata.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-5-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325842991-4404-5-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F1DA8D9.011A,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
> Add a description to the config menu for xen tmem.

I am not sure what this patch gets us. If this is to minimize the
size of the module - so say it gets loaded, but tmem-enabled is 
not set nor cleancache and we just have it consuming memory - we can do it
via returning -ENODEV on the module load.

Like this (completley untested nor compiled tested):

>From 45b49b5d565c52e4396dae036ddb4f4094d914ec Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 13:32:17 -0500
Subject: [PATCH] xen/tmem: Return -ENODEV if the backends are not registered.

.. otherwise the driver might still reside in the memory consuming
memory (that is the theory at least).

CC: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/tmem.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
index d369965..e61b5a3 100644
--- a/drivers/xen/tmem.c
+++ b/drivers/xen/tmem.c
@@ -377,8 +377,10 @@ static struct frontswap_ops tmem_frontswap_ops = {
 
 static int __init xen_tmem_init(void)
 {
+	bool loaded = false;
+
 	if (!xen_domain())
-		return 0;
+		return -ENODEV;
 #ifdef CONFIG_FRONTSWAP
 	if (tmem_enabled && use_frontswap) {
 		char *s = "";
@@ -390,6 +392,7 @@ static int __init xen_tmem_init(void)
 			s = " (WARNING: frontswap_ops overridden)";
 		printk(KERN_INFO "frontswap enabled, RAM provided by "
 				 "Xen Transcendent Memory\n");
+		loaded = true;
 	}
 #endif
 #ifdef CONFIG_CLEANCACHE
@@ -402,9 +405,10 @@ static int __init xen_tmem_init(void)
 			s = " (WARNING: cleancache_ops overridden)";
 		printk(KERN_INFO "cleancache enabled, RAM provided by "
 				 "Xen Transcendent Memory%s\n", s);
+		loaded = true;
 	}
 #endif
-	return 0;
+	return loaded ? 0 : -ENODEV;
 }
 
 module_init(xen_tmem_init)
-- 
1.7.7.5


> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/xen/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 1d24061..7e8d728 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -143,7 +143,7 @@ config SWIOTLB_XEN
>  	select SWIOTLB
>  
>  config XEN_TMEM
> -	bool
> +	bool "Xen Transcendent Memory (tmem)"
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:37:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18: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 1RpOlh-0003DM-L0; Mon, 23 Jan 2012 18:37: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 1RpOlg-0003DH-Mf
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:37:24 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327343837!9605875!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26376 invoked from network); 23 Jan 2012 18:37:18 -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; 23 Jan 2012 18:37:18 -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
	q0NIbCuM006052
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:37:13 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
	q0NIbAQ5004313
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:37:11 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
	q0NIb9Yg025300; Mon, 23 Jan 2012 12:37:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:37:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DA3DF40157; Mon, 23 Jan 2012 13:34:54 -0500 (EST)
Date: Mon, 23 Jan 2012 13:34:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120123183454.GA12542@phenom.dumpdata.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-5-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325842991-4404-5-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F1DA8D9.011A,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
	config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
> Add a description to the config menu for xen tmem.

I am not sure what this patch gets us. If this is to minimize the
size of the module - so say it gets loaded, but tmem-enabled is 
not set nor cleancache and we just have it consuming memory - we can do it
via returning -ENODEV on the module load.

Like this (completley untested nor compiled tested):

>From 45b49b5d565c52e4396dae036ddb4f4094d914ec Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 13:32:17 -0500
Subject: [PATCH] xen/tmem: Return -ENODEV if the backends are not registered.

.. otherwise the driver might still reside in the memory consuming
memory (that is the theory at least).

CC: Dan Magenheimer <dan.magenheimer@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/tmem.c |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
index d369965..e61b5a3 100644
--- a/drivers/xen/tmem.c
+++ b/drivers/xen/tmem.c
@@ -377,8 +377,10 @@ static struct frontswap_ops tmem_frontswap_ops = {
 
 static int __init xen_tmem_init(void)
 {
+	bool loaded = false;
+
 	if (!xen_domain())
-		return 0;
+		return -ENODEV;
 #ifdef CONFIG_FRONTSWAP
 	if (tmem_enabled && use_frontswap) {
 		char *s = "";
@@ -390,6 +392,7 @@ static int __init xen_tmem_init(void)
 			s = " (WARNING: frontswap_ops overridden)";
 		printk(KERN_INFO "frontswap enabled, RAM provided by "
 				 "Xen Transcendent Memory\n");
+		loaded = true;
 	}
 #endif
 #ifdef CONFIG_CLEANCACHE
@@ -402,9 +405,10 @@ static int __init xen_tmem_init(void)
 			s = " (WARNING: cleancache_ops overridden)";
 		printk(KERN_INFO "cleancache enabled, RAM provided by "
 				 "Xen Transcendent Memory%s\n", s);
+		loaded = true;
 	}
 #endif
-	return 0;
+	return loaded ? 0 : -ENODEV;
 }
 
 module_init(xen_tmem_init)
-- 
1.7.7.5


> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/xen/Kconfig |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 1d24061..7e8d728 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -143,7 +143,7 @@ config SWIOTLB_XEN
>  	select SWIOTLB
>  
>  config XEN_TMEM
> -	bool
> +	bool "Xen Transcendent Memory (tmem)"
>  	default y if (CLEANCACHE || FRONTSWAP)
>  	help
>  	  Shim to interface in-kernel Transcendent Memory hooks
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:38:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18: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 1RpOme-0003H4-3e; Mon, 23 Jan 2012 18:38:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpOmc-0003GE-2m
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:38:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327343894!10348781!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23884 invoked from network); 23 Jan 2012 18:38:15 -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; 23 Jan 2012 18:38:15 -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
	q0NIcAQ3007035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:38:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0NIc9S9005883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:38:09 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
	q0NIc8NR012630; Mon, 23 Jan 2012 12:38:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:38:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 06FB240157; Mon, 23 Jan 2012 13:35:54 -0500 (EST)
Date: Mon, 23 Jan 2012 13:35:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120123183553.GB12542@phenom.dumpdata.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-3-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325842991-4404-3-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F1DA913.00A7,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

This looks OK. Let me test this out to see if there is any silly
fallout.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..269b299 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> +	select INPUT_XEN_KBDDEV_FRONTEND
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:38:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18: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 1RpOme-0003H4-3e; Mon, 23 Jan 2012 18:38:24 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpOmc-0003GE-2m
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:38:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327343894!10348781!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk0OTU3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23884 invoked from network); 23 Jan 2012 18:38:15 -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; 23 Jan 2012 18:38:15 -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
	q0NIcAQ3007035
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:38:10 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0NIc9S9005883
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:38:09 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
	q0NIc8NR012630; Mon, 23 Jan 2012 12:38:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:38:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 06FB240157; Mon, 23 Jan 2012 13:35:54 -0500 (EST)
Date: Mon, 23 Jan 2012 13:35:53 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120123183553.GB12542@phenom.dumpdata.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-3-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325842991-4404-3-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F1DA913.00A7,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 2/4] xen kconfig: relax
	INPUT_XEN_KBDDEV_FRONTEND deps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 10:43:09AM +0100, Andrew Jones wrote:
> PV-on-HVM guests may want to use the xen keyboard/mouse frontend, but
> they don't use the xen frame buffer frontend. For this case it doesn't
> make much sense for INPUT_XEN_KBDDEV_FRONTEND to depend on
> XEN_FBDEV_FRONTEND. The opposite direction always makes more sense, i.e.
> if you're using xenfb, then you'll want xenkbd. Switch the dependencies.

This looks OK. Let me test this out to see if there is any silly
fallout.
> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  drivers/input/misc/Kconfig |    2 +-
>  drivers/video/Kconfig      |    1 +
>  2 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 22d875f..36c15bf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -533,7 +533,7 @@ config INPUT_CMA3000_I2C
>  
>  config INPUT_XEN_KBDDEV_FRONTEND
>  	tristate "Xen virtual keyboard and mouse support"
> -	depends on XEN_FBDEV_FRONTEND
> +	depends on XEN
>  	default y
>  	select XEN_XENBUS_FRONTEND
>  	help
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index d83e967..269b299 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2269,6 +2269,7 @@ config XEN_FBDEV_FRONTEND
>  	select FB_SYS_IMAGEBLIT
>  	select FB_SYS_FOPS
>  	select FB_DEFERRED_IO
> +	select INPUT_XEN_KBDDEV_FRONTEND
>  	select XEN_XENBUS_FRONTEND
>  	default y
>  	help
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:45:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:45:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOtC-0003Wf-UE; Mon, 23 Jan 2012 18:45:10 +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 1RpOtB-0003WZ-NV
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:45:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327344302!12097433!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11448 invoked from network); 23 Jan 2012 18:45:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 18:45:03 -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
	q0NIiwNL016609
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:44:59 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
	q0NIivBg008259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:44:57 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
	q0NIiuVa031296; Mon, 23 Jan 2012 12:44:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:44:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3723640157; Mon, 23 Jan 2012 13:42:42 -0500 (EST)
Date: Mon, 23 Jan 2012 13:42:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120123184242.GC12542@phenom.dumpdata.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-4-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325842991-4404-4-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F1DAAAB.0186,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 10:43:10AM +0100, Andrew Jones wrote:
> Describe dom0 support in the config menu and supply help text for it.

So I had this reply in my draft and forgot to send it. Sorry about that.

My understanding from the converstion was that we try to "squash"
the XEN_DOM0 option so that it would not be present. But that did not
work as it lead to a string of X86_LOCAL_APIC, X86_IO_ACPI, ACPI, PCI,
and so on. Then the .h with #define XEN_something based on those
symbols, but that is not the job of a header file. It is the job
of Kconfig.

The other way was to squash this in with the backend support. Since
we are moving away from having one initial domain, to having
multitple "initial domains" (priviliged domains) where each can
server as a backend.  However (quoting Jeremy) "it is more of
disaggregating the privilege to reduce the amount concentrated in any one
part.  Backends don't need any more privilege than to be able to
access the specific device(s) they're being the backend for."

Interestingly, that means DOM0 is kind of .. well, it should be
no different from a normal HVM guest. The old-style PV dom0 remains
would be ..well, almost nothing. The Xen MMU, and Xen SWIOTLB - those
are the ones that pop in mind for Dom0, but they are also used
for PV PCI. In fact, all (I think?) of the CONFIG_XEN_DOM0 functionality
can be _used_ in a PV guest. The 'if (initial_xen_domain()' should
probably be addressed first and to figure which one of those can be
altered as the "backend domain" can run both frontend and backend drivers
(oh joy!). So more relaxing those config options and/or "if (xen..)".

Anyhow, back to the HVM dom0 - that is in the future - and it is going
to take a couple of years to get it. I would rather not shoot my
foot by removing these CONFIG_* option until we get a better grasp of how
we want to deal with the PV hybrid.

What I am saying is that I don't know what the right answer is,
but I don't believe the patch below is it. I wish I had a better
answer in terms of "do this instead", but none of those worked.

Perhaps we can brainstorm some of this at XenSummit by which time
I hope Mukesh's PV hybrid work will be completed and a lot of the
work on the toolstack for backend drivers will be laid out.

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/x86/xen/Kconfig |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..88862d5 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
>  	  Xen hypervisor.
>  
>  config XEN_DOM0
> -	def_bool y
> +	bool "Xen Initial Domain (Dom0) support"
> +	default y
>  	depends on XEN && PCI_XEN && SWIOTLB_XEN
>  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> +	help
> +	  This allows the kernel to be used for the initial Xen domain,
> +	  Domain0. This is a privileged guest that supplies backends
> +	  and is used to manage the other Xen domains.
>  
>  # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
>  # name in tools.
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 18:45:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 18:45:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpOtC-0003Wf-UE; Mon, 23 Jan 2012 18:45:10 +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 1RpOtB-0003WZ-NV
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 18:45:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327344302!12097433!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11448 invoked from network); 23 Jan 2012 18:45:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 18:45:03 -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
	q0NIiwNL016609
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 18:44:59 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
	q0NIivBg008259
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 18:44:57 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
	q0NIiuVa031296; Mon, 23 Jan 2012 12:44:56 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 10:44:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3723640157; Mon, 23 Jan 2012 13:42:42 -0500 (EST)
Date: Mon, 23 Jan 2012 13:42:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Andrew Jones <drjones@redhat.com>
Message-ID: <20120123184242.GC12542@phenom.dumpdata.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-4-git-send-email-drjones@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1325842991-4404-4-git-send-email-drjones@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F1DAAAB.0186,ss=1,re=0.000,fgs=0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 3/4] xen kconfig: add dom0 support help text
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 06, 2012 at 10:43:10AM +0100, Andrew Jones wrote:
> Describe dom0 support in the config menu and supply help text for it.

So I had this reply in my draft and forgot to send it. Sorry about that.

My understanding from the converstion was that we try to "squash"
the XEN_DOM0 option so that it would not be present. But that did not
work as it lead to a string of X86_LOCAL_APIC, X86_IO_ACPI, ACPI, PCI,
and so on. Then the .h with #define XEN_something based on those
symbols, but that is not the job of a header file. It is the job
of Kconfig.

The other way was to squash this in with the backend support. Since
we are moving away from having one initial domain, to having
multitple "initial domains" (priviliged domains) where each can
server as a backend.  However (quoting Jeremy) "it is more of
disaggregating the privilege to reduce the amount concentrated in any one
part.  Backends don't need any more privilege than to be able to
access the specific device(s) they're being the backend for."

Interestingly, that means DOM0 is kind of .. well, it should be
no different from a normal HVM guest. The old-style PV dom0 remains
would be ..well, almost nothing. The Xen MMU, and Xen SWIOTLB - those
are the ones that pop in mind for Dom0, but they are also used
for PV PCI. In fact, all (I think?) of the CONFIG_XEN_DOM0 functionality
can be _used_ in a PV guest. The 'if (initial_xen_domain()' should
probably be addressed first and to figure which one of those can be
altered as the "backend domain" can run both frontend and backend drivers
(oh joy!). So more relaxing those config options and/or "if (xen..)".

Anyhow, back to the HVM dom0 - that is in the future - and it is going
to take a couple of years to get it. I would rather not shoot my
foot by removing these CONFIG_* option until we get a better grasp of how
we want to deal with the PV hybrid.

What I am saying is that I don't know what the right answer is,
but I don't believe the patch below is it. I wish I had a better
answer in terms of "do this instead", but none of those worked.

Perhaps we can brainstorm some of this at XenSummit by which time
I hope Mukesh's PV hybrid work will be completed and a lot of the
work on the toolstack for backend drivers will be laid out.

> 
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
>  arch/x86/xen/Kconfig |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
> index 26c731a..88862d5 100644
> --- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -14,9 +14,14 @@ config XEN
>  	  Xen hypervisor.
>  
>  config XEN_DOM0
> -	def_bool y
> +	bool "Xen Initial Domain (Dom0) support"
> +	default y
>  	depends on XEN && PCI_XEN && SWIOTLB_XEN
>  	depends on X86_LOCAL_APIC && X86_IO_APIC && ACPI && PCI
> +	help
> +	  This allows the kernel to be used for the initial Xen domain,
> +	  Domain0. This is a privileged guest that supplies backends
> +	  and is used to manage the other Xen domains.
>  
>  # Dummy symbol since people have come to rely on the PRIVILEGED_GUEST
>  # name in tools.
> -- 
> 1.7.7.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 19:14:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 19:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpPKd-0003uM-JA; Mon, 23 Jan 2012 19:13:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1RpPKc-0003u9-6s
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 19:13:30 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327346002!12129593!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 10145 invoked from network); 23 Jan 2012 19:13:23 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 19:13:23 -0000
Received: by yhgg71 with SMTP id g71so16109523yhg.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 11:13: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=wHyGhJ7k3v/PWOyWtc1Z93A3w2AlrSp5dQ22WxaFgaE=;
	b=jJ9Di2X/jbwTgG9fZvXAAAWqCo/w5FupjFC8VuiahrbYDE3flOYtesHuvNt1FSNEmr
	0DrXOctDRpGD3eSb9QpcmrehEDu1NA95AmwPsWRajf2MiVmGrW11EuBlwMDuuB2A0zvO
	XI+4V571wt5SlSqdaWrwFvE12YsvkiVleYPlk=
Received: by 10.236.77.232 with SMTP id d68mr13230091yhe.98.1327346002222;
	Mon, 23 Jan 2012 11:13:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.157.136 with HTTP; Mon, 23 Jan 2012 11:13:01 -0800 (PST)
In-Reply-To: <20120122202337.GA30288@andromeda.dapyr.net>
References: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
	<20120122202337.GA30288@andromeda.dapyr.net>
From: Eric Camachat <eric.camachat@gmail.com>
Date: Mon, 23 Jan 2012 11:13:01 -0800
Message-ID: <CACeEFf7K-b88d1++8B0GJROo_+_oYvd8br=GUbfU0n3V6qhcfQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Got kernel BUG message while PCI pass-through to
	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

VGhhbmsgeW91IQoKRXJpYwoKT24gU3VuLCBKYW4gMjIsIDIwMTIgYXQgMTI6MjMgUE0sIEtvbnJh
ZCBSemVzenV0ZWsgV2lsawo8a29ucmFkQGRhcm5vay5vcmc+IHdyb3RlOgo+IE9uIFNhdCwgSmFu
IDIxLCAyMDEyIGF0IDEwOjMyOjM3UE0gLTA4MDAsIEVyaWMgQ2FtYWNoYXQgd3JvdGU6Cj4+IEhp
IGFsbCwKPj4KPj4gSSBnb3Qga2VybmVsIEJVRyBtZXNzYWdlIHdoZW4gUENJIHBhc3MgdGhyb3Vn
aCB0byBkb21VICh4ZW4tcHYpLgo+PiBJcyB0aGVyZSBhbnkgb25lIHNlZW4gdGhpcz8KPgo+IFll
cy4gVGhlIGZpeCBpcyBpbiB0aGUgdXBzdHJlYW0ga2VybmVsLiBQbGVhc2UgdXNlIDMuMS4KPgo+
Pgo+PiBFcmljCj4+Cj4+IGRvbTAga2VybmVsIGNvbmZpZzoKPj4gJCBncmVwIFhFTl9QQ0kgbGlu
dXgtMi42LjMyLjI0Ly5jb25maWcKPj4gQ09ORklHX1hFTl9QQ0lfUEFTU1RIUk9VR0g9eQo+PiBD
T05GSUdfWEVOX1BDSURFVl9GUk9OVEVORD15Cj4+IENPTkZJR19YRU5fUENJREVWX0JBQ0tFTkQ9
eQo+PiAjIENPTkZJR19YRU5fUENJREVWX0JBQ0tFTkRfVlBDSSBpcyBub3Qgc2V0Cj4+IENPTkZJ
R19YRU5fUENJREVWX0JBQ0tFTkRfUEFTUz15Cj4+ICMgQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VO
RF9TTE9UIGlzIG5vdCBzZXQKPj4gIyBDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EX0NPTlRST0xM
RVIgaXMgbm90IHNldAo+PiAjIENPTkZJR19YRU5fUENJREVWX0JFX0RFQlVHIGlzIG5vdCBzZXQK
Pj4KPj4KPj4gV2hlbiBzdGFydCBkb21VLCBnb3QgdGhpcyBlcnJvciBtZXNzYWdlIGluIGRvbTA6
Cj4+IEJVRzogc2xlZXBpbmcgZnVuY3Rpb24gY2FsbGVkIGZyb20gaW52YWxpZCBjb250ZXh0IGF0
IG1tL3NsYWIuYzozMDE2Cj4+IGluX2F0b21pYygpOiAxLCBpcnFzX2Rpc2FibGVkKCk6IDAsIHBp
ZDogMjEsIG5hbWU6IHhlbndhdGNoCj4+IFBpZDogMjEsIGNvbW06IHhlbndhdGNoIFRhaW50ZWQ6
IFAgwqAgwqAgwqAgwqAgwqAgMi42LjMyLjI0LXdzLXN5bWJvbCAjMQo+PiBDYWxsIFRyYWNlOgo+
PiDCoFs8ZmZmZmZmZmY4MTAzNjVlND5dIF9fbWlnaHRfc2xlZXArMHhmNC8weDExMAo+PiDCoFs8
ZmZmZmZmZmY4MTBhYzQ3OD5dIF9fa21hbGxvYysweDExOC8weDE0MAo+PiDCoFs8ZmZmZmZmZmY4
MTFjMTgzNz5dIGt2YXNwcmludGYrMHg1Ny8weDkwCj4+IMKgWzxmZmZmZmZmZjgxM2ZjZDhhPl0g
PyBlcnJvcl9leGl0KzB4MmEvMHg2MAo+PiDCoFs8ZmZmZmZmZmY4MTFjMThkMD5dIGthc3ByaW50
ZisweDYwLzB4NzAKPj4gwqBbPGZmZmZmZmZmODEwMTAxYzI+XSA/IGNoZWNrX2V2ZW50cysweDEy
LzB4MjAKPj4gwqBbPGZmZmZmZmZmODEwMTAxYWY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9l
bmQrMHgwLzB4MQo+PiDCoFs8ZmZmZmZmZmY4MTBhYjZhNz5dID8ga2ZyZWUrMHg4Ny8weGQwCj4+
IMKgWzxmZmZmZmZmZjgxMjMzMjhhPl0gPyByZWFkX3JlcGx5KzB4MTNhLzB4MTUwCj4+IMKgWzxm
ZmZmZmZmZjgxMjMzN2FlPl0gam9pbisweDRlLzB4NjAKPj4gwqBbPGZmZmZmZmZmODEyMzM5NmM+
XSB4ZW5idXNfcmVhZCsweDJjLzB4NzAKPj4gwqBbPGZmZmZmZmZmODEyMzQwMmY+XSB4ZW5idXNf
c2NhbmYrMHgyZi8weGEwCj4+IMKgWzxmZmZmZmZmZjgxMDBmODJkPl0gPyB4ZW5fZm9yY2VfZXZ0
Y2huX2NhbGxiYWNrKzB4ZC8weDEwCj4+IMKgWzxmZmZmZmZmZjgxMDEwMWMyPl0gPyBjaGVja19l
dmVudHMrMHgxMi8weDIwCj4+IMKgWzxmZmZmZmZmZjgxMDEwMWFmPl0gPyB4ZW5fcmVzdG9yZV9m
bF9kaXJlY3RfZW5kKzB4MC8weDEKPj4gwqBbPGZmZmZmZmZmODEwYWI2YTc+XSA/IGtmcmVlKzB4
ODcvMHhkMAo+PiDCoFs8ZmZmZmZmZmY4MTIzMzkxYz5dID8geGVuYnVzX3ByaW50ZisweGJjLzB4
ZTAKPj4gwqBbPGZmZmZmZmZmODEwMGY4MmQ+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2sr
MHhkLzB4MTAKPj4gwqBbPGZmZmZmZmZmODEyM2E2MDA+XSBwY2liYWNrX3B1Ymxpc2hfcGNpX3Jv
b3QrMHg0MC8weDFhMAo+PiDCoFs8ZmZmZmZmZmY4MTAxMDFhZj5dID8geGVuX3Jlc3RvcmVfZmxf
ZGlyZWN0X2VuZCsweDAvMHgxCj4+IG54NDUyNC03QUM0RjAjIFs8ZmZmZmZmZmY4MTBhYzUzZT5d
ID8ga21lbV9jYWNoZV9hbGxvYysweDllLzB4ZjAKPj4gwqBbPGZmZmZmZmZmODEwMTBlMjY+XSA/
IHhlbl9yZWdpc3Rlcl9kZXZpY2VfZG9tYWluX293bmVyKzB4ODYvMHhjMAo+PiDCoFs8ZmZmZmZm
ZmY4MTIzY2M3OD5dIHBjaWJhY2tfcHVibGlzaF9wY2lfcm9vdHMrMHg4OC8weGMwCj4+IMKgWzxm
ZmZmZmZmZjgxMjNhNWMwPl0gPyBwY2liYWNrX3B1Ymxpc2hfcGNpX3Jvb3QrMHgwLzB4MWEwCj4+
IMKgWzxmZmZmZmZmZjgxMjNhYWRkPl0gcGNpYmFja19iZV93YXRjaCsweDFkZC8weDI5MAo+PiDC
oFs8ZmZmZmZmZmY4MTIzMmQ2ND5dID8geHNfZXJyb3IrMHgxNC8weDIwCj4+IMKgWzxmZmZmZmZm
ZjgxMjMzNTcxPl0gPyB4c193YXRjaCsweDUxLzB4NjAKPj4gwqBbPGZmZmZmZmZmODEyMzNiMGQ+
XSA/IHJlZ2lzdGVyX3hlbmJ1c193YXRjaCsweGRkLzB4ZjAKPj4gwqBbPGZmZmZmZmZmODEyM2E5
MDA+XSA/IHBjaWJhY2tfYmVfd2F0Y2grMHgwLzB4MjkwCj4+IMKgWzxmZmZmZmZmZjgxMjNiMGE5
Pl0gcGNpYmFja194ZW5idXNfcHJvYmUrMHgxMzkvMHgxNDAKPj4gwqBbPGZmZmZmZmZmODEyMzRm
M2E+XSB4ZW5idXNfZGV2X3Byb2JlKzB4YWEvMHgxMzAKPj4gwqBbPGZmZmZmZmZmODEyNzk1MGI+
XSBkcml2ZXJfcHJvYmVfZGV2aWNlKzB4N2IvMHgxNjAKPj4gwqBbPGZmZmZmZmZmODEyNzk3ZTA+
XSA/IF9fZGV2aWNlX2F0dGFjaCsweDAvMHg1MAo+PiDCoFs8ZmZmZmZmZmY4MTI3OTgxZD5dIF9f
ZGV2aWNlX2F0dGFjaCsweDNkLzB4NTAKPj4gwqBbPGZmZmZmZmZmODEyNzg1ZTg+XSBidXNfZm9y
X2VhY2hfZHJ2KzB4NjgvMHg5MAo+PiDCoFs8ZmZmZmZmZmY4MTI3OTczYj5dIGRldmljZV9hdHRh
Y2grMHg3Yi8weDgwCj4+IMKgWzxmZmZmZmZmZjgxMjc4NTY1Pl0gYnVzX3Byb2JlX2RldmljZSsw
eDI1LzB4NDAKPj4gwqBbPGZmZmZmZmZmODEyNzZhYzM+XSBkZXZpY2VfYWRkKzB4MjkzLzB4NTcw
Cj4+IMKgWzxmZmZmZmZmZjgxMWI4ZGE2Pl0gPyBrb2JqZWN0X2luaXQrMHgzNi8weDgwCj4+IMKg
WzxmZmZmZmZmZjgxMjc2ZGI5Pl0gZGV2aWNlX3JlZ2lzdGVyKzB4MTkvMHgyMAo+PiDCoFs8ZmZm
ZmZmZmY4MTIzNDc4MD5dIHhlbmJ1c19wcm9iZV9ub2RlKzB4MTMwLzB4MWIwCj4+IMKgWzxmZmZm
ZmZmZjgxMjM0OTk2Pl0geGVuYnVzX2Rldl9jaGFuZ2VkKzB4MTk2LzB4MWEwCj4+IMKgWzxmZmZm
ZmZmZjgxMDEwMWFmPl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfZW5kKzB4MC8weDEKPj4gwqBb
PGZmZmZmZmZmODEwMzY1MmI+XSA/IF9fbWlnaHRfc2xlZXArMHgzYi8weDExMAo+PiDCoFs8ZmZm
ZmZmZmY4MTIzNTBiNj5dIGJhY2tlbmRfY2hhbmdlZCsweDE2LzB4MjAKPj4gwqBbPGZmZmZmZmZm
ODEyMzNlNGI+XSB4ZW53YXRjaF90aHJlYWQrMHgxMGIvMHgxNTAKPj4gwqBbPGZmZmZmZmZmODEw
NTdkOTA+XSA/IGF1dG9yZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg0MAo+PiDCoFs8ZmZmZmZm
ZmY4MTIzM2Q0MD5dID8geGVud2F0Y2hfdGhyZWFkKzB4MC8weDE1MAo+PiDCoFs8ZmZmZmZmZmY4
MTA1N2MxZT5dIGt0aHJlYWQrMHg4ZS8weGEwCj4+IMKgWzxmZmZmZmZmZjgxMDE0ZGZhPl0gY2hp
bGRfcmlwKzB4YS8weDIwCj4+IMKgWzxmZmZmZmZmZjgxMDEzZmE2Pl0gPyBpbnRfcmV0X2Zyb21f
c3lzX2NhbGwrMHg3LzB4MWIKPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQo+PiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 19:14:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 19:14:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpPKd-0003uM-JA; Mon, 23 Jan 2012 19:13:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1RpPKc-0003u9-6s
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 19:13:30 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327346002!12129593!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 10145 invoked from network); 23 Jan 2012 19:13:23 -0000
Received: from mail-yw0-f43.google.com (HELO mail-yw0-f43.google.com)
	(209.85.213.43)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 19:13:23 -0000
Received: by yhgg71 with SMTP id g71so16109523yhg.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 11:13: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=wHyGhJ7k3v/PWOyWtc1Z93A3w2AlrSp5dQ22WxaFgaE=;
	b=jJ9Di2X/jbwTgG9fZvXAAAWqCo/w5FupjFC8VuiahrbYDE3flOYtesHuvNt1FSNEmr
	0DrXOctDRpGD3eSb9QpcmrehEDu1NA95AmwPsWRajf2MiVmGrW11EuBlwMDuuB2A0zvO
	XI+4V571wt5SlSqdaWrwFvE12YsvkiVleYPlk=
Received: by 10.236.77.232 with SMTP id d68mr13230091yhe.98.1327346002222;
	Mon, 23 Jan 2012 11:13:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.157.136 with HTTP; Mon, 23 Jan 2012 11:13:01 -0800 (PST)
In-Reply-To: <20120122202337.GA30288@andromeda.dapyr.net>
References: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
	<20120122202337.GA30288@andromeda.dapyr.net>
From: Eric Camachat <eric.camachat@gmail.com>
Date: Mon, 23 Jan 2012 11:13:01 -0800
Message-ID: <CACeEFf7K-b88d1++8B0GJROo_+_oYvd8br=GUbfU0n3V6qhcfQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Got kernel BUG message while PCI pass-through to
	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

VGhhbmsgeW91IQoKRXJpYwoKT24gU3VuLCBKYW4gMjIsIDIwMTIgYXQgMTI6MjMgUE0sIEtvbnJh
ZCBSemVzenV0ZWsgV2lsawo8a29ucmFkQGRhcm5vay5vcmc+IHdyb3RlOgo+IE9uIFNhdCwgSmFu
IDIxLCAyMDEyIGF0IDEwOjMyOjM3UE0gLTA4MDAsIEVyaWMgQ2FtYWNoYXQgd3JvdGU6Cj4+IEhp
IGFsbCwKPj4KPj4gSSBnb3Qga2VybmVsIEJVRyBtZXNzYWdlIHdoZW4gUENJIHBhc3MgdGhyb3Vn
aCB0byBkb21VICh4ZW4tcHYpLgo+PiBJcyB0aGVyZSBhbnkgb25lIHNlZW4gdGhpcz8KPgo+IFll
cy4gVGhlIGZpeCBpcyBpbiB0aGUgdXBzdHJlYW0ga2VybmVsLiBQbGVhc2UgdXNlIDMuMS4KPgo+
Pgo+PiBFcmljCj4+Cj4+IGRvbTAga2VybmVsIGNvbmZpZzoKPj4gJCBncmVwIFhFTl9QQ0kgbGlu
dXgtMi42LjMyLjI0Ly5jb25maWcKPj4gQ09ORklHX1hFTl9QQ0lfUEFTU1RIUk9VR0g9eQo+PiBD
T05GSUdfWEVOX1BDSURFVl9GUk9OVEVORD15Cj4+IENPTkZJR19YRU5fUENJREVWX0JBQ0tFTkQ9
eQo+PiAjIENPTkZJR19YRU5fUENJREVWX0JBQ0tFTkRfVlBDSSBpcyBub3Qgc2V0Cj4+IENPTkZJ
R19YRU5fUENJREVWX0JBQ0tFTkRfUEFTUz15Cj4+ICMgQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VO
RF9TTE9UIGlzIG5vdCBzZXQKPj4gIyBDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EX0NPTlRST0xM
RVIgaXMgbm90IHNldAo+PiAjIENPTkZJR19YRU5fUENJREVWX0JFX0RFQlVHIGlzIG5vdCBzZXQK
Pj4KPj4KPj4gV2hlbiBzdGFydCBkb21VLCBnb3QgdGhpcyBlcnJvciBtZXNzYWdlIGluIGRvbTA6
Cj4+IEJVRzogc2xlZXBpbmcgZnVuY3Rpb24gY2FsbGVkIGZyb20gaW52YWxpZCBjb250ZXh0IGF0
IG1tL3NsYWIuYzozMDE2Cj4+IGluX2F0b21pYygpOiAxLCBpcnFzX2Rpc2FibGVkKCk6IDAsIHBp
ZDogMjEsIG5hbWU6IHhlbndhdGNoCj4+IFBpZDogMjEsIGNvbW06IHhlbndhdGNoIFRhaW50ZWQ6
IFAgwqAgwqAgwqAgwqAgwqAgMi42LjMyLjI0LXdzLXN5bWJvbCAjMQo+PiBDYWxsIFRyYWNlOgo+
PiDCoFs8ZmZmZmZmZmY4MTAzNjVlND5dIF9fbWlnaHRfc2xlZXArMHhmNC8weDExMAo+PiDCoFs8
ZmZmZmZmZmY4MTBhYzQ3OD5dIF9fa21hbGxvYysweDExOC8weDE0MAo+PiDCoFs8ZmZmZmZmZmY4
MTFjMTgzNz5dIGt2YXNwcmludGYrMHg1Ny8weDkwCj4+IMKgWzxmZmZmZmZmZjgxM2ZjZDhhPl0g
PyBlcnJvcl9leGl0KzB4MmEvMHg2MAo+PiDCoFs8ZmZmZmZmZmY4MTFjMThkMD5dIGthc3ByaW50
ZisweDYwLzB4NzAKPj4gwqBbPGZmZmZmZmZmODEwMTAxYzI+XSA/IGNoZWNrX2V2ZW50cysweDEy
LzB4MjAKPj4gwqBbPGZmZmZmZmZmODEwMTAxYWY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVjdF9l
bmQrMHgwLzB4MQo+PiDCoFs8ZmZmZmZmZmY4MTBhYjZhNz5dID8ga2ZyZWUrMHg4Ny8weGQwCj4+
IMKgWzxmZmZmZmZmZjgxMjMzMjhhPl0gPyByZWFkX3JlcGx5KzB4MTNhLzB4MTUwCj4+IMKgWzxm
ZmZmZmZmZjgxMjMzN2FlPl0gam9pbisweDRlLzB4NjAKPj4gwqBbPGZmZmZmZmZmODEyMzM5NmM+
XSB4ZW5idXNfcmVhZCsweDJjLzB4NzAKPj4gwqBbPGZmZmZmZmZmODEyMzQwMmY+XSB4ZW5idXNf
c2NhbmYrMHgyZi8weGEwCj4+IMKgWzxmZmZmZmZmZjgxMDBmODJkPl0gPyB4ZW5fZm9yY2VfZXZ0
Y2huX2NhbGxiYWNrKzB4ZC8weDEwCj4+IMKgWzxmZmZmZmZmZjgxMDEwMWMyPl0gPyBjaGVja19l
dmVudHMrMHgxMi8weDIwCj4+IMKgWzxmZmZmZmZmZjgxMDEwMWFmPl0gPyB4ZW5fcmVzdG9yZV9m
bF9kaXJlY3RfZW5kKzB4MC8weDEKPj4gwqBbPGZmZmZmZmZmODEwYWI2YTc+XSA/IGtmcmVlKzB4
ODcvMHhkMAo+PiDCoFs8ZmZmZmZmZmY4MTIzMzkxYz5dID8geGVuYnVzX3ByaW50ZisweGJjLzB4
ZTAKPj4gwqBbPGZmZmZmZmZmODEwMGY4MmQ+XSA/IHhlbl9mb3JjZV9ldnRjaG5fY2FsbGJhY2sr
MHhkLzB4MTAKPj4gwqBbPGZmZmZmZmZmODEyM2E2MDA+XSBwY2liYWNrX3B1Ymxpc2hfcGNpX3Jv
b3QrMHg0MC8weDFhMAo+PiDCoFs8ZmZmZmZmZmY4MTAxMDFhZj5dID8geGVuX3Jlc3RvcmVfZmxf
ZGlyZWN0X2VuZCsweDAvMHgxCj4+IG54NDUyNC03QUM0RjAjIFs8ZmZmZmZmZmY4MTBhYzUzZT5d
ID8ga21lbV9jYWNoZV9hbGxvYysweDllLzB4ZjAKPj4gwqBbPGZmZmZmZmZmODEwMTBlMjY+XSA/
IHhlbl9yZWdpc3Rlcl9kZXZpY2VfZG9tYWluX293bmVyKzB4ODYvMHhjMAo+PiDCoFs8ZmZmZmZm
ZmY4MTIzY2M3OD5dIHBjaWJhY2tfcHVibGlzaF9wY2lfcm9vdHMrMHg4OC8weGMwCj4+IMKgWzxm
ZmZmZmZmZjgxMjNhNWMwPl0gPyBwY2liYWNrX3B1Ymxpc2hfcGNpX3Jvb3QrMHgwLzB4MWEwCj4+
IMKgWzxmZmZmZmZmZjgxMjNhYWRkPl0gcGNpYmFja19iZV93YXRjaCsweDFkZC8weDI5MAo+PiDC
oFs8ZmZmZmZmZmY4MTIzMmQ2ND5dID8geHNfZXJyb3IrMHgxNC8weDIwCj4+IMKgWzxmZmZmZmZm
ZjgxMjMzNTcxPl0gPyB4c193YXRjaCsweDUxLzB4NjAKPj4gwqBbPGZmZmZmZmZmODEyMzNiMGQ+
XSA/IHJlZ2lzdGVyX3hlbmJ1c193YXRjaCsweGRkLzB4ZjAKPj4gwqBbPGZmZmZmZmZmODEyM2E5
MDA+XSA/IHBjaWJhY2tfYmVfd2F0Y2grMHgwLzB4MjkwCj4+IMKgWzxmZmZmZmZmZjgxMjNiMGE5
Pl0gcGNpYmFja194ZW5idXNfcHJvYmUrMHgxMzkvMHgxNDAKPj4gwqBbPGZmZmZmZmZmODEyMzRm
M2E+XSB4ZW5idXNfZGV2X3Byb2JlKzB4YWEvMHgxMzAKPj4gwqBbPGZmZmZmZmZmODEyNzk1MGI+
XSBkcml2ZXJfcHJvYmVfZGV2aWNlKzB4N2IvMHgxNjAKPj4gwqBbPGZmZmZmZmZmODEyNzk3ZTA+
XSA/IF9fZGV2aWNlX2F0dGFjaCsweDAvMHg1MAo+PiDCoFs8ZmZmZmZmZmY4MTI3OTgxZD5dIF9f
ZGV2aWNlX2F0dGFjaCsweDNkLzB4NTAKPj4gwqBbPGZmZmZmZmZmODEyNzg1ZTg+XSBidXNfZm9y
X2VhY2hfZHJ2KzB4NjgvMHg5MAo+PiDCoFs8ZmZmZmZmZmY4MTI3OTczYj5dIGRldmljZV9hdHRh
Y2grMHg3Yi8weDgwCj4+IMKgWzxmZmZmZmZmZjgxMjc4NTY1Pl0gYnVzX3Byb2JlX2RldmljZSsw
eDI1LzB4NDAKPj4gwqBbPGZmZmZmZmZmODEyNzZhYzM+XSBkZXZpY2VfYWRkKzB4MjkzLzB4NTcw
Cj4+IMKgWzxmZmZmZmZmZjgxMWI4ZGE2Pl0gPyBrb2JqZWN0X2luaXQrMHgzNi8weDgwCj4+IMKg
WzxmZmZmZmZmZjgxMjc2ZGI5Pl0gZGV2aWNlX3JlZ2lzdGVyKzB4MTkvMHgyMAo+PiDCoFs8ZmZm
ZmZmZmY4MTIzNDc4MD5dIHhlbmJ1c19wcm9iZV9ub2RlKzB4MTMwLzB4MWIwCj4+IMKgWzxmZmZm
ZmZmZjgxMjM0OTk2Pl0geGVuYnVzX2Rldl9jaGFuZ2VkKzB4MTk2LzB4MWEwCj4+IMKgWzxmZmZm
ZmZmZjgxMDEwMWFmPl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfZW5kKzB4MC8weDEKPj4gwqBb
PGZmZmZmZmZmODEwMzY1MmI+XSA/IF9fbWlnaHRfc2xlZXArMHgzYi8weDExMAo+PiDCoFs8ZmZm
ZmZmZmY4MTIzNTBiNj5dIGJhY2tlbmRfY2hhbmdlZCsweDE2LzB4MjAKPj4gwqBbPGZmZmZmZmZm
ODEyMzNlNGI+XSB4ZW53YXRjaF90aHJlYWQrMHgxMGIvMHgxNTAKPj4gwqBbPGZmZmZmZmZmODEw
NTdkOTA+XSA/IGF1dG9yZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg0MAo+PiDCoFs8ZmZmZmZm
ZmY4MTIzM2Q0MD5dID8geGVud2F0Y2hfdGhyZWFkKzB4MC8weDE1MAo+PiDCoFs8ZmZmZmZmZmY4
MTA1N2MxZT5dIGt0aHJlYWQrMHg4ZS8weGEwCj4+IMKgWzxmZmZmZmZmZjgxMDE0ZGZhPl0gY2hp
bGRfcmlwKzB4YS8weDIwCj4+IMKgWzxmZmZmZmZmZjgxMDEzZmE2Pl0gPyBpbnRfcmV0X2Zyb21f
c3lzX2NhbGwrMHg3LzB4MWIKPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KPj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlz
dHMueGVuc291cmNlLmNvbQo+PiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Mon Jan 23 19:23:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 19:23:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpPTn-0004EX-RE; Mon, 23 Jan 2012 19:22:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1RpPTm-0004EH-K7
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 19:22:58 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327346571!12187464!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 11715 invoked from network); 23 Jan 2012 19:22:52 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 19:22:52 -0000
Received: by yenr9 with SMTP id r9so45542740yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 11:22: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=OvKKyClF5rc98jgNj9h3jg8mU4WTdl5tiETMfQXCPls=;
	b=TOogOgK7P5Jn3m69VpF5FkACbu4tDf12H/o2LcewSG9e3HxRPppzVdpyRWbiEwF4yA
	v2VdpzhdqpZCUxIdIOxL4GVxHkanNeRnG9FV1rZ2/s0O8y20ZPaCbGQjioj8TTpUeq0e
	aLK2VYl0QraeCvvUGRBhbzT33hxpbPWGIErgk=
Received: by 10.236.80.65 with SMTP id j41mr11824010yhe.115.1327346569200;
	Mon, 23 Jan 2012 11:22:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.157.136 with HTTP; Mon, 23 Jan 2012 11:22:28 -0800 (PST)
In-Reply-To: <20120122202337.GA30288@andromeda.dapyr.net>
References: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
	<20120122202337.GA30288@andromeda.dapyr.net>
From: Eric Camachat <eric.camachat@gmail.com>
Date: Mon, 23 Jan 2012 11:22:28 -0800
Message-ID: <CACeEFf60o2jJ=5exxEfVegfPAVN_VjV0L4MXYFK_RQx1XXGfPQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Got kernel BUG message while PCI pass-through to
	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

VGhhbmtzLCAgS29ucmFkLgoKRG8geW91IG1lYW4gZG9tMCBrZXJuZWw/IG9yIFRoZSBkb21VIGtl
cm5lbD8KCkVyaWMKCk9uIFN1biwgSmFuIDIyLCAyMDEyIGF0IDEyOjIzIFBNLCBLb25yYWQgUnpl
c3p1dGVrIFdpbGsKPGtvbnJhZEBkYXJub2sub3JnPiB3cm90ZToKPiBPbiBTYXQsIEphbiAyMSwg
MjAxMiBhdCAxMDozMjozN1BNIC0wODAwLCBFcmljIENhbWFjaGF0IHdyb3RlOgo+PiBIaSBhbGws
Cj4+Cj4+IEkgZ290IGtlcm5lbCBCVUcgbWVzc2FnZSB3aGVuIFBDSSBwYXNzIHRocm91Z2ggdG8g
ZG9tVSAoeGVuLXB2KS4KPj4gSXMgdGhlcmUgYW55IG9uZSBzZWVuIHRoaXM/Cj4KPiBZZXMuIFRo
ZSBmaXggaXMgaW4gdGhlIHVwc3RyZWFtIGtlcm5lbC4gUGxlYXNlIHVzZSAzLjEuCj4KPj4KPj4g
RXJpYwo+Pgo+PiBkb20wIGtlcm5lbCBjb25maWc6Cj4+ICQgZ3JlcCBYRU5fUENJIGxpbnV4LTIu
Ni4zMi4yNC8uY29uZmlnCj4+IENPTkZJR19YRU5fUENJX1BBU1NUSFJPVUdIPXkKPj4gQ09ORklH
X1hFTl9QQ0lERVZfRlJPTlRFTkQ9eQo+PiBDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EPXkKPj4g
IyBDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EX1ZQQ0kgaXMgbm90IHNldAo+PiBDT05GSUdfWEVO
X1BDSURFVl9CQUNLRU5EX1BBU1M9eQo+PiAjIENPTkZJR19YRU5fUENJREVWX0JBQ0tFTkRfU0xP
VCBpcyBub3Qgc2V0Cj4+ICMgQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORF9DT05UUk9MTEVSIGlz
IG5vdCBzZXQKPj4gIyBDT05GSUdfWEVOX1BDSURFVl9CRV9ERUJVRyBpcyBub3Qgc2V0Cj4+Cj4+
Cj4+IFdoZW4gc3RhcnQgZG9tVSwgZ290IHRoaXMgZXJyb3IgbWVzc2FnZSBpbiBkb20wOgo+PiBC
VUc6IHNsZWVwaW5nIGZ1bmN0aW9uIGNhbGxlZCBmcm9tIGludmFsaWQgY29udGV4dCBhdCBtbS9z
bGFiLmM6MzAxNgo+PiBpbl9hdG9taWMoKTogMSwgaXJxc19kaXNhYmxlZCgpOiAwLCBwaWQ6IDIx
LCBuYW1lOiB4ZW53YXRjaAo+PiBQaWQ6IDIxLCBjb21tOiB4ZW53YXRjaCBUYWludGVkOiBQIMKg
IMKgIMKgIMKgIMKgIDIuNi4zMi4yNC13cy1zeW1ib2wgIzEKPj4gQ2FsbCBUcmFjZToKPj4gwqBb
PGZmZmZmZmZmODEwMzY1ZTQ+XSBfX21pZ2h0X3NsZWVwKzB4ZjQvMHgxMTAKPj4gwqBbPGZmZmZm
ZmZmODEwYWM0Nzg+XSBfX2ttYWxsb2MrMHgxMTgvMHgxNDAKPj4gwqBbPGZmZmZmZmZmODExYzE4
Mzc+XSBrdmFzcHJpbnRmKzB4NTcvMHg5MAo+PiDCoFs8ZmZmZmZmZmY4MTNmY2Q4YT5dID8gZXJy
b3JfZXhpdCsweDJhLzB4NjAKPj4gwqBbPGZmZmZmZmZmODExYzE4ZDA+XSBrYXNwcmludGYrMHg2
MC8weDcwCj4+IMKgWzxmZmZmZmZmZjgxMDEwMWMyPl0gPyBjaGVja19ldmVudHMrMHgxMi8weDIw
Cj4+IMKgWzxmZmZmZmZmZjgxMDEwMWFmPl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfZW5kKzB4
MC8weDEKPj4gwqBbPGZmZmZmZmZmODEwYWI2YTc+XSA/IGtmcmVlKzB4ODcvMHhkMAo+PiDCoFs8
ZmZmZmZmZmY4MTIzMzI4YT5dID8gcmVhZF9yZXBseSsweDEzYS8weDE1MAo+PiDCoFs8ZmZmZmZm
ZmY4MTIzMzdhZT5dIGpvaW4rMHg0ZS8weDYwCj4+IMKgWzxmZmZmZmZmZjgxMjMzOTZjPl0geGVu
YnVzX3JlYWQrMHgyYy8weDcwCj4+IMKgWzxmZmZmZmZmZjgxMjM0MDJmPl0geGVuYnVzX3NjYW5m
KzB4MmYvMHhhMAo+PiDCoFs8ZmZmZmZmZmY4MTAwZjgyZD5dID8geGVuX2ZvcmNlX2V2dGNobl9j
YWxsYmFjaysweGQvMHgxMAo+PiDCoFs8ZmZmZmZmZmY4MTAxMDFjMj5dID8gY2hlY2tfZXZlbnRz
KzB4MTIvMHgyMAo+PiDCoFs8ZmZmZmZmZmY4MTAxMDFhZj5dID8geGVuX3Jlc3RvcmVfZmxfZGly
ZWN0X2VuZCsweDAvMHgxCj4+IMKgWzxmZmZmZmZmZjgxMGFiNmE3Pl0gPyBrZnJlZSsweDg3LzB4
ZDAKPj4gwqBbPGZmZmZmZmZmODEyMzM5MWM+XSA/IHhlbmJ1c19wcmludGYrMHhiYy8weGUwCj4+
IMKgWzxmZmZmZmZmZjgxMDBmODJkPl0gPyB4ZW5fZm9yY2VfZXZ0Y2huX2NhbGxiYWNrKzB4ZC8w
eDEwCj4+IMKgWzxmZmZmZmZmZjgxMjNhNjAwPl0gcGNpYmFja19wdWJsaXNoX3BjaV9yb290KzB4
NDAvMHgxYTAKPj4gwqBbPGZmZmZmZmZmODEwMTAxYWY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVj
dF9lbmQrMHgwLzB4MQo+PiBueDQ1MjQtN0FDNEYwIyBbPGZmZmZmZmZmODEwYWM1M2U+XSA/IGtt
ZW1fY2FjaGVfYWxsb2MrMHg5ZS8weGYwCj4+IMKgWzxmZmZmZmZmZjgxMDEwZTI2Pl0gPyB4ZW5f
cmVnaXN0ZXJfZGV2aWNlX2RvbWFpbl9vd25lcisweDg2LzB4YzAKPj4gwqBbPGZmZmZmZmZmODEy
M2NjNzg+XSBwY2liYWNrX3B1Ymxpc2hfcGNpX3Jvb3RzKzB4ODgvMHhjMAo+PiDCoFs8ZmZmZmZm
ZmY4MTIzYTVjMD5dID8gcGNpYmFja19wdWJsaXNoX3BjaV9yb290KzB4MC8weDFhMAo+PiDCoFs8
ZmZmZmZmZmY4MTIzYWFkZD5dIHBjaWJhY2tfYmVfd2F0Y2grMHgxZGQvMHgyOTAKPj4gwqBbPGZm
ZmZmZmZmODEyMzJkNjQ+XSA/IHhzX2Vycm9yKzB4MTQvMHgyMAo+PiDCoFs8ZmZmZmZmZmY4MTIz
MzU3MT5dID8geHNfd2F0Y2grMHg1MS8weDYwCj4+IMKgWzxmZmZmZmZmZjgxMjMzYjBkPl0gPyBy
ZWdpc3Rlcl94ZW5idXNfd2F0Y2grMHhkZC8weGYwCj4+IMKgWzxmZmZmZmZmZjgxMjNhOTAwPl0g
PyBwY2liYWNrX2JlX3dhdGNoKzB4MC8weDI5MAo+PiDCoFs8ZmZmZmZmZmY4MTIzYjBhOT5dIHBj
aWJhY2tfeGVuYnVzX3Byb2JlKzB4MTM5LzB4MTQwCj4+IMKgWzxmZmZmZmZmZjgxMjM0ZjNhPl0g
eGVuYnVzX2Rldl9wcm9iZSsweGFhLzB4MTMwCj4+IMKgWzxmZmZmZmZmZjgxMjc5NTBiPl0gZHJp
dmVyX3Byb2JlX2RldmljZSsweDdiLzB4MTYwCj4+IMKgWzxmZmZmZmZmZjgxMjc5N2UwPl0gPyBf
X2RldmljZV9hdHRhY2grMHgwLzB4NTAKPj4gwqBbPGZmZmZmZmZmODEyNzk4MWQ+XSBfX2Rldmlj
ZV9hdHRhY2grMHgzZC8weDUwCj4+IMKgWzxmZmZmZmZmZjgxMjc4NWU4Pl0gYnVzX2Zvcl9lYWNo
X2RydisweDY4LzB4OTAKPj4gwqBbPGZmZmZmZmZmODEyNzk3M2I+XSBkZXZpY2VfYXR0YWNoKzB4
N2IvMHg4MAo+PiDCoFs8ZmZmZmZmZmY4MTI3ODU2NT5dIGJ1c19wcm9iZV9kZXZpY2UrMHgyNS8w
eDQwCj4+IMKgWzxmZmZmZmZmZjgxMjc2YWMzPl0gZGV2aWNlX2FkZCsweDI5My8weDU3MAo+PiDC
oFs8ZmZmZmZmZmY4MTFiOGRhNj5dID8ga29iamVjdF9pbml0KzB4MzYvMHg4MAo+PiDCoFs8ZmZm
ZmZmZmY4MTI3NmRiOT5dIGRldmljZV9yZWdpc3RlcisweDE5LzB4MjAKPj4gwqBbPGZmZmZmZmZm
ODEyMzQ3ODA+XSB4ZW5idXNfcHJvYmVfbm9kZSsweDEzMC8weDFiMAo+PiDCoFs8ZmZmZmZmZmY4
MTIzNDk5Nj5dIHhlbmJ1c19kZXZfY2hhbmdlZCsweDE5Ni8weDFhMAo+PiDCoFs8ZmZmZmZmZmY4
MTAxMDFhZj5dID8geGVuX3Jlc3RvcmVfZmxfZGlyZWN0X2VuZCsweDAvMHgxCj4+IMKgWzxmZmZm
ZmZmZjgxMDM2NTJiPl0gPyBfX21pZ2h0X3NsZWVwKzB4M2IvMHgxMTAKPj4gwqBbPGZmZmZmZmZm
ODEyMzUwYjY+XSBiYWNrZW5kX2NoYW5nZWQrMHgxNi8weDIwCj4+IMKgWzxmZmZmZmZmZjgxMjMz
ZTRiPl0geGVud2F0Y2hfdGhyZWFkKzB4MTBiLzB4MTUwCj4+IMKgWzxmZmZmZmZmZjgxMDU3ZDkw
Pl0gPyBhdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4NDAKPj4gwqBbPGZmZmZmZmZmODEy
MzNkNDA+XSA/IHhlbndhdGNoX3RocmVhZCsweDAvMHgxNTAKPj4gwqBbPGZmZmZmZmZmODEwNTdj
MWU+XSBrdGhyZWFkKzB4OGUvMHhhMAo+PiDCoFs8ZmZmZmZmZmY4MTAxNGRmYT5dIGNoaWxkX3Jp
cCsweGEvMHgyMAo+PiDCoFs8ZmZmZmZmZmY4MTAxM2ZhNj5dID8gaW50X3JldF9mcm9tX3N5c19j
YWxsKzB4Ny8weDFiCj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCj4+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KPj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 23 19:23:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 19:23:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpPTn-0004EX-RE; Mon, 23 Jan 2012 19:22:59 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.camachat@gmail.com>) id 1RpPTm-0004EH-K7
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 19:22:58 +0000
X-Env-Sender: eric.camachat@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327346571!12187464!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 11715 invoked from network); 23 Jan 2012 19:22:52 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	23 Jan 2012 19:22:52 -0000
Received: by yenr9 with SMTP id r9so45542740yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 23 Jan 2012 11:22: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:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=OvKKyClF5rc98jgNj9h3jg8mU4WTdl5tiETMfQXCPls=;
	b=TOogOgK7P5Jn3m69VpF5FkACbu4tDf12H/o2LcewSG9e3HxRPppzVdpyRWbiEwF4yA
	v2VdpzhdqpZCUxIdIOxL4GVxHkanNeRnG9FV1rZ2/s0O8y20ZPaCbGQjioj8TTpUeq0e
	aLK2VYl0QraeCvvUGRBhbzT33hxpbPWGIErgk=
Received: by 10.236.80.65 with SMTP id j41mr11824010yhe.115.1327346569200;
	Mon, 23 Jan 2012 11:22:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.157.136 with HTTP; Mon, 23 Jan 2012 11:22:28 -0800 (PST)
In-Reply-To: <20120122202337.GA30288@andromeda.dapyr.net>
References: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
	<20120122202337.GA30288@andromeda.dapyr.net>
From: Eric Camachat <eric.camachat@gmail.com>
Date: Mon, 23 Jan 2012 11:22:28 -0800
Message-ID: <CACeEFf60o2jJ=5exxEfVegfPAVN_VjV0L4MXYFK_RQx1XXGfPQ@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Got kernel BUG message while PCI pass-through to
	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

VGhhbmtzLCAgS29ucmFkLgoKRG8geW91IG1lYW4gZG9tMCBrZXJuZWw/IG9yIFRoZSBkb21VIGtl
cm5lbD8KCkVyaWMKCk9uIFN1biwgSmFuIDIyLCAyMDEyIGF0IDEyOjIzIFBNLCBLb25yYWQgUnpl
c3p1dGVrIFdpbGsKPGtvbnJhZEBkYXJub2sub3JnPiB3cm90ZToKPiBPbiBTYXQsIEphbiAyMSwg
MjAxMiBhdCAxMDozMjozN1BNIC0wODAwLCBFcmljIENhbWFjaGF0IHdyb3RlOgo+PiBIaSBhbGws
Cj4+Cj4+IEkgZ290IGtlcm5lbCBCVUcgbWVzc2FnZSB3aGVuIFBDSSBwYXNzIHRocm91Z2ggdG8g
ZG9tVSAoeGVuLXB2KS4KPj4gSXMgdGhlcmUgYW55IG9uZSBzZWVuIHRoaXM/Cj4KPiBZZXMuIFRo
ZSBmaXggaXMgaW4gdGhlIHVwc3RyZWFtIGtlcm5lbC4gUGxlYXNlIHVzZSAzLjEuCj4KPj4KPj4g
RXJpYwo+Pgo+PiBkb20wIGtlcm5lbCBjb25maWc6Cj4+ICQgZ3JlcCBYRU5fUENJIGxpbnV4LTIu
Ni4zMi4yNC8uY29uZmlnCj4+IENPTkZJR19YRU5fUENJX1BBU1NUSFJPVUdIPXkKPj4gQ09ORklH
X1hFTl9QQ0lERVZfRlJPTlRFTkQ9eQo+PiBDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EPXkKPj4g
IyBDT05GSUdfWEVOX1BDSURFVl9CQUNLRU5EX1ZQQ0kgaXMgbm90IHNldAo+PiBDT05GSUdfWEVO
X1BDSURFVl9CQUNLRU5EX1BBU1M9eQo+PiAjIENPTkZJR19YRU5fUENJREVWX0JBQ0tFTkRfU0xP
VCBpcyBub3Qgc2V0Cj4+ICMgQ09ORklHX1hFTl9QQ0lERVZfQkFDS0VORF9DT05UUk9MTEVSIGlz
IG5vdCBzZXQKPj4gIyBDT05GSUdfWEVOX1BDSURFVl9CRV9ERUJVRyBpcyBub3Qgc2V0Cj4+Cj4+
Cj4+IFdoZW4gc3RhcnQgZG9tVSwgZ290IHRoaXMgZXJyb3IgbWVzc2FnZSBpbiBkb20wOgo+PiBC
VUc6IHNsZWVwaW5nIGZ1bmN0aW9uIGNhbGxlZCBmcm9tIGludmFsaWQgY29udGV4dCBhdCBtbS9z
bGFiLmM6MzAxNgo+PiBpbl9hdG9taWMoKTogMSwgaXJxc19kaXNhYmxlZCgpOiAwLCBwaWQ6IDIx
LCBuYW1lOiB4ZW53YXRjaAo+PiBQaWQ6IDIxLCBjb21tOiB4ZW53YXRjaCBUYWludGVkOiBQIMKg
IMKgIMKgIMKgIMKgIDIuNi4zMi4yNC13cy1zeW1ib2wgIzEKPj4gQ2FsbCBUcmFjZToKPj4gwqBb
PGZmZmZmZmZmODEwMzY1ZTQ+XSBfX21pZ2h0X3NsZWVwKzB4ZjQvMHgxMTAKPj4gwqBbPGZmZmZm
ZmZmODEwYWM0Nzg+XSBfX2ttYWxsb2MrMHgxMTgvMHgxNDAKPj4gwqBbPGZmZmZmZmZmODExYzE4
Mzc+XSBrdmFzcHJpbnRmKzB4NTcvMHg5MAo+PiDCoFs8ZmZmZmZmZmY4MTNmY2Q4YT5dID8gZXJy
b3JfZXhpdCsweDJhLzB4NjAKPj4gwqBbPGZmZmZmZmZmODExYzE4ZDA+XSBrYXNwcmludGYrMHg2
MC8weDcwCj4+IMKgWzxmZmZmZmZmZjgxMDEwMWMyPl0gPyBjaGVja19ldmVudHMrMHgxMi8weDIw
Cj4+IMKgWzxmZmZmZmZmZjgxMDEwMWFmPl0gPyB4ZW5fcmVzdG9yZV9mbF9kaXJlY3RfZW5kKzB4
MC8weDEKPj4gwqBbPGZmZmZmZmZmODEwYWI2YTc+XSA/IGtmcmVlKzB4ODcvMHhkMAo+PiDCoFs8
ZmZmZmZmZmY4MTIzMzI4YT5dID8gcmVhZF9yZXBseSsweDEzYS8weDE1MAo+PiDCoFs8ZmZmZmZm
ZmY4MTIzMzdhZT5dIGpvaW4rMHg0ZS8weDYwCj4+IMKgWzxmZmZmZmZmZjgxMjMzOTZjPl0geGVu
YnVzX3JlYWQrMHgyYy8weDcwCj4+IMKgWzxmZmZmZmZmZjgxMjM0MDJmPl0geGVuYnVzX3NjYW5m
KzB4MmYvMHhhMAo+PiDCoFs8ZmZmZmZmZmY4MTAwZjgyZD5dID8geGVuX2ZvcmNlX2V2dGNobl9j
YWxsYmFjaysweGQvMHgxMAo+PiDCoFs8ZmZmZmZmZmY4MTAxMDFjMj5dID8gY2hlY2tfZXZlbnRz
KzB4MTIvMHgyMAo+PiDCoFs8ZmZmZmZmZmY4MTAxMDFhZj5dID8geGVuX3Jlc3RvcmVfZmxfZGly
ZWN0X2VuZCsweDAvMHgxCj4+IMKgWzxmZmZmZmZmZjgxMGFiNmE3Pl0gPyBrZnJlZSsweDg3LzB4
ZDAKPj4gwqBbPGZmZmZmZmZmODEyMzM5MWM+XSA/IHhlbmJ1c19wcmludGYrMHhiYy8weGUwCj4+
IMKgWzxmZmZmZmZmZjgxMDBmODJkPl0gPyB4ZW5fZm9yY2VfZXZ0Y2huX2NhbGxiYWNrKzB4ZC8w
eDEwCj4+IMKgWzxmZmZmZmZmZjgxMjNhNjAwPl0gcGNpYmFja19wdWJsaXNoX3BjaV9yb290KzB4
NDAvMHgxYTAKPj4gwqBbPGZmZmZmZmZmODEwMTAxYWY+XSA/IHhlbl9yZXN0b3JlX2ZsX2RpcmVj
dF9lbmQrMHgwLzB4MQo+PiBueDQ1MjQtN0FDNEYwIyBbPGZmZmZmZmZmODEwYWM1M2U+XSA/IGtt
ZW1fY2FjaGVfYWxsb2MrMHg5ZS8weGYwCj4+IMKgWzxmZmZmZmZmZjgxMDEwZTI2Pl0gPyB4ZW5f
cmVnaXN0ZXJfZGV2aWNlX2RvbWFpbl9vd25lcisweDg2LzB4YzAKPj4gwqBbPGZmZmZmZmZmODEy
M2NjNzg+XSBwY2liYWNrX3B1Ymxpc2hfcGNpX3Jvb3RzKzB4ODgvMHhjMAo+PiDCoFs8ZmZmZmZm
ZmY4MTIzYTVjMD5dID8gcGNpYmFja19wdWJsaXNoX3BjaV9yb290KzB4MC8weDFhMAo+PiDCoFs8
ZmZmZmZmZmY4MTIzYWFkZD5dIHBjaWJhY2tfYmVfd2F0Y2grMHgxZGQvMHgyOTAKPj4gwqBbPGZm
ZmZmZmZmODEyMzJkNjQ+XSA/IHhzX2Vycm9yKzB4MTQvMHgyMAo+PiDCoFs8ZmZmZmZmZmY4MTIz
MzU3MT5dID8geHNfd2F0Y2grMHg1MS8weDYwCj4+IMKgWzxmZmZmZmZmZjgxMjMzYjBkPl0gPyBy
ZWdpc3Rlcl94ZW5idXNfd2F0Y2grMHhkZC8weGYwCj4+IMKgWzxmZmZmZmZmZjgxMjNhOTAwPl0g
PyBwY2liYWNrX2JlX3dhdGNoKzB4MC8weDI5MAo+PiDCoFs8ZmZmZmZmZmY4MTIzYjBhOT5dIHBj
aWJhY2tfeGVuYnVzX3Byb2JlKzB4MTM5LzB4MTQwCj4+IMKgWzxmZmZmZmZmZjgxMjM0ZjNhPl0g
eGVuYnVzX2Rldl9wcm9iZSsweGFhLzB4MTMwCj4+IMKgWzxmZmZmZmZmZjgxMjc5NTBiPl0gZHJp
dmVyX3Byb2JlX2RldmljZSsweDdiLzB4MTYwCj4+IMKgWzxmZmZmZmZmZjgxMjc5N2UwPl0gPyBf
X2RldmljZV9hdHRhY2grMHgwLzB4NTAKPj4gwqBbPGZmZmZmZmZmODEyNzk4MWQ+XSBfX2Rldmlj
ZV9hdHRhY2grMHgzZC8weDUwCj4+IMKgWzxmZmZmZmZmZjgxMjc4NWU4Pl0gYnVzX2Zvcl9lYWNo
X2RydisweDY4LzB4OTAKPj4gwqBbPGZmZmZmZmZmODEyNzk3M2I+XSBkZXZpY2VfYXR0YWNoKzB4
N2IvMHg4MAo+PiDCoFs8ZmZmZmZmZmY4MTI3ODU2NT5dIGJ1c19wcm9iZV9kZXZpY2UrMHgyNS8w
eDQwCj4+IMKgWzxmZmZmZmZmZjgxMjc2YWMzPl0gZGV2aWNlX2FkZCsweDI5My8weDU3MAo+PiDC
oFs8ZmZmZmZmZmY4MTFiOGRhNj5dID8ga29iamVjdF9pbml0KzB4MzYvMHg4MAo+PiDCoFs8ZmZm
ZmZmZmY4MTI3NmRiOT5dIGRldmljZV9yZWdpc3RlcisweDE5LzB4MjAKPj4gwqBbPGZmZmZmZmZm
ODEyMzQ3ODA+XSB4ZW5idXNfcHJvYmVfbm9kZSsweDEzMC8weDFiMAo+PiDCoFs8ZmZmZmZmZmY4
MTIzNDk5Nj5dIHhlbmJ1c19kZXZfY2hhbmdlZCsweDE5Ni8weDFhMAo+PiDCoFs8ZmZmZmZmZmY4
MTAxMDFhZj5dID8geGVuX3Jlc3RvcmVfZmxfZGlyZWN0X2VuZCsweDAvMHgxCj4+IMKgWzxmZmZm
ZmZmZjgxMDM2NTJiPl0gPyBfX21pZ2h0X3NsZWVwKzB4M2IvMHgxMTAKPj4gwqBbPGZmZmZmZmZm
ODEyMzUwYjY+XSBiYWNrZW5kX2NoYW5nZWQrMHgxNi8weDIwCj4+IMKgWzxmZmZmZmZmZjgxMjMz
ZTRiPl0geGVud2F0Y2hfdGhyZWFkKzB4MTBiLzB4MTUwCj4+IMKgWzxmZmZmZmZmZjgxMDU3ZDkw
Pl0gPyBhdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4NDAKPj4gwqBbPGZmZmZmZmZmODEy
MzNkNDA+XSA/IHhlbndhdGNoX3RocmVhZCsweDAvMHgxNTAKPj4gwqBbPGZmZmZmZmZmODEwNTdj
MWU+XSBrdGhyZWFkKzB4OGUvMHhhMAo+PiDCoFs8ZmZmZmZmZmY4MTAxNGRmYT5dIGNoaWxkX3Jp
cCsweGEvMHgyMAo+PiDCoFs8ZmZmZmZmZmY4MTAxM2ZhNj5dID8gaW50X3JldF9mcm9tX3N5c19j
YWxsKzB4Ny8weDFiCj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCj4+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKPj4gWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KPj4gaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Mon Jan 23 19:33:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 19:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpPdT-0004TD-W0; Mon, 23 Jan 2012 19:32:59 +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 1RpPdS-0004T8-0T
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 19:32:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327347114!58106690!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5516 invoked from network); 23 Jan 2012 19:31:55 -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;
	23 Jan 2012 19:31:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,557,1320642000"; d="scan'208";a="178733731"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 14:32:52 -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, 23 Jan 2012 14:32:52 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0NJWl2x032362;
	Mon, 23 Jan 2012 11:32:47 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 23 Jan 2012 19:32:25 +0000
Message-ID: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to always
	fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
xen_spinlock is 32 bits.  When a spin lock is contended and
xl->spinners is modified the two bytes immediately after the spin lock
would be corrupted.

This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
(x86, ticketlock: Clean up types and accessors) which reduced the size
of arch_spinlock_t.

Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
BUILD_BUG_ON() is also added to check the sizes of the two structures
are compatible.

In many cases this was not noticable as there would often be padding
bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).

The bnx2 driver is affected. In struct bnx2, phy_lock and
indirect_lock may have no padding after them.  Contention on phy_lock
would corrupt indirect_lock making it appear locked and the driver
would deadlock.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
---
 arch/x86/xen/spinlock.c |   27 ++++++++++++++++++++++-----
 1 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index cc9b1e1..d69cc6c 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -116,9 +116,26 @@ static inline void spin_time_accum_blocked(u64 start)
 }
 #endif  /* CONFIG_XEN_DEBUG_FS */
 
+/*
+ * Size struct xen_spinlock so it's the same as arch_spinlock_t.
+ */
+#if NR_CPUS < 256
+typedef u8 xen_spinners_t;
+# define inc_spinners(xl) \
+	asm(LOCK_PREFIX " incb %0" : "+m" ((xl)->spinners) : : "memory");
+# define dec_spinners(xl) \
+	asm(LOCK_PREFIX " decb %0" : "+m" ((xl)->spinners) : : "memory");
+#else
+typedef u16 xen_spinners_t;
+# define inc_spinners(xl) \
+	asm(LOCK_PREFIX " incw %0" : "+m" ((xl)->spinners) : : "memory");
+# define dec_spinners(xl) \
+	asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
+#endif
+
 struct xen_spinlock {
 	unsigned char lock;		/* 0 -> free; 1 -> locked */
-	unsigned short spinners;	/* count of waiting cpus */
+	xen_spinners_t spinners;	/* count of waiting cpus */
 };
 
 static int xen_spin_is_locked(struct arch_spinlock *lock)
@@ -164,8 +181,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
 
 	wmb();			/* set lock of interest before count */
 
-	asm(LOCK_PREFIX " incw %0"
-	    : "+m" (xl->spinners) : : "memory");
+	inc_spinners(xl);
 
 	return prev;
 }
@@ -176,8 +192,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
  */
 static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev)
 {
-	asm(LOCK_PREFIX " decw %0"
-	    : "+m" (xl->spinners) : : "memory");
+	dec_spinners(xl);
 	wmb();			/* decrement count before restoring lock */
 	__this_cpu_write(lock_spinners, prev);
 }
@@ -373,6 +388,8 @@ void xen_uninit_lock_cpu(int cpu)
 
 void __init xen_init_spinlocks(void)
 {
+	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
+
 	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
 	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
 	pv_lock_ops.spin_lock = xen_spin_lock;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 19:33:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 19:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpPdT-0004TD-W0; Mon, 23 Jan 2012 19:32:59 +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 1RpPdS-0004T8-0T
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 19:32:58 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327347114!58106690!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQzNzE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5516 invoked from network); 23 Jan 2012 19:31:55 -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;
	23 Jan 2012 19:31:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,557,1320642000"; d="scan'208";a="178733731"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 14:32:52 -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, 23 Jan 2012 14:32:52 -0500
Received: from qabil.uk.xensource.com (qabil.uk.xensource.com [10.80.2.76])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0NJWl2x032362;
	Mon, 23 Jan 2012 11:32:47 -0800
From: David Vrabel <david.vrabel@citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 23 Jan 2012 19:32:25 +0000
Message-ID: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to always
	fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: David Vrabel <david.vrabel@citrix.com>

If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
xen_spinlock is 32 bits.  When a spin lock is contended and
xl->spinners is modified the two bytes immediately after the spin lock
would be corrupted.

This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
(x86, ticketlock: Clean up types and accessors) which reduced the size
of arch_spinlock_t.

Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
BUILD_BUG_ON() is also added to check the sizes of the two structures
are compatible.

In many cases this was not noticable as there would often be padding
bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).

The bnx2 driver is affected. In struct bnx2, phy_lock and
indirect_lock may have no padding after them.  Contention on phy_lock
would corrupt indirect_lock making it appear locked and the driver
would deadlock.

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
---
 arch/x86/xen/spinlock.c |   27 ++++++++++++++++++++++-----
 1 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index cc9b1e1..d69cc6c 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -116,9 +116,26 @@ static inline void spin_time_accum_blocked(u64 start)
 }
 #endif  /* CONFIG_XEN_DEBUG_FS */
 
+/*
+ * Size struct xen_spinlock so it's the same as arch_spinlock_t.
+ */
+#if NR_CPUS < 256
+typedef u8 xen_spinners_t;
+# define inc_spinners(xl) \
+	asm(LOCK_PREFIX " incb %0" : "+m" ((xl)->spinners) : : "memory");
+# define dec_spinners(xl) \
+	asm(LOCK_PREFIX " decb %0" : "+m" ((xl)->spinners) : : "memory");
+#else
+typedef u16 xen_spinners_t;
+# define inc_spinners(xl) \
+	asm(LOCK_PREFIX " incw %0" : "+m" ((xl)->spinners) : : "memory");
+# define dec_spinners(xl) \
+	asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
+#endif
+
 struct xen_spinlock {
 	unsigned char lock;		/* 0 -> free; 1 -> locked */
-	unsigned short spinners;	/* count of waiting cpus */
+	xen_spinners_t spinners;	/* count of waiting cpus */
 };
 
 static int xen_spin_is_locked(struct arch_spinlock *lock)
@@ -164,8 +181,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
 
 	wmb();			/* set lock of interest before count */
 
-	asm(LOCK_PREFIX " incw %0"
-	    : "+m" (xl->spinners) : : "memory");
+	inc_spinners(xl);
 
 	return prev;
 }
@@ -176,8 +192,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
  */
 static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev)
 {
-	asm(LOCK_PREFIX " decw %0"
-	    : "+m" (xl->spinners) : : "memory");
+	dec_spinners(xl);
 	wmb();			/* decrement count before restoring lock */
 	__this_cpu_write(lock_spinners, prev);
 }
@@ -373,6 +388,8 @@ void xen_uninit_lock_cpu(int cpu)
 
 void __init xen_init_spinlocks(void)
 {
+	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
+
 	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
 	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
 	pv_lock_ops.spin_lock = xen_spin_lock;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 19:53:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 19:53:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpPx2-00056g-IJ; Mon, 23 Jan 2012 19:53:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpPx0-00056Y-Nx
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 19:53:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327348368!63622569!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18911 invoked from network); 23 Jan 2012 19:52:49 -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; 23 Jan 2012 19:52: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
	q0NJr4wD011441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 19:53:05 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0NJr3LY003263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 19:53:03 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0NJr2f2002883; Mon, 23 Jan 2012 13:53:02 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 11:53:02 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B82AB40157; Mon, 23 Jan 2012 14:50:47 -0500 (EST)
Date: Mon, 23 Jan 2012 14:50:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120123195047.GA11002@phenom.dumpdata.com>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F1DBAA1.00F7,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
 always fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 07:32:25PM +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
> xen_spinlock is 32 bits.  When a spin lock is contended and
> xl->spinners is modified the two bytes immediately after the spin lock
> would be corrupted.
> 
> This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
> (x86, ticketlock: Clean up types and accessors) which reduced the size
> of arch_spinlock_t.
> 
> Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
> BUILD_BUG_ON() is also added to check the sizes of the two structures
> are compatible.
> 
> In many cases this was not noticable as there would often be padding
> bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
> CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
> 
> The bnx2 driver is affected. In struct bnx2, phy_lock and
> indirect_lock may have no padding after them.  Contention on phy_lock
> would corrupt indirect_lock making it appear locked and the driver
> would deadlock.

Nice find. I think it also affected the ahci driver, and some of the USB
ones - at least those I saw starting to hang with:

[   79.317407] BUG: soft lockup - CPU#1 stuck for 22s! [modprobe:2244]

Do you have some of those messages by any chance?

Going to test this overnight to see if it fixes the mysterious rash of
32-bit v3.3-rc1 build dying and showing:

 [<c1308681>] ? xen_poll_irq_timeout+0x41/0x60
 [<c13086ac>] xen_poll_irq+0xc/0x10
 [<c104447a>] xen_spin_lock_slow+0xca/0x210
 [<c10447bc>] xen_spin_lock+0xec/0x100
 [<c154a561>] _raw_spin_lock+0x21/0x30

Thanks!
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> ---
>  arch/x86/xen/spinlock.c |   27 ++++++++++++++++++++++-----
>  1 files changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index cc9b1e1..d69cc6c 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -116,9 +116,26 @@ static inline void spin_time_accum_blocked(u64 start)
>  }
>  #endif  /* CONFIG_XEN_DEBUG_FS */
>  
> +/*
> + * Size struct xen_spinlock so it's the same as arch_spinlock_t.
> + */
> +#if NR_CPUS < 256
> +typedef u8 xen_spinners_t;
> +# define inc_spinners(xl) \
> +	asm(LOCK_PREFIX " incb %0" : "+m" ((xl)->spinners) : : "memory");
> +# define dec_spinners(xl) \
> +	asm(LOCK_PREFIX " decb %0" : "+m" ((xl)->spinners) : : "memory");
> +#else
> +typedef u16 xen_spinners_t;
> +# define inc_spinners(xl) \
> +	asm(LOCK_PREFIX " incw %0" : "+m" ((xl)->spinners) : : "memory");
> +# define dec_spinners(xl) \
> +	asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
> +#endif
> +
>  struct xen_spinlock {
>  	unsigned char lock;		/* 0 -> free; 1 -> locked */
> -	unsigned short spinners;	/* count of waiting cpus */
> +	xen_spinners_t spinners;	/* count of waiting cpus */
>  };
>  
>  static int xen_spin_is_locked(struct arch_spinlock *lock)
> @@ -164,8 +181,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
>  
>  	wmb();			/* set lock of interest before count */
>  
> -	asm(LOCK_PREFIX " incw %0"
> -	    : "+m" (xl->spinners) : : "memory");
> +	inc_spinners(xl);
>  
>  	return prev;
>  }
> @@ -176,8 +192,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
>   */
>  static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev)
>  {
> -	asm(LOCK_PREFIX " decw %0"
> -	    : "+m" (xl->spinners) : : "memory");
> +	dec_spinners(xl);
>  	wmb();			/* decrement count before restoring lock */
>  	__this_cpu_write(lock_spinners, prev);
>  }
> @@ -373,6 +388,8 @@ void xen_uninit_lock_cpu(int cpu)
>  
>  void __init xen_init_spinlocks(void)
>  {
> +	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
> +
>  	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
>  	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
>  	pv_lock_ops.spin_lock = xen_spin_lock;
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 19:53:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 19:53:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpPx2-00056g-IJ; Mon, 23 Jan 2012 19:53:12 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpPx0-00056Y-Nx
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 19:53:10 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327348368!63622569!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18911 invoked from network); 23 Jan 2012 19:52:49 -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; 23 Jan 2012 19:52: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
	q0NJr4wD011441
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 19:53:05 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0NJr3LY003263
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 19:53:03 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0NJr2f2002883; Mon, 23 Jan 2012 13:53:02 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 11:53:02 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id B82AB40157; Mon, 23 Jan 2012 14:50:47 -0500 (EST)
Date: Mon, 23 Jan 2012 14:50:47 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Message-ID: <20120123195047.GA11002@phenom.dumpdata.com>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F1DBAA1.00F7,ss=1,re=0.000,fgs=0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
 always fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 07:32:25PM +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
> xen_spinlock is 32 bits.  When a spin lock is contended and
> xl->spinners is modified the two bytes immediately after the spin lock
> would be corrupted.
> 
> This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
> (x86, ticketlock: Clean up types and accessors) which reduced the size
> of arch_spinlock_t.
> 
> Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
> BUILD_BUG_ON() is also added to check the sizes of the two structures
> are compatible.
> 
> In many cases this was not noticable as there would often be padding
> bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
> CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
> 
> The bnx2 driver is affected. In struct bnx2, phy_lock and
> indirect_lock may have no padding after them.  Contention on phy_lock
> would corrupt indirect_lock making it appear locked and the driver
> would deadlock.

Nice find. I think it also affected the ahci driver, and some of the USB
ones - at least those I saw starting to hang with:

[   79.317407] BUG: soft lockup - CPU#1 stuck for 22s! [modprobe:2244]

Do you have some of those messages by any chance?

Going to test this overnight to see if it fixes the mysterious rash of
32-bit v3.3-rc1 build dying and showing:

 [<c1308681>] ? xen_poll_irq_timeout+0x41/0x60
 [<c13086ac>] xen_poll_irq+0xc/0x10
 [<c104447a>] xen_spin_lock_slow+0xca/0x210
 [<c10447bc>] xen_spin_lock+0xec/0x100
 [<c154a561>] _raw_spin_lock+0x21/0x30

Thanks!
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> ---
>  arch/x86/xen/spinlock.c |   27 ++++++++++++++++++++++-----
>  1 files changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index cc9b1e1..d69cc6c 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -116,9 +116,26 @@ static inline void spin_time_accum_blocked(u64 start)
>  }
>  #endif  /* CONFIG_XEN_DEBUG_FS */
>  
> +/*
> + * Size struct xen_spinlock so it's the same as arch_spinlock_t.
> + */
> +#if NR_CPUS < 256
> +typedef u8 xen_spinners_t;
> +# define inc_spinners(xl) \
> +	asm(LOCK_PREFIX " incb %0" : "+m" ((xl)->spinners) : : "memory");
> +# define dec_spinners(xl) \
> +	asm(LOCK_PREFIX " decb %0" : "+m" ((xl)->spinners) : : "memory");
> +#else
> +typedef u16 xen_spinners_t;
> +# define inc_spinners(xl) \
> +	asm(LOCK_PREFIX " incw %0" : "+m" ((xl)->spinners) : : "memory");
> +# define dec_spinners(xl) \
> +	asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
> +#endif
> +
>  struct xen_spinlock {
>  	unsigned char lock;		/* 0 -> free; 1 -> locked */
> -	unsigned short spinners;	/* count of waiting cpus */
> +	xen_spinners_t spinners;	/* count of waiting cpus */
>  };
>  
>  static int xen_spin_is_locked(struct arch_spinlock *lock)
> @@ -164,8 +181,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
>  
>  	wmb();			/* set lock of interest before count */
>  
> -	asm(LOCK_PREFIX " incw %0"
> -	    : "+m" (xl->spinners) : : "memory");
> +	inc_spinners(xl);
>  
>  	return prev;
>  }
> @@ -176,8 +192,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
>   */
>  static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev)
>  {
> -	asm(LOCK_PREFIX " decw %0"
> -	    : "+m" (xl->spinners) : : "memory");
> +	dec_spinners(xl);
>  	wmb();			/* decrement count before restoring lock */
>  	__this_cpu_write(lock_spinners, prev);
>  }
> @@ -373,6 +388,8 @@ void xen_uninit_lock_cpu(int cpu)
>  
>  void __init xen_init_spinlocks(void)
>  {
> +	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
> +
>  	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
>  	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
>  	pv_lock_ops.spin_lock = xen_spin_lock;
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 20:22:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 20: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 1RpQOx-0005xX-2b; Mon, 23 Jan 2012 20:22: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 1RpQOv-0005xS-20
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 20:22:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327350113!10369527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31691 invoked from network); 23 Jan 2012 20:21:54 -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;
	23 Jan 2012 20:21:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,557,1320624000"; d="scan'208";a="10231170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 20: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; Mon, 23 Jan 2012 20: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 1RpQOl-0001to-C4;
	Mon, 23 Jan 2012 20:21:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RpQOl-0006ir-5S;
	Mon, 23 Jan 2012 20:21:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11561-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 23 Jan 2012 20:21:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11561: 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 11561 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11561/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 11164
 test-amd64-amd64-xl-win       7 windows-install              fail   like 11217
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 11275
 test-amd64-amd64-win          7 windows-install              fail   like 11217

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-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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  370924e204dc
baseline version:
 xen                  80fdf2182bc6

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Marcus Granado <marcus.granado@eu.citrix.com>
  Paul Bolle <pebolle@tiscali.nl>
  Sascha Hauer <s.hauer@pengutronix.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <Tim.Deegan@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=370924e204dc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 370924e204dc
+ branch=xen-unstable
+ revision=370924e204dc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 370924e204dc ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 14 changesets with 57 changes to 51 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 20:22:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 20: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 1RpQOx-0005xX-2b; Mon, 23 Jan 2012 20:22: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 1RpQOv-0005xS-20
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 20:22:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327350113!10369527!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzgxMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31691 invoked from network); 23 Jan 2012 20:21:54 -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;
	23 Jan 2012 20:21:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,557,1320624000"; d="scan'208";a="10231170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 20: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; Mon, 23 Jan 2012 20: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 1RpQOl-0001to-C4;
	Mon, 23 Jan 2012 20:21:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RpQOl-0006ir-5S;
	Mon, 23 Jan 2012 20:21:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11561-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 23 Jan 2012 20:21:51 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11561: 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 11561 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11561/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xend-winxpsp3  7 windows-install              fail  like 11164
 test-amd64-amd64-xl-win       7 windows-install              fail   like 11217
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 11275
 test-amd64-amd64-win          7 windows-install              fail   like 11217

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-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-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  370924e204dc
baseline version:
 xen                  80fdf2182bc6

------------------------------------------------------------
People who touched revisions under test:
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Marcus Granado <marcus.granado@eu.citrix.com>
  Paul Bolle <pebolle@tiscali.nl>
  Sascha Hauer <s.hauer@pengutronix.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <Tim.Deegan@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=370924e204dc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 370924e204dc
+ branch=xen-unstable
+ revision=370924e204dc
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 370924e204dc ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 14 changesets with 57 changes to 51 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 20:57:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 20:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpQwu-0006ck-96; Mon, 23 Jan 2012 20:57:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RpQws-0006cf-Vs
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 20:57:07 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327352218!12225599!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21840 invoked from network); 23 Jan 2012 20:57:00 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 20:57:00 -0000
Received: from [192.168.168.154]
	(50-76-62-73-ip-static.hfc.comcastbusiness.net [50.76.62.73])
	(Authenticated sender: jeremy)
	by claw.goop.org (Postfix) with ESMTPSA id D555A948F;
	Mon, 23 Jan 2012 12:56:56 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Jeremy Fitzhardinge <jeremy@goop.org>
In-Reply-To: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
Date: Mon, 23 Jan 2012 12:57:11 -0800
Message-Id: <85CF1130-DC77-4859-8E48-7A07A55634F7@goop.org>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
	always fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Jan 23, 2012, at 11:32 AM, David Vrabel wrote:

> From: David Vrabel <david.vrabel@citrix.com>
> 
> If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
> xen_spinlock is 32 bits.  When a spin lock is contended and
> xl->spinners is modified the two bytes immediately after the spin lock
> would be corrupted.
> 
> This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
> (x86, ticketlock: Clean up types and accessors) which reduced the size
> of arch_spinlock_t.

Oh, *ouch*.  Very sorry about that one.

	J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 20:57:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 20:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpQwu-0006ck-96; Mon, 23 Jan 2012 20:57:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jeremy@goop.org>) id 1RpQws-0006cf-Vs
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 20:57:07 +0000
X-Env-Sender: jeremy@goop.org
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327352218!12225599!1
X-Originating-IP: [74.207.240.146]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21840 invoked from network); 23 Jan 2012 20:57:00 -0000
Received: from claw.goop.org (HELO claw.goop.org) (74.207.240.146)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 20:57:00 -0000
Received: from [192.168.168.154]
	(50-76-62-73-ip-static.hfc.comcastbusiness.net [50.76.62.73])
	(Authenticated sender: jeremy)
	by claw.goop.org (Postfix) with ESMTPSA id D555A948F;
	Mon, 23 Jan 2012 12:56:56 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Jeremy Fitzhardinge <jeremy@goop.org>
In-Reply-To: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
Date: Mon, 23 Jan 2012 12:57:11 -0800
Message-Id: <85CF1130-DC77-4859-8E48-7A07A55634F7@goop.org>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
	always fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


On Jan 23, 2012, at 11:32 AM, David Vrabel wrote:

> From: David Vrabel <david.vrabel@citrix.com>
> 
> If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
> xen_spinlock is 32 bits.  When a spin lock is contended and
> xl->spinners is modified the two bytes immediately after the spin lock
> would be corrupted.
> 
> This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
> (x86, ticketlock: Clean up types and accessors) which reduced the size
> of arch_spinlock_t.

Oh, *ouch*.  Very sorry about that one.

	J

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 20:59:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 20:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpQz6-0006le-07; Mon, 23 Jan 2012 20:59: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 1RpQz3-0006lS-Sf
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 20:59:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327352354!12076770!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18995 invoked from network); 23 Jan 2012 20:59:15 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 20:59:15 -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
	q0NKwvIW027954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 20:58:58 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
	q0NKwsSN012608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 20:58:55 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
	q0NKwrOA028859; Mon, 23 Jan 2012 14:58:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 12:58:53 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8E6AD40157; Mon, 23 Jan 2012 15:56:38 -0500 (EST)
Date: Mon, 23 Jan 2012 15:56:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>, a.p.zijlstra@chello.nl,
	tglx@linutronix.de, mingo@elte.hu, linux-kernel@vger.kernel.org
Message-ID: <20120123205638.GA8542@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F1DCA13.0016,ss=1,re=-2.300,fgs=0
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, gregkh@suse.de
Subject: [Xen-devel] v3.3-rc1, regression introduced by "sched,
 nohz: Implement sched group,
 domain aware nohz idle load balancing" when unplugging 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

Hey,

Not exactly sure how this patch does it, but with this git commit
0b005cf54eac170a8f22540ab096a6e07bf49e7c, the Linux kernel crashes
if I try to hot unplug VCPUs to the first (initial) domain.
This is found using git bisection, and if I use the kernel compiled
with 69e1e811dcc436a6b129dbef273ad9ec22d095ce (the previous commit)
it works nicely.
 
I am not really sure if xen_send_IPI_one needs to be updated, but
it looks as if an IPI to a non-existed (torn-down) CPU is sent.. Hmm.

The VCPU unplug mechanism uses the arch_unregister_cpu, so I think
this can also be reproduced by doing ACPI CPU hotplug on baremetal.

The steps to reproduce this are quite easy.

sh-4.1# uname -a
Linux tst018.dumpdata.com 3.2.0-rc1-00328-g0b005cf #1 SMP PREEMPT Mon Jan 23 15:34:43 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
sh-4.1# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   -b-       5.0  any cpu
Domain-0                             0     1    1   -b-       1.3  any cpu
Domain-0                             0     2    2   -b-       1.6  any cpu
Domain-0                             0     3    3   r--       2.0  any cpu
sh-4.1# xl vcpu-set 0 2
sh-4.1# [  123.856084] ------------[ cut here ]------------
[  123.857166] kernel BUG at /home/konrad/ssd/linux/drivers/xen/events.c:1071!
[  123.858265] invalid opcode: 0000 [#1] PREEMPT SMP 
[  123.859387] CPU 1 
[  123.859400] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sd_mod usbhid hid usb_storage nouveau ahci libahci ata_generic libata i915 fbcon ttm tileblit scsi_mod font mxm_wmi bitblit e1000e softcursor wmi drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs
[  123.864413] 
[  123.865679] Pid: 2568, comm: kworker/u:7 Not tainted 3.2.0-rc1-00328-g0b005cf #1                  /DQ67SW
[  123.867010] RIP: e030:[<ffffffff8138a81e>]  [<ffffffff8138a81e>] xen_send_IPI_one+0x2e/0x40
[  123.868352] RSP: e02b:ffff8803e2ea3c18  EFLAGS: 00010086
[  123.869688] RAX: 0000000000010980 RBX: 0000000000000001 RCX: 0000000000000002
[  123.871051] RDX: ffff8803e2ebc000 RSI: 0000000000000000 RDI: 00000000ffffffff
[  123.872407] RBP: ffff8803e2ea3c18 R08: 0000000000000000 R09: 0000000000000001
[  123.873768] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8803e2eb3800
[  123.875115] R13: 00000000fffd338f R14: ffff8803e2eb3800 R15: 0000000000000001
[  123.876458] FS:  00007fd00c8a4700(0000) GS:ffff8803e2ea0000(0000) knlGS:0000000000000000
[  123.877806] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  123.879169] CR2: 00007fd00c8a2000 CR3: 00000003bbd2c000 CR4: 0000000000002660
[  123.880538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  123.881900] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  123.883258] Process kworker/u:7 (pid: 2568, threadinfo ffff8803c39ce000, task ffff8803cc753d20)
[  123.884626] Stack:
[  123.885980]  ffff8803e2ea3c28 ffffffff81049d70 ffff8803e2ea3c78 ffffffff810c69b0
[  123.887376]  0000000000000001 00000002cc753d68 ffff8803e2ea3c78 ffff8803e2eb3800
[  123.888759]  0000000000000001 0000000000000001 ffff8803e2eb3800 ffff8803cc753d20
[  123.890136] Call Trace:
[  123.891455]  <IRQ> 
[  123.892763]  [<ffffffff81049d70>] xen_smp_send_reschedule+0x10/0x20
[  123.894085]  [<ffffffff810c69b0>] trigger_load_balance+0x260/0x330
[  123.895392]  [<ffffffff810bc044>] scheduler_tick+0x104/0x160
[  123.896691]  [<ffffffff8109a66e>] update_process_times+0x6e/0x90
[  123.897980]  [<ffffffff810d97c2>] tick_sched_timer+0x62/0xc0
[  123.899257]  [<ffffffff810b3766>] __run_hrtimer+0x96/0x280
[  123.900539]  [<ffffffff810d9760>] ? tick_nohz_handler+0x100/0x100
[  123.901846]  [<ffffffff810b3be6>] hrtimer_interrupt+0x106/0x240
[  123.903165]  [<ffffffff81042398>] xen_timer_interrupt+0x38/0x1f0
[  123.904478]  [<ffffffff810919bb>] ? irq_exit+0x7b/0x100
[  123.905780]  [<ffffffff8110eeed>] handle_irq_event_percpu+0x8d/0x290
[  123.907081]  [<ffffffff81112238>] handle_percpu_irq+0x48/0x70
[  123.908359]  [<ffffffff813891b1>] __xen_evtchn_do_upcall+0x1c1/0x2c0
[  123.909631]  [<ffffffff8138947f>] xen_evtchn_do_upcall+0x2f/0x50
[  123.910898]  [<ffffffff8164677e>] xen_do_hypervisor_callback+0x1e/0x30
[  123.912150]  <EOI> 
[  123.913384]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  123.914627]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  123.915847]  [<ffffffff81041e1d>] ? xen_force_evtchn_callback+0xd/0x10
[  123.917067]  [<ffffffff81042802>] ? check_events+0x12/0x20
[  123.918282]  [<ffffffff810427a9>] ? xen_irq_enable_direct_reloc+0x4/0x4
[  123.919508]  [<ffffffff8163cd6b>] ? _raw_spin_unlock_irq+0x2b/0x70
[  123.920718]  [<ffffffff810bc53e>] ? finish_task_switch+0x4e/0xe0
[  123.921913]  [<ffffffff8163b669>] ? __schedule+0x469/0x890
[  123.923103]  [<ffffffff8163bb6f>] ? schedule+0x3f/0x60
[  123.924285]  [<ffffffff816399ad>] ? schedule_timeout+0x1fd/0x350
[  123.925466]  [<ffffffff8104259c>] ? xen_clocksource_read+0x4c/0x80
[  123.926645]  [<ffffffff810c57f4>] ? update_curr+0x144/0x1e0
[  123.927816]  [<ffffffff8104a8c6>] ? xen_spin_lock+0xa6/0x110
[  123.928974]  [<ffffffff810bb491>] ? get_parent_ip+0x11/0x50
[  123.930117]  [<ffffffff8163aff0>] ? wait_for_common+0xd0/0x190
[  123.931262]  [<ffffffff810c0c20>] ? try_to_wake_up+0x2c0/0x2c0
[  123.932367]  [<ffffffff8163b18d>] ? wait_for_completion+0x1d/0x20
[  123.933427]  [<ffffffff81089eb9>] ? do_fork+0xe9/0x350
[  123.934440]  [<ffffffff810a5640>] ? call_usermodehelper_exec+0xe0/0xe0
[  123.935465]  [<ffffffff810557d6>] ? kernel_thread+0x76/0x80
[  123.936473]  [<ffffffff810a5290>] ? call_usermodehelper_setup+0xa0/0xa0
[  123.937471]  [<ffffffff81646630>] ? gs_change+0x13/0x13
[  123.938454]  [<ffffffff816409ad>] ? sub_preempt_count+0x9d/0xd0
[  123.939428]  [<ffffffff810a5677>] ? __call_usermodehelper+0x37/0xb0
[  123.940411]  [<ffffffff810a7b59>] ? process_one_work+0x129/0x4e0
[  123.941400]  [<ffffffff810a9c4e>] ? worker_thread+0x17e/0x410
[  123.942383]  [<ffffffff810a9ad0>] ? manage_workers+0x210/0x210
[  123.943363]  [<ffffffff810ae906>] ? kthread+0x96/0xa0
[  123.944327]  [<ffffffff81646634>] ? kernel_thread_helper+0x4/0x10
[  123.945287]  [<ffffffff816446e3>] ? int_ret_from_sys_call+0x7/0x1b
[  123.946238]  [<ffffffff8163d200>] ? retint_restore_args+0x5/0x6
[  123.947187]  [<ffffffff81646630>] ? gs_change+0x13/0x13
[  123.948132] Code: e5 66 66 66 66 90 48 c7 c0 80 09 01 00 89 ff 89 f6 48 8b 14 fd e0 28 ac 81 48 8d 04 b0 8b 3c 10 85 ff 78 07 e8 74 ff ff ff c9 c3 <0f> 0b eb fe 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 
[  123.950401] RIP  [<ffffffff8138a81e>] xen_send_IPI_one+0x2e/0x40
[  123.951419]  RSP <ffff8803e2ea3c18>
[  123.952425] ---[ end trace 4c21b5ae5c292a38 ]---
[  123.953438] Kernel panic - not syncing: Fatal exception in interrupt
[  123.954459] Pid: 2568, comm: kworker/u:7 Tainted: G      D      3.2.0-rc1-00328-g0b005cf #1
[  123.955508] Call Trace:
[  123.956539]  <IRQ>  [<ffffffff816394e2>] panic+0x9b/0x1c9
[  123.957592]  [<ffffffff81042802>] ? check_events+0x12/0x20
[  123.958644]  [<ffffffff8163df8a>] oops_end+0x10a/0x120
[  123.959694]  [<ffffffff8104fcbb>] die+0x5b/0x90
[  123.960736]  [<ffffffff8163d8c4>] do_trap+0xc4/0x170
[  123.961774]  [<ffffffff8104d906>] do_invalid_op+0xa6/0xc0
[  123.962813]  [<ffffffff8138a81e>] ? xen_send_IPI_one+0x2e/0x40
[  123.963850]  [<ffffffff810c510b>] ? find_busiest_group+0x9bb/0xac0
[  123.964890]  [<ffffffff816464ab>] invalid_op+0x1b/0x20
[  123.965929]  [<ffffffff8138a81e>] ? xen_send_IPI_one+0x2e/0x40
[  123.966967]  [<ffffffff81049d70>] xen_smp_send_reschedule+0x10/0x20
[  123.968009]  [<ffffffff810c69b0>] trigger_load_balance+0x260/0x330
[  123.969049]  [<ffffffff810bc044>] scheduler_tick+0x104/0x160
[  123.970086]  [<ffffffff8109a66e>] update_process_times+0x6e/0x90
[  123.971119]  [<ffffffff810d97c2>] tick_sched_timer+0x62/0xc0
[  123.972148]  [<ffffffff810b3766>] __run_hrtimer+0x96/0x280
[  123.973167]  [<ffffffff810d9760>] ? tick_nohz_handler+0x100/0x100
[  123.974203]  [<ffffffff810b3be6>] hrtimer_interrupt+0x106/0x240
[  123.975238]  [<ffffffff81042398>] xen_timer_interrupt+0x38/0x1f0
[  123.976274]  [<ffffffff810919bb>] ? irq_exit+0x7b/0x100
[  123.977308]  [<ffffffff8110eeed>] handle_irq_event_percpu+0x8d/0x290
[  123.978344]  [<ffffffff81112238>] handle_percpu_irq+0x48/0x70
[  123.979379]  [<ffffffff813891b1>] __xen_evtchn_do_upcall+0x1c1/0x2c0
[  123.980422]  [<ffffffff8138947f>] xen_evtchn_do_upcall+0x2f/0x50
[  123.981465]  [<ffffffff8164677e>] xen_do_hypervisor_callback+0x1e/0x30
[  123.982517]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  123.983584]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  123.984652]  [<ffffffff81041e1d>] ? xen_force_evtchn_callback+0xd/0x10
[  123.985721]  [<ffffffff81042802>] ? check_events+0x12/0x20
[  123.986792]  [<ffffffff810427a9>] ? xen_irq_enable_direct_reloc+0x4/0x4
[  123.987869]  [<ffffffff8163cd6b>] ? _raw_spin_unlock_irq+0x2b/0x70
[  123.988948]  [<ffffffff810bc53e>] ? finish_task_switch+0x4e/0xe0
[  123.990027]  [<ffffffff8163b669>] ? __schedule+0x469/0x890
[  123.991106]  [<ffffffff8163bb6f>] ? schedule+0x3f/0x60
[  123.992176]  [<ffffffff816399ad>] ? schedule_timeout+0x1fd/0x350
[  123.993244]  [<ffffffff8104259c>] ? xen_clocksource_read+0x4c/0x80
[  123.994308]  [<ffffffff810c57f4>] ? update_curr+0x144/0x1e0
[  123.995370]  [<ffffffff8104a8c6>] ? xen_spin_lock+0xa6/0x110
[  123.996429]  [<ffffffff810bb491>] ? get_parent_ip+0x11/0x50
[  123.997489]  [<ffffffff8163aff0>] ? wait_for_common+0xd0/0x190
[  123.998545]  [<ffffffff810c0c20>] ? try_to_wake_up+0x2c0/0x2c0
[  123.999600]  [<ffffffff8163b18d>] ? wait_for_completion+0x1d/0x20
[  124.000660]  [<ffffffff81089eb9>] ? do_fork+0xe9/0x350
[  124.001715]  [<ffffffff810a5640>] ? call_usermodehelper_exec+0xe0/0xe0
[  124.002781]  [<ffffffff810557d6>] ? kernel_thread+0x76/0x80
[  124.003847]  [<ffffffff810a5290>] ? call_usermodehelper_setup+0xa0/0xa0
[  124.004914]  [<ffffffff81646630>] ? gs_change+0x13/0x13
[  124.005982]  [<ffffffff816409ad>] ? sub_preempt_count+0x9d/0xd0
[  124.007009]  [<ffffffff810a5677>] ? __call_usermodehelper+0x37/0xb0
[  124.007991]  [<ffffffff810a7b59>] ? process_one_work+0x129/0x4e0
[  124.008965]  [<ffffffff810a9c4e>] ? worker_thread+0x17e/0x410
[  124.009923]  [<ffffffff810a9ad0>] ? manage_workers+0x210/0x210
[  124.010882]  [<ffffffff810ae906>] ? kthread+0x96/0xa0
[  124.011830]  [<ffffffff81646634>] ? kernel_thread_helper+0x4/0x10
[  124.012765]  [<ffffffff816446e3>] ? int_ret_from_sys_call+0x7/0x1b
[  124.013684]  [<ffffffff8163d200>] ? retint_restore_args+0x5/0x6
[  124.014603]  [<ffffffff81646630>] ? gs_change+0x13/0x13
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
amtterm: RUN_SOL -> ERROR (failure)
amtterm: ERROR: redir_data: unknown r->buf 0x29


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 20:59:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 20:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpQz6-0006le-07; Mon, 23 Jan 2012 20:59: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 1RpQz3-0006lS-Sf
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 20:59:22 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327352354!12076770!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18995 invoked from network); 23 Jan 2012 20:59:15 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 20:59:15 -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
	q0NKwvIW027954
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 20:58:58 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
	q0NKwsSN012608
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 20:58:55 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
	q0NKwrOA028859; Mon, 23 Jan 2012 14:58:53 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 12:58:53 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8E6AD40157; Mon, 23 Jan 2012 15:56:38 -0500 (EST)
Date: Mon, 23 Jan 2012 15:56:38 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Suresh Siddha <suresh.b.siddha@intel.com>, a.p.zijlstra@chello.nl,
	tglx@linutronix.de, mingo@elte.hu, linux-kernel@vger.kernel.org
Message-ID: <20120123205638.GA8542@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F1DCA13.0016,ss=1,re=-2.300,fgs=0
Cc: rjw@sisk.pl, xen-devel@lists.xensource.com, gregkh@suse.de
Subject: [Xen-devel] v3.3-rc1, regression introduced by "sched,
 nohz: Implement sched group,
 domain aware nohz idle load balancing" when unplugging 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

Hey,

Not exactly sure how this patch does it, but with this git commit
0b005cf54eac170a8f22540ab096a6e07bf49e7c, the Linux kernel crashes
if I try to hot unplug VCPUs to the first (initial) domain.
This is found using git bisection, and if I use the kernel compiled
with 69e1e811dcc436a6b129dbef273ad9ec22d095ce (the previous commit)
it works nicely.
 
I am not really sure if xen_send_IPI_one needs to be updated, but
it looks as if an IPI to a non-existed (torn-down) CPU is sent.. Hmm.

The VCPU unplug mechanism uses the arch_unregister_cpu, so I think
this can also be reproduced by doing ACPI CPU hotplug on baremetal.

The steps to reproduce this are quite easy.

sh-4.1# uname -a
Linux tst018.dumpdata.com 3.2.0-rc1-00328-g0b005cf #1 SMP PREEMPT Mon Jan 23 15:34:43 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
sh-4.1# xl vcpu-list
Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
Domain-0                             0     0    0   -b-       5.0  any cpu
Domain-0                             0     1    1   -b-       1.3  any cpu
Domain-0                             0     2    2   -b-       1.6  any cpu
Domain-0                             0     3    3   r--       2.0  any cpu
sh-4.1# xl vcpu-set 0 2
sh-4.1# [  123.856084] ------------[ cut here ]------------
[  123.857166] kernel BUG at /home/konrad/ssd/linux/drivers/xen/events.c:1071!
[  123.858265] invalid opcode: 0000 [#1] PREEMPT SMP 
[  123.859387] CPU 1 
[  123.859400] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c sg sd_mod usbhid hid usb_storage nouveau ahci libahci ata_generic libata i915 fbcon ttm tileblit scsi_mod font mxm_wmi bitblit e1000e softcursor wmi drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs
[  123.864413] 
[  123.865679] Pid: 2568, comm: kworker/u:7 Not tainted 3.2.0-rc1-00328-g0b005cf #1                  /DQ67SW
[  123.867010] RIP: e030:[<ffffffff8138a81e>]  [<ffffffff8138a81e>] xen_send_IPI_one+0x2e/0x40
[  123.868352] RSP: e02b:ffff8803e2ea3c18  EFLAGS: 00010086
[  123.869688] RAX: 0000000000010980 RBX: 0000000000000001 RCX: 0000000000000002
[  123.871051] RDX: ffff8803e2ebc000 RSI: 0000000000000000 RDI: 00000000ffffffff
[  123.872407] RBP: ffff8803e2ea3c18 R08: 0000000000000000 R09: 0000000000000001
[  123.873768] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8803e2eb3800
[  123.875115] R13: 00000000fffd338f R14: ffff8803e2eb3800 R15: 0000000000000001
[  123.876458] FS:  00007fd00c8a4700(0000) GS:ffff8803e2ea0000(0000) knlGS:0000000000000000
[  123.877806] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[  123.879169] CR2: 00007fd00c8a2000 CR3: 00000003bbd2c000 CR4: 0000000000002660
[  123.880538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  123.881900] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  123.883258] Process kworker/u:7 (pid: 2568, threadinfo ffff8803c39ce000, task ffff8803cc753d20)
[  123.884626] Stack:
[  123.885980]  ffff8803e2ea3c28 ffffffff81049d70 ffff8803e2ea3c78 ffffffff810c69b0
[  123.887376]  0000000000000001 00000002cc753d68 ffff8803e2ea3c78 ffff8803e2eb3800
[  123.888759]  0000000000000001 0000000000000001 ffff8803e2eb3800 ffff8803cc753d20
[  123.890136] Call Trace:
[  123.891455]  <IRQ> 
[  123.892763]  [<ffffffff81049d70>] xen_smp_send_reschedule+0x10/0x20
[  123.894085]  [<ffffffff810c69b0>] trigger_load_balance+0x260/0x330
[  123.895392]  [<ffffffff810bc044>] scheduler_tick+0x104/0x160
[  123.896691]  [<ffffffff8109a66e>] update_process_times+0x6e/0x90
[  123.897980]  [<ffffffff810d97c2>] tick_sched_timer+0x62/0xc0
[  123.899257]  [<ffffffff810b3766>] __run_hrtimer+0x96/0x280
[  123.900539]  [<ffffffff810d9760>] ? tick_nohz_handler+0x100/0x100
[  123.901846]  [<ffffffff810b3be6>] hrtimer_interrupt+0x106/0x240
[  123.903165]  [<ffffffff81042398>] xen_timer_interrupt+0x38/0x1f0
[  123.904478]  [<ffffffff810919bb>] ? irq_exit+0x7b/0x100
[  123.905780]  [<ffffffff8110eeed>] handle_irq_event_percpu+0x8d/0x290
[  123.907081]  [<ffffffff81112238>] handle_percpu_irq+0x48/0x70
[  123.908359]  [<ffffffff813891b1>] __xen_evtchn_do_upcall+0x1c1/0x2c0
[  123.909631]  [<ffffffff8138947f>] xen_evtchn_do_upcall+0x2f/0x50
[  123.910898]  [<ffffffff8164677e>] xen_do_hypervisor_callback+0x1e/0x30
[  123.912150]  <EOI> 
[  123.913384]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  123.914627]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  123.915847]  [<ffffffff81041e1d>] ? xen_force_evtchn_callback+0xd/0x10
[  123.917067]  [<ffffffff81042802>] ? check_events+0x12/0x20
[  123.918282]  [<ffffffff810427a9>] ? xen_irq_enable_direct_reloc+0x4/0x4
[  123.919508]  [<ffffffff8163cd6b>] ? _raw_spin_unlock_irq+0x2b/0x70
[  123.920718]  [<ffffffff810bc53e>] ? finish_task_switch+0x4e/0xe0
[  123.921913]  [<ffffffff8163b669>] ? __schedule+0x469/0x890
[  123.923103]  [<ffffffff8163bb6f>] ? schedule+0x3f/0x60
[  123.924285]  [<ffffffff816399ad>] ? schedule_timeout+0x1fd/0x350
[  123.925466]  [<ffffffff8104259c>] ? xen_clocksource_read+0x4c/0x80
[  123.926645]  [<ffffffff810c57f4>] ? update_curr+0x144/0x1e0
[  123.927816]  [<ffffffff8104a8c6>] ? xen_spin_lock+0xa6/0x110
[  123.928974]  [<ffffffff810bb491>] ? get_parent_ip+0x11/0x50
[  123.930117]  [<ffffffff8163aff0>] ? wait_for_common+0xd0/0x190
[  123.931262]  [<ffffffff810c0c20>] ? try_to_wake_up+0x2c0/0x2c0
[  123.932367]  [<ffffffff8163b18d>] ? wait_for_completion+0x1d/0x20
[  123.933427]  [<ffffffff81089eb9>] ? do_fork+0xe9/0x350
[  123.934440]  [<ffffffff810a5640>] ? call_usermodehelper_exec+0xe0/0xe0
[  123.935465]  [<ffffffff810557d6>] ? kernel_thread+0x76/0x80
[  123.936473]  [<ffffffff810a5290>] ? call_usermodehelper_setup+0xa0/0xa0
[  123.937471]  [<ffffffff81646630>] ? gs_change+0x13/0x13
[  123.938454]  [<ffffffff816409ad>] ? sub_preempt_count+0x9d/0xd0
[  123.939428]  [<ffffffff810a5677>] ? __call_usermodehelper+0x37/0xb0
[  123.940411]  [<ffffffff810a7b59>] ? process_one_work+0x129/0x4e0
[  123.941400]  [<ffffffff810a9c4e>] ? worker_thread+0x17e/0x410
[  123.942383]  [<ffffffff810a9ad0>] ? manage_workers+0x210/0x210
[  123.943363]  [<ffffffff810ae906>] ? kthread+0x96/0xa0
[  123.944327]  [<ffffffff81646634>] ? kernel_thread_helper+0x4/0x10
[  123.945287]  [<ffffffff816446e3>] ? int_ret_from_sys_call+0x7/0x1b
[  123.946238]  [<ffffffff8163d200>] ? retint_restore_args+0x5/0x6
[  123.947187]  [<ffffffff81646630>] ? gs_change+0x13/0x13
[  123.948132] Code: e5 66 66 66 66 90 48 c7 c0 80 09 01 00 89 ff 89 f6 48 8b 14 fd e0 28 ac 81 48 8d 04 b0 8b 3c 10 85 ff 78 07 e8 74 ff ff ff c9 c3 <0f> 0b eb fe 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 
[  123.950401] RIP  [<ffffffff8138a81e>] xen_send_IPI_one+0x2e/0x40
[  123.951419]  RSP <ffff8803e2ea3c18>
[  123.952425] ---[ end trace 4c21b5ae5c292a38 ]---
[  123.953438] Kernel panic - not syncing: Fatal exception in interrupt
[  123.954459] Pid: 2568, comm: kworker/u:7 Tainted: G      D      3.2.0-rc1-00328-g0b005cf #1
[  123.955508] Call Trace:
[  123.956539]  <IRQ>  [<ffffffff816394e2>] panic+0x9b/0x1c9
[  123.957592]  [<ffffffff81042802>] ? check_events+0x12/0x20
[  123.958644]  [<ffffffff8163df8a>] oops_end+0x10a/0x120
[  123.959694]  [<ffffffff8104fcbb>] die+0x5b/0x90
[  123.960736]  [<ffffffff8163d8c4>] do_trap+0xc4/0x170
[  123.961774]  [<ffffffff8104d906>] do_invalid_op+0xa6/0xc0
[  123.962813]  [<ffffffff8138a81e>] ? xen_send_IPI_one+0x2e/0x40
[  123.963850]  [<ffffffff810c510b>] ? find_busiest_group+0x9bb/0xac0
[  123.964890]  [<ffffffff816464ab>] invalid_op+0x1b/0x20
[  123.965929]  [<ffffffff8138a81e>] ? xen_send_IPI_one+0x2e/0x40
[  123.966967]  [<ffffffff81049d70>] xen_smp_send_reschedule+0x10/0x20
[  123.968009]  [<ffffffff810c69b0>] trigger_load_balance+0x260/0x330
[  123.969049]  [<ffffffff810bc044>] scheduler_tick+0x104/0x160
[  123.970086]  [<ffffffff8109a66e>] update_process_times+0x6e/0x90
[  123.971119]  [<ffffffff810d97c2>] tick_sched_timer+0x62/0xc0
[  123.972148]  [<ffffffff810b3766>] __run_hrtimer+0x96/0x280
[  123.973167]  [<ffffffff810d9760>] ? tick_nohz_handler+0x100/0x100
[  123.974203]  [<ffffffff810b3be6>] hrtimer_interrupt+0x106/0x240
[  123.975238]  [<ffffffff81042398>] xen_timer_interrupt+0x38/0x1f0
[  123.976274]  [<ffffffff810919bb>] ? irq_exit+0x7b/0x100
[  123.977308]  [<ffffffff8110eeed>] handle_irq_event_percpu+0x8d/0x290
[  123.978344]  [<ffffffff81112238>] handle_percpu_irq+0x48/0x70
[  123.979379]  [<ffffffff813891b1>] __xen_evtchn_do_upcall+0x1c1/0x2c0
[  123.980422]  [<ffffffff8138947f>] xen_evtchn_do_upcall+0x2f/0x50
[  123.981465]  [<ffffffff8164677e>] xen_do_hypervisor_callback+0x1e/0x30
[  123.982517]  <EOI>  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  123.983584]  [<ffffffff8100122a>] ? hypercall_page+0x22a/0x1000
[  123.984652]  [<ffffffff81041e1d>] ? xen_force_evtchn_callback+0xd/0x10
[  123.985721]  [<ffffffff81042802>] ? check_events+0x12/0x20
[  123.986792]  [<ffffffff810427a9>] ? xen_irq_enable_direct_reloc+0x4/0x4
[  123.987869]  [<ffffffff8163cd6b>] ? _raw_spin_unlock_irq+0x2b/0x70
[  123.988948]  [<ffffffff810bc53e>] ? finish_task_switch+0x4e/0xe0
[  123.990027]  [<ffffffff8163b669>] ? __schedule+0x469/0x890
[  123.991106]  [<ffffffff8163bb6f>] ? schedule+0x3f/0x60
[  123.992176]  [<ffffffff816399ad>] ? schedule_timeout+0x1fd/0x350
[  123.993244]  [<ffffffff8104259c>] ? xen_clocksource_read+0x4c/0x80
[  123.994308]  [<ffffffff810c57f4>] ? update_curr+0x144/0x1e0
[  123.995370]  [<ffffffff8104a8c6>] ? xen_spin_lock+0xa6/0x110
[  123.996429]  [<ffffffff810bb491>] ? get_parent_ip+0x11/0x50
[  123.997489]  [<ffffffff8163aff0>] ? wait_for_common+0xd0/0x190
[  123.998545]  [<ffffffff810c0c20>] ? try_to_wake_up+0x2c0/0x2c0
[  123.999600]  [<ffffffff8163b18d>] ? wait_for_completion+0x1d/0x20
[  124.000660]  [<ffffffff81089eb9>] ? do_fork+0xe9/0x350
[  124.001715]  [<ffffffff810a5640>] ? call_usermodehelper_exec+0xe0/0xe0
[  124.002781]  [<ffffffff810557d6>] ? kernel_thread+0x76/0x80
[  124.003847]  [<ffffffff810a5290>] ? call_usermodehelper_setup+0xa0/0xa0
[  124.004914]  [<ffffffff81646630>] ? gs_change+0x13/0x13
[  124.005982]  [<ffffffff816409ad>] ? sub_preempt_count+0x9d/0xd0
[  124.007009]  [<ffffffff810a5677>] ? __call_usermodehelper+0x37/0xb0
[  124.007991]  [<ffffffff810a7b59>] ? process_one_work+0x129/0x4e0
[  124.008965]  [<ffffffff810a9c4e>] ? worker_thread+0x17e/0x410
[  124.009923]  [<ffffffff810a9ad0>] ? manage_workers+0x210/0x210
[  124.010882]  [<ffffffff810ae906>] ? kthread+0x96/0xa0
[  124.011830]  [<ffffffff81646634>] ? kernel_thread_helper+0x4/0x10
[  124.012765]  [<ffffffff816446e3>] ? int_ret_from_sys_call+0x7/0x1b
[  124.013684]  [<ffffffff8163d200>] ? retint_restore_args+0x5/0x6
[  124.014603]  [<ffffffff81646630>] ? gs_change+0x13/0x13
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
amtterm: RUN_SOL -> ERROR (failure)
amtterm: ERROR: redir_data: unknown r->buf 0x29


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 21:01:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 21: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 1RpR0h-0006sy-G0; Mon, 23 Jan 2012 21:01:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <a.p.zijlstra@chello.nl>) id 1RpR0f-0006sC-Bz
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 21:01:02 +0000
X-Env-Sender: a.p.zijlstra@chello.nl
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327352454!12092818!1
X-Originating-IP: [85.118.1.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8594 invoked from network); 23 Jan 2012 21:00:55 -0000
Received: from casper.infradead.org (HELO casper.infradead.org) (85.118.1.10)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 21:00:55 -0000
Received: from 178-85-86-190.dynamic.upc.nl ([178.85.86.190] helo=twins)
	by casper.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1RpR0U-0005DV-1z; Mon, 23 Jan 2012 21:00:50 +0000
Received: by twins (Postfix, from userid 1000)
	id 4C1E78277E7C; Mon, 23 Jan 2012 22:00:49 +0100 (CET)
Message-ID: <1327352449.2446.19.camel@twins>
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 22:00:49 +0100
In-Reply-To: <20120123205638.GA8542@phenom.dumpdata.com>
References: <20120123205638.GA8542@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.1- 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	gregkh@suse.de, linux-kernel@vger.kernel.org, rjw@sisk.pl,
	tglx@linutronix.de, mingo@elte.hu
Subject: Re: [Xen-devel] v3.3-rc1, regression introduced by "sched,
 nohz: Implement sched group,
 domain aware nohz idle load balancing" when unplugging 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 Mon, 2012-01-23 at 15:56 -0500, Konrad Rzeszutek Wilk wrote:
> Not exactly sure how this patch does it, but with this git commit
> 0b005cf54eac170a8f22540ab096a6e07bf49e7c, the Linux kernel crashes
> if I try to hot unplug VCPUs to the first (initial) domain.
> This is found using git bisection, and if I use the kernel compiled
> with 69e1e811dcc436a6b129dbef273ad9ec22d095ce (the previous commit)
> it works nicely. 

https://lkml.org/lkml/2012/1/19/463

is already on its way...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 21:01:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 21: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 1RpR0h-0006sy-G0; Mon, 23 Jan 2012 21:01:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <a.p.zijlstra@chello.nl>) id 1RpR0f-0006sC-Bz
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 21:01:02 +0000
X-Env-Sender: a.p.zijlstra@chello.nl
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327352454!12092818!1
X-Originating-IP: [85.118.1.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8594 invoked from network); 23 Jan 2012 21:00:55 -0000
Received: from casper.infradead.org (HELO casper.infradead.org) (85.118.1.10)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 21:00:55 -0000
Received: from 178-85-86-190.dynamic.upc.nl ([178.85.86.190] helo=twins)
	by casper.infradead.org with esmtpsa (Exim 4.76 #1 (Red Hat Linux))
	id 1RpR0U-0005DV-1z; Mon, 23 Jan 2012 21:00:50 +0000
Received: by twins (Postfix, from userid 1000)
	id 4C1E78277E7C; Mon, 23 Jan 2012 22:00:49 +0100 (CET)
Message-ID: <1327352449.2446.19.camel@twins>
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 23 Jan 2012 22:00:49 +0100
In-Reply-To: <20120123205638.GA8542@phenom.dumpdata.com>
References: <20120123205638.GA8542@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.1- 
Mime-Version: 1.0
Cc: xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	gregkh@suse.de, linux-kernel@vger.kernel.org, rjw@sisk.pl,
	tglx@linutronix.de, mingo@elte.hu
Subject: Re: [Xen-devel] v3.3-rc1, regression introduced by "sched,
 nohz: Implement sched group,
 domain aware nohz idle load balancing" when unplugging 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 Mon, 2012-01-23 at 15:56 -0500, Konrad Rzeszutek Wilk wrote:
> Not exactly sure how this patch does it, but with this git commit
> 0b005cf54eac170a8f22540ab096a6e07bf49e7c, the Linux kernel crashes
> if I try to hot unplug VCPUs to the first (initial) domain.
> This is found using git bisection, and if I use the kernel compiled
> with 69e1e811dcc436a6b129dbef273ad9ec22d095ce (the previous commit)
> it works nicely. 

https://lkml.org/lkml/2012/1/19/463

is already on its way...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 21:19:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 21:19:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpRHl-0007Gz-5t; Mon, 23 Jan 2012 21:18:41 +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 1RpRHj-0007Ge-UV
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 21:18:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327353512!10360999!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4618 invoked from network); 23 Jan 2012 21:18:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 21:18:33 -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
	q0NLD8Ee014118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 21:13:21 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
	q0NLD6un006432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 21:13:07 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0NLD5go006467; Mon, 23 Jan 2012 15:13:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 13:13:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4746340157; Mon, 23 Jan 2012 16:10:51 -0500 (EST)
Date: Mon, 23 Jan 2012 16:10:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Message-ID: <20120123211051.GA10967@phenom.dumpdata.com>
References: <20120123205638.GA8542@phenom.dumpdata.com>
	<1327352449.2446.19.camel@twins>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327352449.2446.19.camel@twins>
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.4F1DCE97.0093,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	gregkh@suse.de, linux-kernel@vger.kernel.org, rjw@sisk.pl,
	tglx@linutronix.de, mingo@elte.hu
Subject: Re: [Xen-devel] v3.3-rc1, regression introduced by "sched,
 nohz: Implement sched group,
 domain aware nohz idle load balancing" when unplugging 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 Mon, Jan 23, 2012 at 10:00:49PM +0100, Peter Zijlstra wrote:
> On Mon, 2012-01-23 at 15:56 -0500, Konrad Rzeszutek Wilk wrote:
> > Not exactly sure how this patch does it, but with this git commit
> > 0b005cf54eac170a8f22540ab096a6e07bf49e7c, the Linux kernel crashes
> > if I try to hot unplug VCPUs to the first (initial) domain.
> > This is found using git bisection, and if I use the kernel compiled
> > with 69e1e811dcc436a6b129dbef273ad9ec22d095ce (the previous commit)
> > it works nicely. 
> 
> https://lkml.org/lkml/2012/1/19/463
> 
> is already on its way...

Oh, somehow I thought the mce check fixes were already in v3.3-rc1.
My apologies and will take that patch on a test-spin.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 21:19:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 21:19:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpRHl-0007Gz-5t; Mon, 23 Jan 2012 21:18:41 +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 1RpRHj-0007Ge-UV
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 21:18:40 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327353512!10360999!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4618 invoked from network); 23 Jan 2012 21:18:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-6.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 21:18:33 -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
	q0NLD8Ee014118
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 21:13:21 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
	q0NLD6un006432
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 21:13:07 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0NLD5go006467; Mon, 23 Jan 2012 15:13:05 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 13:13:05 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4746340157; Mon, 23 Jan 2012 16:10:51 -0500 (EST)
Date: Mon, 23 Jan 2012 16:10:51 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Message-ID: <20120123211051.GA10967@phenom.dumpdata.com>
References: <20120123205638.GA8542@phenom.dumpdata.com>
	<1327352449.2446.19.camel@twins>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327352449.2446.19.camel@twins>
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.4F1DCE97.0093,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	gregkh@suse.de, linux-kernel@vger.kernel.org, rjw@sisk.pl,
	tglx@linutronix.de, mingo@elte.hu
Subject: Re: [Xen-devel] v3.3-rc1, regression introduced by "sched,
 nohz: Implement sched group,
 domain aware nohz idle load balancing" when unplugging 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 Mon, Jan 23, 2012 at 10:00:49PM +0100, Peter Zijlstra wrote:
> On Mon, 2012-01-23 at 15:56 -0500, Konrad Rzeszutek Wilk wrote:
> > Not exactly sure how this patch does it, but with this git commit
> > 0b005cf54eac170a8f22540ab096a6e07bf49e7c, the Linux kernel crashes
> > if I try to hot unplug VCPUs to the first (initial) domain.
> > This is found using git bisection, and if I use the kernel compiled
> > with 69e1e811dcc436a6b129dbef273ad9ec22d095ce (the previous commit)
> > it works nicely. 
> 
> https://lkml.org/lkml/2012/1/19/463
> 
> is already on its way...

Oh, somehow I thought the mce check fixes were already in v3.3-rc1.
My apologies and will take that patch on a test-spin.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 21:24:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 21: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 1RpRNM-0007k6-VP; Mon, 23 Jan 2012 21:24:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpRNL-0007jw-IT
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 21:24:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327353812!51435846!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18664 invoked from network); 23 Jan 2012 21:23:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 21:23:33 -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
	q0NLO06m027716
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 21:24:01 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
	q0NLNwUE022408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 21:23:59 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
	q0NLNvZ2032552; Mon, 23 Jan 2012 15:23:57 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 13:23:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7E57940157; Mon, 23 Jan 2012 16:21:42 -0500 (EST)
Date: Mon, 23 Jan 2012 16:21:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Message-ID: <20120123212142.GA29288@phenom.dumpdata.com>
References: <20120123205638.GA8542@phenom.dumpdata.com>
	<1327352449.2446.19.camel@twins>
	<20120123211051.GA10967@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120123211051.GA10967@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F1DCFF2.0067,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	gregkh@suse.de, linux-kernel@vger.kernel.org, rjw@sisk.pl,
	tglx@linutronix.de, mingo@elte.hu
Subject: Re: [Xen-devel] v3.3-rc1, regression introduced by "sched,
 nohz: Implement sched group,
 domain aware nohz idle load balancing" when unplugging 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 Mon, Jan 23, 2012 at 04:10:51PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 23, 2012 at 10:00:49PM +0100, Peter Zijlstra wrote:
> > On Mon, 2012-01-23 at 15:56 -0500, Konrad Rzeszutek Wilk wrote:
> > > Not exactly sure how this patch does it, but with this git commit
> > > 0b005cf54eac170a8f22540ab096a6e07bf49e7c, the Linux kernel crashes
> > > if I try to hot unplug VCPUs to the first (initial) domain.
> > > This is found using git bisection, and if I use the kernel compiled
> > > with 69e1e811dcc436a6b129dbef273ad9ec22d095ce (the previous commit)
> > > it works nicely. 
> > 
> > https://lkml.org/lkml/2012/1/19/463
> > 
> > is already on its way...
> 
> Oh, somehow I thought the mce check fixes were already in v3.3-rc1.
> My apologies and will take that patch on a test-spin.

Tested-by: Konrad Rzeszutek Wilk <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 Mon Jan 23 21:24:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 21: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 1RpRNM-0007k6-VP; Mon, 23 Jan 2012 21:24:28 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpRNL-0007jw-IT
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 21:24:27 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327353812!51435846!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18664 invoked from network); 23 Jan 2012 21:23:33 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 21:23:33 -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
	q0NLO06m027716
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 21:24:01 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
	q0NLNwUE022408
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 21:23:59 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
	q0NLNvZ2032552; Mon, 23 Jan 2012 15:23:57 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 13:23:56 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 7E57940157; Mon, 23 Jan 2012 16:21:42 -0500 (EST)
Date: Mon, 23 Jan 2012 16:21:42 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Message-ID: <20120123212142.GA29288@phenom.dumpdata.com>
References: <20120123205638.GA8542@phenom.dumpdata.com>
	<1327352449.2446.19.camel@twins>
	<20120123211051.GA10967@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120123211051.GA10967@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090207.4F1DCFF2.0067,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, Suresh Siddha <suresh.b.siddha@intel.com>,
	gregkh@suse.de, linux-kernel@vger.kernel.org, rjw@sisk.pl,
	tglx@linutronix.de, mingo@elte.hu
Subject: Re: [Xen-devel] v3.3-rc1, regression introduced by "sched,
 nohz: Implement sched group,
 domain aware nohz idle load balancing" when unplugging 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 Mon, Jan 23, 2012 at 04:10:51PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 23, 2012 at 10:00:49PM +0100, Peter Zijlstra wrote:
> > On Mon, 2012-01-23 at 15:56 -0500, Konrad Rzeszutek Wilk wrote:
> > > Not exactly sure how this patch does it, but with this git commit
> > > 0b005cf54eac170a8f22540ab096a6e07bf49e7c, the Linux kernel crashes
> > > if I try to hot unplug VCPUs to the first (initial) domain.
> > > This is found using git bisection, and if I use the kernel compiled
> > > with 69e1e811dcc436a6b129dbef273ad9ec22d095ce (the previous commit)
> > > it works nicely. 
> > 
> > https://lkml.org/lkml/2012/1/19/463
> > 
> > is already on its way...
> 
> Oh, somehow I thought the mce check fixes were already in v3.3-rc1.
> My apologies and will take that patch on a test-spin.

Tested-by: Konrad Rzeszutek Wilk <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 Mon Jan 23 21:45:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 21: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 1RpRhT-0007wC-RW; Mon, 23 Jan 2012 21:45:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dvrabel@cantab.net>) id 1RpRhR-0007w4-Gy
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 21:45:13 +0000
X-Env-Sender: dvrabel@cantab.net
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327355107!13601195!1
X-Originating-IP: [212.23.3.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIzLjMuMTQxID0+IDc3NTQz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21632 invoked from network); 23 Jan 2012 21:45:07 -0000
Received: from smarthost02.mail.zen.net.uk (HELO smarthost02.mail.zen.net.uk)
	(212.23.3.141) by server-2.tower-216.messagelabs.com with SMTP;
	23 Jan 2012 21:45:07 -0000
Received: from [82.70.146.41] (helo=pear)
	by smarthost02.mail.zen.net.uk with esmtps
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <dvrabel@cantab.net>)
	id 1RpRhB-0003pJ-Bv; Mon, 23 Jan 2012 21:44:57 +0000
Received: from apple.davidvrabel.org.uk ([82.70.146.43])
	by pear with esmtp (Exim 4.72) (envelope-from <dvrabel@cantab.net>)
	id 1RpRgv-0000nL-NN; Mon, 23 Jan 2012 21:44:55 +0000
Message-ID: <4F1DD4C1.2070704@cantab.net>
Date: Mon, 23 Jan 2012 21:44:33 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
	<20120123195047.GA11002@phenom.dumpdata.com>
In-Reply-To: <20120123195047.GA11002@phenom.dumpdata.com>
X-SA-Exim-Connect-IP: 82.70.146.43
X-SA-Exim-Mail-From: dvrabel@cantab.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pear
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_NEUTRAL
	autolearn=no version=3.3.1
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000)
X-SA-Exim-Scanned: Yes (on pear)
X-Originating-Smarthost02-IP: [82.70.146.41]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
 always fit in arch_spinlock_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>
Content-Transfer-Encoding: 7bit
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 23/01/2012 19:50, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 23, 2012 at 07:32:25PM +0000, David Vrabel wrote:
>> From: David Vrabel<david.vrabel@citrix.com>
>>
>> If NR_CPUS<  256 then arch_spinlock_t is only 16 bits wide but struct
>> xen_spinlock is 32 bits.  When a spin lock is contended and
>> xl->spinners is modified the two bytes immediately after the spin lock
>> would be corrupted.
>>
>> This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
>> (x86, ticketlock: Clean up types and accessors) which reduced the size
>> of arch_spinlock_t.
>>
>> Fix this by making xl->spinners a u8 if NR_CPUS<  256.  A
>> BUILD_BUG_ON() is also added to check the sizes of the two structures
>> are compatible.
>>
>> In many cases this was not noticable as there would often be padding
>> bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
>> CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
>>
>> The bnx2 driver is affected. In struct bnx2, phy_lock and
>> indirect_lock may have no padding after them.  Contention on phy_lock
>> would corrupt indirect_lock making it appear locked and the driver
>> would deadlock.
>
> Nice find. I think it also affected the ahci driver, and some of the USB
> ones - at least those I saw starting to hang with:

It's possible but keep in mind that this isn't a recent regression.  I 
think it's been around since 3.0 and maybe even earlier.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 21:45:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 21: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 1RpRhT-0007wC-RW; Mon, 23 Jan 2012 21:45:15 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dvrabel@cantab.net>) id 1RpRhR-0007w4-Gy
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 21:45:13 +0000
X-Env-Sender: dvrabel@cantab.net
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327355107!13601195!1
X-Originating-IP: [212.23.3.141]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEyLjIzLjMuMTQxID0+IDc3NTQz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21632 invoked from network); 23 Jan 2012 21:45:07 -0000
Received: from smarthost02.mail.zen.net.uk (HELO smarthost02.mail.zen.net.uk)
	(212.23.3.141) by server-2.tower-216.messagelabs.com with SMTP;
	23 Jan 2012 21:45:07 -0000
Received: from [82.70.146.41] (helo=pear)
	by smarthost02.mail.zen.net.uk with esmtps
	(TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72)
	(envelope-from <dvrabel@cantab.net>)
	id 1RpRhB-0003pJ-Bv; Mon, 23 Jan 2012 21:44:57 +0000
Received: from apple.davidvrabel.org.uk ([82.70.146.43])
	by pear with esmtp (Exim 4.72) (envelope-from <dvrabel@cantab.net>)
	id 1RpRgv-0000nL-NN; Mon, 23 Jan 2012 21:44:55 +0000
Message-ID: <4F1DD4C1.2070704@cantab.net>
Date: Mon, 23 Jan 2012 21:44:33 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
	<20120123195047.GA11002@phenom.dumpdata.com>
In-Reply-To: <20120123195047.GA11002@phenom.dumpdata.com>
X-SA-Exim-Connect-IP: 82.70.146.43
X-SA-Exim-Mail-From: dvrabel@cantab.net
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pear
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_NEUTRAL
	autolearn=no version=3.3.1
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000)
X-SA-Exim-Scanned: Yes (on pear)
X-Originating-Smarthost02-IP: [82.70.146.41]
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	David Vrabel <david.vrabel@citrix.com>, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
 always fit in arch_spinlock_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>
Content-Transfer-Encoding: 7bit
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 23/01/2012 19:50, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 23, 2012 at 07:32:25PM +0000, David Vrabel wrote:
>> From: David Vrabel<david.vrabel@citrix.com>
>>
>> If NR_CPUS<  256 then arch_spinlock_t is only 16 bits wide but struct
>> xen_spinlock is 32 bits.  When a spin lock is contended and
>> xl->spinners is modified the two bytes immediately after the spin lock
>> would be corrupted.
>>
>> This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
>> (x86, ticketlock: Clean up types and accessors) which reduced the size
>> of arch_spinlock_t.
>>
>> Fix this by making xl->spinners a u8 if NR_CPUS<  256.  A
>> BUILD_BUG_ON() is also added to check the sizes of the two structures
>> are compatible.
>>
>> In many cases this was not noticable as there would often be padding
>> bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
>> CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
>>
>> The bnx2 driver is affected. In struct bnx2, phy_lock and
>> indirect_lock may have no padding after them.  Contention on phy_lock
>> would corrupt indirect_lock making it appear locked and the driver
>> would deadlock.
>
> Nice find. I think it also affected the ahci driver, and some of the USB
> ones - at least those I saw starting to hang with:

It's possible but keep in mind that this isn't a recent regression.  I 
think it's been around since 3.0 and maybe even earlier.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpS6Y-0008IH-5t; Mon, 23 Jan 2012 22:11: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 1RpS6W-0008Hi-Ga
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:11:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327356613!51438777!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5ODcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19149 invoked from network); 23 Jan 2012 22:10:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 22:10:14 -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
	q0NMACFd022086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 22:10:13 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
	q0NMAB85024711
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 22:10:11 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
	q0NMAAXH030295; Mon, 23 Jan 2012 16:10:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 14:10:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 944D040157; Mon, 23 Jan 2012 17:07:55 -0500 (EST)
Date: Mon, 23 Jan 2012 17:07:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120123220755.GA31306@phenom.dumpdata.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EBA8FAA020000780005FD5F@nat28.tlf.novell.com>
	<4EBC125A.70300@goop.org> <20120119194232.GA3728@konrad-lan>
	<4F194880020000780006DD7F@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F194880020000780006DD7F@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F1DDAC5.00C2,ss=1,re=0.000,fgs=0
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@darnok.org>, Laszlo Ersek <lersek@redhat.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 Fri, Jan 20, 2012 at 09:57:04AM +0000, Jan Beulich wrote:
> >>> On 19.01.12 at 20:42, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > I finally got some time to look at them and I think they are these ones:
> > 
> > git log --oneline 
> > e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b
> > 255a4 
> > 3c404b5 KVM guest: Add a pv_ops stub for steal time
> > c9aaa89 KVM: Steal time implementation
> > 9ddabbe KVM: KVM Steal time guest/host interface
> > 4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host 
> > interface
> > 
> > What is interesting is that they end up inserting a bunch of:
> > 
> >  
> > +       if (steal_account_process_tick())
> > +               return;
> > +
> > 
> > in irqtime_account_process_tick and in account_process_tick.
> 
> And this (particularly the "return" part of it) is what I have a hard
> time to understand: How can it be correct to not do any of the
> other accounting? After all, the function calls only
> account_steal_time(), but its certainly going to be common that
> part of the time was stolen, and part was spent executing.
> 
> Further, it's being called only from the process tick accounting
> functions, but clearly part of idle or interrupt time can also be
> stolen.

I took a stab at trying to implement this using this API and basing
it on top Laszlo patch.. But I've doubts about it too and I haven't
run any benchmarks past booting a guest.


commit b1acd2adad821fd87da6941c38f0dbaddd37dc6b
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Jan 23 14:21:20 2012 -0500

    xen/time: Use the pv_ops steal_time.
    
    In the past we were using do_stolen_account() to update the
    stolen time and this was done when by calling account_steal_ticks().
    
    The do_stolen_account() was called from xen_timer_interrupt(). The
    xen_timer_interrupt() would be called periodically (or frequently)
    depending on what the timer decided. We would piggy-back on the
    timer IRQ to update the steal time and idle time (fixed by
    'remove blocked time accounting from xen "clockchip"' patch).
    
    Instead of piggy-backing on the timer interrupt lets do it
    via the provided API pv-ops time calls - the steal_clock.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 5c4a7f8..59cdd1b 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -71,14 +71,14 @@ static u64 get64(const u64 *p)
 /*
  * Runstate accounting
  */
-static void get_runstate_snapshot(struct vcpu_runstate_info *res)
+static void get_runstate_snapshot(struct vcpu_runstate_info *res, int cpu)
 {
 	u64 state_time;
 	struct vcpu_runstate_info *state;
 
 	BUG_ON(preemptible());
 
-	state = &__get_cpu_var(xen_runstate);
+	state = &per_cpu(xen_runstate, cpu);
 
 	/*
 	 * The runstate info is always updated by the hypervisor on
@@ -110,18 +110,18 @@ void xen_setup_runstate_info(int cpu)
 		BUG();
 }
 
-static void do_stolen_accounting(void)
+static u64 xen_steal_clock(int cpu)
 {
 	struct vcpu_runstate_info state;
 	struct vcpu_runstate_info *snap;
 	s64 runnable, offline, stolen;
-	cputime_t ticks;
+	u64 ticks;
 
-	get_runstate_snapshot(&state);
+	get_runstate_snapshot(&state, cpu);
 
 	WARN_ON(state.state != RUNSTATE_running);
 
-	snap = &__get_cpu_var(xen_runstate_snapshot);
+	snap = &per_cpu(xen_runstate_snapshot, cpu);
 
 	/* work out how much time the VCPU has not been runn*ing*  */
 	runnable = state.time[RUNSTATE_runnable] - snap->time[RUNSTATE_runnable];
@@ -138,7 +138,8 @@ static void do_stolen_accounting(void)
 
 	ticks = iter_div_u64_rem(stolen, NS_PER_TICK, &stolen);
 	__this_cpu_write(xen_residual_stolen, stolen);
-	account_steal_ticks(ticks);
+
+	return ticks;
 }
 
 /* Get the TSC speed from Xen */
@@ -377,8 +378,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void *dev_id)
 		ret = IRQ_HANDLED;
 	}
 
-	do_stolen_accounting();
-
 	return ret;
 }
 
@@ -439,6 +438,7 @@ void xen_timer_resume(void)
 
 static const struct pv_time_ops xen_time_ops __initconst = {
 	.sched_clock = xen_clocksource_read,
+	.steal_clock = xen_steal_clock,
 };
 
 static void __init xen_time_init(void)
@@ -464,6 +464,9 @@ static void __init xen_time_init(void)
 	xen_setup_runstate_info(cpu);
 	xen_setup_timer(cpu);
 	xen_setup_cpu_clockevents();
+
+	jump_label_inc(&paravirt_steal_enabled);
+	jump_label_inc(&paravirt_steal_rq_enabled);
 }
 
 void __init xen_init_time_ops(void)
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpS6Y-0008IH-5t; Mon, 23 Jan 2012 22:11: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 1RpS6W-0008Hi-Ga
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:11:08 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327356613!51438777!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5ODcyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19149 invoked from network); 23 Jan 2012 22:10:14 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 22:10:14 -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
	q0NMACFd022086
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 22:10:13 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
	q0NMAB85024711
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 22:10:11 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
	q0NMAAXH030295; Mon, 23 Jan 2012 16:10:10 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 14:10:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 944D040157; Mon, 23 Jan 2012 17:07:55 -0500 (EST)
Date: Mon, 23 Jan 2012 17:07:55 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120123220755.GA31306@phenom.dumpdata.com>
References: <1318970579-6282-1-git-send-email-lersek@redhat.com>
	<4EBA8FAA020000780005FD5F@nat28.tlf.novell.com>
	<4EBC125A.70300@goop.org> <20120119194232.GA3728@konrad-lan>
	<4F194880020000780006DD7F@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F194880020000780006DD7F@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F1DDAC5.00C2,ss=1,re=0.000,fgs=0
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@darnok.org>, Laszlo Ersek <lersek@redhat.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 Fri, Jan 20, 2012 at 09:57:04AM +0000, Jan Beulich wrote:
> >>> On 19.01.12 at 20:42, Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:
> > I finally got some time to look at them and I think they are these ones:
> > 
> > git log --oneline 
> > e03b644fe68b1c6401465b02724d261538dba10f..3c404b578fab699c4708279938078d9404b
> > 255a4 
> > 3c404b5 KVM guest: Add a pv_ops stub for steal time
> > c9aaa89 KVM: Steal time implementation
> > 9ddabbe KVM: KVM Steal time guest/host interface
> > 4b6b35f KVM: Add constant to represent KVM MSRs enabled bit in guest/host 
> > interface
> > 
> > What is interesting is that they end up inserting a bunch of:
> > 
> >  
> > +       if (steal_account_process_tick())
> > +               return;
> > +
> > 
> > in irqtime_account_process_tick and in account_process_tick.
> 
> And this (particularly the "return" part of it) is what I have a hard
> time to understand: How can it be correct to not do any of the
> other accounting? After all, the function calls only
> account_steal_time(), but its certainly going to be common that
> part of the time was stolen, and part was spent executing.
> 
> Further, it's being called only from the process tick accounting
> functions, but clearly part of idle or interrupt time can also be
> stolen.

I took a stab at trying to implement this using this API and basing
it on top Laszlo patch.. But I've doubts about it too and I haven't
run any benchmarks past booting a guest.


commit b1acd2adad821fd87da6941c38f0dbaddd37dc6b
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Jan 23 14:21:20 2012 -0500

    xen/time: Use the pv_ops steal_time.
    
    In the past we were using do_stolen_account() to update the
    stolen time and this was done when by calling account_steal_ticks().
    
    The do_stolen_account() was called from xen_timer_interrupt(). The
    xen_timer_interrupt() would be called periodically (or frequently)
    depending on what the timer decided. We would piggy-back on the
    timer IRQ to update the steal time and idle time (fixed by
    'remove blocked time accounting from xen "clockchip"' patch).
    
    Instead of piggy-backing on the timer interrupt lets do it
    via the provided API pv-ops time calls - the steal_clock.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 5c4a7f8..59cdd1b 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -71,14 +71,14 @@ static u64 get64(const u64 *p)
 /*
  * Runstate accounting
  */
-static void get_runstate_snapshot(struct vcpu_runstate_info *res)
+static void get_runstate_snapshot(struct vcpu_runstate_info *res, int cpu)
 {
 	u64 state_time;
 	struct vcpu_runstate_info *state;
 
 	BUG_ON(preemptible());
 
-	state = &__get_cpu_var(xen_runstate);
+	state = &per_cpu(xen_runstate, cpu);
 
 	/*
 	 * The runstate info is always updated by the hypervisor on
@@ -110,18 +110,18 @@ void xen_setup_runstate_info(int cpu)
 		BUG();
 }
 
-static void do_stolen_accounting(void)
+static u64 xen_steal_clock(int cpu)
 {
 	struct vcpu_runstate_info state;
 	struct vcpu_runstate_info *snap;
 	s64 runnable, offline, stolen;
-	cputime_t ticks;
+	u64 ticks;
 
-	get_runstate_snapshot(&state);
+	get_runstate_snapshot(&state, cpu);
 
 	WARN_ON(state.state != RUNSTATE_running);
 
-	snap = &__get_cpu_var(xen_runstate_snapshot);
+	snap = &per_cpu(xen_runstate_snapshot, cpu);
 
 	/* work out how much time the VCPU has not been runn*ing*  */
 	runnable = state.time[RUNSTATE_runnable] - snap->time[RUNSTATE_runnable];
@@ -138,7 +138,8 @@ static void do_stolen_accounting(void)
 
 	ticks = iter_div_u64_rem(stolen, NS_PER_TICK, &stolen);
 	__this_cpu_write(xen_residual_stolen, stolen);
-	account_steal_ticks(ticks);
+
+	return ticks;
 }
 
 /* Get the TSC speed from Xen */
@@ -377,8 +378,6 @@ static irqreturn_t xen_timer_interrupt(int irq, void *dev_id)
 		ret = IRQ_HANDLED;
 	}
 
-	do_stolen_accounting();
-
 	return ret;
 }
 
@@ -439,6 +438,7 @@ void xen_timer_resume(void)
 
 static const struct pv_time_ops xen_time_ops __initconst = {
 	.sched_clock = xen_clocksource_read,
+	.steal_clock = xen_steal_clock,
 };
 
 static void __init xen_time_init(void)
@@ -464,6 +464,9 @@ static void __init xen_time_init(void)
 	xen_setup_runstate_info(cpu);
 	xen_setup_timer(cpu);
 	xen_setup_cpu_clockevents();
+
+	jump_label_inc(&paravirt_steal_enabled);
+	jump_label_inc(&paravirt_steal_rq_enabled);
 }
 
 void __init xen_init_time_ops(void)
> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:36:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22:36:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpSU7-0000jk-HQ; Mon, 23 Jan 2012 22:35:31 +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 1RpSU5-0000jX-Qs
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:35:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327358121!12092041!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30312 invoked from network); 23 Jan 2012 22:35:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 22:35:23 -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
	q0NMYU4e018183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 22:34:31 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
	q0NMYSnr001670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 22:34:29 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
	q0NMYRHv026600; Mon, 23 Jan 2012 16:34:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 14:34:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9B95E40157; Mon, 23 Jan 2012 17:32:13 -0500 (EST)
Date: Mon, 23 Jan 2012 17:32:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120123223213.GA31929@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<4F16BC97020000780006D6D6@nat28.tlf.novell.com>
	<20120118142923.GA6052@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <20120118142923.GA6052@andromeda.dapyr.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.0A090204.4F1DE078.000D,ss=1,re=0.000,fgs=0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.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


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > The issue as I understand is that the DVB drivers allocate their buffers
> > > from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> > > 
> > > While the pv-ops one ends up quite frequently doing the bounce-buffering, 
> > > which
> > > implies that the DVB drivers end up allocating their buffers above the 4GB.
> > > This means we end up spending some CPU time (in the guest) copying the 
> > > memory
> > > from >4GB to 0-4GB region (And vice-versa).
> > 
> > This reminds me of something (not sure what XenoLinux you use for
> > comparison) - how are they allocating that memory? Not vmalloc_32()
> 
> I was using the 2.6.18, then the one I saw on Google for Gentoo, and now
> I am going to look at the 2.6.38 from OpenSuSE.
> 
> > by chance (I remember having seen numerous uses under - iirc -
> > drivers/media/)?
> > 
> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
> > what their (driver) callers might expect in a PV guest (including the
> > contiguity assumption for the latter, recalling that you earlier said
> > you were able to see the problem after several guest starts), and I
> > had put into our kernels an adjustment to make vmalloc_32() actually
> > behave as expected.
> 
> Aaah.. The plot thickens! Let me look in the sources! Thanks for the
> pointer.

Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32
and then performs PCI DMA operations on the allocted vmalloc_32
area.

So I cobbled up the attached patch (hadn't actually tested it and sadly
won't until next week) which removes the call to vmalloc_32 and instead
sets up DMA allocated set of pages.

If that fixes it for you that is awesome, but if it breaks please
send me your logs.

Cheers,
Konrad

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=vmalloc

commit 0b5428f4a22be4855b5f03aa1369f9e30e095014
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Jan 23 15:52:01 2012 -0500

    vmalloc_sg: make sure all pages in vmalloc area are really DMA-ready
    
    Under Xen, vmalloc_32() isn't guaranteed to return pages which are really
    under 4G in machine physical addresses (only in virtual pseudo-physical
    addresses).  To work around this, implement a vmalloc variant which
    allocates each page with dma_alloc_coherent() to guarantee that each
    page is suitable for the device in question.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/media/video/videobuf-dma-sg.c b/drivers/media/video/videobuf-dma-sg.c
index f300dea..3da2428 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -211,13 +211,36 @@ EXPORT_SYMBOL_GPL(videobuf_dma_init_user);
 int videobuf_dma_init_kernel(struct videobuf_dmabuf *dma, int direction,
 			     int nr_pages)
 {
+	int i;
+
 	dprintk(1, "init kernel [%d pages]\n", nr_pages);
 
 	dma->direction = direction;
-	dma->vaddr = vmalloc_32(nr_pages << PAGE_SHIFT);
+	dma->vaddr_pages = kcalloc(nr_pages, sizeof(*dma->vaddr_pages),
+				   GFP_KERNEL);
+	if (!dma->vaddr_pages)
+		return -ENOMEM;
+
+	dma->dma_addr = kcalloc(nr_pages, sizeof(*dma->dma_addr), GFP_KERNEL);
+	if (!dma->dma_addr) {
+		kfree(dma->vaddr_pages);
+		return -ENOMEM;
+	}
+	for (i = 0; i < nr_pages; i++) {
+		void *addr;
+
+		addr = dma_alloc_coherent(dma->dev, PAGE_SIZE,
+					  &(dma->dma_addr[i]), GFP_KERNEL);
+		if (addr == NULL)
+			goto out_free_pages;
+
+		dma->vaddr_pages[i] = virt_to_page(addr);
+	}
+	dma->vaddr = vmap(dma->vaddr_pages, nr_pages, VM_MAP | VM_IOREMAP,
+			  PAGE_KERNEL);
 	if (NULL == dma->vaddr) {
 		dprintk(1, "vmalloc_32(%d pages) failed\n", nr_pages);
-		return -ENOMEM;
+		goto out_free_pages;
 	}
 
 	dprintk(1, "vmalloc is at addr 0x%08lx, size=%d\n",
@@ -228,6 +251,18 @@ int videobuf_dma_init_kernel(struct videobuf_dmabuf *dma, int direction,
 	dma->nr_pages = nr_pages;
 
 	return 0;
+out_free_pages:
+	while (i > 0) {
+		void *addr = page_address(dma->vaddr_pages[i]);
+		dma_free_coherent(dma->dev, PAGE_SIZE, addr, dma->dma_addr[i]);
+		i--;
+	}
+	kfree(dma->dma_addr);
+	dma->dma_addr = NULL;
+	kfree(dma->vaddr_pages);
+	dma->vaddr_pages = NULL;
+
+	return -ENOMEM;
 }
 EXPORT_SYMBOL_GPL(videobuf_dma_init_kernel);
 
@@ -322,8 +357,21 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
 		dma->pages = NULL;
 	}
 
-	vfree(dma->vaddr);
-	dma->vaddr = NULL;
+	if (dma->dma_addr) {
+		for (i = 0; i < dma->nr_pages; i++) {
+			void *addr;
+
+			addr = page_address(dma->vaddr_pages[i]);
+			dma_free_coherent(dma->dev, PAGE_SIZE, addr,
+					  dma->dma_addr[i]);
+		}
+		kfree(dma->dma_addr);
+		dma->dma_addr = NULL;
+		kfree(dma->vaddr_pages);
+		dma->vaddr_pages = NULL;
+		vunmap(dma->vaddr);
+		dma->vaddr = NULL;
+	}
 
 	if (dma->bus_addr)
 		dma->bus_addr = 0;
@@ -461,6 +509,11 @@ static int __videobuf_iolock(struct videobuf_queue *q,
 
 	MAGIC_CHECK(mem->magic, MAGIC_SG_MEM);
 
+	if (!mem->dma.dev)
+		mem->dma.dev = q->dev;
+	else
+		WARN_ON(mem->dma.dev != q->dev);
+
 	switch (vb->memory) {
 	case V4L2_MEMORY_MMAP:
 	case V4L2_MEMORY_USERPTR:
diff --git a/include/media/videobuf-dma-sg.h b/include/media/videobuf-dma-sg.h
index d8fb601..870cb21 100644
--- a/include/media/videobuf-dma-sg.h
+++ b/include/media/videobuf-dma-sg.h
@@ -53,6 +53,9 @@ struct videobuf_dmabuf {
 
 	/* for kernel buffers */
 	void                *vaddr;
+	struct page	    **vaddr_pages;
+	dma_addr_t	    *dma_addr;
+	struct device	    *dev;
 
 	/* for overlay buffers (pci-pci dma) */
 	dma_addr_t          bus_addr;

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--a8Wt8u1KmwUX3Y2C--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:36:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22:36:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpSU7-0000jk-HQ; Mon, 23 Jan 2012 22:35:31 +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 1RpSU5-0000jX-Qs
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:35:30 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327358121!12092041!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5Njk0MQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30312 invoked from network); 23 Jan 2012 22:35:23 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-2.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 22:35:23 -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
	q0NMYU4e018183
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 23 Jan 2012 22:34:31 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
	q0NMYSnr001670
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 23 Jan 2012 22:34:29 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
	q0NMYRHv026600; Mon, 23 Jan 2012 16:34:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 14:34:27 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9B95E40157; Mon, 23 Jan 2012 17:32:13 -0500 (EST)
Date: Mon, 23 Jan 2012 17:32:13 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120123223213.GA31929@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<4F16BC97020000780006D6D6@nat28.tlf.novell.com>
	<20120118142923.GA6052@andromeda.dapyr.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="a8Wt8u1KmwUX3Y2C"
Content-Disposition: inline
In-Reply-To: <20120118142923.GA6052@andromeda.dapyr.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.0A090204.4F1DE078.000D,ss=1,re=0.000,fgs=0
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.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


--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > > The issue as I understand is that the DVB drivers allocate their buffers
> > > from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> > > 
> > > While the pv-ops one ends up quite frequently doing the bounce-buffering, 
> > > which
> > > implies that the DVB drivers end up allocating their buffers above the 4GB.
> > > This means we end up spending some CPU time (in the guest) copying the 
> > > memory
> > > from >4GB to 0-4GB region (And vice-versa).
> > 
> > This reminds me of something (not sure what XenoLinux you use for
> > comparison) - how are they allocating that memory? Not vmalloc_32()
> 
> I was using the 2.6.18, then the one I saw on Google for Gentoo, and now
> I am going to look at the 2.6.38 from OpenSuSE.
> 
> > by chance (I remember having seen numerous uses under - iirc -
> > drivers/media/)?
> > 
> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
> > what their (driver) callers might expect in a PV guest (including the
> > contiguity assumption for the latter, recalling that you earlier said
> > you were able to see the problem after several guest starts), and I
> > had put into our kernels an adjustment to make vmalloc_32() actually
> > behave as expected.
> 
> Aaah.. The plot thickens! Let me look in the sources! Thanks for the
> pointer.

Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32
and then performs PCI DMA operations on the allocted vmalloc_32
area.

So I cobbled up the attached patch (hadn't actually tested it and sadly
won't until next week) which removes the call to vmalloc_32 and instead
sets up DMA allocated set of pages.

If that fixes it for you that is awesome, but if it breaks please
send me your logs.

Cheers,
Konrad

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=vmalloc

commit 0b5428f4a22be4855b5f03aa1369f9e30e095014
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Mon Jan 23 15:52:01 2012 -0500

    vmalloc_sg: make sure all pages in vmalloc area are really DMA-ready
    
    Under Xen, vmalloc_32() isn't guaranteed to return pages which are really
    under 4G in machine physical addresses (only in virtual pseudo-physical
    addresses).  To work around this, implement a vmalloc variant which
    allocates each page with dma_alloc_coherent() to guarantee that each
    page is suitable for the device in question.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/drivers/media/video/videobuf-dma-sg.c b/drivers/media/video/videobuf-dma-sg.c
index f300dea..3da2428 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -211,13 +211,36 @@ EXPORT_SYMBOL_GPL(videobuf_dma_init_user);
 int videobuf_dma_init_kernel(struct videobuf_dmabuf *dma, int direction,
 			     int nr_pages)
 {
+	int i;
+
 	dprintk(1, "init kernel [%d pages]\n", nr_pages);
 
 	dma->direction = direction;
-	dma->vaddr = vmalloc_32(nr_pages << PAGE_SHIFT);
+	dma->vaddr_pages = kcalloc(nr_pages, sizeof(*dma->vaddr_pages),
+				   GFP_KERNEL);
+	if (!dma->vaddr_pages)
+		return -ENOMEM;
+
+	dma->dma_addr = kcalloc(nr_pages, sizeof(*dma->dma_addr), GFP_KERNEL);
+	if (!dma->dma_addr) {
+		kfree(dma->vaddr_pages);
+		return -ENOMEM;
+	}
+	for (i = 0; i < nr_pages; i++) {
+		void *addr;
+
+		addr = dma_alloc_coherent(dma->dev, PAGE_SIZE,
+					  &(dma->dma_addr[i]), GFP_KERNEL);
+		if (addr == NULL)
+			goto out_free_pages;
+
+		dma->vaddr_pages[i] = virt_to_page(addr);
+	}
+	dma->vaddr = vmap(dma->vaddr_pages, nr_pages, VM_MAP | VM_IOREMAP,
+			  PAGE_KERNEL);
 	if (NULL == dma->vaddr) {
 		dprintk(1, "vmalloc_32(%d pages) failed\n", nr_pages);
-		return -ENOMEM;
+		goto out_free_pages;
 	}
 
 	dprintk(1, "vmalloc is at addr 0x%08lx, size=%d\n",
@@ -228,6 +251,18 @@ int videobuf_dma_init_kernel(struct videobuf_dmabuf *dma, int direction,
 	dma->nr_pages = nr_pages;
 
 	return 0;
+out_free_pages:
+	while (i > 0) {
+		void *addr = page_address(dma->vaddr_pages[i]);
+		dma_free_coherent(dma->dev, PAGE_SIZE, addr, dma->dma_addr[i]);
+		i--;
+	}
+	kfree(dma->dma_addr);
+	dma->dma_addr = NULL;
+	kfree(dma->vaddr_pages);
+	dma->vaddr_pages = NULL;
+
+	return -ENOMEM;
 }
 EXPORT_SYMBOL_GPL(videobuf_dma_init_kernel);
 
@@ -322,8 +357,21 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma)
 		dma->pages = NULL;
 	}
 
-	vfree(dma->vaddr);
-	dma->vaddr = NULL;
+	if (dma->dma_addr) {
+		for (i = 0; i < dma->nr_pages; i++) {
+			void *addr;
+
+			addr = page_address(dma->vaddr_pages[i]);
+			dma_free_coherent(dma->dev, PAGE_SIZE, addr,
+					  dma->dma_addr[i]);
+		}
+		kfree(dma->dma_addr);
+		dma->dma_addr = NULL;
+		kfree(dma->vaddr_pages);
+		dma->vaddr_pages = NULL;
+		vunmap(dma->vaddr);
+		dma->vaddr = NULL;
+	}
 
 	if (dma->bus_addr)
 		dma->bus_addr = 0;
@@ -461,6 +509,11 @@ static int __videobuf_iolock(struct videobuf_queue *q,
 
 	MAGIC_CHECK(mem->magic, MAGIC_SG_MEM);
 
+	if (!mem->dma.dev)
+		mem->dma.dev = q->dev;
+	else
+		WARN_ON(mem->dma.dev != q->dev);
+
 	switch (vb->memory) {
 	case V4L2_MEMORY_MMAP:
 	case V4L2_MEMORY_USERPTR:
diff --git a/include/media/videobuf-dma-sg.h b/include/media/videobuf-dma-sg.h
index d8fb601..870cb21 100644
--- a/include/media/videobuf-dma-sg.h
+++ b/include/media/videobuf-dma-sg.h
@@ -53,6 +53,9 @@ struct videobuf_dmabuf {
 
 	/* for kernel buffers */
 	void                *vaddr;
+	struct page	    **vaddr_pages;
+	dma_addr_t	    *dma_addr;
+	struct device	    *dev;
 
 	/* for overlay buffers (pci-pci dma) */
 	dma_addr_t          bus_addr;

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--a8Wt8u1KmwUX3Y2C--


From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:49:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22: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 1RpShJ-0001EJ-Vj; Mon, 23 Jan 2012 22:49:09 +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 1RpShI-0001DR-9C
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:49:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327358939!9913185!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12804 invoked from network); 23 Jan 2012 22:49:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 22:49:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0NMmrCC017843; Mon, 23 Jan 2012 14:48:53 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0NMmrlG017840;
	Mon, 23 Jan 2012 14:48:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 11fb1dfda7de4d6759dec87d80cd16cf137f7369
Message-Id: <11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 23 Jan 2012 14:46:26 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model
	suspend/resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327358638 28800
# Node ID 11fb1dfda7de4d6759dec87d80cd16cf137f7369
# Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
tools/libxl: QEMU device model suspend/resume

 * Refactor the libxl__domain_save_device_model.
 * Add support for suspend/resume QEMU device model
   (both traditional xen and QMP).


Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jan 21 17:15:40 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:43:58 2012 -0800
@@ -477,7 +477,7 @@
 
     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);
+        rc = libxl__domain_save_device_model(gc, domid, fd, /* No Remus */ 0);
     GC_FREE;
     return rc;
 }
diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Sat Jan 21 17:15:40 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 14:43:58 2012 -0800
@@ -534,6 +534,53 @@
     return 0;
 }
 
+static int libxl__remus_domain_suspend_qemu(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        char *path = NULL;
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                              domid);
+        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        /* Stop QEMU */
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
+static int libxl__remus_domain_resume_qemu(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        char *path = NULL;
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                              domid);
+        libxl__xs_write(gc, XBT_NULL, path, "continue");
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        /* Stop QEMU */
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -620,7 +667,7 @@
     return rc;
 }
 
-int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
+int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd, int remus)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret, fd2 = -1, c;
@@ -631,13 +678,12 @@
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        char *path = NULL;
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                              domid);
-        libxl__xs_write(gc, XBT_NULL, path, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        /* For Remus,we issue suspend_qemu call separately */
+        if (!remus) {
+            c = libxl__remus_domain_suspend_qemu(gc, domid);
+            if (c)
+                return c;
+        }
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
@@ -668,8 +714,9 @@
     qemu_state_len = st.st_size;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                              "saved-state file", "qemu signature");
+    ret = libxl_write_exactly(ctx, fd, remus ? REMUS_QEMU_SIGNATURE : QEMU_SIGNATURE,
+                            remus ? strlen(REMUS_QEMU_SIGNATURE): strlen(QEMU_SIGNATURE),
+                            "saved-state file", "qemu signature");
     if (ret)
         goto out;
 
diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Sat Jan 21 17:15:40 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 14:43:58 2012 -0800
@@ -73,6 +73,7 @@
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
+#define REMUS_QEMU_SIGNATURE "RemusDeviceModelState"
 #define STUBDOM_CONSOLE_LOGGING 0
 #define STUBDOM_CONSOLE_SAVE 1
 #define STUBDOM_CONSOLE_RESTORE 2
@@ -273,7 +274,8 @@
                                          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 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd,
+                                            int remus);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
@@ -616,6 +618,10 @@
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
 /* close and free the QMP handler */
diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Sat Jan 21 17:15:40 2012 +0000
+++ b/tools/libxl/libxl_qmp.c	Mon Jan 23 14:43:58 2012 -0800
@@ -878,6 +878,38 @@
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:49:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22: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 1RpShJ-0001EJ-Vj; Mon, 23 Jan 2012 22:49:09 +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 1RpShI-0001DR-9C
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:49:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327358939!9913185!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12804 invoked from network); 23 Jan 2012 22:49:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 22:49:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0NMmrCC017843; Mon, 23 Jan 2012 14:48:53 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0NMmrlG017840;
	Mon, 23 Jan 2012 14:48:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 11fb1dfda7de4d6759dec87d80cd16cf137f7369
Message-Id: <11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 23 Jan 2012 14:46:26 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model
	suspend/resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327358638 28800
# Node ID 11fb1dfda7de4d6759dec87d80cd16cf137f7369
# Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
tools/libxl: QEMU device model suspend/resume

 * Refactor the libxl__domain_save_device_model.
 * Add support for suspend/resume QEMU device model
   (both traditional xen and QMP).


Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jan 21 17:15:40 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:43:58 2012 -0800
@@ -477,7 +477,7 @@
 
     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);
+        rc = libxl__domain_save_device_model(gc, domid, fd, /* No Remus */ 0);
     GC_FREE;
     return rc;
 }
diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Sat Jan 21 17:15:40 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 14:43:58 2012 -0800
@@ -534,6 +534,53 @@
     return 0;
 }
 
+static int libxl__remus_domain_suspend_qemu(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        char *path = NULL;
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                              domid);
+        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        /* Stop QEMU */
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
+static int libxl__remus_domain_resume_qemu(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        char *path = NULL;
+        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                              domid);
+        libxl__xs_write(gc, XBT_NULL, path, "continue");
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        /* Stop QEMU */
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -620,7 +667,7 @@
     return rc;
 }
 
-int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
+int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd, int remus)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int ret, fd2 = -1, c;
@@ -631,13 +678,12 @@
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        char *path = NULL;
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                              domid);
-        libxl__xs_write(gc, XBT_NULL, path, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        /* For Remus,we issue suspend_qemu call separately */
+        if (!remus) {
+            c = libxl__remus_domain_suspend_qemu(gc, domid);
+            if (c)
+                return c;
+        }
         break;
     }
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
@@ -668,8 +714,9 @@
     qemu_state_len = st.st_size;
     LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
 
-    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
-                              "saved-state file", "qemu signature");
+    ret = libxl_write_exactly(ctx, fd, remus ? REMUS_QEMU_SIGNATURE : QEMU_SIGNATURE,
+                            remus ? strlen(REMUS_QEMU_SIGNATURE): strlen(QEMU_SIGNATURE),
+                            "saved-state file", "qemu signature");
     if (ret)
         goto out;
 
diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Sat Jan 21 17:15:40 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 14:43:58 2012 -0800
@@ -73,6 +73,7 @@
 #define LIBXL_HVM_EXTRA_MEMORY 2048
 #define LIBXL_MIN_DOM0_MEM (128*1024)
 #define QEMU_SIGNATURE "DeviceModelRecord0002"
+#define REMUS_QEMU_SIGNATURE "RemusDeviceModelState"
 #define STUBDOM_CONSOLE_LOGGING 0
 #define STUBDOM_CONSOLE_SAVE 1
 #define STUBDOM_CONSOLE_RESTORE 2
@@ -273,7 +274,8 @@
                                          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 int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd,
+                                            int remus);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
 _hidden int libxl__domain_pvcontrol_available(libxl__gc *gc, uint32_t domid);
@@ -616,6 +618,10 @@
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
 /* close and free the QMP handler */
diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Sat Jan 21 17:15:40 2012 +0000
+++ b/tools/libxl/libxl_qmp.c	Mon Jan 23 14:43:58 2012 -0800
@@ -878,6 +878,38 @@
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:49:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22: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 1RpShD-0001DW-Rk; Mon, 23 Jan 2012 22:49:03 +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 1RpShC-0001DN-Ej
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:49:02 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327358809!49762250!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5442 invoked from network); 23 Jan 2012 22:46:50 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 22:46:50 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0NMmrCs017857; Mon, 23 Jan 2012 14:48:53 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0NMmrKY017854;
	Mon, 23 Jan 2012 14:48:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 822536df4aeced5aee00f1f26299086faa622681
Message-Id: <822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 23 Jan 2012 14:46:28 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] tools/libxl: xl remus/remus-receive
	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

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327358642 28800
# Node ID 822536df4aeced5aee00f1f26299086faa622681
# Parent  0446591bee86eb4e767d75b70c885549c7a3cfef
tools/libxl: xl remus/remus-receive commands

 * xl remus (and its receive counterpart remus-receive) act as frontends
   to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication are
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * xl remus borrows some aspects of xl migrate. Replication is currently
   done over a ssh connection. Future versions will use a low-overhead
   plain tcp socket for replication (similar to xend/remus).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 0446591bee86 -r 822536df4aec tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:44:02 2012 -0800
@@ -466,6 +466,40 @@
     return ptr;
 }
 
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = -1;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
diff -r 0446591bee86 -r 822536df4aec tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/libxl.h	Mon Jan 23 14:44:02 2012 -0800
@@ -272,6 +272,8 @@
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/xl.h	Mon Jan 23 14:44:02 2012 -0800
@@ -93,6 +93,8 @@
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus_receive(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:44:02 2012 -0800
@@ -1814,7 +1814,7 @@
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
      */
-    if ( !need_daemon )
+    if ( daemonize && !need_daemon )
         exit(ret);
 
     return ret;
@@ -5853,6 +5853,175 @@
     return ret;
 }
 
+int main_remus_receive(int argc, char **argv)
+{
+    int rc;
+    char *migration_domname;
+    struct domain_create dom_info;
+
+    signal(SIGPIPE, SIG_IGN);
+    memset(&dom_info, 0, sizeof(dom_info));
+    dom_info.debug = 1;
+    dom_info.no_incr_generationid = 1;
+    dom_info.restore_file = "incoming checkpoint stream";
+    dom_info.migrate_fd = 0; /* stdin - will change in future*/
+    dom_info.migration_domname_r = &migration_domname;
+
+    rc = create_domain(&dom_info);
+    if (rc < 0) {
+        fprintf(stderr, "migration target (Remus): Domain creation failed"
+                " (code %d) domid %u.\n", rc, domid);
+        exit(-rc);
+    }
+
+    /* If we are here, it means that the sender (primary) has crashed.
+     * If domain renaming fails, lets just continue (as we need the domain
+     * to be up & dom names may not matter much, as long as its reachable
+     * over network).
+     *
+     * If domain unpausing fails, destroy domain ? Or is it better to have
+     * a consistent copy of the domain (memory, cpu state, disk)
+     * on atleast one physical host ? Right now, lets just leave the domain
+     * as is and let the Administrator decide (or troubleshoot).
+     */
+    fprintf(stderr, "migration target: Remus Failover for domain %u\n", domid);
+    if (migration_domname) {
+        rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                 common_domname);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to rename domain from %s to %s:%d\n",
+                    migration_domname, common_domname, rc);
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+    }
+
+    return -rc;
+}
+
+int main_remus(int argc, char **argv)
+{
+    int opt, rc;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+
+    int sendpipe[2], recvpipe[2];
+    int send_fd = -1, recv_fd = -1;
+    pid_t child = -1;
+
+    uint8_t *config_data;
+    int config_len;
+
+    libxl_domain_remus_info r_info;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        }
+    }
+
+    domain = argv[optind];
+    host = argv[optind + 1];
+
+    if (r_info.blackhole) {
+        find_domain(domain);
+        send_fd = open("/dev/null", O_RDWR, 0644);
+        if (send_fd < 0) {
+            perror("failed to open /dev/null");
+            exit(-1);
+        }
+    } else {
+
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl remus-receive",
+                         ssh_command, host) < 0)
+                return 1;
+        }
+
+        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+
+        if (!config_len) {
+            fprintf(stderr, "No config file stored for running domain and "
+                    "none supplied - cannot start remus.\n");
+            exit(1);
+        }
+
+        MUST( libxl_pipe(ctx, sendpipe) );
+        MUST( libxl_pipe(ctx, recvpipe) );
+
+        child = libxl_fork(ctx);
+        if (child==-1) exit(1);
+
+        /* TODO: change this to plain TCP socket based channel
+         * instead of SSH.
+         */
+        if (!child) {
+            dup2(sendpipe[0], 0);
+            dup2(recvpipe[1], 1);
+            close(sendpipe[0]); close(sendpipe[1]);
+            close(recvpipe[0]); close(recvpipe[1]);
+            execlp("sh","sh","-c",rune,(char*)0);
+            perror("failed to exec sh");
+            exit(-1);
+        }
+
+        close(sendpipe[0]);
+        close(recvpipe[1]);
+        send_fd = sendpipe[1];
+        recv_fd = recvpipe[0];
+
+        signal(SIGPIPE, SIG_IGN);
+
+        save_domain_core_writeconfig(send_fd, "migration stream",
+                                     config_data, config_len);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Mon Jan 23 14:44:02 2012 -0800
@@ -407,6 +407,22 @@
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus-receive",
+      &main_remus_receive, 0,
+      "Remus Checkpoint Receiver",
+      "- for internal use only",
+    },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<DestinationHost>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl remus-receive\n"
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:49:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22: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 1RpShD-0001DW-Rk; Mon, 23 Jan 2012 22:49:03 +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 1RpShC-0001DN-Ej
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:49:02 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327358809!49762250!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5442 invoked from network); 23 Jan 2012 22:46:50 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 23 Jan 2012 22:46:50 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0NMmrCs017857; Mon, 23 Jan 2012 14:48:53 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0NMmrKY017854;
	Mon, 23 Jan 2012 14:48:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 822536df4aeced5aee00f1f26299086faa622681
Message-Id: <822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 23 Jan 2012 14:46:28 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 3] tools/libxl: xl remus/remus-receive
	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

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327358642 28800
# Node ID 822536df4aeced5aee00f1f26299086faa622681
# Parent  0446591bee86eb4e767d75b70c885549c7a3cfef
tools/libxl: xl remus/remus-receive commands

 * xl remus (and its receive counterpart remus-receive) act as frontends
   to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication are
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * xl remus borrows some aspects of xl migrate. Replication is currently
   done over a ssh connection. Future versions will use a low-overhead
   plain tcp socket for replication (similar to xend/remus).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 0446591bee86 -r 822536df4aec tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:44:02 2012 -0800
@@ -466,6 +466,40 @@
     return ptr;
 }
 
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = -1;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
diff -r 0446591bee86 -r 822536df4aec tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/libxl.h	Mon Jan 23 14:44:02 2012 -0800
@@ -272,6 +272,8 @@
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/xl.h	Mon Jan 23 14:44:02 2012 -0800
@@ -93,6 +93,8 @@
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus_receive(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:44:02 2012 -0800
@@ -1814,7 +1814,7 @@
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
      */
-    if ( !need_daemon )
+    if ( daemonize && !need_daemon )
         exit(ret);
 
     return ret;
@@ -5853,6 +5853,175 @@
     return ret;
 }
 
+int main_remus_receive(int argc, char **argv)
+{
+    int rc;
+    char *migration_domname;
+    struct domain_create dom_info;
+
+    signal(SIGPIPE, SIG_IGN);
+    memset(&dom_info, 0, sizeof(dom_info));
+    dom_info.debug = 1;
+    dom_info.no_incr_generationid = 1;
+    dom_info.restore_file = "incoming checkpoint stream";
+    dom_info.migrate_fd = 0; /* stdin - will change in future*/
+    dom_info.migration_domname_r = &migration_domname;
+
+    rc = create_domain(&dom_info);
+    if (rc < 0) {
+        fprintf(stderr, "migration target (Remus): Domain creation failed"
+                " (code %d) domid %u.\n", rc, domid);
+        exit(-rc);
+    }
+
+    /* If we are here, it means that the sender (primary) has crashed.
+     * If domain renaming fails, lets just continue (as we need the domain
+     * to be up & dom names may not matter much, as long as its reachable
+     * over network).
+     *
+     * If domain unpausing fails, destroy domain ? Or is it better to have
+     * a consistent copy of the domain (memory, cpu state, disk)
+     * on atleast one physical host ? Right now, lets just leave the domain
+     * as is and let the Administrator decide (or troubleshoot).
+     */
+    fprintf(stderr, "migration target: Remus Failover for domain %u\n", domid);
+    if (migration_domname) {
+        rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                 common_domname);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to rename domain from %s to %s:%d\n",
+                    migration_domname, common_domname, rc);
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+    }
+
+    return -rc;
+}
+
+int main_remus(int argc, char **argv)
+{
+    int opt, rc;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+
+    int sendpipe[2], recvpipe[2];
+    int send_fd = -1, recv_fd = -1;
+    pid_t child = -1;
+
+    uint8_t *config_data;
+    int config_len;
+
+    libxl_domain_remus_info r_info;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        }
+    }
+
+    domain = argv[optind];
+    host = argv[optind + 1];
+
+    if (r_info.blackhole) {
+        find_domain(domain);
+        send_fd = open("/dev/null", O_RDWR, 0644);
+        if (send_fd < 0) {
+            perror("failed to open /dev/null");
+            exit(-1);
+        }
+    } else {
+
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl remus-receive",
+                         ssh_command, host) < 0)
+                return 1;
+        }
+
+        save_domain_core_begin(domain, NULL, &config_data, &config_len);
+
+        if (!config_len) {
+            fprintf(stderr, "No config file stored for running domain and "
+                    "none supplied - cannot start remus.\n");
+            exit(1);
+        }
+
+        MUST( libxl_pipe(ctx, sendpipe) );
+        MUST( libxl_pipe(ctx, recvpipe) );
+
+        child = libxl_fork(ctx);
+        if (child==-1) exit(1);
+
+        /* TODO: change this to plain TCP socket based channel
+         * instead of SSH.
+         */
+        if (!child) {
+            dup2(sendpipe[0], 0);
+            dup2(recvpipe[1], 1);
+            close(sendpipe[0]); close(sendpipe[1]);
+            close(recvpipe[0]); close(recvpipe[1]);
+            execlp("sh","sh","-c",rune,(char*)0);
+            perror("failed to exec sh");
+            exit(-1);
+        }
+
+        close(sendpipe[0]);
+        close(recvpipe[1]);
+        send_fd = sendpipe[1];
+        recv_fd = recvpipe[0];
+
+        signal(SIGPIPE, SIG_IGN);
+
+        save_domain_core_writeconfig(send_fd, "migration stream",
+                                     config_data, config_len);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Jan 23 14:44:00 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Mon Jan 23 14:44:02 2012 -0800
@@ -407,6 +407,22 @@
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus-receive",
+      &main_remus_receive, 0,
+      "Remus Checkpoint Receiver",
+      "- for internal use only",
+    },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<DestinationHost>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl remus-receive\n"
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:49:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22: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 1RpShJ-0001EA-JR; Mon, 23 Jan 2012 22:49:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RpShH-0001DO-Qf
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:49:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327358939!11654578!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29071 invoked from network); 23 Jan 2012 22:49:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 22:49:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0NMmqvc017836; Mon, 23 Jan 2012 14:48:52 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0NMmqdf017833;
	Mon, 23 Jan 2012 14:48:52 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 23 Jan 2012 14:46:25 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] Remus - libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series introduces a basic support framework to
incorporate Remus into the libxl toolstack. The only functionality
currently implemented is memory checkpointing.

Shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:49:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22: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 1RpShJ-0001EA-JR; Mon, 23 Jan 2012 22:49:09 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RpShH-0001DO-Qf
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:49:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327358939!11654578!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29071 invoked from network); 23 Jan 2012 22:49:01 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 22:49:01 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0NMmqvc017836; Mon, 23 Jan 2012 14:48:52 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0NMmqdf017833;
	Mon, 23 Jan 2012 14:48:52 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 23 Jan 2012 14:46:25 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 3] Remus - libxl support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series introduces a basic support framework to
incorporate Remus into the libxl toolstack. The only functionality
currently implemented is memory checkpointing.

Shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:49:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22: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 1RpShJ-0001E3-81; Mon, 23 Jan 2012 22:49:09 +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 1RpShH-0001DM-Dv
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:49:07 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327358938!12063694!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11930 invoked from network); 23 Jan 2012 22:49:00 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 22:49:00 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0NMmrEk017850; Mon, 23 Jan 2012 14:48:53 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0NMmrQk017847;
	Mon, 23 Jan 2012 14:48:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0446591bee86eb4e767d75b70c885549c7a3cfef
Message-Id: <0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 23 Jan 2012 14:46:27 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] tools/libxl: suspend/postflush/commit
	callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327358640 28800
# Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef
# Parent  11fb1dfda7de4d6759dec87d80cd16cf137f7369
tools/libxl: suspend/postflush/commit callbacks

 * Add libxl callbacks for Remus checkpoint suspend, postflush (aka resume)
   and checkpoint commit callbacks.
 * suspend callback just bounces off libxl__domain_suspend_common_callback
 * resume callback directly calls xc_domain_resume instead of re-using
   libxl_domain_resume (as the latter does not set the fast suspend argument
   to xc_domain_resume - aka suspend_cancel support).
 * commit callback just sleeps for the checkpoint interval (for the moment).

 * Future patches will augument these callbacks with more functionalities like
   issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 14:43:58 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:44:00 2012 -0800
@@ -475,7 +475,9 @@
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd, /* No Remus */ 0);
     GC_FREE;
diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 14:43:58 2012 -0800
+++ b/tools/libxl/libxl.h	Mon Jan 23 14:44:00 2012 -0800
@@ -212,6 +212,12 @@
     int (*suspend_callback)(void *, int);
 } libxl_domain_suspend_info;
 
+typedef struct {
+    int interval;
+    int blackhole;
+    int compression;
+} libxl_domain_remus_info;
+
 enum {
     ERROR_NONSPECIFIC = -1,
     ERROR_VERSION = -2,
diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 23 14:43:58 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 14:44:00 2012 -0800
@@ -395,6 +395,8 @@
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* remus checkpoint interval */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -581,9 +583,69 @@
     return 0;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    if (libxl__domain_suspend_common_callback(data)) {
+        if (si->hvm) {
+            if (!libxl__remus_domain_suspend_qemu(si->gc, si->domid))
+                return 1;
+            else
+                return 0;
+        }
+        return 1;
+    }
+    return 0;
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Assumes that SUSPEND_CANCEL is available - just like
+     * xm version of Remus. Without that, remus wont work.
+     * Since libxl_domain_resume calls xc_domain_resume with
+     * fast_suspend = 0, we cant re-use that api.
+     */
+    if (xc_domain_resume(ctx->xch, si->domid, 1)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "xc_domain_resume failed for domain %u",
+                   si->domid);
+        return 0;
+    }
+    if (!xs_resume_domain(ctx->xsh, si->domid)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "xs_resume_domain failed for domain %u",
+                   si->domid);
+        return 0;
+    }
+
+    if (si->hvm) {
+        if (libxl__remus_domain_resume_qemu(si->gc, si->domid))
+            return 0;
+    }
+    return 1;
+}
+
+/* For now, just sleep. Later, we need to release disk/netbuf */
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    if (si->hvm && libxl__domain_save_device_model(si->gc, si->domid,
+                                                   si->save_fd, 1))
+            return 0;
+
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -614,10 +676,20 @@
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -641,7 +713,13 @@
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 14:43:58 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 14:44:00 2012 -0800
@@ -272,7 +272,8 @@
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd,
                                             int remus);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 23 22:49:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 23 Jan 2012 22: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 1RpShJ-0001E3-81; Mon, 23 Jan 2012 22:49:09 +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 1RpShH-0001DM-Dv
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 22:49:07 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327358938!12063694!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11930 invoked from network); 23 Jan 2012 22:49:00 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 23 Jan 2012 22:49:00 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0NMmrEk017850; Mon, 23 Jan 2012 14:48:53 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0NMmrQk017847;
	Mon, 23 Jan 2012 14:48:53 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0446591bee86eb4e767d75b70c885549c7a3cfef
Message-Id: <0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 23 Jan 2012 14:46:27 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 3] tools/libxl: suspend/postflush/commit
	callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327358640 28800
# Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef
# Parent  11fb1dfda7de4d6759dec87d80cd16cf137f7369
tools/libxl: suspend/postflush/commit callbacks

 * Add libxl callbacks for Remus checkpoint suspend, postflush (aka resume)
   and checkpoint commit callbacks.
 * suspend callback just bounces off libxl__domain_suspend_common_callback
 * resume callback directly calls xc_domain_resume instead of re-using
   libxl_domain_resume (as the latter does not set the fast suspend argument
   to xc_domain_resume - aka suspend_cancel support).
 * commit callback just sleeps for the checkpoint interval (for the moment).

 * Future patches will augument these callbacks with more functionalities like
   issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 23 14:43:58 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 23 14:44:00 2012 -0800
@@ -475,7 +475,9 @@
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd, /* No Remus */ 0);
     GC_FREE;
diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 23 14:43:58 2012 -0800
+++ b/tools/libxl/libxl.h	Mon Jan 23 14:44:00 2012 -0800
@@ -212,6 +212,12 @@
     int (*suspend_callback)(void *, int);
 } libxl_domain_suspend_info;
 
+typedef struct {
+    int interval;
+    int blackhole;
+    int compression;
+} libxl_domain_remus_info;
+
 enum {
     ERROR_NONSPECIFIC = -1,
     ERROR_VERSION = -2,
diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 23 14:43:58 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Mon Jan 23 14:44:00 2012 -0800
@@ -395,6 +395,8 @@
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* remus checkpoint interval */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -581,9 +583,69 @@
     return 0;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    if (libxl__domain_suspend_common_callback(data)) {
+        if (si->hvm) {
+            if (!libxl__remus_domain_suspend_qemu(si->gc, si->domid))
+                return 1;
+            else
+                return 0;
+        }
+        return 1;
+    }
+    return 0;
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Assumes that SUSPEND_CANCEL is available - just like
+     * xm version of Remus. Without that, remus wont work.
+     * Since libxl_domain_resume calls xc_domain_resume with
+     * fast_suspend = 0, we cant re-use that api.
+     */
+    if (xc_domain_resume(ctx->xch, si->domid, 1)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "xc_domain_resume failed for domain %u",
+                   si->domid);
+        return 0;
+    }
+    if (!xs_resume_domain(ctx->xsh, si->domid)) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "xs_resume_domain failed for domain %u",
+                   si->domid);
+        return 0;
+    }
+
+    if (si->hvm) {
+        if (libxl__remus_domain_resume_qemu(si->gc, si->domid))
+            return 0;
+    }
+    return 1;
+}
+
+/* For now, just sleep. Later, we need to release disk/netbuf */
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    if (si->hvm && libxl__domain_save_device_model(si->gc, si->domid,
+                                                   si->save_fd, 1))
+            return 0;
+
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -614,10 +676,20 @@
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -641,7 +713,13 @@
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 23 14:43:58 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Mon Jan 23 14:44:00 2012 -0800
@@ -272,7 +272,8 @@
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd,
                                             int remus);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 00:00:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 00:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpTnp-0003JI-UO; Mon, 23 Jan 2012 23:59:57 +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 1RpTno-0003JB-Da
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 23:59:56 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327363148!49783299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzkwMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12139 invoked from network); 23 Jan 2012 23:59:08 -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;
	23 Jan 2012 23:59:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,558,1320624000"; d="scan'208";a="10234180"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 23:59:55 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 23 Jan 2012
	23:59:55 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 23:59:47 +0000
Thread-Topic: [PATCH] Add a GNTTABOP to swap the content of two grant
	references under lock provided that they are not currently active.
Thread-Index: AczZxXGICc62GvoHTHO6TG85553OnAAZYAtg
Message-ID: <291EDFCB1E9E224A99088639C4762022C80E2F0D38@LONPMAILBOX01.citrite.net>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1327319475-7594-1-git-send-email-wei.liu2@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: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: 23 January 2012 03:51
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant; Wei Liu (Intern)
> Subject: [PATCH] Add a GNTTABOP to swap the content of two grant
> references under lock provided that they are not currently active.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

> ---
>  xen/arch/x86/hvm/hvm.c           |    1 +
>  xen/common/grant_table.c         |   86
> ++++++++++++++++++++++++++++++++++++++
>  xen/include/public/grant_table.h |   18 +++++++-
>  xen/include/xlat.lst             |    1 +
>  4 files changed, 104 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
> b3d9ac0..c46bd3e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int
> cmd)
>      case GNTTABOP_copy:
>      case GNTTABOP_map_grant_ref:
>      case GNTTABOP_unmap_grant_ref:
> +    case GNTTABOP_swap_grant_ref:
>          return 1;
>      default:
>          /* all other commands need auditing */ diff --git
> a/xen/common/grant_table.c b/xen/common/grant_table.c index
> 34a49db..1147a3b 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2282,6 +2282,78 @@
> gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
>      return 0;
>  }
> 
> +static s16
> +__gnttab_swap_grant_ref(unsigned long ref_a, unsigned long ref_b) {
> +    struct domain *d;
> +    struct active_grant_entry *act;
> +    s16 rc = GNTST_okay;
> +
> +    d = rcu_lock_current_domain();
> +
> +    spin_lock(&d->grant_table->lock);
> +
> +    act = &active_entry(d->grant_table, ref_a);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_a);
> +
> +    act = &active_entry(d->grant_table, ref_b);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_b);
> +
> +    if ( d->grant_table->gt_version == 1 ) {
> +        grant_entry_v1_t shared;
> +
> +        shared = shared_entry_v1(d->grant_table, ref_a);
> +
> +        shared_entry_v1(d->grant_table, ref_a) =
> +            shared_entry_v1(d->grant_table, ref_b);
> +
> +        shared_entry_v1(d->grant_table, ref_b) = shared;
> +    } else {
> +        grant_entry_v2_t shared;
> +        grant_status_t status;
> +
> +        shared = shared_entry_v2(d->grant_table, ref_a);
> +        status = status_entry(d->grant_table, ref_a);
> +
> +        shared_entry_v2(d->grant_table, ref_a) =
> +            shared_entry_v2(d->grant_table, ref_b);
> +        status_entry(d->grant_table, ref_a) =
> +            status_entry(d->grant_table, ref_b);
> +
> +        shared_entry_v2(d->grant_table, ref_b) = shared;
> +        status_entry(d->grant_table, ref_b) = status;
> +    }
> +
> +out:
> +    spin_unlock(&d->grant_table->lock);
> +
> +    rcu_unlock_domain(d);
> +
> +    return rc;
> +}
> +
> +static long
> +gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t
> uop),
> +                      unsigned int count) {
> +    int i;
> +    gnttab_swap_grant_ref_t op;
> +
> +    for ( i = 0; i < count; i++ )
> +    {
> +        if ( i && hypercall_preempt_check() )
> +            return i;
> +        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
> +            return -EFAULT;
> +        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
> +            return -EFAULT;
> +    }
> +    return 0;
> +}
> +
>  long
>  do_grant_table_op(
>      unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
> @@ -2400,6 +2472,20 @@ do_grant_table_op(
>          rc = gnttab_get_version(guest_handle_cast(uop,
> gnttab_get_version_t));
>          break;
>      }
> +    case GNTTABOP_swap_grant_ref:
> +    {
> +        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
> +            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
> +        if ( unlikely(!guest_handle_okay(swap, count)) )
> +            goto out;
> +        rc = gnttab_swap_grant_ref(swap, count);
> +        if ( rc > 0 )
> +        {
> +            guest_handle_add_offset(swap, rc);
> +            uop = guest_handle_cast(swap, void);
> +        }
> +        break;
> +    }
>      default:
>          rc = -ENOSYS;
>          break;
> diff --git a/xen/include/public/grant_table.h
> b/xen/include/public/grant_table.h
> index 0bf20bc..54d9551 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -511,6 +511,20 @@ struct gnttab_get_version {  typedef struct
> gnttab_get_version gnttab_get_version_t;
> DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
> 
> +/*
> + * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
> + */
> +#define GNTTABOP_swap_grant_ref	      11
> +struct gnttab_swap_grant_ref {
> +    /* IN parameters */
> +    grant_ref_t ref_a;
> +    grant_ref_t ref_b;
> +    /* OUT parameters */
> +    int16_t status;             /* GNTST_* */
> +};
> +typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
> +DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
> +
>  #endif /* __XEN_INTERFACE_VERSION__ */
> 
>  /*
> @@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>  #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 GNTST_eagain          (-12) /* Operation not done; try again.        */
> 
>  #define GNTTABOP_error_msgs {                   \
>      "okay",                                     \
> @@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>      "bad page",                                 \
>      "copy arguments cross page boundary",       \
>      "page address size too large",              \
> -    "could not map at the moment, retry"        \
> +    "operation not done; try again"             \
>  }
> 
>  #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */ diff --git
> a/xen/include/xlat.lst b/xen/include/xlat.lst index 3d92175..f602155 100644
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -50,6 +50,7 @@
>  ?	grant_entry_v1			grant_table.h
>  ?       grant_entry_header              grant_table.h
>  ?	grant_entry_v2			grant_table.h
> +?	gnttab_swap_grant_ref		grant_table.h
>  ?	kexec_exec			kexec.h
>  !	kexec_image			kexec.h
>  !	kexec_range			kexec.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 Jan 24 00:00:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 00:00:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpTnp-0003JI-UO; Mon, 23 Jan 2012 23:59:57 +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 1RpTno-0003JB-Da
	for xen-devel@lists.xensource.com; Mon, 23 Jan 2012 23:59:56 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327363148!49783299!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzkwMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12139 invoked from network); 23 Jan 2012 23:59:08 -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;
	23 Jan 2012 23:59:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,558,1320624000"; d="scan'208";a="10234180"
Received: from lonpmailmx02.citrite.net ([10.30.203.163])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	23 Jan 2012 23:59:55 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX02.citrite.net ([10.30.203.163]) with mapi; Mon, 23 Jan 2012
	23:59:55 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Date: Mon, 23 Jan 2012 23:59:47 +0000
Thread-Topic: [PATCH] Add a GNTTABOP to swap the content of two grant
	references under lock provided that they are not currently active.
Thread-Index: AczZxXGICc62GvoHTHO6TG85553OnAAZYAtg
Message-ID: <291EDFCB1E9E224A99088639C4762022C80E2F0D38@LONPMAILBOX01.citrite.net>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1327319475-7594-1-git-send-email-wei.liu2@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: "Wei Liu \(Intern\)" <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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: Wei Liu [mailto:wei.liu2@citrix.com]
> Sent: 23 January 2012 03:51
> To: xen-devel@lists.xensource.com
> Cc: Paul Durrant; Wei Liu (Intern)
> Subject: [PATCH] Add a GNTTABOP to swap the content of two grant
> references under lock provided that they are not currently active.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

> ---
>  xen/arch/x86/hvm/hvm.c           |    1 +
>  xen/common/grant_table.c         |   86
> ++++++++++++++++++++++++++++++++++++++
>  xen/include/public/grant_table.h |   18 +++++++-
>  xen/include/xlat.lst             |    1 +
>  4 files changed, 104 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index
> b3d9ac0..c46bd3e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int
> cmd)
>      case GNTTABOP_copy:
>      case GNTTABOP_map_grant_ref:
>      case GNTTABOP_unmap_grant_ref:
> +    case GNTTABOP_swap_grant_ref:
>          return 1;
>      default:
>          /* all other commands need auditing */ diff --git
> a/xen/common/grant_table.c b/xen/common/grant_table.c index
> 34a49db..1147a3b 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2282,6 +2282,78 @@
> gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
>      return 0;
>  }
> 
> +static s16
> +__gnttab_swap_grant_ref(unsigned long ref_a, unsigned long ref_b) {
> +    struct domain *d;
> +    struct active_grant_entry *act;
> +    s16 rc = GNTST_okay;
> +
> +    d = rcu_lock_current_domain();
> +
> +    spin_lock(&d->grant_table->lock);
> +
> +    act = &active_entry(d->grant_table, ref_a);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_a);
> +
> +    act = &active_entry(d->grant_table, ref_b);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref %ld busy\n", ref_b);
> +
> +    if ( d->grant_table->gt_version == 1 ) {
> +        grant_entry_v1_t shared;
> +
> +        shared = shared_entry_v1(d->grant_table, ref_a);
> +
> +        shared_entry_v1(d->grant_table, ref_a) =
> +            shared_entry_v1(d->grant_table, ref_b);
> +
> +        shared_entry_v1(d->grant_table, ref_b) = shared;
> +    } else {
> +        grant_entry_v2_t shared;
> +        grant_status_t status;
> +
> +        shared = shared_entry_v2(d->grant_table, ref_a);
> +        status = status_entry(d->grant_table, ref_a);
> +
> +        shared_entry_v2(d->grant_table, ref_a) =
> +            shared_entry_v2(d->grant_table, ref_b);
> +        status_entry(d->grant_table, ref_a) =
> +            status_entry(d->grant_table, ref_b);
> +
> +        shared_entry_v2(d->grant_table, ref_b) = shared;
> +        status_entry(d->grant_table, ref_b) = status;
> +    }
> +
> +out:
> +    spin_unlock(&d->grant_table->lock);
> +
> +    rcu_unlock_domain(d);
> +
> +    return rc;
> +}
> +
> +static long
> +gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t
> uop),
> +                      unsigned int count) {
> +    int i;
> +    gnttab_swap_grant_ref_t op;
> +
> +    for ( i = 0; i < count; i++ )
> +    {
> +        if ( i && hypercall_preempt_check() )
> +            return i;
> +        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
> +            return -EFAULT;
> +        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
> +            return -EFAULT;
> +    }
> +    return 0;
> +}
> +
>  long
>  do_grant_table_op(
>      unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
> @@ -2400,6 +2472,20 @@ do_grant_table_op(
>          rc = gnttab_get_version(guest_handle_cast(uop,
> gnttab_get_version_t));
>          break;
>      }
> +    case GNTTABOP_swap_grant_ref:
> +    {
> +        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
> +            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
> +        if ( unlikely(!guest_handle_okay(swap, count)) )
> +            goto out;
> +        rc = gnttab_swap_grant_ref(swap, count);
> +        if ( rc > 0 )
> +        {
> +            guest_handle_add_offset(swap, rc);
> +            uop = guest_handle_cast(swap, void);
> +        }
> +        break;
> +    }
>      default:
>          rc = -ENOSYS;
>          break;
> diff --git a/xen/include/public/grant_table.h
> b/xen/include/public/grant_table.h
> index 0bf20bc..54d9551 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -511,6 +511,20 @@ struct gnttab_get_version {  typedef struct
> gnttab_get_version gnttab_get_version_t;
> DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
> 
> +/*
> + * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
> + */
> +#define GNTTABOP_swap_grant_ref	      11
> +struct gnttab_swap_grant_ref {
> +    /* IN parameters */
> +    grant_ref_t ref_a;
> +    grant_ref_t ref_b;
> +    /* OUT parameters */
> +    int16_t status;             /* GNTST_* */
> +};
> +typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
> +DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
> +
>  #endif /* __XEN_INTERFACE_VERSION__ */
> 
>  /*
> @@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>  #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 GNTST_eagain          (-12) /* Operation not done; try again.        */
> 
>  #define GNTTABOP_error_msgs {                   \
>      "okay",                                     \
> @@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>      "bad page",                                 \
>      "copy arguments cross page boundary",       \
>      "page address size too large",              \
> -    "could not map at the moment, retry"        \
> +    "operation not done; try again"             \
>  }
> 
>  #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */ diff --git
> a/xen/include/xlat.lst b/xen/include/xlat.lst index 3d92175..f602155 100644
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -50,6 +50,7 @@
>  ?	grant_entry_v1			grant_table.h
>  ?       grant_entry_header              grant_table.h
>  ?	grant_entry_v2			grant_table.h
> +?	gnttab_swap_grant_ref		grant_table.h
>  ?	kexec_exec			kexec.h
>  !	kexec_image			kexec.h
>  !	kexec_range			kexec.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 Jan 24 00:29:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 00: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 1RpUFr-0004QY-I6; Tue, 24 Jan 2012 00:28:55 +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 1RpUFq-0004QT-8J
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 00:28:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327364926!12105035!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 8339 invoked from network); 24 Jan 2012 00:28:47 -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; 24 Jan 2012 00:28:47 -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
	q0O0SXkA018851
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 19:28:33 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O0SSSV018839;
	Mon, 23 Jan 2012 19:28:28 -0500
Date: Mon, 23 Jan 2012 20:28:28 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: David Vrabel <dvrabel@cantab.net>
Message-ID: <20120124002828.GA18635@andromeda.dapyr.net>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
	<20120123195047.GA11002@phenom.dumpdata.com>
	<4F1DD4C1.2070704@cantab.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1DD4C1.2070704@cantab.net>
User-Agent: Mutt/1.5.9i
Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
	always fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 09:44:33PM +0000, David Vrabel wrote:
> On 23/01/2012 19:50, Konrad Rzeszutek Wilk wrote:
> >On Mon, Jan 23, 2012 at 07:32:25PM +0000, David Vrabel wrote:
> >>From: David Vrabel<david.vrabel@citrix.com>
> >>
> >>If NR_CPUS<  256 then arch_spinlock_t is only 16 bits wide but struct
> >>xen_spinlock is 32 bits.  When a spin lock is contended and
> >>xl->spinners is modified the two bytes immediately after the spin lock
> >>would be corrupted.
> >>
> >>This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
> >>(x86, ticketlock: Clean up types and accessors) which reduced the size
> >>of arch_spinlock_t.
> >>
> >>Fix this by making xl->spinners a u8 if NR_CPUS<  256.  A
> >>BUILD_BUG_ON() is also added to check the sizes of the two structures
> >>are compatible.
> >>
> >>In many cases this was not noticable as there would often be padding
> >>bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
> >>CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
> >>
> >>The bnx2 driver is affected. In struct bnx2, phy_lock and
> >>indirect_lock may have no padding after them.  Contention on phy_lock
> >>would corrupt indirect_lock making it appear locked and the driver
> >>would deadlock.
> >
> >Nice find. I think it also affected the ahci driver, and some of the USB
> >ones - at least those I saw starting to hang with:
> 
> It's possible but keep in mind that this isn't a recent regression.  I 
> think it's been around since 3.0 and maybe even earlier.

konrad@phenom:~/work/linux.mm$ git tag --contains 84eb950db13ca40a0572ce9957e14723500943d6 | grep -v rc
v3.2

So since v3.2, hmm, I should double-check those serial logs
to see if the problems I had were in 3.2 as well.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 00:29:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 00: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 1RpUFr-0004QY-I6; Tue, 24 Jan 2012 00:28:55 +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 1RpUFq-0004QT-8J
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 00:28:54 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327364926!12105035!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 8339 invoked from network); 24 Jan 2012 00:28:47 -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; 24 Jan 2012 00:28:47 -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
	q0O0SXkA018851
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 19:28:33 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O0SSSV018839;
	Mon, 23 Jan 2012 19:28:28 -0500
Date: Mon, 23 Jan 2012 20:28:28 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: David Vrabel <dvrabel@cantab.net>
Message-ID: <20120124002828.GA18635@andromeda.dapyr.net>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
	<20120123195047.GA11002@phenom.dumpdata.com>
	<4F1DD4C1.2070704@cantab.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1DD4C1.2070704@cantab.net>
User-Agent: Mutt/1.5.9i
Cc: linux-kernel@vger.kernel.org, Jeremy Fitzhardinge <jeremy@goop.org>,
	xen-devel@lists.xensource.com, David Vrabel <david.vrabel@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
	always fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 09:44:33PM +0000, David Vrabel wrote:
> On 23/01/2012 19:50, Konrad Rzeszutek Wilk wrote:
> >On Mon, Jan 23, 2012 at 07:32:25PM +0000, David Vrabel wrote:
> >>From: David Vrabel<david.vrabel@citrix.com>
> >>
> >>If NR_CPUS<  256 then arch_spinlock_t is only 16 bits wide but struct
> >>xen_spinlock is 32 bits.  When a spin lock is contended and
> >>xl->spinners is modified the two bytes immediately after the spin lock
> >>would be corrupted.
> >>
> >>This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
> >>(x86, ticketlock: Clean up types and accessors) which reduced the size
> >>of arch_spinlock_t.
> >>
> >>Fix this by making xl->spinners a u8 if NR_CPUS<  256.  A
> >>BUILD_BUG_ON() is also added to check the sizes of the two structures
> >>are compatible.
> >>
> >>In many cases this was not noticable as there would often be padding
> >>bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
> >>CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
> >>
> >>The bnx2 driver is affected. In struct bnx2, phy_lock and
> >>indirect_lock may have no padding after them.  Contention on phy_lock
> >>would corrupt indirect_lock making it appear locked and the driver
> >>would deadlock.
> >
> >Nice find. I think it also affected the ahci driver, and some of the USB
> >ones - at least those I saw starting to hang with:
> 
> It's possible but keep in mind that this isn't a recent regression.  I 
> think it's been around since 3.0 and maybe even earlier.

konrad@phenom:~/work/linux.mm$ git tag --contains 84eb950db13ca40a0572ce9957e14723500943d6 | grep -v rc
v3.2

So since v3.2, hmm, I should double-check those serial logs
to see if the problems I had were in 3.2 as well.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 00:36:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 00: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 1RpUMv-0004Zn-FQ; Tue, 24 Jan 2012 00:36:13 +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 1RpUMt-0004Zg-T7
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 00:36:12 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327365322!49785160!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21936 invoked from network); 24 Jan 2012 00:35:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 00:35: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
	q0O0a8Mp019196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 19:36:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O0a8Lr019194;
	Mon, 23 Jan 2012 19:36:08 -0500
Date: Mon, 23 Jan 2012 20:36:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Eric Camachat <eric.camachat@gmail.com>
Message-ID: <20120124003608.GB18635@andromeda.dapyr.net>
References: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
	<20120122202337.GA30288@andromeda.dapyr.net>
	<CACeEFf60o2jJ=5exxEfVegfPAVN_VjV0L4MXYFK_RQx1XXGfPQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACeEFf60o2jJ=5exxEfVegfPAVN_VjV0L4MXYFK_RQx1XXGfPQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Got kernel BUG message while PCI pass-through to
	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 Mon, Jan 23, 2012 at 11:22:28AM -0800, Eric Camachat wrote:
> Thanks,  Konrad.
> 
> Do you mean dom0 kernel? or The domU kernel?

Please don't top post.

The fix (and the bug) are both in xen_pciback - which is in the
dom0.

The fix I believe is this git commit:
commit b1766b62890e3bba1a778a20ef8bf9348d6096c2
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Sep 16 14:43:14 2011 -0400

    xen/pciback: Use mutexes when working with Xenbus state transitions.
    
    The caller that orchestrates the state changes is xenwatch_thread
    and it takes a mutex. In our processing of Xenbus states we can take
    the luxery of going to sleep on a mutex, so lets do that and
    also fix this bug:
    
    BUG: sleeping function called from invalid context at
/linux/kernel/mutex.c:271
    in_atomic(): 1, irqs_disabled(): 0, pid: 32, name: xenwatch
    2 locks held by xenwatch/32:
     #0:  (xenwatch_mutex){......}, at: [<ffffffff813856ab>]
xenwatch_thread+0x4b/0x180
     #1:  (&(&pdev->dev_lock)->rlock){......}, at: [<ffffffff8138f05b>]
xen_pcibk_disconnect+0x1b/0x80
    Pid: 32, comm: xenwatch Not tainted 3.1.0-rc6-00015-g3ce340d #2
    Call Trace:
     [<ffffffff810892b2>] __might_sleep+0x102/0x130
     [<ffffffff8163b90f>] mutex_lock_nested+0x2f/0x50
     [<ffffffff81382c1c>] unbind_from_irq+0x2c/0x1b0
     [<ffffffff8110da66>] ? free_irq+0x56/0xb0
     [<ffffffff81382dbc>] unbind_from_irqhandler+0x1c/0x30
     [<ffffffff8138f06b>] xen_pcibk_disconnect+0x2b/0x80
     [<ffffffff81390348>] xen_pcibk_frontend_changed+0xe8/0x140
     [<ffffffff81387ac2>] xenbus_otherend_changed+0xd2/0x150
     [<ffffffff810895c1>] ? get_parent_ip+0x11/0x50
     [<ffffffff81387de0>] frontend_changed+0x10/0x20
     [<ffffffff81385712>] xenwatch_thread+0xb2/0x180
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

So it went in 3.1.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 00:36:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 00: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 1RpUMv-0004Zn-FQ; Tue, 24 Jan 2012 00:36:13 +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 1RpUMt-0004Zg-T7
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 00:36:12 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327365322!49785160!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21936 invoked from network); 24 Jan 2012 00:35:23 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 00:35: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
	q0O0a8Mp019196
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 19:36:08 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O0a8Lr019194;
	Mon, 23 Jan 2012 19:36:08 -0500
Date: Mon, 23 Jan 2012 20:36:08 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Eric Camachat <eric.camachat@gmail.com>
Message-ID: <20120124003608.GB18635@andromeda.dapyr.net>
References: <CACeEFf4MzcMvU+uiMjG8AyT6B-yw6DQh2Y1Luo9nbVGaO_gw4A@mail.gmail.com>
	<20120122202337.GA30288@andromeda.dapyr.net>
	<CACeEFf60o2jJ=5exxEfVegfPAVN_VjV0L4MXYFK_RQx1XXGfPQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CACeEFf60o2jJ=5exxEfVegfPAVN_VjV0L4MXYFK_RQx1XXGfPQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Got kernel BUG message while PCI pass-through to
	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 Mon, Jan 23, 2012 at 11:22:28AM -0800, Eric Camachat wrote:
> Thanks,  Konrad.
> 
> Do you mean dom0 kernel? or The domU kernel?

Please don't top post.

The fix (and the bug) are both in xen_pciback - which is in the
dom0.

The fix I believe is this git commit:
commit b1766b62890e3bba1a778a20ef8bf9348d6096c2
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Sep 16 14:43:14 2011 -0400

    xen/pciback: Use mutexes when working with Xenbus state transitions.
    
    The caller that orchestrates the state changes is xenwatch_thread
    and it takes a mutex. In our processing of Xenbus states we can take
    the luxery of going to sleep on a mutex, so lets do that and
    also fix this bug:
    
    BUG: sleeping function called from invalid context at
/linux/kernel/mutex.c:271
    in_atomic(): 1, irqs_disabled(): 0, pid: 32, name: xenwatch
    2 locks held by xenwatch/32:
     #0:  (xenwatch_mutex){......}, at: [<ffffffff813856ab>]
xenwatch_thread+0x4b/0x180
     #1:  (&(&pdev->dev_lock)->rlock){......}, at: [<ffffffff8138f05b>]
xen_pcibk_disconnect+0x1b/0x80
    Pid: 32, comm: xenwatch Not tainted 3.1.0-rc6-00015-g3ce340d #2
    Call Trace:
     [<ffffffff810892b2>] __might_sleep+0x102/0x130
     [<ffffffff8163b90f>] mutex_lock_nested+0x2f/0x50
     [<ffffffff81382c1c>] unbind_from_irq+0x2c/0x1b0
     [<ffffffff8110da66>] ? free_irq+0x56/0xb0
     [<ffffffff81382dbc>] unbind_from_irqhandler+0x1c/0x30
     [<ffffffff8138f06b>] xen_pcibk_disconnect+0x2b/0x80
     [<ffffffff81390348>] xen_pcibk_frontend_changed+0xe8/0x140
     [<ffffffff81387ac2>] xenbus_otherend_changed+0xd2/0x150
     [<ffffffff810895c1>] ? get_parent_ip+0x11/0x50
     [<ffffffff81387de0>] frontend_changed+0x10/0x20
     [<ffffffff81385712>] xenwatch_thread+0xb2/0x180
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

So it went in 3.1.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 01:42:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 01:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpVOY-0000Ui-DB; Tue, 24 Jan 2012 01:41:58 +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 1RpVOW-0000Ud-F3
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 01:41:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327369309!12073227!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 27891 invoked from network); 24 Jan 2012 01:41:50 -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; 24 Jan 2012 01:41:50 -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
	q0O1fj1W024151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:41:45 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1fi4X024149;
	Mon, 23 Jan 2012 20:41:44 -0500
Date: Mon, 23 Jan 2012 21:41:44 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120124014144.GA23702@andromeda.dapyr.net>
References: <mailman.1214.1327325228.1471.xen-devel@lists.xensource.com>
	<2354ea8a6f50d7f7703369aac0ed80a2.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2354ea8a6f50d7f7703369aac0ed80a2.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] Xen 4.2 TODO List
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 07:03:09AM -0800, Andres Lagar-Cavilla wrote:
> > Date: Mon, 23 Jan 2012 13:19:05 +0000
> > From: Ian Campbell <Ian.Campbell@citrix.com>
> > To: xen-devel <xen-devel@lists.xensource.com>
> > Subject: [Xen-devel] Xen 4.2 TODO List Update
> > Message-ID: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Newly updated list follows. Please send me corrections (especially
> > "done"). I've stopped CCing everyone, since I guess it is mostly spam to
> > the majority.
> >
> > hypervisor, blockers:
> >
> >       * round-up of the closing of the security hole in MSI-X
> >         passthrough (uniformly - i.e. even for Dom0 - disallowing write
> >         access to MSI-X table pages). (Jan Beulich -- more fixes
> >         required than first thought, patches posted)
> >       * domctls / sysctls set up to modify scheduler parameters, like
> >         the credit1 timeslice and schedule rate. (George Dunlap)
> >       * get the interface changes for sharing/paging/mem-events done and
> >         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
> >         Andres Lagar-Cavilla et al)
> >               * mem event ring management posted, seems close to going
> >                 in.
> Mem event ring management has gone in, so you can chalk it off the list.

Any progress on the pvops side of this? This is the -EBUSY patches
right?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 01:42:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 01:42:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpVOY-0000Ui-DB; Tue, 24 Jan 2012 01:41:58 +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 1RpVOW-0000Ud-F3
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 01:41:56 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327369309!12073227!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 27891 invoked from network); 24 Jan 2012 01:41:50 -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; 24 Jan 2012 01:41:50 -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
	q0O1fj1W024151
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:41:45 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1fi4X024149;
	Mon, 23 Jan 2012 20:41:44 -0500
Date: Mon, 23 Jan 2012 21:41:44 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120124014144.GA23702@andromeda.dapyr.net>
References: <mailman.1214.1327325228.1471.xen-devel@lists.xensource.com>
	<2354ea8a6f50d7f7703369aac0ed80a2.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2354ea8a6f50d7f7703369aac0ed80a2.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com
Subject: Re: [Xen-devel] Xen 4.2 TODO List
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 07:03:09AM -0800, Andres Lagar-Cavilla wrote:
> > Date: Mon, 23 Jan 2012 13:19:05 +0000
> > From: Ian Campbell <Ian.Campbell@citrix.com>
> > To: xen-devel <xen-devel@lists.xensource.com>
> > Subject: [Xen-devel] Xen 4.2 TODO List Update
> > Message-ID: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Newly updated list follows. Please send me corrections (especially
> > "done"). I've stopped CCing everyone, since I guess it is mostly spam to
> > the majority.
> >
> > hypervisor, blockers:
> >
> >       * round-up of the closing of the security hole in MSI-X
> >         passthrough (uniformly - i.e. even for Dom0 - disallowing write
> >         access to MSI-X table pages). (Jan Beulich -- more fixes
> >         required than first thought, patches posted)
> >       * domctls / sysctls set up to modify scheduler parameters, like
> >         the credit1 timeslice and schedule rate. (George Dunlap)
> >       * get the interface changes for sharing/paging/mem-events done and
> >         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
> >         Andres Lagar-Cavilla et al)
> >               * mem event ring management posted, seems close to going
> >                 in.
> Mem event ring management has gone in, so you can chalk it off the list.

Any progress on the pvops side of this? This is the -EBUSY patches
right?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 01:48:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 01:48:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpVTx-0000lx-Db; Tue, 24 Jan 2012 01:47:33 +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 1RpVTw-0000lr-5x
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 01:47:32 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327369601!51449969!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10830 invoked from network); 24 Jan 2012 01:46:42 -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; 24 Jan 2012 01:46: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
	q0O1lJ7Q024308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:47:22 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1lHXV024305;
	Mon, 23 Jan 2012 20:47:17 -0500
Date: Mon, 23 Jan 2012 21:47:17 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Joe Perches <joe@perches.com>
Message-ID: <20120124014717.GA24204@andromeda.dapyr.net>
References: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Andy Whitcroft <apw@canonical.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] include/checkpatch: Prefer __scanf to
	__attribute__((format(scanf, ...)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 20, 2012 at 04:01:12PM -0800, Joe Perches wrote:
> It's equivalent to __printf, so prefer __scanf.

So ... looking at this patch it just seems to macro-fy the
__printf and __scanf attributes. Is this required to make
cleanpatch.pl work easier?

And there is also some checkpatch.pl features. Should that part
be in a seperate patch?

> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>  include/linux/compiler-gcc.h |    3 ++-
>  include/linux/kernel.h       |    8 ++++----
>  include/xen/xenbus.h         |    4 ++--
>  scripts/checkpatch.pl        |    6 ++++++
>  4 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 3fd17c2..e5834aa 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -87,7 +87,8 @@
>   */
>  #define __pure				__attribute__((pure))
>  #define __aligned(x)			__attribute__((aligned(x)))
> -#define __printf(a,b)			__attribute__((format(printf,a,b)))
> +#define __printf(a, b)			__attribute__((format(printf, a, b)))
> +#define __scanf(a, b)			__attribute__((format(scanf, a, b)))
>  #define  noinline			__attribute__((noinline))
>  #define __attribute_const__		__attribute__((__const__))
>  #define __maybe_unused			__attribute__((unused))
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e834342..30f21ec 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -315,10 +315,10 @@ extern __printf(2, 3)
>  char *kasprintf(gfp_t gfp, const char *fmt, ...);
>  extern char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
>  
> -extern int sscanf(const char *, const char *, ...)
> -	__attribute__ ((format (scanf, 2, 3)));
> -extern int vsscanf(const char *, const char *, va_list)
> -	__attribute__ ((format (scanf, 2, 0)));
> +extern __scanf(2, 3)
> +int sscanf(const char *, const char *, ...);
> +extern __scanf(2, 0)
> +int vsscanf(const char *, const char *, va_list);
>  
>  extern int get_option(char **str, int *pint);
>  extern char *get_options(const char *str, int nints, int *ints);
> diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
> index e8c599b..0a7515c 100644
> --- a/include/xen/xenbus.h
> +++ b/include/xen/xenbus.h
> @@ -139,9 +139,9 @@ int xenbus_transaction_start(struct xenbus_transaction *t);
>  int xenbus_transaction_end(struct xenbus_transaction t, int abort);
>  
>  /* Single read and scanf: returns -errno or num scanned if > 0. */
> +__scanf(4, 5)
>  int xenbus_scanf(struct xenbus_transaction t,
> -		 const char *dir, const char *node, const char *fmt, ...)
> -	__attribute__((format(scanf, 4, 5)));
> +		 const char *dir, const char *node, const char *fmt, ...);
>  
>  /* Single printf and write: returns -errno or 0. */
>  __printf(4, 5)
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index e3bfcbe..2b52aeb 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3117,6 +3117,12 @@ sub process {
>  			     "__printf(string-index, first-to-check) is preferred over __attribute__((format(printf, string-index, first-to-check)))\n" . $herecurr);
>  		}
>  
> +# Check for __attribute__ format(scanf, prefer __scanf
> +		if ($line =~ /\b__attribute__\s*\(\s*\(\s*format\s*\(\s*scanf\b/) {
> +			WARN("PREFER_SCANF",
> +			     "__scanf(string-index, first-to-check) is preferred over __attribute__((format(scanf, string-index, first-to-check)))\n" . $herecurr);
> +		}
> +
>  # check for sizeof(&)
>  		if ($line =~ /\bsizeof\s*\(\s*\&/) {
>  			WARN("SIZEOF_ADDRESS",
> -- 
> 1.7.8.111.gad25c.dirty
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 24 01:48:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 01:48:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpVTx-0000lx-Db; Tue, 24 Jan 2012 01:47:33 +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 1RpVTw-0000lr-5x
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 01:47:32 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327369601!51449969!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10830 invoked from network); 24 Jan 2012 01:46:42 -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; 24 Jan 2012 01:46: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
	q0O1lJ7Q024308
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:47:22 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1lHXV024305;
	Mon, 23 Jan 2012 20:47:17 -0500
Date: Mon, 23 Jan 2012 21:47:17 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Joe Perches <joe@perches.com>
Message-ID: <20120124014717.GA24204@andromeda.dapyr.net>
References: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
User-Agent: Mutt/1.5.9i
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Andy Whitcroft <apw@canonical.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] include/checkpatch: Prefer __scanf to
	__attribute__((format(scanf, ...)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 20, 2012 at 04:01:12PM -0800, Joe Perches wrote:
> It's equivalent to __printf, so prefer __scanf.

So ... looking at this patch it just seems to macro-fy the
__printf and __scanf attributes. Is this required to make
cleanpatch.pl work easier?

And there is also some checkpatch.pl features. Should that part
be in a seperate patch?

> Signed-off-by: Joe Perches <joe@perches.com>
> ---
>  include/linux/compiler-gcc.h |    3 ++-
>  include/linux/kernel.h       |    8 ++++----
>  include/xen/xenbus.h         |    4 ++--
>  scripts/checkpatch.pl        |    6 ++++++
>  4 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 3fd17c2..e5834aa 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -87,7 +87,8 @@
>   */
>  #define __pure				__attribute__((pure))
>  #define __aligned(x)			__attribute__((aligned(x)))
> -#define __printf(a,b)			__attribute__((format(printf,a,b)))
> +#define __printf(a, b)			__attribute__((format(printf, a, b)))
> +#define __scanf(a, b)			__attribute__((format(scanf, a, b)))
>  #define  noinline			__attribute__((noinline))
>  #define __attribute_const__		__attribute__((__const__))
>  #define __maybe_unused			__attribute__((unused))
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e834342..30f21ec 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -315,10 +315,10 @@ extern __printf(2, 3)
>  char *kasprintf(gfp_t gfp, const char *fmt, ...);
>  extern char *kvasprintf(gfp_t gfp, const char *fmt, va_list args);
>  
> -extern int sscanf(const char *, const char *, ...)
> -	__attribute__ ((format (scanf, 2, 3)));
> -extern int vsscanf(const char *, const char *, va_list)
> -	__attribute__ ((format (scanf, 2, 0)));
> +extern __scanf(2, 3)
> +int sscanf(const char *, const char *, ...);
> +extern __scanf(2, 0)
> +int vsscanf(const char *, const char *, va_list);
>  
>  extern int get_option(char **str, int *pint);
>  extern char *get_options(const char *str, int nints, int *ints);
> diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h
> index e8c599b..0a7515c 100644
> --- a/include/xen/xenbus.h
> +++ b/include/xen/xenbus.h
> @@ -139,9 +139,9 @@ int xenbus_transaction_start(struct xenbus_transaction *t);
>  int xenbus_transaction_end(struct xenbus_transaction t, int abort);
>  
>  /* Single read and scanf: returns -errno or num scanned if > 0. */
> +__scanf(4, 5)
>  int xenbus_scanf(struct xenbus_transaction t,
> -		 const char *dir, const char *node, const char *fmt, ...)
> -	__attribute__((format(scanf, 4, 5)));
> +		 const char *dir, const char *node, const char *fmt, ...);
>  
>  /* Single printf and write: returns -errno or 0. */
>  __printf(4, 5)
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index e3bfcbe..2b52aeb 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3117,6 +3117,12 @@ sub process {
>  			     "__printf(string-index, first-to-check) is preferred over __attribute__((format(printf, string-index, first-to-check)))\n" . $herecurr);
>  		}
>  
> +# Check for __attribute__ format(scanf, prefer __scanf
> +		if ($line =~ /\b__attribute__\s*\(\s*\(\s*format\s*\(\s*scanf\b/) {
> +			WARN("PREFER_SCANF",
> +			     "__scanf(string-index, first-to-check) is preferred over __attribute__((format(scanf, string-index, first-to-check)))\n" . $herecurr);
> +		}
> +
>  # check for sizeof(&)
>  		if ($line =~ /\bsizeof\s*\(\s*\&/) {
>  			WARN("SIZEOF_ADDRESS",
> -- 
> 1.7.8.111.gad25c.dirty
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 24 01:54:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 01: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 1RpVZs-0000wN-As; Tue, 24 Jan 2012 01:53: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 1RpVZr-0000wE-Hm; Tue, 24 Jan 2012 01:53:39 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327370011!9923476!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 3029 invoked from network); 24 Jan 2012 01:53:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 01:53: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
	q0O1rUt4024454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:53:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1rTwR024452;
	Mon, 23 Jan 2012 20:53:29 -0500
Date: Mon, 23 Jan 2012 21:53:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120124015329.GC24204@andromeda.dapyr.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
	<CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
	John Sherwood <jrs@vt.edu>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 12:45:05PM +0100, Sandi Romih wrote:
> Hi John,
> 
> I am trying to pass my secondary graphics card through to the VM. My dom0
> runs with the primary card (an onboard GPU).
> 
> What happens with me is that the secondary card (GTX480) is relinquished to
> pciback and according to the logs, it looks like the card is passed through
> successfully to the domU.
> What happens though is a bit puzzling (with gfx_passthru=1):
> 1) When I start the domU, my dom0 screen goes blank (which is using a
> different graphics card than is assigned to the domU)
> 2) The domain does not boot; i.e. the CDROM does not spin up.
> 3) If I connect to the domain via vnc, I see only the qemu console.
> 
> With gfx_passthru=0, the following happens:
> a) The domain boots fine (the CDROM spins up).
> b) I can connect to the OS in the domain via vnc.
> c) The Windows OS installs fine and functions fine afterwards too.
> d) I can see the GFX480 card in the device manager, but I can not use the
> device (even if I install the correct drivers for it)

So you are using Nvidia. And those seem to require some extra patches.
Look for the vBar=pBar or so.

> 
> Check out the details of my problem
> here<http://lists.xen.org/archives/html/xen-devel/2012-01/msg01626.html>.
> I have marked the things that concern me in red. I am obviously missing
> something...

Did you look at David Techer postings? He has been doing extensive work
in this area.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 01:54:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 01: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 1RpVZs-0000wN-As; Tue, 24 Jan 2012 01:53: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 1RpVZr-0000wE-Hm; Tue, 24 Jan 2012 01:53:39 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327370011!9923476!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 3029 invoked from network); 24 Jan 2012 01:53:32 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-8.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 01:53: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
	q0O1rUt4024454
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:53:30 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1rTwR024452;
	Mon, 23 Jan 2012 20:53:29 -0500
Date: Mon, 23 Jan 2012 21:53:29 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120124015329.GC24204@andromeda.dapyr.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<3B7B9131A63345CCB34B508E3E4F3507@nobody>
	<CAKnNFz_DUQQ5FjGB83_p-uFefSu63T3jVh6Gu-hE5xD978qj4A@mail.gmail.com>
	<CAH5ygH1Q=Eh8Ma3erT52r65VceGjQKgiLxbRSwa_rr6COS8p6A@mail.gmail.com>
	<CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVO7B3LTuKkuSVLcToE+txDFuEq2-NA4Q5BqZhUCbBo8Qg@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com,
	John Sherwood <jrs@vt.edu>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 12:45:05PM +0100, Sandi Romih wrote:
> Hi John,
> 
> I am trying to pass my secondary graphics card through to the VM. My dom0
> runs with the primary card (an onboard GPU).
> 
> What happens with me is that the secondary card (GTX480) is relinquished to
> pciback and according to the logs, it looks like the card is passed through
> successfully to the domU.
> What happens though is a bit puzzling (with gfx_passthru=1):
> 1) When I start the domU, my dom0 screen goes blank (which is using a
> different graphics card than is assigned to the domU)
> 2) The domain does not boot; i.e. the CDROM does not spin up.
> 3) If I connect to the domain via vnc, I see only the qemu console.
> 
> With gfx_passthru=0, the following happens:
> a) The domain boots fine (the CDROM spins up).
> b) I can connect to the OS in the domain via vnc.
> c) The Windows OS installs fine and functions fine afterwards too.
> d) I can see the GFX480 card in the device manager, but I can not use the
> device (even if I install the correct drivers for it)

So you are using Nvidia. And those seem to require some extra patches.
Look for the vBar=pBar or so.

> 
> Check out the details of my problem
> here<http://lists.xen.org/archives/html/xen-devel/2012-01/msg01626.html>.
> I have marked the things that concern me in red. I am obviously missing
> something...

Did you look at David Techer postings? He has been doing extensive work
in this area.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 01:55:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 01: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 1RpVbi-00012V-1D; Tue, 24 Jan 2012 01:55:34 +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 1RpVbh-00012F-8E; Tue, 24 Jan 2012 01:55:33 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327370125!9558068!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 22757 invoked from network); 24 Jan 2012 01:55:26 -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; 24 Jan 2012 01:55: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
	q0O1tJ8p024510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:55:19 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1tJHs024507;
	Mon, 23 Jan 2012 20:55:19 -0500
Date: Mon, 23 Jan 2012 21:55:19 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120124015519.GD24204@andromeda.dapyr.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<20120120203205.GW12984@reaktio.net>
	<CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
> Pasi,
> 
> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
> 
> (XEN) I/O virtualisation enabled
> 
> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
> 
> But I dont think I have this message (I am not near my system now, so I can
> not confirm)
> 
> (XEN) I/O virtualisation for PV guests enabled
> 
> 
> I believe that many have managed to get VGA passthru working, but they
> generally dont post their stories. one only finds the problems they are
> encountering when searching about this. That is why it would be nice to put
> together a kind of manual in the wiki which would have all this info
> together in one location.

http://lmgtfy.com/?q=Xen+VGA+passthrough

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 01:55:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 01: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 1RpVbi-00012V-1D; Tue, 24 Jan 2012 01:55:34 +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 1RpVbh-00012F-8E; Tue, 24 Jan 2012 01:55:33 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-21.messagelabs.com!1327370125!9558068!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 22757 invoked from network); 24 Jan 2012 01:55:26 -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; 24 Jan 2012 01:55: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
	q0O1tJ8p024510
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:55:19 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1tJHs024507;
	Mon, 23 Jan 2012 20:55:19 -0500
Date: Mon, 23 Jan 2012 21:55:19 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120124015519.GD24204@andromeda.dapyr.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120120154745.GV12984@reaktio.net>
	<CAFoWEVN20pqy-79k9st2-fnD-1JjOzoKTwXmMUJ+fwvKPFUGHQ@mail.gmail.com>
	<20120120203205.GW12984@reaktio.net>
	<CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVOU=s01j3LOO5qH8Len6AyT+2Tf4WcZm0UB4q8NTN+N2Q@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 12:53:50PM +0100, Sandi Romih wrote:
> Pasi,
> 
> Yes, I did verify that IOMMU is enabled. I get this in my xm dmesg:
> 
> (XEN) I/O virtualisation enabled
> 
> (XEN) Intel VT-d Snoop Control supported.(XEN) Intel VT-d DMA
> Passthrough not supported.(XEN) Intel VT-d Queued Invalidation
> supported.(XEN) Intel VT-d Interrupt Remapping not supported.
> 
> But I dont think I have this message (I am not near my system now, so I can
> not confirm)
> 
> (XEN) I/O virtualisation for PV guests enabled
> 
> 
> I believe that many have managed to get VGA passthru working, but they
> generally dont post their stories. one only finds the problems they are
> encountering when searching about this. That is why it would be nice to put
> together a kind of manual in the wiki which would have all this info
> together in one location.

http://lmgtfy.com/?q=Xen+VGA+passthrough

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 02:01:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 02:01:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpVgv-0001cA-Tl; Tue, 24 Jan 2012 02:00:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe@perches.com>) id 1RpVgu-0001bx-A4
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 02:00:56 +0000
X-Env-Sender: joe@perches.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327370448!12094482!1
X-Originating-IP: [206.117.179.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24394 invoked from network); 24 Jan 2012 02:00:49 -0000
Received: from perches-mx.perches.com (HELO labridge.com) (206.117.179.246)
	by server-10.tower-182.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	24 Jan 2012 02:00:49 -0000
Received: from [173.60.85.8] (account joe@perches.com HELO [192.168.1.162])
	by labridge.com (CommuniGate Pro SMTP 5.0.14)
	with ESMTPA id 18699371; Mon, 23 Jan 2012 18:00:32 -0800
Message-ID: <1327370429.20805.4.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Mon, 23 Jan 2012 18:00:29 -0800
In-Reply-To: <20120124014717.GA24204@andromeda.dapyr.net>
References: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
	<20120124014717.GA24204@andromeda.dapyr.net>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Andy Whitcroft <apw@canonical.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] include/checkpatch: Prefer __scanf to
 __attribute__((format(scanf, ...)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 21:47 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 20, 2012 at 04:01:12PM -0800, Joe Perches wrote:
> > It's equivalent to __printf, so prefer __scanf.
> So ... looking at this patch it just seems to macro-fy the
> __printf and __scanf attributes.

It's just for __scanf.  The __printf change is just
a neatening/spacing change.

> Is this required to make
> cleanpatch.pl work easier?

No.  It's a trivial symmetry patch added to
make fewer uses of __attribute__((format(...)
similar to the __printf commit from awhile ago.

commit b9075fa968a0a4347aef35e235e2995c0e57dddd

> And there is also some checkpatch.pl features. Should that part
> be in a seperate patch?

I think it's OK to do the whole thing at once.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 02:01:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 02:01:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpVgv-0001cA-Tl; Tue, 24 Jan 2012 02:00:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <joe@perches.com>) id 1RpVgu-0001bx-A4
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 02:00:56 +0000
X-Env-Sender: joe@perches.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327370448!12094482!1
X-Originating-IP: [206.117.179.246]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24394 invoked from network); 24 Jan 2012 02:00:49 -0000
Received: from perches-mx.perches.com (HELO labridge.com) (206.117.179.246)
	by server-10.tower-182.messagelabs.com with DES-CBC3-SHA encrypted SMTP;
	24 Jan 2012 02:00:49 -0000
Received: from [173.60.85.8] (account joe@perches.com HELO [192.168.1.162])
	by labridge.com (CommuniGate Pro SMTP 5.0.14)
	with ESMTPA id 18699371; Mon, 23 Jan 2012 18:00:32 -0800
Message-ID: <1327370429.20805.4.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Date: Mon, 23 Jan 2012 18:00:29 -0800
In-Reply-To: <20120124014717.GA24204@andromeda.dapyr.net>
References: <2cf7ddd75001233e79e928c4dcfae6768af5790c.1327103792.git.joe@perches.com>
	<20120124014717.GA24204@andromeda.dapyr.net>
X-Mailer: Evolution 3.2.2- 
Mime-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org,
	Andy Whitcroft <apw@canonical.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [Xen-devel] [PATCH] include/checkpatch: Prefer __scanf to
 __attribute__((format(scanf, ...)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 21:47 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 20, 2012 at 04:01:12PM -0800, Joe Perches wrote:
> > It's equivalent to __printf, so prefer __scanf.
> So ... looking at this patch it just seems to macro-fy the
> __printf and __scanf attributes.

It's just for __scanf.  The __printf change is just
a neatening/spacing change.

> Is this required to make
> cleanpatch.pl work easier?

No.  It's a trivial symmetry patch added to
make fewer uses of __attribute__((format(...)
similar to the __printf commit from awhile ago.

commit b9075fa968a0a4347aef35e235e2995c0e57dddd

> And there is also some checkpatch.pl features. Should that part
> be in a seperate patch?

I think it's OK to do the whole thing at once.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 02:16:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 02:16:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpVvL-0001n4-Be; Tue, 24 Jan 2012 02:15:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RpVvK-0001mw-1s
	for Xen-devel@lists.xensource.com; Tue, 24 Jan 2012 02:15:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327371342!13616613!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5ODcyMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32154 invoked from network); 24 Jan 2012 02:15:43 -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; 24 Jan 2012 02:15:43 -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
	q0O2Er0L028669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 02:14:55 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
	q0O2EpLs017757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jan 2012 02:14:51 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
	q0O2Eo7u026532; Mon, 23 Jan 2012 20:14:50 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 18:14:50 -0800
Date: Mon, 23 Jan 2012 18:14:47 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120123181447.40ef747c@mantra.us.oracle.com>
In-Reply-To: <20120123164316.GA22488@andromeda.dapyr.net>
References: <20120120172932.3dd3f5ac@mantra.us.oracle.com>
	<20120123164316.GA22488@andromeda.dapyr.net>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F1E141F.0037,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Ques]:xen_ident_map_ISA ant it's 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

On Mon, 23 Jan 2012 12:43:17 -0400
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:

> On Fri, Jan 20, 2012 at 05:29:32PM -0800, Mukesh Rathor wrote:
> > Hi,
> > 
> > I am bit confused about the do_update_va_mapping call that dom0
> > makes in xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The
> > mfn belongs to DOMID_IO. Before the mfn is mapped, the l1 entry is
> > not empty:
> > 
> > 0000000139d08500:  00100001380a0027
> > 
> > After the mapping:
> > 
> > 0000000139d08500:  00100000000a0467  as expected.
> > 
> > However, the mfn 1380a0 still seems to belong to dom0. Shouldn't
> > that have been returned back to the xen heap? 
> 
> It should if dom0 had returned it back. The setup.c code you where
> it returns the swatches of memory has a check where it decides to
> return only memory above 1M. The <1MB is left unused.
> 
> In other words, we make all the PTE's to the look as if PFN are
> 1:1 to MFN. But if you do a MFN lookup to PFN (mfn_to_pfn) for the
> regions below 1MB, you end up getting PFNs that are _not_ in the 1MB
> region. Instead they are just normal memory.
> 
> There is a good reason for this, which if I remeber right is to allow
> fixmap to work correctly, but if you are using ioremap it would return
> empty RAM so that most of the PnP devices (like RTC) would not load.
> 
> hmm, I think so . I remember thinking to remove that once (so allow
> the <1MB region to be freed), and I hit some pretty big problems.
> 
> Is there a particular reason you want to "Free" that memory?

I am not trying to "free" it. It just occured to me the old frames are
never used, 1380a0 in the above case.

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 02:16:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 02:16:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpVvL-0001n4-Be; Tue, 24 Jan 2012 02:15:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mukesh.rathor@oracle.com>) id 1RpVvK-0001mw-1s
	for Xen-devel@lists.xensource.com; Tue, 24 Jan 2012 02:15:50 +0000
X-Env-Sender: mukesh.rathor@oracle.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327371342!13616613!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDQ5ODcyMA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32154 invoked from network); 24 Jan 2012 02:15:43 -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; 24 Jan 2012 02:15:43 -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
	q0O2Er0L028669
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 02:14:55 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
	q0O2EpLs017757
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jan 2012 02:14:51 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
	q0O2Eo7u026532; Mon, 23 Jan 2012 20:14:50 -0600
Received: from mantra.us.oracle.com (/130.35.68.95)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 23 Jan 2012 18:14:50 -0800
Date: Mon, 23 Jan 2012 18:14:47 -0800
From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Message-ID: <20120123181447.40ef747c@mantra.us.oracle.com>
In-Reply-To: <20120123164316.GA22488@andromeda.dapyr.net>
References: <20120120172932.3dd3f5ac@mantra.us.oracle.com>
	<20120123164316.GA22488@andromeda.dapyr.net>
Organization: Oracle Corporation
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F1E141F.0037,ss=1,re=0.000,fgs=0
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [Ques]:xen_ident_map_ISA ant it's 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

On Mon, 23 Jan 2012 12:43:17 -0400
Konrad Rzeszutek Wilk <konrad@darnok.org> wrote:

> On Fri, Jan 20, 2012 at 05:29:32PM -0800, Mukesh Rathor wrote:
> > Hi,
> > 
> > I am bit confused about the do_update_va_mapping call that dom0
> > makes in xen_ident_map_ISA() to map ffff8800000a0000 to mfn a0. The
> > mfn belongs to DOMID_IO. Before the mfn is mapped, the l1 entry is
> > not empty:
> > 
> > 0000000139d08500:  00100001380a0027
> > 
> > After the mapping:
> > 
> > 0000000139d08500:  00100000000a0467  as expected.
> > 
> > However, the mfn 1380a0 still seems to belong to dom0. Shouldn't
> > that have been returned back to the xen heap? 
> 
> It should if dom0 had returned it back. The setup.c code you where
> it returns the swatches of memory has a check where it decides to
> return only memory above 1M. The <1MB is left unused.
> 
> In other words, we make all the PTE's to the look as if PFN are
> 1:1 to MFN. But if you do a MFN lookup to PFN (mfn_to_pfn) for the
> regions below 1MB, you end up getting PFNs that are _not_ in the 1MB
> region. Instead they are just normal memory.
> 
> There is a good reason for this, which if I remeber right is to allow
> fixmap to work correctly, but if you are using ioremap it would return
> empty RAM so that most of the PnP devices (like RTC) would not load.
> 
> hmm, I think so . I remember thinking to remove that once (so allow
> the <1MB region to be freed), and I hit some pretty big problems.
> 
> Is there a particular reason you want to "Free" that memory?

I am not trying to "free" it. It just occured to me the old frames are
never used, 1380a0 in the above case.

thanks,
Mukesh



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 04:17:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 04: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 1RpXoD-0002wr-BO; Tue, 24 Jan 2012 04:16:37 +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 1RpXoB-0002wj-6P; Tue, 24 Jan 2012 04:16:35 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327369764!58128072!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9096 invoked from network); 24 Jan 2012 01:49:25 -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; 24 Jan 2012 01:49: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
	q0O1oLtf024386
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:50:21 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1oLD9024384;
	Mon, 23 Jan 2012 20:50:21 -0500
Date: Mon, 23 Jan 2012 21:50:21 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120124015021.GB24204@andromeda.dapyr.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201201231417.43018.tobias.geiger@vido.info>
User-Agent: Mutt/1.5.9i
Cc: Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	xen-devel@lists.xensource.com,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> Hello!
> 
> The thing is, you either dont need patches at all to get it to work (ATI), or 
> you need to customize patches reflecting your individual setup (NVIDIA);
> 
> To be more specific:
> I can confirm that passing through a ATI Card works "out of the box" - either 
> to Windows 7 or Windows XP;
> In the past i had a setup running with a NVIDIA card, it only worked with 
> special patches (the ones David packed together and offers as tarball) and - as 
> far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you 
> have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then the 
> passed through Card worked only with Windows XP - NOT with Windows 7;
> 
> Both setup have the "flaw" that they only work once - meaning you can't reboot 
> your DomU , cause after the reboot the passed-through Card doesnt have correct 
> 3D-Accelleration any more (was/is the case with NVIDIA and ATI, Windows XP and 
> Windows7 )

For me it was with ATI with Windows7. Hadn't tried other OSes.

Anybody had luck with passing the card more than once to a guest? With
any random set of patches?
> 
> So - to summarize: It works easiest and most featureful with a ATI Card; 
>                             It may work with patches and only with WindowsXP 
> with an NVIDIA card
> 
> To me it seems that unless someone finds an general approach to runtime-detect 
> the NVIDIA-Secific stuff , submitting any patches may be to early, as it arouses 
> expectations which only in some cases will be met.

> 
> That said - i gladly can forward-port these old patches, if you think they are 
> helping in any way.
> 
> Greetings!
> Tobias
> 
> Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
> > Please do not a) top-post or b) cross-post. The latter being aimed at
> > whoever started this thread.
> > 
> > On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
> > > Yeah, I guess xen has generally been focused on the server end.
> > 
> > Xen is focused on whatever people submit patches to do. Many of the core
> > developers are not currently looking at VGA passthrough, we have plenty
> > of stuff on our plates, but we are more than happy to review and accept
> > patches to implement/improve/fix this feature if only those people who
> > are interested in it would take the time to submit them per
> > http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
> > going to go out hunting for patches on the Internet.
> > 
> > David Techer recently offered to do this but perhaps he would be
> > interested in some help from you?
> > 
> > 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 04:17:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 04: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 1RpXoD-0002wr-BO; Tue, 24 Jan 2012 04:16:37 +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 1RpXoB-0002wj-6P; Tue, 24 Jan 2012 04:16:35 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327369764!58128072!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9096 invoked from network); 24 Jan 2012 01:49:25 -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; 24 Jan 2012 01:49: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
	q0O1oLtf024386
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 23 Jan 2012 20:50:21 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0O1oLD9024384;
	Mon, 23 Jan 2012 20:50:21 -0500
Date: Mon, 23 Jan 2012 21:50:21 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Tobias Geiger <tobias.geiger@vido.info>
Message-ID: <20120124015021.GB24204@andromeda.dapyr.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201201231417.43018.tobias.geiger@vido.info>
User-Agent: Mutt/1.5.9i
Cc: Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	xen-devel@lists.xensource.com,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> Hello!
> 
> The thing is, you either dont need patches at all to get it to work (ATI), or 
> you need to customize patches reflecting your individual setup (NVIDIA);
> 
> To be more specific:
> I can confirm that passing through a ATI Card works "out of the box" - either 
> to Windows 7 or Windows XP;
> In the past i had a setup running with a NVIDIA card, it only worked with 
> special patches (the ones David packed together and offers as tarball) and - as 
> far as i can tell - are not generaly working for all NVIDIA Cards, i.e. you 
> have to adjust Memory-Adresses in the acpi.dst (iirc). - and even then the 
> passed through Card worked only with Windows XP - NOT with Windows 7;
> 
> Both setup have the "flaw" that they only work once - meaning you can't reboot 
> your DomU , cause after the reboot the passed-through Card doesnt have correct 
> 3D-Accelleration any more (was/is the case with NVIDIA and ATI, Windows XP and 
> Windows7 )

For me it was with ATI with Windows7. Hadn't tried other OSes.

Anybody had luck with passing the card more than once to a guest? With
any random set of patches?
> 
> So - to summarize: It works easiest and most featureful with a ATI Card; 
>                             It may work with patches and only with WindowsXP 
> with an NVIDIA card
> 
> To me it seems that unless someone finds an general approach to runtime-detect 
> the NVIDIA-Secific stuff , submitting any patches may be to early, as it arouses 
> expectations which only in some cases will be met.

> 
> That said - i gladly can forward-port these old patches, if you think they are 
> helping in any way.
> 
> Greetings!
> Tobias
> 
> Am Montag, 23. Januar 2012, 12:39:38 schrieb Ian Campbell:
> > Please do not a) top-post or b) cross-post. The latter being aimed at
> > whoever started this thread.
> > 
> > On Mon, 2012-01-23 at 11:25 +0000, Sandi Romih wrote:
> > > Yeah, I guess xen has generally been focused on the server end.
> > 
> > Xen is focused on whatever people submit patches to do. Many of the core
> > developers are not currently looking at VGA passthrough, we have plenty
> > of stuff on our plates, but we are more than happy to review and accept
> > patches to implement/improve/fix this feature if only those people who
> > are interested in it would take the time to submit them per
> > http://wiki.xen.org/wiki/SubmittingXenPatches . I'm afraid we are not
> > going to go out hunting for patches on the Internet.
> > 
> > David Techer recently offered to do this but perhaps he would be
> > interested in some help from you?
> > 
> > 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 04:53:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 04:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpYMt-0003NW-Pm; Tue, 24 Jan 2012 04:52:27 +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 1RpYMs-0003NR-1U
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 04:52:26 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327380688!53769302!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMTgx\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMTgx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8925 invoked from network); 24 Jan 2012 04:51:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-3.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 04:51:29 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 934FB458081;
	Mon, 23 Jan 2012 20:52: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=MCDcr73WZbHpR9YzpDKfY618O4wsECWJ/iUpN8uDXsxv
	Kz6vAF4l0TtAgmr2iwwKZMpzr1SdslRbLDkWGFMAVjUhOoWP8B3LlcF7cpAAYfUz
	cOtNNinh4e0qJxWafJWaBrjWfhI4TuZ2pWybxw37/t2XwvGII73QJUlqnClkSMI=
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=MX7DBkb7UnpshuwWnaisnuXBiYE=; b=KLk/TyGB
	x7U2malFsRUdPo98XiEVZreZVKX8aWXwELptiWaZd/YxYarpVQK1Lon/EMBVxHA4
	NyKdLu7Ib0H3nYlDUPM29XGOqypgFANF+vd60FadcG9c6xSkXqhYFPxOT+aOttfu
	sOGX5wG076xFzBzal4GwlPZFrOPhIvxs/WM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 068C4458080; 
	Mon, 23 Jan 2012 20:52:20 -0800 (PST)
Received: from 69.196.173.90 (proxying for 69.196.173.90)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 23 Jan 2012 20:52:20 -0800
Message-ID: <f890bfdfa94240a5e92cd7b8bbd5ce4f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120124014144.GA23702@andromeda.dapyr.net>
References: <mailman.1214.1327325228.1471.xen-devel@lists.xensource.com>
	<2354ea8a6f50d7f7703369aac0ed80a2.squirrel@webmail.lagarcavilla.org>
	<20120124014144.GA23702@andromeda.dapyr.net>
Date: Mon, 23 Jan 2012 20:52: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: xen-devel@lists.xensource.com, ian.campbell@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] Xen 4.2 TODO List
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, Jan 23, 2012 at 07:03:09AM -0800, Andres Lagar-Cavilla wrote:
>> > Date: Mon, 23 Jan 2012 13:19:05 +0000
>> > From: Ian Campbell <Ian.Campbell@citrix.com>
>> > To: xen-devel <xen-devel@lists.xensource.com>
>> > Subject: [Xen-devel] Xen 4.2 TODO List Update
>> > Message-ID: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
>> > Content-Type: text/plain; charset="UTF-8"
>> >
>> > Newly updated list follows. Please send me corrections (especially
>> > "done"). I've stopped CCing everyone, since I guess it is mostly spam
>> to
>> > the majority.
>> >
>> > hypervisor, blockers:
>> >
>> >       * round-up of the closing of the security hole in MSI-X
>> >         passthrough (uniformly - i.e. even for Dom0 - disallowing
>> write
>> >         access to MSI-X table pages). (Jan Beulich -- more fixes
>> >         required than first thought, patches posted)
>> >       * domctls / sysctls set up to modify scheduler parameters, like
>> >         the credit1 timeslice and schedule rate. (George Dunlap)
>> >       * get the interface changes for sharing/paging/mem-events done
>> and
>> >         dusted so that 4.2 is a stable API that we hold to. (Tim
>> Deegan,
>> >         Andres Lagar-Cavilla et al)
>> >               * mem event ring management posted, seems close to going
>> >                 in.
>> Mem event ring management has gone in, so you can chalk it off the list.
>
> Any progress on the pvops side of this? This is the -EBUSY patches
> right?

Actually, this is something quite different -- making sure that when the
hypervisor needs to kick the pager into action no events get lost.

On the pvops kernel we need to make sure backends wait for that pager to
get things right. And we halted that for a little while, after your
exchanges with Adin by the end of the year. But we'll be back with the
scheduled programming after the short break ;)

Cheers,
Andres
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 04:53:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 04:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpYMt-0003NW-Pm; Tue, 24 Jan 2012 04:52:27 +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 1RpYMs-0003NR-1U
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 04:52:26 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327380688!53769302!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMTgx\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMTgx\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8925 invoked from network); 24 Jan 2012 04:51:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.81) by server-3.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 04:51:29 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 934FB458081;
	Mon, 23 Jan 2012 20:52: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=MCDcr73WZbHpR9YzpDKfY618O4wsECWJ/iUpN8uDXsxv
	Kz6vAF4l0TtAgmr2iwwKZMpzr1SdslRbLDkWGFMAVjUhOoWP8B3LlcF7cpAAYfUz
	cOtNNinh4e0qJxWafJWaBrjWfhI4TuZ2pWybxw37/t2XwvGII73QJUlqnClkSMI=
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=MX7DBkb7UnpshuwWnaisnuXBiYE=; b=KLk/TyGB
	x7U2malFsRUdPo98XiEVZreZVKX8aWXwELptiWaZd/YxYarpVQK1Lon/EMBVxHA4
	NyKdLu7Ib0H3nYlDUPM29XGOqypgFANF+vd60FadcG9c6xSkXqhYFPxOT+aOttfu
	sOGX5wG076xFzBzal4GwlPZFrOPhIvxs/WM=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 068C4458080; 
	Mon, 23 Jan 2012 20:52:20 -0800 (PST)
Received: from 69.196.173.90 (proxying for 69.196.173.90)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Mon, 23 Jan 2012 20:52:20 -0800
Message-ID: <f890bfdfa94240a5e92cd7b8bbd5ce4f.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120124014144.GA23702@andromeda.dapyr.net>
References: <mailman.1214.1327325228.1471.xen-devel@lists.xensource.com>
	<2354ea8a6f50d7f7703369aac0ed80a2.squirrel@webmail.lagarcavilla.org>
	<20120124014144.GA23702@andromeda.dapyr.net>
Date: Mon, 23 Jan 2012 20:52: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: xen-devel@lists.xensource.com, ian.campbell@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] Xen 4.2 TODO List
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, Jan 23, 2012 at 07:03:09AM -0800, Andres Lagar-Cavilla wrote:
>> > Date: Mon, 23 Jan 2012 13:19:05 +0000
>> > From: Ian Campbell <Ian.Campbell@citrix.com>
>> > To: xen-devel <xen-devel@lists.xensource.com>
>> > Subject: [Xen-devel] Xen 4.2 TODO List Update
>> > Message-ID: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
>> > Content-Type: text/plain; charset="UTF-8"
>> >
>> > Newly updated list follows. Please send me corrections (especially
>> > "done"). I've stopped CCing everyone, since I guess it is mostly spam
>> to
>> > the majority.
>> >
>> > hypervisor, blockers:
>> >
>> >       * round-up of the closing of the security hole in MSI-X
>> >         passthrough (uniformly - i.e. even for Dom0 - disallowing
>> write
>> >         access to MSI-X table pages). (Jan Beulich -- more fixes
>> >         required than first thought, patches posted)
>> >       * domctls / sysctls set up to modify scheduler parameters, like
>> >         the credit1 timeslice and schedule rate. (George Dunlap)
>> >       * get the interface changes for sharing/paging/mem-events done
>> and
>> >         dusted so that 4.2 is a stable API that we hold to. (Tim
>> Deegan,
>> >         Andres Lagar-Cavilla et al)
>> >               * mem event ring management posted, seems close to going
>> >                 in.
>> Mem event ring management has gone in, so you can chalk it off the list.
>
> Any progress on the pvops side of this? This is the -EBUSY patches
> right?

Actually, this is something quite different -- making sure that when the
hypervisor needs to kick the pager into action no events get lost.

On the pvops kernel we need to make sure backends wait for that pager to
get things right. And we halted that for a little while, after your
exchanges with Adin by the end of the year. But we'll be back with the
scheduled programming after the short break ;)

Cheers,
Andres
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 05:52:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 05: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 1RpZIK-0004PS-Cw; Tue, 24 Jan 2012 05:51:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpZIJ-0004PK-AG
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 05:51:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327384300!11719394!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzkwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16290 invoked from network); 24 Jan 2012 05:51:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 05:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,560,1320624000"; d="scan'208";a="10237116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 05:51:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 05:51: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 1RpZIB-0005JX-Qv;
	Tue, 24 Jan 2012 05:51:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RpZIB-0005LO-Ls;
	Tue, 24 Jan 2012 05:51:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11574-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Jan 2012 05:51:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11574: 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 11574 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11574/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win           7 windows-install             fail pass in 11561
 test-i386-i386-win            7 windows-install             fail pass in 11561
 test-amd64-i386-xend-winxpsp3  7 windows-install   fail in 11561 pass in 11574
 test-amd64-amd64-xl-win       7 windows-install    fail in 11561 pass in 11574
 test-amd64-amd64-win          7 windows-install    fail in 11561 pass in 11574

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 11561

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11561 never pass
 test-i386-i386-win           16 leak-check/check      fail in 11561 never pass

version targeted for testing:
 xen                  370924e204dc
baseline version:
 xen                  370924e204dc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Tue Jan 24 05:52:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 05: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 1RpZIK-0004PS-Cw; Tue, 24 Jan 2012 05:51:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpZIJ-0004PK-AG
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 05:51:47 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327384300!11719394!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzkwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16290 invoked from network); 24 Jan 2012 05:51:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 05:51:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,560,1320624000"; d="scan'208";a="10237116"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 05:51:40 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 05:51: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 1RpZIB-0005JX-Qv;
	Tue, 24 Jan 2012 05:51:39 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RpZIB-0005LO-Ls;
	Tue, 24 Jan 2012 05:51:39 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11574-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Jan 2012 05:51:39 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11574: 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 11574 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11574/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-win           7 windows-install             fail pass in 11561
 test-i386-i386-win            7 windows-install             fail pass in 11561
 test-amd64-i386-xend-winxpsp3  7 windows-install   fail in 11561 pass in 11574
 test-amd64-amd64-xl-win       7 windows-install    fail in 11561 pass in 11574
 test-amd64-amd64-win          7 windows-install    fail in 11561 pass in 11574

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-win-vcpus1    7 windows-install              fail   like 11561

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11561 never pass
 test-i386-i386-win           16 leak-check/check      fail in 11561 never pass

version targeted for testing:
 xen                  370924e204dc
baseline version:
 xen                  370924e204dc

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Tue Jan 24 06:01:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 06:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpZQv-0004dR-5e; Tue, 24 Jan 2012 06:00:41 +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 1RpZQu-0004cv-02
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 06:00:40 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327384832!10400874!2
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26267 invoked from network); 24 Jan 2012 06:00:33 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 06:00:33 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=cgzcjAncfQcmJ1atns087lWcLagqAbiU6t98ZXq6pTvEVHELQ7w2YatY
	5M0Q1sK8kW4OaSILa2eBZpuLNajwMj2zJJUk3IGU0iEi3Wz0AqDQL4jaU
	AGYd+raUHbNj05a61QS6E0J+3qVG1144oqVtHRMsDKZWniP0L1RbuS39W
	8kkkgz1SB0sR5s4cnCkW0oCdZrFqJggi2TW5HpL7N2IeEWUi7dZeWjCkt
	ZzIrhTTzxjLE2uSzafaXMFCIC3gZy;
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=1327384833; x=1358920833;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=zGC3224cVdcmZ+7JzoomfvwlBtOv84PpaCdK8qSTqx4=;
	b=N491dIypl1V7UABvOp3amdGpEUMQL+b38aOyT9WLDf0KDNF9oNHMUZaU
	x9BzzdxpAwOUboYQTPoPwWh/DsG3SOst4YOIBtDh5Adx38E3jAdTJpa1w
	e1APvsQ/DGU8oIzpRzYbdCe3SI//r5I7P8D+apNIJnImvkeINRW9x1l2d
	rxfRzmqoxbt7+nByBeoFLtjbQzk+AN86Myg3Ch+jUTn9rnBzg7KV8RyJt
	RaQYfbAuslTwg154Bgs3U06Cwbp8C;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,559,1320620400"; d="scan'208";a="99486544"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127616494"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 3741995AB6B;
	Tue, 24 Jan 2012 07:00:31 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============5631704230253884863=="
MIME-Version: 1.0
X-Mercurial-Node: 08232960ff4bed750d26e5f1ff53972fee9e0130
Message-Id: <08232960ff4bed750d26.1327384451@nehalem1>
In-Reply-To: <patchbomb.1327384449@nehalem1>
Date: Tue, 24 Jan 2012 06:54:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3] switch to dynamically allocated cpumask
	in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5631704230253884863==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

cpumasks should rather be allocated dynamically.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 8 insertions(+), 4 deletions(-)
xen/common/domain.c |   12 ++++++++----



--===============5631704230253884863==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327384410 -3600
# Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
# Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
switch to dynamically allocated cpumask in domain_update_node_affinity()

cpumasks should rather be allocated dynamically.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
--- a/xen/common/domain.c	Tue Jan 24 06:53:06 2012 +0100
+++ b/xen/common/domain.c	Tue Jan 24 06:53:30 2012 +0100
@@ -333,23 +333,27 @@ struct domain *domain_create(
 
 void domain_update_node_affinity(struct domain *d)
 {
-    cpumask_t cpumask;
+    cpumask_var_t cpumask;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
-    cpumask_clear(&cpumask);
+    if ( !zalloc_cpumask_var(&cpumask) )
+        return;
+
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+        cpumask_or(cpumask, cpumask, v->cpu_affinity);
 
     for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
+
+    free_cpumask_var(cpumask);
 }
 
 

--===============5631704230253884863==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5631704230253884863==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 06:01:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 06:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpZQv-0004dR-5e; Tue, 24 Jan 2012 06:00:41 +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 1RpZQu-0004cv-02
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 06:00:40 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327384832!10400874!2
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26267 invoked from network); 24 Jan 2012 06:00:33 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 06:00:33 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=cgzcjAncfQcmJ1atns087lWcLagqAbiU6t98ZXq6pTvEVHELQ7w2YatY
	5M0Q1sK8kW4OaSILa2eBZpuLNajwMj2zJJUk3IGU0iEi3Wz0AqDQL4jaU
	AGYd+raUHbNj05a61QS6E0J+3qVG1144oqVtHRMsDKZWniP0L1RbuS39W
	8kkkgz1SB0sR5s4cnCkW0oCdZrFqJggi2TW5HpL7N2IeEWUi7dZeWjCkt
	ZzIrhTTzxjLE2uSzafaXMFCIC3gZy;
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=1327384833; x=1358920833;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=zGC3224cVdcmZ+7JzoomfvwlBtOv84PpaCdK8qSTqx4=;
	b=N491dIypl1V7UABvOp3amdGpEUMQL+b38aOyT9WLDf0KDNF9oNHMUZaU
	x9BzzdxpAwOUboYQTPoPwWh/DsG3SOst4YOIBtDh5Adx38E3jAdTJpa1w
	e1APvsQ/DGU8oIzpRzYbdCe3SI//r5I7P8D+apNIJnImvkeINRW9x1l2d
	rxfRzmqoxbt7+nByBeoFLtjbQzk+AN86Myg3Ch+jUTn9rnBzg7KV8RyJt
	RaQYfbAuslTwg154Bgs3U06Cwbp8C;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,559,1320620400"; d="scan'208";a="99486544"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127616494"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 3741995AB6B;
	Tue, 24 Jan 2012 07:00:31 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============5631704230253884863=="
MIME-Version: 1.0
X-Mercurial-Node: 08232960ff4bed750d26e5f1ff53972fee9e0130
Message-Id: <08232960ff4bed750d26.1327384451@nehalem1>
In-Reply-To: <patchbomb.1327384449@nehalem1>
Date: Tue, 24 Jan 2012 06:54:11 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3] switch to dynamically allocated cpumask
	in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5631704230253884863==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

cpumasks should rather be allocated dynamically.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 8 insertions(+), 4 deletions(-)
xen/common/domain.c |   12 ++++++++----



--===============5631704230253884863==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327384410 -3600
# Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
# Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
switch to dynamically allocated cpumask in domain_update_node_affinity()

cpumasks should rather be allocated dynamically.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
--- a/xen/common/domain.c	Tue Jan 24 06:53:06 2012 +0100
+++ b/xen/common/domain.c	Tue Jan 24 06:53:30 2012 +0100
@@ -333,23 +333,27 @@ struct domain *domain_create(
 
 void domain_update_node_affinity(struct domain *d)
 {
-    cpumask_t cpumask;
+    cpumask_var_t cpumask;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
-    cpumask_clear(&cpumask);
+    if ( !zalloc_cpumask_var(&cpumask) )
+        return;
+
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+        cpumask_or(cpumask, cpumask, v->cpu_affinity);
 
     for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
+
+    free_cpumask_var(cpumask);
 }
 
 

--===============5631704230253884863==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5631704230253884863==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 06:01:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 06:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpZQv-0004dY-HY; Tue, 24 Jan 2012 06:00:41 +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 1RpZQu-0004cw-3I
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 06:00:40 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327384832!10400874!3
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26277 invoked from network); 24 Jan 2012 06:00:33 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 06:00:33 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=R1Mv/gJ/7rcR0jIG1BQsHYUM9h1mB8WQpn/JOB1ZYLqVP62hmBON6MPz
	pQJDYncHfnGuz/BT9HqKP8Y1MjhErqIZ5SHfeWUe7F82rS+6O8YPcGDv/
	j7QNL4ZxCbom9cI3WUv8+i1CAdfAgkq3jFOeh2i6LI/Lu3uRw0oHH8/No
	8s6I+lm3R67EWuvbADbyq5IdxKzWrQ2EJ/phfKFAvu6OrRaxTaUqjziqR
	nzy5GSqZG4iSjIuzsRplNKhsetBZ4;
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=1327384833; x=1358920833;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=ZmbzLDOFuxjgvFmqvBBiPZDe07Zn5eYisVtIWDFL0CE=;
	b=Ya24u/oAQaXLfkIrvbzAB62j3lY8w8adCQ/dk9vj89XNBWURQ6ARQUc3
	PqhOZ5XG0I0I2vu7q88lT+nv28grYmk1LWyKNqKLSzZWho8gQR5KVDeKm
	NLUVBVcFOgPrK0dPW1PaTMb9drOdVVeuE9E4HxDfM+Bju5k5cgHYRHZpp
	qFPZpNicb/8Ivf5P3xf01N4mqxZDnBxKDnOqVBCr+jGKNc67HhIFEhrdp
	ASb29iSVUilVm17hVe/1aknbMaYem;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,559,1320620400"; d="scan'208";a="99486545"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127616495"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 423AF960CF6;
	Tue, 24 Jan 2012 07:00:31 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============3437071407843130718=="
MIME-Version: 1.0
X-Mercurial-Node: 574dba7570ff785d3351051a4a0a724c63066f57
Message-Id: <574dba7570ff785d3351.1327384452@nehalem1>
In-Reply-To: <patchbomb.1327384449@nehalem1>
Date: Tue, 24 Jan 2012 06:54:12 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3] reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3437071407843130718==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com


3 files changed, 27 insertions(+), 8 deletions(-)
xen/common/cpupool.c  |    9 +++++++++
xen/common/domain.c   |   16 +++++++++++++++-
xen/common/schedule.c |   10 +++-------



--===============3437071407843130718==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327384424 -3600
# Node ID 574dba7570ff785d3351051a4a0a724c63066f57
# Parent  08232960ff4bed750d26e5f1ff53972fee9e0130
reflect cpupool in numa node affinity

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 08232960ff4b -r 574dba7570ff xen/common/cpupool.c
--- a/xen/common/cpupool.c	Tue Jan 24 06:53:30 2012 +0100
+++ b/xen/common/cpupool.c	Tue Jan 24 06:53:44 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r 08232960ff4b -r 574dba7570ff xen/common/domain.c
--- a/xen/common/domain.c	Tue Jan 24 06:53:30 2012 +0100
+++ b/xen/common/domain.c	Tue Jan 24 06:53:44 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -334,17 +335,29 @@ void domain_update_node_affinity(struct 
 void domain_update_node_affinity(struct domain *d)
 {
     cpumask_var_t cpumask;
+    cpumask_var_t online_affinity;
+    const cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
     if ( !zalloc_cpumask_var(&cpumask) )
         return;
+    if ( !alloc_cpumask_var(&online_affinity) )
+    {
+        free_cpumask_var(cpumask);
+        return;
+    }
+
+    online = cpupool_online_cpumask(d->cpupool);
 
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(cpumask, cpumask, v->cpu_affinity);
+    {
+        cpumask_and(online_affinity, v->cpu_affinity, online);
+        cpumask_or(cpumask, cpumask, online_affinity);
+    }
 
     for_each_online_node ( node )
         if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
@@ -353,6 +366,7 @@ void domain_update_node_affinity(struct 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
 
+    free_cpumask_var(online_affinity);
     free_cpumask_var(cpumask);
 }
 
diff -r 08232960ff4b -r 574dba7570ff xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Jan 24 06:53:30 2012 +0100
+++ b/xen/common/schedule.c	Tue Jan 24 06:53:44 2012 +0100
@@ -280,11 +280,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -535,7 +536,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -543,8 +543,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -556,7 +554,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -580,8 +577,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;

--===============3437071407843130718==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3437071407843130718==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 06:01:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 06:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpZQv-0004dY-HY; Tue, 24 Jan 2012 06:00:41 +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 1RpZQu-0004cw-3I
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 06:00:40 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327384832!10400874!3
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26277 invoked from network); 24 Jan 2012 06:00:33 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 06:00:33 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=R1Mv/gJ/7rcR0jIG1BQsHYUM9h1mB8WQpn/JOB1ZYLqVP62hmBON6MPz
	pQJDYncHfnGuz/BT9HqKP8Y1MjhErqIZ5SHfeWUe7F82rS+6O8YPcGDv/
	j7QNL4ZxCbom9cI3WUv8+i1CAdfAgkq3jFOeh2i6LI/Lu3uRw0oHH8/No
	8s6I+lm3R67EWuvbADbyq5IdxKzWrQ2EJ/phfKFAvu6OrRaxTaUqjziqR
	nzy5GSqZG4iSjIuzsRplNKhsetBZ4;
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=1327384833; x=1358920833;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=ZmbzLDOFuxjgvFmqvBBiPZDe07Zn5eYisVtIWDFL0CE=;
	b=Ya24u/oAQaXLfkIrvbzAB62j3lY8w8adCQ/dk9vj89XNBWURQ6ARQUc3
	PqhOZ5XG0I0I2vu7q88lT+nv28grYmk1LWyKNqKLSzZWho8gQR5KVDeKm
	NLUVBVcFOgPrK0dPW1PaTMb9drOdVVeuE9E4HxDfM+Bju5k5cgHYRHZpp
	qFPZpNicb/8Ivf5P3xf01N4mqxZDnBxKDnOqVBCr+jGKNc67HhIFEhrdp
	ASb29iSVUilVm17hVe/1aknbMaYem;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,559,1320620400"; d="scan'208";a="99486545"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127616495"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 423AF960CF6;
	Tue, 24 Jan 2012 07:00:31 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============3437071407843130718=="
MIME-Version: 1.0
X-Mercurial-Node: 574dba7570ff785d3351051a4a0a724c63066f57
Message-Id: <574dba7570ff785d3351.1327384452@nehalem1>
In-Reply-To: <patchbomb.1327384449@nehalem1>
Date: Tue, 24 Jan 2012 06:54:12 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3] reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3437071407843130718==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com


3 files changed, 27 insertions(+), 8 deletions(-)
xen/common/cpupool.c  |    9 +++++++++
xen/common/domain.c   |   16 +++++++++++++++-
xen/common/schedule.c |   10 +++-------



--===============3437071407843130718==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327384424 -3600
# Node ID 574dba7570ff785d3351051a4a0a724c63066f57
# Parent  08232960ff4bed750d26e5f1ff53972fee9e0130
reflect cpupool in numa node affinity

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 08232960ff4b -r 574dba7570ff xen/common/cpupool.c
--- a/xen/common/cpupool.c	Tue Jan 24 06:53:30 2012 +0100
+++ b/xen/common/cpupool.c	Tue Jan 24 06:53:44 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r 08232960ff4b -r 574dba7570ff xen/common/domain.c
--- a/xen/common/domain.c	Tue Jan 24 06:53:30 2012 +0100
+++ b/xen/common/domain.c	Tue Jan 24 06:53:44 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -334,17 +335,29 @@ void domain_update_node_affinity(struct 
 void domain_update_node_affinity(struct domain *d)
 {
     cpumask_var_t cpumask;
+    cpumask_var_t online_affinity;
+    const cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
     if ( !zalloc_cpumask_var(&cpumask) )
         return;
+    if ( !alloc_cpumask_var(&online_affinity) )
+    {
+        free_cpumask_var(cpumask);
+        return;
+    }
+
+    online = cpupool_online_cpumask(d->cpupool);
 
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(cpumask, cpumask, v->cpu_affinity);
+    {
+        cpumask_and(online_affinity, v->cpu_affinity, online);
+        cpumask_or(cpumask, cpumask, online_affinity);
+    }
 
     for_each_online_node ( node )
         if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
@@ -353,6 +366,7 @@ void domain_update_node_affinity(struct 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
 
+    free_cpumask_var(online_affinity);
     free_cpumask_var(cpumask);
 }
 
diff -r 08232960ff4b -r 574dba7570ff xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Jan 24 06:53:30 2012 +0100
+++ b/xen/common/schedule.c	Tue Jan 24 06:53:44 2012 +0100
@@ -280,11 +280,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -535,7 +536,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -543,8 +543,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -556,7 +554,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -580,8 +577,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;

--===============3437071407843130718==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3437071407843130718==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 06:01:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 06: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 1RpZQu-0004dK-Q0; Tue, 24 Jan 2012 06:00:40 +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 1RpZQt-0004cu-FI
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 06:00:39 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327384832!10400874!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26259 invoked from network); 24 Jan 2012 06:00:33 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 06:00:33 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:
	Content-Transfer-Encoding:Subject:Message-Id:Date:From:To;
	b=hHMCfYdeLJ218mklRa8rlLNFz0NaXmfKdYwKFgOs9bsnL16xOgg9HDmF
	TdIfrOzmEDNqQOJhhVnAeIfTeE/E3/VUyrmbavIKZB+rKToa6J4pqTZJt
	hqqGRLOahTXhYMbfJRsfQrV7eohXTRrdRQ65oWq0InQELJ+Tc09u/0l31
	C3LfOrUDnIZnVTx2+tsHbuYI+UBzy8+bimxJTm/wNcnTaT3owaMANjHuY
	udE+Ca2s75YIuMijPtjw3+v2jLs8C;
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=1327384833; x=1358920833;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to;
	bh=ShRS8L77IO6JmBMCAqQ4KKyO3uWYDEzDK1nxaOXx+qk=;
	b=eVoNr6MWNjqlSmx5XT7FH/syn+NZRI3O87HJVJIZaAaPIZS76cjr4Vnf
	NrKFB27NdIZAMr6jG87xDg/xyyFGWeVME+9gfO9MCh0bp1wCJn5TvkilF
	WQg5ZDHOLonsut27C66r0koTPwpsu662CCjlGlcEhKkYhobire92Wq3eb
	wlrm92J41Zlv1L52zG6Bn34fcYrzg9pPr0C//QCPyIdAp21xsT+G2J7E+
	4gtUZvZLnumvfmEFSYo4aSS9IB/CP;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,559,1320620400"; d="scan'208";a="99486542"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127616493"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 06601960E89;
	Tue, 24 Jan 2012 07:00:31 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1327384449@nehalem1>
Date: Tue, 24 Jan 2012 06:54:09 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3] Reflect cpupool in numa node affinity
	(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

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Changes in v4:
- split in three patches

Changes in v3:
- formatting
- avoid memory leak

Changes in v2:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

8 files changed, 48 insertions(+), 28 deletions(-)
xen/common/cpupool.c       |    9 +++++++++
xen/common/domain.c        |   28 +++++++++++++++++++++++-----
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |   16 +++++-----------
xen/include/xen/sched-if.h |    5 +++++

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 06:01:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 06: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 1RpZQu-0004dK-Q0; Tue, 24 Jan 2012 06:00:40 +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 1RpZQt-0004cu-FI
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 06:00:39 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327384832!10400874!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26259 invoked from network); 24 Jan 2012 06:00:33 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 06:00:33 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:
	Content-Transfer-Encoding:Subject:Message-Id:Date:From:To;
	b=hHMCfYdeLJ218mklRa8rlLNFz0NaXmfKdYwKFgOs9bsnL16xOgg9HDmF
	TdIfrOzmEDNqQOJhhVnAeIfTeE/E3/VUyrmbavIKZB+rKToa6J4pqTZJt
	hqqGRLOahTXhYMbfJRsfQrV7eohXTRrdRQ65oWq0InQELJ+Tc09u/0l31
	C3LfOrUDnIZnVTx2+tsHbuYI+UBzy8+bimxJTm/wNcnTaT3owaMANjHuY
	udE+Ca2s75YIuMijPtjw3+v2jLs8C;
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=1327384833; x=1358920833;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to;
	bh=ShRS8L77IO6JmBMCAqQ4KKyO3uWYDEzDK1nxaOXx+qk=;
	b=eVoNr6MWNjqlSmx5XT7FH/syn+NZRI3O87HJVJIZaAaPIZS76cjr4Vnf
	NrKFB27NdIZAMr6jG87xDg/xyyFGWeVME+9gfO9MCh0bp1wCJn5TvkilF
	WQg5ZDHOLonsut27C66r0koTPwpsu662CCjlGlcEhKkYhobire92Wq3eb
	wlrm92J41Zlv1L52zG6Bn34fcYrzg9pPr0C//QCPyIdAp21xsT+G2J7E+
	4gtUZvZLnumvfmEFSYo4aSS9IB/CP;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,559,1320620400"; d="scan'208";a="99486542"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127616493"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 06601960E89;
	Tue, 24 Jan 2012 07:00:31 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1327384449@nehalem1>
Date: Tue, 24 Jan 2012 06:54:09 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3] Reflect cpupool in numa node affinity
	(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

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Changes in v4:
- split in three patches

Changes in v3:
- formatting
- avoid memory leak

Changes in v2:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

8 files changed, 48 insertions(+), 28 deletions(-)
xen/common/cpupool.c       |    9 +++++++++
xen/common/domain.c        |   28 +++++++++++++++++++++++-----
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |   16 +++++-----------
xen/include/xen/sched-if.h |    5 +++++

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 06:01:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 06: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 1RpZQu-0004d6-Cz; Tue, 24 Jan 2012 06:00:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpZQs-0004ct-By
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 06:00:38 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327384831!12111200!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDA3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4731 invoked from network); 24 Jan 2012 06:00:31 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 06:00:31 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=JR6dC0MFMct9+ABdVVJTz35k6CQzslSH+mYhy7kte7P5Vn07+Fbsnz7/
	jRug0ut4isimcB8ZmnuVX971PQw94v5wc2SdBoYSlUMQemx7P5DLwKVwH
	MSncVKMkW//BJ2mPc0wcJvqCjF3ZmmvMOwcMgvpmgQVz8/X1L9cLV1tet
	gJvURDJp4UJpe9NNxIoug71ncNs2ehxJDjLgjUh3r/m/q7aNE3PTULU5t
	bU/7KRUQlSDh6gLhNnHEa4ZhOuJDA;
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=1327384832; x=1358920832;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=3lJdgiYDHDXrIHYKf3AsYgVdLcaKlM3cnMxnuHP5lXk=;
	b=veOE1MCf3RrufXYhCP6GCoY4/7gUjhrCW8XYoKb1TzecWfj7bKN1H3pK
	EgV98TOELWs6lWib609bsRL4FH/CmZHLcaCWpOSjMACmsYwsDOjfozCJd
	RaPxXM50DW8i/ymDUbVV/aVfQP/tHFlz+M0dO1mFCLqCfHnsssZBLsiqR
	tI0/5PrDjR/KkMs71oSWPrpPAyDxJiO47OYYdUZX65+1YpF9mb1o1pvQR
	lQLs2PLTza5HnHIEfyapx/Z6mCp66;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="84316287"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127310336"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 1B162960E87;
	Tue, 24 Jan 2012 07:00:31 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============0149990694721582626=="
MIME-Version: 1.0
X-Mercurial-Node: 99f98e501f226825fbf16f6210b4b7834dff5df1
Message-Id: <99f98e501f226825fbf1.1327384450@nehalem1>
In-Reply-To: <patchbomb.1327384449@nehalem1>
Date: Tue, 24 Jan 2012 06:54:10 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3] introduce and use common macros for
	selecting cpupool	based cpumasks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0149990694721582626==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

There are several instances of the same construct finding the cpumask for a
cpupool. Use macros instead.

Signed-off-by: juergen.gross@ts.fujitsu.com


6 files changed, 13 insertions(+), 16 deletions(-)
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |    6 ++----
xen/include/xen/sched-if.h |    5 +++++



--===============0149990694721582626==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327384386 -3600
# Node ID 99f98e501f226825fbf16f6210b4b7834dff5df1
# Parent  370924e204dc29e12cd807dd730974d6b2bc53d3
introduce and use common macros for selecting cpupool based cpumasks

There are several instances of the same construct finding the cpumask for a
cpupool. Use macros instead.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 370924e204dc -r 99f98e501f22 xen/common/domctl.c
--- a/xen/common/domctl.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/domctl.c	Tue Jan 24 06:53:06 2012 +0100
@@ -518,7 +518,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             goto maxvcpu_out;
 
         ret = -ENOMEM;
-        online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
+        online = cpupool_online_cpumask(d->cpupool);
         if ( max > d->max_vcpus )
         {
             struct vcpu **vcpus;
diff -r 370924e204dc -r 99f98e501f22 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_credit.c	Tue Jan 24 06:53:06 2012 +0100
@@ -72,8 +72,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 
 /*
@@ -471,7 +469,7 @@ _csched_cpu_pick(const struct scheduler 
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
      */
-    online = CSCHED_CPUONLINE(vc->domain->cpupool);
+    online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
     cpu = cpumask_test_cpu(vc->processor, &cpus)
             ? vc->processor
@@ -1230,7 +1228,7 @@ csched_load_balance(struct csched_privat
     int peer_cpu;
 
     BUG_ON( cpu != snext->vcpu->processor );
-    online = CSCHED_CPUONLINE(per_cpu(cpupool, cpu));
+    online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
 
     /* If this CPU is going offline we shouldn't steal work. */
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
diff -r 370924e204dc -r 99f98e501f22 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_credit2.c	Tue Jan 24 06:53:06 2012 +0100
@@ -169,8 +169,6 @@ integer_param("sched_credit2_migrate_res
     ((struct csched_private *)((_ops)->sched_data))
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 /* CPU to runq_id macro */
 #define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
diff -r 370924e204dc -r 99f98e501f22 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_sedf.c	Tue Jan 24 06:53:06 2012 +0100
@@ -12,9 +12,6 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
-
-#define SEDF_CPUONLINE(_pool)                                             \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 #ifndef NDEBUG
 #define SEDF_STATS
@@ -397,7 +394,7 @@ static int sedf_pick_cpu(const struct sc
     cpumask_t online_affinity;
     cpumask_t *online;
 
-    online = SEDF_CPUONLINE(v->domain->cpupool);
+    online = cpupool_scheduler_cpumask(v->domain->cpupool);
     cpumask_and(&online_affinity, v->cpu_affinity, online);
     return cpumask_first(&online_affinity);
 }
@@ -801,7 +798,8 @@ static struct task_slice sedf_do_schedul
      */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
-         unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, cpu)))) )
+         unlikely(!cpumask_test_cpu(cpu,
+                   cpupool_scheduler_cpumask(per_cpu(cpupool, cpu)))) )
     {
         ret.task = IDLETASK(cpu);
         ret.time = SECONDS(1);
diff -r 370924e204dc -r 99f98e501f22 xen/common/schedule.c
--- a/xen/common/schedule.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/schedule.c	Tue Jan 24 06:53:06 2012 +0100
@@ -77,9 +77,7 @@ static struct scheduler __read_mostly op
 
 #define DOM2OP(_d)    (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched))
 #define VCPU2OP(_v)   (DOM2OP((_v)->domain))
-#define VCPU2ONLINE(_v)                                                    \
-         (((_v)->domain->cpupool == NULL) ? &cpu_online_map                \
-         : (_v)->domain->cpupool->cpu_valid)
+#define VCPU2ONLINE(_v) cpupool_online_cpumask((_v)->domain->cpupool)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)
 {
@@ -1418,7 +1416,7 @@ void schedule_dump(struct cpupool *c)
     cpumask_t        *cpus;
 
     sched = (c == NULL) ? &ops : c->sched;
-    cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
+    cpus = cpupool_scheduler_cpumask(c);
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
     SCHED_OP(sched, dump_settings);
 
diff -r 370924e204dc -r 99f98e501f22 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/include/xen/sched-if.h	Tue Jan 24 06:53:06 2012 +0100
@@ -204,4 +204,9 @@ struct cpupool
     atomic_t         refcnt;
 };
 
+#define cpupool_scheduler_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
+#define cpupool_online_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpu_online_map : (_pool)->cpu_valid)
+
 #endif /* __XEN_SCHED_IF_H__ */

--===============0149990694721582626==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0149990694721582626==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 06:01:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 06: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 1RpZQu-0004d6-Cz; Tue, 24 Jan 2012 06:00:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpZQs-0004ct-By
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 06:00:38 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327384831!12111200!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDA3NA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4731 invoked from network); 24 Jan 2012 06:00:31 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 06:00:31 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=JR6dC0MFMct9+ABdVVJTz35k6CQzslSH+mYhy7kte7P5Vn07+Fbsnz7/
	jRug0ut4isimcB8ZmnuVX971PQw94v5wc2SdBoYSlUMQemx7P5DLwKVwH
	MSncVKMkW//BJ2mPc0wcJvqCjF3ZmmvMOwcMgvpmgQVz8/X1L9cLV1tet
	gJvURDJp4UJpe9NNxIoug71ncNs2ehxJDjLgjUh3r/m/q7aNE3PTULU5t
	bU/7KRUQlSDh6gLhNnHEa4ZhOuJDA;
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=1327384832; x=1358920832;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=3lJdgiYDHDXrIHYKf3AsYgVdLcaKlM3cnMxnuHP5lXk=;
	b=veOE1MCf3RrufXYhCP6GCoY4/7gUjhrCW8XYoKb1TzecWfj7bKN1H3pK
	EgV98TOELWs6lWib609bsRL4FH/CmZHLcaCWpOSjMACmsYwsDOjfozCJd
	RaPxXM50DW8i/ymDUbVV/aVfQP/tHFlz+M0dO1mFCLqCfHnsssZBLsiqR
	tI0/5PrDjR/KkMs71oSWPrpPAyDxJiO47OYYdUZX65+1YpF9mb1o1pvQR
	lQLs2PLTza5HnHIEfyapx/Z6mCp66;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="84316287"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127310336"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 24 Jan 2012 07:00:31 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id 1B162960E87;
	Tue, 24 Jan 2012 07:00:31 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============0149990694721582626=="
MIME-Version: 1.0
X-Mercurial-Node: 99f98e501f226825fbf16f6210b4b7834dff5df1
Message-Id: <99f98e501f226825fbf1.1327384450@nehalem1>
In-Reply-To: <patchbomb.1327384449@nehalem1>
Date: Tue, 24 Jan 2012 06:54:10 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3] introduce and use common macros for
	selecting cpupool	based cpumasks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0149990694721582626==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

There are several instances of the same construct finding the cpumask for a
cpupool. Use macros instead.

Signed-off-by: juergen.gross@ts.fujitsu.com


6 files changed, 13 insertions(+), 16 deletions(-)
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |    6 ++----
xen/include/xen/sched-if.h |    5 +++++



--===============0149990694721582626==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327384386 -3600
# Node ID 99f98e501f226825fbf16f6210b4b7834dff5df1
# Parent  370924e204dc29e12cd807dd730974d6b2bc53d3
introduce and use common macros for selecting cpupool based cpumasks

There are several instances of the same construct finding the cpumask for a
cpupool. Use macros instead.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 370924e204dc -r 99f98e501f22 xen/common/domctl.c
--- a/xen/common/domctl.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/domctl.c	Tue Jan 24 06:53:06 2012 +0100
@@ -518,7 +518,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             goto maxvcpu_out;
 
         ret = -ENOMEM;
-        online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
+        online = cpupool_online_cpumask(d->cpupool);
         if ( max > d->max_vcpus )
         {
             struct vcpu **vcpus;
diff -r 370924e204dc -r 99f98e501f22 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_credit.c	Tue Jan 24 06:53:06 2012 +0100
@@ -72,8 +72,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 
 /*
@@ -471,7 +469,7 @@ _csched_cpu_pick(const struct scheduler 
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
      */
-    online = CSCHED_CPUONLINE(vc->domain->cpupool);
+    online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
     cpu = cpumask_test_cpu(vc->processor, &cpus)
             ? vc->processor
@@ -1230,7 +1228,7 @@ csched_load_balance(struct csched_privat
     int peer_cpu;
 
     BUG_ON( cpu != snext->vcpu->processor );
-    online = CSCHED_CPUONLINE(per_cpu(cpupool, cpu));
+    online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
 
     /* If this CPU is going offline we shouldn't steal work. */
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
diff -r 370924e204dc -r 99f98e501f22 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_credit2.c	Tue Jan 24 06:53:06 2012 +0100
@@ -169,8 +169,6 @@ integer_param("sched_credit2_migrate_res
     ((struct csched_private *)((_ops)->sched_data))
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 /* CPU to runq_id macro */
 #define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
diff -r 370924e204dc -r 99f98e501f22 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_sedf.c	Tue Jan 24 06:53:06 2012 +0100
@@ -12,9 +12,6 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
-
-#define SEDF_CPUONLINE(_pool)                                             \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 #ifndef NDEBUG
 #define SEDF_STATS
@@ -397,7 +394,7 @@ static int sedf_pick_cpu(const struct sc
     cpumask_t online_affinity;
     cpumask_t *online;
 
-    online = SEDF_CPUONLINE(v->domain->cpupool);
+    online = cpupool_scheduler_cpumask(v->domain->cpupool);
     cpumask_and(&online_affinity, v->cpu_affinity, online);
     return cpumask_first(&online_affinity);
 }
@@ -801,7 +798,8 @@ static struct task_slice sedf_do_schedul
      */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
-         unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, cpu)))) )
+         unlikely(!cpumask_test_cpu(cpu,
+                   cpupool_scheduler_cpumask(per_cpu(cpupool, cpu)))) )
     {
         ret.task = IDLETASK(cpu);
         ret.time = SECONDS(1);
diff -r 370924e204dc -r 99f98e501f22 xen/common/schedule.c
--- a/xen/common/schedule.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/schedule.c	Tue Jan 24 06:53:06 2012 +0100
@@ -77,9 +77,7 @@ static struct scheduler __read_mostly op
 
 #define DOM2OP(_d)    (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched))
 #define VCPU2OP(_v)   (DOM2OP((_v)->domain))
-#define VCPU2ONLINE(_v)                                                    \
-         (((_v)->domain->cpupool == NULL) ? &cpu_online_map                \
-         : (_v)->domain->cpupool->cpu_valid)
+#define VCPU2ONLINE(_v) cpupool_online_cpumask((_v)->domain->cpupool)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)
 {
@@ -1418,7 +1416,7 @@ void schedule_dump(struct cpupool *c)
     cpumask_t        *cpus;
 
     sched = (c == NULL) ? &ops : c->sched;
-    cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
+    cpus = cpupool_scheduler_cpumask(c);
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
     SCHED_OP(sched, dump_settings);
 
diff -r 370924e204dc -r 99f98e501f22 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/include/xen/sched-if.h	Tue Jan 24 06:53:06 2012 +0100
@@ -204,4 +204,9 @@ struct cpupool
     atomic_t         refcnt;
 };
 
+#define cpupool_scheduler_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
+#define cpupool_online_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpu_online_map : (_pool)->cpu_valid)
+
 #endif /* __XEN_SCHED_IF_H__ */

--===============0149990694721582626==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0149990694721582626==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 07:22:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 07:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpagv-00062L-FP; Tue, 24 Jan 2012 07:21:17 +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 1Rpagt-00062D-Vk
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 07:21:16 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327389669!8549022!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22228 invoked from network); 24 Jan 2012 07:21:09 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 07:21:09 -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=BFqSZfNMOIEvEchL/YNN1BEQQW7gQM3pEs5m7J/H1O5VeBWoGBNlMiYF
	29WthKa9Tv1Ju17f42QGU9hZwEqjtcqW58jLSngVOHEUygARvp9uUyX2+
	wHe8IhwzGahO7LtS1PjY014IH/NcHGCr5ODSA4y1Tx6yJPuffcM/p/jRY
	1gJWqsj3Ezn3E7I0+aeI6sjmg7lPXegFSSWuPzPDsrEY5ToEHBy+odMxh
	cQC/7KV+QKMXXWamP4Vuepoy/PK91;
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=1327389670; x=1358925670;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=wJpbEfyjoqYo+dDPEyfRQJ7OESmDmJ95cb4jFMR/GuY=;
	b=UE/8ANUYBtLNvzgbXejgcvK+VKJxMCFOCUB/ZUFrFaoY4J4g010AhDU9
	N8lqHf+NKWkmkOBgNtgKRRMvozzQjGoE+5heUMlWc79lNeVEl9IoVD9eB
	EKdFn52QB6hJp3eQg5LWhQaZjkzfyRajEKRDOLJCZueroClfdu7aby2NM
	aYwjN7L/TbSd28HnACQSZX4x08jDlWLyZ3Z122UHzOJBnyKbLQbHes1Gb
	x9j5kg1/niAzXEYL+FjzdyeM2cf1p;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="99492504"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 08:21:09 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127313627"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 24 Jan 2012 08:21:08 +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 CAAEC95C35B;
	Tue, 24 Jan 2012 08:21:08 +0100 (CET)
Message-ID: <4F1E5BE4.3010406@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 08:21:08 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
	<c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
In-Reply-To: <c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl:
	remove	libxl_domain_create_info.poolname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 03:43 PM, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1327329346 0
> # Node ID c91bee33280debdfe602d28e48318c03ddf0f4c9
> # Parent  4bb2b6a04ec02c3502c1825e2736df54870229e5
> libxl: remove libxl_domain_create_info.poolname
>
> It is redundant with poolid and allowing the user to specify both
> opens up the possibility of a disconnect.
>
> Also default c_info->poolid to -1 (no pool) instead of defaulting to 0 in the
> library and overriding in the toolstack.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
Acked-by: juergen.gross@ts.fujitsu.com
> diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri Jan 20 17:12:17 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Mon Jan 23 14:35:46 2012 +0000
> @@ -60,7 +60,7 @@ int libxl_init_create_info(libxl_ctx *ct
>       c_info->type = LIBXL_DOMAIN_TYPE_HVM;
>       c_info->oos = 1;
>       c_info->ssidref = 0;
> -    c_info->poolid = 0;
> +    c_info->poolid = -1;
>       return 0;
>   }
>
> @@ -438,8 +438,9 @@ retry_transaction:
>
>       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));
> -    if (info->poolname)
> -        xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/pool_name", vm_path), info->poolname, strlen(info->poolname));
> +    if (info->poolid != -1)
> +        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
> +                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
>
>       libxl__xs_writev(gc, t, dom_path, info->xsdata);
>       libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
> diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Fri Jan 20 17:12:17 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Mon Jan 23 14:35:46 2012 +0000
> @@ -156,7 +156,6 @@ libxl_domain_create_info = Struct("domai
>       ("xsdata",       libxl_key_value_list),
>       ("platformdata", libxl_key_value_list),
>       ("poolid",       uint32),
> -    ("poolname",     string),
>       ])
>
>   libxl_domain_build_info = Struct("domain_build_info",[
> diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Fri Jan 20 17:12:17 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:46 2012 +0000
> @@ -315,7 +315,7 @@ static void printf_info(int domid,
>           printf("\t(uuid<unknown>)\n");
>       }
>
> -    printf("\t(cpupool %s)\n", c_info->poolname);
> +    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
>       if (c_info->xsdata)
>           printf("\t(xsdata contains data)\n");
>       else
> @@ -640,11 +640,9 @@ static void parse_config_data(const char
>           c_info->oos = l;
>
>       if (!xlu_cfg_get_string (config, "pool",&buf, 0)) {
> -        c_info->poolid = -1;
>           cpupool_qualifier_to_cpupoolid(buf,&c_info->poolid, NULL);
>       }
> -    c_info->poolname = libxl_cpupoolid_to_name(ctx, c_info->poolid);
> -    if (!c_info->poolname) {
> +    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
>           fprintf(stderr, "Illegal pool specified\n");
>           exit(1);
>       }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 07:22:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 07:22:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpagv-00062L-FP; Tue, 24 Jan 2012 07:21:17 +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 1Rpagt-00062D-Vk
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 07:21:16 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327389669!8549022!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDEyMA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22228 invoked from network); 24 Jan 2012 07:21:09 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 07:21:09 -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=BFqSZfNMOIEvEchL/YNN1BEQQW7gQM3pEs5m7J/H1O5VeBWoGBNlMiYF
	29WthKa9Tv1Ju17f42QGU9hZwEqjtcqW58jLSngVOHEUygARvp9uUyX2+
	wHe8IhwzGahO7LtS1PjY014IH/NcHGCr5ODSA4y1Tx6yJPuffcM/p/jRY
	1gJWqsj3Ezn3E7I0+aeI6sjmg7lPXegFSSWuPzPDsrEY5ToEHBy+odMxh
	cQC/7KV+QKMXXWamP4Vuepoy/PK91;
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=1327389670; x=1358925670;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=wJpbEfyjoqYo+dDPEyfRQJ7OESmDmJ95cb4jFMR/GuY=;
	b=UE/8ANUYBtLNvzgbXejgcvK+VKJxMCFOCUB/ZUFrFaoY4J4g010AhDU9
	N8lqHf+NKWkmkOBgNtgKRRMvozzQjGoE+5heUMlWc79lNeVEl9IoVD9eB
	EKdFn52QB6hJp3eQg5LWhQaZjkzfyRajEKRDOLJCZueroClfdu7aby2NM
	aYwjN7L/TbSd28HnACQSZX4x08jDlWLyZ3Z122UHzOJBnyKbLQbHes1Gb
	x9j5kg1/niAzXEYL+FjzdyeM2cf1p;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="99492504"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 08:21:09 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127313627"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 24 Jan 2012 08:21:08 +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 CAAEC95C35B;
	Tue, 24 Jan 2012 08:21:08 +0100 (CET)
Message-ID: <4F1E5BE4.3010406@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 08:21:08 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
	<c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
In-Reply-To: <c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl:
	remove	libxl_domain_create_info.poolname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 03:43 PM, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1327329346 0
> # Node ID c91bee33280debdfe602d28e48318c03ddf0f4c9
> # Parent  4bb2b6a04ec02c3502c1825e2736df54870229e5
> libxl: remove libxl_domain_create_info.poolname
>
> It is redundant with poolid and allowing the user to specify both
> opens up the possibility of a disconnect.
>
> Also default c_info->poolid to -1 (no pool) instead of defaulting to 0 in the
> library and overriding in the toolstack.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
Acked-by: juergen.gross@ts.fujitsu.com
> diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Fri Jan 20 17:12:17 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Mon Jan 23 14:35:46 2012 +0000
> @@ -60,7 +60,7 @@ int libxl_init_create_info(libxl_ctx *ct
>       c_info->type = LIBXL_DOMAIN_TYPE_HVM;
>       c_info->oos = 1;
>       c_info->ssidref = 0;
> -    c_info->poolid = 0;
> +    c_info->poolid = -1;
>       return 0;
>   }
>
> @@ -438,8 +438,9 @@ retry_transaction:
>
>       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));
> -    if (info->poolname)
> -        xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/pool_name", vm_path), info->poolname, strlen(info->poolname));
> +    if (info->poolid != -1)
> +        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
> +                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
>
>       libxl__xs_writev(gc, t, dom_path, info->xsdata);
>       libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
> diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Fri Jan 20 17:12:17 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Mon Jan 23 14:35:46 2012 +0000
> @@ -156,7 +156,6 @@ libxl_domain_create_info = Struct("domai
>       ("xsdata",       libxl_key_value_list),
>       ("platformdata", libxl_key_value_list),
>       ("poolid",       uint32),
> -    ("poolname",     string),
>       ])
>
>   libxl_domain_build_info = Struct("domain_build_info",[
> diff -r 4bb2b6a04ec0 -r c91bee33280d tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Fri Jan 20 17:12:17 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:46 2012 +0000
> @@ -315,7 +315,7 @@ static void printf_info(int domid,
>           printf("\t(uuid<unknown>)\n");
>       }
>
> -    printf("\t(cpupool %s)\n", c_info->poolname);
> +    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
>       if (c_info->xsdata)
>           printf("\t(xsdata contains data)\n");
>       else
> @@ -640,11 +640,9 @@ static void parse_config_data(const char
>           c_info->oos = l;
>
>       if (!xlu_cfg_get_string (config, "pool",&buf, 0)) {
> -        c_info->poolid = -1;
>           cpupool_qualifier_to_cpupoolid(buf,&c_info->poolid, NULL);
>       }
> -    c_info->poolname = libxl_cpupoolid_to_name(ctx, c_info->poolid);
> -    if (!c_info->poolname) {
> +    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
>           fprintf(stderr, "Illegal pool specified\n");
>           exit(1);
>       }
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 07:22:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 07:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpahO-00063T-Sp; Tue, 24 Jan 2012 07:21:46 +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 1RpahM-00063G-VY
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 07:21:45 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327389658!61459726!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDA3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14672 invoked from network); 24 Jan 2012 07:20:58 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 07:20:58 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=vDLVNpFU/P0Reun/cdG/xeKUX5BQn7wY2oY/NLKge8g9Go6F6fmRgnNH
	iS5SjAo4zHnytxg7HKPWghUjZvoJW11K1cBx0hRxwbf8vYQ/vqMa5qinJ
	DSGfd88PhDOAq0rEHLverIQv9uRe2Skb6fKfTB8yQvJZ6AOm47K0ZUofQ
	6r1BAuFmsNXjKcxSmGJ2XrtO7pFe7r1FKzh4jJ1QIajSGAYrVZS1+8T8t
	yTsxxC6CjYVO6nl5Ys15Ekml9+Tf0;
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=1327389701; x=1358925701;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=/dJvaHrBLYowJt7NS1TLwkQoSVnwUSgYX8FYP49OY1A=;
	b=iTdyW+PVlTnQJ8GxRz49UnhqAQqODeyl3WNVNJJEOkzRxWbhFUntDu7L
	6v4pkAItHJMuYrNtfDmU+njVyL3zAj+/AeuTF6lGPddNb0n/ujYX78UWW
	8uZEOtQYnmEvps8c+q0ViPTl+g/VS1PXItihwUL/deIPvm+kwOIfIjTiv
	4riswcU2IKYeppYKg6f0glEskp/whhNaNLk+ksn4/2JgJoXt8MStqpPIG
	eGDYFl4U3KqKxT4kXHo6qwSW+KKpp;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="84321523"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 08:21:40 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127620865"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 08:21:39 +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 F194B95C35B;
	Tue, 24 Jan 2012 08:21:39 +0100 (CET)
Message-ID: <4F1E5C03.40208@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 08:21:39 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
	<10f5656caaaa2bdfd6a7.1327329790@cosworth.uk.xensource.com>
In-Reply-To: <10f5656caaaa2bdfd6a7.1327329790@cosworth.uk.xensource.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: name libxl_create_cpupool
 consistent with other 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 03:43 PM, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1327329347 0
> # Node ID 10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
> # Parent  c91bee33280debdfe602d28e48318c03ddf0f4c9
> libxl: name libxl_create_cpupool consistent with other functions.
>
> The pattern for the other cpupool functions is libxl_cpupool_<ACTION>
> and in general we use libxl_<THING>_<ACTION>
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
Acked-by: juergen.gross@ts.fujitsu.com
> diff -r c91bee33280d -r 10f5656caaaa tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 23 14:35:46 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 23 14:35:47 2012 +0000
> @@ -3172,7 +3172,7 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
>       return 0;
>   }
>
> -int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
> +int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
>                            libxl_cpumap cpumap, libxl_uuid *uuid,
>                            uint32_t *poolid)
>   {
> diff -r c91bee33280d -r 10f5656caaaa tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Mon Jan 23 14:35:46 2012 +0000
> +++ b/tools/libxl/libxl.h	Mon Jan 23 14:35:47 2012 +0000
> @@ -605,7 +605,7 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
>   int libxl_tmem_freeable(libxl_ctx *ctx);
>
>   int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
> -int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
> +int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
>                            libxl_cpumap cpumap, libxl_uuid *uuid,
>                            uint32_t *poolid);
>   int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
> diff -r c91bee33280d -r 10f5656caaaa tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:46 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:47 2012 +0000
> @@ -5332,7 +5332,7 @@ int main_cpupoolcreate(int argc, char **
>           return 0;
>
>       poolid = 0;
> -    if (libxl_create_cpupool(ctx, name, schedid, cpumap,&uuid,&poolid)) {
> +    if (libxl_cpupool_create(ctx, name, schedid, cpumap,&uuid,&poolid)) {
>           fprintf(stderr, "error on creating cpupool\n");
>           return -ERROR_FAIL;
>       }
> @@ -5706,7 +5706,7 @@ int main_cpupoolnumasplit(int argc, char
>           snprintf(name, 15, "Pool-node%d", node);
>           libxl_uuid_generate(&uuid);
>           poolid = 0;
> -        ret = -libxl_create_cpupool(ctx, name, schedid, cpumap,&uuid,&poolid);
> +        ret = -libxl_cpupool_create(ctx, name, schedid, cpumap,&uuid,&poolid);
>           if (ret) {
>               fprintf(stderr, "error on creating cpupool\n");
>               goto out;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 07:22:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 07:22:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpahO-00063T-Sp; Tue, 24 Jan 2012 07:21:46 +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 1RpahM-00063G-VY
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 07:21:45 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327389658!61459726!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDA3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14672 invoked from network); 24 Jan 2012 07:20:58 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 07:20:58 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=vDLVNpFU/P0Reun/cdG/xeKUX5BQn7wY2oY/NLKge8g9Go6F6fmRgnNH
	iS5SjAo4zHnytxg7HKPWghUjZvoJW11K1cBx0hRxwbf8vYQ/vqMa5qinJ
	DSGfd88PhDOAq0rEHLverIQv9uRe2Skb6fKfTB8yQvJZ6AOm47K0ZUofQ
	6r1BAuFmsNXjKcxSmGJ2XrtO7pFe7r1FKzh4jJ1QIajSGAYrVZS1+8T8t
	yTsxxC6CjYVO6nl5Ys15Ekml9+Tf0;
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=1327389701; x=1358925701;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=/dJvaHrBLYowJt7NS1TLwkQoSVnwUSgYX8FYP49OY1A=;
	b=iTdyW+PVlTnQJ8GxRz49UnhqAQqODeyl3WNVNJJEOkzRxWbhFUntDu7L
	6v4pkAItHJMuYrNtfDmU+njVyL3zAj+/AeuTF6lGPddNb0n/ujYX78UWW
	8uZEOtQYnmEvps8c+q0ViPTl+g/VS1PXItihwUL/deIPvm+kwOIfIjTiv
	4riswcU2IKYeppYKg6f0glEskp/whhNaNLk+ksn4/2JgJoXt8MStqpPIG
	eGDYFl4U3KqKxT4kXHo6qwSW+KKpp;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="84321523"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 08:21:40 +0100
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="127620865"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 08:21:39 +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 F194B95C35B;
	Tue, 24 Jan 2012 08:21:39 +0100 (CET)
Message-ID: <4F1E5C03.40208@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 08:21:39 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
	<10f5656caaaa2bdfd6a7.1327329790@cosworth.uk.xensource.com>
In-Reply-To: <10f5656caaaa2bdfd6a7.1327329790@cosworth.uk.xensource.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 2 of 3] libxl: name libxl_create_cpupool
 consistent with other 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 03:43 PM, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1327329347 0
> # Node ID 10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
> # Parent  c91bee33280debdfe602d28e48318c03ddf0f4c9
> libxl: name libxl_create_cpupool consistent with other functions.
>
> The pattern for the other cpupool functions is libxl_cpupool_<ACTION>
> and in general we use libxl_<THING>_<ACTION>
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>
Acked-by: juergen.gross@ts.fujitsu.com
> diff -r c91bee33280d -r 10f5656caaaa tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 23 14:35:46 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 23 14:35:47 2012 +0000
> @@ -3172,7 +3172,7 @@ int libxl_get_freecpus(libxl_ctx *ctx, l
>       return 0;
>   }
>
> -int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
> +int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
>                            libxl_cpumap cpumap, libxl_uuid *uuid,
>                            uint32_t *poolid)
>   {
> diff -r c91bee33280d -r 10f5656caaaa tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Mon Jan 23 14:35:46 2012 +0000
> +++ b/tools/libxl/libxl.h	Mon Jan 23 14:35:47 2012 +0000
> @@ -605,7 +605,7 @@ int libxl_tmem_shared_auth(libxl_ctx *ct
>   int libxl_tmem_freeable(libxl_ctx *ctx);
>
>   int libxl_get_freecpus(libxl_ctx *ctx, libxl_cpumap *cpumap);
> -int libxl_create_cpupool(libxl_ctx *ctx, const char *name, int schedid,
> +int libxl_cpupool_create(libxl_ctx *ctx, const char *name, int schedid,
>                            libxl_cpumap cpumap, libxl_uuid *uuid,
>                            uint32_t *poolid);
>   int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
> diff -r c91bee33280d -r 10f5656caaaa tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:46 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 14:35:47 2012 +0000
> @@ -5332,7 +5332,7 @@ int main_cpupoolcreate(int argc, char **
>           return 0;
>
>       poolid = 0;
> -    if (libxl_create_cpupool(ctx, name, schedid, cpumap,&uuid,&poolid)) {
> +    if (libxl_cpupool_create(ctx, name, schedid, cpumap,&uuid,&poolid)) {
>           fprintf(stderr, "error on creating cpupool\n");
>           return -ERROR_FAIL;
>       }
> @@ -5706,7 +5706,7 @@ int main_cpupoolnumasplit(int argc, char
>           snprintf(name, 15, "Pool-node%d", node);
>           libxl_uuid_generate(&uuid);
>           poolid = 0;
> -        ret = -libxl_create_cpupool(ctx, name, schedid, cpumap,&uuid,&poolid);
> +        ret = -libxl_cpupool_create(ctx, name, schedid, cpumap,&uuid,&poolid);
>           if (ret) {
>               fprintf(stderr, "error on creating cpupool\n");
>               goto out;
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:08:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08: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 1RpbQE-000794-Ou; Tue, 24 Jan 2012 08:08:06 +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 1RpbQC-00078z-TZ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:08:05 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327392478!10235082!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDA3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1583 invoked from network); 24 Jan 2012 08:07:58 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 08:07:58 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=ojOC9vy0uLy7olYnl+P0LZGJ0S8Oz+/s6d+kTYyjekC+FQKcjTqXlblo
	SaEnFl0v+BSt5nTOxA2/SYafDUpiRSuvJprTeT7wS9t+WhdErxAVe+Sn/
	J1BQOs5uFgbETfwJydu4aduOAhQPJs0nA5bsA9BywsicqYIPb6kCuuF6y
	KuwpvW/gZcg2PvDZKLMfcxwSRSow8RVZ3Fb5Hm2gRdc1VuK9zMYRHVvX6
	KDOMWGtjguOlA19L8un8/wE+0HZE4;
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=1327392479; x=1358928479;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=++VRlXIBPIqN6zjlnKFOW8ypHMFhDWaSPZ6fIKuxaTs=;
	b=gzVmeFti/w+NON/OsBvHrWly+Gh2iMYVUscSgOmFyBR+8dXCjrcYt6XH
	/Os8uF99a186QiJmZrtdUf6a0W1agCA7Vq3QU21u1vlYrDm1SSwyI28bA
	n+AdI0nQepihPGkNpXtjJu9QitPUbN4tOxoz6stP8LrDiIkzq+SbktpQY
	wgXXjG6vUvr7WTYDK2pkzUinIh634LScrQGly+/LzAuElWAyf+eG+rLVo
	g39rk/g3jUdFkiyd7eyoBeh0dFY+e;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="84326728"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 09:07:58 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127625302"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 09:07:58 +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 4E94C95FCFF;
	Tue, 24 Jan 2012 09:07:58 +0100 (CET)
Message-ID: <4F1E66DE.8030800@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 09:07:58 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
	<d8efdb16b1ef06013061.1327329791@cosworth.uk.xensource.com>
In-Reply-To: <d8efdb16b1ef06013061.1327329791@cosworth.uk.xensource.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] libxl: do not write/maintain
 "pool_name" in XenStore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 03:43 PM, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1327329565 0
> # Node ID d8efdb16b1ef06013061da1f47c2dbce4b042992
> # Parent  10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
> libxl: do not write/maintain "pool_name" in XenStore
>
> Nothing that I can find ever reads this key.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>

Acked-by: juergen.gross@ts.fujitsu.com

> diff -r 10f5656caaaa -r d8efdb16b1ef tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 23 14:35:47 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 23 14:39:25 2012 +0000
> @@ -3434,16 +3434,6 @@ int libxl_cpupool_movedomain(libxl_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);
> -    if (!dom_path) {
> -        GC_FREE;
> -        return ERROR_FAIL;
> -    }
>
>       rc = xc_cpupool_movedomain(ctx->xch, poolid, domid);
>       if (rc) {
> @@ -3453,21 +3443,6 @@ int libxl_cpupool_movedomain(libxl_ctx *
>           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));
> -        if (!vm_path)
> -            break;
> -
> -        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;
> -    }
> -
>       GC_FREE;
>       return 0;
>   }
> diff -r 10f5656caaaa -r d8efdb16b1ef tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Jan 23 14:35:47 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Mon Jan 23 14:39:25 2012 +0000
> @@ -438,9 +438,6 @@ retry_transaction:
>
>       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));
> -    if (info->poolid != -1)
> -        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
> -                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
>
>       libxl__xs_writev(gc, t, dom_path, info->xsdata);
>       libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:08:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08: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 1RpbQE-000794-Ou; Tue, 24 Jan 2012 08:08:06 +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 1RpbQC-00078z-TZ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:08:05 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327392478!10235082!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDA3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1583 invoked from network); 24 Jan 2012 08:07:58 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 08:07:58 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=ojOC9vy0uLy7olYnl+P0LZGJ0S8Oz+/s6d+kTYyjekC+FQKcjTqXlblo
	SaEnFl0v+BSt5nTOxA2/SYafDUpiRSuvJprTeT7wS9t+WhdErxAVe+Sn/
	J1BQOs5uFgbETfwJydu4aduOAhQPJs0nA5bsA9BywsicqYIPb6kCuuF6y
	KuwpvW/gZcg2PvDZKLMfcxwSRSow8RVZ3Fb5Hm2gRdc1VuK9zMYRHVvX6
	KDOMWGtjguOlA19L8un8/wE+0HZE4;
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=1327392479; x=1358928479;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=++VRlXIBPIqN6zjlnKFOW8ypHMFhDWaSPZ6fIKuxaTs=;
	b=gzVmeFti/w+NON/OsBvHrWly+Gh2iMYVUscSgOmFyBR+8dXCjrcYt6XH
	/Os8uF99a186QiJmZrtdUf6a0W1agCA7Vq3QU21u1vlYrDm1SSwyI28bA
	n+AdI0nQepihPGkNpXtjJu9QitPUbN4tOxoz6stP8LrDiIkzq+SbktpQY
	wgXXjG6vUvr7WTYDK2pkzUinIh634LScrQGly+/LzAuElWAyf+eG+rLVo
	g39rk/g3jUdFkiyd7eyoBeh0dFY+e;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="84326728"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 09:07:58 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127625302"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 09:07:58 +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 4E94C95FCFF;
	Tue, 24 Jan 2012 09:07:58 +0100 (CET)
Message-ID: <4F1E66DE.8030800@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 09:07:58 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <ian.campbell@citrix.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
	<d8efdb16b1ef06013061.1327329791@cosworth.uk.xensource.com>
In-Reply-To: <d8efdb16b1ef06013061.1327329791@cosworth.uk.xensource.com>
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] libxl: do not write/maintain
 "pool_name" in XenStore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 03:43 PM, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell<ian.campbell@citrix.com>
> # Date 1327329565 0
> # Node ID d8efdb16b1ef06013061da1f47c2dbce4b042992
> # Parent  10f5656caaaa2bdfd6a7ae9aada903da8bddcbb6
> libxl: do not write/maintain "pool_name" in XenStore
>
> Nothing that I can find ever reads this key.
>
> Signed-off-by: Ian Campbell<ian.campbell@citrix.com>

Acked-by: juergen.gross@ts.fujitsu.com

> diff -r 10f5656caaaa -r d8efdb16b1ef tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 23 14:35:47 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 23 14:39:25 2012 +0000
> @@ -3434,16 +3434,6 @@ int libxl_cpupool_movedomain(libxl_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);
> -    if (!dom_path) {
> -        GC_FREE;
> -        return ERROR_FAIL;
> -    }
>
>       rc = xc_cpupool_movedomain(ctx->xch, poolid, domid);
>       if (rc) {
> @@ -3453,21 +3443,6 @@ int libxl_cpupool_movedomain(libxl_ctx *
>           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));
> -        if (!vm_path)
> -            break;
> -
> -        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;
> -    }
> -
>       GC_FREE;
>       return 0;
>   }
> diff -r 10f5656caaaa -r d8efdb16b1ef tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Mon Jan 23 14:35:47 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Mon Jan 23 14:39:25 2012 +0000
> @@ -438,9 +438,6 @@ retry_transaction:
>
>       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));
> -    if (info->poolid != -1)
> -        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
> -                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
>
>       libxl__xs_writev(gc, t, dom_path, info->xsdata);
>       libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpblv-0007Tm-OV; Tue, 24 Jan 2012 08:30:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1Rpblt-0007Th-TD
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:30:30 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327393769!58154955!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8396 invoked from network); 24 Jan 2012 08:29:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 08:29: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 q0O8ULbU011265
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 03:30:22 -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 q0O8UKgv020230; Tue, 24 Jan 2012 03:30:20 -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 q0O8UGjZ022406;
	Tue, 24 Jan 2012 03:30:17 -0500
Message-ID: <4F1E6C17.7060609@redhat.com>
Date: Tue, 24 Jan 2012 09:30:15 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-5-git-send-email-drjones@redhat.com>
	<20120123183454.GA12542@phenom.dumpdata.com>
In-Reply-To: <20120123183454.GA12542@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	jeremy@goop.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
 config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 07:34 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
>> Add a description to the config menu for xen tmem.
>
> I am not sure what this patch gets us. If this is to minimize the
> size of the module - so say it gets loaded, but tmem-enabled is
> not set nor cleancache and we just have it consuming memory - we can do it
> via returning -ENODEV on the module load.

But why compile in something that one may never use? At least with this patch
I'll have a choice to turn it off if I don't need it.
For example when I build hardened kernel, I'd like to turn of all unnecessary
features for a particular config (i.e. reduce attack surface as much as possible).

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpblv-0007Tm-OV; Tue, 24 Jan 2012 08:30:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <imammedo@redhat.com>) id 1Rpblt-0007Th-TD
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:30:30 +0000
X-Env-Sender: imammedo@redhat.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327393769!58154955!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyMTE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8396 invoked from network); 24 Jan 2012 08:29:29 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-2.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 08:29: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 q0O8ULbU011265
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 03:30:22 -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 q0O8UKgv020230; Tue, 24 Jan 2012 03:30:20 -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 q0O8UGjZ022406;
	Tue, 24 Jan 2012 03:30:17 -0500
Message-ID: <4F1E6C17.7060609@redhat.com>
Date: Tue, 24 Jan 2012 09:30:15 +0100
From: Igor Mammedov <imammedo@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-5-git-send-email-drjones@redhat.com>
	<20120123183454.GA12542@phenom.dumpdata.com>
In-Reply-To: <20120123183454.GA12542@phenom.dumpdata.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	jeremy@goop.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
 config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 07:34 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
>> Add a description to the config menu for xen tmem.
>
> I am not sure what this patch gets us. If this is to minimize the
> size of the module - so say it gets loaded, but tmem-enabled is
> not set nor cleancache and we just have it consuming memory - we can do it
> via returning -ENODEV on the module load.

But why compile in something that one may never use? At least with this patch
I'll have a choice to turn it off if I don't need it.
For example when I build hardened kernel, I'd like to turn of all unnecessary
features for a particular config (i.e. reduce attack surface as much as possible).

-- 
Thanks,
  Igor

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:49:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpc49-0007fe-Cg; Tue, 24 Jan 2012 08:49:21 +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 1Rpc47-0007fZ-Rf
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:49:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327394841!60954205!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8428 invoked from network); 24 Jan 2012 08:47: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; 24 Jan 2012 08:47:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 08:49:17 +0000
Message-Id: <4F1E7EE4020000780006E9EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 08:50:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>,
	<George.Dunlap@eu.citrix.com>,"Keir Fraser" <keir@xen.org>
References: <CB4349F0.37FDB%keir@xen.org> <1327340433.26455.338.camel@elijah>
In-Reply-To: <1327340433.26455.338.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 18:40, George Dunlap <george.dunlap@citrix.com> wrote:
> If I were writing this patch series from the beginning, I'd have one
> patch which "fixed" the various internal functions to use 64-bits for
> EIP, since even in 32-bit that value in the struct can be 64-bit.  That
> patch by itself could have a bug in it, and so as a reviewer /
> archaeologist, *I* would have preferred it did just that one thing, so I
> didn't have to figure out what each individual line was supposed to be
> doing.  Then the guest-visible functional change would have been its own
> patch.

This way round it would seem a reasonable split to me. Yet that
prerequisite patch wasn't sent as such, but instead as a follow up
one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:49:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08:49:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpc49-0007fe-Cg; Tue, 24 Jan 2012 08:49:21 +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 1Rpc47-0007fZ-Rf
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:49:20 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327394841!60954205!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8428 invoked from network); 24 Jan 2012 08:47: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; 24 Jan 2012 08:47:22 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 08:49:17 +0000
Message-Id: <4F1E7EE4020000780006E9EB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 08:50:28 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>,
	<George.Dunlap@eu.citrix.com>,"Keir Fraser" <keir@xen.org>
References: <CB4349F0.37FDB%keir@xen.org> <1327340433.26455.338.camel@elijah>
In-Reply-To: <1327340433.26455.338.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Marcus Granado <Marcus.Granado@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 3/3] xenoprof: Make the escape code
 consistent across 32 and 64-bit 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 23.01.12 at 18:40, George Dunlap <george.dunlap@citrix.com> wrote:
> If I were writing this patch series from the beginning, I'd have one
> patch which "fixed" the various internal functions to use 64-bits for
> EIP, since even in 32-bit that value in the struct can be 64-bit.  That
> patch by itself could have a bug in it, and so as a reviewer /
> archaeologist, *I* would have preferred it did just that one thing, so I
> didn't have to figure out what each individual line was supposed to be
> doing.  Then the guest-visible functional change would have been its own
> patch.

This way round it would seem a reasonable split to me. Yet that
prerequisite patch wasn't sent as such, but instead as a follow up
one.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:57:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08: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 1RpcBp-0007p3-Av; Tue, 24 Jan 2012 08:57:17 +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 1RpcBn-0007ou-Um
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:57:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327395388!61471698!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29910 invoked from network); 24 Jan 2012 08:56:29 -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; 24 Jan 2012 08:56:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 08:57:11 +0000
Message-Id: <4F1E80BE020000780006E9FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 08:58:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<4F16BC97020000780006D6D6@nat28.tlf.novell.com>
	<20120118142923.GA6052@andromeda.dapyr.net>
	<20120123223213.GA31929@phenom.dumpdata.com>
In-Reply-To: <20120123223213.GA31929@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.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 23.01.12 at 23:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
>> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > > The issue as I understand is that the DVB drivers allocate their buffers
>> > > from 0->4GB most (all the time?) so they never have to do bounce-buffering.
>> > > 
>> > > While the pv-ops one ends up quite frequently doing the bounce-buffering, 
>> > > which
>> > > implies that the DVB drivers end up allocating their buffers above the 
> 4GB.
>> > > This means we end up spending some CPU time (in the guest) copying the 
>> > > memory
>> > > from >4GB to 0-4GB region (And vice-versa).
>> > 
>> > This reminds me of something (not sure what XenoLinux you use for
>> > comparison) - how are they allocating that memory? Not vmalloc_32()
>> 
>> I was using the 2.6.18, then the one I saw on Google for Gentoo, and now
>> I am going to look at the 2.6.38 from OpenSuSE.
>> 
>> > by chance (I remember having seen numerous uses under - iirc -
>> > drivers/media/)?
>> > 
>> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
>> > what their (driver) callers might expect in a PV guest (including the
>> > contiguity assumption for the latter, recalling that you earlier said
>> > you were able to see the problem after several guest starts), and I
>> > had put into our kernels an adjustment to make vmalloc_32() actually
>> > behave as expected.
>> 
>> Aaah.. The plot thickens! Let me look in the sources! Thanks for the
>> pointer.
> 
> Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32
> and then performs PCI DMA operations on the allocted vmalloc_32
> area.
> 
> So I cobbled up the attached patch (hadn't actually tested it and sadly
> won't until next week) which removes the call to vmalloc_32 and instead
> sets up DMA allocated set of pages.

What a big patch (which would need re-doing for every vmalloc_32()
caller)! Fixing vmalloc_32() would be much less intrusive (reproducing
our 3.2 version of the affected function below, but clearly that's not
pv-ops ready).

Jan

static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
				 pgprot_t prot, int node, void *caller)
{
	const int order = 0;
	struct page **pages;
	unsigned int nr_pages, array_size, i;
	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
#ifdef CONFIG_XEN
	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);

	BUILD_BUG_ON((__GFP_DMA | __GFP_DMA32) != (__GFP_DMA + __GFP_DMA32));
	if (dma_mask == (__GFP_DMA | __GFP_DMA32))
		gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
#endif

	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
	array_size = (nr_pages * sizeof(struct page *));

	area->nr_pages = nr_pages;
	/* Please note that the recursion is strictly bounded. */
	if (array_size > PAGE_SIZE) {
		pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM,
				PAGE_KERNEL, node, caller);
		area->flags |= VM_VPAGES;
	} else {
		pages = kmalloc_node(array_size, nested_gfp, node);
	}
	area->pages = pages;
	area->caller = caller;
	if (!area->pages) {
		remove_vm_area(area->addr);
		kfree(area);
		return NULL;
	}

	for (i = 0; i < area->nr_pages; i++) {
		struct page *page;
		gfp_t tmp_mask = gfp_mask | __GFP_NOWARN;

		if (node < 0)
			page = alloc_page(tmp_mask);
		else
			page = alloc_pages_node(node, tmp_mask, order);

		if (unlikely(!page)) {
			/* Successfully allocated i pages, free them in __vunmap() */
			area->nr_pages = i;
			goto fail;
		}
		area->pages[i] = page;
#ifdef CONFIG_XEN
		if (dma_mask) {
			if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
				area->nr_pages = i + 1;
				goto fail;
			}
			if (gfp_mask & __GFP_ZERO)
				clear_highpage(page);
		}
#endif
	}

	if (map_vm_area(area, prot, &pages))
		goto fail;
	return area->addr;

fail:
	warn_alloc_failed(gfp_mask, order,
			  "vmalloc: allocation failure, allocated %ld of %ld bytes\n",
			  (area->nr_pages*PAGE_SIZE), area->size);
	vfree(area->addr);
	return NULL;
}

...

#if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
#define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
#elif defined(CONFIG_XEN)
#define GFP_VMALLOC32 __GFP_DMA | __GFP_DMA32 | GFP_KERNEL
#else
#define GFP_VMALLOC32 GFP_KERNEL
#endif


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:57:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08: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 1RpcBp-0007p3-Av; Tue, 24 Jan 2012 08:57:17 +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 1RpcBn-0007ou-Um
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:57:16 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327395388!61471698!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29910 invoked from network); 24 Jan 2012 08:56:29 -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; 24 Jan 2012 08:56:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 08:57:11 +0000
Message-Id: <4F1E80BE020000780006E9FB@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 08:58:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<783969451.20111218011916@eikelenboom.it>
	<20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<4F16BC97020000780006D6D6@nat28.tlf.novell.com>
	<20120118142923.GA6052@andromeda.dapyr.net>
	<20120123223213.GA31929@phenom.dumpdata.com>
In-Reply-To: <20120123223213.GA31929@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Sander Eikelenboom <linux@eikelenboom.it>,
	xen-devel <xen-devel@lists.xensource.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 23.01.12 at 23:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
>> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > > The issue as I understand is that the DVB drivers allocate their buffers
>> > > from 0->4GB most (all the time?) so they never have to do bounce-buffering.
>> > > 
>> > > While the pv-ops one ends up quite frequently doing the bounce-buffering, 
>> > > which
>> > > implies that the DVB drivers end up allocating their buffers above the 
> 4GB.
>> > > This means we end up spending some CPU time (in the guest) copying the 
>> > > memory
>> > > from >4GB to 0-4GB region (And vice-versa).
>> > 
>> > This reminds me of something (not sure what XenoLinux you use for
>> > comparison) - how are they allocating that memory? Not vmalloc_32()
>> 
>> I was using the 2.6.18, then the one I saw on Google for Gentoo, and now
>> I am going to look at the 2.6.38 from OpenSuSE.
>> 
>> > by chance (I remember having seen numerous uses under - iirc -
>> > drivers/media/)?
>> > 
>> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
>> > what their (driver) callers might expect in a PV guest (including the
>> > contiguity assumption for the latter, recalling that you earlier said
>> > you were able to see the problem after several guest starts), and I
>> > had put into our kernels an adjustment to make vmalloc_32() actually
>> > behave as expected.
>> 
>> Aaah.. The plot thickens! Let me look in the sources! Thanks for the
>> pointer.
> 
> Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32
> and then performs PCI DMA operations on the allocted vmalloc_32
> area.
> 
> So I cobbled up the attached patch (hadn't actually tested it and sadly
> won't until next week) which removes the call to vmalloc_32 and instead
> sets up DMA allocated set of pages.

What a big patch (which would need re-doing for every vmalloc_32()
caller)! Fixing vmalloc_32() would be much less intrusive (reproducing
our 3.2 version of the affected function below, but clearly that's not
pv-ops ready).

Jan

static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
				 pgprot_t prot, int node, void *caller)
{
	const int order = 0;
	struct page **pages;
	unsigned int nr_pages, array_size, i;
	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
#ifdef CONFIG_XEN
	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);

	BUILD_BUG_ON((__GFP_DMA | __GFP_DMA32) != (__GFP_DMA + __GFP_DMA32));
	if (dma_mask == (__GFP_DMA | __GFP_DMA32))
		gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
#endif

	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
	array_size = (nr_pages * sizeof(struct page *));

	area->nr_pages = nr_pages;
	/* Please note that the recursion is strictly bounded. */
	if (array_size > PAGE_SIZE) {
		pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM,
				PAGE_KERNEL, node, caller);
		area->flags |= VM_VPAGES;
	} else {
		pages = kmalloc_node(array_size, nested_gfp, node);
	}
	area->pages = pages;
	area->caller = caller;
	if (!area->pages) {
		remove_vm_area(area->addr);
		kfree(area);
		return NULL;
	}

	for (i = 0; i < area->nr_pages; i++) {
		struct page *page;
		gfp_t tmp_mask = gfp_mask | __GFP_NOWARN;

		if (node < 0)
			page = alloc_page(tmp_mask);
		else
			page = alloc_pages_node(node, tmp_mask, order);

		if (unlikely(!page)) {
			/* Successfully allocated i pages, free them in __vunmap() */
			area->nr_pages = i;
			goto fail;
		}
		area->pages[i] = page;
#ifdef CONFIG_XEN
		if (dma_mask) {
			if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
				area->nr_pages = i + 1;
				goto fail;
			}
			if (gfp_mask & __GFP_ZERO)
				clear_highpage(page);
		}
#endif
	}

	if (map_vm_area(area, prot, &pages))
		goto fail;
	return area->addr;

fail:
	warn_alloc_failed(gfp_mask, order,
			  "vmalloc: allocation failure, allocated %ld of %ld bytes\n",
			  (area->nr_pages*PAGE_SIZE), area->size);
	vfree(area->addr);
	return NULL;
}

...

#if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
#define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
#elif defined(CONFIG_XEN)
#define GFP_VMALLOC32 __GFP_DMA | __GFP_DMA32 | GFP_KERNEL
#else
#define GFP_VMALLOC32 GFP_KERNEL
#endif


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 08:58:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpcCi-0007sd-UB; Tue, 24 Jan 2012 08:58: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 1RpcCh-0007s7-PO
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:58:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327395485!11740691!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzkwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2623 invoked from network); 24 Jan 2012 08:58:05 -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;
	24 Jan 2012 08:58:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10239424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 08:58:01 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 08:58:01 +0000
Message-ID: <1327395480.17019.1.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 24 Jan 2012 08:58:00 +0000
In-Reply-To: <20120123182443.GA22963@phenom.dumpdata.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
	<4F160113.1030503@oracle.com>
	<1326877176.29475.37.camel@dagon.hellion.org.uk>
	<4F173467.90106@oracle.com>
	<20120123182443.GA22963@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Tina Yang <tina.yang@oracle.com>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 18:24 +0000, Konrad Rzeszutek Wilk wrote:

> Ok, so let me update the git commit description to include this.
> 
> I am listed as the maintainer but I would have thought that it should
> go through David?

Generally folks listed as specific network driver maintainers are
sub-maintainers under David, so the flow would be You->David->Linus. For
netback I generally don't bother with the "You->" bit but just Ack them
on list and David picks them up.

> David, should it go through you or should I stick it in my tree? Here
> is the patch with a better git description.
> 
> From 1c265b7946f222ab6a5aac5245a0ab84618772c8 Mon Sep 17 00:00:00 2001
> From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> Date: Thu, 12 Jan 2012 10:18:29 +0800
> Subject: [PATCH] xen/netfront: add netconsole support.
> 
> add polling interface to xen-netfront device to support netconsole
> 
> This patch also alters the spin_lock usage to use irqsave variant.
> Documentation/networking/netdevices.txt states that start_xmit
> can be called with interrupts disabled by netconsole and therefore using
> the irqsave/restore locking in this function is looks correct.
> 
> Signed-off-by: Tina.Yang <tina.yang@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
> Tested-by: gurudas.pai <gurudas.pai@oracle.com>
> [v1: Copy-n-pasted Ian Campbell comments]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Tue Jan 24 08:58:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 08:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpcCi-0007sd-UB; Tue, 24 Jan 2012 08:58: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 1RpcCh-0007s7-PO
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 08:58:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327395485!11740691!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4MzkwMw==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2623 invoked from network); 24 Jan 2012 08:58:05 -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;
	24 Jan 2012 08:58:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10239424"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 08:58:01 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 08:58:01 +0000
Message-ID: <1327395480.17019.1.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 24 Jan 2012 08:58:00 +0000
In-Reply-To: <20120123182443.GA22963@phenom.dumpdata.com>
References: <1326271956-25565-1-git-send-email-zhenzhong.duan@oracle.com>
	<20120112141745.GA7685@phenom.dumpdata.com>
	<1326452769.17210.331.camel@zakaz.uk.xensource.com>
	<4F15EB3E.3060700@oracle.com>
	<20120117215100.GA25367@phenom.dumpdata.com>
	<4F160113.1030503@oracle.com>
	<1326877176.29475.37.camel@dagon.hellion.org.uk>
	<4F173467.90106@oracle.com>
	<20120123182443.GA22963@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"gurudas.pai@oracle.com" <gurudas.pai@oracle.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>,
	Tina Yang <tina.yang@oracle.com>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 18:24 +0000, Konrad Rzeszutek Wilk wrote:

> Ok, so let me update the git commit description to include this.
> 
> I am listed as the maintainer but I would have thought that it should
> go through David?

Generally folks listed as specific network driver maintainers are
sub-maintainers under David, so the flow would be You->David->Linus. For
netback I generally don't bother with the "You->" bit but just Ack them
on list and David picks them up.

> David, should it go through you or should I stick it in my tree? Here
> is the patch with a better git description.
> 
> From 1c265b7946f222ab6a5aac5245a0ab84618772c8 Mon Sep 17 00:00:00 2001
> From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> Date: Thu, 12 Jan 2012 10:18:29 +0800
> Subject: [PATCH] xen/netfront: add netconsole support.
> 
> add polling interface to xen-netfront device to support netconsole
> 
> This patch also alters the spin_lock usage to use irqsave variant.
> Documentation/networking/netdevices.txt states that start_xmit
> can be called with interrupts disabled by netconsole and therefore using
> the irqsave/restore locking in this function is looks correct.
> 
> Signed-off-by: Tina.Yang <tina.yang@oracle.com>
> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
> Tested-by: gurudas.pai <gurudas.pai@oracle.com>
> [v1: Copy-n-pasted Ian Campbell comments]
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Tue Jan 24 09:13:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 09:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpcR4-00005P-Gs; Tue, 24 Jan 2012 09:13:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RpcR2-00005I-PU
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 09:13:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327396312!62229840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 454 invoked from network); 24 Jan 2012 09:11:52 -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;
	24 Jan 2012 09:11:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10239847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 09:12:47 +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;
	Tue, 24 Jan 2012 09:12:47 +0000
Message-ID: <1327396329.19799.1.camel@liuw-workstation>
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Tue, 24 Jan 2012 09:12:09 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80E2F0D38@LONPMAILBOX01.citrite.net>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0D38@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 23:59 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: 23 January 2012 03:51
> > To: xen-devel@lists.xensource.com
> > Cc: Paul Durrant; Wei Liu (Intern)
> > Subject: [PATCH] Add a GNTTABOP to swap the content of two grant
> > references under lock provided that they are not currently active.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 

Paul, I posted version 2 of the patch later yesterday.

Please sign off that patch instead.

Thanks
Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 09:13:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 09:13:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpcR4-00005P-Gs; Tue, 24 Jan 2012 09:13:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RpcR2-00005I-PU
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 09:13:01 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327396312!62229840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 454 invoked from network); 24 Jan 2012 09:11:52 -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;
	24 Jan 2012 09:11:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10239847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 09:12:47 +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;
	Tue, 24 Jan 2012 09:12:47 +0000
Message-ID: <1327396329.19799.1.camel@liuw-workstation>
From: Wei Liu <wei.liu2@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Tue, 24 Jan 2012 09:12:09 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80E2F0D38@LONPMAILBOX01.citrite.net>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0D38@LONPMAILBOX01.citrite.net>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 23:59 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > Sent: 23 January 2012 03:51
> > To: xen-devel@lists.xensource.com
> > Cc: Paul Durrant; Wei Liu (Intern)
> > Subject: [PATCH] Add a GNTTABOP to swap the content of two grant
> > references under lock provided that they are not currently active.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 

Paul, I posted version 2 of the patch later yesterday.

Please sign off that patch instead.

Thanks
Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 09:23:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 09:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpcb9-0000Xd-Mq; Tue, 24 Jan 2012 09:23:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rpcb8-0000XU-Gd
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 09:23:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327396999!10427136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19477 invoked from network); 24 Jan 2012 09:23: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;
	24 Jan 2012 09:23:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10240085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 09:23:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 09:23:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 24 Jan 2012 09:23:18 +0000
In-Reply-To: <1327396329.19799.1.camel@liuw-workstation>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0D38@LONPMAILBOX01.citrite.net>
	<1327396329.19799.1.camel@liuw-workstation>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327396999.24561.161.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 09:12 +0000, Wei Liu wrote:
> On Mon, 2012-01-23 at 23:59 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: 23 January 2012 03:51
> > > To: xen-devel@lists.xensource.com
> > > Cc: Paul Durrant; Wei Liu (Intern)
> > > Subject: [PATCH] Add a GNTTABOP to swap the content of two grant
> > > references under lock provided that they are not currently active.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > 
> 
> Paul, I posted version 2 of the patch later yesterday.
> 
> Please sign off that patch instead.

It's ok, you can carry this sign-off onto your modified versions.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 09:23:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 09:23:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpcb9-0000Xd-Mq; Tue, 24 Jan 2012 09:23:27 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rpcb8-0000XU-Gd
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 09:23:26 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327396999!10427136!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19477 invoked from network); 24 Jan 2012 09:23: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;
	24 Jan 2012 09:23:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10240085"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 09:23:19 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 09:23:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 24 Jan 2012 09:23:18 +0000
In-Reply-To: <1327396329.19799.1.camel@liuw-workstation>
References: <1327319475-7594-1-git-send-email-wei.liu2@citrix.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0D38@LONPMAILBOX01.citrite.net>
	<1327396329.19799.1.camel@liuw-workstation>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327396999.24561.161.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] Add a GNTTABOP to swap the content of two
 grant references under lock provided that they are not currently active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 09:12 +0000, Wei Liu wrote:
> On Mon, 2012-01-23 at 23:59 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Wei Liu [mailto:wei.liu2@citrix.com]
> > > Sent: 23 January 2012 03:51
> > > To: xen-devel@lists.xensource.com
> > > Cc: Paul Durrant; Wei Liu (Intern)
> > > Subject: [PATCH] Add a GNTTABOP to swap the content of two grant
> > > references under lock provided that they are not currently active.
> > > 
> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > 
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > 
> 
> Paul, I posted version 2 of the patch later yesterday.
> 
> Please sign off that patch instead.

It's ok, you can carry this sign-off onto your modified versions.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 09:33:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 09:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpckh-0000jm-QC; Tue, 24 Jan 2012 09:33:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rpckg-0000jh-9o
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 09:33:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327397592!10426662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9393 invoked from network); 24 Jan 2012 09:33:12 -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;
	24 Jan 2012 09:33:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10240306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 09:33: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;
	Tue, 24 Jan 2012 09:33:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 09:33:11 +0000
In-Reply-To: <08232960ff4bed750d26.1327384451@nehalem1>
References: <08232960ff4bed750d26.1327384451@nehalem1>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327397591.24561.166.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] switch to dynamically allocated
 cpumask in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 05:54 +0000, Juergen Gross wrote:
> # HG changeset patch
> # User Juergen Gross <juergen.gross@ts.fujitsu.com>
> # Date 1327384410 -3600
> # Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
> # Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
> switch to dynamically allocated cpumask in
> domain_update_node_affinity()
> 
> cpumasks should rather be allocated dynamically.
> 
> Signed-off-by: juergen.gross@ts.fujitsu.com
> 
> diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
> --- a/xen/common/domain.c       Tue Jan 24 06:53:06 2012 +0100
> +++ b/xen/common/domain.c       Tue Jan 24 06:53:30 2012 +0100
> @@ -333,23 +333,27 @@ struct domain *domain_create(
>  
>  void domain_update_node_affinity(struct domain *d)
>  {
> -    cpumask_t cpumask;
> +    cpumask_var_t cpumask;
>      nodemask_t nodemask = NODE_MASK_NONE;
>      struct vcpu *v;
>      unsigned int node;
>  
> -    cpumask_clear(&cpumask);
> +    if ( !zalloc_cpumask_var(&cpumask) )
> +        return;

If this ends up always failing we will never set node_affinity to
anything at all. Granted that is already a pretty nasty situation to be
in but perhaps setting the affinity to NODE_MASK_ALL on failure is
slightly more robust?

> +
>      spin_lock(&d->node_affinity_lock);
>  
>      for_each_vcpu ( d, v )
> -        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
> +        cpumask_or(cpumask, cpumask, v->cpu_affinity);
>  
>      for_each_online_node ( node )
> -        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
> +        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
>              node_set(node, nodemask);
>  
>      d->node_affinity = nodemask;
>      spin_unlock(&d->node_affinity_lock);
> +
> +    free_cpumask_var(cpumask);
>  }
>  
>   


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 09:33:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 09:33:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpckh-0000jm-QC; Tue, 24 Jan 2012 09:33:19 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rpckg-0000jh-9o
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 09:33:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327397592!10426662!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9393 invoked from network); 24 Jan 2012 09:33:12 -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;
	24 Jan 2012 09:33:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10240306"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 09:33: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;
	Tue, 24 Jan 2012 09:33:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 09:33:11 +0000
In-Reply-To: <08232960ff4bed750d26.1327384451@nehalem1>
References: <08232960ff4bed750d26.1327384451@nehalem1>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327397591.24561.166.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] switch to dynamically allocated
 cpumask in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 05:54 +0000, Juergen Gross wrote:
> # HG changeset patch
> # User Juergen Gross <juergen.gross@ts.fujitsu.com>
> # Date 1327384410 -3600
> # Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
> # Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
> switch to dynamically allocated cpumask in
> domain_update_node_affinity()
> 
> cpumasks should rather be allocated dynamically.
> 
> Signed-off-by: juergen.gross@ts.fujitsu.com
> 
> diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
> --- a/xen/common/domain.c       Tue Jan 24 06:53:06 2012 +0100
> +++ b/xen/common/domain.c       Tue Jan 24 06:53:30 2012 +0100
> @@ -333,23 +333,27 @@ struct domain *domain_create(
>  
>  void domain_update_node_affinity(struct domain *d)
>  {
> -    cpumask_t cpumask;
> +    cpumask_var_t cpumask;
>      nodemask_t nodemask = NODE_MASK_NONE;
>      struct vcpu *v;
>      unsigned int node;
>  
> -    cpumask_clear(&cpumask);
> +    if ( !zalloc_cpumask_var(&cpumask) )
> +        return;

If this ends up always failing we will never set node_affinity to
anything at all. Granted that is already a pretty nasty situation to be
in but perhaps setting the affinity to NODE_MASK_ALL on failure is
slightly more robust?

> +
>      spin_lock(&d->node_affinity_lock);
>  
>      for_each_vcpu ( d, v )
> -        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
> +        cpumask_or(cpumask, cpumask, v->cpu_affinity);
>  
>      for_each_online_node ( node )
> -        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
> +        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
>              node_set(node, nodemask);
>  
>      d->node_affinity = nodemask;
>      spin_unlock(&d->node_affinity_lock);
> +
> +    free_cpumask_var(cpumask);
>  }
>  
>   


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 09:57:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 09:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpd7N-00015b-0e; Tue, 24 Jan 2012 09:56:45 +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 1Rpd7L-00015W-G1
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 09:56:43 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327398996!10430872!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDQ0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6758 invoked from network); 24 Jan 2012 09:56:36 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 09:56:36 -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=v1xx3x45RBr1Qyyu1PyqhpZH0rvIM59yrqR2xHn51AyiDKoOb6vcsG53
	ogSJ5f/MTD5pt61u5IvuH4Y0XlpAuF4mWDYQ25FOZeVH5pFTICry/pWiD
	EuvY5RPVI/q2GGdoz1XEGW/Eb4a3LKM1gE7ZZPH38QdilpjLlbblR0q1Q
	LelfCTsxXa6XLavvy5JxzMagFX3z8ysd176RJaPdWEmkrf+DLy1RiBQ1n
	/u9+YrGk6jYZdQD1j/mIXsuekPysW;
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=1327398997; x=1358934997;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=qyibd+EwW7hJFuZPQXC7GhJwE6XOMwG/8ybm1tMMbFY=;
	b=TCbZfNUm/tMIYdRDz4JbfRFGe/PA+sLtIEDoYs7bgE/EHTEYK0VHZAi6
	45l9qBzJXIRk2hGiaI3ZGXcKmI5/rg0rXni/9Hhr8IYVV+BI/O+w9z7Kl
	XvFEbx76cmY4yzpIK7XvvL7GeP3qVBUl3cZsq/LruiWWcnDAOjNQLC1z9
	pvtbl/1dUKE+vFw4SuZFlvLVAE9yBJbN19hVpOeKo6g5VnqZshjZX2oet
	WjmQiBGM3b8k5ctYUecKqrFBX075x;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="99518987"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 10:56:36 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127636073"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 10:56:35 +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 AFE1E960CB7;
	Tue, 24 Jan 2012 10:56:35 +0100 (CET)
Message-ID: <4F1E8053.5090104@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 10:56:35 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <08232960ff4bed750d26.1327384451@nehalem1>
	<1327397591.24561.166.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327397591.24561.166.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] switch to dynamically allocated
 cpumask in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 10:33 AM, Ian Campbell wrote:
> On Tue, 2012-01-24 at 05:54 +0000, Juergen Gross wrote:
>> # HG changeset patch
>> # User Juergen Gross<juergen.gross@ts.fujitsu.com>
>> # Date 1327384410 -3600
>> # Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
>> # Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
>> switch to dynamically allocated cpumask in
>> domain_update_node_affinity()
>>
>> cpumasks should rather be allocated dynamically.
>>
>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>
>> diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
>> --- a/xen/common/domain.c       Tue Jan 24 06:53:06 2012 +0100
>> +++ b/xen/common/domain.c       Tue Jan 24 06:53:30 2012 +0100
>> @@ -333,23 +333,27 @@ struct domain *domain_create(
>>
>>   void domain_update_node_affinity(struct domain *d)
>>   {
>> -    cpumask_t cpumask;
>> +    cpumask_var_t cpumask;
>>       nodemask_t nodemask = NODE_MASK_NONE;
>>       struct vcpu *v;
>>       unsigned int node;
>>
>> -    cpumask_clear(&cpumask);
>> +    if ( !zalloc_cpumask_var(&cpumask) )
>> +        return;
> If this ends up always failing we will never set node_affinity to
> anything at all. Granted that is already a pretty nasty situation to be
> in but perhaps setting the affinity to NODE_MASK_ALL on failure is
> slightly more robust?

Hmm, I really don't know.

node_affinity is only used in alloc_heap_pages(), which will fall back to other
nodes if no memory is found on those nodes.

OTOH this implementation might change in the future.

The question is whether node_affinity should rather contain a subset or a
superset of the nodes the domain is running on.

What should be done if allocating a cpumask fails later? Should node_affinity
be set to NODE_MASK_ALL/NONE or should it be left untouched assuming a real
change is a rare thing to happen?


Juergen

>> +
>>       spin_lock(&d->node_affinity_lock);
>>
>>       for_each_vcpu ( d, v )
>> -        cpumask_or(&cpumask,&cpumask, v->cpu_affinity);
>> +        cpumask_or(cpumask, cpumask, v->cpu_affinity);
>>
>>       for_each_online_node ( node )
>> -        if ( cpumask_intersects(&node_to_cpumask(node),&cpumask) )
>> +        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
>>               node_set(node, nodemask);
>>
>>       d->node_affinity = nodemask;
>>       spin_unlock(&d->node_affinity_lock);
>> +
>> +    free_cpumask_var(cpumask);
>>   }
>>
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 09:57:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 09:57:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpd7N-00015b-0e; Tue, 24 Jan 2012 09:56:45 +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 1Rpd7L-00015W-G1
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 09:56:43 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327398996!10430872!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNDQ0Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6758 invoked from network); 24 Jan 2012 09:56:36 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 09:56:36 -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=v1xx3x45RBr1Qyyu1PyqhpZH0rvIM59yrqR2xHn51AyiDKoOb6vcsG53
	ogSJ5f/MTD5pt61u5IvuH4Y0XlpAuF4mWDYQ25FOZeVH5pFTICry/pWiD
	EuvY5RPVI/q2GGdoz1XEGW/Eb4a3LKM1gE7ZZPH38QdilpjLlbblR0q1Q
	LelfCTsxXa6XLavvy5JxzMagFX3z8ysd176RJaPdWEmkrf+DLy1RiBQ1n
	/u9+YrGk6jYZdQD1j/mIXsuekPysW;
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=1327398997; x=1358934997;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=qyibd+EwW7hJFuZPQXC7GhJwE6XOMwG/8ybm1tMMbFY=;
	b=TCbZfNUm/tMIYdRDz4JbfRFGe/PA+sLtIEDoYs7bgE/EHTEYK0VHZAi6
	45l9qBzJXIRk2hGiaI3ZGXcKmI5/rg0rXni/9Hhr8IYVV+BI/O+w9z7Kl
	XvFEbx76cmY4yzpIK7XvvL7GeP3qVBUl3cZsq/LruiWWcnDAOjNQLC1z9
	pvtbl/1dUKE+vFw4SuZFlvLVAE9yBJbN19hVpOeKo6g5VnqZshjZX2oet
	WjmQiBGM3b8k5ctYUecKqrFBX075x;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,560,1320620400"; d="scan'208";a="99518987"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 24 Jan 2012 10:56:36 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127636073"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 10:56:35 +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 AFE1E960CB7;
	Tue, 24 Jan 2012 10:56:35 +0100 (CET)
Message-ID: <4F1E8053.5090104@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 10:56:35 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <08232960ff4bed750d26.1327384451@nehalem1>
	<1327397591.24561.166.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327397591.24561.166.camel@zakaz.uk.xensource.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] switch to dynamically allocated
 cpumask in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 10:33 AM, Ian Campbell wrote:
> On Tue, 2012-01-24 at 05:54 +0000, Juergen Gross wrote:
>> # HG changeset patch
>> # User Juergen Gross<juergen.gross@ts.fujitsu.com>
>> # Date 1327384410 -3600
>> # Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
>> # Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
>> switch to dynamically allocated cpumask in
>> domain_update_node_affinity()
>>
>> cpumasks should rather be allocated dynamically.
>>
>> Signed-off-by: juergen.gross@ts.fujitsu.com
>>
>> diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
>> --- a/xen/common/domain.c       Tue Jan 24 06:53:06 2012 +0100
>> +++ b/xen/common/domain.c       Tue Jan 24 06:53:30 2012 +0100
>> @@ -333,23 +333,27 @@ struct domain *domain_create(
>>
>>   void domain_update_node_affinity(struct domain *d)
>>   {
>> -    cpumask_t cpumask;
>> +    cpumask_var_t cpumask;
>>       nodemask_t nodemask = NODE_MASK_NONE;
>>       struct vcpu *v;
>>       unsigned int node;
>>
>> -    cpumask_clear(&cpumask);
>> +    if ( !zalloc_cpumask_var(&cpumask) )
>> +        return;
> If this ends up always failing we will never set node_affinity to
> anything at all. Granted that is already a pretty nasty situation to be
> in but perhaps setting the affinity to NODE_MASK_ALL on failure is
> slightly more robust?

Hmm, I really don't know.

node_affinity is only used in alloc_heap_pages(), which will fall back to other
nodes if no memory is found on those nodes.

OTOH this implementation might change in the future.

The question is whether node_affinity should rather contain a subset or a
superset of the nodes the domain is running on.

What should be done if allocating a cpumask fails later? Should node_affinity
be set to NODE_MASK_ALL/NONE or should it be left untouched assuming a real
change is a rare thing to happen?


Juergen

>> +
>>       spin_lock(&d->node_affinity_lock);
>>
>>       for_each_vcpu ( d, v )
>> -        cpumask_or(&cpumask,&cpumask, v->cpu_affinity);
>> +        cpumask_or(cpumask, cpumask, v->cpu_affinity);
>>
>>       for_each_online_node ( node )
>> -        if ( cpumask_intersects(&node_to_cpumask(node),&cpumask) )
>> +        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
>>               node_set(node, nodemask);
>>
>>       d->node_affinity = nodemask;
>>       spin_unlock(&d->node_affinity_lock);
>> +
>> +    free_cpumask_var(cpumask);
>>   }
>>
>>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdFO-0001JF-06; Tue, 24 Jan 2012 10:05:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpdFM-0001JA-6h
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:05:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327399460!49542168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10100 invoked from network); 24 Jan 2012 10:04:20 -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;
	24 Jan 2012 10:04:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10241126"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 10:04:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 10:04:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 10:04:55 +0000
In-Reply-To: <4F1E8053.5090104@ts.fujitsu.com>
References: <08232960ff4bed750d26.1327384451@nehalem1>
	<1327397591.24561.166.camel@zakaz.uk.xensource.com>
	<4F1E8053.5090104@ts.fujitsu.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327399495.24561.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 3] switch to dynamically allocated
 cpumask in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 09:56 +0000, Juergen Gross wrote:
> On 01/24/2012 10:33 AM, Ian Campbell wrote:
> > On Tue, 2012-01-24 at 05:54 +0000, Juergen Gross wrote:
> >> # HG changeset patch
> >> # User Juergen Gross<juergen.gross@ts.fujitsu.com>
> >> # Date 1327384410 -3600
> >> # Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
> >> # Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
> >> switch to dynamically allocated cpumask in
> >> domain_update_node_affinity()
> >>
> >> cpumasks should rather be allocated dynamically.
> >>
> >> Signed-off-by: juergen.gross@ts.fujitsu.com
> >>
> >> diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
> >> --- a/xen/common/domain.c       Tue Jan 24 06:53:06 2012 +0100
> >> +++ b/xen/common/domain.c       Tue Jan 24 06:53:30 2012 +0100
> >> @@ -333,23 +333,27 @@ struct domain *domain_create(
> >>
> >>   void domain_update_node_affinity(struct domain *d)
> >>   {
> >> -    cpumask_t cpumask;
> >> +    cpumask_var_t cpumask;
> >>       nodemask_t nodemask = NODE_MASK_NONE;
> >>       struct vcpu *v;
> >>       unsigned int node;
> >>
> >> -    cpumask_clear(&cpumask);
> >> +    if ( !zalloc_cpumask_var(&cpumask) )
> >> +        return;
> > If this ends up always failing we will never set node_affinity to
> > anything at all. Granted that is already a pretty nasty situation to be
> > in but perhaps setting the affinity to NODE_MASK_ALL on failure is
> > slightly more robust?
> 
> Hmm, I really don't know.
> 
> node_affinity is only used in alloc_heap_pages(), which will fall back to other
> nodes if no memory is found on those nodes.
> 
> OTOH this implementation might change in the future.
> 
> The question is whether node_affinity should rather contain a subset or a
> superset of the nodes the domain is running on.

If we've had an allocation failure then we are presumably unable to
calculate whether anything is a sub/super set other than the trivial all
nodes or no nodes cases. IMHO no nodes is likely to lead to
strange/unexpected behaviour so all nodes is safer.
 
> What should be done if allocating a cpumask fails later? Should node_affinity
> be set to NODE_MASK_ALL/NONE or should it be left untouched assuming a real
> change is a rare thing to happen?

Leaving alone seems reasonable and it would mean this issue could be
fixed by simply initialising d->node_affinity to all nodes on allocation
instead of worrying about it here.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:05:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:05:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdFO-0001JF-06; Tue, 24 Jan 2012 10:05:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpdFM-0001JA-6h
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:05:00 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327399460!49542168!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10100 invoked from network); 24 Jan 2012 10:04:20 -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;
	24 Jan 2012 10:04:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10241126"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 10:04:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 10:04:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 10:04:55 +0000
In-Reply-To: <4F1E8053.5090104@ts.fujitsu.com>
References: <08232960ff4bed750d26.1327384451@nehalem1>
	<1327397591.24561.166.camel@zakaz.uk.xensource.com>
	<4F1E8053.5090104@ts.fujitsu.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327399495.24561.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 3] switch to dynamically allocated
 cpumask in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 09:56 +0000, Juergen Gross wrote:
> On 01/24/2012 10:33 AM, Ian Campbell wrote:
> > On Tue, 2012-01-24 at 05:54 +0000, Juergen Gross wrote:
> >> # HG changeset patch
> >> # User Juergen Gross<juergen.gross@ts.fujitsu.com>
> >> # Date 1327384410 -3600
> >> # Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
> >> # Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
> >> switch to dynamically allocated cpumask in
> >> domain_update_node_affinity()
> >>
> >> cpumasks should rather be allocated dynamically.
> >>
> >> Signed-off-by: juergen.gross@ts.fujitsu.com
> >>
> >> diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
> >> --- a/xen/common/domain.c       Tue Jan 24 06:53:06 2012 +0100
> >> +++ b/xen/common/domain.c       Tue Jan 24 06:53:30 2012 +0100
> >> @@ -333,23 +333,27 @@ struct domain *domain_create(
> >>
> >>   void domain_update_node_affinity(struct domain *d)
> >>   {
> >> -    cpumask_t cpumask;
> >> +    cpumask_var_t cpumask;
> >>       nodemask_t nodemask = NODE_MASK_NONE;
> >>       struct vcpu *v;
> >>       unsigned int node;
> >>
> >> -    cpumask_clear(&cpumask);
> >> +    if ( !zalloc_cpumask_var(&cpumask) )
> >> +        return;
> > If this ends up always failing we will never set node_affinity to
> > anything at all. Granted that is already a pretty nasty situation to be
> > in but perhaps setting the affinity to NODE_MASK_ALL on failure is
> > slightly more robust?
> 
> Hmm, I really don't know.
> 
> node_affinity is only used in alloc_heap_pages(), which will fall back to other
> nodes if no memory is found on those nodes.
> 
> OTOH this implementation might change in the future.
> 
> The question is whether node_affinity should rather contain a subset or a
> superset of the nodes the domain is running on.

If we've had an allocation failure then we are presumably unable to
calculate whether anything is a sub/super set other than the trivial all
nodes or no nodes cases. IMHO no nodes is likely to lead to
strange/unexpected behaviour so all nodes is safer.
 
> What should be done if allocating a cpumask fails later? Should node_affinity
> be set to NODE_MASK_ALL/NONE or should it be left untouched assuming a real
> change is a rare thing to happen?

Leaving alone seems reasonable and it would mean this issue could be
fixed by simply initialising d->node_affinity to all nodes on allocation
instead of worrying about it here.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:14:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdNx-0001T4-0k; Tue, 24 Jan 2012 10:13:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpdNv-0001So-I2
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:13:51 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327400025!12334288!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22054 invoked from network); 24 Jan 2012 10:13:45 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:13:45 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:
	Content-Transfer-Encoding:Subject:Message-Id:Date:From:To;
	b=qwvvKJ0KShoFg+2yC745NmWxqubdAfqF6Bj3l4OOlpqHSpE4yXK2E9sr
	DuZfHiMXo6sM9ZmG+HkjBmBm/cJoIsFZPcMbU2Gqdf4c3rFjKDgs1FxXV
	JfzyZbX8JfRnxFIgtLxXxGw00pUsepXEalGzBkBhGHVwo3weSMt9y5/gl
	63+CndXCgrl1C0N+9WWX0kiXJkS+a7sgz16oh2CCsGferXf1qcYtQk4MR
	+UK2Wle/jz/dHMo03AmKOCR1xQtHV;
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=1327400025; x=1358936025;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to;
	bh=5lBekYkp/DyTs9lVFLkygmRxunXWG8Bv4ePRK+nCag8=;
	b=DsqpORU/L0LrUL/ZS4cgByl9UrU0gOqRQ+F2CTLsocWH62POMEKuzjdk
	YiIT76NbnF1eN1MTs6Z0qsprHy/BncWnsoFgetXse8prQb8FAjTl+wNev
	0fUEp8S1H/ZLXitshHqcs7zNYQpolTp/TeNY0CV9FT7mUaCa1DFGZJ28G
	YjPxFZkeMY4kXxrAYEELAK3UGV5rtX/DZ+dkXhUPw9rrvDU27x0mtb4ng
	bS4FaOmvm22nY59eL+Ywx+BBYXzsq;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84346520"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:44 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127637779"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:45 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id AFA9895AB6B;
	Tue, 24 Jan 2012 11:13:44 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1327399566@nehalem1>
Date: Tue, 24 Jan 2012 11:06:06 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3] Reflect cpupool in numa node affinity
	(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

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Changes in v5:
- pre-initialze node_affinity to NODE_MASK_ALL

Changes in v4:
- split in three patches

Changes in v3:
- formatting
- avoid memory leak

Changes in v2:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

8 files changed, 49 insertions(+), 28 deletions(-)
xen/common/cpupool.c       |    9 +++++++++
xen/common/domain.c        |   29 ++++++++++++++++++++++++-----
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |   16 +++++-----------
xen/include/xen/sched-if.h |    5 +++++

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:14:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdNx-0001T4-0k; Tue, 24 Jan 2012 10:13:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpdNv-0001So-I2
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:13:51 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327400025!12334288!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22054 invoked from network); 24 Jan 2012 10:13:45 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:13:45 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:
	Content-Transfer-Encoding:Subject:Message-Id:Date:From:To;
	b=qwvvKJ0KShoFg+2yC745NmWxqubdAfqF6Bj3l4OOlpqHSpE4yXK2E9sr
	DuZfHiMXo6sM9ZmG+HkjBmBm/cJoIsFZPcMbU2Gqdf4c3rFjKDgs1FxXV
	JfzyZbX8JfRnxFIgtLxXxGw00pUsepXEalGzBkBhGHVwo3weSMt9y5/gl
	63+CndXCgrl1C0N+9WWX0kiXJkS+a7sgz16oh2CCsGferXf1qcYtQk4MR
	+UK2Wle/jz/dHMo03AmKOCR1xQtHV;
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=1327400025; x=1358936025;
	h=mime-version:content-transfer-encoding:subject:
	message-id:date:from:to;
	bh=5lBekYkp/DyTs9lVFLkygmRxunXWG8Bv4ePRK+nCag8=;
	b=DsqpORU/L0LrUL/ZS4cgByl9UrU0gOqRQ+F2CTLsocWH62POMEKuzjdk
	YiIT76NbnF1eN1MTs6Z0qsprHy/BncWnsoFgetXse8prQb8FAjTl+wNev
	0fUEp8S1H/ZLXitshHqcs7zNYQpolTp/TeNY0CV9FT7mUaCa1DFGZJ28G
	YjPxFZkeMY4kXxrAYEELAK3UGV5rtX/DZ+dkXhUPw9rrvDU27x0mtb4ng
	bS4FaOmvm22nY59eL+Ywx+BBYXzsq;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84346520"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:44 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127637779"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:45 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id AFA9895AB6B;
	Tue, 24 Jan 2012 11:13:44 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1327399566@nehalem1>
Date: Tue, 24 Jan 2012 11:06:06 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 0 of 3] Reflect cpupool in numa node affinity
	(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

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Changes in v5:
- pre-initialze node_affinity to NODE_MASK_ALL

Changes in v4:
- split in three patches

Changes in v3:
- formatting
- avoid memory leak

Changes in v2:
- switch to dynamically allocated cpumasks in domain_update_node_affinity()
- introduce and use common macros for selecting cpupool based cpumasks

8 files changed, 49 insertions(+), 28 deletions(-)
xen/common/cpupool.c       |    9 +++++++++
xen/common/domain.c        |   29 ++++++++++++++++++++++++-----
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |   16 +++++-----------
xen/include/xen/sched-if.h |    5 +++++

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:14:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdNx-0001TI-P2; Tue, 24 Jan 2012 10:13:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpdNw-0001Sq-8c
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:13:52 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327400025!12334288!3
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22099 invoked from network); 24 Jan 2012 10:13:46 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:13:46 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=CcxxBr3xwH6b0mijdF3w/V0AulmjesYlpbTucw+kLfNwKC15rQlMQFMs
	QuwUjIZ7jCGncI8fZWk0kICw//KI6N6X4U2gJJx8c8BURYbHRx3gZslnL
	nhAlGcCAudmPwvgEgdz9cu6ejMMQqLVfL+XdgGmU3T/D6b7hvox1z1yXT
	f3G1gw0RWf6ai8PKSWlCw+EckktYkudlizssUHPkqJtW9UzcKin9GVCvY
	yXbX04bMhZjlgow/cJMiEHijCmOIF;
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=1327400026; x=1358936026;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=iH3DlrjFEUiLhsQabDib0UM1SbAq6wLNj83nig4WoK4=;
	b=GA8clx7Yk7rdqhRvBzM4NgC+lxb+D/Xv0kfV06Xe5YpBb1uYNzus0OU6
	UgjoHru29o/t7RPkCUbABUYWUoprOFQP921oxmJYBMdqc9sfTTxvZJsuU
	JLC4dpADViFSs0s8XVKnf57Y2sSBbh3xfJTUAxNv8hHKO9X93W/73WT7o
	gadLyPpmjiTCuh7Sv5rkwYbBIeKr4Wz4wZ52A/9gsARuoyoYuQRBSurPL
	F/skD3n4uH9Se7wCk6bv6q55RWlmw;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84346523"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:44 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127637781"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:46 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id C674F95AB6B;
	Tue, 24 Jan 2012 11:13:44 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============5694991945195412612=="
MIME-Version: 1.0
X-Mercurial-Node: 0caec9849a8c98bc3afa650199683c6f294bf101
Message-Id: <0caec9849a8c98bc3afa.1327399568@nehalem1>
In-Reply-To: <patchbomb.1327399566@nehalem1>
Date: Tue, 24 Jan 2012 11:06:08 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3] switch to dynamically allocated cpumask
	in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5694991945195412612==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

cpumasks should rather be allocated dynamically.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 9 insertions(+), 4 deletions(-)
xen/common/domain.c |   13 +++++++++----



--===============5694991945195412612==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327399530 -3600
# Node ID 0caec9849a8c98bc3afa650199683c6f294bf101
# Parent  5589314aa984152c684bedffb4276272646314f0
switch to dynamically allocated cpumask in domain_update_node_affinity()

cpumasks should rather be allocated dynamically.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 5589314aa984 -r 0caec9849a8c xen/common/domain.c
--- a/xen/common/domain.c	Tue Jan 24 11:03:03 2012 +0100
+++ b/xen/common/domain.c	Tue Jan 24 11:05:30 2012 +0100
@@ -220,6 +220,7 @@ struct domain *domain_create(
     INIT_PAGE_LIST_HEAD(&d->xenpage_list);
 
     spin_lock_init(&d->node_affinity_lock);
+    d->node_affinity = NODE_MASK_ALL;
 
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code = -1;
@@ -333,23 +334,27 @@ struct domain *domain_create(
 
 void domain_update_node_affinity(struct domain *d)
 {
-    cpumask_t cpumask;
+    cpumask_var_t cpumask;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
-    cpumask_clear(&cpumask);
+    if ( !zalloc_cpumask_var(&cpumask) )
+        return;
+
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+        cpumask_or(cpumask, cpumask, v->cpu_affinity);
 
     for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
+
+    free_cpumask_var(cpumask);
 }
 
 

--===============5694991945195412612==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5694991945195412612==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:14:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:14:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdNx-0001TI-P2; Tue, 24 Jan 2012 10:13:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpdNw-0001Sq-8c
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:13:52 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327400025!12334288!3
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22099 invoked from network); 24 Jan 2012 10:13:46 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:13:46 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=CcxxBr3xwH6b0mijdF3w/V0AulmjesYlpbTucw+kLfNwKC15rQlMQFMs
	QuwUjIZ7jCGncI8fZWk0kICw//KI6N6X4U2gJJx8c8BURYbHRx3gZslnL
	nhAlGcCAudmPwvgEgdz9cu6ejMMQqLVfL+XdgGmU3T/D6b7hvox1z1yXT
	f3G1gw0RWf6ai8PKSWlCw+EckktYkudlizssUHPkqJtW9UzcKin9GVCvY
	yXbX04bMhZjlgow/cJMiEHijCmOIF;
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=1327400026; x=1358936026;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=iH3DlrjFEUiLhsQabDib0UM1SbAq6wLNj83nig4WoK4=;
	b=GA8clx7Yk7rdqhRvBzM4NgC+lxb+D/Xv0kfV06Xe5YpBb1uYNzus0OU6
	UgjoHru29o/t7RPkCUbABUYWUoprOFQP921oxmJYBMdqc9sfTTxvZJsuU
	JLC4dpADViFSs0s8XVKnf57Y2sSBbh3xfJTUAxNv8hHKO9X93W/73WT7o
	gadLyPpmjiTCuh7Sv5rkwYbBIeKr4Wz4wZ52A/9gsARuoyoYuQRBSurPL
	F/skD3n4uH9Se7wCk6bv6q55RWlmw;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84346523"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:44 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127637781"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:46 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id C674F95AB6B;
	Tue, 24 Jan 2012 11:13:44 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============5694991945195412612=="
MIME-Version: 1.0
X-Mercurial-Node: 0caec9849a8c98bc3afa650199683c6f294bf101
Message-Id: <0caec9849a8c98bc3afa.1327399568@nehalem1>
In-Reply-To: <patchbomb.1327399566@nehalem1>
Date: Tue, 24 Jan 2012 11:06:08 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 2 of 3] switch to dynamically allocated cpumask
	in	domain_update_node_affinity()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5694991945195412612==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

cpumasks should rather be allocated dynamically.

Signed-off-by: juergen.gross@ts.fujitsu.com


1 file changed, 9 insertions(+), 4 deletions(-)
xen/common/domain.c |   13 +++++++++----



--===============5694991945195412612==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327399530 -3600
# Node ID 0caec9849a8c98bc3afa650199683c6f294bf101
# Parent  5589314aa984152c684bedffb4276272646314f0
switch to dynamically allocated cpumask in domain_update_node_affinity()

cpumasks should rather be allocated dynamically.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 5589314aa984 -r 0caec9849a8c xen/common/domain.c
--- a/xen/common/domain.c	Tue Jan 24 11:03:03 2012 +0100
+++ b/xen/common/domain.c	Tue Jan 24 11:05:30 2012 +0100
@@ -220,6 +220,7 @@ struct domain *domain_create(
     INIT_PAGE_LIST_HEAD(&d->xenpage_list);
 
     spin_lock_init(&d->node_affinity_lock);
+    d->node_affinity = NODE_MASK_ALL;
 
     spin_lock_init(&d->shutdown_lock);
     d->shutdown_code = -1;
@@ -333,23 +334,27 @@ struct domain *domain_create(
 
 void domain_update_node_affinity(struct domain *d)
 {
-    cpumask_t cpumask;
+    cpumask_var_t cpumask;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
-    cpumask_clear(&cpumask);
+    if ( !zalloc_cpumask_var(&cpumask) )
+        return;
+
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(&cpumask, &cpumask, v->cpu_affinity);
+        cpumask_or(cpumask, cpumask, v->cpu_affinity);
 
     for_each_online_node ( node )
-        if ( cpumask_intersects(&node_to_cpumask(node), &cpumask) )
+        if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
             node_set(node, nodemask);
 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
+
+    free_cpumask_var(cpumask);
 }
 
 

--===============5694991945195412612==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5694991945195412612==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:14:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:14:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdNx-0001TB-Cl; Tue, 24 Jan 2012 10:13:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpdNw-0001Sp-6Q
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:13:52 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327400025!12334288!2
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22064 invoked from network); 24 Jan 2012 10:13:45 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:13:45 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=YXiS44VTX/A0Y56Urq3fal+Srsh5Q+lAB3eNUfclm6/tqRJ28EJUuqXO
	0Emd4wZpHBr5PN25YGRlSm61PzoMDDuXzRD761Fp7Vacw82xLqFHZRQEn
	GT6qH8DV5q7Il3iw6devmfvrtFFdl10ShTVgS3Y55oZ5tKoJcNX7qWRla
	MwOT/SC8AUKL4AglUruFn/ki0WuIltkteCK8r/YGacRYIGV6EZyZB7r57
	YbXAhB7n1ufgWxF/USr4DAN8szzbe;
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=1327400025; x=1358936025;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=q3mTamspAuLvRlMvr+75vNoQzSlskDjPi7ZOoDH6Rww=;
	b=pPq8dTUDqmCOKsnq6yJRd5GXxtFAx9GfXJbL2N/LCR12r37vJTkgHu6G
	RIzOy+HS17oF63gz0RuyH8p/AAt+pYJcM7f58bv6H4N+ZKfWSSG+N+xVG
	mMKwNTq6FE5Fcz+PZWj/DStUQ6siYzColhCBFrR2Ayk1dWi6ejBg5z7j0
	VwFe05fPTMFVUhw0hy1rzsUzafYIQprA2iCTOLIBIcHRmpp+9oeqYTNzD
	/BgpYLZAaJ/r/Glc8i30+UD6D4U6u;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84346521"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:44 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127637780"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:46 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id BAF9095B258;
	Tue, 24 Jan 2012 11:13:44 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============3562230627209732071=="
MIME-Version: 1.0
X-Mercurial-Node: 5589314aa984152c684bedffb4276272646314f0
Message-Id: <5589314aa984152c684b.1327399567@nehalem1>
In-Reply-To: <patchbomb.1327399566@nehalem1>
Date: Tue, 24 Jan 2012 11:06:07 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3] introduce and use common macros for
	selecting cpupool	based cpumasks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3562230627209732071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

There are several instances of the same construct finding the cpumask for a
cpupool. Use macros instead.

Signed-off-by: juergen.gross@ts.fujitsu.com


6 files changed, 13 insertions(+), 16 deletions(-)
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |    6 ++----
xen/include/xen/sched-if.h |    5 +++++



--===============3562230627209732071==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327399383 -3600
# Node ID 5589314aa984152c684bedffb4276272646314f0
# Parent  370924e204dc29e12cd807dd730974d6b2bc53d3
introduce and use common macros for selecting cpupool based cpumasks

There are several instances of the same construct finding the cpumask for a
cpupool. Use macros instead.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 370924e204dc -r 5589314aa984 xen/common/domctl.c
--- a/xen/common/domctl.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/domctl.c	Tue Jan 24 11:03:03 2012 +0100
@@ -518,7 +518,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             goto maxvcpu_out;
 
         ret = -ENOMEM;
-        online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
+        online = cpupool_online_cpumask(d->cpupool);
         if ( max > d->max_vcpus )
         {
             struct vcpu **vcpus;
diff -r 370924e204dc -r 5589314aa984 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_credit.c	Tue Jan 24 11:03:03 2012 +0100
@@ -72,8 +72,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 
 /*
@@ -471,7 +469,7 @@ _csched_cpu_pick(const struct scheduler 
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
      */
-    online = CSCHED_CPUONLINE(vc->domain->cpupool);
+    online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
     cpu = cpumask_test_cpu(vc->processor, &cpus)
             ? vc->processor
@@ -1230,7 +1228,7 @@ csched_load_balance(struct csched_privat
     int peer_cpu;
 
     BUG_ON( cpu != snext->vcpu->processor );
-    online = CSCHED_CPUONLINE(per_cpu(cpupool, cpu));
+    online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
 
     /* If this CPU is going offline we shouldn't steal work. */
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
diff -r 370924e204dc -r 5589314aa984 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_credit2.c	Tue Jan 24 11:03:03 2012 +0100
@@ -169,8 +169,6 @@ integer_param("sched_credit2_migrate_res
     ((struct csched_private *)((_ops)->sched_data))
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 /* CPU to runq_id macro */
 #define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
diff -r 370924e204dc -r 5589314aa984 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_sedf.c	Tue Jan 24 11:03:03 2012 +0100
@@ -12,9 +12,6 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
-
-#define SEDF_CPUONLINE(_pool)                                             \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 #ifndef NDEBUG
 #define SEDF_STATS
@@ -397,7 +394,7 @@ static int sedf_pick_cpu(const struct sc
     cpumask_t online_affinity;
     cpumask_t *online;
 
-    online = SEDF_CPUONLINE(v->domain->cpupool);
+    online = cpupool_scheduler_cpumask(v->domain->cpupool);
     cpumask_and(&online_affinity, v->cpu_affinity, online);
     return cpumask_first(&online_affinity);
 }
@@ -801,7 +798,8 @@ static struct task_slice sedf_do_schedul
      */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
-         unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, cpu)))) )
+         unlikely(!cpumask_test_cpu(cpu,
+                   cpupool_scheduler_cpumask(per_cpu(cpupool, cpu)))) )
     {
         ret.task = IDLETASK(cpu);
         ret.time = SECONDS(1);
diff -r 370924e204dc -r 5589314aa984 xen/common/schedule.c
--- a/xen/common/schedule.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/schedule.c	Tue Jan 24 11:03:03 2012 +0100
@@ -77,9 +77,7 @@ static struct scheduler __read_mostly op
 
 #define DOM2OP(_d)    (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched))
 #define VCPU2OP(_v)   (DOM2OP((_v)->domain))
-#define VCPU2ONLINE(_v)                                                    \
-         (((_v)->domain->cpupool == NULL) ? &cpu_online_map                \
-         : (_v)->domain->cpupool->cpu_valid)
+#define VCPU2ONLINE(_v) cpupool_online_cpumask((_v)->domain->cpupool)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)
 {
@@ -1418,7 +1416,7 @@ void schedule_dump(struct cpupool *c)
     cpumask_t        *cpus;
 
     sched = (c == NULL) ? &ops : c->sched;
-    cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
+    cpus = cpupool_scheduler_cpumask(c);
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
     SCHED_OP(sched, dump_settings);
 
diff -r 370924e204dc -r 5589314aa984 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/include/xen/sched-if.h	Tue Jan 24 11:03:03 2012 +0100
@@ -204,4 +204,9 @@ struct cpupool
     atomic_t         refcnt;
 };
 
+#define cpupool_scheduler_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
+#define cpupool_online_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpu_online_map : (_pool)->cpu_valid)
+
 #endif /* __XEN_SCHED_IF_H__ */

--===============3562230627209732071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3562230627209732071==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:14:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:14:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdNx-0001TB-Cl; Tue, 24 Jan 2012 10:13:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RpdNw-0001Sp-6Q
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:13:52 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327400025!12334288!2
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22064 invoked from network); 24 Jan 2012 10:13:45 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:13:45 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=YXiS44VTX/A0Y56Urq3fal+Srsh5Q+lAB3eNUfclm6/tqRJ28EJUuqXO
	0Emd4wZpHBr5PN25YGRlSm61PzoMDDuXzRD761Fp7Vacw82xLqFHZRQEn
	GT6qH8DV5q7Il3iw6devmfvrtFFdl10ShTVgS3Y55oZ5tKoJcNX7qWRla
	MwOT/SC8AUKL4AglUruFn/ki0WuIltkteCK8r/YGacRYIGV6EZyZB7r57
	YbXAhB7n1ufgWxF/USr4DAN8szzbe;
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=1327400025; x=1358936025;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=q3mTamspAuLvRlMvr+75vNoQzSlskDjPi7ZOoDH6Rww=;
	b=pPq8dTUDqmCOKsnq6yJRd5GXxtFAx9GfXJbL2N/LCR12r37vJTkgHu6G
	RIzOy+HS17oF63gz0RuyH8p/AAt+pYJcM7f58bv6H4N+ZKfWSSG+N+xVG
	mMKwNTq6FE5Fcz+PZWj/DStUQ6siYzColhCBFrR2Ayk1dWi6ejBg5z7j0
	VwFe05fPTMFVUhw0hy1rzsUzafYIQprA2iCTOLIBIcHRmpp+9oeqYTNzD
	/BgpYLZAaJ/r/Glc8i30+UD6D4U6u;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84346521"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:44 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127637780"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:46 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id BAF9095B258;
	Tue, 24 Jan 2012 11:13:44 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============3562230627209732071=="
MIME-Version: 1.0
X-Mercurial-Node: 5589314aa984152c684bedffb4276272646314f0
Message-Id: <5589314aa984152c684b.1327399567@nehalem1>
In-Reply-To: <patchbomb.1327399566@nehalem1>
Date: Tue, 24 Jan 2012 11:06:07 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 1 of 3] introduce and use common macros for
	selecting cpupool	based cpumasks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3562230627209732071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

There are several instances of the same construct finding the cpumask for a
cpupool. Use macros instead.

Signed-off-by: juergen.gross@ts.fujitsu.com


6 files changed, 13 insertions(+), 16 deletions(-)
xen/common/domctl.c        |    2 +-
xen/common/sched_credit.c  |    6 ++----
xen/common/sched_credit2.c |    2 --
xen/common/sched_sedf.c    |    8 +++-----
xen/common/schedule.c      |    6 ++----
xen/include/xen/sched-if.h |    5 +++++



--===============3562230627209732071==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327399383 -3600
# Node ID 5589314aa984152c684bedffb4276272646314f0
# Parent  370924e204dc29e12cd807dd730974d6b2bc53d3
introduce and use common macros for selecting cpupool based cpumasks

There are several instances of the same construct finding the cpumask for a
cpupool. Use macros instead.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 370924e204dc -r 5589314aa984 xen/common/domctl.c
--- a/xen/common/domctl.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/domctl.c	Tue Jan 24 11:03:03 2012 +0100
@@ -518,7 +518,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
             goto maxvcpu_out;
 
         ret = -ENOMEM;
-        online = (d->cpupool == NULL) ? &cpu_online_map : d->cpupool->cpu_valid;
+        online = cpupool_online_cpumask(d->cpupool);
         if ( max > d->max_vcpus )
         {
             struct vcpu **vcpus;
diff -r 370924e204dc -r 5589314aa984 xen/common/sched_credit.c
--- a/xen/common/sched_credit.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_credit.c	Tue Jan 24 11:03:03 2012 +0100
@@ -72,8 +72,6 @@
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
 #define RUNQ(_cpu)          (&(CSCHED_PCPU(_cpu)->runq))
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 
 /*
@@ -471,7 +469,7 @@ _csched_cpu_pick(const struct scheduler 
      * Pick from online CPUs in VCPU's affinity mask, giving a
      * preference to its current processor if it's in there.
      */
-    online = CSCHED_CPUONLINE(vc->domain->cpupool);
+    online = cpupool_scheduler_cpumask(vc->domain->cpupool);
     cpumask_and(&cpus, online, vc->cpu_affinity);
     cpu = cpumask_test_cpu(vc->processor, &cpus)
             ? vc->processor
@@ -1230,7 +1228,7 @@ csched_load_balance(struct csched_privat
     int peer_cpu;
 
     BUG_ON( cpu != snext->vcpu->processor );
-    online = CSCHED_CPUONLINE(per_cpu(cpupool, cpu));
+    online = cpupool_scheduler_cpumask(per_cpu(cpupool, cpu));
 
     /* If this CPU is going offline we shouldn't steal work. */
     if ( unlikely(!cpumask_test_cpu(cpu, online)) )
diff -r 370924e204dc -r 5589314aa984 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_credit2.c	Tue Jan 24 11:03:03 2012 +0100
@@ -169,8 +169,6 @@ integer_param("sched_credit2_migrate_res
     ((struct csched_private *)((_ops)->sched_data))
 #define CSCHED_VCPU(_vcpu)  ((struct csched_vcpu *) (_vcpu)->sched_priv)
 #define CSCHED_DOM(_dom)    ((struct csched_dom *) (_dom)->sched_priv)
-#define CSCHED_CPUONLINE(_pool)    \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 /* CPU to runq_id macro */
 #define c2r(_ops, _cpu)     (CSCHED_PRIV(_ops)->runq_map[(_cpu)])
 /* CPU to runqueue struct macro */
diff -r 370924e204dc -r 5589314aa984 xen/common/sched_sedf.c
--- a/xen/common/sched_sedf.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/sched_sedf.c	Tue Jan 24 11:03:03 2012 +0100
@@ -12,9 +12,6 @@
 #include <xen/softirq.h>
 #include <xen/time.h>
 #include <xen/errno.h>
-
-#define SEDF_CPUONLINE(_pool)                                             \
-    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
 
 #ifndef NDEBUG
 #define SEDF_STATS
@@ -397,7 +394,7 @@ static int sedf_pick_cpu(const struct sc
     cpumask_t online_affinity;
     cpumask_t *online;
 
-    online = SEDF_CPUONLINE(v->domain->cpupool);
+    online = cpupool_scheduler_cpumask(v->domain->cpupool);
     cpumask_and(&online_affinity, v->cpu_affinity, online);
     return cpumask_first(&online_affinity);
 }
@@ -801,7 +798,8 @@ static struct task_slice sedf_do_schedul
      */
     if ( tasklet_work_scheduled ||
          (list_empty(runq) && list_empty(waitq)) ||
-         unlikely(!cpumask_test_cpu(cpu, SEDF_CPUONLINE(per_cpu(cpupool, cpu)))) )
+         unlikely(!cpumask_test_cpu(cpu,
+                   cpupool_scheduler_cpumask(per_cpu(cpupool, cpu)))) )
     {
         ret.task = IDLETASK(cpu);
         ret.time = SECONDS(1);
diff -r 370924e204dc -r 5589314aa984 xen/common/schedule.c
--- a/xen/common/schedule.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/schedule.c	Tue Jan 24 11:03:03 2012 +0100
@@ -77,9 +77,7 @@ static struct scheduler __read_mostly op
 
 #define DOM2OP(_d)    (((_d)->cpupool == NULL) ? &ops : ((_d)->cpupool->sched))
 #define VCPU2OP(_v)   (DOM2OP((_v)->domain))
-#define VCPU2ONLINE(_v)                                                    \
-         (((_v)->domain->cpupool == NULL) ? &cpu_online_map                \
-         : (_v)->domain->cpupool->cpu_valid)
+#define VCPU2ONLINE(_v) cpupool_online_cpumask((_v)->domain->cpupool)
 
 static inline void trace_runstate_change(struct vcpu *v, int new_state)
 {
@@ -1418,7 +1416,7 @@ void schedule_dump(struct cpupool *c)
     cpumask_t        *cpus;
 
     sched = (c == NULL) ? &ops : c->sched;
-    cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
+    cpus = cpupool_scheduler_cpumask(c);
     printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
     SCHED_OP(sched, dump_settings);
 
diff -r 370924e204dc -r 5589314aa984 xen/include/xen/sched-if.h
--- a/xen/include/xen/sched-if.h	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/include/xen/sched-if.h	Tue Jan 24 11:03:03 2012 +0100
@@ -204,4 +204,9 @@ struct cpupool
     atomic_t         refcnt;
 };
 
+#define cpupool_scheduler_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpupool_free_cpus : (_pool)->cpu_valid)
+#define cpupool_online_cpumask(_pool) \
+    (((_pool) == NULL) ? &cpu_online_map : (_pool)->cpu_valid)
+
 #endif /* __XEN_SCHED_IF_H__ */

--===============3562230627209732071==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3562230627209732071==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:14:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:14:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdNy-0001Tc-AW; Tue, 24 Jan 2012 10:13:54 +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 1RpdNx-0001Sr-BE
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:13:53 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327400026!10256790!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9239 invoked from network); 24 Jan 2012 10:13:46 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:13:46 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=XbHiw9gBee6KMmNlmez15rq4/WPWOe7aoibxMnHhiHOjwBAys/9qpJXl
	jasQjAvP99kv0K/+UtUhlDyt6C0lARE9kFwnjbZQBhbO11cLpAZPh+XGA
	qwqdhNOTeakMB1Fs4AdYbNV2S/Q2KsQuHGnWD7DzUXseFGUG7FKfuRHpi
	r5TrtqIxl/vvlOaUsuFuvb/MNmE9k8fGz6O0J/BRkTCUwNuHq9xbORpPz
	RLMWsUoVhNVvGoIP5Ft+AcK+FTQZ7;
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=1327400026; x=1358936026;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=3KqjaKbJZBhDj2NzudAF0ieKgMCSjVzovRSksKLaeRQ=;
	b=IoSkFfg/wh+scrsCvqbiv4v/GjJJjhJoJj01DnuwyH+OUOojFVwb61gh
	3Bq5wfYvBycyPFfdTZcPMtzB/ufjDDe28KFu/P3q8PxBXAk0nmnbOXfTz
	QhkgMnkPOm3nNNJ9yGd7K5mh9Fos0HVFJqECe9fmhsmBCvrsa98BZIKQZ
	4yTgdK9CExZuEhw35HZxgkUmfPQgiIIj5Yp4kIdqJtjseZZ/XBnS2S2kx
	SqLURhgp7glJRcwHgea2bBto9u+vM;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84346525"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:44 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127637782"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:46 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id D0E1D95B258;
	Tue, 24 Jan 2012 11:13:44 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============1997856895585602042=="
MIME-Version: 1.0
X-Mercurial-Node: 844f36fd8c76690bb7b3348260ac20619fc8d059
Message-Id: <844f36fd8c76690bb7b3.1327399569@nehalem1>
In-Reply-To: <patchbomb.1327399566@nehalem1>
Date: Tue, 24 Jan 2012 11:06:09 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3] reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1997856895585602042==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com


3 files changed, 27 insertions(+), 8 deletions(-)
xen/common/cpupool.c  |    9 +++++++++
xen/common/domain.c   |   16 +++++++++++++++-
xen/common/schedule.c |   10 +++-------



--===============1997856895585602042==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327399537 -3600
# Node ID 844f36fd8c76690bb7b3348260ac20619fc8d059
# Parent  0caec9849a8c98bc3afa650199683c6f294bf101
reflect cpupool in numa node affinity

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 0caec9849a8c -r 844f36fd8c76 xen/common/cpupool.c
--- a/xen/common/cpupool.c	Tue Jan 24 11:05:30 2012 +0100
+++ b/xen/common/cpupool.c	Tue Jan 24 11:05:37 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r 0caec9849a8c -r 844f36fd8c76 xen/common/domain.c
--- a/xen/common/domain.c	Tue Jan 24 11:05:30 2012 +0100
+++ b/xen/common/domain.c	Tue Jan 24 11:05:37 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -335,17 +336,29 @@ void domain_update_node_affinity(struct 
 void domain_update_node_affinity(struct domain *d)
 {
     cpumask_var_t cpumask;
+    cpumask_var_t online_affinity;
+    const cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
     if ( !zalloc_cpumask_var(&cpumask) )
         return;
+    if ( !alloc_cpumask_var(&online_affinity) )
+    {
+        free_cpumask_var(cpumask);
+        return;
+    }
+
+    online = cpupool_online_cpumask(d->cpupool);
 
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(cpumask, cpumask, v->cpu_affinity);
+    {
+        cpumask_and(online_affinity, v->cpu_affinity, online);
+        cpumask_or(cpumask, cpumask, online_affinity);
+    }
 
     for_each_online_node ( node )
         if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
@@ -354,6 +367,7 @@ void domain_update_node_affinity(struct 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
 
+    free_cpumask_var(online_affinity);
     free_cpumask_var(cpumask);
 }
 
diff -r 0caec9849a8c -r 844f36fd8c76 xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Jan 24 11:05:30 2012 +0100
+++ b/xen/common/schedule.c	Tue Jan 24 11:05:37 2012 +0100
@@ -280,11 +280,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -535,7 +536,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -543,8 +543,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -556,7 +554,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -580,8 +577,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;

--===============1997856895585602042==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1997856895585602042==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:14:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:14:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdNy-0001Tc-AW; Tue, 24 Jan 2012 10:13:54 +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 1RpdNx-0001Sr-BE
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:13:53 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327400026!10256790!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9239 invoked from network); 24 Jan 2012 10:13:46 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:13:46 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Content-Type:MIME-Version:Subject:
	X-Mercurial-Node:Message-Id:In-Reply-To:Date:From:To;
	b=XbHiw9gBee6KMmNlmez15rq4/WPWOe7aoibxMnHhiHOjwBAys/9qpJXl
	jasQjAvP99kv0K/+UtUhlDyt6C0lARE9kFwnjbZQBhbO11cLpAZPh+XGA
	qwqdhNOTeakMB1Fs4AdYbNV2S/Q2KsQuHGnWD7DzUXseFGUG7FKfuRHpi
	r5TrtqIxl/vvlOaUsuFuvb/MNmE9k8fGz6O0J/BRkTCUwNuHq9xbORpPz
	RLMWsUoVhNVvGoIP5Ft+AcK+FTQZ7;
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=1327400026; x=1358936026;
	h=mime-version:subject:message-id:in-reply-to:date:from:to;
	bh=3KqjaKbJZBhDj2NzudAF0ieKgMCSjVzovRSksKLaeRQ=;
	b=IoSkFfg/wh+scrsCvqbiv4v/GjJJjhJoJj01DnuwyH+OUOojFVwb61gh
	3Bq5wfYvBycyPFfdTZcPMtzB/ufjDDe28KFu/P3q8PxBXAk0nmnbOXfTz
	QhkgMnkPOm3nNNJ9yGd7K5mh9Fos0HVFJqECe9fmhsmBCvrsa98BZIKQZ
	4yTgdK9CExZuEhw35HZxgkUmfPQgiIIj5Yp4kIdqJtjseZZ/XBnS2S2kx
	SqLURhgp7glJRcwHgea2bBto9u+vM;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84346525"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:44 +0100
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="127637782"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 11:13:46 +0100
Received: from [172.17.21.25] (nehalem1.osd.mch.fsc.net [172.17.21.25])
	by sanpedro.mch.fsc.net (Postfix) with ESMTP id D0E1D95B258;
	Tue, 24 Jan 2012 11:13:44 +0100 (CET)
Content-Type: multipart/mixed; boundary="===============1997856895585602042=="
MIME-Version: 1.0
X-Mercurial-Node: 844f36fd8c76690bb7b3348260ac20619fc8d059
Message-Id: <844f36fd8c76690bb7b3.1327399569@nehalem1>
In-Reply-To: <patchbomb.1327399566@nehalem1>
Date: Tue, 24 Jan 2012 11:06:09 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 3 of 3] reflect cpupool in numa node affinity
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1997856895585602042==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com


3 files changed, 27 insertions(+), 8 deletions(-)
xen/common/cpupool.c  |    9 +++++++++
xen/common/domain.c   |   16 +++++++++++++++-
xen/common/schedule.c |   10 +++-------



--===============1997856895585602042==
Content-Type: text/x-patch; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=xen-staging.hg-3.patch

# HG changeset patch
# User Juergen Gross <juergen.gross@ts.fujitsu.com>
# Date 1327399537 -3600
# Node ID 844f36fd8c76690bb7b3348260ac20619fc8d059
# Parent  0caec9849a8c98bc3afa650199683c6f294bf101
reflect cpupool in numa node affinity

In order to prefer node local memory for a domain the numa node locality
info must be built according to the cpus belonging to the cpupool of the
domain.

Signed-off-by: juergen.gross@ts.fujitsu.com

diff -r 0caec9849a8c -r 844f36fd8c76 xen/common/cpupool.c
--- a/xen/common/cpupool.c	Tue Jan 24 11:05:30 2012 +0100
+++ b/xen/common/cpupool.c	Tue Jan 24 11:05:37 2012 +0100
@@ -220,6 +220,7 @@ static int cpupool_assign_cpu_locked(str
 {
     int ret;
     struct cpupool *old;
+    struct domain *d;
 
     if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
         return -EBUSY;
@@ -240,6 +241,14 @@ static int cpupool_assign_cpu_locked(str
         cpupool_cpu_moving = NULL;
     }
     cpumask_set_cpu(cpu, c->cpu_valid);
+
+    rcu_read_lock(&domlist_read_lock);
+    for_each_domain_in_cpupool(d, c)
+    {
+        domain_update_node_affinity(d);
+    }
+    rcu_read_unlock(&domlist_read_lock);
+
     return 0;
 }
 
diff -r 0caec9849a8c -r 844f36fd8c76 xen/common/domain.c
--- a/xen/common/domain.c	Tue Jan 24 11:05:30 2012 +0100
+++ b/xen/common/domain.c	Tue Jan 24 11:05:37 2012 +0100
@@ -11,6 +11,7 @@
 #include <xen/ctype.h>
 #include <xen/errno.h>
 #include <xen/sched.h>
+#include <xen/sched-if.h>
 #include <xen/domain.h>
 #include <xen/mm.h>
 #include <xen/event.h>
@@ -335,17 +336,29 @@ void domain_update_node_affinity(struct 
 void domain_update_node_affinity(struct domain *d)
 {
     cpumask_var_t cpumask;
+    cpumask_var_t online_affinity;
+    const cpumask_t *online;
     nodemask_t nodemask = NODE_MASK_NONE;
     struct vcpu *v;
     unsigned int node;
 
     if ( !zalloc_cpumask_var(&cpumask) )
         return;
+    if ( !alloc_cpumask_var(&online_affinity) )
+    {
+        free_cpumask_var(cpumask);
+        return;
+    }
+
+    online = cpupool_online_cpumask(d->cpupool);
 
     spin_lock(&d->node_affinity_lock);
 
     for_each_vcpu ( d, v )
-        cpumask_or(cpumask, cpumask, v->cpu_affinity);
+    {
+        cpumask_and(online_affinity, v->cpu_affinity, online);
+        cpumask_or(cpumask, cpumask, online_affinity);
+    }
 
     for_each_online_node ( node )
         if ( cpumask_intersects(&node_to_cpumask(node), cpumask) )
@@ -354,6 +367,7 @@ void domain_update_node_affinity(struct 
     d->node_affinity = nodemask;
     spin_unlock(&d->node_affinity_lock);
 
+    free_cpumask_var(online_affinity);
     free_cpumask_var(cpumask);
 }
 
diff -r 0caec9849a8c -r 844f36fd8c76 xen/common/schedule.c
--- a/xen/common/schedule.c	Tue Jan 24 11:05:30 2012 +0100
+++ b/xen/common/schedule.c	Tue Jan 24 11:05:37 2012 +0100
@@ -280,11 +280,12 @@ int sched_move_domain(struct domain *d, 
 
         SCHED_OP(VCPU2OP(v), insert_vcpu, v);
     }
-    domain_update_node_affinity(d);
 
     d->cpupool = c;
     SCHED_OP(DOM2OP(d), free_domdata, d->sched_priv);
     d->sched_priv = domdata;
+
+    domain_update_node_affinity(d);
 
     domain_unpause(d);
 
@@ -535,7 +536,6 @@ int cpu_disable_scheduler(unsigned int c
     struct cpupool *c;
     cpumask_t online_affinity;
     int    ret = 0;
-    bool_t affinity_broken;
 
     c = per_cpu(cpupool, cpu);
     if ( c == NULL )
@@ -543,8 +543,6 @@ int cpu_disable_scheduler(unsigned int c
 
     for_each_domain_in_cpupool ( d, c )
     {
-        affinity_broken = 0;
-
         for_each_vcpu ( d, v )
         {
             vcpu_schedule_lock_irq(v);
@@ -556,7 +554,6 @@ int cpu_disable_scheduler(unsigned int c
                 printk("Breaking vcpu affinity for domain %d vcpu %d\n",
                         v->domain->domain_id, v->vcpu_id);
                 cpumask_setall(v->cpu_affinity);
-                affinity_broken = 1;
             }
 
             if ( v->processor == cpu )
@@ -580,8 +577,7 @@ int cpu_disable_scheduler(unsigned int c
                 ret = -EAGAIN;
         }
 
-        if ( affinity_broken )
-            domain_update_node_affinity(d);
+        domain_update_node_affinity(d);
     }
 
     return ret;

--===============1997856895585602042==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1997856895585602042==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:22:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:22:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdVm-00024P-BK; Tue, 24 Jan 2012 10:21:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RpdVl-00024D-0I
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:21:57 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327400510!10426079!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1826 invoked from network); 24 Jan 2012 10:21:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 10:21: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 q0OALjsp000942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 05:21:45 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-58.ams2.redhat.com
	[10.36.116.58])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OALfUU018968; Tue, 24 Jan 2012 05:21:42 -0500
Message-ID: <4F1E8635.2020608@redhat.com>
Date: Tue, 24 Jan 2012 11:21:41 +0100
From: Gerd Hoffmann <kraxel@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: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>
	<4F1D9649.1000102@codemonkey.ws> <4F1D995A.4020604@siemens.com>
	<4F1D9A8E.1080102@codemonkey.ws>
In-Reply-To: <4F1D9A8E.1080102@codemonkey.ws>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  Hi,

>>> We really should view RAM as just another device so I don't like the
>>> idea of
>>> propagating a global concept of "when RAM is restored" because that
>>> treats it
>>> specially compared to other devices.
>>>
>>> But viewing RAM as just another device, having Xen only restore a
>>> subset of
>>> devices should be a reasonable thing to do moving forward.

I don't think modeling device memory (i.e. vga vram) as something
independent from the device (vga) is a good idea.  Because it isn't.

>> To my understanding, QXL will break identically on Xen for the same
>> reason: the reset handler assumes it can deal with the VRAM as it likes.

Yes.  Some data structures for host <-> guest communication are living
in device memory, and a reset initializes these.

> QXL also has a VGA BIOS that it could use to initialize VRAM.  A similar
> change could be made for it.

Hmm.  Not sure this is a good idea.

cheers,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:22:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:22:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpdVm-00024P-BK; Tue, 24 Jan 2012 10:21:58 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <kraxel@redhat.com>) id 1RpdVl-00024D-0I
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:21:57 +0000
X-Env-Sender: kraxel@redhat.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327400510!10426079!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1826 invoked from network); 24 Jan 2012 10:21:50 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 10:21: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 q0OALjsp000942
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 05:21:45 -0500
Received: from rincewind.home.kraxel.org (ovpn-116-58.ams2.redhat.com
	[10.36.116.58])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OALfUU018968; Tue, 24 Jan 2012 05:21:42 -0500
Message-ID: <4F1E8635.2020608@redhat.com>
Date: Tue, 24 Jan 2012 11:21:41 +0100
From: Gerd Hoffmann <kraxel@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: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>
	<4F1D9649.1000102@codemonkey.ws> <4F1D995A.4020604@siemens.com>
	<4F1D9A8E.1080102@codemonkey.ws>
In-Reply-To: <4F1D9A8E.1080102@codemonkey.ws>
X-Enigmail-Version: 1.1.2
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

  Hi,

>>> We really should view RAM as just another device so I don't like the
>>> idea of
>>> propagating a global concept of "when RAM is restored" because that
>>> treats it
>>> specially compared to other devices.
>>>
>>> But viewing RAM as just another device, having Xen only restore a
>>> subset of
>>> devices should be a reasonable thing to do moving forward.

I don't think modeling device memory (i.e. vga vram) as something
independent from the device (vga) is a good idea.  Because it isn't.

>> To my understanding, QXL will break identically on Xen for the same
>> reason: the reset handler assumes it can deal with the VRAM as it likes.

Yes.  Some data structures for host <-> guest communication are living
in device memory, and a reset initializes these.

> QXL also has a VGA BIOS that it could use to initialize VRAM.  A similar
> change could be made for it.

Hmm.  Not sure this is a good idea.

cheers,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:28:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpdbv-0002Kq-82; Tue, 24 Jan 2012 10:28:19 +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 1Rpdbt-0002KZ-7u
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:28:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327400848!49838692!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzEzOTY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzEzOTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2362 invoked from network); 24 Jan 2012 10:27:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 10:27:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327400895; l=2738;
	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=7oJGB3RvdzP0jnTOAnrJoJGb8iw=;
	b=R7PLh307w7S0qOrH+6BhUg+RzTvfxRKR/agPH0iHAIdP6BPNZWWIKWiYokYVUl0D8fG
	LWTHUhRbYw89yn9K6bigPlmAYDqECTTrmbNRupmUpecTVlfxGJtAroZFfg64Mdi5mLNOQ
	+I8dw8Xebd8cn2jwh4ywFknVLnYTFBsF0LE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qErUK
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-106.pools.arcor-ip.net [84.57.90.106])
	by smtp.strato.de (jimi mo35) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a074aco0O8Kecq ;
	Tue, 24 Jan 2012 11:27:55 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D3CFF18637; Tue, 24 Jan 2012 11:27:57 +0100 (CET)
Date: Tue, 24 Jan 2012 11:27:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120124102757.GA14598@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
	<4F1D786A020000780006E6D1@nat28.tlf.novell.com>
	<20120123142232.GA8983@aepfle.de>
	<4F1D8145020000780006E70C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1D8145020000780006E70C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, Jan Beulich wrote:

> sle11sp2 (3.0): building fine.)

Not for the xen.src.rpm, it also contains this change. I think the
reason is that the kernel sources are searched before the xen sources
for asm/hypervisor.h:

/usr/src/linux-3.0.13-0.11/arch/x86/include/asm/hypervisor.h
/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include/asm/hypervisor.h


This is the cmdline as shown by 
make -C /usr/src/linux-obj/x86_64/default modules M=/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default V=1
abuild@bax:/usr/src/linux-obj/x86_64/default> gcc
-Wp,-MD,/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/.platform-pci.o.d
-nostdinc
-isystem
/usr/lib64/gcc/x86_64-suse-linux/4.3/include
-I/usr/src/linux-3.0.13-0.11/arch/x86/include
-Iarch/x86/include/generated
-Iinclude
-I/usr/src/linux-3.0.13-0.11/include
-include
include/generated/autoconf.h
-I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fno-stack-protector -fomit-frame-pointer -fasynchronous-unwind-tables -g -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -D__XEN_INTERFACE_VERSION__=0x00030205 -DCONFIG_XEN_COMPAT=0xffffff
-I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include
-I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/compat-include
-DHAVE_XEN_PLATFORM_COMPAT_H
-include /usr/src/linux-3.0.13-0.11-obj/x86_64/default/include/generated/autoconf.h
-I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci  -DMODULE  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(platform_pci)"  -D"KBUILD_MODNAME=KBUILD_STR(xen_platform_pci)" -c -o /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/.tmp_platform-pci.o /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/platform-pci.c --save-temps
gcc: warning: -pipe ignored because -save-temps specified
/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/platform-pci.c:121: error: redefinition of 'xen_cpuid_base'
/usr/src/linux-3.0.13-0.11/arch/x86/include/asm/xen/hypervisor.h:43: error: previous definition of 'xen_cpuid_base' was here


Its probably not a bug to prefer kernel-source over local directories.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:28:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpdbv-0002Kq-82; Tue, 24 Jan 2012 10:28:19 +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 1Rpdbt-0002KZ-7u
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:28:17 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327400848!49838692!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzEzOTY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzEzOTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2362 invoked from network); 24 Jan 2012 10:27:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 10:27:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327400895; l=2738;
	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=7oJGB3RvdzP0jnTOAnrJoJGb8iw=;
	b=R7PLh307w7S0qOrH+6BhUg+RzTvfxRKR/agPH0iHAIdP6BPNZWWIKWiYokYVUl0D8fG
	LWTHUhRbYw89yn9K6bigPlmAYDqECTTrmbNRupmUpecTVlfxGJtAroZFfg64Mdi5mLNOQ
	+I8dw8Xebd8cn2jwh4ywFknVLnYTFBsF0LE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lk2c7qErUK
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-090-106.pools.arcor-ip.net [84.57.90.106])
	by smtp.strato.de (jimi mo35) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a074aco0O8Kecq ;
	Tue, 24 Jan 2012 11:27:55 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id D3CFF18637; Tue, 24 Jan 2012 11:27:57 +0100 (CET)
Date: Tue, 24 Jan 2012 11:27:57 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120124102757.GA14598@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
	<4F1D786A020000780006E6D1@nat28.tlf.novell.com>
	<20120123142232.GA8983@aepfle.de>
	<4F1D8145020000780006E70C@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1D8145020000780006E70C@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, Jan Beulich wrote:

> sle11sp2 (3.0): building fine.)

Not for the xen.src.rpm, it also contains this change. I think the
reason is that the kernel sources are searched before the xen sources
for asm/hypervisor.h:

/usr/src/linux-3.0.13-0.11/arch/x86/include/asm/hypervisor.h
/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include/asm/hypervisor.h


This is the cmdline as shown by 
make -C /usr/src/linux-obj/x86_64/default modules M=/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default V=1
abuild@bax:/usr/src/linux-obj/x86_64/default> gcc
-Wp,-MD,/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/.platform-pci.o.d
-nostdinc
-isystem
/usr/lib64/gcc/x86_64-suse-linux/4.3/include
-I/usr/src/linux-3.0.13-0.11/arch/x86/include
-Iarch/x86/include/generated
-Iinclude
-I/usr/src/linux-3.0.13-0.11/include
-include
include/generated/autoconf.h
-I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 -mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fno-stack-protector -fomit-frame-pointer -fasynchronous-unwind-tables -g -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -D__XEN_INTERFACE_VERSION__=0x00030205 -DCONFIG_XEN_COMPAT=0xffffff
-I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include
-I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/compat-include
-DHAVE_XEN_PLATFORM_COMPAT_H
-include /usr/src/linux-3.0.13-0.11-obj/x86_64/default/include/generated/autoconf.h
-I/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci  -DMODULE  -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(platform_pci)"  -D"KBUILD_MODNAME=KBUILD_STR(xen_platform_pci)" -c -o /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/.tmp_platform-pci.o /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/platform-pci.c --save-temps
gcc: warning: -pipe ignored because -save-temps specified
/usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/platform-pci/platform-pci.c:121: error: redefinition of 'xen_cpuid_base'
/usr/src/linux-3.0.13-0.11/arch/x86/include/asm/xen/hypervisor.h:43: error: previous definition of 'xen_cpuid_base' was here


Its probably not a bug to prefer kernel-source over local directories.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:29:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:29:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpdd7-0002Rn-Tq; Tue, 24 Jan 2012 10:29:33 +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 1Rpdd6-0002RF-Ux
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:29:33 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327400965!8578352!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3431 invoked from network); 24 Jan 2012 10:29:26 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:29:26 -0000
Received: by iaeh11 with SMTP id h11so24403301iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 02:29: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;
	bh=MvO4Q1/NcBIhqDjuOchGjy2cQg8i8nO2eZxwv0KiDYM=;
	b=j9rBVRBDD7CrR+TvZa8B8gjt5lhSK9G0ixOf/ZXM/73lJMCANHFivHqDkspfppFBy9
	RvH1fR5ds8lk4rURIadWd7kTn/SJXSKc7k5t4u/lzE0Zm6tv4LKCLLKpWuOgYZWaAmNP
	1aTFrZxZJ84di9FrHs8JbgiLrPhZ8JbCmrCYM=
MIME-Version: 1.0
Received: by 10.50.6.227 with SMTP id e3mr1746149iga.20.1327400965007; Tue, 24
	Jan 2012 02:29:25 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Tue, 24 Jan 2012 02:29:24 -0800 (PST)
In-Reply-To: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
Date: Tue, 24 Jan 2012 10:29:24 +0000
X-Google-Sender-Auth: 4JAAUsLtW9OnBU7ZgpfBs1oPKxQ
Message-ID: <CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> x86's vMCE implementation lets a guest know of as many MCE reporting
> banks as there are in the host. While a PV guest could be expected to
> deal with this number changing (particularly decreasing) during migration
> (not currently handled anywhere afaict), for HVM guests this is certainly
> wrong.
>
> At least to me it isn't, however, clear how to properly handle this. The
> easiest would appear to be to save and restore the number of banks
> the guest was made believe it can access, making vmce_{rd,wr}msr()
> silently tolerate accesses between the host and guest values.

We ran into this in the XS 6.0 release as well.  I think that the
ideal thing to do would be to have a parameter that can be set at
boot, to say how many vMCE banks a guest has, defaulting to the number
of MCE banks on the host.  This parameter would be preserved across
migration.  Ideally, a pool-aware toolstack like xapi would then set
this value to be the value of the host in the pool with the largest
number of banks, allowing a guest to access all the banks on any host
to which it migrates.

What do you think?
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 10:29:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 10:29:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpdd7-0002Rn-Tq; Tue, 24 Jan 2012 10:29:33 +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 1Rpdd6-0002RF-Ux
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 10:29:33 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327400965!8578352!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3431 invoked from network); 24 Jan 2012 10:29:26 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 10:29:26 -0000
Received: by iaeh11 with SMTP id h11so24403301iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 02:29: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;
	bh=MvO4Q1/NcBIhqDjuOchGjy2cQg8i8nO2eZxwv0KiDYM=;
	b=j9rBVRBDD7CrR+TvZa8B8gjt5lhSK9G0ixOf/ZXM/73lJMCANHFivHqDkspfppFBy9
	RvH1fR5ds8lk4rURIadWd7kTn/SJXSKc7k5t4u/lzE0Zm6tv4LKCLLKpWuOgYZWaAmNP
	1aTFrZxZJ84di9FrHs8JbgiLrPhZ8JbCmrCYM=
MIME-Version: 1.0
Received: by 10.50.6.227 with SMTP id e3mr1746149iga.20.1327400965007; Tue, 24
	Jan 2012 02:29:25 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Tue, 24 Jan 2012 02:29:24 -0800 (PST)
In-Reply-To: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
Date: Tue, 24 Jan 2012 10:29:24 +0000
X-Google-Sender-Auth: 4JAAUsLtW9OnBU7ZgpfBs1oPKxQ
Message-ID: <CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> x86's vMCE implementation lets a guest know of as many MCE reporting
> banks as there are in the host. While a PV guest could be expected to
> deal with this number changing (particularly decreasing) during migration
> (not currently handled anywhere afaict), for HVM guests this is certainly
> wrong.
>
> At least to me it isn't, however, clear how to properly handle this. The
> easiest would appear to be to save and restore the number of banks
> the guest was made believe it can access, making vmce_{rd,wr}msr()
> silently tolerate accesses between the host and guest values.

We ran into this in the XS 6.0 release as well.  I think that the
ideal thing to do would be to have a parameter that can be set at
boot, to say how many vMCE banks a guest has, defaulting to the number
of MCE banks on the host.  This parameter would be preserved across
migration.  Ideally, a pool-aware toolstack like xapi would then set
this value to be the value of the host in the pool with the largest
number of banks, allowing a guest to access all the banks on any host
to which it migrates.

What do you think?
 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:08:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11: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 1RpeDv-0002v3-9y; Tue, 24 Jan 2012 11:07:35 +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 1RpeDu-0002uy-Mn
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:07:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327403247!10434699!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16708 invoked from network); 24 Jan 2012 11:07: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; 24 Jan 2012 11:07:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 11:07:26 +0000
Message-Id: <4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 11:08:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
In-Reply-To: <CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.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] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> x86's vMCE implementation lets a guest know of as many MCE reporting
>> banks as there are in the host. While a PV guest could be expected to
>> deal with this number changing (particularly decreasing) during migration
>> (not currently handled anywhere afaict), for HVM guests this is certainly
>> wrong.
>>
>> At least to me it isn't, however, clear how to properly handle this. The
>> easiest would appear to be to save and restore the number of banks
>> the guest was made believe it can access, making vmce_{rd,wr}msr()
>> silently tolerate accesses between the host and guest values.
> 
> We ran into this in the XS 6.0 release as well.  I think that the
> ideal thing to do would be to have a parameter that can be set at
> boot, to say how many vMCE banks a guest has, defaulting to the number
> of MCE banks on the host.  This parameter would be preserved across
> migration.  Ideally, a pool-aware toolstack like xapi would then set
> this value to be the value of the host in the pool with the largest
> number of banks, allowing a guest to access all the banks on any host
> to which it migrates.
> 
> What do you think?

That sounds like the way to go.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:08:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11: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 1RpeDv-0002v3-9y; Tue, 24 Jan 2012 11:07:35 +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 1RpeDu-0002uy-Mn
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:07:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327403247!10434699!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16708 invoked from network); 24 Jan 2012 11:07: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; 24 Jan 2012 11:07:28 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 11:07:26 +0000
Message-Id: <4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 11:08:37 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <George.Dunlap@eu.citrix.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
In-Reply-To: <CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.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] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> x86's vMCE implementation lets a guest know of as many MCE reporting
>> banks as there are in the host. While a PV guest could be expected to
>> deal with this number changing (particularly decreasing) during migration
>> (not currently handled anywhere afaict), for HVM guests this is certainly
>> wrong.
>>
>> At least to me it isn't, however, clear how to properly handle this. The
>> easiest would appear to be to save and restore the number of banks
>> the guest was made believe it can access, making vmce_{rd,wr}msr()
>> silently tolerate accesses between the host and guest values.
> 
> We ran into this in the XS 6.0 release as well.  I think that the
> ideal thing to do would be to have a parameter that can be set at
> boot, to say how many vMCE banks a guest has, defaulting to the number
> of MCE banks on the host.  This parameter would be preserved across
> migration.  Ideally, a pool-aware toolstack like xapi would then set
> this value to be the value of the host in the pool with the largest
> number of banks, allowing a guest to access all the banks on any host
> to which it migrates.
> 
> What do you think?

That sounds like the way to go.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:11:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpeHG-00033R-TT; Tue, 24 Jan 2012 11:11:02 +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 1RpeHE-00033H-FG
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:11:00 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327403453!11614951!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6142 invoked from network); 24 Jan 2012 11:10:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	24 Jan 2012 11:10: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 q0OBAmA2001405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 06:10:49 -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 q0OBAh7b004569; Tue, 24 Jan 2012 06:10:44 -0500
Message-ID: <4F1E91AF.9040402@redhat.com>
Date: Tue, 24 Jan 2012 13:10:39 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
In-Reply-To: <4F1D9649.1000102@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 07:18 PM, Anthony Liguori wrote:
> Generally speaking, RAM is an independent device in most useful cases.  

Can you give examples?  Do you mean a subdevice with composition, or a
really independent device?

> Onboard RAM is a very special case because it's extremely unusual.

What's unusual (or even extremely unusual) about it?  I don't see a
difference between a few billion bits of state and, say, the few bits of
state in an RTC device.

> But since some video cards can make use of dedicated external RAM, I
> don't think any video card really depends on initial RAM state.
>
> What's most likely here is that the VGA BIOS of a Cirrus card sets an
> initial RAM state during device initialization.

Yes, that's likely.  DRAMs aren't reset and some state survives even a
short power off.

>
> We really should view RAM as just another device so I don't like the
> idea of propagating a global concept of "when RAM is restored" because
> that treats it specially compared to other devices.

Agree.  In fact the first step has been taken as now creating a RAM
region with memory_region_init_ram() doesn't register it for migration. 
The next step would be a VMSTATE_RAM() to make it part of the containing
device.

> But viewing RAM as just another device, having Xen only restore a
> subset of devices should be a reasonable thing to do moving forward. 
> The main problem here I believe is that we have part of the VGA Bios
> functionality in the hardware emulation.

Doesn't the main BIOS clear the screen first thing at boot?  Not even
sure the reset is needed.

-- 
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 Tue Jan 24 11:11:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:11:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpeHG-00033R-TT; Tue, 24 Jan 2012 11:11:02 +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 1RpeHE-00033H-FG
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:11:00 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327403453!11614951!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6142 invoked from network); 24 Jan 2012 11:10:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-182.messagelabs.com with SMTP;
	24 Jan 2012 11:10: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 q0OBAmA2001405
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 06:10:49 -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 q0OBAh7b004569; Tue, 24 Jan 2012 06:10:44 -0500
Message-ID: <4F1E91AF.9040402@redhat.com>
Date: Tue, 24 Jan 2012 13:10:39 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
In-Reply-To: <4F1D9649.1000102@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 07:18 PM, Anthony Liguori wrote:
> Generally speaking, RAM is an independent device in most useful cases.  

Can you give examples?  Do you mean a subdevice with composition, or a
really independent device?

> Onboard RAM is a very special case because it's extremely unusual.

What's unusual (or even extremely unusual) about it?  I don't see a
difference between a few billion bits of state and, say, the few bits of
state in an RTC device.

> But since some video cards can make use of dedicated external RAM, I
> don't think any video card really depends on initial RAM state.
>
> What's most likely here is that the VGA BIOS of a Cirrus card sets an
> initial RAM state during device initialization.

Yes, that's likely.  DRAMs aren't reset and some state survives even a
short power off.

>
> We really should view RAM as just another device so I don't like the
> idea of propagating a global concept of "when RAM is restored" because
> that treats it specially compared to other devices.

Agree.  In fact the first step has been taken as now creating a RAM
region with memory_region_init_ram() doesn't register it for migration. 
The next step would be a VMSTATE_RAM() to make it part of the containing
device.

> But viewing RAM as just another device, having Xen only restore a
> subset of devices should be a reasonable thing to do moving forward. 
> The main problem here I believe is that we have part of the VGA Bios
> functionality in the hardware emulation.

Doesn't the main BIOS clear the screen first thing at boot?  Not even
sure the reset is needed.

-- 
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 Tue Jan 24 11:13:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpeJQ-0003AA-Eb; Tue, 24 Jan 2012 11:13:16 +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 1RpeJO-00039j-EQ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:13:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327403587!9983744!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16579 invoked from network); 24 Jan 2012 11:13:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 11:13: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 q0OBD4BZ010904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 06:13:04 -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 q0OBD1FS029170; Tue, 24 Jan 2012 06:13:02 -0500
Message-ID: <4F1E923D.2090208@redhat.com>
Date: Tue, 24 Jan 2012 13:13:01 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Gerd Hoffmann <kraxel@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>
	<4F1D9649.1000102@codemonkey.ws> <4F1D995A.4020604@siemens.com>
	<4F1D9A8E.1080102@codemonkey.ws> <4F1E8635.2020608@redhat.com>
In-Reply-To: <4F1E8635.2020608@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> >>>
> >>> But viewing RAM as just another device, having Xen only restore a
> >>> subset of
> >>> devices should be a reasonable thing to do moving forward.
>
> I don't think modeling device memory (i.e. vga vram) as something
> independent from the device (vga) is a good idea.  Because it isn't.

Right.  We should have VMSTATE_RAM() to express the dependency.

-- 
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 Tue Jan 24 11:13:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:13:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpeJQ-0003AA-Eb; Tue, 24 Jan 2012 11:13:16 +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 1RpeJO-00039j-EQ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:13:14 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327403587!9983744!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16579 invoked from network); 24 Jan 2012 11:13:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 11:13: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 q0OBD4BZ010904
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 06:13:04 -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 q0OBD1FS029170; Tue, 24 Jan 2012 06:13:02 -0500
Message-ID: <4F1E923D.2090208@redhat.com>
Date: Tue, 24 Jan 2012 13:13:01 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Gerd Hoffmann <kraxel@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>
	<4F1D9649.1000102@codemonkey.ws> <4F1D995A.4020604@siemens.com>
	<4F1D9A8E.1080102@codemonkey.ws> <4F1E8635.2020608@redhat.com>
In-Reply-To: <4F1E8635.2020608@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> >>>
> >>> But viewing RAM as just another device, having Xen only restore a
> >>> subset of
> >>> devices should be a reasonable thing to do moving forward.
>
> I don't think modeling device memory (i.e. vga vram) as something
> independent from the device (vga) is a good idea.  Because it isn't.

Right.  We should have VMSTATE_RAM() to express the dependency.

-- 
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 Tue Jan 24 11:17:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11: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 1RpeMu-0003ON-2g; Tue, 24 Jan 2012 11:16: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 1RpeMr-0003Nl-R2
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:16:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327403803!10446534!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10714 invoked from network); 24 Jan 2012 11:16:43 -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; 24 Jan 2012 11:16:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 11:16:42 +0000
Message-Id: <4F1EA172020000780006EA6E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 11:17:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
	<4F1D786A020000780006E6D1@nat28.tlf.novell.com>
	<20120123142232.GA8983@aepfle.de>
	<4F1D8145020000780006E70C@nat28.tlf.novell.com>
	<20120124102757.GA14598@aepfle.de>
In-Reply-To: <20120124102757.GA14598@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.01.12 at 11:27, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jan 23, Jan Beulich wrote:
> 
>> sle11sp2 (3.0): building fine.)
> 
> Not for the xen.src.rpm, it also contains this change. I think the

Oh, I wasn't even aware of that custom change of ours.

> reason is that the kernel sources are searched before the xen sources
> for asm/hypervisor.h:
> 
> /usr/src/linux-3.0.13-0.11/arch/x86/include/asm/hypervisor.h
> /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include/asm/hypervisor.h
>...
> Its probably not a bug to prefer kernel-source over local directories.

Agreed.

While it's still a hack (what if the function got un-inlined and exported),

Acked-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 Tue Jan 24 11:17:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11: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 1RpeMu-0003ON-2g; Tue, 24 Jan 2012 11:16: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 1RpeMr-0003Nl-R2
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:16:50 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327403803!10446534!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10714 invoked from network); 24 Jan 2012 11:16:43 -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; 24 Jan 2012 11:16:43 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 11:16:42 +0000
Message-Id: <4F1EA172020000780006EA6E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 11:17:54 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Olaf Hering" <olaf@aepfle.de>
References: <88bddf1f0bafade64316.1327326599@probook.site>
	<4F1D786A020000780006E6D1@nat28.tlf.novell.com>
	<20120123142232.GA8983@aepfle.de>
	<4F1D8145020000780006E70C@nat28.tlf.novell.com>
	<20120124102757.GA14598@aepfle.de>
In-Reply-To: <20120124102757.GA14598@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] pv drivers: wrap xen_cpuid_base()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.01.12 at 11:27, Olaf Hering <olaf@aepfle.de> wrote:
> On Mon, Jan 23, Jan Beulich wrote:
> 
>> sle11sp2 (3.0): building fine.)
> 
> Not for the xen.src.rpm, it also contains this change. I think the

Oh, I wasn't even aware of that custom change of ours.

> reason is that the kernel sources are searched before the xen sources
> for asm/hypervisor.h:
> 
> /usr/src/linux-3.0.13-0.11/arch/x86/include/asm/hypervisor.h
> /usr/src/packages/BUILD/xen-4.2.24547/non-dbg/obj/default/include/asm/hypervisor.h
>...
> Its probably not a bug to prefer kernel-source over local directories.

Agreed.

While it's still a hack (what if the function got un-inlined and exported),

Acked-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 Tue Jan 24 11:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpeXP-0003la-87; Tue, 24 Jan 2012 11:27:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1RpeXO-0003lV-0K
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:27:42 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327404454!10385067!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12378 invoked from network); 24 Jan 2012 11:27:35 -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;
	24 Jan 2012 11:27:35 -0000
Received: by iaeh11 with SMTP id h11so24622948iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 03:27:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=A4suDaE+s57+bLXEg6gxvxNYg9GV9i0ig+NtBvicBG0=;
	b=E7Aflybwgxs5Zw4uSAyi0Dr+gmTG3dRyhLgO6UL2XZRf8Acx7OJBikQYHwlUUGjb9R
	BIb66SkOeEODUvRU5h5Ou+FBYLBvMg+MAGI82j63xQgQ+eE4WMbzTxHryuV4Mu6FEFaE
	7Y3jhgIFMk0C3MJTuKAdwT8+tk6Ya2Rfv8klw=
Received: by 10.50.15.161 with SMTP id y1mr17162637igc.4.1327404454318;
	Tue, 24 Jan 2012 03:27:34 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id l28sm57804036ibc.3.2012.01.24.03.27.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 03:27:33 -0800 (PST)
Message-ID: <4F1E959F.4060001@redhat.com>
Date: Tue, 24 Jan 2012 12:27:27 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com>
In-Reply-To: <4F1E91AF.9040402@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 12:10 PM, Avi Kivity wrote:
>> But viewing RAM as just another device, having Xen only restore a
>> subset of devices should be a reasonable thing to do moving forward.
>> The main problem here I believe is that we have part of the VGA Bios
>> functionality in the hardware emulation.
>
> Doesn't the main BIOS clear the screen first thing at boot?  Not even
> sure the reset is needed.

Clearing the screen should only write to the RAM at 0xB8000 (and perhaps 
0xA0000 since IIRC it's where text-mode fonts lie).  The option ROM 
cannot even assume that the main BIOS knows about the VESA framebuffer, 
can it?

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpeXP-0003la-87; Tue, 24 Jan 2012 11:27:43 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1RpeXO-0003lV-0K
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:27:42 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327404454!10385067!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12378 invoked from network); 24 Jan 2012 11:27:35 -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;
	24 Jan 2012 11:27:35 -0000
Received: by iaeh11 with SMTP id h11so24622948iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 03:27:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=A4suDaE+s57+bLXEg6gxvxNYg9GV9i0ig+NtBvicBG0=;
	b=E7Aflybwgxs5Zw4uSAyi0Dr+gmTG3dRyhLgO6UL2XZRf8Acx7OJBikQYHwlUUGjb9R
	BIb66SkOeEODUvRU5h5Ou+FBYLBvMg+MAGI82j63xQgQ+eE4WMbzTxHryuV4Mu6FEFaE
	7Y3jhgIFMk0C3MJTuKAdwT8+tk6Ya2Rfv8klw=
Received: by 10.50.15.161 with SMTP id y1mr17162637igc.4.1327404454318;
	Tue, 24 Jan 2012 03:27:34 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id l28sm57804036ibc.3.2012.01.24.03.27.30
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 03:27:33 -0800 (PST)
Message-ID: <4F1E959F.4060001@redhat.com>
Date: Tue, 24 Jan 2012 12:27:27 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com>
In-Reply-To: <4F1E91AF.9040402@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 12:10 PM, Avi Kivity wrote:
>> But viewing RAM as just another device, having Xen only restore a
>> subset of devices should be a reasonable thing to do moving forward.
>> The main problem here I believe is that we have part of the VGA Bios
>> functionality in the hardware emulation.
>
> Doesn't the main BIOS clear the screen first thing at boot?  Not even
> sure the reset is needed.

Clearing the screen should only write to the RAM at 0xB8000 (and perhaps 
0xA0000 since IIRC it's where text-mode fonts lie).  The option ROM 
cannot even assume that the main BIOS knows about the VESA framebuffer, 
can it?

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:32:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11: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 1Rpeby-0003tL-VI; Tue, 24 Jan 2012 11:32:26 +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 1Rpebx-0003t9-13
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:32:25 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327404695!61502690!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7258 invoked from network); 24 Jan 2012 11:31:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 11:31:36 -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 q0OBWF7F015609
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 06:32:15 -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 q0OBWBw4017757; Tue, 24 Jan 2012 06:32:12 -0500
Message-ID: <4F1E96BA.40801@redhat.com>
Date: Tue, 24 Jan 2012 13:32:10 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
In-Reply-To: <4F1E959F.4060001@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 01:27 PM, Paolo Bonzini wrote:
> On 01/24/2012 12:10 PM, Avi Kivity wrote:
>>> But viewing RAM as just another device, having Xen only restore a
>>> subset of devices should be a reasonable thing to do moving forward.
>>> The main problem here I believe is that we have part of the VGA Bios
>>> functionality in the hardware emulation.
>>
>> Doesn't the main BIOS clear the screen first thing at boot?  Not even
>> sure the reset is needed.
>
> Clearing the screen should only write to the RAM at 0xB8000 (and
> perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
> option ROM cannot even assume that the main BIOS knows about the VESA
> framebuffer, can it?

Yes, but why should anything else be needed?

When you switch to a graphics mode, clear as much of the framebuffer as
you need.

-- 
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 Tue Jan 24 11:32:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11: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 1Rpeby-0003tL-VI; Tue, 24 Jan 2012 11:32:26 +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 1Rpebx-0003t9-13
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:32:25 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327404695!61502690!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7258 invoked from network); 24 Jan 2012 11:31:36 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 11:31:36 -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 q0OBWF7F015609
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 06:32:15 -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 q0OBWBw4017757; Tue, 24 Jan 2012 06:32:12 -0500
Message-ID: <4F1E96BA.40801@redhat.com>
Date: Tue, 24 Jan 2012 13:32:10 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
In-Reply-To: <4F1E959F.4060001@redhat.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 01:27 PM, Paolo Bonzini wrote:
> On 01/24/2012 12:10 PM, Avi Kivity wrote:
>>> But viewing RAM as just another device, having Xen only restore a
>>> subset of devices should be a reasonable thing to do moving forward.
>>> The main problem here I believe is that we have part of the VGA Bios
>>> functionality in the hardware emulation.
>>
>> Doesn't the main BIOS clear the screen first thing at boot?  Not even
>> sure the reset is needed.
>
> Clearing the screen should only write to the RAM at 0xB8000 (and
> perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
> option ROM cannot even assume that the main BIOS knows about the VESA
> framebuffer, can it?

Yes, but why should anything else be needed?

When you switch to a graphics mode, clear as much of the framebuffer as
you need.

-- 
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 Tue Jan 24 11:45:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11: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 1RpeoD-0004Op-0e; Tue, 24 Jan 2012 11:45:05 +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 1RpeoC-0004Of-3G
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:45:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327405497!12309788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12935 invoked from network); 24 Jan 2012 11:44:57 -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;
	24 Jan 2012 11:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10243951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:44: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, 24 Jan 2012 11:44: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
	1Rpeo4-0007Us-86; Tue, 24 Jan 2012 11:44:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpeo3-0004w9-Ug;
	Tue, 24 Jan 2012 11:44:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.39351.854362.661374@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 11:44:55 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Tim Deegan <tim@xen.org>, 
	Adin Scannell <adin@scanneel.ca>, Keir Fraser <keir@xen.org>
In-Reply-To: <osstest-11574-mainreport@xen.org>
References: <osstest-11574-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: 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

xen.org writes ("[xen-unstable test] 11574: tolerable FAIL"):
> Tests which are failing intermittently (not blocking):
>  test-amd64-i386-win           7 windows-install             fail pass in 11561

This is a host-specific, but deterministic, failure.  My bisector has
been working on it (the basis pass was in November so there has been a
lot of ground to cover and I had to make some new arrangements to be
able to run an ad-hoc bisection of this problem) and the results so
far are fingering changesets between 24367:537ceb11d51e (bad) and
24362:d35bedf334f2 (good).

Extract from hg log -v is below.

I have looked at the logs of one of these failures and there is
nothing of note.  The screenshot shows the Windows screensaver, so I
guess neither the guest itself nor qemu have crashed.  The likely
situation is either that the guest has somehow locked up and ceased to
make progress, or that the networking is nonfunctional.

I'm expecting the bisector to finger a specific changeset and will let
you know when it does, but this will take some more hours and maybe
only finish overnight or tomorrow.

Ian.

changeset:   24367:537ceb11d51e
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:31:49 2011 +0000
files:       xen/arch/x86/hvm/hvm.c
description:
Improve handling of nested page faults

Add checks for access type. Be less reliant on implicit semantics.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24366:534b2a15e669
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_sharing.c xen/arch/x86/mm/p2m.c xen/include/public/mem_event.h
description:
x86/mm: Allow dummy responses on the mem_event ring.

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>
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24365:c65d1a9769b4
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_event.c xen/arch/x86/mm/mem_sharing.c xen/arch/x86/mm/p2m.c xen/include/asm-x86/mem_event.h
description:
x86/mm: Consume multiple mem event responses off the ring

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scanneel.ca>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24364:0964341efd65
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_event.c
description:
x86/mm: Allow memevent responses to be signaled via the event channel

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>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24363:1620291f0c4a
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/ia64/vmx/vmx_init.c xen/arch/x86/hvm/hvm.c xen/arch/x86/mm/mem_event.c xen/common/event_channel.c xen/include/xen/event.h xen/include/xen/sched.h
description:
Create a generic callback mechanism for  Xen-bound event channels

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>
Committed-by: Tim Deegan <tim@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:45:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11: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 1RpeoD-0004Op-0e; Tue, 24 Jan 2012 11:45:05 +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 1RpeoC-0004Of-3G
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:45:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327405497!12309788!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12935 invoked from network); 24 Jan 2012 11:44:57 -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;
	24 Jan 2012 11:44:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10243951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:44: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, 24 Jan 2012 11:44: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
	1Rpeo4-0007Us-86; Tue, 24 Jan 2012 11:44:56 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpeo3-0004w9-Ug;
	Tue, 24 Jan 2012 11:44:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.39351.854362.661374@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 11:44:55 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Tim Deegan <tim@xen.org>, 
	Adin Scannell <adin@scanneel.ca>, Keir Fraser <keir@xen.org>
In-Reply-To: <osstest-11574-mainreport@xen.org>
References: <osstest-11574-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: 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

xen.org writes ("[xen-unstable test] 11574: tolerable FAIL"):
> Tests which are failing intermittently (not blocking):
>  test-amd64-i386-win           7 windows-install             fail pass in 11561

This is a host-specific, but deterministic, failure.  My bisector has
been working on it (the basis pass was in November so there has been a
lot of ground to cover and I had to make some new arrangements to be
able to run an ad-hoc bisection of this problem) and the results so
far are fingering changesets between 24367:537ceb11d51e (bad) and
24362:d35bedf334f2 (good).

Extract from hg log -v is below.

I have looked at the logs of one of these failures and there is
nothing of note.  The screenshot shows the Windows screensaver, so I
guess neither the guest itself nor qemu have crashed.  The likely
situation is either that the guest has somehow locked up and ceased to
make progress, or that the networking is nonfunctional.

I'm expecting the bisector to finger a specific changeset and will let
you know when it does, but this will take some more hours and maybe
only finish overnight or tomorrow.

Ian.

changeset:   24367:537ceb11d51e
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:31:49 2011 +0000
files:       xen/arch/x86/hvm/hvm.c
description:
Improve handling of nested page faults

Add checks for access type. Be less reliant on implicit semantics.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24366:534b2a15e669
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_sharing.c xen/arch/x86/mm/p2m.c xen/include/public/mem_event.h
description:
x86/mm: Allow dummy responses on the mem_event ring.

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>
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24365:c65d1a9769b4
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_event.c xen/arch/x86/mm/mem_sharing.c xen/arch/x86/mm/p2m.c xen/include/asm-x86/mem_event.h
description:
x86/mm: Consume multiple mem event responses off the ring

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scanneel.ca>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24364:0964341efd65
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/x86/mm/mem_event.c
description:
x86/mm: Allow memevent responses to be signaled via the event channel

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>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>


changeset:   24363:1620291f0c4a
user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
date:        Tue Dec 06 20:10:32 2011 +0000
files:       xen/arch/ia64/vmx/vmx_init.c xen/arch/x86/hvm/hvm.c xen/arch/x86/mm/mem_event.c xen/common/event_channel.c xen/include/xen/event.h xen/include/xen/sched.h
description:
Create a generic callback mechanism for  Xen-bound event channels

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>
Committed-by: Tim Deegan <tim@xen.org>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:45:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpeoI-0004Pb-KZ; Tue, 24 Jan 2012 11:45:10 +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 1RpeoH-0004Ok-4q
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:45:09 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327405385!60986848!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31631 invoked from network); 24 Jan 2012 11:43:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 11:43:06 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0OBiw54003241
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 06:44:58 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-25.ams2.redhat.com
	[10.36.112.25])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OBismR032623; Tue, 24 Jan 2012 06:44:55 -0500
Message-ID: <4F1E99B6.7010709@redhat.com>
Date: Tue, 24 Jan 2012 12:44:54 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
	<4F1E96BA.40801@redhat.com>
In-Reply-To: <4F1E96BA.40801@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 12:32 PM, Avi Kivity wrote:
>> >  Clearing the screen should only write to the RAM at 0xB8000 (and
>> >  perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
>> >  option ROM cannot even assume that the main BIOS knows about the VESA
>> >  framebuffer, can it?
> Yes, but why should anything else be needed?
>
> When you switch to a graphics mode, clear as much of the framebuffer as
> you need.

Based on the comments, Windows apparently disagrees. :)

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:45:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:45:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpeoI-0004Pb-KZ; Tue, 24 Jan 2012 11:45:10 +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 1RpeoH-0004Ok-4q
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:45:09 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327405385!60986848!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31631 invoked from network); 24 Jan 2012 11:43:06 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 11:43:06 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0OBiw54003241
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 06:44:58 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-25.ams2.redhat.com
	[10.36.112.25])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OBismR032623; Tue, 24 Jan 2012 06:44:55 -0500
Message-ID: <4F1E99B6.7010709@redhat.com>
Date: Tue, 24 Jan 2012 12:44:54 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Avi Kivity <avi@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
	<4F1E96BA.40801@redhat.com>
In-Reply-To: <4F1E96BA.40801@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 12:32 PM, Avi Kivity wrote:
>> >  Clearing the screen should only write to the RAM at 0xB8000 (and
>> >  perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
>> >  option ROM cannot even assume that the main BIOS knows about the VESA
>> >  framebuffer, can it?
> Yes, but why should anything else be needed?
>
> When you switch to a graphics mode, clear as much of the framebuffer as
> you need.

Based on the comments, Windows apparently disagrees. :)

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:52:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpev2-0004oy-I9; Tue, 24 Jan 2012 11:52: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 1Rpev2-0004ot-07
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:52:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327405879!61505988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11469 invoked from network); 24 Jan 2012 11:51:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 11:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10244134"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:52: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; Tue, 24 Jan 2012 11:52:01 +0000
Date: Tue, 24 Jan 2012 11:52:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F1E96BA.40801@redhat.com>
Message-ID: <alpine.DEB.2.00.1201241144230.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
	<4F1E96BA.40801@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 24 Jan 2012, Avi Kivity wrote:
> On 01/24/2012 01:27 PM, Paolo Bonzini wrote:
> > On 01/24/2012 12:10 PM, Avi Kivity wrote:
> >>> But viewing RAM as just another device, having Xen only restore a
> >>> subset of devices should be a reasonable thing to do moving forward.
> >>> The main problem here I believe is that we have part of the VGA Bios
> >>> functionality in the hardware emulation.
> >>
> >> Doesn't the main BIOS clear the screen first thing at boot?  Not even
> >> sure the reset is needed.
> >
> > Clearing the screen should only write to the RAM at 0xB8000 (and
> > perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
> > option ROM cannot even assume that the main BIOS knows about the VESA
> > framebuffer, can it?
> 
> Yes, but why should anything else be needed?
> 
> When you switch to a graphics mode, clear as much of the framebuffer as
> you need.

After installing Win2K, I managed to reproduce the issue with the old
qemu-xen and rombios (removing the memset in the vga emulator).
However I cannot reproduce the issue with upstream qemu and seabios
(even if I remove the memset).

I think that the memset was a workaround a bug in rombios, hence it is
not needed anymore.

Removing the cirrus_vga memset would solve the main issue we have left
with save/restore on Xen.
However it wouldn't solve the problem for QXL: as Gerd pointed out, QXL
needs a reset to initialize some memory regions, so another "if we are
restoring don't do that" would be required to make it work on Xen...

Maybe we can extend the loadvm == 1 to all the reset performed before
load_vmstate?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 11:52:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 11:52:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpev2-0004oy-I9; Tue, 24 Jan 2012 11:52: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 1Rpev2-0004ot-07
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:52:08 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327405879!61505988!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11469 invoked from network); 24 Jan 2012 11:51:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 11:51:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208";a="10244134"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:52: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; Tue, 24 Jan 2012 11:52:01 +0000
Date: Tue, 24 Jan 2012 11:52:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F1E96BA.40801@redhat.com>
Message-ID: <alpine.DEB.2.00.1201241144230.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
	<4F1E96BA.40801@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 24 Jan 2012, Avi Kivity wrote:
> On 01/24/2012 01:27 PM, Paolo Bonzini wrote:
> > On 01/24/2012 12:10 PM, Avi Kivity wrote:
> >>> But viewing RAM as just another device, having Xen only restore a
> >>> subset of devices should be a reasonable thing to do moving forward.
> >>> The main problem here I believe is that we have part of the VGA Bios
> >>> functionality in the hardware emulation.
> >>
> >> Doesn't the main BIOS clear the screen first thing at boot?  Not even
> >> sure the reset is needed.
> >
> > Clearing the screen should only write to the RAM at 0xB8000 (and
> > perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
> > option ROM cannot even assume that the main BIOS knows about the VESA
> > framebuffer, can it?
> 
> Yes, but why should anything else be needed?
> 
> When you switch to a graphics mode, clear as much of the framebuffer as
> you need.

After installing Win2K, I managed to reproduce the issue with the old
qemu-xen and rombios (removing the memset in the vga emulator).
However I cannot reproduce the issue with upstream qemu and seabios
(even if I remove the memset).

I think that the memset was a workaround a bug in rombios, hence it is
not needed anymore.

Removing the cirrus_vga memset would solve the main issue we have left
with save/restore on Xen.
However it wouldn't solve the problem for QXL: as Gerd pointed out, QXL
needs a reset to initialize some memory regions, so another "if we are
restoring don't do that" would be required to make it work on Xen...

Maybe we can extend the loadvm == 1 to all the reset performed before
load_vmstate?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 12:00:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 12:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpf2U-0004yg-OS; Tue, 24 Jan 2012 11:59:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rpf2T-0004yY-7g
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:59:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327406381!8378063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15278 invoked from network); 24 Jan 2012 11:59:42 -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;
	24 Jan 2012 11:59:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10244477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:59:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:59:40 +0000
Date: Tue, 24 Jan 2012 12:00:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F1E923D.2090208@redhat.com>
Message-ID: <alpine.DEB.2.00.1201241158240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com> <4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 24 Jan 2012, Avi Kivity wrote:
> On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> > >>>
> > >>> But viewing RAM as just another device, having Xen only restore a
> > >>> subset of
> > >>> devices should be a reasonable thing to do moving forward.
> >
> > I don't think modeling device memory (i.e. vga vram) as something
> > independent from the device (vga) is a good idea.  Because it isn't.
> 
> Right.  We should have VMSTATE_RAM() to express the dependency.

So if I understand correctly you are planning on removing the call to
vmstate_register_ram_global in hw/vga.c?
In that case it might be better if I wait for your "VMSTATE_RAM" patch
before I can send a new patch to save only non-RAM devices, because I
guess they will clash with one another.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 12:00:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 12:00:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpf2U-0004yg-OS; Tue, 24 Jan 2012 11:59:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rpf2T-0004yY-7g
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 11:59:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327406381!8378063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15278 invoked from network); 24 Jan 2012 11:59:42 -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;
	24 Jan 2012 11:59:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10244477"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:59:40 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:59:40 +0000
Date: Tue, 24 Jan 2012 12:00:07 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F1E923D.2090208@redhat.com>
Message-ID: <alpine.DEB.2.00.1201241158240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com> <4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 24 Jan 2012, Avi Kivity wrote:
> On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> > >>>
> > >>> But viewing RAM as just another device, having Xen only restore a
> > >>> subset of
> > >>> devices should be a reasonable thing to do moving forward.
> >
> > I don't think modeling device memory (i.e. vga vram) as something
> > independent from the device (vga) is a good idea.  Because it isn't.
> 
> Right.  We should have VMSTATE_RAM() to express the dependency.

So if I understand correctly you are planning on removing the call to
vmstate_register_ram_global in hw/vga.c?
In that case it might be better if I wait for your "VMSTATE_RAM" patch
before I can send a new patch to save only non-RAM devices, because I
guess they will clash with one another.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 12:02:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 12: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 1Rpf4e-0005Bb-D0; Tue, 24 Jan 2012 12:02:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rpf4c-0005BD-Ec
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 12:02:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327406514!10461747!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2452 invoked from network); 24 Jan 2012 12:01:55 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 12:01:55 -0000
Received: by iaeh11 with SMTP id h11so24749082iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 04:01:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=kfWXdXmGURfPMeCR8zpOulvGd/wCZn8Nc0A13vxgqYg=;
	b=meXNdKEoUylDNPiaDZvW8yUBOTB8hiaEWPb9O/q6kZyBn4u5/7Tx0Ay/mQVx3k4gVa
	FI2DRYAHBNHd7wzSYBf1f8d/Fr0QxjOxJ5Zsrw/JDziSAthhtp3jMrqET82SLA0apWUt
	C5ln1F5ghpmq/cWhnHcNBgrvnNXmkE6y7S3OI=
MIME-Version: 1.0
Received: by 10.50.42.167 with SMTP id p7mr14403729igl.20.1327406513716; Tue,
	24 Jan 2012 04:01:53 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Tue, 24 Jan 2012 04:01:53 -0800 (PST)
In-Reply-To: <CAFLBxZYJ3oYaXbPoFMYU5omN6rPQcR9zJm_FRJKxxYCKzg5iDQ@mail.gmail.com>
References: <fe8d0ca867aa280cbfb3.1326104556@wsm-ep-n0>
	<CAFLBxZYJ3oYaXbPoFMYU5omN6rPQcR9zJm_FRJKxxYCKzg5iDQ@mail.gmail.com>
Date: Tue, 24 Jan 2012 12:01:53 +0000
X-Google-Sender-Auth: EorlR8VZY9aWQJga_tdzKXW80I0
Message-ID: <CAFLBxZYa=yWp2aBrbN09MLyqhqEM86=zHAeQDuEEHeQY-6vJOg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Keir Fraser <keir@xen.org>
Cc: xen-devel@lists.xensource.com, raistlin@linux.it, 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="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 Tue, Jan 10, 2012 at 10:05 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Mon, Jan 9, 2012 at 10:22 AM, Hui Lv <hui.lv@intel.com> wrote:
>> Updated the warning sentence for ratelimit_us.
>>
>> This patch can improve Xen performance:
>> 1. Basically, the "delay method" can achieve 11% overall performance boo=
st for SPECvirt than original credit scheduler.
>> 2. We have tried 1ms delay and 10ms delay, there is no big difference be=
tween these two configurations. (1ms is enough to achieve a good performanc=
e)
>> 3. We have compared different load level response time/latency (low, hig=
h, peak), "delay method" didn't bring very much response time increase.
>> 4. 1ms delay can reduce 30% context switch at peak performance, where pr=
oduces the benefits. (int sched_ratelimit_us =3D 1000 is the recommended se=
tting)
>>
>> Signed-off-by: Hui Lv <hui.lv@intel.com>
>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> Just confirming this:
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> Thanks, Hui.
> =A0-George
>
>>
>> diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -0500
>> @@ -172,6 +172,7 @@ struct csched_private {
>> =A0 =A0 uint32_t credit;
>> =A0 =A0 int credit_balance;
>> =A0 =A0 uint32_t runq_sort;
>> + =A0 =A0unsigned ratelimit_us;
>> =A0 =A0 /* Period of master and tick in milliseconds */
>> =A0 =A0 unsigned tslice_ms, tick_period_us, ticks_per_tslice;
>> =A0 =A0 unsigned credits_per_tslice;
>> @@ -1297,10 +1298,15 @@ csched_schedule(
>> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
>> =A0 =A0 struct csched_vcpu *snext;
>> =A0 =A0 struct task_slice ret;
>> + =A0 =A0s_time_t runtime, tslice;
>>
>> =A0 =A0 CSCHED_STAT_CRANK(schedule);
>> =A0 =A0 CSCHED_VCPU_CHECK(current);
>>
>> + =A0 =A0runtime =3D now - current->runstate.state_entry_time;
>> + =A0 =A0if ( runtime < 0 ) /* Does this ever happen? */
>> + =A0 =A0 =A0 =A0runtime =3D 0;
>> +
>> =A0 =A0 if ( !is_idle_vcpu(scurr->vcpu) )
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 /* Update credits of a non-idle VCPU. */
>> @@ -1313,6 +1319,35 @@ csched_schedule(
>> =A0 =A0 =A0 =A0 scurr->pri =3D CSCHED_PRI_IDLE;
>> =A0 =A0 }
>>
>> + =A0 =A0/* Choices, choices:
>> + =A0 =A0 * - If we have a tasklet, we need to run the idle vcpu no matt=
er what.
>> + =A0 =A0 * - If sched rate limiting is in effect, and the current vcpu =
has
>> + =A0 =A0 * =A0 run for less than that amount of time, continue the curr=
ent one,
>> + =A0 =A0 * =A0 but with a shorter timeslice and return it immediately
>> + =A0 =A0 * - Otherwise, chose the one with the highest priority (which =
may
>> + =A0 =A0 * =A0 be the one currently running)
>> + =A0 =A0 * - If the currently running one is TS_OVER, see if there
>> + =A0 =A0 * =A0 is a higher priority one waiting on the runqueue of anot=
her
>> + =A0 =A0 * =A0 cpu and steal it.
>> + =A0 =A0 */
>> +
>> + =A0 =A0/* If we have schedule rate limiting enabled, check to see
>> + =A0 =A0 * how long we've run for. */
>> + =A0 =A0if ( !tasklet_work_scheduled
>> + =A0 =A0 =A0 =A0 && prv->ratelimit_us
>> + =A0 =A0 =A0 =A0 && vcpu_runnable(current)
>> + =A0 =A0 =A0 =A0 && !is_idle_vcpu(current)
>> + =A0 =A0 =A0 =A0 && runtime < MICROSECS(prv->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(prv->ratelimit_us);
>> + =A0 =A0 =A0 =A0ret.migrated =3D 0;
>> + =A0 =A0 =A0 =A0goto out;
>> + =A0 =A0}
>> + =A0 =A0tslice =3D MILLISECS(prv->tslice_ms);
>> +
>> =A0 =A0 /*
>> =A0 =A0 =A0* Select next runnable local VCPU (ie top of local runq)
>> =A0 =A0 =A0*/
>> @@ -1367,11 +1402,12 @@ csched_schedule(
>> =A0 =A0 if ( !is_idle_vcpu(snext->vcpu) )
>> =A0 =A0 =A0 =A0 snext->start_time +=3D now;
>>
>> +out:
>> =A0 =A0 /*
>> =A0 =A0 =A0* Return task to run next...
>> =A0 =A0 =A0*/
>> =A0 =A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ?
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(prv->tslice_ms));
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : tslice);
>> =A0 =A0 ret.task =3D snext->vcpu;
>>
>> =A0 =A0 CSCHED_VCPU_CHECK(ret.task);
>> @@ -1533,6 +1569,15 @@ csched_init(struct scheduler *ops)
>> =A0 =A0 prv->tick_period_us =3D prv->tslice_ms * 1000 / prv->ticks_per_t=
slice;
>> =A0 =A0 prv->credits_per_tslice =3D CSCHED_CREDITS_PER_MSEC * prv->tslic=
e_ms;
>>
>> + =A0 =A0if ( MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tsl=
ice_ms) )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0printk("WARNING: sched_ratelimit_us >"
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "sched_credit_tslice_ms is undefined\n"
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Setting ratelimit_us to 1000 * tslice_ms\=
n");
>> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D 1000 * prv->tslice_ms;
>> + =A0 =A0}
>> + =A0 =A0else
>> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D sched_ratelimit_us;
>> =A0 =A0 return 0;
>> =A0}
>>
>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
>> --- a/xen/common/schedule.c =A0 =A0 Fri Dec 16 18:46:27 2011 +0000
>> +++ b/xen/common/schedule.c =A0 =A0 Mon Jan 09 05:21:35 2012 -0500
>> @@ -47,6 +47,11 @@ string_param("sched", opt_sched);
>> =A0bool_t sched_smt_power_savings =3D 0;
>> =A0boolean_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_ts=
lice_ms is undefined
>> + * */
>> +int sched_ratelimit_us =3D 1000;
>> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
>> =A0/* Various timer handlers. */
>> =A0static void s_timer_fn(void *unused);
>> =A0static void vcpu_periodic_timer_fn(void *data);
>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/perfc_defn.h
>> --- a/xen/include/xen/perfc_defn.h =A0 =A0 =A0Fri Dec 16 18:46:27 2011 +=
0000
>> +++ b/xen/include/xen/perfc_defn.h =A0 =A0 =A0Mon Jan 09 05:21:35 2012 -=
0500
>> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sch
>> =A0PERFCOUNTER(sched_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: runs throug=
h scheduler")
>> =A0PERFCOUNTER(sched_ctx, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: context swi=
tches")
>>
>> +PERFCOUNTER(delay_ms, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: delay")
>> =A0PERFCOUNTER(vcpu_check, =A0 =A0 =A0 =A0 =A0 =A0 "csched: vcpu_check")
>> =A0PERFCOUNTER(schedule, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: schedule")
>> =A0PERFCOUNTER(acct_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: acct_run")
>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/sched-if.h
>> --- a/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Fri Dec 16 18:46:27 2011=
 +0000
>> +++ b/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Mon Jan 09 05:21:35 2012=
 -0500
>> @@ -16,6 +16,11 @@ extern struct cpupool *cpupool0;
>> =A0/* cpus currently in no cpupool */
>> =A0extern cpumask_t cpupool_free_cpus;
>>
>> +/* Scheduler generic parameters
>> + * */
>> +extern int sched_ratelimit_us;
>> +
>> +
>> =A0/*
>> =A0* In order to allow a scheduler to remap the lock->cpu mapping,
>> =A0* 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 12:02:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 12: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 1Rpf4e-0005Bb-D0; Tue, 24 Jan 2012 12:02:04 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dunlapg@gmail.com>) id 1Rpf4c-0005BD-Ec
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 12:02:02 +0000
X-Env-Sender: dunlapg@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327406514!10461747!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2452 invoked from network); 24 Jan 2012 12:01:55 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 12:01:55 -0000
Received: by iaeh11 with SMTP id h11so24749082iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 04:01:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=kfWXdXmGURfPMeCR8zpOulvGd/wCZn8Nc0A13vxgqYg=;
	b=meXNdKEoUylDNPiaDZvW8yUBOTB8hiaEWPb9O/q6kZyBn4u5/7Tx0Ay/mQVx3k4gVa
	FI2DRYAHBNHd7wzSYBf1f8d/Fr0QxjOxJ5Zsrw/JDziSAthhtp3jMrqET82SLA0apWUt
	C5ln1F5ghpmq/cWhnHcNBgrvnNXmkE6y7S3OI=
MIME-Version: 1.0
Received: by 10.50.42.167 with SMTP id p7mr14403729igl.20.1327406513716; Tue,
	24 Jan 2012 04:01:53 -0800 (PST)
Received: by 10.231.23.207 with HTTP; Tue, 24 Jan 2012 04:01:53 -0800 (PST)
In-Reply-To: <CAFLBxZYJ3oYaXbPoFMYU5omN6rPQcR9zJm_FRJKxxYCKzg5iDQ@mail.gmail.com>
References: <fe8d0ca867aa280cbfb3.1326104556@wsm-ep-n0>
	<CAFLBxZYJ3oYaXbPoFMYU5omN6rPQcR9zJm_FRJKxxYCKzg5iDQ@mail.gmail.com>
Date: Tue, 24 Jan 2012 12:01:53 +0000
X-Google-Sender-Auth: EorlR8VZY9aWQJga_tdzKXW80I0
Message-ID: <CAFLBxZYa=yWp2aBrbN09MLyqhqEM86=zHAeQDuEEHeQY-6vJOg@mail.gmail.com>
From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Keir Fraser <keir@xen.org>
Cc: xen-devel@lists.xensource.com, raistlin@linux.it, 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="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 Tue, Jan 10, 2012 at 10:05 AM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> On Mon, Jan 9, 2012 at 10:22 AM, Hui Lv <hui.lv@intel.com> wrote:
>> Updated the warning sentence for ratelimit_us.
>>
>> This patch can improve Xen performance:
>> 1. Basically, the "delay method" can achieve 11% overall performance boo=
st for SPECvirt than original credit scheduler.
>> 2. We have tried 1ms delay and 10ms delay, there is no big difference be=
tween these two configurations. (1ms is enough to achieve a good performanc=
e)
>> 3. We have compared different load level response time/latency (low, hig=
h, peak), "delay method" didn't bring very much response time increase.
>> 4. 1ms delay can reduce 30% context switch at peak performance, where pr=
oduces the benefits. (int sched_ratelimit_us =3D 1000 is the recommended se=
tting)
>>
>> Signed-off-by: Hui Lv <hui.lv@intel.com>
>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> Just confirming this:
> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>
> Thanks, Hui.
> =A0-George
>
>>
>> diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -0500
>> @@ -172,6 +172,7 @@ struct csched_private {
>> =A0 =A0 uint32_t credit;
>> =A0 =A0 int credit_balance;
>> =A0 =A0 uint32_t runq_sort;
>> + =A0 =A0unsigned ratelimit_us;
>> =A0 =A0 /* Period of master and tick in milliseconds */
>> =A0 =A0 unsigned tslice_ms, tick_period_us, ticks_per_tslice;
>> =A0 =A0 unsigned credits_per_tslice;
>> @@ -1297,10 +1298,15 @@ csched_schedule(
>> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
>> =A0 =A0 struct csched_vcpu *snext;
>> =A0 =A0 struct task_slice ret;
>> + =A0 =A0s_time_t runtime, tslice;
>>
>> =A0 =A0 CSCHED_STAT_CRANK(schedule);
>> =A0 =A0 CSCHED_VCPU_CHECK(current);
>>
>> + =A0 =A0runtime =3D now - current->runstate.state_entry_time;
>> + =A0 =A0if ( runtime < 0 ) /* Does this ever happen? */
>> + =A0 =A0 =A0 =A0runtime =3D 0;
>> +
>> =A0 =A0 if ( !is_idle_vcpu(scurr->vcpu) )
>> =A0 =A0 {
>> =A0 =A0 =A0 =A0 /* Update credits of a non-idle VCPU. */
>> @@ -1313,6 +1319,35 @@ csched_schedule(
>> =A0 =A0 =A0 =A0 scurr->pri =3D CSCHED_PRI_IDLE;
>> =A0 =A0 }
>>
>> + =A0 =A0/* Choices, choices:
>> + =A0 =A0 * - If we have a tasklet, we need to run the idle vcpu no matt=
er what.
>> + =A0 =A0 * - If sched rate limiting is in effect, and the current vcpu =
has
>> + =A0 =A0 * =A0 run for less than that amount of time, continue the curr=
ent one,
>> + =A0 =A0 * =A0 but with a shorter timeslice and return it immediately
>> + =A0 =A0 * - Otherwise, chose the one with the highest priority (which =
may
>> + =A0 =A0 * =A0 be the one currently running)
>> + =A0 =A0 * - If the currently running one is TS_OVER, see if there
>> + =A0 =A0 * =A0 is a higher priority one waiting on the runqueue of anot=
her
>> + =A0 =A0 * =A0 cpu and steal it.
>> + =A0 =A0 */
>> +
>> + =A0 =A0/* If we have schedule rate limiting enabled, check to see
>> + =A0 =A0 * how long we've run for. */
>> + =A0 =A0if ( !tasklet_work_scheduled
>> + =A0 =A0 =A0 =A0 && prv->ratelimit_us
>> + =A0 =A0 =A0 =A0 && vcpu_runnable(current)
>> + =A0 =A0 =A0 =A0 && !is_idle_vcpu(current)
>> + =A0 =A0 =A0 =A0 && runtime < MICROSECS(prv->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(prv->ratelimit_us);
>> + =A0 =A0 =A0 =A0ret.migrated =3D 0;
>> + =A0 =A0 =A0 =A0goto out;
>> + =A0 =A0}
>> + =A0 =A0tslice =3D MILLISECS(prv->tslice_ms);
>> +
>> =A0 =A0 /*
>> =A0 =A0 =A0* Select next runnable local VCPU (ie top of local runq)
>> =A0 =A0 =A0*/
>> @@ -1367,11 +1402,12 @@ csched_schedule(
>> =A0 =A0 if ( !is_idle_vcpu(snext->vcpu) )
>> =A0 =A0 =A0 =A0 snext->start_time +=3D now;
>>
>> +out:
>> =A0 =A0 /*
>> =A0 =A0 =A0* Return task to run next...
>> =A0 =A0 =A0*/
>> =A0 =A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ?
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(prv->tslice_ms));
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : tslice);
>> =A0 =A0 ret.task =3D snext->vcpu;
>>
>> =A0 =A0 CSCHED_VCPU_CHECK(ret.task);
>> @@ -1533,6 +1569,15 @@ csched_init(struct scheduler *ops)
>> =A0 =A0 prv->tick_period_us =3D prv->tslice_ms * 1000 / prv->ticks_per_t=
slice;
>> =A0 =A0 prv->credits_per_tslice =3D CSCHED_CREDITS_PER_MSEC * prv->tslic=
e_ms;
>>
>> + =A0 =A0if ( MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_tsl=
ice_ms) )
>> + =A0 =A0{
>> + =A0 =A0 =A0 =A0printk("WARNING: sched_ratelimit_us >"
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "sched_credit_tslice_ms is undefined\n"
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Setting ratelimit_us to 1000 * tslice_ms\=
n");
>> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D 1000 * prv->tslice_ms;
>> + =A0 =A0}
>> + =A0 =A0else
>> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D sched_ratelimit_us;
>> =A0 =A0 return 0;
>> =A0}
>>
>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
>> --- a/xen/common/schedule.c =A0 =A0 Fri Dec 16 18:46:27 2011 +0000
>> +++ b/xen/common/schedule.c =A0 =A0 Mon Jan 09 05:21:35 2012 -0500
>> @@ -47,6 +47,11 @@ string_param("sched", opt_sched);
>> =A0bool_t sched_smt_power_savings =3D 0;
>> =A0boolean_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_ts=
lice_ms is undefined
>> + * */
>> +int sched_ratelimit_us =3D 1000;
>> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
>> =A0/* Various timer handlers. */
>> =A0static void s_timer_fn(void *unused);
>> =A0static void vcpu_periodic_timer_fn(void *data);
>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/perfc_defn.h
>> --- a/xen/include/xen/perfc_defn.h =A0 =A0 =A0Fri Dec 16 18:46:27 2011 +=
0000
>> +++ b/xen/include/xen/perfc_defn.h =A0 =A0 =A0Mon Jan 09 05:21:35 2012 -=
0500
>> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sch
>> =A0PERFCOUNTER(sched_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: runs throug=
h scheduler")
>> =A0PERFCOUNTER(sched_ctx, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: context swi=
tches")
>>
>> +PERFCOUNTER(delay_ms, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: delay")
>> =A0PERFCOUNTER(vcpu_check, =A0 =A0 =A0 =A0 =A0 =A0 "csched: vcpu_check")
>> =A0PERFCOUNTER(schedule, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: schedule")
>> =A0PERFCOUNTER(acct_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: acct_run")
>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/sched-if.h
>> --- a/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Fri Dec 16 18:46:27 2011=
 +0000
>> +++ b/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Mon Jan 09 05:21:35 2012=
 -0500
>> @@ -16,6 +16,11 @@ extern struct cpupool *cpupool0;
>> =A0/* cpus currently in no cpupool */
>> =A0extern cpumask_t cpupool_free_cpus;
>>
>> +/* Scheduler generic parameters
>> + * */
>> +extern int sched_ratelimit_us;
>> +
>> +
>> =A0/*
>> =A0* In order to allow a scheduler to remap the lock->cpu mapping,
>> =A0* 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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 12:30:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 12:30:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpfVf-0005Wu-Ui; Tue, 24 Jan 2012 12:29: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 1RpfVe-0005Wp-FQ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 12:29:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327408192!10459522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9849 invoked from network); 24 Jan 2012 12:29:52 -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;
	24 Jan 2012 12:29:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10245706"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 12:29:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 12:29:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 24 Jan 2012 12:29:51 +0000
In-Reply-To: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327408191.24561.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>
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
 always fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 19:32 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
> xen_spinlock is 32 bits.  When a spin lock is contended and
> xl->spinners is modified the two bytes immediately after the spin lock
> would be corrupted.
> 
> This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
> (x86, ticketlock: Clean up types and accessors) which reduced the size
> of arch_spinlock_t.
> 
> Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
> BUILD_BUG_ON() is also added to check the sizes of the two structures
> are compatible.
> 
> In many cases this was not noticable as there would often be padding
> bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
> CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
> 
> The bnx2 driver is affected. In struct bnx2, phy_lock and
> indirect_lock may have no padding after them.  Contention on phy_lock
> would corrupt indirect_lock making it appear locked and the driver
> would deadlock.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Very good catch!

> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> ---
>  arch/x86/xen/spinlock.c |   27 ++++++++++++++++++++++-----
>  1 files changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index cc9b1e1..d69cc6c 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -116,9 +116,26 @@ static inline void spin_time_accum_blocked(u64 start)
>  }
>  #endif  /* CONFIG_XEN_DEBUG_FS */
>  
> +/*
> + * Size struct xen_spinlock so it's the same as arch_spinlock_t.
> + */
> +#if NR_CPUS < 256
> +typedef u8 xen_spinners_t;
> +# define inc_spinners(xl) \
> +	asm(LOCK_PREFIX " incb %0" : "+m" ((xl)->spinners) : : "memory");
> +# define dec_spinners(xl) \
> +	asm(LOCK_PREFIX " decb %0" : "+m" ((xl)->spinners) : : "memory");
> +#else
> +typedef u16 xen_spinners_t;
> +# define inc_spinners(xl) \
> +	asm(LOCK_PREFIX " incw %0" : "+m" ((xl)->spinners) : : "memory");
> +# define dec_spinners(xl) \
> +	asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
> +#endif
> +
>  struct xen_spinlock {
>  	unsigned char lock;		/* 0 -> free; 1 -> locked */
> -	unsigned short spinners;	/* count of waiting cpus */
> +	xen_spinners_t spinners;	/* count of waiting cpus */
>  };
>  
>  static int xen_spin_is_locked(struct arch_spinlock *lock)
> @@ -164,8 +181,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
>  
>  	wmb();			/* set lock of interest before count */
>  
> -	asm(LOCK_PREFIX " incw %0"
> -	    : "+m" (xl->spinners) : : "memory");
> +	inc_spinners(xl);
>  
>  	return prev;
>  }
> @@ -176,8 +192,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
>   */
>  static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev)
>  {
> -	asm(LOCK_PREFIX " decw %0"
> -	    : "+m" (xl->spinners) : : "memory");
> +	dec_spinners(xl);
>  	wmb();			/* decrement count before restoring lock */
>  	__this_cpu_write(lock_spinners, prev);
>  }
> @@ -373,6 +388,8 @@ void xen_uninit_lock_cpu(int cpu)
>  
>  void __init xen_init_spinlocks(void)
>  {
> +	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
> +
>  	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
>  	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
>  	pv_lock_ops.spin_lock = xen_spin_lock;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 12:30:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 12:30:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpfVf-0005Wu-Ui; Tue, 24 Jan 2012 12:29: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 1RpfVe-0005Wp-FQ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 12:29:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327408192!10459522!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9849 invoked from network); 24 Jan 2012 12:29:52 -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;
	24 Jan 2012 12:29:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10245706"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 12:29:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 12:29:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: David Vrabel <david.vrabel@citrix.com>
Date: Tue, 24 Jan 2012 12:29:51 +0000
In-Reply-To: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
References: <1327347145-16439-1-git-send-email-david.vrabel@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327408191.24561.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>
Subject: Re: [Xen-devel] [PATCH] x86: xen: size struct xen_spinlock to
 always fit in arch_spinlock_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 19:32 +0000, David Vrabel wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> 
> If NR_CPUS < 256 then arch_spinlock_t is only 16 bits wide but struct
> xen_spinlock is 32 bits.  When a spin lock is contended and
> xl->spinners is modified the two bytes immediately after the spin lock
> would be corrupted.
> 
> This is a regression caused by 84eb950db13ca40a0572ce9957e14723500943d6
> (x86, ticketlock: Clean up types and accessors) which reduced the size
> of arch_spinlock_t.
> 
> Fix this by making xl->spinners a u8 if NR_CPUS < 256.  A
> BUILD_BUG_ON() is also added to check the sizes of the two structures
> are compatible.
> 
> In many cases this was not noticable as there would often be padding
> bytes after the lock (e.g., if any of CONFIG_GENERIC_LOCKBREAK,
> CONFIG_DEBUG_SPINLOCK, or CONFIG_DEBUG_LOCK_ALLOC were enabled).
> 
> The bnx2 driver is affected. In struct bnx2, phy_lock and
> indirect_lock may have no padding after them.  Contention on phy_lock
> would corrupt indirect_lock making it appear locked and the driver
> would deadlock.
> 
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Very good catch!

> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
> ---
>  arch/x86/xen/spinlock.c |   27 ++++++++++++++++++++++-----
>  1 files changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index cc9b1e1..d69cc6c 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -116,9 +116,26 @@ static inline void spin_time_accum_blocked(u64 start)
>  }
>  #endif  /* CONFIG_XEN_DEBUG_FS */
>  
> +/*
> + * Size struct xen_spinlock so it's the same as arch_spinlock_t.
> + */
> +#if NR_CPUS < 256
> +typedef u8 xen_spinners_t;
> +# define inc_spinners(xl) \
> +	asm(LOCK_PREFIX " incb %0" : "+m" ((xl)->spinners) : : "memory");
> +# define dec_spinners(xl) \
> +	asm(LOCK_PREFIX " decb %0" : "+m" ((xl)->spinners) : : "memory");
> +#else
> +typedef u16 xen_spinners_t;
> +# define inc_spinners(xl) \
> +	asm(LOCK_PREFIX " incw %0" : "+m" ((xl)->spinners) : : "memory");
> +# define dec_spinners(xl) \
> +	asm(LOCK_PREFIX " decw %0" : "+m" ((xl)->spinners) : : "memory");
> +#endif
> +
>  struct xen_spinlock {
>  	unsigned char lock;		/* 0 -> free; 1 -> locked */
> -	unsigned short spinners;	/* count of waiting cpus */
> +	xen_spinners_t spinners;	/* count of waiting cpus */
>  };
>  
>  static int xen_spin_is_locked(struct arch_spinlock *lock)
> @@ -164,8 +181,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
>  
>  	wmb();			/* set lock of interest before count */
>  
> -	asm(LOCK_PREFIX " incw %0"
> -	    : "+m" (xl->spinners) : : "memory");
> +	inc_spinners(xl);
>  
>  	return prev;
>  }
> @@ -176,8 +192,7 @@ static inline struct xen_spinlock *spinning_lock(struct xen_spinlock *xl)
>   */
>  static inline void unspinning_lock(struct xen_spinlock *xl, struct xen_spinlock *prev)
>  {
> -	asm(LOCK_PREFIX " decw %0"
> -	    : "+m" (xl->spinners) : : "memory");
> +	dec_spinners(xl);
>  	wmb();			/* decrement count before restoring lock */
>  	__this_cpu_write(lock_spinners, prev);
>  }
> @@ -373,6 +388,8 @@ void xen_uninit_lock_cpu(int cpu)
>  
>  void __init xen_init_spinlocks(void)
>  {
> +	BUILD_BUG_ON(sizeof(struct xen_spinlock) > sizeof(arch_spinlock_t));
> +
>  	pv_lock_ops.spin_is_locked = xen_spin_is_locked;
>  	pv_lock_ops.spin_is_contended = xen_spin_is_contended;
>  	pv_lock_ops.spin_lock = xen_spin_lock;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 12:41:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 12:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpfg6-0005hy-3d; Tue, 24 Jan 2012 12:40:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rpfg4-0005ht-Kd
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 12:40:44 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327408800!61514561!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25035 invoked from network); 24 Jan 2012 12:40:00 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-9.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 12:40:00 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0OCeePd023336;
	Tue, 24 Jan 2012 07:40:40 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0OCeePQ022066;
	Tue, 24 Jan 2012 07:40:40 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012407403911061 ; Tue, 24 Jan 2012 07:40:39 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1327361981.14809.140661027127213@webmail.messagingengine.com>
Date: Tue, 24 Jan 2012 07:40:39 -0500
Message-Id: <3576FFC8-AEF0-4F29-976F-F5E70FF216C9@nrl.navy.mil>
References: <1327172879.12733.140661026288845@webmail.messagingengine.com>
	<1327361981.14809.140661027127213@webmail.messagingengine.com>
To: erin.balid@inoutbox.com
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [opensuse-virtual] After switching from "xm" to
	"xl" toolstack, can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Erin,

We also have what appears to be this problem, on Fedora 16 with Xen 4.1.2. We can create guests with xm that connect to network but the same guest will not connect, when created by xl. In both cases we can see the appropriate vif has been created and attached (xl network-list shows it) but no connectivity from within the guest. (If I convert the same guest config file to virsh format, then virsh also creates and connects it to the network successfully.)

I post this to the list as evidence that this is not just a problem with SuSE.

Sincerely,

John


On Jan 23, 2012, at 6:39 PM, erin.balid@inoutbox.com wrote:

> Hi All.
> 
> This problem's got a little - not a lot! - of traction over at the
> xen-devel list.
> 
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01754.html. 
> 
> Rather than leave this open & uncommented here, I'm going to concentrate
> on that thread instead for now.
> 
> Erin
> -- 
> To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org
> To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 12:41:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 12:41:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpfg6-0005hy-3d; Tue, 24 Jan 2012 12:40:46 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rpfg4-0005ht-Kd
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 12:40:44 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327408800!61514561!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25035 invoked from network); 24 Jan 2012 12:40:00 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-9.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 12:40:00 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0OCeePd023336;
	Tue, 24 Jan 2012 07:40:40 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0OCeePQ022066;
	Tue, 24 Jan 2012 07:40:40 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012407403911061 ; Tue, 24 Jan 2012 07:40:39 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1327361981.14809.140661027127213@webmail.messagingengine.com>
Date: Tue, 24 Jan 2012 07:40:39 -0500
Message-Id: <3576FFC8-AEF0-4F29-976F-F5E70FF216C9@nrl.navy.mil>
References: <1327172879.12733.140661026288845@webmail.messagingengine.com>
	<1327361981.14809.140661027127213@webmail.messagingengine.com>
To: erin.balid@inoutbox.com
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [opensuse-virtual] After switching from "xm" to
	"xl" toolstack, can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Erin,

We also have what appears to be this problem, on Fedora 16 with Xen 4.1.2. We can create guests with xm that connect to network but the same guest will not connect, when created by xl. In both cases we can see the appropriate vif has been created and attached (xl network-list shows it) but no connectivity from within the guest. (If I convert the same guest config file to virsh format, then virsh also creates and connects it to the network successfully.)

I post this to the list as evidence that this is not just a problem with SuSE.

Sincerely,

John


On Jan 23, 2012, at 6:39 PM, erin.balid@inoutbox.com wrote:

> Hi All.
> 
> This problem's got a little - not a lot! - of traction over at the
> xen-devel list.
> 
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01754.html. 
> 
> Rather than leave this open & uncommented here, I'm going to concentrate
> on that thread instead for now.
> 
> Erin
> -- 
> To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org
> To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 13:15:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgDH-00068p-7q; Tue, 24 Jan 2012 13:15:03 +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 1RpgDF-00068k-BL
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:15:01 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327410893!12157337!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1287 invoked from network); 24 Jan 2012 13:14:54 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 13:14:54 -0000
Received: by ggnk3 with SMTP id k3so46389629ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 05:14:53 -0800 (PST)
Received: by 10.50.173.98 with SMTP id bj2mr2239127igc.27.1327410892904;
	Tue, 24 Jan 2012 05:14:52 -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 vg9sm29337265igb.4.2012.01.24.05.14.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 05:14:51 -0800 (PST)
Message-ID: <4F1EAEC7.5050304@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:14:47 -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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com>
In-Reply-To: <4F1E91AF.9040402@redhat.com>
X-Gm-Message-State: ALoCoQni2RT8rge4yEP0bapqG+oVAwdU4aV5kzlHv2vhIY4VsCVwlwIUi76PDkipKUkux0H6lhtI
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 05:10 AM, Avi Kivity wrote:
> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>> Generally speaking, RAM is an independent device in most useful cases.
>
> Can you give examples?  Do you mean a subdevice with composition, or a
> really independent device?

I expect we'll have one Ram device.  It's size will be configurable.  One Ram 
device will hang off of the machine which would be the main ram.

A video card would have a Ram device via composition.

The important consideration about reset is how it propagates.  My expectation is 
that we'll propagate reset through the composition tree in a preorder 
transversal.  That means in the VGA device reset function, it's child device 
(Ram) has not been reset yet.

>> Onboard RAM is a very special case because it's extremely unusual.
>
> What's unusual (or even extremely unusual) about it?  I don't see a
> difference between a few billion bits of state and, say, the few bits of
> state in an RTC device.

Okay, but let's not get philosophical here :-)  There are very few devices that 
have a DRAM chip that is mapped through a bar into the main address space and 
behaves (usually) like normal RAM.

>> We really should view RAM as just another device so I don't like the
>> idea of propagating a global concept of "when RAM is restored" because
>> that treats it specially compared to other devices.
>
> Agree.  In fact the first step has been taken as now creating a RAM
> region with memory_region_init_ram() doesn't register it for migration.
> The next step would be a VMSTATE_RAM() to make it part of the containing
> device.

That's not necessary (or wise).

Let's not confuse a Ram device with a MemoryRegion.  They are separate things 
and should be treated as separate things.  I thought we discussed that 
MemoryRegions are stateless (or at least, there state is all derived) and don't 
need to be serialized?

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 Tue Jan 24 13:15:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:15:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgDH-00068p-7q; Tue, 24 Jan 2012 13:15:03 +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 1RpgDF-00068k-BL
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:15:01 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327410893!12157337!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1287 invoked from network); 24 Jan 2012 13:14:54 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 13:14:54 -0000
Received: by ggnk3 with SMTP id k3so46389629ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 05:14:53 -0800 (PST)
Received: by 10.50.173.98 with SMTP id bj2mr2239127igc.27.1327410892904;
	Tue, 24 Jan 2012 05:14:52 -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 vg9sm29337265igb.4.2012.01.24.05.14.49
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 05:14:51 -0800 (PST)
Message-ID: <4F1EAEC7.5050304@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:14:47 -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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com>
In-Reply-To: <4F1E91AF.9040402@redhat.com>
X-Gm-Message-State: ALoCoQni2RT8rge4yEP0bapqG+oVAwdU4aV5kzlHv2vhIY4VsCVwlwIUi76PDkipKUkux0H6lhtI
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 05:10 AM, Avi Kivity wrote:
> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>> Generally speaking, RAM is an independent device in most useful cases.
>
> Can you give examples?  Do you mean a subdevice with composition, or a
> really independent device?

I expect we'll have one Ram device.  It's size will be configurable.  One Ram 
device will hang off of the machine which would be the main ram.

A video card would have a Ram device via composition.

The important consideration about reset is how it propagates.  My expectation is 
that we'll propagate reset through the composition tree in a preorder 
transversal.  That means in the VGA device reset function, it's child device 
(Ram) has not been reset yet.

>> Onboard RAM is a very special case because it's extremely unusual.
>
> What's unusual (or even extremely unusual) about it?  I don't see a
> difference between a few billion bits of state and, say, the few bits of
> state in an RTC device.

Okay, but let's not get philosophical here :-)  There are very few devices that 
have a DRAM chip that is mapped through a bar into the main address space and 
behaves (usually) like normal RAM.

>> We really should view RAM as just another device so I don't like the
>> idea of propagating a global concept of "when RAM is restored" because
>> that treats it specially compared to other devices.
>
> Agree.  In fact the first step has been taken as now creating a RAM
> region with memory_region_init_ram() doesn't register it for migration.
> The next step would be a VMSTATE_RAM() to make it part of the containing
> device.

That's not necessary (or wise).

Let's not confuse a Ram device with a MemoryRegion.  They are separate things 
and should be treated as separate things.  I thought we discussed that 
MemoryRegions are stateless (or at least, there state is all derived) and don't 
need to be serialized?

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 Tue Jan 24 13:16:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:16:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgEE-0006Bf-Ls; Tue, 24 Jan 2012 13:16:02 +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 1RpgEC-0006BS-CM
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:16:00 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327410911!51374968!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30927 invoked from network); 24 Jan 2012 13:15:12 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 13:15:12 -0000
Received: by iaeh11 with SMTP id h11so24996539iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 05:15:57 -0800 (PST)
Received: by 10.42.153.6 with SMTP id k6mr11592011icw.30.1327410957660;
	Tue, 24 Jan 2012 05:15:57 -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 z22sm58682273ibg.5.2012.01.24.05.15.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 05:15:56 -0800 (PST)
Message-ID: <4F1EAF09.3030105@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:15:53 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
	<4F1E96BA.40801@redhat.com>
	<alpine.DEB.2.00.1201241144230.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201241144230.3196@kaball-desktop>
X-Gm-Message-State: ALoCoQkUXxucQ6LKNo8t7Uo7yo0JlHQyuwpCqVsarxTxsey1HEy1VIlPwljpeemK55OTJ3ikpIy/
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 05:52 AM, Stefano Stabellini wrote:
> On Tue, 24 Jan 2012, Avi Kivity wrote:
>> On 01/24/2012 01:27 PM, Paolo Bonzini wrote:
>>> On 01/24/2012 12:10 PM, Avi Kivity wrote:
>>>>> But viewing RAM as just another device, having Xen only restore a
>>>>> subset of devices should be a reasonable thing to do moving forward.
>>>>> The main problem here I believe is that we have part of the VGA Bios
>>>>> functionality in the hardware emulation.
>>>>
>>>> Doesn't the main BIOS clear the screen first thing at boot?  Not even
>>>> sure the reset is needed.
>>>
>>> Clearing the screen should only write to the RAM at 0xB8000 (and
>>> perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
>>> option ROM cannot even assume that the main BIOS knows about the VESA
>>> framebuffer, can it?
>>
>> Yes, but why should anything else be needed?
>>
>> When you switch to a graphics mode, clear as much of the framebuffer as
>> you need.
>
> After installing Win2K, I managed to reproduce the issue with the old
> qemu-xen and rombios (removing the memset in the vga emulator).
> However I cannot reproduce the issue with upstream qemu and seabios
> (even if I remove the memset).
>
> I think that the memset was a workaround a bug in rombios, hence it is
> not needed anymore.
>
> Removing the cirrus_vga memset would solve the main issue we have left
> with save/restore on Xen.
> However it wouldn't solve the problem for QXL: as Gerd pointed out, QXL
> needs a reset to initialize some memory regions, so another "if we are
> restoring don't do that" would be required to make it work on Xen...

I believe this is a bug in QXL (or misdesign).  It should move this logic into 
the VGA Bios.

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 Tue Jan 24 13:16:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:16:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgEE-0006Bf-Ls; Tue, 24 Jan 2012 13:16:02 +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 1RpgEC-0006BS-CM
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:16:00 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327410911!51374968!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30927 invoked from network); 24 Jan 2012 13:15:12 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 13:15:12 -0000
Received: by iaeh11 with SMTP id h11so24996539iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 05:15:57 -0800 (PST)
Received: by 10.42.153.6 with SMTP id k6mr11592011icw.30.1327410957660;
	Tue, 24 Jan 2012 05:15:57 -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 z22sm58682273ibg.5.2012.01.24.05.15.54
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 05:15:56 -0800 (PST)
Message-ID: <4F1EAF09.3030105@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:15:53 -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: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
	<4F1E96BA.40801@redhat.com>
	<alpine.DEB.2.00.1201241144230.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201241144230.3196@kaball-desktop>
X-Gm-Message-State: ALoCoQkUXxucQ6LKNo8t7Uo7yo0JlHQyuwpCqVsarxTxsey1HEy1VIlPwljpeemK55OTJ3ikpIy/
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 05:52 AM, Stefano Stabellini wrote:
> On Tue, 24 Jan 2012, Avi Kivity wrote:
>> On 01/24/2012 01:27 PM, Paolo Bonzini wrote:
>>> On 01/24/2012 12:10 PM, Avi Kivity wrote:
>>>>> But viewing RAM as just another device, having Xen only restore a
>>>>> subset of devices should be a reasonable thing to do moving forward.
>>>>> The main problem here I believe is that we have part of the VGA Bios
>>>>> functionality in the hardware emulation.
>>>>
>>>> Doesn't the main BIOS clear the screen first thing at boot?  Not even
>>>> sure the reset is needed.
>>>
>>> Clearing the screen should only write to the RAM at 0xB8000 (and
>>> perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
>>> option ROM cannot even assume that the main BIOS knows about the VESA
>>> framebuffer, can it?
>>
>> Yes, but why should anything else be needed?
>>
>> When you switch to a graphics mode, clear as much of the framebuffer as
>> you need.
>
> After installing Win2K, I managed to reproduce the issue with the old
> qemu-xen and rombios (removing the memset in the vga emulator).
> However I cannot reproduce the issue with upstream qemu and seabios
> (even if I remove the memset).
>
> I think that the memset was a workaround a bug in rombios, hence it is
> not needed anymore.
>
> Removing the cirrus_vga memset would solve the main issue we have left
> with save/restore on Xen.
> However it wouldn't solve the problem for QXL: as Gerd pointed out, QXL
> needs a reset to initialize some memory regions, so another "if we are
> restoring don't do that" would be required to make it work on Xen...

I believe this is a bug in QXL (or misdesign).  It should move this logic into 
the VGA Bios.

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 Tue Jan 24 13:19:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgHG-0006ok-VN; Tue, 24 Jan 2012 13:19:10 +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 1RpgHF-0006o3-KE
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:19:09 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327411083!58209592!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20952 invoked from network); 24 Jan 2012 13:18:04 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 13:18:04 -0000
Received: by iaeh11 with SMTP id h11so25005747iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 05:19:02 -0800 (PST)
Received: by 10.50.216.201 with SMTP id os9mr3500844igc.22.1327411142236;
	Tue, 24 Jan 2012 05:19:02 -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 py9sm29370632igc.2.2012.01.24.05.18.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 05:19:01 -0800 (PST)
Message-ID: <4F1EAFC1.6040204@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:18:57 -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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
In-Reply-To: <4F1E923D.2090208@redhat.com>
X-Gm-Message-State: ALoCoQnIIUOhcLF2S/BqriRV6hb1aRJLKnHb55gT7+ASTINVqNlHb994YZd5677rdwDXG6x5U+do
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 05:13 AM, Avi Kivity wrote:
> On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
>>>>>
>>>>> But viewing RAM as just another device, having Xen only restore a
>>>>> subset of
>>>>> devices should be a reasonable thing to do moving forward.
>>
>> I don't think modeling device memory (i.e. vga vram) as something
>> independent from the device (vga) is a good idea.  Because it isn't.
>
> Right.  We should have VMSTATE_RAM() to express the dependency.

No, VMSTATE has nothign to do with reset.

Ram should be a device and then you can hook up ram through the composition tree.

But reset is going to propagate preorder, not postorder, so this isn't going to 
help anyway.

Postorder initialization doesn't make a whole lot of sense when you think about 
the semantics of it.

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 Tue Jan 24 13:19:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:19:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgHG-0006ok-VN; Tue, 24 Jan 2012 13:19:10 +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 1RpgHF-0006o3-KE
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:19:09 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327411083!58209592!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20952 invoked from network); 24 Jan 2012 13:18:04 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 13:18:04 -0000
Received: by iaeh11 with SMTP id h11so25005747iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 05:19:02 -0800 (PST)
Received: by 10.50.216.201 with SMTP id os9mr3500844igc.22.1327411142236;
	Tue, 24 Jan 2012 05:19:02 -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 py9sm29370632igc.2.2012.01.24.05.18.59
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 05:19:01 -0800 (PST)
Message-ID: <4F1EAFC1.6040204@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:18:57 -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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
In-Reply-To: <4F1E923D.2090208@redhat.com>
X-Gm-Message-State: ALoCoQnIIUOhcLF2S/BqriRV6hb1aRJLKnHb55gT7+ASTINVqNlHb994YZd5677rdwDXG6x5U+do
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 05:13 AM, Avi Kivity wrote:
> On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
>>>>>
>>>>> But viewing RAM as just another device, having Xen only restore a
>>>>> subset of
>>>>> devices should be a reasonable thing to do moving forward.
>>
>> I don't think modeling device memory (i.e. vga vram) as something
>> independent from the device (vga) is a good idea.  Because it isn't.
>
> Right.  We should have VMSTATE_RAM() to express the dependency.

No, VMSTATE has nothign to do with reset.

Ram should be a device and then you can hook up ram through the composition tree.

But reset is going to propagate preorder, not postorder, so this isn't going to 
help anyway.

Postorder initialization doesn't make a whole lot of sense when you think about 
the semantics of it.

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 Tue Jan 24 13:25:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:25:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgNA-0007MB-VK; Tue, 24 Jan 2012 13:25:16 +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 1RpgN8-0007Lx-MJ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:25:14 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327411507!8396637!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4418 invoked from network); 24 Jan 2012 13:25:08 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 13:25:08 -0000
Received: by iaeh11 with SMTP id h11so25024066iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 05:25:06 -0800 (PST)
Received: by 10.50.180.233 with SMTP id dr9mr2323625igc.11.1327411506743;
	Tue, 24 Jan 2012 05:25:06 -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 ba5sm22575099igb.6.2012.01.24.05.25.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 05:25:05 -0800 (PST)
Message-ID: <4F1EB12E.5080802@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:25:02 -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: Gerd Hoffmann <kraxel@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com>
In-Reply-To: <4F1E8635.2020608@redhat.com>
X-Gm-Message-State: ALoCoQkNmdM8k26eZJaJ2mvsEdRA+zwXHbOaUn6Dc3O7Tf0RxMCE+1iJeudLH2b49AY8k8kxr7+F
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 04:21 AM, Gerd Hoffmann wrote:
>    Hi,
>
>>>> We really should view RAM as just another device so I don't like the
>>>> idea of
>>>> propagating a global concept of "when RAM is restored" because that
>>>> treats it
>>>> specially compared to other devices.
>>>>
>>>> But viewing RAM as just another device, having Xen only restore a
>>>> subset of
>>>> devices should be a reasonable thing to do moving forward.
>
> I don't think modeling device memory (i.e. vga vram) as something
> independent from the device (vga) is a good idea.  Because it isn't.

It is, but probably not in the way you're assuming that I mean it is.

>
>>> To my understanding, QXL will break identically on Xen for the same
>>> reason: the reset handler assumes it can deal with the VRAM as it likes.
>
> Yes.  Some data structures for host<->  guest communication are living
> in device memory, and a reset initializes these.

This should be done by firmware or system software.  Devices don't initialize 
memory with data structures on power up.  The first problem with doing this is 
that it assumes a reset order which would lengthen the quiescing process.  The 
second problem is that this would require fairly sophisticated logic that could 
just as well live in firmware.

The advantage of not enabling a device to behave like this is it lets us do a 
much simpler reset model.  To model this properly, we would have to support 
multiple reset propagation hooks (at least a preorder and postorder hook).  This 
adds a fair amount of complication for not a lot of benefit (the only benefit is 
moving firmware logic into QEMU which is really a downside :-)).

Regards,

Anthony Liguori

>
>> QXL also has a VGA BIOS that it could use to initialize VRAM.  A similar
>> change could be made for it.
>
> Hmm.  Not sure this is a good idea.
>
> cheers,
>    Gerd
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 13:25:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:25:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgNA-0007MB-VK; Tue, 24 Jan 2012 13:25:16 +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 1RpgN8-0007Lx-MJ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:25:14 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327411507!8396637!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4418 invoked from network); 24 Jan 2012 13:25:08 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 13:25:08 -0000
Received: by iaeh11 with SMTP id h11so25024066iae.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 05:25:06 -0800 (PST)
Received: by 10.50.180.233 with SMTP id dr9mr2323625igc.11.1327411506743;
	Tue, 24 Jan 2012 05:25:06 -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 ba5sm22575099igb.6.2012.01.24.05.25.04
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 05:25:05 -0800 (PST)
Message-ID: <4F1EB12E.5080802@codemonkey.ws>
Date: Tue, 24 Jan 2012 07:25:02 -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: Gerd Hoffmann <kraxel@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com>
In-Reply-To: <4F1E8635.2020608@redhat.com>
X-Gm-Message-State: ALoCoQkNmdM8k26eZJaJ2mvsEdRA+zwXHbOaUn6Dc3O7Tf0RxMCE+1iJeudLH2b49AY8k8kxr7+F
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 04:21 AM, Gerd Hoffmann wrote:
>    Hi,
>
>>>> We really should view RAM as just another device so I don't like the
>>>> idea of
>>>> propagating a global concept of "when RAM is restored" because that
>>>> treats it
>>>> specially compared to other devices.
>>>>
>>>> But viewing RAM as just another device, having Xen only restore a
>>>> subset of
>>>> devices should be a reasonable thing to do moving forward.
>
> I don't think modeling device memory (i.e. vga vram) as something
> independent from the device (vga) is a good idea.  Because it isn't.

It is, but probably not in the way you're assuming that I mean it is.

>
>>> To my understanding, QXL will break identically on Xen for the same
>>> reason: the reset handler assumes it can deal with the VRAM as it likes.
>
> Yes.  Some data structures for host<->  guest communication are living
> in device memory, and a reset initializes these.

This should be done by firmware or system software.  Devices don't initialize 
memory with data structures on power up.  The first problem with doing this is 
that it assumes a reset order which would lengthen the quiescing process.  The 
second problem is that this would require fairly sophisticated logic that could 
just as well live in firmware.

The advantage of not enabling a device to behave like this is it lets us do a 
much simpler reset model.  To model this properly, we would have to support 
multiple reset propagation hooks (at least a preorder and postorder hook).  This 
adds a fair amount of complication for not a lot of benefit (the only benefit is 
moving firmware logic into QEMU which is really a downside :-)).

Regards,

Anthony Liguori

>
>> QXL also has a VGA BIOS that it could use to initialize VRAM.  A similar
>> change could be made for it.
>
> Hmm.  Not sure this is a good idea.
>
> cheers,
>    Gerd
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 13:34:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgVr-0007qP-Mj; Tue, 24 Jan 2012 13:34:15 +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 1RpgVq-0007q8-3M
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:34:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327412047!10470674!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30166 invoked from network); 24 Jan 2012 13:34:07 -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; 24 Jan 2012 13:34:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 13:34:07 +0000
Message-Id: <4F1EC1A7020000780006EAB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 13:35:19 +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="=__Part0D235187.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/xenbus_dev: add missing error
 checks to watch handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0D235187.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So far only the watch path was checked to be zero terminated, while
the watch token was merely assumed to be.

Additionally, none of the three associated memory allocations got
checked for being successful.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/xenbus/xenbus_dev.c
+++ b/drivers/xen/xenbus/xenbus_dev.c
@@ -269,18 +269,24 @@ static ssize_t xenbus_dev_write(struct f
 			goto out;
 		}
 		token++;
+		if (memchr(token, 0, u->u.msg.len - (token - path)) =3D=3D =
NULL) {
+			rc =3D -EILSEQ;
+			goto out;
+		}
=20
 		if (msg_type =3D=3D XS_WATCH) {
 			watch =3D kzalloc(sizeof(*watch), GFP_KERNEL);
-			watch->watch.node =3D kmalloc(strlen(path)+1,
-                                                    GFP_KERNEL);
-			strcpy((char *)watch->watch.node, path);
+			if (watch =3D=3D NULL) {
+				rc =3D -ENOMEM;
+				goto out;
+			}
+			watch->watch.node =3D kstrdup(path, GFP_KERNEL);
 			watch->watch.callback =3D watch_fired;
-			watch->token =3D kmalloc(strlen(token)+1, =
GFP_KERNEL);
-			strcpy(watch->token, token);
+			watch->token =3D kstrdup(token, GFP_KERNEL);
 			watch->dev_data =3D u;
=20
-			err =3D register_xenbus_watch(&watch->watch);
+			err =3D watch->watch.node && watch->token
+			      ? register_xenbus_watch(&watch->watch) : =
-ENOMEM;
 			if (err) {
 				free_watch_adapter(watch);
 				rc =3D err;




--=__Part0D235187.0__=
Content-Type: text/plain; name="xen-xenbus-dev-write-watch.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-xenbus-dev-write-watch.patch"

xenbus_dev: add missing error checks to watch handling=0A=0ASo far only =
the watch path was checked to be zero terminated, while=0Athe watch token =
was merely assumed to be.=0A=0AAdditionally, none of the three associated =
memory allocations got=0Achecked for being successful.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/xenbus/xenbus_dev.c=
=0A+++ b/drivers/xen/xenbus/xenbus_dev.c=0A@@ -269,18 +269,24 @@ static =
ssize_t xenbus_dev_write(struct f=0A 			goto out;=0A 		=
}=0A 		token++;=0A+		if (memchr(token, 0, u->u.msg.len =
- (token - path)) =3D=3D NULL) {=0A+			rc =3D -EILSEQ;=0A+=
			goto out;=0A+		}=0A =0A 		if =
(msg_type =3D=3D XS_WATCH) {=0A 			watch =3D =
kzalloc(sizeof(*watch), GFP_KERNEL);=0A-			watch->watc=
h.node =3D kmalloc(strlen(path)+1,=0A-                                     =
               GFP_KERNEL);=0A-			strcpy((char *)watch->watch=
.node, path);=0A+			if (watch =3D=3D NULL) {=0A+		=
		rc =3D -ENOMEM;=0A+				goto =
out;=0A+			}=0A+			watch->watch.node =
=3D kstrdup(path, GFP_KERNEL);=0A 			watch->watch.callba=
ck =3D watch_fired;=0A-			watch->token =3D kmalloc(strlen(tok=
en)+1, GFP_KERNEL);=0A-			strcpy(watch->token, token);=0A+	=
		watch->token =3D kstrdup(token, GFP_KERNEL);=0A 		=
	watch->dev_data =3D u;=0A =0A-			err =3D register_xe=
nbus_watch(&watch->watch);=0A+			err =3D watch->watch.node =
&& watch->token=0A+			      ? register_xenbus_watch(&watc=
h->watch) : -ENOMEM;=0A 			if (err) {=0A 			=
	free_watch_adapter(watch);=0A 				rc =3D =
err;=0A
--=__Part0D235187.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

--=__Part0D235187.0__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 13:34:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:34:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgVr-0007qP-Mj; Tue, 24 Jan 2012 13:34:15 +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 1RpgVq-0007q8-3M
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:34:14 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327412047!10470674!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30166 invoked from network); 24 Jan 2012 13:34:07 -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; 24 Jan 2012 13:34:07 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 13:34:07 +0000
Message-Id: <4F1EC1A7020000780006EAB5@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 13:35:19 +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="=__Part0D235187.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/xenbus_dev: add missing error
 checks to watch handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part0D235187.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So far only the watch path was checked to be zero terminated, while
the watch token was merely assumed to be.

Additionally, none of the three associated memory allocations got
checked for being successful.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/xenbus/xenbus_dev.c
+++ b/drivers/xen/xenbus/xenbus_dev.c
@@ -269,18 +269,24 @@ static ssize_t xenbus_dev_write(struct f
 			goto out;
 		}
 		token++;
+		if (memchr(token, 0, u->u.msg.len - (token - path)) =3D=3D =
NULL) {
+			rc =3D -EILSEQ;
+			goto out;
+		}
=20
 		if (msg_type =3D=3D XS_WATCH) {
 			watch =3D kzalloc(sizeof(*watch), GFP_KERNEL);
-			watch->watch.node =3D kmalloc(strlen(path)+1,
-                                                    GFP_KERNEL);
-			strcpy((char *)watch->watch.node, path);
+			if (watch =3D=3D NULL) {
+				rc =3D -ENOMEM;
+				goto out;
+			}
+			watch->watch.node =3D kstrdup(path, GFP_KERNEL);
 			watch->watch.callback =3D watch_fired;
-			watch->token =3D kmalloc(strlen(token)+1, =
GFP_KERNEL);
-			strcpy(watch->token, token);
+			watch->token =3D kstrdup(token, GFP_KERNEL);
 			watch->dev_data =3D u;
=20
-			err =3D register_xenbus_watch(&watch->watch);
+			err =3D watch->watch.node && watch->token
+			      ? register_xenbus_watch(&watch->watch) : =
-ENOMEM;
 			if (err) {
 				free_watch_adapter(watch);
 				rc =3D err;




--=__Part0D235187.0__=
Content-Type: text/plain; name="xen-xenbus-dev-write-watch.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-xenbus-dev-write-watch.patch"

xenbus_dev: add missing error checks to watch handling=0A=0ASo far only =
the watch path was checked to be zero terminated, while=0Athe watch token =
was merely assumed to be.=0A=0AAdditionally, none of the three associated =
memory allocations got=0Achecked for being successful.=0A=0ASigned-off-by: =
Jan Beulich <jbeulich@suse.com>=0A=0A--- a/drivers/xen/xenbus/xenbus_dev.c=
=0A+++ b/drivers/xen/xenbus/xenbus_dev.c=0A@@ -269,18 +269,24 @@ static =
ssize_t xenbus_dev_write(struct f=0A 			goto out;=0A 		=
}=0A 		token++;=0A+		if (memchr(token, 0, u->u.msg.len =
- (token - path)) =3D=3D NULL) {=0A+			rc =3D -EILSEQ;=0A+=
			goto out;=0A+		}=0A =0A 		if =
(msg_type =3D=3D XS_WATCH) {=0A 			watch =3D =
kzalloc(sizeof(*watch), GFP_KERNEL);=0A-			watch->watc=
h.node =3D kmalloc(strlen(path)+1,=0A-                                     =
               GFP_KERNEL);=0A-			strcpy((char *)watch->watch=
.node, path);=0A+			if (watch =3D=3D NULL) {=0A+		=
		rc =3D -ENOMEM;=0A+				goto =
out;=0A+			}=0A+			watch->watch.node =
=3D kstrdup(path, GFP_KERNEL);=0A 			watch->watch.callba=
ck =3D watch_fired;=0A-			watch->token =3D kmalloc(strlen(tok=
en)+1, GFP_KERNEL);=0A-			strcpy(watch->token, token);=0A+	=
		watch->token =3D kstrdup(token, GFP_KERNEL);=0A 		=
	watch->dev_data =3D u;=0A =0A-			err =3D register_xe=
nbus_watch(&watch->watch);=0A+			err =3D watch->watch.node =
&& watch->token=0A+			      ? register_xenbus_watch(&watc=
h->watch) : -ENOMEM;=0A 			if (err) {=0A 			=
	free_watch_adapter(watch);=0A 				rc =3D =
err;=0A
--=__Part0D235187.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

--=__Part0D235187.0__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 13:38:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgZS-00080J-C4; Tue, 24 Jan 2012 13:37:58 +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 1RpgZQ-000805-EM
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:37:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327412269!6248102!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5632 invoked from network); 24 Jan 2012 13:37:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 13:37:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 13:37:49 +0000
Message-Id: <4F1EC284020000780006EAB9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 13:39: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="=__PartE9C7B564.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/drivers/xen/: user strlcpy()
 instead of strncpy()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartE9C7B564.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... for being the safer alternative.

In blktap2, snprintf() also gets replaced by strlcpy(), and the bounds
check in blktap_sysfs_set_name() also gets adjusted.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blktap/xenbus.c
+++ b/drivers/xen/blktap/xenbus.c
@@ -72,24 +72,22 @@ static int strsep_len(const char *str, c
                                 return i;
                         len--;
                 }
-        return (len =3D=3D 0) ? i : -ERANGE;
+        return -ERANGE;
 }
=20
 static long get_id(const char *str)
 {
-        int len,end;
+	int len;
         const char *ptr;
-        char *tptr, num[10];
+	char num[10];
 =09
         len =3D strsep_len(str, '/', 2);
-        end =3D strlen(str);
-        if ( (len < 0) || (end < 0) ) return -1;
+	if (len < 0)
+		return -1;
 =09
         ptr =3D str + len + 1;
-        strncpy(num,ptr,end - len);
-        tptr =3D num + (end - (len + 1));
-        *tptr =3D '\0';
-	DPRINTK("Get_id called for %s (%s)\n",str,num);
+	strlcpy(num, ptr, ARRAY_SIZE(num));
+	DPRINTK("get_id(%s) -> %s\n", str, num);
 =09
         return simple_strtol(num, NULL, 10);
 }			=09
--- a/drivers/xen/blktap2/sysfs.c
+++ b/drivers/xen/blktap2/sysfs.c
@@ -65,12 +65,12 @@ blktap_sysfs_set_name(struct class_devic
 		goto out;
 	}
=20
-	if (strnlen(buf, BLKTAP2_MAX_MESSAGE_LEN) >=3D BLKTAP2_MAX_MESSAGE_=
LEN) {
+	if (strnlen(buf, size) >=3D size) {
 		err =3D -EINVAL;
 		goto out;
 	}
=20
-	snprintf(tap->params.name, sizeof(tap->params.name) - 1, "%s", =
buf);
+	strlcpy(tap->params.name, buf, size);
 	err =3D size;
=20
 out:
--- a/drivers/xen/usbback/usbstub.c
+++ b/drivers/xen/usbback/usbstub.c
@@ -110,7 +110,7 @@ int portid_add(const char *busid,
 	portid->handle =3D handle;
 	portid->portnum =3D portnum;
=20
-	strncpy(portid->phys_bus, busid, BUS_ID_SIZE);
+	strlcpy(portid->phys_bus, busid, BUS_ID_SIZE);
=20
 	spin_lock_irqsave(&port_list_lock, flags);
 	list_add(&portid->id_list, &port_list);
--- a/drivers/xen/xenoprof/xenoprofile.c
+++ b/drivers/xen/xenoprof/xenoprofile.c
@@ -553,9 +553,8 @@ int __init xenoprofile_init(struct oprof
 		xenoprof_arch_init_counter(&init);
 		xenoprof_is_primary =3D init.is_primary;
=20
-		/*  cpu_type is detected by Xen */
-		cpu_type[XENOPROF_CPU_TYPE_SIZE-1] =3D 0;
-		strncpy(cpu_type, init.cpu_type, XENOPROF_CPU_TYPE_SIZE - =
1);
+		/* cpu_type is detected by Xen */
+		strlcpy(cpu_type, init.cpu_type, XENOPROF_CPU_TYPE_SIZE);
 		xenoprof_ops.cpu_type =3D cpu_type;
=20
 		init_driverfs();




--=__PartE9C7B564.0__=
Content-Type: text/plain; name="xen-strlcpy.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-strlcpy.patch"

drivers/xen/: user strlcpy() instead of strncpy()=0A=0A... for being the =
safer alternative.=0A=0AIn blktap2, snprintf() also gets replaced by =
strlcpy(), and the bounds=0Acheck in blktap_sysfs_set_name() also gets =
adjusted.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/blktap/xenbus.c=0A+++ b/drivers/xen/blktap/xenbus.c=0A@@ =
-72,24 +72,22 @@ static int strsep_len(const char *str, c=0A               =
                  return i;=0A                         len--;=0A           =
      }=0A-        return (len =3D=3D 0) ? i : -ERANGE;=0A+        return =
-ERANGE;=0A }=0A =0A static long get_id(const char *str)=0A {=0A-        =
int len,end;=0A+	int len;=0A         const char *ptr;=0A-        =
char *tptr, num[10];=0A+	char num[10];=0A 	=0A         len =
=3D strsep_len(str, '/', 2);=0A-        end =3D strlen(str);=0A-        if =
( (len < 0) || (end < 0) ) return -1;=0A+	if (len < 0)=0A+		=
return -1;=0A 	=0A         ptr =3D str + len + 1;=0A-        strncpy(num,p=
tr,end - len);=0A-        tptr =3D num + (end - (len + 1));=0A-        =
*tptr =3D '\0';=0A-	DPRINTK("Get_id called for %s (%s)\n",str,num);=0A+=
	strlcpy(num, ptr, ARRAY_SIZE(num));=0A+	DPRINTK("get_id(%s) -> =
%s\n", str, num);=0A 	=0A         return simple_strtol(num, NULL, =
10);=0A }				=0A--- a/drivers/xen/blktap2/sysfs.=
c=0A+++ b/drivers/xen/blktap2/sysfs.c=0A@@ -65,12 +65,12 @@ blktap_sysfs_se=
t_name(struct class_devic=0A 		goto out;=0A 	}=0A =0A-	if =
(strnlen(buf, BLKTAP2_MAX_MESSAGE_LEN) >=3D BLKTAP2_MAX_MESSAGE_LEN) {=0A+	=
if (strnlen(buf, size) >=3D size) {=0A 		err =3D -EINVAL;=0A 		=
goto out;=0A 	}=0A =0A-	snprintf(tap->params.name, sizeof(tap->para=
ms.name) - 1, "%s", buf);=0A+	strlcpy(tap->params.name, buf, size);=0A 	=
err =3D size;=0A =0A out:=0A--- a/drivers/xen/usbback/usbstub.c=0A+++ =
b/drivers/xen/usbback/usbstub.c=0A@@ -110,7 +110,7 @@ int portid_add(const =
char *busid,=0A 	portid->handle =3D handle;=0A 	portid->portnum =
=3D portnum;=0A =0A-	strncpy(portid->phys_bus, busid, BUS_ID_SIZE);=0A+	=
strlcpy(portid->phys_bus, busid, BUS_ID_SIZE);=0A =0A 	spin_lock_irqsave(&=
port_list_lock, flags);=0A 	list_add(&portid->id_list, &port_list);=0A-=
-- a/drivers/xen/xenoprof/xenoprofile.c=0A+++ b/drivers/xen/xenoprof/xenopr=
ofile.c=0A@@ -553,9 +553,8 @@ int __init xenoprofile_init(struct oprof=0A 	=
	xenoprof_arch_init_counter(&init);=0A 		xenoprof_is_primary=
 =3D init.is_primary;=0A =0A-		/*  cpu_type is detected by Xen =
*/=0A-		cpu_type[XENOPROF_CPU_TYPE_SIZE-1] =3D 0;=0A-		=
strncpy(cpu_type, init.cpu_type, XENOPROF_CPU_TYPE_SIZE - 1);=0A+		=
/* cpu_type is detected by Xen */=0A+		strlcpy(cpu_type, =
init.cpu_type, XENOPROF_CPU_TYPE_SIZE);=0A 		xenoprof_ops.cpu_ty=
pe =3D cpu_type;=0A =0A 		init_driverfs();=0A
--=__PartE9C7B564.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

--=__PartE9C7B564.0__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 13:38:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:38:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpgZS-00080J-C4; Tue, 24 Jan 2012 13:37:58 +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 1RpgZQ-000805-EM
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:37:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327412269!6248102!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5632 invoked from network); 24 Jan 2012 13:37:49 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 13:37:49 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 13:37:49 +0000
Message-Id: <4F1EC284020000780006EAB9@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 13:39: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="=__PartE9C7B564.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/drivers/xen/: user strlcpy()
 instead of strncpy()
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartE9C7B564.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

... for being the safer alternative.

In blktap2, snprintf() also gets replaced by strlcpy(), and the bounds
check in blktap_sysfs_set_name() also gets adjusted.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/xen/blktap/xenbus.c
+++ b/drivers/xen/blktap/xenbus.c
@@ -72,24 +72,22 @@ static int strsep_len(const char *str, c
                                 return i;
                         len--;
                 }
-        return (len =3D=3D 0) ? i : -ERANGE;
+        return -ERANGE;
 }
=20
 static long get_id(const char *str)
 {
-        int len,end;
+	int len;
         const char *ptr;
-        char *tptr, num[10];
+	char num[10];
 =09
         len =3D strsep_len(str, '/', 2);
-        end =3D strlen(str);
-        if ( (len < 0) || (end < 0) ) return -1;
+	if (len < 0)
+		return -1;
 =09
         ptr =3D str + len + 1;
-        strncpy(num,ptr,end - len);
-        tptr =3D num + (end - (len + 1));
-        *tptr =3D '\0';
-	DPRINTK("Get_id called for %s (%s)\n",str,num);
+	strlcpy(num, ptr, ARRAY_SIZE(num));
+	DPRINTK("get_id(%s) -> %s\n", str, num);
 =09
         return simple_strtol(num, NULL, 10);
 }			=09
--- a/drivers/xen/blktap2/sysfs.c
+++ b/drivers/xen/blktap2/sysfs.c
@@ -65,12 +65,12 @@ blktap_sysfs_set_name(struct class_devic
 		goto out;
 	}
=20
-	if (strnlen(buf, BLKTAP2_MAX_MESSAGE_LEN) >=3D BLKTAP2_MAX_MESSAGE_=
LEN) {
+	if (strnlen(buf, size) >=3D size) {
 		err =3D -EINVAL;
 		goto out;
 	}
=20
-	snprintf(tap->params.name, sizeof(tap->params.name) - 1, "%s", =
buf);
+	strlcpy(tap->params.name, buf, size);
 	err =3D size;
=20
 out:
--- a/drivers/xen/usbback/usbstub.c
+++ b/drivers/xen/usbback/usbstub.c
@@ -110,7 +110,7 @@ int portid_add(const char *busid,
 	portid->handle =3D handle;
 	portid->portnum =3D portnum;
=20
-	strncpy(portid->phys_bus, busid, BUS_ID_SIZE);
+	strlcpy(portid->phys_bus, busid, BUS_ID_SIZE);
=20
 	spin_lock_irqsave(&port_list_lock, flags);
 	list_add(&portid->id_list, &port_list);
--- a/drivers/xen/xenoprof/xenoprofile.c
+++ b/drivers/xen/xenoprof/xenoprofile.c
@@ -553,9 +553,8 @@ int __init xenoprofile_init(struct oprof
 		xenoprof_arch_init_counter(&init);
 		xenoprof_is_primary =3D init.is_primary;
=20
-		/*  cpu_type is detected by Xen */
-		cpu_type[XENOPROF_CPU_TYPE_SIZE-1] =3D 0;
-		strncpy(cpu_type, init.cpu_type, XENOPROF_CPU_TYPE_SIZE - =
1);
+		/* cpu_type is detected by Xen */
+		strlcpy(cpu_type, init.cpu_type, XENOPROF_CPU_TYPE_SIZE);
 		xenoprof_ops.cpu_type =3D cpu_type;
=20
 		init_driverfs();




--=__PartE9C7B564.0__=
Content-Type: text/plain; name="xen-strlcpy.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-strlcpy.patch"

drivers/xen/: user strlcpy() instead of strncpy()=0A=0A... for being the =
safer alternative.=0A=0AIn blktap2, snprintf() also gets replaced by =
strlcpy(), and the bounds=0Acheck in blktap_sysfs_set_name() also gets =
adjusted.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/xen/blktap/xenbus.c=0A+++ b/drivers/xen/blktap/xenbus.c=0A@@ =
-72,24 +72,22 @@ static int strsep_len(const char *str, c=0A               =
                  return i;=0A                         len--;=0A           =
      }=0A-        return (len =3D=3D 0) ? i : -ERANGE;=0A+        return =
-ERANGE;=0A }=0A =0A static long get_id(const char *str)=0A {=0A-        =
int len,end;=0A+	int len;=0A         const char *ptr;=0A-        =
char *tptr, num[10];=0A+	char num[10];=0A 	=0A         len =
=3D strsep_len(str, '/', 2);=0A-        end =3D strlen(str);=0A-        if =
( (len < 0) || (end < 0) ) return -1;=0A+	if (len < 0)=0A+		=
return -1;=0A 	=0A         ptr =3D str + len + 1;=0A-        strncpy(num,p=
tr,end - len);=0A-        tptr =3D num + (end - (len + 1));=0A-        =
*tptr =3D '\0';=0A-	DPRINTK("Get_id called for %s (%s)\n",str,num);=0A+=
	strlcpy(num, ptr, ARRAY_SIZE(num));=0A+	DPRINTK("get_id(%s) -> =
%s\n", str, num);=0A 	=0A         return simple_strtol(num, NULL, =
10);=0A }				=0A--- a/drivers/xen/blktap2/sysfs.=
c=0A+++ b/drivers/xen/blktap2/sysfs.c=0A@@ -65,12 +65,12 @@ blktap_sysfs_se=
t_name(struct class_devic=0A 		goto out;=0A 	}=0A =0A-	if =
(strnlen(buf, BLKTAP2_MAX_MESSAGE_LEN) >=3D BLKTAP2_MAX_MESSAGE_LEN) {=0A+	=
if (strnlen(buf, size) >=3D size) {=0A 		err =3D -EINVAL;=0A 		=
goto out;=0A 	}=0A =0A-	snprintf(tap->params.name, sizeof(tap->para=
ms.name) - 1, "%s", buf);=0A+	strlcpy(tap->params.name, buf, size);=0A 	=
err =3D size;=0A =0A out:=0A--- a/drivers/xen/usbback/usbstub.c=0A+++ =
b/drivers/xen/usbback/usbstub.c=0A@@ -110,7 +110,7 @@ int portid_add(const =
char *busid,=0A 	portid->handle =3D handle;=0A 	portid->portnum =
=3D portnum;=0A =0A-	strncpy(portid->phys_bus, busid, BUS_ID_SIZE);=0A+	=
strlcpy(portid->phys_bus, busid, BUS_ID_SIZE);=0A =0A 	spin_lock_irqsave(&=
port_list_lock, flags);=0A 	list_add(&portid->id_list, &port_list);=0A-=
-- a/drivers/xen/xenoprof/xenoprofile.c=0A+++ b/drivers/xen/xenoprof/xenopr=
ofile.c=0A@@ -553,9 +553,8 @@ int __init xenoprofile_init(struct oprof=0A 	=
	xenoprof_arch_init_counter(&init);=0A 		xenoprof_is_primary=
 =3D init.is_primary;=0A =0A-		/*  cpu_type is detected by Xen =
*/=0A-		cpu_type[XENOPROF_CPU_TYPE_SIZE-1] =3D 0;=0A-		=
strncpy(cpu_type, init.cpu_type, XENOPROF_CPU_TYPE_SIZE - 1);=0A+		=
/* cpu_type is detected by Xen */=0A+		strlcpy(cpu_type, =
init.cpu_type, XENOPROF_CPU_TYPE_SIZE);=0A 		xenoprof_ops.cpu_ty=
pe =3D cpu_type;=0A =0A 		init_driverfs();=0A
--=__PartE9C7B564.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

--=__PartE9C7B564.0__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 13:52:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpgmd-0008Rh-QZ; Tue, 24 Jan 2012 13:51: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 1Rpgmb-0008RW-Fo
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:51:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327413045!51381505!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10044 invoked from network); 24 Jan 2012 13:50:45 -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; 24 Jan 2012 13:50:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 13:51:31 +0000
Message-Id: <4F1EC5BA020000780006EABF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 13:52:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <konrad@darnok.org>,"Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part341A68BA.2__="
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xenbus_dev: add missing error check to watch
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part341A68BA.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So far only the watch path was checked to be zero terminated, while
the watch token was merely assumed to be.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xenbus/xenbus_dev_frontend.c |    4 ++++
 1 file changed, 4 insertions(+)

--- 3.3-rc1/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ 3.3-rc1-xenbus-dev-write-watch/drivers/xen/xenbus/xenbus_dev_frontend.c=

@@ -369,6 +369,10 @@ static int xenbus_write_watch(unsigned m
 		goto out;
 	}
 	token++;
+	if (memchr(token, 0, u->u.msg.len - (token - path)) =3D=3D NULL) {
+		rc =3D -EILSEQ;
+		goto out;
+	}
=20
 	if (msg_type =3D=3D XS_WATCH) {
 		watch =3D alloc_watch_adapter(path, token);




--=__Part341A68BA.2__=
Content-Type: text/plain; name="linux-3.3-rc1-xenbus-dev-write-watch.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.3-rc1-xenbus-dev-write-watch.patch"

xenbus_dev: add missing error check to watch handling=0A=0ASo far only the =
watch path was checked to be zero terminated, while=0Athe watch token was =
merely assumed to be.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A---=0A drivers/xen/xenbus/xenbus_dev_frontend.c |    4 ++++=0A 1 =
file changed, 4 insertions(+)=0A=0A--- 3.3-rc1/drivers/xen/xenbus/xenbus_de=
v_frontend.c=0A+++ 3.3-rc1-xenbus-dev-write-watch/drivers/xen/xenbus/xenbus=
_dev_frontend.c=0A@@ -369,6 +369,10 @@ static int xenbus_write_watch(unsign=
ed m=0A 		goto out;=0A 	}=0A 	token++;=0A+	if =
(memchr(token, 0, u->u.msg.len - (token - path)) =3D=3D NULL) {=0A+		=
rc =3D -EILSEQ;=0A+		goto out;=0A+	}=0A =0A 	if =
(msg_type =3D=3D XS_WATCH) {=0A 		watch =3D alloc_watch_adapt=
er(path, token);=0A
--=__Part341A68BA.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

--=__Part341A68BA.2__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 13:52:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 13:52:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpgmd-0008Rh-QZ; Tue, 24 Jan 2012 13:51: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 1Rpgmb-0008RW-Fo
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 13:51:33 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327413045!51381505!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10044 invoked from network); 24 Jan 2012 13:50:45 -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; 24 Jan 2012 13:50:45 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 13:51:31 +0000
Message-Id: <4F1EC5BA020000780006EABF@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 13:52:42 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: <konrad@darnok.org>,"Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part341A68BA.2__="
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	linux-kernel@vger.kernel.org
Subject: [Xen-devel] [PATCH] xenbus_dev: add missing error check to watch
	handling
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part341A68BA.2__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

So far only the watch path was checked to be zero terminated, while
the watch token was merely assumed to be.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

---
 drivers/xen/xenbus/xenbus_dev_frontend.c |    4 ++++
 1 file changed, 4 insertions(+)

--- 3.3-rc1/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ 3.3-rc1-xenbus-dev-write-watch/drivers/xen/xenbus/xenbus_dev_frontend.c=

@@ -369,6 +369,10 @@ static int xenbus_write_watch(unsigned m
 		goto out;
 	}
 	token++;
+	if (memchr(token, 0, u->u.msg.len - (token - path)) =3D=3D NULL) {
+		rc =3D -EILSEQ;
+		goto out;
+	}
=20
 	if (msg_type =3D=3D XS_WATCH) {
 		watch =3D alloc_watch_adapter(path, token);




--=__Part341A68BA.2__=
Content-Type: text/plain; name="linux-3.3-rc1-xenbus-dev-write-watch.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="linux-3.3-rc1-xenbus-dev-write-watch.patch"

xenbus_dev: add missing error check to watch handling=0A=0ASo far only the =
watch path was checked to be zero terminated, while=0Athe watch token was =
merely assumed to be.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=
=0A=0A---=0A drivers/xen/xenbus/xenbus_dev_frontend.c |    4 ++++=0A 1 =
file changed, 4 insertions(+)=0A=0A--- 3.3-rc1/drivers/xen/xenbus/xenbus_de=
v_frontend.c=0A+++ 3.3-rc1-xenbus-dev-write-watch/drivers/xen/xenbus/xenbus=
_dev_frontend.c=0A@@ -369,6 +369,10 @@ static int xenbus_write_watch(unsign=
ed m=0A 		goto out;=0A 	}=0A 	token++;=0A+	if =
(memchr(token, 0, u->u.msg.len - (token - path)) =3D=3D NULL) {=0A+		=
rc =3D -EILSEQ;=0A+		goto out;=0A+	}=0A =0A 	if =
(msg_type =3D=3D XS_WATCH) {=0A 		watch =3D alloc_watch_adapt=
er(path, token);=0A
--=__Part341A68BA.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

--=__Part341A68BA.2__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:14:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14: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 1Rph8S-0000I3-Sw; Tue, 24 Jan 2012 14:14:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>)
	id 1Rph8R-0000Hv-Ox; Tue, 24 Jan 2012 14:14:07 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327414438!8531113!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25496 invoked from network); 24 Jan 2012 14:14:00 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 14:14:00 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0OECwkM006021;
	Tue, 24 Jan 2012 09:12:58 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 24 Jan 2012 09:12:40 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
In-Reply-To: <20120124015021.GB24204@andromeda.dapyr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [Xen-users]  VGA passthough still not working
Thread-Index: AczaUAwmcNj4mU4mSzCsGQ4NNYSsOgAUH5/g
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
From: <djmagee@mageenet.net>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Tobias Geiger" <tobias.geiger@vido.info>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: Sandi Romih <romihs.forums@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xensource.com, chris <tknchris@gmail.com>,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Monday, January 23, 2012 8:50 PM
> To: Tobias Geiger
> Cc: Sandi Romih; chris; xen-devel@lists.xensource.com; xen-
> users@lists.xensource.com; Ian Campbell
> Subject: Re: [Xen-devel] [Xen-users] VGA passthough still not working
> 
> On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> > Hello!
> >
> > The thing is, you either dont need patches at all to get it to work
> (ATI), or
> > you need to customize patches reflecting your individual setup
> (NVIDIA);
> >
> > To be more specific:
> > I can confirm that passing through a ATI Card works "out of the box"
> - either
> > to Windows 7 or Windows XP;
> > In the past i had a setup running with a NVIDIA card, it only worked
> with
> > special patches (the ones David packed together and offers as
> tarball) and - as
> > far as i can tell - are not generaly working for all NVIDIA Cards,
> i.e. you
> > have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
> then the
> > passed through Card worked only with Windows XP - NOT with Windows
7;
> >
> > Both setup have the "flaw" that they only work once - meaning you
> can't reboot
> > your DomU , cause after the reboot the passed-through Card doesnt
> have correct
> > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> Windows XP and
> > Windows7 )
> 
> For me it was with ATI with Windows7. Hadn't tried other OSes.
> 
> Anybody had luck with passing the card more than once to a guest? With
> any random set of patches?

Yes, I've had a machine running for a couple of weeks, hosting a Windows
7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
machine multiple times, as well as gone through a couple of xl
destroy/create cycles.

I only pass it through as a secondary card, as I have the IGD as the
primary on the host.  The machine is a DQ67SW with a Core i5.  This is
running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.

I haven't, however, had any luck passing through the IGD to anything
other than a Windows XP, and that includes running the latest qemu-xen
with Jean's patches (opregion, host bridge config space mapping).  I've
been intending to start a separate thread for that...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:14:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14: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 1Rph8S-0000I3-Sw; Tue, 24 Jan 2012 14:14:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>)
	id 1Rph8R-0000Hv-Ox; Tue, 24 Jan 2012 14:14:07 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327414438!8531113!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25496 invoked from network); 24 Jan 2012 14:14:00 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 14:14:00 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0OECwkM006021;
	Tue, 24 Jan 2012 09:12:58 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 24 Jan 2012 09:12:40 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
In-Reply-To: <20120124015021.GB24204@andromeda.dapyr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] [Xen-users]  VGA passthough still not working
Thread-Index: AczaUAwmcNj4mU4mSzCsGQ4NNYSsOgAUH5/g
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com><CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com><1327318778.24561.74.camel@zakaz.uk.xensource.com><201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
From: <djmagee@mageenet.net>
To: "Konrad Rzeszutek Wilk" <konrad@darnok.org>,
	"Tobias Geiger" <tobias.geiger@vido.info>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: Sandi Romih <romihs.forums@gmail.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	xen-devel@lists.xensource.com, chris <tknchris@gmail.com>,
	xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> Sent: Monday, January 23, 2012 8:50 PM
> To: Tobias Geiger
> Cc: Sandi Romih; chris; xen-devel@lists.xensource.com; xen-
> users@lists.xensource.com; Ian Campbell
> Subject: Re: [Xen-devel] [Xen-users] VGA passthough still not working
> 
> On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> > Hello!
> >
> > The thing is, you either dont need patches at all to get it to work
> (ATI), or
> > you need to customize patches reflecting your individual setup
> (NVIDIA);
> >
> > To be more specific:
> > I can confirm that passing through a ATI Card works "out of the box"
> - either
> > to Windows 7 or Windows XP;
> > In the past i had a setup running with a NVIDIA card, it only worked
> with
> > special patches (the ones David packed together and offers as
> tarball) and - as
> > far as i can tell - are not generaly working for all NVIDIA Cards,
> i.e. you
> > have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
> then the
> > passed through Card worked only with Windows XP - NOT with Windows
7;
> >
> > Both setup have the "flaw" that they only work once - meaning you
> can't reboot
> > your DomU , cause after the reboot the passed-through Card doesnt
> have correct
> > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> Windows XP and
> > Windows7 )
> 
> For me it was with ATI with Windows7. Hadn't tried other OSes.
> 
> Anybody had luck with passing the card more than once to a guest? With
> any random set of patches?

Yes, I've had a machine running for a couple of weeks, hosting a Windows
7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
machine multiple times, as well as gone through a couple of xl
destroy/create cycles.

I only pass it through as a secondary card, as I have the IGD as the
primary on the host.  The machine is a DQ67SW with a Core i5.  This is
running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.

I haven't, however, had any luck passing through the IGD to anything
other than a Windows XP, and that includes running the latest qemu-xen
with Jean's patches (opregion, host bridge config space mapping).  I've
been intending to start a separate thread for that...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:18:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:18:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphC8-0000dv-Ud; Tue, 24 Jan 2012 14:17: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 1RphC7-0000cz-2W
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:17:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327414668!10468590!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28260 invoked from network); 24 Jan 2012 14:17:48 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 14:17:48 -0000
Received: by wibhm2 with SMTP id hm2so2663061wib.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 06:17:48 -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=Dn7Pj3DYfV3EE1kCY+sPloeORs82kMkBMKbSSO5bpAQ=;
	b=klEETr8On+C0TTi0NIl5YPVODQV9WrN090N12qdg71pEkQhlP+N4/oc2PrAMJFASqz
	r/Dd6j5KQ8XeN1Lge8nPDkHdiOX20ZN9e/tspVzEYjzmL8ZXIC3kKxQ7Yh12c6aTSit0
	hCcylksw/K/MthWdFyFb4Va31HWKBaBOpwXnc=
Received: by 10.180.84.133 with SMTP id z5mr3941927wiy.10.1327414668416;
	Tue, 24 Jan 2012 06:17:48 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id u12sm18925440wiv.10.2012.01.24.06.17.45
	(version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 06:17:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 24 Jan 2012 14:17:40 +0000
From: Keir Fraser <keir@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CB446E04.38059%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
Thread-Index: Aczaou4Ithbc4yxvykOIiCHKoau6jQ==
In-Reply-To: <CAFLBxZYa=yWp2aBrbN09MLyqhqEM86=zHAeQDuEEHeQY-6vJOg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, raistlin@linux.it, 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/01/2012 12:01, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> Ping?

It's been in the tree for a week.

> On Tue, Jan 10, 2012 at 10:05 AM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
>> On Mon, Jan 9, 2012 at 10:22 AM, Hui Lv <hui.lv@intel.com> wrote:
>>> Updated the warning sentence for ratelimit_us.
>>> =

>>> This patch can improve Xen performance:
>>> 1. Basically, the "delay method" can achieve 11% overall performance bo=
ost
>>> 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, hi=
gh,
>>> 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 =3D 1000 is the recommen=
ded
>>> setting)
>>> =

>>> Signed-off-by: Hui Lv <hui.lv@intel.com>
>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>> =

>>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> =

>> Just confirming this:
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> =

>> Thanks, Hui.
>> =A0-George
>> =

>>> =

>>> diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -0500
>>> @@ -172,6 +172,7 @@ struct csched_private {
>>> =A0 =A0 uint32_t credit;
>>> =A0 =A0 int credit_balance;
>>> =A0 =A0 uint32_t runq_sort;
>>> + =A0 =A0unsigned ratelimit_us;
>>> =A0 =A0 /* Period of master and tick in milliseconds */
>>> =A0 =A0 unsigned tslice_ms, tick_period_us, ticks_per_tslice;
>>> =A0 =A0 unsigned credits_per_tslice;
>>> @@ -1297,10 +1298,15 @@ csched_schedule(
>>> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
>>> =A0 =A0 struct csched_vcpu *snext;
>>> =A0 =A0 struct task_slice ret;
>>> + =A0 =A0s_time_t runtime, tslice;
>>> =

>>> =A0 =A0 CSCHED_STAT_CRANK(schedule);
>>> =A0 =A0 CSCHED_VCPU_CHECK(current);
>>> =

>>> + =A0 =A0runtime =3D now - current->runstate.state_entry_time;
>>> + =A0 =A0if ( runtime < 0 ) /* Does this ever happen? */
>>> + =A0 =A0 =A0 =A0runtime =3D 0;
>>> +
>>> =A0 =A0 if ( !is_idle_vcpu(scurr->vcpu) )
>>> =A0 =A0 {
>>> =A0 =A0 =A0 =A0 /* Update credits of a non-idle VCPU. */
>>> @@ -1313,6 +1319,35 @@ csched_schedule(
>>> =A0 =A0 =A0 =A0 scurr->pri =3D CSCHED_PRI_IDLE;
>>> =A0 =A0 }
>>> =

>>> + =A0 =A0/* Choices, choices:
>>> + =A0 =A0 * - If we have a tasklet, we need to run the idle vcpu no mat=
ter what.
>>> + =A0 =A0 * - If sched rate limiting is in effect, and the current vcpu=
 has
>>> + =A0 =A0 * =A0 run for less than that amount of time, continue the cur=
rent one,
>>> + =A0 =A0 * =A0 but with a shorter timeslice and return it immediately
>>> + =A0 =A0 * - Otherwise, chose the one with the highest priority (which=
 may
>>> + =A0 =A0 * =A0 be the one currently running)
>>> + =A0 =A0 * - If the currently running one is TS_OVER, see if there
>>> + =A0 =A0 * =A0 is a higher priority one waiting on the runqueue of ano=
ther
>>> + =A0 =A0 * =A0 cpu and steal it.
>>> + =A0 =A0 */
>>> +
>>> + =A0 =A0/* If we have schedule rate limiting enabled, check to see
>>> + =A0 =A0 * how long we've run for. */
>>> + =A0 =A0if ( !tasklet_work_scheduled
>>> + =A0 =A0 =A0 =A0 && prv->ratelimit_us
>>> + =A0 =A0 =A0 =A0 && vcpu_runnable(current)
>>> + =A0 =A0 =A0 =A0 && !is_idle_vcpu(current)
>>> + =A0 =A0 =A0 =A0 && runtime < MICROSECS(prv->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(prv->ratelimit_us);
>>> + =A0 =A0 =A0 =A0ret.migrated =3D 0;
>>> + =A0 =A0 =A0 =A0goto out;
>>> + =A0 =A0}
>>> + =A0 =A0tslice =3D MILLISECS(prv->tslice_ms);
>>> +
>>> =A0 =A0 /*
>>> =A0 =A0 =A0* Select next runnable local VCPU (ie top of local runq)
>>> =A0 =A0 =A0*/
>>> @@ -1367,11 +1402,12 @@ csched_schedule(
>>> =A0 =A0 if ( !is_idle_vcpu(snext->vcpu) )
>>> =A0 =A0 =A0 =A0 snext->start_time +=3D now;
>>> =

>>> +out:
>>> =A0 =A0 /*
>>> =A0 =A0 =A0* Return task to run next...
>>> =A0 =A0 =A0*/
>>> =A0 =A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ?
>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(prv->tslice_ms));
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : tslice);
>>> =A0 =A0 ret.task =3D snext->vcpu;
>>> =

>>> =A0 =A0 CSCHED_VCPU_CHECK(ret.task);
>>> @@ -1533,6 +1569,15 @@ csched_init(struct scheduler *ops)
>>> =A0 =A0 prv->tick_period_us =3D prv->tslice_ms * 1000 / prv->ticks_per_=
tslice;
>>> =A0 =A0 prv->credits_per_tslice =3D CSCHED_CREDITS_PER_MSEC * prv->tsli=
ce_ms;
>>> =

>>> + =A0 =A0if ( MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_ts=
lice_ms)
>>> )
>>> + =A0 =A0{
>>> + =A0 =A0 =A0 =A0printk("WARNING: sched_ratelimit_us >"
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "sched_credit_tslice_ms is undefined\n"
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Setting ratelimit_us to 1000 * tslice_ms=
\n");
>>> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D 1000 * prv->tslice_ms;
>>> + =A0 =A0}
>>> + =A0 =A0else
>>> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D sched_ratelimit_us;
>>> =A0 =A0 return 0;
>>> =A0}
>>> =

>>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
>>> --- a/xen/common/schedule.c =A0 =A0 Fri Dec 16 18:46:27 2011 +0000
>>> +++ b/xen/common/schedule.c =A0 =A0 Mon Jan 09 05:21:35 2012 -0500
>>> @@ -47,6 +47,11 @@ string_param("sched", opt_sched);
>>> =A0bool_t sched_smt_power_savings =3D 0;
>>> =A0boolean_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 =3D 1000;
>>> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
>>> =A0/* Various timer handlers. */
>>> =A0static void s_timer_fn(void *unused);
>>> =A0static void vcpu_periodic_timer_fn(void *data);
>>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/perfc_defn.h
>>> --- a/xen/include/xen/perfc_defn.h =A0 =A0 =A0Fri Dec 16 18:46:27 2011 =
+0000
>>> +++ b/xen/include/xen/perfc_defn.h =A0 =A0 =A0Mon Jan 09 05:21:35 2012 =
-0500
>>> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sch
>>> =A0PERFCOUNTER(sched_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: runs throu=
gh scheduler")
>>> =A0PERFCOUNTER(sched_ctx, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: context sw=
itches")
>>> =

>>> +PERFCOUNTER(delay_ms, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: delay")
>>> =A0PERFCOUNTER(vcpu_check, =A0 =A0 =A0 =A0 =A0 =A0 "csched: vcpu_check")
>>> =A0PERFCOUNTER(schedule, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: schedule")
>>> =A0PERFCOUNTER(acct_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: acct_run")
>>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/sched-if.h
>>> --- a/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Fri Dec 16 18:46:27 201=
1 +0000
>>> +++ b/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Mon Jan 09 05:21:35 201=
2 -0500
>>> @@ -16,6 +16,11 @@ extern struct cpupool *cpupool0;
>>> =A0/* cpus currently in no cpupool */
>>> =A0extern cpumask_t cpupool_free_cpus;
>>> =

>>> +/* Scheduler generic parameters
>>> + * */
>>> +extern int sched_ratelimit_us;
>>> +
>>> +
>>> =A0/*
>>> =A0* In order to allow a scheduler to remap the lock->cpu mapping,
>>> =A0* 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:18:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:18:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphC8-0000dv-Ud; Tue, 24 Jan 2012 14:17: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 1RphC7-0000cz-2W
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:17:55 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327414668!10468590!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28260 invoked from network); 24 Jan 2012 14:17:48 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 14:17:48 -0000
Received: by wibhm2 with SMTP id hm2so2663061wib.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 06:17:48 -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=Dn7Pj3DYfV3EE1kCY+sPloeORs82kMkBMKbSSO5bpAQ=;
	b=klEETr8On+C0TTi0NIl5YPVODQV9WrN090N12qdg71pEkQhlP+N4/oc2PrAMJFASqz
	r/Dd6j5KQ8XeN1Lge8nPDkHdiOX20ZN9e/tspVzEYjzmL8ZXIC3kKxQ7Yh12c6aTSit0
	hCcylksw/K/MthWdFyFb4Va31HWKBaBOpwXnc=
Received: by 10.180.84.133 with SMTP id z5mr3941927wiy.10.1327414668416;
	Tue, 24 Jan 2012 06:17:48 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id u12sm18925440wiv.10.2012.01.24.06.17.45
	(version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 06:17:46 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 24 Jan 2012 14:17:40 +0000
From: Keir Fraser <keir@xen.org>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Message-ID: <CB446E04.38059%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH] xen/sched_credit: Use delay to control
	scheduling frequency
Thread-Index: Aczaou4Ithbc4yxvykOIiCHKoau6jQ==
In-Reply-To: <CAFLBxZYa=yWp2aBrbN09MLyqhqEM86=zHAeQDuEEHeQY-6vJOg@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com, raistlin@linux.it, 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 24/01/2012 12:01, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

> Ping?

It's been in the tree for a week.

> On Tue, Jan 10, 2012 at 10:05 AM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
>> On Mon, Jan 9, 2012 at 10:22 AM, Hui Lv <hui.lv@intel.com> wrote:
>>> Updated the warning sentence for ratelimit_us.
>>> =

>>> This patch can improve Xen performance:
>>> 1. Basically, the "delay method" can achieve 11% overall performance bo=
ost
>>> 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, hi=
gh,
>>> 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 =3D 1000 is the recommen=
ded
>>> setting)
>>> =

>>> Signed-off-by: Hui Lv <hui.lv@intel.com>
>>> Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
>>> =

>>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> =

>> Just confirming this:
>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
>> =

>> Thanks, Hui.
>> =A0-George
>> =

>>> =

>>> diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -0500
>>> @@ -172,6 +172,7 @@ struct csched_private {
>>> =A0 =A0 uint32_t credit;
>>> =A0 =A0 int credit_balance;
>>> =A0 =A0 uint32_t runq_sort;
>>> + =A0 =A0unsigned ratelimit_us;
>>> =A0 =A0 /* Period of master and tick in milliseconds */
>>> =A0 =A0 unsigned tslice_ms, tick_period_us, ticks_per_tslice;
>>> =A0 =A0 unsigned credits_per_tslice;
>>> @@ -1297,10 +1298,15 @@ csched_schedule(
>>> =A0 =A0 struct csched_private *prv =3D CSCHED_PRIV(ops);
>>> =A0 =A0 struct csched_vcpu *snext;
>>> =A0 =A0 struct task_slice ret;
>>> + =A0 =A0s_time_t runtime, tslice;
>>> =

>>> =A0 =A0 CSCHED_STAT_CRANK(schedule);
>>> =A0 =A0 CSCHED_VCPU_CHECK(current);
>>> =

>>> + =A0 =A0runtime =3D now - current->runstate.state_entry_time;
>>> + =A0 =A0if ( runtime < 0 ) /* Does this ever happen? */
>>> + =A0 =A0 =A0 =A0runtime =3D 0;
>>> +
>>> =A0 =A0 if ( !is_idle_vcpu(scurr->vcpu) )
>>> =A0 =A0 {
>>> =A0 =A0 =A0 =A0 /* Update credits of a non-idle VCPU. */
>>> @@ -1313,6 +1319,35 @@ csched_schedule(
>>> =A0 =A0 =A0 =A0 scurr->pri =3D CSCHED_PRI_IDLE;
>>> =A0 =A0 }
>>> =

>>> + =A0 =A0/* Choices, choices:
>>> + =A0 =A0 * - If we have a tasklet, we need to run the idle vcpu no mat=
ter what.
>>> + =A0 =A0 * - If sched rate limiting is in effect, and the current vcpu=
 has
>>> + =A0 =A0 * =A0 run for less than that amount of time, continue the cur=
rent one,
>>> + =A0 =A0 * =A0 but with a shorter timeslice and return it immediately
>>> + =A0 =A0 * - Otherwise, chose the one with the highest priority (which=
 may
>>> + =A0 =A0 * =A0 be the one currently running)
>>> + =A0 =A0 * - If the currently running one is TS_OVER, see if there
>>> + =A0 =A0 * =A0 is a higher priority one waiting on the runqueue of ano=
ther
>>> + =A0 =A0 * =A0 cpu and steal it.
>>> + =A0 =A0 */
>>> +
>>> + =A0 =A0/* If we have schedule rate limiting enabled, check to see
>>> + =A0 =A0 * how long we've run for. */
>>> + =A0 =A0if ( !tasklet_work_scheduled
>>> + =A0 =A0 =A0 =A0 && prv->ratelimit_us
>>> + =A0 =A0 =A0 =A0 && vcpu_runnable(current)
>>> + =A0 =A0 =A0 =A0 && !is_idle_vcpu(current)
>>> + =A0 =A0 =A0 =A0 && runtime < MICROSECS(prv->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(prv->ratelimit_us);
>>> + =A0 =A0 =A0 =A0ret.migrated =3D 0;
>>> + =A0 =A0 =A0 =A0goto out;
>>> + =A0 =A0}
>>> + =A0 =A0tslice =3D MILLISECS(prv->tslice_ms);
>>> +
>>> =A0 =A0 /*
>>> =A0 =A0 =A0* Select next runnable local VCPU (ie top of local runq)
>>> =A0 =A0 =A0*/
>>> @@ -1367,11 +1402,12 @@ csched_schedule(
>>> =A0 =A0 if ( !is_idle_vcpu(snext->vcpu) )
>>> =A0 =A0 =A0 =A0 snext->start_time +=3D now;
>>> =

>>> +out:
>>> =A0 =A0 /*
>>> =A0 =A0 =A0* Return task to run next...
>>> =A0 =A0 =A0*/
>>> =A0 =A0 ret.time =3D (is_idle_vcpu(snext->vcpu) ?
>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : MILLISECS(prv->tslice_ms));
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 : tslice);
>>> =A0 =A0 ret.task =3D snext->vcpu;
>>> =

>>> =A0 =A0 CSCHED_VCPU_CHECK(ret.task);
>>> @@ -1533,6 +1569,15 @@ csched_init(struct scheduler *ops)
>>> =A0 =A0 prv->tick_period_us =3D prv->tslice_ms * 1000 / prv->ticks_per_=
tslice;
>>> =A0 =A0 prv->credits_per_tslice =3D CSCHED_CREDITS_PER_MSEC * prv->tsli=
ce_ms;
>>> =

>>> + =A0 =A0if ( MICROSECS(sched_ratelimit_us) > MILLISECS(sched_credit_ts=
lice_ms)
>>> )
>>> + =A0 =A0{
>>> + =A0 =A0 =A0 =A0printk("WARNING: sched_ratelimit_us >"
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "sched_credit_tslice_ms is undefined\n"
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Setting ratelimit_us to 1000 * tslice_ms=
\n");
>>> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D 1000 * prv->tslice_ms;
>>> + =A0 =A0}
>>> + =A0 =A0else
>>> + =A0 =A0 =A0 =A0prv->ratelimit_us =3D sched_ratelimit_us;
>>> =A0 =A0 return 0;
>>> =A0}
>>> =

>>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
>>> --- a/xen/common/schedule.c =A0 =A0 Fri Dec 16 18:46:27 2011 +0000
>>> +++ b/xen/common/schedule.c =A0 =A0 Mon Jan 09 05:21:35 2012 -0500
>>> @@ -47,6 +47,11 @@ string_param("sched", opt_sched);
>>> =A0bool_t sched_smt_power_savings =3D 0;
>>> =A0boolean_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 =3D 1000;
>>> +integer_param("sched_ratelimit_us", sched_ratelimit_us);
>>> =A0/* Various timer handlers. */
>>> =A0static void s_timer_fn(void *unused);
>>> =A0static void vcpu_periodic_timer_fn(void *data);
>>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/perfc_defn.h
>>> --- a/xen/include/xen/perfc_defn.h =A0 =A0 =A0Fri Dec 16 18:46:27 2011 =
+0000
>>> +++ b/xen/include/xen/perfc_defn.h =A0 =A0 =A0Mon Jan 09 05:21:35 2012 =
-0500
>>> @@ -16,6 +16,7 @@ PERFCOUNTER(sched_irq, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sch
>>> =A0PERFCOUNTER(sched_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: runs throu=
gh scheduler")
>>> =A0PERFCOUNTER(sched_ctx, =A0 =A0 =A0 =A0 =A0 =A0 =A0"sched: context sw=
itches")
>>> =

>>> +PERFCOUNTER(delay_ms, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: delay")
>>> =A0PERFCOUNTER(vcpu_check, =A0 =A0 =A0 =A0 =A0 =A0 "csched: vcpu_check")
>>> =A0PERFCOUNTER(schedule, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: schedule")
>>> =A0PERFCOUNTER(acct_run, =A0 =A0 =A0 =A0 =A0 =A0 =A0 "csched: acct_run")
>>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/include/xen/sched-if.h
>>> --- a/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Fri Dec 16 18:46:27 201=
1 +0000
>>> +++ b/xen/include/xen/sched-if.h =A0 =A0 =A0 =A0Mon Jan 09 05:21:35 201=
2 -0500
>>> @@ -16,6 +16,11 @@ extern struct cpupool *cpupool0;
>>> =A0/* cpus currently in no cpupool */
>>> =A0extern cpumask_t cpupool_free_cpus;
>>> =

>>> +/* Scheduler generic parameters
>>> + * */
>>> +extern int sched_ratelimit_us;
>>> +
>>> +
>>> =A0/*
>>> =A0* In order to allow a scheduler to remap the lock->cpu mapping,
>>> =A0* 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:23:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphGs-0001Bz-6E; Tue, 24 Jan 2012 14:22:50 +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 1RphGr-0001BX-BB
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:22:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327414961!3135571!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk4Njg2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3060 invoked from network); 24 Jan 2012 14:22:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 14:22:43 -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
	q0OEJrT3020165
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 14:19:54 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0OEJqdx004691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jan 2012 14:19:52 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
	q0OEJpBT005881; Tue, 24 Jan 2012 08:19:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Jan 2012 06:19:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 90C4040167; Tue, 24 Jan 2012 09:17:35 -0500 (EST)
Date: Tue, 24 Jan 2012 09:17:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120124141735.GA31731@phenom.dumpdata.com>
References: <20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<4F16BC97020000780006D6D6@nat28.tlf.novell.com>
	<20120118142923.GA6052@andromeda.dapyr.net>
	<20120123223213.GA31929@phenom.dumpdata.com>
	<4F1E80BE020000780006E9FB@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1E80BE020000780006E9FB@nat28.tlf.novell.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.0A090208.4F1EBE7E.00DD,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 08:58:22AM +0000, Jan Beulich wrote:
> >>> On 23.01.12 at 23:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> >> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > > The issue as I understand is that the DVB drivers allocate their buffers
> >> > > from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> >> > > 
> >> > > While the pv-ops one ends up quite frequently doing the bounce-buffering, 
> >> > > which
> >> > > implies that the DVB drivers end up allocating their buffers above the 
> > 4GB.
> >> > > This means we end up spending some CPU time (in the guest) copying the 
> >> > > memory
> >> > > from >4GB to 0-4GB region (And vice-versa).
> >> > 
> >> > This reminds me of something (not sure what XenoLinux you use for
> >> > comparison) - how are they allocating that memory? Not vmalloc_32()
> >> 
> >> I was using the 2.6.18, then the one I saw on Google for Gentoo, and now
> >> I am going to look at the 2.6.38 from OpenSuSE.
> >> 
> >> > by chance (I remember having seen numerous uses under - iirc -
> >> > drivers/media/)?
> >> > 
> >> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
> >> > what their (driver) callers might expect in a PV guest (including the
> >> > contiguity assumption for the latter, recalling that you earlier said
> >> > you were able to see the problem after several guest starts), and I
> >> > had put into our kernels an adjustment to make vmalloc_32() actually
> >> > behave as expected.
> >> 
> >> Aaah.. The plot thickens! Let me look in the sources! Thanks for the
> >> pointer.
> > 
> > Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32
> > and then performs PCI DMA operations on the allocted vmalloc_32
> > area.
> > 
> > So I cobbled up the attached patch (hadn't actually tested it and sadly
> > won't until next week) which removes the call to vmalloc_32 and instead
> > sets up DMA allocated set of pages.
> 
> What a big patch (which would need re-doing for every vmalloc_32()
> caller)! Fixing vmalloc_32() would be much less intrusive (reproducing
> our 3.2 version of the affected function below, but clearly that's not
> pv-ops ready).

I just want to get to the bottom of this before attempting a proper fix.

> 
> Jan
> 
> static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> 				 pgprot_t prot, int node, void *caller)
> {
> 	const int order = 0;
> 	struct page **pages;
> 	unsigned int nr_pages, array_size, i;
> 	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> #ifdef CONFIG_XEN
> 	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> 
> 	BUILD_BUG_ON((__GFP_DMA | __GFP_DMA32) != (__GFP_DMA + __GFP_DMA32));
> 	if (dma_mask == (__GFP_DMA | __GFP_DMA32))
> 		gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> #endif
> 
> 	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> 	array_size = (nr_pages * sizeof(struct page *));
> 
> 	area->nr_pages = nr_pages;
> 	/* Please note that the recursion is strictly bounded. */
> 	if (array_size > PAGE_SIZE) {
> 		pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM,
> 				PAGE_KERNEL, node, caller);
> 		area->flags |= VM_VPAGES;
> 	} else {
> 		pages = kmalloc_node(array_size, nested_gfp, node);
> 	}
> 	area->pages = pages;
> 	area->caller = caller;
> 	if (!area->pages) {
> 		remove_vm_area(area->addr);
> 		kfree(area);
> 		return NULL;
> 	}
> 
> 	for (i = 0; i < area->nr_pages; i++) {
> 		struct page *page;
> 		gfp_t tmp_mask = gfp_mask | __GFP_NOWARN;
> 
> 		if (node < 0)
> 			page = alloc_page(tmp_mask);
> 		else
> 			page = alloc_pages_node(node, tmp_mask, order);
> 
> 		if (unlikely(!page)) {
> 			/* Successfully allocated i pages, free them in __vunmap() */
> 			area->nr_pages = i;
> 			goto fail;
> 		}
> 		area->pages[i] = page;
> #ifdef CONFIG_XEN
> 		if (dma_mask) {
> 			if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
> 				area->nr_pages = i + 1;
> 				goto fail;
> 			}
> 			if (gfp_mask & __GFP_ZERO)
> 				clear_highpage(page);
> 		}
> #endif
> 	}
> 
> 	if (map_vm_area(area, prot, &pages))
> 		goto fail;
> 	return area->addr;
> 
> fail:
> 	warn_alloc_failed(gfp_mask, order,
> 			  "vmalloc: allocation failure, allocated %ld of %ld bytes\n",
> 			  (area->nr_pages*PAGE_SIZE), area->size);
> 	vfree(area->addr);
> 	return NULL;
> }
> 
> ...
> 
> #if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
> #define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
> #elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
> #define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
> #elif defined(CONFIG_XEN)
> #define GFP_VMALLOC32 __GFP_DMA | __GFP_DMA32 | GFP_KERNEL
> #else
> #define GFP_VMALLOC32 GFP_KERNEL
> #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:23:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:23:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphGs-0001Bz-6E; Tue, 24 Jan 2012 14:22:50 +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 1RphGr-0001BX-BB
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:22:49 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327414961!3135571!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNDk4Njg2\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3060 invoked from network); 24 Jan 2012 14:22:43 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 14:22:43 -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
	q0OEJrT3020165
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 14:19:54 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0OEJqdx004691
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jan 2012 14:19:52 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
	q0OEJpBT005881; Tue, 24 Jan 2012 08:19:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Jan 2012 06:19:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 90C4040167; Tue, 24 Jan 2012 09:17:35 -0500 (EST)
Date: Tue, 24 Jan 2012 09:17:35 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120124141735.GA31731@phenom.dumpdata.com>
References: <20111219145609.GB28969@andromeda.dapyr.net>
	<20120110215533.GA21862@phenom.dumpdata.com>
	<1442969761.20120112230601@eikelenboom.it>
	<20120113151307.GC5025@phenom.dumpdata.com>
	<1383590207.20120115123259@eikelenboom.it>
	<20120117210225.GA23782@phenom.dumpdata.com>
	<4F16BC97020000780006D6D6@nat28.tlf.novell.com>
	<20120118142923.GA6052@andromeda.dapyr.net>
	<20120123223213.GA31929@phenom.dumpdata.com>
	<4F1E80BE020000780006E9FB@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1E80BE020000780006E9FB@nat28.tlf.novell.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.0A090208.4F1EBE7E.00DD,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 08:58:22AM +0000, Jan Beulich wrote:
> >>> On 23.01.12 at 23:32, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> >> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> >> > > The issue as I understand is that the DVB drivers allocate their buffers
> >> > > from 0->4GB most (all the time?) so they never have to do bounce-buffering.
> >> > > 
> >> > > While the pv-ops one ends up quite frequently doing the bounce-buffering, 
> >> > > which
> >> > > implies that the DVB drivers end up allocating their buffers above the 
> > 4GB.
> >> > > This means we end up spending some CPU time (in the guest) copying the 
> >> > > memory
> >> > > from >4GB to 0-4GB region (And vice-versa).
> >> > 
> >> > This reminds me of something (not sure what XenoLinux you use for
> >> > comparison) - how are they allocating that memory? Not vmalloc_32()
> >> 
> >> I was using the 2.6.18, then the one I saw on Google for Gentoo, and now
> >> I am going to look at the 2.6.38 from OpenSuSE.
> >> 
> >> > by chance (I remember having seen numerous uses under - iirc -
> >> > drivers/media/)?
> >> > 
> >> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do
> >> > what their (driver) callers might expect in a PV guest (including the
> >> > contiguity assumption for the latter, recalling that you earlier said
> >> > you were able to see the problem after several guest starts), and I
> >> > had put into our kernels an adjustment to make vmalloc_32() actually
> >> > behave as expected.
> >> 
> >> Aaah.. The plot thickens! Let me look in the sources! Thanks for the
> >> pointer.
> > 
> > Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32
> > and then performs PCI DMA operations on the allocted vmalloc_32
> > area.
> > 
> > So I cobbled up the attached patch (hadn't actually tested it and sadly
> > won't until next week) which removes the call to vmalloc_32 and instead
> > sets up DMA allocated set of pages.
> 
> What a big patch (which would need re-doing for every vmalloc_32()
> caller)! Fixing vmalloc_32() would be much less intrusive (reproducing
> our 3.2 version of the affected function below, but clearly that's not
> pv-ops ready).

I just want to get to the bottom of this before attempting a proper fix.

> 
> Jan
> 
> static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask,
> 				 pgprot_t prot, int node, void *caller)
> {
> 	const int order = 0;
> 	struct page **pages;
> 	unsigned int nr_pages, array_size, i;
> 	gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> #ifdef CONFIG_XEN
> 	gfp_t dma_mask = gfp_mask & (__GFP_DMA | __GFP_DMA32);
> 
> 	BUILD_BUG_ON((__GFP_DMA | __GFP_DMA32) != (__GFP_DMA + __GFP_DMA32));
> 	if (dma_mask == (__GFP_DMA | __GFP_DMA32))
> 		gfp_mask &= ~(__GFP_DMA | __GFP_DMA32);
> #endif
> 
> 	nr_pages = (area->size - PAGE_SIZE) >> PAGE_SHIFT;
> 	array_size = (nr_pages * sizeof(struct page *));
> 
> 	area->nr_pages = nr_pages;
> 	/* Please note that the recursion is strictly bounded. */
> 	if (array_size > PAGE_SIZE) {
> 		pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM,
> 				PAGE_KERNEL, node, caller);
> 		area->flags |= VM_VPAGES;
> 	} else {
> 		pages = kmalloc_node(array_size, nested_gfp, node);
> 	}
> 	area->pages = pages;
> 	area->caller = caller;
> 	if (!area->pages) {
> 		remove_vm_area(area->addr);
> 		kfree(area);
> 		return NULL;
> 	}
> 
> 	for (i = 0; i < area->nr_pages; i++) {
> 		struct page *page;
> 		gfp_t tmp_mask = gfp_mask | __GFP_NOWARN;
> 
> 		if (node < 0)
> 			page = alloc_page(tmp_mask);
> 		else
> 			page = alloc_pages_node(node, tmp_mask, order);
> 
> 		if (unlikely(!page)) {
> 			/* Successfully allocated i pages, free them in __vunmap() */
> 			area->nr_pages = i;
> 			goto fail;
> 		}
> 		area->pages[i] = page;
> #ifdef CONFIG_XEN
> 		if (dma_mask) {
> 			if (xen_limit_pages_to_max_mfn(page, 0, 32)) {
> 				area->nr_pages = i + 1;
> 				goto fail;
> 			}
> 			if (gfp_mask & __GFP_ZERO)
> 				clear_highpage(page);
> 		}
> #endif
> 	}
> 
> 	if (map_vm_area(area, prot, &pages))
> 		goto fail;
> 	return area->addr;
> 
> fail:
> 	warn_alloc_failed(gfp_mask, order,
> 			  "vmalloc: allocation failure, allocated %ld of %ld bytes\n",
> 			  (area->nr_pages*PAGE_SIZE), area->size);
> 	vfree(area->addr);
> 	return NULL;
> }
> 
> ...
> 
> #if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
> #define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
> #elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
> #define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
> #elif defined(CONFIG_XEN)
> #define GFP_VMALLOC32 __GFP_DMA | __GFP_DMA32 | GFP_KERNEL
> #else
> #define GFP_VMALLOC32 GFP_KERNEL
> #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:26:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphKS-0001OT-Tq; Tue, 24 Jan 2012 14:26: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 1RphKR-0001Nr-60
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:26:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327415184!10302538!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13450 invoked from network); 24 Jan 2012 14:26:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 14:26:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10250553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 14:26:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 14:26:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Tue, 24 Jan 2012 14:26:24 +0000
In-Reply-To: <1327332514.25697.140661026919117@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327415184.24561.182.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 15:28 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> On Mon, Jan 23, 2012, at 11:27 AM, Ian Campbell wrote:
> > ISTRT xl had a bug at one point where it would fail to strip whitespace
> > in the network KVP lists. i.e. the above ended up expecting to find a
> > bridge named "br0  ". Can you try without the spaces please?
> 
> Edit the configuration file.
> 
>  - vif          = [ 'mac=00:16:3E:12:34:01, bridge=br0' ]
>  + vif=['mac=00:16:3E:12:34:01,bridge=br0']
>
[...]
> brctl show
>  bridge name     bridge id               STP enabled     interfaces
>  br0             8000.0052351d5337       yes             eth0

Hrm. The device simply isn't on the bridge. Does "ifconfig -a" in dom0
show a vifX.Y device for the domain? You previous xenstore log suggests
it should be there but lets double check.

Do you get anything in the logs under /var/log/xen?

Are your hotplug scripts running at all? One trick I usually use is to
add to the top of vif-bridge something like:
	exec 1>>/tmp/hotplog.log
	exec 2>&1
	echo "`date`: Running $0 $*"
Then any hotplug script which gets run will dump its output
to /tmp/hotplug.log.

http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen lists a bunch of
configuration files and logs which might be of interest, at least to
skim looking for anything odd.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:26:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:26:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphKS-0001OT-Tq; Tue, 24 Jan 2012 14:26: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 1RphKR-0001Nr-60
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:26:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327415184!10302538!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13450 invoked from network); 24 Jan 2012 14:26:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 14:26:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10250553"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 14:26:24 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 24 Jan 2012 14:26:24 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Tue, 24 Jan 2012 14:26:24 +0000
In-Reply-To: <1327332514.25697.140661026919117@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327415184.24561.182.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 15:28 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> On Mon, Jan 23, 2012, at 11:27 AM, Ian Campbell wrote:
> > ISTRT xl had a bug at one point where it would fail to strip whitespace
> > in the network KVP lists. i.e. the above ended up expecting to find a
> > bridge named "br0  ". Can you try without the spaces please?
> 
> Edit the configuration file.
> 
>  - vif          = [ 'mac=00:16:3E:12:34:01, bridge=br0' ]
>  + vif=['mac=00:16:3E:12:34:01,bridge=br0']
>
[...]
> brctl show
>  bridge name     bridge id               STP enabled     interfaces
>  br0             8000.0052351d5337       yes             eth0

Hrm. The device simply isn't on the bridge. Does "ifconfig -a" in dom0
show a vifX.Y device for the domain? You previous xenstore log suggests
it should be there but lets double check.

Do you get anything in the logs under /var/log/xen?

Are your hotplug scripts running at all? One trick I usually use is to
add to the top of vif-bridge something like:
	exec 1>>/tmp/hotplog.log
	exec 2>&1
	echo "`date`: Running $0 $*"
Then any hotplug script which gets run will dump its output
to /tmp/hotplug.log.

http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen lists a bunch of
configuration files and logs which might be of interest, at least to
skim looking for anything odd.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:31:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphPL-0001kM-DO; Tue, 24 Jan 2012 14:31:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RphPJ-0001jP-Na
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:31:34 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327415487!12216539!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18951 invoked from network); 24 Jan 2012 14:31:27 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 14:31:27 -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=SvkPcNePIv/LygBBTnDCeLJ1taV0nwRWGLOUqGXWkFENVRCdwp188ti0
	JJtd3prP7zsQDLpQVegO2GgwHfFeuEzLGhBgCMZ9t3z7UiTb4L+1aMR7D
	6c76GWDFsWSiGP5mDPnekJIn8hcXmyTW4jEQ7w8O9GVnFF5B2PRfvOklO
	yKG2rnRX2VeWwiudrWfF4VT2v0e2XfmfowOxHPMatyELRfJ3VFTDmyBnI
	v3vUcLxBB0FqEvS1Nakv0vONmnVgE;
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=1327415487; x=1358951487;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=97OS0uzYkRZNkggZ7S0WXT07JW4C+09SX7EJ1GvBDfA=;
	b=MW4e9P1OvAJWtzW6E71F0gBYKY2hVFAm3CxxpIUPTP4AXE9jt928m1XV
	hh6HrktVKVj1etzxJlpiPLEo3ObdEjF5HzPnmdNj4xOPLtOp6aoh66GtC
	mrxO9piZvaAEB+P0DVSUCD7/pcp9GCWXiB6phgu8m3NFtapn7miQhi+Ef
	hWq/bWhOg/s9JDpD4podVa4EdK8rDGb45mbxXvd3bFShnuwv3CJwJU/yB
	FeYUsk3PTvvE9l8/GW8klknkGCJ9o;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84382783"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 15:31:26 +0100
X-IronPort-AV: E=Sophos;i="4.71,562,1320620400"; d="scan'208";a="127660112"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 15:31:26 +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 9B2DF95AB6B;
	Tue, 24 Jan 2012 15:31:26 +0100 (CET)
Message-ID: <4F1EC0BE.8050904@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 15:31:26 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 02:19 PM, Ian Campbell wrote:
> Newly updated list follows. Please send me corrections (especially
> "done"). I've stopped CCing everyone, since I guess it is mostly spam to
> the majority.
>
> hypervisor, blockers:
>
>        * round-up of the closing of the security hole in MSI-X
>          passthrough (uniformly - i.e. even for Dom0 - disallowing write
>          access to MSI-X table pages). (Jan Beulich -- more fixes
>          required than first thought, patches posted)
>        * domctls / sysctls set up to modify scheduler parameters, like
>          the credit1 timeslice and schedule rate. (George Dunlap)
>        * get the interface changes for sharing/paging/mem-events done and
>          dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>          Andres Lagar-Cavilla et al)
>                * mem event ring management posted, seems close to going
>                  in.
>                * sharing patches posted
>
> tools, blockers:
>
>        * libxl stable API -- we would like 4.2 to define a stable API
>          which downstream's can start to rely on not changing. Aspects of
>          this are:
>                * event handling (Ian Jackson, posted several rounds,
>                  nearing completion?)
>                * drop libxl_device_model_info (move bits to build_info or
>                  elsewhere as appropriate) (Ian Campbell, first RFC sent)
>                * add libxl_defbool and generally try and arrange that
>                  memset(foo,0,...) requests the defaults (Ian Campbell,
>                  first RFC sent)
>                * topologyinfo datastructure should be a list of tuples,
>                  not a tuple of lists. (nobody currently looking at this,
>                  not 100% sure this makes sense, could possibly defer and
>                  change after 4.2 in a compatible way)
>        * xl to use json for machine readable output instead of sexp by
>          default (Ian Campbell to revisit existing patch)
>        * xl support for vcpu pinning (Dario Faggioli)
>        * xl feature parity with xend wrt driver domain support (George
>          Dunlap)
>        * Integrate qemu+seabios upstream into the build (patches
>          reposted, pending). No change in default qemu for 4.2.
>        * More formally deprecate xm/xend. Manpage patches already in
>          tree. Needs release noting and communication around -rc1 to
>          remind people to test xl.
>
> hypervisor, nice to have:
>
>        * solid implementation of sharing/paging/mem-events (using work
>          queues) (Tim Deegan, Olaf Herring et al)
>        * A long standing issue is a fully synchronized p2m (locking
>          lookups) (Andres Lagar-Cavilla)
>        * NUMA improvement: domain affinity consistent with cpupool
>          membership (Dario Faggioli, Jeurgen Gross -- patch posted)

Patches accepted (cs24549..24551)

> tools, nice to have:
>
>        * Hotplug script stuff -- internal to libxl (I think, therefore I
>          didn't put this under stable API above) but still good to have
>          for 4.2? Roger Pau Monet was looking at this but its looking
>          like a big can-o-worms. (discussion on-going)
>        * Block script support -- follows on from hotplug script (Roger
>          Pau Monet)
>        * libyajl v2 support (patch posted by Roger Pau Monet, blocked on
>          autoconf?)
>        * Configure/control paging via xl/libxl (Olaf Herring)
>        * Upstream qemu feature patches:
>                * Upstream qemu PCI passthrough support (Anthony Perard)
>                * Upstream qemu save restore (Anthony Perard)
>        * Nested-virtualisation (currently should be marked
>          experimental,likely to release that way? Consider nested-svm
>          separate to nested-vmx. Nested-svm is in better shape)
>
> Tools, need to decide if pre- or post-4.2 feature:
>
>        * Autoconf (Roger Pau Monet posted a patch)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:31:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:31:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphPL-0001kM-DO; Tue, 24 Jan 2012 14:31:35 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RphPJ-0001jP-Na
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:31:34 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327415487!12216539!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NDI3MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18951 invoked from network); 24 Jan 2012 14:31:27 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 14:31:27 -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=SvkPcNePIv/LygBBTnDCeLJ1taV0nwRWGLOUqGXWkFENVRCdwp188ti0
	JJtd3prP7zsQDLpQVegO2GgwHfFeuEzLGhBgCMZ9t3z7UiTb4L+1aMR7D
	6c76GWDFsWSiGP5mDPnekJIn8hcXmyTW4jEQ7w8O9GVnFF5B2PRfvOklO
	yKG2rnRX2VeWwiudrWfF4VT2v0e2XfmfowOxHPMatyELRfJ3VFTDmyBnI
	v3vUcLxBB0FqEvS1Nakv0vONmnVgE;
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=1327415487; x=1358951487;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=97OS0uzYkRZNkggZ7S0WXT07JW4C+09SX7EJ1GvBDfA=;
	b=MW4e9P1OvAJWtzW6E71F0gBYKY2hVFAm3CxxpIUPTP4AXE9jt928m1XV
	hh6HrktVKVj1etzxJlpiPLEo3ObdEjF5HzPnmdNj4xOPLtOp6aoh66GtC
	mrxO9piZvaAEB+P0DVSUCD7/pcp9GCWXiB6phgu8m3NFtapn7miQhi+Ef
	hWq/bWhOg/s9JDpD4podVa4EdK8rDGb45mbxXvd3bFShnuwv3CJwJU/yB
	FeYUsk3PTvvE9l8/GW8klknkGCJ9o;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,561,1320620400"; d="scan'208";a="84382783"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 24 Jan 2012 15:31:26 +0100
X-IronPort-AV: E=Sophos;i="4.71,562,1320620400"; d="scan'208";a="127660112"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 24 Jan 2012 15:31:26 +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 9B2DF95AB6B;
	Tue, 24 Jan 2012 15:31:26 +0100 (CET)
Message-ID: <4F1EC0BE.8050904@ts.fujitsu.com>
Date: Tue, 24 Jan 2012 15:31:26 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/23/2012 02:19 PM, Ian Campbell wrote:
> Newly updated list follows. Please send me corrections (especially
> "done"). I've stopped CCing everyone, since I guess it is mostly spam to
> the majority.
>
> hypervisor, blockers:
>
>        * round-up of the closing of the security hole in MSI-X
>          passthrough (uniformly - i.e. even for Dom0 - disallowing write
>          access to MSI-X table pages). (Jan Beulich -- more fixes
>          required than first thought, patches posted)
>        * domctls / sysctls set up to modify scheduler parameters, like
>          the credit1 timeslice and schedule rate. (George Dunlap)
>        * get the interface changes for sharing/paging/mem-events done and
>          dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>          Andres Lagar-Cavilla et al)
>                * mem event ring management posted, seems close to going
>                  in.
>                * sharing patches posted
>
> tools, blockers:
>
>        * libxl stable API -- we would like 4.2 to define a stable API
>          which downstream's can start to rely on not changing. Aspects of
>          this are:
>                * event handling (Ian Jackson, posted several rounds,
>                  nearing completion?)
>                * drop libxl_device_model_info (move bits to build_info or
>                  elsewhere as appropriate) (Ian Campbell, first RFC sent)
>                * add libxl_defbool and generally try and arrange that
>                  memset(foo,0,...) requests the defaults (Ian Campbell,
>                  first RFC sent)
>                * topologyinfo datastructure should be a list of tuples,
>                  not a tuple of lists. (nobody currently looking at this,
>                  not 100% sure this makes sense, could possibly defer and
>                  change after 4.2 in a compatible way)
>        * xl to use json for machine readable output instead of sexp by
>          default (Ian Campbell to revisit existing patch)
>        * xl support for vcpu pinning (Dario Faggioli)
>        * xl feature parity with xend wrt driver domain support (George
>          Dunlap)
>        * Integrate qemu+seabios upstream into the build (patches
>          reposted, pending). No change in default qemu for 4.2.
>        * More formally deprecate xm/xend. Manpage patches already in
>          tree. Needs release noting and communication around -rc1 to
>          remind people to test xl.
>
> hypervisor, nice to have:
>
>        * solid implementation of sharing/paging/mem-events (using work
>          queues) (Tim Deegan, Olaf Herring et al)
>        * A long standing issue is a fully synchronized p2m (locking
>          lookups) (Andres Lagar-Cavilla)
>        * NUMA improvement: domain affinity consistent with cpupool
>          membership (Dario Faggioli, Jeurgen Gross -- patch posted)

Patches accepted (cs24549..24551)

> tools, nice to have:
>
>        * Hotplug script stuff -- internal to libxl (I think, therefore I
>          didn't put this under stable API above) but still good to have
>          for 4.2? Roger Pau Monet was looking at this but its looking
>          like a big can-o-worms. (discussion on-going)
>        * Block script support -- follows on from hotplug script (Roger
>          Pau Monet)
>        * libyajl v2 support (patch posted by Roger Pau Monet, blocked on
>          autoconf?)
>        * Configure/control paging via xl/libxl (Olaf Herring)
>        * Upstream qemu feature patches:
>                * Upstream qemu PCI passthrough support (Anthony Perard)
>                * Upstream qemu save restore (Anthony Perard)
>        * Nested-virtualisation (currently should be marked
>          experimental,likely to release that way? Consider nested-svm
>          separate to nested-vmx. Nested-svm is in better shape)
>
> Tools, need to decide if pre- or post-4.2 feature:
>
>        * Autoconf (Roger Pau Monet posted a patch)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>


-- 
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@ts.fujitsu.com
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:32:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphPr-0001pI-S4; Tue, 24 Jan 2012 14:32:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RphPq-0001oP-N4
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:32:07 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327415518!12191701!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30021 invoked from network); 24 Jan 2012 14:31:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 14:31:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="21221479"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 09:31: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, 24 Jan 2012 09:31:34 -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 q0OEVVYK002437;
	Tue, 24 Jan 2012 06:31:32 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CB446E04.38059%keir@xen.org>
References: <CB446E04.38059%keir@xen.org>
Date: Tue, 24 Jan 2012 14:31:30 +0000
Message-ID: <1327415490.26455.352.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>,
	"raistlin@linux.it" <raistlin@linux.it>,
	"JBeulich@suse.com" <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

On Tue, 2012-01-24 at 14:17 +0000, Keir Fraser wrote:
> On 24/01/2012 12:01, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:
> 
> > Ping?
> 
> It's been in the tree for a week.


Sorry -- I was sure I looked for it and didn't see it; but now I look
again, there it is. :-/

 -George

> 
> > On Tue, Jan 10, 2012 at 10:05 AM, George Dunlap
> > <George.Dunlap@eu.citrix.com> wrote:
> >> On Mon, Jan 9, 2012 at 10:22 AM, Hui Lv <hui.lv@intel.com> wrote:
> >>> Updated the warning sentence for ratelimit_us.
> >>> 
> >>> 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>
> >>> 
> >>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> >> 
> >> Just confirming this:
> >> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> >> 
> >> Thanks, Hui.
> >>  -George
> >> 
> >>> 
> >>> diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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"
> >>> +               "Setting ratelimit_us to 1000 * tslice_ms\n");
> >>> +        prv->ratelimit_us = 1000 * prv->tslice_ms;
> >>> +    }
> >>> +    else
> >>> +        prv->ratelimit_us = sched_ratelimit_us;
> >>>     return 0;
> >>>  }
> >>> 
> >>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
> >>> --- a/xen/common/schedule.c     Fri Dec 16 18:46:27 2011 +0000
> >>> +++ b/xen/common/schedule.c     Mon Jan 09 05:21:35 2012 -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 fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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 fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:32:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14:32:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RphPr-0001pI-S4; Tue, 24 Jan 2012 14:32:07 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RphPq-0001oP-N4
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 14:32:07 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327415518!12191701!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30021 invoked from network); 24 Jan 2012 14:31:59 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 14:31:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="21221479"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 09:31: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, 24 Jan 2012 09:31:34 -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 q0OEVVYK002437;
	Tue, 24 Jan 2012 06:31:32 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CB446E04.38059%keir@xen.org>
References: <CB446E04.38059%keir@xen.org>
Date: Tue, 24 Jan 2012 14:31:30 +0000
Message-ID: <1327415490.26455.352.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>,
	"raistlin@linux.it" <raistlin@linux.it>,
	"JBeulich@suse.com" <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

On Tue, 2012-01-24 at 14:17 +0000, Keir Fraser wrote:
> On 24/01/2012 12:01, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:
> 
> > Ping?
> 
> It's been in the tree for a week.


Sorry -- I was sure I looked for it and didn't see it; but now I look
again, there it is. :-/

 -George

> 
> > On Tue, Jan 10, 2012 at 10:05 AM, George Dunlap
> > <George.Dunlap@eu.citrix.com> wrote:
> >> On Mon, Jan 9, 2012 at 10:22 AM, Hui Lv <hui.lv@intel.com> wrote:
> >>> Updated the warning sentence for ratelimit_us.
> >>> 
> >>> 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>
> >>> 
> >>> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> >> 
> >> Just confirming this:
> >> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
> >> 
> >> Thanks, Hui.
> >>  -George
> >> 
> >>> 
> >>> diff -r a4bff36780a3 -r fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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"
> >>> +               "Setting ratelimit_us to 1000 * tslice_ms\n");
> >>> +        prv->ratelimit_us = 1000 * prv->tslice_ms;
> >>> +    }
> >>> +    else
> >>> +        prv->ratelimit_us = sched_ratelimit_us;
> >>>     return 0;
> >>>  }
> >>> 
> >>> diff -r a4bff36780a3 -r fe8d0ca867aa xen/common/schedule.c
> >>> --- a/xen/common/schedule.c     Fri Dec 16 18:46:27 2011 +0000
> >>> +++ b/xen/common/schedule.c     Mon Jan 09 05:21:35 2012 -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 fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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 fe8d0ca867aa 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 Jan 09 05:21:35 2012 -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
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:37:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14: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 1RphVD-0002Nh-K9; Tue, 24 Jan 2012 14:37:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1RphVB-0002NH-S7; Tue, 24 Jan 2012 14:37:38 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327415805!51546863!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4542 invoked from network); 24 Jan 2012 14:36:45 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-5.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 14:36:45 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id ED875D3477F;
	Tue, 24 Jan 2012 15:37:32 +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 Tj6n4Pwuzwzs; Tue, 24 Jan 2012 15:37:25 +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 66EEDD341CA;
	Tue, 24 Jan 2012 15:37:25 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: djmagee@mageenet.net
Date: Tue, 24 Jan 2012 15:37:24 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
MIME-Version: 1.0
Message-Id: <201201241537.24507.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag, 24. Januar 2012, 15:12:40 schrieb djmagee@mageenet.net:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> > Sent: Monday, January 23, 2012 8:50 PM
> > To: Tobias Geiger
> > Cc: Sandi Romih; chris; xen-devel@lists.xensource.com; xen-
> > users@lists.xensource.com; Ian Campbell
> > Subject: Re: [Xen-devel] [Xen-users] VGA passthough still not working
> > 
> > On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> > > Hello!
> > > 
> > > The thing is, you either dont need patches at all to get it to work
> > 
> > (ATI), or
> > 
> > > you need to customize patches reflecting your individual setup
> > 
> > (NVIDIA);
> > 
> > > To be more specific:
> > > I can confirm that passing through a ATI Card works "out of the box"
> > 
> > - either
> > 
> > > to Windows 7 or Windows XP;
> > > In the past i had a setup running with a NVIDIA card, it only worked
> > 
> > with
> > 
> > > special patches (the ones David packed together and offers as
> > 
> > tarball) and - as
> > 
> > > far as i can tell - are not generaly working for all NVIDIA Cards,
> > 
> > i.e. you
> > 
> > > have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
> > 
> > then the
> > 
> > > passed through Card worked only with Windows XP - NOT with Windows
> 
> 7;
> 
> > > Both setup have the "flaw" that they only work once - meaning you
> > 
> > can't reboot
> > 
> > > your DomU , cause after the reboot the passed-through Card doesnt
> > 
> > have correct
> > 
> > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > 
> > Windows XP and
> > 
> > > Windows7 )
> > 
> > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > 
> > Anybody had luck with passing the card more than once to a guest? With
> > any random set of patches?
> 

I was a bit un-percice regarding the "reboot" issue:

The passing-through itself works even after a reboot of DomU - the rebooted 
System spits out its Graphics normaly through the passed-through Card (NVIDA 
or ATI doesnt matter here) ; BUT:
After a reboot it doesn't work properly. Meaning: Slow 3d Performance, i.e. 
unsable for real 3d apps, even a 3d Desktop;
For example, when the Card gives you 70fps in a Benchmark after a fresh Cold 
Boot, it only gives you 5-10fps after a reboot, this will be that low until 
you reboot Dom0 also, not only DomU;

hopefully i described the scenario better now...


> Yes, I've had a machine running for a couple of weeks, hosting a Windows
> 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> machine multiple times, as well as gone through a couple of xl
> destroy/create cycles.
> 
> I only pass it through as a secondary card, as I have the IGD as the
> primary on the host.  The machine is a DQ67SW with a Core i5.  This is
> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.
> 
> I haven't, however, had any luck passing through the IGD to anything
> other than a Windows XP, and that includes running the latest qemu-xen
> with Jean's patches (opregion, host bridge config space mapping).  I've
> been intending to start a separate thread for that...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 14:37:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 14: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 1RphVD-0002Nh-K9; Tue, 24 Jan 2012 14:37:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1RphVB-0002NH-S7; Tue, 24 Jan 2012 14:37:38 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327415805!51546863!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4542 invoked from network); 24 Jan 2012 14:36:45 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-5.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 14:36:45 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id ED875D3477F;
	Tue, 24 Jan 2012 15:37:32 +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 Tj6n4Pwuzwzs; Tue, 24 Jan 2012 15:37:25 +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 66EEDD341CA;
	Tue, 24 Jan 2012 15:37:25 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: djmagee@mageenet.net
Date: Tue, 24 Jan 2012 15:37:24 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
MIME-Version: 1.0
Message-Id: <201201241537.24507.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]  VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag, 24. Januar 2012, 15:12:40 schrieb djmagee@mageenet.net:
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of Konrad Rzeszutek Wilk
> > Sent: Monday, January 23, 2012 8:50 PM
> > To: Tobias Geiger
> > Cc: Sandi Romih; chris; xen-devel@lists.xensource.com; xen-
> > users@lists.xensource.com; Ian Campbell
> > Subject: Re: [Xen-devel] [Xen-users] VGA passthough still not working
> > 
> > On Mon, Jan 23, 2012 at 02:17:42PM +0100, Tobias Geiger wrote:
> > > Hello!
> > > 
> > > The thing is, you either dont need patches at all to get it to work
> > 
> > (ATI), or
> > 
> > > you need to customize patches reflecting your individual setup
> > 
> > (NVIDIA);
> > 
> > > To be more specific:
> > > I can confirm that passing through a ATI Card works "out of the box"
> > 
> > - either
> > 
> > > to Windows 7 or Windows XP;
> > > In the past i had a setup running with a NVIDIA card, it only worked
> > 
> > with
> > 
> > > special patches (the ones David packed together and offers as
> > 
> > tarball) and - as
> > 
> > > far as i can tell - are not generaly working for all NVIDIA Cards,
> > 
> > i.e. you
> > 
> > > have to adjust Memory-Adresses in the acpi.dst (iirc). - and even
> > 
> > then the
> > 
> > > passed through Card worked only with Windows XP - NOT with Windows
> 
> 7;
> 
> > > Both setup have the "flaw" that they only work once - meaning you
> > 
> > can't reboot
> > 
> > > your DomU , cause after the reboot the passed-through Card doesnt
> > 
> > have correct
> > 
> > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > 
> > Windows XP and
> > 
> > > Windows7 )
> > 
> > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > 
> > Anybody had luck with passing the card more than once to a guest? With
> > any random set of patches?
> 

I was a bit un-percice regarding the "reboot" issue:

The passing-through itself works even after a reboot of DomU - the rebooted 
System spits out its Graphics normaly through the passed-through Card (NVIDA 
or ATI doesnt matter here) ; BUT:
After a reboot it doesn't work properly. Meaning: Slow 3d Performance, i.e. 
unsable for real 3d apps, even a 3d Desktop;
For example, when the Card gives you 70fps in a Benchmark after a fresh Cold 
Boot, it only gives you 5-10fps after a reboot, this will be that low until 
you reboot Dom0 also, not only DomU;

hopefully i described the scenario better now...


> Yes, I've had a machine running for a couple of weeks, hosting a Windows
> 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> machine multiple times, as well as gone through a couple of xl
> destroy/create cycles.
> 
> I only pass it through as a secondary card, as I have the IGD as the
> primary on the host.  The machine is a DQ67SW with a Core i5.  This is
> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra patches.
> 
> I haven't, however, had any luck passing through the IGD to anything
> other than a Windows XP, and that includes running the latest qemu-xen
> with Jean's patches (opregion, host bridge config space mapping).  I've
> been intending to start a separate thread for that...


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 15:23:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpiDd-0004sY-Df; Tue, 24 Jan 2012 15:23: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 1RpiDb-0004s7-HV
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:23:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327418605!11812804!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5144 invoked from network); 24 Jan 2012 15:23:25 -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;
	24 Jan 2012 15:23:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10252897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 15:23: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; Tue, 24 Jan 2012 15:23: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
	1RpiDU-0000Sy-Pl; Tue, 24 Jan 2012 15:23:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpiDU-0003hz-JY;
	Tue, 24 Jan 2012 15:23:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.52460.459365.115952@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 15:23:24 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@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 v10 0/7] build upstream qemu and 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 ("[Xen-devel] [PATCH v10 0/7] build upstream qemu and seabios by default"):
> this is the tenth version of the patch series to introduce upstream qemu
> and seabios in the xen-unstable build system.

I have successfully build-tested and hence applied this series, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 15:23:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:23:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpiDd-0004sY-Df; Tue, 24 Jan 2012 15:23: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 1RpiDb-0004s7-HV
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:23:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327418605!11812804!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5144 invoked from network); 24 Jan 2012 15:23:25 -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;
	24 Jan 2012 15:23:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10252897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 15:23: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; Tue, 24 Jan 2012 15:23: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
	1RpiDU-0000Sy-Pl; Tue, 24 Jan 2012 15:23:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpiDU-0003hz-JY;
	Tue, 24 Jan 2012 15:23:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.52460.459365.115952@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 15:23:24 +0000
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@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 v10 0/7] build upstream qemu and 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 ("[Xen-devel] [PATCH v10 0/7] build upstream qemu and seabios by default"):
> this is the tenth version of the patch series to introduce upstream qemu
> and seabios in the xen-unstable build system.

I have successfully build-tested and hence applied this series, thanks.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 15:31:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1RpiKx-00058C-Az; Tue, 24 Jan 2012 15:31: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 1RpiKv-00057y-PE
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:31:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327419059!11661786!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19083 invoked from network); 24 Jan 2012 15:31:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 15:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10253406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 15: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; Tue, 24 Jan 2012 15:30: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
	1RpiKp-0000Vb-2y; Tue, 24 Jan 2012 15:30:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpiKp-0003og-0U;
	Tue, 24 Jan 2012 15:30:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.52915.2282.288349@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 15:30:59 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <8032df4baf729fc215de.1326798490@cosworth.uk.xensource.com>
References: <8032df4baf729fc215de.1326798490@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] libxl: remove _libxl_json_internal.h from
	libxl_json.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

Ian Campbell writes ("[PATCH] libxl: remove _libxl_json_internal.h from libxl_json.h"):
> libxl: remove _libxl_json_internal.h from libxl_json.h

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 Jan 24 15:31:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1RpiKx-00058C-Az; Tue, 24 Jan 2012 15:31: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 1RpiKv-00057y-PE
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:31:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327419059!11661786!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19083 invoked from network); 24 Jan 2012 15:31:00 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 15:31:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10253406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 15: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; Tue, 24 Jan 2012 15:30: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
	1RpiKp-0000Vb-2y; Tue, 24 Jan 2012 15:30:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpiKp-0003og-0U;
	Tue, 24 Jan 2012 15:30:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.52915.2282.288349@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 15:30:59 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <8032df4baf729fc215de.1326798490@cosworth.uk.xensource.com>
References: <8032df4baf729fc215de.1326798490@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] libxl: remove _libxl_json_internal.h from
	libxl_json.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

Ian Campbell writes ("[PATCH] libxl: remove _libxl_json_internal.h from libxl_json.h"):
> libxl: remove _libxl_json_internal.h from libxl_json.h

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 Jan 24 15:34:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1RpiNc-0005IB-4Z; Tue, 24 Jan 2012 15: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 1RpiNa-0005I3-T6
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:33:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327419224!12188425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25082 invoked from network); 24 Jan 2012 15:33:45 -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;
	24 Jan 2012 15:33:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10253467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 15: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; Tue, 24 Jan 2012 15:33: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
	1RpiNU-0000WX-JN; Tue, 24 Jan 2012 15:33:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpiNU-0003qA-IS;
	Tue, 24 Jan 2012 15:33:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.53080.559771.801496@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 15:33:44 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1326810832-11927-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1326810832-11927-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" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xl: Add missing trigger for the xl trigger
	cmd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 ("[PATCH] xl: Add missing trigger for the xl trigger cmd."):
> Add s3resume trigger in the usage of the xl trigger cmd.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 15:34:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1RpiNc-0005IB-4Z; Tue, 24 Jan 2012 15: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 1RpiNa-0005I3-T6
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:33:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1327419224!12188425!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25082 invoked from network); 24 Jan 2012 15:33:45 -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;
	24 Jan 2012 15:33:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10253467"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 15: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; Tue, 24 Jan 2012 15:33: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
	1RpiNU-0000WX-JN; Tue, 24 Jan 2012 15:33:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpiNU-0003qA-IS;
	Tue, 24 Jan 2012 15:33:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.53080.559771.801496@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 15:33:44 +0000
To: Jean Guyader <jean.guyader@eu.citrix.com>
In-Reply-To: <1326810832-11927-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1326810832-11927-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" <xen-devel@lists.xensource.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xl: Add missing trigger for the xl trigger
	cmd.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 ("[PATCH] xl: Add missing trigger for the xl trigger cmd."):
> Add s3resume trigger in the usage of the xl trigger cmd.
> 
> Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 15:37:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1RpiQv-0005Rp-Od; Tue, 24 Jan 2012 15:37:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpiQt-0005Ri-LG
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:37:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327419383!51557315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28490 invoked from network); 24 Jan 2012 15:36:23 -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;
	24 Jan 2012 15:36:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10253577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 15:37: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, 24 Jan 2012 15:37: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
	1RpiQp-0000Xu-5o; Tue, 24 Jan 2012 15:37:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpiQp-0003rp-4b;
	Tue, 24 Jan 2012 15:37:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.53287.107013.866188@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 15:37:11 +0000
To: Doug Magee <djmagee@mageenet.net>
In-Reply-To: <3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
	<3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
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 1 of 2] libxl_pci: rename is_assigned to
	is_pcidev_in_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

Doug Magee writes ("[PATCH 1 of 2] libxl_pci: rename is_assigned to is_pcidev_in_array"):
> All this function does is check to see if a device is in an array of pcidevs passed by the caller.  The function name can be misleading if ever used to check against a list of devices other than those assigned to a domain.

This is a good change and I have committed it, but I think it would be
good to change the name of the formal parameter to is_pcidev_in_array,
too, to "array" or "devices" or "haystack" or something.  And a
corresponding change to num_assigned.

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 Jan 24 15:37:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1RpiQv-0005Rp-Od; Tue, 24 Jan 2012 15:37:17 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpiQt-0005Ri-LG
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:37:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327419383!51557315!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28490 invoked from network); 24 Jan 2012 15:36:23 -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;
	24 Jan 2012 15:36:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10253577"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 15:37: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, 24 Jan 2012 15:37: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
	1RpiQp-0000Xu-5o; Tue, 24 Jan 2012 15:37:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpiQp-0003rp-4b;
	Tue, 24 Jan 2012 15:37:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.53287.107013.866188@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 15:37:11 +0000
To: Doug Magee <djmagee@mageenet.net>
In-Reply-To: <3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
References: <patchbomb.1326813905@mnetdjm4.mageenet.host>
	<3becc16526930a5bc6a3.1326813906@mnetdjm4.mageenet.host>
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 1 of 2] libxl_pci: rename is_assigned to
	is_pcidev_in_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

Doug Magee writes ("[PATCH 1 of 2] libxl_pci: rename is_assigned to is_pcidev_in_array"):
> All this function does is check to see if a device is in an array of pcidevs passed by the caller.  The function name can be misleading if ever used to check against a list of devices other than those assigned to a domain.

This is a good change and I have committed it, but I think it would be
good to change the name of the formal parameter to is_pcidev_in_array,
too, to "array" or "devices" or "haystack" or something.  And a
corresponding change to num_assigned.

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 Jan 24 15:40:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpiTc-0005dx-18; Tue, 24 Jan 2012 15:40:04 +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 1RpiTZ-0005bk-5L
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:40:02 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327419594!10484593!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17466 invoked from network); 24 Jan 2012 15:39:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 15:39:54 -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 q0OFdoiq009330
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:39:50 -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 q0OFdlbl004021; Tue, 24 Jan 2012 10:39:48 -0500
Message-ID: <4F1ED0C3.7030008@redhat.com>
Date: Tue, 24 Jan 2012 17:39:47 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com> <4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
	<alpine.DEB.2.00.1201241158240.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201241158240.3196@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 02:00 PM, Stefano Stabellini wrote:
> On Tue, 24 Jan 2012, Avi Kivity wrote:
> > On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> > > >>>
> > > >>> But viewing RAM as just another device, having Xen only restore a
> > > >>> subset of
> > > >>> devices should be a reasonable thing to do moving forward.
> > >
> > > I don't think modeling device memory (i.e. vga vram) as something
> > > independent from the device (vga) is a good idea.  Because it isn't.
> > 
> > Right.  We should have VMSTATE_RAM() to express the dependency.
>
> So if I understand correctly you are planning on removing the call to
> vmstate_register_ram_global in hw/vga.c?

I can't say I'm planning to do so, but that's the direction I think we
need to go.

> In that case it might be better if I wait for your "VMSTATE_RAM" patch
> before I can send a new patch to save only non-RAM devices, because I
> guess they will clash with one another.

I don't understand what sense a patch to save non-RAM devices makes (or
even, what non-RAM devices are).

We have a special case here where Xen manages the RAM even though qemu
thinks it does.  IMO an if (xen) is the best way to express this
specialness.

-- 
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 Tue Jan 24 15:40:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:40:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpiTc-0005dx-18; Tue, 24 Jan 2012 15:40:04 +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 1RpiTZ-0005bk-5L
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:40:02 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327419594!10484593!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17466 invoked from network); 24 Jan 2012 15:39:54 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 15:39:54 -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 q0OFdoiq009330
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:39:50 -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 q0OFdlbl004021; Tue, 24 Jan 2012 10:39:48 -0500
Message-ID: <4F1ED0C3.7030008@redhat.com>
Date: Tue, 24 Jan 2012 17:39:47 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com> <4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
	<alpine.DEB.2.00.1201241158240.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201241158240.3196@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 02:00 PM, Stefano Stabellini wrote:
> On Tue, 24 Jan 2012, Avi Kivity wrote:
> > On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
> > > >>>
> > > >>> But viewing RAM as just another device, having Xen only restore a
> > > >>> subset of
> > > >>> devices should be a reasonable thing to do moving forward.
> > >
> > > I don't think modeling device memory (i.e. vga vram) as something
> > > independent from the device (vga) is a good idea.  Because it isn't.
> > 
> > Right.  We should have VMSTATE_RAM() to express the dependency.
>
> So if I understand correctly you are planning on removing the call to
> vmstate_register_ram_global in hw/vga.c?

I can't say I'm planning to do so, but that's the direction I think we
need to go.

> In that case it might be better if I wait for your "VMSTATE_RAM" patch
> before I can send a new patch to save only non-RAM devices, because I
> guess they will clash with one another.

I don't understand what sense a patch to save non-RAM devices makes (or
even, what non-RAM devices are).

We have a special case here where Xen manages the RAM even though qemu
thinks it does.  IMO an if (xen) is the best way to express this
specialness.

-- 
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 Tue Jan 24 15:43:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpiWc-0005x7-K2; Tue, 24 Jan 2012 15:43:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RpiWb-0005wz-On
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:43:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327419728!58236291!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12577 invoked from network); 24 Jan 2012 15:42:09 -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;
	24 Jan 2012 15:42:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="21225811"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 10:43:06 -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, 24 Jan 2012
	10:43:06 -0500
Message-ID: <4F1ED189.70401@citrix.com>
Date: Tue, 24 Jan 2012 15:43:05 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
In-Reply-To: <4F19A577020000780006E115@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/12 16:33, Jan Beulich wrote:
> This addresses a number of problems in msixtbl_{read,write}():
> - address alignment was not checked, allowing for memory corruption in
>   the hypervisor (write case) or returning of hypervisor private data
>   to the guest (read case)
> - the interrupt mask bit was permitted to be written by the guest
>   (while Xen's interrupt flow control routines need to control it)
> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>   numbers (making it unobvious why they have these values, and making
>   the latter non-portable)
> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>   non-zero table offset); this was also affecting host MSI-X code
> - struct msixtbl_entry's table_flags[] was one element larger than
>   necessary due to improper open-coding of BITS_TO_LONGS()
> - msixtbl_read() unconditionally accessed the physical table, even
>   though the data was only needed in a quarter of all cases
> - various calculations were done unnecessarily for both of the rather
>   distinct code paths in msixtbl_read()
>
> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
> chosen to be 3.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Tested by backport to XenServer 6.0 (Xen-4.1.1)  The only conflicts were
with the context around adding the two new header files, and <xen/pfn.h>
which is a new header file.

Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -165,7 +165,7 @@ struct msixtbl_entry
>      struct pci_dev *pdev;
>      unsigned long gtable;       /* gpa of msix table */
>      unsigned long table_len;
> -    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + 1];
> +    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
>  #define MAX_MSIX_ACC_ENTRIES 3
>      struct { 
>          uint32_t msi_ad[3];	/* Shadow of address low, high and data */
> @@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin
>  static void __iomem *msixtbl_addr_to_virt(
>      struct msixtbl_entry *entry, unsigned long addr)
>  {
> -    int idx, nr_page;
> +    unsigned int idx, nr_page;
>  
> -    if ( !entry )
> +    if ( !entry || !entry->pdev )
>          return NULL;
>  
>      nr_page = (addr >> PAGE_SHIFT) -
>                (entry->gtable >> PAGE_SHIFT);
>  
> -    if ( !entry->pdev )
> -        return NULL;
> -
>      idx = entry->pdev->msix_table_idx[nr_page];
>      if ( !idx )
>          return NULL;
> @@ -215,37 +212,34 @@ static int msixtbl_read(
>      struct vcpu *v, unsigned long address,
>      unsigned long len, unsigned long *pval)
>  {
> -    unsigned long offset, val;
> +    unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
> -    virt = msixtbl_addr_to_virt(entry, address);
> -    if ( !virt )
> -        goto out;
> -
> -    nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
>      offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
> -    if ( nr_entry >= MAX_MSIX_ACC_ENTRIES && 
> -         offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
> -        goto out;
>  
> -    val = readl(virt);
>      if ( offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
>      {
> +        nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> +        if ( nr_entry >= MAX_MSIX_ACC_ENTRIES )
> +            goto out;
>          index = offset / sizeof(uint32_t);
>          *pval = entry->gentries[nr_entry].msi_ad[index];
>      }
>      else 
>      {
> -        *pval = val;
> +        virt = msixtbl_addr_to_virt(entry, address);
> +        if ( !virt )
> +            goto out;
> +        *pval = readl(virt);
>      }
>      
>      r = X86EMUL_OKAY;
> @@ -260,13 +254,13 @@ static int msixtbl_write(struct vcpu *v,
>      unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
>      nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>      if ( !virt )
>          goto out;
>  
> +    /* Do not allow the mask bit to be changed. */
> +#if 0 /* XXX
> +       * As the mask bit is the only defined bit in the word, and as the
> +       * host MSI-X code doesn't preserve the other bits anyway, doing
> +       * this is pointless. So for now just discard the write (also
> +       * saving us from having to determine the matching irq_desc).
> +       */
> +    spin_lock_irqsave(&desc->lock, flags);
> +    orig = readl(virt);
> +    val &= ~PCI_MSIX_VECTOR_BITMASK;
> +    val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
> -    r = X86EMUL_OKAY;
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +#endif
>  
> +    r = X86EMUL_OKAY;
>  out:
>      rcu_read_unlock(&msixtbl_rcu_lock);
>      return r;
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -122,12 +122,6 @@ int msi_free_irq(struct msi_desc *entry)
>   */
>  #define NR_HP_RESERVED_VECTORS 	20
>  
> -#define PCI_MSIX_ENTRY_SIZE			16
> -#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> -#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> -#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> -#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> -
>  #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>  #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>  #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -11,6 +11,8 @@
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
>  #include <xen/irq.h>
> +#include <xen/pci_regs.h>
> +#include <xen/pfn.h>
>  #include <asm/pci.h>
>  
>  /*
> @@ -30,8 +32,10 @@
>  #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
>  #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
>  
> -#define MAX_MSIX_TABLE_ENTRIES  2048
> -#define MAX_MSIX_TABLE_PAGES    8
> +#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
> +#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
> +                                       PCI_MSIX_ENTRY_SIZE + \
> +                                       (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))
>  struct pci_dev_info {
>      bool_t is_extfn;
>      bool_t is_virtfn;
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -305,6 +305,12 @@
>  #define PCI_MSIX_PBA		8
>  #define  PCI_MSIX_BIRMASK	(7 << 0)
>  
> +#define PCI_MSIX_ENTRY_SIZE			16
> +#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> +#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> +#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> +#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> +
>  #define PCI_MSIX_VECTOR_BITMASK	(1 << 0)
>  
>  /* CompactPCI Hotswap Register */
>
>

-- 
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 Jan 24 15:43:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:43:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpiWc-0005x7-K2; Tue, 24 Jan 2012 15:43:10 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RpiWb-0005wz-On
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:43:10 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327419728!58236291!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12577 invoked from network); 24 Jan 2012 15:42:09 -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;
	24 Jan 2012 15:42:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="21225811"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 10:43:06 -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, 24 Jan 2012
	10:43:06 -0500
Message-ID: <4F1ED189.70401@citrix.com>
Date: Tue, 24 Jan 2012 15:43:05 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
In-Reply-To: <4F19A577020000780006E115@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 20/01/12 16:33, Jan Beulich wrote:
> This addresses a number of problems in msixtbl_{read,write}():
> - address alignment was not checked, allowing for memory corruption in
>   the hypervisor (write case) or returning of hypervisor private data
>   to the guest (read case)
> - the interrupt mask bit was permitted to be written by the guest
>   (while Xen's interrupt flow control routines need to control it)
> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>   numbers (making it unobvious why they have these values, and making
>   the latter non-portable)
> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>   non-zero table offset); this was also affecting host MSI-X code
> - struct msixtbl_entry's table_flags[] was one element larger than
>   necessary due to improper open-coding of BITS_TO_LONGS()
> - msixtbl_read() unconditionally accessed the physical table, even
>   though the data was only needed in a quarter of all cases
> - various calculations were done unnecessarily for both of the rather
>   distinct code paths in msixtbl_read()
>
> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
> chosen to be 3.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Tested by backport to XenServer 6.0 (Xen-4.1.1)  The only conflicts were
with the context around adding the two new header files, and <xen/pfn.h>
which is a new header file.

Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -165,7 +165,7 @@ struct msixtbl_entry
>      struct pci_dev *pdev;
>      unsigned long gtable;       /* gpa of msix table */
>      unsigned long table_len;
> -    unsigned long table_flags[MAX_MSIX_TABLE_ENTRIES / BITS_PER_LONG + 1];
> +    unsigned long table_flags[BITS_TO_LONGS(MAX_MSIX_TABLE_ENTRIES)];
>  #define MAX_MSIX_ACC_ENTRIES 3
>      struct { 
>          uint32_t msi_ad[3];	/* Shadow of address low, high and data */
> @@ -192,17 +192,14 @@ static struct msixtbl_entry *msixtbl_fin
>  static void __iomem *msixtbl_addr_to_virt(
>      struct msixtbl_entry *entry, unsigned long addr)
>  {
> -    int idx, nr_page;
> +    unsigned int idx, nr_page;
>  
> -    if ( !entry )
> +    if ( !entry || !entry->pdev )
>          return NULL;
>  
>      nr_page = (addr >> PAGE_SHIFT) -
>                (entry->gtable >> PAGE_SHIFT);
>  
> -    if ( !entry->pdev )
> -        return NULL;
> -
>      idx = entry->pdev->msix_table_idx[nr_page];
>      if ( !idx )
>          return NULL;
> @@ -215,37 +212,34 @@ static int msixtbl_read(
>      struct vcpu *v, unsigned long address,
>      unsigned long len, unsigned long *pval)
>  {
> -    unsigned long offset, val;
> +    unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
> -    virt = msixtbl_addr_to_virt(entry, address);
> -    if ( !virt )
> -        goto out;
> -
> -    nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
>      offset = address & (PCI_MSIX_ENTRY_SIZE - 1);
> -    if ( nr_entry >= MAX_MSIX_ACC_ENTRIES && 
> -         offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
> -        goto out;
>  
> -    val = readl(virt);
>      if ( offset != PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET )
>      {
> +        nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> +        if ( nr_entry >= MAX_MSIX_ACC_ENTRIES )
> +            goto out;
>          index = offset / sizeof(uint32_t);
>          *pval = entry->gentries[nr_entry].msi_ad[index];
>      }
>      else 
>      {
> -        *pval = val;
> +        virt = msixtbl_addr_to_virt(entry, address);
> +        if ( !virt )
> +            goto out;
> +        *pval = readl(virt);
>      }
>      
>      r = X86EMUL_OKAY;
> @@ -260,13 +254,13 @@ static int msixtbl_write(struct vcpu *v,
>      unsigned long offset;
>      struct msixtbl_entry *entry;
>      void *virt;
> -    int nr_entry, index;
> +    unsigned int nr_entry, index;
>      int r = X86EMUL_UNHANDLEABLE;
>  
> -    rcu_read_lock(&msixtbl_rcu_lock);
> +    if ( len != 4 || (address & 3) )
> +        return r;
>  
> -    if ( len != 4 )
> -        goto out;
> +    rcu_read_lock(&msixtbl_rcu_lock);
>  
>      entry = msixtbl_find_entry(v, address);
>      nr_entry = (address - entry->gtable) / PCI_MSIX_ENTRY_SIZE;
> @@ -291,9 +285,22 @@ static int msixtbl_write(struct vcpu *v,
>      if ( !virt )
>          goto out;
>  
> +    /* Do not allow the mask bit to be changed. */
> +#if 0 /* XXX
> +       * As the mask bit is the only defined bit in the word, and as the
> +       * host MSI-X code doesn't preserve the other bits anyway, doing
> +       * this is pointless. So for now just discard the write (also
> +       * saving us from having to determine the matching irq_desc).
> +       */
> +    spin_lock_irqsave(&desc->lock, flags);
> +    orig = readl(virt);
> +    val &= ~PCI_MSIX_VECTOR_BITMASK;
> +    val |= orig & PCI_MSIX_VECTOR_BITMASK;
>      writel(val, virt);
> -    r = X86EMUL_OKAY;
> +    spin_unlock_irqrestore(&desc->lock, flags);
> +#endif
>  
> +    r = X86EMUL_OKAY;
>  out:
>      rcu_read_unlock(&msixtbl_rcu_lock);
>      return r;
> --- a/xen/include/asm-x86/msi.h
> +++ b/xen/include/asm-x86/msi.h
> @@ -122,12 +122,6 @@ int msi_free_irq(struct msi_desc *entry)
>   */
>  #define NR_HP_RESERVED_VECTORS 	20
>  
> -#define PCI_MSIX_ENTRY_SIZE			16
> -#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> -#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> -#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> -#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> -
>  #define msi_control_reg(base)		(base + PCI_MSI_FLAGS)
>  #define msi_lower_address_reg(base)	(base + PCI_MSI_ADDRESS_LO)
>  #define msi_upper_address_reg(base)	(base + PCI_MSI_ADDRESS_HI)
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -11,6 +11,8 @@
>  #include <xen/list.h>
>  #include <xen/spinlock.h>
>  #include <xen/irq.h>
> +#include <xen/pci_regs.h>
> +#include <xen/pfn.h>
>  #include <asm/pci.h>
>  
>  /*
> @@ -30,8 +32,10 @@
>  #define PCI_BDF(b,d,f)  ((((b) & 0xff) << 8) | PCI_DEVFN(d,f))
>  #define PCI_BDF2(b,df)  ((((b) & 0xff) << 8) | ((df) & 0xff))
>  
> -#define MAX_MSIX_TABLE_ENTRIES  2048
> -#define MAX_MSIX_TABLE_PAGES    8
> +#define MAX_MSIX_TABLE_ENTRIES  (PCI_MSIX_FLAGS_QSIZE + 1)
> +#define MAX_MSIX_TABLE_PAGES    PFN_UP(MAX_MSIX_TABLE_ENTRIES * \
> +                                       PCI_MSIX_ENTRY_SIZE + \
> +                                       (~PCI_MSIX_BIRMASK & (PAGE_SIZE - 1)))
>  struct pci_dev_info {
>      bool_t is_extfn;
>      bool_t is_virtfn;
> --- a/xen/include/xen/pci_regs.h
> +++ b/xen/include/xen/pci_regs.h
> @@ -305,6 +305,12 @@
>  #define PCI_MSIX_PBA		8
>  #define  PCI_MSIX_BIRMASK	(7 << 0)
>  
> +#define PCI_MSIX_ENTRY_SIZE			16
> +#define  PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET	0
> +#define  PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET	4
> +#define  PCI_MSIX_ENTRY_DATA_OFFSET		8
> +#define  PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET	12
> +
>  #define PCI_MSIX_VECTOR_BITMASK	(1 << 0)
>  
>  /* CompactPCI Hotswap Register */
>
>

-- 
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 Jan 24 15:43:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:43:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpiX4-00060h-7r; Tue, 24 Jan 2012 15:43:38 +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 1RpiX3-000605-53
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:43:37 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327419810!10032874!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29954 invoked from network); 24 Jan 2012 15:43:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 15:43:30 -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 q0OFhRNc010387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:43:27 -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 q0OFhOuG005144; Tue, 24 Jan 2012 10:43:25 -0500
Message-ID: <4F1ED19C.6060507@redhat.com>
Date: Tue, 24 Jan 2012 17:43:24 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
	<4F1EAFC1.6040204@codemonkey.ws>
In-Reply-To: <4F1EAFC1.6040204@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 03:18 PM, Anthony Liguori wrote:
> On 01/24/2012 05:13 AM, Avi Kivity wrote:
>> On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
>>>>>>
>>>>>> But viewing RAM as just another device, having Xen only restore a
>>>>>> subset of
>>>>>> devices should be a reasonable thing to do moving forward.
>>>
>>> I don't think modeling device memory (i.e. vga vram) as something
>>> independent from the device (vga) is a good idea.  Because it isn't.
>>
>> Right.  We should have VMSTATE_RAM() to express the dependency.
>
> No, VMSTATE has nothign to do with reset.

It's so that the device's post_load happens after the RAM was loaded.

>
> Ram should be a device and then you can hook up ram through the
> composition tree.

I think that's too heavy a hammer.  Think about things like ivshmem. 
Does it really need to be a composite device?  If we keep going in this
direction the amount of know how needed to write a device for qemu will
be overwhelming.

RAM is a large array of bits.  We model an 32-bit register with a
uint32_t, memory_region_init_io(), and some vmstate.  We should be able
to do the same thing for RAM.

>
> But reset is going to propagate preorder, not postorder, so this isn't
> going to help anyway.
>
> Postorder initialization doesn't make a whole lot of sense when you
> think about the semantics of it.

-- 
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 Tue Jan 24 15:43:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:43:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpiX4-00060h-7r; Tue, 24 Jan 2012 15:43:38 +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 1RpiX3-000605-53
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:43:37 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327419810!10032874!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29954 invoked from network); 24 Jan 2012 15:43:30 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 15:43:30 -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 q0OFhRNc010387
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:43:27 -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 q0OFhOuG005144; Tue, 24 Jan 2012 10:43:25 -0500
Message-ID: <4F1ED19C.6060507@redhat.com>
Date: Tue, 24 Jan 2012 17:43:24 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1E923D.2090208@redhat.com>
	<4F1EAFC1.6040204@codemonkey.ws>
In-Reply-To: <4F1EAFC1.6040204@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 03:18 PM, Anthony Liguori wrote:
> On 01/24/2012 05:13 AM, Avi Kivity wrote:
>> On 01/24/2012 12:21 PM, Gerd Hoffmann wrote:
>>>>>>
>>>>>> But viewing RAM as just another device, having Xen only restore a
>>>>>> subset of
>>>>>> devices should be a reasonable thing to do moving forward.
>>>
>>> I don't think modeling device memory (i.e. vga vram) as something
>>> independent from the device (vga) is a good idea.  Because it isn't.
>>
>> Right.  We should have VMSTATE_RAM() to express the dependency.
>
> No, VMSTATE has nothign to do with reset.

It's so that the device's post_load happens after the RAM was loaded.

>
> Ram should be a device and then you can hook up ram through the
> composition tree.

I think that's too heavy a hammer.  Think about things like ivshmem. 
Does it really need to be a composite device?  If we keep going in this
direction the amount of know how needed to write a device for qemu will
be overwhelming.

RAM is a large array of bits.  We model an 32-bit register with a
uint32_t, memory_region_init_io(), and some vmstate.  We should be able
to do the same thing for RAM.

>
> But reset is going to propagate preorder, not postorder, so this isn't
> going to help anyway.
>
> Postorder initialization doesn't make a whole lot of sense when you
> think about the semantics of it.

-- 
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 Tue Jan 24 15:47:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpiae-0006Pa-0u; Tue, 24 Jan 2012 15:47: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 1Rpiab-0006P4-NW
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:47:17 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327420031!12177810!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14286 invoked from network); 24 Jan 2012 15:47:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	24 Jan 2012 15:47:11 -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 q0OFl8HH011684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:47:08 -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 q0OFl5Es016787; Tue, 24 Jan 2012 10:47:06 -0500
Message-ID: <4F1ED278.3040707@redhat.com>
Date: Tue, 24 Jan 2012 17:47:04 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1EB12E.5080802@codemonkey.ws>
In-Reply-To: <4F1EB12E.5080802@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 03:25 PM, Anthony Liguori wrote:
>
>>
>>>> To my understanding, QXL will break identically on Xen for the same
>>>> reason: the reset handler assumes it can deal with the VRAM as it
>>>> likes.
>>
>> Yes.  Some data structures for host<->  guest communication are living
>> in device memory, and a reset initializes these.
>
> This should be done by firmware or system software.  

It should be done in the way the device spec says it does.  What does
the qxl spec says?  If it's lacking, we need to fill it up from existing
practice.

> Devices don't initialize memory with data structures on power up.  The
> first problem with doing this is that it assumes a reset order which
> would lengthen the quiescing process.  The second problem is that this
> would require fairly sophisticated logic that could just as well live
> in firmware.

If it's in device firmware, there's no way to tell.  Nothing prevents
the device from clearing its on-board memory during reset.

>
> The advantage of not enabling a device to behave like this is it lets
> us do a much simpler reset model.  To model this properly, we would
> have to support multiple reset propagation hooks (at least a preorder
> and postorder hook).  This adds a fair amount of complication for not
> a lot of benefit (the only benefit is moving firmware logic into QEMU
> which is really a downside :-)).
>

You're arguing about changing a device so it could fit qemu better.  It
should be the other way around.  Granted this is a paravirt device so we
have more leeway, but still qxl is out there and we can't change it.

-- 
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 Tue Jan 24 15:47:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15:47:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpiae-0006Pa-0u; Tue, 24 Jan 2012 15:47: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 1Rpiab-0006P4-NW
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:47:17 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327420031!12177810!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14286 invoked from network); 24 Jan 2012 15:47:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-11.tower-182.messagelabs.com with SMTP;
	24 Jan 2012 15:47:11 -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 q0OFl8HH011684
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:47:08 -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 q0OFl5Es016787; Tue, 24 Jan 2012 10:47:06 -0500
Message-ID: <4F1ED278.3040707@redhat.com>
Date: Tue, 24 Jan 2012 17:47:04 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>	<4F19AB66.8060901@siemens.com>	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>	<4F1D4974.4090003@siemens.com>	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>	<4F1D4E43.7000501@siemens.com>	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>	<4F1D80BA.1040504@siemens.com>	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>	<4F1D9546.4040801@siemens.com>	<4F1D9649.1000102@codemonkey.ws>
	<4F1D995A.4020604@siemens.com>	<4F1D9A8E.1080102@codemonkey.ws>
	<4F1E8635.2020608@redhat.com> <4F1EB12E.5080802@codemonkey.ws>
In-Reply-To: <4F1EB12E.5080802@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 03:25 PM, Anthony Liguori wrote:
>
>>
>>>> To my understanding, QXL will break identically on Xen for the same
>>>> reason: the reset handler assumes it can deal with the VRAM as it
>>>> likes.
>>
>> Yes.  Some data structures for host<->  guest communication are living
>> in device memory, and a reset initializes these.
>
> This should be done by firmware or system software.  

It should be done in the way the device spec says it does.  What does
the qxl spec says?  If it's lacking, we need to fill it up from existing
practice.

> Devices don't initialize memory with data structures on power up.  The
> first problem with doing this is that it assumes a reset order which
> would lengthen the quiescing process.  The second problem is that this
> would require fairly sophisticated logic that could just as well live
> in firmware.

If it's in device firmware, there's no way to tell.  Nothing prevents
the device from clearing its on-board memory during reset.

>
> The advantage of not enabling a device to behave like this is it lets
> us do a much simpler reset model.  To model this properly, we would
> have to support multiple reset propagation hooks (at least a preorder
> and postorder hook).  This adds a fair amount of complication for not
> a lot of benefit (the only benefit is moving firmware logic into QEMU
> which is really a downside :-)).
>

You're arguing about changing a device so it could fit qemu better.  It
should be the other way around.  Granted this is a paravirt device so we
have more leeway, but still qxl is out there and we can't change it.

-- 
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 Tue Jan 24 15:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1Rpibg-0006Vn-Fw; Tue, 24 Jan 2012 15:48:24 +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 1Rpibf-0006V6-Ae
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:48:23 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327420096!11775709!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22815 invoked from network); 24 Jan 2012 15:48:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	24 Jan 2012 15:48:17 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0OFmDd3029045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:48:13 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OFmAKQ010298; Tue, 24 Jan 2012 10:48:11 -0500
Message-ID: <4F1ED2BA.5050505@redhat.com>
Date: Tue, 24 Jan 2012 17:48:10 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
	<4F1E96BA.40801@redhat.com> <4F1E99B6.7010709@redhat.com>
In-Reply-To: <4F1E99B6.7010709@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 01:44 PM, Paolo Bonzini wrote:
> On 01/24/2012 12:32 PM, Avi Kivity wrote:
>>> >  Clearing the screen should only write to the RAM at 0xB8000 (and
>>> >  perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
>>> >  option ROM cannot even assume that the main BIOS knows about the
>>> VESA
>>> >  framebuffer, can it?
>> Yes, but why should anything else be needed?
>>
>> When you switch to a graphics mode, clear as much of the framebuffer as
>> you need.
>
> Based on the comments, Windows apparently disagrees. :)

Based on the testing, it does not.

-- 
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 Tue Jan 24 15:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1Rpibg-0006Vn-Fw; Tue, 24 Jan 2012 15:48:24 +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 1Rpibf-0006V6-Ae
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:48:23 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327420096!11775709!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22815 invoked from network); 24 Jan 2012 15:48:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-13.tower-216.messagelabs.com with SMTP;
	24 Jan 2012 15:48:17 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0OFmDd3029045
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:48:13 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OFmAKQ010298; Tue, 24 Jan 2012 10:48:11 -0500
Message-ID: <4F1ED2BA.5050505@redhat.com>
Date: Tue, 24 Jan 2012 17:48:10 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Paolo Bonzini <pbonzini@redhat.com>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1E959F.4060001@redhat.com>
	<4F1E96BA.40801@redhat.com> <4F1E99B6.7010709@redhat.com>
In-Reply-To: <4F1E99B6.7010709@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 01:44 PM, Paolo Bonzini wrote:
> On 01/24/2012 12:32 PM, Avi Kivity wrote:
>>> >  Clearing the screen should only write to the RAM at 0xB8000 (and
>>> >  perhaps 0xA0000 since IIRC it's where text-mode fonts lie).  The
>>> >  option ROM cannot even assume that the main BIOS knows about the
>>> VESA
>>> >  framebuffer, can it?
>> Yes, but why should anything else be needed?
>>
>> When you switch to a graphics mode, clear as much of the framebuffer as
>> you need.
>
> Based on the comments, Windows apparently disagrees. :)

Based on the testing, it does not.

-- 
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 Tue Jan 24 15:57:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1Rpik6-0007Un-An; Tue, 24 Jan 2012 15:57:06 +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 1Rpik4-0007Tg-MQ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:57:04 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327420617!3152385!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31120 invoked from network); 24 Jan 2012 15:56:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 15:56:58 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0OFuoXh014715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:56:51 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OFumYD013296; Tue, 24 Jan 2012 10:56:49 -0500
Message-ID: <4F1ED4BF.20505@redhat.com>
Date: Tue, 24 Jan 2012 17:56:47 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1EAEC7.5050304@codemonkey.ws>
In-Reply-To: <4F1EAEC7.5050304@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 03:14 PM, Anthony Liguori wrote:
> On 01/24/2012 05:10 AM, Avi Kivity wrote:
>> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>>> Generally speaking, RAM is an independent device in most useful cases.
>>
>> Can you give examples?  Do you mean a subdevice with composition, or a
>> really independent device?
>
> I expect we'll have one Ram device.  It's size will be configurable. 
> One Ram device will hang off of the machine which would be the main ram.

We'll also have a hotpluggable variant which talks to some GPIOs.  A
motherboard may support multiple slots with such devices.

> A video card would have a Ram device via composition.

IMO, overkill.

>
> The important consideration about reset is how it propagates.  My
> expectation is that we'll propagate reset through the composition tree
> in a preorder transversal.  That means in the VGA device reset
> function, it's child device (Ram) has not been reset yet.

Doesn't depth first make more sense?  A bus is considered reset after
all devices in the bus have been reset.


>
>>> We really should view RAM as just another device so I don't like the
>>> idea of propagating a global concept of "when RAM is restored" because
>>> that treats it specially compared to other devices.
>>
>> Agree.  In fact the first step has been taken as now creating a RAM
>> region with memory_region_init_ram() doesn't register it for migration.
>> The next step would be a VMSTATE_RAM() to make it part of the containing
>> device.
>
> That's not necessary (or wise).
>
> Let's not confuse a Ram device with a MemoryRegion.  They are separate
> things and should be treated as separate things.  I thought we
> discussed that MemoryRegions are stateless (or at least, there state
> is all derived) and don't need to be serialized?

Well, the actual bits in memory are state.  All other attributes are
indeed derived.

I just think that making any device that has a bit of RAM a composed
device is overkill.  What do we gain from it?  The cost is not trivial.

-- 
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 Tue Jan 24 15:57:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1Rpik6-0007Un-An; Tue, 24 Jan 2012 15:57:06 +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 1Rpik4-0007Tg-MQ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:57:04 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327420617!3152385!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTEyNTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31120 invoked from network); 24 Jan 2012 15:56:58 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 15:56:58 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0OFuoXh014715
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 10:56:51 -0500
Received: from balrog.usersys.redhat.com (dhcp-4-24.tlv.redhat.com
	[10.35.4.24])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0OFumYD013296; Tue, 24 Jan 2012 10:56:49 -0500
Message-ID: <4F1ED4BF.20505@redhat.com>
Date: Tue, 24 Jan 2012 17:56:47 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1EAEC7.5050304@codemonkey.ws>
In-Reply-To: <4F1EAEC7.5050304@codemonkey.ws>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 03:14 PM, Anthony Liguori wrote:
> On 01/24/2012 05:10 AM, Avi Kivity wrote:
>> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>>> Generally speaking, RAM is an independent device in most useful cases.
>>
>> Can you give examples?  Do you mean a subdevice with composition, or a
>> really independent device?
>
> I expect we'll have one Ram device.  It's size will be configurable. 
> One Ram device will hang off of the machine which would be the main ram.

We'll also have a hotpluggable variant which talks to some GPIOs.  A
motherboard may support multiple slots with such devices.

> A video card would have a Ram device via composition.

IMO, overkill.

>
> The important consideration about reset is how it propagates.  My
> expectation is that we'll propagate reset through the composition tree
> in a preorder transversal.  That means in the VGA device reset
> function, it's child device (Ram) has not been reset yet.

Doesn't depth first make more sense?  A bus is considered reset after
all devices in the bus have been reset.


>
>>> We really should view RAM as just another device so I don't like the
>>> idea of propagating a global concept of "when RAM is restored" because
>>> that treats it specially compared to other devices.
>>
>> Agree.  In fact the first step has been taken as now creating a RAM
>> region with memory_region_init_ram() doesn't register it for migration.
>> The next step would be a VMSTATE_RAM() to make it part of the containing
>> device.
>
> That's not necessary (or wise).
>
> Let's not confuse a Ram device with a MemoryRegion.  They are separate
> things and should be treated as separate things.  I thought we
> discussed that MemoryRegions are stateless (or at least, there state
> is all derived) and don't need to be serialized?

Well, the actual bits in memory are state.  All other attributes are
indeed derived.

I just think that making any device that has a bit of RAM a composed
device is overkill.  What do we gain from it?  The cost is not trivial.

-- 
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 Tue Jan 24 15:57:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1Rpik3-0007US-UN; Tue, 24 Jan 2012 15:57:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpik2-0007T2-Q8
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:57:03 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327420616!12357969!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16742 invoked from network); 24 Jan 2012 15:56:56 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 15:56:56 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C883621902
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 10:56:51 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Tue, 24 Jan 2012 10:56:51 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	vvW1tiB+uco/qWUMDlr5JYHIQUk=; b=c2tpFemxUEGOWpJeqbctp939LrAiv603
	//O9ZtZufclA7nxO2NVl9qbpLePY+OXSskusHBTr5PdFUPS4ZjsYylusMSCy+OnZ
	IzZUJ4RNr/Ypj82iorEKtN33ZNvkc9uCpl7LpyZiDekOLtMqd8xXb5U/oOAps0P3
	qtyo0jN4dUk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=vvW1tiB+uco/qWUMDlr5JYHIQUk=; b=
	gqV6e2JoSVgg1ervstDs5KMT3iUp5j9cG8jpL2htrCF2Fzf+J9kAlArfg61s8u5e
	6Ixdqc/cyOzhKkV7wyebJDSkqX/S9NJ+5hAkAKPTH6jcY8bW4lJzB4Qbc5GH8JuC
	LfBXlSdGScsLhEALkNZfaYrWVkPw10UHS/W+jc4xDOs=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 9754AA000A6; Tue, 24 Jan 2012 10:56:51 -0500 (EST)
Message-Id: <1327420611.19936.140661027415609@webmail.messagingengine.com>
X-Sasl-Enc: m8Xh3J8pDFdeeCon/7GZkCxy3OZCGqoo6PRakizR2Utb 1327420611
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327415184.24561.182.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Jan 2012 07:56:51 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

> Does "ifconfig -a" in dom0 show a vifX.Y device for the domain? You previous xenstore log
> suggests it should be there but lets double check.

edit /etc/xen/scripts/vif-bridge
	#!/bin/bash
+       exec 1>>/tmp/hotplog.log
+       exec 2>&1
+       echo "`date`: Running $0 $*"

xl create test.cfg


ifconfig -a
brINT     Link encap:Ethernet  HWaddr 00:52:35:11:26:3B
          inet addr:192.168.1.10  Bcast:192.168.1.255 
          Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:444732 errors:0 dropped:0 overruns:0 frame:0
          TX packets:287814 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1096020765 (1045.2 Mb)  TX bytes:95900515 (91.4 Mb)

eth0      Link encap:Ethernet  HWaddr 00:52:35:11:26:3B
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:840591 errors:0 dropped:0 overruns:0 frame:0
          TX packets:376159 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1132351110 (1079.8 Mb)  TX bytes:100533253 (95.8 Mb)
          Interrupt:48

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3922 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3922 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:252238 (246.3 Kb)  TX bytes:252238 (246.3 Kb)

vif7.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

xl network-list test
 Idx BE Mac Addr.         handle state evt-ch   tx-/rx-ring-ref BE-path
 0   0  00:16:3e:12:34:01      0     4     15   768/769        
 /local/domain/0/backend/vif/7/0


> Do you get anything in the logs under /var/log/xen?

Just this after the Guest launches.  It looks a bit suspect maybe?

cat /var/log/xen/*log
 domid: 7
 Warning: vlan 0 is not connected to host network
 -videoram option does not work with cirrus vga device model. Videoram
 set to 4M.
 /home/abuild/rpmbuild/BUILD/xen-4.1.2-testing/tools/ioemu-dir/hw/xen_blktap.c:704:
 Init blktap pipes
 Could not open /var/run/tap/qemu-read-7
 char device redirected to /dev/pts/1
 xs_read(): target get error. /local/domain/7/target.
 xs_read(): vncpasswd get error.
 /vm/22eef8a2-7b68-4bb6-a69f-632d20db0d84/vncpasswd.
 Waiting for domain test (domid 7) to die [pid 28807]

> Are your hotplug scripts running at all? ...

cat /tmp/hotplog.log
 Tue Jan 24 07:23:49 PST 2012: Running /etc/xen/scripts/vif-bridge
 online type_if=vif
 Tue Jan 24 07:23:49 PST 2012: Running /etc/xen/scripts/vif-bridge
 online

> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen lists a bunch of
> configuration files and logs which might be of interest, at least to
> skim looking for anything odd.

cat /var/log/xen/xen-hotplug.log
cat /var/log/xen/qemu-dm-*.log
 above ...

cat /var/log/xeb/console/*
 cat: /var/log/xeb/console/*: No such file or directory

I'm not completely sure what to look for that I'd know to be "odd".  I
think/hope the rest has already been reported in this thread.  If you
need anything else, please ID it and I can post it.

Regards,

Erin

p.s. Over on the opensuse-virtual list, at this thread,
http://lists.opensuse.org/opensuse-virtual/2012-01/msg00015.html

I just received a new post (It hasn't propagated to the list archive
just yet) says:

	"We also have what appears to be this problem, on Fedora 16 with
	Xen 4.1.2. We can create guests with xm that connect to network
	but the same guest will not connect, when created by xl. In both
	cases we can see the appropriate vif has been created and
	attached (xl network-list shows it) but no connectivity from
	within the guest. (If I convert the same guest config file to
	virsh format, then virsh also creates and connects it to the
	network successfully.)

	I post this to the list as evidence that this is not just a
	problem with SuSE."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 15:57:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 15: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 1Rpik3-0007US-UN; Tue, 24 Jan 2012 15:57:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpik2-0007T2-Q8
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 15:57:03 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327420616!12357969!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16742 invoked from network); 24 Jan 2012 15:56:56 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-4.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 15:56:56 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C883621902
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 10:56:51 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Tue, 24 Jan 2012 10:56:51 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	vvW1tiB+uco/qWUMDlr5JYHIQUk=; b=c2tpFemxUEGOWpJeqbctp939LrAiv603
	//O9ZtZufclA7nxO2NVl9qbpLePY+OXSskusHBTr5PdFUPS4ZjsYylusMSCy+OnZ
	IzZUJ4RNr/Ypj82iorEKtN33ZNvkc9uCpl7LpyZiDekOLtMqd8xXb5U/oOAps0P3
	qtyo0jN4dUk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=vvW1tiB+uco/qWUMDlr5JYHIQUk=; b=
	gqV6e2JoSVgg1ervstDs5KMT3iUp5j9cG8jpL2htrCF2Fzf+J9kAlArfg61s8u5e
	6Ixdqc/cyOzhKkV7wyebJDSkqX/S9NJ+5hAkAKPTH6jcY8bW4lJzB4Qbc5GH8JuC
	LfBXlSdGScsLhEALkNZfaYrWVkPw10UHS/W+jc4xDOs=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 9754AA000A6; Tue, 24 Jan 2012 10:56:51 -0500 (EST)
Message-Id: <1327420611.19936.140661027415609@webmail.messagingengine.com>
X-Sasl-Enc: m8Xh3J8pDFdeeCon/7GZkCxy3OZCGqoo6PRakizR2Utb 1327420611
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327415184.24561.182.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Jan 2012 07:56:51 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

> Does "ifconfig -a" in dom0 show a vifX.Y device for the domain? You previous xenstore log
> suggests it should be there but lets double check.

edit /etc/xen/scripts/vif-bridge
	#!/bin/bash
+       exec 1>>/tmp/hotplog.log
+       exec 2>&1
+       echo "`date`: Running $0 $*"

xl create test.cfg


ifconfig -a
brINT     Link encap:Ethernet  HWaddr 00:52:35:11:26:3B
          inet addr:192.168.1.10  Bcast:192.168.1.255 
          Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:444732 errors:0 dropped:0 overruns:0 frame:0
          TX packets:287814 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1096020765 (1045.2 Mb)  TX bytes:95900515 (91.4 Mb)

eth0      Link encap:Ethernet  HWaddr 00:52:35:11:26:3B
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:840591 errors:0 dropped:0 overruns:0 frame:0
          TX packets:376159 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1132351110 (1079.8 Mb)  TX bytes:100533253 (95.8 Mb)
          Interrupt:48

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3922 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3922 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:252238 (246.3 Kb)  TX bytes:252238 (246.3 Kb)

vif7.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

xl network-list test
 Idx BE Mac Addr.         handle state evt-ch   tx-/rx-ring-ref BE-path
 0   0  00:16:3e:12:34:01      0     4     15   768/769        
 /local/domain/0/backend/vif/7/0


> Do you get anything in the logs under /var/log/xen?

Just this after the Guest launches.  It looks a bit suspect maybe?

cat /var/log/xen/*log
 domid: 7
 Warning: vlan 0 is not connected to host network
 -videoram option does not work with cirrus vga device model. Videoram
 set to 4M.
 /home/abuild/rpmbuild/BUILD/xen-4.1.2-testing/tools/ioemu-dir/hw/xen_blktap.c:704:
 Init blktap pipes
 Could not open /var/run/tap/qemu-read-7
 char device redirected to /dev/pts/1
 xs_read(): target get error. /local/domain/7/target.
 xs_read(): vncpasswd get error.
 /vm/22eef8a2-7b68-4bb6-a69f-632d20db0d84/vncpasswd.
 Waiting for domain test (domid 7) to die [pid 28807]

> Are your hotplug scripts running at all? ...

cat /tmp/hotplog.log
 Tue Jan 24 07:23:49 PST 2012: Running /etc/xen/scripts/vif-bridge
 online type_if=vif
 Tue Jan 24 07:23:49 PST 2012: Running /etc/xen/scripts/vif-bridge
 online

> http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen lists a bunch of
> configuration files and logs which might be of interest, at least to
> skim looking for anything odd.

cat /var/log/xen/xen-hotplug.log
cat /var/log/xen/qemu-dm-*.log
 above ...

cat /var/log/xeb/console/*
 cat: /var/log/xeb/console/*: No such file or directory

I'm not completely sure what to look for that I'd know to be "odd".  I
think/hope the rest has already been reported in this thread.  If you
need anything else, please ID it and I can post it.

Regards,

Erin

p.s. Over on the opensuse-virtual list, at this thread,
http://lists.opensuse.org/opensuse-virtual/2012-01/msg00015.html

I just received a new post (It hasn't propagated to the list archive
just yet) says:

	"We also have what appears to be this problem, on Fedora 16 with
	Xen 4.1.2. We can create guests with xm that connect to network
	but the same guest will not connect, when created by xl. In both
	cases we can see the appropriate vif has been created and
	attached (xl network-list shows it) but no connectivity from
	within the guest. (If I convert the same guest config file to
	virsh format, then virsh also creates and connects it to the
	network successfully.)

	I post this to the list as evidence that this is not just a
	problem with SuSE."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:01:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpinp-0008Ik-7x; Tue, 24 Jan 2012 16:00:57 +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 1Rpinn-0008IE-LJ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:00:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327420847!12355192!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18517 invoked from network); 24 Jan 2012 16:00:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:00:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10254256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:00: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; Tue, 24 Jan 2012 16:00: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
	1Rpinc-0000ga-Uj; Tue, 24 Jan 2012 16:00:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpinc-0003vq-Sc;
	Tue, 24 Jan 2012 16:00:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.54700.872146.773765@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:00:44 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Tim Deegan <tim@xen.org>, 
	Adin Scannell <adin@scannel.ca>, Keir Fraser <keir@xen.org>
In-Reply-To: <20254.39351.854362.661374@mariner.uk.xensource.com>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.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] 11574: 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

Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
> This is a host-specific, but deterministic, failure.  My bisector has
> been working on it (the basis pass was in November so there has been a
> lot of ground to cover and I had to make some new arrangements to be
> able to run an ad-hoc bisection of this problem) and the results so
> far are fingering changesets between 24367:537ceb11d51e (bad) and
> 24362:d35bedf334f2 (good).

The bisector is now minded to blame this changeset:

  changeset:   24367:537ceb11d51e
  user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
  date:        Tue Dec 06 20:31:49 2011 +0000
  files:       xen/arch/x86/hvm/hvm.c
  description:
  Improve handling of nested page faults

  Add checks for access type. Be less reliant on implicit semantics.

  Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Acked-by: Tim Deegan <tim@xen.org>
  Committed-by: Tim Deegan <tim@xen.org>

It's doing a couple more before-and-after repros to be sure, but this
looks like a plausible candidate.  Full diff below.

I'm not an expert on this area.  Perhaps someone could speculate what
Windows is doing that is triggering one of these new checks ?

Ian.

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.org>
# Date 1323203509 0
# Node ID 537ceb11d51ef60cd4abffd2f54de0ae0ca50008
# Parent  534b2a15e6695dfd8866c0ff626b002cbf57991a
Improve handling of nested page faults

Add checks for access type. Be less reliant on implicit semantics.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>

diff -r 534b2a15e669 -r 537ceb11d51e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Tue Dec 06 20:10:32 2011 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Tue Dec 06 20:31:49 2011 +0000
@@ -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 Tue Jan 24 16:01:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:01:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpinp-0008Ik-7x; Tue, 24 Jan 2012 16:00:57 +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 1Rpinn-0008IE-LJ
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:00:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327420847!12355192!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18517 invoked from network); 24 Jan 2012 16:00:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:00:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10254256"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:00: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; Tue, 24 Jan 2012 16:00: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
	1Rpinc-0000ga-Uj; Tue, 24 Jan 2012 16:00:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpinc-0003vq-Sc;
	Tue, 24 Jan 2012 16:00:44 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.54700.872146.773765@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:00:44 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>, Tim Deegan <tim@xen.org>, 
	Adin Scannell <adin@scannel.ca>, Keir Fraser <keir@xen.org>
In-Reply-To: <20254.39351.854362.661374@mariner.uk.xensource.com>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.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] 11574: 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

Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
> This is a host-specific, but deterministic, failure.  My bisector has
> been working on it (the basis pass was in November so there has been a
> lot of ground to cover and I had to make some new arrangements to be
> able to run an ad-hoc bisection of this problem) and the results so
> far are fingering changesets between 24367:537ceb11d51e (bad) and
> 24362:d35bedf334f2 (good).

The bisector is now minded to blame this changeset:

  changeset:   24367:537ceb11d51e
  user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
  date:        Tue Dec 06 20:31:49 2011 +0000
  files:       xen/arch/x86/hvm/hvm.c
  description:
  Improve handling of nested page faults

  Add checks for access type. Be less reliant on implicit semantics.

  Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Acked-by: Tim Deegan <tim@xen.org>
  Committed-by: Tim Deegan <tim@xen.org>

It's doing a couple more before-and-after repros to be sure, but this
looks like a plausible candidate.  Full diff below.

I'm not an expert on this area.  Perhaps someone could speculate what
Windows is doing that is triggering one of these new checks ?

Ian.

# HG changeset patch
# User Andres Lagar-Cavilla <andres@lagarcavilla.org>
# Date 1323203509 0
# Node ID 537ceb11d51ef60cd4abffd2f54de0ae0ca50008
# Parent  534b2a15e6695dfd8866c0ff626b002cbf57991a
Improve handling of nested page faults

Add checks for access type. Be less reliant on implicit semantics.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>

diff -r 534b2a15e669 -r 537ceb11d51e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Tue Dec 06 20:10:32 2011 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Tue Dec 06 20:31:49 2011 +0000
@@ -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 Tue Jan 24 16:06:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16: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 1RpitG-0000Dj-6w; Tue, 24 Jan 2012 16:06: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 1RpitF-0000Db-3P
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:06:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327421165!50072921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13651 invoked from network); 24 Jan 2012 16:06:05 -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;
	24 Jan 2012 16:06:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10254435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:06:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 16:06: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
	1Rpit8-0000iY-4d; Tue, 24 Jan 2012 16:06:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpit8-0003wH-3Y;
	Tue, 24 Jan 2012 16:06:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.55041.872764.353017@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:06:25 +0000
To: Doug Magee <djmagee@mageenet.net>
In-Reply-To: <6a3f270992ebb15b7ea4.1326821190@mnetdjm4.mageenet.host>
References: <patchbomb.1326821188@mnetdjm4.mageenet.host>
	<6a3f270992ebb15b7ea4.1326821190@mnetdjm4.mageenet.host>
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 2 of 2] libxl_pci: verify device is
 assignable before adding to 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

Doug Magee writes ("[PATCH 2 of 2] libxl_pci: verify device is assignable before adding to domain"):
> Previously, libxl__device_pci_add only checked the device to be added against
> the list of currently assigned devices.  This patch changes the behavior to
> check that the device to be assigned is in the list of assignable devices,
> which only includes those owned by pciback and not assigned to another domain.
...
> +    libxl_device_pci *assignable;
> +    int num_assignable, i, rc;
...
> +    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);
> +

What about failure ?  libxl_device_pci_list_assignable might return
NULL on failure, I think.  So you need to add a check for that.

And in that case it won't assign to num_assignable either, leading to
an uninitialised variable use and possible crash in out.  I think you
should initialise assignable and num_assignable to 0 to avoid this.

> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device is either assigned to another domain, or not owned by pciback");

While you're here, would you please wrap this line to within 75-80
columns ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:06:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16: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 1RpitG-0000Dj-6w; Tue, 24 Jan 2012 16:06: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 1RpitF-0000Db-3P
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:06:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327421165!50072921!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13651 invoked from network); 24 Jan 2012 16:06:05 -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;
	24 Jan 2012 16:06:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10254435"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:06:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 16:06: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
	1Rpit8-0000iY-4d; Tue, 24 Jan 2012 16:06:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpit8-0003wH-3Y;
	Tue, 24 Jan 2012 16:06:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.55041.872764.353017@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:06:25 +0000
To: Doug Magee <djmagee@mageenet.net>
In-Reply-To: <6a3f270992ebb15b7ea4.1326821190@mnetdjm4.mageenet.host>
References: <patchbomb.1326821188@mnetdjm4.mageenet.host>
	<6a3f270992ebb15b7ea4.1326821190@mnetdjm4.mageenet.host>
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 2 of 2] libxl_pci: verify device is
 assignable before adding to 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

Doug Magee writes ("[PATCH 2 of 2] libxl_pci: verify device is assignable before adding to domain"):
> Previously, libxl__device_pci_add only checked the device to be added against
> the list of currently assigned devices.  This patch changes the behavior to
> check that the device to be assigned is in the list of assignable devices,
> which only includes those owned by pciback and not assigned to another domain.
...
> +    libxl_device_pci *assignable;
> +    int num_assignable, i, rc;
...
> +    assignable = libxl_device_pci_list_assignable(ctx, &num_assignable);
> +

What about failure ?  libxl_device_pci_list_assignable might return
NULL on failure, I think.  So you need to add a check for that.

And in that case it won't assign to num_assignable either, leading to
an uninitialised variable use and possible crash in out.  I think you
should initialise assignable and num_assignable to 0 to avoid this.

> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device already attached to a domain");
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "PCI device is either assigned to another domain, or not owned by pciback");

While you're here, would you please wrap this line to within 75-80
columns ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpiy5-0000aU-3Y; Tue, 24 Jan 2012 16:11:33 +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 1Rpiy3-0000ZL-Bj
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:11:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327421483!8638586!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24769 invoked from network); 24 Jan 2012 16:11:25 -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;
	24 Jan 2012 16:11:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="21227185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:11:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:11:24 -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 q0OGBK8C002675;
	Tue, 24 Jan 2012 08:11:23 -0800
MIME-Version: 1.0
X-Mercurial-Node: c6111aec665afded66a6f6b2d7ee4380b0dd58d2
Message-ID: <c6111aec665afded66a6.1327421384@elijah>
In-Reply-To: <patchbomb.1327421382@elijah>
References: <patchbomb.1327421382@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 24 Jan 2012 16:09:44 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] xenoprof: Make the escape code
	consistent across 32 and	64-bit 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 the moment, the xenoprof escape code is defined as "~0UL".
Unfortunately, this expands to 0xffffffff on 32-bit systems
and 0xffffffffffffffff on 64-bit systems; with the result that
while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
"compat mode") is broken.

This patch makes the definition consistent across architectures.
In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
but this was seen as an acceptable thing to do.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r dc346270f1aa -r c6111aec665a xen/include/public/xenoprof.h
--- a/xen/include/public/xenoprof.h	Tue Jan 24 16:09:14 2012 +0000
+++ b/xen/include/public/xenoprof.h	Tue Jan 24 16:09:15 2012 +0000
@@ -68,7 +68,7 @@ struct event_log {
 };
 
 /* PC value that indicates a special code */
-#define XENOPROF_ESCAPE_CODE ~0UL
+#define XENOPROF_ESCAPE_CODE (~0ULL)
 /* Transient events for the xenoprof->oprofile cpu buf */
 #define XENOPROF_TRACE_BEGIN 1
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpiy5-0000aU-3Y; Tue, 24 Jan 2012 16:11:33 +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 1Rpiy3-0000ZL-Bj
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:11:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327421483!8638586!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24769 invoked from network); 24 Jan 2012 16:11:25 -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;
	24 Jan 2012 16:11:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="21227185"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:11:24 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:11:24 -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 q0OGBK8C002675;
	Tue, 24 Jan 2012 08:11:23 -0800
MIME-Version: 1.0
X-Mercurial-Node: c6111aec665afded66a6f6b2d7ee4380b0dd58d2
Message-ID: <c6111aec665afded66a6.1327421384@elijah>
In-Reply-To: <patchbomb.1327421382@elijah>
References: <patchbomb.1327421382@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 24 Jan 2012 16:09:44 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] xenoprof: Make the escape code
	consistent across 32 and	64-bit 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 the moment, the xenoprof escape code is defined as "~0UL".
Unfortunately, this expands to 0xffffffff on 32-bit systems
and 0xffffffffffffffff on 64-bit systems; with the result that
while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
"compat mode") is broken.

This patch makes the definition consistent across architectures.
In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
but this was seen as an acceptable thing to do.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r dc346270f1aa -r c6111aec665a xen/include/public/xenoprof.h
--- a/xen/include/public/xenoprof.h	Tue Jan 24 16:09:14 2012 +0000
+++ b/xen/include/public/xenoprof.h	Tue Jan 24 16:09:15 2012 +0000
@@ -68,7 +68,7 @@ struct event_log {
 };
 
 /* PC value that indicates a special code */
-#define XENOPROF_ESCAPE_CODE ~0UL
+#define XENOPROF_ESCAPE_CODE (~0ULL)
 /* Transient events for the xenoprof->oprofile cpu buf */
 #define XENOPROF_TRACE_BEGIN 1
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpiy5-0000af-Fu; Tue, 24 Jan 2012 16:11:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rpiy3-0000ZO-NW
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:11:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327421484!12202459!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQ2Nzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 460 invoked from network); 24 Jan 2012 16:11:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:11:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="178870736"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:11:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:11:23 -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 q0OGBK8B002675;
	Tue, 24 Jan 2012 08:11:22 -0800
MIME-Version: 1.0
X-Mercurial-Node: dc346270f1aa218e4ea806412dafc1b12c1b9458
Message-ID: <dc346270f1aa218e4ea8.1327421383@elijah>
In-Reply-To: <patchbomb.1327421382@elijah>
References: <patchbomb.1327421382@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 24 Jan 2012 16:09:43 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] xenoprof: Use uint64_t explicitly for
	internal calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A recent changeset to make XENOPROF_ESCAPE_CODE consistent across
32- and 64-bit builds caused a build failure, because values were
passed through functions as "unsigned long".  Replace these with
uint64_t explicitly.

Also remove redundant function prototype from perfmon.c, now that
it's in a header file.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 370924e204dc -r dc346270f1aa xen/arch/ia64/xen/oprofile/perfmon.c
--- a/xen/arch/ia64/xen/oprofile/perfmon.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/arch/ia64/xen/oprofile/perfmon.c	Tue Jan 24 16:09:14 2012 +0000
@@ -38,8 +38,6 @@
 #include <asm/vmx.h>    /* for vmx_user_mode() */
 
 // XXX move them to an appropriate header file
-extern void xenoprof_log_event(struct vcpu *vcpu, struct pt_regs * regs,
-                               unsigned long eip, int mode, int event);
 extern int is_active(struct domain *d);
 
 static int allow_virq;
diff -r 370924e204dc -r dc346270f1aa xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/xenoprof.c	Tue Jan 24 16:09:14 2012 +0000
@@ -475,7 +475,7 @@ static int xenoprof_buf_space(struct dom
 
 /* Check for space and add a sample. Return 1 if successful, 0 otherwise. */
 static int xenoprof_add_sample(struct domain *d, xenoprof_buf_t *buf,
-                               unsigned long eip, int mode, int event)
+                               uint64_t eip, int mode, int event)
 {
     int head, tail, size;
 
@@ -512,7 +512,7 @@ static int xenoprof_add_sample(struct do
 }
 
 int xenoprof_add_trace(struct domain *d, struct vcpu *vcpu,
-                       unsigned long eip, int mode)
+                       uint64_t eip, int mode)
 {
     xenoprof_buf_t *buf = d->xenoprof->vcpu[vcpu->vcpu_id].buffer;
 
@@ -527,7 +527,7 @@ int xenoprof_add_trace(struct domain *d,
 }
 
 void xenoprof_log_event(struct vcpu *vcpu, 
-                        struct cpu_user_regs * regs, unsigned long eip, 
+                        struct cpu_user_regs * regs, uint64_t eip, 
                         int mode, int event)
 {
     struct domain *d = vcpu->domain;
diff -r 370924e204dc -r dc346270f1aa xen/include/xen/xenoprof.h
--- a/xen/include/xen/xenoprof.h	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/include/xen/xenoprof.h	Tue Jan 24 16:09:14 2012 +0000
@@ -69,7 +69,7 @@ int is_passive(struct domain *d);
 void free_xenoprof_pages(struct domain *d);
 
 int xenoprof_add_trace(struct domain *d, struct vcpu *v, 
-                       unsigned long eip, int mode);
+                       uint64_t eip, int mode);
 
 #define PMU_OWNER_NONE          0
 #define PMU_OWNER_XENOPROF      1
@@ -78,7 +78,7 @@ int acquire_pmu_ownship(int pmu_ownershi
 void release_pmu_ownship(int pmu_ownership);
 
 void xenoprof_log_event(struct vcpu *vcpu,
-                        struct cpu_user_regs * regs, unsigned long eip,
+                        struct cpu_user_regs * regs, uint64_t eip,
                         int mode, int event);
 
 #endif  /* __XEN__XENOPROF_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpiy5-0000af-Fu; Tue, 24 Jan 2012 16:11:33 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rpiy3-0000ZO-NW
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:11:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327421484!12202459!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQ2Nzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 460 invoked from network); 24 Jan 2012 16:11:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:11:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="178870736"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:11:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:11:23 -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 q0OGBK8B002675;
	Tue, 24 Jan 2012 08:11:22 -0800
MIME-Version: 1.0
X-Mercurial-Node: dc346270f1aa218e4ea806412dafc1b12c1b9458
Message-ID: <dc346270f1aa218e4ea8.1327421383@elijah>
In-Reply-To: <patchbomb.1327421382@elijah>
References: <patchbomb.1327421382@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 24 Jan 2012 16:09:43 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] xenoprof: Use uint64_t explicitly for
	internal calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A recent changeset to make XENOPROF_ESCAPE_CODE consistent across
32- and 64-bit builds caused a build failure, because values were
passed through functions as "unsigned long".  Replace these with
uint64_t explicitly.

Also remove redundant function prototype from perfmon.c, now that
it's in a header file.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 370924e204dc -r dc346270f1aa xen/arch/ia64/xen/oprofile/perfmon.c
--- a/xen/arch/ia64/xen/oprofile/perfmon.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/arch/ia64/xen/oprofile/perfmon.c	Tue Jan 24 16:09:14 2012 +0000
@@ -38,8 +38,6 @@
 #include <asm/vmx.h>    /* for vmx_user_mode() */
 
 // XXX move them to an appropriate header file
-extern void xenoprof_log_event(struct vcpu *vcpu, struct pt_regs * regs,
-                               unsigned long eip, int mode, int event);
 extern int is_active(struct domain *d);
 
 static int allow_virq;
diff -r 370924e204dc -r dc346270f1aa xen/common/xenoprof.c
--- a/xen/common/xenoprof.c	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/common/xenoprof.c	Tue Jan 24 16:09:14 2012 +0000
@@ -475,7 +475,7 @@ static int xenoprof_buf_space(struct dom
 
 /* Check for space and add a sample. Return 1 if successful, 0 otherwise. */
 static int xenoprof_add_sample(struct domain *d, xenoprof_buf_t *buf,
-                               unsigned long eip, int mode, int event)
+                               uint64_t eip, int mode, int event)
 {
     int head, tail, size;
 
@@ -512,7 +512,7 @@ static int xenoprof_add_sample(struct do
 }
 
 int xenoprof_add_trace(struct domain *d, struct vcpu *vcpu,
-                       unsigned long eip, int mode)
+                       uint64_t eip, int mode)
 {
     xenoprof_buf_t *buf = d->xenoprof->vcpu[vcpu->vcpu_id].buffer;
 
@@ -527,7 +527,7 @@ int xenoprof_add_trace(struct domain *d,
 }
 
 void xenoprof_log_event(struct vcpu *vcpu, 
-                        struct cpu_user_regs * regs, unsigned long eip, 
+                        struct cpu_user_regs * regs, uint64_t eip, 
                         int mode, int event)
 {
     struct domain *d = vcpu->domain;
diff -r 370924e204dc -r dc346270f1aa xen/include/xen/xenoprof.h
--- a/xen/include/xen/xenoprof.h	Mon Jan 23 15:10:43 2012 +0000
+++ b/xen/include/xen/xenoprof.h	Tue Jan 24 16:09:14 2012 +0000
@@ -69,7 +69,7 @@ int is_passive(struct domain *d);
 void free_xenoprof_pages(struct domain *d);
 
 int xenoprof_add_trace(struct domain *d, struct vcpu *v, 
-                       unsigned long eip, int mode);
+                       uint64_t eip, int mode);
 
 #define PMU_OWNER_NONE          0
 #define PMU_OWNER_XENOPROF      1
@@ -78,7 +78,7 @@ int acquire_pmu_ownship(int pmu_ownershi
 void release_pmu_ownship(int pmu_ownership);
 
 void xenoprof_log_event(struct vcpu *vcpu,
-                        struct cpu_user_regs * regs, unsigned long eip,
+                        struct cpu_user_regs * regs, uint64_t eip,
                         int mode, int event);
 
 #endif  /* __XEN__XENOPROF_H__ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpiy3-0000Zn-Mu; Tue, 24 Jan 2012 16:11:31 +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 1Rpiy2-0000ZH-Rk
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:11:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327421483!8638586!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24745 invoked from network); 24 Jan 2012 16:11:24 -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;
	24 Jan 2012 16:11:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="21227184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:11:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:11:22 -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 q0OGBK8A002675;
	Tue, 24 Jan 2012 08:11:21 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327421382@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 24 Jan 2012 16:09:42 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] xenoprof: Fix 32-on-64 bit (supplemental)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Tue Jan 24 16:11:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:11:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpiy3-0000Zn-Mu; Tue, 24 Jan 2012 16:11:31 +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 1Rpiy2-0000ZH-Rk
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:11:31 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327421483!8638586!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24745 invoked from network); 24 Jan 2012 16:11:24 -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;
	24 Jan 2012 16:11:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="21227184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:11:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:11:22 -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 q0OGBK8A002675;
	Tue, 24 Jan 2012 08:11:21 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327421382@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Tue, 24 Jan 2012 16:09:42 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] xenoprof: Fix 32-on-64 bit (supplemental)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Tue Jan 24 16:13:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:13:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj0C-0000uF-1O; Tue, 24 Jan 2012 16:13:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rpj0A-0000tj-Gz
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:13:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327421615!12234192!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQ2Nzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13023 invoked from network); 24 Jan 2012 16:13:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:13:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="178871217"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:13:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:13:31 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0OGDU8a002682;
	Tue, 24 Jan 2012 08:13:31 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <patchbomb.1327421382@elijah>
References: <patchbomb.1327421382@elijah>
Date: Tue, 24 Jan 2012 16:13:29 +0000
Message-ID: <1327421609.26455.360.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 2] xenoprof: Fix 32-on-64 bit
	(supplemental)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Actually, please hold off on applying these for a minute -- I meant to
cancel the send pending a final build check (both 32- and 64-bit), but
it didn't work.  I'll send an ACK when they're ready.

 -George

On Tue, 2012-01-24 at 16:09 +0000, George Dunlap wrote:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:13:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:13:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj0C-0000uF-1O; Tue, 24 Jan 2012 16:13:44 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rpj0A-0000tj-Gz
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:13:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327421615!12234192!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQ2Nzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13023 invoked from network); 24 Jan 2012 16:13:36 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:13:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="178871217"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:13:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 11:13:31 -0500
Received: from [10.80.2.24] (elijah.uk.xensource.com [10.80.2.24])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0OGDU8a002682;
	Tue, 24 Jan 2012 08:13:31 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
In-Reply-To: <patchbomb.1327421382@elijah>
References: <patchbomb.1327421382@elijah>
Date: Tue, 24 Jan 2012 16:13:29 +0000
Message-ID: <1327421609.26455.360.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 2] xenoprof: Fix 32-on-64 bit
	(supplemental)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Actually, please hold off on applying these for a minute -- I meant to
cancel the send pending a final build check (both 32- and 64-bit), but
it didn't work.  I'll send an ACK when they're ready.

 -George

On Tue, 2012-01-24 at 16:09 +0000, George Dunlap wrote:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:14:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj0P-0000wB-FD; Tue, 24 Jan 2012 16:13: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 1Rpj0N-0000vE-Vd
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:13:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327421629!8425324!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10338 invoked from network); 24 Jan 2012 16:13:50 -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; 24 Jan 2012 16:13:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 16:13:49 +0000
Message-Id: <4F1EE714020000780006EB0C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 16:15:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1ED189.70401@citrix.com>
In-Reply-To: <4F1ED189.70401@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.01.12 at 16:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 20/01/12 16:33, Jan Beulich wrote:
>> This addresses a number of problems in msixtbl_{read,write}():
>> - address alignment was not checked, allowing for memory corruption in
>>   the hypervisor (write case) or returning of hypervisor private data
>>   to the guest (read case)
>> - the interrupt mask bit was permitted to be written by the guest
>>   (while Xen's interrupt flow control routines need to control it)
>> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>>   numbers (making it unobvious why they have these values, and making
>>   the latter non-portable)
>> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>>   non-zero table offset); this was also affecting host MSI-X code
>> - struct msixtbl_entry's table_flags[] was one element larger than
>>   necessary due to improper open-coding of BITS_TO_LONGS()
>> - msixtbl_read() unconditionally accessed the physical table, even
>>   though the data was only needed in a quarter of all cases
>> - various calculations were done unnecessarily for both of the rather
>>   distinct code paths in msixtbl_read()
>>
>> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
>> chosen to be 3.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Tested by backport to XenServer 6.0 (Xen-4.1.1)  The only conflicts were
> with the context around adding the two new header files, and <xen/pfn.h>
> which is a new header file.
> 
> Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks a lot, Andrew! (Keir had already committed the patch.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:14:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj0P-0000wB-FD; Tue, 24 Jan 2012 16:13: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 1Rpj0N-0000vE-Vd
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:13:56 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327421629!8425324!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10338 invoked from network); 24 Jan 2012 16:13:50 -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; 24 Jan 2012 16:13:50 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 16:13:49 +0000
Message-Id: <4F1EE714020000780006EB0C@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 16:15:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F19A577020000780006E115@nat28.tlf.novell.com>
	<4F1ED189.70401@citrix.com>
In-Reply-To: <4F1ED189.70401@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/vMSI: miscellaneous fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 24.01.12 at 16:43, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 20/01/12 16:33, Jan Beulich wrote:
>> This addresses a number of problems in msixtbl_{read,write}():
>> - address alignment was not checked, allowing for memory corruption in
>>   the hypervisor (write case) or returning of hypervisor private data
>>   to the guest (read case)
>> - the interrupt mask bit was permitted to be written by the guest
>>   (while Xen's interrupt flow control routines need to control it)
>> - MAX_MSIX_TABLE_{ENTRIES,PAGES} were pointlessly defined to plain
>>   numbers (making it unobvious why they have these values, and making
>>   the latter non-portable)
>> - MAX_MSIX_TABLE_PAGES was also off by one (failing to account for a
>>   non-zero table offset); this was also affecting host MSI-X code
>> - struct msixtbl_entry's table_flags[] was one element larger than
>>   necessary due to improper open-coding of BITS_TO_LONGS()
>> - msixtbl_read() unconditionally accessed the physical table, even
>>   though the data was only needed in a quarter of all cases
>> - various calculations were done unnecessarily for both of the rather
>>   distinct code paths in msixtbl_read()
>>
>> Additionally it is unclear on what basis MAX_MSIX_ACC_ENTRIES was
>> chosen to be 3.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Tested by backport to XenServer 6.0 (Xen-4.1.1)  The only conflicts were
> with the context around adding the two new header files, and <xen/pfn.h>
> which is a new header file.
> 
> Tested-and-acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

Thanks a lot, Andrew! (Keir had already committed the patch.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:16:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:16:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj2U-0001En-2f; Tue, 24 Jan 2012 16:16:06 +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 1Rpj2S-0001EX-KL
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:16:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327421721!57277904!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYyODc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31450 invoked from network); 24 Jan 2012 16:15:22 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 16:15:22 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4F7D27EC076;
	Tue, 24 Jan 2012 08:16:02 -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=bktJAXlp8BCMxvQZy3AcqsLjp7RSEauyYXczQVofZE7E
	qFwKbvZhsCpSTlMcCop5X1avFSd1xUVpwVcRdJdq06oqKkxmCfEK31sjXaJFsK7v
	Hr27k8eUV5hnJWxtm8/ZQN65xmRLBo4wiqmrKsCg+0FWYYLFfNk86MGgwnE4gak=
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=9zvb2X1pYBm+R50XrubRTBTmqgE=; b=oCbUjuB0
	WeIB5/NP1euN6FC9X071kJAWSSPQtU923/B5PWAXWHOkqG7/6/5CI95FCj6Xx++3
	e1TIx7o4CY8masxHlUtgJltGu8wOdcyerawshSl0X22Dbe+VH/oEihuWEYv/wlSO
	MbyW/Nlz2HiirZMjB0bWjzrrDbXGl6urDY0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id D43147EC072; 
	Tue, 24 Jan 2012 08:16:01 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Jan 2012 08:16:02 -0800
Message-ID: <1509870155131642e5d6afff5f2cc337.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20254.54700.872146.773765@mariner.uk.xensource.com>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 08:16:02 -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: Adin Scannell <adin@scannell.ca>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: tolerable 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

> Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
>> This is a host-specific, but deterministic, failure.  My bisector has
>> been working on it (the basis pass was in November so there has been a
>> lot of ground to cover and I had to make some new arrangements to be
>> able to run an ad-hoc bisection of this problem) and the results so
>> far are fingering changesets between 24367:537ceb11d51e (bad) and
>> 24362:d35bedf334f2 (good).
>
> The bisector is now minded to blame this changeset:
>
>   changeset:   24367:537ceb11d51e
>   user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   date:        Tue Dec 06 20:31:49 2011 +0000
>   files:       xen/arch/x86/hvm/hvm.c
>   description:
>   Improve handling of nested page faults
>
>   Add checks for access type. Be less reliant on implicit semantics.
>
>   Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Acked-by: Tim Deegan <tim@xen.org>
>   Committed-by: Tim Deegan <tim@xen.org>
>
> It's doing a couple more before-and-after repros to be sure, but this
> looks like a plausible candidate.  Full diff below.

Thanks Ian,
just to be sure, none of the following conditions apply on your test:
- hvm uses memory sharing
- hvm runs a backend pv driver
- hvm uses populate-on-demand.

If all the above apply, I can quickly put together a micro-patch to assert
that the deal-breaker is
> -    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
> +    if ( (p2mt == p2m_mmio_dm) ||
> +         (access_w && (p2mt == p2m_ram_ro)) )
>

Would you be able to test that?
Thanks again
Andres
> I'm not an expert on this area.  Perhaps someone could speculate what
> Windows is doing that is triggering one of these new checks ?
>
> Ian.
>
> # HG changeset patch
> # User Andres Lagar-Cavilla <andres@lagarcavilla.org>
> # Date 1323203509 0
> # Node ID 537ceb11d51ef60cd4abffd2f54de0ae0ca50008
> # Parent  534b2a15e6695dfd8866c0ff626b002cbf57991a
> Improve handling of nested page faults
>
> Add checks for access type. Be less reliant on implicit semantics.
>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Acked-by: Tim Deegan <tim@xen.org>
> Committed-by: Tim Deegan <tim@xen.org>
>
> diff -r 534b2a15e669 -r 537ceb11d51e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c	Tue Dec 06 20:10:32 2011 +0000
> +++ b/xen/arch/x86/hvm/hvm.c	Tue Dec 06 20:31:49 2011 +0000
> @@ -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 Tue Jan 24 16:16:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:16:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj2U-0001En-2f; Tue, 24 Jan 2012 16:16:06 +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 1Rpj2S-0001EX-KL
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:16:04 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327421721!57277904!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTYyODc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31450 invoked from network); 24 Jan 2012 16:15:22 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-4.tower-27.messagelabs.com with SMTP;
	24 Jan 2012 16:15:22 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4F7D27EC076;
	Tue, 24 Jan 2012 08:16:02 -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=bktJAXlp8BCMxvQZy3AcqsLjp7RSEauyYXczQVofZE7E
	qFwKbvZhsCpSTlMcCop5X1avFSd1xUVpwVcRdJdq06oqKkxmCfEK31sjXaJFsK7v
	Hr27k8eUV5hnJWxtm8/ZQN65xmRLBo4wiqmrKsCg+0FWYYLFfNk86MGgwnE4gak=
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=9zvb2X1pYBm+R50XrubRTBTmqgE=; b=oCbUjuB0
	WeIB5/NP1euN6FC9X071kJAWSSPQtU923/B5PWAXWHOkqG7/6/5CI95FCj6Xx++3
	e1TIx7o4CY8masxHlUtgJltGu8wOdcyerawshSl0X22Dbe+VH/oEihuWEYv/wlSO
	MbyW/Nlz2HiirZMjB0bWjzrrDbXGl6urDY0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id D43147EC072; 
	Tue, 24 Jan 2012 08:16:01 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Tue, 24 Jan 2012 08:16:02 -0800
Message-ID: <1509870155131642e5d6afff5f2cc337.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20254.54700.872146.773765@mariner.uk.xensource.com>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 08:16:02 -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: Adin Scannell <adin@scannell.ca>, Keir Fraser <keir@xen.org>,
	Tim Deegan <tim@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: tolerable 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

> Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
>> This is a host-specific, but deterministic, failure.  My bisector has
>> been working on it (the basis pass was in November so there has been a
>> lot of ground to cover and I had to make some new arrangements to be
>> able to run an ad-hoc bisection of this problem) and the results so
>> far are fingering changesets between 24367:537ceb11d51e (bad) and
>> 24362:d35bedf334f2 (good).
>
> The bisector is now minded to blame this changeset:
>
>   changeset:   24367:537ceb11d51e
>   user:        Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   date:        Tue Dec 06 20:31:49 2011 +0000
>   files:       xen/arch/x86/hvm/hvm.c
>   description:
>   Improve handling of nested page faults
>
>   Add checks for access type. Be less reliant on implicit semantics.
>
>   Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Acked-by: Tim Deegan <tim@xen.org>
>   Committed-by: Tim Deegan <tim@xen.org>
>
> It's doing a couple more before-and-after repros to be sure, but this
> looks like a plausible candidate.  Full diff below.

Thanks Ian,
just to be sure, none of the following conditions apply on your test:
- hvm uses memory sharing
- hvm runs a backend pv driver
- hvm uses populate-on-demand.

If all the above apply, I can quickly put together a micro-patch to assert
that the deal-breaker is
> -    if ( (p2mt == p2m_mmio_dm) || (p2mt == p2m_ram_ro) )
> +    if ( (p2mt == p2m_mmio_dm) ||
> +         (access_w && (p2mt == p2m_ram_ro)) )
>

Would you be able to test that?
Thanks again
Andres
> I'm not an expert on this area.  Perhaps someone could speculate what
> Windows is doing that is triggering one of these new checks ?
>
> Ian.
>
> # HG changeset patch
> # User Andres Lagar-Cavilla <andres@lagarcavilla.org>
> # Date 1323203509 0
> # Node ID 537ceb11d51ef60cd4abffd2f54de0ae0ca50008
> # Parent  534b2a15e6695dfd8866c0ff626b002cbf57991a
> Improve handling of nested page faults
>
> Add checks for access type. Be less reliant on implicit semantics.
>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Acked-by: Tim Deegan <tim@xen.org>
> Committed-by: Tim Deegan <tim@xen.org>
>
> diff -r 534b2a15e669 -r 537ceb11d51e xen/arch/x86/hvm/hvm.c
> --- a/xen/arch/x86/hvm/hvm.c	Tue Dec 06 20:10:32 2011 +0000
> +++ b/xen/arch/x86/hvm/hvm.c	Tue Dec 06 20:31:49 2011 +0000
> @@ -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 Tue Jan 24 16:17:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj42-0001T5-Iv; Tue, 24 Jan 2012 16:17:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rpj41-0001Sb-Uu
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:17:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327421854!10490005!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQ2Nzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26754 invoked from network); 24 Jan 2012 16:17:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:17:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="178872200"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:17: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, 24 Jan 2012 11:17:28 -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 q0OGHRw0002688;
	Tue, 24 Jan 2012 08:17:28 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <1327421609.26455.360.camel@elijah>
References: <patchbomb.1327421382@elijah> <1327421609.26455.360.camel@elijah>
Date: Tue, 24 Jan 2012 16:17:27 +0000
Message-ID: <1327421847.26455.362.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 2] xenoprof: Fix 32-on-64 bit
	(supplemental)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 16:13 +0000, George Dunlap wrote:
> Actually, please hold off on applying these for a minute -- I meant to
> cancel the send pending a final build check (both 32- and 64-bit), but
> it didn't work.  I'll send an ACK when they're ready.

OK, I think things are all good.

ACKed-by: George Dunlap <george.dunlap@eu.citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:17:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:17:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj42-0001T5-Iv; Tue, 24 Jan 2012 16:17:42 +0000
Received: from mail174.messagelabs.com ([85.158.138.51])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1Rpj41-0001Sb-Uu
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:17:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327421854!10490005!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjQ2Nzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26754 invoked from network); 24 Jan 2012 16:17:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-6.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:17:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="178872200"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 11:17: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, 24 Jan 2012 11:17:28 -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 q0OGHRw0002688;
	Tue, 24 Jan 2012 08:17:28 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
In-Reply-To: <1327421609.26455.360.camel@elijah>
References: <patchbomb.1327421382@elijah> <1327421609.26455.360.camel@elijah>
Date: Tue, 24 Jan 2012 16:17:27 +0000
Message-ID: <1327421847.26455.362.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 0 of 2] xenoprof: Fix 32-on-64 bit
	(supplemental)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 16:13 +0000, George Dunlap wrote:
> Actually, please hold off on applying these for a minute -- I meant to
> cancel the send pending a final build check (both 32- and 64-bit), but
> it didn't work.  I'll send an ACK when they're ready.

OK, I think things are all good.

ACKed-by: George Dunlap <george.dunlap@eu.citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:21:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj7U-0001lw-HZ; Tue, 24 Jan 2012 16:21:16 +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 1Rpj7T-0001lb-0L; Tue, 24 Jan 2012 16:21:15 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327422068!12358325!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 27715 invoked from network); 24 Jan 2012 16:21:08 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-6.tower-216.messagelabs.com with SMTP;
	24 Jan 2012 16:21:08 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 63BD7D34728;
	Tue, 24 Jan 2012 17:21:08 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id ks9cJEYIJ8Tf; Tue, 24 Jan 2012 17:21:05 +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 7F32ED34717;
	Tue, 24 Jan 2012 17:21:05 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: "Likarpenkov Alexander" <al@ohosting.org.ua>
Date: Tue, 24 Jan 2012 17:21:03 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<3565C625B95341E1A6C2F804B7D7D8E3@nobody>
In-Reply-To: <3565C625B95341E1A6C2F804B7D7D8E3@nobody>
MIME-Version: 1.0
Message-Id: <201201241721.04526.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	chris <tknchris@gmail.com>, djmagee@mageenet.net,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?

I'm of course deigning an answer (what a nice english word - didn't know that 
before!) - here it is:

My Hardware:

Motherboard: DX58SO
CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

Dom0 kernel: 3.3.0-rc1
Dom0 gfx: 02:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 
9500 GT] (rev a1)

DomU OS: Windows 7 64bit
DomU gfx: 03:00.0 VGA compatible controller: ATI Technologies Inc Cayman XT 
[Radeon HD 6970]


Step one: get xen working 
i'm using the current unstable, but 4.1.X was also working;

hg clone http://xenbits.xensource.com/xen-unstable.hg
make
make install 
...

Step two: Prepare your Dom0 kernel - my .config for 3.3.0-rc1 is here: 
http://pastebin.com/T74n3KVg

You need to find out your PCI-Ids to pass through - lspci does the job here;
my personal cmdline is:

ro root=/dev/sda1 ro selinux=0 xen-pciback.hide=(03:00.0)(03:00.1)(00:1d.0)
(00:1d.1)(00:1d.2)(00:1d.7) noirqdebug nouveau.modeset=1 security=apparmor

It passes through the ATI Card (3.00) and its HDMI controller (3.00.1) and one 
USB Controller (1.0 and 2.0/ EHCI and OHCI)


Step three: Configure xen DomU config: - mine is here: 
http://pastebin.com/4BJcfpw9 
(CAUTION: insert valid uuid and mac!)


Step four: Fire it up and dont be irritated by the fact that you need to do 
the initial windows setup within the VNC Screen - as soon as you install the 
Catalyst Driver and reboot you should get output on your Physical Screen 
attached to the passed through gfx card


IIRC thats it. 

Dont fiddle with GPLPV Drivers - i dont know why but the performance is worse 
with GPLPV drivers compared to "vanilla" windows drivers...

And dont try to install any soundcard (except a USB attached one) - the ac97 
device emulated by the current qemu version has no valid driver for win7-64 - 
we have to wait until upstream qemu is working with current xen, it brings a 
emulated intel-hda card.

Step five may be important, otherwise you go crazy with the emulated mouse 
within the vnc-screen: Install Synergy on domU and Dom0 ;)


Greetings and good luck!
Tobias













_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:21:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj7U-0001lw-HZ; Tue, 24 Jan 2012 16:21:16 +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 1Rpj7T-0001lb-0L; Tue, 24 Jan 2012 16:21:15 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327422068!12358325!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 27715 invoked from network); 24 Jan 2012 16:21:08 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-6.tower-216.messagelabs.com with SMTP;
	24 Jan 2012 16:21:08 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 63BD7D34728;
	Tue, 24 Jan 2012 17:21:08 +0100 (CET)
X-Virus-Scanned: by amavis at mail.vido.info
Received: from mail.vido.info ([127.0.0.1])
	by localhost (mail.vido.info [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id ks9cJEYIJ8Tf; Tue, 24 Jan 2012 17:21:05 +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 7F32ED34717;
	Tue, 24 Jan 2012 17:21:05 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: "Likarpenkov Alexander" <al@ohosting.org.ua>
Date: Tue, 24 Jan 2012 17:21:03 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<3565C625B95341E1A6C2F804B7D7D8E3@nobody>
In-Reply-To: <3565C625B95341E1A6C2F804B7D7D8E3@nobody>
MIME-Version: 1.0
Message-Id: <201201241721.04526.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	chris <tknchris@gmail.com>, djmagee@mageenet.net,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?

I'm of course deigning an answer (what a nice english word - didn't know that 
before!) - here it is:

My Hardware:

Motherboard: DX58SO
CPU: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz

Dom0 kernel: 3.3.0-rc1
Dom0 gfx: 02:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 
9500 GT] (rev a1)

DomU OS: Windows 7 64bit
DomU gfx: 03:00.0 VGA compatible controller: ATI Technologies Inc Cayman XT 
[Radeon HD 6970]


Step one: get xen working 
i'm using the current unstable, but 4.1.X was also working;

hg clone http://xenbits.xensource.com/xen-unstable.hg
make
make install 
...

Step two: Prepare your Dom0 kernel - my .config for 3.3.0-rc1 is here: 
http://pastebin.com/T74n3KVg

You need to find out your PCI-Ids to pass through - lspci does the job here;
my personal cmdline is:

ro root=/dev/sda1 ro selinux=0 xen-pciback.hide=(03:00.0)(03:00.1)(00:1d.0)
(00:1d.1)(00:1d.2)(00:1d.7) noirqdebug nouveau.modeset=1 security=apparmor

It passes through the ATI Card (3.00) and its HDMI controller (3.00.1) and one 
USB Controller (1.0 and 2.0/ EHCI and OHCI)


Step three: Configure xen DomU config: - mine is here: 
http://pastebin.com/4BJcfpw9 
(CAUTION: insert valid uuid and mac!)


Step four: Fire it up and dont be irritated by the fact that you need to do 
the initial windows setup within the VNC Screen - as soon as you install the 
Catalyst Driver and reboot you should get output on your Physical Screen 
attached to the passed through gfx card


IIRC thats it. 

Dont fiddle with GPLPV Drivers - i dont know why but the performance is worse 
with GPLPV drivers compared to "vanilla" windows drivers...

And dont try to install any soundcard (except a USB attached one) - the ac97 
device emulated by the current qemu version has no valid driver for win7-64 - 
we have to wait until upstream qemu is working with current xen, it brings a 
emulated intel-hda card.

Step five may be important, otherwise you go crazy with the emulated mouse 
within the vnc-screen: Install Synergy on domU and Dom0 ;)


Greetings and good luck!
Tobias













_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:23:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:23:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj9u-00022B-PC; Tue, 24 Jan 2012 16:23:46 +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 1Rpj9t-00021g-JI
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:23:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327422219!3156932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 24 Jan 2012 16:23:39 -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;
	24 Jan 2012 16:23:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10254992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:23: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, 24 Jan 2012 16:23: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
	1Rpj9n-0000s9-4o; Tue, 24 Jan 2012 16:23:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpj9n-00049o-3h;
	Tue, 24 Jan 2012 16:23:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.56075.92172.575268@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:23:39 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326908004.14689.296.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326908004.14689.296.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 3/9] 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 3/9] libxl: New event generation API"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > +    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);
> 
> Why a helper for deaths but not ejects?

Because the deaths function needs to be called twice, once for each of
two lists.


> > +typedef struct libxl_event_hooks {
> > +    uint64_t event_occurs_mask;
> 
> libxl_event_{wait,check} and LIBXL_EVENTMASK_ALL have an unsigned long
> mask. Are they not the same set of bits?

This is a mistake.  I'll change it to 64 everywhere.


> > + * 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.
> 
> Does anything actually guarantee that sizeof(uint64_t) >
> sizeof(intptr_t)? I'm sure it's true in practice and I'm happy to rely
> on it. Just interested.

No, nothing does.  If we port this code to a platform where pointers
are more than 64 bits, we will need to change the type of this field
(to make it be an intptr_t or some other type).

> > +libxl_ev_user = UInt(64)
> 
> The other option here would be Builtin(...) and an entry in the builtin
> table in the wrapper generator. 

As I say, that prevents the ocaml idl generator from knowing that the
type is 64 bits and so prevents it from using the right ocaml type.

> Arguably the idl could be improved by causing Number() to have a width
> field. Currently it has a signedness and width is a property of UInt but
> the latter could be pushed up the hierarchy.
> 
> You'd still end up with 
> 	FOO = Number("FOO", width=X)
> which isn't really much better.

Indeed.

> Or the ocaml generate could handle Number as the biggest int.

That's a bit wasteful.

> Hrm. None of that seems all that much better than what you have. Chalk
> it up to potential future work.

Right.


> > +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
> > +
> > +libxl_event = Struct("event",[
> > +    ("link",     libxl_ev_link,0),
> 
> This "0" == "const=False" which is the default. I don't think it is
> necessary.

This is a leftover from when there was an in-idl comment parameter.  I
will remove it.

> [...]
> > +    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> > +    if (ret) goto out;
> > 
> [...]
> > +    if (!diskws) {
> > +        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
> 
> I didn't see this getting freed on the exit path.

This is deliberate.  Why bother freeing things when the process is
about to exit.

> > +        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;
> > +    }
> 
> This is all (I think) safe for num_disks == 0 but why waste the effort?

I'm not sure I follow.  Do you think I should put an if() round it,
testing whether d_config.num_disks is nonzero ?

In which case by "effort" do you mean computer effort ?  Surely you
can't mean that because this performance detail of this code is
entirely irrelevant.  But you can't mean human effort in the code
because adding the test would be additional code to write, read,
understand and maintain ...

> Incidentally we have libxl_device_disk.removable which might be an
> opportunity to optimise? Assuming it is meaningful in that way. I think
> in reality only emulated CD-ROM devices ever generate this event but
> perhaps exposing that in the API overcomplicates things.

Optimise to save on pointless xenstore watches you mean ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:23:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:23:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpj9u-00022B-PC; Tue, 24 Jan 2012 16:23:46 +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 1Rpj9t-00021g-JI
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:23:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327422219!3156932!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5509 invoked from network); 24 Jan 2012 16:23:39 -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;
	24 Jan 2012 16:23:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10254992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:23: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, 24 Jan 2012 16:23: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
	1Rpj9n-0000s9-4o; Tue, 24 Jan 2012 16:23:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpj9n-00049o-3h;
	Tue, 24 Jan 2012 16:23:39 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.56075.92172.575268@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:23:39 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326908004.14689.296.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326908004.14689.296.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 3/9] 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 3/9] libxl: New event generation API"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > +    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);
> 
> Why a helper for deaths but not ejects?

Because the deaths function needs to be called twice, once for each of
two lists.


> > +typedef struct libxl_event_hooks {
> > +    uint64_t event_occurs_mask;
> 
> libxl_event_{wait,check} and LIBXL_EVENTMASK_ALL have an unsigned long
> mask. Are they not the same set of bits?

This is a mistake.  I'll change it to 64 everywhere.


> > + * 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.
> 
> Does anything actually guarantee that sizeof(uint64_t) >
> sizeof(intptr_t)? I'm sure it's true in practice and I'm happy to rely
> on it. Just interested.

No, nothing does.  If we port this code to a platform where pointers
are more than 64 bits, we will need to change the type of this field
(to make it be an intptr_t or some other type).

> > +libxl_ev_user = UInt(64)
> 
> The other option here would be Builtin(...) and an entry in the builtin
> table in the wrapper generator. 

As I say, that prevents the ocaml idl generator from knowing that the
type is 64 bits and so prevents it from using the right ocaml type.

> Arguably the idl could be improved by causing Number() to have a width
> field. Currently it has a signedness and width is a property of UInt but
> the latter could be pushed up the hierarchy.
> 
> You'd still end up with 
> 	FOO = Number("FOO", width=X)
> which isn't really much better.

Indeed.

> Or the ocaml generate could handle Number as the biggest int.

That's a bit wasteful.

> Hrm. None of that seems all that much better than what you have. Chalk
> it up to potential future work.

Right.


> > +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
> > +
> > +libxl_event = Struct("event",[
> > +    ("link",     libxl_ev_link,0),
> 
> This "0" == "const=False" which is the default. I don't think it is
> necessary.

This is a leftover from when there was an in-idl comment parameter.  I
will remove it.

> [...]
> > +    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> > +    if (ret) goto out;
> > 
> [...]
> > +    if (!diskws) {
> > +        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
> 
> I didn't see this getting freed on the exit path.

This is deliberate.  Why bother freeing things when the process is
about to exit.

> > +        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;
> > +    }
> 
> This is all (I think) safe for num_disks == 0 but why waste the effort?

I'm not sure I follow.  Do you think I should put an if() round it,
testing whether d_config.num_disks is nonzero ?

In which case by "effort" do you mean computer effort ?  Surely you
can't mean that because this performance detail of this code is
entirely irrelevant.  But you can't mean human effort in the code
because adding the test would be additional code to write, read,
understand and maintain ...

> Incidentally we have libxl_device_disk.removable which might be an
> opportunity to optimise? Assuming it is meaningful in that way. I think
> in reality only emulated CD-ROM devices ever generate this event but
> perhaps exposing that in the API overcomplicates things.

Optimise to save on pointless xenstore watches you mean ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:25:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjBD-0002DD-8p; Tue, 24 Jan 2012 16:25:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpjBB-0002CO-D5
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:25:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327422297!10039877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31445 invoked from network); 24 Jan 2012 16:24:58 -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;
	24 Jan 2012 16:24:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10255029"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:24: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, 24 Jan 2012 16:24: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
	1RpjB3-0000sY-Hm; Tue, 24 Jan 2012 16:24:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpjB3-0004A3-Gl;
	Tue, 24 Jan 2012 16:24:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.56153.506648.395280@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:24:57 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326908107.14689.298.camel@zakaz.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1326886420.14689.206.camel@zakaz.uk.xensource.com>
	<20246.64955.717774.909586@mariner.uk.xensource.com>
	<1326908107.14689.298.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
 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 ("Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios stubdom"):
> On Wed, 2012-01-18 at 17:13 +0000, Ian Jackson wrote:
> > I would normally prefer:
> > 
> > > +#ifndef __MINIOS__
> > >  static void write_pidfile(const char *pidfile)
> > >      stuff
> > >  }
> > > +#else
> > > +static void write_pidfile(const char *pidfile)
> > > +}
> > > +endif
> 
> Yes, I'd normally do it this way too, not sure why I wrote the other...
> 
> Only real difference is that it prevents the prototype getting out of
> sync and bit-rotting the infrequently used case if there is one.

Better that the prototype gets out of sync and you get a compiler
error, than that the prototype is updated but the little-used
implementations of the body of the function is not adjusted for new
semantics implied by new arguments ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:25:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjBD-0002DD-8p; Tue, 24 Jan 2012 16:25:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpjBB-0002CO-D5
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:25:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327422297!10039877!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31445 invoked from network); 24 Jan 2012 16:24:58 -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;
	24 Jan 2012 16:24:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,562,1320624000"; d="scan'208";a="10255029"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:24: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, 24 Jan 2012 16:24: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
	1RpjB3-0000sY-Hm; Tue, 24 Jan 2012 16:24:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpjB3-0004A3-Gl;
	Tue, 24 Jan 2012 16:24:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.56153.506648.395280@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:24:57 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326908107.14689.298.camel@zakaz.uk.xensource.com>
References: <1326302490-19428-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1326411330-7915-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1326886420.14689.206.camel@zakaz.uk.xensource.com>
	<20246.64955.717774.909586@mariner.uk.xensource.com>
	<1326908107.14689.298.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios
 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 ("Re: [Xen-devel] [PATCH 13/18] xenstored: support running in minios stubdom"):
> On Wed, 2012-01-18 at 17:13 +0000, Ian Jackson wrote:
> > I would normally prefer:
> > 
> > > +#ifndef __MINIOS__
> > >  static void write_pidfile(const char *pidfile)
> > >      stuff
> > >  }
> > > +#else
> > > +static void write_pidfile(const char *pidfile)
> > > +}
> > > +endif
> 
> Yes, I'd normally do it this way too, not sure why I wrote the other...
> 
> Only real difference is that it prevents the prototype getting out of
> sync and bit-rotting the infrequently used case if there is one.

Better that the prototype gets out of sync and you get a compiler
error, than that the prototype is updated but the little-used
implementations of the body of the function is not adjusted for new
semantics implied by new arguments ...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:34:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjKF-0002fR-DN; Tue, 24 Jan 2012 16:34:27 +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 1RpjKD-0002fJ-Uv
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:34:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327422859!10041480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2230 invoked from network); 24 Jan 2012 16:34: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;
	24 Jan 2012 16:34:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10255250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:34: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, 24 Jan 2012 16:34: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
	1RpjK7-0000vo-IT; Tue, 24 Jan 2012 16:34:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpjK7-0004VO-76;
	Tue, 24 Jan 2012 16:34:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.56714.943562.668425@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:34:18 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326967315.17599.29.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-6-git-send-email-ian.jackson@eu.citrix.com>
	<1326967315.17599.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>
Subject: Re: [Xen-devel] [PATCH 5/9] libxl: Permit multithreaded event
 waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 5/9] libxl: Permit multithreaded event waiting"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > We also need to move some variables from globals in the ctx to be
> > per-polling-thread.
> 
> I don't think this relates to this patch, just that the mention of
> multithreaded waiting brought it to mind. What are the intended
> semantics of two calls to libxl_event_wait with overlapping event masks?

You get each event exactly once, via one of the (possibly several)
suitable libxl_event_wait calls.

> Do we expect that the caller must have called the appropriate evenables
> twice such that both waits get an event (possibly discriminate via the
> predicate)?

No.  Well, I guess the caller could do that by divvying up the ev_user
space between the two calls, but it would be a very perverse thing to
do.

> Presumably we want to ensure that one of the waits doesn't sleep for
> ever.

Yes, that's what the wakeup pipe is for.

> How does this interact with events generated via the hooks mechanism? Do
> we always deliver to the explicit wait in preference?

No.  As the doc comment for libxl_event_register_callbacks says:

   * 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.

So if you ask for callbacks you don't get the events via wait.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:34:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:34:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjKF-0002fR-DN; Tue, 24 Jan 2012 16:34:27 +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 1RpjKD-0002fJ-Uv
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:34:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327422859!10041480!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2230 invoked from network); 24 Jan 2012 16:34: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;
	24 Jan 2012 16:34:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10255250"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:34: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, 24 Jan 2012 16:34: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
	1RpjK7-0000vo-IT; Tue, 24 Jan 2012 16:34:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpjK7-0004VO-76;
	Tue, 24 Jan 2012 16:34:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.56714.943562.668425@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 16:34:18 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326967315.17599.29.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-6-git-send-email-ian.jackson@eu.citrix.com>
	<1326967315.17599.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>
Subject: Re: [Xen-devel] [PATCH 5/9] libxl: Permit multithreaded event
 waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 5/9] libxl: Permit multithreaded event waiting"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > We also need to move some variables from globals in the ctx to be
> > per-polling-thread.
> 
> I don't think this relates to this patch, just that the mention of
> multithreaded waiting brought it to mind. What are the intended
> semantics of two calls to libxl_event_wait with overlapping event masks?

You get each event exactly once, via one of the (possibly several)
suitable libxl_event_wait calls.

> Do we expect that the caller must have called the appropriate evenables
> twice such that both waits get an event (possibly discriminate via the
> predicate)?

No.  Well, I guess the caller could do that by divvying up the ev_user
space between the two calls, but it would be a very perverse thing to
do.

> Presumably we want to ensure that one of the waits doesn't sleep for
> ever.

Yes, that's what the wakeup pipe is for.

> How does this interact with events generated via the hooks mechanism? Do
> we always deliver to the explicit wait in preference?

No.  As the doc comment for libxl_event_register_callbacks says:

   * 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.

So if you ask for callbacks you don't get the events via wait.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:37:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjMn-0002u4-Vi; Tue, 24 Jan 2012 16:37:05 +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 1RpjMm-0002ti-H1; Tue, 24 Jan 2012 16:37:04 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327423018!8519965!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 18434 invoked from network); 24 Jan 2012 16:36:58 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-7.tower-216.messagelabs.com with SMTP;
	24 Jan 2012 16:36:58 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id D5949D347C4;
	Tue, 24 Jan 2012 17:36:57 +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 D3FWUIcBwrOG; Tue, 24 Jan 2012 17:36:51 +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 D7D7AD34717;
	Tue, 24 Jan 2012 17:36:50 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: "Likarpenkov Alexander" <al@ohosting.org.ua>
Date: Tue, 24 Jan 2012 17:36:49 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<3565C625B95341E1A6C2F804B7D7D8E3@nobody>
In-Reply-To: <3565C625B95341E1A6C2F804B7D7D8E3@nobody>
MIME-Version: 1.0
Message-Id: <201201241736.49889.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	chris <tknchris@gmail.com>, djmagee@mageenet.net,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?


What i forgot was the cmdline for the xen hypervisor (not that important 
though):

watchdog dom0_mem=4096M dom0_max_vcpus=4 dom0_vcpus_pin 
cpufreq=xen:performance


it turned out to be a good idea to pin the vcpus not while running (with xl 
vcpu-pin) but as early as possible -  that way even a "make -j99 bzImage" 
within Dom0 doesnt really affect the DomU Performance (yes, otherwise i had the 
impression it was noticable)

Greetings again!
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:37:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:37:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjMn-0002u4-Vi; Tue, 24 Jan 2012 16:37:05 +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 1RpjMm-0002ti-H1; Tue, 24 Jan 2012 16:37:04 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327423018!8519965!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 18434 invoked from network); 24 Jan 2012 16:36:58 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-7.tower-216.messagelabs.com with SMTP;
	24 Jan 2012 16:36:58 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id D5949D347C4;
	Tue, 24 Jan 2012 17:36:57 +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 D3FWUIcBwrOG; Tue, 24 Jan 2012 17:36:51 +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 D7D7AD34717;
	Tue, 24 Jan 2012 17:36:50 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: "Likarpenkov Alexander" <al@ohosting.org.ua>
Date: Tue, 24 Jan 2012 17:36:49 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<3565C625B95341E1A6C2F804B7D7D8E3@nobody>
In-Reply-To: <3565C625B95341E1A6C2F804B7D7D8E3@nobody>
MIME-Version: 1.0
Message-Id: <201201241736.49889.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	chris <tknchris@gmail.com>, djmagee@mageenet.net,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?


What i forgot was the cmdline for the xen hypervisor (not that important 
though):

watchdog dom0_mem=4096M dom0_max_vcpus=4 dom0_vcpus_pin 
cpufreq=xen:performance


it turned out to be a good idea to pin the vcpus not while running (with xl 
vcpu-pin) but as early as possible -  that way even a "make -j99 bzImage" 
within Dom0 doesnt really affect the DomU Performance (yes, otherwise i had the 
impression it was noticable)

Greetings again!
Tobias

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:39:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjOi-0003FW-79; Tue, 24 Jan 2012 16:39: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 1RpjOg-0003Dx-8o
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:39:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327423136!12273986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8977 invoked from network); 24 Jan 2012 16:38:56 -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;
	24 Jan 2012 16:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10255379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:38: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;
	Tue, 24 Jan 2012 16:38:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Jan 2012 16:38:55 +0000
In-Reply-To: <20254.56075.92172.575268@mariner.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326908004.14689.296.camel@zakaz.uk.xensource.com>
	<20254.56075.92172.575268@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327423135.24561.208.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/9] 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, 2012-01-24 at 16:23 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 3/9] libxl: New event generation API"):
> > On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:

> > > +libxl_ev_user = UInt(64)
> > 
> > The other option here would be Builtin(...) and an entry in the builtin
> > table in the wrapper generator. 
> 
> As I say, that prevents the ocaml idl generator from knowing that the
> type is 64 bits and so prevents it from using the right ocaml type.

The ocaml type of a "builtin" is supplied by the builtin table in the
generator. However:

[...]
> > Hrm. None of that seems all that much better than what you have. Chalk
> > it up to potential future work.
> 
> Right.

ACK.

> > [...]
> > > +    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> > > +    if (ret) goto out;
> > > 
> > [...]
> > > +    if (!diskws) {
> > > +        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
> > 
> > I didn't see this getting freed on the exit path.
> 
> This is deliberate.  Why bother freeing things when the process is
> about to exit.

Usually I agree.

However xl is intended as a libxl testbed as well as a toolstack in its
own right and it is useful to be able to run tools such as valgrind on
it to detect leaks in the library, but this requires not having too many
"false positives" in xl.

> > > +        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;
> > > +    }
> > 
> > This is all (I think) safe for num_disks == 0 but why waste the effort?
> 
> I'm not sure I follow.  Do you think I should put an if() round it,
> testing whether d_config.num_disks is nonzero ?

I did but then I read the below which is entirely correct.

> In which case by "effort" do you mean computer effort ?  Surely you
> can't mean that because this performance detail of this code is
> entirely irrelevant.  But you can't mean human effort in the code
> because adding the test would be additional code to write, read,
> understand and maintain ...
> 
> > Incidentally we have libxl_device_disk.removable which might be an
> > opportunity to optimise? Assuming it is meaningful in that way. I think
> > in reality only emulated CD-ROM devices ever generate this event but
> > perhaps exposing that in the API overcomplicates things.
> 
> Optimise to save on pointless xenstore watches you mean ?

That and event overhead generally of having the events registered and
being tracked etc. In the common case we probably have 1 disk and 1
cdrom so we've effectively doubled the amount of stuff we're dealing
with -- whether this becomes significant e.g. on a system with 100+ VMs
I'm not sure.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:39:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:39:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjOi-0003FW-79; Tue, 24 Jan 2012 16:39: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 1RpjOg-0003Dx-8o
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:39:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327423136!12273986!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8977 invoked from network); 24 Jan 2012 16:38:56 -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;
	24 Jan 2012 16:38:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10255379"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:38: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;
	Tue, 24 Jan 2012 16:38:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 24 Jan 2012 16:38:55 +0000
In-Reply-To: <20254.56075.92172.575268@mariner.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326908004.14689.296.camel@zakaz.uk.xensource.com>
	<20254.56075.92172.575268@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327423135.24561.208.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/9] 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, 2012-01-24 at 16:23 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 3/9] libxl: New event generation API"):
> > On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:

> > > +libxl_ev_user = UInt(64)
> > 
> > The other option here would be Builtin(...) and an entry in the builtin
> > table in the wrapper generator. 
> 
> As I say, that prevents the ocaml idl generator from knowing that the
> type is 64 bits and so prevents it from using the right ocaml type.

The ocaml type of a "builtin" is supplied by the builtin table in the
generator. However:

[...]
> > Hrm. None of that seems all that much better than what you have. Chalk
> > it up to potential future work.
> 
> Right.

ACK.

> > [...]
> > > +    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
> > > +    if (ret) goto out;
> > > 
> > [...]
> > > +    if (!diskws) {
> > > +        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
> > 
> > I didn't see this getting freed on the exit path.
> 
> This is deliberate.  Why bother freeing things when the process is
> about to exit.

Usually I agree.

However xl is intended as a libxl testbed as well as a toolstack in its
own right and it is useful to be able to run tools such as valgrind on
it to detect leaks in the library, but this requires not having too many
"false positives" in xl.

> > > +        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;
> > > +    }
> > 
> > This is all (I think) safe for num_disks == 0 but why waste the effort?
> 
> I'm not sure I follow.  Do you think I should put an if() round it,
> testing whether d_config.num_disks is nonzero ?

I did but then I read the below which is entirely correct.

> In which case by "effort" do you mean computer effort ?  Surely you
> can't mean that because this performance detail of this code is
> entirely irrelevant.  But you can't mean human effort in the code
> because adding the test would be additional code to write, read,
> understand and maintain ...
> 
> > Incidentally we have libxl_device_disk.removable which might be an
> > opportunity to optimise? Assuming it is meaningful in that way. I think
> > in reality only emulated CD-ROM devices ever generate this event but
> > perhaps exposing that in the API overcomplicates things.
> 
> Optimise to save on pointless xenstore watches you mean ?

That and event overhead generally of having the events registered and
being tracked etc. In the common case we probably have 1 disk and 1
cdrom so we've effectively doubled the amount of stuff we're dealing
with -- whether this becomes significant e.g. on a system with 100+ VMs
I'm not sure.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:42:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjRY-0003ai-2J; Tue, 24 Jan 2012 16:42:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpjRX-0003aQ-5D
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:41:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327423313!12190104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31961 invoked from network); 24 Jan 2012 16:41:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:41:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10255444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:41: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;
	Tue, 24 Jan 2012 16:41:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Tue, 24 Jan 2012 16:41:52 +0000
In-Reply-To: <1327420611.19936.140661027415609@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327423312.24561.211.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 15:56 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> > Does "ifconfig -a" in dom0 show a vifX.Y device for the domain? You previous xenstore log
> > suggests it should be there but lets double check.
> 
> edit /etc/xen/scripts/vif-bridge
> 	#!/bin/bash
> +       exec 1>>/tmp/hotplog.log
> +       exec 2>&1
> +       echo "`date`: Running $0 $*"
> 
> xl create test.cfg
> 
> 
> ifconfig -a
> brINT     Link encap:Ethernet  HWaddr 00:52:35:11:26:3B

brINT is not the name you've been quoting before (which was br0). Are
you running these tests on a variety of different systems with different
configurations?

It would be really helpful for those of us trying to help you if you
could use the same system with the same setup (modulo requested changes)
for the entirety of this conversation. Otherwise it becomes rather hard
for us to correlate the facts.

In this case I now have to ask if you are sure that you used the
appropriate "bridge=brINT" in your guest configuration instead of
"bridge=br0" which you had before.

[...]
> vif7.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF

Good that this exists.

> > Do you get anything in the logs under /var/log/xen?
> 
> Just this after the Guest launches.  It looks a bit suspect maybe?
> 
> cat /var/log/xen/*log
>  domid: 7
>  Warning: vlan 0 is not connected to host network
>  -videoram option does not work with cirrus vga device model. Videoram
>  set to 4M.
>  /home/abuild/rpmbuild/BUILD/xen-4.1.2-testing/tools/ioemu-dir/hw/xen_blktap.c:704:
>  Init blktap pipes
>  Could not open /var/run/tap/qemu-read-7
>  char device redirected to /dev/pts/1
>  xs_read(): target get error. /local/domain/7/target.
>  xs_read(): vncpasswd get error.
>  /vm/22eef8a2-7b68-4bb6-a69f-632d20db0d84/vncpasswd.
>  Waiting for domain test (domid 7) to die [pid 28807]

These are the logs for the qemu process which is serving as your vfb
backend. These all look reasonably normal (in the sense that all this
pointless noise is normal).

> > Are your hotplug scripts running at all? ...
> 
> cat /tmp/hotplog.log
>  Tue Jan 24 07:23:49 PST 2012: Running /etc/xen/scripts/vif-bridge
>  online type_if=vif
>  Tue Jan 24 07:23:49 PST 2012: Running /etc/xen/scripts/vif-bridge
>  online

So the hotplug script is running without any apparent error, at least
not one that was logged.

At this point I'm afraid my only suggesting is to drop "echo made it to
XXX" breadcrumbs throughout the script and try to narrow down to the
line which exits.

You could also perhaps run "udevadm monitor" in another window while
starting the guest, so wee can see what events you are actually seeing.

[...]
> cat /var/log/xeb/console/*
>  cat: /var/log/xeb/console/*: No such file or directory

Obviously a typo, but there's probably not too much of interest in the
guest console logs.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:42:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjRY-0003ai-2J; Tue, 24 Jan 2012 16:42:00 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpjRX-0003aQ-5D
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:41:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327423313!12190104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31961 invoked from network); 24 Jan 2012 16:41:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 16:41:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10255444"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 16:41: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;
	Tue, 24 Jan 2012 16:41:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Tue, 24 Jan 2012 16:41:52 +0000
In-Reply-To: <1327420611.19936.140661027415609@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327423312.24561.211.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 15:56 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> > Does "ifconfig -a" in dom0 show a vifX.Y device for the domain? You previous xenstore log
> > suggests it should be there but lets double check.
> 
> edit /etc/xen/scripts/vif-bridge
> 	#!/bin/bash
> +       exec 1>>/tmp/hotplog.log
> +       exec 2>&1
> +       echo "`date`: Running $0 $*"
> 
> xl create test.cfg
> 
> 
> ifconfig -a
> brINT     Link encap:Ethernet  HWaddr 00:52:35:11:26:3B

brINT is not the name you've been quoting before (which was br0). Are
you running these tests on a variety of different systems with different
configurations?

It would be really helpful for those of us trying to help you if you
could use the same system with the same setup (modulo requested changes)
for the entirety of this conversation. Otherwise it becomes rather hard
for us to correlate the facts.

In this case I now have to ask if you are sure that you used the
appropriate "bridge=brINT" in your guest configuration instead of
"bridge=br0" which you had before.

[...]
> vif7.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF

Good that this exists.

> > Do you get anything in the logs under /var/log/xen?
> 
> Just this after the Guest launches.  It looks a bit suspect maybe?
> 
> cat /var/log/xen/*log
>  domid: 7
>  Warning: vlan 0 is not connected to host network
>  -videoram option does not work with cirrus vga device model. Videoram
>  set to 4M.
>  /home/abuild/rpmbuild/BUILD/xen-4.1.2-testing/tools/ioemu-dir/hw/xen_blktap.c:704:
>  Init blktap pipes
>  Could not open /var/run/tap/qemu-read-7
>  char device redirected to /dev/pts/1
>  xs_read(): target get error. /local/domain/7/target.
>  xs_read(): vncpasswd get error.
>  /vm/22eef8a2-7b68-4bb6-a69f-632d20db0d84/vncpasswd.
>  Waiting for domain test (domid 7) to die [pid 28807]

These are the logs for the qemu process which is serving as your vfb
backend. These all look reasonably normal (in the sense that all this
pointless noise is normal).

> > Are your hotplug scripts running at all? ...
> 
> cat /tmp/hotplog.log
>  Tue Jan 24 07:23:49 PST 2012: Running /etc/xen/scripts/vif-bridge
>  online type_if=vif
>  Tue Jan 24 07:23:49 PST 2012: Running /etc/xen/scripts/vif-bridge
>  online

So the hotplug script is running without any apparent error, at least
not one that was logged.

At this point I'm afraid my only suggesting is to drop "echo made it to
XXX" breadcrumbs throughout the script and try to narrow down to the
line which exits.

You could also perhaps run "udevadm monitor" in another window while
starting the guest, so wee can see what events you are actually seeing.

[...]
> cat /var/log/xeb/console/*
>  cat: /var/log/xeb/console/*: No such file or directory

Obviously a typo, but there's probably not too much of interest in the
guest console logs.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:44:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjTI-0003jy-JE; Tue, 24 Jan 2012 16:43: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 1RpjTG-0003jc-MY
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:43:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327423419!8431582!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25543 invoked from network); 24 Jan 2012 16:43:39 -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; 24 Jan 2012 16:43:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 16:43:39 +0000
Message-Id: <4F1EEE13020000780006EB28@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 16:44: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="=__PartCAE49613.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/xenoprof: consolidate read/write
 of active/passive domain IDs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartCAE49613.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This doesn't just fold redundant code, but also fixes the potential for
a buffer overrun: While active_domains[] was properly sized (matching
the main loop in adomain_write()), passive_domains[] was declared one
entry too short.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/oprofile/oprofile_files.c
+++ b/drivers/oprofile/oprofile_files.c
@@ -126,13 +126,22 @@ static const struct file_operations dump
=20
 #define TMPBUFSIZE 512
=20
-static unsigned int adomains =3D 0;
-static int active_domains[MAX_OPROF_DOMAINS + 1];
-static DEFINE_MUTEX(adom_mutex);
+struct domain_data {
+    unsigned int nr;
+    int ids[MAX_OPROF_DOMAINS + 1];
+    struct mutex mutex;
+    int (*set)(int[], unsigned int);
+};
+#define DEFINE_DOMAIN_DATA(what) \
+	struct domain_data what##_domains =3D { \
+		.mutex =3D __MUTEX_INITIALIZER(what##_domains.mutex), \
+		.set =3D oprofile_set_##what \
+	}
=20
-static ssize_t adomain_write(struct file * file, char const __user * =
buf,=20
-			     size_t count, loff_t * offset)
+static ssize_t domain_write(struct file *filp, char const __user *buf,
+			    size_t count, loff_t *offset)
 {
+	struct domain_data *dom =3D filp->private_data;
 	char *tmpbuf;
 	char *startp, *endp;
 	int i;
@@ -153,7 +162,7 @@ static ssize_t adomain_write(struct file
 	}
 	tmpbuf[count] =3D 0;
=20
-	mutex_lock(&adom_mutex);
+	mutex_lock(&dom->mutex);
=20
 	startp =3D tmpbuf;
 	/* Parse one more than MAX_OPROF_DOMAINS, for easy error checking =
*/
@@ -163,31 +172,32 @@ static ssize_t adomain_write(struct file
 			break;
 		while (ispunct(*endp) || isspace(*endp))
 			endp++;
-		active_domains[i] =3D val;
-		if (active_domains[i] !=3D val)
+		dom->ids[i] =3D val;
+		if (dom->ids[i] !=3D val)
 			/* Overflow, force error below */
 			i =3D MAX_OPROF_DOMAINS + 1;
 		startp =3D endp;
 	}
 	/* Force error on trailing junk */
-	adomains =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;
+	dom->nr =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;
=20
 	kfree(tmpbuf);
=20
-	if (adomains > MAX_OPROF_DOMAINS
-	    || oprofile_set_active(active_domains, adomains)) {
-		adomains =3D 0;
+	if (dom->nr > MAX_OPROF_DOMAINS
+	    || dom->set(dom->ids, dom->nr)) {
+		dom->nr =3D 0;
 		retval =3D -EINVAL;
 	}
=20
-	mutex_unlock(&adom_mutex);
+	mutex_unlock(&dom->mutex);
 	return retval;
 }
=20
-static ssize_t adomain_read(struct file * file, char __user * buf,=20
-			    size_t count, loff_t * offset)
+static ssize_t domain_read(struct file *filp, char __user *buf,
+			    size_t count, loff_t *offset)
 {
-	char * tmpbuf;
+	struct domain_data *dom =3D filp->private_data;
+	char *tmpbuf;
 	size_t len;
 	int i;
 	ssize_t retval;
@@ -195,18 +205,18 @@ static ssize_t adomain_read(struct file=20
 	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))
 		return -ENOMEM;
=20
-	mutex_lock(&adom_mutex);
+	mutex_lock(&dom->mutex);
=20
 	len =3D 0;
-	for (i =3D 0; i < adomains; i++)
+	for (i =3D 0; i < dom->nr; i++)
 		len +=3D snprintf(tmpbuf + len,
 				len < TMPBUFSIZE ? TMPBUFSIZE - len : 0,
-				"%u ", active_domains[i]);
+				"%u ", dom->ids[i]);
 	WARN_ON(len > TMPBUFSIZE);
 	if (len !=3D 0 && len <=3D TMPBUFSIZE)
 		tmpbuf[len-1] =3D '\n';
=20
-	mutex_unlock(&adom_mutex);
+	mutex_unlock(&dom->mutex);
=20
 	retval =3D simple_read_from_buffer(buf, count, offset, tmpbuf, =
len);
=20
@@ -214,103 +224,32 @@ static ssize_t adomain_read(struct file=20
 	return retval;
 }
=20
+static DEFINE_DOMAIN_DATA(active);
=20
-static const struct file_operations active_domain_ops =3D {
-	.read		=3D adomain_read,
-	.write		=3D adomain_write,
-};
-
-static unsigned int pdomains =3D 0;
-static int passive_domains[MAX_OPROF_DOMAINS];
-static DEFINE_MUTEX(pdom_mutex);
-
-static ssize_t pdomain_write(struct file * file, char const __user * =
buf,=20
-			     size_t count, loff_t * offset)
+static int adomain_open(struct inode *inode, struct file *filp)
 {
-	char *tmpbuf;
-	char *startp, *endp;
-	int i;
-	unsigned long val;
-	ssize_t retval =3D count;
-=09
-	if (*offset)
-		return -EINVAL;=09
-	if (count > TMPBUFSIZE - 1)
-		return -EINVAL;
-
-	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))
-		return -ENOMEM;
-
-	if (copy_from_user(tmpbuf, buf, count)) {
-		kfree(tmpbuf);
-		return -EFAULT;
-	}
-	tmpbuf[count] =3D 0;
-
-	mutex_lock(&pdom_mutex);
-
-	startp =3D tmpbuf;
-	/* Parse one more than MAX_OPROF_DOMAINS, for easy error checking =
*/
-	for (i =3D 0; i <=3D MAX_OPROF_DOMAINS; i++) {
-		val =3D simple_strtoul(startp, &endp, 0);
-		if (endp =3D=3D startp)
-			break;
-		while (ispunct(*endp) || isspace(*endp))
-			endp++;
-		passive_domains[i] =3D val;
-		if (passive_domains[i] !=3D val)
-			/* Overflow, force error below */
-			i =3D MAX_OPROF_DOMAINS + 1;
-		startp =3D endp;
-	}
-	/* Force error on trailing junk */
-	pdomains =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;
-
-	kfree(tmpbuf);
-
-	if (pdomains > MAX_OPROF_DOMAINS
-	    || oprofile_set_passive(passive_domains, pdomains)) {
-		pdomains =3D 0;
-		retval =3D -EINVAL;
-	}
-
-	mutex_unlock(&pdom_mutex);
-	return retval;
+    filp->private_data =3D &active_domains;
+    return 0;
 }
=20
-static ssize_t pdomain_read(struct file * file, char __user * buf,=20
-			    size_t count, loff_t * offset)
-{
-	char * tmpbuf;
-	size_t len;
-	int i;
-	ssize_t retval;
-
-	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))
-		return -ENOMEM;
-
-	mutex_lock(&pdom_mutex);
-
-	len =3D 0;
-	for (i =3D 0; i < pdomains; i++)
-		len +=3D snprintf(tmpbuf + len,
-				len < TMPBUFSIZE ? TMPBUFSIZE - len : 0,
-				"%u ", passive_domains[i]);
-	WARN_ON(len > TMPBUFSIZE);
-	if (len !=3D 0 && len <=3D TMPBUFSIZE)
-		tmpbuf[len-1] =3D '\n';
-
-	mutex_unlock(&pdom_mutex);
+static const struct file_operations active_domain_ops =3D {
+	.open		=3D adomain_open,
+	.read		=3D domain_read,
+	.write		=3D domain_write,
+};
=20
-	retval =3D simple_read_from_buffer(buf, count, offset, tmpbuf, =
len);
+static DEFINE_DOMAIN_DATA(passive);
=20
-	kfree(tmpbuf);
-	return retval;
+static int pdomain_open(struct inode *inode, struct file *filp)
+{
+    filp->private_data =3D &passive_domains;
+    return 0;
 }
=20
 static const struct file_operations passive_domain_ops =3D {
-	.read		=3D pdomain_read,
-	.write		=3D pdomain_write,
+	.open		=3D pdomain_open,
+	.read		=3D domain_read,
+	.write		=3D domain_write,
 };
=20
 void oprofile_create_files(struct super_block * sb, struct dentry * root)



--=__PartCAE49613.0__=
Content-Type: text/plain; name="xen-oprofile-files.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-oprofile-files.patch"

xenoprof: consolidate read/write of active/passive domain IDs=0A=0AThis =
doesn't just fold redundant code, but also fixes the potential for=0Aa =
buffer overrun: While active_domains[] was properly sized (matching=0Athe =
main loop in adomain_write()), passive_domains[] was declared one=0Aentry =
too short.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/oprofile/oprofile_files.c=0A+++ b/drivers/oprofile/oprofile_files=
.c=0A@@ -126,13 +126,22 @@ static const struct file_operations dump=0A =0A =
#define TMPBUFSIZE 512=0A =0A-static unsigned int adomains =3D 0;=0A-static=
 int active_domains[MAX_OPROF_DOMAINS + 1];=0A-static DEFINE_MUTEX(adom_mut=
ex);=0A+struct domain_data {=0A+    unsigned int nr;=0A+    int ids[MAX_OPR=
OF_DOMAINS + 1];=0A+    struct mutex mutex;=0A+    int (*set)(int[], =
unsigned int);=0A+};=0A+#define DEFINE_DOMAIN_DATA(what) \=0A+	struct =
domain_data what##_domains =3D { \=0A+		.mutex =3D __MUTEX_INITIALI=
ZER(what##_domains.mutex), \=0A+		.set =3D oprofile_set_##wha=
t \=0A+	}=0A =0A-static ssize_t adomain_write(struct file * file, char =
const __user * buf, =0A-			     size_t count, loff_t =
* offset)=0A+static ssize_t domain_write(struct file *filp, char const =
__user *buf,=0A+			    size_t count, loff_t =
*offset)=0A {=0A+	struct domain_data *dom =3D filp->private_data;=0A =
	char *tmpbuf;=0A 	char *startp, *endp;=0A 	int =
i;=0A@@ -153,7 +162,7 @@ static ssize_t adomain_write(struct file=0A 	=
}=0A 	tmpbuf[count] =3D 0;=0A =0A-	mutex_lock(&adom_mutex);=0A+	=
mutex_lock(&dom->mutex);=0A =0A 	startp =3D tmpbuf;=0A 	/* Parse =
one more than MAX_OPROF_DOMAINS, for easy error checking */=0A@@ -163,31 =
+172,32 @@ static ssize_t adomain_write(struct file=0A 			=
break;=0A 		while (ispunct(*endp) || isspace(*endp))=0A 		=
	endp++;=0A-		active_domains[i] =3D val;=0A-		if =
(active_domains[i] !=3D val)=0A+		dom->ids[i] =3D val;=0A+	=
	if (dom->ids[i] !=3D val)=0A 			/* Overflow, force =
error below */=0A 			i =3D MAX_OPROF_DOMAINS + 1;=0A 	=
	startp =3D endp;=0A 	}=0A 	/* Force error on trailing junk =
*/=0A-	adomains =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;=0A+	dom->nr =
=3D *startp ? MAX_OPROF_DOMAINS + 1 : i;=0A =0A 	kfree(tmpbuf);=0A =
=0A-	if (adomains > MAX_OPROF_DOMAINS=0A-	    || oprofile_set_active(=
active_domains, adomains)) {=0A-		adomains =3D 0;=0A+	if =
(dom->nr > MAX_OPROF_DOMAINS=0A+	    || dom->set(dom->ids, =
dom->nr)) {=0A+		dom->nr =3D 0;=0A 		retval =3D =
-EINVAL;=0A 	}=0A =0A-	mutex_unlock(&adom_mutex);=0A+	mutex_unloc=
k(&dom->mutex);=0A 	return retval;=0A }=0A =0A-static ssize_t =
adomain_read(struct file * file, char __user * buf, =0A-			=
    size_t count, loff_t * offset)=0A+static ssize_t domain_read(struct =
file *filp, char __user *buf,=0A+			    size_t count, =
loff_t *offset)=0A {=0A-	char * tmpbuf;=0A+	struct domain_data =
*dom =3D filp->private_data;=0A+	char *tmpbuf;=0A 	size_t =
len;=0A 	int i;=0A 	ssize_t retval;=0A@@ -195,18 +205,18 @@ =
static ssize_t adomain_read(struct file =0A 	if (!(tmpbuf =3D kmalloc(TM=
PBUFSIZE, GFP_KERNEL)))=0A 		return -ENOMEM;=0A =0A-	mutex_lock(=
&adom_mutex);=0A+	mutex_lock(&dom->mutex);=0A =0A 	len =3D =
0;=0A-	for (i =3D 0; i < adomains; i++)=0A+	for (i =3D 0; i < dom->nr; =
i++)=0A 		len +=3D snprintf(tmpbuf + len,=0A 			=
	len < TMPBUFSIZE ? TMPBUFSIZE - len : 0,=0A-				=
"%u ", active_domains[i]);=0A+				"%u ", dom->ids[i])=
;=0A 	WARN_ON(len > TMPBUFSIZE);=0A 	if (len !=3D 0 && len <=3D =
TMPBUFSIZE)=0A 		tmpbuf[len-1] =3D '\n';=0A =0A-	mutex_unlock(&adom_=
mutex);=0A+	mutex_unlock(&dom->mutex);=0A =0A 	retval =3D =
simple_read_from_buffer(buf, count, offset, tmpbuf, len);=0A =0A@@ =
-214,103 +224,32 @@ static ssize_t adomain_read(struct file =0A 	=
return retval;=0A }=0A =0A+static DEFINE_DOMAIN_DATA(active);=0A =0A-static=
 const struct file_operations active_domain_ops =3D {=0A-	.read		=
=3D adomain_read,=0A-	.write		=3D adomain_write,=0A-};=0A-=0A-sta=
tic unsigned int pdomains =3D 0;=0A-static int passive_domains[MAX_OPROF_DO=
MAINS];=0A-static DEFINE_MUTEX(pdom_mutex);=0A-=0A-static ssize_t =
pdomain_write(struct file * file, char const __user * buf, =0A-			=
     size_t count, loff_t * offset)=0A+static int adomain_open(struct =
inode *inode, struct file *filp)=0A {=0A-	char *tmpbuf;=0A-	=
char *startp, *endp;=0A-	int i;=0A-	unsigned long val;=0A-	=
ssize_t retval =3D count;=0A-	=0A-	if (*offset)=0A-		=
return -EINVAL;	=0A-	if (count > TMPBUFSIZE - 1)=0A-		return =
-EINVAL;=0A-=0A-	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))=
=0A-		return -ENOMEM;=0A-=0A-	if (copy_from_user(tmpbuf, buf, =
count)) {=0A-		kfree(tmpbuf);=0A-		return -EFAULT;=0A-=
	}=0A-	tmpbuf[count] =3D 0;=0A-=0A-	mutex_lock(&pdom_mutex);=0A=
-=0A-	startp =3D tmpbuf;=0A-	/* Parse one more than MAX_OPROF_DOMAINS, =
for easy error checking */=0A-	for (i =3D 0; i <=3D MAX_OPROF_DOMAINS; =
i++) {=0A-		val =3D simple_strtoul(startp, &endp, 0);=0A-		=
if (endp =3D=3D startp)=0A-			break;=0A-		=
while (ispunct(*endp) || isspace(*endp))=0A-			endp++;=0A-=
		passive_domains[i] =3D val;=0A-		if (passive_domains=
[i] !=3D val)=0A-			/* Overflow, force error below =
*/=0A-			i =3D MAX_OPROF_DOMAINS + 1;=0A-		=
startp =3D endp;=0A-	}=0A-	/* Force error on trailing junk */=0A-	=
pdomains =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;=0A-=0A-	kfree(tmpbu=
f);=0A-=0A-	if (pdomains > MAX_OPROF_DOMAINS=0A-	    || oprofile_set=
_passive(passive_domains, pdomains)) {=0A-		pdomains =3D =
0;=0A-		retval =3D -EINVAL;=0A-	}=0A-=0A-	mutex_unlock(&pdom_=
mutex);=0A-	return retval;=0A+    filp->private_data =3D &active_domain=
s;=0A+    return 0;=0A }=0A =0A-static ssize_t pdomain_read(struct file * =
file, char __user * buf, =0A-			    size_t count, loff_t * =
offset)=0A-{=0A-	char * tmpbuf;=0A-	size_t len;=0A-	int i;=0A-	=
ssize_t retval;=0A-=0A-	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))=
=0A-		return -ENOMEM;=0A-=0A-	mutex_lock(&pdom_mutex);=0A-=0A-	=
len =3D 0;=0A-	for (i =3D 0; i < pdomains; i++)=0A-		len +=3D =
snprintf(tmpbuf + len,=0A-				len < TMPBUFSIZE ? =
TMPBUFSIZE - len : 0,=0A-				"%u ", passive_doma=
ins[i]);=0A-	WARN_ON(len > TMPBUFSIZE);=0A-	if (len !=3D 0 && len <=3D =
TMPBUFSIZE)=0A-		tmpbuf[len-1] =3D '\n';=0A-=0A-	mutex_unlock(&pdom_=
mutex);=0A+static const struct file_operations active_domain_ops =3D {=0A+	=
.open		=3D adomain_open,=0A+	.read		=3D domain_read,=0A=
+	.write		=3D domain_write,=0A+};=0A =0A-	retval =3D =
simple_read_from_buffer(buf, count, offset, tmpbuf, len);=0A+static =
DEFINE_DOMAIN_DATA(passive);=0A =0A-	kfree(tmpbuf);=0A-	return =
retval;=0A+static int pdomain_open(struct inode *inode, struct file =
*filp)=0A+{=0A+    filp->private_data =3D &passive_domains;=0A+    return =
0;=0A }=0A =0A static const struct file_operations passive_domain_ops =3D =
{=0A-	.read		=3D pdomain_read,=0A-	.write		=3D =
pdomain_write,=0A+	.open		=3D pdomain_open,=0A+	.read		=
=3D domain_read,=0A+	.write		=3D domain_write,=0A };=0A =0A =
void oprofile_create_files(struct super_block * sb, struct dentry * =
root)=0A
--=__PartCAE49613.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

--=__PartCAE49613.0__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:44:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:44:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjTI-0003jy-JE; Tue, 24 Jan 2012 16:43: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 1RpjTG-0003jc-MY
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:43:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327423419!8431582!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25543 invoked from network); 24 Jan 2012 16:43:39 -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; 24 Jan 2012 16:43:39 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 24 Jan 2012 16:43:39 +0000
Message-Id: <4F1EEE13020000780006EB28@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 24 Jan 2012 16:44: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="=__PartCAE49613.0__="
Subject: [Xen-devel] [PATCH] linux-2.6.18/xenoprof: consolidate read/write
 of active/passive domain IDs
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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.

--=__PartCAE49613.0__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

This doesn't just fold redundant code, but also fixes the potential for
a buffer overrun: While active_domains[] was properly sized (matching
the main loop in adomain_write()), passive_domains[] was declared one
entry too short.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/drivers/oprofile/oprofile_files.c
+++ b/drivers/oprofile/oprofile_files.c
@@ -126,13 +126,22 @@ static const struct file_operations dump
=20
 #define TMPBUFSIZE 512
=20
-static unsigned int adomains =3D 0;
-static int active_domains[MAX_OPROF_DOMAINS + 1];
-static DEFINE_MUTEX(adom_mutex);
+struct domain_data {
+    unsigned int nr;
+    int ids[MAX_OPROF_DOMAINS + 1];
+    struct mutex mutex;
+    int (*set)(int[], unsigned int);
+};
+#define DEFINE_DOMAIN_DATA(what) \
+	struct domain_data what##_domains =3D { \
+		.mutex =3D __MUTEX_INITIALIZER(what##_domains.mutex), \
+		.set =3D oprofile_set_##what \
+	}
=20
-static ssize_t adomain_write(struct file * file, char const __user * =
buf,=20
-			     size_t count, loff_t * offset)
+static ssize_t domain_write(struct file *filp, char const __user *buf,
+			    size_t count, loff_t *offset)
 {
+	struct domain_data *dom =3D filp->private_data;
 	char *tmpbuf;
 	char *startp, *endp;
 	int i;
@@ -153,7 +162,7 @@ static ssize_t adomain_write(struct file
 	}
 	tmpbuf[count] =3D 0;
=20
-	mutex_lock(&adom_mutex);
+	mutex_lock(&dom->mutex);
=20
 	startp =3D tmpbuf;
 	/* Parse one more than MAX_OPROF_DOMAINS, for easy error checking =
*/
@@ -163,31 +172,32 @@ static ssize_t adomain_write(struct file
 			break;
 		while (ispunct(*endp) || isspace(*endp))
 			endp++;
-		active_domains[i] =3D val;
-		if (active_domains[i] !=3D val)
+		dom->ids[i] =3D val;
+		if (dom->ids[i] !=3D val)
 			/* Overflow, force error below */
 			i =3D MAX_OPROF_DOMAINS + 1;
 		startp =3D endp;
 	}
 	/* Force error on trailing junk */
-	adomains =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;
+	dom->nr =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;
=20
 	kfree(tmpbuf);
=20
-	if (adomains > MAX_OPROF_DOMAINS
-	    || oprofile_set_active(active_domains, adomains)) {
-		adomains =3D 0;
+	if (dom->nr > MAX_OPROF_DOMAINS
+	    || dom->set(dom->ids, dom->nr)) {
+		dom->nr =3D 0;
 		retval =3D -EINVAL;
 	}
=20
-	mutex_unlock(&adom_mutex);
+	mutex_unlock(&dom->mutex);
 	return retval;
 }
=20
-static ssize_t adomain_read(struct file * file, char __user * buf,=20
-			    size_t count, loff_t * offset)
+static ssize_t domain_read(struct file *filp, char __user *buf,
+			    size_t count, loff_t *offset)
 {
-	char * tmpbuf;
+	struct domain_data *dom =3D filp->private_data;
+	char *tmpbuf;
 	size_t len;
 	int i;
 	ssize_t retval;
@@ -195,18 +205,18 @@ static ssize_t adomain_read(struct file=20
 	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))
 		return -ENOMEM;
=20
-	mutex_lock(&adom_mutex);
+	mutex_lock(&dom->mutex);
=20
 	len =3D 0;
-	for (i =3D 0; i < adomains; i++)
+	for (i =3D 0; i < dom->nr; i++)
 		len +=3D snprintf(tmpbuf + len,
 				len < TMPBUFSIZE ? TMPBUFSIZE - len : 0,
-				"%u ", active_domains[i]);
+				"%u ", dom->ids[i]);
 	WARN_ON(len > TMPBUFSIZE);
 	if (len !=3D 0 && len <=3D TMPBUFSIZE)
 		tmpbuf[len-1] =3D '\n';
=20
-	mutex_unlock(&adom_mutex);
+	mutex_unlock(&dom->mutex);
=20
 	retval =3D simple_read_from_buffer(buf, count, offset, tmpbuf, =
len);
=20
@@ -214,103 +224,32 @@ static ssize_t adomain_read(struct file=20
 	return retval;
 }
=20
+static DEFINE_DOMAIN_DATA(active);
=20
-static const struct file_operations active_domain_ops =3D {
-	.read		=3D adomain_read,
-	.write		=3D adomain_write,
-};
-
-static unsigned int pdomains =3D 0;
-static int passive_domains[MAX_OPROF_DOMAINS];
-static DEFINE_MUTEX(pdom_mutex);
-
-static ssize_t pdomain_write(struct file * file, char const __user * =
buf,=20
-			     size_t count, loff_t * offset)
+static int adomain_open(struct inode *inode, struct file *filp)
 {
-	char *tmpbuf;
-	char *startp, *endp;
-	int i;
-	unsigned long val;
-	ssize_t retval =3D count;
-=09
-	if (*offset)
-		return -EINVAL;=09
-	if (count > TMPBUFSIZE - 1)
-		return -EINVAL;
-
-	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))
-		return -ENOMEM;
-
-	if (copy_from_user(tmpbuf, buf, count)) {
-		kfree(tmpbuf);
-		return -EFAULT;
-	}
-	tmpbuf[count] =3D 0;
-
-	mutex_lock(&pdom_mutex);
-
-	startp =3D tmpbuf;
-	/* Parse one more than MAX_OPROF_DOMAINS, for easy error checking =
*/
-	for (i =3D 0; i <=3D MAX_OPROF_DOMAINS; i++) {
-		val =3D simple_strtoul(startp, &endp, 0);
-		if (endp =3D=3D startp)
-			break;
-		while (ispunct(*endp) || isspace(*endp))
-			endp++;
-		passive_domains[i] =3D val;
-		if (passive_domains[i] !=3D val)
-			/* Overflow, force error below */
-			i =3D MAX_OPROF_DOMAINS + 1;
-		startp =3D endp;
-	}
-	/* Force error on trailing junk */
-	pdomains =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;
-
-	kfree(tmpbuf);
-
-	if (pdomains > MAX_OPROF_DOMAINS
-	    || oprofile_set_passive(passive_domains, pdomains)) {
-		pdomains =3D 0;
-		retval =3D -EINVAL;
-	}
-
-	mutex_unlock(&pdom_mutex);
-	return retval;
+    filp->private_data =3D &active_domains;
+    return 0;
 }
=20
-static ssize_t pdomain_read(struct file * file, char __user * buf,=20
-			    size_t count, loff_t * offset)
-{
-	char * tmpbuf;
-	size_t len;
-	int i;
-	ssize_t retval;
-
-	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))
-		return -ENOMEM;
-
-	mutex_lock(&pdom_mutex);
-
-	len =3D 0;
-	for (i =3D 0; i < pdomains; i++)
-		len +=3D snprintf(tmpbuf + len,
-				len < TMPBUFSIZE ? TMPBUFSIZE - len : 0,
-				"%u ", passive_domains[i]);
-	WARN_ON(len > TMPBUFSIZE);
-	if (len !=3D 0 && len <=3D TMPBUFSIZE)
-		tmpbuf[len-1] =3D '\n';
-
-	mutex_unlock(&pdom_mutex);
+static const struct file_operations active_domain_ops =3D {
+	.open		=3D adomain_open,
+	.read		=3D domain_read,
+	.write		=3D domain_write,
+};
=20
-	retval =3D simple_read_from_buffer(buf, count, offset, tmpbuf, =
len);
+static DEFINE_DOMAIN_DATA(passive);
=20
-	kfree(tmpbuf);
-	return retval;
+static int pdomain_open(struct inode *inode, struct file *filp)
+{
+    filp->private_data =3D &passive_domains;
+    return 0;
 }
=20
 static const struct file_operations passive_domain_ops =3D {
-	.read		=3D pdomain_read,
-	.write		=3D pdomain_write,
+	.open		=3D pdomain_open,
+	.read		=3D domain_read,
+	.write		=3D domain_write,
 };
=20
 void oprofile_create_files(struct super_block * sb, struct dentry * root)



--=__PartCAE49613.0__=
Content-Type: text/plain; name="xen-oprofile-files.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="xen-oprofile-files.patch"

xenoprof: consolidate read/write of active/passive domain IDs=0A=0AThis =
doesn't just fold redundant code, but also fixes the potential for=0Aa =
buffer overrun: While active_domains[] was properly sized (matching=0Athe =
main loop in adomain_write()), passive_domains[] was declared one=0Aentry =
too short.=0A=0ASigned-off-by: Jan Beulich <jbeulich@suse.com>=0A=0A--- =
a/drivers/oprofile/oprofile_files.c=0A+++ b/drivers/oprofile/oprofile_files=
.c=0A@@ -126,13 +126,22 @@ static const struct file_operations dump=0A =0A =
#define TMPBUFSIZE 512=0A =0A-static unsigned int adomains =3D 0;=0A-static=
 int active_domains[MAX_OPROF_DOMAINS + 1];=0A-static DEFINE_MUTEX(adom_mut=
ex);=0A+struct domain_data {=0A+    unsigned int nr;=0A+    int ids[MAX_OPR=
OF_DOMAINS + 1];=0A+    struct mutex mutex;=0A+    int (*set)(int[], =
unsigned int);=0A+};=0A+#define DEFINE_DOMAIN_DATA(what) \=0A+	struct =
domain_data what##_domains =3D { \=0A+		.mutex =3D __MUTEX_INITIALI=
ZER(what##_domains.mutex), \=0A+		.set =3D oprofile_set_##wha=
t \=0A+	}=0A =0A-static ssize_t adomain_write(struct file * file, char =
const __user * buf, =0A-			     size_t count, loff_t =
* offset)=0A+static ssize_t domain_write(struct file *filp, char const =
__user *buf,=0A+			    size_t count, loff_t =
*offset)=0A {=0A+	struct domain_data *dom =3D filp->private_data;=0A =
	char *tmpbuf;=0A 	char *startp, *endp;=0A 	int =
i;=0A@@ -153,7 +162,7 @@ static ssize_t adomain_write(struct file=0A 	=
}=0A 	tmpbuf[count] =3D 0;=0A =0A-	mutex_lock(&adom_mutex);=0A+	=
mutex_lock(&dom->mutex);=0A =0A 	startp =3D tmpbuf;=0A 	/* Parse =
one more than MAX_OPROF_DOMAINS, for easy error checking */=0A@@ -163,31 =
+172,32 @@ static ssize_t adomain_write(struct file=0A 			=
break;=0A 		while (ispunct(*endp) || isspace(*endp))=0A 		=
	endp++;=0A-		active_domains[i] =3D val;=0A-		if =
(active_domains[i] !=3D val)=0A+		dom->ids[i] =3D val;=0A+	=
	if (dom->ids[i] !=3D val)=0A 			/* Overflow, force =
error below */=0A 			i =3D MAX_OPROF_DOMAINS + 1;=0A 	=
	startp =3D endp;=0A 	}=0A 	/* Force error on trailing junk =
*/=0A-	adomains =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;=0A+	dom->nr =
=3D *startp ? MAX_OPROF_DOMAINS + 1 : i;=0A =0A 	kfree(tmpbuf);=0A =
=0A-	if (adomains > MAX_OPROF_DOMAINS=0A-	    || oprofile_set_active(=
active_domains, adomains)) {=0A-		adomains =3D 0;=0A+	if =
(dom->nr > MAX_OPROF_DOMAINS=0A+	    || dom->set(dom->ids, =
dom->nr)) {=0A+		dom->nr =3D 0;=0A 		retval =3D =
-EINVAL;=0A 	}=0A =0A-	mutex_unlock(&adom_mutex);=0A+	mutex_unloc=
k(&dom->mutex);=0A 	return retval;=0A }=0A =0A-static ssize_t =
adomain_read(struct file * file, char __user * buf, =0A-			=
    size_t count, loff_t * offset)=0A+static ssize_t domain_read(struct =
file *filp, char __user *buf,=0A+			    size_t count, =
loff_t *offset)=0A {=0A-	char * tmpbuf;=0A+	struct domain_data =
*dom =3D filp->private_data;=0A+	char *tmpbuf;=0A 	size_t =
len;=0A 	int i;=0A 	ssize_t retval;=0A@@ -195,18 +205,18 @@ =
static ssize_t adomain_read(struct file =0A 	if (!(tmpbuf =3D kmalloc(TM=
PBUFSIZE, GFP_KERNEL)))=0A 		return -ENOMEM;=0A =0A-	mutex_lock(=
&adom_mutex);=0A+	mutex_lock(&dom->mutex);=0A =0A 	len =3D =
0;=0A-	for (i =3D 0; i < adomains; i++)=0A+	for (i =3D 0; i < dom->nr; =
i++)=0A 		len +=3D snprintf(tmpbuf + len,=0A 			=
	len < TMPBUFSIZE ? TMPBUFSIZE - len : 0,=0A-				=
"%u ", active_domains[i]);=0A+				"%u ", dom->ids[i])=
;=0A 	WARN_ON(len > TMPBUFSIZE);=0A 	if (len !=3D 0 && len <=3D =
TMPBUFSIZE)=0A 		tmpbuf[len-1] =3D '\n';=0A =0A-	mutex_unlock(&adom_=
mutex);=0A+	mutex_unlock(&dom->mutex);=0A =0A 	retval =3D =
simple_read_from_buffer(buf, count, offset, tmpbuf, len);=0A =0A@@ =
-214,103 +224,32 @@ static ssize_t adomain_read(struct file =0A 	=
return retval;=0A }=0A =0A+static DEFINE_DOMAIN_DATA(active);=0A =0A-static=
 const struct file_operations active_domain_ops =3D {=0A-	.read		=
=3D adomain_read,=0A-	.write		=3D adomain_write,=0A-};=0A-=0A-sta=
tic unsigned int pdomains =3D 0;=0A-static int passive_domains[MAX_OPROF_DO=
MAINS];=0A-static DEFINE_MUTEX(pdom_mutex);=0A-=0A-static ssize_t =
pdomain_write(struct file * file, char const __user * buf, =0A-			=
     size_t count, loff_t * offset)=0A+static int adomain_open(struct =
inode *inode, struct file *filp)=0A {=0A-	char *tmpbuf;=0A-	=
char *startp, *endp;=0A-	int i;=0A-	unsigned long val;=0A-	=
ssize_t retval =3D count;=0A-	=0A-	if (*offset)=0A-		=
return -EINVAL;	=0A-	if (count > TMPBUFSIZE - 1)=0A-		return =
-EINVAL;=0A-=0A-	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))=
=0A-		return -ENOMEM;=0A-=0A-	if (copy_from_user(tmpbuf, buf, =
count)) {=0A-		kfree(tmpbuf);=0A-		return -EFAULT;=0A-=
	}=0A-	tmpbuf[count] =3D 0;=0A-=0A-	mutex_lock(&pdom_mutex);=0A=
-=0A-	startp =3D tmpbuf;=0A-	/* Parse one more than MAX_OPROF_DOMAINS, =
for easy error checking */=0A-	for (i =3D 0; i <=3D MAX_OPROF_DOMAINS; =
i++) {=0A-		val =3D simple_strtoul(startp, &endp, 0);=0A-		=
if (endp =3D=3D startp)=0A-			break;=0A-		=
while (ispunct(*endp) || isspace(*endp))=0A-			endp++;=0A-=
		passive_domains[i] =3D val;=0A-		if (passive_domains=
[i] !=3D val)=0A-			/* Overflow, force error below =
*/=0A-			i =3D MAX_OPROF_DOMAINS + 1;=0A-		=
startp =3D endp;=0A-	}=0A-	/* Force error on trailing junk */=0A-	=
pdomains =3D *startp ? MAX_OPROF_DOMAINS + 1 : i;=0A-=0A-	kfree(tmpbu=
f);=0A-=0A-	if (pdomains > MAX_OPROF_DOMAINS=0A-	    || oprofile_set=
_passive(passive_domains, pdomains)) {=0A-		pdomains =3D =
0;=0A-		retval =3D -EINVAL;=0A-	}=0A-=0A-	mutex_unlock(&pdom_=
mutex);=0A-	return retval;=0A+    filp->private_data =3D &active_domain=
s;=0A+    return 0;=0A }=0A =0A-static ssize_t pdomain_read(struct file * =
file, char __user * buf, =0A-			    size_t count, loff_t * =
offset)=0A-{=0A-	char * tmpbuf;=0A-	size_t len;=0A-	int i;=0A-	=
ssize_t retval;=0A-=0A-	if (!(tmpbuf =3D kmalloc(TMPBUFSIZE, GFP_KERNEL)))=
=0A-		return -ENOMEM;=0A-=0A-	mutex_lock(&pdom_mutex);=0A-=0A-	=
len =3D 0;=0A-	for (i =3D 0; i < pdomains; i++)=0A-		len +=3D =
snprintf(tmpbuf + len,=0A-				len < TMPBUFSIZE ? =
TMPBUFSIZE - len : 0,=0A-				"%u ", passive_doma=
ins[i]);=0A-	WARN_ON(len > TMPBUFSIZE);=0A-	if (len !=3D 0 && len <=3D =
TMPBUFSIZE)=0A-		tmpbuf[len-1] =3D '\n';=0A-=0A-	mutex_unlock(&pdom_=
mutex);=0A+static const struct file_operations active_domain_ops =3D {=0A+	=
.open		=3D adomain_open,=0A+	.read		=3D domain_read,=0A=
+	.write		=3D domain_write,=0A+};=0A =0A-	retval =3D =
simple_read_from_buffer(buf, count, offset, tmpbuf, len);=0A+static =
DEFINE_DOMAIN_DATA(passive);=0A =0A-	kfree(tmpbuf);=0A-	return =
retval;=0A+static int pdomain_open(struct inode *inode, struct file =
*filp)=0A+{=0A+    filp->private_data =3D &passive_domains;=0A+    return =
0;=0A }=0A =0A static const struct file_operations passive_domain_ops =3D =
{=0A-	.read		=3D pdomain_read,=0A-	.write		=3D =
pdomain_write,=0A+	.open		=3D pdomain_open,=0A+	.read		=
=3D domain_read,=0A+	.write		=3D domain_write,=0A };=0A =0A =
void oprofile_create_files(struct super_block * sb, struct dentry * =
root)=0A
--=__PartCAE49613.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

--=__PartCAE49613.0__=--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:48:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjXo-00044e-Ah; Tue, 24 Jan 2012 16:48:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RpjXm-00044N-P9
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:48:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327423699!12337756!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 11276 invoked from network); 24 Jan 2012 16:48:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 16:48:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RpjXb-0005mv-Ht; Tue, 24 Jan 2012 16:48:15 +0000
Date: Tue, 24 Jan 2012 16:48:15 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120124164815.GA14906@ocelot.phlegethon.org>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO"
Content-Disposition: inline
In-Reply-To: <20254.54700.872146.773765@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Adin Scannell <adin@scannel.ca>, Keir Fraser <keir@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Hi, 

At 16:00 +0000 on 24 Jan (1327420844), Ian Jackson wrote:
> Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
> > This is a host-specific, but deterministic, failure. 
> 
> Improve handling of nested page faults
> 
> Add checks for access type. Be less reliant on implicit semantics.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Acked-by: Tim Deegan <tim@xen.org>
> Committed-by: Tim Deegan <tim@xen.org>

Hmm, Didn't have to pull on that thread too hard to find it's not tied
to anything.  The access_* arguments to hvm_hap_nested_page_fault()
aren't plumbed in on AMD:

    ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);

so gating behaviour on them is not going to work so well.  Sorry about
that - I should definitely have caught this.  (But Andres, did you test
this, or any of your mm work, on AMD?)

The attached patch ought to fix it.  Smoke-tested but I won't have
good enough access to my test machines to check Windows installs before
Thursday. 

Cheers,

Tim.

--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=npt-access-bits

# HG changeset patch
# User Tim Deegan <tim@xen.org>
SVM: Plumb NPT error-code bits into nested-fault access_X arguments.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4cd3560aec0b -r 5f77c1f5aac6 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Tue Jan 24 15:36:19 2012 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Tue Jan 24 16:40:35 2012 +0000
@@ -1185,7 +1185,6 @@ void hvm_inject_exception(unsigned int t
 int hvm_hap_nested_page_fault(unsigned long gpa,
                               bool_t gla_valid,
                               unsigned long gla,
-                              bool_t access_valid,
                               bool_t access_r,
                               bool_t access_w,
                               bool_t access_x)
@@ -1234,7 +1233,7 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_guest, NULL);
 
     /* Check access permissions first, then handle faults */
-    if ( access_valid && (mfn_x(mfn) != INVALID_MFN) )
+    if ( mfn_x(mfn) != INVALID_MFN )
     {
         int violation = 0;
         /* If the access is against the permissions, then send to mem_event */
diff -r 4cd3560aec0b -r 5f77c1f5aac6 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Tue Jan 24 15:36:19 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Tue Jan 24 16:40:35 2012 +0000
@@ -1143,7 +1143,7 @@ struct hvm_function_table * __init start
 }
 
 static void svm_do_nested_pgfault(struct vcpu *v,
-    struct cpu_user_regs *regs, paddr_t gpa)
+    struct cpu_user_regs *regs, uint32_t npfec, paddr_t gpa)
 {
     int ret;
     unsigned long gfn = gpa >> PAGE_SHIFT;
@@ -1152,7 +1152,10 @@ static void svm_do_nested_pgfault(struct
     p2m_access_t p2ma;
     struct p2m_domain *p2m = NULL;
 
-    ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);
+    ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 
+                                    1, /* All NPFs count as reads */
+                                    npfec & PFEC_write_access, 
+                                    npfec & PFEC_insn_fetch);
 
     if ( tb_init_done )
     {
@@ -1181,7 +1184,7 @@ static void svm_do_nested_pgfault(struct
     case -1:
         ASSERT(nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v));
         /* inject #VMEXIT(NPF) into guest. */
-        nestedsvm_vmexit_defer(v, VMEXIT_NPF, regs->error_code, gpa);
+        nestedsvm_vmexit_defer(v, VMEXIT_NPF, npfec, gpa);
         return;
     }
 
@@ -2198,10 +2201,9 @@ void svm_vmexit_handler(struct cpu_user_
 
     case VMEXIT_NPF:
         perfc_incra(svmexits, VMEXIT_NPF_PERFC);
-        regs->error_code = vmcb->exitinfo1;
         if ( cpu_has_svm_decode )
             v->arch.hvm_svm.cached_insn_len = vmcb->guest_ins_len & 0xf;
-        svm_do_nested_pgfault(v, regs, vmcb->exitinfo2);
+        svm_do_nested_pgfault(v, regs, vmcb->exitinfo1, vmcb->exitinfo2);
         v->arch.hvm_svm.cached_insn_len = 0;
         break;
 
diff -r 4cd3560aec0b -r 5f77c1f5aac6 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 24 15:36:19 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 24 16:40:35 2012 +0000
@@ -2106,7 +2106,6 @@ static void ept_handle_violation(unsigne
                                    qualification & EPT_GLA_VALID       ? 1 : 0,
                                    qualification & EPT_GLA_VALID
                                      ? __vmread(GUEST_LINEAR_ADDRESS) : ~0ull,
-                                   1, /* access types are as follows */
                                    qualification & EPT_READ_VIOLATION  ? 1 : 0,
                                    qualification & EPT_WRITE_VIOLATION ? 1 : 0,
                                    qualification & EPT_EXEC_VIOLATION  ? 1 : 0) )
diff -r 4cd3560aec0b -r 5f77c1f5aac6 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Tue Jan 24 15:36:19 2012 +0000
+++ b/xen/include/asm-x86/hvm/hvm.h	Tue Jan 24 16:40:35 2012 +0000
@@ -409,7 +409,6 @@ int hvm_debug_op(struct vcpu *v, int32_t
 
 int hvm_hap_nested_page_fault(unsigned long gpa,
                               bool_t gla_valid, unsigned long gla,
-                              bool_t access_valid, 
                               bool_t access_r,
                               bool_t access_w,
                               bool_t access_x);

--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--2oS5YaxWCcQjTEyO--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:48:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:48:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpjXo-00044e-Ah; Tue, 24 Jan 2012 16:48:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RpjXm-00044N-P9
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 16:48:27 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327423699!12337756!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 11276 invoked from network); 24 Jan 2012 16:48:19 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 16:48:19 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RpjXb-0005mv-Ht; Tue, 24 Jan 2012 16:48:15 +0000
Date: Tue, 24 Jan 2012 16:48:15 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120124164815.GA14906@ocelot.phlegethon.org>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO"
Content-Disposition: inline
In-Reply-To: <20254.54700.872146.773765@mariner.uk.xensource.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Adin Scannell <adin@scannel.ca>, Keir Fraser <keir@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: 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>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Hi, 

At 16:00 +0000 on 24 Jan (1327420844), Ian Jackson wrote:
> Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
> > This is a host-specific, but deterministic, failure. 
> 
> Improve handling of nested page faults
> 
> Add checks for access type. Be less reliant on implicit semantics.
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
> Acked-by: Tim Deegan <tim@xen.org>
> Committed-by: Tim Deegan <tim@xen.org>

Hmm, Didn't have to pull on that thread too hard to find it's not tied
to anything.  The access_* arguments to hvm_hap_nested_page_fault()
aren't plumbed in on AMD:

    ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);

so gating behaviour on them is not going to work so well.  Sorry about
that - I should definitely have caught this.  (But Andres, did you test
this, or any of your mm work, on AMD?)

The attached patch ought to fix it.  Smoke-tested but I won't have
good enough access to my test machines to check Windows installs before
Thursday. 

Cheers,

Tim.

--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename=npt-access-bits

# HG changeset patch
# User Tim Deegan <tim@xen.org>
SVM: Plumb NPT error-code bits into nested-fault access_X arguments.

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r 4cd3560aec0b -r 5f77c1f5aac6 xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c	Tue Jan 24 15:36:19 2012 +0000
+++ b/xen/arch/x86/hvm/hvm.c	Tue Jan 24 16:40:35 2012 +0000
@@ -1185,7 +1185,6 @@ void hvm_inject_exception(unsigned int t
 int hvm_hap_nested_page_fault(unsigned long gpa,
                               bool_t gla_valid,
                               unsigned long gla,
-                              bool_t access_valid,
                               bool_t access_r,
                               bool_t access_w,
                               bool_t access_x)
@@ -1234,7 +1233,7 @@ int hvm_hap_nested_page_fault(unsigned l
     mfn = get_gfn_type_access(p2m, gfn, &p2mt, &p2ma, p2m_guest, NULL);
 
     /* Check access permissions first, then handle faults */
-    if ( access_valid && (mfn_x(mfn) != INVALID_MFN) )
+    if ( mfn_x(mfn) != INVALID_MFN )
     {
         int violation = 0;
         /* If the access is against the permissions, then send to mem_event */
diff -r 4cd3560aec0b -r 5f77c1f5aac6 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Tue Jan 24 15:36:19 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Tue Jan 24 16:40:35 2012 +0000
@@ -1143,7 +1143,7 @@ struct hvm_function_table * __init start
 }
 
 static void svm_do_nested_pgfault(struct vcpu *v,
-    struct cpu_user_regs *regs, paddr_t gpa)
+    struct cpu_user_regs *regs, uint32_t npfec, paddr_t gpa)
 {
     int ret;
     unsigned long gfn = gpa >> PAGE_SHIFT;
@@ -1152,7 +1152,10 @@ static void svm_do_nested_pgfault(struct
     p2m_access_t p2ma;
     struct p2m_domain *p2m = NULL;
 
-    ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);
+    ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 
+                                    1, /* All NPFs count as reads */
+                                    npfec & PFEC_write_access, 
+                                    npfec & PFEC_insn_fetch);
 
     if ( tb_init_done )
     {
@@ -1181,7 +1184,7 @@ static void svm_do_nested_pgfault(struct
     case -1:
         ASSERT(nestedhvm_enabled(v->domain) && nestedhvm_vcpu_in_guestmode(v));
         /* inject #VMEXIT(NPF) into guest. */
-        nestedsvm_vmexit_defer(v, VMEXIT_NPF, regs->error_code, gpa);
+        nestedsvm_vmexit_defer(v, VMEXIT_NPF, npfec, gpa);
         return;
     }
 
@@ -2198,10 +2201,9 @@ void svm_vmexit_handler(struct cpu_user_
 
     case VMEXIT_NPF:
         perfc_incra(svmexits, VMEXIT_NPF_PERFC);
-        regs->error_code = vmcb->exitinfo1;
         if ( cpu_has_svm_decode )
             v->arch.hvm_svm.cached_insn_len = vmcb->guest_ins_len & 0xf;
-        svm_do_nested_pgfault(v, regs, vmcb->exitinfo2);
+        svm_do_nested_pgfault(v, regs, vmcb->exitinfo1, vmcb->exitinfo2);
         v->arch.hvm_svm.cached_insn_len = 0;
         break;
 
diff -r 4cd3560aec0b -r 5f77c1f5aac6 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 24 15:36:19 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 24 16:40:35 2012 +0000
@@ -2106,7 +2106,6 @@ static void ept_handle_violation(unsigne
                                    qualification & EPT_GLA_VALID       ? 1 : 0,
                                    qualification & EPT_GLA_VALID
                                      ? __vmread(GUEST_LINEAR_ADDRESS) : ~0ull,
-                                   1, /* access types are as follows */
                                    qualification & EPT_READ_VIOLATION  ? 1 : 0,
                                    qualification & EPT_WRITE_VIOLATION ? 1 : 0,
                                    qualification & EPT_EXEC_VIOLATION  ? 1 : 0) )
diff -r 4cd3560aec0b -r 5f77c1f5aac6 xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h	Tue Jan 24 15:36:19 2012 +0000
+++ b/xen/include/asm-x86/hvm/hvm.h	Tue Jan 24 16:40:35 2012 +0000
@@ -409,7 +409,6 @@ int hvm_debug_op(struct vcpu *v, int32_t
 
 int hvm_hap_nested_page_fault(unsigned long gpa,
                               bool_t gla_valid, unsigned long gla,
-                              bool_t access_valid, 
                               bool_t access_r,
                               bool_t access_w,
                               bool_t access_x);

--2oS5YaxWCcQjTEyO
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--2oS5YaxWCcQjTEyO--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:53:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpjbw-0004R7-1Q; Tue, 24 Jan 2012 16:52:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1Rpjbu-0004Qd-W4; Tue, 24 Jan 2012 16:52:43 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327423956!2422762!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10165 invoked from network); 24 Jan 2012 16:52:36 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-5.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 16:52:36 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id E0A1DD347C4;
	Tue, 24 Jan 2012 17:52:35 +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 Chzz30hJf+3V; Tue, 24 Jan 2012 17:52:30 +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 5E626D34717;
	Tue, 24 Jan 2012 17:52:30 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: "Likarpenkov Alexander" <al@ohosting.org.ua>
Date: Tue, 24 Jan 2012 17:52:28 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<3565C625B95341E1A6C2F804B7D7D8E3@nobody>
In-Reply-To: <3565C625B95341E1A6C2F804B7D7D8E3@nobody>
MIME-Version: 1.0
Message-Id: <201201241752.29350.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	chris <tknchris@gmail.com>, djmagee@mageenet.net,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 more i think about it, the more i remember:

After installing Windows within DomU and after installing the Catalyst Driver, 
i remember disabling the Emulated Cirrus VGA Card within the Device-Manager in 
Windows; don't know exactly anymore, but this could be an important step so 
that the Catalyst Driver "takes over" correctly;

Another hint: To acces the VNC console:

xvncviewer localhost:5910
(if you use the DomU Config pasted)

and of course you need to adapt the DomU Config especially for the first boot - 
to include an ISO Image of the Windows-Install-CD , e.g.:

disk = [ 'phy:/dev/vg_ssd/win7system,hda,w' , 
'file:/path/to/windows.iso,ioemu:hdb,r' ]

also 
boot="dc"

would be better while installing Windows

Greetings!
Tobias




Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 16:53:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 16:53:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpjbw-0004R7-1Q; Tue, 24 Jan 2012 16:52:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>)
	id 1Rpjbu-0004Qd-W4; Tue, 24 Jan 2012 16:52:43 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327423956!2422762!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10165 invoked from network); 24 Jan 2012 16:52:36 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-5.tower-21.messagelabs.com with SMTP;
	24 Jan 2012 16:52:36 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id E0A1DD347C4;
	Tue, 24 Jan 2012 17:52:35 +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 Chzz30hJf+3V; Tue, 24 Jan 2012 17:52:30 +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 5E626D34717;
	Tue, 24 Jan 2012 17:52:30 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: "Likarpenkov Alexander" <al@ohosting.org.ua>
Date: Tue, 24 Jan 2012 17:52:28 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<3565C625B95341E1A6C2F804B7D7D8E3@nobody>
In-Reply-To: <3565C625B95341E1A6C2F804B7D7D8E3@nobody>
MIME-Version: 1.0
Message-Id: <201201241752.29350.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	chris <tknchris@gmail.com>, djmagee@mageenet.net,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 more i think about it, the more i remember:

After installing Windows within DomU and after installing the Catalyst Driver, 
i remember disabling the Emulated Cirrus VGA Card within the Device-Manager in 
Windows; don't know exactly anymore, but this could be an important step so 
that the Catalyst Driver "takes over" correctly;

Another hint: To acces the VNC console:

xvncviewer localhost:5910
(if you use the DomU Config pasted)

and of course you need to adapt the DomU Config especially for the first boot - 
to include an ISO Image of the Windows-Install-CD , e.g.:

disk = [ 'phy:/dev/vg_ssd/win7system,hda,w' , 
'file:/path/to/windows.iso,ioemu:hdb,r' ]

also 
boot="dc"

would be better while installing Windows

Greetings!
Tobias




Am Dienstag, 24. Januar 2012, 16:15:29 schrieb Likarpenkov Alexander:
> TG> I was a bit un-percice regarding the "reboot" issue:
> 
>  TG> The passing-through itself works even after a reboot of DomU - the
>  TG> rebooted System spits out its Graphics normaly through the
>  TG> passed-through Card (NVIDA or ATI doesnt matter here) ; BUT:
>  TG> After a reboot it doesn't work properly. Meaning:
>  TG> Slow 3d Performance, i.e.
>  TG> unsable for real 3d apps, even a 3d Desktop;
>  TG> For example, when the Card gives you 70fps in a Benchmark after a
> fresh TG> Cold Boot, it only gives you 5-10fps after a reboot, this will
> be that TG> low until you reboot Dom0 also, not only DomU;
>  TG> hopefully i described the scenario better now...
> 
> I'm sorry. Errors are highlighted in red.
> 
>  That is, situations as follows:
> - There is a certain group who are trying to make a vga pass, but not
> successed (unsuccessfully) - In the second group turned out, the
> performance on the second restart the deplorable
> 
> I belong to the first group, but I use a pci pass and after 10-20 reboots
> the system does not lose the 3D performance.
> 
> Question for Tobias Geiger:
> You do not deign to describe the process step by step is the setup and
> configuration xen-linux-systeM to a successful vga pass?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:10:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:10:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpjt2-0005F3-Qs; Tue, 24 Jan 2012 17:10:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpjt1-0005Ey-3h
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:10:23 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327425016!8435650!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28435 invoked from network); 24 Jan 2012 17:10:16 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 17:10:16 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C515020CE2
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 12:10:15 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute6.internal (MEProxy); Tue, 24 Jan 2012 12:10:15 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	Cx/JMwh/GA+ZGkm0Qsu+r2NrdQg=; b=nBlXDHQyQ+D0I/bVeMSg2u1MZWM3Qg+0
	kCsws7gPCAY1aX6Cvm+k9UrW+WJo8sgQs736weMeLFPRBoeLzvuhwKCezArS6O/g
	exSWsUKyTSzzG3spR0+pZKrjWOhDZnrPlTTMpi2eX3+Gp9msbFOcImDpO2VPHkFv
	uHbtp2/mNwU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=Cx/JMwh/GA+ZGkm0Qsu+r2NrdQg=; b=
	or+mI23gHfpXM5v3HZaqgY7jZtpCHeSeU1Jp8VzksYl6FRUXzv3MIyZacB1ppvcH
	nqO+e1mrTFxw715FuVrXFWkT2+0HT3hvAMUq4Bgsg2Z066FZaW+zXjwrBPGJao9+
	CLjVElS7WgEjmFQviIdG/VpMZO4CYIU2tBaK6jsLimc=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 9D951A000A6; Tue, 24 Jan 2012 12:10:15 -0500 (EST)
Message-Id: <1327425015.8709.140661027442201@webmail.messagingengine.com>
X-Sasl-Enc: 8G5kfwnlevYNgxAKXKwKeVDNmPxJAWyAPOwUPOCAKY+Y 1327425015
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327423312.24561.211.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Jan 2012 09:10:15 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, Jan 24, 2012, at 04:41 PM, Ian Campbell wrote:
> brINT is not the name you've been quoting before (which was br0). Are
> you running these tests on a variety of different systems with different
> configurations?
>
> It would be really helpful for those of us trying to help you if you
> could use the same system with the same setup (modulo requested changes)
> for the entirety of this conversation. Otherwise it becomes rather hard
> for us to correlate the facts.
> 
> In this case I now have to ask if you are sure that you used the
> appropriate "bridge=brINT" in your guest configuration instead of
> "bridge=br0" which you had before.

No, the same system.  Just a different bridge config file because I've
read some speculation re: bridge naming requirements, and have been
testing it -- in response to others that are trying to help me.

The email to this list was just a copy and paste problem from the notes
I'm trying to keep.

Returning to just =br0, the problem still exists exactly as I reported
above.  I can repost everything if you'd like to see that. Just to
remind, there are now at least 3 persons reporting similar problems with
no network access with xl-created Guests.

> At this point I'm afraid my only suggesting is to drop "echo made it to
> XXX" breadcrumbs throughout the script and try to narrow down to the
> line which exits.

I'll give that a try and report.

> You could also perhaps run "udevadm monitor" in another window while
> starting the guest, so wee can see what events you are actually seeing.

xl create /etc/xen/vm/test.cfg
 Parsing config file /etc/xen/vm/test.cfg
 Daemon running with PID 29685

xl list
 Name                                        ID   Mem VCPUs      State  
 Time(s)
 Domain-0                                     0  1010     1     r-----  
  2524.2
 test                                         8  2048     2     -b----  
     7.0

xl console test
 login ...

@ the Guest
dmesg | egrep -i "bus|eth|dri|pci"
 [    0.157505] PCI: Fatal: No config space access function found
 [    0.157512] PCI: setting up Xen PCI frontend stub
 [    0.157878] xen_mem: Initialising balloon driver.
 [    0.160157] PCI: System does not support PCI
 [    0.160157] PCI: System does not support PCI
 [    0.164020] PCI: max bus depth: 0 pci_try_num: 1
 [    0.166097] PCI: CLS 64 bytes
 [    0.227389] Block layer SCSI generic (bsg) driver version 0.4 loaded
 (major 253)
 [    0.227651] Non-volatile memory driver v1.3
 [    0.311840] Fixed MDIO Bus: probed
 [    0.412125] XENBUS: Device with no driver: device/vbd/51712
 [    0.412133] XENBUS: Device with no driver: device/vbd/51728
 [    0.412139] XENBUS: Device with no driver: device/vbd/51744
 [    0.412144] XENBUS: Device with no driver: device/vif/0
 [    0.412153]
 /home/abuild/rpmbuild/BUILD/kernel-xen-3.1.0/linux-3.1/drivers/rtc/hctosys.c:
 unable to open rtc device (rtc0)
 [    0.868480] netfront: Initialising virtual ethernet driver.

@ the Host
udevadm monitor
 monitor will print the received events for:
 UDEV - the event which udev sends out after rule processing
 KERNEL - the kernel uevent

 KERNEL[172855.382354] add      /devices/xen-backend/vbd-8-51712
 (xen-backend)
 KERNEL[172855.471281] add      /devices/xen-backend/vbd-8-51728
 (xen-backend)
 UDEV  [172855.491539] add      /devices/xen-backend/vbd-8-51712
 (xen-backend)
 KERNEL[172855.561121] add      /devices/xen-backend/vbd-8-51744
 (xen-backend)
 UDEV  [172855.579734] add      /devices/xen-backend/vbd-8-51728
 (xen-backend)
 KERNEL[172855.610413] add      /devices/xen-backend/vif-8-0
 (xen-backend)
 KERNEL[172855.635818] add      /devices/xen-backend/vif-8-0/net/vif8.0
 (net)
 KERNEL[172855.635839] add     
 /devices/xen-backend/vif-8-0/net/vif8.0/queues/rx-0 (queues)
 KERNEL[172855.635851] add     
 /devices/xen-backend/vif-8-0/net/vif8.0/queues/tx-0 (queues)
 KERNEL[172855.636154] online   /devices/xen-backend/vif-8-0
 (xen-backend)
 UDEV  [172855.655709] add      /devices/xen-backend/vif-8-0
 (xen-backend)
 UDEV  [172855.673354] add      /devices/xen-backend/vbd-8-51744
 (xen-backend)
 KERNEL[172855.700762] add      /devices/xen-backend/vfb-8-0
 (xen-backend)
 UDEV  [172855.706786] add      /devices/xen-backend/vfb-8-0
 (xen-backend)
 UDEV  [172855.720759] add      /devices/xen-backend/vif-8-0/net/vif8.0
 (net)
 UDEV  [172855.721130] add     
 /devices/xen-backend/vif-8-0/net/vif8.0/queues/rx-0 (queues)
 UDEV  [172855.721457] add     
 /devices/xen-backend/vif-8-0/net/vif8.0/queues/tx-0 (queues)
 KERNEL[172855.725625] add      /devices/xen-backend/vkbd-8-0
 (xen-backend)
 UDEV  [172855.732509] add      /devices/xen-backend/vkbd-8-0
 (xen-backend)
 KERNEL[172855.758430] add      /devices/xen-backend/console-8-0
 (xen-backend)
 UDEV  [172855.768396] add      /devices/xen-backend/console-8-0
 (xen-backend)
 UDEV  [172855.909030] online   /devices/xen-backend/vif-8-0
 (xen-backend)

> [...]
> > cat /var/log/xeb/console/*
> >  cat: /var/log/xeb/console/*: No such file or directory
> 
> Obviously a typo, but there's probably not too much of interest in the
> guest console logs.

Yes a typo.

 cat /var/log/xen/console/*
  cat: /var/log/xen/console/*: No such file or directory


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:10:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:10:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpjt2-0005F3-Qs; Tue, 24 Jan 2012 17:10:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpjt1-0005Ey-3h
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:10:23 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327425016!8435650!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28435 invoked from network); 24 Jan 2012 17:10:16 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 17:10:16 -0000
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C515020CE2
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 12:10:15 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute6.internal (MEProxy); Tue, 24 Jan 2012 12:10:15 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	Cx/JMwh/GA+ZGkm0Qsu+r2NrdQg=; b=nBlXDHQyQ+D0I/bVeMSg2u1MZWM3Qg+0
	kCsws7gPCAY1aX6Cvm+k9UrW+WJo8sgQs736weMeLFPRBoeLzvuhwKCezArS6O/g
	exSWsUKyTSzzG3spR0+pZKrjWOhDZnrPlTTMpi2eX3+Gp9msbFOcImDpO2VPHkFv
	uHbtp2/mNwU=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=Cx/JMwh/GA+ZGkm0Qsu+r2NrdQg=; b=
	or+mI23gHfpXM5v3HZaqgY7jZtpCHeSeU1Jp8VzksYl6FRUXzv3MIyZacB1ppvcH
	nqO+e1mrTFxw715FuVrXFWkT2+0HT3hvAMUq4Bgsg2Z066FZaW+zXjwrBPGJao9+
	CLjVElS7WgEjmFQviIdG/VpMZO4CYIU2tBaK6jsLimc=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 9D951A000A6; Tue, 24 Jan 2012 12:10:15 -0500 (EST)
Message-Id: <1327425015.8709.140661027442201@webmail.messagingengine.com>
X-Sasl-Enc: 8G5kfwnlevYNgxAKXKwKeVDNmPxJAWyAPOwUPOCAKY+Y 1327425015
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327423312.24561.211.camel@zakaz.uk.xensource.com>
Date: Tue, 24 Jan 2012 09:10:15 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, Jan 24, 2012, at 04:41 PM, Ian Campbell wrote:
> brINT is not the name you've been quoting before (which was br0). Are
> you running these tests on a variety of different systems with different
> configurations?
>
> It would be really helpful for those of us trying to help you if you
> could use the same system with the same setup (modulo requested changes)
> for the entirety of this conversation. Otherwise it becomes rather hard
> for us to correlate the facts.
> 
> In this case I now have to ask if you are sure that you used the
> appropriate "bridge=brINT" in your guest configuration instead of
> "bridge=br0" which you had before.

No, the same system.  Just a different bridge config file because I've
read some speculation re: bridge naming requirements, and have been
testing it -- in response to others that are trying to help me.

The email to this list was just a copy and paste problem from the notes
I'm trying to keep.

Returning to just =br0, the problem still exists exactly as I reported
above.  I can repost everything if you'd like to see that. Just to
remind, there are now at least 3 persons reporting similar problems with
no network access with xl-created Guests.

> At this point I'm afraid my only suggesting is to drop "echo made it to
> XXX" breadcrumbs throughout the script and try to narrow down to the
> line which exits.

I'll give that a try and report.

> You could also perhaps run "udevadm monitor" in another window while
> starting the guest, so wee can see what events you are actually seeing.

xl create /etc/xen/vm/test.cfg
 Parsing config file /etc/xen/vm/test.cfg
 Daemon running with PID 29685

xl list
 Name                                        ID   Mem VCPUs      State  
 Time(s)
 Domain-0                                     0  1010     1     r-----  
  2524.2
 test                                         8  2048     2     -b----  
     7.0

xl console test
 login ...

@ the Guest
dmesg | egrep -i "bus|eth|dri|pci"
 [    0.157505] PCI: Fatal: No config space access function found
 [    0.157512] PCI: setting up Xen PCI frontend stub
 [    0.157878] xen_mem: Initialising balloon driver.
 [    0.160157] PCI: System does not support PCI
 [    0.160157] PCI: System does not support PCI
 [    0.164020] PCI: max bus depth: 0 pci_try_num: 1
 [    0.166097] PCI: CLS 64 bytes
 [    0.227389] Block layer SCSI generic (bsg) driver version 0.4 loaded
 (major 253)
 [    0.227651] Non-volatile memory driver v1.3
 [    0.311840] Fixed MDIO Bus: probed
 [    0.412125] XENBUS: Device with no driver: device/vbd/51712
 [    0.412133] XENBUS: Device with no driver: device/vbd/51728
 [    0.412139] XENBUS: Device with no driver: device/vbd/51744
 [    0.412144] XENBUS: Device with no driver: device/vif/0
 [    0.412153]
 /home/abuild/rpmbuild/BUILD/kernel-xen-3.1.0/linux-3.1/drivers/rtc/hctosys.c:
 unable to open rtc device (rtc0)
 [    0.868480] netfront: Initialising virtual ethernet driver.

@ the Host
udevadm monitor
 monitor will print the received events for:
 UDEV - the event which udev sends out after rule processing
 KERNEL - the kernel uevent

 KERNEL[172855.382354] add      /devices/xen-backend/vbd-8-51712
 (xen-backend)
 KERNEL[172855.471281] add      /devices/xen-backend/vbd-8-51728
 (xen-backend)
 UDEV  [172855.491539] add      /devices/xen-backend/vbd-8-51712
 (xen-backend)
 KERNEL[172855.561121] add      /devices/xen-backend/vbd-8-51744
 (xen-backend)
 UDEV  [172855.579734] add      /devices/xen-backend/vbd-8-51728
 (xen-backend)
 KERNEL[172855.610413] add      /devices/xen-backend/vif-8-0
 (xen-backend)
 KERNEL[172855.635818] add      /devices/xen-backend/vif-8-0/net/vif8.0
 (net)
 KERNEL[172855.635839] add     
 /devices/xen-backend/vif-8-0/net/vif8.0/queues/rx-0 (queues)
 KERNEL[172855.635851] add     
 /devices/xen-backend/vif-8-0/net/vif8.0/queues/tx-0 (queues)
 KERNEL[172855.636154] online   /devices/xen-backend/vif-8-0
 (xen-backend)
 UDEV  [172855.655709] add      /devices/xen-backend/vif-8-0
 (xen-backend)
 UDEV  [172855.673354] add      /devices/xen-backend/vbd-8-51744
 (xen-backend)
 KERNEL[172855.700762] add      /devices/xen-backend/vfb-8-0
 (xen-backend)
 UDEV  [172855.706786] add      /devices/xen-backend/vfb-8-0
 (xen-backend)
 UDEV  [172855.720759] add      /devices/xen-backend/vif-8-0/net/vif8.0
 (net)
 UDEV  [172855.721130] add     
 /devices/xen-backend/vif-8-0/net/vif8.0/queues/rx-0 (queues)
 UDEV  [172855.721457] add     
 /devices/xen-backend/vif-8-0/net/vif8.0/queues/tx-0 (queues)
 KERNEL[172855.725625] add      /devices/xen-backend/vkbd-8-0
 (xen-backend)
 UDEV  [172855.732509] add      /devices/xen-backend/vkbd-8-0
 (xen-backend)
 KERNEL[172855.758430] add      /devices/xen-backend/console-8-0
 (xen-backend)
 UDEV  [172855.768396] add      /devices/xen-backend/console-8-0
 (xen-backend)
 UDEV  [172855.909030] online   /devices/xen-backend/vif-8-0
 (xen-backend)

> [...]
> > cat /var/log/xeb/console/*
> >  cat: /var/log/xeb/console/*: No such file or directory
> 
> Obviously a typo, but there's probably not too much of interest in the
> guest console logs.

Yes a typo.

 cat /var/log/xen/console/*
  cat: /var/log/xen/console/*: No such file or directory


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:23:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:23:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpk5p-0005el-QB; Tue, 24 Jan 2012 17:23:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rpk5o-0005ec-GU
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:23:36 +0000
Received: from [85.158.138.51:56289] by server-10.bemta-3.messagelabs.com id
	B7/65-20948-719EE1F4; Tue, 24 Jan 2012 17:23:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327425814!10510898!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc4NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20209 invoked from network); 24 Jan 2012 17:23:34 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-11.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 17:23:34 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 0B68D604089;
	Tue, 24 Jan 2012 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=eENl91budv6T4WjOOvsvTKjWiNRQ3cisxYSWuIkBAYrU
	up6S0RVV3XoUyA8CBqvc4z7prUbTXzxtoZFAt26aA1uJW3dkjKrsyI0O41UdTdPq
	Yc62DBet17+ISdZSmmwrnJ3x4IUcaI/Yw+IMhWMPE8Xo+AN4991Rk3TddwTeSe8=
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=WLFr5m09nntt9HRfwztLer3XXWY=; b=SzZaNZW1
	e+ga3LLqBK0tX3pXy2YhybIPZf/RK8mj5YIjTqbtq72ECPJMsgy/LAga/DGaSVBB
	Y520ToeSvsL96s0dmN++e3CCzIUebQhWUf/7uQAE0iZV3d/7O2Oq0wUsBBSC9sd8
	z0pTh3B1mIxPnOfwr089f/DyVMdqoGttIuU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 31167604079; 
	Tue, 24 Jan 2012 09:23:33 -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, 24 Jan 2012 09:23:33 -0800
Message-ID: <e9643717a12a4645a46942ee5a231416.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120124164815.GA14906@ocelot.phlegethon.org>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
	<20120124164815.GA14906@ocelot.phlegethon.org>
Date: Tue, 24 Jan 2012 09:23:33 -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: Adin Scannell <adin@scannell.ca>, Keir Fraser <keir@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: tolerable 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

> Hi,
>
> At 16:00 +0000 on 24 Jan (1327420844), Ian Jackson wrote:
>> Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
>> > This is a host-specific, but deterministic, failure.
>>
>> Improve handling of nested page faults
>>
>> Add checks for access type. Be less reliant on implicit semantics.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Acked-by: Tim Deegan <tim@xen.org>
>> Committed-by: Tim Deegan <tim@xen.org>
>
> Hmm, Didn't have to pull on that thread too hard to find it's not tied
> to anything.  The access_* arguments to hvm_hap_nested_page_fault()
> aren't plumbed in on AMD:
>
>     ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);
>
> so gating behaviour on them is not going to work so well.  Sorry about
> that - I should definitely have caught this.  (But Andres, did you test
> this, or any of your mm work, on AMD?)

Phew, thanks Tim. FWIW:
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

And, no, we haven't tested on AMD, because we depend critically on the
support that has been built into EPT for paging/mem_access.

Andres
>
> The attached patch ought to fix it.  Smoke-tested but I won't have
> good enough access to my test machines to check Windows installs before
> Thursday.
>
> 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 Jan 24 17:23:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:23:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpk5p-0005el-QB; Tue, 24 Jan 2012 17:23:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1Rpk5o-0005ec-GU
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:23:36 +0000
Received: from [85.158.138.51:56289] by server-10.bemta-3.messagelabs.com id
	B7/65-20948-719EE1F4; Tue, 24 Jan 2012 17:23:35 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327425814!10510898!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTc4NjE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20209 invoked from network); 24 Jan 2012 17:23:34 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.177) by server-11.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 17:23:34 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 0B68D604089;
	Tue, 24 Jan 2012 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=eENl91budv6T4WjOOvsvTKjWiNRQ3cisxYSWuIkBAYrU
	up6S0RVV3XoUyA8CBqvc4z7prUbTXzxtoZFAt26aA1uJW3dkjKrsyI0O41UdTdPq
	Yc62DBet17+ISdZSmmwrnJ3x4IUcaI/Yw+IMhWMPE8Xo+AN4991Rk3TddwTeSe8=
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=WLFr5m09nntt9HRfwztLer3XXWY=; b=SzZaNZW1
	e+ga3LLqBK0tX3pXy2YhybIPZf/RK8mj5YIjTqbtq72ECPJMsgy/LAga/DGaSVBB
	Y520ToeSvsL96s0dmN++e3CCzIUebQhWUf/7uQAE0iZV3d/7O2Oq0wUsBBSC9sd8
	z0pTh3B1mIxPnOfwr089f/DyVMdqoGttIuU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 31167604079; 
	Tue, 24 Jan 2012 09:23:33 -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, 24 Jan 2012 09:23:33 -0800
Message-ID: <e9643717a12a4645a46942ee5a231416.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120124164815.GA14906@ocelot.phlegethon.org>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
	<20120124164815.GA14906@ocelot.phlegethon.org>
Date: Tue, 24 Jan 2012 09:23:33 -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: Adin Scannell <adin@scannell.ca>, Keir Fraser <keir@xen.org>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: tolerable 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

> Hi,
>
> At 16:00 +0000 on 24 Jan (1327420844), Ian Jackson wrote:
>> Ian Jackson writes ("Re: [xen-unstable test] 11574: tolerable FAIL"):
>> > This is a host-specific, but deterministic, failure.
>>
>> Improve handling of nested page faults
>>
>> Add checks for access type. Be less reliant on implicit semantics.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>> Acked-by: Tim Deegan <tim@xen.org>
>> Committed-by: Tim Deegan <tim@xen.org>
>
> Hmm, Didn't have to pull on that thread too hard to find it's not tied
> to anything.  The access_* arguments to hvm_hap_nested_page_fault()
> aren't plumbed in on AMD:
>
>     ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);
>
> so gating behaviour on them is not going to work so well.  Sorry about
> that - I should definitely have caught this.  (But Andres, did you test
> this, or any of your mm work, on AMD?)

Phew, thanks Tim. FWIW:
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

And, no, we haven't tested on AMD, because we depend critically on the
support that has been built into EPT for paging/mem_access.

Andres
>
> The attached patch ought to fix it.  Smoke-tested but I won't have
> good enough access to my test machines to check Windows installs before
> Thursday.
>
> 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 Jan 24 17:28:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17: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 1RpkAF-0005zx-Kx; Tue, 24 Jan 2012 17:28: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 1RpkAD-0005zh-CL
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:28:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327426082!12244193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8876 invoked from network); 24 Jan 2012 17:28:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 17:28:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10256716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 17:27: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, 24 Jan 2012 17:27: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
	1RpkA1-0001Dz-El; Tue, 24 Jan 2012 17:27:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpkA1-0005Gk-Dh;
	Tue, 24 Jan 2012 17:27:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.59933.408785.834@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 17:27:57 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326969875.17599.50.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
	<1326969875.17599.50.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 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for the thorough review.

Ian Campbell writes ("Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> You've done device removal, do you have a list of other things which
> should use this? (perhaps with an associated list of people's names...)

No, I don't have such a list, but offhand:
  domain creation (bootloader, etc.)
  qmp
  device attach
  domain destruction
  bootloader
  vncviewer exec (or vncviewer parameter fetching - api should change)
(these may overlap).


> > + * If ao_how==NULL, the function will be synchronous.
> > + *
> > + * If ao_how!=NULL, the function will set the operation going, and
> > + * if this is successful will return ERROR_ASYNCH_INPROGRESS.
> 
> There's an extra H here compared with the actual symbol name (I think
> the symbol is right).

Fixed everywhere.


> Is there a possibility that libxl might decide that the operation isn't
> actually going to take all the long and do things synchronously,
> returning normal success (e.g. 0)? Is that the reason for the separate
> return code for this "I did what you asked me" case?

No, even if the operation completes quickly, the same exit path is
taken.  So if you ask for a callback or an event, you get that even if
the callback or event happened before your initiating function
returns.  As I say:

 * Note that it is possible for an asynchronous operation which is to
 * result in a callback to complete during its initiating function
 * call.  In this case the initating function will return
 * ERROR_ASYNC_INPROGRESS, even though by the time it returns the
 * operation is complete and the callback has already happened.

If ao_how is non-NULL then these functions cannot return 0.
If it is NULL they cannot return ASYNC_INPROGRESS.

I chose to use a new exit status because it seemed safer but that's a
matter of taste and if you prefer I could return 0 for that case.


> Can we drop the ERROR_ prefix? I know that's inconsistent with the other
> return codes but those actually are errors.

I guess we could but isn't this going to become a proper IDL enum at
some point ?


> > + *
> > + * If ao_how->callback!=NULL, the callback will be called when the
> > + * operation completes.  The same rules as for libxl_event_hooks
> > + * apply, including the reentrancy rules and the possibility of
> 
>            ^ (see above/below) -- depending on how these comments end up
> relative to each other.

It's actually in a different file.  I'll add a cross-reference.


> > + * "disaster", except that libxl calls ao_how->callback instead of
> > + * libxl_event_hooks.event_occurs.
> > + *
> > + * If ao_how->callback==NULL, a libxl_event will be generated which
> > + * can be obtained from libxl_event_wait or libxl_event_check.
> 
> Or be delivered via event_occurs?

Yes, in principle, although that would be a silly thing to ask for.
Why would you want your ao completions delivered via some central
callback function just so that you could split them up again ?



> > + * call.  In this case the initating function will return
> 
>                               initiating

Fixed.


> > +typedef struct {
> > +    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
> > +    union {
> > +        libxl_ev_user for_event; /* used if callback==NULL */
> > +        void *for_callback; /* passed to callback */
> 
> Why void * for one bit of "closure" but an explicit uint64_t for the
> other. I nearly commented on the use of uint64_t previously -- void *,
> or perhaps (u)intptr_t is more normal.

The context value in an event needs to be marshallable to a foreign
language or a foreign process.  So it can't be a pointer.  Or at
least, it has to be a type which can contain integers as well as
pointers, and an integer type is better for that.

The context value for a callback function can be a void* because you
don't ever need to "marshal" the "callback", or if you do you can wrap
up the context appropriately.

> > + * Completion after initiator return (asynch. only):
...
> > + *   * initiator calls ao_complete:               |
> > + *     - observes event not net done,             |
> > + *     - returns to caller                        |
> > + *                                                |
> > + *                              - ao completes on some thread
> > + *                              - generate the event or call the callback
> > + *                              - destroy the ao
> 
> Where does ao_inprogress fit into these diagrams?

There's a mistake in the diagrams: where it says on the left
"initiator calls ao_complete" it should read "... ao_inprogress", and
likewise for "ao_complete takes the lock".  I will fix this.


> > + */
> > +
> > +void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao) {
> 
> CODING_STYLE wants these braces on the next line (a bunch more follow)

Oh yes, will fix.


> > +void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
> > +    assert(ao->magic == LIBXL__AO_MAGIC);
> > +    assert(!ao->complete);
> > +    ao->complete = 1;
> > +    ao->rc = rc;
> > +
> > +    if (ao->poller) {
> > +        assert(ao->in_initiator);
> > +        libxl__poller_wakeup(egc, ao->poller);
> > +    } else if (ao->how.callback) {
> > +        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
> > +    } else {
> > +        libxl_event *ev;
> > +        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
> > +        if (ev) {
> > +            ev->for_user = ao->how.u.for_event;
> > +            ev->u.operation_complete.rc = ao->rc;
> > +            libxl__event_occurred(egc, ev);
> > +        }
> > +        ao->notified = 1;
> > +    }
> > +    if (!ao->in_initiator && ao->notified)
> > +        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
> 
> You added a helper for this libxl__gc_owner(&egc..) construct.

You mean EGC_GC and CTX.  I don't think that's a good idea here
because it obscures exactly what's going on.  In particular, there are
two gcs here - the ao's and the egc's - and one of them may be about
to evaporate.


> > +    ao = calloc(sizeof(*ao),1);
> 
> calloc is actually (nmemb, size). I'm sure it doesn't really matter
> though.

I'll fix it though.


> > +            rc = eventloop_iteration(&egc,ao->poller);
> > +            if (rc) {
> > +                /* Oh dear, this is quite unfortunate. */
> > +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
> > +                           " event during long-running operation (rc=%d)", rc);
> > +                sleep(1);
> > +                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
> > +                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
> > +                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
> > +                 * cancellation ability. */
> 
> Does this constitute a "disaster" (in the special hook sense)?

No, disaster just lets us say that some events may be lost and an ao
completion might not be an event.  disaster doesn't let us randomly
store up ongoing activity and have it happen when not expected.
For example, a caller asking a synchronous operation does not expect
to get an error code and then have the operation continue in the
background anyway.


> > + *   Usually callback function should use GET_CONTAINING_STRUCT
> 
> Now called CONTAINER_OF

Fixed.  Sometimes I wish the compiler could look into comments and
spot when I've done this kind of thing.


> > + *   to obtain its own structure, containing a pointer to the ao,
> > + *   and then use the gc from that ao.
> > + */
> > +
> > +#define AO_CREATE(ctx, domid, ao_how)                           \
> > +    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
> > +    if (!ao) return ERROR_NOMEM;                                \
> > +    AO_GC;                                                      \
> > +    CTX_LOCK;
> 
> Where does the unlock which balances this come from? The only unlock I
> see in this patch is the temporary drop in libxl__ao_inprogress which is
> matched by another lock.

The AO_INPROGRESS macro is supposed to unlock it, but locks it again
by mistake.  Well spotted.

> > +#define AO_INPROGRESS do{                                       \
> > +        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> > +        int ao__rc = libxl__ao_inprogress(ao);                  \
> > +        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
> 
> Is this supposed to be unlock answering my question above? Likewise in
> ABORT?

Yes.  Indeed the comment above agrees:

 * - If initiation is successful, the initiating function needs
 *   to run libxl__ao_inprogress right before unlocking and
 *   returning, and return whatever it returns (AO_INPROGRESS macro).
 *
 * - If the initiation is unsuccessful, the initiating function must
 *   call libxl__ao_abort before unlocking and returning whatever
 *   error code is appropriate (AO_ABORT macro).


 > > +        return ao__rc;                                          \
> > +   }while(0)
> 
> Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
> would become
>         return AO_INPROGRESS;

That would be possible.  I wasn't sure whether to do it like that.
Note that AO_CREATE already might return; doing it the way I have it
now seems more symmetrical.

But perhaps it would make things clearer to have the return outside
the macro.

> Is the ({stuff,stuff,stuff,val}) syntax a gcc-ism?

Yes.  But I don't think that should stop us if we prefer it.


> > +/* All of these MUST be called with the ctx locked.
> 
> Except libxl__ao_create? at least according to the implementation of
> AO_CREATE which takes the lock after.

libxl_ao__create calls libxl__poller_get which needs to be called with
the lock held.  Well spotted.


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 Jan 24 17:28:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17: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 1RpkAF-0005zx-Kx; Tue, 24 Jan 2012 17:28: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 1RpkAD-0005zh-CL
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:28:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327426082!12244193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8876 invoked from network); 24 Jan 2012 17:28:03 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 17:28:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10256716"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 17:27: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, 24 Jan 2012 17:27: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
	1RpkA1-0001Dz-El; Tue, 24 Jan 2012 17:27:57 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpkA1-0005Gk-Dh;
	Tue, 24 Jan 2012 17:27:57 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.59933.408785.834@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 17:27:57 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326969875.17599.50.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
	<1326969875.17599.50.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 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Thanks for the thorough review.

Ian Campbell writes ("Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> You've done device removal, do you have a list of other things which
> should use this? (perhaps with an associated list of people's names...)

No, I don't have such a list, but offhand:
  domain creation (bootloader, etc.)
  qmp
  device attach
  domain destruction
  bootloader
  vncviewer exec (or vncviewer parameter fetching - api should change)
(these may overlap).


> > + * If ao_how==NULL, the function will be synchronous.
> > + *
> > + * If ao_how!=NULL, the function will set the operation going, and
> > + * if this is successful will return ERROR_ASYNCH_INPROGRESS.
> 
> There's an extra H here compared with the actual symbol name (I think
> the symbol is right).

Fixed everywhere.


> Is there a possibility that libxl might decide that the operation isn't
> actually going to take all the long and do things synchronously,
> returning normal success (e.g. 0)? Is that the reason for the separate
> return code for this "I did what you asked me" case?

No, even if the operation completes quickly, the same exit path is
taken.  So if you ask for a callback or an event, you get that even if
the callback or event happened before your initiating function
returns.  As I say:

 * Note that it is possible for an asynchronous operation which is to
 * result in a callback to complete during its initiating function
 * call.  In this case the initating function will return
 * ERROR_ASYNC_INPROGRESS, even though by the time it returns the
 * operation is complete and the callback has already happened.

If ao_how is non-NULL then these functions cannot return 0.
If it is NULL they cannot return ASYNC_INPROGRESS.

I chose to use a new exit status because it seemed safer but that's a
matter of taste and if you prefer I could return 0 for that case.


> Can we drop the ERROR_ prefix? I know that's inconsistent with the other
> return codes but those actually are errors.

I guess we could but isn't this going to become a proper IDL enum at
some point ?


> > + *
> > + * If ao_how->callback!=NULL, the callback will be called when the
> > + * operation completes.  The same rules as for libxl_event_hooks
> > + * apply, including the reentrancy rules and the possibility of
> 
>            ^ (see above/below) -- depending on how these comments end up
> relative to each other.

It's actually in a different file.  I'll add a cross-reference.


> > + * "disaster", except that libxl calls ao_how->callback instead of
> > + * libxl_event_hooks.event_occurs.
> > + *
> > + * If ao_how->callback==NULL, a libxl_event will be generated which
> > + * can be obtained from libxl_event_wait or libxl_event_check.
> 
> Or be delivered via event_occurs?

Yes, in principle, although that would be a silly thing to ask for.
Why would you want your ao completions delivered via some central
callback function just so that you could split them up again ?



> > + * call.  In this case the initating function will return
> 
>                               initiating

Fixed.


> > +typedef struct {
> > +    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
> > +    union {
> > +        libxl_ev_user for_event; /* used if callback==NULL */
> > +        void *for_callback; /* passed to callback */
> 
> Why void * for one bit of "closure" but an explicit uint64_t for the
> other. I nearly commented on the use of uint64_t previously -- void *,
> or perhaps (u)intptr_t is more normal.

The context value in an event needs to be marshallable to a foreign
language or a foreign process.  So it can't be a pointer.  Or at
least, it has to be a type which can contain integers as well as
pointers, and an integer type is better for that.

The context value for a callback function can be a void* because you
don't ever need to "marshal" the "callback", or if you do you can wrap
up the context appropriately.

> > + * Completion after initiator return (asynch. only):
...
> > + *   * initiator calls ao_complete:               |
> > + *     - observes event not net done,             |
> > + *     - returns to caller                        |
> > + *                                                |
> > + *                              - ao completes on some thread
> > + *                              - generate the event or call the callback
> > + *                              - destroy the ao
> 
> Where does ao_inprogress fit into these diagrams?

There's a mistake in the diagrams: where it says on the left
"initiator calls ao_complete" it should read "... ao_inprogress", and
likewise for "ao_complete takes the lock".  I will fix this.


> > + */
> > +
> > +void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao) {
> 
> CODING_STYLE wants these braces on the next line (a bunch more follow)

Oh yes, will fix.


> > +void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
> > +    assert(ao->magic == LIBXL__AO_MAGIC);
> > +    assert(!ao->complete);
> > +    ao->complete = 1;
> > +    ao->rc = rc;
> > +
> > +    if (ao->poller) {
> > +        assert(ao->in_initiator);
> > +        libxl__poller_wakeup(egc, ao->poller);
> > +    } else if (ao->how.callback) {
> > +        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
> > +    } else {
> > +        libxl_event *ev;
> > +        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
> > +        if (ev) {
> > +            ev->for_user = ao->how.u.for_event;
> > +            ev->u.operation_complete.rc = ao->rc;
> > +            libxl__event_occurred(egc, ev);
> > +        }
> > +        ao->notified = 1;
> > +    }
> > +    if (!ao->in_initiator && ao->notified)
> > +        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
> 
> You added a helper for this libxl__gc_owner(&egc..) construct.

You mean EGC_GC and CTX.  I don't think that's a good idea here
because it obscures exactly what's going on.  In particular, there are
two gcs here - the ao's and the egc's - and one of them may be about
to evaporate.


> > +    ao = calloc(sizeof(*ao),1);
> 
> calloc is actually (nmemb, size). I'm sure it doesn't really matter
> though.

I'll fix it though.


> > +            rc = eventloop_iteration(&egc,ao->poller);
> > +            if (rc) {
> > +                /* Oh dear, this is quite unfortunate. */
> > +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
> > +                           " event during long-running operation (rc=%d)", rc);
> > +                sleep(1);
> > +                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
> > +                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
> > +                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
> > +                 * cancellation ability. */
> 
> Does this constitute a "disaster" (in the special hook sense)?

No, disaster just lets us say that some events may be lost and an ao
completion might not be an event.  disaster doesn't let us randomly
store up ongoing activity and have it happen when not expected.
For example, a caller asking a synchronous operation does not expect
to get an error code and then have the operation continue in the
background anyway.


> > + *   Usually callback function should use GET_CONTAINING_STRUCT
> 
> Now called CONTAINER_OF

Fixed.  Sometimes I wish the compiler could look into comments and
spot when I've done this kind of thing.


> > + *   to obtain its own structure, containing a pointer to the ao,
> > + *   and then use the gc from that ao.
> > + */
> > +
> > +#define AO_CREATE(ctx, domid, ao_how)                           \
> > +    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
> > +    if (!ao) return ERROR_NOMEM;                                \
> > +    AO_GC;                                                      \
> > +    CTX_LOCK;
> 
> Where does the unlock which balances this come from? The only unlock I
> see in this patch is the temporary drop in libxl__ao_inprogress which is
> matched by another lock.

The AO_INPROGRESS macro is supposed to unlock it, but locks it again
by mistake.  Well spotted.

> > +#define AO_INPROGRESS do{                                       \
> > +        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> > +        int ao__rc = libxl__ao_inprogress(ao);                  \
> > +        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
> 
> Is this supposed to be unlock answering my question above? Likewise in
> ABORT?

Yes.  Indeed the comment above agrees:

 * - If initiation is successful, the initiating function needs
 *   to run libxl__ao_inprogress right before unlocking and
 *   returning, and return whatever it returns (AO_INPROGRESS macro).
 *
 * - If the initiation is unsuccessful, the initiating function must
 *   call libxl__ao_abort before unlocking and returning whatever
 *   error code is appropriate (AO_ABORT macro).


 > > +        return ao__rc;                                          \
> > +   }while(0)
> 
> Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
> would become
>         return AO_INPROGRESS;

That would be possible.  I wasn't sure whether to do it like that.
Note that AO_CREATE already might return; doing it the way I have it
now seems more symmetrical.

But perhaps it would make things clearer to have the return outside
the macro.

> Is the ({stuff,stuff,stuff,val}) syntax a gcc-ism?

Yes.  But I don't think that should stop us if we prefer it.


> > +/* All of these MUST be called with the ctx locked.
> 
> Except libxl__ao_create? at least according to the implementation of
> AO_CREATE which takes the lock after.

libxl_ao__create calls libxl__poller_get which needs to be called with
the lock held.  Well spotted.


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 Jan 24 17:33:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkFQ-0006Wa-3H; Tue, 24 Jan 2012 17:33: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 1RpkFP-0006W2-4Z
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:33:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327426405!9644449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3366 invoked from network); 24 Jan 2012 17:33:25 -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;
	24 Jan 2012 17:33:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10256806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 17:33: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; Tue, 24 Jan 2012 17:33: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
	1RpkFI-0001Fp-NP; Tue, 24 Jan 2012 17:33:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpkFI-0005SN-L6;
	Tue, 24 Jan 2012 17:33:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.60260.642300.195152@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 17:33:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326970442.17599.53.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
	<1326970442.17599.53.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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 8/9] libxl: Introduce libxl__ev_devstate"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > Provide a new-style asynchronous facility for waiting for device
> > states on xenbus.  This will replace libxl__wait_for_device_state,
> > after the callers have been updated in later patches.
> 
> Is event-with-timeout likely to be a useful/common enough pattern to be
> worth baking into the infrastructure/helpers rather than implementing
> just for this one event type? (if yes then, "I will refactor for the
> second user is a valid response").

I'm not convinced.  I thought of this but I think it would result in
flabby code - all the libxl__ev_register functions would gain a new
timeout parameter (and note that the timeout machinery has both
absolute and relative timeouts...)

I think when we have a second user it might be worth seeing if some
commonality could be extracted but TBH I doubt it would make the code
smaller or simpler.

> > +static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
> > +                             const struct timeval *requested_abs)
> > +{
> > +    EGC_GC;
> > +    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
> > +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
> > +               " timed out", ds->watch.path, ds->wanted);
> > +    libxl__ev_devstate_cancel(gc, ds);
> 
> What prevents racing here with the watch happening? Might the caller see
> two callbacks?

  static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
                                               libxl__ev_devstate *ds)
  {
      libxl__ev_time_deregister(gc,&ds->timeout);
      libxl__ev_xswatch_deregister(gc,&ds->watch);
  }

So, no.  When the timeout happens, the ev xswatch is deregistered and
can thereafter no longer generate callbacks.  If there are any
xenstore watch events in the pipeline for deregistered ev_xswatch's,
they're discarded by watchfd_callback.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:33:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:33:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkFQ-0006Wa-3H; Tue, 24 Jan 2012 17:33: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 1RpkFP-0006W2-4Z
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:33:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327426405!9644449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3366 invoked from network); 24 Jan 2012 17:33:25 -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;
	24 Jan 2012 17:33:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10256806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 17:33: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; Tue, 24 Jan 2012 17:33: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
	1RpkFI-0001Fp-NP; Tue, 24 Jan 2012 17:33:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpkFI-0005SN-L6;
	Tue, 24 Jan 2012 17:33:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.60260.642300.195152@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 17:33:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326970442.17599.53.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
	<1326970442.17599.53.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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 8/9] libxl: Introduce libxl__ev_devstate"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > Provide a new-style asynchronous facility for waiting for device
> > states on xenbus.  This will replace libxl__wait_for_device_state,
> > after the callers have been updated in later patches.
> 
> Is event-with-timeout likely to be a useful/common enough pattern to be
> worth baking into the infrastructure/helpers rather than implementing
> just for this one event type? (if yes then, "I will refactor for the
> second user is a valid response").

I'm not convinced.  I thought of this but I think it would result in
flabby code - all the libxl__ev_register functions would gain a new
timeout parameter (and note that the timeout machinery has both
absolute and relative timeouts...)

I think when we have a second user it might be worth seeing if some
commonality could be extracted but TBH I doubt it would make the code
smaller or simpler.

> > +static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
> > +                             const struct timeval *requested_abs)
> > +{
> > +    EGC_GC;
> > +    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
> > +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
> > +               " timed out", ds->watch.path, ds->wanted);
> > +    libxl__ev_devstate_cancel(gc, ds);
> 
> What prevents racing here with the watch happening? Might the caller see
> two callbacks?

  static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
                                               libxl__ev_devstate *ds)
  {
      libxl__ev_time_deregister(gc,&ds->timeout);
      libxl__ev_xswatch_deregister(gc,&ds->watch);
  }

So, no.  When the timeout happens, the ev xswatch is deregistered and
can thereafter no longer generate callbacks.  If there are any
xenstore watch events in the pipeline for deregistered ev_xswatch's,
they're discarded by watchfd_callback.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:38:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17: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 1RpkK8-0006vi-2e; Tue, 24 Jan 2012 17:38:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RpkK7-0006vM-Ic
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:38:23 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327426697!3589158!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15007 invoked from network); 24 Jan 2012 17:38:17 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 17:38:17 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E49322054D
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 12:38:16 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute3.internal (MEProxy); Tue, 24 Jan 2012 12:38:16 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:subject:date; s=mesmtp; bh=I5WNsHHKZUOPjmST6etgcX4
	f6uE=; b=j4aVQVbRhAj2x7U4UdFMpN5EW5YpIerNkwTrZ354OOaA7JQ0iQwYiW9
	tXWEwR2hUvX4cjEawPq2tp6ibiUwcsWYpBmbWc1WbXvc/Yhbxo1YDof/Mz27su0o
	GjXS1OotopmKcRv2VVYl9eQd4GSzTzBLxeZXRug/bNgj2Qqf81Cc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:subject:date; s=smtpout;
	bh=I5WNsHHKZUOPjmST6etgcX4f6uE=; b=S8mRlSDH0q/gSKGKI1C6DCsVmPqY
	TO3XWWpWG4Puv8C5FD+m/WFnfn+UGg7cfdabdr/ukS2hjcit/IdRFxyYTzdBvEZr
	fA7dYqRkJQkmbYo+VleqJePA7DTrI4IDZc/hGIDfPOgLqFbw3GQYhU+qMiMSdQpe
	z/S/1Py4T/NB4BY=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id BC706A000A6; Tue, 24 Jan 2012 12:38:16 -0500 (EST)
Message-Id: <1327426696.16492.140661027458613@webmail.messagingengine.com>
X-Sasl-Enc: 7Vs0Y2q8Sr6kWiJh+5jiGAIaxH34ZKyiiVTi5CsY+xu8 1327426696
From: erin.balid@inoutbox.com
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Date: Tue, 24 Jan 2012 09:38:16 -0800
Subject: [Xen-devel] Where does xl debug logging info appear?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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.

Following instructions in another thread, I've added a bunch of "log
debug ..." breadcrumbs in the vif-bridge script.

Now I'm trying to *see* those breadcrumbs when I "xl create" a Guest.

But

export XEND_DEBUG=1
xl create test.cfg
ls -al /var/log/xen/*debug*
 ls: cannot access /var/log/xen/*debug*: No such file or directory

xl destroy test

service xend start
xm create test.cfg
ls -al /var/log/xen/*debug*
 -rw-r--r-- 1 root root 835 Jan 24 09:32 /var/log/xen/xend-debug.log

cat /var/log/xen/xend-debug.log
 Xend started at Tue Jan 24 09:30:59 2012.
 Exception starting xend: [Errno 32] Broken pipe
 Traceback (most recent call last):
   File "/usr/sbin/xend", line 110, in <module>
     sys.exit(main())
   File "/usr/sbin/xend", line 92, in main
     return daemon.start()
   File
   "/usr/lib64/python2.7/site-packages/xen/xend/server/SrvDaemon.py",
   line 234, in start
     self.run(w and os.fdopen(w, 'w') or None)
   File
   "/usr/lib64/python2.7/site-packages/xen/xend/server/SrvDaemon.py",
   line 351, in run
     status.write('1')
 ValueError: I/O operation on closed file
 Xend started at Tue Jan 24 09:31:35 2012.
 Traceback (most recent call last):
   File "/usr/lib64/python2.7/site-packages/xen/xend/server/Hald.py",
   line 55, in shutdown
     os.kill(self.pid, signal.SIGINT)
 OSError: [Errno 3] No such process
 Xend started at Tue Jan 24 09:32:05 2012.

xm console test
 login ...
ping -c1 8.8.8.8
 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=13.7 ms
 
 --- 8.8.8.8 ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 13.711/13.711/13.711/0.000 ms

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:38:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17: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 1RpkK8-0006vi-2e; Tue, 24 Jan 2012 17:38:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RpkK7-0006vM-Ic
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:38:23 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327426697!3589158!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15007 invoked from network); 24 Jan 2012 17:38:17 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 17:38:17 -0000
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E49322054D
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 12:38:16 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute3.internal (MEProxy); Tue, 24 Jan 2012 12:38:16 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:mime-version:content-transfer-encoding
	:content-type:subject:date; s=mesmtp; bh=I5WNsHHKZUOPjmST6etgcX4
	f6uE=; b=j4aVQVbRhAj2x7U4UdFMpN5EW5YpIerNkwTrZ354OOaA7JQ0iQwYiW9
	tXWEwR2hUvX4cjEawPq2tp6ibiUwcsWYpBmbWc1WbXvc/Yhbxo1YDof/Mz27su0o
	GjXS1OotopmKcRv2VVYl9eQd4GSzTzBLxeZXRug/bNgj2Qqf81Cc=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:mime-version
	:content-transfer-encoding:content-type:subject:date; s=smtpout;
	bh=I5WNsHHKZUOPjmST6etgcX4f6uE=; b=S8mRlSDH0q/gSKGKI1C6DCsVmPqY
	TO3XWWpWG4Puv8C5FD+m/WFnfn+UGg7cfdabdr/ukS2hjcit/IdRFxyYTzdBvEZr
	fA7dYqRkJQkmbYo+VleqJePA7DTrI4IDZc/hGIDfPOgLqFbw3GQYhU+qMiMSdQpe
	z/S/1Py4T/NB4BY=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id BC706A000A6; Tue, 24 Jan 2012 12:38:16 -0500 (EST)
Message-Id: <1327426696.16492.140661027458613@webmail.messagingengine.com>
X-Sasl-Enc: 7Vs0Y2q8Sr6kWiJh+5jiGAIaxH34ZKyiiVTi5CsY+xu8 1327426696
From: erin.balid@inoutbox.com
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
Date: Tue, 24 Jan 2012 09:38:16 -0800
Subject: [Xen-devel] Where does xl debug logging info appear?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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.

Following instructions in another thread, I've added a bunch of "log
debug ..." breadcrumbs in the vif-bridge script.

Now I'm trying to *see* those breadcrumbs when I "xl create" a Guest.

But

export XEND_DEBUG=1
xl create test.cfg
ls -al /var/log/xen/*debug*
 ls: cannot access /var/log/xen/*debug*: No such file or directory

xl destroy test

service xend start
xm create test.cfg
ls -al /var/log/xen/*debug*
 -rw-r--r-- 1 root root 835 Jan 24 09:32 /var/log/xen/xend-debug.log

cat /var/log/xen/xend-debug.log
 Xend started at Tue Jan 24 09:30:59 2012.
 Exception starting xend: [Errno 32] Broken pipe
 Traceback (most recent call last):
   File "/usr/sbin/xend", line 110, in <module>
     sys.exit(main())
   File "/usr/sbin/xend", line 92, in main
     return daemon.start()
   File
   "/usr/lib64/python2.7/site-packages/xen/xend/server/SrvDaemon.py",
   line 234, in start
     self.run(w and os.fdopen(w, 'w') or None)
   File
   "/usr/lib64/python2.7/site-packages/xen/xend/server/SrvDaemon.py",
   line 351, in run
     status.write('1')
 ValueError: I/O operation on closed file
 Xend started at Tue Jan 24 09:31:35 2012.
 Traceback (most recent call last):
   File "/usr/lib64/python2.7/site-packages/xen/xend/server/Hald.py",
   line 55, in shutdown
     os.kill(self.pid, signal.SIGINT)
 OSError: [Errno 3] No such process
 Xend started at Tue Jan 24 09:32:05 2012.

xm console test
 login ...
ping -c1 8.8.8.8
 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
 64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=13.7 ms
 
 --- 8.8.8.8 ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 13.711/13.711/13.711/0.000 ms

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkLH-00070o-HW; Tue, 24 Jan 2012 17:39: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 1RpkLG-00070Q-Dy
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:39:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327426768!12245309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 650 invoked from network); 24 Jan 2012 17:39:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 17:39:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10256890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 17: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; Tue, 24 Jan 2012 17:39: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
	1RpkL9-0001Hq-V2; Tue, 24 Jan 2012 17:39:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpkL9-0005TW-Lj;
	Tue, 24 Jan 2012 17:39:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.60623.619405.532989@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 17:39:27 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326974118.17599.72.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-10-git-send-email-ian.jackson@eu.citrix.com>
	<1326974118.17599.72.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 9/9] libxl: Convert to asynchronous: device
 removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 9/9] libxl: Convert to asynchronous: device removal"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > Convert libxl_FOO_device_remove, and the function which does the bulk
> > of the work, libxl__device_remove, to the new async ops scheme.
...
> 
> After all the internal complexity the actual usage is refreshingly
> simple. Phew!

Yes, that was my main aim ...

> >  int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
> > @@ -1536,11 +1540,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
> >  out:
> 
> The async capability here ought to be propagated to the
> libxl_cdrom_insert interface too. I guess that would mean handling
> compound asynchronous operations.

Yes.  Compound asynchronous operations are already supported by the
current scheme: the code which implements them just sets up an
appropriate series of callbacks.

> > +int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
> >  {
> > +    /* Arranges that dev will be removed from its guest.  When
> > +     * this is done, the ao will be completed.  An error
> > +     * return from libxl__device_remove means that the ao
> > +     * will _not_ be completed and the caller must do so.
> 
> Do you mean aborted or cancelled rather than completed here?

No.  An ao cannot be aborted or cancelled, only completed (perhaps
with an error code).

I see that the comment is missing "initiate_" from the function name,
which I will fix.

> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index b7f0f54..9920fb9 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -653,35 +653,15 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
> [...]
> > +/* Arranges that dev will be removed from its guest.  When
> > + * this is done, the ao will be completed.  An error
> > + * return from libxl__device_remove means that the ao
> > + * will _not_ be completed and the caller must do so. */
> 
> This is the same comment as at the head of the implementation so the
> same comment re aborting applies. Do we need both comments?

No.  The comment should be in the header file only.  I'll fix this.

> > -    if (libxl_device_nic_remove(ctx, domid, &nic)) {
> > +    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
...
> 
> There aren't actually any examples of a caller using the ao-ness in xl
> are there?

No.

> I know that sync is for the most part ao+wait but I'm a bit concerned
> that e.g. several of the paths in libxl__ao_complete probably haven't
> been run and one of the flow-charts added to tools/libxl/libxl_event.c
> in patch 6/8 has probably never happened either.

Yes.

> IMHO this isn't a blocker for this patch but since xl is, in addition to
> being a toolstack, a testbed for libxl perhaps one or more "gratuitously
> asynchronous" calls could be made? Perhaps the libxl_cdrom_insert case
> would be an interesting one? In particular the case in the
> create_domain() event loop (e.g. so that the response to a cdrom eject
> does not block shutdown processing).

That would be definitely worthwhile.  I'll put it (mentally) on my
todo list.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkLH-00070o-HW; Tue, 24 Jan 2012 17:39: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 1RpkLG-00070Q-Dy
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:39:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327426768!12245309!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 650 invoked from network); 24 Jan 2012 17:39:28 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 17:39:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10256890"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 17: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; Tue, 24 Jan 2012 17:39: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
	1RpkL9-0001Hq-V2; Tue, 24 Jan 2012 17:39:27 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpkL9-0005TW-Lj;
	Tue, 24 Jan 2012 17:39:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.60623.619405.532989@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 17:39:27 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326974118.17599.72.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-10-git-send-email-ian.jackson@eu.citrix.com>
	<1326974118.17599.72.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 9/9] libxl: Convert to asynchronous: device
 removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 9/9] libxl: Convert to asynchronous: device removal"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > Convert libxl_FOO_device_remove, and the function which does the bulk
> > of the work, libxl__device_remove, to the new async ops scheme.
...
> 
> After all the internal complexity the actual usage is refreshingly
> simple. Phew!

Yes, that was my main aim ...

> >  int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
> > @@ -1536,11 +1540,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
> >  out:
> 
> The async capability here ought to be propagated to the
> libxl_cdrom_insert interface too. I guess that would mean handling
> compound asynchronous operations.

Yes.  Compound asynchronous operations are already supported by the
current scheme: the code which implements them just sets up an
appropriate series of callbacks.

> > +int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
> >  {
> > +    /* Arranges that dev will be removed from its guest.  When
> > +     * this is done, the ao will be completed.  An error
> > +     * return from libxl__device_remove means that the ao
> > +     * will _not_ be completed and the caller must do so.
> 
> Do you mean aborted or cancelled rather than completed here?

No.  An ao cannot be aborted or cancelled, only completed (perhaps
with an error code).

I see that the comment is missing "initiate_" from the function name,
which I will fix.

> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index b7f0f54..9920fb9 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -653,35 +653,15 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
> [...]
> > +/* Arranges that dev will be removed from its guest.  When
> > + * this is done, the ao will be completed.  An error
> > + * return from libxl__device_remove means that the ao
> > + * will _not_ be completed and the caller must do so. */
> 
> This is the same comment as at the head of the implementation so the
> same comment re aborting applies. Do we need both comments?

No.  The comment should be in the header file only.  I'll fix this.

> > -    if (libxl_device_nic_remove(ctx, domid, &nic)) {
> > +    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
...
> 
> There aren't actually any examples of a caller using the ao-ness in xl
> are there?

No.

> I know that sync is for the most part ao+wait but I'm a bit concerned
> that e.g. several of the paths in libxl__ao_complete probably haven't
> been run and one of the flow-charts added to tools/libxl/libxl_event.c
> in patch 6/8 has probably never happened either.

Yes.

> IMHO this isn't a blocker for this patch but since xl is, in addition to
> being a toolstack, a testbed for libxl perhaps one or more "gratuitously
> asynchronous" calls could be made? Perhaps the libxl_cdrom_insert case
> would be an interesting one? In particular the case in the
> create_domain() event loop (e.g. so that the response to a cdrom eject
> does not block shutdown processing).

That would be definitely worthwhile.  I'll put it (mentally) on my
todo list.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:41:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:41:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkMa-00078F-5G; Tue, 24 Jan 2012 17:40:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpkMY-000783-GV
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:40:54 +0000
Received: from [85.158.138.51:43203] by server-8.bemta-3.messagelabs.com id
	0D/AB-31878-52DEE1F4; Tue, 24 Jan 2012 17:40:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327426851!10446993!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwMDcxOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 852 invoked from network); 24 Jan 2012 17:40:53 -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; 24 Jan 2012 17:40:53 -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
	q0OHej4g013742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 17:40:47 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
	q0OHeh2k023988
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jan 2012 17:40:44 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
	q0OHehDl011746; Tue, 24 Jan 2012 11:40:43 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Jan 2012 09:40:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6B45F4016B; Tue, 24 Jan 2012 12:38:27 -0500 (EST)
Date: Tue, 24 Jan 2012 12:38:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Igor Mammedov <imammedo@redhat.com>
Message-ID: <20120124173827.GA10434@phenom.dumpdata.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-5-git-send-email-drjones@redhat.com>
	<20120123183454.GA12542@phenom.dumpdata.com>
	<4F1E6C17.7060609@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1E6C17.7060609@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F1EED20.0122,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	jeremy@goop.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
 config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 09:30:15AM +0100, Igor Mammedov wrote:
> On 01/23/2012 07:34 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
> >>Add a description to the config menu for xen tmem.
> >
> >I am not sure what this patch gets us. If this is to minimize the
> >size of the module - so say it gets loaded, but tmem-enabled is
> >not set nor cleancache and we just have it consuming memory - we can do it
> >via returning -ENODEV on the module load.
> 
> But why compile in something that one may never use? At least with this patch
> I'll have a choice to turn it off if I don't need it.

Then this patch is misleading. It should state at the start
what its purpose is. It sounds like adding the description is just
a way for the real purpose of this patch - which is to disable tmem.

> For example when I build hardened kernel, I'd like to turn of all unnecessary
> features for a particular config (i.e. reduce attack surface as much as possible).

The 'tmem' gets turned off if you disable cleancache. Can't you just
disable cleancache in your hardened config?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:41:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:41:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkMa-00078F-5G; Tue, 24 Jan 2012 17:40:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpkMY-000783-GV
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:40:54 +0000
Received: from [85.158.138.51:43203] by server-8.bemta-3.messagelabs.com id
	0D/AB-31878-52DEE1F4; Tue, 24 Jan 2012 17:40:53 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327426851!10446993!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwMDcxOA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 852 invoked from network); 24 Jan 2012 17:40:53 -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; 24 Jan 2012 17:40:53 -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
	q0OHej4g013742
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 24 Jan 2012 17:40:47 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
	q0OHeh2k023988
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 24 Jan 2012 17:40:44 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
	q0OHehDl011746; Tue, 24 Jan 2012 11:40:43 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Jan 2012 09:40:43 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 6B45F4016B; Tue, 24 Jan 2012 12:38:27 -0500 (EST)
Date: Tue, 24 Jan 2012 12:38:27 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Igor Mammedov <imammedo@redhat.com>
Message-ID: <20120124173827.GA10434@phenom.dumpdata.com>
References: <1325842991-4404-1-git-send-email-drjones@redhat.com>
	<1325842991-4404-5-git-send-email-drjones@redhat.com>
	<20120123183454.GA12542@phenom.dumpdata.com>
	<4F1E6C17.7060609@redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F1E6C17.7060609@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090205.4F1EED20.0122,ss=1,re=0.000,fgs=0
Cc: Andrew Jones <drjones@redhat.com>, xen-devel@lists.xensource.com,
	jeremy@goop.org, virtualization@lists.linux-foundation.org
Subject: Re: [Xen-devel] [PATCH 4/4] xen kconfig: describe xen tmem in the
 config menu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 09:30:15AM +0100, Igor Mammedov wrote:
> On 01/23/2012 07:34 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jan 06, 2012 at 10:43:11AM +0100, Andrew Jones wrote:
> >>Add a description to the config menu for xen tmem.
> >
> >I am not sure what this patch gets us. If this is to minimize the
> >size of the module - so say it gets loaded, but tmem-enabled is
> >not set nor cleancache and we just have it consuming memory - we can do it
> >via returning -ENODEV on the module load.
> 
> But why compile in something that one may never use? At least with this patch
> I'll have a choice to turn it off if I don't need it.

Then this patch is misleading. It should state at the start
what its purpose is. It sounds like adding the description is just
a way for the real purpose of this patch - which is to disable tmem.

> For example when I build hardened kernel, I'd like to turn of all unnecessary
> features for a particular config (i.e. reduce attack surface as much as possible).

The 'tmem' gets turned off if you disable cleancache. Can't you just
disable cleancache in your hardened config?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 17:44:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkPh-0007QC-PE; Tue, 24 Jan 2012 17:44: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 1RpkPg-0007PZ-GO
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:44:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327427041!12410345!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26441 invoked from network); 24 Jan 2012 17:44:01 -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;
	24 Jan 2012 17:44:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10256981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 17:44: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, 24 Jan 2012 17:44:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RpkPY-0001JT-CZ; Tue, 24 Jan 2012 17:44:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpkPY-0005U3-AL;
	Tue, 24 Jan 2012 17:44:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.60896.125888.550392@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 17:44:00 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120124164815.GA14906@ocelot.phlegethon.org>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
	<20120124164815.GA14906@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Adin Scannell <adin@scannel.ca>, "Keir \(Xen.org\)" <keir@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: 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

Tim Deegan writes ("Re: [Xen-devel] [xen-unstable test] 11574: tolerable FAIL"):
> At 16:00 +0000 on 24 Jan (1327420844), Ian Jackson wrote:
> Hmm, Didn't have to pull on that thread too hard to find it's not tied
> to anything.  The access_* arguments to hvm_hap_nested_page_fault()
> aren't plumbed in on AMD:
> 
>     ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);
> 
> so gating behaviour on them is not going to work so well.  Sorry about
> that - I should definitely have caught this.  (But Andres, did you test
> this, or any of your mm work, on AMD?)

In general it's probably unrealistic to ask every submitter to test
every patch on two different systems...

> The attached patch ought to fix it.  Smoke-tested but I won't have
> good enough access to my test machines to check Windows installs before
> Thursday. 

I'd be quite happy if this patch went into -unstable right away.  We
should be able to tell from the automatic tests whether it is awful
:-) and the current situation is rather poor.

Also when we have got rid of this host-specific failure I can push my
new test machinery branch which is intended to (mostly) prevent
host-specific failures being regarded as heisenbugs.

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 Jan 24 17:44:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkPh-0007QC-PE; Tue, 24 Jan 2012 17:44: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 1RpkPg-0007PZ-GO
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:44:08 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327427041!12410345!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26441 invoked from network); 24 Jan 2012 17:44:01 -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;
	24 Jan 2012 17:44:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10256981"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 17:44: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, 24 Jan 2012 17:44:00 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RpkPY-0001JT-CZ; Tue, 24 Jan 2012 17:44:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RpkPY-0005U3-AL;
	Tue, 24 Jan 2012 17:44:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.60896.125888.550392@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 17:44:00 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120124164815.GA14906@ocelot.phlegethon.org>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
	<20120124164815.GA14906@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Adin Scannell <adin@scannel.ca>, "Keir \(Xen.org\)" <keir@xen.org>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: 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

Tim Deegan writes ("Re: [Xen-devel] [xen-unstable test] 11574: tolerable FAIL"):
> At 16:00 +0000 on 24 Jan (1327420844), Ian Jackson wrote:
> Hmm, Didn't have to pull on that thread too hard to find it's not tied
> to anything.  The access_* arguments to hvm_hap_nested_page_fault()
> aren't plumbed in on AMD:
> 
>     ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);
> 
> so gating behaviour on them is not going to work so well.  Sorry about
> that - I should definitely have caught this.  (But Andres, did you test
> this, or any of your mm work, on AMD?)

In general it's probably unrealistic to ask every submitter to test
every patch on two different systems...

> The attached patch ought to fix it.  Smoke-tested but I won't have
> good enough access to my test machines to check Windows installs before
> Thursday. 

I'd be quite happy if this patch went into -unstable right away.  We
should be able to tell from the automatic tests whether it is awful
:-) and the current situation is rather poor.

Also when we have got rid of this host-specific failure I can push my
new test machinery branch which is intended to (mostly) prevent
host-specific failures being regarded as heisenbugs.

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 Jan 24 17:51:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkWY-0007i4-NJ; Tue, 24 Jan 2012 17:51: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 1RpkWX-0007hw-QR
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:51:14 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327427466!8566358!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27027 invoked from network); 24 Jan 2012 17:51:07 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 17:51:07 -0000
Received: by ggnk3 with SMTP id k3so46965719ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 09:51:06 -0800 (PST)
Received: by 10.50.160.131 with SMTP id xk3mr15529073igb.19.1327427466240;
	Tue, 24 Jan 2012 09:51:06 -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 py9sm30445836igc.2.2012.01.24.09.51.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 09:51:05 -0800 (PST)
Message-ID: <4F1EEF85.1020900@codemonkey.ws>
Date: Tue, 24 Jan 2012 11:51:01 -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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1EAEC7.5050304@codemonkey.ws>
	<4F1ED4BF.20505@redhat.com>
In-Reply-To: <4F1ED4BF.20505@redhat.com>
X-Gm-Message-State: ALoCoQk87qX35TMg7d7kiVHLS3+mfnQzA8i25FcZo6XgT23tleqZHTfs9mWTxF1Wpuhs6T6U6Xez
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 09:56 AM, Avi Kivity wrote:
> On 01/24/2012 03:14 PM, Anthony Liguori wrote:
>> On 01/24/2012 05:10 AM, Avi Kivity wrote:
>>> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>>>> Generally speaking, RAM is an independent device in most useful cases.
>>>
>>> Can you give examples?  Do you mean a subdevice with composition, or a
>>> really independent device?
>>
>> I expect we'll have one Ram device.  It's size will be configurable.
>> One Ram device will hang off of the machine which would be the main ram.
>
> We'll also have a hotpluggable variant which talks to some GPIOs.  A
> motherboard may support multiple slots with such devices.

Yup.  And boards can subclass the Ram device in order to be able to restrict the 
valid RAM sizes.

-m just becomes an analysis to set the ram size for a ram device.  The 
infrastructure around RAMBlock, etc. would go away as each RAMBlock would 
correspond to a Ram device.

>> A video card would have a Ram device via composition.
>
> IMO, overkill.

I think it's a lot of refactoring to get there and it's not the most critical 
infrastructure changes we have coming up, but I think it would be nice to get 
there eventually.

>
>>
>> The important consideration about reset is how it propagates.  My
>> expectation is that we'll propagate reset through the composition tree
>> in a preorder transversal.  That means in the VGA device reset
>> function, it's child device (Ram) has not been reset yet.
>
> Doesn't depth first make more sense?

Yes, it would be depth first, but you're looking for a preorder and post order 
hook.  In otherwords:

void do_reset(DeviceState *dev)
{
     dev->pre_reset(dev);  // this is preorder
     do_reset_all(dev->children);
     dev->post_reset(dev);  // this is postorder
}

The PCI bus overloads the reset handler and does a post-order reset.  I guess I 
can rationalize it after all but it's not entirely clear to me that a pre_reset 
hook isn't necessary too.

>  A bus is considered reset after
> all devices in the bus have been reset.
>
>
>>
>>>> We really should view RAM as just another device so I don't like the
>>>> idea of propagating a global concept of "when RAM is restored" because
>>>> that treats it specially compared to other devices.
>>>
>>> Agree.  In fact the first step has been taken as now creating a RAM
>>> region with memory_region_init_ram() doesn't register it for migration.
>>> The next step would be a VMSTATE_RAM() to make it part of the containing
>>> device.
>>
>> That's not necessary (or wise).
>>
>> Let's not confuse a Ram device with a MemoryRegion.  They are separate
>> things and should be treated as separate things.  I thought we
>> discussed that MemoryRegions are stateless (or at least, there state
>> is all derived) and don't need to be serialized?
>
> Well, the actual bits in memory are state.  All other attributes are
> indeed derived.
>
> I just think that making any device that has a bit of RAM a composed
> device is overkill.  What do we gain from it?  The cost is not trivial.

The cost of composition is pretty trivial.

struct VGADevice {
    DeviceState parent;

    Ram vga_ram;
};

static void vga_device_initfn(Object *obj)
{
    VGADevice *vga = VGA(obj);

    object_property_add_child(obj, "vram", (Object *)&vga_ram,
                              TYPE_RAM, NULL);
}

Now a user can control the VGA ram size by accessing vga/vram.size = 16M.

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 Tue Jan 24 17:51:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 17:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkWY-0007i4-NJ; Tue, 24 Jan 2012 17:51: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 1RpkWX-0007hw-QR
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 17:51:14 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327427466!8566358!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27027 invoked from network); 24 Jan 2012 17:51:07 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 17:51:07 -0000
Received: by ggnk3 with SMTP id k3so46965719ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 09:51:06 -0800 (PST)
Received: by 10.50.160.131 with SMTP id xk3mr15529073igb.19.1327427466240;
	Tue, 24 Jan 2012 09:51:06 -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 py9sm30445836igc.2.2012.01.24.09.51.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Tue, 24 Jan 2012 09:51:05 -0800 (PST)
Message-ID: <4F1EEF85.1020900@codemonkey.ws>
Date: Tue, 24 Jan 2012 11:51:01 -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: <alpine.DEB.2.00.1201201457040.3196@kaball-desktop>
	<4F19AB66.8060901@siemens.com>
	<alpine.DEB.2.00.1201231042250.3196@kaball-desktop>
	<4F1D4974.4090003@siemens.com>
	<alpine.DEB.2.00.1201231154050.3196@kaball-desktop>
	<4F1D4E43.7000501@siemens.com>
	<alpine.DEB.2.00.1201231427110.3196@kaball-desktop>
	<4F1D80BA.1040504@siemens.com>
	<alpine.DEB.2.00.1201231554550.3196@kaball-desktop>
	<4F1D9546.4040801@siemens.com> <4F1D9649.1000102@codemonkey.ws>
	<4F1E91AF.9040402@redhat.com> <4F1EAEC7.5050304@codemonkey.ws>
	<4F1ED4BF.20505@redhat.com>
In-Reply-To: <4F1ED4BF.20505@redhat.com>
X-Gm-Message-State: ALoCoQk87qX35TMg7d7kiVHLS3+mfnQzA8i25FcZo6XgT23tleqZHTfs9mWTxF1Wpuhs6T6U6Xez
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/24/2012 09:56 AM, Avi Kivity wrote:
> On 01/24/2012 03:14 PM, Anthony Liguori wrote:
>> On 01/24/2012 05:10 AM, Avi Kivity wrote:
>>> On 01/23/2012 07:18 PM, Anthony Liguori wrote:
>>>> Generally speaking, RAM is an independent device in most useful cases.
>>>
>>> Can you give examples?  Do you mean a subdevice with composition, or a
>>> really independent device?
>>
>> I expect we'll have one Ram device.  It's size will be configurable.
>> One Ram device will hang off of the machine which would be the main ram.
>
> We'll also have a hotpluggable variant which talks to some GPIOs.  A
> motherboard may support multiple slots with such devices.

Yup.  And boards can subclass the Ram device in order to be able to restrict the 
valid RAM sizes.

-m just becomes an analysis to set the ram size for a ram device.  The 
infrastructure around RAMBlock, etc. would go away as each RAMBlock would 
correspond to a Ram device.

>> A video card would have a Ram device via composition.
>
> IMO, overkill.

I think it's a lot of refactoring to get there and it's not the most critical 
infrastructure changes we have coming up, but I think it would be nice to get 
there eventually.

>
>>
>> The important consideration about reset is how it propagates.  My
>> expectation is that we'll propagate reset through the composition tree
>> in a preorder transversal.  That means in the VGA device reset
>> function, it's child device (Ram) has not been reset yet.
>
> Doesn't depth first make more sense?

Yes, it would be depth first, but you're looking for a preorder and post order 
hook.  In otherwords:

void do_reset(DeviceState *dev)
{
     dev->pre_reset(dev);  // this is preorder
     do_reset_all(dev->children);
     dev->post_reset(dev);  // this is postorder
}

The PCI bus overloads the reset handler and does a post-order reset.  I guess I 
can rationalize it after all but it's not entirely clear to me that a pre_reset 
hook isn't necessary too.

>  A bus is considered reset after
> all devices in the bus have been reset.
>
>
>>
>>>> We really should view RAM as just another device so I don't like the
>>>> idea of propagating a global concept of "when RAM is restored" because
>>>> that treats it specially compared to other devices.
>>>
>>> Agree.  In fact the first step has been taken as now creating a RAM
>>> region with memory_region_init_ram() doesn't register it for migration.
>>> The next step would be a VMSTATE_RAM() to make it part of the containing
>>> device.
>>
>> That's not necessary (or wise).
>>
>> Let's not confuse a Ram device with a MemoryRegion.  They are separate
>> things and should be treated as separate things.  I thought we
>> discussed that MemoryRegions are stateless (or at least, there state
>> is all derived) and don't need to be serialized?
>
> Well, the actual bits in memory are state.  All other attributes are
> indeed derived.
>
> I just think that making any device that has a bit of RAM a composed
> device is overkill.  What do we gain from it?  The cost is not trivial.

The cost of composition is pretty trivial.

struct VGADevice {
    DeviceState parent;

    Ram vga_ram;
};

static void vga_device_initfn(Object *obj)
{
    VGADevice *vga = VGA(obj);

    object_property_add_child(obj, "vram", (Object *)&vga_ram,
                              TYPE_RAM, NULL);
}

Now a user can control the VGA ram size by accessing vga/vram.size = 16M.

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 Tue Jan 24 18:03:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18: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 1RpkiV-0007vu-VM; Tue, 24 Jan 2012 18:03:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RpkiU-0007vp-Oa
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:03:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327428208!11794687!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 25592 invoked from network); 24 Jan 2012 18:03:28 -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; 24 Jan 2012 18:03:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RpkiN-00060c-77; Tue, 24 Jan 2012 18:03:27 +0000
Date: Tue, 24 Jan 2012 18:03:27 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120124180327.GB14906@ocelot.phlegethon.org>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
	<20120124164815.GA14906@ocelot.phlegethon.org>
	<20254.60896.125888.550392@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20254.60896.125888.550392@mariner.uk.xensource.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>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Adin Scannell <adin@scannel.ca>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: 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

At 17:44 +0000 on 24 Jan (1327427040), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [xen-unstable test] 11574: tolerable FAIL"):
> > At 16:00 +0000 on 24 Jan (1327420844), Ian Jackson wrote:
> > Hmm, Didn't have to pull on that thread too hard to find it's not tied
> > to anything.  The access_* arguments to hvm_hap_nested_page_fault()
> > aren't plumbed in on AMD:
> > 
> >     ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);
> > 
> > so gating behaviour on them is not going to work so well.  Sorry about
> > that - I should definitely have caught this.  (But Andres, did you test
> > this, or any of your mm work, on AMD?)
> 
> In general it's probably unrealistic to ask every submitter to test
> every patch on two different systems...

True.

> > The attached patch ought to fix it.  Smoke-tested but I won't have
> > good enough access to my test machines to check Windows installs before
> > Thursday. 
> 
> I'd be quite happy if this patch went into -unstable right away.  We
> should be able to tell from the automatic tests whether it is awful
> :-) and the current situation is rather poor.

Done.

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 Jan 24 18:03:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18: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 1RpkiV-0007vu-VM; Tue, 24 Jan 2012 18:03:35 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RpkiU-0007vp-Oa
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:03:34 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327428208!11794687!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 25592 invoked from network); 24 Jan 2012 18:03:28 -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; 24 Jan 2012 18:03:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RpkiN-00060c-77; Tue, 24 Jan 2012 18:03:27 +0000
Date: Tue, 24 Jan 2012 18:03:27 +0000
From: Tim Deegan <tim@xen.org>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120124180327.GB14906@ocelot.phlegethon.org>
References: <osstest-11574-mainreport@xen.org>
	<20254.39351.854362.661374@mariner.uk.xensource.com>
	<20254.54700.872146.773765@mariner.uk.xensource.com>
	<20120124164815.GA14906@ocelot.phlegethon.org>
	<20254.60896.125888.550392@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20254.60896.125888.550392@mariner.uk.xensource.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>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Adin Scannell <adin@scannel.ca>
Subject: Re: [Xen-devel] [xen-unstable test] 11574: 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

At 17:44 +0000 on 24 Jan (1327427040), Ian Jackson wrote:
> Tim Deegan writes ("Re: [Xen-devel] [xen-unstable test] 11574: tolerable FAIL"):
> > At 16:00 +0000 on 24 Jan (1327420844), Ian Jackson wrote:
> > Hmm, Didn't have to pull on that thread too hard to find it's not tied
> > to anything.  The access_* arguments to hvm_hap_nested_page_fault()
> > aren't plumbed in on AMD:
> > 
> >     ret = hvm_hap_nested_page_fault(gpa, 0, ~0ul, 0, 0, 0, 0);
> > 
> > so gating behaviour on them is not going to work so well.  Sorry about
> > that - I should definitely have caught this.  (But Andres, did you test
> > this, or any of your mm work, on AMD?)
> 
> In general it's probably unrealistic to ask every submitter to test
> every patch on two different systems...

True.

> > The attached patch ought to fix it.  Smoke-tested but I won't have
> > good enough access to my test machines to check Windows installs before
> > Thursday. 
> 
> I'd be quite happy if this patch went into -unstable right away.  We
> should be able to tell from the automatic tests whether it is awful
> :-) and the current situation is rather poor.

Done.

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 Jan 24 18:05:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkkQ-00080W-Fz; Tue, 24 Jan 2012 18:05:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RpkkO-00080K-Lw
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:05:32 +0000
Received: from [85.158.138.51:25134] by server-8.bemta-3.messagelabs.com id
	52/3C-31878-BE2FE1F4; Tue, 24 Jan 2012 18:05:31 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327428330!10513708!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13360 invoked from network); 24 Jan 2012 18:05:31 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 18:05:31 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 77035215B1
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 13:05:29 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute4.internal (MEProxy); Tue, 24 Jan 2012 13:05:29 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	I/+8XE2CgBiQMbdL2KYQ/9Z2a3E=; b=jxyC2uxgyvCek3UOTu7bCX44vUzduuSP
	+LbRnP9QOGDDLoPvM0JGkzRB6FP1vMwHTB330oCzUgZ9/bEWVT6xwlVz02qRrvnu
	ZD6MijB3Iktfw2XYERh4ai4Fp53hN3ri1mXRWMCbJdYyJ+KCS/70ia2mmiUOAoiI
	ZYnu+XSmIX8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=I/+8XE2CgBiQMbdL2KYQ/9Z2a3E=; b=
	BBfAoo458terTFOz4PytNH9yawioGfnV0pOrc3MFcGsdPfYDU3ovWBmC19TZSW9e
	QF9h9woJELwDUF41ziGqQxEuw60NniuCsNjQJt6dwibWfzU+qhhC4FnZWQq7b5cp
	LVObn47VQBMxe/rGVSMOdPQfEs0/4D2earziHfN7aQ4=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 4D420A000A6; Tue, 24 Jan 2012 13:05:29 -0500 (EST)
Message-Id: <1327428329.24310.140661027473797@webmail.messagingengine.com>
X-Sasl-Enc: YIYRULQF56Tw7sSiZOziuRY1o37mJ+myhwISbK0pSg31 1327428329
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><1327318076.24561.63.camel@zakaz.uk.xensource.com><1327332514.25697.140661026919117@webmail.messagingengine.com><1327415184.24561.182.camel@zakaz.uk.xensource.com><1327420611.19936.140661027415609@webmail.messagingengine.com><1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
In-Reply-To: <1327425015.8709.140661027442201@webmail.messagingengine.com>
Date: Tue, 24 Jan 2012 10:05:29 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

On Tue, Jan 24, 2012, at 09:10 AM, erin.balid@inoutbox.com wrote:
> > At this point I'm afraid my only suggesting is to drop "echo made it to
> > XXX" breadcrumbs throughout the script and try to narrow down to the
> > line which exits.
> 
> I'll give that a try and report.

I can't figure out how to get xl to output to a xend-debug.log (xm does,
as expected).

Using the same log redirection you mentioned before

edit /etc/xen/scripts/vif-bridge
	#!/bin/bash
+       exec 1>>/tmp/vif-bridge.log
+       exec 2>&1
+       echo "`date`: Running $0 $*"
...
+       ## TEST ##
+       echo "made it to 001"

	dir=$(dirname "$0")
	. "$dir/vif-common.sh"

+       ## TEST ##
+       echo "made it to 002"


	domu=$(xenstore_read_default "$XENBUS_PATH/domain" "")
	if [ -z "$domu" ]
	then
	    log debug "No device details in $XENBUS_PATH, exiting."
	    exit 0
	fi

+       ## TEST ##
+       echo "made it to 003"
...


Then

xl destroy test
xl create /etc/xen/vm/test.cfg

tail -f /tmp/vif-bridge.log
 Tue Jan 24 09:59:29 PST 2012: Running /etc/xen/scripts/vif-bridge
 online type_if=vif
  made it to 001
  made it to 002
  Tue Jan 24 09:59:29 PST 2012: Running /etc/xen/scripts/vif-bridge
  online
  made it to 001
  made it to 002

Never makes it to "003".

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:05:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18:05:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpkkQ-00080W-Fz; Tue, 24 Jan 2012 18:05:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RpkkO-00080K-Lw
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:05:32 +0000
Received: from [85.158.138.51:25134] by server-8.bemta-3.messagelabs.com id
	52/3C-31878-BE2FE1F4; Tue, 24 Jan 2012 18:05:31 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327428330!10513708!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13360 invoked from network); 24 Jan 2012 18:05:31 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 18:05:31 -0000
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 77035215B1
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 13:05:29 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute4.internal (MEProxy); Tue, 24 Jan 2012 13:05:29 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	I/+8XE2CgBiQMbdL2KYQ/9Z2a3E=; b=jxyC2uxgyvCek3UOTu7bCX44vUzduuSP
	+LbRnP9QOGDDLoPvM0JGkzRB6FP1vMwHTB330oCzUgZ9/bEWVT6xwlVz02qRrvnu
	ZD6MijB3Iktfw2XYERh4ai4Fp53hN3ri1mXRWMCbJdYyJ+KCS/70ia2mmiUOAoiI
	ZYnu+XSmIX8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=I/+8XE2CgBiQMbdL2KYQ/9Z2a3E=; b=
	BBfAoo458terTFOz4PytNH9yawioGfnV0pOrc3MFcGsdPfYDU3ovWBmC19TZSW9e
	QF9h9woJELwDUF41ziGqQxEuw60NniuCsNjQJt6dwibWfzU+qhhC4FnZWQq7b5cp
	LVObn47VQBMxe/rGVSMOdPQfEs0/4D2earziHfN7aQ4=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 4D420A000A6; Tue, 24 Jan 2012 13:05:29 -0500 (EST)
Message-Id: <1327428329.24310.140661027473797@webmail.messagingengine.com>
X-Sasl-Enc: YIYRULQF56Tw7sSiZOziuRY1o37mJ+myhwISbK0pSg31 1327428329
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><1327318076.24561.63.camel@zakaz.uk.xensource.com><1327332514.25697.140661026919117@webmail.messagingengine.com><1327415184.24561.182.camel@zakaz.uk.xensource.com><1327420611.19936.140661027415609@webmail.messagingengine.com><1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
In-Reply-To: <1327425015.8709.140661027442201@webmail.messagingengine.com>
Date: Tue, 24 Jan 2012 10:05:29 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

On Tue, Jan 24, 2012, at 09:10 AM, erin.balid@inoutbox.com wrote:
> > At this point I'm afraid my only suggesting is to drop "echo made it to
> > XXX" breadcrumbs throughout the script and try to narrow down to the
> > line which exits.
> 
> I'll give that a try and report.

I can't figure out how to get xl to output to a xend-debug.log (xm does,
as expected).

Using the same log redirection you mentioned before

edit /etc/xen/scripts/vif-bridge
	#!/bin/bash
+       exec 1>>/tmp/vif-bridge.log
+       exec 2>&1
+       echo "`date`: Running $0 $*"
...
+       ## TEST ##
+       echo "made it to 001"

	dir=$(dirname "$0")
	. "$dir/vif-common.sh"

+       ## TEST ##
+       echo "made it to 002"


	domu=$(xenstore_read_default "$XENBUS_PATH/domain" "")
	if [ -z "$domu" ]
	then
	    log debug "No device details in $XENBUS_PATH, exiting."
	    exit 0
	fi

+       ## TEST ##
+       echo "made it to 003"
...


Then

xl destroy test
xl create /etc/xen/vm/test.cfg

tail -f /tmp/vif-bridge.log
 Tue Jan 24 09:59:29 PST 2012: Running /etc/xen/scripts/vif-bridge
 online type_if=vif
  made it to 001
  made it to 002
  Tue Jan 24 09:59:29 PST 2012: Running /etc/xen/scripts/vif-bridge
  online
  made it to 001
  made it to 002

Never makes it to "003".

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:19:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18: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 1Rpkxs-0008Ux-2p; Tue, 24 Jan 2012 18:19:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpkxr-0008U3-2G
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:19:27 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327429160!12378689!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32328 invoked from network); 24 Jan 2012 18:19:20 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 18:19:20 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CF7BC20B86
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 13:19:19 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Tue, 24 Jan 2012 13:19:19 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	P8L/L2AyO74Lvh9fcftCR1sG/GA=; b=e2KtEFga2kYEIuUTj0QKrD6HhBJ6okRH
	Olfc9XzZNjC8i3Qj7hM/sNk//1hlRhRIr74a3RR0/MfBjdJE8GYPYyBeWVNQr4wj
	Lgax8lYIBUHIsv9NaNXMt136kBFVFeQ2LBSKJSBRtfaSgYGdCU41znUKUOU3HHVR
	Kk4M424oTJM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=P8L/L2AyO74Lvh9fcftCR1sG/GA=; b=
	e9TVA0BvKK2Axixxk+wBqPoMWPC9ihJZxpogD48kVMn+JUbJ8rOtZ4+yoXAtPDNh
	DYioO1aXpDCYp+HIokDerpN+uG97ZUAkajT6RIBzBlevxEda4QyiqEWZqi0BuThj
	PTnMaH0JbGzLTRuwzWzi6RVyRITiR8VCQy/0pxxSGaU=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id A8258A000A6; Tue, 24 Jan 2012 13:19:19 -0500 (EST)
Message-Id: <1327429159.27858.140661027476141@webmail.messagingengine.com>
X-Sasl-Enc: CtIEEX/59Mrl62UMaeT80r9OwtlbF9biAP4YeR2KAfjg 1327429159
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><1327318076.24561.63.camel@zakaz.uk.xensource.com><1327332514.25697.140661026919117@webmail.messagingengine.com><1327415184.24561.182.camel@zakaz.uk.xensource.com><1327420611.19936.140661027415609@webmail.messagingengine.com><1327423312.24561.211.camel@zakaz.uk.xensource.com><1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
In-Reply-To: <1327428329.24310.140661027473797@webmail.messagingengine.com>
Date: Tue, 24 Jan 2012 10:19:19 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

On Tue, Jan 24, 2012, at 10:05 AM, erin.balid@inoutbox.com wrote:
> I can't figure out how to get xl to output to a xend-debug.log (xm does,
> as expected).


Reading http://www.gossamer-threads.com/lists/xen/devel/198734, and
checking "-vvv" console output

xl destroy test
xl -vvv create /etc/xen/vm/test.cfg

XEND_DEBUG = 1
Parsing config file /etc/xen/vm/test.cfg
libxl: debug: libxl.c:1208:libxl_device_disk_local_attach attaching PHY
disk /dev/XenVols/test_boot to domain 0
domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvdc1
resume=/dev/xvdb1 kbdtype=us headless text quiet nofb selinux=0
apparmor-0 edd=off splash=silent noshell showopts root=/dev/xvdc1
textmode=1 xencons=xvc0 noirqdebug", features="(null)"
domainbuilder: detail: xc_dom_kernel_mem: called
domainbuilder: detail: xc_dom_malloc            : 11850 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x425f68 -> 0xb92a70
domainbuilder: detail: xc_dom_ramdisk_mem: called
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, 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
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x2000 memsz=0x8a5000
xc: detail: elf_parse_binary: phdr: paddr=0x8a7000 memsz=0x7a0e8
xc: detail: elf_parse_binary: phdr: paddr=0x922000 memsz=0xaac0
xc: detail: elf_parse_binary: phdr: paddr=0x92d000 memsz=0x158000
xc: detail: elf_parse_binary: memory: 0x2000 -> 0xa85000
xc: detail: elf_xen_parse_note: GUEST_OS = "linux"
xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6"
xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0"
xc: detail: elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0x0
xc: detail: elf_xen_parse_note: ENTRY = 0xffffffff80002000
xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff80003000
xc: detail: elf_xen_parse_note: unknown xen elf note (0xd)
xc: detail: elf_xen_parse_note: MOD_START_PFN = 0x1
xc: detail: elf_xen_parse_note: INIT_P2M = 0xffffea0000000000
xc: detail: elf_xen_parse_note: FEATURES =
"writable_page_tables|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
xc: detail: elf_xen_parse_note: SUPPORTED_FEATURES = 0x80f
xc: detail: elf_xen_parse_note: LOADER = "generic"
xc: detail: elf_xen_parse_note: SUSPEND_CANCEL = 0x1
xc: detail: elf_xen_addr_calc_check: addresses:
xc: detail:     virt_base        = 0xffffffff80000000
xc: detail:     elf_paddr_offset = 0x0
xc: detail:     virt_offset      = 0xffffffff80000000
xc: detail:     virt_kstart      = 0xffffffff80002000
xc: detail:     virt_kend        = 0xffffffff80a85000
xc: detail:     virt_entry       = 0xffffffff80002000
xc: detail:     p2m_base         = 0xffffea0000000000
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64:
0xffffffff80002000 -> 0xffffffff80a85000
domainbuilder: detail: xc_dom_mem_init: mem 2048 MB, pages 0x80000
pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x80000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
domainbuilder: detail: xc_dom_malloc            : 4096 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       :
0xffffffff80002000 -> 0xffffffff80a85000  (pfn 0x2 + 0xa83 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x2+0xa83 at
0x7fcd83941000
xc: detail: elf_load_binary: phdr 0 at 0x0x7fcd83941000 ->
0x0x7fcd841e6000
xc: detail: elf_load_binary: phdr 1 at 0x0x7fcd841e6000 ->
0x0x7fcd842600e8
xc: detail: elf_load_binary: phdr 2 at 0x0x7fcd84261000 ->
0x0x7fcd8426bac0
xc: detail: elf_load_binary: phdr 3 at 0x0x7fcd8426c000 ->
0x0x7fcd842d1000
domainbuilder: detail: xc_dom_alloc_segment:   ramdisk      :
0xffffffff80a85000 -> 0xffffffff82078000  (pfn 0xa85 + 0x15f3 pages)
domainbuilder: detail: xc_dom_malloc            : 131 kB
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa85+0x15f3
at 0x7fcd8234e000
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x94895f -> 0x15f2e10
domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    :
0xffffffff82078000 -> 0xffffffff82478000  (pfn 0x2078 + 0x400 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x2078+0x400
at 0x7fcd81f4e000
domainbuilder: detail: xc_dom_alloc_page   :   start info   :
0xffffffff82478000 (pfn 0x2478)
domainbuilder: detail: xc_dom_alloc_page   :   xenstore     :
0xffffffff82479000 (pfn 0x2479)
domainbuilder: detail: xc_dom_alloc_page   :   console      :
0xffffffff8247a000 (pfn 0x247a)
domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48:
0xffff000000000000 -> 0xffffffffffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39:
0xffffff8000000000 -> 0xffffffffffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30:
0xffffffff80000000 -> 0xffffffffbfffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21:
0xffffffff80000000 -> 0xffffffff827fffff, 20 table(s)
domainbuilder: detail: xc_dom_alloc_segment:   page tables  :
0xffffffff8247b000 -> 0xffffffff82492000  (pfn 0x247b + 0x17 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x247b+0x17
at 0x7fcd81f37000
domainbuilder: detail: xc_dom_alloc_page   :   boot stack   :
0xffffffff82492000 (pfn 0x2492)
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end :
0xffffffff82493000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end :
0xffffffff82800000
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-x86_64 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_32
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_64
domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x80000
domainbuilder: detail: clear_page: pfn 0x247a, mfn 0x11fe01
domainbuilder: detail: clear_page: pfn 0x2479, mfn 0x11fe02
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x2478+0x1
at 0x7fcd889b0000
domainbuilder: detail: start_info_x86_64: called
domainbuilder: detail: setup_hypercall_page: vaddr=0xffffffff80003000
pfn=0x3
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 16168 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 0 bytes
domainbuilder: detail:       domU mmap          : 36 MB
domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn
0xcfc5c
domainbuilder: detail: shared_info_x86_64: called
domainbuilder: detail: vcpu_x86_64: called
domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x247b mfn 0x11fe00
domainbuilder: detail: launch_vm: called, ctxt=0x7fffa5f0a510
domainbuilder: detail: xc_dom_release: called
Daemon running with PID 2864
xc: debug: hypercall buffer: total allocations:99 total releases:99
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:94 misses:2 toobig:3

Does that help at all?

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:19:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18: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 1Rpkxs-0008Ux-2p; Tue, 24 Jan 2012 18:19:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpkxr-0008U3-2G
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:19:27 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327429160!12378689!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32328 invoked from network); 24 Jan 2012 18:19:20 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 18:19:20 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CF7BC20B86
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 13:19:19 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Tue, 24 Jan 2012 13:19:19 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:references:subject:in-reply-to:date; s=mesmtp; bh=
	P8L/L2AyO74Lvh9fcftCR1sG/GA=; b=e2KtEFga2kYEIuUTj0QKrD6HhBJ6okRH
	Olfc9XzZNjC8i3Qj7hM/sNk//1hlRhRIr74a3RR0/MfBjdJE8GYPYyBeWVNQr4wj
	Lgax8lYIBUHIsv9NaNXMt136kBFVFeQ2LBSKJSBRtfaSgYGdCU41znUKUOU3HHVR
	Kk4M424oTJM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:references:subject
	:in-reply-to:date; s=smtpout; bh=P8L/L2AyO74Lvh9fcftCR1sG/GA=; b=
	e9TVA0BvKK2Axixxk+wBqPoMWPC9ihJZxpogD48kVMn+JUbJ8rOtZ4+yoXAtPDNh
	DYioO1aXpDCYp+HIokDerpN+uG97ZUAkajT6RIBzBlevxEda4QyiqEWZqi0BuThj
	PTnMaH0JbGzLTRuwzWzi6RVyRITiR8VCQy/0pxxSGaU=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id A8258A000A6; Tue, 24 Jan 2012 13:19:19 -0500 (EST)
Message-Id: <1327429159.27858.140661027476141@webmail.messagingengine.com>
X-Sasl-Enc: CtIEEX/59Mrl62UMaeT80r9OwtlbF9biAP4YeR2KAfjg 1327429159
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><1327318076.24561.63.camel@zakaz.uk.xensource.com><1327332514.25697.140661026919117@webmail.messagingengine.com><1327415184.24561.182.camel@zakaz.uk.xensource.com><1327420611.19936.140661027415609@webmail.messagingengine.com><1327423312.24561.211.camel@zakaz.uk.xensource.com><1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
In-Reply-To: <1327428329.24310.140661027473797@webmail.messagingengine.com>
Date: Tue, 24 Jan 2012 10:19:19 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

On Tue, Jan 24, 2012, at 10:05 AM, erin.balid@inoutbox.com wrote:
> I can't figure out how to get xl to output to a xend-debug.log (xm does,
> as expected).


Reading http://www.gossamer-threads.com/lists/xen/devel/198734, and
checking "-vvv" console output

xl destroy test
xl -vvv create /etc/xen/vm/test.cfg

XEND_DEBUG = 1
Parsing config file /etc/xen/vm/test.cfg
libxl: debug: libxl.c:1208:libxl_device_disk_local_attach attaching PHY
disk /dev/XenVols/test_boot to domain 0
domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/xvdc1
resume=/dev/xvdb1 kbdtype=us headless text quiet nofb selinux=0
apparmor-0 edd=off splash=silent noshell showopts root=/dev/xvdc1
textmode=1 xencons=xvc0 noirqdebug", features="(null)"
domainbuilder: detail: xc_dom_kernel_mem: called
domainbuilder: detail: xc_dom_malloc            : 11850 kB
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x425f68 -> 0xb92a70
domainbuilder: detail: xc_dom_ramdisk_mem: called
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.1, 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
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying ELF-generic loader ...
domainbuilder: detail: loader probe OK
xc: detail: elf_parse_binary: phdr: paddr=0x2000 memsz=0x8a5000
xc: detail: elf_parse_binary: phdr: paddr=0x8a7000 memsz=0x7a0e8
xc: detail: elf_parse_binary: phdr: paddr=0x922000 memsz=0xaac0
xc: detail: elf_parse_binary: phdr: paddr=0x92d000 memsz=0x158000
xc: detail: elf_parse_binary: memory: 0x2000 -> 0xa85000
xc: detail: elf_xen_parse_note: GUEST_OS = "linux"
xc: detail: elf_xen_parse_note: GUEST_VERSION = "2.6"
xc: detail: elf_xen_parse_note: XEN_VERSION = "xen-3.0"
xc: detail: elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
xc: detail: elf_xen_parse_note: PADDR_OFFSET = 0x0
xc: detail: elf_xen_parse_note: ENTRY = 0xffffffff80002000
xc: detail: elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff80003000
xc: detail: elf_xen_parse_note: unknown xen elf note (0xd)
xc: detail: elf_xen_parse_note: MOD_START_PFN = 0x1
xc: detail: elf_xen_parse_note: INIT_P2M = 0xffffea0000000000
xc: detail: elf_xen_parse_note: FEATURES =
"writable_page_tables|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
xc: detail: elf_xen_parse_note: SUPPORTED_FEATURES = 0x80f
xc: detail: elf_xen_parse_note: LOADER = "generic"
xc: detail: elf_xen_parse_note: SUSPEND_CANCEL = 0x1
xc: detail: elf_xen_addr_calc_check: addresses:
xc: detail:     virt_base        = 0xffffffff80000000
xc: detail:     elf_paddr_offset = 0x0
xc: detail:     virt_offset      = 0xffffffff80000000
xc: detail:     virt_kstart      = 0xffffffff80002000
xc: detail:     virt_kend        = 0xffffffff80a85000
xc: detail:     virt_entry       = 0xffffffff80002000
xc: detail:     p2m_base         = 0xffffea0000000000
domainbuilder: detail: xc_dom_parse_elf_kernel: xen-3.0-x86_64:
0xffffffff80002000 -> 0xffffffff80a85000
domainbuilder: detail: xc_dom_mem_init: mem 2048 MB, pages 0x80000
pages, 4k each
domainbuilder: detail: xc_dom_mem_init: 0x80000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: x86_compat: guest xen-3.0-x86_64, address size 64
domainbuilder: detail: xc_dom_malloc            : 4096 kB
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment:   kernel       :
0xffffffff80002000 -> 0xffffffff80a85000  (pfn 0x2 + 0xa83 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x2+0xa83 at
0x7fcd83941000
xc: detail: elf_load_binary: phdr 0 at 0x0x7fcd83941000 ->
0x0x7fcd841e6000
xc: detail: elf_load_binary: phdr 1 at 0x0x7fcd841e6000 ->
0x0x7fcd842600e8
xc: detail: elf_load_binary: phdr 2 at 0x0x7fcd84261000 ->
0x0x7fcd8426bac0
xc: detail: elf_load_binary: phdr 3 at 0x0x7fcd8426c000 ->
0x0x7fcd842d1000
domainbuilder: detail: xc_dom_alloc_segment:   ramdisk      :
0xffffffff80a85000 -> 0xffffffff82078000  (pfn 0xa85 + 0x15f3 pages)
domainbuilder: detail: xc_dom_malloc            : 131 kB
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0xa85+0x15f3
at 0x7fcd8234e000
domainbuilder: detail: xc_dom_do_gunzip: unzip ok, 0x94895f -> 0x15f2e10
domainbuilder: detail: xc_dom_alloc_segment:   phys2mach    :
0xffffffff82078000 -> 0xffffffff82478000  (pfn 0x2078 + 0x400 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x2078+0x400
at 0x7fcd81f4e000
domainbuilder: detail: xc_dom_alloc_page   :   start info   :
0xffffffff82478000 (pfn 0x2478)
domainbuilder: detail: xc_dom_alloc_page   :   xenstore     :
0xffffffff82479000 (pfn 0x2479)
domainbuilder: detail: xc_dom_alloc_page   :   console      :
0xffffffff8247a000 (pfn 0x247a)
domainbuilder: detail: nr_page_tables: 0x0000ffffffffffff/48:
0xffff000000000000 -> 0xffffffffffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x0000007fffffffff/39:
0xffffff8000000000 -> 0xffffffffffffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x000000003fffffff/30:
0xffffffff80000000 -> 0xffffffffbfffffff, 1 table(s)
domainbuilder: detail: nr_page_tables: 0x00000000001fffff/21:
0xffffffff80000000 -> 0xffffffff827fffff, 20 table(s)
domainbuilder: detail: xc_dom_alloc_segment:   page tables  :
0xffffffff8247b000 -> 0xffffffff82492000  (pfn 0x247b + 0x17 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x247b+0x17
at 0x7fcd81f37000
domainbuilder: detail: xc_dom_alloc_page   :   boot stack   :
0xffffffff82492000 (pfn 0x2492)
domainbuilder: detail: xc_dom_build_image  : virt_alloc_end :
0xffffffff82493000
domainbuilder: detail: xc_dom_build_image  : virt_pgtab_end :
0xffffffff82800000
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-x86_64 <= matches
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_32
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_32p
domainbuilder: detail: xc_dom_compat_check: supported guest type:
hvm-3.0-x86_64
domainbuilder: detail: xc_dom_update_guest_p2m: dst 64bit, pages 0x80000
domainbuilder: detail: clear_page: pfn 0x247a, mfn 0x11fe01
domainbuilder: detail: clear_page: pfn 0x2479, mfn 0x11fe02
domainbuilder: detail: xc_dom_pfn_to_ptr: domU mapping: pfn 0x2478+0x1
at 0x7fcd889b0000
domainbuilder: detail: start_info_x86_64: called
domainbuilder: detail: setup_hypercall_page: vaddr=0xffffffff80003000
pfn=0x3
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail:    allocated
domainbuilder: detail:       malloc             : 16168 kB
domainbuilder: detail:       anon mmap          : 0 bytes
domainbuilder: detail:    mapped
domainbuilder: detail:       file mmap          : 0 bytes
domainbuilder: detail:       domU mmap          : 36 MB
domainbuilder: detail: arch_setup_bootlate: shared_info: pfn 0x0, mfn
0xcfc5c
domainbuilder: detail: shared_info_x86_64: called
domainbuilder: detail: vcpu_x86_64: called
domainbuilder: detail: vcpu_x86_64: cr3: pfn 0x247b mfn 0x11fe00
domainbuilder: detail: launch_vm: called, ctxt=0x7fffa5f0a510
domainbuilder: detail: xc_dom_release: called
Daemon running with PID 2864
xc: debug: hypercall buffer: total allocations:99 total releases:99
xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
xc: debug: hypercall buffer: cache current size:2
xc: debug: hypercall buffer: cache hits:94 misses:2 toobig:3

Does that help at all?

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:23:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 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 1Rpl1a-0000N3-Og; Tue, 24 Jan 2012 18:23: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 1Rpl1Z-0000Mg-Hg
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:23:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327429391!4897974!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9090 invoked from network); 24 Jan 2012 18:23:11 -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;
	24 Jan 2012 18:23:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10257624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 18:23: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, 24 Jan 2012 18:23: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
	1Rpl1S-0001Wy-TM; Tue, 24 Jan 2012 18:23:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpl1S-0005XF-MW;
	Tue, 24 Jan 2012 18:23:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.63246.632221.124056@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 18:23:10 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: add support fo=
r yajl 2.x"):
> Don't know how difficult it is to update the test bed to use the new
> configure script, ideally it should only require adding "./configure"
> before performing a "make tools". Since I don't know how the test bed
> works, it might be necessary to pass some options to configure
> execution to obtain the same result.

Currently the tester drops a .config in the root directory containing
various tags and urls of the subtrees that the xen tree clones.  Is
that stuff affected by your autoconf series ?

I can easily enough have it test whether ./configure exists and make
it run it if it does.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:23:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 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 1Rpl1a-0000N3-Og; Tue, 24 Jan 2012 18:23: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 1Rpl1Z-0000Mg-Hg
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:23:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327429391!4897974!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9090 invoked from network); 24 Jan 2012 18:23:11 -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;
	24 Jan 2012 18:23:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10257624"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 18:23: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, 24 Jan 2012 18:23: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
	1Rpl1S-0001Wy-TM; Tue, 24 Jan 2012 18:23:10 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rpl1S-0005XF-MW;
	Tue, 24 Jan 2012 18:23:10 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.63246.632221.124056@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 18:23:10 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: add support fo=
r yajl 2.x"):
> Don't know how difficult it is to update the test bed to use the new
> configure script, ideally it should only require adding "./configure"
> before performing a "make tools". Since I don't know how the test bed
> works, it might be necessary to pass some options to configure
> execution to obtain the same result.

Currently the tester drops a .config in the root directory containing
various tags and urls of the subtrees that the xen tree clones.  Is
that stuff affected by your autoconf series ?

I can easily enough have it test whether ./configure exists and make
it run it if it does.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:25:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpl37-0000U1-8H; Tue, 24 Jan 2012 18:24: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 1Rpl35-0000Tj-8K
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:24:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327429442!49916969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22293 invoked from network); 24 Jan 2012 18:24:03 -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;
	24 Jan 2012 18:24:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10257672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 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; Tue, 24 Jan 2012 18:24: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
	1Rpl33-0001Xd-PH; Tue, 24 Jan 2012 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 1Rpl33-0005XP-OO;
	Tue, 24 Jan 2012 18:24:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.63345.742208.74009@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 18:24:49 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: add support fo=
r yajl 2.x"):
> Autotools in general is quite a mess, we don't use automake, but we
> need it to generate config.sub and config.guess (yes, I know I can
> also copy them). That's all we need automake for (don't know why
> autoconf can't do this automatically...)

Please just copy them, and don't run automake.  That's what was done
before automake existed and it's what we should do.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:25:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18:25:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpl37-0000U1-8H; Tue, 24 Jan 2012 18:24: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 1Rpl35-0000Tj-8K
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:24:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327429442!49916969!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22293 invoked from network); 24 Jan 2012 18:24:03 -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;
	24 Jan 2012 18:24:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10257672"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 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; Tue, 24 Jan 2012 18:24: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
	1Rpl33-0001Xd-PH; Tue, 24 Jan 2012 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 1Rpl33-0005XP-OO;
	Tue, 24 Jan 2012 18:24:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.63345.742208.74009@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 18:24:49 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Y6X6SPnFZVGxA_dz_8-NzrcngAeFVqKQuh7Qg_f3ipA@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: add support fo=
r yajl 2.x"):
> Autotools in general is quite a mess, we don't use automake, but we
> need it to generate config.sub and config.guess (yes, I know I can
> also copy them). That's all we need automake for (don't know why
> autoconf can't do this automatically...)

Please just copy them, and don't run automake.  That's what was done
before automake existed and it's what we should do.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:32:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18: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 1RplA7-0000qG-5K; Tue, 24 Jan 2012 18:32:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RplA5-0000q5-O7
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:32:05 +0000
Received: from [85.158.138.51:10099] by server-12.bemta-3.messagelabs.com id
	4A/EC-24557-429FE1F4; Tue, 24 Jan 2012 18:32:04 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327429922!10485126!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16461 invoked from network); 24 Jan 2012 18:32:03 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 18:32:03 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0OIW14Z017065;
	Tue, 24 Jan 2012 13:32:01 -0500
Received: from [172.16.21.50] ([172.16.21.50]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Tue, 24 Jan 2012 13:31:40 -0500
Message-ID: <1327429905.7929.5.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Tobias Geiger <tobias.geiger@vido.info>
Date: Tue, 24 Jan 2012 13:31:45 -0500
In-Reply-To: <201201241537.24507.tobias.geiger@vido.info>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<201201241537.24507.tobias.geiger@vido.info>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 24 Jan 2012 18:31:40.0512 (UTC)
	FILETIME=[6A162E00:01CCDAC6]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > Both setup have the "flaw" that they only work once - meaning
> you
> > >
> > > can't reboot
> > >
> > > > your DomU , cause after the reboot the passed-through Card
> doesnt
> > >
> > > have correct
> > >
> > > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > >
> > > Windows XP and
> > >
> > > > Windows7 )
> > >
> > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > >
> > > Anybody had luck with passing the card more than once to a guest?
> With
> > > any random set of patches?
> >
> 
> I was a bit un-percice regarding the "reboot" issue:
> 
> The passing-through itself works even after a reboot of DomU - the
> rebooted
> System spits out its Graphics normaly through the passed-through Card
> (NVIDA
> or ATI doesnt matter here) ; BUT:
> After a reboot it doesn't work properly. Meaning: Slow 3d Performance,
> i.e.
> unsable for real 3d apps, even a 3d Desktop;
> For example, when the Card gives you 70fps in a Benchmark after a
> fresh Cold
> Boot, it only gives you 5-10fps after a reboot, this will be that low
> until
> you reboot Dom0 also, not only DomU;
> 
> hopefully i described the scenario better now...
> 

Ah, got it.  I hadn't been doing anything 3D intensive, only running the
Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.  I
get the same results (within a fraction of a %) after a cold boot as i
do after rebooting multiple times, and always very close to native.  It
seems i don't have the problem you're having.

Do you get any different log messages after a reboot (xl dmesg, dom0
dmesg, qemu log)?  Have you tried with iommu=verbose to see if there's
any more useful information there?

> 
> > Yes, I've had a machine running for a couple of weeks, hosting a
> Windows
> > 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> > machine multiple times, as well as gone through a couple of xl
> > destroy/create cycles.
> >
> > I only pass it through as a secondary card, as I have the IGD as the
> > primary on the host.  The machine is a DQ67SW with a Core i5.  This
> is
> > running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> patches.
> >
> > I haven't, however, had any luck passing through the IGD to anything
> > other than a Windows XP, and that includes running the latest
> qemu-xen
> > with Jean's patches (opregion, host bridge config space mapping).
> I've
> > been intending to start a separate thread for that...
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:32:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18: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 1RplA7-0000qG-5K; Tue, 24 Jan 2012 18:32:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RplA5-0000q5-O7
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:32:05 +0000
Received: from [85.158.138.51:10099] by server-12.bemta-3.messagelabs.com id
	4A/EC-24557-429FE1F4; Tue, 24 Jan 2012 18:32:04 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327429922!10485126!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16461 invoked from network); 24 Jan 2012 18:32:03 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 18:32:03 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0OIW14Z017065;
	Tue, 24 Jan 2012 13:32:01 -0500
Received: from [172.16.21.50] ([172.16.21.50]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Tue, 24 Jan 2012 13:31:40 -0500
Message-ID: <1327429905.7929.5.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Tobias Geiger <tobias.geiger@vido.info>
Date: Tue, 24 Jan 2012 13:31:45 -0500
In-Reply-To: <201201241537.24507.tobias.geiger@vido.info>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<201201241537.24507.tobias.geiger@vido.info>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 24 Jan 2012 18:31:40.0512 (UTC)
	FILETIME=[6A162E00:01CCDAC6]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > Both setup have the "flaw" that they only work once - meaning
> you
> > >
> > > can't reboot
> > >
> > > > your DomU , cause after the reboot the passed-through Card
> doesnt
> > >
> > > have correct
> > >
> > > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > >
> > > Windows XP and
> > >
> > > > Windows7 )
> > >
> > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > >
> > > Anybody had luck with passing the card more than once to a guest?
> With
> > > any random set of patches?
> >
> 
> I was a bit un-percice regarding the "reboot" issue:
> 
> The passing-through itself works even after a reboot of DomU - the
> rebooted
> System spits out its Graphics normaly through the passed-through Card
> (NVIDA
> or ATI doesnt matter here) ; BUT:
> After a reboot it doesn't work properly. Meaning: Slow 3d Performance,
> i.e.
> unsable for real 3d apps, even a 3d Desktop;
> For example, when the Card gives you 70fps in a Benchmark after a
> fresh Cold
> Boot, it only gives you 5-10fps after a reboot, this will be that low
> until
> you reboot Dom0 also, not only DomU;
> 
> hopefully i described the scenario better now...
> 

Ah, got it.  I hadn't been doing anything 3D intensive, only running the
Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.  I
get the same results (within a fraction of a %) after a cold boot as i
do after rebooting multiple times, and always very close to native.  It
seems i don't have the problem you're having.

Do you get any different log messages after a reboot (xl dmesg, dom0
dmesg, qemu log)?  Have you tried with iommu=verbose to see if there's
any more useful information there?

> 
> > Yes, I've had a machine running for a couple of weeks, hosting a
> Windows
> > 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> > machine multiple times, as well as gone through a couple of xl
> > destroy/create cycles.
> >
> > I only pass it through as a secondary card, as I have the IGD as the
> > primary on the host.  The machine is a DQ67SW with a Core i5.  This
> is
> > running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> patches.
> >
> > I haven't, however, had any luck passing through the IGD to anything
> > other than a Windows XP, and that includes running the latest
> qemu-xen
> > with Jean's patches (opregion, host bridge config space mapping).
> I've
> > been intending to start a separate thread for that...
> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:35:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RplDN-0001HG-I3; Tue, 24 Jan 2012 18:35:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stern+4f088378@rowland.harvard.edu>)
	id 1RplDL-0001H4-SG
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:35:28 +0000
Received: from [85.158.138.51:22075] by server-2.bemta-3.messagelabs.com id
	16/79-24515-EE9FE1F4; Tue, 24 Jan 2012 18:35:26 +0000
X-Env-Sender: stern+4f088378@rowland.harvard.edu
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327430125!10483432!1
X-Originating-IP: [192.131.102.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15401 invoked from network); 24 Jan 2012 18:35:25 -0000
Received: from iolanthe.rowland.org (HELO iolanthe.rowland.org)
	(192.131.102.54) by server-8.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 18:35:25 -0000
Received: (qmail 1528 invoked by uid 2102); 24 Jan 2012 13:35:24 -0500
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 24 Jan 2012 13:35:24 -0500
Date: Tue, 24 Jan 2012 13:35:24 -0500 (EST)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@iolanthe.rowland.org
To: Greg KH <greg@kroah.com>
Message-ID: <Pine.LNX.4.44L0.1201241317120.1200-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Joerg Roedel <joerg.roedel@amd.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Michael Buesch <m@bues.ch>, netdev@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 4/5] Remove useless get_driver()/put_driver()
	calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

As part of the removal of get_driver()/put_driver(), this patch
(as1512) gets rid of various useless and unnecessary calls in several
drivers.  In some cases it may be desirable to pin the driver by
calling try_module_get(), but that can be done later.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: "David S. Miller" <davem@davemloft.net>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Michael Buesch <m@bues.ch>
CC: Joerg Roedel <joerg.roedel@amd.com>

---

 drivers/net/phy/phy_device.c |    6 +-----
 drivers/pci/xen-pcifront.c   |    3 +--
 drivers/ssb/main.c           |   20 ++------------------
 lib/dma-debug.c              |    3 +--
 4 files changed, 5 insertions(+), 27 deletions(-)

Index: usb-3.3/drivers/net/phy/phy_device.c
===================================================================
--- usb-3.3.orig/drivers/net/phy/phy_device.c
+++ usb-3.3/drivers/net/phy/phy_device.c
@@ -915,9 +915,7 @@ static int phy_probe(struct device *dev)
 
 	phydev = to_phy_device(dev);
 
-	/* Make sure the driver is held.
-	 * XXX -- Is this correct? */
-	drv = get_driver(phydev->dev.driver);
+	drv = phydev->dev.driver;
 	phydrv = to_phy_driver(drv);
 	phydev->drv = phydrv;
 
@@ -957,8 +955,6 @@ static int phy_remove(struct device *dev
 
 	if (phydev->drv->remove)
 		phydev->drv->remove(phydev);
-
-	put_driver(dev->driver);
 	phydev->drv = NULL;
 
 	return 0;
Index: usb-3.3/drivers/pci/xen-pcifront.c
===================================================================
--- usb-3.3.orig/drivers/pci/xen-pcifront.c
+++ usb-3.3/drivers/pci/xen-pcifront.c
@@ -593,7 +593,7 @@ static pci_ers_result_t pcifront_common_
 	}
 	pdrv = pcidev->driver;
 
-	if (get_driver(&pdrv->driver)) {
+	if (pdrv->driver) {
 		if (pdrv->err_handler && pdrv->err_handler->error_detected) {
 			dev_dbg(&pcidev->dev,
 				"trying to call AER service\n");
@@ -623,7 +623,6 @@ static pci_ers_result_t pcifront_common_
 				}
 			}
 		}
-		put_driver(&pdrv->driver);
 	}
 	if (!flag)
 		result = PCI_ERS_RESULT_NONE;
Index: usb-3.3/drivers/ssb/main.c
===================================================================
--- usb-3.3.orig/drivers/ssb/main.c
+++ usb-3.3/drivers/ssb/main.c
@@ -140,19 +140,6 @@ static void ssb_device_put(struct ssb_de
 		put_device(dev->dev);
 }
 
-static inline struct ssb_driver *ssb_driver_get(struct ssb_driver *drv)
-{
-	if (drv)
-		get_driver(&drv->drv);
-	return drv;
-}
-
-static inline void ssb_driver_put(struct ssb_driver *drv)
-{
-	if (drv)
-		put_driver(&drv->drv);
-}
-
 static int ssb_device_resume(struct device *dev)
 {
 	struct ssb_device *ssb_dev = dev_to_ssb_dev(dev);
@@ -250,11 +237,9 @@ int ssb_devices_freeze(struct ssb_bus *b
 			ssb_device_put(sdev);
 			continue;
 		}
-		sdrv = ssb_driver_get(drv_to_ssb_drv(sdev->dev->driver));
-		if (!sdrv || SSB_WARN_ON(!sdrv->remove)) {
-			ssb_device_put(sdev);
+		sdrv = drv_to_ssb_drv(sdev->dev->driver);
+		if (SSB_WARN_ON(!sdrv->remove))
 			continue;
-		}
 		sdrv->remove(sdev);
 		ctx->device_frozen[i] = 1;
 	}
@@ -293,7 +278,6 @@ int ssb_devices_thaw(struct ssb_freeze_c
 				   dev_name(sdev->dev));
 			result = err;
 		}
-		ssb_driver_put(sdrv);
 		ssb_device_put(sdev);
 	}
 
Index: usb-3.3/lib/dma-debug.c
===================================================================
--- usb-3.3.orig/lib/dma-debug.c
+++ usb-3.3/lib/dma-debug.c
@@ -170,7 +170,7 @@ static bool driver_filter(struct device
 		return false;
 
 	/* driver filter on but not yet initialized */
-	drv = get_driver(dev->driver);
+	drv = dev->driver;
 	if (!drv)
 		return false;
 
@@ -185,7 +185,6 @@ static bool driver_filter(struct device
 	}
 
 	read_unlock_irqrestore(&driver_name_lock, flags);
-	put_driver(drv);
 
 	return ret;
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:35:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18:35:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RplDN-0001HG-I3; Tue, 24 Jan 2012 18:35:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <stern+4f088378@rowland.harvard.edu>)
	id 1RplDL-0001H4-SG
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:35:28 +0000
Received: from [85.158.138.51:22075] by server-2.bemta-3.messagelabs.com id
	16/79-24515-EE9FE1F4; Tue, 24 Jan 2012 18:35:26 +0000
X-Env-Sender: stern+4f088378@rowland.harvard.edu
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327430125!10483432!1
X-Originating-IP: [192.131.102.54]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15401 invoked from network); 24 Jan 2012 18:35:25 -0000
Received: from iolanthe.rowland.org (HELO iolanthe.rowland.org)
	(192.131.102.54) by server-8.tower-174.messagelabs.com with SMTP;
	24 Jan 2012 18:35:25 -0000
Received: (qmail 1528 invoked by uid 2102); 24 Jan 2012 13:35:24 -0500
Received: from localhost (sendmail-bs@127.0.0.1)
	by localhost with SMTP; 24 Jan 2012 13:35:24 -0500
Date: Tue, 24 Jan 2012 13:35:24 -0500 (EST)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@iolanthe.rowland.org
To: Greg KH <greg@kroah.com>
Message-ID: <Pine.LNX.4.44L0.1201241317120.1200-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Joerg Roedel <joerg.roedel@amd.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Michael Buesch <m@bues.ch>, netdev@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>
Subject: [Xen-devel] [PATCH 4/5] Remove useless get_driver()/put_driver()
	calls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

As part of the removal of get_driver()/put_driver(), this patch
(as1512) gets rid of various useless and unnecessary calls in several
drivers.  In some cases it may be desirable to pin the driver by
calling try_module_get(), but that can be done later.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: "David S. Miller" <davem@davemloft.net>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Michael Buesch <m@bues.ch>
CC: Joerg Roedel <joerg.roedel@amd.com>

---

 drivers/net/phy/phy_device.c |    6 +-----
 drivers/pci/xen-pcifront.c   |    3 +--
 drivers/ssb/main.c           |   20 ++------------------
 lib/dma-debug.c              |    3 +--
 4 files changed, 5 insertions(+), 27 deletions(-)

Index: usb-3.3/drivers/net/phy/phy_device.c
===================================================================
--- usb-3.3.orig/drivers/net/phy/phy_device.c
+++ usb-3.3/drivers/net/phy/phy_device.c
@@ -915,9 +915,7 @@ static int phy_probe(struct device *dev)
 
 	phydev = to_phy_device(dev);
 
-	/* Make sure the driver is held.
-	 * XXX -- Is this correct? */
-	drv = get_driver(phydev->dev.driver);
+	drv = phydev->dev.driver;
 	phydrv = to_phy_driver(drv);
 	phydev->drv = phydrv;
 
@@ -957,8 +955,6 @@ static int phy_remove(struct device *dev
 
 	if (phydev->drv->remove)
 		phydev->drv->remove(phydev);
-
-	put_driver(dev->driver);
 	phydev->drv = NULL;
 
 	return 0;
Index: usb-3.3/drivers/pci/xen-pcifront.c
===================================================================
--- usb-3.3.orig/drivers/pci/xen-pcifront.c
+++ usb-3.3/drivers/pci/xen-pcifront.c
@@ -593,7 +593,7 @@ static pci_ers_result_t pcifront_common_
 	}
 	pdrv = pcidev->driver;
 
-	if (get_driver(&pdrv->driver)) {
+	if (pdrv->driver) {
 		if (pdrv->err_handler && pdrv->err_handler->error_detected) {
 			dev_dbg(&pcidev->dev,
 				"trying to call AER service\n");
@@ -623,7 +623,6 @@ static pci_ers_result_t pcifront_common_
 				}
 			}
 		}
-		put_driver(&pdrv->driver);
 	}
 	if (!flag)
 		result = PCI_ERS_RESULT_NONE;
Index: usb-3.3/drivers/ssb/main.c
===================================================================
--- usb-3.3.orig/drivers/ssb/main.c
+++ usb-3.3/drivers/ssb/main.c
@@ -140,19 +140,6 @@ static void ssb_device_put(struct ssb_de
 		put_device(dev->dev);
 }
 
-static inline struct ssb_driver *ssb_driver_get(struct ssb_driver *drv)
-{
-	if (drv)
-		get_driver(&drv->drv);
-	return drv;
-}
-
-static inline void ssb_driver_put(struct ssb_driver *drv)
-{
-	if (drv)
-		put_driver(&drv->drv);
-}
-
 static int ssb_device_resume(struct device *dev)
 {
 	struct ssb_device *ssb_dev = dev_to_ssb_dev(dev);
@@ -250,11 +237,9 @@ int ssb_devices_freeze(struct ssb_bus *b
 			ssb_device_put(sdev);
 			continue;
 		}
-		sdrv = ssb_driver_get(drv_to_ssb_drv(sdev->dev->driver));
-		if (!sdrv || SSB_WARN_ON(!sdrv->remove)) {
-			ssb_device_put(sdev);
+		sdrv = drv_to_ssb_drv(sdev->dev->driver);
+		if (SSB_WARN_ON(!sdrv->remove))
 			continue;
-		}
 		sdrv->remove(sdev);
 		ctx->device_frozen[i] = 1;
 	}
@@ -293,7 +278,6 @@ int ssb_devices_thaw(struct ssb_freeze_c
 				   dev_name(sdev->dev));
 			result = err;
 		}
-		ssb_driver_put(sdrv);
 		ssb_device_put(sdev);
 	}
 
Index: usb-3.3/lib/dma-debug.c
===================================================================
--- usb-3.3.orig/lib/dma-debug.c
+++ usb-3.3/lib/dma-debug.c
@@ -170,7 +170,7 @@ static bool driver_filter(struct device
 		return false;
 
 	/* driver filter on but not yet initialized */
-	drv = get_driver(dev->driver);
+	drv = dev->driver;
 	if (!drv)
 		return false;
 
@@ -185,7 +185,6 @@ static bool driver_filter(struct device
 	}
 
 	read_unlock_irqrestore(&driver_name_lock, flags);
-	put_driver(drv);
 
 	return ret;
 }


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:42:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18:42:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RplJo-0001pd-J7; Tue, 24 Jan 2012 18:42:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>)
	id 1RplJn-0001pJ-05; Tue, 24 Jan 2012 18:42:07 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327430519!8444482!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30399 invoked from network); 24 Jan 2012 18:42:00 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 18:42:00 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0OIfxn6017490;
	Tue, 24 Jan 2012 13:41:59 -0500
Received: from [172.16.21.50] ([172.16.21.50]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Tue, 24 Jan 2012 13:41:32 -0500
Message-ID: <1327430498.7929.14.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Date: Tue, 24 Jan 2012 13:41:38 -0500
In-Reply-To: <3758972BBA474BCBB9CA5D1D316892E7@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 24 Jan 2012 18:41:32.0969 (UTC)
	FILETIME=[CB37F190:01CCDAC7]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 09:33 -0500, Likarpenkov Alexander wrote:

>  ??>> Anybody had luck with passing the card more than once to a
> guest? With
>  ??>> any random set of patches?
> ^^^^^^^^^^^^^^^^^^^^^^^^
> Better not to quote, than to do wrong quoting!!!
> Also see the question below/
> 
>  d> Yes, I've had a machine running for a couple of weeks, hosting a
> Windows
>  d> 7 domu with a passed-through Radeon 4770.  I've rebooted the
> virtual
>  d> machine multiple times, as well as gone through a couple of xl
>  d> destroy/create cycles.
> 
>  d> I only pass it through as a secondary card, as I have the IGD as
> the
>  d> primary on the host.  The machine is a DQ67SW with a Core i5.
> This is
>  d> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> patches.
> 
>  d> I haven't, however, had any luck passing through the IGD to
> anything
>  d> other than a Windows XP, and that includes running the latest
> qemu-xen
>  d> with Jean's patches (opregion, host bridge config space mapping).
> I've
>  d> been intending to start a separate thread for that...
> 
> Can you put a youtube video start DomU after
> # Xm create
> ???

I use the xl toolstack, not xm.  I don't think xm is being actively
maintained, at least not for current releases.

I don't know what a video could show you.  In the ATI case, there's no
signal until Windows loads the drivers.  It automatically disables the
emulated adapter, so i can watch the BIOS and Windows loading screens
via VNC, then my desktop appears on the monitor and the VNC console goes
black.

In the IGD case, i can see the output from ROMBIOS and the windows
loader (or grub2) on the monitor.  If i'm booting a XP domU, the windows
login screen then appears.  If i'm booting a Win7 domU, the screen goes
black.  If i'm booting a fedora16 domu, the signal vanishes entirely.
In the Win7 case, the domU seems to be stuck in a loop.  In the Fedora
case, i can ssh to the machine and see various WARN_ON dumps in dmesg
related to the i915 driver, and eventually, a message saying it failed
to reset the adapter.

I think that gives you more detail than any video i could post.

> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:42:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 18:42:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RplJo-0001pd-J7; Tue, 24 Jan 2012 18:42:08 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>)
	id 1RplJn-0001pJ-05; Tue, 24 Jan 2012 18:42:07 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327430519!8444482!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30399 invoked from network); 24 Jan 2012 18:42:00 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 18:42:00 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0OIfxn6017490;
	Tue, 24 Jan 2012 13:41:59 -0500
Received: from [172.16.21.50] ([172.16.21.50]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Tue, 24 Jan 2012 13:41:32 -0500
Message-ID: <1327430498.7929.14.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Date: Tue, 24 Jan 2012 13:41:38 -0500
In-Reply-To: <3758972BBA474BCBB9CA5D1D316892E7@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 24 Jan 2012 18:41:32.0969 (UTC)
	FILETIME=[CB37F190:01CCDAC7]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 09:33 -0500, Likarpenkov Alexander wrote:

>  ??>> Anybody had luck with passing the card more than once to a
> guest? With
>  ??>> any random set of patches?
> ^^^^^^^^^^^^^^^^^^^^^^^^
> Better not to quote, than to do wrong quoting!!!
> Also see the question below/
> 
>  d> Yes, I've had a machine running for a couple of weeks, hosting a
> Windows
>  d> 7 domu with a passed-through Radeon 4770.  I've rebooted the
> virtual
>  d> machine multiple times, as well as gone through a couple of xl
>  d> destroy/create cycles.
> 
>  d> I only pass it through as a secondary card, as I have the IGD as
> the
>  d> primary on the host.  The machine is a DQ67SW with a Core i5.
> This is
>  d> running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> patches.
> 
>  d> I haven't, however, had any luck passing through the IGD to
> anything
>  d> other than a Windows XP, and that includes running the latest
> qemu-xen
>  d> with Jean's patches (opregion, host bridge config space mapping).
> I've
>  d> been intending to start a separate thread for that...
> 
> Can you put a youtube video start DomU after
> # Xm create
> ???

I use the xl toolstack, not xm.  I don't think xm is being actively
maintained, at least not for current releases.

I don't know what a video could show you.  In the ATI case, there's no
signal until Windows loads the drivers.  It automatically disables the
emulated adapter, so i can watch the BIOS and Windows loading screens
via VNC, then my desktop appears on the monitor and the VNC console goes
black.

In the IGD case, i can see the output from ROMBIOS and the windows
loader (or grub2) on the monitor.  If i'm booting a XP domU, the windows
login screen then appears.  If i'm booting a Win7 domU, the screen goes
black.  If i'm booting a fedora16 domu, the signal vanishes entirely.
In the Win7 case, the domU seems to be stuck in a loop.  In the Fedora
case, i can ssh to the machine and see various WARN_ON dumps in dmesg
related to the i915 driver, and eventually, a message saying it failed
to reset the adapter.

I think that gives you more detail than any video i could post.

> 
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:43:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 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 1RplL6-0001zg-OA; Tue, 24 Jan 2012 18:43:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RplL5-0001yo-Tg
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:43:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327430601!8571597!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11823 invoked from network); 24 Jan 2012 18:43:22 -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;
	24 Jan 2012 18:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10257990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 18:43:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 18:43: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
	1RplKz-0001dy-HD; Tue, 24 Jan 2012 18:43:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RplKz-0005nF-FM;
	Tue, 24 Jan 2012 18:43:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.64457.464401.761955@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 18:43:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327423135.24561.208.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326908004.14689.296.camel@zakaz.uk.xensource.com>
	<20254.56075.92172.575268@mariner.uk.xensource.com>
	<1327423135.24561.208.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 3/9] 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 3/9] libxl: New event generation API"):
> On Tue, 2012-01-24 at 16:23 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 3/9] libxl: New event generation API"):
> > > On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> 
> > > > +    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
...
> > > > +        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
> > > 
> > > I didn't see this getting freed on the exit path.
> > 
> > This is deliberate.  Why bother freeing things when the process is
> > about to exit.
> 
> Usually I agree.
> 
> However xl is intended as a libxl testbed as well as a toolstack in its
> own right and it is useful to be able to run tools such as valgrind on
> it to detect leaks in the library, but this requires not having too many
> "false positives" in xl.

Hmm, true.  OK, I will clean up these evgens.

> > > Incidentally we have libxl_device_disk.removable which might be an
> > > opportunity to optimise? Assuming it is meaningful in that way. I think
> > > in reality only emulated CD-ROM devices ever generate this event but
> > > perhaps exposing that in the API overcomplicates things.
> > 
> > Optimise to save on pointless xenstore watches you mean ?
> 
> That and event overhead generally of having the events registered and
> being tracked etc. In the common case we probably have 1 disk and 1
> cdrom so we've effectively doubled the amount of stuff we're dealing
> with -- whether this becomes significant e.g. on a system with 100+ VMs
> I'm not sure.

OK, it's an easy enough test to add.  I'll do so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 18:43:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 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 1RplL6-0001zg-OA; Tue, 24 Jan 2012 18:43:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RplL5-0001yo-Tg
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 18:43:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327430601!8571597!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11823 invoked from network); 24 Jan 2012 18:43:22 -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;
	24 Jan 2012 18:43:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10257990"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 18:43:21 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 18:43: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
	1RplKz-0001dy-HD; Tue, 24 Jan 2012 18:43:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RplKz-0005nF-FM;
	Tue, 24 Jan 2012 18:43:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20254.64457.464401.761955@mariner.uk.xensource.com>
Date: Tue, 24 Jan 2012 18:43:21 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327423135.24561.208.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-4-git-send-email-ian.jackson@eu.citrix.com>
	<1326908004.14689.296.camel@zakaz.uk.xensource.com>
	<20254.56075.92172.575268@mariner.uk.xensource.com>
	<1327423135.24561.208.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 3/9] 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 3/9] libxl: New event generation API"):
> On Tue, 2012-01-24 at 16:23 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 3/9] libxl: New event generation API"):
> > > On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> 
> > > > +    ret = libxl_evenable_domain_death(ctx, domid, 0, &deathw);
...
> > > > +        diskws = xmalloc(sizeof(*diskws) * d_config.num_disks);
> > > 
> > > I didn't see this getting freed on the exit path.
> > 
> > This is deliberate.  Why bother freeing things when the process is
> > about to exit.
> 
> Usually I agree.
> 
> However xl is intended as a libxl testbed as well as a toolstack in its
> own right and it is useful to be able to run tools such as valgrind on
> it to detect leaks in the library, but this requires not having too many
> "false positives" in xl.

Hmm, true.  OK, I will clean up these evgens.

> > > Incidentally we have libxl_device_disk.removable which might be an
> > > opportunity to optimise? Assuming it is meaningful in that way. I think
> > > in reality only emulated CD-ROM devices ever generate this event but
> > > perhaps exposing that in the API overcomplicates things.
> > 
> > Optimise to save on pointless xenstore watches you mean ?
> 
> That and event overhead generally of having the events registered and
> being tracked etc. In the common case we probably have 1 disk and 1
> cdrom so we've effectively doubled the amount of stuff we're dealing
> with -- whether this becomes significant e.g. on a system with 100+ VMs
> I'm not sure.

OK, it's an easy enough test to add.  I'll do so.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 19:14:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 19: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 1RploP-000326-Jn; Tue, 24 Jan 2012 19:13:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RploN-000320-SI
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:13:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327432370!49920996!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19130 invoked from network); 24 Jan 2012 19:12:50 -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;
	24 Jan 2012 19:12:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10258602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 19:13:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 19:13: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 1RploG-0001oD-Od;
	Tue, 24 Jan 2012 19:13:36 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RploG-0008JD-4Q;
	Tue, 24 Jan 2012 19:13:36 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11582-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Jan 2012 19:13:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11582: 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 11582 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11582/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 11574
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 11574
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 11574
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 11574
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 11574
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 11574

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-win       7 windows-install              fail   like 11561

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-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-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-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  0f8f633dbe2d
baseline version:
 xen                  370924e204dc

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@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                                   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.

------------------------------------------------------------
changeset:   24551:0f8f633dbe2d
tag:         tip
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:21:12 2012 +0000
    
    reflect cpupool in numa node affinity
    
    In order to prefer node local memory for a domain the numa node
    locality info must be built according to the cpus belonging to the
    cpupool of the domain.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24550:455a50622fb2
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:20:40 2012 +0000
    
    switch to dynamically allocated cpumask in domain_update_node_affinity()
    
    cpumasks should rather be allocated dynamically.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24549:3df3a0a95551
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:19:58 2012 +0000
    
    introduce and use common macros for selecting cpupool based cpumasks
    
    There are several instances of the same construct finding the cpumask
    for a cpupool. Use macros instead.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24548:d115844ebfbb
user:        Wei Liu <wei.liu2@citrix.com>
date:        Tue Jan 24 14:16:04 2012 +0000
    
    Add a GNTTABOP to swap the content of two grant references under lock
    provided that they are not currently active.
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24547:370924e204dc
user:        Keir Fraser <keir@xen.org>
date:        Mon Jan 23 15:10:43 2012 +0000
    
    Revert 24538:5bb22a6871f6 "xenoprof: Make the escape code consistent across 32 and 64-bit xen"
    
    Breaks 32-bit build.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Tue Jan 24 19:14:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 19: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 1RploP-000326-Jn; Tue, 24 Jan 2012 19:13:45 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RploN-000320-SI
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:13:44 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327432370!49920996!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19130 invoked from network); 24 Jan 2012 19:12:50 -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;
	24 Jan 2012 19:12:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320624000"; d="scan'208";a="10258602"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 19:13:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 19:13: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 1RploG-0001oD-Od;
	Tue, 24 Jan 2012 19:13:36 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RploG-0008JD-4Q;
	Tue, 24 Jan 2012 19:13:36 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11582-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Jan 2012 19:13:36 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11582: 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 11582 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11582/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    9 guest-start               fail REGR. vs. 11574
 test-amd64-amd64-xl-win7-amd64  7 windows-install         fail REGR. vs. 11574
 test-i386-i386-xl-win         7 windows-install           fail REGR. vs. 11574
 test-amd64-i386-xl-win-vcpus1  7 windows-install          fail REGR. vs. 11574
 test-amd64-i386-xl-win7-amd64  7 windows-install          fail REGR. vs. 11574
 test-i386-i386-xl-winxpsp3    7 windows-install           fail REGR. vs. 11574

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-win       7 windows-install              fail   like 11561

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-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-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-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  0f8f633dbe2d
baseline version:
 xen                  370924e204dc

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Liu <wei.liu2@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                                   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.

------------------------------------------------------------
changeset:   24551:0f8f633dbe2d
tag:         tip
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:21:12 2012 +0000
    
    reflect cpupool in numa node affinity
    
    In order to prefer node local memory for a domain the numa node
    locality info must be built according to the cpus belonging to the
    cpupool of the domain.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24550:455a50622fb2
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:20:40 2012 +0000
    
    switch to dynamically allocated cpumask in domain_update_node_affinity()
    
    cpumasks should rather be allocated dynamically.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24549:3df3a0a95551
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:19:58 2012 +0000
    
    introduce and use common macros for selecting cpupool based cpumasks
    
    There are several instances of the same construct finding the cpumask
    for a cpupool. Use macros instead.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24548:d115844ebfbb
user:        Wei Liu <wei.liu2@citrix.com>
date:        Tue Jan 24 14:16:04 2012 +0000
    
    Add a GNTTABOP to swap the content of two grant references under lock
    provided that they are not currently active.
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24547:370924e204dc
user:        Keir Fraser <keir@xen.org>
date:        Mon Jan 23 15:10:43 2012 +0000
    
    Revert 24538:5bb22a6871f6 "xenoprof: Make the escape code consistent across 32 and 64-bit xen"
    
    Breaks 32-bit build.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Tue Jan 24 19:30:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 19: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 1Rpm3x-0003Y0-8r; Tue, 24 Jan 2012 19:29:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1Rpm3v-0003Xs-0b
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:29:47 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327433380!12234888!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11942 invoked from network); 24 Jan 2012 19:29:40 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 19:29:40 -0000
Received: by bkar1 with SMTP id r1so3740963bka.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 11:29:39 -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=TXaPIJFrnvdxtApN6EGfr1QZj+cV0CNlfCLExvUBu18=;
	b=QbwnFZc271wef1p5t1lS/Mip3JXxux2ildQmc1lYGEdi2w6LP16U7VLNaSeqq61Ujc
	9VY4fKdCZRTobZVSNCOemJLCM2yAZxZII8qeSWoMMN2zfmz0S+/faKA0AMmF4hwQlM7O
	4WeGj6XPa+2r/YX+gar8xrsUow7BF2H8SzODU=
Received: by 10.204.154.86 with SMTP id n22mr5457586bkw.85.1327433378335; Tue,
	24 Jan 2012 11:29:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 24 Jan 2012 11:28:56 -0800 (PST)
In-Reply-To: <4F1EC0BE.8050904@ts.fujitsu.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<4F1EC0BE.8050904@ts.fujitsu.com>
From: Shriram Rajagopalan <rshriram@gmail.com>
Date: Tue, 24 Jan 2012 11:28:56 -0800
Message-ID: <CAP8mzPNdvd969BJ3PE3bLi5+1-E_5OwH+0GodMoHefsCXjxU6w@mail.gmail.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List 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: multipart/mixed; boundary="===============6403989552165692273=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6403989552165692273==
Content-Type: multipart/alternative; boundary=0015175d0396fa8d2404b74b2abb

--0015175d0396fa8d2404b74b2abb
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 24, 2012 at 6:31 AM, Juergen Gross <juergen.gross@ts.fujitsu.com
> wrote:

> On 01/23/2012 02:19 PM, Ian Campbell wrote:
>
>> Newly updated list follows. Please send me corrections (especially
>> "done"). I've stopped CCing everyone, since I guess it is mostly spam to
>> the majority.
>>
>> hypervisor, blockers:
>>
>>       * round-up of the closing of the security hole in MSI-X
>>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>>         access to MSI-X table pages). (Jan Beulich -- more fixes
>>         required than first thought, patches posted)
>>       * domctls / sysctls set up to modify scheduler parameters, like
>>         the credit1 timeslice and schedule rate. (George Dunlap)
>>       * get the interface changes for sharing/paging/mem-events done and
>>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>>         Andres Lagar-Cavilla et al)
>>               * mem event ring management posted, seems close to going
>>                 in.
>>               * sharing patches posted
>>
>> tools, blockers:
>>
>>       * libxl stable API -- we would like 4.2 to define a stable API
>>         which downstream's can start to rely on not changing. Aspects of
>>         this are:
>>               * event handling (Ian Jackson, posted several rounds,
>>                 nearing completion?)
>>               * drop libxl_device_model_info (move bits to build_info or
>>                 elsewhere as appropriate) (Ian Campbell, first RFC sent)
>>               * add libxl_defbool and generally try and arrange that
>>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>>                 first RFC sent)
>>               * topologyinfo datastructure should be a list of tuples,
>>                 not a tuple of lists. (nobody currently looking at this,
>>                 not 100% sure this makes sense, could possibly defer and
>>                 change after 4.2 in a compatible way)
>>       * xl to use json for machine readable output instead of sexp by
>>         default (Ian Campbell to revisit existing patch)
>>       * xl support for vcpu pinning (Dario Faggioli)
>>       * xl feature parity with xend wrt driver domain support (George
>>         Dunlap)
>>       * Integrate qemu+seabios upstream into the build (patches
>>         reposted, pending). No change in default qemu for 4.2.
>>       * More formally deprecate xm/xend. Manpage patches already in
>>         tree. Needs release noting and communication around -rc1 to
>>         remind people to test xl.
>>
>> hypervisor, nice to have:
>>
>>       * solid implementation of sharing/paging/mem-events (using work
>>         queues) (Tim Deegan, Olaf Herring et al)
>>       * A long standing issue is a fully synchronized p2m (locking
>>         lookups) (Andres Lagar-Cavilla)
>>       * NUMA improvement: domain affinity consistent with cpupool
>>         membership (Dario Faggioli, Jeurgen Gross -- patch posted)
>>
>
> Patches accepted (cs24549..24551)
>
>
>  tools, nice to have:
>>
>>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>>         didn't put this under stable API above) but still good to have
>>         for 4.2? Roger Pau Monet was looking at this but its looking
>>         like a big can-o-worms. (discussion on-going)
>>       * Block script support -- follows on from hotplug script (Roger
>>         Pau Monet)
>>       * libyajl v2 support (patch posted by Roger Pau Monet, blocked on
>>         autoconf?)
>>       * Configure/control paging via xl/libxl (Olaf Herring)
>>       * Upstream qemu feature patches:
>>               * Upstream qemu PCI passthrough support (Anthony Perard)
>>               * Upstream qemu save restore (Anthony Perard)
>>       * Nested-virtualisation (currently should be marked
>>         experimental,likely to release that way? Consider nested-svm
>>         separate to nested-vmx. Nested-svm is in better shape)
>>
>>
             * Basic remus support in libxl.

I have sent the patches. If the block script patches get in on time, I
could add
disk checkpointing support too. That would leave only network buffering.


> Tools, need to decide if pre- or post-4.2 feature:
>>
>>       * Autoconf (Roger Pau Monet posted a patch)
>>
>>
>> ______________________________**_________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/**xen-devel<http://lists.xensource.com/xen-devel>
>>
>>
>>
>
> --
> Juergen Gross                 Principal Developer Operating Systems
> PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
> Fujitsu Technology Solutions              e-mail:
> juergen.gross@ts.fujitsu.com
> Domagkstr. 28                           Internet: ts.fujitsu.com
> D-80807 Muenchen                 Company details:
> ts.fujitsu.com/imprint.html
>
>
>
> ______________________________**_________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/**xen-devel<http://lists.xensource.com/xen-devel>
>

--0015175d0396fa8d2404b74b2abb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Jan 24, 2012 at 6:31 AM, Juergen=
 Gross <span dir=3D"ltr">&lt;<a href=3D"mailto:juergen.gross@ts.fujitsu.com=
">juergen.gross@ts.fujitsu.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On 01/23/2012 02:19 PM, Ian Campbel=
l wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Newly updated list follows. Please send me corrections (especially<br>
&quot;done&quot;). I&#39;ve stopped CCing everyone, since I guess it is mos=
tly spam to<br>
the majority.<br>
<br>
hypervisor, blockers:<br>
<br>
 =A0 =A0 =A0 * round-up of the closing of the security hole in MSI-X<br>
 =A0 =A0 =A0 =A0 passthrough (uniformly - i.e. even for Dom0 - disallowing =
write<br>
 =A0 =A0 =A0 =A0 access to MSI-X table pages). (Jan Beulich -- more fixes<b=
r>
 =A0 =A0 =A0 =A0 required than first thought, patches posted)<br>
 =A0 =A0 =A0 * domctls / sysctls set up to modify scheduler parameters, lik=
e<br>
 =A0 =A0 =A0 =A0 the credit1 timeslice and schedule rate. (George Dunlap)<b=
r>
 =A0 =A0 =A0 * get the interface changes for sharing/paging/mem-events done=
 and<br>
 =A0 =A0 =A0 =A0 dusted so that 4.2 is a stable API that we hold to. (Tim D=
eegan,<br>
 =A0 =A0 =A0 =A0 Andres Lagar-Cavilla et al)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * mem event ring management posted, seems clos=
e to going<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in.<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * sharing patches posted<br>
<br>
tools, blockers:<br>
<br>
 =A0 =A0 =A0 * libxl stable API -- we would like 4.2 to define a stable API=
<br>
 =A0 =A0 =A0 =A0 which downstream&#39;s can start to rely on not changing. =
Aspects of<br>
 =A0 =A0 =A0 =A0 this are:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * event handling (Ian Jackson, posted several =
rounds,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nearing completion?)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * drop libxl_device_model_info (move bits to b=
uild_info or<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elsewhere as appropriate) (Ian Campbell, f=
irst RFC sent)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * add libxl_defbool and generally try and arra=
nge that<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 memset(foo,0,...) requests the defaults (I=
an Campbell,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 first RFC sent)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * topologyinfo datastructure should be a list =
of tuples,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not a tuple of lists. (nobody currently lo=
oking at this,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not 100% sure this makes sense, could poss=
ibly defer and<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 change after 4.2 in a compatible way)<br>
 =A0 =A0 =A0 * xl to use json for machine readable output instead of sexp b=
y<br>
 =A0 =A0 =A0 =A0 default (Ian Campbell to revisit existing patch)<br>
 =A0 =A0 =A0 * xl support for vcpu pinning (Dario Faggioli)<br>
 =A0 =A0 =A0 * xl feature parity with xend wrt driver domain support (Georg=
e<br>
 =A0 =A0 =A0 =A0 Dunlap)<br>
 =A0 =A0 =A0 * Integrate qemu+seabios upstream into the build (patches<br>
 =A0 =A0 =A0 =A0 reposted, pending). No change in default qemu for 4.2.<br>
 =A0 =A0 =A0 * More formally deprecate xm/xend. Manpage patches already in<=
br>
 =A0 =A0 =A0 =A0 tree. Needs release noting and communication around -rc1 t=
o<br>
 =A0 =A0 =A0 =A0 remind people to test xl.<br>
<br>
hypervisor, nice to have:<br>
<br>
 =A0 =A0 =A0 * solid implementation of sharing/paging/mem-events (using wor=
k<br>
 =A0 =A0 =A0 =A0 queues) (Tim Deegan, Olaf Herring et al)<br>
 =A0 =A0 =A0 * A long standing issue is a fully synchronized p2m (locking<b=
r>
 =A0 =A0 =A0 =A0 lookups) (Andres Lagar-Cavilla)<br>
 =A0 =A0 =A0 * NUMA improvement: domain affinity consistent with cpupool<br=
>
 =A0 =A0 =A0 =A0 membership (Dario Faggioli, Jeurgen Gross -- patch posted)=
<br>
</blockquote>
<br></div></div>
Patches accepted (cs24549..24551)<div class=3D"im HOEnZb"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
tools, nice to have:<br>
<br>
 =A0 =A0 =A0 * Hotplug script stuff -- internal to libxl (I think, therefor=
e I<br>
 =A0 =A0 =A0 =A0 didn&#39;t put this under stable API above) but still good=
 to have<br>
 =A0 =A0 =A0 =A0 for 4.2? Roger Pau Monet was looking at this but its looki=
ng<br>
 =A0 =A0 =A0 =A0 like a big can-o-worms. (discussion on-going)<br>
 =A0 =A0 =A0 * Block script support -- follows on from hotplug script (Roge=
r<br>
 =A0 =A0 =A0 =A0 Pau Monet)<br>
 =A0 =A0 =A0 * libyajl v2 support (patch posted by Roger Pau Monet, blocked=
 on<br>
 =A0 =A0 =A0 =A0 autoconf?)<br>
 =A0 =A0 =A0 * Configure/control paging via xl/libxl (Olaf Herring)<br>
 =A0 =A0 =A0 * Upstream qemu feature patches:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Upstream qemu PCI passthrough support (Antho=
ny Perard)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Upstream qemu save restore (Anthony Perard)<=
br>
 =A0 =A0 =A0 * Nested-virtualisation (currently should be marked<br>
 =A0 =A0 =A0 =A0 experimental,likely to release that way? Consider nested-s=
vm<br>
 =A0 =A0 =A0 =A0 separate to nested-vmx. Nested-svm is in better shape)<br>
<br></blockquote></div></blockquote><div><br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 * Basic remus support in libxl.<br><br>I have sent the patches. If t=
he block script patches get in on time, I could add<br>disk checkpointing s=
upport too. That would leave only network buffering.<br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im=
 HOEnZb"><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">


Tools, need to decide if pre- or post-4.2 feature:<br>
<br>
 =A0 =A0 =A0 * Autoconf (Roger Pau Monet posted a patch)<br>
<br>
<br>
______________________________<u></u>_________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-devel</a><br>
<br>
<br>
</blockquote>
<br>
<br></div><span class=3D"HOEnZb"><font color=3D"#888888">
-- <br>
Juergen Gross =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Principal Developer Operating=
 Systems<br>
PDG ES&amp;S SWE OS6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Telephone:=
 <a href=3D"tel:%2B49%20%280%29%2089%203222%202967" value=3D"+498932222967"=
 target=3D"_blank">+49 (0) 89 3222 2967</a><br>
Fujitsu Technology Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0e-mail: <a href=3D"=
mailto:juergen.gross@ts.fujitsu.com" target=3D"_blank">juergen.gross@ts.fuj=
itsu.com</a><br>
Domagkstr. 28 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet:=
 <a href=3D"http://ts.fujitsu.com" target=3D"_blank">ts.fujitsu.com</a><br>
D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Company details: <a href=
=3D"http://ts.fujitsu.com/imprint.html" target=3D"_blank">ts.fujitsu.com/im=
print.html</a></font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-devel</a><br>
</div></div></blockquote></div><br>

--0015175d0396fa8d2404b74b2abb--


--===============6403989552165692273==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6403989552165692273==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 19:30:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 19: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 1Rpm3x-0003Y0-8r; Tue, 24 Jan 2012 19:29:49 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1Rpm3v-0003Xs-0b
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:29:47 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327433380!12234888!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40, HTML_MESSAGE, ML_RADAR_SPEW_LINKS_14, RCVD_BY_IP,
	spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11942 invoked from network); 24 Jan 2012 19:29:40 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 19:29:40 -0000
Received: by bkar1 with SMTP id r1so3740963bka.30
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 11:29:39 -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=TXaPIJFrnvdxtApN6EGfr1QZj+cV0CNlfCLExvUBu18=;
	b=QbwnFZc271wef1p5t1lS/Mip3JXxux2ildQmc1lYGEdi2w6LP16U7VLNaSeqq61Ujc
	9VY4fKdCZRTobZVSNCOemJLCM2yAZxZII8qeSWoMMN2zfmz0S+/faKA0AMmF4hwQlM7O
	4WeGj6XPa+2r/YX+gar8xrsUow7BF2H8SzODU=
Received: by 10.204.154.86 with SMTP id n22mr5457586bkw.85.1327433378335; Tue,
	24 Jan 2012 11:29:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 24 Jan 2012 11:28:56 -0800 (PST)
In-Reply-To: <4F1EC0BE.8050904@ts.fujitsu.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<4F1EC0BE.8050904@ts.fujitsu.com>
From: Shriram Rajagopalan <rshriram@gmail.com>
Date: Tue, 24 Jan 2012 11:28:56 -0800
Message-ID: <CAP8mzPNdvd969BJ3PE3bLi5+1-E_5OwH+0GodMoHefsCXjxU6w@mail.gmail.com>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List 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: multipart/mixed; boundary="===============6403989552165692273=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6403989552165692273==
Content-Type: multipart/alternative; boundary=0015175d0396fa8d2404b74b2abb

--0015175d0396fa8d2404b74b2abb
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 24, 2012 at 6:31 AM, Juergen Gross <juergen.gross@ts.fujitsu.com
> wrote:

> On 01/23/2012 02:19 PM, Ian Campbell wrote:
>
>> Newly updated list follows. Please send me corrections (especially
>> "done"). I've stopped CCing everyone, since I guess it is mostly spam to
>> the majority.
>>
>> hypervisor, blockers:
>>
>>       * round-up of the closing of the security hole in MSI-X
>>         passthrough (uniformly - i.e. even for Dom0 - disallowing write
>>         access to MSI-X table pages). (Jan Beulich -- more fixes
>>         required than first thought, patches posted)
>>       * domctls / sysctls set up to modify scheduler parameters, like
>>         the credit1 timeslice and schedule rate. (George Dunlap)
>>       * get the interface changes for sharing/paging/mem-events done and
>>         dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
>>         Andres Lagar-Cavilla et al)
>>               * mem event ring management posted, seems close to going
>>                 in.
>>               * sharing patches posted
>>
>> tools, blockers:
>>
>>       * libxl stable API -- we would like 4.2 to define a stable API
>>         which downstream's can start to rely on not changing. Aspects of
>>         this are:
>>               * event handling (Ian Jackson, posted several rounds,
>>                 nearing completion?)
>>               * drop libxl_device_model_info (move bits to build_info or
>>                 elsewhere as appropriate) (Ian Campbell, first RFC sent)
>>               * add libxl_defbool and generally try and arrange that
>>                 memset(foo,0,...) requests the defaults (Ian Campbell,
>>                 first RFC sent)
>>               * topologyinfo datastructure should be a list of tuples,
>>                 not a tuple of lists. (nobody currently looking at this,
>>                 not 100% sure this makes sense, could possibly defer and
>>                 change after 4.2 in a compatible way)
>>       * xl to use json for machine readable output instead of sexp by
>>         default (Ian Campbell to revisit existing patch)
>>       * xl support for vcpu pinning (Dario Faggioli)
>>       * xl feature parity with xend wrt driver domain support (George
>>         Dunlap)
>>       * Integrate qemu+seabios upstream into the build (patches
>>         reposted, pending). No change in default qemu for 4.2.
>>       * More formally deprecate xm/xend. Manpage patches already in
>>         tree. Needs release noting and communication around -rc1 to
>>         remind people to test xl.
>>
>> hypervisor, nice to have:
>>
>>       * solid implementation of sharing/paging/mem-events (using work
>>         queues) (Tim Deegan, Olaf Herring et al)
>>       * A long standing issue is a fully synchronized p2m (locking
>>         lookups) (Andres Lagar-Cavilla)
>>       * NUMA improvement: domain affinity consistent with cpupool
>>         membership (Dario Faggioli, Jeurgen Gross -- patch posted)
>>
>
> Patches accepted (cs24549..24551)
>
>
>  tools, nice to have:
>>
>>       * Hotplug script stuff -- internal to libxl (I think, therefore I
>>         didn't put this under stable API above) but still good to have
>>         for 4.2? Roger Pau Monet was looking at this but its looking
>>         like a big can-o-worms. (discussion on-going)
>>       * Block script support -- follows on from hotplug script (Roger
>>         Pau Monet)
>>       * libyajl v2 support (patch posted by Roger Pau Monet, blocked on
>>         autoconf?)
>>       * Configure/control paging via xl/libxl (Olaf Herring)
>>       * Upstream qemu feature patches:
>>               * Upstream qemu PCI passthrough support (Anthony Perard)
>>               * Upstream qemu save restore (Anthony Perard)
>>       * Nested-virtualisation (currently should be marked
>>         experimental,likely to release that way? Consider nested-svm
>>         separate to nested-vmx. Nested-svm is in better shape)
>>
>>
             * Basic remus support in libxl.

I have sent the patches. If the block script patches get in on time, I
could add
disk checkpointing support too. That would leave only network buffering.


> Tools, need to decide if pre- or post-4.2 feature:
>>
>>       * Autoconf (Roger Pau Monet posted a patch)
>>
>>
>> ______________________________**_________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/**xen-devel<http://lists.xensource.com/xen-devel>
>>
>>
>>
>
> --
> Juergen Gross                 Principal Developer Operating Systems
> PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
> Fujitsu Technology Solutions              e-mail:
> juergen.gross@ts.fujitsu.com
> Domagkstr. 28                           Internet: ts.fujitsu.com
> D-80807 Muenchen                 Company details:
> ts.fujitsu.com/imprint.html
>
>
>
> ______________________________**_________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/**xen-devel<http://lists.xensource.com/xen-devel>
>

--0015175d0396fa8d2404b74b2abb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Jan 24, 2012 at 6:31 AM, Juergen=
 Gross <span dir=3D"ltr">&lt;<a href=3D"mailto:juergen.gross@ts.fujitsu.com=
">juergen.gross@ts.fujitsu.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On 01/23/2012 02:19 PM, Ian Campbel=
l wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Newly updated list follows. Please send me corrections (especially<br>
&quot;done&quot;). I&#39;ve stopped CCing everyone, since I guess it is mos=
tly spam to<br>
the majority.<br>
<br>
hypervisor, blockers:<br>
<br>
 =A0 =A0 =A0 * round-up of the closing of the security hole in MSI-X<br>
 =A0 =A0 =A0 =A0 passthrough (uniformly - i.e. even for Dom0 - disallowing =
write<br>
 =A0 =A0 =A0 =A0 access to MSI-X table pages). (Jan Beulich -- more fixes<b=
r>
 =A0 =A0 =A0 =A0 required than first thought, patches posted)<br>
 =A0 =A0 =A0 * domctls / sysctls set up to modify scheduler parameters, lik=
e<br>
 =A0 =A0 =A0 =A0 the credit1 timeslice and schedule rate. (George Dunlap)<b=
r>
 =A0 =A0 =A0 * get the interface changes for sharing/paging/mem-events done=
 and<br>
 =A0 =A0 =A0 =A0 dusted so that 4.2 is a stable API that we hold to. (Tim D=
eegan,<br>
 =A0 =A0 =A0 =A0 Andres Lagar-Cavilla et al)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * mem event ring management posted, seems clos=
e to going<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in.<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * sharing patches posted<br>
<br>
tools, blockers:<br>
<br>
 =A0 =A0 =A0 * libxl stable API -- we would like 4.2 to define a stable API=
<br>
 =A0 =A0 =A0 =A0 which downstream&#39;s can start to rely on not changing. =
Aspects of<br>
 =A0 =A0 =A0 =A0 this are:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * event handling (Ian Jackson, posted several =
rounds,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nearing completion?)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * drop libxl_device_model_info (move bits to b=
uild_info or<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elsewhere as appropriate) (Ian Campbell, f=
irst RFC sent)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * add libxl_defbool and generally try and arra=
nge that<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 memset(foo,0,...) requests the defaults (I=
an Campbell,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 first RFC sent)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * topologyinfo datastructure should be a list =
of tuples,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not a tuple of lists. (nobody currently lo=
oking at this,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not 100% sure this makes sense, could poss=
ibly defer and<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 change after 4.2 in a compatible way)<br>
 =A0 =A0 =A0 * xl to use json for machine readable output instead of sexp b=
y<br>
 =A0 =A0 =A0 =A0 default (Ian Campbell to revisit existing patch)<br>
 =A0 =A0 =A0 * xl support for vcpu pinning (Dario Faggioli)<br>
 =A0 =A0 =A0 * xl feature parity with xend wrt driver domain support (Georg=
e<br>
 =A0 =A0 =A0 =A0 Dunlap)<br>
 =A0 =A0 =A0 * Integrate qemu+seabios upstream into the build (patches<br>
 =A0 =A0 =A0 =A0 reposted, pending). No change in default qemu for 4.2.<br>
 =A0 =A0 =A0 * More formally deprecate xm/xend. Manpage patches already in<=
br>
 =A0 =A0 =A0 =A0 tree. Needs release noting and communication around -rc1 t=
o<br>
 =A0 =A0 =A0 =A0 remind people to test xl.<br>
<br>
hypervisor, nice to have:<br>
<br>
 =A0 =A0 =A0 * solid implementation of sharing/paging/mem-events (using wor=
k<br>
 =A0 =A0 =A0 =A0 queues) (Tim Deegan, Olaf Herring et al)<br>
 =A0 =A0 =A0 * A long standing issue is a fully synchronized p2m (locking<b=
r>
 =A0 =A0 =A0 =A0 lookups) (Andres Lagar-Cavilla)<br>
 =A0 =A0 =A0 * NUMA improvement: domain affinity consistent with cpupool<br=
>
 =A0 =A0 =A0 =A0 membership (Dario Faggioli, Jeurgen Gross -- patch posted)=
<br>
</blockquote>
<br></div></div>
Patches accepted (cs24549..24551)<div class=3D"im HOEnZb"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
tools, nice to have:<br>
<br>
 =A0 =A0 =A0 * Hotplug script stuff -- internal to libxl (I think, therefor=
e I<br>
 =A0 =A0 =A0 =A0 didn&#39;t put this under stable API above) but still good=
 to have<br>
 =A0 =A0 =A0 =A0 for 4.2? Roger Pau Monet was looking at this but its looki=
ng<br>
 =A0 =A0 =A0 =A0 like a big can-o-worms. (discussion on-going)<br>
 =A0 =A0 =A0 * Block script support -- follows on from hotplug script (Roge=
r<br>
 =A0 =A0 =A0 =A0 Pau Monet)<br>
 =A0 =A0 =A0 * libyajl v2 support (patch posted by Roger Pau Monet, blocked=
 on<br>
 =A0 =A0 =A0 =A0 autoconf?)<br>
 =A0 =A0 =A0 * Configure/control paging via xl/libxl (Olaf Herring)<br>
 =A0 =A0 =A0 * Upstream qemu feature patches:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Upstream qemu PCI passthrough support (Antho=
ny Perard)<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * Upstream qemu save restore (Anthony Perard)<=
br>
 =A0 =A0 =A0 * Nested-virtualisation (currently should be marked<br>
 =A0 =A0 =A0 =A0 experimental,likely to release that way? Consider nested-s=
vm<br>
 =A0 =A0 =A0 =A0 separate to nested-vmx. Nested-svm is in better shape)<br>
<br></blockquote></div></blockquote><div><br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 * Basic remus support in libxl.<br><br>I have sent the patches. If t=
he block script patches get in on time, I could add<br>disk checkpointing s=
upport too. That would leave only network buffering.<br>

=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im=
 HOEnZb"><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">


Tools, need to decide if pre- or post-4.2 feature:<br>
<br>
 =A0 =A0 =A0 * Autoconf (Roger Pau Monet posted a patch)<br>
<br>
<br>
______________________________<u></u>_________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-devel</a><br>
<br>
<br>
</blockquote>
<br>
<br></div><span class=3D"HOEnZb"><font color=3D"#888888">
-- <br>
Juergen Gross =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Principal Developer Operating=
 Systems<br>
PDG ES&amp;S SWE OS6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Telephone:=
 <a href=3D"tel:%2B49%20%280%29%2089%203222%202967" value=3D"+498932222967"=
 target=3D"_blank">+49 (0) 89 3222 2967</a><br>
Fujitsu Technology Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0e-mail: <a href=3D"=
mailto:juergen.gross@ts.fujitsu.com" target=3D"_blank">juergen.gross@ts.fuj=
itsu.com</a><br>
Domagkstr. 28 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet:=
 <a href=3D"http://ts.fujitsu.com" target=3D"_blank">ts.fujitsu.com</a><br>
D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Company details: <a href=
=3D"http://ts.fujitsu.com/imprint.html" target=3D"_blank">ts.fujitsu.com/im=
print.html</a></font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
Xen-devel mailing list<br>
<a href=3D"mailto:Xen-devel@lists.xensource.com" target=3D"_blank">Xen-deve=
l@lists.xensource.com</a><br>
<a href=3D"http://lists.xensource.com/xen-devel" target=3D"_blank">http://l=
ists.xensource.com/<u></u>xen-devel</a><br>
</div></div></blockquote></div><br>

--0015175d0396fa8d2404b74b2abb--


--===============6403989552165692273==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6403989552165692273==--


From xen-devel-bounces@lists.xensource.com Tue Jan 24 19:31:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 19: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 1Rpm4t-0003ba-T9; Tue, 24 Jan 2012 19:30:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1Rpm4t-0003bR-1h
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:30:47 +0000
Received: from [85.158.138.51:54436] by server-2.bemta-3.messagelabs.com id
	9F/91-24515-6E60F1F4; Tue, 24 Jan 2012 19:30:46 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327433442!8660520!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27895 invoked from network); 24 Jan 2012 19:30:43 -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;
	24 Jan 2012 19:30:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320642000"; d="scan'208";a="21235179"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 14:30:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 14:30:41 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0OJUdq0003261;	Tue, 24 Jan 2012 11:30:40 -0800
Message-ID: <4F1F062A.4080306@citrix.com>
Date: Tue, 24 Jan 2012 19:27:38 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F19B62C.9020402@citrix.com>
	<4F1D3B79020000780006E509@nat28.tlf.novell.com>
In-Reply-To: <4F1D3B79020000780006E509@nat28.tlf.novell.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xenoprof: Handle 32-bit guest stacks
 properly in a 64-bit 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 23/01/12 09:50, Jan Beulich wrote:
> If you're adding a compat mode guest case here, then you should
> also use compat mode accessors (compat_handle_okay(),
> __copy_from_compat_offset()), implying that you also have a local
> handle variable of the appropriate type (and perhaps moving the
> native one down into the 'else' body).

I'm trying to understand the compat handle. It is not clear to me how to 
map one from head (a 64-bit pointer), since COMPAT_HANDLE seems to store 
a 32-bit compat_ptr_t value in its structure. Ideally, what I would like 
to do is

COMPAT_HANDLE(char) guest_head = map_guest_handle_to_compat_handle 
(guest_handle_from_ptr(head, char));
or
COMPAT_HANDLE(char) guest_head = compat_handle_from_ptr(head, char));
but I can't find any equivalent functions in any header.

The following line compiles,
COMPAT_HANDLE(char) guest_head = { (full_ptr_t)head };
but it looks like, in this case, the compat handle structure in compat.h 
will truncate the most significant bits from the head pointer, so 
compat_handle_okay(guest_head,...) and 
__copy_from_compat(...,guest_head,...) below will be using a truncated 
pointer:

      56 static struct frame_head *
      57 dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
      58                      struct frame_head * head, int mode)
      59 {
      60     struct frame_head bufhead[2];
      61
      62 #ifdef CONFIG_X86_64
      63     if ( is_32bit_vcpu(vcpu) )
      64     {
      65         COMPAT_HANDLE(char) guest_head = { (full_ptr_t)head };
      66         struct frame_head_32bit bufhead32[2];
      67         /* Also check accessibility of one struct frame_head 
beyond */
      68         if (!compat_handle_okay(guest_head, sizeof(bufhead32)))
      69             return 0;
      70         if (__copy_from_compat((char *)bufhead32, guest_head,
      71                                      sizeof(bufhead32)))
      72             return 0;
      73         bufhead[0].ebp=(struct frame_head 
*)(full_ptr_t)bufhead32[0].ebp;
      74         bufhead[0].ret=bufhead32[0].ret;
      75     }
      76     else
      77 #endif

Any advice? Maybe the best option in this case is to avoid the compat* 
functions and to use the original guest* functions instead.

Thanks,
Marcus


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 19:31:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 19: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 1Rpm4t-0003ba-T9; Tue, 24 Jan 2012 19:30:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Marcus.Granado@eu.citrix.com>) id 1Rpm4t-0003bR-1h
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:30:47 +0000
Received: from [85.158.138.51:54436] by server-2.bemta-3.messagelabs.com id
	9F/91-24515-6E60F1F4; Tue, 24 Jan 2012 19:30:46 +0000
X-Env-Sender: Marcus.Granado@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327433442!8660520!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY1MTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27895 invoked from network); 24 Jan 2012 19:30:43 -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;
	24 Jan 2012 19:30:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,563,1320642000"; d="scan'208";a="21235179"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 14:30:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 24 Jan 2012 14:30:41 -0500
Received: from [10.80.3.62] (dhcp-3-62.uk.xensource.com [10.80.3.62] (may be
	forged))	by smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id
	q0OJUdq0003261;	Tue, 24 Jan 2012 11:30:40 -0800
Message-ID: <4F1F062A.4080306@citrix.com>
Date: Tue, 24 Jan 2012 19:27:38 +0000
From: Marcus Granado <marcus.granado@citrix.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F19B62C.9020402@citrix.com>
	<4F1D3B79020000780006E509@nat28.tlf.novell.com>
In-Reply-To: <4F1D3B79020000780006E509@nat28.tlf.novell.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xenoprof: Handle 32-bit guest stacks
 properly in a 64-bit 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 23/01/12 09:50, Jan Beulich wrote:
> If you're adding a compat mode guest case here, then you should
> also use compat mode accessors (compat_handle_okay(),
> __copy_from_compat_offset()), implying that you also have a local
> handle variable of the appropriate type (and perhaps moving the
> native one down into the 'else' body).

I'm trying to understand the compat handle. It is not clear to me how to 
map one from head (a 64-bit pointer), since COMPAT_HANDLE seems to store 
a 32-bit compat_ptr_t value in its structure. Ideally, what I would like 
to do is

COMPAT_HANDLE(char) guest_head = map_guest_handle_to_compat_handle 
(guest_handle_from_ptr(head, char));
or
COMPAT_HANDLE(char) guest_head = compat_handle_from_ptr(head, char));
but I can't find any equivalent functions in any header.

The following line compiles,
COMPAT_HANDLE(char) guest_head = { (full_ptr_t)head };
but it looks like, in this case, the compat handle structure in compat.h 
will truncate the most significant bits from the head pointer, so 
compat_handle_okay(guest_head,...) and 
__copy_from_compat(...,guest_head,...) below will be using a truncated 
pointer:

      56 static struct frame_head *
      57 dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
      58                      struct frame_head * head, int mode)
      59 {
      60     struct frame_head bufhead[2];
      61
      62 #ifdef CONFIG_X86_64
      63     if ( is_32bit_vcpu(vcpu) )
      64     {
      65         COMPAT_HANDLE(char) guest_head = { (full_ptr_t)head };
      66         struct frame_head_32bit bufhead32[2];
      67         /* Also check accessibility of one struct frame_head 
beyond */
      68         if (!compat_handle_okay(guest_head, sizeof(bufhead32)))
      69             return 0;
      70         if (__copy_from_compat((char *)bufhead32, guest_head,
      71                                      sizeof(bufhead32)))
      72             return 0;
      73         bufhead[0].ebp=(struct frame_head 
*)(full_ptr_t)bufhead32[0].ebp;
      74         bufhead[0].ret=bufhead32[0].ret;
      75     }
      76     else
      77 #endif

Any advice? Maybe the best option in this case is to avoid the compat* 
functions and to use the original guest* functions instead.

Thanks,
Marcus


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 19:35:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 19:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpm8c-0003ox-Hr; Tue, 24 Jan 2012 19:34:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aliguori@us.ibm.com>) id 1Rpm8a-0003oj-D5
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:34:37 +0000
Received: from [85.158.138.51:7395] by server-3.bemta-3.messagelabs.com id
	A8/68-26314-BC70F1F4; Tue, 24 Jan 2012 19:34:35 +0000
X-Env-Sender: aliguori@us.ibm.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327433672!10511820!1
X-Originating-IP: [32.97.110.158]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1OCA9PiA2OTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3258 invoked from network); 24 Jan 2012 19:34:33 -0000
Received: from e37.co.us.ibm.com (HELO e37.co.us.ibm.com) (32.97.110.158)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 19:34:33 -0000
Received: from /spool/local
	by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <aliguori@us.ibm.com>;
	Tue, 24 Jan 2012 12:34:30 -0700
Received: from d03dlp02.boulder.ibm.com (9.17.202.178)
	by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 24 Jan 2012 12:34:01 -0700
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com
	[9.17.195.228])
	by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id BE8FA3E4004A
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 12:33:59 -0700 (MST)
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167])
	by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0OJXtim112120
	for <xen-devel@lists.xensource.com>; Tue, 24 Jan 2012 12:33:55 -0700
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1])
	by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q0OJXs0j009869
	for <xen-devel@lists.xensource.com>; Tue, 24 Jan 2012 12:33:55 -0700
Received: from titi.austin.rr.com (sig-9-65-115-125.mts.ibm.com [9.65.115.125])
	by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0OJXNdi006821; Tue, 24 Jan 2012 12:33:52 -0700
From: Anthony Liguori <aliguori@us.ibm.com>
To: qemu-devel@nongnu.org
Date: Tue, 24 Jan 2012 13:33:18 -0600
Message-Id: <1327433600-7403-27-git-send-email-aliguori@us.ibm.com>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com>
References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12012419-7408-0000-0000-00000222E669
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>,
	xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Alexander Graf <agraf@suse.de>, Blue Swirl <blauwirbel@gmail.com>,
	=?UTF-8?q?Andreas=20F=C3=A4rber?= <andreas.faerber@web.de>,
	qemu-ppc@nongnu.org, Paul Brook <paul@codesourcery.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH 26/28] pci: convert to QEMU Object Model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 hw/9pfs/virtio-9p-device.c |   43 ++++++----
 hw/ac97.c                  |   39 +++++----
 hw/acpi_piix4.c            |   59 +++++++------
 hw/apb_pci.c               |   54 ++++++++-----
 hw/bonito.c                |   30 ++++---
 hw/cirrus_vga.c            |   33 +++++---
 hw/dec_pci.c               |   57 ++++++++-----
 hw/e1000.c                 |   43 ++++++----
 hw/eepro100.c              |  200 +++++++++++++++++++++++++++----------------
 hw/es1370.c                |   31 ++++---
 hw/grackle_pci.c           |   25 ++++--
 hw/gt64xxx.c               |   23 ++++--
 hw/i82378.c                |   31 ++++---
 hw/ide/cmd646.c            |   36 +++++---
 hw/ide/ich.c               |   31 ++++---
 hw/ide/piix.c              |   79 +++++++++++-------
 hw/ide/via.c               |   27 ++++--
 hw/intel-hda.c             |   56 ++++++++----
 hw/ioh3420.c               |   59 +++++++------
 hw/ivshmem.c               |   47 ++++++----
 hw/lsi53c895a.c            |   31 ++++---
 hw/macio.c                 |   19 +++--
 hw/ne2000.c                |   35 +++++---
 hw/pci.c                   |  123 ++++++++++++---------------
 hw/pci.h                   |   80 +++++++++---------
 hw/pci_bridge.c            |    2 +-
 hw/pcie.c                  |    2 +-
 hw/pcnet-pci.c             |   39 +++++----
 hw/piix4.c                 |   30 ++++---
 hw/piix_pci.c              |   95 +++++++++++++--------
 hw/ppc4xx_pci.c            |   21 +++--
 hw/ppce500_pci.c           |   21 +++--
 hw/prep_pci.c              |   33 ++++----
 hw/qdev.c                  |    1 +
 hw/qxl.c                   |   62 ++++++++-----
 hw/rtl8139.c               |   41 ++++++----
 hw/sh_pci.c                |   19 +++--
 hw/spapr_pci.c             |   15 +++-
 hw/sun4u.c                 |   23 ++++--
 hw/unin_pci.c              |   92 +++++++++++++-------
 hw/usb-ehci.c              |   54 ++++++++-----
 hw/usb-ohci.c              |   37 +++++---
 hw/usb-uhci.c              |  168 +++++++++++++++++++++++--------------
 hw/usb-xhci.c              |   33 +++++---
 hw/versatile_pci.c         |   22 +++--
 hw/vga-pci.c               |   27 ++++---
 hw/virtio-pci.c            |  188 ++++++++++++++++++++++++-----------------
 hw/vmware_vga.c            |   34 +++++---
 hw/vt82c686.c              |  120 ++++++++++++++++----------
 hw/wdt_i6300esb.c          |   33 +++++---
 hw/xen_platform.c          |   34 +++++---
 hw/xio3130_downstream.c    |   59 +++++++------
 hw/xio3130_upstream.c      |   53 +++++++-----
 53 files changed, 1599 insertions(+), 1050 deletions(-)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 1325f2f..aded048 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -163,23 +163,32 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
     return 0;
 }
 
-static PCIDeviceInfo virtio_9p_info = {
-    .qdev.name = "virtio-9p-pci",
-    .qdev.size = sizeof(VirtIOPCIProxy),
-    .init      = virtio_9p_init_pci,
-    .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id = 0x1009,
-    .revision  = VIRTIO_PCI_ABI_VERSION,
-    .class_id  = 0x2,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-        DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
-        DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_PROP_STRING("mount_tag", VirtIOPCIProxy, fsconf.tag),
-        DEFINE_PROP_STRING("fsdev", VirtIOPCIProxy, fsconf.fsdev_id),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static Property virtio_9p_properties[] = {
+    DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
+    DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
+    DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_PROP_STRING("mount_tag", VirtIOPCIProxy, fsconf.tag),
+    DEFINE_PROP_STRING("fsdev", VirtIOPCIProxy, fsconf.fsdev_id),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_9p_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_9p_init_pci;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = 0x1009;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = 0x2;
+}
+
+static DeviceInfo virtio_9p_info = {
+    .name = "virtio-9p-pci",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_9p_properties,
+    .class_init = virtio_9p_class_init,
+    .reset = virtio_pci_reset,
 };
 
 static void virtio_9p_register_devices(void)
diff --git a/hw/ac97.c b/hw/ac97.c
index 03be99b..33b85f5 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -1344,21 +1344,30 @@ int ac97_init (PCIBus *bus)
     return 0;
 }
 
-static PCIDeviceInfo ac97_info = {
-    .qdev.name    = "AC97",
-    .qdev.desc    = "Intel 82801AA AC97 Audio",
-    .qdev.size    = sizeof (AC97LinkState),
-    .qdev.vmsd    = &vmstate_ac97,
-    .init         = ac97_initfn,
-    .exit         = ac97_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801AA_5,
-    .revision     = 0x01,
-    .class_id     = PCI_CLASS_MULTIMEDIA_AUDIO,
-    .qdev.props   = (Property[]) {
-        DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property ac97_properties[] = {
+    DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ac97_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = ac97_initfn;
+    k->exit = ac97_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801AA_5;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
+}
+
+static DeviceInfo ac97_info = {
+    .name = "AC97",
+    .desc = "Intel 82801AA AC97 Audio",
+    .size = sizeof (AC97LinkState),
+    .vmsd = &vmstate_ac97,
+    .props = ac97_properties,
+    .class_init = ac97_class_init,
 };
 
 static void ac97_register (void)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 4d0b390..9058a7c 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -280,11 +280,11 @@ static void piix4_update_hotplug(PIIX4PMState *s)
     s->pci0_hotplug_enable = ~0;
 
     QTAILQ_FOREACH_SAFE(qdev, &bus->children, sibling, next) {
-        PCIDeviceInfo *info = container_of(qdev_get_info(qdev), PCIDeviceInfo, qdev);
-        PCIDevice *pdev = DO_UPCAST(PCIDevice, qdev, qdev);
+        PCIDevice *pdev = PCI_DEVICE(qdev);
+        PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pdev);
         int slot = PCI_SLOT(pdev->devfn);
 
-        if (info->no_hotplug) {
+        if (pc->no_hotplug) {
             s->pci0_hotplug_enable &= ~(1 << slot);
         }
     }
@@ -396,23 +396,32 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
     return s->smb.smbus;
 }
 
-static PCIDeviceInfo piix4_pm_info = {
-    .qdev.name          = "PIIX4_PM",
-    .qdev.desc          = "PM",
-    .qdev.size          = sizeof(PIIX4PMState),
-    .qdev.vmsd          = &vmstate_acpi,
-    .qdev.no_user       = 1,
-    .no_hotplug         = 1,
-    .init               = piix4_pm_initfn,
-    .config_write       = pm_write_config,
-    .vendor_id          = PCI_VENDOR_ID_INTEL,
-    .device_id          = PCI_DEVICE_ID_INTEL_82371AB_3,
-    .revision           = 0x03,
-    .class_id           = PCI_CLASS_BRIDGE_OTHER,
-    .qdev.props         = (Property[]) {
-        DEFINE_PROP_UINT32("smb_io_base", PIIX4PMState, smb_io_base, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property piix4_pm_properties[] = {
+    DEFINE_PROP_UINT32("smb_io_base", PIIX4PMState, smb_io_base, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void piix4_pm_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = piix4_pm_initfn;
+    k->config_write = pm_write_config;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371AB_3;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_BRIDGE_OTHER;
+}
+
+static DeviceInfo piix4_pm_info = {
+    .name = "PIIX4_PM",
+    .desc = "PM",
+    .size = sizeof(PIIX4PMState),
+    .vmsd = &vmstate_acpi,
+    .no_user = 1,
+    .props = piix4_pm_properties,
+    .class_init = piix4_pm_class_init,
 };
 
 static void piix4_pm_register(void)
@@ -485,14 +494,12 @@ static void pciej_write(void *opaque, uint32_t addr, uint32_t val)
 {
     BusState *bus = opaque;
     DeviceState *qdev, *next;
-    PCIDevice *dev;
-    PCIDeviceInfo *info;
     int slot = ffs(val) - 1;
 
     QTAILQ_FOREACH_SAFE(qdev, &bus->children, sibling, next) {
-        dev = DO_UPCAST(PCIDevice, qdev, qdev);
-        info = container_of(qdev_get_info(qdev), PCIDeviceInfo, qdev);
-        if (PCI_SLOT(dev->devfn) == slot && !info->no_hotplug) {
+        PCIDevice *dev = PCI_DEVICE(qdev);
+        PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
+        if (PCI_SLOT(dev->devfn) == slot && !pc->no_hotplug) {
             qdev_free(qdev);
         }
     }
@@ -553,7 +560,7 @@ static int piix4_device_hotplug(DeviceState *qdev, PCIDevice *dev,
 {
     int slot = PCI_SLOT(dev->devfn);
     PIIX4PMState *s = DO_UPCAST(PIIX4PMState, dev,
-                                DO_UPCAST(PCIDevice, qdev, qdev));
+                                PCI_DEVICE(qdev));
 
     /* Don't send event when device is enabled during qemu machine creation:
      * it is present on boot, no hotplug event is necessary. We do send an
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 3a1b111..70cfc77 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -436,14 +436,21 @@ static int pbm_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo pbm_pci_host_info = {
-    .qdev.name = "pbm",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = pbm_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_SUN,
-    .device_id = PCI_DEVICE_ID_SUN_SABRE,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
-    .is_bridge = 1,
+static void pbm_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pbm_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_SUN;
+    k->device_id = PCI_DEVICE_ID_SUN_SABRE;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+    k->is_bridge = 1;
+}
+
+static DeviceInfo pbm_pci_host_info = {
+    .name = "pbm",
+    .size = sizeof(PCIDevice),
+    .class_init = pbm_pci_host_class_init,
 };
 
 static SysBusDeviceInfo pbm_host_info = {
@@ -453,18 +460,25 @@ static SysBusDeviceInfo pbm_host_info = {
     .init = pci_pbm_init_device,
 };
 
-static PCIDeviceInfo pbm_pci_bridge_info = {
-    .qdev.name = "pbm-bridge",
-    .qdev.size = sizeof(PCIBridge),
-    .qdev.vmsd = &vmstate_pci_device,
-    .qdev.reset = pci_bridge_reset,
-    .init = apb_pci_bridge_initfn,
-    .exit = pci_bridge_exitfn,
-    .vendor_id = PCI_VENDOR_ID_SUN,
-    .device_id = PCI_DEVICE_ID_SUN_SIMBA,
-    .revision = 0x11,
-    .config_write = pci_bridge_write_config,
-    .is_bridge = 1,
+static void pbm_pci_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = apb_pci_bridge_initfn;
+    k->exit = pci_bridge_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_SUN;
+    k->device_id = PCI_DEVICE_ID_SUN_SIMBA;
+    k->revision = 0x11;
+    k->config_write = pci_bridge_write_config;
+    k->is_bridge = 1;
+}
+
+static DeviceInfo pbm_pci_bridge_info = {
+    .name = "pbm-bridge",
+    .size = sizeof(PCIBridge),
+    .vmsd = &vmstate_pci_device,
+    .reset = pci_bridge_reset,
+    .class_init = pbm_pci_bridge_class_init,
 };
 
 static void pbm_register_devices(void)
diff --git a/hw/bonito.c b/hw/bonito.c
index f2c7837..23384ec 100644
--- a/hw/bonito.c
+++ b/hw/bonito.c
@@ -766,18 +766,24 @@ PCIBus *bonito_init(qemu_irq *pic)
     return b;
 }
 
-static PCIDeviceInfo bonito_info = {
-    .qdev.name    = "Bonito",
-    .qdev.desc    = "Host bridge",
-    .qdev.size    = sizeof(PCIBonitoState),
-    .qdev.vmsd    = &vmstate_bonito,
-    .qdev.no_user = 1,
-    .init         = bonito_initfn,
-    /*Bonito North Bridge, built on FPGA, VENDOR_ID/DEVICE_ID are "undefined"*/
-    .vendor_id    = 0xdf53,
-    .device_id    = 0x00d5,
-    .revision     = 0x01,
-    .class_id     = PCI_CLASS_BRIDGE_HOST,
+static void bonito_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = bonito_initfn;
+    k->vendor_id = 0xdf53;
+    k->device_id = 0x00d5;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo bonito_info = {
+    .name = "Bonito",
+    .desc = "Host bridge",
+    .size = sizeof(PCIBonitoState),
+    .vmsd = &vmstate_bonito,
+    .no_user = 1,
+    .class_init = bonito_class_init,
 };
 
 static SysBusDeviceInfo bonito_pcihost_info = {
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 1d0aadf..3fac2ee 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2935,8 +2935,8 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
 {
      PCICirrusVGAState *d = DO_UPCAST(PCICirrusVGAState, dev, dev);
      CirrusVGAState *s = &d->cirrus_vga;
-     PCIDeviceInfo *info = DO_UPCAST(PCIDeviceInfo, qdev, qdev_get_info(&dev->qdev));
-     int16_t device_id = info->device_id;
+     PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
+     int16_t device_id = pc->device_id;
 
      /* setup VGA */
      vga_common_init(&s->vga, VGA_RAM_SIZE);
@@ -2970,17 +2970,24 @@ DeviceState *pci_cirrus_vga_init(PCIBus *bus)
     return &pci_create_simple(bus, -1, "cirrus-vga")->qdev;
 }
 
-static PCIDeviceInfo cirrus_vga_info = {
-    .qdev.name    = "cirrus-vga",
-    .qdev.desc    = "Cirrus CLGD 54xx VGA",
-    .qdev.size    = sizeof(PCICirrusVGAState),
-    .qdev.vmsd    = &vmstate_pci_cirrus_vga,
-    .no_hotplug   = 1,
-    .init         = pci_cirrus_vga_initfn,
-    .romfile      = VGABIOS_CIRRUS_FILENAME,
-    .vendor_id    = PCI_VENDOR_ID_CIRRUS,
-    .device_id    = CIRRUS_ID_CLGD5446,
-    .class_id     = PCI_CLASS_DISPLAY_VGA,
+static void cirrus_vga_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_cirrus_vga_initfn;
+    k->romfile = VGABIOS_CIRRUS_FILENAME;
+    k->vendor_id = PCI_VENDOR_ID_CIRRUS;
+    k->device_id = CIRRUS_ID_CLGD5446;
+    k->class_id = PCI_CLASS_DISPLAY_VGA;
+}
+
+static DeviceInfo cirrus_vga_info = {
+    .name = "cirrus-vga",
+    .desc = "Cirrus CLGD 54xx VGA",
+    .size = sizeof(PCICirrusVGAState),
+    .vmsd = &vmstate_pci_cirrus_vga,
+    .class_init = cirrus_vga_class_init,
 };
 
 static void cirrus_vga_register(void)
diff --git a/hw/dec_pci.c b/hw/dec_pci.c
index 08d4e06..7c3f50e 100644
--- a/hw/dec_pci.c
+++ b/hw/dec_pci.c
@@ -50,18 +50,25 @@ static int dec_map_irq(PCIDevice *pci_dev, int irq_num)
     return irq_num;
 }
 
-static PCIDeviceInfo dec_21154_pci_bridge_info = {
-    .qdev.name = "dec-21154-p2p-bridge",
-    .qdev.desc = "DEC 21154 PCI-PCI bridge",
-    .qdev.size = sizeof(PCIBridge),
-    .qdev.vmsd = &vmstate_pci_device,
-    .qdev.reset = pci_bridge_reset,
-    .init = pci_bridge_initfn,
-    .exit = pci_bridge_exitfn,
-    .vendor_id = PCI_VENDOR_ID_DEC,
-    .device_id = PCI_DEVICE_ID_DEC_21154,
-    .config_write = pci_bridge_write_config,
-    .is_bridge = 1,
+static void dec_21154_pci_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_bridge_initfn;
+    k->exit = pci_bridge_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_DEC;
+    k->device_id = PCI_DEVICE_ID_DEC_21154;
+    k->config_write = pci_bridge_write_config;
+    k->is_bridge = 1;
+}
+
+static DeviceInfo dec_21154_pci_bridge_info = {
+    .name = "dec-21154-p2p-bridge",
+    .desc = "DEC 21154 PCI-PCI bridge",
+    .size = sizeof(PCIBridge),
+    .vmsd = &vmstate_pci_device,
+    .reset = pci_bridge_reset,
+    .class_init = dec_21154_pci_bridge_class_init,
 };
 
 PCIBus *pci_dec_21154_init(PCIBus *parent_bus, int devfn)
@@ -98,21 +105,29 @@ static int dec_21154_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo dec_21154_pci_host_info = {
-    .qdev.name = "dec-21154",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = dec_21154_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_DEC,
-    .device_id = PCI_DEVICE_ID_DEC_21154,
-    .revision = 0x02,
-    .class_id = PCI_CLASS_BRIDGE_PCI,
-    .is_bridge  = 1,
+static void dec_21154_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = dec_21154_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_DEC;
+    k->device_id = PCI_DEVICE_ID_DEC_21154;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_BRIDGE_PCI;
+    k->is_bridge = 1;
+}
+
+static DeviceInfo dec_21154_pci_host_info = {
+    .name = "dec-21154",
+    .size = sizeof(PCIDevice),
+    .class_init = dec_21154_pci_host_class_init,
 };
 
 static void dec_register_devices(void)
 {
     sysbus_register_dev("dec-21154", sizeof(DECState),
                         pci_dec_21154_init_device);
+
     pci_qdev_register(&dec_21154_pci_host_info);
     pci_qdev_register(&dec_21154_pci_bridge_info);
 }
diff --git a/hw/e1000.c b/hw/e1000.c
index 6bab54e..c5d3ecb 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1192,23 +1192,32 @@ static void qdev_e1000_reset(DeviceState *dev)
     e1000_reset(d);
 }
 
-static PCIDeviceInfo e1000_info = {
-    .qdev.name  = "e1000",
-    .qdev.desc  = "Intel Gigabit Ethernet",
-    .qdev.size  = sizeof(E1000State),
-    .qdev.reset = qdev_e1000_reset,
-    .qdev.vmsd  = &vmstate_e1000,
-    .init       = pci_e1000_init,
-    .exit       = pci_e1000_uninit,
-    .romfile    = "pxe-e1000.rom",
-    .vendor_id  = PCI_VENDOR_ID_INTEL,
-    .device_id  = E1000_DEVID,
-    .revision   = 0x03,
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_NIC_PROPERTIES(E1000State, conf),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property e1000_properties[] = {
+    DEFINE_NIC_PROPERTIES(E1000State, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void e1000_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_e1000_init;
+    k->exit = pci_e1000_uninit;
+    k->romfile = "pxe-e1000.rom";
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = E1000_DEVID;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo e1000_info = {
+    .name = "e1000",
+    .desc = "Intel Gigabit Ethernet",
+    .size = sizeof(E1000State),
+    .reset = qdev_e1000_reset,
+    .vmsd = &vmstate_e1000,
+    .props = e1000_properties,
+    .class_init = e1000_class_init,
 };
 
 static void e1000_register_devices(void)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index f0059c6..9f6d333 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -128,7 +128,13 @@
 #define DRVR_INT        0x0200  /* Driver generated interrupt. */
 
 typedef struct {
-    PCIDeviceInfo pci;
+    DeviceInfo qdev;
+
+    uint16_t device_id;
+    uint8_t revision;
+    uint16_t subsystem_vendor_id;
+    uint16_t subsystem_id;
+
     uint32_t device;
     uint8_t stats_size;
     bool has_extended_tcb_support;
@@ -318,6 +324,8 @@ static const uint16_t eepro100_mdi_mask[] = {
 
 #define POLYNOMIAL 0x04c11db6
 
+static E100PCIDeviceInfo *eepro100_get_class(EEPRO100State *s);
+
 /* From FreeBSD */
 /* XXX: optimize */
 static unsigned compute_mcast_idx(const uint8_t * ep)
@@ -487,8 +495,9 @@ static void eepro100_fcp_interrupt(EEPRO100State * s)
 }
 #endif
 
-static void e100_pci_reset(EEPRO100State * s, E100PCIDeviceInfo *e100_device)
+static void e100_pci_reset(EEPRO100State * s)
 {
+    E100PCIDeviceInfo *info = eepro100_get_class(s);
     uint32_t device = s->device;
     uint8_t *pci_conf = s->dev.config;
 
@@ -508,8 +517,8 @@ static void e100_pci_reset(EEPRO100State * s, E100PCIDeviceInfo *e100_device)
     /* Maximum Latency */
     pci_set_byte(pci_conf + PCI_MAX_LAT, 0x18);
 
-    s->stats_size = e100_device->stats_size;
-    s->has_extended_tcb_support = e100_device->has_extended_tcb_support;
+    s->stats_size = info->stats_size;
+    s->has_extended_tcb_support = info->has_extended_tcb_support;
 
     switch (device) {
     case i82550:
@@ -558,7 +567,7 @@ static void e100_pci_reset(EEPRO100State * s, E100PCIDeviceInfo *e100_device)
     }
     assert(s->stats_size > 0 && s->stats_size <= sizeof(s->statistics));
 
-    if (e100_device->power_management) {
+    if (info->power_management) {
         /* Power Management Capabilities */
         int cfg_offset = 0xdc;
         int r = pci_add_capability(&s->dev, PCI_CAP_ID_PM,
@@ -1847,14 +1856,13 @@ static NetClientInfo net_eepro100_info = {
 static int e100_nic_init(PCIDevice *pci_dev)
 {
     EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
-    E100PCIDeviceInfo *e100_device = DO_UPCAST(E100PCIDeviceInfo, pci.qdev,
-                                               qdev_get_info(&pci_dev->qdev));
+    E100PCIDeviceInfo *info = eepro100_get_class(s);
 
     TRACE(OTHER, logout("\n"));
 
-    s->device = e100_device->device;
+    s->device = info->device;
 
-    e100_pci_reset(s, e100_device);
+    e100_pci_reset(s);
 
     /* Add 64 * 2 EEPROM. i82557 and i82558 support a 64 word EEPROM,
      * i82559 and later support 64 or 256 word EEPROM. */
@@ -1897,136 +1905,182 @@ static int e100_nic_init(PCIDevice *pci_dev)
 
 static E100PCIDeviceInfo e100_devices[] = {
     {
-        .pci.qdev.name = "i82550",
-        .pci.qdev.desc = "Intel i82550 Ethernet",
+        .qdev.name = "i82550",
+        .qdev.desc = "Intel i82550 Ethernet",
         .device = i82550,
         /* TODO: check device id. */
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82551IT,
+        .device_id = PCI_DEVICE_ID_INTEL_82551IT,
         /* Revision ID: 0x0c, 0x0d, 0x0e. */
-        .pci.revision = 0x0e,
+        .revision = 0x0e,
         /* TODO: check size of statistical counters. */
         .stats_size = 80,
         /* TODO: check extended tcb support. */
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82551",
-        .pci.qdev.desc = "Intel i82551 Ethernet",
+        .qdev.name = "i82551",
+        .qdev.desc = "Intel i82551 Ethernet",
         .device = i82551,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82551IT,
+        .device_id = PCI_DEVICE_ID_INTEL_82551IT,
         /* Revision ID: 0x0f, 0x10. */
-        .pci.revision = 0x0f,
+        .revision = 0x0f,
         /* TODO: check size of statistical counters. */
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82557a",
-        .pci.qdev.desc = "Intel i82557A Ethernet",
+        .qdev.name = "i82557a",
+        .qdev.desc = "Intel i82557A Ethernet",
         .device = i82557A,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x01,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x01,
         .power_management = false,
     },{
-        .pci.qdev.name = "i82557b",
-        .pci.qdev.desc = "Intel i82557B Ethernet",
+        .qdev.name = "i82557b",
+        .qdev.desc = "Intel i82557B Ethernet",
         .device = i82557B,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x02,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x02,
         .power_management = false,
     },{
-        .pci.qdev.name = "i82557c",
-        .pci.qdev.desc = "Intel i82557C Ethernet",
+        .qdev.name = "i82557c",
+        .qdev.desc = "Intel i82557C Ethernet",
         .device = i82557C,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x03,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x03,
         .power_management = false,
     },{
-        .pci.qdev.name = "i82558a",
-        .pci.qdev.desc = "Intel i82558A Ethernet",
+        .qdev.name = "i82558a",
+        .qdev.desc = "Intel i82558A Ethernet",
         .device = i82558A,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x04,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x04,
         .stats_size = 76,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82558b",
-        .pci.qdev.desc = "Intel i82558B Ethernet",
+        .qdev.name = "i82558b",
+        .qdev.desc = "Intel i82558B Ethernet",
         .device = i82558B,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x05,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x05,
         .stats_size = 76,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82559a",
-        .pci.qdev.desc = "Intel i82559A Ethernet",
+        .qdev.name = "i82559a",
+        .qdev.desc = "Intel i82559A Ethernet",
         .device = i82559A,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x06,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x06,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82559b",
-        .pci.qdev.desc = "Intel i82559B Ethernet",
+        .qdev.name = "i82559b",
+        .qdev.desc = "Intel i82559B Ethernet",
         .device = i82559B,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x07,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x07,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82559c",
-        .pci.qdev.desc = "Intel i82559C Ethernet",
+        .qdev.name = "i82559c",
+        .qdev.desc = "Intel i82559C Ethernet",
         .device = i82559C,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
 #if 0
-        .pci.revision = 0x08,
+        .revision = 0x08,
 #endif
         /* TODO: Windows wants revision id 0x0c. */
-        .pci.revision = 0x0c,
+        .revision = 0x0c,
 #if EEPROM_SIZE > 0
-        .pci.subsystem_vendor_id = PCI_VENDOR_ID_INTEL,
-        .pci.subsystem_id = 0x0040,
+        .subsystem_vendor_id = PCI_VENDOR_ID_INTEL,
+        .subsystem_id = 0x0040,
 #endif
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82559er",
-        .pci.qdev.desc = "Intel i82559ER Ethernet",
+        .qdev.name = "i82559er",
+        .qdev.desc = "Intel i82559ER Ethernet",
         .device = i82559ER,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82551IT,
-        .pci.revision = 0x09,
+        .device_id = PCI_DEVICE_ID_INTEL_82551IT,
+        .revision = 0x09,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82562",
-        .pci.qdev.desc = "Intel i82562 Ethernet",
+        .qdev.name = "i82562",
+        .qdev.desc = "Intel i82562 Ethernet",
         .device = i82562,
         /* TODO: check device id. */
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82551IT,
+        .device_id = PCI_DEVICE_ID_INTEL_82551IT,
         /* TODO: wrong revision id. */
-        .pci.revision = 0x0e,
+        .revision = 0x0e,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
         /* Toshiba Tecra 8200. */
-        .pci.qdev.name = "i82801",
-        .pci.qdev.desc = "Intel i82801 Ethernet",
+        .qdev.name = "i82801",
+        .qdev.desc = "Intel i82801 Ethernet",
         .device = i82801,
-        .pci.device_id = 0x2449,
-        .pci.revision = 0x03,
+        .device_id = 0x2449,
+        .revision = 0x03,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     }
 };
 
+static E100PCIDeviceInfo *eepro100_get_class_by_name(const char *typename)
+{
+    E100PCIDeviceInfo *info = NULL;
+    int i;
+
+    /* This is admittedly awkward but also temporary.  QOM allows for
+     * parameterized typing and for subclassing both of which would suitable
+     * handle what's going on here.  But class_data is already being used as
+     * a stop-gap hack to allow incremental qdev conversion so we cannot use it
+     * right now.  Once we merge the final QOM series, we can come back here and
+     * do this in a much more elegant fashion.
+     */
+    for (i = 0; i < ARRAY_SIZE(e100_devices); i++) {
+        if (strcmp(e100_devices[i].qdev.name, typename) == 0) {
+            info = &e100_devices[i];
+            break;
+        }
+    }
+    assert(info != NULL);
+
+    return info;
+}
+
+static E100PCIDeviceInfo *eepro100_get_class(EEPRO100State *s)
+{
+    return eepro100_get_class_by_name(object_get_typename(OBJECT(s)));
+}
+
+static void eepro100_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+    E100PCIDeviceInfo *info;
+
+    info = eepro100_get_class_by_name(object_class_get_name(klass));
+
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+    k->romfile = "pxe-eepro100.rom";
+    k->init = e100_nic_init;
+    k->exit = pci_nic_uninit;
+    k->device_id = info->device_id;
+    k->revision = info->revision;
+    k->subsystem_vendor_id = info->subsystem_vendor_id;
+    k->subsystem_id = info->subsystem_id;
+}
+
 static Property e100_properties[] = {
     DEFINE_NIC_PROPERTIES(EEPRO100State, conf),
     DEFINE_PROP_END_OF_LIST(),
@@ -2036,17 +2090,13 @@ static void eepro100_register_devices(void)
 {
     size_t i;
     for (i = 0; i < ARRAY_SIZE(e100_devices); i++) {
-        PCIDeviceInfo *pci_dev = &e100_devices[i].pci;
-        /* We use the same rom file for all device ids.
-           QEMU fixes the device id during rom load. */
-        pci_dev->vendor_id = PCI_VENDOR_ID_INTEL;
-        pci_dev->class_id = PCI_CLASS_NETWORK_ETHERNET;
-        pci_dev->romfile = "pxe-eepro100.rom";
-        pci_dev->init = e100_nic_init;
-        pci_dev->exit = pci_nic_uninit;
-        pci_dev->qdev.props = e100_properties;
-        pci_dev->qdev.size = sizeof(EEPRO100State);
-        pci_qdev_register(pci_dev);
+        DeviceInfo *info = &e100_devices[i].qdev;
+
+        info->class_init = eepro100_class_init;
+        info->size = sizeof(EEPRO100State);
+        info->props = e100_properties;
+        
+        pci_qdev_register(info);
     }
 }
 
diff --git a/hw/es1370.c b/hw/es1370.c
index 3527eb6..205bed7 100644
--- a/hw/es1370.c
+++ b/hw/es1370.c
@@ -1031,18 +1031,25 @@ int es1370_init (PCIBus *bus)
     return 0;
 }
 
-static PCIDeviceInfo es1370_info = {
-    .qdev.name    = "ES1370",
-    .qdev.desc    = "ENSONIQ AudioPCI ES1370",
-    .qdev.size    = sizeof (ES1370State),
-    .qdev.vmsd    = &vmstate_es1370,
-    .init         = es1370_initfn,
-    .exit         = es1370_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_ENSONIQ,
-    .device_id    = PCI_DEVICE_ID_ENSONIQ_ES1370,
-    .class_id     = PCI_CLASS_MULTIMEDIA_AUDIO,
-    .subsystem_vendor_id = 0x4942,
-    .subsystem_id = 0x4c4c,
+static void es1370_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = es1370_initfn;
+    k->exit = es1370_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_ENSONIQ;
+    k->device_id = PCI_DEVICE_ID_ENSONIQ_ES1370;
+    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
+    k->subsystem_vendor_id = 0x4942;
+    k->subsystem_id = 0x4c4c;
+}
+
+static DeviceInfo es1370_info = {
+    .name = "ES1370",
+    .desc = "ENSONIQ AudioPCI ES1370",
+    .size = sizeof (ES1370State),
+    .vmsd = &vmstate_es1370,
+    .class_init = es1370_class_init,
 };
 
 static void es1370_register (void)
diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index be10a6d..a790f97 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -121,15 +121,22 @@ static int grackle_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo grackle_pci_info = {
-    .qdev.name = "grackle",
-    .qdev.size = sizeof(PCIDevice),
-    .qdev.no_user = 1,
-    .init      = grackle_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_MOTOROLA,
-    .device_id = PCI_DEVICE_ID_MOTOROLA_MPC106,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void grackle_pci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = grackle_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_MOTOROLA;
+    k->device_id = PCI_DEVICE_ID_MOTOROLA_MPC106;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo grackle_pci_info = {
+    .name = "grackle",
+    .size = sizeof(PCIDevice),
+    .no_user = 1,
+    .class_init = grackle_pci_class_init,
 };
 
 static SysBusDeviceInfo grackle_pci_host_info = {
diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c
index 432683a..9fc51f2 100644
--- a/hw/gt64xxx.c
+++ b/hw/gt64xxx.c
@@ -1136,14 +1136,21 @@ static int gt64120_pci_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo gt64120_pci_info = {
-    .qdev.name = "gt64120_pci",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = gt64120_pci_init,
-    .vendor_id = PCI_VENDOR_ID_MARVELL,
-    .device_id = PCI_DEVICE_ID_MARVELL_GT6412X,
-    .revision  = 0x10,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void gt64120_pci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = gt64120_pci_init;
+    k->vendor_id = PCI_VENDOR_ID_MARVELL;
+    k->device_id = PCI_DEVICE_ID_MARVELL_GT6412X;
+    k->revision = 0x10;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo gt64120_pci_info = {
+    .name = "gt64120_pci",
+    .size = sizeof(PCIDevice),
+    .class_init = gt64120_pci_class_init,
 };
 
 static void gt64120_pci_register_devices(void)
diff --git a/hw/i82378.c b/hw/i82378.c
index 95ae274..99b453a 100644
--- a/hw/i82378.c
+++ b/hw/i82378.c
@@ -238,18 +238,25 @@ static int pci_i82378_init(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo pci_i82378_info = {
-    .init = pci_i82378_init,
-    .qdev.name = "i82378",
-    .qdev.size = sizeof(PCIi82378State),
-    .qdev.vmsd = &vmstate_pci_i82378,
-    .vendor_id = PCI_VENDOR_ID_INTEL,
-    .device_id = PCI_DEVICE_ID_INTEL_82378,
-    .revision = 0x03,
-    .class_id = PCI_CLASS_BRIDGE_ISA,
-    .subsystem_vendor_id = 0x0,
-    .subsystem_id = 0x0,
-    .qdev.props = (Property[]) {
+static void pci_i82378_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_i82378_init;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82378;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+    k->subsystem_vendor_id = 0x0;
+    k->subsystem_id = 0x0;
+}
+
+static DeviceInfo pci_i82378_info = {
+    .name = "i82378",
+    .size = sizeof(PCIi82378State),
+    .vmsd = &vmstate_pci_i82378,
+    .class_init = pci_i82378_class_init,
+    .props = (Property[]) {
         DEFINE_PROP_HEX32("iobase", PCIi82378State, isa_io_base, 0x80000000),
         DEFINE_PROP_HEX32("membase", PCIi82378State, isa_mem_base, 0xc0000000),
         DEFINE_PROP_END_OF_LIST()
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index 99e7e6f..9c673bb 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -325,20 +325,28 @@ void pci_cmd646_ide_init(PCIBus *bus, DriveInfo **hd_table,
     pci_ide_create_devs(dev, hd_table);
 }
 
-static PCIDeviceInfo cmd646_ide_info = {
-    .qdev.name    = "cmd646-ide",
-    .qdev.size    = sizeof(PCIIDEState),
-    .init         = pci_cmd646_ide_initfn,
-    .exit         = pci_cmd646_ide_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_CMD,
-    .device_id    = PCI_DEVICE_ID_CMD_646,
-    /* IDE controller revision */
-    .revision     = 0x07,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
-    .qdev.props   = (Property[]) {
-        DEFINE_PROP_UINT32("secondary", PCIIDEState, secondary, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    },
+static Property cmd646_ide_properties[] = {
+    DEFINE_PROP_UINT32("secondary", PCIIDEState, secondary, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void cmd646_ide_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_cmd646_ide_initfn;
+    k->exit = pci_cmd646_ide_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_CMD;
+    k->device_id = PCI_DEVICE_ID_CMD_646;
+    k->revision = 0x07;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo cmd646_ide_info = {
+    .name = "cmd646-ide",
+    .size = sizeof(PCIIDEState),
+    .props = cmd646_ide_properties,
+    .class_init = cmd646_ide_class_init,
 };
 
 static void cmd646_ide_register(void)
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index e6421e2..1cae9f1 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -146,18 +146,25 @@ static void pci_ich9_write_config(PCIDevice *pci, uint32_t addr,
     msi_write_config(pci, addr, val, len);
 }
 
-static PCIDeviceInfo ich_ahci_info = {
-    .qdev.name    = "ich9-ahci",
-    .qdev.alias   = "ahci",
-    .qdev.size    = sizeof(AHCIPCIState),
-    .qdev.vmsd    = &vmstate_ahci,
-    .init         = pci_ich9_ahci_init,
-    .exit         = pci_ich9_uninit,
-    .config_write = pci_ich9_write_config,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801IR,
-    .revision     = 0x02,
-    .class_id     = PCI_CLASS_STORAGE_SATA,
+static void ich_ahci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_ich9_ahci_init;
+    k->exit = pci_ich9_uninit;
+    k->config_write = pci_ich9_write_config;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801IR;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_STORAGE_SATA;
+}
+
+static DeviceInfo ich_ahci_info = {
+    .name = "ich9-ahci",
+    .alias = "ahci",
+    .size = sizeof(AHCIPCIState),
+    .vmsd = &vmstate_ahci,
+    .class_init = ich_ahci_class_init,
 };
 
 static void ich_ahci_register(void)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 91b77a2..832a507 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -237,39 +237,60 @@ PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
     return dev;
 }
 
-static PCIDeviceInfo piix3_ide_info = {
-    .qdev.name    = "piix3-ide",
-    .qdev.size    = sizeof(PCIIDEState),
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = pci_piix_ide_initfn,
-    .exit         = pci_piix_ide_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371SB_1,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
+static void piix3_ide_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_piix_ide_initfn;
+    k->exit = pci_piix_ide_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371SB_1;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo piix3_ide_info = {
+    .name = "piix3-ide",
+    .size = sizeof(PCIIDEState),
+    .no_user = 1,
+    .class_init = piix3_ide_class_init,
 };
 
-static PCIDeviceInfo piix3_ide_xen_info = {
-    .qdev.name    = "piix3-ide-xen",
-    .qdev.size    = sizeof(PCIIDEState),
-    .qdev.no_user = 1,
-    .qdev.unplug  = pci_piix3_xen_ide_unplug,
-    .init         = pci_piix_ide_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371SB_1,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
+static void piix3_ide_xen_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_piix_ide_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371SB_1;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo piix3_ide_xen_info = {
+    .name = "piix3-ide-xen",
+    .size = sizeof(PCIIDEState),
+    .no_user = 1,
+    .class_init = piix3_ide_xen_class_init,
+    .unplug = pci_piix3_xen_ide_unplug,
 };
 
-static PCIDeviceInfo piix4_ide_info = {
-    .qdev.name    = "piix4-ide",
-    .qdev.size    = sizeof(PCIIDEState),
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = pci_piix_ide_initfn,
-    .exit         = pci_piix_ide_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371AB,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
+static void piix4_ide_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_piix_ide_initfn;
+    k->exit = pci_piix_ide_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371AB;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo piix4_ide_info = {
+    .name = "piix4-ide",
+    .size = sizeof(PCIIDEState),
+    .no_user = 1,
+    .class_init = piix4_ide_class_init,
 };
 
 static void piix_ide_register(void)
diff --git a/hw/ide/via.c b/hw/ide/via.c
index 4ea2064..ef70864 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -213,16 +213,23 @@ void vt82c686b_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
     pci_ide_create_devs(dev, hd_table);
 }
 
-static PCIDeviceInfo via_ide_info = {
-    .qdev.name    = "via-ide",
-    .qdev.size    = sizeof(PCIIDEState),
-    .qdev.no_user = 1,
-    .init         = vt82c686b_ide_initfn,
-    .exit         = vt82c686b_ide_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_VIA,
-    .device_id    = PCI_DEVICE_ID_VIA_IDE,
-    .revision     = 0x06,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
+static void via_ide_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_ide_initfn;
+    k->exit = vt82c686b_ide_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_IDE;
+    k->revision = 0x06;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo via_ide_info = {
+    .name = "via-ide",
+    .size = sizeof(PCIIDEState),
+    .no_user = 1,
+    .class_init = via_ide_class_init,
 };
 
 static void via_ide_register(void)
diff --git a/hw/intel-hda.c b/hw/intel-hda.c
index f727c22..f062133 100644
--- a/hw/intel-hda.c
+++ b/hw/intel-hda.c
@@ -79,7 +79,7 @@ void hda_codec_register(DeviceInfo *info)
     info->init = hda_codec_dev_init;
     info->exit = hda_codec_dev_exit;
     info->bus_info = &hda_codec_bus_info;
-    qdev_register(info);
+    qdev_register_subclass(info, TYPE_HDA_CODEC_DEVICE);
 }
 
 HDACodecDevice *hda_codec_find(HDACodecBus *bus, uint32_t cad)
@@ -1247,29 +1247,47 @@ static const VMStateDescription vmstate_intel_hda = {
     }
 };
 
-static PCIDeviceInfo intel_hda_info = {
-    .qdev.name    = "intel-hda",
-    .qdev.desc    = "Intel HD Audio Controller",
-    .qdev.size    = sizeof(IntelHDAState),
-    .qdev.vmsd    = &vmstate_intel_hda,
-    .qdev.reset   = intel_hda_reset,
-    .init         = intel_hda_init,
-    .exit         = intel_hda_exit,
-    .config_write = intel_hda_write_config,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = 0x2668,
-    .revision     = 1,
-    .class_id     = PCI_CLASS_MULTIMEDIA_HD_AUDIO,
-    .qdev.props   = (Property[]) {
-        DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0),
-        DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property intel_hda_properties[] = {
+    DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0),
+    DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void intel_hda_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = intel_hda_init;
+    k->exit = intel_hda_exit;
+    k->config_write = intel_hda_write_config;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = 0x2668;
+    k->revision = 1;
+    k->class_id = PCI_CLASS_MULTIMEDIA_HD_AUDIO;
+}
+
+static DeviceInfo intel_hda_info = {
+    .name = "intel-hda",
+    .desc = "Intel HD Audio Controller",
+    .size = sizeof(IntelHDAState),
+    .vmsd = &vmstate_intel_hda,
+    .reset = intel_hda_reset,
+    .props = intel_hda_properties,
+    .class_init = intel_hda_class_init,
+};
+
+static TypeInfo hda_codec_device_type_info = {
+    .name = TYPE_HDA_CODEC_DEVICE,
+    .parent = TYPE_DEVICE,
+    .instance_size = sizeof(HDACodecDevice),
+    .abstract = true,
+    .class_size = sizeof(HDACodecDeviceClass),
 };
 
 static void intel_hda_register(void)
 {
     pci_qdev_register(&intel_hda_info);
+    type_register_static(&hda_codec_device_type_info);
 }
 device_init(intel_hda_register);
 
diff --git a/hw/ioh3420.c b/hw/ioh3420.c
index a6bfbb9..6cfafb3 100644
--- a/hw/ioh3420.c
+++ b/hw/ioh3420.c
@@ -80,7 +80,7 @@ static void ioh3420_write_config(PCIDevice *d,
 
 static void ioh3420_reset(DeviceState *qdev)
 {
-    PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *d = PCI_DEVICE(qdev);
     msi_reset(d);
     ioh3420_aer_vector_update(d);
     pcie_cap_root_reset(d);
@@ -201,31 +201,38 @@ static const VMStateDescription vmstate_ioh3420 = {
     }
 };
 
-static PCIDeviceInfo ioh3420_info = {
-    .qdev.name = "ioh3420",
-    .qdev.desc = "Intel IOH device id 3420 PCIE Root Port",
-    .qdev.size = sizeof(PCIESlot),
-    .qdev.reset = ioh3420_reset,
-    .qdev.vmsd = &vmstate_ioh3420,
-
-    .is_express = 1,
-    .is_bridge = 1,
-    .config_write = ioh3420_write_config,
-    .init = ioh3420_initfn,
-    .exit = ioh3420_exitfn,
-    .vendor_id = PCI_VENDOR_ID_INTEL,
-    .device_id = PCI_DEVICE_ID_IOH_EPORT,
-    .revision = PCI_DEVICE_ID_IOH_REV,
-
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
-        DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
-        DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
-        DEFINE_PROP_UINT16("aer_log_max", PCIESlot,
-                           port.br.dev.exp.aer_log.log_max,
-                           PCIE_AER_LOG_MAX_DEFAULT),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property ioh3420_properties[] = {
+    DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
+    DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
+    DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
+    DEFINE_PROP_UINT16("aer_log_max", PCIESlot,
+    port.br.dev.exp.aer_log.log_max,
+    PCIE_AER_LOG_MAX_DEFAULT),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ioh3420_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->is_express = 1;
+    k->is_bridge = 1;
+    k->config_write = ioh3420_write_config;
+    k->init = ioh3420_initfn;
+    k->exit = ioh3420_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_IOH_EPORT;
+    k->revision = PCI_DEVICE_ID_IOH_REV;
+}
+
+static DeviceInfo ioh3420_info = {
+    .name = "ioh3420",
+    .desc = "Intel IOH device id 3420 PCIE Root Port",
+    .size = sizeof(PCIESlot),
+    .reset = ioh3420_reset,
+    .vmsd = &vmstate_ioh3420,
+    .props = ioh3420_properties,
+    .class_init = ioh3420_class_init,
 };
 
 static void ioh3420_register(void)
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index bec2e0b..e2880be 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -766,25 +766,34 @@ static int pci_ivshmem_uninit(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo ivshmem_info = {
-    .qdev.name  = "ivshmem",
-    .qdev.size  = sizeof(IVShmemState),
-    .qdev.reset = ivshmem_reset,
-    .init       = pci_ivshmem_init,
-    .exit       = pci_ivshmem_uninit,
-    .vendor_id  = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id  = 0x1110,
-    .class_id   = PCI_CLASS_MEMORY_RAM,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_CHR("chardev", IVShmemState, server_chr),
-        DEFINE_PROP_STRING("size", IVShmemState, sizearg),
-        DEFINE_PROP_UINT32("vectors", IVShmemState, vectors, 1),
-        DEFINE_PROP_BIT("ioeventfd", IVShmemState, features, IVSHMEM_IOEVENTFD, false),
-        DEFINE_PROP_BIT("msi", IVShmemState, features, IVSHMEM_MSI, true),
-        DEFINE_PROP_STRING("shm", IVShmemState, shmobj),
-        DEFINE_PROP_STRING("role", IVShmemState, role),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property ivshmem_properties[] = {
+    DEFINE_PROP_CHR("chardev", IVShmemState, server_chr),
+    DEFINE_PROP_STRING("size", IVShmemState, sizearg),
+    DEFINE_PROP_UINT32("vectors", IVShmemState, vectors, 1),
+    DEFINE_PROP_BIT("ioeventfd", IVShmemState, features, IVSHMEM_IOEVENTFD, false),
+    DEFINE_PROP_BIT("msi", IVShmemState, features, IVSHMEM_MSI, true),
+    DEFINE_PROP_STRING("shm", IVShmemState, shmobj),
+    DEFINE_PROP_STRING("role", IVShmemState, role),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ivshmem_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_ivshmem_init;
+    k->exit = pci_ivshmem_uninit;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = 0x1110;
+    k->class_id = PCI_CLASS_MEMORY_RAM;
+}
+
+static DeviceInfo ivshmem_info = {
+    .name = "ivshmem",
+    .size = sizeof(IVShmemState),
+    .reset = ivshmem_reset,
+    .props = ivshmem_properties,
+    .class_init = ivshmem_class_init,
 };
 
 static void ivshmem_register_devices(void)
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index 3a87171..3571588 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895a.c
@@ -2120,18 +2120,25 @@ static int lsi_scsi_init(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo lsi_info = {
-    .qdev.name  = "lsi53c895a",
-    .qdev.alias = "lsi",
-    .qdev.size  = sizeof(LSIState),
-    .qdev.reset = lsi_scsi_reset,
-    .qdev.vmsd  = &vmstate_lsi_scsi,
-    .init       = lsi_scsi_init,
-    .exit       = lsi_scsi_uninit,
-    .vendor_id  = PCI_VENDOR_ID_LSI_LOGIC,
-    .device_id  = PCI_DEVICE_ID_LSI_53C895A,
-    .class_id   = PCI_CLASS_STORAGE_SCSI,
-    .subsystem_id = 0x1000,
+static void lsi_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = lsi_scsi_init;
+    k->exit = lsi_scsi_uninit;
+    k->vendor_id = PCI_VENDOR_ID_LSI_LOGIC;
+    k->device_id = PCI_DEVICE_ID_LSI_53C895A;
+    k->class_id = PCI_CLASS_STORAGE_SCSI;
+    k->subsystem_id = 0x1000;
+}
+
+static DeviceInfo lsi_info = {
+    .name = "lsi53c895a",
+    .alias = "lsi",
+    .size = sizeof(LSIState),
+    .reset = lsi_scsi_reset,
+    .vmsd = &vmstate_lsi_scsi,
+    .class_init = lsi_class_init,
 };
 
 static void lsi53c895a_register_devices(void)
diff --git a/hw/macio.c b/hw/macio.c
index 357e0ea..ae9db08 100644
--- a/hw/macio.c
+++ b/hw/macio.c
@@ -81,12 +81,19 @@ static int macio_initfn(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo macio_info = {
-    .qdev.name = "macio",
-    .qdev.size = sizeof(MacIOState),
-    .init = macio_initfn,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .class_id = PCI_CLASS_OTHERS << 8,
+static void macio_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = macio_initfn;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->class_id = PCI_CLASS_OTHERS << 8;
+}
+
+static DeviceInfo macio_info = {
+    .name = "macio",
+    .size = sizeof(MacIOState),
+    .class_init = macio_class_init,
 };
 
 static void macio_register(void)
diff --git a/hw/ne2000.c b/hw/ne2000.c
index b44eab1..138479a 100644
--- a/hw/ne2000.c
+++ b/hw/ne2000.c
@@ -786,19 +786,28 @@ static int pci_ne2000_exit(PCIDevice *pci_dev)
     return 0;
 }
 
-static PCIDeviceInfo ne2000_info = {
-    .qdev.name  = "ne2k_pci",
-    .qdev.size  = sizeof(PCINE2000State),
-    .qdev.vmsd  = &vmstate_pci_ne2000,
-    .init       = pci_ne2000_init,
-    .exit       = pci_ne2000_exit,
-    .vendor_id  = PCI_VENDOR_ID_REALTEK,
-    .device_id  = PCI_DEVICE_ID_REALTEK_8029,
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_NIC_PROPERTIES(PCINE2000State, ne2000.c),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property ne2000_properties[] = {
+    DEFINE_NIC_PROPERTIES(PCINE2000State, ne2000.c),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ne2000_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_ne2000_init;
+    k->exit = pci_ne2000_exit;
+    k->vendor_id = PCI_VENDOR_ID_REALTEK;
+    k->device_id = PCI_DEVICE_ID_REALTEK_8029;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo ne2000_info = {
+    .name = "ne2k_pci",
+    .size = sizeof(PCINE2000State),
+    .vmsd = &vmstate_pci_ne2000,
+    .props = ne2000_properties,
+    .class_init = ne2000_class_init,
 };
 
 static void ne2000_register_devices(void)
diff --git a/hw/pci.c b/hw/pci.c
index 516da08..6a0b1f5 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -89,7 +89,6 @@ static const VMStateDescription vmstate_pcibus = {
         VMSTATE_END_OF_LIST()
     }
 };
-
 static int pci_bar(PCIDevice *d, int reg)
 {
     uint8_t type;
@@ -730,11 +729,11 @@ static void pci_config_free(PCIDevice *pci_dev)
 
 /* -1 for devfn means auto assign */
 static PCIDevice *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
-                                         const char *name, int devfn,
-                                         const PCIDeviceInfo *info)
+                                         const char *name, int devfn)
 {
-    PCIConfigReadFunc *config_read = info->config_read;
-    PCIConfigWriteFunc *config_write = info->config_write;
+    PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pci_dev);
+    PCIConfigReadFunc *config_read = pc->config_read;
+    PCIConfigWriteFunc *config_write = pc->config_write;
 
     if (devfn < 0) {
         for(devfn = bus->devfn_min ; devfn < ARRAY_SIZE(bus->devices);
@@ -756,29 +755,29 @@ static PCIDevice *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
     pci_dev->irq_state = 0;
     pci_config_alloc(pci_dev);
 
-    pci_config_set_vendor_id(pci_dev->config, info->vendor_id);
-    pci_config_set_device_id(pci_dev->config, info->device_id);
-    pci_config_set_revision(pci_dev->config, info->revision);
-    pci_config_set_class(pci_dev->config, info->class_id);
+    pci_config_set_vendor_id(pci_dev->config, pc->vendor_id);
+    pci_config_set_device_id(pci_dev->config, pc->device_id);
+    pci_config_set_revision(pci_dev->config, pc->revision);
+    pci_config_set_class(pci_dev->config, pc->class_id);
 
-    if (!info->is_bridge) {
-        if (info->subsystem_vendor_id || info->subsystem_id) {
+    if (!pc->is_bridge) {
+        if (pc->subsystem_vendor_id || pc->subsystem_id) {
             pci_set_word(pci_dev->config + PCI_SUBSYSTEM_VENDOR_ID,
-                         info->subsystem_vendor_id);
+                         pc->subsystem_vendor_id);
             pci_set_word(pci_dev->config + PCI_SUBSYSTEM_ID,
-                         info->subsystem_id);
+                         pc->subsystem_id);
         } else {
             pci_set_default_subsystem_id(pci_dev);
         }
     } else {
         /* subsystem_vendor_id/subsystem_id are only for header type 0 */
-        assert(!info->subsystem_vendor_id);
-        assert(!info->subsystem_id);
+        assert(!pc->subsystem_vendor_id);
+        assert(!pc->subsystem_id);
     }
     pci_init_cmask(pci_dev);
     pci_init_wmask(pci_dev);
     pci_init_w1cmask(pci_dev);
-    if (info->is_bridge) {
+    if (pc->is_bridge) {
         pci_init_wmask_bridge(pci_dev);
     }
     if (pci_init_multifunction(bus, pci_dev)) {
@@ -805,26 +804,6 @@ static void do_pci_unregister_device(PCIDevice *pci_dev)
     pci_config_free(pci_dev);
 }
 
-/* TODO: obsolete. eliminate this once all pci devices are qdevifed. */
-PCIDevice *pci_register_device(PCIBus *bus, const char *name,
-                               int instance_size, int devfn,
-                               PCIConfigReadFunc *config_read,
-                               PCIConfigWriteFunc *config_write)
-{
-    PCIDevice *pci_dev;
-    PCIDeviceInfo info = {
-        .config_read = config_read,
-        .config_write = config_write,
-    };
-
-    pci_dev = g_malloc0(instance_size);
-    pci_dev = do_pci_register_device(pci_dev, bus, name, devfn, &info);
-    if (pci_dev == NULL) {
-        hw_error("PCI: can't register device\n");
-    }
-    return pci_dev;
-}
-
 static void pci_unregister_io_regions(PCIDevice *pci_dev)
 {
     PCIIORegion *r;
@@ -840,12 +819,12 @@ static void pci_unregister_io_regions(PCIDevice *pci_dev)
 
 static int pci_unregister_device(DeviceState *dev)
 {
-    PCIDevice *pci_dev = DO_UPCAST(PCIDevice, qdev, dev);
-    PCIDeviceInfo *info = DO_UPCAST(PCIDeviceInfo, qdev, qdev_get_info(dev));
+    PCIDevice *pci_dev = PCI_DEVICE(dev);
+    PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pci_dev);
     int ret = 0;
 
-    if (info->exit)
-        ret = info->exit(pci_dev);
+    if (pc->exit)
+        ret = pc->exit(pci_dev);
     if (ret)
         return ret;
 
@@ -1477,28 +1456,27 @@ PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn)
 static int pci_qdev_init(DeviceState *qdev, DeviceInfo *base)
 {
     PCIDevice *pci_dev = (PCIDevice *)qdev;
-    PCIDeviceInfo *info = container_of(base, PCIDeviceInfo, qdev);
+    PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pci_dev);
     PCIBus *bus;
     int rc;
     bool is_default_rom;
 
     /* initialize cap_present for pci_is_express() and pci_config_size() */
-    if (info->is_express) {
+    if (pc->is_express) {
         pci_dev->cap_present |= QEMU_PCI_CAP_EXPRESS;
     }
 
     bus = FROM_QBUS(PCIBus, qdev_get_parent_bus(qdev));
-    pci_dev = do_pci_register_device(pci_dev, bus, base->name,
-                                     pci_dev->devfn, info);
+    pci_dev = do_pci_register_device(pci_dev, bus, base->name, pci_dev->devfn);
     if (pci_dev == NULL)
         return -1;
-    if (qdev->hotplugged && info->no_hotplug) {
+    if (qdev->hotplugged && pc->no_hotplug) {
         qerror_report(QERR_DEVICE_NO_HOTPLUG, object_get_typename(OBJECT(pci_dev)));
         do_pci_unregister_device(pci_dev);
         return -1;
     }
-    if (info->init) {
-        rc = info->init(pci_dev);
+    if (pc->init) {
+        rc = pc->init(pci_dev);
         if (rc != 0) {
             do_pci_unregister_device(pci_dev);
             return rc;
@@ -1507,8 +1485,8 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo *base)
 
     /* rom loading */
     is_default_rom = false;
-    if (pci_dev->romfile == NULL && info->romfile != NULL) {
-        pci_dev->romfile = g_strdup(info->romfile);
+    if (pci_dev->romfile == NULL && pc->romfile != NULL) {
+        pci_dev->romfile = g_strdup(pc->romfile);
         is_default_rom = true;
     }
     pci_add_option_rom(pci_dev, is_default_rom);
@@ -1530,10 +1508,10 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo *base)
 
 static int pci_unplug_device(DeviceState *qdev)
 {
-    PCIDevice *dev = DO_UPCAST(PCIDevice, qdev, qdev);
-    PCIDeviceInfo *info = container_of(qdev_get_info(qdev), PCIDeviceInfo, qdev);
+    PCIDevice *dev = PCI_DEVICE(qdev);
+    PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
 
-    if (info->no_hotplug) {
+    if (pc->no_hotplug) {
         qerror_report(QERR_DEVICE_NO_HOTPLUG, object_get_typename(OBJECT(dev)));
         return -1;
     }
@@ -1541,23 +1519,15 @@ static int pci_unplug_device(DeviceState *qdev)
                              PCI_HOTPLUG_DISABLED);
 }
 
-void pci_qdev_register(PCIDeviceInfo *info)
-{
-    info->qdev.init = pci_qdev_init;
-    if (!info->qdev.unplug) {
-        info->qdev.unplug = pci_unplug_device;
-    }
-    info->qdev.exit = pci_unregister_device;
-    info->qdev.bus_info = &pci_bus_info;
-    qdev_register(&info->qdev);
-}
-
-void pci_qdev_register_many(PCIDeviceInfo *info)
+void pci_qdev_register(DeviceInfo *info)
 {
-    while (info->qdev.name) {
-        pci_qdev_register(info);
-        info++;
+    info->init = pci_qdev_init;
+    if (!info->unplug) {
+        info->unplug = pci_unplug_device;
     }
+    info->exit = pci_unregister_device;
+    info->bus_info = &pci_bus_info;
+    qdev_register_subclass(info, TYPE_PCI_DEVICE);
 }
 
 PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool multifunction,
@@ -1568,7 +1538,7 @@ PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool multifunction,
     dev = qdev_create(&bus->qbus, name);
     qdev_prop_set_uint32(dev, "addr", devfn);
     qdev_prop_set_bit(dev, "multifunction", multifunction);
-    return DO_UPCAST(PCIDevice, qdev, dev);
+    return PCI_DEVICE(dev);
 }
 
 PCIDevice *pci_create_simple_multifunction(PCIBus *bus, int devfn,
@@ -1985,7 +1955,7 @@ static int pci_qdev_find_recursive(PCIBus *bus,
     /* roughly check if given qdev is pci device */
     if (qdev_get_info(qdev)->init == &pci_qdev_init &&
         qdev->parent_bus->info == &pci_bus_info) {
-        *pdev = DO_UPCAST(PCIDevice, qdev, qdev);
+        *pdev = PCI_DEVICE(qdev);
         return 0;
     }
     return -EINVAL;
@@ -2019,3 +1989,18 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
 {
     return dev->bus->address_space_io;
 }
+
+static TypeInfo pci_device_type_info = {
+    .name = TYPE_PCI_DEVICE,
+    .parent = TYPE_DEVICE,
+    .instance_size = sizeof(PCIDevice),
+    .abstract = true,
+    .class_size = sizeof(PCIDeviceClass),
+};
+
+static void pci_register_devices(void)
+{
+    type_register_static(&pci_device_type_info);
+}
+
+device_init(pci_register_devices);
diff --git a/hw/pci.h b/hw/pci.h
index 5501d95..09b2324 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -127,6 +127,46 @@ enum {
     QEMU_PCI_CAP_SERR = (1 << QEMU_PCI_CAP_SERR_BITNR),
 };
 
+#define TYPE_PCI_DEVICE "pci-device"
+#define PCI_DEVICE(obj) \
+     OBJECT_CHECK(PCIDevice, (obj), TYPE_PCI_DEVICE)
+#define PCI_DEVICE_CLASS(klass) \
+     OBJECT_CLASS_CHECK(PCIDeviceClass, (klass), TYPE_PCI_DEVICE)
+#define PCI_DEVICE_GET_CLASS(obj) \
+     OBJECT_GET_CLASS(PCIDeviceClass, (obj), TYPE_PCI_DEVICE)
+
+typedef struct PCIDeviceClass {
+    DeviceClass parent_class;
+
+    int (*init)(PCIDevice *dev);
+    PCIUnregisterFunc *exit;
+    PCIConfigReadFunc *config_read;
+    PCIConfigWriteFunc *config_write;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+    uint8_t revision;
+    uint16_t class_id;
+    uint16_t subsystem_vendor_id;       /* only for header type = 0 */
+    uint16_t subsystem_id;              /* only for header type = 0 */
+
+    /*
+     * pci-to-pci bridge or normal device.
+     * This doesn't mean pci host switch.
+     * When card bus bridge is supported, this would be enhanced.
+     */
+    int is_bridge;
+
+    /* pcie stuff */
+    int is_express;   /* is this device pci express? */
+
+    /* device isn't hot-pluggable */
+    int no_hotplug;
+
+    /* rom bar */
+    const char *romfile;
+} PCIDeviceClass;
+
 struct PCIDevice {
     DeviceState qdev;
     /* PCI config space */
@@ -196,11 +236,6 @@ struct PCIDevice {
     uint32_t rom_bar;
 };
 
-PCIDevice *pci_register_device(PCIBus *bus, const char *name,
-                               int instance_size, int devfn,
-                               PCIConfigReadFunc *config_read,
-                               PCIConfigWriteFunc *config_write);
-
 void pci_register_bar(PCIDevice *pci_dev, int region_num,
                       uint8_t attr, MemoryRegion *memory);
 pcibus_t pci_get_bar_addr(PCIDevice *pci_dev, int region_num);
@@ -429,40 +464,7 @@ pci_quad_test_and_set_mask(uint8_t *config, uint64_t mask)
     return val & mask;
 }
 
-typedef int (*pci_qdev_initfn)(PCIDevice *dev);
-typedef struct {
-    DeviceInfo qdev;
-    pci_qdev_initfn init;
-    PCIUnregisterFunc *exit;
-    PCIConfigReadFunc *config_read;
-    PCIConfigWriteFunc *config_write;
-
-    uint16_t vendor_id;
-    uint16_t device_id;
-    uint8_t revision;
-    uint16_t class_id;
-    uint16_t subsystem_vendor_id;       /* only for header type = 0 */
-    uint16_t subsystem_id;              /* only for header type = 0 */
-
-    /*
-     * pci-to-pci bridge or normal device.
-     * This doesn't mean pci host switch.
-     * When card bus bridge is supported, this would be enhanced.
-     */
-    int is_bridge;
-
-    /* pcie stuff */
-    int is_express;   /* is this device pci express? */
-
-    /* device isn't hot-pluggable */
-    int no_hotplug;
-
-    /* rom bar */
-    const char *romfile;
-} PCIDeviceInfo;
-
-void pci_qdev_register(PCIDeviceInfo *info);
-void pci_qdev_register_many(PCIDeviceInfo *info);
+void pci_qdev_register(DeviceInfo *info);
 
 PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool multifunction,
                                     const char *name);
diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
index 650d165..1ed4339 100644
--- a/hw/pci_bridge.c
+++ b/hw/pci_bridge.c
@@ -294,7 +294,7 @@ void pci_bridge_reset_reg(PCIDevice *dev)
 /* default reset function for PCI-to-PCI bridge */
 void pci_bridge_reset(DeviceState *qdev)
 {
-    PCIDevice *dev = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *dev = PCI_DEVICE(qdev);
     pci_bridge_reset_reg(dev);
 }
 
diff --git a/hw/pcie.c b/hw/pcie.c
index 5c9eb2f..7c92f19 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -203,7 +203,7 @@ static void pcie_cap_slot_event(PCIDevice *dev, PCIExpressHotPlugEvent event)
 static int pcie_cap_slot_hotplug(DeviceState *qdev,
                                  PCIDevice *pci_dev, PCIHotplugState state)
 {
-    PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *d = PCI_DEVICE(qdev);
     uint8_t *exp_cap = d->config + d->exp.exp_cap;
     uint16_t sltsta = pci_get_word(exp_cap + PCI_EXP_SLTSTA);
 
diff --git a/hw/pcnet-pci.c b/hw/pcnet-pci.c
index 4e164da..be3bd79 100644
--- a/hw/pcnet-pci.c
+++ b/hw/pcnet-pci.c
@@ -348,21 +348,30 @@ static void pci_reset(DeviceState *dev)
     pcnet_h_reset(&d->state);
 }
 
-static PCIDeviceInfo pcnet_info = {
-    .qdev.name  = "pcnet",
-    .qdev.size  = sizeof(PCIPCNetState),
-    .qdev.reset = pci_reset,
-    .qdev.vmsd  = &vmstate_pci_pcnet,
-    .init       = pci_pcnet_init,
-    .exit       = pci_pcnet_uninit,
-    .vendor_id  = PCI_VENDOR_ID_AMD,
-    .device_id  = PCI_DEVICE_ID_AMD_LANCE,
-    .revision   = 0x10,
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_NIC_PROPERTIES(PCIPCNetState, state.conf),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property pcnet_properties[] = {
+    DEFINE_NIC_PROPERTIES(PCIPCNetState, state.conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pcnet_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_pcnet_init;
+    k->exit = pci_pcnet_uninit;
+    k->vendor_id = PCI_VENDOR_ID_AMD;
+    k->device_id = PCI_DEVICE_ID_AMD_LANCE;
+    k->revision = 0x10;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo pcnet_info = {
+    .name = "pcnet",
+    .size = sizeof(PCIPCNetState),
+    .reset = pci_reset,
+    .vmsd = &vmstate_pci_pcnet,
+    .props = pcnet_properties,
+    .class_init = pcnet_class_init,
 };
 
 static void pci_pcnet_register_devices(void)
diff --git a/hw/piix4.c b/hw/piix4.c
index 130dfd1..88be535 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -102,18 +102,24 @@ int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
     return d->devfn;
 }
 
-static PCIDeviceInfo piix4_info = {
-    .qdev.name    = "PIIX4",
-    .qdev.desc    = "ISA bridge",
-    .qdev.size    = sizeof(PIIX4State),
-    .qdev.vmsd    = &vmstate_piix4,
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = piix4_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    /* 82371AB/EB/MB PIIX4 PCI-to-ISA bridge */
-    .device_id    = PCI_DEVICE_ID_INTEL_82371AB_0,
-    .class_id     = PCI_CLASS_BRIDGE_ISA,
+static void piix4_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = piix4_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371AB_0;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+}
+
+static DeviceInfo piix4_info = {
+    .name = "PIIX4",
+    .desc = "ISA bridge",
+    .size = sizeof(PIIX4State),
+    .vmsd = &vmstate_piix4,
+    .no_user = 1,
+    .class_init = piix4_class_init,
 };
 
 static void piix4_register(void)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 5cbeed5..787db4e 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -502,47 +502,68 @@ static int piix3_initfn(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo i440fx_info = {
-    .qdev.name    = "i440FX",
-    .qdev.desc    = "Host bridge",
-    .qdev.size    = sizeof(PCII440FXState),
-    .qdev.vmsd    = &vmstate_i440fx,
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = i440fx_initfn,
-    .config_write = i440fx_write_config,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82441,
-    .revision     = 0x02,
-    .class_id     = PCI_CLASS_BRIDGE_HOST,
+static void piix3_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug   = 1;
+    k->init         = piix3_initfn;
+    k->config_write = piix3_write_config;
+    k->vendor_id    = PCI_VENDOR_ID_INTEL;
+    k->device_id    = PCI_DEVICE_ID_INTEL_82371SB_0; // 82371SB PIIX3 PCI-to-ISA bridge (Step A1)
+    k->class_id     = PCI_CLASS_BRIDGE_ISA;
+}
+
+static DeviceInfo piix3_info = {
+    .name    = "PIIX3",
+    .desc    = "ISA bridge",
+    .size    = sizeof(PIIX3State),
+    .vmsd    = &vmstate_piix3,
+    .no_user = 1,
+    .class_init = piix3_class_init,
 };
 
-static PCIDeviceInfo piix3_info = {
-    .qdev.name    = "PIIX3",
-    .qdev.desc    = "ISA bridge",
-    .qdev.size    = sizeof(PIIX3State),
-    .qdev.vmsd    = &vmstate_piix3,
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = piix3_initfn,
-    .config_write = piix3_write_config,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371SB_0, // 82371SB PIIX3 PCI-to-ISA bridge (Step A1)
-    .class_id     = PCI_CLASS_BRIDGE_ISA,
+static void piix3_xen_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug   = 1;
+    k->init         = piix3_initfn;
+    k->config_write = piix3_write_config_xen;
+    k->vendor_id    = PCI_VENDOR_ID_INTEL;
+    k->device_id    = PCI_DEVICE_ID_INTEL_82371SB_0; // 82371SB PIIX3 PCI-to-ISA bridge (Step A1)
+    k->class_id     = PCI_CLASS_BRIDGE_ISA;
 };
 
-static PCIDeviceInfo piix3_xen_info = {
-    .qdev.name    = "PIIX3-xen",
-    .qdev.desc    = "ISA bridge",
-    .qdev.size    = sizeof(PIIX3State),
-    .qdev.vmsd    = &vmstate_piix3,
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = piix3_initfn,
-    .config_write = piix3_write_config_xen,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371SB_0, // 82371SB PIIX3 PCI-to-ISA bridge (Step A1)
-    .class_id     = PCI_CLASS_BRIDGE_ISA,
+static DeviceInfo piix3_xen_info = {
+    .name    = "PIIX3-xen",
+    .desc    = "ISA bridge",
+    .size    = sizeof(PIIX3State),
+    .vmsd    = &vmstate_piix3,
+    .no_user = 1,
+    .class_init = piix3_xen_class_init,
+};
+
+static void i440fx_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = i440fx_initfn;
+    k->config_write = i440fx_write_config;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82441;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo i440fx_info = {
+    .name = "i440FX",
+    .desc = "Host bridge",
+    .size = sizeof(PCII440FXState),
+    .vmsd = &vmstate_i440fx,
+    .no_user = 1,
+    .class_init = i440fx_class_init,
 };
 
 static SysBusDeviceInfo i440fx_pcihost_info = {
diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c
index 26de007..b38840e 100644
--- a/hw/ppc4xx_pci.c
+++ b/hw/ppc4xx_pci.c
@@ -366,13 +366,20 @@ static int ppc4xx_pcihost_initfn(SysBusDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo ppc4xx_host_bridge_info = {
-    .qdev.name    = "ppc4xx-host-bridge",
-    .qdev.desc    = "Host bridge",
-    .qdev.size    = sizeof(PCIDevice),
-    .vendor_id    = PCI_VENDOR_ID_IBM,
-    .device_id    = PCI_DEVICE_ID_IBM_440GX,
-    .class_id     = PCI_CLASS_BRIDGE_OTHER,
+static void ppc4xx_host_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->vendor_id    = PCI_VENDOR_ID_IBM;
+    k->device_id    = PCI_DEVICE_ID_IBM_440GX;
+    k->class_id     = PCI_CLASS_BRIDGE_OTHER;
+}
+
+static DeviceInfo ppc4xx_host_bridge_info = {
+    .name    = "ppc4xx-host-bridge",
+    .desc    = "Host bridge",
+    .size    = sizeof(PCIDevice),
+    .class_init = ppc4xx_host_bridge_class_init,
 };
 
 static SysBusDeviceInfo ppc4xx_pcihost_info = {
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index b606206..bc783bf 100644
--- a/hw/ppce500_pci.c
+++ b/hw/ppce500_pci.c
@@ -339,13 +339,20 @@ static int e500_pcihost_initfn(SysBusDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo e500_host_bridge_info = {
-    .qdev.name    = "e500-host-bridge",
-    .qdev.desc    = "Host bridge",
-    .qdev.size    = sizeof(PCIDevice),
-    .vendor_id    = PCI_VENDOR_ID_FREESCALE,
-    .device_id    = PCI_DEVICE_ID_MPC8533E,
-    .class_id     = PCI_CLASS_PROCESSOR_POWERPC,
+static void e500_host_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->vendor_id = PCI_VENDOR_ID_FREESCALE;
+    k->device_id = PCI_DEVICE_ID_MPC8533E;
+    k->class_id = PCI_CLASS_PROCESSOR_POWERPC;
+}
+
+static DeviceInfo e500_host_bridge_info = {
+    .name = "e500-host-bridge",
+    .desc = "Host bridge",
+    .size = sizeof(PCIDevice),
+    .class_init = e500_host_bridge_class_init,
 };
 
 static SysBusDeviceInfo e500_pcihost_info = {
diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index 4961eed..4ff1049 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -134,21 +134,24 @@ static const VMStateDescription vmstate_raven = {
     },
 };
 
-static PCIDeviceInfo raven_info = {
-    .qdev.name = "raven",
-    .qdev.desc = "PReP Host Bridge - Motorola Raven",
-    .qdev.size = sizeof(RavenPCIState),
-    .qdev.vmsd = &vmstate_raven,
-    .qdev.no_user = 1,
-    .no_hotplug = 1,
-    .init = raven_init,
-    .vendor_id = PCI_VENDOR_ID_MOTOROLA,
-    .device_id = PCI_DEVICE_ID_MOTOROLA_RAVEN,
-    .revision = 0x00,
-    .class_id = PCI_CLASS_BRIDGE_HOST,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_END_OF_LIST()
-    },
+static void raven_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = raven_init;
+    k->vendor_id = PCI_VENDOR_ID_MOTOROLA;
+    k->device_id = PCI_DEVICE_ID_MOTOROLA_RAVEN;
+    k->revision = 0x00;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo raven_info = {
+    .name = "raven",
+    .desc = "PReP Host Bridge - Motorola Raven",
+    .size = sizeof(RavenPCIState),
+    .vmsd = &vmstate_raven,
+    .no_user = 1,
+    .class_init = raven_class_init,
 };
 
 static SysBusDeviceInfo raven_pcihost_info = {
diff --git a/hw/qdev.c b/hw/qdev.c
index 81996bb..a8c24de 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -119,6 +119,7 @@ bool qdev_exists(const char *name)
 {
     return !!qdev_find_info(NULL, name);
 }
+
 static void qdev_property_add_legacy(DeviceState *dev, Property *prop,
                                      Error **errp);
 
diff --git a/hw/qxl.c b/hw/qxl.c
index 2a716bf..7aa7d19 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1827,32 +1827,46 @@ static Property qxl_properties[] = {
         DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo qxl_primary_info = {
-    .qdev.name    = "qxl-vga",
-    .qdev.desc    = "Spice QXL GPU (primary, vga compatible)",
-    .qdev.size    = sizeof(PCIQXLDevice),
-    .qdev.reset   = qxl_reset_handler,
-    .qdev.vmsd    = &qxl_vmstate,
-    .no_hotplug   = 1,
-    .init         = qxl_init_primary,
-    .romfile      = "vgabios-qxl.bin",
-    .vendor_id    = REDHAT_PCI_VENDOR_ID,
-    .device_id    = QXL_DEVICE_ID_STABLE,
-    .class_id     = PCI_CLASS_DISPLAY_VGA,
-    .qdev.props   = qxl_properties,
+static void qxl_primary_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = qxl_init_primary;
+    k->romfile = "vgabios-qxl.bin";
+    k->vendor_id = REDHAT_PCI_VENDOR_ID;
+    k->device_id = QXL_DEVICE_ID_STABLE;
+    k->class_id = PCI_CLASS_DISPLAY_VGA;
+}
+
+static DeviceInfo qxl_primary_info = {
+    .name = "qxl-vga",
+    .desc = "Spice QXL GPU (primary, vga compatible)",
+    .size = sizeof(PCIQXLDevice),
+    .reset = qxl_reset_handler,
+    .vmsd = &qxl_vmstate,
+    .props = qxl_properties,
+    .class_init = qxl_primary_class_init,
 };
 
-static PCIDeviceInfo qxl_secondary_info = {
-    .qdev.name    = "qxl",
-    .qdev.desc    = "Spice QXL GPU (secondary)",
-    .qdev.size    = sizeof(PCIQXLDevice),
-    .qdev.reset   = qxl_reset_handler,
-    .qdev.vmsd    = &qxl_vmstate,
-    .init         = qxl_init_secondary,
-    .vendor_id    = REDHAT_PCI_VENDOR_ID,
-    .device_id    = QXL_DEVICE_ID_STABLE,
-    .class_id     = PCI_CLASS_DISPLAY_OTHER,
-    .qdev.props   = qxl_properties,
+static void qxl_secondary_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = qxl_init_secondary;
+    k->vendor_id = REDHAT_PCI_VENDOR_ID;
+    k->device_id = QXL_DEVICE_ID_STABLE;
+    k->class_id = PCI_CLASS_DISPLAY_OTHER;
+}
+
+static DeviceInfo qxl_secondary_info = {
+    .name = "qxl",
+    .desc = "Spice QXL GPU (secondary)",
+    .size = sizeof(PCIQXLDevice),
+    .reset = qxl_reset_handler,
+    .vmsd = &qxl_vmstate,
+    .props = qxl_properties,
+    .class_init = qxl_secondary_class_init,
 };
 
 static void qxl_register(void)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 2b55c7f..15dec9b 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -3494,22 +3494,31 @@ static int pci_rtl8139_init(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo rtl8139_info = {
-    .qdev.name  = "rtl8139",
-    .qdev.size  = sizeof(RTL8139State),
-    .qdev.reset = rtl8139_reset,
-    .qdev.vmsd  = &vmstate_rtl8139,
-    .init       = pci_rtl8139_init,
-    .exit       = pci_rtl8139_uninit,
-    .romfile    = "pxe-rtl8139.rom",
-    .vendor_id  = PCI_VENDOR_ID_REALTEK,
-    .device_id  = PCI_DEVICE_ID_REALTEK_8139,
-    .revision   = RTL8139_PCI_REVID, /* >=0x20 is for 8139C+ */
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_NIC_PROPERTIES(RTL8139State, conf),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property rtl8139_properties[] = {
+    DEFINE_NIC_PROPERTIES(RTL8139State, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void rtl8139_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_rtl8139_init;
+    k->exit = pci_rtl8139_uninit;
+    k->romfile = "pxe-rtl8139.rom";
+    k->vendor_id = PCI_VENDOR_ID_REALTEK;
+    k->device_id = PCI_DEVICE_ID_REALTEK_8139;
+    k->revision = RTL8139_PCI_REVID; /* >=0x20 is for 8139C+ */
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo rtl8139_info = {
+    .name = "rtl8139",
+    .size = sizeof(RTL8139State),
+    .reset = rtl8139_reset,
+    .vmsd = &vmstate_rtl8139,
+    .props = rtl8139_properties,
+    .class_init = rtl8139_class_init,
 };
 
 static void rtl8139_register_devices(void)
diff --git a/hw/sh_pci.c b/hw/sh_pci.c
index d4d028d..baeab9e 100644
--- a/hw/sh_pci.c
+++ b/hw/sh_pci.c
@@ -147,12 +147,19 @@ static int sh_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo sh_pci_host_info = {
-    .qdev.name = "sh_pci_host",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = sh_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_HITACHI,
-    .device_id = PCI_DEVICE_ID_HITACHI_SH7751R,
+static void sh_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = sh_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_HITACHI;
+    k->device_id = PCI_DEVICE_ID_HITACHI_SH7751R;
+}
+
+static DeviceInfo sh_pci_host_info = {
+    .name = "sh_pci_host",
+    .size = sizeof(PCIDevice),
+    .class_init = sh_pci_host_class_init,
 };
 
 static void sh_pci_register_devices(void)
diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index 2c95faa..8a39f8f 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -214,10 +214,17 @@ static int spapr_main_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo spapr_main_pci_host_info = {
-    .qdev.name = "spapr-pci-host-bridge",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = spapr_main_pci_host_init,
+static void spapr_main_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = spapr_main_pci_host_init;
+}
+
+static DeviceInfo spapr_main_pci_host_info = {
+    .name = "spapr-pci-host-bridge",
+    .size = sizeof(PCIDevice),
+    .class_init = spapr_main_pci_host_class_init,
 };
 
 static void spapr_register_devices(void)
diff --git a/hw/sun4u.c b/hw/sun4u.c
index 2dc3d04..6d9fdf6 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -562,14 +562,21 @@ pci_ebus_init1(PCIDevice *pci_dev)
     return 0;
 }
 
-static PCIDeviceInfo ebus_info = {
-    .qdev.name = "ebus",
-    .qdev.size = sizeof(EbusState),
-    .init = pci_ebus_init1,
-    .vendor_id = PCI_VENDOR_ID_SUN,
-    .device_id = PCI_DEVICE_ID_SUN_EBUS,
-    .revision = 0x01,
-    .class_id = PCI_CLASS_BRIDGE_OTHER,
+static void ebus_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_ebus_init1;
+    k->vendor_id = PCI_VENDOR_ID_SUN;
+    k->device_id = PCI_DEVICE_ID_SUN_EBUS;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_BRIDGE_OTHER;
+}
+
+static DeviceInfo ebus_info = {
+    .name = "ebus",
+    .size = sizeof(EbusState),
+    .class_init = ebus_class_init,
 };
 
 static void pci_ebus_register(void)
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index 6a10013..6a148e0 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -339,44 +339,72 @@ static int unin_internal_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo unin_main_pci_host_info = {
-    .qdev.name = "uni-north-pci",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = unin_main_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .device_id = PCI_DEVICE_ID_APPLE_UNI_N_PCI,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void unin_main_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = unin_main_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_UNI_N_PCI;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo unin_main_pci_host_info = {
+    .name = "uni-north-pci",
+    .size = sizeof(PCIDevice),
+    .class_init = unin_main_pci_host_class_init,
 };
 
-static PCIDeviceInfo u3_agp_pci_host_info = {
-    .qdev.name = "u3-agp",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = u3_agp_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .device_id = PCI_DEVICE_ID_APPLE_U3_AGP,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void u3_agp_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = u3_agp_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_U3_AGP;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo u3_agp_pci_host_info = {
+    .name = "u3-agp",
+    .size = sizeof(PCIDevice),
+    .class_init = u3_agp_pci_host_class_init,
 };
 
-static PCIDeviceInfo unin_agp_pci_host_info = {
-    .qdev.name = "uni-north-agp",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = unin_agp_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .device_id = PCI_DEVICE_ID_APPLE_UNI_N_AGP,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void unin_agp_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = unin_agp_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_UNI_N_AGP;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo unin_agp_pci_host_info = {
+    .name = "uni-north-agp",
+    .size = sizeof(PCIDevice),
+    .class_init = unin_agp_pci_host_class_init,
 };
 
-static PCIDeviceInfo unin_internal_pci_host_info = {
-    .qdev.name = "uni-north-internal-pci",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = unin_internal_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .device_id = PCI_DEVICE_ID_APPLE_UNI_N_I_PCI,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void unin_internal_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = unin_internal_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_UNI_N_I_PCI;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo unin_internal_pci_host_info = {
+    .name = "uni-north-internal-pci",
+    .size = sizeof(PCIDevice),
+    .class_init = unin_internal_pci_host_class_init,
 };
 
 static SysBusDeviceInfo sysbus_unin_pci_host_info = {
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index 63fc3c7..8baff1d 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -2263,28 +2263,42 @@ static Property ehci_properties[] = {
     DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo ehci_info = {
-    .qdev.name    = "usb-ehci",
-    .qdev.size    = sizeof(EHCIState),
-    .qdev.vmsd    = &vmstate_ehci,
-    .init         = usb_ehci_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801D, /* ich4 */
-    .revision     = 0x10,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = ehci_properties,
+static void ehci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_ehci_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801D; /* ich4 */
+    k->revision = 0x10;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ehci_info = {
+    .name = "usb-ehci",
+    .size = sizeof(EHCIState),
+    .vmsd = &vmstate_ehci,
+    .props = ehci_properties,
+    .class_init = ehci_class_init,
 };
 
-static PCIDeviceInfo ich9_ehci_info = {
-    .qdev.name    = "ich9-usb-ehci1",
-    .qdev.size    = sizeof(EHCIState),
-    .qdev.vmsd    = &vmstate_ehci,
-    .init         = usb_ehci_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801I_EHCI1,
-    .revision     = 0x03,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = ehci_properties,
+static void ich9_ehci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_ehci_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801I_EHCI1;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ich9_ehci_info = {
+    .name = "ich9-usb-ehci1",
+    .size = sizeof(EHCIState),
+    .vmsd = &vmstate_ehci,
+    .props = ehci_properties,
+    .class_init = ich9_ehci_class_init,
 };
 
 static int usb_ehci_initfn(PCIDevice *dev)
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index 2df6a6e..b9b37d5 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -1836,20 +1836,29 @@ static int ohci_init_pxa(SysBusDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo ohci_pci_info = {
-    .qdev.name    = "pci-ohci",
-    .qdev.desc    = "Apple USB Controller",
-    .qdev.size    = sizeof(OHCIPCIState),
-    .init         = usb_ohci_initfn_pci,
-    .vendor_id    = PCI_VENDOR_ID_APPLE,
-    .device_id    = PCI_DEVICE_ID_APPLE_IPID_USB,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = (Property[]) {
-        DEFINE_PROP_STRING("masterbus", OHCIPCIState, masterbus),
-        DEFINE_PROP_UINT32("num-ports", OHCIPCIState, num_ports, 3),
-        DEFINE_PROP_UINT32("firstport", OHCIPCIState, firstport, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    },
+static Property ohci_pci_properties[] = {
+    DEFINE_PROP_STRING("masterbus", OHCIPCIState, masterbus),
+    DEFINE_PROP_UINT32("num-ports", OHCIPCIState, num_ports, 3),
+    DEFINE_PROP_UINT32("firstport", OHCIPCIState, firstport, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ohci_pci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_ohci_initfn_pci;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_IPID_USB;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ohci_pci_info = {
+    .name = "pci-ohci",
+    .desc = "Apple USB Controller",
+    .size = sizeof(OHCIPCIState),
+    .props = ohci_pci_properties,
+    .class_init = ohci_pci_class_init,
 };
 
 static SysBusDeviceInfo ohci_sysbus_info = {
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 1821063..e20d7c4 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1192,79 +1192,121 @@ static Property uhci_properties[] = {
     DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo piix3_uhci_info = {
-        .qdev.name    = "piix3-usb-uhci",
-        .qdev.size    = sizeof(UHCIState),
-        .qdev.vmsd    = &vmstate_uhci,
-        .init         = usb_uhci_common_initfn,
-        .exit         = usb_uhci_exit,
-        .vendor_id    = PCI_VENDOR_ID_INTEL,
-        .device_id    = PCI_DEVICE_ID_INTEL_82371SB_2,
-        .revision     = 0x01,
-        .class_id     = PCI_CLASS_SERIAL_USB,
-        .qdev.props   = uhci_properties,
+static void piix3_uhci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->exit = usb_uhci_exit;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371SB_2;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo piix3_uhci_info = {
+    .name = "piix3-usb-uhci",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = piix3_uhci_class_init,
 };
 
-static PCIDeviceInfo piix4_uhci_info = {
-        .qdev.name    = "piix4-usb-uhci",
-        .qdev.size    = sizeof(UHCIState),
-        .qdev.vmsd    = &vmstate_uhci,
-        .init         = usb_uhci_common_initfn,
-        .exit         = usb_uhci_exit,
-        .vendor_id    = PCI_VENDOR_ID_INTEL,
-        .device_id    = PCI_DEVICE_ID_INTEL_82371AB_2,
-        .revision     = 0x01,
-        .class_id     = PCI_CLASS_SERIAL_USB,
-        .qdev.props   = uhci_properties,
+static void piix4_uhci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->exit = usb_uhci_exit;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371AB_2;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo piix4_uhci_info = {
+    .name = "piix4-usb-uhci",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = piix4_uhci_class_init,
 };
 
-static PCIDeviceInfo vt82c686b_uhci_info = {
-    .qdev.name    = "vt82c686b-usb-uhci",
-    .qdev.size    = sizeof(UHCIState),
-    .qdev.vmsd    = &vmstate_uhci,
-    .init         = usb_uhci_vt82c686b_initfn,
-    .exit         = usb_uhci_exit,
-    .vendor_id    = PCI_VENDOR_ID_VIA,
-    .device_id    = PCI_DEVICE_ID_VIA_UHCI,
-    .revision     = 0x01,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = uhci_properties,
+static void vt82c686b_uhci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_vt82c686b_initfn;
+    k->exit = usb_uhci_exit;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_UHCI;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo vt82c686b_uhci_info = {
+    .name = "vt82c686b-usb-uhci",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = vt82c686b_uhci_class_init,
 };
 
-static PCIDeviceInfo ich9_uhci1_info = {
-    .qdev.name    = "ich9-usb-uhci1",
-    .qdev.size    = sizeof(UHCIState),
-    .qdev.vmsd    = &vmstate_uhci,
-    .init         = usb_uhci_common_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801I_UHCI1,
-    .revision     = 0x03,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = uhci_properties,
+static void ich9_uhci1_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI1;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ich9_uhci1_info = {
+    .name = "ich9-usb-uhci1",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = ich9_uhci1_class_init,
 };
 
-static PCIDeviceInfo ich9_uhci2_info = {
-    .qdev.name    = "ich9-usb-uhci2",
-    .qdev.size    = sizeof(UHCIState),
-    .qdev.vmsd    = &vmstate_uhci,
-    .init         = usb_uhci_common_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801I_UHCI2,
-    .revision     = 0x03,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = uhci_properties,
+static void ich9_uhci2_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI2;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ich9_uhci2_info = {
+    .name = "ich9-usb-uhci2",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = ich9_uhci2_class_init,
 };
 
-static PCIDeviceInfo ich9_uhci3_info = {
-    .qdev.name    = "ich9-usb-uhci3",
-    .qdev.size    = sizeof(UHCIState),
-    .qdev.vmsd    = &vmstate_uhci,
-    .init         = usb_uhci_common_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801I_UHCI3,
-    .revision     = 0x03,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = uhci_properties,
+static void ich9_uhci3_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI3;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ich9_uhci3_info = {
+    .name = "ich9-usb-uhci3",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = ich9_uhci3_class_init,
 };
 
 static void uhci_register(void)
diff --git a/hw/usb-xhci.c b/hw/usb-xhci.c
index 95bf010..fba2de3 100644
--- a/hw/usb-xhci.c
+++ b/hw/usb-xhci.c
@@ -2724,19 +2724,26 @@ static const VMStateDescription vmstate_xhci = {
     .unmigratable = 1,
 };
 
-static PCIDeviceInfo xhci_info = {
-    .qdev.name    = "nec-usb-xhci",
-    .qdev.alias   = "xhci",
-    .qdev.size    = sizeof(XHCIState),
-    .qdev.vmsd    = &vmstate_xhci,
-    .init         = usb_xhci_initfn,
-    .vendor_id    = PCI_VENDOR_ID_NEC,
-    .device_id    = PCI_DEVICE_ID_NEC_UPD720200,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .revision     = 0x03,
-    .is_express   = 1,
-    .config_write = xhci_write_config,
-    .qdev.props   = (Property[]) {
+static void xhci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init         = usb_xhci_initfn;
+    k->vendor_id    = PCI_VENDOR_ID_NEC;
+    k->device_id    = PCI_DEVICE_ID_NEC_UPD720200;
+    k->class_id     = PCI_CLASS_SERIAL_USB;
+    k->revision     = 0x03;
+    k->is_express   = 1;
+    k->config_write = xhci_write_config;
+}
+
+static DeviceInfo xhci_info = {
+    .name    = "nec-usb-xhci",
+    .alias   = "xhci",
+    .size    = sizeof(XHCIState),
+    .vmsd    = &vmstate_xhci,
+    .class_init   = xhci_class_init,
+    .props   = (Property[]) {
         DEFINE_PROP_UINT32("msi", XHCIState, msi, 0),
         DEFINE_PROP_END_OF_LIST(),
     }
diff --git a/hw/versatile_pci.c b/hw/versatile_pci.c
index a285f7f..0eb7d32 100644
--- a/hw/versatile_pci.c
+++ b/hw/versatile_pci.c
@@ -109,14 +109,20 @@ static int versatile_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo versatile_pci_host_info = {
-    .qdev.name = "versatile_pci_host",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = versatile_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_XILINX,
-    /* Both boards have the same device ID.  Oh well.  */
-    .device_id = PCI_DEVICE_ID_XILINX_XC2VP30,
-    .class_id  = PCI_CLASS_PROCESSOR_CO,
+static void versatile_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = versatile_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_XILINX;
+    k->device_id = PCI_DEVICE_ID_XILINX_XC2VP30;
+    k->class_id = PCI_CLASS_PROCESSOR_CO;
+}
+
+static DeviceInfo versatile_pci_host_info = {
+    .name = "versatile_pci_host",
+    .size = sizeof(PCIDevice),
+    .class_init = versatile_pci_host_class_init,
 };
 
 static void versatile_pci_register_devices(void)
diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index a75dbf3..ef9f8a5 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -75,18 +75,23 @@ DeviceState *pci_vga_init(PCIBus *bus)
     return &pci_create_simple(bus, -1, "VGA")->qdev;
 }
 
-static PCIDeviceInfo vga_info = {
-    .qdev.name    = "VGA",
-    .qdev.size    = sizeof(PCIVGAState),
-    .qdev.vmsd    = &vmstate_vga_pci,
-    .no_hotplug   = 1,
-    .init         = pci_vga_initfn,
-    .romfile      = "vgabios-stdvga.bin",
+static void vga_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_vga_initfn;
+    k->romfile = "vgabios-stdvga.bin";
+    k->vendor_id = PCI_VENDOR_ID_QEMU;
+    k->device_id = PCI_DEVICE_ID_QEMU_VGA;
+    k->class_id = PCI_CLASS_DISPLAY_VGA;
+}
 
-    /* dummy VGA (same as Bochs ID) */
-    .vendor_id    = PCI_VENDOR_ID_QEMU,
-    .device_id    = PCI_DEVICE_ID_QEMU_VGA,
-    .class_id     = PCI_CLASS_DISPLAY_VGA,
+static DeviceInfo vga_info = {
+    .name = "VGA",
+    .size = sizeof(PCIVGAState),
+    .vmsd = &vmstate_vga_pci,
+    .class_init = vga_class_init,
 };
 
 static void vga_register(void)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 72b53af..126fb08 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -806,88 +806,124 @@ static int virtio_balloon_exit_pci(PCIDevice *pci_dev)
     return virtio_exit_pci(pci_dev);
 }
 
-static PCIDeviceInfo virtio_blk_info = {
-    .qdev.name = "virtio-blk-pci",
-    .qdev.alias = "virtio-blk",
-    .qdev.size = sizeof(VirtIOPCIProxy),
-    .init      = virtio_blk_init_pci,
-    .exit      = virtio_blk_exit_pci,
-    .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id = PCI_DEVICE_ID_VIRTIO_BLOCK,
-    .revision  = VIRTIO_PCI_ABI_VERSION,
-    .class_id  = PCI_CLASS_STORAGE_SCSI,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
-        DEFINE_BLOCK_PROPERTIES(VirtIOPCIProxy, block),
-        DEFINE_PROP_STRING("serial", VirtIOPCIProxy, block_serial),
-        DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-        DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
-        DEFINE_VIRTIO_BLK_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static Property virtio_blk_properties[] = {
+    DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
+    DEFINE_BLOCK_PROPERTIES(VirtIOPCIProxy, block),
+    DEFINE_PROP_STRING("serial", VirtIOPCIProxy, block_serial),
+    DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
+    DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
+    DEFINE_VIRTIO_BLK_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo virtio_net_info = {
-    .qdev.name  = "virtio-net-pci",
-    .qdev.alias = "virtio-net",
-    .qdev.size  = sizeof(VirtIOPCIProxy),
-    .init       = virtio_net_init_pci,
-    .exit       = virtio_net_exit_pci,
-    .romfile    = "pxe-virtio.rom",
-    .vendor_id  = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id  = PCI_DEVICE_ID_VIRTIO_NET,
-    .revision   = VIRTIO_PCI_ABI_VERSION,
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, false),
-        DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 3),
-        DEFINE_VIRTIO_NET_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_NIC_PROPERTIES(VirtIOPCIProxy, nic),
-        DEFINE_PROP_UINT32("x-txtimer", VirtIOPCIProxy, net.txtimer, TX_TIMER_INTERVAL),
-        DEFINE_PROP_INT32("x-txburst", VirtIOPCIProxy, net.txburst, TX_BURST),
-        DEFINE_PROP_STRING("tx", VirtIOPCIProxy, net.tx),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static void virtio_blk_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_blk_init_pci;
+    k->exit = virtio_blk_exit_pci;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = PCI_DEVICE_ID_VIRTIO_BLOCK;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = PCI_CLASS_STORAGE_SCSI;
+}
+
+static DeviceInfo virtio_blk_info = {
+    .name = "virtio-blk-pci",
+    .alias = "virtio-blk",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_blk_properties,
+    .reset = virtio_pci_reset,
+    .class_init = virtio_blk_class_init,
+};
+
+static Property virtio_net_properties[] = {
+    DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, false),
+    DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 3),
+    DEFINE_VIRTIO_NET_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_NIC_PROPERTIES(VirtIOPCIProxy, nic),
+    DEFINE_PROP_UINT32("x-txtimer", VirtIOPCIProxy, net.txtimer, TX_TIMER_INTERVAL),
+    DEFINE_PROP_INT32("x-txburst", VirtIOPCIProxy, net.txburst, TX_BURST),
+    DEFINE_PROP_STRING("tx", VirtIOPCIProxy, net.tx),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_net_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_net_init_pci;
+    k->exit = virtio_net_exit_pci;
+    k->romfile = "pxe-virtio.rom";
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = PCI_DEVICE_ID_VIRTIO_NET;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo virtio_net_info = {
+    .name = "virtio-net-pci",
+    .alias = "virtio-net",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_net_properties,
+    .reset = virtio_pci_reset,
+    .class_init = virtio_net_class_init,
 };
 
-static PCIDeviceInfo virtio_serial_info = {
-    .qdev.name = "virtio-serial-pci",
-    .qdev.alias = "virtio-serial",
-    .qdev.size = sizeof(VirtIOPCIProxy),
-    .init      = virtio_serial_init_pci,
-    .exit      = virtio_serial_exit_pci,
-    .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id = PCI_DEVICE_ID_VIRTIO_CONSOLE,
-    .revision  = VIRTIO_PCI_ABI_VERSION,
-    .class_id  = PCI_CLASS_COMMUNICATION_OTHER,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-        DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, DEV_NVECTORS_UNSPECIFIED),
-        DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
-        DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy, serial.max_virtserial_ports, 31),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static Property virtio_serial_properties[] = {
+    DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
+    DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, DEV_NVECTORS_UNSPECIFIED),
+    DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
+    DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy, serial.max_virtserial_ports, 31),
+    DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo virtio_balloon_info = {
-    .qdev.name = "virtio-balloon-pci",
-    .qdev.alias = "virtio-balloon",
-    .qdev.size = sizeof(VirtIOPCIProxy),
-    .init      = virtio_balloon_init_pci,
-    .exit      = virtio_balloon_exit_pci,
-    .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id = PCI_DEVICE_ID_VIRTIO_BALLOON,
-    .revision  = VIRTIO_PCI_ABI_VERSION,
-    .class_id  = PCI_CLASS_MEMORY_RAM,
-    .qdev.props = (Property[]) {
-        DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static void virtio_serial_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_serial_init_pci;
+    k->exit = virtio_serial_exit_pci;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = PCI_DEVICE_ID_VIRTIO_CONSOLE;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = PCI_CLASS_COMMUNICATION_OTHER;
+}
+
+static DeviceInfo virtio_serial_info = {
+    .name = "virtio-serial-pci",
+    .alias = "virtio-serial",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_serial_properties,
+    .reset = virtio_pci_reset,
+    .class_init = virtio_serial_class_init,
+};
+
+static Property virtio_balloon_properties[] = {
+    DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_balloon_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_balloon_init_pci;
+    k->exit = virtio_balloon_exit_pci;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = PCI_DEVICE_ID_VIRTIO_BALLOON;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = PCI_CLASS_MEMORY_RAM;
+}
+
+static DeviceInfo virtio_balloon_info = {
+    .name = "virtio-balloon-pci",
+    .alias = "virtio-balloon",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_balloon_properties,
+    .reset = virtio_pci_reset,
+    .class_init = virtio_balloon_class_init,
 };
 
 static void virtio_pci_register_devices(void)
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index b1885c3..e7bbf7c 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -1199,20 +1199,26 @@ static int pci_vmsvga_initfn(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo vmsvga_info = {
-    .qdev.name    = "vmware-svga",
-    .qdev.size    = sizeof(struct pci_vmsvga_state_s),
-    .qdev.vmsd    = &vmstate_vmware_vga,
-    .qdev.reset   = vmsvga_reset,
-    .no_hotplug   = 1,
-    .init         = pci_vmsvga_initfn,
-    .romfile      = "vgabios-vmware.bin",
-
-    .vendor_id    =  PCI_VENDOR_ID_VMWARE,
-    .device_id    = SVGA_PCI_DEVICE_ID,
-    .class_id     = PCI_CLASS_DISPLAY_VGA,
-    .subsystem_vendor_id = PCI_VENDOR_ID_VMWARE,
-    .subsystem_id = SVGA_PCI_DEVICE_ID,
+static void vmsvga_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_vmsvga_initfn;
+    k->romfile = "vgabios-vmware.bin";
+    k->vendor_id = PCI_VENDOR_ID_VMWARE;
+    k->device_id = SVGA_PCI_DEVICE_ID;
+    k->class_id = PCI_CLASS_DISPLAY_VGA;
+    k->subsystem_vendor_id = PCI_VENDOR_ID_VMWARE;
+    k->subsystem_id = SVGA_PCI_DEVICE_ID;
+}
+
+static DeviceInfo vmsvga_info = {
+    .name = "vmware-svga",
+    .size = sizeof(struct pci_vmsvga_state_s),
+    .vmsd = &vmstate_vmware_vga,
+    .reset = vmsvga_reset,
+    .class_init = vmsvga_class_init,
 };
 
 static void vmsvga_register(void)
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
index 7fb88a5..72be4fd 100644
--- a/hw/vt82c686.c
+++ b/hw/vt82c686.c
@@ -346,15 +346,22 @@ void vt82c686b_ac97_init(PCIBus *bus, int devfn)
     qdev_init_nofail(&dev->qdev);
 }
 
-static PCIDeviceInfo via_ac97_info = {
-    .qdev.name          = "VT82C686B_AC97",
-    .qdev.desc          = "AC97",
-    .qdev.size          = sizeof(VT686AC97State),
-    .init               = vt82c686b_ac97_initfn,
-    .vendor_id          = PCI_VENDOR_ID_VIA,
-    .device_id          = PCI_DEVICE_ID_VIA_AC97,
-    .revision           = 0x50,
-    .class_id           = PCI_CLASS_MULTIMEDIA_AUDIO,
+static void via_ac97_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_ac97_initfn;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_AC97;
+    k->revision = 0x50;
+    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
+}
+
+static DeviceInfo via_ac97_info = {
+    .name = "VT82C686B_AC97",
+    .desc = "AC97",
+    .size = sizeof(VT686AC97State),
+    .class_init = via_ac97_class_init,
 };
 
 static void vt82c686b_ac97_register(void)
@@ -385,15 +392,22 @@ void vt82c686b_mc97_init(PCIBus *bus, int devfn)
     qdev_init_nofail(&dev->qdev);
 }
 
-static PCIDeviceInfo via_mc97_info = {
-    .qdev.name          = "VT82C686B_MC97",
-    .qdev.desc          = "MC97",
-    .qdev.size          = sizeof(VT686MC97State),
-    .init               = vt82c686b_mc97_initfn,
-    .vendor_id          = PCI_VENDOR_ID_VIA,
-    .device_id          = PCI_DEVICE_ID_VIA_MC97,
-    .class_id           = PCI_CLASS_COMMUNICATION_OTHER,
-    .revision           = 0x30,
+static void via_mc97_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_mc97_initfn;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_MC97;
+    k->class_id = PCI_CLASS_COMMUNICATION_OTHER;
+    k->revision = 0x30;
+}
+
+static DeviceInfo via_mc97_info = {
+    .name = "VT82C686B_MC97",
+    .desc = "MC97",
+    .size = sizeof(VT686MC97State),
+    .class_init = via_mc97_class_init,
 };
 
 static void vt82c686b_mc97_register(void)
@@ -451,21 +465,30 @@ i2c_bus *vt82c686b_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
     return s->smb.smbus;
 }
 
-static PCIDeviceInfo via_pm_info = {
-    .qdev.name          = "VT82C686B_PM",
-    .qdev.desc          = "PM",
-    .qdev.size          = sizeof(VT686PMState),
-    .qdev.vmsd          = &vmstate_acpi,
-    .init               = vt82c686b_pm_initfn,
-    .config_write       = pm_write_config,
-    .vendor_id          = PCI_VENDOR_ID_VIA,
-    .device_id          = PCI_DEVICE_ID_VIA_ACPI,
-    .class_id           = PCI_CLASS_BRIDGE_OTHER,
-    .revision           = 0x40,
-    .qdev.props         = (Property[]) {
-        DEFINE_PROP_UINT32("smb_io_base", VT686PMState, smb_io_base, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property via_pm_properties[] = {
+    DEFINE_PROP_UINT32("smb_io_base", VT686PMState, smb_io_base, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void via_pm_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_pm_initfn;
+    k->config_write = pm_write_config;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_ACPI;
+    k->class_id = PCI_CLASS_BRIDGE_OTHER;
+    k->revision = 0x40;
+}
+
+static DeviceInfo via_pm_info = {
+    .name = "VT82C686B_PM",
+    .desc = "PM",
+    .size = sizeof(VT686PMState),
+    .vmsd = &vmstate_acpi,
+    .props = via_pm_properties,
+    .class_init = via_pm_class_init,
 };
 
 static void vt82c686b_pm_register(void)
@@ -519,18 +542,25 @@ ISABus *vt82c686b_init(PCIBus *bus, int devfn)
     return DO_UPCAST(ISABus, qbus, qdev_get_child_bus(&d->qdev, "isa.0"));
 }
 
-static PCIDeviceInfo via_info = {
-    .qdev.name    = "VT82C686B",
-    .qdev.desc    = "ISA bridge",
-    .qdev.size    = sizeof(VT82C686BState),
-    .qdev.vmsd    = &vmstate_via,
-    .qdev.no_user = 1,
-    .init         = vt82c686b_initfn,
-    .config_write = vt82c686b_write_config,
-    .vendor_id    = PCI_VENDOR_ID_VIA,
-    .device_id    = PCI_DEVICE_ID_VIA_ISA_BRIDGE,
-    .class_id     = PCI_CLASS_BRIDGE_ISA,
-    .revision     = 0x40,
+static void via_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_initfn;
+    k->config_write = vt82c686b_write_config;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_ISA_BRIDGE;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+    k->revision = 0x40;
+}
+
+static DeviceInfo via_info = {
+    .name = "VT82C686B",
+    .desc = "ISA bridge",
+    .size = sizeof(VT82C686BState),
+    .vmsd = &vmstate_via,
+    .no_user = 1,
+    .class_init = via_class_init,
 };
 
 static void vt82c686b_register(void)
diff --git a/hw/wdt_i6300esb.c b/hw/wdt_i6300esb.c
index 20d8673..a6ceff8 100644
--- a/hw/wdt_i6300esb.c
+++ b/hw/wdt_i6300esb.c
@@ -143,7 +143,7 @@ static void i6300esb_disable_timer(I6300State *d)
 
 static void i6300esb_reset(DeviceState *dev)
 {
-    PCIDevice *pdev = DO_UPCAST(PCIDevice, qdev, dev);
+    PCIDevice *pdev = PCI_DEVICE(dev);
     I6300State *d = DO_UPCAST(I6300State, dev, pdev);
 
     i6300esb_debug("I6300State = %p\n", d);
@@ -425,18 +425,25 @@ static WatchdogTimerModel model = {
     .wdt_description = "Intel 6300ESB",
 };
 
-static PCIDeviceInfo i6300esb_info = {
-    .qdev.name    = "i6300esb",
-    .qdev.size    = sizeof(I6300State),
-    .qdev.vmsd    = &vmstate_i6300esb,
-    .qdev.reset   = i6300esb_reset,
-    .config_read  = i6300esb_config_read,
-    .config_write = i6300esb_config_write,
-    .init         = i6300esb_init,
-    .exit         = i6300esb_exit,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_ESB_9,
-    .class_id     = PCI_CLASS_SYSTEM_OTHER,
+static void i6300esb_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->config_read = i6300esb_config_read;
+    k->config_write = i6300esb_config_write;
+    k->init = i6300esb_init;
+    k->exit = i6300esb_exit;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_ESB_9;
+    k->class_id = PCI_CLASS_SYSTEM_OTHER;
+}
+
+static DeviceInfo i6300esb_info = {
+    .name = "i6300esb",
+    .size = sizeof(I6300State),
+    .vmsd = &vmstate_i6300esb,
+    .reset = i6300esb_reset,
+    .class_init = i6300esb_class_init,
 };
 
 static void i6300esb_register_devices(void)
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index e62eaef..40687fb 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -372,20 +372,26 @@ static void platform_reset(DeviceState *dev)
     platform_fixed_ioport_reset(s);
 }
 
-static PCIDeviceInfo xen_platform_info = {
-    .init = xen_platform_initfn,
-    .qdev.name = "xen-platform",
-    .qdev.desc = "XEN platform pci device",
-    .qdev.size = sizeof(PCIXenPlatformState),
-    .qdev.vmsd = &vmstate_xen_platform,
-    .qdev.reset = platform_reset,
-
-    .vendor_id    =  PCI_VENDOR_ID_XEN,
-    .device_id    = PCI_DEVICE_ID_XEN_PLATFORM,
-    .class_id     = PCI_CLASS_OTHERS << 8 | 0x80,
-    .subsystem_vendor_id = PCI_VENDOR_ID_XEN,
-    .subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM,
-    .revision = 1,
+static void xen_platform_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = xen_platform_initfn;
+    k->vendor_id = PCI_VENDOR_ID_XEN;
+    k->device_id = PCI_DEVICE_ID_XEN_PLATFORM;
+    k->class_id = PCI_CLASS_OTHERS << 8 | 0x80;
+    k->subsystem_vendor_id = PCI_VENDOR_ID_XEN;
+    k->subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM;
+    k->revision = 1;
+}
+
+static DeviceInfo xen_platform_info = {
+    .name = "xen-platform",
+    .desc = "XEN platform pci device",
+    .size = sizeof(PCIXenPlatformState),
+    .vmsd = &vmstate_xen_platform,
+    .reset = platform_reset,
+    .class_init = xen_platform_class_init,
 };
 
 static void xen_platform_register(void)
diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c
index d3c387d..6d625cb 100644
--- a/hw/xio3130_downstream.c
+++ b/hw/xio3130_downstream.c
@@ -47,7 +47,7 @@ static void xio3130_downstream_write_config(PCIDevice *d, uint32_t address,
 
 static void xio3130_downstream_reset(DeviceState *qdev)
 {
-    PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *d = PCI_DEVICE(qdev);
     msi_reset(d);
     pcie_cap_deverr_reset(d);
     pcie_cap_slot_reset(d);
@@ -167,31 +167,38 @@ static const VMStateDescription vmstate_xio3130_downstream = {
     }
 };
 
-static PCIDeviceInfo xio3130_downstream_info = {
-    .qdev.name = "xio3130-downstream",
-    .qdev.desc = "TI X3130 Downstream Port of PCI Express Switch",
-    .qdev.size = sizeof(PCIESlot),
-    .qdev.reset = xio3130_downstream_reset,
-    .qdev.vmsd = &vmstate_xio3130_downstream,
-
-    .is_express = 1,
-    .is_bridge = 1,
-    .config_write = xio3130_downstream_write_config,
-    .init = xio3130_downstream_initfn,
-    .exit = xio3130_downstream_exitfn,
-    .vendor_id = PCI_VENDOR_ID_TI,
-    .device_id = PCI_DEVICE_ID_TI_XIO3130D,
-    .revision = XIO3130_REVISION,
-
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
-        DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
-        DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
-        DEFINE_PROP_UINT16("aer_log_max", PCIESlot,
-                           port.br.dev.exp.aer_log.log_max,
-                           PCIE_AER_LOG_MAX_DEFAULT),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property xio3130_downstream_properties[] = {
+    DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
+    DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
+    DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
+    DEFINE_PROP_UINT16("aer_log_max", PCIESlot,
+    port.br.dev.exp.aer_log.log_max,
+    PCIE_AER_LOG_MAX_DEFAULT),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xio3130_downstream_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->is_express = 1;
+    k->is_bridge = 1;
+    k->config_write = xio3130_downstream_write_config;
+    k->init = xio3130_downstream_initfn;
+    k->exit = xio3130_downstream_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_TI;
+    k->device_id = PCI_DEVICE_ID_TI_XIO3130D;
+    k->revision = XIO3130_REVISION;
+}
+
+static DeviceInfo xio3130_downstream_info = {
+    .name = "xio3130-downstream",
+    .desc = "TI X3130 Downstream Port of PCI Express Switch",
+    .size = sizeof(PCIESlot),
+    .reset = xio3130_downstream_reset,
+    .vmsd = &vmstate_xio3130_downstream,
+    .props = xio3130_downstream_properties,
+    .class_init = xio3130_downstream_class_init,
 };
 
 static void xio3130_downstream_register(void)
diff --git a/hw/xio3130_upstream.c b/hw/xio3130_upstream.c
index 8283695..ec4c5e3 100644
--- a/hw/xio3130_upstream.c
+++ b/hw/xio3130_upstream.c
@@ -46,7 +46,7 @@ static void xio3130_upstream_write_config(PCIDevice *d, uint32_t address,
 
 static void xio3130_upstream_reset(DeviceState *qdev)
 {
-    PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *d = PCI_DEVICE(qdev);
     msi_reset(d);
     pci_bridge_reset(qdev);
     pcie_cap_deverr_reset(d);
@@ -144,28 +144,35 @@ static const VMStateDescription vmstate_xio3130_upstream = {
     }
 };
 
-static PCIDeviceInfo xio3130_upstream_info = {
-    .qdev.name = "x3130-upstream",
-    .qdev.desc = "TI X3130 Upstream Port of PCI Express Switch",
-    .qdev.size = sizeof(PCIEPort),
-    .qdev.reset = xio3130_upstream_reset,
-    .qdev.vmsd = &vmstate_xio3130_upstream,
-
-    .is_express = 1,
-    .is_bridge = 1,
-    .config_write = xio3130_upstream_write_config,
-    .init = xio3130_upstream_initfn,
-    .exit = xio3130_upstream_exitfn,
-    .vendor_id = PCI_VENDOR_ID_TI,
-    .device_id = PCI_DEVICE_ID_TI_XIO3130U,
-    .revision = XIO3130_REVISION,
-
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_UINT8("port", PCIEPort, port, 0),
-        DEFINE_PROP_UINT16("aer_log_max", PCIEPort, br.dev.exp.aer_log.log_max,
-                           PCIE_AER_LOG_MAX_DEFAULT),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property xio3130_upstream_properties[] = {
+    DEFINE_PROP_UINT8("port", PCIEPort, port, 0),
+    DEFINE_PROP_UINT16("aer_log_max", PCIEPort, br.dev.exp.aer_log.log_max,
+    PCIE_AER_LOG_MAX_DEFAULT),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xio3130_upstream_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->is_express = 1;
+    k->is_bridge = 1;
+    k->config_write = xio3130_upstream_write_config;
+    k->init = xio3130_upstream_initfn;
+    k->exit = xio3130_upstream_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_TI;
+    k->device_id = PCI_DEVICE_ID_TI_XIO3130U;
+    k->revision = XIO3130_REVISION;
+}
+
+static DeviceInfo xio3130_upstream_info = {
+    .name = "x3130-upstream",
+    .desc = "TI X3130 Upstream Port of PCI Express Switch",
+    .size = sizeof(PCIEPort),
+    .reset = xio3130_upstream_reset,
+    .vmsd = &vmstate_xio3130_upstream,
+    .props = xio3130_upstream_properties,
+    .class_init = xio3130_upstream_class_init,
 };
 
 static void xio3130_upstream_register(void)
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 19:35:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 19:35:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpm8c-0003ox-Hr; Tue, 24 Jan 2012 19:34:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <aliguori@us.ibm.com>) id 1Rpm8a-0003oj-D5
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 19:34:37 +0000
Received: from [85.158.138.51:7395] by server-3.bemta-3.messagelabs.com id
	A8/68-26314-BC70F1F4; Tue, 24 Jan 2012 19:34:35 +0000
X-Env-Sender: aliguori@us.ibm.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327433672!10511820!1
X-Originating-IP: [32.97.110.158]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMzIuOTcuMTEwLjE1OCA9PiA2OTc2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3258 invoked from network); 24 Jan 2012 19:34:33 -0000
Received: from e37.co.us.ibm.com (HELO e37.co.us.ibm.com) (32.97.110.158)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 19:34:33 -0000
Received: from /spool/local
	by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only!
	Violators will be prosecuted
	for <xen-devel@lists.xensource.com> from <aliguori@us.ibm.com>;
	Tue, 24 Jan 2012 12:34:30 -0700
Received: from d03dlp02.boulder.ibm.com (9.17.202.178)
	by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway:
	Authorized Use Only! Violators will be prosecuted; 
	Tue, 24 Jan 2012 12:34:01 -0700
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com
	[9.17.195.228])
	by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id BE8FA3E4004A
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 12:33:59 -0700 (MST)
Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167])
	by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	q0OJXtim112120
	for <xen-devel@lists.xensource.com>; Tue, 24 Jan 2012 12:33:55 -0700
Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1])
	by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP
	id q0OJXs0j009869
	for <xen-devel@lists.xensource.com>; Tue, 24 Jan 2012 12:33:55 -0700
Received: from titi.austin.rr.com (sig-9-65-115-125.mts.ibm.com [9.65.115.125])
	by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id
	q0OJXNdi006821; Tue, 24 Jan 2012 12:33:52 -0700
From: Anthony Liguori <aliguori@us.ibm.com>
To: qemu-devel@nongnu.org
Date: Tue, 24 Jan 2012 13:33:18 -0600
Message-Id: <1327433600-7403-27-git-send-email-aliguori@us.ibm.com>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com>
References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com>
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12012419-7408-0000-0000-00000222E669
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>,
	xen-devel@lists.xensource.com, "Michael S. Tsirkin" <mst@redhat.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Alexander Graf <agraf@suse.de>, Blue Swirl <blauwirbel@gmail.com>,
	=?UTF-8?q?Andreas=20F=C3=A4rber?= <andreas.faerber@web.de>,
	qemu-ppc@nongnu.org, Paul Brook <paul@codesourcery.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: [Xen-devel] [PATCH 26/28] pci: convert to QEMU Object Model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 hw/9pfs/virtio-9p-device.c |   43 ++++++----
 hw/ac97.c                  |   39 +++++----
 hw/acpi_piix4.c            |   59 +++++++------
 hw/apb_pci.c               |   54 ++++++++-----
 hw/bonito.c                |   30 ++++---
 hw/cirrus_vga.c            |   33 +++++---
 hw/dec_pci.c               |   57 ++++++++-----
 hw/e1000.c                 |   43 ++++++----
 hw/eepro100.c              |  200 +++++++++++++++++++++++++++----------------
 hw/es1370.c                |   31 ++++---
 hw/grackle_pci.c           |   25 ++++--
 hw/gt64xxx.c               |   23 ++++--
 hw/i82378.c                |   31 ++++---
 hw/ide/cmd646.c            |   36 +++++---
 hw/ide/ich.c               |   31 ++++---
 hw/ide/piix.c              |   79 +++++++++++-------
 hw/ide/via.c               |   27 ++++--
 hw/intel-hda.c             |   56 ++++++++----
 hw/ioh3420.c               |   59 +++++++------
 hw/ivshmem.c               |   47 ++++++----
 hw/lsi53c895a.c            |   31 ++++---
 hw/macio.c                 |   19 +++--
 hw/ne2000.c                |   35 +++++---
 hw/pci.c                   |  123 ++++++++++++---------------
 hw/pci.h                   |   80 +++++++++---------
 hw/pci_bridge.c            |    2 +-
 hw/pcie.c                  |    2 +-
 hw/pcnet-pci.c             |   39 +++++----
 hw/piix4.c                 |   30 ++++---
 hw/piix_pci.c              |   95 +++++++++++++--------
 hw/ppc4xx_pci.c            |   21 +++--
 hw/ppce500_pci.c           |   21 +++--
 hw/prep_pci.c              |   33 ++++----
 hw/qdev.c                  |    1 +
 hw/qxl.c                   |   62 ++++++++-----
 hw/rtl8139.c               |   41 ++++++----
 hw/sh_pci.c                |   19 +++--
 hw/spapr_pci.c             |   15 +++-
 hw/sun4u.c                 |   23 ++++--
 hw/unin_pci.c              |   92 +++++++++++++-------
 hw/usb-ehci.c              |   54 ++++++++-----
 hw/usb-ohci.c              |   37 +++++---
 hw/usb-uhci.c              |  168 +++++++++++++++++++++++--------------
 hw/usb-xhci.c              |   33 +++++---
 hw/versatile_pci.c         |   22 +++--
 hw/vga-pci.c               |   27 ++++---
 hw/virtio-pci.c            |  188 ++++++++++++++++++++++++-----------------
 hw/vmware_vga.c            |   34 +++++---
 hw/vt82c686.c              |  120 ++++++++++++++++----------
 hw/wdt_i6300esb.c          |   33 +++++---
 hw/xen_platform.c          |   34 +++++---
 hw/xio3130_downstream.c    |   59 +++++++------
 hw/xio3130_upstream.c      |   53 +++++++-----
 53 files changed, 1599 insertions(+), 1050 deletions(-)

diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 1325f2f..aded048 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -163,23 +163,32 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
     return 0;
 }
 
-static PCIDeviceInfo virtio_9p_info = {
-    .qdev.name = "virtio-9p-pci",
-    .qdev.size = sizeof(VirtIOPCIProxy),
-    .init      = virtio_9p_init_pci,
-    .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id = 0x1009,
-    .revision  = VIRTIO_PCI_ABI_VERSION,
-    .class_id  = 0x2,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-        DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
-        DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_PROP_STRING("mount_tag", VirtIOPCIProxy, fsconf.tag),
-        DEFINE_PROP_STRING("fsdev", VirtIOPCIProxy, fsconf.fsdev_id),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static Property virtio_9p_properties[] = {
+    DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
+    DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
+    DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_PROP_STRING("mount_tag", VirtIOPCIProxy, fsconf.tag),
+    DEFINE_PROP_STRING("fsdev", VirtIOPCIProxy, fsconf.fsdev_id),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_9p_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_9p_init_pci;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = 0x1009;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = 0x2;
+}
+
+static DeviceInfo virtio_9p_info = {
+    .name = "virtio-9p-pci",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_9p_properties,
+    .class_init = virtio_9p_class_init,
+    .reset = virtio_pci_reset,
 };
 
 static void virtio_9p_register_devices(void)
diff --git a/hw/ac97.c b/hw/ac97.c
index 03be99b..33b85f5 100644
--- a/hw/ac97.c
+++ b/hw/ac97.c
@@ -1344,21 +1344,30 @@ int ac97_init (PCIBus *bus)
     return 0;
 }
 
-static PCIDeviceInfo ac97_info = {
-    .qdev.name    = "AC97",
-    .qdev.desc    = "Intel 82801AA AC97 Audio",
-    .qdev.size    = sizeof (AC97LinkState),
-    .qdev.vmsd    = &vmstate_ac97,
-    .init         = ac97_initfn,
-    .exit         = ac97_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801AA_5,
-    .revision     = 0x01,
-    .class_id     = PCI_CLASS_MULTIMEDIA_AUDIO,
-    .qdev.props   = (Property[]) {
-        DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property ac97_properties[] = {
+    DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ac97_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = ac97_initfn;
+    k->exit = ac97_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801AA_5;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
+}
+
+static DeviceInfo ac97_info = {
+    .name = "AC97",
+    .desc = "Intel 82801AA AC97 Audio",
+    .size = sizeof (AC97LinkState),
+    .vmsd = &vmstate_ac97,
+    .props = ac97_properties,
+    .class_init = ac97_class_init,
 };
 
 static void ac97_register (void)
diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
index 4d0b390..9058a7c 100644
--- a/hw/acpi_piix4.c
+++ b/hw/acpi_piix4.c
@@ -280,11 +280,11 @@ static void piix4_update_hotplug(PIIX4PMState *s)
     s->pci0_hotplug_enable = ~0;
 
     QTAILQ_FOREACH_SAFE(qdev, &bus->children, sibling, next) {
-        PCIDeviceInfo *info = container_of(qdev_get_info(qdev), PCIDeviceInfo, qdev);
-        PCIDevice *pdev = DO_UPCAST(PCIDevice, qdev, qdev);
+        PCIDevice *pdev = PCI_DEVICE(qdev);
+        PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pdev);
         int slot = PCI_SLOT(pdev->devfn);
 
-        if (info->no_hotplug) {
+        if (pc->no_hotplug) {
             s->pci0_hotplug_enable &= ~(1 << slot);
         }
     }
@@ -396,23 +396,32 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
     return s->smb.smbus;
 }
 
-static PCIDeviceInfo piix4_pm_info = {
-    .qdev.name          = "PIIX4_PM",
-    .qdev.desc          = "PM",
-    .qdev.size          = sizeof(PIIX4PMState),
-    .qdev.vmsd          = &vmstate_acpi,
-    .qdev.no_user       = 1,
-    .no_hotplug         = 1,
-    .init               = piix4_pm_initfn,
-    .config_write       = pm_write_config,
-    .vendor_id          = PCI_VENDOR_ID_INTEL,
-    .device_id          = PCI_DEVICE_ID_INTEL_82371AB_3,
-    .revision           = 0x03,
-    .class_id           = PCI_CLASS_BRIDGE_OTHER,
-    .qdev.props         = (Property[]) {
-        DEFINE_PROP_UINT32("smb_io_base", PIIX4PMState, smb_io_base, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property piix4_pm_properties[] = {
+    DEFINE_PROP_UINT32("smb_io_base", PIIX4PMState, smb_io_base, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void piix4_pm_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = piix4_pm_initfn;
+    k->config_write = pm_write_config;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371AB_3;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_BRIDGE_OTHER;
+}
+
+static DeviceInfo piix4_pm_info = {
+    .name = "PIIX4_PM",
+    .desc = "PM",
+    .size = sizeof(PIIX4PMState),
+    .vmsd = &vmstate_acpi,
+    .no_user = 1,
+    .props = piix4_pm_properties,
+    .class_init = piix4_pm_class_init,
 };
 
 static void piix4_pm_register(void)
@@ -485,14 +494,12 @@ static void pciej_write(void *opaque, uint32_t addr, uint32_t val)
 {
     BusState *bus = opaque;
     DeviceState *qdev, *next;
-    PCIDevice *dev;
-    PCIDeviceInfo *info;
     int slot = ffs(val) - 1;
 
     QTAILQ_FOREACH_SAFE(qdev, &bus->children, sibling, next) {
-        dev = DO_UPCAST(PCIDevice, qdev, qdev);
-        info = container_of(qdev_get_info(qdev), PCIDeviceInfo, qdev);
-        if (PCI_SLOT(dev->devfn) == slot && !info->no_hotplug) {
+        PCIDevice *dev = PCI_DEVICE(qdev);
+        PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
+        if (PCI_SLOT(dev->devfn) == slot && !pc->no_hotplug) {
             qdev_free(qdev);
         }
     }
@@ -553,7 +560,7 @@ static int piix4_device_hotplug(DeviceState *qdev, PCIDevice *dev,
 {
     int slot = PCI_SLOT(dev->devfn);
     PIIX4PMState *s = DO_UPCAST(PIIX4PMState, dev,
-                                DO_UPCAST(PCIDevice, qdev, qdev));
+                                PCI_DEVICE(qdev));
 
     /* Don't send event when device is enabled during qemu machine creation:
      * it is present on boot, no hotplug event is necessary. We do send an
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index 3a1b111..70cfc77 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -436,14 +436,21 @@ static int pbm_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo pbm_pci_host_info = {
-    .qdev.name = "pbm",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = pbm_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_SUN,
-    .device_id = PCI_DEVICE_ID_SUN_SABRE,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
-    .is_bridge = 1,
+static void pbm_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pbm_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_SUN;
+    k->device_id = PCI_DEVICE_ID_SUN_SABRE;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+    k->is_bridge = 1;
+}
+
+static DeviceInfo pbm_pci_host_info = {
+    .name = "pbm",
+    .size = sizeof(PCIDevice),
+    .class_init = pbm_pci_host_class_init,
 };
 
 static SysBusDeviceInfo pbm_host_info = {
@@ -453,18 +460,25 @@ static SysBusDeviceInfo pbm_host_info = {
     .init = pci_pbm_init_device,
 };
 
-static PCIDeviceInfo pbm_pci_bridge_info = {
-    .qdev.name = "pbm-bridge",
-    .qdev.size = sizeof(PCIBridge),
-    .qdev.vmsd = &vmstate_pci_device,
-    .qdev.reset = pci_bridge_reset,
-    .init = apb_pci_bridge_initfn,
-    .exit = pci_bridge_exitfn,
-    .vendor_id = PCI_VENDOR_ID_SUN,
-    .device_id = PCI_DEVICE_ID_SUN_SIMBA,
-    .revision = 0x11,
-    .config_write = pci_bridge_write_config,
-    .is_bridge = 1,
+static void pbm_pci_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = apb_pci_bridge_initfn;
+    k->exit = pci_bridge_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_SUN;
+    k->device_id = PCI_DEVICE_ID_SUN_SIMBA;
+    k->revision = 0x11;
+    k->config_write = pci_bridge_write_config;
+    k->is_bridge = 1;
+}
+
+static DeviceInfo pbm_pci_bridge_info = {
+    .name = "pbm-bridge",
+    .size = sizeof(PCIBridge),
+    .vmsd = &vmstate_pci_device,
+    .reset = pci_bridge_reset,
+    .class_init = pbm_pci_bridge_class_init,
 };
 
 static void pbm_register_devices(void)
diff --git a/hw/bonito.c b/hw/bonito.c
index f2c7837..23384ec 100644
--- a/hw/bonito.c
+++ b/hw/bonito.c
@@ -766,18 +766,24 @@ PCIBus *bonito_init(qemu_irq *pic)
     return b;
 }
 
-static PCIDeviceInfo bonito_info = {
-    .qdev.name    = "Bonito",
-    .qdev.desc    = "Host bridge",
-    .qdev.size    = sizeof(PCIBonitoState),
-    .qdev.vmsd    = &vmstate_bonito,
-    .qdev.no_user = 1,
-    .init         = bonito_initfn,
-    /*Bonito North Bridge, built on FPGA, VENDOR_ID/DEVICE_ID are "undefined"*/
-    .vendor_id    = 0xdf53,
-    .device_id    = 0x00d5,
-    .revision     = 0x01,
-    .class_id     = PCI_CLASS_BRIDGE_HOST,
+static void bonito_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = bonito_initfn;
+    k->vendor_id = 0xdf53;
+    k->device_id = 0x00d5;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo bonito_info = {
+    .name = "Bonito",
+    .desc = "Host bridge",
+    .size = sizeof(PCIBonitoState),
+    .vmsd = &vmstate_bonito,
+    .no_user = 1,
+    .class_init = bonito_class_init,
 };
 
 static SysBusDeviceInfo bonito_pcihost_info = {
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 1d0aadf..3fac2ee 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2935,8 +2935,8 @@ static int pci_cirrus_vga_initfn(PCIDevice *dev)
 {
      PCICirrusVGAState *d = DO_UPCAST(PCICirrusVGAState, dev, dev);
      CirrusVGAState *s = &d->cirrus_vga;
-     PCIDeviceInfo *info = DO_UPCAST(PCIDeviceInfo, qdev, qdev_get_info(&dev->qdev));
-     int16_t device_id = info->device_id;
+     PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
+     int16_t device_id = pc->device_id;
 
      /* setup VGA */
      vga_common_init(&s->vga, VGA_RAM_SIZE);
@@ -2970,17 +2970,24 @@ DeviceState *pci_cirrus_vga_init(PCIBus *bus)
     return &pci_create_simple(bus, -1, "cirrus-vga")->qdev;
 }
 
-static PCIDeviceInfo cirrus_vga_info = {
-    .qdev.name    = "cirrus-vga",
-    .qdev.desc    = "Cirrus CLGD 54xx VGA",
-    .qdev.size    = sizeof(PCICirrusVGAState),
-    .qdev.vmsd    = &vmstate_pci_cirrus_vga,
-    .no_hotplug   = 1,
-    .init         = pci_cirrus_vga_initfn,
-    .romfile      = VGABIOS_CIRRUS_FILENAME,
-    .vendor_id    = PCI_VENDOR_ID_CIRRUS,
-    .device_id    = CIRRUS_ID_CLGD5446,
-    .class_id     = PCI_CLASS_DISPLAY_VGA,
+static void cirrus_vga_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_cirrus_vga_initfn;
+    k->romfile = VGABIOS_CIRRUS_FILENAME;
+    k->vendor_id = PCI_VENDOR_ID_CIRRUS;
+    k->device_id = CIRRUS_ID_CLGD5446;
+    k->class_id = PCI_CLASS_DISPLAY_VGA;
+}
+
+static DeviceInfo cirrus_vga_info = {
+    .name = "cirrus-vga",
+    .desc = "Cirrus CLGD 54xx VGA",
+    .size = sizeof(PCICirrusVGAState),
+    .vmsd = &vmstate_pci_cirrus_vga,
+    .class_init = cirrus_vga_class_init,
 };
 
 static void cirrus_vga_register(void)
diff --git a/hw/dec_pci.c b/hw/dec_pci.c
index 08d4e06..7c3f50e 100644
--- a/hw/dec_pci.c
+++ b/hw/dec_pci.c
@@ -50,18 +50,25 @@ static int dec_map_irq(PCIDevice *pci_dev, int irq_num)
     return irq_num;
 }
 
-static PCIDeviceInfo dec_21154_pci_bridge_info = {
-    .qdev.name = "dec-21154-p2p-bridge",
-    .qdev.desc = "DEC 21154 PCI-PCI bridge",
-    .qdev.size = sizeof(PCIBridge),
-    .qdev.vmsd = &vmstate_pci_device,
-    .qdev.reset = pci_bridge_reset,
-    .init = pci_bridge_initfn,
-    .exit = pci_bridge_exitfn,
-    .vendor_id = PCI_VENDOR_ID_DEC,
-    .device_id = PCI_DEVICE_ID_DEC_21154,
-    .config_write = pci_bridge_write_config,
-    .is_bridge = 1,
+static void dec_21154_pci_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_bridge_initfn;
+    k->exit = pci_bridge_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_DEC;
+    k->device_id = PCI_DEVICE_ID_DEC_21154;
+    k->config_write = pci_bridge_write_config;
+    k->is_bridge = 1;
+}
+
+static DeviceInfo dec_21154_pci_bridge_info = {
+    .name = "dec-21154-p2p-bridge",
+    .desc = "DEC 21154 PCI-PCI bridge",
+    .size = sizeof(PCIBridge),
+    .vmsd = &vmstate_pci_device,
+    .reset = pci_bridge_reset,
+    .class_init = dec_21154_pci_bridge_class_init,
 };
 
 PCIBus *pci_dec_21154_init(PCIBus *parent_bus, int devfn)
@@ -98,21 +105,29 @@ static int dec_21154_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo dec_21154_pci_host_info = {
-    .qdev.name = "dec-21154",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = dec_21154_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_DEC,
-    .device_id = PCI_DEVICE_ID_DEC_21154,
-    .revision = 0x02,
-    .class_id = PCI_CLASS_BRIDGE_PCI,
-    .is_bridge  = 1,
+static void dec_21154_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = dec_21154_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_DEC;
+    k->device_id = PCI_DEVICE_ID_DEC_21154;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_BRIDGE_PCI;
+    k->is_bridge = 1;
+}
+
+static DeviceInfo dec_21154_pci_host_info = {
+    .name = "dec-21154",
+    .size = sizeof(PCIDevice),
+    .class_init = dec_21154_pci_host_class_init,
 };
 
 static void dec_register_devices(void)
 {
     sysbus_register_dev("dec-21154", sizeof(DECState),
                         pci_dec_21154_init_device);
+
     pci_qdev_register(&dec_21154_pci_host_info);
     pci_qdev_register(&dec_21154_pci_bridge_info);
 }
diff --git a/hw/e1000.c b/hw/e1000.c
index 6bab54e..c5d3ecb 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1192,23 +1192,32 @@ static void qdev_e1000_reset(DeviceState *dev)
     e1000_reset(d);
 }
 
-static PCIDeviceInfo e1000_info = {
-    .qdev.name  = "e1000",
-    .qdev.desc  = "Intel Gigabit Ethernet",
-    .qdev.size  = sizeof(E1000State),
-    .qdev.reset = qdev_e1000_reset,
-    .qdev.vmsd  = &vmstate_e1000,
-    .init       = pci_e1000_init,
-    .exit       = pci_e1000_uninit,
-    .romfile    = "pxe-e1000.rom",
-    .vendor_id  = PCI_VENDOR_ID_INTEL,
-    .device_id  = E1000_DEVID,
-    .revision   = 0x03,
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_NIC_PROPERTIES(E1000State, conf),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property e1000_properties[] = {
+    DEFINE_NIC_PROPERTIES(E1000State, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void e1000_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_e1000_init;
+    k->exit = pci_e1000_uninit;
+    k->romfile = "pxe-e1000.rom";
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = E1000_DEVID;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo e1000_info = {
+    .name = "e1000",
+    .desc = "Intel Gigabit Ethernet",
+    .size = sizeof(E1000State),
+    .reset = qdev_e1000_reset,
+    .vmsd = &vmstate_e1000,
+    .props = e1000_properties,
+    .class_init = e1000_class_init,
 };
 
 static void e1000_register_devices(void)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index f0059c6..9f6d333 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -128,7 +128,13 @@
 #define DRVR_INT        0x0200  /* Driver generated interrupt. */
 
 typedef struct {
-    PCIDeviceInfo pci;
+    DeviceInfo qdev;
+
+    uint16_t device_id;
+    uint8_t revision;
+    uint16_t subsystem_vendor_id;
+    uint16_t subsystem_id;
+
     uint32_t device;
     uint8_t stats_size;
     bool has_extended_tcb_support;
@@ -318,6 +324,8 @@ static const uint16_t eepro100_mdi_mask[] = {
 
 #define POLYNOMIAL 0x04c11db6
 
+static E100PCIDeviceInfo *eepro100_get_class(EEPRO100State *s);
+
 /* From FreeBSD */
 /* XXX: optimize */
 static unsigned compute_mcast_idx(const uint8_t * ep)
@@ -487,8 +495,9 @@ static void eepro100_fcp_interrupt(EEPRO100State * s)
 }
 #endif
 
-static void e100_pci_reset(EEPRO100State * s, E100PCIDeviceInfo *e100_device)
+static void e100_pci_reset(EEPRO100State * s)
 {
+    E100PCIDeviceInfo *info = eepro100_get_class(s);
     uint32_t device = s->device;
     uint8_t *pci_conf = s->dev.config;
 
@@ -508,8 +517,8 @@ static void e100_pci_reset(EEPRO100State * s, E100PCIDeviceInfo *e100_device)
     /* Maximum Latency */
     pci_set_byte(pci_conf + PCI_MAX_LAT, 0x18);
 
-    s->stats_size = e100_device->stats_size;
-    s->has_extended_tcb_support = e100_device->has_extended_tcb_support;
+    s->stats_size = info->stats_size;
+    s->has_extended_tcb_support = info->has_extended_tcb_support;
 
     switch (device) {
     case i82550:
@@ -558,7 +567,7 @@ static void e100_pci_reset(EEPRO100State * s, E100PCIDeviceInfo *e100_device)
     }
     assert(s->stats_size > 0 && s->stats_size <= sizeof(s->statistics));
 
-    if (e100_device->power_management) {
+    if (info->power_management) {
         /* Power Management Capabilities */
         int cfg_offset = 0xdc;
         int r = pci_add_capability(&s->dev, PCI_CAP_ID_PM,
@@ -1847,14 +1856,13 @@ static NetClientInfo net_eepro100_info = {
 static int e100_nic_init(PCIDevice *pci_dev)
 {
     EEPRO100State *s = DO_UPCAST(EEPRO100State, dev, pci_dev);
-    E100PCIDeviceInfo *e100_device = DO_UPCAST(E100PCIDeviceInfo, pci.qdev,
-                                               qdev_get_info(&pci_dev->qdev));
+    E100PCIDeviceInfo *info = eepro100_get_class(s);
 
     TRACE(OTHER, logout("\n"));
 
-    s->device = e100_device->device;
+    s->device = info->device;
 
-    e100_pci_reset(s, e100_device);
+    e100_pci_reset(s);
 
     /* Add 64 * 2 EEPROM. i82557 and i82558 support a 64 word EEPROM,
      * i82559 and later support 64 or 256 word EEPROM. */
@@ -1897,136 +1905,182 @@ static int e100_nic_init(PCIDevice *pci_dev)
 
 static E100PCIDeviceInfo e100_devices[] = {
     {
-        .pci.qdev.name = "i82550",
-        .pci.qdev.desc = "Intel i82550 Ethernet",
+        .qdev.name = "i82550",
+        .qdev.desc = "Intel i82550 Ethernet",
         .device = i82550,
         /* TODO: check device id. */
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82551IT,
+        .device_id = PCI_DEVICE_ID_INTEL_82551IT,
         /* Revision ID: 0x0c, 0x0d, 0x0e. */
-        .pci.revision = 0x0e,
+        .revision = 0x0e,
         /* TODO: check size of statistical counters. */
         .stats_size = 80,
         /* TODO: check extended tcb support. */
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82551",
-        .pci.qdev.desc = "Intel i82551 Ethernet",
+        .qdev.name = "i82551",
+        .qdev.desc = "Intel i82551 Ethernet",
         .device = i82551,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82551IT,
+        .device_id = PCI_DEVICE_ID_INTEL_82551IT,
         /* Revision ID: 0x0f, 0x10. */
-        .pci.revision = 0x0f,
+        .revision = 0x0f,
         /* TODO: check size of statistical counters. */
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82557a",
-        .pci.qdev.desc = "Intel i82557A Ethernet",
+        .qdev.name = "i82557a",
+        .qdev.desc = "Intel i82557A Ethernet",
         .device = i82557A,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x01,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x01,
         .power_management = false,
     },{
-        .pci.qdev.name = "i82557b",
-        .pci.qdev.desc = "Intel i82557B Ethernet",
+        .qdev.name = "i82557b",
+        .qdev.desc = "Intel i82557B Ethernet",
         .device = i82557B,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x02,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x02,
         .power_management = false,
     },{
-        .pci.qdev.name = "i82557c",
-        .pci.qdev.desc = "Intel i82557C Ethernet",
+        .qdev.name = "i82557c",
+        .qdev.desc = "Intel i82557C Ethernet",
         .device = i82557C,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x03,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x03,
         .power_management = false,
     },{
-        .pci.qdev.name = "i82558a",
-        .pci.qdev.desc = "Intel i82558A Ethernet",
+        .qdev.name = "i82558a",
+        .qdev.desc = "Intel i82558A Ethernet",
         .device = i82558A,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x04,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x04,
         .stats_size = 76,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82558b",
-        .pci.qdev.desc = "Intel i82558B Ethernet",
+        .qdev.name = "i82558b",
+        .qdev.desc = "Intel i82558B Ethernet",
         .device = i82558B,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x05,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x05,
         .stats_size = 76,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82559a",
-        .pci.qdev.desc = "Intel i82559A Ethernet",
+        .qdev.name = "i82559a",
+        .qdev.desc = "Intel i82559A Ethernet",
         .device = i82559A,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x06,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x06,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82559b",
-        .pci.qdev.desc = "Intel i82559B Ethernet",
+        .qdev.name = "i82559b",
+        .qdev.desc = "Intel i82559B Ethernet",
         .device = i82559B,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
-        .pci.revision = 0x07,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
+        .revision = 0x07,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82559c",
-        .pci.qdev.desc = "Intel i82559C Ethernet",
+        .qdev.name = "i82559c",
+        .qdev.desc = "Intel i82559C Ethernet",
         .device = i82559C,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82557,
+        .device_id = PCI_DEVICE_ID_INTEL_82557,
 #if 0
-        .pci.revision = 0x08,
+        .revision = 0x08,
 #endif
         /* TODO: Windows wants revision id 0x0c. */
-        .pci.revision = 0x0c,
+        .revision = 0x0c,
 #if EEPROM_SIZE > 0
-        .pci.subsystem_vendor_id = PCI_VENDOR_ID_INTEL,
-        .pci.subsystem_id = 0x0040,
+        .subsystem_vendor_id = PCI_VENDOR_ID_INTEL,
+        .subsystem_id = 0x0040,
 #endif
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82559er",
-        .pci.qdev.desc = "Intel i82559ER Ethernet",
+        .qdev.name = "i82559er",
+        .qdev.desc = "Intel i82559ER Ethernet",
         .device = i82559ER,
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82551IT,
-        .pci.revision = 0x09,
+        .device_id = PCI_DEVICE_ID_INTEL_82551IT,
+        .revision = 0x09,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
-        .pci.qdev.name = "i82562",
-        .pci.qdev.desc = "Intel i82562 Ethernet",
+        .qdev.name = "i82562",
+        .qdev.desc = "Intel i82562 Ethernet",
         .device = i82562,
         /* TODO: check device id. */
-        .pci.device_id = PCI_DEVICE_ID_INTEL_82551IT,
+        .device_id = PCI_DEVICE_ID_INTEL_82551IT,
         /* TODO: wrong revision id. */
-        .pci.revision = 0x0e,
+        .revision = 0x0e,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     },{
         /* Toshiba Tecra 8200. */
-        .pci.qdev.name = "i82801",
-        .pci.qdev.desc = "Intel i82801 Ethernet",
+        .qdev.name = "i82801",
+        .qdev.desc = "Intel i82801 Ethernet",
         .device = i82801,
-        .pci.device_id = 0x2449,
-        .pci.revision = 0x03,
+        .device_id = 0x2449,
+        .revision = 0x03,
         .stats_size = 80,
         .has_extended_tcb_support = true,
         .power_management = true,
     }
 };
 
+static E100PCIDeviceInfo *eepro100_get_class_by_name(const char *typename)
+{
+    E100PCIDeviceInfo *info = NULL;
+    int i;
+
+    /* This is admittedly awkward but also temporary.  QOM allows for
+     * parameterized typing and for subclassing both of which would suitable
+     * handle what's going on here.  But class_data is already being used as
+     * a stop-gap hack to allow incremental qdev conversion so we cannot use it
+     * right now.  Once we merge the final QOM series, we can come back here and
+     * do this in a much more elegant fashion.
+     */
+    for (i = 0; i < ARRAY_SIZE(e100_devices); i++) {
+        if (strcmp(e100_devices[i].qdev.name, typename) == 0) {
+            info = &e100_devices[i];
+            break;
+        }
+    }
+    assert(info != NULL);
+
+    return info;
+}
+
+static E100PCIDeviceInfo *eepro100_get_class(EEPRO100State *s)
+{
+    return eepro100_get_class_by_name(object_get_typename(OBJECT(s)));
+}
+
+static void eepro100_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+    E100PCIDeviceInfo *info;
+
+    info = eepro100_get_class_by_name(object_class_get_name(klass));
+
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+    k->romfile = "pxe-eepro100.rom";
+    k->init = e100_nic_init;
+    k->exit = pci_nic_uninit;
+    k->device_id = info->device_id;
+    k->revision = info->revision;
+    k->subsystem_vendor_id = info->subsystem_vendor_id;
+    k->subsystem_id = info->subsystem_id;
+}
+
 static Property e100_properties[] = {
     DEFINE_NIC_PROPERTIES(EEPRO100State, conf),
     DEFINE_PROP_END_OF_LIST(),
@@ -2036,17 +2090,13 @@ static void eepro100_register_devices(void)
 {
     size_t i;
     for (i = 0; i < ARRAY_SIZE(e100_devices); i++) {
-        PCIDeviceInfo *pci_dev = &e100_devices[i].pci;
-        /* We use the same rom file for all device ids.
-           QEMU fixes the device id during rom load. */
-        pci_dev->vendor_id = PCI_VENDOR_ID_INTEL;
-        pci_dev->class_id = PCI_CLASS_NETWORK_ETHERNET;
-        pci_dev->romfile = "pxe-eepro100.rom";
-        pci_dev->init = e100_nic_init;
-        pci_dev->exit = pci_nic_uninit;
-        pci_dev->qdev.props = e100_properties;
-        pci_dev->qdev.size = sizeof(EEPRO100State);
-        pci_qdev_register(pci_dev);
+        DeviceInfo *info = &e100_devices[i].qdev;
+
+        info->class_init = eepro100_class_init;
+        info->size = sizeof(EEPRO100State);
+        info->props = e100_properties;
+        
+        pci_qdev_register(info);
     }
 }
 
diff --git a/hw/es1370.c b/hw/es1370.c
index 3527eb6..205bed7 100644
--- a/hw/es1370.c
+++ b/hw/es1370.c
@@ -1031,18 +1031,25 @@ int es1370_init (PCIBus *bus)
     return 0;
 }
 
-static PCIDeviceInfo es1370_info = {
-    .qdev.name    = "ES1370",
-    .qdev.desc    = "ENSONIQ AudioPCI ES1370",
-    .qdev.size    = sizeof (ES1370State),
-    .qdev.vmsd    = &vmstate_es1370,
-    .init         = es1370_initfn,
-    .exit         = es1370_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_ENSONIQ,
-    .device_id    = PCI_DEVICE_ID_ENSONIQ_ES1370,
-    .class_id     = PCI_CLASS_MULTIMEDIA_AUDIO,
-    .subsystem_vendor_id = 0x4942,
-    .subsystem_id = 0x4c4c,
+static void es1370_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = es1370_initfn;
+    k->exit = es1370_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_ENSONIQ;
+    k->device_id = PCI_DEVICE_ID_ENSONIQ_ES1370;
+    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
+    k->subsystem_vendor_id = 0x4942;
+    k->subsystem_id = 0x4c4c;
+}
+
+static DeviceInfo es1370_info = {
+    .name = "ES1370",
+    .desc = "ENSONIQ AudioPCI ES1370",
+    .size = sizeof (ES1370State),
+    .vmsd = &vmstate_es1370,
+    .class_init = es1370_class_init,
 };
 
 static void es1370_register (void)
diff --git a/hw/grackle_pci.c b/hw/grackle_pci.c
index be10a6d..a790f97 100644
--- a/hw/grackle_pci.c
+++ b/hw/grackle_pci.c
@@ -121,15 +121,22 @@ static int grackle_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo grackle_pci_info = {
-    .qdev.name = "grackle",
-    .qdev.size = sizeof(PCIDevice),
-    .qdev.no_user = 1,
-    .init      = grackle_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_MOTOROLA,
-    .device_id = PCI_DEVICE_ID_MOTOROLA_MPC106,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void grackle_pci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = grackle_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_MOTOROLA;
+    k->device_id = PCI_DEVICE_ID_MOTOROLA_MPC106;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo grackle_pci_info = {
+    .name = "grackle",
+    .size = sizeof(PCIDevice),
+    .no_user = 1,
+    .class_init = grackle_pci_class_init,
 };
 
 static SysBusDeviceInfo grackle_pci_host_info = {
diff --git a/hw/gt64xxx.c b/hw/gt64xxx.c
index 432683a..9fc51f2 100644
--- a/hw/gt64xxx.c
+++ b/hw/gt64xxx.c
@@ -1136,14 +1136,21 @@ static int gt64120_pci_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo gt64120_pci_info = {
-    .qdev.name = "gt64120_pci",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = gt64120_pci_init,
-    .vendor_id = PCI_VENDOR_ID_MARVELL,
-    .device_id = PCI_DEVICE_ID_MARVELL_GT6412X,
-    .revision  = 0x10,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void gt64120_pci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = gt64120_pci_init;
+    k->vendor_id = PCI_VENDOR_ID_MARVELL;
+    k->device_id = PCI_DEVICE_ID_MARVELL_GT6412X;
+    k->revision = 0x10;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo gt64120_pci_info = {
+    .name = "gt64120_pci",
+    .size = sizeof(PCIDevice),
+    .class_init = gt64120_pci_class_init,
 };
 
 static void gt64120_pci_register_devices(void)
diff --git a/hw/i82378.c b/hw/i82378.c
index 95ae274..99b453a 100644
--- a/hw/i82378.c
+++ b/hw/i82378.c
@@ -238,18 +238,25 @@ static int pci_i82378_init(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo pci_i82378_info = {
-    .init = pci_i82378_init,
-    .qdev.name = "i82378",
-    .qdev.size = sizeof(PCIi82378State),
-    .qdev.vmsd = &vmstate_pci_i82378,
-    .vendor_id = PCI_VENDOR_ID_INTEL,
-    .device_id = PCI_DEVICE_ID_INTEL_82378,
-    .revision = 0x03,
-    .class_id = PCI_CLASS_BRIDGE_ISA,
-    .subsystem_vendor_id = 0x0,
-    .subsystem_id = 0x0,
-    .qdev.props = (Property[]) {
+static void pci_i82378_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_i82378_init;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82378;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+    k->subsystem_vendor_id = 0x0;
+    k->subsystem_id = 0x0;
+}
+
+static DeviceInfo pci_i82378_info = {
+    .name = "i82378",
+    .size = sizeof(PCIi82378State),
+    .vmsd = &vmstate_pci_i82378,
+    .class_init = pci_i82378_class_init,
+    .props = (Property[]) {
         DEFINE_PROP_HEX32("iobase", PCIi82378State, isa_io_base, 0x80000000),
         DEFINE_PROP_HEX32("membase", PCIi82378State, isa_mem_base, 0xc0000000),
         DEFINE_PROP_END_OF_LIST()
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index 99e7e6f..9c673bb 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -325,20 +325,28 @@ void pci_cmd646_ide_init(PCIBus *bus, DriveInfo **hd_table,
     pci_ide_create_devs(dev, hd_table);
 }
 
-static PCIDeviceInfo cmd646_ide_info = {
-    .qdev.name    = "cmd646-ide",
-    .qdev.size    = sizeof(PCIIDEState),
-    .init         = pci_cmd646_ide_initfn,
-    .exit         = pci_cmd646_ide_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_CMD,
-    .device_id    = PCI_DEVICE_ID_CMD_646,
-    /* IDE controller revision */
-    .revision     = 0x07,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
-    .qdev.props   = (Property[]) {
-        DEFINE_PROP_UINT32("secondary", PCIIDEState, secondary, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    },
+static Property cmd646_ide_properties[] = {
+    DEFINE_PROP_UINT32("secondary", PCIIDEState, secondary, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void cmd646_ide_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_cmd646_ide_initfn;
+    k->exit = pci_cmd646_ide_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_CMD;
+    k->device_id = PCI_DEVICE_ID_CMD_646;
+    k->revision = 0x07;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo cmd646_ide_info = {
+    .name = "cmd646-ide",
+    .size = sizeof(PCIIDEState),
+    .props = cmd646_ide_properties,
+    .class_init = cmd646_ide_class_init,
 };
 
 static void cmd646_ide_register(void)
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index e6421e2..1cae9f1 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -146,18 +146,25 @@ static void pci_ich9_write_config(PCIDevice *pci, uint32_t addr,
     msi_write_config(pci, addr, val, len);
 }
 
-static PCIDeviceInfo ich_ahci_info = {
-    .qdev.name    = "ich9-ahci",
-    .qdev.alias   = "ahci",
-    .qdev.size    = sizeof(AHCIPCIState),
-    .qdev.vmsd    = &vmstate_ahci,
-    .init         = pci_ich9_ahci_init,
-    .exit         = pci_ich9_uninit,
-    .config_write = pci_ich9_write_config,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801IR,
-    .revision     = 0x02,
-    .class_id     = PCI_CLASS_STORAGE_SATA,
+static void ich_ahci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_ich9_ahci_init;
+    k->exit = pci_ich9_uninit;
+    k->config_write = pci_ich9_write_config;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801IR;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_STORAGE_SATA;
+}
+
+static DeviceInfo ich_ahci_info = {
+    .name = "ich9-ahci",
+    .alias = "ahci",
+    .size = sizeof(AHCIPCIState),
+    .vmsd = &vmstate_ahci,
+    .class_init = ich_ahci_class_init,
 };
 
 static void ich_ahci_register(void)
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 91b77a2..832a507 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -237,39 +237,60 @@ PCIDevice *pci_piix4_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
     return dev;
 }
 
-static PCIDeviceInfo piix3_ide_info = {
-    .qdev.name    = "piix3-ide",
-    .qdev.size    = sizeof(PCIIDEState),
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = pci_piix_ide_initfn,
-    .exit         = pci_piix_ide_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371SB_1,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
+static void piix3_ide_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_piix_ide_initfn;
+    k->exit = pci_piix_ide_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371SB_1;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo piix3_ide_info = {
+    .name = "piix3-ide",
+    .size = sizeof(PCIIDEState),
+    .no_user = 1,
+    .class_init = piix3_ide_class_init,
 };
 
-static PCIDeviceInfo piix3_ide_xen_info = {
-    .qdev.name    = "piix3-ide-xen",
-    .qdev.size    = sizeof(PCIIDEState),
-    .qdev.no_user = 1,
-    .qdev.unplug  = pci_piix3_xen_ide_unplug,
-    .init         = pci_piix_ide_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371SB_1,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
+static void piix3_ide_xen_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_piix_ide_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371SB_1;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo piix3_ide_xen_info = {
+    .name = "piix3-ide-xen",
+    .size = sizeof(PCIIDEState),
+    .no_user = 1,
+    .class_init = piix3_ide_xen_class_init,
+    .unplug = pci_piix3_xen_ide_unplug,
 };
 
-static PCIDeviceInfo piix4_ide_info = {
-    .qdev.name    = "piix4-ide",
-    .qdev.size    = sizeof(PCIIDEState),
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = pci_piix_ide_initfn,
-    .exit         = pci_piix_ide_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371AB,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
+static void piix4_ide_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_piix_ide_initfn;
+    k->exit = pci_piix_ide_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371AB;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo piix4_ide_info = {
+    .name = "piix4-ide",
+    .size = sizeof(PCIIDEState),
+    .no_user = 1,
+    .class_init = piix4_ide_class_init,
 };
 
 static void piix_ide_register(void)
diff --git a/hw/ide/via.c b/hw/ide/via.c
index 4ea2064..ef70864 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -213,16 +213,23 @@ void vt82c686b_ide_init(PCIBus *bus, DriveInfo **hd_table, int devfn)
     pci_ide_create_devs(dev, hd_table);
 }
 
-static PCIDeviceInfo via_ide_info = {
-    .qdev.name    = "via-ide",
-    .qdev.size    = sizeof(PCIIDEState),
-    .qdev.no_user = 1,
-    .init         = vt82c686b_ide_initfn,
-    .exit         = vt82c686b_ide_exitfn,
-    .vendor_id    = PCI_VENDOR_ID_VIA,
-    .device_id    = PCI_DEVICE_ID_VIA_IDE,
-    .revision     = 0x06,
-    .class_id     = PCI_CLASS_STORAGE_IDE,
+static void via_ide_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_ide_initfn;
+    k->exit = vt82c686b_ide_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_IDE;
+    k->revision = 0x06;
+    k->class_id = PCI_CLASS_STORAGE_IDE;
+}
+
+static DeviceInfo via_ide_info = {
+    .name = "via-ide",
+    .size = sizeof(PCIIDEState),
+    .no_user = 1,
+    .class_init = via_ide_class_init,
 };
 
 static void via_ide_register(void)
diff --git a/hw/intel-hda.c b/hw/intel-hda.c
index f727c22..f062133 100644
--- a/hw/intel-hda.c
+++ b/hw/intel-hda.c
@@ -79,7 +79,7 @@ void hda_codec_register(DeviceInfo *info)
     info->init = hda_codec_dev_init;
     info->exit = hda_codec_dev_exit;
     info->bus_info = &hda_codec_bus_info;
-    qdev_register(info);
+    qdev_register_subclass(info, TYPE_HDA_CODEC_DEVICE);
 }
 
 HDACodecDevice *hda_codec_find(HDACodecBus *bus, uint32_t cad)
@@ -1247,29 +1247,47 @@ static const VMStateDescription vmstate_intel_hda = {
     }
 };
 
-static PCIDeviceInfo intel_hda_info = {
-    .qdev.name    = "intel-hda",
-    .qdev.desc    = "Intel HD Audio Controller",
-    .qdev.size    = sizeof(IntelHDAState),
-    .qdev.vmsd    = &vmstate_intel_hda,
-    .qdev.reset   = intel_hda_reset,
-    .init         = intel_hda_init,
-    .exit         = intel_hda_exit,
-    .config_write = intel_hda_write_config,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = 0x2668,
-    .revision     = 1,
-    .class_id     = PCI_CLASS_MULTIMEDIA_HD_AUDIO,
-    .qdev.props   = (Property[]) {
-        DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0),
-        DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property intel_hda_properties[] = {
+    DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0),
+    DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void intel_hda_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = intel_hda_init;
+    k->exit = intel_hda_exit;
+    k->config_write = intel_hda_write_config;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = 0x2668;
+    k->revision = 1;
+    k->class_id = PCI_CLASS_MULTIMEDIA_HD_AUDIO;
+}
+
+static DeviceInfo intel_hda_info = {
+    .name = "intel-hda",
+    .desc = "Intel HD Audio Controller",
+    .size = sizeof(IntelHDAState),
+    .vmsd = &vmstate_intel_hda,
+    .reset = intel_hda_reset,
+    .props = intel_hda_properties,
+    .class_init = intel_hda_class_init,
+};
+
+static TypeInfo hda_codec_device_type_info = {
+    .name = TYPE_HDA_CODEC_DEVICE,
+    .parent = TYPE_DEVICE,
+    .instance_size = sizeof(HDACodecDevice),
+    .abstract = true,
+    .class_size = sizeof(HDACodecDeviceClass),
 };
 
 static void intel_hda_register(void)
 {
     pci_qdev_register(&intel_hda_info);
+    type_register_static(&hda_codec_device_type_info);
 }
 device_init(intel_hda_register);
 
diff --git a/hw/ioh3420.c b/hw/ioh3420.c
index a6bfbb9..6cfafb3 100644
--- a/hw/ioh3420.c
+++ b/hw/ioh3420.c
@@ -80,7 +80,7 @@ static void ioh3420_write_config(PCIDevice *d,
 
 static void ioh3420_reset(DeviceState *qdev)
 {
-    PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *d = PCI_DEVICE(qdev);
     msi_reset(d);
     ioh3420_aer_vector_update(d);
     pcie_cap_root_reset(d);
@@ -201,31 +201,38 @@ static const VMStateDescription vmstate_ioh3420 = {
     }
 };
 
-static PCIDeviceInfo ioh3420_info = {
-    .qdev.name = "ioh3420",
-    .qdev.desc = "Intel IOH device id 3420 PCIE Root Port",
-    .qdev.size = sizeof(PCIESlot),
-    .qdev.reset = ioh3420_reset,
-    .qdev.vmsd = &vmstate_ioh3420,
-
-    .is_express = 1,
-    .is_bridge = 1,
-    .config_write = ioh3420_write_config,
-    .init = ioh3420_initfn,
-    .exit = ioh3420_exitfn,
-    .vendor_id = PCI_VENDOR_ID_INTEL,
-    .device_id = PCI_DEVICE_ID_IOH_EPORT,
-    .revision = PCI_DEVICE_ID_IOH_REV,
-
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
-        DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
-        DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
-        DEFINE_PROP_UINT16("aer_log_max", PCIESlot,
-                           port.br.dev.exp.aer_log.log_max,
-                           PCIE_AER_LOG_MAX_DEFAULT),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property ioh3420_properties[] = {
+    DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
+    DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
+    DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
+    DEFINE_PROP_UINT16("aer_log_max", PCIESlot,
+    port.br.dev.exp.aer_log.log_max,
+    PCIE_AER_LOG_MAX_DEFAULT),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ioh3420_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->is_express = 1;
+    k->is_bridge = 1;
+    k->config_write = ioh3420_write_config;
+    k->init = ioh3420_initfn;
+    k->exit = ioh3420_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_IOH_EPORT;
+    k->revision = PCI_DEVICE_ID_IOH_REV;
+}
+
+static DeviceInfo ioh3420_info = {
+    .name = "ioh3420",
+    .desc = "Intel IOH device id 3420 PCIE Root Port",
+    .size = sizeof(PCIESlot),
+    .reset = ioh3420_reset,
+    .vmsd = &vmstate_ioh3420,
+    .props = ioh3420_properties,
+    .class_init = ioh3420_class_init,
 };
 
 static void ioh3420_register(void)
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index bec2e0b..e2880be 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -766,25 +766,34 @@ static int pci_ivshmem_uninit(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo ivshmem_info = {
-    .qdev.name  = "ivshmem",
-    .qdev.size  = sizeof(IVShmemState),
-    .qdev.reset = ivshmem_reset,
-    .init       = pci_ivshmem_init,
-    .exit       = pci_ivshmem_uninit,
-    .vendor_id  = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id  = 0x1110,
-    .class_id   = PCI_CLASS_MEMORY_RAM,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_CHR("chardev", IVShmemState, server_chr),
-        DEFINE_PROP_STRING("size", IVShmemState, sizearg),
-        DEFINE_PROP_UINT32("vectors", IVShmemState, vectors, 1),
-        DEFINE_PROP_BIT("ioeventfd", IVShmemState, features, IVSHMEM_IOEVENTFD, false),
-        DEFINE_PROP_BIT("msi", IVShmemState, features, IVSHMEM_MSI, true),
-        DEFINE_PROP_STRING("shm", IVShmemState, shmobj),
-        DEFINE_PROP_STRING("role", IVShmemState, role),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property ivshmem_properties[] = {
+    DEFINE_PROP_CHR("chardev", IVShmemState, server_chr),
+    DEFINE_PROP_STRING("size", IVShmemState, sizearg),
+    DEFINE_PROP_UINT32("vectors", IVShmemState, vectors, 1),
+    DEFINE_PROP_BIT("ioeventfd", IVShmemState, features, IVSHMEM_IOEVENTFD, false),
+    DEFINE_PROP_BIT("msi", IVShmemState, features, IVSHMEM_MSI, true),
+    DEFINE_PROP_STRING("shm", IVShmemState, shmobj),
+    DEFINE_PROP_STRING("role", IVShmemState, role),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ivshmem_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_ivshmem_init;
+    k->exit = pci_ivshmem_uninit;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = 0x1110;
+    k->class_id = PCI_CLASS_MEMORY_RAM;
+}
+
+static DeviceInfo ivshmem_info = {
+    .name = "ivshmem",
+    .size = sizeof(IVShmemState),
+    .reset = ivshmem_reset,
+    .props = ivshmem_properties,
+    .class_init = ivshmem_class_init,
 };
 
 static void ivshmem_register_devices(void)
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index 3a87171..3571588 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895a.c
@@ -2120,18 +2120,25 @@ static int lsi_scsi_init(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo lsi_info = {
-    .qdev.name  = "lsi53c895a",
-    .qdev.alias = "lsi",
-    .qdev.size  = sizeof(LSIState),
-    .qdev.reset = lsi_scsi_reset,
-    .qdev.vmsd  = &vmstate_lsi_scsi,
-    .init       = lsi_scsi_init,
-    .exit       = lsi_scsi_uninit,
-    .vendor_id  = PCI_VENDOR_ID_LSI_LOGIC,
-    .device_id  = PCI_DEVICE_ID_LSI_53C895A,
-    .class_id   = PCI_CLASS_STORAGE_SCSI,
-    .subsystem_id = 0x1000,
+static void lsi_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = lsi_scsi_init;
+    k->exit = lsi_scsi_uninit;
+    k->vendor_id = PCI_VENDOR_ID_LSI_LOGIC;
+    k->device_id = PCI_DEVICE_ID_LSI_53C895A;
+    k->class_id = PCI_CLASS_STORAGE_SCSI;
+    k->subsystem_id = 0x1000;
+}
+
+static DeviceInfo lsi_info = {
+    .name = "lsi53c895a",
+    .alias = "lsi",
+    .size = sizeof(LSIState),
+    .reset = lsi_scsi_reset,
+    .vmsd = &vmstate_lsi_scsi,
+    .class_init = lsi_class_init,
 };
 
 static void lsi53c895a_register_devices(void)
diff --git a/hw/macio.c b/hw/macio.c
index 357e0ea..ae9db08 100644
--- a/hw/macio.c
+++ b/hw/macio.c
@@ -81,12 +81,19 @@ static int macio_initfn(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo macio_info = {
-    .qdev.name = "macio",
-    .qdev.size = sizeof(MacIOState),
-    .init = macio_initfn,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .class_id = PCI_CLASS_OTHERS << 8,
+static void macio_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = macio_initfn;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->class_id = PCI_CLASS_OTHERS << 8;
+}
+
+static DeviceInfo macio_info = {
+    .name = "macio",
+    .size = sizeof(MacIOState),
+    .class_init = macio_class_init,
 };
 
 static void macio_register(void)
diff --git a/hw/ne2000.c b/hw/ne2000.c
index b44eab1..138479a 100644
--- a/hw/ne2000.c
+++ b/hw/ne2000.c
@@ -786,19 +786,28 @@ static int pci_ne2000_exit(PCIDevice *pci_dev)
     return 0;
 }
 
-static PCIDeviceInfo ne2000_info = {
-    .qdev.name  = "ne2k_pci",
-    .qdev.size  = sizeof(PCINE2000State),
-    .qdev.vmsd  = &vmstate_pci_ne2000,
-    .init       = pci_ne2000_init,
-    .exit       = pci_ne2000_exit,
-    .vendor_id  = PCI_VENDOR_ID_REALTEK,
-    .device_id  = PCI_DEVICE_ID_REALTEK_8029,
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_NIC_PROPERTIES(PCINE2000State, ne2000.c),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property ne2000_properties[] = {
+    DEFINE_NIC_PROPERTIES(PCINE2000State, ne2000.c),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ne2000_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_ne2000_init;
+    k->exit = pci_ne2000_exit;
+    k->vendor_id = PCI_VENDOR_ID_REALTEK;
+    k->device_id = PCI_DEVICE_ID_REALTEK_8029;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo ne2000_info = {
+    .name = "ne2k_pci",
+    .size = sizeof(PCINE2000State),
+    .vmsd = &vmstate_pci_ne2000,
+    .props = ne2000_properties,
+    .class_init = ne2000_class_init,
 };
 
 static void ne2000_register_devices(void)
diff --git a/hw/pci.c b/hw/pci.c
index 516da08..6a0b1f5 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -89,7 +89,6 @@ static const VMStateDescription vmstate_pcibus = {
         VMSTATE_END_OF_LIST()
     }
 };
-
 static int pci_bar(PCIDevice *d, int reg)
 {
     uint8_t type;
@@ -730,11 +729,11 @@ static void pci_config_free(PCIDevice *pci_dev)
 
 /* -1 for devfn means auto assign */
 static PCIDevice *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
-                                         const char *name, int devfn,
-                                         const PCIDeviceInfo *info)
+                                         const char *name, int devfn)
 {
-    PCIConfigReadFunc *config_read = info->config_read;
-    PCIConfigWriteFunc *config_write = info->config_write;
+    PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pci_dev);
+    PCIConfigReadFunc *config_read = pc->config_read;
+    PCIConfigWriteFunc *config_write = pc->config_write;
 
     if (devfn < 0) {
         for(devfn = bus->devfn_min ; devfn < ARRAY_SIZE(bus->devices);
@@ -756,29 +755,29 @@ static PCIDevice *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
     pci_dev->irq_state = 0;
     pci_config_alloc(pci_dev);
 
-    pci_config_set_vendor_id(pci_dev->config, info->vendor_id);
-    pci_config_set_device_id(pci_dev->config, info->device_id);
-    pci_config_set_revision(pci_dev->config, info->revision);
-    pci_config_set_class(pci_dev->config, info->class_id);
+    pci_config_set_vendor_id(pci_dev->config, pc->vendor_id);
+    pci_config_set_device_id(pci_dev->config, pc->device_id);
+    pci_config_set_revision(pci_dev->config, pc->revision);
+    pci_config_set_class(pci_dev->config, pc->class_id);
 
-    if (!info->is_bridge) {
-        if (info->subsystem_vendor_id || info->subsystem_id) {
+    if (!pc->is_bridge) {
+        if (pc->subsystem_vendor_id || pc->subsystem_id) {
             pci_set_word(pci_dev->config + PCI_SUBSYSTEM_VENDOR_ID,
-                         info->subsystem_vendor_id);
+                         pc->subsystem_vendor_id);
             pci_set_word(pci_dev->config + PCI_SUBSYSTEM_ID,
-                         info->subsystem_id);
+                         pc->subsystem_id);
         } else {
             pci_set_default_subsystem_id(pci_dev);
         }
     } else {
         /* subsystem_vendor_id/subsystem_id are only for header type 0 */
-        assert(!info->subsystem_vendor_id);
-        assert(!info->subsystem_id);
+        assert(!pc->subsystem_vendor_id);
+        assert(!pc->subsystem_id);
     }
     pci_init_cmask(pci_dev);
     pci_init_wmask(pci_dev);
     pci_init_w1cmask(pci_dev);
-    if (info->is_bridge) {
+    if (pc->is_bridge) {
         pci_init_wmask_bridge(pci_dev);
     }
     if (pci_init_multifunction(bus, pci_dev)) {
@@ -805,26 +804,6 @@ static void do_pci_unregister_device(PCIDevice *pci_dev)
     pci_config_free(pci_dev);
 }
 
-/* TODO: obsolete. eliminate this once all pci devices are qdevifed. */
-PCIDevice *pci_register_device(PCIBus *bus, const char *name,
-                               int instance_size, int devfn,
-                               PCIConfigReadFunc *config_read,
-                               PCIConfigWriteFunc *config_write)
-{
-    PCIDevice *pci_dev;
-    PCIDeviceInfo info = {
-        .config_read = config_read,
-        .config_write = config_write,
-    };
-
-    pci_dev = g_malloc0(instance_size);
-    pci_dev = do_pci_register_device(pci_dev, bus, name, devfn, &info);
-    if (pci_dev == NULL) {
-        hw_error("PCI: can't register device\n");
-    }
-    return pci_dev;
-}
-
 static void pci_unregister_io_regions(PCIDevice *pci_dev)
 {
     PCIIORegion *r;
@@ -840,12 +819,12 @@ static void pci_unregister_io_regions(PCIDevice *pci_dev)
 
 static int pci_unregister_device(DeviceState *dev)
 {
-    PCIDevice *pci_dev = DO_UPCAST(PCIDevice, qdev, dev);
-    PCIDeviceInfo *info = DO_UPCAST(PCIDeviceInfo, qdev, qdev_get_info(dev));
+    PCIDevice *pci_dev = PCI_DEVICE(dev);
+    PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pci_dev);
     int ret = 0;
 
-    if (info->exit)
-        ret = info->exit(pci_dev);
+    if (pc->exit)
+        ret = pc->exit(pci_dev);
     if (ret)
         return ret;
 
@@ -1477,28 +1456,27 @@ PCIDevice *pci_find_device(PCIBus *bus, int bus_num, uint8_t devfn)
 static int pci_qdev_init(DeviceState *qdev, DeviceInfo *base)
 {
     PCIDevice *pci_dev = (PCIDevice *)qdev;
-    PCIDeviceInfo *info = container_of(base, PCIDeviceInfo, qdev);
+    PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pci_dev);
     PCIBus *bus;
     int rc;
     bool is_default_rom;
 
     /* initialize cap_present for pci_is_express() and pci_config_size() */
-    if (info->is_express) {
+    if (pc->is_express) {
         pci_dev->cap_present |= QEMU_PCI_CAP_EXPRESS;
     }
 
     bus = FROM_QBUS(PCIBus, qdev_get_parent_bus(qdev));
-    pci_dev = do_pci_register_device(pci_dev, bus, base->name,
-                                     pci_dev->devfn, info);
+    pci_dev = do_pci_register_device(pci_dev, bus, base->name, pci_dev->devfn);
     if (pci_dev == NULL)
         return -1;
-    if (qdev->hotplugged && info->no_hotplug) {
+    if (qdev->hotplugged && pc->no_hotplug) {
         qerror_report(QERR_DEVICE_NO_HOTPLUG, object_get_typename(OBJECT(pci_dev)));
         do_pci_unregister_device(pci_dev);
         return -1;
     }
-    if (info->init) {
-        rc = info->init(pci_dev);
+    if (pc->init) {
+        rc = pc->init(pci_dev);
         if (rc != 0) {
             do_pci_unregister_device(pci_dev);
             return rc;
@@ -1507,8 +1485,8 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo *base)
 
     /* rom loading */
     is_default_rom = false;
-    if (pci_dev->romfile == NULL && info->romfile != NULL) {
-        pci_dev->romfile = g_strdup(info->romfile);
+    if (pci_dev->romfile == NULL && pc->romfile != NULL) {
+        pci_dev->romfile = g_strdup(pc->romfile);
         is_default_rom = true;
     }
     pci_add_option_rom(pci_dev, is_default_rom);
@@ -1530,10 +1508,10 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo *base)
 
 static int pci_unplug_device(DeviceState *qdev)
 {
-    PCIDevice *dev = DO_UPCAST(PCIDevice, qdev, qdev);
-    PCIDeviceInfo *info = container_of(qdev_get_info(qdev), PCIDeviceInfo, qdev);
+    PCIDevice *dev = PCI_DEVICE(qdev);
+    PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(dev);
 
-    if (info->no_hotplug) {
+    if (pc->no_hotplug) {
         qerror_report(QERR_DEVICE_NO_HOTPLUG, object_get_typename(OBJECT(dev)));
         return -1;
     }
@@ -1541,23 +1519,15 @@ static int pci_unplug_device(DeviceState *qdev)
                              PCI_HOTPLUG_DISABLED);
 }
 
-void pci_qdev_register(PCIDeviceInfo *info)
-{
-    info->qdev.init = pci_qdev_init;
-    if (!info->qdev.unplug) {
-        info->qdev.unplug = pci_unplug_device;
-    }
-    info->qdev.exit = pci_unregister_device;
-    info->qdev.bus_info = &pci_bus_info;
-    qdev_register(&info->qdev);
-}
-
-void pci_qdev_register_many(PCIDeviceInfo *info)
+void pci_qdev_register(DeviceInfo *info)
 {
-    while (info->qdev.name) {
-        pci_qdev_register(info);
-        info++;
+    info->init = pci_qdev_init;
+    if (!info->unplug) {
+        info->unplug = pci_unplug_device;
     }
+    info->exit = pci_unregister_device;
+    info->bus_info = &pci_bus_info;
+    qdev_register_subclass(info, TYPE_PCI_DEVICE);
 }
 
 PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool multifunction,
@@ -1568,7 +1538,7 @@ PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool multifunction,
     dev = qdev_create(&bus->qbus, name);
     qdev_prop_set_uint32(dev, "addr", devfn);
     qdev_prop_set_bit(dev, "multifunction", multifunction);
-    return DO_UPCAST(PCIDevice, qdev, dev);
+    return PCI_DEVICE(dev);
 }
 
 PCIDevice *pci_create_simple_multifunction(PCIBus *bus, int devfn,
@@ -1985,7 +1955,7 @@ static int pci_qdev_find_recursive(PCIBus *bus,
     /* roughly check if given qdev is pci device */
     if (qdev_get_info(qdev)->init == &pci_qdev_init &&
         qdev->parent_bus->info == &pci_bus_info) {
-        *pdev = DO_UPCAST(PCIDevice, qdev, qdev);
+        *pdev = PCI_DEVICE(qdev);
         return 0;
     }
     return -EINVAL;
@@ -2019,3 +1989,18 @@ MemoryRegion *pci_address_space_io(PCIDevice *dev)
 {
     return dev->bus->address_space_io;
 }
+
+static TypeInfo pci_device_type_info = {
+    .name = TYPE_PCI_DEVICE,
+    .parent = TYPE_DEVICE,
+    .instance_size = sizeof(PCIDevice),
+    .abstract = true,
+    .class_size = sizeof(PCIDeviceClass),
+};
+
+static void pci_register_devices(void)
+{
+    type_register_static(&pci_device_type_info);
+}
+
+device_init(pci_register_devices);
diff --git a/hw/pci.h b/hw/pci.h
index 5501d95..09b2324 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -127,6 +127,46 @@ enum {
     QEMU_PCI_CAP_SERR = (1 << QEMU_PCI_CAP_SERR_BITNR),
 };
 
+#define TYPE_PCI_DEVICE "pci-device"
+#define PCI_DEVICE(obj) \
+     OBJECT_CHECK(PCIDevice, (obj), TYPE_PCI_DEVICE)
+#define PCI_DEVICE_CLASS(klass) \
+     OBJECT_CLASS_CHECK(PCIDeviceClass, (klass), TYPE_PCI_DEVICE)
+#define PCI_DEVICE_GET_CLASS(obj) \
+     OBJECT_GET_CLASS(PCIDeviceClass, (obj), TYPE_PCI_DEVICE)
+
+typedef struct PCIDeviceClass {
+    DeviceClass parent_class;
+
+    int (*init)(PCIDevice *dev);
+    PCIUnregisterFunc *exit;
+    PCIConfigReadFunc *config_read;
+    PCIConfigWriteFunc *config_write;
+
+    uint16_t vendor_id;
+    uint16_t device_id;
+    uint8_t revision;
+    uint16_t class_id;
+    uint16_t subsystem_vendor_id;       /* only for header type = 0 */
+    uint16_t subsystem_id;              /* only for header type = 0 */
+
+    /*
+     * pci-to-pci bridge or normal device.
+     * This doesn't mean pci host switch.
+     * When card bus bridge is supported, this would be enhanced.
+     */
+    int is_bridge;
+
+    /* pcie stuff */
+    int is_express;   /* is this device pci express? */
+
+    /* device isn't hot-pluggable */
+    int no_hotplug;
+
+    /* rom bar */
+    const char *romfile;
+} PCIDeviceClass;
+
 struct PCIDevice {
     DeviceState qdev;
     /* PCI config space */
@@ -196,11 +236,6 @@ struct PCIDevice {
     uint32_t rom_bar;
 };
 
-PCIDevice *pci_register_device(PCIBus *bus, const char *name,
-                               int instance_size, int devfn,
-                               PCIConfigReadFunc *config_read,
-                               PCIConfigWriteFunc *config_write);
-
 void pci_register_bar(PCIDevice *pci_dev, int region_num,
                       uint8_t attr, MemoryRegion *memory);
 pcibus_t pci_get_bar_addr(PCIDevice *pci_dev, int region_num);
@@ -429,40 +464,7 @@ pci_quad_test_and_set_mask(uint8_t *config, uint64_t mask)
     return val & mask;
 }
 
-typedef int (*pci_qdev_initfn)(PCIDevice *dev);
-typedef struct {
-    DeviceInfo qdev;
-    pci_qdev_initfn init;
-    PCIUnregisterFunc *exit;
-    PCIConfigReadFunc *config_read;
-    PCIConfigWriteFunc *config_write;
-
-    uint16_t vendor_id;
-    uint16_t device_id;
-    uint8_t revision;
-    uint16_t class_id;
-    uint16_t subsystem_vendor_id;       /* only for header type = 0 */
-    uint16_t subsystem_id;              /* only for header type = 0 */
-
-    /*
-     * pci-to-pci bridge or normal device.
-     * This doesn't mean pci host switch.
-     * When card bus bridge is supported, this would be enhanced.
-     */
-    int is_bridge;
-
-    /* pcie stuff */
-    int is_express;   /* is this device pci express? */
-
-    /* device isn't hot-pluggable */
-    int no_hotplug;
-
-    /* rom bar */
-    const char *romfile;
-} PCIDeviceInfo;
-
-void pci_qdev_register(PCIDeviceInfo *info);
-void pci_qdev_register_many(PCIDeviceInfo *info);
+void pci_qdev_register(DeviceInfo *info);
 
 PCIDevice *pci_create_multifunction(PCIBus *bus, int devfn, bool multifunction,
                                     const char *name);
diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
index 650d165..1ed4339 100644
--- a/hw/pci_bridge.c
+++ b/hw/pci_bridge.c
@@ -294,7 +294,7 @@ void pci_bridge_reset_reg(PCIDevice *dev)
 /* default reset function for PCI-to-PCI bridge */
 void pci_bridge_reset(DeviceState *qdev)
 {
-    PCIDevice *dev = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *dev = PCI_DEVICE(qdev);
     pci_bridge_reset_reg(dev);
 }
 
diff --git a/hw/pcie.c b/hw/pcie.c
index 5c9eb2f..7c92f19 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -203,7 +203,7 @@ static void pcie_cap_slot_event(PCIDevice *dev, PCIExpressHotPlugEvent event)
 static int pcie_cap_slot_hotplug(DeviceState *qdev,
                                  PCIDevice *pci_dev, PCIHotplugState state)
 {
-    PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *d = PCI_DEVICE(qdev);
     uint8_t *exp_cap = d->config + d->exp.exp_cap;
     uint16_t sltsta = pci_get_word(exp_cap + PCI_EXP_SLTSTA);
 
diff --git a/hw/pcnet-pci.c b/hw/pcnet-pci.c
index 4e164da..be3bd79 100644
--- a/hw/pcnet-pci.c
+++ b/hw/pcnet-pci.c
@@ -348,21 +348,30 @@ static void pci_reset(DeviceState *dev)
     pcnet_h_reset(&d->state);
 }
 
-static PCIDeviceInfo pcnet_info = {
-    .qdev.name  = "pcnet",
-    .qdev.size  = sizeof(PCIPCNetState),
-    .qdev.reset = pci_reset,
-    .qdev.vmsd  = &vmstate_pci_pcnet,
-    .init       = pci_pcnet_init,
-    .exit       = pci_pcnet_uninit,
-    .vendor_id  = PCI_VENDOR_ID_AMD,
-    .device_id  = PCI_DEVICE_ID_AMD_LANCE,
-    .revision   = 0x10,
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_NIC_PROPERTIES(PCIPCNetState, state.conf),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property pcnet_properties[] = {
+    DEFINE_NIC_PROPERTIES(PCIPCNetState, state.conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pcnet_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_pcnet_init;
+    k->exit = pci_pcnet_uninit;
+    k->vendor_id = PCI_VENDOR_ID_AMD;
+    k->device_id = PCI_DEVICE_ID_AMD_LANCE;
+    k->revision = 0x10;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo pcnet_info = {
+    .name = "pcnet",
+    .size = sizeof(PCIPCNetState),
+    .reset = pci_reset,
+    .vmsd = &vmstate_pci_pcnet,
+    .props = pcnet_properties,
+    .class_init = pcnet_class_init,
 };
 
 static void pci_pcnet_register_devices(void)
diff --git a/hw/piix4.c b/hw/piix4.c
index 130dfd1..88be535 100644
--- a/hw/piix4.c
+++ b/hw/piix4.c
@@ -102,18 +102,24 @@ int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
     return d->devfn;
 }
 
-static PCIDeviceInfo piix4_info = {
-    .qdev.name    = "PIIX4",
-    .qdev.desc    = "ISA bridge",
-    .qdev.size    = sizeof(PIIX4State),
-    .qdev.vmsd    = &vmstate_piix4,
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = piix4_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    /* 82371AB/EB/MB PIIX4 PCI-to-ISA bridge */
-    .device_id    = PCI_DEVICE_ID_INTEL_82371AB_0,
-    .class_id     = PCI_CLASS_BRIDGE_ISA,
+static void piix4_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = piix4_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371AB_0;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+}
+
+static DeviceInfo piix4_info = {
+    .name = "PIIX4",
+    .desc = "ISA bridge",
+    .size = sizeof(PIIX4State),
+    .vmsd = &vmstate_piix4,
+    .no_user = 1,
+    .class_init = piix4_class_init,
 };
 
 static void piix4_register(void)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 5cbeed5..787db4e 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -502,47 +502,68 @@ static int piix3_initfn(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo i440fx_info = {
-    .qdev.name    = "i440FX",
-    .qdev.desc    = "Host bridge",
-    .qdev.size    = sizeof(PCII440FXState),
-    .qdev.vmsd    = &vmstate_i440fx,
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = i440fx_initfn,
-    .config_write = i440fx_write_config,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82441,
-    .revision     = 0x02,
-    .class_id     = PCI_CLASS_BRIDGE_HOST,
+static void piix3_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug   = 1;
+    k->init         = piix3_initfn;
+    k->config_write = piix3_write_config;
+    k->vendor_id    = PCI_VENDOR_ID_INTEL;
+    k->device_id    = PCI_DEVICE_ID_INTEL_82371SB_0; // 82371SB PIIX3 PCI-to-ISA bridge (Step A1)
+    k->class_id     = PCI_CLASS_BRIDGE_ISA;
+}
+
+static DeviceInfo piix3_info = {
+    .name    = "PIIX3",
+    .desc    = "ISA bridge",
+    .size    = sizeof(PIIX3State),
+    .vmsd    = &vmstate_piix3,
+    .no_user = 1,
+    .class_init = piix3_class_init,
 };
 
-static PCIDeviceInfo piix3_info = {
-    .qdev.name    = "PIIX3",
-    .qdev.desc    = "ISA bridge",
-    .qdev.size    = sizeof(PIIX3State),
-    .qdev.vmsd    = &vmstate_piix3,
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = piix3_initfn,
-    .config_write = piix3_write_config,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371SB_0, // 82371SB PIIX3 PCI-to-ISA bridge (Step A1)
-    .class_id     = PCI_CLASS_BRIDGE_ISA,
+static void piix3_xen_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug   = 1;
+    k->init         = piix3_initfn;
+    k->config_write = piix3_write_config_xen;
+    k->vendor_id    = PCI_VENDOR_ID_INTEL;
+    k->device_id    = PCI_DEVICE_ID_INTEL_82371SB_0; // 82371SB PIIX3 PCI-to-ISA bridge (Step A1)
+    k->class_id     = PCI_CLASS_BRIDGE_ISA;
 };
 
-static PCIDeviceInfo piix3_xen_info = {
-    .qdev.name    = "PIIX3-xen",
-    .qdev.desc    = "ISA bridge",
-    .qdev.size    = sizeof(PIIX3State),
-    .qdev.vmsd    = &vmstate_piix3,
-    .qdev.no_user = 1,
-    .no_hotplug   = 1,
-    .init         = piix3_initfn,
-    .config_write = piix3_write_config_xen,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82371SB_0, // 82371SB PIIX3 PCI-to-ISA bridge (Step A1)
-    .class_id     = PCI_CLASS_BRIDGE_ISA,
+static DeviceInfo piix3_xen_info = {
+    .name    = "PIIX3-xen",
+    .desc    = "ISA bridge",
+    .size    = sizeof(PIIX3State),
+    .vmsd    = &vmstate_piix3,
+    .no_user = 1,
+    .class_init = piix3_xen_class_init,
+};
+
+static void i440fx_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = i440fx_initfn;
+    k->config_write = i440fx_write_config;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82441;
+    k->revision = 0x02;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo i440fx_info = {
+    .name = "i440FX",
+    .desc = "Host bridge",
+    .size = sizeof(PCII440FXState),
+    .vmsd = &vmstate_i440fx,
+    .no_user = 1,
+    .class_init = i440fx_class_init,
 };
 
 static SysBusDeviceInfo i440fx_pcihost_info = {
diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c
index 26de007..b38840e 100644
--- a/hw/ppc4xx_pci.c
+++ b/hw/ppc4xx_pci.c
@@ -366,13 +366,20 @@ static int ppc4xx_pcihost_initfn(SysBusDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo ppc4xx_host_bridge_info = {
-    .qdev.name    = "ppc4xx-host-bridge",
-    .qdev.desc    = "Host bridge",
-    .qdev.size    = sizeof(PCIDevice),
-    .vendor_id    = PCI_VENDOR_ID_IBM,
-    .device_id    = PCI_DEVICE_ID_IBM_440GX,
-    .class_id     = PCI_CLASS_BRIDGE_OTHER,
+static void ppc4xx_host_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->vendor_id    = PCI_VENDOR_ID_IBM;
+    k->device_id    = PCI_DEVICE_ID_IBM_440GX;
+    k->class_id     = PCI_CLASS_BRIDGE_OTHER;
+}
+
+static DeviceInfo ppc4xx_host_bridge_info = {
+    .name    = "ppc4xx-host-bridge",
+    .desc    = "Host bridge",
+    .size    = sizeof(PCIDevice),
+    .class_init = ppc4xx_host_bridge_class_init,
 };
 
 static SysBusDeviceInfo ppc4xx_pcihost_info = {
diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
index b606206..bc783bf 100644
--- a/hw/ppce500_pci.c
+++ b/hw/ppce500_pci.c
@@ -339,13 +339,20 @@ static int e500_pcihost_initfn(SysBusDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo e500_host_bridge_info = {
-    .qdev.name    = "e500-host-bridge",
-    .qdev.desc    = "Host bridge",
-    .qdev.size    = sizeof(PCIDevice),
-    .vendor_id    = PCI_VENDOR_ID_FREESCALE,
-    .device_id    = PCI_DEVICE_ID_MPC8533E,
-    .class_id     = PCI_CLASS_PROCESSOR_POWERPC,
+static void e500_host_bridge_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->vendor_id = PCI_VENDOR_ID_FREESCALE;
+    k->device_id = PCI_DEVICE_ID_MPC8533E;
+    k->class_id = PCI_CLASS_PROCESSOR_POWERPC;
+}
+
+static DeviceInfo e500_host_bridge_info = {
+    .name = "e500-host-bridge",
+    .desc = "Host bridge",
+    .size = sizeof(PCIDevice),
+    .class_init = e500_host_bridge_class_init,
 };
 
 static SysBusDeviceInfo e500_pcihost_info = {
diff --git a/hw/prep_pci.c b/hw/prep_pci.c
index 4961eed..4ff1049 100644
--- a/hw/prep_pci.c
+++ b/hw/prep_pci.c
@@ -134,21 +134,24 @@ static const VMStateDescription vmstate_raven = {
     },
 };
 
-static PCIDeviceInfo raven_info = {
-    .qdev.name = "raven",
-    .qdev.desc = "PReP Host Bridge - Motorola Raven",
-    .qdev.size = sizeof(RavenPCIState),
-    .qdev.vmsd = &vmstate_raven,
-    .qdev.no_user = 1,
-    .no_hotplug = 1,
-    .init = raven_init,
-    .vendor_id = PCI_VENDOR_ID_MOTOROLA,
-    .device_id = PCI_DEVICE_ID_MOTOROLA_RAVEN,
-    .revision = 0x00,
-    .class_id = PCI_CLASS_BRIDGE_HOST,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_END_OF_LIST()
-    },
+static void raven_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = raven_init;
+    k->vendor_id = PCI_VENDOR_ID_MOTOROLA;
+    k->device_id = PCI_DEVICE_ID_MOTOROLA_RAVEN;
+    k->revision = 0x00;
+    k->class_id = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo raven_info = {
+    .name = "raven",
+    .desc = "PReP Host Bridge - Motorola Raven",
+    .size = sizeof(RavenPCIState),
+    .vmsd = &vmstate_raven,
+    .no_user = 1,
+    .class_init = raven_class_init,
 };
 
 static SysBusDeviceInfo raven_pcihost_info = {
diff --git a/hw/qdev.c b/hw/qdev.c
index 81996bb..a8c24de 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -119,6 +119,7 @@ bool qdev_exists(const char *name)
 {
     return !!qdev_find_info(NULL, name);
 }
+
 static void qdev_property_add_legacy(DeviceState *dev, Property *prop,
                                      Error **errp);
 
diff --git a/hw/qxl.c b/hw/qxl.c
index 2a716bf..7aa7d19 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1827,32 +1827,46 @@ static Property qxl_properties[] = {
         DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo qxl_primary_info = {
-    .qdev.name    = "qxl-vga",
-    .qdev.desc    = "Spice QXL GPU (primary, vga compatible)",
-    .qdev.size    = sizeof(PCIQXLDevice),
-    .qdev.reset   = qxl_reset_handler,
-    .qdev.vmsd    = &qxl_vmstate,
-    .no_hotplug   = 1,
-    .init         = qxl_init_primary,
-    .romfile      = "vgabios-qxl.bin",
-    .vendor_id    = REDHAT_PCI_VENDOR_ID,
-    .device_id    = QXL_DEVICE_ID_STABLE,
-    .class_id     = PCI_CLASS_DISPLAY_VGA,
-    .qdev.props   = qxl_properties,
+static void qxl_primary_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = qxl_init_primary;
+    k->romfile = "vgabios-qxl.bin";
+    k->vendor_id = REDHAT_PCI_VENDOR_ID;
+    k->device_id = QXL_DEVICE_ID_STABLE;
+    k->class_id = PCI_CLASS_DISPLAY_VGA;
+}
+
+static DeviceInfo qxl_primary_info = {
+    .name = "qxl-vga",
+    .desc = "Spice QXL GPU (primary, vga compatible)",
+    .size = sizeof(PCIQXLDevice),
+    .reset = qxl_reset_handler,
+    .vmsd = &qxl_vmstate,
+    .props = qxl_properties,
+    .class_init = qxl_primary_class_init,
 };
 
-static PCIDeviceInfo qxl_secondary_info = {
-    .qdev.name    = "qxl",
-    .qdev.desc    = "Spice QXL GPU (secondary)",
-    .qdev.size    = sizeof(PCIQXLDevice),
-    .qdev.reset   = qxl_reset_handler,
-    .qdev.vmsd    = &qxl_vmstate,
-    .init         = qxl_init_secondary,
-    .vendor_id    = REDHAT_PCI_VENDOR_ID,
-    .device_id    = QXL_DEVICE_ID_STABLE,
-    .class_id     = PCI_CLASS_DISPLAY_OTHER,
-    .qdev.props   = qxl_properties,
+static void qxl_secondary_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = qxl_init_secondary;
+    k->vendor_id = REDHAT_PCI_VENDOR_ID;
+    k->device_id = QXL_DEVICE_ID_STABLE;
+    k->class_id = PCI_CLASS_DISPLAY_OTHER;
+}
+
+static DeviceInfo qxl_secondary_info = {
+    .name = "qxl",
+    .desc = "Spice QXL GPU (secondary)",
+    .size = sizeof(PCIQXLDevice),
+    .reset = qxl_reset_handler,
+    .vmsd = &qxl_vmstate,
+    .props = qxl_properties,
+    .class_init = qxl_secondary_class_init,
 };
 
 static void qxl_register(void)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index 2b55c7f..15dec9b 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -3494,22 +3494,31 @@ static int pci_rtl8139_init(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo rtl8139_info = {
-    .qdev.name  = "rtl8139",
-    .qdev.size  = sizeof(RTL8139State),
-    .qdev.reset = rtl8139_reset,
-    .qdev.vmsd  = &vmstate_rtl8139,
-    .init       = pci_rtl8139_init,
-    .exit       = pci_rtl8139_uninit,
-    .romfile    = "pxe-rtl8139.rom",
-    .vendor_id  = PCI_VENDOR_ID_REALTEK,
-    .device_id  = PCI_DEVICE_ID_REALTEK_8139,
-    .revision   = RTL8139_PCI_REVID, /* >=0x20 is for 8139C+ */
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_NIC_PROPERTIES(RTL8139State, conf),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property rtl8139_properties[] = {
+    DEFINE_NIC_PROPERTIES(RTL8139State, conf),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void rtl8139_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_rtl8139_init;
+    k->exit = pci_rtl8139_uninit;
+    k->romfile = "pxe-rtl8139.rom";
+    k->vendor_id = PCI_VENDOR_ID_REALTEK;
+    k->device_id = PCI_DEVICE_ID_REALTEK_8139;
+    k->revision = RTL8139_PCI_REVID; /* >=0x20 is for 8139C+ */
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo rtl8139_info = {
+    .name = "rtl8139",
+    .size = sizeof(RTL8139State),
+    .reset = rtl8139_reset,
+    .vmsd = &vmstate_rtl8139,
+    .props = rtl8139_properties,
+    .class_init = rtl8139_class_init,
 };
 
 static void rtl8139_register_devices(void)
diff --git a/hw/sh_pci.c b/hw/sh_pci.c
index d4d028d..baeab9e 100644
--- a/hw/sh_pci.c
+++ b/hw/sh_pci.c
@@ -147,12 +147,19 @@ static int sh_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo sh_pci_host_info = {
-    .qdev.name = "sh_pci_host",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = sh_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_HITACHI,
-    .device_id = PCI_DEVICE_ID_HITACHI_SH7751R,
+static void sh_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = sh_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_HITACHI;
+    k->device_id = PCI_DEVICE_ID_HITACHI_SH7751R;
+}
+
+static DeviceInfo sh_pci_host_info = {
+    .name = "sh_pci_host",
+    .size = sizeof(PCIDevice),
+    .class_init = sh_pci_host_class_init,
 };
 
 static void sh_pci_register_devices(void)
diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
index 2c95faa..8a39f8f 100644
--- a/hw/spapr_pci.c
+++ b/hw/spapr_pci.c
@@ -214,10 +214,17 @@ static int spapr_main_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo spapr_main_pci_host_info = {
-    .qdev.name = "spapr-pci-host-bridge",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = spapr_main_pci_host_init,
+static void spapr_main_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = spapr_main_pci_host_init;
+}
+
+static DeviceInfo spapr_main_pci_host_info = {
+    .name = "spapr-pci-host-bridge",
+    .size = sizeof(PCIDevice),
+    .class_init = spapr_main_pci_host_class_init,
 };
 
 static void spapr_register_devices(void)
diff --git a/hw/sun4u.c b/hw/sun4u.c
index 2dc3d04..6d9fdf6 100644
--- a/hw/sun4u.c
+++ b/hw/sun4u.c
@@ -562,14 +562,21 @@ pci_ebus_init1(PCIDevice *pci_dev)
     return 0;
 }
 
-static PCIDeviceInfo ebus_info = {
-    .qdev.name = "ebus",
-    .qdev.size = sizeof(EbusState),
-    .init = pci_ebus_init1,
-    .vendor_id = PCI_VENDOR_ID_SUN,
-    .device_id = PCI_DEVICE_ID_SUN_EBUS,
-    .revision = 0x01,
-    .class_id = PCI_CLASS_BRIDGE_OTHER,
+static void ebus_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = pci_ebus_init1;
+    k->vendor_id = PCI_VENDOR_ID_SUN;
+    k->device_id = PCI_DEVICE_ID_SUN_EBUS;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_BRIDGE_OTHER;
+}
+
+static DeviceInfo ebus_info = {
+    .name = "ebus",
+    .size = sizeof(EbusState),
+    .class_init = ebus_class_init,
 };
 
 static void pci_ebus_register(void)
diff --git a/hw/unin_pci.c b/hw/unin_pci.c
index 6a10013..6a148e0 100644
--- a/hw/unin_pci.c
+++ b/hw/unin_pci.c
@@ -339,44 +339,72 @@ static int unin_internal_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo unin_main_pci_host_info = {
-    .qdev.name = "uni-north-pci",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = unin_main_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .device_id = PCI_DEVICE_ID_APPLE_UNI_N_PCI,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void unin_main_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = unin_main_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_UNI_N_PCI;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo unin_main_pci_host_info = {
+    .name = "uni-north-pci",
+    .size = sizeof(PCIDevice),
+    .class_init = unin_main_pci_host_class_init,
 };
 
-static PCIDeviceInfo u3_agp_pci_host_info = {
-    .qdev.name = "u3-agp",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = u3_agp_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .device_id = PCI_DEVICE_ID_APPLE_U3_AGP,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void u3_agp_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = u3_agp_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_U3_AGP;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo u3_agp_pci_host_info = {
+    .name = "u3-agp",
+    .size = sizeof(PCIDevice),
+    .class_init = u3_agp_pci_host_class_init,
 };
 
-static PCIDeviceInfo unin_agp_pci_host_info = {
-    .qdev.name = "uni-north-agp",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = unin_agp_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .device_id = PCI_DEVICE_ID_APPLE_UNI_N_AGP,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void unin_agp_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = unin_agp_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_UNI_N_AGP;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo unin_agp_pci_host_info = {
+    .name = "uni-north-agp",
+    .size = sizeof(PCIDevice),
+    .class_init = unin_agp_pci_host_class_init,
 };
 
-static PCIDeviceInfo unin_internal_pci_host_info = {
-    .qdev.name = "uni-north-internal-pci",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = unin_internal_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_APPLE,
-    .device_id = PCI_DEVICE_ID_APPLE_UNI_N_I_PCI,
-    .revision  = 0x00,
-    .class_id  = PCI_CLASS_BRIDGE_HOST,
+static void unin_internal_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init      = unin_internal_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_UNI_N_I_PCI;
+    k->revision  = 0x00;
+    k->class_id  = PCI_CLASS_BRIDGE_HOST;
+}
+
+static DeviceInfo unin_internal_pci_host_info = {
+    .name = "uni-north-internal-pci",
+    .size = sizeof(PCIDevice),
+    .class_init = unin_internal_pci_host_class_init,
 };
 
 static SysBusDeviceInfo sysbus_unin_pci_host_info = {
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index 63fc3c7..8baff1d 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -2263,28 +2263,42 @@ static Property ehci_properties[] = {
     DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo ehci_info = {
-    .qdev.name    = "usb-ehci",
-    .qdev.size    = sizeof(EHCIState),
-    .qdev.vmsd    = &vmstate_ehci,
-    .init         = usb_ehci_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801D, /* ich4 */
-    .revision     = 0x10,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = ehci_properties,
+static void ehci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_ehci_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801D; /* ich4 */
+    k->revision = 0x10;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ehci_info = {
+    .name = "usb-ehci",
+    .size = sizeof(EHCIState),
+    .vmsd = &vmstate_ehci,
+    .props = ehci_properties,
+    .class_init = ehci_class_init,
 };
 
-static PCIDeviceInfo ich9_ehci_info = {
-    .qdev.name    = "ich9-usb-ehci1",
-    .qdev.size    = sizeof(EHCIState),
-    .qdev.vmsd    = &vmstate_ehci,
-    .init         = usb_ehci_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801I_EHCI1,
-    .revision     = 0x03,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = ehci_properties,
+static void ich9_ehci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_ehci_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801I_EHCI1;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ich9_ehci_info = {
+    .name = "ich9-usb-ehci1",
+    .size = sizeof(EHCIState),
+    .vmsd = &vmstate_ehci,
+    .props = ehci_properties,
+    .class_init = ich9_ehci_class_init,
 };
 
 static int usb_ehci_initfn(PCIDevice *dev)
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index 2df6a6e..b9b37d5 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -1836,20 +1836,29 @@ static int ohci_init_pxa(SysBusDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo ohci_pci_info = {
-    .qdev.name    = "pci-ohci",
-    .qdev.desc    = "Apple USB Controller",
-    .qdev.size    = sizeof(OHCIPCIState),
-    .init         = usb_ohci_initfn_pci,
-    .vendor_id    = PCI_VENDOR_ID_APPLE,
-    .device_id    = PCI_DEVICE_ID_APPLE_IPID_USB,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = (Property[]) {
-        DEFINE_PROP_STRING("masterbus", OHCIPCIState, masterbus),
-        DEFINE_PROP_UINT32("num-ports", OHCIPCIState, num_ports, 3),
-        DEFINE_PROP_UINT32("firstport", OHCIPCIState, firstport, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    },
+static Property ohci_pci_properties[] = {
+    DEFINE_PROP_STRING("masterbus", OHCIPCIState, masterbus),
+    DEFINE_PROP_UINT32("num-ports", OHCIPCIState, num_ports, 3),
+    DEFINE_PROP_UINT32("firstport", OHCIPCIState, firstport, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ohci_pci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_ohci_initfn_pci;
+    k->vendor_id = PCI_VENDOR_ID_APPLE;
+    k->device_id = PCI_DEVICE_ID_APPLE_IPID_USB;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ohci_pci_info = {
+    .name = "pci-ohci",
+    .desc = "Apple USB Controller",
+    .size = sizeof(OHCIPCIState),
+    .props = ohci_pci_properties,
+    .class_init = ohci_pci_class_init,
 };
 
 static SysBusDeviceInfo ohci_sysbus_info = {
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 1821063..e20d7c4 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1192,79 +1192,121 @@ static Property uhci_properties[] = {
     DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo piix3_uhci_info = {
-        .qdev.name    = "piix3-usb-uhci",
-        .qdev.size    = sizeof(UHCIState),
-        .qdev.vmsd    = &vmstate_uhci,
-        .init         = usb_uhci_common_initfn,
-        .exit         = usb_uhci_exit,
-        .vendor_id    = PCI_VENDOR_ID_INTEL,
-        .device_id    = PCI_DEVICE_ID_INTEL_82371SB_2,
-        .revision     = 0x01,
-        .class_id     = PCI_CLASS_SERIAL_USB,
-        .qdev.props   = uhci_properties,
+static void piix3_uhci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->exit = usb_uhci_exit;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371SB_2;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo piix3_uhci_info = {
+    .name = "piix3-usb-uhci",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = piix3_uhci_class_init,
 };
 
-static PCIDeviceInfo piix4_uhci_info = {
-        .qdev.name    = "piix4-usb-uhci",
-        .qdev.size    = sizeof(UHCIState),
-        .qdev.vmsd    = &vmstate_uhci,
-        .init         = usb_uhci_common_initfn,
-        .exit         = usb_uhci_exit,
-        .vendor_id    = PCI_VENDOR_ID_INTEL,
-        .device_id    = PCI_DEVICE_ID_INTEL_82371AB_2,
-        .revision     = 0x01,
-        .class_id     = PCI_CLASS_SERIAL_USB,
-        .qdev.props   = uhci_properties,
+static void piix4_uhci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->exit = usb_uhci_exit;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82371AB_2;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo piix4_uhci_info = {
+    .name = "piix4-usb-uhci",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = piix4_uhci_class_init,
 };
 
-static PCIDeviceInfo vt82c686b_uhci_info = {
-    .qdev.name    = "vt82c686b-usb-uhci",
-    .qdev.size    = sizeof(UHCIState),
-    .qdev.vmsd    = &vmstate_uhci,
-    .init         = usb_uhci_vt82c686b_initfn,
-    .exit         = usb_uhci_exit,
-    .vendor_id    = PCI_VENDOR_ID_VIA,
-    .device_id    = PCI_DEVICE_ID_VIA_UHCI,
-    .revision     = 0x01,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = uhci_properties,
+static void vt82c686b_uhci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_vt82c686b_initfn;
+    k->exit = usb_uhci_exit;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_UHCI;
+    k->revision = 0x01;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo vt82c686b_uhci_info = {
+    .name = "vt82c686b-usb-uhci",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = vt82c686b_uhci_class_init,
 };
 
-static PCIDeviceInfo ich9_uhci1_info = {
-    .qdev.name    = "ich9-usb-uhci1",
-    .qdev.size    = sizeof(UHCIState),
-    .qdev.vmsd    = &vmstate_uhci,
-    .init         = usb_uhci_common_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801I_UHCI1,
-    .revision     = 0x03,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = uhci_properties,
+static void ich9_uhci1_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI1;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ich9_uhci1_info = {
+    .name = "ich9-usb-uhci1",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = ich9_uhci1_class_init,
 };
 
-static PCIDeviceInfo ich9_uhci2_info = {
-    .qdev.name    = "ich9-usb-uhci2",
-    .qdev.size    = sizeof(UHCIState),
-    .qdev.vmsd    = &vmstate_uhci,
-    .init         = usb_uhci_common_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801I_UHCI2,
-    .revision     = 0x03,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = uhci_properties,
+static void ich9_uhci2_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI2;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ich9_uhci2_info = {
+    .name = "ich9-usb-uhci2",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = ich9_uhci2_class_init,
 };
 
-static PCIDeviceInfo ich9_uhci3_info = {
-    .qdev.name    = "ich9-usb-uhci3",
-    .qdev.size    = sizeof(UHCIState),
-    .qdev.vmsd    = &vmstate_uhci,
-    .init         = usb_uhci_common_initfn,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_82801I_UHCI3,
-    .revision     = 0x03,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .qdev.props   = uhci_properties,
+static void ich9_uhci3_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = usb_uhci_common_initfn;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_82801I_UHCI3;
+    k->revision = 0x03;
+    k->class_id = PCI_CLASS_SERIAL_USB;
+}
+
+static DeviceInfo ich9_uhci3_info = {
+    .name = "ich9-usb-uhci3",
+    .size = sizeof(UHCIState),
+    .vmsd = &vmstate_uhci,
+    .props = uhci_properties,
+    .class_init = ich9_uhci3_class_init,
 };
 
 static void uhci_register(void)
diff --git a/hw/usb-xhci.c b/hw/usb-xhci.c
index 95bf010..fba2de3 100644
--- a/hw/usb-xhci.c
+++ b/hw/usb-xhci.c
@@ -2724,19 +2724,26 @@ static const VMStateDescription vmstate_xhci = {
     .unmigratable = 1,
 };
 
-static PCIDeviceInfo xhci_info = {
-    .qdev.name    = "nec-usb-xhci",
-    .qdev.alias   = "xhci",
-    .qdev.size    = sizeof(XHCIState),
-    .qdev.vmsd    = &vmstate_xhci,
-    .init         = usb_xhci_initfn,
-    .vendor_id    = PCI_VENDOR_ID_NEC,
-    .device_id    = PCI_DEVICE_ID_NEC_UPD720200,
-    .class_id     = PCI_CLASS_SERIAL_USB,
-    .revision     = 0x03,
-    .is_express   = 1,
-    .config_write = xhci_write_config,
-    .qdev.props   = (Property[]) {
+static void xhci_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init         = usb_xhci_initfn;
+    k->vendor_id    = PCI_VENDOR_ID_NEC;
+    k->device_id    = PCI_DEVICE_ID_NEC_UPD720200;
+    k->class_id     = PCI_CLASS_SERIAL_USB;
+    k->revision     = 0x03;
+    k->is_express   = 1;
+    k->config_write = xhci_write_config;
+}
+
+static DeviceInfo xhci_info = {
+    .name    = "nec-usb-xhci",
+    .alias   = "xhci",
+    .size    = sizeof(XHCIState),
+    .vmsd    = &vmstate_xhci,
+    .class_init   = xhci_class_init,
+    .props   = (Property[]) {
         DEFINE_PROP_UINT32("msi", XHCIState, msi, 0),
         DEFINE_PROP_END_OF_LIST(),
     }
diff --git a/hw/versatile_pci.c b/hw/versatile_pci.c
index a285f7f..0eb7d32 100644
--- a/hw/versatile_pci.c
+++ b/hw/versatile_pci.c
@@ -109,14 +109,20 @@ static int versatile_pci_host_init(PCIDevice *d)
     return 0;
 }
 
-static PCIDeviceInfo versatile_pci_host_info = {
-    .qdev.name = "versatile_pci_host",
-    .qdev.size = sizeof(PCIDevice),
-    .init      = versatile_pci_host_init,
-    .vendor_id = PCI_VENDOR_ID_XILINX,
-    /* Both boards have the same device ID.  Oh well.  */
-    .device_id = PCI_DEVICE_ID_XILINX_XC2VP30,
-    .class_id  = PCI_CLASS_PROCESSOR_CO,
+static void versatile_pci_host_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = versatile_pci_host_init;
+    k->vendor_id = PCI_VENDOR_ID_XILINX;
+    k->device_id = PCI_DEVICE_ID_XILINX_XC2VP30;
+    k->class_id = PCI_CLASS_PROCESSOR_CO;
+}
+
+static DeviceInfo versatile_pci_host_info = {
+    .name = "versatile_pci_host",
+    .size = sizeof(PCIDevice),
+    .class_init = versatile_pci_host_class_init,
 };
 
 static void versatile_pci_register_devices(void)
diff --git a/hw/vga-pci.c b/hw/vga-pci.c
index a75dbf3..ef9f8a5 100644
--- a/hw/vga-pci.c
+++ b/hw/vga-pci.c
@@ -75,18 +75,23 @@ DeviceState *pci_vga_init(PCIBus *bus)
     return &pci_create_simple(bus, -1, "VGA")->qdev;
 }
 
-static PCIDeviceInfo vga_info = {
-    .qdev.name    = "VGA",
-    .qdev.size    = sizeof(PCIVGAState),
-    .qdev.vmsd    = &vmstate_vga_pci,
-    .no_hotplug   = 1,
-    .init         = pci_vga_initfn,
-    .romfile      = "vgabios-stdvga.bin",
+static void vga_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_vga_initfn;
+    k->romfile = "vgabios-stdvga.bin";
+    k->vendor_id = PCI_VENDOR_ID_QEMU;
+    k->device_id = PCI_DEVICE_ID_QEMU_VGA;
+    k->class_id = PCI_CLASS_DISPLAY_VGA;
+}
 
-    /* dummy VGA (same as Bochs ID) */
-    .vendor_id    = PCI_VENDOR_ID_QEMU,
-    .device_id    = PCI_DEVICE_ID_QEMU_VGA,
-    .class_id     = PCI_CLASS_DISPLAY_VGA,
+static DeviceInfo vga_info = {
+    .name = "VGA",
+    .size = sizeof(PCIVGAState),
+    .vmsd = &vmstate_vga_pci,
+    .class_init = vga_class_init,
 };
 
 static void vga_register(void)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 72b53af..126fb08 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -806,88 +806,124 @@ static int virtio_balloon_exit_pci(PCIDevice *pci_dev)
     return virtio_exit_pci(pci_dev);
 }
 
-static PCIDeviceInfo virtio_blk_info = {
-    .qdev.name = "virtio-blk-pci",
-    .qdev.alias = "virtio-blk",
-    .qdev.size = sizeof(VirtIOPCIProxy),
-    .init      = virtio_blk_init_pci,
-    .exit      = virtio_blk_exit_pci,
-    .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id = PCI_DEVICE_ID_VIRTIO_BLOCK,
-    .revision  = VIRTIO_PCI_ABI_VERSION,
-    .class_id  = PCI_CLASS_STORAGE_SCSI,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
-        DEFINE_BLOCK_PROPERTIES(VirtIOPCIProxy, block),
-        DEFINE_PROP_STRING("serial", VirtIOPCIProxy, block_serial),
-        DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-        DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
-        DEFINE_VIRTIO_BLK_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static Property virtio_blk_properties[] = {
+    DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
+    DEFINE_BLOCK_PROPERTIES(VirtIOPCIProxy, block),
+    DEFINE_PROP_STRING("serial", VirtIOPCIProxy, block_serial),
+    DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
+    DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 2),
+    DEFINE_VIRTIO_BLK_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo virtio_net_info = {
-    .qdev.name  = "virtio-net-pci",
-    .qdev.alias = "virtio-net",
-    .qdev.size  = sizeof(VirtIOPCIProxy),
-    .init       = virtio_net_init_pci,
-    .exit       = virtio_net_exit_pci,
-    .romfile    = "pxe-virtio.rom",
-    .vendor_id  = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id  = PCI_DEVICE_ID_VIRTIO_NET,
-    .revision   = VIRTIO_PCI_ABI_VERSION,
-    .class_id   = PCI_CLASS_NETWORK_ETHERNET,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, false),
-        DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 3),
-        DEFINE_VIRTIO_NET_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_NIC_PROPERTIES(VirtIOPCIProxy, nic),
-        DEFINE_PROP_UINT32("x-txtimer", VirtIOPCIProxy, net.txtimer, TX_TIMER_INTERVAL),
-        DEFINE_PROP_INT32("x-txburst", VirtIOPCIProxy, net.txburst, TX_BURST),
-        DEFINE_PROP_STRING("tx", VirtIOPCIProxy, net.tx),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static void virtio_blk_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_blk_init_pci;
+    k->exit = virtio_blk_exit_pci;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = PCI_DEVICE_ID_VIRTIO_BLOCK;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = PCI_CLASS_STORAGE_SCSI;
+}
+
+static DeviceInfo virtio_blk_info = {
+    .name = "virtio-blk-pci",
+    .alias = "virtio-blk",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_blk_properties,
+    .reset = virtio_pci_reset,
+    .class_init = virtio_blk_class_init,
+};
+
+static Property virtio_net_properties[] = {
+    DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, false),
+    DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, 3),
+    DEFINE_VIRTIO_NET_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_NIC_PROPERTIES(VirtIOPCIProxy, nic),
+    DEFINE_PROP_UINT32("x-txtimer", VirtIOPCIProxy, net.txtimer, TX_TIMER_INTERVAL),
+    DEFINE_PROP_INT32("x-txburst", VirtIOPCIProxy, net.txburst, TX_BURST),
+    DEFINE_PROP_STRING("tx", VirtIOPCIProxy, net.tx),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_net_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_net_init_pci;
+    k->exit = virtio_net_exit_pci;
+    k->romfile = "pxe-virtio.rom";
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = PCI_DEVICE_ID_VIRTIO_NET;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = PCI_CLASS_NETWORK_ETHERNET;
+}
+
+static DeviceInfo virtio_net_info = {
+    .name = "virtio-net-pci",
+    .alias = "virtio-net",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_net_properties,
+    .reset = virtio_pci_reset,
+    .class_init = virtio_net_class_init,
 };
 
-static PCIDeviceInfo virtio_serial_info = {
-    .qdev.name = "virtio-serial-pci",
-    .qdev.alias = "virtio-serial",
-    .qdev.size = sizeof(VirtIOPCIProxy),
-    .init      = virtio_serial_init_pci,
-    .exit      = virtio_serial_exit_pci,
-    .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id = PCI_DEVICE_ID_VIRTIO_CONSOLE,
-    .revision  = VIRTIO_PCI_ABI_VERSION,
-    .class_id  = PCI_CLASS_COMMUNICATION_OTHER,
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
-        DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, DEV_NVECTORS_UNSPECIFIED),
-        DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
-        DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy, serial.max_virtserial_ports, 31),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static Property virtio_serial_properties[] = {
+    DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags, VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
+    DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors, DEV_NVECTORS_UNSPECIFIED),
+    DEFINE_PROP_HEX32("class", VirtIOPCIProxy, class_code, 0),
+    DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_PROP_UINT32("max_ports", VirtIOPCIProxy, serial.max_virtserial_ports, 31),
+    DEFINE_PROP_END_OF_LIST(),
 };
 
-static PCIDeviceInfo virtio_balloon_info = {
-    .qdev.name = "virtio-balloon-pci",
-    .qdev.alias = "virtio-balloon",
-    .qdev.size = sizeof(VirtIOPCIProxy),
-    .init      = virtio_balloon_init_pci,
-    .exit      = virtio_balloon_exit_pci,
-    .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
-    .device_id = PCI_DEVICE_ID_VIRTIO_BALLOON,
-    .revision  = VIRTIO_PCI_ABI_VERSION,
-    .class_id  = PCI_CLASS_MEMORY_RAM,
-    .qdev.props = (Property[]) {
-        DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
-        DEFINE_PROP_END_OF_LIST(),
-    },
-    .qdev.reset = virtio_pci_reset,
+static void virtio_serial_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_serial_init_pci;
+    k->exit = virtio_serial_exit_pci;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = PCI_DEVICE_ID_VIRTIO_CONSOLE;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = PCI_CLASS_COMMUNICATION_OTHER;
+}
+
+static DeviceInfo virtio_serial_info = {
+    .name = "virtio-serial-pci",
+    .alias = "virtio-serial",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_serial_properties,
+    .reset = virtio_pci_reset,
+    .class_init = virtio_serial_class_init,
+};
+
+static Property virtio_balloon_properties[] = {
+    DEFINE_VIRTIO_COMMON_FEATURES(VirtIOPCIProxy, host_features),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_balloon_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = virtio_balloon_init_pci;
+    k->exit = virtio_balloon_exit_pci;
+    k->vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET;
+    k->device_id = PCI_DEVICE_ID_VIRTIO_BALLOON;
+    k->revision = VIRTIO_PCI_ABI_VERSION;
+    k->class_id = PCI_CLASS_MEMORY_RAM;
+}
+
+static DeviceInfo virtio_balloon_info = {
+    .name = "virtio-balloon-pci",
+    .alias = "virtio-balloon",
+    .size = sizeof(VirtIOPCIProxy),
+    .props = virtio_balloon_properties,
+    .reset = virtio_pci_reset,
+    .class_init = virtio_balloon_class_init,
 };
 
 static void virtio_pci_register_devices(void)
diff --git a/hw/vmware_vga.c b/hw/vmware_vga.c
index b1885c3..e7bbf7c 100644
--- a/hw/vmware_vga.c
+++ b/hw/vmware_vga.c
@@ -1199,20 +1199,26 @@ static int pci_vmsvga_initfn(PCIDevice *dev)
     return 0;
 }
 
-static PCIDeviceInfo vmsvga_info = {
-    .qdev.name    = "vmware-svga",
-    .qdev.size    = sizeof(struct pci_vmsvga_state_s),
-    .qdev.vmsd    = &vmstate_vmware_vga,
-    .qdev.reset   = vmsvga_reset,
-    .no_hotplug   = 1,
-    .init         = pci_vmsvga_initfn,
-    .romfile      = "vgabios-vmware.bin",
-
-    .vendor_id    =  PCI_VENDOR_ID_VMWARE,
-    .device_id    = SVGA_PCI_DEVICE_ID,
-    .class_id     = PCI_CLASS_DISPLAY_VGA,
-    .subsystem_vendor_id = PCI_VENDOR_ID_VMWARE,
-    .subsystem_id = SVGA_PCI_DEVICE_ID,
+static void vmsvga_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->no_hotplug = 1;
+    k->init = pci_vmsvga_initfn;
+    k->romfile = "vgabios-vmware.bin";
+    k->vendor_id = PCI_VENDOR_ID_VMWARE;
+    k->device_id = SVGA_PCI_DEVICE_ID;
+    k->class_id = PCI_CLASS_DISPLAY_VGA;
+    k->subsystem_vendor_id = PCI_VENDOR_ID_VMWARE;
+    k->subsystem_id = SVGA_PCI_DEVICE_ID;
+}
+
+static DeviceInfo vmsvga_info = {
+    .name = "vmware-svga",
+    .size = sizeof(struct pci_vmsvga_state_s),
+    .vmsd = &vmstate_vmware_vga,
+    .reset = vmsvga_reset,
+    .class_init = vmsvga_class_init,
 };
 
 static void vmsvga_register(void)
diff --git a/hw/vt82c686.c b/hw/vt82c686.c
index 7fb88a5..72be4fd 100644
--- a/hw/vt82c686.c
+++ b/hw/vt82c686.c
@@ -346,15 +346,22 @@ void vt82c686b_ac97_init(PCIBus *bus, int devfn)
     qdev_init_nofail(&dev->qdev);
 }
 
-static PCIDeviceInfo via_ac97_info = {
-    .qdev.name          = "VT82C686B_AC97",
-    .qdev.desc          = "AC97",
-    .qdev.size          = sizeof(VT686AC97State),
-    .init               = vt82c686b_ac97_initfn,
-    .vendor_id          = PCI_VENDOR_ID_VIA,
-    .device_id          = PCI_DEVICE_ID_VIA_AC97,
-    .revision           = 0x50,
-    .class_id           = PCI_CLASS_MULTIMEDIA_AUDIO,
+static void via_ac97_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_ac97_initfn;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_AC97;
+    k->revision = 0x50;
+    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
+}
+
+static DeviceInfo via_ac97_info = {
+    .name = "VT82C686B_AC97",
+    .desc = "AC97",
+    .size = sizeof(VT686AC97State),
+    .class_init = via_ac97_class_init,
 };
 
 static void vt82c686b_ac97_register(void)
@@ -385,15 +392,22 @@ void vt82c686b_mc97_init(PCIBus *bus, int devfn)
     qdev_init_nofail(&dev->qdev);
 }
 
-static PCIDeviceInfo via_mc97_info = {
-    .qdev.name          = "VT82C686B_MC97",
-    .qdev.desc          = "MC97",
-    .qdev.size          = sizeof(VT686MC97State),
-    .init               = vt82c686b_mc97_initfn,
-    .vendor_id          = PCI_VENDOR_ID_VIA,
-    .device_id          = PCI_DEVICE_ID_VIA_MC97,
-    .class_id           = PCI_CLASS_COMMUNICATION_OTHER,
-    .revision           = 0x30,
+static void via_mc97_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_mc97_initfn;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_MC97;
+    k->class_id = PCI_CLASS_COMMUNICATION_OTHER;
+    k->revision = 0x30;
+}
+
+static DeviceInfo via_mc97_info = {
+    .name = "VT82C686B_MC97",
+    .desc = "MC97",
+    .size = sizeof(VT686MC97State),
+    .class_init = via_mc97_class_init,
 };
 
 static void vt82c686b_mc97_register(void)
@@ -451,21 +465,30 @@ i2c_bus *vt82c686b_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
     return s->smb.smbus;
 }
 
-static PCIDeviceInfo via_pm_info = {
-    .qdev.name          = "VT82C686B_PM",
-    .qdev.desc          = "PM",
-    .qdev.size          = sizeof(VT686PMState),
-    .qdev.vmsd          = &vmstate_acpi,
-    .init               = vt82c686b_pm_initfn,
-    .config_write       = pm_write_config,
-    .vendor_id          = PCI_VENDOR_ID_VIA,
-    .device_id          = PCI_DEVICE_ID_VIA_ACPI,
-    .class_id           = PCI_CLASS_BRIDGE_OTHER,
-    .revision           = 0x40,
-    .qdev.props         = (Property[]) {
-        DEFINE_PROP_UINT32("smb_io_base", VT686PMState, smb_io_base, 0),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property via_pm_properties[] = {
+    DEFINE_PROP_UINT32("smb_io_base", VT686PMState, smb_io_base, 0),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void via_pm_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_pm_initfn;
+    k->config_write = pm_write_config;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_ACPI;
+    k->class_id = PCI_CLASS_BRIDGE_OTHER;
+    k->revision = 0x40;
+}
+
+static DeviceInfo via_pm_info = {
+    .name = "VT82C686B_PM",
+    .desc = "PM",
+    .size = sizeof(VT686PMState),
+    .vmsd = &vmstate_acpi,
+    .props = via_pm_properties,
+    .class_init = via_pm_class_init,
 };
 
 static void vt82c686b_pm_register(void)
@@ -519,18 +542,25 @@ ISABus *vt82c686b_init(PCIBus *bus, int devfn)
     return DO_UPCAST(ISABus, qbus, qdev_get_child_bus(&d->qdev, "isa.0"));
 }
 
-static PCIDeviceInfo via_info = {
-    .qdev.name    = "VT82C686B",
-    .qdev.desc    = "ISA bridge",
-    .qdev.size    = sizeof(VT82C686BState),
-    .qdev.vmsd    = &vmstate_via,
-    .qdev.no_user = 1,
-    .init         = vt82c686b_initfn,
-    .config_write = vt82c686b_write_config,
-    .vendor_id    = PCI_VENDOR_ID_VIA,
-    .device_id    = PCI_DEVICE_ID_VIA_ISA_BRIDGE,
-    .class_id     = PCI_CLASS_BRIDGE_ISA,
-    .revision     = 0x40,
+static void via_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = vt82c686b_initfn;
+    k->config_write = vt82c686b_write_config;
+    k->vendor_id = PCI_VENDOR_ID_VIA;
+    k->device_id = PCI_DEVICE_ID_VIA_ISA_BRIDGE;
+    k->class_id = PCI_CLASS_BRIDGE_ISA;
+    k->revision = 0x40;
+}
+
+static DeviceInfo via_info = {
+    .name = "VT82C686B",
+    .desc = "ISA bridge",
+    .size = sizeof(VT82C686BState),
+    .vmsd = &vmstate_via,
+    .no_user = 1,
+    .class_init = via_class_init,
 };
 
 static void vt82c686b_register(void)
diff --git a/hw/wdt_i6300esb.c b/hw/wdt_i6300esb.c
index 20d8673..a6ceff8 100644
--- a/hw/wdt_i6300esb.c
+++ b/hw/wdt_i6300esb.c
@@ -143,7 +143,7 @@ static void i6300esb_disable_timer(I6300State *d)
 
 static void i6300esb_reset(DeviceState *dev)
 {
-    PCIDevice *pdev = DO_UPCAST(PCIDevice, qdev, dev);
+    PCIDevice *pdev = PCI_DEVICE(dev);
     I6300State *d = DO_UPCAST(I6300State, dev, pdev);
 
     i6300esb_debug("I6300State = %p\n", d);
@@ -425,18 +425,25 @@ static WatchdogTimerModel model = {
     .wdt_description = "Intel 6300ESB",
 };
 
-static PCIDeviceInfo i6300esb_info = {
-    .qdev.name    = "i6300esb",
-    .qdev.size    = sizeof(I6300State),
-    .qdev.vmsd    = &vmstate_i6300esb,
-    .qdev.reset   = i6300esb_reset,
-    .config_read  = i6300esb_config_read,
-    .config_write = i6300esb_config_write,
-    .init         = i6300esb_init,
-    .exit         = i6300esb_exit,
-    .vendor_id    = PCI_VENDOR_ID_INTEL,
-    .device_id    = PCI_DEVICE_ID_INTEL_ESB_9,
-    .class_id     = PCI_CLASS_SYSTEM_OTHER,
+static void i6300esb_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->config_read = i6300esb_config_read;
+    k->config_write = i6300esb_config_write;
+    k->init = i6300esb_init;
+    k->exit = i6300esb_exit;
+    k->vendor_id = PCI_VENDOR_ID_INTEL;
+    k->device_id = PCI_DEVICE_ID_INTEL_ESB_9;
+    k->class_id = PCI_CLASS_SYSTEM_OTHER;
+}
+
+static DeviceInfo i6300esb_info = {
+    .name = "i6300esb",
+    .size = sizeof(I6300State),
+    .vmsd = &vmstate_i6300esb,
+    .reset = i6300esb_reset,
+    .class_init = i6300esb_class_init,
 };
 
 static void i6300esb_register_devices(void)
diff --git a/hw/xen_platform.c b/hw/xen_platform.c
index e62eaef..40687fb 100644
--- a/hw/xen_platform.c
+++ b/hw/xen_platform.c
@@ -372,20 +372,26 @@ static void platform_reset(DeviceState *dev)
     platform_fixed_ioport_reset(s);
 }
 
-static PCIDeviceInfo xen_platform_info = {
-    .init = xen_platform_initfn,
-    .qdev.name = "xen-platform",
-    .qdev.desc = "XEN platform pci device",
-    .qdev.size = sizeof(PCIXenPlatformState),
-    .qdev.vmsd = &vmstate_xen_platform,
-    .qdev.reset = platform_reset,
-
-    .vendor_id    =  PCI_VENDOR_ID_XEN,
-    .device_id    = PCI_DEVICE_ID_XEN_PLATFORM,
-    .class_id     = PCI_CLASS_OTHERS << 8 | 0x80,
-    .subsystem_vendor_id = PCI_VENDOR_ID_XEN,
-    .subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM,
-    .revision = 1,
+static void xen_platform_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->init = xen_platform_initfn;
+    k->vendor_id = PCI_VENDOR_ID_XEN;
+    k->device_id = PCI_DEVICE_ID_XEN_PLATFORM;
+    k->class_id = PCI_CLASS_OTHERS << 8 | 0x80;
+    k->subsystem_vendor_id = PCI_VENDOR_ID_XEN;
+    k->subsystem_id = PCI_DEVICE_ID_XEN_PLATFORM;
+    k->revision = 1;
+}
+
+static DeviceInfo xen_platform_info = {
+    .name = "xen-platform",
+    .desc = "XEN platform pci device",
+    .size = sizeof(PCIXenPlatformState),
+    .vmsd = &vmstate_xen_platform,
+    .reset = platform_reset,
+    .class_init = xen_platform_class_init,
 };
 
 static void xen_platform_register(void)
diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c
index d3c387d..6d625cb 100644
--- a/hw/xio3130_downstream.c
+++ b/hw/xio3130_downstream.c
@@ -47,7 +47,7 @@ static void xio3130_downstream_write_config(PCIDevice *d, uint32_t address,
 
 static void xio3130_downstream_reset(DeviceState *qdev)
 {
-    PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *d = PCI_DEVICE(qdev);
     msi_reset(d);
     pcie_cap_deverr_reset(d);
     pcie_cap_slot_reset(d);
@@ -167,31 +167,38 @@ static const VMStateDescription vmstate_xio3130_downstream = {
     }
 };
 
-static PCIDeviceInfo xio3130_downstream_info = {
-    .qdev.name = "xio3130-downstream",
-    .qdev.desc = "TI X3130 Downstream Port of PCI Express Switch",
-    .qdev.size = sizeof(PCIESlot),
-    .qdev.reset = xio3130_downstream_reset,
-    .qdev.vmsd = &vmstate_xio3130_downstream,
-
-    .is_express = 1,
-    .is_bridge = 1,
-    .config_write = xio3130_downstream_write_config,
-    .init = xio3130_downstream_initfn,
-    .exit = xio3130_downstream_exitfn,
-    .vendor_id = PCI_VENDOR_ID_TI,
-    .device_id = PCI_DEVICE_ID_TI_XIO3130D,
-    .revision = XIO3130_REVISION,
-
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
-        DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
-        DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
-        DEFINE_PROP_UINT16("aer_log_max", PCIESlot,
-                           port.br.dev.exp.aer_log.log_max,
-                           PCIE_AER_LOG_MAX_DEFAULT),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property xio3130_downstream_properties[] = {
+    DEFINE_PROP_UINT8("port", PCIESlot, port.port, 0),
+    DEFINE_PROP_UINT8("chassis", PCIESlot, chassis, 0),
+    DEFINE_PROP_UINT16("slot", PCIESlot, slot, 0),
+    DEFINE_PROP_UINT16("aer_log_max", PCIESlot,
+    port.br.dev.exp.aer_log.log_max,
+    PCIE_AER_LOG_MAX_DEFAULT),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xio3130_downstream_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->is_express = 1;
+    k->is_bridge = 1;
+    k->config_write = xio3130_downstream_write_config;
+    k->init = xio3130_downstream_initfn;
+    k->exit = xio3130_downstream_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_TI;
+    k->device_id = PCI_DEVICE_ID_TI_XIO3130D;
+    k->revision = XIO3130_REVISION;
+}
+
+static DeviceInfo xio3130_downstream_info = {
+    .name = "xio3130-downstream",
+    .desc = "TI X3130 Downstream Port of PCI Express Switch",
+    .size = sizeof(PCIESlot),
+    .reset = xio3130_downstream_reset,
+    .vmsd = &vmstate_xio3130_downstream,
+    .props = xio3130_downstream_properties,
+    .class_init = xio3130_downstream_class_init,
 };
 
 static void xio3130_downstream_register(void)
diff --git a/hw/xio3130_upstream.c b/hw/xio3130_upstream.c
index 8283695..ec4c5e3 100644
--- a/hw/xio3130_upstream.c
+++ b/hw/xio3130_upstream.c
@@ -46,7 +46,7 @@ static void xio3130_upstream_write_config(PCIDevice *d, uint32_t address,
 
 static void xio3130_upstream_reset(DeviceState *qdev)
 {
-    PCIDevice *d = DO_UPCAST(PCIDevice, qdev, qdev);
+    PCIDevice *d = PCI_DEVICE(qdev);
     msi_reset(d);
     pci_bridge_reset(qdev);
     pcie_cap_deverr_reset(d);
@@ -144,28 +144,35 @@ static const VMStateDescription vmstate_xio3130_upstream = {
     }
 };
 
-static PCIDeviceInfo xio3130_upstream_info = {
-    .qdev.name = "x3130-upstream",
-    .qdev.desc = "TI X3130 Upstream Port of PCI Express Switch",
-    .qdev.size = sizeof(PCIEPort),
-    .qdev.reset = xio3130_upstream_reset,
-    .qdev.vmsd = &vmstate_xio3130_upstream,
-
-    .is_express = 1,
-    .is_bridge = 1,
-    .config_write = xio3130_upstream_write_config,
-    .init = xio3130_upstream_initfn,
-    .exit = xio3130_upstream_exitfn,
-    .vendor_id = PCI_VENDOR_ID_TI,
-    .device_id = PCI_DEVICE_ID_TI_XIO3130U,
-    .revision = XIO3130_REVISION,
-
-    .qdev.props = (Property[]) {
-        DEFINE_PROP_UINT8("port", PCIEPort, port, 0),
-        DEFINE_PROP_UINT16("aer_log_max", PCIEPort, br.dev.exp.aer_log.log_max,
-                           PCIE_AER_LOG_MAX_DEFAULT),
-        DEFINE_PROP_END_OF_LIST(),
-    }
+static Property xio3130_upstream_properties[] = {
+    DEFINE_PROP_UINT8("port", PCIEPort, port, 0),
+    DEFINE_PROP_UINT16("aer_log_max", PCIEPort, br.dev.exp.aer_log.log_max,
+    PCIE_AER_LOG_MAX_DEFAULT),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xio3130_upstream_class_init(ObjectClass *klass, void *data)
+{
+    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+    k->is_express = 1;
+    k->is_bridge = 1;
+    k->config_write = xio3130_upstream_write_config;
+    k->init = xio3130_upstream_initfn;
+    k->exit = xio3130_upstream_exitfn;
+    k->vendor_id = PCI_VENDOR_ID_TI;
+    k->device_id = PCI_DEVICE_ID_TI_XIO3130U;
+    k->revision = XIO3130_REVISION;
+}
+
+static DeviceInfo xio3130_upstream_info = {
+    .name = "x3130-upstream",
+    .desc = "TI X3130 Upstream Port of PCI Express Switch",
+    .size = sizeof(PCIEPort),
+    .reset = xio3130_upstream_reset,
+    .vmsd = &vmstate_xio3130_upstream,
+    .props = xio3130_upstream_properties,
+    .class_init = xio3130_upstream_class_init,
 };
 
 static void xio3130_upstream_register(void)
-- 
1.7.4.1


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 21:21:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 21: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 1RpnnD-0005l9-23; Tue, 24 Jan 2012 21:20:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpnnB-0005kt-4w
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 21:20:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327440027!12417777!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21306 invoked from network); 24 Jan 2012 21:20:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 21:20:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208";a="10260005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 21:20: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;
	Tue, 24 Jan 2012 21:20:31 +0000
Message-ID: <1327440030.17019.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Tue, 24 Jan 2012 21:20:30 +0000
In-Reply-To: <1327429159.27858.140661027476141@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327429159.27858.140661027476141@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 18:19 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> On Tue, Jan 24, 2012, at 10:05 AM, erin.balid@inoutbox.com wrote:
> > I can't figure out how to get xl to output to a xend-debug.log (xm does,
> > as expected).
> 
> 
> Reading http://www.gossamer-threads.com/lists/xen/devel/198734, and
> checking "-vvv" console output
> 
> xl destroy test
> xl -vvv create /etc/xen/vm/test.cfg
[...]
> Does that help at all?

I'm afraid not -- the failure is not at this level.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 21:21:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 21: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 1RpnnD-0005l9-23; Tue, 24 Jan 2012 21:20:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpnnB-0005kt-4w
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 21:20:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327440027!12417777!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21306 invoked from network); 24 Jan 2012 21:20:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 21:20:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208";a="10260005"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 21:20: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;
	Tue, 24 Jan 2012 21:20:31 +0000
Message-ID: <1327440030.17019.17.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Tue, 24 Jan 2012 21:20:30 +0000
In-Reply-To: <1327429159.27858.140661027476141@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327429159.27858.140661027476141@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 18:19 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> On Tue, Jan 24, 2012, at 10:05 AM, erin.balid@inoutbox.com wrote:
> > I can't figure out how to get xl to output to a xend-debug.log (xm does,
> > as expected).
> 
> 
> Reading http://www.gossamer-threads.com/lists/xen/devel/198734, and
> checking "-vvv" console output
> 
> xl destroy test
> xl -vvv create /etc/xen/vm/test.cfg
[...]
> Does that help at all?

I'm afraid not -- the failure is not at this level.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 21:21:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 21: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 1RpnnC-0005l2-NL; Tue, 24 Jan 2012 21:20: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 1RpnnB-0005ks-02
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 21:20:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327440027!12417777!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21293 invoked from network); 24 Jan 2012 21:20:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 21:20:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208";a="10260004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 21:20:27 +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, 24 Jan 2012 21:20:27 +0000
Message-ID: <1327440026.17019.16.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Tue, 24 Jan 2012 21:20:26 +0000
In-Reply-To: <1327428329.24310.140661027473797@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 18:05 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> On Tue, Jan 24, 2012, at 09:10 AM, erin.balid@inoutbox.com wrote:
> > > At this point I'm afraid my only suggesting is to drop "echo made it to
> > > XXX" breadcrumbs throughout the script and try to narrow down to the
> > > line which exits.
> > 
> > I'll give that a try and report.
> 
> I can't figure out how to get xl to output to a xend-debug.log (xm does,
> as expected).

They should be going to /var/log/xen/xen-hotplug.

> Using the same log redirection you mentioned before
> 
> edit /etc/xen/scripts/vif-bridge
> 	#!/bin/bash
> +       exec 1>>/tmp/vif-bridge.log
> +       exec 2>&1
> +       echo "`date`: Running $0 $*"
> ...
> +       ## TEST ##
> +       echo "made it to 001"
> 
> 	dir=$(dirname "$0")
> 	. "$dir/vif-common.sh"
> 
> +       ## TEST ##
> +       echo "made it to 002"
> 
> 
> 	domu=$(xenstore_read_default "$XENBUS_PATH/domain" "")
> 	if [ -z "$domu" ]
> 	then
> 	    log debug "No device details in $XENBUS_PATH, exiting."

So, presumably either the xenstore_read_default is failing or domu is
zero length and the script is explicitly bailing here.

However I do not see anything like this anywhere in the hotplug script
shipped with Xen. Either this is a local modification or something done
by your distribution, in which case you should contact them.

What does this node contain under xend?

What does your script go on to do with this domu value?

Perhaps given that xend writes this domain node so perhaps xl should
too. In a few cases (vkb, vfb, console) it does seem to add it but in
others (disk, nic, etc) etc does not. To be honest I don't really see
what purpose it serves to put the domain's name in each device's backend
subdirectory.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 21:21:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 21: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 1RpnnC-0005l2-NL; Tue, 24 Jan 2012 21:20: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 1RpnnB-0005ks-02
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 21:20:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327440027!12417777!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDA5Mg==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21293 invoked from network); 24 Jan 2012 21:20:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	24 Jan 2012 21:20:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208";a="10260004"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 21:20:27 +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, 24 Jan 2012 21:20:27 +0000
Message-ID: <1327440026.17019.16.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Tue, 24 Jan 2012 21:20:26 +0000
In-Reply-To: <1327428329.24310.140661027473797@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 18:05 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> On Tue, Jan 24, 2012, at 09:10 AM, erin.balid@inoutbox.com wrote:
> > > At this point I'm afraid my only suggesting is to drop "echo made it to
> > > XXX" breadcrumbs throughout the script and try to narrow down to the
> > > line which exits.
> > 
> > I'll give that a try and report.
> 
> I can't figure out how to get xl to output to a xend-debug.log (xm does,
> as expected).

They should be going to /var/log/xen/xen-hotplug.

> Using the same log redirection you mentioned before
> 
> edit /etc/xen/scripts/vif-bridge
> 	#!/bin/bash
> +       exec 1>>/tmp/vif-bridge.log
> +       exec 2>&1
> +       echo "`date`: Running $0 $*"
> ...
> +       ## TEST ##
> +       echo "made it to 001"
> 
> 	dir=$(dirname "$0")
> 	. "$dir/vif-common.sh"
> 
> +       ## TEST ##
> +       echo "made it to 002"
> 
> 
> 	domu=$(xenstore_read_default "$XENBUS_PATH/domain" "")
> 	if [ -z "$domu" ]
> 	then
> 	    log debug "No device details in $XENBUS_PATH, exiting."

So, presumably either the xenstore_read_default is failing or domu is
zero length and the script is explicitly bailing here.

However I do not see anything like this anywhere in the hotplug script
shipped with Xen. Either this is a local modification or something done
by your distribution, in which case you should contact them.

What does this node contain under xend?

What does your script go on to do with this domu value?

Perhaps given that xend writes this domain node so perhaps xl should
too. In a few cases (vkb, vfb, console) it does seem to add it but in
others (disk, nic, etc) etc does not. To be honest I don't really see
what purpose it serves to put the domain's name in each device's backend
subdirectory.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 21:31:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 21:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpnwv-00063S-5v; Tue, 24 Jan 2012 21:30:41 +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 1Rpnwt-00063K-Ph
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 21:30:40 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327440633!11811545!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 17326 invoked from network); 24 Jan 2012 21:30:33 -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; 24 Jan 2012 21:30:33 -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=QxHlvG6waxkINzMbySKj9inw5U6BZ+wDCq4C6zuXviU=; b=oHlx/69
	10b3QMeBvE1hqp1Iua2g80D9+3R1hPmNnUPWoAe9Kby3Z6+Ph/v8I1nvYrV0uSd6
	yfsIiRF/1BxOThUUblPnG8OHMjbKq9gS34/vrAYbUiEn1ZQ+MlfxQJytun/likXN
	YOAFJ4PyPIRyvPCSc6rJvGVSe8GW01DQDNhg=
Received: (qmail 14448 invoked from network); 24 Jan 2012 22:30:32 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.144.237)
	by mail.zeus06.de with ESMTPA; 24 Jan 2012 22:30:32 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 3D4CC2C55B;
	Tue, 24 Jan 2012 22:32:33 +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 Rnqrhg-JtHpM; Tue, 24 Jan 2012 22:32:31 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 391702C55A;
	Tue, 24 Jan 2012 22:32:31 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Tue, 24 Jan 2012 22:32:31 +0100
Mime-Version: 1.0
In-Reply-To: <20120123223213.GA31929@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acza32TRh4JrvATkT4aIRp14X9eGvw==
Message-Id: <zarafa.4f1f236f.5da2.1dcf22913c361536@uhura.space.zz>
Cc: =?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Jan_Beulich?= <JBeulich@suse.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

Konrad, =


I implemented the patch into a 3.1.2 but the patched function doesn't seem =
to be called (I set debug=3D1 for the module).
I think it's only for video capturing devices.

But I greped around and found a vmalloc_32 in drivers/media/common/saa7146_=
core.c line 182 function saa7146_vmalloc_build_pgtable
which is included in module saa7146.ko. This would be the DVB chip. Maybe y=
ou can rework the patch so that we can just test what
you intended to test.

Consequently, the patch you did so far doesn't change the load.

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: Montag, 23. Januar 2012 23:32
An: Konrad Rzeszutek Wilk
Cc: Sander Eikelenboom; xen-devel; Jan Beulich
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com=
> wrote:
> > > The issue as I understand is that the DVB drivers allocate their =

> > > buffers from 0->4GB most (all the time?) so they never have to do bou=
nce-buffering.
> > > =

> > > While the pv-ops one ends up quite frequently doing the =

> > > bounce-buffering, which implies that the DVB drivers end up =

> > > allocating their buffers above the 4GB.
> > > This means we end up spending some CPU time (in the guest) copying =

> > > the memory from >4GB to 0-4GB region (And vice-versa).
> > =

> > This reminds me of something (not sure what XenoLinux you use for
> > comparison) - how are they allocating that memory? Not vmalloc_32()
> =

> I was using the 2.6.18, then the one I saw on Google for Gentoo, and =

> now I am going to look at the 2.6.38 from OpenSuSE.
> =

> > by chance (I remember having seen numerous uses under - iirc - =

> > drivers/media/)?
> > =

> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do =

> > what their (driver) callers might expect in a PV guest (including =

> > the contiguity assumption for the latter, recalling that you earlier =

> > said you were able to see the problem after several guest starts), =

> > and I had put into our kernels an adjustment to make vmalloc_32() =

> > actually behave as expected.
> =

> Aaah.. The plot thickens! Let me look in the sources! Thanks for the =

> pointer.

Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32 =
and then performs PCI DMA operations on the allocted vmalloc_32 area.

So I cobbled up the attached patch (hadn't actually tested it and sadly won=
't until next week) which removes the call to vmalloc_32 and instead sets u=
p DMA allocated set of pages.

If that fixes it for you that is awesome, but if it breaks please send me y=
our logs.

Cheers,
Konrad
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/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 Jan 24 21:31:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 21:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpnwv-00063S-5v; Tue, 24 Jan 2012 21:30:41 +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 1Rpnwt-00063K-Ph
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 21:30:40 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327440633!11811545!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 17326 invoked from network); 24 Jan 2012 21:30:33 -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; 24 Jan 2012 21:30:33 -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=QxHlvG6waxkINzMbySKj9inw5U6BZ+wDCq4C6zuXviU=; b=oHlx/69
	10b3QMeBvE1hqp1Iua2g80D9+3R1hPmNnUPWoAe9Kby3Z6+Ph/v8I1nvYrV0uSd6
	yfsIiRF/1BxOThUUblPnG8OHMjbKq9gS34/vrAYbUiEn1ZQ+MlfxQJytun/likXN
	YOAFJ4PyPIRyvPCSc6rJvGVSe8GW01DQDNhg=
Received: (qmail 14448 invoked from network); 24 Jan 2012 22:30:32 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.144.237)
	by mail.zeus06.de with ESMTPA; 24 Jan 2012 22:30:32 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 3D4CC2C55B;
	Tue, 24 Jan 2012 22:32:33 +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 Rnqrhg-JtHpM; Tue, 24 Jan 2012 22:32:31 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 391702C55A;
	Tue, 24 Jan 2012 22:32:31 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Tue, 24 Jan 2012 22:32:31 +0100
Mime-Version: 1.0
In-Reply-To: <20120123223213.GA31929@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: Acza32TRh4JrvATkT4aIRp14X9eGvw==
Message-Id: <zarafa.4f1f236f.5da2.1dcf22913c361536@uhura.space.zz>
Cc: =?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Jan_Beulich?= <JBeulich@suse.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

Konrad, =


I implemented the patch into a 3.1.2 but the patched function doesn't seem =
to be called (I set debug=3D1 for the module).
I think it's only for video capturing devices.

But I greped around and found a vmalloc_32 in drivers/media/common/saa7146_=
core.c line 182 function saa7146_vmalloc_build_pgtable
which is included in module saa7146.ko. This would be the DVB chip. Maybe y=
ou can rework the patch so that we can just test what
you intended to test.

Consequently, the patch you did so far doesn't change the load.

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: Montag, 23. Januar 2012 23:32
An: Konrad Rzeszutek Wilk
Cc: Sander Eikelenboom; xen-devel; Jan Beulich
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com=
> wrote:
> > > The issue as I understand is that the DVB drivers allocate their =

> > > buffers from 0->4GB most (all the time?) so they never have to do bou=
nce-buffering.
> > > =

> > > While the pv-ops one ends up quite frequently doing the =

> > > bounce-buffering, which implies that the DVB drivers end up =

> > > allocating their buffers above the 4GB.
> > > This means we end up spending some CPU time (in the guest) copying =

> > > the memory from >4GB to 0-4GB region (And vice-versa).
> > =

> > This reminds me of something (not sure what XenoLinux you use for
> > comparison) - how are they allocating that memory? Not vmalloc_32()
> =

> I was using the 2.6.18, then the one I saw on Google for Gentoo, and =

> now I am going to look at the 2.6.38 from OpenSuSE.
> =

> > by chance (I remember having seen numerous uses under - iirc - =

> > drivers/media/)?
> > =

> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do =

> > what their (driver) callers might expect in a PV guest (including =

> > the contiguity assumption for the latter, recalling that you earlier =

> > said you were able to see the problem after several guest starts), =

> > and I had put into our kernels an adjustment to make vmalloc_32() =

> > actually behave as expected.
> =

> Aaah.. The plot thickens! Let me look in the sources! Thanks for the =

> pointer.

Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32 =
and then performs PCI DMA operations on the allocted vmalloc_32 area.

So I cobbled up the attached patch (hadn't actually tested it and sadly won=
't until next week) which removes the call to vmalloc_32 and instead sets u=
p DMA allocated set of pages.

If that fixes it for you that is awesome, but if it breaks please send me y=
our logs.

Cheers,
Konrad
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/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 Jan 24 21:44:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 21:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpo9u-0006E6-Ej; Tue, 24 Jan 2012 21:44:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpo9s-0006E1-OF
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 21:44:05 +0000
Received: from [85.158.138.51:6004] by server-9.bemta-3.messagelabs.com id
	6F/D6-31168-3262F1F4; Tue, 24 Jan 2012 21:44:03 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327441442!10497207!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3516 invoked from network); 24 Jan 2012 21:44:03 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 21:44:03 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8B1DF21272
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 16:44:02 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute2.internal (MEProxy); Tue, 24 Jan 2012 16:44:02 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	NwPTRcvnWkRNg+xJ2jc905etl1k=; b=H4x764Aj6lNCkKfkGmwKkwJz6f8/m+M5
	crQDSh6k/IqmAH307xAKFU1hrXh9pU8fm6eP6I45mHp/aNU2NraukOvNU+K5rzaU
	9Xm90OiPg/jy+evMI9dY5rV7lZZQRfxh+8nLlNDNYe6f+zwKQk/EYcvoJaW3t1P7
	UpsGyvHz720=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=NwPTRcvnWkRNg+xJ2jc905etl1k=; b=HqK
	n+vm3zKhHinsX3JWwYRLQQe+JNPvHkLbkZfudMtJw1odh2PQy7U1+If9YTgUjtPt
	VVx5kv3t8vWm8KuSNwCo3AQzAIDftjR0JB9wd+BPbSWXuin/0b/YLt5gnN/mkpsi
	0Zun3fQ3PYe5499XfPzSm3BtzGwCEoyO5Cmnd5ok=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 527C9A00186; Tue, 24 Jan 2012 16:44:02 -0500 (EST)
Message-Id: <1327441442.19932.140661027559101@webmail.messagingengine.com>
X-Sasl-Enc: O0488799/BUSe2nd51wzavDh3eaHcAwlYlMDKaDdDBDL 1327441442
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <1327440026.17019.16.camel@dagon.hellion.org.uk>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><1327318076.24561.63.camel@zakaz.uk.xensource.com><1327332514.25697.140661026919117@webmail.messagingengine.com><1327415184.24561.182.camel@zakaz.uk.xensource.com><1327420611.19936.140661027415609@webmail.messagingengine.com><1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327440026.17019.16.camel@dagon.hellion.org.uk>
Date: Tue, 24 Jan 2012 13:44:02 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

On Tue, Jan 24, 2012, at 09:20 PM, Ian Campbell wrote:
> > I can't figure out how to get xl to output to a xend-debug.log (xm does,
> > as expected).
> 
> They should be going to /var/log/xen/xen-hotplug.

Not a peep in there.  Not even a there, there.

 xl create test.cfg

 ls -al /var/log/xen/xen-hotplug
  ls: cannot access /var/log/xen/xen-hotplug: No such file or directory

> So, presumably either the xenstore_read_default is failing or domu is
> zero length and the script is explicitly bailing here.
> 
> However I do not see anything like this anywhere in the hotplug script
> shipped with Xen. Either this is a local modification

I haven't made any local modifications.  At least not intentionally.

Here's the vif-bridge script ==> http://pastebin.com/9nHESsqS

> or something done by your distribution

It's opensuse.

> in which case you should contact them.

I already have.  Well, I tried.  Both on their mailing list
(opensuse-virtual), and cc'ing this thread to one of their developers
seemingly active on this mailing list.

So far the only reponses have been - there - from someone on Fedora16
seeing the same problem, and - here - from non-suse types, such as
yourself, trying to help.  Other than asking for their help, I don't
know how to convince them to help.  I can only work with the assistance
of folks that'll talk to me about the problem.

> What does this node contain under xend?

I don't understand the question.  Is there some specific detail I can
give you ?  Is it the value of 'domu' you're after?

> What does your script go on to do with this domu value?

Does the script pastebin above answer that for you?

> Perhaps given that xend writes this domain node so perhaps xl should
> too. In a few cases (vkb, vfb, console) it does seem to add it but in
> others (disk, nic, etc) etc does not. To be honest I don't really see
> what purpose it serves to put the domain's name in each device's backend
> subdirectory.

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 21:44:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 21:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpo9u-0006E6-Ej; Tue, 24 Jan 2012 21:44:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpo9s-0006E1-OF
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 21:44:05 +0000
Received: from [85.158.138.51:6004] by server-9.bemta-3.messagelabs.com id
	6F/D6-31168-3262F1F4; Tue, 24 Jan 2012 21:44:03 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327441442!10497207!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDAwNjA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3516 invoked from network); 24 Jan 2012 21:44:03 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-8.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 24 Jan 2012 21:44:03 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8B1DF21272
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 16:44:02 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute2.internal (MEProxy); Tue, 24 Jan 2012 16:44:02 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	NwPTRcvnWkRNg+xJ2jc905etl1k=; b=H4x764Aj6lNCkKfkGmwKkwJz6f8/m+M5
	crQDSh6k/IqmAH307xAKFU1hrXh9pU8fm6eP6I45mHp/aNU2NraukOvNU+K5rzaU
	9Xm90OiPg/jy+evMI9dY5rV7lZZQRfxh+8nLlNDNYe6f+zwKQk/EYcvoJaW3t1P7
	UpsGyvHz720=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=NwPTRcvnWkRNg+xJ2jc905etl1k=; b=HqK
	n+vm3zKhHinsX3JWwYRLQQe+JNPvHkLbkZfudMtJw1odh2PQy7U1+If9YTgUjtPt
	VVx5kv3t8vWm8KuSNwCo3AQzAIDftjR0JB9wd+BPbSWXuin/0b/YLt5gnN/mkpsi
	0Zun3fQ3PYe5499XfPzSm3BtzGwCEoyO5Cmnd5ok=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 527C9A00186; Tue, 24 Jan 2012 16:44:02 -0500 (EST)
Message-Id: <1327441442.19932.140661027559101@webmail.messagingengine.com>
X-Sasl-Enc: O0488799/BUSe2nd51wzavDh3eaHcAwlYlMDKaDdDBDL 1327441442
From: erin.balid@inoutbox.com
To: Ian Campbell <Ian.Campbell@citrix.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <1327440026.17019.16.camel@dagon.hellion.org.uk>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><1327318076.24561.63.camel@zakaz.uk.xensource.com><1327332514.25697.140661026919117@webmail.messagingengine.com><1327415184.24561.182.camel@zakaz.uk.xensource.com><1327420611.19936.140661027415609@webmail.messagingengine.com><1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327440026.17019.16.camel@dagon.hellion.org.uk>
Date: Tue, 24 Jan 2012 13:44:02 -0800
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.

On Tue, Jan 24, 2012, at 09:20 PM, Ian Campbell wrote:
> > I can't figure out how to get xl to output to a xend-debug.log (xm does,
> > as expected).
> 
> They should be going to /var/log/xen/xen-hotplug.

Not a peep in there.  Not even a there, there.

 xl create test.cfg

 ls -al /var/log/xen/xen-hotplug
  ls: cannot access /var/log/xen/xen-hotplug: No such file or directory

> So, presumably either the xenstore_read_default is failing or domu is
> zero length and the script is explicitly bailing here.
> 
> However I do not see anything like this anywhere in the hotplug script
> shipped with Xen. Either this is a local modification

I haven't made any local modifications.  At least not intentionally.

Here's the vif-bridge script ==> http://pastebin.com/9nHESsqS

> or something done by your distribution

It's opensuse.

> in which case you should contact them.

I already have.  Well, I tried.  Both on their mailing list
(opensuse-virtual), and cc'ing this thread to one of their developers
seemingly active on this mailing list.

So far the only reponses have been - there - from someone on Fedora16
seeing the same problem, and - here - from non-suse types, such as
yourself, trying to help.  Other than asking for their help, I don't
know how to convince them to help.  I can only work with the assistance
of folks that'll talk to me about the problem.

> What does this node contain under xend?

I don't understand the question.  Is there some specific detail I can
give you ?  Is it the value of 'domu' you're after?

> What does your script go on to do with this domu value?

Does the script pastebin above answer that for you?

> Perhaps given that xend writes this domain node so perhaps xl should
> too. In a few cases (vkb, vfb, console) it does seem to add it but in
> others (disk, nic, etc) etc does not. To be honest I don't really see
> what purpose it serves to put the domain's name in each device's backend
> subdirectory.

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 24 22:35:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 22: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 1RpoxJ-00079A-GM; Tue, 24 Jan 2012 22:35: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 1RpoxH-000795-3H
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 22:35:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327444499!12188330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 937 invoked from network); 24 Jan 2012 22:34:59 -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;
	24 Jan 2012 22:34:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208";a="10260917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 22:34: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, 24 Jan 2012 22:34: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 1Rpox8-0002uj-T5;
	Tue, 24 Jan 2012 22:34:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rpox8-0007u8-S5;
	Tue, 24 Jan 2012 22:34:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11584-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Jan 2012 22:34:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11584: 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 11584 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11584/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11574

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a2a8089b1ffb
baseline version:
 xen                  370924e204dc

------------------------------------------------------------
People who touched revisions under test:
  Doug Magee <djmagee@mageenet.net>
  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>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@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


Not pushing.

------------------------------------------------------------
changeset:   24562:a2a8089b1ffb
tag:         tip
user:        Tim Deegan <tim@xen.org>
date:        Tue Jan 24 16:46:17 2012 +0000
    
    SVM: Plumb NPT error-code bits into nested-fault access_X arguments.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24561:4cd3560aec0b
user:        Doug Magee <djmagee@mageenet.net>
date:        Tue Jan 24 15:36:19 2012 +0000
    
    libxl: rename is_assigned to is_pcidev_in_array
    
    All this function does is check to see if a device is in an array of
    pcidevs passed by the caller.  The function name can be misleading if
    ever used to check against a list of devices other than those assigned
    to a domain.
    
    Signed-off-by: Doug Magee <djmagee@mageenet.net>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24560:b7936bee33bf
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Tue Jan 24 15:33:36 2012 +0000
    
    xl: Add missing trigger for the xl trigger cmd.
    
    Add s3resume trigger in the usage of the xl trigger cmd.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24559:cae83bffe676
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Jan 24 15:30:46 2012 +0000
    
    libxl: remove _libxl_json_internal.h from libxl_json.h
    
    libxl_json.h is intended as a user-includable header for applications which
    would like to use libyajl directly with libxl types. It should not expose libxl
    internals.
    
    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:   24558:2c9b3b9da3b1
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:32 2012 +0000
    
    update MAINTAINERS file
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Add Ian as Seabios maintainer and myself as upstream Qemu maintainer.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24557:d919b814d0f3
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:31 2012 +0000
    
    libxl: use new qemu at the location where xen-unstable installs it
    
    From: Ian Campbell <ian.campbell@citrix.com>
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24556:d24509a987c3
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:31 2012 +0000
    
    Clone and build Seabios by default
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24555:277a1cde337f
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:30 2012 +0000
    
    Clone and build upstream Qemu by default
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24554:905ecf8d6482
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:30 2012 +0000
    
    move the call to xen-setup after libxc and xenstore are built
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Move the call to xen-setup, the wrapper script to configure
    qemu-xen-traditional, right before building qemu-xen-traditional and
    after libxc and xenstore are already built.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24553:f9e164f72615
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:29 2012 +0000
    
    Rename ioemu-dir as qemu-xen-traditional-dir
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24552:0bc51b1f2d74
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:29 2012 +0000
    
    Introduce git-checkout.sh
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Introduce a script to perform git checkout on an external git tree; use
    git-checkout.sh in ioemu-dir-find.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24551:0f8f633dbe2d
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:21:12 2012 +0000
    
    reflect cpupool in numa node affinity
    
    In order to prefer node local memory for a domain the numa node
    locality info must be built according to the cpus belonging to the
    cpupool of the domain.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24550:455a50622fb2
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:20:40 2012 +0000
    
    switch to dynamically allocated cpumask in domain_update_node_affinity()
    
    cpumasks should rather be allocated dynamically.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24549:3df3a0a95551
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:19:58 2012 +0000
    
    introduce and use common macros for selecting cpupool based cpumasks
    
    There are several instances of the same construct finding the cpumask
    for a cpupool. Use macros instead.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24548:d115844ebfbb
user:        Wei Liu <wei.liu2@citrix.com>
date:        Tue Jan 24 14:16:04 2012 +0000
    
    Add a GNTTABOP to swap the content of two grant references under lock
    provided that they are not currently active.
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24547:370924e204dc
user:        Keir Fraser <keir@xen.org>
date:        Mon Jan 23 15:10:43 2012 +0000
    
    Revert 24538:5bb22a6871f6 "xenoprof: Make the escape code consistent across 32 and 64-bit xen"
    
    Breaks 32-bit build.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Tue Jan 24 22:35:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 22: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 1RpoxJ-00079A-GM; Tue, 24 Jan 2012 22:35: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 1RpoxH-000795-3H
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 22:35:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327444499!12188330!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 937 invoked from network); 24 Jan 2012 22:34:59 -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;
	24 Jan 2012 22:34:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208";a="10260917"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	24 Jan 2012 22:34: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, 24 Jan 2012 22:34: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 1Rpox8-0002uj-T5;
	Tue, 24 Jan 2012 22:34:58 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rpox8-0007u8-S5;
	Tue, 24 Jan 2012 22:34:58 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11584-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 24 Jan 2012 22:34:58 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11584: 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 11584 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11584/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-win         14 guest-start.2             fail REGR. vs. 11574

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  a2a8089b1ffb
baseline version:
 xen                  370924e204dc

------------------------------------------------------------
People who touched revisions under test:
  Doug Magee <djmagee@mageenet.net>
  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>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@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


Not pushing.

------------------------------------------------------------
changeset:   24562:a2a8089b1ffb
tag:         tip
user:        Tim Deegan <tim@xen.org>
date:        Tue Jan 24 16:46:17 2012 +0000
    
    SVM: Plumb NPT error-code bits into nested-fault access_X arguments.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    
    
changeset:   24561:4cd3560aec0b
user:        Doug Magee <djmagee@mageenet.net>
date:        Tue Jan 24 15:36:19 2012 +0000
    
    libxl: rename is_assigned to is_pcidev_in_array
    
    All this function does is check to see if a device is in an array of
    pcidevs passed by the caller.  The function name can be misleading if
    ever used to check against a list of devices other than those assigned
    to a domain.
    
    Signed-off-by: Doug Magee <djmagee@mageenet.net>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24560:b7936bee33bf
user:        Jean Guyader <jean.guyader@eu.citrix.com>
date:        Tue Jan 24 15:33:36 2012 +0000
    
    xl: Add missing trigger for the xl trigger cmd.
    
    Add s3resume trigger in the usage of the xl trigger cmd.
    
    Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24559:cae83bffe676
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Tue Jan 24 15:30:46 2012 +0000
    
    libxl: remove _libxl_json_internal.h from libxl_json.h
    
    libxl_json.h is intended as a user-includable header for applications which
    would like to use libyajl directly with libxl types. It should not expose libxl
    internals.
    
    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:   24558:2c9b3b9da3b1
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:32 2012 +0000
    
    update MAINTAINERS file
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Add Ian as Seabios maintainer and myself as upstream Qemu maintainer.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24557:d919b814d0f3
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:31 2012 +0000
    
    libxl: use new qemu at the location where xen-unstable installs it
    
    From: Ian Campbell <ian.campbell@citrix.com>
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24556:d24509a987c3
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:31 2012 +0000
    
    Clone and build Seabios by default
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    
    
changeset:   24555:277a1cde337f
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:30 2012 +0000
    
    Clone and build upstream Qemu by default
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24554:905ecf8d6482
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:30 2012 +0000
    
    move the call to xen-setup after libxc and xenstore are built
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Move the call to xen-setup, the wrapper script to configure
    qemu-xen-traditional, right before building qemu-xen-traditional and
    after libxc and xenstore are already built.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24553:f9e164f72615
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:29 2012 +0000
    
    Rename ioemu-dir as qemu-xen-traditional-dir
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24552:0bc51b1f2d74
user:        <stefano.stabellini@eu.citrix.com>
date:        Tue Jan 24 15:09:29 2012 +0000
    
    Introduce git-checkout.sh
    
    From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    
    Introduce a script to perform git checkout on an external git tree; use
    git-checkout.sh in ioemu-dir-find.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson.citrix.com>
    
    
changeset:   24551:0f8f633dbe2d
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:21:12 2012 +0000
    
    reflect cpupool in numa node affinity
    
    In order to prefer node local memory for a domain the numa node
    locality info must be built according to the cpus belonging to the
    cpupool of the domain.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24550:455a50622fb2
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:20:40 2012 +0000
    
    switch to dynamically allocated cpumask in domain_update_node_affinity()
    
    cpumasks should rather be allocated dynamically.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24549:3df3a0a95551
user:        Juergen Gross <juergen.gross@ts.fujitsu.com>
date:        Tue Jan 24 14:19:58 2012 +0000
    
    introduce and use common macros for selecting cpupool based cpumasks
    
    There are several instances of the same construct finding the cpumask
    for a cpupool. Use macros instead.
    
    Signed-off-by: juergen.gross@ts.fujitsu.com
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24548:d115844ebfbb
user:        Wei Liu <wei.liu2@citrix.com>
date:        Tue Jan 24 14:16:04 2012 +0000
    
    Add a GNTTABOP to swap the content of two grant references under lock
    provided that they are not currently active.
    
    Signed-off-by: Wei Liu <wei.liu2@citrix.com>
    Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24547:370924e204dc
user:        Keir Fraser <keir@xen.org>
date:        Mon Jan 23 15:10:43 2012 +0000
    
    Revert 24538:5bb22a6871f6 "xenoprof: Make the escape code consistent across 32 and 64-bit xen"
    
    Breaks 32-bit build.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Tue Jan 24 23:14:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 23: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 1RppYl-0007kz-W2; Tue, 24 Jan 2012 23:13:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RppYk-0007kr-40
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 23:13:50 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327446822!12415086!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17208 invoked from network); 24 Jan 2012 23:13:43 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 23:13:43 -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, 24 Jan 2012 16:13:40 -0700
Message-ID: <4F1F3B23.60304@suse.com>
Date: Tue, 24 Jan 2012 16:13:39 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: erin.balid@inoutbox.com
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
In-Reply-To: <1327254854.9185.140661026566721@webmail.messagingengine.com>
Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

erin.balid@inoutbox.com wrote:
> I found this post from a year ago by an OpenSuse Xen developer -
>
> http://lists.opensuse.org/opensuse-features/2011-03/msg00212.html
>   

A mailing list to discuss openSUSE features, not an authoritative
resource on functionality in any given openSUSE release...

> "Xen 4.1.0 (due February 2011) will be the first release in which thenew
> xl/libxl (aka libxenlight [1]) toolstack will be the default,preferred
> tool set. Although still included in the release, the legacyxm/xend
> toolstack will be disabled and in process of deprecation."
>
> That was for 4.1.0. The current version is 4.1.2.  The post reads then
> like we already should be using xl in OpenSuse.

That talks about upstream xen, not xen packaging in openSUSE.  xl/libxl
is the default, preferred toolstack in upstream Xen 4.1.x.

>   Looks like the author
> posts on this list too.  I'll CC him directly on just this email. Maybe
> he can participate here a bit and has some ideas.
>   

Well, our plan was to switch to xl/libxl in openSUSE12.1, but we
switched back to the legacy toolstack before 12.1 released.  In the end,
we didn't have time to ensure xl/libxl was baked enough serve as a
replacement for xm/xend, let alone ensuring the tools consuming libxl
(e.g. libvirt) were feature parity with the legacy toolstack
counterparts.  Hopefully we will have time to do this during
openSUSE12.2 development cycle.

BTW, I can reproduce your problem and will take a look as time permits.

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 Jan 24 23:14:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 24 Jan 2012 23: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 1RppYl-0007kz-W2; Tue, 24 Jan 2012 23:13:51 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RppYk-0007kr-40
	for xen-devel@lists.xensource.com; Tue, 24 Jan 2012 23:13:50 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327446822!12415086!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17208 invoked from network); 24 Jan 2012 23:13:43 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 24 Jan 2012 23:13:43 -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, 24 Jan 2012 16:13:40 -0700
Message-ID: <4F1F3B23.60304@suse.com>
Date: Tue, 24 Jan 2012 16:13:39 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: erin.balid@inoutbox.com
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
In-Reply-To: <1327254854.9185.140661026566721@webmail.messagingengine.com>
Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

erin.balid@inoutbox.com wrote:
> I found this post from a year ago by an OpenSuse Xen developer -
>
> http://lists.opensuse.org/opensuse-features/2011-03/msg00212.html
>   

A mailing list to discuss openSUSE features, not an authoritative
resource on functionality in any given openSUSE release...

> "Xen 4.1.0 (due February 2011) will be the first release in which thenew
> xl/libxl (aka libxenlight [1]) toolstack will be the default,preferred
> tool set. Although still included in the release, the legacyxm/xend
> toolstack will be disabled and in process of deprecation."
>
> That was for 4.1.0. The current version is 4.1.2.  The post reads then
> like we already should be using xl in OpenSuse.

That talks about upstream xen, not xen packaging in openSUSE.  xl/libxl
is the default, preferred toolstack in upstream Xen 4.1.x.

>   Looks like the author
> posts on this list too.  I'll CC him directly on just this email. Maybe
> he can participate here a bit and has some ideas.
>   

Well, our plan was to switch to xl/libxl in openSUSE12.1, but we
switched back to the legacy toolstack before 12.1 released.  In the end,
we didn't have time to ensure xl/libxl was baked enough serve as a
replacement for xm/xend, let alone ensuring the tools consuming libxl
(e.g. libvirt) were feature parity with the legacy toolstack
counterparts.  Hopefully we will have time to do this during
openSUSE12.2 development cycle.

BTW, I can reproduce your problem and will take a look as time permits.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 01:41:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 01: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 1RprrN-0005XK-04; Wed, 25 Jan 2012 01:41:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jacob.Shin@amd.com>) id 1RprrL-0005XC-Ks
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 01:41:11 +0000
Received: from [85.158.138.51:19025] by server-2.bemta-3.messagelabs.com id
	A3/2D-24515-6BD5F1F4; Wed, 25 Jan 2012 01:41:10 +0000
X-Env-Sender: Jacob.Shin@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327455668!5385031!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13760 invoked from network); 25 Jan 2012 01:41:09 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Jan 2012 01:41:09 -0000
Received: from mail46-tx2-R.bigfish.com (10.9.14.254) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Jan 2012 01:41:07 +0000
Received: from mail46-tx2 (localhost [127.0.0.1])	by mail46-tx2-R.bigfish.com
	(Postfix) with ESMTP id 284D52C02AC;
	Wed, 25 Jan 2012 01:41:07 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h944h)
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 mail46-tx2 (localhost.localdomain [127.0.0.1]) by mail46-tx2
	(MessageSwitch) id 1327455664824206_16082;
	Wed, 25 Jan 2012 01:41:04 +0000 (UTC)
Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.252])	by
	mail46-tx2.bigfish.com (Postfix) with ESMTP id C49E5400045;
	Wed, 25 Jan 2012 01:41:04 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Jan 2012 01:41:01 +0000
X-WSS-ID: 0LYBZCA-01-3QK-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 262A010280A7;	Tue, 24 Jan 2012 19:40:57 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 24 Jan 2012 19:41:09 -0600
Received: from jshin-Toonie (10.236.48.193) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 24 Jan 2012 19:40:59 -0600
Date: Tue, 24 Jan 2012 19:42:40 -0600
From: Jacob Shin <jacob.shin@amd.com>
To: <jeremy@goop.org>, <xen-devel@lists.xensource.com>
Message-ID: <20120125014240.GA9561@jshin-Toonie>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: allow extra memory stay within lowest
	available 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

We have a machine with 1.5 TB of memory which has a e820 that looks 
like this:

(XEN)  0000000000000000 - 000000000008f400 (usable)
(XEN)  000000000008f400 - 00000000000a0000 (reserved)
(XEN)  00000000000d0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000c7eb0000 (usable)
(XEN)  00000000c7eb0000 - 00000000c7ed8000 (ACPI data)
(XEN)  00000000c7ed8000 - 00000000c7eda000 (ACPI NVS)
(XEN)  00000000c7eda000 - 00000000c8000000 (reserved)
(XEN)  00000000c8000000 - 00000000c8001000 (reserved)
(XEN)  00000000d8000000 - 00000000d8001000 (reserved)
(XEN)  00000000d8400000 - 00000000d8401000 (reserved)
(XEN)  00000000d8800000 - 00000000d8801000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fff00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000f038000000 (usable)
(XEN)  000000f038000000 - 000000fd00000000 (reserved)
(XEN)  0000010000000000 - 0000018fff000000 (usable)

Booting with dom0_mem=1024M, 2.6.32.48 adds extra pages for ballooning
at the end, and Dom0 panics:

..
[    0.000000]  Xen: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 000000f038000000 - 000000fd00000000 (reserved)
[    0.000000]  Xen: 000000fd00000000 - 000000ff40000000 (usable)
..
[    0.000000] init_memory_mapping: 0000000100000000-000000ff40000000
[    0.000000]  0100000000 - ff40000000 page 4k
[    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
..
[    0.000000]  [<ffffffff816699f9>] panic+0x8c/0x1a2
[    0.000000]  [<ffffffff81642da6>] init_memory_mapping+0x3d4/0x4b9
[    0.000000]  [<ffffffff81d068ba>] setup_arch+0x651/0xaaa
[    0.000000]  [<ffffffff81669b4b>] ? printk+0x3c/0x3e
[    0.000000]  [<ffffffff8166ba03>] ? _raw_spin_unlock_irqrestore+0x10/0x12
[    0.000000]  [<ffffffff81d00aa7>] start_kernel+0x8f/0x3ca
[    0.000000]  [<ffffffff81d002cb>] x86_64_start_reservations+0xb6/0xba
[    0.000000]  [<ffffffff81d04002>] xen_start_kernel+0x5a0/0x5a7

Below patch allows extra memory to settle on the first available memory
range that can accommodate it. Resulting e820 looks like this:

[    0.000000]  Xen: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000340000000 (usable)
[    0.000000]  Xen: 000000f038000000 - 000000fd00000000 (reserved)

This patch is moot on 3.2 and later because another patch already handles
this case: dc91c728fddc29dfed1ae96f6807216b5f42d3a1 xen: allow extra
memory to be in multiple regions.

Signed-off-by: Jacob Shin <jacob.shin@amd.com>
---
 arch/x86/xen/setup.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..1ce626d 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -240,6 +240,7 @@ char * __init xen_memory_setup(void)
 	memcpy(map_raw, map, sizeof(map));
 	e820.nr_map = 0;
 	xen_extra_mem_start = mem_end;
+	extra_limit = xen_get_max_pages();
 	for (i = 0; i < memmap.nr_entries; i++) {
 		unsigned long long end;
 
@@ -268,7 +269,9 @@ char * __init xen_memory_setup(void)
 		}
 
 		if (map[i].size > 0 && end > xen_extra_mem_start)
-			xen_extra_mem_start = end;
+			if (PFN_DOWN(map[i].addr - xen_extra_mem_start) <
+				(extra_limit - max_pfn))
+				xen_extra_mem_start = end;
 
 		/* Add region if any remains */
 		if (map[i].size > 0)
@@ -305,7 +308,6 @@ char * __init xen_memory_setup(void)
 
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 
-	extra_limit = xen_get_max_pages();
 	if (max_pfn + extra_pages > extra_limit) {
 		if (extra_limit > max_pfn)
 			extra_pages = extra_limit - max_pfn;
-- 
1.7.8.4



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 01:41:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 01: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 1RprrN-0005XK-04; Wed, 25 Jan 2012 01:41:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jacob.Shin@amd.com>) id 1RprrL-0005XC-Ks
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 01:41:11 +0000
Received: from [85.158.138.51:19025] by server-2.bemta-3.messagelabs.com id
	A3/2D-24515-6BD5F1F4; Wed, 25 Jan 2012 01:41:10 +0000
X-Env-Sender: Jacob.Shin@amd.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327455668!5385031!1
X-Originating-IP: [65.55.88.12]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13760 invoked from network); 25 Jan 2012 01:41:09 -0000
Received: from tx2ehsobe002.messaging.microsoft.com (HELO
	TX2EHSOBE003.bigfish.com) (65.55.88.12)
	by server-13.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	25 Jan 2012 01:41:09 -0000
Received: from mail46-tx2-R.bigfish.com (10.9.14.254) by
	TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Jan 2012 01:41:07 +0000
Received: from mail46-tx2 (localhost [127.0.0.1])	by mail46-tx2-R.bigfish.com
	(Postfix) with ESMTP id 284D52C02AC;
	Wed, 25 Jan 2012 01:41:07 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h944h)
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 mail46-tx2 (localhost.localdomain [127.0.0.1]) by mail46-tx2
	(MessageSwitch) id 1327455664824206_16082;
	Wed, 25 Jan 2012 01:41:04 +0000 (UTC)
Received: from TX2EHSMHS012.bigfish.com (unknown [10.9.14.252])	by
	mail46-tx2.bigfish.com (Postfix) with ESMTP id C49E5400045;
	Wed, 25 Jan 2012 01:41:04 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	TX2EHSMHS012.bigfish.com (10.9.99.112) with Microsoft SMTP Server id
	14.1.225.23; Wed, 25 Jan 2012 01:41:01 +0000
X-WSS-ID: 0LYBZCA-01-3QK-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 262A010280A7;	Tue, 24 Jan 2012 19:40:57 -0600 (CST)
Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 24 Jan 2012 19:41:09 -0600
Received: from jshin-Toonie (10.236.48.193) by sausexhtp02.amd.com
	(163.181.3.152) with Microsoft SMTP Server (TLS) id 8.3.213.0;
	Tue, 24 Jan 2012 19:40:59 -0600
Date: Tue, 24 Jan 2012 19:42:40 -0600
From: Jacob Shin <jacob.shin@amd.com>
To: <jeremy@goop.org>, <xen-devel@lists.xensource.com>
Message-ID: <20120125014240.GA9561@jshin-Toonie>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] xen: allow extra memory stay within lowest
	available 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

We have a machine with 1.5 TB of memory which has a e820 that looks 
like this:

(XEN)  0000000000000000 - 000000000008f400 (usable)
(XEN)  000000000008f400 - 00000000000a0000 (reserved)
(XEN)  00000000000d0000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000c7eb0000 (usable)
(XEN)  00000000c7eb0000 - 00000000c7ed8000 (ACPI data)
(XEN)  00000000c7ed8000 - 00000000c7eda000 (ACPI NVS)
(XEN)  00000000c7eda000 - 00000000c8000000 (reserved)
(XEN)  00000000c8000000 - 00000000c8001000 (reserved)
(XEN)  00000000d8000000 - 00000000d8001000 (reserved)
(XEN)  00000000d8400000 - 00000000d8401000 (reserved)
(XEN)  00000000d8800000 - 00000000d8801000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000fff00000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 000000f038000000 (usable)
(XEN)  000000f038000000 - 000000fd00000000 (reserved)
(XEN)  0000010000000000 - 0000018fff000000 (usable)

Booting with dom0_mem=1024M, 2.6.32.48 adds extra pages for ballooning
at the end, and Dom0 panics:

..
[    0.000000]  Xen: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 000000f038000000 - 000000fd00000000 (reserved)
[    0.000000]  Xen: 000000fd00000000 - 000000ff40000000 (usable)
..
[    0.000000] init_memory_mapping: 0000000100000000-000000ff40000000
[    0.000000]  0100000000 - ff40000000 page 4k
[    0.000000] Kernel panic - not syncing: Cannot find space for the kernel page tables
..
[    0.000000]  [<ffffffff816699f9>] panic+0x8c/0x1a2
[    0.000000]  [<ffffffff81642da6>] init_memory_mapping+0x3d4/0x4b9
[    0.000000]  [<ffffffff81d068ba>] setup_arch+0x651/0xaaa
[    0.000000]  [<ffffffff81669b4b>] ? printk+0x3c/0x3e
[    0.000000]  [<ffffffff8166ba03>] ? _raw_spin_unlock_irqrestore+0x10/0x12
[    0.000000]  [<ffffffff81d00aa7>] start_kernel+0x8f/0x3ca
[    0.000000]  [<ffffffff81d002cb>] x86_64_start_reservations+0xb6/0xba
[    0.000000]  [<ffffffff81d04002>] xen_start_kernel+0x5a0/0x5a7

Below patch allows extra memory to settle on the first available memory
range that can accommodate it. Resulting e820 looks like this:

[    0.000000]  Xen: 00000000fff00000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000100000000 - 0000000340000000 (usable)
[    0.000000]  Xen: 000000f038000000 - 000000fd00000000 (reserved)

This patch is moot on 3.2 and later because another patch already handles
this case: dc91c728fddc29dfed1ae96f6807216b5f42d3a1 xen: allow extra
memory to be in multiple regions.

Signed-off-by: Jacob Shin <jacob.shin@amd.com>
---
 arch/x86/xen/setup.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..1ce626d 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -240,6 +240,7 @@ char * __init xen_memory_setup(void)
 	memcpy(map_raw, map, sizeof(map));
 	e820.nr_map = 0;
 	xen_extra_mem_start = mem_end;
+	extra_limit = xen_get_max_pages();
 	for (i = 0; i < memmap.nr_entries; i++) {
 		unsigned long long end;
 
@@ -268,7 +269,9 @@ char * __init xen_memory_setup(void)
 		}
 
 		if (map[i].size > 0 && end > xen_extra_mem_start)
-			xen_extra_mem_start = end;
+			if (PFN_DOWN(map[i].addr - xen_extra_mem_start) <
+				(extra_limit - max_pfn))
+				xen_extra_mem_start = end;
 
 		/* Add region if any remains */
 		if (map[i].size > 0)
@@ -305,7 +308,6 @@ char * __init xen_memory_setup(void)
 
 	sanitize_e820_map(e820.map, ARRAY_SIZE(e820.map), &e820.nr_map);
 
-	extra_limit = xen_get_max_pages();
 	if (max_pfn + extra_pages > extra_limit) {
 		if (extra_limit > max_pfn)
 			extra_pages = extra_limit - max_pfn;
-- 
1.7.8.4



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 02:02:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 02: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 1RpsBC-0006MQ-Qs; Wed, 25 Jan 2012 02:01:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RpsBB-0006ML-He
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 02:01:41 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327456894!8563304!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDE0MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10093 invoked from network); 25 Jan 2012 02:01:35 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 02:01:35 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BB48F2111F
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 21:01:34 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Tue, 24 Jan 2012 21:01:34 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	rkPxdJGU5cLVLafUnF833QR23OY=; b=NUfHD8eLDRNRLnilWcjA/KXdUYNTl9/A
	z5aziG3t5g6fbTiq7urm+t7HjW7iRy3wem5SDPtpR1QuQ70Lns8brwcW3rqlauY0
	EqYSzVRf6i+OTHDtl4sC2sqS/Wd7+DZWy4TEKByTmk7lBWVMkTsTGLnQvNP5XsEK
	HEjGaH5B6V8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=rkPxdJGU5cLVLafUnF833QR23OY=; b=ros
	jGw2ChQGtOoh4w+uz4CEt52SEvh1z/C/5j2fDmjRwN4R5/jH4UebxKnS594Ugkh3
	rpL2COKFKkjpTTD5KM6fg07offE3K0xY1p1peCayQmeVkId2q7gywJ2mSB4GH/HE
	SeEeFe7xGoputJGCFKcVpsMa5vd8JkqI3lVP/VJQ=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 8EF28A001A4; Tue, 24 Jan 2012 21:01:34 -0500 (EST)
Message-Id: <1327456894.17114.140661027646361@webmail.messagingengine.com>
X-Sasl-Enc: sd3lDzZVKXaoLmeuDyupnGNIC4qzjqmaqu+dpMrej1X8 1327456894
From: erin.balid@inoutbox.com
To: Jim Fehlig <jfehlig@suse.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <4F1F3B23.60304@suse.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
	<4F1F3B23.60304@suse.com>
Date: Tue, 24 Jan 2012 18:01:34 -0800
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Jim.

Thanks for chiming in.

On Tue, Jan 24, 2012, at 04:13 PM, Jim Fehlig wrote:
> > http://lists.opensuse.org/opensuse-features/2011-03/msg00212.html
> 
> A mailing list to discuss openSUSE features, not an authoritative
> resource on functionality in any given openSUSE release...

It's been a big challenge finding anything that IS "an authoritative
resource on functionality" for Xen in Opensuse.

Where is the Opensuse-specific and Up-to-Date Xen documentation?  I
guess we cant rely on xen.org docs for Opensuse's Xen?  Is it not really
closely tied to the xen-devel project then?

> Well, our plan was to switch to xl/libxl in openSUSE12.1, but we
> switched back to the legacy toolstack before 12.1 released.  In the end,
> we didn't have time to ensure xl/libxl was baked enough serve as a
> replacement for xm/xend, let alone ensuring the tools consuming libxl
> (e.g. libvirt) were feature parity with the legacy toolstack
> counterparts.  Hopefully we will have time to do this during
> openSUSE12.2 development cycle.
> 
> BTW, I can reproduce your problem and will take a look as time permits.

Okay, so that looks like the answer here.  At the moment, it doesn't
work on Opensuse.  Thanks for verifying you can reproduce it and looking
into it more.

That leaves me back at my earlier question -- What are good docs for Xen
on Opensuse?  I've wasted a lot of time - mine and other people's -
doing what I was told (RTFM!) just to find out that 'real' Xen manual is
the wrong one.

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 02:02:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 02: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 1RpsBC-0006MQ-Qs; Wed, 25 Jan 2012 02:01:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1RpsBB-0006ML-He
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 02:01:41 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327456894!8563304!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDE0MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10093 invoked from network); 25 Jan 2012 02:01:35 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 02:01:35 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BB48F2111F
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 21:01:34 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Tue, 24 Jan 2012 21:01:34 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	rkPxdJGU5cLVLafUnF833QR23OY=; b=NUfHD8eLDRNRLnilWcjA/KXdUYNTl9/A
	z5aziG3t5g6fbTiq7urm+t7HjW7iRy3wem5SDPtpR1QuQ70Lns8brwcW3rqlauY0
	EqYSzVRf6i+OTHDtl4sC2sqS/Wd7+DZWy4TEKByTmk7lBWVMkTsTGLnQvNP5XsEK
	HEjGaH5B6V8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=rkPxdJGU5cLVLafUnF833QR23OY=; b=ros
	jGw2ChQGtOoh4w+uz4CEt52SEvh1z/C/5j2fDmjRwN4R5/jH4UebxKnS594Ugkh3
	rpL2COKFKkjpTTD5KM6fg07offE3K0xY1p1peCayQmeVkId2q7gywJ2mSB4GH/HE
	SeEeFe7xGoputJGCFKcVpsMa5vd8JkqI3lVP/VJQ=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 8EF28A001A4; Tue, 24 Jan 2012 21:01:34 -0500 (EST)
Message-Id: <1327456894.17114.140661027646361@webmail.messagingengine.com>
X-Sasl-Enc: sd3lDzZVKXaoLmeuDyupnGNIC4qzjqmaqu+dpMrej1X8 1327456894
From: erin.balid@inoutbox.com
To: Jim Fehlig <jfehlig@suse.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <4F1F3B23.60304@suse.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
	<4F1F3B23.60304@suse.com>
Date: Tue, 24 Jan 2012 18:01:34 -0800
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Jim.

Thanks for chiming in.

On Tue, Jan 24, 2012, at 04:13 PM, Jim Fehlig wrote:
> > http://lists.opensuse.org/opensuse-features/2011-03/msg00212.html
> 
> A mailing list to discuss openSUSE features, not an authoritative
> resource on functionality in any given openSUSE release...

It's been a big challenge finding anything that IS "an authoritative
resource on functionality" for Xen in Opensuse.

Where is the Opensuse-specific and Up-to-Date Xen documentation?  I
guess we cant rely on xen.org docs for Opensuse's Xen?  Is it not really
closely tied to the xen-devel project then?

> Well, our plan was to switch to xl/libxl in openSUSE12.1, but we
> switched back to the legacy toolstack before 12.1 released.  In the end,
> we didn't have time to ensure xl/libxl was baked enough serve as a
> replacement for xm/xend, let alone ensuring the tools consuming libxl
> (e.g. libvirt) were feature parity with the legacy toolstack
> counterparts.  Hopefully we will have time to do this during
> openSUSE12.2 development cycle.
> 
> BTW, I can reproduce your problem and will take a look as time permits.

Okay, so that looks like the answer here.  At the moment, it doesn't
work on Opensuse.  Thanks for verifying you can reproduce it and looking
into it more.

That leaves me back at my earlier question -- What are good docs for Xen
on Opensuse?  I've wasted a lot of time - mine and other people's -
doing what I was told (RTFM!) just to find out that 'real' Xen manual is
the wrong one.

Regards,

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 03:50:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 03: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 1RptrX-0007v5-3j; Wed, 25 Jan 2012 03:49: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 1RptrV-0007uU-Il
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 03:49:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327463363!12376673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22436 invoked from network); 25 Jan 2012 03:49:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 03:49:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,565,1320624000"; d="scan'208";a="10262605"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 03:49: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; Wed, 25 Jan 2012 03:49: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 1RptrO-0004cl-OW;
	Wed, 25 Jan 2012 03:49:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RptrO-0003v4-HU;
	Wed, 25 Jan 2012 03:49:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11591-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Jan 2012 03:49:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11591: 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 11591 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11591/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 11584
 test-amd64-i386-xend-winxpsp3 14 guest-start.2              fail pass in 11584
 test-i386-i386-win           14 guest-start.2               fail pass in 11584
 test-amd64-amd64-win         14 guest-start.2      fail in 11584 pass in 11591

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11584 never pass
 test-i386-i386-win           16 leak-check/check      fail in 11584 never pass

version targeted for testing:
 xen                  a2a8089b1ffb
baseline version:
 xen                  370924e204dc

------------------------------------------------------------
People who touched revisions under test:
  Doug Magee <djmagee@mageenet.net>
  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>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@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


Pushing revision :

+ branch=xen-unstable
+ revision=a2a8089b1ffb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a2a8089b1ffb
+ branch=xen-unstable
+ revision=a2a8089b1ffb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a2a8089b1ffb ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 15 changesets with 42 changes to 30 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 03:50:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 03: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 1RptrX-0007v5-3j; Wed, 25 Jan 2012 03:49: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 1RptrV-0007uU-Il
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 03:49:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327463363!12376673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDIwMQ==\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22436 invoked from network); 25 Jan 2012 03:49:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 03:49:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,565,1320624000"; d="scan'208";a="10262605"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 03:49: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; Wed, 25 Jan 2012 03:49: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 1RptrO-0004cl-OW;
	Wed, 25 Jan 2012 03:49:22 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RptrO-0003v4-HU;
	Wed, 25 Jan 2012 03:49:22 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11591-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Jan 2012 03:49:22 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11591: 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 11591 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11591/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10      fail pass in 11584
 test-amd64-i386-xend-winxpsp3 14 guest-start.2              fail pass in 11584
 test-i386-i386-win           14 guest-start.2               fail pass in 11584
 test-amd64-amd64-win         14 guest-start.2      fail in 11584 pass in 11591

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11584 never pass
 test-i386-i386-win           16 leak-check/check      fail in 11584 never pass

version targeted for testing:
 xen                  a2a8089b1ffb
baseline version:
 xen                  370924e204dc

------------------------------------------------------------
People who touched revisions under test:
  Doug Magee <djmagee@mageenet.net>
  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>
  juergen.gross@ts.fujitsu.com
  Keir Fraser <keir@xen.org>
  Paul Durrant <paul.durrant@citrix.com>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
  Wei Liu <wei.liu2@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


Pushing revision :

+ branch=xen-unstable
+ revision=a2a8089b1ffb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a2a8089b1ffb
+ branch=xen-unstable
+ revision=a2a8089b1ffb
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 a2a8089b1ffb ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
pushing to ssh://xen@xenbits.xensource.com/HG/xen-unstable.hg
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 15 changesets with 42 changes to 30 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 03:59:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 03:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpu19-00005K-BY; Wed, 25 Jan 2012 03:59:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpu17-00005F-Da
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 03:59:25 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327463958!13780822!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDE0MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22921 invoked from network); 25 Jan 2012 03:59:19 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 03:59:19 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AE44D20BE2
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 22:59:18 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Tue, 24 Jan 2012 22:59:18 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	P7PEZt2Gj9bcrqS9YJoOTSVQfbM=; b=CiI66xwHhDFNUwc6jlqgjfUt2h4qQMJp
	yZQ0X2zy32KG93c+7Faq0dmxd6T4xoPXf94aGVz+TiEhbRX7Z7s4+4R//rdjZ2al
	QtorMJYHdkzp0JI0GH53Gdu6RBGU/I4jDQGzC/v3usXzGToU3qQaIKWWKNOLYhis
	wHkZ+lkmtBk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=P7PEZt2Gj9bcrqS9YJoOTSVQfbM=; b=m3G
	0DIC42r146LPw0R5FSLxRdhGYFnxhntPd9MytrkvSJC4T8flPlIsHSf8tlHhsqdW
	r+bmY0d1SaeyLJbeodRJ38pk95HYKBvIL68r7laZaPrkKZVGIr9+NwKJgjSp6S9G
	Yej+mAuF/X6fJclsTQUpK8I9ZaSx52cvKDoo+zAo=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 8837BA001A4; Tue, 24 Jan 2012 22:59:18 -0500 (EST)
Message-Id: <1327463958.8811.140661027651265@webmail.messagingengine.com>
X-Sasl-Enc: ZlwgjaJjNBOMGVt2pp6LVst/vtkvHA/Gh9frO53NsjjG 1327463958
From: erin.balid@inoutbox.com
To: undisclosed-recipients:;
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <1327441442.19932.140661027559101@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><1327318076.24561.63.camel@zakaz.uk.xensource.com><1327332514.25697.140661026919117@webmail.messagingengine.com><1327415184.24561.182.camel@zakaz.uk.xensource.com><1327420611.19936.140661027415609@webmail.messagingengine.com><1327423312.24561.211.camel@zakaz.uk.xensource.com><1327425015.8709.140661027442201@webmail.messagingengine.com><1327428329.24310.140661027473797@webmail.messagingengine.com><1327440026.17019.16.camel@dagon.hellion.org.uk>
	<1327441442.19932.140661027559101@webmail.messagingengine.com>
Date: Tue, 24 Jan 2012 19:59:18 -0800
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.  Et al.

Thanks for the help in sorting this out.  We at least found out that
it's a problem at the distro.  Jim Fehlig says he can reproduce what I
see and will look into it - time permitting.   Which is great.

I don't know how this addresses the Fedora16 appearance of the problem,
but that's another discussion.

Regards.

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 03:59:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 03:59:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpu19-00005K-BY; Wed, 25 Jan 2012 03:59:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rpu17-00005F-Da
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 03:59:25 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327463958!13780822!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDE0MDI=\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22921 invoked from network); 25 Jan 2012 03:59:19 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 03:59:19 -0000
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AE44D20BE2
	for <xen-devel@lists.xensource.com>;
	Tue, 24 Jan 2012 22:59:18 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute1.internal (MEProxy); Tue, 24 Jan 2012 22:59:18 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	P7PEZt2Gj9bcrqS9YJoOTSVQfbM=; b=CiI66xwHhDFNUwc6jlqgjfUt2h4qQMJp
	yZQ0X2zy32KG93c+7Faq0dmxd6T4xoPXf94aGVz+TiEhbRX7Z7s4+4R//rdjZ2al
	QtorMJYHdkzp0JI0GH53Gdu6RBGU/I4jDQGzC/v3usXzGToU3qQaIKWWKNOLYhis
	wHkZ+lkmtBk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=P7PEZt2Gj9bcrqS9YJoOTSVQfbM=; b=m3G
	0DIC42r146LPw0R5FSLxRdhGYFnxhntPd9MytrkvSJC4T8flPlIsHSf8tlHhsqdW
	r+bmY0d1SaeyLJbeodRJ38pk95HYKBvIL68r7laZaPrkKZVGIr9+NwKJgjSp6S9G
	Yej+mAuF/X6fJclsTQUpK8I9ZaSx52cvKDoo+zAo=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 8837BA001A4; Tue, 24 Jan 2012 22:59:18 -0500 (EST)
Message-Id: <1327463958.8811.140661027651265@webmail.messagingengine.com>
X-Sasl-Enc: ZlwgjaJjNBOMGVt2pp6LVst/vtkvHA/Gh9frO53NsjjG 1327463958
From: erin.balid@inoutbox.com
To: undisclosed-recipients:;
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <1327441442.19932.140661027559101@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><1327318076.24561.63.camel@zakaz.uk.xensource.com><1327332514.25697.140661026919117@webmail.messagingengine.com><1327415184.24561.182.camel@zakaz.uk.xensource.com><1327420611.19936.140661027415609@webmail.messagingengine.com><1327423312.24561.211.camel@zakaz.uk.xensource.com><1327425015.8709.140661027442201@webmail.messagingengine.com><1327428329.24310.140661027473797@webmail.messagingengine.com><1327440026.17019.16.camel@dagon.hellion.org.uk>
	<1327441442.19932.140661027559101@webmail.messagingengine.com>
Date: Tue, 24 Jan 2012 19:59:18 -0800
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi Ian.  Et al.

Thanks for the help in sorting this out.  We at least found out that
it's a problem at the distro.  Jim Fehlig says he can reproduce what I
see and will look into it - time permitting.   Which is great.

I don't know how this addresses the Fedora16 appearance of the problem,
but that's another discussion.

Regards.

Erin

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 04:03:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 04:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpu4Y-0000GI-Vh; Wed, 25 Jan 2012 04:02:58 +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 1Rpu4X-0000G9-LW
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 04:02:57 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327464169!12410415!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11554 invoked from network); 25 Jan 2012 04:02:51 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 04:02:51 -0000
Received: from localhost (cpe-66-65-56-15.nyc.res.rr.com [66.65.56.15])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id q0P40hZ1006471
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 24 Jan 2012 20:00:44 -0800
Date: Tue, 24 Jan 2012 23:00:42 -0500 (EST)
Message-Id: <20120124.230042.1180973944381398704.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1327395480.17019.1.camel@dagon.hellion.org.uk>
References: <4F173467.90106@oracle.com>
	<20120123182443.GA22963@phenom.dumpdata.com>
	<1327395480.17019.1.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]);
	Tue, 24 Jan 2012 20:00:45 -0800 (PST)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, gurudas.pai@oracle.com,
	konrad.wilk@oracle.com, netdev@vger.kernel.org,
	zhenzhong.duan@oracle.com, linux-kernel@vger.kernel.org,
	tina.yang@oracle.com
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 24 Jan 2012 08:58:00 +0000

> On Mon, 2012-01-23 at 18:24 +0000, Konrad Rzeszutek Wilk wrote:
> 
>> From 1c265b7946f222ab6a5aac5245a0ab84618772c8 Mon Sep 17 00:00:00 2001
>> From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>> Date: Thu, 12 Jan 2012 10:18:29 +0800
>> Subject: [PATCH] xen/netfront: add netconsole support.
>> 
>> add polling interface to xen-netfront device to support netconsole
>> 
>> This patch also alters the spin_lock usage to use irqsave variant.
>> Documentation/networking/netdevices.txt states that start_xmit
>> can be called with interrupts disabled by netconsole and therefore using
>> the irqsave/restore locking in this function is looks correct.
>> 
>> Signed-off-by: Tina.Yang <tina.yang@oracle.com>
>> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
>> Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
>> Tested-by: gurudas.pai <gurudas.pai@oracle.com>
>> [v1: Copy-n-pasted Ian Campbell comments]
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Wed Jan 25 04:03:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 04:03:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpu4Y-0000GI-Vh; Wed, 25 Jan 2012 04:02:58 +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 1Rpu4X-0000G9-LW
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 04:02:57 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327464169!12410415!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11554 invoked from network); 25 Jan 2012 04:02:51 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-6.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 04:02:51 -0000
Received: from localhost (cpe-66-65-56-15.nyc.res.rr.com [66.65.56.15])
	(authenticated bits=0)
	by shards.monkeyblade.net (8.14.4/8.14.4) with ESMTP id q0P40hZ1006471
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 24 Jan 2012 20:00:44 -0800
Date: Tue, 24 Jan 2012 23:00:42 -0500 (EST)
Message-Id: <20120124.230042.1180973944381398704.davem@davemloft.net>
To: Ian.Campbell@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1327395480.17019.1.camel@dagon.hellion.org.uk>
References: <4F173467.90106@oracle.com>
	<20120123182443.GA22963@phenom.dumpdata.com>
	<1327395480.17019.1.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]);
	Tue, 24 Jan 2012 20:00:45 -0800 (PST)
Cc: jeremy@goop.org, xen-devel@lists.xensource.com, gurudas.pai@oracle.com,
	konrad.wilk@oracle.com, netdev@vger.kernel.org,
	zhenzhong.duan@oracle.com, linux-kernel@vger.kernel.org,
	tina.yang@oracle.com
Subject: Re: [Xen-devel] [PATCH] add netconsole support for xen-netfront
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 24 Jan 2012 08:58:00 +0000

> On Mon, 2012-01-23 at 18:24 +0000, Konrad Rzeszutek Wilk wrote:
> 
>> From 1c265b7946f222ab6a5aac5245a0ab84618772c8 Mon Sep 17 00:00:00 2001
>> From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>> Date: Thu, 12 Jan 2012 10:18:29 +0800
>> Subject: [PATCH] xen/netfront: add netconsole support.
>> 
>> add polling interface to xen-netfront device to support netconsole
>> 
>> This patch also alters the spin_lock usage to use irqsave variant.
>> Documentation/networking/netdevices.txt states that start_xmit
>> can be called with interrupts disabled by netconsole and therefore using
>> the irqsave/restore locking in this function is looks correct.
>> 
>> Signed-off-by: Tina.Yang <tina.yang@oracle.com>
>> Cc: Jeremy Fitzhardinge <jeremy@goop.org>
>> Signed-off-by: Zhenzhong.Duan <zhenzhong.duan@oracle.com>
>> Tested-by: gurudas.pai <gurudas.pai@oracle.com>
>> [v1: Copy-n-pasted Ian Campbell comments]
>> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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 Wed Jan 25 04:52:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 04:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpuqJ-0001FP-7o; Wed, 25 Jan 2012 04:52:19 +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 1RpuqH-0001FK-CH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 04:52:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327467129!12389605!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAwNjYz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6155 invoked from network); 25 Jan 2012 04:52:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 04:52:11 -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
	q0P4q8sN024256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 04:52:09 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0P4q6rQ000144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 04:52:07 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0P4q6lQ021079; Tue, 24 Jan 2012 22:52:06 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Jan 2012 20:52:06 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C1E61401A1; Tue, 24 Jan 2012 23:49:49 -0500 (EST)
Date: Tue, 24 Jan 2012 23:49:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, annie.li@oracle.com,
	xen-devel@lists.xensource.com
Message-ID: <20120125044949.GB29759@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F1F8A79.0074,ss=1,re=1.599,fgs=0
Subject: [Xen-devel] Regressions in v3.3-rc1 introduced by "xen/granttable:
 Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When I try to bootup a PVonHVM guest with Xen 4.1 I get this:

Loading vmlinuz......................................................................
Loading initramf.gz...........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ready.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.3.0-rc1 (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP PREEMPT Tue Jan 24 23:34:01 EST 2012
[    0.000000] Command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb BOOT_IMAGE=vmlinuz 
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
[    0.000000]  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.1.
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [ffff8800000fbc70] fbc70
[    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
[    0.000000] RAMDISK: 3c058000 - 3ffdf000
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc012cb0 00034 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc012ad0 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc002c40 0FE05 (v02    Xen      HVM 00000000 INTL 20090123)
[    0.000000] ACPI: FACS 00000000fc002c00 00040
[    0.000000] ACPI: APIC 00000000fc012bd0 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-0000000040000000
[    0.000000] Initmem setup node 0 0000000000000000-0000000040000000
[    0.000000]   NODE_DATA [000000003c031000 - 000000003c057fff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   empty
[    0.000000] Movable zone start PFN for each node
[    0.000000] Early memory PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] SMP: Allowing 15 CPUs, 14 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:bc000000)
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:15 nr_cpu_ids:15 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003be00000 s82240 r8192 d24256 u131072
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 257929
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb BOOT_IMAGE=vmlinuz 
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 950340k/1048576k available (6364k kernel code, 456k absent, 97780k reserved, 4742k data, 1180k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:262400 nr_irqs:1208 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] Detected 2294.548 MHz processor.
[    0.004999] Calibrating delay loop (skipped), value calculated using timer frequency.. 4589.09 BogoMIPS (lpj=2294548)
[    0.012002] pid_max: default: 32768 minimum: 301
[    0.016032] Security Framework initialized
[    0.020005] SELinux:  Initializing.
[    0.023127] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.029231] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.035103] Mount-cache hash table entries: 256
[    0.039024] Initializing cgroup subsys cpuacct
[    0.042000] Initializing cgroup subsys freezer
[    0.046075] CPU: Physical Processor ID: 0
[    0.048999] CPU: Processor Core ID: 0
[    0.052012] mce: CPU supports 20 MCE banks
[    0.056219] SMP alternatives: switching to UP code
[    0.072893] ACPI: Core revision 20120111
[    0.089601] ftrace: allocating 22768 entries in 89 pages
[    0.124087] Switched APIC routing to physical flat.
[    0.130228] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.145113] CPU0: Genuine Intel(R) CPU  @ 2.30GHz stepping 02
[    0.149999] installing Xen timer for CPU 0
[    0.153064] cpu 0 spinlock event irq 69
[    0.154041] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events only.
[    0.163051] NMI watchdog disabled (cpu0): hardware events not enabled
[    0.165998] Brought up 1 CPUs
[    0.166990] Total of 1 processors activated (4589.09 BogoMIPS).
[    0.172120] RTC time:  0:47:29, date: 01/25/12
[    0.173037] NET: Registered protocol family 16
[    0.174042] kworker/u:0 used greatest stack depth: 6208 bytes left
[    0.178054] ACPI: bus type pci registered
[    0.181115] PCI: Using configuration type 1 for base access
[    0.182029] kworker/u:0 used greatest stack depth: 5800 bytes left
[    0.184088] kworker/u:0 used greatest stack depth: 5440 bytes left
[    0.217125] bio: create slab <bio-0> at 0
[    0.218102] ACPI: Added _OSI(Module Device)
[    0.219000] ACPI: Added _OSI(Processor Device)
[    0.219995] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.220993] ACPI: Added _OSI(Processor Aggregator Device)
[    0.311044] ACPI: Interpreter enabled
[    0.311975] ACPI: (supports S0 S3 S4 S5)
[    0.316988] ACPI: Using IOAPIC for interrupt routing
[    0.958007] ACPI: No dock devices found.
[    0.958878] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.959994] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.961894] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.962876] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.963876] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.964875] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfbffffff]
[    0.965922] PCI host bridge to bus 0000:00
[    0.966883] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.967888] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.968881] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.969898] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
[    1.029004] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
[    1.029006] * this clock source is slow. Consider trying other clock sources
[    1.041923] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4 ACPI
[    1.084997]  pci0000:00: Unable to request _OSC control (_OSC support mask: 0x1e)
[    2.283755] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    2.287945] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    2.292705] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    2.297697] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    2.301950] xen/balloon: Initialising balloon driver.
[    2.302743] xen-balloon: Initialising balloon driver.
[    2.303932] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    2.304682] vgaarb: loaded
[    2.305682] vgaarb: bridge control possible 0000:00:02.0
[    2.306852] usbcore: registered new interface driver usbfs
[    2.307717] usbcore: registered new interface driver hub
[    2.308728] usbcore: registered new device driver usb
[    2.309840] PCI: Using ACPI for IRQ routing
[    2.312834] NetLabel: Initializing
[    2.313681] NetLabel:  domain hash size = 128
[    2.314679] NetLabel:  protocols = UNLABELED CIPSOv4
[    2.315684] NetLabel:  unlabeled traffic allowed by default
[    2.316745] Switching to clocksource xen
[    2.319978] pnp: PnP ACPI init
[    2.322649] ACPI: bus type pnp registered
[    2.326228] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
[    2.332319] system 00:02: [io  0x10c0-0x1141] has been reserved
[    2.337367] system 00:02: [io  0xb044-0xb047] has been reserved
[    2.342498] system 00:03: [io  0x08a0-0x08a3] has been reserved
[    2.347545] system 00:03: [io  0x0cc0-0x0ccf] has been reserved
[    2.352426] system 00:03: [io  0x04d0-0x04d1] has been reserved
[    2.412166] pnp: PnP ACPI: found 12 devices
[    2.415797] ACPI: ACPI bus type pnp unregistered
[    2.427298] NET: Registered protocol family 2
[    2.431177] IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
[    2.437405] TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
[    2.443897] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    2.449439] TCP: Hash tables configured (established 131072 bind 65536)
[    2.455015] TCP reno registered
[    2.457680] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    2.462645] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    2.468222] NET: Registered protocol family 1
[    2.471928] RPC: Registered named UNIX socket transport module.
[    2.476877] RPC: Registered udp transport module.
[    2.480808] RPC: Registered tcp transport module.
[    2.484855] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    2.490188] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    2.495568] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    2.500610] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    2.506628] Trying to unpack rootfs image as initramfs...
[    3.842613] Freeing initrd memory: 65052k freed
[    3.864308] Machine check injector initialized
[    3.868477] microcode: CPU0 sig=0x206d2, pf=0x1, revision=0x8000020c
[    3.873965] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    3.881877] audit: initializing netlink socket (disabled)
[    3.886453] type=2000 audit(1327452454.332:1): initialized
[    3.905496] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    3.912120] kworker/u:0 used greatest stack depth: 5432 bytes left
[    3.919718] VFS: Disk quotas dquot_6.5.2
[    3.923970] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    3.929942] NTFS driver 2.1.30 [Flags: R/W].
[    3.933815] msgmni has been set to 1983
[    3.937652] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    3.944099] io scheduler noop registered
[    3.947491] io scheduler deadline registered
[    3.951259] io scheduler cfq registered (default)
[    3.955229] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    3.960075] cirrusfb 0000:00:02.0: Cirrus Logic chipset on PCI bus, RAM (4096 kB) at 0xf0000000
[    3.967942] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    3.974452] ACPI: Power Button [PWRF]
[    3.977925] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[    3.984154] ACPI: Sleep Button [SLPF]
[    4.044889] Grant tables using version 2 layout.
[    4.048968] Grant table initialized
[    4.071769] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    4.109127] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    4.154314] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    4.161264] Non-volatile memory driver v1.3
[    4.164959] Linux agpgart interface v0.103
[    4.168774] [drm] Initialized drm 1.1.0 20060810
[    4.174181] brd: module loaded
[    4.177727] loop: module loaded
[    4.180388] Fixed MDIO Bus: probed
[    4.183447] tun: Universal TUN/TAP device driver, 1.6
[    4.187680] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    4.194394] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    4.200165] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    4.205720] uhci_hcd: USB Universal Host Controller Interface driver
[    4.211477] uhci_hcd 0000:00:01.2: UHCI Host Controller
[    4.215859] uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
[    4.222178] uhci_hcd 0000:00:01.2: detected 2 ports
[    4.226499] uhci_hcd 0000:00:01.2: irq 23, io base 0x0000c100
[    4.247577] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[    4.253339] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    4.259578] usb usb1: Product: UHCI Host Controller
[    4.263917] usb usb1: Manufacturer: Linux 3.3.0-rc1 uhci_hcd
[    4.268864] usb usb1: SerialNumber: 0000:00:01.2
[    4.273045] hub 1-0:1.0: USB hub found
[    4.276435] hub 1-0:1.0: 2 ports detected
[    4.280358] usbcore: registered new interface driver usblp
[    4.285415] usbcore: registered new interface driver libusual
[    4.290542] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    4.300400] serio: i8042 KBD port at 0x60,0x64 irq 1
[    4.304522] serio: i8042 AUX port at 0x60,0x64 irq 12
[    4.309034] mousedev: PS/2 mouse device common for all mice
[    4.315162] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    4.334548] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[    4.339970] rtc0: alarms up to one day, 114 bytes nvram
[    4.344805] cpuidle: using governor ladder
[    4.348287] cpuidle: using governor menu
[    4.351324] EFI Variables Facility v0.08 2004-May-17
[    4.355823] zram: num_devices not specified. Using default: 1
[    4.360929] zram: Creating 1 devices ...
[    4.364693] Netfilter messages via NETLINK v0.30.
[    4.368703] nf_conntrack version 0.5.0 (7932 buckets, 31728 max)
[    4.373904] ctnetlink v0.93: registering with nfnetlink.
[    4.378783] ip_tables: (C) 2000-2006 Netfilter Core Team
[    4.383579] TCP cubic registered
[    4.386448] Initializing XFRM netlink socket
[    4.390313] NET: Registered protocol family 10
[    4.394774] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    4.399368] IPv6 over IPv4 tunneling driver
[    4.403511] NET: Registered protocol family 17
[    4.407427] Registering the dns_resolver key type
[    4.411637] registered taskstats version 1
[    4.415787] XENBUS: Device with no driver: device/vfb/0
[    4.420213] XENBUS: Device with no driver: device/vbd/5632
[    4.425050] XENBUS: Device with no driver: device/vif/0
[    4.429562] XENBUS: Device with no driver: device/console/0
[    4.434211]   Magic number: 12:80:760
[    4.440340] Freeing unused kernel memory: 1180k freed
[    4.445074] Write protecting the kernel read-only data: 10240k
[    4.455026] Freeing unused kernel memory: 1808k freed
[    4.460463] Freeing unused kernel memory: 156k freed
init started: BusyBox v1.14.3 (2012-01-24 23:36:42 EST)
Mounting directories  [  OK  ]
[    4.542101] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[    4.623602] modprobe used greatest stack depth: 5208 bytes left
mount: mount point /sys/kernel/config does not exist
[    4.634172] core_filesystem used greatest stack depth: 5096 bytes left
FATAL: Error inserting xen_fbfront (/lib/modules/3.3.0-rc1/kernel/drivers/video/xen-fbfront.ko): No such device
[    4.653547] Initialising Xen virtual ethernet driver.
[    4.760758] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
[    4.776182] udevd (1225): /proc/1225/oom_adj is deprecated, please use /proc/1225/oom_score_adj instead.
[    4.817225] SCSI subsystem initialized
[    4.823855] libata version 3.00 loaded.
[    4.828486] ata_piix 0000:00:01.1: version 2.13
[    4.832645] ata_piix 0000:00:01.1: setting latency timer to 64
[    4.843283] scsi0 : ata_piix
[    4.850210] scsi1 : ata_piix
[    4.853778] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc120 irq 14
[    4.859818] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc128 irq 15
[    4.867005] Refined TSC clocksource calibration: 2294.470 MHz.
udevd-work[1242]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory

[    4.941699] ip used greatest stack depth: 3864 bytes left
[    5.026085] ata2.01: NODEV after polling detection
[    5.054647] ata2.00: ATAPI: QEMU DVD-ROM, 0.10.2, max UDMA/100
[    5.061809] ata2.00: configured for MWDMA2
[    5.083664] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     0.10 PQ: 0 ANSI: 5
[    5.131266] sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
[    5.135461] cdrom: Uniform CD-ROM driver Revision: 3.20
[    5.140627] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    5.147041] sr 1:0:0:0: Attached scsi generic sg0 type 5
Waiting for devices [  OK  ]
Waiting for fb [  OK  ]
Waiting for network [  OK  ]
Bringing up loopback interface:  [  OK  [    5.454600] usb usb1: suspend_rh (auto-stop)
]
Bringing up interface eth0:  [    5.487639] BUG: unable to handle kernel NULL pointer dereference at 0000000000000400
[    5.488057] IP: [<ffffffff81375ae9>] gnttab_end_foreign_access_ref_v2+0x29/0x40
[    5.488057] PGD 32aa3067 PUD 32a87067 PMD 0 
[    5.488057] Oops: 0000 [#1] PREEMPT SMP 
[    5.488057] CPU 0 
[    5.488057] Modules linked in: sg sr_mod cdrom ata_generic ata_piix libata scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
[    5.488057] 
[    5.488057] Pid: 2307, comm: ip Not tainted 3.3.0-rc1 #1 Xen HVM domU
[    5.488057] RIP: 0010:[<ffffffff81375ae9>]  [<ffffffff81375ae9>] gnttab_end_foreign_access_ref_v2+0x29/0x40
[    5.488057] RSP: 0018:ffff88003be03d38  EFLAGS: 00010206
[    5.488057] RAX: 0000000000000000 RBX: ffff880033210640 RCX: 0000000000000040
[    5.488057] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000200
[    5.488057] RBP: ffff88003be03d38 R08: 0000000000000101 R09: 0000000000000000
[    5.488057] R10: dead000000100100 R11: 0000000000000000 R12: ffff88003be03e48
[    5.488057] R13: 0000000000000001 R14: ffff880039461c00 R15: 0000000000000200
[    5.488057] FS:  00007fb1f84ec700(0000) GS:ffff88003be00000(0000) knlGS:0000000000000000
[    5.488057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    5.488057] CR2: 0000000000000400 CR3: 0000000032b1f000 CR4: 00000000000006f0
[    5.488057] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    5.488057] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    5.488057] Process ip (pid: 2307, threadinfo ffff880032b62000, task ffff88003bafe540)
[    5.488057] Stack:
[    5.488057]  ffff88003be03d48 ffffffff81375b13 ffff88003be03e88 ffffffffa00330c3
[    5.488057]  ffffea0000e51810 ffff88003be03e28 ffff88003be03e08 ffff88003be03de8
[    5.488057]  000000018020001e ffff88003be03dd0 ffff880033211300 ffff880033210658
[    5.488057] Call Trace:
[    5.488057]  <IRQ> 
[    5.488057]  [<ffffffff81375b13>] gnttab_end_foreign_access_ref+0x13/0x20
[    5.488057]  [<ffffffffa00330c3>] xennet_poll+0x2a3/0xe60 [xen_netfront]
[    5.488057]  [<ffffffff81041ebc>] ? xen_clocksource_read+0x4c/0x80
[    5.488057]  [<ffffffff810bd910>] ? sched_clock_cpu+0xc0/0x130
[    5.488057]  [<ffffffff814ddae0>] net_rx_action+0x140/0x350
[    5.488057]  [<ffffffff8108df53>] __do_softirq+0xf3/0x270
[    5.488057]  [<ffffffff81633e9c>] call_softirq+0x1c/0x30
[    5.488057]  <EOI> 
[    5.488057]  [<ffffffff8104d3c5>] do_softirq+0x65/0xa0
[    5.488057]  [<ffffffff8108ec3b>] local_bh_enable_ip+0xab/0xc0
[    5.488057]  [<ffffffff8162b0c3>] _raw_spin_unlock_bh+0x23/0x30
[    5.488057]  [<ffffffffa0032d99>] xennet_open+0x59/0xe0 [xen_netfront]
[    5.488057]  [<ffffffff814d893f>] __dev_open+0xbf/0x110
[    5.488057]  [<ffffffff814d6d01>] __dev_change_flags+0xa1/0x180
[    5.488057]  [<ffffffff814d8838>] dev_change_flags+0x28/0x70
[    5.488057]  [<ffffffff814e85e2>] do_setlink+0x1c2/0x9f0
[    5.488057]  [<ffffffff8162b51a>] ? _raw_spin_unlock+0x1a/0x40
[    5.488057]  [<ffffffff812fd064>] ? nla_parse+0x34/0x110
[    5.488057]  [<ffffffff814ea548>] rtnl_newlink+0x3d8/0x600
[    5.488057]  [<ffffffff81293579>] ? selinux_capable+0x39/0x50
[    5.488057]  [<ffffffff814e8187>] rtnetlink_rcv_msg+0x2b7/0x320
[    5.488057]  [<ffffffff810b68d1>] ? get_parent_ip+0x11/0x50
[    5.488057]  [<ffffffff814e7ed0>] ? rtnetlink_rcv+0x40/0x40
[    5.488057]  [<ffffffff815037c9>] netlink_rcv_skb+0xa9/0xd0
[    5.488057]  [<ffffffff814e7eb5>] rtnetlink_rcv+0x25/0x40
[    5.488057]  [<ffffffff81503499>] netlink_unicast+0x1a9/0x1f0
[    5.488057]  [<ffffffff815040ad>] netlink_sendmsg+0x20d/0x300
[    5.488057]  [<ffffffff814c3518>] sock_sendmsg+0xf8/0x130
[    5.488057]  [<ffffffff8113f26b>] ? filemap_fault+0x8b/0x480
[    5.488057]  [<ffffffff810b68d1>] ? get_parent_ip+0x11/0x50
[    5.488057]  [<ffffffff810b68d1>] ? get_parent_ip+0x11/0x50
[    5.488057]  [<ffffffff8113d86a>] ? unlock_page+0x2a/0x40
[    5.488057]  [<ffffffff81165499>] ? __do_fault+0x419/0x520
[    5.488057]  [<ffffffff814c1ef9>] ? copy_from_user+0x9/0x10
[    5.488057]  [<ffffffff814c23be>] ? move_addr_to_kernel+0x4e/0x90
[    5.488057]  [<ffffffff814d0139>] ? verify_iovec+0x69/0xd0
[    5.488057]  [<ffffffff814c4f7a>] __sys_sendmsg+0x3fa/0x420
[    5.488057]  [<ffffffff81165f98>] ? handle_mm_fault+0x148/0x270
[    5.488057]  [<ffffffff8162ea38>] ? do_page_fault+0x1b8/0x4d0
[    5.488057]  [<ffffffff8116a86c>] ? do_brk+0x26c/0x350
[    5.488057]  [<ffffffff814c51a9>] sys_sendmsg+0x49/0x90
[    5.488057]  [<ffffffff816329e9>] system_call_fastpath+0x16/0x1b
[    5.488057] Code: 00 00 55 48 89 e5 66 66 66 66 90 48 8b 05 58 40 a1 00 89 ff 48 89 fa 48 c1 e2 04 66 c7 04 02 00 00 0f ae f0 48 8b 05 4f 40 a1 00 <0f> b7 14 78 31 c0 83 e2 18 75 02 b0 01 c9 c3 0f 1f 84 00 00 00 
[    5.488057] RIP  [<ffffffff81375ae9>] gnttab_end_foreign_access_ref_v2+0x29/0x40
[    5.488057]  RSP <ffff88003be03d38>
[    5.488057] CR2: 0000000000000400
[    5.870364] ---[ end trace 695676be44834560 ]---
[    5.874131] Kernel panic - not syncing: Fatal exception in interrupt


and with this little patch I can get it to work:

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 1cd94da..814a7d0 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -950,6 +950,8 @@ static void gnttab_request_version(void)
 
 	gsv.version = 2;
 	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
+	if (xen_hvm_domain())
+		rc = -1; /* Just so that we use v1 in HVM. */
 	if (rc == 0) {
 		grant_table_version = 2;
 		gnttab_interface = &gnttab_v2_ops;

Any ideas why granttabl v2 won't work in HVM?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 04:52:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 04:52:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpuqJ-0001FP-7o; Wed, 25 Jan 2012 04:52:19 +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 1RpuqH-0001FK-CH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 04:52:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327467129!12389605!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAwNjYz\n
X-StarScan-Version: 6.4.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6155 invoked from network); 25 Jan 2012 04:52:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 04:52:11 -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
	q0P4q8sN024256
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 04:52:09 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0P4q6rQ000144
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 04:52:07 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0P4q6lQ021079; Tue, 24 Jan 2012 22:52:06 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Jan 2012 20:52:06 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id C1E61401A1; Tue, 24 Jan 2012 23:49:49 -0500 (EST)
Date: Tue, 24 Jan 2012 23:49:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, annie.li@oracle.com,
	xen-devel@lists.xensource.com
Message-ID: <20120125044949.GB29759@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F1F8A79.0074,ss=1,re=1.599,fgs=0
Subject: [Xen-devel] Regressions in v3.3-rc1 introduced by "xen/granttable:
 Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

When I try to bootup a PVonHVM guest with Xen 4.1 I get this:

Loading vmlinuz......................................................................
Loading initramf.gz...........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................ready.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.3.0-rc1 (konrad@phenom.dumpdata.com) (gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) ) #1 SMP PREEMPT Tue Jan 24 23:34:01 EST 2012
[    0.000000] Command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb BOOT_IMAGE=vmlinuz 
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e000 (usable)
[    0.000000]  BIOS-e820: 000000000009e000 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
[    0.000000]  BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.4 present.
[    0.000000] Hypervisor detected: Xen HVM
[    0.000000] Xen version 4.1.
[    0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[    0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.
[    0.000000] You might have to change the root device
[    0.000000] from /dev/hd[a-d] to /dev/xvd[a-d]
[    0.000000] in your root= kernel command line option
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0x40000 max_arch_pfn = 0x400000000
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] found SMP MP-table at [ffff8800000fbc70] fbc70
[    0.000000] init_memory_mapping: 0000000000000000-0000000040000000
[    0.000000] RAMDISK: 3c058000 - 3ffdf000
[    0.000000] ACPI: RSDP 00000000000ea020 00024 (v02    Xen)
[    0.000000] ACPI: XSDT 00000000fc012cb0 00034 (v01    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: FACP 00000000fc012ad0 000F4 (v04    Xen      HVM 00000000 HVML 00000000)
[    0.000000] ACPI: DSDT 00000000fc002c40 0FE05 (v02    Xen      HVM 00000000 INTL 20090123)
[    0.000000] ACPI: FACS 00000000fc002c00 00040
[    0.000000] ACPI: APIC 00000000fc012bd0 000D8 (v02    Xen      HVM 00000000 HVML 00000000)
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-0000000040000000
[    0.000000] Initmem setup node 0 0000000000000000-0000000040000000
[    0.000000]   NODE_DATA [000000003c031000 - 000000003c057fff]
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   empty
[    0.000000] Movable zone start PFN for each node
[    0.000000] Early memory PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x00040000
[    0.000000] ACPI: PM-Timer IO Port: 0xb008
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x08] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x0a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x0c] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x0e] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x10] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x12] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x14] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x16] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x18] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x1a] disabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x1c] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-47
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 low level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 low level)
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] SMP: Allowing 15 CPUs, 14 hotplug CPUs
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at 40000000 (gap: 40000000:bc000000)
[    0.000000] Booting paravirtualized kernel on Xen HVM
[    0.000000] setup_percpu: NR_CPUS:4096 nr_cpumask_bits:15 nr_cpu_ids:15 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff88003be00000 s82240 r8192 d24256 u131072
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 257929
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: initrd=initramf.gz  console=ttyS0,115200 test=netstatic nofb BOOT_IMAGE=vmlinuz 
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Memory: 950340k/1048576k available (6364k kernel code, 456k absent, 97780k reserved, 4742k data, 1180k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=15, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:262400 nr_irqs:1208 16
[    0.000000] Xen HVM callback vector for event delivery is enabled
[    0.000000] Console: colour VGA+ 80x25
[    0.000000] console [ttyS0] enabled
[    0.000000] Detected 2294.548 MHz processor.
[    0.004999] Calibrating delay loop (skipped), value calculated using timer frequency.. 4589.09 BogoMIPS (lpj=2294548)
[    0.012002] pid_max: default: 32768 minimum: 301
[    0.016032] Security Framework initialized
[    0.020005] SELinux:  Initializing.
[    0.023127] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.029231] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
[    0.035103] Mount-cache hash table entries: 256
[    0.039024] Initializing cgroup subsys cpuacct
[    0.042000] Initializing cgroup subsys freezer
[    0.046075] CPU: Physical Processor ID: 0
[    0.048999] CPU: Processor Core ID: 0
[    0.052012] mce: CPU supports 20 MCE banks
[    0.056219] SMP alternatives: switching to UP code
[    0.072893] ACPI: Core revision 20120111
[    0.089601] ftrace: allocating 22768 entries in 89 pages
[    0.124087] Switched APIC routing to physical flat.
[    0.130228] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[    0.145113] CPU0: Genuine Intel(R) CPU  @ 2.30GHz stepping 02
[    0.149999] installing Xen timer for CPU 0
[    0.153064] cpu 0 spinlock event irq 69
[    0.154041] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events only.
[    0.163051] NMI watchdog disabled (cpu0): hardware events not enabled
[    0.165998] Brought up 1 CPUs
[    0.166990] Total of 1 processors activated (4589.09 BogoMIPS).
[    0.172120] RTC time:  0:47:29, date: 01/25/12
[    0.173037] NET: Registered protocol family 16
[    0.174042] kworker/u:0 used greatest stack depth: 6208 bytes left
[    0.178054] ACPI: bus type pci registered
[    0.181115] PCI: Using configuration type 1 for base access
[    0.182029] kworker/u:0 used greatest stack depth: 5800 bytes left
[    0.184088] kworker/u:0 used greatest stack depth: 5440 bytes left
[    0.217125] bio: create slab <bio-0> at 0
[    0.218102] ACPI: Added _OSI(Module Device)
[    0.219000] ACPI: Added _OSI(Processor Device)
[    0.219995] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.220993] ACPI: Added _OSI(Processor Aggregator Device)
[    0.311044] ACPI: Interpreter enabled
[    0.311975] ACPI: (supports S0 S3 S4 S5)
[    0.316988] ACPI: Using IOAPIC for interrupt routing
[    0.958007] ACPI: No dock devices found.
[    0.958878] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.959994] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.961894] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.962876] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.963876] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.964875] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfbffffff]
[    0.965922] PCI host bridge to bus 0000:00
[    0.966883] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.967888] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.968881] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.969898] pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfbffffff]
[    1.029004] * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
[    1.029006] * this clock source is slow. Consider trying other clock sources
[    1.041923] pci 0000:00:01.3: quirk: [io  0xb000-0xb03f] claimed by PIIX4 ACPI
[    1.084997]  pci0000:00: Unable to request _OSC control (_OSC support mask: 0x1e)
[    2.283755] ACPI: PCI Interrupt Link [LNKA] (IRQs *5 10 11)
[    2.287945] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    2.292705] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    2.297697] ACPI: PCI Interrupt Link [LNKD] (IRQs *5 10 11)
[    2.301950] xen/balloon: Initialising balloon driver.
[    2.302743] xen-balloon: Initialising balloon driver.
[    2.303932] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    2.304682] vgaarb: loaded
[    2.305682] vgaarb: bridge control possible 0000:00:02.0
[    2.306852] usbcore: registered new interface driver usbfs
[    2.307717] usbcore: registered new interface driver hub
[    2.308728] usbcore: registered new device driver usb
[    2.309840] PCI: Using ACPI for IRQ routing
[    2.312834] NetLabel: Initializing
[    2.313681] NetLabel:  domain hash size = 128
[    2.314679] NetLabel:  protocols = UNLABELED CIPSOv4
[    2.315684] NetLabel:  unlabeled traffic allowed by default
[    2.316745] Switching to clocksource xen
[    2.319978] pnp: PnP ACPI init
[    2.322649] ACPI: bus type pnp registered
[    2.326228] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved
[    2.332319] system 00:02: [io  0x10c0-0x1141] has been reserved
[    2.337367] system 00:02: [io  0xb044-0xb047] has been reserved
[    2.342498] system 00:03: [io  0x08a0-0x08a3] has been reserved
[    2.347545] system 00:03: [io  0x0cc0-0x0ccf] has been reserved
[    2.352426] system 00:03: [io  0x04d0-0x04d1] has been reserved
[    2.412166] pnp: PnP ACPI: found 12 devices
[    2.415797] ACPI: ACPI bus type pnp unregistered
[    2.427298] NET: Registered protocol family 2
[    2.431177] IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
[    2.437405] TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
[    2.443897] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    2.449439] TCP: Hash tables configured (established 131072 bind 65536)
[    2.455015] TCP reno registered
[    2.457680] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    2.462645] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    2.468222] NET: Registered protocol family 1
[    2.471928] RPC: Registered named UNIX socket transport module.
[    2.476877] RPC: Registered udp transport module.
[    2.480808] RPC: Registered tcp transport module.
[    2.484855] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    2.490188] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    2.495568] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    2.500610] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    2.506628] Trying to unpack rootfs image as initramfs...
[    3.842613] Freeing initrd memory: 65052k freed
[    3.864308] Machine check injector initialized
[    3.868477] microcode: CPU0 sig=0x206d2, pf=0x1, revision=0x8000020c
[    3.873965] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    3.881877] audit: initializing netlink socket (disabled)
[    3.886453] type=2000 audit(1327452454.332:1): initialized
[    3.905496] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    3.912120] kworker/u:0 used greatest stack depth: 5432 bytes left
[    3.919718] VFS: Disk quotas dquot_6.5.2
[    3.923970] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    3.929942] NTFS driver 2.1.30 [Flags: R/W].
[    3.933815] msgmni has been set to 1983
[    3.937652] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    3.944099] io scheduler noop registered
[    3.947491] io scheduler deadline registered
[    3.951259] io scheduler cfq registered (default)
[    3.955229] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    3.960075] cirrusfb 0000:00:02.0: Cirrus Logic chipset on PCI bus, RAM (4096 kB) at 0xf0000000
[    3.967942] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    3.974452] ACPI: Power Button [PWRF]
[    3.977925] input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
[    3.984154] ACPI: Sleep Button [SLPF]
[    4.044889] Grant tables using version 2 layout.
[    4.048968] Grant table initialized
[    4.071769] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    4.109127] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    4.154314] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    4.161264] Non-volatile memory driver v1.3
[    4.164959] Linux agpgart interface v0.103
[    4.168774] [drm] Initialized drm 1.1.0 20060810
[    4.174181] brd: module loaded
[    4.177727] loop: module loaded
[    4.180388] Fixed MDIO Bus: probed
[    4.183447] tun: Universal TUN/TAP device driver, 1.6
[    4.187680] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    4.194394] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    4.200165] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    4.205720] uhci_hcd: USB Universal Host Controller Interface driver
[    4.211477] uhci_hcd 0000:00:01.2: UHCI Host Controller
[    4.215859] uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
[    4.222178] uhci_hcd 0000:00:01.2: detected 2 ports
[    4.226499] uhci_hcd 0000:00:01.2: irq 23, io base 0x0000c100
[    4.247577] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[    4.253339] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    4.259578] usb usb1: Product: UHCI Host Controller
[    4.263917] usb usb1: Manufacturer: Linux 3.3.0-rc1 uhci_hcd
[    4.268864] usb usb1: SerialNumber: 0000:00:01.2
[    4.273045] hub 1-0:1.0: USB hub found
[    4.276435] hub 1-0:1.0: 2 ports detected
[    4.280358] usbcore: registered new interface driver usblp
[    4.285415] usbcore: registered new interface driver libusual
[    4.290542] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[    4.300400] serio: i8042 KBD port at 0x60,0x64 irq 1
[    4.304522] serio: i8042 AUX port at 0x60,0x64 irq 12
[    4.309034] mousedev: PS/2 mouse device common for all mice
[    4.315162] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    4.334548] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[    4.339970] rtc0: alarms up to one day, 114 bytes nvram
[    4.344805] cpuidle: using governor ladder
[    4.348287] cpuidle: using governor menu
[    4.351324] EFI Variables Facility v0.08 2004-May-17
[    4.355823] zram: num_devices not specified. Using default: 1
[    4.360929] zram: Creating 1 devices ...
[    4.364693] Netfilter messages via NETLINK v0.30.
[    4.368703] nf_conntrack version 0.5.0 (7932 buckets, 31728 max)
[    4.373904] ctnetlink v0.93: registering with nfnetlink.
[    4.378783] ip_tables: (C) 2000-2006 Netfilter Core Team
[    4.383579] TCP cubic registered
[    4.386448] Initializing XFRM netlink socket
[    4.390313] NET: Registered protocol family 10
[    4.394774] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    4.399368] IPv6 over IPv4 tunneling driver
[    4.403511] NET: Registered protocol family 17
[    4.407427] Registering the dns_resolver key type
[    4.411637] registered taskstats version 1
[    4.415787] XENBUS: Device with no driver: device/vfb/0
[    4.420213] XENBUS: Device with no driver: device/vbd/5632
[    4.425050] XENBUS: Device with no driver: device/vif/0
[    4.429562] XENBUS: Device with no driver: device/console/0
[    4.434211]   Magic number: 12:80:760
[    4.440340] Freeing unused kernel memory: 1180k freed
[    4.445074] Write protecting the kernel read-only data: 10240k
[    4.455026] Freeing unused kernel memory: 1808k freed
[    4.460463] Freeing unused kernel memory: 156k freed
init started: BusyBox v1.14.3 (2012-01-24 23:36:42 EST)
Mounting directories  [  OK  ]
[    4.542101] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[    4.623602] modprobe used greatest stack depth: 5208 bytes left
mount: mount point /sys/kernel/config does not exist
[    4.634172] core_filesystem used greatest stack depth: 5096 bytes left
FATAL: Error inserting xen_fbfront (/lib/modules/3.3.0-rc1/kernel/drivers/video/xen-fbfront.ko): No such device
[    4.653547] Initialising Xen virtual ethernet driver.
[    4.760758] vbd vbd-5632: 19 xenbus_dev_probe on device/vbd/5632
[    4.776182] udevd (1225): /proc/1225/oom_adj is deprecated, please use /proc/1225/oom_score_adj instead.
[    4.817225] SCSI subsystem initialized
[    4.823855] libata version 3.00 loaded.
[    4.828486] ata_piix 0000:00:01.1: version 2.13
[    4.832645] ata_piix 0000:00:01.1: setting latency timer to 64
[    4.843283] scsi0 : ata_piix
[    4.850210] scsi1 : ata_piix
[    4.853778] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc120 irq 14
[    4.859818] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc128 irq 15
[    4.867005] Refined TSC clocksource calibration: 2294.470 MHz.
udevd-work[1242]: error opening ATTR{/sys/devices/system/cpu/cpu0/online} for writing: No such file or directory

[    4.941699] ip used greatest stack depth: 3864 bytes left
[    5.026085] ata2.01: NODEV after polling detection
[    5.054647] ata2.00: ATAPI: QEMU DVD-ROM, 0.10.2, max UDMA/100
[    5.061809] ata2.00: configured for MWDMA2
[    5.083664] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     0.10 PQ: 0 ANSI: 5
[    5.131266] sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
[    5.135461] cdrom: Uniform CD-ROM driver Revision: 3.20
[    5.140627] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    5.147041] sr 1:0:0:0: Attached scsi generic sg0 type 5
Waiting for devices [  OK  ]
Waiting for fb [  OK  ]
Waiting for network [  OK  ]
Bringing up loopback interface:  [  OK  [    5.454600] usb usb1: suspend_rh (auto-stop)
]
Bringing up interface eth0:  [    5.487639] BUG: unable to handle kernel NULL pointer dereference at 0000000000000400
[    5.488057] IP: [<ffffffff81375ae9>] gnttab_end_foreign_access_ref_v2+0x29/0x40
[    5.488057] PGD 32aa3067 PUD 32a87067 PMD 0 
[    5.488057] Oops: 0000 [#1] PREEMPT SMP 
[    5.488057] CPU 0 
[    5.488057] Modules linked in: sg sr_mod cdrom ata_generic ata_piix libata scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
[    5.488057] 
[    5.488057] Pid: 2307, comm: ip Not tainted 3.3.0-rc1 #1 Xen HVM domU
[    5.488057] RIP: 0010:[<ffffffff81375ae9>]  [<ffffffff81375ae9>] gnttab_end_foreign_access_ref_v2+0x29/0x40
[    5.488057] RSP: 0018:ffff88003be03d38  EFLAGS: 00010206
[    5.488057] RAX: 0000000000000000 RBX: ffff880033210640 RCX: 0000000000000040
[    5.488057] RDX: 0000000000002000 RSI: 0000000000000000 RDI: 0000000000000200
[    5.488057] RBP: ffff88003be03d38 R08: 0000000000000101 R09: 0000000000000000
[    5.488057] R10: dead000000100100 R11: 0000000000000000 R12: ffff88003be03e48
[    5.488057] R13: 0000000000000001 R14: ffff880039461c00 R15: 0000000000000200
[    5.488057] FS:  00007fb1f84ec700(0000) GS:ffff88003be00000(0000) knlGS:0000000000000000
[    5.488057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    5.488057] CR2: 0000000000000400 CR3: 0000000032b1f000 CR4: 00000000000006f0
[    5.488057] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    5.488057] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[    5.488057] Process ip (pid: 2307, threadinfo ffff880032b62000, task ffff88003bafe540)
[    5.488057] Stack:
[    5.488057]  ffff88003be03d48 ffffffff81375b13 ffff88003be03e88 ffffffffa00330c3
[    5.488057]  ffffea0000e51810 ffff88003be03e28 ffff88003be03e08 ffff88003be03de8
[    5.488057]  000000018020001e ffff88003be03dd0 ffff880033211300 ffff880033210658
[    5.488057] Call Trace:
[    5.488057]  <IRQ> 
[    5.488057]  [<ffffffff81375b13>] gnttab_end_foreign_access_ref+0x13/0x20
[    5.488057]  [<ffffffffa00330c3>] xennet_poll+0x2a3/0xe60 [xen_netfront]
[    5.488057]  [<ffffffff81041ebc>] ? xen_clocksource_read+0x4c/0x80
[    5.488057]  [<ffffffff810bd910>] ? sched_clock_cpu+0xc0/0x130
[    5.488057]  [<ffffffff814ddae0>] net_rx_action+0x140/0x350
[    5.488057]  [<ffffffff8108df53>] __do_softirq+0xf3/0x270
[    5.488057]  [<ffffffff81633e9c>] call_softirq+0x1c/0x30
[    5.488057]  <EOI> 
[    5.488057]  [<ffffffff8104d3c5>] do_softirq+0x65/0xa0
[    5.488057]  [<ffffffff8108ec3b>] local_bh_enable_ip+0xab/0xc0
[    5.488057]  [<ffffffff8162b0c3>] _raw_spin_unlock_bh+0x23/0x30
[    5.488057]  [<ffffffffa0032d99>] xennet_open+0x59/0xe0 [xen_netfront]
[    5.488057]  [<ffffffff814d893f>] __dev_open+0xbf/0x110
[    5.488057]  [<ffffffff814d6d01>] __dev_change_flags+0xa1/0x180
[    5.488057]  [<ffffffff814d8838>] dev_change_flags+0x28/0x70
[    5.488057]  [<ffffffff814e85e2>] do_setlink+0x1c2/0x9f0
[    5.488057]  [<ffffffff8162b51a>] ? _raw_spin_unlock+0x1a/0x40
[    5.488057]  [<ffffffff812fd064>] ? nla_parse+0x34/0x110
[    5.488057]  [<ffffffff814ea548>] rtnl_newlink+0x3d8/0x600
[    5.488057]  [<ffffffff81293579>] ? selinux_capable+0x39/0x50
[    5.488057]  [<ffffffff814e8187>] rtnetlink_rcv_msg+0x2b7/0x320
[    5.488057]  [<ffffffff810b68d1>] ? get_parent_ip+0x11/0x50
[    5.488057]  [<ffffffff814e7ed0>] ? rtnetlink_rcv+0x40/0x40
[    5.488057]  [<ffffffff815037c9>] netlink_rcv_skb+0xa9/0xd0
[    5.488057]  [<ffffffff814e7eb5>] rtnetlink_rcv+0x25/0x40
[    5.488057]  [<ffffffff81503499>] netlink_unicast+0x1a9/0x1f0
[    5.488057]  [<ffffffff815040ad>] netlink_sendmsg+0x20d/0x300
[    5.488057]  [<ffffffff814c3518>] sock_sendmsg+0xf8/0x130
[    5.488057]  [<ffffffff8113f26b>] ? filemap_fault+0x8b/0x480
[    5.488057]  [<ffffffff810b68d1>] ? get_parent_ip+0x11/0x50
[    5.488057]  [<ffffffff810b68d1>] ? get_parent_ip+0x11/0x50
[    5.488057]  [<ffffffff8113d86a>] ? unlock_page+0x2a/0x40
[    5.488057]  [<ffffffff81165499>] ? __do_fault+0x419/0x520
[    5.488057]  [<ffffffff814c1ef9>] ? copy_from_user+0x9/0x10
[    5.488057]  [<ffffffff814c23be>] ? move_addr_to_kernel+0x4e/0x90
[    5.488057]  [<ffffffff814d0139>] ? verify_iovec+0x69/0xd0
[    5.488057]  [<ffffffff814c4f7a>] __sys_sendmsg+0x3fa/0x420
[    5.488057]  [<ffffffff81165f98>] ? handle_mm_fault+0x148/0x270
[    5.488057]  [<ffffffff8162ea38>] ? do_page_fault+0x1b8/0x4d0
[    5.488057]  [<ffffffff8116a86c>] ? do_brk+0x26c/0x350
[    5.488057]  [<ffffffff814c51a9>] sys_sendmsg+0x49/0x90
[    5.488057]  [<ffffffff816329e9>] system_call_fastpath+0x16/0x1b
[    5.488057] Code: 00 00 55 48 89 e5 66 66 66 66 90 48 8b 05 58 40 a1 00 89 ff 48 89 fa 48 c1 e2 04 66 c7 04 02 00 00 0f ae f0 48 8b 05 4f 40 a1 00 <0f> b7 14 78 31 c0 83 e2 18 75 02 b0 01 c9 c3 0f 1f 84 00 00 00 
[    5.488057] RIP  [<ffffffff81375ae9>] gnttab_end_foreign_access_ref_v2+0x29/0x40
[    5.488057]  RSP <ffff88003be03d38>
[    5.488057] CR2: 0000000000000400
[    5.870364] ---[ end trace 695676be44834560 ]---
[    5.874131] Kernel panic - not syncing: Fatal exception in interrupt


and with this little patch I can get it to work:

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 1cd94da..814a7d0 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -950,6 +950,8 @@ static void gnttab_request_version(void)
 
 	gsv.version = 2;
 	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
+	if (xen_hvm_domain())
+		rc = -1; /* Just so that we use v1 in HVM. */
 	if (rc == 0) {
 		grant_table_version = 2;
 		gnttab_interface = &gnttab_v2_ops;

Any ideas why granttabl v2 won't work in HVM?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 05:15:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 05: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 1RpvCb-0001gZ-EK; Wed, 25 Jan 2012 05:15:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpvCZ-0001gU-RO
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 05:15:20 +0000
Received: from [85.158.138.51:44460] by server-9.bemta-3.messagelabs.com id
	31/2F-31168-7EF8F1F4; Wed, 25 Jan 2012 05:15:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327468516!10555845!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAwNjYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8929 invoked from network); 25 Jan 2012 05:15:18 -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; 25 Jan 2012 05:15:18 -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
	q0P5FBGP012790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 05:15:12 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
	q0P5FA6I012434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 05:15:11 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
	q0P5F9DJ000342; Tue, 24 Jan 2012 23:15:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Jan 2012 21:15:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0F9B7401A1; Wed, 25 Jan 2012 00:12:54 -0500 (EST)
Date: Wed, 25 Jan 2012 00:12:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, annie.li@oracle.com,
	xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20120125051253.GA15501@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120125044949.GB29759@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F1F8FE0.006F,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> When I try to bootup a PVonHVM guest with Xen 4.1 I get this:

.. snip..
> 
> and with this little patch I can get it to work:

I get the domU to boot but the network stops being responsive.
I see this in the Dom0:


(XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
[ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
[ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15

Replacing the patch with:

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 1cd94da..b4d4eac 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -948,9 +948,12 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	gsv.version = 2;
+	if (xen_hvm_domain())
+		gsv.version = 1;
+	else
+		gsv.version = 2;
 	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
-	if (rc == 0) {
+	if (rc == 0 && gsv.version == 2) {
 		grant_table_version = 2;
 		gnttab_interface = &gnttab_v2_ops;
 	} else if (grant_table_version == 2) {

Gets me back to how it worked in Linux v3.2.

But that is just a band-aid fix...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 05:15:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 05: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 1RpvCb-0001gZ-EK; Wed, 25 Jan 2012 05:15:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RpvCZ-0001gU-RO
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 05:15:20 +0000
Received: from [85.158.138.51:44460] by server-9.bemta-3.messagelabs.com id
	31/2F-31168-7EF8F1F4; Wed, 25 Jan 2012 05:15:19 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327468516!10555845!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAwNjYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8929 invoked from network); 25 Jan 2012 05:15:18 -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; 25 Jan 2012 05:15:18 -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
	q0P5FBGP012790
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 05:15:12 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
	q0P5FA6I012434
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 05:15:11 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
	q0P5F9DJ000342; Tue, 24 Jan 2012 23:15:09 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 24 Jan 2012 21:15:09 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0F9B7401A1; Wed, 25 Jan 2012 00:12:54 -0500 (EST)
Date: Wed, 25 Jan 2012 00:12:54 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, annie.li@oracle.com,
	xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@eu.citrix.com>
Message-ID: <20120125051253.GA15501@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120125044949.GB29759@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F1F8FE0.006F,ss=1,re=0.000,fgs=0
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> When I try to bootup a PVonHVM guest with Xen 4.1 I get this:

.. snip..
> 
> and with this little patch I can get it to work:

I get the domU to boot but the network stops being responsive.
I see this in the Dom0:


(XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
[ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
[ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15

Replacing the patch with:

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 1cd94da..b4d4eac 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -948,9 +948,12 @@ static void gnttab_request_version(void)
 	int rc;
 	struct gnttab_set_version gsv;
 
-	gsv.version = 2;
+	if (xen_hvm_domain())
+		gsv.version = 1;
+	else
+		gsv.version = 2;
 	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
-	if (rc == 0) {
+	if (rc == 0 && gsv.version == 2) {
 		grant_table_version = 2;
 		gnttab_interface = &gnttab_v2_ops;
 	} else if (grant_table_version == 2) {

Gets me back to how it worked in Linux v3.2.

But that is just a band-aid fix...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 07:51:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 07:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpxdP-0004Ug-0Q; Wed, 25 Jan 2012 07:51:11 +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 1RpxdN-0004UT-VS
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 07:51:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327477858!12270466!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18738 invoked from network); 25 Jan 2012 07:51:03 -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; 25 Jan 2012 07:51:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Jan 2012 07:50:57 +0000
Message-Id: <4F1FC2B9020000780006EC6B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Jan 2012 07:52:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Marcus Granado" <marcus.granado@citrix.com>
References: <4F19B62C.9020402@citrix.com>
	<4F1D3B79020000780006E509@nat28.tlf.novell.com>
	<4F1F062A.4080306@citrix.com>
In-Reply-To: <4F1F062A.4080306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xenoprof: Handle 32-bit guest stacks
 properly in a 64-bit 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 24.01.12 at 20:27, Marcus Granado <marcus.granado@citrix.com> wrote:
> I'm trying to understand the compat handle. It is not clear to me how to 
> map one from head (a 64-bit pointer), since COMPAT_HANDLE seems to store 

That cannot generally be done, as a 64-bit pointer can never be
represented as a compat handle.

Proper conversion has to start at where 'head' is first generated (i.e.
the line

    head = (struct frame_head *)regs->ebp;

in xenoprof_backtrace() (the more that here you really *want* to
drop the upper 32 bits in the compat case. Working with a union is
a possible approach, but it may also be acceptable to actually do
the truncation in dump_guest_backtrace(), properly explaining why
the dropping of the upper half is valid and intended there.

(I've already put fixing up of this already committed patch on my
todo list, so feel free to drop further attempts; once I'm done I'd
appreciate review/testing of the code though.)

Jan

> a 32-bit compat_ptr_t value in its structure. Ideally, what I would like 
> to do is
> 
> COMPAT_HANDLE(char) guest_head = map_guest_handle_to_compat_handle 
> (guest_handle_from_ptr(head, char));
> or
> COMPAT_HANDLE(char) guest_head = compat_handle_from_ptr(head, char));
> but I can't find any equivalent functions in any header.
> 
> The following line compiles,
> COMPAT_HANDLE(char) guest_head = { (full_ptr_t)head };
> but it looks like, in this case, the compat handle structure in compat.h 
> will truncate the most significant bits from the head pointer, so 
> compat_handle_okay(guest_head,...) and 
> __copy_from_compat(...,guest_head,...) below will be using a truncated 
> pointer:
> 
>       56 static struct frame_head *
>       57 dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
>       58                      struct frame_head * head, int mode)
>       59 {
>       60     struct frame_head bufhead[2];
>       61
>       62 #ifdef CONFIG_X86_64
>       63     if ( is_32bit_vcpu(vcpu) )
>       64     {
>       65         COMPAT_HANDLE(char) guest_head = { (full_ptr_t)head };
>       66         struct frame_head_32bit bufhead32[2];
>       67         /* Also check accessibility of one struct frame_head 
> beyond */
>       68         if (!compat_handle_okay(guest_head, sizeof(bufhead32)))
>       69             return 0;
>       70         if (__copy_from_compat((char *)bufhead32, guest_head,
>       71                                      sizeof(bufhead32)))
>       72             return 0;
>       73         bufhead[0].ebp=(struct frame_head 
> *)(full_ptr_t)bufhead32[0].ebp;
>       74         bufhead[0].ret=bufhead32[0].ret;
>       75     }
>       76     else
>       77 #endif
> 
> Any advice? Maybe the best option in this case is to avoid the compat* 
> functions and to use the original guest* functions instead.
> 
> Thanks,
> Marcus




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 07:51:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 07:51:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpxdP-0004Ug-0Q; Wed, 25 Jan 2012 07:51:11 +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 1RpxdN-0004UT-VS
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 07:51:10 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327477858!12270466!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18738 invoked from network); 25 Jan 2012 07:51:03 -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; 25 Jan 2012 07:51:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Wed, 25 Jan 2012 07:50:57 +0000
Message-Id: <4F1FC2B9020000780006EC6B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Wed, 25 Jan 2012 07:52:09 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Marcus Granado" <marcus.granado@citrix.com>
References: <4F19B62C.9020402@citrix.com>
	<4F1D3B79020000780006E509@nat28.tlf.novell.com>
	<4F1F062A.4080306@citrix.com>
In-Reply-To: <4F1F062A.4080306@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 2/3] xenoprof: Handle 32-bit guest stacks
 properly in a 64-bit 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 24.01.12 at 20:27, Marcus Granado <marcus.granado@citrix.com> wrote:
> I'm trying to understand the compat handle. It is not clear to me how to 
> map one from head (a 64-bit pointer), since COMPAT_HANDLE seems to store 

That cannot generally be done, as a 64-bit pointer can never be
represented as a compat handle.

Proper conversion has to start at where 'head' is first generated (i.e.
the line

    head = (struct frame_head *)regs->ebp;

in xenoprof_backtrace() (the more that here you really *want* to
drop the upper 32 bits in the compat case. Working with a union is
a possible approach, but it may also be acceptable to actually do
the truncation in dump_guest_backtrace(), properly explaining why
the dropping of the upper half is valid and intended there.

(I've already put fixing up of this already committed patch on my
todo list, so feel free to drop further attempts; once I'm done I'd
appreciate review/testing of the code though.)

Jan

> a 32-bit compat_ptr_t value in its structure. Ideally, what I would like 
> to do is
> 
> COMPAT_HANDLE(char) guest_head = map_guest_handle_to_compat_handle 
> (guest_handle_from_ptr(head, char));
> or
> COMPAT_HANDLE(char) guest_head = compat_handle_from_ptr(head, char));
> but I can't find any equivalent functions in any header.
> 
> The following line compiles,
> COMPAT_HANDLE(char) guest_head = { (full_ptr_t)head };
> but it looks like, in this case, the compat handle structure in compat.h 
> will truncate the most significant bits from the head pointer, so 
> compat_handle_okay(guest_head,...) and 
> __copy_from_compat(...,guest_head,...) below will be using a truncated 
> pointer:
> 
>       56 static struct frame_head *
>       57 dump_guest_backtrace(struct domain *d, struct vcpu *vcpu,
>       58                      struct frame_head * head, int mode)
>       59 {
>       60     struct frame_head bufhead[2];
>       61
>       62 #ifdef CONFIG_X86_64
>       63     if ( is_32bit_vcpu(vcpu) )
>       64     {
>       65         COMPAT_HANDLE(char) guest_head = { (full_ptr_t)head };
>       66         struct frame_head_32bit bufhead32[2];
>       67         /* Also check accessibility of one struct frame_head 
> beyond */
>       68         if (!compat_handle_okay(guest_head, sizeof(bufhead32)))
>       69             return 0;
>       70         if (__copy_from_compat((char *)bufhead32, guest_head,
>       71                                      sizeof(bufhead32)))
>       72             return 0;
>       73         bufhead[0].ebp=(struct frame_head 
> *)(full_ptr_t)bufhead32[0].ebp;
>       74         bufhead[0].ret=bufhead32[0].ret;
>       75     }
>       76     else
>       77 #endif
> 
> Any advice? Maybe the best option in this case is to avoid the compat* 
> functions and to use the original guest* functions instead.
> 
> Thanks,
> Marcus




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 08:27:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1RpyBz-0005bj-Ex; Wed, 25 Jan 2012 08:26:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RpyBy-0005be-0s
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 08:26:54 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327480007!12401438!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9430 invoked from network); 25 Jan 2012 08:26:47 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-11.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 08:26:47 -0000
Received: (qmail 26561 invoked from network); 25 Jan 2012 09:26:46 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 09:26:46 +0100
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:26:45 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201201171115.53993.pavel@netsafe.cz>
In-Reply-To: <201201171115.53993.pavel@netsafe.cz>
MIME-Version: 1.0
Message-Id: <201201250926.45689.pavel@netsafe.cz>
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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't hear sound in DomU. Hmm, to be honest I've heard some broken
> pieces,..

Problem found:
You can't load linux ALSA driver before you pass the sound card to the virtual 
machine. Since I removed linux kernel driver Windows play sounds just fine.
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 08:27:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1RpyBz-0005bj-Ex; Wed, 25 Jan 2012 08:26:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RpyBy-0005be-0s
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 08:26:54 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327480007!12401438!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9430 invoked from network); 25 Jan 2012 08:26:47 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-11.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 08:26:47 -0000
Received: (qmail 26561 invoked from network); 25 Jan 2012 09:26:46 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 09:26:46 +0100
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:26:45 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <201201171115.53993.pavel@netsafe.cz>
In-Reply-To: <201201171115.53993.pavel@netsafe.cz>
MIME-Version: 1.0
Message-Id: <201201250926.45689.pavel@netsafe.cz>
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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't hear sound in DomU. Hmm, to be honest I've heard some broken
> pieces,..

Problem found:
You can't load linux ALSA driver before you pass the sound card to the virtual 
machine. Since I removed linux kernel driver Windows play sounds just fine.
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 09:14:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpyvU-0006ZO-5T; Wed, 25 Jan 2012 09:13:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmoya@mmoya.org>) id 1RpyvS-0006ZJ-GH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:13:54 +0000
X-Env-Sender: mmoya@mmoya.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327482817!4962481!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDgyODkgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21004 invoked from network); 25 Jan 2012 09:13:37 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 09:13:37 -0000
Received: by werb14 with SMTP id b14so13030830wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 01:13:37 -0800 (PST)
Received: by 10.180.84.133 with SMTP id z5mr9696802wiy.10.1327482817081;
	Wed, 25 Jan 2012 01:13:37 -0800 (PST)
Received: from [192.168.2.2] (209.pool85-48-91.dynamic.orange.es.
	[85.48.91.209])
	by mx.google.com with ESMTPS id j16sm23336176wie.4.2012.01.25.01.13.35
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 01:13:35 -0800 (PST)
Message-ID: <4F1FC7BE.7090402@mmoya.org>
Date: Wed, 25 Jan 2012 10:13:34 +0100
From: Maykel Moya <mmoya@mmoya.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.4
X-Gm-Message-State: ALoCoQlALMviuEhY19UFzXWL3RpyWxuiowkLHQll1qLhRGmUoaqyEFIp/VL+MdRaMeTaDd/ajqeG
Subject: [Xen-devel] Different network traffic measures (dom0 vs. 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

Hi,

I'm using Xen 4.0.1 with Linux 2.6.32-5-xen-amd64 (standard packages on
a Debian Squeeze system).

>From Xen Networking:

"Think of them (vif<id#>.0 @dom0 and eth0 @domU) as two ethernet
interfaces connected by an internal crossover ethernet cable."

My understanding of this internal crossover thing is that networking
statistics should be the same no matter if you measure it in the dom0
(vifN.N interface) or in the domU (eth0 interface). RX/TX values should
be the same, just inverted.

Nevertheless I'm getting ~20% larger values when traffic is measured in
dom0.

Just after starting the domU I ran this on the dom0:
.
root@dev1:~# while true; do date; cat
/sys/class/net/vif35.0/statistics/{r,t}x_bytes; sleep 1; done
...
Thu Jan 19 13:18:00 EST 2012
4826
466049
Thu Jan 19 13:18:01 EST 2012
4826
466580
Thu Jan 19 13:18:02 EST 2012
4826
467427
Thu Jan 19 13:18:03 EST 2012
4826
467910
Thu Jan 19 13:18:04 EST 2012
4826
468769
Thu Jan 19 13:18:05 EST 2012
4826
469764

and in the domU

root@node2050:~# while true; do date; cat
/sys/class/net/eth0/statistics/{r,t}x_bytes; sleep 1; done
 ...
Thu Jan 19 13:18:00 EST 2012
395229
5792
Thu Jan 19 13:18:01 EST 2012
395961
5792
Thu Jan 19 13:18:02 EST 2012
396617
5792
Thu Jan 19 13:18:03 EST 2012
397304
5792
Thu Jan 19 13:18:04 EST 2012
397735
5792
Thu Jan 19 13:18:05 EST 2012
398620
5792

I didn't found any relevant in Google. Posted a question in serverfault
(http://j.mp/zzDPuV), and there is no an answer yet. Asked in xen-users
and got no answer.

Do anybody have a clue about why the values are (that) different?  Seems
to me a Xen bug but I might be missing something.

Regards,
maykel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 09:14:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09:14:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpyvU-0006ZO-5T; Wed, 25 Jan 2012 09:13:56 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <mmoya@mmoya.org>) id 1RpyvS-0006ZJ-GH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:13:54 +0000
X-Env-Sender: mmoya@mmoya.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327482817!4962481!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_8,
	RCVD_BY_IP,spamassassin: ,async_handler: 
	YXN5bmNfZGVsYXk6IDcwNDgyODkgKHRpbWVvdXQp\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21004 invoked from network); 25 Jan 2012 09:13:37 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 09:13:37 -0000
Received: by werb14 with SMTP id b14so13030830wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 01:13:37 -0800 (PST)
Received: by 10.180.84.133 with SMTP id z5mr9696802wiy.10.1327482817081;
	Wed, 25 Jan 2012 01:13:37 -0800 (PST)
Received: from [192.168.2.2] (209.pool85-48-91.dynamic.orange.es.
	[85.48.91.209])
	by mx.google.com with ESMTPS id j16sm23336176wie.4.2012.01.25.01.13.35
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 01:13:35 -0800 (PST)
Message-ID: <4F1FC7BE.7090402@mmoya.org>
Date: Wed, 25 Jan 2012 10:13:34 +0100
From: Maykel Moya <mmoya@mmoya.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.4
X-Gm-Message-State: ALoCoQlALMviuEhY19UFzXWL3RpyWxuiowkLHQll1qLhRGmUoaqyEFIp/VL+MdRaMeTaDd/ajqeG
Subject: [Xen-devel] Different network traffic measures (dom0 vs. 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

Hi,

I'm using Xen 4.0.1 with Linux 2.6.32-5-xen-amd64 (standard packages on
a Debian Squeeze system).

>From Xen Networking:

"Think of them (vif<id#>.0 @dom0 and eth0 @domU) as two ethernet
interfaces connected by an internal crossover ethernet cable."

My understanding of this internal crossover thing is that networking
statistics should be the same no matter if you measure it in the dom0
(vifN.N interface) or in the domU (eth0 interface). RX/TX values should
be the same, just inverted.

Nevertheless I'm getting ~20% larger values when traffic is measured in
dom0.

Just after starting the domU I ran this on the dom0:
.
root@dev1:~# while true; do date; cat
/sys/class/net/vif35.0/statistics/{r,t}x_bytes; sleep 1; done
...
Thu Jan 19 13:18:00 EST 2012
4826
466049
Thu Jan 19 13:18:01 EST 2012
4826
466580
Thu Jan 19 13:18:02 EST 2012
4826
467427
Thu Jan 19 13:18:03 EST 2012
4826
467910
Thu Jan 19 13:18:04 EST 2012
4826
468769
Thu Jan 19 13:18:05 EST 2012
4826
469764

and in the domU

root@node2050:~# while true; do date; cat
/sys/class/net/eth0/statistics/{r,t}x_bytes; sleep 1; done
 ...
Thu Jan 19 13:18:00 EST 2012
395229
5792
Thu Jan 19 13:18:01 EST 2012
395961
5792
Thu Jan 19 13:18:02 EST 2012
396617
5792
Thu Jan 19 13:18:03 EST 2012
397304
5792
Thu Jan 19 13:18:04 EST 2012
397735
5792
Thu Jan 19 13:18:05 EST 2012
398620
5792

I didn't found any relevant in Google. Posted a question in serverfault
(http://j.mp/zzDPuV), and there is no an answer yet. Asked in xen-users
and got no answer.

Do anybody have a clue about why the values are (that) different?  Seems
to me a Xen bug but I might be missing something.

Regards,
maykel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 09:35:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09: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 1RpzG5-00074q-2r; Wed, 25 Jan 2012 09:35: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 1RpzG3-00074i-6a
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:35:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327484104!4965745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31689 invoked from network); 25 Jan 2012 09:35:04 -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;
	25 Jan 2012 09:35:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10266951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 09:35: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, 25 Jan 2012 09:35:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Wed, 25 Jan 2012 09:35:03 +0000
In-Reply-To: <1327441442.19932.140661027559101@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327440026.17019.16.camel@dagon.hellion.org.uk>
	<1327441442.19932.140661027559101@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327484103.24561.224.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 21:44 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> On Tue, Jan 24, 2012, at 09:20 PM, Ian Campbell wrote:
> > > I can't figure out how to get xl to output to a xend-debug.log (xm does,
> > > as expected).
> > 
> > They should be going to /var/log/xen/xen-hotplug.
> 
> Not a peep in there.  Not even a there, there.
> 
>  xl create test.cfg
> 
>  ls -al /var/log/xen/xen-hotplug
>   ls: cannot access /var/log/xen/xen-hotplug: No such file or directory

My mistake, it is /var/log/xen/xen-hotplug.log.

> > So, presumably either the xenstore_read_default is failing or domu is
> > zero length and the script is explicitly bailing here.
> > 
> > However I do not see anything like this anywhere in the hotplug script
> > shipped with Xen. Either this is a local modification
> 
> I haven't made any local modifications.  At least not intentionally.
> 
> Here's the vif-bridge script ==> http://pastebin.com/9nHESsqS

Seems to read domu and abort if it is not there but subsequently never
makes any use of the variable.

Anyway it seems that SuSE are on the case so I will leave this thread
here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 09:35:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09: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 1RpzG5-00074q-2r; Wed, 25 Jan 2012 09:35: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 1RpzG3-00074i-6a
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:35:11 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327484104!4965745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31689 invoked from network); 25 Jan 2012 09:35:04 -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;
	25 Jan 2012 09:35:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10266951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 09:35: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, 25 Jan 2012 09:35:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Date: Wed, 25 Jan 2012 09:35:03 +0000
In-Reply-To: <1327441442.19932.140661027559101@webmail.messagingengine.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327440026.17019.16.camel@dagon.hellion.org.uk>
	<1327441442.19932.140661027559101@webmail.messagingengine.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327484103.24561.224.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 21:44 +0000, erin.balid@inoutbox.com wrote:
> Hi Ian.
> 
> On Tue, Jan 24, 2012, at 09:20 PM, Ian Campbell wrote:
> > > I can't figure out how to get xl to output to a xend-debug.log (xm does,
> > > as expected).
> > 
> > They should be going to /var/log/xen/xen-hotplug.
> 
> Not a peep in there.  Not even a there, there.
> 
>  xl create test.cfg
> 
>  ls -al /var/log/xen/xen-hotplug
>   ls: cannot access /var/log/xen/xen-hotplug: No such file or directory

My mistake, it is /var/log/xen/xen-hotplug.log.

> > So, presumably either the xenstore_read_default is failing or domu is
> > zero length and the script is explicitly bailing here.
> > 
> > However I do not see anything like this anywhere in the hotplug script
> > shipped with Xen. Either this is a local modification
> 
> I haven't made any local modifications.  At least not intentionally.
> 
> Here's the vif-bridge script ==> http://pastebin.com/9nHESsqS

Seems to read domu and abort if it is not there but subsequently never
makes any use of the variable.

Anyway it seems that SuSE are on the case so I will leave this thread
here.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 09:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpzJd-0007B6-N3; Wed, 25 Jan 2012 09:38:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpzJc-0007Av-G2
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:38:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327484326!4966477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17614 invoked from network); 25 Jan 2012 09:38:46 -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;
	25 Jan 2012 09:38:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10267065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 09:38:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 09:38: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 1RpzJW-0006gB-0A;
	Wed, 25 Jan 2012 09:38:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RpzJV-00056Q-Vu;
	Wed, 25 Jan 2012 09:38:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11595-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Jan 2012 09:38:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11595: 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 11595 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11595/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 11591
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11591 pass in 11595
 test-amd64-i386-xend-winxpsp3 14 guest-start.2     fail in 11591 pass in 11595

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11591

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11591 never pass

version targeted for testing:
 xen                  a2a8089b1ffb
baseline version:
 xen                  a2a8089b1ffb

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Jan 25 09:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpzJd-0007B6-N3; Wed, 25 Jan 2012 09:38:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RpzJc-0007Av-G2
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:38:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327484326!4966477!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17614 invoked from network); 25 Jan 2012 09:38:46 -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;
	25 Jan 2012 09:38:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10267065"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 09:38:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 09:38: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 1RpzJW-0006gB-0A;
	Wed, 25 Jan 2012 09:38:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RpzJV-00056Q-Vu;
	Wed, 25 Jan 2012 09:38:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11595-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Wed, 25 Jan 2012 09:38:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11595: 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 11595 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11595/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-win7-amd64  7 windows-install            fail pass in 11591
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10 fail in 11591 pass in 11595
 test-amd64-i386-xend-winxpsp3 14 guest-start.2     fail in 11591 pass in 11595

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11591

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-i386-win          16 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11591 never pass

version targeted for testing:
 xen                  a2a8089b1ffb
baseline version:
 xen                  a2a8089b1ffb

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Jan 25 09:40:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09: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 1RpzKl-0007FZ-6K; Wed, 25 Jan 2012 09:40:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RpzKj-0007FJ-Nn
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:40:01 +0000
Received: from [85.158.138.51:39339] by server-7.bemta-3.messagelabs.com id
	21/7E-31267-0FDCF1F4; Wed, 25 Jan 2012 09:40:00 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327484400!10556110!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24925 invoked from network); 25 Jan 2012 09:40:00 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 09:40:00 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 0328CD3477F;
	Wed, 25 Jan 2012 10:40:00 +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 fbbFUUxHb5cp; Wed, 25 Jan 2012 10:39:55 +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 16B5ED34714;
	Wed, 25 Jan 2012 10:39:55 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Doug Magee <djmagee@mageenet.net>
Date: Wed, 25 Jan 2012 10:39:53 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<1327429905.7929.5.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327429905.7929.5.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201251039.54148.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Doug!

see below ....


Am Dienstag, 24. Januar 2012, 19:31:45 schrieb Doug Magee:
> On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > > Both setup have the "flaw" that they only work once - meaning
> > 
> > you
> > 
> > > > can't reboot
> > > > 
> > > > > your DomU , cause after the reboot the passed-through Card
> > 
> > doesnt
> > 
> > > > have correct
> > > > 
> > > > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > > > 
> > > > Windows XP and
> > > > 
> > > > > Windows7 )
> > > > 
> > > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > > > 
> > > > Anybody had luck with passing the card more than once to a guest?
> > 
> > With
> > 
> > > > any random set of patches?
> > 
> > I was a bit un-percice regarding the "reboot" issue:
> > 
> > The passing-through itself works even after a reboot of DomU - the
> > rebooted
> > System spits out its Graphics normaly through the passed-through Card
> > (NVIDA
> > or ATI doesnt matter here) ; BUT:
> > After a reboot it doesn't work properly. Meaning: Slow 3d Performance,
> > i.e.
> > unsable for real 3d apps, even a 3d Desktop;
> > For example, when the Card gives you 70fps in a Benchmark after a
> > fresh Cold
> > Boot, it only gives you 5-10fps after a reboot, this will be that low
> > until
> > you reboot Dom0 also, not only DomU;
> > 
> > hopefully i described the scenario better now...
> 
> Ah, got it.  I hadn't been doing anything 3D intensive, only running the
> Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.  I
> get the same results (within a fraction of a %) after a cold boot as i
> do after rebooting multiple times, and always very close to native.  It
> seems i don't have the problem you're having.
> 
> Do you get any different log messages after a reboot (xl dmesg, dom0
> dmesg, qemu log)?  Have you tried with iommu=verbose to see if there's
> any more useful information there?
> 

Cool. Finally someone NOT suffering the reboot-performance-regression-Problem 
:)

I searched back and forth, rebooted DomU like crazy, diff'ed the 
dmesg/xldmesg/qemu-dm - but no difference :(

What kind of ATI Card are you passing through? 


Would be nice to find out whats causing this...

Greetings!
Tobias


> > > Yes, I've had a machine running for a couple of weeks, hosting a
> > 
> > Windows
> > 
> > > 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> > > machine multiple times, as well as gone through a couple of xl
> > > destroy/create cycles.
> > > 
> > > I only pass it through as a secondary card, as I have the IGD as the
> > > primary on the host.  The machine is a DQ67SW with a Core i5.  This
> > 
> > is
> > 
> > > running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> > 
> > patches.
> > 
> > > I haven't, however, had any luck passing through the IGD to anything
> > > other than a Windows XP, and that includes running the latest
> > 
> > qemu-xen
> > 
> > > with Jean's patches (opregion, host bridge config space mapping).
> > 
> > I've
> > 
> > > been intending to start a separate thread for that...
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 09:40:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09: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 1RpzKl-0007FZ-6K; Wed, 25 Jan 2012 09:40:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <tobias.geiger@vido.info>) id 1RpzKj-0007FJ-Nn
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:40:01 +0000
Received: from [85.158.138.51:39339] by server-7.bemta-3.messagelabs.com id
	21/7E-31267-0FDCF1F4; Wed, 25 Jan 2012 09:40:00 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327484400!10556110!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24925 invoked from network); 25 Jan 2012 09:40:00 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-2.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 09:40:00 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 0328CD3477F;
	Wed, 25 Jan 2012 10:40:00 +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 fbbFUUxHb5cp; Wed, 25 Jan 2012 10:39:55 +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 16B5ED34714;
	Wed, 25 Jan 2012 10:39:55 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Doug Magee <djmagee@mageenet.net>
Date: Wed, 25 Jan 2012 10:39:53 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<1327429905.7929.5.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327429905.7929.5.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201251039.54148.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Doug!

see below ....


Am Dienstag, 24. Januar 2012, 19:31:45 schrieb Doug Magee:
> On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > > Both setup have the "flaw" that they only work once - meaning
> > 
> > you
> > 
> > > > can't reboot
> > > > 
> > > > > your DomU , cause after the reboot the passed-through Card
> > 
> > doesnt
> > 
> > > > have correct
> > > > 
> > > > > 3D-Accelleration any more (was/is the case with NVIDIA and ATI,
> > > > 
> > > > Windows XP and
> > > > 
> > > > > Windows7 )
> > > > 
> > > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > > > 
> > > > Anybody had luck with passing the card more than once to a guest?
> > 
> > With
> > 
> > > > any random set of patches?
> > 
> > I was a bit un-percice regarding the "reboot" issue:
> > 
> > The passing-through itself works even after a reboot of DomU - the
> > rebooted
> > System spits out its Graphics normaly through the passed-through Card
> > (NVIDA
> > or ATI doesnt matter here) ; BUT:
> > After a reboot it doesn't work properly. Meaning: Slow 3d Performance,
> > i.e.
> > unsable for real 3d apps, even a 3d Desktop;
> > For example, when the Card gives you 70fps in a Benchmark after a
> > fresh Cold
> > Boot, it only gives you 5-10fps after a reboot, this will be that low
> > until
> > you reboot Dom0 also, not only DomU;
> > 
> > hopefully i described the scenario better now...
> 
> Ah, got it.  I hadn't been doing anything 3D intensive, only running the
> Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.  I
> get the same results (within a fraction of a %) after a cold boot as i
> do after rebooting multiple times, and always very close to native.  It
> seems i don't have the problem you're having.
> 
> Do you get any different log messages after a reboot (xl dmesg, dom0
> dmesg, qemu log)?  Have you tried with iommu=verbose to see if there's
> any more useful information there?
> 

Cool. Finally someone NOT suffering the reboot-performance-regression-Problem 
:)

I searched back and forth, rebooted DomU like crazy, diff'ed the 
dmesg/xldmesg/qemu-dm - but no difference :(

What kind of ATI Card are you passing through? 


Would be nice to find out whats causing this...

Greetings!
Tobias


> > > Yes, I've had a machine running for a couple of weeks, hosting a
> > 
> > Windows
> > 
> > > 7 domu with a passed-through Radeon 4770.  I've rebooted the virtual
> > > machine multiple times, as well as gone through a couple of xl
> > > destroy/create cycles.
> > > 
> > > I only pass it through as a secondary card, as I have the IGD as the
> > > primary on the host.  The machine is a DQ67SW with a Core i5.  This
> > 
> > is
> > 
> > > running xen-unstable (c/s 24465) on a 3.2.1 dom0, with no extra
> > 
> > patches.
> > 
> > > I haven't, however, had any luck passing through the IGD to anything
> > > other than a Windows XP, and that includes running the latest
> > 
> > qemu-xen
> > 
> > > with Jean's patches (opregion, host bridge config space mapping).
> > 
> > I've
> > 
> > > been intending to start a separate thread for that...
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 09:56:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpzZq-00086m-5m; Wed, 25 Jan 2012 09:55:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpzZo-00086U-IR
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:55:36 +0000
Received: from [85.158.138.51:51286] by server-2.bemta-3.messagelabs.com id
	29/7C-24515-791DF1F4; Wed, 25 Jan 2012 09:55:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327485334!10409598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24383 invoked from network); 25 Jan 2012 09:55:35 -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;
	25 Jan 2012 09:55:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10267552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 09:55: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, 25 Jan 2012 09:55:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 09:55:33 +0000
In-Reply-To: <20120125051253.GA15501@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327485333.24561.232.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "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>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> 
> .. snip..
> > 
> > and with this little patch I can get it to work:
> 
> I get the domU to boot but the network stops being responsive.
> I see this in the Dom0:

Your original patch would set the version to two in the hypervisor and
then ignore that and continue to use v1 so that isn't surprising.

> (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> 
> Replacing the patch with:
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 1cd94da..b4d4eac 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	gsv.version = 2;
> +	if (xen_hvm_domain())
> +		gsv.version = 1;
> +	else
> +		gsv.version = 2;
>  	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> -	if (rc == 0) {
> +	if (rc == 0 && gsv.version == 2) {
>  		grant_table_version = 2;
>  		gnttab_interface = &gnttab_v2_ops;
>  	} else if (grant_table_version == 2) {
> 
> Gets me back to how it worked in Linux v3.2.
> 
> But that is just a band-aid fix...

The real bug is presumably either that the Linux v2 code is buggy for
use in an HVM guest or that Xen's support for v2 in HVM guests is either
buggy or explicitly disabled (in which case set_version should fail for
version=2).

Is the set_version with version=1 succeeding or failing? Likewise for
the version=2 call?

The original error was an "unable to handle kernel NULL pointer
dereference at" gnttab_end_foreign_access_ref_v2+0x29/0x40. The only
plausible candidates for such an error are the array access into to
either the gnttab_shared or grstatus arrays. Do you know which one the
IP corresponds to?

On HVM for gnttab_shared we make an add_to_physmap call with
XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
do something similar for the status array though and I don't see a
XENMAPSPACE_* specifically for that case either in the hypervisor
either.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 09:56:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 09:56:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpzZq-00086m-5m; Wed, 25 Jan 2012 09:55:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RpzZo-00086U-IR
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 09:55:36 +0000
Received: from [85.158.138.51:51286] by server-2.bemta-3.messagelabs.com id
	29/7C-24515-791DF1F4; Wed, 25 Jan 2012 09:55:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327485334!10409598!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24383 invoked from network); 25 Jan 2012 09:55:35 -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;
	25 Jan 2012 09:55:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10267552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 09:55: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, 25 Jan 2012 09:55:34 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 09:55:33 +0000
In-Reply-To: <20120125051253.GA15501@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327485333.24561.232.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "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>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> 
> .. snip..
> > 
> > and with this little patch I can get it to work:
> 
> I get the domU to boot but the network stops being responsive.
> I see this in the Dom0:

Your original patch would set the version to two in the hypervisor and
then ignore that and continue to use v1 so that isn't surprising.

> (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> 
> Replacing the patch with:
> 
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 1cd94da..b4d4eac 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
>  	int rc;
>  	struct gnttab_set_version gsv;
>  
> -	gsv.version = 2;
> +	if (xen_hvm_domain())
> +		gsv.version = 1;
> +	else
> +		gsv.version = 2;
>  	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> -	if (rc == 0) {
> +	if (rc == 0 && gsv.version == 2) {
>  		grant_table_version = 2;
>  		gnttab_interface = &gnttab_v2_ops;
>  	} else if (grant_table_version == 2) {
> 
> Gets me back to how it worked in Linux v3.2.
> 
> But that is just a band-aid fix...

The real bug is presumably either that the Linux v2 code is buggy for
use in an HVM guest or that Xen's support for v2 in HVM guests is either
buggy or explicitly disabled (in which case set_version should fail for
version=2).

Is the set_version with version=1 succeeding or failing? Likewise for
the version=2 call?

The original error was an "unable to handle kernel NULL pointer
dereference at" gnttab_end_foreign_access_ref_v2+0x29/0x40. The only
plausible candidates for such an error are the array access into to
either the gnttab_shared or grstatus arrays. Do you know which one the
IP corresponds to?

On HVM for gnttab_shared we make an add_to_physmap call with
XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
do something similar for the status array though and I don't see a
XENMAPSPACE_* specifically for that case either in the hypervisor
either.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:02:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpzgH-0008Vj-6m; Wed, 25 Jan 2012 10:02:17 +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 1RpzgF-0008VO-FI
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:02:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327485726!12426264!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19588 invoked from network); 25 Jan 2012 10:02:08 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:02:08 -0000
Received: by qcsd15 with SMTP id d15so46530033qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 02:02: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=u3Md79V9NCtuAfn0e9PLy86eUxeskCJBs0n16cymymg=;
	b=qaO0Do3Ekz7mAwvZr3yCSSw4hahZX+qU9dN7MeMRkndQ/g2glYAhTHeZEB4UnlPzp6
	rtGgS3e5zd57m34AkrVQh8v2ZLYQflDTCFgJrw+9MVxDQXvpO0jVqxjlgkjqNfUSGDWQ
	ydVyTnljZvZSWJopkA6v420Ch0ew9KbWOlgFc=
MIME-Version: 1.0
Received: by 10.229.78.206 with SMTP id m14mr5667088qck.78.1327485726096; Wed,
	25 Jan 2012 02:02:06 -0800 (PST)
Received: by 10.229.245.72 with HTTP; Wed, 25 Jan 2012 02:02:05 -0800 (PST)
In-Reply-To: <20254.63246.632221.124056@mariner.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<20254.63246.632221.124056@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 11:02:05 +0100
X-Google-Sender-Auth: riP01kHrM_rimItiuB8yvLQIzak
Message-ID: <CAPLaKK4FqCMydSVeZSzZLN943Y2GHJnvH50kkW0xjKtYvThh2Q@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

MjAxMi8xLzI0IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggdjJdIGxpYnhsOiBh
ZGQgc3VwcG9ydCBmb3IgeWFqbCAyLngiKToKPj4gRG9uJ3Qga25vdyBob3cgZGlmZmljdWx0IGl0
IGlzIHRvIHVwZGF0ZSB0aGUgdGVzdCBiZWQgdG8gdXNlIHRoZSBuZXcKPj4gY29uZmlndXJlIHNj
cmlwdCwgaWRlYWxseSBpdCBzaG91bGQgb25seSByZXF1aXJlIGFkZGluZyAiLi9jb25maWd1cmUi
Cj4+IGJlZm9yZSBwZXJmb3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cg
aG93IHRoZSB0ZXN0IGJlZAo+PiB3b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mg
c29tZSBvcHRpb25zIHRvIGNvbmZpZ3VyZQo+PiBleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1l
IHJlc3VsdC4KPgo+IEN1cnJlbnRseSB0aGUgdGVzdGVyIGRyb3BzIGEgLmNvbmZpZyBpbiB0aGUg
cm9vdCBkaXJlY3RvcnkgY29udGFpbmluZwo+IHZhcmlvdXMgdGFncyBhbmQgdXJscyBvZiB0aGUg
c3VidHJlZXMgdGhhdCB0aGUgeGVuIHRyZWUgY2xvbmVzLiDCoElzCj4gdGhhdCBzdHVmZiBhZmZl
Y3RlZCBieSB5b3VyIGF1dG9jb25mIHNlcmllcyA/CgpEb24ndCB0aGluayBzbywgdGhlIG9ubHkg
dGhpbmcgdGhhdCBtaWdodCBjaGFuZ2UgaXMgdGhlIHByZWZpeCBwYXRoLAppZiB5b3Ugd2hlcmUg
dXNpbmcgUFJFRklYLCB5b3Ugc2hvdWxkIHBhc3MgLS1wcmVmaXg9Ly4uLiB0byBjb25maWd1cmUK
c2NyaXB0IGluc3RlYWQgb2Ygc2V0dGluZyBpdCBvbiAuY29uZmlnIG9yIGVudiB2YXJpYWJsZS4g
SWYgeW91IHdhbnQsCnlvdSBjYW4gdGFrZSBhIGxvb2sgYXQgdGhlIG1ha2VmaWxlIHZhcmlhYmxl
cyBkZWZpbmVkIGZyb20gY29uZmlndXJlLAp0aGUgdGVtcGxhdGUgaXMgaW4gY29uZmlnL1Rvb2xz
Lm1rLmluLgoKSWYgeW91IHdoZXJlIHNldHRpbmcgYW55IG9mIHRoZSB2YXJpYWJsZXMgZGVmaW5l
ZCBpbgp0b29scy9Ub29scy5tay5pbiwgY2hlY2sgZm9yIHRoZSBhcHByb3ByaWF0ZSB3YXkgb2Yg
c2V0dGluZyBpdCBmcm9tCmNvbmZpZ3VyZSAoZWl0aGVyIGJ5IHBhc3NpbmcgLS1lbmFibGUtZm9v
IG9yIGJ5IHNldHRpbmcgdGhlIGNvcnJlY3QKZW52aXJvbm1lbnQgdmFyaWFibGUgd2hlbiBleGVj
dXRpbmcgY29uZmlndXJlIHNjcmlwdCkuCgo+IEkgY2FuIGVhc2lseSBlbm91Z2ggaGF2ZSBpdCB0
ZXN0IHdoZXRoZXIgLi9jb25maWd1cmUgZXhpc3RzIGFuZCBtYWtlCj4gaXQgcnVuIGl0IGlmIGl0
IGRvZXMuCgpUaGF0IHNvdW5kcyBvaywgY291bGQgeW91IHRlc3QgaXQgYmVmb3JlIHB1c2hpbmcg
dGhlIGNoYW5nZT8gSSBkb24ndAp3YW50IHRvIGJyZWFrIHlvdXIgdGVzdCBiZWQuCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:02:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:02:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RpzgH-0008Vj-6m; Wed, 25 Jan 2012 10:02:17 +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 1RpzgF-0008VO-FI
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:02:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327485726!12426264!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19588 invoked from network); 25 Jan 2012 10:02:08 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:02:08 -0000
Received: by qcsd15 with SMTP id d15so46530033qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 02:02: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=u3Md79V9NCtuAfn0e9PLy86eUxeskCJBs0n16cymymg=;
	b=qaO0Do3Ekz7mAwvZr3yCSSw4hahZX+qU9dN7MeMRkndQ/g2glYAhTHeZEB4UnlPzp6
	rtGgS3e5zd57m34AkrVQh8v2ZLYQflDTCFgJrw+9MVxDQXvpO0jVqxjlgkjqNfUSGDWQ
	ydVyTnljZvZSWJopkA6v420Ch0ew9KbWOlgFc=
MIME-Version: 1.0
Received: by 10.229.78.206 with SMTP id m14mr5667088qck.78.1327485726096; Wed,
	25 Jan 2012 02:02:06 -0800 (PST)
Received: by 10.229.245.72 with HTTP; Wed, 25 Jan 2012 02:02:05 -0800 (PST)
In-Reply-To: <20254.63246.632221.124056@mariner.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<20254.63246.632221.124056@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 11:02:05 +0100
X-Google-Sender-Auth: riP01kHrM_rimItiuB8yvLQIzak
Message-ID: <CAPLaKK4FqCMydSVeZSzZLN943Y2GHJnvH50kkW0xjKtYvThh2Q@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

MjAxMi8xLzI0IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubsOpIHdyaXRlcyAoIlJlOiBbWGVuLWRldmVsXSBbUEFUQ0ggdjJdIGxpYnhsOiBh
ZGQgc3VwcG9ydCBmb3IgeWFqbCAyLngiKToKPj4gRG9uJ3Qga25vdyBob3cgZGlmZmljdWx0IGl0
IGlzIHRvIHVwZGF0ZSB0aGUgdGVzdCBiZWQgdG8gdXNlIHRoZSBuZXcKPj4gY29uZmlndXJlIHNj
cmlwdCwgaWRlYWxseSBpdCBzaG91bGQgb25seSByZXF1aXJlIGFkZGluZyAiLi9jb25maWd1cmUi
Cj4+IGJlZm9yZSBwZXJmb3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cg
aG93IHRoZSB0ZXN0IGJlZAo+PiB3b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mg
c29tZSBvcHRpb25zIHRvIGNvbmZpZ3VyZQo+PiBleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1l
IHJlc3VsdC4KPgo+IEN1cnJlbnRseSB0aGUgdGVzdGVyIGRyb3BzIGEgLmNvbmZpZyBpbiB0aGUg
cm9vdCBkaXJlY3RvcnkgY29udGFpbmluZwo+IHZhcmlvdXMgdGFncyBhbmQgdXJscyBvZiB0aGUg
c3VidHJlZXMgdGhhdCB0aGUgeGVuIHRyZWUgY2xvbmVzLiDCoElzCj4gdGhhdCBzdHVmZiBhZmZl
Y3RlZCBieSB5b3VyIGF1dG9jb25mIHNlcmllcyA/CgpEb24ndCB0aGluayBzbywgdGhlIG9ubHkg
dGhpbmcgdGhhdCBtaWdodCBjaGFuZ2UgaXMgdGhlIHByZWZpeCBwYXRoLAppZiB5b3Ugd2hlcmUg
dXNpbmcgUFJFRklYLCB5b3Ugc2hvdWxkIHBhc3MgLS1wcmVmaXg9Ly4uLiB0byBjb25maWd1cmUK
c2NyaXB0IGluc3RlYWQgb2Ygc2V0dGluZyBpdCBvbiAuY29uZmlnIG9yIGVudiB2YXJpYWJsZS4g
SWYgeW91IHdhbnQsCnlvdSBjYW4gdGFrZSBhIGxvb2sgYXQgdGhlIG1ha2VmaWxlIHZhcmlhYmxl
cyBkZWZpbmVkIGZyb20gY29uZmlndXJlLAp0aGUgdGVtcGxhdGUgaXMgaW4gY29uZmlnL1Rvb2xz
Lm1rLmluLgoKSWYgeW91IHdoZXJlIHNldHRpbmcgYW55IG9mIHRoZSB2YXJpYWJsZXMgZGVmaW5l
ZCBpbgp0b29scy9Ub29scy5tay5pbiwgY2hlY2sgZm9yIHRoZSBhcHByb3ByaWF0ZSB3YXkgb2Yg
c2V0dGluZyBpdCBmcm9tCmNvbmZpZ3VyZSAoZWl0aGVyIGJ5IHBhc3NpbmcgLS1lbmFibGUtZm9v
IG9yIGJ5IHNldHRpbmcgdGhlIGNvcnJlY3QKZW52aXJvbm1lbnQgdmFyaWFibGUgd2hlbiBleGVj
dXRpbmcgY29uZmlndXJlIHNjcmlwdCkuCgo+IEkgY2FuIGVhc2lseSBlbm91Z2ggaGF2ZSBpdCB0
ZXN0IHdoZXRoZXIgLi9jb25maWd1cmUgZXhpc3RzIGFuZCBtYWtlCj4gaXQgcnVuIGl0IGlmIGl0
IGRvZXMuCgpUaGF0IHNvdW5kcyBvaywgY291bGQgeW91IHRlc3QgaXQgYmVmb3JlIHB1c2hpbmcg
dGhlIGNoYW5nZT8gSSBkb24ndAp3YW50IHRvIGJyZWFrIHlvdXIgdGVzdCBiZWQuCgpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGlu
ZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3Vy
Y2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:12:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:12:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpzpa-0000JD-9c; Wed, 25 Jan 2012 10:11:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RpzpY-0000J8-CW
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:11:52 +0000
Received: from [85.158.138.51:19484] by server-8.bemta-3.messagelabs.com id
	C2/0C-31878-765DF1F4; Wed, 25 Jan 2012 10:11:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327486309!10519257!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5058 invoked from network); 25 Jan 2012 10:11:50 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:11:50 -0000
Received: by qcsd15 with SMTP id d15so46589753qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 02:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=HvA68utDlPApD/Yips+aFPgr95jGqQgDKXV0bz5Uz/E=;
	b=KGm20Q5R25KJtvrfZRxcBNw1v464uVN7GpUitRVAtMMxlsMsOoguSfbIN87Z1PhGZg
	iNN+LtivxGXCwqsg+hVUPdyS9IprwmeH08GLoV9Ytt9oCaOeba0dokYgXF2ZppgwVgjT
	mtSpX3cLOs2eLXn9cx1W4tviu67qayEbl5Ckg=
MIME-Version: 1.0
Received: by 10.229.111.141 with SMTP id s13mr3750867qcp.38.1327486308969;
	Wed, 25 Jan 2012 02:11:48 -0800 (PST)
Received: by 10.229.245.72 with HTTP; Wed, 25 Jan 2012 02:11:48 -0800 (PST)
In-Reply-To: <1327318760.24561.73.camel@zakaz.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 11:11:48 +0100
X-Google-Sender-Auth: 5y_Iij60-HoHBzLVSg7qdegoCzg
Message-ID: <CAPLaKK7yBoKFybmPvco+qvBV_HQxGvvvwHxw-HySsjmXmW9M5Q@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 \(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 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

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMS0yMyBhdCAxMTozMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IFR1ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+ID4+
IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDog
YWRkIHN1cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+ID4+ID4gT24gVGh1LCAyMDExLTEyLTIyIGF0
IDE2OjQxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiA+PiA+ID4gU29tZSBhdXRv
Z29vIHN0dWZmIHdpbGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRoZSB0b29scyBidWlsZC4gQ2Fu
IHlvdQo+PiA+PiA+ID4gc2V0IHVwIHRoZSBiYXNpYyBzdHJ1Y3R1cmUgSWFuPwo+PiA+PiA+Cj4+
ID4+ID4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+PiA+
PiA+Cj4+ID4+ID4gV291bGQgaXQgYmUgc3VmZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0
b29scy9jaGVjayBjcmVhdGUgYQo+PiA+PiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhl
IGNoZWNrcz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+PiA+PiA+IHRvIGJl
IHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+PiA+Pgo+PiA+PiBGb3Igbm93LCBJIHRo
aW5rIHdlIHNob3VsZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhlIGNyaXRpY2FsIHBhdGggZm9y
Cj4+ID4+IFhlbiA0LjIuIMKgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxkIHN3aXRjaCB0byBhdXRv
Y29uZiBJIHRoaW5rLiDCoChJCj4+ID4+IGRvbid0IGFwcHJvdmUgb2YgYXV0b21ha2UuKQo+PiA+
Cj4+ID4gSXQgc2VlbXMgdGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24gdGhlIGF1
dG9jb25mIHN0dWZmLiBDYW4gd2UKPj4gPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0IHdl
IGNhbiBzdXBwb3J0IHlhamwgMi4wIGluIFhlbiA0LjIgYW5kCj4+ID4gc3dpdGNoIHRvIGF1dG9j
b25mIGFmdGVyd2FyZHMgb3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRjaCB0bwo+
PiA+IGF1dG9jb25mIGZvciA0LjI/Cj4+Cj4+IFRoZSBwcm9wb3NlZCBhdXRvY29uZiBwYXRjaCBp
cyBqdXN0IGEgY29udmVuaWVudCByZXBsYWNlbWVudCBmb3IKPj4gdG9vbHMvY2hlY2sgc2NyaXB0
cywgd2hpY2ggYWxsb3dzIHVzIHRvIGdlbmVyYXRlIGEgbWFrZWZpbGUgYW5kIGEKPj4gaGVhZGVy
IHdlIGNhbiBpbmNsdWRlIHRvIGtub3cgdGhlIHN5c3RlbSBjYXBhYmlsaXRpZXMsIG5vdGhpbmcg
bW9yZQo+PiB3YXMgYWRkZWQuCj4+Cj4+ID4gSSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBhYm91
dCBjcml0aWNhbCBwYXRoIGZvciA0LjIuIEkgcHJlc3VtZQo+PiA+IGF1dG9jb25mIHdvdWxkIHJl
cXVpcmUgbW9yZSB0aGFuIGp1c3QgY2hlY2tpbmcgaW4gdGhlIHBhdGNoZXMsCj4+ID4gc3BlY2lm
aWNhbGx5IEknbSB0aGlua2luZyBvZiB0aGUgYXV0b21hdGVkIHRlc3Qgc3lzdGVtIHVwZGF0ZSBh
bmQgZG9jcy4KPj4KPj4gRG9uJ3Qga25vdyBob3cgZGlmZmljdWx0IGl0IGlzIHRvIHVwZGF0ZSB0
aGUgdGVzdCBiZWQgdG8gdXNlIHRoZSBuZXcKPj4gY29uZmlndXJlIHNjcmlwdCwgaWRlYWxseSBp
dCBzaG91bGQgb25seSByZXF1aXJlIGFkZGluZyAiLi9jb25maWd1cmUiCj4+IGJlZm9yZSBwZXJm
b3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cgaG93IHRoZSB0ZXN0IGJl
ZAo+PiB3b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mgc29tZSBvcHRpb25zIHRv
IGNvbmZpZ3VyZQo+PiBleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1lIHJlc3VsdC4KPgo+IElh
biBKIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHRoYXQgb25lLiBIb3BlZnVsbHkganVzdCBydW5uaW5n
IC4vY29uZmlndXJlCj4gd2lsbCBnZXQgdXMgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8gdGhlIGV4
aXN0aW5nIHNldHVwLgo+Cj4gRldJVyB0aGUgdGVzdGVyIGNvZGUgaXMgYXZhaWxhYmxlIGF0IGEg
Z2l0IHVybCB3aGljaCBpcyBpbiBldmVyeSBwb3N0ZWQKPiBzZXQgb2YgcmVzdWx0cy4gUHJvYmFi
bHkgbG9va2luZyBmb3IgYW55d2hlcmUgdGhhdCB3cml0ZXMgdG8gLmNvbmZpZwo+IHdvdWxkIGJl
IGEgZ29vZCBzdGFydCBmb3IgZGVjaWRpbmcgaG93IGZhciBmcm9tIHRoZSBkZWZhdWx0cyBpdCBk
ZXZpYXRlcwo+IChub3QgZmFyLCBJIGV4cGVjdCkuCj4KPj4gPiBPbiB0aGUgb3RoZXIgaGFuZCBS
b2dlciBwb3N0ZWQgdjMgb2YgaGlzIGF1dG9jb25mIHN1cHBvcnQgcGF0Y2ggYW5kCj4+ID4gYWx0
aG91Z2ggSSBoYXZlbid0IGdvdCByb3VuZCB0byByZXZpZXdpbmcgaXQgeWV0IChzb3JyeSkgdjIn
cyByZXZpZXcgd2FzCj4+ID4gZ2VuZXJhbGx5IHBvc2l0aXZlL21pbm9yIGxvb2tpbmcuCj4+Cj4+
IHYzIGlzIGJhc2ljYWxseSBhIHYyIHdpdGggYWxsIHRoZSBtZW50aW9uZWQgZml4ZXMgYW5kIHRo
ZSBvdXRwdXQgZnJvbQo+PiBhdXRvY29uZiAmIGF1dG9tYWtlLCBzbyB3ZSBjYW4gdXNlIHRoZSBj
b25maWd1cmUgc2NyaXB0IHN0cmFpZ2h0IGF3YXkuCj4KPiBhdXRvbWFrZT8gSSB0aG91Z2h0IHdl
IGFncmVlZCBub3QgdG8gdXNlIHRoYXQ/Cj4KPj4gQW55d2F5LCB0aGlzIHBhdGNoIGZvciBhZGRp
bmcgc3VwcG9ydCBvZiB5YWpsIDIuMCBuZWVkcyBzb21lIHJld29yaywKPj4gYWNjb3JkaW5nIHRv
IHRoZSBjb21tZW50cyBtYWRlIGJ5IElhbiBKYWNrc29uLCB3aGljaCBJIHdpbGwgdHJ5IHRvIGRv
Cj4+IGJlZm9yZSB0aGUgZW5kIG9mIHRoZSB3ZWVrIChzb3JyeSBmb3IgdGhlIGRlbGF5LCBidXQg
SSdtIHF1aXRlIGJ1c3kKPj4gdGhpcyBkYXlzKS4KPgo+IFN1cmUsIG5vIHByb2JsZW0uIEkgaGF2
ZSBwdXQgeWFqbDIgc3VwcG9ydCBpbiB0aGUgIm5pY2UgdG8gaGF2ZSBjb2x1bW4iCj4gYW5kIGF1
dG9jb25mIGluIGEgbmV3ICJuZWVkIHRvIGRlY2lkZSBpZiB0aGlzIGlzIDQuMiBvciA0LjMgbWF0
ZXJpYWwiCj4gY29sdW1uLgoKSSdtIGdvaW5nIHRvIHJlLXdvcmsgb24gdGhlIHlhamwgMi4wIHN1
cHBvcnQsIHRvIHRyeSB0byBmaXggdGhlCnJlbWFpbmluZyBpc3N1ZXMgd2l0aCB0aGlzIHBhdGNo
LiBKdXN0IHRvIGJlIGNsZWFyLCBzaG91bGQgSSByZWJhc2UKdGhpcyBwYXRjaCBiYXNlZCBvbiB0
aGUgYXV0b2NvbmYgc3R1ZmY/CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:12:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:12:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpzpa-0000JD-9c; Wed, 25 Jan 2012 10:11:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RpzpY-0000J8-CW
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:11:52 +0000
Received: from [85.158.138.51:19484] by server-8.bemta-3.messagelabs.com id
	C2/0C-31878-765DF1F4; Wed, 25 Jan 2012 10:11:51 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327486309!10519257!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5058 invoked from network); 25 Jan 2012 10:11:50 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:11:50 -0000
Received: by qcsd15 with SMTP id d15so46589753qcs.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 02:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=HvA68utDlPApD/Yips+aFPgr95jGqQgDKXV0bz5Uz/E=;
	b=KGm20Q5R25KJtvrfZRxcBNw1v464uVN7GpUitRVAtMMxlsMsOoguSfbIN87Z1PhGZg
	iNN+LtivxGXCwqsg+hVUPdyS9IprwmeH08GLoV9Ytt9oCaOeba0dokYgXF2ZppgwVgjT
	mtSpX3cLOs2eLXn9cx1W4tviu67qayEbl5Ckg=
MIME-Version: 1.0
Received: by 10.229.111.141 with SMTP id s13mr3750867qcp.38.1327486308969;
	Wed, 25 Jan 2012 02:11:48 -0800 (PST)
Received: by 10.229.245.72 with HTTP; Wed, 25 Jan 2012 02:11:48 -0800 (PST)
In-Reply-To: <1327318760.24561.73.camel@zakaz.uk.xensource.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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 11:11:48 +0100
X-Google-Sender-Auth: 5y_Iij60-HoHBzLVSg7qdegoCzg
Message-ID: <CAPLaKK7yBoKFybmPvco+qvBV_HQxGvvvwHxw-HySsjmXmW9M5Q@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 \(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 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

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIE1v
biwgMjAxMi0wMS0yMyBhdCAxMTozMCArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IFR1ZSwgMjAxMi0wMS0wMyBhdCAxODowMCArMDAwMCwgSWFuIEphY2tzb24gd3JvdGU6Cj4+ID4+
IElhbiBDYW1wYmVsbCB3cml0ZXMgKCJSZTogW1hlbi1kZXZlbF0gW1BBVENIIHYyXSBsaWJ4bDog
YWRkIHN1cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+ID4+ID4gT24gVGh1LCAyMDExLTEyLTIyIGF0
IDE2OjQxICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+PiA+PiA+ID4gU29tZSBhdXRv
Z29vIHN0dWZmIHdpbGwgYmUgZ29vZCwgYXQgbGVhc3QgZm9yIHRoZSB0b29scyBidWlsZC4gQ2Fu
IHlvdQo+PiA+PiA+ID4gc2V0IHVwIHRoZSBiYXNpYyBzdHJ1Y3R1cmUgSWFuPwo+PiA+PiA+Cj4+
ID4+ID4gSSdtIG5vdCBnb2luZyB0byBoYXZlIHRpbWUgaW4gdGhlIG5lYXIgZnV0dXJlLgo+PiA+
PiA+Cj4+ID4+ID4gV291bGQgaXQgYmUgc3VmZmljaWVudCB0byBoYXZlIHRoZSBzdHVmZiBpbiB0
b29scy9jaGVjayBjcmVhdGUgYQo+PiA+PiA+IGNvbmZpZy5oIGFzIHdlbGwgYXMgZG9pbmcgdGhl
IGNoZWNrcz8gTWlnaHQgbmVlZCBhIGJpdCBvZiBNYWtlZmlsZSBtYWdpYwo+PiA+PiA+IHRvIGJl
IHN1cmUgdGhhdCBjaGVjayBpcyBhbHdheXMgcnVuPwo+PiA+Pgo+PiA+PiBGb3Igbm93LCBJIHRo
aW5rIHdlIHNob3VsZCBub3QgYWRkIG1vcmUgc3R1ZmYgdG8gdGhlIGNyaXRpY2FsIHBhdGggZm9y
Cj4+ID4+IFhlbiA0LjIuIMKgQnV0IGFmdGVyIHRoZW4gd2Ugc2hvdWxkIHN3aXRjaCB0byBhdXRv
Y29uZiBJIHRoaW5rLiDCoChJCj4+ID4+IGRvbid0IGFwcHJvdmUgb2YgYXV0b21ha2UuKQo+PiA+
Cj4+ID4gSXQgc2VlbXMgdGhhdCB5YWpsIDIuMCBzdXBwb3J0IGlzIGJsb2NrZWQgb24gdGhlIGF1
dG9jb25mIHN0dWZmLiBDYW4gd2UKPj4gPiBkaXNlbnRhbmdsZSB0aGluZ3Mgc3VjaCB0aGF0IHdl
IGNhbiBzdXBwb3J0IHlhamwgMi4wIGluIFhlbiA0LjIgYW5kCj4+ID4gc3dpdGNoIHRvIGF1dG9j
b25mIGFmdGVyd2FyZHMgb3IgZG8gd2UgaGF2ZS93YW50IHRvIG1ha2UgdGhlIHN3aXRjaCB0bwo+
PiA+IGF1dG9jb25mIGZvciA0LjI/Cj4+Cj4+IFRoZSBwcm9wb3NlZCBhdXRvY29uZiBwYXRjaCBp
cyBqdXN0IGEgY29udmVuaWVudCByZXBsYWNlbWVudCBmb3IKPj4gdG9vbHMvY2hlY2sgc2NyaXB0
cywgd2hpY2ggYWxsb3dzIHVzIHRvIGdlbmVyYXRlIGEgbWFrZWZpbGUgYW5kIGEKPj4gaGVhZGVy
IHdlIGNhbiBpbmNsdWRlIHRvIGtub3cgdGhlIHN5c3RlbSBjYXBhYmlsaXRpZXMsIG5vdGhpbmcg
bW9yZQo+PiB3YXMgYWRkZWQuCj4+Cj4+ID4gSSBhcHByZWNpYXRlIHRoZSBjb25jZXJucyBhYm91
dCBjcml0aWNhbCBwYXRoIGZvciA0LjIuIEkgcHJlc3VtZQo+PiA+IGF1dG9jb25mIHdvdWxkIHJl
cXVpcmUgbW9yZSB0aGFuIGp1c3QgY2hlY2tpbmcgaW4gdGhlIHBhdGNoZXMsCj4+ID4gc3BlY2lm
aWNhbGx5IEknbSB0aGlua2luZyBvZiB0aGUgYXV0b21hdGVkIHRlc3Qgc3lzdGVtIHVwZGF0ZSBh
bmQgZG9jcy4KPj4KPj4gRG9uJ3Qga25vdyBob3cgZGlmZmljdWx0IGl0IGlzIHRvIHVwZGF0ZSB0
aGUgdGVzdCBiZWQgdG8gdXNlIHRoZSBuZXcKPj4gY29uZmlndXJlIHNjcmlwdCwgaWRlYWxseSBp
dCBzaG91bGQgb25seSByZXF1aXJlIGFkZGluZyAiLi9jb25maWd1cmUiCj4+IGJlZm9yZSBwZXJm
b3JtaW5nIGEgIm1ha2UgdG9vbHMiLiBTaW5jZSBJIGRvbid0IGtub3cgaG93IHRoZSB0ZXN0IGJl
ZAo+PiB3b3JrcywgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHBhc3Mgc29tZSBvcHRpb25zIHRv
IGNvbmZpZ3VyZQo+PiBleGVjdXRpb24gdG8gb2J0YWluIHRoZSBzYW1lIHJlc3VsdC4KPgo+IElh
biBKIHdvdWxkIGhhdmUgdG8gYW5zd2VyIHRoYXQgb25lLiBIb3BlZnVsbHkganVzdCBydW5uaW5n
IC4vY29uZmlndXJlCj4gd2lsbCBnZXQgdXMgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8gdGhlIGV4
aXN0aW5nIHNldHVwLgo+Cj4gRldJVyB0aGUgdGVzdGVyIGNvZGUgaXMgYXZhaWxhYmxlIGF0IGEg
Z2l0IHVybCB3aGljaCBpcyBpbiBldmVyeSBwb3N0ZWQKPiBzZXQgb2YgcmVzdWx0cy4gUHJvYmFi
bHkgbG9va2luZyBmb3IgYW55d2hlcmUgdGhhdCB3cml0ZXMgdG8gLmNvbmZpZwo+IHdvdWxkIGJl
IGEgZ29vZCBzdGFydCBmb3IgZGVjaWRpbmcgaG93IGZhciBmcm9tIHRoZSBkZWZhdWx0cyBpdCBk
ZXZpYXRlcwo+IChub3QgZmFyLCBJIGV4cGVjdCkuCj4KPj4gPiBPbiB0aGUgb3RoZXIgaGFuZCBS
b2dlciBwb3N0ZWQgdjMgb2YgaGlzIGF1dG9jb25mIHN1cHBvcnQgcGF0Y2ggYW5kCj4+ID4gYWx0
aG91Z2ggSSBoYXZlbid0IGdvdCByb3VuZCB0byByZXZpZXdpbmcgaXQgeWV0IChzb3JyeSkgdjIn
cyByZXZpZXcgd2FzCj4+ID4gZ2VuZXJhbGx5IHBvc2l0aXZlL21pbm9yIGxvb2tpbmcuCj4+Cj4+
IHYzIGlzIGJhc2ljYWxseSBhIHYyIHdpdGggYWxsIHRoZSBtZW50aW9uZWQgZml4ZXMgYW5kIHRo
ZSBvdXRwdXQgZnJvbQo+PiBhdXRvY29uZiAmIGF1dG9tYWtlLCBzbyB3ZSBjYW4gdXNlIHRoZSBj
b25maWd1cmUgc2NyaXB0IHN0cmFpZ2h0IGF3YXkuCj4KPiBhdXRvbWFrZT8gSSB0aG91Z2h0IHdl
IGFncmVlZCBub3QgdG8gdXNlIHRoYXQ/Cj4KPj4gQW55d2F5LCB0aGlzIHBhdGNoIGZvciBhZGRp
bmcgc3VwcG9ydCBvZiB5YWpsIDIuMCBuZWVkcyBzb21lIHJld29yaywKPj4gYWNjb3JkaW5nIHRv
IHRoZSBjb21tZW50cyBtYWRlIGJ5IElhbiBKYWNrc29uLCB3aGljaCBJIHdpbGwgdHJ5IHRvIGRv
Cj4+IGJlZm9yZSB0aGUgZW5kIG9mIHRoZSB3ZWVrIChzb3JyeSBmb3IgdGhlIGRlbGF5LCBidXQg
SSdtIHF1aXRlIGJ1c3kKPj4gdGhpcyBkYXlzKS4KPgo+IFN1cmUsIG5vIHByb2JsZW0uIEkgaGF2
ZSBwdXQgeWFqbDIgc3VwcG9ydCBpbiB0aGUgIm5pY2UgdG8gaGF2ZSBjb2x1bW4iCj4gYW5kIGF1
dG9jb25mIGluIGEgbmV3ICJuZWVkIHRvIGRlY2lkZSBpZiB0aGlzIGlzIDQuMiBvciA0LjMgbWF0
ZXJpYWwiCj4gY29sdW1uLgoKSSdtIGdvaW5nIHRvIHJlLXdvcmsgb24gdGhlIHlhamwgMi4wIHN1
cHBvcnQsIHRvIHRyeSB0byBmaXggdGhlCnJlbWFpbmluZyBpc3N1ZXMgd2l0aCB0aGlzIHBhdGNo
LiBKdXN0IHRvIGJlIGNsZWFyLCBzaG91bGQgSSByZWJhc2UKdGhpcyBwYXRjaCBiYXNlZCBvbiB0
aGUgYXV0b2NvbmYgc3R1ZmY/CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3Vy
Y2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:19:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpzwd-0000cE-C2; Wed, 25 Jan 2012 10:19:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rpzwc-0000c9-5t
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:19:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327486744!12420840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1795 invoked from network); 25 Jan 2012 10:19:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:19:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10268774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 10:19: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, 25 Jan 2012 10:19:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 25 Jan 2012 10:19:03 +0000
In-Reply-To: <1327342871.2476.14.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss> <1327342871.2476.14.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327486743.24561.250.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 1 of 2] libxl: extend pCPUs specification
	for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 18:21 +0000, Dario Faggioli wrote:
> Allow for "^<cpuid>" syntax while specifying the pCPUs list
> during a vcpu-pin. This enables doing the following:
> 
>  xl vcpu-pin 1 1 0-4,^2
> 
> and achieving:
> 
>  xl vcpu-list
>  Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>  ...
>  Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
>  ...
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Is 0-4,^2-3 (== 0-1,4) a useful thing to want to write? I don't think it
should block this patch going in though.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:19:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:19:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rpzwd-0000cE-C2; Wed, 25 Jan 2012 10:19:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rpzwc-0000c9-5t
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:19:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327486744!12420840!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1795 invoked from network); 25 Jan 2012 10:19:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:19:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10268774"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 10:19: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, 25 Jan 2012 10:19:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 25 Jan 2012 10:19:03 +0000
In-Reply-To: <1327342871.2476.14.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss> <1327342871.2476.14.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327486743.24561.250.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 1 of 2] libxl: extend pCPUs specification
	for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 18:21 +0000, Dario Faggioli wrote:
> Allow for "^<cpuid>" syntax while specifying the pCPUs list
> during a vcpu-pin. This enables doing the following:
> 
>  xl vcpu-pin 1 1 0-4,^2
> 
> and achieving:
> 
>  xl vcpu-list
>  Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>  ...
>  Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
>  ...
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Is 0-4,^2-3 (== 0-1,4) a useful thing to want to write? I don't think it
should block this patch going in though.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:28:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1Rq05i-0000wv-FY; Wed, 25 Jan 2012 10:28: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 1Rq05h-0000wn-7k
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:28:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327487306!9871017!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25996 invoked from network); 25 Jan 2012 10:28:26 -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;
	25 Jan 2012 10:28:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10269453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 10:28:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 10:28:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 25 Jan 2012 10:28:26 +0000
In-Reply-To: <1327342932.2476.15.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss> <1327342932.2476.15.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327487306.24561.258.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 2 of 2] libxl: allow for specifying the
 CPU affinity in the config file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 18:22 +0000, Dario Faggioli wrote:
> Enable CPU affinity specification in a VM's config file with the
> exact syntax `xl vcpu-pin' provides.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r d76603510485 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 23 18:02:42 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 23 18:02:47 2012 +0000
> @@ -2663,6 +2663,20 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
>      return 0;
>  }
>  
> +int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> +                               unsigned int max_vcpus, libxl_cpumap *cpumap)
> +{
> +    int i, rc = 0;
> +
> +    for (i = 0; i < max_vcpus; i++) 
> +        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "no affinity for cpu %d", i);

"failed to set affinity for ..." would better describe what had happened.

> +            rc = ERROR_FAIL;
> +        }
> +    }
> +    return rc;
> +}
> +
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>  {
>      GC_INIT(ctx);
[...]
>                                           if (libxl_cpumap_test(&(m), v))
> diff -r d76603510485 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:42 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:47 2012 +0000
> @@ -288,16 +288,72 @@ static void dolog(const char *file, int 
>          libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
>  }
>  
> +static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
> +{
[...]

I assumed this was pure code motion so I didn't read it.

> +}
> +
>  static void printf_info(int domid,
>                          libxl_domain_config *d_config,
>                          libxl_device_model_info *dm_info)
>  {
> -    int i;
> +    int i, nr_cpus = -1;
>      libxl_dominfo info;
> +    libxl_physinfo physinfo;
>  
>      libxl_domain_create_info *c_info = &d_config->c_info;
>      libxl_domain_build_info *b_info = &d_config->b_info;
>  
> +    if (libxl_get_physinfo(ctx, &physinfo) == 0)
> +        nr_cpus = physinfo.nr_cpus;
> +    else
> +        fprintf(stderr, "libxl_physinfo failed.\n");
> +
>      printf("(domain\n\t(domid %d)\n", domid);
>      printf("\t(create_info)\n");
>      printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
> @@ -328,6 +384,9 @@ static void printf_info(int domid,
>  
>      printf("\t(build_info)\n");
>      printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
> +    printf("\t(CPU affinity ");
> +    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);

If libxl_get_physinfo failed then nr_cpus would == -1 here.

However I don't think it is even necessary to extend this (legacy) sexp
any further. I'm about to send a patch which will use the print the json
representation (which is autogenerated).

If we were to extend it then it should match the xend/xm output since
it's only purpose is for xm compatibility.

> +    printf(")\n");
>      printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
>      printf("\t(max_memkb %d)\n", b_info->max_memkb);
>      printf("\t(target_memkb %d)\n", b_info->target_memkb);
> @@ -569,6 +628,8 @@ static void split_string_into_string_lis
>      free(s);
>  }
>  
> +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);

There are no calls to vcpupin_parse added after this point by this patch
so is this necessary? I'd prefer moving the function up in any case or
at least declaring all the forward references near the top of the file.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:28:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1Rq05i-0000wv-FY; Wed, 25 Jan 2012 10:28: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 1Rq05h-0000wn-7k
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:28:33 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327487306!9871017!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25996 invoked from network); 25 Jan 2012 10:28:26 -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;
	25 Jan 2012 10:28:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10269453"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 10:28:26 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 10:28:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 25 Jan 2012 10:28:26 +0000
In-Reply-To: <1327342932.2476.15.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss> <1327342932.2476.15.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327487306.24561.258.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 2 of 2] libxl: allow for specifying the
 CPU affinity in the config file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 18:22 +0000, Dario Faggioli wrote:
> Enable CPU affinity specification in a VM's config file with the
> exact syntax `xl vcpu-pin' provides.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r d76603510485 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 23 18:02:42 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 23 18:02:47 2012 +0000
> @@ -2663,6 +2663,20 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
>      return 0;
>  }
>  
> +int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> +                               unsigned int max_vcpus, libxl_cpumap *cpumap)
> +{
> +    int i, rc = 0;
> +
> +    for (i = 0; i < max_vcpus; i++) 
> +        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "no affinity for cpu %d", i);

"failed to set affinity for ..." would better describe what had happened.

> +            rc = ERROR_FAIL;
> +        }
> +    }
> +    return rc;
> +}
> +
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>  {
>      GC_INIT(ctx);
[...]
>                                           if (libxl_cpumap_test(&(m), v))
> diff -r d76603510485 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:42 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 23 18:02:47 2012 +0000
> @@ -288,16 +288,72 @@ static void dolog(const char *file, int 
>          libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
>  }
>  
> +static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
> +{
[...]

I assumed this was pure code motion so I didn't read it.

> +}
> +
>  static void printf_info(int domid,
>                          libxl_domain_config *d_config,
>                          libxl_device_model_info *dm_info)
>  {
> -    int i;
> +    int i, nr_cpus = -1;
>      libxl_dominfo info;
> +    libxl_physinfo physinfo;
>  
>      libxl_domain_create_info *c_info = &d_config->c_info;
>      libxl_domain_build_info *b_info = &d_config->b_info;
>  
> +    if (libxl_get_physinfo(ctx, &physinfo) == 0)
> +        nr_cpus = physinfo.nr_cpus;
> +    else
> +        fprintf(stderr, "libxl_physinfo failed.\n");
> +
>      printf("(domain\n\t(domid %d)\n", domid);
>      printf("\t(create_info)\n");
>      printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
> @@ -328,6 +384,9 @@ static void printf_info(int domid,
>  
>      printf("\t(build_info)\n");
>      printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
> +    printf("\t(CPU affinity ");
> +    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);

If libxl_get_physinfo failed then nr_cpus would == -1 here.

However I don't think it is even necessary to extend this (legacy) sexp
any further. I'm about to send a patch which will use the print the json
representation (which is autogenerated).

If we were to extend it then it should match the xend/xm output since
it's only purpose is for xm compatibility.

> +    printf(")\n");
>      printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
>      printf("\t(max_memkb %d)\n", b_info->max_memkb);
>      printf("\t(target_memkb %d)\n", b_info->target_memkb);
> @@ -569,6 +628,8 @@ static void split_string_into_string_lis
>      free(s);
>  }
>  
> +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);

There are no calls to vcpupin_parse added after this point by this patch
so is this necessary? I'd prefer moving the function up in any case or
at least declaring all the forward references near the top of the file.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:45:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0LF-00018M-0h; Wed, 25 Jan 2012 10:44:37 +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 1Rq0LD-00018H-Pc
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:44:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327488269!12497551!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29321 invoked from network); 25 Jan 2012 10:44:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 10:44:29 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75007578; Wed, 25 Jan 2012 11:44:28 +0100
Message-ID: <1327488245.2723.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 25 Jan 2012 11:44:05 +0100
In-Reply-To: <1327487306.24561.258.camel@zakaz.uk.xensource.com>
References: <1327342219.2476.9.camel@Abyss> <1327342932.2476.15.camel@Abyss>
	<1327487306.24561.258.camel@zakaz.uk.xensource.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>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 2 of 2] libxl: allow for specifying the
 CPU affinity in the config 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: multipart/mixed; boundary="===============0221436070339182707=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0221436070339182707==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-JPsWgTfV7tKIYcSrsq4B"


--=-JPsWgTfV7tKIYcSrsq4B
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-25 at 10:28 +0000, Ian Campbell wrote:=20
> > +int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> > +                               unsigned int max_vcpus, libxl_cpumap *c=
pumap)
> > +{
> > +    int i, rc =3D 0;
> > +
> > +    for (i =3D 0; i < max_vcpus; i++)=20
> > +        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
> > +            LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "no affinity for cpu %=
d", i);
>=20
> "failed to set affinity for ..." would better describe what had happened.
>=20
Ok.

> > +static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
> > +{
> [...]
>=20
> I assumed this was pure code motion so I didn't read it.
>=20
It is.

> > @@ -328,6 +384,9 @@ static void printf_info(int domid,
> > =20
> >      printf("\t(build_info)\n");
> >      printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
> > +    printf("\t(CPU affinity ");
> > +    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);
>=20
> If libxl_get_physinfo failed then nr_cpus would =3D=3D -1 here.
>=20
> However I don't think it is even necessary to extend this (legacy) sexp
> any further. I'm about to send a patch which will use the print the json
> representation (which is autogenerated).
>=20
Ok, then I'll drop this.

> > +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);
>=20
> There are no calls to vcpupin_parse added after this point by this patch
> so is this necessary? I'd prefer moving the function up in any case or
> at least declaring all the forward references near the top of the file.
>=20
Oops. I thought I removed all these fwd-decls. Sorry, seems this one
escaped... Will nuke it. :-)

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-JPsWgTfV7tKIYcSrsq4B
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)

iEYEABECAAYFAk8f3PUACgkQk4XaBE3IOsSrwgCfczXYRHhvJ7ScqImHnN337mht
zzsAoKGDwrpCxP2SdMa+AAfqXxqCHMVs
=MkLt
-----END PGP SIGNATURE-----

--=-JPsWgTfV7tKIYcSrsq4B--



--===============0221436070339182707==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0221436070339182707==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:45:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:45:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0LF-00018M-0h; Wed, 25 Jan 2012 10:44:37 +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 1Rq0LD-00018H-Pc
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:44:36 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327488269!12497551!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29321 invoked from network); 25 Jan 2012 10:44:29 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 10:44:29 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75007578; Wed, 25 Jan 2012 11:44:28 +0100
Message-ID: <1327488245.2723.1.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 25 Jan 2012 11:44:05 +0100
In-Reply-To: <1327487306.24561.258.camel@zakaz.uk.xensource.com>
References: <1327342219.2476.9.camel@Abyss> <1327342932.2476.15.camel@Abyss>
	<1327487306.24561.258.camel@zakaz.uk.xensource.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>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 2 of 2] libxl: allow for specifying the
 CPU affinity in the config 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: multipart/mixed; boundary="===============0221436070339182707=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0221436070339182707==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-JPsWgTfV7tKIYcSrsq4B"


--=-JPsWgTfV7tKIYcSrsq4B
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-25 at 10:28 +0000, Ian Campbell wrote:=20
> > +int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> > +                               unsigned int max_vcpus, libxl_cpumap *c=
pumap)
> > +{
> > +    int i, rc =3D 0;
> > +
> > +    for (i =3D 0; i < max_vcpus; i++)=20
> > +        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
> > +            LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "no affinity for cpu %=
d", i);
>=20
> "failed to set affinity for ..." would better describe what had happened.
>=20
Ok.

> > +static void print_bitmap(uint8_t *map, int maplen, FILE *stream)
> > +{
> [...]
>=20
> I assumed this was pure code motion so I didn't read it.
>=20
It is.

> > @@ -328,6 +384,9 @@ static void printf_info(int domid,
> > =20
> >      printf("\t(build_info)\n");
> >      printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
> > +    printf("\t(CPU affinity ");
> > +    print_bitmap(b_info->cpumap.map, nr_cpus, stdout);
>=20
> If libxl_get_physinfo failed then nr_cpus would =3D=3D -1 here.
>=20
> However I don't think it is even necessary to extend this (legacy) sexp
> any further. I'm about to send a patch which will use the print the json
> representation (which is autogenerated).
>=20
Ok, then I'll drop this.

> > +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap);
>=20
> There are no calls to vcpupin_parse added after this point by this patch
> so is this necessary? I'd prefer moving the function up in any case or
> at least declaring all the forward references near the top of the file.
>=20
Oops. I thought I removed all these fwd-decls. Sorry, seems this one
escaped... Will nuke it. :-)

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-JPsWgTfV7tKIYcSrsq4B
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)

iEYEABECAAYFAk8f3PUACgkQk4XaBE3IOsSrwgCfczXYRHhvJ7ScqImHnN337mht
zzsAoKGDwrpCxP2SdMa+AAfqXxqCHMVs
=MkLt
-----END PGP SIGNATURE-----

--=-JPsWgTfV7tKIYcSrsq4B--



--===============0221436070339182707==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0221436070339182707==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:47:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0Nm-0001Jp-Ny; Wed, 25 Jan 2012 10:47:14 +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 1Rq0Nl-0001IZ-9A
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:47:13 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327488426!9737662!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14815 invoked from network); 25 Jan 2012 10:47:06 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 10:47:06 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75007645; Wed, 25 Jan 2012 11:47:06 +0100
Message-ID: <1327488425.2723.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 25 Jan 2012 11:47:05 +0100
In-Reply-To: <1327486743.24561.250.camel@zakaz.uk.xensource.com>
References: <1327342219.2476.9.camel@Abyss> <1327342871.2476.14.camel@Abyss>
	<1327486743.24561.250.camel@zakaz.uk.xensource.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>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 1 of 2] libxl: extend pCPUs specification
	for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5999891186029513161=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5999891186029513161==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IRo24Dr50IXSNAI4YiVO"


--=-IRo24Dr50IXSNAI4YiVO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-25 at 10:19 +0000, Ian Campbell wrote:=20
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>=20
> Is 0-4,^2-3 (=3D=3D 0-1,4) a useful thing to want to write? I don't think=
 it
> should block this patch going in though.
>=20
As I have to respin, I don't think that wouldn't be so hard to add. I'll
give it a try and see if I cat put it there like super-quick and repost
both patches...

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-IRo24Dr50IXSNAI4YiVO
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)

iEYEABECAAYFAk8f3akACgkQk4XaBE3IOsTivACfatB4SIA/atV0j27GGjdTmbmS
ghkAnAlEtpB6XB/EIdOqNw54r4WelE5z
=d4Sa
-----END PGP SIGNATURE-----

--=-IRo24Dr50IXSNAI4YiVO--



--===============5999891186029513161==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5999891186029513161==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:47:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:47:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0Nm-0001Jp-Ny; Wed, 25 Jan 2012 10:47:14 +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 1Rq0Nl-0001IZ-9A
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:47:13 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327488426!9737662!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14815 invoked from network); 25 Jan 2012 10:47:06 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-12.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 10:47:06 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75007645; Wed, 25 Jan 2012 11:47:06 +0100
Message-ID: <1327488425.2723.4.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 25 Jan 2012 11:47:05 +0100
In-Reply-To: <1327486743.24561.250.camel@zakaz.uk.xensource.com>
References: <1327342219.2476.9.camel@Abyss> <1327342871.2476.14.camel@Abyss>
	<1327486743.24561.250.camel@zakaz.uk.xensource.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>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 1 of 2] libxl: extend pCPUs specification
	for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5999891186029513161=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============5999891186029513161==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IRo24Dr50IXSNAI4YiVO"


--=-IRo24Dr50IXSNAI4YiVO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-25 at 10:19 +0000, Ian Campbell wrote:=20
> > Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
>=20
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>=20
> Is 0-4,^2-3 (=3D=3D 0-1,4) a useful thing to want to write? I don't think=
 it
> should block this patch going in though.
>=20
As I have to respin, I don't think that wouldn't be so hard to add. I'll
give it a try and see if I cat put it there like super-quick and repost
both patches...

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-IRo24Dr50IXSNAI4YiVO
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)

iEYEABECAAYFAk8f3akACgkQk4XaBE3IOsTivACfatB4SIA/atV0j27GGjdTmbmS
ghkAnAlEtpB6XB/EIdOqNw54r4WelE5z
=d4Sa
-----END PGP SIGNATURE-----

--=-IRo24Dr50IXSNAI4YiVO--



--===============5999891186029513161==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5999891186029513161==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:49:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0PV-0001UU-8P; Wed, 25 Jan 2012 10:49: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 1Rq0PT-0001UD-GE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:48:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327488533!3928950!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1854 invoked from network); 25 Jan 2012 10:48:53 -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;
	25 Jan 2012 10:48:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10270484"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 10:48: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, 25 Jan 2012 10:48:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Jan 2012 10:48:52 +0000
In-Reply-To: <20254.59933.408785.834@mariner.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
	<1326969875.17599.50.camel@zakaz.uk.xensource.com>
	<20254.59933.408785.834@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327488533.24561.272.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 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 17:27 +0000, Ian Jackson wrote:
> Thanks for the thorough review.
> 
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> > You've done device removal, do you have a list of other things which
> > should use this? (perhaps with an associated list of people's names...)
> 
> No, I don't have such a list, but offhand:
>   domain creation (bootloader, etc.)
>   qmp
>   device attach
>   domain destruction
>   bootloader
>   vncviewer exec (or vncviewer parameter fetching - api should change)
> (these may overlap).

Thanks.

> > Is there a possibility that libxl might decide that the operation isn't
> > actually going to take all the long and do things synchronously,
> > returning normal success (e.g. 0)? Is that the reason for the separate
> > return code for this "I did what you asked me" case?
> 
> No, even if the operation completes quickly, the same exit path is
> taken.  So if you ask for a callback or an event, you get that even if
> the callback or event happened before your initiating function
> returns.  As I say:
> 
>  * Note that it is possible for an asynchronous operation which is to
>  * result in a callback to complete during its initiating function
>  * call.  In this case the initating function will return
>  * ERROR_ASYNC_INPROGRESS, even though by the time it returns the
>  * operation is complete and the callback has already happened.

Thanks, I think I simply hadn't got to that comment when I wrote the
question.

If this is a direct cut-n-paste then presumably there is a patch
somewhere where "initiating" is spelled "initating" as above. Hah, I've
just spotted where I pointed it out last time and you corrected it
below... At least I'm consistent.

> If ao_how is non-NULL then these functions cannot return 0.
> If it is NULL they cannot return ASYNC_INPROGRESS.
> 
> I chose to use a new exit status because it seemed safer but that's a
> matter of taste and if you prefer I could return 0 for that case.

I'm undecided (plus it seems a bit like bikeshedding). I certainly
prefer either 0 or {LIBXL_}ASYNC_IN_PROGRESS to ERROR_ASYNC_IN_PROGRESS
though.

> > Can we drop the ERROR_ prefix? I know that's inconsistent with the other
> > return codes but those actually are errors.
> 
> I guess we could but isn't this going to become a proper IDL enum at
> some point ?

At which point it would become LIBXL_ERROR_{FOOS} and
LIBXL_ASYNC_IN_PROGRESS?

[...]
> > > + * "disaster", except that libxl calls ao_how->callback instead of
> > > + * libxl_event_hooks.event_occurs.
> > > + *
> > > + * If ao_how->callback==NULL, a libxl_event will be generated which
> > > + * can be obtained from libxl_event_wait or libxl_event_check.
> > 
> > Or be delivered via event_occurs?
> 
> Yes, in principle, although that would be a silly thing to ask for.
> Why would you want your ao completions delivered via some central
> callback function just so that you could split them up again ?

True.

> > > + * call.  In this case the initating function will return
> > 
> >                               initiating
> 
> Fixed.
> 
> 
> > > +typedef struct {
> > > +    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
> > > +    union {
> > > +        libxl_ev_user for_event; /* used if callback==NULL */
> > > +        void *for_callback; /* passed to callback */
> > 
> > Why void * for one bit of "closure" but an explicit uint64_t for the
> > other. I nearly commented on the use of uint64_t previously -- void *,
> > or perhaps (u)intptr_t is more normal.
> 
> The context value in an event needs to be marshallable to a foreign
> language or a foreign process.  So it can't be a pointer.  Or at
> least, it has to be a type which can contain integers as well as
> pointers, and an integer type is better for that.

Fair enough.

> 
> The context value for a callback function can be a void* because you
> don't ever need to "marshal" the "callback", or if you do you can wrap
> up the context appropriately.
> 
> > > + * Completion after initiator return (asynch. only):
> ...
> > > + *   * initiator calls ao_complete:               |
> > > + *     - observes event not net done,             |
> > > + *     - returns to caller                        |
> > > + *                                                |
> > > + *                              - ao completes on some thread
> > > + *                              - generate the event or call the callback
> > > + *                              - destroy the ao
> > 
> > Where does ao_inprogress fit into these diagrams?
> 
> There's a mistake in the diagrams: where it says on the left
> "initiator calls ao_complete" it should read "... ao_inprogress", and
> likewise for "ao_complete takes the lock".  I will fix this.

Thanks. While rereading with that substitution (and finding that it made
sense) I noticed:
+ *   * initiator calls ao_complete:               |
+ *     - observes event not net done,             |

You want s/net/yet/.

> > > +void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
> > > +    assert(ao->magic == LIBXL__AO_MAGIC);
> > > +    assert(!ao->complete);
> > > +    ao->complete = 1;
> > > +    ao->rc = rc;
> > > +
> > > +    if (ao->poller) {
> > > +        assert(ao->in_initiator);
> > > +        libxl__poller_wakeup(egc, ao->poller);
> > > +    } else if (ao->how.callback) {
> > > +        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
> > > +    } else {
> > > +        libxl_event *ev;
> > > +        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
> > > +        if (ev) {
> > > +            ev->for_user = ao->how.u.for_event;
> > > +            ev->u.operation_complete.rc = ao->rc;
> > > +            libxl__event_occurred(egc, ev);
> > > +        }
> > > +        ao->notified = 1;
> > > +    }
> > > +    if (!ao->in_initiator && ao->notified)
> > > +        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
> > 
> > You added a helper for this libxl__gc_owner(&egc..) construct.
> 
> You mean EGC_GC and CTX.  I don't think that's a good idea here
> because it obscures exactly what's going on.  In particular, there are
> two gcs here - the ao's and the egc's - and one of them may be about
> to evaporate.

OK.

> > > +            rc = eventloop_iteration(&egc,ao->poller);
> > > +            if (rc) {
> > > +                /* Oh dear, this is quite unfortunate. */
> > > +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
> > > +                           " event during long-running operation (rc=%d)", rc);
> > > +                sleep(1);
> > > +                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
> > > +                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
> > > +                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
> > > +                 * cancellation ability. */
> > 
> > Does this constitute a "disaster" (in the special hook sense)?
> 
> No, disaster just lets us say that some events may be lost and an ao
> completion might not be an event.  disaster doesn't let us randomly
> store up ongoing activity and have it happen when not expected.
> For example, a caller asking a synchronous operation does not expect
> to get an error code and then have the operation continue in the
> background anyway.

OK.

> > > + *   Usually callback function should use GET_CONTAINING_STRUCT
> > 
> > Now called CONTAINER_OF
> 
> Fixed.  Sometimes I wish the compiler could look into comments and
> spot when I've done this kind of thing.

Or read the comments and DWIM so we just need to write the comments ;-)

> > > + *   to obtain its own structure, containing a pointer to the ao,
> > > + *   and then use the gc from that ao.
> > > + */
> > > +
> > > +#define AO_CREATE(ctx, domid, ao_how)                           \
> > > +    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
> > > +    if (!ao) return ERROR_NOMEM;                                \
> > > +    AO_GC;                                                      \
> > > +    CTX_LOCK;
> > 
> > Where does the unlock which balances this come from? The only unlock I
> > see in this patch is the temporary drop in libxl__ao_inprogress which is
> > matched by another lock.
> 
> The AO_INPROGRESS macro is supposed to unlock it, but locks it again
> by mistake.  Well spotted.
> 
> > > +#define AO_INPROGRESS do{                                       \
> > > +        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> > > +        int ao__rc = libxl__ao_inprogress(ao);                  \
> > > +        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
> > 
> > Is this supposed to be unlock answering my question above? Likewise in
> > ABORT?
> 
> Yes.  Indeed the comment above agrees:
> 
>  * - If initiation is successful, the initiating function needs
>  *   to run libxl__ao_inprogress right before unlocking and
>  *   returning, and return whatever it returns (AO_INPROGRESS macro).
>  *
>  * - If the initiation is unsuccessful, the initiating function must
>  *   call libxl__ao_abort before unlocking and returning whatever
>  *   error code is appropriate (AO_ABORT macro).

Right.

I think this highlights my concern about some code paths not being run
by the in-xl users...

>  > > +        return ao__rc;                                          \
> > > +   }while(0)
> > 
> > Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
> > would become
> >         return AO_INPROGRESS;
> 
> That would be possible.  I wasn't sure whether to do it like that.
> Note that AO_CREATE already might return; doing it the way I have it
> now seems more symmetrical.
> 
> But perhaps it would make things clearer to have the return outside
> the macro.

I thought there was a general preference for that sort of thing, but I
suppose it depends on the required macro contortions to make it happen.


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:49:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0PV-0001UU-8P; Wed, 25 Jan 2012 10:49: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 1Rq0PT-0001UD-GE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:48:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327488533!3928950!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1854 invoked from network); 25 Jan 2012 10:48:53 -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;
	25 Jan 2012 10:48:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10270484"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 10:48: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, 25 Jan 2012 10:48:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Jan 2012 10:48:52 +0000
In-Reply-To: <20254.59933.408785.834@mariner.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
	<1326969875.17599.50.camel@zakaz.uk.xensource.com>
	<20254.59933.408785.834@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327488533.24561.272.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 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 17:27 +0000, Ian Jackson wrote:
> Thanks for the thorough review.
> 
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> > You've done device removal, do you have a list of other things which
> > should use this? (perhaps with an associated list of people's names...)
> 
> No, I don't have such a list, but offhand:
>   domain creation (bootloader, etc.)
>   qmp
>   device attach
>   domain destruction
>   bootloader
>   vncviewer exec (or vncviewer parameter fetching - api should change)
> (these may overlap).

Thanks.

> > Is there a possibility that libxl might decide that the operation isn't
> > actually going to take all the long and do things synchronously,
> > returning normal success (e.g. 0)? Is that the reason for the separate
> > return code for this "I did what you asked me" case?
> 
> No, even if the operation completes quickly, the same exit path is
> taken.  So if you ask for a callback or an event, you get that even if
> the callback or event happened before your initiating function
> returns.  As I say:
> 
>  * Note that it is possible for an asynchronous operation which is to
>  * result in a callback to complete during its initiating function
>  * call.  In this case the initating function will return
>  * ERROR_ASYNC_INPROGRESS, even though by the time it returns the
>  * operation is complete and the callback has already happened.

Thanks, I think I simply hadn't got to that comment when I wrote the
question.

If this is a direct cut-n-paste then presumably there is a patch
somewhere where "initiating" is spelled "initating" as above. Hah, I've
just spotted where I pointed it out last time and you corrected it
below... At least I'm consistent.

> If ao_how is non-NULL then these functions cannot return 0.
> If it is NULL they cannot return ASYNC_INPROGRESS.
> 
> I chose to use a new exit status because it seemed safer but that's a
> matter of taste and if you prefer I could return 0 for that case.

I'm undecided (plus it seems a bit like bikeshedding). I certainly
prefer either 0 or {LIBXL_}ASYNC_IN_PROGRESS to ERROR_ASYNC_IN_PROGRESS
though.

> > Can we drop the ERROR_ prefix? I know that's inconsistent with the other
> > return codes but those actually are errors.
> 
> I guess we could but isn't this going to become a proper IDL enum at
> some point ?

At which point it would become LIBXL_ERROR_{FOOS} and
LIBXL_ASYNC_IN_PROGRESS?

[...]
> > > + * "disaster", except that libxl calls ao_how->callback instead of
> > > + * libxl_event_hooks.event_occurs.
> > > + *
> > > + * If ao_how->callback==NULL, a libxl_event will be generated which
> > > + * can be obtained from libxl_event_wait or libxl_event_check.
> > 
> > Or be delivered via event_occurs?
> 
> Yes, in principle, although that would be a silly thing to ask for.
> Why would you want your ao completions delivered via some central
> callback function just so that you could split them up again ?

True.

> > > + * call.  In this case the initating function will return
> > 
> >                               initiating
> 
> Fixed.
> 
> 
> > > +typedef struct {
> > > +    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
> > > +    union {
> > > +        libxl_ev_user for_event; /* used if callback==NULL */
> > > +        void *for_callback; /* passed to callback */
> > 
> > Why void * for one bit of "closure" but an explicit uint64_t for the
> > other. I nearly commented on the use of uint64_t previously -- void *,
> > or perhaps (u)intptr_t is more normal.
> 
> The context value in an event needs to be marshallable to a foreign
> language or a foreign process.  So it can't be a pointer.  Or at
> least, it has to be a type which can contain integers as well as
> pointers, and an integer type is better for that.

Fair enough.

> 
> The context value for a callback function can be a void* because you
> don't ever need to "marshal" the "callback", or if you do you can wrap
> up the context appropriately.
> 
> > > + * Completion after initiator return (asynch. only):
> ...
> > > + *   * initiator calls ao_complete:               |
> > > + *     - observes event not net done,             |
> > > + *     - returns to caller                        |
> > > + *                                                |
> > > + *                              - ao completes on some thread
> > > + *                              - generate the event or call the callback
> > > + *                              - destroy the ao
> > 
> > Where does ao_inprogress fit into these diagrams?
> 
> There's a mistake in the diagrams: where it says on the left
> "initiator calls ao_complete" it should read "... ao_inprogress", and
> likewise for "ao_complete takes the lock".  I will fix this.

Thanks. While rereading with that substitution (and finding that it made
sense) I noticed:
+ *   * initiator calls ao_complete:               |
+ *     - observes event not net done,             |

You want s/net/yet/.

> > > +void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc) {
> > > +    assert(ao->magic == LIBXL__AO_MAGIC);
> > > +    assert(!ao->complete);
> > > +    ao->complete = 1;
> > > +    ao->rc = rc;
> > > +
> > > +    if (ao->poller) {
> > > +        assert(ao->in_initiator);
> > > +        libxl__poller_wakeup(egc, ao->poller);
> > > +    } else if (ao->how.callback) {
> > > +        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
> > > +    } else {
> > > +        libxl_event *ev;
> > > +        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
> > > +        if (ev) {
> > > +            ev->for_user = ao->how.u.for_event;
> > > +            ev->u.operation_complete.rc = ao->rc;
> > > +            libxl__event_occurred(egc, ev);
> > > +        }
> > > +        ao->notified = 1;
> > > +    }
> > > +    if (!ao->in_initiator && ao->notified)
> > > +        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
> > 
> > You added a helper for this libxl__gc_owner(&egc..) construct.
> 
> You mean EGC_GC and CTX.  I don't think that's a good idea here
> because it obscures exactly what's going on.  In particular, there are
> two gcs here - the ao's and the egc's - and one of them may be about
> to evaporate.

OK.

> > > +            rc = eventloop_iteration(&egc,ao->poller);
> > > +            if (rc) {
> > > +                /* Oh dear, this is quite unfortunate. */
> > > +                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
> > > +                           " event during long-running operation (rc=%d)", rc);
> > > +                sleep(1);
> > > +                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
> > > +                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
> > > +                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
> > > +                 * cancellation ability. */
> > 
> > Does this constitute a "disaster" (in the special hook sense)?
> 
> No, disaster just lets us say that some events may be lost and an ao
> completion might not be an event.  disaster doesn't let us randomly
> store up ongoing activity and have it happen when not expected.
> For example, a caller asking a synchronous operation does not expect
> to get an error code and then have the operation continue in the
> background anyway.

OK.

> > > + *   Usually callback function should use GET_CONTAINING_STRUCT
> > 
> > Now called CONTAINER_OF
> 
> Fixed.  Sometimes I wish the compiler could look into comments and
> spot when I've done this kind of thing.

Or read the comments and DWIM so we just need to write the comments ;-)

> > > + *   to obtain its own structure, containing a pointer to the ao,
> > > + *   and then use the gc from that ao.
> > > + */
> > > +
> > > +#define AO_CREATE(ctx, domid, ao_how)                           \
> > > +    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
> > > +    if (!ao) return ERROR_NOMEM;                                \
> > > +    AO_GC;                                                      \
> > > +    CTX_LOCK;
> > 
> > Where does the unlock which balances this come from? The only unlock I
> > see in this patch is the temporary drop in libxl__ao_inprogress which is
> > matched by another lock.
> 
> The AO_INPROGRESS macro is supposed to unlock it, but locks it again
> by mistake.  Well spotted.
> 
> > > +#define AO_INPROGRESS do{                                       \
> > > +        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
> > > +        int ao__rc = libxl__ao_inprogress(ao);                  \
> > > +        libxl__ctx_lock(ao__ctx); /* gc is now invalid */       \
> > 
> > Is this supposed to be unlock answering my question above? Likewise in
> > ABORT?
> 
> Yes.  Indeed the comment above agrees:
> 
>  * - If initiation is successful, the initiating function needs
>  *   to run libxl__ao_inprogress right before unlocking and
>  *   returning, and return whatever it returns (AO_INPROGRESS macro).
>  *
>  * - If the initiation is unsuccessful, the initiating function must
>  *   call libxl__ao_abort before unlocking and returning whatever
>  *   error code is appropriate (AO_ABORT macro).

Right.

I think this highlights my concern about some code paths not being run
by the in-xl users...

>  > > +        return ao__rc;                                          \
> > > +   }while(0)
> > 
> > Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
> > would become
> >         return AO_INPROGRESS;
> 
> That would be possible.  I wasn't sure whether to do it like that.
> Note that AO_CREATE already might return; doing it the way I have it
> now seems more symmetrical.
> 
> But perhaps it would make things clearer to have the return outside
> the macro.

I thought there was a general preference for that sort of thing, but I
suppose it depends on the required macro contortions to make it happen.


Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:58:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0YO-0001vz-A4; Wed, 25 Jan 2012 10:58:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq0YM-0001vu-UJ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:58:11 +0000
Received: from [85.158.138.51:28158] by server-12.bemta-3.messagelabs.com id
	50/B0-24557-240EF1F4; Wed, 25 Jan 2012 10:58:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327489088!10568277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1474 invoked from network); 25 Jan 2012 10:58:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:58:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10271048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 10:57:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 10:57:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Jan 2012 10:57:50 +0000
In-Reply-To: <20254.60260.642300.195152@mariner.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
	<1326970442.17599.53.camel@zakaz.uk.xensource.com>
	<20254.60260.642300.195152@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327489070.24561.276.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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 17:33 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 8/9] libxl: Introduce libxl__ev_devstate"):
> > On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > > Provide a new-style asynchronous facility for waiting for device
> > > states on xenbus.  This will replace libxl__wait_for_device_state,
> > > after the callers have been updated in later patches.
> > 
> > Is event-with-timeout likely to be a useful/common enough pattern to be
> > worth baking into the infrastructure/helpers rather than implementing
> > just for this one event type? (if yes then, "I will refactor for the
> > second user is a valid response").
> 
> I'm not convinced.  I thought of this but I think it would result in
> flabby code - all the libxl__ev_register functions would gain a new
> timeout parameter (and note that the timeout machinery has both
> absolute and relative timeouts...)
> 
> I think when we have a second user it might be worth seeing if some
> commonality could be extracted but TBH I doubt it would make the code
> smaller or simpler.

Right, lets leave it then.

> > > +static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
> > > +                             const struct timeval *requested_abs)
> > > +{
> > > +    EGC_GC;
> > > +    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
> > > +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
> > > +               " timed out", ds->watch.path, ds->wanted);
> > > +    libxl__ev_devstate_cancel(gc, ds);
> > 
> > What prevents racing here with the watch happening? Might the caller see
> > two callbacks?
> 
>   static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
>                                                libxl__ev_devstate *ds)
>   {
>       libxl__ev_time_deregister(gc,&ds->timeout);
>       libxl__ev_xswatch_deregister(gc,&ds->watch);
>   }
> 
> So, no.  When the timeout happens, the ev xswatch is deregistered and
> can thereafter no longer generate callbacks.  If there are any
> xenstore watch events in the pipeline for deregistered ev_xswatch's,
> they're discarded by watchfd_callback.

What happens if the watch occurs and is delivered (in a different
thread) e.g. just before devstate_timeout calls
libxl__ev_devstate_cancel? The watch callback will be delivered but we
will unconditionally go on to deliver the cancel callback as well.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 10:58:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 10:58:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0YO-0001vz-A4; Wed, 25 Jan 2012 10:58:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq0YM-0001vu-UJ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 10:58:11 +0000
Received: from [85.158.138.51:28158] by server-12.bemta-3.messagelabs.com id
	50/B0-24557-240EF1F4; Wed, 25 Jan 2012 10:58:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327489088!10568277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1474 invoked from network); 25 Jan 2012 10:58:09 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 10:58:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10271048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 10:57:51 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 10:57:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Wed, 25 Jan 2012 10:57:50 +0000
In-Reply-To: <20254.60260.642300.195152@mariner.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
	<1326970442.17599.53.camel@zakaz.uk.xensource.com>
	<20254.60260.642300.195152@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327489070.24561.276.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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 17:33 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 8/9] libxl: Introduce libxl__ev_devstate"):
> > On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > > Provide a new-style asynchronous facility for waiting for device
> > > states on xenbus.  This will replace libxl__wait_for_device_state,
> > > after the callers have been updated in later patches.
> > 
> > Is event-with-timeout likely to be a useful/common enough pattern to be
> > worth baking into the infrastructure/helpers rather than implementing
> > just for this one event type? (if yes then, "I will refactor for the
> > second user is a valid response").
> 
> I'm not convinced.  I thought of this but I think it would result in
> flabby code - all the libxl__ev_register functions would gain a new
> timeout parameter (and note that the timeout machinery has both
> absolute and relative timeouts...)
> 
> I think when we have a second user it might be worth seeing if some
> commonality could be extracted but TBH I doubt it would make the code
> smaller or simpler.

Right, lets leave it then.

> > > +static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
> > > +                             const struct timeval *requested_abs)
> > > +{
> > > +    EGC_GC;
> > > +    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
> > > +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
> > > +               " timed out", ds->watch.path, ds->wanted);
> > > +    libxl__ev_devstate_cancel(gc, ds);
> > 
> > What prevents racing here with the watch happening? Might the caller see
> > two callbacks?
> 
>   static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
>                                                libxl__ev_devstate *ds)
>   {
>       libxl__ev_time_deregister(gc,&ds->timeout);
>       libxl__ev_xswatch_deregister(gc,&ds->watch);
>   }
> 
> So, no.  When the timeout happens, the ev xswatch is deregistered and
> can thereafter no longer generate callbacks.  If there are any
> xenstore watch events in the pipeline for deregistered ev_xswatch's,
> they're discarded by watchfd_callback.

What happens if the watch occurs and is delivered (in a different
thread) e.g. just before devstate_timeout calls
libxl__ev_devstate_cancel? The watch callback will be delivered but we
will unconditionally go on to deliver the cancel callback as well.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:07:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0h1-000280-AH; Wed, 25 Jan 2012 11:07:07 +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 1Rq0gz-00027v-Lk
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:07:05 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327489619!12239960!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7234 invoked from network); 25 Jan 2012 11:06:59 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 11:06:59 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75008414; Wed, 25 Jan 2012 12:06:57 +0100
Message-ID: <1327489616.2723.6.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 25 Jan 2012 12:06:56 +0100
In-Reply-To: <1327488425.2723.4.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss> <1327342871.2476.14.camel@Abyss>
	<1327486743.24561.250.camel@zakaz.uk.xensource.com>
	<1327488425.2723.4.camel@Abyss>
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>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 1 of 2] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7738376701774521259=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7738376701774521259==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-bSMBzIAfUsB8RI4TST9q"


--=-bSMBzIAfUsB8RI4TST9q
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-25 at 11:47 +0100, Dario Faggioli wrote:=20
> As I have to respin, I don't think that wouldn't be so hard to add.=20
                      ^I don't think that _would_ be so hard to add.

:-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-bSMBzIAfUsB8RI4TST9q
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)

iEYEABECAAYFAk8f4lAACgkQk4XaBE3IOsSyLQCfZQUvINZlxU1jsPLkEoESnpXT
l/YAn3cjvDdlbmMT/MiXRJepnzWU+tgr
=NlpP
-----END PGP SIGNATURE-----

--=-bSMBzIAfUsB8RI4TST9q--



--===============7738376701774521259==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7738376701774521259==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:07:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0h1-000280-AH; Wed, 25 Jan 2012 11:07:07 +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 1Rq0gz-00027v-Lk
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:07:05 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327489619!12239960!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7234 invoked from network); 25 Jan 2012 11:06:59 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-7.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 11:06:59 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75008414; Wed, 25 Jan 2012 12:06:57 +0100
Message-ID: <1327489616.2723.6.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Date: Wed, 25 Jan 2012 12:06:56 +0100
In-Reply-To: <1327488425.2723.4.camel@Abyss>
References: <1327342219.2476.9.camel@Abyss> <1327342871.2476.14.camel@Abyss>
	<1327486743.24561.250.camel@zakaz.uk.xensource.com>
	<1327488425.2723.4.camel@Abyss>
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>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv2 1 of 2] libxl: extend pCPUs specification
 for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7738376701774521259=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============7738376701774521259==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-bSMBzIAfUsB8RI4TST9q"


--=-bSMBzIAfUsB8RI4TST9q
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-01-25 at 11:47 +0100, Dario Faggioli wrote:=20
> As I have to respin, I don't think that wouldn't be so hard to add.=20
                      ^I don't think that _would_ be so hard to add.

:-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-bSMBzIAfUsB8RI4TST9q
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)

iEYEABECAAYFAk8f4lAACgkQk4XaBE3IOsSyLQCfZQUvINZlxU1jsPLkEoESnpXT
l/YAn3cjvDdlbmMT/MiXRJepnzWU+tgr
=NlpP
-----END PGP SIGNATURE-----

--=-bSMBzIAfUsB8RI4TST9q--



--===============7738376701774521259==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7738376701774521259==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:09:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11: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 1Rq0ij-0002EQ-Vm; Wed, 25 Jan 2012 11:08: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 1Rq0ii-0002EA-DE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:08:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327489673!53973505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13646 invoked from network); 25 Jan 2012 11:07:53 -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;
	25 Jan 2012 11:07:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10271541"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:08:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 11:08:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 11:08:45 +0000
In-Reply-To: <11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327489725.24561.284.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model
 suspend/resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327358638 28800
> # Node ID 11fb1dfda7de4d6759dec87d80cd16cf137f7369
> # Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
> tools/libxl: QEMU device model suspend/resume
> 
>  * Refactor the libxl__domain_save_device_model.
>  * Add support for suspend/resume QEMU device model
>    (both traditional xen and QMP).
> 
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Sat Jan 21 17:15:40 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 23 14:43:58 2012 -0800
> @@ -477,7 +477,7 @@
>  
>      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);
> +        rc = libxl__domain_save_device_model(gc, domid, fd, /* No Remus */ 0);
>      GC_FREE;
>      return rc;
>  }
> diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Sat Jan 21 17:15:40 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Mon Jan 23 14:43:58 2012 -0800
> @@ -534,6 +534,53 @@
>      return 0;
>  }
>  
> +static int libxl__remus_domain_suspend_qemu(libxl__gc *gc, uint32_t domid)
> +{
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        char *path = NULL;
> +        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> +                              domid);
> +        libxl__xs_write(gc, XBT_NULL, path, "save");
> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);

This and libxl__remus_domain_resume_qemu, qemu_pci_add_xenstore,
qemu_pci_remove_xenstore, libxl__domain_save_device_model and
libxl_domain_unpause would probably benefit from a helper function to
send a command to a traditional qemu.

> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        /* Stop QEMU */
> +        if (libxl__qmp_stop(gc, domid))
> +            return ERROR_FAIL;
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return 0;
> +}
> +
> +static int libxl__remus_domain_resume_qemu(libxl__gc *gc, uint32_t domid)
> +{
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        char *path = NULL;
> +        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> +                              domid);
> +        libxl__xs_write(gc, XBT_NULL, path, "continue");
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        /* Stop QEMU */
> +        if (libxl__qmp_resume(gc, domid))
> +            return ERROR_FAIL;
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return 0;
> +}
> +
>  int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                   libxl_domain_type type,
>                                   int live, int debug)
> @@ -620,7 +667,7 @@
>      return rc;
>  }
>  
> -int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
> +int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd, int remus)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int ret, fd2 = -1, c;
> @@ -631,13 +678,12 @@
>  
>      switch (libxl__device_model_version_running(gc, domid)) {
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> -        char *path = NULL;
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> -                   "Saving device model state to %s", filename);
> -        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> -                              domid);
> -        libxl__xs_write(gc, XBT_NULL, path, "save");
> -        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> +        /* For Remus,we issue suspend_qemu call separately */

Why?

How does this interact with Stefano's XC_SAVEID_TOOLSTACK patches?

I think some sort of high level description of the control flow used by
Remus and how/why it differs from normal save/restore would be useful
for review.

> +        if (!remus) {
> +            c = libxl__remus_domain_suspend_qemu(gc, domid);

It seems odd to call this function libxl__remus_FOO and the use it
when !remus. The function doesn't look to be inherently specific to
either remus or !remus anyhow.

> +            if (c)
> +                return c;
> +        }
>          break;
>      }
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> @@ -668,8 +714,9 @@
>      qemu_state_len = st.st_size;
>      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
>  
> -    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
> -                              "saved-state file", "qemu signature");
> +    ret = libxl_write_exactly(ctx, fd, remus ? REMUS_QEMU_SIGNATURE : QEMU_SIGNATURE,
> +                            remus ? strlen(REMUS_QEMU_SIGNATURE): strlen(QEMU_SIGNATURE),
> +                            "saved-state file", "qemu signature");

QEMU_SIGNATURE is "DeviceModelRecord0002" which I believe libxc treats
identically to the Remus signature?

Again consideration of how this interacts with Stefano's patch would be
useful. If possible we'd quite like to pull the qemu-restore our of
xc_domain_restore for consistency with how xc_domain_save saves it, the
current layering is quite mad.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:09:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11: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 1Rq0ij-0002EQ-Vm; Wed, 25 Jan 2012 11:08: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 1Rq0ii-0002EA-DE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:08:52 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327489673!53973505!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13646 invoked from network); 25 Jan 2012 11:07:53 -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;
	25 Jan 2012 11:07:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10271541"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:08:46 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 11:08:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 11:08:45 +0000
In-Reply-To: <11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327489725.24561.284.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model
 suspend/resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327358638 28800
> # Node ID 11fb1dfda7de4d6759dec87d80cd16cf137f7369
> # Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
> tools/libxl: QEMU device model suspend/resume
> 
>  * Refactor the libxl__domain_save_device_model.
>  * Add support for suspend/resume QEMU device model
>    (both traditional xen and QMP).
> 
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Sat Jan 21 17:15:40 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 23 14:43:58 2012 -0800
> @@ -477,7 +477,7 @@
>  
>      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);
> +        rc = libxl__domain_save_device_model(gc, domid, fd, /* No Remus */ 0);
>      GC_FREE;
>      return rc;
>  }
> diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Sat Jan 21 17:15:40 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Mon Jan 23 14:43:58 2012 -0800
> @@ -534,6 +534,53 @@
>      return 0;
>  }
>  
> +static int libxl__remus_domain_suspend_qemu(libxl__gc *gc, uint32_t domid)
> +{
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        char *path = NULL;
> +        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> +                              domid);
> +        libxl__xs_write(gc, XBT_NULL, path, "save");
> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);

This and libxl__remus_domain_resume_qemu, qemu_pci_add_xenstore,
qemu_pci_remove_xenstore, libxl__domain_save_device_model and
libxl_domain_unpause would probably benefit from a helper function to
send a command to a traditional qemu.

> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        /* Stop QEMU */
> +        if (libxl__qmp_stop(gc, domid))
> +            return ERROR_FAIL;
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return 0;
> +}
> +
> +static int libxl__remus_domain_resume_qemu(libxl__gc *gc, uint32_t domid)
> +{
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        char *path = NULL;
> +        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> +                              domid);
> +        libxl__xs_write(gc, XBT_NULL, path, "continue");
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        /* Stop QEMU */
> +        if (libxl__qmp_resume(gc, domid))
> +            return ERROR_FAIL;
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return 0;
> +}
> +
>  int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                   libxl_domain_type type,
>                                   int live, int debug)
> @@ -620,7 +667,7 @@
>      return rc;
>  }
>  
> -int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd)
> +int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd, int remus)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int ret, fd2 = -1, c;
> @@ -631,13 +678,12 @@
>  
>      switch (libxl__device_model_version_running(gc, domid)) {
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> -        char *path = NULL;
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> -                   "Saving device model state to %s", filename);
> -        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> -                              domid);
> -        libxl__xs_write(gc, XBT_NULL, path, "save");
> -        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> +        /* For Remus,we issue suspend_qemu call separately */

Why?

How does this interact with Stefano's XC_SAVEID_TOOLSTACK patches?

I think some sort of high level description of the control flow used by
Remus and how/why it differs from normal save/restore would be useful
for review.

> +        if (!remus) {
> +            c = libxl__remus_domain_suspend_qemu(gc, domid);

It seems odd to call this function libxl__remus_FOO and the use it
when !remus. The function doesn't look to be inherently specific to
either remus or !remus anyhow.

> +            if (c)
> +                return c;
> +        }
>          break;
>      }
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> @@ -668,8 +714,9 @@
>      qemu_state_len = st.st_size;
>      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n", qemu_state_len);
>  
> -    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(QEMU_SIGNATURE),
> -                              "saved-state file", "qemu signature");
> +    ret = libxl_write_exactly(ctx, fd, remus ? REMUS_QEMU_SIGNATURE : QEMU_SIGNATURE,
> +                            remus ? strlen(REMUS_QEMU_SIGNATURE): strlen(QEMU_SIGNATURE),
> +                            "saved-state file", "qemu signature");

QEMU_SIGNATURE is "DeviceModelRecord0002" which I believe libxc treats
identically to the Remus signature?

Again consideration of how this interacts with Stefano's patch would be
useful. If possible we'd quite like to pull the qemu-restore our of
xc_domain_restore for consistency with how xc_domain_save saves it, the
current layering is quite mad.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:23:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0wg-0002lW-Hn; Wed, 25 Jan 2012 11:23: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 1Rq0we-0002lO-Th
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:23:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327490590!9745107!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22412 invoked from network); 25 Jan 2012 11:23:11 -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;
	25 Jan 2012 11:23:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10272450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:22: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;
	Wed, 25 Jan 2012 11:22:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 11:22:38 +0000
In-Reply-To: <0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327490558.24561.294.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] tools/libxl:
 suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327358640 28800
> # Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef
> # Parent  11fb1dfda7de4d6759dec87d80cd16cf137f7369
> tools/libxl: suspend/postflush/commit callbacks
> 
>  * Add libxl callbacks for Remus checkpoint suspend, postflush (aka resume)
>    and checkpoint commit callbacks.
>  * suspend callback just bounces off libxl__domain_suspend_common_callback
>  * resume callback directly calls xc_domain_resume instead of re-using
>    libxl_domain_resume (as the latter does not set the fast suspend argument
>    to xc_domain_resume - aka suspend_cancel support).
>  * commit callback just sleeps for the checkpoint interval (for the moment).
> 
>  * Future patches will augument these callbacks with more functionalities like
>    issuing network buffer plug/unplug commands, disk checkpoint commands, etc.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 

> diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Mon Jan 23 14:43:58 2012 -0800
> +++ b/tools/libxl/libxl.h	Mon Jan 23 14:44:00 2012 -0800
> @@ -212,6 +212,12 @@
>      int (*suspend_callback)(void *, int);
>  } libxl_domain_suspend_info;
>  
> +typedef struct {
> +    int interval;
> +    int blackhole;
> +    int compression;
> +} libxl_domain_remus_info;

This should be defined via the libxl IDL (see libxl_types.idl and
idl.txt)

> +
>  enum {
>      ERROR_NONSPECIFIC = -1,
>      ERROR_VERSION = -2,
> diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Mon Jan 23 14:43:58 2012 -0800
> +++ b/tools/libxl/libxl_dom.c	Mon Jan 23 14:44:00 2012 -0800
> @@ -395,6 +395,8 @@
>      int hvm;
>      unsigned int flags;
>      int guest_responded;
> +    int save_fd; /* Migration stream fd (for Remus) */
> +    int interval; /* remus checkpoint interval */
>  };
>  
>  static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
> @@ -581,9 +583,69 @@
>      return 0;
>  }
>  
> +static int libxl__remus_domain_suspend_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +
> +    if (libxl__domain_suspend_common_callback(data)) {

if (!libxl_domain_suspend_common_callback)
        return 1;
if (si->hvm && !libxl__remus_domain_suspend(...)
        return 1;
return 0;

Is would be clearer than the multiple nested if/elses and returns.

> +        if (si->hvm) {
> +            if (!libxl__remus_domain_suspend_qemu(si->gc, si->domid))

Perhaps libxl__domain_suspend_common_callback should do this in both the
Remus and non-Remus cases?

Likewise perhaps normal save should use the checkpoint hook to call
libxl__domain_save_device_model() as well.

I'm in favour of tweaking the normal suspend/resume case as necessary to
reduce the amount of Remus special casing that is required. IMHO a
normal suspend should look a lot like a Remus suspend which happened to
only do a single iteration.

> +                return 1;
> +            else
> +                return 0;
> +        }
> +        return 1;
> +    }
> +    return 0;
> +}
> +
> +static int libxl__remus_domain_resume_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +    libxl_ctx *ctx = libxl__gc_owner(si->gc);
> +
> +    /* Assumes that SUSPEND_CANCEL is available - just like
> +     * xm version of Remus. Without that, remus wont work.
> +     * Since libxl_domain_resume calls xc_domain_resume with
> +     * fast_suspend = 0, we cant re-use that api.

You could modify that API which would be better than duplicating its
content. I think the "fast" flag is useful to expose to users of libxl
but if not then you could refactor into an internal function which takes
the flag and call it from both here and libxl_domain_resume.

> +     */
> +    if (xc_domain_resume(ctx->xch, si->domid, 1)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "xc_domain_resume failed for domain %u",
> +                   si->domid);
> +        return 0;
> +    }
> +    if (!xs_resume_domain(ctx->xsh, si->domid)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "xs_resume_domain failed for domain %u",
> +                   si->domid);
> +        return 0;
> +    }
> +
> +    if (si->hvm) {
> +        if (libxl__remus_domain_resume_qemu(si->gc, si->domid))
> +            return 0;
> +    }
> +    return 1;
> +}
> +
> +/* For now, just sleep. Later, we need to release disk/netbuf */
> +static int libxl__remus_domain_checkpoint_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +
> +    if (si->hvm && libxl__domain_save_device_model(si->gc, si->domid,
> +                                                   si->save_fd, 1))
> +            return 0;
> +
> +    usleep(si->interval * 1000);
> +    return 1;
> +}
> +
>  int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                   libxl_domain_type type,
> -                                 int live, int debug)
> +                                 int live, int debug,
> +                                 const libxl_domain_remus_info *r_info)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int flags;
> @@ -614,10 +676,20 @@

Please can you add :
        [diff]
        showfunc = True

to your ~/.hgrc.

>          return ERROR_INVAL;
>      }
>  
> +    memset(&si, 0, sizeof(si));
>      flags = (live) ? XCFLAGS_LIVE : 0
>            | (debug) ? XCFLAGS_DEBUG : 0
>            | (hvm) ? XCFLAGS_HVM : 0;
>  
> +    if (r_info != NULL) {
> +        si.interval = r_info->interval;
> +        if (r_info->compression)
> +            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
> +        si.save_fd = fd;
> +    }
> +    else
> +        si.save_fd = -1;
> +
>      si.domid = domid;
>      si.flags = flags;
>      si.hvm = hvm;
> @@ -641,7 +713,13 @@
>      }
>  
>      memset(&callbacks, 0, sizeof(callbacks));
> -    callbacks.suspend = libxl__domain_suspend_common_callback;
> +    if (r_info != NULL) {
> +        callbacks.suspend = libxl__remus_domain_suspend_callback;
> +        callbacks.postcopy = libxl__remus_domain_resume_callback;
> +        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
> +    } else
> +        callbacks.suspend = libxl__domain_suspend_common_callback;
> +
>      callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
>      callbacks.data = &si;
>  
> diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Mon Jan 23 14:43:58 2012 -0800
> +++ b/tools/libxl/libxl_internal.h	Mon Jan 23 14:44:00 2012 -0800
> @@ -272,7 +272,8 @@
>                                           int fd);
>  _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                           libxl_domain_type type,
> -                                         int live, int debug);
> +                                         int live, int debug,
> +                                         const libxl_domain_remus_info *r_info);
>  _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd,
>                                              int remus);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 25 11:23:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq0wg-0002lW-Hn; Wed, 25 Jan 2012 11:23: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 1Rq0we-0002lO-Th
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:23:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327490590!9745107!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22412 invoked from network); 25 Jan 2012 11:23:11 -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;
	25 Jan 2012 11:23:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10272450"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:22: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;
	Wed, 25 Jan 2012 11:22:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 11:22:38 +0000
In-Reply-To: <0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327490558.24561.294.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] tools/libxl:
 suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327358640 28800
> # Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef
> # Parent  11fb1dfda7de4d6759dec87d80cd16cf137f7369
> tools/libxl: suspend/postflush/commit callbacks
> 
>  * Add libxl callbacks for Remus checkpoint suspend, postflush (aka resume)
>    and checkpoint commit callbacks.
>  * suspend callback just bounces off libxl__domain_suspend_common_callback
>  * resume callback directly calls xc_domain_resume instead of re-using
>    libxl_domain_resume (as the latter does not set the fast suspend argument
>    to xc_domain_resume - aka suspend_cancel support).
>  * commit callback just sleeps for the checkpoint interval (for the moment).
> 
>  * Future patches will augument these callbacks with more functionalities like
>    issuing network buffer plug/unplug commands, disk checkpoint commands, etc.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 

> diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Mon Jan 23 14:43:58 2012 -0800
> +++ b/tools/libxl/libxl.h	Mon Jan 23 14:44:00 2012 -0800
> @@ -212,6 +212,12 @@
>      int (*suspend_callback)(void *, int);
>  } libxl_domain_suspend_info;
>  
> +typedef struct {
> +    int interval;
> +    int blackhole;
> +    int compression;
> +} libxl_domain_remus_info;

This should be defined via the libxl IDL (see libxl_types.idl and
idl.txt)

> +
>  enum {
>      ERROR_NONSPECIFIC = -1,
>      ERROR_VERSION = -2,
> diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Mon Jan 23 14:43:58 2012 -0800
> +++ b/tools/libxl/libxl_dom.c	Mon Jan 23 14:44:00 2012 -0800
> @@ -395,6 +395,8 @@
>      int hvm;
>      unsigned int flags;
>      int guest_responded;
> +    int save_fd; /* Migration stream fd (for Remus) */
> +    int interval; /* remus checkpoint interval */
>  };
>  
>  static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
> @@ -581,9 +583,69 @@
>      return 0;
>  }
>  
> +static int libxl__remus_domain_suspend_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +
> +    if (libxl__domain_suspend_common_callback(data)) {

if (!libxl_domain_suspend_common_callback)
        return 1;
if (si->hvm && !libxl__remus_domain_suspend(...)
        return 1;
return 0;

Is would be clearer than the multiple nested if/elses and returns.

> +        if (si->hvm) {
> +            if (!libxl__remus_domain_suspend_qemu(si->gc, si->domid))

Perhaps libxl__domain_suspend_common_callback should do this in both the
Remus and non-Remus cases?

Likewise perhaps normal save should use the checkpoint hook to call
libxl__domain_save_device_model() as well.

I'm in favour of tweaking the normal suspend/resume case as necessary to
reduce the amount of Remus special casing that is required. IMHO a
normal suspend should look a lot like a Remus suspend which happened to
only do a single iteration.

> +                return 1;
> +            else
> +                return 0;
> +        }
> +        return 1;
> +    }
> +    return 0;
> +}
> +
> +static int libxl__remus_domain_resume_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +    libxl_ctx *ctx = libxl__gc_owner(si->gc);
> +
> +    /* Assumes that SUSPEND_CANCEL is available - just like
> +     * xm version of Remus. Without that, remus wont work.
> +     * Since libxl_domain_resume calls xc_domain_resume with
> +     * fast_suspend = 0, we cant re-use that api.

You could modify that API which would be better than duplicating its
content. I think the "fast" flag is useful to expose to users of libxl
but if not then you could refactor into an internal function which takes
the flag and call it from both here and libxl_domain_resume.

> +     */
> +    if (xc_domain_resume(ctx->xch, si->domid, 1)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "xc_domain_resume failed for domain %u",
> +                   si->domid);
> +        return 0;
> +    }
> +    if (!xs_resume_domain(ctx->xsh, si->domid)) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "xs_resume_domain failed for domain %u",
> +                   si->domid);
> +        return 0;
> +    }
> +
> +    if (si->hvm) {
> +        if (libxl__remus_domain_resume_qemu(si->gc, si->domid))
> +            return 0;
> +    }
> +    return 1;
> +}
> +
> +/* For now, just sleep. Later, we need to release disk/netbuf */
> +static int libxl__remus_domain_checkpoint_callback(void *data)
> +{
> +    struct suspendinfo *si = data;
> +
> +    if (si->hvm && libxl__domain_save_device_model(si->gc, si->domid,
> +                                                   si->save_fd, 1))
> +            return 0;
> +
> +    usleep(si->interval * 1000);
> +    return 1;
> +}
> +
>  int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                   libxl_domain_type type,
> -                                 int live, int debug)
> +                                 int live, int debug,
> +                                 const libxl_domain_remus_info *r_info)
>  {
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int flags;
> @@ -614,10 +676,20 @@

Please can you add :
        [diff]
        showfunc = True

to your ~/.hgrc.

>          return ERROR_INVAL;
>      }
>  
> +    memset(&si, 0, sizeof(si));
>      flags = (live) ? XCFLAGS_LIVE : 0
>            | (debug) ? XCFLAGS_DEBUG : 0
>            | (hvm) ? XCFLAGS_HVM : 0;
>  
> +    if (r_info != NULL) {
> +        si.interval = r_info->interval;
> +        if (r_info->compression)
> +            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
> +        si.save_fd = fd;
> +    }
> +    else
> +        si.save_fd = -1;
> +
>      si.domid = domid;
>      si.flags = flags;
>      si.hvm = hvm;
> @@ -641,7 +713,13 @@
>      }
>  
>      memset(&callbacks, 0, sizeof(callbacks));
> -    callbacks.suspend = libxl__domain_suspend_common_callback;
> +    if (r_info != NULL) {
> +        callbacks.suspend = libxl__remus_domain_suspend_callback;
> +        callbacks.postcopy = libxl__remus_domain_resume_callback;
> +        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
> +    } else
> +        callbacks.suspend = libxl__domain_suspend_common_callback;
> +
>      callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
>      callbacks.data = &si;
>  
> diff -r 11fb1dfda7de -r 0446591bee86 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Mon Jan 23 14:43:58 2012 -0800
> +++ b/tools/libxl/libxl_internal.h	Mon Jan 23 14:44:00 2012 -0800
> @@ -272,7 +272,8 @@
>                                           int fd);
>  _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
>                                           libxl_domain_type type,
> -                                         int live, int debug);
> +                                         int live, int debug,
> +                                         const libxl_domain_remus_info *r_info);
>  _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
>  _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd,
>                                              int remus);
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 25 11:46:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11: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 1Rq1IM-00034i-Pv; Wed, 25 Jan 2012 11:45:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rq1IL-00034d-BQ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:45:41 +0000
Received: from [85.158.138.51:34907] by server-7.bemta-3.messagelabs.com id
	6D/40-31267-46BEF1F4; Wed, 25 Jan 2012 11:45:40 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327491939!10615158!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 25 Jan 2012 11:45:39 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 11:45:39 -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 q0PBjXvU003768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 06:45:33 -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 q0PBjT9S008911; Wed, 25 Jan 2012 06:45:30 -0500
Message-ID: <4F1FEB59.8060102@redhat.com>
Date: Wed, 25 Jan 2012 13:45:29 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
	<1326981859.17599.87.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
	xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/19/2012 04:16 PM, Stefano Stabellini wrote:
> > 
> > If you are migrating to a newer qemu then the <original-addr> could in
> > principal change, I think.
>
> Not unless the implementation of qemu_ram_alloc_from_ptr or
> find_ram_offset change, but these are core qemu functions.

Both of these functions will be removed.  There will no longer be a
qemu-internal address space for physical memory; instead memory will be
addressed using a (MemoryRegion, offset) pair.

We can/will hook memory_region_init_ram() to call xen_ram_alloc() which
can then generate those old addresses, but those (like qemu_ram_alloc())
are dependent on allocation order and you shouldn't depend on them
returning stable values.

> Or the device starts allocating more memory of course, but it wouldn't
> be the same device anymore.
> In any case, if we also match on the MemoryRegion name we cannot go
> wrong.

Match on just the MemoryRegion (and match on the object itself, not the
name; see xen_register_framebuffer()).

> > > We could add some additional info to better identify the physmap entry,
> > > probably the best we could use is the memory_region name.
> > 
> > And/Or the PCI BDF + BAR?
>
> I don't think we can get the PCI BDF from the Xen MemoryListener, but we
> can get the MemoryRegion. The most identifying info in it I think is the
> name, for example for vga would be "vga.vram".


-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:46:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11: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 1Rq1IM-00034i-Pv; Wed, 25 Jan 2012 11:45:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <avi@redhat.com>) id 1Rq1IL-00034d-BQ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:45:41 +0000
Received: from [85.158.138.51:34907] by server-7.bemta-3.messagelabs.com id
	6D/40-31267-46BEF1F4; Wed, 25 Jan 2012 11:45:40 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327491939!10615158!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12839 invoked from network); 25 Jan 2012 11:45:39 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 11:45:39 -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 q0PBjXvU003768
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 06:45:33 -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 q0PBjT9S008911; Wed, 25 Jan 2012 06:45:30 -0500
Message-ID: <4F1FEB59.8060102@redhat.com>
Date: Wed, 25 Jan 2012 13:45:29 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
	<1326981859.17599.87.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
	xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/19/2012 04:16 PM, Stefano Stabellini wrote:
> > 
> > If you are migrating to a newer qemu then the <original-addr> could in
> > principal change, I think.
>
> Not unless the implementation of qemu_ram_alloc_from_ptr or
> find_ram_offset change, but these are core qemu functions.

Both of these functions will be removed.  There will no longer be a
qemu-internal address space for physical memory; instead memory will be
addressed using a (MemoryRegion, offset) pair.

We can/will hook memory_region_init_ram() to call xen_ram_alloc() which
can then generate those old addresses, but those (like qemu_ram_alloc())
are dependent on allocation order and you shouldn't depend on them
returning stable values.

> Or the device starts allocating more memory of course, but it wouldn't
> be the same device anymore.
> In any case, if we also match on the MemoryRegion name we cannot go
> wrong.

Match on just the MemoryRegion (and match on the object itself, not the
name; see xen_register_framebuffer()).

> > > We could add some additional info to better identify the physmap entry,
> > > probably the best we could use is the memory_region name.
> > 
> > And/Or the PCI BDF + BAR?
>
> I don't think we can get the PCI BDF from the Xen MemoryListener, but we
> can get the MemoryRegion. The most identifying info in it I think is the
> name, for example for vga would be "vga.vram".


-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:52:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11: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 1Rq1OZ-0003Xp-LL; Wed, 25 Jan 2012 11:52:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq1OY-0003Xk-IP
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:52:06 +0000
Received: from [85.158.138.51:51595] by server-11.bemta-3.messagelabs.com id
	D9/D3-26051-5ECEF1F4; Wed, 25 Jan 2012 11:52:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327492324!10610808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10455 invoked from network); 25 Jan 2012 11:52:05 -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;
	25 Jan 2012 11:52:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10274188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:52:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 11:52:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 11:52:03 +0000
In-Reply-To: <822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327492324.24561.309.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/libxl: xl remus/remus-receive
 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 Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327358642 28800
> # Node ID 822536df4aeced5aee00f1f26299086faa622681
> # Parent  0446591bee86eb4e767d75b70c885549c7a3cfef
> tools/libxl: xl remus/remus-receive commands
> 
>  * xl remus (and its receive counterpart remus-receive) act as frontends
>    to enable remus for a given domain.
>  * At the moment, only memory checkpointing and blackhole replication are
>    supported. Support for disk checkpointing and network buffering will
>    be added in future.
>  * xl remus borrows some aspects of xl migrate. Replication is currently
>    done over a ssh connection. Future versions will use a low-overhead
>    plain tcp socket for replication (similar to xend/remus).

Please also patch docs/man/xl.*.pod as required.

Other references to relevant documentation and/or the addition of such
documentation to the tree would also be useful.

> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 0446591bee86 -r 822536df4aec tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c       Mon Jan 23 14:44:00 2012 -0800
> +++ b/tools/libxl/libxl.c       Mon Jan 23 14:44:02 2012 -0800
> @@ -466,6 +466,40 @@
>      return ptr;
>  }
> 
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> +                             uint32_t domid, int fd)
> +{
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    int rc = 0;
> +
> +    if (info == NULL) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "No remus_info structure supplied for domain %d", domid);
> +        rc = -1;
> +        goto remus_fail;
> +    }
> +
> +    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
> +
> +    /* Point of no return */
> +    rc = libxl__domain_suspend_common(gc, domid, fd, type, /* live */ 1,
> +                                      /* debug */ 0, info);
> +
> +    /*
> +     * With Remus, if we reach this point, it means either
> +     * backup died or some network error occurred preventing us
> +     * from sending checkpoints.
> +     */
> +
> +    /* TBD: Remus cleanup - i.e. detach qdisc, release other
> +     * resources.
> +     */
> + remus_fail:
> +    GC_FREE;
> +    return rc;
> +}
> +
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                           uint32_t domid, int fd)
>  {

> diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Mon Jan 23 14:44:00 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c  Mon Jan 23 14:44:02 2012 -0800
> @@ -1814,7 +1814,7 @@
>       * If we have daemonized then do not return to the caller -- this has
>       * already happened in the parent.
>       */
> -    if ( !need_daemon )
> +    if ( daemonize && !need_daemon )

What is this change for?

>          exit(ret);
> 
>      return ret;
> @@ -5853,6 +5853,175 @@
>      return ret;
>  }
> 
> +int main_remus_receive(int argc, char **argv)

Can this not be done as a flag to migrate-receive? Likewise is there
common code between the remus migrate and regular migration?

Is there any reason that remus would not benefit from the xl migration
protocol preamble?

> +{
> +    int rc;
> +    char *migration_domname;
> +    struct domain_create dom_info;
> +
> +    signal(SIGPIPE, SIG_IGN);
> +    memset(&dom_info, 0, sizeof(dom_info));
> +    dom_info.debug = 1;
> +    dom_info.no_incr_generationid = 1;
> +    dom_info.restore_file = "incoming checkpoint stream";
> +    dom_info.migrate_fd = 0; /* stdin - will change in future*/
> +    dom_info.migration_domname_r = &migration_domname;
> +
> +    rc = create_domain(&dom_info);

I'm totally failing to see where the Remus'ness of this create_domain
comes from.

> +    if (rc < 0) {
> +        fprintf(stderr, "migration target (Remus): Domain creation failed"
> +                " (code %d) domid %u.\n", rc, domid);
> +        exit(-rc);
> +    }
> +
> +    /* If we are here, it means that the sender (primary) has crashed.
> +     * If domain renaming fails, lets just continue (as we need the domain
> +     * to be up & dom names may not matter much, as long as its reachable
> +     * over network).
> +     *
> +     * If domain unpausing fails, destroy domain ? Or is it better to have
> +     * a consistent copy of the domain (memory, cpu state, disk)
> +     * on atleast one physical host ? Right now, lets just leave the domain

             at least 

> +     * as is and let the Administrator decide (or troubleshoot).
> +     */
> +    fprintf(stderr, "migration target: Remus Failover for domain %u\n", domid);
> +    if (migration_domname) {
> +        rc = libxl_domain_rename(ctx, domid, migration_domname,
> +                                 common_domname);
> +        if (rc)
> +            fprintf(stderr, "migration target (Remus): "
> +                    "Failed to rename domain from %s to %s:%d\n",
> +                    migration_domname, common_domname, rc);
> +
> +        rc = libxl_domain_unpause(ctx, domid);
> +        if (rc)
> +            fprintf(stderr, "migration target (Remus): "
> +                    "Failed to unpause domain %s (id: %u):%d\n",
> +                    common_domname, domid, rc);
> +    }
> +
> +    return -rc;
> +}
> +
> +int main_remus(int argc, char **argv)
> +{
> +    int opt, rc;
> +    const char *ssh_command = "ssh";
> +    char *host = NULL, *rune = NULL, *domain = NULL;
> +
> +    int sendpipe[2], recvpipe[2];
> +    int send_fd = -1, recv_fd = -1;
> +    pid_t child = -1;
> +
> +    uint8_t *config_data;
> +    int config_len;
> +
> +    libxl_domain_remus_info r_info;
> +
> +    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
> +    /* Defaults */
> +    r_info.interval = 200;
> +    r_info.blackhole = 0;
> +    r_info.compression = 1;
> +
> +    while ((opt = def_getopt(argc, argv, "bui:s:", "remus", 2)) != -1) {

main_migrate handles a bunch of other options which might also be
interesting in the Remus case? Better would be to add all this as an
option to the std migrate.

> +        switch (opt) {
> +        case 0: case 2:
> +            return opt;
> +
> +        case 'i':
> +           r_info.interval = atoi(optarg);
> +            break;
> +        case 'b':
> +            r_info.blackhole = 1;
> +            break;
> +        case 'u':
> +           r_info.compression = 0;
> +            break;
> +        case 's':
> +            ssh_command = optarg;
> +            break;
> +        }
> +    }
> +
> +    domain = argv[optind];
> +    host = argv[optind + 1];
> +
> +    if (r_info.blackhole) {
> +        find_domain(domain);
> +        send_fd = open("/dev/null", O_RDWR, 0644);
> +        if (send_fd < 0) {
> +            perror("failed to open /dev/null");
> +            exit(-1);
> +        }
> +    } else {

The following duplicates an awful lot of main_migrate which begs for
them to either be the same underlying command or at least for some
refactoring.

> +
> +        if (!ssh_command[0]) {
> +            rune = host;
> +        } else {
> +            if (asprintf(&rune, "exec %s %s xl remus-receive",
> +                         ssh_command, host) < 0)
> +                return 1;
> +        }
> +
> +        save_domain_core_begin(domain, NULL, &config_data, &config_len);
> +
> +        if (!config_len) {
> +            fprintf(stderr, "No config file stored for running domain and "
> +                    "none supplied - cannot start remus.\n");
> +            exit(1);
> +        }
> +
> +        MUST( libxl_pipe(ctx, sendpipe) );
> +        MUST( libxl_pipe(ctx, recvpipe) );
> +
> +        child = libxl_fork(ctx);
> +        if (child==-1) exit(1);
> +
> +        /* TODO: change this to plain TCP socket based channel
> +         * instead of SSH.

There are good reasons for using ssh though. However the user can supply
another command which is not encrypted if they want to.

Whatever happens here the same arguments would apply to non-remus
migration so the changes should be done for both (or better the code
should be made more common.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:52:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11: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 1Rq1OZ-0003Xp-LL; Wed, 25 Jan 2012 11:52:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq1OY-0003Xk-IP
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:52:06 +0000
Received: from [85.158.138.51:51595] by server-11.bemta-3.messagelabs.com id
	D9/D3-26051-5ECEF1F4; Wed, 25 Jan 2012 11:52:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327492324!10610808!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10455 invoked from network); 25 Jan 2012 11:52:05 -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;
	25 Jan 2012 11:52:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10274188"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:52:04 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 11:52:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 11:52:03 +0000
In-Reply-To: <822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327492324.24561.309.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/libxl: xl remus/remus-receive
 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 Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327358642 28800
> # Node ID 822536df4aeced5aee00f1f26299086faa622681
> # Parent  0446591bee86eb4e767d75b70c885549c7a3cfef
> tools/libxl: xl remus/remus-receive commands
> 
>  * xl remus (and its receive counterpart remus-receive) act as frontends
>    to enable remus for a given domain.
>  * At the moment, only memory checkpointing and blackhole replication are
>    supported. Support for disk checkpointing and network buffering will
>    be added in future.
>  * xl remus borrows some aspects of xl migrate. Replication is currently
>    done over a ssh connection. Future versions will use a low-overhead
>    plain tcp socket for replication (similar to xend/remus).

Please also patch docs/man/xl.*.pod as required.

Other references to relevant documentation and/or the addition of such
documentation to the tree would also be useful.

> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 0446591bee86 -r 822536df4aec tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c       Mon Jan 23 14:44:00 2012 -0800
> +++ b/tools/libxl/libxl.c       Mon Jan 23 14:44:02 2012 -0800
> @@ -466,6 +466,40 @@
>      return ptr;
>  }
> 
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> +                             uint32_t domid, int fd)
> +{
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    int rc = 0;
> +
> +    if (info == NULL) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "No remus_info structure supplied for domain %d", domid);
> +        rc = -1;
> +        goto remus_fail;
> +    }
> +
> +    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
> +
> +    /* Point of no return */
> +    rc = libxl__domain_suspend_common(gc, domid, fd, type, /* live */ 1,
> +                                      /* debug */ 0, info);
> +
> +    /*
> +     * With Remus, if we reach this point, it means either
> +     * backup died or some network error occurred preventing us
> +     * from sending checkpoints.
> +     */
> +
> +    /* TBD: Remus cleanup - i.e. detach qdisc, release other
> +     * resources.
> +     */
> + remus_fail:
> +    GC_FREE;
> +    return rc;
> +}
> +
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                           uint32_t domid, int fd)
>  {

> diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c  Mon Jan 23 14:44:00 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c  Mon Jan 23 14:44:02 2012 -0800
> @@ -1814,7 +1814,7 @@
>       * If we have daemonized then do not return to the caller -- this has
>       * already happened in the parent.
>       */
> -    if ( !need_daemon )
> +    if ( daemonize && !need_daemon )

What is this change for?

>          exit(ret);
> 
>      return ret;
> @@ -5853,6 +5853,175 @@
>      return ret;
>  }
> 
> +int main_remus_receive(int argc, char **argv)

Can this not be done as a flag to migrate-receive? Likewise is there
common code between the remus migrate and regular migration?

Is there any reason that remus would not benefit from the xl migration
protocol preamble?

> +{
> +    int rc;
> +    char *migration_domname;
> +    struct domain_create dom_info;
> +
> +    signal(SIGPIPE, SIG_IGN);
> +    memset(&dom_info, 0, sizeof(dom_info));
> +    dom_info.debug = 1;
> +    dom_info.no_incr_generationid = 1;
> +    dom_info.restore_file = "incoming checkpoint stream";
> +    dom_info.migrate_fd = 0; /* stdin - will change in future*/
> +    dom_info.migration_domname_r = &migration_domname;
> +
> +    rc = create_domain(&dom_info);

I'm totally failing to see where the Remus'ness of this create_domain
comes from.

> +    if (rc < 0) {
> +        fprintf(stderr, "migration target (Remus): Domain creation failed"
> +                " (code %d) domid %u.\n", rc, domid);
> +        exit(-rc);
> +    }
> +
> +    /* If we are here, it means that the sender (primary) has crashed.
> +     * If domain renaming fails, lets just continue (as we need the domain
> +     * to be up & dom names may not matter much, as long as its reachable
> +     * over network).
> +     *
> +     * If domain unpausing fails, destroy domain ? Or is it better to have
> +     * a consistent copy of the domain (memory, cpu state, disk)
> +     * on atleast one physical host ? Right now, lets just leave the domain

             at least 

> +     * as is and let the Administrator decide (or troubleshoot).
> +     */
> +    fprintf(stderr, "migration target: Remus Failover for domain %u\n", domid);
> +    if (migration_domname) {
> +        rc = libxl_domain_rename(ctx, domid, migration_domname,
> +                                 common_domname);
> +        if (rc)
> +            fprintf(stderr, "migration target (Remus): "
> +                    "Failed to rename domain from %s to %s:%d\n",
> +                    migration_domname, common_domname, rc);
> +
> +        rc = libxl_domain_unpause(ctx, domid);
> +        if (rc)
> +            fprintf(stderr, "migration target (Remus): "
> +                    "Failed to unpause domain %s (id: %u):%d\n",
> +                    common_domname, domid, rc);
> +    }
> +
> +    return -rc;
> +}
> +
> +int main_remus(int argc, char **argv)
> +{
> +    int opt, rc;
> +    const char *ssh_command = "ssh";
> +    char *host = NULL, *rune = NULL, *domain = NULL;
> +
> +    int sendpipe[2], recvpipe[2];
> +    int send_fd = -1, recv_fd = -1;
> +    pid_t child = -1;
> +
> +    uint8_t *config_data;
> +    int config_len;
> +
> +    libxl_domain_remus_info r_info;
> +
> +    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
> +    /* Defaults */
> +    r_info.interval = 200;
> +    r_info.blackhole = 0;
> +    r_info.compression = 1;
> +
> +    while ((opt = def_getopt(argc, argv, "bui:s:", "remus", 2)) != -1) {

main_migrate handles a bunch of other options which might also be
interesting in the Remus case? Better would be to add all this as an
option to the std migrate.

> +        switch (opt) {
> +        case 0: case 2:
> +            return opt;
> +
> +        case 'i':
> +           r_info.interval = atoi(optarg);
> +            break;
> +        case 'b':
> +            r_info.blackhole = 1;
> +            break;
> +        case 'u':
> +           r_info.compression = 0;
> +            break;
> +        case 's':
> +            ssh_command = optarg;
> +            break;
> +        }
> +    }
> +
> +    domain = argv[optind];
> +    host = argv[optind + 1];
> +
> +    if (r_info.blackhole) {
> +        find_domain(domain);
> +        send_fd = open("/dev/null", O_RDWR, 0644);
> +        if (send_fd < 0) {
> +            perror("failed to open /dev/null");
> +            exit(-1);
> +        }
> +    } else {

The following duplicates an awful lot of main_migrate which begs for
them to either be the same underlying command or at least for some
refactoring.

> +
> +        if (!ssh_command[0]) {
> +            rune = host;
> +        } else {
> +            if (asprintf(&rune, "exec %s %s xl remus-receive",
> +                         ssh_command, host) < 0)
> +                return 1;
> +        }
> +
> +        save_domain_core_begin(domain, NULL, &config_data, &config_len);
> +
> +        if (!config_len) {
> +            fprintf(stderr, "No config file stored for running domain and "
> +                    "none supplied - cannot start remus.\n");
> +            exit(1);
> +        }
> +
> +        MUST( libxl_pipe(ctx, sendpipe) );
> +        MUST( libxl_pipe(ctx, recvpipe) );
> +
> +        child = libxl_fork(ctx);
> +        if (child==-1) exit(1);
> +
> +        /* TODO: change this to plain TCP socket based channel
> +         * instead of SSH.

There are good reasons for using ssh though. However the user can supply
another command which is not encrypted if they want to.

Whatever happens here the same arguments would apply to non-remus
migration so the changes should be done for both (or better the code
should be made more common.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:55:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11: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 1Rq1RS-0003gZ-E4; Wed, 25 Jan 2012 11:55:06 +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 1Rq1RR-0003gP-L3
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:55:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327492499!12315782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14550 invoked from network); 25 Jan 2012 11:54:59 -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;
	25 Jan 2012 11:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10274301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:54:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 11:54:59 +0000
Date: Wed, 25 Jan 2012 11:55:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F1FEB59.8060102@redhat.com>
Message-ID: <alpine.DEB.2.00.1201251154000.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
	<1326981859.17599.87.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
	<4F1FEB59.8060102@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Avi Kivity wrote:
> On 01/19/2012 04:16 PM, Stefano Stabellini wrote:
> > > 
> > > If you are migrating to a newer qemu then the <original-addr> could in
> > > principal change, I think.
> >
> > Not unless the implementation of qemu_ram_alloc_from_ptr or
> > find_ram_offset change, but these are core qemu functions.
> 
> Both of these functions will be removed.  There will no longer be a
> qemu-internal address space for physical memory; instead memory will be
> addressed using a (MemoryRegion, offset) pair.
> 
> We can/will hook memory_region_init_ram() to call xen_ram_alloc() which
> can then generate those old addresses, but those (like qemu_ram_alloc())
> are dependent on allocation order and you shouldn't depend on them
> returning stable values.
> 
> > Or the device starts allocating more memory of course, but it wouldn't
> > be the same device anymore.
> > In any case, if we also match on the MemoryRegion name we cannot go
> > wrong.
> 
> Match on just the MemoryRegion (and match on the object itself, not the
> name; see xen_register_framebuffer()).

I agree that would be ideal, but how can that work across save/restore?
Unless we introduce some other kind of identifier for MemoryRegion, the
best we have is the name right now, correct?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 11:55:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 11: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 1Rq1RS-0003gZ-E4; Wed, 25 Jan 2012 11:55:06 +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 1Rq1RR-0003gP-L3
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 11:55:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327492499!12315782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14550 invoked from network); 25 Jan 2012 11:54:59 -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;
	25 Jan 2012 11:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10274301"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:54:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 11:54:59 +0000
Date: Wed, 25 Jan 2012 11:55:36 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Avi Kivity <avi@redhat.com>
In-Reply-To: <4F1FEB59.8060102@redhat.com>
Message-ID: <alpine.DEB.2.00.1201251154000.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
	<1326981859.17599.87.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
	<4F1FEB59.8060102@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
 xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Avi Kivity wrote:
> On 01/19/2012 04:16 PM, Stefano Stabellini wrote:
> > > 
> > > If you are migrating to a newer qemu then the <original-addr> could in
> > > principal change, I think.
> >
> > Not unless the implementation of qemu_ram_alloc_from_ptr or
> > find_ram_offset change, but these are core qemu functions.
> 
> Both of these functions will be removed.  There will no longer be a
> qemu-internal address space for physical memory; instead memory will be
> addressed using a (MemoryRegion, offset) pair.
> 
> We can/will hook memory_region_init_ram() to call xen_ram_alloc() which
> can then generate those old addresses, but those (like qemu_ram_alloc())
> are dependent on allocation order and you shouldn't depend on them
> returning stable values.
> 
> > Or the device starts allocating more memory of course, but it wouldn't
> > be the same device anymore.
> > In any case, if we also match on the MemoryRegion name we cannot go
> > wrong.
> 
> Match on just the MemoryRegion (and match on the object itself, not the
> name; see xen_register_framebuffer()).

I agree that would be ideal, but how can that work across save/restore?
Unless we introduce some other kind of identifier for MemoryRegion, the
best we have is the name right now, correct?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 12:01:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 12:01:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq1XG-0003wo-Fx; Wed, 25 Jan 2012 12:01:06 +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 1Rq1XF-0003wa-ID
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 12:01:05 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327492810!50010585!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15317 invoked from network); 25 Jan 2012 12:00:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	25 Jan 2012 12:00:11 -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 q0PC0qsS005548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 07:00:53 -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 q0PC0oXI014399; Wed, 25 Jan 2012 07:00:50 -0500
Message-ID: <4F1FEEF1.6060801@redhat.com>
Date: Wed, 25 Jan 2012 14:00:49 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
	<1326981859.17599.87.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
	<4F1FEB59.8060102@redhat.com>
	<alpine.DEB.2.00.1201251154000.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201251154000.3196@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
	xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/25/2012 01:55 PM, Stefano Stabellini wrote:
> > 
> > Match on just the MemoryRegion (and match on the object itself, not the
> > name; see xen_register_framebuffer()).
>
> I agree that would be ideal, but how can that work across save/restore?
> Unless we introduce some other kind of identifier for MemoryRegion, the
> best we have is the name right now, correct?

Right, you can't put the pointer in save/restore, the name is the only
option (and that's what qemu uses in its native save format).  I thought
you were talking about internal matching, like in a previous version of
the patch/discussion.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 12:01:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 12:01:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq1XG-0003wo-Fx; Wed, 25 Jan 2012 12:01:06 +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 1Rq1XF-0003wa-ID
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 12:01:05 +0000
X-Env-Sender: avi@redhat.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327492810!50010585!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15317 invoked from network); 25 Jan 2012 12:00:11 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-10.tower-27.messagelabs.com with SMTP;
	25 Jan 2012 12:00:11 -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 q0PC0qsS005548
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 07:00:53 -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 q0PC0oXI014399; Wed, 25 Jan 2012 07:00:50 -0500
Message-ID: <4F1FEEF1.6060801@redhat.com>
Date: Wed, 25 Jan 2012 14:00:49 +0200
From: Avi Kivity <avi@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201191134350.3150@kaball-desktop>
	<1326974181-32511-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<1326975896.17599.81.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191301000.3150@kaball-desktop>
	<1326981859.17599.87.camel@zakaz.uk.xensource.com>
	<alpine.DEB.2.00.1201191407050.3150@kaball-desktop>
	<4F1FEB59.8060102@redhat.com>
	<alpine.DEB.2.00.1201251154000.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201251154000.3196@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [PATCH v3 5/6] xen: record physmap changes to
	xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/25/2012 01:55 PM, Stefano Stabellini wrote:
> > 
> > Match on just the MemoryRegion (and match on the object itself, not the
> > name; see xen_register_framebuffer()).
>
> I agree that would be ideal, but how can that work across save/restore?
> Unless we introduce some other kind of identifier for MemoryRegion, the
> best we have is the name right now, correct?

Right, you can't put the pointer in save/restore, the name is the only
option (and that's what qemu uses in its native save format).  I thought
you were talking about internal matching, like in a previous version of
the patch/discussion.

-- 
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 12:02:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 12:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq1Yg-000423-0f; Wed, 25 Jan 2012 12:02:34 +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 1Rq1Ye-00041l-Jf
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 12:02:32 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327492945!12492715!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.1 required=7.0 tests=FROM_EXCESS_QP,HTML_30_40,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20891 invoked from network); 25 Jan 2012 12:02:26 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 12:02:26 -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=LfT9+RXBZ34dApFhHTFjarV0Lm+ua
	ui9GR2rS3mkn54=; b=jsRfmj2vz87pJdLrNFJP+8Zb8P2iNIh1PIGXaRi0yBXCZ
	MsUMnACNR92LFMRdUNEL9JGUZ9KftU7kXEWDitUK5u6IQIf1keVLWglW78Ou2NVq
	fpWTgHgwEkvX4J1v5CZD7wZf/agQbxMMR00ZK0u9jt3GvRJQJUUGlGfE6y/ALE=
Received: (qmail 624 invoked from network); 25 Jan 2012 13:02:25 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.223.117)
	by mail.zeus06.de with ESMTPA; 25 Jan 2012 13:02:25 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 216C62C55D;
	Wed, 25 Jan 2012 13:02:45 +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 R1ajEYnlN4pN; Wed, 25 Jan 2012 13:02:43 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 586D72C55B;
	Wed, 25 Jan 2012 13:02:43 +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: Wed, 25 Jan 2012 13:02:43 +0100
Mime-Version: 1.0
In-Reply-To: <20120123223213.GA31929@phenom.dumpdata.com>
References: <20120123223213.GA31929@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4f1fef63.3fdf.6023d7677550323a@uhura.space.zz>
Cc: =?utf-8?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?Jan_Beulich?= <jbeulich@suse.com>
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="===============6935847097306474898=="
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.
--===============6935847097306474898==
Content-Type: multipart/alternative; 
 boundary="=_zZ-7LHgDF3de04T61sXBDaWrO7U7ur3zjzypBiz0AOzPZbPX"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_zZ-7LHgDF3de04T61sXBDaWrO7U7ur3zjzypBiz0AOzPZbPX
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I can now confirm that saa7146_vmalloc_build_pgtable and vmalloc_to_sg ar=
e called once per=0D=0A=0D=0APCI card and will allocate 329 pages. Sorry,=
 but I am not in the position to modify your patch=20=0D=0A=0D=0Ato patch=
 the functions in the right way, but happy to test...=0D=0A=0D=0A=C2=A0=0D=
=0ABR, Carsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=
=0AAn:Konrad Rzeszutek Wilk <konrad@darnok.org>;=20=0D=0ACC:Sander Eikele=
nboom <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>; =
Jan Beulich <JBeulich@suse.com>;=20=0D=0AVon:Konrad Rzeszutek Wilk <konra=
d.wilk@oracle.com>=0D=0AGesendet:Mo 23.01.2012 23:42=0D=0ABetreff:Re: [Xe=
n-devel] Load increase after memory upgrade (part2)=0D=0AAnlage:vmalloc=0D=
=0AOn Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:=
=0D=0A> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:=0D=0A=
> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.c=
om> wrote:=0D=0A> > > The issue as I understand is that the DVB drivers a=
llocate their buffers=0D=0A> > > from 0->4GB most (all the time=3F) so th=
ey never have to do bounce-buffering.=0D=0A> > >=20=0D=0A> > > While the =
pv-ops one ends up quite frequently doing the bounce-buffering,=20=0D=0A>=
 > > which=0D=0A> > > implies that the DVB drivers end up allocating thei=
r buffers above the 4GB.=0D=0A> > > This means we end up spending some CP=
U time (in the guest) copying the=20=0D=0A> > > memory=0D=0A> > > from >4=
GB to 0-4GB region (And vice-versa).=0D=0A> >=20=0D=0A> > This reminds me=
 of something (not sure what XenoLinux you use for=0D=0A> > comparison) -=
 how are they allocating that memory=3F Not vmalloc_32()=0D=0A>=20=0D=0A>=
 I was using the 2.6.18, then the one I saw on Google for Gentoo, and now=
=0D=0A> I am going to look at the 2.6.38 from OpenSuSE.=0D=0A>=20=0D=0A> =
> by chance (I remember having seen numerous uses under - iirc -=0D=0A> >=
 drivers/media/)=3F=0D=0A> >=20=0D=0A> > Obviously, vmalloc_32() and any =
GFP_DMA32 allocations do *not* do=0D=0A> > what their (driver) callers mi=
ght expect in a PV guest (including the=0D=0A> > contiguity assumption fo=
r the latter, recalling that you earlier said=0D=0A> > you were able to s=
ee the problem after several guest starts), and I=0D=0A> > had put into o=
ur kernels an adjustment to make vmalloc_32() actually=0D=0A> > behave as=
 expected.=0D=0A>=20=0D=0A> Aaah.. The plot thickens! Let me look in the =
sources! Thanks for the=0D=0A> pointer.=0D=0A=0D=0AJan hints lead me to t=
he videobuf-dma-sg.c which does indeed to vmalloc_32=0D=0Aand then perfor=
ms PCI DMA operations on the allocted vmalloc_32=0D=0Aarea.=0D=0A=0D=0ASo=
 I cobbled up the attached patch (hadn't actually tested it and sadly=0D=0A=
won't until next week) which removes the call to vmalloc_32 and instead=0D=
=0Asets up DMA allocated set of pages.=0D=0A=0D=0AIf that fixes it for yo=
u that is awesome, but if it breaks please=0D=0Asend me your logs.=0D=0A=0D=
=0ACheers,=0D=0AKonrad=0D=0A_____________________________________________=
__=0D=0AXen-devel mailing list=0D=0AXen-devel@lists.xensource.com=0D=0Aht=
tp://lists.xensource.com/xen-devel=0D=0A
--=_zZ-7LHgDF3de04T61sXBDaWrO7U7ur3zjzypBiz0AOzPZbPX
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>I can now confirm that saa7146_vmalloc_build_pgtable and vmalloc_to_sg =
are called once per</p><p>PCI card and will allocate 329 pages. Sorry, bu=
t I am not in the position to modify your patch </p><p>to patch the funct=
ions in the right way, but happy to test...</p><p>&nbsp;</p><p>BR, Carste=
n.<br />&nbsp;</p><blockquote style=3D"border-left: 2px solid #325FBA; pa=
dding-left: 5px;margin-left:5px;">-----Urspr&uuml;ngliche Nachricht-----<=
br /><strong>An:</strong>=09Konrad Rzeszutek Wilk &lt;konrad@darnok.org&g=
t;; <br /><strong>CC:</strong>=09Sander Eikelenboom &lt;linux@eikelenboom=
=2Eit&gt;; xen-devel &lt;xen-devel@lists.xensource.com&gt;; Jan Beulich &=
lt;JBeulich@suse.com&gt;; <br /><strong>Von:</strong>=09Konrad Rzeszutek =
Wilk &lt;konrad.wilk@oracle.com&gt;<br /><strong>Gesendet:</strong>=09Mo =
23.01.2012 23:42<br /><strong>Betreff:</strong>=09Re: [Xen-devel] Load in=
crease after memory upgrade (part2)<br /><strong>Anlage:</strong>=09vmall=
oc<br />On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk w=
rote:<br />&gt; On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wro=
te:<br />&gt; &gt; &gt;&gt;&gt; On 17.01.12 at 22:02, Konrad Rzeszutek Wi=
lk &lt;konrad.wilk@oracle.com&gt; wrote:<br />&gt; &gt; &gt; The issue as=
 I understand is that the DVB drivers allocate their buffers<br />&gt; &g=
t; &gt; from 0-&gt;4GB most (all the time=3F) so they never have to do bo=
unce-buffering.<br />&gt; &gt; &gt; <br />&gt; &gt; &gt; While the pv-ops=
 one ends up quite frequently doing the bounce-buffering, <br />&gt; &gt;=
 &gt; which<br />&gt; &gt; &gt; implies that the DVB drivers end up alloc=
ating their buffers above the 4GB.<br />&gt; &gt; &gt; This means we end =
up spending some CPU time (in the guest) copying the <br />&gt; &gt; &gt;=
 memory<br />&gt; &gt; &gt; from &gt;4GB to 0-4GB region (And vice-versa)=
=2E<br />&gt; &gt; <br />&gt; &gt; This reminds me of something (not sure=
 what XenoLinux you use for<br />&gt; &gt; comparison) - how are they all=
ocating that memory=3F Not vmalloc_32()<br />&gt; <br />&gt; I was using =
the 2.6.18, then the one I saw on Google for Gentoo, and now<br />&gt; I =
am going to look at the 2.6.38 from OpenSuSE.<br />&gt; <br />&gt; &gt; b=
y chance (I remember having seen numerous uses under - iirc -<br />&gt; &=
gt; drivers/media/)=3F<br />&gt; &gt; <br />&gt; &gt; Obviously, vmalloc_=
32() and any GFP_DMA32 allocations do *not* do<br />&gt; &gt; what their =
(driver) callers might expect in a PV guest (including the<br />&gt; &gt;=
 contiguity assumption for the latter, recalling that you earlier said<br=
 />&gt; &gt; you were able to see the problem after several guest starts)=
, and I<br />&gt; &gt; had put into our kernels an adjustment to make vma=
lloc_32() actually<br />&gt; &gt; behave as expected.<br />&gt; <br />&gt=
; Aaah.. The plot thickens! Let me look in the sources! Thanks for the<br=
 />&gt; pointer.<br /><br />Jan hints lead me to the videobuf-dma-sg.c wh=
ich does indeed to vmalloc_32<br />and then performs PCI DMA operations o=
n the allocted vmalloc_32<br />area.<br /><br />So I cobbled up the attac=
hed patch (hadn&#39;t actually tested it and sadly<br />won&#39;t until n=
ext week) which removes the call to vmalloc_32 and instead<br />sets up D=
MA allocated set of pages.<br /><br />If that fixes it for you that is aw=
esome, but if it breaks please<br />send me your logs.<br /><br />Cheers,=
<br />Konrad<br />_______________________________________________<br />Xe=
n-devel mailing list<br />Xen-devel@lists.xensource.com<br />http://lists=
=2Exensource.com/xen-devel<br /></blockquote>=0A</body>=0A</html>
--=_zZ-7LHgDF3de04T61sXBDaWrO7U7ur3zjzypBiz0AOzPZbPX--



--===============6935847097306474898==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6935847097306474898==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 12:02:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 12:02:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq1Yg-000423-0f; Wed, 25 Jan 2012 12:02:34 +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 1Rq1Ye-00041l-Jf
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 12:02:32 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327492945!12492715!1
X-Originating-IP: [194.117.254.36]
X-SpamReason: No, hits=0.1 required=7.0 tests=FROM_EXCESS_QP,HTML_30_40,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20891 invoked from network); 25 Jan 2012 12:02:26 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-12.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 12:02:26 -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=LfT9+RXBZ34dApFhHTFjarV0Lm+ua
	ui9GR2rS3mkn54=; b=jsRfmj2vz87pJdLrNFJP+8Zb8P2iNIh1PIGXaRi0yBXCZ
	MsUMnACNR92LFMRdUNEL9JGUZ9KftU7kXEWDitUK5u6IQIf1keVLWglW78Ou2NVq
	fpWTgHgwEkvX4J1v5CZD7wZf/agQbxMMR00ZK0u9jt3GvRJQJUUGlGfE6y/ALE=
Received: (qmail 624 invoked from network); 25 Jan 2012 13:02:25 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.223.117)
	by mail.zeus06.de with ESMTPA; 25 Jan 2012 13:02:25 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 216C62C55D;
	Wed, 25 Jan 2012 13:02:45 +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 R1ajEYnlN4pN; Wed, 25 Jan 2012 13:02:43 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 586D72C55B;
	Wed, 25 Jan 2012 13:02:43 +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: Wed, 25 Jan 2012 13:02:43 +0100
Mime-Version: 1.0
In-Reply-To: <20120123223213.GA31929@phenom.dumpdata.com>
References: <20120123223213.GA31929@phenom.dumpdata.com>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Message-Id: <zarafa.4f1fef63.3fdf.6023d7677550323a@uhura.space.zz>
Cc: =?utf-8?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>,
	=?utf-8?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?utf-8?Q?Jan_Beulich?= <jbeulich@suse.com>
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="===============6935847097306474898=="
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.
--===============6935847097306474898==
Content-Type: multipart/alternative; 
 boundary="=_zZ-7LHgDF3de04T61sXBDaWrO7U7ur3zjzypBiz0AOzPZbPX"

This is a multi-part message in MIME format. Your mail reader does not
understand MIME message format.
--=_zZ-7LHgDF3de04T61sXBDaWrO7U7ur3zjzypBiz0AOzPZbPX
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I can now confirm that saa7146_vmalloc_build_pgtable and vmalloc_to_sg ar=
e called once per=0D=0A=0D=0APCI card and will allocate 329 pages. Sorry,=
 but I am not in the position to modify your patch=20=0D=0A=0D=0Ato patch=
 the functions in the right way, but happy to test...=0D=0A=0D=0A=C2=A0=0D=
=0ABR, Carsten.=0D=0A=C2=A0=0D=0A-----Urspr=C3=BCngliche Nachricht-----=0D=
=0AAn:Konrad Rzeszutek Wilk <konrad@darnok.org>;=20=0D=0ACC:Sander Eikele=
nboom <linux@eikelenboom.it>; xen-devel <xen-devel@lists.xensource.com>; =
Jan Beulich <JBeulich@suse.com>;=20=0D=0AVon:Konrad Rzeszutek Wilk <konra=
d.wilk@oracle.com>=0D=0AGesendet:Mo 23.01.2012 23:42=0D=0ABetreff:Re: [Xe=
n-devel] Load increase after memory upgrade (part2)=0D=0AAnlage:vmalloc=0D=
=0AOn Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:=
=0D=0A> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:=0D=0A=
> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.c=
om> wrote:=0D=0A> > > The issue as I understand is that the DVB drivers a=
llocate their buffers=0D=0A> > > from 0->4GB most (all the time=3F) so th=
ey never have to do bounce-buffering.=0D=0A> > >=20=0D=0A> > > While the =
pv-ops one ends up quite frequently doing the bounce-buffering,=20=0D=0A>=
 > > which=0D=0A> > > implies that the DVB drivers end up allocating thei=
r buffers above the 4GB.=0D=0A> > > This means we end up spending some CP=
U time (in the guest) copying the=20=0D=0A> > > memory=0D=0A> > > from >4=
GB to 0-4GB region (And vice-versa).=0D=0A> >=20=0D=0A> > This reminds me=
 of something (not sure what XenoLinux you use for=0D=0A> > comparison) -=
 how are they allocating that memory=3F Not vmalloc_32()=0D=0A>=20=0D=0A>=
 I was using the 2.6.18, then the one I saw on Google for Gentoo, and now=
=0D=0A> I am going to look at the 2.6.38 from OpenSuSE.=0D=0A>=20=0D=0A> =
> by chance (I remember having seen numerous uses under - iirc -=0D=0A> >=
 drivers/media/)=3F=0D=0A> >=20=0D=0A> > Obviously, vmalloc_32() and any =
GFP_DMA32 allocations do *not* do=0D=0A> > what their (driver) callers mi=
ght expect in a PV guest (including the=0D=0A> > contiguity assumption fo=
r the latter, recalling that you earlier said=0D=0A> > you were able to s=
ee the problem after several guest starts), and I=0D=0A> > had put into o=
ur kernels an adjustment to make vmalloc_32() actually=0D=0A> > behave as=
 expected.=0D=0A>=20=0D=0A> Aaah.. The plot thickens! Let me look in the =
sources! Thanks for the=0D=0A> pointer.=0D=0A=0D=0AJan hints lead me to t=
he videobuf-dma-sg.c which does indeed to vmalloc_32=0D=0Aand then perfor=
ms PCI DMA operations on the allocted vmalloc_32=0D=0Aarea.=0D=0A=0D=0ASo=
 I cobbled up the attached patch (hadn't actually tested it and sadly=0D=0A=
won't until next week) which removes the call to vmalloc_32 and instead=0D=
=0Asets up DMA allocated set of pages.=0D=0A=0D=0AIf that fixes it for yo=
u that is awesome, but if it breaks please=0D=0Asend me your logs.=0D=0A=0D=
=0ACheers,=0D=0AKonrad=0D=0A_____________________________________________=
__=0D=0AXen-devel mailing list=0D=0AXen-devel@lists.xensource.com=0D=0Aht=
tp://lists.xensource.com/xen-devel=0D=0A
--=_zZ-7LHgDF3de04T61sXBDaWrO7U7ur3zjzypBiz0AOzPZbPX
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>I can now confirm that saa7146_vmalloc_build_pgtable and vmalloc_to_sg =
are called once per</p><p>PCI card and will allocate 329 pages. Sorry, bu=
t I am not in the position to modify your patch </p><p>to patch the funct=
ions in the right way, but happy to test...</p><p>&nbsp;</p><p>BR, Carste=
n.<br />&nbsp;</p><blockquote style=3D"border-left: 2px solid #325FBA; pa=
dding-left: 5px;margin-left:5px;">-----Urspr&uuml;ngliche Nachricht-----<=
br /><strong>An:</strong>=09Konrad Rzeszutek Wilk &lt;konrad@darnok.org&g=
t;; <br /><strong>CC:</strong>=09Sander Eikelenboom &lt;linux@eikelenboom=
=2Eit&gt;; xen-devel &lt;xen-devel@lists.xensource.com&gt;; Jan Beulich &=
lt;JBeulich@suse.com&gt;; <br /><strong>Von:</strong>=09Konrad Rzeszutek =
Wilk &lt;konrad.wilk@oracle.com&gt;<br /><strong>Gesendet:</strong>=09Mo =
23.01.2012 23:42<br /><strong>Betreff:</strong>=09Re: [Xen-devel] Load in=
crease after memory upgrade (part2)<br /><strong>Anlage:</strong>=09vmall=
oc<br />On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk w=
rote:<br />&gt; On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wro=
te:<br />&gt; &gt; &gt;&gt;&gt; On 17.01.12 at 22:02, Konrad Rzeszutek Wi=
lk &lt;konrad.wilk@oracle.com&gt; wrote:<br />&gt; &gt; &gt; The issue as=
 I understand is that the DVB drivers allocate their buffers<br />&gt; &g=
t; &gt; from 0-&gt;4GB most (all the time=3F) so they never have to do bo=
unce-buffering.<br />&gt; &gt; &gt; <br />&gt; &gt; &gt; While the pv-ops=
 one ends up quite frequently doing the bounce-buffering, <br />&gt; &gt;=
 &gt; which<br />&gt; &gt; &gt; implies that the DVB drivers end up alloc=
ating their buffers above the 4GB.<br />&gt; &gt; &gt; This means we end =
up spending some CPU time (in the guest) copying the <br />&gt; &gt; &gt;=
 memory<br />&gt; &gt; &gt; from &gt;4GB to 0-4GB region (And vice-versa)=
=2E<br />&gt; &gt; <br />&gt; &gt; This reminds me of something (not sure=
 what XenoLinux you use for<br />&gt; &gt; comparison) - how are they all=
ocating that memory=3F Not vmalloc_32()<br />&gt; <br />&gt; I was using =
the 2.6.18, then the one I saw on Google for Gentoo, and now<br />&gt; I =
am going to look at the 2.6.38 from OpenSuSE.<br />&gt; <br />&gt; &gt; b=
y chance (I remember having seen numerous uses under - iirc -<br />&gt; &=
gt; drivers/media/)=3F<br />&gt; &gt; <br />&gt; &gt; Obviously, vmalloc_=
32() and any GFP_DMA32 allocations do *not* do<br />&gt; &gt; what their =
(driver) callers might expect in a PV guest (including the<br />&gt; &gt;=
 contiguity assumption for the latter, recalling that you earlier said<br=
 />&gt; &gt; you were able to see the problem after several guest starts)=
, and I<br />&gt; &gt; had put into our kernels an adjustment to make vma=
lloc_32() actually<br />&gt; &gt; behave as expected.<br />&gt; <br />&gt=
; Aaah.. The plot thickens! Let me look in the sources! Thanks for the<br=
 />&gt; pointer.<br /><br />Jan hints lead me to the videobuf-dma-sg.c wh=
ich does indeed to vmalloc_32<br />and then performs PCI DMA operations o=
n the allocted vmalloc_32<br />area.<br /><br />So I cobbled up the attac=
hed patch (hadn&#39;t actually tested it and sadly<br />won&#39;t until n=
ext week) which removes the call to vmalloc_32 and instead<br />sets up D=
MA allocated set of pages.<br /><br />If that fixes it for you that is aw=
esome, but if it breaks please<br />send me your logs.<br /><br />Cheers,=
<br />Konrad<br />_______________________________________________<br />Xe=
n-devel mailing list<br />Xen-devel@lists.xensource.com<br />http://lists=
=2Exensource.com/xen-devel<br /></blockquote>=0A</body>=0A</html>
--=_zZ-7LHgDF3de04T61sXBDaWrO7U7ur3zjzypBiz0AOzPZbPX--



--===============6935847097306474898==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6935847097306474898==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 12:09:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 12: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 1Rq1fP-0004GP-V5; Wed, 25 Jan 2012 12:09: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 1Rq1fP-0004GK-2l
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 12:09:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327493324!57390129!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10778 invoked from network); 25 Jan 2012 12:08:44 -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;
	25 Jan 2012 12:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10275059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:09:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:09: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
	1Rq1fF-0007lY-61; Wed, 25 Jan 2012 12:09:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rq1fF-0006YO-4V;
	Wed, 25 Jan 2012 12:09:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20255.61681.23982.967893@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 12:09:21 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7yBoKFybmPvco+qvBV_HQxGvvvwHxw-HySsjmXmW9M5Q@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
	<CAPLaKK7yBoKFybmPvco+qvBV_HQxGvvvwHxw-HySsjmXmW9M5Q@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: add support fo=
r yajl 2.x"):
> I'm going to re-work on the yajl 2.0 support, to try to fix the
> remaining issues with this patch. Just to be clear, should I rebase
> this patch based on the autoconf stuff?

I'm happy either way.  We're probably going to end up with both in 4.2
but I think the yajl 2.0 support is important.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 12:09:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 12: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 1Rq1fP-0004GP-V5; Wed, 25 Jan 2012 12:09: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 1Rq1fP-0004GK-2l
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 12:09:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327493324!57390129!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10778 invoked from network); 25 Jan 2012 12:08:44 -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;
	25 Jan 2012 12:08:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,567,1320624000"; d="scan'208";a="10275059"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:09:24 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:09: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
	1Rq1fF-0007lY-61; Wed, 25 Jan 2012 12:09:21 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rq1fF-0006YO-4V;
	Wed, 25 Jan 2012 12:09:21 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20255.61681.23982.967893@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 12:09:21 +0000
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK7yBoKFybmPvco+qvBV_HQxGvvvwHxw-HySsjmXmW9M5Q@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>
	<20227.16947.747976.735762@mariner.uk.xensource.com>
	<1327315626.24561.32.camel@zakaz.uk.xensource.com>
	<CAPLaKK766Ai0GrzEV0N6bc_M=9J_aGHDGKfYzqvnsROiOhvLpw@mail.gmail.com>
	<1327318760.24561.73.camel@zakaz.uk.xensource.com>
	<CAPLaKK7yBoKFybmPvco+qvBV_HQxGvvvwHxw-HySsjmXmW9M5Q@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>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.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

Roger Pau Monn=E9 writes ("Re: [Xen-devel] [PATCH v2] libxl: add support fo=
r yajl 2.x"):
> I'm going to re-work on the yajl 2.0 support, to try to fix the
> remaining issues with this patch. Just to be clear, should I rebase
> this patch based on the autoconf stuff?

I'm happy either way.  We're probably going to end up with both in 4.2
but I think the yajl 2.0 support is important.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 12:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 12:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq28O-0004ny-HS; Wed, 25 Jan 2012 12:39:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rq28N-0004nt-Gi
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 12:39:27 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327495160!12321480!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24868 invoked from network); 25 Jan 2012 12:39:20 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 12:39:20 -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 q0PCdBeq023298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 07:39:12 -0500
Received: from redhat.com (vpn-203-125.tlv.redhat.com [10.35.203.125])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q0PCd5ld021446; Wed, 25 Jan 2012 07:39:06 -0500
Date: Wed, 25 Jan 2012 14:41:24 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Message-ID: <20120125124124.GA22203@redhat.com>
References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com>
	<1327433600-7403-27-git-send-email-aliguori@us.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327433600-7403-27-git-send-email-aliguori@us.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Kevin Wolf <kwolf@redhat.com>, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
	Blue Swirl <blauwirbel@gmail.com>,
	Andreas =?iso-8859-1?Q?F=E4rber?= <andreas.faerber@web.de>,
	qemu-ppc@nongnu.org, Paul Brook <paul@codesourcery.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [PATCH 26/28] pci: convert to QEMU Object Model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 01:33:18PM -0600, Anthony Liguori wrote:
> diff --git a/hw/ac97.c b/hw/ac97.c
> index 03be99b..33b85f5 100644
> --- a/hw/ac97.c
> +++ b/hw/ac97.c
> @@ -1344,21 +1344,30 @@ int ac97_init (PCIBus *bus)
>      return 0;
>  }
>  
> -static PCIDeviceInfo ac97_info = {
> -    .qdev.name    = "AC97",
> -    .qdev.desc    = "Intel 82801AA AC97 Audio",
> -    .qdev.size    = sizeof (AC97LinkState),
> -    .qdev.vmsd    = &vmstate_ac97,
> -    .init         = ac97_initfn,
> -    .exit         = ac97_exitfn,
> -    .vendor_id    = PCI_VENDOR_ID_INTEL,
> -    .device_id    = PCI_DEVICE_ID_INTEL_82801AA_5,
> -    .revision     = 0x01,
> -    .class_id     = PCI_CLASS_MULTIMEDIA_AUDIO,
> -    .qdev.props   = (Property[]) {
> -        DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
> -        DEFINE_PROP_END_OF_LIST(),
> -    }
> +static Property ac97_properties[] = {
> +    DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
> +    DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void ac97_class_init(ObjectClass *klass, void *data)
> +{
> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> +
> +    k->init = ac97_initfn;
> +    k->exit = ac97_exitfn;
> +    k->vendor_id = PCI_VENDOR_ID_INTEL;
> +    k->device_id = PCI_DEVICE_ID_INTEL_82801AA_5;
> +    k->revision = 0x01;
> +    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
> +}
> +
> +static DeviceInfo ac97_info = {
> +    .name = "AC97",
> +    .desc = "Intel 82801AA AC97 Audio",
> +    .size = sizeof (AC97LinkState),
> +    .vmsd = &vmstate_ac97,
> +    .props = ac97_properties,
> +    .class_init = ac97_class_init,
>  };
>  
>  static void ac97_register (void)

So I have a question on this: the whole reason
we moved class, vendor id etc away from device init
functions to a table was to make it possible
to perform queries, like list all available sound device
types, or sort devices based on type, based on these tables.

Another purpose was to remove the manually written description/name,
embedding pci id database in qemu instead, and performing
lookups based on device/vendor id.

We never got these patches but it sounds like a genuinely useful
functionality.

Is this no longer possible?

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 12:39:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 12:39:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq28O-0004ny-HS; Wed, 25 Jan 2012 12:39:28 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mst@redhat.com>) id 1Rq28N-0004nt-Gi
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 12:39:27 +0000
X-Env-Sender: mst@redhat.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327495160!12321480!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0MTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24868 invoked from network); 25 Jan 2012 12:39:20 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-6.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 12:39:20 -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 q0PCdBeq023298
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 07:39:12 -0500
Received: from redhat.com (vpn-203-125.tlv.redhat.com [10.35.203.125])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP
	id q0PCd5ld021446; Wed, 25 Jan 2012 07:39:06 -0500
Date: Wed, 25 Jan 2012 14:41:24 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Message-ID: <20120125124124.GA22203@redhat.com>
References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com>
	<1327433600-7403-27-git-send-email-aliguori@us.ibm.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327433600-7403-27-git-send-email-aliguori@us.ibm.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: Kevin Wolf <kwolf@redhat.com>, xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
	Blue Swirl <blauwirbel@gmail.com>,
	Andreas =?iso-8859-1?Q?F=E4rber?= <andreas.faerber@web.de>,
	qemu-ppc@nongnu.org, Paul Brook <paul@codesourcery.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [PATCH 26/28] pci: convert to QEMU Object Model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 24, 2012 at 01:33:18PM -0600, Anthony Liguori wrote:
> diff --git a/hw/ac97.c b/hw/ac97.c
> index 03be99b..33b85f5 100644
> --- a/hw/ac97.c
> +++ b/hw/ac97.c
> @@ -1344,21 +1344,30 @@ int ac97_init (PCIBus *bus)
>      return 0;
>  }
>  
> -static PCIDeviceInfo ac97_info = {
> -    .qdev.name    = "AC97",
> -    .qdev.desc    = "Intel 82801AA AC97 Audio",
> -    .qdev.size    = sizeof (AC97LinkState),
> -    .qdev.vmsd    = &vmstate_ac97,
> -    .init         = ac97_initfn,
> -    .exit         = ac97_exitfn,
> -    .vendor_id    = PCI_VENDOR_ID_INTEL,
> -    .device_id    = PCI_DEVICE_ID_INTEL_82801AA_5,
> -    .revision     = 0x01,
> -    .class_id     = PCI_CLASS_MULTIMEDIA_AUDIO,
> -    .qdev.props   = (Property[]) {
> -        DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
> -        DEFINE_PROP_END_OF_LIST(),
> -    }
> +static Property ac97_properties[] = {
> +    DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
> +    DEFINE_PROP_END_OF_LIST(),
> +};
> +
> +static void ac97_class_init(ObjectClass *klass, void *data)
> +{
> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
> +
> +    k->init = ac97_initfn;
> +    k->exit = ac97_exitfn;
> +    k->vendor_id = PCI_VENDOR_ID_INTEL;
> +    k->device_id = PCI_DEVICE_ID_INTEL_82801AA_5;
> +    k->revision = 0x01;
> +    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
> +}
> +
> +static DeviceInfo ac97_info = {
> +    .name = "AC97",
> +    .desc = "Intel 82801AA AC97 Audio",
> +    .size = sizeof (AC97LinkState),
> +    .vmsd = &vmstate_ac97,
> +    .props = ac97_properties,
> +    .class_init = ac97_class_init,
>  };
>  
>  static void ac97_register (void)

So I have a question on this: the whole reason
we moved class, vendor id etc away from device init
functions to a table was to make it possible
to perform queries, like list all available sound device
types, or sort devices based on type, based on these tables.

Another purpose was to remove the manually written description/name,
embedding pci id database in qemu instead, and performing
lookups based on device/vendor id.

We never got these patches but it sounds like a genuinely useful
functionality.

Is this no longer possible?

-- 
MST

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:04:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2WD-0005K3-Lf; Wed, 25 Jan 2012 13:04:05 +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 1Rq2WC-0005Jy-A9
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:04:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327496637!12323725!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2001 invoked from network); 25 Jan 2012 13:03:58 -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;
	25 Jan 2012 13:03:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10277987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 13:03: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; Wed, 25 Jan 2012 13:03:57 +0000
Date: Wed, 25 Jan 2012 13:04:35 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this is the fourth version of the Xen save/restore patch series.
We have been discussing this issue for quite a while on #qemu and
qemu-devel:


http://marc.info/?l=qemu-devel&m=132346828427314&w=2
http://marc.info/?l=qemu-devel&m=132377734605464&w=2


The principal changes in the this version are:

- Following Anthony's suggestion I have introduced a new monitor command
to save the non-ram device state to file.

- I have also removed the hack not to reset the cirrus videoram on
restore, because it turns out that the videoram doesn't need to be
reset in the reset handler at all (tested on Win2K, where the problem
was found in the first place).



This is the list of patches with a diffstat:

Anthony PERARD (2):
      xen mapcache: check if memory region has moved.
      xen: do not allocate RAM during INMIGRATE runstate

Stefano Stabellini (4):
      cirrus_vga: do not reset videoram
      Introduce "save_devices"
      xen: record physmap changes to xenstore
      Set runstate to INMIGRATE earlier

 block-migration.c |    2 +-
 hmp-commands.hx   |   14 +++++++
 hw/cirrus_vga.c   |    4 --
 hw/hw.h           |    1 +
 qmp-commands.hx   |   17 +++++++++
 savevm.c          |   72 ++++++++++++++++++++++++++++++++++++-
 sysemu.h          |    1 +
 vl.c              |    4 +-
 xen-all.c         |  104 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen-mapcache.c    |   22 ++++++++++--
 xen-mapcache.h    |    9 ++++-
 11 files changed, 235 insertions(+), 15 deletions(-)


git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-4

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:04:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:04:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2WD-0005K3-Lf; Wed, 25 Jan 2012 13:04:05 +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 1Rq2WC-0005Jy-A9
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:04:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327496637!12323725!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2001 invoked from network); 25 Jan 2012 13:03:58 -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;
	25 Jan 2012 13:03:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10277987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 13:03: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; Wed, 25 Jan 2012 13:03:57 +0000
Date: Wed, 25 Jan 2012 13:04:35 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this is the fourth version of the Xen save/restore patch series.
We have been discussing this issue for quite a while on #qemu and
qemu-devel:


http://marc.info/?l=qemu-devel&m=132346828427314&w=2
http://marc.info/?l=qemu-devel&m=132377734605464&w=2


The principal changes in the this version are:

- Following Anthony's suggestion I have introduced a new monitor command
to save the non-ram device state to file.

- I have also removed the hack not to reset the cirrus videoram on
restore, because it turns out that the videoram doesn't need to be
reset in the reset handler at all (tested on Win2K, where the problem
was found in the first place).



This is the list of patches with a diffstat:

Anthony PERARD (2):
      xen mapcache: check if memory region has moved.
      xen: do not allocate RAM during INMIGRATE runstate

Stefano Stabellini (4):
      cirrus_vga: do not reset videoram
      Introduce "save_devices"
      xen: record physmap changes to xenstore
      Set runstate to INMIGRATE earlier

 block-migration.c |    2 +-
 hmp-commands.hx   |   14 +++++++
 hw/cirrus_vga.c   |    4 --
 hw/hw.h           |    1 +
 qmp-commands.hx   |   17 +++++++++
 savevm.c          |   72 ++++++++++++++++++++++++++++++++++++-
 sysemu.h          |    1 +
 vl.c              |    4 +-
 xen-all.c         |  104 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 xen-mapcache.c    |   22 ++++++++++--
 xen-mapcache.h    |    9 ++++-
 11 files changed, 235 insertions(+), 15 deletions(-)


git://xenbits.xen.org/people/sstabellini/qemu-dm.git saverestore-4

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XR-0005Oj-2V; Wed, 25 Jan 2012 13:05:21 +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 1Rq2XP-0005NC-OS
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327496711!12396712!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1116 invoked from network); 25 Jan 2012 13:05:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:05:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="179018150"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlt005752;
	Wed, 25 Jan 2012 05:05:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:44 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 5/6] Set runstate to INMIGRATE earlier
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index c3a155f..9b9a4fb 100644
--- a/vl.c
+++ b/vl.c
@@ -2972,6 +2972,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_INMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
@@ -3466,7 +3467,6 @@ int main(int argc, char **argv, char **envp)
     }
 
     if (incoming) {
-        runstate_set(RUN_STATE_INMIGRATE);
         int ret = qemu_start_incoming_migration(incoming);
         if (ret < 0) {
             fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XR-0005Oj-2V; Wed, 25 Jan 2012 13:05:21 +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 1Rq2XP-0005NC-OS
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327496711!12396712!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1116 invoked from network); 25 Jan 2012 13:05:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:05:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="179018150"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlt005752;
	Wed, 25 Jan 2012 05:05:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:44 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 5/6] Set runstate to INMIGRATE earlier
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Set runstate to RUN_STATE_INMIGRATE as soon as we can on resume.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 vl.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/vl.c b/vl.c
index c3a155f..9b9a4fb 100644
--- a/vl.c
+++ b/vl.c
@@ -2972,6 +2972,7 @@ int main(int argc, char **argv, char **envp)
                 break;
             case QEMU_OPTION_incoming:
                 incoming = optarg;
+                runstate_set(RUN_STATE_INMIGRATE);
                 break;
             case QEMU_OPTION_nodefaults:
                 default_serial = 0;
@@ -3466,7 +3467,6 @@ int main(int argc, char **argv, char **envp)
     }
 
     if (incoming) {
-        runstate_set(RUN_STATE_INMIGRATE);
         int ret = qemu_start_incoming_migration(incoming);
         if (ret < 0) {
             fprintf(stderr, "Migration failed. Exit code %s(%d), exiting.\n",
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XL-0005NI-3w; Wed, 25 Jan 2012 13:05:15 +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 1Rq2XJ-0005Mw-7m
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327496705!4906929!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4233 invoked from network); 25 Jan 2012 13:05:06 -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;
	25 Jan 2012 13:05:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="21263107"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlp005752;
	Wed, 25 Jan 2012 05:04:56 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:40 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 1/6] cirrus_vga: do not reset videoram
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There is no need to set the videoram to 0xff in cirrus_reset, because it
is the BIOS' job.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index f7b1d3d..5564478 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2760,10 +2760,6 @@ static void cirrus_reset(void *opaque)
     }
     s->vga.cr[0x27] = s->device_id;
 
-    /* Win2K seems to assume that the pattern buffer is at 0xff
-       initially ! */
-    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
-
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XL-0005NI-3w; Wed, 25 Jan 2012 13:05:15 +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 1Rq2XJ-0005Mw-7m
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:13 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327496705!4906929!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4233 invoked from network); 25 Jan 2012 13:05:06 -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;
	25 Jan 2012 13:05:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="21263107"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlp005752;
	Wed, 25 Jan 2012 05:04:56 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:40 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 1/6] cirrus_vga: do not reset videoram
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There is no need to set the videoram to 0xff in cirrus_reset, because it
is the BIOS' job.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/cirrus_vga.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index f7b1d3d..5564478 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
@@ -2760,10 +2760,6 @@ static void cirrus_reset(void *opaque)
     }
     s->vga.cr[0x27] = s->device_id;
 
-    /* Win2K seems to assume that the pattern buffer is at 0xff
-       initially ! */
-    memset(s->vga.vram_ptr, 0xff, s->real_vram_size);
-
     s->cirrus_hidden_dac_lockindex = 5;
     s->cirrus_hidden_dac_data = 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XN-0005Np-L2; Wed, 25 Jan 2012 13:05: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 1Rq2XL-0005NR-U1
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327496595!61154049!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17569 invoked from network); 25 Jan 2012 13:03:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="21263111"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tls005752;
	Wed, 25 Jan 2012 05:05:02 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:43 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 4/6] xen mapcache: check if memory region 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

From: Anthony PERARD <anthony.perard@citrix.com>

This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 4b00a6c..bb66c82 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -1039,7 +1055,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 9fecc64..d9c995b 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)
 {
 }
 
-- 
1.7.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 Jan 25 13:05:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XN-0005Np-L2; Wed, 25 Jan 2012 13:05: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 1Rq2XL-0005NR-U1
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327496595!61154049!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17569 invoked from network); 25 Jan 2012 13:03:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="21263111"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tls005752;
	Wed, 25 Jan 2012 05:05:02 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:43 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 4/6] xen mapcache: check if memory region 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

From: Anthony PERARD <anthony.perard@citrix.com>

This patch changes the xen_map_cache behavior. Before trying to map a guest
addr, mapcache will look into the list of range of address that have been moved
(physmap/set_memory). There is currently one memory space like this, the vram,
"moved" from were it's allocated to were the guest will look into.

This help to have a succefull migration.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c      |   18 +++++++++++++++++-
 xen-mapcache.c |   22 +++++++++++++++++++---
 xen-mapcache.h |    9 +++++++--
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 4b00a6c..bb66c82 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -225,6 +225,22 @@ static XenPhysmap *get_physmapping(XenIOState *state,
     return NULL;
 }
 
+static target_phys_addr_t xen_phys_offset_to_gaddr(target_phys_addr_t start_addr,
+                                                   ram_addr_t size, void *opaque)
+{
+    target_phys_addr_t addr = start_addr & TARGET_PAGE_MASK;
+    XenIOState *xen_io_state = opaque;
+    XenPhysmap *physmap = NULL;
+
+    QLIST_FOREACH(physmap, &xen_io_state->physmap, list) {
+        if (range_covers_byte(physmap->phys_offset, physmap->size, addr)) {
+            return physmap->start_addr;
+        }
+    }
+
+    return start_addr;
+}
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 340
 static int xen_add_to_physmap(XenIOState *state,
                               target_phys_addr_t start_addr,
@@ -1039,7 +1055,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 9fecc64..d9c995b 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)
 {
 }
 
-- 
1.7.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 Jan 25 13:05:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XT-0005PW-9V; Wed, 25 Jan 2012 13:05: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 1Rq2XQ-0005NH-An
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327496670!61674135!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4135 invoked from network); 25 Jan 2012 13:04:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:04:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="179018155"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlu005752;
	Wed, 25 Jan 2012 05:05:05 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:45 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 6/6] xen: do not allocate RAM during
	INMIGRATE 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

From: Anthony PERARD <anthony.perard@citrix.com>

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bb66c82..5b10d0c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* RAM already populated in Xen */
+        fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
+                " bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
+                __func__, size, ram_addr); 
+        return;
+    }
+
     if (mr == &ram_memory) {
         return;
     }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:05:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XT-0005PW-9V; Wed, 25 Jan 2012 13:05: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 1Rq2XQ-0005NH-An
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327496670!61674135!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4135 invoked from network); 25 Jan 2012 13:04:31 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:04:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="179018155"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlu005752;
	Wed, 25 Jan 2012 05:05:05 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:45 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, avi@redhat.com, anthony@codemonkey.ws,
	Anthony PERARD <anthony.perard@citrix.com>
Subject: [Xen-devel] [PATCH v4 6/6] xen: do not allocate RAM during
	INMIGRATE 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

From: Anthony PERARD <anthony.perard@citrix.com>

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bb66c82..5b10d0c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -190,6 +190,14 @@ void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size, MemoryRegion *mr)
     xen_pfn_t *pfn_list;
     int i;
 
+    if (runstate_check(RUN_STATE_INMIGRATE)) {
+        /* RAM already populated in Xen */
+        fprintf(stderr, "%s: do not alloc "RAM_ADDR_FMT
+                " bytes of ram at "RAM_ADDR_FMT" when runstate is INMIGRATE\n",
+                __func__, size, ram_addr); 
+        return;
+    }
+
     if (mr == &ram_memory) {
         return;
     }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:05:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XS-0005P4-Fn; Wed, 25 Jan 2012 13:05:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rq2XQ-0005NF-15
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327496711!12396712!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1185 invoked from network); 25 Jan 2012 13:05:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:05:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="179018151"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlq005752;
	Wed, 25 Jan 2012 05:04:58 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:41 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 2/6] Introduce "save_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

- add an "is_ram" flag to SaveStateEntry;

- add an "is_ram" parameter to register_savevm_live;

- introduce a "save_devices" monitor command that can be used to save
the state of non-ram devices.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 block-migration.c |    2 +-
 hmp-commands.hx   |   14 ++++++++++
 hw/hw.h           |    1 +
 qmp-commands.hx   |   17 ++++++++++++
 savevm.c          |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 sysemu.h          |    1 +
 vl.c              |    2 +-
 7 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/block-migration.c b/block-migration.c
index 2b7edbc..424a87d 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -720,6 +720,6 @@ void blk_mig_init(void)
     QSIMPLEQ_INIT(&block_mig_state.bmds_list);
     QSIMPLEQ_INIT(&block_mig_state.blk_list);
 
-    register_savevm_live(NULL, "block", 0, 1, block_set_params,
+    register_savevm_live(NULL, "block", 0, 1, 0, block_set_params,
                          block_save_live, NULL, block_load, &block_mig_state);
 }
diff --git a/hmp-commands.hx b/hmp-commands.hx
index a586498..ba4c9d5 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -241,6 +241,20 @@ a snapshot with the same tag or ID, it is replaced. More info at
 ETEXI
 
     {
+        .name       = "save_devices",
+        .args_type  = "filename:F",
+        .params     = "filename",
+        .help       = "save the state of non-ram devices.",
+        .mhandler.cmd_new = do_save_device_state,
+    },
+
+STEXI
+@item save_devices @var{filename}
+@findex save_devices
+Save the state of non-ram devices.
+ETEXI
+
+    {
         .name       = "loadvm",
         .args_type  = "name:s",
         .params     = "tag|id",
diff --git a/hw/hw.h b/hw/hw.h
index 932014a..9d3d76d 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -263,6 +263,7 @@ int register_savevm_live(DeviceState *dev,
                          const char *idstr,
                          int instance_id,
                          int version_id,
+                         int is_ram,
                          SaveSetParamsHandler *set_params,
 			 SaveLiveStateHandler *save_live_state,
                          SaveStateHandler *save_state,
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 7e3f4b9..51f4436 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -429,6 +429,23 @@ Note: inject-nmi is only supported for x86 guest currently, it will
 EQMP
 
     {
+        .name       = "save_devices",
+        .args_type  = "filename:F",
+        .params     = "filename",
+        .help       = "save the state of non-ram devices.",
+        .user_print = monitor_user_noop,	
+    .mhandler.cmd_new = do_save_device_state,
+    },
+
+SQMP
+save_devices
+-------
+
+Save the state of non-ram devices.
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/savevm.c b/savevm.c
index 80be1ff..d0e62bb 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1177,6 +1177,7 @@ typedef struct SaveStateEntry {
     void *opaque;
     CompatEntry *compat;
     int no_migrate;
+    int is_ram;
 } SaveStateEntry;
 
 
@@ -1223,6 +1224,7 @@ int register_savevm_live(DeviceState *dev,
                          const char *idstr,
                          int instance_id,
                          int version_id,
+                         int is_ram,
                          SaveSetParamsHandler *set_params,
                          SaveLiveStateHandler *save_live_state,
                          SaveStateHandler *save_state,
@@ -1241,6 +1243,7 @@ int register_savevm_live(DeviceState *dev,
     se->opaque = opaque;
     se->vmsd = NULL;
     se->no_migrate = 0;
+    se->is_ram = is_ram;
 
     if (dev && dev->parent_bus && dev->parent_bus->info->get_dev_path) {
         char *id = dev->parent_bus->info->get_dev_path(dev);
@@ -1277,7 +1280,7 @@ int register_savevm(DeviceState *dev,
                     LoadStateHandler *load_state,
                     void *opaque)
 {
-    return register_savevm_live(dev, idstr, instance_id, version_id,
+    return register_savevm_live(dev, idstr, instance_id, version_id, 0,
                                 NULL, NULL, save_state, load_state, opaque);
 }
 
@@ -1728,6 +1731,43 @@ out:
     return ret;
 }
 
+static int qemu_save_device_state(Monitor *mon, QEMUFile *f)
+{
+    SaveStateEntry *se;
+
+    qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
+    qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+
+    cpu_synchronize_all_states();
+
+    QTAILQ_FOREACH(se, &savevm_handlers, entry) {
+        int len;
+
+        if (se->is_ram)
+            continue;
+        if (se->save_state == NULL && se->vmsd == NULL)
+            continue;
+
+        /* Section type */
+        qemu_put_byte(f, QEMU_VM_SECTION_FULL);
+        qemu_put_be32(f, se->section_id);
+
+        /* ID string */
+        len = strlen(se->idstr);
+        qemu_put_byte(f, len);
+        qemu_put_buffer(f, (uint8_t *)se->idstr, len);
+
+        qemu_put_be32(f, se->instance_id);
+        qemu_put_be32(f, se->version_id);
+
+        vmstate_save(f, se);
+    }
+
+    qemu_put_byte(f, QEMU_VM_EOF);
+
+    return qemu_file_get_error(f);
+}
+
 static SaveStateEntry *find_se(const char *idstr, int instance_id)
 {
     SaveStateEntry *se;
@@ -2109,6 +2149,36 @@ void do_savevm(Monitor *mon, const QDict *qdict)
         vm_start();
 }
 
+int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+    int ret;
+    QEMUFile *f;
+    int saved_vm_running;
+    const char *filename = qdict_get_try_str(qdict, "filename");
+
+    saved_vm_running = runstate_is_running();
+    vm_stop(RUN_STATE_SAVE_VM);
+
+    f = qemu_fopen(filename, "wb");
+    if (!f) {
+        monitor_printf(mon, "Could not open VM state file\n");
+        ret = -1;
+        goto the_end;
+    }
+    ret = qemu_save_device_state(mon, f);
+    qemu_fclose(f);
+    if (ret < 0) {
+        monitor_printf(mon, "Error %d while writing VM\n", ret);
+        goto the_end;
+    }
+    ret = 0;
+
+ the_end:
+    if (saved_vm_running)
+        vm_start();
+    return ret;
+}
+
 int load_vmstate(const char *name)
 {
     BlockDriverState *bs, *bs_vm_state;
diff --git a/sysemu.h b/sysemu.h
index ddef2bb..4103b08 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -59,6 +59,7 @@ void qemu_remove_exit_notifier(Notifier *notify);
 void qemu_add_machine_init_done_notifier(Notifier *notify);
 
 void do_savevm(Monitor *mon, const QDict *qdict);
+int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data);
 int load_vmstate(const char *name);
 void do_delvm(Monitor *mon, const QDict *qdict);
 void do_info_snapshots(Monitor *mon);
diff --git a/vl.c b/vl.c
index ba55b35..c3a155f 100644
--- a/vl.c
+++ b/vl.c
@@ -3270,7 +3270,7 @@ int main(int argc, char **argv, char **envp)
     default_drive(default_sdcard, snapshot, machine->use_scsi,
                   IF_SD, 0, SD_OPTS);
 
-    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
+    register_savevm_live(NULL, "ram", 0, 4, 1, NULL, ram_save_live, NULL,
                          ram_load, NULL);
 
     if (nb_numa_nodes > 0) {
-- 
1.7.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 Jan 25 13:05:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XS-0005P4-Fn; Wed, 25 Jan 2012 13:05:22 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rq2XQ-0005NF-15
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327496711!12396712!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1185 invoked from network); 25 Jan 2012 13:05:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:05:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="179018151"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlq005752;
	Wed, 25 Jan 2012 05:04:58 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:41 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 2/6] Introduce "save_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

- add an "is_ram" flag to SaveStateEntry;

- add an "is_ram" parameter to register_savevm_live;

- introduce a "save_devices" monitor command that can be used to save
the state of non-ram devices.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 block-migration.c |    2 +-
 hmp-commands.hx   |   14 ++++++++++
 hw/hw.h           |    1 +
 qmp-commands.hx   |   17 ++++++++++++
 savevm.c          |   72 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
 sysemu.h          |    1 +
 vl.c              |    2 +-
 7 files changed, 106 insertions(+), 3 deletions(-)

diff --git a/block-migration.c b/block-migration.c
index 2b7edbc..424a87d 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -720,6 +720,6 @@ void blk_mig_init(void)
     QSIMPLEQ_INIT(&block_mig_state.bmds_list);
     QSIMPLEQ_INIT(&block_mig_state.blk_list);
 
-    register_savevm_live(NULL, "block", 0, 1, block_set_params,
+    register_savevm_live(NULL, "block", 0, 1, 0, block_set_params,
                          block_save_live, NULL, block_load, &block_mig_state);
 }
diff --git a/hmp-commands.hx b/hmp-commands.hx
index a586498..ba4c9d5 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -241,6 +241,20 @@ a snapshot with the same tag or ID, it is replaced. More info at
 ETEXI
 
     {
+        .name       = "save_devices",
+        .args_type  = "filename:F",
+        .params     = "filename",
+        .help       = "save the state of non-ram devices.",
+        .mhandler.cmd_new = do_save_device_state,
+    },
+
+STEXI
+@item save_devices @var{filename}
+@findex save_devices
+Save the state of non-ram devices.
+ETEXI
+
+    {
         .name       = "loadvm",
         .args_type  = "name:s",
         .params     = "tag|id",
diff --git a/hw/hw.h b/hw/hw.h
index 932014a..9d3d76d 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -263,6 +263,7 @@ int register_savevm_live(DeviceState *dev,
                          const char *idstr,
                          int instance_id,
                          int version_id,
+                         int is_ram,
                          SaveSetParamsHandler *set_params,
 			 SaveLiveStateHandler *save_live_state,
                          SaveStateHandler *save_state,
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 7e3f4b9..51f4436 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -429,6 +429,23 @@ Note: inject-nmi is only supported for x86 guest currently, it will
 EQMP
 
     {
+        .name       = "save_devices",
+        .args_type  = "filename:F",
+        .params     = "filename",
+        .help       = "save the state of non-ram devices.",
+        .user_print = monitor_user_noop,	
+    .mhandler.cmd_new = do_save_device_state,
+    },
+
+SQMP
+save_devices
+-------
+
+Save the state of non-ram devices.
+
+EQMP
+
+    {
         .name       = "migrate",
         .args_type  = "detach:-d,blk:-b,inc:-i,uri:s",
         .params     = "[-d] [-b] [-i] uri",
diff --git a/savevm.c b/savevm.c
index 80be1ff..d0e62bb 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1177,6 +1177,7 @@ typedef struct SaveStateEntry {
     void *opaque;
     CompatEntry *compat;
     int no_migrate;
+    int is_ram;
 } SaveStateEntry;
 
 
@@ -1223,6 +1224,7 @@ int register_savevm_live(DeviceState *dev,
                          const char *idstr,
                          int instance_id,
                          int version_id,
+                         int is_ram,
                          SaveSetParamsHandler *set_params,
                          SaveLiveStateHandler *save_live_state,
                          SaveStateHandler *save_state,
@@ -1241,6 +1243,7 @@ int register_savevm_live(DeviceState *dev,
     se->opaque = opaque;
     se->vmsd = NULL;
     se->no_migrate = 0;
+    se->is_ram = is_ram;
 
     if (dev && dev->parent_bus && dev->parent_bus->info->get_dev_path) {
         char *id = dev->parent_bus->info->get_dev_path(dev);
@@ -1277,7 +1280,7 @@ int register_savevm(DeviceState *dev,
                     LoadStateHandler *load_state,
                     void *opaque)
 {
-    return register_savevm_live(dev, idstr, instance_id, version_id,
+    return register_savevm_live(dev, idstr, instance_id, version_id, 0,
                                 NULL, NULL, save_state, load_state, opaque);
 }
 
@@ -1728,6 +1731,43 @@ out:
     return ret;
 }
 
+static int qemu_save_device_state(Monitor *mon, QEMUFile *f)
+{
+    SaveStateEntry *se;
+
+    qemu_put_be32(f, QEMU_VM_FILE_MAGIC);
+    qemu_put_be32(f, QEMU_VM_FILE_VERSION);
+
+    cpu_synchronize_all_states();
+
+    QTAILQ_FOREACH(se, &savevm_handlers, entry) {
+        int len;
+
+        if (se->is_ram)
+            continue;
+        if (se->save_state == NULL && se->vmsd == NULL)
+            continue;
+
+        /* Section type */
+        qemu_put_byte(f, QEMU_VM_SECTION_FULL);
+        qemu_put_be32(f, se->section_id);
+
+        /* ID string */
+        len = strlen(se->idstr);
+        qemu_put_byte(f, len);
+        qemu_put_buffer(f, (uint8_t *)se->idstr, len);
+
+        qemu_put_be32(f, se->instance_id);
+        qemu_put_be32(f, se->version_id);
+
+        vmstate_save(f, se);
+    }
+
+    qemu_put_byte(f, QEMU_VM_EOF);
+
+    return qemu_file_get_error(f);
+}
+
 static SaveStateEntry *find_se(const char *idstr, int instance_id)
 {
     SaveStateEntry *se;
@@ -2109,6 +2149,36 @@ void do_savevm(Monitor *mon, const QDict *qdict)
         vm_start();
 }
 
+int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data)
+{
+    int ret;
+    QEMUFile *f;
+    int saved_vm_running;
+    const char *filename = qdict_get_try_str(qdict, "filename");
+
+    saved_vm_running = runstate_is_running();
+    vm_stop(RUN_STATE_SAVE_VM);
+
+    f = qemu_fopen(filename, "wb");
+    if (!f) {
+        monitor_printf(mon, "Could not open VM state file\n");
+        ret = -1;
+        goto the_end;
+    }
+    ret = qemu_save_device_state(mon, f);
+    qemu_fclose(f);
+    if (ret < 0) {
+        monitor_printf(mon, "Error %d while writing VM\n", ret);
+        goto the_end;
+    }
+    ret = 0;
+
+ the_end:
+    if (saved_vm_running)
+        vm_start();
+    return ret;
+}
+
 int load_vmstate(const char *name)
 {
     BlockDriverState *bs, *bs_vm_state;
diff --git a/sysemu.h b/sysemu.h
index ddef2bb..4103b08 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -59,6 +59,7 @@ void qemu_remove_exit_notifier(Notifier *notify);
 void qemu_add_machine_init_done_notifier(Notifier *notify);
 
 void do_savevm(Monitor *mon, const QDict *qdict);
+int do_save_device_state(Monitor *mon, const QDict *qdict, QObject **ret_data);
 int load_vmstate(const char *name);
 void do_delvm(Monitor *mon, const QDict *qdict);
 void do_info_snapshots(Monitor *mon);
diff --git a/vl.c b/vl.c
index ba55b35..c3a155f 100644
--- a/vl.c
+++ b/vl.c
@@ -3270,7 +3270,7 @@ int main(int argc, char **argv, char **envp)
     default_drive(default_sdcard, snapshot, machine->use_scsi,
                   IF_SD, 0, SD_OPTS);
 
-    register_savevm_live(NULL, "ram", 0, 4, NULL, ram_save_live, NULL,
+    register_savevm_live(NULL, "ram", 0, 4, 1, NULL, ram_save_live, NULL,
                          ram_load, NULL);
 
     if (nb_numa_nodes > 0) {
-- 
1.7.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 Jan 25 13:05:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XS-0005PI-SH; Wed, 25 Jan 2012 13:05:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rq2XQ-0005NG-9S
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327496595!61154049!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17535 invoked from network); 25 Jan 2012 13:03:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="21263110"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlr005752;
	Wed, 25 Jan 2012 05:05:00 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:42 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 3/6] xen: record physmap changes to xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index c86ebf4..4b00a6c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -63,7 +63,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 typedef struct XenPhysmap {
     target_phys_addr_t start_addr;
     ram_addr_t size;
-    MemoryRegion *mr;
+    char *name;
     target_phys_addr_t phys_offset;
 
     QLIST_ENTRY(XenPhysmap) list;
@@ -237,6 +237,7 @@ static int xen_add_to_physmap(XenIOState *state,
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+    char path[80], value[17];
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -275,6 +276,7 @@ go_physmap:
 
     physmap->start_addr = start_addr;
     physmap->size = size;
+    physmap->name = (char *)mr->name;
     physmap->phys_offset = phys_offset;
 
     QLIST_INSERT_HEAD(&state->physmap, physmap, list);
@@ -283,6 +285,30 @@ go_physmap:
                                    start_addr >> TARGET_PAGE_BITS,
                                    (start_addr + size) >> TARGET_PAGE_BITS,
                                    XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    if (mr->name) {
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                xen_domid, (uint64_t)phys_offset);
+        if (!xs_write(state->xenstore, 0, path, mr->name, strlen(mr->name))) {
+            return -1;
+        }
+    }
+
     return 0;
 }
 
@@ -910,6 +936,55 @@ int xen_init(void)
     return 0;
 }
 
+static void xen_read_physmap(XenIOState *state)
+{
+    XenPhysmap *physmap = NULL;
+    unsigned int len, num, i;
+    char path[80], *value = NULL;
+    char **entries = NULL;
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap", xen_domid);
+    entries = xs_directory(state->xenstore, 0, path, &num);
+    if (entries == NULL)
+        return;
+
+    for (i = 0; i < num; i++) {
+        physmap = g_malloc(sizeof (XenPhysmap));
+        physmap->phys_offset = strtoull(entries[i], NULL, 16);
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->start_addr = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/size",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->size = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/name",
+                xen_domid, entries[i]);
+        physmap->name = xs_read(state->xenstore, 0, path, &len);
+
+        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+    }
+    free(entries);
+    return;
+}
+
 int xen_hvm_init(void)
 {
     int i, rc;
@@ -982,6 +1057,7 @@ int xen_hvm_init(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
+    xen_read_physmap(state);
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:05:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2XS-0005PI-SH; Wed, 25 Jan 2012 13:05:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rq2XQ-0005NG-9S
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:05:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327496595!61154049!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17535 invoked from network); 25 Jan 2012 13:03:17 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:03:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="21263110"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 08:05:12 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 08:05: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 q0PD4tlr005752;
	Wed, 25 Jan 2012 05:05:00 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Wed, 25 Jan 2012 13:05:42 +0000
Message-ID: <1327496745-31260-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.1201251239180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: jan.kiszka@siemens.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v4 3/6] xen: record physmap changes to xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Write to xenstore any physmap changes so that the hypervisor can be
aware of them.
Read physmap changes from xenstore on boot.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index c86ebf4..4b00a6c 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -63,7 +63,7 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 typedef struct XenPhysmap {
     target_phys_addr_t start_addr;
     ram_addr_t size;
-    MemoryRegion *mr;
+    char *name;
     target_phys_addr_t phys_offset;
 
     QLIST_ENTRY(XenPhysmap) list;
@@ -237,6 +237,7 @@ static int xen_add_to_physmap(XenIOState *state,
     XenPhysmap *physmap = NULL;
     target_phys_addr_t pfn, start_gpfn;
     target_phys_addr_t phys_offset = memory_region_get_ram_addr(mr);
+    char path[80], value[17];
 
     if (get_physmapping(state, start_addr, size)) {
         return 0;
@@ -275,6 +276,7 @@ go_physmap:
 
     physmap->start_addr = start_addr;
     physmap->size = size;
+    physmap->name = (char *)mr->name;
     physmap->phys_offset = phys_offset;
 
     QLIST_INSERT_HEAD(&state->physmap, physmap, list);
@@ -283,6 +285,30 @@ go_physmap:
                                    start_addr >> TARGET_PAGE_BITS,
                                    (start_addr + size) >> TARGET_PAGE_BITS,
                                    XEN_DOMCTL_MEM_CACHEATTR_WB);
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+            xen_domid, (uint64_t)phys_offset);
+    snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
+    if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+        return -1;
+    }
+    if (mr->name) {
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                xen_domid, (uint64_t)phys_offset);
+        if (!xs_write(state->xenstore, 0, path, mr->name, strlen(mr->name))) {
+            return -1;
+        }
+    }
+
     return 0;
 }
 
@@ -910,6 +936,55 @@ int xen_init(void)
     return 0;
 }
 
+static void xen_read_physmap(XenIOState *state)
+{
+    XenPhysmap *physmap = NULL;
+    unsigned int len, num, i;
+    char path[80], *value = NULL;
+    char **entries = NULL;
+
+    snprintf(path, sizeof(path),
+            "/local/domain/0/device-model/%d/physmap", xen_domid);
+    entries = xs_directory(state->xenstore, 0, path, &num);
+    if (entries == NULL)
+        return;
+
+    for (i = 0; i < num; i++) {
+        physmap = g_malloc(sizeof (XenPhysmap));
+        physmap->phys_offset = strtoull(entries[i], NULL, 16);
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->start_addr = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/size",
+                xen_domid, entries[i]);
+        value = xs_read(state->xenstore, 0, path, &len);
+        if (value == NULL) {
+            free(physmap);
+            continue;
+        }
+        physmap->size = strtoull(value, NULL, 16);
+        free(value);
+
+        snprintf(path, sizeof(path),
+                "/local/domain/0/device-model/%d/physmap/%s/name",
+                xen_domid, entries[i]);
+        physmap->name = xs_read(state->xenstore, 0, path, &len);
+
+        QLIST_INSERT_HEAD(&state->physmap, physmap, list);
+    }
+    free(entries);
+    return;
+}
+
 int xen_hvm_init(void)
 {
     int i, rc;
@@ -982,6 +1057,7 @@ int xen_hvm_init(void)
     xen_be_register("console", &xen_console_ops);
     xen_be_register("vkbd", &xen_kbdmouse_ops);
     xen_be_register("qdisk", &xen_blkdev_ops);
+    xen_read_physmap(state);
 
     return 0;
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:13:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2es-0006PN-GE; Wed, 25 Jan 2012 13:13:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rq2eq-0006PI-9C
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:13:00 +0000
Received: from [85.158.138.51:65157] by server-12.bemta-3.messagelabs.com id
	1A/84-24557-BDFFF1F4; Wed, 25 Jan 2012 13:12:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327497178!10560710!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27890 invoked from network); 25 Jan 2012 13:12:58 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:12:58 -0000
Received: by werb14 with SMTP id b14so13496552wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 05:12:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=5GYmUcGzo3sRoNC9MGeaMRQo5UPWNS0S9Pldxb0CO7Q=;
	b=uY7fBjrPNW72fAivq/PpaDhdfU/QSLZYgGP7QpbFlFb6PkuJ9SwPtU6WpwHaOHDtad
	9AlpdgSfCiELI04vtKj3XRet2ccnrWIGhu62wx7TYjnBZXa9fszQpN4NSDTNMXIT5S2a
	43zhaE7ZGbnEzjgoP3LtRXbfN20uFCdq4mzUs=
Received: by 10.216.135.35 with SMTP id t35mr7234478wei.9.1327497178117;
	Wed, 25 Jan 2012 05:12:58 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ho4sm24325450wib.3.2012.01.25.05.12.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Jan 2012 05:12:57 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a1986ef30b7dab4f60fe5cda70856f5751a9fde2
Message-Id: <a1986ef30b7dab4f60fe.1326606964@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 15 Jan 2012 06:56:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v3] 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 1326606960 -3600
# Node ID a1986ef30b7dab4f60fe5cda70856f5751a9fde2
# Parent  cd47dde439e688cac244c7eb9f55d826c85c844f
libxl: add support for yajl 2.x

This patch adds support for yajl versions 2.x, while retaining 1.x
compatibility. All the needed ifdefs can be found in libxl_json.h.

Tested with yajl 2.0.3 and 1.0.12.

Changes since v2:

 * Moved all ifdefs to libxl_json.h, as Ian Jackson suggested.

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 cd47dde439e6 -r a1986ef30b7d Config.mk
--- a/Config.mk	Sat Jan 14 19:04:48 2012 +0100
+++ b/Config.mk	Sun Jan 15 06:56:00 2012 +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_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 cd47dde439e6 -r a1986ef30b7d tools/check/check_yajl_lib
--- a/tools/check/check_yajl_lib	Sat Jan 14 19:04:48 2012 +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 cd47dde439e6 -r a1986ef30b7d tools/libxl/Makefile
--- a/tools/libxl/Makefile	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/Makefile	Sun Jan 15 06:56:00 2012 +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 cd47dde439e6 -r a1986ef30b7d tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_json.c	Sun Jan 15 06:56:00 2012 +0100
@@ -519,7 +519,7 @@ static bool is_decimal(const char *s, un
     return false;
 }
 
-static int json_callback_number(void *opaque, const char *s, unsigned int len)
+static int json_callback_number(void *opaque, const char *s, libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     libxl__json_object *obj = NULL;
@@ -576,7 +576,7 @@ out:
 }
 
 static int json_callback_string(void *opaque, const unsigned char *str,
-                                unsigned int len)
+                                libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -609,7 +609,7 @@ static int json_callback_string(void *op
 }
 
 static int json_callback_map_key(void *opaque, const unsigned char *str,
-                                 unsigned int len)
+                                 libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -772,17 +772,13 @@ libxl__json_object *libxl__json_parse(li
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
     if (yajl_ctx.hand == NULL) {
-        yajl_parser_config cfg = {
-            .allowComments = 1,
-            .checkUTF8 = 1,
-        };
-        yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
+        yajl_ctx.hand = libxl__yajl_alloc(&callbacks, NULL, &yajl_ctx);
     }
     status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
     if (status != yajl_status_ok)
         goto out;
 
-    status = yajl_parse_complete(yajl_ctx.hand);
+    status = yajl_complete_parse(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
 
@@ -834,14 +830,13 @@ 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)
 {
-    yajl_gen_config conf = { 1, "    " };
     const unsigned char *buf;
     char *ret = NULL;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
     if (!hand)
         return NULL;
 
diff -r cd47dde439e6 -r a1986ef30b7d tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_json.h	Sun Jan 15 06:56:00 2012 +0100
@@ -16,8 +16,55 @@
 #define LIBXL_JSON_H
 
 #include <yajl/yajl_gen.h>
+#include <yajl/yajl_parse.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
+
+#ifdef HAVE_YAJL_V2
+typedef size_t libxl_yajl_length;
+
+static inline yajl_handle libxl__yajl_alloc(const yajl_callbacks *callbacks,
+                                            yajl_alloc_funcs *allocFuncs,
+                                            void *ctx)
+{
+    return yajl_alloc(callbacks, allocFuncs, ctx);
+}
+
+static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+{
+    return yajl_gen_alloc(allocFuncs);
+}
+#else
+#define yajl_complete_parse yajl_parse_complete
+
+typedef unsigned int libxl_yajl_length;
+
+static inline yajl_handle libxl__yajl_alloc(const yajl_callbacks *callbacks,
+                                            const yajl_alloc_funcs *allocFuncs,
+                                            void *ctx)
+{
+    yajl_parser_config cfg = {
+        .allowComments = 1,
+        .checkUTF8 = 1,
+    };
+    return yajl_alloc(callbacks, &cfg, allocFuncs, ctx);
+}
+
+static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+{
+    yajl_gen_config conf = { 1, "    " };
+    return yajl_gen_alloc(&conf, allocFuncs);
+}
+#endif
+
 #endif /* LIBXL_JSON_H */
diff -r cd47dde439e6 -r a1986ef30b7d tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Sun Jan 15 06:56:00 2012 +0100
@@ -453,15 +453,15 @@ static char *qmp_send_prepare(libxl__gc 
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
-    yajl_gen_config conf = { 0, NULL };
     const unsigned char *buf = NULL;
     char *ret = NULL;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
+
     if (!hand) {
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:13:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:13:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2es-0006PN-GE; Wed, 25 Jan 2012 13:13:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rq2eq-0006PI-9C
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:13:00 +0000
Received: from [85.158.138.51:65157] by server-12.bemta-3.messagelabs.com id
	1A/84-24557-BDFFF1F4; Wed, 25 Jan 2012 13:12:59 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327497178!10560710!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=2.0 required=7.0 tests=DATE_IN_PAST_96_XX, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27890 invoked from network); 25 Jan 2012 13:12:58 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:12:58 -0000
Received: by werb14 with SMTP id b14so13496552wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 05:12:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:content-type:mime-version:content-transfer-encoding:subject
	:x-mercurial-node:message-id:user-agent:date:from:to;
	bh=5GYmUcGzo3sRoNC9MGeaMRQo5UPWNS0S9Pldxb0CO7Q=;
	b=uY7fBjrPNW72fAivq/PpaDhdfU/QSLZYgGP7QpbFlFb6PkuJ9SwPtU6WpwHaOHDtad
	9AlpdgSfCiELI04vtKj3XRet2ccnrWIGhu62wx7TYjnBZXa9fszQpN4NSDTNMXIT5S2a
	43zhaE7ZGbnEzjgoP3LtRXbfN20uFCdq4mzUs=
Received: by 10.216.135.35 with SMTP id t35mr7234478wei.9.1327497178117;
	Wed, 25 Jan 2012 05:12:58 -0800 (PST)
Received: from alpine.localdomain (tina.upc.es. [147.83.39.243])
	by mx.google.com with ESMTPS id ho4sm24325450wib.3.2012.01.25.05.12.56
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Jan 2012 05:12:57 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a1986ef30b7dab4f60fe5cda70856f5751a9fde2
Message-Id: <a1986ef30b7dab4f60fe.1326606964@alpine.localdomain>
User-Agent: Mercurial-patchbomb/1.9.3
Date: Sun, 15 Jan 2012 06:56:04 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v3] 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 1326606960 -3600
# Node ID a1986ef30b7dab4f60fe5cda70856f5751a9fde2
# Parent  cd47dde439e688cac244c7eb9f55d826c85c844f
libxl: add support for yajl 2.x

This patch adds support for yajl versions 2.x, while retaining 1.x
compatibility. All the needed ifdefs can be found in libxl_json.h.

Tested with yajl 2.0.3 and 1.0.12.

Changes since v2:

 * Moved all ifdefs to libxl_json.h, as Ian Jackson suggested.

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 cd47dde439e6 -r a1986ef30b7d Config.mk
--- a/Config.mk	Sat Jan 14 19:04:48 2012 +0100
+++ b/Config.mk	Sun Jan 15 06:56:00 2012 +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_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 cd47dde439e6 -r a1986ef30b7d tools/check/check_yajl_lib
--- a/tools/check/check_yajl_lib	Sat Jan 14 19:04:48 2012 +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 cd47dde439e6 -r a1986ef30b7d tools/libxl/Makefile
--- a/tools/libxl/Makefile	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/Makefile	Sun Jan 15 06:56:00 2012 +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 cd47dde439e6 -r a1986ef30b7d tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_json.c	Sun Jan 15 06:56:00 2012 +0100
@@ -519,7 +519,7 @@ static bool is_decimal(const char *s, un
     return false;
 }
 
-static int json_callback_number(void *opaque, const char *s, unsigned int len)
+static int json_callback_number(void *opaque, const char *s, libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     libxl__json_object *obj = NULL;
@@ -576,7 +576,7 @@ out:
 }
 
 static int json_callback_string(void *opaque, const unsigned char *str,
-                                unsigned int len)
+                                libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -609,7 +609,7 @@ static int json_callback_string(void *op
 }
 
 static int json_callback_map_key(void *opaque, const unsigned char *str,
-                                 unsigned int len)
+                                 libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -772,17 +772,13 @@ libxl__json_object *libxl__json_parse(li
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
     if (yajl_ctx.hand == NULL) {
-        yajl_parser_config cfg = {
-            .allowComments = 1,
-            .checkUTF8 = 1,
-        };
-        yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
+        yajl_ctx.hand = libxl__yajl_alloc(&callbacks, NULL, &yajl_ctx);
     }
     status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
     if (status != yajl_status_ok)
         goto out;
 
-    status = yajl_parse_complete(yajl_ctx.hand);
+    status = yajl_complete_parse(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
 
@@ -834,14 +830,13 @@ 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)
 {
-    yajl_gen_config conf = { 1, "    " };
     const unsigned char *buf;
     char *ret = NULL;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
     if (!hand)
         return NULL;
 
diff -r cd47dde439e6 -r a1986ef30b7d tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_json.h	Sun Jan 15 06:56:00 2012 +0100
@@ -16,8 +16,55 @@
 #define LIBXL_JSON_H
 
 #include <yajl/yajl_gen.h>
+#include <yajl/yajl_parse.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
+
+#ifdef HAVE_YAJL_V2
+typedef size_t libxl_yajl_length;
+
+static inline yajl_handle libxl__yajl_alloc(const yajl_callbacks *callbacks,
+                                            yajl_alloc_funcs *allocFuncs,
+                                            void *ctx)
+{
+    return yajl_alloc(callbacks, allocFuncs, ctx);
+}
+
+static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+{
+    return yajl_gen_alloc(allocFuncs);
+}
+#else
+#define yajl_complete_parse yajl_parse_complete
+
+typedef unsigned int libxl_yajl_length;
+
+static inline yajl_handle libxl__yajl_alloc(const yajl_callbacks *callbacks,
+                                            const yajl_alloc_funcs *allocFuncs,
+                                            void *ctx)
+{
+    yajl_parser_config cfg = {
+        .allowComments = 1,
+        .checkUTF8 = 1,
+    };
+    return yajl_alloc(callbacks, &cfg, allocFuncs, ctx);
+}
+
+static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+{
+    yajl_gen_config conf = { 1, "    " };
+    return yajl_gen_alloc(&conf, allocFuncs);
+}
+#endif
+
 #endif /* LIBXL_JSON_H */
diff -r cd47dde439e6 -r a1986ef30b7d tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_qmp.c	Sun Jan 15 06:56:00 2012 +0100
@@ -453,15 +453,15 @@ static char *qmp_send_prepare(libxl__gc 
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
-    yajl_gen_config conf = { 0, NULL };
     const unsigned char *buf = NULL;
     char *ret = NULL;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
+
     if (!hand) {
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 13:34:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2zb-0006tj-Fq; Wed, 25 Jan 2012 13:34:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1Rq2zX-0006te-FQ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:34:25 +0000
Received: from [85.158.138.51:62891] by server-1.bemta-3.messagelabs.com id
	B6/68-09565-ED4002F4; Wed, 25 Jan 2012 13:34:22 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327498459!10448308!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28878 invoked from network); 25 Jan 2012 13:34:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:34:21 -0000
Received: by pbdx13 with SMTP id x13so14381922pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 05:34:18 -0800 (PST)
Received: by 10.68.74.41 with SMTP id q9mr40652143pbv.129.1327498458515;
	Wed, 25 Jan 2012 05:34:18 -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 h9sm2539195pbq.14.2012.01.25.05.34.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Jan 2012 05:34:17 -0800 (PST)
Message-ID: <4F2004D5.9060804@codemonkey.ws>
Date: Wed, 25 Jan 2012 07:34:13 -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: "Michael S. Tsirkin" <mst@redhat.com>
References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com>	<1327433600-7403-27-git-send-email-aliguori@us.ibm.com>
	<20120125124124.GA22203@redhat.com>
In-Reply-To: <20120125124124.GA22203@redhat.com>
X-Gm-Message-State: ALoCoQn9vtJzUfmIdCogRsrntB2bwoatk4QF9YRsWZoyce4C1XkxTDA8faOscfYYfpPznFN4jumi
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org,
	Blue Swirl <blauwirbel@gmail.com>,
	=?ISO-8859-1?Q?Andreas_F=E4rber?= <andreas.faerber@web.de>,
	qemu-ppc@nongnu.org, Paul Brook <paul@codesourcery.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 26/28] pci: convert to QEMU
	Object Model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/25/2012 06:41 AM, Michael S. Tsirkin wrote:
> On Tue, Jan 24, 2012 at 01:33:18PM -0600, Anthony Liguori wrote:
>> diff --git a/hw/ac97.c b/hw/ac97.c
>> index 03be99b..33b85f5 100644
>> --- a/hw/ac97.c
>> +++ b/hw/ac97.c
>> @@ -1344,21 +1344,30 @@ int ac97_init (PCIBus *bus)
>>       return 0;
>>   }
>>
>> -static PCIDeviceInfo ac97_info = {
>> -    .qdev.name    = "AC97",
>> -    .qdev.desc    = "Intel 82801AA AC97 Audio",
>> -    .qdev.size    = sizeof (AC97LinkState),
>> -    .qdev.vmsd    =&vmstate_ac97,
>> -    .init         = ac97_initfn,
>> -    .exit         = ac97_exitfn,
>> -    .vendor_id    = PCI_VENDOR_ID_INTEL,
>> -    .device_id    = PCI_DEVICE_ID_INTEL_82801AA_5,
>> -    .revision     = 0x01,
>> -    .class_id     = PCI_CLASS_MULTIMEDIA_AUDIO,
>> -    .qdev.props   = (Property[]) {
>> -        DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
>> -        DEFINE_PROP_END_OF_LIST(),
>> -    }
>> +static Property ac97_properties[] = {
>> +    DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
>> +    DEFINE_PROP_END_OF_LIST(),
>> +};
>> +
>> +static void ac97_class_init(ObjectClass *klass, void *data)
>> +{
>> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>> +
>> +    k->init = ac97_initfn;
>> +    k->exit = ac97_exitfn;
>> +    k->vendor_id = PCI_VENDOR_ID_INTEL;
>> +    k->device_id = PCI_DEVICE_ID_INTEL_82801AA_5;
>> +    k->revision = 0x01;
>> +    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
>> +}
>> +
>> +static DeviceInfo ac97_info = {
>> +    .name = "AC97",
>> +    .desc = "Intel 82801AA AC97 Audio",
>> +    .size = sizeof (AC97LinkState),
>> +    .vmsd =&vmstate_ac97,
>> +    .props = ac97_properties,
>> +    .class_init = ac97_class_init,
>>   };
>>
>>   static void ac97_register (void)
>
> So I have a question on this: the whole reason
> we moved class, vendor id etc away from device init
> functions to a table was to make it possible
> to perform queries, like list all available sound device
> types, or sort devices based on type, based on these tables.
>
> Another purpose was to remove the manually written description/name,
> embedding pci id database in qemu instead, and performing
> lookups based on device/vendor id.
>
> We never got these patches but it sounds like a genuinely useful
> functionality.
>
> Is this no longer possible?

There is one class instance per type.  It's initialized lazily but the types are 
always known.  IOW, ac97_class_init() is called once on the global 
PCIDeviceClass object, most likely very early during init.

These class objects can be searched and interacted with independently of any 
existing object.  What you're after is:

static void show_pci_device(ObjectClass *klass, void *opaque)
{
     PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);

     printf("Device %s is %02x:%02x\n",
            object_class_get_name(klass), pc->vendor_id, pc->device_id);
}

{
     ...
     object_class_foreach(show_pci_device, TYPE_PCI_DEVICE, false, NULL);
}

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 Wed Jan 25 13:34:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 13:34:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq2zb-0006tj-Fq; Wed, 25 Jan 2012 13:34:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <anthony@codemonkey.ws>) id 1Rq2zX-0006te-FQ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 13:34:25 +0000
Received: from [85.158.138.51:62891] by server-1.bemta-3.messagelabs.com id
	B6/68-09565-ED4002F4; Wed, 25 Jan 2012 13:34:22 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327498459!10448308!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28878 invoked from network); 25 Jan 2012 13:34:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 13:34:21 -0000
Received: by pbdx13 with SMTP id x13so14381922pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 05:34:18 -0800 (PST)
Received: by 10.68.74.41 with SMTP id q9mr40652143pbv.129.1327498458515;
	Wed, 25 Jan 2012 05:34:18 -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 h9sm2539195pbq.14.2012.01.25.05.34.15
	(version=TLSv1/SSLv3 cipher=OTHER);
	Wed, 25 Jan 2012 05:34:17 -0800 (PST)
Message-ID: <4F2004D5.9060804@codemonkey.ws>
Date: Wed, 25 Jan 2012 07:34:13 -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: "Michael S. Tsirkin" <mst@redhat.com>
References: <1327433600-7403-1-git-send-email-aliguori@us.ibm.com>	<1327433600-7403-27-git-send-email-aliguori@us.ibm.com>
	<20120125124124.GA22203@redhat.com>
In-Reply-To: <20120125124124.GA22203@redhat.com>
X-Gm-Message-State: ALoCoQn9vtJzUfmIdCogRsrntB2bwoatk4QF9YRsWZoyce4C1XkxTDA8faOscfYYfpPznFN4jumi
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>,
	xen-devel@lists.xensource.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org,
	Blue Swirl <blauwirbel@gmail.com>,
	=?ISO-8859-1?Q?Andreas_F=E4rber?= <andreas.faerber@web.de>,
	qemu-ppc@nongnu.org, Paul Brook <paul@codesourcery.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH 26/28] pci: convert to QEMU
	Object Model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/25/2012 06:41 AM, Michael S. Tsirkin wrote:
> On Tue, Jan 24, 2012 at 01:33:18PM -0600, Anthony Liguori wrote:
>> diff --git a/hw/ac97.c b/hw/ac97.c
>> index 03be99b..33b85f5 100644
>> --- a/hw/ac97.c
>> +++ b/hw/ac97.c
>> @@ -1344,21 +1344,30 @@ int ac97_init (PCIBus *bus)
>>       return 0;
>>   }
>>
>> -static PCIDeviceInfo ac97_info = {
>> -    .qdev.name    = "AC97",
>> -    .qdev.desc    = "Intel 82801AA AC97 Audio",
>> -    .qdev.size    = sizeof (AC97LinkState),
>> -    .qdev.vmsd    =&vmstate_ac97,
>> -    .init         = ac97_initfn,
>> -    .exit         = ac97_exitfn,
>> -    .vendor_id    = PCI_VENDOR_ID_INTEL,
>> -    .device_id    = PCI_DEVICE_ID_INTEL_82801AA_5,
>> -    .revision     = 0x01,
>> -    .class_id     = PCI_CLASS_MULTIMEDIA_AUDIO,
>> -    .qdev.props   = (Property[]) {
>> -        DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
>> -        DEFINE_PROP_END_OF_LIST(),
>> -    }
>> +static Property ac97_properties[] = {
>> +    DEFINE_PROP_UINT32("use_broken_id", AC97LinkState, use_broken_id, 0),
>> +    DEFINE_PROP_END_OF_LIST(),
>> +};
>> +
>> +static void ac97_class_init(ObjectClass *klass, void *data)
>> +{
>> +    PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>> +
>> +    k->init = ac97_initfn;
>> +    k->exit = ac97_exitfn;
>> +    k->vendor_id = PCI_VENDOR_ID_INTEL;
>> +    k->device_id = PCI_DEVICE_ID_INTEL_82801AA_5;
>> +    k->revision = 0x01;
>> +    k->class_id = PCI_CLASS_MULTIMEDIA_AUDIO;
>> +}
>> +
>> +static DeviceInfo ac97_info = {
>> +    .name = "AC97",
>> +    .desc = "Intel 82801AA AC97 Audio",
>> +    .size = sizeof (AC97LinkState),
>> +    .vmsd =&vmstate_ac97,
>> +    .props = ac97_properties,
>> +    .class_init = ac97_class_init,
>>   };
>>
>>   static void ac97_register (void)
>
> So I have a question on this: the whole reason
> we moved class, vendor id etc away from device init
> functions to a table was to make it possible
> to perform queries, like list all available sound device
> types, or sort devices based on type, based on these tables.
>
> Another purpose was to remove the manually written description/name,
> embedding pci id database in qemu instead, and performing
> lookups based on device/vendor id.
>
> We never got these patches but it sounds like a genuinely useful
> functionality.
>
> Is this no longer possible?

There is one class instance per type.  It's initialized lazily but the types are 
always known.  IOW, ac97_class_init() is called once on the global 
PCIDeviceClass object, most likely very early during init.

These class objects can be searched and interacted with independently of any 
existing object.  What you're after is:

static void show_pci_device(ObjectClass *klass, void *opaque)
{
     PCIDeviceClass *pc = PCI_DEVICE_CLASS(klass);

     printf("Device %s is %02x:%02x\n",
            object_class_get_name(klass), pc->vendor_id, pc->device_id);
}

{
     ...
     object_class_foreach(show_pci_device, TYPE_PCI_DEVICE, false, NULL);
}

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 Wed Jan 25 14:16:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3dO-0007Tr-Rw; Wed, 25 Jan 2012 14:15:34 +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 1Rq3dN-0007Tm-Ve
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:15:34 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327500926!11918182!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28067 invoked from network); 25 Jan 2012 14:15:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:15:27 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75014746; Wed, 25 Jan 2012 15:15:24 +0100
Message-ID: <1327500920.2723.11.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:15:20 +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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv3 0 of 2] libxl: Extend CPU affinity syntax and
 enable for specifying it in config 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: multipart/mixed; boundary="===============1113084775177027250=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1113084775177027250==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-nh8llEmFPFy2BfVh1v74"


--=-nh8llEmFPFy2BfVh1v74
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Everyone,

This series slightly extends the current support for specifying CPU
affinity, basically adding the support for "^<cpuid>" kind of entries
(i.e., "^6", meaning "not on CPU#6), and enables doing so in a VM's
config file, like it (probably?) was possible with `xm'.

With respect to v1:
* Syntax made even more general, now "0-4,^1-2" is supported
* Avoid touching printf_info (dryrun case of domain creation)
* Remove another fwd decl that survived to the last round

With respect to v1:
* Reworked (hopefully improved) the parsing of the cpu-pin string
* Removed forward declarations (as asked during review)
* Added some helper functions (as asked during review)
* Put a saner default for cpu-pinning for libxl (as asked during review)

Regards,
Dario

--
generalize-vcpupin-parsig.patch
support-cpus-par-in-config-file.patch
--=20
tools/libxl/libxl.c         |   15 +++++++++++++++
 tools/libxl/libxl.h         |    2 ++
 tools/libxl/libxl_create.c  |    3 +++
 tools/libxl/libxl_dom.c     |    1 +
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/libxl_utils.h   |   14 ++++++++++++++
 tools/libxl/xl_cmdimpl.c    |  117 +++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++--------------------------=
---
 7 files changed, 124 insertions(+), 29 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-nh8llEmFPFy2BfVh1v74
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)

iEYEABECAAYFAk8gDngACgkQk4XaBE3IOsQHrgCgnzSpVN5egdog1vis8vM2Y54/
Q1kAniYnkv4OWLMDHWb57Vod0CRrZQPi
=Pa45
-----END PGP SIGNATURE-----

--=-nh8llEmFPFy2BfVh1v74--



--===============1113084775177027250==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1113084775177027250==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:16:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:16:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3dO-0007Tr-Rw; Wed, 25 Jan 2012 14:15:34 +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 1Rq3dN-0007Tm-Ve
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:15:34 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327500926!11918182!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28067 invoked from network); 25 Jan 2012 14:15:27 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-13.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:15:27 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75014746; Wed, 25 Jan 2012 15:15:24 +0100
Message-ID: <1327500920.2723.11.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:15:20 +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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv3 0 of 2] libxl: Extend CPU affinity syntax and
 enable for specifying it in config 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: multipart/mixed; boundary="===============1113084775177027250=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1113084775177027250==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-nh8llEmFPFy2BfVh1v74"


--=-nh8llEmFPFy2BfVh1v74
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Everyone,

This series slightly extends the current support for specifying CPU
affinity, basically adding the support for "^<cpuid>" kind of entries
(i.e., "^6", meaning "not on CPU#6), and enables doing so in a VM's
config file, like it (probably?) was possible with `xm'.

With respect to v1:
* Syntax made even more general, now "0-4,^1-2" is supported
* Avoid touching printf_info (dryrun case of domain creation)
* Remove another fwd decl that survived to the last round

With respect to v1:
* Reworked (hopefully improved) the parsing of the cpu-pin string
* Removed forward declarations (as asked during review)
* Added some helper functions (as asked during review)
* Put a saner default for cpu-pinning for libxl (as asked during review)

Regards,
Dario

--
generalize-vcpupin-parsig.patch
support-cpus-par-in-config-file.patch
--=20
tools/libxl/libxl.c         |   15 +++++++++++++++
 tools/libxl/libxl.h         |    2 ++
 tools/libxl/libxl_create.c  |    3 +++
 tools/libxl/libxl_dom.c     |    1 +
 tools/libxl/libxl_types.idl |    1 +
 tools/libxl/libxl_utils.h   |   14 ++++++++++++++
 tools/libxl/xl_cmdimpl.c    |  117 +++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++--------------------------=
---
 7 files changed, 124 insertions(+), 29 deletions(-)

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-nh8llEmFPFy2BfVh1v74
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)

iEYEABECAAYFAk8gDngACgkQk4XaBE3IOsQHrgCgnzSpVN5egdog1vis8vM2Y54/
Q1kAniYnkv4OWLMDHWb57Vod0CRrZQPi
=Pa45
-----END PGP SIGNATURE-----

--=-nh8llEmFPFy2BfVh1v74--



--===============1113084775177027250==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1113084775177027250==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:33:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3uT-0007vw-Fy; Wed, 25 Jan 2012 14:33:13 +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 1Rq3uR-0007vm-HD
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:33:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327501983!3594595!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2909 invoked from network); 25 Jan 2012 14:33:04 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:33:04 -0000
Received: by pbdx13 with SMTP id x13so14637115pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 06:33:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=w0DJ0or+raS5+wDfdvqdKvo3hlJ5oyeVcSz53IKk2XQ=;
	b=UK2QQ7kC+lBqegcIZTIFjbrrzeV+GySA43Z5MFhCXR3guPtrlLpni4O9+ETpTrSsdP
	CpBH8NXHWyhDckqAtajXWt3QcDrOOBXJ2mXiaPuEMkYByeD//0BP95D2UvnXnVf7sWDl
	0+QEF1w0lDAOcL2rYSlMvTShjSZiuuWTh0F1w=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr40820668pbu.124.1327501982694; Wed,
	25 Jan 2012 06:33:02 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Wed, 25 Jan 2012 06:33:02 -0800 (PST)
In-Reply-To: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 15:33:02 +0100
X-Google-Sender-Auth: CcXlI6DqISRLVjuW98DX2dIV0Og
Message-ID: <CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE5ld2x5
IHVwZGF0ZWQgbGlzdCBmb2xsb3dzLiBQbGVhc2Ugc2VuZCBtZSBjb3JyZWN0aW9ucyAoZXNwZWNp
YWxseQo+ICJkb25lIikuIEkndmUgc3RvcHBlZCBDQ2luZyBldmVyeW9uZSwgc2luY2UgSSBndWVz
cyBpdCBpcyBtb3N0bHkgc3BhbSB0bwo+IHRoZSBtYWpvcml0eS4KPgo+IGh5cGVydmlzb3IsIGJs
b2NrZXJzOgo+Cj4gwqAgwqAgwqAqIHJvdW5kLXVwIG9mIHRoZSBjbG9zaW5nIG9mIHRoZSBzZWN1
cml0eSBob2xlIGluIE1TSS1YCj4gwqAgwqAgwqAgwqBwYXNzdGhyb3VnaCAodW5pZm9ybWx5IC0g
aS5lLiBldmVuIGZvciBEb20wIC0gZGlzYWxsb3dpbmcgd3JpdGUKPiDCoCDCoCDCoCDCoGFjY2Vz
cyB0byBNU0ktWCB0YWJsZSBwYWdlcykuIChKYW4gQmV1bGljaCAtLSBtb3JlIGZpeGVzCj4gwqAg
wqAgwqAgwqByZXF1aXJlZCB0aGFuIGZpcnN0IHRob3VnaHQsIHBhdGNoZXMgcG9zdGVkKQo+IMKg
IMKgIMKgKiBkb21jdGxzIC8gc3lzY3RscyBzZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJh
bWV0ZXJzLCBsaWtlCj4gwqAgwqAgwqAgwqB0aGUgY3JlZGl0MSB0aW1lc2xpY2UgYW5kIHNjaGVk
dWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwKQo+IMKgIMKgIMKgKiBnZXQgdGhlIGludGVyZmFjZSBj
aGFuZ2VzIGZvciBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCj4gwqAgwqAgwqAg
wqBkdXN0ZWQgc28gdGhhdCA0LjIgaXMgYSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4gKFRp
bSBEZWVnYW4sCj4gwqAgwqAgwqAgwqBBbmRyZXMgTGFnYXItQ2F2aWxsYSBldCBhbCkKPiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNlZW1z
IGNsb3NlIHRvIGdvaW5nCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbi4KPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogc2hhcmluZyBwYXRjaGVzIHBvc3RlZAo+Cj4gdG9vbHMsIGJsb2NrZXJzOgo+
Cj4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVm
aW5lIGEgc3RhYmxlIEFQSQo+IMKgIMKgIMKgIMKgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFy
dCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgo+IMKgIMKgIMKgIMKgdGhpcyBh
cmU6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGV2ZW50IGhhbmRsaW5nIChJYW4gSmFja3Nvbiwg
cG9zdGVkIHNldmVyYWwgcm91bmRzLAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbmVhcmluZyBj
b21wbGV0aW9uPykKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogZHJvcCBsaWJ4bF9kZXZpY2VfbW9k
ZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2luZm8gb3IKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkgKElhbiBDYW1wYmVsbCwgZmlyc3QgUkZDIHNl
bnQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGFkZCBsaWJ4bF9kZWZib29sIGFuZCBnZW5lcmFs
bHkgdHJ5IGFuZCBhcnJhbmdlIHRoYXQKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1lbXNldChm
b28sMCwuLi4pIHJlcXVlc3RzIHRoZSBkZWZhdWx0cyAoSWFuIENhbXBiZWxsLAo+IMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgZmlyc3QgUkZDIHNlbnQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIHRv
cG9sb2d5aW5mbyBkYXRhc3RydWN0dXJlIHNob3VsZCBiZSBhIGxpc3Qgb2YgdHVwbGVzLAo+IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgbm90IGEgdHVwbGUgb2YgbGlzdHMuIChub2JvZHkgY3VycmVu
dGx5IGxvb2tpbmcgYXQgdGhpcywKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5vdCAxMDAlIHN1
cmUgdGhpcyBtYWtlcyBzZW5zZSwgY291bGQgcG9zc2libHkgZGVmZXIgYW5kCj4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqBjaGFuZ2UgYWZ0ZXIgNC4yIGluIGEgY29tcGF0aWJsZSB3YXkpCj4gwqAg
wqAgwqAqIHhsIHRvIHVzZSBqc29uIGZvciBtYWNoaW5lIHJlYWRhYmxlIG91dHB1dCBpbnN0ZWFk
IG9mIHNleHAgYnkKPiDCoCDCoCDCoCDCoGRlZmF1bHQgKElhbiBDYW1wYmVsbCB0byByZXZpc2l0
IGV4aXN0aW5nIHBhdGNoKQo+IMKgIMKgIMKgKiB4bCBzdXBwb3J0IGZvciB2Y3B1IHBpbm5pbmcg
KERhcmlvIEZhZ2dpb2xpKQo+IMKgIMKgIMKgKiB4bCBmZWF0dXJlIHBhcml0eSB3aXRoIHhlbmQg
d3J0IGRyaXZlciBkb21haW4gc3VwcG9ydCAoR2VvcmdlCj4gwqAgwqAgwqAgwqBEdW5sYXApCj4g
wqAgwqAgwqAqIEludGVncmF0ZSBxZW11K3NlYWJpb3MgdXBzdHJlYW0gaW50byB0aGUgYnVpbGQg
KHBhdGNoZXMKPiDCoCDCoCDCoCDCoHJlcG9zdGVkLCBwZW5kaW5nKS4gTm8gY2hhbmdlIGluIGRl
ZmF1bHQgcWVtdSBmb3IgNC4yLgo+IMKgIMKgIMKgKiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4
bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgo+IMKgIMKgIMKgIMKgdHJlZS4gTmVl
ZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPiDCoCDC
oCDCoCDCoHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPgo+IGh5cGVydmlzb3IsIG5pY2UgdG8g
aGF2ZToKPgo+IMKgIMKgIMKgKiBzb2xpZCBpbXBsZW1lbnRhdGlvbiBvZiBzaGFyaW5nL3BhZ2lu
Zy9tZW0tZXZlbnRzICh1c2luZyB3b3JrCj4gwqAgwqAgwqAgwqBxdWV1ZXMpIChUaW0gRGVlZ2Fu
LCBPbGFmIEhlcnJpbmcgZXQgYWwpCj4gwqAgwqAgwqAqIEEgbG9uZyBzdGFuZGluZyBpc3N1ZSBp
cyBhIGZ1bGx5IHN5bmNocm9uaXplZCBwMm0gKGxvY2tpbmcKPiDCoCDCoCDCoCDCoGxvb2t1cHMp
IChBbmRyZXMgTGFnYXItQ2F2aWxsYSkKPiDCoCDCoCDCoCogTlVNQSBpbXByb3ZlbWVudDogZG9t
YWluIGFmZmluaXR5IGNvbnNpc3RlbnQgd2l0aCBjcHVwb29sCj4gwqAgwqAgwqAgwqBtZW1iZXJz
aGlwIChEYXJpbyBGYWdnaW9saSwgSmV1cmdlbiBHcm9zcyAtLSBwYXRjaCBwb3N0ZWQpCj4KPiB0
b29scywgbmljZSB0byBoYXZlOgo+Cj4gwqAgwqAgwqAqIEhvdHBsdWcgc2NyaXB0IHN0dWZmIC0t
IGludGVybmFsIHRvIGxpYnhsIChJIHRoaW5rLCB0aGVyZWZvcmUgSQo+IMKgIMKgIMKgIMKgZGlk
bid0IHB1dCB0aGlzIHVuZGVyIHN0YWJsZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhh
dmUKPiDCoCDCoCDCoCDCoGZvciA0LjI/IFJvZ2VyIFBhdSBNb25ldCB3YXMgbG9va2luZyBhdCB0
aGlzIGJ1dCBpdHMgbG9va2luZwo+IMKgIMKgIMKgIMKgbGlrZSBhIGJpZyBjYW4tby13b3Jtcy4g
KGRpc2N1c3Npb24gb24tZ29pbmcpCj4gwqAgwqAgwqAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0t
IGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIKPiDCoCDCoCDCoCDCoFBhdSBN
b25ldCkKPiDCoCDCoCDCoCogbGlieWFqbCB2MiBzdXBwb3J0IChwYXRjaCBwb3N0ZWQgYnkgUm9n
ZXIgUGF1IE1vbmV0LCBibG9ja2VkIG9uCj4gwqAgwqAgwqAgwqBhdXRvY29uZj8pCj4gwqAgwqAg
wqAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVycmluZykK
PiDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkg
UGVyYXJkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9y
ZSAoQW50aG9ueSBQZXJhcmQpCj4gwqAgwqAgwqAqIE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3Vy
cmVudGx5IHNob3VsZCBiZSBtYXJrZWQKPiDCoCDCoCDCoCDCoGV4cGVyaW1lbnRhbCxsaWtlbHkg
dG8gcmVsZWFzZSB0aGF0IHdheT8gQ29uc2lkZXIgbmVzdGVkLXN2bQo+IMKgIMKgIMKgIMKgc2Vw
YXJhdGUgdG8gbmVzdGVkLXZteC4gTmVzdGVkLXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCgoKSnVz
dCBhIHJhbmRvbSB0aG91Z2h0LCBidXQgSSBmaW5kIGl0IHF1aXRlIGFubm95aW5nIHRvIG5lZWQg
bGF0ZXggdG8KY29tcGlsZSB0aGUgZG9jdW1lbnRhdGlvbi4gSSB0aGluayBpdCB3aWxsIGJlIHdp
c2UgdG8gY3JlYXRlIGEgbmV3Ck1ha2VmaWxlIHRhcmdldCwgbGlrZSBtYW4tcGFnZXMgYW5kIGlu
c3RhbGwtbWFuLXBhZ2VzIHRvIGFsbG93IHRoZQp1c2VyIHRvIGJ1aWxkIGFuZCBpbnN0YWxsIG1h
biBwYWdlcyBvbmx5IChvciBkb24ndCBhYm9ydCBkb2NzIGJ1aWxkIGlmCmxhdGV4IGlzIG5vdCBm
b3VuZCkuIFBlcnNvbmFsbHkgSSBkb24ndCBoYXZlIGxhdGV4IG9uIG15IHNlcnZlciwgYW5kIEkK
ZG9uJ3Qgd2FudCB0byBpbnN0YWxsIGl0LCBidXQgSSB3b3VsZCBsaWtlIHRvIGhhdmUgdGhlIG1h
biBwYWdlcyB3aGVuCmJ1aWxkaW5nIFhlbiBmcm9tIHNvdXJjZS4KCj4gVG9vbHMsIG5lZWQgdG8g
ZGVjaWRlIGlmIHByZS0gb3IgcG9zdC00LjIgZmVhdHVyZToKPgo+IMKgIMKgIMKgKiBBdXRvY29u
ZiAoUm9nZXIgUGF1IE1vbmV0IHBvc3RlZCBhIHBhdGNoKQo+Cj4KPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:33:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:33:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3uT-0007vw-Fy; Wed, 25 Jan 2012 14:33:13 +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 1Rq3uR-0007vm-HD
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:33:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327501983!3594595!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2909 invoked from network); 25 Jan 2012 14:33:04 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:33:04 -0000
Received: by pbdx13 with SMTP id x13so14637115pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 06:33:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=w0DJ0or+raS5+wDfdvqdKvo3hlJ5oyeVcSz53IKk2XQ=;
	b=UK2QQ7kC+lBqegcIZTIFjbrrzeV+GySA43Z5MFhCXR3guPtrlLpni4O9+ETpTrSsdP
	CpBH8NXHWyhDckqAtajXWt3QcDrOOBXJ2mXiaPuEMkYByeD//0BP95D2UvnXnVf7sWDl
	0+QEF1w0lDAOcL2rYSlMvTShjSZiuuWTh0F1w=
MIME-Version: 1.0
Received: by 10.68.72.9 with SMTP id z9mr40820668pbu.124.1327501982694; Wed,
	25 Jan 2012 06:33:02 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Wed, 25 Jan 2012 06:33:02 -0800 (PST)
In-Reply-To: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 15:33:02 +0100
X-Google-Sender-Auth: CcXlI6DqISRLVjuW98DX2dIV0Og
Message-ID: <CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE5ld2x5
IHVwZGF0ZWQgbGlzdCBmb2xsb3dzLiBQbGVhc2Ugc2VuZCBtZSBjb3JyZWN0aW9ucyAoZXNwZWNp
YWxseQo+ICJkb25lIikuIEkndmUgc3RvcHBlZCBDQ2luZyBldmVyeW9uZSwgc2luY2UgSSBndWVz
cyBpdCBpcyBtb3N0bHkgc3BhbSB0bwo+IHRoZSBtYWpvcml0eS4KPgo+IGh5cGVydmlzb3IsIGJs
b2NrZXJzOgo+Cj4gwqAgwqAgwqAqIHJvdW5kLXVwIG9mIHRoZSBjbG9zaW5nIG9mIHRoZSBzZWN1
cml0eSBob2xlIGluIE1TSS1YCj4gwqAgwqAgwqAgwqBwYXNzdGhyb3VnaCAodW5pZm9ybWx5IC0g
aS5lLiBldmVuIGZvciBEb20wIC0gZGlzYWxsb3dpbmcgd3JpdGUKPiDCoCDCoCDCoCDCoGFjY2Vz
cyB0byBNU0ktWCB0YWJsZSBwYWdlcykuIChKYW4gQmV1bGljaCAtLSBtb3JlIGZpeGVzCj4gwqAg
wqAgwqAgwqByZXF1aXJlZCB0aGFuIGZpcnN0IHRob3VnaHQsIHBhdGNoZXMgcG9zdGVkKQo+IMKg
IMKgIMKgKiBkb21jdGxzIC8gc3lzY3RscyBzZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJh
bWV0ZXJzLCBsaWtlCj4gwqAgwqAgwqAgwqB0aGUgY3JlZGl0MSB0aW1lc2xpY2UgYW5kIHNjaGVk
dWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwKQo+IMKgIMKgIMKgKiBnZXQgdGhlIGludGVyZmFjZSBj
aGFuZ2VzIGZvciBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCj4gwqAgwqAgwqAg
wqBkdXN0ZWQgc28gdGhhdCA0LjIgaXMgYSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4gKFRp
bSBEZWVnYW4sCj4gwqAgwqAgwqAgwqBBbmRyZXMgTGFnYXItQ2F2aWxsYSBldCBhbCkKPiDCoCDC
oCDCoCDCoCDCoCDCoCDCoCogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNlZW1z
IGNsb3NlIHRvIGdvaW5nCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbi4KPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogc2hhcmluZyBwYXRjaGVzIHBvc3RlZAo+Cj4gdG9vbHMsIGJsb2NrZXJzOgo+
Cj4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8gZGVm
aW5lIGEgc3RhYmxlIEFQSQo+IMKgIMKgIMKgIMKgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFy
dCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgo+IMKgIMKgIMKgIMKgdGhpcyBh
cmU6Cj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGV2ZW50IGhhbmRsaW5nIChJYW4gSmFja3Nvbiwg
cG9zdGVkIHNldmVyYWwgcm91bmRzLAo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbmVhcmluZyBj
b21wbGV0aW9uPykKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogZHJvcCBsaWJ4bF9kZXZpY2VfbW9k
ZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2luZm8gb3IKPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkgKElhbiBDYW1wYmVsbCwgZmlyc3QgUkZDIHNl
bnQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGFkZCBsaWJ4bF9kZWZib29sIGFuZCBnZW5lcmFs
bHkgdHJ5IGFuZCBhcnJhbmdlIHRoYXQKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1lbXNldChm
b28sMCwuLi4pIHJlcXVlc3RzIHRoZSBkZWZhdWx0cyAoSWFuIENhbXBiZWxsLAo+IMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgZmlyc3QgUkZDIHNlbnQpCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIHRv
cG9sb2d5aW5mbyBkYXRhc3RydWN0dXJlIHNob3VsZCBiZSBhIGxpc3Qgb2YgdHVwbGVzLAo+IMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgbm90IGEgdHVwbGUgb2YgbGlzdHMuIChub2JvZHkgY3VycmVu
dGx5IGxvb2tpbmcgYXQgdGhpcywKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5vdCAxMDAlIHN1
cmUgdGhpcyBtYWtlcyBzZW5zZSwgY291bGQgcG9zc2libHkgZGVmZXIgYW5kCj4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqBjaGFuZ2UgYWZ0ZXIgNC4yIGluIGEgY29tcGF0aWJsZSB3YXkpCj4gwqAg
wqAgwqAqIHhsIHRvIHVzZSBqc29uIGZvciBtYWNoaW5lIHJlYWRhYmxlIG91dHB1dCBpbnN0ZWFk
IG9mIHNleHAgYnkKPiDCoCDCoCDCoCDCoGRlZmF1bHQgKElhbiBDYW1wYmVsbCB0byByZXZpc2l0
IGV4aXN0aW5nIHBhdGNoKQo+IMKgIMKgIMKgKiB4bCBzdXBwb3J0IGZvciB2Y3B1IHBpbm5pbmcg
KERhcmlvIEZhZ2dpb2xpKQo+IMKgIMKgIMKgKiB4bCBmZWF0dXJlIHBhcml0eSB3aXRoIHhlbmQg
d3J0IGRyaXZlciBkb21haW4gc3VwcG9ydCAoR2VvcmdlCj4gwqAgwqAgwqAgwqBEdW5sYXApCj4g
wqAgwqAgwqAqIEludGVncmF0ZSBxZW11K3NlYWJpb3MgdXBzdHJlYW0gaW50byB0aGUgYnVpbGQg
KHBhdGNoZXMKPiDCoCDCoCDCoCDCoHJlcG9zdGVkLCBwZW5kaW5nKS4gTm8gY2hhbmdlIGluIGRl
ZmF1bHQgcWVtdSBmb3IgNC4yLgo+IMKgIMKgIMKgKiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4
bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgo+IMKgIMKgIMKgIMKgdHJlZS4gTmVl
ZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPiDCoCDC
oCDCoCDCoHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPgo+IGh5cGVydmlzb3IsIG5pY2UgdG8g
aGF2ZToKPgo+IMKgIMKgIMKgKiBzb2xpZCBpbXBsZW1lbnRhdGlvbiBvZiBzaGFyaW5nL3BhZ2lu
Zy9tZW0tZXZlbnRzICh1c2luZyB3b3JrCj4gwqAgwqAgwqAgwqBxdWV1ZXMpIChUaW0gRGVlZ2Fu
LCBPbGFmIEhlcnJpbmcgZXQgYWwpCj4gwqAgwqAgwqAqIEEgbG9uZyBzdGFuZGluZyBpc3N1ZSBp
cyBhIGZ1bGx5IHN5bmNocm9uaXplZCBwMm0gKGxvY2tpbmcKPiDCoCDCoCDCoCDCoGxvb2t1cHMp
IChBbmRyZXMgTGFnYXItQ2F2aWxsYSkKPiDCoCDCoCDCoCogTlVNQSBpbXByb3ZlbWVudDogZG9t
YWluIGFmZmluaXR5IGNvbnNpc3RlbnQgd2l0aCBjcHVwb29sCj4gwqAgwqAgwqAgwqBtZW1iZXJz
aGlwIChEYXJpbyBGYWdnaW9saSwgSmV1cmdlbiBHcm9zcyAtLSBwYXRjaCBwb3N0ZWQpCj4KPiB0
b29scywgbmljZSB0byBoYXZlOgo+Cj4gwqAgwqAgwqAqIEhvdHBsdWcgc2NyaXB0IHN0dWZmIC0t
IGludGVybmFsIHRvIGxpYnhsIChJIHRoaW5rLCB0aGVyZWZvcmUgSQo+IMKgIMKgIMKgIMKgZGlk
bid0IHB1dCB0aGlzIHVuZGVyIHN0YWJsZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhh
dmUKPiDCoCDCoCDCoCDCoGZvciA0LjI/IFJvZ2VyIFBhdSBNb25ldCB3YXMgbG9va2luZyBhdCB0
aGlzIGJ1dCBpdHMgbG9va2luZwo+IMKgIMKgIMKgIMKgbGlrZSBhIGJpZyBjYW4tby13b3Jtcy4g
KGRpc2N1c3Npb24gb24tZ29pbmcpCj4gwqAgwqAgwqAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0t
IGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIKPiDCoCDCoCDCoCDCoFBhdSBN
b25ldCkKPiDCoCDCoCDCoCogbGlieWFqbCB2MiBzdXBwb3J0IChwYXRjaCBwb3N0ZWQgYnkgUm9n
ZXIgUGF1IE1vbmV0LCBibG9ja2VkIG9uCj4gwqAgwqAgwqAgwqBhdXRvY29uZj8pCj4gwqAgwqAg
wqAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVycmluZykK
PiDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkg
UGVyYXJkKQo+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9y
ZSAoQW50aG9ueSBQZXJhcmQpCj4gwqAgwqAgwqAqIE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3Vy
cmVudGx5IHNob3VsZCBiZSBtYXJrZWQKPiDCoCDCoCDCoCDCoGV4cGVyaW1lbnRhbCxsaWtlbHkg
dG8gcmVsZWFzZSB0aGF0IHdheT8gQ29uc2lkZXIgbmVzdGVkLXN2bQo+IMKgIMKgIMKgIMKgc2Vw
YXJhdGUgdG8gbmVzdGVkLXZteC4gTmVzdGVkLXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCgoKSnVz
dCBhIHJhbmRvbSB0aG91Z2h0LCBidXQgSSBmaW5kIGl0IHF1aXRlIGFubm95aW5nIHRvIG5lZWQg
bGF0ZXggdG8KY29tcGlsZSB0aGUgZG9jdW1lbnRhdGlvbi4gSSB0aGluayBpdCB3aWxsIGJlIHdp
c2UgdG8gY3JlYXRlIGEgbmV3Ck1ha2VmaWxlIHRhcmdldCwgbGlrZSBtYW4tcGFnZXMgYW5kIGlu
c3RhbGwtbWFuLXBhZ2VzIHRvIGFsbG93IHRoZQp1c2VyIHRvIGJ1aWxkIGFuZCBpbnN0YWxsIG1h
biBwYWdlcyBvbmx5IChvciBkb24ndCBhYm9ydCBkb2NzIGJ1aWxkIGlmCmxhdGV4IGlzIG5vdCBm
b3VuZCkuIFBlcnNvbmFsbHkgSSBkb24ndCBoYXZlIGxhdGV4IG9uIG15IHNlcnZlciwgYW5kIEkK
ZG9uJ3Qgd2FudCB0byBpbnN0YWxsIGl0LCBidXQgSSB3b3VsZCBsaWtlIHRvIGhhdmUgdGhlIG1h
biBwYWdlcyB3aGVuCmJ1aWxkaW5nIFhlbiBmcm9tIHNvdXJjZS4KCj4gVG9vbHMsIG5lZWQgdG8g
ZGVjaWRlIGlmIHByZS0gb3IgcG9zdC00LjIgZmVhdHVyZToKPgo+IMKgIMKgIMKgKiBBdXRvY29u
ZiAoUm9nZXIgUGF1IE1vbmV0IHBvc3RlZCBhIHBhdGNoKQo+Cj4KPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFhlbi1kZXZlbCBtYWlsaW5nIGxpc3QK
PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+IGh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:35:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3wP-000827-8e; Wed, 25 Jan 2012 14:35: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 1Rq3wO-00081q-AJ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:35:12 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327502104!2122789!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24931 invoked from network); 25 Jan 2012 14:35:04 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 14:35:04 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75015376; Wed, 25 Jan 2012 15:35:04 +0100
Message-ID: <1327502102.2723.15.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:35:02 +0100
In-Reply-To: <1327500920.2723.11.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv3 1 of 2] libxl: extend pCPUs specification for
	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1683186530190811548=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1683186530190811548==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-CGSy+IITgneX3cfd+GRi"


--=-CGSy+IITgneX3cfd+GRi
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Allow for "^<cpuid>" syntax while specifying the pCPUs list
during a vcpu-pin. This enables doing the following:

 xl vcpu-pin 1 1 0-4,^2

and achieving:

 xl vcpu-list
 Name                                ID  VCPU   CPU State   Time(s) CPU Aff=
inity
 ...
 Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
 ...

Negative ranges are also supported, such as "0-4,^1-2" to
mean "0,3-4"

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r a2a8089b1ffb tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Tue Jan 24 16:46:17 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Wed Jan 25 11:40:22 2012 +0000
@@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
+#define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
+                                             if (libxl_cpumap_test(&(m), v=
))
=20
 int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
=20
diff -r a2a8089b1ffb tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 24 16:46:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 11:40:22 2012 +0000
@@ -3503,13 +3503,72 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb, *saveptr =3D NULL;
+    int i, rc =3D 0, rmcpu;
+
+    if (!strcmp(cpu, "all")) {
+        memset(cpumap->map, -1, cpumap->size);
+        return 0;
+    }
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+        return ENOMEM;
+    }
+
+    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
+         toka =3D strtok_r(NULL, ",", &saveptr)) {
+        rmcpu =3D 0;
+        if (*toka =3D=3D '^') {
+            /* This (These) Cpu(s) will be removed from the map */
+            toka++;
+            rmcpu =3D 1;
+        }
+        /* Extract a valid (range of) cpu(s) */
+        cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
+        if (endptr =3D=3D toka) {
+            fprintf(stderr, "Error: Invalid argument.\n");
+            rc =3D EINVAL;
+            goto vcpp_out;
+        }
+        if (*endptr =3D=3D '-') {
+            tokb =3D endptr + 1;
+            cpuidb =3D strtoul(tokb, &endptr, 10);
+            if (endptr =3D=3D tokb || cpuida > cpuidb) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                rc =3D EINVAL;
+                goto vcpp_out;
+            }
+        }
+        while (cpuida <=3D cpuidb) {
+            rmcpu =3D=3D 0 ? libxl_cpumap_set(cpumap, cpuida) :
+                         libxl_cpumap_set(&exclude_cpumap, cpuida);
+            cpuida++;
+        }
+    }
+
+    /* Clear all the cpus from the removal list */
+    libxl_for_each_set_cpu(i, exclude_cpumap) {
+        libxl_cpumap_reset(cpumap, i);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return rc;
+}
+
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_cpumap cpumap;
=20
-    uint32_t vcpuid, cpuida, cpuidb;
-    char *endptr, *toka, *tokb;
+    uint32_t vcpuid;
+    char *endptr;
     int i, nb_vcpu;
=20
     vcpuid =3D strtoul(vcpu, &endptr, 10);
@@ -3526,32 +3585,9 @@ static void vcpupin(const char *d, const
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
-    if (strcmp(cpu, "all")) {
-        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
-            cpuida =3D strtoul(toka, &endptr, 10);
-            if (toka =3D=3D endptr) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                goto vcpupin_out1;
-            }
-            if (*endptr =3D=3D '-') {
-                tokb =3D endptr + 1;
-                cpuidb =3D strtoul(tokb, &endptr, 10);
-                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
-                    fprintf(stderr, "Error: Invalid argument.\n");
-                    goto vcpupin_out1;
-                }
-                while (cpuida <=3D cpuidb) {
-                    libxl_cpumap_set(&cpumap, cpuida);
-                    ++cpuida;
-                }
-            } else {
-                libxl_cpumap_set(&cpumap, cpuida);
-            }
-        }
-    }
-    else {
-        memset(cpumap.map, -1, cpumap.size);
-    }
+
+    if (vcpupin_parse(cpu, &cpumap))
+        goto vcpupin_out1;
=20
     if (vcpuid !=3D -1) {
         if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) =3D=3D -1)=
 {

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-CGSy+IITgneX3cfd+GRi
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)

iEYEABECAAYFAk8gExYACgkQk4XaBE3IOsSh3QCdG2qBF2LSzWVy9DjzSxkdZw9x
FGYAoK3vzlfeOpecoFRVZvxYtIt9jafL
=PcYJ
-----END PGP SIGNATURE-----

--=-CGSy+IITgneX3cfd+GRi--



--===============1683186530190811548==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1683186530190811548==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:35:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3wP-000827-8e; Wed, 25 Jan 2012 14:35: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 1Rq3wO-00081q-AJ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:35:12 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327502104!2122789!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24931 invoked from network); 25 Jan 2012 14:35:04 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-9.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 14:35:04 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75015376; Wed, 25 Jan 2012 15:35:04 +0100
Message-ID: <1327502102.2723.15.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:35:02 +0100
In-Reply-To: <1327500920.2723.11.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv3 1 of 2] libxl: extend pCPUs specification for
	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1683186530190811548=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1683186530190811548==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-CGSy+IITgneX3cfd+GRi"


--=-CGSy+IITgneX3cfd+GRi
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Allow for "^<cpuid>" syntax while specifying the pCPUs list
during a vcpu-pin. This enables doing the following:

 xl vcpu-pin 1 1 0-4,^2

and achieving:

 xl vcpu-list
 Name                                ID  VCPU   CPU State   Time(s) CPU Aff=
inity
 ...
 Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
 ...

Negative ranges are also supported, such as "0-4,^1-2" to
mean "0,3-4"

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r a2a8089b1ffb tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Tue Jan 24 16:46:17 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Wed Jan 25 11:40:22 2012 +0000
@@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
+#define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
+                                             if (libxl_cpumap_test(&(m), v=
))
=20
 int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
=20
diff -r a2a8089b1ffb tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 24 16:46:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 11:40:22 2012 +0000
@@ -3503,13 +3503,72 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb, *saveptr =3D NULL;
+    int i, rc =3D 0, rmcpu;
+
+    if (!strcmp(cpu, "all")) {
+        memset(cpumap->map, -1, cpumap->size);
+        return 0;
+    }
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+        return ENOMEM;
+    }
+
+    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
+         toka =3D strtok_r(NULL, ",", &saveptr)) {
+        rmcpu =3D 0;
+        if (*toka =3D=3D '^') {
+            /* This (These) Cpu(s) will be removed from the map */
+            toka++;
+            rmcpu =3D 1;
+        }
+        /* Extract a valid (range of) cpu(s) */
+        cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
+        if (endptr =3D=3D toka) {
+            fprintf(stderr, "Error: Invalid argument.\n");
+            rc =3D EINVAL;
+            goto vcpp_out;
+        }
+        if (*endptr =3D=3D '-') {
+            tokb =3D endptr + 1;
+            cpuidb =3D strtoul(tokb, &endptr, 10);
+            if (endptr =3D=3D tokb || cpuida > cpuidb) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                rc =3D EINVAL;
+                goto vcpp_out;
+            }
+        }
+        while (cpuida <=3D cpuidb) {
+            rmcpu =3D=3D 0 ? libxl_cpumap_set(cpumap, cpuida) :
+                         libxl_cpumap_set(&exclude_cpumap, cpuida);
+            cpuida++;
+        }
+    }
+
+    /* Clear all the cpus from the removal list */
+    libxl_for_each_set_cpu(i, exclude_cpumap) {
+        libxl_cpumap_reset(cpumap, i);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return rc;
+}
+
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_cpumap cpumap;
=20
-    uint32_t vcpuid, cpuida, cpuidb;
-    char *endptr, *toka, *tokb;
+    uint32_t vcpuid;
+    char *endptr;
     int i, nb_vcpu;
=20
     vcpuid =3D strtoul(vcpu, &endptr, 10);
@@ -3526,32 +3585,9 @@ static void vcpupin(const char *d, const
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
-    if (strcmp(cpu, "all")) {
-        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
-            cpuida =3D strtoul(toka, &endptr, 10);
-            if (toka =3D=3D endptr) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                goto vcpupin_out1;
-            }
-            if (*endptr =3D=3D '-') {
-                tokb =3D endptr + 1;
-                cpuidb =3D strtoul(tokb, &endptr, 10);
-                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
-                    fprintf(stderr, "Error: Invalid argument.\n");
-                    goto vcpupin_out1;
-                }
-                while (cpuida <=3D cpuidb) {
-                    libxl_cpumap_set(&cpumap, cpuida);
-                    ++cpuida;
-                }
-            } else {
-                libxl_cpumap_set(&cpumap, cpuida);
-            }
-        }
-    }
-    else {
-        memset(cpumap.map, -1, cpumap.size);
-    }
+
+    if (vcpupin_parse(cpu, &cpumap))
+        goto vcpupin_out1;
=20
     if (vcpuid !=3D -1) {
         if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) =3D=3D -1)=
 {

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-CGSy+IITgneX3cfd+GRi
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)

iEYEABECAAYFAk8gExYACgkQk4XaBE3IOsSh3QCdG2qBF2LSzWVy9DjzSxkdZw9x
FGYAoK3vzlfeOpecoFRVZvxYtIt9jafL
=PcYJ
-----END PGP SIGNATURE-----

--=-CGSy+IITgneX3cfd+GRi--



--===============1683186530190811548==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1683186530190811548==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:36:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3xZ-00086h-Ol; Wed, 25 Jan 2012 14:36:25 +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 1Rq3xY-00086L-1E
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:36:24 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327502174!12340534!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9608 invoked from network); 25 Jan 2012 14:36:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 14:36:15 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75015413; Wed, 25 Jan 2012 15:36:12 +0100
Message-ID: <1327502171.2723.17.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:36:11 +0100
In-Reply-To: <1327500920.2723.11.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv3 1 of 2] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============1220177572573469436=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1220177572573469436==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-zrugTtglDLYN0Fm/cuFQ"


--=-zrugTtglDLYN0Fm/cuFQ
Content-Type: multipart/mixed; boundary="=-oqQVQy5diNUns+vXee/K"


--=-oqQVQy5diNUns+vXee/K
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Enable CPU affinity specification in a VM's config file with the
exact syntax `xl vcpu-pin' provides.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r e4fd5305381e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Jan 25 14:08:21 2012 +0000
@@ -2663,6 +2663,21 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
     return 0;
 }
=20
+int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
+                               unsigned int max_vcpus, libxl_cpumap *cpuma=
p)
+{
+    int i, rc =3D 0;
+
+    for (i =3D 0; i < max_vcpus; i++) {
+        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
+            LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
+                       "failed to set affinity for %d", i);
+            rc =3D ERROR_FAIL;
+        }
+    }
+    return rc;
+}
+
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpu=
map)
 {
     GC_INIT(ctx);
diff -r e4fd5305381e tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Jan 25 14:08:21 2012 +0000
@@ -560,6 +560,8 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
                                        int *nb_vcpu, int *nrcpus);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid=
,
                            libxl_cpumap *cpumap);
+int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
+                               unsigned int max_vcpus, libxl_cpumap *cpuma=
p);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpu=
map);
=20
 int libxl_get_sched_id(libxl_ctx *ctx);
diff -r e4fd5305381e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 25 14:08:21 2012 +0000
@@ -71,6 +71,9 @@ int libxl_init_build_info(libxl_ctx *ctx
     memset(b_info, '\0', sizeof(*b_info));
     b_info->max_vcpus =3D 1;
     b_info->cur_vcpus =3D 1;
+    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
+        return ERROR_NOMEM;
+    libxl_cpumap_set_any(&b_info->cpumap);
     b_info->max_memkb =3D 32 * 1024;
     b_info->target_memkb =3D b_info->max_memkb;
     b_info->disable_migrate =3D 0;
diff -r e4fd5305381e tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Jan 25 14:08:21 2012 +0000
@@ -65,6 +65,7 @@ int libxl__build_pre(libxl__gc *gc, uint
     libxl_ctx *ctx =3D libxl__gc_owner(gc);
     int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
+    libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap)=
;
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM=
_CONSTANT);
     if (info->type =3D=3D LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
diff -r e4fd5305381e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 25 14:08:21 2012 +0000
@@ -162,6 +162,7 @@ libxl_domain_create_info =3D Struct("domai
 libxl_domain_build_info =3D Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
+    ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
diff -r e4fd5305381e tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Wed Jan 25 14:08:21 2012 +0000
@@ -70,6 +70,18 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
+{
+    memset(cpumap->map, -1, cpumap->size);
+}
+static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
+{
+    memset(cpumap->map, 0, cpumap->size);
+}
+static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
+{
+    return cpu >=3D 0 && cpu < (cpumap->size * 8);
+}
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
 #define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
                                              if (libxl_cpumap_test(&(m), v=
))
diff -r e4fd5305381e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 14:08:21 2012 +0000
@@ -569,6 +569,65 @@ static void split_string_into_string_lis
     free(s);
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb, *saveptr =3D NULL;
+    int i, rc =3D 0, rmcpu;
+
+    if (!strcmp(cpu, "all")) {
+        libxl_cpumap_set_any(cpumap);
+        return 0;
+    }
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+        return ENOMEM;
+    }
+
+    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
+         toka =3D strtok_r(NULL, ",", &saveptr)) {
+        rmcpu =3D 0;
+        if (*toka =3D=3D '^') {
+            /* This (These) Cpu(s) will be removed from the map */
+            toka++;
+            rmcpu =3D 1;
+        }
+        /* Extract a valid (range of) cpu(s) */
+        cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
+        if (endptr =3D=3D toka) {
+            fprintf(stderr, "Error: Invalid argument.\n");
+            rc =3D EINVAL;
+            goto vcpp_out;
+        }
+        if (*endptr =3D=3D '-') {
+            tokb =3D endptr + 1;
+            cpuidb =3D strtoul(tokb, &endptr, 10);
+            if (endptr =3D=3D tokb || cpuida > cpuidb) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                rc =3D EINVAL;
+                goto vcpp_out;
+            }
+        }
+        while (cpuida <=3D cpuidb) {
+            rmcpu =3D=3D 0 ? libxl_cpumap_set(cpumap, cpuida) :
+                         libxl_cpumap_set(&exclude_cpumap, cpuida);
+            cpuida++;
+        }
+    }
+
+    /* Clear all the cpus from the removal list */
+    libxl_for_each_set_cpu(i, exclude_cpumap) {
+        libxl_cpumap_reset(cpumap, i);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return rc;
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -578,7 +637,7 @@ static void parse_config_data(const char
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int e;
@@ -661,6 +720,29 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus =3D l;
=20
+    if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
+        int i, n_cpus =3D 0;
+
+        libxl_cpumap_set_none(&b_info->cpumap);
+        while ((buf =3D xlu_cfg_get_listitem(cpus, n_cpus)) !=3D NULL) {
+            i =3D atoi(buf);
+            if (!libxl_cpumap_cpu_valid(&b_info->cpumap, i)) {
+                fprintf(stderr, "cpu %d illegal\n", i);
+                exit(1);
+            }
+            libxl_cpumap_set(&b_info->cpumap, i);
+            n_cpus++;
+        }
+    }
+    else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
+        char *buf2 =3D strdup(buf);
+
+        libxl_cpumap_set_none(&b_info->cpumap);
+        if (vcpupin_parse(buf2, &b_info->cpumap))
+            exit(1);
+        free(buf2);
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb =3D l * 1024;
         b_info->target_memkb =3D b_info->max_memkb;
@@ -3503,65 +3585,6 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
-static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
-{
-    libxl_cpumap exclude_cpumap;
-    uint32_t cpuida, cpuidb;
-    char *endptr, *toka, *tokb, *saveptr =3D NULL;
-    int i, rc =3D 0, rmcpu;
-
-    if (!strcmp(cpu, "all")) {
-        memset(cpumap->map, -1, cpumap->size);
-        return 0;
-    }
-
-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
-        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
-        return ENOMEM;
-    }
-
-    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
-         toka =3D strtok_r(NULL, ",", &saveptr)) {
-        rmcpu =3D 0;
-        if (*toka =3D=3D '^') {
-            /* This (These) Cpu(s) will be removed from the map */
-            toka++;
-            rmcpu =3D 1;
-        }
-        /* Extract a valid (range of) cpu(s) */
-        cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
-        if (endptr =3D=3D toka) {
-            fprintf(stderr, "Error: Invalid argument.\n");
-            rc =3D EINVAL;
-            goto vcpp_out;
-        }
-        if (*endptr =3D=3D '-') {
-            tokb =3D endptr + 1;
-            cpuidb =3D strtoul(tokb, &endptr, 10);
-            if (endptr =3D=3D tokb || cpuida > cpuidb) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                rc =3D EINVAL;
-                goto vcpp_out;
-            }
-        }
-        while (cpuida <=3D cpuidb) {
-            rmcpu =3D=3D 0 ? libxl_cpumap_set(cpumap, cpuida) :
-                         libxl_cpumap_set(&exclude_cpumap, cpuida);
-            cpuida++;
-        }
-    }
-
-    /* Clear all the cpus from the removal list */
-    libxl_for_each_set_cpu(i, exclude_cpumap) {
-        libxl_cpumap_reset(cpumap, i);
-    }
-
-vcpp_out:
-    libxl_cpumap_dispose(&exclude_cpumap);
-
-    return rc;
-}
-
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-oqQVQy5diNUns+vXee/K
Content-Disposition: attachment; filename="support-cpus-par-in-config-file.patch"
Content-Type: text/x-patch; name="support-cpus-par-in-config-file.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGU0ZmQ1MzA1MzgxZTYzYWY5NjhmYmEwN2U1
YjQ5ZGQzMjFkMDg0ZGMNCmxpYnhsOiBhbGxvdyBmb3Igc3BlY2lmeWluZyB0aGUgQ1BVIGFmZmlu
aXR5IGluIHRoZSBjb25maWcgZmlsZS4NCg0KRW5hYmxlIENQVSBhZmZpbml0eSBzcGVjaWZpY2F0
aW9uIGluIGEgVk0ncyBjb25maWcgZmlsZSB3aXRoIHRoZQ0KZXhhY3Qgc3ludGF4IGB4bCB2Y3B1
LXBpbicgcHJvdmlkZXMuDQoNClNpZ25lZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5m
YWdnaW9saUBjaXRyaXguY29tPg0KDQpkaWZmIC1yIGU0ZmQ1MzA1MzgxZSB0b29scy9saWJ4bC9s
aWJ4bC5jDQotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCVdlZCBKYW4gMjUgMTE6NDA6MjMgMjAx
MiArMDAwMA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYwlXZWQgSmFuIDI1IDE0OjA4OjIxIDIw
MTIgKzAwMDANCkBAIC0yNjYzLDYgKzI2NjMsMjEgQEAgaW50IGxpYnhsX3NldF92Y3B1YWZmaW5p
dHkobGlieGxfY3R4ICpjdA0KICAgICByZXR1cm4gMDsNCiB9DQogDQoraW50IGxpYnhsX3NldF92
Y3B1YWZmaW5pdHlfYWxsKGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IG1heF92Y3B1cywgbGlieGxfY3B1
bWFwICpjcHVtYXApDQorew0KKyAgICBpbnQgaSwgcmMgPSAwOw0KKw0KKyAgICBmb3IgKGkgPSAw
OyBpIDwgbWF4X3ZjcHVzOyBpKyspIHsNCisgICAgICAgIGlmIChsaWJ4bF9zZXRfdmNwdWFmZmlu
aXR5KGN0eCwgZG9taWQsIGksIGNwdW1hcCkpIHsNCisgICAgICAgICAgICBMSUJYTF9fTE9HKGN0
eCwgTElCWExfX0xPR19XQVJOSU5HLA0KKyAgICAgICAgICAgICAgICAgICAgICAgImZhaWxlZCB0
byBzZXQgYWZmaW5pdHkgZm9yICVkIiwgaSk7DQorICAgICAgICAgICAgcmMgPSBFUlJPUl9GQUlM
Ow0KKyAgICAgICAgfQ0KKyAgICB9DQorICAgIHJldHVybiByYzsNCit9DQorDQogaW50IGxpYnhs
X3NldF92Y3B1b25saW5lKGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgbGlieGxfY3B1
bWFwICpjcHVtYXApDQogew0KICAgICBHQ19JTklUKGN0eCk7DQpkaWZmIC1yIGU0ZmQ1MzA1Mzgx
ZSB0b29scy9saWJ4bC9saWJ4bC5oDQotLS0gYS90b29scy9saWJ4bC9saWJ4bC5oCVdlZCBKYW4g
MjUgMTE6NDA6MjMgMjAxMiArMDAwMA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGwuaAlXZWQgSmFu
IDI1IDE0OjA4OjIxIDIwMTIgKzAwMDANCkBAIC01NjAsNiArNTYwLDggQEAgbGlieGxfdmNwdWlu
Zm8gKmxpYnhsX2xpc3RfdmNwdShsaWJ4bF9jdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGludCAqbmJfdmNwdSwgaW50ICpucmNwdXMpOw0KIGludCBsaWJ4bF9zZXRf
dmNwdWFmZmluaXR5KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgdWludDMyX3QgdmNw
dWlkLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2NwdW1hcCAqY3B1bWFwKTsN
CitpbnQgbGlieGxfc2V0X3ZjcHVhZmZpbml0eV9hbGwobGlieGxfY3R4ICpjdHgsIHVpbnQzMl90
IGRvbWlkLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgbWF4
X3ZjcHVzLCBsaWJ4bF9jcHVtYXAgKmNwdW1hcCk7DQogaW50IGxpYnhsX3NldF92Y3B1b25saW5l
KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgbGlieGxfY3B1bWFwICpjcHVtYXApOw0K
IA0KIGludCBsaWJ4bF9nZXRfc2NoZWRfaWQobGlieGxfY3R4ICpjdHgpOw0KZGlmZiAtciBlNGZk
NTMwNTM4MWUgdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL2xp
YnhsX2NyZWF0ZS5jCVdlZCBKYW4gMjUgMTE6NDA6MjMgMjAxMiArMDAwMA0KKysrIGIvdG9vbHMv
bGlieGwvbGlieGxfY3JlYXRlLmMJV2VkIEphbiAyNSAxNDowODoyMSAyMDEyICswMDAwDQpAQCAt
NzEsNiArNzEsOSBAQCBpbnQgbGlieGxfaW5pdF9idWlsZF9pbmZvKGxpYnhsX2N0eCAqY3R4DQog
ICAgIG1lbXNldChiX2luZm8sICdcMCcsIHNpemVvZigqYl9pbmZvKSk7DQogICAgIGJfaW5mby0+
bWF4X3ZjcHVzID0gMTsNCiAgICAgYl9pbmZvLT5jdXJfdmNwdXMgPSAxOw0KKyAgICBpZiAobGli
eGxfY3B1bWFwX2FsbG9jKGN0eCwgJmJfaW5mby0+Y3B1bWFwKSkNCisgICAgICAgIHJldHVybiBF
UlJPUl9OT01FTTsNCisgICAgbGlieGxfY3B1bWFwX3NldF9hbnkoJmJfaW5mby0+Y3B1bWFwKTsN
CiAgICAgYl9pbmZvLT5tYXhfbWVta2IgPSAzMiAqIDEwMjQ7DQogICAgIGJfaW5mby0+dGFyZ2V0
X21lbWtiID0gYl9pbmZvLT5tYXhfbWVta2I7DQogICAgIGJfaW5mby0+ZGlzYWJsZV9taWdyYXRl
ID0gMDsNCmRpZmYgLXIgZTRmZDUzMDUzODFlIHRvb2xzL2xpYnhsL2xpYnhsX2RvbS5jDQotLS0g
YS90b29scy9saWJ4bC9saWJ4bF9kb20uYwlXZWQgSmFuIDI1IDExOjQwOjIzIDIwMTIgKzAwMDAN
CisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5jCVdlZCBKYW4gMjUgMTQ6MDg6MjEgMjAxMiAr
MDAwMA0KQEAgLTY1LDYgKzY1LDcgQEAgaW50IGxpYnhsX19idWlsZF9wcmUobGlieGxfX2djICpn
YywgdWludA0KICAgICBsaWJ4bF9jdHggKmN0eCA9IGxpYnhsX19nY19vd25lcihnYyk7DQogICAg
IGludCB0c2NfbW9kZTsNCiAgICAgeGNfZG9tYWluX21heF92Y3B1cyhjdHgtPnhjaCwgZG9taWQs
IGluZm8tPm1heF92Y3B1cyk7DQorICAgIGxpYnhsX3NldF92Y3B1YWZmaW5pdHlfYWxsKGN0eCwg
ZG9taWQsIGluZm8tPm1heF92Y3B1cywgJmluZm8tPmNwdW1hcCk7DQogICAgIHhjX2RvbWFpbl9z
ZXRtYXhtZW0oY3R4LT54Y2gsIGRvbWlkLCBpbmZvLT50YXJnZXRfbWVta2IgKyBMSUJYTF9NQVhN
RU1fQ09OU1RBTlQpOw0KICAgICBpZiAoaW5mby0+dHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9Q
VikNCiAgICAgICAgIHhjX2RvbWFpbl9zZXRfbWVtbWFwX2xpbWl0KGN0eC0+eGNoLCBkb21pZCwN
CmRpZmYgLXIgZTRmZDUzMDUzODFlIHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbA0KLS0tIGEv
dG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVdlZCBKYW4gMjUgMTE6NDA6MjMgMjAxMiArMDAw
MA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVdlZCBKYW4gMjUgMTQ6MDg6MjEg
MjAxMiArMDAwMA0KQEAgLTE2Miw2ICsxNjIsNyBAQCBsaWJ4bF9kb21haW5fY3JlYXRlX2luZm8g
PSBTdHJ1Y3QoImRvbWFpDQogbGlieGxfZG9tYWluX2J1aWxkX2luZm8gPSBTdHJ1Y3QoImRvbWFp
bl9idWlsZF9pbmZvIixbDQogICAgICgibWF4X3ZjcHVzIiwgICAgICAgaW50ZWdlciksDQogICAg
ICgiY3VyX3ZjcHVzIiwgICAgICAgaW50ZWdlciksDQorICAgICgiY3B1bWFwIiwgICAgICAgICAg
bGlieGxfY3B1bWFwKSwNCiAgICAgKCJ0c2NfbW9kZSIsICAgICAgICBsaWJ4bF90c2NfbW9kZSks
DQogICAgICgibWF4X21lbWtiIiwgICAgICAgdWludDMyKSwNCiAgICAgKCJ0YXJnZXRfbWVta2Ii
LCAgICB1aW50MzIpLA0KZGlmZiAtciBlNGZkNTMwNTM4MWUgdG9vbHMvbGlieGwvbGlieGxfdXRp
bHMuaA0KLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfdXRpbHMuaAlXZWQgSmFuIDI1IDExOjQwOjIz
IDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgJV2VkIEphbiAyNSAx
NDowODoyMSAyMDEyICswMDAwDQpAQCAtNzAsNiArNzAsMTggQEAgaW50IGxpYnhsX2NwdW1hcF9h
bGxvYyhsaWJ4bF9jdHggKmN0eCwgbA0KIGludCBsaWJ4bF9jcHVtYXBfdGVzdChsaWJ4bF9jcHVt
YXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4bF9jcHVtYXBfc2V0KGxpYnhsX2NwdW1h
cCAqY3B1bWFwLCBpbnQgY3B1KTsNCiB2b2lkIGxpYnhsX2NwdW1hcF9yZXNldChsaWJ4bF9jcHVt
YXAgKmNwdW1hcCwgaW50IGNwdSk7DQorc3RhdGljIGlubGluZSB2b2lkIGxpYnhsX2NwdW1hcF9z
ZXRfYW55KGxpYnhsX2NwdW1hcCAqY3B1bWFwKQ0KK3sNCisgICAgbWVtc2V0KGNwdW1hcC0+bWFw
LCAtMSwgY3B1bWFwLT5zaXplKTsNCit9DQorc3RhdGljIGlubGluZSB2b2lkIGxpYnhsX2NwdW1h
cF9zZXRfbm9uZShsaWJ4bF9jcHVtYXAgKmNwdW1hcCkNCit7DQorICAgIG1lbXNldChjcHVtYXAt
Pm1hcCwgMCwgY3B1bWFwLT5zaXplKTsNCit9DQorc3RhdGljIGlubGluZSBpbnQgbGlieGxfY3B1
bWFwX2NwdV92YWxpZChsaWJ4bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSkNCit7DQorICAgIHJl
dHVybiBjcHUgPj0gMCAmJiBjcHUgPCAoY3B1bWFwLT5zaXplICogOCk7DQorfQ0KICNkZWZpbmUg
bGlieGxfZm9yX2VhY2hfY3B1KHZhciwgbWFwKSBmb3IgKHZhciA9IDA7IHZhciA8IChtYXApLnNp
emUgKiA4OyB2YXIrKykNCiAjZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUodiwgbSkgZm9y
ICh2ID0gMDsgdiA8IChtKS5zaXplICogODsgdisrKSBcDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaWYgKGxpYnhsX2NwdW1hcF90ZXN0KCYobSksIHYpKQ0K
ZGlmZiAtciBlNGZkNTMwNTM4MWUgdG9vbHMvbGlieGwveGxfY21kaW1wbC5jDQotLS0gYS90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMJV2VkIEphbiAyNSAxMTo0MDoyMyAyMDEyICswMDAwDQorKysg
Yi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMJV2VkIEphbiAyNSAxNDowODoyMSAyMDEyICswMDAw
DQpAQCAtNTY5LDYgKzU2OSw2NSBAQCBzdGF0aWMgdm9pZCBzcGxpdF9zdHJpbmdfaW50b19zdHJp
bmdfbGlzDQogICAgIGZyZWUocyk7DQogfQ0KIA0KK3N0YXRpYyBpbnQgdmNwdXBpbl9wYXJzZShj
aGFyICpjcHUsIGxpYnhsX2NwdW1hcCAqY3B1bWFwKQ0KK3sNCisgICAgbGlieGxfY3B1bWFwIGV4
Y2x1ZGVfY3B1bWFwOw0KKyAgICB1aW50MzJfdCBjcHVpZGEsIGNwdWlkYjsNCisgICAgY2hhciAq
ZW5kcHRyLCAqdG9rYSwgKnRva2IsICpzYXZlcHRyID0gTlVMTDsNCisgICAgaW50IGksIHJjID0g
MCwgcm1jcHU7DQorDQorICAgIGlmICghc3RyY21wKGNwdSwgImFsbCIpKSB7DQorICAgICAgICBs
aWJ4bF9jcHVtYXBfc2V0X2FueShjcHVtYXApOw0KKyAgICAgICAgcmV0dXJuIDA7DQorICAgIH0N
CisNCisgICAgaWYgKGxpYnhsX2NwdW1hcF9hbGxvYyhjdHgsICZleGNsdWRlX2NwdW1hcCkpIHsN
CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEZhaWxlZCB0byBhbGxvY2F0ZSBjcHVt
YXAuXG4iKTsNCisgICAgICAgIHJldHVybiBFTk9NRU07DQorICAgIH0NCisNCisgICAgZm9yICh0
b2thID0gc3RydG9rX3IoY3B1LCAiLCIsICZzYXZlcHRyKTsgdG9rYTsNCisgICAgICAgICB0b2th
ID0gc3RydG9rX3IoTlVMTCwgIiwiLCAmc2F2ZXB0cikpIHsNCisgICAgICAgIHJtY3B1ID0gMDsN
CisgICAgICAgIGlmICgqdG9rYSA9PSAnXicpIHsNCisgICAgICAgICAgICAvKiBUaGlzIChUaGVz
ZSkgQ3B1KHMpIHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSBtYXAgKi8NCisgICAgICAgICAgICB0
b2thKys7DQorICAgICAgICAgICAgcm1jcHUgPSAxOw0KKyAgICAgICAgfQ0KKyAgICAgICAgLyog
RXh0cmFjdCBhIHZhbGlkIChyYW5nZSBvZikgY3B1KHMpICovDQorICAgICAgICBjcHVpZGEgPSBj
cHVpZGIgPSBzdHJ0b3VsKHRva2EsICZlbmRwdHIsIDEwKTsNCisgICAgICAgIGlmIChlbmRwdHIg
PT0gdG9rYSkgew0KKyAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFsaWQg
YXJndW1lbnQuXG4iKTsNCisgICAgICAgICAgICByYyA9IEVJTlZBTDsNCisgICAgICAgICAgICBn
b3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgfQ0KKyAgICAgICAgaWYgKCplbmRwdHIgPT0gJy0nKSB7
DQorICAgICAgICAgICAgdG9rYiA9IGVuZHB0ciArIDE7DQorICAgICAgICAgICAgY3B1aWRiID0g
c3RydG91bCh0b2tiLCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAgaWYgKGVuZHB0ciA9PSB0
b2tiIHx8IGNwdWlkYSA+IGNwdWlkYikgew0KKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVy
ciwgIkVycm9yOiBJbnZhbGlkIGFyZ3VtZW50LlxuIik7DQorICAgICAgICAgICAgICAgIHJjID0g
RUlOVkFMOw0KKyAgICAgICAgICAgICAgICBnb3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgICAgIH0N
CisgICAgICAgIH0NCisgICAgICAgIHdoaWxlIChjcHVpZGEgPD0gY3B1aWRiKSB7DQorICAgICAg
ICAgICAgcm1jcHUgPT0gMCA/IGxpYnhsX2NwdW1hcF9zZXQoY3B1bWFwLCBjcHVpZGEpIDoNCisg
ICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfY3B1bWFwX3NldCgmZXhjbHVkZV9jcHVtYXAs
IGNwdWlkYSk7DQorICAgICAgICAgICAgY3B1aWRhKys7DQorICAgICAgICB9DQorICAgIH0NCisN
CisgICAgLyogQ2xlYXIgYWxsIHRoZSBjcHVzIGZyb20gdGhlIHJlbW92YWwgbGlzdCAqLw0KKyAg
ICBsaWJ4bF9mb3JfZWFjaF9zZXRfY3B1KGksIGV4Y2x1ZGVfY3B1bWFwKSB7DQorICAgICAgICBs
aWJ4bF9jcHVtYXBfcmVzZXQoY3B1bWFwLCBpKTsNCisgICAgfQ0KKw0KK3ZjcHBfb3V0Og0KKyAg
ICBsaWJ4bF9jcHVtYXBfZGlzcG9zZSgmZXhjbHVkZV9jcHVtYXApOw0KKw0KKyAgICByZXR1cm4g
cmM7DQorfQ0KKw0KIHN0YXRpYyB2b2lkIHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXIgKmNv
bmZpZ2ZpbGVfZmlsZW5hbWVfcmVwb3J0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGNvbnN0IGNoYXIgKmNvbmZpZ2ZpbGVfZGF0YSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBpbnQgY29uZmlnZmlsZV9sZW4sDQpAQCAtNTc4LDcgKzYzNyw3IEBAIHN0YXRpYyB2b2lk
IHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXINCiAgICAgY29uc3QgY2hhciAqYnVmOw0KICAg
ICBsb25nIGw7DQogICAgIFhMVV9Db25maWcgKmNvbmZpZzsNCi0gICAgWExVX0NvbmZpZ0xpc3Qg
KnZiZHMsICpuaWNzLCAqcGNpcywgKmN2ZmJzLCAqY3B1aWRzOw0KKyAgICBYTFVfQ29uZmlnTGlz
dCAqY3B1cywgKnZiZHMsICpuaWNzLCAqcGNpcywgKmN2ZmJzLCAqY3B1aWRzOw0KICAgICBpbnQg
cGNpX3Bvd2VyX21nbXQgPSAwOw0KICAgICBpbnQgcGNpX21zaXRyYW5zbGF0ZSA9IDE7DQogICAg
IGludCBlOw0KQEAgLTY2MSw2ICs3MjAsMjkgQEAgc3RhdGljIHZvaWQgcGFyc2VfY29uZmlnX2Rh
dGEoY29uc3QgY2hhcg0KICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcgKGNvbmZpZywgIm1heHZj
cHVzIiwgJmwsIDApKQ0KICAgICAgICAgYl9pbmZvLT5tYXhfdmNwdXMgPSBsOw0KIA0KKyAgICBp
ZiAoIXhsdV9jZmdfZ2V0X2xpc3QgKGNvbmZpZywgImNwdXMiLCAmY3B1cywgMCwgMSkpIHsNCisg
ICAgICAgIGludCBpLCBuX2NwdXMgPSAwOw0KKw0KKyAgICAgICAgbGlieGxfY3B1bWFwX3NldF9u
b25lKCZiX2luZm8tPmNwdW1hcCk7DQorICAgICAgICB3aGlsZSAoKGJ1ZiA9IHhsdV9jZmdfZ2V0
X2xpc3RpdGVtKGNwdXMsIG5fY3B1cykpICE9IE5VTEwpIHsNCisgICAgICAgICAgICBpID0gYXRv
aShidWYpOw0KKyAgICAgICAgICAgIGlmICghbGlieGxfY3B1bWFwX2NwdV92YWxpZCgmYl9pbmZv
LT5jcHVtYXAsIGkpKSB7DQorICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiY3B1ICVk
IGlsbGVnYWxcbiIsIGkpOw0KKyAgICAgICAgICAgICAgICBleGl0KDEpOw0KKyAgICAgICAgICAg
IH0NCisgICAgICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0KCZiX2luZm8tPmNwdW1hcCwgaSk7DQor
ICAgICAgICAgICAgbl9jcHVzKys7DQorICAgICAgICB9DQorICAgIH0NCisgICAgZWxzZSBpZiAo
IXhsdV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAiY3B1cyIsICZidWYsIDApKSB7DQorICAgICAg
ICBjaGFyICpidWYyID0gc3RyZHVwKGJ1Zik7DQorDQorICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0
X25vbmUoJmJfaW5mby0+Y3B1bWFwKTsNCisgICAgICAgIGlmICh2Y3B1cGluX3BhcnNlKGJ1ZjIs
ICZiX2luZm8tPmNwdW1hcCkpDQorICAgICAgICAgICAgZXhpdCgxKTsNCisgICAgICAgIGZyZWUo
YnVmMik7DQorICAgIH0NCisNCiAgICAgaWYgKCF4bHVfY2ZnX2dldF9sb25nIChjb25maWcsICJt
ZW1vcnkiLCAmbCwgMCkpIHsNCiAgICAgICAgIGJfaW5mby0+bWF4X21lbWtiID0gbCAqIDEwMjQ7
DQogICAgICAgICBiX2luZm8tPnRhcmdldF9tZW1rYiA9IGJfaW5mby0+bWF4X21lbWtiOw0KQEAg
LTM1MDMsNjUgKzM1ODUsNiBAQCBpbnQgbWFpbl92Y3B1bGlzdChpbnQgYXJnYywgY2hhciAqKmFy
Z3YpDQogICAgIHJldHVybiAwOw0KIH0NCiANCi1zdGF0aWMgaW50IHZjcHVwaW5fcGFyc2UoY2hh
ciAqY3B1LCBsaWJ4bF9jcHVtYXAgKmNwdW1hcCkNCi17DQotICAgIGxpYnhsX2NwdW1hcCBleGNs
dWRlX2NwdW1hcDsNCi0gICAgdWludDMyX3QgY3B1aWRhLCBjcHVpZGI7DQotICAgIGNoYXIgKmVu
ZHB0ciwgKnRva2EsICp0b2tiLCAqc2F2ZXB0ciA9IE5VTEw7DQotICAgIGludCBpLCByYyA9IDAs
IHJtY3B1Ow0KLQ0KLSAgICBpZiAoIXN0cmNtcChjcHUsICJhbGwiKSkgew0KLSAgICAgICAgbWVt
c2V0KGNwdW1hcC0+bWFwLCAtMSwgY3B1bWFwLT5zaXplKTsNCi0gICAgICAgIHJldHVybiAwOw0K
LSAgICB9DQotDQotICAgIGlmIChsaWJ4bF9jcHVtYXBfYWxsb2MoY3R4LCAmZXhjbHVkZV9jcHVt
YXApKSB7DQotICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBGYWlsZWQgdG8gYWxsb2Nh
dGUgY3B1bWFwLlxuIik7DQotICAgICAgICByZXR1cm4gRU5PTUVNOw0KLSAgICB9DQotDQotICAg
IGZvciAodG9rYSA9IHN0cnRva19yKGNwdSwgIiwiLCAmc2F2ZXB0cik7IHRva2E7DQotICAgICAg
ICAgdG9rYSA9IHN0cnRva19yKE5VTEwsICIsIiwgJnNhdmVwdHIpKSB7DQotICAgICAgICBybWNw
dSA9IDA7DQotICAgICAgICBpZiAoKnRva2EgPT0gJ14nKSB7DQotICAgICAgICAgICAgLyogVGhp
cyAoVGhlc2UpIENwdShzKSB3aWxsIGJlIHJlbW92ZWQgZnJvbSB0aGUgbWFwICovDQotICAgICAg
ICAgICAgdG9rYSsrOw0KLSAgICAgICAgICAgIHJtY3B1ID0gMTsNCi0gICAgICAgIH0NCi0gICAg
ICAgIC8qIEV4dHJhY3QgYSB2YWxpZCAocmFuZ2Ugb2YpIGNwdShzKSAqLw0KLSAgICAgICAgY3B1
aWRhID0gY3B1aWRiID0gc3RydG91bCh0b2thLCAmZW5kcHRyLCAxMCk7DQotICAgICAgICBpZiAo
ZW5kcHRyID09IHRva2EpIHsNCi0gICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBJ
bnZhbGlkIGFyZ3VtZW50LlxuIik7DQotICAgICAgICAgICAgcmMgPSBFSU5WQUw7DQotICAgICAg
ICAgICAgZ290byB2Y3BwX291dDsNCi0gICAgICAgIH0NCi0gICAgICAgIGlmICgqZW5kcHRyID09
ICctJykgew0KLSAgICAgICAgICAgIHRva2IgPSBlbmRwdHIgKyAxOw0KLSAgICAgICAgICAgIGNw
dWlkYiA9IHN0cnRvdWwodG9rYiwgJmVuZHB0ciwgMTApOw0KLSAgICAgICAgICAgIGlmIChlbmRw
dHIgPT0gdG9rYiB8fCBjcHVpZGEgPiBjcHVpZGIpIHsNCi0gICAgICAgICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJFcnJvcjogSW52YWxpZCBhcmd1bWVudC5cbiIpOw0KLSAgICAgICAgICAgICAg
ICByYyA9IEVJTlZBTDsNCi0gICAgICAgICAgICAgICAgZ290byB2Y3BwX291dDsNCi0gICAgICAg
ICAgICB9DQotICAgICAgICB9DQotICAgICAgICB3aGlsZSAoY3B1aWRhIDw9IGNwdWlkYikgew0K
LSAgICAgICAgICAgIHJtY3B1ID09IDAgPyBsaWJ4bF9jcHVtYXBfc2V0KGNwdW1hcCwgY3B1aWRh
KSA6DQotICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2NwdW1hcF9zZXQoJmV4Y2x1ZGVf
Y3B1bWFwLCBjcHVpZGEpOw0KLSAgICAgICAgICAgIGNwdWlkYSsrOw0KLSAgICAgICAgfQ0KLSAg
ICB9DQotDQotICAgIC8qIENsZWFyIGFsbCB0aGUgY3B1cyBmcm9tIHRoZSByZW1vdmFsIGxpc3Qg
Ki8NCi0gICAgbGlieGxfZm9yX2VhY2hfc2V0X2NwdShpLCBleGNsdWRlX2NwdW1hcCkgew0KLSAg
ICAgICAgbGlieGxfY3B1bWFwX3Jlc2V0KGNwdW1hcCwgaSk7DQotICAgIH0NCi0NCi12Y3BwX291
dDoNCi0gICAgbGlieGxfY3B1bWFwX2Rpc3Bvc2UoJmV4Y2x1ZGVfY3B1bWFwKTsNCi0NCi0gICAg
cmV0dXJuIHJjOw0KLX0NCi0NCiBzdGF0aWMgdm9pZCB2Y3B1cGluKGNvbnN0IGNoYXIgKmQsIGNv
bnN0IGNoYXIgKnZjcHUsIGNoYXIgKmNwdSkNCiB7DQogICAgIGxpYnhsX3ZjcHVpbmZvICp2Y3B1
aW5mbzsNCg==


--=-oqQVQy5diNUns+vXee/K--

--=-zrugTtglDLYN0Fm/cuFQ
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)

iEYEABECAAYFAk8gE1sACgkQk4XaBE3IOsRjQgCgmyA1blq/BhmHuVn7iBI0yEFu
mWAAoIx5ZosTtI82MwEMJdXYLie+/ssX
=gdwS
-----END PGP SIGNATURE-----

--=-zrugTtglDLYN0Fm/cuFQ--



--===============1220177572573469436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1220177572573469436==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:36:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3xZ-00086h-Ol; Wed, 25 Jan 2012 14:36:25 +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 1Rq3xY-00086L-1E
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:36:24 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327502174!12340534!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9608 invoked from network); 25 Jan 2012 14:36:15 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-6.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 14:36:15 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75015413; Wed, 25 Jan 2012 15:36:12 +0100
Message-ID: <1327502171.2723.17.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:36:11 +0100
In-Reply-To: <1327500920.2723.11.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv3 1 of 2] libxl: allow for specifying the CPU
 affinity in the config 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: multipart/mixed; boundary="===============1220177572573469436=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============1220177572573469436==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-zrugTtglDLYN0Fm/cuFQ"


--=-zrugTtglDLYN0Fm/cuFQ
Content-Type: multipart/mixed; boundary="=-oqQVQy5diNUns+vXee/K"


--=-oqQVQy5diNUns+vXee/K
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Enable CPU affinity specification in a VM's config file with the
exact syntax `xl vcpu-pin' provides.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r e4fd5305381e tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Jan 25 14:08:21 2012 +0000
@@ -2663,6 +2663,21 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
     return 0;
 }
=20
+int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
+                               unsigned int max_vcpus, libxl_cpumap *cpuma=
p)
+{
+    int i, rc =3D 0;
+
+    for (i =3D 0; i < max_vcpus; i++) {
+        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
+            LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
+                       "failed to set affinity for %d", i);
+            rc =3D ERROR_FAIL;
+        }
+    }
+    return rc;
+}
+
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpu=
map)
 {
     GC_INIT(ctx);
diff -r e4fd5305381e tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Jan 25 14:08:21 2012 +0000
@@ -560,6 +560,8 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
                                        int *nb_vcpu, int *nrcpus);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid=
,
                            libxl_cpumap *cpumap);
+int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
+                               unsigned int max_vcpus, libxl_cpumap *cpuma=
p);
 int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpu=
map);
=20
 int libxl_get_sched_id(libxl_ctx *ctx);
diff -r e4fd5305381e tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 25 14:08:21 2012 +0000
@@ -71,6 +71,9 @@ int libxl_init_build_info(libxl_ctx *ctx
     memset(b_info, '\0', sizeof(*b_info));
     b_info->max_vcpus =3D 1;
     b_info->cur_vcpus =3D 1;
+    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
+        return ERROR_NOMEM;
+    libxl_cpumap_set_any(&b_info->cpumap);
     b_info->max_memkb =3D 32 * 1024;
     b_info->target_memkb =3D b_info->max_memkb;
     b_info->disable_migrate =3D 0;
diff -r e4fd5305381e tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Wed Jan 25 14:08:21 2012 +0000
@@ -65,6 +65,7 @@ int libxl__build_pre(libxl__gc *gc, uint
     libxl_ctx *ctx =3D libxl__gc_owner(gc);
     int tsc_mode;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
+    libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap)=
;
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM=
_CONSTANT);
     if (info->type =3D=3D LIBXL_DOMAIN_TYPE_PV)
         xc_domain_set_memmap_limit(ctx->xch, domid,
diff -r e4fd5305381e tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 25 14:08:21 2012 +0000
@@ -162,6 +162,7 @@ libxl_domain_create_info =3D Struct("domai
 libxl_domain_build_info =3D Struct("domain_build_info",[
     ("max_vcpus",       integer),
     ("cur_vcpus",       integer),
+    ("cpumap",          libxl_cpumap),
     ("tsc_mode",        libxl_tsc_mode),
     ("max_memkb",       uint32),
     ("target_memkb",    uint32),
diff -r e4fd5305381e tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Wed Jan 25 14:08:21 2012 +0000
@@ -70,6 +70,18 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
 int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
+static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
+{
+    memset(cpumap->map, -1, cpumap->size);
+}
+static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
+{
+    memset(cpumap->map, 0, cpumap->size);
+}
+static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
+{
+    return cpu >=3D 0 && cpu < (cpumap->size * 8);
+}
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
 #define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
                                              if (libxl_cpumap_test(&(m), v=
))
diff -r e4fd5305381e tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 11:40:23 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 14:08:21 2012 +0000
@@ -569,6 +569,65 @@ static void split_string_into_string_lis
     free(s);
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb, *saveptr =3D NULL;
+    int i, rc =3D 0, rmcpu;
+
+    if (!strcmp(cpu, "all")) {
+        libxl_cpumap_set_any(cpumap);
+        return 0;
+    }
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+        return ENOMEM;
+    }
+
+    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
+         toka =3D strtok_r(NULL, ",", &saveptr)) {
+        rmcpu =3D 0;
+        if (*toka =3D=3D '^') {
+            /* This (These) Cpu(s) will be removed from the map */
+            toka++;
+            rmcpu =3D 1;
+        }
+        /* Extract a valid (range of) cpu(s) */
+        cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
+        if (endptr =3D=3D toka) {
+            fprintf(stderr, "Error: Invalid argument.\n");
+            rc =3D EINVAL;
+            goto vcpp_out;
+        }
+        if (*endptr =3D=3D '-') {
+            tokb =3D endptr + 1;
+            cpuidb =3D strtoul(tokb, &endptr, 10);
+            if (endptr =3D=3D tokb || cpuida > cpuidb) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                rc =3D EINVAL;
+                goto vcpp_out;
+            }
+        }
+        while (cpuida <=3D cpuidb) {
+            rmcpu =3D=3D 0 ? libxl_cpumap_set(cpumap, cpuida) :
+                         libxl_cpumap_set(&exclude_cpumap, cpuida);
+            cpuida++;
+        }
+    }
+
+    /* Clear all the cpus from the removal list */
+    libxl_for_each_set_cpu(i, exclude_cpumap) {
+        libxl_cpumap_reset(cpumap, i);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return rc;
+}
+
 static void parse_config_data(const char *configfile_filename_report,
                               const char *configfile_data,
                               int configfile_len,
@@ -578,7 +637,7 @@ static void parse_config_data(const char
     const char *buf;
     long l;
     XLU_Config *config;
-    XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
+    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
     int pci_power_mgmt =3D 0;
     int pci_msitranslate =3D 1;
     int e;
@@ -661,6 +720,29 @@ static void parse_config_data(const char
     if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
         b_info->max_vcpus =3D l;
=20
+    if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
+        int i, n_cpus =3D 0;
+
+        libxl_cpumap_set_none(&b_info->cpumap);
+        while ((buf =3D xlu_cfg_get_listitem(cpus, n_cpus)) !=3D NULL) {
+            i =3D atoi(buf);
+            if (!libxl_cpumap_cpu_valid(&b_info->cpumap, i)) {
+                fprintf(stderr, "cpu %d illegal\n", i);
+                exit(1);
+            }
+            libxl_cpumap_set(&b_info->cpumap, i);
+            n_cpus++;
+        }
+    }
+    else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
+        char *buf2 =3D strdup(buf);
+
+        libxl_cpumap_set_none(&b_info->cpumap);
+        if (vcpupin_parse(buf2, &b_info->cpumap))
+            exit(1);
+        free(buf2);
+    }
+
     if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
         b_info->max_memkb =3D l * 1024;
         b_info->target_memkb =3D b_info->max_memkb;
@@ -3503,65 +3585,6 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
-static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
-{
-    libxl_cpumap exclude_cpumap;
-    uint32_t cpuida, cpuidb;
-    char *endptr, *toka, *tokb, *saveptr =3D NULL;
-    int i, rc =3D 0, rmcpu;
-
-    if (!strcmp(cpu, "all")) {
-        memset(cpumap->map, -1, cpumap->size);
-        return 0;
-    }
-
-    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
-        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
-        return ENOMEM;
-    }
-
-    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
-         toka =3D strtok_r(NULL, ",", &saveptr)) {
-        rmcpu =3D 0;
-        if (*toka =3D=3D '^') {
-            /* This (These) Cpu(s) will be removed from the map */
-            toka++;
-            rmcpu =3D 1;
-        }
-        /* Extract a valid (range of) cpu(s) */
-        cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
-        if (endptr =3D=3D toka) {
-            fprintf(stderr, "Error: Invalid argument.\n");
-            rc =3D EINVAL;
-            goto vcpp_out;
-        }
-        if (*endptr =3D=3D '-') {
-            tokb =3D endptr + 1;
-            cpuidb =3D strtoul(tokb, &endptr, 10);
-            if (endptr =3D=3D tokb || cpuida > cpuidb) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                rc =3D EINVAL;
-                goto vcpp_out;
-            }
-        }
-        while (cpuida <=3D cpuidb) {
-            rmcpu =3D=3D 0 ? libxl_cpumap_set(cpumap, cpuida) :
-                         libxl_cpumap_set(&exclude_cpumap, cpuida);
-            cpuida++;
-        }
-    }
-
-    /* Clear all the cpus from the removal list */
-    libxl_for_each_set_cpu(i, exclude_cpumap) {
-        libxl_cpumap_reset(cpumap, i);
-    }
-
-vcpp_out:
-    libxl_cpumap_dispose(&exclude_cpumap);
-
-    return rc;
-}
-
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-oqQVQy5diNUns+vXee/K
Content-Disposition: attachment; filename="support-cpus-par-in-config-file.patch"
Content-Type: text/x-patch; name="support-cpus-par-in-config-file.patch";
	charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGU0ZmQ1MzA1MzgxZTYzYWY5NjhmYmEwN2U1
YjQ5ZGQzMjFkMDg0ZGMNCmxpYnhsOiBhbGxvdyBmb3Igc3BlY2lmeWluZyB0aGUgQ1BVIGFmZmlu
aXR5IGluIHRoZSBjb25maWcgZmlsZS4NCg0KRW5hYmxlIENQVSBhZmZpbml0eSBzcGVjaWZpY2F0
aW9uIGluIGEgVk0ncyBjb25maWcgZmlsZSB3aXRoIHRoZQ0KZXhhY3Qgc3ludGF4IGB4bCB2Y3B1
LXBpbicgcHJvdmlkZXMuDQoNClNpZ25lZC1vZmYtYnk6IERhcmlvIEZhZ2dpb2xpIDxkYXJpby5m
YWdnaW9saUBjaXRyaXguY29tPg0KDQpkaWZmIC1yIGU0ZmQ1MzA1MzgxZSB0b29scy9saWJ4bC9s
aWJ4bC5jDQotLS0gYS90b29scy9saWJ4bC9saWJ4bC5jCVdlZCBKYW4gMjUgMTE6NDA6MjMgMjAx
MiArMDAwMA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYwlXZWQgSmFuIDI1IDE0OjA4OjIxIDIw
MTIgKzAwMDANCkBAIC0yNjYzLDYgKzI2NjMsMjEgQEAgaW50IGxpYnhsX3NldF92Y3B1YWZmaW5p
dHkobGlieGxfY3R4ICpjdA0KICAgICByZXR1cm4gMDsNCiB9DQogDQoraW50IGxpYnhsX3NldF92
Y3B1YWZmaW5pdHlfYWxsKGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwNCisgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgdW5zaWduZWQgaW50IG1heF92Y3B1cywgbGlieGxfY3B1
bWFwICpjcHVtYXApDQorew0KKyAgICBpbnQgaSwgcmMgPSAwOw0KKw0KKyAgICBmb3IgKGkgPSAw
OyBpIDwgbWF4X3ZjcHVzOyBpKyspIHsNCisgICAgICAgIGlmIChsaWJ4bF9zZXRfdmNwdWFmZmlu
aXR5KGN0eCwgZG9taWQsIGksIGNwdW1hcCkpIHsNCisgICAgICAgICAgICBMSUJYTF9fTE9HKGN0
eCwgTElCWExfX0xPR19XQVJOSU5HLA0KKyAgICAgICAgICAgICAgICAgICAgICAgImZhaWxlZCB0
byBzZXQgYWZmaW5pdHkgZm9yICVkIiwgaSk7DQorICAgICAgICAgICAgcmMgPSBFUlJPUl9GQUlM
Ow0KKyAgICAgICAgfQ0KKyAgICB9DQorICAgIHJldHVybiByYzsNCit9DQorDQogaW50IGxpYnhs
X3NldF92Y3B1b25saW5lKGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgbGlieGxfY3B1
bWFwICpjcHVtYXApDQogew0KICAgICBHQ19JTklUKGN0eCk7DQpkaWZmIC1yIGU0ZmQ1MzA1Mzgx
ZSB0b29scy9saWJ4bC9saWJ4bC5oDQotLS0gYS90b29scy9saWJ4bC9saWJ4bC5oCVdlZCBKYW4g
MjUgMTE6NDA6MjMgMjAxMiArMDAwMA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGwuaAlXZWQgSmFu
IDI1IDE0OjA4OjIxIDIwMTIgKzAwMDANCkBAIC01NjAsNiArNTYwLDggQEAgbGlieGxfdmNwdWlu
Zm8gKmxpYnhsX2xpc3RfdmNwdShsaWJ4bF9jdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIGludCAqbmJfdmNwdSwgaW50ICpucmNwdXMpOw0KIGludCBsaWJ4bF9zZXRf
dmNwdWFmZmluaXR5KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgdWludDMyX3QgdmNw
dWlkLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2NwdW1hcCAqY3B1bWFwKTsN
CitpbnQgbGlieGxfc2V0X3ZjcHVhZmZpbml0eV9hbGwobGlieGxfY3R4ICpjdHgsIHVpbnQzMl90
IGRvbWlkLA0KKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1bnNpZ25lZCBpbnQgbWF4
X3ZjcHVzLCBsaWJ4bF9jcHVtYXAgKmNwdW1hcCk7DQogaW50IGxpYnhsX3NldF92Y3B1b25saW5l
KGxpYnhsX2N0eCAqY3R4LCB1aW50MzJfdCBkb21pZCwgbGlieGxfY3B1bWFwICpjcHVtYXApOw0K
IA0KIGludCBsaWJ4bF9nZXRfc2NoZWRfaWQobGlieGxfY3R4ICpjdHgpOw0KZGlmZiAtciBlNGZk
NTMwNTM4MWUgdG9vbHMvbGlieGwvbGlieGxfY3JlYXRlLmMNCi0tLSBhL3Rvb2xzL2xpYnhsL2xp
YnhsX2NyZWF0ZS5jCVdlZCBKYW4gMjUgMTE6NDA6MjMgMjAxMiArMDAwMA0KKysrIGIvdG9vbHMv
bGlieGwvbGlieGxfY3JlYXRlLmMJV2VkIEphbiAyNSAxNDowODoyMSAyMDEyICswMDAwDQpAQCAt
NzEsNiArNzEsOSBAQCBpbnQgbGlieGxfaW5pdF9idWlsZF9pbmZvKGxpYnhsX2N0eCAqY3R4DQog
ICAgIG1lbXNldChiX2luZm8sICdcMCcsIHNpemVvZigqYl9pbmZvKSk7DQogICAgIGJfaW5mby0+
bWF4X3ZjcHVzID0gMTsNCiAgICAgYl9pbmZvLT5jdXJfdmNwdXMgPSAxOw0KKyAgICBpZiAobGli
eGxfY3B1bWFwX2FsbG9jKGN0eCwgJmJfaW5mby0+Y3B1bWFwKSkNCisgICAgICAgIHJldHVybiBF
UlJPUl9OT01FTTsNCisgICAgbGlieGxfY3B1bWFwX3NldF9hbnkoJmJfaW5mby0+Y3B1bWFwKTsN
CiAgICAgYl9pbmZvLT5tYXhfbWVta2IgPSAzMiAqIDEwMjQ7DQogICAgIGJfaW5mby0+dGFyZ2V0
X21lbWtiID0gYl9pbmZvLT5tYXhfbWVta2I7DQogICAgIGJfaW5mby0+ZGlzYWJsZV9taWdyYXRl
ID0gMDsNCmRpZmYgLXIgZTRmZDUzMDUzODFlIHRvb2xzL2xpYnhsL2xpYnhsX2RvbS5jDQotLS0g
YS90b29scy9saWJ4bC9saWJ4bF9kb20uYwlXZWQgSmFuIDI1IDExOjQwOjIzIDIwMTIgKzAwMDAN
CisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX2RvbS5jCVdlZCBKYW4gMjUgMTQ6MDg6MjEgMjAxMiAr
MDAwMA0KQEAgLTY1LDYgKzY1LDcgQEAgaW50IGxpYnhsX19idWlsZF9wcmUobGlieGxfX2djICpn
YywgdWludA0KICAgICBsaWJ4bF9jdHggKmN0eCA9IGxpYnhsX19nY19vd25lcihnYyk7DQogICAg
IGludCB0c2NfbW9kZTsNCiAgICAgeGNfZG9tYWluX21heF92Y3B1cyhjdHgtPnhjaCwgZG9taWQs
IGluZm8tPm1heF92Y3B1cyk7DQorICAgIGxpYnhsX3NldF92Y3B1YWZmaW5pdHlfYWxsKGN0eCwg
ZG9taWQsIGluZm8tPm1heF92Y3B1cywgJmluZm8tPmNwdW1hcCk7DQogICAgIHhjX2RvbWFpbl9z
ZXRtYXhtZW0oY3R4LT54Y2gsIGRvbWlkLCBpbmZvLT50YXJnZXRfbWVta2IgKyBMSUJYTF9NQVhN
RU1fQ09OU1RBTlQpOw0KICAgICBpZiAoaW5mby0+dHlwZSA9PSBMSUJYTF9ET01BSU5fVFlQRV9Q
VikNCiAgICAgICAgIHhjX2RvbWFpbl9zZXRfbWVtbWFwX2xpbWl0KGN0eC0+eGNoLCBkb21pZCwN
CmRpZmYgLXIgZTRmZDUzMDUzODFlIHRvb2xzL2xpYnhsL2xpYnhsX3R5cGVzLmlkbA0KLS0tIGEv
dG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVdlZCBKYW4gMjUgMTE6NDA6MjMgMjAxMiArMDAw
MA0KKysrIGIvdG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsCVdlZCBKYW4gMjUgMTQ6MDg6MjEg
MjAxMiArMDAwMA0KQEAgLTE2Miw2ICsxNjIsNyBAQCBsaWJ4bF9kb21haW5fY3JlYXRlX2luZm8g
PSBTdHJ1Y3QoImRvbWFpDQogbGlieGxfZG9tYWluX2J1aWxkX2luZm8gPSBTdHJ1Y3QoImRvbWFp
bl9idWlsZF9pbmZvIixbDQogICAgICgibWF4X3ZjcHVzIiwgICAgICAgaW50ZWdlciksDQogICAg
ICgiY3VyX3ZjcHVzIiwgICAgICAgaW50ZWdlciksDQorICAgICgiY3B1bWFwIiwgICAgICAgICAg
bGlieGxfY3B1bWFwKSwNCiAgICAgKCJ0c2NfbW9kZSIsICAgICAgICBsaWJ4bF90c2NfbW9kZSks
DQogICAgICgibWF4X21lbWtiIiwgICAgICAgdWludDMyKSwNCiAgICAgKCJ0YXJnZXRfbWVta2Ii
LCAgICB1aW50MzIpLA0KZGlmZiAtciBlNGZkNTMwNTM4MWUgdG9vbHMvbGlieGwvbGlieGxfdXRp
bHMuaA0KLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfdXRpbHMuaAlXZWQgSmFuIDI1IDExOjQwOjIz
IDIwMTIgKzAwMDANCisrKyBiL3Rvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgJV2VkIEphbiAyNSAx
NDowODoyMSAyMDEyICswMDAwDQpAQCAtNzAsNiArNzAsMTggQEAgaW50IGxpYnhsX2NwdW1hcF9h
bGxvYyhsaWJ4bF9jdHggKmN0eCwgbA0KIGludCBsaWJ4bF9jcHVtYXBfdGVzdChsaWJ4bF9jcHVt
YXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4bF9jcHVtYXBfc2V0KGxpYnhsX2NwdW1h
cCAqY3B1bWFwLCBpbnQgY3B1KTsNCiB2b2lkIGxpYnhsX2NwdW1hcF9yZXNldChsaWJ4bF9jcHVt
YXAgKmNwdW1hcCwgaW50IGNwdSk7DQorc3RhdGljIGlubGluZSB2b2lkIGxpYnhsX2NwdW1hcF9z
ZXRfYW55KGxpYnhsX2NwdW1hcCAqY3B1bWFwKQ0KK3sNCisgICAgbWVtc2V0KGNwdW1hcC0+bWFw
LCAtMSwgY3B1bWFwLT5zaXplKTsNCit9DQorc3RhdGljIGlubGluZSB2b2lkIGxpYnhsX2NwdW1h
cF9zZXRfbm9uZShsaWJ4bF9jcHVtYXAgKmNwdW1hcCkNCit7DQorICAgIG1lbXNldChjcHVtYXAt
Pm1hcCwgMCwgY3B1bWFwLT5zaXplKTsNCit9DQorc3RhdGljIGlubGluZSBpbnQgbGlieGxfY3B1
bWFwX2NwdV92YWxpZChsaWJ4bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSkNCit7DQorICAgIHJl
dHVybiBjcHUgPj0gMCAmJiBjcHUgPCAoY3B1bWFwLT5zaXplICogOCk7DQorfQ0KICNkZWZpbmUg
bGlieGxfZm9yX2VhY2hfY3B1KHZhciwgbWFwKSBmb3IgKHZhciA9IDA7IHZhciA8IChtYXApLnNp
emUgKiA4OyB2YXIrKykNCiAjZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUodiwgbSkgZm9y
ICh2ID0gMDsgdiA8IChtKS5zaXplICogODsgdisrKSBcDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgaWYgKGxpYnhsX2NwdW1hcF90ZXN0KCYobSksIHYpKQ0K
ZGlmZiAtciBlNGZkNTMwNTM4MWUgdG9vbHMvbGlieGwveGxfY21kaW1wbC5jDQotLS0gYS90b29s
cy9saWJ4bC94bF9jbWRpbXBsLmMJV2VkIEphbiAyNSAxMTo0MDoyMyAyMDEyICswMDAwDQorKysg
Yi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMJV2VkIEphbiAyNSAxNDowODoyMSAyMDEyICswMDAw
DQpAQCAtNTY5LDYgKzU2OSw2NSBAQCBzdGF0aWMgdm9pZCBzcGxpdF9zdHJpbmdfaW50b19zdHJp
bmdfbGlzDQogICAgIGZyZWUocyk7DQogfQ0KIA0KK3N0YXRpYyBpbnQgdmNwdXBpbl9wYXJzZShj
aGFyICpjcHUsIGxpYnhsX2NwdW1hcCAqY3B1bWFwKQ0KK3sNCisgICAgbGlieGxfY3B1bWFwIGV4
Y2x1ZGVfY3B1bWFwOw0KKyAgICB1aW50MzJfdCBjcHVpZGEsIGNwdWlkYjsNCisgICAgY2hhciAq
ZW5kcHRyLCAqdG9rYSwgKnRva2IsICpzYXZlcHRyID0gTlVMTDsNCisgICAgaW50IGksIHJjID0g
MCwgcm1jcHU7DQorDQorICAgIGlmICghc3RyY21wKGNwdSwgImFsbCIpKSB7DQorICAgICAgICBs
aWJ4bF9jcHVtYXBfc2V0X2FueShjcHVtYXApOw0KKyAgICAgICAgcmV0dXJuIDA7DQorICAgIH0N
CisNCisgICAgaWYgKGxpYnhsX2NwdW1hcF9hbGxvYyhjdHgsICZleGNsdWRlX2NwdW1hcCkpIHsN
CisgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEZhaWxlZCB0byBhbGxvY2F0ZSBjcHVt
YXAuXG4iKTsNCisgICAgICAgIHJldHVybiBFTk9NRU07DQorICAgIH0NCisNCisgICAgZm9yICh0
b2thID0gc3RydG9rX3IoY3B1LCAiLCIsICZzYXZlcHRyKTsgdG9rYTsNCisgICAgICAgICB0b2th
ID0gc3RydG9rX3IoTlVMTCwgIiwiLCAmc2F2ZXB0cikpIHsNCisgICAgICAgIHJtY3B1ID0gMDsN
CisgICAgICAgIGlmICgqdG9rYSA9PSAnXicpIHsNCisgICAgICAgICAgICAvKiBUaGlzIChUaGVz
ZSkgQ3B1KHMpIHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSBtYXAgKi8NCisgICAgICAgICAgICB0
b2thKys7DQorICAgICAgICAgICAgcm1jcHUgPSAxOw0KKyAgICAgICAgfQ0KKyAgICAgICAgLyog
RXh0cmFjdCBhIHZhbGlkIChyYW5nZSBvZikgY3B1KHMpICovDQorICAgICAgICBjcHVpZGEgPSBj
cHVpZGIgPSBzdHJ0b3VsKHRva2EsICZlbmRwdHIsIDEwKTsNCisgICAgICAgIGlmIChlbmRwdHIg
PT0gdG9rYSkgew0KKyAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFsaWQg
YXJndW1lbnQuXG4iKTsNCisgICAgICAgICAgICByYyA9IEVJTlZBTDsNCisgICAgICAgICAgICBn
b3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgfQ0KKyAgICAgICAgaWYgKCplbmRwdHIgPT0gJy0nKSB7
DQorICAgICAgICAgICAgdG9rYiA9IGVuZHB0ciArIDE7DQorICAgICAgICAgICAgY3B1aWRiID0g
c3RydG91bCh0b2tiLCAmZW5kcHRyLCAxMCk7DQorICAgICAgICAgICAgaWYgKGVuZHB0ciA9PSB0
b2tiIHx8IGNwdWlkYSA+IGNwdWlkYikgew0KKyAgICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVy
ciwgIkVycm9yOiBJbnZhbGlkIGFyZ3VtZW50LlxuIik7DQorICAgICAgICAgICAgICAgIHJjID0g
RUlOVkFMOw0KKyAgICAgICAgICAgICAgICBnb3RvIHZjcHBfb3V0Ow0KKyAgICAgICAgICAgIH0N
CisgICAgICAgIH0NCisgICAgICAgIHdoaWxlIChjcHVpZGEgPD0gY3B1aWRiKSB7DQorICAgICAg
ICAgICAgcm1jcHUgPT0gMCA/IGxpYnhsX2NwdW1hcF9zZXQoY3B1bWFwLCBjcHVpZGEpIDoNCisg
ICAgICAgICAgICAgICAgICAgICAgICAgbGlieGxfY3B1bWFwX3NldCgmZXhjbHVkZV9jcHVtYXAs
IGNwdWlkYSk7DQorICAgICAgICAgICAgY3B1aWRhKys7DQorICAgICAgICB9DQorICAgIH0NCisN
CisgICAgLyogQ2xlYXIgYWxsIHRoZSBjcHVzIGZyb20gdGhlIHJlbW92YWwgbGlzdCAqLw0KKyAg
ICBsaWJ4bF9mb3JfZWFjaF9zZXRfY3B1KGksIGV4Y2x1ZGVfY3B1bWFwKSB7DQorICAgICAgICBs
aWJ4bF9jcHVtYXBfcmVzZXQoY3B1bWFwLCBpKTsNCisgICAgfQ0KKw0KK3ZjcHBfb3V0Og0KKyAg
ICBsaWJ4bF9jcHVtYXBfZGlzcG9zZSgmZXhjbHVkZV9jcHVtYXApOw0KKw0KKyAgICByZXR1cm4g
cmM7DQorfQ0KKw0KIHN0YXRpYyB2b2lkIHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXIgKmNv
bmZpZ2ZpbGVfZmlsZW5hbWVfcmVwb3J0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGNvbnN0IGNoYXIgKmNvbmZpZ2ZpbGVfZGF0YSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBpbnQgY29uZmlnZmlsZV9sZW4sDQpAQCAtNTc4LDcgKzYzNyw3IEBAIHN0YXRpYyB2b2lk
IHBhcnNlX2NvbmZpZ19kYXRhKGNvbnN0IGNoYXINCiAgICAgY29uc3QgY2hhciAqYnVmOw0KICAg
ICBsb25nIGw7DQogICAgIFhMVV9Db25maWcgKmNvbmZpZzsNCi0gICAgWExVX0NvbmZpZ0xpc3Qg
KnZiZHMsICpuaWNzLCAqcGNpcywgKmN2ZmJzLCAqY3B1aWRzOw0KKyAgICBYTFVfQ29uZmlnTGlz
dCAqY3B1cywgKnZiZHMsICpuaWNzLCAqcGNpcywgKmN2ZmJzLCAqY3B1aWRzOw0KICAgICBpbnQg
cGNpX3Bvd2VyX21nbXQgPSAwOw0KICAgICBpbnQgcGNpX21zaXRyYW5zbGF0ZSA9IDE7DQogICAg
IGludCBlOw0KQEAgLTY2MSw2ICs3MjAsMjkgQEAgc3RhdGljIHZvaWQgcGFyc2VfY29uZmlnX2Rh
dGEoY29uc3QgY2hhcg0KICAgICBpZiAoIXhsdV9jZmdfZ2V0X2xvbmcgKGNvbmZpZywgIm1heHZj
cHVzIiwgJmwsIDApKQ0KICAgICAgICAgYl9pbmZvLT5tYXhfdmNwdXMgPSBsOw0KIA0KKyAgICBp
ZiAoIXhsdV9jZmdfZ2V0X2xpc3QgKGNvbmZpZywgImNwdXMiLCAmY3B1cywgMCwgMSkpIHsNCisg
ICAgICAgIGludCBpLCBuX2NwdXMgPSAwOw0KKw0KKyAgICAgICAgbGlieGxfY3B1bWFwX3NldF9u
b25lKCZiX2luZm8tPmNwdW1hcCk7DQorICAgICAgICB3aGlsZSAoKGJ1ZiA9IHhsdV9jZmdfZ2V0
X2xpc3RpdGVtKGNwdXMsIG5fY3B1cykpICE9IE5VTEwpIHsNCisgICAgICAgICAgICBpID0gYXRv
aShidWYpOw0KKyAgICAgICAgICAgIGlmICghbGlieGxfY3B1bWFwX2NwdV92YWxpZCgmYl9pbmZv
LT5jcHVtYXAsIGkpKSB7DQorICAgICAgICAgICAgICAgIGZwcmludGYoc3RkZXJyLCAiY3B1ICVk
IGlsbGVnYWxcbiIsIGkpOw0KKyAgICAgICAgICAgICAgICBleGl0KDEpOw0KKyAgICAgICAgICAg
IH0NCisgICAgICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0KCZiX2luZm8tPmNwdW1hcCwgaSk7DQor
ICAgICAgICAgICAgbl9jcHVzKys7DQorICAgICAgICB9DQorICAgIH0NCisgICAgZWxzZSBpZiAo
IXhsdV9jZmdfZ2V0X3N0cmluZyAoY29uZmlnLCAiY3B1cyIsICZidWYsIDApKSB7DQorICAgICAg
ICBjaGFyICpidWYyID0gc3RyZHVwKGJ1Zik7DQorDQorICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0
X25vbmUoJmJfaW5mby0+Y3B1bWFwKTsNCisgICAgICAgIGlmICh2Y3B1cGluX3BhcnNlKGJ1ZjIs
ICZiX2luZm8tPmNwdW1hcCkpDQorICAgICAgICAgICAgZXhpdCgxKTsNCisgICAgICAgIGZyZWUo
YnVmMik7DQorICAgIH0NCisNCiAgICAgaWYgKCF4bHVfY2ZnX2dldF9sb25nIChjb25maWcsICJt
ZW1vcnkiLCAmbCwgMCkpIHsNCiAgICAgICAgIGJfaW5mby0+bWF4X21lbWtiID0gbCAqIDEwMjQ7
DQogICAgICAgICBiX2luZm8tPnRhcmdldF9tZW1rYiA9IGJfaW5mby0+bWF4X21lbWtiOw0KQEAg
LTM1MDMsNjUgKzM1ODUsNiBAQCBpbnQgbWFpbl92Y3B1bGlzdChpbnQgYXJnYywgY2hhciAqKmFy
Z3YpDQogICAgIHJldHVybiAwOw0KIH0NCiANCi1zdGF0aWMgaW50IHZjcHVwaW5fcGFyc2UoY2hh
ciAqY3B1LCBsaWJ4bF9jcHVtYXAgKmNwdW1hcCkNCi17DQotICAgIGxpYnhsX2NwdW1hcCBleGNs
dWRlX2NwdW1hcDsNCi0gICAgdWludDMyX3QgY3B1aWRhLCBjcHVpZGI7DQotICAgIGNoYXIgKmVu
ZHB0ciwgKnRva2EsICp0b2tiLCAqc2F2ZXB0ciA9IE5VTEw7DQotICAgIGludCBpLCByYyA9IDAs
IHJtY3B1Ow0KLQ0KLSAgICBpZiAoIXN0cmNtcChjcHUsICJhbGwiKSkgew0KLSAgICAgICAgbWVt
c2V0KGNwdW1hcC0+bWFwLCAtMSwgY3B1bWFwLT5zaXplKTsNCi0gICAgICAgIHJldHVybiAwOw0K
LSAgICB9DQotDQotICAgIGlmIChsaWJ4bF9jcHVtYXBfYWxsb2MoY3R4LCAmZXhjbHVkZV9jcHVt
YXApKSB7DQotICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBGYWlsZWQgdG8gYWxsb2Nh
dGUgY3B1bWFwLlxuIik7DQotICAgICAgICByZXR1cm4gRU5PTUVNOw0KLSAgICB9DQotDQotICAg
IGZvciAodG9rYSA9IHN0cnRva19yKGNwdSwgIiwiLCAmc2F2ZXB0cik7IHRva2E7DQotICAgICAg
ICAgdG9rYSA9IHN0cnRva19yKE5VTEwsICIsIiwgJnNhdmVwdHIpKSB7DQotICAgICAgICBybWNw
dSA9IDA7DQotICAgICAgICBpZiAoKnRva2EgPT0gJ14nKSB7DQotICAgICAgICAgICAgLyogVGhp
cyAoVGhlc2UpIENwdShzKSB3aWxsIGJlIHJlbW92ZWQgZnJvbSB0aGUgbWFwICovDQotICAgICAg
ICAgICAgdG9rYSsrOw0KLSAgICAgICAgICAgIHJtY3B1ID0gMTsNCi0gICAgICAgIH0NCi0gICAg
ICAgIC8qIEV4dHJhY3QgYSB2YWxpZCAocmFuZ2Ugb2YpIGNwdShzKSAqLw0KLSAgICAgICAgY3B1
aWRhID0gY3B1aWRiID0gc3RydG91bCh0b2thLCAmZW5kcHRyLCAxMCk7DQotICAgICAgICBpZiAo
ZW5kcHRyID09IHRva2EpIHsNCi0gICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkVycm9yOiBJ
bnZhbGlkIGFyZ3VtZW50LlxuIik7DQotICAgICAgICAgICAgcmMgPSBFSU5WQUw7DQotICAgICAg
ICAgICAgZ290byB2Y3BwX291dDsNCi0gICAgICAgIH0NCi0gICAgICAgIGlmICgqZW5kcHRyID09
ICctJykgew0KLSAgICAgICAgICAgIHRva2IgPSBlbmRwdHIgKyAxOw0KLSAgICAgICAgICAgIGNw
dWlkYiA9IHN0cnRvdWwodG9rYiwgJmVuZHB0ciwgMTApOw0KLSAgICAgICAgICAgIGlmIChlbmRw
dHIgPT0gdG9rYiB8fCBjcHVpZGEgPiBjcHVpZGIpIHsNCi0gICAgICAgICAgICAgICAgZnByaW50
ZihzdGRlcnIsICJFcnJvcjogSW52YWxpZCBhcmd1bWVudC5cbiIpOw0KLSAgICAgICAgICAgICAg
ICByYyA9IEVJTlZBTDsNCi0gICAgICAgICAgICAgICAgZ290byB2Y3BwX291dDsNCi0gICAgICAg
ICAgICB9DQotICAgICAgICB9DQotICAgICAgICB3aGlsZSAoY3B1aWRhIDw9IGNwdWlkYikgew0K
LSAgICAgICAgICAgIHJtY3B1ID09IDAgPyBsaWJ4bF9jcHVtYXBfc2V0KGNwdW1hcCwgY3B1aWRh
KSA6DQotICAgICAgICAgICAgICAgICAgICAgICAgIGxpYnhsX2NwdW1hcF9zZXQoJmV4Y2x1ZGVf
Y3B1bWFwLCBjcHVpZGEpOw0KLSAgICAgICAgICAgIGNwdWlkYSsrOw0KLSAgICAgICAgfQ0KLSAg
ICB9DQotDQotICAgIC8qIENsZWFyIGFsbCB0aGUgY3B1cyBmcm9tIHRoZSByZW1vdmFsIGxpc3Qg
Ki8NCi0gICAgbGlieGxfZm9yX2VhY2hfc2V0X2NwdShpLCBleGNsdWRlX2NwdW1hcCkgew0KLSAg
ICAgICAgbGlieGxfY3B1bWFwX3Jlc2V0KGNwdW1hcCwgaSk7DQotICAgIH0NCi0NCi12Y3BwX291
dDoNCi0gICAgbGlieGxfY3B1bWFwX2Rpc3Bvc2UoJmV4Y2x1ZGVfY3B1bWFwKTsNCi0NCi0gICAg
cmV0dXJuIHJjOw0KLX0NCi0NCiBzdGF0aWMgdm9pZCB2Y3B1cGluKGNvbnN0IGNoYXIgKmQsIGNv
bnN0IGNoYXIgKnZjcHUsIGNoYXIgKmNwdSkNCiB7DQogICAgIGxpYnhsX3ZjcHVpbmZvICp2Y3B1
aW5mbzsNCg==


--=-oqQVQy5diNUns+vXee/K--

--=-zrugTtglDLYN0Fm/cuFQ
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)

iEYEABECAAYFAk8gE1sACgkQk4XaBE3IOsRjQgCgmyA1blq/BhmHuVn7iBI0yEFu
mWAAoIx5ZosTtI82MwEMJdXYLie+/ssX
=gdwS
-----END PGP SIGNATURE-----

--=-zrugTtglDLYN0Fm/cuFQ--



--===============1220177572573469436==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1220177572573469436==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zX-0008SI-Ka; Wed, 25 Jan 2012 14:38:27 +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 1Rq3zS-0008Hs-Gz
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327502227!62444517!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32161 invoked from network); 25 Jan 2012 14:37:07 -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;
	25 Jan 2012 14:37: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
	q0PEcCUH003891; Wed, 25 Jan 2012 14:38: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 q0PEcCwq011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:37 -0500
Message-Id: <1327502278-1790-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/23] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   66 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 154 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 37b0fd6..2ffdd85 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -749,6 +749,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index fd20210..500c7a2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -86,7 +86,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -480,7 +480,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -621,7 +621,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -680,7 +680,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 5b0fc4a..8001a91 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -995,6 +995,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..43bd167 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,68 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++)
+    {
+        if (global_virq_handlers[virq] == d)
+        {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count)
+    {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1222,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..6560182 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -288,7 +288,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -315,7 +315,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 232d50e..40b8a7a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,11 +23,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..e3cae60 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..acf9c8a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..543dc77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zP-0008Iq-ON; Wed, 25 Jan 2012 14:38:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zN-0008Hq-Lx
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:17 +0000
Received: from [85.158.138.51:28402] by server-9.bemta-3.messagelabs.com id
	B6/01-31168-8D3102F4; Wed, 25 Jan 2012 14:38:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327502294!6414357!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13587 invoked from network); 25 Jan 2012 14:38:15 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:15 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PEcChp004117
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCwu011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:41 -0500
Message-Id: <1327502278-1790-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/23] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..3828c62 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -64,6 +64,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -95,9 +96,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c8da45..965dbd0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -243,9 +243,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zR-0008Kh-KU; Wed, 25 Jan 2012 14:38:21 +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 1Rq3zQ-0008HJ-26
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327502293!12530576!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10158 invoked from network); 25 Jan 2012 14:38:14 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:38:14 -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
	q0PEcCUH003892
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCws011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:39 -0500
Message-Id: <1327502278-1790-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/23] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 8001a91..904fb45 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -264,6 +264,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index acf9c8a..d99f886 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zV-0008PG-Pl; Wed, 25 Jan 2012 14:38:25 +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 1Rq3zR-0008Hf-EB
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327502293!9782345!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25877 invoked from network); 25 Jan 2012 14:38:14 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 14:38:14 -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
	q0PEcCUH003895
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx1011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:46 -0500
Message-Id: <1327502278-1790-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 11/23] mini-os: Move test functions into test.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

While useful, these test functions should not be compiled into every
mini-os instance that we compile.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile             |    1 +
 extras/mini-os/kernel.c             |  414 -----------------------------------
 extras/mini-os/{kernel.c => test.c} |  139 +-----------
 stubdom/c/minios.cfg                |    1 +
 stubdom/caml/minios.cfg             |    1 +
 5 files changed, 8 insertions(+), 548 deletions(-)
 copy extras/mini-os/{kernel.c => test.c} (80%)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index be38170..96c661a 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -63,6 +63,7 @@ src-y += mm.c
 src-y += netfront.c
 src-y += pcifront.c
 src-y += sched.c
+src-$(CONFIG_TEST) += test.c
 
 src-y += lib/ctype.c
 src-y += lib/math.c
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index 2875bf1..c8b9b8c 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -46,8 +46,6 @@
 #include <xen/features.h>
 #include <xen/version.h>
 
-static struct netfront_dev *net_dev;
-
 uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
 
 void setup_xen_features(void)
@@ -66,407 +64,10 @@ void setup_xen_features(void)
     }
 }
 
-void test_xenbus(void);
-
-static void xenbus_tester(void *p)
-{
-    printk("Xenbus tests disabled, because of a Xend bug.\n");
-    /* test_xenbus(); */
-}
-
-static void periodic_thread(void *p)
-{
-    struct timeval tv;
-    printk("Periodic thread started.\n");
-    for(;;)
-    {
-        gettimeofday(&tv, NULL);
-        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
-        msleep(1000);
-    }
-}
-
-static void netfront_thread(void *p)
-{
-    net_dev = init_netfront(NULL, NULL, NULL, NULL);
-}
-
-static struct blkfront_dev *blk_dev;
-static struct blkfront_info blk_info;
-static uint64_t blk_size_read;
-static uint64_t blk_size_write;
-
-struct blk_req {
-    struct blkfront_aiocb aiocb;
-    int rand_value;
-    struct blk_req *next;
-};
-
-#ifdef BLKTEST_WRITE
-static struct blk_req *blk_to_read;
-#endif
-
-static struct blk_req *blk_alloc_req(uint64_t sector)
-{
-    struct blk_req *req = xmalloc(struct blk_req);
-    req->aiocb.aio_dev = blk_dev;
-    req->aiocb.aio_buf = _xmalloc(blk_info.sector_size, blk_info.sector_size);
-    req->aiocb.aio_nbytes = blk_info.sector_size;
-    req->aiocb.aio_offset = sector * blk_info.sector_size;
-    req->aiocb.data = req;
-    req->next = NULL;
-    return req;
-}
-
-static void blk_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret)
-        printk("got error code %d when reading at offset %ld\n", ret, aiocb->aio_offset);
-    else
-        blk_size_read += blk_info.sector_size;
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_read_sector(uint64_t sector)
-{
-    struct blk_req *req;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_read_completed;
-
-    blkfront_aio_read(&req->aiocb);
-}
-
-#ifdef BLKTEST_WRITE
-static void blk_write_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    int rand_value;
-    int i;
-    int *buf;
-
-    if (ret) {
-        printk("got error code %d when reading back at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_read += blk_info.sector_size;
-    buf = (int*) aiocb->aio_buf;
-    rand_value = req->rand_value;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        if (buf[i] != rand_value) {
-            printk("bogus data at offset %ld\n", aiocb->aio_offset + i);
-            break;
-        }
-        rand_value *= RAND_MIX;
-    }
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_write_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret) {
-        printk("got error code %d when writing at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_write += blk_info.sector_size;
-    /* Push write check */
-    req->next = blk_to_read;
-    blk_to_read = req;
-}
-
-static void blk_write_sector(uint64_t sector)
-{
-    struct blk_req *req;
-    int rand_value;
-    int i;
-    int *buf;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_write_completed;
-    req->rand_value = rand_value = rand();
-
-    buf = (int*) req->aiocb.aio_buf;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        buf[i] = rand_value;
-        rand_value *= RAND_MIX;
-    }
-
-    blkfront_aio_write(&req->aiocb);
-}
-#endif
-
-static void blkfront_thread(void *p)
-{
-    time_t lasttime = 0;
-
-    blk_dev = init_blkfront(NULL, &blk_info);
-    if (!blk_dev)
-        return;
-
-    if (blk_info.info & VDISK_CDROM)
-        printk("Block device is a CDROM\n");
-    if (blk_info.info & VDISK_REMOVABLE)
-        printk("Block device is removable\n");
-    if (blk_info.info & VDISK_READONLY)
-        printk("Block device is read-only\n");
-
-#ifdef BLKTEST_WRITE
-    if (blk_info.mode == O_RDWR) {
-        blk_write_sector(0);
-        blk_write_sector(blk_info.sectors-1);
-    } else
-#endif
-    {
-        blk_read_sector(0);
-        blk_read_sector(blk_info.sectors-1);
-    }
-
-    while (1) {
-        uint64_t sector = rand() % blk_info.sectors;
-        struct timeval tv;
-#ifdef BLKTEST_WRITE
-        if (blk_info.mode == O_RDWR)
-            blk_write_sector(sector);
-        else
-#endif
-            blk_read_sector(sector);
-        blkfront_aio_poll(blk_dev);
-        gettimeofday(&tv, NULL);
-        if (tv.tv_sec > lasttime + 10) {
-            printk("%llu read, %llu write\n", blk_size_read, blk_size_write);
-            lasttime = tv.tv_sec;
-        }
-
-#ifdef BLKTEST_WRITE
-        while (blk_to_read) {
-            struct blk_req *req = blk_to_read;
-            blk_to_read = blk_to_read->next;
-            req->aiocb.aio_cb = blk_write_read_completed;
-            blkfront_aio_read(&req->aiocb);
-        }
-#endif
-    }
-}
-
-#define WIDTH 800
-#define HEIGHT 600
-#define DEPTH 32
-
-static uint32_t *fb;
-static int refresh_period = 50;
-static struct fbfront_dev *fb_dev;
-static struct semaphore fbfront_sem = __SEMAPHORE_INITIALIZER(fbfront_sem, 0);
-
-static void fbfront_drawvert(int x, int y1, int y2, uint32_t color)
-{
-    int y;
-    if (x < 0)
-        return;
-    if (x >= WIDTH)
-        return;
-    if (y1 < 0)
-        y1 = 0;
-    if (y2 >= HEIGHT)
-        y2 = HEIGHT-1;
-    for (y = y1; y <= y2; y++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_drawhoriz(int x1, int x2, int y, uint32_t color)
-{
-    int x;
-    if (y < 0)
-        return;
-    if (y >= HEIGHT)
-        return;
-    if (x1 < 0)
-        x1 = 0;
-    if (x2 >= WIDTH)
-        x2 = WIDTH-1;
-    for (x = x1; x <= x2; x++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_thread(void *p)
-{
-    size_t line_length = WIDTH * (DEPTH / 8);
-    size_t memsize = HEIGHT * line_length;
-    unsigned long *mfns;
-    int i, n = (memsize + PAGE_SIZE-1) / PAGE_SIZE;
-
-    memsize = n * PAGE_SIZE;
-    fb = _xmalloc(memsize, PAGE_SIZE);
-    memset(fb, 0, memsize);
-    mfns = xmalloc_array(unsigned long, n);
-    for (i = 0; i < n; i++)
-        mfns[i] = virtual_to_mfn((char *) fb + i * PAGE_SIZE);
-    fb_dev = init_fbfront(NULL, mfns, WIDTH, HEIGHT, DEPTH, line_length, n);
-    xfree(mfns);
-    if (!fb_dev) {
-        xfree(fb);
-        return;
-    }
-    up(&fbfront_sem);
-}
-
-static void clip_cursor(int *x, int *y)
-{
-    if (*x < 0)
-        *x = 0;
-    if (*x >= WIDTH)
-        *x = WIDTH - 1;
-    if (*y < 0)
-        *y = 0;
-    if (*y >= HEIGHT)
-        *y = HEIGHT - 1;
-}
-
-static void refresh_cursor(int new_x, int new_y)
-{
-    static int old_x = -1, old_y = -1;
-
-    if (!refresh_period)
-        return;
-
-    if (old_x != -1 && old_y != -1) {
-        fbfront_drawvert(old_x, old_y + 1, old_y + 8, 0xffffffff);
-        fbfront_drawhoriz(old_x + 1, old_x + 8, old_y, 0xffffffff);
-        fbfront_update(fb_dev, old_x, old_y, 9, 9);
-    }
-    old_x = new_x;
-    old_y = new_y;
-    fbfront_drawvert(new_x, new_y + 1, new_y + 8, 0xffffffff);
-    fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
-    fbfront_update(fb_dev, new_x, new_y, 9, 9);
-}
-
-static struct kbdfront_dev *kbd_dev;
-static void kbdfront_thread(void *p)
-{
-    DEFINE_WAIT(w);
-    DEFINE_WAIT(w2);
-    int x = WIDTH / 2, y = HEIGHT / 2, z = 0;
-
-    kbd_dev = init_kbdfront(NULL, 1);
-    if (!kbd_dev)
-        return;
-
-    down(&fbfront_sem);
-    refresh_cursor(x, y);
-    while (1) {
-        union xenkbd_in_event kbdevent;
-        union xenfb_in_event fbevent;
-        int sleep = 1;
-
-        add_waiter(w, kbdfront_queue);
-        add_waiter(w2, fbfront_queue);
-
-        while (kbdfront_receive(kbd_dev, &kbdevent, 1) != 0) {
-            sleep = 0;
-            switch(kbdevent.type) {
-            case XENKBD_TYPE_MOTION:
-                printk("motion x:%d y:%d z:%d\n",
-                        kbdevent.motion.rel_x,
-                        kbdevent.motion.rel_y,
-                        kbdevent.motion.rel_z);
-                x += kbdevent.motion.rel_x;
-                y += kbdevent.motion.rel_y;
-                z += kbdevent.motion.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_POS:
-                printk("pos x:%d y:%d dz:%d\n",
-                        kbdevent.pos.abs_x,
-                        kbdevent.pos.abs_y,
-                        kbdevent.pos.rel_z);
-                x = kbdevent.pos.abs_x;
-                y = kbdevent.pos.abs_y;
-                z = kbdevent.pos.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_KEY:
-                printk("key %d %s\n",
-                        kbdevent.key.keycode,
-                        kbdevent.key.pressed ? "pressed" : "released");
-                if (kbdevent.key.keycode == BTN_LEFT) {
-                    printk("mouse %s at (%d,%d,%d)\n",
-                            kbdevent.key.pressed ? "clic" : "release", x, y, z);
-                    if (kbdevent.key.pressed) {
-                        uint32_t color = rand();
-                        fbfront_drawvert(x - 16, y - 16, y + 15, color);
-                        fbfront_drawhoriz(x - 16, x + 15, y + 16, color);
-                        fbfront_drawvert(x + 16, y - 15, y + 16, color);
-                        fbfront_drawhoriz(x - 15, x + 16, y - 16, color);
-                        fbfront_update(fb_dev, x - 16, y - 16, 33, 33);
-                    }
-                } else if (kbdevent.key.keycode == KEY_Q) {
-                    struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_poweroff };
-                    HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-                    do_exit();
-                }
-                break;
-            }
-        }
-        while (fbfront_receive(fb_dev, &fbevent, 1) != 0) {
-            sleep = 0;
-            switch(fbevent.type) {
-            case XENFB_TYPE_REFRESH_PERIOD:
-                refresh_period = fbevent.refresh_period.period;
-                printk("refresh period %d\n", refresh_period);
-                refresh_cursor(x, y);
-                break;
-            }
-        }
-        if (sleep)
-            schedule();
-    }
-}
-
-static struct pcifront_dev *pci_dev;
-
-static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
-{
-    unsigned int vendor, device, rev, class;
-
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x00, 2, &vendor);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x02, 2, &device);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x08, 1, &rev);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x0a, 2, &class);
-
-    printk("%04x:%02x:%02x.%02x %04x: %04x:%04x (rev %02x)\n", domain, bus, slot, fun, class, vendor, device, rev);
-}
-
-static void pcifront_thread(void *p)
-{
-    pcifront_watches(NULL);
-    pci_dev = init_pcifront(NULL);
-    if (!pci_dev)
-        return;
-    printk("PCI devices:\n");
-    pcifront_scan(pci_dev, print_pcidev);
-}
-
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
 {
     printk("Dummy main: start_info=%p\n", si);
-    create_thread("xenbus_tester", xenbus_tester, si);
-    create_thread("periodic_thread", periodic_thread, si);
-    create_thread("netfront", netfront_thread, si);
-    create_thread("blkfront", blkfront_thread, si);
-    create_thread("fbfront", fbfront_thread, si);
-    create_thread("kbdfront", kbdfront_thread, si);
-    create_thread("pcifront", pcifront_thread, si);
     return 0;
 }
 
@@ -534,21 +135,6 @@ void start_kernel(start_info_t *si)
 
 void stop_kernel(void)
 {
-    if (net_dev)
-        shutdown_netfront(net_dev);
-
-    if (blk_dev)
-        shutdown_blkfront(blk_dev);
-
-    if (fb_dev)
-        shutdown_fbfront(fb_dev);
-
-    if (kbd_dev)
-        shutdown_kbdfront(kbd_dev);
-
-    if (pci_dev)
-        shutdown_pcifront(pci_dev);
-
     /* TODO: fs import */
 
     local_irq_disable();
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/test.c
similarity index 80%
copy from extras/mini-os/kernel.c
copy to extras/mini-os/test.c
index 2875bf1..9039cb3 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/test.c
@@ -1,8 +1,7 @@
 /******************************************************************************
- * kernel.c
+ * test.c
  * 
- * Assorted crap goes here, including the initial C entry point, jumped at
- * from head.S.
+ * Test code for all the various frontends; split from kernel.c
  * 
  * Copyright (c) 2002-2003, K A Fraser & R Neugebauer
  * Copyright (c) 2005, Grzegorz Milos, Intel Research Cambridge
@@ -48,24 +47,6 @@
 
 static struct netfront_dev *net_dev;
 
-uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
-
-void setup_xen_features(void)
-{
-    xen_feature_info_t fi;
-    int i, j;
-
-    for (i = 0; i < XENFEAT_NR_SUBMAPS; i++) 
-    {
-        fi.submap_idx = i;
-        if (HYPERVISOR_xen_version(XENVER_get_features, &fi) < 0)
-            break;
-        
-        for (j=0; j<32; j++)
-            xen_features[i*32+j] = !!(fi.submap & 1<<j);
-    }
-}
-
 void test_xenbus(void);
 
 static void xenbus_tester(void *p)
@@ -456,10 +437,9 @@ static void pcifront_thread(void *p)
     pcifront_scan(pci_dev, print_pcidev);
 }
 
-/* This should be overridden by the application we are linked against. */
-__attribute__((weak)) int app_main(start_info_t *si)
+int app_main(start_info_t *si)
 {
-    printk("Dummy main: start_info=%p\n", si);
+    printk("Test main: start_info=%p\n", si);
     create_thread("xenbus_tester", xenbus_tester, si);
     create_thread("periodic_thread", periodic_thread, si);
     create_thread("netfront", netfront_thread, si);
@@ -470,69 +450,7 @@ __attribute__((weak)) int app_main(start_info_t *si)
     return 0;
 }
 
-/*
- * INITIAL C ENTRY POINT.
- */
-void start_kernel(start_info_t *si)
-{
-    static char hello[] = "Bootstrapping...\n";
-
-    (void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
-
-    arch_init(si);
-
-    trap_init();
-
-    /* print out some useful information  */
-    printk("Xen Minimal OS!\n");
-    printk("  start_info: %p(VA)\n", si);
-    printk("    nr_pages: 0x%lx\n", si->nr_pages);
-    printk("  shared_inf: 0x%08lx(MA)\n", si->shared_info);
-    printk("     pt_base: %p(VA)\n", (void *)si->pt_base); 
-    printk("nr_pt_frames: 0x%lx\n", si->nr_pt_frames);
-    printk("    mfn_list: %p(VA)\n", (void *)si->mfn_list); 
-    printk("   mod_start: 0x%lx(VA)\n", si->mod_start);
-    printk("     mod_len: %lu\n", si->mod_len); 
-    printk("       flags: 0x%x\n", (unsigned int)si->flags);
-    printk("    cmd_line: %s\n",  
-           si->cmd_line ? (const char *)si->cmd_line : "NULL");
-
-    /* Set up events. */
-    init_events();
-    
-    /* ENABLE EVENT DELIVERY. This is disabled at start of day. */
-    __sti();
-
-    arch_print_info();
-
-    setup_xen_features();
-
-    /* Init memory management. */
-    init_mm();
-
-    /* Init time and timers. */
-    init_time();
-
-    /* Init the console driver. */
-    init_console();
-
-    /* Init grant tables */
-    init_gnttab();
-    
-    /* Init scheduler. */
-    init_sched();
- 
-    /* Init XenBus */
-    init_xenbus();
-
-    /* Call (possibly overridden) app_main() */
-    app_main(&start_info);
-
-    /* Everything initialised, start idle thread */
-    run_idle_thread();
-}
-
-void stop_kernel(void)
+void shutdown_frontends(void)
 {
     if (net_dev)
         shutdown_netfront(net_dev);
@@ -548,51 +466,4 @@ void stop_kernel(void)
 
     if (pci_dev)
         shutdown_pcifront(pci_dev);
-
-    /* TODO: fs import */
-
-    local_irq_disable();
-
-    /* Reset grant tables */
-    fini_gnttab();
-
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
-    /* Reset XenBus */
-    fini_xenbus();
-
-    /* Reset timers */
-    fini_time();
-
-    /* Reset memory management. */
-    fini_mm();
-
-    /* Reset events. */
-    fini_events();
-
-    /* Reset traps */
-    trap_fini();
-
-    /* Reset arch details */
-    arch_fini();
-}
-
-/*
- * do_exit: This is called whenever an IRET fails in entry.S.
- * This will generally be because an application has got itself into
- * a really bad state (probably a bad CS or SS). It must be killed.
- * Of course, minimal OS doesn't have applications :-)
- */
-
-void do_exit(void)
-{
-    printk("Do_exit called!\n");
-    stack_walk();
-    for( ;; )
-    {
-        struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_crash };
-        HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-    }
 }
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/c/minios.cfg
+++ b/stubdom/c/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/caml/minios.cfg
+++ b/stubdom/caml/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zS-0008Lc-I3; Wed, 25 Jan 2012 14:38:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zQ-0008Is-9L
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:20 +0000
Received: from [85.158.138.51:28690] by server-3.bemta-3.messagelabs.com id
	E8/8D-26314-BD3102F4; Wed, 25 Jan 2012 14:38:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327502296!10459224!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32362 invoked from network); 25 Jan 2012 14:38:16 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-16.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:16 -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
	q0PEcChp004118; Wed, 25 Jan 2012 14:38: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 q0PEcCwv011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:42 -0500
Message-Id: <1327502278-1790-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 07/23] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  158 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 210 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..5f609de 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,163 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    gnttab_setup_table_t setup;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+    unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+    if (gmfnp == NULL)
+        return -1;
+
+    setup.dom = domid;
+    setup.nr_frames = 1;
+    set_xen_guest_handle(setup.frame_list, gmfnp);
+    setup.status = 0;
+
+    rc = xc_gnttab_op(xch, GNTTABOP_setup_table, &setup, sizeof(setup), 1);
+    gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+        .domid = domid,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..8bee684 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..3bd5549 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3828c62..28646e0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -224,7 +224,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -250,6 +252,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -263,7 +269,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -296,6 +303,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -349,7 +358,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -387,7 +398,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zX-0008SI-Ka; Wed, 25 Jan 2012 14:38:27 +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 1Rq3zS-0008Hs-Gz
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327502227!62444517!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32161 invoked from network); 25 Jan 2012 14:37:07 -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;
	25 Jan 2012 14:37: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
	q0PEcCUH003891; Wed, 25 Jan 2012 14:38: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 q0PEcCwq011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:37 -0500
Message-Id: <1327502278-1790-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/23] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   66 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 154 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 37b0fd6..2ffdd85 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -749,6 +749,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index fd20210..500c7a2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -86,7 +86,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -480,7 +480,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -621,7 +621,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -680,7 +680,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 5b0fc4a..8001a91 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -995,6 +995,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..43bd167 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,68 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++)
+    {
+        if (global_virq_handlers[virq] == d)
+        {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count)
+    {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1222,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..6560182 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -288,7 +288,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -315,7 +315,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 232d50e..40b8a7a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,11 +23,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..e3cae60 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..acf9c8a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..543dc77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zR-0008Kh-KU; Wed, 25 Jan 2012 14:38:21 +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 1Rq3zQ-0008HJ-26
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327502293!12530576!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10158 invoked from network); 25 Jan 2012 14:38:14 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-8.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:38:14 -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
	q0PEcCUH003892
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCws011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:39 -0500
Message-Id: <1327502278-1790-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/23] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 8001a91..904fb45 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -264,6 +264,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index acf9c8a..d99f886 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zV-0008PG-Pl; Wed, 25 Jan 2012 14:38:25 +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 1Rq3zR-0008Hf-EB
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327502293!9782345!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25877 invoked from network); 25 Jan 2012 14:38:14 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 14:38:14 -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
	q0PEcCUH003895
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx1011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:46 -0500
Message-Id: <1327502278-1790-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 11/23] mini-os: Move test functions into test.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

While useful, these test functions should not be compiled into every
mini-os instance that we compile.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile             |    1 +
 extras/mini-os/kernel.c             |  414 -----------------------------------
 extras/mini-os/{kernel.c => test.c} |  139 +-----------
 stubdom/c/minios.cfg                |    1 +
 stubdom/caml/minios.cfg             |    1 +
 5 files changed, 8 insertions(+), 548 deletions(-)
 copy extras/mini-os/{kernel.c => test.c} (80%)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index be38170..96c661a 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -63,6 +63,7 @@ src-y += mm.c
 src-y += netfront.c
 src-y += pcifront.c
 src-y += sched.c
+src-$(CONFIG_TEST) += test.c
 
 src-y += lib/ctype.c
 src-y += lib/math.c
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index 2875bf1..c8b9b8c 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -46,8 +46,6 @@
 #include <xen/features.h>
 #include <xen/version.h>
 
-static struct netfront_dev *net_dev;
-
 uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
 
 void setup_xen_features(void)
@@ -66,407 +64,10 @@ void setup_xen_features(void)
     }
 }
 
-void test_xenbus(void);
-
-static void xenbus_tester(void *p)
-{
-    printk("Xenbus tests disabled, because of a Xend bug.\n");
-    /* test_xenbus(); */
-}
-
-static void periodic_thread(void *p)
-{
-    struct timeval tv;
-    printk("Periodic thread started.\n");
-    for(;;)
-    {
-        gettimeofday(&tv, NULL);
-        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
-        msleep(1000);
-    }
-}
-
-static void netfront_thread(void *p)
-{
-    net_dev = init_netfront(NULL, NULL, NULL, NULL);
-}
-
-static struct blkfront_dev *blk_dev;
-static struct blkfront_info blk_info;
-static uint64_t blk_size_read;
-static uint64_t blk_size_write;
-
-struct blk_req {
-    struct blkfront_aiocb aiocb;
-    int rand_value;
-    struct blk_req *next;
-};
-
-#ifdef BLKTEST_WRITE
-static struct blk_req *blk_to_read;
-#endif
-
-static struct blk_req *blk_alloc_req(uint64_t sector)
-{
-    struct blk_req *req = xmalloc(struct blk_req);
-    req->aiocb.aio_dev = blk_dev;
-    req->aiocb.aio_buf = _xmalloc(blk_info.sector_size, blk_info.sector_size);
-    req->aiocb.aio_nbytes = blk_info.sector_size;
-    req->aiocb.aio_offset = sector * blk_info.sector_size;
-    req->aiocb.data = req;
-    req->next = NULL;
-    return req;
-}
-
-static void blk_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret)
-        printk("got error code %d when reading at offset %ld\n", ret, aiocb->aio_offset);
-    else
-        blk_size_read += blk_info.sector_size;
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_read_sector(uint64_t sector)
-{
-    struct blk_req *req;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_read_completed;
-
-    blkfront_aio_read(&req->aiocb);
-}
-
-#ifdef BLKTEST_WRITE
-static void blk_write_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    int rand_value;
-    int i;
-    int *buf;
-
-    if (ret) {
-        printk("got error code %d when reading back at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_read += blk_info.sector_size;
-    buf = (int*) aiocb->aio_buf;
-    rand_value = req->rand_value;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        if (buf[i] != rand_value) {
-            printk("bogus data at offset %ld\n", aiocb->aio_offset + i);
-            break;
-        }
-        rand_value *= RAND_MIX;
-    }
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_write_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret) {
-        printk("got error code %d when writing at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_write += blk_info.sector_size;
-    /* Push write check */
-    req->next = blk_to_read;
-    blk_to_read = req;
-}
-
-static void blk_write_sector(uint64_t sector)
-{
-    struct blk_req *req;
-    int rand_value;
-    int i;
-    int *buf;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_write_completed;
-    req->rand_value = rand_value = rand();
-
-    buf = (int*) req->aiocb.aio_buf;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        buf[i] = rand_value;
-        rand_value *= RAND_MIX;
-    }
-
-    blkfront_aio_write(&req->aiocb);
-}
-#endif
-
-static void blkfront_thread(void *p)
-{
-    time_t lasttime = 0;
-
-    blk_dev = init_blkfront(NULL, &blk_info);
-    if (!blk_dev)
-        return;
-
-    if (blk_info.info & VDISK_CDROM)
-        printk("Block device is a CDROM\n");
-    if (blk_info.info & VDISK_REMOVABLE)
-        printk("Block device is removable\n");
-    if (blk_info.info & VDISK_READONLY)
-        printk("Block device is read-only\n");
-
-#ifdef BLKTEST_WRITE
-    if (blk_info.mode == O_RDWR) {
-        blk_write_sector(0);
-        blk_write_sector(blk_info.sectors-1);
-    } else
-#endif
-    {
-        blk_read_sector(0);
-        blk_read_sector(blk_info.sectors-1);
-    }
-
-    while (1) {
-        uint64_t sector = rand() % blk_info.sectors;
-        struct timeval tv;
-#ifdef BLKTEST_WRITE
-        if (blk_info.mode == O_RDWR)
-            blk_write_sector(sector);
-        else
-#endif
-            blk_read_sector(sector);
-        blkfront_aio_poll(blk_dev);
-        gettimeofday(&tv, NULL);
-        if (tv.tv_sec > lasttime + 10) {
-            printk("%llu read, %llu write\n", blk_size_read, blk_size_write);
-            lasttime = tv.tv_sec;
-        }
-
-#ifdef BLKTEST_WRITE
-        while (blk_to_read) {
-            struct blk_req *req = blk_to_read;
-            blk_to_read = blk_to_read->next;
-            req->aiocb.aio_cb = blk_write_read_completed;
-            blkfront_aio_read(&req->aiocb);
-        }
-#endif
-    }
-}
-
-#define WIDTH 800
-#define HEIGHT 600
-#define DEPTH 32
-
-static uint32_t *fb;
-static int refresh_period = 50;
-static struct fbfront_dev *fb_dev;
-static struct semaphore fbfront_sem = __SEMAPHORE_INITIALIZER(fbfront_sem, 0);
-
-static void fbfront_drawvert(int x, int y1, int y2, uint32_t color)
-{
-    int y;
-    if (x < 0)
-        return;
-    if (x >= WIDTH)
-        return;
-    if (y1 < 0)
-        y1 = 0;
-    if (y2 >= HEIGHT)
-        y2 = HEIGHT-1;
-    for (y = y1; y <= y2; y++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_drawhoriz(int x1, int x2, int y, uint32_t color)
-{
-    int x;
-    if (y < 0)
-        return;
-    if (y >= HEIGHT)
-        return;
-    if (x1 < 0)
-        x1 = 0;
-    if (x2 >= WIDTH)
-        x2 = WIDTH-1;
-    for (x = x1; x <= x2; x++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_thread(void *p)
-{
-    size_t line_length = WIDTH * (DEPTH / 8);
-    size_t memsize = HEIGHT * line_length;
-    unsigned long *mfns;
-    int i, n = (memsize + PAGE_SIZE-1) / PAGE_SIZE;
-
-    memsize = n * PAGE_SIZE;
-    fb = _xmalloc(memsize, PAGE_SIZE);
-    memset(fb, 0, memsize);
-    mfns = xmalloc_array(unsigned long, n);
-    for (i = 0; i < n; i++)
-        mfns[i] = virtual_to_mfn((char *) fb + i * PAGE_SIZE);
-    fb_dev = init_fbfront(NULL, mfns, WIDTH, HEIGHT, DEPTH, line_length, n);
-    xfree(mfns);
-    if (!fb_dev) {
-        xfree(fb);
-        return;
-    }
-    up(&fbfront_sem);
-}
-
-static void clip_cursor(int *x, int *y)
-{
-    if (*x < 0)
-        *x = 0;
-    if (*x >= WIDTH)
-        *x = WIDTH - 1;
-    if (*y < 0)
-        *y = 0;
-    if (*y >= HEIGHT)
-        *y = HEIGHT - 1;
-}
-
-static void refresh_cursor(int new_x, int new_y)
-{
-    static int old_x = -1, old_y = -1;
-
-    if (!refresh_period)
-        return;
-
-    if (old_x != -1 && old_y != -1) {
-        fbfront_drawvert(old_x, old_y + 1, old_y + 8, 0xffffffff);
-        fbfront_drawhoriz(old_x + 1, old_x + 8, old_y, 0xffffffff);
-        fbfront_update(fb_dev, old_x, old_y, 9, 9);
-    }
-    old_x = new_x;
-    old_y = new_y;
-    fbfront_drawvert(new_x, new_y + 1, new_y + 8, 0xffffffff);
-    fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
-    fbfront_update(fb_dev, new_x, new_y, 9, 9);
-}
-
-static struct kbdfront_dev *kbd_dev;
-static void kbdfront_thread(void *p)
-{
-    DEFINE_WAIT(w);
-    DEFINE_WAIT(w2);
-    int x = WIDTH / 2, y = HEIGHT / 2, z = 0;
-
-    kbd_dev = init_kbdfront(NULL, 1);
-    if (!kbd_dev)
-        return;
-
-    down(&fbfront_sem);
-    refresh_cursor(x, y);
-    while (1) {
-        union xenkbd_in_event kbdevent;
-        union xenfb_in_event fbevent;
-        int sleep = 1;
-
-        add_waiter(w, kbdfront_queue);
-        add_waiter(w2, fbfront_queue);
-
-        while (kbdfront_receive(kbd_dev, &kbdevent, 1) != 0) {
-            sleep = 0;
-            switch(kbdevent.type) {
-            case XENKBD_TYPE_MOTION:
-                printk("motion x:%d y:%d z:%d\n",
-                        kbdevent.motion.rel_x,
-                        kbdevent.motion.rel_y,
-                        kbdevent.motion.rel_z);
-                x += kbdevent.motion.rel_x;
-                y += kbdevent.motion.rel_y;
-                z += kbdevent.motion.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_POS:
-                printk("pos x:%d y:%d dz:%d\n",
-                        kbdevent.pos.abs_x,
-                        kbdevent.pos.abs_y,
-                        kbdevent.pos.rel_z);
-                x = kbdevent.pos.abs_x;
-                y = kbdevent.pos.abs_y;
-                z = kbdevent.pos.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_KEY:
-                printk("key %d %s\n",
-                        kbdevent.key.keycode,
-                        kbdevent.key.pressed ? "pressed" : "released");
-                if (kbdevent.key.keycode == BTN_LEFT) {
-                    printk("mouse %s at (%d,%d,%d)\n",
-                            kbdevent.key.pressed ? "clic" : "release", x, y, z);
-                    if (kbdevent.key.pressed) {
-                        uint32_t color = rand();
-                        fbfront_drawvert(x - 16, y - 16, y + 15, color);
-                        fbfront_drawhoriz(x - 16, x + 15, y + 16, color);
-                        fbfront_drawvert(x + 16, y - 15, y + 16, color);
-                        fbfront_drawhoriz(x - 15, x + 16, y - 16, color);
-                        fbfront_update(fb_dev, x - 16, y - 16, 33, 33);
-                    }
-                } else if (kbdevent.key.keycode == KEY_Q) {
-                    struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_poweroff };
-                    HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-                    do_exit();
-                }
-                break;
-            }
-        }
-        while (fbfront_receive(fb_dev, &fbevent, 1) != 0) {
-            sleep = 0;
-            switch(fbevent.type) {
-            case XENFB_TYPE_REFRESH_PERIOD:
-                refresh_period = fbevent.refresh_period.period;
-                printk("refresh period %d\n", refresh_period);
-                refresh_cursor(x, y);
-                break;
-            }
-        }
-        if (sleep)
-            schedule();
-    }
-}
-
-static struct pcifront_dev *pci_dev;
-
-static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
-{
-    unsigned int vendor, device, rev, class;
-
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x00, 2, &vendor);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x02, 2, &device);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x08, 1, &rev);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x0a, 2, &class);
-
-    printk("%04x:%02x:%02x.%02x %04x: %04x:%04x (rev %02x)\n", domain, bus, slot, fun, class, vendor, device, rev);
-}
-
-static void pcifront_thread(void *p)
-{
-    pcifront_watches(NULL);
-    pci_dev = init_pcifront(NULL);
-    if (!pci_dev)
-        return;
-    printk("PCI devices:\n");
-    pcifront_scan(pci_dev, print_pcidev);
-}
-
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
 {
     printk("Dummy main: start_info=%p\n", si);
-    create_thread("xenbus_tester", xenbus_tester, si);
-    create_thread("periodic_thread", periodic_thread, si);
-    create_thread("netfront", netfront_thread, si);
-    create_thread("blkfront", blkfront_thread, si);
-    create_thread("fbfront", fbfront_thread, si);
-    create_thread("kbdfront", kbdfront_thread, si);
-    create_thread("pcifront", pcifront_thread, si);
     return 0;
 }
 
@@ -534,21 +135,6 @@ void start_kernel(start_info_t *si)
 
 void stop_kernel(void)
 {
-    if (net_dev)
-        shutdown_netfront(net_dev);
-
-    if (blk_dev)
-        shutdown_blkfront(blk_dev);
-
-    if (fb_dev)
-        shutdown_fbfront(fb_dev);
-
-    if (kbd_dev)
-        shutdown_kbdfront(kbd_dev);
-
-    if (pci_dev)
-        shutdown_pcifront(pci_dev);
-
     /* TODO: fs import */
 
     local_irq_disable();
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/test.c
similarity index 80%
copy from extras/mini-os/kernel.c
copy to extras/mini-os/test.c
index 2875bf1..9039cb3 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/test.c
@@ -1,8 +1,7 @@
 /******************************************************************************
- * kernel.c
+ * test.c
  * 
- * Assorted crap goes here, including the initial C entry point, jumped at
- * from head.S.
+ * Test code for all the various frontends; split from kernel.c
  * 
  * Copyright (c) 2002-2003, K A Fraser & R Neugebauer
  * Copyright (c) 2005, Grzegorz Milos, Intel Research Cambridge
@@ -48,24 +47,6 @@
 
 static struct netfront_dev *net_dev;
 
-uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
-
-void setup_xen_features(void)
-{
-    xen_feature_info_t fi;
-    int i, j;
-
-    for (i = 0; i < XENFEAT_NR_SUBMAPS; i++) 
-    {
-        fi.submap_idx = i;
-        if (HYPERVISOR_xen_version(XENVER_get_features, &fi) < 0)
-            break;
-        
-        for (j=0; j<32; j++)
-            xen_features[i*32+j] = !!(fi.submap & 1<<j);
-    }
-}
-
 void test_xenbus(void);
 
 static void xenbus_tester(void *p)
@@ -456,10 +437,9 @@ static void pcifront_thread(void *p)
     pcifront_scan(pci_dev, print_pcidev);
 }
 
-/* This should be overridden by the application we are linked against. */
-__attribute__((weak)) int app_main(start_info_t *si)
+int app_main(start_info_t *si)
 {
-    printk("Dummy main: start_info=%p\n", si);
+    printk("Test main: start_info=%p\n", si);
     create_thread("xenbus_tester", xenbus_tester, si);
     create_thread("periodic_thread", periodic_thread, si);
     create_thread("netfront", netfront_thread, si);
@@ -470,69 +450,7 @@ __attribute__((weak)) int app_main(start_info_t *si)
     return 0;
 }
 
-/*
- * INITIAL C ENTRY POINT.
- */
-void start_kernel(start_info_t *si)
-{
-    static char hello[] = "Bootstrapping...\n";
-
-    (void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
-
-    arch_init(si);
-
-    trap_init();
-
-    /* print out some useful information  */
-    printk("Xen Minimal OS!\n");
-    printk("  start_info: %p(VA)\n", si);
-    printk("    nr_pages: 0x%lx\n", si->nr_pages);
-    printk("  shared_inf: 0x%08lx(MA)\n", si->shared_info);
-    printk("     pt_base: %p(VA)\n", (void *)si->pt_base); 
-    printk("nr_pt_frames: 0x%lx\n", si->nr_pt_frames);
-    printk("    mfn_list: %p(VA)\n", (void *)si->mfn_list); 
-    printk("   mod_start: 0x%lx(VA)\n", si->mod_start);
-    printk("     mod_len: %lu\n", si->mod_len); 
-    printk("       flags: 0x%x\n", (unsigned int)si->flags);
-    printk("    cmd_line: %s\n",  
-           si->cmd_line ? (const char *)si->cmd_line : "NULL");
-
-    /* Set up events. */
-    init_events();
-    
-    /* ENABLE EVENT DELIVERY. This is disabled at start of day. */
-    __sti();
-
-    arch_print_info();
-
-    setup_xen_features();
-
-    /* Init memory management. */
-    init_mm();
-
-    /* Init time and timers. */
-    init_time();
-
-    /* Init the console driver. */
-    init_console();
-
-    /* Init grant tables */
-    init_gnttab();
-    
-    /* Init scheduler. */
-    init_sched();
- 
-    /* Init XenBus */
-    init_xenbus();
-
-    /* Call (possibly overridden) app_main() */
-    app_main(&start_info);
-
-    /* Everything initialised, start idle thread */
-    run_idle_thread();
-}
-
-void stop_kernel(void)
+void shutdown_frontends(void)
 {
     if (net_dev)
         shutdown_netfront(net_dev);
@@ -548,51 +466,4 @@ void stop_kernel(void)
 
     if (pci_dev)
         shutdown_pcifront(pci_dev);
-
-    /* TODO: fs import */
-
-    local_irq_disable();
-
-    /* Reset grant tables */
-    fini_gnttab();
-
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
-    /* Reset XenBus */
-    fini_xenbus();
-
-    /* Reset timers */
-    fini_time();
-
-    /* Reset memory management. */
-    fini_mm();
-
-    /* Reset events. */
-    fini_events();
-
-    /* Reset traps */
-    trap_fini();
-
-    /* Reset arch details */
-    arch_fini();
-}
-
-/*
- * do_exit: This is called whenever an IRET fails in entry.S.
- * This will generally be because an application has got itself into
- * a really bad state (probably a bad CS or SS). It must be killed.
- * Of course, minimal OS doesn't have applications :-)
- */
-
-void do_exit(void)
-{
-    printk("Do_exit called!\n");
-    stack_walk();
-    for( ;; )
-    {
-        struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_crash };
-        HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-    }
 }
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/c/minios.cfg
+++ b/stubdom/c/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/caml/minios.cfg
+++ b/stubdom/caml/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zS-0008Lc-I3; Wed, 25 Jan 2012 14:38:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zQ-0008Is-9L
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:20 +0000
Received: from [85.158.138.51:28690] by server-3.bemta-3.messagelabs.com id
	E8/8D-26314-BD3102F4; Wed, 25 Jan 2012 14:38:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327502296!10459224!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32362 invoked from network); 25 Jan 2012 14:38:16 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-16.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:16 -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
	q0PEcChp004118; Wed, 25 Jan 2012 14:38: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 q0PEcCwv011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:42 -0500
Message-Id: <1327502278-1790-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 07/23] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  158 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 210 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..5f609de 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,163 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    gnttab_setup_table_t setup;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+    unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+    if (gmfnp == NULL)
+        return -1;
+
+    setup.dom = domid;
+    setup.nr_frames = 1;
+    set_xen_guest_handle(setup.frame_list, gmfnp);
+    setup.status = 0;
+
+    rc = xc_gnttab_op(xch, GNTTABOP_setup_table, &setup, sizeof(setup), 1);
+    gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+        .domid = domid,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..8bee684 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..3bd5549 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3828c62..28646e0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -224,7 +224,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -250,6 +252,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -263,7 +269,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -296,6 +303,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -349,7 +358,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -387,7 +398,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zS-0008Lu-UY; Wed, 25 Jan 2012 14:38:22 +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 1Rq3zQ-0008HS-Sl
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327502294!12496785!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19256 invoked from network); 25 Jan 2012 14:38:14 -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;
	25 Jan 2012 14:38:14 -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
	q0PEcDUH003904
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCxA011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:55 -0500
Message-Id: <1327502278-1790-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 20/23] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   11 +++++++++++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 7564edd..dee7bbd 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1804,6 +1804,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1817,6 +1818,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1871,6 +1873,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 435f76a..6a0dbc2 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -602,6 +602,17 @@ void restore_existing_connections(void)
 #ifdef __MINIOS__
 static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zG-0008Gn-Gm; Wed, 25 Jan 2012 14:38:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rq3zE-0008Ga-FT
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:09 +0000
Received: from [85.158.138.51:9601] by server-7.bemta-3.messagelabs.com id
	83/6F-31267-FC3102F4; Wed, 25 Jan 2012 14:38:07 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327502277!10459159!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30886 invoked from network); 25 Jan 2012 14:37:58 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:37:58 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75015449; Wed, 25 Jan 2012 15:37:55 +0100
Message-ID: <1327502273.2723.19.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:37:53 +0100
In-Reply-To: <1327500920.2723.11.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv3 1 of 2] libxl: extend pCPUs specification for
	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4175367600534927591=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4175367600534927591==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-k+39NQ5VqV2/znaiDeQU"


--=-k+39NQ5VqV2/znaiDeQU
Content-Type: multipart/mixed; boundary="=-fTs9J/Zljhf/O4TV79Dv"


--=-fTs9J/Zljhf/O4TV79Dv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[Resending with patch attached, in case the client mangled the body of =20
the message (although it really shouldn't!)]=20

Allow for "^<cpuid>" syntax while specifying the pCPUs list
during a vcpu-pin. This enables doing the following:

 xl vcpu-pin 1 1 0-4,^2

and achieving:

 xl vcpu-list
 Name                                ID  VCPU   CPU State   Time(s) CPU Aff=
inity
 ...
 Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
 ...

Negative ranges are also supported, such as "0-4,^1-2" to
mean "0,3-4"

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r a2a8089b1ffb tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Tue Jan 24 16:46:17 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Wed Jan 25 11:40:22 2012 +0000
@@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
+#define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
+                                             if (libxl_cpumap_test(&(m), v=
))
=20
 int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
=20
diff -r a2a8089b1ffb tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 24 16:46:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 11:40:22 2012 +0000
@@ -3503,13 +3503,72 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb, *saveptr =3D NULL;
+    int i, rc =3D 0, rmcpu;
+
+    if (!strcmp(cpu, "all")) {
+        memset(cpumap->map, -1, cpumap->size);
+        return 0;
+    }
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+        return ENOMEM;
+    }
+
+    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
+         toka =3D strtok_r(NULL, ",", &saveptr)) {
+        rmcpu =3D 0;
+        if (*toka =3D=3D '^') {
+            /* This (These) Cpu(s) will be removed from the map */
+            toka++;
+            rmcpu =3D 1;
+        }
+        /* Extract a valid (range of) cpu(s) */
+        cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
+        if (endptr =3D=3D toka) {
+            fprintf(stderr, "Error: Invalid argument.\n");
+            rc =3D EINVAL;
+            goto vcpp_out;
+        }
+        if (*endptr =3D=3D '-') {
+            tokb =3D endptr + 1;
+            cpuidb =3D strtoul(tokb, &endptr, 10);
+            if (endptr =3D=3D tokb || cpuida > cpuidb) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                rc =3D EINVAL;
+                goto vcpp_out;
+            }
+        }
+        while (cpuida <=3D cpuidb) {
+            rmcpu =3D=3D 0 ? libxl_cpumap_set(cpumap, cpuida) :
+                         libxl_cpumap_set(&exclude_cpumap, cpuida);
+            cpuida++;
+        }
+    }
+
+    /* Clear all the cpus from the removal list */
+    libxl_for_each_set_cpu(i, exclude_cpumap) {
+        libxl_cpumap_reset(cpumap, i);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return rc;
+}
+
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_cpumap cpumap;
=20
-    uint32_t vcpuid, cpuida, cpuidb;
-    char *endptr, *toka, *tokb;
+    uint32_t vcpuid;
+    char *endptr;
     int i, nb_vcpu;
=20
     vcpuid =3D strtoul(vcpu, &endptr, 10);
@@ -3526,32 +3585,9 @@ static void vcpupin(const char *d, const
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
-    if (strcmp(cpu, "all")) {
-        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
-            cpuida =3D strtoul(toka, &endptr, 10);
-            if (toka =3D=3D endptr) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                goto vcpupin_out1;
-            }
-            if (*endptr =3D=3D '-') {
-                tokb =3D endptr + 1;
-                cpuidb =3D strtoul(tokb, &endptr, 10);
-                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
-                    fprintf(stderr, "Error: Invalid argument.\n");
-                    goto vcpupin_out1;
-                }
-                while (cpuida <=3D cpuidb) {
-                    libxl_cpumap_set(&cpumap, cpuida);
-                    ++cpuida;
-                }
-            } else {
-                libxl_cpumap_set(&cpumap, cpuida);
-            }
-        }
-    }
-    else {
-        memset(cpumap.map, -1, cpumap.size);
-    }
+
+    if (vcpupin_parse(cpu, &cpumap))
+        goto vcpupin_out1;
=20
     if (vcpuid !=3D -1) {
         if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) =3D=3D -1)=
 {

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)




--=-fTs9J/Zljhf/O4TV79Dv
Content-Disposition: attachment; filename="generalize-vcpupin-parsig.patch"
Content-Type: text/x-patch; name="generalize-vcpupin-parsig.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGEyYTgwODliMWZmYmY1NzU3Y2EzMTkxY2I4
Zjc0YTVmMWVkN2ZlZDENCmxpYnhsOiBleHRlbmQgcENQVXMgc3BlY2lmaWNhdGlvbiBmb3IgdmNw
dS1waW4uDQoNCkFsbG93IGZvciAiXjxjcHVpZD4iIHN5bnRheCB3aGlsZSBzcGVjaWZ5aW5nIHRo
ZSBwQ1BVcyBsaXN0DQpkdXJpbmcgYSB2Y3B1LXBpbi4gVGhpcyBlbmFibGVzIGRvaW5nIHRoZSBm
b2xsb3dpbmc6DQoNCiB4bCB2Y3B1LXBpbiAxIDEgMC00LF4yDQoNCmFuZCBhY2hpZXZpbmc6DQoN
CiB4bCB2Y3B1LWxpc3QNCiBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAg
VkNQVSAgIENQVSBTdGF0ZSAgIFRpbWUocykgQ1BVIEFmZmluaXR5DQogLi4uDQogU3F1ZWV6ZV9w
diAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgIDEgICAgMyAgIC1iLSAgICAgICAyLjQg
IDAtMSwzLTQNCiAuLi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZh
Z2dpb2xpQGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgYTJhODA4OWIxZmZiIHRvb2xzL2xpYnhsL2xp
YnhsX3V0aWxzLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgJVHVlIEphbiAyNCAx
Njo0NjoxNyAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF91dGlscy5oCVdlZCBK
YW4gMjUgMTE6NDA6MjIgMjAxMiArMDAwMA0KQEAgLTcxLDYgKzcxLDggQEAgaW50IGxpYnhsX2Nw
dW1hcF90ZXN0KGxpYnhsX2NwdW1hcCAqY3B1bQ0KIHZvaWQgbGlieGxfY3B1bWFwX3NldChsaWJ4
bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4bF9jcHVtYXBfcmVzZXQobGli
eGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KICNkZWZpbmUgbGlieGxfZm9yX2VhY2hfY3B1
KHZhciwgbWFwKSBmb3IgKHZhciA9IDA7IHZhciA8IChtYXApLnNpemUgKiA4OyB2YXIrKykNCisj
ZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUodiwgbSkgZm9yICh2ID0gMDsgdiA8IChtKS5z
aXplICogODsgdisrKSBcDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKGxpYnhsX2NwdW1hcF90ZXN0KCYobSksIHYpKQ0KIA0KIGludCBsaWJ4bF9jcHVh
cnJheV9hbGxvYyhsaWJ4bF9jdHggKmN0eCwgbGlieGxfY3B1YXJyYXkgKmNwdWFycmF5KTsNCiAN
CmRpZmYgLXIgYTJhODA4OWIxZmZiIHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYw0KLS0tIGEvdG9v
bHMvbGlieGwveGxfY21kaW1wbC5jCVR1ZSBKYW4gMjQgMTY6NDY6MTcgMjAxMiArMDAwMA0KKysr
IGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCVdlZCBKYW4gMjUgMTE6NDA6MjIgMjAxMiArMDAw
MA0KQEAgLTM1MDMsMTMgKzM1MDMsNzIgQEAgaW50IG1haW5fdmNwdWxpc3QoaW50IGFyZ2MsIGNo
YXIgKiphcmd2KQ0KICAgICByZXR1cm4gMDsNCiB9DQogDQorc3RhdGljIGludCB2Y3B1cGluX3Bh
cnNlKGNoYXIgKmNwdSwgbGlieGxfY3B1bWFwICpjcHVtYXApDQorew0KKyAgICBsaWJ4bF9jcHVt
YXAgZXhjbHVkZV9jcHVtYXA7DQorICAgIHVpbnQzMl90IGNwdWlkYSwgY3B1aWRiOw0KKyAgICBj
aGFyICplbmRwdHIsICp0b2thLCAqdG9rYiwgKnNhdmVwdHIgPSBOVUxMOw0KKyAgICBpbnQgaSwg
cmMgPSAwLCBybWNwdTsNCisNCisgICAgaWYgKCFzdHJjbXAoY3B1LCAiYWxsIikpIHsNCisgICAg
ICAgIG1lbXNldChjcHVtYXAtPm1hcCwgLTEsIGNwdW1hcC0+c2l6ZSk7DQorICAgICAgICByZXR1
cm4gMDsNCisgICAgfQ0KKw0KKyAgICBpZiAobGlieGxfY3B1bWFwX2FsbG9jKGN0eCwgJmV4Y2x1
ZGVfY3B1bWFwKSkgew0KKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogRmFpbGVkIHRv
IGFsbG9jYXRlIGNwdW1hcC5cbiIpOw0KKyAgICAgICAgcmV0dXJuIEVOT01FTTsNCisgICAgfQ0K
Kw0KKyAgICBmb3IgKHRva2EgPSBzdHJ0b2tfcihjcHUsICIsIiwgJnNhdmVwdHIpOyB0b2thOw0K
KyAgICAgICAgIHRva2EgPSBzdHJ0b2tfcihOVUxMLCAiLCIsICZzYXZlcHRyKSkgew0KKyAgICAg
ICAgcm1jcHUgPSAwOw0KKyAgICAgICAgaWYgKCp0b2thID09ICdeJykgew0KKyAgICAgICAgICAg
IC8qIFRoaXMgKFRoZXNlKSBDcHUocykgd2lsbCBiZSByZW1vdmVkIGZyb20gdGhlIG1hcCAqLw0K
KyAgICAgICAgICAgIHRva2ErKzsNCisgICAgICAgICAgICBybWNwdSA9IDE7DQorICAgICAgICB9
DQorICAgICAgICAvKiBFeHRyYWN0IGEgdmFsaWQgKHJhbmdlIG9mKSBjcHUocykgKi8NCisgICAg
ICAgIGNwdWlkYSA9IGNwdWlkYiA9IHN0cnRvdWwodG9rYSwgJmVuZHB0ciwgMTApOw0KKyAgICAg
ICAgaWYgKGVuZHB0ciA9PSB0b2thKSB7DQorICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJF
cnJvcjogSW52YWxpZCBhcmd1bWVudC5cbiIpOw0KKyAgICAgICAgICAgIHJjID0gRUlOVkFMOw0K
KyAgICAgICAgICAgIGdvdG8gdmNwcF9vdXQ7DQorICAgICAgICB9DQorICAgICAgICBpZiAoKmVu
ZHB0ciA9PSAnLScpIHsNCisgICAgICAgICAgICB0b2tiID0gZW5kcHRyICsgMTsNCisgICAgICAg
ICAgICBjcHVpZGIgPSBzdHJ0b3VsKHRva2IsICZlbmRwdHIsIDEwKTsNCisgICAgICAgICAgICBp
ZiAoZW5kcHRyID09IHRva2IgfHwgY3B1aWRhID4gY3B1aWRiKSB7DQorICAgICAgICAgICAgICAg
IGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFsaWQgYXJndW1lbnQuXG4iKTsNCisgICAgICAg
ICAgICAgICAgcmMgPSBFSU5WQUw7DQorICAgICAgICAgICAgICAgIGdvdG8gdmNwcF9vdXQ7DQor
ICAgICAgICAgICAgfQ0KKyAgICAgICAgfQ0KKyAgICAgICAgd2hpbGUgKGNwdWlkYSA8PSBjcHVp
ZGIpIHsNCisgICAgICAgICAgICBybWNwdSA9PSAwID8gbGlieGxfY3B1bWFwX3NldChjcHVtYXAs
IGNwdWlkYSkgOg0KKyAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0KCZl
eGNsdWRlX2NwdW1hcCwgY3B1aWRhKTsNCisgICAgICAgICAgICBjcHVpZGErKzsNCisgICAgICAg
IH0NCisgICAgfQ0KKw0KKyAgICAvKiBDbGVhciBhbGwgdGhlIGNwdXMgZnJvbSB0aGUgcmVtb3Zh
bCBsaXN0ICovDQorICAgIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUoaSwgZXhjbHVkZV9jcHVtYXAp
IHsNCisgICAgICAgIGxpYnhsX2NwdW1hcF9yZXNldChjcHVtYXAsIGkpOw0KKyAgICB9DQorDQor
dmNwcF9vdXQ6DQorICAgIGxpYnhsX2NwdW1hcF9kaXNwb3NlKCZleGNsdWRlX2NwdW1hcCk7DQor
DQorICAgIHJldHVybiByYzsNCit9DQorDQogc3RhdGljIHZvaWQgdmNwdXBpbihjb25zdCBjaGFy
ICpkLCBjb25zdCBjaGFyICp2Y3B1LCBjaGFyICpjcHUpDQogew0KICAgICBsaWJ4bF92Y3B1aW5m
byAqdmNwdWluZm87DQogICAgIGxpYnhsX2NwdW1hcCBjcHVtYXA7DQogDQotICAgIHVpbnQzMl90
IHZjcHVpZCwgY3B1aWRhLCBjcHVpZGI7DQotICAgIGNoYXIgKmVuZHB0ciwgKnRva2EsICp0b2ti
Ow0KKyAgICB1aW50MzJfdCB2Y3B1aWQ7DQorICAgIGNoYXIgKmVuZHB0cjsNCiAgICAgaW50IGks
IG5iX3ZjcHU7DQogDQogICAgIHZjcHVpZCA9IHN0cnRvdWwodmNwdSwgJmVuZHB0ciwgMTApOw0K
QEAgLTM1MjYsMzIgKzM1ODUsOSBAQCBzdGF0aWMgdm9pZCB2Y3B1cGluKGNvbnN0IGNoYXIgKmQs
IGNvbnN0DQogICAgIGlmIChsaWJ4bF9jcHVtYXBfYWxsb2MoY3R4LCAmY3B1bWFwKSkgew0KICAg
ICAgICAgZ290byB2Y3B1cGluX291dDsNCiAgICAgfQ0KLSAgICBpZiAoc3RyY21wKGNwdSwgImFs
bCIpKSB7DQotICAgICAgICBmb3IgKHRva2EgPSBzdHJ0b2soY3B1LCAiLCIpLCBpID0gMDsgdG9r
YTsgdG9rYSA9IHN0cnRvayhOVUxMLCAiLCIpLCArK2kpIHsNCi0gICAgICAgICAgICBjcHVpZGEg
PSBzdHJ0b3VsKHRva2EsICZlbmRwdHIsIDEwKTsNCi0gICAgICAgICAgICBpZiAodG9rYSA9PSBl
bmRwdHIpIHsNCi0gICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogSW52YWxp
ZCBhcmd1bWVudC5cbiIpOw0KLSAgICAgICAgICAgICAgICBnb3RvIHZjcHVwaW5fb3V0MTsNCi0g
ICAgICAgICAgICB9DQotICAgICAgICAgICAgaWYgKCplbmRwdHIgPT0gJy0nKSB7DQotICAgICAg
ICAgICAgICAgIHRva2IgPSBlbmRwdHIgKyAxOw0KLSAgICAgICAgICAgICAgICBjcHVpZGIgPSBz
dHJ0b3VsKHRva2IsICZlbmRwdHIsIDEwKTsNCi0gICAgICAgICAgICAgICAgaWYgKCh0b2tiID09
IGVuZHB0cikgfHwgKGNwdWlkYSA+IGNwdWlkYikpIHsNCi0gICAgICAgICAgICAgICAgICAgIGZw
cmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFsaWQgYXJndW1lbnQuXG4iKTsNCi0gICAgICAgICAg
ICAgICAgICAgIGdvdG8gdmNwdXBpbl9vdXQxOw0KLSAgICAgICAgICAgICAgICB9DQotICAgICAg
ICAgICAgICAgIHdoaWxlIChjcHVpZGEgPD0gY3B1aWRiKSB7DQotICAgICAgICAgICAgICAgICAg
ICBsaWJ4bF9jcHVtYXBfc2V0KCZjcHVtYXAsIGNwdWlkYSk7DQotICAgICAgICAgICAgICAgICAg
ICArK2NwdWlkYTsNCi0gICAgICAgICAgICAgICAgfQ0KLSAgICAgICAgICAgIH0gZWxzZSB7DQot
ICAgICAgICAgICAgICAgIGxpYnhsX2NwdW1hcF9zZXQoJmNwdW1hcCwgY3B1aWRhKTsNCi0gICAg
ICAgICAgICB9DQotICAgICAgICB9DQotICAgIH0NCi0gICAgZWxzZSB7DQotICAgICAgICBtZW1z
ZXQoY3B1bWFwLm1hcCwgLTEsIGNwdW1hcC5zaXplKTsNCi0gICAgfQ0KKw0KKyAgICBpZiAodmNw
dXBpbl9wYXJzZShjcHUsICZjcHVtYXApKQ0KKyAgICAgICAgZ290byB2Y3B1cGluX291dDE7DQog
DQogICAgIGlmICh2Y3B1aWQgIT0gLTEpIHsNCiAgICAgICAgIGlmIChsaWJ4bF9zZXRfdmNwdWFm
ZmluaXR5KGN0eCwgZG9taWQsIHZjcHVpZCwgJmNwdW1hcCkgPT0gLTEpIHsNCg==


--=-fTs9J/Zljhf/O4TV79Dv--

--=-k+39NQ5VqV2/znaiDeQU
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)

iEYEABECAAYFAk8gE8EACgkQk4XaBE3IOsRrtgCgo7CSOL7p1/PkUfl78v169six
u2YAnRbAU0h9hj4gM9KgQMLyzuM34ySe
=45UL
-----END PGP SIGNATURE-----

--=-k+39NQ5VqV2/znaiDeQU--



--===============4175367600534927591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4175367600534927591==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zG-0008Gn-Gm; Wed, 25 Jan 2012 14:38:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1Rq3zE-0008Ga-FT
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:09 +0000
Received: from [85.158.138.51:9601] by server-7.bemta-3.messagelabs.com id
	83/6F-31267-FC3102F4; Wed, 25 Jan 2012 14:38:07 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327502277!10459159!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30886 invoked from network); 25 Jan 2012 14:37:58 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-16.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:37:58 -0000
Received: from [62.94.182.21] (account d.faggioli@sssup.it HELO [192.168.0.20])
	by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75015449; Wed, 25 Jan 2012 15:37:55 +0100
Message-ID: <1327502273.2723.19.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:37:53 +0100
In-Reply-To: <1327500920.2723.11.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss>
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: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCHv3 1 of 2] libxl: extend pCPUs specification for
	vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4175367600534927591=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============4175367600534927591==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-k+39NQ5VqV2/znaiDeQU"


--=-k+39NQ5VqV2/znaiDeQU
Content-Type: multipart/mixed; boundary="=-fTs9J/Zljhf/O4TV79Dv"


--=-fTs9J/Zljhf/O4TV79Dv
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[Resending with patch attached, in case the client mangled the body of =20
the message (although it really shouldn't!)]=20

Allow for "^<cpuid>" syntax while specifying the pCPUs list
during a vcpu-pin. This enables doing the following:

 xl vcpu-pin 1 1 0-4,^2

and achieving:

 xl vcpu-list
 Name                                ID  VCPU   CPU State   Time(s) CPU Aff=
inity
 ...
 Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
 ...

Negative ranges are also supported, such as "0-4,^1-2" to
mean "0,3-4"

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

diff -r a2a8089b1ffb tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h	Tue Jan 24 16:46:17 2012 +0000
+++ b/tools/libxl/libxl_utils.h	Wed Jan 25 11:40:22 2012 +0000
@@ -71,6 +71,8 @@ int libxl_cpumap_test(libxl_cpumap *cpum
 void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var =3D 0; var < (map).size * 8;=
 var++)
+#define libxl_for_each_set_cpu(v, m) for (v =3D 0; v < (m).size * 8; v++) =
\
+                                             if (libxl_cpumap_test(&(m), v=
))
=20
 int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
=20
diff -r a2a8089b1ffb tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 24 16:46:17 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 11:40:22 2012 +0000
@@ -3503,13 +3503,72 @@ int main_vcpulist(int argc, char **argv)
     return 0;
 }
=20
+static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
+{
+    libxl_cpumap exclude_cpumap;
+    uint32_t cpuida, cpuidb;
+    char *endptr, *toka, *tokb, *saveptr =3D NULL;
+    int i, rc =3D 0, rmcpu;
+
+    if (!strcmp(cpu, "all")) {
+        memset(cpumap->map, -1, cpumap->size);
+        return 0;
+    }
+
+    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
+        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
+        return ENOMEM;
+    }
+
+    for (toka =3D strtok_r(cpu, ",", &saveptr); toka;
+         toka =3D strtok_r(NULL, ",", &saveptr)) {
+        rmcpu =3D 0;
+        if (*toka =3D=3D '^') {
+            /* This (These) Cpu(s) will be removed from the map */
+            toka++;
+            rmcpu =3D 1;
+        }
+        /* Extract a valid (range of) cpu(s) */
+        cpuida =3D cpuidb =3D strtoul(toka, &endptr, 10);
+        if (endptr =3D=3D toka) {
+            fprintf(stderr, "Error: Invalid argument.\n");
+            rc =3D EINVAL;
+            goto vcpp_out;
+        }
+        if (*endptr =3D=3D '-') {
+            tokb =3D endptr + 1;
+            cpuidb =3D strtoul(tokb, &endptr, 10);
+            if (endptr =3D=3D tokb || cpuida > cpuidb) {
+                fprintf(stderr, "Error: Invalid argument.\n");
+                rc =3D EINVAL;
+                goto vcpp_out;
+            }
+        }
+        while (cpuida <=3D cpuidb) {
+            rmcpu =3D=3D 0 ? libxl_cpumap_set(cpumap, cpuida) :
+                         libxl_cpumap_set(&exclude_cpumap, cpuida);
+            cpuida++;
+        }
+    }
+
+    /* Clear all the cpus from the removal list */
+    libxl_for_each_set_cpu(i, exclude_cpumap) {
+        libxl_cpumap_reset(cpumap, i);
+    }
+
+vcpp_out:
+    libxl_cpumap_dispose(&exclude_cpumap);
+
+    return rc;
+}
+
 static void vcpupin(const char *d, const char *vcpu, char *cpu)
 {
     libxl_vcpuinfo *vcpuinfo;
     libxl_cpumap cpumap;
=20
-    uint32_t vcpuid, cpuida, cpuidb;
-    char *endptr, *toka, *tokb;
+    uint32_t vcpuid;
+    char *endptr;
     int i, nb_vcpu;
=20
     vcpuid =3D strtoul(vcpu, &endptr, 10);
@@ -3526,32 +3585,9 @@ static void vcpupin(const char *d, const
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         goto vcpupin_out;
     }
-    if (strcmp(cpu, "all")) {
-        for (toka =3D strtok(cpu, ","), i =3D 0; toka; toka =3D strtok(NUL=
L, ","), ++i) {
-            cpuida =3D strtoul(toka, &endptr, 10);
-            if (toka =3D=3D endptr) {
-                fprintf(stderr, "Error: Invalid argument.\n");
-                goto vcpupin_out1;
-            }
-            if (*endptr =3D=3D '-') {
-                tokb =3D endptr + 1;
-                cpuidb =3D strtoul(tokb, &endptr, 10);
-                if ((tokb =3D=3D endptr) || (cpuida > cpuidb)) {
-                    fprintf(stderr, "Error: Invalid argument.\n");
-                    goto vcpupin_out1;
-                }
-                while (cpuida <=3D cpuidb) {
-                    libxl_cpumap_set(&cpumap, cpuida);
-                    ++cpuida;
-                }
-            } else {
-                libxl_cpumap_set(&cpumap, cpuida);
-            }
-        }
-    }
-    else {
-        memset(cpumap.map, -1, cpumap.size);
-    }
+
+    if (vcpupin_parse(cpu, &cpumap))
+        goto vcpupin_out1;
=20
     if (vcpuid !=3D -1) {
         if (libxl_set_vcpuaffinity(ctx, domid, vcpuid, &cpumap) =3D=3D -1)=
 {

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)




--=-fTs9J/Zljhf/O4TV79Dv
Content-Disposition: attachment; filename="generalize-vcpupin-parsig.patch"
Content-Type: text/x-patch; name="generalize-vcpupin-parsig.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

IyBIRyBjaGFuZ2VzZXQgcGF0Y2gNCiMgUGFyZW50IGEyYTgwODliMWZmYmY1NzU3Y2EzMTkxY2I4
Zjc0YTVmMWVkN2ZlZDENCmxpYnhsOiBleHRlbmQgcENQVXMgc3BlY2lmaWNhdGlvbiBmb3IgdmNw
dS1waW4uDQoNCkFsbG93IGZvciAiXjxjcHVpZD4iIHN5bnRheCB3aGlsZSBzcGVjaWZ5aW5nIHRo
ZSBwQ1BVcyBsaXN0DQpkdXJpbmcgYSB2Y3B1LXBpbi4gVGhpcyBlbmFibGVzIGRvaW5nIHRoZSBm
b2xsb3dpbmc6DQoNCiB4bCB2Y3B1LXBpbiAxIDEgMC00LF4yDQoNCmFuZCBhY2hpZXZpbmc6DQoN
CiB4bCB2Y3B1LWxpc3QNCiBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCAg
VkNQVSAgIENQVSBTdGF0ZSAgIFRpbWUocykgQ1BVIEFmZmluaXR5DQogLi4uDQogU3F1ZWV6ZV9w
diAgICAgICAgICAgICAgICAgICAgICAgICAgIDEgICAgIDEgICAgMyAgIC1iLSAgICAgICAyLjQg
IDAtMSwzLTQNCiAuLi4NCg0KU2lnbmVkLW9mZi1ieTogRGFyaW8gRmFnZ2lvbGkgPGRhcmlvLmZh
Z2dpb2xpQGNpdHJpeC5jb20+DQoNCmRpZmYgLXIgYTJhODA4OWIxZmZiIHRvb2xzL2xpYnhsL2xp
YnhsX3V0aWxzLmgNCi0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX3V0aWxzLmgJVHVlIEphbiAyNCAx
Njo0NjoxNyAyMDEyICswMDAwDQorKysgYi90b29scy9saWJ4bC9saWJ4bF91dGlscy5oCVdlZCBK
YW4gMjUgMTE6NDA6MjIgMjAxMiArMDAwMA0KQEAgLTcxLDYgKzcxLDggQEAgaW50IGxpYnhsX2Nw
dW1hcF90ZXN0KGxpYnhsX2NwdW1hcCAqY3B1bQ0KIHZvaWQgbGlieGxfY3B1bWFwX3NldChsaWJ4
bF9jcHVtYXAgKmNwdW1hcCwgaW50IGNwdSk7DQogdm9pZCBsaWJ4bF9jcHVtYXBfcmVzZXQobGli
eGxfY3B1bWFwICpjcHVtYXAsIGludCBjcHUpOw0KICNkZWZpbmUgbGlieGxfZm9yX2VhY2hfY3B1
KHZhciwgbWFwKSBmb3IgKHZhciA9IDA7IHZhciA8IChtYXApLnNpemUgKiA4OyB2YXIrKykNCisj
ZGVmaW5lIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUodiwgbSkgZm9yICh2ID0gMDsgdiA8IChtKS5z
aXplICogODsgdisrKSBcDQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgKGxpYnhsX2NwdW1hcF90ZXN0KCYobSksIHYpKQ0KIA0KIGludCBsaWJ4bF9jcHVh
cnJheV9hbGxvYyhsaWJ4bF9jdHggKmN0eCwgbGlieGxfY3B1YXJyYXkgKmNwdWFycmF5KTsNCiAN
CmRpZmYgLXIgYTJhODA4OWIxZmZiIHRvb2xzL2xpYnhsL3hsX2NtZGltcGwuYw0KLS0tIGEvdG9v
bHMvbGlieGwveGxfY21kaW1wbC5jCVR1ZSBKYW4gMjQgMTY6NDY6MTcgMjAxMiArMDAwMA0KKysr
IGIvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCVdlZCBKYW4gMjUgMTE6NDA6MjIgMjAxMiArMDAw
MA0KQEAgLTM1MDMsMTMgKzM1MDMsNzIgQEAgaW50IG1haW5fdmNwdWxpc3QoaW50IGFyZ2MsIGNo
YXIgKiphcmd2KQ0KICAgICByZXR1cm4gMDsNCiB9DQogDQorc3RhdGljIGludCB2Y3B1cGluX3Bh
cnNlKGNoYXIgKmNwdSwgbGlieGxfY3B1bWFwICpjcHVtYXApDQorew0KKyAgICBsaWJ4bF9jcHVt
YXAgZXhjbHVkZV9jcHVtYXA7DQorICAgIHVpbnQzMl90IGNwdWlkYSwgY3B1aWRiOw0KKyAgICBj
aGFyICplbmRwdHIsICp0b2thLCAqdG9rYiwgKnNhdmVwdHIgPSBOVUxMOw0KKyAgICBpbnQgaSwg
cmMgPSAwLCBybWNwdTsNCisNCisgICAgaWYgKCFzdHJjbXAoY3B1LCAiYWxsIikpIHsNCisgICAg
ICAgIG1lbXNldChjcHVtYXAtPm1hcCwgLTEsIGNwdW1hcC0+c2l6ZSk7DQorICAgICAgICByZXR1
cm4gMDsNCisgICAgfQ0KKw0KKyAgICBpZiAobGlieGxfY3B1bWFwX2FsbG9jKGN0eCwgJmV4Y2x1
ZGVfY3B1bWFwKSkgew0KKyAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogRmFpbGVkIHRv
IGFsbG9jYXRlIGNwdW1hcC5cbiIpOw0KKyAgICAgICAgcmV0dXJuIEVOT01FTTsNCisgICAgfQ0K
Kw0KKyAgICBmb3IgKHRva2EgPSBzdHJ0b2tfcihjcHUsICIsIiwgJnNhdmVwdHIpOyB0b2thOw0K
KyAgICAgICAgIHRva2EgPSBzdHJ0b2tfcihOVUxMLCAiLCIsICZzYXZlcHRyKSkgew0KKyAgICAg
ICAgcm1jcHUgPSAwOw0KKyAgICAgICAgaWYgKCp0b2thID09ICdeJykgew0KKyAgICAgICAgICAg
IC8qIFRoaXMgKFRoZXNlKSBDcHUocykgd2lsbCBiZSByZW1vdmVkIGZyb20gdGhlIG1hcCAqLw0K
KyAgICAgICAgICAgIHRva2ErKzsNCisgICAgICAgICAgICBybWNwdSA9IDE7DQorICAgICAgICB9
DQorICAgICAgICAvKiBFeHRyYWN0IGEgdmFsaWQgKHJhbmdlIG9mKSBjcHUocykgKi8NCisgICAg
ICAgIGNwdWlkYSA9IGNwdWlkYiA9IHN0cnRvdWwodG9rYSwgJmVuZHB0ciwgMTApOw0KKyAgICAg
ICAgaWYgKGVuZHB0ciA9PSB0b2thKSB7DQorICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJF
cnJvcjogSW52YWxpZCBhcmd1bWVudC5cbiIpOw0KKyAgICAgICAgICAgIHJjID0gRUlOVkFMOw0K
KyAgICAgICAgICAgIGdvdG8gdmNwcF9vdXQ7DQorICAgICAgICB9DQorICAgICAgICBpZiAoKmVu
ZHB0ciA9PSAnLScpIHsNCisgICAgICAgICAgICB0b2tiID0gZW5kcHRyICsgMTsNCisgICAgICAg
ICAgICBjcHVpZGIgPSBzdHJ0b3VsKHRva2IsICZlbmRwdHIsIDEwKTsNCisgICAgICAgICAgICBp
ZiAoZW5kcHRyID09IHRva2IgfHwgY3B1aWRhID4gY3B1aWRiKSB7DQorICAgICAgICAgICAgICAg
IGZwcmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFsaWQgYXJndW1lbnQuXG4iKTsNCisgICAgICAg
ICAgICAgICAgcmMgPSBFSU5WQUw7DQorICAgICAgICAgICAgICAgIGdvdG8gdmNwcF9vdXQ7DQor
ICAgICAgICAgICAgfQ0KKyAgICAgICAgfQ0KKyAgICAgICAgd2hpbGUgKGNwdWlkYSA8PSBjcHVp
ZGIpIHsNCisgICAgICAgICAgICBybWNwdSA9PSAwID8gbGlieGxfY3B1bWFwX3NldChjcHVtYXAs
IGNwdWlkYSkgOg0KKyAgICAgICAgICAgICAgICAgICAgICAgICBsaWJ4bF9jcHVtYXBfc2V0KCZl
eGNsdWRlX2NwdW1hcCwgY3B1aWRhKTsNCisgICAgICAgICAgICBjcHVpZGErKzsNCisgICAgICAg
IH0NCisgICAgfQ0KKw0KKyAgICAvKiBDbGVhciBhbGwgdGhlIGNwdXMgZnJvbSB0aGUgcmVtb3Zh
bCBsaXN0ICovDQorICAgIGxpYnhsX2Zvcl9lYWNoX3NldF9jcHUoaSwgZXhjbHVkZV9jcHVtYXAp
IHsNCisgICAgICAgIGxpYnhsX2NwdW1hcF9yZXNldChjcHVtYXAsIGkpOw0KKyAgICB9DQorDQor
dmNwcF9vdXQ6DQorICAgIGxpYnhsX2NwdW1hcF9kaXNwb3NlKCZleGNsdWRlX2NwdW1hcCk7DQor
DQorICAgIHJldHVybiByYzsNCit9DQorDQogc3RhdGljIHZvaWQgdmNwdXBpbihjb25zdCBjaGFy
ICpkLCBjb25zdCBjaGFyICp2Y3B1LCBjaGFyICpjcHUpDQogew0KICAgICBsaWJ4bF92Y3B1aW5m
byAqdmNwdWluZm87DQogICAgIGxpYnhsX2NwdW1hcCBjcHVtYXA7DQogDQotICAgIHVpbnQzMl90
IHZjcHVpZCwgY3B1aWRhLCBjcHVpZGI7DQotICAgIGNoYXIgKmVuZHB0ciwgKnRva2EsICp0b2ti
Ow0KKyAgICB1aW50MzJfdCB2Y3B1aWQ7DQorICAgIGNoYXIgKmVuZHB0cjsNCiAgICAgaW50IGks
IG5iX3ZjcHU7DQogDQogICAgIHZjcHVpZCA9IHN0cnRvdWwodmNwdSwgJmVuZHB0ciwgMTApOw0K
QEAgLTM1MjYsMzIgKzM1ODUsOSBAQCBzdGF0aWMgdm9pZCB2Y3B1cGluKGNvbnN0IGNoYXIgKmQs
IGNvbnN0DQogICAgIGlmIChsaWJ4bF9jcHVtYXBfYWxsb2MoY3R4LCAmY3B1bWFwKSkgew0KICAg
ICAgICAgZ290byB2Y3B1cGluX291dDsNCiAgICAgfQ0KLSAgICBpZiAoc3RyY21wKGNwdSwgImFs
bCIpKSB7DQotICAgICAgICBmb3IgKHRva2EgPSBzdHJ0b2soY3B1LCAiLCIpLCBpID0gMDsgdG9r
YTsgdG9rYSA9IHN0cnRvayhOVUxMLCAiLCIpLCArK2kpIHsNCi0gICAgICAgICAgICBjcHVpZGEg
PSBzdHJ0b3VsKHRva2EsICZlbmRwdHIsIDEwKTsNCi0gICAgICAgICAgICBpZiAodG9rYSA9PSBl
bmRwdHIpIHsNCi0gICAgICAgICAgICAgICAgZnByaW50ZihzdGRlcnIsICJFcnJvcjogSW52YWxp
ZCBhcmd1bWVudC5cbiIpOw0KLSAgICAgICAgICAgICAgICBnb3RvIHZjcHVwaW5fb3V0MTsNCi0g
ICAgICAgICAgICB9DQotICAgICAgICAgICAgaWYgKCplbmRwdHIgPT0gJy0nKSB7DQotICAgICAg
ICAgICAgICAgIHRva2IgPSBlbmRwdHIgKyAxOw0KLSAgICAgICAgICAgICAgICBjcHVpZGIgPSBz
dHJ0b3VsKHRva2IsICZlbmRwdHIsIDEwKTsNCi0gICAgICAgICAgICAgICAgaWYgKCh0b2tiID09
IGVuZHB0cikgfHwgKGNwdWlkYSA+IGNwdWlkYikpIHsNCi0gICAgICAgICAgICAgICAgICAgIGZw
cmludGYoc3RkZXJyLCAiRXJyb3I6IEludmFsaWQgYXJndW1lbnQuXG4iKTsNCi0gICAgICAgICAg
ICAgICAgICAgIGdvdG8gdmNwdXBpbl9vdXQxOw0KLSAgICAgICAgICAgICAgICB9DQotICAgICAg
ICAgICAgICAgIHdoaWxlIChjcHVpZGEgPD0gY3B1aWRiKSB7DQotICAgICAgICAgICAgICAgICAg
ICBsaWJ4bF9jcHVtYXBfc2V0KCZjcHVtYXAsIGNwdWlkYSk7DQotICAgICAgICAgICAgICAgICAg
ICArK2NwdWlkYTsNCi0gICAgICAgICAgICAgICAgfQ0KLSAgICAgICAgICAgIH0gZWxzZSB7DQot
ICAgICAgICAgICAgICAgIGxpYnhsX2NwdW1hcF9zZXQoJmNwdW1hcCwgY3B1aWRhKTsNCi0gICAg
ICAgICAgICB9DQotICAgICAgICB9DQotICAgIH0NCi0gICAgZWxzZSB7DQotICAgICAgICBtZW1z
ZXQoY3B1bWFwLm1hcCwgLTEsIGNwdW1hcC5zaXplKTsNCi0gICAgfQ0KKw0KKyAgICBpZiAodmNw
dXBpbl9wYXJzZShjcHUsICZjcHVtYXApKQ0KKyAgICAgICAgZ290byB2Y3B1cGluX291dDE7DQog
DQogICAgIGlmICh2Y3B1aWQgIT0gLTEpIHsNCiAgICAgICAgIGlmIChsaWJ4bF9zZXRfdmNwdWFm
ZmluaXR5KGN0eCwgZG9taWQsIHZjcHVpZCwgJmNwdW1hcCkgPT0gLTEpIHsNCg==


--=-fTs9J/Zljhf/O4TV79Dv--

--=-k+39NQ5VqV2/znaiDeQU
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)

iEYEABECAAYFAk8gE8EACgkQk4XaBE3IOsRrtgCgo7CSOL7p1/PkUfl78v169six
u2YAnRbAU0h9hj4gM9KgQMLyzuM34ySe
=45UL
-----END PGP SIGNATURE-----

--=-k+39NQ5VqV2/znaiDeQU--



--===============4175367600534927591==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4175367600534927591==--



From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zP-0008Iq-ON; Wed, 25 Jan 2012 14:38:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zN-0008Hq-Lx
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:17 +0000
Received: from [85.158.138.51:28402] by server-9.bemta-3.messagelabs.com id
	B6/01-31168-8D3102F4; Wed, 25 Jan 2012 14:38:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327502294!6414357!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13587 invoked from network); 25 Jan 2012 14:38:15 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:15 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PEcChp004117
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCwu011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:41 -0500
Message-Id: <1327502278-1790-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/23] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..3828c62 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -64,6 +64,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -95,9 +96,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c8da45..965dbd0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -243,9 +243,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zP-0008Ie-BT; Wed, 25 Jan 2012 14:38:19 +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 1Rq3zN-0008Hl-D8
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327502259!49750926!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18307 invoked from network); 25 Jan 2012 14:37:39 -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;
	25 Jan 2012 14:37:39 -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
	q0PEcCUH003890; Wed, 25 Jan 2012 14:38: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 q0PEcCwp011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:36 -0500
Message-Id: <1327502278-1790-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/23] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/compat/memory.c  |   14 ++++++++++++++
 xen/common/memory.c         |   37 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-ia64/mm.h   |    1 +
 xen/include/public/memory.h |   16 ++++++++++++++++
 xen/include/xlat.lst        |    1 +
 xen/include/xsm/xsm.h       |    6 ++++++
 xen/xsm/dummy.c             |    6 ++++++
 xen/xsm/flask/hooks.c       |    6 ++++++
 8 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 2402984..e7257cc 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -25,6 +25,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             XEN_GUEST_HANDLE(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
+            struct xen_remove_from_physmap *xrfp;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
@@ -179,6 +180,18 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             nat.hnd = compat;
             break;
 
+        case XENMEM_remove_from_physmap:
+        {
+            struct compat_remove_from_physmap cmp;
+
+            if ( copy_from_guest(&cmp, compat, 1) )
+                return -EFAULT;
+
+            XLAT_remove_from_physmap(nat.xrfp, &cmp);
+
+            break;
+        }
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -284,6 +297,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
         case XENMEM_current_reservation:
         case XENMEM_maximum_reservation:
         case XENMEM_maximum_gpfn:
+        case XENMEM_remove_from_physmap:
             break;
 
         default:
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8d45439..53886ce 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -659,6 +659,43 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
 
         break;
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+        else
+            rc = -ENOENT;
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     default:
         rc = arch_memory_op(op, arg);
         break;
diff --git a/xen/include/asm-ia64/mm.h b/xen/include/asm-ia64/mm.h
index d09c363..a2bfc02 100644
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -550,6 +550,7 @@ extern u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__,
 #define gmfn_to_mfn(_d, gpfn)			\
     gmfn_to_mfn_foreign((_d), (gpfn))
 
+#define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
 #define put_gfn(d, g)   ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index f602155..3d4f1e3 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -60,6 +60,7 @@
 !	memory_map			memory.h
 !	memory_reservation		memory.h
 !	pod_target			memory.h
+!	remove_from_physmap		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zS-0008Lu-UY; Wed, 25 Jan 2012 14:38:22 +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 1Rq3zQ-0008HS-Sl
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327502294!12496785!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19256 invoked from network); 25 Jan 2012 14:38:14 -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;
	25 Jan 2012 14:38:14 -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
	q0PEcDUH003904
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCxA011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:55 -0500
Message-Id: <1327502278-1790-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 20/23] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   11 +++++++++++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 7564edd..dee7bbd 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1804,6 +1804,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1817,6 +1818,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1871,6 +1873,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 435f76a..6a0dbc2 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -602,6 +602,17 @@ void restore_existing_connections(void)
 #ifdef __MINIOS__
 static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zU-0008NO-50; Wed, 25 Jan 2012 14:38:24 +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 1Rq3zR-0008Ha-5b
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327502247!51539840!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1032 invoked from network); 25 Jan 2012 14:37:27 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-27.messagelabs.com with SMTP;
	25 Jan 2012 14:37:27 -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
	q0PEcDUH003899
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx5011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:50 -0500
Message-Id: <1327502278-1790-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/23] xenstored: refactor socket 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>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/xenstore/xenstored_core.c |   85 +++++++++++++++++++++------------------
 1 files changed, 46 insertions(+), 39 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..0e7d43f 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -343,13 +343,6 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
-static int destroy_fd(void *_fd)
-{
-	int *fd = _fd;
-	close(*fd);
-	return 0;
-}
-
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
 {
@@ -1705,6 +1698,51 @@ static void daemonize(void)
 	umask(0);
 }
 
+static int destroy_fd(void *_fd)
+{
+	int *fd = _fd;
+	close(*fd);
+	return 0;
+}
+
+static void init_sockets(int **psock, int **pro_sock)
+{
+	struct sockaddr_un addr;
+	int *sock, *ro_sock;
+	/* Create sockets for them to listen to. */
+	*psock = sock = talloc(talloc_autofree_context(), int);
+	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*sock < 0)
+		barf_perror("Could not create socket");
+	*pro_sock = ro_sock = talloc(talloc_autofree_context(), int);
+	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*ro_sock < 0)
+		barf_perror("Could not create socket");
+	talloc_set_destructor(sock, destroy_fd);
+	talloc_set_destructor(ro_sock, destroy_fd);
+
+	/* FIXME: Be more sophisticated, don't mug running daemon. */
+	unlink(xs_daemon_socket());
+	unlink(xs_daemon_socket_ro());
+
+	addr.sun_family = AF_UNIX;
+	strcpy(addr.sun_path, xs_daemon_socket());
+	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s", xs_daemon_socket());
+	strcpy(addr.sun_path, xs_daemon_socket_ro());
+	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s",
+			    xs_daemon_socket_ro());
+	if (chmod(xs_daemon_socket(), 0600) != 0
+	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
+		barf_perror("Could not chmod sockets");
+
+	if (listen(*sock, 1) != 0
+	    || listen(*ro_sock, 1) != 0)
+		barf_perror("Could not listen on sockets");
+
+
+}
 
 static void usage(void)
 {
@@ -1753,7 +1791,6 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
-	struct sockaddr_un addr;
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,40 +1874,10 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
-	/* Create sockets for them to listen to. */
-	sock = talloc(talloc_autofree_context(), int);
-	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*sock < 0)
-		barf_perror("Could not create socket");
-	ro_sock = talloc(talloc_autofree_context(), int);
-	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*ro_sock < 0)
-		barf_perror("Could not create socket");
-	talloc_set_destructor(sock, destroy_fd);
-	talloc_set_destructor(ro_sock, destroy_fd);
-
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
-	/* FIXME: Be more sophisticated, don't mug running daemon. */
-	unlink(xs_daemon_socket());
-	unlink(xs_daemon_socket_ro());
-
-	addr.sun_family = AF_UNIX;
-	strcpy(addr.sun_path, xs_daemon_socket());
-	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s", xs_daemon_socket());
-	strcpy(addr.sun_path, xs_daemon_socket_ro());
-	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s",
-			    xs_daemon_socket_ro());
-	if (chmod(xs_daemon_socket(), 0600) != 0
-	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
-		barf_perror("Could not chmod sockets");
-
-	if (listen(*sock, 1) != 0
-	    || listen(*ro_sock, 1) != 0)
-		barf_perror("Could not listen on sockets");
+	init_sockets(&sock, &ro_sock);
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zU-0008NO-50; Wed, 25 Jan 2012 14:38:24 +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 1Rq3zR-0008Ha-5b
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327502247!51539840!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1032 invoked from network); 25 Jan 2012 14:37:27 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-27.messagelabs.com with SMTP;
	25 Jan 2012 14:37:27 -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
	q0PEcDUH003899
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx5011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:50 -0500
Message-Id: <1327502278-1790-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/23] xenstored: refactor socket 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>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/xenstore/xenstored_core.c |   85 +++++++++++++++++++++------------------
 1 files changed, 46 insertions(+), 39 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..0e7d43f 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -343,13 +343,6 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
-static int destroy_fd(void *_fd)
-{
-	int *fd = _fd;
-	close(*fd);
-	return 0;
-}
-
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
 {
@@ -1705,6 +1698,51 @@ static void daemonize(void)
 	umask(0);
 }
 
+static int destroy_fd(void *_fd)
+{
+	int *fd = _fd;
+	close(*fd);
+	return 0;
+}
+
+static void init_sockets(int **psock, int **pro_sock)
+{
+	struct sockaddr_un addr;
+	int *sock, *ro_sock;
+	/* Create sockets for them to listen to. */
+	*psock = sock = talloc(talloc_autofree_context(), int);
+	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*sock < 0)
+		barf_perror("Could not create socket");
+	*pro_sock = ro_sock = talloc(talloc_autofree_context(), int);
+	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*ro_sock < 0)
+		barf_perror("Could not create socket");
+	talloc_set_destructor(sock, destroy_fd);
+	talloc_set_destructor(ro_sock, destroy_fd);
+
+	/* FIXME: Be more sophisticated, don't mug running daemon. */
+	unlink(xs_daemon_socket());
+	unlink(xs_daemon_socket_ro());
+
+	addr.sun_family = AF_UNIX;
+	strcpy(addr.sun_path, xs_daemon_socket());
+	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s", xs_daemon_socket());
+	strcpy(addr.sun_path, xs_daemon_socket_ro());
+	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s",
+			    xs_daemon_socket_ro());
+	if (chmod(xs_daemon_socket(), 0600) != 0
+	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
+		barf_perror("Could not chmod sockets");
+
+	if (listen(*sock, 1) != 0
+	    || listen(*ro_sock, 1) != 0)
+		barf_perror("Could not listen on sockets");
+
+
+}
 
 static void usage(void)
 {
@@ -1753,7 +1791,6 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
-	struct sockaddr_un addr;
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,40 +1874,10 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
-	/* Create sockets for them to listen to. */
-	sock = talloc(talloc_autofree_context(), int);
-	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*sock < 0)
-		barf_perror("Could not create socket");
-	ro_sock = talloc(talloc_autofree_context(), int);
-	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*ro_sock < 0)
-		barf_perror("Could not create socket");
-	talloc_set_destructor(sock, destroy_fd);
-	talloc_set_destructor(ro_sock, destroy_fd);
-
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
-	/* FIXME: Be more sophisticated, don't mug running daemon. */
-	unlink(xs_daemon_socket());
-	unlink(xs_daemon_socket_ro());
-
-	addr.sun_family = AF_UNIX;
-	strcpy(addr.sun_path, xs_daemon_socket());
-	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s", xs_daemon_socket());
-	strcpy(addr.sun_path, xs_daemon_socket_ro());
-	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s",
-			    xs_daemon_socket_ro());
-	if (chmod(xs_daemon_socket(), 0600) != 0
-	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
-		barf_perror("Could not chmod sockets");
-
-	if (listen(*sock, 1) != 0
-	    || listen(*ro_sock, 1) != 0)
-		barf_perror("Could not listen on sockets");
+	init_sockets(&sock, &ro_sock);
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zP-0008Ie-BT; Wed, 25 Jan 2012 14:38:19 +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 1Rq3zN-0008Hl-D8
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327502259!49750926!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18307 invoked from network); 25 Jan 2012 14:37:39 -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;
	25 Jan 2012 14:37:39 -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
	q0PEcCUH003890; Wed, 25 Jan 2012 14:38: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 q0PEcCwp011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:36 -0500
Message-Id: <1327502278-1790-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/23] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/compat/memory.c  |   14 ++++++++++++++
 xen/common/memory.c         |   37 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-ia64/mm.h   |    1 +
 xen/include/public/memory.h |   16 ++++++++++++++++
 xen/include/xlat.lst        |    1 +
 xen/include/xsm/xsm.h       |    6 ++++++
 xen/xsm/dummy.c             |    6 ++++++
 xen/xsm/flask/hooks.c       |    6 ++++++
 8 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 2402984..e7257cc 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -25,6 +25,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             XEN_GUEST_HANDLE(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
+            struct xen_remove_from_physmap *xrfp;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
@@ -179,6 +180,18 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             nat.hnd = compat;
             break;
 
+        case XENMEM_remove_from_physmap:
+        {
+            struct compat_remove_from_physmap cmp;
+
+            if ( copy_from_guest(&cmp, compat, 1) )
+                return -EFAULT;
+
+            XLAT_remove_from_physmap(nat.xrfp, &cmp);
+
+            break;
+        }
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -284,6 +297,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
         case XENMEM_current_reservation:
         case XENMEM_maximum_reservation:
         case XENMEM_maximum_gpfn:
+        case XENMEM_remove_from_physmap:
             break;
 
         default:
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8d45439..53886ce 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -659,6 +659,43 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
 
         break;
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+        else
+            rc = -ENOENT;
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     default:
         rc = arch_memory_op(op, arg);
         break;
diff --git a/xen/include/asm-ia64/mm.h b/xen/include/asm-ia64/mm.h
index d09c363..a2bfc02 100644
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -550,6 +550,7 @@ extern u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__,
 #define gmfn_to_mfn(_d, gpfn)			\
     gmfn_to_mfn_foreign((_d), (gpfn))
 
+#define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
 #define put_gfn(d, g)   ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index f602155..3d4f1e3 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -60,6 +60,7 @@
 !	memory_map			memory.h
 !	memory_reservation		memory.h
 !	pod_target			memory.h
+!	remove_from_physmap		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zQ-0008J3-3w; Wed, 25 Jan 2012 14:38:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zO-0008Ht-2E
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:18 +0000
Received: from [85.158.138.51:28392] by server-4.bemta-3.messagelabs.com id
	5D/73-32238-8D3102F4; Wed, 25 Jan 2012 14:38:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327502294!10606223!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28010 invoked from network); 25 Jan 2012 14:38:15 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:15 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PEcDhp004126
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCxB011600; 
	Wed, 25 Jan 2012 09:38:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:56 -0500
Message-Id: <1327502278-1790-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 21/23] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index dee7bbd..06703ec 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -463,7 +463,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -801,11 +801,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 6a0dbc2..d89528f 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -356,7 +356,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -420,7 +420,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -472,7 +472,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -509,7 +509,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zQ-0008Jc-Nd; Wed, 25 Jan 2012 14:38:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zO-0008Ht-J6
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:18 +0000
Received: from [85.158.138.51:14512] by server-4.bemta-3.messagelabs.com id
	45/83-32238-9D3102F4; Wed, 25 Jan 2012 14:38:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327502295!10628442!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15739 invoked from network); 25 Jan 2012 14:38:15 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:15 -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
	q0PEcCUH003894
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx0011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:45 -0500
Message-Id: <1327502278-1790-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 10/23] mini-os: create app-specific configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile  |   52 ++++++++++++++++++++++++++++++++++++++++-----
 extras/mini-os/main.c    |   16 +++++++-------
 extras/mini-os/minios.mk |    4 +-
 stubdom/Makefile         |    8 +++---
 stubdom/grub/minios.cfg  |    2 +
 stubdom/ioemu-minios.cfg |    1 +
 6 files changed, 63 insertions(+), 20 deletions(-)
 create mode 100644 stubdom/c/minios.cfg
 create mode 100644 stubdom/caml/minios.cfg
 create mode 100644 stubdom/grub/minios.cfg
 create mode 100644 stubdom/ioemu-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c2ee062..be38170 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,10 +8,25 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(MINIOS_CONFIG),)
 include Config.mk
+else
+EXTRA_DEPS += $(MINIOS_CONFIG)
+include $(MINIOS_CONFIG)
 endif
 
+# Configuration defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+CONFIG_QEMU_XS_ARGS ?= n
+
+# Export config items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
 # Include common mini-os makerules.
 include minios.mk
 
@@ -34,13 +49,38 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e9dbf02..d4da2bb 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/grub/minios.cfg b/stubdom/grub/minios.cfg
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/stubdom/grub/minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
new file mode 100644
index 0000000..7ea1d2f
--- /dev/null
+++ b/stubdom/ioemu-minios.cfg
@@ -0,0 +1 @@
+CONFIG_QEMU_XS_ARGS=y
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zW-0008Qm-MG; Wed, 25 Jan 2012 14:38:26 +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 1Rq3zS-0008Hi-6p
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327502295!12474036!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 705 invoked from network); 25 Jan 2012 14:38:16 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:38:16 -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
	q0PEcDhp004122; Wed, 25 Jan 2012 14:38: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 q0PEcCx6011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:51 -0500
Message-Id: <1327502278-1790-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 16/23] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Add option for compiling xenstored without unix sockets to support
running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c |   28 +++++++++++++++++++++++-----
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0e7d43f..c1ee932 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
-	set_fd(sock,               inset, &max);
-	set_fd(ro_sock,            inset, &max);
+	if (sock != -1)
+		set_fd(sock, inset, &max);
+	if (ro_sock != -1)
+		set_fd(ro_sock, inset, &max);
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -1345,6 +1349,11 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifdef NO_SOCKETS
+static void accept_connection(int sock, bool canwrite)
+{
+}
+#else
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1399,6 +1408,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1698,6 +1708,13 @@ static void daemonize(void)
 	umask(0);
 }
 
+#ifdef NO_SOCKETS
+static void init_sockets(int **psock, int **pro_sock)
+{
+	static int minus_one = -1;
+	*psock = *pro_sock = &minus_one;
+}
+#else
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
@@ -1743,6 +1760,7 @@ static void init_sockets(int **psock, int **pro_sock)
 
 
 }
+#endif
 
 static void usage(void)
 {
@@ -1938,10 +1956,10 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
-		if (FD_ISSET(*sock, &inset))
+		if (*sock != -1 && FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
-		if (FD_ISSET(*ro_sock, &inset))
+		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zZ-000056-To; Wed, 25 Jan 2012 14:38:29 +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 1Rq3zU-0008Ic-J5
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327502295!12275542!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3582 invoked from network); 25 Jan 2012 14:38:16 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 14:38:16 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PEcDUH003903; Wed, 25 Jan 2012 14:38: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 q0PEcCx8011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:53 -0500
Message-Id: <1327502278-1790-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 18/23] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/Makefile           |    9 ++++++++-
 tools/xenstore/tdb.c              |    6 +++---
 tools/xenstore/utils.h            |    2 ++
 tools/xenstore/xenstored_core.c   |   29 ++++++++++++++++++++++++++---
 tools/xenstore/xenstored_domain.c |   11 +++++++++++
 5 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..be892fd 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 3ecd3fc..cb66ea7 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 
 		/* Iterate through chain */
 		while( tlock->off) {
-			tdb_off current;
+			tdb_off mycurrent;
 			if (rec_read(tdb, tlock->off, rec) == -1)
 				goto fail;
 
@@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 			}
 
 			/* Try to clean dead ones from old traverses */
-			current = tlock->off;
+			mycurrent = tlock->off;
 			tlock->off = rec->next;
 			if (!tdb->read_only && 
-			    do_delete(tdb, current, rec) != 0)
+			    do_delete(tdb, mycurrent, rec) != 0)
 				goto fail;
 		}
 		tdb_unlock(tdb, tlock->hash, F_WRLCK);
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index c1ee932..7564edd 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -92,8 +92,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
+#ifndef __MINIOS__
 	if (rename(newname, xs_daemon_tdb()) != 0)
 		return false;
+#endif
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -223,7 +225,6 @@ static void reopen_log(void)
 	}
 }
 
-
 static bool write_messages(struct connection *conn)
 {
 	int ret;
@@ -326,7 +327,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 		set_fd(sock, inset, &max);
 	if (ro_sock != -1)
 		set_fd(ro_sock, inset, &max);
-	set_fd(reopen_log_pipe[0], inset, &max);
+	if (reopen_log_pipe[0] != -1)
+		set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1410,7 +1412,11 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
+#ifdef __MINIOS__
+#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
+#else
 #define TDB_FLAGS 0
+#endif
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1435,7 +1441,11 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
+#ifdef __MINIOS__
+	tdb_ctx = NULL;
+#else
 	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+#endif
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1661,6 +1671,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifndef __MINIOS__
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1707,6 +1718,7 @@ static void daemonize(void)
 	/* Discard our parent's old-fashioned umask prejudices. */
 	umask(0);
 }
+#endif
 
 #ifdef NO_SOCKETS
 static void init_sockets(int **psock, int **pro_sock)
@@ -1866,6 +1878,7 @@ int main(int argc, char *argv[])
 
 	reopen_log();
 
+#ifndef __MINIOS__
 	/* make sure xenstored directory exists */
 	if (mkdir(xs_daemon_rundir(), 0755)) {
 		if (errno != EEXIST) {
@@ -1887,6 +1900,7 @@ int main(int argc, char *argv[])
 	}
 	if (pidfile)
 		write_pidfile(pidfile);
+#endif
 
 	/* Talloc leak reports go to stderr, which is closed if we fork. */
 	if (!dofork)
@@ -1897,9 +1911,14 @@ int main(int argc, char *argv[])
 
 	init_sockets(&sock, &ro_sock);
 
+#ifdef __MINIOS__
+	reopen_log_pipe[0] = -1;
+	reopen_log_pipe[1] = -1;
+#else
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1916,6 +1935,7 @@ int main(int argc, char *argv[])
 		fflush(stdout);
 	}
 
+#ifndef __MINIOS__
 	/* redirect to /dev/null now we're ready to accept connections */
 	if (dofork) {
 		int devnull = open("/dev/null", O_RDWR);
@@ -1927,6 +1947,7 @@ int main(int argc, char *argv[])
 		close(devnull);
 		xprintf = trace;
 	}
+#endif
 
 	signal(SIGHUP, trigger_reopen_log);
 
@@ -1936,8 +1957,10 @@ int main(int argc, char *argv[])
 	/* Get ready to listen to the tools. */
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1949,7 +1972,7 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
-		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
+		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 661d955..435f76a 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		unmap_interface(domain->interface);
+#else
 		if (domain->domid == 0)
 			munmap(domain->interface, getpagesize());
 		else
 			unmap_interface(domain->interface);
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
@@ -595,6 +599,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static int dom0_init(void)
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -618,6 +628,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zR-0008K2-4L; Wed, 25 Jan 2012 14:38:21 +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 1Rq3zO-0008HQ-Oh
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:18 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327502272!50209744!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 681 invoked from network); 25 Jan 2012 14:37:52 -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;
	25 Jan 2012 14:37:52 -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
	q0PEcDhp004123
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx9011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:54 -0500
Message-Id: <1327502278-1790-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 19/23] stubdom: enable xenstored 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>
MIME-Version: 1.0
Content-Type: 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>
---
 stubdom/Makefile            |   29 ++++++++++++++++++++++++++---
 stubdom/xenstore-minios.cfg |    9 +++++++++
 2 files changed, 35 insertions(+), 3 deletions(-)
 create mode 100644 stubdom/xenstore-minios.cfg

diff --git a/stubdom/Makefile b/stubdom/Makefile
index d4da2bb..5c02464 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg
new file mode 100644
index 0000000..ab7338f
--- /dev/null
+++ b/stubdom/xenstore-minios.cfg
@@ -0,0 +1,9 @@
+CONFIG_BLKFRONT=n
+CONFIG_NETFRONT=n
+CONFIG_FBFRONT=n
+CONFIG_KBDFRONT=n
+CONFIG_CONSFRONT=n
+CONFIG_XENBUS=n
+
+lwip=n
+DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS))
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zT-0008MS-BO; Wed, 25 Jan 2012 14:38:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zQ-0008J5-Kn
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
Received: from [85.158.138.51:14763] by server-6.bemta-3.messagelabs.com id
	C3/C7-31032-BD3102F4; Wed, 25 Jan 2012 14:38:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327502295!10459222!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32342 invoked from network); 25 Jan 2012 14:38:16 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:16 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PEcCUH003898; Wed, 25 Jan 2012 14:38: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 q0PEcCx4011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:49 -0500
Message-Id: <1327502278-1790-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 14/23] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_domain.c |   52 ++++++++++++++++++++++++++++++++----
 1 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..661d955 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
 	return len;
 }
 
+static void *map_interface(domid_t domid, unsigned long mfn)
+{
+	if (*xcg_handle >= 0) {
+		/* this is the preferred method */
+		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	} else {
+		return xc_map_foreign_range(*xc_handle, domid,
+			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+	}
+}
+
+static void unmap_interface(void *interface)
+{
+	if (*xcg_handle >= 0)
+		xc_gnttab_munmap(*xcg_handle, interface, 1);
+	else
+		munmap(interface, getpagesize());
+}
+
 static int destroy_domain(void *_domain)
 {
 	struct domain *domain = _domain;
@@ -174,8 +196,12 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		if (domain->domid == 0)
+			munmap(domain->interface, getpagesize());
+		else
+			unmap_interface(domain->interface);
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +370,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		interface = map_interface(domid, mfn);
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +378,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			unmap_interface(interface);
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +576,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +633,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zY-0008Sv-1u; Wed, 25 Jan 2012 14:38:28 +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 1Rq3zS-0008Hw-MP
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327502295!8287656!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22660 invoked from network); 25 Jan 2012 14:38:16 -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;
	25 Jan 2012 14:38:16 -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
	q0PEcChp004119; Wed, 25 Jan 2012 14:38: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 q0PEcCwx011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:44 -0500
Message-Id: <1327502278-1790-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/23] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This changes the minios evtchn implementation to use a list instead of
an array which ahis allows it to grow as necessary to support any number
of ports, only limited by Xen (NR_EVS is 1024, should be enough for now).

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zM-0008Hj-Un; Wed, 25 Jan 2012 14:38:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zL-0008HL-Ch
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:15 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327502265!57113327!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1332 invoked from network); 25 Jan 2012 14:37:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-27.messagelabs.com with SMTP;
	25 Jan 2012 14:37:45 -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
	q0PEcChp004116
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCwt011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:40 -0500
Message-Id: <1327502278-1790-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/23] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to preserve v2-only features such as sub-page grants will
produce a warning and invalidate the resulting v1 grant entry.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
 xen/include/public/grant_table.h |    7 +++++
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0c55fd1..6f24a94 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2131,7 +2132,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2156,15 +2157,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1)
+    {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    }
+    else if (gt->gt_version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)
+            {
+                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
+                       d->domain_id, reserved_entries[i].flags, i);
+                reserved_entries[i].flags = GTF_invalid;
+            }
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1)
     {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    }
+    else if (gt->gt_version != 0 && op.version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 54d9551..292d724 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,13 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* The first few grant table entries will be preserved across grant table
+ * version changes and may be pre-populated at domain creation by tools.
+ */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zW-0008Pq-6T; Wed, 25 Jan 2012 14:38:26 +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 1Rq3zS-0008Hg-0s
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327502295!8658353!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8220 invoked from network); 25 Jan 2012 14:38:15 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:38:15 -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
	q0PEcDUH003902; Wed, 25 Jan 2012 14:38: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 q0PEcCx7011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:52 -0500
Message-Id: <1327502278-1790-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 17/23] xenstored: support for tdb_copy with
	TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
databases; this is required to run in mini-os which does not use a
filesystem.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/tdb.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..3ecd3fc 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,41 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+		return copy;
+intfail:
+		talloc_free(copy);
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zQ-0008J3-3w; Wed, 25 Jan 2012 14:38:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zO-0008Ht-2E
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:18 +0000
Received: from [85.158.138.51:28392] by server-4.bemta-3.messagelabs.com id
	5D/73-32238-8D3102F4; Wed, 25 Jan 2012 14:38:16 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327502294!10606223!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28010 invoked from network); 25 Jan 2012 14:38:15 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:15 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PEcDhp004126
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCxB011600; 
	Wed, 25 Jan 2012 09:38:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:56 -0500
Message-Id: <1327502278-1790-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 21/23] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index dee7bbd..06703ec 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -463,7 +463,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -801,11 +801,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 6a0dbc2..d89528f 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -356,7 +356,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -420,7 +420,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -472,7 +472,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -509,7 +509,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zX-0008Rc-51; Wed, 25 Jan 2012 14:38:27 +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 1Rq3zS-0008Hm-Bc
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327502294!12355960!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28606 invoked from network); 25 Jan 2012 14:38:14 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 14:38:14 -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
	q0PEcChp004112
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCwo011600
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:35 -0500
Message-Id: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
Subject: [Xen-devel] [PATCH v4 00/23] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v3:
 - mini-os configuration files moved into stubdom/
 - mini-os extra console support now a config option
 - Fewer #ifdefs
 - grant table setup uses hypercall bounce
 - Xenstore stub domain syslog support re-enabled

Changes from v2:
 - configuration support added to mini-os build system
 - add mini-os support for conditionally compiling frontends, xenbus
 - XENMEM_remove_from_physmap moved out of arch-specific code
 - use uint32_t for virqs
 - warn when dropping grant v2-only flags when switching versions
 - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
 - ioctl now returns -EEXIST if xenstored has already been connected
 - various cosmetic cleanups, shuffling

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

Other notes:

The console for xenstored is not currently set up by
init-xenstore-domain. If the hypervisor is compiled with VERBOSE or
debug=y, output from xenstored will be visible on the hypervisor serial
console (or ring buffer if enabled with console_to_ring). The xenstore
stub domain itself supports console output, and init-xenstore-domain
could be extended to daemonize and spool this output to a log file. The
normal xenconsole daemon cannot be used here due to the possibility of a
deadlock.

----

[PATCH 01/23] xen: reinstate previously unused
[PATCH 02/23] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/23] xen: change virq parameters from int to uint32_t
[PATCH 04/23] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 05/23] xen: Preserve reserved grant entries when switching

[PATCH 06/23] tools/libxl: pull xenstore/console domids from
[PATCH 07/23] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 08/23] mini-os: avoid crash if no console is provided
[PATCH 09/23] mini-os: remove per-fd evtchn limit
[PATCH 10/23] mini-os: create app-specific configuration
[PATCH 11/23] mini-os: Move test functions into test.c
[PATCH 12/23] mini-os: make frontends and xenbus optional
[PATCH 13/23] mini-os: fix list.h include guard name

[PATCH 14/23] xenstored: use grant references instead of
[PATCH 15/23] xenstored: refactor socket setup code
[PATCH 16/23] xenstored: add NO_SOCKETS compilation option
[PATCH 17/23] xenstored: support for tdb_copy with TDB_INTERNAL
[PATCH 18/23] xenstored: support running in minios stubdom
[PATCH 19/23] stubdom: enable xenstored build
[PATCH 20/23] xenstored: add --event parameter for bootstrapping
[PATCH 21/23] xenstored: use domain_is_unprivileged instead of
[PATCH 22/23] xenstored: add --priv-domid parameter
[PATCH 23/23] xenstored: Add stub domain builder

Linux patch unchanged since v3, not reposted this time:
[PATCH] xenbus: Add support for xenbus backend in stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zZ-000056-To; Wed, 25 Jan 2012 14:38:29 +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 1Rq3zU-0008Ic-J5
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:25 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327502295!12275542!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3582 invoked from network); 25 Jan 2012 14:38:16 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 14:38:16 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PEcDUH003903; Wed, 25 Jan 2012 14:38: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 q0PEcCx8011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:53 -0500
Message-Id: <1327502278-1790-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 18/23] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/Makefile           |    9 ++++++++-
 tools/xenstore/tdb.c              |    6 +++---
 tools/xenstore/utils.h            |    2 ++
 tools/xenstore/xenstored_core.c   |   29 ++++++++++++++++++++++++++---
 tools/xenstore/xenstored_domain.c |   11 +++++++++++
 5 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..be892fd 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 3ecd3fc..cb66ea7 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 
 		/* Iterate through chain */
 		while( tlock->off) {
-			tdb_off current;
+			tdb_off mycurrent;
 			if (rec_read(tdb, tlock->off, rec) == -1)
 				goto fail;
 
@@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
 			}
 
 			/* Try to clean dead ones from old traverses */
-			current = tlock->off;
+			mycurrent = tlock->off;
 			tlock->off = rec->next;
 			if (!tdb->read_only && 
-			    do_delete(tdb, current, rec) != 0)
+			    do_delete(tdb, mycurrent, rec) != 0)
 				goto fail;
 		}
 		tdb_unlock(tdb, tlock->hash, F_WRLCK);
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index c1ee932..7564edd 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -92,8 +92,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
+#ifndef __MINIOS__
 	if (rename(newname, xs_daemon_tdb()) != 0)
 		return false;
+#endif
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -223,7 +225,6 @@ static void reopen_log(void)
 	}
 }
 
-
 static bool write_messages(struct connection *conn)
 {
 	int ret;
@@ -326,7 +327,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 		set_fd(sock, inset, &max);
 	if (ro_sock != -1)
 		set_fd(ro_sock, inset, &max);
-	set_fd(reopen_log_pipe[0], inset, &max);
+	if (reopen_log_pipe[0] != -1)
+		set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1410,7 +1412,11 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
+#ifdef __MINIOS__
+#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
+#else
 #define TDB_FLAGS 0
+#endif
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1435,7 +1441,11 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
+#ifdef __MINIOS__
+	tdb_ctx = NULL;
+#else
 	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+#endif
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1661,6 +1671,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifndef __MINIOS__
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1707,6 +1718,7 @@ static void daemonize(void)
 	/* Discard our parent's old-fashioned umask prejudices. */
 	umask(0);
 }
+#endif
 
 #ifdef NO_SOCKETS
 static void init_sockets(int **psock, int **pro_sock)
@@ -1866,6 +1878,7 @@ int main(int argc, char *argv[])
 
 	reopen_log();
 
+#ifndef __MINIOS__
 	/* make sure xenstored directory exists */
 	if (mkdir(xs_daemon_rundir(), 0755)) {
 		if (errno != EEXIST) {
@@ -1887,6 +1900,7 @@ int main(int argc, char *argv[])
 	}
 	if (pidfile)
 		write_pidfile(pidfile);
+#endif
 
 	/* Talloc leak reports go to stderr, which is closed if we fork. */
 	if (!dofork)
@@ -1897,9 +1911,14 @@ int main(int argc, char *argv[])
 
 	init_sockets(&sock, &ro_sock);
 
+#ifdef __MINIOS__
+	reopen_log_pipe[0] = -1;
+	reopen_log_pipe[1] = -1;
+#else
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1916,6 +1935,7 @@ int main(int argc, char *argv[])
 		fflush(stdout);
 	}
 
+#ifndef __MINIOS__
 	/* redirect to /dev/null now we're ready to accept connections */
 	if (dofork) {
 		int devnull = open("/dev/null", O_RDWR);
@@ -1927,6 +1947,7 @@ int main(int argc, char *argv[])
 		close(devnull);
 		xprintf = trace;
 	}
+#endif
 
 	signal(SIGHUP, trigger_reopen_log);
 
@@ -1936,8 +1957,10 @@ int main(int argc, char *argv[])
 	/* Get ready to listen to the tools. */
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1949,7 +1972,7 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
-		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
+		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 661d955..435f76a 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		unmap_interface(domain->interface);
+#else
 		if (domain->domid == 0)
 			munmap(domain->interface, getpagesize());
 		else
 			unmap_interface(domain->interface);
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
@@ -595,6 +599,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static int dom0_init(void)
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -618,6 +628,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zW-0008Qm-MG; Wed, 25 Jan 2012 14:38:26 +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 1Rq3zS-0008Hi-6p
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327502295!12474036!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 705 invoked from network); 25 Jan 2012 14:38:16 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:38:16 -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
	q0PEcDhp004122; Wed, 25 Jan 2012 14:38: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 q0PEcCx6011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:51 -0500
Message-Id: <1327502278-1790-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 16/23] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Add option for compiling xenstored without unix sockets to support
running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c |   28 +++++++++++++++++++++++-----
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0e7d43f..c1ee932 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
-	set_fd(sock,               inset, &max);
-	set_fd(ro_sock,            inset, &max);
+	if (sock != -1)
+		set_fd(sock, inset, &max);
+	if (ro_sock != -1)
+		set_fd(ro_sock, inset, &max);
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -1345,6 +1349,11 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifdef NO_SOCKETS
+static void accept_connection(int sock, bool canwrite)
+{
+}
+#else
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1399,6 +1408,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1698,6 +1708,13 @@ static void daemonize(void)
 	umask(0);
 }
 
+#ifdef NO_SOCKETS
+static void init_sockets(int **psock, int **pro_sock)
+{
+	static int minus_one = -1;
+	*psock = *pro_sock = &minus_one;
+}
+#else
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
@@ -1743,6 +1760,7 @@ static void init_sockets(int **psock, int **pro_sock)
 
 
 }
+#endif
 
 static void usage(void)
 {
@@ -1938,10 +1956,10 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
-		if (FD_ISSET(*sock, &inset))
+		if (*sock != -1 && FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
-		if (FD_ISSET(*ro_sock, &inset))
+		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zY-0008Sv-1u; Wed, 25 Jan 2012 14:38:28 +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 1Rq3zS-0008Hw-MP
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327502295!8287656!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22660 invoked from network); 25 Jan 2012 14:38:16 -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;
	25 Jan 2012 14:38:16 -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
	q0PEcChp004119; Wed, 25 Jan 2012 14:38: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 q0PEcCwx011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:44 -0500
Message-Id: <1327502278-1790-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/23] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This changes the minios evtchn implementation to use a list instead of
an array which ahis allows it to grow as necessary to support any number
of ports, only limited by Xen (NR_EVS is 1024, should be enough for now).

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zR-0008K2-4L; Wed, 25 Jan 2012 14:38:21 +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 1Rq3zO-0008HQ-Oh
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:18 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327502272!50209744!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 681 invoked from network); 25 Jan 2012 14:37:52 -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;
	25 Jan 2012 14:37:52 -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
	q0PEcDhp004123
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx9011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:54 -0500
Message-Id: <1327502278-1790-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 19/23] stubdom: enable xenstored 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>
MIME-Version: 1.0
Content-Type: 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>
---
 stubdom/Makefile            |   29 ++++++++++++++++++++++++++---
 stubdom/xenstore-minios.cfg |    9 +++++++++
 2 files changed, 35 insertions(+), 3 deletions(-)
 create mode 100644 stubdom/xenstore-minios.cfg

diff --git a/stubdom/Makefile b/stubdom/Makefile
index d4da2bb..5c02464 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg
new file mode 100644
index 0000000..ab7338f
--- /dev/null
+++ b/stubdom/xenstore-minios.cfg
@@ -0,0 +1,9 @@
+CONFIG_BLKFRONT=n
+CONFIG_NETFRONT=n
+CONFIG_FBFRONT=n
+CONFIG_KBDFRONT=n
+CONFIG_CONSFRONT=n
+CONFIG_XENBUS=n
+
+lwip=n
+DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS))
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3zT-0008My-Ow; Wed, 25 Jan 2012 14:38:23 +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 1Rq3zR-0008Hb-4z
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327502293!8287648!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22545 invoked from network); 25 Jan 2012 14:38:14 -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;
	25 Jan 2012 14:38:14 -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
	q0PEcChp004115
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCwr011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:38 -0500
Message-Id: <1327502278-1790-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/23] xen: change virq parameters from int to
	uint32_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c   |   10 +++++-----
 xen/include/asm-ia64/event.h |    2 +-
 xen/include/asm-x86/event.h  |    2 +-
 xen/include/xen/event.h      |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43bd167..f784254 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,11 +104,11 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 
 static int evtchn_set_pending(struct vcpu *v, int port);
 
-static int virq_is_global(int virq)
+static int virq_is_global(uint32_t virq)
 {
     int rc;
 
-    ASSERT((virq >= 0) && (virq < NR_VIRQS));
+    ASSERT(virq < NR_VIRQS);
 
     switch ( virq )
     {
@@ -665,12 +665,12 @@ static int evtchn_set_pending(struct vcpu *v, int port)
     return 0;
 }
 
-int guest_enabled_event(struct vcpu *v, int virq)
+int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
 }
 
-void send_guest_vcpu_virq(struct vcpu *v, int virq)
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 {
     unsigned long flags;
     int port;
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
     unsigned long flags;
     int port;
diff --git a/xen/include/asm-ia64/event.h b/xen/include/asm-ia64/event.h
index c99babd..4463cb3 100644
--- a/xen/include/asm-ia64/event.h
+++ b/xen/include/asm-ia64/event.h
@@ -63,7 +63,7 @@ static inline void local_event_delivery_enable(void)
     current->vcpu_info->evtchn_upcall_mask = 0;
 }
 
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     int rc;
 
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index 606ec6d..06057c7 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -39,7 +39,7 @@ static inline void local_event_delivery_enable(void)
 }
 
 /* No arch specific virq definition now. Default to global. */
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     return 1;
 }
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 40b8a7a..22fc6a3 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,7 @@
  *  @v:        VCPU to which virtual IRQ should be sent
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_vcpu_virq(struct vcpu *v, int virq);
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
  * send_global_virq: Notify the domain handling a global VIRQ.
@@ -65,7 +65,7 @@ void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
 /* Query if event channel is in use by the guest */
-int guest_enabled_event(struct vcpu *v, int virq);
+int guest_enabled_event(struct vcpu *v, uint32_t virq);
 
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3zS-0008L8-2D; Wed, 25 Jan 2012 14:38:22 +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 1Rq3zQ-0008HN-Ch
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327502293!12530578!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10167 invoked from network); 25 Jan 2012 14:38:14 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:38:14 -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
	q0PEcDhp004129
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCxC011600; 
	Wed, 25 Jan 2012 09:38:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:57 -0500
Message-Id: <1327502278-1790-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 22/23] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 06703ec..6e0f782 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1807,6 +1807,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1819,6 +1820,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1876,6 +1878,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index d89528f..8c215fb 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -261,7 +261,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zT-0008MS-BO; Wed, 25 Jan 2012 14:38:23 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zQ-0008J5-Kn
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
Received: from [85.158.138.51:14763] by server-6.bemta-3.messagelabs.com id
	C3/C7-31032-BD3102F4; Wed, 25 Jan 2012 14:38:19 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327502295!10459222!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32342 invoked from network); 25 Jan 2012 14:38:16 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:16 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PEcCUH003898; Wed, 25 Jan 2012 14:38: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 q0PEcCx4011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:49 -0500
Message-Id: <1327502278-1790-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 14/23] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_domain.c |   52 ++++++++++++++++++++++++++++++++----
 1 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..661d955 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
 	return len;
 }
 
+static void *map_interface(domid_t domid, unsigned long mfn)
+{
+	if (*xcg_handle >= 0) {
+		/* this is the preferred method */
+		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	} else {
+		return xc_map_foreign_range(*xc_handle, domid,
+			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+	}
+}
+
+static void unmap_interface(void *interface)
+{
+	if (*xcg_handle >= 0)
+		xc_gnttab_munmap(*xcg_handle, interface, 1);
+	else
+		munmap(interface, getpagesize());
+}
+
 static int destroy_domain(void *_domain)
 {
 	struct domain *domain = _domain;
@@ -174,8 +196,12 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		if (domain->domid == 0)
+			munmap(domain->interface, getpagesize());
+		else
+			unmap_interface(domain->interface);
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +370,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		interface = map_interface(domid, mfn);
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +378,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			unmap_interface(interface);
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +576,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +633,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zM-0008Hj-Un; Wed, 25 Jan 2012 14:38:16 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zL-0008HL-Ch
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:15 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327502265!57113327!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1332 invoked from network); 25 Jan 2012 14:37:45 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-13.tower-27.messagelabs.com with SMTP;
	25 Jan 2012 14:37:45 -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
	q0PEcChp004116
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCwt011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:40 -0500
Message-Id: <1327502278-1790-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/23] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to preserve v2-only features such as sub-page grants will
produce a warning and invalidate the resulting v1 grant entry.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
 xen/include/public/grant_table.h |    7 +++++
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0c55fd1..6f24a94 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2131,7 +2132,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2156,15 +2157,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1)
+    {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    }
+    else if (gt->gt_version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)
+            {
+                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
+                       d->domain_id, reserved_entries[i].flags, i);
+                reserved_entries[i].flags = GTF_invalid;
+            }
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1)
     {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    }
+    else if (gt->gt_version != 0 && op.version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 54d9551..292d724 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,13 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* The first few grant table entries will be preserved across grant table
+ * version changes and may be pre-populated at domain creation by tools.
+ */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zW-0008Pq-6T; Wed, 25 Jan 2012 14:38:26 +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 1Rq3zS-0008Hg-0s
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327502295!8658353!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8220 invoked from network); 25 Jan 2012 14:38:15 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:38:15 -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
	q0PEcDUH003902; Wed, 25 Jan 2012 14:38: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 q0PEcCx7011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:52 -0500
Message-Id: <1327502278-1790-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 17/23] xenstored: support for tdb_copy with
	TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
databases; this is required to run in mini-os which does not use a
filesystem.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/tdb.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..3ecd3fc 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,41 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+		return copy;
+intfail:
+		talloc_free(copy);
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zX-0008Rc-51; Wed, 25 Jan 2012 14:38:27 +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 1Rq3zS-0008Hm-Bc
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:22 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327502294!12355960!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28606 invoked from network); 25 Jan 2012 14:38:14 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-182.messagelabs.com with SMTP;
	25 Jan 2012 14:38:14 -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
	q0PEcChp004112
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCwo011600
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:35 -0500
Message-Id: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
Subject: [Xen-devel] [PATCH v4 00/23] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v3:
 - mini-os configuration files moved into stubdom/
 - mini-os extra console support now a config option
 - Fewer #ifdefs
 - grant table setup uses hypercall bounce
 - Xenstore stub domain syslog support re-enabled

Changes from v2:
 - configuration support added to mini-os build system
 - add mini-os support for conditionally compiling frontends, xenbus
 - XENMEM_remove_from_physmap moved out of arch-specific code
 - use uint32_t for virqs
 - warn when dropping grant v2-only flags when switching versions
 - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
 - ioctl now returns -EEXIST if xenstored has already been connected
 - various cosmetic cleanups, shuffling

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

Other notes:

The console for xenstored is not currently set up by
init-xenstore-domain. If the hypervisor is compiled with VERBOSE or
debug=y, output from xenstored will be visible on the hypervisor serial
console (or ring buffer if enabled with console_to_ring). The xenstore
stub domain itself supports console output, and init-xenstore-domain
could be extended to daemonize and spool this output to a log file. The
normal xenconsole daemon cannot be used here due to the possibility of a
deadlock.

----

[PATCH 01/23] xen: reinstate previously unused
[PATCH 02/23] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/23] xen: change virq parameters from int to uint32_t
[PATCH 04/23] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 05/23] xen: Preserve reserved grant entries when switching

[PATCH 06/23] tools/libxl: pull xenstore/console domids from
[PATCH 07/23] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 08/23] mini-os: avoid crash if no console is provided
[PATCH 09/23] mini-os: remove per-fd evtchn limit
[PATCH 10/23] mini-os: create app-specific configuration
[PATCH 11/23] mini-os: Move test functions into test.c
[PATCH 12/23] mini-os: make frontends and xenbus optional
[PATCH 13/23] mini-os: fix list.h include guard name

[PATCH 14/23] xenstored: use grant references instead of
[PATCH 15/23] xenstored: refactor socket setup code
[PATCH 16/23] xenstored: add NO_SOCKETS compilation option
[PATCH 17/23] xenstored: support for tdb_copy with TDB_INTERNAL
[PATCH 18/23] xenstored: support running in minios stubdom
[PATCH 19/23] stubdom: enable xenstored build
[PATCH 20/23] xenstored: add --event parameter for bootstrapping
[PATCH 21/23] xenstored: use domain_is_unprivileged instead of
[PATCH 22/23] xenstored: add --priv-domid parameter
[PATCH 23/23] xenstored: Add stub domain builder

Linux patch unchanged since v3, not reposted this time:
[PATCH] xenbus: Add support for xenbus backend in stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3zS-0008L8-2D; Wed, 25 Jan 2012 14:38:22 +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 1Rq3zQ-0008HN-Ch
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:20 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327502293!12530578!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10167 invoked from network); 25 Jan 2012 14:38:14 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 14:38:14 -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
	q0PEcDhp004129
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCxC011600; 
	Wed, 25 Jan 2012 09:38:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:57 -0500
Message-Id: <1327502278-1790-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 22/23] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 06703ec..6e0f782 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1807,6 +1807,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1819,6 +1820,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1876,6 +1878,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index d89528f..8c215fb 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -261,7 +261,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zQ-0008Jc-Nd; Wed, 25 Jan 2012 14:38:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rq3zO-0008Ht-J6
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:18 +0000
Received: from [85.158.138.51:14512] by server-4.bemta-3.messagelabs.com id
	45/83-32238-9D3102F4; Wed, 25 Jan 2012 14:38:17 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327502295!10628442!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15739 invoked from network); 25 Jan 2012 14:38:15 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-4.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 14:38:15 -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
	q0PEcCUH003894
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx0011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:45 -0500
Message-Id: <1327502278-1790-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 10/23] mini-os: create app-specific configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile  |   52 ++++++++++++++++++++++++++++++++++++++++-----
 extras/mini-os/main.c    |   16 +++++++-------
 extras/mini-os/minios.mk |    4 +-
 stubdom/Makefile         |    8 +++---
 stubdom/grub/minios.cfg  |    2 +
 stubdom/ioemu-minios.cfg |    1 +
 6 files changed, 63 insertions(+), 20 deletions(-)
 create mode 100644 stubdom/c/minios.cfg
 create mode 100644 stubdom/caml/minios.cfg
 create mode 100644 stubdom/grub/minios.cfg
 create mode 100644 stubdom/ioemu-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c2ee062..be38170 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,10 +8,25 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(MINIOS_CONFIG),)
 include Config.mk
+else
+EXTRA_DEPS += $(MINIOS_CONFIG)
+include $(MINIOS_CONFIG)
 endif
 
+# Configuration defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+CONFIG_QEMU_XS_ARGS ?= n
+
+# Export config items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
 # Include common mini-os makerules.
 include minios.mk
 
@@ -34,13 +49,38 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e9dbf02..d4da2bb 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/grub/minios.cfg b/stubdom/grub/minios.cfg
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/stubdom/grub/minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
new file mode 100644
index 0000000..7ea1d2f
--- /dev/null
+++ b/stubdom/ioemu-minios.cfg
@@ -0,0 +1 @@
+CONFIG_QEMU_XS_ARGS=y
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3zT-0008My-Ow; Wed, 25 Jan 2012 14:38:23 +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 1Rq3zR-0008Hb-4z
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:21 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327502293!8287648!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22545 invoked from network); 25 Jan 2012 14:38:14 -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;
	25 Jan 2012 14:38:14 -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
	q0PEcChp004115
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCwr011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:38 -0500
Message-Id: <1327502278-1790-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/23] xen: change virq parameters from int to
	uint32_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c   |   10 +++++-----
 xen/include/asm-ia64/event.h |    2 +-
 xen/include/asm-x86/event.h  |    2 +-
 xen/include/xen/event.h      |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43bd167..f784254 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,11 +104,11 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 
 static int evtchn_set_pending(struct vcpu *v, int port);
 
-static int virq_is_global(int virq)
+static int virq_is_global(uint32_t virq)
 {
     int rc;
 
-    ASSERT((virq >= 0) && (virq < NR_VIRQS));
+    ASSERT(virq < NR_VIRQS);
 
     switch ( virq )
     {
@@ -665,12 +665,12 @@ static int evtchn_set_pending(struct vcpu *v, int port)
     return 0;
 }
 
-int guest_enabled_event(struct vcpu *v, int virq)
+int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
 }
 
-void send_guest_vcpu_virq(struct vcpu *v, int virq)
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 {
     unsigned long flags;
     int port;
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
     unsigned long flags;
     int port;
diff --git a/xen/include/asm-ia64/event.h b/xen/include/asm-ia64/event.h
index c99babd..4463cb3 100644
--- a/xen/include/asm-ia64/event.h
+++ b/xen/include/asm-ia64/event.h
@@ -63,7 +63,7 @@ static inline void local_event_delivery_enable(void)
     current->vcpu_info->evtchn_upcall_mask = 0;
 }
 
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     int rc;
 
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index 606ec6d..06057c7 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -39,7 +39,7 @@ static inline void local_event_delivery_enable(void)
 }
 
 /* No arch specific virq definition now. Default to global. */
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     return 1;
 }
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 40b8a7a..22fc6a3 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,7 @@
  *  @v:        VCPU to which virtual IRQ should be sent
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_vcpu_virq(struct vcpu *v, int virq);
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
  * send_global_virq: Notify the domain handling a global VIRQ.
@@ -65,7 +65,7 @@ void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
 /* Query if event channel is in use by the guest */
-int guest_enabled_event(struct vcpu *v, int virq);
+int guest_enabled_event(struct vcpu *v, uint32_t virq);
 
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3za-00006f-KA; Wed, 25 Jan 2012 14:38:30 +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 1Rq3zU-0008IP-77
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327502295!12355962!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28629 invoked from network); 25 Jan 2012 14:38:15 -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;
	25 Jan 2012 14:38:15 -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
	q0PEcDUH003907
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCxD011600; 
	Wed, 25 Jan 2012 09:38:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:58 -0500
Message-Id: <1327502278-1790-24-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 23/23] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   44 ++++++++++++++
 tools/xenstore/Makefile                  |    9 ++-
 tools/xenstore/init-xenstore-domain.c    |   94 ++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..bbee8c6
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,44 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index be892fd..2fce994 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
@@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..f6c31d0
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,94 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+	if (rv < 0) return rv;
+	snprintf(cmdline, 512, "--event %d", rv);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3za-00006f-KA; Wed, 25 Jan 2012 14:38:30 +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 1Rq3zU-0008IP-77
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327502295!12355962!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28629 invoked from network); 25 Jan 2012 14:38:15 -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;
	25 Jan 2012 14:38:15 -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
	q0PEcDUH003907
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCxD011600; 
	Wed, 25 Jan 2012 09:38:13 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:58 -0500
Message-Id: <1327502278-1790-24-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 23/23] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   44 ++++++++++++++
 tools/xenstore/Makefile                  |    9 ++-
 tools/xenstore/init-xenstore-domain.c    |   94 ++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..bbee8c6
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,44 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index be892fd..2fce994 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
@@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..f6c31d0
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,94 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+	if (rv < 0) return rv;
+	snprintf(cmdline, 512, "--event %d", rv);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3zZ-0008VV-DA; Wed, 25 Jan 2012 14:38:29 +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 1Rq3zT-0008IC-L6
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327502294!12342830!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18424 invoked from network); 25 Jan 2012 14:38:15 -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;
	25 Jan 2012 14:38:15 -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
	q0PEcCUH003896
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx2011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:47 -0500
Message-Id: <1327502278-1790-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 12/23] mini-os: make frontends and xenbus
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds compile-time logic to disable certain frontends in mini-os:
 - pcifront is disabled by default, enabled for ioemu
 - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default
 - xenbus is required for any frontend, and is enabled by default

If all frontends and xenbus are disabled, mini-os will run without
needing to communicate with xenstore, making it suitable to run the
xenstore daemon. The console frontend is not required for the initial
console, only consoles opened via openpt or ptmx.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile                            |   32 +++-
 extras/mini-os/console/console.c                   |    5 -
 extras/mini-os/console/console.h                   |    2 +
 .../mini-os/console/{xencons_ring.c => xenbus.c}   |  182 +-------------------
 extras/mini-os/console/xencons_ring.c              |  182 +-------------------
 extras/mini-os/include/lib.h                       |    2 +
 extras/mini-os/include/xenbus.h                    |   12 ++
 extras/mini-os/kernel.c                            |    4 -
 extras/mini-os/lib/sys.c                           |   43 +++++
 extras/mini-os/main.c                              |    6 +-
 stubdom/ioemu-minios.cfg                           |    1 +
 11 files changed, 96 insertions(+), 375 deletions(-)
 create mode 100644 extras/mini-os/console/console.h
 copy extras/mini-os/console/{xencons_ring.c => xenbus.c} (56%)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index 96c661a..ea5d0b5 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -19,11 +19,25 @@ endif
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
+CONFIG_PCIFRONT ?= n
+CONFIG_BLKFRONT ?= y
+CONFIG_NETFRONT ?= y
+CONFIG_FBFRONT ?= y
+CONFIG_KBDFRONT ?= y
+CONFIG_CONSFRONT ?= y
+CONFIG_XENBUS ?= y
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
+flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
+flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
+flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
+flags-$(CONFIG_CONSFRONT) += -DCONFIG_CONSFRONT
+flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 
 DEF_CFLAGS += $(flags-y)
 
@@ -49,10 +63,10 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
-src-y += blkfront.c
+src-$(CONFIG_BLKFRONT) += blkfront.c
 src-y += daytime.c
 src-y += events.c
-src-y += fbfront.c
+src-$(CONFIG_FBFRONT) += fbfront.c
 src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
@@ -60,8 +74,8 @@ src-y += kernel.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
-src-y += netfront.c
-src-y += pcifront.c
+src-$(CONFIG_NETFRONT) += netfront.c
+src-$(CONFIG_PCIFRONT) += pcifront.c
 src-y += sched.c
 src-$(CONFIG_TEST) += test.c
 
@@ -72,12 +86,13 @@ src-y += lib/stack_chk_fail.c
 src-y += lib/string.c
 src-y += lib/sys.c
 src-y += lib/xmalloc.c
-src-y += lib/xs.c
+src-$(CONFIG_XENBUS) += lib/xs.c
 
-src-y += xenbus/xenbus.c
+src-$(CONFIG_XENBUS) += xenbus/xenbus.c
 
 src-y += console/console.c
 src-y += console/xencons_ring.c
+src-$(CONFIG_CONSFRONT) += console/xenbus.c
 
 # The common mini-os objects to build.
 APP_OBJS :=
@@ -108,7 +123,10 @@ ifeq ($(lwip),y)
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
 LWO	:= $(patsubst %.c,%.o,$(LWC))
-LWO	+= $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
+LWO	+= $(OBJ_DIR)/lwip-arch.o
+ifeq ($(CONFIG_NETFRONT),y)
+LWO += $(OBJ_DIR)/lwip-net.o
+endif
 
 $(OBJ_DIR)/lwip.a: $(LWO)
 	$(RM) $@
diff --git a/extras/mini-os/console/console.c b/extras/mini-os/console/console.c
index 2b4ed9f..fec3791 100644
--- a/extras/mini-os/console/console.c
+++ b/extras/mini-os/console/console.c
@@ -158,8 +158,3 @@ void init_console(void)
     /* This is also required to notify the daemon */
     printk("done.\n");
 }
-
-void fini_console(struct consfront_dev *dev)
-{
-    if (dev) free_consfront(dev);
-}
diff --git a/extras/mini-os/console/console.h b/extras/mini-os/console/console.h
new file mode 100644
index 0000000..e85147a
--- /dev/null
+++ b/extras/mini-os/console/console.h
@@ -0,0 +1,2 @@
+
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data);
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xenbus.c
similarity index 56%
copy from extras/mini-os/console/xencons_ring.c
copy to extras/mini-os/console/xenbus.c
index af0afed..a7c517d 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xenbus.c
@@ -11,181 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
-
-DECLARE_WAIT_QUEUE_HEAD(console_queue);
-
-static inline void notify_daemon(struct consfront_dev *dev)
-{
-    /* Use evtchn: this is called early, before irq is set up. */
-    if (!dev)
-        notify_remote_via_evtchn(start_info.console.domU.evtchn);
-    else
-        notify_remote_via_evtchn(dev->evtchn);
-}
-
-static inline struct xencons_interface *xencons_interface(void)
-{
-    if (start_info.console.domU.evtchn)
-        return mfn_to_virt(start_info.console.domU.mfn);
-    else
-        return NULL;
-} 
- 
-int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
-{	
-    int sent = 0;
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-
-	if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-        if (!intf)
-            return sent;
-
-	cons = intf->out_cons;
-	prod = intf->out_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->out));
-
-	while ((sent < len) && ((prod - cons) < sizeof(intf->out)))
-		intf->out[MASK_XENCONS_IDX(prod++, intf->out)] = data[sent++];
-
-	wmb();
-	intf->out_prod = prod;
-    
-    return sent;
-}
-
-int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
-{
-    int sent;
-
-    sent = xencons_ring_send_no_notify(dev, data, len);
-    notify_daemon(dev);
-
-    return sent;
-}	
-
-
-
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
-{
-	struct consfront_dev *dev = (struct consfront_dev *) data;
-#ifdef HAVE_LIBC
-        int fd = dev ? dev->fd : -1;
-
-        if (fd != -1)
-            files[fd].read = 1;
-
-        wake_up(&console_queue);
-#else
-	struct xencons_interface *intf = xencons_interface();
-	XENCONS_RING_IDX cons, prod;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-	while (cons != prod) {
-		xencons_rx(intf->in+MASK_XENCONS_IDX(cons,intf->in), 1, regs);
-		cons++;
-	}
-
-	mb();
-	intf->in_cons = cons;
-
-	notify_daemon(dev);
-
-	xencons_tx();
-#endif
-}
-
-#ifdef HAVE_LIBC
-int xencons_ring_avail(struct consfront_dev *dev)
-{
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-
-        if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-        return prod - cons;
-}
-
-int xencons_ring_recv(struct consfront_dev *dev, char *data, unsigned len)
-{
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-        unsigned filled = 0;
-
-        if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-        while (filled < len && cons + filled != prod) {
-                data[filled] = *(intf->in + MASK_XENCONS_IDX(cons + filled, intf->in));
-                filled++;
-	}
-
-	mb();
-        intf->in_cons = cons + filled;
-
-	notify_daemon(dev);
-
-        return filled;
-}
-#endif
-
-struct consfront_dev *xencons_ring_init(void)
-{
-	int err;
-	struct consfront_dev *dev;
-
-	if (!start_info.console.domU.evtchn)
-		return 0;
-
-	dev = malloc(sizeof(struct consfront_dev));
-	memset(dev, 0, sizeof(struct consfront_dev));
-	dev->nodename = "device/console";
-	dev->dom = 0;
-	dev->backend = 0;
-	dev->ring_ref = 0;
-
-#ifdef HAVE_LIBC
-	dev->fd = -1;
-#endif
-	dev->evtchn = start_info.console.domU.evtchn;
-	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
-
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
-	if (err <= 0) {
-		printk("XEN console request chn bind failed %i\n", err);
-                free(dev);
-		return NULL;
-	}
-        unmask_evtchn(dev->evtchn);
-
-	/* In case we have in-flight data after save/restore... */
-	notify_daemon(dev);
-
-	return dev;
-}
+#include "console.h"
 
 void free_consfront(struct consfront_dev *dev)
 {
@@ -262,7 +88,7 @@ struct consfront_dev *init_consfront(char *_nodename)
         return NULL;
     else
         dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
+    evtchn_alloc_unbound(dev->dom, console_handle_input, dev, &dev->evtchn);
 
     dev->ring = (struct xencons_interface *) alloc_page();
     memset(dev->ring, 0, PAGE_SIZE);
@@ -364,8 +190,8 @@ error:
     return NULL;
 }
 
-void xencons_resume(void)
+void fini_console(struct consfront_dev *dev)
 {
-	(void)xencons_ring_init();
+    if (dev) free_consfront(dev);
 }
 
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index af0afed..81c8e99 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -11,6 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
+#include "console.h"
 
 DECLARE_WAIT_QUEUE_HEAD(console_queue);
 
@@ -70,7 +71,7 @@ int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
 
 
 
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
 	struct consfront_dev *dev = (struct consfront_dev *) data;
 #ifdef HAVE_LIBC
@@ -173,7 +174,7 @@ struct consfront_dev *xencons_ring_init(void)
 	dev->evtchn = start_info.console.domU.evtchn;
 	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
 
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
+	err = bind_evtchn(dev->evtchn, console_handle_input, dev);
 	if (err <= 0) {
 		printk("XEN console request chn bind failed %i\n", err);
                 free(dev);
@@ -187,183 +188,6 @@ struct consfront_dev *xencons_ring_init(void)
 	return dev;
 }
 
-void free_consfront(struct consfront_dev *dev)
-{
-    char* err = NULL;
-    XenbusState state;
-
-    char path[strlen(dev->backend) + 1 + 5 + 1];
-    char nodename[strlen(dev->nodename) + 1 + 5 + 1];
-
-    snprintf(path, sizeof(path), "%s/state", dev->backend);
-    snprintf(nodename, sizeof(nodename), "%s/state", dev->nodename);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosing)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosing, err);
-        goto close;
-    }
-    state = xenbus_read_integer(path);
-    while (err == NULL && state < XenbusStateClosing)
-        err = xenbus_wait_for_state_change(path, &state, &dev->events);
-    if (err) free(err);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosed)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosed, err);
-        goto close;
-    }
-
-close:
-    if (err) free(err);
-    xenbus_unwatch_path_token(XBT_NIL, path, path);
-
-    mask_evtchn(dev->evtchn);
-    unbind_evtchn(dev->evtchn);
-    free(dev->backend);
-    free(dev->nodename);
-
-    gnttab_end_access(dev->ring_ref);
-
-    free_page(dev->ring);
-    free(dev);
-}
-
-struct consfront_dev *init_consfront(char *_nodename)
-{
-    xenbus_transaction_t xbt;
-    char* err;
-    char* message=NULL;
-    int retry=0;
-    char* msg = NULL;
-    char nodename[256];
-    char path[256];
-    static int consfrontends = 3;
-    struct consfront_dev *dev;
-    int res;
-
-    if (!_nodename)
-        snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
-    else
-        strncpy(nodename, _nodename, sizeof(nodename));
-
-    printk("******************* CONSFRONT for %s **********\n\n\n", nodename);
-
-    consfrontends++;
-    dev = malloc(sizeof(*dev));
-    memset(dev, 0, sizeof(*dev));
-    dev->nodename = strdup(nodename);
-#ifdef HAVE_LIBC
-    dev->fd = -1;
-#endif
-
-    snprintf(path, sizeof(path), "%s/backend-id", nodename);
-    if ((res = xenbus_read_integer(path)) < 0) 
-        return NULL;
-    else
-        dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
-
-    dev->ring = (struct xencons_interface *) alloc_page();
-    memset(dev->ring, 0, PAGE_SIZE);
-    dev->ring_ref = gnttab_grant_access(dev->dom, virt_to_mfn(dev->ring), 0);
-
-    dev->events = NULL;
-
-again:
-    err = xenbus_transaction_start(&xbt);
-    if (err) {
-        printk("starting transaction\n");
-        free(err);
-    }
-
-    err = xenbus_printf(xbt, nodename, "ring-ref","%u",
-                dev->ring_ref);
-    if (err) {
-        message = "writing ring-ref";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "port", "%u", dev->evtchn);
-    if (err) {
-        message = "writing event-channel";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "protocol", "%s", XEN_IO_PROTO_ABI_NATIVE);
-    if (err) {
-        message = "writing protocol";
-        goto abort_transaction;
-    }
-
-    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
-    if (err) {
-        message = "writing type";
-        goto abort_transaction;
-    }
-
-    snprintf(path, sizeof(path), "%s/state", nodename);
-    err = xenbus_switch_state(xbt, path, XenbusStateConnected);
-    if (err) {
-        message = "switching state";
-        goto abort_transaction;
-    }
-
-
-    err = xenbus_transaction_end(xbt, 0, &retry);
-    if (err) free(err);
-    if (retry) {
-            goto again;
-        printk("completing transaction\n");
-    }
-
-    goto done;
-
-abort_transaction:
-    free(err);
-    err = xenbus_transaction_end(xbt, 1, &retry);
-    goto error;
-
-done:
-
-    snprintf(path, sizeof(path), "%s/backend", nodename);
-    msg = xenbus_read(XBT_NIL, path, &dev->backend);
-    if (msg) {
-        printk("Error %s when reading the backend path %s\n", msg, path);
-        goto error;
-    }
-
-    printk("backend at %s\n", dev->backend);
-
-    {
-        XenbusState state;
-        char path[strlen(dev->backend) + 1 + 19 + 1];
-        snprintf(path, sizeof(path), "%s/state", dev->backend);
-        
-	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
-        msg = NULL;
-        state = xenbus_read_integer(path);
-        while (msg == NULL && state < XenbusStateConnected)
-            msg = xenbus_wait_for_state_change(path, &state, &dev->events);
-        if (msg != NULL || state != XenbusStateConnected) {
-            printk("backend not available, state=%d\n", state);
-            xenbus_unwatch_path_token(XBT_NIL, path, path);
-            goto error;
-        }
-    }
-    unmask_evtchn(dev->evtchn);
-
-    printk("**************************\n");
-
-    return dev;
-
-error:
-    free(msg);
-    free(err);
-    free_consfront(dev);
-    return NULL;
-}
-
 void xencons_resume(void)
 {
 	(void)xencons_ring_init();
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 12070c3..9c69440 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -182,11 +182,13 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
              * FD.  */
             xenbus_event_queue events;
         } xenbus;
+#endif
     };
     int read;	/* maybe available for read */
 } files[];
diff --git a/extras/mini-os/include/xenbus.h b/extras/mini-os/include/xenbus.h
index de618fc..cd6316e 100644
--- a/extras/mini-os/include/xenbus.h
+++ b/extras/mini-os/include/xenbus.h
@@ -6,8 +6,14 @@
 typedef unsigned long xenbus_transaction_t;
 #define XBT_NIL ((xenbus_transaction_t)0)
 
+#ifdef CONFIG_XENBUS
 /* Initialize the XenBus system. */
 void init_xenbus(void);
+#else
+static inline void init_xenbus(void)
+{
+}
+#endif
 
 /* Read the value associated with a path.  Returns a malloc'd error
    string on failure and sets *value to NULL.  On success, *value is
@@ -98,7 +104,13 @@ char* xenbus_printf(xenbus_transaction_t xbt,
 /* Utility function to figure out our domain id */
 domid_t xenbus_get_self_id(void);
 
+#ifdef CONFIG_XENBUS
 /* Reset the XenBus system. */
 void fini_xenbus(void);
+#else
+static inline void fini_xenbus(void)
+{
+}
+#endif
 
 #endif /* XENBUS_H__ */
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index c8b9b8c..a8dfe6d 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -142,10 +142,6 @@ void stop_kernel(void)
     /* Reset grant tables */
     fini_gnttab();
 
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
     /* Reset XenBus */
     fini_xenbus();
 
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index b7b3aff..dcdf096 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -164,6 +164,7 @@ int mkdir(const char *pathname, mode_t mode)
     return -1;
 }
 
+#ifdef CONFIG_CONSFRONT
 int posix_openpt(int flags)
 {
     struct consfront_dev *dev;
@@ -192,6 +193,18 @@ int open_savefile(const char *path, int save)
     printk("fd(%d) = open_savefile\n", dev->fd);
     return(dev->fd);
 }
+#else
+int posix_openpt(int flags)
+{
+	errno = EIO;
+	return -1;
+}
+int open_savefile(const char *path, int save)
+{
+	errno = EIO;
+	return -1;
+}
+#endif
 
 int open(const char *pathname, int flags, ...)
 {
@@ -241,6 +254,7 @@ int read(int fd, void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_read(files[fd].socket.fd, buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP: {
 	    ssize_t ret;
 	    ret = netfront_receive(files[fd].tap.dev, buf, nbytes);
@@ -250,6 +264,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret;
 	}
+#endif
+#ifdef CONFIG_KBDFRONT
         case FTYPE_KBD: {
             int ret, n;
             n = nbytes / sizeof(union xenkbd_in_event);
@@ -260,6 +276,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenkbd_in_event);
         }
+#endif
+#ifdef CONFIG_FBFRONT
         case FTYPE_FB: {
             int ret, n;
             n = nbytes / sizeof(union xenfb_in_event);
@@ -270,6 +288,7 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenfb_in_event);
         }
+#endif
 	default:
 	    break;
     }
@@ -297,9 +316,11 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_write(files[fd].socket.fd, (void*) buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
+#endif
 	default:
 	    break;
     }
@@ -326,9 +347,11 @@ int close(int fd)
         default:
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
             xs_daemon_close((void*)(intptr_t) fd);
             return 0;
+#endif
 #ifdef HAVE_LWIP
 	case FTYPE_SOCKET: {
 	    int res = lwip_close(files[fd].socket.fd);
@@ -345,27 +368,37 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_BLKFRONT
 	case FTYPE_BLK:
             shutdown_blkfront(files[fd].blk.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_FBFRONT
 	case FTYPE_FB:
             shutdown_fbfront(files[fd].fb.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_CONSFRONT
         case FTYPE_SAVEFILE:
         case FTYPE_CONSOLE:
             fini_console(files[fd].cons.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
 	case FTYPE_NONE:
 	    break;
     }
@@ -611,6 +644,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
                 n++;
 	    FD_CLR(i, exceptfds);
 	    break;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
 	    if (FD_ISSET(i, readfds)) {
                 if (files[i].xenbus.events)
@@ -621,6 +655,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
 	    FD_CLR(i, writefds);
 	    FD_CLR(i, exceptfds);
 	    break;
+#endif
 	case FTYPE_EVTCHN:
 	case FTYPE_TAP:
 	case FTYPE_BLK:
@@ -727,11 +762,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
+#ifdef CONFIG_NETFRONT
     add_waiter(w1, netfront_queue);
+#endif
     add_waiter(w2, event_queue);
+#ifdef CONFIG_BLKFRONT
     add_waiter(w3, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     add_waiter(w4, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     add_waiter(w5, kbdfront_queue);
+#endif
     add_waiter(w6, console_queue);
 
     if (readfds)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index aeda548..73eb6fb 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -63,10 +63,12 @@ static void call_main(void *p)
 #ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #endif
-#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK) && defined(CONFIG_NETFRONT)
     start_networking();
 #endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
@@ -169,7 +171,7 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
-#ifdef HAVE_LWIP
+#if defined(HAVE_LWIP) && defined(CONFIG_NETFRONT)
     stop_networking();
 #endif
     stop_kernel();
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
index 7ea1d2f..e3a96da 100644
--- a/stubdom/ioemu-minios.cfg
+++ b/stubdom/ioemu-minios.cfg
@@ -1 +1,2 @@
 CONFIG_QEMU_XS_ARGS=y
+CONFIG_PCIFRONT=y
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3zZ-0008VV-DA; Wed, 25 Jan 2012 14:38:29 +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 1Rq3zT-0008IC-L6
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:24 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327502294!12342830!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18424 invoked from network); 25 Jan 2012 14:38:15 -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;
	25 Jan 2012 14:38:15 -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
	q0PEcCUH003896
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx2011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:47 -0500
Message-Id: <1327502278-1790-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 12/23] mini-os: make frontends and xenbus
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds compile-time logic to disable certain frontends in mini-os:
 - pcifront is disabled by default, enabled for ioemu
 - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default
 - xenbus is required for any frontend, and is enabled by default

If all frontends and xenbus are disabled, mini-os will run without
needing to communicate with xenstore, making it suitable to run the
xenstore daemon. The console frontend is not required for the initial
console, only consoles opened via openpt or ptmx.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile                            |   32 +++-
 extras/mini-os/console/console.c                   |    5 -
 extras/mini-os/console/console.h                   |    2 +
 .../mini-os/console/{xencons_ring.c => xenbus.c}   |  182 +-------------------
 extras/mini-os/console/xencons_ring.c              |  182 +-------------------
 extras/mini-os/include/lib.h                       |    2 +
 extras/mini-os/include/xenbus.h                    |   12 ++
 extras/mini-os/kernel.c                            |    4 -
 extras/mini-os/lib/sys.c                           |   43 +++++
 extras/mini-os/main.c                              |    6 +-
 stubdom/ioemu-minios.cfg                           |    1 +
 11 files changed, 96 insertions(+), 375 deletions(-)
 create mode 100644 extras/mini-os/console/console.h
 copy extras/mini-os/console/{xencons_ring.c => xenbus.c} (56%)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index 96c661a..ea5d0b5 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -19,11 +19,25 @@ endif
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
+CONFIG_PCIFRONT ?= n
+CONFIG_BLKFRONT ?= y
+CONFIG_NETFRONT ?= y
+CONFIG_FBFRONT ?= y
+CONFIG_KBDFRONT ?= y
+CONFIG_CONSFRONT ?= y
+CONFIG_XENBUS ?= y
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
+flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
+flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
+flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
+flags-$(CONFIG_CONSFRONT) += -DCONFIG_CONSFRONT
+flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 
 DEF_CFLAGS += $(flags-y)
 
@@ -49,10 +63,10 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
-src-y += blkfront.c
+src-$(CONFIG_BLKFRONT) += blkfront.c
 src-y += daytime.c
 src-y += events.c
-src-y += fbfront.c
+src-$(CONFIG_FBFRONT) += fbfront.c
 src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
@@ -60,8 +74,8 @@ src-y += kernel.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
-src-y += netfront.c
-src-y += pcifront.c
+src-$(CONFIG_NETFRONT) += netfront.c
+src-$(CONFIG_PCIFRONT) += pcifront.c
 src-y += sched.c
 src-$(CONFIG_TEST) += test.c
 
@@ -72,12 +86,13 @@ src-y += lib/stack_chk_fail.c
 src-y += lib/string.c
 src-y += lib/sys.c
 src-y += lib/xmalloc.c
-src-y += lib/xs.c
+src-$(CONFIG_XENBUS) += lib/xs.c
 
-src-y += xenbus/xenbus.c
+src-$(CONFIG_XENBUS) += xenbus/xenbus.c
 
 src-y += console/console.c
 src-y += console/xencons_ring.c
+src-$(CONFIG_CONSFRONT) += console/xenbus.c
 
 # The common mini-os objects to build.
 APP_OBJS :=
@@ -108,7 +123,10 @@ ifeq ($(lwip),y)
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
 LWO	:= $(patsubst %.c,%.o,$(LWC))
-LWO	+= $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
+LWO	+= $(OBJ_DIR)/lwip-arch.o
+ifeq ($(CONFIG_NETFRONT),y)
+LWO += $(OBJ_DIR)/lwip-net.o
+endif
 
 $(OBJ_DIR)/lwip.a: $(LWO)
 	$(RM) $@
diff --git a/extras/mini-os/console/console.c b/extras/mini-os/console/console.c
index 2b4ed9f..fec3791 100644
--- a/extras/mini-os/console/console.c
+++ b/extras/mini-os/console/console.c
@@ -158,8 +158,3 @@ void init_console(void)
     /* This is also required to notify the daemon */
     printk("done.\n");
 }
-
-void fini_console(struct consfront_dev *dev)
-{
-    if (dev) free_consfront(dev);
-}
diff --git a/extras/mini-os/console/console.h b/extras/mini-os/console/console.h
new file mode 100644
index 0000000..e85147a
--- /dev/null
+++ b/extras/mini-os/console/console.h
@@ -0,0 +1,2 @@
+
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data);
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xenbus.c
similarity index 56%
copy from extras/mini-os/console/xencons_ring.c
copy to extras/mini-os/console/xenbus.c
index af0afed..a7c517d 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xenbus.c
@@ -11,181 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
-
-DECLARE_WAIT_QUEUE_HEAD(console_queue);
-
-static inline void notify_daemon(struct consfront_dev *dev)
-{
-    /* Use evtchn: this is called early, before irq is set up. */
-    if (!dev)
-        notify_remote_via_evtchn(start_info.console.domU.evtchn);
-    else
-        notify_remote_via_evtchn(dev->evtchn);
-}
-
-static inline struct xencons_interface *xencons_interface(void)
-{
-    if (start_info.console.domU.evtchn)
-        return mfn_to_virt(start_info.console.domU.mfn);
-    else
-        return NULL;
-} 
- 
-int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
-{	
-    int sent = 0;
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-
-	if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-        if (!intf)
-            return sent;
-
-	cons = intf->out_cons;
-	prod = intf->out_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->out));
-
-	while ((sent < len) && ((prod - cons) < sizeof(intf->out)))
-		intf->out[MASK_XENCONS_IDX(prod++, intf->out)] = data[sent++];
-
-	wmb();
-	intf->out_prod = prod;
-    
-    return sent;
-}
-
-int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
-{
-    int sent;
-
-    sent = xencons_ring_send_no_notify(dev, data, len);
-    notify_daemon(dev);
-
-    return sent;
-}	
-
-
-
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
-{
-	struct consfront_dev *dev = (struct consfront_dev *) data;
-#ifdef HAVE_LIBC
-        int fd = dev ? dev->fd : -1;
-
-        if (fd != -1)
-            files[fd].read = 1;
-
-        wake_up(&console_queue);
-#else
-	struct xencons_interface *intf = xencons_interface();
-	XENCONS_RING_IDX cons, prod;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-	while (cons != prod) {
-		xencons_rx(intf->in+MASK_XENCONS_IDX(cons,intf->in), 1, regs);
-		cons++;
-	}
-
-	mb();
-	intf->in_cons = cons;
-
-	notify_daemon(dev);
-
-	xencons_tx();
-#endif
-}
-
-#ifdef HAVE_LIBC
-int xencons_ring_avail(struct consfront_dev *dev)
-{
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-
-        if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-        return prod - cons;
-}
-
-int xencons_ring_recv(struct consfront_dev *dev, char *data, unsigned len)
-{
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-        unsigned filled = 0;
-
-        if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-        while (filled < len && cons + filled != prod) {
-                data[filled] = *(intf->in + MASK_XENCONS_IDX(cons + filled, intf->in));
-                filled++;
-	}
-
-	mb();
-        intf->in_cons = cons + filled;
-
-	notify_daemon(dev);
-
-        return filled;
-}
-#endif
-
-struct consfront_dev *xencons_ring_init(void)
-{
-	int err;
-	struct consfront_dev *dev;
-
-	if (!start_info.console.domU.evtchn)
-		return 0;
-
-	dev = malloc(sizeof(struct consfront_dev));
-	memset(dev, 0, sizeof(struct consfront_dev));
-	dev->nodename = "device/console";
-	dev->dom = 0;
-	dev->backend = 0;
-	dev->ring_ref = 0;
-
-#ifdef HAVE_LIBC
-	dev->fd = -1;
-#endif
-	dev->evtchn = start_info.console.domU.evtchn;
-	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
-
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
-	if (err <= 0) {
-		printk("XEN console request chn bind failed %i\n", err);
-                free(dev);
-		return NULL;
-	}
-        unmask_evtchn(dev->evtchn);
-
-	/* In case we have in-flight data after save/restore... */
-	notify_daemon(dev);
-
-	return dev;
-}
+#include "console.h"
 
 void free_consfront(struct consfront_dev *dev)
 {
@@ -262,7 +88,7 @@ struct consfront_dev *init_consfront(char *_nodename)
         return NULL;
     else
         dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
+    evtchn_alloc_unbound(dev->dom, console_handle_input, dev, &dev->evtchn);
 
     dev->ring = (struct xencons_interface *) alloc_page();
     memset(dev->ring, 0, PAGE_SIZE);
@@ -364,8 +190,8 @@ error:
     return NULL;
 }
 
-void xencons_resume(void)
+void fini_console(struct consfront_dev *dev)
 {
-	(void)xencons_ring_init();
+    if (dev) free_consfront(dev);
 }
 
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index af0afed..81c8e99 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -11,6 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
+#include "console.h"
 
 DECLARE_WAIT_QUEUE_HEAD(console_queue);
 
@@ -70,7 +71,7 @@ int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
 
 
 
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
 	struct consfront_dev *dev = (struct consfront_dev *) data;
 #ifdef HAVE_LIBC
@@ -173,7 +174,7 @@ struct consfront_dev *xencons_ring_init(void)
 	dev->evtchn = start_info.console.domU.evtchn;
 	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
 
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
+	err = bind_evtchn(dev->evtchn, console_handle_input, dev);
 	if (err <= 0) {
 		printk("XEN console request chn bind failed %i\n", err);
                 free(dev);
@@ -187,183 +188,6 @@ struct consfront_dev *xencons_ring_init(void)
 	return dev;
 }
 
-void free_consfront(struct consfront_dev *dev)
-{
-    char* err = NULL;
-    XenbusState state;
-
-    char path[strlen(dev->backend) + 1 + 5 + 1];
-    char nodename[strlen(dev->nodename) + 1 + 5 + 1];
-
-    snprintf(path, sizeof(path), "%s/state", dev->backend);
-    snprintf(nodename, sizeof(nodename), "%s/state", dev->nodename);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosing)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosing, err);
-        goto close;
-    }
-    state = xenbus_read_integer(path);
-    while (err == NULL && state < XenbusStateClosing)
-        err = xenbus_wait_for_state_change(path, &state, &dev->events);
-    if (err) free(err);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosed)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosed, err);
-        goto close;
-    }
-
-close:
-    if (err) free(err);
-    xenbus_unwatch_path_token(XBT_NIL, path, path);
-
-    mask_evtchn(dev->evtchn);
-    unbind_evtchn(dev->evtchn);
-    free(dev->backend);
-    free(dev->nodename);
-
-    gnttab_end_access(dev->ring_ref);
-
-    free_page(dev->ring);
-    free(dev);
-}
-
-struct consfront_dev *init_consfront(char *_nodename)
-{
-    xenbus_transaction_t xbt;
-    char* err;
-    char* message=NULL;
-    int retry=0;
-    char* msg = NULL;
-    char nodename[256];
-    char path[256];
-    static int consfrontends = 3;
-    struct consfront_dev *dev;
-    int res;
-
-    if (!_nodename)
-        snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
-    else
-        strncpy(nodename, _nodename, sizeof(nodename));
-
-    printk("******************* CONSFRONT for %s **********\n\n\n", nodename);
-
-    consfrontends++;
-    dev = malloc(sizeof(*dev));
-    memset(dev, 0, sizeof(*dev));
-    dev->nodename = strdup(nodename);
-#ifdef HAVE_LIBC
-    dev->fd = -1;
-#endif
-
-    snprintf(path, sizeof(path), "%s/backend-id", nodename);
-    if ((res = xenbus_read_integer(path)) < 0) 
-        return NULL;
-    else
-        dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
-
-    dev->ring = (struct xencons_interface *) alloc_page();
-    memset(dev->ring, 0, PAGE_SIZE);
-    dev->ring_ref = gnttab_grant_access(dev->dom, virt_to_mfn(dev->ring), 0);
-
-    dev->events = NULL;
-
-again:
-    err = xenbus_transaction_start(&xbt);
-    if (err) {
-        printk("starting transaction\n");
-        free(err);
-    }
-
-    err = xenbus_printf(xbt, nodename, "ring-ref","%u",
-                dev->ring_ref);
-    if (err) {
-        message = "writing ring-ref";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "port", "%u", dev->evtchn);
-    if (err) {
-        message = "writing event-channel";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "protocol", "%s", XEN_IO_PROTO_ABI_NATIVE);
-    if (err) {
-        message = "writing protocol";
-        goto abort_transaction;
-    }
-
-    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
-    if (err) {
-        message = "writing type";
-        goto abort_transaction;
-    }
-
-    snprintf(path, sizeof(path), "%s/state", nodename);
-    err = xenbus_switch_state(xbt, path, XenbusStateConnected);
-    if (err) {
-        message = "switching state";
-        goto abort_transaction;
-    }
-
-
-    err = xenbus_transaction_end(xbt, 0, &retry);
-    if (err) free(err);
-    if (retry) {
-            goto again;
-        printk("completing transaction\n");
-    }
-
-    goto done;
-
-abort_transaction:
-    free(err);
-    err = xenbus_transaction_end(xbt, 1, &retry);
-    goto error;
-
-done:
-
-    snprintf(path, sizeof(path), "%s/backend", nodename);
-    msg = xenbus_read(XBT_NIL, path, &dev->backend);
-    if (msg) {
-        printk("Error %s when reading the backend path %s\n", msg, path);
-        goto error;
-    }
-
-    printk("backend at %s\n", dev->backend);
-
-    {
-        XenbusState state;
-        char path[strlen(dev->backend) + 1 + 19 + 1];
-        snprintf(path, sizeof(path), "%s/state", dev->backend);
-        
-	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
-        msg = NULL;
-        state = xenbus_read_integer(path);
-        while (msg == NULL && state < XenbusStateConnected)
-            msg = xenbus_wait_for_state_change(path, &state, &dev->events);
-        if (msg != NULL || state != XenbusStateConnected) {
-            printk("backend not available, state=%d\n", state);
-            xenbus_unwatch_path_token(XBT_NIL, path, path);
-            goto error;
-        }
-    }
-    unmask_evtchn(dev->evtchn);
-
-    printk("**************************\n");
-
-    return dev;
-
-error:
-    free(msg);
-    free(err);
-    free_consfront(dev);
-    return NULL;
-}
-
 void xencons_resume(void)
 {
 	(void)xencons_ring_init();
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 12070c3..9c69440 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -182,11 +182,13 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
              * FD.  */
             xenbus_event_queue events;
         } xenbus;
+#endif
     };
     int read;	/* maybe available for read */
 } files[];
diff --git a/extras/mini-os/include/xenbus.h b/extras/mini-os/include/xenbus.h
index de618fc..cd6316e 100644
--- a/extras/mini-os/include/xenbus.h
+++ b/extras/mini-os/include/xenbus.h
@@ -6,8 +6,14 @@
 typedef unsigned long xenbus_transaction_t;
 #define XBT_NIL ((xenbus_transaction_t)0)
 
+#ifdef CONFIG_XENBUS
 /* Initialize the XenBus system. */
 void init_xenbus(void);
+#else
+static inline void init_xenbus(void)
+{
+}
+#endif
 
 /* Read the value associated with a path.  Returns a malloc'd error
    string on failure and sets *value to NULL.  On success, *value is
@@ -98,7 +104,13 @@ char* xenbus_printf(xenbus_transaction_t xbt,
 /* Utility function to figure out our domain id */
 domid_t xenbus_get_self_id(void);
 
+#ifdef CONFIG_XENBUS
 /* Reset the XenBus system. */
 void fini_xenbus(void);
+#else
+static inline void fini_xenbus(void)
+{
+}
+#endif
 
 #endif /* XENBUS_H__ */
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index c8b9b8c..a8dfe6d 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -142,10 +142,6 @@ void stop_kernel(void)
     /* Reset grant tables */
     fini_gnttab();
 
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
     /* Reset XenBus */
     fini_xenbus();
 
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index b7b3aff..dcdf096 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -164,6 +164,7 @@ int mkdir(const char *pathname, mode_t mode)
     return -1;
 }
 
+#ifdef CONFIG_CONSFRONT
 int posix_openpt(int flags)
 {
     struct consfront_dev *dev;
@@ -192,6 +193,18 @@ int open_savefile(const char *path, int save)
     printk("fd(%d) = open_savefile\n", dev->fd);
     return(dev->fd);
 }
+#else
+int posix_openpt(int flags)
+{
+	errno = EIO;
+	return -1;
+}
+int open_savefile(const char *path, int save)
+{
+	errno = EIO;
+	return -1;
+}
+#endif
 
 int open(const char *pathname, int flags, ...)
 {
@@ -241,6 +254,7 @@ int read(int fd, void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_read(files[fd].socket.fd, buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP: {
 	    ssize_t ret;
 	    ret = netfront_receive(files[fd].tap.dev, buf, nbytes);
@@ -250,6 +264,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret;
 	}
+#endif
+#ifdef CONFIG_KBDFRONT
         case FTYPE_KBD: {
             int ret, n;
             n = nbytes / sizeof(union xenkbd_in_event);
@@ -260,6 +276,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenkbd_in_event);
         }
+#endif
+#ifdef CONFIG_FBFRONT
         case FTYPE_FB: {
             int ret, n;
             n = nbytes / sizeof(union xenfb_in_event);
@@ -270,6 +288,7 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenfb_in_event);
         }
+#endif
 	default:
 	    break;
     }
@@ -297,9 +316,11 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_write(files[fd].socket.fd, (void*) buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
+#endif
 	default:
 	    break;
     }
@@ -326,9 +347,11 @@ int close(int fd)
         default:
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
             xs_daemon_close((void*)(intptr_t) fd);
             return 0;
+#endif
 #ifdef HAVE_LWIP
 	case FTYPE_SOCKET: {
 	    int res = lwip_close(files[fd].socket.fd);
@@ -345,27 +368,37 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_BLKFRONT
 	case FTYPE_BLK:
             shutdown_blkfront(files[fd].blk.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_FBFRONT
 	case FTYPE_FB:
             shutdown_fbfront(files[fd].fb.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_CONSFRONT
         case FTYPE_SAVEFILE:
         case FTYPE_CONSOLE:
             fini_console(files[fd].cons.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
 	case FTYPE_NONE:
 	    break;
     }
@@ -611,6 +644,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
                 n++;
 	    FD_CLR(i, exceptfds);
 	    break;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
 	    if (FD_ISSET(i, readfds)) {
                 if (files[i].xenbus.events)
@@ -621,6 +655,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
 	    FD_CLR(i, writefds);
 	    FD_CLR(i, exceptfds);
 	    break;
+#endif
 	case FTYPE_EVTCHN:
 	case FTYPE_TAP:
 	case FTYPE_BLK:
@@ -727,11 +762,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
+#ifdef CONFIG_NETFRONT
     add_waiter(w1, netfront_queue);
+#endif
     add_waiter(w2, event_queue);
+#ifdef CONFIG_BLKFRONT
     add_waiter(w3, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     add_waiter(w4, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     add_waiter(w5, kbdfront_queue);
+#endif
     add_waiter(w6, console_queue);
 
     if (readfds)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index aeda548..73eb6fb 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -63,10 +63,12 @@ static void call_main(void *p)
 #ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #endif
-#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK) && defined(CONFIG_NETFRONT)
     start_networking();
 #endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
@@ -169,7 +171,7 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
-#ifdef HAVE_LWIP
+#if defined(HAVE_LWIP) && defined(CONFIG_NETFRONT)
     stop_networking();
 #endif
     stop_kernel();
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
index 7ea1d2f..e3a96da 100644
--- a/stubdom/ioemu-minios.cfg
+++ b/stubdom/ioemu-minios.cfg
@@ -1 +1,2 @@
 CONFIG_QEMU_XS_ARGS=y
+CONFIG_PCIFRONT=y
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zY-0008UZ-UO; Wed, 25 Jan 2012 14:38:28 +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 1Rq3zT-0008IB-EX
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327502294!12340865!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16721 invoked from network); 25 Jan 2012 14:38:15 -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;
	25 Jan 2012 14:38:15 -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
	q0PEcCUH003893
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCww011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:43 -0500
Message-Id: <1327502278-1790-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/23] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..af0afed 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+        if (!intf)
+            return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:38:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq3zY-0008UZ-UO; Wed, 25 Jan 2012 14:38:28 +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 1Rq3zT-0008IB-EX
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:23 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327502294!12340865!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16721 invoked from network); 25 Jan 2012 14:38:15 -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;
	25 Jan 2012 14:38:15 -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
	q0PEcCUH003893
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCww011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:43 -0500
Message-Id: <1327502278-1790-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/23] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..af0afed 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+        if (!intf)
+            return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3zg-0000KR-Cl; Wed, 25 Jan 2012 14:38:36 +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 1Rq3za-0008OJ-MN
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:30 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327502304!11922106!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18217 invoked from network); 25 Jan 2012 14:38:24 -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;
	25 Jan 2012 14:38:24 -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
	q0PEcCUH003897
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx3011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:48 -0500
Message-Id: <1327502278-1790-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 13/23] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The symbol _LINUX_LIST_H collides with other header files.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:38:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14: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 1Rq3zg-0000KR-Cl; Wed, 25 Jan 2012 14:38:36 +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 1Rq3za-0008OJ-MN
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:38:30 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327502304!11922106!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18217 invoked from network); 25 Jan 2012 14:38:24 -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;
	25 Jan 2012 14:38:24 -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
	q0PEcCUH003897
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 14:38: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 q0PEcCx3011600; 
	Wed, 25 Jan 2012 09:38:12 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 09:37:48 -0500
Message-Id: <1327502278-1790-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 13/23] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The symbol _LINUX_LIST_H collides with other header files.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:41:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq428-0002Zy-Ja; Wed, 25 Jan 2012 14:41:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq427-0002Z7-3O
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:41:07 +0000
Received: from [85.158.138.51:51384] by server-10.bemta-3.messagelabs.com id
	FF/90-20948-284102F4; Wed, 25 Jan 2012 14:41:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327502465!10640735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10355 invoked from network); 25 Jan 2012 14:41:05 -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;
	25 Jan 2012 14:41:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:41: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, 25 Jan 2012 14:41:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 25 Jan 2012 14:41:04 +0000
In-Reply-To: <CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327502464.24561.325.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDE0OjMzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8yMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE5ld2x5IHVwZGF0ZWQgbGlzdCBmb2xsb3dzLiBQbGVhc2Ugc2VuZCBtZSBjb3JyZWN0aW9ucyAo
ZXNwZWNpYWxseQo+ID4gImRvbmUiKS4gSSd2ZSBzdG9wcGVkIENDaW5nIGV2ZXJ5b25lLCBzaW5j
ZSBJIGd1ZXNzIGl0IGlzIG1vc3RseSBzcGFtIHRvCj4gPiB0aGUgbWFqb3JpdHkuCj4gPgo+ID4g
aHlwZXJ2aXNvciwgYmxvY2tlcnM6Cj4gPgo+ID4gICAgICAqIHJvdW5kLXVwIG9mIHRoZSBjbG9z
aW5nIG9mIHRoZSBzZWN1cml0eSBob2xlIGluIE1TSS1YCj4gPiAgICAgICAgcGFzc3Rocm91Z2gg
KHVuaWZvcm1seSAtIGkuZS4gZXZlbiBmb3IgRG9tMCAtIGRpc2FsbG93aW5nIHdyaXRlCj4gPiAg
ICAgICAgYWNjZXNzIHRvIE1TSS1YIHRhYmxlIHBhZ2VzKS4gKEphbiBCZXVsaWNoIC0tIG1vcmUg
Zml4ZXMKPiA+ICAgICAgICByZXF1aXJlZCB0aGFuIGZpcnN0IHRob3VnaHQsIHBhdGNoZXMgcG9z
dGVkKQo+ID4gICAgICAqIGRvbWN0bHMgLyBzeXNjdGxzIHNldCB1cCB0byBtb2RpZnkgc2NoZWR1
bGVyIHBhcmFtZXRlcnMsIGxpa2UKPiA+ICAgICAgICB0aGUgY3JlZGl0MSB0aW1lc2xpY2UgYW5k
IHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwKQo+ID4gICAgICAqIGdldCB0aGUgaW50ZXJm
YWNlIGNoYW5nZXMgZm9yIHNoYXJpbmcvcGFnaW5nL21lbS1ldmVudHMgZG9uZSBhbmQKPiA+ICAg
ICAgICBkdXN0ZWQgc28gdGhhdCA0LjIgaXMgYSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4g
KFRpbSBEZWVnYW4sCj4gPiAgICAgICAgQW5kcmVzIExhZ2FyLUNhdmlsbGEgZXQgYWwpCj4gPiAg
ICAgICAgICAgICAgKiBtZW0gZXZlbnQgcmluZyBtYW5hZ2VtZW50IHBvc3RlZCwgc2VlbXMgY2xv
c2UgdG8gZ29pbmcKPiA+ICAgICAgICAgICAgICAgIGluLgo+ID4gICAgICAgICAgICAgICogc2hh
cmluZyBwYXRjaGVzIHBvc3RlZAo+ID4KPiA+IHRvb2xzLCBibG9ja2VyczoKPiA+Cj4gPiAgICAg
ICogbGlieGwgc3RhYmxlIEFQSSAtLSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFi
bGUgQVBJCj4gPiAgICAgICAgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9u
IG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgo+ID4gICAgICAgIHRoaXMgYXJlOgo+ID4gICAgICAg
ICAgICAgICogZXZlbnQgaGFuZGxpbmcgKElhbiBKYWNrc29uLCBwb3N0ZWQgc2V2ZXJhbCByb3Vu
ZHMsCj4gPiAgICAgICAgICAgICAgICBuZWFyaW5nIGNvbXBsZXRpb24/KQo+ID4gICAgICAgICAg
ICAgICogZHJvcCBsaWJ4bF9kZXZpY2VfbW9kZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2lu
Zm8gb3IKPiA+ICAgICAgICAgICAgICAgIGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkgKElhbiBD
YW1wYmVsbCwgZmlyc3QgUkZDIHNlbnQpCj4gPiAgICAgICAgICAgICAgKiBhZGQgbGlieGxfZGVm
Ym9vbCBhbmQgZ2VuZXJhbGx5IHRyeSBhbmQgYXJyYW5nZSB0aGF0Cj4gPiAgICAgICAgICAgICAg
ICBtZW1zZXQoZm9vLDAsLi4uKSByZXF1ZXN0cyB0aGUgZGVmYXVsdHMgKElhbiBDYW1wYmVsbCwK
PiA+ICAgICAgICAgICAgICAgIGZpcnN0IFJGQyBzZW50KQo+ID4gICAgICAgICAgICAgICogdG9w
b2xvZ3lpbmZvIGRhdGFzdHJ1Y3R1cmUgc2hvdWxkIGJlIGEgbGlzdCBvZiB0dXBsZXMsCj4gPiAg
ICAgICAgICAgICAgICBub3QgYSB0dXBsZSBvZiBsaXN0cy4gKG5vYm9keSBjdXJyZW50bHkgbG9v
a2luZyBhdCB0aGlzLAo+ID4gICAgICAgICAgICAgICAgbm90IDEwMCUgc3VyZSB0aGlzIG1ha2Vz
IHNlbnNlLCBjb3VsZCBwb3NzaWJseSBkZWZlciBhbmQKPiA+ICAgICAgICAgICAgICAgIGNoYW5n
ZSBhZnRlciA0LjIgaW4gYSBjb21wYXRpYmxlIHdheSkKPiA+ICAgICAgKiB4bCB0byB1c2UganNv
biBmb3IgbWFjaGluZSByZWFkYWJsZSBvdXRwdXQgaW5zdGVhZCBvZiBzZXhwIGJ5Cj4gPiAgICAg
ICAgZGVmYXVsdCAoSWFuIENhbXBiZWxsIHRvIHJldmlzaXQgZXhpc3RpbmcgcGF0Y2gpCj4gPiAg
ICAgICogeGwgc3VwcG9ydCBmb3IgdmNwdSBwaW5uaW5nIChEYXJpbyBGYWdnaW9saSkKPiA+ICAg
ICAgKiB4bCBmZWF0dXJlIHBhcml0eSB3aXRoIHhlbmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9y
dCAoR2VvcmdlCj4gPiAgICAgICAgRHVubGFwKQo+ID4gICAgICAqIEludGVncmF0ZSBxZW11K3Nl
YWJpb3MgdXBzdHJlYW0gaW50byB0aGUgYnVpbGQgKHBhdGNoZXMKPiA+ICAgICAgICByZXBvc3Rl
ZCwgcGVuZGluZykuIE5vIGNoYW5nZSBpbiBkZWZhdWx0IHFlbXUgZm9yIDQuMi4KPiA+ICAgICAg
KiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFk
eSBpbgo+ID4gICAgICAgIHRyZWUuIE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0
aW9uIGFyb3VuZCAtcmMxIHRvCj4gPiAgICAgICAgcmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgo+
ID4KPiA+IGh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKPiA+Cj4gPiAgICAgICogc29saWQgaW1w
bGVtZW50YXRpb24gb2Ygc2hhcmluZy9wYWdpbmcvbWVtLWV2ZW50cyAodXNpbmcgd29yawo+ID4g
ICAgICAgIHF1ZXVlcykgKFRpbSBEZWVnYW4sIE9sYWYgSGVycmluZyBldCBhbCkKPiA+ICAgICAg
KiBBIGxvbmcgc3RhbmRpbmcgaXNzdWUgaXMgYSBmdWxseSBzeW5jaHJvbml6ZWQgcDJtIChsb2Nr
aW5nCj4gPiAgICAgICAgbG9va3VwcykgKEFuZHJlcyBMYWdhci1DYXZpbGxhKQo+ID4gICAgICAq
IE5VTUEgaW1wcm92ZW1lbnQ6IGRvbWFpbiBhZmZpbml0eSBjb25zaXN0ZW50IHdpdGggY3B1cG9v
bAo+ID4gICAgICAgIG1lbWJlcnNoaXAgKERhcmlvIEZhZ2dpb2xpLCBKZXVyZ2VuIEdyb3NzIC0t
IHBhdGNoIHBvc3RlZCkKPiA+Cj4gPiB0b29scywgbmljZSB0byBoYXZlOgo+ID4KPiA+ICAgICAg
KiBIb3RwbHVnIHNjcmlwdCBzdHVmZiAtLSBpbnRlcm5hbCB0byBsaWJ4bCAoSSB0aGluaywgdGhl
cmVmb3JlIEkKPiA+ICAgICAgICBkaWRuJ3QgcHV0IHRoaXMgdW5kZXIgc3RhYmxlIEFQSSBhYm92
ZSkgYnV0IHN0aWxsIGdvb2QgdG8gaGF2ZQo+ID4gICAgICAgIGZvciA0LjI/IFJvZ2VyIFBhdSBN
b25ldCB3YXMgbG9va2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9va2luZwo+ID4gICAgICAgIGxpa2Ug
YSBiaWcgY2FuLW8td29ybXMuIChkaXNjdXNzaW9uIG9uLWdvaW5nKQo+ID4gICAgICAqIEJsb2Nr
IHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIK
PiA+ICAgICAgICBQYXUgTW9uZXQpCj4gPiAgICAgICogbGlieWFqbCB2MiBzdXBwb3J0IChwYXRj
aCBwb3N0ZWQgYnkgUm9nZXIgUGF1IE1vbmV0LCBibG9ja2VkIG9uCj4gPiAgICAgICAgYXV0b2Nv
bmY/KQo+ID4gICAgICAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9s
YWYgSGVycmluZykKPiA+ICAgICAgKiBVcHN0cmVhbSBxZW11IGZlYXR1cmUgcGF0Y2hlczoKPiA+
ICAgICAgICAgICAgICAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFu
dGhvbnkgUGVyYXJkKQo+ID4gICAgICAgICAgICAgICogVXBzdHJlYW0gcWVtdSBzYXZlIHJlc3Rv
cmUgKEFudGhvbnkgUGVyYXJkKQo+ID4gICAgICAqIE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3Vy
cmVudGx5IHNob3VsZCBiZSBtYXJrZWQKPiA+ICAgICAgICBleHBlcmltZW50YWwsbGlrZWx5IHRv
IHJlbGVhc2UgdGhhdCB3YXk/IENvbnNpZGVyIG5lc3RlZC1zdm0KPiA+ICAgICAgICBzZXBhcmF0
ZSB0byBuZXN0ZWQtdm14LiBOZXN0ZWQtc3ZtIGlzIGluIGJldHRlciBzaGFwZSkKPiAKPiAKPiBK
dXN0IGEgcmFuZG9tIHRob3VnaHQsIGJ1dCBJIGZpbmQgaXQgcXVpdGUgYW5ub3lpbmcgdG8gbmVl
ZCBsYXRleCB0bwo+IGNvbXBpbGUgdGhlIGRvY3VtZW50YXRpb24uIEkgdGhpbmsgaXQgd2lsbCBi
ZSB3aXNlIHRvIGNyZWF0ZSBhIG5ldwo+IE1ha2VmaWxlIHRhcmdldCwgbGlrZSBtYW4tcGFnZXMg
YW5kIGluc3RhbGwtbWFuLXBhZ2VzIHRvIGFsbG93IHRoZQo+IHVzZXIgdG8gYnVpbGQgYW5kIGlu
c3RhbGwgbWFuIHBhZ2VzIG9ubHkgKG9yIGRvbid0IGFib3J0IGRvY3MgYnVpbGQgaWYKPiBsYXRl
eCBpcyBub3QgZm91bmQpLiBQZXJzb25hbGx5IEkgZG9uJ3QgaGF2ZSBsYXRleCBvbiBteSBzZXJ2
ZXIsIGFuZCBJCj4gZG9uJ3Qgd2FudCB0byBpbnN0YWxsIGl0LCBidXQgSSB3b3VsZCBsaWtlIHRv
IGhhdmUgdGhlIG1hbiBwYWdlcyB3aGVuCj4gYnVpbGRpbmcgWGVuIGZyb20gc291cmNlLgoKIm1h
a2UgLUMgZG9jcyBtYW4tcGFnZXMiIHdpbGwgZG8gd2hhdCB5b3Ugd2FudC4KCkkgbXVzdCBhZG1p
dCBJIHRob3VnaHQgbGF0ZXggd2FzIG9wdGlvbmFsIGFuZCB0aGF0ICJtYWtlIGRvY3MiIHdvdWxk
CnNpbXBseSBza2lwIHRob3NlIGRvY3MgaWYgaXQgd2Fzbid0IGluc3RhbGxlZCAtLSB0aGF0J3Mg
d2hhdCB0aGUgImlmCndoaWNoICQoVE9PTCkiIGNvbnN0cnVjdCB1c2VkIGluIHRoZXJlIGlzIChz
dXBwb3NlZCB0byBiZSkgZG9pbmcuCgpJYW4uCgo+IAo+ID4gVG9vbHMsIG5lZWQgdG8gZGVjaWRl
IGlmIHByZS0gb3IgcG9zdC00LjIgZmVhdHVyZToKPiA+Cj4gPiAgICAgICogQXV0b2NvbmYgKFJv
Z2VyIFBhdSBNb25ldCBwb3N0ZWQgYSBwYXRjaCkKPiA+Cj4gPgo+ID4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKPiA+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gPiBodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:41:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:41:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq428-0002Zy-Ja; Wed, 25 Jan 2012 14:41:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq427-0002Z7-3O
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:41:07 +0000
Received: from [85.158.138.51:51384] by server-10.bemta-3.messagelabs.com id
	FF/90-20948-284102F4; Wed, 25 Jan 2012 14:41:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327502465!10640735!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10355 invoked from network); 25 Jan 2012 14:41:05 -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;
	25 Jan 2012 14:41:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:41: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, 25 Jan 2012 14:41:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 25 Jan 2012 14:41:04 +0000
In-Reply-To: <CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327502464.24561.325.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDE0OjMzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8yMyBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE5ld2x5IHVwZGF0ZWQgbGlzdCBmb2xsb3dzLiBQbGVhc2Ugc2VuZCBtZSBjb3JyZWN0aW9ucyAo
ZXNwZWNpYWxseQo+ID4gImRvbmUiKS4gSSd2ZSBzdG9wcGVkIENDaW5nIGV2ZXJ5b25lLCBzaW5j
ZSBJIGd1ZXNzIGl0IGlzIG1vc3RseSBzcGFtIHRvCj4gPiB0aGUgbWFqb3JpdHkuCj4gPgo+ID4g
aHlwZXJ2aXNvciwgYmxvY2tlcnM6Cj4gPgo+ID4gICAgICAqIHJvdW5kLXVwIG9mIHRoZSBjbG9z
aW5nIG9mIHRoZSBzZWN1cml0eSBob2xlIGluIE1TSS1YCj4gPiAgICAgICAgcGFzc3Rocm91Z2gg
KHVuaWZvcm1seSAtIGkuZS4gZXZlbiBmb3IgRG9tMCAtIGRpc2FsbG93aW5nIHdyaXRlCj4gPiAg
ICAgICAgYWNjZXNzIHRvIE1TSS1YIHRhYmxlIHBhZ2VzKS4gKEphbiBCZXVsaWNoIC0tIG1vcmUg
Zml4ZXMKPiA+ICAgICAgICByZXF1aXJlZCB0aGFuIGZpcnN0IHRob3VnaHQsIHBhdGNoZXMgcG9z
dGVkKQo+ID4gICAgICAqIGRvbWN0bHMgLyBzeXNjdGxzIHNldCB1cCB0byBtb2RpZnkgc2NoZWR1
bGVyIHBhcmFtZXRlcnMsIGxpa2UKPiA+ICAgICAgICB0aGUgY3JlZGl0MSB0aW1lc2xpY2UgYW5k
IHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwKQo+ID4gICAgICAqIGdldCB0aGUgaW50ZXJm
YWNlIGNoYW5nZXMgZm9yIHNoYXJpbmcvcGFnaW5nL21lbS1ldmVudHMgZG9uZSBhbmQKPiA+ICAg
ICAgICBkdXN0ZWQgc28gdGhhdCA0LjIgaXMgYSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4g
KFRpbSBEZWVnYW4sCj4gPiAgICAgICAgQW5kcmVzIExhZ2FyLUNhdmlsbGEgZXQgYWwpCj4gPiAg
ICAgICAgICAgICAgKiBtZW0gZXZlbnQgcmluZyBtYW5hZ2VtZW50IHBvc3RlZCwgc2VlbXMgY2xv
c2UgdG8gZ29pbmcKPiA+ICAgICAgICAgICAgICAgIGluLgo+ID4gICAgICAgICAgICAgICogc2hh
cmluZyBwYXRjaGVzIHBvc3RlZAo+ID4KPiA+IHRvb2xzLCBibG9ja2VyczoKPiA+Cj4gPiAgICAg
ICogbGlieGwgc3RhYmxlIEFQSSAtLSB3ZSB3b3VsZCBsaWtlIDQuMiB0byBkZWZpbmUgYSBzdGFi
bGUgQVBJCj4gPiAgICAgICAgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9u
IG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgo+ID4gICAgICAgIHRoaXMgYXJlOgo+ID4gICAgICAg
ICAgICAgICogZXZlbnQgaGFuZGxpbmcgKElhbiBKYWNrc29uLCBwb3N0ZWQgc2V2ZXJhbCByb3Vu
ZHMsCj4gPiAgICAgICAgICAgICAgICBuZWFyaW5nIGNvbXBsZXRpb24/KQo+ID4gICAgICAgICAg
ICAgICogZHJvcCBsaWJ4bF9kZXZpY2VfbW9kZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2lu
Zm8gb3IKPiA+ICAgICAgICAgICAgICAgIGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkgKElhbiBD
YW1wYmVsbCwgZmlyc3QgUkZDIHNlbnQpCj4gPiAgICAgICAgICAgICAgKiBhZGQgbGlieGxfZGVm
Ym9vbCBhbmQgZ2VuZXJhbGx5IHRyeSBhbmQgYXJyYW5nZSB0aGF0Cj4gPiAgICAgICAgICAgICAg
ICBtZW1zZXQoZm9vLDAsLi4uKSByZXF1ZXN0cyB0aGUgZGVmYXVsdHMgKElhbiBDYW1wYmVsbCwK
PiA+ICAgICAgICAgICAgICAgIGZpcnN0IFJGQyBzZW50KQo+ID4gICAgICAgICAgICAgICogdG9w
b2xvZ3lpbmZvIGRhdGFzdHJ1Y3R1cmUgc2hvdWxkIGJlIGEgbGlzdCBvZiB0dXBsZXMsCj4gPiAg
ICAgICAgICAgICAgICBub3QgYSB0dXBsZSBvZiBsaXN0cy4gKG5vYm9keSBjdXJyZW50bHkgbG9v
a2luZyBhdCB0aGlzLAo+ID4gICAgICAgICAgICAgICAgbm90IDEwMCUgc3VyZSB0aGlzIG1ha2Vz
IHNlbnNlLCBjb3VsZCBwb3NzaWJseSBkZWZlciBhbmQKPiA+ICAgICAgICAgICAgICAgIGNoYW5n
ZSBhZnRlciA0LjIgaW4gYSBjb21wYXRpYmxlIHdheSkKPiA+ICAgICAgKiB4bCB0byB1c2UganNv
biBmb3IgbWFjaGluZSByZWFkYWJsZSBvdXRwdXQgaW5zdGVhZCBvZiBzZXhwIGJ5Cj4gPiAgICAg
ICAgZGVmYXVsdCAoSWFuIENhbXBiZWxsIHRvIHJldmlzaXQgZXhpc3RpbmcgcGF0Y2gpCj4gPiAg
ICAgICogeGwgc3VwcG9ydCBmb3IgdmNwdSBwaW5uaW5nIChEYXJpbyBGYWdnaW9saSkKPiA+ICAg
ICAgKiB4bCBmZWF0dXJlIHBhcml0eSB3aXRoIHhlbmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9y
dCAoR2VvcmdlCj4gPiAgICAgICAgRHVubGFwKQo+ID4gICAgICAqIEludGVncmF0ZSBxZW11K3Nl
YWJpb3MgdXBzdHJlYW0gaW50byB0aGUgYnVpbGQgKHBhdGNoZXMKPiA+ICAgICAgICByZXBvc3Rl
ZCwgcGVuZGluZykuIE5vIGNoYW5nZSBpbiBkZWZhdWx0IHFlbXUgZm9yIDQuMi4KPiA+ICAgICAg
KiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFk
eSBpbgo+ID4gICAgICAgIHRyZWUuIE5lZWRzIHJlbGVhc2Ugbm90aW5nIGFuZCBjb21tdW5pY2F0
aW9uIGFyb3VuZCAtcmMxIHRvCj4gPiAgICAgICAgcmVtaW5kIHBlb3BsZSB0byB0ZXN0IHhsLgo+
ID4KPiA+IGh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKPiA+Cj4gPiAgICAgICogc29saWQgaW1w
bGVtZW50YXRpb24gb2Ygc2hhcmluZy9wYWdpbmcvbWVtLWV2ZW50cyAodXNpbmcgd29yawo+ID4g
ICAgICAgIHF1ZXVlcykgKFRpbSBEZWVnYW4sIE9sYWYgSGVycmluZyBldCBhbCkKPiA+ICAgICAg
KiBBIGxvbmcgc3RhbmRpbmcgaXNzdWUgaXMgYSBmdWxseSBzeW5jaHJvbml6ZWQgcDJtIChsb2Nr
aW5nCj4gPiAgICAgICAgbG9va3VwcykgKEFuZHJlcyBMYWdhci1DYXZpbGxhKQo+ID4gICAgICAq
IE5VTUEgaW1wcm92ZW1lbnQ6IGRvbWFpbiBhZmZpbml0eSBjb25zaXN0ZW50IHdpdGggY3B1cG9v
bAo+ID4gICAgICAgIG1lbWJlcnNoaXAgKERhcmlvIEZhZ2dpb2xpLCBKZXVyZ2VuIEdyb3NzIC0t
IHBhdGNoIHBvc3RlZCkKPiA+Cj4gPiB0b29scywgbmljZSB0byBoYXZlOgo+ID4KPiA+ICAgICAg
KiBIb3RwbHVnIHNjcmlwdCBzdHVmZiAtLSBpbnRlcm5hbCB0byBsaWJ4bCAoSSB0aGluaywgdGhl
cmVmb3JlIEkKPiA+ICAgICAgICBkaWRuJ3QgcHV0IHRoaXMgdW5kZXIgc3RhYmxlIEFQSSBhYm92
ZSkgYnV0IHN0aWxsIGdvb2QgdG8gaGF2ZQo+ID4gICAgICAgIGZvciA0LjI/IFJvZ2VyIFBhdSBN
b25ldCB3YXMgbG9va2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9va2luZwo+ID4gICAgICAgIGxpa2Ug
YSBiaWcgY2FuLW8td29ybXMuIChkaXNjdXNzaW9uIG9uLWdvaW5nKQo+ID4gICAgICAqIEJsb2Nr
IHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIK
PiA+ICAgICAgICBQYXUgTW9uZXQpCj4gPiAgICAgICogbGlieWFqbCB2MiBzdXBwb3J0IChwYXRj
aCBwb3N0ZWQgYnkgUm9nZXIgUGF1IE1vbmV0LCBibG9ja2VkIG9uCj4gPiAgICAgICAgYXV0b2Nv
bmY/KQo+ID4gICAgICAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9s
YWYgSGVycmluZykKPiA+ICAgICAgKiBVcHN0cmVhbSBxZW11IGZlYXR1cmUgcGF0Y2hlczoKPiA+
ICAgICAgICAgICAgICAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFu
dGhvbnkgUGVyYXJkKQo+ID4gICAgICAgICAgICAgICogVXBzdHJlYW0gcWVtdSBzYXZlIHJlc3Rv
cmUgKEFudGhvbnkgUGVyYXJkKQo+ID4gICAgICAqIE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3Vy
cmVudGx5IHNob3VsZCBiZSBtYXJrZWQKPiA+ICAgICAgICBleHBlcmltZW50YWwsbGlrZWx5IHRv
IHJlbGVhc2UgdGhhdCB3YXk/IENvbnNpZGVyIG5lc3RlZC1zdm0KPiA+ICAgICAgICBzZXBhcmF0
ZSB0byBuZXN0ZWQtdm14LiBOZXN0ZWQtc3ZtIGlzIGluIGJldHRlciBzaGFwZSkKPiAKPiAKPiBK
dXN0IGEgcmFuZG9tIHRob3VnaHQsIGJ1dCBJIGZpbmQgaXQgcXVpdGUgYW5ub3lpbmcgdG8gbmVl
ZCBsYXRleCB0bwo+IGNvbXBpbGUgdGhlIGRvY3VtZW50YXRpb24uIEkgdGhpbmsgaXQgd2lsbCBi
ZSB3aXNlIHRvIGNyZWF0ZSBhIG5ldwo+IE1ha2VmaWxlIHRhcmdldCwgbGlrZSBtYW4tcGFnZXMg
YW5kIGluc3RhbGwtbWFuLXBhZ2VzIHRvIGFsbG93IHRoZQo+IHVzZXIgdG8gYnVpbGQgYW5kIGlu
c3RhbGwgbWFuIHBhZ2VzIG9ubHkgKG9yIGRvbid0IGFib3J0IGRvY3MgYnVpbGQgaWYKPiBsYXRl
eCBpcyBub3QgZm91bmQpLiBQZXJzb25hbGx5IEkgZG9uJ3QgaGF2ZSBsYXRleCBvbiBteSBzZXJ2
ZXIsIGFuZCBJCj4gZG9uJ3Qgd2FudCB0byBpbnN0YWxsIGl0LCBidXQgSSB3b3VsZCBsaWtlIHRv
IGhhdmUgdGhlIG1hbiBwYWdlcyB3aGVuCj4gYnVpbGRpbmcgWGVuIGZyb20gc291cmNlLgoKIm1h
a2UgLUMgZG9jcyBtYW4tcGFnZXMiIHdpbGwgZG8gd2hhdCB5b3Ugd2FudC4KCkkgbXVzdCBhZG1p
dCBJIHRob3VnaHQgbGF0ZXggd2FzIG9wdGlvbmFsIGFuZCB0aGF0ICJtYWtlIGRvY3MiIHdvdWxk
CnNpbXBseSBza2lwIHRob3NlIGRvY3MgaWYgaXQgd2Fzbid0IGluc3RhbGxlZCAtLSB0aGF0J3Mg
d2hhdCB0aGUgImlmCndoaWNoICQoVE9PTCkiIGNvbnN0cnVjdCB1c2VkIGluIHRoZXJlIGlzIChz
dXBwb3NlZCB0byBiZSkgZG9pbmcuCgpJYW4uCgo+IAo+ID4gVG9vbHMsIG5lZWQgdG8gZGVjaWRl
IGlmIHByZS0gb3IgcG9zdC00LjIgZmVhdHVyZToKPiA+Cj4gPiAgICAgICogQXV0b2NvbmYgKFJv
Z2VyIFBhdSBNb25ldCBwb3N0ZWQgYSBwYXRjaCkKPiA+Cj4gPgo+ID4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+IFhlbi1kZXZlbCBtYWlsaW5nIGxp
c3QKPiA+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gPiBodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:44:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq450-0003pX-7U; Wed, 25 Jan 2012 14:44: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 1Rq44y-0003o5-Rs
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:44:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327502638!2124451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25743 invoked from network); 25 Jan 2012 14:43:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:43:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:43:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 14:43:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 25 Jan 2012 14:43:57 +0000
In-Reply-To: <1327502102.2723.15.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss> <1327502102.2723.15.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327502637.24561.326.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv3 1 of 2] libxl: extend pCPUs specification
	for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 14:35 +0000, Dario Faggioli wrote:
> Allow for "^<cpuid>" syntax while specifying the pCPUs list
> during a vcpu-pin. This enables doing the following:
> 
>  xl vcpu-pin 1 1 0-4,^2
> 
> and achieving:
> 
>  xl vcpu-list
>  Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>  ...
>  Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
>  ...
> 
> Negative ranges are also supported, such as "0-4,^1-2" to
> mean "0,3-4"
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@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 Wed Jan 25 14:44:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:44:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq450-0003pX-7U; Wed, 25 Jan 2012 14:44: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 1Rq44y-0003o5-Rs
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:44:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327502638!2124451!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25743 invoked from network); 25 Jan 2012 14:43:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:43:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283752"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:43:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 14:43:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 25 Jan 2012 14:43:57 +0000
In-Reply-To: <1327502102.2723.15.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss> <1327502102.2723.15.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327502637.24561.326.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv3 1 of 2] libxl: extend pCPUs specification
	for vcpu-pin.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 14:35 +0000, Dario Faggioli wrote:
> Allow for "^<cpuid>" syntax while specifying the pCPUs list
> during a vcpu-pin. This enables doing the following:
> 
>  xl vcpu-pin 1 1 0-4,^2
> 
> and achieving:
> 
>  xl vcpu-list
>  Name                                ID  VCPU   CPU State   Time(s) CPU Affinity
>  ...
>  Squeeze_pv                           1     1    3   -b-       2.4  0-1,3-4
>  ...
> 
> Negative ranges are also supported, such as "0-4,^1-2" to
> mean "0,3-4"
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@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 Wed Jan 25 14:45:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq46J-00040K-W2; Wed, 25 Jan 2012 14:45: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 1Rq46I-0003zm-5A
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:45:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327502720!12291468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30260 invoked from network); 25 Jan 2012 14:45:20 -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;
	25 Jan 2012 14:45:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:45: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, 25 Jan 2012 14:45: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
	1Rq46B-0000EH-3C; Wed, 25 Jan 2012 14:45:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rq46B-0007g5-1V;
	Wed, 25 Jan 2012 14:45:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20256.5502.898249.801471@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 14:45:18 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327488533.24561.272.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
	<1326969875.17599.50.camel@zakaz.uk.xensource.com>
	<20254.59933.408785.834@mariner.uk.xensource.com>
	<1327488533.24561.272.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 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> On Tue, 2012-01-24 at 17:27 +0000, Ian Jackson wrote:
> > If ao_how is non-NULL then these functions cannot return 0.
> > If it is NULL they cannot return ASYNC_INPROGRESS.
> > 
> > I chose to use a new exit status because it seemed safer but that's a
> > matter of taste and if you prefer I could return 0 for that case.
> 
> I'm undecided (plus it seems a bit like bikeshedding). I certainly
> prefer either 0 or {LIBXL_}ASYNC_IN_PROGRESS to ERROR_ASYNC_IN_PROGRESS
> though.

OK, I'll rename it.

> > I guess we could but isn't this going to become a proper IDL enum at
> > some point ?
> 
> At which point it would become LIBXL_ERROR_{FOOS} and
> LIBXL_ASYNC_IN_PROGRESS?

I guess so.  Or we could rename it LIBXL_RC_...

> + *   * initiator calls ao_complete:               |
> + *     - observes event not net done,             |
> 
> You want s/net/yet/.

Yes.

> > > Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
> > > would become
> > >         return AO_INPROGRESS;
> > 
> > That would be possible.  I wasn't sure whether to do it like that.
> > Note that AO_CREATE already might return; doing it the way I have it
> > now seems more symmetrical.
> > 
> > But perhaps it would make things clearer to have the return outside
> > the macro.
> 
> I thought there was a general preference for that sort of thing, but I
> suppose it depends on the required macro contortions to make it happen.

I think this should be easily doable.  I'll sort it out.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:45:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:45:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq46J-00040K-W2; Wed, 25 Jan 2012 14:45: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 1Rq46I-0003zm-5A
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:45:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327502720!12291468!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30260 invoked from network); 25 Jan 2012 14:45:20 -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;
	25 Jan 2012 14:45:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283794"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:45: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, 25 Jan 2012 14:45: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
	1Rq46B-0000EH-3C; Wed, 25 Jan 2012 14:45:19 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rq46B-0007g5-1V;
	Wed, 25 Jan 2012 14:45:19 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20256.5502.898249.801471@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 14:45:18 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327488533.24561.272.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
	<1326969875.17599.50.camel@zakaz.uk.xensource.com>
	<20254.59933.408785.834@mariner.uk.xensource.com>
	<1327488533.24561.272.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 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> On Tue, 2012-01-24 at 17:27 +0000, Ian Jackson wrote:
> > If ao_how is non-NULL then these functions cannot return 0.
> > If it is NULL they cannot return ASYNC_INPROGRESS.
> > 
> > I chose to use a new exit status because it seemed safer but that's a
> > matter of taste and if you prefer I could return 0 for that case.
> 
> I'm undecided (plus it seems a bit like bikeshedding). I certainly
> prefer either 0 or {LIBXL_}ASYNC_IN_PROGRESS to ERROR_ASYNC_IN_PROGRESS
> though.

OK, I'll rename it.

> > I guess we could but isn't this going to become a proper IDL enum at
> > some point ?
> 
> At which point it would become LIBXL_ERROR_{FOOS} and
> LIBXL_ASYNC_IN_PROGRESS?

I guess so.  Or we could rename it LIBXL_RC_...

> + *   * initiator calls ao_complete:               |
> + *     - observes event not net done,             |
> 
> You want s/net/yet/.

Yes.

> > > Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
> > > would become
> > >         return AO_INPROGRESS;
> > 
> > That would be possible.  I wasn't sure whether to do it like that.
> > Note that AO_CREATE already might return; doing it the way I have it
> > now seems more symmetrical.
> > 
> > But perhaps it would make things clearer to have the return outside
> > the macro.
> 
> I thought there was a general preference for that sort of thing, but I
> suppose it depends on the required macro contortions to make it happen.

I think this should be easily doable.  I'll sort it out.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:45:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1Rq46l-00044P-EL; Wed, 25 Jan 2012 14:45:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq46k-000448-6X
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:45:54 +0000
Received: from [85.158.138.51:19744] by server-1.bemta-3.messagelabs.com id
	C5/92-09565-1A5102F4; Wed, 25 Jan 2012 14:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327502752!10629911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14717 invoked from network); 25 Jan 2012 14:45:52 -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;
	25 Jan 2012 14:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:45:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 14:45:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 25 Jan 2012 14:45:51 +0000
In-Reply-To: <1327502171.2723.17.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss> <1327502171.2723.17.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327502752.24561.328.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv3 1 of 2] libxl: allow for specifying the
 CPU affinity in the config file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 14:36 +0000, Dario Faggioli wrote:
> Enable CPU affinity specification in a VM's config file with the
> exact syntax `xl vcpu-pin' provides.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(if you do end up resending for any reason then you could combine the
code motion of vcpupin_parse in ths patch with it's introduction in the
prior patch).

> 
> diff -r e4fd5305381e tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl.c	Wed Jan 25 14:08:21 2012 +0000
> @@ -2663,6 +2663,21 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
>      return 0;
>  }
>  
> +int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> +                               unsigned int max_vcpus, libxl_cpumap *cpumap)
> +{
> +    int i, rc = 0;
> +
> +    for (i = 0; i < max_vcpus; i++) {
> +        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
> +                       "failed to set affinity for %d", i);
> +            rc = ERROR_FAIL;
> +        }
> +    }
> +    return rc;
> +}
> +
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>  {
>      GC_INIT(ctx);
> diff -r e4fd5305381e tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl.h	Wed Jan 25 14:08:21 2012 +0000
> @@ -560,6 +560,8 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
>                                         int *nb_vcpu, int *nrcpus);
>  int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>                             libxl_cpumap *cpumap);
> +int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> +                               unsigned int max_vcpus, libxl_cpumap *cpumap);
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
>  
>  int libxl_get_sched_id(libxl_ctx *ctx);
> diff -r e4fd5305381e tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Wed Jan 25 14:08:21 2012 +0000
> @@ -71,6 +71,9 @@ int libxl_init_build_info(libxl_ctx *ctx
>      memset(b_info, '\0', sizeof(*b_info));
>      b_info->max_vcpus = 1;
>      b_info->cur_vcpus = 1;
> +    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
> +        return ERROR_NOMEM;
> +    libxl_cpumap_set_any(&b_info->cpumap);
>      b_info->max_memkb = 32 * 1024;
>      b_info->target_memkb = b_info->max_memkb;
>      b_info->disable_migrate = 0;
> diff -r e4fd5305381e tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Wed Jan 25 14:08:21 2012 +0000
> @@ -65,6 +65,7 @@ int libxl__build_pre(libxl__gc *gc, uint
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int tsc_mode;
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> +    libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
>      if (info->type == LIBXL_DOMAIN_TYPE_PV)
>          xc_domain_set_memmap_limit(ctx->xch, domid,
> diff -r e4fd5305381e tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Wed Jan 25 14:08:21 2012 +0000
> @@ -162,6 +162,7 @@ libxl_domain_create_info = Struct("domai
>  libxl_domain_build_info = Struct("domain_build_info",[
>      ("max_vcpus",       integer),
>      ("cur_vcpus",       integer),
> +    ("cpumap",          libxl_cpumap),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       uint32),
>      ("target_memkb",    uint32),
> diff -r e4fd5305381e tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl_utils.h	Wed Jan 25 14:08:21 2012 +0000
> @@ -70,6 +70,18 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
>  int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
> +static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
> +{
> +    memset(cpumap->map, -1, cpumap->size);
> +}
> +static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
> +{
> +    memset(cpumap->map, 0, cpumap->size);
> +}
> +static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
> +{
> +    return cpu >= 0 && cpu < (cpumap->size * 8);
> +}
>  #define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
>  #define libxl_for_each_set_cpu(v, m) for (v = 0; v < (m).size * 8; v++) \
>                                               if (libxl_cpumap_test(&(m), v))
> diff -r e4fd5305381e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 14:08:21 2012 +0000
> @@ -569,6 +569,65 @@ static void split_string_into_string_lis
>      free(s);
>  }
>  
> +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> +{
> +    libxl_cpumap exclude_cpumap;
> +    uint32_t cpuida, cpuidb;
> +    char *endptr, *toka, *tokb, *saveptr = NULL;
> +    int i, rc = 0, rmcpu;
> +
> +    if (!strcmp(cpu, "all")) {
> +        libxl_cpumap_set_any(cpumap);
> +        return 0;
> +    }
> +
> +    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
> +        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
> +        return ENOMEM;
> +    }
> +
> +    for (toka = strtok_r(cpu, ",", &saveptr); toka;
> +         toka = strtok_r(NULL, ",", &saveptr)) {
> +        rmcpu = 0;
> +        if (*toka == '^') {
> +            /* This (These) Cpu(s) will be removed from the map */
> +            toka++;
> +            rmcpu = 1;
> +        }
> +        /* Extract a valid (range of) cpu(s) */
> +        cpuida = cpuidb = strtoul(toka, &endptr, 10);
> +        if (endptr == toka) {
> +            fprintf(stderr, "Error: Invalid argument.\n");
> +            rc = EINVAL;
> +            goto vcpp_out;
> +        }
> +        if (*endptr == '-') {
> +            tokb = endptr + 1;
> +            cpuidb = strtoul(tokb, &endptr, 10);
> +            if (endptr == tokb || cpuida > cpuidb) {
> +                fprintf(stderr, "Error: Invalid argument.\n");
> +                rc = EINVAL;
> +                goto vcpp_out;
> +            }
> +        }
> +        while (cpuida <= cpuidb) {
> +            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
> +                         libxl_cpumap_set(&exclude_cpumap, cpuida);
> +            cpuida++;
> +        }
> +    }
> +
> +    /* Clear all the cpus from the removal list */
> +    libxl_for_each_set_cpu(i, exclude_cpumap) {
> +        libxl_cpumap_reset(cpumap, i);
> +    }
> +
> +vcpp_out:
> +    libxl_cpumap_dispose(&exclude_cpumap);
> +
> +    return rc;
> +}
> +
>  static void parse_config_data(const char *configfile_filename_report,
>                                const char *configfile_data,
>                                int configfile_len,
> @@ -578,7 +637,7 @@ static void parse_config_data(const char
>      const char *buf;
>      long l;
>      XLU_Config *config;
> -    XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
> +    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
>      int pci_power_mgmt = 0;
>      int pci_msitranslate = 1;
>      int e;
> @@ -661,6 +720,29 @@ static void parse_config_data(const char
>      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
>          b_info->max_vcpus = l;
>  
> +    if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
> +        int i, n_cpus = 0;
> +
> +        libxl_cpumap_set_none(&b_info->cpumap);
> +        while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
> +            i = atoi(buf);
> +            if (!libxl_cpumap_cpu_valid(&b_info->cpumap, i)) {
> +                fprintf(stderr, "cpu %d illegal\n", i);
> +                exit(1);
> +            }
> +            libxl_cpumap_set(&b_info->cpumap, i);
> +            n_cpus++;
> +        }
> +    }
> +    else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
> +        char *buf2 = strdup(buf);
> +
> +        libxl_cpumap_set_none(&b_info->cpumap);
> +        if (vcpupin_parse(buf2, &b_info->cpumap))
> +            exit(1);
> +        free(buf2);
> +    }
> +
>      if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
>          b_info->max_memkb = l * 1024;
>          b_info->target_memkb = b_info->max_memkb;
> @@ -3503,65 +3585,6 @@ int main_vcpulist(int argc, char **argv)
>      return 0;
>  }
>  
> -static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> -{
> -    libxl_cpumap exclude_cpumap;
> -    uint32_t cpuida, cpuidb;
> -    char *endptr, *toka, *tokb, *saveptr = NULL;
> -    int i, rc = 0, rmcpu;
> -
> -    if (!strcmp(cpu, "all")) {
> -        memset(cpumap->map, -1, cpumap->size);
> -        return 0;
> -    }
> -
> -    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
> -        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
> -        return ENOMEM;
> -    }
> -
> -    for (toka = strtok_r(cpu, ",", &saveptr); toka;
> -         toka = strtok_r(NULL, ",", &saveptr)) {
> -        rmcpu = 0;
> -        if (*toka == '^') {
> -            /* This (These) Cpu(s) will be removed from the map */
> -            toka++;
> -            rmcpu = 1;
> -        }
> -        /* Extract a valid (range of) cpu(s) */
> -        cpuida = cpuidb = strtoul(toka, &endptr, 10);
> -        if (endptr == toka) {
> -            fprintf(stderr, "Error: Invalid argument.\n");
> -            rc = EINVAL;
> -            goto vcpp_out;
> -        }
> -        if (*endptr == '-') {
> -            tokb = endptr + 1;
> -            cpuidb = strtoul(tokb, &endptr, 10);
> -            if (endptr == tokb || cpuida > cpuidb) {
> -                fprintf(stderr, "Error: Invalid argument.\n");
> -                rc = EINVAL;
> -                goto vcpp_out;
> -            }
> -        }
> -        while (cpuida <= cpuidb) {
> -            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
> -                         libxl_cpumap_set(&exclude_cpumap, cpuida);
> -            cpuida++;
> -        }
> -    }
> -
> -    /* Clear all the cpus from the removal list */
> -    libxl_for_each_set_cpu(i, exclude_cpumap) {
> -        libxl_cpumap_reset(cpumap, i);
> -    }
> -
> -vcpp_out:
> -    libxl_cpumap_dispose(&exclude_cpumap);
> -
> -    return rc;
> -}
> -
>  static void vcpupin(const char *d, const char *vcpu, char *cpu)
>  {
>      libxl_vcpuinfo *vcpuinfo;
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:45:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1Rq46l-00044P-EL; Wed, 25 Jan 2012 14:45:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq46k-000448-6X
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:45:54 +0000
Received: from [85.158.138.51:19744] by server-1.bemta-3.messagelabs.com id
	C5/92-09565-1A5102F4; Wed, 25 Jan 2012 14:45:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327502752!10629911!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14717 invoked from network); 25 Jan 2012 14:45:52 -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;
	25 Jan 2012 14:45:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283816"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:45:52 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 14:45:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Date: Wed, 25 Jan 2012 14:45:51 +0000
In-Reply-To: <1327502171.2723.17.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss> <1327502171.2723.17.camel@Abyss>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327502752.24561.328.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCHv3 1 of 2] libxl: allow for specifying the
 CPU affinity in the config file.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 14:36 +0000, Dario Faggioli wrote:
> Enable CPU affinity specification in a VM's config file with the
> exact syntax `xl vcpu-pin' provides.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

(if you do end up resending for any reason then you could combine the
code motion of vcpupin_parse in ths patch with it's introduction in the
prior patch).

> 
> diff -r e4fd5305381e tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl.c	Wed Jan 25 14:08:21 2012 +0000
> @@ -2663,6 +2663,21 @@ int libxl_set_vcpuaffinity(libxl_ctx *ct
>      return 0;
>  }
>  
> +int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> +                               unsigned int max_vcpus, libxl_cpumap *cpumap)
> +{
> +    int i, rc = 0;
> +
> +    for (i = 0; i < max_vcpus; i++) {
> +        if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap)) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
> +                       "failed to set affinity for %d", i);
> +            rc = ERROR_FAIL;
> +        }
> +    }
> +    return rc;
> +}
> +
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap)
>  {
>      GC_INIT(ctx);
> diff -r e4fd5305381e tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl.h	Wed Jan 25 14:08:21 2012 +0000
> @@ -560,6 +560,8 @@ libxl_vcpuinfo *libxl_list_vcpu(libxl_ct
>                                         int *nb_vcpu, int *nrcpus);
>  int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
>                             libxl_cpumap *cpumap);
> +int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
> +                               unsigned int max_vcpus, libxl_cpumap *cpumap);
>  int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_cpumap *cpumap);
>  
>  int libxl_get_sched_id(libxl_ctx *ctx);
> diff -r e4fd5305381e tools/libxl/libxl_create.c
> --- a/tools/libxl/libxl_create.c	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl_create.c	Wed Jan 25 14:08:21 2012 +0000
> @@ -71,6 +71,9 @@ int libxl_init_build_info(libxl_ctx *ctx
>      memset(b_info, '\0', sizeof(*b_info));
>      b_info->max_vcpus = 1;
>      b_info->cur_vcpus = 1;
> +    if (libxl_cpumap_alloc(ctx, &b_info->cpumap))
> +        return ERROR_NOMEM;
> +    libxl_cpumap_set_any(&b_info->cpumap);
>      b_info->max_memkb = 32 * 1024;
>      b_info->target_memkb = b_info->max_memkb;
>      b_info->disable_migrate = 0;
> diff -r e4fd5305381e tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Wed Jan 25 14:08:21 2012 +0000
> @@ -65,6 +65,7 @@ int libxl__build_pre(libxl__gc *gc, uint
>      libxl_ctx *ctx = libxl__gc_owner(gc);
>      int tsc_mode;
>      xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
> +    libxl_set_vcpuaffinity_all(ctx, domid, info->max_vcpus, &info->cpumap);
>      xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
>      if (info->type == LIBXL_DOMAIN_TYPE_PV)
>          xc_domain_set_memmap_limit(ctx->xch, domid,
> diff -r e4fd5305381e tools/libxl/libxl_types.idl
> --- a/tools/libxl/libxl_types.idl	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl_types.idl	Wed Jan 25 14:08:21 2012 +0000
> @@ -162,6 +162,7 @@ libxl_domain_create_info = Struct("domai
>  libxl_domain_build_info = Struct("domain_build_info",[
>      ("max_vcpus",       integer),
>      ("cur_vcpus",       integer),
> +    ("cpumap",          libxl_cpumap),
>      ("tsc_mode",        libxl_tsc_mode),
>      ("max_memkb",       uint32),
>      ("target_memkb",    uint32),
> diff -r e4fd5305381e tools/libxl/libxl_utils.h
> --- a/tools/libxl/libxl_utils.h	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/libxl_utils.h	Wed Jan 25 14:08:21 2012 +0000
> @@ -70,6 +70,18 @@ int libxl_cpumap_alloc(libxl_ctx *ctx, l
>  int libxl_cpumap_test(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_set(libxl_cpumap *cpumap, int cpu);
>  void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
> +static inline void libxl_cpumap_set_any(libxl_cpumap *cpumap)
> +{
> +    memset(cpumap->map, -1, cpumap->size);
> +}
> +static inline void libxl_cpumap_set_none(libxl_cpumap *cpumap)
> +{
> +    memset(cpumap->map, 0, cpumap->size);
> +}
> +static inline int libxl_cpumap_cpu_valid(libxl_cpumap *cpumap, int cpu)
> +{
> +    return cpu >= 0 && cpu < (cpumap->size * 8);
> +}
>  #define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
>  #define libxl_for_each_set_cpu(v, m) for (v = 0; v < (m).size * 8; v++) \
>                                               if (libxl_cpumap_test(&(m), v))
> diff -r e4fd5305381e tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 11:40:23 2012 +0000
> +++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 14:08:21 2012 +0000
> @@ -569,6 +569,65 @@ static void split_string_into_string_lis
>      free(s);
>  }
>  
> +static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> +{
> +    libxl_cpumap exclude_cpumap;
> +    uint32_t cpuida, cpuidb;
> +    char *endptr, *toka, *tokb, *saveptr = NULL;
> +    int i, rc = 0, rmcpu;
> +
> +    if (!strcmp(cpu, "all")) {
> +        libxl_cpumap_set_any(cpumap);
> +        return 0;
> +    }
> +
> +    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
> +        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
> +        return ENOMEM;
> +    }
> +
> +    for (toka = strtok_r(cpu, ",", &saveptr); toka;
> +         toka = strtok_r(NULL, ",", &saveptr)) {
> +        rmcpu = 0;
> +        if (*toka == '^') {
> +            /* This (These) Cpu(s) will be removed from the map */
> +            toka++;
> +            rmcpu = 1;
> +        }
> +        /* Extract a valid (range of) cpu(s) */
> +        cpuida = cpuidb = strtoul(toka, &endptr, 10);
> +        if (endptr == toka) {
> +            fprintf(stderr, "Error: Invalid argument.\n");
> +            rc = EINVAL;
> +            goto vcpp_out;
> +        }
> +        if (*endptr == '-') {
> +            tokb = endptr + 1;
> +            cpuidb = strtoul(tokb, &endptr, 10);
> +            if (endptr == tokb || cpuida > cpuidb) {
> +                fprintf(stderr, "Error: Invalid argument.\n");
> +                rc = EINVAL;
> +                goto vcpp_out;
> +            }
> +        }
> +        while (cpuida <= cpuidb) {
> +            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
> +                         libxl_cpumap_set(&exclude_cpumap, cpuida);
> +            cpuida++;
> +        }
> +    }
> +
> +    /* Clear all the cpus from the removal list */
> +    libxl_for_each_set_cpu(i, exclude_cpumap) {
> +        libxl_cpumap_reset(cpumap, i);
> +    }
> +
> +vcpp_out:
> +    libxl_cpumap_dispose(&exclude_cpumap);
> +
> +    return rc;
> +}
> +
>  static void parse_config_data(const char *configfile_filename_report,
>                                const char *configfile_data,
>                                int configfile_len,
> @@ -578,7 +637,7 @@ static void parse_config_data(const char
>      const char *buf;
>      long l;
>      XLU_Config *config;
> -    XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids;
> +    XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids;
>      int pci_power_mgmt = 0;
>      int pci_msitranslate = 1;
>      int e;
> @@ -661,6 +720,29 @@ static void parse_config_data(const char
>      if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
>          b_info->max_vcpus = l;
>  
> +    if (!xlu_cfg_get_list (config, "cpus", &cpus, 0, 1)) {
> +        int i, n_cpus = 0;
> +
> +        libxl_cpumap_set_none(&b_info->cpumap);
> +        while ((buf = xlu_cfg_get_listitem(cpus, n_cpus)) != NULL) {
> +            i = atoi(buf);
> +            if (!libxl_cpumap_cpu_valid(&b_info->cpumap, i)) {
> +                fprintf(stderr, "cpu %d illegal\n", i);
> +                exit(1);
> +            }
> +            libxl_cpumap_set(&b_info->cpumap, i);
> +            n_cpus++;
> +        }
> +    }
> +    else if (!xlu_cfg_get_string (config, "cpus", &buf, 0)) {
> +        char *buf2 = strdup(buf);
> +
> +        libxl_cpumap_set_none(&b_info->cpumap);
> +        if (vcpupin_parse(buf2, &b_info->cpumap))
> +            exit(1);
> +        free(buf2);
> +    }
> +
>      if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
>          b_info->max_memkb = l * 1024;
>          b_info->target_memkb = b_info->max_memkb;
> @@ -3503,65 +3585,6 @@ int main_vcpulist(int argc, char **argv)
>      return 0;
>  }
>  
> -static int vcpupin_parse(char *cpu, libxl_cpumap *cpumap)
> -{
> -    libxl_cpumap exclude_cpumap;
> -    uint32_t cpuida, cpuidb;
> -    char *endptr, *toka, *tokb, *saveptr = NULL;
> -    int i, rc = 0, rmcpu;
> -
> -    if (!strcmp(cpu, "all")) {
> -        memset(cpumap->map, -1, cpumap->size);
> -        return 0;
> -    }
> -
> -    if (libxl_cpumap_alloc(ctx, &exclude_cpumap)) {
> -        fprintf(stderr, "Error: Failed to allocate cpumap.\n");
> -        return ENOMEM;
> -    }
> -
> -    for (toka = strtok_r(cpu, ",", &saveptr); toka;
> -         toka = strtok_r(NULL, ",", &saveptr)) {
> -        rmcpu = 0;
> -        if (*toka == '^') {
> -            /* This (These) Cpu(s) will be removed from the map */
> -            toka++;
> -            rmcpu = 1;
> -        }
> -        /* Extract a valid (range of) cpu(s) */
> -        cpuida = cpuidb = strtoul(toka, &endptr, 10);
> -        if (endptr == toka) {
> -            fprintf(stderr, "Error: Invalid argument.\n");
> -            rc = EINVAL;
> -            goto vcpp_out;
> -        }
> -        if (*endptr == '-') {
> -            tokb = endptr + 1;
> -            cpuidb = strtoul(tokb, &endptr, 10);
> -            if (endptr == tokb || cpuida > cpuidb) {
> -                fprintf(stderr, "Error: Invalid argument.\n");
> -                rc = EINVAL;
> -                goto vcpp_out;
> -            }
> -        }
> -        while (cpuida <= cpuidb) {
> -            rmcpu == 0 ? libxl_cpumap_set(cpumap, cpuida) :
> -                         libxl_cpumap_set(&exclude_cpumap, cpuida);
> -            cpuida++;
> -        }
> -    }
> -
> -    /* Clear all the cpus from the removal list */
> -    libxl_for_each_set_cpu(i, exclude_cpumap) {
> -        libxl_cpumap_reset(cpumap, i);
> -    }
> -
> -vcpp_out:
> -    libxl_cpumap_dispose(&exclude_cpumap);
> -
> -    return rc;
> -}
> -
>  static void vcpupin(const char *d, const char *vcpu, char *cpu)
>  {
>      libxl_vcpuinfo *vcpuinfo;
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:49:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4A0-0004oK-5Z; Wed, 25 Jan 2012 14:49:16 +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 1Rq49y-0004nu-PC
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:49:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327502946!12369236!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5958 invoked from network); 25 Jan 2012 14:49:08 -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;
	25 Jan 2012 14:49:08 -0000
Received: by pbdx13 with SMTP id x13so14708917pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 06:49: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=fK5XVcbrDfTQQ8Hh6qVoAld3ILlW8apI5IEqe9ckkmo=;
	b=hJbzW0qUBDm8FIYb0VwHm/DKOGlyembD0QdlrDD5LYfYdUAl/U7NUEa5HLcAEj8eWP
	YLHmQEWK7xa86ktdBCKUjOJ70To7rspmrj94PnUNutM8Pko59m1xJsG9fHhjmS/WgABx
	XgASxliHGtMM39qeQnrj3ClQ4pAWItYm4iidM=
MIME-Version: 1.0
Received: by 10.68.238.229 with SMTP id vn5mr2726135pbc.39.1327502945973; Wed,
	25 Jan 2012 06:49:05 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Wed, 25 Jan 2012 06:49:05 -0800 (PST)
In-Reply-To: <1327502464.24561.325.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
	<1327502464.24561.325.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 15:49:05 +0100
X-Google-Sender-Auth: whkIk_Gs0K-VfrPZiYHJQc0xMBo
Message-ID: <CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI1IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMS0yNSBhdCAxNDozMyArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE5l
d2x5IHVwZGF0ZWQgbGlzdCBmb2xsb3dzLiBQbGVhc2Ugc2VuZCBtZSBjb3JyZWN0aW9ucyAoZXNw
ZWNpYWxseQo+PiA+ICJkb25lIikuIEkndmUgc3RvcHBlZCBDQ2luZyBldmVyeW9uZSwgc2luY2Ug
SSBndWVzcyBpdCBpcyBtb3N0bHkgc3BhbSB0bwo+PiA+IHRoZSBtYWpvcml0eS4KPj4gPgo+PiA+
IGh5cGVydmlzb3IsIGJsb2NrZXJzOgo+PiA+Cj4+ID4gwqAgwqAgwqAqIHJvdW5kLXVwIG9mIHRo
ZSBjbG9zaW5nIG9mIHRoZSBzZWN1cml0eSBob2xlIGluIE1TSS1YCj4+ID4gwqAgwqAgwqAgwqBw
YXNzdGhyb3VnaCAodW5pZm9ybWx5IC0gaS5lLiBldmVuIGZvciBEb20wIC0gZGlzYWxsb3dpbmcg
d3JpdGUKPj4gPiDCoCDCoCDCoCDCoGFjY2VzcyB0byBNU0ktWCB0YWJsZSBwYWdlcykuIChKYW4g
QmV1bGljaCAtLSBtb3JlIGZpeGVzCj4+ID4gwqAgwqAgwqAgwqByZXF1aXJlZCB0aGFuIGZpcnN0
IHRob3VnaHQsIHBhdGNoZXMgcG9zdGVkKQo+PiA+IMKgIMKgIMKgKiBkb21jdGxzIC8gc3lzY3Rs
cyBzZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBsaWtlCj4+ID4gwqAgwqAg
wqAgwqB0aGUgY3JlZGl0MSB0aW1lc2xpY2UgYW5kIHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVu
bGFwKQo+PiA+IMKgIMKgIMKgKiBnZXQgdGhlIGludGVyZmFjZSBjaGFuZ2VzIGZvciBzaGFyaW5n
L3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCj4+ID4gwqAgwqAgwqAgwqBkdXN0ZWQgc28gdGhh
dCA0LjIgaXMgYSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4gKFRpbSBEZWVnYW4sCj4+ID4g
wqAgwqAgwqAgwqBBbmRyZXMgTGFnYXItQ2F2aWxsYSBldCBhbCkKPj4gPiDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNlZW1zIGNsb3NlIHRv
IGdvaW5nCj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbi4KPj4gPiDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogc2hhcmluZyBwYXRjaGVzIHBvc3RlZAo+PiA+Cj4+ID4gdG9vbHMsIGJsb2NrZXJz
Ogo+PiA+Cj4+ID4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0
LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+PiA+IMKgIMKgIMKgIMKgd2hpY2ggZG93bnN0cmVh
bSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgo+PiA+IMKg
IMKgIMKgIMKgdGhpcyBhcmU6Cj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGV2ZW50IGhhbmRs
aW5nIChJYW4gSmFja3NvbiwgcG9zdGVkIHNldmVyYWwgcm91bmRzLAo+PiA+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgbmVhcmluZyBjb21wbGV0aW9uPykKPj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCogZHJvcCBsaWJ4bF9kZXZpY2VfbW9kZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2luZm8g
b3IKPj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkg
KElhbiBDYW1wYmVsbCwgZmlyc3QgUkZDIHNlbnQpCj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAq
IGFkZCBsaWJ4bF9kZWZib29sIGFuZCBnZW5lcmFsbHkgdHJ5IGFuZCBhcnJhbmdlIHRoYXQKPj4g
PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1lbXNldChmb28sMCwuLi4pIHJlcXVlc3RzIHRoZSBk
ZWZhdWx0cyAoSWFuIENhbXBiZWxsLAo+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmlyc3Qg
UkZDIHNlbnQpCj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIHRvcG9sb2d5aW5mbyBkYXRhc3Ry
dWN0dXJlIHNob3VsZCBiZSBhIGxpc3Qgb2YgdHVwbGVzLAo+PiA+IMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgbm90IGEgdHVwbGUgb2YgbGlzdHMuIChub2JvZHkgY3VycmVudGx5IGxvb2tpbmcgYXQg
dGhpcywKPj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5vdCAxMDAlIHN1cmUgdGhpcyBtYWtl
cyBzZW5zZSwgY291bGQgcG9zc2libHkgZGVmZXIgYW5kCj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqBjaGFuZ2UgYWZ0ZXIgNC4yIGluIGEgY29tcGF0aWJsZSB3YXkpCj4+ID4gwqAgwqAgwqAq
IHhsIHRvIHVzZSBqc29uIGZvciBtYWNoaW5lIHJlYWRhYmxlIG91dHB1dCBpbnN0ZWFkIG9mIHNl
eHAgYnkKPj4gPiDCoCDCoCDCoCDCoGRlZmF1bHQgKElhbiBDYW1wYmVsbCB0byByZXZpc2l0IGV4
aXN0aW5nIHBhdGNoKQo+PiA+IMKgIMKgIMKgKiB4bCBzdXBwb3J0IGZvciB2Y3B1IHBpbm5pbmcg
KERhcmlvIEZhZ2dpb2xpKQo+PiA+IMKgIMKgIMKgKiB4bCBmZWF0dXJlIHBhcml0eSB3aXRoIHhl
bmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9ydCAoR2VvcmdlCj4+ID4gwqAgwqAgwqAgwqBEdW5s
YXApCj4+ID4gwqAgwqAgwqAqIEludGVncmF0ZSBxZW11K3NlYWJpb3MgdXBzdHJlYW0gaW50byB0
aGUgYnVpbGQgKHBhdGNoZXMKPj4gPiDCoCDCoCDCoCDCoHJlcG9zdGVkLCBwZW5kaW5nKS4gTm8g
Y2hhbmdlIGluIGRlZmF1bHQgcWVtdSBmb3IgNC4yLgo+PiA+IMKgIMKgIMKgKiBNb3JlIGZvcm1h
bGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgo+PiA+IMKg
IMKgIMKgIMKgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24gYXJv
dW5kIC1yYzEgdG8KPj4gPiDCoCDCoCDCoCDCoHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPj4g
Pgo+PiA+IGh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKPj4gPgo+PiA+IMKgIMKgIMKgKiBzb2xp
ZCBpbXBsZW1lbnRhdGlvbiBvZiBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzICh1c2luZyB3b3Jr
Cj4+ID4gwqAgwqAgwqAgwqBxdWV1ZXMpIChUaW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcgZXQgYWwp
Cj4+ID4gwqAgwqAgwqAqIEEgbG9uZyBzdGFuZGluZyBpc3N1ZSBpcyBhIGZ1bGx5IHN5bmNocm9u
aXplZCBwMm0gKGxvY2tpbmcKPj4gPiDCoCDCoCDCoCDCoGxvb2t1cHMpIChBbmRyZXMgTGFnYXIt
Q2F2aWxsYSkKPj4gPiDCoCDCoCDCoCogTlVNQSBpbXByb3ZlbWVudDogZG9tYWluIGFmZmluaXR5
IGNvbnNpc3RlbnQgd2l0aCBjcHVwb29sCj4+ID4gwqAgwqAgwqAgwqBtZW1iZXJzaGlwIChEYXJp
byBGYWdnaW9saSwgSmV1cmdlbiBHcm9zcyAtLSBwYXRjaCBwb3N0ZWQpCj4+ID4KPj4gPiB0b29s
cywgbmljZSB0byBoYXZlOgo+PiA+Cj4+ID4gwqAgwqAgwqAqIEhvdHBsdWcgc2NyaXB0IHN0dWZm
IC0tIGludGVybmFsIHRvIGxpYnhsIChJIHRoaW5rLCB0aGVyZWZvcmUgSQo+PiA+IMKgIMKgIMKg
IMKgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0YWJsZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29k
IHRvIGhhdmUKPj4gPiDCoCDCoCDCoCDCoGZvciA0LjI/IFJvZ2VyIFBhdSBNb25ldCB3YXMgbG9v
a2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9va2luZwo+PiA+IMKgIMKgIMKgIMKgbGlrZSBhIGJpZyBj
YW4tby13b3Jtcy4gKGRpc2N1c3Npb24gb24tZ29pbmcpCj4+ID4gwqAgwqAgwqAqIEJsb2NrIHNj
cmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIKPj4g
PiDCoCDCoCDCoCDCoFBhdSBNb25ldCkKPj4gPiDCoCDCoCDCoCogbGlieWFqbCB2MiBzdXBwb3J0
IChwYXRjaCBwb3N0ZWQgYnkgUm9nZXIgUGF1IE1vbmV0LCBibG9ja2VkIG9uCj4+ID4gwqAgwqAg
wqAgwqBhdXRvY29uZj8pCj4+ID4gwqAgwqAgwqAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2
aWEgeGwvbGlieGwgKE9sYWYgSGVycmluZykKPj4gPiDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBm
ZWF0dXJlIHBhdGNoZXM6Cj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIFVwc3RyZWFtIHFlbXUg
UENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkgUGVyYXJkKQo+PiA+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgKiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQpCj4+
ID4gwqAgwqAgwqAqIE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3VycmVudGx5IHNob3VsZCBiZSBt
YXJrZWQKPj4gPiDCoCDCoCDCoCDCoGV4cGVyaW1lbnRhbCxsaWtlbHkgdG8gcmVsZWFzZSB0aGF0
IHdheT8gQ29uc2lkZXIgbmVzdGVkLXN2bQo+PiA+IMKgIMKgIMKgIMKgc2VwYXJhdGUgdG8gbmVz
dGVkLXZteC4gTmVzdGVkLXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCj4+Cj4+Cj4+IEp1c3QgYSBy
YW5kb20gdGhvdWdodCwgYnV0IEkgZmluZCBpdCBxdWl0ZSBhbm5veWluZyB0byBuZWVkIGxhdGV4
IHRvCj4+IGNvbXBpbGUgdGhlIGRvY3VtZW50YXRpb24uIEkgdGhpbmsgaXQgd2lsbCBiZSB3aXNl
IHRvIGNyZWF0ZSBhIG5ldwo+PiBNYWtlZmlsZSB0YXJnZXQsIGxpa2UgbWFuLXBhZ2VzIGFuZCBp
bnN0YWxsLW1hbi1wYWdlcyB0byBhbGxvdyB0aGUKPj4gdXNlciB0byBidWlsZCBhbmQgaW5zdGFs
bCBtYW4gcGFnZXMgb25seSAob3IgZG9uJ3QgYWJvcnQgZG9jcyBidWlsZCBpZgo+PiBsYXRleCBp
cyBub3QgZm91bmQpLiBQZXJzb25hbGx5IEkgZG9uJ3QgaGF2ZSBsYXRleCBvbiBteSBzZXJ2ZXIs
IGFuZCBJCj4+IGRvbid0IHdhbnQgdG8gaW5zdGFsbCBpdCwgYnV0IEkgd291bGQgbGlrZSB0byBo
YXZlIHRoZSBtYW4gcGFnZXMgd2hlbgo+PiBidWlsZGluZyBYZW4gZnJvbSBzb3VyY2UuCj4KPiAi
bWFrZSAtQyBkb2NzIG1hbi1wYWdlcyIgd2lsbCBkbyB3aGF0IHlvdSB3YW50LgoKVGhhbmtzLCBJ
J3ZlIGFscmVhZHkgZG9uZSB0aGlzIHRvIGJ1aWxkIHRoZW0gb24gbXkgc3lzdGVtLCBidXQgSSB0
aGluawp3ZSBzaG91bGQgcHJvdmlkZSBzb21lIGVhc3kgd2F5IGZvciB1c2VycyB3aXRob3V0IGxh
dGV4IHRvIGJ1aWxkIGFuZAppbnN0YWxsIHRoZSBtYW4gcGFnZXMuCgo+IEkgbXVzdCBhZG1pdCBJ
IHRob3VnaHQgbGF0ZXggd2FzIG9wdGlvbmFsIGFuZCB0aGF0ICJtYWtlIGRvY3MiIHdvdWxkCj4g
c2ltcGx5IHNraXAgdGhvc2UgZG9jcyBpZiBpdCB3YXNuJ3QgaW5zdGFsbGVkIC0tIHRoYXQncyB3
aGF0IHRoZSAiaWYKPiB3aGljaCAkKFRPT0wpIiBjb25zdHJ1Y3QgdXNlZCBpbiB0aGVyZSBpcyAo
c3VwcG9zZWQgdG8gYmUpIGRvaW5nLgoKSWYgbGF0ZXggaXMgbm90IGZvdW5kLCB0aGUgY29tcGls
YXRpb24gaXMgYWJvcnRlZDoKCiMgbWFrZSBkb2NzCnNoIC4vZG9jcy9jaGVja19wa2dzICYmIG1h
a2UgLUMgZG9jcyBpbnN0YWxsIHx8IHRydWUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09Cj0gV0FSTklORzogUGFja2FnZSAnbGF0ZXgnIGlzIHJlcXVpcmVkCj0gICAg
ICAgICAgdG8gYnVpbGQgWGVuIGRvY3VtZW50YXRpb24KPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09CgpJIHRoaW5rIG1ha2UgZG9jcyBzaG91bGQganVzdCBza2lwIGxh
dGV4IGlmIG5vdCBmb3VuZC4KCj4KPiBJYW4uCj4KPj4KPj4gPiBUb29scywgbmVlZCB0byBkZWNp
ZGUgaWYgcHJlLSBvciBwb3N0LTQuMiBmZWF0dXJlOgo+PiA+Cj4+ID4gwqAgwqAgwqAqIEF1dG9j
b25mIChSb2dlciBQYXUgTW9uZXQgcG9zdGVkIGEgcGF0Y2gpCj4+ID4KPj4gPgo+PiA+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+ID4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+PiA+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4+ID4gaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCj4KPgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:49:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:49:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4A0-0004oK-5Z; Wed, 25 Jan 2012 14:49:16 +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 1Rq49y-0004nu-PC
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:49:15 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327502946!12369236!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5958 invoked from network); 25 Jan 2012 14:49:08 -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;
	25 Jan 2012 14:49:08 -0000
Received: by pbdx13 with SMTP id x13so14708917pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 06:49: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=fK5XVcbrDfTQQ8Hh6qVoAld3ILlW8apI5IEqe9ckkmo=;
	b=hJbzW0qUBDm8FIYb0VwHm/DKOGlyembD0QdlrDD5LYfYdUAl/U7NUEa5HLcAEj8eWP
	YLHmQEWK7xa86ktdBCKUjOJ70To7rspmrj94PnUNutM8Pko59m1xJsG9fHhjmS/WgABx
	XgASxliHGtMM39qeQnrj3ClQ4pAWItYm4iidM=
MIME-Version: 1.0
Received: by 10.68.238.229 with SMTP id vn5mr2726135pbc.39.1327502945973; Wed,
	25 Jan 2012 06:49:05 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Wed, 25 Jan 2012 06:49:05 -0800 (PST)
In-Reply-To: <1327502464.24561.325.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
	<1327502464.24561.325.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 15:49:05 +0100
X-Google-Sender-Auth: whkIk_Gs0K-VfrPZiYHJQc0xMBo
Message-ID: <CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI1IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMS0yNSBhdCAxNDozMyArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE5l
d2x5IHVwZGF0ZWQgbGlzdCBmb2xsb3dzLiBQbGVhc2Ugc2VuZCBtZSBjb3JyZWN0aW9ucyAoZXNw
ZWNpYWxseQo+PiA+ICJkb25lIikuIEkndmUgc3RvcHBlZCBDQ2luZyBldmVyeW9uZSwgc2luY2Ug
SSBndWVzcyBpdCBpcyBtb3N0bHkgc3BhbSB0bwo+PiA+IHRoZSBtYWpvcml0eS4KPj4gPgo+PiA+
IGh5cGVydmlzb3IsIGJsb2NrZXJzOgo+PiA+Cj4+ID4gwqAgwqAgwqAqIHJvdW5kLXVwIG9mIHRo
ZSBjbG9zaW5nIG9mIHRoZSBzZWN1cml0eSBob2xlIGluIE1TSS1YCj4+ID4gwqAgwqAgwqAgwqBw
YXNzdGhyb3VnaCAodW5pZm9ybWx5IC0gaS5lLiBldmVuIGZvciBEb20wIC0gZGlzYWxsb3dpbmcg
d3JpdGUKPj4gPiDCoCDCoCDCoCDCoGFjY2VzcyB0byBNU0ktWCB0YWJsZSBwYWdlcykuIChKYW4g
QmV1bGljaCAtLSBtb3JlIGZpeGVzCj4+ID4gwqAgwqAgwqAgwqByZXF1aXJlZCB0aGFuIGZpcnN0
IHRob3VnaHQsIHBhdGNoZXMgcG9zdGVkKQo+PiA+IMKgIMKgIMKgKiBkb21jdGxzIC8gc3lzY3Rs
cyBzZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBsaWtlCj4+ID4gwqAgwqAg
wqAgwqB0aGUgY3JlZGl0MSB0aW1lc2xpY2UgYW5kIHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVu
bGFwKQo+PiA+IMKgIMKgIMKgKiBnZXQgdGhlIGludGVyZmFjZSBjaGFuZ2VzIGZvciBzaGFyaW5n
L3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCj4+ID4gwqAgwqAgwqAgwqBkdXN0ZWQgc28gdGhh
dCA0LjIgaXMgYSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4gKFRpbSBEZWVnYW4sCj4+ID4g
wqAgwqAgwqAgwqBBbmRyZXMgTGFnYXItQ2F2aWxsYSBldCBhbCkKPj4gPiDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNlZW1zIGNsb3NlIHRv
IGdvaW5nCj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbi4KPj4gPiDCoCDCoCDCoCDCoCDC
oCDCoCDCoCogc2hhcmluZyBwYXRjaGVzIHBvc3RlZAo+PiA+Cj4+ID4gdG9vbHMsIGJsb2NrZXJz
Ogo+PiA+Cj4+ID4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0
LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+PiA+IMKgIMKgIMKgIMKgd2hpY2ggZG93bnN0cmVh
bSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4gQXNwZWN0cyBvZgo+PiA+IMKg
IMKgIMKgIMKgdGhpcyBhcmU6Cj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGV2ZW50IGhhbmRs
aW5nIChJYW4gSmFja3NvbiwgcG9zdGVkIHNldmVyYWwgcm91bmRzLAo+PiA+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgIMKgbmVhcmluZyBjb21wbGV0aW9uPykKPj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDC
oCogZHJvcCBsaWJ4bF9kZXZpY2VfbW9kZWxfaW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2luZm8g
b3IKPj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkg
KElhbiBDYW1wYmVsbCwgZmlyc3QgUkZDIHNlbnQpCj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAq
IGFkZCBsaWJ4bF9kZWZib29sIGFuZCBnZW5lcmFsbHkgdHJ5IGFuZCBhcnJhbmdlIHRoYXQKPj4g
PiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG1lbXNldChmb28sMCwuLi4pIHJlcXVlc3RzIHRoZSBk
ZWZhdWx0cyAoSWFuIENhbXBiZWxsLAo+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmlyc3Qg
UkZDIHNlbnQpCj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIHRvcG9sb2d5aW5mbyBkYXRhc3Ry
dWN0dXJlIHNob3VsZCBiZSBhIGxpc3Qgb2YgdHVwbGVzLAo+PiA+IMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgbm90IGEgdHVwbGUgb2YgbGlzdHMuIChub2JvZHkgY3VycmVudGx5IGxvb2tpbmcgYXQg
dGhpcywKPj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5vdCAxMDAlIHN1cmUgdGhpcyBtYWtl
cyBzZW5zZSwgY291bGQgcG9zc2libHkgZGVmZXIgYW5kCj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqBjaGFuZ2UgYWZ0ZXIgNC4yIGluIGEgY29tcGF0aWJsZSB3YXkpCj4+ID4gwqAgwqAgwqAq
IHhsIHRvIHVzZSBqc29uIGZvciBtYWNoaW5lIHJlYWRhYmxlIG91dHB1dCBpbnN0ZWFkIG9mIHNl
eHAgYnkKPj4gPiDCoCDCoCDCoCDCoGRlZmF1bHQgKElhbiBDYW1wYmVsbCB0byByZXZpc2l0IGV4
aXN0aW5nIHBhdGNoKQo+PiA+IMKgIMKgIMKgKiB4bCBzdXBwb3J0IGZvciB2Y3B1IHBpbm5pbmcg
KERhcmlvIEZhZ2dpb2xpKQo+PiA+IMKgIMKgIMKgKiB4bCBmZWF0dXJlIHBhcml0eSB3aXRoIHhl
bmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9ydCAoR2VvcmdlCj4+ID4gwqAgwqAgwqAgwqBEdW5s
YXApCj4+ID4gwqAgwqAgwqAqIEludGVncmF0ZSBxZW11K3NlYWJpb3MgdXBzdHJlYW0gaW50byB0
aGUgYnVpbGQgKHBhdGNoZXMKPj4gPiDCoCDCoCDCoCDCoHJlcG9zdGVkLCBwZW5kaW5nKS4gTm8g
Y2hhbmdlIGluIGRlZmF1bHQgcWVtdSBmb3IgNC4yLgo+PiA+IMKgIMKgIMKgKiBNb3JlIGZvcm1h
bGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNoZXMgYWxyZWFkeSBpbgo+PiA+IMKg
IMKgIMKgIMKgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3RpbmcgYW5kIGNvbW11bmljYXRpb24gYXJv
dW5kIC1yYzEgdG8KPj4gPiDCoCDCoCDCoCDCoHJlbWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPj4g
Pgo+PiA+IGh5cGVydmlzb3IsIG5pY2UgdG8gaGF2ZToKPj4gPgo+PiA+IMKgIMKgIMKgKiBzb2xp
ZCBpbXBsZW1lbnRhdGlvbiBvZiBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzICh1c2luZyB3b3Jr
Cj4+ID4gwqAgwqAgwqAgwqBxdWV1ZXMpIChUaW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcgZXQgYWwp
Cj4+ID4gwqAgwqAgwqAqIEEgbG9uZyBzdGFuZGluZyBpc3N1ZSBpcyBhIGZ1bGx5IHN5bmNocm9u
aXplZCBwMm0gKGxvY2tpbmcKPj4gPiDCoCDCoCDCoCDCoGxvb2t1cHMpIChBbmRyZXMgTGFnYXIt
Q2F2aWxsYSkKPj4gPiDCoCDCoCDCoCogTlVNQSBpbXByb3ZlbWVudDogZG9tYWluIGFmZmluaXR5
IGNvbnNpc3RlbnQgd2l0aCBjcHVwb29sCj4+ID4gwqAgwqAgwqAgwqBtZW1iZXJzaGlwIChEYXJp
byBGYWdnaW9saSwgSmV1cmdlbiBHcm9zcyAtLSBwYXRjaCBwb3N0ZWQpCj4+ID4KPj4gPiB0b29s
cywgbmljZSB0byBoYXZlOgo+PiA+Cj4+ID4gwqAgwqAgwqAqIEhvdHBsdWcgc2NyaXB0IHN0dWZm
IC0tIGludGVybmFsIHRvIGxpYnhsIChJIHRoaW5rLCB0aGVyZWZvcmUgSQo+PiA+IMKgIMKgIMKg
IMKgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0YWJsZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29k
IHRvIGhhdmUKPj4gPiDCoCDCoCDCoCDCoGZvciA0LjI/IFJvZ2VyIFBhdSBNb25ldCB3YXMgbG9v
a2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9va2luZwo+PiA+IMKgIMKgIMKgIMKgbGlrZSBhIGJpZyBj
YW4tby13b3Jtcy4gKGRpc2N1c3Npb24gb24tZ29pbmcpCj4+ID4gwqAgwqAgwqAqIEJsb2NrIHNj
cmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3RwbHVnIHNjcmlwdCAoUm9nZXIKPj4g
PiDCoCDCoCDCoCDCoFBhdSBNb25ldCkKPj4gPiDCoCDCoCDCoCogbGlieWFqbCB2MiBzdXBwb3J0
IChwYXRjaCBwb3N0ZWQgYnkgUm9nZXIgUGF1IE1vbmV0LCBibG9ja2VkIG9uCj4+ID4gwqAgwqAg
wqAgwqBhdXRvY29uZj8pCj4+ID4gwqAgwqAgwqAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2
aWEgeGwvbGlieGwgKE9sYWYgSGVycmluZykKPj4gPiDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBm
ZWF0dXJlIHBhdGNoZXM6Cj4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIFVwc3RyZWFtIHFlbXUg
UENJIHBhc3N0aHJvdWdoIHN1cHBvcnQgKEFudGhvbnkgUGVyYXJkKQo+PiA+IMKgIMKgIMKgIMKg
IMKgIMKgIMKgKiBVcHN0cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQpCj4+
ID4gwqAgwqAgwqAqIE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3VycmVudGx5IHNob3VsZCBiZSBt
YXJrZWQKPj4gPiDCoCDCoCDCoCDCoGV4cGVyaW1lbnRhbCxsaWtlbHkgdG8gcmVsZWFzZSB0aGF0
IHdheT8gQ29uc2lkZXIgbmVzdGVkLXN2bQo+PiA+IMKgIMKgIMKgIMKgc2VwYXJhdGUgdG8gbmVz
dGVkLXZteC4gTmVzdGVkLXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCj4+Cj4+Cj4+IEp1c3QgYSBy
YW5kb20gdGhvdWdodCwgYnV0IEkgZmluZCBpdCBxdWl0ZSBhbm5veWluZyB0byBuZWVkIGxhdGV4
IHRvCj4+IGNvbXBpbGUgdGhlIGRvY3VtZW50YXRpb24uIEkgdGhpbmsgaXQgd2lsbCBiZSB3aXNl
IHRvIGNyZWF0ZSBhIG5ldwo+PiBNYWtlZmlsZSB0YXJnZXQsIGxpa2UgbWFuLXBhZ2VzIGFuZCBp
bnN0YWxsLW1hbi1wYWdlcyB0byBhbGxvdyB0aGUKPj4gdXNlciB0byBidWlsZCBhbmQgaW5zdGFs
bCBtYW4gcGFnZXMgb25seSAob3IgZG9uJ3QgYWJvcnQgZG9jcyBidWlsZCBpZgo+PiBsYXRleCBp
cyBub3QgZm91bmQpLiBQZXJzb25hbGx5IEkgZG9uJ3QgaGF2ZSBsYXRleCBvbiBteSBzZXJ2ZXIs
IGFuZCBJCj4+IGRvbid0IHdhbnQgdG8gaW5zdGFsbCBpdCwgYnV0IEkgd291bGQgbGlrZSB0byBo
YXZlIHRoZSBtYW4gcGFnZXMgd2hlbgo+PiBidWlsZGluZyBYZW4gZnJvbSBzb3VyY2UuCj4KPiAi
bWFrZSAtQyBkb2NzIG1hbi1wYWdlcyIgd2lsbCBkbyB3aGF0IHlvdSB3YW50LgoKVGhhbmtzLCBJ
J3ZlIGFscmVhZHkgZG9uZSB0aGlzIHRvIGJ1aWxkIHRoZW0gb24gbXkgc3lzdGVtLCBidXQgSSB0
aGluawp3ZSBzaG91bGQgcHJvdmlkZSBzb21lIGVhc3kgd2F5IGZvciB1c2VycyB3aXRob3V0IGxh
dGV4IHRvIGJ1aWxkIGFuZAppbnN0YWxsIHRoZSBtYW4gcGFnZXMuCgo+IEkgbXVzdCBhZG1pdCBJ
IHRob3VnaHQgbGF0ZXggd2FzIG9wdGlvbmFsIGFuZCB0aGF0ICJtYWtlIGRvY3MiIHdvdWxkCj4g
c2ltcGx5IHNraXAgdGhvc2UgZG9jcyBpZiBpdCB3YXNuJ3QgaW5zdGFsbGVkIC0tIHRoYXQncyB3
aGF0IHRoZSAiaWYKPiB3aGljaCAkKFRPT0wpIiBjb25zdHJ1Y3QgdXNlZCBpbiB0aGVyZSBpcyAo
c3VwcG9zZWQgdG8gYmUpIGRvaW5nLgoKSWYgbGF0ZXggaXMgbm90IGZvdW5kLCB0aGUgY29tcGls
YXRpb24gaXMgYWJvcnRlZDoKCiMgbWFrZSBkb2NzCnNoIC4vZG9jcy9jaGVja19wa2dzICYmIG1h
a2UgLUMgZG9jcyBpbnN0YWxsIHx8IHRydWUKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09Cj0gV0FSTklORzogUGFja2FnZSAnbGF0ZXgnIGlzIHJlcXVpcmVkCj0gICAg
ICAgICAgdG8gYnVpbGQgWGVuIGRvY3VtZW50YXRpb24KPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09CgpJIHRoaW5rIG1ha2UgZG9jcyBzaG91bGQganVzdCBza2lwIGxh
dGV4IGlmIG5vdCBmb3VuZC4KCj4KPiBJYW4uCj4KPj4KPj4gPiBUb29scywgbmVlZCB0byBkZWNp
ZGUgaWYgcHJlLSBvciBwb3N0LTQuMiBmZWF0dXJlOgo+PiA+Cj4+ID4gwqAgwqAgwqAqIEF1dG9j
b25mIChSb2dlciBQYXUgTW9uZXQgcG9zdGVkIGEgcGF0Y2gpCj4+ID4KPj4gPgo+PiA+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+ID4gWGVuLWRldmVs
IG1haWxpbmcgbGlzdAo+PiA+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4+ID4gaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCj4KPgoKX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4t
ZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4t
ZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:49:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:49:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4AS-0004rH-LI; Wed, 25 Jan 2012 14:49:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rq4AQ-0004qt-VY
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:49:43 +0000
Received: from [85.158.138.51:46575] by server-5.bemta-3.messagelabs.com id
	BB/18-02363-686102F4; Wed, 25 Jan 2012 14:49:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327502981!10645965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11832 invoked from network); 25 Jan 2012 14:49:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:49:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:49: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; Wed, 25 Jan 2012 14:49: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
	1Rq4AP-0000G3-3j; Wed, 25 Jan 2012 14:49:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rq4AP-000871-2v;
	Wed, 25 Jan 2012 14:49:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20256.5765.77301.338576@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 14:49:41 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327489070.24561.276.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
	<1326970442.17599.53.camel@zakaz.uk.xensource.com>
	<20254.60260.642300.195152@mariner.uk.xensource.com>
	<1327489070.24561.276.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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 8/9] libxl: Introduce libxl__ev_devstate"):
> On Tue, 2012-01-24 at 17:33 +0000, Ian Jackson wrote:
> > So, no.  When the timeout happens, the ev xswatch is deregistered and
> > can thereafter no longer generate callbacks.  If there are any
> > xenstore watch events in the pipeline for deregistered ev_xswatch's,
> > they're discarded by watchfd_callback.
> 
> What happens if the watch occurs and is delivered (in a different
> thread) e.g. just before devstate_timeout calls
> libxl__ev_devstate_cancel? The watch callback will be delivered but we
> will unconditionally go on to deliver the cancel callback as well.

All of these callback functions are called with the lock held, so
there aren't any of these kind of races.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:49:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:49:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4AS-0004rH-LI; Wed, 25 Jan 2012 14:49:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rq4AQ-0004qt-VY
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:49:43 +0000
Received: from [85.158.138.51:46575] by server-5.bemta-3.messagelabs.com id
	BB/18-02363-686102F4; Wed, 25 Jan 2012 14:49:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327502981!10645965!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11832 invoked from network); 25 Jan 2012 14:49:41 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:49:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10283993"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:49: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; Wed, 25 Jan 2012 14:49: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
	1Rq4AP-0000G3-3j; Wed, 25 Jan 2012 14:49:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rq4AP-000871-2v;
	Wed, 25 Jan 2012 14:49:41 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20256.5765.77301.338576@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 14:49:41 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327489070.24561.276.camel@zakaz.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-9-git-send-email-ian.jackson@eu.citrix.com>
	<1326970442.17599.53.camel@zakaz.uk.xensource.com>
	<20254.60260.642300.195152@mariner.uk.xensource.com>
	<1327489070.24561.276.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 8/9] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 8/9] libxl: Introduce libxl__ev_devstate"):
> On Tue, 2012-01-24 at 17:33 +0000, Ian Jackson wrote:
> > So, no.  When the timeout happens, the ev xswatch is deregistered and
> > can thereafter no longer generate callbacks.  If there are any
> > xenstore watch events in the pipeline for deregistered ev_xswatch's,
> > they're discarded by watchfd_callback.
> 
> What happens if the watch occurs and is delivered (in a different
> thread) e.g. just before devstate_timeout calls
> libxl__ev_devstate_cancel? The watch callback will be delivered but we
> will unconditionally go on to deliver the cancel callback as well.

All of these callback functions are called with the lock held, so
there aren't any of these kind of races.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:58:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4IS-0005Bw-8R; Wed, 25 Jan 2012 14:58:00 +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 1Rq4IQ-0005Br-EN
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:57:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327503472!12470532!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1297 invoked from network); 25 Jan 2012 14:57:52 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:57:52 -0000
Received: by werb14 with SMTP id b14so13790006wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 06:57: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=c1mYwShqYzh2BAE9bM7FK+13gNLn9CrkXuuORlsajns=;
	b=aysts9pQV8iXQ/51a4beoHiJPmb6lgsOsTYL4bK5Qfnyb7EDaoPi7Wdj+vPI6y9d56
	QJGA289OUJW94LtAMa/xY9Ok05wzJz4H0i+wOOTcHDYmLIoRurhxWJCZpMc0b3S6grEO
	ALyj/YoZ8fkONaa+hA7Ni5LpAQRagnFrCaEEM=
Received: by 10.216.137.165 with SMTP id y37mr6929681wei.10.1327503472281;
	Wed, 25 Jan 2012 06:57:52 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id di5sm2379312wib.3.2012.01.25.06.57.50
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 06:57:51 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jan 2012 14:57:47 +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: <CB45C8EB.29986%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen 4.2 TODO List Update
Thread-Index: AczbcbMhEPamWNU9QkGOTQ9CFlhnug==
In-Reply-To: <CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/01/2012 14:49, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

>>> don't want to install it, but I would like to have the man pages when
>>
>>> building Xen from source.
>
> "make -C docs man-pages" will do what you
>>> want.

Thanks, I've already done this to build them on my system, but I
>>> think
we should provide some easy way for users without latex to build
>>> and
install the man pages.

> I must admit I thought latex was optional and
>>> that "make docs" would
> simply skip those docs if it wasn't installed --
>>> that's what the "if
> which $(TOOL)" construct used in there is (supposed to
>>> be) doing.

If latex is not found, the compilation is aborted:

# make
>>> docs
sh ./docs/check_pkgs && make -C docs install ||
>>> true
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
=3D WARNING: Package 'latex' is required
=3D
>>> to build Xen =

>>> documentation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I think make docs should just skip
>>> latex if not found.

I'm dubious whether the latex docs are at all useful these days. We could
possibly just remove them entirely.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:58:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:58:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4IS-0005Bw-8R; Wed, 25 Jan 2012 14:58:00 +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 1Rq4IQ-0005Br-EN
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:57:58 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327503472!12470532!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1297 invoked from network); 25 Jan 2012 14:57:52 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:57:52 -0000
Received: by werb14 with SMTP id b14so13790006wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 06:57: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=c1mYwShqYzh2BAE9bM7FK+13gNLn9CrkXuuORlsajns=;
	b=aysts9pQV8iXQ/51a4beoHiJPmb6lgsOsTYL4bK5Qfnyb7EDaoPi7Wdj+vPI6y9d56
	QJGA289OUJW94LtAMa/xY9Ok05wzJz4H0i+wOOTcHDYmLIoRurhxWJCZpMc0b3S6grEO
	ALyj/YoZ8fkONaa+hA7Ni5LpAQRagnFrCaEEM=
Received: by 10.216.137.165 with SMTP id y37mr6929681wei.10.1327503472281;
	Wed, 25 Jan 2012 06:57:52 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id di5sm2379312wib.3.2012.01.25.06.57.50
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 06:57:51 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jan 2012 14:57:47 +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: <CB45C8EB.29986%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] Xen 4.2 TODO List Update
Thread-Index: AczbcbMhEPamWNU9QkGOTQ9CFlhnug==
In-Reply-To: <CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/01/2012 14:49, "Roger Pau Monn=E9" <roger.pau@entel.upc.edu> wrote:

>>> don't want to install it, but I would like to have the man pages when
>>
>>> building Xen from source.
>
> "make -C docs man-pages" will do what you
>>> want.

Thanks, I've already done this to build them on my system, but I
>>> think
we should provide some easy way for users without latex to build
>>> and
install the man pages.

> I must admit I thought latex was optional and
>>> that "make docs" would
> simply skip those docs if it wasn't installed --
>>> that's what the "if
> which $(TOOL)" construct used in there is (supposed to
>>> be) doing.

If latex is not found, the compilation is aborted:

# make
>>> docs
sh ./docs/check_pkgs && make -C docs install ||
>>> true
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
=3D WARNING: Package 'latex' is required
=3D
>>> to build Xen =

>>> documentation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I think make docs should just skip
>>> latex if not found.

I'm dubious whether the latex docs are at all useful these days. We could
possibly just remove them entirely.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:59:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4Jd-0005GC-Mt; Wed, 25 Jan 2012 14:59: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 1Rq4Jc-0005Fm-UE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:59:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327503546!12500422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10294 invoked from network); 25 Jan 2012 14:59:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:59:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10284332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:59: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, 25 Jan 2012 14:59:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 25 Jan 2012 14:59:06 +0000
In-Reply-To: <CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
	<1327502464.24561.325.camel@zakaz.uk.xensource.com>
	<CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327503546.24561.331.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDE0OjQ5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8yNSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFdlZCwgMjAxMi0wMS0yNSBhdCAxNDozMyArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90
ZToKPiA+PiAyMDEyLzEvMjMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46
Cj4gPj4gPiBOZXdseSB1cGRhdGVkIGxpc3QgZm9sbG93cy4gUGxlYXNlIHNlbmQgbWUgY29ycmVj
dGlvbnMgKGVzcGVjaWFsbHkKPiA+PiA+ICJkb25lIikuIEkndmUgc3RvcHBlZCBDQ2luZyBldmVy
eW9uZSwgc2luY2UgSSBndWVzcyBpdCBpcyBtb3N0bHkgc3BhbSB0bwo+ID4+ID4gdGhlIG1ham9y
aXR5Lgo+ID4+ID4KPiA+PiA+IGh5cGVydmlzb3IsIGJsb2NrZXJzOgo+ID4+ID4KPiA+PiA+ICAg
ICAgKiByb3VuZC11cCBvZiB0aGUgY2xvc2luZyBvZiB0aGUgc2VjdXJpdHkgaG9sZSBpbiBNU0kt
WAo+ID4+ID4gICAgICAgIHBhc3N0aHJvdWdoICh1bmlmb3JtbHkgLSBpLmUuIGV2ZW4gZm9yIERv
bTAgLSBkaXNhbGxvd2luZyB3cml0ZQo+ID4+ID4gICAgICAgIGFjY2VzcyB0byBNU0ktWCB0YWJs
ZSBwYWdlcykuIChKYW4gQmV1bGljaCAtLSBtb3JlIGZpeGVzCj4gPj4gPiAgICAgICAgcmVxdWly
ZWQgdGhhbiBmaXJzdCB0aG91Z2h0LCBwYXRjaGVzIHBvc3RlZCkKPiA+PiA+ICAgICAgKiBkb21j
dGxzIC8gc3lzY3RscyBzZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBsaWtl
Cj4gPj4gPiAgICAgICAgdGhlIGNyZWRpdDEgdGltZXNsaWNlIGFuZCBzY2hlZHVsZSByYXRlLiAo
R2VvcmdlIER1bmxhcCkKPiA+PiA+ICAgICAgKiBnZXQgdGhlIGludGVyZmFjZSBjaGFuZ2VzIGZv
ciBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCj4gPj4gPiAgICAgICAgZHVzdGVk
IHNvIHRoYXQgNC4yIGlzIGEgc3RhYmxlIEFQSSB0aGF0IHdlIGhvbGQgdG8uIChUaW0gRGVlZ2Fu
LAo+ID4+ID4gICAgICAgIEFuZHJlcyBMYWdhci1DYXZpbGxhIGV0IGFsKQo+ID4+ID4gICAgICAg
ICAgICAgICogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNlZW1zIGNsb3NlIHRv
IGdvaW5nCj4gPj4gPiAgICAgICAgICAgICAgICBpbi4KPiA+PiA+ICAgICAgICAgICAgICAqIHNo
YXJpbmcgcGF0Y2hlcyBwb3N0ZWQKPiA+PiA+Cj4gPj4gPiB0b29scywgYmxvY2tlcnM6Cj4gPj4g
Pgo+ID4+ID4gICAgICAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8g
ZGVmaW5lIGEgc3RhYmxlIEFQSQo+ID4+ID4gICAgICAgIHdoaWNoIGRvd25zdHJlYW0ncyBjYW4g
c3RhcnQgdG8gcmVseSBvbiBub3QgY2hhbmdpbmcuIEFzcGVjdHMgb2YKPiA+PiA+ICAgICAgICB0
aGlzIGFyZToKPiA+PiA+ICAgICAgICAgICAgICAqIGV2ZW50IGhhbmRsaW5nIChJYW4gSmFja3Nv
biwgcG9zdGVkIHNldmVyYWwgcm91bmRzLAo+ID4+ID4gICAgICAgICAgICAgICAgbmVhcmluZyBj
b21wbGV0aW9uPykKPiA+PiA+ICAgICAgICAgICAgICAqIGRyb3AgbGlieGxfZGV2aWNlX21vZGVs
X2luZm8gKG1vdmUgYml0cyB0byBidWlsZF9pbmZvIG9yCj4gPj4gPiAgICAgICAgICAgICAgICBl
bHNld2hlcmUgYXMgYXBwcm9wcmlhdGUpIChJYW4gQ2FtcGJlbGwsIGZpcnN0IFJGQyBzZW50KQo+
ID4+ID4gICAgICAgICAgICAgICogYWRkIGxpYnhsX2RlZmJvb2wgYW5kIGdlbmVyYWxseSB0cnkg
YW5kIGFycmFuZ2UgdGhhdAo+ID4+ID4gICAgICAgICAgICAgICAgbWVtc2V0KGZvbywwLC4uLikg
cmVxdWVzdHMgdGhlIGRlZmF1bHRzIChJYW4gQ2FtcGJlbGwsCj4gPj4gPiAgICAgICAgICAgICAg
ICBmaXJzdCBSRkMgc2VudCkKPiA+PiA+ICAgICAgICAgICAgICAqIHRvcG9sb2d5aW5mbyBkYXRh
c3RydWN0dXJlIHNob3VsZCBiZSBhIGxpc3Qgb2YgdHVwbGVzLAo+ID4+ID4gICAgICAgICAgICAg
ICAgbm90IGEgdHVwbGUgb2YgbGlzdHMuIChub2JvZHkgY3VycmVudGx5IGxvb2tpbmcgYXQgdGhp
cywKPiA+PiA+ICAgICAgICAgICAgICAgIG5vdCAxMDAlIHN1cmUgdGhpcyBtYWtlcyBzZW5zZSwg
Y291bGQgcG9zc2libHkgZGVmZXIgYW5kCj4gPj4gPiAgICAgICAgICAgICAgICBjaGFuZ2UgYWZ0
ZXIgNC4yIGluIGEgY29tcGF0aWJsZSB3YXkpCj4gPj4gPiAgICAgICogeGwgdG8gdXNlIGpzb24g
Zm9yIG1hY2hpbmUgcmVhZGFibGUgb3V0cHV0IGluc3RlYWQgb2Ygc2V4cCBieQo+ID4+ID4gICAg
ICAgIGRlZmF1bHQgKElhbiBDYW1wYmVsbCB0byByZXZpc2l0IGV4aXN0aW5nIHBhdGNoKQo+ID4+
ID4gICAgICAqIHhsIHN1cHBvcnQgZm9yIHZjcHUgcGlubmluZyAoRGFyaW8gRmFnZ2lvbGkpCj4g
Pj4gPiAgICAgICogeGwgZmVhdHVyZSBwYXJpdHkgd2l0aCB4ZW5kIHdydCBkcml2ZXIgZG9tYWlu
IHN1cHBvcnQgKEdlb3JnZQo+ID4+ID4gICAgICAgIER1bmxhcCkKPiA+PiA+ICAgICAgKiBJbnRl
Z3JhdGUgcWVtdStzZWFiaW9zIHVwc3RyZWFtIGludG8gdGhlIGJ1aWxkIChwYXRjaGVzCj4gPj4g
PiAgICAgICAgcmVwb3N0ZWQsIHBlbmRpbmcpLiBObyBjaGFuZ2UgaW4gZGVmYXVsdCBxZW11IGZv
ciA0LjIuCj4gPj4gPiAgICAgICogTW9yZSBmb3JtYWxseSBkZXByZWNhdGUgeG0veGVuZC4gTWFu
cGFnZSBwYXRjaGVzIGFscmVhZHkgaW4KPiA+PiA+ICAgICAgICB0cmVlLiBOZWVkcyByZWxlYXNl
IG5vdGluZyBhbmQgY29tbXVuaWNhdGlvbiBhcm91bmQgLXJjMSB0bwo+ID4+ID4gICAgICAgIHJl
bWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPiA+PiA+Cj4gPj4gPiBoeXBlcnZpc29yLCBuaWNlIHRv
IGhhdmU6Cj4gPj4gPgo+ID4+ID4gICAgICAqIHNvbGlkIGltcGxlbWVudGF0aW9uIG9mIHNoYXJp
bmcvcGFnaW5nL21lbS1ldmVudHMgKHVzaW5nIHdvcmsKPiA+PiA+ICAgICAgICBxdWV1ZXMpIChU
aW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcgZXQgYWwpCj4gPj4gPiAgICAgICogQSBsb25nIHN0YW5k
aW5nIGlzc3VlIGlzIGEgZnVsbHkgc3luY2hyb25pemVkIHAybSAobG9ja2luZwo+ID4+ID4gICAg
ICAgIGxvb2t1cHMpIChBbmRyZXMgTGFnYXItQ2F2aWxsYSkKPiA+PiA+ICAgICAgKiBOVU1BIGlt
cHJvdmVtZW50OiBkb21haW4gYWZmaW5pdHkgY29uc2lzdGVudCB3aXRoIGNwdXBvb2wKPiA+PiA+
ICAgICAgICBtZW1iZXJzaGlwIChEYXJpbyBGYWdnaW9saSwgSmV1cmdlbiBHcm9zcyAtLSBwYXRj
aCBwb3N0ZWQpCj4gPj4gPgo+ID4+ID4gdG9vbHMsIG5pY2UgdG8gaGF2ZToKPiA+PiA+Cj4gPj4g
PiAgICAgICogSG90cGx1ZyBzY3JpcHQgc3R1ZmYgLS0gaW50ZXJuYWwgdG8gbGlieGwgKEkgdGhp
bmssIHRoZXJlZm9yZSBJCj4gPj4gPiAgICAgICAgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0YWJs
ZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhhdmUKPiA+PiA+ICAgICAgICBmb3IgNC4y
PyBSb2dlciBQYXUgTW9uZXQgd2FzIGxvb2tpbmcgYXQgdGhpcyBidXQgaXRzIGxvb2tpbmcKPiA+
PiA+ICAgICAgICBsaWtlIGEgYmlnIGNhbi1vLXdvcm1zLiAoZGlzY3Vzc2lvbiBvbi1nb2luZykK
PiA+PiA+ICAgICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dzIG9uIGZyb20gaG90
cGx1ZyBzY3JpcHQgKFJvZ2VyCj4gPj4gPiAgICAgICAgUGF1IE1vbmV0KQo+ID4+ID4gICAgICAq
IGxpYnlhamwgdjIgc3VwcG9ydCAocGF0Y2ggcG9zdGVkIGJ5IFJvZ2VyIFBhdSBNb25ldCwgYmxv
Y2tlZCBvbgo+ID4+ID4gICAgICAgIGF1dG9jb25mPykKPiA+PiA+ICAgICAgKiBDb25maWd1cmUv
Y29udHJvbCBwYWdpbmcgdmlhIHhsL2xpYnhsIChPbGFmIEhlcnJpbmcpCj4gPj4gPiAgICAgICog
VXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4gPj4gPiAgICAgICAgICAgICAgKiBVcHN0
cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRob255IFBlcmFyZCkKPiA+PiA+
ICAgICAgICAgICAgICAqIFVwc3RyZWFtIHFlbXUgc2F2ZSByZXN0b3JlIChBbnRob255IFBlcmFy
ZCkKPiA+PiA+ICAgICAgKiBOZXN0ZWQtdmlydHVhbGlzYXRpb24gKGN1cnJlbnRseSBzaG91bGQg
YmUgbWFya2VkCj4gPj4gPiAgICAgICAgZXhwZXJpbWVudGFsLGxpa2VseSB0byByZWxlYXNlIHRo
YXQgd2F5PyBDb25zaWRlciBuZXN0ZWQtc3ZtCj4gPj4gPiAgICAgICAgc2VwYXJhdGUgdG8gbmVz
dGVkLXZteC4gTmVzdGVkLXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCj4gPj4KPiA+Pgo+ID4+IEp1
c3QgYSByYW5kb20gdGhvdWdodCwgYnV0IEkgZmluZCBpdCBxdWl0ZSBhbm5veWluZyB0byBuZWVk
IGxhdGV4IHRvCj4gPj4gY29tcGlsZSB0aGUgZG9jdW1lbnRhdGlvbi4gSSB0aGluayBpdCB3aWxs
IGJlIHdpc2UgdG8gY3JlYXRlIGEgbmV3Cj4gPj4gTWFrZWZpbGUgdGFyZ2V0LCBsaWtlIG1hbi1w
YWdlcyBhbmQgaW5zdGFsbC1tYW4tcGFnZXMgdG8gYWxsb3cgdGhlCj4gPj4gdXNlciB0byBidWls
ZCBhbmQgaW5zdGFsbCBtYW4gcGFnZXMgb25seSAob3IgZG9uJ3QgYWJvcnQgZG9jcyBidWlsZCBp
Zgo+ID4+IGxhdGV4IGlzIG5vdCBmb3VuZCkuIFBlcnNvbmFsbHkgSSBkb24ndCBoYXZlIGxhdGV4
IG9uIG15IHNlcnZlciwgYW5kIEkKPiA+PiBkb24ndCB3YW50IHRvIGluc3RhbGwgaXQsIGJ1dCBJ
IHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgbWFuIHBhZ2VzIHdoZW4KPiA+PiBidWlsZGluZyBYZW4g
ZnJvbSBzb3VyY2UuCj4gPgo+ID4gIm1ha2UgLUMgZG9jcyBtYW4tcGFnZXMiIHdpbGwgZG8gd2hh
dCB5b3Ugd2FudC4KPiAKPiBUaGFua3MsIEkndmUgYWxyZWFkeSBkb25lIHRoaXMgdG8gYnVpbGQg
dGhlbSBvbiBteSBzeXN0ZW0sIGJ1dCBJIHRoaW5rCj4gd2Ugc2hvdWxkIHByb3ZpZGUgc29tZSBl
YXN5IHdheSBmb3IgdXNlcnMgd2l0aG91dCBsYXRleCB0byBidWlsZCBhbmQKPiBpbnN0YWxsIHRo
ZSBtYW4gcGFnZXMuCgpJdCdzIGhhcmQgdG8gZ2V0IG11Y2ggZWFzaWVyLCBidXQuLi4KCj4gPiBJ
IG11c3QgYWRtaXQgSSB0aG91Z2h0IGxhdGV4IHdhcyBvcHRpb25hbCBhbmQgdGhhdCAibWFrZSBk
b2NzIiB3b3VsZAo+ID4gc2ltcGx5IHNraXAgdGhvc2UgZG9jcyBpZiBpdCB3YXNuJ3QgaW5zdGFs
bGVkIC0tIHRoYXQncyB3aGF0IHRoZSAiaWYKPiA+IHdoaWNoICQoVE9PTCkiIGNvbnN0cnVjdCB1
c2VkIGluIHRoZXJlIGlzIChzdXBwb3NlZCB0byBiZSkgZG9pbmcuCj4gCj4gSWYgbGF0ZXggaXMg
bm90IGZvdW5kLCB0aGUgY29tcGlsYXRpb24gaXMgYWJvcnRlZDoKPiAKPiAjIG1ha2UgZG9jcwo+
IHNoIC4vZG9jcy9jaGVja19wa2dzICYmIG1ha2UgLUMgZG9jcyBpbnN0YWxsIHx8IHRydWUKPiA9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+ID0gV0FSTklORzog
UGFja2FnZSAnbGF0ZXgnIGlzIHJlcXVpcmVkCj4gPSAgICAgICAgICB0byBidWlsZCBYZW4gZG9j
dW1lbnRhdGlvbgo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
Cj4gCj4gSSB0aGluayBtYWtlIGRvY3Mgc2hvdWxkIGp1c3Qgc2tpcCBsYXRleCBpZiBub3QgZm91
bmQuCgpMb29rcyBsaWtlIGl0IGlzIHNpbXBseSB0aGUgY2hlY2sgd2hpY2ggaXMgdG9vIHN0cmlj
dC4gQUZBSUNUIHRoZSBhY3R1YWwKZG9jcyBidWlsZCBhbHJlYWR5IHNraXBzIHRob3NlIGRvY3Mg
aWYgeW91IGRvbid0IGhhdmUgTGF0ZXguIFlvdSBjYW4KdGVzdCB0aGlzIHdpdGggIm1ha2UgLUMg
ZG9jcyIgd2hpY2ggaXMgYmFzaWNhbGx5IHRoZSBzYW1lIGFzICJtYWtlIGRvY3MiCmJ1dCB3aXRo
b3V0IHRoZSBjaGVja3MuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 25 14:59:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 14:59:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4Jd-0005GC-Mt; Wed, 25 Jan 2012 14:59: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 1Rq4Jc-0005Fm-UE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 14:59:13 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327503546!12500422!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10294 invoked from network); 25 Jan 2012 14:59:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 14:59:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10284332"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 14:59: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, 25 Jan 2012 14:59:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 25 Jan 2012 14:59:06 +0000
In-Reply-To: <CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
	<1327502464.24561.325.camel@zakaz.uk.xensource.com>
	<CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327503546.24561.331.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDE0OjQ5ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8yNSBJYW4gQ2FtcGJlbGwgPElhbi5DYW1wYmVsbEBjaXRyaXguY29tPjoKPiA+
IE9uIFdlZCwgMjAxMi0wMS0yNSBhdCAxNDozMyArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90
ZToKPiA+PiAyMDEyLzEvMjMgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0cml4LmNvbT46
Cj4gPj4gPiBOZXdseSB1cGRhdGVkIGxpc3QgZm9sbG93cy4gUGxlYXNlIHNlbmQgbWUgY29ycmVj
dGlvbnMgKGVzcGVjaWFsbHkKPiA+PiA+ICJkb25lIikuIEkndmUgc3RvcHBlZCBDQ2luZyBldmVy
eW9uZSwgc2luY2UgSSBndWVzcyBpdCBpcyBtb3N0bHkgc3BhbSB0bwo+ID4+ID4gdGhlIG1ham9y
aXR5Lgo+ID4+ID4KPiA+PiA+IGh5cGVydmlzb3IsIGJsb2NrZXJzOgo+ID4+ID4KPiA+PiA+ICAg
ICAgKiByb3VuZC11cCBvZiB0aGUgY2xvc2luZyBvZiB0aGUgc2VjdXJpdHkgaG9sZSBpbiBNU0kt
WAo+ID4+ID4gICAgICAgIHBhc3N0aHJvdWdoICh1bmlmb3JtbHkgLSBpLmUuIGV2ZW4gZm9yIERv
bTAgLSBkaXNhbGxvd2luZyB3cml0ZQo+ID4+ID4gICAgICAgIGFjY2VzcyB0byBNU0ktWCB0YWJs
ZSBwYWdlcykuIChKYW4gQmV1bGljaCAtLSBtb3JlIGZpeGVzCj4gPj4gPiAgICAgICAgcmVxdWly
ZWQgdGhhbiBmaXJzdCB0aG91Z2h0LCBwYXRjaGVzIHBvc3RlZCkKPiA+PiA+ICAgICAgKiBkb21j
dGxzIC8gc3lzY3RscyBzZXQgdXAgdG8gbW9kaWZ5IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBsaWtl
Cj4gPj4gPiAgICAgICAgdGhlIGNyZWRpdDEgdGltZXNsaWNlIGFuZCBzY2hlZHVsZSByYXRlLiAo
R2VvcmdlIER1bmxhcCkKPiA+PiA+ICAgICAgKiBnZXQgdGhlIGludGVyZmFjZSBjaGFuZ2VzIGZv
ciBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzIGRvbmUgYW5kCj4gPj4gPiAgICAgICAgZHVzdGVk
IHNvIHRoYXQgNC4yIGlzIGEgc3RhYmxlIEFQSSB0aGF0IHdlIGhvbGQgdG8uIChUaW0gRGVlZ2Fu
LAo+ID4+ID4gICAgICAgIEFuZHJlcyBMYWdhci1DYXZpbGxhIGV0IGFsKQo+ID4+ID4gICAgICAg
ICAgICAgICogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNlZW1zIGNsb3NlIHRv
IGdvaW5nCj4gPj4gPiAgICAgICAgICAgICAgICBpbi4KPiA+PiA+ICAgICAgICAgICAgICAqIHNo
YXJpbmcgcGF0Y2hlcyBwb3N0ZWQKPiA+PiA+Cj4gPj4gPiB0b29scywgYmxvY2tlcnM6Cj4gPj4g
Pgo+ID4+ID4gICAgICAqIGxpYnhsIHN0YWJsZSBBUEkgLS0gd2Ugd291bGQgbGlrZSA0LjIgdG8g
ZGVmaW5lIGEgc3RhYmxlIEFQSQo+ID4+ID4gICAgICAgIHdoaWNoIGRvd25zdHJlYW0ncyBjYW4g
c3RhcnQgdG8gcmVseSBvbiBub3QgY2hhbmdpbmcuIEFzcGVjdHMgb2YKPiA+PiA+ICAgICAgICB0
aGlzIGFyZToKPiA+PiA+ICAgICAgICAgICAgICAqIGV2ZW50IGhhbmRsaW5nIChJYW4gSmFja3Nv
biwgcG9zdGVkIHNldmVyYWwgcm91bmRzLAo+ID4+ID4gICAgICAgICAgICAgICAgbmVhcmluZyBj
b21wbGV0aW9uPykKPiA+PiA+ICAgICAgICAgICAgICAqIGRyb3AgbGlieGxfZGV2aWNlX21vZGVs
X2luZm8gKG1vdmUgYml0cyB0byBidWlsZF9pbmZvIG9yCj4gPj4gPiAgICAgICAgICAgICAgICBl
bHNld2hlcmUgYXMgYXBwcm9wcmlhdGUpIChJYW4gQ2FtcGJlbGwsIGZpcnN0IFJGQyBzZW50KQo+
ID4+ID4gICAgICAgICAgICAgICogYWRkIGxpYnhsX2RlZmJvb2wgYW5kIGdlbmVyYWxseSB0cnkg
YW5kIGFycmFuZ2UgdGhhdAo+ID4+ID4gICAgICAgICAgICAgICAgbWVtc2V0KGZvbywwLC4uLikg
cmVxdWVzdHMgdGhlIGRlZmF1bHRzIChJYW4gQ2FtcGJlbGwsCj4gPj4gPiAgICAgICAgICAgICAg
ICBmaXJzdCBSRkMgc2VudCkKPiA+PiA+ICAgICAgICAgICAgICAqIHRvcG9sb2d5aW5mbyBkYXRh
c3RydWN0dXJlIHNob3VsZCBiZSBhIGxpc3Qgb2YgdHVwbGVzLAo+ID4+ID4gICAgICAgICAgICAg
ICAgbm90IGEgdHVwbGUgb2YgbGlzdHMuIChub2JvZHkgY3VycmVudGx5IGxvb2tpbmcgYXQgdGhp
cywKPiA+PiA+ICAgICAgICAgICAgICAgIG5vdCAxMDAlIHN1cmUgdGhpcyBtYWtlcyBzZW5zZSwg
Y291bGQgcG9zc2libHkgZGVmZXIgYW5kCj4gPj4gPiAgICAgICAgICAgICAgICBjaGFuZ2UgYWZ0
ZXIgNC4yIGluIGEgY29tcGF0aWJsZSB3YXkpCj4gPj4gPiAgICAgICogeGwgdG8gdXNlIGpzb24g
Zm9yIG1hY2hpbmUgcmVhZGFibGUgb3V0cHV0IGluc3RlYWQgb2Ygc2V4cCBieQo+ID4+ID4gICAg
ICAgIGRlZmF1bHQgKElhbiBDYW1wYmVsbCB0byByZXZpc2l0IGV4aXN0aW5nIHBhdGNoKQo+ID4+
ID4gICAgICAqIHhsIHN1cHBvcnQgZm9yIHZjcHUgcGlubmluZyAoRGFyaW8gRmFnZ2lvbGkpCj4g
Pj4gPiAgICAgICogeGwgZmVhdHVyZSBwYXJpdHkgd2l0aCB4ZW5kIHdydCBkcml2ZXIgZG9tYWlu
IHN1cHBvcnQgKEdlb3JnZQo+ID4+ID4gICAgICAgIER1bmxhcCkKPiA+PiA+ICAgICAgKiBJbnRl
Z3JhdGUgcWVtdStzZWFiaW9zIHVwc3RyZWFtIGludG8gdGhlIGJ1aWxkIChwYXRjaGVzCj4gPj4g
PiAgICAgICAgcmVwb3N0ZWQsIHBlbmRpbmcpLiBObyBjaGFuZ2UgaW4gZGVmYXVsdCBxZW11IGZv
ciA0LjIuCj4gPj4gPiAgICAgICogTW9yZSBmb3JtYWxseSBkZXByZWNhdGUgeG0veGVuZC4gTWFu
cGFnZSBwYXRjaGVzIGFscmVhZHkgaW4KPiA+PiA+ICAgICAgICB0cmVlLiBOZWVkcyByZWxlYXNl
IG5vdGluZyBhbmQgY29tbXVuaWNhdGlvbiBhcm91bmQgLXJjMSB0bwo+ID4+ID4gICAgICAgIHJl
bWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPiA+PiA+Cj4gPj4gPiBoeXBlcnZpc29yLCBuaWNlIHRv
IGhhdmU6Cj4gPj4gPgo+ID4+ID4gICAgICAqIHNvbGlkIGltcGxlbWVudGF0aW9uIG9mIHNoYXJp
bmcvcGFnaW5nL21lbS1ldmVudHMgKHVzaW5nIHdvcmsKPiA+PiA+ICAgICAgICBxdWV1ZXMpIChU
aW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcgZXQgYWwpCj4gPj4gPiAgICAgICogQSBsb25nIHN0YW5k
aW5nIGlzc3VlIGlzIGEgZnVsbHkgc3luY2hyb25pemVkIHAybSAobG9ja2luZwo+ID4+ID4gICAg
ICAgIGxvb2t1cHMpIChBbmRyZXMgTGFnYXItQ2F2aWxsYSkKPiA+PiA+ICAgICAgKiBOVU1BIGlt
cHJvdmVtZW50OiBkb21haW4gYWZmaW5pdHkgY29uc2lzdGVudCB3aXRoIGNwdXBvb2wKPiA+PiA+
ICAgICAgICBtZW1iZXJzaGlwIChEYXJpbyBGYWdnaW9saSwgSmV1cmdlbiBHcm9zcyAtLSBwYXRj
aCBwb3N0ZWQpCj4gPj4gPgo+ID4+ID4gdG9vbHMsIG5pY2UgdG8gaGF2ZToKPiA+PiA+Cj4gPj4g
PiAgICAgICogSG90cGx1ZyBzY3JpcHQgc3R1ZmYgLS0gaW50ZXJuYWwgdG8gbGlieGwgKEkgdGhp
bmssIHRoZXJlZm9yZSBJCj4gPj4gPiAgICAgICAgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0YWJs
ZSBBUEkgYWJvdmUpIGJ1dCBzdGlsbCBnb29kIHRvIGhhdmUKPiA+PiA+ICAgICAgICBmb3IgNC4y
PyBSb2dlciBQYXUgTW9uZXQgd2FzIGxvb2tpbmcgYXQgdGhpcyBidXQgaXRzIGxvb2tpbmcKPiA+
PiA+ICAgICAgICBsaWtlIGEgYmlnIGNhbi1vLXdvcm1zLiAoZGlzY3Vzc2lvbiBvbi1nb2luZykK
PiA+PiA+ICAgICAgKiBCbG9jayBzY3JpcHQgc3VwcG9ydCAtLSBmb2xsb3dzIG9uIGZyb20gaG90
cGx1ZyBzY3JpcHQgKFJvZ2VyCj4gPj4gPiAgICAgICAgUGF1IE1vbmV0KQo+ID4+ID4gICAgICAq
IGxpYnlhamwgdjIgc3VwcG9ydCAocGF0Y2ggcG9zdGVkIGJ5IFJvZ2VyIFBhdSBNb25ldCwgYmxv
Y2tlZCBvbgo+ID4+ID4gICAgICAgIGF1dG9jb25mPykKPiA+PiA+ICAgICAgKiBDb25maWd1cmUv
Y29udHJvbCBwYWdpbmcgdmlhIHhsL2xpYnhsIChPbGFmIEhlcnJpbmcpCj4gPj4gPiAgICAgICog
VXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4gPj4gPiAgICAgICAgICAgICAgKiBVcHN0
cmVhbSBxZW11IFBDSSBwYXNzdGhyb3VnaCBzdXBwb3J0IChBbnRob255IFBlcmFyZCkKPiA+PiA+
ICAgICAgICAgICAgICAqIFVwc3RyZWFtIHFlbXUgc2F2ZSByZXN0b3JlIChBbnRob255IFBlcmFy
ZCkKPiA+PiA+ICAgICAgKiBOZXN0ZWQtdmlydHVhbGlzYXRpb24gKGN1cnJlbnRseSBzaG91bGQg
YmUgbWFya2VkCj4gPj4gPiAgICAgICAgZXhwZXJpbWVudGFsLGxpa2VseSB0byByZWxlYXNlIHRo
YXQgd2F5PyBDb25zaWRlciBuZXN0ZWQtc3ZtCj4gPj4gPiAgICAgICAgc2VwYXJhdGUgdG8gbmVz
dGVkLXZteC4gTmVzdGVkLXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCj4gPj4KPiA+Pgo+ID4+IEp1
c3QgYSByYW5kb20gdGhvdWdodCwgYnV0IEkgZmluZCBpdCBxdWl0ZSBhbm5veWluZyB0byBuZWVk
IGxhdGV4IHRvCj4gPj4gY29tcGlsZSB0aGUgZG9jdW1lbnRhdGlvbi4gSSB0aGluayBpdCB3aWxs
IGJlIHdpc2UgdG8gY3JlYXRlIGEgbmV3Cj4gPj4gTWFrZWZpbGUgdGFyZ2V0LCBsaWtlIG1hbi1w
YWdlcyBhbmQgaW5zdGFsbC1tYW4tcGFnZXMgdG8gYWxsb3cgdGhlCj4gPj4gdXNlciB0byBidWls
ZCBhbmQgaW5zdGFsbCBtYW4gcGFnZXMgb25seSAob3IgZG9uJ3QgYWJvcnQgZG9jcyBidWlsZCBp
Zgo+ID4+IGxhdGV4IGlzIG5vdCBmb3VuZCkuIFBlcnNvbmFsbHkgSSBkb24ndCBoYXZlIGxhdGV4
IG9uIG15IHNlcnZlciwgYW5kIEkKPiA+PiBkb24ndCB3YW50IHRvIGluc3RhbGwgaXQsIGJ1dCBJ
IHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGUgbWFuIHBhZ2VzIHdoZW4KPiA+PiBidWlsZGluZyBYZW4g
ZnJvbSBzb3VyY2UuCj4gPgo+ID4gIm1ha2UgLUMgZG9jcyBtYW4tcGFnZXMiIHdpbGwgZG8gd2hh
dCB5b3Ugd2FudC4KPiAKPiBUaGFua3MsIEkndmUgYWxyZWFkeSBkb25lIHRoaXMgdG8gYnVpbGQg
dGhlbSBvbiBteSBzeXN0ZW0sIGJ1dCBJIHRoaW5rCj4gd2Ugc2hvdWxkIHByb3ZpZGUgc29tZSBl
YXN5IHdheSBmb3IgdXNlcnMgd2l0aG91dCBsYXRleCB0byBidWlsZCBhbmQKPiBpbnN0YWxsIHRo
ZSBtYW4gcGFnZXMuCgpJdCdzIGhhcmQgdG8gZ2V0IG11Y2ggZWFzaWVyLCBidXQuLi4KCj4gPiBJ
IG11c3QgYWRtaXQgSSB0aG91Z2h0IGxhdGV4IHdhcyBvcHRpb25hbCBhbmQgdGhhdCAibWFrZSBk
b2NzIiB3b3VsZAo+ID4gc2ltcGx5IHNraXAgdGhvc2UgZG9jcyBpZiBpdCB3YXNuJ3QgaW5zdGFs
bGVkIC0tIHRoYXQncyB3aGF0IHRoZSAiaWYKPiA+IHdoaWNoICQoVE9PTCkiIGNvbnN0cnVjdCB1
c2VkIGluIHRoZXJlIGlzIChzdXBwb3NlZCB0byBiZSkgZG9pbmcuCj4gCj4gSWYgbGF0ZXggaXMg
bm90IGZvdW5kLCB0aGUgY29tcGlsYXRpb24gaXMgYWJvcnRlZDoKPiAKPiAjIG1ha2UgZG9jcwo+
IHNoIC4vZG9jcy9jaGVja19wa2dzICYmIG1ha2UgLUMgZG9jcyBpbnN0YWxsIHx8IHRydWUKPiA9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4gPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+ID0gV0FSTklORzog
UGFja2FnZSAnbGF0ZXgnIGlzIHJlcXVpcmVkCj4gPSAgICAgICAgICB0byBidWlsZCBYZW4gZG9j
dW1lbnRhdGlvbgo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
Cj4gCj4gSSB0aGluayBtYWtlIGRvY3Mgc2hvdWxkIGp1c3Qgc2tpcCBsYXRleCBpZiBub3QgZm91
bmQuCgpMb29rcyBsaWtlIGl0IGlzIHNpbXBseSB0aGUgY2hlY2sgd2hpY2ggaXMgdG9vIHN0cmlj
dC4gQUZBSUNUIHRoZSBhY3R1YWwKZG9jcyBidWlsZCBhbHJlYWR5IHNraXBzIHRob3NlIGRvY3Mg
aWYgeW91IGRvbid0IGhhdmUgTGF0ZXguIFlvdSBjYW4KdGVzdCB0aGlzIHdpdGggIm1ha2UgLUMg
ZG9jcyIgd2hpY2ggaXMgYmFzaWNhbGx5IHRoZSBzYW1lIGFzICJtYWtlIGRvY3MiCmJ1dCB3aXRo
b3V0IHRoZSBjaGVja3MuCgpJYW4uCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:04:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15: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 1Rq4O9-0005eN-Ea; Wed, 25 Jan 2012 15:03:53 +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 1Rq4O8-0005e7-CA
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:03:52 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327503824!12523731!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9079 invoked from network); 25 Jan 2012 15:03:45 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:03:45 -0000
Received: by pbdx13 with SMTP id x13so14777554pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 07:03: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=9U+XgVwiIgIXCdoEgzCbjJlnxAvkimYLY0yzs4hvXro=;
	b=QNj/h607fdWYRyUNEUFTDu6pYaE/ganOs5UeNIC0W+kp7/dnj5BEmzQF3nFQf5IUT6
	UZIYdYk9r+YjMdgZuuTsjMV/TtDpbHeaxdthbZhShZmZJVAXtOZkkgt32bC+TEaibAcG
	+2CwfS1VVmX+nNPE9OOvtfZbKkkZB5NAjj3zE=
MIME-Version: 1.0
Received: by 10.68.74.132 with SMTP id t4mr41347408pbv.22.1327503823700; Wed,
	25 Jan 2012 07:03:43 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Wed, 25 Jan 2012 07:03:43 -0800 (PST)
In-Reply-To: <1327503546.24561.331.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
	<1327502464.24561.325.camel@zakaz.uk.xensource.com>
	<CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
	<1327503546.24561.331.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 16:03:43 +0100
X-Google-Sender-Auth: 0laV-nqqU9eYurywxoHeVUYmecU
Message-ID: <CAPLaKK4brH4yW9=RuoBsaBzHKiTchepmMnW9uZpX185MaAoSPA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI1IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMS0yNSBhdCAxNDo0OSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzI1IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IFdlZCwgMjAxMi0wMS0yNSBhdCAxNDozMyArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToK
Pj4gPj4gMjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+
PiA+PiA+IE5ld2x5IHVwZGF0ZWQgbGlzdCBmb2xsb3dzLiBQbGVhc2Ugc2VuZCBtZSBjb3JyZWN0
aW9ucyAoZXNwZWNpYWxseQo+PiA+PiA+ICJkb25lIikuIEkndmUgc3RvcHBlZCBDQ2luZyBldmVy
eW9uZSwgc2luY2UgSSBndWVzcyBpdCBpcyBtb3N0bHkgc3BhbSB0bwo+PiA+PiA+IHRoZSBtYWpv
cml0eS4KPj4gPj4gPgo+PiA+PiA+IGh5cGVydmlzb3IsIGJsb2NrZXJzOgo+PiA+PiA+Cj4+ID4+
ID4gwqAgwqAgwqAqIHJvdW5kLXVwIG9mIHRoZSBjbG9zaW5nIG9mIHRoZSBzZWN1cml0eSBob2xl
IGluIE1TSS1YCj4+ID4+ID4gwqAgwqAgwqAgwqBwYXNzdGhyb3VnaCAodW5pZm9ybWx5IC0gaS5l
LiBldmVuIGZvciBEb20wIC0gZGlzYWxsb3dpbmcgd3JpdGUKPj4gPj4gPiDCoCDCoCDCoCDCoGFj
Y2VzcyB0byBNU0ktWCB0YWJsZSBwYWdlcykuIChKYW4gQmV1bGljaCAtLSBtb3JlIGZpeGVzCj4+
ID4+ID4gwqAgwqAgwqAgwqByZXF1aXJlZCB0aGFuIGZpcnN0IHRob3VnaHQsIHBhdGNoZXMgcG9z
dGVkKQo+PiA+PiA+IMKgIMKgIMKgKiBkb21jdGxzIC8gc3lzY3RscyBzZXQgdXAgdG8gbW9kaWZ5
IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBsaWtlCj4+ID4+ID4gwqAgwqAgwqAgwqB0aGUgY3JlZGl0
MSB0aW1lc2xpY2UgYW5kIHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwKQo+PiA+PiA+IMKg
IMKgIMKgKiBnZXQgdGhlIGludGVyZmFjZSBjaGFuZ2VzIGZvciBzaGFyaW5nL3BhZ2luZy9tZW0t
ZXZlbnRzIGRvbmUgYW5kCj4+ID4+ID4gwqAgwqAgwqAgwqBkdXN0ZWQgc28gdGhhdCA0LjIgaXMg
YSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4gKFRpbSBEZWVnYW4sCj4+ID4+ID4gwqAgwqAg
wqAgwqBBbmRyZXMgTGFnYXItQ2F2aWxsYSBldCBhbCkKPj4gPj4gPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNlZW1zIGNsb3NlIHRvIGdv
aW5nCj4+ID4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbi4KPj4gPj4gPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogc2hhcmluZyBwYXRjaGVzIHBvc3RlZAo+PiA+PiA+Cj4+ID4+ID4gdG9vbHMs
IGJsb2NrZXJzOgo+PiA+PiA+Cj4+ID4+ID4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkgLS0g
d2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+PiA+PiA+IMKgIMKgIMKg
IMKgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4g
QXNwZWN0cyBvZgo+PiA+PiA+IMKgIMKgIMKgIMKgdGhpcyBhcmU6Cj4+ID4+ID4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAqIGV2ZW50IGhhbmRsaW5nIChJYW4gSmFja3NvbiwgcG9zdGVkIHNldmVyYWwg
cm91bmRzLAo+PiA+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbmVhcmluZyBjb21wbGV0aW9u
PykKPj4gPj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogZHJvcCBsaWJ4bF9kZXZpY2VfbW9kZWxf
aW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2luZm8gb3IKPj4gPj4gPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkgKElhbiBDYW1wYmVsbCwgZmlyc3QgUkZD
IHNlbnQpCj4+ID4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGFkZCBsaWJ4bF9kZWZib29sIGFu
ZCBnZW5lcmFsbHkgdHJ5IGFuZCBhcnJhbmdlIHRoYXQKPj4gPj4gPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoG1lbXNldChmb28sMCwuLi4pIHJlcXVlc3RzIHRoZSBkZWZhdWx0cyAoSWFuIENhbXBi
ZWxsLAo+PiA+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmlyc3QgUkZDIHNlbnQpCj4+ID4+
ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIHRvcG9sb2d5aW5mbyBkYXRhc3RydWN0dXJlIHNob3Vs
ZCBiZSBhIGxpc3Qgb2YgdHVwbGVzLAo+PiA+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbm90
IGEgdHVwbGUgb2YgbGlzdHMuIChub2JvZHkgY3VycmVudGx5IGxvb2tpbmcgYXQgdGhpcywKPj4g
Pj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5vdCAxMDAlIHN1cmUgdGhpcyBtYWtlcyBzZW5z
ZSwgY291bGQgcG9zc2libHkgZGVmZXIgYW5kCj4+ID4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqBjaGFuZ2UgYWZ0ZXIgNC4yIGluIGEgY29tcGF0aWJsZSB3YXkpCj4+ID4+ID4gwqAgwqAgwqAq
IHhsIHRvIHVzZSBqc29uIGZvciBtYWNoaW5lIHJlYWRhYmxlIG91dHB1dCBpbnN0ZWFkIG9mIHNl
eHAgYnkKPj4gPj4gPiDCoCDCoCDCoCDCoGRlZmF1bHQgKElhbiBDYW1wYmVsbCB0byByZXZpc2l0
IGV4aXN0aW5nIHBhdGNoKQo+PiA+PiA+IMKgIMKgIMKgKiB4bCBzdXBwb3J0IGZvciB2Y3B1IHBp
bm5pbmcgKERhcmlvIEZhZ2dpb2xpKQo+PiA+PiA+IMKgIMKgIMKgKiB4bCBmZWF0dXJlIHBhcml0
eSB3aXRoIHhlbmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9ydCAoR2VvcmdlCj4+ID4+ID4gwqAg
wqAgwqAgwqBEdW5sYXApCj4+ID4+ID4gwqAgwqAgwqAqIEludGVncmF0ZSBxZW11K3NlYWJpb3Mg
dXBzdHJlYW0gaW50byB0aGUgYnVpbGQgKHBhdGNoZXMKPj4gPj4gPiDCoCDCoCDCoCDCoHJlcG9z
dGVkLCBwZW5kaW5nKS4gTm8gY2hhbmdlIGluIGRlZmF1bHQgcWVtdSBmb3IgNC4yLgo+PiA+PiA+
IMKgIMKgIMKgKiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNo
ZXMgYWxyZWFkeSBpbgo+PiA+PiA+IMKgIMKgIMKgIMKgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3Rp
bmcgYW5kIGNvbW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPj4gPj4gPiDCoCDCoCDCoCDCoHJl
bWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPj4gPj4gPgo+PiA+PiA+IGh5cGVydmlzb3IsIG5pY2Ug
dG8gaGF2ZToKPj4gPj4gPgo+PiA+PiA+IMKgIMKgIMKgKiBzb2xpZCBpbXBsZW1lbnRhdGlvbiBv
ZiBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzICh1c2luZyB3b3JrCj4+ID4+ID4gwqAgwqAgwqAg
wqBxdWV1ZXMpIChUaW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcgZXQgYWwpCj4+ID4+ID4gwqAgwqAg
wqAqIEEgbG9uZyBzdGFuZGluZyBpc3N1ZSBpcyBhIGZ1bGx5IHN5bmNocm9uaXplZCBwMm0gKGxv
Y2tpbmcKPj4gPj4gPiDCoCDCoCDCoCDCoGxvb2t1cHMpIChBbmRyZXMgTGFnYXItQ2F2aWxsYSkK
Pj4gPj4gPiDCoCDCoCDCoCogTlVNQSBpbXByb3ZlbWVudDogZG9tYWluIGFmZmluaXR5IGNvbnNp
c3RlbnQgd2l0aCBjcHVwb29sCj4+ID4+ID4gwqAgwqAgwqAgwqBtZW1iZXJzaGlwIChEYXJpbyBG
YWdnaW9saSwgSmV1cmdlbiBHcm9zcyAtLSBwYXRjaCBwb3N0ZWQpCj4+ID4+ID4KPj4gPj4gPiB0
b29scywgbmljZSB0byBoYXZlOgo+PiA+PiA+Cj4+ID4+ID4gwqAgwqAgwqAqIEhvdHBsdWcgc2Ny
aXB0IHN0dWZmIC0tIGludGVybmFsIHRvIGxpYnhsIChJIHRoaW5rLCB0aGVyZWZvcmUgSQo+PiA+
PiA+IMKgIMKgIMKgIMKgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0YWJsZSBBUEkgYWJvdmUpIGJ1
dCBzdGlsbCBnb29kIHRvIGhhdmUKPj4gPj4gPiDCoCDCoCDCoCDCoGZvciA0LjI/IFJvZ2VyIFBh
dSBNb25ldCB3YXMgbG9va2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9va2luZwo+PiA+PiA+IMKgIMKg
IMKgIMKgbGlrZSBhIGJpZyBjYW4tby13b3Jtcy4gKGRpc2N1c3Npb24gb24tZ29pbmcpCj4+ID4+
ID4gwqAgwqAgwqAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3Rw
bHVnIHNjcmlwdCAoUm9nZXIKPj4gPj4gPiDCoCDCoCDCoCDCoFBhdSBNb25ldCkKPj4gPj4gPiDC
oCDCoCDCoCogbGlieWFqbCB2MiBzdXBwb3J0IChwYXRjaCBwb3N0ZWQgYnkgUm9nZXIgUGF1IE1v
bmV0LCBibG9ja2VkIG9uCj4+ID4+ID4gwqAgwqAgwqAgwqBhdXRvY29uZj8pCj4+ID4+ID4gwqAg
wqAgwqAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVycmlu
ZykKPj4gPj4gPiDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4+ID4+
ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1
cHBvcnQgKEFudGhvbnkgUGVyYXJkKQo+PiA+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBVcHN0
cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQpCj4+ID4+ID4gwqAgwqAgwqAq
IE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3VycmVudGx5IHNob3VsZCBiZSBtYXJrZWQKPj4gPj4g
PiDCoCDCoCDCoCDCoGV4cGVyaW1lbnRhbCxsaWtlbHkgdG8gcmVsZWFzZSB0aGF0IHdheT8gQ29u
c2lkZXIgbmVzdGVkLXN2bQo+PiA+PiA+IMKgIMKgIMKgIMKgc2VwYXJhdGUgdG8gbmVzdGVkLXZt
eC4gTmVzdGVkLXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCj4+ID4+Cj4+ID4+Cj4+ID4+IEp1c3Qg
YSByYW5kb20gdGhvdWdodCwgYnV0IEkgZmluZCBpdCBxdWl0ZSBhbm5veWluZyB0byBuZWVkIGxh
dGV4IHRvCj4+ID4+IGNvbXBpbGUgdGhlIGRvY3VtZW50YXRpb24uIEkgdGhpbmsgaXQgd2lsbCBi
ZSB3aXNlIHRvIGNyZWF0ZSBhIG5ldwo+PiA+PiBNYWtlZmlsZSB0YXJnZXQsIGxpa2UgbWFuLXBh
Z2VzIGFuZCBpbnN0YWxsLW1hbi1wYWdlcyB0byBhbGxvdyB0aGUKPj4gPj4gdXNlciB0byBidWls
ZCBhbmQgaW5zdGFsbCBtYW4gcGFnZXMgb25seSAob3IgZG9uJ3QgYWJvcnQgZG9jcyBidWlsZCBp
Zgo+PiA+PiBsYXRleCBpcyBub3QgZm91bmQpLiBQZXJzb25hbGx5IEkgZG9uJ3QgaGF2ZSBsYXRl
eCBvbiBteSBzZXJ2ZXIsIGFuZCBJCj4+ID4+IGRvbid0IHdhbnQgdG8gaW5zdGFsbCBpdCwgYnV0
IEkgd291bGQgbGlrZSB0byBoYXZlIHRoZSBtYW4gcGFnZXMgd2hlbgo+PiA+PiBidWlsZGluZyBY
ZW4gZnJvbSBzb3VyY2UuCj4+ID4KPj4gPiAibWFrZSAtQyBkb2NzIG1hbi1wYWdlcyIgd2lsbCBk
byB3aGF0IHlvdSB3YW50Lgo+Pgo+PiBUaGFua3MsIEkndmUgYWxyZWFkeSBkb25lIHRoaXMgdG8g
YnVpbGQgdGhlbSBvbiBteSBzeXN0ZW0sIGJ1dCBJIHRoaW5rCj4+IHdlIHNob3VsZCBwcm92aWRl
IHNvbWUgZWFzeSB3YXkgZm9yIHVzZXJzIHdpdGhvdXQgbGF0ZXggdG8gYnVpbGQgYW5kCj4+IGlu
c3RhbGwgdGhlIG1hbiBwYWdlcy4KPgo+IEl0J3MgaGFyZCB0byBnZXQgbXVjaCBlYXNpZXIsIGJ1
dC4uLgo+Cj4+ID4gSSBtdXN0IGFkbWl0IEkgdGhvdWdodCBsYXRleCB3YXMgb3B0aW9uYWwgYW5k
IHRoYXQgIm1ha2UgZG9jcyIgd291bGQKPj4gPiBzaW1wbHkgc2tpcCB0aG9zZSBkb2NzIGlmIGl0
IHdhc24ndCBpbnN0YWxsZWQgLS0gdGhhdCdzIHdoYXQgdGhlICJpZgo+PiA+IHdoaWNoICQoVE9P
TCkiIGNvbnN0cnVjdCB1c2VkIGluIHRoZXJlIGlzIChzdXBwb3NlZCB0byBiZSkgZG9pbmcuCj4+
Cj4+IElmIGxhdGV4IGlzIG5vdCBmb3VuZCwgdGhlIGNvbXBpbGF0aW9uIGlzIGFib3J0ZWQ6Cj4+
Cj4+ICMgbWFrZSBkb2NzCj4+IHNoIC4vZG9jcy9jaGVja19wa2dzICYmIG1ha2UgLUMgZG9jcyBp
bnN0YWxsIHx8IHRydWUKPj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQo+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09Cj4+ID0gV0FSTklORzogUGFja2FnZSAnbGF0ZXgnIGlzIHJlcXVpcmVkCj4+ID0gwqAg
wqAgwqAgwqAgwqB0byBidWlsZCBYZW4gZG9jdW1lbnRhdGlvbgo+PiA9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4+ID09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPj4KPj4gSSB0aGluayBtYWtlIGRvY3Mgc2hv
dWxkIGp1c3Qgc2tpcCBsYXRleCBpZiBub3QgZm91bmQuCj4KPiBMb29rcyBsaWtlIGl0IGlzIHNp
bXBseSB0aGUgY2hlY2sgd2hpY2ggaXMgdG9vIHN0cmljdC4gQUZBSUNUIHRoZSBhY3R1YWwKPiBk
b2NzIGJ1aWxkIGFscmVhZHkgc2tpcHMgdGhvc2UgZG9jcyBpZiB5b3UgZG9uJ3QgaGF2ZSBMYXRl
eC4gWW91IGNhbgo+IHRlc3QgdGhpcyB3aXRoICJtYWtlIC1DIGRvY3MiIHdoaWNoIGlzIGJhc2lj
YWxseSB0aGUgc2FtZSBhcyAibWFrZSBkb2NzIgo+IGJ1dCB3aXRob3V0IHRoZSBjaGVja3MuCgpJ
J20gbm90IHJlYWxseSBzdXJlIGxhdGV4IGlzIHNraXBwZWQgaWYgbm90IGZvdW5kOgoKIyBtYWtl
IC1DIGRvY3MKbWFrZTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4td29yay9kb2NzJwps
YXRleCBzcmMvdXNlci50ZXggPi9kZXYvbnVsbAovYmluL3NoOiBsYXRleDogbm90IGZvdW5kCm1h
a2U6ICoqKiBbdXNlci5kdmldIEVycm9yIDEyNwptYWtlOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jv
b3QveGVuLXdvcmsvZG9jcycKCkVpdGhlciB3ZSByZW1vdmUgdGhlIGxhdGV4IGRvY3Mgb3Igd2Ug
YWRkIHNvbWUgY2hlY2tzIHRvIHNraXAgdGhlCnNlY3Rpb25zIHRoYXQgcmVxdWlyZSBsYXRleC4K
Cj4KPiBJYW4uCj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:04:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15: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 1Rq4O9-0005eN-Ea; Wed, 25 Jan 2012 15:03:53 +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 1Rq4O8-0005e7-CA
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:03:52 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327503824!12523731!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9079 invoked from network); 25 Jan 2012 15:03:45 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:03:45 -0000
Received: by pbdx13 with SMTP id x13so14777554pbd.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 07:03: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=9U+XgVwiIgIXCdoEgzCbjJlnxAvkimYLY0yzs4hvXro=;
	b=QNj/h607fdWYRyUNEUFTDu6pYaE/ganOs5UeNIC0W+kp7/dnj5BEmzQF3nFQf5IUT6
	UZIYdYk9r+YjMdgZuuTsjMV/TtDpbHeaxdthbZhShZmZJVAXtOZkkgt32bC+TEaibAcG
	+2CwfS1VVmX+nNPE9OOvtfZbKkkZB5NAjj3zE=
MIME-Version: 1.0
Received: by 10.68.74.132 with SMTP id t4mr41347408pbv.22.1327503823700; Wed,
	25 Jan 2012 07:03:43 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Wed, 25 Jan 2012 07:03:43 -0800 (PST)
In-Reply-To: <1327503546.24561.331.camel@zakaz.uk.xensource.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
	<1327502464.24561.325.camel@zakaz.uk.xensource.com>
	<CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
	<1327503546.24561.331.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 16:03:43 +0100
X-Google-Sender-Auth: 0laV-nqqU9eYurywxoHeVUYmecU
Message-ID: <CAPLaKK4brH4yW9=RuoBsaBzHKiTchepmMnW9uZpX185MaAoSPA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI1IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+IE9uIFdl
ZCwgMjAxMi0wMS0yNSBhdCAxNDo0OSArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToKPj4g
MjAxMi8xLzI1IElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+PiA+IE9u
IFdlZCwgMjAxMi0wMS0yNSBhdCAxNDozMyArMDAwMCwgUm9nZXIgUGF1IE1vbm7DqSB3cm90ZToK
Pj4gPj4gMjAxMi8xLzIzIElhbiBDYW1wYmVsbCA8SWFuLkNhbXBiZWxsQGNpdHJpeC5jb20+Ogo+
PiA+PiA+IE5ld2x5IHVwZGF0ZWQgbGlzdCBmb2xsb3dzLiBQbGVhc2Ugc2VuZCBtZSBjb3JyZWN0
aW9ucyAoZXNwZWNpYWxseQo+PiA+PiA+ICJkb25lIikuIEkndmUgc3RvcHBlZCBDQ2luZyBldmVy
eW9uZSwgc2luY2UgSSBndWVzcyBpdCBpcyBtb3N0bHkgc3BhbSB0bwo+PiA+PiA+IHRoZSBtYWpv
cml0eS4KPj4gPj4gPgo+PiA+PiA+IGh5cGVydmlzb3IsIGJsb2NrZXJzOgo+PiA+PiA+Cj4+ID4+
ID4gwqAgwqAgwqAqIHJvdW5kLXVwIG9mIHRoZSBjbG9zaW5nIG9mIHRoZSBzZWN1cml0eSBob2xl
IGluIE1TSS1YCj4+ID4+ID4gwqAgwqAgwqAgwqBwYXNzdGhyb3VnaCAodW5pZm9ybWx5IC0gaS5l
LiBldmVuIGZvciBEb20wIC0gZGlzYWxsb3dpbmcgd3JpdGUKPj4gPj4gPiDCoCDCoCDCoCDCoGFj
Y2VzcyB0byBNU0ktWCB0YWJsZSBwYWdlcykuIChKYW4gQmV1bGljaCAtLSBtb3JlIGZpeGVzCj4+
ID4+ID4gwqAgwqAgwqAgwqByZXF1aXJlZCB0aGFuIGZpcnN0IHRob3VnaHQsIHBhdGNoZXMgcG9z
dGVkKQo+PiA+PiA+IMKgIMKgIMKgKiBkb21jdGxzIC8gc3lzY3RscyBzZXQgdXAgdG8gbW9kaWZ5
IHNjaGVkdWxlciBwYXJhbWV0ZXJzLCBsaWtlCj4+ID4+ID4gwqAgwqAgwqAgwqB0aGUgY3JlZGl0
MSB0aW1lc2xpY2UgYW5kIHNjaGVkdWxlIHJhdGUuIChHZW9yZ2UgRHVubGFwKQo+PiA+PiA+IMKg
IMKgIMKgKiBnZXQgdGhlIGludGVyZmFjZSBjaGFuZ2VzIGZvciBzaGFyaW5nL3BhZ2luZy9tZW0t
ZXZlbnRzIGRvbmUgYW5kCj4+ID4+ID4gwqAgwqAgwqAgwqBkdXN0ZWQgc28gdGhhdCA0LjIgaXMg
YSBzdGFibGUgQVBJIHRoYXQgd2UgaG9sZCB0by4gKFRpbSBEZWVnYW4sCj4+ID4+ID4gwqAgwqAg
wqAgwqBBbmRyZXMgTGFnYXItQ2F2aWxsYSBldCBhbCkKPj4gPj4gPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCogbWVtIGV2ZW50IHJpbmcgbWFuYWdlbWVudCBwb3N0ZWQsIHNlZW1zIGNsb3NlIHRvIGdv
aW5nCj4+ID4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpbi4KPj4gPj4gPiDCoCDCoCDCoCDC
oCDCoCDCoCDCoCogc2hhcmluZyBwYXRjaGVzIHBvc3RlZAo+PiA+PiA+Cj4+ID4+ID4gdG9vbHMs
IGJsb2NrZXJzOgo+PiA+PiA+Cj4+ID4+ID4gwqAgwqAgwqAqIGxpYnhsIHN0YWJsZSBBUEkgLS0g
d2Ugd291bGQgbGlrZSA0LjIgdG8gZGVmaW5lIGEgc3RhYmxlIEFQSQo+PiA+PiA+IMKgIMKgIMKg
IMKgd2hpY2ggZG93bnN0cmVhbSdzIGNhbiBzdGFydCB0byByZWx5IG9uIG5vdCBjaGFuZ2luZy4g
QXNwZWN0cyBvZgo+PiA+PiA+IMKgIMKgIMKgIMKgdGhpcyBhcmU6Cj4+ID4+ID4gwqAgwqAgwqAg
wqAgwqAgwqAgwqAqIGV2ZW50IGhhbmRsaW5nIChJYW4gSmFja3NvbiwgcG9zdGVkIHNldmVyYWwg
cm91bmRzLAo+PiA+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbmVhcmluZyBjb21wbGV0aW9u
PykKPj4gPj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCogZHJvcCBsaWJ4bF9kZXZpY2VfbW9kZWxf
aW5mbyAobW92ZSBiaXRzIHRvIGJ1aWxkX2luZm8gb3IKPj4gPj4gPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoGVsc2V3aGVyZSBhcyBhcHByb3ByaWF0ZSkgKElhbiBDYW1wYmVsbCwgZmlyc3QgUkZD
IHNlbnQpCj4+ID4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIGFkZCBsaWJ4bF9kZWZib29sIGFu
ZCBnZW5lcmFsbHkgdHJ5IGFuZCBhcnJhbmdlIHRoYXQKPj4gPj4gPiDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoG1lbXNldChmb28sMCwuLi4pIHJlcXVlc3RzIHRoZSBkZWZhdWx0cyAoSWFuIENhbXBi
ZWxsLAo+PiA+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgZmlyc3QgUkZDIHNlbnQpCj4+ID4+
ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIHRvcG9sb2d5aW5mbyBkYXRhc3RydWN0dXJlIHNob3Vs
ZCBiZSBhIGxpc3Qgb2YgdHVwbGVzLAo+PiA+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgbm90
IGEgdHVwbGUgb2YgbGlzdHMuIChub2JvZHkgY3VycmVudGx5IGxvb2tpbmcgYXQgdGhpcywKPj4g
Pj4gPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoG5vdCAxMDAlIHN1cmUgdGhpcyBtYWtlcyBzZW5z
ZSwgY291bGQgcG9zc2libHkgZGVmZXIgYW5kCj4+ID4+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqBjaGFuZ2UgYWZ0ZXIgNC4yIGluIGEgY29tcGF0aWJsZSB3YXkpCj4+ID4+ID4gwqAgwqAgwqAq
IHhsIHRvIHVzZSBqc29uIGZvciBtYWNoaW5lIHJlYWRhYmxlIG91dHB1dCBpbnN0ZWFkIG9mIHNl
eHAgYnkKPj4gPj4gPiDCoCDCoCDCoCDCoGRlZmF1bHQgKElhbiBDYW1wYmVsbCB0byByZXZpc2l0
IGV4aXN0aW5nIHBhdGNoKQo+PiA+PiA+IMKgIMKgIMKgKiB4bCBzdXBwb3J0IGZvciB2Y3B1IHBp
bm5pbmcgKERhcmlvIEZhZ2dpb2xpKQo+PiA+PiA+IMKgIMKgIMKgKiB4bCBmZWF0dXJlIHBhcml0
eSB3aXRoIHhlbmQgd3J0IGRyaXZlciBkb21haW4gc3VwcG9ydCAoR2VvcmdlCj4+ID4+ID4gwqAg
wqAgwqAgwqBEdW5sYXApCj4+ID4+ID4gwqAgwqAgwqAqIEludGVncmF0ZSBxZW11K3NlYWJpb3Mg
dXBzdHJlYW0gaW50byB0aGUgYnVpbGQgKHBhdGNoZXMKPj4gPj4gPiDCoCDCoCDCoCDCoHJlcG9z
dGVkLCBwZW5kaW5nKS4gTm8gY2hhbmdlIGluIGRlZmF1bHQgcWVtdSBmb3IgNC4yLgo+PiA+PiA+
IMKgIMKgIMKgKiBNb3JlIGZvcm1hbGx5IGRlcHJlY2F0ZSB4bS94ZW5kLiBNYW5wYWdlIHBhdGNo
ZXMgYWxyZWFkeSBpbgo+PiA+PiA+IMKgIMKgIMKgIMKgdHJlZS4gTmVlZHMgcmVsZWFzZSBub3Rp
bmcgYW5kIGNvbW11bmljYXRpb24gYXJvdW5kIC1yYzEgdG8KPj4gPj4gPiDCoCDCoCDCoCDCoHJl
bWluZCBwZW9wbGUgdG8gdGVzdCB4bC4KPj4gPj4gPgo+PiA+PiA+IGh5cGVydmlzb3IsIG5pY2Ug
dG8gaGF2ZToKPj4gPj4gPgo+PiA+PiA+IMKgIMKgIMKgKiBzb2xpZCBpbXBsZW1lbnRhdGlvbiBv
ZiBzaGFyaW5nL3BhZ2luZy9tZW0tZXZlbnRzICh1c2luZyB3b3JrCj4+ID4+ID4gwqAgwqAgwqAg
wqBxdWV1ZXMpIChUaW0gRGVlZ2FuLCBPbGFmIEhlcnJpbmcgZXQgYWwpCj4+ID4+ID4gwqAgwqAg
wqAqIEEgbG9uZyBzdGFuZGluZyBpc3N1ZSBpcyBhIGZ1bGx5IHN5bmNocm9uaXplZCBwMm0gKGxv
Y2tpbmcKPj4gPj4gPiDCoCDCoCDCoCDCoGxvb2t1cHMpIChBbmRyZXMgTGFnYXItQ2F2aWxsYSkK
Pj4gPj4gPiDCoCDCoCDCoCogTlVNQSBpbXByb3ZlbWVudDogZG9tYWluIGFmZmluaXR5IGNvbnNp
c3RlbnQgd2l0aCBjcHVwb29sCj4+ID4+ID4gwqAgwqAgwqAgwqBtZW1iZXJzaGlwIChEYXJpbyBG
YWdnaW9saSwgSmV1cmdlbiBHcm9zcyAtLSBwYXRjaCBwb3N0ZWQpCj4+ID4+ID4KPj4gPj4gPiB0
b29scywgbmljZSB0byBoYXZlOgo+PiA+PiA+Cj4+ID4+ID4gwqAgwqAgwqAqIEhvdHBsdWcgc2Ny
aXB0IHN0dWZmIC0tIGludGVybmFsIHRvIGxpYnhsIChJIHRoaW5rLCB0aGVyZWZvcmUgSQo+PiA+
PiA+IMKgIMKgIMKgIMKgZGlkbid0IHB1dCB0aGlzIHVuZGVyIHN0YWJsZSBBUEkgYWJvdmUpIGJ1
dCBzdGlsbCBnb29kIHRvIGhhdmUKPj4gPj4gPiDCoCDCoCDCoCDCoGZvciA0LjI/IFJvZ2VyIFBh
dSBNb25ldCB3YXMgbG9va2luZyBhdCB0aGlzIGJ1dCBpdHMgbG9va2luZwo+PiA+PiA+IMKgIMKg
IMKgIMKgbGlrZSBhIGJpZyBjYW4tby13b3Jtcy4gKGRpc2N1c3Npb24gb24tZ29pbmcpCj4+ID4+
ID4gwqAgwqAgwqAqIEJsb2NrIHNjcmlwdCBzdXBwb3J0IC0tIGZvbGxvd3Mgb24gZnJvbSBob3Rw
bHVnIHNjcmlwdCAoUm9nZXIKPj4gPj4gPiDCoCDCoCDCoCDCoFBhdSBNb25ldCkKPj4gPj4gPiDC
oCDCoCDCoCogbGlieWFqbCB2MiBzdXBwb3J0IChwYXRjaCBwb3N0ZWQgYnkgUm9nZXIgUGF1IE1v
bmV0LCBibG9ja2VkIG9uCj4+ID4+ID4gwqAgwqAgwqAgwqBhdXRvY29uZj8pCj4+ID4+ID4gwqAg
wqAgwqAqIENvbmZpZ3VyZS9jb250cm9sIHBhZ2luZyB2aWEgeGwvbGlieGwgKE9sYWYgSGVycmlu
ZykKPj4gPj4gPiDCoCDCoCDCoCogVXBzdHJlYW0gcWVtdSBmZWF0dXJlIHBhdGNoZXM6Cj4+ID4+
ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAqIFVwc3RyZWFtIHFlbXUgUENJIHBhc3N0aHJvdWdoIHN1
cHBvcnQgKEFudGhvbnkgUGVyYXJkKQo+PiA+PiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgKiBVcHN0
cmVhbSBxZW11IHNhdmUgcmVzdG9yZSAoQW50aG9ueSBQZXJhcmQpCj4+ID4+ID4gwqAgwqAgwqAq
IE5lc3RlZC12aXJ0dWFsaXNhdGlvbiAoY3VycmVudGx5IHNob3VsZCBiZSBtYXJrZWQKPj4gPj4g
PiDCoCDCoCDCoCDCoGV4cGVyaW1lbnRhbCxsaWtlbHkgdG8gcmVsZWFzZSB0aGF0IHdheT8gQ29u
c2lkZXIgbmVzdGVkLXN2bQo+PiA+PiA+IMKgIMKgIMKgIMKgc2VwYXJhdGUgdG8gbmVzdGVkLXZt
eC4gTmVzdGVkLXN2bSBpcyBpbiBiZXR0ZXIgc2hhcGUpCj4+ID4+Cj4+ID4+Cj4+ID4+IEp1c3Qg
YSByYW5kb20gdGhvdWdodCwgYnV0IEkgZmluZCBpdCBxdWl0ZSBhbm5veWluZyB0byBuZWVkIGxh
dGV4IHRvCj4+ID4+IGNvbXBpbGUgdGhlIGRvY3VtZW50YXRpb24uIEkgdGhpbmsgaXQgd2lsbCBi
ZSB3aXNlIHRvIGNyZWF0ZSBhIG5ldwo+PiA+PiBNYWtlZmlsZSB0YXJnZXQsIGxpa2UgbWFuLXBh
Z2VzIGFuZCBpbnN0YWxsLW1hbi1wYWdlcyB0byBhbGxvdyB0aGUKPj4gPj4gdXNlciB0byBidWls
ZCBhbmQgaW5zdGFsbCBtYW4gcGFnZXMgb25seSAob3IgZG9uJ3QgYWJvcnQgZG9jcyBidWlsZCBp
Zgo+PiA+PiBsYXRleCBpcyBub3QgZm91bmQpLiBQZXJzb25hbGx5IEkgZG9uJ3QgaGF2ZSBsYXRl
eCBvbiBteSBzZXJ2ZXIsIGFuZCBJCj4+ID4+IGRvbid0IHdhbnQgdG8gaW5zdGFsbCBpdCwgYnV0
IEkgd291bGQgbGlrZSB0byBoYXZlIHRoZSBtYW4gcGFnZXMgd2hlbgo+PiA+PiBidWlsZGluZyBY
ZW4gZnJvbSBzb3VyY2UuCj4+ID4KPj4gPiAibWFrZSAtQyBkb2NzIG1hbi1wYWdlcyIgd2lsbCBk
byB3aGF0IHlvdSB3YW50Lgo+Pgo+PiBUaGFua3MsIEkndmUgYWxyZWFkeSBkb25lIHRoaXMgdG8g
YnVpbGQgdGhlbSBvbiBteSBzeXN0ZW0sIGJ1dCBJIHRoaW5rCj4+IHdlIHNob3VsZCBwcm92aWRl
IHNvbWUgZWFzeSB3YXkgZm9yIHVzZXJzIHdpdGhvdXQgbGF0ZXggdG8gYnVpbGQgYW5kCj4+IGlu
c3RhbGwgdGhlIG1hbiBwYWdlcy4KPgo+IEl0J3MgaGFyZCB0byBnZXQgbXVjaCBlYXNpZXIsIGJ1
dC4uLgo+Cj4+ID4gSSBtdXN0IGFkbWl0IEkgdGhvdWdodCBsYXRleCB3YXMgb3B0aW9uYWwgYW5k
IHRoYXQgIm1ha2UgZG9jcyIgd291bGQKPj4gPiBzaW1wbHkgc2tpcCB0aG9zZSBkb2NzIGlmIGl0
IHdhc24ndCBpbnN0YWxsZWQgLS0gdGhhdCdzIHdoYXQgdGhlICJpZgo+PiA+IHdoaWNoICQoVE9P
TCkiIGNvbnN0cnVjdCB1c2VkIGluIHRoZXJlIGlzIChzdXBwb3NlZCB0byBiZSkgZG9pbmcuCj4+
Cj4+IElmIGxhdGV4IGlzIG5vdCBmb3VuZCwgdGhlIGNvbXBpbGF0aW9uIGlzIGFib3J0ZWQ6Cj4+
Cj4+ICMgbWFrZSBkb2NzCj4+IHNoIC4vZG9jcy9jaGVja19wa2dzICYmIG1ha2UgLUMgZG9jcyBp
bnN0YWxsIHx8IHRydWUKPj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQo+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09Cj4+ID0gV0FSTklORzogUGFja2FnZSAnbGF0ZXgnIGlzIHJlcXVpcmVkCj4+ID0gwqAg
wqAgwqAgwqAgwqB0byBidWlsZCBYZW4gZG9jdW1lbnRhdGlvbgo+PiA9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Cj4+ID09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPj4KPj4gSSB0aGluayBtYWtlIGRvY3Mgc2hv
dWxkIGp1c3Qgc2tpcCBsYXRleCBpZiBub3QgZm91bmQuCj4KPiBMb29rcyBsaWtlIGl0IGlzIHNp
bXBseSB0aGUgY2hlY2sgd2hpY2ggaXMgdG9vIHN0cmljdC4gQUZBSUNUIHRoZSBhY3R1YWwKPiBk
b2NzIGJ1aWxkIGFscmVhZHkgc2tpcHMgdGhvc2UgZG9jcyBpZiB5b3UgZG9uJ3QgaGF2ZSBMYXRl
eC4gWW91IGNhbgo+IHRlc3QgdGhpcyB3aXRoICJtYWtlIC1DIGRvY3MiIHdoaWNoIGlzIGJhc2lj
YWxseSB0aGUgc2FtZSBhcyAibWFrZSBkb2NzIgo+IGJ1dCB3aXRob3V0IHRoZSBjaGVja3MuCgpJ
J20gbm90IHJlYWxseSBzdXJlIGxhdGV4IGlzIHNraXBwZWQgaWYgbm90IGZvdW5kOgoKIyBtYWtl
IC1DIGRvY3MKbWFrZTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4td29yay9kb2NzJwps
YXRleCBzcmMvdXNlci50ZXggPi9kZXYvbnVsbAovYmluL3NoOiBsYXRleDogbm90IGZvdW5kCm1h
a2U6ICoqKiBbdXNlci5kdmldIEVycm9yIDEyNwptYWtlOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Jv
b3QveGVuLXdvcmsvZG9jcycKCkVpdGhlciB3ZSByZW1vdmUgdGhlIGxhdGV4IGRvY3Mgb3Igd2Ug
YWRkIHNvbWUgY2hlY2tzIHRvIHNraXAgdGhlCnNlY3Rpb25zIHRoYXQgcmVxdWlyZSBsYXRleC4K
Cj4KPiBJYW4uCj4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:17:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1Rq4av-0006AN-E8; Wed, 25 Jan 2012 15:17:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Rq4at-0006AF-SV
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:17:04 +0000
Received: from [85.158.138.51:38687] by server-9.bemta-3.messagelabs.com id
	98/C9-31168-FEC102F4; Wed, 25 Jan 2012 15:17:03 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327504622!10646958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30470 invoked from network); 25 Jan 2012 15:17:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:17:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10284872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:17:02 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 25 Jan 2012
	15:17:02 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 15:16:59 +0000
Thread-Topic: [Xen-devel] Regressions in v3.3-rc1 introduced by
	"xen/granttable: Grant tables V2 implementation"
Thread-Index: AczbR6urhH5y2nAfQyqLZl2xeNa+3wALHyNw
Message-ID: <291EDFCB1E9E224A99088639C4762022C80E2F0F20@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327485333.24561.232.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: "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>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> 
> On HVM for gnttab_shared we make an add_to_physmap call with
> XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> do something similar for the status array though and I don't see a
> XENMAPSPACE_* specifically for that case either in the hypervisor either.
> 

There is no map-space for the status pages. To map them you use the standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky, but that's how it is.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:17:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1Rq4av-0006AN-E8; Wed, 25 Jan 2012 15:17:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Paul.Durrant@citrix.com>) id 1Rq4at-0006AF-SV
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:17:04 +0000
Received: from [85.158.138.51:38687] by server-9.bemta-3.messagelabs.com id
	98/C9-31168-FEC102F4; Wed, 25 Jan 2012 15:17:03 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327504622!10646958!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30470 invoked from network); 25 Jan 2012 15:17:02 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:17:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10284872"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:17:02 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 25 Jan 2012
	15:17:02 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk
	<konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 15:16:59 +0000
Thread-Topic: [Xen-devel] Regressions in v3.3-rc1 introduced by
	"xen/granttable: Grant tables V2 implementation"
Thread-Index: AczbR6urhH5y2nAfQyqLZl2xeNa+3wALHyNw
Message-ID: <291EDFCB1E9E224A99088639C4762022C80E2F0F20@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327485333.24561.232.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: "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>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> 
> On HVM for gnttab_shared we make an add_to_physmap call with
> XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> do something similar for the status array though and I don't see a
> XENMAPSPACE_* specifically for that case either in the hypervisor either.
> 

There is no map-space for the status pages. To map them you use the standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky, but that's how it is.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:23:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4hF-0006bI-9U; Wed, 25 Jan 2012 15:23:37 +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 1Rq4hE-0006b7-6v
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:23:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327505010!8665715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29613 invoked from network); 25 Jan 2012 15:23: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;
	25 Jan 2012 15:23:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285036"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:23:30 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 25 Jan 2012
	15:23:30 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, "Konrad Rzeszutek Wilk
	(konrad.wilk@oracle.com)" <konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 15:23:28 +0000
Thread-Topic: [Xen-devel] Regressions in v3.3-rc1 introduced by
	"xen/granttable: Grant tables V2 implementation"
Thread-Index: AczbR6urhH5y2nAfQyqLZl2xeNa+3wALHyNwAAAuB1A=
Message-ID: <291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.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: "ANNIE LI \(annie.li@oracle.com\)" <annie.li@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Paul Durrant
> Sent: 25 January 2012 07:17
> To: Ian Campbell; Konrad Rzeszutek Wilk
> Cc: annie.li@oracle.com; xen-devel@lists.xensource.com; linux-
> kernel@vger.kernel.org
> Subject: RE: [Xen-devel] Regressions in v3.3-rc1 introduced by
> "xen/granttable: Grant tables V2 implementation"
> 
> > -----Original Message-----
> >
> > On HVM for gnttab_shared we make an add_to_physmap call with
> > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call
> > to do something similar for the status array though and I don't see a
> > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> >
> 
> There is no map-space for the status pages. To map them you use the
> standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky,
> but that's how it is.
> 

I fixed a bug in xen-unstable a few weeks back that prevented mapping of the status frames so I guess the bug is possibly due to trying to use gnttab 2 on 4.1, where this bug would hit, but failing to check the return code from the status mapping hypercall?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:23:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:23:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4hF-0006bI-9U; Wed, 25 Jan 2012 15:23:37 +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 1Rq4hE-0006b7-6v
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:23:36 +0000
X-Env-Sender: Paul.Durrant@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327505010!8665715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29613 invoked from network); 25 Jan 2012 15:23: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;
	25 Jan 2012 15:23:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285036"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:23:30 +0000
Received: from LONPMAILBOX01.citrite.net ([10.30.224.160]) by
	LONPMAILMX01.citrite.net ([10.30.203.162]) with mapi; Wed, 25 Jan 2012
	15:23:30 +0000
From: Paul Durrant <Paul.Durrant@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Ian
	Campbell <Ian.Campbell@citrix.com>, "Konrad Rzeszutek Wilk
	(konrad.wilk@oracle.com)" <konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 15:23:28 +0000
Thread-Topic: [Xen-devel] Regressions in v3.3-rc1 introduced by
	"xen/granttable: Grant tables V2 implementation"
Thread-Index: AczbR6urhH5y2nAfQyqLZl2xeNa+3wALHyNwAAAuB1A=
Message-ID: <291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.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: "ANNIE LI \(annie.li@oracle.com\)" <annie.li@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> -----Original Message-----
> From: Paul Durrant
> Sent: 25 January 2012 07:17
> To: Ian Campbell; Konrad Rzeszutek Wilk
> Cc: annie.li@oracle.com; xen-devel@lists.xensource.com; linux-
> kernel@vger.kernel.org
> Subject: RE: [Xen-devel] Regressions in v3.3-rc1 introduced by
> "xen/granttable: Grant tables V2 implementation"
> 
> > -----Original Message-----
> >
> > On HVM for gnttab_shared we make an add_to_physmap call with
> > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call
> > to do something similar for the status array though and I don't see a
> > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> >
> 
> There is no map-space for the status pages. To map them you use the
> standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky,
> but that's how it is.
> 

I fixed a bug in xen-unstable a few weeks back that prevented mapping of the status frames so I guess the bug is possibly due to trying to use gnttab 2 on 4.1, where this bug would hit, but failing to check the return code from the status mapping hypercall?

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:41:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4xi-00071M-A0; Wed, 25 Jan 2012 15:40:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq4xg-00071H-B8
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:40:36 +0000
Received: from [85.158.138.51:39362] by server-10.bemta-3.messagelabs.com id
	9F/18-20948-372202F4; Wed, 25 Jan 2012 15:40:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327506034!10637934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16175 invoked from network); 25 Jan 2012 15:40:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:40:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 15:40:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 25 Jan 2012 15:40:34 +0000
In-Reply-To: <CAPLaKK4brH4yW9=RuoBsaBzHKiTchepmMnW9uZpX185MaAoSPA@mail.gmail.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
	<1327502464.24561.325.camel@zakaz.uk.xensource.com>
	<CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
	<1327503546.24561.331.camel@zakaz.uk.xensource.com>
	<CAPLaKK4brH4yW9=RuoBsaBzHKiTchepmMnW9uZpX185MaAoSPA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506034.24561.332.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDE1OjAzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
OgoKPiBJJ20gbm90IHJlYWxseSBzdXJlIGxhdGV4IGlzIHNraXBwZWQgaWYgbm90IGZvdW5kOgo+
IAo+ICMgbWFrZSAtQyBkb2NzCj4gbWFrZTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4t
d29yay9kb2NzJwo+IGxhdGV4IHNyYy91c2VyLnRleCA+L2Rldi9udWxsCj4gL2Jpbi9zaDogbGF0
ZXg6IG5vdCBmb3VuZAo+IG1ha2U6ICoqKiBbdXNlci5kdmldIEVycm9yIDEyNwo+IG1ha2U6IExl
YXZpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4td29yay9kb2NzJwo+IAo+IEVpdGhlciB3ZSByZW1v
dmUgdGhlIGxhdGV4IGRvY3Mgb3Igd2UgYWRkIHNvbWUgY2hlY2tzIHRvIHNraXAgdGhlCj4gc2Vj
dGlvbnMgdGhhdCByZXF1aXJlIGxhdGV4LgoKQWgsIEkgd2FzIGxvb2tpbmcgYXQgbGF0ZXgyaHRt
bCBhbmQgbWlzc2VkIHRoZSByYXcgbGF0ZXggY29tbWFuZCwgc29ycnkuClllcyB3ZSBzaG91bGQg
Z2F0ZSB0aGVtLCBvciByZW1vdmUgdGhlbSBhcyBLZWlyIHN1Z2dlc3RzLgoKSWFuLgoKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:41:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:41:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4xi-00071M-A0; Wed, 25 Jan 2012 15:40:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq4xg-00071H-B8
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:40:36 +0000
Received: from [85.158.138.51:39362] by server-10.bemta-3.messagelabs.com id
	9F/18-20948-372202F4; Wed, 25 Jan 2012 15:40:35 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327506034!10637934!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16175 invoked from network); 25 Jan 2012 15:40:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:40:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285472"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:40:34 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 15:40:35 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Wed, 25 Jan 2012 15:40:34 +0000
In-Reply-To: <CAPLaKK4brH4yW9=RuoBsaBzHKiTchepmMnW9uZpX185MaAoSPA@mail.gmail.com>
References: <1327324745.24561.124.camel@zakaz.uk.xensource.com>
	<CAPLaKK49YTYQzMtSnphxnjbic0Da++SPROKBGFEQj1JNwSp_Fg@mail.gmail.com>
	<1327502464.24561.325.camel@zakaz.uk.xensource.com>
	<CAPLaKK7RiUysAR_xr6Hc2FBf_btj-XvG+3h4FxgbrBaDmF2zCA@mail.gmail.com>
	<1327503546.24561.331.camel@zakaz.uk.xensource.com>
	<CAPLaKK4brH4yW9=RuoBsaBzHKiTchepmMnW9uZpX185MaAoSPA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506034.24561.332.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDE1OjAzICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
OgoKPiBJJ20gbm90IHJlYWxseSBzdXJlIGxhdGV4IGlzIHNraXBwZWQgaWYgbm90IGZvdW5kOgo+
IAo+ICMgbWFrZSAtQyBkb2NzCj4gbWFrZTogRW50ZXJpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4t
d29yay9kb2NzJwo+IGxhdGV4IHNyYy91c2VyLnRleCA+L2Rldi9udWxsCj4gL2Jpbi9zaDogbGF0
ZXg6IG5vdCBmb3VuZAo+IG1ha2U6ICoqKiBbdXNlci5kdmldIEVycm9yIDEyNwo+IG1ha2U6IExl
YXZpbmcgZGlyZWN0b3J5IGAvcm9vdC94ZW4td29yay9kb2NzJwo+IAo+IEVpdGhlciB3ZSByZW1v
dmUgdGhlIGxhdGV4IGRvY3Mgb3Igd2UgYWRkIHNvbWUgY2hlY2tzIHRvIHNraXAgdGhlCj4gc2Vj
dGlvbnMgdGhhdCByZXF1aXJlIGxhdGV4LgoKQWgsIEkgd2FzIGxvb2tpbmcgYXQgbGF0ZXgyaHRt
bCBhbmQgbWlzc2VkIHRoZSByYXcgbGF0ZXggY29tbWFuZCwgc29ycnkuClllcyB3ZSBzaG91bGQg
Z2F0ZSB0aGVtLCBvciByZW1vdmUgdGhlbSBhcyBLZWlyIHN1Z2dlc3RzLgoKSWFuLgoKCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:41:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4yF-000735-Nv; Wed, 25 Jan 2012 15:41:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq4yE-00072U-Cl
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:41:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327506064!12477989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3319 invoked from network); 25 Jan 2012 15:41:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:41:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:41: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, 25 Jan 2012 15:41:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Wed, 25 Jan 2012 15:41:03 +0000
In-Reply-To: <CB45C8EB.29986%keir.xen@gmail.com>
References: <CB45C8EB.29986%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506063.24561.333.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 <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 14:57 +0000, Keir Fraser wrote:
> I'm dubious whether the latex docs are at all useful these days. We
> could possibly just remove them entirely. 

Or at least not build them by default. Personally I'm happy to have them
removed.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:41:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:41:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq4yF-000735-Nv; Wed, 25 Jan 2012 15:41:11 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq4yE-00072U-Cl
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:41:10 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327506064!12477989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3319 invoked from network); 25 Jan 2012 15:41:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:41:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285490"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:41: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, 25 Jan 2012 15:41:04 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Keir Fraser <keir.xen@gmail.com>
Date: Wed, 25 Jan 2012 15:41:03 +0000
In-Reply-To: <CB45C8EB.29986%keir.xen@gmail.com>
References: <CB45C8EB.29986%keir.xen@gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506063.24561.333.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 <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 14:57 +0000, Keir Fraser wrote:
> I'm dubious whether the latex docs are at all useful these days. We
> could possibly just remove them entirely. 

Or at least not build them by default. Personally I'm happy to have them
removed.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15: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 1Rq55C-0007QD-KP; Wed, 25 Jan 2012 15:48: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 1Rq55A-0007Q8-Q7
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:48:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327506494!3609041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9828 invoked from network); 25 Jan 2012 15:48:14 -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;
	25 Jan 2012 15:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:47: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, 25 Jan 2012 15:47:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 25 Jan 2012 15:47:42 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80E2F0F20@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F20@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506463.24561.335.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "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 Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 15:16 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > 
> > On HVM for gnttab_shared we make an add_to_physmap call with
> > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> > do something similar for the status array though and I don't see a
> > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > 
> 
> There is no map-space for the status pages. To map them you use the
> standard map space but OR a bit (top bit IIRC) into in the idx. It's a
> bit icky, but that's how it is.

I can't see that happening anywhere in the current Linux tree, there's
only one call to XENMAPSPACE_grant_table and it doesn't set the top bit,
so presumably this is at least part of the problem.

I hope that "top bit" is consistent for 32 and 64 bit domains....

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15: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 1Rq55C-0007QD-KP; Wed, 25 Jan 2012 15:48: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 1Rq55A-0007Q8-Q7
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:48:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327506494!3609041!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9828 invoked from network); 25 Jan 2012 15:48:14 -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;
	25 Jan 2012 15:48:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:47: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, 25 Jan 2012 15:47:43 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 25 Jan 2012 15:47:42 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80E2F0F20@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F20@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506463.24561.335.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "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 Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 15:16 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > 
> > On HVM for gnttab_shared we make an add_to_physmap call with
> > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> > do something similar for the status array though and I don't see a
> > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > 
> 
> There is no map-space for the status pages. To map them you use the
> standard map space but OR a bit (top bit IIRC) into in the idx. It's a
> bit icky, but that's how it is.

I can't see that happening anywhere in the current Linux tree, there's
only one call to XENMAPSPACE_grant_table and it doesn't set the top bit,
so presumably this is at least part of the problem.

I hope that "top bit" is consistent for 32 and 64 bit domains....

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:50:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq56i-0007Z1-4I; Wed, 25 Jan 2012 15:49:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq56g-0007Yv-R6
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:49:55 +0000
Received: from [85.158.138.51:42382] by server-7.bemta-3.messagelabs.com id
	FE/91-31267-2A4202F4; Wed, 25 Jan 2012 15:49:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327506593!10652077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4110 invoked from network); 25 Jan 2012 15:49:53 -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;
	25 Jan 2012 15:49:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15: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;
	Wed, 25 Jan 2012 15:49:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 25 Jan 2012 15:49:52 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506593.24561.337.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "ANNIE LI \(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
	Rzeszutek Wilk \(konrad.wilk@oracle.com\)" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 15:23 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Paul Durrant
> > Sent: 25 January 2012 07:17
> > To: Ian Campbell; Konrad Rzeszutek Wilk
> > Cc: annie.li@oracle.com; xen-devel@lists.xensource.com; linux-
> > kernel@vger.kernel.org
> > Subject: RE: [Xen-devel] Regressions in v3.3-rc1 introduced by
> > "xen/granttable: Grant tables V2 implementation"
> > 
> > > -----Original Message-----
> > >
> > > On HVM for gnttab_shared we make an add_to_physmap call with
> > > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call
> > > to do something similar for the status array though and I don't see a
> > > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > >
> > 
> > There is no map-space for the status pages. To map them you use the
> > standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky,
> > but that's how it is.
> > 
> 
> I fixed a bug in xen-unstable a few weeks back that prevented mapping
> of the status frames so I guess the bug is possibly due to trying to
> use gnttab 2 on 4.1, where this bug would hit, but failing to check
> the return code from the status mapping hypercall?

That bit in the Linux code seems to be correct, at least by inspection.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:50:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:50:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq56i-0007Z1-4I; Wed, 25 Jan 2012 15:49:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq56g-0007Yv-R6
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:49:55 +0000
Received: from [85.158.138.51:42382] by server-7.bemta-3.messagelabs.com id
	FE/91-31267-2A4202F4; Wed, 25 Jan 2012 15:49:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327506593!10652077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4110 invoked from network); 25 Jan 2012 15:49:53 -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;
	25 Jan 2012 15:49:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285714"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15: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;
	Wed, 25 Jan 2012 15:49:53 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 25 Jan 2012 15:49:52 +0000
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506593.24561.337.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "ANNIE LI \(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
	Rzeszutek Wilk \(konrad.wilk@oracle.com\)" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 15:23 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Paul Durrant
> > Sent: 25 January 2012 07:17
> > To: Ian Campbell; Konrad Rzeszutek Wilk
> > Cc: annie.li@oracle.com; xen-devel@lists.xensource.com; linux-
> > kernel@vger.kernel.org
> > Subject: RE: [Xen-devel] Regressions in v3.3-rc1 introduced by
> > "xen/granttable: Grant tables V2 implementation"
> > 
> > > -----Original Message-----
> > >
> > > On HVM for gnttab_shared we make an add_to_physmap call with
> > > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call
> > > to do something similar for the status array though and I don't see a
> > > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > >
> > 
> > There is no map-space for the status pages. To map them you use the
> > standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky,
> > but that's how it is.
> > 
> 
> I fixed a bug in xen-unstable a few weeks back that prevented mapping
> of the status frames so I guess the bug is possibly due to trying to
> use gnttab 2 on 4.1, where this bug would hit, but failing to check
> the return code from the status mapping hypercall?

That bit in the Linux code seems to be correct, at least by inspection.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:52:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq58c-0007nZ-Lf; Wed, 25 Jan 2012 15:51: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 1Rq58b-0007kZ-CH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:51:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327506707!12361125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27196 invoked from network); 25 Jan 2012 15:51:47 -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;
	25 Jan 2012 15:51:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:51:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 15:51:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 25 Jan 2012 15:51:46 +0000
In-Reply-To: <45B8991A987A4149B40F1A061BF49097CBE27F2A88@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F20@LONPMAILBOX01.citrite.net>
	<45B8991A987A4149B40F1A061BF49097CBE27F2A88@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506706.24561.338.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "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 Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 15:47 +0000, Ian Campbell wrote:
> On Wed, 2012-01-25 at 15:16 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > 
> > > On HVM for gnttab_shared we make an add_to_physmap call with
> > > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> > > do something similar for the status array though and I don't see a
> > > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > > 
> > 
> > There is no map-space for the status pages. To map them you use the
> > standard map space but OR a bit (top bit IIRC) into in the idx. It's a
> > bit icky, but that's how it is.
> 
> I can't see that happening anywhere in the current Linux tree, there's
> only one call to XENMAPSPACE_grant_table and it doesn't set the top bit,
> so presumably this is at least part of the problem.
> 
> I hope that "top bit" is consistent for 32 and 64 bit domains....

#define XENMAPIDX_grant_table_status 0x80000000

...so yes

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:52:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:52:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq58c-0007nZ-Lf; Wed, 25 Jan 2012 15:51: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 1Rq58b-0007kZ-CH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:51:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327506707!12361125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27196 invoked from network); 25 Jan 2012 15:51:47 -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;
	25 Jan 2012 15:51:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285768"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:51:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 15:51:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Date: Wed, 25 Jan 2012 15:51:46 +0000
In-Reply-To: <45B8991A987A4149B40F1A061BF49097CBE27F2A88@LONPMAILBOX01.citrite.net>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F20@LONPMAILBOX01.citrite.net>
	<45B8991A987A4149B40F1A061BF49097CBE27F2A88@LONPMAILBOX01.citrite.net>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327506706.24561.338.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "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 Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 15:47 +0000, Ian Campbell wrote:
> On Wed, 2012-01-25 at 15:16 +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > 
> > > On HVM for gnttab_shared we make an add_to_physmap call with
> > > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> > > do something similar for the status array though and I don't see a
> > > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > > 
> > 
> > There is no map-space for the status pages. To map them you use the
> > standard map space but OR a bit (top bit IIRC) into in the idx. It's a
> > bit icky, but that's how it is.
> 
> I can't see that happening anywhere in the current Linux tree, there's
> only one call to XENMAPSPACE_grant_table and it doesn't set the top bit,
> so presumably this is at least part of the problem.
> 
> I hope that "top bit" is consistent for 32 and 64 bit domains....

#define XENMAPIDX_grant_table_status 0x80000000

...so yes

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:52:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq59E-0007wW-3V; Wed, 25 Jan 2012 15:52:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rq59C-0007vg-BH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:52:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327506676!62457092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9064 invoked from network); 25 Jan 2012 15:51: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;
	25 Jan 2012 15:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:52: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, 25 Jan 2012 15:52:24 +0000
Date: Wed, 25 Jan 2012 15:53: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.1201251359570.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] README: add upstream qemu dependecies
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Upstream Qemu, just added to the Xen build system, needs GLib 2.0 and
pkg-config to compile.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/README b/README
index 02d1d50..bc28a61 100644
--- a/README
+++ b/README
@@ -50,6 +50,8 @@ provided by your OS distributor:
     * Development install of yajl (e.g. libyajl-dev)
     * Development install of libaio (e.g. libaio-dev) version 0.3.107 or
       greater. Set CONFIG_SYSTEM_LIBAIO in .config if this is not available.
+    * Development install of GLib v2.0 (e.g. libglib2.0-dev)
+    * pkg-config
     * bridge-utils package (/sbin/brctl)
     * iproute package (/sbin/ip)
     * hotplug or udev

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:52:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:52:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq59E-0007wW-3V; Wed, 25 Jan 2012 15:52:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rq59C-0007vg-BH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:52:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327506676!62457092!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9064 invoked from network); 25 Jan 2012 15:51: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;
	25 Jan 2012 15:51:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:52: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, 25 Jan 2012 15:52:24 +0000
Date: Wed, 25 Jan 2012 15:53: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.1201251359570.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] README: add upstream qemu dependecies
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Upstream Qemu, just added to the Xen build system, needs GLib 2.0 and
pkg-config to compile.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/README b/README
index 02d1d50..bc28a61 100644
--- a/README
+++ b/README
@@ -50,6 +50,8 @@ provided by your OS distributor:
     * Development install of yajl (e.g. libyajl-dev)
     * Development install of libaio (e.g. libaio-dev) version 0.3.107 or
       greater. Set CONFIG_SYSTEM_LIBAIO in .config if this is not available.
+    * Development install of GLib v2.0 (e.g. libglib2.0-dev)
+    * pkg-config
     * bridge-utils package (/sbin/brctl)
     * iproute package (/sbin/ip)
     * hotplug or udev

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:52:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq59P-0007yb-H2; Wed, 25 Jan 2012 15:52:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rq59N-0007xS-Fi
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:52:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327506729!57125437!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5366 invoked from network); 25 Jan 2012 15:52:09 -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;
	25 Jan 2012 15:52:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:52:37 +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, 25 Jan 2012 15:52:37 +0000
Message-ID: <1327506721.2318.2.camel@leeni.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:52:01 +0000
In-Reply-To: <1327326980.3921.12.camel@liuw-workstation>
References: <1327326980.3921.12.camel@liuw-workstation>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH V2] Add a GNTTABOP to swap the content of
 two grant references under lock provided that they are not currently
 active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, ping?

And got a SOB from Paul:

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

On Mon, 2012-01-23 at 13:56 +0000, Wei Liu (Intern) wrote:
> Fix issues commented by Jan - coding style, stubs and variable types.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/arch/x86/hvm/hvm.c           |    1 +
>  xen/common/compat/grant_table.c  |    8 +++
>  xen/common/grant_table.c         |   89 ++++++++++++++++++++++++++++++++++++++
>  xen/include/public/grant_table.h |   18 +++++++-
>  xen/include/xlat.lst             |    1 +
>  5 files changed, 115 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index b3d9ac0..c46bd3e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int cmd)
>      case GNTTABOP_copy:
>      case GNTTABOP_map_grant_ref:
>      case GNTTABOP_unmap_grant_ref:
> +    case GNTTABOP_swap_grant_ref:
>          return 1;
>      default:
>          /* all other commands need auditing */
> diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
> index ca60395..edd20c6 100644
> --- a/xen/common/compat/grant_table.c
> +++ b/xen/common/compat/grant_table.c
> @@ -47,6 +47,10 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_status_frames_compat_t);
>  CHECK_gnttab_get_version;
>  #undef xen_gnttab_get_version
>  
> +#define xen_gnttab_swap_grant_ref gnttab_swap_grant_ref
> +CHECK_gnttab_swap_grant_ref;
> +#undef xen_gnttab_swap_grant_ref
> +
>  int compat_grant_table_op(unsigned int cmd,
>                            XEN_GUEST_HANDLE(void) cmp_uop,
>                            unsigned int count)
> @@ -98,6 +102,10 @@ int compat_grant_table_op(unsigned int cmd,
>      CASE(get_status_frames);
>  #endif
>  
> +#ifndef CHECK_gnttab_swap_grant_ref
> +    CASE(swap_grant_ref);
> +#endif
> +
>  #undef CASE
>      default:
>          return do_grant_table_op(cmd, cmp_uop, count);
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 34a49db..2683324 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2282,6 +2282,81 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
>      return 0;
>  }
>  
> +static s16
> +__gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
> +{
> +    struct domain *d;
> +    struct active_grant_entry *act;
> +    s16 rc = GNTST_okay;
> +
> +    d = rcu_lock_current_domain();
> +
> +    spin_lock(&d->grant_table->lock);
> +
> +    act = &active_entry(d->grant_table, ref_a);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
> +
> +    act = &active_entry(d->grant_table, ref_b);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
> +
> +    if ( d->grant_table->gt_version == 1 )
> +    {
> +        grant_entry_v1_t shared;
> +
> +        shared = shared_entry_v1(d->grant_table, ref_a);
> +
> +        shared_entry_v1(d->grant_table, ref_a) =
> +            shared_entry_v1(d->grant_table, ref_b);
> +
> +        shared_entry_v1(d->grant_table, ref_b) = shared;
> +    }
> +    else
> +    {
> +        grant_entry_v2_t shared;
> +        grant_status_t status;
> +
> +        shared = shared_entry_v2(d->grant_table, ref_a);
> +        status = status_entry(d->grant_table, ref_a);
> +
> +        shared_entry_v2(d->grant_table, ref_a) =
> +            shared_entry_v2(d->grant_table, ref_b);
> +        status_entry(d->grant_table, ref_a) =
> +            status_entry(d->grant_table, ref_b);
> +
> +        shared_entry_v2(d->grant_table, ref_b) = shared;
> +        status_entry(d->grant_table, ref_b) = status;
> +    }
> +
> +out:
> +    spin_unlock(&d->grant_table->lock);
> +
> +    rcu_unlock_domain(d);
> +
> +    return rc;
> +}
> +
> +static long
> +gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
> +                      unsigned int count)
> +{
> +    int i;
> +    gnttab_swap_grant_ref_t op;
> +
> +    for ( i = 0; i < count; i++ )
> +    {
> +        if ( i && hypercall_preempt_check() )
> +            return i;
> +        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
> +            return -EFAULT;
> +        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
> +            return -EFAULT;
> +    }
> +    return 0;
> +}
> +
>  long
>  do_grant_table_op(
>      unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
> @@ -2400,6 +2475,20 @@ do_grant_table_op(
>          rc = gnttab_get_version(guest_handle_cast(uop, gnttab_get_version_t));
>          break;
>      }
> +    case GNTTABOP_swap_grant_ref:
> +    {
> +        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
> +            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
> +        if ( unlikely(!guest_handle_okay(swap, count)) )
> +            goto out;
> +        rc = gnttab_swap_grant_ref(swap, count);
> +        if ( rc > 0 )
> +        {
> +            guest_handle_add_offset(swap, rc);
> +            uop = guest_handle_cast(swap, void);
> +        }
> +        break;
> +    }
>      default:
>          rc = -ENOSYS;
>          break;
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 0bf20bc..54d9551 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -511,6 +511,20 @@ struct gnttab_get_version {
>  typedef struct gnttab_get_version gnttab_get_version_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>  
> +/* 
> + * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
> + */
> +#define GNTTABOP_swap_grant_ref	      11
> +struct gnttab_swap_grant_ref {
> +    /* IN parameters */
> +    grant_ref_t ref_a;
> +    grant_ref_t ref_b;
> +    /* OUT parameters */
> +    int16_t status;             /* GNTST_* */
> +};
> +typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
> +DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
> +
>  #endif /* __XEN_INTERFACE_VERSION__ */
>  
>  /*
> @@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>  #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 GNTST_eagain          (-12) /* Operation not done; try again.        */
>  
>  #define GNTTABOP_error_msgs {                   \
>      "okay",                                     \
> @@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>      "bad page",                                 \
>      "copy arguments cross page boundary",       \
>      "page address size too large",              \
> -    "could not map at the moment, retry"        \
> +    "operation not done; try again"             \
>  }
>  
>  #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> index 3d92175..f602155 100644
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -50,6 +50,7 @@
>  ?	grant_entry_v1			grant_table.h
>  ?       grant_entry_header              grant_table.h
>  ?	grant_entry_v2			grant_table.h
> +?	gnttab_swap_grant_ref		grant_table.h
>  ?	kexec_exec			kexec.h
>  !	kexec_image			kexec.h
>  !	kexec_range			kexec.h



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:52:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:52:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq59P-0007yb-H2; Wed, 25 Jan 2012 15:52:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1Rq59N-0007xS-Fi
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:52:41 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327506729!57125437!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5366 invoked from network); 25 Jan 2012 15:52:09 -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;
	25 Jan 2012 15:52:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10285793"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 15:52:37 +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, 25 Jan 2012 15:52:37 +0000
Message-ID: <1327506721.2318.2.camel@leeni.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 15:52:01 +0000
In-Reply-To: <1327326980.3921.12.camel@liuw-workstation>
References: <1327326980.3921.12.camel@liuw-workstation>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
MIME-Version: 1.0
Cc: Keir Fraser <keir.xen@gmail.com>, wei.liu2@citrix.com
Subject: Re: [Xen-devel] [PATCH V2] Add a GNTTABOP to swap the content of
 two grant references under lock provided that they are not currently
 active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, ping?

And got a SOB from Paul:

Signed-off-by: Paul Durrant <paul.durrant@citrix.com>

On Mon, 2012-01-23 at 13:56 +0000, Wei Liu (Intern) wrote:
> Fix issues commented by Jan - coding style, stubs and variable types.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/arch/x86/hvm/hvm.c           |    1 +
>  xen/common/compat/grant_table.c  |    8 +++
>  xen/common/grant_table.c         |   89 ++++++++++++++++++++++++++++++++++++++
>  xen/include/public/grant_table.h |   18 +++++++-
>  xen/include/xlat.lst             |    1 +
>  5 files changed, 115 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index b3d9ac0..c46bd3e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int cmd)
>      case GNTTABOP_copy:
>      case GNTTABOP_map_grant_ref:
>      case GNTTABOP_unmap_grant_ref:
> +    case GNTTABOP_swap_grant_ref:
>          return 1;
>      default:
>          /* all other commands need auditing */
> diff --git a/xen/common/compat/grant_table.c b/xen/common/compat/grant_table.c
> index ca60395..edd20c6 100644
> --- a/xen/common/compat/grant_table.c
> +++ b/xen/common/compat/grant_table.c
> @@ -47,6 +47,10 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_status_frames_compat_t);
>  CHECK_gnttab_get_version;
>  #undef xen_gnttab_get_version
>  
> +#define xen_gnttab_swap_grant_ref gnttab_swap_grant_ref
> +CHECK_gnttab_swap_grant_ref;
> +#undef xen_gnttab_swap_grant_ref
> +
>  int compat_grant_table_op(unsigned int cmd,
>                            XEN_GUEST_HANDLE(void) cmp_uop,
>                            unsigned int count)
> @@ -98,6 +102,10 @@ int compat_grant_table_op(unsigned int cmd,
>      CASE(get_status_frames);
>  #endif
>  
> +#ifndef CHECK_gnttab_swap_grant_ref
> +    CASE(swap_grant_ref);
> +#endif
> +
>  #undef CASE
>      default:
>          return do_grant_table_op(cmd, cmp_uop, count);
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 34a49db..2683324 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2282,6 +2282,81 @@ gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
>      return 0;
>  }
>  
> +static s16
> +__gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
> +{
> +    struct domain *d;
> +    struct active_grant_entry *act;
> +    s16 rc = GNTST_okay;
> +
> +    d = rcu_lock_current_domain();
> +
> +    spin_lock(&d->grant_table->lock);
> +
> +    act = &active_entry(d->grant_table, ref_a);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
> +
> +    act = &active_entry(d->grant_table, ref_b);
> +    if ( act->pin )
> +        PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
> +
> +    if ( d->grant_table->gt_version == 1 )
> +    {
> +        grant_entry_v1_t shared;
> +
> +        shared = shared_entry_v1(d->grant_table, ref_a);
> +
> +        shared_entry_v1(d->grant_table, ref_a) =
> +            shared_entry_v1(d->grant_table, ref_b);
> +
> +        shared_entry_v1(d->grant_table, ref_b) = shared;
> +    }
> +    else
> +    {
> +        grant_entry_v2_t shared;
> +        grant_status_t status;
> +
> +        shared = shared_entry_v2(d->grant_table, ref_a);
> +        status = status_entry(d->grant_table, ref_a);
> +
> +        shared_entry_v2(d->grant_table, ref_a) =
> +            shared_entry_v2(d->grant_table, ref_b);
> +        status_entry(d->grant_table, ref_a) =
> +            status_entry(d->grant_table, ref_b);
> +
> +        shared_entry_v2(d->grant_table, ref_b) = shared;
> +        status_entry(d->grant_table, ref_b) = status;
> +    }
> +
> +out:
> +    spin_unlock(&d->grant_table->lock);
> +
> +    rcu_unlock_domain(d);
> +
> +    return rc;
> +}
> +
> +static long
> +gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
> +                      unsigned int count)
> +{
> +    int i;
> +    gnttab_swap_grant_ref_t op;
> +
> +    for ( i = 0; i < count; i++ )
> +    {
> +        if ( i && hypercall_preempt_check() )
> +            return i;
> +        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
> +            return -EFAULT;
> +        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
> +            return -EFAULT;
> +    }
> +    return 0;
> +}
> +
>  long
>  do_grant_table_op(
>      unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
> @@ -2400,6 +2475,20 @@ do_grant_table_op(
>          rc = gnttab_get_version(guest_handle_cast(uop, gnttab_get_version_t));
>          break;
>      }
> +    case GNTTABOP_swap_grant_ref:
> +    {
> +        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
> +            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
> +        if ( unlikely(!guest_handle_okay(swap, count)) )
> +            goto out;
> +        rc = gnttab_swap_grant_ref(swap, count);
> +        if ( rc > 0 )
> +        {
> +            guest_handle_add_offset(swap, rc);
> +            uop = guest_handle_cast(swap, void);
> +        }
> +        break;
> +    }
>      default:
>          rc = -ENOSYS;
>          break;
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 0bf20bc..54d9551 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -511,6 +511,20 @@ struct gnttab_get_version {
>  typedef struct gnttab_get_version gnttab_get_version_t;
>  DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>  
> +/* 
> + * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
> + */
> +#define GNTTABOP_swap_grant_ref	      11
> +struct gnttab_swap_grant_ref {
> +    /* IN parameters */
> +    grant_ref_t ref_a;
> +    grant_ref_t ref_b;
> +    /* OUT parameters */
> +    int16_t status;             /* GNTST_* */
> +};
> +typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
> +DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
> +
>  #endif /* __XEN_INTERFACE_VERSION__ */
>  
>  /*
> @@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>  #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 GNTST_eagain          (-12) /* Operation not done; try again.        */
>  
>  #define GNTTABOP_error_msgs {                   \
>      "okay",                                     \
> @@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>      "bad page",                                 \
>      "copy arguments cross page boundary",       \
>      "page address size too large",              \
> -    "could not map at the moment, retry"        \
> +    "operation not done; try again"             \
>  }
>  
>  #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
> index 3d92175..f602155 100644
> --- a/xen/include/xlat.lst
> +++ b/xen/include/xlat.lst
> @@ -50,6 +50,7 @@
>  ?	grant_entry_v1			grant_table.h
>  ?       grant_entry_header              grant_table.h
>  ?	grant_entry_v2			grant_table.h
> +?	gnttab_swap_grant_ref		grant_table.h
>  ?	kexec_exec			kexec.h
>  !	kexec_image			kexec.h
>  !	kexec_range			kexec.h



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:55:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5Bw-0008NH-56; Wed, 25 Jan 2012 15:55:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rq5Bv-0008My-9I
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:55:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327506894!63894211!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23763 invoked from network); 25 Jan 2012 15:54:54 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:54:54 -0000
Received: by wibhm2 with SMTP id hm2so5570692wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 07:55:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5CUvLRssPxPf5rd6ityssQ+Agdni8dt1VH3C590t4q8=;
	b=Y/4PtN/swE1Li90LvUTVm1T0tOuEGvmj6PcJvFTOjpVmJ2u1XeLscydedHJfyzMg08
	4PtIY5LECGDGw9FFYIx6TEghACLhLwynQtIsq6r2QqtychUYbva7JSrbSyHgGLs/e3Nh
	4l17aAt91AjiIeNZ0PTkwwgKqLQVGoNq4qaYM=
Received: by 10.180.95.105 with SMTP id dj9mr28952618wib.18.1327506914916;
	Wed, 25 Jan 2012 07:55:14 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q7sm555476wix.5.2012.01.25.07.55.13
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 07:55:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jan 2012 15:55:04 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>
Message-ID: <CB45D658.382E7%keir@xen.org>
Thread-Topic: [Xen-devel] Xen 4.2 TODO List Update
Thread-Index: AczbebO9/+8gHSO0xE+X+GGzyNl8Fw==
In-Reply-To: <1327506034.24561.332.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/01/2012 15:40, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-01-25 at 15:03 +0000, Roger Pau Monn=E9 wrote:

> I'm not really
> sure latex is skipped if not found:
> =

> # make -C docs
> make: Entering
> directory `/root/xen-work/docs'
> latex src/user.tex >/dev/null
> /bin/sh:
> latex: not found
> make: *** [user.dvi] Error 127
> make: Leaving directory
> `/root/xen-work/docs'
> =

> Either we remove the latex docs or we add some
> checks to skip the
> sections that require latex.

Ah, I was looking at
> latex2html and missed the raw latex command, sorry.
Yes we should gate them,
> or remove them as Keir
> suggests.

Ian.



_______________________________________________
Xen-devel
> mailing =

> list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


I've removed them.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:55:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:55:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5Bw-0008NH-56; Wed, 25 Jan 2012 15:55:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rq5Bv-0008My-9I
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:55:19 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327506894!63894211!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23763 invoked from network); 25 Jan 2012 15:54:54 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:54:54 -0000
Received: by wibhm2 with SMTP id hm2so5570692wib.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 07:55:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=5CUvLRssPxPf5rd6ityssQ+Agdni8dt1VH3C590t4q8=;
	b=Y/4PtN/swE1Li90LvUTVm1T0tOuEGvmj6PcJvFTOjpVmJ2u1XeLscydedHJfyzMg08
	4PtIY5LECGDGw9FFYIx6TEghACLhLwynQtIsq6r2QqtychUYbva7JSrbSyHgGLs/e3Nh
	4l17aAt91AjiIeNZ0PTkwwgKqLQVGoNq4qaYM=
Received: by 10.180.95.105 with SMTP id dj9mr28952618wib.18.1327506914916;
	Wed, 25 Jan 2012 07:55:14 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q7sm555476wix.5.2012.01.25.07.55.13
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 07:55:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jan 2012 15:55:04 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Roger Pau =?ISO-8859-1?B?TW9ubuk=?= <roger.pau@entel.upc.edu>
Message-ID: <CB45D658.382E7%keir@xen.org>
Thread-Topic: [Xen-devel] Xen 4.2 TODO List Update
Thread-Index: AczbebO9/+8gHSO0xE+X+GGzyNl8Fw==
In-Reply-To: <1327506034.24561.332.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/01/2012 15:40, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

> On Wed, 2012-01-25 at 15:03 +0000, Roger Pau Monn=E9 wrote:

> I'm not really
> sure latex is skipped if not found:
> =

> # make -C docs
> make: Entering
> directory `/root/xen-work/docs'
> latex src/user.tex >/dev/null
> /bin/sh:
> latex: not found
> make: *** [user.dvi] Error 127
> make: Leaving directory
> `/root/xen-work/docs'
> =

> Either we remove the latex docs or we add some
> checks to skip the
> sections that require latex.

Ah, I was looking at
> latex2html and missed the raw latex command, sorry.
Yes we should gate them,
> or remove them as Keir
> suggests.

Ian.



_______________________________________________
Xen-devel
> mailing =

> list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel


I've removed them.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:55:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15: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 1Rq5CP-0008SH-Tn; Wed, 25 Jan 2012 15:55:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq5CN-0008Rz-S6
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:55:48 +0000
Received: from [85.158.138.51:22662] by server-3.bemta-3.messagelabs.com id
	48/6B-26314-306202F4; Wed, 25 Jan 2012 15:55:47 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327506944!10471964!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13682 invoked from network); 25 Jan 2012 15:55:46 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 15:55:46 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 08:55:41 -0700
Message-ID: <4F2025FC.7060407@suse.com>
Date: Wed, 25 Jan 2012 08:55:40 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: erin.balid@inoutbox.com
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
	<4F1F3B23.60304@suse.com>
	<1327456894.17114.140661027646361@webmail.messagingengine.com>
In-Reply-To: <1327456894.17114.140661027646361@webmail.messagingengine.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

erin.balid@inoutbox.com wrote:
> Hi Jim.
>
> Thanks for chiming in.
>
> On Tue, Jan 24, 2012, at 04:13 PM, Jim Fehlig wrote:
>   
>>> http://lists.opensuse.org/opensuse-features/2011-03/msg00212.html
>>>       
>> A mailing list to discuss openSUSE features, not an authoritative
>> resource on functionality in any given openSUSE release...
>>     
>
> It's been a big challenge finding anything that IS "an authoritative
> resource on functionality" for Xen in Opensuse.
>
> Where is the Opensuse-specific and Up-to-Date Xen documentation?  I
> guess we cant rely on xen.org docs for Opensuse's Xen?  Is it not really
> closely tied to the xen-devel project then?
>   

Generally speaking, xen.org documentation applies to the xen packages in
openSUSE.  In the case of toolstacks, openSUSE still enables the legacy
toolstack by default, and all upstream documentation wrt the legacy
toolstack applies.  You can use the new toolstack as well, in which case
the upstream xl/libxl documentation applies - including recommendation
that the toolstacks should not be used in parallel.

What you have described in this thread is a bug in openSUSE12.1.  You
followed the documentation and it didn't work :-).

> That leaves me back at my earlier question -- What are good docs for Xen
> on Opensuse?  I've wasted a lot of time - mine and other people's -
> doing what I was told (RTFM!) just to find out that 'real' Xen manual is
> the wrong one.
>   

I'm not sure what the problem is with the manual.  You've hit a bug I
introduced in openSUSE.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:55:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15: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 1Rq5CP-0008SH-Tn; Wed, 25 Jan 2012 15:55:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq5CN-0008Rz-S6
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:55:48 +0000
Received: from [85.158.138.51:22662] by server-3.bemta-3.messagelabs.com id
	48/6B-26314-306202F4; Wed, 25 Jan 2012 15:55:47 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327506944!10471964!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13682 invoked from network); 25 Jan 2012 15:55:46 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 15:55:46 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 08:55:41 -0700
Message-ID: <4F2025FC.7060407@suse.com>
Date: Wed, 25 Jan 2012 08:55:40 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: erin.balid@inoutbox.com
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
	<4F1F3B23.60304@suse.com>
	<1327456894.17114.140661027646361@webmail.messagingengine.com>
In-Reply-To: <1327456894.17114.140661027646361@webmail.messagingengine.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

erin.balid@inoutbox.com wrote:
> Hi Jim.
>
> Thanks for chiming in.
>
> On Tue, Jan 24, 2012, at 04:13 PM, Jim Fehlig wrote:
>   
>>> http://lists.opensuse.org/opensuse-features/2011-03/msg00212.html
>>>       
>> A mailing list to discuss openSUSE features, not an authoritative
>> resource on functionality in any given openSUSE release...
>>     
>
> It's been a big challenge finding anything that IS "an authoritative
> resource on functionality" for Xen in Opensuse.
>
> Where is the Opensuse-specific and Up-to-Date Xen documentation?  I
> guess we cant rely on xen.org docs for Opensuse's Xen?  Is it not really
> closely tied to the xen-devel project then?
>   

Generally speaking, xen.org documentation applies to the xen packages in
openSUSE.  In the case of toolstacks, openSUSE still enables the legacy
toolstack by default, and all upstream documentation wrt the legacy
toolstack applies.  You can use the new toolstack as well, in which case
the upstream xl/libxl documentation applies - including recommendation
that the toolstacks should not be used in parallel.

What you have described in this thread is a bug in openSUSE12.1.  You
followed the documentation and it didn't work :-).

> That leaves me back at my earlier question -- What are good docs for Xen
> on Opensuse?  I've wasted a lot of time - mine and other people's -
> doing what I was told (RTFM!) just to find out that 'real' Xen manual is
> the wrong one.
>   

I'm not sure what the problem is with the manual.  You've hit a bug I
introduced in openSUSE.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:56:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5D3-00008R-CI; Wed, 25 Jan 2012 15:56:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rq5D1-00007w-FE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:56:27 +0000
Received: from [85.158.138.51:25459] by server-7.bemta-3.messagelabs.com id
	0E/2F-31267-A26202F4; Wed, 25 Jan 2012 15:56:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327506985!5490081!1
X-Originating-IP: [74.125.82.176]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8784 invoked from network); 25 Jan 2012 15:56:25 -0000
Received: from mail-we0-f176.google.com (HELO mail-we0-f176.google.com)
	(74.125.82.176)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:56:25 -0000
Received: by wejx9 with SMTP id x9so3275630wej.7
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 07:56:25 -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=Nl0GDiev5/F523F5zYr96jorp5bsc1ABPSrPwYPS094=;
	b=d+KcE2dYwtHHwbGaJMXu2RCcwAeFM3m/I5YR1exPjY1VFG1cxz01w71b83TLjC5dKn
	k1SDypSoNWvqIONueNT3njIIW4fm4y4T7BRhuPyiIoeiD75DaAdzOin6Vyh5b70F+pIw
	uScVj8Le6/wong/tjyG1Oy4GzUrY3hyImtL+w=
Received: by 10.216.131.91 with SMTP id l69mr3036899wei.28.1327506985370;
	Wed, 25 Jan 2012 07:56:25 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id u12sm530859wiv.10.2012.01.25.07.56.23
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 07:56:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jan 2012 15:56:20 +0000
From: Keir Fraser <keir@xen.org>
To: Wei Liu <wei.liu2@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Message-ID: <CB45D6A4.382EE%keir@xen.org>
Thread-Topic: [PATCH V2] Add a GNTTABOP to swap the content of two grant
	references under lock provided that they are not currently active.
Thread-Index: AczbeeEKNXBdTNDMwUq4qc9EjL8DoA==
In-Reply-To: <1327506721.2318.2.camel@leeni.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH V2] Add a GNTTABOP to swap the content of
 two grant references under lock provided that they are not currently
 active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/01/2012 15:52, "Wei Liu" <wei.liu2@citrix.com> wrote:

> Keir, ping?

It is already checked in.

 -- Keir

> And got a SOB from Paul:
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> On Mon, 2012-01-23 at 13:56 +0000, Wei Liu (Intern) wrote:
>> Fix issues commented by Jan - coding style, stubs and variable types.
>> 
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> ---
>>  xen/arch/x86/hvm/hvm.c           |    1 +
>>  xen/common/compat/grant_table.c  |    8 +++
>>  xen/common/grant_table.c         |   89
>> ++++++++++++++++++++++++++++++++++++++
>>  xen/include/public/grant_table.h |   18 +++++++-
>>  xen/include/xlat.lst             |    1 +
>>  5 files changed, 115 insertions(+), 2 deletions(-)
>> 
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index b3d9ac0..c46bd3e 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int cmd)
>>      case GNTTABOP_copy:
>>      case GNTTABOP_map_grant_ref:
>>      case GNTTABOP_unmap_grant_ref:
>> +    case GNTTABOP_swap_grant_ref:
>>          return 1;
>>      default:
>>          /* all other commands need auditing */
>> diff --git a/xen/common/compat/grant_table.c
>> b/xen/common/compat/grant_table.c
>> index ca60395..edd20c6 100644
>> --- a/xen/common/compat/grant_table.c
>> +++ b/xen/common/compat/grant_table.c
>> @@ -47,6 +47,10 @@
>> DEFINE_XEN_GUEST_HANDLE(gnttab_get_status_frames_compat_t);
>>  CHECK_gnttab_get_version;
>>  #undef xen_gnttab_get_version
>>  
>> +#define xen_gnttab_swap_grant_ref gnttab_swap_grant_ref
>> +CHECK_gnttab_swap_grant_ref;
>> +#undef xen_gnttab_swap_grant_ref
>> +
>>  int compat_grant_table_op(unsigned int cmd,
>>                            XEN_GUEST_HANDLE(void) cmp_uop,
>>                            unsigned int count)
>> @@ -98,6 +102,10 @@ int compat_grant_table_op(unsigned int cmd,
>>      CASE(get_status_frames);
>>  #endif
>>  
>> +#ifndef CHECK_gnttab_swap_grant_ref
>> +    CASE(swap_grant_ref);
>> +#endif
>> +
>>  #undef CASE
>>      default:
>>          return do_grant_table_op(cmd, cmp_uop, count);
>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> index 34a49db..2683324 100644
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -2282,6 +2282,81 @@
>> gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
>>      return 0;
>>  }
>>  
>> +static s16
>> +__gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
>> +{
>> +    struct domain *d;
>> +    struct active_grant_entry *act;
>> +    s16 rc = GNTST_okay;
>> +
>> +    d = rcu_lock_current_domain();
>> +
>> +    spin_lock(&d->grant_table->lock);
>> +
>> +    act = &active_entry(d->grant_table, ref_a);
>> +    if ( act->pin )
>> +        PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
>> +
>> +    act = &active_entry(d->grant_table, ref_b);
>> +    if ( act->pin )
>> +        PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
>> +
>> +    if ( d->grant_table->gt_version == 1 )
>> +    {
>> +        grant_entry_v1_t shared;
>> +
>> +        shared = shared_entry_v1(d->grant_table, ref_a);
>> +
>> +        shared_entry_v1(d->grant_table, ref_a) =
>> +            shared_entry_v1(d->grant_table, ref_b);
>> +
>> +        shared_entry_v1(d->grant_table, ref_b) = shared;
>> +    }
>> +    else
>> +    {
>> +        grant_entry_v2_t shared;
>> +        grant_status_t status;
>> +
>> +        shared = shared_entry_v2(d->grant_table, ref_a);
>> +        status = status_entry(d->grant_table, ref_a);
>> +
>> +        shared_entry_v2(d->grant_table, ref_a) =
>> +            shared_entry_v2(d->grant_table, ref_b);
>> +        status_entry(d->grant_table, ref_a) =
>> +            status_entry(d->grant_table, ref_b);
>> +
>> +        shared_entry_v2(d->grant_table, ref_b) = shared;
>> +        status_entry(d->grant_table, ref_b) = status;
>> +    }
>> +
>> +out:
>> +    spin_unlock(&d->grant_table->lock);
>> +
>> +    rcu_unlock_domain(d);
>> +
>> +    return rc;
>> +}
>> +
>> +static long
>> +gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
>> +                      unsigned int count)
>> +{
>> +    int i;
>> +    gnttab_swap_grant_ref_t op;
>> +
>> +    for ( i = 0; i < count; i++ )
>> +    {
>> +        if ( i && hypercall_preempt_check() )
>> +            return i;
>> +        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
>> +            return -EFAULT;
>> +        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
>> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
>> +            return -EFAULT;
>> +    }
>> +    return 0;
>> +}
>> +
>>  long
>>  do_grant_table_op(
>>      unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
>> @@ -2400,6 +2475,20 @@ do_grant_table_op(
>>          rc = gnttab_get_version(guest_handle_cast(uop,
>> gnttab_get_version_t));
>>          break;
>>      }
>> +    case GNTTABOP_swap_grant_ref:
>> +    {
>> +        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
>> +            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
>> +        if ( unlikely(!guest_handle_okay(swap, count)) )
>> +            goto out;
>> +        rc = gnttab_swap_grant_ref(swap, count);
>> +        if ( rc > 0 )
>> +        {
>> +            guest_handle_add_offset(swap, rc);
>> +            uop = guest_handle_cast(swap, void);
>> +        }
>> +        break;
>> +    }
>>      default:
>>          rc = -ENOSYS;
>>          break;
>> diff --git a/xen/include/public/grant_table.h
>> b/xen/include/public/grant_table.h
>> index 0bf20bc..54d9551 100644
>> --- a/xen/include/public/grant_table.h
>> +++ b/xen/include/public/grant_table.h
>> @@ -511,6 +511,20 @@ struct gnttab_get_version {
>>  typedef struct gnttab_get_version gnttab_get_version_t;
>>  DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>>  
>> +/* 
>> + * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
>> + */
>> +#define GNTTABOP_swap_grant_ref       11
>> +struct gnttab_swap_grant_ref {
>> +    /* IN parameters */
>> +    grant_ref_t ref_a;
>> +    grant_ref_t ref_b;
>> +    /* OUT parameters */
>> +    int16_t status;             /* GNTST_* */
>> +};
>> +typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
>> +DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
>> +
>>  #endif /* __XEN_INTERFACE_VERSION__ */
>>  
>>  /*
>> @@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>>  #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 GNTST_eagain          (-12) /* Operation not done; try again.
>> */
>>  
>>  #define GNTTABOP_error_msgs {                   \
>>      "okay",                                     \
>> @@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>>      "bad page",                                 \
>>      "copy arguments cross page boundary",       \
>>      "page address size too large",              \
>> -    "could not map at the moment, retry"        \
>> +    "operation not done; try again"             \
>>  }
>>  
>>  #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
>> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
>> index 3d92175..f602155 100644
>> --- a/xen/include/xlat.lst
>> +++ b/xen/include/xlat.lst
>> @@ -50,6 +50,7 @@
>>  ? grant_entry_v1   grant_table.h
>>  ?       grant_entry_header              grant_table.h
>>  ? grant_entry_v2   grant_table.h
>> +? gnttab_swap_grant_ref  grant_table.h
>>  ? kexec_exec   kexec.h
>>  ! kexec_image   kexec.h
>>  ! kexec_range   kexec.h
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 15:56:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 15:56:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5D3-00008R-CI; Wed, 25 Jan 2012 15:56:29 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rq5D1-00007w-FE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 15:56:27 +0000
Received: from [85.158.138.51:25459] by server-7.bemta-3.messagelabs.com id
	0E/2F-31267-A26202F4; Wed, 25 Jan 2012 15:56:26 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327506985!5490081!1
X-Originating-IP: [74.125.82.176]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8784 invoked from network); 25 Jan 2012 15:56:25 -0000
Received: from mail-we0-f176.google.com (HELO mail-we0-f176.google.com)
	(74.125.82.176)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 15:56:25 -0000
Received: by wejx9 with SMTP id x9so3275630wej.7
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 07:56:25 -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=Nl0GDiev5/F523F5zYr96jorp5bsc1ABPSrPwYPS094=;
	b=d+KcE2dYwtHHwbGaJMXu2RCcwAeFM3m/I5YR1exPjY1VFG1cxz01w71b83TLjC5dKn
	k1SDypSoNWvqIONueNT3njIIW4fm4y4T7BRhuPyiIoeiD75DaAdzOin6Vyh5b70F+pIw
	uScVj8Le6/wong/tjyG1Oy4GzUrY3hyImtL+w=
Received: by 10.216.131.91 with SMTP id l69mr3036899wei.28.1327506985370;
	Wed, 25 Jan 2012 07:56:25 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id u12sm530859wiv.10.2012.01.25.07.56.23
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 07:56:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jan 2012 15:56:20 +0000
From: Keir Fraser <keir@xen.org>
To: Wei Liu <wei.liu2@citrix.com>,
	xen-devel <xen-devel@lists.xensource.com>
Message-ID: <CB45D6A4.382EE%keir@xen.org>
Thread-Topic: [PATCH V2] Add a GNTTABOP to swap the content of two grant
	references under lock provided that they are not currently active.
Thread-Index: AczbeeEKNXBdTNDMwUq4qc9EjL8DoA==
In-Reply-To: <1327506721.2318.2.camel@leeni.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH V2] Add a GNTTABOP to swap the content of
 two grant references under lock provided that they are not currently
 active.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/01/2012 15:52, "Wei Liu" <wei.liu2@citrix.com> wrote:

> Keir, ping?

It is already checked in.

 -- Keir

> And got a SOB from Paul:
> 
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> 
> On Mon, 2012-01-23 at 13:56 +0000, Wei Liu (Intern) wrote:
>> Fix issues commented by Jan - coding style, stubs and variable types.
>> 
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> ---
>>  xen/arch/x86/hvm/hvm.c           |    1 +
>>  xen/common/compat/grant_table.c  |    8 +++
>>  xen/common/grant_table.c         |   89
>> ++++++++++++++++++++++++++++++++++++++
>>  xen/include/public/grant_table.h |   18 +++++++-
>>  xen/include/xlat.lst             |    1 +
>>  5 files changed, 115 insertions(+), 2 deletions(-)
>> 
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index b3d9ac0..c46bd3e 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -2857,6 +2857,7 @@ static int grant_table_op_is_allowed(unsigned int cmd)
>>      case GNTTABOP_copy:
>>      case GNTTABOP_map_grant_ref:
>>      case GNTTABOP_unmap_grant_ref:
>> +    case GNTTABOP_swap_grant_ref:
>>          return 1;
>>      default:
>>          /* all other commands need auditing */
>> diff --git a/xen/common/compat/grant_table.c
>> b/xen/common/compat/grant_table.c
>> index ca60395..edd20c6 100644
>> --- a/xen/common/compat/grant_table.c
>> +++ b/xen/common/compat/grant_table.c
>> @@ -47,6 +47,10 @@
>> DEFINE_XEN_GUEST_HANDLE(gnttab_get_status_frames_compat_t);
>>  CHECK_gnttab_get_version;
>>  #undef xen_gnttab_get_version
>>  
>> +#define xen_gnttab_swap_grant_ref gnttab_swap_grant_ref
>> +CHECK_gnttab_swap_grant_ref;
>> +#undef xen_gnttab_swap_grant_ref
>> +
>>  int compat_grant_table_op(unsigned int cmd,
>>                            XEN_GUEST_HANDLE(void) cmp_uop,
>>                            unsigned int count)
>> @@ -98,6 +102,10 @@ int compat_grant_table_op(unsigned int cmd,
>>      CASE(get_status_frames);
>>  #endif
>>  
>> +#ifndef CHECK_gnttab_swap_grant_ref
>> +    CASE(swap_grant_ref);
>> +#endif
>> +
>>  #undef CASE
>>      default:
>>          return do_grant_table_op(cmd, cmp_uop, count);
>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> index 34a49db..2683324 100644
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -2282,6 +2282,81 @@
>> gnttab_get_version(XEN_GUEST_HANDLE(gnttab_get_version_t uop))
>>      return 0;
>>  }
>>  
>> +static s16
>> +__gnttab_swap_grant_ref(grant_ref_t ref_a, grant_ref_t ref_b)
>> +{
>> +    struct domain *d;
>> +    struct active_grant_entry *act;
>> +    s16 rc = GNTST_okay;
>> +
>> +    d = rcu_lock_current_domain();
>> +
>> +    spin_lock(&d->grant_table->lock);
>> +
>> +    act = &active_entry(d->grant_table, ref_a);
>> +    if ( act->pin )
>> +        PIN_FAIL(out, GNTST_eagain, "ref a %ld busy\n", (long)ref_a);
>> +
>> +    act = &active_entry(d->grant_table, ref_b);
>> +    if ( act->pin )
>> +        PIN_FAIL(out, GNTST_eagain, "ref b %ld busy\n", (long)ref_b);
>> +
>> +    if ( d->grant_table->gt_version == 1 )
>> +    {
>> +        grant_entry_v1_t shared;
>> +
>> +        shared = shared_entry_v1(d->grant_table, ref_a);
>> +
>> +        shared_entry_v1(d->grant_table, ref_a) =
>> +            shared_entry_v1(d->grant_table, ref_b);
>> +
>> +        shared_entry_v1(d->grant_table, ref_b) = shared;
>> +    }
>> +    else
>> +    {
>> +        grant_entry_v2_t shared;
>> +        grant_status_t status;
>> +
>> +        shared = shared_entry_v2(d->grant_table, ref_a);
>> +        status = status_entry(d->grant_table, ref_a);
>> +
>> +        shared_entry_v2(d->grant_table, ref_a) =
>> +            shared_entry_v2(d->grant_table, ref_b);
>> +        status_entry(d->grant_table, ref_a) =
>> +            status_entry(d->grant_table, ref_b);
>> +
>> +        shared_entry_v2(d->grant_table, ref_b) = shared;
>> +        status_entry(d->grant_table, ref_b) = status;
>> +    }
>> +
>> +out:
>> +    spin_unlock(&d->grant_table->lock);
>> +
>> +    rcu_unlock_domain(d);
>> +
>> +    return rc;
>> +}
>> +
>> +static long
>> +gnttab_swap_grant_ref(XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t uop),
>> +                      unsigned int count)
>> +{
>> +    int i;
>> +    gnttab_swap_grant_ref_t op;
>> +
>> +    for ( i = 0; i < count; i++ )
>> +    {
>> +        if ( i && hypercall_preempt_check() )
>> +            return i;
>> +        if ( unlikely(__copy_from_guest_offset(&op, uop, i, 1)) )
>> +            return -EFAULT;
>> +        op.status = __gnttab_swap_grant_ref(op.ref_a, op.ref_b);
>> +        if ( unlikely(__copy_to_guest_offset(uop, i, &op, 1)) )
>> +            return -EFAULT;
>> +    }
>> +    return 0;
>> +}
>> +
>>  long
>>  do_grant_table_op(
>>      unsigned int cmd, XEN_GUEST_HANDLE(void) uop, unsigned int count)
>> @@ -2400,6 +2475,20 @@ do_grant_table_op(
>>          rc = gnttab_get_version(guest_handle_cast(uop,
>> gnttab_get_version_t));
>>          break;
>>      }
>> +    case GNTTABOP_swap_grant_ref:
>> +    {
>> +        XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t) swap =
>> +            guest_handle_cast(uop, gnttab_swap_grant_ref_t);
>> +        if ( unlikely(!guest_handle_okay(swap, count)) )
>> +            goto out;
>> +        rc = gnttab_swap_grant_ref(swap, count);
>> +        if ( rc > 0 )
>> +        {
>> +            guest_handle_add_offset(swap, rc);
>> +            uop = guest_handle_cast(swap, void);
>> +        }
>> +        break;
>> +    }
>>      default:
>>          rc = -ENOSYS;
>>          break;
>> diff --git a/xen/include/public/grant_table.h
>> b/xen/include/public/grant_table.h
>> index 0bf20bc..54d9551 100644
>> --- a/xen/include/public/grant_table.h
>> +++ b/xen/include/public/grant_table.h
>> @@ -511,6 +511,20 @@ struct gnttab_get_version {
>>  typedef struct gnttab_get_version gnttab_get_version_t;
>>  DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>>  
>> +/* 
>> + * GNTTABOP_swap_grant_ref: Swap the contents of two grant entries.
>> + */
>> +#define GNTTABOP_swap_grant_ref       11
>> +struct gnttab_swap_grant_ref {
>> +    /* IN parameters */
>> +    grant_ref_t ref_a;
>> +    grant_ref_t ref_b;
>> +    /* OUT parameters */
>> +    int16_t status;             /* GNTST_* */
>> +};
>> +typedef struct gnttab_swap_grant_ref gnttab_swap_grant_ref_t;
>> +DEFINE_XEN_GUEST_HANDLE(gnttab_swap_grant_ref_t);
>> +
>>  #endif /* __XEN_INTERFACE_VERSION__ */
>>  
>>  /*
>> @@ -566,7 +580,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>>  #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 GNTST_eagain          (-12) /* Operation not done; try again.
>> */
>>  
>>  #define GNTTABOP_error_msgs {                   \
>>      "okay",                                     \
>> @@ -581,7 +595,7 @@ DEFINE_XEN_GUEST_HANDLE(gnttab_get_version_t);
>>      "bad page",                                 \
>>      "copy arguments cross page boundary",       \
>>      "page address size too large",              \
>> -    "could not map at the moment, retry"        \
>> +    "operation not done; try again"             \
>>  }
>>  
>>  #endif /* __XEN_PUBLIC_GRANT_TABLE_H__ */
>> diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
>> index 3d92175..f602155 100644
>> --- a/xen/include/xlat.lst
>> +++ b/xen/include/xlat.lst
>> @@ -50,6 +50,7 @@
>>  ? grant_entry_v1   grant_table.h
>>  ?       grant_entry_header              grant_table.h
>>  ? grant_entry_v2   grant_table.h
>> +? gnttab_swap_grant_ref  grant_table.h
>>  ? kexec_exec   kexec.h
>>  ! kexec_image   kexec.h
>>  ! kexec_range   kexec.h
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:03:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq5Jm-0000vs-9N; Wed, 25 Jan 2012 16:03:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq5Jl-0000vn-7g
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327507353!50050971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26423 invoked from network); 25 Jan 2012 16:02:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:02:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10286091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:03:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 16:03:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	Fraser" <keir@xen.org>
Date: Wed, 25 Jan 2012 16:03:14 +0000
In-Reply-To: <E1Rq5Bp-0000Bb-9U@xenbits.xen.org>
References: <E1Rq5Bp-0000Bb-9U@xenbits.xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327507396.24561.341.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] docs: Remove outdated LaTex documentation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 15:55 +0000, Xen patchbot-unstable wrote:
> # HG changeset patch
> # User Keir Fraser <keir@xen.org>
> # Date 1327506767 0
> # Node ID 4271634e4c86568b6bf2241ebf9be4a82ab430bf
> # Parent  a2a8089b1ffbf5757ca3191cb8f74a5f1ed7fed1
> docs: Remove outdated LaTex documentation.

Nice.

> @@ -82,7 +70,7 @@
>         $(MAKE) -C xen-api clean
>         rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~
>         rm -rf *.ilg *.log *.ind *.toc *.bak core

I'd hazard a guess that all of these, apart from *~, are latex droppings
too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:03:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq5Jm-0000vs-9N; Wed, 25 Jan 2012 16:03:26 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq5Jl-0000vn-7g
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:03:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327507353!50050971!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26423 invoked from network); 25 Jan 2012 16:02:33 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:02:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320624000"; d="scan'208";a="10286091"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:03:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 16:03:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	Fraser" <keir@xen.org>
Date: Wed, 25 Jan 2012 16:03:14 +0000
In-Reply-To: <E1Rq5Bp-0000Bb-9U@xenbits.xen.org>
References: <E1Rq5Bp-0000Bb-9U@xenbits.xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327507396.24561.341.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: Re: [Xen-devel] docs: Remove outdated LaTex documentation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 15:55 +0000, Xen patchbot-unstable wrote:
> # HG changeset patch
> # User Keir Fraser <keir@xen.org>
> # Date 1327506767 0
> # Node ID 4271634e4c86568b6bf2241ebf9be4a82ab430bf
> # Parent  a2a8089b1ffbf5757ca3191cb8f74a5f1ed7fed1
> docs: Remove outdated LaTex documentation.

Nice.

> @@ -82,7 +70,7 @@
>         $(MAKE) -C xen-api clean
>         rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~
>         rm -rf *.ilg *.log *.ind *.toc *.bak core

I'd hazard a guess that all of these, apart from *~, are latex droppings
too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:06:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5Mi-00011z-So; Wed, 25 Jan 2012 16:06: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 1Rq5Mh-00011r-Ke
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:06:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327507523!58392566!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27248 invoked from network); 25 Jan 2012 16:05:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:05:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="21273628"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:06:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 11:06:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0PG6B60006122;
	Wed, 25 Jan 2012 08:06:12 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 16:07:04 +0000
Message-ID: <1327507624-1914-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: anthony.perard@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl_qmp: fix qmp_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

qmp_next doesn't handle multiple lines read together in a single buffer
correctly at the moment.
This patch fixes it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_qmp.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f77365b..41a12ad 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -412,17 +412,18 @@ do_select_again:
             char *end = NULL;
             if (incomplete) {
                 size_t current_pos = s - incomplete;
-                incomplete_size += rd;
                 incomplete = libxl__realloc(gc, incomplete,
-                                            incomplete_size + 1);
-                incomplete = strncat(incomplete, qmp->buffer, rd);
+                                            incomplete_size + rd);
+                strncat(incomplete + incomplete_size, qmp->buffer, rd);
                 s = incomplete + current_pos;
+                incomplete_size += rd;
                 s_end = incomplete + incomplete_size;
             } else {
                 incomplete = libxl__strndup(gc, qmp->buffer, rd);
                 incomplete_size = rd;
                 s = incomplete;
                 s_end = s + rd;
+                rd = 0;
             }
 
             end = strstr(s, "\r\n");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:06:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:06:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5Mi-00011z-So; Wed, 25 Jan 2012 16:06: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 1Rq5Mh-00011r-Ke
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:06:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327507523!58392566!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27248 invoked from network); 25 Jan 2012 16:05:24 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:05:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="21273628"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:06:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 11:06:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0PG6B60006122;
	Wed, 25 Jan 2012 08:06:12 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 16:07:04 +0000
Message-ID: <1327507624-1914-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: anthony.perard@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] libxl_qmp: fix qmp_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

qmp_next doesn't handle multiple lines read together in a single buffer
correctly at the moment.
This patch fixes it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_qmp.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index f77365b..41a12ad 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -412,17 +412,18 @@ do_select_again:
             char *end = NULL;
             if (incomplete) {
                 size_t current_pos = s - incomplete;
-                incomplete_size += rd;
                 incomplete = libxl__realloc(gc, incomplete,
-                                            incomplete_size + 1);
-                incomplete = strncat(incomplete, qmp->buffer, rd);
+                                            incomplete_size + rd);
+                strncat(incomplete + incomplete_size, qmp->buffer, rd);
                 s = incomplete + current_pos;
+                incomplete_size += rd;
                 s_end = incomplete + incomplete_size;
             } else {
                 incomplete = libxl__strndup(gc, qmp->buffer, rd);
                 incomplete_size = rd;
                 s = incomplete;
                 s_end = s + rd;
+                rd = 0;
             }
 
             end = strstr(s, "\r\n");
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:18:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq5YQ-0001Hg-84; Wed, 25 Jan 2012 16:18:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Rq5YN-0001Hb-HY
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:18:32 +0000
Received: from [85.158.139.83:15135] by server-10.bemta-5.messagelabs.com id
	46/26-18919-65B202F4; Wed, 25 Jan 2012 16:18:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327508309!12334703!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODg1OTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 25 Jan 2012 16:18:30 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 16:18:30 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 4C9321465;
	Wed, 25 Jan 2012 18:18:28 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B263420057; Wed, 25 Jan 2012 18:18:28 +0200 (EET)
Date: Wed, 25 Jan 2012 18:18:28 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Pavel Mateja <pavel@netsafe.cz>
Message-ID: <20120125161828.GC12984@reaktio.net>
References: <201201171115.53993.pavel@netsafe.cz>
	<201201250926.45689.pavel@netsafe.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201201250926.45689.pavel@netsafe.cz>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 09:26:45AM +0100, Pavel Mateja wrote:
> > I can't hear sound in DomU. Hmm, to be honest I've heard some broken
> > pieces,..
> 
> Problem found:
> You can't load linux ALSA driver before you pass the sound card to the virtual 
> machine. Since I removed linux kernel driver Windows play sounds just fine.
>

Thanks for the update. And that's quite obvious reason..
naturally you can't use a single PCI device in multiple domains at the same time.

PCI passthru *dedicates* the device to specific domain, so it can only be used in that domain.
If dom0 is trying to use it aswell, things will go wrong.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:18:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq5YQ-0001Hg-84; Wed, 25 Jan 2012 16:18:34 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pasik@iki.fi>) id 1Rq5YN-0001Hb-HY
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:18:32 +0000
Received: from [85.158.139.83:15135] by server-10.bemta-5.messagelabs.com id
	46/26-18919-65B202F4; Wed, 25 Jan 2012 16:18:30 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327508309!12334703!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzODg1OTM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20168 invoked from network); 25 Jan 2012 16:18:30 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-11.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 16:18:30 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id 4C9321465;
	Wed, 25 Jan 2012 18:18:28 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id B263420057; Wed, 25 Jan 2012 18:18:28 +0200 (EET)
Date: Wed, 25 Jan 2012 18:18:28 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Pavel Mateja <pavel@netsafe.cz>
Message-ID: <20120125161828.GC12984@reaktio.net>
References: <201201171115.53993.pavel@netsafe.cz>
	<201201250926.45689.pavel@netsafe.cz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201201250926.45689.pavel@netsafe.cz>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 09:26:45AM +0100, Pavel Mateja wrote:
> > I can't hear sound in DomU. Hmm, to be honest I've heard some broken
> > pieces,..
> 
> Problem found:
> You can't load linux ALSA driver before you pass the sound card to the virtual 
> machine. Since I removed linux kernel driver Windows play sounds just fine.
>

Thanks for the update. And that's quite obvious reason..
naturally you can't use a single PCI device in multiple domains at the same time.

PCI passthru *dedicates* the device to specific domain, so it can only be used in that domain.
If dom0 is trying to use it aswell, things will go wrong.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:19:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5ZN-0001Lh-NC; Wed, 25 Jan 2012 16:19:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq5ZM-0001LY-Rt
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:19:33 +0000
Received: from [85.158.138.51:57704] by server-5.bemta-3.messagelabs.com id
	30/C0-02363-49B202F4; Wed, 25 Jan 2012 16:19:32 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327508369!10644201!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6575 invoked from network); 25 Jan 2012 16:19:31 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:19:31 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 09:19:23 -0700
Message-ID: <4F202B8A.4060506@suse.com>
Date: Wed, 25 Jan 2012 09:19:22 -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: <1327176409.25269.140661026313477@webmail.messagingengine.com>	<1327318076.24561.63.camel@zakaz.uk.xensource.com>	<1327332514.25697.140661026919117@webmail.messagingengine.com>	<1327415184.24561.182.camel@zakaz.uk.xensource.com>	<1327420611.19936.140661027415609@webmail.messagingengine.com>	<1327423312.24561.211.camel@zakaz.uk.xensource.com>	<1327425015.8709.140661027442201@webmail.messagingengine.com>	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327440026.17019.16.camel@dagon.hellion.org.uk>
In-Reply-To: <1327440026.17019.16.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Tue, 2012-01-24 at 18:05 +0000, erin.balid@inoutbox.com wrote:
>   
>> Using the same log redirection you mentioned before
>>
>> edit /etc/xen/scripts/vif-bridge
>> 	#!/bin/bash
>> +       exec 1>>/tmp/vif-bridge.log
>> +       exec 2>&1
>> +       echo "`date`: Running $0 $*"
>> ...
>> +       ## TEST ##
>> +       echo "made it to 001"
>>
>> 	dir=$(dirname "$0")
>> 	. "$dir/vif-common.sh"
>>
>> +       ## TEST ##
>> +       echo "made it to 002"
>>
>>
>> 	domu=$(xenstore_read_default "$XENBUS_PATH/domain" "")
>> 	if [ -z "$domu" ]
>> 	then
>> 	    log debug "No device details in $XENBUS_PATH, exiting."
>>     
>
> So, presumably either the xenstore_read_default is failing or domu is
> zero length and the script is explicitly bailing here.
>
> However I do not see anything like this anywhere in the hotplug script
> shipped with Xen. Either this is a local modification or something done
> by your distribution, in which case you should contact them.
>   

Grrr, that is my patch here

http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html

which thankfully was never applied upstream but did make its way into
openSUSE12.1.  In that thread, Ian suggested having the toolstack write
the literal tap device name to xenstore and then read it in the vif
script.  I have this on my todo list with very low priority, but seems I
should bump it now :-).

> What does this node contain under xend?
>   

The xend toolstack writes the domain name under this node but xl/libxl
doesn't, hence the failure Erin is seeing.

Erin, you can revert the patch mentioned above to fix your problem. 
I'll try to work on the proper fix soon.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:19:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:19:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5ZN-0001Lh-NC; Wed, 25 Jan 2012 16:19:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq5ZM-0001LY-Rt
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:19:33 +0000
Received: from [85.158.138.51:57704] by server-5.bemta-3.messagelabs.com id
	30/C0-02363-49B202F4; Wed, 25 Jan 2012 16:19:32 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327508369!10644201!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6575 invoked from network); 25 Jan 2012 16:19:31 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-4.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:19:31 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 09:19:23 -0700
Message-ID: <4F202B8A.4060506@suse.com>
Date: Wed, 25 Jan 2012 09:19:22 -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: <1327176409.25269.140661026313477@webmail.messagingengine.com>	<1327318076.24561.63.camel@zakaz.uk.xensource.com>	<1327332514.25697.140661026919117@webmail.messagingengine.com>	<1327415184.24561.182.camel@zakaz.uk.xensource.com>	<1327420611.19936.140661027415609@webmail.messagingengine.com>	<1327423312.24561.211.camel@zakaz.uk.xensource.com>	<1327425015.8709.140661027442201@webmail.messagingengine.com>	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327440026.17019.16.camel@dagon.hellion.org.uk>
In-Reply-To: <1327440026.17019.16.camel@dagon.hellion.org.uk>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Tue, 2012-01-24 at 18:05 +0000, erin.balid@inoutbox.com wrote:
>   
>> Using the same log redirection you mentioned before
>>
>> edit /etc/xen/scripts/vif-bridge
>> 	#!/bin/bash
>> +       exec 1>>/tmp/vif-bridge.log
>> +       exec 2>&1
>> +       echo "`date`: Running $0 $*"
>> ...
>> +       ## TEST ##
>> +       echo "made it to 001"
>>
>> 	dir=$(dirname "$0")
>> 	. "$dir/vif-common.sh"
>>
>> +       ## TEST ##
>> +       echo "made it to 002"
>>
>>
>> 	domu=$(xenstore_read_default "$XENBUS_PATH/domain" "")
>> 	if [ -z "$domu" ]
>> 	then
>> 	    log debug "No device details in $XENBUS_PATH, exiting."
>>     
>
> So, presumably either the xenstore_read_default is failing or domu is
> zero length and the script is explicitly bailing here.
>
> However I do not see anything like this anywhere in the hotplug script
> shipped with Xen. Either this is a local modification or something done
> by your distribution, in which case you should contact them.
>   

Grrr, that is my patch here

http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html

which thankfully was never applied upstream but did make its way into
openSUSE12.1.  In that thread, Ian suggested having the toolstack write
the literal tap device name to xenstore and then read it in the vif
script.  I have this on my todo list with very low priority, but seems I
should bump it now :-).

> What does this node contain under xend?
>   

The xend toolstack writes the domain name under this node but xl/libxl
doesn't, hence the failure Erin is seeing.

Erin, you can revert the patch mentioned above to fix your problem. 
I'll try to work on the proper fix soon.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:25:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5ec-0001nE-Hg; Wed, 25 Jan 2012 16:24:58 +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 1Rq5ea-0001n1-TU
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:24:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327508690!8307214!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29917 invoked from network); 25 Jan 2012 16:24:51 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:24:51 -0000
Received: by werb14 with SMTP id b14so13999383wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 08:24:50 -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=XDuZ7djE+KgdMZiQ060cihTkUwqCULALTLootN93u5Q=;
	b=xc4CBnsNODkHxDoq4eF0JTak4d2RZlcC1WJ2Q5mv7D+sQXOvbAJqbwb8qZa9ui/JCC
	NFhRZWsv1p/XEEF3YhZESIoH4+kWQx8aAl4YQkUi98GD6pwArZ41Umn5d4kxswnbJz7w
	IdY0FJxFNvxt9L7tLZt7O7QgyGgLkxYtIxjUk=
Received: by 10.216.137.7 with SMTP id x7mr3053385wei.52.1327508690795;
	Wed, 25 Jan 2012 08:24:50 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id df2sm703976wib.4.2012.01.25.08.24.48
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 08:24:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jan 2012 16:24:46 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB45DD4E.382F9%keir@xen.org>
Thread-Topic: docs: Remove outdated LaTex documentation.
Thread-Index: AczbfdnlgMJx/lYcw0eckKPUJ7ExPA==
In-Reply-To: <1327507396.24561.341.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] docs: Remove outdated LaTex documentation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/01/2012 16:03, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> @@ -82,7 +70,7 @@
>>         $(MAKE) -C xen-api clean
>>         rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~
>>         rm -rf *.ilg *.log *.ind *.toc *.bak core
> 
> I'd hazard a guess that all of these, apart from *~, are latex droppings
> too.

Yeah, agreed. I couldn't be bothered checking, and it was harmless to leave
them. ;-)

 K.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:25:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:25:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5ec-0001nE-Hg; Wed, 25 Jan 2012 16:24:58 +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 1Rq5ea-0001n1-TU
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:24:57 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327508690!8307214!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29917 invoked from network); 25 Jan 2012 16:24:51 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:24:51 -0000
Received: by werb14 with SMTP id b14so13999383wer.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 08:24:50 -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=XDuZ7djE+KgdMZiQ060cihTkUwqCULALTLootN93u5Q=;
	b=xc4CBnsNODkHxDoq4eF0JTak4d2RZlcC1WJ2Q5mv7D+sQXOvbAJqbwb8qZa9ui/JCC
	NFhRZWsv1p/XEEF3YhZESIoH4+kWQx8aAl4YQkUi98GD6pwArZ41Umn5d4kxswnbJz7w
	IdY0FJxFNvxt9L7tLZt7O7QgyGgLkxYtIxjUk=
Received: by 10.216.137.7 with SMTP id x7mr3053385wei.52.1327508690795;
	Wed, 25 Jan 2012 08:24:50 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id df2sm703976wib.4.2012.01.25.08.24.48
	(version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 08:24:49 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Wed, 25 Jan 2012 16:24:46 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB45DD4E.382F9%keir@xen.org>
Thread-Topic: docs: Remove outdated LaTex documentation.
Thread-Index: AczbfdnlgMJx/lYcw0eckKPUJ7ExPA==
In-Reply-To: <1327507396.24561.341.camel@zakaz.uk.xensource.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] docs: Remove outdated LaTex documentation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 25/01/2012 16:03, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:

>> @@ -82,7 +70,7 @@
>>         $(MAKE) -C xen-api clean
>>         rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~
>>         rm -rf *.ilg *.log *.ind *.toc *.bak core
> 
> I'd hazard a guess that all of these, apart from *~, are latex droppings
> too.

Yeah, agreed. I couldn't be bothered checking, and it was harmless to leave
them. ;-)

 K.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:27:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5gj-0001wy-8b; Wed, 25 Jan 2012 16:27:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rq5gh-0001wj-Lk
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:27:08 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327508820!8721650!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDI5NTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14771 invoked from network); 25 Jan 2012 16:27:01 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:27:01 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 42EBB211C5
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 11:27:00 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute2.internal (MEProxy); Wed, 25 Jan 2012 11:27:00 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	+mm028ToC9ONUHVteyC47uZpEtw=; b=UgDme7pTTAPwI+KQT1A0v1b2HZ6Jki5i
	pYY1/WHP3RUGp3VdZEYMENG9CHbQnCX7jsYQIK8/2+27WTjPGvf8RJbyPqZCqUb7
	iEcZPAjV24RjgjNtgSUuk7K9fc3sBFmKgRoyAx2c87M8kt7OL0UyrvLwjbH04UgV
	vKrif10HPC0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=+mm028ToC9ONUHVteyC47uZpEtw=; b=C6V
	6qvWqh31B9fLxnsRbLbLPFgO3JXcxTFSWyuO1WtjwWN73oiWo4mGOBB8eT945MPP
	6XBtm5YTzSFkGBsAty3Qm/njeL4ghB9URSQoqtBDV3lHEga403UcNoWh8dICbLa6
	jgfGGZuF5ehTvGuJ+uAUaMHQx8lIMBL9Cty3hj8s=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 1F37FA0007B; Wed, 25 Jan 2012 11:27:00 -0500 (EST)
Message-Id: <1327508820.28123.140661027898793@webmail.messagingengine.com>
X-Sasl-Enc: Pe1AeiiI0Y+i7vFMUH6u3nzHVAclvu+TfIfonmJ4PJOu 1327508820
From: erin.balid@inoutbox.com
To: Jim Fehlig <jfehlig@suse.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <4F2025FC.7060407@suse.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
	<4F1F3B23.60304@suse.com>
	<1327456894.17114.140661027646361@webmail.messagingengine.com>
	<4F2025FC.7060407@suse.com>
Date: Wed, 25 Jan 2012 08:27:00 -0800
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Jim.

On Wed, Jan 25, 2012, at 08:55 AM, Jim Fehlig wrote:
> Generally speaking, xen.org documentation applies to the xen packages in openSUSE.

Okay then.  That simplifies life.  Thanks.

What will be the best place to track fixes to this issue in
Opensuse-land?  Xen-users list?  Opensuse-virtual list? I'd like to get
off _this_ list if possible.  I don't really fit here.  Unless it really
is the right forum to follow.

I got your comment that you'd look for fixes in the Opensuse 12.2
time-frame.  As I read the openSUSE Roadmap, the scheduled release date
for openSUSE 12.2 is July 2012.

We won't switch to a new OS release until after it's in production.  We
_are_ willing to use a few non-production repositories for key packages.
 Xen's one of them.

Should we plan to see these Xen fixes in a shorter timeframe in a repo
built for use with 12.1 release/kernel prior to that 12.2 release date? 
Or to meet our requirements, would you - or others here - suggest we get
onto a different OS+Xen stack?

Regards,

Erin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:27:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5gj-0001wy-8b; Wed, 25 Jan 2012 16:27:09 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <erin.balid@inoutbox.com>) id 1Rq5gh-0001wj-Lk
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:27:08 +0000
X-Env-Sender: erin.balid@inoutbox.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327508820!8721650!1
X-Originating-IP: [66.111.4.27]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTExLjQuMjcgPT4gNDI5NTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14771 invoked from network); 25 Jan 2012 16:27:01 -0000
Received: from out3-smtp.messagingengine.com (HELO
	out3-smtp.messagingengine.com) (66.111.4.27)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:27:01 -0000
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 42EBB211C5
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 11:27:00 -0500 (EST)
Received: from web1.nyi.mail.srv.osa ([10.202.2.211])
	by compute2.internal (MEProxy); Wed, 25 Jan 2012 11:27:00 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=inoutbox.com; h=
	message-id:from:to:cc:mime-version:content-transfer-encoding
	:content-type:in-reply-to:references:subject:date; s=mesmtp; bh=
	+mm028ToC9ONUHVteyC47uZpEtw=; b=UgDme7pTTAPwI+KQT1A0v1b2HZ6Jki5i
	pYY1/WHP3RUGp3VdZEYMENG9CHbQnCX7jsYQIK8/2+27WTjPGvf8RJbyPqZCqUb7
	iEcZPAjV24RjgjNtgSUuk7K9fc3sBFmKgRoyAx2c87M8kt7OL0UyrvLwjbH04UgV
	vKrif10HPC0=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:from:to:cc:mime-version
	:content-transfer-encoding:content-type:in-reply-to:references
	:subject:date; s=smtpout; bh=+mm028ToC9ONUHVteyC47uZpEtw=; b=C6V
	6qvWqh31B9fLxnsRbLbLPFgO3JXcxTFSWyuO1WtjwWN73oiWo4mGOBB8eT945MPP
	6XBtm5YTzSFkGBsAty3Qm/njeL4ghB9URSQoqtBDV3lHEga403UcNoWh8dICbLa6
	jgfGGZuF5ehTvGuJ+uAUaMHQx8lIMBL9Cty3hj8s=
Received: by web1.nyi.mail.srv.osa (Postfix, from userid 99)
	id 1F37FA0007B; Wed, 25 Jan 2012 11:27:00 -0500 (EST)
Message-Id: <1327508820.28123.140661027898793@webmail.messagingengine.com>
X-Sasl-Enc: Pe1AeiiI0Y+i7vFMUH6u3nzHVAclvu+TfIfonmJ4PJOu 1327508820
From: erin.balid@inoutbox.com
To: Jim Fehlig <jfehlig@suse.com>
MIME-Version: 1.0
X-Mailer: MessagingEngine.com Webmail Interface
In-Reply-To: <4F2025FC.7060407@suse.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
	<4F1F3B23.60304@suse.com>
	<1327456894.17114.140661027646361@webmail.messagingengine.com>
	<4F2025FC.7060407@suse.com>
Date: Wed, 25 Jan 2012 08:27:00 -0800
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 Jim.

On Wed, Jan 25, 2012, at 08:55 AM, Jim Fehlig wrote:
> Generally speaking, xen.org documentation applies to the xen packages in openSUSE.

Okay then.  That simplifies life.  Thanks.

What will be the best place to track fixes to this issue in
Opensuse-land?  Xen-users list?  Opensuse-virtual list? I'd like to get
off _this_ list if possible.  I don't really fit here.  Unless it really
is the right forum to follow.

I got your comment that you'd look for fixes in the Opensuse 12.2
time-frame.  As I read the openSUSE Roadmap, the scheduled release date
for openSUSE 12.2 is July 2012.

We won't switch to a new OS release until after it's in production.  We
_are_ willing to use a few non-production repositories for key packages.
 Xen's one of them.

Should we plan to see these Xen fixes in a shorter timeframe in a repo
built for use with 12.1 release/kernel prior to that 12.2 release date? 
Or to meet our requirements, would you - or others here - suggest we get
onto a different OS+Xen stack?

Regards,

Erin


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:29:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1Rq5iN-00023v-Oa; Wed, 25 Jan 2012 16:28:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq5iM-00023p-QZ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:28:50 +0000
Received: from [85.158.139.83:34766] by server-1.bemta-5.messagelabs.com id
	6E/3B-18433-2CD202F4; Wed, 25 Jan 2012 16:28:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327508927!12366390!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2169 invoked from network); 25 Jan 2012 16:28:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:28:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21274925"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:28: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; Wed, 25 Jan 2012 11:28:46 -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
	q0PGSigZ006182;	Wed, 25 Jan 2012 08:28:45 -0800
MIME-Version: 1.0
X-Mercurial-Node: 98b01cd24140a0899205c210b847aa1ec4a76efd
Message-ID: <98b01cd24140a0899205.1327508924@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 16:28:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] seabios: update to 1.6.3.1 release
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327508914 0
# Node ID 98b01cd24140a0899205c210b847aa1ec4a76efd
# Parent  074d485f1d3d925b0b306602c694b4faea8b0b18
seabios: update to 1.6.3.1 release

This is the latest seabios stable release.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/Config.mk b/Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -215,7 +215,7 @@ QEMU_UPSTREAM_URL ?= git://xenbits.xen.o
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
 QEMU_UPSTREAM_REVISION ?= master
-SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560
+SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:29:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 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 1Rq5iN-00023v-Oa; Wed, 25 Jan 2012 16:28:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq5iM-00023p-QZ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:28:50 +0000
Received: from [85.158.139.83:34766] by server-1.bemta-5.messagelabs.com id
	6E/3B-18433-2CD202F4; Wed, 25 Jan 2012 16:28:50 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327508927!12366390!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2169 invoked from network); 25 Jan 2012 16:28:48 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:28:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21274925"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 11:28: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; Wed, 25 Jan 2012 11:28:46 -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
	q0PGSigZ006182;	Wed, 25 Jan 2012 08:28:45 -0800
MIME-Version: 1.0
X-Mercurial-Node: 98b01cd24140a0899205c210b847aa1ec4a76efd
Message-ID: <98b01cd24140a0899205.1327508924@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 16:28:44 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH] seabios: update to 1.6.3.1 release
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327508914 0
# Node ID 98b01cd24140a0899205c210b847aa1ec4a76efd
# Parent  074d485f1d3d925b0b306602c694b4faea8b0b18
seabios: update to 1.6.3.1 release

This is the latest seabios stable release.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/Config.mk b/Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -215,7 +215,7 @@ QEMU_UPSTREAM_URL ?= git://xenbits.xen.o
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
 endif
 QEMU_UPSTREAM_REVISION ?= master
-SEABIOS_UPSTREAM_TAG ?= 7fc039e9c262b4199fab497f3e12f4e425c37560
+SEABIOS_UPSTREAM_TAG ?= rel-1.6.3.1
 
 # Specify which qemu-dm to use. This may be `ioemu' to use the old
 # Mercurial in-tree version, or a local directory, or a git URL.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:29:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq5j0-00027b-5y; Wed, 25 Jan 2012 16:29:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq5iy-00027N-RI
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:29:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327508947!63898993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12574 invoked from network); 25 Jan 2012 16:29:07 -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;
	25 Jan 2012 16:29:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10286766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:29: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;
	Wed, 25 Jan 2012 16:29:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 25 Jan 2012 16:29:27 +0000
In-Reply-To: <1326732775-15485-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
	<1326732775-15485-6-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327508967.24561.345.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 v10 6/7] libxl: use new qemu at the location
 where xen-unstable installs 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 Mon, 2012-01-16 at 16:52 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/libxl/libxl_dm.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 97d91b4..9d84b6f 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -58,7 +58,7 @@ const char *libxl__domain_device_model(libxl__gc *gc,
>              dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
>              break;
>          case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -            dm = libxl__strdup(gc, "/usr/bin/qemu");
> +            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());

The actual installed path (in staging tree now)
is /usr/lib/xen/bin/qemu-system-i386 so if I boot a guest with
device_model_version="qemu-xen" then, as you might expect, I get:
        libxl: error: libxl_dm.c:809:libxl__create_device_model: device model /usr/lib/xen/bin/qemu is not executable: No such file or directory
        libxl: error: libxl_create.c:579:do_domain_create: failed to create device model: -3
        libxl: error: libxl_dm.c:926:libxl__destroy_device_model: Couldn't find device model's pid: No such file or directory
        libxl: error: libxl.c:796:libxl_domain_destroy: libxl__destroy_device_model failed for 21

I can add device_model_override="/usr/lib/xen/bin/qemu-system-i386" and
then things work as expected.

Presumably if I build my tools for 64 bit it will be qemu-system-amd64.

So, should we fix libxl, the qemu build or our build integration?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:29:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq5j0-00027b-5y; Wed, 25 Jan 2012 16:29:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq5iy-00027N-RI
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:29:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327508947!63898993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12574 invoked from network); 25 Jan 2012 16:29:07 -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;
	25 Jan 2012 16:29:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10286766"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:29: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;
	Wed, 25 Jan 2012 16:29:27 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
Date: Wed, 25 Jan 2012 16:29:27 +0000
In-Reply-To: <1326732775-15485-6-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
	<1326732775-15485-6-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327508967.24561.345.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 v10 6/7] libxl: use new qemu at the location
 where xen-unstable installs 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 Mon, 2012-01-16 at 16:52 +0000, stefano.stabellini@eu.citrix.com
wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  tools/libxl/libxl_dm.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 97d91b4..9d84b6f 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -58,7 +58,7 @@ const char *libxl__domain_device_model(libxl__gc *gc,
>              dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
>              break;
>          case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> -            dm = libxl__strdup(gc, "/usr/bin/qemu");
> +            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());

The actual installed path (in staging tree now)
is /usr/lib/xen/bin/qemu-system-i386 so if I boot a guest with
device_model_version="qemu-xen" then, as you might expect, I get:
        libxl: error: libxl_dm.c:809:libxl__create_device_model: device model /usr/lib/xen/bin/qemu is not executable: No such file or directory
        libxl: error: libxl_create.c:579:do_domain_create: failed to create device model: -3
        libxl: error: libxl_dm.c:926:libxl__destroy_device_model: Couldn't find device model's pid: No such file or directory
        libxl: error: libxl.c:796:libxl_domain_destroy: libxl__destroy_device_model failed for 21

I can add device_model_override="/usr/lib/xen/bin/qemu-system-i386" and
then things work as expected.

Presumably if I build my tools for 64 bit it will be qemu-system-amd64.

So, should we fix libxl, the qemu build or our build integration?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:32:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5lp-0002N4-Pv; Wed, 25 Jan 2012 16:32:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq5ln-0002MS-SE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:32:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327509137!12536830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31215 invoked from network); 25 Jan 2012 16:32:18 -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;
	25 Jan 2012 16:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10286829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:32: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;
	Wed, 25 Jan 2012 16:32:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Wed, 25 Jan 2012 16:32:17 +0000
In-Reply-To: <4F202B8A.4060506@suse.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327440026.17019.16.camel@dagon.hellion.org.uk>
	<4F202B8A.4060506@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327509137.24561.347.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 16:19 +0000, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Tue, 2012-01-24 at 18:05 +0000, erin.balid@inoutbox.com wrote:
> >   
> >> Using the same log redirection you mentioned before
> >>
> >> edit /etc/xen/scripts/vif-bridge
> >> 	#!/bin/bash
> >> +       exec 1>>/tmp/vif-bridge.log
> >> +       exec 2>&1
> >> +       echo "`date`: Running $0 $*"
> >> ...
> >> +       ## TEST ##
> >> +       echo "made it to 001"
> >>
> >> 	dir=$(dirname "$0")
> >> 	. "$dir/vif-common.sh"
> >>
> >> +       ## TEST ##
> >> +       echo "made it to 002"
> >>
> >>
> >> 	domu=$(xenstore_read_default "$XENBUS_PATH/domain" "")
> >> 	if [ -z "$domu" ]
> >> 	then
> >> 	    log debug "No device details in $XENBUS_PATH, exiting."
> >>     
> >
> > So, presumably either the xenstore_read_default is failing or domu is
> > zero length and the script is explicitly bailing here.
> >
> > However I do not see anything like this anywhere in the hotplug script
> > shipped with Xen. Either this is a local modification or something done
> > by your distribution, in which case you should contact them.
> >   
> 
> Grrr, that is my patch here
> 
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
> 
> which thankfully was never applied upstream but did make its way into
> openSUSE12.1.  In that thread, Ian suggested having the toolstack write
> the literal tap device name to xenstore and then read it in the vif
> script.  I have this on my todo list with very low priority, but seems I
> should bump it now :-).

There's been a fair bit of discussion recently on changing the way these
scripts are executed, this case is one which we need to remember to
handle too.

In particular Roger Pau Monet has posted a few series recently. You
should be able to find these and the discussion in the archives.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:32:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:32:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5lp-0002N4-Pv; Wed, 25 Jan 2012 16:32:25 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq5ln-0002MS-SE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:32:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327509137!12536830!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31215 invoked from network); 25 Jan 2012 16:32:18 -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;
	25 Jan 2012 16:32:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10286829"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:32: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;
	Wed, 25 Jan 2012 16:32:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Date: Wed, 25 Jan 2012 16:32:17 +0000
In-Reply-To: <4F202B8A.4060506@suse.com>
References: <1327176409.25269.140661026313477@webmail.messagingengine.com>
	<1327318076.24561.63.camel@zakaz.uk.xensource.com>
	<1327332514.25697.140661026919117@webmail.messagingengine.com>
	<1327415184.24561.182.camel@zakaz.uk.xensource.com>
	<1327420611.19936.140661027415609@webmail.messagingengine.com>
	<1327423312.24561.211.camel@zakaz.uk.xensource.com>
	<1327425015.8709.140661027442201@webmail.messagingengine.com>
	<1327428329.24310.140661027473797@webmail.messagingengine.com>
	<1327440026.17019.16.camel@dagon.hellion.org.uk>
	<4F202B8A.4060506@suse.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327509137.24561.347.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"erin.balid@inoutbox.com" <erin.balid@inoutbox.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 16:19 +0000, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Tue, 2012-01-24 at 18:05 +0000, erin.balid@inoutbox.com wrote:
> >   
> >> Using the same log redirection you mentioned before
> >>
> >> edit /etc/xen/scripts/vif-bridge
> >> 	#!/bin/bash
> >> +       exec 1>>/tmp/vif-bridge.log
> >> +       exec 2>&1
> >> +       echo "`date`: Running $0 $*"
> >> ...
> >> +       ## TEST ##
> >> +       echo "made it to 001"
> >>
> >> 	dir=$(dirname "$0")
> >> 	. "$dir/vif-common.sh"
> >>
> >> +       ## TEST ##
> >> +       echo "made it to 002"
> >>
> >>
> >> 	domu=$(xenstore_read_default "$XENBUS_PATH/domain" "")
> >> 	if [ -z "$domu" ]
> >> 	then
> >> 	    log debug "No device details in $XENBUS_PATH, exiting."
> >>     
> >
> > So, presumably either the xenstore_read_default is failing or domu is
> > zero length and the script is explicitly bailing here.
> >
> > However I do not see anything like this anywhere in the hotplug script
> > shipped with Xen. Either this is a local modification or something done
> > by your distribution, in which case you should contact them.
> >   
> 
> Grrr, that is my patch here
> 
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
> 
> which thankfully was never applied upstream but did make its way into
> openSUSE12.1.  In that thread, Ian suggested having the toolstack write
> the literal tap device name to xenstore and then read it in the vif
> script.  I have this on my todo list with very low priority, but seems I
> should bump it now :-).

There's been a fair bit of discussion recently on changing the way these
scripts are executed, this case is one which we need to remember to
handle too.

In particular Roger Pau Monet has posted a few series recently. You
should be able to find these and the discussion in the archives.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq5pc-0002cQ-Ea; Wed, 25 Jan 2012 16:36: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 1Rq5pb-0002cJ-2G
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:36:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327509330!50056302!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17720 invoked from network); 25 Jan 2012 16:35:30 -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;
	25 Jan 2012 16:35:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10286968"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:36: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; Wed, 25 Jan 2012 16:36:17 +0000
Date: Wed, 25 Jan 2012 16:37:07 +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: <1327508967.24561.345.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201251634310.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
	<1326732775-15485-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327508967.24561.345.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 v10 6/7] libxl: use new qemu at the location
 where xen-unstable installs 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 Wed, 25 Jan 2012, Ian Campbell wrote:
> On Mon, 2012-01-16 at 16:52 +0000, stefano.stabellini@eu.citrix.com
> wrote:
> > From: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  tools/libxl/libxl_dm.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 97d91b4..9d84b6f 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -58,7 +58,7 @@ const char *libxl__domain_device_model(libxl__gc *gc,
> >              dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
> >              break;
> >          case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > -            dm = libxl__strdup(gc, "/usr/bin/qemu");
> > +            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());
> 
> The actual installed path (in staging tree now)
> is /usr/lib/xen/bin/qemu-system-i386 so if I boot a guest with
> device_model_version="qemu-xen" then, as you might expect, I get:
>         libxl: error: libxl_dm.c:809:libxl__create_device_model: device model /usr/lib/xen/bin/qemu is not executable: No such file or directory
>         libxl: error: libxl_create.c:579:do_domain_create: failed to create device model: -3
>         libxl: error: libxl_dm.c:926:libxl__destroy_device_model: Couldn't find device model's pid: No such file or directory
>         libxl: error: libxl.c:796:libxl_domain_destroy: libxl__destroy_device_model failed for 21
> 
> I can add device_model_override="/usr/lib/xen/bin/qemu-system-i386" and
> then things work as expected.
> 
> Presumably if I build my tools for 64 bit it will be qemu-system-amd64.

It is always qemu-system-i386, unless we change the target in the
configure line. Of course it doesn't really matter for us because we
don't use it for cpu emulation.

> So, should we fix libxl, the qemu build or our build integration?
 
The binary name changed for the 1.0 release, I don't expect it to change
again. I think we should update libxl.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:36:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq5pc-0002cQ-Ea; Wed, 25 Jan 2012 16:36: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 1Rq5pb-0002cJ-2G
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:36:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-27.messagelabs.com!1327509330!50056302!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17720 invoked from network); 25 Jan 2012 16:35:30 -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;
	25 Jan 2012 16:35:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10286968"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:36: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; Wed, 25 Jan 2012 16:36:17 +0000
Date: Wed, 25 Jan 2012 16:37:07 +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: <1327508967.24561.345.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201251634310.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201161606280.3150@kaball-desktop>
	<1326732775-15485-6-git-send-email-stefano.stabellini@eu.citrix.com>
	<1327508967.24561.345.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 v10 6/7] libxl: use new qemu at the location
 where xen-unstable installs 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 Wed, 25 Jan 2012, Ian Campbell wrote:
> On Mon, 2012-01-16 at 16:52 +0000, stefano.stabellini@eu.citrix.com
> wrote:
> > From: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> >  tools/libxl/libxl_dm.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 97d91b4..9d84b6f 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -58,7 +58,7 @@ const char *libxl__domain_device_model(libxl__gc *gc,
> >              dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
> >              break;
> >          case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > -            dm = libxl__strdup(gc, "/usr/bin/qemu");
> > +            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());
> 
> The actual installed path (in staging tree now)
> is /usr/lib/xen/bin/qemu-system-i386 so if I boot a guest with
> device_model_version="qemu-xen" then, as you might expect, I get:
>         libxl: error: libxl_dm.c:809:libxl__create_device_model: device model /usr/lib/xen/bin/qemu is not executable: No such file or directory
>         libxl: error: libxl_create.c:579:do_domain_create: failed to create device model: -3
>         libxl: error: libxl_dm.c:926:libxl__destroy_device_model: Couldn't find device model's pid: No such file or directory
>         libxl: error: libxl.c:796:libxl_domain_destroy: libxl__destroy_device_model failed for 21
> 
> I can add device_model_override="/usr/lib/xen/bin/qemu-system-i386" and
> then things work as expected.
> 
> Presumably if I build my tools for 64 bit it will be qemu-system-amd64.

It is always qemu-system-i386, unless we change the target in the
configure line. Of course it doesn't really matter for us because we
don't use it for cpu emulation.

> So, should we fix libxl, the qemu build or our build integration?
 
The binary name changed for the 1.0 release, I don't expect it to change
again. I think we should update libxl.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:41:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5uj-0002n5-BG; Wed, 25 Jan 2012 16:41:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rq5ui-0002mz-Bm
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:41:36 +0000
Received: from [85.158.138.51:10643] by server-4.bemta-3.messagelabs.com id
	CC/A2-32238-FB0302F4; Wed, 25 Jan 2012 16:41:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327509693!6433903!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21001 invoked from network); 25 Jan 2012 16:41:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:41:34 -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
	q0PGfSFG008939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 16:41:29 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
	q0PGfRfu006914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 16:41:28 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0PGfQVv015425; Wed, 25 Jan 2012 10:41:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 08:41:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 83CB6401A1; Wed, 25 Jan 2012 11:39:10 -0500 (EST)
Date: Wed, 25 Jan 2012 11:39:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: =?utf-8?B?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?= <socketpair@gmail.com>
Message-ID: <20120125163910.GC23999@phenom.dumpdata.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
	<CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F2030BA.0055,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Fwd: BUG in
	linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBKYW4gMjUsIDIwMTIgYXQgMDQ6MjA6MjZQTSArMDYwMCwg0JzQsNGA0Log0JrQvtGA
0LXQvdCx0LXRgNCzIHdyb3RlOgo+IEZpcnN0LCBtYWludGFpbmVyJ3MgYWRkcmVzc2VzIChSeWFu
IFdpbHNvbiA8aGFwOUBlcG9jaC5uY3NjLm1pbD4sCj4gQ2hyaXMgQm9va2hvbHQgPGhhcDEwQGVw
b2NoLm5jc2MubWlsPikgYXJlIHdyb25nICh1c2VycyB1bmtub3duIHRvCj4gcmVtb3RlIG1haWxz
eXN0ZW0pLCBzbyBwb3N0aW5nIHRvIHlvdToKClRob3NlIGFyZSB0aGUgYXV0aG9ycyBvbmVzLi4g
SWYgeW91IGRvOgprb25yYWRAcGhlbm9tOn4vd29yay9saW51eCQgc2NyaXB0cy9nZXRfbWFpbnRh
aW5lci5wbCAtZiBkcml2ZXJzL3hlbi94ZW4tcGNpYmFjay9wY2lfc3R1Yi5jCktvbnJhZCBSemVz
enV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4gKHN1cHBvcnRlcjpYRU4gSFlQRVJW
SVNPUiBJTi4uLixjb21taXRfc2lnbmVyOjExLzExPTEwMCUpCkplcmVteSBGaXR6aGFyZGluZ2Ug
PGplcmVteUBnb29wLm9yZz4gKHN1cHBvcnRlcjpYRU4gSFlQRVJWSVNPUiBJTi4uLixjb21taXRf
c2lnbmVyOjIvMTE9MTglKQpKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+IChjb21taXRf
c2lnbmVyOjEvMTE9OSUpCnhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tIChvcGVuIGxpc3Q6
WEVOIEhZUEVSVklTT1IgSU4uLi4pCnZpcnR1YWxpemF0aW9uQGxpc3RzLmxpbnV4LWZvdW5kYXRp
b24ub3JnIChvcGVuIGxpc3Q6WEVOIEhZUEVSVklTT1IgSU4uLi4pCmxpbnV4LWtlcm5lbEB2Z2Vy
Lmtlcm5lbC5vcmcgKG9wZW4gbGlzdCkKCj4gCj4gUENJIGJ1cyBmb3JtYXQgc3RyaW5ncyBhcmUg
d3JvbmcuCj4gCj4gIiUwNHg6JTAyeDolMDJ4LiVkIgo+IAo+IHNob3VsZCBiZSB1c2VkIGluc3Rl
YWQgb2YKPiAKPiAiJTA0eDolMDJ4OiUwMnguJTF4IgoKT2g/IFdvdWxkIHlvdSBiZSB3aWxsaW5n
IHRvIGNvbWUgdXAgd2l0aCBhIHBhdGNoIHdpdGggeW91ciBTT0IsIHBsZWFzZT8KCj4gCj4gKGlu
IG1hbnkgcGxhY2VzIG9mIGxpbnV4K3YzLjIuMS9kcml2ZXJzL3hlbi94ZW4tcGNpYmFjay9wY2lf
c3R1Yi5jKQo+IAo+IC0tIAo+IFNlZ21lbnRhdGlvbiBmYXVsdAo+IC0tCj4gVG8gdW5zdWJzY3Jp
YmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWtlcm5l
bCIgaW4KPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9y
Zwo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jk
b21vLWluZm8uaHRtbAo+IFBsZWFzZSByZWFkIHRoZSBGQVEgYXQgIGh0dHA6Ly93d3cudHV4Lm9y
Zy9sa21sLwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:41:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:41:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq5uj-0002n5-BG; Wed, 25 Jan 2012 16:41:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rq5ui-0002mz-Bm
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:41:36 +0000
Received: from [85.158.138.51:10643] by server-4.bemta-3.messagelabs.com id
	CC/A2-32238-FB0302F4; Wed, 25 Jan 2012 16:41:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327509693!6433903!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21001 invoked from network); 25 Jan 2012 16:41:34 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:41:34 -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
	q0PGfSFG008939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 16:41:29 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
	q0PGfRfu006914
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 16:41:28 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0PGfQVv015425; Wed, 25 Jan 2012 10:41:27 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 08:41:26 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 83CB6401A1; Wed, 25 Jan 2012 11:39:10 -0500 (EST)
Date: Wed, 25 Jan 2012 11:39:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: =?utf-8?B?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?= <socketpair@gmail.com>
Message-ID: <20120125163910.GC23999@phenom.dumpdata.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
	<CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F2030BA.0055,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Fwd: BUG in
	linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBKYW4gMjUsIDIwMTIgYXQgMDQ6MjA6MjZQTSArMDYwMCwg0JzQsNGA0Log0JrQvtGA
0LXQvdCx0LXRgNCzIHdyb3RlOgo+IEZpcnN0LCBtYWludGFpbmVyJ3MgYWRkcmVzc2VzIChSeWFu
IFdpbHNvbiA8aGFwOUBlcG9jaC5uY3NjLm1pbD4sCj4gQ2hyaXMgQm9va2hvbHQgPGhhcDEwQGVw
b2NoLm5jc2MubWlsPikgYXJlIHdyb25nICh1c2VycyB1bmtub3duIHRvCj4gcmVtb3RlIG1haWxz
eXN0ZW0pLCBzbyBwb3N0aW5nIHRvIHlvdToKClRob3NlIGFyZSB0aGUgYXV0aG9ycyBvbmVzLi4g
SWYgeW91IGRvOgprb25yYWRAcGhlbm9tOn4vd29yay9saW51eCQgc2NyaXB0cy9nZXRfbWFpbnRh
aW5lci5wbCAtZiBkcml2ZXJzL3hlbi94ZW4tcGNpYmFjay9wY2lfc3R1Yi5jCktvbnJhZCBSemVz
enV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4gKHN1cHBvcnRlcjpYRU4gSFlQRVJW
SVNPUiBJTi4uLixjb21taXRfc2lnbmVyOjExLzExPTEwMCUpCkplcmVteSBGaXR6aGFyZGluZ2Ug
PGplcmVteUBnb29wLm9yZz4gKHN1cHBvcnRlcjpYRU4gSFlQRVJWSVNPUiBJTi4uLixjb21taXRf
c2lnbmVyOjIvMTE9MTglKQpKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+IChjb21taXRf
c2lnbmVyOjEvMTE9OSUpCnhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tIChvcGVuIGxpc3Q6
WEVOIEhZUEVSVklTT1IgSU4uLi4pCnZpcnR1YWxpemF0aW9uQGxpc3RzLmxpbnV4LWZvdW5kYXRp
b24ub3JnIChvcGVuIGxpc3Q6WEVOIEhZUEVSVklTT1IgSU4uLi4pCmxpbnV4LWtlcm5lbEB2Z2Vy
Lmtlcm5lbC5vcmcgKG9wZW4gbGlzdCkKCj4gCj4gUENJIGJ1cyBmb3JtYXQgc3RyaW5ncyBhcmUg
d3JvbmcuCj4gCj4gIiUwNHg6JTAyeDolMDJ4LiVkIgo+IAo+IHNob3VsZCBiZSB1c2VkIGluc3Rl
YWQgb2YKPiAKPiAiJTA0eDolMDJ4OiUwMnguJTF4IgoKT2g/IFdvdWxkIHlvdSBiZSB3aWxsaW5n
IHRvIGNvbWUgdXAgd2l0aCBhIHBhdGNoIHdpdGggeW91ciBTT0IsIHBsZWFzZT8KCj4gCj4gKGlu
IG1hbnkgcGxhY2VzIG9mIGxpbnV4K3YzLjIuMS9kcml2ZXJzL3hlbi94ZW4tcGNpYmFjay9wY2lf
c3R1Yi5jKQo+IAo+IC0tIAo+IFNlZ21lbnRhdGlvbiBmYXVsdAo+IC0tCj4gVG8gdW5zdWJzY3Jp
YmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxpbmUgInVuc3Vic2NyaWJlIGxpbnV4LWtlcm5l
bCIgaW4KPiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9y
Zwo+IE1vcmUgbWFqb3Jkb21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jk
b21vLWluZm8uaHRtbAo+IFBsZWFzZSByZWFkIHRoZSBGQVEgYXQgIGh0dHA6Ly93d3cudHV4Lm9y
Zy9sa21sLwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
WGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRw
Oi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:47:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:47:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq60b-0002zV-5Y; Wed, 25 Jan 2012 16:47:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq60Z-0002z8-TK
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:47:40 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327510051!8725025!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27759 invoked from network); 25 Jan 2012 16:47:32 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:47:32 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 09:47:23 -0700
Message-ID: <4F20321A.9090204@suse.com>
Date: Wed, 25 Jan 2012 09:47:22 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: erin.balid@inoutbox.com
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
	<4F1F3B23.60304@suse.com>
	<1327456894.17114.140661027646361@webmail.messagingengine.com>
	<4F2025FC.7060407@suse.com>
	<1327508820.28123.140661027898793@webmail.messagingengine.com>
In-Reply-To: <1327508820.28123.140661027898793@webmail.messagingengine.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

erin.balid@inoutbox.com wrote:
> Hi Jim.
>
> On Wed, Jan 25, 2012, at 08:55 AM, Jim Fehlig wrote:
>   
>> Generally speaking, xen.org documentation applies to the xen packages in openSUSE.
>>     
>
> Okay then.  That simplifies life.  Thanks.
>
> What will be the best place to track fixes to this issue in
> Opensuse-land?  Xen-users list?  Opensuse-virtual list?

bugzilla.novell.com

>  I'd like to get
> off _this_ list if possible.  I don't really fit here.  Unless it really
> is the right forum to follow.
>   

Yes, let's stop this thread here :-).  This is a downstream issue.

> I got your comment that you'd look for fixes in the Opensuse 12.2
> time-frame.  As I read the openSUSE Roadmap, the scheduled release date
> for openSUSE 12.2 is July 2012.
>
> We won't switch to a new OS release until after it's in production.  We
> _are_ willing to use a few non-production repositories for key packages.
>  Xen's one of them.
>
> Should we plan to see these Xen fixes in a shorter timeframe in a repo
> built for use with 12.1 release/kernel prior to that 12.2 release date?

We do maintenance on virtualization packages in openSUSE, so a fix for
this could be delivered to the openSUSE12.1 update repository.  But the
process starts with a bugzilla entry...

Regards,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:47:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:47:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq60b-0002zV-5Y; Wed, 25 Jan 2012 16:47:41 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq60Z-0002z8-TK
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:47:40 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327510051!8725025!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27759 invoked from network); 25 Jan 2012 16:47:32 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-3.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:47:32 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 09:47:23 -0700
Message-ID: <4F20321A.9090204@suse.com>
Date: Wed, 25 Jan 2012 09:47:22 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: erin.balid@inoutbox.com
References: <1327176409.25269.140661026313477@webmail.messagingengine.com><CAPLaKK6izAoCF=TtYK=OxEvNOFvKLOrpg+iMSBfyQb0UaS3c3Q@mail.gmail.com><1327187042.28621.140661026352253@webmail.messagingengine.com><CAPLaKK5YKuAAG+TL=JjWk7EbSrxiRC1hHFWtr5VwLtRo6Z6-SQ@mail.gmail.com><1327252276.343.140661026559797@webmail.messagingengine.com>
	<CAPLaKK4_WpMh=CEmop7vnUgUzX5iuGgwjyoeXpKDF8b72Z7SZA@mail.gmail.com>
	<1327254854.9185.140661026566721@webmail.messagingengine.com>
	<4F1F3B23.60304@suse.com>
	<1327456894.17114.140661027646361@webmail.messagingengine.com>
	<4F2025FC.7060407@suse.com>
	<1327508820.28123.140661027898793@webmail.messagingengine.com>
In-Reply-To: <1327508820.28123.140661027898793@webmail.messagingengine.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

erin.balid@inoutbox.com wrote:
> Hi Jim.
>
> On Wed, Jan 25, 2012, at 08:55 AM, Jim Fehlig wrote:
>   
>> Generally speaking, xen.org documentation applies to the xen packages in openSUSE.
>>     
>
> Okay then.  That simplifies life.  Thanks.
>
> What will be the best place to track fixes to this issue in
> Opensuse-land?  Xen-users list?  Opensuse-virtual list?

bugzilla.novell.com

>  I'd like to get
> off _this_ list if possible.  I don't really fit here.  Unless it really
> is the right forum to follow.
>   

Yes, let's stop this thread here :-).  This is a downstream issue.

> I got your comment that you'd look for fixes in the Opensuse 12.2
> time-frame.  As I read the openSUSE Roadmap, the scheduled release date
> for openSUSE 12.2 is July 2012.
>
> We won't switch to a new OS release until after it's in production.  We
> _are_ willing to use a few non-production repositories for key packages.
>  Xen's one of them.
>
> Should we plan to see these Xen fixes in a shorter timeframe in a repo
> built for use with 12.1 release/kernel prior to that 12.2 release date?

We do maintenance on virtualization packages in openSUSE, so a fix for
this could be delivered to the openSUSE12.1 update repository.  But the
process starts with a bugzilla entry...

Regards,
Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:52:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq65D-0003H0-23; Wed, 25 Jan 2012 16:52:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rq65C-0003Gu-DI
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:52:26 +0000
Received: from [85.158.138.51:10884] by server-9.bemta-3.messagelabs.com id
	C1/56-31168-943302F4; Wed, 25 Jan 2012 16:52:25 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327510343!10661893!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17608 invoked from network); 25 Jan 2012 16:52:24 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:52:24 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PGqMdG014222;
	Wed, 25 Jan 2012 11:52:23 -0500
Received: from [192.168.37.18] ([192.168.37.18]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Wed, 25 Jan 2012 11:52:00 -0500
Message-ID: <1327510331.2452.21.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Date: Wed, 25 Jan 2012 11:52:11 -0500
In-Reply-To: <EE3AE950D047481283FF742510029D1E@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2012 16:52:00.0946 (UTC)
	FILETIME=[A8669120:01CCDB81]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDAzOjI2IC0wNTAwLCBMaWthcnBlbmtvdiBBbGV4YW5kZXIg
d3JvdGU6Cj4g0JfQtNGA0LDQstGB0YLQstGD0LnRgtC1IQo+IAo+INCS0L4g0LLRgtC+0YDQvdC4
0LosINC00LLQsNC00YbQsNGC0Ywg0YfQtdGC0LLQtdGA0YLQvtCz0L4g0Y/QvdCy0LDRgNGPIDIw
MTIg0LPQvtC00LAsINCyIDIwOjQxOjM4INCS0YsKPiDQv9C40YHQsNC70Lg6Cj4gIERNPiBJIHVz
ZSB0aGUgeGwgdG9vbHN0YWNrLCBub3QgeG0uICBJIGRvbid0IHRoaW5rIHhtIGlzIGJlaW5nCj4g
YWN0aXZlbHkKPiAgRE0+IG1haW50YWluZWQsIGF0IGxlYXN0IG5vdCBmb3IgY3VycmVudCByZWxl
YXNlcy4KPiAKPiBZb3UgY2FuIGluIGEgbnV0c2hlbGwgd2hhdCBiZXR0ZXIgeGwgeG0/CgpJJ20g
bm90IHRoZSBwZXJzb24gd2hvIGNhbiBnaXZlIHlvdSB0aGUgbW9zdCB0aG9yb3VnaCByZXNwb25z
ZSwgaG93ZXZlciwKSSBjYW4gdGVsbCB5b3Ugd2hhdCBpIGtub3cuICBYbCBpcyBsaWdodGVyLXdl
aWdodCAoQyB2cyBweXRob24sIGFtb25nCm90aGVyIHN0cnVjdHVyYWwgZGlmZmVyZW5jZXMpLiAg
WGwgaXMgdGhlIG9ubHkgJ3N1dXBvcnRlZCcgdG9vbHN0YWNrCmdvaW5nIGZvcndhcmQsIGFuZCB4
ZW5kL3htIGlzIG5vIGxvbmdlciBiZWluZyBtYWludGFpbmVkLiAgQUZBSUNULCB4bCBpcwpuZWFy
IGZlYXR1cmUgcGFyaXR5IHdpdGggeGVuZC94bSBpbiB0aGUgY3VycmVudCB1bnN0YWJsZS4KClhs
IGlzIHRoZSB3YXkgdG8gZ28gaWYgeW91J3JlIHdvcmtpbmcgb24geGVuLXVuc3RhYmxlLgoKSSBp
bWFnaW5lIHVzZXJzIG9uIDQuMS54IGFyZSBlbmNvdXJhZ2VkIHRvIHVzZSBpdCwgYnV0IGNlcnRh
aW4gZmVhdHVyZXMKKHN1Y2ggYXMgcmVjb2duaXppbmcgYW5kIHBhc3NpbmcgZ2Z4X3Bhc3N0aHJ1
IGZsYWcgdG8gcWVtdSkgbWF5IG9yIG1heQpub3QgYmUgaW1wbGVtZW50ZWQgaW4gb2xkZXIgdmVy
c2lvbnMsIHNvIGZvciB5b3VyIHRlc3RpbmcsIHlvdSBtYXkgaGF2ZQp0byB1c2UgeG0gZm9yIHNv
bWUgY29tbWFuZHMgaWYgeW91J3JlIGJ1aWxkaW5nIGFuIG9sZGVyIFhlbi4KCklmIGFueW9uZSBj
YW4gY2xlYXIgdGhhdCB1cC9jb3JyZWN0IGFueSBpbm5hY3VyYWNpZXMsIHBsZWFzZSBqdW1wIGlu
LgpUaGVyZSBzaG91bGQgcHJvYmFibHkgYmUgYSB3aWtpIHBhZ2Ugb24gdGhpcyBpZiB0aGVyZSBp
c24ndCBhbHJlYWR5IG9uZS4KTG9va2VkIGp1c3Qgbm93LCBhbmQgdGhlIG9ubHkgcmVsZXZhbnQg
aW5mbyBzZWVtcyB0byBiZSBoZXJlOgpodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvTWlncmF0aW9u
X0d1aWRlX1RvX1hlbjQuMSUyQgoKPiAKPiAgRE0+IEkgZG9uJ3Qga25vdyB3aGF0IGEgdmlkZW8g
Y291bGQgc2hvdyB5b3UuICBJbiB0aGUgQVRJIGNhc2UsCj4gdGhlcmUncyBubwo+ICBETT4gc2ln
bmFsIHVudGlsIFdpbmRvd3MgbG9hZHMgdGhlIGRyaXZlcnMuICBJdCBhdXRvbWF0aWNhbGx5Cj4g
ZGlzYWJsZXMgdGhlCj4gIERNPiBlbXVsYXRlZCBhZGFwdGVyLCBzbyBpIGNhbiB3YXRjaCB0aGUg
QklPUyBhbmQgV2luZG93cyBsb2FkaW5nCj4gc2NyZWVucwo+ICBETT4gdmlhIFZOQywgdGhlbiBt
eSBkZXNrdG9wIGFwcGVhcnMgb24gdGhlIG1vbml0b3IgYW5kIHRoZSBWTkMKPiBjb25zb2xlCj4g
IERNPiBnb2VzIGJsYWNrLgo+IAo+IEkgc2F5IHRoYXQgQVRJIHByb2R1Y2VzIHRoZSBzYW1lIGVm
ZmVjdC4gSSBkbyBub3Qgc2VlIGFueXRoaW5nIHVudGlsCj4gdGhlCj4gd2VsY29tZSBzY3JlZW4g
YW5kIG9ubHkgd2hlbiBnZnhfcGFzc3RocnUgPSAwLiBJZiBnZnhfcGFzc3RocnUgPSAxIC0KPiBx
ZW11Cj4gc2hlbGwgb24gdm5jIGNvbnNvbGUgYW5kIGZyZWV6ZWQgZG9tVSA6KAoKWW91IHdvbid0
IGJlIGFibGUgdG8gcGFzc3Rocm91Z2ggYW4gQVRJIGNhcmQgd2l0aCB0aGUgQklPUyBmb3IgbXVs
dGlwbGUKcmVhc29ucy4gIEZpcnN0LCB0aGUgYXRpIGJpb3Mga2VlcHMgYSBjb3B5IG9mIHRoZSBw
Y2kgY29uZmlnIHNwYWNlLCBzbwpjZXJ0YWluIHZhbHVlcyBuZWVkIHRvIGJlIG1vZGlmaWVkIGZv
ciBpdCB0byB3b3JrIHByb3Blcmx5IHdpdGggdGhlCmd1ZXN0IGFkZHJlc3Nlcy4gIFRoZSBtb3N0
IHJlY2VudCBleHBlcmltZW50YWwgcGF0Y2ggZm9yIHRoaXMgd2FzIGZyb20KZGVjZW1iZXIgMjAx
MDoKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMC0xMi9t
c2cwMDcwNS5odG1sCkkgY2FuIGNvbmZpcm1tIGkgaGFkIGxpbWl0ZWQgc3VjY2VzcyB3aXRoIHRo
aXMuCgpIb3dldmVyLCB0aGlzIHBhdGNoIHdhcyBiYXNlZCBvbiB4ZW4tdW5zdGFibGUgYmVmb3Jl
IHRoZSA0LjEtcmMncyBjYW1lCm91dC4gIFlvdSBjYW4gdHJ5IGJ1aWxkaW5nIGFuIG9sZGVyIHZl
cnNpb24gb2YgeGVuIChpbiB0aGF0IHRocmVhZCwgaQptZW50aW9uZWQgdGhlIHNwZWNpZmljIEMv
UyBpIHVzZWQgaW4gdGVzdGluZykgYW5kIGFwcGx5aW5nIHRoZSBwYXRjaCBvcgpmb3J3YXJkIHBv
cnRpbmcgdGhlIHBhdGNoIHRvIHRoZSBjdXJyZW50IHhlbi9xZW11LXhlbi4KCkFsc28sIGkgYmVs
aWV2ZSB5b3Ugc2FpZCB0aGUgY2FyZCB5b3UncmUgdHJ5aW5nIHRvIHBhc3MgdGhyb3VnaCBpcyBu
b3QKdGhlIHByaW1hcnkgY2FyZCBpbiB5b3VyIGhvc3Qgc3lzdGVtLiAgSWYgdGhhdCdzIHRoZSBj
YXNlLCBkb24ndCB1c2UKZ2Z4X3Bhc3N0aHJ1IG9yIGV4cGVjdCB0byBnZXQgdGhlIHZpZGVvIGJp
b3Mgd29ya2luZy4gIFRoZSAncHJpbWFyeScKdmlkZW8gYWRhcHRlciBvd25zIGNlcnRhaW4gaW8g
cG9ydHMgYW5kIG1lbW9yeSBhcmVhcyB0aGF0IGFyZSBjb25zaXRlbnQKZnJvbSBtYWNoaW5lIHRv
IG1hY2hpbmUuICBBbHNvLCB0aGUgc3lzdGVtIHdpbGwgY29weSB0aGUgdmJpb3MgZnJvbSB0aGUK
Y2FyZCB0byBhIGxvY2F0aW9uIGluIG1lbW9yeSAoMHhjMDAwMCkgc28gaXQgY2FuIGV4ZWN1dGUg
YXQgYm9vdCB0aW1lLiAKClhlbidzIGdmeF9wYXNzdGhydSBjb2RlIGRlcGVuZHMgb24gYWxsIG9m
IHRoZXNlIGZhY3RvcnMuICBBcyB0aGUgY29kZQpzdGFuZHMsIGlmIHlvdSB1c2UgZ2Z4X3Bhc3N0
aHJ1IG9uIGEgc2Vjb25kYXJ5IGNhcmQsIGl0IHdpbGwgc3RpbGwgY29weQp0aGUgdmJpb3MgZnJv
bSB0aGUgcHJpbWFyeSBjYXJkIChhcyBpdCBzaW1wbHkgcmVhZHMgbWVtb3J5IGZyb20KMHhjMDAw
MCksIGFuZCBkaXJlY3RseSBtYXAgaW8gcG9ydHMgYW5kIGxvdyBtZW1vcnkgYXJlYXMgdG8gdGhv
c2UgdXNlZApieSB0aGUgcHJpbWFyeSBjYXJkIGluIHRoZSBob3N0IHN5c3RlbS4gIEluIHRoaXMg
Y2FzZSB0aGUgZ3Vlc3Qgd2lsbAphbG1vc3QgY2VydGFpbmx5IG5ldmVyIGdldCBwYXN0IGV4ZWN1
dGluZyBST01CSU9TLCBhbmQgdGhlIGhvc3QgbWF5IG9yCm1heSBub3QgbG9jayB1cCBvciBleHBl
cmllbmNlICdpc3N1ZXMnLgoKPiAKPiAgRE0+IEluIHRoZSBJR0QgY2FzZSwgaSBjYW4gc2VlIHRo
ZSBvdXRwdXQgZnJvbSBST01CSU9TIGFuZCB0aGUKPiB3aW5kb3dzCj4gIERNPiBsb2FkZXIgKG9y
IGdydWIyKSBvbiB0aGUgbW9uaXRvci4gIElmIGknbSBib290aW5nIGEgWFAgZG9tVSwgdGhlCj4g
IERNPiB3aW5kb3dzIGxvZ2luIHNjcmVlbiB0aGVuIGFwcGVhcnMuICBJZiBpJ20gYm9vdGluZyBh
IFdpbjcgZG9tVSwKPiB0aGUKPiAgRE0+IHNjcmVlbiBnb2VzIGJsYWNrLiAgSWYgaSdtIGJvb3Rp
bmcgYSBmZWRvcmExNiBkb211LCB0aGUgc2lnbmFsCj4gdmFuaXNoZXMKPiAgRE0+IGVudGlyZWx5
LiBJbiB0aGUgV2luNyBjYXNlLCB0aGUgZG9tVSBzZWVtcyB0byBiZSBzdHVjayBpbiBhIGxvb3Au
Cj4gSW4KPiAgRE0+IHRoZSBGZWRvcmEgY2FzZSwgaSBjYW4gc3NoIHRvIHRoZSBtYWNoaW5lIGFu
ZCBzZWUgdmFyaW91cyBXQVJOX09OCj4gZHVtcHMKPiAgRE0+IGluIGRtZXNnIHJlbGF0ZWQgdG8g
dGhlIGk5MTUgZHJpdmVyLCBhbmQgZXZlbnR1YWxseSwgYSBtZXNzYWdlCj4gc2F5aW5nCj4gIERN
PiBpdCBmYWlsZWQgdG8gcmVzZXQgdGhlIGFkYXB0ZXIuCj4gCj4gIERNPiBJIHRoaW5rIHRoYXQg
Z2l2ZXMgeW91IG1vcmUgZGV0YWlsIHRoYW4gYW55IHZpZGVvIGkgY291bGQgcG9zdC4KPiAKPiBZ
ZXMsIHlvdXIgcG9zdCBpcyByZWFsbHkgYmV0dGVyIHZpZGVvCj4gCj4gCj4gCgoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:52:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq65D-0003H0-23; Wed, 25 Jan 2012 16:52:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rq65C-0003Gu-DI
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:52:26 +0000
Received: from [85.158.138.51:10884] by server-9.bemta-3.messagelabs.com id
	C1/56-31168-943302F4; Wed, 25 Jan 2012 16:52:25 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327510343!10661893!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17608 invoked from network); 25 Jan 2012 16:52:24 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 16:52:24 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PGqMdG014222;
	Wed, 25 Jan 2012 11:52:23 -0500
Received: from [192.168.37.18] ([192.168.37.18]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Wed, 25 Jan 2012 11:52:00 -0500
Message-ID: <1327510331.2452.21.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Date: Wed, 25 Jan 2012 11:52:11 -0500
In-Reply-To: <EE3AE950D047481283FF742510029D1E@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2012 16:52:00.0946 (UTC)
	FILETIME=[A8669120:01CCDB81]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-users@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDAzOjI2IC0wNTAwLCBMaWthcnBlbmtvdiBBbGV4YW5kZXIg
d3JvdGU6Cj4g0JfQtNGA0LDQstGB0YLQstGD0LnRgtC1IQo+IAo+INCS0L4g0LLRgtC+0YDQvdC4
0LosINC00LLQsNC00YbQsNGC0Ywg0YfQtdGC0LLQtdGA0YLQvtCz0L4g0Y/QvdCy0LDRgNGPIDIw
MTIg0LPQvtC00LAsINCyIDIwOjQxOjM4INCS0YsKPiDQv9C40YHQsNC70Lg6Cj4gIERNPiBJIHVz
ZSB0aGUgeGwgdG9vbHN0YWNrLCBub3QgeG0uICBJIGRvbid0IHRoaW5rIHhtIGlzIGJlaW5nCj4g
YWN0aXZlbHkKPiAgRE0+IG1haW50YWluZWQsIGF0IGxlYXN0IG5vdCBmb3IgY3VycmVudCByZWxl
YXNlcy4KPiAKPiBZb3UgY2FuIGluIGEgbnV0c2hlbGwgd2hhdCBiZXR0ZXIgeGwgeG0/CgpJJ20g
bm90IHRoZSBwZXJzb24gd2hvIGNhbiBnaXZlIHlvdSB0aGUgbW9zdCB0aG9yb3VnaCByZXNwb25z
ZSwgaG93ZXZlciwKSSBjYW4gdGVsbCB5b3Ugd2hhdCBpIGtub3cuICBYbCBpcyBsaWdodGVyLXdl
aWdodCAoQyB2cyBweXRob24sIGFtb25nCm90aGVyIHN0cnVjdHVyYWwgZGlmZmVyZW5jZXMpLiAg
WGwgaXMgdGhlIG9ubHkgJ3N1dXBvcnRlZCcgdG9vbHN0YWNrCmdvaW5nIGZvcndhcmQsIGFuZCB4
ZW5kL3htIGlzIG5vIGxvbmdlciBiZWluZyBtYWludGFpbmVkLiAgQUZBSUNULCB4bCBpcwpuZWFy
IGZlYXR1cmUgcGFyaXR5IHdpdGggeGVuZC94bSBpbiB0aGUgY3VycmVudCB1bnN0YWJsZS4KClhs
IGlzIHRoZSB3YXkgdG8gZ28gaWYgeW91J3JlIHdvcmtpbmcgb24geGVuLXVuc3RhYmxlLgoKSSBp
bWFnaW5lIHVzZXJzIG9uIDQuMS54IGFyZSBlbmNvdXJhZ2VkIHRvIHVzZSBpdCwgYnV0IGNlcnRh
aW4gZmVhdHVyZXMKKHN1Y2ggYXMgcmVjb2duaXppbmcgYW5kIHBhc3NpbmcgZ2Z4X3Bhc3N0aHJ1
IGZsYWcgdG8gcWVtdSkgbWF5IG9yIG1heQpub3QgYmUgaW1wbGVtZW50ZWQgaW4gb2xkZXIgdmVy
c2lvbnMsIHNvIGZvciB5b3VyIHRlc3RpbmcsIHlvdSBtYXkgaGF2ZQp0byB1c2UgeG0gZm9yIHNv
bWUgY29tbWFuZHMgaWYgeW91J3JlIGJ1aWxkaW5nIGFuIG9sZGVyIFhlbi4KCklmIGFueW9uZSBj
YW4gY2xlYXIgdGhhdCB1cC9jb3JyZWN0IGFueSBpbm5hY3VyYWNpZXMsIHBsZWFzZSBqdW1wIGlu
LgpUaGVyZSBzaG91bGQgcHJvYmFibHkgYmUgYSB3aWtpIHBhZ2Ugb24gdGhpcyBpZiB0aGVyZSBp
c24ndCBhbHJlYWR5IG9uZS4KTG9va2VkIGp1c3Qgbm93LCBhbmQgdGhlIG9ubHkgcmVsZXZhbnQg
aW5mbyBzZWVtcyB0byBiZSBoZXJlOgpodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvTWlncmF0aW9u
X0d1aWRlX1RvX1hlbjQuMSUyQgoKPiAKPiAgRE0+IEkgZG9uJ3Qga25vdyB3aGF0IGEgdmlkZW8g
Y291bGQgc2hvdyB5b3UuICBJbiB0aGUgQVRJIGNhc2UsCj4gdGhlcmUncyBubwo+ICBETT4gc2ln
bmFsIHVudGlsIFdpbmRvd3MgbG9hZHMgdGhlIGRyaXZlcnMuICBJdCBhdXRvbWF0aWNhbGx5Cj4g
ZGlzYWJsZXMgdGhlCj4gIERNPiBlbXVsYXRlZCBhZGFwdGVyLCBzbyBpIGNhbiB3YXRjaCB0aGUg
QklPUyBhbmQgV2luZG93cyBsb2FkaW5nCj4gc2NyZWVucwo+ICBETT4gdmlhIFZOQywgdGhlbiBt
eSBkZXNrdG9wIGFwcGVhcnMgb24gdGhlIG1vbml0b3IgYW5kIHRoZSBWTkMKPiBjb25zb2xlCj4g
IERNPiBnb2VzIGJsYWNrLgo+IAo+IEkgc2F5IHRoYXQgQVRJIHByb2R1Y2VzIHRoZSBzYW1lIGVm
ZmVjdC4gSSBkbyBub3Qgc2VlIGFueXRoaW5nIHVudGlsCj4gdGhlCj4gd2VsY29tZSBzY3JlZW4g
YW5kIG9ubHkgd2hlbiBnZnhfcGFzc3RocnUgPSAwLiBJZiBnZnhfcGFzc3RocnUgPSAxIC0KPiBx
ZW11Cj4gc2hlbGwgb24gdm5jIGNvbnNvbGUgYW5kIGZyZWV6ZWQgZG9tVSA6KAoKWW91IHdvbid0
IGJlIGFibGUgdG8gcGFzc3Rocm91Z2ggYW4gQVRJIGNhcmQgd2l0aCB0aGUgQklPUyBmb3IgbXVs
dGlwbGUKcmVhc29ucy4gIEZpcnN0LCB0aGUgYXRpIGJpb3Mga2VlcHMgYSBjb3B5IG9mIHRoZSBw
Y2kgY29uZmlnIHNwYWNlLCBzbwpjZXJ0YWluIHZhbHVlcyBuZWVkIHRvIGJlIG1vZGlmaWVkIGZv
ciBpdCB0byB3b3JrIHByb3Blcmx5IHdpdGggdGhlCmd1ZXN0IGFkZHJlc3Nlcy4gIFRoZSBtb3N0
IHJlY2VudCBleHBlcmltZW50YWwgcGF0Y2ggZm9yIHRoaXMgd2FzIGZyb20KZGVjZW1iZXIgMjAx
MDoKaHR0cDovL2xpc3RzLnhlbi5vcmcvYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAxMC0xMi9t
c2cwMDcwNS5odG1sCkkgY2FuIGNvbmZpcm1tIGkgaGFkIGxpbWl0ZWQgc3VjY2VzcyB3aXRoIHRo
aXMuCgpIb3dldmVyLCB0aGlzIHBhdGNoIHdhcyBiYXNlZCBvbiB4ZW4tdW5zdGFibGUgYmVmb3Jl
IHRoZSA0LjEtcmMncyBjYW1lCm91dC4gIFlvdSBjYW4gdHJ5IGJ1aWxkaW5nIGFuIG9sZGVyIHZl
cnNpb24gb2YgeGVuIChpbiB0aGF0IHRocmVhZCwgaQptZW50aW9uZWQgdGhlIHNwZWNpZmljIEMv
UyBpIHVzZWQgaW4gdGVzdGluZykgYW5kIGFwcGx5aW5nIHRoZSBwYXRjaCBvcgpmb3J3YXJkIHBv
cnRpbmcgdGhlIHBhdGNoIHRvIHRoZSBjdXJyZW50IHhlbi9xZW11LXhlbi4KCkFsc28sIGkgYmVs
aWV2ZSB5b3Ugc2FpZCB0aGUgY2FyZCB5b3UncmUgdHJ5aW5nIHRvIHBhc3MgdGhyb3VnaCBpcyBu
b3QKdGhlIHByaW1hcnkgY2FyZCBpbiB5b3VyIGhvc3Qgc3lzdGVtLiAgSWYgdGhhdCdzIHRoZSBj
YXNlLCBkb24ndCB1c2UKZ2Z4X3Bhc3N0aHJ1IG9yIGV4cGVjdCB0byBnZXQgdGhlIHZpZGVvIGJp
b3Mgd29ya2luZy4gIFRoZSAncHJpbWFyeScKdmlkZW8gYWRhcHRlciBvd25zIGNlcnRhaW4gaW8g
cG9ydHMgYW5kIG1lbW9yeSBhcmVhcyB0aGF0IGFyZSBjb25zaXRlbnQKZnJvbSBtYWNoaW5lIHRv
IG1hY2hpbmUuICBBbHNvLCB0aGUgc3lzdGVtIHdpbGwgY29weSB0aGUgdmJpb3MgZnJvbSB0aGUK
Y2FyZCB0byBhIGxvY2F0aW9uIGluIG1lbW9yeSAoMHhjMDAwMCkgc28gaXQgY2FuIGV4ZWN1dGUg
YXQgYm9vdCB0aW1lLiAKClhlbidzIGdmeF9wYXNzdGhydSBjb2RlIGRlcGVuZHMgb24gYWxsIG9m
IHRoZXNlIGZhY3RvcnMuICBBcyB0aGUgY29kZQpzdGFuZHMsIGlmIHlvdSB1c2UgZ2Z4X3Bhc3N0
aHJ1IG9uIGEgc2Vjb25kYXJ5IGNhcmQsIGl0IHdpbGwgc3RpbGwgY29weQp0aGUgdmJpb3MgZnJv
bSB0aGUgcHJpbWFyeSBjYXJkIChhcyBpdCBzaW1wbHkgcmVhZHMgbWVtb3J5IGZyb20KMHhjMDAw
MCksIGFuZCBkaXJlY3RseSBtYXAgaW8gcG9ydHMgYW5kIGxvdyBtZW1vcnkgYXJlYXMgdG8gdGhv
c2UgdXNlZApieSB0aGUgcHJpbWFyeSBjYXJkIGluIHRoZSBob3N0IHN5c3RlbS4gIEluIHRoaXMg
Y2FzZSB0aGUgZ3Vlc3Qgd2lsbAphbG1vc3QgY2VydGFpbmx5IG5ldmVyIGdldCBwYXN0IGV4ZWN1
dGluZyBST01CSU9TLCBhbmQgdGhlIGhvc3QgbWF5IG9yCm1heSBub3QgbG9jayB1cCBvciBleHBl
cmllbmNlICdpc3N1ZXMnLgoKPiAKPiAgRE0+IEluIHRoZSBJR0QgY2FzZSwgaSBjYW4gc2VlIHRo
ZSBvdXRwdXQgZnJvbSBST01CSU9TIGFuZCB0aGUKPiB3aW5kb3dzCj4gIERNPiBsb2FkZXIgKG9y
IGdydWIyKSBvbiB0aGUgbW9uaXRvci4gIElmIGknbSBib290aW5nIGEgWFAgZG9tVSwgdGhlCj4g
IERNPiB3aW5kb3dzIGxvZ2luIHNjcmVlbiB0aGVuIGFwcGVhcnMuICBJZiBpJ20gYm9vdGluZyBh
IFdpbjcgZG9tVSwKPiB0aGUKPiAgRE0+IHNjcmVlbiBnb2VzIGJsYWNrLiAgSWYgaSdtIGJvb3Rp
bmcgYSBmZWRvcmExNiBkb211LCB0aGUgc2lnbmFsCj4gdmFuaXNoZXMKPiAgRE0+IGVudGlyZWx5
LiBJbiB0aGUgV2luNyBjYXNlLCB0aGUgZG9tVSBzZWVtcyB0byBiZSBzdHVjayBpbiBhIGxvb3Au
Cj4gSW4KPiAgRE0+IHRoZSBGZWRvcmEgY2FzZSwgaSBjYW4gc3NoIHRvIHRoZSBtYWNoaW5lIGFu
ZCBzZWUgdmFyaW91cyBXQVJOX09OCj4gZHVtcHMKPiAgRE0+IGluIGRtZXNnIHJlbGF0ZWQgdG8g
dGhlIGk5MTUgZHJpdmVyLCBhbmQgZXZlbnR1YWxseSwgYSBtZXNzYWdlCj4gc2F5aW5nCj4gIERN
PiBpdCBmYWlsZWQgdG8gcmVzZXQgdGhlIGFkYXB0ZXIuCj4gCj4gIERNPiBJIHRoaW5rIHRoYXQg
Z2l2ZXMgeW91IG1vcmUgZGV0YWlsIHRoYW4gYW55IHZpZGVvIGkgY291bGQgcG9zdC4KPiAKPiBZ
ZXMsIHlvdXIgcG9zdCBpcyByZWFsbHkgYmV0dGVyIHZpZGVvCj4gCj4gCj4gCgoKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:54:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:54:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq678-0003T0-9l; Wed, 25 Jan 2012 16:54:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq677-0003Sk-6g
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:54:25 +0000
Received: from [85.158.138.51:33648] by server-1.bemta-3.messagelabs.com id
	DB/A8-09565-0C3302F4; Wed, 25 Jan 2012 16:54:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327510463!8798493!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20813 invoked from network); 25 Jan 2012 16:54:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:54:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10287393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:54:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 16:54:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Date: Wed, 25 Jan 2012 16:54:22 +0000
In-Reply-To: <EE3AE950D047481283FF742510029D1E@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327510462.24561.351.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>, Doug Magee <djmagee@mageenet.net>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] Future of xend and xl (Was: Re: [Xen-users] VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDA4OjI2ICswMDAwLCBMaWthcnBlbmtvdiBBbGV4YW5kZXIg
d3JvdGU6Cj4g0JfQtNGA0LDQstGB0YLQstGD0LnRgtC1IQo+IAo+INCS0L4g0LLRgtC+0YDQvdC4
0LosINC00LLQsNC00YbQsNGC0Ywg0YfQtdGC0LLQtdGA0YLQvtCz0L4g0Y/QvdCy0LDRgNGPIDIw
MTIg0LPQvtC00LAsINCyIDIwOjQxOjM4INCS0Ysg0L/QuNGB0LDQu9C4Ogo+ICBETT4gSSB1c2Ug
dGhlIHhsIHRvb2xzdGFjaywgbm90IHhtLiAgSSBkb24ndCB0aGluayB4bSBpcyBiZWluZyBhY3Rp
dmVseQo+ICBETT4gbWFpbnRhaW5lZCwgYXQgbGVhc3Qgbm90IGZvciBjdXJyZW50IHJlbGVhc2Vz
Lgo+IAo+IFlvdSBjYW4gaW4gYSBudXRzaGVsbCB3aGF0IGJldHRlciB4bCB4bT8KCnhtIChhbmQg
dGhlIHVuZGVybHlpbmcgeGVuZCBkYWVtb24pIGhhdmUgYmVlbiBlZmZlY3RpdmVseSB1bm1haW50
YWluZWQKc2luY2UgWGVuIDMuNCBvciBwZXJoYXBzIGV2ZW4gZWFybGllciAod2UgdGFrZSBiYW5k
LWFpZHMgYW5kIG9idmlvdXMKZml4dXBzIGJ1dCBubyBwcm9wZXIgbWFpbnRlbmFuY2UgaGFzIGJl
ZW4gb2NjdXJyaW5nKS4KCkluIHRoZSBvcGluaW9uIG9mIHRoZSBjb3JlIGRldmVsb3BlcnMgeGVu
ZCBpcyB1bm1haW50YWluYWJsZSBhbmQgc28gd2UKaGF2ZSBjaG9zZW4gdG8gZm9jdXMgb3VyIGVm
Zm9ydHMgb24gbGlieGwgKGEgbGlicmFyeSBkZXNpZ25lZCB0byBwcm92aWRlCmEgY29tbW9uICJi
b3R0b20gdGhpcmQiIGZvciBhbnkgWGVuIHRvb2xzdGFjaykgYW5kIHRoZSB4bCB0b29sc3RhY2sg
dGhhdAppcyBidWlsdCB1c2luZyBpdC4gbGlieGwgaXMgYWxzbyBzdXBwb3J0ZWQgYnkgbGlidmly
dCBhbmQgdGhlcmUgYXJlCnBsYW5zIGZvciB4YXBpICh0aGUgWENQIHRvb2xzdGFjaykgdG8gdXNl
IGl0IGFzIHdlbGwuCgpUaGlzIHdhcyBhbm5vdW5jZWQgaW4gdGhlIFhlbiA0LjEgcmVsZWFzZSBu
b3Rlc1sxXSBhbmQgdGhlIHVwZ3JhZGUKZ3VpZGVbMl0uIEluIFhlbiA0LjIgd2UgaGF2ZSBlbmRl
ZCB1cCBmb3JtYWxseSBkZXByZWNhdGluZyB4ZW5kIHJhdGhlcgp0aGFuIHJlbW92aW5nIGl0IGJ1
dCB5b3Ugc2hvdWxkIGV4cGVjdCB0aGF0IHhlbmQgd2lsbCBiZSByZW1vdmVkIGluIGEKZnV0dXJl
IHJlbGVhc2Ugb2YgWGVuIGFuZCBiZWdpbiBwbGFubmluZyB5b3VyIHRyYW5zaXRpb24gdG8geGwg
KG9yIG9uZQpvZiB0aGUgb3RoZXIgYWx0ZXJuYXRpdmUgdG9vbHN0YWNrcyksIHRlc3RpbmcgdGhl
IGZlYXR1cmVzIHdoaWNoIG1hdHRlcgp0byB5b3UgYW5kIHJlcG9ydGluZyBidWdzL3N1Ym1pdHRp
bmcgcGF0Y2hlcyBhcyBhcHByb3ByaWF0ZS4KCkhvd2V2ZXIgaWYgc29tZW9uZSAob3IgYSB0ZWFt
IG9mIHNvbWVvbmVzKSB3ZXJlIHRvIHN0ZXAgdXAgYW5kIGJlZ2luIHRvCnByb3Blcmx5IG1haW50
YWluIHhlbmQgd2Ugd291bGQgaGF2ZSBubyBvYmplY3Rpb25zIGFuZCB3b3VsZCBiZQpzdXBwb3J0
aXZlIG9mIHRoYXQgZWZmb3J0LiBXZSB3b3VsZCBzdHJvbmdseSByZWNvbW1lbmQgdGhhdCBhbnlv
bmUgd2hvCndhbnRzIHRvIGRvIHRoaXMgY29uc2lkZXJzIHBvcnRpbmcgeGVuZCB0byBsaWJ4bCBh
cyBvbmUgb2YgdGhlaXIgZmlyc3QKYWN0aXZpdGllcy4gSW5pdGlhbCBQeXRob24gYmluZGluZ3Mg
Zm9yIGxpYnhsIGRvIGV4aXN0LCBidXQgaW4gdGhlCmFic2VuY2Ugb2YgYSB4ZW5kIHBvcnQgdGhl
eSBoYXZlIG5vdCBzZWVuIHNpZ25pZmljYW50IHVzZS4KCklhbi4KClsxXSBodHRwOi8vd2lraS54
ZW4ub3JnL3hlbndpa2kvWGVuNC4xClsyXSBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvTWlncmF0
aW9uX0d1aWRlX1RvX1hlbjQuMSsKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:54:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:54:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq678-0003T0-9l; Wed, 25 Jan 2012 16:54:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq677-0003Sk-6g
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:54:25 +0000
Received: from [85.158.138.51:33648] by server-1.bemta-3.messagelabs.com id
	DB/A8-09565-0C3302F4; Wed, 25 Jan 2012 16:54:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327510463!8798493!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20813 invoked from network); 25 Jan 2012 16:54:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:54:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10287393"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:54:22 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 16:54:22 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Likarpenkov Alexander <al@ohosting.org.ua>
Date: Wed, 25 Jan 2012 16:54:22 +0000
In-Reply-To: <EE3AE950D047481283FF742510029D1E@nobody>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327510462.24561.351.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>, Doug Magee <djmagee@mageenet.net>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: [Xen-devel] Future of xend and xl (Was: Re: [Xen-users] VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDA4OjI2ICswMDAwLCBMaWthcnBlbmtvdiBBbGV4YW5kZXIg
d3JvdGU6Cj4g0JfQtNGA0LDQstGB0YLQstGD0LnRgtC1IQo+IAo+INCS0L4g0LLRgtC+0YDQvdC4
0LosINC00LLQsNC00YbQsNGC0Ywg0YfQtdGC0LLQtdGA0YLQvtCz0L4g0Y/QvdCy0LDRgNGPIDIw
MTIg0LPQvtC00LAsINCyIDIwOjQxOjM4INCS0Ysg0L/QuNGB0LDQu9C4Ogo+ICBETT4gSSB1c2Ug
dGhlIHhsIHRvb2xzdGFjaywgbm90IHhtLiAgSSBkb24ndCB0aGluayB4bSBpcyBiZWluZyBhY3Rp
dmVseQo+ICBETT4gbWFpbnRhaW5lZCwgYXQgbGVhc3Qgbm90IGZvciBjdXJyZW50IHJlbGVhc2Vz
Lgo+IAo+IFlvdSBjYW4gaW4gYSBudXRzaGVsbCB3aGF0IGJldHRlciB4bCB4bT8KCnhtIChhbmQg
dGhlIHVuZGVybHlpbmcgeGVuZCBkYWVtb24pIGhhdmUgYmVlbiBlZmZlY3RpdmVseSB1bm1haW50
YWluZWQKc2luY2UgWGVuIDMuNCBvciBwZXJoYXBzIGV2ZW4gZWFybGllciAod2UgdGFrZSBiYW5k
LWFpZHMgYW5kIG9idmlvdXMKZml4dXBzIGJ1dCBubyBwcm9wZXIgbWFpbnRlbmFuY2UgaGFzIGJl
ZW4gb2NjdXJyaW5nKS4KCkluIHRoZSBvcGluaW9uIG9mIHRoZSBjb3JlIGRldmVsb3BlcnMgeGVu
ZCBpcyB1bm1haW50YWluYWJsZSBhbmQgc28gd2UKaGF2ZSBjaG9zZW4gdG8gZm9jdXMgb3VyIGVm
Zm9ydHMgb24gbGlieGwgKGEgbGlicmFyeSBkZXNpZ25lZCB0byBwcm92aWRlCmEgY29tbW9uICJi
b3R0b20gdGhpcmQiIGZvciBhbnkgWGVuIHRvb2xzdGFjaykgYW5kIHRoZSB4bCB0b29sc3RhY2sg
dGhhdAppcyBidWlsdCB1c2luZyBpdC4gbGlieGwgaXMgYWxzbyBzdXBwb3J0ZWQgYnkgbGlidmly
dCBhbmQgdGhlcmUgYXJlCnBsYW5zIGZvciB4YXBpICh0aGUgWENQIHRvb2xzdGFjaykgdG8gdXNl
IGl0IGFzIHdlbGwuCgpUaGlzIHdhcyBhbm5vdW5jZWQgaW4gdGhlIFhlbiA0LjEgcmVsZWFzZSBu
b3Rlc1sxXSBhbmQgdGhlIHVwZ3JhZGUKZ3VpZGVbMl0uIEluIFhlbiA0LjIgd2UgaGF2ZSBlbmRl
ZCB1cCBmb3JtYWxseSBkZXByZWNhdGluZyB4ZW5kIHJhdGhlcgp0aGFuIHJlbW92aW5nIGl0IGJ1
dCB5b3Ugc2hvdWxkIGV4cGVjdCB0aGF0IHhlbmQgd2lsbCBiZSByZW1vdmVkIGluIGEKZnV0dXJl
IHJlbGVhc2Ugb2YgWGVuIGFuZCBiZWdpbiBwbGFubmluZyB5b3VyIHRyYW5zaXRpb24gdG8geGwg
KG9yIG9uZQpvZiB0aGUgb3RoZXIgYWx0ZXJuYXRpdmUgdG9vbHN0YWNrcyksIHRlc3RpbmcgdGhl
IGZlYXR1cmVzIHdoaWNoIG1hdHRlcgp0byB5b3UgYW5kIHJlcG9ydGluZyBidWdzL3N1Ym1pdHRp
bmcgcGF0Y2hlcyBhcyBhcHByb3ByaWF0ZS4KCkhvd2V2ZXIgaWYgc29tZW9uZSAob3IgYSB0ZWFt
IG9mIHNvbWVvbmVzKSB3ZXJlIHRvIHN0ZXAgdXAgYW5kIGJlZ2luIHRvCnByb3Blcmx5IG1haW50
YWluIHhlbmQgd2Ugd291bGQgaGF2ZSBubyBvYmplY3Rpb25zIGFuZCB3b3VsZCBiZQpzdXBwb3J0
aXZlIG9mIHRoYXQgZWZmb3J0LiBXZSB3b3VsZCBzdHJvbmdseSByZWNvbW1lbmQgdGhhdCBhbnlv
bmUgd2hvCndhbnRzIHRvIGRvIHRoaXMgY29uc2lkZXJzIHBvcnRpbmcgeGVuZCB0byBsaWJ4bCBh
cyBvbmUgb2YgdGhlaXIgZmlyc3QKYWN0aXZpdGllcy4gSW5pdGlhbCBQeXRob24gYmluZGluZ3Mg
Zm9yIGxpYnhsIGRvIGV4aXN0LCBidXQgaW4gdGhlCmFic2VuY2Ugb2YgYSB4ZW5kIHBvcnQgdGhl
eSBoYXZlIG5vdCBzZWVuIHNpZ25pZmljYW50IHVzZS4KCklhbi4KClsxXSBodHRwOi8vd2lraS54
ZW4ub3JnL3hlbndpa2kvWGVuNC4xClsyXSBodHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvTWlncmF0
aW9uX0d1aWRlX1RvX1hlbjQuMSsKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:55:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:55:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq67p-0003Zm-EK; Wed, 25 Jan 2012 16:55: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 1Rq67n-0003Yn-GN
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:55:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327510499!12525198!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4569 invoked from network); 25 Jan 2012 16:54: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;
	25 Jan 2012 16:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10287411"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:54: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, 25 Jan 2012 16:54:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 16:54:56 +0000
In-Reply-To: <c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
	<c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327510496.24561.352.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "juergen.gross@ts.fujitsu.com" <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: remove
 libxl_domain_create_info.poolname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 14:43 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1327329346 0
> # Node ID c91bee33280debdfe602d28e48318c03ddf0f4c9
> # Parent  4bb2b6a04ec02c3502c1825e2736df54870229e5
> libxl: remove libxl_domain_create_info.poolname
> 
> It is redundant with poolid and allowing the user to specify both
> opens up the possibility of a disconnect.
> 
> Also default c_info->poolid to -1 (no pool) instead of defaulting to 0 in the
> library and overriding in the toolstack.

The above seems to be a false assumption -- the correct default is 0,
libxl does not actually treat -1 as special and xen always creates a
single pool on boot.

Found by actually testing without using a pool option which also showed
up that the option parsing in xl was wrong, we cannot call
libxl_cpupoolid_to_name on an invalid pool (which is the case if no pool
is given).

Corrected patch follows.

8<---------------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327510469 0
# Node ID 4b54a3680947f9cf24340a3f7e458afc948c7165
# Parent  3f0d2ed701104e7e37560a3262bc7bcd7da5b90b
libxl: remove libxl_domain_create_info.poolname

It is redundant with poolid and allowing the user to specify both
opens up the possibility of a disconnect.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 3f0d2ed70110 -r 4b54a3680947 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 25 16:28:58 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 25 16:54:29 2012 +0000
@@ -438,8 +438,9 @@ retry_transaction:
 
     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));
-    if (info->poolname)
-        xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/pool_name", vm_path), info->poolname, strlen(info->poolname));
+    if (info->poolid != -1)
+        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
+                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
 
     libxl__xs_writev(gc, t, dom_path, info->xsdata);
     libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
diff -r 3f0d2ed70110 -r 4b54a3680947 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 25 16:28:58 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 25 16:54:29 2012 +0000
@@ -156,7 +156,6 @@ libxl_domain_create_info = Struct("domai
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
-    ("poolname",     string),
     ])
 
 libxl_domain_build_info = Struct("domain_build_info",[
diff -r 3f0d2ed70110 -r 4b54a3680947 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:28:58 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:54:29 2012 +0000
@@ -315,7 +315,7 @@ static void printf_info(int domid,
         printf("\t(uuid <unknown>)\n");
     }
 
-    printf("\t(cpupool %s)\n", c_info->poolname);
+    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
     if (c_info->xsdata)
         printf("\t(xsdata contains data)\n");
     else
@@ -643,8 +643,7 @@ static void parse_config_data(const char
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
-    c_info->poolname = libxl_cpupoolid_to_name(ctx, c_info->poolid);
-    if (!c_info->poolname) {
+    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
         fprintf(stderr, "Illegal pool specified\n");
         exit(1);
     }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:55:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16:55:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq67p-0003Zm-EK; Wed, 25 Jan 2012 16:55: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 1Rq67n-0003Yn-GN
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:55:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327510499!12525198!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4569 invoked from network); 25 Jan 2012 16:54: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;
	25 Jan 2012 16:54:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10287411"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16:54: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, 25 Jan 2012 16:54:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 16:54:56 +0000
In-Reply-To: <c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
References: <patchbomb.1327329788@cosworth.uk.xensource.com>
	<c91bee33280debdfe602.1327329789@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327510496.24561.352.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "juergen.gross@ts.fujitsu.com" <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] libxl: remove
 libxl_domain_create_info.poolname
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-23 at 14:43 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1327329346 0
> # Node ID c91bee33280debdfe602d28e48318c03ddf0f4c9
> # Parent  4bb2b6a04ec02c3502c1825e2736df54870229e5
> libxl: remove libxl_domain_create_info.poolname
> 
> It is redundant with poolid and allowing the user to specify both
> opens up the possibility of a disconnect.
> 
> Also default c_info->poolid to -1 (no pool) instead of defaulting to 0 in the
> library and overriding in the toolstack.

The above seems to be a false assumption -- the correct default is 0,
libxl does not actually treat -1 as special and xen always creates a
single pool on boot.

Found by actually testing without using a pool option which also showed
up that the option parsing in xl was wrong, we cannot call
libxl_cpupoolid_to_name on an invalid pool (which is the case if no pool
is given).

Corrected patch follows.

8<---------------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327510469 0
# Node ID 4b54a3680947f9cf24340a3f7e458afc948c7165
# Parent  3f0d2ed701104e7e37560a3262bc7bcd7da5b90b
libxl: remove libxl_domain_create_info.poolname

It is redundant with poolid and allowing the user to specify both
opens up the possibility of a disconnect.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 3f0d2ed70110 -r 4b54a3680947 tools/libxl/libxl_create.c
--- a/tools/libxl/libxl_create.c	Wed Jan 25 16:28:58 2012 +0000
+++ b/tools/libxl/libxl_create.c	Wed Jan 25 16:54:29 2012 +0000
@@ -438,8 +438,9 @@ retry_transaction:
 
     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));
-    if (info->poolname)
-        xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/pool_name", vm_path), info->poolname, strlen(info->poolname));
+    if (info->poolid != -1)
+        libxl__xs_write(gc, t, libxl__sprintf(gc, "%s/pool_name", vm_path),
+                        "%s", libxl__cpupoolid_to_name(gc, info->poolid));
 
     libxl__xs_writev(gc, t, dom_path, info->xsdata);
     libxl__xs_writev(gc, t, libxl__sprintf(gc, "%s/platform", dom_path), info->platformdata);
diff -r 3f0d2ed70110 -r 4b54a3680947 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 25 16:28:58 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 25 16:54:29 2012 +0000
@@ -156,7 +156,6 @@ libxl_domain_create_info = Struct("domai
     ("xsdata",       libxl_key_value_list),
     ("platformdata", libxl_key_value_list),
     ("poolid",       uint32),
-    ("poolname",     string),
     ])
 
 libxl_domain_build_info = Struct("domain_build_info",[
diff -r 3f0d2ed70110 -r 4b54a3680947 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:28:58 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:54:29 2012 +0000
@@ -315,7 +315,7 @@ static void printf_info(int domid,
         printf("\t(uuid <unknown>)\n");
     }
 
-    printf("\t(cpupool %s)\n", c_info->poolname);
+    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
     if (c_info->xsdata)
         printf("\t(xsdata contains data)\n");
     else
@@ -643,8 +643,7 @@ static void parse_config_data(const char
         c_info->poolid = -1;
         cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
     }
-    c_info->poolname = libxl_cpupoolid_to_name(ctx, c_info->poolid);
-    if (!c_info->poolname) {
+    if (!libxl_cpupoolid_to_name(ctx, c_info->poolid)) {
         fprintf(stderr, "Illegal pool specified\n");
         exit(1);
     }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 16:57:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq69P-000423-Vx; Wed, 25 Jan 2012 16:56: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 1Rq69O-0003zz-AL
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:56:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327510599!12562528!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24002 invoked from network); 25 Jan 2012 16:56:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:56:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10287448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16: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; Wed, 25 Jan 2012 16:56: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
	1Rq69G-00016z-6g; Wed, 25 Jan 2012 16:56:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rq69G-0008RW-1h;
	Wed, 25 Jan 2012 16:56:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20256.13379.152546.739333@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 16:56:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
In-Reply-To: <20256.5502.898249.801471@mariner.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
	<1326969875.17599.50.camel@zakaz.uk.xensource.com>
	<20254.59933.408785.834@mariner.uk.xensource.com>
	<1327488533.24561.272.camel@zakaz.uk.xensource.com>
	<20256.5502.898249.801471@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> > On Tue, 2012-01-24 at 17:27 +0000, Ian Jackson wrote:
> > > If ao_how is non-NULL then these functions cannot return 0.
> > > If it is NULL they cannot return ASYNC_INPROGRESS.
> > > 
> > > I chose to use a new exit status because it seemed safer but that's a
> > > matter of taste and if you prefer I could return 0 for that case.
> > 
> > I'm undecided (plus it seems a bit like bikeshedding). I certainly
> > prefer either 0 or {LIBXL_}ASYNC_IN_PROGRESS to ERROR_ASYNC_IN_PROGRESS
> > though.
> 
> OK, I'll rename it.

Having thought about this some more, and particularly about what
callers would be likely to want, I decided it would be better to
abolish it and return 0 instead.

So I will 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 Jan 25 16:57:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 16: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 1Rq69P-000423-Vx; Wed, 25 Jan 2012 16:56: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 1Rq69O-0003zz-AL
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 16:56:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327510599!12562528!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24002 invoked from network); 25 Jan 2012 16:56:39 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 16:56:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10287448"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 16: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; Wed, 25 Jan 2012 16:56: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
	1Rq69G-00016z-6g; Wed, 25 Jan 2012 16:56:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rq69G-0008RW-1h;
	Wed, 25 Jan 2012 16:56:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20256.13379.152546.739333@mariner.uk.xensource.com>
Date: Wed, 25 Jan 2012 16:56:35 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
In-Reply-To: <20256.5502.898249.801471@mariner.uk.xensource.com>
References: <1326482728-10733-1-git-send-email-ian.jackson@eu.citrix.com>
	<1326482728-10733-7-git-send-email-ian.jackson@eu.citrix.com>
	<1326969875.17599.50.camel@zakaz.uk.xensource.com>
	<20254.59933.408785.834@mariner.uk.xensource.com>
	<1327488533.24561.272.camel@zakaz.uk.xensource.com>
	<20256.5502.898249.801471@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running
 operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure"):
> > On Tue, 2012-01-24 at 17:27 +0000, Ian Jackson wrote:
> > > If ao_how is non-NULL then these functions cannot return 0.
> > > If it is NULL they cannot return ASYNC_INPROGRESS.
> > > 
> > > I chose to use a new exit status because it seemed safer but that's a
> > > matter of taste and if you prefer I could return 0 for that case.
> > 
> > I'm undecided (plus it seems a bit like bikeshedding). I certainly
> > prefer either 0 or {LIBXL_}ASYNC_IN_PROGRESS to ERROR_ASYNC_IN_PROGRESS
> > though.
> 
> OK, I'll rename it.

Having thought about this some more, and particularly about what
callers would be likely to want, I decided it would be better to
abolish it and return 0 instead.

So I will 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 Jan 25 17:07:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:07:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6JN-0004o7-5O; Wed, 25 Jan 2012 17:07:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rq6JL-0004nz-Ok
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:07:03 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327511216!12554838!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7503 invoked from network); 25 Jan 2012 17:06:56 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-8.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 17:06:56 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0PH6tg9027640
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 12:06:55 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0PH6t8f003570
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 12:06:55 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012512065413531
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 12:06:54 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 12:06:55 -0500
Message-Id: <5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>
To: xen-devel@lists.xensource.com
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 problem also happens in Fedora 16. Should we be making bugzilla entries for problems with Xen?

On Jan 25, 2012, at 11:47 AM, xen-devel-request@lists.xensource.com wrote:

> Yes, let's stop this thread here :-).  This is a downstream issue.
> 
>> I got your comment that you'd look for fixes in the Opensuse 12.2
>> time-frame.  As I read the openSUSE Roadmap, the scheduled release date
>> for openSUSE 12.2 is July 2012.
>> 
>> We won't switch to a new OS release until after it's in production.  We
>> _are_ willing to use a few non-production repositories for key packages.
>> Xen's one of them.
>> 
>> Should we plan to see these Xen fixes in a shorter timeframe in a repo
>> built for use with 12.1 release/kernel prior to that 12.2 release date?
> 
> We do maintenance on virtualization packages in openSUSE, so a fix for
> this could be delivered to the openSUSE12.1 update repository.  But the
> process starts with a bugzilla entry...

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:07:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:07:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6JN-0004o7-5O; Wed, 25 Jan 2012 17:07:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rq6JL-0004nz-Ok
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:07:03 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327511216!12554838!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7503 invoked from network); 25 Jan 2012 17:06:56 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-8.tower-216.messagelabs.com with SMTP;
	25 Jan 2012 17:06:56 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0PH6tg9027640
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 12:06:55 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0PH6t8f003570
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 12:06:55 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012512065413531
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 12:06:54 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 12:06:55 -0500
Message-Id: <5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>
To: xen-devel@lists.xensource.com
X-Mailer: Apple Mail (2.1084)
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 problem also happens in Fedora 16. Should we be making bugzilla entries for problems with Xen?

On Jan 25, 2012, at 11:47 AM, xen-devel-request@lists.xensource.com wrote:

> Yes, let's stop this thread here :-).  This is a downstream issue.
> 
>> I got your comment that you'd look for fixes in the Opensuse 12.2
>> time-frame.  As I read the openSUSE Roadmap, the scheduled release date
>> for openSUSE 12.2 is July 2012.
>> 
>> We won't switch to a new OS release until after it's in production.  We
>> _are_ willing to use a few non-production repositories for key packages.
>> Xen's one of them.
>> 
>> Should we plan to see these Xen fixes in a shorter timeframe in a repo
>> built for use with 12.1 release/kernel prior to that 12.2 release date?
> 
> We do maintenance on virtualization packages in openSUSE, so a fix for
> this could be delivered to the openSUSE12.1 update repository.  But the
> process starts with a bugzilla entry...

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:16:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17: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 1Rq6SO-000511-9e; Wed, 25 Jan 2012 17:16:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6SM-00050m-Ju
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:16:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327511713!62469890!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1365 invoked from network); 25 Jan 2012 17:15:13 -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 Jan 2012 17:15:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10287847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 17:16:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 17:16:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Wed, 25 Jan 2012 17:16:21 +0000
In-Reply-To: <5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>
	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327511781.24561.354.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please don't top post.

On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
> This problem also happens in Fedora 16. Should we be making bugzilla
> entries for problems with Xen?

There is more than one reason why networking may not work for you so
there isn't necessarily any reason (yet) to think you are seeing the
same issue.

I think xen-users or an equivalent fedora list would be an appropriate
forum for your bug report in the first instance.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:16:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17: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 1Rq6SO-000511-9e; Wed, 25 Jan 2012 17:16:24 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6SM-00050m-Ju
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:16:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327511713!62469890!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1365 invoked from network); 25 Jan 2012 17:15:13 -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 Jan 2012 17:15:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10287847"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 17:16:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 17:16:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
Date: Wed, 25 Jan 2012 17:16:21 +0000
In-Reply-To: <5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>
	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327511781.24561.354.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Please don't top post.

On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
> This problem also happens in Fedora 16. Should we be making bugzilla
> entries for problems with Xen?

There is more than one reason why networking may not work for you so
there isn't necessarily any reason (yet) to think you are seeing the
same issue.

I think xen-users or an equivalent fedora list would be an appropriate
forum for your bug report in the first instance.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:23:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:23:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6ZB-0005Pj-RY; Wed, 25 Jan 2012 17:23:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rq6Z9-0005PX-PH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:23:24 +0000
Received: from [85.158.139.83:60483] by server-8.bemta-5.messagelabs.com id
	CF/4E-20787-B8A302F4; Wed, 25 Jan 2012 17:23:23 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327512200!12391830!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14916 invoked from network); 25 Jan 2012 17:23:21 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 17:23:21 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PHNJXJ015562;
	Wed, 25 Jan 2012 12:23:19 -0500
Received: from [192.168.37.18] ([192.168.37.18]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Wed, 25 Jan 2012 12:22:57 -0500
Message-ID: <1327512187.2452.28.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Tobias Geiger <tobias.geiger@vido.info>
Date: Wed, 25 Jan 2012 12:23:07 -0500
In-Reply-To: <201201251039.54148.tobias.geiger@vido.info>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<1327429905.7929.5.camel@mnetdjm5.mageenet.host>
	<201201251039.54148.tobias.geiger@vido.info>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2012 17:22:57.0658 (UTC)
	FILETIME=[FB1655A0:01CCDB85]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 04:39 -0500, Tobias Geiger wrote:
> Hello Doug!
> 
> see below ....
> 
> 
> Am Dienstag, 24. Januar 2012, 19:31:45 schrieb Doug Magee:
> > On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > > > Both setup have the "flaw" that they only work once -
> meaning
> > >
> > > you
> > >
> > > > > can't reboot
> > > > >
> > > > > > your DomU , cause after the reboot the passed-through Card
> > >
> > > doesnt
> > >
> > > > > have correct
> > > > >
> > > > > > 3D-Accelleration any more (was/is the case with NVIDIA and
> ATI,
> > > > >
> > > > > Windows XP and
> > > > >
> > > > > > Windows7 )
> > > > >
> > > > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > > > >
> > > > > Anybody had luck with passing the card more than once to a
> guest?
> > >
> > > With
> > >
> > > > > any random set of patches?
> > >
> > > I was a bit un-percice regarding the "reboot" issue:
> > >
> > > The passing-through itself works even after a reboot of DomU - the
> > > rebooted
> > > System spits out its Graphics normaly through the passed-through
> Card
> > > (NVIDA
> > > or ATI doesnt matter here) ; BUT:
> > > After a reboot it doesn't work properly. Meaning: Slow 3d
> Performance,
> > > i.e.
> > > unsable for real 3d apps, even a 3d Desktop;
> > > For example, when the Card gives you 70fps in a Benchmark after a
> > > fresh Cold
> > > Boot, it only gives you 5-10fps after a reboot, this will be that
> low
> > > until
> > > you reboot Dom0 also, not only DomU;
> > >
> > > hopefully i described the scenario better now...
> >
> > Ah, got it.  I hadn't been doing anything 3D intensive, only running
> the
> > Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.
> I
> > get the same results (within a fraction of a %) after a cold boot as
> i
> > do after rebooting multiple times, and always very close to native.
> It
> > seems i don't have the problem you're having.
> >
> > Do you get any different log messages after a reboot (xl dmesg, dom0
> > dmesg, qemu log)?  Have you tried with iommu=verbose to see if
> there's
> > any more useful information there?
> >
> 
> Cool. Finally someone NOT suffering the
> reboot-performance-regression-Problem
> :)
> 
> I searched back and forth, rebooted DomU like crazy, diff'ed the
> dmesg/xldmesg/qemu-dm - but no difference :(
> 
> What kind of ATI Card are you passing through?

It's an HIS incarnation of the Radeon 4770. lspci -vvv output at the
bottom of the message.

> 
> 
> Would be nice to find out whats causing this...

Does your device/bus support FLR?  Do you get any messages like the
following when you use xl create/xl pci-attach?

libxl: error: libxl_pci.c:... The kernel doesn't support reset from
sysfs for PCI device ...

> 
> Greetings!
> Tobias

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770
[RV740] (prog-if 00 [VGA controller])
	Subsystem: ATI Technologies Inc Device 0d00
	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 d0000000 (64-bit, prefetchable) [size=256M]
	Region 2: Memory at fbb20000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at e000 [size=256]
	Expansion ROM at fbb00000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1
unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, 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 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 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: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee00438  Data: 0000
	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
Len=010 <?>
	Kernel driver in use: pciback
	Kernel modules: radeon



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:23:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:23:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6ZB-0005Pj-RY; Wed, 25 Jan 2012 17:23:25 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rq6Z9-0005PX-PH
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:23:24 +0000
Received: from [85.158.139.83:60483] by server-8.bemta-5.messagelabs.com id
	CF/4E-20787-B8A302F4; Wed, 25 Jan 2012 17:23:23 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327512200!12391830!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14916 invoked from network); 25 Jan 2012 17:23:21 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-5.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 17:23:21 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PHNJXJ015562;
	Wed, 25 Jan 2012 12:23:19 -0500
Received: from [192.168.37.18] ([192.168.37.18]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Wed, 25 Jan 2012 12:22:57 -0500
Message-ID: <1327512187.2452.28.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Tobias Geiger <tobias.geiger@vido.info>
Date: Wed, 25 Jan 2012 12:23:07 -0500
In-Reply-To: <201201251039.54148.tobias.geiger@vido.info>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201241537.24507.tobias.geiger@vido.info>
	<1327429905.7929.5.camel@mnetdjm5.mageenet.host>
	<201201251039.54148.tobias.geiger@vido.info>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2012 17:22:57.0658 (UTC)
	FILETIME=[FB1655A0:01CCDB85]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 04:39 -0500, Tobias Geiger wrote:
> Hello Doug!
> 
> see below ....
> 
> 
> Am Dienstag, 24. Januar 2012, 19:31:45 schrieb Doug Magee:
> > On Tue, 2012-01-24 at 09:37 -0500, Tobias Geiger wrote:
> > > > > > Both setup have the "flaw" that they only work once -
> meaning
> > >
> > > you
> > >
> > > > > can't reboot
> > > > >
> > > > > > your DomU , cause after the reboot the passed-through Card
> > >
> > > doesnt
> > >
> > > > > have correct
> > > > >
> > > > > > 3D-Accelleration any more (was/is the case with NVIDIA and
> ATI,
> > > > >
> > > > > Windows XP and
> > > > >
> > > > > > Windows7 )
> > > > >
> > > > > For me it was with ATI with Windows7. Hadn't tried other OSes.
> > > > >
> > > > > Anybody had luck with passing the card more than once to a
> guest?
> > >
> > > With
> > >
> > > > > any random set of patches?
> > >
> > > I was a bit un-percice regarding the "reboot" issue:
> > >
> > > The passing-through itself works even after a reboot of DomU - the
> > > rebooted
> > > System spits out its Graphics normaly through the passed-through
> Card
> > > (NVIDA
> > > or ATI doesnt matter here) ; BUT:
> > > After a reboot it doesn't work properly. Meaning: Slow 3d
> Performance,
> > > i.e.
> > > unsable for real 3d apps, even a 3d Desktop;
> > > For example, when the Card gives you 70fps in a Benchmark after a
> > > fresh Cold
> > > Boot, it only gives you 5-10fps after a reboot, this will be that
> low
> > > until
> > > you reboot Dom0 also, not only DomU;
> > >
> > > hopefully i described the scenario better now...
> >
> > Ah, got it.  I hadn't been doing anything 3D intensive, only running
> the
> > Aero desktop.  I installed 3DMark Vantage and ran a couple of tests.
> I
> > get the same results (within a fraction of a %) after a cold boot as
> i
> > do after rebooting multiple times, and always very close to native.
> It
> > seems i don't have the problem you're having.
> >
> > Do you get any different log messages after a reboot (xl dmesg, dom0
> > dmesg, qemu log)?  Have you tried with iommu=verbose to see if
> there's
> > any more useful information there?
> >
> 
> Cool. Finally someone NOT suffering the
> reboot-performance-regression-Problem
> :)
> 
> I searched back and forth, rebooted DomU like crazy, diff'ed the
> dmesg/xldmesg/qemu-dm - but no difference :(
> 
> What kind of ATI Card are you passing through?

It's an HIS incarnation of the Radeon 4770. lspci -vvv output at the
bottom of the message.

> 
> 
> Would be nice to find out whats causing this...

Does your device/bus support FLR?  Do you get any messages like the
following when you use xl create/xl pci-attach?

libxl: error: libxl_pci.c:... The kernel doesn't support reset from
sysfs for PCI device ...

> 
> Greetings!
> Tobias

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770
[RV740] (prog-if 00 [VGA controller])
	Subsystem: ATI Technologies Inc Device 0d00
	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 d0000000 (64-bit, prefetchable) [size=256M]
	Region 2: Memory at fbb20000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at e000 [size=256]
	Expansion ROM at fbb00000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1
unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, 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 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive-
BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
		LnkCtl2: Target Link Speed: 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: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
		Address: 00000000fee00438  Data: 0000
	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
Len=010 <?>
	Kernel driver in use: pciback
	Kernel modules: radeon



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a4-0005Xd-Il; Wed, 25 Jan 2012 17:24:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a3-0005Ws-Aq
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:19 +0000
Received: from [85.158.138.51:6269] by server-6.bemta-3.messagelabs.com id
	40/E5-31032-2CA302F4; Wed, 25 Jan 2012 17:24:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19368 invoked from network); 25 Jan 2012 17:24:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076312"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:15 -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
	q0PHOCM9006355;	Wed, 25 Jan 2012 09:24:14 -0800
MIME-Version: 1.0
X-Mercurial-Node: b9973edc7528e5233698fefd234be19dd6d6bcee
Message-ID: <b9973edc7528e5233698.1327512252@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:12 +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 9] libxl: de-hard-tabbify idl.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327510508 0
# Node ID b9973edc7528e5233698fefd234be19dd6d6bcee
# Parent  9a366717e0c0a0e0261796669e9e96c0ba514923
libxl: de-hard-tabbify idl.txt

Hard tabs were in the minority, nuke them.

Also we no longer supply the inaddr_ip builtin.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
--- a/tools/libxl/idl.txt
+++ b/tools/libxl/idl.txt
@@ -2,10 +2,9 @@ libxl IDL
 ---------
 
 Each type in the libxl interface is represented by an object of type
-idl.Type (or a subclass thereof). Every local variable defined by
-the .idl file must be an instance of idl.Type (e.g. you may not
-define Python functions or any other construct other than defining
-variables)
+idl.Type (or a subclass thereof). Every local variable defined by the
+.idl file must be an instance of idl.Type (e.g. you may not define
+Python functions or any other construct other than defining variables)
 
 The name of the type must be passed as the first argument to the
 constructor when defining a new type. The name given should not
@@ -16,9 +15,9 @@ The Type.typename contains the C name of
 namespace element while Type.rawname is always set to the 'base' name
 of the type.
 
-The idl.Type base class has several other properties which apply
-to all types. The properties are set by passing a named parameter to
-the constructor.
+The idl.Type base class has several other properties which apply to
+all types. The properties are set by passing a named parameter to the
+constructor.
 
 Type.namespace: (default: "libxl_")
 
@@ -81,7 +80,7 @@ libxltype.Enumeration
 
   Each EnumerationValue has the following properties:
 
-    EnumerationValue.enum	Reference to containing Enumeration
+    EnumerationValue.enum       Reference to containing Enumeration
     EnumerationValue.name       The C name of this value, including
                                     the namespace and typename of the
                                     containing Enumeration (e.g.
@@ -90,10 +89,10 @@ libxltype.Enumeration
                                     the namespace but including the
                                     typename of the containing
                                     Enumeration (e.g. "FOOENUM_VALUE")
-    EnumerationValue.valuename	The name of this value, excluding the
-				    name of the containing Enumeration
-				    and any namespace (e.g. "VALUE")
-    EnumerationValue.value	The integer value associated with this name.
+    EnumerationValue.valuename  The name of this value, excluding the
+                                    name of the containing Enumeration
+                                    and any namespace (e.g. "VALUE")
+    EnumerationValue.value      The integer value associated with this name.
 
 libxltype.Aggregate
 
@@ -106,10 +105,10 @@ libxltype.Aggregate
 
  Each field has the following properties:
 
-  Field.type	The type of the member (a idl.Type).
+  Field.type    The type of the member (a idl.Type).
   Field.name    The name of the member (can be None for anonymous
-		fields).
-  Field.const	Boolean, true if the member is const.
+                fields).
+  Field.const   Boolean, true if the member is const.
 
 libxltype.Struct
 
@@ -139,15 +138,13 @@ Standard Types
 
 Several standard types a predefined. They are
 
-void			(void pointer type)
+void                    (void pointer type)
 bool
 size_t
-integer			24 bit signed integer.
+integer                 24 bit signed integer.
 
-uint{8,16,32,64}	uint{8,16,32,64}_t
+uint{8,16,32,64}        uint{8,16,32,64}_t
 
-domid			Domain ID
+domid                   Domain ID
 
-string			NULL terminated string
-
-inaddr_ip		struct in_addr
+string                  NULL terminated string

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a4-0005Xd-Il; Wed, 25 Jan 2012 17:24:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a3-0005Ws-Aq
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:19 +0000
Received: from [85.158.138.51:6269] by server-6.bemta-3.messagelabs.com id
	40/E5-31032-2CA302F4; Wed, 25 Jan 2012 17:24:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19368 invoked from network); 25 Jan 2012 17:24:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076312"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:15 -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
	q0PHOCM9006355;	Wed, 25 Jan 2012 09:24:14 -0800
MIME-Version: 1.0
X-Mercurial-Node: b9973edc7528e5233698fefd234be19dd6d6bcee
Message-ID: <b9973edc7528e5233698.1327512252@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:12 +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 9] libxl: de-hard-tabbify idl.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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327510508 0
# Node ID b9973edc7528e5233698fefd234be19dd6d6bcee
# Parent  9a366717e0c0a0e0261796669e9e96c0ba514923
libxl: de-hard-tabbify idl.txt

Hard tabs were in the minority, nuke them.

Also we no longer supply the inaddr_ip builtin.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
--- a/tools/libxl/idl.txt
+++ b/tools/libxl/idl.txt
@@ -2,10 +2,9 @@ libxl IDL
 ---------
 
 Each type in the libxl interface is represented by an object of type
-idl.Type (or a subclass thereof). Every local variable defined by
-the .idl file must be an instance of idl.Type (e.g. you may not
-define Python functions or any other construct other than defining
-variables)
+idl.Type (or a subclass thereof). Every local variable defined by the
+.idl file must be an instance of idl.Type (e.g. you may not define
+Python functions or any other construct other than defining variables)
 
 The name of the type must be passed as the first argument to the
 constructor when defining a new type. The name given should not
@@ -16,9 +15,9 @@ The Type.typename contains the C name of
 namespace element while Type.rawname is always set to the 'base' name
 of the type.
 
-The idl.Type base class has several other properties which apply
-to all types. The properties are set by passing a named parameter to
-the constructor.
+The idl.Type base class has several other properties which apply to
+all types. The properties are set by passing a named parameter to the
+constructor.
 
 Type.namespace: (default: "libxl_")
 
@@ -81,7 +80,7 @@ libxltype.Enumeration
 
   Each EnumerationValue has the following properties:
 
-    EnumerationValue.enum	Reference to containing Enumeration
+    EnumerationValue.enum       Reference to containing Enumeration
     EnumerationValue.name       The C name of this value, including
                                     the namespace and typename of the
                                     containing Enumeration (e.g.
@@ -90,10 +89,10 @@ libxltype.Enumeration
                                     the namespace but including the
                                     typename of the containing
                                     Enumeration (e.g. "FOOENUM_VALUE")
-    EnumerationValue.valuename	The name of this value, excluding the
-				    name of the containing Enumeration
-				    and any namespace (e.g. "VALUE")
-    EnumerationValue.value	The integer value associated with this name.
+    EnumerationValue.valuename  The name of this value, excluding the
+                                    name of the containing Enumeration
+                                    and any namespace (e.g. "VALUE")
+    EnumerationValue.value      The integer value associated with this name.
 
 libxltype.Aggregate
 
@@ -106,10 +105,10 @@ libxltype.Aggregate
 
  Each field has the following properties:
 
-  Field.type	The type of the member (a idl.Type).
+  Field.type    The type of the member (a idl.Type).
   Field.name    The name of the member (can be None for anonymous
-		fields).
-  Field.const	Boolean, true if the member is const.
+                fields).
+  Field.const   Boolean, true if the member is const.
 
 libxltype.Struct
 
@@ -139,15 +138,13 @@ Standard Types
 
 Several standard types a predefined. They are
 
-void			(void pointer type)
+void                    (void pointer type)
 bool
 size_t
-integer			24 bit signed integer.
+integer                 24 bit signed integer.
 
-uint{8,16,32,64}	uint{8,16,32,64}_t
+uint{8,16,32,64}        uint{8,16,32,64}_t
 
-domid			Domain ID
+domid                   Domain ID
 
-string			NULL terminated string
-
-inaddr_ip		struct in_addr
+string                  NULL terminated string

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a6-0005Yn-8H; Wed, 25 Jan 2012 17:24:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a4-0005XT-Ru
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:21 +0000
Received: from [85.158.138.51:55809] by server-8.bemta-3.messagelabs.com id
	0A/9B-31878-4CA302F4; Wed, 25 Jan 2012 17:24:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327512257!8802333!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3779 invoked from network); 25 Jan 2012 17:24:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21277756"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:18 -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
	q0PHOCMC006355;	Wed, 25 Jan 2012 09:24:17 -0800
MIME-Version: 1.0
X-Mercurial-Node: d09c5ab835ec6685822c04a140afa1620cca1138
Message-ID: <d09c5ab835ec6685822c.1327512255@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 5 of 9] ocaml: Topology.get returns an array not
 a single element
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327512175 0
# Node ID d09c5ab835ec6685822c04a140afa1620cca1138
# Parent  32e51774992b4d22b07f1ce3ab16880e33aa3794
ocaml: Topology.get returns an array not a single element.

The stub implementation appears to already be correct.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -26,7 +26,7 @@ module Topologyinfo = struct
 		socket : int;
 		node : int;
 	}
-	external get : unit -> t = "stub_xl_topologyinfo"
+	external get : unit -> t array = "stub_xl_topologyinfo"
 end
 
 
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -26,7 +26,7 @@ module Topologyinfo : sig
 		socket : int;
 		node : int;
 	}
-	external get : unit -> t = "stub_xl_topologyinfo"
+	external get : unit -> t array = "stub_xl_topologyinfo"
 end
 
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a6-0005Yn-8H; Wed, 25 Jan 2012 17:24:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a4-0005XT-Ru
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:21 +0000
Received: from [85.158.138.51:55809] by server-8.bemta-3.messagelabs.com id
	0A/9B-31878-4CA302F4; Wed, 25 Jan 2012 17:24:20 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327512257!8802333!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3779 invoked from network); 25 Jan 2012 17:24:19 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21277756"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:18 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:18 -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
	q0PHOCMC006355;	Wed, 25 Jan 2012 09:24:17 -0800
MIME-Version: 1.0
X-Mercurial-Node: d09c5ab835ec6685822c04a140afa1620cca1138
Message-ID: <d09c5ab835ec6685822c.1327512255@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:15 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 5 of 9] ocaml: Topology.get returns an array not
 a single element
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327512175 0
# Node ID d09c5ab835ec6685822c04a140afa1620cca1138
# Parent  32e51774992b4d22b07f1ce3ab16880e33aa3794
ocaml: Topology.get returns an array not a single element.

The stub implementation appears to already be correct.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -26,7 +26,7 @@ module Topologyinfo = struct
 		socket : int;
 		node : int;
 	}
-	external get : unit -> t = "stub_xl_topologyinfo"
+	external get : unit -> t array = "stub_xl_topologyinfo"
 end
 
 
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -26,7 +26,7 @@ module Topologyinfo : sig
 		socket : int;
 		node : int;
 	}
-	external get : unit -> t = "stub_xl_topologyinfo"
+	external get : unit -> t array = "stub_xl_topologyinfo"
 end
 
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a4-0005XI-5K; Wed, 25 Jan 2012 17:24:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a2-0005Wg-JN
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:18 +0000
Received: from [85.158.138.51:6214] by server-11.bemta-3.messagelabs.com id
	B0/12-26051-1CA302F4; Wed, 25 Jan 2012 17:24:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19297 invoked from network); 25 Jan 2012 17:24:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076306"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:13 -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
	q0PHOCM7006355;	Wed, 25 Jan 2012 09:24:12 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:10 +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 9] libxl: API updates + xl: JSON
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A random(ish) colletion of libxl patches.

 - Fixup idl infrastructure naming clash/annoyance
 - Consolidate libxl_button_press and libxl_send_trigger
 - Change the way libxl exposes CPU topology information to be a list
   of CPU (core,node,socket) tuples instead of three lists. This is a
   more sensible representation but is also a bit easier on the
   language bindings.

Plus:

 - Cause xl to use JSON with the "xl create -d" option and similar
   output.

This follows the 20 patches in my "libxl: drop device_model_info"
series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a5-0005YW-Qc; Wed, 25 Jan 2012 17:24:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a4-0005X7-6C
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:20 +0000
Received: from [85.158.138.51:6307] by server-10.bemta-3.messagelabs.com id
	DE/F7-20948-3CA302F4; Wed, 25 Jan 2012 17:24:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19474 invoked from network); 25 Jan 2012 17:24:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076327"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24: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
	q0PHOCMB006355;	Wed, 25 Jan 2012 09:24:16 -0800
MIME-Version: 1.0
X-Mercurial-Node: 32e51774992b4d22b07f1ce3ab16880e33aa3794
Message-ID: <32e51774992b4d22b07f.1327512254@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 4 of 9] ocaml: add helper's for Some/None option
	types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327512173 0
# Node ID 32e51774992b4d22b07f1ce3ab16880e33aa3794
# Parent  a7776e38447d4e633a45b926295f7923c046fbc9
ocaml: add helper's for Some/None option types.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c b/tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -130,6 +130,19 @@ static int string_string_tuple_array_val
 
 #endif
 
+/* Option type support as per http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php */
+#define Val_none Val_int(0)
+#define Some_val(v) Field(v,0)
+
+static value Val_some(value v)
+{
+	CAMLparam1(v);
+	CAMLlocal1(some);
+	some = caml_alloc(1, 0);
+	Store_field(some, 0, v);
+	CAMLreturn(some);
+}
+
 static value Val_mac (libxl_mac *c_val)
 {
 	CAMLparam0();
@@ -205,14 +218,13 @@ static value Val_topologyinfo(libxl_topo
 
 	topologyinfo = caml_alloc_tuple(c_val->coremap.entries);
 	for (i = 0; i < c_val->coremap.entries; i++) {
-		v = Val_int(0); /* None */
+		v = Val_none;
 		if (c_val->coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY) {
 			topology = caml_alloc_tuple(3);
 			Store_field(topology, 0, Val_int(c_val->coremap.array[i]));
 			Store_field(topology, 1, Val_int(c_val->socketmap.array[i]));
 			Store_field(topology, 2, Val_int(c_val->nodemap.array[i]));
-			v = caml_alloc(1, 0); /* Some */
-			Store_field(v, 0, topology);
+			v = Val_some(topology);
 		}
 		Store_field(topologyinfo, i, v);
 	}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a5-0005YW-Qc; Wed, 25 Jan 2012 17:24:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a4-0005X7-6C
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:20 +0000
Received: from [85.158.138.51:6307] by server-10.bemta-3.messagelabs.com id
	DE/F7-20948-3CA302F4; Wed, 25 Jan 2012 17:24:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n,
	ML_RADAR_SPEW_LINKS_18,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19474 invoked from network); 25 Jan 2012 17:24:18 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076327"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:17 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24: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
	q0PHOCMB006355;	Wed, 25 Jan 2012 09:24:16 -0800
MIME-Version: 1.0
X-Mercurial-Node: 32e51774992b4d22b07f1ce3ab16880e33aa3794
Message-ID: <32e51774992b4d22b07f.1327512254@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:14 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 4 of 9] ocaml: add helper's for Some/None option
	types
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327512173 0
# Node ID 32e51774992b4d22b07f1ce3ab16880e33aa3794
# Parent  a7776e38447d4e633a45b926295f7923c046fbc9
ocaml: add helper's for Some/None option types.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c b/tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -130,6 +130,19 @@ static int string_string_tuple_array_val
 
 #endif
 
+/* Option type support as per http://www.linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php */
+#define Val_none Val_int(0)
+#define Some_val(v) Field(v,0)
+
+static value Val_some(value v)
+{
+	CAMLparam1(v);
+	CAMLlocal1(some);
+	some = caml_alloc(1, 0);
+	Store_field(some, 0, v);
+	CAMLreturn(some);
+}
+
 static value Val_mac (libxl_mac *c_val)
 {
 	CAMLparam0();
@@ -205,14 +218,13 @@ static value Val_topologyinfo(libxl_topo
 
 	topologyinfo = caml_alloc_tuple(c_val->coremap.entries);
 	for (i = 0; i < c_val->coremap.entries; i++) {
-		v = Val_int(0); /* None */
+		v = Val_none;
 		if (c_val->coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY) {
 			topology = caml_alloc_tuple(3);
 			Store_field(topology, 0, Val_int(c_val->coremap.array[i]));
 			Store_field(topology, 1, Val_int(c_val->socketmap.array[i]));
 			Store_field(topology, 2, Val_int(c_val->nodemap.array[i]));
-			v = caml_alloc(1, 0); /* Some */
-			Store_field(v, 0, topology);
+			v = Val_some(topology);
 		}
 		Store_field(topologyinfo, i, v);
 	}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a4-0005XI-5K; Wed, 25 Jan 2012 17:24:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a2-0005Wg-JN
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:18 +0000
Received: from [85.158.138.51:6214] by server-11.bemta-3.messagelabs.com id
	B0/12-26051-1CA302F4; Wed, 25 Jan 2012 17:24:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19297 invoked from network); 25 Jan 2012 17:24:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076306"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:13 -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
	q0PHOCM7006355;	Wed, 25 Jan 2012 09:24:12 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:10 +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 9] libxl: API updates + xl: JSON
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A random(ish) colletion of libxl patches.

 - Fixup idl infrastructure naming clash/annoyance
 - Consolidate libxl_button_press and libxl_send_trigger
 - Change the way libxl exposes CPU topology information to be a list
   of CPU (core,node,socket) tuples instead of three lists. This is a
   more sensible representation but is also a bit easier on the
   language bindings.

Plus:

 - Cause xl to use JSON with the "xl create -d" option and similar
   output.

This follows the 20 patches in my "libxl: drop device_model_info"
series.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a5-0005YA-DS; Wed, 25 Jan 2012 17:24:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a4-0005Wt-4O
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:20 +0000
Received: from [85.158.138.51:55787] by server-1.bemta-3.messagelabs.com id
	46/80-09565-3CA302F4; Wed, 25 Jan 2012 17:24:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327512255!8802330!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3750 invoked from network); 25 Jan 2012 17:24:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21277754"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:16 -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
	q0PHOCMA006355;	Wed, 25 Jan 2012 09:24:15 -0800
MIME-Version: 1.0
X-Mercurial-Node: a7776e38447d4e633a45b926295f7923c046fbc9
Message-ID: <a7776e38447d4e633a45.1327512253@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:13 +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 9] libxl: remove libxl_button_press in
 favour of libxl_send_trigger
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327510508 0
# Node ID a7776e38447d4e633a45b926295f7923c046fbc9
# Parent  b9973edc7528e5233698fefd234be19dd6d6bcee
libxl: remove libxl_button_press in favour of libxl_send_trigger.

send_trigger already included all the operations covered by button_press.

Rework send_trigger to take an enum instead of a string.

I stopped short at removing the xl "button-press" command but instead have
marked it as deprecated.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -86,6 +86,8 @@ previously, most commands take I<domain-
 
 =item B<button-press> I<domain-id> I<button>
 
+I<This command is deprecated. Please use C<xl trigger> in preference>
+
 Indicate an ACPI button press to the domain. I<button> is may be 'power' or
 'sleep'. This command is only available for HVM domains.
 
@@ -448,7 +450,7 @@ It can be used to send SysRq requests to
 your Linux Kernel sources for more information.
 It requires PV drivers to be installed in your guest OS.
 
-=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
+=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep|s3resume> [I<VCPU>]
 
 Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
 or sleep.  Optionally a specific vcpu number can be passed as an argument.
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -32,6 +32,9 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, idl.Aggregate):
+        if isinstance(ty, idl.KeyedUnion):
+            s += libxl_C_instance_of(ty.keyvar_type, ty.keyvar_name) + ";\n"
+            
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2477,24 +2477,6 @@ out:
     return 0;
 }
 
-int libxl_button_press(libxl_ctx *ctx, uint32_t domid, libxl_button button)
-{
-    int rc = -1;
-
-    switch (button) {
-    case LIBXL_BUTTON_POWER:
-        rc = xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_POWER, 0);
-        break;
-    case LIBXL_BUTTON_SLEEP:
-        rc = xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_SLEEP, 0);
-        break;
-    default:
-        break;
-    }
-
-    return rc;
-}
-
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 {
     xc_physinfo_t xcphysinfo = { 0 };
@@ -2876,44 +2858,46 @@ int libxl_sched_sedf_domain_set(libxl_ct
     return 0;
 }
 
-static int trigger_type_from_string(char *trigger_name)
+int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
+                       libxl_trigger trigger, uint32_t vcpuid)
 {
-    if (!strcmp(trigger_name, "nmi"))
-        return XEN_DOMCTL_SENDTRIGGER_NMI;
-    else if (!strcmp(trigger_name, "reset"))
-        return XEN_DOMCTL_SENDTRIGGER_RESET;
-    else if (!strcmp(trigger_name, "init"))
-        return XEN_DOMCTL_SENDTRIGGER_INIT;
-    else if (!strcmp(trigger_name, "power"))
-        return XEN_DOMCTL_SENDTRIGGER_POWER;
-    else if (!strcmp(trigger_name, "sleep"))
-        return XEN_DOMCTL_SENDTRIGGER_SLEEP;
-    else
-        return -1;
-}
-
-int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint32_t vcpuid)
-{
-    int rc = -1;
-    int trigger_type = -1;
-
-    if (!strcmp(trigger_name, "s3resume")) {
+    int rc;
+
+    switch (trigger) {
+    case LIBXL_TRIGGER_POWER:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_POWER, vcpuid);
+        break;
+    case LIBXL_TRIGGER_SLEEP:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_SLEEP, vcpuid);
+        break;
+    case LIBXL_TRIGGER_NMI:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_NMI, vcpuid);
+        break;
+    case LIBXL_TRIGGER_INIT:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_INIT, vcpuid);
+        break;
+    case LIBXL_TRIGGER_RESET:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_RESET, vcpuid);
+        break;
+    case LIBXL_TRIGGER_S3RESUME:
         xc_set_hvm_param(ctx->xch, domid, HVM_PARAM_ACPI_S_STATE, 0);
-        return 0;
+        rc = 0;
+        break;
+    default:
+        rc = EINVAL;
+        break;
     }
 
-    trigger_type = trigger_type_from_string(trigger_name);
-    if (trigger_type == -1) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
-            "Invalid trigger, valid triggers are <nmi|reset|init|power|sleep>");
-        return ERROR_INVAL;
-    }
-
-    rc = xc_domain_send_trigger(ctx->xch, domid, trigger_type, vcpuid);
     if (rc != 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
-            "Send trigger '%s' failed", trigger_name);
-        return ERROR_FAIL;
+                            "Send trigger '%s' failed",
+                            libxl_trigger_to_string(trigger));
+        rc = ERROR_FAIL;
     }
 
     return 0;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -547,8 +547,6 @@ int libxl_userdata_retrieve(libxl_ctx *c
    * On error return, *data_r and *datalen_r are undefined.
    */
 
-int libxl_button_press(libxl_ctx *ctx, uint32_t domid, libxl_button button);
-
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
 int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
@@ -573,7 +571,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
                                 libxl_sched_sedf *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
-                       char *trigger_name, uint32_t vcpuid);
+                       libxl_trigger trigger, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
 int libxl_send_debug_keys(libxl_ctx *ctx, char *keys);
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -80,9 +80,14 @@ libxl_event_type = Enumeration("event_ty
     (2, "DISK_EJECT"),
     ])
 
-libxl_button = Enumeration("button", [
+libxl_trigger = Enumeration("trigger", [
+    (0, "UNKNOWN"),
     (1, "POWER"),
     (2, "SLEEP"),
+    (3, "NMI"),
+    (4, "INIT"),
+    (5, "RESET"),
+    (6, "S3RESUME"),
     ])
 
 libxl_tsc_mode = Enumeration("tsc_mode", [
@@ -203,7 +208,6 @@ libxl_domain_build_info = Struct("domain
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
-    ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3318,26 +3318,29 @@ int main_create(int argc, char **argv)
 
 static void button_press(const char *p, const char *b)
 {
-    libxl_button button;
+    libxl_trigger trigger;
 
     find_domain(p);
 
     if (!strcmp(b, "power")) {
-        button = LIBXL_BUTTON_POWER;
+        trigger = LIBXL_TRIGGER_POWER;
     } else if (!strcmp(b, "sleep")) {
-        button = LIBXL_BUTTON_SLEEP;
+        trigger = LIBXL_TRIGGER_SLEEP;
     } else {
         fprintf(stderr, "%s is an invalid button identifier\n", b);
         exit(2);
     }
 
-    libxl_button_press(ctx, domid, button);
+    libxl_send_trigger(ctx, domid, trigger, 0);
 }
 
 int main_button_press(int argc, char **argv)
 {
     int opt;
 
+    fprintf(stderr, "WARNING: \"button-press\" is deprecated. "
+            "Please use \"trigger\"\n");
+
     if ((opt = def_getopt(argc, argv, "", "button-press", 2)) != -1)
         return opt;
 
@@ -4322,10 +4325,11 @@ int main_rename(int argc, char **argv)
 int main_trigger(int argc, char **argv)
 {
     int opt;
-    char *trigger_name = NULL;
     char *endptr = NULL;
     const char *dom = NULL;
     int vcpuid = 0;
+    const char *trigger_name = NULL;
+    libxl_trigger trigger;
 
     if ((opt = def_getopt(argc, argv, "", "trigger", 2)) != -1)
         return opt;
@@ -4335,6 +4339,10 @@ int main_trigger(int argc, char **argv)
     find_domain(dom);
 
     trigger_name = argv[optind++];
+    if (libxl_trigger_from_string(trigger_name, &trigger)) {
+        fprintf(stderr, "Invalid trigger \"%s\"\n", trigger_name);
+        return -1;
+    }
 
     if (argv[optind]) {
         vcpuid = strtol(argv[optind], &endptr, 10);
@@ -4343,7 +4351,7 @@ int main_trigger(int argc, char **argv)
         }
     }
 
-    libxl_send_trigger(ctx, domid, trigger_name, vcpuid);
+    libxl_send_trigger(ctx, domid, trigger, vcpuid);
 
     return 0;
 }
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -29,10 +29,8 @@ module Topologyinfo = struct
 	external get : unit -> t = "stub_xl_topologyinfo"
 end
 
-external button_press : domid -> button -> unit = "stub_xl_button_press"
 
-
-external send_trigger : domid -> string -> int -> unit = "stub_xl_send_trigger"
+external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
 
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -29,8 +29,6 @@ module Topologyinfo : sig
 	external get : unit -> t = "stub_xl_topologyinfo"
 end
 
-external button_press : domid -> button -> unit = "stub_xl_button_press"
-
-external send_trigger : domid -> string -> int -> unit = "stub_xl_send_trigger"
+external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c b/tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -432,21 +432,6 @@ value stub_xl_device_pci_remove(value in
 	CAMLreturn(Val_unit);
 }
 
-value stub_xl_button_press(value domid, value button)
-{
-	CAMLparam2(domid, button);
-	int ret;
-	INIT_STRUCT();
-
-	INIT_CTX();
-	ret = libxl_button_press(ctx, Int_val(domid), Int_val(button) + LIBXL_BUTTON_POWER);
-	if (ret != 0)
-		failwith_xl("button_press", &lg);
-	FREE_CTX();
-
-	CAMLreturn(Val_unit);
-}
-
 value stub_xl_physinfo_get(value unit)
 {
 	CAMLparam1(unit);
@@ -523,10 +508,10 @@ value stub_xl_send_trigger(value domid, 
 {
 	CAMLparam3(domid, trigger, vcpuid);
 	int ret;
-	char *c_trigger;
+	libxl_trigger c_trigger = LIBXL_TRIGGER_UNKNOWN;
 	INIT_STRUCT();
 
-	c_trigger = dup_String_val(&gc, trigger);
+	trigger_val(&gc, &lg, &c_trigger, trigger);
 
 	INIT_CTX();
 	ret = libxl_send_trigger(ctx, Int_val(domid), c_trigger, Int_val(vcpuid));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a5-0005YA-DS; Wed, 25 Jan 2012 17:24:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a4-0005Wt-4O
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:20 +0000
Received: from [85.158.138.51:55787] by server-1.bemta-3.messagelabs.com id
	46/80-09565-3CA302F4; Wed, 25 Jan 2012 17:24:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327512255!8802330!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3750 invoked from network); 25 Jan 2012 17:24:18 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21277754"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:16 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:16 -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
	q0PHOCMA006355;	Wed, 25 Jan 2012 09:24:15 -0800
MIME-Version: 1.0
X-Mercurial-Node: a7776e38447d4e633a45b926295f7923c046fbc9
Message-ID: <a7776e38447d4e633a45.1327512253@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:13 +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 9] libxl: remove libxl_button_press in
 favour of libxl_send_trigger
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327510508 0
# Node ID a7776e38447d4e633a45b926295f7923c046fbc9
# Parent  b9973edc7528e5233698fefd234be19dd6d6bcee
libxl: remove libxl_button_press in favour of libxl_send_trigger.

send_trigger already included all the operations covered by button_press.

Rework send_trigger to take an enum instead of a string.

I stopped short at removing the xl "button-press" command but instead have
marked it as deprecated.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -86,6 +86,8 @@ previously, most commands take I<domain-
 
 =item B<button-press> I<domain-id> I<button>
 
+I<This command is deprecated. Please use C<xl trigger> in preference>
+
 Indicate an ACPI button press to the domain. I<button> is may be 'power' or
 'sleep'. This command is only available for HVM domains.
 
@@ -448,7 +450,7 @@ It can be used to send SysRq requests to
 your Linux Kernel sources for more information.
 It requires PV drivers to be installed in your guest OS.
 
-=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
+=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep|s3resume> [I<VCPU>]
 
 Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
 or sleep.  Optionally a specific vcpu number can be passed as an argument.
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -32,6 +32,9 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, idl.Aggregate):
+        if isinstance(ty, idl.KeyedUnion):
+            s += libxl_C_instance_of(ty.keyvar_type, ty.keyvar_name) + ";\n"
+            
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2477,24 +2477,6 @@ out:
     return 0;
 }
 
-int libxl_button_press(libxl_ctx *ctx, uint32_t domid, libxl_button button)
-{
-    int rc = -1;
-
-    switch (button) {
-    case LIBXL_BUTTON_POWER:
-        rc = xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_POWER, 0);
-        break;
-    case LIBXL_BUTTON_SLEEP:
-        rc = xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_SLEEP, 0);
-        break;
-    default:
-        break;
-    }
-
-    return rc;
-}
-
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 {
     xc_physinfo_t xcphysinfo = { 0 };
@@ -2876,44 +2858,46 @@ int libxl_sched_sedf_domain_set(libxl_ct
     return 0;
 }
 
-static int trigger_type_from_string(char *trigger_name)
+int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
+                       libxl_trigger trigger, uint32_t vcpuid)
 {
-    if (!strcmp(trigger_name, "nmi"))
-        return XEN_DOMCTL_SENDTRIGGER_NMI;
-    else if (!strcmp(trigger_name, "reset"))
-        return XEN_DOMCTL_SENDTRIGGER_RESET;
-    else if (!strcmp(trigger_name, "init"))
-        return XEN_DOMCTL_SENDTRIGGER_INIT;
-    else if (!strcmp(trigger_name, "power"))
-        return XEN_DOMCTL_SENDTRIGGER_POWER;
-    else if (!strcmp(trigger_name, "sleep"))
-        return XEN_DOMCTL_SENDTRIGGER_SLEEP;
-    else
-        return -1;
-}
-
-int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint32_t vcpuid)
-{
-    int rc = -1;
-    int trigger_type = -1;
-
-    if (!strcmp(trigger_name, "s3resume")) {
+    int rc;
+
+    switch (trigger) {
+    case LIBXL_TRIGGER_POWER:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_POWER, vcpuid);
+        break;
+    case LIBXL_TRIGGER_SLEEP:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_SLEEP, vcpuid);
+        break;
+    case LIBXL_TRIGGER_NMI:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_NMI, vcpuid);
+        break;
+    case LIBXL_TRIGGER_INIT:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_INIT, vcpuid);
+        break;
+    case LIBXL_TRIGGER_RESET:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_RESET, vcpuid);
+        break;
+    case LIBXL_TRIGGER_S3RESUME:
         xc_set_hvm_param(ctx->xch, domid, HVM_PARAM_ACPI_S_STATE, 0);
-        return 0;
+        rc = 0;
+        break;
+    default:
+        rc = EINVAL;
+        break;
     }
 
-    trigger_type = trigger_type_from_string(trigger_name);
-    if (trigger_type == -1) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
-            "Invalid trigger, valid triggers are <nmi|reset|init|power|sleep>");
-        return ERROR_INVAL;
-    }
-
-    rc = xc_domain_send_trigger(ctx->xch, domid, trigger_type, vcpuid);
     if (rc != 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
-            "Send trigger '%s' failed", trigger_name);
-        return ERROR_FAIL;
+                            "Send trigger '%s' failed",
+                            libxl_trigger_to_string(trigger));
+        rc = ERROR_FAIL;
     }
 
     return 0;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -547,8 +547,6 @@ int libxl_userdata_retrieve(libxl_ctx *c
    * On error return, *data_r and *datalen_r are undefined.
    */
 
-int libxl_button_press(libxl_ctx *ctx, uint32_t domid, libxl_button button);
-
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
 int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
@@ -573,7 +571,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
                                 libxl_sched_sedf *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
-                       char *trigger_name, uint32_t vcpuid);
+                       libxl_trigger trigger, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
 int libxl_send_debug_keys(libxl_ctx *ctx, char *keys);
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -80,9 +80,14 @@ libxl_event_type = Enumeration("event_ty
     (2, "DISK_EJECT"),
     ])
 
-libxl_button = Enumeration("button", [
+libxl_trigger = Enumeration("trigger", [
+    (0, "UNKNOWN"),
     (1, "POWER"),
     (2, "SLEEP"),
+    (3, "NMI"),
+    (4, "INIT"),
+    (5, "RESET"),
+    (6, "S3RESUME"),
     ])
 
 libxl_tsc_mode = Enumeration("tsc_mode", [
@@ -203,7 +208,6 @@ libxl_domain_build_info = Struct("domain
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
-    ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3318,26 +3318,29 @@ int main_create(int argc, char **argv)
 
 static void button_press(const char *p, const char *b)
 {
-    libxl_button button;
+    libxl_trigger trigger;
 
     find_domain(p);
 
     if (!strcmp(b, "power")) {
-        button = LIBXL_BUTTON_POWER;
+        trigger = LIBXL_TRIGGER_POWER;
     } else if (!strcmp(b, "sleep")) {
-        button = LIBXL_BUTTON_SLEEP;
+        trigger = LIBXL_TRIGGER_SLEEP;
     } else {
         fprintf(stderr, "%s is an invalid button identifier\n", b);
         exit(2);
     }
 
-    libxl_button_press(ctx, domid, button);
+    libxl_send_trigger(ctx, domid, trigger, 0);
 }
 
 int main_button_press(int argc, char **argv)
 {
     int opt;
 
+    fprintf(stderr, "WARNING: \"button-press\" is deprecated. "
+            "Please use \"trigger\"\n");
+
     if ((opt = def_getopt(argc, argv, "", "button-press", 2)) != -1)
         return opt;
 
@@ -4322,10 +4325,11 @@ int main_rename(int argc, char **argv)
 int main_trigger(int argc, char **argv)
 {
     int opt;
-    char *trigger_name = NULL;
     char *endptr = NULL;
     const char *dom = NULL;
     int vcpuid = 0;
+    const char *trigger_name = NULL;
+    libxl_trigger trigger;
 
     if ((opt = def_getopt(argc, argv, "", "trigger", 2)) != -1)
         return opt;
@@ -4335,6 +4339,10 @@ int main_trigger(int argc, char **argv)
     find_domain(dom);
 
     trigger_name = argv[optind++];
+    if (libxl_trigger_from_string(trigger_name, &trigger)) {
+        fprintf(stderr, "Invalid trigger \"%s\"\n", trigger_name);
+        return -1;
+    }
 
     if (argv[optind]) {
         vcpuid = strtol(argv[optind], &endptr, 10);
@@ -4343,7 +4351,7 @@ int main_trigger(int argc, char **argv)
         }
     }
 
-    libxl_send_trigger(ctx, domid, trigger_name, vcpuid);
+    libxl_send_trigger(ctx, domid, trigger, vcpuid);
 
     return 0;
 }
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -29,10 +29,8 @@ module Topologyinfo = struct
 	external get : unit -> t = "stub_xl_topologyinfo"
 end
 
-external button_press : domid -> button -> unit = "stub_xl_button_press"
 
-
-external send_trigger : domid -> string -> int -> unit = "stub_xl_send_trigger"
+external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
 
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -29,8 +29,6 @@ module Topologyinfo : sig
 	external get : unit -> t = "stub_xl_topologyinfo"
 end
 
-external button_press : domid -> button -> unit = "stub_xl_button_press"
-
-external send_trigger : domid -> string -> int -> unit = "stub_xl_send_trigger"
+external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c b/tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -432,21 +432,6 @@ value stub_xl_device_pci_remove(value in
 	CAMLreturn(Val_unit);
 }
 
-value stub_xl_button_press(value domid, value button)
-{
-	CAMLparam2(domid, button);
-	int ret;
-	INIT_STRUCT();
-
-	INIT_CTX();
-	ret = libxl_button_press(ctx, Int_val(domid), Int_val(button) + LIBXL_BUTTON_POWER);
-	if (ret != 0)
-		failwith_xl("button_press", &lg);
-	FREE_CTX();
-
-	CAMLreturn(Val_unit);
-}
-
 value stub_xl_physinfo_get(value unit)
 {
 	CAMLparam1(unit);
@@ -523,10 +508,10 @@ value stub_xl_send_trigger(value domid, 
 {
 	CAMLparam3(domid, trigger, vcpuid);
 	int ret;
-	char *c_trigger;
+	libxl_trigger c_trigger = LIBXL_TRIGGER_UNKNOWN;
 	INIT_STRUCT();
 
-	c_trigger = dup_String_val(&gc, trigger);
+	trigger_val(&gc, &lg, &c_trigger, trigger);
 
 	INIT_CTX();
 	ret = libxl_send_trigger(ctx, Int_val(domid), c_trigger, Int_val(vcpuid));

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a8-0005aT-R7; Wed, 25 Jan 2012 17:24:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a6-0005Yd-IK
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:22 +0000
Received: from [85.158.138.51:6371] by server-4.bemta-3.messagelabs.com id
	CC/12-32238-5CA302F4; Wed, 25 Jan 2012 17:24:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19595 invoked from network); 25 Jan 2012 17:24:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076330"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:19 -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
	q0PHOCMD006355;	Wed, 25 Jan 2012 09:24:18 -0800
MIME-Version: 1.0
X-Mercurial-Node: e1753f37c9064f1e84fa32dfc37ff0f286e2df1e
Message-ID: <e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:16 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a single
 list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327512175 0
# Node ID e1753f37c9064f1e84fa32dfc37ff0f286e2df1e
# Parent  d09c5ab835ec6685822c04a140afa1620cca1138
libxl: expose cpu topology as a single list of cpu->{node,core,socket} maps.

Rather than the previous tripple list which is more complicated to work with
and harder for language bindings.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -195,6 +195,7 @@ static void libxl_string_list_rand_init(
     *p = l;
 }
 
+#if 0
 static void libxl_cpuarray_rand_init(libxl_cpuarray *p)
 {
     int i;
@@ -209,6 +210,7 @@ static void libxl_cpuarray_rand_init(lib
             p->array[i] = r;
     }
 }
+#endif
 """)
     for ty in builtins + types:
         if ty.typename not in handcoded:
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2502,57 +2502,68 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
+    libxl_cputopology *ret = NULL;
     int i;
-    int rc = 0;
-
-    rc += libxl_cpuarray_alloc(ctx, &info->coremap);
-    rc += libxl_cpuarray_alloc(ctx, &info->socketmap);
-    rc += libxl_cpuarray_alloc(ctx, &info->nodemap);
-    if (rc)
+    int max_cpus;
+
+    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus == 0)
+    {
+        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
+        return NULL;
+    }
+
+    coremap = xc_hypercall_buffer_alloc
+        (ctx->xch, coremap, sizeof(*coremap) * max_cpus);
+    socketmap = xc_hypercall_buffer_alloc
+        (ctx->xch, socketmap, sizeof(*socketmap) * max_cpus);
+    nodemap = xc_hypercall_buffer_alloc
+        (ctx->xch, nodemap, sizeof(*nodemap) * max_cpus);
+    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL)) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate hypercall arguments");
         goto fail;
-
-    coremap = xc_hypercall_buffer_alloc(ctx->xch, coremap, sizeof(*coremap) * info->coremap.entries);
-    socketmap = xc_hypercall_buffer_alloc(ctx->xch, socketmap, sizeof(*socketmap) * info->socketmap.entries);
-    nodemap = xc_hypercall_buffer_alloc(ctx->xch, nodemap, sizeof(*nodemap) * info->nodemap.entries);
-    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL))
-        goto fail;
+    }
 
     set_xen_guest_handle(tinfo.cpu_to_core, coremap);
     set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
     set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
-    tinfo.max_cpu_index = info->coremap.entries - 1;
-    if (xc_topologyinfo(ctx->xch, &tinfo) != 0)
+    tinfo.max_cpu_index = max_cpus - 1;
+    if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
+        LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
         goto fail;
-
-    for (i = 0; i <= tinfo.max_cpu_index; i++) {
-        if (i < info->coremap.entries)
-            info->coremap.array[i] = (coremap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : coremap[i];
-        if (i < info->socketmap.entries)
-            info->socketmap.array[i] = (socketmap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : socketmap[i];
-        if (i < info->nodemap.entries)
-            info->nodemap.array[i] = (nodemap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : nodemap[i];
     }
 
-    xc_hypercall_buffer_free(ctx->xch, coremap);
-    xc_hypercall_buffer_free(ctx->xch, socketmap);
-    xc_hypercall_buffer_free(ctx->xch, nodemap);
-    return 0;
+    ret = malloc(sizeof(libxl_cputopology) * max_cpus);
+    if (ret == NULL) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate return value");
+        goto fail;
+    }
+
+    for (i = 0; i <= max_cpus; i++) {
+#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \
+    LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i]
+        ret[i].core = V(coremap, i);
+        ret[i].socket = V(socketmap, i);
+        ret[i].node = V(nodemap, i);
+#undef V
+    }
 
 fail:
     xc_hypercall_buffer_free(ctx->xch, coremap);
     xc_hypercall_buffer_free(ctx->xch, socketmap);
     xc_hypercall_buffer_free(ctx->xch, nodemap);
-    libxl_topologyinfo_dispose(info);
-    return ERROR_FAIL;
+
+    if (ret)
+        *nr = max_cpus;
+    return ret;
 }
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
@@ -3336,30 +3347,30 @@ int libxl_cpupool_cpuadd(libxl_ctx *ctx,
 int libxl_cpupool_cpuadd_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus)
 {
     int rc = 0;
-    int cpu;
+    int cpu, nr;
     libxl_cpumap freemap;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         return ERROR_FAIL;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &nr);
+    if (!topology) {
         rc = ERROR_FAIL;
         goto out;
     }
 
     *cpus = 0;
-    for (cpu = 0; cpu < topology.nodemap.entries; cpu++) {
-        if (libxl_cpumap_test(&freemap, cpu) &&
-            (topology.nodemap.array[cpu] == node) &&
+    for (cpu = 0; cpu < nr; cpu++) {
+        if (libxl_cpumap_test(&freemap, cpu) && (topology[cpu].node == node) &&
             !libxl_cpupool_cpuadd(ctx, poolid, cpu)) {
                 (*cpus)++;
         }
+        libxl_cputopology_dispose(&topology[cpu]);
     }
 
-    libxl_topologyinfo_dispose(&topology);
-
+    free(topology);
 out:
     libxl_cpumap_dispose(&freemap);
     return rc;
@@ -3383,8 +3394,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
     int ret = 0;
     int n_pools;
     int p;
-    int cpu;
-    libxl_topologyinfo topology;
+    int cpu, nr_cpus;
+    libxl_cputopology *topology;
     libxl_cpupoolinfo *poolinfo;
 
     poolinfo = libxl_list_cpupool(ctx, &n_pools);
@@ -3392,7 +3403,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
         return ERROR_NOMEM;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (!topology) {
         ret = ERROR_FAIL;
         goto out;
     }
@@ -3400,8 +3412,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
     *cpus = 0;
     for (p = 0; p < n_pools; p++) {
         if (poolinfo[p].poolid == poolid) {
-            for (cpu = 0; cpu < topology.nodemap.entries; cpu++) {
-                if ((topology.nodemap.array[cpu] == node) &&
+            for (cpu = 0; cpu < nr_cpus; cpu++) {
+                if ((topology[cpu].node == node) &&
                     libxl_cpumap_test(&poolinfo[p].cpumap, cpu) &&
                     !libxl_cpupool_cpuremove(ctx, poolid, cpu)) {
                         (*cpus)++;
@@ -3410,7 +3422,9 @@ int libxl_cpupool_cpuremove_node(libxl_c
         }
     }
 
-    libxl_topologyinfo_dispose(&topology);
+    for (cpu = 0; cpu < nr_cpus; cpu++)
+        libxl_cputopology_dispose(&topology[cpu]);
+    free(topology);
 
 out:
     for (p = 0; p < n_pools; p++) {
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -548,7 +548,8 @@ int libxl_userdata_retrieve(libxl_ctx *c
    */
 
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
-int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info);
+#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY ~0
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
                                        int *nb_vcpu, int *nrcpus);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -377,10 +377,10 @@ libxl_physinfo = Struct("physinfo", [
     ("phys_cap", uint32),
     ], dispose_fn=None, dir=DIR_OUT)
 
-libxl_topologyinfo = Struct("topologyinfo", [
-    ("coremap", libxl_cpuarray),   # cpu to core map
-    ("socketmap", libxl_cpuarray), # cpu to socket map
-    ("nodemap", libxl_cpuarray),   # cpu to node map
+libxl_cputopology = Struct("cputopology", [
+    ("core", uint32),
+    ("socket", uint32),
+    ("node", uint32),
     ])
 
 libxl_sched_credit = Struct("sched_credit", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3707,10 +3707,11 @@ static void output_physinfo(void)
 
 static void output_topologyinfo(void)
 {
-    libxl_topologyinfo info;
-    int i;
-
-    if (libxl_get_topologyinfo(ctx, &info)) {
+    libxl_cputopology *info;
+    int i, nr;
+
+    info = libxl_get_cpu_topology(ctx, &nr);
+    if (info == NULL) {
         fprintf(stderr, "libxl_get_topologyinfo failed.\n");
         return;
     }
@@ -3718,16 +3719,17 @@ static void output_topologyinfo(void)
     printf("cpu_topology           :\n");
     printf("cpu:    core    socket     node\n");
 
-    for (i = 0; i < info.coremap.entries; i++) {
-        if (info.coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY)
-            printf("%3d:    %4d     %4d     %4d\n", i, info.coremap.array[i],
-                info.socketmap.array[i], info.nodemap.array[i]);
-    }
+    for (i = 0; i < nr; i++) {
+        if (info[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+            printf("%3d:    %4d     %4d     %4d\n", i,
+                   info[i].core, info[i].socket, info[i].node);
+        libxl_cputopology_dispose(&info[i]);
+    }
+
+    free(info);
 
     printf("numa_info              : none\n");
 
-    libxl_topologyinfo_dispose(&info);
-
     return;
 }
 
@@ -5160,7 +5162,7 @@ int main_cpupoolcreate(int argc, char **
     libxl_cpumap freemap;
     libxl_cpumap cpumap;
     libxl_uuid uuid;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
 
     while (1) {
         opt = getopt_long(argc, argv, "hnf:", long_options, &option_index);
@@ -5269,16 +5271,18 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
     if (!xlu_cfg_get_list(config, "nodes", &nodes, 0, 0)) {
+        int nr;
         n_cpus = 0;
         n_nodes = 0;
-        if (libxl_get_topologyinfo(ctx, &topology)) {
+        topology = libxl_get_cpu_topology(ctx, &nr);
+        if (topology == NULL) {
             fprintf(stderr, "libxl_get_topologyinfo failed\n");
             return -ERROR_FAIL;
         }
         while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
             n = atoi(buf);
-            for (i = 0; i < topology.nodemap.entries; i++) {
-                if ((topology.nodemap.array[i] == n) &&
+            for (i = 0; i < nr; i++) {
+                if ((topology[i].node == n) &&
                     libxl_cpumap_test(&freemap, i)) {
                     libxl_cpumap_set(&cpumap, i);
                     n_cpus++;
@@ -5287,7 +5291,10 @@ int main_cpupoolcreate(int argc, char **
             n_nodes++;
         }
 
-        libxl_topologyinfo_dispose(&topology);
+        for (i = 0; i < nr; i++)
+            libxl_cputopology_dispose(&topology[i]);
+
+        free(topology);
 
         if (n_cpus == 0) {
             fprintf(stderr, "no free cpu found\n");
@@ -5609,11 +5616,12 @@ int main_cpupoolnumasplit(int argc, char
     int schedid;
     int n_pools;
     int node;
+    int n_cpus;
     char name[16];
     libxl_uuid uuid;
     libxl_cpumap cpumap;
     libxl_cpupoolinfo *poolinfo;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
     libxl_dominfo info;
 
     if ((opt = def_getopt(argc, argv, "", "cpupool-numa-split", 0)) != -1)
@@ -5635,21 +5643,24 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &n_cpus);
+    if (topology == NULL) {
         fprintf(stderr, "libxl_get_topologyinfo failed\n");
         return -ERROR_FAIL;
     }
 
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
-        libxl_topologyinfo_dispose(&topology);
+        for (c=0; c<n_cpus; c++)
+            libxl_cputopology_dispose(&topology[c]);
+        free(topology);
         return -ERROR_FAIL;
     }
 
     /* Reset Pool-0 to 1st node: first add cpus, then remove cpus to avoid
        a cpupool without cpus in between */
 
-    node = topology.nodemap.array[0];
+    node = topology[0].node;
     if (libxl_cpupool_cpuadd_node(ctx, 0, node, &n)) {
         fprintf(stderr, "error on adding cpu to Pool 0\n");
         return -ERROR_FAIL;
@@ -5663,9 +5674,9 @@ int main_cpupoolnumasplit(int argc, char
     }
 
     n = 0;
-    for (c = 0; c < topology.nodemap.entries; c++) {
-        if (topology.nodemap.array[c] == node) {
-            topology.nodemap.array[c] = LIBXL_CPUARRAY_INVALID_ENTRY;
+    for (c = 0; c < n_cpus; c++) {
+        if (topology[c].node == node) {
+            topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             libxl_cpumap_set(&cpumap, n);
             n++;
         }
@@ -5690,12 +5701,12 @@ int main_cpupoolnumasplit(int argc, char
     }
     memset(cpumap.map, 0, cpumap.size);
 
-    for (c = 0; c < topology.nodemap.entries; c++) {
-        if (topology.nodemap.array[c] == LIBXL_CPUARRAY_INVALID_ENTRY) {
+    for (c = 0; c < n_cpus; c++) {
+        if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
             continue;
         }
 
-        node = topology.nodemap.array[c];
+        node = topology[c].node;
         ret = -libxl_cpupool_cpuremove_node(ctx, 0, node, &n);
         if (ret) {
             fprintf(stderr, "error on removing cpu from Pool 0\n");
@@ -5717,15 +5728,17 @@ int main_cpupoolnumasplit(int argc, char
             goto out;
         }
 
-        for (p = c; p < topology.nodemap.entries; p++) {
-            if (topology.nodemap.array[p] == node) {
-                topology.nodemap.array[p] = LIBXL_CPUARRAY_INVALID_ENTRY;
+        for (p = c; p < n_cpus; p++) {
+            if (topology[p].node == node) {
+                topology[p].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             }
         }
     }
 
 out:
-    libxl_topologyinfo_dispose(&topology);
+    for (c=0; c<n_cpus; c++)
+        libxl_cputopology_dispose(&topology[c]);
+    free(topology);
     libxl_cpumap_dispose(&cpumap);
 
     return ret;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -29,6 +29,8 @@ functions = { # ( name , [type1,type2,..
     "device_pci":     DEVICE_FUNCTIONS,
     "physinfo":       [ ("get",            ["unit", "t"]),
                       ],
+    "cputopology":    [ ("get",            ["unit", "t array"]),
+                      ],
     "sched_credit":   [ ("domain_get",     ["domid", "t"]),
                         ("domain_set",     ["domid", "t", "unit"]),
                       ],
@@ -259,7 +261,6 @@ if __name__ == '__main__':
         "domain_create_info",
         "domain_build_info",
         "vcpuinfo",
-        "topologyinfo",
         ]
 
     for t in blacklist:
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -19,17 +19,6 @@ type domid = int
 
 (* @@LIBXL_TYPES@@ *)
 
-module Topologyinfo = struct
-	type t =
-	{
-		core : int;
-		socket : int;
-		node : int;
-	}
-	external get : unit -> t array = "stub_xl_topologyinfo"
-end
-
-
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -19,16 +19,6 @@ type domid = int
 
 (* @@LIBXL_TYPES@@ *)
 
-module Topologyinfo : sig
-	type t =
-	{
-		core : int;
-		socket : int;
-		node : int;
-	}
-	external get : unit -> t array = "stub_xl_topologyinfo"
-end
-
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c b/tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -210,28 +210,6 @@ static value Val_hwcap(libxl_hwcap *c_va
 
 #include "_libxl_types.inc"
 
-static value Val_topologyinfo(libxl_topologyinfo *c_val)
-{
-	CAMLparam0();
-	CAMLlocal3(v, topology, topologyinfo);
-	int i;
-
-	topologyinfo = caml_alloc_tuple(c_val->coremap.entries);
-	for (i = 0; i < c_val->coremap.entries; i++) {
-		v = Val_none;
-		if (c_val->coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY) {
-			topology = caml_alloc_tuple(3);
-			Store_field(topology, 0, Val_int(c_val->coremap.array[i]));
-			Store_field(topology, 1, Val_int(c_val->socketmap.array[i]));
-			Store_field(topology, 2, Val_int(c_val->nodemap.array[i]));
-			v = Val_some(topology);
-		}
-		Store_field(topologyinfo, i, v);
-	}
-
-	CAMLreturn(topologyinfo);
-}
-
 value stub_xl_device_disk_add(value info, value domid)
 {
 	CAMLparam2(info, domid);
@@ -462,22 +440,34 @@ value stub_xl_physinfo_get(value unit)
 	CAMLreturn(physinfo);
 }
 
-value stub_xl_topologyinfo(value unit)
+value stub_xl_cputopology_get(value unit)
 {
 	CAMLparam1(unit);
-	CAMLlocal1(topologyinfo);
-	libxl_topologyinfo c_topologyinfo;
-	int ret;
+	CAMLlocal2(topology, v);
+	libxl_cputopology *c_topology;
+	int i, nr, ret;
 	INIT_STRUCT();
 
 	INIT_CTX();
-	ret = libxl_get_topologyinfo(ctx, &c_topologyinfo);
+
+	c_topology = libxl_get_cpu_topology(ctx, &nr);
 	if (ret != 0)
 		failwith_xl("topologyinfo", &lg);
+
+	topology = caml_alloc_tuple(nr);
+	for (i = 0; i < nr; i++) {
+		if (c_topology[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+			v = Val_some(Val_cputopology(&gc, &lg, &c_topology[i]));
+		else
+			v = Val_none;
+		Store_field(topology, i, v);
+		libxl_cputopology_dispose(&c_topology[i]);
+	}
+
+	free(c_topology);
+
 	FREE_CTX();
-
-	topologyinfo = Val_topologyinfo(&c_topologyinfo);
-	CAMLreturn(topologyinfo);
+	CAMLreturn(topology);
 }
 
 value stub_xl_sched_credit_domain_get(value domid)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a8-0005aT-R7; Wed, 25 Jan 2012 17:24:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a6-0005Yd-IK
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:22 +0000
Received: from [85.158.138.51:6371] by server-4.bemta-3.messagelabs.com id
	CC/12-32238-5CA302F4; Wed, 25 Jan 2012 17:24:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19595 invoked from network); 25 Jan 2012 17:24:20 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076330"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:19 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:19 -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
	q0PHOCMD006355;	Wed, 25 Jan 2012 09:24:18 -0800
MIME-Version: 1.0
X-Mercurial-Node: e1753f37c9064f1e84fa32dfc37ff0f286e2df1e
Message-ID: <e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:16 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a single
 list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327512175 0
# Node ID e1753f37c9064f1e84fa32dfc37ff0f286e2df1e
# Parent  d09c5ab835ec6685822c04a140afa1620cca1138
libxl: expose cpu topology as a single list of cpu->{node,core,socket} maps.

Rather than the previous tripple list which is more complicated to work with
and harder for language bindings.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -195,6 +195,7 @@ static void libxl_string_list_rand_init(
     *p = l;
 }
 
+#if 0
 static void libxl_cpuarray_rand_init(libxl_cpuarray *p)
 {
     int i;
@@ -209,6 +210,7 @@ static void libxl_cpuarray_rand_init(lib
             p->array[i] = r;
     }
 }
+#endif
 """)
     for ty in builtins + types:
         if ty.typename not in handcoded:
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2502,57 +2502,68 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
+    libxl_cputopology *ret = NULL;
     int i;
-    int rc = 0;
-
-    rc += libxl_cpuarray_alloc(ctx, &info->coremap);
-    rc += libxl_cpuarray_alloc(ctx, &info->socketmap);
-    rc += libxl_cpuarray_alloc(ctx, &info->nodemap);
-    if (rc)
+    int max_cpus;
+
+    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus == 0)
+    {
+        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
+        return NULL;
+    }
+
+    coremap = xc_hypercall_buffer_alloc
+        (ctx->xch, coremap, sizeof(*coremap) * max_cpus);
+    socketmap = xc_hypercall_buffer_alloc
+        (ctx->xch, socketmap, sizeof(*socketmap) * max_cpus);
+    nodemap = xc_hypercall_buffer_alloc
+        (ctx->xch, nodemap, sizeof(*nodemap) * max_cpus);
+    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL)) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate hypercall arguments");
         goto fail;
-
-    coremap = xc_hypercall_buffer_alloc(ctx->xch, coremap, sizeof(*coremap) * info->coremap.entries);
-    socketmap = xc_hypercall_buffer_alloc(ctx->xch, socketmap, sizeof(*socketmap) * info->socketmap.entries);
-    nodemap = xc_hypercall_buffer_alloc(ctx->xch, nodemap, sizeof(*nodemap) * info->nodemap.entries);
-    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL))
-        goto fail;
+    }
 
     set_xen_guest_handle(tinfo.cpu_to_core, coremap);
     set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
     set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
-    tinfo.max_cpu_index = info->coremap.entries - 1;
-    if (xc_topologyinfo(ctx->xch, &tinfo) != 0)
+    tinfo.max_cpu_index = max_cpus - 1;
+    if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
+        LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
         goto fail;
-
-    for (i = 0; i <= tinfo.max_cpu_index; i++) {
-        if (i < info->coremap.entries)
-            info->coremap.array[i] = (coremap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : coremap[i];
-        if (i < info->socketmap.entries)
-            info->socketmap.array[i] = (socketmap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : socketmap[i];
-        if (i < info->nodemap.entries)
-            info->nodemap.array[i] = (nodemap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : nodemap[i];
     }
 
-    xc_hypercall_buffer_free(ctx->xch, coremap);
-    xc_hypercall_buffer_free(ctx->xch, socketmap);
-    xc_hypercall_buffer_free(ctx->xch, nodemap);
-    return 0;
+    ret = malloc(sizeof(libxl_cputopology) * max_cpus);
+    if (ret == NULL) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate return value");
+        goto fail;
+    }
+
+    for (i = 0; i <= max_cpus; i++) {
+#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \
+    LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i]
+        ret[i].core = V(coremap, i);
+        ret[i].socket = V(socketmap, i);
+        ret[i].node = V(nodemap, i);
+#undef V
+    }
 
 fail:
     xc_hypercall_buffer_free(ctx->xch, coremap);
     xc_hypercall_buffer_free(ctx->xch, socketmap);
     xc_hypercall_buffer_free(ctx->xch, nodemap);
-    libxl_topologyinfo_dispose(info);
-    return ERROR_FAIL;
+
+    if (ret)
+        *nr = max_cpus;
+    return ret;
 }
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
@@ -3336,30 +3347,30 @@ int libxl_cpupool_cpuadd(libxl_ctx *ctx,
 int libxl_cpupool_cpuadd_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus)
 {
     int rc = 0;
-    int cpu;
+    int cpu, nr;
     libxl_cpumap freemap;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         return ERROR_FAIL;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &nr);
+    if (!topology) {
         rc = ERROR_FAIL;
         goto out;
     }
 
     *cpus = 0;
-    for (cpu = 0; cpu < topology.nodemap.entries; cpu++) {
-        if (libxl_cpumap_test(&freemap, cpu) &&
-            (topology.nodemap.array[cpu] == node) &&
+    for (cpu = 0; cpu < nr; cpu++) {
+        if (libxl_cpumap_test(&freemap, cpu) && (topology[cpu].node == node) &&
             !libxl_cpupool_cpuadd(ctx, poolid, cpu)) {
                 (*cpus)++;
         }
+        libxl_cputopology_dispose(&topology[cpu]);
     }
 
-    libxl_topologyinfo_dispose(&topology);
-
+    free(topology);
 out:
     libxl_cpumap_dispose(&freemap);
     return rc;
@@ -3383,8 +3394,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
     int ret = 0;
     int n_pools;
     int p;
-    int cpu;
-    libxl_topologyinfo topology;
+    int cpu, nr_cpus;
+    libxl_cputopology *topology;
     libxl_cpupoolinfo *poolinfo;
 
     poolinfo = libxl_list_cpupool(ctx, &n_pools);
@@ -3392,7 +3403,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
         return ERROR_NOMEM;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (!topology) {
         ret = ERROR_FAIL;
         goto out;
     }
@@ -3400,8 +3412,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
     *cpus = 0;
     for (p = 0; p < n_pools; p++) {
         if (poolinfo[p].poolid == poolid) {
-            for (cpu = 0; cpu < topology.nodemap.entries; cpu++) {
-                if ((topology.nodemap.array[cpu] == node) &&
+            for (cpu = 0; cpu < nr_cpus; cpu++) {
+                if ((topology[cpu].node == node) &&
                     libxl_cpumap_test(&poolinfo[p].cpumap, cpu) &&
                     !libxl_cpupool_cpuremove(ctx, poolid, cpu)) {
                         (*cpus)++;
@@ -3410,7 +3422,9 @@ int libxl_cpupool_cpuremove_node(libxl_c
         }
     }
 
-    libxl_topologyinfo_dispose(&topology);
+    for (cpu = 0; cpu < nr_cpus; cpu++)
+        libxl_cputopology_dispose(&topology[cpu]);
+    free(topology);
 
 out:
     for (p = 0; p < n_pools; p++) {
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -548,7 +548,8 @@ int libxl_userdata_retrieve(libxl_ctx *c
    */
 
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
-int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info);
+#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY ~0
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
                                        int *nb_vcpu, int *nrcpus);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -377,10 +377,10 @@ libxl_physinfo = Struct("physinfo", [
     ("phys_cap", uint32),
     ], dispose_fn=None, dir=DIR_OUT)
 
-libxl_topologyinfo = Struct("topologyinfo", [
-    ("coremap", libxl_cpuarray),   # cpu to core map
-    ("socketmap", libxl_cpuarray), # cpu to socket map
-    ("nodemap", libxl_cpuarray),   # cpu to node map
+libxl_cputopology = Struct("cputopology", [
+    ("core", uint32),
+    ("socket", uint32),
+    ("node", uint32),
     ])
 
 libxl_sched_credit = Struct("sched_credit", [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3707,10 +3707,11 @@ static void output_physinfo(void)
 
 static void output_topologyinfo(void)
 {
-    libxl_topologyinfo info;
-    int i;
-
-    if (libxl_get_topologyinfo(ctx, &info)) {
+    libxl_cputopology *info;
+    int i, nr;
+
+    info = libxl_get_cpu_topology(ctx, &nr);
+    if (info == NULL) {
         fprintf(stderr, "libxl_get_topologyinfo failed.\n");
         return;
     }
@@ -3718,16 +3719,17 @@ static void output_topologyinfo(void)
     printf("cpu_topology           :\n");
     printf("cpu:    core    socket     node\n");
 
-    for (i = 0; i < info.coremap.entries; i++) {
-        if (info.coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY)
-            printf("%3d:    %4d     %4d     %4d\n", i, info.coremap.array[i],
-                info.socketmap.array[i], info.nodemap.array[i]);
-    }
+    for (i = 0; i < nr; i++) {
+        if (info[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+            printf("%3d:    %4d     %4d     %4d\n", i,
+                   info[i].core, info[i].socket, info[i].node);
+        libxl_cputopology_dispose(&info[i]);
+    }
+
+    free(info);
 
     printf("numa_info              : none\n");
 
-    libxl_topologyinfo_dispose(&info);
-
     return;
 }
 
@@ -5160,7 +5162,7 @@ int main_cpupoolcreate(int argc, char **
     libxl_cpumap freemap;
     libxl_cpumap cpumap;
     libxl_uuid uuid;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
 
     while (1) {
         opt = getopt_long(argc, argv, "hnf:", long_options, &option_index);
@@ -5269,16 +5271,18 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
     if (!xlu_cfg_get_list(config, "nodes", &nodes, 0, 0)) {
+        int nr;
         n_cpus = 0;
         n_nodes = 0;
-        if (libxl_get_topologyinfo(ctx, &topology)) {
+        topology = libxl_get_cpu_topology(ctx, &nr);
+        if (topology == NULL) {
             fprintf(stderr, "libxl_get_topologyinfo failed\n");
             return -ERROR_FAIL;
         }
         while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
             n = atoi(buf);
-            for (i = 0; i < topology.nodemap.entries; i++) {
-                if ((topology.nodemap.array[i] == n) &&
+            for (i = 0; i < nr; i++) {
+                if ((topology[i].node == n) &&
                     libxl_cpumap_test(&freemap, i)) {
                     libxl_cpumap_set(&cpumap, i);
                     n_cpus++;
@@ -5287,7 +5291,10 @@ int main_cpupoolcreate(int argc, char **
             n_nodes++;
         }
 
-        libxl_topologyinfo_dispose(&topology);
+        for (i = 0; i < nr; i++)
+            libxl_cputopology_dispose(&topology[i]);
+
+        free(topology);
 
         if (n_cpus == 0) {
             fprintf(stderr, "no free cpu found\n");
@@ -5609,11 +5616,12 @@ int main_cpupoolnumasplit(int argc, char
     int schedid;
     int n_pools;
     int node;
+    int n_cpus;
     char name[16];
     libxl_uuid uuid;
     libxl_cpumap cpumap;
     libxl_cpupoolinfo *poolinfo;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
     libxl_dominfo info;
 
     if ((opt = def_getopt(argc, argv, "", "cpupool-numa-split", 0)) != -1)
@@ -5635,21 +5643,24 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &n_cpus);
+    if (topology == NULL) {
         fprintf(stderr, "libxl_get_topologyinfo failed\n");
         return -ERROR_FAIL;
     }
 
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
-        libxl_topologyinfo_dispose(&topology);
+        for (c=0; c<n_cpus; c++)
+            libxl_cputopology_dispose(&topology[c]);
+        free(topology);
         return -ERROR_FAIL;
     }
 
     /* Reset Pool-0 to 1st node: first add cpus, then remove cpus to avoid
        a cpupool without cpus in between */
 
-    node = topology.nodemap.array[0];
+    node = topology[0].node;
     if (libxl_cpupool_cpuadd_node(ctx, 0, node, &n)) {
         fprintf(stderr, "error on adding cpu to Pool 0\n");
         return -ERROR_FAIL;
@@ -5663,9 +5674,9 @@ int main_cpupoolnumasplit(int argc, char
     }
 
     n = 0;
-    for (c = 0; c < topology.nodemap.entries; c++) {
-        if (topology.nodemap.array[c] == node) {
-            topology.nodemap.array[c] = LIBXL_CPUARRAY_INVALID_ENTRY;
+    for (c = 0; c < n_cpus; c++) {
+        if (topology[c].node == node) {
+            topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             libxl_cpumap_set(&cpumap, n);
             n++;
         }
@@ -5690,12 +5701,12 @@ int main_cpupoolnumasplit(int argc, char
     }
     memset(cpumap.map, 0, cpumap.size);
 
-    for (c = 0; c < topology.nodemap.entries; c++) {
-        if (topology.nodemap.array[c] == LIBXL_CPUARRAY_INVALID_ENTRY) {
+    for (c = 0; c < n_cpus; c++) {
+        if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
             continue;
         }
 
-        node = topology.nodemap.array[c];
+        node = topology[c].node;
         ret = -libxl_cpupool_cpuremove_node(ctx, 0, node, &n);
         if (ret) {
             fprintf(stderr, "error on removing cpu from Pool 0\n");
@@ -5717,15 +5728,17 @@ int main_cpupoolnumasplit(int argc, char
             goto out;
         }
 
-        for (p = c; p < topology.nodemap.entries; p++) {
-            if (topology.nodemap.array[p] == node) {
-                topology.nodemap.array[p] = LIBXL_CPUARRAY_INVALID_ENTRY;
+        for (p = c; p < n_cpus; p++) {
+            if (topology[p].node == node) {
+                topology[p].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             }
         }
     }
 
 out:
-    libxl_topologyinfo_dispose(&topology);
+    for (c=0; c<n_cpus; c++)
+        libxl_cputopology_dispose(&topology[c]);
+    free(topology);
     libxl_cpumap_dispose(&cpumap);
 
     return ret;
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -29,6 +29,8 @@ functions = { # ( name , [type1,type2,..
     "device_pci":     DEVICE_FUNCTIONS,
     "physinfo":       [ ("get",            ["unit", "t"]),
                       ],
+    "cputopology":    [ ("get",            ["unit", "t array"]),
+                      ],
     "sched_credit":   [ ("domain_get",     ["domid", "t"]),
                         ("domain_set",     ["domid", "t", "unit"]),
                       ],
@@ -259,7 +261,6 @@ if __name__ == '__main__':
         "domain_create_info",
         "domain_build_info",
         "vcpuinfo",
-        "topologyinfo",
         ]
 
     for t in blacklist:
diff --git a/tools/ocaml/libs/xl/xenlight.ml.in b/tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in
+++ b/tools/ocaml/libs/xl/xenlight.ml.in
@@ -19,17 +19,6 @@ type domid = int
 
 (* @@LIBXL_TYPES@@ *)
 
-module Topologyinfo = struct
-	type t =
-	{
-		core : int;
-		socket : int;
-		node : int;
-	}
-	external get : unit -> t array = "stub_xl_topologyinfo"
-end
-
-
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff --git a/tools/ocaml/libs/xl/xenlight.mli.in b/tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in
+++ b/tools/ocaml/libs/xl/xenlight.mli.in
@@ -19,16 +19,6 @@ type domid = int
 
 (* @@LIBXL_TYPES@@ *)
 
-module Topologyinfo : sig
-	type t =
-	{
-		core : int;
-		socket : int;
-		node : int;
-	}
-	external get : unit -> t array = "stub_xl_topologyinfo"
-end
-
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c b/tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -210,28 +210,6 @@ static value Val_hwcap(libxl_hwcap *c_va
 
 #include "_libxl_types.inc"
 
-static value Val_topologyinfo(libxl_topologyinfo *c_val)
-{
-	CAMLparam0();
-	CAMLlocal3(v, topology, topologyinfo);
-	int i;
-
-	topologyinfo = caml_alloc_tuple(c_val->coremap.entries);
-	for (i = 0; i < c_val->coremap.entries; i++) {
-		v = Val_none;
-		if (c_val->coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY) {
-			topology = caml_alloc_tuple(3);
-			Store_field(topology, 0, Val_int(c_val->coremap.array[i]));
-			Store_field(topology, 1, Val_int(c_val->socketmap.array[i]));
-			Store_field(topology, 2, Val_int(c_val->nodemap.array[i]));
-			v = Val_some(topology);
-		}
-		Store_field(topologyinfo, i, v);
-	}
-
-	CAMLreturn(topologyinfo);
-}
-
 value stub_xl_device_disk_add(value info, value domid)
 {
 	CAMLparam2(info, domid);
@@ -462,22 +440,34 @@ value stub_xl_physinfo_get(value unit)
 	CAMLreturn(physinfo);
 }
 
-value stub_xl_topologyinfo(value unit)
+value stub_xl_cputopology_get(value unit)
 {
 	CAMLparam1(unit);
-	CAMLlocal1(topologyinfo);
-	libxl_topologyinfo c_topologyinfo;
-	int ret;
+	CAMLlocal2(topology, v);
+	libxl_cputopology *c_topology;
+	int i, nr, ret;
 	INIT_STRUCT();
 
 	INIT_CTX();
-	ret = libxl_get_topologyinfo(ctx, &c_topologyinfo);
+
+	c_topology = libxl_get_cpu_topology(ctx, &nr);
 	if (ret != 0)
 		failwith_xl("topologyinfo", &lg);
+
+	topology = caml_alloc_tuple(nr);
+	for (i = 0; i < nr; i++) {
+		if (c_topology[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+			v = Val_some(Val_cputopology(&gc, &lg, &c_topology[i]));
+		else
+			v = Val_none;
+		Store_field(topology, i, v);
+		libxl_cputopology_dispose(&c_topology[i]);
+	}
+
+	free(c_topology);
+
 	FREE_CTX();
-
-	topologyinfo = Val_topologyinfo(&c_topologyinfo);
-	CAMLreturn(topologyinfo);
+	CAMLreturn(topology);
 }
 
 value stub_xl_sched_credit_domain_get(value domid)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6aC-0005fB-B4; Wed, 25 Jan 2012 17:24:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a9-0005bP-UT
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:26 +0000
Received: from [85.158.138.51:6556] by server-9.bemta-3.messagelabs.com id
	FB/71-31168-9CA302F4; Wed, 25 Jan 2012 17:24:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19997 invoked from network); 25 Jan 2012 17:24:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076334"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:22 -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
	q0PHOCMG006355;	Wed, 25 Jan 2012 09:24:21 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9e3be181b2b70f521defcd55ecbd9967cd206fb2
Message-ID: <9e3be181b2b70f521def.1327512259@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:19 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 9 of 9] xl: use json output by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327512175 0
# Node ID 9e3be181b2b70f521defcd55ecbd9967cd206fb2
# Parent  f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
xl: use json output by default

Move the sxp producing code off into a separate file. It is supported
for legacy reasons and needn't be updated other than the improve
compatibility with xm.

libxl_domain_config is not currently generated by the IDL (adding the
necessary support for Array types is on my to do list) so hand code
the json generation function for now.

Since this rather directly exposes a libxl data structure it's not
clear what sort of forward compatibility guarantees we can
make. However it seems like it should be as stable as libxl's own API
(which we are looking to stabilise)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -219,7 +219,7 @@ B<OPTIONS>
 =item B<-l>, B<--long>
 
 The output for B<xl list> is not the table view shown below, but 
-instead presents the data in SXP compatible format.
+instead presents the data in as a JSON data structure.
 
 =item B<-Z>, B<--context>
 Also prints the security labels.
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -62,7 +62,7 @@ LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_
 
 CLIENTS = xl testidl
 
-XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o
+XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -239,6 +239,7 @@ typedef struct {
     libxl_action_on_shutdown on_watchdog;
     libxl_action_on_shutdown on_crash;
 } libxl_domain_config;
+char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p);
 
 /* context functions */
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -848,6 +848,158 @@ out:
     return ret;
 }
 
+yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
+                                             libxl_domain_config *p)
+{
+    yajl_gen_status s;
+    int i;
+
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"c_info",
+                        sizeof("c_info")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_create_info_gen_json(hand, &p->c_info);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"b_info",
+                        sizeof("b_info")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_build_info_gen_json(hand, &p->b_info);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"disks",
+                        sizeof("disks")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_disks; i++) {
+        s = libxl_device_disk_gen_json(hand, &p->disks[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vifs",
+                        sizeof("vifs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vifs; i++) {
+        s = libxl_device_nic_gen_json(hand, &p->vifs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"pcidevs",
+                        sizeof("pcidevs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_pcidevs; i++) {
+        s = libxl_device_pci_gen_json(hand, &p->pcidevs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vfbs",
+                        sizeof("vfbs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vfbs; i++) {
+        s = libxl_device_vfb_gen_json(hand, &p->vfbs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vkbs",
+                        sizeof("vkbs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vkbs; i++) {
+        s = libxl_device_vkb_gen_json(hand, &p->vkbs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_poweroff",
+                        sizeof("on_poweroff")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_poweroff);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_reboot",
+                        sizeof("on_reboot")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_reboot);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_watchdog",
+                        sizeof("on_watchdog")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_watchdog);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_crash",
+                        sizeof("on_crash")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_crash);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    out:
+    return s;
+}
+
+char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p)
+{
+    return libxl__object_to_json(ctx, "libxl_domain_config",
+                        (libxl__gen_json_callback)&libxl_domain_config_gen_json,
+                        (void *)p);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -19,4 +19,7 @@
 
 #include <_libxl_types_json.h>
 
+yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
+                                             libxl_domain_config *p);
+
 #endif /* LIBXL_JSON_H */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -38,6 +38,7 @@ int dryrun_only;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
+enum output_format default_output_format = OUTPUT_FORMAT_JSON;
 
 static xentoollog_level minmsglevel = XTL_PROGRESS;
 
@@ -78,6 +79,15 @@ static void parse_global_config(const ch
     if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
+    if (!xlu_cfg_get_string (config, "output_format", &buf, 0)) {
+        if (!strcmp(buf, "json"))
+            default_output_format = OUTPUT_FORMAT_JSON;
+        else if (!strcmp(buf, "sxp"))
+            default_output_format = OUTPUT_FORMAT_SXP;
+        else {
+            fprintf(stderr, "invalid default output format \"%s\"\n", buf);
+        }
+    }
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -110,6 +110,14 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 
+enum output_format {
+    OUTPUT_FORMAT_JSON,
+    OUTPUT_FORMAT_SXP,
+};
+extern enum output_format default_output_format;
+
+extern void printf_info_sexp(int domid, libxl_domain_config *d_config);
+
 #endif /* XL_H */
 
 /*
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -38,6 +38,7 @@
 
 #include "libxl.h"
 #include "libxl_utils.h"
+#include "libxl_json.h"
 #include "libxlutil.h"
 #include "xl.h"
 
@@ -288,187 +289,66 @@ static void dolog(const char *file, int 
         libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
 }
 
-static void printf_info(int domid,
+static void printf_info(enum output_format output_format,
+                        int domid,
                         libxl_domain_config *d_config)
 {
-    int i;
-    libxl_dominfo info;
-
-    libxl_domain_create_info *c_info = &d_config->c_info;
-    libxl_domain_build_info *b_info = &d_config->b_info;
-
-    printf("(domain\n\t(domid %d)\n", domid);
-    printf("\t(create_info)\n");
-    printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
-    printf("\t(ssidref %d)\n", c_info->ssidref);
-    printf("\t(name %s)\n", c_info->name);
-
-    /* retrieve the UUID from dominfo, since it is probably generated
-     * during parsing and thus does not match the real one
-     */
-    if (libxl_domain_info(ctx, &info, domid) == 0) {
-        printf("\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
-    } else {
-        printf("\t(uuid <unknown>)\n");
-    }
-
-    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
-    if (c_info->xsdata)
-        printf("\t(xsdata contains data)\n");
+    if (output_format == OUTPUT_FORMAT_SXP)
+        return printf_info_sexp(domid, d_config);
+
+    yajl_gen_config conf = { 1, "    " };
+    const char *buf;
+    unsigned int len = 0;
+    yajl_gen_status s;
+    yajl_gen hand;
+
+    hand = yajl_gen_alloc(&conf, NULL);
+    if (!hand) {
+        fprintf(stderr, "unable to allocate JSON generator\n");
+        return;
+    }
+
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"domid",
+                        sizeof("domid")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    if (domid != -1)
+        s = yajl_gen_integer(hand, domid);
     else
-        printf("\t(xsdata (null))\n");
-    if (c_info->platformdata)
-        printf("\t(platformdata contains data)\n");
-    else
-        printf("\t(platformdata (null))\n");
-
-
-    printf("\t(build_info)\n");
-    printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
-    printf("\t(max_memkb %d)\n", b_info->max_memkb);
-    printf("\t(target_memkb %d)\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
-
-    if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
-        int i;
-        printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
-        if (b_info->u.pv.bootloader_args) {
-            printf("\t(bootloader_args");
-            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
-                printf(" %s", b_info->u.pv.bootloader_args[i]);
-            printf(")\n");
-        }
-    }
-
-    printf("\t(image\n");
-    switch (c_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        printf("\t\t(hvm\n");
-        printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
-        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
-        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
-        printf("\t\t\t(timer_mode %s)\n",
-               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
-
-        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
-        printf("\t\t\t(no_incr_generationid %d)\n",
-                    b_info->u.hvm.no_incr_generationid);
-
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
-        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
-        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
-        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
-
-        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
-        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
-        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
-        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
-        printf("\t\t)\n");
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        printf("\t\t(linux %d)\n", 0);
-        printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
-        printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
-        printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
-        printf("\t\t)\n");
-        break;
-    default:
-        fprintf(stderr, "Unknown domain type %d\n", c_info->type);
-        exit(1);
-    }
-    printf("\t)\n");
-
-    for (i = 0; i < d_config->num_disks; i++) {
-        printf("\t(device\n");
-        printf("\t\t(tap\n");
-        printf("\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
-        printf("\t\t\t(phystype %d)\n", d_config->disks[i].backend);
-        printf("\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
-        printf("\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
-        printf("\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
-        printf("\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_vifs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(vif\n");
-        if (d_config->vifs[i].ifname)
-            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
-        printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
-        printf("\t\t\t(mtu %d)\n", d_config->vifs[i].mtu);
-        printf("\t\t\t(model %s)\n", d_config->vifs[i].model);
-        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
-               d_config->vifs[i].mac[0], d_config->vifs[i].mac[1],
-               d_config->vifs[i].mac[2], d_config->vifs[i].mac[3],
-               d_config->vifs[i].mac[4], d_config->vifs[i].mac[5]);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_pcidevs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(pci\n");
-        printf("\t\t\t(pci dev %04x:%02x:%02x.%01x@%02x)\n",
-               d_config->pcidevs[i].domain, d_config->pcidevs[i].bus,
-               d_config->pcidevs[i].dev, d_config->pcidevs[i].func,
-               d_config->pcidevs[i].vdevfn);
-        printf("\t\t\t(opts msitranslate %d power_mgmt %d)\n",
-               d_config->pcidevs[i].msitranslate,
-               d_config->pcidevs[i].power_mgmt);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_vfbs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(vfb\n");
-        printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
-        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
-        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-    printf(")\n");
+        s = yajl_gen_null(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"config",
+                        sizeof("config")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_config_gen_json(hand, d_config);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_get_buf(hand, (const unsigned char **)&buf, &len);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    puts(buf);
+
+out:
+    yajl_gen_free(hand);
+
+    if (s != yajl_gen_status_ok)
+        fprintf(stderr,
+                "unable to format domain config as JSON (YAJL:%d)\n", s);
+
+    if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
 }
 
 static int parse_action_on_shutdown(const char *buf, libxl_action_on_shutdown *a)
@@ -622,7 +502,7 @@ static void parse_config_data(const char
         c_info->hap = l;
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
-        fprintf(stderr, "Domain name must be specified.");
+        fprintf(stderr, "Domain name must be specified.\n");
         exit(1);
     }
 
@@ -1599,7 +1479,7 @@ static int create_domain(struct domain_c
             dom_info->no_incr_generationid;
 
     if (debug || dom_info->dryrun)
-        printf_info(-1, &d_config);
+        printf_info(default_output_format, -1, &d_config);
 
     ret = 0;
     if (dom_info->dryrun)
@@ -2367,7 +2247,7 @@ static void list_domains_details(const l
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
         parse_config_data(config_file, (char *)data, len, &d_config);
-        printf_info(info[i].domid, &d_config);
+        printf_info(default_output_format, info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_file);
diff --git a/tools/libxl/xl_sxp.c b/tools/libxl/xl_sxp.c
new file mode 100644
--- /dev/null
+++ b/tools/libxl/xl_sxp.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright (C) 2009      Citrix Ltd.
+ * Author Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * Legacy SXP output handling
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+
+#include "libxl.h"
+#include "libxl_utils.h"
+#include "xl.h"
+
+/* In general you should not add new output to this function since it
+ * is intended only for legacy use.
+ */
+void printf_info_sexp(int domid, libxl_domain_config *d_config)
+{
+    int i;
+    libxl_dominfo info;
+
+    libxl_domain_create_info *c_info = &d_config->c_info;
+    libxl_domain_build_info *b_info = &d_config->b_info;
+
+    printf("(domain\n\t(domid %d)\n", domid);
+    printf("\t(create_info)\n");
+    printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
+    printf("\t(hap %d)\n", c_info->hap);
+    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(ssidref %d)\n", c_info->ssidref);
+    printf("\t(name %s)\n", c_info->name);
+
+    /* retrieve the UUID from dominfo, since it is probably generated
+     * during parsing and thus does not match the real one
+     */
+    if (libxl_domain_info(ctx, &info, domid) == 0) {
+        printf("\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
+    } else {
+        printf("\t(uuid <unknown>)\n");
+    }
+
+    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
+    if (c_info->xsdata)
+        printf("\t(xsdata contains data)\n");
+    else
+        printf("\t(xsdata (null))\n");
+    if (c_info->platformdata)
+        printf("\t(platformdata contains data)\n");
+    else
+        printf("\t(platformdata (null))\n");
+
+
+    printf("\t(build_info)\n");
+    printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
+    printf("\t(max_memkb %d)\n", b_info->max_memkb);
+    printf("\t(target_memkb %d)\n", b_info->target_memkb);
+    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
+
+    if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
+        int i;
+        printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
+        if (b_info->u.pv.bootloader_args) {
+            printf("\t(bootloader_args");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
+    }
+
+    printf("\t(image\n");
+    switch (c_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        printf("\t\t(hvm\n");
+        printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
+        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
+        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
+        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
+        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
+        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
+        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
+        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
+        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
+        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(timer_mode %s)\n",
+               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
+        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
+
+        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
+        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
+        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
+        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
+        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
+        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
+        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
+        printf("\t\t\t(spicedisable_ticketing %d)\n",
+                    b_info->u.hvm.spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+
+        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
+        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
+        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
+        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
+        printf("\t\t)\n");
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        printf("\t\t(linux %d)\n", 0);
+        printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
+        printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
+        printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
+        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t)\n");
+        break;
+    default:
+        fprintf(stderr, "Unknown domain type %d\n", c_info->type);
+        exit(1);
+    }
+    printf("\t)\n");
+
+    for (i = 0; i < d_config->num_disks; i++) {
+        printf("\t(device\n");
+        printf("\t\t(tap\n");
+        printf("\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
+        printf("\t\t\t(phystype %d)\n", d_config->disks[i].backend);
+        printf("\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
+        printf("\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
+        printf("\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
+        printf("\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_vifs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(vif\n");
+        if (d_config->vifs[i].ifname)
+            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
+        printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
+        printf("\t\t\t(mtu %d)\n", d_config->vifs[i].mtu);
+        printf("\t\t\t(model %s)\n", d_config->vifs[i].model);
+        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
+               d_config->vifs[i].mac[0], d_config->vifs[i].mac[1],
+               d_config->vifs[i].mac[2], d_config->vifs[i].mac[3],
+               d_config->vifs[i].mac[4], d_config->vifs[i].mac[5]);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_pcidevs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(pci\n");
+        printf("\t\t\t(pci dev %04x:%02x:%02x.%01x@%02x)\n",
+               d_config->pcidevs[i].domain, d_config->pcidevs[i].bus,
+               d_config->pcidevs[i].dev, d_config->pcidevs[i].func,
+               d_config->pcidevs[i].vdevfn);
+        printf("\t\t\t(opts msitranslate %d power_mgmt %d)\n",
+               d_config->pcidevs[i].msitranslate,
+               d_config->pcidevs[i].power_mgmt);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_vfbs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(vfb\n");
+        printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
+        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
+        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
+        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
+        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
+        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+    printf(")\n");
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6aC-0005fB-B4; Wed, 25 Jan 2012 17:24:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a9-0005bP-UT
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:26 +0000
Received: from [85.158.138.51:6556] by server-9.bemta-3.messagelabs.com id
	FB/71-31168-9CA302F4; Wed, 25 Jan 2012 17:24:25 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19997 invoked from network); 25 Jan 2012 17:24:23 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076334"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:22 -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
	q0PHOCMG006355;	Wed, 25 Jan 2012 09:24:21 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9e3be181b2b70f521defcd55ecbd9967cd206fb2
Message-ID: <9e3be181b2b70f521def.1327512259@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:19 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 9 of 9] xl: use json output by default
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327512175 0
# Node ID 9e3be181b2b70f521defcd55ecbd9967cd206fb2
# Parent  f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
xl: use json output by default

Move the sxp producing code off into a separate file. It is supported
for legacy reasons and needn't be updated other than the improve
compatibility with xm.

libxl_domain_config is not currently generated by the IDL (adding the
necessary support for Array types is on my to do list) so hand code
the json generation function for now.

Since this rather directly exposes a libxl data structure it's not
clear what sort of forward compatibility guarantees we can
make. However it seems like it should be as stable as libxl's own API
(which we are looking to stabilise)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -219,7 +219,7 @@ B<OPTIONS>
 =item B<-l>, B<--long>
 
 The output for B<xl list> is not the table view shown below, but 
-instead presents the data in SXP compatible format.
+instead presents the data in as a JSON data structure.
 
 =item B<-Z>, B<--context>
 Also prints the security labels.
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -62,7 +62,7 @@ LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_
 
 CLIENTS = xl testidl
 
-XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o
+XL_OBJS = xl.o xl_cmdimpl.o xl_cmdtable.o xl_sxp.o
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxenlight)
 
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -239,6 +239,7 @@ typedef struct {
     libxl_action_on_shutdown on_watchdog;
     libxl_action_on_shutdown on_crash;
 } libxl_domain_config;
+char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p);
 
 /* context functions */
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -848,6 +848,158 @@ out:
     return ret;
 }
 
+yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
+                                             libxl_domain_config *p)
+{
+    yajl_gen_status s;
+    int i;
+
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"c_info",
+                        sizeof("c_info")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_create_info_gen_json(hand, &p->c_info);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"b_info",
+                        sizeof("b_info")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_build_info_gen_json(hand, &p->b_info);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"disks",
+                        sizeof("disks")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_disks; i++) {
+        s = libxl_device_disk_gen_json(hand, &p->disks[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vifs",
+                        sizeof("vifs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vifs; i++) {
+        s = libxl_device_nic_gen_json(hand, &p->vifs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"pcidevs",
+                        sizeof("pcidevs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_pcidevs; i++) {
+        s = libxl_device_pci_gen_json(hand, &p->pcidevs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vfbs",
+                        sizeof("vfbs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vfbs; i++) {
+        s = libxl_device_vfb_gen_json(hand, &p->vfbs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"vkbs",
+                        sizeof("vkbs")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = yajl_gen_array_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    for (i = 0; i < p->num_vkbs; i++) {
+        s = libxl_device_vkb_gen_json(hand, &p->vkbs[i]);
+        if (s != yajl_gen_status_ok)
+            goto out;
+    }
+    s = yajl_gen_array_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_poweroff",
+                        sizeof("on_poweroff")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_poweroff);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_reboot",
+                        sizeof("on_reboot")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_reboot);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_watchdog",
+                        sizeof("on_watchdog")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_watchdog);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"on_crash",
+                        sizeof("on_crash")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_action_on_shutdown_gen_json(hand, &p->on_crash);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    out:
+    return s;
+}
+
+char *libxl_domain_config_to_json(libxl_ctx *ctx, libxl_domain_config *p)
+{
+    return libxl__object_to_json(ctx, "libxl_domain_config",
+                        (libxl__gen_json_callback)&libxl_domain_config_gen_json,
+                        (void *)p);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -19,4 +19,7 @@
 
 #include <_libxl_types_json.h>
 
+yajl_gen_status libxl_domain_config_gen_json(yajl_gen hand,
+                                             libxl_domain_config *p);
+
 #endif /* LIBXL_JSON_H */
diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -38,6 +38,7 @@ int dryrun_only;
 int autoballoon = 1;
 char *lockfile;
 char *default_vifscript = NULL;
+enum output_format default_output_format = OUTPUT_FORMAT_JSON;
 
 static xentoollog_level minmsglevel = XTL_PROGRESS;
 
@@ -78,6 +79,15 @@ static void parse_global_config(const ch
     if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
         default_vifscript = strdup(buf);
 
+    if (!xlu_cfg_get_string (config, "output_format", &buf, 0)) {
+        if (!strcmp(buf, "json"))
+            default_output_format = OUTPUT_FORMAT_JSON;
+        else if (!strcmp(buf, "sxp"))
+            default_output_format = OUTPUT_FORMAT_SXP;
+        else {
+            fprintf(stderr, "invalid default output format \"%s\"\n", buf);
+        }
+    }
     xlu_cfg_destroy(config);
 }
 
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -110,6 +110,14 @@ extern int dryrun_only;
 extern char *lockfile;
 extern char *default_vifscript;
 
+enum output_format {
+    OUTPUT_FORMAT_JSON,
+    OUTPUT_FORMAT_SXP,
+};
+extern enum output_format default_output_format;
+
+extern void printf_info_sexp(int domid, libxl_domain_config *d_config);
+
 #endif /* XL_H */
 
 /*
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -38,6 +38,7 @@
 
 #include "libxl.h"
 #include "libxl_utils.h"
+#include "libxl_json.h"
 #include "libxlutil.h"
 #include "xl.h"
 
@@ -288,187 +289,66 @@ static void dolog(const char *file, int 
         libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
 }
 
-static void printf_info(int domid,
+static void printf_info(enum output_format output_format,
+                        int domid,
                         libxl_domain_config *d_config)
 {
-    int i;
-    libxl_dominfo info;
-
-    libxl_domain_create_info *c_info = &d_config->c_info;
-    libxl_domain_build_info *b_info = &d_config->b_info;
-
-    printf("(domain\n\t(domid %d)\n", domid);
-    printf("\t(create_info)\n");
-    printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
-    printf("\t(hap %d)\n", c_info->hap);
-    printf("\t(oos %d)\n", c_info->oos);
-    printf("\t(ssidref %d)\n", c_info->ssidref);
-    printf("\t(name %s)\n", c_info->name);
-
-    /* retrieve the UUID from dominfo, since it is probably generated
-     * during parsing and thus does not match the real one
-     */
-    if (libxl_domain_info(ctx, &info, domid) == 0) {
-        printf("\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
-    } else {
-        printf("\t(uuid <unknown>)\n");
-    }
-
-    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
-    if (c_info->xsdata)
-        printf("\t(xsdata contains data)\n");
+    if (output_format == OUTPUT_FORMAT_SXP)
+        return printf_info_sexp(domid, d_config);
+
+    yajl_gen_config conf = { 1, "    " };
+    const char *buf;
+    unsigned int len = 0;
+    yajl_gen_status s;
+    yajl_gen hand;
+
+    hand = yajl_gen_alloc(&conf, NULL);
+    if (!hand) {
+        fprintf(stderr, "unable to allocate JSON generator\n");
+        return;
+    }
+
+    s = yajl_gen_map_open(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"domid",
+                        sizeof("domid")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    if (domid != -1)
+        s = yajl_gen_integer(hand, domid);
     else
-        printf("\t(xsdata (null))\n");
-    if (c_info->platformdata)
-        printf("\t(platformdata contains data)\n");
-    else
-        printf("\t(platformdata (null))\n");
-
-
-    printf("\t(build_info)\n");
-    printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
-    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
-    printf("\t(max_memkb %d)\n", b_info->max_memkb);
-    printf("\t(target_memkb %d)\n", b_info->target_memkb);
-    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
-
-    if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
-        int i;
-        printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
-        if (b_info->u.pv.bootloader_args) {
-            printf("\t(bootloader_args");
-            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
-                printf(" %s", b_info->u.pv.bootloader_args[i]);
-            printf(")\n");
-        }
-    }
-
-    printf("\t(image\n");
-    switch (c_info->type) {
-    case LIBXL_DOMAIN_TYPE_HVM:
-        printf("\t\t(hvm\n");
-        printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
-        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
-        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
-        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
-        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
-        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
-        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
-        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
-        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
-        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
-        printf("\t\t\t(timer_mode %s)\n",
-               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
-
-        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
-        printf("\t\t\t(no_incr_generationid %d)\n",
-                    b_info->u.hvm.no_incr_generationid);
-
-        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
-        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
-        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
-        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
-        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
-        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
-        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
-        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
-        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
-        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
-        printf("\t\t\t(spicedisable_ticketing %d)\n",
-                    b_info->u.hvm.spice.disable_ticketing);
-        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
-
-        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
-        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
-        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
-        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
-        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
-        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
-        printf("\t\t)\n");
-        break;
-    case LIBXL_DOMAIN_TYPE_PV:
-        printf("\t\t(linux %d)\n", 0);
-        printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
-        printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
-        printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
-        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
-        printf("\t\t)\n");
-        break;
-    default:
-        fprintf(stderr, "Unknown domain type %d\n", c_info->type);
-        exit(1);
-    }
-    printf("\t)\n");
-
-    for (i = 0; i < d_config->num_disks; i++) {
-        printf("\t(device\n");
-        printf("\t\t(tap\n");
-        printf("\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
-        printf("\t\t\t(phystype %d)\n", d_config->disks[i].backend);
-        printf("\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
-        printf("\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
-        printf("\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
-        printf("\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_vifs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(vif\n");
-        if (d_config->vifs[i].ifname)
-            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
-        printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
-        printf("\t\t\t(mtu %d)\n", d_config->vifs[i].mtu);
-        printf("\t\t\t(model %s)\n", d_config->vifs[i].model);
-        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
-               d_config->vifs[i].mac[0], d_config->vifs[i].mac[1],
-               d_config->vifs[i].mac[2], d_config->vifs[i].mac[3],
-               d_config->vifs[i].mac[4], d_config->vifs[i].mac[5]);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_pcidevs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(pci\n");
-        printf("\t\t\t(pci dev %04x:%02x:%02x.%01x@%02x)\n",
-               d_config->pcidevs[i].domain, d_config->pcidevs[i].bus,
-               d_config->pcidevs[i].dev, d_config->pcidevs[i].func,
-               d_config->pcidevs[i].vdevfn);
-        printf("\t\t\t(opts msitranslate %d power_mgmt %d)\n",
-               d_config->pcidevs[i].msitranslate,
-               d_config->pcidevs[i].power_mgmt);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-
-    for (i = 0; i < d_config->num_vfbs; i++) {
-        printf("\t(device\n");
-        printf("\t\t(vfb\n");
-        printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
-        printf("\t\t\t(frontend_domid %d)\n", domid);
-        printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
-        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
-        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
-        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
-        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
-        printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
-        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
-        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
-        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
-        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
-        printf("\t\t)\n");
-        printf("\t)\n");
-    }
-    printf(")\n");
+        s = yajl_gen_null(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_string(hand, (const unsigned char *)"config",
+                        sizeof("config")-1);
+    if (s != yajl_gen_status_ok)
+        goto out;
+    s = libxl_domain_config_gen_json(hand, d_config);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_map_close(hand);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    s = yajl_gen_get_buf(hand, (const unsigned char **)&buf, &len);
+    if (s != yajl_gen_status_ok)
+        goto out;
+
+    puts(buf);
+
+out:
+    yajl_gen_free(hand);
+
+    if (s != yajl_gen_status_ok)
+        fprintf(stderr,
+                "unable to format domain config as JSON (YAJL:%d)\n", s);
+
+    if (ferror(stdout) || fflush(stdout)) { perror("stdout"); exit(-1); }
 }
 
 static int parse_action_on_shutdown(const char *buf, libxl_action_on_shutdown *a)
@@ -622,7 +502,7 @@ static void parse_config_data(const char
         c_info->hap = l;
 
     if (xlu_cfg_replace_string (config, "name", &c_info->name, 0)) {
-        fprintf(stderr, "Domain name must be specified.");
+        fprintf(stderr, "Domain name must be specified.\n");
         exit(1);
     }
 
@@ -1599,7 +1479,7 @@ static int create_domain(struct domain_c
             dom_info->no_incr_generationid;
 
     if (debug || dom_info->dryrun)
-        printf_info(-1, &d_config);
+        printf_info(default_output_format, -1, &d_config);
 
     ret = 0;
     if (dom_info->dryrun)
@@ -2367,7 +2247,7 @@ static void list_domains_details(const l
         CHK_ERRNO(asprintf(&config_file, "<domid %d data>", info[i].domid));
         memset(&d_config, 0x00, sizeof(d_config));
         parse_config_data(config_file, (char *)data, len, &d_config);
-        printf_info(info[i].domid, &d_config);
+        printf_info(default_output_format, info[i].domid, &d_config);
         libxl_domain_config_dispose(&d_config);
         free(data);
         free(config_file);
diff --git a/tools/libxl/xl_sxp.c b/tools/libxl/xl_sxp.c
new file mode 100644
--- /dev/null
+++ b/tools/libxl/xl_sxp.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright (C) 2009      Citrix Ltd.
+ * Author Stefano Stabellini <stefano.stabellini@eu.citrix.com>
+ * Author Vincent Hanquez <vincent.hanquez@eu.citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+/*
+ * Legacy SXP output handling
+ */
+
+#include "libxl_osdeps.h"
+
+#include <stdlib.h>
+
+#include "libxl.h"
+#include "libxl_utils.h"
+#include "xl.h"
+
+/* In general you should not add new output to this function since it
+ * is intended only for legacy use.
+ */
+void printf_info_sexp(int domid, libxl_domain_config *d_config)
+{
+    int i;
+    libxl_dominfo info;
+
+    libxl_domain_create_info *c_info = &d_config->c_info;
+    libxl_domain_build_info *b_info = &d_config->b_info;
+
+    printf("(domain\n\t(domid %d)\n", domid);
+    printf("\t(create_info)\n");
+    printf("\t(hvm %d)\n", c_info->type == LIBXL_DOMAIN_TYPE_HVM);
+    printf("\t(hap %d)\n", c_info->hap);
+    printf("\t(oos %d)\n", c_info->oos);
+    printf("\t(ssidref %d)\n", c_info->ssidref);
+    printf("\t(name %s)\n", c_info->name);
+
+    /* retrieve the UUID from dominfo, since it is probably generated
+     * during parsing and thus does not match the real one
+     */
+    if (libxl_domain_info(ctx, &info, domid) == 0) {
+        printf("\t(uuid " LIBXL_UUID_FMT ")\n", LIBXL_UUID_BYTES(info.uuid));
+    } else {
+        printf("\t(uuid <unknown>)\n");
+    }
+
+    printf("\t(cpupool %s)\n", libxl_cpupoolid_to_name(ctx, c_info->poolid));
+    if (c_info->xsdata)
+        printf("\t(xsdata contains data)\n");
+    else
+        printf("\t(xsdata (null))\n");
+    if (c_info->platformdata)
+        printf("\t(platformdata contains data)\n");
+    else
+        printf("\t(platformdata (null))\n");
+
+
+    printf("\t(build_info)\n");
+    printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
+    printf("\t(tsc_mode %s)\n", libxl_tsc_mode_to_string(b_info->tsc_mode));
+    printf("\t(max_memkb %d)\n", b_info->max_memkb);
+    printf("\t(target_memkb %d)\n", b_info->target_memkb);
+    printf("\t(nomigrate %d)\n", b_info->disable_migrate);
+
+    if (c_info->type == LIBXL_DOMAIN_TYPE_PV && b_info->u.pv.bootloader) {
+        int i;
+        printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
+        if (b_info->u.pv.bootloader_args) {
+            printf("\t(bootloader_args");
+            for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+                printf(" %s", b_info->u.pv.bootloader_args[i]);
+            printf(")\n");
+        }
+    }
+
+    printf("\t(image\n");
+    switch (c_info->type) {
+    case LIBXL_DOMAIN_TYPE_HVM:
+        printf("\t\t(hvm\n");
+        printf("\t\t\t(firmware %s)\n", b_info->u.hvm.firmware);
+        printf("\t\t\t(video_memkb %d)\n", b_info->video_memkb);
+        printf("\t\t\t(shadow_memkb %d)\n", b_info->shadow_memkb);
+        printf("\t\t\t(pae %d)\n", b_info->u.hvm.pae);
+        printf("\t\t\t(apic %d)\n", b_info->u.hvm.apic);
+        printf("\t\t\t(acpi %d)\n", b_info->u.hvm.acpi);
+        printf("\t\t\t(nx %d)\n", b_info->u.hvm.nx);
+        printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
+        printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
+        printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
+        printf("\t\t\t(timer_mode %s)\n",
+               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
+        printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
+        printf("\t\t\t(no_incr_generationid %d)\n",
+                    b_info->u.hvm.no_incr_generationid);
+
+        printf("\t\t\t(stdvga %d)\n", b_info->u.hvm.stdvga);
+        printf("\t\t\t(vnc %d)\n", b_info->u.hvm.vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", b_info->u.hvm.vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", b_info->u.hvm.vnc.display);
+        printf("\t\t\t(vncunused %d)\n", b_info->u.hvm.vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", b_info->u.hvm.keymap);
+        printf("\t\t\t(sdl %d)\n", b_info->u.hvm.sdl.enable);
+        printf("\t\t\t(opengl %d)\n", b_info->u.hvm.sdl.opengl);
+        printf("\t\t\t(nographic %d)\n", b_info->u.hvm.nographic);
+        printf("\t\t\t(spice %d)\n", b_info->u.hvm.spice.enable);
+        printf("\t\t\t(spiceport %d)\n", b_info->u.hvm.spice.port);
+        printf("\t\t\t(spicetls_port %d)\n", b_info->u.hvm.spice.tls_port);
+        printf("\t\t\t(spicehost %s)\n", b_info->u.hvm.spice.host);
+        printf("\t\t\t(spicedisable_ticketing %d)\n",
+                    b_info->u.hvm.spice.disable_ticketing);
+        printf("\t\t\t(spiceagent_mouse %d)\n", b_info->u.hvm.spice.agent_mouse);
+
+        printf("\t\t\t(device_model %s)\n", b_info->device_model ? : "default");
+        printf("\t\t\t(gfx_passthru %d)\n", b_info->u.hvm.gfx_passthru);
+        printf("\t\t\t(serial %s)\n", b_info->u.hvm.serial);
+        printf("\t\t\t(boot %s)\n", b_info->u.hvm.boot);
+        printf("\t\t\t(usb %d)\n", b_info->u.hvm.usb);
+        printf("\t\t\t(usbdevice %s)\n", b_info->u.hvm.usbdevice);
+        printf("\t\t)\n");
+        break;
+    case LIBXL_DOMAIN_TYPE_PV:
+        printf("\t\t(linux %d)\n", 0);
+        printf("\t\t\t(kernel %s)\n", b_info->u.pv.kernel.path);
+        printf("\t\t\t(cmdline %s)\n", b_info->u.pv.cmdline);
+        printf("\t\t\t(ramdisk %s)\n", b_info->u.pv.ramdisk.path);
+        printf("\t\t\t(e820_host %d)\n", b_info->u.pv.e820_host);
+        printf("\t\t)\n");
+        break;
+    default:
+        fprintf(stderr, "Unknown domain type %d\n", c_info->type);
+        exit(1);
+    }
+    printf("\t)\n");
+
+    for (i = 0; i < d_config->num_disks; i++) {
+        printf("\t(device\n");
+        printf("\t\t(tap\n");
+        printf("\t\t\t(backend_domid %d)\n", d_config->disks[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(physpath %s)\n", d_config->disks[i].pdev_path);
+        printf("\t\t\t(phystype %d)\n", d_config->disks[i].backend);
+        printf("\t\t\t(virtpath %s)\n", d_config->disks[i].vdev);
+        printf("\t\t\t(unpluggable %d)\n", d_config->disks[i].removable);
+        printf("\t\t\t(readwrite %d)\n", d_config->disks[i].readwrite);
+        printf("\t\t\t(is_cdrom %d)\n", d_config->disks[i].is_cdrom);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_vifs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(vif\n");
+        if (d_config->vifs[i].ifname)
+            printf("\t\t\t(vifname %s)\n", d_config->vifs[i].ifname);
+        printf("\t\t\t(backend_domid %d)\n", d_config->vifs[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(devid %d)\n", d_config->vifs[i].devid);
+        printf("\t\t\t(mtu %d)\n", d_config->vifs[i].mtu);
+        printf("\t\t\t(model %s)\n", d_config->vifs[i].model);
+        printf("\t\t\t(mac %02x%02x%02x%02x%02x%02x)\n",
+               d_config->vifs[i].mac[0], d_config->vifs[i].mac[1],
+               d_config->vifs[i].mac[2], d_config->vifs[i].mac[3],
+               d_config->vifs[i].mac[4], d_config->vifs[i].mac[5]);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_pcidevs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(pci\n");
+        printf("\t\t\t(pci dev %04x:%02x:%02x.%01x@%02x)\n",
+               d_config->pcidevs[i].domain, d_config->pcidevs[i].bus,
+               d_config->pcidevs[i].dev, d_config->pcidevs[i].func,
+               d_config->pcidevs[i].vdevfn);
+        printf("\t\t\t(opts msitranslate %d power_mgmt %d)\n",
+               d_config->pcidevs[i].msitranslate,
+               d_config->pcidevs[i].power_mgmt);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+
+    for (i = 0; i < d_config->num_vfbs; i++) {
+        printf("\t(device\n");
+        printf("\t\t(vfb\n");
+        printf("\t\t\t(backend_domid %d)\n", d_config->vfbs[i].backend_domid);
+        printf("\t\t\t(frontend_domid %d)\n", domid);
+        printf("\t\t\t(devid %d)\n", d_config->vfbs[i].devid);
+        printf("\t\t\t(vnc %d)\n", d_config->vfbs[i].vnc.enable);
+        printf("\t\t\t(vnclisten %s)\n", d_config->vfbs[i].vnc.listen);
+        printf("\t\t\t(vncdisplay %d)\n", d_config->vfbs[i].vnc.display);
+        printf("\t\t\t(vncunused %d)\n", d_config->vfbs[i].vnc.findunused);
+        printf("\t\t\t(keymap %s)\n", d_config->vfbs[i].keymap);
+        printf("\t\t\t(sdl %d)\n", d_config->vfbs[i].sdl.enable);
+        printf("\t\t\t(opengl %d)\n", d_config->vfbs[i].sdl.opengl);
+        printf("\t\t\t(display %s)\n", d_config->vfbs[i].sdl.display);
+        printf("\t\t\t(xauthority %s)\n", d_config->vfbs[i].sdl.xauthority);
+        printf("\t\t)\n");
+        printf("\t)\n");
+    }
+    printf(")\n");
+}
+
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a4-0005Xr-WA; Wed, 25 Jan 2012 17:24:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a3-0005Wt-BF
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:19 +0000
Received: from [85.158.138.51:6258] by server-1.bemta-3.messagelabs.com id
	1D/70-09565-2CA302F4; Wed, 25 Jan 2012 17:24:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327512255!8802330!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3706 invoked from network); 25 Jan 2012 17:24:17 -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;
	25 Jan 2012 17:24:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21277753"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:14 -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
	q0PHOCM8006355;	Wed, 25 Jan 2012 09:24:13 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9a366717e0c0a0e0261796669e9e96c0ba514923
Message-ID: <9a366717e0c0a0e02617.1327512251@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:11 +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 9] libxl: Rename libxl IDL infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327510508 0
# Node ID 9a366717e0c0a0e0261796669e9e96c0ba514923
# Parent  9b126ae26d95ff9c54beb7ff0908558d423ba098
libxl: Rename libxl IDL infrastructure.

Originally libxltypes.py provided the infrastructure and libxl.idl provided the
specific types.

In 23887:a543e10211f7 libxl.idl became libxl_types.idl (to allow for
libxl_types_internal.idl) which means we now have libxl_types.FOO and
libxltypes.FOO providing different things and annoying people in tab
completion.

Rename the infrastructure as idl.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -107,7 +107,7 @@ libxl_internal_json.h: _libxl_types_inte
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
 $(LIBXL_OBJS): libxl_internal.h
 
-_libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py
+_libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py idl.py
 	$(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*_json.h __libxl_type$*.c
 	$(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h)
 	$(call move-if-changed,__libxl_type$*_json.h,_libxl_type$*_json.h)
diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -4,7 +4,7 @@ import sys
 import re
 import random
 
-import libxltypes
+import idl
 
 def randomize_char(c):
     if random.random() < 0.5:
@@ -25,9 +25,9 @@ handcoded = ["libxl_cpumap", "libxl_key_
 
 def gen_rand_init(ty, v, indent = "    ", parent = None):
     s = ""
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty))
-    elif isinstance(ty, libxltypes.KeyedUnion):
+    elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
         s += "switch (%s) {\n" % (parent + ty.keyvar_name)
@@ -37,7 +37,7 @@ def gen_rand_init(ty, v, indent = "    "
             s += gen_rand_init(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
-    elif isinstance(ty, libxltypes.Struct) \
+    elif isinstance(ty, idl.Struct) \
      and (parent is None or ty.json_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
@@ -45,10 +45,10 @@ def gen_rand_init(ty, v, indent = "    "
     elif hasattr(ty, "rand_init") and ty.rand_init is not None:
         s += "%s(%s);\n" % (ty.rand_init,
                             ty.pass_arg(v, isref=parent is None,
-                                        passby=libxltypes.PASS_BY_REFERENCE))
+                                        passby=idl.PASS_BY_REFERENCE))
     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, libxltypes.Number):
+    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
         s += "%s = rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
@@ -74,8 +74,7 @@ if __name__ == '__main__':
 
     random.seed()
 
-    idl = sys.argv[1]
-    (builtins,types) = libxltypes.parse(idl)
+    (builtins,types) = idl.parse(sys.argv[1])
 
     impl = sys.argv[2]
     f = open(impl, "w")
@@ -215,10 +214,10 @@ static void libxl_cpuarray_rand_init(lib
         if ty.typename not in handcoded:
             f.write("static void %s_rand_init(%s);\n" % \
                     (ty.typename,
-                     ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE)))
+                     ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
             f.write("static void %s_rand_init(%s)\n" % \
                     (ty.typename,
-                     ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE)))
+                     ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
             f.write("{\n")
             f.write(gen_rand_init(ty, "p"))
             f.write("}\n")
@@ -252,7 +251,7 @@ int main(int argc, char **argv)
     for ty in [t for t in types if t.json_fn is not None]:
         arg = ty.typename + "_val"
         f.write("    %s_rand_init(%s);\n" % (ty.typename, \
-            ty.pass_arg(arg, isref=False, passby=libxltypes.PASS_BY_REFERENCE)))
+            ty.pass_arg(arg, isref=False, passby=idl.PASS_BY_REFERENCE)))
         f.write("    s = %s_to_json(ctx, %s);\n" % \
                 (ty.typename, ty.pass_arg(arg, isref=False)))
         f.write("    printf(\"%%s: %%s\\n\", \"%s\", s);\n" % ty.typename)
@@ -265,7 +264,7 @@ int main(int argc, char **argv)
     f.write("    printf(\"Testing Enumerations\\n\");\n")
     f.write("    printf(\"--------------------\\n\");\n")
     f.write("    printf(\"\\n\");\n")
-    for ty in [t for t in types if isinstance(t,libxltypes.Enumeration)]:
+    for ty in [t for t in types if isinstance(t,idl.Enumeration)]:
         f.write("    printf(\"%s -- to string:\\n\");\n" % (ty.typename))
         for v in ty.values:
             f.write("    printf(\"\\t%s = %%d = \\\"%%s\\\"\\n\", " \
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -3,10 +3,10 @@
 import sys
 import re
 
-import libxltypes
+import idl
 
 def libxl_C_instance_of(ty, instancename):
-    if isinstance(ty, libxltypes.Aggregate) and ty.typename is None:
+    if isinstance(ty, idl.Aggregate) and ty.typename is None:
         if instancename is None:
             return libxl_C_type_define(ty)
         else:
@@ -16,7 +16,7 @@ def libxl_C_instance_of(ty, instancename
 
 def libxl_C_type_define(ty, indent = ""):
     s = ""
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         if ty.typename is None:
             s += "enum {\n"
         else:
@@ -31,7 +31,7 @@ def libxl_C_type_define(ty, indent = "")
         else:
             s += "} %s" % ty.typename
 
-    elif isinstance(ty, libxltypes.Aggregate):
+    elif isinstance(ty, idl.Aggregate):
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
@@ -53,7 +53,7 @@ def libxl_C_type_define(ty, indent = "")
 
 def libxl_C_type_dispose(ty, v, indent = "    ", parent = None):
     s = ""
-    if isinstance(ty, libxltypes.KeyedUnion):
+    if isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
         s += "switch (%s) {\n" % (parent + ty.keyvar_name)
@@ -63,7 +63,7 @@ def libxl_C_type_dispose(ty, v, indent =
             s += libxl_C_type_dispose(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
-    elif isinstance(ty, libxltypes.Struct) and (parent is None or ty.dispose_fn is None):
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.dispose_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += libxl_C_type_dispose(f.type, fexpr, "", nparent)
@@ -79,11 +79,11 @@ def libxl_C_type_gen_json(ty, v, indent 
     s = ""
     if parent is None:
         s += "yajl_gen_status s;\n"
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         s += "s = libxl__yajl_gen_enum(hand, %s_to_string(%s));\n" % (ty.typename, ty.pass_arg(v, parent is None))
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
-    elif isinstance(ty, libxltypes.KeyedUnion):
+    elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
         s += "switch (%s) {\n" % (parent + ty.keyvar_name)
@@ -93,7 +93,7 @@ def libxl_C_type_gen_json(ty, v, indent 
             s += libxl_C_type_gen_json(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
-    elif isinstance(ty, libxltypes.Struct) and (parent is None or ty.json_fn is None):
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.json_fn is None):
         s += "s = yajl_gen_map_open(hand);\n"
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
@@ -123,7 +123,7 @@ def libxl_C_type_gen_json(ty, v, indent 
 def libxl_C_type_to_json(ty, v, indent = "    "):
     s = ""
     gen = "(libxl__gen_json_callback)&%s_gen_json" % ty.typename
-    s += "return libxl__object_to_json(ctx, \"%s\", %s, (void *)%s);\n" % (ty.typename, gen, ty.pass_arg(v, passby=libxltypes.PASS_BY_REFERENCE))
+    s += "return libxl__object_to_json(ctx, \"%s\", %s, (void *)%s);\n" % (ty.typename, gen, ty.pass_arg(v, passby=idl.PASS_BY_REFERENCE))
 
     if s != "":
         s = indent + s
@@ -171,9 +171,9 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: gentypes.py <idl> <header> <header-json> <implementation>"
         sys.exit(1)
 
-    (_, idl, header, header_json, impl) = sys.argv
+    (_, idlname, header, header_json, impl) = sys.argv
 
-    (builtins,types) = libxltypes.parse(idl)
+    (builtins,types) = idl.parse(idlname)
 
     print "outputting libxl type definitions to %s" % header
 
@@ -198,9 +198,9 @@ if __name__ == '__main__':
             f.write("void %s(%s);\n" % (ty.dispose_fn, ty.make_arg("p")))
         if ty.json_fn is not None:
             f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p")))
-        if isinstance(ty, libxltypes.Enumeration):
+        if isinstance(ty, idl.Enumeration):
             f.write("const char *%s_to_string(%s);\n" % (ty.typename, ty.make_arg("p")))
-            f.write("int %s_from_string(const char *s, %s);\n" % (ty.typename, ty.make_arg("e", passby=libxltypes.PASS_BY_REFERENCE)))
+            f.write("int %s_from_string(const char *s, %s);\n" % (ty.typename, ty.make_arg("e", passby=idl.PASS_BY_REFERENCE)))
             f.write("extern libxl_enum_string_table %s_string_table[];\n" % (ty.typename))
         f.write("\n")
 
@@ -225,7 +225,7 @@ if __name__ == '__main__':
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
     for ty in [ty for ty in types+builtins if ty.json_fn is not None]:
-        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE)))
+        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
     f.write("""#endif /* %s */\n""" % header_json_define)
@@ -262,7 +262,7 @@ if __name__ == '__main__':
         f.write("}\n")
         f.write("\n")
 
-    for ty in [t for t in types if isinstance(t,libxltypes.Enumeration)]:
+    for ty in [t for t in types if isinstance(t,idl.Enumeration)]:
         f.write("const char *%s_to_string(%s e)\n" % (ty.typename, ty.typename))
         f.write("{\n")
         f.write(libxl_C_enum_to_string(ty, "e"))
@@ -278,7 +278,7 @@ if __name__ == '__main__':
         f.write("\n")
 
     for ty in [t for t in types if t.json_fn is not None]:
-        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE)))
+        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
         f.write("{\n")
         f.write(libxl_C_type_gen_json(ty, "p"))
         f.write("}\n")
diff --git a/tools/libxl/libxltypes.py b/tools/libxl/idl.py
rename from tools/libxl/libxltypes.py
rename to tools/libxl/idl.py
diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
--- a/tools/libxl/idl.txt
+++ b/tools/libxl/idl.txt
@@ -1,10 +1,10 @@
-libxltypes IDL
---------------
+libxl IDL
+---------
 
 Each type in the libxl interface is represented by an object of type
-libxltypes.Type (or a subclass thereof). Every local variable defined
-by the .idl file must be an instance of libxltypes.Type (e.g. you may
-not define Python functions or any other construct other than defining
+idl.Type (or a subclass thereof). Every local variable defined by
+the .idl file must be an instance of idl.Type (e.g. you may not
+define Python functions or any other construct other than defining
 variables)
 
 The name of the type must be passed as the first argument to the
@@ -16,9 +16,9 @@ The Type.typename contains the C name of
 namespace element while Type.rawname is always set to the 'base' name
 of the type.
 
-The libxltypes.Type base class has several other properties which
-apply to all types. The properties are set by passing a named
-parameter to the constructor.
+The idl.Type base class has several other properties which apply
+to all types. The properties are set by passing a named parameter to
+the constructor.
 
 Type.namespace: (default: "libxl_")
 
@@ -28,12 +28,12 @@ Type.namespace: (default: "libxl_")
  If the typename is not None then the namespace is prepended to the
  type.
  
-Type.passby: (default: libxltypes.PASS_BY_VALUE)
+Type.passby: (default: idl.PASS_BY_VALUE)
 
  Defines the manner in which a type should be passed to C
  functions. Valid values for this fields are:
-   libxltypes.PASS_BY_VALUE
-   libxltypes.PASS_BY_REFERENCE
+   idl.PASS_BY_VALUE
+   idl.PASS_BY_REFERENCE
 
 Type.dispose_fn: (default: typename + "_dispose" or None if type == None)
 
@@ -106,7 +106,7 @@ libxltype.Aggregate
 
  Each field has the following properties:
 
-  Field.type	The type of the member (a libxltypes.Type).
+  Field.type	The type of the member (a idl.Type).
   Field.name    The name of the member (can be None for anonymous
 		fields).
   Field.const	Boolean, true if the member is const.
diff --git a/tools/ocaml/libs/xl/Makefile b/tools/ocaml/libs/xl/Makefile
--- a/tools/ocaml/libs/xl/Makefile
+++ b/tools/ocaml/libs/xl/Makefile
@@ -46,7 +46,7 @@ xenlight.mli: xenlight.mli.in _libxl_typ
 	$(Q)mv xenlight.mli.tmp xenlight.mli
 
 _libxl_types.ml.in _libxl_types.mli.in _libxl_types.inc: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
-                $(XEN_ROOT)/tools/libxl/libxltypes.py
+                $(XEN_ROOT)/tools/libxl/idl.py
 	PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \
 		$(XEN_ROOT)/tools/libxl/libxl_types.idl \
 		_libxl_types.mli.in _libxl_types.ml.in _libxl_types.inc
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -2,7 +2,7 @@
 
 import sys,os
 
-import libxltypes
+import idl
 
 # typename -> ( ocaml_type, c_from_ocaml, ocaml_from_c )
 builtins = {
@@ -39,7 +39,7 @@ def stub_fn_name(ty, name):
 def ocaml_type_of(ty):
     if ty.rawname == "domid":
         return "domid"
-    elif isinstance(ty,libxltypes.UInt):
+    elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
             width = None
@@ -52,14 +52,14 @@ def ocaml_type_of(ty):
         else:
             return "int"
 
-    elif isinstance(ty,libxltypes.Builtin):
+    elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
         typename,_,_ = builtins[ty.typename]
         if not typename:
             raise NotImplementedError("No typename for Builtin %s (%s)" % (ty.typename, type(ty)))
         return typename
-    elif isinstance(ty,libxltypes.Aggregate):
+    elif isinstance(ty,idl.Aggregate):
         return ty.rawname.capitalize() + ".t"
     else:
         return ty.rawname
@@ -73,11 +73,11 @@ def gen_ocaml_ml(ty, interface, indent="
         s = ("""(* %s interface *)\n""" % ty.typename)
     else:
         s = ("""(* %s implementation *)\n""" % ty.typename)
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         s = "type %s = \n" % ty.rawname
         for v in ty.values:
             s += "\t | %s\n" % v.rawname
-    elif isinstance(ty, libxltypes.Aggregate):
+    elif isinstance(ty, idl.Aggregate):
         s = ""
         if ty.typename is None:
             raise NotImplementedError("%s has no typename" % type(ty))
@@ -113,7 +113,7 @@ def gen_ocaml_ml(ty, interface, indent="
 
 def c_val(ty, c, o, indent="", parent = None):
     s = indent
-    if isinstance(ty,libxltypes.UInt):
+    if isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
             width = None
@@ -125,14 +125,14 @@ def c_val(ty, c, o, indent="", parent = 
             s += "%s = Int%d_val(%s);" % (c, width, o)
         else:
             s += "%s = Int_val(%s);" % (c, o)
-    elif isinstance(ty,libxltypes.Builtin):
+    elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
         _,fn,_ = builtins[ty.typename]
         if not fn:
             raise NotImplementedError("No c_val fn for Builtin %s (%s)" % (ty.typename, type(ty)))
         s += "%s;" % (fn % { "o": o, "c": c })
-    elif isinstance(ty,libxltypes.Enumeration) and (parent is None):
+    elif isinstance(ty,idl.Enumeration) and (parent is None):
         n = 0
         s += "switch(Int_val(%s)) {\n" % o
         for e in ty.values:
@@ -140,21 +140,21 @@ def c_val(ty, c, o, indent="", parent = 
             n += 1
         s += "    default: failwith_xl(\"cannot convert value to %s\", lg); break;\n" % ty.typename
         s += "}"
-    elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
+    elif isinstance(ty, idl.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
             (nparent,fexpr) = ty.member(c, f, parent is None)
             s += "%s\n" % c_val(f.type, fexpr, "Field(%s, %d)" % (o,n), parent=nparent)
             n = n + 1
     else:
-        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, ty.pass_arg(c, parent is None, passby=libxltypes.PASS_BY_REFERENCE), o)
+        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, ty.pass_arg(c, parent is None, passby=idl.PASS_BY_REFERENCE), o)
     
     return s.replace("\n", "\n%s" % indent)
 
 def gen_c_val(ty, indent=""):
     s = "/* Convert caml value to %s */\n" % ty.rawname
     
-    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s, value v)\n" % (ty.rawname, ty.make_arg("c_val", passby=libxltypes.PASS_BY_REFERENCE))
+    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s, value v)\n" % (ty.rawname, ty.make_arg("c_val", passby=idl.PASS_BY_REFERENCE))
     s += "{\n"
     s += "\tCAMLparam1(v);\n"
     s += "\n"
@@ -168,7 +168,7 @@ def gen_c_val(ty, indent=""):
 
 def ocaml_Val(ty, o, c, indent="", parent = None):
     s = indent
-    if isinstance(ty,libxltypes.UInt):
+    if isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
             width = None
@@ -180,14 +180,14 @@ def ocaml_Val(ty, o, c, indent="", paren
             s += "%s = caml_copy_int%d(%s);" % (o, width, c)
         else:
             s += "%s = Val_int(%s);" % (o, c)
-    elif isinstance(ty,libxltypes.Builtin):
+    elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
         _,_,fn = builtins[ty.typename]
         if not fn:
             raise NotImplementedError("No ocaml Val fn for Builtin %s (%s)" % (ty.typename, type(ty)))
         s += "%s = %s;" % (o, fn % { "c": c })
-    elif isinstance(ty,libxltypes.Enumeration) and (parent is None):
+    elif isinstance(ty,idl.Enumeration) and (parent is None):
         n = 0
         s += "switch(%s) {\n" % c
         for e in ty.values:
@@ -195,7 +195,7 @@ def ocaml_Val(ty, o, c, indent="", paren
             n += 1
         s += "    default: failwith_xl(\"cannot convert value from %s\", lg); break;\n" % ty.typename
         s += "}"
-    elif isinstance(ty,libxltypes.Aggregate) and (parent is None):
+    elif isinstance(ty,idl.Aggregate) and (parent is None):
         s += "{\n"
         s += "\tvalue %s_field;\n" % ty.rawname
         s += "\n"
@@ -251,8 +251,7 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: genwrap.py <idl> <mli> <ml> <c-inc>"
         sys.exit(1)
 
-    idl = sys.argv[1]
-    (_,types) = libxltypes.parse(idl)
+    (_,types) = idl.parse(sys.argv[1])
 
     # Do not generate these yet.
     blacklist = [
diff --git a/tools/python/Makefile b/tools/python/Makefile
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -11,7 +11,7 @@ genpath-target = $(call buildmakevars2fi
 
 .PHONY: build
 build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
-		$(XEN_ROOT)/tools/libxl/libxltypes.py
+		$(XEN_ROOT)/tools/libxl/idl.py
 	PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \
 		$(XEN_ROOT)/tools/libxl/libxl_types.idl \
 		xen/lowlevel/xl/_pyxl_types.h \
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
--- a/tools/python/genwrap.py
+++ b/tools/python/genwrap.py
@@ -2,23 +2,23 @@
 
 import sys,os
 
-import libxltypes
+import idl
 
 (TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
 
 def py_type(ty):
-    if ty == libxltypes.bool:
+    if ty == idl.bool:
         return TYPE_BOOL
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         return TYPE_UINT
-    if isinstance(ty, libxltypes.Number):
+    if isinstance(ty, idl.Number):
         if ty.signed:
             return TYPE_INT
         else:
             return TYPE_UINT
-    if isinstance(ty, libxltypes.Aggregate):
+    if isinstance(ty, idl.Aggregate):
         return TYPE_AGGREGATE
-    if ty == libxltypes.string:
+    if ty == idl.string:
         return TYPE_STRING
     return None
 
@@ -38,7 +38,7 @@ def fsanitize(name):
 
 def py_decls(ty):
     l = []
-    if isinstance(ty, libxltypes.Aggregate):
+    if isinstance(ty, idl.Aggregate):
         l.append('_hidden Py_%s *Py%s_New(void);\n'%(ty.rawname, ty.rawname))
         l.append('_hidden int Py%s_Check(PyObject *self);\n'%ty.rawname)
         for f in ty.fields:
@@ -211,10 +211,10 @@ def py_initfuncs(types):
     l.append('void genwrap__init(PyObject *m)')
     l.append('{')
     for ty in types:
-        if isinstance(ty, libxltypes.Enumeration):
+        if isinstance(ty, idl.Enumeration):
             for v in ty.values:
                 l.append('    PyModule_AddIntConstant(m, "%s", %s);' % (v.rawname, v.name))
-        elif isinstance(ty, libxltypes.Aggregate):
+        elif isinstance(ty, idl.Aggregate):
             l.append('    if (PyType_Ready(&Py%s_Type) >= 0) {'%ty.rawname)
             l.append('        Py_INCREF(&Py%s_Type);'%ty.rawname)
             l.append('        PyModule_AddObject(m, "%s", (PyObject *)&Py%s_Type);'%(ty.rawname, ty.rawname))
@@ -227,7 +227,7 @@ def py_initfuncs(types):
 
 def tree_frob(types):
     ret = types[:]
-    for ty in [ty for ty in ret if isinstance(ty, libxltypes.Aggregate)]:
+    for ty in [ty for ty in ret if isinstance(ty, idl.Aggregate)]:
         ty.fields = filter(lambda f:f.name is not None and f.type.typename is not None, ty.fields)
     return ret
 
@@ -236,8 +236,7 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: genwrap.py <idl> <decls> <defns>"
         sys.exit(1)
 
-    idl = sys.argv[1]
-    (_,types) = libxltypes.parse(idl)
+    (_,types) = idl.parse(sys.argv[1])
 
     types = tree_frob(types)
 
@@ -278,7 +277,7 @@ _hidden PyObject *genwrap__ll_get(long l
 _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
 
 """ % " ".join(sys.argv))
-    for ty in [ty for ty in types if isinstance(ty, libxltypes.Aggregate)]:
+    for ty in [ty for ty in types if isinstance(ty, idl.Aggregate)]:
         f.write('/* Internal API for %s wrapper */\n'%ty.typename)
         f.write(py_wrapstruct(ty))
         f.write(py_decls(ty))
@@ -307,7 +306,7 @@ _hidden int genwrap__ll_set(PyObject *v,
     for ty in types:
         if ty.private:
             continue
-        if isinstance(ty, libxltypes.Aggregate):
+        if isinstance(ty, idl.Aggregate):
             f.write('/* Attribute get/set functions for %s */\n'%ty.typename)
             for a in ty.fields:
                 if a.type.private:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a4-0005Xr-WA; Wed, 25 Jan 2012 17:24:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a3-0005Wt-BF
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:19 +0000
Received: from [85.158.138.51:6258] by server-1.bemta-3.messagelabs.com id
	1D/70-09565-2CA302F4; Wed, 25 Jan 2012 17:24:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327512255!8802330!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3706 invoked from network); 25 Jan 2012 17:24:17 -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;
	25 Jan 2012 17:24:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21277753"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:15 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:14 -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
	q0PHOCM8006355;	Wed, 25 Jan 2012 09:24:13 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9a366717e0c0a0e0261796669e9e96c0ba514923
Message-ID: <9a366717e0c0a0e02617.1327512251@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:11 +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 9] libxl: Rename libxl IDL infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327510508 0
# Node ID 9a366717e0c0a0e0261796669e9e96c0ba514923
# Parent  9b126ae26d95ff9c54beb7ff0908558d423ba098
libxl: Rename libxl IDL infrastructure.

Originally libxltypes.py provided the infrastructure and libxl.idl provided the
specific types.

In 23887:a543e10211f7 libxl.idl became libxl_types.idl (to allow for
libxl_types_internal.idl) which means we now have libxl_types.FOO and
libxltypes.FOO providing different things and annoying people in tab
completion.

Rename the infrastructure as idl.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -107,7 +107,7 @@ libxl_internal_json.h: _libxl_types_inte
 $(LIBXL_OBJS) $(LIBXLU_OBJS) $(XL_OBJS): libxl.h
 $(LIBXL_OBJS): libxl_internal.h
 
-_libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py libxltypes.py
+_libxl_type%.h _libxl_type%_json.h _libxl_type%.c: libxl_type%.idl gentypes.py idl.py
 	$(PYTHON) gentypes.py libxl_type$*.idl __libxl_type$*.h __libxl_type$*_json.h __libxl_type$*.c
 	$(call move-if-changed,__libxl_type$*.h,_libxl_type$*.h)
 	$(call move-if-changed,__libxl_type$*_json.h,_libxl_type$*_json.h)
diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -4,7 +4,7 @@ import sys
 import re
 import random
 
-import libxltypes
+import idl
 
 def randomize_char(c):
     if random.random() < 0.5:
@@ -25,9 +25,9 @@ handcoded = ["libxl_cpumap", "libxl_key_
 
 def gen_rand_init(ty, v, indent = "    ", parent = None):
     s = ""
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         s += "%s = %s;\n" % (ty.pass_arg(v, parent is None), randomize_enum(ty))
-    elif isinstance(ty, libxltypes.KeyedUnion):
+    elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
         s += "switch (%s) {\n" % (parent + ty.keyvar_name)
@@ -37,7 +37,7 @@ def gen_rand_init(ty, v, indent = "    "
             s += gen_rand_init(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
-    elif isinstance(ty, libxltypes.Struct) \
+    elif isinstance(ty, idl.Struct) \
      and (parent is None or ty.json_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
@@ -45,10 +45,10 @@ def gen_rand_init(ty, v, indent = "    "
     elif hasattr(ty, "rand_init") and ty.rand_init is not None:
         s += "%s(%s);\n" % (ty.rand_init,
                             ty.pass_arg(v, isref=parent is None,
-                                        passby=libxltypes.PASS_BY_REFERENCE))
+                                        passby=idl.PASS_BY_REFERENCE))
     elif ty.typename in ["libxl_uuid", "libxl_mac", "libxl_hwcap"]:
         s += "rand_bytes((uint8_t *)%s, sizeof(*%s));\n" % (v,v)
-    elif ty.typename in ["libxl_domid"] or isinstance(ty, libxltypes.Number):
+    elif ty.typename in ["libxl_domid"] or isinstance(ty, idl.Number):
         s += "%s = rand() %% (sizeof(%s)*8);\n" % \
              (ty.pass_arg(v, parent is None),
               ty.pass_arg(v, parent is None))
@@ -74,8 +74,7 @@ if __name__ == '__main__':
 
     random.seed()
 
-    idl = sys.argv[1]
-    (builtins,types) = libxltypes.parse(idl)
+    (builtins,types) = idl.parse(sys.argv[1])
 
     impl = sys.argv[2]
     f = open(impl, "w")
@@ -215,10 +214,10 @@ static void libxl_cpuarray_rand_init(lib
         if ty.typename not in handcoded:
             f.write("static void %s_rand_init(%s);\n" % \
                     (ty.typename,
-                     ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE)))
+                     ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
             f.write("static void %s_rand_init(%s)\n" % \
                     (ty.typename,
-                     ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE)))
+                     ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
             f.write("{\n")
             f.write(gen_rand_init(ty, "p"))
             f.write("}\n")
@@ -252,7 +251,7 @@ int main(int argc, char **argv)
     for ty in [t for t in types if t.json_fn is not None]:
         arg = ty.typename + "_val"
         f.write("    %s_rand_init(%s);\n" % (ty.typename, \
-            ty.pass_arg(arg, isref=False, passby=libxltypes.PASS_BY_REFERENCE)))
+            ty.pass_arg(arg, isref=False, passby=idl.PASS_BY_REFERENCE)))
         f.write("    s = %s_to_json(ctx, %s);\n" % \
                 (ty.typename, ty.pass_arg(arg, isref=False)))
         f.write("    printf(\"%%s: %%s\\n\", \"%s\", s);\n" % ty.typename)
@@ -265,7 +264,7 @@ int main(int argc, char **argv)
     f.write("    printf(\"Testing Enumerations\\n\");\n")
     f.write("    printf(\"--------------------\\n\");\n")
     f.write("    printf(\"\\n\");\n")
-    for ty in [t for t in types if isinstance(t,libxltypes.Enumeration)]:
+    for ty in [t for t in types if isinstance(t,idl.Enumeration)]:
         f.write("    printf(\"%s -- to string:\\n\");\n" % (ty.typename))
         for v in ty.values:
             f.write("    printf(\"\\t%s = %%d = \\\"%%s\\\"\\n\", " \
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py
+++ b/tools/libxl/gentypes.py
@@ -3,10 +3,10 @@
 import sys
 import re
 
-import libxltypes
+import idl
 
 def libxl_C_instance_of(ty, instancename):
-    if isinstance(ty, libxltypes.Aggregate) and ty.typename is None:
+    if isinstance(ty, idl.Aggregate) and ty.typename is None:
         if instancename is None:
             return libxl_C_type_define(ty)
         else:
@@ -16,7 +16,7 @@ def libxl_C_instance_of(ty, instancename
 
 def libxl_C_type_define(ty, indent = ""):
     s = ""
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         if ty.typename is None:
             s += "enum {\n"
         else:
@@ -31,7 +31,7 @@ def libxl_C_type_define(ty, indent = "")
         else:
             s += "} %s" % ty.typename
 
-    elif isinstance(ty, libxltypes.Aggregate):
+    elif isinstance(ty, idl.Aggregate):
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
@@ -53,7 +53,7 @@ def libxl_C_type_define(ty, indent = "")
 
 def libxl_C_type_dispose(ty, v, indent = "    ", parent = None):
     s = ""
-    if isinstance(ty, libxltypes.KeyedUnion):
+    if isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
         s += "switch (%s) {\n" % (parent + ty.keyvar_name)
@@ -63,7 +63,7 @@ def libxl_C_type_dispose(ty, v, indent =
             s += libxl_C_type_dispose(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
-    elif isinstance(ty, libxltypes.Struct) and (parent is None or ty.dispose_fn is None):
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.dispose_fn is None):
         for f in [f for f in ty.fields if not f.const]:
             (nparent,fexpr) = ty.member(v, f, parent is None)
             s += libxl_C_type_dispose(f.type, fexpr, "", nparent)
@@ -79,11 +79,11 @@ def libxl_C_type_gen_json(ty, v, indent 
     s = ""
     if parent is None:
         s += "yajl_gen_status s;\n"
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         s += "s = libxl__yajl_gen_enum(hand, %s_to_string(%s));\n" % (ty.typename, ty.pass_arg(v, parent is None))
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
-    elif isinstance(ty, libxltypes.KeyedUnion):
+    elif isinstance(ty, idl.KeyedUnion):
         if parent is None:
             raise Exception("KeyedUnion type must have a parent")
         s += "switch (%s) {\n" % (parent + ty.keyvar_name)
@@ -93,7 +93,7 @@ def libxl_C_type_gen_json(ty, v, indent 
             s += libxl_C_type_gen_json(f.type, fexpr, indent + "    ", nparent)
             s += "    break;\n"
         s += "}\n"
-    elif isinstance(ty, libxltypes.Struct) and (parent is None or ty.json_fn is None):
+    elif isinstance(ty, idl.Struct) and (parent is None or ty.json_fn is None):
         s += "s = yajl_gen_map_open(hand);\n"
         s += "if (s != yajl_gen_status_ok)\n"
         s += "    goto out;\n"
@@ -123,7 +123,7 @@ def libxl_C_type_gen_json(ty, v, indent 
 def libxl_C_type_to_json(ty, v, indent = "    "):
     s = ""
     gen = "(libxl__gen_json_callback)&%s_gen_json" % ty.typename
-    s += "return libxl__object_to_json(ctx, \"%s\", %s, (void *)%s);\n" % (ty.typename, gen, ty.pass_arg(v, passby=libxltypes.PASS_BY_REFERENCE))
+    s += "return libxl__object_to_json(ctx, \"%s\", %s, (void *)%s);\n" % (ty.typename, gen, ty.pass_arg(v, passby=idl.PASS_BY_REFERENCE))
 
     if s != "":
         s = indent + s
@@ -171,9 +171,9 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: gentypes.py <idl> <header> <header-json> <implementation>"
         sys.exit(1)
 
-    (_, idl, header, header_json, impl) = sys.argv
+    (_, idlname, header, header_json, impl) = sys.argv
 
-    (builtins,types) = libxltypes.parse(idl)
+    (builtins,types) = idl.parse(idlname)
 
     print "outputting libxl type definitions to %s" % header
 
@@ -198,9 +198,9 @@ if __name__ == '__main__':
             f.write("void %s(%s);\n" % (ty.dispose_fn, ty.make_arg("p")))
         if ty.json_fn is not None:
             f.write("char *%s_to_json(libxl_ctx *ctx, %s);\n" % (ty.typename, ty.make_arg("p")))
-        if isinstance(ty, libxltypes.Enumeration):
+        if isinstance(ty, idl.Enumeration):
             f.write("const char *%s_to_string(%s);\n" % (ty.typename, ty.make_arg("p")))
-            f.write("int %s_from_string(const char *s, %s);\n" % (ty.typename, ty.make_arg("e", passby=libxltypes.PASS_BY_REFERENCE)))
+            f.write("int %s_from_string(const char *s, %s);\n" % (ty.typename, ty.make_arg("e", passby=idl.PASS_BY_REFERENCE)))
             f.write("extern libxl_enum_string_table %s_string_table[];\n" % (ty.typename))
         f.write("\n")
 
@@ -225,7 +225,7 @@ if __name__ == '__main__':
 """ % (header_json_define, header_json_define, " ".join(sys.argv)))
 
     for ty in [ty for ty in types+builtins if ty.json_fn is not None]:
-        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE)))
+        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s);\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
 
     f.write("\n")
     f.write("""#endif /* %s */\n""" % header_json_define)
@@ -262,7 +262,7 @@ if __name__ == '__main__':
         f.write("}\n")
         f.write("\n")
 
-    for ty in [t for t in types if isinstance(t,libxltypes.Enumeration)]:
+    for ty in [t for t in types if isinstance(t,idl.Enumeration)]:
         f.write("const char *%s_to_string(%s e)\n" % (ty.typename, ty.typename))
         f.write("{\n")
         f.write(libxl_C_enum_to_string(ty, "e"))
@@ -278,7 +278,7 @@ if __name__ == '__main__':
         f.write("\n")
 
     for ty in [t for t in types if t.json_fn is not None]:
-        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=libxltypes.PASS_BY_REFERENCE)))
+        f.write("yajl_gen_status %s_gen_json(yajl_gen hand, %s)\n" % (ty.typename, ty.make_arg("p", passby=idl.PASS_BY_REFERENCE)))
         f.write("{\n")
         f.write(libxl_C_type_gen_json(ty, "p"))
         f.write("}\n")
diff --git a/tools/libxl/libxltypes.py b/tools/libxl/idl.py
rename from tools/libxl/libxltypes.py
rename to tools/libxl/idl.py
diff --git a/tools/libxl/idl.txt b/tools/libxl/idl.txt
--- a/tools/libxl/idl.txt
+++ b/tools/libxl/idl.txt
@@ -1,10 +1,10 @@
-libxltypes IDL
---------------
+libxl IDL
+---------
 
 Each type in the libxl interface is represented by an object of type
-libxltypes.Type (or a subclass thereof). Every local variable defined
-by the .idl file must be an instance of libxltypes.Type (e.g. you may
-not define Python functions or any other construct other than defining
+idl.Type (or a subclass thereof). Every local variable defined by
+the .idl file must be an instance of idl.Type (e.g. you may not
+define Python functions or any other construct other than defining
 variables)
 
 The name of the type must be passed as the first argument to the
@@ -16,9 +16,9 @@ The Type.typename contains the C name of
 namespace element while Type.rawname is always set to the 'base' name
 of the type.
 
-The libxltypes.Type base class has several other properties which
-apply to all types. The properties are set by passing a named
-parameter to the constructor.
+The idl.Type base class has several other properties which apply
+to all types. The properties are set by passing a named parameter to
+the constructor.
 
 Type.namespace: (default: "libxl_")
 
@@ -28,12 +28,12 @@ Type.namespace: (default: "libxl_")
  If the typename is not None then the namespace is prepended to the
  type.
  
-Type.passby: (default: libxltypes.PASS_BY_VALUE)
+Type.passby: (default: idl.PASS_BY_VALUE)
 
  Defines the manner in which a type should be passed to C
  functions. Valid values for this fields are:
-   libxltypes.PASS_BY_VALUE
-   libxltypes.PASS_BY_REFERENCE
+   idl.PASS_BY_VALUE
+   idl.PASS_BY_REFERENCE
 
 Type.dispose_fn: (default: typename + "_dispose" or None if type == None)
 
@@ -106,7 +106,7 @@ libxltype.Aggregate
 
  Each field has the following properties:
 
-  Field.type	The type of the member (a libxltypes.Type).
+  Field.type	The type of the member (a idl.Type).
   Field.name    The name of the member (can be None for anonymous
 		fields).
   Field.const	Boolean, true if the member is const.
diff --git a/tools/ocaml/libs/xl/Makefile b/tools/ocaml/libs/xl/Makefile
--- a/tools/ocaml/libs/xl/Makefile
+++ b/tools/ocaml/libs/xl/Makefile
@@ -46,7 +46,7 @@ xenlight.mli: xenlight.mli.in _libxl_typ
 	$(Q)mv xenlight.mli.tmp xenlight.mli
 
 _libxl_types.ml.in _libxl_types.mli.in _libxl_types.inc: genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
-                $(XEN_ROOT)/tools/libxl/libxltypes.py
+                $(XEN_ROOT)/tools/libxl/idl.py
 	PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \
 		$(XEN_ROOT)/tools/libxl/libxl_types.idl \
 		_libxl_types.mli.in _libxl_types.ml.in _libxl_types.inc
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -2,7 +2,7 @@
 
 import sys,os
 
-import libxltypes
+import idl
 
 # typename -> ( ocaml_type, c_from_ocaml, ocaml_from_c )
 builtins = {
@@ -39,7 +39,7 @@ def stub_fn_name(ty, name):
 def ocaml_type_of(ty):
     if ty.rawname == "domid":
         return "domid"
-    elif isinstance(ty,libxltypes.UInt):
+    elif isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
             width = None
@@ -52,14 +52,14 @@ def ocaml_type_of(ty):
         else:
             return "int"
 
-    elif isinstance(ty,libxltypes.Builtin):
+    elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
         typename,_,_ = builtins[ty.typename]
         if not typename:
             raise NotImplementedError("No typename for Builtin %s (%s)" % (ty.typename, type(ty)))
         return typename
-    elif isinstance(ty,libxltypes.Aggregate):
+    elif isinstance(ty,idl.Aggregate):
         return ty.rawname.capitalize() + ".t"
     else:
         return ty.rawname
@@ -73,11 +73,11 @@ def gen_ocaml_ml(ty, interface, indent="
         s = ("""(* %s interface *)\n""" % ty.typename)
     else:
         s = ("""(* %s implementation *)\n""" % ty.typename)
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         s = "type %s = \n" % ty.rawname
         for v in ty.values:
             s += "\t | %s\n" % v.rawname
-    elif isinstance(ty, libxltypes.Aggregate):
+    elif isinstance(ty, idl.Aggregate):
         s = ""
         if ty.typename is None:
             raise NotImplementedError("%s has no typename" % type(ty))
@@ -113,7 +113,7 @@ def gen_ocaml_ml(ty, interface, indent="
 
 def c_val(ty, c, o, indent="", parent = None):
     s = indent
-    if isinstance(ty,libxltypes.UInt):
+    if isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
             width = None
@@ -125,14 +125,14 @@ def c_val(ty, c, o, indent="", parent = 
             s += "%s = Int%d_val(%s);" % (c, width, o)
         else:
             s += "%s = Int_val(%s);" % (c, o)
-    elif isinstance(ty,libxltypes.Builtin):
+    elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
         _,fn,_ = builtins[ty.typename]
         if not fn:
             raise NotImplementedError("No c_val fn for Builtin %s (%s)" % (ty.typename, type(ty)))
         s += "%s;" % (fn % { "o": o, "c": c })
-    elif isinstance(ty,libxltypes.Enumeration) and (parent is None):
+    elif isinstance(ty,idl.Enumeration) and (parent is None):
         n = 0
         s += "switch(Int_val(%s)) {\n" % o
         for e in ty.values:
@@ -140,21 +140,21 @@ def c_val(ty, c, o, indent="", parent = 
             n += 1
         s += "    default: failwith_xl(\"cannot convert value to %s\", lg); break;\n" % ty.typename
         s += "}"
-    elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
+    elif isinstance(ty, idl.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
             (nparent,fexpr) = ty.member(c, f, parent is None)
             s += "%s\n" % c_val(f.type, fexpr, "Field(%s, %d)" % (o,n), parent=nparent)
             n = n + 1
     else:
-        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, ty.pass_arg(c, parent is None, passby=libxltypes.PASS_BY_REFERENCE), o)
+        s += "%s_val(gc, lg, %s, %s);" % (ty.rawname, ty.pass_arg(c, parent is None, passby=idl.PASS_BY_REFERENCE), o)
     
     return s.replace("\n", "\n%s" % indent)
 
 def gen_c_val(ty, indent=""):
     s = "/* Convert caml value to %s */\n" % ty.rawname
     
-    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s, value v)\n" % (ty.rawname, ty.make_arg("c_val", passby=libxltypes.PASS_BY_REFERENCE))
+    s += "static int %s_val (caml_gc *gc, struct caml_logger *lg, %s, value v)\n" % (ty.rawname, ty.make_arg("c_val", passby=idl.PASS_BY_REFERENCE))
     s += "{\n"
     s += "\tCAMLparam1(v);\n"
     s += "\n"
@@ -168,7 +168,7 @@ def gen_c_val(ty, indent=""):
 
 def ocaml_Val(ty, o, c, indent="", parent = None):
     s = indent
-    if isinstance(ty,libxltypes.UInt):
+    if isinstance(ty,idl.UInt):
         if ty.width in [8, 16]:
             # handle as ints
             width = None
@@ -180,14 +180,14 @@ def ocaml_Val(ty, o, c, indent="", paren
             s += "%s = caml_copy_int%d(%s);" % (o, width, c)
         else:
             s += "%s = Val_int(%s);" % (o, c)
-    elif isinstance(ty,libxltypes.Builtin):
+    elif isinstance(ty,idl.Builtin):
         if not builtins.has_key(ty.typename):
             raise NotImplementedError("Unknown Builtin %s (%s)" % (ty.typename, type(ty)))
         _,_,fn = builtins[ty.typename]
         if not fn:
             raise NotImplementedError("No ocaml Val fn for Builtin %s (%s)" % (ty.typename, type(ty)))
         s += "%s = %s;" % (o, fn % { "c": c })
-    elif isinstance(ty,libxltypes.Enumeration) and (parent is None):
+    elif isinstance(ty,idl.Enumeration) and (parent is None):
         n = 0
         s += "switch(%s) {\n" % c
         for e in ty.values:
@@ -195,7 +195,7 @@ def ocaml_Val(ty, o, c, indent="", paren
             n += 1
         s += "    default: failwith_xl(\"cannot convert value from %s\", lg); break;\n" % ty.typename
         s += "}"
-    elif isinstance(ty,libxltypes.Aggregate) and (parent is None):
+    elif isinstance(ty,idl.Aggregate) and (parent is None):
         s += "{\n"
         s += "\tvalue %s_field;\n" % ty.rawname
         s += "\n"
@@ -251,8 +251,7 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: genwrap.py <idl> <mli> <ml> <c-inc>"
         sys.exit(1)
 
-    idl = sys.argv[1]
-    (_,types) = libxltypes.parse(idl)
+    (_,types) = idl.parse(sys.argv[1])
 
     # Do not generate these yet.
     blacklist = [
diff --git a/tools/python/Makefile b/tools/python/Makefile
--- a/tools/python/Makefile
+++ b/tools/python/Makefile
@@ -11,7 +11,7 @@ genpath-target = $(call buildmakevars2fi
 
 .PHONY: build
 build: genpath genwrap.py $(XEN_ROOT)/tools/libxl/libxl_types.idl \
-		$(XEN_ROOT)/tools/libxl/libxltypes.py
+		$(XEN_ROOT)/tools/libxl/idl.py
 	PYTHONPATH=$(XEN_ROOT)/tools/libxl $(PYTHON) genwrap.py \
 		$(XEN_ROOT)/tools/libxl/libxl_types.idl \
 		xen/lowlevel/xl/_pyxl_types.h \
diff --git a/tools/python/genwrap.py b/tools/python/genwrap.py
--- a/tools/python/genwrap.py
+++ b/tools/python/genwrap.py
@@ -2,23 +2,23 @@
 
 import sys,os
 
-import libxltypes
+import idl
 
 (TYPE_BOOL, TYPE_INT, TYPE_UINT, TYPE_STRING, TYPE_AGGREGATE) = range(5)
 
 def py_type(ty):
-    if ty == libxltypes.bool:
+    if ty == idl.bool:
         return TYPE_BOOL
-    if isinstance(ty, libxltypes.Enumeration):
+    if isinstance(ty, idl.Enumeration):
         return TYPE_UINT
-    if isinstance(ty, libxltypes.Number):
+    if isinstance(ty, idl.Number):
         if ty.signed:
             return TYPE_INT
         else:
             return TYPE_UINT
-    if isinstance(ty, libxltypes.Aggregate):
+    if isinstance(ty, idl.Aggregate):
         return TYPE_AGGREGATE
-    if ty == libxltypes.string:
+    if ty == idl.string:
         return TYPE_STRING
     return None
 
@@ -38,7 +38,7 @@ def fsanitize(name):
 
 def py_decls(ty):
     l = []
-    if isinstance(ty, libxltypes.Aggregate):
+    if isinstance(ty, idl.Aggregate):
         l.append('_hidden Py_%s *Py%s_New(void);\n'%(ty.rawname, ty.rawname))
         l.append('_hidden int Py%s_Check(PyObject *self);\n'%ty.rawname)
         for f in ty.fields:
@@ -211,10 +211,10 @@ def py_initfuncs(types):
     l.append('void genwrap__init(PyObject *m)')
     l.append('{')
     for ty in types:
-        if isinstance(ty, libxltypes.Enumeration):
+        if isinstance(ty, idl.Enumeration):
             for v in ty.values:
                 l.append('    PyModule_AddIntConstant(m, "%s", %s);' % (v.rawname, v.name))
-        elif isinstance(ty, libxltypes.Aggregate):
+        elif isinstance(ty, idl.Aggregate):
             l.append('    if (PyType_Ready(&Py%s_Type) >= 0) {'%ty.rawname)
             l.append('        Py_INCREF(&Py%s_Type);'%ty.rawname)
             l.append('        PyModule_AddObject(m, "%s", (PyObject *)&Py%s_Type);'%(ty.rawname, ty.rawname))
@@ -227,7 +227,7 @@ def py_initfuncs(types):
 
 def tree_frob(types):
     ret = types[:]
-    for ty in [ty for ty in ret if isinstance(ty, libxltypes.Aggregate)]:
+    for ty in [ty for ty in ret if isinstance(ty, idl.Aggregate)]:
         ty.fields = filter(lambda f:f.name is not None and f.type.typename is not None, ty.fields)
     return ret
 
@@ -236,8 +236,7 @@ if __name__ == '__main__':
         print >>sys.stderr, "Usage: genwrap.py <idl> <decls> <defns>"
         sys.exit(1)
 
-    idl = sys.argv[1]
-    (_,types) = libxltypes.parse(idl)
+    (_,types) = idl.parse(sys.argv[1])
 
     types = tree_frob(types)
 
@@ -278,7 +277,7 @@ _hidden PyObject *genwrap__ll_get(long l
 _hidden int genwrap__ll_set(PyObject *v, long long *val, long long mask);
 
 """ % " ".join(sys.argv))
-    for ty in [ty for ty in types if isinstance(ty, libxltypes.Aggregate)]:
+    for ty in [ty for ty in types if isinstance(ty, idl.Aggregate)]:
         f.write('/* Internal API for %s wrapper */\n'%ty.typename)
         f.write(py_wrapstruct(ty))
         f.write(py_decls(ty))
@@ -307,7 +306,7 @@ _hidden int genwrap__ll_set(PyObject *v,
     for ty in types:
         if ty.private:
             continue
-        if isinstance(ty, libxltypes.Aggregate):
+        if isinstance(ty, idl.Aggregate):
             f.write('/* Attribute get/set functions for %s */\n'%ty.typename)
             for a in ty.fields:
                 if a.type.private:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6aA-0005dr-TS; Wed, 25 Jan 2012 17:24:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a8-0005a4-Pc
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:25 +0000
Received: from [85.158.139.83:6086] by server-5.bemta-5.messagelabs.com id
	85/BC-12374-7CA302F4; Wed, 25 Jan 2012 17:24:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327512261!4945936!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16033 invoked from network); 25 Jan 2012 17:24:22 -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;
	25 Jan 2012 17:24:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21277757"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:20 -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
	q0PHOCME006355;	Wed, 25 Jan 2012 09:24:19 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0bf43ff297fc2cb4d6982da80cceec181deb6d55
Message-ID: <0bf43ff297fc2cb4d698.1327512257@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:17 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 7 of 9] libxl: drop libxl_cpuarray -- topology
 was the only 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327512175 0
# Node ID 0bf43ff297fc2cb4d6982da80cceec181deb6d55
# Parent  e1753f37c9064f1e84fa32dfc37ff0f286e2df1e
libxl: drop libxl_cpuarray -- topology was the only user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -21,7 +21,7 @@ def randomize_enum(e):
 
 handcoded = ["libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
-             "libxl_string_list", "libxl_cpuarray"]
+             "libxl_string_list"]
 
 def gen_rand_init(ty, v, indent = "    ", parent = None):
     s = ""
@@ -194,23 +194,6 @@ static void libxl_string_list_rand_init(
     l[i] = NULL;
     *p = l;
 }
-
-#if 0
-static void libxl_cpuarray_rand_init(libxl_cpuarray *p)
-{
-    int i;
-    /* Up to 16 VCPUs on 32 PCPUS */
-    p->entries = rand() % 16;
-    p->array = calloc(p->entries, sizeof(*p->array));
-    for (i = 0; i < p->entries; i++) {
-        int r = rand() % 32*1.5; /* 2:1 valid:invalid */
-        if (r >= 32)
-            p->array[i] = LIBXL_CPUARRAY_INVALID_ENTRY;
-        else
-            p->array[i] = r;
-    }
-}
-#endif
 """)
     for ty in builtins + types:
         if ty.typename not in handcoded:
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -158,13 +158,6 @@ typedef struct {
 void libxl_cpumap_dispose(libxl_cpumap *map);
 
 typedef struct {
-    uint32_t entries;
-    uint32_t *array;
-} libxl_cpuarray;
-#define LIBXL_CPUARRAY_INVALID_ENTRY  ~0
-void libxl_cpuarray_dispose(libxl_cpuarray *array);
-
-typedef struct {
     /*
      * Path is always set if the file reference is valid. However if
      * mapped is true then the actual file may already be unlinked.
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -246,27 +246,6 @@ out:
     return s;
 }
 
-yajl_gen_status libxl_cpuarray_gen_json(yajl_gen hand,
-                                        libxl_cpuarray *cpuarray)
-{
-    yajl_gen_status s;
-    int i;
-
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok) goto out;
-
-    for(i=0; i<cpuarray->entries; i++) {
-        if (cpuarray->array[i] == LIBXL_CPUARRAY_INVALID_ENTRY)
-            s = yajl_gen_null(hand);
-        else
-            s = yajl_gen_integer(hand, cpuarray->array[i]);
-        if (s != yajl_gen_status_ok) goto out;
-    }
-    s = yajl_gen_array_close(hand);
-out:
-    return s;
-}
-
 yajl_gen_status libxl_file_reference_gen_json(yajl_gen hand,
                                               libxl_file_reference *p)
 {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -9,7 +9,6 @@ libxl_domid = Builtin("domid", json_fn =
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
 libxl_cpumap = Builtin("cpumap", dispose_fn="libxl_cpumap_dispose", passby=PASS_BY_REFERENCE)
-libxl_cpuarray = Builtin("cpuarray", dispose_fn="libxl_cpuarray_dispose", passby=PASS_BY_REFERENCE)
 libxl_cpuid_policy_list = Builtin("cpuid_policy_list", dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE)
 
 libxl_string_list = Builtin("string_list", dispose_fn="libxl_string_list_dispose", passby=PASS_BY_REFERENCE)
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -514,30 +514,6 @@ void libxl_cpumap_reset(libxl_cpumap *cp
     cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
 }
 
-int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray)
-{
-    int max_cpus;
-    int i;
-
-    max_cpus = libxl_get_max_cpus(ctx);
-    if (max_cpus == 0)
-        return ERROR_FAIL;
-
-    cpuarray->array = calloc(max_cpus, sizeof(*cpuarray->array));
-    if (!cpuarray->array)
-        return ERROR_NOMEM;
-    cpuarray->entries = max_cpus;
-    for (i = 0; i < max_cpus; i++)
-        cpuarray->array[i] = LIBXL_CPUARRAY_INVALID_ENTRY;
-
-    return 0;
-}
-
-void libxl_cpuarray_dispose(libxl_cpuarray *array)
-{
-    free(array->array);
-}
-
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -72,8 +72,6 @@ void libxl_cpumap_set(libxl_cpumap *cpum
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
 
-int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
-
 static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
     return (s + 1023) / 1024;
 }
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -227,11 +227,6 @@ int attrib__libxl_cpumap_set(PyObject *v
     return 0;
 }
 
-int attrib__libxl_cpuarray_set(PyObject *v, libxl_cpuarray *pptr)
-{
-    return -1;
-}
-
 int attrib__libxl_file_reference_set(PyObject *v, libxl_file_reference *pptr)
 {
     return genwrap__string_set(v, &pptr->path);
@@ -304,25 +299,6 @@ PyObject *attrib__libxl_cpumap_get(libxl
     return cpulist;
 }
 
-PyObject *attrib__libxl_cpuarray_get(libxl_cpuarray *pptr)
-{
-    PyObject *list = NULL;
-    int i;
-
-    list = PyList_New(0);
-    for (i = 0; i < pptr->entries; i++) {
-        if (pptr->array[i] == LIBXL_CPUARRAY_INVALID_ENTRY) {
-            PyList_Append(list, Py_None);
-        } else {
-            PyObject* pyint = PyInt_FromLong(pptr->array[i]);
-
-            PyList_Append(list, pyint);
-            Py_DECREF(pyint);
-        }
-    }
-    return list;
-}
-
 PyObject *attrib__libxl_file_reference_get(libxl_file_reference *pptr)
 {
     return genwrap__string_get(&pptr->path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6aA-0005dr-TS; Wed, 25 Jan 2012 17:24:26 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a8-0005a4-Pc
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:25 +0000
Received: from [85.158.139.83:6086] by server-5.bemta-5.messagelabs.com id
	85/BC-12374-7CA302F4; Wed, 25 Jan 2012 17:24:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327512261!4945936!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTY5MDA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16033 invoked from network); 25 Jan 2012 17:24:22 -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;
	25 Jan 2012 17:24:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="21277757"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:20 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24:20 -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
	q0PHOCME006355;	Wed, 25 Jan 2012 09:24:19 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0bf43ff297fc2cb4d6982da80cceec181deb6d55
Message-ID: <0bf43ff297fc2cb4d698.1327512257@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:17 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 7 of 9] libxl: drop libxl_cpuarray -- topology
 was the only 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

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327512175 0
# Node ID 0bf43ff297fc2cb4d6982da80cceec181deb6d55
# Parent  e1753f37c9064f1e84fa32dfc37ff0f286e2df1e
libxl: drop libxl_cpuarray -- topology was the only user.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/gentest.py b/tools/libxl/gentest.py
--- a/tools/libxl/gentest.py
+++ b/tools/libxl/gentest.py
@@ -21,7 +21,7 @@ def randomize_enum(e):
 
 handcoded = ["libxl_cpumap", "libxl_key_value_list",
              "libxl_cpuid_policy_list", "libxl_file_reference",
-             "libxl_string_list", "libxl_cpuarray"]
+             "libxl_string_list"]
 
 def gen_rand_init(ty, v, indent = "    ", parent = None):
     s = ""
@@ -194,23 +194,6 @@ static void libxl_string_list_rand_init(
     l[i] = NULL;
     *p = l;
 }
-
-#if 0
-static void libxl_cpuarray_rand_init(libxl_cpuarray *p)
-{
-    int i;
-    /* Up to 16 VCPUs on 32 PCPUS */
-    p->entries = rand() % 16;
-    p->array = calloc(p->entries, sizeof(*p->array));
-    for (i = 0; i < p->entries; i++) {
-        int r = rand() % 32*1.5; /* 2:1 valid:invalid */
-        if (r >= 32)
-            p->array[i] = LIBXL_CPUARRAY_INVALID_ENTRY;
-        else
-            p->array[i] = r;
-    }
-}
-#endif
 """)
     for ty in builtins + types:
         if ty.typename not in handcoded:
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -158,13 +158,6 @@ typedef struct {
 void libxl_cpumap_dispose(libxl_cpumap *map);
 
 typedef struct {
-    uint32_t entries;
-    uint32_t *array;
-} libxl_cpuarray;
-#define LIBXL_CPUARRAY_INVALID_ENTRY  ~0
-void libxl_cpuarray_dispose(libxl_cpuarray *array);
-
-typedef struct {
     /*
      * Path is always set if the file reference is valid. However if
      * mapped is true then the actual file may already be unlinked.
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -246,27 +246,6 @@ out:
     return s;
 }
 
-yajl_gen_status libxl_cpuarray_gen_json(yajl_gen hand,
-                                        libxl_cpuarray *cpuarray)
-{
-    yajl_gen_status s;
-    int i;
-
-    s = yajl_gen_array_open(hand);
-    if (s != yajl_gen_status_ok) goto out;
-
-    for(i=0; i<cpuarray->entries; i++) {
-        if (cpuarray->array[i] == LIBXL_CPUARRAY_INVALID_ENTRY)
-            s = yajl_gen_null(hand);
-        else
-            s = yajl_gen_integer(hand, cpuarray->array[i]);
-        if (s != yajl_gen_status_ok) goto out;
-    }
-    s = yajl_gen_array_close(hand);
-out:
-    return s;
-}
-
 yajl_gen_status libxl_file_reference_gen_json(yajl_gen hand,
                                               libxl_file_reference *p)
 {
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -9,7 +9,6 @@ libxl_domid = Builtin("domid", json_fn =
 libxl_uuid = Builtin("uuid", passby=PASS_BY_REFERENCE)
 libxl_mac = Builtin("mac", passby=PASS_BY_REFERENCE)
 libxl_cpumap = Builtin("cpumap", dispose_fn="libxl_cpumap_dispose", passby=PASS_BY_REFERENCE)
-libxl_cpuarray = Builtin("cpuarray", dispose_fn="libxl_cpuarray_dispose", passby=PASS_BY_REFERENCE)
 libxl_cpuid_policy_list = Builtin("cpuid_policy_list", dispose_fn="libxl_cpuid_dispose", passby=PASS_BY_REFERENCE)
 
 libxl_string_list = Builtin("string_list", dispose_fn="libxl_string_list_dispose", passby=PASS_BY_REFERENCE)
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -514,30 +514,6 @@ void libxl_cpumap_reset(libxl_cpumap *cp
     cpumap->map[cpu / 8] &= ~(1 << (cpu & 7));
 }
 
-int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray)
-{
-    int max_cpus;
-    int i;
-
-    max_cpus = libxl_get_max_cpus(ctx);
-    if (max_cpus == 0)
-        return ERROR_FAIL;
-
-    cpuarray->array = calloc(max_cpus, sizeof(*cpuarray->array));
-    if (!cpuarray->array)
-        return ERROR_NOMEM;
-    cpuarray->entries = max_cpus;
-    for (i = 0; i < max_cpus; i++)
-        cpuarray->array[i] = LIBXL_CPUARRAY_INVALID_ENTRY;
-
-    return 0;
-}
-
-void libxl_cpuarray_dispose(libxl_cpuarray *array)
-{
-    free(array->array);
-}
-
 int libxl_get_max_cpus(libxl_ctx *ctx)
 {
     return xc_get_max_cpus(ctx->xch);
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -72,8 +72,6 @@ void libxl_cpumap_set(libxl_cpumap *cpum
 void libxl_cpumap_reset(libxl_cpumap *cpumap, int cpu);
 #define libxl_for_each_cpu(var, map) for (var = 0; var < (map).size * 8; var++)
 
-int libxl_cpuarray_alloc(libxl_ctx *ctx, libxl_cpuarray *cpuarray);
-
 static inline uint32_t libxl__sizekb_to_mb(uint32_t s) {
     return (s + 1023) / 1024;
 }
diff --git a/tools/python/xen/lowlevel/xl/xl.c b/tools/python/xen/lowlevel/xl/xl.c
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -227,11 +227,6 @@ int attrib__libxl_cpumap_set(PyObject *v
     return 0;
 }
 
-int attrib__libxl_cpuarray_set(PyObject *v, libxl_cpuarray *pptr)
-{
-    return -1;
-}
-
 int attrib__libxl_file_reference_set(PyObject *v, libxl_file_reference *pptr)
 {
     return genwrap__string_set(v, &pptr->path);
@@ -304,25 +299,6 @@ PyObject *attrib__libxl_cpumap_get(libxl
     return cpulist;
 }
 
-PyObject *attrib__libxl_cpuarray_get(libxl_cpuarray *pptr)
-{
-    PyObject *list = NULL;
-    int i;
-
-    list = PyList_New(0);
-    for (i = 0; i < pptr->entries; i++) {
-        if (pptr->array[i] == LIBXL_CPUARRAY_INVALID_ENTRY) {
-            PyList_Append(list, Py_None);
-        } else {
-            PyObject* pyint = PyInt_FromLong(pptr->array[i]);
-
-            PyList_Append(list, pyint);
-            Py_DECREF(pyint);
-        }
-    }
-    return list;
-}
-
 PyObject *attrib__libxl_file_reference_get(libxl_file_reference *pptr)
 {
     return genwrap__string_get(&pptr->path);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a9-0005bQ-F6; Wed, 25 Jan 2012 17:24:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a8-0005Wt-1B
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:24 +0000
Received: from [85.158.138.51:6487] by server-1.bemta-3.messagelabs.com id
	C4/A0-09565-7CA302F4; Wed, 25 Jan 2012 17:24:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19874 invoked from network); 25 Jan 2012 17:24:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076332"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24: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
	q0PHOCMF006355;	Wed, 25 Jan 2012 09:24:20 -0800
MIME-Version: 1.0
X-Mercurial-Node: f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
Message-ID: <f43e2015d86f4d4c7dfa.1327512258@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 8 of 9] libxl: add named enum for timer mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327512175 0
# Node ID f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
# Parent  0bf43ff297fc2cb4d6982da80cceec181deb6d55
libxl: add named enum for timer mode.

Unlike previous iterations of this patch the enum values now match the
underlying domctl values.

I looked at updating xl.cfg(5) for these while I was here but frankly, even
after reading the comment in xen/include/public/hvm/params.h, I don't have a
clue what they mean, no_missed_ticks_pending in particular might as well be
written in klingon...

For the same reason I didn't try and give the enum more user-friendly names.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -194,6 +194,8 @@ typedef struct {
 
 typedef struct libxl__ctx libxl_ctx;
 
+#define LIBXL_TIMER_MODE_DEFAULT LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS
+
 #include "_libxl_types.h"
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -250,6 +250,13 @@ out:
     return ret == 0 ? 0 : ERROR_FAIL;
 }
 
+static unsigned long timer_mode(const libxl_domain_build_info *info)
+{
+    const libxl_timer_mode mode = info->u.hvm.timer_mode;
+    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
+           mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
+    return ((unsigned long)mode);
+}
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
@@ -281,7 +288,7 @@ static int hvm_build_set_params(xc_inter
     xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN, info->u.hvm.viridian);
     xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED, (unsigned long) info->u.hvm.hpet);
 #endif
-    xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, (unsigned long) info->u.hvm.timer_mode);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
     xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->u.hvm.vpt_align);
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -96,6 +96,14 @@ libxl_tsc_mode = Enumeration("tsc_mode",
     (3, "native_paravirt"),
     ])
 
+# Consistent with the values defined for HVM_PARAM_TIMER_MODE.
+libxl_timer_mode = Enumeration("timer_mode", [
+    (0, "delay_for_missed_ticks"),
+    (1, "no_delay_for_missed_ticks"),
+    (2, "no_missed_ticks_pending"),
+    (3, "one_missed_tick_pending"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -232,7 +240,7 @@ libxl_domain_build_info = Struct("domain
                                        ("timeoffset", string),
                                        ("hpet", bool),
                                        ("vpt_align", bool),
-                                       ("timer_mode", integer),
+                                       ("timer_mode", libxl_timer_mode),
                                        ("nested_hvm", bool),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -357,7 +357,9 @@ static void printf_info(int domid,
         printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
         printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
-        printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
+        printf("\t\t\t(timer_mode %s)\n",
+               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
+
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
         printf("\t\t\t(no_incr_generationid %d)\n",
                     b_info->u.hvm.no_incr_generationid);
@@ -757,8 +759,30 @@ static void parse_config_data(const char
             b_info->u.hvm.hpet = l;
         if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
             b_info->u.hvm.vpt_align = l;
-        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
+
+        if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
+            const char *s = libxl_timer_mode_to_string(l);
+            fprintf(stderr, "WARNING: specifying \"timer_mode\" as an integer is deprecated. "
+                    "Please use the named parameter variant. %s%s%s\n",
+                    s ? "e.g. timer_mode=\"" : "",
+                    s ? s : "",
+                    s ? "\"" : "");
+
+            if (l < LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS ||
+                l > LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING) {
+                fprintf(stderr, "ERROR: invalid value %ld for \"timer_mode\"\n", l);
+                exit (1);
+            }
             b_info->u.hvm.timer_mode = l;
+        } else if (!xlu_cfg_get_string(config, "timer_mode", &buf, 0)) {
+            fprintf(stderr, "got a timer mode string: \"%s\"\n", buf);
+            if (libxl_timer_mode_from_string(buf, &b_info->u.hvm.timer_mode)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"timer_mode\"\n",
+                        buf);
+                exit (1);
+            }
+        }
+
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
         break;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:24:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:24:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6a9-0005bQ-F6; Wed, 25 Jan 2012 17:24:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rq6a8-0005Wt-1B
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:24:24 +0000
Received: from [85.158.138.51:6487] by server-1.bemta-3.messagelabs.com id
	C4/A0-09565-7CA302F4; Wed, 25 Jan 2012 17:24:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327512255!10589283!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjUwODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19874 invoked from network); 25 Jan 2012 17:24:22 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:24:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320642000"; d="scan'208";a="179076332"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 12:24:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 12:24: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
	q0PHOCMF006355;	Wed, 25 Jan 2012 09:24:20 -0800
MIME-Version: 1.0
X-Mercurial-Node: f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
Message-ID: <f43e2015d86f4d4c7dfa.1327512258@cosworth.uk.xensource.com>
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Wed, 25 Jan 2012 17:24:18 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com
Subject: [Xen-devel] [PATCH 8 of 9] libxl: add named enum for timer mode
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327512175 0
# Node ID f43e2015d86f4d4c7dfa4db69f9d580fb3d705d9
# Parent  0bf43ff297fc2cb4d6982da80cceec181deb6d55
libxl: add named enum for timer mode.

Unlike previous iterations of this patch the enum values now match the
underlying domctl values.

I looked at updating xl.cfg(5) for these while I was here but frankly, even
after reading the comment in xen/include/public/hvm/params.h, I don't have a
clue what they mean, no_missed_ticks_pending in particular might as well be
written in klingon...

For the same reason I didn't try and give the enum more user-friendly names.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -194,6 +194,8 @@ typedef struct {
 
 typedef struct libxl__ctx libxl_ctx;
 
+#define LIBXL_TIMER_MODE_DEFAULT LIBXL_TIMER_MODE_NO_DELAY_FOR_MISSED_TICKS
+
 #include "_libxl_types.h"
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -250,6 +250,13 @@ out:
     return ret == 0 ? 0 : ERROR_FAIL;
 }
 
+static unsigned long timer_mode(const libxl_domain_build_info *info)
+{
+    const libxl_timer_mode mode = info->u.hvm.timer_mode;
+    assert(mode != LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS &&
+           mode <= LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING);
+    return ((unsigned long)mode);
+}
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
@@ -281,7 +288,7 @@ static int hvm_build_set_params(xc_inter
     xc_set_hvm_param(handle, domid, HVM_PARAM_VIRIDIAN, info->u.hvm.viridian);
     xc_set_hvm_param(handle, domid, HVM_PARAM_HPET_ENABLED, (unsigned long) info->u.hvm.hpet);
 #endif
-    xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, (unsigned long) info->u.hvm.timer_mode);
+    xc_set_hvm_param(handle, domid, HVM_PARAM_TIMER_MODE, timer_mode(info));
     xc_set_hvm_param(handle, domid, HVM_PARAM_VPT_ALIGN, (unsigned long) info->u.hvm.vpt_align);
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -96,6 +96,14 @@ libxl_tsc_mode = Enumeration("tsc_mode",
     (3, "native_paravirt"),
     ])
 
+# Consistent with the values defined for HVM_PARAM_TIMER_MODE.
+libxl_timer_mode = Enumeration("timer_mode", [
+    (0, "delay_for_missed_ticks"),
+    (1, "no_delay_for_missed_ticks"),
+    (2, "no_missed_ticks_pending"),
+    (3, "one_missed_tick_pending"),
+    ])
+
 #
 # Complex libxl types
 #
@@ -232,7 +240,7 @@ libxl_domain_build_info = Struct("domain
                                        ("timeoffset", string),
                                        ("hpet", bool),
                                        ("vpt_align", bool),
-                                       ("timer_mode", integer),
+                                       ("timer_mode", libxl_timer_mode),
                                        ("nested_hvm", bool),
                                        ("no_incr_generationid", bool),
                                        ("nographic",        bool),
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -357,7 +357,9 @@ static void printf_info(int domid,
         printf("\t\t\t(viridian %d)\n", b_info->u.hvm.viridian);
         printf("\t\t\t(hpet %d)\n", b_info->u.hvm.hpet);
         printf("\t\t\t(vpt_align %d)\n", b_info->u.hvm.vpt_align);
-        printf("\t\t\t(timer_mode %d)\n", b_info->u.hvm.timer_mode);
+        printf("\t\t\t(timer_mode %s)\n",
+               libxl_timer_mode_to_string(b_info->u.hvm.timer_mode));
+
         printf("\t\t\t(nestedhvm %d)\n", b_info->u.hvm.nested_hvm);
         printf("\t\t\t(no_incr_generationid %d)\n",
                     b_info->u.hvm.no_incr_generationid);
@@ -757,8 +759,30 @@ static void parse_config_data(const char
             b_info->u.hvm.hpet = l;
         if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
             b_info->u.hvm.vpt_align = l;
-        if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
+
+        if (!xlu_cfg_get_long(config, "timer_mode", &l, 1)) {
+            const char *s = libxl_timer_mode_to_string(l);
+            fprintf(stderr, "WARNING: specifying \"timer_mode\" as an integer is deprecated. "
+                    "Please use the named parameter variant. %s%s%s\n",
+                    s ? "e.g. timer_mode=\"" : "",
+                    s ? s : "",
+                    s ? "\"" : "");
+
+            if (l < LIBXL_TIMER_MODE_DELAY_FOR_MISSED_TICKS ||
+                l > LIBXL_TIMER_MODE_ONE_MISSED_TICK_PENDING) {
+                fprintf(stderr, "ERROR: invalid value %ld for \"timer_mode\"\n", l);
+                exit (1);
+            }
             b_info->u.hvm.timer_mode = l;
+        } else if (!xlu_cfg_get_string(config, "timer_mode", &buf, 0)) {
+            fprintf(stderr, "got a timer mode string: \"%s\"\n", buf);
+            if (libxl_timer_mode_from_string(buf, &b_info->u.hvm.timer_mode)) {
+                fprintf(stderr, "ERROR: invalid value \"%s\" for \"timer_mode\"\n",
+                        buf);
+                exit (1);
+            }
+        }
+
         if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
             b_info->u.hvm.nested_hvm = l;
         break;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:28:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6eM-0007Zc-AW; Wed, 25 Jan 2012 17:28:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rq6eL-0007ZH-3N
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:28:45 +0000
Received: from [85.158.138.51:25790] by server-8.bemta-3.messagelabs.com id
	BE/B2-31878-CCB302F4; Wed, 25 Jan 2012 17:28:44 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327512522!10653072!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8255 invoked from network); 25 Jan 2012 17:28:43 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-4.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 17:28:43 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0PHMFI2029282;
	Wed, 25 Jan 2012 12:22:15 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0PHMFqX004516;
	Wed, 25 Jan 2012 12:22:15 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012512221413563 ; Wed, 25 Jan 2012 12:22:14 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1327511781.24561.354.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 12:22:14 -0500
Message-Id: <67ADAD60-3C59-41BE-A8DA-3A8BAFCB246D@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>
	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
	<1327511781.24561.354.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

I did not intend to top post. I have already posted this once on Xen-devel and got no response.

-----
	Subject: 	Re: [opensuse-virtual] After switching from "xm" to "xl" toolstack, can't get Guest networking to work.
	From: 	John McDermott CIV <john.mcdermott@nrl.navy.mil>
	Date: 	January 24, 2012 7:40:39 AM EST
	To: 	erin.balid@inoutbox.com
	Cc: 	xen-devel@lists.xensource.com


Erin,

We also have what appears to be this problem, on Fedora 16 with Xen 4.1.2. We can create guests with xm that connect to network but the same guest will not connect, when created by xl. In both cases we can see the appropriate vif has been created and attached (xl network-list shows it) but no connectivity from within the guest. (If I convert the same guest config file to virsh format, then virsh also creates and connects it to the network successfully.)

I post this to the list as evidence that this is not just a problem with SuSE.

Sincerely,

John
----

On Jan 23, 2012, at 6:39 PM, erin.balid@inoutbox.com wrote:

> Hi All.
> 
> This problem's got a little - not a lot! - of traction over at the
> xen-devel list.
> 
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01754.html. 
> 
> Rather than leave this open & uncommented here, I'm going to concentrate
> on that thread instead for now.
> 
> Erin
> -- 
> To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org
> To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942












On Jan 25, 2012, at 12:16 PM, Ian Campbell wrote:

> Please don't top post.
> 
> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>> This problem also happens in Fedora 16. Should we be making bugzilla
>> entries for problems with Xen?
> 
> There is more than one reason why networking may not work for you so
> there isn't necessarily any reason (yet) to think you are seeing the
> same issue.
> 
> I think xen-users or an equivalent fedora list would be an appropriate
> forum for your bug report in the first instance.
> 
> Ian.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:28:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:28:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6eM-0007Zc-AW; Wed, 25 Jan 2012 17:28:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rq6eL-0007ZH-3N
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:28:45 +0000
Received: from [85.158.138.51:25790] by server-8.bemta-3.messagelabs.com id
	BE/B2-31878-CCB302F4; Wed, 25 Jan 2012 17:28:44 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327512522!10653072!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8255 invoked from network); 25 Jan 2012 17:28:43 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-4.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 17:28:43 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0PHMFI2029282;
	Wed, 25 Jan 2012 12:22:15 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0PHMFqX004516;
	Wed, 25 Jan 2012 12:22:15 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012512221413563 ; Wed, 25 Jan 2012 12:22:14 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <1327511781.24561.354.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 12:22:14 -0500
Message-Id: <67ADAD60-3C59-41BE-A8DA-3A8BAFCB246D@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>
	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
	<1327511781.24561.354.camel@zakaz.uk.xensource.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
X-Mailer: Apple Mail (2.1084)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian,

I did not intend to top post. I have already posted this once on Xen-devel and got no response.

-----
	Subject: 	Re: [opensuse-virtual] After switching from "xm" to "xl" toolstack, can't get Guest networking to work.
	From: 	John McDermott CIV <john.mcdermott@nrl.navy.mil>
	Date: 	January 24, 2012 7:40:39 AM EST
	To: 	erin.balid@inoutbox.com
	Cc: 	xen-devel@lists.xensource.com


Erin,

We also have what appears to be this problem, on Fedora 16 with Xen 4.1.2. We can create guests with xm that connect to network but the same guest will not connect, when created by xl. In both cases we can see the appropriate vif has been created and attached (xl network-list shows it) but no connectivity from within the guest. (If I convert the same guest config file to virsh format, then virsh also creates and connects it to the network successfully.)

I post this to the list as evidence that this is not just a problem with SuSE.

Sincerely,

John
----

On Jan 23, 2012, at 6:39 PM, erin.balid@inoutbox.com wrote:

> Hi All.
> 
> This problem's got a little - not a lot! - of traction over at the
> xen-devel list.
> 
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01754.html. 
> 
> Rather than leave this open & uncommented here, I'm going to concentrate
> on that thread instead for now.
> 
> Erin
> -- 
> To unsubscribe, e-mail: opensuse-virtual+unsubscribe@opensuse.org
> To contact the owner, e-mail: opensuse-virtual+owner@opensuse.org

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942












On Jan 25, 2012, at 12:16 PM, Ian Campbell wrote:

> Please don't top post.
> 
> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>> This problem also happens in Fedora 16. Should we be making bugzilla
>> entries for problems with Xen?
> 
> There is more than one reason why networking may not work for you so
> there isn't necessarily any reason (yet) to think you are seeing the
> same issue.
> 
> I think xen-users or an equivalent fedora list would be an appropriate
> forum for your bug report in the first instance.
> 
> Ian.

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:33:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6ic-0007xn-1e; Wed, 25 Jan 2012 17:33:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq6ia-0007xc-Ly
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:33:08 +0000
Received: from [85.158.138.51:57355] by server-1.bemta-3.messagelabs.com id
	69/3F-09565-1DC302F4; Wed, 25 Jan 2012 17:33:05 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327512782!5503239!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19558 invoked from network); 25 Jan 2012 17:33:04 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 17:33:04 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 10:33:00 -0700
Message-ID: <4F203CCC.50705@suse.com>
Date: Wed, 25 Jan 2012 10:33:00 -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: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
	<1327511781.24561.354.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327511781.24561.354.camel@zakaz.uk.xensource.com>
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:
> Please don't top post.
>
> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>   
>> This problem also happens in Fedora 16. Should we be making bugzilla
>> entries for problems with Xen?
>>     
>
> There is more than one reason why networking may not work for you so
> there isn't necessarily any reason (yet) to think you are seeing the
> same issue.
>   

Yes, different issue.  I'd be really surprised if Fedora had this patch

http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:33:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17:33:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq6ic-0007xn-1e; Wed, 25 Jan 2012 17:33:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq6ia-0007xc-Ly
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:33:08 +0000
Received: from [85.158.138.51:57355] by server-1.bemta-3.messagelabs.com id
	69/3F-09565-1DC302F4; Wed, 25 Jan 2012 17:33:05 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327512782!5503239!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19558 invoked from network); 25 Jan 2012 17:33:04 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 17:33:04 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 10:33:00 -0700
Message-ID: <4F203CCC.50705@suse.com>
Date: Wed, 25 Jan 2012 10:33:00 -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: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
	<1327511781.24561.354.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327511781.24561.354.camel@zakaz.uk.xensource.com>
Cc: John McDermott CIV <john.mcdermott@nrl.navy.mil>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:
> Please don't top post.
>
> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>   
>> This problem also happens in Fedora 16. Should we be making bugzilla
>> entries for problems with Xen?
>>     
>
> There is more than one reason why networking may not work for you so
> there isn't necessarily any reason (yet) to think you are seeing the
> same issue.
>   

Yes, different issue.  I'd be really surprised if Fedora had this patch

http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:40:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17: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 1Rq6p9-0008Ce-5h; Wed, 25 Jan 2012 17:39:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rq6p7-0008CZ-8n
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:39:53 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327513186!2594719!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22792 invoked from network); 25 Jan 2012 17:39:46 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-5.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 17:39:46 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0PHdiIW001284;
	Wed, 25 Jan 2012 12:39:44 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0PHdiXP005778;
	Wed, 25 Jan 2012 12:39:44 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012512394313610 ; Wed, 25 Jan 2012 12:39:43 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <4F203CCC.50705@suse.com>
Date: Wed, 25 Jan 2012 12:39:44 -0500
Message-Id: <9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
	<1327511781.24561.354.camel@zakaz.uk.xensource.com>
	<4F203CCC.50705@suse.com>
To: Jim Fehlig <jfehlig@suse.com>
X-Mailer: Apple Mail (2.1084)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

So I should try this patch and report back if it works?

On Jan 25, 2012, at 12:33 PM, Jim Fehlig wrote:

> Ian Campbell wrote:
>> Please don't top post.
>> 
>> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>> 
>>> This problem also happens in Fedora 16. Should we be making bugzilla
>>> entries for problems with Xen?
>>> 
>> 
>> There is more than one reason why networking may not work for you so
>> there isn't necessarily any reason (yet) to think you are seeing the
>> same issue.
>> 
> 
> Yes, different issue.  I'd be really surprised if Fedora had this patch
> 
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
> 
> Regards,
> Jim

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:40:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17: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 1Rq6p9-0008Ce-5h; Wed, 25 Jan 2012 17:39:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rq6p7-0008CZ-8n
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:39:53 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327513186!2594719!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22792 invoked from network); 25 Jan 2012 17:39:46 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-5.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 17:39:46 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0PHdiIW001284;
	Wed, 25 Jan 2012 12:39:44 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0PHdiXP005778;
	Wed, 25 Jan 2012 12:39:44 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012512394313610 ; Wed, 25 Jan 2012 12:39:43 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <4F203CCC.50705@suse.com>
Date: Wed, 25 Jan 2012 12:39:44 -0500
Message-Id: <9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>
	<1327511781.24561.354.camel@zakaz.uk.xensource.com>
	<4F203CCC.50705@suse.com>
To: Jim Fehlig <jfehlig@suse.com>
X-Mailer: Apple Mail (2.1084)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

So I should try this patch and report back if it works?

On Jan 25, 2012, at 12:33 PM, Jim Fehlig wrote:

> Ian Campbell wrote:
>> Please don't top post.
>> 
>> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>> 
>>> This problem also happens in Fedora 16. Should we be making bugzilla
>>> entries for problems with Xen?
>>> 
>> 
>> There is more than one reason why networking may not work for you so
>> there isn't necessarily any reason (yet) to think you are seeing the
>> same issue.
>> 
> 
> Yes, different issue.  I'd be really surprised if Fedora had this patch
> 
> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
> 
> Regards,
> Jim

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:45:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17: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 1Rq6tu-0008N5-Sj; Wed, 25 Jan 2012 17:44: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 1Rq6tt-0008Mz-8t
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:44:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327513420!62472998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3574 invoked from network); 25 Jan 2012 17:43:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:43:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10288679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 17:44: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;
	Wed, 25 Jan 2012 17:44:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 17:44:47 +0000
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327513487.24561.355.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] BONUS: [PATCH 10 of 9] docs: document /etc/xen/xl.conf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327513374 0
# Node ID 6ad2a7d8805acd8f1b5eaf8ebb7b28007840c8f4
# Parent  9e3be181b2b70f521defcd55ecbd9967cd206fb2
docs: document /etc/xen/xl.conf

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9e3be181b2b7 -r 6ad2a7d8805a docs/man/xl.conf.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.conf.pod.5	Wed Jan 25 17:42:54 2012 +0000
@@ -0,0 +1,93 @@
+=head1 NAME
+
+/etc/xen/xl.conf - XL Global/Host Configuration 
+
+=head1 DESCRIPTION
+
+The F<xl.conf> file allows configuration of hostwide C<xl> toolstack
+options.
+
+For details of per-domain configuration options please see
+L<xl.cfg(5)>.
+
+=head1 SYNTAX
+
+The config file consists of a series of C<KEY=VALUE> pairs.
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<autoballoon=BOOLEAN>
+
+If enabled then C<xl> will not attempt to reduce the amount of memory
+assigned to domain 0 in order to create free memory when starting a
+new domain. You should set this if you use the C<dom0_mem> hypervisor
+command line to reduce the amount of memory given to domain 0 by
+default.
+
+Default: C<0>
+
+=item B<lockfile="PATH">
+
+Sets the path to the lock file used by xl to serialise certain
+operations (primarily domain creation).
+
+Default: C</var/lock/xl>
+
+=item B<vifscript="PATH">
+
+Configures the default hotplug script used by virtual network devices.
+
+Default: C</etc/xen/scripts/vif-bridge>
+
+=item B<output_format="json|sxp">
+
+Configures the default output format used by xl when printing "machine
+readable" information. The default is to use the C<JSON>
+L<http://www.json.org/> syntax. However for compatibility with the
+previous C<xm> toolstack this can be configured to use the old C<SXP>
+(S-Expression-like) syntax instead.
+
+Default: C<json>
+
+=back
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item L<xl.cfg(5)>
+
+=item http://www.json.org/
+
+=back



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 17:45:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 17: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 1Rq6tu-0008N5-Sj; Wed, 25 Jan 2012 17:44: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 1Rq6tt-0008Mz-8t
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 17:44:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327513420!62472998!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3574 invoked from network); 25 Jan 2012 17:43:40 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 17:43:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10288679"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 17:44: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;
	Wed, 25 Jan 2012 17:44:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wed, 25 Jan 2012 17:44:47 +0000
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327513487.24561.355.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: [Xen-devel] BONUS: [PATCH 10 of 9] docs: document /etc/xen/xl.conf
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327513374 0
# Node ID 6ad2a7d8805acd8f1b5eaf8ebb7b28007840c8f4
# Parent  9e3be181b2b70f521defcd55ecbd9967cd206fb2
docs: document /etc/xen/xl.conf

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9e3be181b2b7 -r 6ad2a7d8805a docs/man/xl.conf.pod.5
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.conf.pod.5	Wed Jan 25 17:42:54 2012 +0000
@@ -0,0 +1,93 @@
+=head1 NAME
+
+/etc/xen/xl.conf - XL Global/Host Configuration 
+
+=head1 DESCRIPTION
+
+The F<xl.conf> file allows configuration of hostwide C<xl> toolstack
+options.
+
+For details of per-domain configuration options please see
+L<xl.cfg(5)>.
+
+=head1 SYNTAX
+
+The config file consists of a series of C<KEY=VALUE> pairs.
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True> (any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is required.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<autoballoon=BOOLEAN>
+
+If enabled then C<xl> will not attempt to reduce the amount of memory
+assigned to domain 0 in order to create free memory when starting a
+new domain. You should set this if you use the C<dom0_mem> hypervisor
+command line to reduce the amount of memory given to domain 0 by
+default.
+
+Default: C<0>
+
+=item B<lockfile="PATH">
+
+Sets the path to the lock file used by xl to serialise certain
+operations (primarily domain creation).
+
+Default: C</var/lock/xl>
+
+=item B<vifscript="PATH">
+
+Configures the default hotplug script used by virtual network devices.
+
+Default: C</etc/xen/scripts/vif-bridge>
+
+=item B<output_format="json|sxp">
+
+Configures the default output format used by xl when printing "machine
+readable" information. The default is to use the C<JSON>
+L<http://www.json.org/> syntax. However for compatibility with the
+previous C<xm> toolstack this can be configured to use the old C<SXP>
+(S-Expression-like) syntax instead.
+
+Default: C<json>
+
+=back
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item L<xl.cfg(5)>
+
+=item http://www.json.org/
+
+=back



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 18:02:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 18:02:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq7Az-0000xe-6p; Wed, 25 Jan 2012 18:02:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq7Ax-0000xE-LR
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 18:02:27 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327514538!12570500!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30028 invoked from network); 25 Jan 2012 18:02:20 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 18:02:20 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 11:02:13 -0700
Message-ID: <4F2043A4.7080708@suse.com>
Date: Wed, 25 Jan 2012 11:02:12 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>	<1327511781.24561.354.camel@zakaz.uk.xensource.com>	<4F203CCC.50705@suse.com>
	<9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
In-Reply-To: <9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John McDermott CIV wrote:
> So I should try this patch and report back if it works?
>   

No, that patch causes the issue reported by Erin :-).  In Erin's case,
the vif was not connected to the bridge.  In the problem you described,
the vif was connected to the bridge but didn't work for other reasons.

Regards,
Jim

> On Jan 25, 2012, at 12:33 PM, Jim Fehlig wrote:
>
>   
>> Ian Campbell wrote:
>>     
>>> Please don't top post.
>>>
>>> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>>>
>>>       
>>>> This problem also happens in Fedora 16. Should we be making bugzilla
>>>> entries for problems with Xen?
>>>>
>>>>         
>>> There is more than one reason why networking may not work for you so
>>> there isn't necessarily any reason (yet) to think you are seeing the
>>> same issue.
>>>
>>>       
>> Yes, different issue.  I'd be really surprised if Fedora had this patch
>>
>> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
>>
>> Regards,
>> Jim
>>     
>
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
>
> J.P. McDermott			building 12
> Code 5542			john.mcdermott@nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 18:02:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 18:02:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq7Az-0000xe-6p; Wed, 25 Jan 2012 18:02:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1Rq7Ax-0000xE-LR
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 18:02:27 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327514538!12570500!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30028 invoked from network); 25 Jan 2012 18:02:20 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 18:02:20 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 11:02:13 -0700
Message-ID: <4F2043A4.7080708@suse.com>
Date: Wed, 25 Jan 2012 11:02:12 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>	<1327511781.24561.354.camel@zakaz.uk.xensource.com>	<4F203CCC.50705@suse.com>
	<9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
In-Reply-To: <9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John McDermott CIV wrote:
> So I should try this patch and report back if it works?
>   

No, that patch causes the issue reported by Erin :-).  In Erin's case,
the vif was not connected to the bridge.  In the problem you described,
the vif was connected to the bridge but didn't work for other reasons.

Regards,
Jim

> On Jan 25, 2012, at 12:33 PM, Jim Fehlig wrote:
>
>   
>> Ian Campbell wrote:
>>     
>>> Please don't top post.
>>>
>>> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>>>
>>>       
>>>> This problem also happens in Fedora 16. Should we be making bugzilla
>>>> entries for problems with Xen?
>>>>
>>>>         
>>> There is more than one reason why networking may not work for you so
>>> there isn't necessarily any reason (yet) to think you are seeing the
>>> same issue.
>>>
>>>       
>> Yes, different issue.  I'd be really surprised if Fedora had this patch
>>
>> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
>>
>> Regards,
>> Jim
>>     
>
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
>
> J.P. McDermott			building 12
> Code 5542			john.mcdermott@nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 18:04:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 18:04:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq7Cb-00014h-N7; Wed, 25 Jan 2012 18:04:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rq7Ca-00014Y-Tn
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 18:04:09 +0000
Received: from [85.158.139.83:14092] by server-5.bemta-5.messagelabs.com id
	4B/5F-12374-814402F4; Wed, 25 Jan 2012 18:04:08 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327514646!12372341!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13529 invoked from network); 25 Jan 2012 18:04:07 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 18:04:07 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PI3OOv017289;
	Wed, 25 Jan 2012 13:03:25 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 25 Jan 2012 13:03:12 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: GPLPV and pci passthrough
Thread-Index: Aczbi5pS4UQEljXgRDKydrkry+FyIQ==
From: <djmagee@mageenet.net>
To: <lta@akr.fm>, <james.harper@bendigoit.com.au>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] GPLPV and 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

James,
	At least one other person (Lta, included in this message) and I
have had problems using passthrough pci devices and your GPLPV drivers
at the same time.  My symptoms are that SMB connections are totally
unreliable (however, downloading over http seems to work well enough).
For example, if I start a video or audio file, playing from the network,
it will play the first few seconds fine, then the connection drops out.
I can confirm that the problems don't exist when not passing through any
devices.

	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU
with an ATI 4770, USB controller, and ICE1712 based pci sound card
passed through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.

	I tried the -debug drivers, and I see a ton of output in qemu
log, however, all that output seems to be at initialization.  I do not
see any additional output from your drivers after boot, including when
I'm experiencing problems.

	I took a quick look at tcpdump output and it does seem the guest
is ACKing the packets as they come in, so my first guess is that they're
getting lost somewhere between the driver and the OS network stack.

	I've never set up a build environment for these drivers so I
haven't tried adding any extra debug output.  Have you looked into the
(or a similar) problem before, or have a more verbose debug copy of the
net driver you've used to diagnose similar problems before?

	I guess the real question is, do you have any idea where we
should start looking?

Thanks,
Doug

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 18:04:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 18:04:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq7Cb-00014h-N7; Wed, 25 Jan 2012 18:04:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rq7Ca-00014Y-Tn
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 18:04:09 +0000
Received: from [85.158.139.83:14092] by server-5.bemta-5.messagelabs.com id
	4B/5F-12374-814402F4; Wed, 25 Jan 2012 18:04:08 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327514646!12372341!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13529 invoked from network); 25 Jan 2012 18:04:07 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-12.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 25 Jan 2012 18:04:07 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PI3OOv017289;
	Wed, 25 Jan 2012 13:03:25 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 25 Jan 2012 13:03:12 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: GPLPV and pci passthrough
Thread-Index: Aczbi5pS4UQEljXgRDKydrkry+FyIQ==
From: <djmagee@mageenet.net>
To: <lta@akr.fm>, <james.harper@bendigoit.com.au>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] GPLPV and 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

James,
	At least one other person (Lta, included in this message) and I
have had problems using passthrough pci devices and your GPLPV drivers
at the same time.  My symptoms are that SMB connections are totally
unreliable (however, downloading over http seems to work well enough).
For example, if I start a video or audio file, playing from the network,
it will play the first few seconds fine, then the connection drops out.
I can confirm that the problems don't exist when not passing through any
devices.

	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU
with an ATI 4770, USB controller, and ICE1712 based pci sound card
passed through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.

	I tried the -debug drivers, and I see a ton of output in qemu
log, however, all that output seems to be at initialization.  I do not
see any additional output from your drivers after boot, including when
I'm experiencing problems.

	I took a quick look at tcpdump output and it does seem the guest
is ACKing the packets as they come in, so my first guess is that they're
getting lost somewhere between the driver and the OS network stack.

	I've never set up a build environment for these drivers so I
haven't tried adding any extra debug output.  Have you looked into the
(or a similar) problem before, or have a more verbose debug copy of the
net driver you've used to diagnose similar problems before?

	I guess the real question is, do you have any idea where we
should start looking?

Thanks,
Doug

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 18:52:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 18:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq7xC-0002WL-Te; Wed, 25 Jan 2012 18:52:18 +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 1Rq7xB-0002WD-7Y
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 18:52:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327517531!2601899!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13444 invoked from network); 25 Jan 2012 18:52:11 -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;
	25 Jan 2012 18:52:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10289906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 18:52:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 18:52:11 +0000
Date: Wed, 25 Jan 2012 18:52:51 +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: <1327502278-1790-17-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201251851360.3196@kaball-desktop>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327502278-1790-17-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 16/23] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> Add option for compiling xenstored without unix sockets to support
> running on mini-OS

It looks much nicer now, thanks.


> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_core.c |   28 +++++++++++++++++++++++-----
>  1 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 0e7d43f..c1ee932 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -19,9 +19,11 @@
>  
>  #include <sys/types.h>
>  #include <sys/stat.h>
> -#include <sys/socket.h>
>  #include <sys/select.h>
> +#ifndef NO_SOCKETS
> +#include <sys/socket.h>
>  #include <sys/un.h>
> +#endif
>  #include <sys/time.h>
>  #include <time.h>
>  #include <unistd.h>
> @@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	FD_ZERO(inset);
>  	FD_ZERO(outset);
>  
> -	set_fd(sock,               inset, &max);
> -	set_fd(ro_sock,            inset, &max);
> +	if (sock != -1)
> +		set_fd(sock, inset, &max);
> +	if (ro_sock != -1)
> +		set_fd(ro_sock, inset, &max);
>  	set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
> @@ -1345,6 +1349,11 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
>  	return new;
>  }
>  
> +#ifdef NO_SOCKETS
> +static void accept_connection(int sock, bool canwrite)
> +{
> +}
> +#else
>  static int writefd(struct connection *conn, const void *data, unsigned int len)
>  {
>  	int rc;
> @@ -1399,6 +1408,7 @@ static void accept_connection(int sock, bool canwrite)
>  	} else
>  		close(fd);
>  }
> +#endif
>  
>  #define TDB_FLAGS 0
>  
> @@ -1698,6 +1708,13 @@ static void daemonize(void)
>  	umask(0);
>  }
>  
> +#ifdef NO_SOCKETS
> +static void init_sockets(int **psock, int **pro_sock)
> +{
> +	static int minus_one = -1;
> +	*psock = *pro_sock = &minus_one;
> +}
> +#else
>  static int destroy_fd(void *_fd)
>  {
>  	int *fd = _fd;
> @@ -1743,6 +1760,7 @@ static void init_sockets(int **psock, int **pro_sock)
>  
>  
>  }
> +#endif
>  
>  static void usage(void)
>  {
> @@ -1938,10 +1956,10 @@ int main(int argc, char *argv[])
>  			reopen_log();
>  		}
>  
> -		if (FD_ISSET(*sock, &inset))
> +		if (*sock != -1 && FD_ISSET(*sock, &inset))
>  			accept_connection(*sock, true);
>  
> -		if (FD_ISSET(*ro_sock, &inset))
> +		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
>  			accept_connection(*ro_sock, false);
>  
>  		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 18:52:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 18:52:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq7xC-0002WL-Te; Wed, 25 Jan 2012 18:52:18 +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 1Rq7xB-0002WD-7Y
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 18:52:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327517531!2601899!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13444 invoked from network); 25 Jan 2012 18:52:11 -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;
	25 Jan 2012 18:52:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10289906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 18:52:11 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Wed, 25 Jan 2012 18:52:11 +0000
Date: Wed, 25 Jan 2012 18:52:51 +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: <1327502278-1790-17-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201251851360.3196@kaball-desktop>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327502278-1790-17-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 16/23] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> Add option for compiling xenstored without unix sockets to support
> running on mini-OS

It looks much nicer now, thanks.


> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/xenstored_core.c |   28 +++++++++++++++++++++++-----
>  1 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 0e7d43f..c1ee932 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -19,9 +19,11 @@
>  
>  #include <sys/types.h>
>  #include <sys/stat.h>
> -#include <sys/socket.h>
>  #include <sys/select.h>
> +#ifndef NO_SOCKETS
> +#include <sys/socket.h>
>  #include <sys/un.h>
> +#endif
>  #include <sys/time.h>
>  #include <time.h>
>  #include <unistd.h>
> @@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  	FD_ZERO(inset);
>  	FD_ZERO(outset);
>  
> -	set_fd(sock,               inset, &max);
> -	set_fd(ro_sock,            inset, &max);
> +	if (sock != -1)
> +		set_fd(sock, inset, &max);
> +	if (ro_sock != -1)
> +		set_fd(ro_sock, inset, &max);
>  	set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
> @@ -1345,6 +1349,11 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
>  	return new;
>  }
>  
> +#ifdef NO_SOCKETS
> +static void accept_connection(int sock, bool canwrite)
> +{
> +}
> +#else
>  static int writefd(struct connection *conn, const void *data, unsigned int len)
>  {
>  	int rc;
> @@ -1399,6 +1408,7 @@ static void accept_connection(int sock, bool canwrite)
>  	} else
>  		close(fd);
>  }
> +#endif
>  
>  #define TDB_FLAGS 0
>  
> @@ -1698,6 +1708,13 @@ static void daemonize(void)
>  	umask(0);
>  }
>  
> +#ifdef NO_SOCKETS
> +static void init_sockets(int **psock, int **pro_sock)
> +{
> +	static int minus_one = -1;
> +	*psock = *pro_sock = &minus_one;
> +}
> +#else
>  static int destroy_fd(void *_fd)
>  {
>  	int *fd = _fd;
> @@ -1743,6 +1760,7 @@ static void init_sockets(int **psock, int **pro_sock)
>  
>  
>  }
> +#endif
>  
>  static void usage(void)
>  {
> @@ -1938,10 +1956,10 @@ int main(int argc, char *argv[])
>  			reopen_log();
>  		}
>  
> -		if (FD_ISSET(*sock, &inset))
> +		if (*sock != -1 && FD_ISSET(*sock, &inset))
>  			accept_connection(*sock, true);
>  
> -		if (FD_ISSET(*ro_sock, &inset))
> +		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
>  			accept_connection(*ro_sock, false);
>  
>  		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
> -- 
> 1.7.7.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:06:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19: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 1Rq8AQ-0002qN-9D; Wed, 25 Jan 2012 19:05:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1Rq8AO-0002qI-3J
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:05:56 +0000
Received: from [85.158.139.83:19300] by server-8.bemta-5.messagelabs.com id
	1B/2E-20787-392502F4; Wed, 25 Jan 2012 19:05:55 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327518354!12308769!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 25 Jan 2012 19:05:54 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 19:05:54 -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=aNiXWlIe09vTa6EwjgARP7SOcKRFjkh9YlH8lhUNRKs=; b=Z/orAOE
	s7lAdP6SqxulDKWu3XgbGNCsSESMv2512PbNUcvZdrqssXUlxuZ0+8i1CUfjlOeU
	OzCGjCJtohvDxzoPv9wsoqaO6LxkHkQSy0f77gzt+ysByDhdFt769gLzAZBVpu2l
	kyp87leVEuGKqU2t3Pn1zxWQJqlAU++uIaJI=
Received: (qmail 18288 invoked from network); 25 Jan 2012 20:05:53 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.223.117)
	by mail.zeus06.de with ESMTPA; 25 Jan 2012 20:05:53 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id B04852C55B;
	Wed, 25 Jan 2012 20:06:14 +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 VufPegMr4BJx; Wed, 25 Jan 2012 20:06:12 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 7EE2A2C55A;
	Wed, 25 Jan 2012 20:06:12 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Wed, 25 Jan 2012 20:06:12 +0100
Mime-Version: 1.0
In-Reply-To: <20120123223213.GA31929@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AczblGdziMsb+yx4SiyF7dRckwqFcg==
Message-Id: <zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
Cc: =?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Jan_Beulich?= <JBeulich@suse.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

Some news: in order to prepare a clean setting, I upgraded to 3.2.1 kernel.=
 I noticed that the load increase is
reduced a bit, but noticably. It's only a simple test, running the DomU for=
 2 minutes, but the idle load is aprox.

  - 2.6.32 pvops		12-13%
  - 3.2.1 pvops		10-11%
  - 2.6.34 XenoLinux	7-8%

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: Montag, 23. Januar 2012 23:32
An: Konrad Rzeszutek Wilk
Cc: Sander Eikelenboom; xen-devel; Jan Beulich
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com=
> wrote:
> > > The issue as I understand is that the DVB drivers allocate their =

> > > buffers from 0->4GB most (all the time?) so they never have to do bou=
nce-buffering.
> > > =

> > > While the pv-ops one ends up quite frequently doing the =

> > > bounce-buffering, which implies that the DVB drivers end up =

> > > allocating their buffers above the 4GB.
> > > This means we end up spending some CPU time (in the guest) copying =

> > > the memory from >4GB to 0-4GB region (And vice-versa).
> > =

> > This reminds me of something (not sure what XenoLinux you use for
> > comparison) - how are they allocating that memory? Not vmalloc_32()
> =

> I was using the 2.6.18, then the one I saw on Google for Gentoo, and =

> now I am going to look at the 2.6.38 from OpenSuSE.
> =

> > by chance (I remember having seen numerous uses under - iirc - =

> > drivers/media/)?
> > =

> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do =

> > what their (driver) callers might expect in a PV guest (including =

> > the contiguity assumption for the latter, recalling that you earlier =

> > said you were able to see the problem after several guest starts), =

> > and I had put into our kernels an adjustment to make vmalloc_32() =

> > actually behave as expected.
> =

> Aaah.. The plot thickens! Let me look in the sources! Thanks for the =

> pointer.

Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32 =
and then performs PCI DMA operations on the allocted vmalloc_32 area.

So I cobbled up the attached patch (hadn't actually tested it and sadly won=
't until next week) which removes the call to vmalloc_32 and instead sets u=
p DMA allocated set of pages.

If that fixes it for you that is awesome, but if it breaks please send me y=
our logs.

Cheers,
Konrad
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/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 Jan 25 19:06:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19: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 1Rq8AQ-0002qN-9D; Wed, 25 Jan 2012 19:05:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <carsten@schiers.de>) id 1Rq8AO-0002qI-3J
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:05:56 +0000
Received: from [85.158.139.83:19300] by server-8.bemta-5.messagelabs.com id
	1B/2E-20787-392502F4; Wed, 25 Jan 2012 19:05:55 +0000
X-Env-Sender: carsten@schiers.de
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327518354!12308769!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31420 invoked from network); 25 Jan 2012 19:05:54 -0000
Received: from www.zeus06.de (HELO mail.zeus06.de) (194.117.254.36)
	by server-7.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 19:05:54 -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=aNiXWlIe09vTa6EwjgARP7SOcKRFjkh9YlH8lhUNRKs=; b=Z/orAOE
	s7lAdP6SqxulDKWu3XgbGNCsSESMv2512PbNUcvZdrqssXUlxuZ0+8i1CUfjlOeU
	OzCGjCJtohvDxzoPv9wsoqaO6LxkHkQSy0f77gzt+ysByDhdFt769gLzAZBVpu2l
	kyp87leVEuGKqU2t3Pn1zxWQJqlAU++uIaJI=
Received: (qmail 18288 invoked from network); 25 Jan 2012 20:05:53 +0100
Received: from unknown (HELO uhura.zz) (l3s6271p1@46.59.223.117)
	by mail.zeus06.de with ESMTPA; 25 Jan 2012 20:05:53 +0100
Received: from localhost (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id B04852C55B;
	Wed, 25 Jan 2012 20:06:14 +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 VufPegMr4BJx; Wed, 25 Jan 2012 20:06:12 +0100 (CET)
Received: from uhura.space.zz (localhost [127.0.0.1])
	by uhura.zz (Postfix) with ESMTP id 7EE2A2C55A;
	Wed, 25 Jan 2012 20:06:12 +0100 (CET)
From: =?iso-8859-1?Q?Carsten_Schiers?= <carsten@schiers.de>
To: =?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad.wilk@oracle.com>, 
	=?iso-8859-1?Q?Konrad_Rzeszutek_Wilk?= <konrad@darnok.org>
Date: Wed, 25 Jan 2012 20:06:12 +0100
Mime-Version: 1.0
In-Reply-To: <20120123223213.GA31929@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
X-Priority: 3 (Normal)
X-Mailer: Zarafa 7.0.2-29470
Thread-Index: AczblGdziMsb+yx4SiyF7dRckwqFcg==
Message-Id: <zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
Cc: =?iso-8859-1?Q?Sander_Eikelenboom?= <linux@eikelenboom.it>,
	=?iso-8859-1?Q?xen-devel?= <xen-devel@lists.xensource.com>,
	=?iso-8859-1?Q?Jan_Beulich?= <JBeulich@suse.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

Some news: in order to prepare a clean setting, I upgraded to 3.2.1 kernel.=
 I noticed that the load increase is
reduced a bit, but noticably. It's only a simple test, running the DomU for=
 2 minutes, but the idle load is aprox.

  - 2.6.32 pvops		12-13%
  - 3.2.1 pvops		10-11%
  - 2.6.34 XenoLinux	7-8%

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: Montag, 23. Januar 2012 23:32
An: Konrad Rzeszutek Wilk
Cc: Sander Eikelenboom; xen-devel; Jan Beulich
Betreff: Re: [Xen-devel] Load increase after memory upgrade (part2)

On Wed, Jan 18, 2012 at 10:29:23AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 18, 2012 at 11:35:35AM +0000, Jan Beulich wrote:
> > >>> On 17.01.12 at 22:02, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com=
> wrote:
> > > The issue as I understand is that the DVB drivers allocate their =

> > > buffers from 0->4GB most (all the time?) so they never have to do bou=
nce-buffering.
> > > =

> > > While the pv-ops one ends up quite frequently doing the =

> > > bounce-buffering, which implies that the DVB drivers end up =

> > > allocating their buffers above the 4GB.
> > > This means we end up spending some CPU time (in the guest) copying =

> > > the memory from >4GB to 0-4GB region (And vice-versa).
> > =

> > This reminds me of something (not sure what XenoLinux you use for
> > comparison) - how are they allocating that memory? Not vmalloc_32()
> =

> I was using the 2.6.18, then the one I saw on Google for Gentoo, and =

> now I am going to look at the 2.6.38 from OpenSuSE.
> =

> > by chance (I remember having seen numerous uses under - iirc - =

> > drivers/media/)?
> > =

> > Obviously, vmalloc_32() and any GFP_DMA32 allocations do *not* do =

> > what their (driver) callers might expect in a PV guest (including =

> > the contiguity assumption for the latter, recalling that you earlier =

> > said you were able to see the problem after several guest starts), =

> > and I had put into our kernels an adjustment to make vmalloc_32() =

> > actually behave as expected.
> =

> Aaah.. The plot thickens! Let me look in the sources! Thanks for the =

> pointer.

Jan hints lead me to the videobuf-dma-sg.c which does indeed to vmalloc_32 =
and then performs PCI DMA operations on the allocted vmalloc_32 area.

So I cobbled up the attached patch (hadn't actually tested it and sadly won=
't until next week) which removes the call to vmalloc_32 and instead sets u=
p DMA allocated set of pages.

If that fixes it for you that is awesome, but if it breaks please send me y=
our logs.

Cheers,
Konrad
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/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 Jan 25 19:14:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19: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 1Rq8IN-0003Je-96; Wed, 25 Jan 2012 19:14:11 +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 1Rq8IL-0003JS-Gt
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:14:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327518821!50245858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11972 invoked from network); 25 Jan 2012 19:13:41 -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;
	25 Jan 2012 19:13:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10290392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 19:14: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; Wed, 25 Jan 2012 19:14:03 +0000
Date: Wed, 25 Jan 2012 19:14:43 +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: <1327502278-1790-19-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201251854530.3196@kaball-desktop>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327502278-1790-19-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 18/23] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/Makefile           |    9 ++++++++-
>  tools/xenstore/tdb.c              |    6 +++---
>  tools/xenstore/utils.h            |    2 ++
>  tools/xenstore/xenstored_core.c   |   29 ++++++++++++++++++++++++++---
>  tools/xenstore/xenstored_domain.c |   11 +++++++++++
>  5 files changed, 50 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 4facb62..be892fd 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -28,6 +28,10 @@ endif
>  
>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>  
> +ifdef CONFIG_STUBDOM
> +CFLAGS += -DNO_SOCKETS=1
> +endif
> +
>  .PHONY: all
>  all: $(ALL_TARGETS)
>  
> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
>  
>  CFLAGS += -DHAVE_DTRACE=1
>  endif
> - 
> +
>  xenstored: $(XENSTORED_OBJS)
>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
> +xenstored.a: $(XENSTORED_OBJS)
> +	$(AR) cr $@ $^
> +
>  $(CLIENTS): xenstore
>  	ln -f xenstore $@
>  
> diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
> index 3ecd3fc..cb66ea7 100644
> --- a/tools/xenstore/tdb.c
> +++ b/tools/xenstore/tdb.c
> @@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>  
>  		/* Iterate through chain */
>  		while( tlock->off) {
> -			tdb_off current;
> +			tdb_off mycurrent;
>  			if (rec_read(tdb, tlock->off, rec) == -1)
>  				goto fail;
>  
> @@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>  			}
>  
>  			/* Try to clean dead ones from old traverses */
> -			current = tlock->off;
> +			mycurrent = tlock->off;
>  			tlock->off = rec->next;
>  			if (!tdb->read_only && 
> -			    do_delete(tdb, current, rec) != 0)
> +			    do_delete(tdb, mycurrent, rec) != 0)
>  				goto fail;
>  		}
>  		tdb_unlock(tdb, tlock->hash, F_WRLCK);

Why are you renaming current to mycurrent?


> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
> index f378343..2effd17 100644
> --- a/tools/xenstore/utils.h
> +++ b/tools/xenstore/utils.h
> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>  	return streq(a + strlen(a) - strlen(b), b);
>  }
>  
> +#ifndef ARRAY_SIZE
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
>  
>  void barf(const char *fmt, ...) __attribute__((noreturn));
>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index c1ee932..7564edd 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -92,8 +92,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
>  
>  bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
>  {
> +#ifndef __MINIOS__
>  	if (rename(newname, xs_daemon_tdb()) != 0)
>  		return false;
> +#endif
>  	tdb_close(tdb_ctx);
>  	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
>  	return true;

Are you doing this because the database is not on file anymore, correct?
Maybe there is some room for introducing this concept more generally
because it could be useful on Linux too and it would avoid this and
other ifdef's.


> @@ -223,7 +225,6 @@ static void reopen_log(void)
>  	}
>  }
>  
> -
>  static bool write_messages(struct connection *conn)
>  {
>  	int ret;
> @@ -326,7 +327,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  		set_fd(sock, inset, &max);
>  	if (ro_sock != -1)
>  		set_fd(ro_sock, inset, &max);
> -	set_fd(reopen_log_pipe[0], inset, &max);
> +	if (reopen_log_pipe[0] != -1)
> +		set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1410,7 +1412,11 @@ static void accept_connection(int sock, bool canwrite)
>  }
>  #endif
>  
> +#ifdef __MINIOS__
> +#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
> +#else
>  #define TDB_FLAGS 0
> +#endif

See above

>  /* We create initial nodes manually. */
>  static void manual_node(const char *name, const char *child)
> @@ -1435,7 +1441,11 @@ static void setup_structure(void)
>  {
>  	char *tdbname;
>  	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
> +#ifdef __MINIOS__
> +	tdb_ctx = NULL;
> +#else
>  	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
> +#endif

ditto

>  	if (tdb_ctx) {
>  		/* XXX When we make xenstored able to restart, this will have
> @@ -1661,6 +1671,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
>  
>  
> +#ifndef __MINIOS__
>  static void write_pidfile(const char *pidfile)
>  {
>  	char buf[100];
> @@ -1707,6 +1718,7 @@ static void daemonize(void)
>  	/* Discard our parent's old-fashioned umask prejudices. */
>  	umask(0);
>  }
> +#endif
>  
>  #ifdef NO_SOCKETS
>  static void init_sockets(int **psock, int **pro_sock)
> @@ -1866,6 +1878,7 @@ int main(int argc, char *argv[])
>  
>  	reopen_log();
>  
> +#ifndef __MINIOS__
>  	/* make sure xenstored directory exists */
>  	if (mkdir(xs_daemon_rundir(), 0755)) {
>  		if (errno != EEXIST) {
> @@ -1887,6 +1900,7 @@ int main(int argc, char *argv[])
>  	}
>  	if (pidfile)
>  		write_pidfile(pidfile);
> +#endif

Maybe we could just have this fail gracefully: after all even on Linux
if the socket interface is not available everything should be able to
run correctly.


>  	/* Talloc leak reports go to stderr, which is closed if we fork. */
>  	if (!dofork)
> @@ -1897,9 +1911,14 @@ int main(int argc, char *argv[])
>  
>  	init_sockets(&sock, &ro_sock);
>  
> +#ifdef __MINIOS__
> +	reopen_log_pipe[0] = -1;
> +	reopen_log_pipe[1] = -1;
> +#else
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
>  	}
> +#endif
>  
>  	/* Setup the database */
>  	setup_structure();
> @@ -1916,6 +1935,7 @@ int main(int argc, char *argv[])
>  		fflush(stdout);
>  	}
>  
> +#ifndef __MINIOS__
>  	/* redirect to /dev/null now we're ready to accept connections */
>  	if (dofork) {
>  		int devnull = open("/dev/null", O_RDWR);
> @@ -1927,6 +1947,7 @@ int main(int argc, char *argv[])
>  		close(devnull);
>  		xprintf = trace;
>  	}
> +#endif

we could probably handle /dev/null in minios from sys.c


>  	signal(SIGHUP, trigger_reopen_log);
>  
> @@ -1936,8 +1957,10 @@ int main(int argc, char *argv[])
>  	/* Get ready to listen to the tools. */
>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>  
> +#ifndef __MINIOS__
>  	/* Tell the kernel we're up and running. */
>  	xenbus_notify_running();
> +#endif
>  
>  	/* Main loop. */
>  	for (;;) {
> @@ -1949,7 +1972,7 @@ int main(int argc, char *argv[])
>  			barf_perror("Select failed");
>  		}
>  
> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>  			char c;
>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>  				barf_perror("read failed");
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 661d955..435f76a 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
>  	}
>  
>  	if (domain->interface) {
> +#ifdef __MINIOS__
> +		unmap_interface(domain->interface);
> +#else
>  		if (domain->domid == 0)
>  			munmap(domain->interface, getpagesize());
>  		else
>  			unmap_interface(domain->interface);
> +#endif
>  	}

Argh. 
Why dom0 cannot be handled inside unmap_interface?


>  	fire_watches(NULL, "@releaseDomain", false);
> @@ -595,6 +599,12 @@ void restore_existing_connections(void)
>  {
>  }
>  
> +#ifdef __MINIOS__
> +static int dom0_init(void)
> +{
> +	return 0;
> +}
> +#else
>  static int dom0_init(void) 
>  { 
>  	evtchn_port_t port;
> @@ -618,6 +628,7 @@ static int dom0_init(void)
>  
>  	return 0; 
>  }
> +#endif
>  
>  void domain_init(void)
>  {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:14:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19: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 1Rq8IN-0003Je-96; Wed, 25 Jan 2012 19:14:11 +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 1Rq8IL-0003JS-Gt
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:14:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327518821!50245858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11972 invoked from network); 25 Jan 2012 19:13:41 -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;
	25 Jan 2012 19:13:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,569,1320624000"; d="scan'208";a="10290392"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 19:14: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; Wed, 25 Jan 2012 19:14:03 +0000
Date: Wed, 25 Jan 2012 19:14:43 +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: <1327502278-1790-19-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201251854530.3196@kaball-desktop>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327502278-1790-19-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 18/23] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  tools/xenstore/Makefile           |    9 ++++++++-
>  tools/xenstore/tdb.c              |    6 +++---
>  tools/xenstore/utils.h            |    2 ++
>  tools/xenstore/xenstored_core.c   |   29 ++++++++++++++++++++++++++---
>  tools/xenstore/xenstored_domain.c |   11 +++++++++++
>  5 files changed, 50 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 4facb62..be892fd 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -28,6 +28,10 @@ endif
>  
>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>  
> +ifdef CONFIG_STUBDOM
> +CFLAGS += -DNO_SOCKETS=1
> +endif
> +
>  .PHONY: all
>  all: $(ALL_TARGETS)
>  
> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
>  
>  CFLAGS += -DHAVE_DTRACE=1
>  endif
> - 
> +
>  xenstored: $(XENSTORED_OBJS)
>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
> +xenstored.a: $(XENSTORED_OBJS)
> +	$(AR) cr $@ $^
> +
>  $(CLIENTS): xenstore
>  	ln -f xenstore $@
>  
> diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
> index 3ecd3fc..cb66ea7 100644
> --- a/tools/xenstore/tdb.c
> +++ b/tools/xenstore/tdb.c
> @@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>  
>  		/* Iterate through chain */
>  		while( tlock->off) {
> -			tdb_off current;
> +			tdb_off mycurrent;
>  			if (rec_read(tdb, tlock->off, rec) == -1)
>  				goto fail;
>  
> @@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>  			}
>  
>  			/* Try to clean dead ones from old traverses */
> -			current = tlock->off;
> +			mycurrent = tlock->off;
>  			tlock->off = rec->next;
>  			if (!tdb->read_only && 
> -			    do_delete(tdb, current, rec) != 0)
> +			    do_delete(tdb, mycurrent, rec) != 0)
>  				goto fail;
>  		}
>  		tdb_unlock(tdb, tlock->hash, F_WRLCK);

Why are you renaming current to mycurrent?


> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
> index f378343..2effd17 100644
> --- a/tools/xenstore/utils.h
> +++ b/tools/xenstore/utils.h
> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>  	return streq(a + strlen(a) - strlen(b), b);
>  }
>  
> +#ifndef ARRAY_SIZE
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
>  
>  void barf(const char *fmt, ...) __attribute__((noreturn));
>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index c1ee932..7564edd 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -92,8 +92,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
>  
>  bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
>  {
> +#ifndef __MINIOS__
>  	if (rename(newname, xs_daemon_tdb()) != 0)
>  		return false;
> +#endif
>  	tdb_close(tdb_ctx);
>  	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
>  	return true;

Are you doing this because the database is not on file anymore, correct?
Maybe there is some room for introducing this concept more generally
because it could be useful on Linux too and it would avoid this and
other ifdef's.


> @@ -223,7 +225,6 @@ static void reopen_log(void)
>  	}
>  }
>  
> -
>  static bool write_messages(struct connection *conn)
>  {
>  	int ret;
> @@ -326,7 +327,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  		set_fd(sock, inset, &max);
>  	if (ro_sock != -1)
>  		set_fd(ro_sock, inset, &max);
> -	set_fd(reopen_log_pipe[0], inset, &max);
> +	if (reopen_log_pipe[0] != -1)
> +		set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1410,7 +1412,11 @@ static void accept_connection(int sock, bool canwrite)
>  }
>  #endif
>  
> +#ifdef __MINIOS__
> +#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
> +#else
>  #define TDB_FLAGS 0
> +#endif

See above

>  /* We create initial nodes manually. */
>  static void manual_node(const char *name, const char *child)
> @@ -1435,7 +1441,11 @@ static void setup_structure(void)
>  {
>  	char *tdbname;
>  	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
> +#ifdef __MINIOS__
> +	tdb_ctx = NULL;
> +#else
>  	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
> +#endif

ditto

>  	if (tdb_ctx) {
>  		/* XXX When we make xenstored able to restart, this will have
> @@ -1661,6 +1671,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
>  
>  
> +#ifndef __MINIOS__
>  static void write_pidfile(const char *pidfile)
>  {
>  	char buf[100];
> @@ -1707,6 +1718,7 @@ static void daemonize(void)
>  	/* Discard our parent's old-fashioned umask prejudices. */
>  	umask(0);
>  }
> +#endif
>  
>  #ifdef NO_SOCKETS
>  static void init_sockets(int **psock, int **pro_sock)
> @@ -1866,6 +1878,7 @@ int main(int argc, char *argv[])
>  
>  	reopen_log();
>  
> +#ifndef __MINIOS__
>  	/* make sure xenstored directory exists */
>  	if (mkdir(xs_daemon_rundir(), 0755)) {
>  		if (errno != EEXIST) {
> @@ -1887,6 +1900,7 @@ int main(int argc, char *argv[])
>  	}
>  	if (pidfile)
>  		write_pidfile(pidfile);
> +#endif

Maybe we could just have this fail gracefully: after all even on Linux
if the socket interface is not available everything should be able to
run correctly.


>  	/* Talloc leak reports go to stderr, which is closed if we fork. */
>  	if (!dofork)
> @@ -1897,9 +1911,14 @@ int main(int argc, char *argv[])
>  
>  	init_sockets(&sock, &ro_sock);
>  
> +#ifdef __MINIOS__
> +	reopen_log_pipe[0] = -1;
> +	reopen_log_pipe[1] = -1;
> +#else
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
>  	}
> +#endif
>  
>  	/* Setup the database */
>  	setup_structure();
> @@ -1916,6 +1935,7 @@ int main(int argc, char *argv[])
>  		fflush(stdout);
>  	}
>  
> +#ifndef __MINIOS__
>  	/* redirect to /dev/null now we're ready to accept connections */
>  	if (dofork) {
>  		int devnull = open("/dev/null", O_RDWR);
> @@ -1927,6 +1947,7 @@ int main(int argc, char *argv[])
>  		close(devnull);
>  		xprintf = trace;
>  	}
> +#endif

we could probably handle /dev/null in minios from sys.c


>  	signal(SIGHUP, trigger_reopen_log);
>  
> @@ -1936,8 +1957,10 @@ int main(int argc, char *argv[])
>  	/* Get ready to listen to the tools. */
>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>  
> +#ifndef __MINIOS__
>  	/* Tell the kernel we're up and running. */
>  	xenbus_notify_running();
> +#endif
>  
>  	/* Main loop. */
>  	for (;;) {
> @@ -1949,7 +1972,7 @@ int main(int argc, char *argv[])
>  			barf_perror("Select failed");
>  		}
>  
> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>  			char c;
>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>  				barf_perror("read failed");
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 661d955..435f76a 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
>  	}
>  
>  	if (domain->interface) {
> +#ifdef __MINIOS__
> +		unmap_interface(domain->interface);
> +#else
>  		if (domain->domid == 0)
>  			munmap(domain->interface, getpagesize());
>  		else
>  			unmap_interface(domain->interface);
> +#endif
>  	}

Argh. 
Why dom0 cannot be handled inside unmap_interface?


>  	fire_watches(NULL, "@releaseDomain", false);
> @@ -595,6 +599,12 @@ void restore_existing_connections(void)
>  {
>  }
>  
> +#ifdef __MINIOS__
> +static int dom0_init(void)
> +{
> +	return 0;
> +}
> +#else
>  static int dom0_init(void) 
>  { 
>  	evtchn_port_t port;
> @@ -618,6 +628,7 @@ static int dom0_init(void)
>  
>  	return 0; 
>  }
> +#endif
>  
>  void domain_init(void)
>  {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:20:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19: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 1Rq8OD-0003pe-4C; Wed, 25 Jan 2012 19:20:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq8OC-0003pM-EJ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:20:12 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327519205!4012588!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 607 invoked from network); 25 Jan 2012 19:20:05 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-2.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 19:20:05 -0000
Received: (qmail 17181 invoked from network); 25 Jan 2012 20:20:00 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 20:20:00 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 20:19:59 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
MIME-Version: 1.0
Message-Id: <201201252019.59693.pavel@netsafe.cz>
Subject: Re: [Xen-devel] GPLPV and 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 Wed 25. of January 2012 19:03:12 djmagee@mageenet.net wrote:
> James,
> 	At least one other person (Lta, included in this message) and I
> have had problems using passthrough pci devices and your GPLPV drivers
> at the same time.  My symptoms are that SMB connections are totally
> unreliable (however, downloading over http seems to work well enough).
> For example, if I start a video or audio file, playing from the network,
> it will play the first few seconds fine, then the connection drops out.
> I can confirm that the problems don't exist when not passing through any
> devices.
>
> 	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU
> with an ATI 4770, USB controller, and ICE1712 based pci sound card
> passed through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.
> 
> 	I guess the real question is, do you have any idea where we
> should start looking?

Hi,
I had similar problem. I have several Win7 virtual machines with passed VGA 
where we play games with friends.
Some games were not able to connect to LAN game when 0.11.0.308 were in place.
Then I've installed 0.11.0.322 mentioned in
http://old-list-archives.xen.org/archives/html/xen-devel/2011-09/msg01159.html
and everything runs just fine.
But they are not available to download anymore.
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:20:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19: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 1Rq8OD-0003pe-4C; Wed, 25 Jan 2012 19:20:13 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq8OC-0003pM-EJ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:20:12 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327519205!4012588!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 607 invoked from network); 25 Jan 2012 19:20:05 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-2.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 19:20:05 -0000
Received: (qmail 17181 invoked from network); 25 Jan 2012 20:20:00 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 20:20:00 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 20:19:59 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
MIME-Version: 1.0
Message-Id: <201201252019.59693.pavel@netsafe.cz>
Subject: Re: [Xen-devel] GPLPV and 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 Wed 25. of January 2012 19:03:12 djmagee@mageenet.net wrote:
> James,
> 	At least one other person (Lta, included in this message) and I
> have had problems using passthrough pci devices and your GPLPV drivers
> at the same time.  My symptoms are that SMB connections are totally
> unreliable (however, downloading over http seems to work well enough).
> For example, if I start a video or audio file, playing from the network,
> it will play the first few seconds fine, then the connection drops out.
> I can confirm that the problems don't exist when not passing through any
> devices.
>
> 	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU
> with an ATI 4770, USB controller, and ICE1712 based pci sound card
> passed through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.
> 
> 	I guess the real question is, do you have any idea where we
> should start looking?

Hi,
I had similar problem. I have several Win7 virtual machines with passed VGA 
where we play games with friends.
Some games were not able to connect to LAN game when 0.11.0.308 were in place.
Then I've installed 0.11.0.322 mentioned in
http://old-list-archives.xen.org/archives/html/xen-devel/2011-09/msg01159.html
and everything runs just fine.
But they are not available to download anymore.
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:20:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19: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 1Rq8Ob-0003ra-Hd; Wed, 25 Jan 2012 19:20:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rq8Oa-0003qu-1G
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:20:36 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327519229!12464297!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15698 invoked from network); 25 Jan 2012 19:20:29 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-14.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 19:20:29 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0PJKSNV012448;
	Wed, 25 Jan 2012 14:20:28 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0PJKRsd017886;
	Wed, 25 Jan 2012 14:20:27 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012514202613855 ; Wed, 25 Jan 2012 14:20:26 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <4F2043A4.7080708@suse.com>
Date: Wed, 25 Jan 2012 14:20:27 -0500
Message-Id: <BC223C0E-DEE4-406A-81C1-0401B6A02F4D@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>	<1327511781.24561.354.camel@zakaz.uk.xensource.com>	<4F203CCC.50705@suse.com>
	<9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
	<4F2043A4.7080708@suse.com>
To: Jim Fehlig <jfehlig@suse.com>
X-Mailer: Apple Mail (2.1084)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, that's what I though from looking at the patch, but I am completely ignorant of the tools part of codebase.

Should I report this as a separate problem? We (NRL) really like xl and want to use it. What sort of debug dumps should I make?

Sincerely,

John
----


On Jan 25, 2012, at 1:02 PM, Jim Fehlig wrote:

> John McDermott CIV wrote:
>> So I should try this patch and report back if it works?
>> 
> 
> No, that patch causes the issue reported by Erin :-).  In Erin's case,
> the vif was not connected to the bridge.  In the problem you described,
> the vif was connected to the bridge but didn't work for other reasons.
> 
> Regards,
> Jim
> 
>> On Jan 25, 2012, at 12:33 PM, Jim Fehlig wrote:
>> 
>> 
>>> Ian Campbell wrote:
>>> 
>>>> Please don't top post.
>>>> 
>>>> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>>>> 
>>>> 
>>>>> This problem also happens in Fedora 16. Should we be making bugzilla
>>>>> entries for problems with Xen?
>>>>> 
>>>>> 
>>>> There is more than one reason why networking may not work for you so
>>>> there isn't necessarily any reason (yet) to think you are seeing the
>>>> same issue.
>>>> 
>>>> 
>>> Yes, different issue.  I'd be really surprised if Fedora had this patch
>>> 
>>> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
>>> 
>>> Regards,
>>> Jim
>>> 
>> 
>> ----
>> What is the formal meaning of the one-line program
>> #include "/dev/tty"
>> 
>> J.P. McDermott			building 12
>> Code 5542			john.mcdermott@nrl.navy.mil
>> Naval Research Laboratory	voice: +1 202.404.8301
>> Washington, DC 20375, US	fax:   +1 202.404.7942
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 
>> 

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:20:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19: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 1Rq8Ob-0003ra-Hd; Wed, 25 Jan 2012 19:20:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <john.mcdermott@nrl.navy.mil>) id 1Rq8Oa-0003qu-1G
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:20:36 +0000
X-Env-Sender: john.mcdermott@nrl.navy.mil
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327519229!12464297!1
X-Originating-IP: [132.250.196.100]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15698 invoked from network); 25 Jan 2012 19:20:29 -0000
Received: from fw5540.nrl.navy.mil (HELO fw5540.nrl.navy.mil) (132.250.196.100)
	by server-14.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 19:20:29 -0000
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11])
	by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0PJKSNV012448;
	Wed, 25 Jan 2012 14:20:28 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11])
	by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id q0PJKRsd017886;
	Wed, 25 Jan 2012 14:20:27 -0500 (EST)
Received: from gir.fw5540.net ([10.0.2.110])
	by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id
	M2012012514202613855 ; Wed, 25 Jan 2012 14:20:26 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
From: John McDermott CIV <john.mcdermott@nrl.navy.mil>
In-Reply-To: <4F2043A4.7080708@suse.com>
Date: Wed, 25 Jan 2012 14:20:27 -0500
Message-Id: <BC223C0E-DEE4-406A-81C1-0401B6A02F4D@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>	<1327511781.24561.354.camel@zakaz.uk.xensource.com>	<4F203CCC.50705@suse.com>
	<9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
	<4F2043A4.7080708@suse.com>
To: Jim Fehlig <jfehlig@suse.com>
X-Mailer: Apple Mail (2.1084)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
	can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, that's what I though from looking at the patch, but I am completely ignorant of the tools part of codebase.

Should I report this as a separate problem? We (NRL) really like xl and want to use it. What sort of debug dumps should I make?

Sincerely,

John
----


On Jan 25, 2012, at 1:02 PM, Jim Fehlig wrote:

> John McDermott CIV wrote:
>> So I should try this patch and report back if it works?
>> 
> 
> No, that patch causes the issue reported by Erin :-).  In Erin's case,
> the vif was not connected to the bridge.  In the problem you described,
> the vif was connected to the bridge but didn't work for other reasons.
> 
> Regards,
> Jim
> 
>> On Jan 25, 2012, at 12:33 PM, Jim Fehlig wrote:
>> 
>> 
>>> Ian Campbell wrote:
>>> 
>>>> Please don't top post.
>>>> 
>>>> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>>>> 
>>>> 
>>>>> This problem also happens in Fedora 16. Should we be making bugzilla
>>>>> entries for problems with Xen?
>>>>> 
>>>>> 
>>>> There is more than one reason why networking may not work for you so
>>>> there isn't necessarily any reason (yet) to think you are seeing the
>>>> same issue.
>>>> 
>>>> 
>>> Yes, different issue.  I'd be really surprised if Fedora had this patch
>>> 
>>> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
>>> 
>>> Regards,
>>> Jim
>>> 
>> 
>> ----
>> What is the formal meaning of the one-line program
>> #include "/dev/tty"
>> 
>> J.P. McDermott			building 12
>> Code 5542			john.mcdermott@nrl.navy.mil
>> Naval Research Laboratory	voice: +1 202.404.8301
>> Washington, DC 20375, US	fax:   +1 202.404.7942
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>> 
>> 

----
What is the formal meaning of the one-line program
#include "/dev/tty"

J.P. McDermott			building 12
Code 5542			john.mcdermott@nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, US	fax:   +1 202.404.7942











_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:29:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq8X0-0004Ax-Hq; Wed, 25 Jan 2012 19:29:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq8Wz-0004As-20
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:29:17 +0000
Received: from [85.158.138.51:39116] by server-1.bemta-3.messagelabs.com id
	3C/6B-09565-C08502F4; Wed, 25 Jan 2012 19:29:16 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327519755!10642129!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15697 invoked from network); 25 Jan 2012 19:29:15 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-8.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 19:29:15 -0000
Received: (qmail 17878 invoked from network); 25 Jan 2012 20:29:14 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 20:29:14 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 20:29:12 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327510331.2452.21.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201252029.12936.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> Also, i believe you said the card you're trying to pass through is not
> the primary card in your host system.  If that's the case, don't use
> gfx_passthru or expect to get the video bios working.  The 'primary'
> video adapter owns certain io ports and memory areas that are consitent
> from machine to machine.  Also, the system will copy the vbios from the
> card to a location in memory (0xc0000) so it can execute at boot time.
> 
> Xen's gfx_passthru code depends on all of these factors.  As the code
> stands, if you use gfx_passthru on a secondary card, it will still copy
> the vbios from the primary card (as it simply reads memory from
> 0xc0000), and directly map io ports and low memory areas to those used
> by the primary card in the host system.  In this case the guest will
> almost certainly never get past executing ROMBIOS, and the host may or
> may not lock up or experience 'issues'.

This will do the trick with secondary card (replace path to VGA BIOS):

--- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c 2012-01-25 
20:26:37.927654890 +0100
+++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c 
2011-07-30 13:57:57.347396095 +0200
@@ -487,10 +487,10 @@
 {
     int fd;
     uint32_t bios_size = 0;
-    uint32_t start = 0;
+    uint32_t start = 0xC0000;
     uint16_t magic = 0;
 
-    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin", O_RDONLY)) < 
0 )
+    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
     {
         PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
         return 0;
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:29:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19:29:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq8X0-0004Ax-Hq; Wed, 25 Jan 2012 19:29:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq8Wz-0004As-20
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:29:17 +0000
Received: from [85.158.138.51:39116] by server-1.bemta-3.messagelabs.com id
	3C/6B-09565-C08502F4; Wed, 25 Jan 2012 19:29:16 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327519755!10642129!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15697 invoked from network); 25 Jan 2012 19:29:15 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-8.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 19:29:15 -0000
Received: (qmail 17878 invoked from network); 25 Jan 2012 20:29:14 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 20:29:14 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 20:29:12 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327510331.2452.21.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201252029.12936.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> Also, i believe you said the card you're trying to pass through is not
> the primary card in your host system.  If that's the case, don't use
> gfx_passthru or expect to get the video bios working.  The 'primary'
> video adapter owns certain io ports and memory areas that are consitent
> from machine to machine.  Also, the system will copy the vbios from the
> card to a location in memory (0xc0000) so it can execute at boot time.
> 
> Xen's gfx_passthru code depends on all of these factors.  As the code
> stands, if you use gfx_passthru on a secondary card, it will still copy
> the vbios from the primary card (as it simply reads memory from
> 0xc0000), and directly map io ports and low memory areas to those used
> by the primary card in the host system.  In this case the guest will
> almost certainly never get past executing ROMBIOS, and the host may or
> may not lock up or experience 'issues'.

This will do the trick with secondary card (replace path to VGA BIOS):

--- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c 2012-01-25 
20:26:37.927654890 +0100
+++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c 
2011-07-30 13:57:57.347396095 +0200
@@ -487,10 +487,10 @@
 {
     int fd;
     uint32_t bios_size = 0;
-    uint32_t start = 0;
+    uint32_t start = 0xC0000;
     uint16_t magic = 0;
 
-    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin", O_RDONLY)) < 
0 )
+    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
     {
         PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
         return 0;
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq8kN-0004Lu-U6; Wed, 25 Jan 2012 19:43:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1Rq8kL-0004Ll-Hz
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:43:05 +0000
Received: from [85.158.138.51:16809] by server-2.bemta-3.messagelabs.com id
	96/10-24515-84B502F4; Wed, 25 Jan 2012 19:43:04 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327520582!6451867!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25240 invoked from network); 25 Jan 2012 19:43:03 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 19:43:03 -0000
Received: by iaeh11 with SMTP id h11so33721275iae.30
	for <multiple recipients>; Wed, 25 Jan 2012 11:43:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=0RG5w8JSXR7XgOf00Tm8JWfeRxweIW3o4leaoZUzmv8=;
	b=dQvcFv+r0CvdUZCgVnwX3PmWDQt73P300AuzLZl6IjS4sIkE+IeeEyj/IvCnI7k8Qc
	Fo4u/SGHz64KnGsfDd5xAcjn46j1KW1t8j6Z32BG9W1aACNnsfpUBHtQSI8EXZoqvRKI
	Ew+a8fPqaSL/tlCeQ8rikP99sEeRMPB7mRynQ=
MIME-Version: 1.0
Received: by 10.42.246.71 with SMTP id lx7mr15928023icb.54.1327520581712; Wed,
	25 Jan 2012 11:43:01 -0800 (PST)
Received: by 10.231.8.37 with HTTP; Wed, 25 Jan 2012 11:43:01 -0800 (PST)
In-Reply-To: <1327510462.24561.351.camel@zakaz.uk.xensource.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510462.24561.351.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 20:43:01 +0100
Message-ID: <CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Tobias Geiger <tobias.geiger@vido.info>, Doug Magee <djmagee@mageenet.net>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Likarpenkov Alexander <al@ohosting.org.ua>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGkgSWFuIGFuZCBhbGwsCgoyMDEyLzEvMjUgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0
cml4LmNvbT46Cj4gT24gV2VkLCAyMDEyLTAxLTI1IGF0IDA4OjI2ICswMDAwLCBMaWthcnBlbmtv
diBBbGV4YW5kZXIgd3JvdGU6Cj4+IPrE0sHX09TX1crUxSEKPj4KPj4g988g19TP0s7JyywgxNfB
xMPB1Ngg3sXU18XS1M/HzyDRztfB0tEgMjAxMiDHz8TBLCDXIDIwOjQxOjM4IPfZINDJ08HMyToK
Pj4gmkRNPiBJIHVzZSB0aGUgeGwgdG9vbHN0YWNrLCBub3QgeG0uIJpJIGRvbid0IHRoaW5rIHht
IGlzIGJlaW5nIGFjdGl2ZWx5Cj4+IJpETT4gbWFpbnRhaW5lZCwgYXQgbGVhc3Qgbm90IGZvciBj
dXJyZW50IHJlbGVhc2VzLgo+Pgo+PiBZb3UgY2FuIGluIGEgbnV0c2hlbGwgd2hhdCBiZXR0ZXIg
eGwgeG0/Cj4KPiB4bSAoYW5kIHRoZSB1bmRlcmx5aW5nIHhlbmQgZGFlbW9uKSBoYXZlIGJlZW4g
ZWZmZWN0aXZlbHkgdW5tYWludGFpbmVkCj4gc2luY2UgWGVuIDMuNCBvciBwZXJoYXBzIGV2ZW4g
ZWFybGllciAod2UgdGFrZSBiYW5kLWFpZHMgYW5kIG9idmlvdXMKPiBmaXh1cHMgYnV0IG5vIHBy
b3BlciBtYWludGVuYW5jZSBoYXMgYmVlbiBvY2N1cnJpbmcpLgoKdGhhdHMgbm90IGFuIGFkdmFu
dGFnZSBvZiB4bCBpbWhvLgp4bSAvIHhlbmQgYmVpbmcgYW4gdW5zdGFibGUgbWVzcyBhbmQgeGwg
YmVpbmcgYmxhemluZ2x5IGZhc3QgaXMgb25lLgoKPiBJbiB0aGUgb3BpbmlvbiBvZiB0aGUgY29y
ZSBkZXZlbG9wZXJzIHhlbmQgaXMgdW5tYWludGFpbmFibGUgYW5kIHNvIHdlCj4gaGF2ZSBjaG9z
ZW4gdG8gZm9jdXMgb3VyIGVmZm9ydHMgb24gbGlieGwgKGEgbGlicmFyeSBkZXNpZ25lZCB0byBw
cm92aWRlCj4gYSBjb21tb24gImJvdHRvbSB0aGlyZCIgZm9yIGFueSBYZW4gdG9vbHN0YWNrKSBh
bmQgdGhlIHhsIHRvb2xzdGFjayB0aGF0Cj4gaXMgYnVpbHQgdXNpbmcgaXQuIGxpYnhsIGlzIGFs
c28gc3VwcG9ydGVkIGJ5IGxpYnZpcnQgYW5kIHRoZXJlIGFyZQo+IHBsYW5zIGZvciB4YXBpICh0
aGUgWENQIHRvb2xzdGFjaykgdG8gdXNlIGl0IGFzIHdlbGwuCgp0aGlzIGlzIGFub3RoZXIgcGll
Y2Ugb2YgdW4tbWFpbnRhaW5lZC1uZXNzPwpsaWJ2aXJ0ICsgeGVuZCBqdXN0IHdlbnQgYXdheSBi
ZWNhdXNlIG5vYm9keSBldmVuIGNvbXBsYWluZWQgd2hlbgpsaWJ2aXJ0IHN1ZGRlbmx5IGRlZmF1
bHRlZCB0byBub3QgYnVpbGQgeGVuIHN1cHBvcnQuIE9rLCBwcm9iYWJseQpiZWNhdXNlIG1vc3Qg
WGVuIHVzZXJzIGRvbid0IG5lZWQgYSBndWkgdG9vbCB0byBzdGFydCB0aGVpciBWTXMgOikKCj4g
VGhpcyB3YXMgYW5ub3VuY2VkIGluIHRoZSBYZW4gNC4xIHJlbGVhc2Ugbm90ZXNbMV0gYW5kIHRo
ZSB1cGdyYWRlCj4gZ3VpZGVbMl0uIEluIFhlbiA0LjIgd2UgaGF2ZSBlbmRlZCB1cCBmb3JtYWxs
eSBkZXByZWNhdGluZyB4ZW5kIHJhdGhlcgo+IHRoYW4gcmVtb3ZpbmcgaXQgYnV0IHlvdSBzaG91
bGQgZXhwZWN0IHRoYXQgeGVuZCB3aWxsIGJlIHJlbW92ZWQgaW4gYQo+IGZ1dHVyZSByZWxlYXNl
IG9mIFhlbiBhbmQgYmVnaW4gcGxhbm5pbmcgeW91ciB0cmFuc2l0aW9uIHRvIHhsIChvciBvbmUK
PiBvZiB0aGUgb3RoZXIgYWx0ZXJuYXRpdmUgdG9vbHN0YWNrcyksIHRlc3RpbmcgdGhlIGZlYXR1
cmVzIHdoaWNoIG1hdHRlcgo+IHRvIHlvdSBhbmQgcmVwb3J0aW5nIGJ1Z3Mvc3VibWl0dGluZyBw
YXRjaGVzIGFzIGFwcHJvcHJpYXRlLgoKSSB0aGluayBpdCB3b3VsZCBiZSBhIG5pY2UgbW92ZSBp
ZiB0aGlzIHdhc24ndCBqdXN0IGxlZnQgdG8gdXMgdXNlcnMsCmVzcGVjaWFsbHkgc2luY2UgaXQg
aXMgYSBwcm9jZXNzIG9mIHN1ZGRlbmx5IGZpbmRpbmcgbWlzc2luZyBwYXJ0cyBvcgpsYXJnZSBj
aGFuZ2VzIGluIGZ1bmN0aW9uYWxpdHkgaW4gc29tZXRoaW5nIGxpa2UgYW4gZWFzdGVyIGVnZyBo
dW50LgoKSG93IGFib3V0IGlmIHdlIGFzc2VtYmxlIGEgbGlzdCBvZiBYZW4gZmVhdHVyZXMgaW4g
eG0veGVuZCBhbmQgdGhvc2UKdGhhdCB5b3UgaGF2ZSBpbXBsZW1lbnRlZCBpbiB4bC4gUmlnaHQg
bm93IGl0J3MganVzdCBndWVzc3dvcmsgYW5kIGEKbG90IGRvdWJsZSBlZmZvcnQgc2luY2Ugb25l
IGRvZXNuJ3QganVzdCBoYXZlIHRvIHRyYWNrIHdoaWNoIHBhcnRzIGFyZQpnb25lLCBidXQgd2Ug
ZXZlbiBoYXZlIHRvIGNvbnN0YW50bHkgcmVhZCBhbGwgdGhyZWFkcyBvbiB0aGUgbGlzdHMgdG8K
ZmluZCBvdXQgaWYgYSBmZWF0dXJlIGlzIHN1ZGRlbmx5IGNvbWluZyBiYWNrIG9yIGJlaW5nIGRl
cHJlY2F0ZWQuCgppLmUuIHRha2Ugc29tZXRoaW5nIGxpa2UgUmVtdXMgdGhhdCBoYWQgb2ZmaWNp
YWxseSBiZWNvbWUgYSBwYXJ0IG9mClhlbiBzb21lIHRpbWUgYmFjayBidXQgaXNuJ3QgcG9zc2li
bGUgdG8gdXNlIHdpdGggUFYgZG9tVXMgd2l0aCBhbnkKcmVhc29uYWJsZSBhbW91bnQgb2YgZWZm
b3J0LiBBbmQgbm90IGJ5IGZvcm1hbCBkZWNpc2lvbiwgYWZ0ZXIgYQoiaGVhZHMgdXAiIG1haWws
IGJ1dCBqdXN0IGJ5IGNoYW5jZS4gQSBmZXcgbW9udGhzIEkgd2FzIHN0aWxsIHRoaW5raW5nCkkg
d291bGQgYmUgYWJsZSB0byB1c2UgaXQgaW4gYSBob3N0aW5nIHByb2R1Y3QgYnV0ICJ3aG9vcHMi
IG5vdAp3b3JraW5nIGFueW1vcmUuCgpCYWNrIHRvIHhsOgpQcm9iYWJseSBub29uZSByZWFsbHkg
b2JqZWN0cyByZW1vdmluZyB4bSBieSBub3cgc2luY2UgaXQncyBub3QgcmVhbGx5Cndvcmtpbmcg
YW55bW9yZSBvbmNlIHRoZSBzeXN0ZW0gaGFzIHhsIHN1cHBvcnQgYW5kIHRoZSB0d28gYXJlIG5v
dApjb21wYXRpYmxlLiBJdCBoYXMgdG8gYmUgaW4gZXZlcnlvbmVzIGludGVyZXN0IHRoYXQgdGhl
cmUgaXMgbm8KdW5uZWVkZWQgY29kZSB0byBtYWludGFpbiBhbmQgdGhhdCB0aGUgY29yZSBkZXZz
IExJS0UgdGhhdCBjb2RlIGFuZAp0aGF0IHBlb3BsZSBjYW4gcmVseSBvbiBpdCBiZWluZyBtYWlu
dGFpbmVkIGZvciB0aGUgeWVhcnMgdG8gY29tZS4KSXQgZG9lc24ndCBtYXR0ZXIgaWYgd2UgdHlw
ZSAneGwnIG9yICd4bScsIGl0IGhhcyB0byAqd29yayogOikKCkJ1dCBtYXliZSB3ZSBjYW4gaGF2
ZSBhIHNvbWV3aGF0IHJlbGlhYmxlIHJvYWRtYXAgd2hlcmUgb25lIGNhbiBzZWUgeG0Kd2lsbCBi
ZSBraWNrZWQgaW4gNC40ICphbmQqIHdlJ3JlIHBsYW5uaW5nIHRvIGhhdmUgdGhlIGZvbGxvd2lu
ZyAxMjM0CmZlYXR1cmVzIHN1cHBvcnRlZCBieSB0aGVuLgpUaGF0IHdheSBpbnRlcmVzdGVkIHBh
cnRpZXMgaGF2ZSBhIGNoYW5jZSB0byBwdXQgcmVzc291cmNlcyBpbnRvCmdldHRpbmcgbWlzc2lu
ZyBmZWF0dXJlcyAiYmFjayBpbiIgYW5kIG90aGVyIHByb2plY3RzIGtub3cgaG93IG11Y2gKdGlt
ZSB0aGV5IGhhdmUgdG8gY2xlYW4gdXAgdGhlaXIgY29kZS4gSS5lLiBjb2JibGVyL2tvYW4gaXMg
c3VkZGVubHkKYnJva2VuIGFmdGVyIDQgeWVhcnMgYW5kIHBlb3BsZSBjYW4ndCBpbnN0YWxsIGRv
bVVzIGFueW1vcmUuIDopCgpHcmVldGluZ3MsCkZsb3JpYW4KCnAucy46IEkgYW0gYXdhcmUgSSB3
aWxsIGhhdmUgdG8gbWFrZSB1cCBmb3IgdGhpcyBtYWlsIGluIGJlZXIgb25jZQp0aGVyZSBpcyBh
biBvcHBvcnR1bml0eS4KCi0tIAp0aGUgcHVycG9zZSBvZiBsaWJ2aXJ0IGlzIHRvIHByb3ZpZGUg
YW4gYWJzdHJhY3Rpb24gbGF5ZXIgaGlkaW5nIGFsbAp4ZW4gZmVhdHVyZXMgYWRkZWQgc2luY2Ug
MjAwNiB1bnRpbCB0aGV5IHdlcmUgZmluYWxseSB1bmRlcnN0b29kIGFuZApjb3BpZWQgYnkgdGhl
IGt2bSBkZXZzLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:43:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19:43:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq8kN-0004Lu-U6; Wed, 25 Jan 2012 19:43:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>) id 1Rq8kL-0004Ll-Hz
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:43:05 +0000
Received: from [85.158.138.51:16809] by server-2.bemta-3.messagelabs.com id
	96/10-24515-84B502F4; Wed, 25 Jan 2012 19:43:04 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327520582!6451867!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25240 invoked from network); 25 Jan 2012 19:43:03 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-7.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	25 Jan 2012 19:43:03 -0000
Received: by iaeh11 with SMTP id h11so33721275iae.30
	for <multiple recipients>; Wed, 25 Jan 2012 11:43:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=0RG5w8JSXR7XgOf00Tm8JWfeRxweIW3o4leaoZUzmv8=;
	b=dQvcFv+r0CvdUZCgVnwX3PmWDQt73P300AuzLZl6IjS4sIkE+IeeEyj/IvCnI7k8Qc
	Fo4u/SGHz64KnGsfDd5xAcjn46j1KW1t8j6Z32BG9W1aACNnsfpUBHtQSI8EXZoqvRKI
	Ew+a8fPqaSL/tlCeQ8rikP99sEeRMPB7mRynQ=
MIME-Version: 1.0
Received: by 10.42.246.71 with SMTP id lx7mr15928023icb.54.1327520581712; Wed,
	25 Jan 2012 11:43:01 -0800 (PST)
Received: by 10.231.8.37 with HTTP; Wed, 25 Jan 2012 11:43:01 -0800 (PST)
In-Reply-To: <1327510462.24561.351.camel@zakaz.uk.xensource.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510462.24561.351.camel@zakaz.uk.xensource.com>
Date: Wed, 25 Jan 2012 20:43:01 +0100
Message-ID: <CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Tobias Geiger <tobias.geiger@vido.info>, Doug Magee <djmagee@mageenet.net>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Likarpenkov Alexander <al@ohosting.org.ua>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGkgSWFuIGFuZCBhbGwsCgoyMDEyLzEvMjUgSWFuIENhbXBiZWxsIDxJYW4uQ2FtcGJlbGxAY2l0
cml4LmNvbT46Cj4gT24gV2VkLCAyMDEyLTAxLTI1IGF0IDA4OjI2ICswMDAwLCBMaWthcnBlbmtv
diBBbGV4YW5kZXIgd3JvdGU6Cj4+IPrE0sHX09TX1crUxSEKPj4KPj4g988g19TP0s7JyywgxNfB
xMPB1Ngg3sXU18XS1M/HzyDRztfB0tEgMjAxMiDHz8TBLCDXIDIwOjQxOjM4IPfZINDJ08HMyToK
Pj4gmkRNPiBJIHVzZSB0aGUgeGwgdG9vbHN0YWNrLCBub3QgeG0uIJpJIGRvbid0IHRoaW5rIHht
IGlzIGJlaW5nIGFjdGl2ZWx5Cj4+IJpETT4gbWFpbnRhaW5lZCwgYXQgbGVhc3Qgbm90IGZvciBj
dXJyZW50IHJlbGVhc2VzLgo+Pgo+PiBZb3UgY2FuIGluIGEgbnV0c2hlbGwgd2hhdCBiZXR0ZXIg
eGwgeG0/Cj4KPiB4bSAoYW5kIHRoZSB1bmRlcmx5aW5nIHhlbmQgZGFlbW9uKSBoYXZlIGJlZW4g
ZWZmZWN0aXZlbHkgdW5tYWludGFpbmVkCj4gc2luY2UgWGVuIDMuNCBvciBwZXJoYXBzIGV2ZW4g
ZWFybGllciAod2UgdGFrZSBiYW5kLWFpZHMgYW5kIG9idmlvdXMKPiBmaXh1cHMgYnV0IG5vIHBy
b3BlciBtYWludGVuYW5jZSBoYXMgYmVlbiBvY2N1cnJpbmcpLgoKdGhhdHMgbm90IGFuIGFkdmFu
dGFnZSBvZiB4bCBpbWhvLgp4bSAvIHhlbmQgYmVpbmcgYW4gdW5zdGFibGUgbWVzcyBhbmQgeGwg
YmVpbmcgYmxhemluZ2x5IGZhc3QgaXMgb25lLgoKPiBJbiB0aGUgb3BpbmlvbiBvZiB0aGUgY29y
ZSBkZXZlbG9wZXJzIHhlbmQgaXMgdW5tYWludGFpbmFibGUgYW5kIHNvIHdlCj4gaGF2ZSBjaG9z
ZW4gdG8gZm9jdXMgb3VyIGVmZm9ydHMgb24gbGlieGwgKGEgbGlicmFyeSBkZXNpZ25lZCB0byBw
cm92aWRlCj4gYSBjb21tb24gImJvdHRvbSB0aGlyZCIgZm9yIGFueSBYZW4gdG9vbHN0YWNrKSBh
bmQgdGhlIHhsIHRvb2xzdGFjayB0aGF0Cj4gaXMgYnVpbHQgdXNpbmcgaXQuIGxpYnhsIGlzIGFs
c28gc3VwcG9ydGVkIGJ5IGxpYnZpcnQgYW5kIHRoZXJlIGFyZQo+IHBsYW5zIGZvciB4YXBpICh0
aGUgWENQIHRvb2xzdGFjaykgdG8gdXNlIGl0IGFzIHdlbGwuCgp0aGlzIGlzIGFub3RoZXIgcGll
Y2Ugb2YgdW4tbWFpbnRhaW5lZC1uZXNzPwpsaWJ2aXJ0ICsgeGVuZCBqdXN0IHdlbnQgYXdheSBi
ZWNhdXNlIG5vYm9keSBldmVuIGNvbXBsYWluZWQgd2hlbgpsaWJ2aXJ0IHN1ZGRlbmx5IGRlZmF1
bHRlZCB0byBub3QgYnVpbGQgeGVuIHN1cHBvcnQuIE9rLCBwcm9iYWJseQpiZWNhdXNlIG1vc3Qg
WGVuIHVzZXJzIGRvbid0IG5lZWQgYSBndWkgdG9vbCB0byBzdGFydCB0aGVpciBWTXMgOikKCj4g
VGhpcyB3YXMgYW5ub3VuY2VkIGluIHRoZSBYZW4gNC4xIHJlbGVhc2Ugbm90ZXNbMV0gYW5kIHRo
ZSB1cGdyYWRlCj4gZ3VpZGVbMl0uIEluIFhlbiA0LjIgd2UgaGF2ZSBlbmRlZCB1cCBmb3JtYWxs
eSBkZXByZWNhdGluZyB4ZW5kIHJhdGhlcgo+IHRoYW4gcmVtb3ZpbmcgaXQgYnV0IHlvdSBzaG91
bGQgZXhwZWN0IHRoYXQgeGVuZCB3aWxsIGJlIHJlbW92ZWQgaW4gYQo+IGZ1dHVyZSByZWxlYXNl
IG9mIFhlbiBhbmQgYmVnaW4gcGxhbm5pbmcgeW91ciB0cmFuc2l0aW9uIHRvIHhsIChvciBvbmUK
PiBvZiB0aGUgb3RoZXIgYWx0ZXJuYXRpdmUgdG9vbHN0YWNrcyksIHRlc3RpbmcgdGhlIGZlYXR1
cmVzIHdoaWNoIG1hdHRlcgo+IHRvIHlvdSBhbmQgcmVwb3J0aW5nIGJ1Z3Mvc3VibWl0dGluZyBw
YXRjaGVzIGFzIGFwcHJvcHJpYXRlLgoKSSB0aGluayBpdCB3b3VsZCBiZSBhIG5pY2UgbW92ZSBp
ZiB0aGlzIHdhc24ndCBqdXN0IGxlZnQgdG8gdXMgdXNlcnMsCmVzcGVjaWFsbHkgc2luY2UgaXQg
aXMgYSBwcm9jZXNzIG9mIHN1ZGRlbmx5IGZpbmRpbmcgbWlzc2luZyBwYXJ0cyBvcgpsYXJnZSBj
aGFuZ2VzIGluIGZ1bmN0aW9uYWxpdHkgaW4gc29tZXRoaW5nIGxpa2UgYW4gZWFzdGVyIGVnZyBo
dW50LgoKSG93IGFib3V0IGlmIHdlIGFzc2VtYmxlIGEgbGlzdCBvZiBYZW4gZmVhdHVyZXMgaW4g
eG0veGVuZCBhbmQgdGhvc2UKdGhhdCB5b3UgaGF2ZSBpbXBsZW1lbnRlZCBpbiB4bC4gUmlnaHQg
bm93IGl0J3MganVzdCBndWVzc3dvcmsgYW5kIGEKbG90IGRvdWJsZSBlZmZvcnQgc2luY2Ugb25l
IGRvZXNuJ3QganVzdCBoYXZlIHRvIHRyYWNrIHdoaWNoIHBhcnRzIGFyZQpnb25lLCBidXQgd2Ug
ZXZlbiBoYXZlIHRvIGNvbnN0YW50bHkgcmVhZCBhbGwgdGhyZWFkcyBvbiB0aGUgbGlzdHMgdG8K
ZmluZCBvdXQgaWYgYSBmZWF0dXJlIGlzIHN1ZGRlbmx5IGNvbWluZyBiYWNrIG9yIGJlaW5nIGRl
cHJlY2F0ZWQuCgppLmUuIHRha2Ugc29tZXRoaW5nIGxpa2UgUmVtdXMgdGhhdCBoYWQgb2ZmaWNp
YWxseSBiZWNvbWUgYSBwYXJ0IG9mClhlbiBzb21lIHRpbWUgYmFjayBidXQgaXNuJ3QgcG9zc2li
bGUgdG8gdXNlIHdpdGggUFYgZG9tVXMgd2l0aCBhbnkKcmVhc29uYWJsZSBhbW91bnQgb2YgZWZm
b3J0LiBBbmQgbm90IGJ5IGZvcm1hbCBkZWNpc2lvbiwgYWZ0ZXIgYQoiaGVhZHMgdXAiIG1haWws
IGJ1dCBqdXN0IGJ5IGNoYW5jZS4gQSBmZXcgbW9udGhzIEkgd2FzIHN0aWxsIHRoaW5raW5nCkkg
d291bGQgYmUgYWJsZSB0byB1c2UgaXQgaW4gYSBob3N0aW5nIHByb2R1Y3QgYnV0ICJ3aG9vcHMi
IG5vdAp3b3JraW5nIGFueW1vcmUuCgpCYWNrIHRvIHhsOgpQcm9iYWJseSBub29uZSByZWFsbHkg
b2JqZWN0cyByZW1vdmluZyB4bSBieSBub3cgc2luY2UgaXQncyBub3QgcmVhbGx5Cndvcmtpbmcg
YW55bW9yZSBvbmNlIHRoZSBzeXN0ZW0gaGFzIHhsIHN1cHBvcnQgYW5kIHRoZSB0d28gYXJlIG5v
dApjb21wYXRpYmxlLiBJdCBoYXMgdG8gYmUgaW4gZXZlcnlvbmVzIGludGVyZXN0IHRoYXQgdGhl
cmUgaXMgbm8KdW5uZWVkZWQgY29kZSB0byBtYWludGFpbiBhbmQgdGhhdCB0aGUgY29yZSBkZXZz
IExJS0UgdGhhdCBjb2RlIGFuZAp0aGF0IHBlb3BsZSBjYW4gcmVseSBvbiBpdCBiZWluZyBtYWlu
dGFpbmVkIGZvciB0aGUgeWVhcnMgdG8gY29tZS4KSXQgZG9lc24ndCBtYXR0ZXIgaWYgd2UgdHlw
ZSAneGwnIG9yICd4bScsIGl0IGhhcyB0byAqd29yayogOikKCkJ1dCBtYXliZSB3ZSBjYW4gaGF2
ZSBhIHNvbWV3aGF0IHJlbGlhYmxlIHJvYWRtYXAgd2hlcmUgb25lIGNhbiBzZWUgeG0Kd2lsbCBi
ZSBraWNrZWQgaW4gNC40ICphbmQqIHdlJ3JlIHBsYW5uaW5nIHRvIGhhdmUgdGhlIGZvbGxvd2lu
ZyAxMjM0CmZlYXR1cmVzIHN1cHBvcnRlZCBieSB0aGVuLgpUaGF0IHdheSBpbnRlcmVzdGVkIHBh
cnRpZXMgaGF2ZSBhIGNoYW5jZSB0byBwdXQgcmVzc291cmNlcyBpbnRvCmdldHRpbmcgbWlzc2lu
ZyBmZWF0dXJlcyAiYmFjayBpbiIgYW5kIG90aGVyIHByb2plY3RzIGtub3cgaG93IG11Y2gKdGlt
ZSB0aGV5IGhhdmUgdG8gY2xlYW4gdXAgdGhlaXIgY29kZS4gSS5lLiBjb2JibGVyL2tvYW4gaXMg
c3VkZGVubHkKYnJva2VuIGFmdGVyIDQgeWVhcnMgYW5kIHBlb3BsZSBjYW4ndCBpbnN0YWxsIGRv
bVVzIGFueW1vcmUuIDopCgpHcmVldGluZ3MsCkZsb3JpYW4KCnAucy46IEkgYW0gYXdhcmUgSSB3
aWxsIGhhdmUgdG8gbWFrZSB1cCBmb3IgdGhpcyBtYWlsIGluIGJlZXIgb25jZQp0aGVyZSBpcyBh
biBvcHBvcnR1bml0eS4KCi0tIAp0aGUgcHVycG9zZSBvZiBsaWJ2aXJ0IGlzIHRvIHByb3ZpZGUg
YW4gYWJzdHJhY3Rpb24gbGF5ZXIgaGlkaW5nIGFsbAp4ZW4gZmVhdHVyZXMgYWRkZWQgc2luY2Ug
MjAwNiB1bnRpbCB0aGV5IHdlcmUgZmluYWxseSB1bmRlcnN0b29kIGFuZApjb3BpZWQgYnkgdGhl
IGt2bSBkZXZzLgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:49:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq8py-0004oz-IC; Wed, 25 Jan 2012 19:48:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq8pw-0004oM-Qw
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:48:53 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327520926!8329659!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2793 invoked from network); 25 Jan 2012 19:48:46 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-10.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 19:48:46 -0000
Received: (qmail 19084 invoked from network); 25 Jan 2012 20:48:45 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 20:48:45 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 20:48:44 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <201201171115.53993.pavel@netsafe.cz>
	<201201250926.45689.pavel@netsafe.cz>
	<20120125161828.GC12984@reaktio.net>
In-Reply-To: <20120125161828.GC12984@reaktio.net>
MIME-Version: 1.0
Message-Id: <201201252048.44437.pavel@netsafe.cz>
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed 25. of January 2012 17:18:28 you wrote:
> On Wed, Jan 25, 2012 at 09:26:45AM +0100, Pavel Mateja wrote:
> > > I can't hear sound in DomU. Hmm, to be honest I've heard some broken
> > > pieces,..
> > 
> > Problem found:
> > You can't load linux ALSA driver before you pass the sound card to the
> > virtual machine. Since I removed linux kernel driver Windows play sounds
> > just fine.
> 
> Thanks for the update. And that's quite obvious reason..
> naturally you can't use a single PCI device in multiple domains at the same
> time.
> 
> PCI passthru *dedicates* the device to specific domain, so it can only be
> used in that domain. If dom0 is trying to use it aswell, things will go
> wrong.
> 
> -- Pasi

I know that.
I power down USB controller and rescan PCI because of resource_allignment and 
I unbind all the devices (USB, VGA, Sound Card) from drivers.
Just sound card didn't work well after this.
Strange thing is the sound was working on Crosshair IV Formula.
I suppose linux driver sets up the card in way Windows can't handle.
Funny thing: sound worked in analog in Battlefield 3 but not plain Win7. No 
single beep from SPDIF. One big WTF?
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:49:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq8py-0004oz-IC; Wed, 25 Jan 2012 19:48:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq8pw-0004oM-Qw
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:48:53 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327520926!8329659!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2793 invoked from network); 25 Jan 2012 19:48:46 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-10.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 19:48:46 -0000
Received: (qmail 19084 invoked from network); 25 Jan 2012 20:48:45 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 20:48:45 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 20:48:44 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <201201171115.53993.pavel@netsafe.cz>
	<201201250926.45689.pavel@netsafe.cz>
	<20120125161828.GC12984@reaktio.net>
In-Reply-To: <20120125161828.GC12984@reaktio.net>
MIME-Version: 1.0
Message-Id: <201201252048.44437.pavel@netsafe.cz>
Subject: Re: [Xen-devel] VGA Passthru HW upgrade
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed 25. of January 2012 17:18:28 you wrote:
> On Wed, Jan 25, 2012 at 09:26:45AM +0100, Pavel Mateja wrote:
> > > I can't hear sound in DomU. Hmm, to be honest I've heard some broken
> > > pieces,..
> > 
> > Problem found:
> > You can't load linux ALSA driver before you pass the sound card to the
> > virtual machine. Since I removed linux kernel driver Windows play sounds
> > just fine.
> 
> Thanks for the update. And that's quite obvious reason..
> naturally you can't use a single PCI device in multiple domains at the same
> time.
> 
> PCI passthru *dedicates* the device to specific domain, so it can only be
> used in that domain. If dom0 is trying to use it aswell, things will go
> wrong.
> 
> -- Pasi

I know that.
I power down USB controller and rescan PCI because of resource_allignment and 
I unbind all the devices (USB, VGA, Sound Card) from drivers.
Just sound card didn't work well after this.
Strange thing is the sound was working on Crosshair IV Formula.
I suppose linux driver sets up the card in way Windows can't handle.
Funny thing: sound worked in analog in Battlefield 3 but not plain Win7. No 
single beep from SPDIF. One big WTF?
-- 
Pavel Mateja

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq8tK-0005CY-60; Wed, 25 Jan 2012 19:52:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq8tJ-0005CH-21
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:52:21 +0000
Received: from [85.158.138.51:42413] by server-2.bemta-3.messagelabs.com id
	7E/47-24515-47D502F4; Wed, 25 Jan 2012 19:52:20 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327521139!10666011!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3717 invoked from network); 25 Jan 2012 19:52:19 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-4.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 19:52:19 -0000
Received: (qmail 19441 invoked from network); 25 Jan 2012 20:52:18 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 20:52:18 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 20:52:17 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
	<201201252029.12936.pavel@netsafe.cz>
In-Reply-To: <201201252029.12936.pavel@netsafe.cz>
MIME-Version: 1.0
Message-Id: <201201252052.17845.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkIDI1LiBvZiBKYW51YXJ5IDIwMTIgMjA6Mjk6MTIgUGF2ZWwgTWF0xJtqYSB3cm90ZToK
PiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAxNzo1MjoxMSBEb3VnIE1hZ2VlIHdyb3RlOgo+
ID4gQWxzbywgaSBiZWxpZXZlIHlvdSBzYWlkIHRoZSBjYXJkIHlvdSdyZSB0cnlpbmcgdG8gcGFz
cyB0aHJvdWdoIGlzIG5vdAo+ID4gdGhlIHByaW1hcnkgY2FyZCBpbiB5b3VyIGhvc3Qgc3lzdGVt
LiAgSWYgdGhhdCdzIHRoZSBjYXNlLCBkb24ndCB1c2UKPiA+IGdmeF9wYXNzdGhydSBvciBleHBl
Y3QgdG8gZ2V0IHRoZSB2aWRlbyBiaW9zIHdvcmtpbmcuICBUaGUgJ3ByaW1hcnknCj4gPiB2aWRl
byBhZGFwdGVyIG93bnMgY2VydGFpbiBpbyBwb3J0cyBhbmQgbWVtb3J5IGFyZWFzIHRoYXQgYXJl
IGNvbnNpdGVudAo+ID4gZnJvbSBtYWNoaW5lIHRvIG1hY2hpbmUuICBBbHNvLCB0aGUgc3lzdGVt
IHdpbGwgY29weSB0aGUgdmJpb3MgZnJvbSB0aGUKPiA+IGNhcmQgdG8gYSBsb2NhdGlvbiBpbiBt
ZW1vcnkgKDB4YzAwMDApIHNvIGl0IGNhbiBleGVjdXRlIGF0IGJvb3QgdGltZS4KPiA+IAo+ID4g
WGVuJ3MgZ2Z4X3Bhc3N0aHJ1IGNvZGUgZGVwZW5kcyBvbiBhbGwgb2YgdGhlc2UgZmFjdG9ycy4g
IEFzIHRoZSBjb2RlCj4gPiBzdGFuZHMsIGlmIHlvdSB1c2UgZ2Z4X3Bhc3N0aHJ1IG9uIGEgc2Vj
b25kYXJ5IGNhcmQsIGl0IHdpbGwgc3RpbGwgY29weQo+ID4gdGhlIHZiaW9zIGZyb20gdGhlIHBy
aW1hcnkgY2FyZCAoYXMgaXQgc2ltcGx5IHJlYWRzIG1lbW9yeSBmcm9tCj4gPiAweGMwMDAwKSwg
YW5kIGRpcmVjdGx5IG1hcCBpbyBwb3J0cyBhbmQgbG93IG1lbW9yeSBhcmVhcyB0byB0aG9zZSB1
c2VkCj4gPiBieSB0aGUgcHJpbWFyeSBjYXJkIGluIHRoZSBob3N0IHN5c3RlbS4gIEluIHRoaXMg
Y2FzZSB0aGUgZ3Vlc3Qgd2lsbAo+ID4gYWxtb3N0IGNlcnRhaW5seSBuZXZlciBnZXQgcGFzdCBl
eGVjdXRpbmcgUk9NQklPUywgYW5kIHRoZSBob3N0IG1heSBvcgo+ID4gbWF5IG5vdCBsb2NrIHVw
IG9yIGV4cGVyaWVuY2UgJ2lzc3VlcycuCj4gCj4gVGhpcyB3aWxsIGRvIHRoZSB0cmljayB3aXRo
IHNlY29uZGFyeSBjYXJkIChyZXBsYWNlIHBhdGggdG8gVkdBIEJJT1MpOgo+IAo+IC0tLSB4ZW4t
dW5zdGFibGUuaGcud29ya2luZy90b29scy9pb2VtdS1yZW1vdGUvaHcvcHQtZ3JhcGhpY3MuYyAy
MDEyLTAxLTI1Cj4gMjA6MjY6MzcuOTI3NjU0ODkwICswMTAwCj4gKysrIHhlbi11bnN0YWJsZS5o
Zy53b3JraW5nLmdlbmVyaWMvdG9vbHMvaW9lbXUtcmVtb3RlL2h3L3B0LWdyYXBoaWNzLmMKPiAy
MDExLTA3LTMwIDEzOjU3OjU3LjM0NzM5NjA5NSArMDIwMAo+IEBAIC00ODcsMTAgKzQ4NywxMCBA
QAo+ICB7Cj4gICAgICBpbnQgZmQ7Cj4gICAgICB1aW50MzJfdCBiaW9zX3NpemUgPSAwOwo+IC0g
ICAgdWludDMyX3Qgc3RhcnQgPSAwOwo+ICsgICAgdWludDMyX3Qgc3RhcnQgPSAweEMwMDAwOwo+
ICAgICAgdWludDE2X3QgbWFnaWMgPSAwOwo+IAo+IC0gICAgaWYgKCAoZmQgPSBvcGVuKCIvbGli
L2Zpcm13YXJlL0FTVVMuSEQ2ODUwLjEwMjQuMTAxMDA3LmJpbiIsCj4gT19SRE9OTFkpKSA8IDAg
KQo+ICsgICAgaWYgKCAoZmQgPSBvcGVuKCIvZGV2L21lbSIsIE9fUkRPTkxZKSkgPCAwICkKPiAg
ICAgIHsKPiAgICAgICAgICBQVF9MT0coIkVycm9yOiBDYW4ndCBvcGVuIC9kZXYvbWVtOiAlc1xu
Iiwgc3RyZXJyb3IoZXJybm8pKTsKPiAgICAgICAgICByZXR1cm4gMDsKClNvcnJ5LCBzd2l0Y2gg
dGhlICsgYW5kIC0uCi0tIApQYXZlbCBNYXRlamEKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 25 19:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 19:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq8tK-0005CY-60; Wed, 25 Jan 2012 19:52:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq8tJ-0005CH-21
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 19:52:21 +0000
Received: from [85.158.138.51:42413] by server-2.bemta-3.messagelabs.com id
	7E/47-24515-47D502F4; Wed, 25 Jan 2012 19:52:20 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327521139!10666011!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3717 invoked from network); 25 Jan 2012 19:52:19 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-4.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 19:52:19 -0000
Received: (qmail 19441 invoked from network); 25 Jan 2012 20:52:18 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 20:52:18 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 20:52:17 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
	<201201252029.12936.pavel@netsafe.cz>
In-Reply-To: <201201252029.12936.pavel@netsafe.cz>
MIME-Version: 1.0
Message-Id: <201201252052.17845.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkIDI1LiBvZiBKYW51YXJ5IDIwMTIgMjA6Mjk6MTIgUGF2ZWwgTWF0xJtqYSB3cm90ZToK
PiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAxNzo1MjoxMSBEb3VnIE1hZ2VlIHdyb3RlOgo+
ID4gQWxzbywgaSBiZWxpZXZlIHlvdSBzYWlkIHRoZSBjYXJkIHlvdSdyZSB0cnlpbmcgdG8gcGFz
cyB0aHJvdWdoIGlzIG5vdAo+ID4gdGhlIHByaW1hcnkgY2FyZCBpbiB5b3VyIGhvc3Qgc3lzdGVt
LiAgSWYgdGhhdCdzIHRoZSBjYXNlLCBkb24ndCB1c2UKPiA+IGdmeF9wYXNzdGhydSBvciBleHBl
Y3QgdG8gZ2V0IHRoZSB2aWRlbyBiaW9zIHdvcmtpbmcuICBUaGUgJ3ByaW1hcnknCj4gPiB2aWRl
byBhZGFwdGVyIG93bnMgY2VydGFpbiBpbyBwb3J0cyBhbmQgbWVtb3J5IGFyZWFzIHRoYXQgYXJl
IGNvbnNpdGVudAo+ID4gZnJvbSBtYWNoaW5lIHRvIG1hY2hpbmUuICBBbHNvLCB0aGUgc3lzdGVt
IHdpbGwgY29weSB0aGUgdmJpb3MgZnJvbSB0aGUKPiA+IGNhcmQgdG8gYSBsb2NhdGlvbiBpbiBt
ZW1vcnkgKDB4YzAwMDApIHNvIGl0IGNhbiBleGVjdXRlIGF0IGJvb3QgdGltZS4KPiA+IAo+ID4g
WGVuJ3MgZ2Z4X3Bhc3N0aHJ1IGNvZGUgZGVwZW5kcyBvbiBhbGwgb2YgdGhlc2UgZmFjdG9ycy4g
IEFzIHRoZSBjb2RlCj4gPiBzdGFuZHMsIGlmIHlvdSB1c2UgZ2Z4X3Bhc3N0aHJ1IG9uIGEgc2Vj
b25kYXJ5IGNhcmQsIGl0IHdpbGwgc3RpbGwgY29weQo+ID4gdGhlIHZiaW9zIGZyb20gdGhlIHBy
aW1hcnkgY2FyZCAoYXMgaXQgc2ltcGx5IHJlYWRzIG1lbW9yeSBmcm9tCj4gPiAweGMwMDAwKSwg
YW5kIGRpcmVjdGx5IG1hcCBpbyBwb3J0cyBhbmQgbG93IG1lbW9yeSBhcmVhcyB0byB0aG9zZSB1
c2VkCj4gPiBieSB0aGUgcHJpbWFyeSBjYXJkIGluIHRoZSBob3N0IHN5c3RlbS4gIEluIHRoaXMg
Y2FzZSB0aGUgZ3Vlc3Qgd2lsbAo+ID4gYWxtb3N0IGNlcnRhaW5seSBuZXZlciBnZXQgcGFzdCBl
eGVjdXRpbmcgUk9NQklPUywgYW5kIHRoZSBob3N0IG1heSBvcgo+ID4gbWF5IG5vdCBsb2NrIHVw
IG9yIGV4cGVyaWVuY2UgJ2lzc3VlcycuCj4gCj4gVGhpcyB3aWxsIGRvIHRoZSB0cmljayB3aXRo
IHNlY29uZGFyeSBjYXJkIChyZXBsYWNlIHBhdGggdG8gVkdBIEJJT1MpOgo+IAo+IC0tLSB4ZW4t
dW5zdGFibGUuaGcud29ya2luZy90b29scy9pb2VtdS1yZW1vdGUvaHcvcHQtZ3JhcGhpY3MuYyAy
MDEyLTAxLTI1Cj4gMjA6MjY6MzcuOTI3NjU0ODkwICswMTAwCj4gKysrIHhlbi11bnN0YWJsZS5o
Zy53b3JraW5nLmdlbmVyaWMvdG9vbHMvaW9lbXUtcmVtb3RlL2h3L3B0LWdyYXBoaWNzLmMKPiAy
MDExLTA3LTMwIDEzOjU3OjU3LjM0NzM5NjA5NSArMDIwMAo+IEBAIC00ODcsMTAgKzQ4NywxMCBA
QAo+ICB7Cj4gICAgICBpbnQgZmQ7Cj4gICAgICB1aW50MzJfdCBiaW9zX3NpemUgPSAwOwo+IC0g
ICAgdWludDMyX3Qgc3RhcnQgPSAwOwo+ICsgICAgdWludDMyX3Qgc3RhcnQgPSAweEMwMDAwOwo+
ICAgICAgdWludDE2X3QgbWFnaWMgPSAwOwo+IAo+IC0gICAgaWYgKCAoZmQgPSBvcGVuKCIvbGli
L2Zpcm13YXJlL0FTVVMuSEQ2ODUwLjEwMjQuMTAxMDA3LmJpbiIsCj4gT19SRE9OTFkpKSA8IDAg
KQo+ICsgICAgaWYgKCAoZmQgPSBvcGVuKCIvZGV2L21lbSIsIE9fUkRPTkxZKSkgPCAwICkKPiAg
ICAgIHsKPiAgICAgICAgICBQVF9MT0coIkVycm9yOiBDYW4ndCBvcGVuIC9kZXYvbWVtOiAlc1xu
Iiwgc3RyZXJyb3IoZXJybm8pKTsKPiAgICAgICAgICByZXR1cm4gMDsKClNvcnJ5LCBzd2l0Y2gg
dGhlICsgYW5kIC0uCi0tIApQYXZlbCBNYXRlamEKCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxp
c3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:23:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20: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 1Rq9Md-0005uk-PG; Wed, 25 Jan 2012 20:22:39 +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 1Rq9Mb-0005uf-Tw
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:22:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327522950!13910946!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10012 invoked from network); 25 Jan 2012 20:22:31 -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;
	25 Jan 2012 20:22:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PKMSY7014315; Wed, 25 Jan 2012 20:22:28 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 q0PKMRJA030030; 
	Wed, 25 Jan 2012 15:22:27 -0500
Message-ID: <4F206484.3030508@tycho.nsa.gov>
Date: Wed, 25 Jan 2012 15:22:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327502278-1790-19-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201251854530.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201251854530.3196@kaball-desktop>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 18/23] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/25/2012 02:14 PM, Stefano Stabellini wrote:
> On Wed, 25 Jan 2012, Daniel De Graaf wrote:
>> A previous versions of this patch has been sent to xen-devel. See
>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
>>
>> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/Makefile           |    9 ++++++++-
>>  tools/xenstore/tdb.c              |    6 +++---
>>  tools/xenstore/utils.h            |    2 ++
>>  tools/xenstore/xenstored_core.c   |   29 ++++++++++++++++++++++++++---
>>  tools/xenstore/xenstored_domain.c |   11 +++++++++++
>>  5 files changed, 50 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
>> index 4facb62..be892fd 100644
>> --- a/tools/xenstore/Makefile
>> +++ b/tools/xenstore/Makefile
>> @@ -28,6 +28,10 @@ endif
>>  
>>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>>  
>> +ifdef CONFIG_STUBDOM
>> +CFLAGS += -DNO_SOCKETS=1
>> +endif
>> +
>>  .PHONY: all
>>  all: $(ALL_TARGETS)
>>  
>> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
>>  
>>  CFLAGS += -DHAVE_DTRACE=1
>>  endif
>> - 
>> +
>>  xenstored: $(XENSTORED_OBJS)
>>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>>  
>> +xenstored.a: $(XENSTORED_OBJS)
>> +	$(AR) cr $@ $^
>> +
>>  $(CLIENTS): xenstore
>>  	ln -f xenstore $@
>>  
>> diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
>> index 3ecd3fc..cb66ea7 100644
>> --- a/tools/xenstore/tdb.c
>> +++ b/tools/xenstore/tdb.c
>> @@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>>  
>>  		/* Iterate through chain */
>>  		while( tlock->off) {
>> -			tdb_off current;
>> +			tdb_off mycurrent;
>>  			if (rec_read(tdb, tlock->off, rec) == -1)
>>  				goto fail;
>>  
>> @@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>>  			}
>>  
>>  			/* Try to clean dead ones from old traverses */
>> -			current = tlock->off;
>> +			mycurrent = tlock->off;
>>  			tlock->off = rec->next;
>>  			if (!tdb->read_only && 
>> -			    do_delete(tdb, current, rec) != 0)
>> +			    do_delete(tdb, mycurrent, rec) != 0)
>>  				goto fail;
>>  		}
>>  		tdb_unlock(tdb, tlock->hash, F_WRLCK);
> 
> Why are you renaming current to mycurrent?

Hmm. While current is a #define in mini-os sched.h, this file doesn't
include that header so it shouldn't break. I'll drop this change.

> 
>> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
>> index f378343..2effd17 100644
>> --- a/tools/xenstore/utils.h
>> +++ b/tools/xenstore/utils.h
>> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>>  	return streq(a + strlen(a) - strlen(b), b);
>>  }
>>  
>> +#ifndef ARRAY_SIZE
>>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
>> +#endif
>>  
>>  void barf(const char *fmt, ...) __attribute__((noreturn));
>>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index c1ee932..7564edd 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -92,8 +92,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
>>  
>>  bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
>>  {
>> +#ifndef __MINIOS__
>>  	if (rename(newname, xs_daemon_tdb()) != 0)
>>  		return false;
>> +#endif
>>  	tdb_close(tdb_ctx);
>>  	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
>>  	return true;
> 
> Are you doing this because the database is not on file anymore, correct?
> Maybe there is some room for introducing this concept more generally
> because it could be useful on Linux too and it would avoid this and
> other ifdef's.

Yes, this one can check TDB_INTERNAL (not sure why the original author
didn't want to check that flag; it works fine).

> 
>> @@ -223,7 +225,6 @@ static void reopen_log(void)
>>  	}
>>  }
>>  
>> -
>>  static bool write_messages(struct connection *conn)
>>  {
>>  	int ret;
>> @@ -326,7 +327,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>>  		set_fd(sock, inset, &max);
>>  	if (ro_sock != -1)
>>  		set_fd(ro_sock, inset, &max);
>> -	set_fd(reopen_log_pipe[0], inset, &max);
>> +	if (reopen_log_pipe[0] != -1)
>> +		set_fd(reopen_log_pipe[0], inset, &max);
>>  
>>  	if (xce_handle != NULL)
>>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
>> @@ -1410,7 +1412,11 @@ static void accept_connection(int sock, bool canwrite)
>>  }
>>  #endif
>>  
>> +#ifdef __MINIOS__
>> +#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
>> +#else
>>  #define TDB_FLAGS 0
>> +#endif
> 
> See above

I will be adding a command-line argument for this, and force it to be
enabled if __MINIOS__.

> 
>>  /* We create initial nodes manually. */
>>  static void manual_node(const char *name, const char *child)
>> @@ -1435,7 +1441,11 @@ static void setup_structure(void)
>>  {
>>  	char *tdbname;
>>  	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
>> +#ifdef __MINIOS__
>> +	tdb_ctx = NULL;
>> +#else
>>  	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
>> +#endif
> 
> ditto
> 
>>  	if (tdb_ctx) {
>>  		/* XXX When we make xenstored able to restart, this will have
>> @@ -1661,6 +1671,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>>  }
>>  
>>  
>> +#ifndef __MINIOS__
>>  static void write_pidfile(const char *pidfile)
>>  {
>>  	char buf[100];
>> @@ -1707,6 +1718,7 @@ static void daemonize(void)
>>  	/* Discard our parent's old-fashioned umask prejudices. */
>>  	umask(0);
>>  }
>> +#endif
>>  
>>  #ifdef NO_SOCKETS
>>  static void init_sockets(int **psock, int **pro_sock)
>> @@ -1866,6 +1878,7 @@ int main(int argc, char *argv[])
>>  
>>  	reopen_log();
>>  
>> +#ifndef __MINIOS__
>>  	/* make sure xenstored directory exists */
>>  	if (mkdir(xs_daemon_rundir(), 0755)) {
>>  		if (errno != EEXIST) {
>> @@ -1887,6 +1900,7 @@ int main(int argc, char *argv[])
>>  	}
>>  	if (pidfile)
>>  		write_pidfile(pidfile);
>> +#endif
> 
> Maybe we could just have this fail gracefully: after all even on Linux
> if the socket interface is not available everything should be able to
> run correctly.
> 

That's simple enough to change, although it might make debugging a bit harder
on Linux if there are stale socket files around with bad permissions.

Actually... this is just making the directories. Error reporting doesn't belong
here, it belongs where we open the files that go in the directories.

> 
>>  	/* Talloc leak reports go to stderr, which is closed if we fork. */
>>  	if (!dofork)
>> @@ -1897,9 +1911,14 @@ int main(int argc, char *argv[])
>>  
>>  	init_sockets(&sock, &ro_sock);
>>  
>> +#ifdef __MINIOS__
>> +	reopen_log_pipe[0] = -1;
>> +	reopen_log_pipe[1] = -1;
>> +#else
>>  	if (pipe(reopen_log_pipe)) {
>>  		barf_perror("pipe");
>>  	}
>> +#endif
>>  
>>  	/* Setup the database */
>>  	setup_structure();
>> @@ -1916,6 +1935,7 @@ int main(int argc, char *argv[])
>>  		fflush(stdout);
>>  	}
>>  
>> +#ifndef __MINIOS__
>>  	/* redirect to /dev/null now we're ready to accept connections */
>>  	if (dofork) {
>>  		int devnull = open("/dev/null", O_RDWR);
>> @@ -1927,6 +1947,7 @@ int main(int argc, char *argv[])
>>  		close(devnull);
>>  		xprintf = trace;
>>  	}
>> +#endif
> 
> we could probably handle /dev/null in minios from sys.c

This should really be part of daemonize() except that we still need the
original stdout for outputpid; I'll move it to a finish_daemonize().

> 
>>  	signal(SIGHUP, trigger_reopen_log);
>>  
>> @@ -1936,8 +1957,10 @@ int main(int argc, char *argv[])
>>  	/* Get ready to listen to the tools. */
>>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>>  
>> +#ifndef __MINIOS__
>>  	/* Tell the kernel we're up and running. */
>>  	xenbus_notify_running();
>> +#endif
>>  
>>  	/* Main loop. */
>>  	for (;;) {
>> @@ -1949,7 +1972,7 @@ int main(int argc, char *argv[])
>>  			barf_perror("Select failed");
>>  		}
>>  
>> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
>> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>>  			char c;
>>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>>  				barf_perror("read failed");
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 661d955..435f76a 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
>>  	}
>>  
>>  	if (domain->interface) {
>> +#ifdef __MINIOS__
>> +		unmap_interface(domain->interface);
>> +#else
>>  		if (domain->domid == 0)
>>  			munmap(domain->interface, getpagesize());
>>  		else
>>  			unmap_interface(domain->interface);
>> +#endif
>>  	}
> 
> Argh. 
> Why dom0 cannot be handled inside unmap_interface?

Because dom0 isn't mapped the same way as domU. The mapping for dom0
is set up by introduce_dom0 which uses mmap directly, so it cannot be
unmapped using the grant table unmap function. When xenstore was using
map_foreign_range this didn't matter, everyone used munmap. In fact,
on Linux it still doesn't matter as the grant table unmap is munmap.

I'll add (as part of #14) a comment here since it's the second time
I've needed to explain this nuance.

> 
>>  	fire_watches(NULL, "@releaseDomain", false);
>> @@ -595,6 +599,12 @@ void restore_existing_connections(void)
>>  {
>>  }
>>  
>> +#ifdef __MINIOS__
>> +static int dom0_init(void)
>> +{
>> +	return 0;
>> +}
>> +#else
>>  static int dom0_init(void) 
>>  { 
>>  	evtchn_port_t port;
>> @@ -618,6 +628,7 @@ static int dom0_init(void)
>>  
>>  	return 0; 
>>  }
>> +#endif
>>  
>>  void domain_init(void)
>>  {
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:23:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20: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 1Rq9Md-0005uk-PG; Wed, 25 Jan 2012 20:22:39 +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 1Rq9Mb-0005uf-Tw
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:22:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327522950!13910946!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10012 invoked from network); 25 Jan 2012 20:22:31 -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;
	25 Jan 2012 20:22:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0PKMSY7014315; Wed, 25 Jan 2012 20:22:28 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 q0PKMRJA030030; 
	Wed, 25 Jan 2012 15:22:27 -0500
Message-ID: <4F206484.3030508@tycho.nsa.gov>
Date: Wed, 25 Jan 2012 15:22:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1327502278-1790-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327502278-1790-19-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201251854530.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201251854530.3196@kaball-desktop>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 18/23] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/25/2012 02:14 PM, Stefano Stabellini wrote:
> On Wed, 25 Jan 2012, Daniel De Graaf wrote:
>> A previous versions of this patch has been sent to xen-devel. See
>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
>>
>> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  tools/xenstore/Makefile           |    9 ++++++++-
>>  tools/xenstore/tdb.c              |    6 +++---
>>  tools/xenstore/utils.h            |    2 ++
>>  tools/xenstore/xenstored_core.c   |   29 ++++++++++++++++++++++++++---
>>  tools/xenstore/xenstored_domain.c |   11 +++++++++++
>>  5 files changed, 50 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
>> index 4facb62..be892fd 100644
>> --- a/tools/xenstore/Makefile
>> +++ b/tools/xenstore/Makefile
>> @@ -28,6 +28,10 @@ endif
>>  
>>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>>  
>> +ifdef CONFIG_STUBDOM
>> +CFLAGS += -DNO_SOCKETS=1
>> +endif
>> +
>>  .PHONY: all
>>  all: $(ALL_TARGETS)
>>  
>> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
>>  
>>  CFLAGS += -DHAVE_DTRACE=1
>>  endif
>> - 
>> +
>>  xenstored: $(XENSTORED_OBJS)
>>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>>  
>> +xenstored.a: $(XENSTORED_OBJS)
>> +	$(AR) cr $@ $^
>> +
>>  $(CLIENTS): xenstore
>>  	ln -f xenstore $@
>>  
>> diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
>> index 3ecd3fc..cb66ea7 100644
>> --- a/tools/xenstore/tdb.c
>> +++ b/tools/xenstore/tdb.c
>> @@ -1334,7 +1334,7 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>>  
>>  		/* Iterate through chain */
>>  		while( tlock->off) {
>> -			tdb_off current;
>> +			tdb_off mycurrent;
>>  			if (rec_read(tdb, tlock->off, rec) == -1)
>>  				goto fail;
>>  
>> @@ -1352,10 +1352,10 @@ static int tdb_next_lock(TDB_CONTEXT *tdb, struct tdb_traverse_lock *tlock,
>>  			}
>>  
>>  			/* Try to clean dead ones from old traverses */
>> -			current = tlock->off;
>> +			mycurrent = tlock->off;
>>  			tlock->off = rec->next;
>>  			if (!tdb->read_only && 
>> -			    do_delete(tdb, current, rec) != 0)
>> +			    do_delete(tdb, mycurrent, rec) != 0)
>>  				goto fail;
>>  		}
>>  		tdb_unlock(tdb, tlock->hash, F_WRLCK);
> 
> Why are you renaming current to mycurrent?

Hmm. While current is a #define in mini-os sched.h, this file doesn't
include that header so it shouldn't break. I'll drop this change.

> 
>> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
>> index f378343..2effd17 100644
>> --- a/tools/xenstore/utils.h
>> +++ b/tools/xenstore/utils.h
>> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>>  	return streq(a + strlen(a) - strlen(b), b);
>>  }
>>  
>> +#ifndef ARRAY_SIZE
>>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
>> +#endif
>>  
>>  void barf(const char *fmt, ...) __attribute__((noreturn));
>>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index c1ee932..7564edd 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -92,8 +92,10 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
>>  
>>  bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
>>  {
>> +#ifndef __MINIOS__
>>  	if (rename(newname, xs_daemon_tdb()) != 0)
>>  		return false;
>> +#endif
>>  	tdb_close(tdb_ctx);
>>  	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
>>  	return true;
> 
> Are you doing this because the database is not on file anymore, correct?
> Maybe there is some room for introducing this concept more generally
> because it could be useful on Linux too and it would avoid this and
> other ifdef's.

Yes, this one can check TDB_INTERNAL (not sure why the original author
didn't want to check that flag; it works fine).

> 
>> @@ -223,7 +225,6 @@ static void reopen_log(void)
>>  	}
>>  }
>>  
>> -
>>  static bool write_messages(struct connection *conn)
>>  {
>>  	int ret;
>> @@ -326,7 +327,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>>  		set_fd(sock, inset, &max);
>>  	if (ro_sock != -1)
>>  		set_fd(ro_sock, inset, &max);
>> -	set_fd(reopen_log_pipe[0], inset, &max);
>> +	if (reopen_log_pipe[0] != -1)
>> +		set_fd(reopen_log_pipe[0], inset, &max);
>>  
>>  	if (xce_handle != NULL)
>>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
>> @@ -1410,7 +1412,11 @@ static void accept_connection(int sock, bool canwrite)
>>  }
>>  #endif
>>  
>> +#ifdef __MINIOS__
>> +#define TDB_FLAGS TDB_INTERNAL|TDB_NOLOCK
>> +#else
>>  #define TDB_FLAGS 0
>> +#endif
> 
> See above

I will be adding a command-line argument for this, and force it to be
enabled if __MINIOS__.

> 
>>  /* We create initial nodes manually. */
>>  static void manual_node(const char *name, const char *child)
>> @@ -1435,7 +1441,11 @@ static void setup_structure(void)
>>  {
>>  	char *tdbname;
>>  	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
>> +#ifdef __MINIOS__
>> +	tdb_ctx = NULL;
>> +#else
>>  	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
>> +#endif
> 
> ditto
> 
>>  	if (tdb_ctx) {
>>  		/* XXX When we make xenstored able to restart, this will have
>> @@ -1661,6 +1671,7 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>>  }
>>  
>>  
>> +#ifndef __MINIOS__
>>  static void write_pidfile(const char *pidfile)
>>  {
>>  	char buf[100];
>> @@ -1707,6 +1718,7 @@ static void daemonize(void)
>>  	/* Discard our parent's old-fashioned umask prejudices. */
>>  	umask(0);
>>  }
>> +#endif
>>  
>>  #ifdef NO_SOCKETS
>>  static void init_sockets(int **psock, int **pro_sock)
>> @@ -1866,6 +1878,7 @@ int main(int argc, char *argv[])
>>  
>>  	reopen_log();
>>  
>> +#ifndef __MINIOS__
>>  	/* make sure xenstored directory exists */
>>  	if (mkdir(xs_daemon_rundir(), 0755)) {
>>  		if (errno != EEXIST) {
>> @@ -1887,6 +1900,7 @@ int main(int argc, char *argv[])
>>  	}
>>  	if (pidfile)
>>  		write_pidfile(pidfile);
>> +#endif
> 
> Maybe we could just have this fail gracefully: after all even on Linux
> if the socket interface is not available everything should be able to
> run correctly.
> 

That's simple enough to change, although it might make debugging a bit harder
on Linux if there are stale socket files around with bad permissions.

Actually... this is just making the directories. Error reporting doesn't belong
here, it belongs where we open the files that go in the directories.

> 
>>  	/* Talloc leak reports go to stderr, which is closed if we fork. */
>>  	if (!dofork)
>> @@ -1897,9 +1911,14 @@ int main(int argc, char *argv[])
>>  
>>  	init_sockets(&sock, &ro_sock);
>>  
>> +#ifdef __MINIOS__
>> +	reopen_log_pipe[0] = -1;
>> +	reopen_log_pipe[1] = -1;
>> +#else
>>  	if (pipe(reopen_log_pipe)) {
>>  		barf_perror("pipe");
>>  	}
>> +#endif
>>  
>>  	/* Setup the database */
>>  	setup_structure();
>> @@ -1916,6 +1935,7 @@ int main(int argc, char *argv[])
>>  		fflush(stdout);
>>  	}
>>  
>> +#ifndef __MINIOS__
>>  	/* redirect to /dev/null now we're ready to accept connections */
>>  	if (dofork) {
>>  		int devnull = open("/dev/null", O_RDWR);
>> @@ -1927,6 +1947,7 @@ int main(int argc, char *argv[])
>>  		close(devnull);
>>  		xprintf = trace;
>>  	}
>> +#endif
> 
> we could probably handle /dev/null in minios from sys.c

This should really be part of daemonize() except that we still need the
original stdout for outputpid; I'll move it to a finish_daemonize().

> 
>>  	signal(SIGHUP, trigger_reopen_log);
>>  
>> @@ -1936,8 +1957,10 @@ int main(int argc, char *argv[])
>>  	/* Get ready to listen to the tools. */
>>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>>  
>> +#ifndef __MINIOS__
>>  	/* Tell the kernel we're up and running. */
>>  	xenbus_notify_running();
>> +#endif
>>  
>>  	/* Main loop. */
>>  	for (;;) {
>> @@ -1949,7 +1972,7 @@ int main(int argc, char *argv[])
>>  			barf_perror("Select failed");
>>  		}
>>  
>> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
>> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>>  			char c;
>>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>>  				barf_perror("read failed");
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index 661d955..435f76a 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -197,10 +197,14 @@ static int destroy_domain(void *_domain)
>>  	}
>>  
>>  	if (domain->interface) {
>> +#ifdef __MINIOS__
>> +		unmap_interface(domain->interface);
>> +#else
>>  		if (domain->domid == 0)
>>  			munmap(domain->interface, getpagesize());
>>  		else
>>  			unmap_interface(domain->interface);
>> +#endif
>>  	}
> 
> Argh. 
> Why dom0 cannot be handled inside unmap_interface?

Because dom0 isn't mapped the same way as domU. The mapping for dom0
is set up by introduce_dom0 which uses mmap directly, so it cannot be
unmapped using the grant table unmap function. When xenstore was using
map_foreign_range this didn't matter, everyone used munmap. In fact,
on Linux it still doesn't matter as the grant table unmap is munmap.

I'll add (as part of #14) a comment here since it's the second time
I've needed to explain this nuance.

> 
>>  	fire_watches(NULL, "@releaseDomain", false);
>> @@ -595,6 +599,12 @@ void restore_existing_connections(void)
>>  {
>>  }
>>  
>> +#ifdef __MINIOS__
>> +static int dom0_init(void)
>> +{
>> +	return 0;
>> +}
>> +#else
>>  static int dom0_init(void) 
>>  { 
>>  	evtchn_port_t port;
>> @@ -618,6 +628,7 @@ static int dom0_init(void)
>>  
>>  	return 0; 
>>  }
>> +#endif
>>  
>>  void domain_init(void)
>>  {
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:30:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20: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 1Rq9TL-00063t-L7; Wed, 25 Jan 2012 20:29:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rq9TJ-00063g-NE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:29:33 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327523365!8332906!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5498 invoked from network); 25 Jan 2012 20:29:27 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 20:29:27 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PKTOcY023450
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 15:29:25 -0500
Received: from [192.168.37.18] ([192.168.37.18]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Wed, 25 Jan 2012 15:29:02 -0500
Message-ID: <1327523353.2452.38.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Pavel =?UTF-8?Q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Date: Wed, 25 Jan 2012 15:29:13 -0500
In-Reply-To: <201201252052.17845.pavel@netsafe.cz>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
	<201201252029.12936.pavel@netsafe.cz>
	<201201252052.17845.pavel@netsafe.cz>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2012 20:29:02.0843 (UTC)
	FILETIME=[FA0E5CB0:01CCDB9F]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDIwOjUyICswMTAwLCBQYXZlbCBNYXTEm2phIHdyb3RlOgo+
IE9uIFdlZCAyNS4gb2YgSmFudWFyeSAyMDEyIDIwOjI5OjEyIFBhdmVsIE1hdMSbamEgd3JvdGU6
Cj4gPiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAxNzo1MjoxMSBEb3VnIE1hZ2VlIHdyb3Rl
Ogo+ID4gPiBBbHNvLCBpIGJlbGlldmUgeW91IHNhaWQgdGhlIGNhcmQgeW91J3JlIHRyeWluZyB0
byBwYXNzIHRocm91Z2ggaXMgbm90Cj4gPiA+IHRoZSBwcmltYXJ5IGNhcmQgaW4geW91ciBob3N0
IHN5c3RlbS4gIElmIHRoYXQncyB0aGUgY2FzZSwgZG9uJ3QgdXNlCj4gPiA+IGdmeF9wYXNzdGhy
dSBvciBleHBlY3QgdG8gZ2V0IHRoZSB2aWRlbyBiaW9zIHdvcmtpbmcuICBUaGUgJ3ByaW1hcnkn
Cj4gPiA+IHZpZGVvIGFkYXB0ZXIgb3ducyBjZXJ0YWluIGlvIHBvcnRzIGFuZCBtZW1vcnkgYXJl
YXMgdGhhdCBhcmUgY29uc2l0ZW50Cj4gPiA+IGZyb20gbWFjaGluZSB0byBtYWNoaW5lLiAgQWxz
bywgdGhlIHN5c3RlbSB3aWxsIGNvcHkgdGhlIHZiaW9zIGZyb20gdGhlCj4gPiA+IGNhcmQgdG8g
YSBsb2NhdGlvbiBpbiBtZW1vcnkgKDB4YzAwMDApIHNvIGl0IGNhbiBleGVjdXRlIGF0IGJvb3Qg
dGltZS4KPiA+ID4gCj4gPiA+IFhlbidzIGdmeF9wYXNzdGhydSBjb2RlIGRlcGVuZHMgb24gYWxs
IG9mIHRoZXNlIGZhY3RvcnMuICBBcyB0aGUgY29kZQo+ID4gPiBzdGFuZHMsIGlmIHlvdSB1c2Ug
Z2Z4X3Bhc3N0aHJ1IG9uIGEgc2Vjb25kYXJ5IGNhcmQsIGl0IHdpbGwgc3RpbGwgY29weQo+ID4g
PiB0aGUgdmJpb3MgZnJvbSB0aGUgcHJpbWFyeSBjYXJkIChhcyBpdCBzaW1wbHkgcmVhZHMgbWVt
b3J5IGZyb20KPiA+ID4gMHhjMDAwMCksIGFuZCBkaXJlY3RseSBtYXAgaW8gcG9ydHMgYW5kIGxv
dyBtZW1vcnkgYXJlYXMgdG8gdGhvc2UgdXNlZAo+ID4gPiBieSB0aGUgcHJpbWFyeSBjYXJkIGlu
IHRoZSBob3N0IHN5c3RlbS4gIEluIHRoaXMgY2FzZSB0aGUgZ3Vlc3Qgd2lsbAo+ID4gPiBhbG1v
c3QgY2VydGFpbmx5IG5ldmVyIGdldCBwYXN0IGV4ZWN1dGluZyBST01CSU9TLCBhbmQgdGhlIGhv
c3QgbWF5IG9yCj4gPiA+IG1heSBub3QgbG9jayB1cCBvciBleHBlcmllbmNlICdpc3N1ZXMnLgo+
ID4gCj4gPiBUaGlzIHdpbGwgZG8gdGhlIHRyaWNrIHdpdGggc2Vjb25kYXJ5IGNhcmQgKHJlcGxh
Y2UgcGF0aCB0byBWR0EgQklPUyk6Cj4gPiAKPiA+IC0tLSB4ZW4tdW5zdGFibGUuaGcud29ya2lu
Zy90b29scy9pb2VtdS1yZW1vdGUvaHcvcHQtZ3JhcGhpY3MuYyAyMDEyLTAxLTI1Cj4gPiAyMDoy
NjozNy45Mjc2NTQ4OTAgKzAxMDAKPiA+ICsrKyB4ZW4tdW5zdGFibGUuaGcud29ya2luZy5nZW5l
cmljL3Rvb2xzL2lvZW11LXJlbW90ZS9ody9wdC1ncmFwaGljcy5jCj4gPiAyMDExLTA3LTMwIDEz
OjU3OjU3LjM0NzM5NjA5NSArMDIwMAo+ID4gQEAgLTQ4NywxMCArNDg3LDEwIEBACj4gPiAgewo+
ID4gICAgICBpbnQgZmQ7Cj4gPiAgICAgIHVpbnQzMl90IGJpb3Nfc2l6ZSA9IDA7Cj4gPiAtICAg
IHVpbnQzMl90IHN0YXJ0ID0gMDsKPiA+ICsgICAgdWludDMyX3Qgc3RhcnQgPSAweEMwMDAwOwo+
ID4gICAgICB1aW50MTZfdCBtYWdpYyA9IDA7Cj4gPiAKPiA+IC0gICAgaWYgKCAoZmQgPSBvcGVu
KCIvbGliL2Zpcm13YXJlL0FTVVMuSEQ2ODUwLjEwMjQuMTAxMDA3LmJpbiIsCj4gPiBPX1JET05M
WSkpIDwgMCApCj4gPiArICAgIGlmICggKGZkID0gb3BlbigiL2Rldi9tZW0iLCBPX1JET05MWSkp
IDwgMCApCj4gPiAgICAgIHsKPiA+ICAgICAgICAgIFBUX0xPRygiRXJyb3I6IENhbid0IG9wZW4g
L2Rldi9tZW06ICVzXG4iLCBzdHJlcnJvcihlcnJubykpOwo+ID4gICAgICAgICAgcmV0dXJuIDA7
Cj4gCj4gU29ycnksIHN3aXRjaCB0aGUgKyBhbmQgLS4KClRoaXMgd2lsbCBsb2FkIHRoZSBwcm9w
ZXIgQklPUywgYnV0IGl0IHNlZW1zIHRoaXMgd291bGRuJ3QgYmUgZW5vdWdoLgpJbiBody9wdC1n
cmFwaGljcy5jOnJlZ2lzdGVyX3ZnYV9yZWdpb25zKCksIHdlIG1hcCAxOjEgaW9wb3J0cwoweDNi
MC0weDNiYiwgMHgzYzAtMHgzZGYsIGFuZCBtZW1vcnkgYXQgMHhhMDAwMC0weGJmZmZmLgoKSWYg
aSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGVzZSBpb3BvcnRzIGFuZCBtZW1vcnkgYXJl
YXMgYXJlIGJvdW5kCnRvIHRoZSBwcmltYXJ5IHZpZGVvIGFkYXB0ZXIgaW4gdGhlIGhvc3Qgb24g
Ym9vdCBieSB0aGUgQklPUywgZGVwZW5kaW5nCm9uIHdoYXQgZGV2aWNlIHlvdSd2ZSBzZWxlY3Rl
ZCBpbiB0aGUgQklPUyBzZXR1cCBzY3JlZW4gdG8gYmUgeW91cgpwcmltYXJ5IGFkYXB0ZXIuICBU
aGVyZWZvcmUsIHlvdSBjb3VsZCBsb2FkIHRoZSBwcm9wZXIgYmlvcywgYnV0IGl0CndvdWxkIHN0
aWxsIHdyaXRlIHRvIG1lbW9yeSBhbmQgaW8gcG9ydHMgdGhhdCBhcmUgYm91bmQgdG8gdGhlIHBy
aW1hcnkKY2FyZCBpbiB0aGUgaG9zdCwgbm90IHRoZSBjYXJkIGJlaW5nIHBhc3NlZCB0aHJvdWdo
IHRvIHRoZSBndWVzdC4KCkRvZXMgdGhpcyBtYWtlIHNlbnNlPyAoT3IsIGFtIGkgbnV0cz8pCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:30:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20: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 1Rq9TL-00063t-L7; Wed, 25 Jan 2012 20:29:35 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rq9TJ-00063g-NE
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:29:33 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327523365!8332906!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5498 invoked from network); 25 Jan 2012 20:29:27 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 20:29:27 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PKTOcY023450
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 15:29:25 -0500
Received: from [192.168.37.18] ([192.168.37.18]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Wed, 25 Jan 2012 15:29:02 -0500
Message-ID: <1327523353.2452.38.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Pavel =?UTF-8?Q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Date: Wed, 25 Jan 2012 15:29:13 -0500
In-Reply-To: <201201252052.17845.pavel@netsafe.cz>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
	<201201252029.12936.pavel@netsafe.cz>
	<201201252052.17845.pavel@netsafe.cz>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2012 20:29:02.0843 (UTC)
	FILETIME=[FA0E5CB0:01CCDB9F]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDIwOjUyICswMTAwLCBQYXZlbCBNYXTEm2phIHdyb3RlOgo+
IE9uIFdlZCAyNS4gb2YgSmFudWFyeSAyMDEyIDIwOjI5OjEyIFBhdmVsIE1hdMSbamEgd3JvdGU6
Cj4gPiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAxNzo1MjoxMSBEb3VnIE1hZ2VlIHdyb3Rl
Ogo+ID4gPiBBbHNvLCBpIGJlbGlldmUgeW91IHNhaWQgdGhlIGNhcmQgeW91J3JlIHRyeWluZyB0
byBwYXNzIHRocm91Z2ggaXMgbm90Cj4gPiA+IHRoZSBwcmltYXJ5IGNhcmQgaW4geW91ciBob3N0
IHN5c3RlbS4gIElmIHRoYXQncyB0aGUgY2FzZSwgZG9uJ3QgdXNlCj4gPiA+IGdmeF9wYXNzdGhy
dSBvciBleHBlY3QgdG8gZ2V0IHRoZSB2aWRlbyBiaW9zIHdvcmtpbmcuICBUaGUgJ3ByaW1hcnkn
Cj4gPiA+IHZpZGVvIGFkYXB0ZXIgb3ducyBjZXJ0YWluIGlvIHBvcnRzIGFuZCBtZW1vcnkgYXJl
YXMgdGhhdCBhcmUgY29uc2l0ZW50Cj4gPiA+IGZyb20gbWFjaGluZSB0byBtYWNoaW5lLiAgQWxz
bywgdGhlIHN5c3RlbSB3aWxsIGNvcHkgdGhlIHZiaW9zIGZyb20gdGhlCj4gPiA+IGNhcmQgdG8g
YSBsb2NhdGlvbiBpbiBtZW1vcnkgKDB4YzAwMDApIHNvIGl0IGNhbiBleGVjdXRlIGF0IGJvb3Qg
dGltZS4KPiA+ID4gCj4gPiA+IFhlbidzIGdmeF9wYXNzdGhydSBjb2RlIGRlcGVuZHMgb24gYWxs
IG9mIHRoZXNlIGZhY3RvcnMuICBBcyB0aGUgY29kZQo+ID4gPiBzdGFuZHMsIGlmIHlvdSB1c2Ug
Z2Z4X3Bhc3N0aHJ1IG9uIGEgc2Vjb25kYXJ5IGNhcmQsIGl0IHdpbGwgc3RpbGwgY29weQo+ID4g
PiB0aGUgdmJpb3MgZnJvbSB0aGUgcHJpbWFyeSBjYXJkIChhcyBpdCBzaW1wbHkgcmVhZHMgbWVt
b3J5IGZyb20KPiA+ID4gMHhjMDAwMCksIGFuZCBkaXJlY3RseSBtYXAgaW8gcG9ydHMgYW5kIGxv
dyBtZW1vcnkgYXJlYXMgdG8gdGhvc2UgdXNlZAo+ID4gPiBieSB0aGUgcHJpbWFyeSBjYXJkIGlu
IHRoZSBob3N0IHN5c3RlbS4gIEluIHRoaXMgY2FzZSB0aGUgZ3Vlc3Qgd2lsbAo+ID4gPiBhbG1v
c3QgY2VydGFpbmx5IG5ldmVyIGdldCBwYXN0IGV4ZWN1dGluZyBST01CSU9TLCBhbmQgdGhlIGhv
c3QgbWF5IG9yCj4gPiA+IG1heSBub3QgbG9jayB1cCBvciBleHBlcmllbmNlICdpc3N1ZXMnLgo+
ID4gCj4gPiBUaGlzIHdpbGwgZG8gdGhlIHRyaWNrIHdpdGggc2Vjb25kYXJ5IGNhcmQgKHJlcGxh
Y2UgcGF0aCB0byBWR0EgQklPUyk6Cj4gPiAKPiA+IC0tLSB4ZW4tdW5zdGFibGUuaGcud29ya2lu
Zy90b29scy9pb2VtdS1yZW1vdGUvaHcvcHQtZ3JhcGhpY3MuYyAyMDEyLTAxLTI1Cj4gPiAyMDoy
NjozNy45Mjc2NTQ4OTAgKzAxMDAKPiA+ICsrKyB4ZW4tdW5zdGFibGUuaGcud29ya2luZy5nZW5l
cmljL3Rvb2xzL2lvZW11LXJlbW90ZS9ody9wdC1ncmFwaGljcy5jCj4gPiAyMDExLTA3LTMwIDEz
OjU3OjU3LjM0NzM5NjA5NSArMDIwMAo+ID4gQEAgLTQ4NywxMCArNDg3LDEwIEBACj4gPiAgewo+
ID4gICAgICBpbnQgZmQ7Cj4gPiAgICAgIHVpbnQzMl90IGJpb3Nfc2l6ZSA9IDA7Cj4gPiAtICAg
IHVpbnQzMl90IHN0YXJ0ID0gMDsKPiA+ICsgICAgdWludDMyX3Qgc3RhcnQgPSAweEMwMDAwOwo+
ID4gICAgICB1aW50MTZfdCBtYWdpYyA9IDA7Cj4gPiAKPiA+IC0gICAgaWYgKCAoZmQgPSBvcGVu
KCIvbGliL2Zpcm13YXJlL0FTVVMuSEQ2ODUwLjEwMjQuMTAxMDA3LmJpbiIsCj4gPiBPX1JET05M
WSkpIDwgMCApCj4gPiArICAgIGlmICggKGZkID0gb3BlbigiL2Rldi9tZW0iLCBPX1JET05MWSkp
IDwgMCApCj4gPiAgICAgIHsKPiA+ICAgICAgICAgIFBUX0xPRygiRXJyb3I6IENhbid0IG9wZW4g
L2Rldi9tZW06ICVzXG4iLCBzdHJlcnJvcihlcnJubykpOwo+ID4gICAgICAgICAgcmV0dXJuIDA7
Cj4gCj4gU29ycnksIHN3aXRjaCB0aGUgKyBhbmQgLS4KClRoaXMgd2lsbCBsb2FkIHRoZSBwcm9w
ZXIgQklPUywgYnV0IGl0IHNlZW1zIHRoaXMgd291bGRuJ3QgYmUgZW5vdWdoLgpJbiBody9wdC1n
cmFwaGljcy5jOnJlZ2lzdGVyX3ZnYV9yZWdpb25zKCksIHdlIG1hcCAxOjEgaW9wb3J0cwoweDNi
MC0weDNiYiwgMHgzYzAtMHgzZGYsIGFuZCBtZW1vcnkgYXQgMHhhMDAwMC0weGJmZmZmLgoKSWYg
aSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGVzZSBpb3BvcnRzIGFuZCBtZW1vcnkgYXJl
YXMgYXJlIGJvdW5kCnRvIHRoZSBwcmltYXJ5IHZpZGVvIGFkYXB0ZXIgaW4gdGhlIGhvc3Qgb24g
Ym9vdCBieSB0aGUgQklPUywgZGVwZW5kaW5nCm9uIHdoYXQgZGV2aWNlIHlvdSd2ZSBzZWxlY3Rl
ZCBpbiB0aGUgQklPUyBzZXR1cCBzY3JlZW4gdG8gYmUgeW91cgpwcmltYXJ5IGFkYXB0ZXIuICBU
aGVyZWZvcmUsIHlvdSBjb3VsZCBsb2FkIHRoZSBwcm9wZXIgYmlvcywgYnV0IGl0CndvdWxkIHN0
aWxsIHdyaXRlIHRvIG1lbW9yeSBhbmQgaW8gcG9ydHMgdGhhdCBhcmUgYm91bmQgdG8gdGhlIHBy
aW1hcnkKY2FyZCBpbiB0aGUgaG9zdCwgbm90IHRoZSBjYXJkIGJlaW5nIHBhc3NlZCB0aHJvdWdo
IHRvIHRoZSBndWVzdC4KCkRvZXMgdGhpcyBtYWtlIHNlbnNlPyAoT3IsIGFtIGkgbnV0cz8pCgoK
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZl
bCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3Rz
LnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:49:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20: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 1Rq9m3-0006HI-EC; Wed, 25 Jan 2012 20:48:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq9m2-0006HD-7f
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:48:54 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327524527!8334383!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28410 invoked from network); 25 Jan 2012 20:48:47 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-10.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 20:48:47 -0000
Received: (qmail 23152 invoked from network); 25 Jan 2012 21:48:46 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 21:48:46 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 21:48:42 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252052.17845.pavel@netsafe.cz>
	<1327523353.2452.38.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327523353.2452.38.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201252148.43195.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkIDI1LiBvZiBKYW51YXJ5IDIwMTIgMjE6Mjk6MTMgeW91IHdyb3RlOgo+IE9uIFdlZCwg
MjAxMi0wMS0yNSBhdCAyMDo1MiArMDEwMCwgUGF2ZWwgTWF0xJtqYSB3cm90ZToKPiA+IE9uIFdl
ZCAyNS4gb2YgSmFudWFyeSAyMDEyIDIwOjI5OjEyIFBhdmVsIE1hdMSbamEgd3JvdGU6Cj4gPiA+
IE9uIFdlZCAyNS4gb2YgSmFudWFyeSAyMDEyIDE3OjUyOjExIERvdWcgTWFnZWUgd3JvdGU6Cj4g
PiA+ID4gQWxzbywgaSBiZWxpZXZlIHlvdSBzYWlkIHRoZSBjYXJkIHlvdSdyZSB0cnlpbmcgdG8g
cGFzcyB0aHJvdWdoIGlzCj4gPiA+ID4gbm90IHRoZSBwcmltYXJ5IGNhcmQgaW4geW91ciBob3N0
IHN5c3RlbS4gIElmIHRoYXQncyB0aGUgY2FzZSwgZG9uJ3QKPiA+ID4gPiB1c2UgZ2Z4X3Bhc3N0
aHJ1IG9yIGV4cGVjdCB0byBnZXQgdGhlIHZpZGVvIGJpb3Mgd29ya2luZy4gIFRoZQo+ID4gPiA+
ICdwcmltYXJ5JyB2aWRlbyBhZGFwdGVyIG93bnMgY2VydGFpbiBpbyBwb3J0cyBhbmQgbWVtb3J5
IGFyZWFzIHRoYXQKPiA+ID4gPiBhcmUgY29uc2l0ZW50IGZyb20gbWFjaGluZSB0byBtYWNoaW5l
LiAgQWxzbywgdGhlIHN5c3RlbSB3aWxsIGNvcHkKPiA+ID4gPiB0aGUgdmJpb3MgZnJvbSB0aGUg
Y2FyZCB0byBhIGxvY2F0aW9uIGluIG1lbW9yeSAoMHhjMDAwMCkgc28gaXQgY2FuCj4gPiA+ID4g
ZXhlY3V0ZSBhdCBib290IHRpbWUuCj4gPiA+ID4gCj4gPiA+ID4gWGVuJ3MgZ2Z4X3Bhc3N0aHJ1
IGNvZGUgZGVwZW5kcyBvbiBhbGwgb2YgdGhlc2UgZmFjdG9ycy4gIEFzIHRoZSBjb2RlCj4gPiA+
ID4gc3RhbmRzLCBpZiB5b3UgdXNlIGdmeF9wYXNzdGhydSBvbiBhIHNlY29uZGFyeSBjYXJkLCBp
dCB3aWxsIHN0aWxsCj4gPiA+ID4gY29weSB0aGUgdmJpb3MgZnJvbSB0aGUgcHJpbWFyeSBjYXJk
IChhcyBpdCBzaW1wbHkgcmVhZHMgbWVtb3J5IGZyb20KPiA+ID4gPiAweGMwMDAwKSwgYW5kIGRp
cmVjdGx5IG1hcCBpbyBwb3J0cyBhbmQgbG93IG1lbW9yeSBhcmVhcyB0byB0aG9zZQo+ID4gPiA+
IHVzZWQgYnkgdGhlIHByaW1hcnkgY2FyZCBpbiB0aGUgaG9zdCBzeXN0ZW0uICBJbiB0aGlzIGNh
c2UgdGhlIGd1ZXN0Cj4gPiA+ID4gd2lsbCBhbG1vc3QgY2VydGFpbmx5IG5ldmVyIGdldCBwYXN0
IGV4ZWN1dGluZyBST01CSU9TLCBhbmQgdGhlIGhvc3QKPiA+ID4gPiBtYXkgb3IgbWF5IG5vdCBs
b2NrIHVwIG9yIGV4cGVyaWVuY2UgJ2lzc3VlcycuCj4gPiA+IAo+ID4gPiBUaGlzIHdpbGwgZG8g
dGhlIHRyaWNrIHdpdGggc2Vjb25kYXJ5IGNhcmQgKHJlcGxhY2UgcGF0aCB0byBWR0EgQklPUyk6
Cj4gPiA+IAo+ID4gPiAtLS0geGVuLXVuc3RhYmxlLmhnLndvcmtpbmcvdG9vbHMvaW9lbXUtcmVt
b3RlL2h3L3B0LWdyYXBoaWNzLmMKPiA+ID4gMjAxMi0wMS0yNSAyMDoyNjozNy45Mjc2NTQ4OTAg
KzAxMDAKPiA+ID4gKysrIHhlbi11bnN0YWJsZS5oZy53b3JraW5nLmdlbmVyaWMvdG9vbHMvaW9l
bXUtcmVtb3RlL2h3L3B0LWdyYXBoaWNzLmMKPiA+ID4gMjAxMS0wNy0zMCAxMzo1Nzo1Ny4zNDcz
OTYwOTUgKzAyMDAKPiA+ID4gQEAgLTQ4NywxMCArNDg3LDEwIEBACj4gPiA+IAo+ID4gPiAgewo+
ID4gPiAgCj4gPiA+ICAgICAgaW50IGZkOwo+ID4gPiAgICAgIHVpbnQzMl90IGJpb3Nfc2l6ZSA9
IDA7Cj4gPiA+IAo+ID4gPiAtICAgIHVpbnQzMl90IHN0YXJ0ID0gMDsKPiA+ID4gKyAgICB1aW50
MzJfdCBzdGFydCA9IDB4QzAwMDA7Cj4gPiA+IAo+ID4gPiAgICAgIHVpbnQxNl90IG1hZ2ljID0g
MDsKPiA+ID4gCj4gPiA+IC0gICAgaWYgKCAoZmQgPSBvcGVuKCIvbGliL2Zpcm13YXJlL0FTVVMu
SEQ2ODUwLjEwMjQuMTAxMDA3LmJpbiIsCj4gPiA+IE9fUkRPTkxZKSkgPCAwICkKPiA+ID4gKyAg
ICBpZiAoIChmZCA9IG9wZW4oIi9kZXYvbWVtIiwgT19SRE9OTFkpKSA8IDAgKQo+ID4gPiAKPiA+
ID4gICAgICB7Cj4gPiA+ICAgICAgCj4gPiA+ICAgICAgICAgIFBUX0xPRygiRXJyb3I6IENhbid0
IG9wZW4gL2Rldi9tZW06ICVzXG4iLCBzdHJlcnJvcihlcnJubykpOwo+ID4gPiAgICAgICAgICBy
ZXR1cm4gMDsKPiA+IAo+ID4gU29ycnksIHN3aXRjaCB0aGUgKyBhbmQgLS4KPiAKPiBUaGlzIHdp
bGwgbG9hZCB0aGUgcHJvcGVyIEJJT1MsIGJ1dCBpdCBzZWVtcyB0aGlzIHdvdWxkbid0IGJlIGVu
b3VnaC4KPiBJbiBody9wdC1ncmFwaGljcy5jOnJlZ2lzdGVyX3ZnYV9yZWdpb25zKCksIHdlIG1h
cCAxOjEgaW9wb3J0cwo+IDB4M2IwLTB4M2JiLCAweDNjMC0weDNkZiwgYW5kIG1lbW9yeSBhdCAw
eGEwMDAwLTB4YmZmZmYuCj4gCj4gSWYgaSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGVz
ZSBpb3BvcnRzIGFuZCBtZW1vcnkgYXJlYXMgYXJlIGJvdW5kCj4gdG8gdGhlIHByaW1hcnkgdmlk
ZW8gYWRhcHRlciBpbiB0aGUgaG9zdCBvbiBib290IGJ5IHRoZSBCSU9TLCBkZXBlbmRpbmcKPiBv
biB3aGF0IGRldmljZSB5b3UndmUgc2VsZWN0ZWQgaW4gdGhlIEJJT1Mgc2V0dXAgc2NyZWVuIHRv
IGJlIHlvdXIKPiBwcmltYXJ5IGFkYXB0ZXIuICBUaGVyZWZvcmUsIHlvdSBjb3VsZCBsb2FkIHRo
ZSBwcm9wZXIgYmlvcywgYnV0IGl0Cj4gd291bGQgc3RpbGwgd3JpdGUgdG8gbWVtb3J5IGFuZCBp
byBwb3J0cyB0aGF0IGFyZSBib3VuZCB0byB0aGUgcHJpbWFyeQo+IGNhcmQgaW4gdGhlIGhvc3Qs
IG5vdCB0aGUgY2FyZCBiZWluZyBwYXNzZWQgdGhyb3VnaCB0byB0aGUgZ3Vlc3QuCj4gCj4gRG9l
cyB0aGlzIG1ha2Ugc2Vuc2U/IChPciwgYW0gaSBudXRzPykKCkl0IG1ha2VzIHNlbnNlIGFuZCBp
dCdzIHF1aXRlIGNvbXBsaWNhdGVkLgpQcmltYXJ5IGNhcmQgaXMgImJvdW5kIiB0byB0aG9zZSBw
b3J0cyBieSBQQ0kgYnJpZGdlLiBXaGVuIHlvdSBhY2Nlc3MgbGVnYWN5IApJTyBwb3J0IHRoZSBQ
Q0kgd2lsbCBleGFtaW5lIGFsbCBicmlkZ2VzIGxvb2tpbmcgZm9yIFZHQSBFbmFibGUgYml0IGlu
IHRoZSAKQnJpZGdlIENvbnRyb2wgcmVnaXN0ZXIgYW5kIHBhc3MgdGhlIGNhbGwgdG8gc3VjaCBz
dWNoIGJyaWRnZS4gU28gdGhlcmUgc2hvdWxkIApiZSBsaW51eCBzeXNjYWxsIHRvIHZnYWFyYiBi
ZWZvcmUgYW5kIGFmdGVyIGVhY2ggaW9wb3J0IGFjY2VzcyB3aGljaCB3aWxsIHNldCAKYW5kIHVu
c2V0IHRoZSBiaXQgZm9yIHJpZ2h0IGNhcmQncyBicmlkZ2UuCkJ1dCB0aGlzIHNldHVwIHdvcmtz
IGFueXdheSEgV2luZG93cyBkcml2ZXIgZG9lc24ndCBhY2Nlc3MgaW9wb3J0cy4gSnVzdCBWR0Eg
CkJJT1MgZG9lcy4gSXQgbWVhbnMgbG9hZGluZyB0aGUgQklPUyB3aWxsIG1lc3MgaW1hZ2Ugb24g
cHJpbWFyeSBjYXJkLgpJbiB0aGUgZW5kIEknbSBhYmxlIHRvIGJvb3QgdGhyZWUgdmlydHVhbCBt
YWNoaW5lcyBhbGwgd2l0aCBwYXNzZWQgKEFNRCkgVkdBLgotLSAKUGF2ZWwgTWF0ZWphCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:49:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20: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 1Rq9m3-0006HI-EC; Wed, 25 Jan 2012 20:48:55 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq9m2-0006HD-7f
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:48:54 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327524527!8334383!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28410 invoked from network); 25 Jan 2012 20:48:47 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-10.tower-21.messagelabs.com with SMTP;
	25 Jan 2012 20:48:47 -0000
Received: (qmail 23152 invoked from network); 25 Jan 2012 21:48:46 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 21:48:46 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 21:48:42 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252052.17845.pavel@netsafe.cz>
	<1327523353.2452.38.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327523353.2452.38.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201252148.43195.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkIDI1LiBvZiBKYW51YXJ5IDIwMTIgMjE6Mjk6MTMgeW91IHdyb3RlOgo+IE9uIFdlZCwg
MjAxMi0wMS0yNSBhdCAyMDo1MiArMDEwMCwgUGF2ZWwgTWF0xJtqYSB3cm90ZToKPiA+IE9uIFdl
ZCAyNS4gb2YgSmFudWFyeSAyMDEyIDIwOjI5OjEyIFBhdmVsIE1hdMSbamEgd3JvdGU6Cj4gPiA+
IE9uIFdlZCAyNS4gb2YgSmFudWFyeSAyMDEyIDE3OjUyOjExIERvdWcgTWFnZWUgd3JvdGU6Cj4g
PiA+ID4gQWxzbywgaSBiZWxpZXZlIHlvdSBzYWlkIHRoZSBjYXJkIHlvdSdyZSB0cnlpbmcgdG8g
cGFzcyB0aHJvdWdoIGlzCj4gPiA+ID4gbm90IHRoZSBwcmltYXJ5IGNhcmQgaW4geW91ciBob3N0
IHN5c3RlbS4gIElmIHRoYXQncyB0aGUgY2FzZSwgZG9uJ3QKPiA+ID4gPiB1c2UgZ2Z4X3Bhc3N0
aHJ1IG9yIGV4cGVjdCB0byBnZXQgdGhlIHZpZGVvIGJpb3Mgd29ya2luZy4gIFRoZQo+ID4gPiA+
ICdwcmltYXJ5JyB2aWRlbyBhZGFwdGVyIG93bnMgY2VydGFpbiBpbyBwb3J0cyBhbmQgbWVtb3J5
IGFyZWFzIHRoYXQKPiA+ID4gPiBhcmUgY29uc2l0ZW50IGZyb20gbWFjaGluZSB0byBtYWNoaW5l
LiAgQWxzbywgdGhlIHN5c3RlbSB3aWxsIGNvcHkKPiA+ID4gPiB0aGUgdmJpb3MgZnJvbSB0aGUg
Y2FyZCB0byBhIGxvY2F0aW9uIGluIG1lbW9yeSAoMHhjMDAwMCkgc28gaXQgY2FuCj4gPiA+ID4g
ZXhlY3V0ZSBhdCBib290IHRpbWUuCj4gPiA+ID4gCj4gPiA+ID4gWGVuJ3MgZ2Z4X3Bhc3N0aHJ1
IGNvZGUgZGVwZW5kcyBvbiBhbGwgb2YgdGhlc2UgZmFjdG9ycy4gIEFzIHRoZSBjb2RlCj4gPiA+
ID4gc3RhbmRzLCBpZiB5b3UgdXNlIGdmeF9wYXNzdGhydSBvbiBhIHNlY29uZGFyeSBjYXJkLCBp
dCB3aWxsIHN0aWxsCj4gPiA+ID4gY29weSB0aGUgdmJpb3MgZnJvbSB0aGUgcHJpbWFyeSBjYXJk
IChhcyBpdCBzaW1wbHkgcmVhZHMgbWVtb3J5IGZyb20KPiA+ID4gPiAweGMwMDAwKSwgYW5kIGRp
cmVjdGx5IG1hcCBpbyBwb3J0cyBhbmQgbG93IG1lbW9yeSBhcmVhcyB0byB0aG9zZQo+ID4gPiA+
IHVzZWQgYnkgdGhlIHByaW1hcnkgY2FyZCBpbiB0aGUgaG9zdCBzeXN0ZW0uICBJbiB0aGlzIGNh
c2UgdGhlIGd1ZXN0Cj4gPiA+ID4gd2lsbCBhbG1vc3QgY2VydGFpbmx5IG5ldmVyIGdldCBwYXN0
IGV4ZWN1dGluZyBST01CSU9TLCBhbmQgdGhlIGhvc3QKPiA+ID4gPiBtYXkgb3IgbWF5IG5vdCBs
b2NrIHVwIG9yIGV4cGVyaWVuY2UgJ2lzc3VlcycuCj4gPiA+IAo+ID4gPiBUaGlzIHdpbGwgZG8g
dGhlIHRyaWNrIHdpdGggc2Vjb25kYXJ5IGNhcmQgKHJlcGxhY2UgcGF0aCB0byBWR0EgQklPUyk6
Cj4gPiA+IAo+ID4gPiAtLS0geGVuLXVuc3RhYmxlLmhnLndvcmtpbmcvdG9vbHMvaW9lbXUtcmVt
b3RlL2h3L3B0LWdyYXBoaWNzLmMKPiA+ID4gMjAxMi0wMS0yNSAyMDoyNjozNy45Mjc2NTQ4OTAg
KzAxMDAKPiA+ID4gKysrIHhlbi11bnN0YWJsZS5oZy53b3JraW5nLmdlbmVyaWMvdG9vbHMvaW9l
bXUtcmVtb3RlL2h3L3B0LWdyYXBoaWNzLmMKPiA+ID4gMjAxMS0wNy0zMCAxMzo1Nzo1Ny4zNDcz
OTYwOTUgKzAyMDAKPiA+ID4gQEAgLTQ4NywxMCArNDg3LDEwIEBACj4gPiA+IAo+ID4gPiAgewo+
ID4gPiAgCj4gPiA+ICAgICAgaW50IGZkOwo+ID4gPiAgICAgIHVpbnQzMl90IGJpb3Nfc2l6ZSA9
IDA7Cj4gPiA+IAo+ID4gPiAtICAgIHVpbnQzMl90IHN0YXJ0ID0gMDsKPiA+ID4gKyAgICB1aW50
MzJfdCBzdGFydCA9IDB4QzAwMDA7Cj4gPiA+IAo+ID4gPiAgICAgIHVpbnQxNl90IG1hZ2ljID0g
MDsKPiA+ID4gCj4gPiA+IC0gICAgaWYgKCAoZmQgPSBvcGVuKCIvbGliL2Zpcm13YXJlL0FTVVMu
SEQ2ODUwLjEwMjQuMTAxMDA3LmJpbiIsCj4gPiA+IE9fUkRPTkxZKSkgPCAwICkKPiA+ID4gKyAg
ICBpZiAoIChmZCA9IG9wZW4oIi9kZXYvbWVtIiwgT19SRE9OTFkpKSA8IDAgKQo+ID4gPiAKPiA+
ID4gICAgICB7Cj4gPiA+ICAgICAgCj4gPiA+ICAgICAgICAgIFBUX0xPRygiRXJyb3I6IENhbid0
IG9wZW4gL2Rldi9tZW06ICVzXG4iLCBzdHJlcnJvcihlcnJubykpOwo+ID4gPiAgICAgICAgICBy
ZXR1cm4gMDsKPiA+IAo+ID4gU29ycnksIHN3aXRjaCB0aGUgKyBhbmQgLS4KPiAKPiBUaGlzIHdp
bGwgbG9hZCB0aGUgcHJvcGVyIEJJT1MsIGJ1dCBpdCBzZWVtcyB0aGlzIHdvdWxkbid0IGJlIGVu
b3VnaC4KPiBJbiBody9wdC1ncmFwaGljcy5jOnJlZ2lzdGVyX3ZnYV9yZWdpb25zKCksIHdlIG1h
cCAxOjEgaW9wb3J0cwo+IDB4M2IwLTB4M2JiLCAweDNjMC0weDNkZiwgYW5kIG1lbW9yeSBhdCAw
eGEwMDAwLTB4YmZmZmYuCj4gCj4gSWYgaSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGVz
ZSBpb3BvcnRzIGFuZCBtZW1vcnkgYXJlYXMgYXJlIGJvdW5kCj4gdG8gdGhlIHByaW1hcnkgdmlk
ZW8gYWRhcHRlciBpbiB0aGUgaG9zdCBvbiBib290IGJ5IHRoZSBCSU9TLCBkZXBlbmRpbmcKPiBv
biB3aGF0IGRldmljZSB5b3UndmUgc2VsZWN0ZWQgaW4gdGhlIEJJT1Mgc2V0dXAgc2NyZWVuIHRv
IGJlIHlvdXIKPiBwcmltYXJ5IGFkYXB0ZXIuICBUaGVyZWZvcmUsIHlvdSBjb3VsZCBsb2FkIHRo
ZSBwcm9wZXIgYmlvcywgYnV0IGl0Cj4gd291bGQgc3RpbGwgd3JpdGUgdG8gbWVtb3J5IGFuZCBp
byBwb3J0cyB0aGF0IGFyZSBib3VuZCB0byB0aGUgcHJpbWFyeQo+IGNhcmQgaW4gdGhlIGhvc3Qs
IG5vdCB0aGUgY2FyZCBiZWluZyBwYXNzZWQgdGhyb3VnaCB0byB0aGUgZ3Vlc3QuCj4gCj4gRG9l
cyB0aGlzIG1ha2Ugc2Vuc2U/IChPciwgYW0gaSBudXRzPykKCkl0IG1ha2VzIHNlbnNlIGFuZCBp
dCdzIHF1aXRlIGNvbXBsaWNhdGVkLgpQcmltYXJ5IGNhcmQgaXMgImJvdW5kIiB0byB0aG9zZSBw
b3J0cyBieSBQQ0kgYnJpZGdlLiBXaGVuIHlvdSBhY2Nlc3MgbGVnYWN5IApJTyBwb3J0IHRoZSBQ
Q0kgd2lsbCBleGFtaW5lIGFsbCBicmlkZ2VzIGxvb2tpbmcgZm9yIFZHQSBFbmFibGUgYml0IGlu
IHRoZSAKQnJpZGdlIENvbnRyb2wgcmVnaXN0ZXIgYW5kIHBhc3MgdGhlIGNhbGwgdG8gc3VjaCBz
dWNoIGJyaWRnZS4gU28gdGhlcmUgc2hvdWxkIApiZSBsaW51eCBzeXNjYWxsIHRvIHZnYWFyYiBi
ZWZvcmUgYW5kIGFmdGVyIGVhY2ggaW9wb3J0IGFjY2VzcyB3aGljaCB3aWxsIHNldCAKYW5kIHVu
c2V0IHRoZSBiaXQgZm9yIHJpZ2h0IGNhcmQncyBicmlkZ2UuCkJ1dCB0aGlzIHNldHVwIHdvcmtz
IGFueXdheSEgV2luZG93cyBkcml2ZXIgZG9lc24ndCBhY2Nlc3MgaW9wb3J0cy4gSnVzdCBWR0Eg
CkJJT1MgZG9lcy4gSXQgbWVhbnMgbG9hZGluZyB0aGUgQklPUyB3aWxsIG1lc3MgaW1hZ2Ugb24g
cHJpbWFyeSBjYXJkLgpJbiB0aGUgZW5kIEknbSBhYmxlIHRvIGJvb3QgdGhyZWUgdmlydHVhbCBt
YWNoaW5lcyBhbGwgd2l0aCBwYXNzZWQgKEFNRCkgVkdBLgotLSAKUGF2ZWwgTWF0ZWphCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:49:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq9mR-0006It-0k; Wed, 25 Jan 2012 20:49:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rq9mP-0006IY-Hz
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:49:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327524422!50064603!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15253 invoked from network); 25 Jan 2012 20:47:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 20:47:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q0PKn9Vp005242
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 20:49:10 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
	q0PKn96a016252
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 20:49:09 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0PKn89j016128; Wed, 25 Jan 2012 14:49:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 12:49:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 74402401A3; Wed, 25 Jan 2012 15:46:52 -0500 (EST)
Date: Wed, 25 Jan 2012 15:46:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120125204652.GA21284@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327485333.24561.232.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F206AC6.00AD,ss=1,re=0.000,fgs=0
Cc: "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>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 09:55:33AM +0000, Ian Campbell wrote:
> On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> > 
> > .. snip..
> > > 
> > > and with this little patch I can get it to work:
> > 
> > I get the domU to boot but the network stops being responsive.
> > I see this in the Dom0:
> 
> Your original patch would set the version to two in the hypervisor and
> then ignore that and continue to use v1 so that isn't surprising.
> 
> > (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> > [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> > [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> > 
> > Replacing the patch with:
> > 
> > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > index 1cd94da..b4d4eac 100644
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
> >  	int rc;
> >  	struct gnttab_set_version gsv;
> >  
> > -	gsv.version = 2;
> > +	if (xen_hvm_domain())
> > +		gsv.version = 1;
> > +	else
> > +		gsv.version = 2;
> >  	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> > -	if (rc == 0) {
> > +	if (rc == 0 && gsv.version == 2) {
> >  		grant_table_version = 2;
> >  		gnttab_interface = &gnttab_v2_ops;
> >  	} else if (grant_table_version == 2) {
> > 
> > Gets me back to how it worked in Linux v3.2.
> > 
> > But that is just a band-aid fix...
> 
> The real bug is presumably either that the Linux v2 code is buggy for
> use in an HVM guest or that Xen's support for v2 in HVM guests is either
> buggy or explicitly disabled (in which case set_version should fail for
> version=2).
> 
> Is the set_version with version=1 succeeding or failing? Likewise for
> the version=2 call?

Both return 0. But version=2 returns the error in the hypervisor:

 (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)

> 
> The original error was an "unable to handle kernel NULL pointer
> dereference at" gnttab_end_foreign_access_ref_v2+0x29/0x40. The only
> plausible candidates for such an error are the array access into to
> either the gnttab_shared or grstatus arrays. Do you know which one the
> IP corresponds to?

Didn't look deeper into this than just enought to send this hastily crafted
email. Will check shortly.
> 
> On HVM for gnttab_shared we make an add_to_physmap call with
> XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> do something similar for the status array though and I don't see a
> XENMAPSPACE_* specifically for that case either in the hypervisor
> either.
> 
> Ian.
> 
> --
> 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 Jan 25 20:49:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20:49:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq9mR-0006It-0k; Wed, 25 Jan 2012 20:49:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rq9mP-0006IY-Hz
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:49:17 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327524422!50064603!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15253 invoked from network); 25 Jan 2012 20:47:03 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 20:47:03 -0000
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237])
	by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id
	q0PKn9Vp005242
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 20:49:10 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
	q0PKn96a016252
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 20:49:09 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0PKn89j016128; Wed, 25 Jan 2012 14:49:08 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 12:49:08 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 74402401A3; Wed, 25 Jan 2012 15:46:52 -0500 (EST)
Date: Wed, 25 Jan 2012 15:46:52 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120125204652.GA21284@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327485333.24561.232.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F206AC6.00AD,ss=1,re=0.000,fgs=0
Cc: "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>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 09:55:33AM +0000, Ian Campbell wrote:
> On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> > 
> > .. snip..
> > > 
> > > and with this little patch I can get it to work:
> > 
> > I get the domU to boot but the network stops being responsive.
> > I see this in the Dom0:
> 
> Your original patch would set the version to two in the hypervisor and
> then ignore that and continue to use v1 so that isn't surprising.
> 
> > (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> > [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> > [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> > 
> > Replacing the patch with:
> > 
> > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > index 1cd94da..b4d4eac 100644
> > --- a/drivers/xen/grant-table.c
> > +++ b/drivers/xen/grant-table.c
> > @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
> >  	int rc;
> >  	struct gnttab_set_version gsv;
> >  
> > -	gsv.version = 2;
> > +	if (xen_hvm_domain())
> > +		gsv.version = 1;
> > +	else
> > +		gsv.version = 2;
> >  	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> > -	if (rc == 0) {
> > +	if (rc == 0 && gsv.version == 2) {
> >  		grant_table_version = 2;
> >  		gnttab_interface = &gnttab_v2_ops;
> >  	} else if (grant_table_version == 2) {
> > 
> > Gets me back to how it worked in Linux v3.2.
> > 
> > But that is just a band-aid fix...
> 
> The real bug is presumably either that the Linux v2 code is buggy for
> use in an HVM guest or that Xen's support for v2 in HVM guests is either
> buggy or explicitly disabled (in which case set_version should fail for
> version=2).
> 
> Is the set_version with version=1 succeeding or failing? Likewise for
> the version=2 call?

Both return 0. But version=2 returns the error in the hypervisor:

 (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)

> 
> The original error was an "unable to handle kernel NULL pointer
> dereference at" gnttab_end_foreign_access_ref_v2+0x29/0x40. The only
> plausible candidates for such an error are the array access into to
> either the gnttab_shared or grstatus arrays. Do you know which one the
> IP corresponds to?

Didn't look deeper into this than just enought to send this hastily crafted
email. Will check shortly.
> 
> On HVM for gnttab_shared we make an add_to_physmap call with
> XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call to
> do something similar for the status array though and I don't see a
> XENMAPSPACE_* specifically for that case either in the hypervisor
> either.
> 
> Ian.
> 
> --
> 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 Jan 25 20:53:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq9qD-0006ZL-M2; Wed, 25 Jan 2012 20:53:13 +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 1Rq9qB-0006Z0-HA
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:53:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327524783!8621347!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17355 invoked from network); 25 Jan 2012 20:53:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 20:53:05 -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
	q0PKr1LG009495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 20:53:02 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
	q0PKr0PV006881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 20:53:00 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0PKr0FM018886; Wed, 25 Jan 2012 14:53:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 12:52:59 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9A7A7401A3; Wed, 25 Jan 2012 15:50:43 -0500 (EST)
Date: Wed, 25 Jan 2012 15:50:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20120125205043.GB21284@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.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.0A090206.4F206BAE.0059,ss=1,re=0.000,fgs=0
Cc: "ANNIE LI \(annie.li@oracle.com\)" <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 03:23:28PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Paul Durrant
> > Sent: 25 January 2012 07:17
> > To: Ian Campbell; Konrad Rzeszutek Wilk
> > Cc: annie.li@oracle.com; xen-devel@lists.xensource.com; linux-
> > kernel@vger.kernel.org
> > Subject: RE: [Xen-devel] Regressions in v3.3-rc1 introduced by
> > "xen/granttable: Grant tables V2 implementation"
> > 
> > > -----Original Message-----
> > >
> > > On HVM for gnttab_shared we make an add_to_physmap call with
> > > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call
> > > to do something similar for the status array though and I don't see a
> > > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > >
> > 
> > There is no map-space for the status pages. To map them you use the
> > standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky,
> > but that's how it is.
> > 
> 
> I fixed a bug in xen-unstable a few weeks back that prevented mapping of the status frames so I guess the bug is possibly due to trying to use gnttab 2 on 4.1, where this bug would hit, but failing to check the return code from the status mapping hypercall?

changeset:   24428:5b4b7e565ab8
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:39:14 2011 +0000
summary:     Fix grant_table v2 status mapping.

changeset:   24427:931bf1105730
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:38:32 2011 +0000
summary:     Allow VMs to query their own grant table version.


Looks like c/s 24427 needs to be in the hypervior. Hm, but that exists
in 4.1 too as 23204. Will try back-porting cs 24428 in Xen 4.1 and seeing
if that does it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:53:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rq9qD-0006ZL-M2; Wed, 25 Jan 2012 20:53:13 +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 1Rq9qB-0006Z0-HA
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:53:11 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327524783!8621347!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwNDQ5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17355 invoked from network); 25 Jan 2012 20:53:05 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-15.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 20:53:05 -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
	q0PKr1LG009495
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 20:53:02 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
	q0PKr0PV006881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 20:53:00 GMT
Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0PKr0FM018886; Wed, 25 Jan 2012 14:53:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 12:52:59 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 9A7A7401A3; Wed, 25 Jan 2012 15:50:43 -0500 (EST)
Date: Wed, 25 Jan 2012 15:50:43 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Paul Durrant <Paul.Durrant@citrix.com>
Message-ID: <20120125205043.GB21284@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.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.0A090206.4F206BAE.0059,ss=1,re=0.000,fgs=0
Cc: "ANNIE LI \(annie.li@oracle.com\)" <annie.li@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 03:23:28PM +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Paul Durrant
> > Sent: 25 January 2012 07:17
> > To: Ian Campbell; Konrad Rzeszutek Wilk
> > Cc: annie.li@oracle.com; xen-devel@lists.xensource.com; linux-
> > kernel@vger.kernel.org
> > Subject: RE: [Xen-devel] Regressions in v3.3-rc1 introduced by
> > "xen/granttable: Grant tables V2 implementation"
> > 
> > > -----Original Message-----
> > >
> > > On HVM for gnttab_shared we make an add_to_physmap call with
> > > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call
> > > to do something similar for the status array though and I don't see a
> > > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > >
> > 
> > There is no map-space for the status pages. To map them you use the
> > standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky,
> > but that's how it is.
> > 
> 
> I fixed a bug in xen-unstable a few weeks back that prevented mapping of the status frames so I guess the bug is possibly due to trying to use gnttab 2 on 4.1, where this bug would hit, but failing to check the return code from the status mapping hypercall?

changeset:   24428:5b4b7e565ab8
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:39:14 2011 +0000
summary:     Fix grant_table v2 status mapping.

changeset:   24427:931bf1105730
user:        Paul Durrant <paul.durrant@citrix.com>
date:        Sun Dec 18 14:38:32 2011 +0000
summary:     Allow VMs to query their own grant table version.


Looks like c/s 24427 needs to be in the hypervior. Hm, but that exists
in 4.1 too as 23204. Will try back-porting cs 24428 in Xen 4.1 and seeing
if that does it.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:55:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20: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 1Rq9sD-0006hn-FB; Wed, 25 Jan 2012 20:55:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq9sC-0006hL-42
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:55:16 +0000
Received: from [85.158.138.51:18545] by server-6.bemta-3.messagelabs.com id
	87/C3-31032-33C602F4; Wed, 25 Jan 2012 20:55:15 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327524914!8820127!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2049 invoked from network); 25 Jan 2012 20:55:14 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-15.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 20:55:14 -0000
Received: (qmail 23590 invoked from network); 25 Jan 2012 21:55:13 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 21:55:13 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 21:55:12 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252052.17845.pavel@netsafe.cz>
	<1327523353.2452.38.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327523353.2452.38.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201252155.12457.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkIDI1LiBvZiBKYW51YXJ5IDIwMTIgMjE6Mjk6MTMgRG91ZyBNYWdlZSB3cm90ZToKPiBP
biBXZWQsIDIwMTItMDEtMjUgYXQgMjA6NTIgKzAxMDAsIFBhdmVsIE1hdMSbamEgd3JvdGU6Cj4g
PiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAyMDoyOToxMiBQYXZlbCBNYXTEm2phIHdyb3Rl
Ogo+ID4gPiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAxNzo1MjoxMSBEb3VnIE1hZ2VlIHdy
b3RlOgo+ID4gPiA+IEFsc28sIGkgYmVsaWV2ZSB5b3Ugc2FpZCB0aGUgY2FyZCB5b3UncmUgdHJ5
aW5nIHRvIHBhc3MgdGhyb3VnaCBpcwo+ID4gPiA+IG5vdCB0aGUgcHJpbWFyeSBjYXJkIGluIHlv
dXIgaG9zdCBzeXN0ZW0uICBJZiB0aGF0J3MgdGhlIGNhc2UsIGRvbid0Cj4gPiA+ID4gdXNlIGdm
eF9wYXNzdGhydSBvciBleHBlY3QgdG8gZ2V0IHRoZSB2aWRlbyBiaW9zIHdvcmtpbmcuICBUaGUK
PiA+ID4gPiAncHJpbWFyeScgdmlkZW8gYWRhcHRlciBvd25zIGNlcnRhaW4gaW8gcG9ydHMgYW5k
IG1lbW9yeSBhcmVhcyB0aGF0Cj4gPiA+ID4gYXJlIGNvbnNpdGVudCBmcm9tIG1hY2hpbmUgdG8g
bWFjaGluZS4gIEFsc28sIHRoZSBzeXN0ZW0gd2lsbCBjb3B5Cj4gPiA+ID4gdGhlIHZiaW9zIGZy
b20gdGhlIGNhcmQgdG8gYSBsb2NhdGlvbiBpbiBtZW1vcnkgKDB4YzAwMDApIHNvIGl0IGNhbgo+
ID4gPiA+IGV4ZWN1dGUgYXQgYm9vdCB0aW1lLgo+ID4gPiA+IAo+ID4gPiA+IFhlbidzIGdmeF9w
YXNzdGhydSBjb2RlIGRlcGVuZHMgb24gYWxsIG9mIHRoZXNlIGZhY3RvcnMuICBBcyB0aGUgY29k
ZQo+ID4gPiA+IHN0YW5kcywgaWYgeW91IHVzZSBnZnhfcGFzc3RocnUgb24gYSBzZWNvbmRhcnkg
Y2FyZCwgaXQgd2lsbCBzdGlsbAo+ID4gPiA+IGNvcHkgdGhlIHZiaW9zIGZyb20gdGhlIHByaW1h
cnkgY2FyZCAoYXMgaXQgc2ltcGx5IHJlYWRzIG1lbW9yeSBmcm9tCj4gPiA+ID4gMHhjMDAwMCks
IGFuZCBkaXJlY3RseSBtYXAgaW8gcG9ydHMgYW5kIGxvdyBtZW1vcnkgYXJlYXMgdG8gdGhvc2UK
PiA+ID4gPiB1c2VkIGJ5IHRoZSBwcmltYXJ5IGNhcmQgaW4gdGhlIGhvc3Qgc3lzdGVtLiAgSW4g
dGhpcyBjYXNlIHRoZSBndWVzdAo+ID4gPiA+IHdpbGwgYWxtb3N0IGNlcnRhaW5seSBuZXZlciBn
ZXQgcGFzdCBleGVjdXRpbmcgUk9NQklPUywgYW5kIHRoZSBob3N0Cj4gPiA+ID4gbWF5IG9yIG1h
eSBub3QgbG9jayB1cCBvciBleHBlcmllbmNlICdpc3N1ZXMnLgo+ID4gPiAKPiA+ID4gVGhpcyB3
aWxsIGRvIHRoZSB0cmljayB3aXRoIHNlY29uZGFyeSBjYXJkIChyZXBsYWNlIHBhdGggdG8gVkdB
IEJJT1MpOgo+ID4gPiAKPiA+ID4gLS0tIHhlbi11bnN0YWJsZS5oZy53b3JraW5nL3Rvb2xzL2lv
ZW11LXJlbW90ZS9ody9wdC1ncmFwaGljcy5jCj4gPiA+IDIwMTItMDEtMjUgMjA6MjY6MzcuOTI3
NjU0ODkwICswMTAwCj4gPiA+ICsrKyB4ZW4tdW5zdGFibGUuaGcud29ya2luZy5nZW5lcmljL3Rv
b2xzL2lvZW11LXJlbW90ZS9ody9wdC1ncmFwaGljcy5jCj4gPiA+IDIwMTEtMDctMzAgMTM6NTc6
NTcuMzQ3Mzk2MDk1ICswMjAwCj4gPiA+IEBAIC00ODcsMTAgKzQ4NywxMCBAQAo+ID4gPiAKPiA+
ID4gIHsKPiA+ID4gIAo+ID4gPiAgICAgIGludCBmZDsKPiA+ID4gICAgICB1aW50MzJfdCBiaW9z
X3NpemUgPSAwOwo+ID4gPiAKPiA+ID4gLSAgICB1aW50MzJfdCBzdGFydCA9IDA7Cj4gPiA+ICsg
ICAgdWludDMyX3Qgc3RhcnQgPSAweEMwMDAwOwo+ID4gPiAKPiA+ID4gICAgICB1aW50MTZfdCBt
YWdpYyA9IDA7Cj4gPiA+IAo+ID4gPiAtICAgIGlmICggKGZkID0gb3BlbigiL2xpYi9maXJtd2Fy
ZS9BU1VTLkhENjg1MC4xMDI0LjEwMTAwNy5iaW4iLAo+ID4gPiBPX1JET05MWSkpIDwgMCApCj4g
PiA+ICsgICAgaWYgKCAoZmQgPSBvcGVuKCIvZGV2L21lbSIsIE9fUkRPTkxZKSkgPCAwICkKPiA+
ID4gCj4gPiA+ICAgICAgewo+ID4gPiAgICAgIAo+ID4gPiAgICAgICAgICBQVF9MT0coIkVycm9y
OiBDYW4ndCBvcGVuIC9kZXYvbWVtOiAlc1xuIiwgc3RyZXJyb3IoZXJybm8pKTsKPiA+ID4gICAg
ICAgICAgcmV0dXJuIDA7Cj4gPiAKPiA+IFNvcnJ5LCBzd2l0Y2ggdGhlICsgYW5kIC0uCj4gCj4g
VGhpcyB3aWxsIGxvYWQgdGhlIHByb3BlciBCSU9TLCBidXQgaXQgc2VlbXMgdGhpcyB3b3VsZG4n
dCBiZSBlbm91Z2guCj4gSW4gaHcvcHQtZ3JhcGhpY3MuYzpyZWdpc3Rlcl92Z2FfcmVnaW9ucygp
LCB3ZSBtYXAgMToxIGlvcG9ydHMKPiAweDNiMC0weDNiYiwgMHgzYzAtMHgzZGYsIGFuZCBtZW1v
cnkgYXQgMHhhMDAwMC0weGJmZmZmLgo+IAo+IElmIGkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3Rs
eSwgdGhlc2UgaW9wb3J0cyBhbmQgbWVtb3J5IGFyZWFzIGFyZSBib3VuZAo+IHRvIHRoZSBwcmlt
YXJ5IHZpZGVvIGFkYXB0ZXIgaW4gdGhlIGhvc3Qgb24gYm9vdCBieSB0aGUgQklPUywgZGVwZW5k
aW5nCj4gb24gd2hhdCBkZXZpY2UgeW91J3ZlIHNlbGVjdGVkIGluIHRoZSBCSU9TIHNldHVwIHNj
cmVlbiB0byBiZSB5b3VyCj4gcHJpbWFyeSBhZGFwdGVyLiAgVGhlcmVmb3JlLCB5b3UgY291bGQg
bG9hZCB0aGUgcHJvcGVyIGJpb3MsIGJ1dCBpdAo+IHdvdWxkIHN0aWxsIHdyaXRlIHRvIG1lbW9y
eSBhbmQgaW8gcG9ydHMgdGhhdCBhcmUgYm91bmQgdG8gdGhlIHByaW1hcnkKPiBjYXJkIGluIHRo
ZSBob3N0LCBub3QgdGhlIGNhcmQgYmVpbmcgcGFzc2VkIHRocm91Z2ggdG8gdGhlIGd1ZXN0Lgo+
IAo+IERvZXMgdGhpcyBtYWtlIHNlbnNlPyAoT3IsIGFtIGkgbnV0cz8pCgpUbyBzYXZlIHlvdSBz
b21lIHRpbWU6CgpMaW51eCBWR0EgYXJiaXRlcjoKaHR0cDovL2x3bi5uZXQvQXJ0aWNsZXMvMzQ2
NDA0LwoKUENJIHNwZWNpZmljYXRpb246CjQuNS4xLiBWR0EgQ29tcGF0aWJsZSBBZGRyZXNzaW5n
ClRoZSBWR0EgRW5hYmxlIGJpdCBpbiB0aGUgQnJpZGdlIENvbnRyb2wgcmVnaXN0ZXIgaXMgdXNl
ZCB0byBjb250cm9sIHJlc3BvbnNlIApieSB0aGUgYnJpZGdlIHRvIGJvdGggdGhlIFZHQSBmcmFt
ZSBidWZmZXIgYWRkcmVzc2VzIGFuZCB0byB0aGUgVkdBIHJlZ2lzdGVyIAphZGRyZXNzZXMuIElm
IGEgVkdBIGNvbXBhdGlibGUgZGV2aWNlIGlzIGxvY2F0ZWQgZG93bnN0cmVhbSBvZiBhIGJyaWRn
ZSwgdGhlIApWR0EgRW5hYmxlIGJpdCBtdXN0IGJlIHNldC4gSWYgdGhlIFZHQSBFbmFibGUgYml0
IGlzIHNldCwgdGhlIGJyaWRnZSB3aWxsIApwb3NpdGl2ZWx5IGRlY29kZSBhbmQgZm9yd2FyZCBt
ZW1vcnkgYWNjZXNzZXMgdG8gVkdBIGZyYW1lIGJ1ZmZlcgphZGRyZXNzZXMgYW5kIEkvTyBhY2Nl
c3NlcyB0byBWR0EgcmVnaXN0ZXJzIGZyb20gdGhlIHByaW1hcnkgaW50ZXJmYWNlIHRvIHRoZSAK
c2Vjb25kYXJ5IGludGVyZmFjZSAoYW5kIGJsb2NrIGZvcndhcmRpbmcgZnJvbSB0aGUgc2Vjb25k
YXJ5IHRvIHByaW1hcnkgCmludGVyZmFjZSBvZiB0aGVzZSBzYW1lIGFjY2Vzc2VzKS4gQSBicmlk
Z2UgbmV2ZXIgZm9yd2FyZHMgdHJhbnNhY3Rpb25zIHRoYXQgCmFjY2VzcyBWR0EgQklPUyBtZW1v
cnkgYWRkcmVzc2VzIChyZWdhcmRsZXNzIG9mIHRoZSBzZXR0aW5nIG9mIHRoZSBWR0EgRW5hYmxl
IApiaXQpLiBST00gY29kZSBwcm92aWRlZCBieSBQQ0kgY29tcGF0aWJsZSBkZXZpY2VzIG11c3Qg
YmUgY29waWVkIHRvIHN5c3RlbSAKbWVtb3J5IGJlZm9yZSBleGVjdXRpb24gYW5kIG1heSBiZSBt
YXBwZWQgdG8gYW55IGFkZHJlc3MgaW4gUENJIG1lbW9yeQphZGRyZXNzIHNwYWNlIHZpYSB0aGUg
RXhwYW5zaW9uIFJPTSBCYXNlIEFkZHJlc3MgcmVnaXN0ZXIgaW4gdGhlIGRldmljZeKAmXMgCmNv
bmZpZ3VyYXRpb24gaGVhZGVyLgpWR0EgbWVtb3J5IGFkZHJlc3NlcwrigKIKMEEgMDAwMGggdGhy
b3VnaCAwQiBGRkZGaApWR0EgSS9PIGFkZHJlc3NlcyAoaW5jbHVkaW5nIElTQSBhbGlhc2VzIC0g
QURbMTU6OjEwXSBhcmUgbm90IGRlY29kZWQpCuKAogpBRFs5OjowXSA9IDNCMGggdGhyb3VnaCAz
QkJoLCBhbmQgM0MwaCB0aHJvdWdoIDNERmgKLS0gClBhdmVsIE1hdGVqYQoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 20:55:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 20: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 1Rq9sD-0006hn-FB; Wed, 25 Jan 2012 20:55:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1Rq9sC-0006hL-42
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 20:55:16 +0000
Received: from [85.158.138.51:18545] by server-6.bemta-3.messagelabs.com id
	87/C3-31032-33C602F4; Wed, 25 Jan 2012 20:55:15 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327524914!8820127!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2049 invoked from network); 25 Jan 2012 20:55:14 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-15.tower-174.messagelabs.com with SMTP;
	25 Jan 2012 20:55:14 -0000
Received: (qmail 23590 invoked from network); 25 Jan 2012 21:55:13 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-104.9 required=5.0 tests=BAYES_00,RDNS_NONE,
	USER_IN_WHITELIST autolearn=no version=3.2.5
Received: from unknown (HELO lemra.localnet) (pavel@195.47.79.16)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	25 Jan 2012 21:55:13 +0100
From: Pavel =?utf-8?q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Organization: Netsafe Solutions s.r.o.
To: xen-devel@lists.xensource.com
Date: Wed, 25 Jan 2012 21:55:12 +0100
User-Agent: KMail/1.13.7 (Linux/3.3.0-rc1-00060-gc1aab02; KDE/4.6.5; x86_64; ;
	)
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252052.17845.pavel@netsafe.cz>
	<1327523353.2452.38.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327523353.2452.38.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201252155.12457.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkIDI1LiBvZiBKYW51YXJ5IDIwMTIgMjE6Mjk6MTMgRG91ZyBNYWdlZSB3cm90ZToKPiBP
biBXZWQsIDIwMTItMDEtMjUgYXQgMjA6NTIgKzAxMDAsIFBhdmVsIE1hdMSbamEgd3JvdGU6Cj4g
PiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAyMDoyOToxMiBQYXZlbCBNYXTEm2phIHdyb3Rl
Ogo+ID4gPiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAxNzo1MjoxMSBEb3VnIE1hZ2VlIHdy
b3RlOgo+ID4gPiA+IEFsc28sIGkgYmVsaWV2ZSB5b3Ugc2FpZCB0aGUgY2FyZCB5b3UncmUgdHJ5
aW5nIHRvIHBhc3MgdGhyb3VnaCBpcwo+ID4gPiA+IG5vdCB0aGUgcHJpbWFyeSBjYXJkIGluIHlv
dXIgaG9zdCBzeXN0ZW0uICBJZiB0aGF0J3MgdGhlIGNhc2UsIGRvbid0Cj4gPiA+ID4gdXNlIGdm
eF9wYXNzdGhydSBvciBleHBlY3QgdG8gZ2V0IHRoZSB2aWRlbyBiaW9zIHdvcmtpbmcuICBUaGUK
PiA+ID4gPiAncHJpbWFyeScgdmlkZW8gYWRhcHRlciBvd25zIGNlcnRhaW4gaW8gcG9ydHMgYW5k
IG1lbW9yeSBhcmVhcyB0aGF0Cj4gPiA+ID4gYXJlIGNvbnNpdGVudCBmcm9tIG1hY2hpbmUgdG8g
bWFjaGluZS4gIEFsc28sIHRoZSBzeXN0ZW0gd2lsbCBjb3B5Cj4gPiA+ID4gdGhlIHZiaW9zIGZy
b20gdGhlIGNhcmQgdG8gYSBsb2NhdGlvbiBpbiBtZW1vcnkgKDB4YzAwMDApIHNvIGl0IGNhbgo+
ID4gPiA+IGV4ZWN1dGUgYXQgYm9vdCB0aW1lLgo+ID4gPiA+IAo+ID4gPiA+IFhlbidzIGdmeF9w
YXNzdGhydSBjb2RlIGRlcGVuZHMgb24gYWxsIG9mIHRoZXNlIGZhY3RvcnMuICBBcyB0aGUgY29k
ZQo+ID4gPiA+IHN0YW5kcywgaWYgeW91IHVzZSBnZnhfcGFzc3RocnUgb24gYSBzZWNvbmRhcnkg
Y2FyZCwgaXQgd2lsbCBzdGlsbAo+ID4gPiA+IGNvcHkgdGhlIHZiaW9zIGZyb20gdGhlIHByaW1h
cnkgY2FyZCAoYXMgaXQgc2ltcGx5IHJlYWRzIG1lbW9yeSBmcm9tCj4gPiA+ID4gMHhjMDAwMCks
IGFuZCBkaXJlY3RseSBtYXAgaW8gcG9ydHMgYW5kIGxvdyBtZW1vcnkgYXJlYXMgdG8gdGhvc2UK
PiA+ID4gPiB1c2VkIGJ5IHRoZSBwcmltYXJ5IGNhcmQgaW4gdGhlIGhvc3Qgc3lzdGVtLiAgSW4g
dGhpcyBjYXNlIHRoZSBndWVzdAo+ID4gPiA+IHdpbGwgYWxtb3N0IGNlcnRhaW5seSBuZXZlciBn
ZXQgcGFzdCBleGVjdXRpbmcgUk9NQklPUywgYW5kIHRoZSBob3N0Cj4gPiA+ID4gbWF5IG9yIG1h
eSBub3QgbG9jayB1cCBvciBleHBlcmllbmNlICdpc3N1ZXMnLgo+ID4gPiAKPiA+ID4gVGhpcyB3
aWxsIGRvIHRoZSB0cmljayB3aXRoIHNlY29uZGFyeSBjYXJkIChyZXBsYWNlIHBhdGggdG8gVkdB
IEJJT1MpOgo+ID4gPiAKPiA+ID4gLS0tIHhlbi11bnN0YWJsZS5oZy53b3JraW5nL3Rvb2xzL2lv
ZW11LXJlbW90ZS9ody9wdC1ncmFwaGljcy5jCj4gPiA+IDIwMTItMDEtMjUgMjA6MjY6MzcuOTI3
NjU0ODkwICswMTAwCj4gPiA+ICsrKyB4ZW4tdW5zdGFibGUuaGcud29ya2luZy5nZW5lcmljL3Rv
b2xzL2lvZW11LXJlbW90ZS9ody9wdC1ncmFwaGljcy5jCj4gPiA+IDIwMTEtMDctMzAgMTM6NTc6
NTcuMzQ3Mzk2MDk1ICswMjAwCj4gPiA+IEBAIC00ODcsMTAgKzQ4NywxMCBAQAo+ID4gPiAKPiA+
ID4gIHsKPiA+ID4gIAo+ID4gPiAgICAgIGludCBmZDsKPiA+ID4gICAgICB1aW50MzJfdCBiaW9z
X3NpemUgPSAwOwo+ID4gPiAKPiA+ID4gLSAgICB1aW50MzJfdCBzdGFydCA9IDA7Cj4gPiA+ICsg
ICAgdWludDMyX3Qgc3RhcnQgPSAweEMwMDAwOwo+ID4gPiAKPiA+ID4gICAgICB1aW50MTZfdCBt
YWdpYyA9IDA7Cj4gPiA+IAo+ID4gPiAtICAgIGlmICggKGZkID0gb3BlbigiL2xpYi9maXJtd2Fy
ZS9BU1VTLkhENjg1MC4xMDI0LjEwMTAwNy5iaW4iLAo+ID4gPiBPX1JET05MWSkpIDwgMCApCj4g
PiA+ICsgICAgaWYgKCAoZmQgPSBvcGVuKCIvZGV2L21lbSIsIE9fUkRPTkxZKSkgPCAwICkKPiA+
ID4gCj4gPiA+ICAgICAgewo+ID4gPiAgICAgIAo+ID4gPiAgICAgICAgICBQVF9MT0coIkVycm9y
OiBDYW4ndCBvcGVuIC9kZXYvbWVtOiAlc1xuIiwgc3RyZXJyb3IoZXJybm8pKTsKPiA+ID4gICAg
ICAgICAgcmV0dXJuIDA7Cj4gPiAKPiA+IFNvcnJ5LCBzd2l0Y2ggdGhlICsgYW5kIC0uCj4gCj4g
VGhpcyB3aWxsIGxvYWQgdGhlIHByb3BlciBCSU9TLCBidXQgaXQgc2VlbXMgdGhpcyB3b3VsZG4n
dCBiZSBlbm91Z2guCj4gSW4gaHcvcHQtZ3JhcGhpY3MuYzpyZWdpc3Rlcl92Z2FfcmVnaW9ucygp
LCB3ZSBtYXAgMToxIGlvcG9ydHMKPiAweDNiMC0weDNiYiwgMHgzYzAtMHgzZGYsIGFuZCBtZW1v
cnkgYXQgMHhhMDAwMC0weGJmZmZmLgo+IAo+IElmIGkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3Rs
eSwgdGhlc2UgaW9wb3J0cyBhbmQgbWVtb3J5IGFyZWFzIGFyZSBib3VuZAo+IHRvIHRoZSBwcmlt
YXJ5IHZpZGVvIGFkYXB0ZXIgaW4gdGhlIGhvc3Qgb24gYm9vdCBieSB0aGUgQklPUywgZGVwZW5k
aW5nCj4gb24gd2hhdCBkZXZpY2UgeW91J3ZlIHNlbGVjdGVkIGluIHRoZSBCSU9TIHNldHVwIHNj
cmVlbiB0byBiZSB5b3VyCj4gcHJpbWFyeSBhZGFwdGVyLiAgVGhlcmVmb3JlLCB5b3UgY291bGQg
bG9hZCB0aGUgcHJvcGVyIGJpb3MsIGJ1dCBpdAo+IHdvdWxkIHN0aWxsIHdyaXRlIHRvIG1lbW9y
eSBhbmQgaW8gcG9ydHMgdGhhdCBhcmUgYm91bmQgdG8gdGhlIHByaW1hcnkKPiBjYXJkIGluIHRo
ZSBob3N0LCBub3QgdGhlIGNhcmQgYmVpbmcgcGFzc2VkIHRocm91Z2ggdG8gdGhlIGd1ZXN0Lgo+
IAo+IERvZXMgdGhpcyBtYWtlIHNlbnNlPyAoT3IsIGFtIGkgbnV0cz8pCgpUbyBzYXZlIHlvdSBz
b21lIHRpbWU6CgpMaW51eCBWR0EgYXJiaXRlcjoKaHR0cDovL2x3bi5uZXQvQXJ0aWNsZXMvMzQ2
NDA0LwoKUENJIHNwZWNpZmljYXRpb246CjQuNS4xLiBWR0EgQ29tcGF0aWJsZSBBZGRyZXNzaW5n
ClRoZSBWR0EgRW5hYmxlIGJpdCBpbiB0aGUgQnJpZGdlIENvbnRyb2wgcmVnaXN0ZXIgaXMgdXNl
ZCB0byBjb250cm9sIHJlc3BvbnNlIApieSB0aGUgYnJpZGdlIHRvIGJvdGggdGhlIFZHQSBmcmFt
ZSBidWZmZXIgYWRkcmVzc2VzIGFuZCB0byB0aGUgVkdBIHJlZ2lzdGVyIAphZGRyZXNzZXMuIElm
IGEgVkdBIGNvbXBhdGlibGUgZGV2aWNlIGlzIGxvY2F0ZWQgZG93bnN0cmVhbSBvZiBhIGJyaWRn
ZSwgdGhlIApWR0EgRW5hYmxlIGJpdCBtdXN0IGJlIHNldC4gSWYgdGhlIFZHQSBFbmFibGUgYml0
IGlzIHNldCwgdGhlIGJyaWRnZSB3aWxsIApwb3NpdGl2ZWx5IGRlY29kZSBhbmQgZm9yd2FyZCBt
ZW1vcnkgYWNjZXNzZXMgdG8gVkdBIGZyYW1lIGJ1ZmZlcgphZGRyZXNzZXMgYW5kIEkvTyBhY2Nl
c3NlcyB0byBWR0EgcmVnaXN0ZXJzIGZyb20gdGhlIHByaW1hcnkgaW50ZXJmYWNlIHRvIHRoZSAK
c2Vjb25kYXJ5IGludGVyZmFjZSAoYW5kIGJsb2NrIGZvcndhcmRpbmcgZnJvbSB0aGUgc2Vjb25k
YXJ5IHRvIHByaW1hcnkgCmludGVyZmFjZSBvZiB0aGVzZSBzYW1lIGFjY2Vzc2VzKS4gQSBicmlk
Z2UgbmV2ZXIgZm9yd2FyZHMgdHJhbnNhY3Rpb25zIHRoYXQgCmFjY2VzcyBWR0EgQklPUyBtZW1v
cnkgYWRkcmVzc2VzIChyZWdhcmRsZXNzIG9mIHRoZSBzZXR0aW5nIG9mIHRoZSBWR0EgRW5hYmxl
IApiaXQpLiBST00gY29kZSBwcm92aWRlZCBieSBQQ0kgY29tcGF0aWJsZSBkZXZpY2VzIG11c3Qg
YmUgY29waWVkIHRvIHN5c3RlbSAKbWVtb3J5IGJlZm9yZSBleGVjdXRpb24gYW5kIG1heSBiZSBt
YXBwZWQgdG8gYW55IGFkZHJlc3MgaW4gUENJIG1lbW9yeQphZGRyZXNzIHNwYWNlIHZpYSB0aGUg
RXhwYW5zaW9uIFJPTSBCYXNlIEFkZHJlc3MgcmVnaXN0ZXIgaW4gdGhlIGRldmljZeKAmXMgCmNv
bmZpZ3VyYXRpb24gaGVhZGVyLgpWR0EgbWVtb3J5IGFkZHJlc3NlcwrigKIKMEEgMDAwMGggdGhy
b3VnaCAwQiBGRkZGaApWR0EgSS9PIGFkZHJlc3NlcyAoaW5jbHVkaW5nIElTQSBhbGlhc2VzIC0g
QURbMTU6OjEwXSBhcmUgbm90IGRlY29kZWQpCuKAogpBRFs5OjowXSA9IDNCMGggdGhyb3VnaCAz
QkJoLCBhbmQgM0MwaCB0aHJvdWdoIDNERmgKLS0gClBhdmVsIE1hdGVqYQoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlz
dApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNv
bS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Wed Jan 25 21:06:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 21:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqA2P-0007IV-Li; Wed, 25 Jan 2012 21:05:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqA2N-0007IN-QP
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 21:05:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327525412!50065788!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAyOTY3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15048 invoked from network); 25 Jan 2012 21:03:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 21:03:33 -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
	q0PL4pC1002115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 21:04:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0PL4o7R025881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 21:04:50 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
	q0PL4nr5022737; Wed, 25 Jan 2012 15:04:49 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 13:04:49 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 051D2401A3; Wed, 25 Jan 2012 16:02:32 -0500 (EST)
Date: Wed, 25 Jan 2012 16:02:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20120125210232.GA29196@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F206E76.000C,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 08:06:12PM +0100, Carsten Schiers wrote:
> Some news: in order to prepare a clean setting, I upgraded to 3.2.1 kernel. I noticed that the load increase is
> reduced a bit, but noticably. It's only a simple test, running the DomU for 2 minutes, but the idle load is aprox.
> 
>   - 2.6.32 pvops		12-13%
>   - 3.2.1 pvops		10-11%

Yeah. I think this idue to the fix I added in xen-swiotlb to not always
do the bounce copying.

>   - 2.6.34 XenoLinux	7-8%
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 21:06:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 21:06:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqA2P-0007IV-Li; Wed, 25 Jan 2012 21:05:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqA2N-0007IN-QP
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 21:05:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327525412!50065788!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAyOTY3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15048 invoked from network); 25 Jan 2012 21:03:33 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 21:03:33 -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
	q0PL4pC1002115
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 21:04:53 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0PL4o7R025881
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 21:04:50 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
	q0PL4nr5022737; Wed, 25 Jan 2012 15:04:49 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 13:04:49 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 051D2401A3; Wed, 25 Jan 2012 16:02:32 -0500 (EST)
Date: Wed, 25 Jan 2012 16:02:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Carsten Schiers <carsten@schiers.de>
Message-ID: <20120125210232.GA29196@phenom.dumpdata.com>
References: <zarafa.4eed13dd.0c2e.0c908eda504bffd9@uhura.space.zz>
	<zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <zarafa.4f2052a4.080f.57e9c5dc2a4ae722@uhura.space.zz>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090204.4F206E76.000C,ss=1,re=0.000,fgs=0
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>,
	xen-devel <xen-devel@lists.xensource.com>, Jan Beulich <JBeulich@suse.com>,
	Sander Eikelenboom <linux@eikelenboom.it>
Subject: Re: [Xen-devel] Load increase after memory upgrade (part2)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 08:06:12PM +0100, Carsten Schiers wrote:
> Some news: in order to prepare a clean setting, I upgraded to 3.2.1 kernel. I noticed that the load increase is
> reduced a bit, but noticably. It's only a simple test, running the DomU for 2 minutes, but the idle load is aprox.
> 
>   - 2.6.32 pvops		12-13%
>   - 3.2.1 pvops		10-11%

Yeah. I think this idue to the fix I added in xen-swiotlb to not always
do the bounce copying.

>   - 2.6.34 XenoLinux	7-8%
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 21:17:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 21: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 1RqADL-0007XZ-Qw; Wed, 25 Jan 2012 21:17:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RqADK-0007U1-5O
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 21:17:06 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327526218!12519614!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18537 invoked from network); 25 Jan 2012 21:16:59 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 21:16:59 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 14:16:53 -0700
Message-ID: <4F207144.1070303@suse.com>
Date: Wed, 25 Jan 2012 14:16:52 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>	<1327511781.24561.354.camel@zakaz.uk.xensource.com>	<4F203CCC.50705@suse.com>
	<9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
	<4F2043A4.7080708@suse.com>
	<BC223C0E-DEE4-406A-81C1-0401B6A02F4D@nrl.navy.mil>
In-Reply-To: <BC223C0E-DEE4-406A-81C1-0401B6A02F4D@nrl.navy.mil>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John McDermott CIV wrote:
> Thanks, that's what I though from looking at the patch, but I am completely ignorant of the tools part of codebase.
>
> Should I report this as a separate problem? We (NRL) really like xl and want to use it. What sort of debug dumps should I make?
>   

As Ian suggested, I'd report this to Redhat bugzilla or the appropriate
fedora list.  I don't see the issue in openSUSE12.1.

Regards,
Jim

> Sincerely,
>
> John
> ----
>
>
> On Jan 25, 2012, at 1:02 PM, Jim Fehlig wrote:
>
>   
>> John McDermott CIV wrote:
>>     
>>> So I should try this patch and report back if it works?
>>>
>>>       
>> No, that patch causes the issue reported by Erin :-).  In Erin's case,
>> the vif was not connected to the bridge.  In the problem you described,
>> the vif was connected to the bridge but didn't work for other reasons.
>>
>> Regards,
>> Jim
>>
>>     
>>> On Jan 25, 2012, at 12:33 PM, Jim Fehlig wrote:
>>>
>>>
>>>       
>>>> Ian Campbell wrote:
>>>>
>>>>         
>>>>> Please don't top post.
>>>>>
>>>>> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> This problem also happens in Fedora 16. Should we be making bugzilla
>>>>>> entries for problems with Xen?
>>>>>>
>>>>>>
>>>>>>             
>>>>> There is more than one reason why networking may not work for you so
>>>>> there isn't necessarily any reason (yet) to think you are seeing the
>>>>> same issue.
>>>>>
>>>>>
>>>>>           
>>>> Yes, different issue.  I'd be really surprised if Fedora had this patch
>>>>
>>>> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
>>>>
>>>> Regards,
>>>> Jim
>>>>
>>>>         
>>> ----
>>> What is the formal meaning of the one-line program
>>> #include "/dev/tty"
>>>
>>> J.P. McDermott			building 12
>>> Code 5542			john.mcdermott@nrl.navy.mil
>>> Naval Research Laboratory	voice: +1 202.404.8301
>>> Washington, DC 20375, US	fax:   +1 202.404.7942
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>>       
>
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
>
> J.P. McDermott			building 12
> Code 5542			john.mcdermott@nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
>
>
>
>
>
>
>
>
>
>
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 21:17:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 21: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 1RqADL-0007XZ-Qw; Wed, 25 Jan 2012 21:17:07 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RqADK-0007U1-5O
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 21:17:06 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327526218!12519614!1
X-Originating-IP: [137.65.250.26]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18537 invoked from network); 25 Jan 2012 21:16:59 -0000
Received: from victor.provo.novell.com (HELO victor.provo.novell.com)
	(137.65.250.26)
	by server-3.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 21:16:59 -0000
Received: from [137.65.135.33] (prv-ext-foundry1int.gns.novell.com
	[137.65.251.240])
	by victor.provo.novell.com with ESMTP (TLS encrypted);
	Wed, 25 Jan 2012 14:16:53 -0700
Message-ID: <4F207144.1070303@suse.com>
Date: Wed, 25 Jan 2012 14:16:52 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: John McDermott CIV <john.mcdermott@nrl.navy.mil>
References: <mailman.1527.1327510060.1471.xen-devel@lists.xensource.com>	<5EB101FB-4F12-402B-8042-DDF8D8B7C241@nrl.navy.mil>	<1327511781.24561.354.camel@zakaz.uk.xensource.com>	<4F203CCC.50705@suse.com>
	<9EF3B1C1-BCD0-4DF0-B536-9B3F4DD28F6A@nrl.navy.mil>
	<4F2043A4.7080708@suse.com>
	<BC223C0E-DEE4-406A-81C1-0401B6A02F4D@nrl.navy.mil>
In-Reply-To: <BC223C0E-DEE4-406A-81C1-0401B6A02F4D@nrl.navy.mil>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] After switching from "xm" to "xl" toolstack,
 can't get Guest networking to work.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

John McDermott CIV wrote:
> Thanks, that's what I though from looking at the patch, but I am completely ignorant of the tools part of codebase.
>
> Should I report this as a separate problem? We (NRL) really like xl and want to use it. What sort of debug dumps should I make?
>   

As Ian suggested, I'd report this to Redhat bugzilla or the appropriate
fedora list.  I don't see the issue in openSUSE12.1.

Regards,
Jim

> Sincerely,
>
> John
> ----
>
>
> On Jan 25, 2012, at 1:02 PM, Jim Fehlig wrote:
>
>   
>> John McDermott CIV wrote:
>>     
>>> So I should try this patch and report back if it works?
>>>
>>>       
>> No, that patch causes the issue reported by Erin :-).  In Erin's case,
>> the vif was not connected to the bridge.  In the problem you described,
>> the vif was connected to the bridge but didn't work for other reasons.
>>
>> Regards,
>> Jim
>>
>>     
>>> On Jan 25, 2012, at 12:33 PM, Jim Fehlig wrote:
>>>
>>>
>>>       
>>>> Ian Campbell wrote:
>>>>
>>>>         
>>>>> Please don't top post.
>>>>>
>>>>> On Wed, 2012-01-25 at 17:06 +0000, John McDermott CIV wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> This problem also happens in Fedora 16. Should we be making bugzilla
>>>>>> entries for problems with Xen?
>>>>>>
>>>>>>
>>>>>>             
>>>>> There is more than one reason why networking may not work for you so
>>>>> there isn't necessarily any reason (yet) to think you are seeing the
>>>>> same issue.
>>>>>
>>>>>
>>>>>           
>>>> Yes, different issue.  I'd be really surprised if Fedora had this patch
>>>>
>>>> http://old-list-archives.xen.org/archives/html/xen-devel/2011-10/msg01790.html
>>>>
>>>> Regards,
>>>> Jim
>>>>
>>>>         
>>> ----
>>> What is the formal meaning of the one-line program
>>> #include "/dev/tty"
>>>
>>> J.P. McDermott			building 12
>>> Code 5542			john.mcdermott@nrl.navy.mil
>>> Naval Research Laboratory	voice: +1 202.404.8301
>>> Washington, DC 20375, US	fax:   +1 202.404.7942
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>>       
>
> ----
> What is the formal meaning of the one-line program
> #include "/dev/tty"
>
> J.P. McDermott			building 12
> Code 5542			john.mcdermott@nrl.navy.mil
> Naval Research Laboratory	voice: +1 202.404.8301
> Washington, DC 20375, US	fax:   +1 202.404.7942
>
>
>
>
>
>
>
>
>
>
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 21:24:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 21:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqAKc-0007tY-Nr; Wed, 25 Jan 2012 21:24:38 +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 1RqAKb-0007tT-G5
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 21:24:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327526633!57459632!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAyOTY3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28382 invoked from network); 25 Jan 2012 21:23:54 -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; 25 Jan 2012 21:23:54 -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
	q0PLOW8e024668
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 21:24:33 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
	q0PLOVtj005228
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 21:24: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
	q0PLOUs9028021; Wed, 25 Jan 2012 15:24:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 13:24:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 30A23401A3; Wed, 25 Jan 2012 16:22:14 -0500 (EST)
Date: Wed, 25 Jan 2012 16:22:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: =?utf-8?B?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?= <socketpair@gmail.com>
Message-ID: <20120125212214.GA29571@phenom.dumpdata.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
	<CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
	<20120125163910.GC23999@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120125163910.GC23999@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F207311.005E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Fwd: BUG in
	linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBKYW4gMjUsIDIwMTIgYXQgMTE6Mzk6MTBBTSAtMDUwMCwgS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIHdyb3RlOgo+IE9uIFdlZCwgSmFuIDI1LCAyMDEyIGF0IDA0OjIwOjI2UE0gKzA2MDAs
INCc0LDRgNC6INCa0L7RgNC10L3QsdC10YDQsyB3cm90ZToKPiA+IEZpcnN0LCBtYWludGFpbmVy
J3MgYWRkcmVzc2VzIChSeWFuIFdpbHNvbiA8aGFwOUBlcG9jaC5uY3NjLm1pbD4sCj4gPiBDaHJp
cyBCb29raG9sdCA8aGFwMTBAZXBvY2gubmNzYy5taWw+KSBhcmUgd3JvbmcgKHVzZXJzIHVua25v
d24gdG8KPiA+IHJlbW90ZSBtYWlsc3lzdGVtKSwgc28gcG9zdGluZyB0byB5b3U6Cj4gCj4gVGhv
c2UgYXJlIHRoZSBhdXRob3JzIG9uZXMuLiBJZiB5b3UgZG86Cj4ga29ucmFkQHBoZW5vbTp+L3dv
cmsvbGludXgkIHNjcmlwdHMvZ2V0X21haW50YWluZXIucGwgLWYgZHJpdmVycy94ZW4veGVuLXBj
aWJhY2svcGNpX3N0dWIuYwo+IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3Jh
Y2xlLmNvbT4gKHN1cHBvcnRlcjpYRU4gSFlQRVJWSVNPUiBJTi4uLixjb21taXRfc2lnbmVyOjEx
LzExPTEwMCUpCj4gSmVyZW15IEZpdHpoYXJkaW5nZSA8amVyZW15QGdvb3Aub3JnPiAoc3VwcG9y
dGVyOlhFTiBIWVBFUlZJU09SIElOLi4uLGNvbW1pdF9zaWduZXI6Mi8xMT0xOCUpCj4gSmFuIEJl
dWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPiAoY29tbWl0X3NpZ25lcjoxLzExPTklKQo+IHhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tIChvcGVuIGxpc3Q6WEVOIEhZUEVSVklTT1IgSU4uLi4p
Cj4gdmlydHVhbGl6YXRpb25AbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcgKG9wZW4gbGlzdDpY
RU4gSFlQRVJWSVNPUiBJTi4uLikKPiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIChvcGVu
IGxpc3QpCj4gCj4gPiAKPiA+IFBDSSBidXMgZm9ybWF0IHN0cmluZ3MgYXJlIHdyb25nLgo+ID4g
Cj4gPiAiJTA0eDolMDJ4OiUwMnguJWQiCj4gPiAKPiA+IHNob3VsZCBiZSB1c2VkIGluc3RlYWQg
b2YKPiA+IAo+ID4gIiUwNHg6JTAyeDolMDJ4LiUxeCIKPiAKPiBPaD8gV291bGQgeW91IGJlIHdp
bGxpbmcgdG8gY29tZSB1cCB3aXRoIGEgcGF0Y2ggd2l0aCB5b3VyIFNPQiwgcGxlYXNlPwoKQWN0
dWFsbHkgSSB0aGluayBpdCBpcyBzb21ldGhpbmcgbGlrZSB0aGlzOiBCdXQgd2Ugc3RpbGwgbmVl
ZCBzb21ldGhpbmcgZm9yIHRoZQpwcm90b2NvbC4uCgpGcm9tIGU3ZDc1MTQxMzM0MjcxMzRkMTg2
YjU4Yjg0MmVjZDZiZWRhM2JmMDMgTW9uIFNlcCAxNyAwMDowMDowMCAyMDAxCkZyb206IEtvbnJh
ZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KRGF0ZTogV2VkLCAyNSBK
YW4gMjAxMiAxNjowMDowMCAtMDUwMApTdWJqZWN0OiBbUEFUQ0hdIHhlbi9wY2lbZnJvbnR8YmFj
a106IFVzZSAlZCBpbnN0ZWFkIG9mICUxeCBmb3IgZGlzcGxheWluZwogUENJIGRldmZuLgpNSU1F
LVZlcnNpb246IDEuMApDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29u
dGVudC1UcmFuc2Zlci1FbmNvZGluZzogOGJpdAoKLi4gYXMgdGhlIHJlc3Qgb2YgdGhlIGtlcm5l
bCBpcyB1c2luZyB0aGF0IGZvcm1hdC4KClN1Z2dlc3RlZC1ieTog0JzQsNGA0Log0JrQvtGA0LXQ
vdCx0LXRgNCzIDxzb2NrZXRwYWlyQGdtYWlsLmNvbT4KU2lnbmVkLW9mZi1ieTogS29ucmFkIFJ6
ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgotLS0KIGRyaXZlcnMvcGNpL3hl
bi1wY2lmcm9udC5jICAgICAgICAgfCAgIDEwICsrKysrLS0tLS0KIGRyaXZlcnMveGVuL3hlbi1w
Y2liYWNrL3BjaV9zdHViLmMgfCAgICA4ICsrKystLS0tCiBkcml2ZXJzL3hlbi94ZW4tcGNpYmFj
ay94ZW5idXMuYyAgIHwgICAgNyArKysrLS0tCiAzIGZpbGVzIGNoYW5nZWQsIDEzIGluc2VydGlv
bnMoKyksIDEyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvcGNpL3hlbi1wY2lm
cm9udC5jIGIvZHJpdmVycy9wY2kveGVuLXBjaWZyb250LmMKaW5kZXggN2NmM2QyZi4uMTYyMDA4
OCAxMDA2NDQKLS0tIGEvZHJpdmVycy9wY2kveGVuLXBjaWZyb250LmMKKysrIGIvZHJpdmVycy9w
Y2kveGVuLXBjaWZyb250LmMKQEAgLTE4OSw3ICsxODksNyBAQCBzdGF0aWMgaW50IHBjaWZyb250
X2J1c19yZWFkKHN0cnVjdCBwY2lfYnVzICpidXMsIHVuc2lnbmVkIGludCBkZXZmbiwKIAogCWlm
ICh2ZXJib3NlX3JlcXVlc3QpCiAJCWRldl9pbmZvKCZwZGV2LT54ZGV2LT5kZXYsCi0JCQkgInJl
YWQgZGV2PSUwNHg6JTAyeDolMDJ4LiUwMXggLSBvZmZzZXQgJXggc2l6ZSAlZFxuIiwKKwkJCSAi
cmVhZCBkZXY9JTA0eDolMDJ4OiUwMnguJWQgLSBvZmZzZXQgJXggc2l6ZSAlZFxuIiwKIAkJCSBw
Y2lfZG9tYWluX25yKGJ1cyksIGJ1cy0+bnVtYmVyLCBQQ0lfU0xPVChkZXZmbiksCiAJCQkgUENJ
X0ZVTkMoZGV2Zm4pLCB3aGVyZSwgc2l6ZSk7CiAKQEAgLTIyOCw3ICsyMjgsNyBAQCBzdGF0aWMg
aW50IHBjaWZyb250X2J1c193cml0ZShzdHJ1Y3QgcGNpX2J1cyAqYnVzLCB1bnNpZ25lZCBpbnQg
ZGV2Zm4sCiAKIAlpZiAodmVyYm9zZV9yZXF1ZXN0KQogCQlkZXZfaW5mbygmcGRldi0+eGRldi0+
ZGV2LAotCQkJICJ3cml0ZSBkZXY9JTA0eDolMDJ4OiUwMnguJTAxeCAtICIKKwkJCSAid3JpdGUg
ZGV2PSUwNHg6JTAyeDolMDJ4LiVkIC0gIgogCQkJICJvZmZzZXQgJXggc2l6ZSAlZCB2YWwgJXhc
biIsCiAJCQkgcGNpX2RvbWFpbl9ucihidXMpLCBidXMtPm51bWJlciwKIAkJCSBQQ0lfU0xPVChk
ZXZmbiksIFBDSV9GVU5DKGRldmZuKSwgd2hlcmUsIHNpemUsIHZhbCk7CkBAIC00MzIsNyArNDMy
LDcgQEAgc3RhdGljIGludCBfX2RldmluaXQgcGNpZnJvbnRfc2Nhbl9idXMoc3RydWN0IHBjaWZy
b250X2RldmljZSAqcGRldiwKIAkJZCA9IHBjaV9zY2FuX3NpbmdsZV9kZXZpY2UoYiwgZGV2Zm4p
OwogCQlpZiAoZCkKIAkJCWRldl9pbmZvKCZwZGV2LT54ZGV2LT5kZXYsICJOZXcgZGV2aWNlIG9u
ICIKLQkJCQkgIiUwNHg6JTAyeDolMDJ4LiUwMnggZm91bmQuXG4iLCBkb21haW4sIGJ1cywKKwkJ
CQkgIiUwNHg6JTAyeDolMDJ4LiVkIGZvdW5kLlxuIiwgZG9tYWluLCBidXMsCiAJCQkJIFBDSV9T
TE9UKGRldmZuKSwgUENJX0ZVTkMoZGV2Zm4pKTsKIAl9CiAKQEAgLTEwNDEsNyArMTA0MSw3IEBA
IHN0YXRpYyBpbnQgcGNpZnJvbnRfZGV0YWNoX2RldmljZXMoc3RydWN0IHBjaWZyb250X2Rldmlj
ZSAqcGRldikKIAkJcGNpX2RldiA9IHBjaV9nZXRfc2xvdChwY2lfYnVzLCBQQ0lfREVWRk4oc2xv
dCwgZnVuYykpOwogCQlpZiAoIXBjaV9kZXYpIHsKIAkJCWRldl9kYmcoJnBkZXYtPnhkZXYtPmRl
diwKLQkJCQkiQ2Fubm90IGdldCBQQ0kgZGV2aWNlICUwNHg6JTAyeDolMDJ4LiUwMnhcbiIsCisJ
CQkJIkNhbm5vdCBnZXQgUENJIGRldmljZSAlMDR4OiUwMng6JTAyeC4lZFxuIiwKIAkJCQlkb21h
aW4sIGJ1cywgc2xvdCwgZnVuYyk7CiAJCQljb250aW51ZTsKIAkJfQpAQCAtMTA0OSw3ICsxMDQ5
LDcgQEAgc3RhdGljIGludCBwY2lmcm9udF9kZXRhY2hfZGV2aWNlcyhzdHJ1Y3QgcGNpZnJvbnRf
ZGV2aWNlICpwZGV2KQogCQlwY2lfZGV2X3B1dChwY2lfZGV2KTsKIAogCQlkZXZfZGJnKCZwZGV2
LT54ZGV2LT5kZXYsCi0JCQkiUENJIGRldmljZSAlMDR4OiUwMng6JTAyeC4lMDJ4IHJlbW92ZWQu
XG4iLAorCQkJIlBDSSBkZXZpY2UgJTA0eDolMDJ4OiUwMnguJWQgcmVtb3ZlZC5cbiIsCiAJCQlk
b21haW4sIGJ1cywgc2xvdCwgZnVuYyk7CiAJfQogCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94
ZW4tcGNpYmFjay9wY2lfc3R1Yi5jIGIvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNpX3N0dWIu
YwppbmRleCA2ZjYzYjlkLi4wOTdlNTM2IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW4tcGNp
YmFjay9wY2lfc3R1Yi5jCisrKyBiL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaV9zdHViLmMK
QEAgLTkxOSw3ICs5MTksNyBAQCBzdGF0aWMgaW5saW5lIGludCBzdHJfdG9fcXVpcmsoY29uc3Qg
Y2hhciAqYnVmLCBpbnQgKmRvbWFpbiwgaW50ICpidXMsIGludAogCWludCBlcnI7CiAKIAllcnIg
PQotCSAgICBzc2NhbmYoYnVmLCAiICUwNHg6JTAyeDolMDJ4LiUxeC0lMDh4OiUxeDolMDh4Iiwg
ZG9tYWluLCBidXMsIHNsb3QsCisJICAgIHNzY2FuZihidWYsICIgJTA0eDolMDJ4OiUwMnguJWQt
JTA4eDolMXg6JTA4eCIsIGRvbWFpbiwgYnVzLCBzbG90LAogCQkgICBmdW5jLCByZWcsIHNpemUs
IG1hc2spOwogCWlmIChlcnIgPT0gNykKIAkJcmV0dXJuIDA7CkBAIC05MzksNyArOTM5LDcgQEAg
c3RhdGljIGludCBwY2lzdHViX2RldmljZV9pZF9hZGQoaW50IGRvbWFpbiwgaW50IGJ1cywgaW50
IHNsb3QsIGludCBmdW5jKQogCXBjaV9kZXZfaWQtPmJ1cyA9IGJ1czsKIAlwY2lfZGV2X2lkLT5k
ZXZmbiA9IFBDSV9ERVZGTihzbG90LCBmdW5jKTsKIAotCXByX2RlYnVnKERSVl9OQU1FICI6IHdh
bnRzIHRvIHNlaXplICUwNHg6JTAyeDolMDJ4LiUwMXhcbiIsCisJcHJfZGVidWcoRFJWX05BTUUg
Ijogd2FudHMgdG8gc2VpemUgJTA0eDolMDJ4OiUwMnguJWRcbiIsCiAJCSBkb21haW4sIGJ1cywg
c2xvdCwgZnVuYyk7CiAKIAlzcGluX2xvY2tfaXJxc2F2ZSgmZGV2aWNlX2lkc19sb2NrLCBmbGFn
cyk7CkBAIC05NjksNyArOTY5LDcgQEAgc3RhdGljIGludCBwY2lzdHViX2RldmljZV9pZF9yZW1v
dmUoaW50IGRvbWFpbiwgaW50IGJ1cywgaW50IHNsb3QsIGludCBmdW5jKQogCiAJCQllcnIgPSAw
OwogCi0JCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiByZW1vdmVkICUwNHg6JTAyeDolMDJ4LiUwMXgg
ZnJvbSAiCisJCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiByZW1vdmVkICUwNHg6JTAyeDolMDJ4LiVk
IGZyb20gIgogCQkJCSAic2VpemUgbGlzdFxuIiwgZG9tYWluLCBidXMsIHNsb3QsIGZ1bmMpOwog
CQl9CiAJfQpAQCAtMTA2NCw3ICsxMDY0LDcgQEAgc3RhdGljIHNzaXplX3QgcGNpc3R1Yl9zbG90
X3Nob3coc3RydWN0IGRldmljZV9kcml2ZXIgKmRydiwgY2hhciAqYnVmKQogCQkJYnJlYWs7CiAK
IAkJY291bnQgKz0gc2NucHJpbnRmKGJ1ZiArIGNvdW50LCBQQUdFX1NJWkUgLSBjb3VudCwKLQkJ
CQkgICAiJTA0eDolMDJ4OiUwMnguJTAxeFxuIiwKKwkJCQkgICAiJTA0eDolMDJ4OiUwMnguJWRc
biIsCiAJCQkJICAgcGNpX2Rldl9pZC0+ZG9tYWluLCBwY2lfZGV2X2lkLT5idXMsCiAJCQkJICAg
UENJX1NMT1QocGNpX2Rldl9pZC0+ZGV2Zm4pLAogCQkJCSAgIFBDSV9GVU5DKHBjaV9kZXZfaWQt
PmRldmZuKSk7CmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94ZW4tcGNpYmFjay94ZW5idXMuYyBi
L2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3hlbmJ1cy5jCmluZGV4IGQ1ZGNmOGQuLjliMmY3MDUg
MTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3hlbmJ1cy5jCisrKyBiL2RyaXZl
cnMveGVuL3hlbi1wY2liYWNrL3hlbmJ1cy5jCkBAIC0yMDYsOCArMjA2LDkgQEAgc3RhdGljIGlu
dCB4ZW5fcGNpYmtfcHVibGlzaF9wY2lfZGV2KHN0cnVjdCB4ZW5fcGNpYmtfZGV2aWNlICpwZGV2
LAogCQlnb3RvIG91dDsKIAl9CiAKKwkvKiBUT0RPOiBpbXBsZW1lbnQgZmVhdHVyZS11c2UtZGVj
aW1hbC1mb3ItZGV2Zm4gKi8KIAllcnIgPSB4ZW5idXNfcHJpbnRmKFhCVF9OSUwsIHBkZXYtPnhk
ZXYtPm5vZGVuYW1lLCBzdHIsCi0JCQkgICAgIiUwNHg6JTAyeDolMDJ4LiUwMngiLCBkb21haW4s
IGJ1cywKKwkJCSAgICAiJTA0eDolMDJ4OiUwMnguJTF4IiwgZG9tYWluLCBidXMsCiAJCQkgICAg
UENJX1NMT1QoZGV2Zm4pLCBQQ0lfRlVOQyhkZXZmbikpOwogCiBvdXQ6CkBAIC0yMjksNyArMjMw
LDcgQEAgc3RhdGljIGludCB4ZW5fcGNpYmtfZXhwb3J0X2RldmljZShzdHJ1Y3QgeGVuX3BjaWJr
X2RldmljZSAqcGRldiwKIAkJZXJyID0gLUVJTlZBTDsKIAkJeGVuYnVzX2Rldl9mYXRhbChwZGV2
LT54ZGV2LCBlcnIsCiAJCQkJICJDb3VsZG4ndCBsb2NhdGUgUENJIGRldmljZSAiCi0JCQkJICIo
JTA0eDolMDJ4OiUwMnguJTAxeCkhICIKKwkJCQkgIiglMDR4OiUwMng6JTAyeC4lZCkhICIKIAkJ
CQkgInBlcmhhcHMgYWxyZWFkeSBpbi11c2U/IiwKIAkJCQkgZG9tYWluLCBidXMsIHNsb3QsIGZ1
bmMpOwogCQlnb3RvIG91dDsKQEAgLTI3NCw3ICsyNzUsNyBAQCBzdGF0aWMgaW50IHhlbl9wY2li
a19yZW1vdmVfZGV2aWNlKHN0cnVjdCB4ZW5fcGNpYmtfZGV2aWNlICpwZGV2LAogCWlmICghZGV2
KSB7CiAJCWVyciA9IC1FSU5WQUw7CiAJCWRldl9kYmcoJnBkZXYtPnhkZXYtPmRldiwgIkNvdWxk
bid0IGxvY2F0ZSBQQ0kgZGV2aWNlICIKLQkJCSIoJTA0eDolMDJ4OiUwMnguJTAxeCkhIG5vdCBv
d25lZCBieSB0aGlzIGRvbWFpblxuIiwKKwkJCSIoJTA0eDolMDJ4OiUwMnguJWQpISBub3Qgb3du
ZWQgYnkgdGhpcyBkb21haW5cbiIsCiAJCQlkb21haW4sIGJ1cywgc2xvdCwgZnVuYyk7CiAJCWdv
dG8gb3V0OwogCX0KLS0gCjEuNy43LjUKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 21:24:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 21:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqAKc-0007tY-Nr; Wed, 25 Jan 2012 21:24:38 +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 1RqAKb-0007tT-G5
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 21:24:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327526633!57459632!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTAyOTY3\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28382 invoked from network); 25 Jan 2012 21:23:54 -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; 25 Jan 2012 21:23:54 -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
	q0PLOW8e024668
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Wed, 25 Jan 2012 21:24:33 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
	q0PLOVtj005228
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 25 Jan 2012 21:24: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
	q0PLOUs9028021; Wed, 25 Jan 2012 15:24:30 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Wed, 25 Jan 2012 13:24:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 30A23401A3; Wed, 25 Jan 2012 16:22:14 -0500 (EST)
Date: Wed, 25 Jan 2012 16:22:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: =?utf-8?B?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?= <socketpair@gmail.com>
Message-ID: <20120125212214.GA29571@phenom.dumpdata.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
	<CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
	<20120125163910.GC23999@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120125163910.GC23999@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090201.4F207311.005E,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Fwd: BUG in
	linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCBKYW4gMjUsIDIwMTIgYXQgMTE6Mzk6MTBBTSAtMDUwMCwgS29ucmFkIFJ6ZXN6dXRl
ayBXaWxrIHdyb3RlOgo+IE9uIFdlZCwgSmFuIDI1LCAyMDEyIGF0IDA0OjIwOjI2UE0gKzA2MDAs
INCc0LDRgNC6INCa0L7RgNC10L3QsdC10YDQsyB3cm90ZToKPiA+IEZpcnN0LCBtYWludGFpbmVy
J3MgYWRkcmVzc2VzIChSeWFuIFdpbHNvbiA8aGFwOUBlcG9jaC5uY3NjLm1pbD4sCj4gPiBDaHJp
cyBCb29raG9sdCA8aGFwMTBAZXBvY2gubmNzYy5taWw+KSBhcmUgd3JvbmcgKHVzZXJzIHVua25v
d24gdG8KPiA+IHJlbW90ZSBtYWlsc3lzdGVtKSwgc28gcG9zdGluZyB0byB5b3U6Cj4gCj4gVGhv
c2UgYXJlIHRoZSBhdXRob3JzIG9uZXMuLiBJZiB5b3UgZG86Cj4ga29ucmFkQHBoZW5vbTp+L3dv
cmsvbGludXgkIHNjcmlwdHMvZ2V0X21haW50YWluZXIucGwgLWYgZHJpdmVycy94ZW4veGVuLXBj
aWJhY2svcGNpX3N0dWIuYwo+IEtvbnJhZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3Jh
Y2xlLmNvbT4gKHN1cHBvcnRlcjpYRU4gSFlQRVJWSVNPUiBJTi4uLixjb21taXRfc2lnbmVyOjEx
LzExPTEwMCUpCj4gSmVyZW15IEZpdHpoYXJkaW5nZSA8amVyZW15QGdvb3Aub3JnPiAoc3VwcG9y
dGVyOlhFTiBIWVBFUlZJU09SIElOLi4uLGNvbW1pdF9zaWduZXI6Mi8xMT0xOCUpCj4gSmFuIEJl
dWxpY2ggPGpiZXVsaWNoQHN1c2UuY29tPiAoY29tbWl0X3NpZ25lcjoxLzExPTklKQo+IHhlbi1k
ZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tIChvcGVuIGxpc3Q6WEVOIEhZUEVSVklTT1IgSU4uLi4p
Cj4gdmlydHVhbGl6YXRpb25AbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmcgKG9wZW4gbGlzdDpY
RU4gSFlQRVJWSVNPUiBJTi4uLikKPiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIChvcGVu
IGxpc3QpCj4gCj4gPiAKPiA+IFBDSSBidXMgZm9ybWF0IHN0cmluZ3MgYXJlIHdyb25nLgo+ID4g
Cj4gPiAiJTA0eDolMDJ4OiUwMnguJWQiCj4gPiAKPiA+IHNob3VsZCBiZSB1c2VkIGluc3RlYWQg
b2YKPiA+IAo+ID4gIiUwNHg6JTAyeDolMDJ4LiUxeCIKPiAKPiBPaD8gV291bGQgeW91IGJlIHdp
bGxpbmcgdG8gY29tZSB1cCB3aXRoIGEgcGF0Y2ggd2l0aCB5b3VyIFNPQiwgcGxlYXNlPwoKQWN0
dWFsbHkgSSB0aGluayBpdCBpcyBzb21ldGhpbmcgbGlrZSB0aGlzOiBCdXQgd2Ugc3RpbGwgbmVl
ZCBzb21ldGhpbmcgZm9yIHRoZQpwcm90b2NvbC4uCgpGcm9tIGU3ZDc1MTQxMzM0MjcxMzRkMTg2
YjU4Yjg0MmVjZDZiZWRhM2JmMDMgTW9uIFNlcCAxNyAwMDowMDowMCAyMDAxCkZyb206IEtvbnJh
ZCBSemVzenV0ZWsgV2lsayA8a29ucmFkLndpbGtAb3JhY2xlLmNvbT4KRGF0ZTogV2VkLCAyNSBK
YW4gMjAxMiAxNjowMDowMCAtMDUwMApTdWJqZWN0OiBbUEFUQ0hdIHhlbi9wY2lbZnJvbnR8YmFj
a106IFVzZSAlZCBpbnN0ZWFkIG9mICUxeCBmb3IgZGlzcGxheWluZwogUENJIGRldmZuLgpNSU1F
LVZlcnNpb246IDEuMApDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgKQ29u
dGVudC1UcmFuc2Zlci1FbmNvZGluZzogOGJpdAoKLi4gYXMgdGhlIHJlc3Qgb2YgdGhlIGtlcm5l
bCBpcyB1c2luZyB0aGF0IGZvcm1hdC4KClN1Z2dlc3RlZC1ieTog0JzQsNGA0Log0JrQvtGA0LXQ
vdCx0LXRgNCzIDxzb2NrZXRwYWlyQGdtYWlsLmNvbT4KU2lnbmVkLW9mZi1ieTogS29ucmFkIFJ6
ZXN6dXRlayBXaWxrIDxrb25yYWQud2lsa0BvcmFjbGUuY29tPgotLS0KIGRyaXZlcnMvcGNpL3hl
bi1wY2lmcm9udC5jICAgICAgICAgfCAgIDEwICsrKysrLS0tLS0KIGRyaXZlcnMveGVuL3hlbi1w
Y2liYWNrL3BjaV9zdHViLmMgfCAgICA4ICsrKystLS0tCiBkcml2ZXJzL3hlbi94ZW4tcGNpYmFj
ay94ZW5idXMuYyAgIHwgICAgNyArKysrLS0tCiAzIGZpbGVzIGNoYW5nZWQsIDEzIGluc2VydGlv
bnMoKyksIDEyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvcGNpL3hlbi1wY2lm
cm9udC5jIGIvZHJpdmVycy9wY2kveGVuLXBjaWZyb250LmMKaW5kZXggN2NmM2QyZi4uMTYyMDA4
OCAxMDA2NDQKLS0tIGEvZHJpdmVycy9wY2kveGVuLXBjaWZyb250LmMKKysrIGIvZHJpdmVycy9w
Y2kveGVuLXBjaWZyb250LmMKQEAgLTE4OSw3ICsxODksNyBAQCBzdGF0aWMgaW50IHBjaWZyb250
X2J1c19yZWFkKHN0cnVjdCBwY2lfYnVzICpidXMsIHVuc2lnbmVkIGludCBkZXZmbiwKIAogCWlm
ICh2ZXJib3NlX3JlcXVlc3QpCiAJCWRldl9pbmZvKCZwZGV2LT54ZGV2LT5kZXYsCi0JCQkgInJl
YWQgZGV2PSUwNHg6JTAyeDolMDJ4LiUwMXggLSBvZmZzZXQgJXggc2l6ZSAlZFxuIiwKKwkJCSAi
cmVhZCBkZXY9JTA0eDolMDJ4OiUwMnguJWQgLSBvZmZzZXQgJXggc2l6ZSAlZFxuIiwKIAkJCSBw
Y2lfZG9tYWluX25yKGJ1cyksIGJ1cy0+bnVtYmVyLCBQQ0lfU0xPVChkZXZmbiksCiAJCQkgUENJ
X0ZVTkMoZGV2Zm4pLCB3aGVyZSwgc2l6ZSk7CiAKQEAgLTIyOCw3ICsyMjgsNyBAQCBzdGF0aWMg
aW50IHBjaWZyb250X2J1c193cml0ZShzdHJ1Y3QgcGNpX2J1cyAqYnVzLCB1bnNpZ25lZCBpbnQg
ZGV2Zm4sCiAKIAlpZiAodmVyYm9zZV9yZXF1ZXN0KQogCQlkZXZfaW5mbygmcGRldi0+eGRldi0+
ZGV2LAotCQkJICJ3cml0ZSBkZXY9JTA0eDolMDJ4OiUwMnguJTAxeCAtICIKKwkJCSAid3JpdGUg
ZGV2PSUwNHg6JTAyeDolMDJ4LiVkIC0gIgogCQkJICJvZmZzZXQgJXggc2l6ZSAlZCB2YWwgJXhc
biIsCiAJCQkgcGNpX2RvbWFpbl9ucihidXMpLCBidXMtPm51bWJlciwKIAkJCSBQQ0lfU0xPVChk
ZXZmbiksIFBDSV9GVU5DKGRldmZuKSwgd2hlcmUsIHNpemUsIHZhbCk7CkBAIC00MzIsNyArNDMy
LDcgQEAgc3RhdGljIGludCBfX2RldmluaXQgcGNpZnJvbnRfc2Nhbl9idXMoc3RydWN0IHBjaWZy
b250X2RldmljZSAqcGRldiwKIAkJZCA9IHBjaV9zY2FuX3NpbmdsZV9kZXZpY2UoYiwgZGV2Zm4p
OwogCQlpZiAoZCkKIAkJCWRldl9pbmZvKCZwZGV2LT54ZGV2LT5kZXYsICJOZXcgZGV2aWNlIG9u
ICIKLQkJCQkgIiUwNHg6JTAyeDolMDJ4LiUwMnggZm91bmQuXG4iLCBkb21haW4sIGJ1cywKKwkJ
CQkgIiUwNHg6JTAyeDolMDJ4LiVkIGZvdW5kLlxuIiwgZG9tYWluLCBidXMsCiAJCQkJIFBDSV9T
TE9UKGRldmZuKSwgUENJX0ZVTkMoZGV2Zm4pKTsKIAl9CiAKQEAgLTEwNDEsNyArMTA0MSw3IEBA
IHN0YXRpYyBpbnQgcGNpZnJvbnRfZGV0YWNoX2RldmljZXMoc3RydWN0IHBjaWZyb250X2Rldmlj
ZSAqcGRldikKIAkJcGNpX2RldiA9IHBjaV9nZXRfc2xvdChwY2lfYnVzLCBQQ0lfREVWRk4oc2xv
dCwgZnVuYykpOwogCQlpZiAoIXBjaV9kZXYpIHsKIAkJCWRldl9kYmcoJnBkZXYtPnhkZXYtPmRl
diwKLQkJCQkiQ2Fubm90IGdldCBQQ0kgZGV2aWNlICUwNHg6JTAyeDolMDJ4LiUwMnhcbiIsCisJ
CQkJIkNhbm5vdCBnZXQgUENJIGRldmljZSAlMDR4OiUwMng6JTAyeC4lZFxuIiwKIAkJCQlkb21h
aW4sIGJ1cywgc2xvdCwgZnVuYyk7CiAJCQljb250aW51ZTsKIAkJfQpAQCAtMTA0OSw3ICsxMDQ5
LDcgQEAgc3RhdGljIGludCBwY2lmcm9udF9kZXRhY2hfZGV2aWNlcyhzdHJ1Y3QgcGNpZnJvbnRf
ZGV2aWNlICpwZGV2KQogCQlwY2lfZGV2X3B1dChwY2lfZGV2KTsKIAogCQlkZXZfZGJnKCZwZGV2
LT54ZGV2LT5kZXYsCi0JCQkiUENJIGRldmljZSAlMDR4OiUwMng6JTAyeC4lMDJ4IHJlbW92ZWQu
XG4iLAorCQkJIlBDSSBkZXZpY2UgJTA0eDolMDJ4OiUwMnguJWQgcmVtb3ZlZC5cbiIsCiAJCQlk
b21haW4sIGJ1cywgc2xvdCwgZnVuYyk7CiAJfQogCmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94
ZW4tcGNpYmFjay9wY2lfc3R1Yi5jIGIvZHJpdmVycy94ZW4veGVuLXBjaWJhY2svcGNpX3N0dWIu
YwppbmRleCA2ZjYzYjlkLi4wOTdlNTM2IDEwMDY0NAotLS0gYS9kcml2ZXJzL3hlbi94ZW4tcGNp
YmFjay9wY2lfc3R1Yi5jCisrKyBiL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3BjaV9zdHViLmMK
QEAgLTkxOSw3ICs5MTksNyBAQCBzdGF0aWMgaW5saW5lIGludCBzdHJfdG9fcXVpcmsoY29uc3Qg
Y2hhciAqYnVmLCBpbnQgKmRvbWFpbiwgaW50ICpidXMsIGludAogCWludCBlcnI7CiAKIAllcnIg
PQotCSAgICBzc2NhbmYoYnVmLCAiICUwNHg6JTAyeDolMDJ4LiUxeC0lMDh4OiUxeDolMDh4Iiwg
ZG9tYWluLCBidXMsIHNsb3QsCisJICAgIHNzY2FuZihidWYsICIgJTA0eDolMDJ4OiUwMnguJWQt
JTA4eDolMXg6JTA4eCIsIGRvbWFpbiwgYnVzLCBzbG90LAogCQkgICBmdW5jLCByZWcsIHNpemUs
IG1hc2spOwogCWlmIChlcnIgPT0gNykKIAkJcmV0dXJuIDA7CkBAIC05MzksNyArOTM5LDcgQEAg
c3RhdGljIGludCBwY2lzdHViX2RldmljZV9pZF9hZGQoaW50IGRvbWFpbiwgaW50IGJ1cywgaW50
IHNsb3QsIGludCBmdW5jKQogCXBjaV9kZXZfaWQtPmJ1cyA9IGJ1czsKIAlwY2lfZGV2X2lkLT5k
ZXZmbiA9IFBDSV9ERVZGTihzbG90LCBmdW5jKTsKIAotCXByX2RlYnVnKERSVl9OQU1FICI6IHdh
bnRzIHRvIHNlaXplICUwNHg6JTAyeDolMDJ4LiUwMXhcbiIsCisJcHJfZGVidWcoRFJWX05BTUUg
Ijogd2FudHMgdG8gc2VpemUgJTA0eDolMDJ4OiUwMnguJWRcbiIsCiAJCSBkb21haW4sIGJ1cywg
c2xvdCwgZnVuYyk7CiAKIAlzcGluX2xvY2tfaXJxc2F2ZSgmZGV2aWNlX2lkc19sb2NrLCBmbGFn
cyk7CkBAIC05NjksNyArOTY5LDcgQEAgc3RhdGljIGludCBwY2lzdHViX2RldmljZV9pZF9yZW1v
dmUoaW50IGRvbWFpbiwgaW50IGJ1cywgaW50IHNsb3QsIGludCBmdW5jKQogCiAJCQllcnIgPSAw
OwogCi0JCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiByZW1vdmVkICUwNHg6JTAyeDolMDJ4LiUwMXgg
ZnJvbSAiCisJCQlwcl9kZWJ1ZyhEUlZfTkFNRSAiOiByZW1vdmVkICUwNHg6JTAyeDolMDJ4LiVk
IGZyb20gIgogCQkJCSAic2VpemUgbGlzdFxuIiwgZG9tYWluLCBidXMsIHNsb3QsIGZ1bmMpOwog
CQl9CiAJfQpAQCAtMTA2NCw3ICsxMDY0LDcgQEAgc3RhdGljIHNzaXplX3QgcGNpc3R1Yl9zbG90
X3Nob3coc3RydWN0IGRldmljZV9kcml2ZXIgKmRydiwgY2hhciAqYnVmKQogCQkJYnJlYWs7CiAK
IAkJY291bnQgKz0gc2NucHJpbnRmKGJ1ZiArIGNvdW50LCBQQUdFX1NJWkUgLSBjb3VudCwKLQkJ
CQkgICAiJTA0eDolMDJ4OiUwMnguJTAxeFxuIiwKKwkJCQkgICAiJTA0eDolMDJ4OiUwMnguJWRc
biIsCiAJCQkJICAgcGNpX2Rldl9pZC0+ZG9tYWluLCBwY2lfZGV2X2lkLT5idXMsCiAJCQkJICAg
UENJX1NMT1QocGNpX2Rldl9pZC0+ZGV2Zm4pLAogCQkJCSAgIFBDSV9GVU5DKHBjaV9kZXZfaWQt
PmRldmZuKSk7CmRpZmYgLS1naXQgYS9kcml2ZXJzL3hlbi94ZW4tcGNpYmFjay94ZW5idXMuYyBi
L2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3hlbmJ1cy5jCmluZGV4IGQ1ZGNmOGQuLjliMmY3MDUg
MTAwNjQ0Ci0tLSBhL2RyaXZlcnMveGVuL3hlbi1wY2liYWNrL3hlbmJ1cy5jCisrKyBiL2RyaXZl
cnMveGVuL3hlbi1wY2liYWNrL3hlbmJ1cy5jCkBAIC0yMDYsOCArMjA2LDkgQEAgc3RhdGljIGlu
dCB4ZW5fcGNpYmtfcHVibGlzaF9wY2lfZGV2KHN0cnVjdCB4ZW5fcGNpYmtfZGV2aWNlICpwZGV2
LAogCQlnb3RvIG91dDsKIAl9CiAKKwkvKiBUT0RPOiBpbXBsZW1lbnQgZmVhdHVyZS11c2UtZGVj
aW1hbC1mb3ItZGV2Zm4gKi8KIAllcnIgPSB4ZW5idXNfcHJpbnRmKFhCVF9OSUwsIHBkZXYtPnhk
ZXYtPm5vZGVuYW1lLCBzdHIsCi0JCQkgICAgIiUwNHg6JTAyeDolMDJ4LiUwMngiLCBkb21haW4s
IGJ1cywKKwkJCSAgICAiJTA0eDolMDJ4OiUwMnguJTF4IiwgZG9tYWluLCBidXMsCiAJCQkgICAg
UENJX1NMT1QoZGV2Zm4pLCBQQ0lfRlVOQyhkZXZmbikpOwogCiBvdXQ6CkBAIC0yMjksNyArMjMw
LDcgQEAgc3RhdGljIGludCB4ZW5fcGNpYmtfZXhwb3J0X2RldmljZShzdHJ1Y3QgeGVuX3BjaWJr
X2RldmljZSAqcGRldiwKIAkJZXJyID0gLUVJTlZBTDsKIAkJeGVuYnVzX2Rldl9mYXRhbChwZGV2
LT54ZGV2LCBlcnIsCiAJCQkJICJDb3VsZG4ndCBsb2NhdGUgUENJIGRldmljZSAiCi0JCQkJICIo
JTA0eDolMDJ4OiUwMnguJTAxeCkhICIKKwkJCQkgIiglMDR4OiUwMng6JTAyeC4lZCkhICIKIAkJ
CQkgInBlcmhhcHMgYWxyZWFkeSBpbi11c2U/IiwKIAkJCQkgZG9tYWluLCBidXMsIHNsb3QsIGZ1
bmMpOwogCQlnb3RvIG91dDsKQEAgLTI3NCw3ICsyNzUsNyBAQCBzdGF0aWMgaW50IHhlbl9wY2li
a19yZW1vdmVfZGV2aWNlKHN0cnVjdCB4ZW5fcGNpYmtfZGV2aWNlICpwZGV2LAogCWlmICghZGV2
KSB7CiAJCWVyciA9IC1FSU5WQUw7CiAJCWRldl9kYmcoJnBkZXYtPnhkZXYtPmRldiwgIkNvdWxk
bid0IGxvY2F0ZSBQQ0kgZGV2aWNlICIKLQkJCSIoJTA0eDolMDJ4OiUwMnguJTAxeCkhIG5vdCBv
d25lZCBieSB0aGlzIGRvbWFpblxuIiwKKwkJCSIoJTA0eDolMDJ4OiUwMnguJWQpISBub3Qgb3du
ZWQgYnkgdGhpcyBkb21haW5cbiIsCiAJCQlkb21haW4sIGJ1cywgc2xvdCwgZnVuYyk7CiAJCWdv
dG8gb3V0OwogCX0KLS0gCjEuNy43LjUKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54
ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 21:29:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 21:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqAPT-00083g-M1; Wed, 25 Jan 2012 21:29:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RqAPS-00083Z-D0
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 21:29:38 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327526934!57459922!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 679 invoked from network); 25 Jan 2012 21:28:55 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 21:28:55 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PLTY6i026061
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 16:29:34 -0500
Received: from [192.168.37.18] ([192.168.37.18]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Wed, 25 Jan 2012 16:29:12 -0500
Message-ID: <1327526963.2452.41.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Pavel =?UTF-8?Q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Date: Wed, 25 Jan 2012 16:29:23 -0500
In-Reply-To: <201201252148.43195.pavel@netsafe.cz>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252052.17845.pavel@netsafe.cz>
	<1327523353.2452.38.camel@mnetdjm5.mageenet.host>
	<201201252148.43195.pavel@netsafe.cz>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2012 21:29:12.0449 (UTC)
	FILETIME=[618C8710:01CCDBA8]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDIxOjQ4ICswMTAwLCBQYXZlbCBNYXTEm2phIHdyb3RlOgo+
IE9uIFdlZCAyNS4gb2YgSmFudWFyeSAyMDEyIDIxOjI5OjEzIHlvdSB3cm90ZToKPiA+IE9uIFdl
ZCwgMjAxMi0wMS0yNSBhdCAyMDo1MiArMDEwMCwgUGF2ZWwgTWF0xJtqYSB3cm90ZToKPiA+ID4g
T24gV2VkIDI1LiBvZiBKYW51YXJ5IDIwMTIgMjA6Mjk6MTIgUGF2ZWwgTWF0xJtqYSB3cm90ZToK
PiA+ID4gPiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAxNzo1MjoxMSBEb3VnIE1hZ2VlIHdy
b3RlOgo+ID4gPiA+ID4gQWxzbywgaSBiZWxpZXZlIHlvdSBzYWlkIHRoZSBjYXJkIHlvdSdyZSB0
cnlpbmcgdG8gcGFzcyB0aHJvdWdoIGlzCj4gPiA+ID4gPiBub3QgdGhlIHByaW1hcnkgY2FyZCBp
biB5b3VyIGhvc3Qgc3lzdGVtLiAgSWYgdGhhdCdzIHRoZSBjYXNlLCBkb24ndAo+ID4gPiA+ID4g
dXNlIGdmeF9wYXNzdGhydSBvciBleHBlY3QgdG8gZ2V0IHRoZSB2aWRlbyBiaW9zIHdvcmtpbmcu
ICBUaGUKPiA+ID4gPiA+ICdwcmltYXJ5JyB2aWRlbyBhZGFwdGVyIG93bnMgY2VydGFpbiBpbyBw
b3J0cyBhbmQgbWVtb3J5IGFyZWFzIHRoYXQKPiA+ID4gPiA+IGFyZSBjb25zaXRlbnQgZnJvbSBt
YWNoaW5lIHRvIG1hY2hpbmUuICBBbHNvLCB0aGUgc3lzdGVtIHdpbGwgY29weQo+ID4gPiA+ID4g
dGhlIHZiaW9zIGZyb20gdGhlIGNhcmQgdG8gYSBsb2NhdGlvbiBpbiBtZW1vcnkgKDB4YzAwMDAp
IHNvIGl0IGNhbgo+ID4gPiA+ID4gZXhlY3V0ZSBhdCBib290IHRpbWUuCj4gPiA+ID4gPiAKPiA+
ID4gPiA+IFhlbidzIGdmeF9wYXNzdGhydSBjb2RlIGRlcGVuZHMgb24gYWxsIG9mIHRoZXNlIGZh
Y3RvcnMuICBBcyB0aGUgY29kZQo+ID4gPiA+ID4gc3RhbmRzLCBpZiB5b3UgdXNlIGdmeF9wYXNz
dGhydSBvbiBhIHNlY29uZGFyeSBjYXJkLCBpdCB3aWxsIHN0aWxsCj4gPiA+ID4gPiBjb3B5IHRo
ZSB2YmlvcyBmcm9tIHRoZSBwcmltYXJ5IGNhcmQgKGFzIGl0IHNpbXBseSByZWFkcyBtZW1vcnkg
ZnJvbQo+ID4gPiA+ID4gMHhjMDAwMCksIGFuZCBkaXJlY3RseSBtYXAgaW8gcG9ydHMgYW5kIGxv
dyBtZW1vcnkgYXJlYXMgdG8gdGhvc2UKPiA+ID4gPiA+IHVzZWQgYnkgdGhlIHByaW1hcnkgY2Fy
ZCBpbiB0aGUgaG9zdCBzeXN0ZW0uICBJbiB0aGlzIGNhc2UgdGhlIGd1ZXN0Cj4gPiA+ID4gPiB3
aWxsIGFsbW9zdCBjZXJ0YWlubHkgbmV2ZXIgZ2V0IHBhc3QgZXhlY3V0aW5nIFJPTUJJT1MsIGFu
ZCB0aGUgaG9zdAo+ID4gPiA+ID4gbWF5IG9yIG1heSBub3QgbG9jayB1cCBvciBleHBlcmllbmNl
ICdpc3N1ZXMnLgo+ID4gPiA+IAo+ID4gPiA+IFRoaXMgd2lsbCBkbyB0aGUgdHJpY2sgd2l0aCBz
ZWNvbmRhcnkgY2FyZCAocmVwbGFjZSBwYXRoIHRvIFZHQSBCSU9TKToKPiA+ID4gPiAKPiA+ID4g
PiAtLS0geGVuLXVuc3RhYmxlLmhnLndvcmtpbmcvdG9vbHMvaW9lbXUtcmVtb3RlL2h3L3B0LWdy
YXBoaWNzLmMKPiA+ID4gPiAyMDEyLTAxLTI1IDIwOjI2OjM3LjkyNzY1NDg5MCArMDEwMAo+ID4g
PiA+ICsrKyB4ZW4tdW5zdGFibGUuaGcud29ya2luZy5nZW5lcmljL3Rvb2xzL2lvZW11LXJlbW90
ZS9ody9wdC1ncmFwaGljcy5jCj4gPiA+ID4gMjAxMS0wNy0zMCAxMzo1Nzo1Ny4zNDczOTYwOTUg
KzAyMDAKPiA+ID4gPiBAQCAtNDg3LDEwICs0ODcsMTAgQEAKPiA+ID4gPiAKPiA+ID4gPiAgewo+
ID4gPiA+ICAKPiA+ID4gPiAgICAgIGludCBmZDsKPiA+ID4gPiAgICAgIHVpbnQzMl90IGJpb3Nf
c2l6ZSA9IDA7Cj4gPiA+ID4gCj4gPiA+ID4gLSAgICB1aW50MzJfdCBzdGFydCA9IDA7Cj4gPiA+
ID4gKyAgICB1aW50MzJfdCBzdGFydCA9IDB4QzAwMDA7Cj4gPiA+ID4gCj4gPiA+ID4gICAgICB1
aW50MTZfdCBtYWdpYyA9IDA7Cj4gPiA+ID4gCj4gPiA+ID4gLSAgICBpZiAoIChmZCA9IG9wZW4o
Ii9saWIvZmlybXdhcmUvQVNVUy5IRDY4NTAuMTAyNC4xMDEwMDcuYmluIiwKPiA+ID4gPiBPX1JE
T05MWSkpIDwgMCApCj4gPiA+ID4gKyAgICBpZiAoIChmZCA9IG9wZW4oIi9kZXYvbWVtIiwgT19S
RE9OTFkpKSA8IDAgKQo+ID4gPiA+IAo+ID4gPiA+ICAgICAgewo+ID4gPiA+ICAgICAgCj4gPiA+
ID4gICAgICAgICAgUFRfTE9HKCJFcnJvcjogQ2FuJ3Qgb3BlbiAvZGV2L21lbTogJXNcbiIsIHN0
cmVycm9yKGVycm5vKSk7Cj4gPiA+ID4gICAgICAgICAgcmV0dXJuIDA7Cj4gPiA+IAo+ID4gPiBT
b3JyeSwgc3dpdGNoIHRoZSArIGFuZCAtLgo+ID4gCj4gPiBUaGlzIHdpbGwgbG9hZCB0aGUgcHJv
cGVyIEJJT1MsIGJ1dCBpdCBzZWVtcyB0aGlzIHdvdWxkbid0IGJlIGVub3VnaC4KPiA+IEluIGh3
L3B0LWdyYXBoaWNzLmM6cmVnaXN0ZXJfdmdhX3JlZ2lvbnMoKSwgd2UgbWFwIDE6MSBpb3BvcnRz
Cj4gPiAweDNiMC0weDNiYiwgMHgzYzAtMHgzZGYsIGFuZCBtZW1vcnkgYXQgMHhhMDAwMC0weGJm
ZmZmLgo+ID4gCj4gPiBJZiBpIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0bHksIHRoZXNlIGlvcG9y
dHMgYW5kIG1lbW9yeSBhcmVhcyBhcmUgYm91bmQKPiA+IHRvIHRoZSBwcmltYXJ5IHZpZGVvIGFk
YXB0ZXIgaW4gdGhlIGhvc3Qgb24gYm9vdCBieSB0aGUgQklPUywgZGVwZW5kaW5nCj4gPiBvbiB3
aGF0IGRldmljZSB5b3UndmUgc2VsZWN0ZWQgaW4gdGhlIEJJT1Mgc2V0dXAgc2NyZWVuIHRvIGJl
IHlvdXIKPiA+IHByaW1hcnkgYWRhcHRlci4gIFRoZXJlZm9yZSwgeW91IGNvdWxkIGxvYWQgdGhl
IHByb3BlciBiaW9zLCBidXQgaXQKPiA+IHdvdWxkIHN0aWxsIHdyaXRlIHRvIG1lbW9yeSBhbmQg
aW8gcG9ydHMgdGhhdCBhcmUgYm91bmQgdG8gdGhlIHByaW1hcnkKPiA+IGNhcmQgaW4gdGhlIGhv
c3QsIG5vdCB0aGUgY2FyZCBiZWluZyBwYXNzZWQgdGhyb3VnaCB0byB0aGUgZ3Vlc3QuCj4gPiAK
PiA+IERvZXMgdGhpcyBtYWtlIHNlbnNlPyAoT3IsIGFtIGkgbnV0cz8pCj4gCj4gSXQgbWFrZXMg
c2Vuc2UgYW5kIGl0J3MgcXVpdGUgY29tcGxpY2F0ZWQuCj4gUHJpbWFyeSBjYXJkIGlzICJib3Vu
ZCIgdG8gdGhvc2UgcG9ydHMgYnkgUENJIGJyaWRnZS4gV2hlbiB5b3UgYWNjZXNzIGxlZ2FjeSAK
PiBJTyBwb3J0IHRoZSBQQ0kgd2lsbCBleGFtaW5lIGFsbCBicmlkZ2VzIGxvb2tpbmcgZm9yIFZH
QSBFbmFibGUgYml0IGluIHRoZSAKPiBCcmlkZ2UgQ29udHJvbCByZWdpc3RlciBhbmQgcGFzcyB0
aGUgY2FsbCB0byBzdWNoIHN1Y2ggYnJpZGdlLiBTbyB0aGVyZSBzaG91bGQgCj4gYmUgbGludXgg
c3lzY2FsbCB0byB2Z2FhcmIgYmVmb3JlIGFuZCBhZnRlciBlYWNoIGlvcG9ydCBhY2Nlc3Mgd2hp
Y2ggd2lsbCBzZXQgCj4gYW5kIHVuc2V0IHRoZSBiaXQgZm9yIHJpZ2h0IGNhcmQncyBicmlkZ2Uu
Cj4gQnV0IHRoaXMgc2V0dXAgd29ya3MgYW55d2F5ISBXaW5kb3dzIGRyaXZlciBkb2Vzbid0IGFj
Y2VzcyBpb3BvcnRzLiBKdXN0IFZHQSAKPiBCSU9TIGRvZXMuIEl0IG1lYW5zIGxvYWRpbmcgdGhl
IEJJT1Mgd2lsbCBtZXNzIGltYWdlIG9uIHByaW1hcnkgY2FyZC4KPiBJbiB0aGUgZW5kIEknbSBh
YmxlIHRvIGJvb3QgdGhyZWUgdmlydHVhbCBtYWNoaW5lcyBhbGwgd2l0aCBwYXNzZWQgKEFNRCkg
VkdBLgoKQWgsIG9rLCBzbyBpbiB5b3VyIGNhc2UsIHRoZSB2QklPUyBkb2Vzbid0IGFjdHVhbGx5
IHdvcmssIGFuZCB5b3UgZG9uJ3QKZ2V0IGFueSBvdXRwdXQgdW50aWwgdGhlIE9TIGRyaXZlcnMg
bG9hZD8gIEJ1dCB5b3UgbmVlZCB0byBsb2FkIHRoZQpwcm9wZXIgYmlvcyB0byBndWVzdCBtZW1v
cnkgYW55d2F5IGJlY2F1c2UgdGhlIGRyaXZlcnMgZGVwZW5kIG9uIGl0PwoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 21:29:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 21:29:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqAPT-00083g-M1; Wed, 25 Jan 2012 21:29:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RqAPS-00083Z-D0
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 21:29:38 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327526934!57459922!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 679 invoked from network); 25 Jan 2012 21:28:55 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 21:28:55 -0000
Received: from mnetweb5 ([172.23.4.45])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0PLTY6i026061
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 16:29:34 -0500
Received: from [192.168.37.18] ([192.168.37.18]) by mnetweb5 with Microsoft
	SMTPSVC(7.5.7600.16601); Wed, 25 Jan 2012 16:29:12 -0500
Message-ID: <1327526963.2452.41.camel@mnetdjm5.mageenet.host>
From: Doug Magee <djmagee@mageenet.net>
To: Pavel =?UTF-8?Q?Mat=C4=9Bja?= <pavel@netsafe.cz>
Date: Wed, 25 Jan 2012 16:29:23 -0500
In-Reply-To: <201201252148.43195.pavel@netsafe.cz>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252052.17845.pavel@netsafe.cz>
	<1327523353.2452.38.camel@mnetdjm5.mageenet.host>
	<201201252148.43195.pavel@netsafe.cz>
X-Mailer: Evolution 3.2.2 (3.2.2-1.fc16) 
Mime-Version: 1.0
X-OriginalArrivalTime: 25 Jan 2012 21:29:12.0449 (UTC)
	FILETIME=[618C8710:01CCDBA8]
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gV2VkLCAyMDEyLTAxLTI1IGF0IDIxOjQ4ICswMTAwLCBQYXZlbCBNYXTEm2phIHdyb3RlOgo+
IE9uIFdlZCAyNS4gb2YgSmFudWFyeSAyMDEyIDIxOjI5OjEzIHlvdSB3cm90ZToKPiA+IE9uIFdl
ZCwgMjAxMi0wMS0yNSBhdCAyMDo1MiArMDEwMCwgUGF2ZWwgTWF0xJtqYSB3cm90ZToKPiA+ID4g
T24gV2VkIDI1LiBvZiBKYW51YXJ5IDIwMTIgMjA6Mjk6MTIgUGF2ZWwgTWF0xJtqYSB3cm90ZToK
PiA+ID4gPiBPbiBXZWQgMjUuIG9mIEphbnVhcnkgMjAxMiAxNzo1MjoxMSBEb3VnIE1hZ2VlIHdy
b3RlOgo+ID4gPiA+ID4gQWxzbywgaSBiZWxpZXZlIHlvdSBzYWlkIHRoZSBjYXJkIHlvdSdyZSB0
cnlpbmcgdG8gcGFzcyB0aHJvdWdoIGlzCj4gPiA+ID4gPiBub3QgdGhlIHByaW1hcnkgY2FyZCBp
biB5b3VyIGhvc3Qgc3lzdGVtLiAgSWYgdGhhdCdzIHRoZSBjYXNlLCBkb24ndAo+ID4gPiA+ID4g
dXNlIGdmeF9wYXNzdGhydSBvciBleHBlY3QgdG8gZ2V0IHRoZSB2aWRlbyBiaW9zIHdvcmtpbmcu
ICBUaGUKPiA+ID4gPiA+ICdwcmltYXJ5JyB2aWRlbyBhZGFwdGVyIG93bnMgY2VydGFpbiBpbyBw
b3J0cyBhbmQgbWVtb3J5IGFyZWFzIHRoYXQKPiA+ID4gPiA+IGFyZSBjb25zaXRlbnQgZnJvbSBt
YWNoaW5lIHRvIG1hY2hpbmUuICBBbHNvLCB0aGUgc3lzdGVtIHdpbGwgY29weQo+ID4gPiA+ID4g
dGhlIHZiaW9zIGZyb20gdGhlIGNhcmQgdG8gYSBsb2NhdGlvbiBpbiBtZW1vcnkgKDB4YzAwMDAp
IHNvIGl0IGNhbgo+ID4gPiA+ID4gZXhlY3V0ZSBhdCBib290IHRpbWUuCj4gPiA+ID4gPiAKPiA+
ID4gPiA+IFhlbidzIGdmeF9wYXNzdGhydSBjb2RlIGRlcGVuZHMgb24gYWxsIG9mIHRoZXNlIGZh
Y3RvcnMuICBBcyB0aGUgY29kZQo+ID4gPiA+ID4gc3RhbmRzLCBpZiB5b3UgdXNlIGdmeF9wYXNz
dGhydSBvbiBhIHNlY29uZGFyeSBjYXJkLCBpdCB3aWxsIHN0aWxsCj4gPiA+ID4gPiBjb3B5IHRo
ZSB2YmlvcyBmcm9tIHRoZSBwcmltYXJ5IGNhcmQgKGFzIGl0IHNpbXBseSByZWFkcyBtZW1vcnkg
ZnJvbQo+ID4gPiA+ID4gMHhjMDAwMCksIGFuZCBkaXJlY3RseSBtYXAgaW8gcG9ydHMgYW5kIGxv
dyBtZW1vcnkgYXJlYXMgdG8gdGhvc2UKPiA+ID4gPiA+IHVzZWQgYnkgdGhlIHByaW1hcnkgY2Fy
ZCBpbiB0aGUgaG9zdCBzeXN0ZW0uICBJbiB0aGlzIGNhc2UgdGhlIGd1ZXN0Cj4gPiA+ID4gPiB3
aWxsIGFsbW9zdCBjZXJ0YWlubHkgbmV2ZXIgZ2V0IHBhc3QgZXhlY3V0aW5nIFJPTUJJT1MsIGFu
ZCB0aGUgaG9zdAo+ID4gPiA+ID4gbWF5IG9yIG1heSBub3QgbG9jayB1cCBvciBleHBlcmllbmNl
ICdpc3N1ZXMnLgo+ID4gPiA+IAo+ID4gPiA+IFRoaXMgd2lsbCBkbyB0aGUgdHJpY2sgd2l0aCBz
ZWNvbmRhcnkgY2FyZCAocmVwbGFjZSBwYXRoIHRvIFZHQSBCSU9TKToKPiA+ID4gPiAKPiA+ID4g
PiAtLS0geGVuLXVuc3RhYmxlLmhnLndvcmtpbmcvdG9vbHMvaW9lbXUtcmVtb3RlL2h3L3B0LWdy
YXBoaWNzLmMKPiA+ID4gPiAyMDEyLTAxLTI1IDIwOjI2OjM3LjkyNzY1NDg5MCArMDEwMAo+ID4g
PiA+ICsrKyB4ZW4tdW5zdGFibGUuaGcud29ya2luZy5nZW5lcmljL3Rvb2xzL2lvZW11LXJlbW90
ZS9ody9wdC1ncmFwaGljcy5jCj4gPiA+ID4gMjAxMS0wNy0zMCAxMzo1Nzo1Ny4zNDczOTYwOTUg
KzAyMDAKPiA+ID4gPiBAQCAtNDg3LDEwICs0ODcsMTAgQEAKPiA+ID4gPiAKPiA+ID4gPiAgewo+
ID4gPiA+ICAKPiA+ID4gPiAgICAgIGludCBmZDsKPiA+ID4gPiAgICAgIHVpbnQzMl90IGJpb3Nf
c2l6ZSA9IDA7Cj4gPiA+ID4gCj4gPiA+ID4gLSAgICB1aW50MzJfdCBzdGFydCA9IDA7Cj4gPiA+
ID4gKyAgICB1aW50MzJfdCBzdGFydCA9IDB4QzAwMDA7Cj4gPiA+ID4gCj4gPiA+ID4gICAgICB1
aW50MTZfdCBtYWdpYyA9IDA7Cj4gPiA+ID4gCj4gPiA+ID4gLSAgICBpZiAoIChmZCA9IG9wZW4o
Ii9saWIvZmlybXdhcmUvQVNVUy5IRDY4NTAuMTAyNC4xMDEwMDcuYmluIiwKPiA+ID4gPiBPX1JE
T05MWSkpIDwgMCApCj4gPiA+ID4gKyAgICBpZiAoIChmZCA9IG9wZW4oIi9kZXYvbWVtIiwgT19S
RE9OTFkpKSA8IDAgKQo+ID4gPiA+IAo+ID4gPiA+ICAgICAgewo+ID4gPiA+ICAgICAgCj4gPiA+
ID4gICAgICAgICAgUFRfTE9HKCJFcnJvcjogQ2FuJ3Qgb3BlbiAvZGV2L21lbTogJXNcbiIsIHN0
cmVycm9yKGVycm5vKSk7Cj4gPiA+ID4gICAgICAgICAgcmV0dXJuIDA7Cj4gPiA+IAo+ID4gPiBT
b3JyeSwgc3dpdGNoIHRoZSArIGFuZCAtLgo+ID4gCj4gPiBUaGlzIHdpbGwgbG9hZCB0aGUgcHJv
cGVyIEJJT1MsIGJ1dCBpdCBzZWVtcyB0aGlzIHdvdWxkbid0IGJlIGVub3VnaC4KPiA+IEluIGh3
L3B0LWdyYXBoaWNzLmM6cmVnaXN0ZXJfdmdhX3JlZ2lvbnMoKSwgd2UgbWFwIDE6MSBpb3BvcnRz
Cj4gPiAweDNiMC0weDNiYiwgMHgzYzAtMHgzZGYsIGFuZCBtZW1vcnkgYXQgMHhhMDAwMC0weGJm
ZmZmLgo+ID4gCj4gPiBJZiBpIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0bHksIHRoZXNlIGlvcG9y
dHMgYW5kIG1lbW9yeSBhcmVhcyBhcmUgYm91bmQKPiA+IHRvIHRoZSBwcmltYXJ5IHZpZGVvIGFk
YXB0ZXIgaW4gdGhlIGhvc3Qgb24gYm9vdCBieSB0aGUgQklPUywgZGVwZW5kaW5nCj4gPiBvbiB3
aGF0IGRldmljZSB5b3UndmUgc2VsZWN0ZWQgaW4gdGhlIEJJT1Mgc2V0dXAgc2NyZWVuIHRvIGJl
IHlvdXIKPiA+IHByaW1hcnkgYWRhcHRlci4gIFRoZXJlZm9yZSwgeW91IGNvdWxkIGxvYWQgdGhl
IHByb3BlciBiaW9zLCBidXQgaXQKPiA+IHdvdWxkIHN0aWxsIHdyaXRlIHRvIG1lbW9yeSBhbmQg
aW8gcG9ydHMgdGhhdCBhcmUgYm91bmQgdG8gdGhlIHByaW1hcnkKPiA+IGNhcmQgaW4gdGhlIGhv
c3QsIG5vdCB0aGUgY2FyZCBiZWluZyBwYXNzZWQgdGhyb3VnaCB0byB0aGUgZ3Vlc3QuCj4gPiAK
PiA+IERvZXMgdGhpcyBtYWtlIHNlbnNlPyAoT3IsIGFtIGkgbnV0cz8pCj4gCj4gSXQgbWFrZXMg
c2Vuc2UgYW5kIGl0J3MgcXVpdGUgY29tcGxpY2F0ZWQuCj4gUHJpbWFyeSBjYXJkIGlzICJib3Vu
ZCIgdG8gdGhvc2UgcG9ydHMgYnkgUENJIGJyaWRnZS4gV2hlbiB5b3UgYWNjZXNzIGxlZ2FjeSAK
PiBJTyBwb3J0IHRoZSBQQ0kgd2lsbCBleGFtaW5lIGFsbCBicmlkZ2VzIGxvb2tpbmcgZm9yIFZH
QSBFbmFibGUgYml0IGluIHRoZSAKPiBCcmlkZ2UgQ29udHJvbCByZWdpc3RlciBhbmQgcGFzcyB0
aGUgY2FsbCB0byBzdWNoIHN1Y2ggYnJpZGdlLiBTbyB0aGVyZSBzaG91bGQgCj4gYmUgbGludXgg
c3lzY2FsbCB0byB2Z2FhcmIgYmVmb3JlIGFuZCBhZnRlciBlYWNoIGlvcG9ydCBhY2Nlc3Mgd2hp
Y2ggd2lsbCBzZXQgCj4gYW5kIHVuc2V0IHRoZSBiaXQgZm9yIHJpZ2h0IGNhcmQncyBicmlkZ2Uu
Cj4gQnV0IHRoaXMgc2V0dXAgd29ya3MgYW55d2F5ISBXaW5kb3dzIGRyaXZlciBkb2Vzbid0IGFj
Y2VzcyBpb3BvcnRzLiBKdXN0IFZHQSAKPiBCSU9TIGRvZXMuIEl0IG1lYW5zIGxvYWRpbmcgdGhl
IEJJT1Mgd2lsbCBtZXNzIGltYWdlIG9uIHByaW1hcnkgY2FyZC4KPiBJbiB0aGUgZW5kIEknbSBh
YmxlIHRvIGJvb3QgdGhyZWUgdmlydHVhbCBtYWNoaW5lcyBhbGwgd2l0aCBwYXNzZWQgKEFNRCkg
VkdBLgoKQWgsIG9rLCBzbyBpbiB5b3VyIGNhc2UsIHRoZSB2QklPUyBkb2Vzbid0IGFjdHVhbGx5
IHdvcmssIGFuZCB5b3UgZG9uJ3QKZ2V0IGFueSBvdXRwdXQgdW50aWwgdGhlIE9TIGRyaXZlcnMg
bG9hZD8gIEJ1dCB5b3UgbmVlZCB0byBsb2FkIHRoZQpwcm9wZXIgYmlvcyB0byBndWVzdCBtZW1v
cnkgYW55d2F5IGJlY2F1c2UgdGhlIGRyaXZlcnMgZGVwZW5kIG9uIGl0PwoKCgpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBs
aXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2Uu
Y29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Wed Jan 25 22:31:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 22: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 1RqBMV-0000Uh-Er; Wed, 25 Jan 2012 22:30:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqBMU-0000Uc-1g
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 22:30:38 +0000
Received: from [85.158.139.83:33023] by server-10.bemta-5.messagelabs.com id
	CE/14-18919-D82802F4; Wed, 25 Jan 2012 22:30:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327530636!12405973!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25017 invoked from network); 25 Jan 2012 22:30:36 -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;
	25 Jan 2012 22:30:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,570,1320624000"; d="scan'208";a="10292480"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 22:30: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;
	Wed, 25 Jan 2012 22:30:36 +0000
Message-ID: <1327530635.856.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 22:30:35 +0000
In-Reply-To: <20120125204652.GA21284@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<20120125204652.GA21284@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "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>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 20:46 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 25, 2012 at 09:55:33AM +0000, Ian Campbell wrote:
> > On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> > > 
> > > .. snip..
> > > > 
> > > > and with this little patch I can get it to work:
> > > 
> > > I get the domU to boot but the network stops being responsive.
> > > I see this in the Dom0:
> > 
> > Your original patch would set the version to two in the hypervisor and
> > then ignore that and continue to use v1 so that isn't surprising.
> > 
> > > (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> > > [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> > > [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> > > 
> > > Replacing the patch with:
> > > 
> > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > > index 1cd94da..b4d4eac 100644
> > > --- a/drivers/xen/grant-table.c
> > > +++ b/drivers/xen/grant-table.c
> > > @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
> > >  	int rc;
> > >  	struct gnttab_set_version gsv;
> > >  
> > > -	gsv.version = 2;
> > > +	if (xen_hvm_domain())
> > > +		gsv.version = 1;
> > > +	else
> > > +		gsv.version = 2;
> > >  	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> > > -	if (rc == 0) {
> > > +	if (rc == 0 && gsv.version == 2) {
> > >  		grant_table_version = 2;
> > >  		gnttab_interface = &gnttab_v2_ops;
> > >  	} else if (grant_table_version == 2) {
> > > 
> > > Gets me back to how it worked in Linux v3.2.
> > > 
> > > But that is just a band-aid fix...
> > 
> > The real bug is presumably either that the Linux v2 code is buggy for
> > use in an HVM guest or that Xen's support for v2 in HVM guests is either
> > buggy or explicitly disabled (in which case set_version should fail for
> > version=2).
> > 
> > Is the set_version with version=1 succeeding or failing? Likewise for
> > the version=2 call?
> 
> Both return 0. But version=2 returns the error in the hypervisor:
> 
>  (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)

This was with your first (buggy) patch, right?

I think this error is because your first version of the patch switched
to v2 but then ignored that and continued to use the v1 data structures
-- hence there is a disagreement between the kernel and the hypervisor
about where the flags actually are and you get errors like the above.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 22:31:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 22: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 1RqBMV-0000Uh-Er; Wed, 25 Jan 2012 22:30:39 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqBMU-0000Uc-1g
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 22:30:38 +0000
Received: from [85.158.139.83:33023] by server-10.bemta-5.messagelabs.com id
	CE/14-18919-D82802F4; Wed, 25 Jan 2012 22:30:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327530636!12405973!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDI4OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25017 invoked from network); 25 Jan 2012 22:30:36 -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;
	25 Jan 2012 22:30:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,570,1320624000"; d="scan'208";a="10292480"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 22:30: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;
	Wed, 25 Jan 2012 22:30:36 +0000
Message-ID: <1327530635.856.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 22:30:35 +0000
In-Reply-To: <20120125204652.GA21284@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<20120125204652.GA21284@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "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>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 20:46 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 25, 2012 at 09:55:33AM +0000, Ian Campbell wrote:
> > On Wed, 2012-01-25 at 05:12 +0000, Konrad Rzeszutek Wilk wrote:
> > > On Tue, Jan 24, 2012 at 11:49:49PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > When I try to bootup a PVonHVM guest with Xen 4.1 I get this:
> > > 
> > > .. snip..
> > > > 
> > > > and with this little patch I can get it to work:
> > > 
> > > I get the domU to boot but the network stops being responsive.
> > > I see this in the Dom0:
> > 
> > Your original patch would set the version to two in the hypervisor and
> > then ignore that and continue to use v1 so that isn't surprising.
> > 
> > > (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)
> > > [ 6834.488816] vif vif-12-0: 1 mapping in shared page 768 from domain 12
> > > [ 6834.490235] vif vif-12-0: 1 mapping shared-frames 768/769 port 15
> > > 
> > > Replacing the patch with:
> > > 
> > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > > index 1cd94da..b4d4eac 100644
> > > --- a/drivers/xen/grant-table.c
> > > +++ b/drivers/xen/grant-table.c
> > > @@ -948,9 +948,12 @@ static void gnttab_request_version(void)
> > >  	int rc;
> > >  	struct gnttab_set_version gsv;
> > >  
> > > -	gsv.version = 2;
> > > +	if (xen_hvm_domain())
> > > +		gsv.version = 1;
> > > +	else
> > > +		gsv.version = 2;
> > >  	rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
> > > -	if (rc == 0) {
> > > +	if (rc == 0 && gsv.version == 2) {
> > >  		grant_table_version = 2;
> > >  		gnttab_interface = &gnttab_v2_ops;
> > >  	} else if (grant_table_version == 2) {
> > > 
> > > Gets me back to how it worked in Linux v3.2.
> > > 
> > > But that is just a band-aid fix...
> > 
> > The real bug is presumably either that the Linux v2 code is buggy for
> > use in an HVM guest or that Xen's support for v2 in HVM guests is either
> > buggy or explicitly disabled (in which case set_version should fail for
> > version=2).
> > 
> > Is the set_version with version=1 succeeding or failing? Likewise for
> > the version=2 call?
> 
> Both return 0. But version=2 returns the error in the hypervisor:
> 
>  (XEN) grant_table.c:362:d0 Bad flags (0) or dom (0). (expected dom 0, flags 103)

This was with your first (buggy) patch, right?

I think this error is because your first version of the patch switched
to v2 but then ignored that and continued to use the v1 data structures
-- hence there is a disagreement between the kernel and the hypervisor
about where the flags actually are and you get errors like the above.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 22:34:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 22:34:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqBPt-0000bK-2R; Wed, 25 Jan 2012 22:34: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 1RqBPr-0000b9-O7
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 22:34:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327530841!12524607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDcyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 656 invoked from network); 25 Jan 2012 22:34:01 -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;
	25 Jan 2012 22:34:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,570,1320624000"; d="scan'208";a="10292513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 22:34:01 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 22:34:01 +0000
Message-ID: <1327530840.856.9.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 22:34:00 +0000
In-Reply-To: <20120125205043.GB21284@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
	<20120125205043.GB21284@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "ANNIE LI \(annie.li@oracle.com\)" <annie.li@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 20:50 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 25, 2012 at 03:23:28PM +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Paul Durrant
> > > Sent: 25 January 2012 07:17
> > > To: Ian Campbell; Konrad Rzeszutek Wilk
> > > Cc: annie.li@oracle.com; xen-devel@lists.xensource.com; linux-
> > > kernel@vger.kernel.org
> > > Subject: RE: [Xen-devel] Regressions in v3.3-rc1 introduced by
> > > "xen/granttable: Grant tables V2 implementation"
> > > 
> > > > -----Original Message-----
> > > >
> > > > On HVM for gnttab_shared we make an add_to_physmap call with
> > > > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call
> > > > to do something similar for the status array though and I don't see a
> > > > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > > >
> > > 
> > > There is no map-space for the status pages. To map them you use the
> > > standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky,
> > > but that's how it is.
> > > 
> > 
> > I fixed a bug in xen-unstable a few weeks back that prevented
> mapping of the status frames so I guess the bug is possibly due to
> trying to use gnttab 2 on 4.1, where this bug would hit, but failing
> to check the return code from the status mapping hypercall?
> 
> changeset:   24428:5b4b7e565ab8
> user:        Paul Durrant <paul.durrant@citrix.com>
> date:        Sun Dec 18 14:39:14 2011 +0000
> summary:     Fix grant_table v2 status mapping.
> 
> changeset:   24427:931bf1105730
> user:        Paul Durrant <paul.durrant@citrix.com>
> date:        Sun Dec 18 14:38:32 2011 +0000
> summary:     Allow VMs to query their own grant table version.
> 
> 
> Looks like c/s 24427 needs to be in the hypervior. Hm, but that exists
> in 4.1 too as 23204. Will try back-porting cs 24428 in Xen 4.1 and seeing
> if that does it.

I think this bug is a red herring -- the current code in Linux will
never get anywhere near triggering it because it never even tries to map
the status pages into the p2m.

IOW the call to XENMEM_add_to_physmap in
drivers/xen/grant-table.c:gnttab_map() needs to be done for the status
pages too or there is no chance of v2 grant tables working for HVM
guests.

I think the best bet is to disable v2 for HVM guests for now (something
like your second patch) and implement it for 3.4.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 22:34:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 22:34:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqBPt-0000bK-2R; Wed, 25 Jan 2012 22:34: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 1RqBPr-0000b9-O7
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 22:34:07 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327530841!12524607!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDcyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 656 invoked from network); 25 Jan 2012 22:34:01 -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;
	25 Jan 2012 22:34:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,570,1320624000"; d="scan'208";a="10292513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	25 Jan 2012 22:34:01 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Wed, 25 Jan 2012 22:34:01 +0000
Message-ID: <1327530840.856.9.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 25 Jan 2012 22:34:00 +0000
In-Reply-To: <20120125205043.GB21284@phenom.dumpdata.com>
References: <20120125044949.GB29759@phenom.dumpdata.com>
	<20120125051253.GA15501@phenom.dumpdata.com>
	<1327485333.24561.232.camel@zakaz.uk.xensource.com>
	<291EDFCB1E9E224A99088639C4762022C80E2F0F23@LONPMAILBOX01.citrite.net>
	<20120125205043.GB21284@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "ANNIE LI \(annie.li@oracle.com\)" <annie.li@oracle.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] Regressions in v3.3-rc1 introduced by
 "xen/granttable: Grant tables V2 implementation"
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 20:50 +0000, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 25, 2012 at 03:23:28PM +0000, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Paul Durrant
> > > Sent: 25 January 2012 07:17
> > > To: Ian Campbell; Konrad Rzeszutek Wilk
> > > Cc: annie.li@oracle.com; xen-devel@lists.xensource.com; linux-
> > > kernel@vger.kernel.org
> > > Subject: RE: [Xen-devel] Regressions in v3.3-rc1 introduced by
> > > "xen/granttable: Grant tables V2 implementation"
> > > 
> > > > -----Original Message-----
> > > >
> > > > On HVM for gnttab_shared we make an add_to_physmap call with
> > > > XENMAPSPACE_grant_table (in gnttab_map). I don't see any support call
> > > > to do something similar for the status array though and I don't see a
> > > > XENMAPSPACE_* specifically for that case either in the hypervisor either.
> > > >
> > > 
> > > There is no map-space for the status pages. To map them you use the
> > > standard map space but OR a bit (top bit IIRC) into in the idx. It's a bit icky,
> > > but that's how it is.
> > > 
> > 
> > I fixed a bug in xen-unstable a few weeks back that prevented
> mapping of the status frames so I guess the bug is possibly due to
> trying to use gnttab 2 on 4.1, where this bug would hit, but failing
> to check the return code from the status mapping hypercall?
> 
> changeset:   24428:5b4b7e565ab8
> user:        Paul Durrant <paul.durrant@citrix.com>
> date:        Sun Dec 18 14:39:14 2011 +0000
> summary:     Fix grant_table v2 status mapping.
> 
> changeset:   24427:931bf1105730
> user:        Paul Durrant <paul.durrant@citrix.com>
> date:        Sun Dec 18 14:38:32 2011 +0000
> summary:     Allow VMs to query their own grant table version.
> 
> 
> Looks like c/s 24427 needs to be in the hypervior. Hm, but that exists
> in 4.1 too as 23204. Will try back-porting cs 24428 in Xen 4.1 and seeing
> if that does it.

I think this bug is a red herring -- the current code in Linux will
never get anywhere near triggering it because it never even tries to map
the status pages into the p2m.

IOW the call to XENMEM_add_to_physmap in
drivers/xen/grant-table.c:gnttab_map() needs to be done for the status
pages too or there is no chance of v2 grant tables working for HVM
guests.

I think the best bet is to disable v2 for HVM guests for now (something
like your second patch) and implement it for 3.4.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Wed Jan 25 23:09:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 23: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 1RqBxH-0001AK-UV; Wed, 25 Jan 2012 23:08:40 +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 1RqBxB-0001AE-RJ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 23:08:34 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327532904!12480761!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3979 invoked from network); 25 Jan 2012 23:08:25 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 23:08:25 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0PN8KLr007324
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 15:08:21 -0800
Received: by bkar1 with SMTP id r1so5706819bka.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 15:08:19 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr7641348bkc.13.1327532899355; Wed,
	25 Jan 2012 15:08:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Wed, 25 Jan 2012 15:07:38 -0800 (PST)
In-Reply-To: <1327489725.24561.284.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
	<1327489725.24561.284.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 15:07:38 -0800
Message-ID: <CAP8mzPMed1A_BVCgoAKfcuPhRr910j8uJQFuQ_x9t9PHx0iifA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model
	suspend/resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1070106237907176106=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1070106237907176106==
Content-Type: multipart/alternative; boundary=000e0ce04044e4cbb404b7625698

--000e0ce04044e4cbb404b7625698
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 25, 2012 at 3:08 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1327358638 28800
> > # Node ID 11fb1dfda7de4d6759dec87d80cd16cf137f7369
> > # Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
> > tools/libxl: QEMU device model suspend/resume
> >
> >  * Refactor the libxl__domain_save_device_model.
> >  * Add support for suspend/resume QEMU device model
> >    (both traditional xen and QMP).
> >
> >
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >
> > diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c     Sat Jan 21 17:15:40 2012 +0000
> > +++ b/tools/libxl/libxl.c     Mon Jan 23 14:43:58 2012 -0800
> > @@ -477,7 +477,7 @@
> >
> >      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);
> > +        rc = libxl__domain_save_device_model(gc, domid, fd, /* No Remus
> */ 0);
> >      GC_FREE;
> >      return rc;
> >  }
> > diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c Sat Jan 21 17:15:40 2012 +0000
> > +++ b/tools/libxl/libxl_dom.c Mon Jan 23 14:43:58 2012 -0800
> > @@ -534,6 +534,53 @@
> >      return 0;
> >  }
> >
> > +static int libxl__remus_domain_suspend_qemu(libxl__gc *gc, uint32_t
> domid)
> > +{
> > +
> > +    switch (libxl__device_model_version_running(gc, domid)) {
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> > +        char *path = NULL;
> > +        path = libxl__sprintf(gc,
> "/local/domain/0/device-model/%d/command",
> > +                              domid);
> > +        libxl__xs_write(gc, XBT_NULL, path, "save");
> > +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL,
> NULL);
>
> This and libxl__remus_domain_resume_qemu, qemu_pci_add_xenstore,
> qemu_pci_remove_xenstore, libxl__domain_save_device_model and
> libxl_domain_unpause would probably benefit from a helper function to
> send a command to a traditional qemu.
>
> > +        break;
> > +    }
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > +        /* Stop QEMU */
> > +        if (libxl__qmp_stop(gc, domid))
> > +            return ERROR_FAIL;
> > +        break;
> > +    default:
> > +        return ERROR_INVAL;
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> > +static int libxl__remus_domain_resume_qemu(libxl__gc *gc, uint32_t
> domid)
> > +{
> > +
> > +    switch (libxl__device_model_version_running(gc, domid)) {
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> > +        char *path = NULL;
> > +        path = libxl__sprintf(gc,
> "/local/domain/0/device-model/%d/command",
> > +                              domid);
> > +        libxl__xs_write(gc, XBT_NULL, path, "continue");
> > +        break;
> > +    }
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > +        /* Stop QEMU */
> > +        if (libxl__qmp_resume(gc, domid))
> > +            return ERROR_FAIL;
> > +        break;
> > +    default:
> > +        return ERROR_INVAL;
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> >  int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> >                                   libxl_domain_type type,
> >                                   int live, int debug)
> > @@ -620,7 +667,7 @@
> >      return rc;
> >  }
> >
> > -int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int
> fd)
> > +int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int
> fd, int remus)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> >      int ret, fd2 = -1, c;
> > @@ -631,13 +678,12 @@
> >
> >      switch (libxl__device_model_version_running(gc, domid)) {
> >      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> > -        char *path = NULL;
> > -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> > -                   "Saving device model state to %s", filename);
> > -        path = libxl__sprintf(gc,
> "/local/domain/0/device-model/%d/command",
> > -                              domid);
> > -        libxl__xs_write(gc, XBT_NULL, path, "save");
> > -        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL,
> NULL);
> > +        /* For Remus,we issue suspend_qemu call separately */
>
> Why?
>
>
In remus, save and transmit device model phases are decoupled. This code
(sending the saved device model to the target) is executed after the domain
is
resumed.

The control flow in current Remus is like this:
1 suspend vm
  1.1 suspend qemu (save command, that saves the device model to a file)
2 copy out dirty memory into a buffer
3 resume vm
  3.1 resume qemu
4 send the data in the buffer
5  send the saved device model
    (xc_domain_restore extracts this from the tailbuf)



> How does this interact with Stefano's XC_SAVEID_TOOLSTACK patches?
>
>
 I couldnt find anything online by this name. Can you point me to the patch
series?


I think some sort of high level description of the control flow used by
> Remus and how/why it differs from normal save/restore would be useful
> for review.
>
> > +        if (!remus) {
> > +            c = libxl__remus_domain_suspend_qemu(gc, domid);
>
> It seems odd to call this function libxl__remus_FOO and the use it
> when !remus. The function doesn't look to be inherently specific to
> either remus or !remus anyhow.
>
> > +            if (c)
> > +                return c;
> > +        }
> >          break;
> >      }
> >      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > @@ -668,8 +714,9 @@
> >      qemu_state_len = st.st_size;
> >      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n",
> qemu_state_len);
> >
> > -    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE,
> strlen(QEMU_SIGNATURE),
> > -                              "saved-state file", "qemu signature");
> > +    ret = libxl_write_exactly(ctx, fd, remus ? REMUS_QEMU_SIGNATURE :
> QEMU_SIGNATURE,
> > +                            remus ? strlen(REMUS_QEMU_SIGNATURE):
> strlen(QEMU_SIGNATURE),
> > +                            "saved-state file", "qemu signature");
>
> QEMU_SIGNATURE is "DeviceModelRecord0002" which I believe libxc treats
> identically to the Remus signature?
>
>
Thanks. Yep, the remus_signature is redundant.


> Again consideration of how this interacts with Stefano's patch would be
> useful. If possible we'd quite like to pull the qemu-restore our of
> xc_domain_restore for consistency with how xc_domain_save saves it, the
> current layering is quite mad.
>
> Ian.
>
>

--000e0ce04044e4cbb404b7625698
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jan 25, 2012 at 3:08 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On Mon, 2012-01-23 at 22:46 +0000, =
<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; # HG changeset patch<br>
&gt; # User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">r=
shriram@cs.ubc.ca</a>&gt;<br>
&gt; # Date 1327358638 28800<br>
&gt; # Node ID 11fb1dfda7de4d6759dec87d80cd16cf137f7369<br>
&gt; # Parent =A080fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd<br>
&gt; tools/libxl: QEMU device model suspend/resume<br>
&gt;<br>
&gt; =A0* Refactor the libxl__domain_save_device_model.<br>
&gt; =A0* Add support for suspend/resume QEMU device model<br>
&gt; =A0 =A0(both traditional xen and QMP).<br>
&gt;<br>
&gt;<br>
&gt; Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.u=
bc.ca">rshriram@cs.ubc.ca</a>&gt;<br>
&gt;<br>
&gt; diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl.c<br>
&gt; --- a/tools/libxl/libxl.c =A0 =A0 Sat Jan 21 17:15:40 2012 +0000<br>
&gt; +++ b/tools/libxl/libxl.c =A0 =A0 Mon Jan 23 14:43:58 2012 -0800<br>
&gt; @@ -477,7 +477,7 @@<br>
&gt;<br>
&gt; =A0 =A0 =A0rc =3D libxl__domain_suspend_common(gc, domid, fd, type, li=
ve, debug);<br>
&gt; =A0 =A0 =A0if (!rc &amp;&amp; type =3D=3D LIBXL_DOMAIN_TYPE_HVM)<br>
&gt; - =A0 =A0 =A0 =A0rc =3D libxl__domain_save_device_model(gc, domid, fd)=
;<br>
&gt; + =A0 =A0 =A0 =A0rc =3D libxl__domain_save_device_model(gc, domid, fd,=
 /* No Remus */ 0);<br>
&gt; =A0 =A0 =A0GC_FREE;<br>
&gt; =A0 =A0 =A0return rc;<br>
&gt; =A0}<br>
&gt; diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_dom.c<br>
&gt; --- a/tools/libxl/libxl_dom.c Sat Jan 21 17:15:40 2012 +0000<br>
&gt; +++ b/tools/libxl/libxl_dom.c Mon Jan 23 14:43:58 2012 -0800<br>
&gt; @@ -534,6 +534,53 @@<br>
&gt; =A0 =A0 =A0return 0;<br>
&gt; =A0}<br>
&gt;<br>
&gt; +static int libxl__remus_domain_suspend_qemu(libxl__gc *gc, uint32_t d=
omid)<br>
&gt; +{<br>
&gt; +<br>
&gt; + =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; + =A0 =A0 =A0 =A0char *path =3D NULL;<br>
&gt; + =A0 =A0 =A0 =A0path =3D libxl__sprintf(gc, &quot;/local/domain/0/dev=
ice-model/%d/command&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid);<b=
r>
&gt; + =A0 =A0 =A0 =A0libxl__xs_write(gc, XBT_NULL, path, &quot;save&quot;)=
;<br>
&gt; + =A0 =A0 =A0 =A0libxl__wait_for_device_model(gc, domid, &quot;paused&=
quot;, NULL, NULL, NULL);<br>
<br>
</div></div>This and libxl__remus_domain_resume_qemu, qemu_pci_add_xenstore=
,<br>
qemu_pci_remove_xenstore, libxl__domain_save_device_model and<br>
libxl_domain_unpause would probably benefit from a helper function to<br>
send a command to a traditional qemu.<br>
<div><div class=3D"h5"><br>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0}<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; + =A0 =A0 =A0 =A0/* Stop QEMU */<br>
&gt; + =A0 =A0 =A0 =A0if (libxl__qmp_stop(gc, domid))<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0default:<br>
&gt; + =A0 =A0 =A0 =A0return ERROR_INVAL;<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return 0;<br>
&gt; +}<br>
&gt; +<br>
&gt; +static int libxl__remus_domain_resume_qemu(libxl__gc *gc, uint32_t do=
mid)<br>
&gt; +{<br>
&gt; +<br>
&gt; + =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; + =A0 =A0 =A0 =A0char *path =3D NULL;<br>
&gt; + =A0 =A0 =A0 =A0path =3D libxl__sprintf(gc, &quot;/local/domain/0/dev=
ice-model/%d/command&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid);<b=
r>
&gt; + =A0 =A0 =A0 =A0libxl__xs_write(gc, XBT_NULL, path, &quot;continue&qu=
ot;);<br>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0}<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; + =A0 =A0 =A0 =A0/* Stop QEMU */<br>
&gt; + =A0 =A0 =A0 =A0if (libxl__qmp_resume(gc, domid))<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0default:<br>
&gt; + =A0 =A0 =A0 =A0return ERROR_INVAL;<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return 0;<br>
&gt; +}<br>
&gt; +<br>
&gt; =A0int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int=
 fd,<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 li=
bxl_domain_type type,<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in=
t live, int debug)<br>
&gt; @@ -620,7 +667,7 @@<br>
&gt; =A0 =A0 =A0return rc;<br>
&gt; =A0}<br>
&gt;<br>
&gt; -int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, in=
t fd)<br>
&gt; +int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, in=
t fd, int remus)<br>
&gt; =A0{<br>
&gt; =A0 =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
&gt; =A0 =A0 =A0int ret, fd2 =3D -1, c;<br>
&gt; @@ -631,13 +678,12 @@<br>
&gt;<br>
&gt; =A0 =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<b=
r>
&gt; =A0 =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; - =A0 =A0 =A0 =A0char *path =3D NULL;<br>
&gt; - =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;Saving device model state =
to %s&quot;, filename);<br>
&gt; - =A0 =A0 =A0 =A0path =3D libxl__sprintf(gc, &quot;/local/domain/0/dev=
ice-model/%d/command&quot;,<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid);<b=
r>
&gt; - =A0 =A0 =A0 =A0libxl__xs_write(gc, XBT_NULL, path, &quot;save&quot;)=
;<br>
&gt; - =A0 =A0 =A0 =A0libxl__wait_for_device_model(gc, domid, &quot;paused&=
quot;, NULL, NULL, NULL);<br>
&gt; + =A0 =A0 =A0 =A0/* For Remus,we issue suspend_qemu call separately */=
<br>
<br>
</div></div>Why?<br>
<br></blockquote><div><br>In remus, save and transmit device model phases a=
re decoupled. This code <br>(sending the saved device model to the target) =
is executed after the domain is<br>resumed.<br><br>The control flow in curr=
ent Remus is like this:<br>

1 suspend vm<br>=A0 1.1 suspend qemu (save command, that saves the device m=
odel to a file)<br>2 copy out dirty memory into a buffer<br>3 resume vm <br=
>=A0 3.1 resume qemu<br>4 send the data in the buffer<br>5=A0 send the save=
d device model<br>

=A0 =A0 (xc_domain_restore extracts this from the tailbuf)<br><br>=A0</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">
How does this interact with Stefano&#39;s XC_SAVEID_TOOLSTACK patches?<br>
<br></blockquote><div><br>=A0I couldnt find anything online by this name. C=
an you point me to the patch series? <br><br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">


I think some sort of high level description of the control flow used by<br>
Remus and how/why it differs from normal save/restore would be useful<br>
for review.<br>
<div class=3D"im"><br>
&gt; + =A0 =A0 =A0 =A0if (!remus) {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0c =3D libxl__remus_domain_suspend_qemu(gc, do=
mid);<br>
<br>
</div>It seems odd to call this function libxl__remus_FOO and the use it<br=
>
when !remus. The function doesn&#39;t look to be inherently specific to<br>
either remus or !remus anyhow.<br>
<div class=3D"im"><br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0if (c)<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return c;<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0break;<br>
&gt; =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; @@ -668,8 +714,9 @@<br>
&gt; =A0 =A0 =A0qemu_state_len =3D st.st_size;<br>
&gt; =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, &quot;Qemu state is %d by=
tes\n&quot;, qemu_state_len);<br>
&gt;<br>
&gt; - =A0 =A0ret =3D libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(Q=
EMU_SIGNATURE),<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;sav=
ed-state file&quot;, &quot;qemu signature&quot;);<br>
&gt; + =A0 =A0ret =3D libxl_write_exactly(ctx, fd, remus ? REMUS_QEMU_SIGNA=
TURE : QEMU_SIGNATURE,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remus ? strle=
n(REMUS_QEMU_SIGNATURE): strlen(QEMU_SIGNATURE),<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;saved-s=
tate file&quot;, &quot;qemu signature&quot;);<br>
<br>
</div>QEMU_SIGNATURE is &quot;DeviceModelRecord0002&quot; which I believe l=
ibxc treats<br>
identically to the Remus signature?<br>
<br></blockquote><div><br>Thanks. Yep, the remus_signature is redundant.<br=
>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Again consideration of how this interacts with Stefano&#39;s patch would be=
<br>
useful. If possible we&#39;d quite like to pull the qemu-restore our of<br>
xc_domain_restore for consistency with how xc_domain_save saves it, the<br>
current layering is quite mad.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"HOEnZb"=
><font color=3D"#888888">
Ian.<br>
<br>
</font></span></blockquote></div><br>

--000e0ce04044e4cbb404b7625698--


--===============1070106237907176106==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1070106237907176106==--


From xen-devel-bounces@lists.xensource.com Wed Jan 25 23:09:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 23: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 1RqBxH-0001AK-UV; Wed, 25 Jan 2012 23:08:40 +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 1RqBxB-0001AE-RJ
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 23:08:34 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327532904!12480761!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3979 invoked from network); 25 Jan 2012 23:08:25 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-14.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 23:08:25 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0PN8KLr007324
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 15:08:21 -0800
Received: by bkar1 with SMTP id r1so5706819bka.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 15:08:19 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr7641348bkc.13.1327532899355; Wed,
	25 Jan 2012 15:08:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Wed, 25 Jan 2012 15:07:38 -0800 (PST)
In-Reply-To: <1327489725.24561.284.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
	<1327489725.24561.284.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 15:07:38 -0800
Message-ID: <CAP8mzPMed1A_BVCgoAKfcuPhRr910j8uJQFuQ_x9t9PHx0iifA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model
	suspend/resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1070106237907176106=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1070106237907176106==
Content-Type: multipart/alternative; boundary=000e0ce04044e4cbb404b7625698

--000e0ce04044e4cbb404b7625698
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 25, 2012 at 3:08 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1327358638 28800
> > # Node ID 11fb1dfda7de4d6759dec87d80cd16cf137f7369
> > # Parent  80fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd
> > tools/libxl: QEMU device model suspend/resume
> >
> >  * Refactor the libxl__domain_save_device_model.
> >  * Add support for suspend/resume QEMU device model
> >    (both traditional xen and QMP).
> >
> >
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >
> > diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl.c
> > --- a/tools/libxl/libxl.c     Sat Jan 21 17:15:40 2012 +0000
> > +++ b/tools/libxl/libxl.c     Mon Jan 23 14:43:58 2012 -0800
> > @@ -477,7 +477,7 @@
> >
> >      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);
> > +        rc = libxl__domain_save_device_model(gc, domid, fd, /* No Remus
> */ 0);
> >      GC_FREE;
> >      return rc;
> >  }
> > diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_dom.c
> > --- a/tools/libxl/libxl_dom.c Sat Jan 21 17:15:40 2012 +0000
> > +++ b/tools/libxl/libxl_dom.c Mon Jan 23 14:43:58 2012 -0800
> > @@ -534,6 +534,53 @@
> >      return 0;
> >  }
> >
> > +static int libxl__remus_domain_suspend_qemu(libxl__gc *gc, uint32_t
> domid)
> > +{
> > +
> > +    switch (libxl__device_model_version_running(gc, domid)) {
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> > +        char *path = NULL;
> > +        path = libxl__sprintf(gc,
> "/local/domain/0/device-model/%d/command",
> > +                              domid);
> > +        libxl__xs_write(gc, XBT_NULL, path, "save");
> > +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL,
> NULL);
>
> This and libxl__remus_domain_resume_qemu, qemu_pci_add_xenstore,
> qemu_pci_remove_xenstore, libxl__domain_save_device_model and
> libxl_domain_unpause would probably benefit from a helper function to
> send a command to a traditional qemu.
>
> > +        break;
> > +    }
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > +        /* Stop QEMU */
> > +        if (libxl__qmp_stop(gc, domid))
> > +            return ERROR_FAIL;
> > +        break;
> > +    default:
> > +        return ERROR_INVAL;
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> > +static int libxl__remus_domain_resume_qemu(libxl__gc *gc, uint32_t
> domid)
> > +{
> > +
> > +    switch (libxl__device_model_version_running(gc, domid)) {
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> > +        char *path = NULL;
> > +        path = libxl__sprintf(gc,
> "/local/domain/0/device-model/%d/command",
> > +                              domid);
> > +        libxl__xs_write(gc, XBT_NULL, path, "continue");
> > +        break;
> > +    }
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > +        /* Stop QEMU */
> > +        if (libxl__qmp_resume(gc, domid))
> > +            return ERROR_FAIL;
> > +        break;
> > +    default:
> > +        return ERROR_INVAL;
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> >  int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
> >                                   libxl_domain_type type,
> >                                   int live, int debug)
> > @@ -620,7 +667,7 @@
> >      return rc;
> >  }
> >
> > -int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int
> fd)
> > +int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int
> fd, int remus)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> >      int ret, fd2 = -1, c;
> > @@ -631,13 +678,12 @@
> >
> >      switch (libxl__device_model_version_running(gc, domid)) {
> >      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> > -        char *path = NULL;
> > -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> > -                   "Saving device model state to %s", filename);
> > -        path = libxl__sprintf(gc,
> "/local/domain/0/device-model/%d/command",
> > -                              domid);
> > -        libxl__xs_write(gc, XBT_NULL, path, "save");
> > -        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL,
> NULL);
> > +        /* For Remus,we issue suspend_qemu call separately */
>
> Why?
>
>
In remus, save and transmit device model phases are decoupled. This code
(sending the saved device model to the target) is executed after the domain
is
resumed.

The control flow in current Remus is like this:
1 suspend vm
  1.1 suspend qemu (save command, that saves the device model to a file)
2 copy out dirty memory into a buffer
3 resume vm
  3.1 resume qemu
4 send the data in the buffer
5  send the saved device model
    (xc_domain_restore extracts this from the tailbuf)



> How does this interact with Stefano's XC_SAVEID_TOOLSTACK patches?
>
>
 I couldnt find anything online by this name. Can you point me to the patch
series?


I think some sort of high level description of the control flow used by
> Remus and how/why it differs from normal save/restore would be useful
> for review.
>
> > +        if (!remus) {
> > +            c = libxl__remus_domain_suspend_qemu(gc, domid);
>
> It seems odd to call this function libxl__remus_FOO and the use it
> when !remus. The function doesn't look to be inherently specific to
> either remus or !remus anyhow.
>
> > +            if (c)
> > +                return c;
> > +        }
> >          break;
> >      }
> >      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > @@ -668,8 +714,9 @@
> >      qemu_state_len = st.st_size;
> >      LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Qemu state is %d bytes\n",
> qemu_state_len);
> >
> > -    ret = libxl_write_exactly(ctx, fd, QEMU_SIGNATURE,
> strlen(QEMU_SIGNATURE),
> > -                              "saved-state file", "qemu signature");
> > +    ret = libxl_write_exactly(ctx, fd, remus ? REMUS_QEMU_SIGNATURE :
> QEMU_SIGNATURE,
> > +                            remus ? strlen(REMUS_QEMU_SIGNATURE):
> strlen(QEMU_SIGNATURE),
> > +                            "saved-state file", "qemu signature");
>
> QEMU_SIGNATURE is "DeviceModelRecord0002" which I believe libxc treats
> identically to the Remus signature?
>
>
Thanks. Yep, the remus_signature is redundant.


> Again consideration of how this interacts with Stefano's patch would be
> useful. If possible we'd quite like to pull the qemu-restore our of
> xc_domain_restore for consistency with how xc_domain_save saves it, the
> current layering is quite mad.
>
> Ian.
>
>

--000e0ce04044e4cbb404b7625698
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jan 25, 2012 at 3:08 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On Mon, 2012-01-23 at 22:46 +0000, =
<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; # HG changeset patch<br>
&gt; # User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">r=
shriram@cs.ubc.ca</a>&gt;<br>
&gt; # Date 1327358638 28800<br>
&gt; # Node ID 11fb1dfda7de4d6759dec87d80cd16cf137f7369<br>
&gt; # Parent =A080fdf2182bc62ca358ba2f1a3513b47a4f8d9dfd<br>
&gt; tools/libxl: QEMU device model suspend/resume<br>
&gt;<br>
&gt; =A0* Refactor the libxl__domain_save_device_model.<br>
&gt; =A0* Add support for suspend/resume QEMU device model<br>
&gt; =A0 =A0(both traditional xen and QMP).<br>
&gt;<br>
&gt;<br>
&gt; Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.u=
bc.ca">rshriram@cs.ubc.ca</a>&gt;<br>
&gt;<br>
&gt; diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl.c<br>
&gt; --- a/tools/libxl/libxl.c =A0 =A0 Sat Jan 21 17:15:40 2012 +0000<br>
&gt; +++ b/tools/libxl/libxl.c =A0 =A0 Mon Jan 23 14:43:58 2012 -0800<br>
&gt; @@ -477,7 +477,7 @@<br>
&gt;<br>
&gt; =A0 =A0 =A0rc =3D libxl__domain_suspend_common(gc, domid, fd, type, li=
ve, debug);<br>
&gt; =A0 =A0 =A0if (!rc &amp;&amp; type =3D=3D LIBXL_DOMAIN_TYPE_HVM)<br>
&gt; - =A0 =A0 =A0 =A0rc =3D libxl__domain_save_device_model(gc, domid, fd)=
;<br>
&gt; + =A0 =A0 =A0 =A0rc =3D libxl__domain_save_device_model(gc, domid, fd,=
 /* No Remus */ 0);<br>
&gt; =A0 =A0 =A0GC_FREE;<br>
&gt; =A0 =A0 =A0return rc;<br>
&gt; =A0}<br>
&gt; diff -r 80fdf2182bc6 -r 11fb1dfda7de tools/libxl/libxl_dom.c<br>
&gt; --- a/tools/libxl/libxl_dom.c Sat Jan 21 17:15:40 2012 +0000<br>
&gt; +++ b/tools/libxl/libxl_dom.c Mon Jan 23 14:43:58 2012 -0800<br>
&gt; @@ -534,6 +534,53 @@<br>
&gt; =A0 =A0 =A0return 0;<br>
&gt; =A0}<br>
&gt;<br>
&gt; +static int libxl__remus_domain_suspend_qemu(libxl__gc *gc, uint32_t d=
omid)<br>
&gt; +{<br>
&gt; +<br>
&gt; + =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; + =A0 =A0 =A0 =A0char *path =3D NULL;<br>
&gt; + =A0 =A0 =A0 =A0path =3D libxl__sprintf(gc, &quot;/local/domain/0/dev=
ice-model/%d/command&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid);<b=
r>
&gt; + =A0 =A0 =A0 =A0libxl__xs_write(gc, XBT_NULL, path, &quot;save&quot;)=
;<br>
&gt; + =A0 =A0 =A0 =A0libxl__wait_for_device_model(gc, domid, &quot;paused&=
quot;, NULL, NULL, NULL);<br>
<br>
</div></div>This and libxl__remus_domain_resume_qemu, qemu_pci_add_xenstore=
,<br>
qemu_pci_remove_xenstore, libxl__domain_save_device_model and<br>
libxl_domain_unpause would probably benefit from a helper function to<br>
send a command to a traditional qemu.<br>
<div><div class=3D"h5"><br>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0}<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; + =A0 =A0 =A0 =A0/* Stop QEMU */<br>
&gt; + =A0 =A0 =A0 =A0if (libxl__qmp_stop(gc, domid))<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0default:<br>
&gt; + =A0 =A0 =A0 =A0return ERROR_INVAL;<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return 0;<br>
&gt; +}<br>
&gt; +<br>
&gt; +static int libxl__remus_domain_resume_qemu(libxl__gc *gc, uint32_t do=
mid)<br>
&gt; +{<br>
&gt; +<br>
&gt; + =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; + =A0 =A0 =A0 =A0char *path =3D NULL;<br>
&gt; + =A0 =A0 =A0 =A0path =3D libxl__sprintf(gc, &quot;/local/domain/0/dev=
ice-model/%d/command&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid);<b=
r>
&gt; + =A0 =A0 =A0 =A0libxl__xs_write(gc, XBT_NULL, path, &quot;continue&qu=
ot;);<br>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0}<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; + =A0 =A0 =A0 =A0/* Stop QEMU */<br>
&gt; + =A0 =A0 =A0 =A0if (libxl__qmp_resume(gc, domid))<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0default:<br>
&gt; + =A0 =A0 =A0 =A0return ERROR_INVAL;<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return 0;<br>
&gt; +}<br>
&gt; +<br>
&gt; =A0int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int=
 fd,<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 li=
bxl_domain_type type,<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in=
t live, int debug)<br>
&gt; @@ -620,7 +667,7 @@<br>
&gt; =A0 =A0 =A0return rc;<br>
&gt; =A0}<br>
&gt;<br>
&gt; -int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, in=
t fd)<br>
&gt; +int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, in=
t fd, int remus)<br>
&gt; =A0{<br>
&gt; =A0 =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(gc);<br>
&gt; =A0 =A0 =A0int ret, fd2 =3D -1, c;<br>
&gt; @@ -631,13 +678,12 @@<br>
&gt;<br>
&gt; =A0 =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<b=
r>
&gt; =A0 =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; - =A0 =A0 =A0 =A0char *path =3D NULL;<br>
&gt; - =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &quot;Saving device model state =
to %s&quot;, filename);<br>
&gt; - =A0 =A0 =A0 =A0path =3D libxl__sprintf(gc, &quot;/local/domain/0/dev=
ice-model/%d/command&quot;,<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid);<b=
r>
&gt; - =A0 =A0 =A0 =A0libxl__xs_write(gc, XBT_NULL, path, &quot;save&quot;)=
;<br>
&gt; - =A0 =A0 =A0 =A0libxl__wait_for_device_model(gc, domid, &quot;paused&=
quot;, NULL, NULL, NULL);<br>
&gt; + =A0 =A0 =A0 =A0/* For Remus,we issue suspend_qemu call separately */=
<br>
<br>
</div></div>Why?<br>
<br></blockquote><div><br>In remus, save and transmit device model phases a=
re decoupled. This code <br>(sending the saved device model to the target) =
is executed after the domain is<br>resumed.<br><br>The control flow in curr=
ent Remus is like this:<br>

1 suspend vm<br>=A0 1.1 suspend qemu (save command, that saves the device m=
odel to a file)<br>2 copy out dirty memory into a buffer<br>3 resume vm <br=
>=A0 3.1 resume qemu<br>4 send the data in the buffer<br>5=A0 send the save=
d device model<br>

=A0 =A0 (xc_domain_restore extracts this from the tailbuf)<br><br>=A0</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">
How does this interact with Stefano&#39;s XC_SAVEID_TOOLSTACK patches?<br>
<br></blockquote><div><br>=A0I couldnt find anything online by this name. C=
an you point me to the patch series? <br><br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">


I think some sort of high level description of the control flow used by<br>
Remus and how/why it differs from normal save/restore would be useful<br>
for review.<br>
<div class=3D"im"><br>
&gt; + =A0 =A0 =A0 =A0if (!remus) {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0c =3D libxl__remus_domain_suspend_qemu(gc, do=
mid);<br>
<br>
</div>It seems odd to call this function libxl__remus_FOO and the use it<br=
>
when !remus. The function doesn&#39;t look to be inherently specific to<br>
either remus or !remus anyhow.<br>
<div class=3D"im"><br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0if (c)<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return c;<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0break;<br>
&gt; =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; @@ -668,8 +714,9 @@<br>
&gt; =A0 =A0 =A0qemu_state_len =3D st.st_size;<br>
&gt; =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, &quot;Qemu state is %d by=
tes\n&quot;, qemu_state_len);<br>
&gt;<br>
&gt; - =A0 =A0ret =3D libxl_write_exactly(ctx, fd, QEMU_SIGNATURE, strlen(Q=
EMU_SIGNATURE),<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;sav=
ed-state file&quot;, &quot;qemu signature&quot;);<br>
&gt; + =A0 =A0ret =3D libxl_write_exactly(ctx, fd, remus ? REMUS_QEMU_SIGNA=
TURE : QEMU_SIGNATURE,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0remus ? strle=
n(REMUS_QEMU_SIGNATURE): strlen(QEMU_SIGNATURE),<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;saved-s=
tate file&quot;, &quot;qemu signature&quot;);<br>
<br>
</div>QEMU_SIGNATURE is &quot;DeviceModelRecord0002&quot; which I believe l=
ibxc treats<br>
identically to the Remus signature?<br>
<br></blockquote><div><br>Thanks. Yep, the remus_signature is redundant.<br=
>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Again consideration of how this interacts with Stefano&#39;s patch would be=
<br>
useful. If possible we&#39;d quite like to pull the qemu-restore our of<br>
xc_domain_restore for consistency with how xc_domain_save saves it, the<br>
current layering is quite mad.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"HOEnZb"=
><font color=3D"#888888">
Ian.<br>
<br>
</font></span></blockquote></div><br>

--000e0ce04044e4cbb404b7625698--


--===============1070106237907176106==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1070106237907176106==--


From xen-devel-bounces@lists.xensource.com Wed Jan 25 23:16:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 23: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 1RqC4J-0001LQ-O0; Wed, 25 Jan 2012 23:15:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RqC4I-0001LK-Dv
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 23:15:54 +0000
Received: from [85.158.138.51:29499] by server-4.bemta-3.messagelabs.com id
	F7/36-32238-92D802F4; Wed, 25 Jan 2012 23:15:53 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327533350!10615102!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31421 invoked from network); 25 Jan 2012 23:15:52 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 23:15:52 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0PNFlnD008472
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 15:15:49 -0800
Received: by bkar1 with SMTP id r1so5713710bka.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 15:15:46 -0800 (PST)
Received: by 10.204.130.89 with SMTP id r25mr7629143bks.49.1327533346334; Wed,
	25 Jan 2012 15:15:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Wed, 25 Jan 2012 15:15:05 -0800 (PST)
In-Reply-To: <1327490558.24561.294.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
	<1327490558.24561.294.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 15:15:05 -0800
Message-ID: <CAP8mzPNgZVUYh_Rgwsfin2-kBLniBAccrnvp6nrq0iedsQhrTQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] tools/libxl:
	suspend/postflush/commit callbacks
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="===============8881910461148374788=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8881910461148374788==
Content-Type: multipart/alternative; boundary=001517448266892a3b04b7627193

--001517448266892a3b04b7627193
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 25, 2012 at 3:22 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1327358640 28800
> > # Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef
> > # Parent  11fb1dfda7de4d6759dec87d80cd16cf137f7369
> > tools/libxl: suspend/postflush/commit callbacks
> >
> >  * Add libxl callbacks for Remus checkpoint suspend, postflush (aka
> resume)
> >    and checkpoint commit callbacks.
> >  * suspend callback just bounces off
> libxl__domain_suspend_common_callback
> >  * resume callback directly calls xc_domain_resume instead of re-using
> >    libxl_domain_resume (as the latter does not set the fast suspend
> argument
> >    to xc_domain_resume - aka suspend_cancel support).
> >  * commit callback just sleeps for the checkpoint interval (for the
> moment).
> >
> >  * Future patches will augument these callbacks with more
> functionalities like
> >    issuing network buffer plug/unplug commands, disk checkpoint
> commands, etc.
> >
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >
>
>
> > +static int libxl__remus_domain_resume_callback(void *data)
> > +{
> > +    struct suspendinfo *si = data;
> > +    libxl_ctx *ctx = libxl__gc_owner(si->gc);
> > +
> > +    /* Assumes that SUSPEND_CANCEL is available - just like
> > +     * xm version of Remus. Without that, remus wont work.
> > +     * Since libxl_domain_resume calls xc_domain_resume with
> > +     * fast_suspend = 0, we cant re-use that api.
>
> You could modify that API which would be better than duplicating its
> content. I think the "fast" flag is useful to expose to users of libxl
> but if not then you could refactor into an internal function which takes
> the flag and call it from both here and libxl_domain_resume.
>
>
I didnt want to touch any existing public interfaces, structures, etc,
especially
something so common like domain_resume. While users of xl resume (or
unpause)
wont see any difference, other libraries using the libxl API might be
affected.
But I am in favor of "exposing" the flag instead of hiding it in an
internal function,
 if there are no objections :).


shriram

--001517448266892a3b04b7627193
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jan 25, 2012 at 3:22 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_b=
lank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">


<div>On Mon, 2012-01-23 at 22:46 +0000, <a href=3D"mailto:rshriram@cs.ubc.c=
a" target=3D"_blank">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; # HG changeset patch<br>
&gt; # User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca" t=
arget=3D"_blank">rshriram@cs.ubc.ca</a>&gt;<br>
&gt; # Date 1327358640 28800<br>
&gt; # Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef<br>
&gt; # Parent =A011fb1dfda7de4d6759dec87d80cd16cf137f7369<br>
&gt; tools/libxl: suspend/postflush/commit callbacks<br>
&gt;<br>
&gt; =A0* Add libxl callbacks for Remus checkpoint suspend, postflush (aka =
resume)<br>
&gt; =A0 =A0and checkpoint commit callbacks.<br>
&gt; =A0* suspend callback just bounces off libxl__domain_suspend_common_ca=
llback<br>
&gt; =A0* resume callback directly calls xc_domain_resume instead of re-usi=
ng<br>
&gt; =A0 =A0libxl_domain_resume (as the latter does not set the fast suspen=
d argument<br>
&gt; =A0 =A0to xc_domain_resume - aka suspend_cancel support).<br>
&gt; =A0* commit callback just sleeps for the checkpoint interval (for the =
moment).<br>
&gt;<br>
&gt; =A0* Future patches will augument these callbacks with more functional=
ities like<br>
&gt; =A0 =A0issuing network buffer plug/unplug commands, disk checkpoint co=
mmands, etc.<br>
&gt;<br>
&gt; Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.u=
bc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;<br>
&gt;<br>
<br>
</div><br><div>
&gt; +static int libxl__remus_domain_resume_callback(void *data)<br>
&gt; +{<br>
&gt; + =A0 =A0struct suspendinfo *si =3D data;<br>
&gt; + =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(si-&gt;gc);<br>
&gt; +<br>
&gt; + =A0 =A0/* Assumes that SUSPEND_CANCEL is available - just like<br>
&gt; + =A0 =A0 * xm version of Remus. Without that, remus wont work.<br>
&gt; + =A0 =A0 * Since libxl_domain_resume calls xc_domain_resume with<br>
&gt; + =A0 =A0 * fast_suspend =3D 0, we cant re-use that api.<br>
<br>
</div>You could modify that API which would be better than duplicating its<=
br>
content. I think the &quot;fast&quot; flag is useful to expose to users of =
libxl<br>
but if not then you could refactor into an internal function which takes<br=
>
the flag and call it from both here and libxl_domain_resume.<br>
<div><div><br></div></div></blockquote><div><br>I didnt want to touch any e=
xisting public interfaces, structures, etc, especially<br>something so comm=
on like domain_resume. While users of xl resume (or unpause)<br>
wont see any difference, other libraries using the libxl API might be affec=
ted.<br>But I am in favor of &quot;exposing&quot; the flag instead of hidin=
g it in an internal function,<br>=A0if there are no objections :).<br>=A0</=
div>

<br>shriram<br>
</div>

--001517448266892a3b04b7627193--


--===============8881910461148374788==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8881910461148374788==--


From xen-devel-bounces@lists.xensource.com Wed Jan 25 23:16:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Wed, 25 Jan 2012 23: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 1RqC4J-0001LQ-O0; Wed, 25 Jan 2012 23:15:55 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RqC4I-0001LK-Dv
	for xen-devel@lists.xensource.com; Wed, 25 Jan 2012 23:15:54 +0000
Received: from [85.158.138.51:29499] by server-4.bemta-3.messagelabs.com id
	F7/36-32238-92D802F4; Wed, 25 Jan 2012 23:15:53 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327533350!10615102!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31421 invoked from network); 25 Jan 2012 23:15:52 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 25 Jan 2012 23:15:52 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0PNFlnD008472
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 15:15:49 -0800
Received: by bkar1 with SMTP id r1so5713710bka.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 15:15:46 -0800 (PST)
Received: by 10.204.130.89 with SMTP id r25mr7629143bks.49.1327533346334; Wed,
	25 Jan 2012 15:15:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Wed, 25 Jan 2012 15:15:05 -0800 (PST)
In-Reply-To: <1327490558.24561.294.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
	<1327490558.24561.294.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 15:15:05 -0800
Message-ID: <CAP8mzPNgZVUYh_Rgwsfin2-kBLniBAccrnvp6nrq0iedsQhrTQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] tools/libxl:
	suspend/postflush/commit callbacks
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="===============8881910461148374788=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8881910461148374788==
Content-Type: multipart/alternative; boundary=001517448266892a3b04b7627193

--001517448266892a3b04b7627193
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 25, 2012 at 3:22 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1327358640 28800
> > # Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef
> > # Parent  11fb1dfda7de4d6759dec87d80cd16cf137f7369
> > tools/libxl: suspend/postflush/commit callbacks
> >
> >  * Add libxl callbacks for Remus checkpoint suspend, postflush (aka
> resume)
> >    and checkpoint commit callbacks.
> >  * suspend callback just bounces off
> libxl__domain_suspend_common_callback
> >  * resume callback directly calls xc_domain_resume instead of re-using
> >    libxl_domain_resume (as the latter does not set the fast suspend
> argument
> >    to xc_domain_resume - aka suspend_cancel support).
> >  * commit callback just sleeps for the checkpoint interval (for the
> moment).
> >
> >  * Future patches will augument these callbacks with more
> functionalities like
> >    issuing network buffer plug/unplug commands, disk checkpoint
> commands, etc.
> >
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> >
>
>
> > +static int libxl__remus_domain_resume_callback(void *data)
> > +{
> > +    struct suspendinfo *si = data;
> > +    libxl_ctx *ctx = libxl__gc_owner(si->gc);
> > +
> > +    /* Assumes that SUSPEND_CANCEL is available - just like
> > +     * xm version of Remus. Without that, remus wont work.
> > +     * Since libxl_domain_resume calls xc_domain_resume with
> > +     * fast_suspend = 0, we cant re-use that api.
>
> You could modify that API which would be better than duplicating its
> content. I think the "fast" flag is useful to expose to users of libxl
> but if not then you could refactor into an internal function which takes
> the flag and call it from both here and libxl_domain_resume.
>
>
I didnt want to touch any existing public interfaces, structures, etc,
especially
something so common like domain_resume. While users of xl resume (or
unpause)
wont see any difference, other libraries using the libxl API might be
affected.
But I am in favor of "exposing" the flag instead of hiding it in an
internal function,
 if there are no objections :).


shriram

--001517448266892a3b04b7627193
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jan 25, 2012 at 3:22 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com" target=3D"_b=
lank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">


<div>On Mon, 2012-01-23 at 22:46 +0000, <a href=3D"mailto:rshriram@cs.ubc.c=
a" target=3D"_blank">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; # HG changeset patch<br>
&gt; # User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca" t=
arget=3D"_blank">rshriram@cs.ubc.ca</a>&gt;<br>
&gt; # Date 1327358640 28800<br>
&gt; # Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef<br>
&gt; # Parent =A011fb1dfda7de4d6759dec87d80cd16cf137f7369<br>
&gt; tools/libxl: suspend/postflush/commit callbacks<br>
&gt;<br>
&gt; =A0* Add libxl callbacks for Remus checkpoint suspend, postflush (aka =
resume)<br>
&gt; =A0 =A0and checkpoint commit callbacks.<br>
&gt; =A0* suspend callback just bounces off libxl__domain_suspend_common_ca=
llback<br>
&gt; =A0* resume callback directly calls xc_domain_resume instead of re-usi=
ng<br>
&gt; =A0 =A0libxl_domain_resume (as the latter does not set the fast suspen=
d argument<br>
&gt; =A0 =A0to xc_domain_resume - aka suspend_cancel support).<br>
&gt; =A0* commit callback just sleeps for the checkpoint interval (for the =
moment).<br>
&gt;<br>
&gt; =A0* Future patches will augument these callbacks with more functional=
ities like<br>
&gt; =A0 =A0issuing network buffer plug/unplug commands, disk checkpoint co=
mmands, etc.<br>
&gt;<br>
&gt; Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.u=
bc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a>&gt;<br>
&gt;<br>
<br>
</div><br><div>
&gt; +static int libxl__remus_domain_resume_callback(void *data)<br>
&gt; +{<br>
&gt; + =A0 =A0struct suspendinfo *si =3D data;<br>
&gt; + =A0 =A0libxl_ctx *ctx =3D libxl__gc_owner(si-&gt;gc);<br>
&gt; +<br>
&gt; + =A0 =A0/* Assumes that SUSPEND_CANCEL is available - just like<br>
&gt; + =A0 =A0 * xm version of Remus. Without that, remus wont work.<br>
&gt; + =A0 =A0 * Since libxl_domain_resume calls xc_domain_resume with<br>
&gt; + =A0 =A0 * fast_suspend =3D 0, we cant re-use that api.<br>
<br>
</div>You could modify that API which would be better than duplicating its<=
br>
content. I think the &quot;fast&quot; flag is useful to expose to users of =
libxl<br>
but if not then you could refactor into an internal function which takes<br=
>
the flag and call it from both here and libxl_domain_resume.<br>
<div><div><br></div></div></blockquote><div><br>I didnt want to touch any e=
xisting public interfaces, structures, etc, especially<br>something so comm=
on like domain_resume. While users of xl resume (or unpause)<br>
wont see any difference, other libraries using the libxl API might be affec=
ted.<br>But I am in favor of &quot;exposing&quot; the flag instead of hidin=
g it in an internal function,<br>=A0if there are no objections :).<br>=A0</=
div>

<br>shriram<br>
</div>

--001517448266892a3b04b7627193--


--===============8881910461148374788==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8881910461148374788==--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 00:11:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 00:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqCvE-0002Zn-6t; Thu, 26 Jan 2012 00:10:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RqCvB-0002Zi-RR
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 00:10:34 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327536624!11978613!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27870 invoked from network); 26 Jan 2012 00:10:25 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 00:10:25 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0Q0AKnG024475
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 16:10:21 -0800
Received: by bkar1 with SMTP id r1so6007bka.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 16:10:19 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr7716173bkc.13.1327536619353; Wed,
	25 Jan 2012 16:10:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Wed, 25 Jan 2012 16:09:38 -0800 (PST)
In-Reply-To: <1327492324.24561.309.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
	<1327492324.24561.309.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 16:09:38 -0800
Message-ID: <CAP8mzPN3R=39smy2Ysd1GR6LiZ6z1BnDpEwRojTNtUJkXOS1mA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/libxl: xl remus/remus-receive
	commands
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="===============7803345780401809841=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7803345780401809841==
Content-Type: multipart/alternative; boundary=000e0ce040449f771e04b76334a4

--000e0ce040449f771e04b76334a4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 25, 2012 at 3:52 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> >
>
> > diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c  Mon Jan 23 14:44:00 2012 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c  Mon Jan 23 14:44:02 2012 -0800
> > @@ -1814,7 +1814,7 @@
> >       * If we have daemonized then do not return to the caller -- this
> has
> >       * already happened in the parent.
> >       */
> > -    if ( !need_daemon )
> > +    if ( daemonize && !need_daemon )
>
> What is this change for?
>
>
Sorry my bad. I should have sent it out as a separate patch. Well, if you
look at the control flow in the create_domain function , you would realize
that this is a bug.

create_domain()
{
 int daemonize = dom_info->daemonize;
 ....
 int need_daemon = daemonize;

 restore_domain() or create_new()

 if (!daemonize && !monitor) goto out;

 if (need_daemon) {
    fork()
    daemon()..
    need_daemon = 0;
 }
 ...
out:
         /* If we have daemonized then do not return to the caller -- this
has
         * already happened in the parent.
         */
        if ( !need_daemon )
         exit()

}


So, even if one explicitly sets daemonize to 0, the function will never
return to the
caller. I needed it to return to the caller (remus_receiver() ), to take
further actions.

 >          exit(ret);
> >
> >      return ret;
> > @@ -5853,6 +5853,175 @@
> >      return ret;
> >  }
> >
> > +int main_remus_receive(int argc, char **argv)
>
> Can this not be done as a flag to migrate-receive? Likewise is there
> common code between the remus migrate and regular migration?
>
>
It can but it would basically terminate after the create_domain() call in
the
migrate_receive function. I would have to have something like
 if (remus) {
   dont wait for permission to start domain
   try renaming domain
   unpause domain
   return
 }

and a bunch of if (remus) flags peppered around the migrate receive
function.

Having it in a separate function allows me to add support for creating a TCP
channel that receives the checkpoints, add hooks or call external
libraries/binaries
that allows the user to check for split-brain before resuming the domain.

Is there any reason that remus would not benefit from the xl migration
> protocol preamble?
>
>
No specific reason.

> +{
> > +    int rc;
> > +    char *migration_domname;
> > +    struct domain_create dom_info;
> > +
> > +    signal(SIGPIPE, SIG_IGN);
> > +    memset(&dom_info, 0, sizeof(dom_info));
> > +    dom_info.debug = 1;
> > +    dom_info.no_incr_generationid = 1;
> > +    dom_info.restore_file = "incoming checkpoint stream";
> > +    dom_info.migrate_fd = 0; /* stdin - will change in future*/
> > +    dom_info.migration_domname_r = &migration_domname;
> > +
> > +    rc = create_domain(&dom_info);
>
> I'm totally failing to see where the Remus'ness of this create_domain
> comes from.
>
>
dom_info.daemonize = 0, .monitor = 0 and .paused = 0;

As I said earlier, this part is probably the only duplication between
migrate-receive
and remus-receive. With Xend, there was no separate remus receiver, to
control
what happens on the backup host. Now that I have an opportunity to
incorporate
remus into the toolstack from start, I thought I will keep the remus
control flow as separate as possible
and not have to worry about breaking live migration (nor complicate its
code).


> +    if (rc < 0) {
> > +        fprintf(stderr, "migration target (Remus): Domain creation
> failed"
> > +                " (code %d) domid %u.\n", rc, domid);
> > +        exit(-rc);
> > +    }
> > +
> > +    /* If we are here, it means that the sender (primary) has crashed.
> > +     * If domain renaming fails, lets just continue (as we need the
> domain
> > +     * to be up & dom names may not matter much, as long as its
> reachable
> > +     * over network).
> > +     *
> > +     * If domain unpausing fails, destroy domain ? Or is it better to
> have
> > +     * a consistent copy of the domain (memory, cpu state, disk)
> > +     * on atleast one physical host ? Right now, lets just leave the
> domain
>
>              at least
>
> > +     * as is and let the Administrator decide (or troubleshoot).
> > +     */
> > +    fprintf(stderr, "migration target: Remus Failover for domain %u\n",
> domid);
> > +    if (migration_domname) {
> > +        rc = libxl_domain_rename(ctx, domid, migration_domname,
> > +                                 common_domname);
> > +        if (rc)
> > +            fprintf(stderr, "migration target (Remus): "
> > +                    "Failed to rename domain from %s to %s:%d\n",
> > +                    migration_domname, common_domname, rc);
> > +
> > +        rc = libxl_domain_unpause(ctx, domid);
> > +        if (rc)
> > +            fprintf(stderr, "migration target (Remus): "
> > +                    "Failed to unpause domain %s (id: %u):%d\n",
> > +                    common_domname, domid, rc);
> > +    }
> > +
> > +    return -rc;
> > +}
> > +
> > +int main_remus(int argc, char **argv)
> > +{
> > +    int opt, rc;
> > +    const char *ssh_command = "ssh";
> > +    char *host = NULL, *rune = NULL, *domain = NULL;
> > +
> > +    int sendpipe[2], recvpipe[2];
> > +    int send_fd = -1, recv_fd = -1;
> > +    pid_t child = -1;
> > +
> > +    uint8_t *config_data;
> > +    int config_len;
> > +
> > +    libxl_domain_remus_info r_info;
> > +
> > +    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
> > +    /* Defaults */
> > +    r_info.interval = 200;
> > +    r_info.blackhole = 0;
> > +    r_info.compression = 1;
> > +
> > +    while ((opt = def_getopt(argc, argv, "bui:s:", "remus", 2)) != -1) {
>
> main_migrate handles a bunch of other options which might also be
> interesting in the Remus case? Better would be to add all this as an
> option to the std migrate.
>


Negative. It would look totally unintuitive to have a checkpoint interval
option (or blackhole
replication option) in a live migration command. To an end user, remus is
just a HA system
and live migration is for moving VMs around. What is the point in trying to
educate him/her
that remus is basically "continuous live migration" ?

Imagine a command like
 "xl migrate --R --i 100 --N Guest Backup"
and help options like
  "-R enable remus HA
   -i remus checkpoint interval
   -N disable network buffering in Remus"

To you and me, as devs, it may not matter. But to common users who are
mostly going to
use just live migration, this would be utterly confusing.



> > +        switch (opt) {
> > +        case 0: case 2:
> > +            return opt;
> > +
> > +        case 'i':
> > +           r_info.interval = atoi(optarg);
> > +            break;
> > +        case 'b':
> > +            r_info.blackhole = 1;
> > +            break;
> > +        case 'u':
> > +           r_info.compression = 0;
> > +            break;
> > +        case 's':
> > +            ssh_command = optarg;
> > +            break;
> > +        }
> > +    }
> > +
> > +    domain = argv[optind];
> > +    host = argv[optind + 1];
> > +
> > +    if (r_info.blackhole) {
> > +        find_domain(domain);
> > +        send_fd = open("/dev/null", O_RDWR, 0644);
> > +        if (send_fd < 0) {
> > +            perror("failed to open /dev/null");
> > +            exit(-1);
> > +        }
> > +    } else {
>
> The following duplicates an awful lot of main_migrate which begs for
> them to either be the same underlying command or at least for some
> refactoring.
>
>
I agree.


> > +
> > +        if (!ssh_command[0]) {
> > +            rune = host;
> > +        } else {
> > +            if (asprintf(&rune, "exec %s %s xl remus-receive",
> > +                         ssh_command, host) < 0)
> > +                return 1;
> > +        }
> > +
> > +        save_domain_core_begin(domain, NULL, &config_data, &config_len);
> > +
> > +        if (!config_len) {
> > +            fprintf(stderr, "No config file stored for running domain
> and "
> > +                    "none supplied - cannot start remus.\n");
> > +            exit(1);
> > +        }
> > +
> > +        MUST( libxl_pipe(ctx, sendpipe) );
> > +        MUST( libxl_pipe(ctx, recvpipe) );
> > +
> > +        child = libxl_fork(ctx);
> > +        if (child==-1) exit(1);
> > +
> > +        /* TODO: change this to plain TCP socket based channel
> > +         * instead of SSH.
>
> There are good reasons for using ssh though. However the user can supply
> another command which is not encrypted if they want to.
>
Whatever happens here the same arguments would apply to non-remus
> migration so the changes should be done for both (or better the code
> should be made more common.
>
> Ian.
>
>
>

--000e0ce040449f771e04b76334a4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jan 25, 2012 at 3:52 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

&gt;<br><div><div class=3D"h5">
<br>
</div></div><div class=3D"im">&gt; diff -r 0446591bee86 -r 822536df4aec too=
ls/libxl/xl_cmdimpl.c<br>
&gt; --- a/tools/libxl/xl_cmdimpl.c =A0Mon Jan 23 14:44:00 2012 -0800<br>
&gt; +++ b/tools/libxl/xl_cmdimpl.c =A0Mon Jan 23 14:44:02 2012 -0800<br>
&gt; @@ -1814,7 +1814,7 @@<br>
&gt; =A0 =A0 =A0 * If we have daemonized then do not return to the caller -=
- this has<br>
&gt; =A0 =A0 =A0 * already happened in the parent.<br>
&gt; =A0 =A0 =A0 */<br>
&gt; - =A0 =A0if ( !need_daemon )<br>
&gt; + =A0 =A0if ( daemonize &amp;&amp; !need_daemon )<br>
<br>
</div>What is this change for?<br>
<div class=3D"im"><br></div></blockquote><div><br>Sorry my bad. I should ha=
ve sent it out as a separate patch. Well, if you <br>look at the control fl=
ow in the create_domain function , you would realize<br>that this is a bug.=
<br>

<br>create_domain() <br>{<br>=A0int daemonize =3D dom_info-&gt;daemonize;<b=
r>=A0....<br>=A0int need_daemon =3D daemonize;<br><br>=A0restore_domain() o=
r create_new()<br><br>=A0if (!daemonize &amp;&amp; !monitor) goto out;<br>=
=A0<br>=A0if (need_daemon) {<br>

=A0=A0=A0 fork()<br>=A0=A0=A0 daemon()..<br>=A0=A0=A0 need_daemon =3D 0;<br=
>=A0}<br>=A0...<br>out:<br>=A0=A0=A0=A0=A0=A0=A0=A0 /* If we have daemonize=
d then do not return to the caller -- this has<br>=A0 =A0 =A0=A0 =A0 * alre=
ady happened in the parent.<br>
=A0=A0 =A0 =A0 =A0 */<br>=A0=A0=A0=A0=A0=A0=A0 if ( !need_daemon )<br>=A0=
=A0=A0=A0=A0=A0=A0=A0 exit()<br><br>
}<br><br><br>So, even if one explicitly sets daemonize to 0, the function w=
ill never return to the<br>caller. I needed it to return to the caller (rem=
us_receiver() ), to take further actions.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">

<div class=3D"im">
&gt; =A0 =A0 =A0 =A0 =A0exit(ret);<br>
&gt;<br>
&gt; =A0 =A0 =A0return ret;<br>
&gt; @@ -5853,6 +5853,175 @@<br>
&gt; =A0 =A0 =A0return ret;<br>
&gt; =A0}<br>
&gt;<br>
&gt; +int main_remus_receive(int argc, char **argv)<br>
<br>
</div>Can this not be done as a flag to migrate-receive? Likewise is there<=
br>
common code between the remus migrate and regular migration?<br>
<br></blockquote><div><br>It can but it would basically terminate after the=
 create_domain() call in the<br>migrate_receive function. I would have to h=
ave something like<br>=A0if (remus) {<br>=A0=A0 dont wait for permission to=
 start domain<br>

=A0=A0 try renaming domain<br>=A0=A0 unpause domain<br>=A0=A0 return<br>=A0=
}<br><br>and a bunch of if (remus) flags peppered around the migrate receiv=
e function.<br><br>Having it in a separate function allows me to add suppor=
t for creating a TCP<br>

channel that receives the checkpoints, add hooks or call external libraries=
/binaries<br>that allows the user to check for split-brain before resuming =
the domain.<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">


Is there any reason that remus would not benefit from the xl migration<br>
protocol preamble?<br>
<div class=3D"im"><br></div></blockquote><div><br>No specific reason.=A0 <b=
r><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=
"im">


&gt; +{<br>
&gt; + =A0 =A0int rc;<br>
&gt; + =A0 =A0char *migration_domname;<br>
&gt; + =A0 =A0struct domain_create dom_info;<br>
&gt; +<br>
&gt; + =A0 =A0signal(SIGPIPE, SIG_IGN);<br>
&gt; + =A0 =A0memset(&amp;dom_info, 0, sizeof(dom_info));<br>
&gt; + =A0 =A0dom_info.debug =3D 1;<br>
&gt; + =A0 =A0dom_info.no_incr_generationid =3D 1;<br>
&gt; + =A0 =A0dom_info.restore_file =3D &quot;incoming checkpoint stream&qu=
ot;;<br>
&gt; + =A0 =A0dom_info.migrate_fd =3D 0; /* stdin - will change in future*/=
<br>
&gt; + =A0 =A0dom_info.migration_domname_r =3D &amp;migration_domname;<br>
&gt; +<br>
&gt; + =A0 =A0rc =3D create_domain(&amp;dom_info);<br>
<br>
</div>I&#39;m totally failing to see where the Remus&#39;ness of this creat=
e_domain<br>
comes from.<br>
<div class=3D"im"><br></div></blockquote><div><br>dom_info.daemonize =3D 0,=
 .monitor =3D 0 and .paused =3D 0;<br><br>As I said earlier, this part is p=
robably the only duplication between migrate-receive<br>and remus-receive. =
With Xend, there was no separate remus receiver, to control<br>

what happens on the backup host. Now that I have an opportunity to incorpor=
ate<br>remus into the toolstack from start, I thought I will keep the remus=
 control flow as separate as possible<br>and not have to worry about breaki=
ng live migration (nor complicate its code).<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"im">
&gt; + =A0 =A0if (rc &lt; 0) {<br>
&gt; + =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Remus): Domai=
n creation failed&quot;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot; (code %d) domid %u.\n&quot;, r=
c, domid);<br>
&gt; + =A0 =A0 =A0 =A0exit(-rc);<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0/* If we are here, it means that the sender (primary) has cra=
shed.<br>
&gt; + =A0 =A0 * If domain renaming fails, lets just continue (as we need t=
he domain<br>
&gt; + =A0 =A0 * to be up &amp; dom names may not matter much, as long as i=
ts reachable<br>
&gt; + =A0 =A0 * over network).<br>
&gt; + =A0 =A0 *<br>
&gt; + =A0 =A0 * If domain unpausing fails, destroy domain ? Or is it bette=
r to have<br>
&gt; + =A0 =A0 * a consistent copy of the domain (memory, cpu state, disk)<=
br>
&gt; + =A0 =A0 * on atleast one physical host ? Right now, lets just leave =
the domain<br>
<br>
</div> =A0 =A0 =A0 =A0 =A0 =A0 at least<br>
<div><div class=3D"h5"><br>
&gt; + =A0 =A0 * as is and let the Administrator decide (or troubleshoot).<=
br>
&gt; + =A0 =A0 */<br>
&gt; + =A0 =A0fprintf(stderr, &quot;migration target: Remus Failover for do=
main %u\n&quot;, domid);<br>
&gt; + =A0 =A0if (migration_domname) {<br>
&gt; + =A0 =A0 =A0 =A0rc =3D libxl_domain_rename(ctx, domid, migration_domn=
ame,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 comm=
on_domname);<br>
&gt; + =A0 =A0 =A0 =A0if (rc)<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Remus=
): &quot;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;Failed to rename domain=
 from %s to %s:%d\n&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0migration_domname, common_dom=
name, rc);<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0rc =3D libxl_domain_unpause(ctx, domid);<br>
&gt; + =A0 =A0 =A0 =A0if (rc)<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Remus=
): &quot;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;Failed to unpause domai=
n %s (id: %u):%d\n&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0common_domname, domid, rc);<b=
r>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return -rc;<br>
&gt; +}<br>
&gt; +<br>
&gt; +int main_remus(int argc, char **argv)<br>
&gt; +{<br>
&gt; + =A0 =A0int opt, rc;<br>
&gt; + =A0 =A0const char *ssh_command =3D &quot;ssh&quot;;<br>
&gt; + =A0 =A0char *host =3D NULL, *rune =3D NULL, *domain =3D NULL;<br>
&gt; +<br>
&gt; + =A0 =A0int sendpipe[2], recvpipe[2];<br>
&gt; + =A0 =A0int send_fd =3D -1, recv_fd =3D -1;<br>
&gt; + =A0 =A0pid_t child =3D -1;<br>
&gt; +<br>
&gt; + =A0 =A0uint8_t *config_data;<br>
&gt; + =A0 =A0int config_len;<br>
&gt; +<br>
&gt; + =A0 =A0libxl_domain_remus_info r_info;<br>
&gt; +<br>
&gt; + =A0 =A0memset(&amp;r_info, 0, sizeof(libxl_domain_remus_info));<br>
&gt; + =A0 =A0/* Defaults */<br>
&gt; + =A0 =A0r_info.interval =3D 200;<br>
&gt; + =A0 =A0r_info.blackhole =3D 0;<br>
&gt; + =A0 =A0r_info.compression =3D 1;<br>
&gt; +<br>
&gt; + =A0 =A0while ((opt =3D def_getopt(argc, argv, &quot;bui:s:&quot;, &q=
uot;remus&quot;, 2)) !=3D -1) {<br>
<br>
</div></div>main_migrate handles a bunch of other options which might also =
be<br>
interesting in the Remus case? Better would be to add all this as an<br>
option to the std migrate.<br></blockquote><div><br><br>Negative. It would =
look totally unintuitive to have a checkpoint interval option (or blackhole=
<br>replication option) in a live migration command. To an end user, remus =
is just a HA system<br>

and live migration is for moving VMs around. What is the point in trying to=
 educate him/her<br>
that remus is basically &quot;continuous live migration&quot; ? <br><br>Ima=
gine a command like<br>=A0&quot;xl migrate --R --i 100 --N Guest Backup&quo=
t;<br>and help options like<br>=A0 &quot;-R enable remus HA<br>=A0=A0 -i re=
mus checkpoint interval<br>

=A0=A0 -N disable network buffering in Remus&quot;<br><br>To you and me, as=
 devs, it may not matter. But to common users who are mostly going to<br>us=
e just live migration, this would be utterly confusing.<br><br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">


<div><div class=3D"h5"><br>
&gt; + =A0 =A0 =A0 =A0switch (opt) {<br>
&gt; + =A0 =A0 =A0 =A0case 0: case 2:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return opt;<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0case &#39;i&#39;:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 r_info.interval =3D atoi(optarg);<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0 =A0 =A0case &#39;b&#39;:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0r_info.blackhole =3D 1;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0 =A0 =A0case &#39;u&#39;:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 r_info.compression =3D 0;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0 =A0 =A0case &#39;s&#39;:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0ssh_command =3D optarg;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0domain =3D argv[optind];<br>
&gt; + =A0 =A0host =3D argv[optind + 1];<br>
&gt; +<br>
&gt; + =A0 =A0if (r_info.blackhole) {<br>
&gt; + =A0 =A0 =A0 =A0find_domain(domain);<br>
&gt; + =A0 =A0 =A0 =A0send_fd =3D open(&quot;/dev/null&quot;, O_RDWR, 0644)=
;<br>
&gt; + =A0 =A0 =A0 =A0if (send_fd &lt; 0) {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0perror(&quot;failed to open /dev/null&quot;);=
<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0exit(-1);<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; + =A0 =A0} else {<br>
<br>
</div></div>The following duplicates an awful lot of main_migrate which beg=
s for<br>
them to either be the same underlying command or at least for some<br>
refactoring.<br>
<div><div class=3D"h5"><br></div></div></blockquote><div><br>I agree.<br>=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div cl=
ass=3D"h5">


&gt; +<br>
&gt; + =A0 =A0 =A0 =A0if (!ssh_command[0]) {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0rune =3D host;<br>
&gt; + =A0 =A0 =A0 =A0} else {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0if (asprintf(&amp;rune, &quot;exec %s %s xl r=
emus-receive&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssh_command, host) &=
lt; 0)<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0save_domain_core_begin(domain, NULL, &amp;config_data=
, &amp;config_len);<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0if (!config_len) {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;No config file stored f=
or running domain and &quot;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;none supplied - cannot =
start remus.\n&quot;);<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0exit(1);<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0MUST( libxl_pipe(ctx, sendpipe) );<br>
&gt; + =A0 =A0 =A0 =A0MUST( libxl_pipe(ctx, recvpipe) );<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0child =3D libxl_fork(ctx);<br>
&gt; + =A0 =A0 =A0 =A0if (child=3D=3D-1) exit(1);<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0/* TODO: change this to plain TCP socket based channe=
l<br>
&gt; + =A0 =A0 =A0 =A0 * instead of SSH.<br>
<br>
</div></div>There are good reasons for using ssh though. However the user c=
an supply<br>
another command which is not encrypted if they want to. <br></blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
Whatever happens here the same arguments would apply to non-remus<br>
migration so the changes should be done for both (or better the code<br>
should be made more common.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br>

--000e0ce040449f771e04b76334a4--


--===============7803345780401809841==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7803345780401809841==--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 00:11:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 00:11:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqCvE-0002Zn-6t; Thu, 26 Jan 2012 00:10:36 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RqCvB-0002Zi-RR
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 00:10:34 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327536624!11978613!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_30_40,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27870 invoked from network); 26 Jan 2012 00:10:25 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 00:10:25 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0Q0AKnG024475
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Wed, 25 Jan 2012 16:10:21 -0800
Received: by bkar1 with SMTP id r1so6007bka.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 16:10:19 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr7716173bkc.13.1327536619353; Wed,
	25 Jan 2012 16:10:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Wed, 25 Jan 2012 16:09:38 -0800 (PST)
In-Reply-To: <1327492324.24561.309.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
	<1327492324.24561.309.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Wed, 25 Jan 2012 16:09:38 -0800
Message-ID: <CAP8mzPN3R=39smy2Ysd1GR6LiZ6z1BnDpEwRojTNtUJkXOS1mA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/libxl: xl remus/remus-receive
	commands
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="===============7803345780401809841=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7803345780401809841==
Content-Type: multipart/alternative; boundary=000e0ce040449f771e04b76334a4

--000e0ce040449f771e04b76334a4
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 25, 2012 at 3:52 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> >
>
> > diff -r 0446591bee86 -r 822536df4aec tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c  Mon Jan 23 14:44:00 2012 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c  Mon Jan 23 14:44:02 2012 -0800
> > @@ -1814,7 +1814,7 @@
> >       * If we have daemonized then do not return to the caller -- this
> has
> >       * already happened in the parent.
> >       */
> > -    if ( !need_daemon )
> > +    if ( daemonize && !need_daemon )
>
> What is this change for?
>
>
Sorry my bad. I should have sent it out as a separate patch. Well, if you
look at the control flow in the create_domain function , you would realize
that this is a bug.

create_domain()
{
 int daemonize = dom_info->daemonize;
 ....
 int need_daemon = daemonize;

 restore_domain() or create_new()

 if (!daemonize && !monitor) goto out;

 if (need_daemon) {
    fork()
    daemon()..
    need_daemon = 0;
 }
 ...
out:
         /* If we have daemonized then do not return to the caller -- this
has
         * already happened in the parent.
         */
        if ( !need_daemon )
         exit()

}


So, even if one explicitly sets daemonize to 0, the function will never
return to the
caller. I needed it to return to the caller (remus_receiver() ), to take
further actions.

 >          exit(ret);
> >
> >      return ret;
> > @@ -5853,6 +5853,175 @@
> >      return ret;
> >  }
> >
> > +int main_remus_receive(int argc, char **argv)
>
> Can this not be done as a flag to migrate-receive? Likewise is there
> common code between the remus migrate and regular migration?
>
>
It can but it would basically terminate after the create_domain() call in
the
migrate_receive function. I would have to have something like
 if (remus) {
   dont wait for permission to start domain
   try renaming domain
   unpause domain
   return
 }

and a bunch of if (remus) flags peppered around the migrate receive
function.

Having it in a separate function allows me to add support for creating a TCP
channel that receives the checkpoints, add hooks or call external
libraries/binaries
that allows the user to check for split-brain before resuming the domain.

Is there any reason that remus would not benefit from the xl migration
> protocol preamble?
>
>
No specific reason.

> +{
> > +    int rc;
> > +    char *migration_domname;
> > +    struct domain_create dom_info;
> > +
> > +    signal(SIGPIPE, SIG_IGN);
> > +    memset(&dom_info, 0, sizeof(dom_info));
> > +    dom_info.debug = 1;
> > +    dom_info.no_incr_generationid = 1;
> > +    dom_info.restore_file = "incoming checkpoint stream";
> > +    dom_info.migrate_fd = 0; /* stdin - will change in future*/
> > +    dom_info.migration_domname_r = &migration_domname;
> > +
> > +    rc = create_domain(&dom_info);
>
> I'm totally failing to see where the Remus'ness of this create_domain
> comes from.
>
>
dom_info.daemonize = 0, .monitor = 0 and .paused = 0;

As I said earlier, this part is probably the only duplication between
migrate-receive
and remus-receive. With Xend, there was no separate remus receiver, to
control
what happens on the backup host. Now that I have an opportunity to
incorporate
remus into the toolstack from start, I thought I will keep the remus
control flow as separate as possible
and not have to worry about breaking live migration (nor complicate its
code).


> +    if (rc < 0) {
> > +        fprintf(stderr, "migration target (Remus): Domain creation
> failed"
> > +                " (code %d) domid %u.\n", rc, domid);
> > +        exit(-rc);
> > +    }
> > +
> > +    /* If we are here, it means that the sender (primary) has crashed.
> > +     * If domain renaming fails, lets just continue (as we need the
> domain
> > +     * to be up & dom names may not matter much, as long as its
> reachable
> > +     * over network).
> > +     *
> > +     * If domain unpausing fails, destroy domain ? Or is it better to
> have
> > +     * a consistent copy of the domain (memory, cpu state, disk)
> > +     * on atleast one physical host ? Right now, lets just leave the
> domain
>
>              at least
>
> > +     * as is and let the Administrator decide (or troubleshoot).
> > +     */
> > +    fprintf(stderr, "migration target: Remus Failover for domain %u\n",
> domid);
> > +    if (migration_domname) {
> > +        rc = libxl_domain_rename(ctx, domid, migration_domname,
> > +                                 common_domname);
> > +        if (rc)
> > +            fprintf(stderr, "migration target (Remus): "
> > +                    "Failed to rename domain from %s to %s:%d\n",
> > +                    migration_domname, common_domname, rc);
> > +
> > +        rc = libxl_domain_unpause(ctx, domid);
> > +        if (rc)
> > +            fprintf(stderr, "migration target (Remus): "
> > +                    "Failed to unpause domain %s (id: %u):%d\n",
> > +                    common_domname, domid, rc);
> > +    }
> > +
> > +    return -rc;
> > +}
> > +
> > +int main_remus(int argc, char **argv)
> > +{
> > +    int opt, rc;
> > +    const char *ssh_command = "ssh";
> > +    char *host = NULL, *rune = NULL, *domain = NULL;
> > +
> > +    int sendpipe[2], recvpipe[2];
> > +    int send_fd = -1, recv_fd = -1;
> > +    pid_t child = -1;
> > +
> > +    uint8_t *config_data;
> > +    int config_len;
> > +
> > +    libxl_domain_remus_info r_info;
> > +
> > +    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
> > +    /* Defaults */
> > +    r_info.interval = 200;
> > +    r_info.blackhole = 0;
> > +    r_info.compression = 1;
> > +
> > +    while ((opt = def_getopt(argc, argv, "bui:s:", "remus", 2)) != -1) {
>
> main_migrate handles a bunch of other options which might also be
> interesting in the Remus case? Better would be to add all this as an
> option to the std migrate.
>


Negative. It would look totally unintuitive to have a checkpoint interval
option (or blackhole
replication option) in a live migration command. To an end user, remus is
just a HA system
and live migration is for moving VMs around. What is the point in trying to
educate him/her
that remus is basically "continuous live migration" ?

Imagine a command like
 "xl migrate --R --i 100 --N Guest Backup"
and help options like
  "-R enable remus HA
   -i remus checkpoint interval
   -N disable network buffering in Remus"

To you and me, as devs, it may not matter. But to common users who are
mostly going to
use just live migration, this would be utterly confusing.



> > +        switch (opt) {
> > +        case 0: case 2:
> > +            return opt;
> > +
> > +        case 'i':
> > +           r_info.interval = atoi(optarg);
> > +            break;
> > +        case 'b':
> > +            r_info.blackhole = 1;
> > +            break;
> > +        case 'u':
> > +           r_info.compression = 0;
> > +            break;
> > +        case 's':
> > +            ssh_command = optarg;
> > +            break;
> > +        }
> > +    }
> > +
> > +    domain = argv[optind];
> > +    host = argv[optind + 1];
> > +
> > +    if (r_info.blackhole) {
> > +        find_domain(domain);
> > +        send_fd = open("/dev/null", O_RDWR, 0644);
> > +        if (send_fd < 0) {
> > +            perror("failed to open /dev/null");
> > +            exit(-1);
> > +        }
> > +    } else {
>
> The following duplicates an awful lot of main_migrate which begs for
> them to either be the same underlying command or at least for some
> refactoring.
>
>
I agree.


> > +
> > +        if (!ssh_command[0]) {
> > +            rune = host;
> > +        } else {
> > +            if (asprintf(&rune, "exec %s %s xl remus-receive",
> > +                         ssh_command, host) < 0)
> > +                return 1;
> > +        }
> > +
> > +        save_domain_core_begin(domain, NULL, &config_data, &config_len);
> > +
> > +        if (!config_len) {
> > +            fprintf(stderr, "No config file stored for running domain
> and "
> > +                    "none supplied - cannot start remus.\n");
> > +            exit(1);
> > +        }
> > +
> > +        MUST( libxl_pipe(ctx, sendpipe) );
> > +        MUST( libxl_pipe(ctx, recvpipe) );
> > +
> > +        child = libxl_fork(ctx);
> > +        if (child==-1) exit(1);
> > +
> > +        /* TODO: change this to plain TCP socket based channel
> > +         * instead of SSH.
>
> There are good reasons for using ssh though. However the user can supply
> another command which is not encrypted if they want to.
>
Whatever happens here the same arguments would apply to non-remus
> migration so the changes should be done for both (or better the code
> should be made more common.
>
> Ian.
>
>
>

--000e0ce040449f771e04b76334a4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jan 25, 2012 at 3:52 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

&gt;<br><div><div class=3D"h5">
<br>
</div></div><div class=3D"im">&gt; diff -r 0446591bee86 -r 822536df4aec too=
ls/libxl/xl_cmdimpl.c<br>
&gt; --- a/tools/libxl/xl_cmdimpl.c =A0Mon Jan 23 14:44:00 2012 -0800<br>
&gt; +++ b/tools/libxl/xl_cmdimpl.c =A0Mon Jan 23 14:44:02 2012 -0800<br>
&gt; @@ -1814,7 +1814,7 @@<br>
&gt; =A0 =A0 =A0 * If we have daemonized then do not return to the caller -=
- this has<br>
&gt; =A0 =A0 =A0 * already happened in the parent.<br>
&gt; =A0 =A0 =A0 */<br>
&gt; - =A0 =A0if ( !need_daemon )<br>
&gt; + =A0 =A0if ( daemonize &amp;&amp; !need_daemon )<br>
<br>
</div>What is this change for?<br>
<div class=3D"im"><br></div></blockquote><div><br>Sorry my bad. I should ha=
ve sent it out as a separate patch. Well, if you <br>look at the control fl=
ow in the create_domain function , you would realize<br>that this is a bug.=
<br>

<br>create_domain() <br>{<br>=A0int daemonize =3D dom_info-&gt;daemonize;<b=
r>=A0....<br>=A0int need_daemon =3D daemonize;<br><br>=A0restore_domain() o=
r create_new()<br><br>=A0if (!daemonize &amp;&amp; !monitor) goto out;<br>=
=A0<br>=A0if (need_daemon) {<br>

=A0=A0=A0 fork()<br>=A0=A0=A0 daemon()..<br>=A0=A0=A0 need_daemon =3D 0;<br=
>=A0}<br>=A0...<br>out:<br>=A0=A0=A0=A0=A0=A0=A0=A0 /* If we have daemonize=
d then do not return to the caller -- this has<br>=A0 =A0 =A0=A0 =A0 * alre=
ady happened in the parent.<br>
=A0=A0 =A0 =A0 =A0 */<br>=A0=A0=A0=A0=A0=A0=A0 if ( !need_daemon )<br>=A0=
=A0=A0=A0=A0=A0=A0=A0 exit()<br><br>
}<br><br><br>So, even if one explicitly sets daemonize to 0, the function w=
ill never return to the<br>caller. I needed it to return to the caller (rem=
us_receiver() ), to take further actions.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">

<div class=3D"im">
&gt; =A0 =A0 =A0 =A0 =A0exit(ret);<br>
&gt;<br>
&gt; =A0 =A0 =A0return ret;<br>
&gt; @@ -5853,6 +5853,175 @@<br>
&gt; =A0 =A0 =A0return ret;<br>
&gt; =A0}<br>
&gt;<br>
&gt; +int main_remus_receive(int argc, char **argv)<br>
<br>
</div>Can this not be done as a flag to migrate-receive? Likewise is there<=
br>
common code between the remus migrate and regular migration?<br>
<br></blockquote><div><br>It can but it would basically terminate after the=
 create_domain() call in the<br>migrate_receive function. I would have to h=
ave something like<br>=A0if (remus) {<br>=A0=A0 dont wait for permission to=
 start domain<br>

=A0=A0 try renaming domain<br>=A0=A0 unpause domain<br>=A0=A0 return<br>=A0=
}<br><br>and a bunch of if (remus) flags peppered around the migrate receiv=
e function.<br><br>Having it in a separate function allows me to add suppor=
t for creating a TCP<br>

channel that receives the checkpoints, add hooks or call external libraries=
/binaries<br>that allows the user to check for split-brain before resuming =
the domain.<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">


Is there any reason that remus would not benefit from the xl migration<br>
protocol preamble?<br>
<div class=3D"im"><br></div></blockquote><div><br>No specific reason.=A0 <b=
r><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=
"im">


&gt; +{<br>
&gt; + =A0 =A0int rc;<br>
&gt; + =A0 =A0char *migration_domname;<br>
&gt; + =A0 =A0struct domain_create dom_info;<br>
&gt; +<br>
&gt; + =A0 =A0signal(SIGPIPE, SIG_IGN);<br>
&gt; + =A0 =A0memset(&amp;dom_info, 0, sizeof(dom_info));<br>
&gt; + =A0 =A0dom_info.debug =3D 1;<br>
&gt; + =A0 =A0dom_info.no_incr_generationid =3D 1;<br>
&gt; + =A0 =A0dom_info.restore_file =3D &quot;incoming checkpoint stream&qu=
ot;;<br>
&gt; + =A0 =A0dom_info.migrate_fd =3D 0; /* stdin - will change in future*/=
<br>
&gt; + =A0 =A0dom_info.migration_domname_r =3D &amp;migration_domname;<br>
&gt; +<br>
&gt; + =A0 =A0rc =3D create_domain(&amp;dom_info);<br>
<br>
</div>I&#39;m totally failing to see where the Remus&#39;ness of this creat=
e_domain<br>
comes from.<br>
<div class=3D"im"><br></div></blockquote><div><br>dom_info.daemonize =3D 0,=
 .monitor =3D 0 and .paused =3D 0;<br><br>As I said earlier, this part is p=
robably the only duplication between migrate-receive<br>and remus-receive. =
With Xend, there was no separate remus receiver, to control<br>

what happens on the backup host. Now that I have an opportunity to incorpor=
ate<br>remus into the toolstack from start, I thought I will keep the remus=
 control flow as separate as possible<br>and not have to worry about breaki=
ng live migration (nor complicate its code).<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"im">
&gt; + =A0 =A0if (rc &lt; 0) {<br>
&gt; + =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Remus): Domai=
n creation failed&quot;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot; (code %d) domid %u.\n&quot;, r=
c, domid);<br>
&gt; + =A0 =A0 =A0 =A0exit(-rc);<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0/* If we are here, it means that the sender (primary) has cra=
shed.<br>
&gt; + =A0 =A0 * If domain renaming fails, lets just continue (as we need t=
he domain<br>
&gt; + =A0 =A0 * to be up &amp; dom names may not matter much, as long as i=
ts reachable<br>
&gt; + =A0 =A0 * over network).<br>
&gt; + =A0 =A0 *<br>
&gt; + =A0 =A0 * If domain unpausing fails, destroy domain ? Or is it bette=
r to have<br>
&gt; + =A0 =A0 * a consistent copy of the domain (memory, cpu state, disk)<=
br>
&gt; + =A0 =A0 * on atleast one physical host ? Right now, lets just leave =
the domain<br>
<br>
</div> =A0 =A0 =A0 =A0 =A0 =A0 at least<br>
<div><div class=3D"h5"><br>
&gt; + =A0 =A0 * as is and let the Administrator decide (or troubleshoot).<=
br>
&gt; + =A0 =A0 */<br>
&gt; + =A0 =A0fprintf(stderr, &quot;migration target: Remus Failover for do=
main %u\n&quot;, domid);<br>
&gt; + =A0 =A0if (migration_domname) {<br>
&gt; + =A0 =A0 =A0 =A0rc =3D libxl_domain_rename(ctx, domid, migration_domn=
ame,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 comm=
on_domname);<br>
&gt; + =A0 =A0 =A0 =A0if (rc)<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Remus=
): &quot;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;Failed to rename domain=
 from %s to %s:%d\n&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0migration_domname, common_dom=
name, rc);<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0rc =3D libxl_domain_unpause(ctx, domid);<br>
&gt; + =A0 =A0 =A0 =A0if (rc)<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;migration target (Remus=
): &quot;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;Failed to unpause domai=
n %s (id: %u):%d\n&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0common_domname, domid, rc);<b=
r>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return -rc;<br>
&gt; +}<br>
&gt; +<br>
&gt; +int main_remus(int argc, char **argv)<br>
&gt; +{<br>
&gt; + =A0 =A0int opt, rc;<br>
&gt; + =A0 =A0const char *ssh_command =3D &quot;ssh&quot;;<br>
&gt; + =A0 =A0char *host =3D NULL, *rune =3D NULL, *domain =3D NULL;<br>
&gt; +<br>
&gt; + =A0 =A0int sendpipe[2], recvpipe[2];<br>
&gt; + =A0 =A0int send_fd =3D -1, recv_fd =3D -1;<br>
&gt; + =A0 =A0pid_t child =3D -1;<br>
&gt; +<br>
&gt; + =A0 =A0uint8_t *config_data;<br>
&gt; + =A0 =A0int config_len;<br>
&gt; +<br>
&gt; + =A0 =A0libxl_domain_remus_info r_info;<br>
&gt; +<br>
&gt; + =A0 =A0memset(&amp;r_info, 0, sizeof(libxl_domain_remus_info));<br>
&gt; + =A0 =A0/* Defaults */<br>
&gt; + =A0 =A0r_info.interval =3D 200;<br>
&gt; + =A0 =A0r_info.blackhole =3D 0;<br>
&gt; + =A0 =A0r_info.compression =3D 1;<br>
&gt; +<br>
&gt; + =A0 =A0while ((opt =3D def_getopt(argc, argv, &quot;bui:s:&quot;, &q=
uot;remus&quot;, 2)) !=3D -1) {<br>
<br>
</div></div>main_migrate handles a bunch of other options which might also =
be<br>
interesting in the Remus case? Better would be to add all this as an<br>
option to the std migrate.<br></blockquote><div><br><br>Negative. It would =
look totally unintuitive to have a checkpoint interval option (or blackhole=
<br>replication option) in a live migration command. To an end user, remus =
is just a HA system<br>

and live migration is for moving VMs around. What is the point in trying to=
 educate him/her<br>
that remus is basically &quot;continuous live migration&quot; ? <br><br>Ima=
gine a command like<br>=A0&quot;xl migrate --R --i 100 --N Guest Backup&quo=
t;<br>and help options like<br>=A0 &quot;-R enable remus HA<br>=A0=A0 -i re=
mus checkpoint interval<br>

=A0=A0 -N disable network buffering in Remus&quot;<br><br>To you and me, as=
 devs, it may not matter. But to common users who are mostly going to<br>us=
e just live migration, this would be utterly confusing.<br><br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">


<div><div class=3D"h5"><br>
&gt; + =A0 =A0 =A0 =A0switch (opt) {<br>
&gt; + =A0 =A0 =A0 =A0case 0: case 2:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return opt;<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0case &#39;i&#39;:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 r_info.interval =3D atoi(optarg);<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0 =A0 =A0case &#39;b&#39;:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0r_info.blackhole =3D 1;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0 =A0 =A0case &#39;u&#39;:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 r_info.compression =3D 0;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0 =A0 =A0case &#39;s&#39;:<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0ssh_command =3D optarg;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0domain =3D argv[optind];<br>
&gt; + =A0 =A0host =3D argv[optind + 1];<br>
&gt; +<br>
&gt; + =A0 =A0if (r_info.blackhole) {<br>
&gt; + =A0 =A0 =A0 =A0find_domain(domain);<br>
&gt; + =A0 =A0 =A0 =A0send_fd =3D open(&quot;/dev/null&quot;, O_RDWR, 0644)=
;<br>
&gt; + =A0 =A0 =A0 =A0if (send_fd &lt; 0) {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0perror(&quot;failed to open /dev/null&quot;);=
<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0exit(-1);<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; + =A0 =A0} else {<br>
<br>
</div></div>The following duplicates an awful lot of main_migrate which beg=
s for<br>
them to either be the same underlying command or at least for some<br>
refactoring.<br>
<div><div class=3D"h5"><br></div></div></blockquote><div><br>I agree.<br>=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div cl=
ass=3D"h5">


&gt; +<br>
&gt; + =A0 =A0 =A0 =A0if (!ssh_command[0]) {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0rune =3D host;<br>
&gt; + =A0 =A0 =A0 =A0} else {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0if (asprintf(&amp;rune, &quot;exec %s %s xl r=
emus-receive&quot;,<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ssh_command, host) &=
lt; 0)<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0save_domain_core_begin(domain, NULL, &amp;config_data=
, &amp;config_len);<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0if (!config_len) {<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;No config file stored f=
or running domain and &quot;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;none supplied - cannot =
start remus.\n&quot;);<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0exit(1);<br>
&gt; + =A0 =A0 =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0MUST( libxl_pipe(ctx, sendpipe) );<br>
&gt; + =A0 =A0 =A0 =A0MUST( libxl_pipe(ctx, recvpipe) );<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0child =3D libxl_fork(ctx);<br>
&gt; + =A0 =A0 =A0 =A0if (child=3D=3D-1) exit(1);<br>
&gt; +<br>
&gt; + =A0 =A0 =A0 =A0/* TODO: change this to plain TCP socket based channe=
l<br>
&gt; + =A0 =A0 =A0 =A0 * instead of SSH.<br>
<br>
</div></div>There are good reasons for using ssh though. However the user c=
an supply<br>
another command which is not encrypted if they want to. <br></blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
Whatever happens here the same arguments would apply to non-remus<br>
migration so the changes should be done for both (or better the code<br>
should be made more common.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br>
</font></span></blockquote></div><br>

--000e0ce040449f771e04b76334a4--


--===============7803345780401809841==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7803345780401809841==--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 00:24:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 00:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqD81-00032t-PG; Thu, 26 Jan 2012 00:23:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RqD80-00032l-QY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 00:23:49 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327537418!12471117!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13109 invoked from network); 26 Jan 2012 00:23:42 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Jan 2012 00:23:42 -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 1RqD7e-0003RX-RO; Thu, 26 Jan 2012 11:23:26 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 26 Jan 2012 11:23:26 +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;
	Thu, 26 Jan 2012 11:23:26 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "djmagee@mageenet.net" <djmagee@mageenet.net>, "lta@akr.fm" <lta@akr.fm>
Thread-Topic: GPLPV and pci passthrough
Thread-Index: Aczbi5pS4UQEljXgRDKydrkry+FyIQANK/MA
Date: Thu, 26 Jan 2012 00:23:23 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
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 Jan 2012 00:23:26.0627 (UTC)
	FILETIME=[B8B97F30:01CCDBC0]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV and 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

> 
> James,
> 	At least one other person (Lta, included in this message) and I have
> had problems using passthrough pci devices and your GPLPV drivers at the
> same time.  My symptoms are that SMB connections are totally unreliable
> (however, downloading over http seems to work well enough).
> For example, if I start a video or audio file, playing from the network, it will
> play the first few seconds fine, then the connection drops out.
> I can confirm that the problems don't exist when not passing through any
> devices.
> 
> 	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU with
> an ATI 4770, USB controller, and ICE1712 based pci sound card passed
> through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.
> 
> 	I tried the -debug drivers, and I see a ton of output in qemu log,
> however, all that output seems to be at initialization.  I do not see any
> additional output from your drivers after boot, including when I'm
> experiencing problems.
> 
> 	I took a quick look at tcpdump output and it does seem the guest is
> ACKing the packets as they come in, so my first guess is that they're getting
> lost somewhere between the driver and the OS network stack.
> 
> 	I've never set up a build environment for these drivers so I haven't
> tried adding any extra debug output.  Have you looked into the (or a similar)
> problem before, or have a more verbose debug copy of the net driver you've
> used to diagnose similar problems before?
> 
> 	I guess the real question is, do you have any idea where we should
> start looking?
> 

I'd be first looking at interrupt sharing. Maybe GPLPV doesn't like sharing interrupts with anything?

Have a look in device manager and set the view as "Resources by type" and see if anything is sharing an interrupt with the "Xen PCI Device Driver".

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 00:24:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 00:24:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqD81-00032t-PG; Thu, 26 Jan 2012 00:23:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RqD80-00032l-QY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 00:23:49 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327537418!12471117!1
X-Originating-IP: [203.16.207.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13109 invoked from network); 26 Jan 2012 00:23:42 -0000
Received: from smtp2.bendigoit.com.au (HELO smtp2.bendigoit.com.au)
	(203.16.207.99)
	by server-10.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	26 Jan 2012 00:23:42 -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 1RqD7e-0003RX-RO; Thu, 26 Jan 2012 11:23:26 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Thu, 26 Jan 2012 11:23:26 +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;
	Thu, 26 Jan 2012 11:23:26 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "djmagee@mageenet.net" <djmagee@mageenet.net>, "lta@akr.fm" <lta@akr.fm>
Thread-Topic: GPLPV and pci passthrough
Thread-Index: Aczbi5pS4UQEljXgRDKydrkry+FyIQANK/MA
Date: Thu, 26 Jan 2012 00:23:23 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
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 Jan 2012 00:23:26.0627 (UTC)
	FILETIME=[B8B97F30:01CCDBC0]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV and 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

> 
> James,
> 	At least one other person (Lta, included in this message) and I have
> had problems using passthrough pci devices and your GPLPV drivers at the
> same time.  My symptoms are that SMB connections are totally unreliable
> (however, downloading over http seems to work well enough).
> For example, if I start a video or audio file, playing from the network, it will
> play the first few seconds fine, then the connection drops out.
> I can confirm that the problems don't exist when not passing through any
> devices.
> 
> 	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU with
> an ATI 4770, USB controller, and ICE1712 based pci sound card passed
> through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.
> 
> 	I tried the -debug drivers, and I see a ton of output in qemu log,
> however, all that output seems to be at initialization.  I do not see any
> additional output from your drivers after boot, including when I'm
> experiencing problems.
> 
> 	I took a quick look at tcpdump output and it does seem the guest is
> ACKing the packets as they come in, so my first guess is that they're getting
> lost somewhere between the driver and the OS network stack.
> 
> 	I've never set up a build environment for these drivers so I haven't
> tried adding any extra debug output.  Have you looked into the (or a similar)
> problem before, or have a more verbose debug copy of the net driver you've
> used to diagnose similar problems before?
> 
> 	I guess the real question is, do you have any idea where we should
> start looking?
> 

I'd be first looking at interrupt sharing. Maybe GPLPV doesn't like sharing interrupts with anything?

Have a look in device manager and set the view as "Resources by type" and see if anything is sharing an interrupt with the "Xen PCI Device Driver".

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 00:39:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 00: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 1RqDMG-0003DL-8U; Thu, 26 Jan 2012 00:38: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 1RqDME-0003DG-9M
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 00:38:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327538256!54064616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDcyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7483 invoked from network); 26 Jan 2012 00:37:36 -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;
	26 Jan 2012 00:37:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,571,1320624000"; d="scan'208";a="10293170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 00:38: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, 26 Jan 2012 00:38: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 1RqDMC-0003uW-Hg;
	Thu, 26 Jan 2012 00:38:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqDMC-0002nX-HK;
	Thu, 26 Jan 2012 00:38:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11600-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 00:38:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11600: 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 11600 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11600/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11595

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4271634e4c86
baseline version:
 xen                  a2a8089b1ffb

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=4271634e4c86
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 4271634e4c86
+ branch=xen-unstable
+ revision=4271634e4c86
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 4271634e4c86 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 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 Thu Jan 26 00:39:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 00: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 1RqDMG-0003DL-8U; Thu, 26 Jan 2012 00:38: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 1RqDME-0003DG-9M
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 00:38:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327538256!54064616!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDcyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7483 invoked from network); 26 Jan 2012 00:37:36 -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;
	26 Jan 2012 00:37:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,571,1320624000"; d="scan'208";a="10293170"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 00:38: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, 26 Jan 2012 00:38: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 1RqDMC-0003uW-Hg;
	Thu, 26 Jan 2012 00:38:28 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqDMC-0002nX-HK;
	Thu, 26 Jan 2012 00:38:28 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11600-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 00:38:28 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11600: 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 11600 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11600/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11595

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4271634e4c86
baseline version:
 xen                  a2a8089b1ffb

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-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=4271634e4c86
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 4271634e4c86
+ branch=xen-unstable
+ revision=4271634e4c86
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 4271634e4c86 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 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 Thu Jan 26 01:50:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 01:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqET4-00085r-6A; Thu, 26 Jan 2012 01:49:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RqET2-00085m-N5
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 01:49:37 +0000
Received: from [85.158.139.83:50943] by server-8.bemta-5.messagelabs.com id
	6A/6D-20787-E21B02F4; Thu, 26 Jan 2012 01:49:34 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327542572!12399455!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 628 invoked from network); 26 Jan 2012 01:49:33 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 01:49:33 -0000
Received: by ghbf1 with SMTP id f1so1062929ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 17:49: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:cc:content-type;
	bh=4n7VwXtmTrUKYYROjiYTcmmk5Nyl9lVC2ln0+/FvlEQ=;
	b=vBs6a6dzfmDTGNxKfpe3uy+p/XTU4bOWTTFhRCY7ZYdvIMnN2lM8MAu9u/V8yPmD50
	BYvuK/b9NjkUky3L3RTcBEkTH9UoafoN0cdEr/+6r3hGUfCA80VmjsHVbEq3PEjQqTs4
	r8tVk3gdF61BWmenrSVnd65xmA6qccxTNssvc=
MIME-Version: 1.0
Received: by 10.236.124.172 with SMTP id x32mr127429yhh.19.1327542572065; Wed,
	25 Jan 2012 17:49:32 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Wed, 25 Jan 2012 17:49:32 -0800 (PST)
Date: Thu, 26 Jan 2012 01:49:32 +0000
Message-ID: <CAEc3jaAJP7g6hA8_QC5vLq7vd0tKKwWR9ZR3ckkHf-izgjFceQ@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Race condition in gntdev 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

Hi Daniel and Konrad,

In an email thread at the end of last year ('Questions about GPLPV
stability tests'), I mentioned a certain bug in the gntdev driver. I
think I found the bug and would like your opinion. Since Daniel did a
lot of work on gntdev recently, I think he is most familiar with the
code.

The systems on which I see this bug run Xen 4.1.2 and Linux 2.6.32.48
(pvops), but the same bug should be in Linux 3.x since the code is
similar.

Let me summarize the problem. At some point in time a DomU is
shutdown. Apparently shutdown takes too long according to Xend,
causing it to SIGKILL qemu-dm:
[2012-01-16 14:54:34 3419] INFO (XendDomainInfo:2078) Domain has
shutdown: name=win7-1 id=7581 reason=poweroff.
[2012-01-16 14:54:34 3419] DEBUG (XendDomainInfo:3071)
XendDomainInfo.destroy: domid=7581
[2012-01-16 14:54:36 3419] DEBUG (XendDomainInfo:2401) Destroying device model
[2012-01-16 14:54:46 3419] WARNING (image:649) DeviceModel 31742 took
more than 10s to terminate: sending SIGKILL

This triggers the following Oops:
[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!


Below I attached the in my opinion relevant part of the gntdev driver:
static int gntdev_open(struct inode *inode, struct file *flip)
{
...
...
	priv->mm = get_task_mm(current);
	if (!priv->mm) {
		kfree(priv);
		return -ENOMEM;
	}
	priv->mn.ops = &gntdev_mmu_ops;
	mmu_notifier_register(&priv->mn, priv->mm);
	mmput(priv->mm);

	flip->private_data = priv;
...
}

static int gntdev_release(struct inode *inode, struct file *flip)
{
	struct gntdev_priv *priv = flip->private_data;
...
	mmu_notifier_unregister(&priv->mn, priv->mm);
	kfree(priv);
	return 0;
}

I think the bug is due to gntdev not handling reference counting
(mm->mm_users) in combination with a race condition. The function
gntdev_open calls get_task_mm (which increases mm_users) but straight
after storing 'mm' in 'priv' it performs a mmput which again decreases
the reference count. Since mmu_notifier_register also increases the
reference count, the count is definitely positive after gntdev_open. I
suspect that due to a race condition (after 10 seconds, xend performed
a SIGKILL) the mm structure already got freed somehow. This causes a
bug in mmu_notifier_unregister.

If this is correct then the the 'mmput' line should be moved to
gntdev_release and placed after mmu_notifier_unregister. What do you
think? If this is correct, I will send a patch for this.

Regards,
Roderick Colenbrander

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 01:50:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 01:50:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqET4-00085r-6A; Thu, 26 Jan 2012 01:49:38 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1RqET2-00085m-N5
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 01:49:37 +0000
Received: from [85.158.139.83:50943] by server-8.bemta-5.messagelabs.com id
	6A/6D-20787-E21B02F4; Thu, 26 Jan 2012 01:49:34 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327542572!12399455!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 628 invoked from network); 26 Jan 2012 01:49:33 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 01:49:33 -0000
Received: by ghbf1 with SMTP id f1so1062929ghb.30
	for <xen-devel@lists.xensource.com>;
	Wed, 25 Jan 2012 17:49: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:cc:content-type;
	bh=4n7VwXtmTrUKYYROjiYTcmmk5Nyl9lVC2ln0+/FvlEQ=;
	b=vBs6a6dzfmDTGNxKfpe3uy+p/XTU4bOWTTFhRCY7ZYdvIMnN2lM8MAu9u/V8yPmD50
	BYvuK/b9NjkUky3L3RTcBEkTH9UoafoN0cdEr/+6r3hGUfCA80VmjsHVbEq3PEjQqTs4
	r8tVk3gdF61BWmenrSVnd65xmA6qccxTNssvc=
MIME-Version: 1.0
Received: by 10.236.124.172 with SMTP id x32mr127429yhh.19.1327542572065; Wed,
	25 Jan 2012 17:49:32 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Wed, 25 Jan 2012 17:49:32 -0800 (PST)
Date: Thu, 26 Jan 2012 01:49:32 +0000
Message-ID: <CAEc3jaAJP7g6hA8_QC5vLq7vd0tKKwWR9ZR3ckkHf-izgjFceQ@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] Race condition in gntdev 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

Hi Daniel and Konrad,

In an email thread at the end of last year ('Questions about GPLPV
stability tests'), I mentioned a certain bug in the gntdev driver. I
think I found the bug and would like your opinion. Since Daniel did a
lot of work on gntdev recently, I think he is most familiar with the
code.

The systems on which I see this bug run Xen 4.1.2 and Linux 2.6.32.48
(pvops), but the same bug should be in Linux 3.x since the code is
similar.

Let me summarize the problem. At some point in time a DomU is
shutdown. Apparently shutdown takes too long according to Xend,
causing it to SIGKILL qemu-dm:
[2012-01-16 14:54:34 3419] INFO (XendDomainInfo:2078) Domain has
shutdown: name=win7-1 id=7581 reason=poweroff.
[2012-01-16 14:54:34 3419] DEBUG (XendDomainInfo:3071)
XendDomainInfo.destroy: domid=7581
[2012-01-16 14:54:36 3419] DEBUG (XendDomainInfo:2401) Destroying device model
[2012-01-16 14:54:46 3419] WARNING (image:649) DeviceModel 31742 took
more than 10s to terminate: sending SIGKILL

This triggers the following Oops:
[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!


Below I attached the in my opinion relevant part of the gntdev driver:
static int gntdev_open(struct inode *inode, struct file *flip)
{
...
...
	priv->mm = get_task_mm(current);
	if (!priv->mm) {
		kfree(priv);
		return -ENOMEM;
	}
	priv->mn.ops = &gntdev_mmu_ops;
	mmu_notifier_register(&priv->mn, priv->mm);
	mmput(priv->mm);

	flip->private_data = priv;
...
}

static int gntdev_release(struct inode *inode, struct file *flip)
{
	struct gntdev_priv *priv = flip->private_data;
...
	mmu_notifier_unregister(&priv->mn, priv->mm);
	kfree(priv);
	return 0;
}

I think the bug is due to gntdev not handling reference counting
(mm->mm_users) in combination with a race condition. The function
gntdev_open calls get_task_mm (which increases mm_users) but straight
after storing 'mm' in 'priv' it performs a mmput which again decreases
the reference count. Since mmu_notifier_register also increases the
reference count, the count is definitely positive after gntdev_open. I
suspect that due to a race condition (after 10 seconds, xend performed
a SIGKILL) the mm structure already got freed somehow. This causes a
bug in mmu_notifier_unregister.

If this is correct then the the 'mmput' line should be moved to
gntdev_release and placed after mmu_notifier_unregister. What do you
think? If this is correct, I will send a patch for this.

Regards,
Roderick Colenbrander

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqG0C-0001Lg-68; Thu, 26 Jan 2012 03:27:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG09-0001JF-Qq
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:54 +0000
Received: from [85.158.138.51:13105] by server-3.bemta-3.messagelabs.com id
	D8/3B-26314-938C02F4; Thu, 26 Jan 2012 03:27:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327548472!10674136!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTkzNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19896 invoked from network); 26 Jan 2012 03:27:52 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.207) by server-2.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:27:52 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id BF8817EC069;
	Wed, 25 Jan 2012 19:27: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=Fqsx3T86W8HxCyBQOqAc3IPLZtN4xoIU65Iduedm7TSM
	CRo4GFjY4y+ItCssSx0bUVF96kqlu13RiQ6EBiHFYv9T2iTHN2bWsP+rG3K+9gXY
	PeLWDnsgKvlXiNLGbgaNChmJ474alg0huEgp764dTYOkcsUiOZw6BCAsNbNQufg=
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=MtaxaoSzklJ/BVXsxj4DGj4NlyY=; b=gTzDppIouEk
	5g2f8P4DMODothapTw+GEPqeCZ39bkQeUA6+aOh80F25LNHnLolXIXuK1SldyY3K
	Rbn1pp6ol8/flE84QsvJZNNSs92FoZ8gA9os3sAdSMwkg80De9LWAxbquVvYeV5l
	zOjFSTsKnuG8GlKxCswUagyscRsH0pQ0=
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 9EC6D7EC065; 
	Wed, 25 Jan 2012 19:27:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9116fc441ca47afb2cfc29601eaa11b4621488c3
Message-Id: <9116fc441ca47afb2cfc.1327548754@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:34 -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 13] 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_memshr.c |  10 ++++++++++
 tools/libxc/xenctrl.h   |  17 +++++++++++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f859c29d4011 -r 9116fc441ca4 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -225,3 +225,13 @@ int xc_memshr_debug_gref(xc_interface *x
     return do_domctl(xch, &domctl);
 }
 
+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);
+}
+
diff -r f859c29d4011 -r 9116fc441ca4 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1233,6 +1233,23 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
+/**
+ * This function returns the total number of pages freed by using sharing
+ * on the system.  For example, if two domains contain a single entry in
+ * their p2m map that points to the same shared page (and no other pages
+ * in the system are shared), then this function should return 1.
+ */
+long xc_sharing_freed_pages(xc_interface *xch);
+
+/**
+ * This function returns the total number of frames occupied by shared
+ * pages on the system.  This is independent of the number of domains
+ * pointing at these frames.  For example, in the above scenario this
+ * should return 1. The following should hold:
+ *  memory usage without sharing = freed_pages + used_frames
+ */
+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 Jan 26 03:28:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqG0C-0001Lg-68; Thu, 26 Jan 2012 03:27:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG09-0001JF-Qq
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:54 +0000
Received: from [85.158.138.51:13105] by server-3.bemta-3.messagelabs.com id
	D8/3B-26314-938C02F4; Thu, 26 Jan 2012 03:27:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327548472!10674136!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTkzNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19896 invoked from network); 26 Jan 2012 03:27:52 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.207) by server-2.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:27:52 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id BF8817EC069;
	Wed, 25 Jan 2012 19:27: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=Fqsx3T86W8HxCyBQOqAc3IPLZtN4xoIU65Iduedm7TSM
	CRo4GFjY4y+ItCssSx0bUVF96kqlu13RiQ6EBiHFYv9T2iTHN2bWsP+rG3K+9gXY
	PeLWDnsgKvlXiNLGbgaNChmJ474alg0huEgp764dTYOkcsUiOZw6BCAsNbNQufg=
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=MtaxaoSzklJ/BVXsxj4DGj4NlyY=; b=gTzDppIouEk
	5g2f8P4DMODothapTw+GEPqeCZ39bkQeUA6+aOh80F25LNHnLolXIXuK1SldyY3K
	Rbn1pp6ol8/flE84QsvJZNNSs92FoZ8gA9os3sAdSMwkg80De9LWAxbquVvYeV5l
	zOjFSTsKnuG8GlKxCswUagyscRsH0pQ0=
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 9EC6D7EC065; 
	Wed, 25 Jan 2012 19:27:50 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 9116fc441ca47afb2cfc29601eaa11b4621488c3
Message-Id: <9116fc441ca47afb2cfc.1327548754@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:34 -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 13] 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_memshr.c |  10 ++++++++++
 tools/libxc/xenctrl.h   |  17 +++++++++++++++++
 2 files changed, 27 insertions(+), 0 deletions(-)


Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f859c29d4011 -r 9116fc441ca4 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -225,3 +225,13 @@ int xc_memshr_debug_gref(xc_interface *x
     return do_domctl(xch, &domctl);
 }
 
+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);
+}
+
diff -r f859c29d4011 -r 9116fc441ca4 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1233,6 +1233,23 @@ int xc_mmuext_op(xc_interface *xch, stru
 /* System wide memory properties */
 long xc_maximum_ram_page(xc_interface *xch);
 
+/**
+ * This function returns the total number of pages freed by using sharing
+ * on the system.  For example, if two domains contain a single entry in
+ * their p2m map that points to the same shared page (and no other pages
+ * in the system are shared), then this function should return 1.
+ */
+long xc_sharing_freed_pages(xc_interface *xch);
+
+/**
+ * This function returns the total number of frames occupied by shared
+ * pages on the system.  This is independent of the number of domains
+ * pointing at these frames.  For example, in the above scenario this
+ * should return 1. The following should hold:
+ *  memory usage without sharing = freed_pages + used_frames
+ */
+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 Jan 26 03:28:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqG09-0001Jg-Nd; Thu, 26 Jan 2012 03:27:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG07-0001Gu-Nt
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327548397!62508509!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTkyMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22335 invoked from network); 26 Jan 2012 03:26:37 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.119) by server-7.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 03:26:37 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 695E67EC076;
	Wed, 25 Jan 2012 19:27:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cIgT0GFPzKehK5MoVh4Ymd2SIHv1j46kPNJR/RVYne94
	lpccLZlYxR5NYBWKGoOTp8aBba3fRDG/8sriM/OXm5teTq9PN0sZ5+CKfyWuXIjn
	3bngIl4rdUVFpSDT8jYCFQ2utU9clMVoS5mWaZS4vJyQIzmBfZKOgzAMh6Xu8Ew=
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=nmM/ifyjq/b4BKjb3neStv7s31k=; b=gwDRB2k/Ebm
	SOw8nO+VzC/EBT8ry4BmJR6dwvZYmja1rXR14LhZsliNN0xVNv9OD9xBZMCIaFby
	cB+Ij4guyq4UCSzZfFxL38Q6LEyJFgi+E7hKbyzy/t68apvegcIcjC6jyPwKiQBL
	4F31OFvgAJuW3sANuFX3kF+Xk/1fjYEQ=
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 5997F7EC072; 
	Wed, 25 Jan 2012 19:27:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4a2a0b4949609849ff980d34537b884560b48ca8
Message-Id: <4a2a0b4949609849ff98.1327548749@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:29 -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 13] 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     |  25 +++++++++++++++++++++++++
 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, 40 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>
Acked-by: Tim Deegan <tim@xen.org>

diff -r e66fe1c0b893 -r 4a2a0b494960 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
@@ -5024,11 +5023,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 e66fe1c0b893 -r 4a2a0b494960 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -138,6 +138,7 @@ static inline shr_handle_t get_next_hand
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
+static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 typedef struct gfn_info
 {
@@ -208,9 +209,12 @@ static struct page_info* mem_sharing_loo
 static void 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)
     {
@@ -258,6 +262,9 @@ static void mem_sharing_audit(void)
            continue;
         }
 
+        /* We've found a page that is shared */
+        count_found++;
+
         /* Check if all GFNs map to the MFN, and the p2m types */
         list_for_each(le, &pg->shared_info->gfns)
         {
@@ -302,6 +309,14 @@ static void mem_sharing_audit(void)
             errors++;
         }
     }
+
+    if ( count_found != count_expected )
+    {
+        MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
+                          count_expected, count_found);
+        errors++;
+    }
+
 }
 #endif
 
@@ -342,6 +357,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;
@@ -663,6 +683,9 @@ int mem_sharing_nominate_page(struct dom
         goto out;
     }
 
+    /* Account for this page. */
+    atomic_inc(&nr_shared_mfns);
+
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
@@ -786,6 +809,7 @@ int mem_sharing_share_pages(struct domai
         put_page(cpage);
 
     /* We managed to free a domain page. */
+    atomic_dec(&nr_shared_mfns);
     atomic_inc(&nr_saved_mfns);
     ret = 0;
     
@@ -851,6 +875,7 @@ gfn_found:
         audit_del_list(page);
         xfree(page->shared_info);
         page->shared_info = NULL;
+        atomic_dec(&nr_shared_mfns);
     }
     else
         atomic_dec(&nr_saved_mfns);
diff -r e66fe1c0b893 -r 4a2a0b494960 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 e66fe1c0b893 -r 4a2a0b494960 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. */
@@ -1093,6 +1094,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 e66fe1c0b893 -r 4a2a0b494960 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 e66fe1c0b893 -r 4a2a0b494960 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 Jan 26 03:28:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqG09-0001Jg-Nd; Thu, 26 Jan 2012 03:27:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG07-0001Gu-Nt
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327548397!62508509!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTkyMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22335 invoked from network); 26 Jan 2012 03:26:37 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.119) by server-7.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 03:26:37 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 695E67EC076;
	Wed, 25 Jan 2012 19:27:44 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=cIgT0GFPzKehK5MoVh4Ymd2SIHv1j46kPNJR/RVYne94
	lpccLZlYxR5NYBWKGoOTp8aBba3fRDG/8sriM/OXm5teTq9PN0sZ5+CKfyWuXIjn
	3bngIl4rdUVFpSDT8jYCFQ2utU9clMVoS5mWaZS4vJyQIzmBfZKOgzAMh6Xu8Ew=
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=nmM/ifyjq/b4BKjb3neStv7s31k=; b=gwDRB2k/Ebm
	SOw8nO+VzC/EBT8ry4BmJR6dwvZYmja1rXR14LhZsliNN0xVNv9OD9xBZMCIaFby
	cB+Ij4guyq4UCSzZfFxL38Q6LEyJFgi+E7hKbyzy/t68apvegcIcjC6jyPwKiQBL
	4F31OFvgAJuW3sANuFX3kF+Xk/1fjYEQ=
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 5997F7EC072; 
	Wed, 25 Jan 2012 19:27:43 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4a2a0b4949609849ff980d34537b884560b48ca8
Message-Id: <4a2a0b4949609849ff98.1327548749@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:29 -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 13] 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     |  25 +++++++++++++++++++++++++
 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, 40 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>
Acked-by: Tim Deegan <tim@xen.org>

diff -r e66fe1c0b893 -r 4a2a0b494960 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
@@ -5024,11 +5023,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 e66fe1c0b893 -r 4a2a0b494960 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -138,6 +138,7 @@ static inline shr_handle_t get_next_hand
 #define page_to_mfn(_pg) _mfn(__page_to_mfn(_pg))
 
 static atomic_t nr_saved_mfns   = ATOMIC_INIT(0); 
+static atomic_t nr_shared_mfns  = ATOMIC_INIT(0);
 
 typedef struct gfn_info
 {
@@ -208,9 +209,12 @@ static struct page_info* mem_sharing_loo
 static void 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)
     {
@@ -258,6 +262,9 @@ static void mem_sharing_audit(void)
            continue;
         }
 
+        /* We've found a page that is shared */
+        count_found++;
+
         /* Check if all GFNs map to the MFN, and the p2m types */
         list_for_each(le, &pg->shared_info->gfns)
         {
@@ -302,6 +309,14 @@ static void mem_sharing_audit(void)
             errors++;
         }
     }
+
+    if ( count_found != count_expected )
+    {
+        MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
+                          count_expected, count_found);
+        errors++;
+    }
+
 }
 #endif
 
@@ -342,6 +357,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;
@@ -663,6 +683,9 @@ int mem_sharing_nominate_page(struct dom
         goto out;
     }
 
+    /* Account for this page. */
+    atomic_inc(&nr_shared_mfns);
+
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
@@ -786,6 +809,7 @@ int mem_sharing_share_pages(struct domai
         put_page(cpage);
 
     /* We managed to free a domain page. */
+    atomic_dec(&nr_shared_mfns);
     atomic_inc(&nr_saved_mfns);
     ret = 0;
     
@@ -851,6 +875,7 @@ gfn_found:
         audit_del_list(page);
         xfree(page->shared_info);
         page->shared_info = NULL;
+        atomic_dec(&nr_shared_mfns);
     }
     else
         atomic_dec(&nr_saved_mfns);
diff -r e66fe1c0b893 -r 4a2a0b494960 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 e66fe1c0b893 -r 4a2a0b494960 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. */
@@ -1093,6 +1094,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 e66fe1c0b893 -r 4a2a0b494960 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 e66fe1c0b893 -r 4a2a0b494960 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 Jan 26 03:28:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqG05-0001Hc-RT; Thu, 26 Jan 2012 03:27:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG04-0001HC-Pf
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:49 +0000
Received: from [85.158.139.83:60517] by server-8.bemta-5.messagelabs.com id
	3A/1B-20787-438C02F4; Thu, 26 Jan 2012 03:27:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327548466!12408406!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjcxNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17662 invoked from network); 26 Jan 2012 03:27:46 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-12.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:27:46 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E5A827EC069;
	Wed, 25 Jan 2012 19:27:45 -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=dAESqreJWNggt4hC02l4onoC3/hieqopRTXKSIBfipcq
	PTAVosBZixQJr3JpNrNz62VB+fN+8sdeQPRh79vp0gGvrGZO2vCB3RjEJei8+qL2
	bHR2kleDncPOWfetXD045hc3pINWTFv2eg7IIonpNrB9IQUgXL3dwEVu2bK9U4Y=
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=ElJ9K/u0UcZpp8QFK47J+aCPUh4=; b=NkA556yt22b
	5Hro6SAhmYy/EthTT89Bxknebk7LsHwBeIl//JkVvvI1gCG2GXNxfLMPqbvo9L5o
	bLsZlvaidlBOpg4BesHJhSAV+SoU036HiEb6HPdHGDEhxV3Y7oQKDauD2KdMNjF+
	W+52Mr07xKQAvFzjTjRgv3hYC2qHVH2Q=
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 92E077EC065; 
	Wed, 25 Jan 2012 19:27:44 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c87eb9e63483621ff512ea152781e722febd3f0b
Message-Id: <c87eb9e63483621ff512.1327548750@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:30 -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 13] 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 |  103 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h   |    3 +-
 2 files changed, 105 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>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 4a2a0b494960 -r c87eb9e63483 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -820,6 +820,73 @@ 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;
+    
+    /* 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;
+    }
+
+    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(cd, gfn_info);
+        put_page_and_type(spage);
+    } else
+        ret = 0;
+
+    atomic_inc(&nr_saved_mfns);
+
+err_unlock:
+    mem_sharing_page_unlock(spage);
+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)
@@ -1042,6 +1109,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 4a2a0b494960 -r c87eb9e63483 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)
@@ -801,7 +802,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 */
             domid_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 Jan 26 03:28:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03:28:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqG05-0001Hc-RT; Thu, 26 Jan 2012 03:27:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG04-0001HC-Pf
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:49 +0000
Received: from [85.158.139.83:60517] by server-8.bemta-5.messagelabs.com id
	3A/1B-20787-438C02F4; Thu, 26 Jan 2012 03:27:48 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327548466!12408406!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjcxNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17662 invoked from network); 26 Jan 2012 03:27:46 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-12.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:27:46 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E5A827EC069;
	Wed, 25 Jan 2012 19:27:45 -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=dAESqreJWNggt4hC02l4onoC3/hieqopRTXKSIBfipcq
	PTAVosBZixQJr3JpNrNz62VB+fN+8sdeQPRh79vp0gGvrGZO2vCB3RjEJei8+qL2
	bHR2kleDncPOWfetXD045hc3pINWTFv2eg7IIonpNrB9IQUgXL3dwEVu2bK9U4Y=
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=ElJ9K/u0UcZpp8QFK47J+aCPUh4=; b=NkA556yt22b
	5Hro6SAhmYy/EthTT89Bxknebk7LsHwBeIl//JkVvvI1gCG2GXNxfLMPqbvo9L5o
	bLsZlvaidlBOpg4BesHJhSAV+SoU036HiEb6HPdHGDEhxV3Y7oQKDauD2KdMNjF+
	W+52Mr07xKQAvFzjTjRgv3hYC2qHVH2Q=
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 92E077EC065; 
	Wed, 25 Jan 2012 19:27:44 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c87eb9e63483621ff512ea152781e722febd3f0b
Message-Id: <c87eb9e63483621ff512.1327548750@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:30 -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 13] 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 |  103 ++++++++++++++++++++++++++++++++++++++++++
 xen/include/public/domctl.h   |    3 +-
 2 files changed, 105 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>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 4a2a0b494960 -r c87eb9e63483 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -820,6 +820,73 @@ 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;
+    
+    /* 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;
+    }
+
+    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(cd, gfn_info);
+        put_page_and_type(spage);
+    } else
+        ret = 0;
+
+    atomic_inc(&nr_saved_mfns);
+
+err_unlock:
+    mem_sharing_page_unlock(spage);
+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)
@@ -1042,6 +1109,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 4a2a0b494960 -r c87eb9e63483 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)
@@ -801,7 +802,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 */
             domid_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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG07-0001IC-8A; Thu, 26 Jan 2012 03:27:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG05-0001HT-M2
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:49 +0000
Received: from [85.158.139.83:60535] by server-9.bemta-5.messagelabs.com id
	3E/C1-24580-538C02F4; Thu, 26 Jan 2012 03:27:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327548467!11869862!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE3OTEw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16934 invoked from network); 26 Jan 2012 03:27:48 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-13.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:27:48 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 551827EC072;
	Wed, 25 Jan 2012 19:27: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=mwLRAhRvK155CND6RjjLNM76eo8zdfIZnB0Ib6hiydsK
	e4wB8On4+KpD/u7nQQQSDrn4Iv500o18f1XPF+S5X27ViDJRyN7PHMmtGPthQSUP
	ncAfCg6NPN4xmUDSJovkritEGh6XXr2PR8yALyDHhuDgqp5wkkDcBRaS0Uxh+YU=
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=Igks9v7T/8LNDYD+I1hNS8DZDjQ=; b=oy0Gzn65RKz
	UxlT4TXZgc3nqDLrSxEP1Dei8EY29iYSz7gxI4ZcPbRAf/HdK6nWUmXd5ZkIyDbd
	Rqia78XvdHo9pLEotOVltyMqsiFc5onqvjUrCFcJMHbjnCY5PbK5tiFA8rYZM3Y9
	vkuUMIqh3EdrRJTBiDDVGg+MPyJSSauk=
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 21DAC7EC065; 
	Wed, 25 Jan 2012 19:27:46 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a45fb86e24196fa87e998246c35ef0fbc3cec829
Message-Id: <a45fb86e24196fa87e99.1327548751@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:31 -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 13] 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  |   5 +++++
 xen/arch/x86/mm.c       |  14 ++++++++++++++
 xen/common/keyhandler.c |   7 +++++--
 xen/include/xen/mm.h    |   3 +++
 4 files changed, 27 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Tim Deegan <tim@xen.org>

diff -r c87eb9e63483 -r a45fb86e2419 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3574,6 +3574,11 @@ p2m_pod_decrease_reservation(struct doma
     return 0;
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+}
+
 /*
  * Local variables:
  * mode: C
diff -r c87eb9e63483 -r a45fb86e2419 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -113,6 +113,7 @@
 #include <asm/e820.h>
 #include <asm/hypercall.h>
 #include <asm/shared.h>
+#include <asm/mem_sharing.h>
 #include <public/memory.h>
 #include <public/sched.h>
 #include <xsm/xsm.h>
@@ -5832,6 +5833,19 @@ void memguard_unguard_stack(void *p)
     memguard_unguard_range(p, PAGE_SIZE);
 }
 
+#if defined(__x86_64__)
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared frames %u -- Saved frames %u\n",
+            mem_sharing_get_nr_shared_mfns(),
+            mem_sharing_get_nr_saved_mfns());
+}
+#else
+void arch_dump_shared_mem_info(void)
+{
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r c87eb9e63483 -r a45fb86e2419 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 <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
@@ -249,8 +250,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],
@@ -309,6 +310,8 @@ static void dump_domains(unsigned char k
         }
     }
 
+    arch_dump_shared_mem_info();
+
     rcu_read_unlock(&domlist_read_lock);
 #undef tmpstr
 }
diff -r c87eb9e63483 -r a45fb86e2419 xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -72,6 +72,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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG07-0001IC-8A; Thu, 26 Jan 2012 03:27:51 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG05-0001HT-M2
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:49 +0000
Received: from [85.158.139.83:60535] by server-9.bemta-5.messagelabs.com id
	3E/C1-24580-538C02F4; Thu, 26 Jan 2012 03:27:49 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327548467!11869862!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE3OTEw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16934 invoked from network); 26 Jan 2012 03:27:48 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-13.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:27:48 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 551827EC072;
	Wed, 25 Jan 2012 19:27: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=mwLRAhRvK155CND6RjjLNM76eo8zdfIZnB0Ib6hiydsK
	e4wB8On4+KpD/u7nQQQSDrn4Iv500o18f1XPF+S5X27ViDJRyN7PHMmtGPthQSUP
	ncAfCg6NPN4xmUDSJovkritEGh6XXr2PR8yALyDHhuDgqp5wkkDcBRaS0Uxh+YU=
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=Igks9v7T/8LNDYD+I1hNS8DZDjQ=; b=oy0Gzn65RKz
	UxlT4TXZgc3nqDLrSxEP1Dei8EY29iYSz7gxI4ZcPbRAf/HdK6nWUmXd5ZkIyDbd
	Rqia78XvdHo9pLEotOVltyMqsiFc5onqvjUrCFcJMHbjnCY5PbK5tiFA8rYZM3Y9
	vkuUMIqh3EdrRJTBiDDVGg+MPyJSSauk=
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 21DAC7EC065; 
	Wed, 25 Jan 2012 19:27:46 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: a45fb86e24196fa87e998246c35ef0fbc3cec829
Message-Id: <a45fb86e24196fa87e99.1327548751@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:31 -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 13] 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  |   5 +++++
 xen/arch/x86/mm.c       |  14 ++++++++++++++
 xen/common/keyhandler.c |   7 +++++--
 xen/include/xen/mm.h    |   3 +++
 4 files changed, 27 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Tim Deegan <tim@xen.org>

diff -r c87eb9e63483 -r a45fb86e2419 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c
+++ b/xen/arch/ia64/xen/mm.c
@@ -3574,6 +3574,11 @@ p2m_pod_decrease_reservation(struct doma
     return 0;
 }
 
+/* Simple no-op */
+void arch_dump_shared_mem_info(void)
+{
+}
+
 /*
  * Local variables:
  * mode: C
diff -r c87eb9e63483 -r a45fb86e2419 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -113,6 +113,7 @@
 #include <asm/e820.h>
 #include <asm/hypercall.h>
 #include <asm/shared.h>
+#include <asm/mem_sharing.h>
 #include <public/memory.h>
 #include <public/sched.h>
 #include <xsm/xsm.h>
@@ -5832,6 +5833,19 @@ void memguard_unguard_stack(void *p)
     memguard_unguard_range(p, PAGE_SIZE);
 }
 
+#if defined(__x86_64__)
+void arch_dump_shared_mem_info(void)
+{
+    printk("Shared frames %u -- Saved frames %u\n",
+            mem_sharing_get_nr_shared_mfns(),
+            mem_sharing_get_nr_saved_mfns());
+}
+#else
+void arch_dump_shared_mem_info(void)
+{
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff -r c87eb9e63483 -r a45fb86e2419 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 <xen/init.h>
 #include <asm/debugger.h>
 #include <asm/div64.h>
@@ -249,8 +250,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],
@@ -309,6 +310,8 @@ static void dump_domains(unsigned char k
         }
     }
 
+    arch_dump_shared_mem_info();
+
     rcu_read_unlock(&domlist_read_lock);
 #undef tmpstr
 }
diff -r c87eb9e63483 -r a45fb86e2419 xen/include/xen/mm.h
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -72,6 +72,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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG09-0001J2-3k; Thu, 26 Jan 2012 03:27:53 +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 1RqG07-0001Gp-4e
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327548463!12572113!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzc3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6395 invoked from network); 26 Jan 2012 03:27:44 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-4.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:27:44 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 2C3807EC074;
	Wed, 25 Jan 2012 19:27:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=DJf7BytrYwJhfjQW8iQsxeHpYPg50FnMBNuVH0e8/uDH
	7ct+02bXrXp4I2Kuo/Xh7Q2lemdZk43O8t70r91sNEkfq1gMoD+Ry107n3D3/rjN
	WG8UN/kFBNPZqa1aMEX9qSCBgKIq0JJ7avTuWTUPh4Qvlq1NuoyGXBblcYLO2K4=
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=seiG6k8ESTZpAI6z06hOm+MEbi0=; b=bxlrDxCG+Sy
	xyXAHcGJt7QZSbzBvXq1Qs6vYyGywp0vrDkLrrrjbA6Upa2uC04mlNgLOJG9RIEH
	+LgOhz3kXRdjc90FPWr+RgMxWMKnR+SPCh6DydSNyPEihVDkieSgTwFAS8gfWpM7
	fnyQygLujryDJkAu/CePr9RjAoJLbG/Y=
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 1F6BA7EC072; 
	Wed, 25 Jan 2012 19:27:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e66fe1c0b893873cda6738b16425e8bed0542232
Message-Id: <e66fe1c0b893873cda67.1327548748@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:28 -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 13] x86/mm: Enforce lock ordering for
	sharing page locks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 |  16 ++++++++++++++++
 xen/arch/x86/mm/mm-locks.h    |  18 +++++++++++++++++-
 xen/include/asm-x86/mm.h      |   3 ++-
 3 files changed, 35 insertions(+), 2 deletions(-)


Use the ordering constructs in mm-locks.h to enforce an order
for the p2m and page locks in the sharing code. Applies to either
the global sharing lock (in audit mode) or the per page locks.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scanneell <adin@scannell.ca>

diff -r f5e3c94b2066 -r e66fe1c0b893 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -37,6 +37,13 @@
 
 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_PER_CPU(pg_lock_data_t, __pld);
+
 #if MEM_SHARING_AUDIT
 
 static mm_lock_t shr_lock;
@@ -85,16 +92,25 @@ static inline int mem_sharing_page_lock(
 static inline int mem_sharing_page_lock(struct page_info *pg)
 {
     int rc;
+    pg_lock_data_t *pld = &(this_cpu(__pld));
+
+    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 = &(this_cpu(__pld));
+
+    page_sharing_mm_unlock(pld->mm_unlock_level, 
+                           &pld->recurse_count);
     preempt_enable();
     page_unlock(pg);
 }
diff -r f5e3c94b2066 -r e66fe1c0b893 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -156,7 +156,23 @@ declare_mm_lock(shr)
 
 #else
 
-/* We use an efficient per-page lock when AUDIT is not enabled. */
+/* 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 */
 
diff -r f5e3c94b2066 -r e66fe1c0b893 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -351,7 +351,8 @@ void clear_superpage_mark(struct page_in
  * 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. 
+ * 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0L-0001U4-GA; Thu, 26 Jan 2012 03:28: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 1RqG0J-0001Mn-3e
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:28:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327548476!12572124!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjcxNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6812 invoked from network); 26 Jan 2012 03:27:56 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-4.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:27:56 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 66F6E7EC072;
	Wed, 25 Jan 2012 19:27:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=rVndpLX6hGbypu0WQKbOoYR3G/PKZQoxsWag+v0fS5GI
	womI2dCVjfP/oRKiTnHfl+zEy7QvT6PUYxyXb5AatwTfrnpHeV7b08WqULFjGKxe
	NKz5zadxc2AewZm+8sOj2YSPA4TlyRuk5FC1aWwi1tOyyvb0/LUkBfRWFz23KqI=
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=pffAOozVUeDYKHSwIFwpDH75nZU=; b=rkMHGWv65ys
	Ni54ncrmKcpmg3B5ddDbBT6cWPKpbTvYuS/qSgk8nJYbMLxhjmrJKLwnAQVdeBoI
	mah078WrbN79Sn6Fk4BVvlBpmIE3c6sWwedt3OFgBmhUnOcke57C49C7sHve/LjN
	OIliGTHJwfdCnFwJE/JURJ2xQsG+D2sk=
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 653BB7EC069; 
	Wed, 25 Jan 2012 19:27:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f09f62ae92b7a8be9989dc3ced8eb839fa3bd8b2
Message-Id: <f09f62ae92b7a8be9989.1327548757@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 13 of 13] x86/mm: Sharing overhaul style
	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

 xen/arch/x86/mm/mem_sharing.c |  64 +++++++++++++++++++++---------------------
 xen/include/asm-x86/mm.h      |   2 +-
 2 files changed, 33 insertions(+), 33 deletions(-)


The name 'shared_info' for the list of shared pages backed by a share frame
collided with the identifier also used for a domain's shared info page. To
avoid grep/cscope/etc aliasing, rename the shared memory token to 'sharing.

This patch only addresses style, and performs no functional changes. To ease
reviwing, the patch was left as a stand-alone last-slot addition to the queue
to avoid propagating changes throughout the whole series.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 88856b776fcf -r f09f62ae92b7 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -64,19 +64,19 @@ static void _free_pg_shared_info(struct 
 
 static inline void audit_add_list(struct page_info *page)
 {
-    INIT_LIST_HEAD(&page->shared_info->entry);
+    INIT_LIST_HEAD(&page->sharing->entry);
     spin_lock(&shr_audit_lock);
-    list_add_rcu(&page->shared_info->entry, &shr_audit_list);
+    list_add_rcu(&page->sharing->entry, &shr_audit_list);
     spin_unlock(&shr_audit_lock);
 }
 
 static inline void audit_del_list(struct page_info *page)
 {
     spin_lock(&shr_audit_lock);
-    list_del_rcu(&page->shared_info->entry);
+    list_del_rcu(&page->sharing->entry);
     spin_unlock(&shr_audit_lock);
-    INIT_RCU_HEAD(&page->shared_info->rcu_head);
-    call_rcu(&page->shared_info->rcu_head, _free_pg_shared_info);
+    INIT_RCU_HEAD(&page->sharing->rcu_head);
+    call_rcu(&page->sharing->rcu_head, _free_pg_shared_info);
 }
 
 #else
@@ -86,7 +86,7 @@ static inline void audit_del_list(struct
 #define audit_add_list(p)  ((void)0)
 static inline void audit_del_list(struct page_info *page)
 {
-    xfree(page->shared_info);
+    xfree(page->sharing);
 }
 
 #endif /* MEM_SHARING_AUDIT */
@@ -171,7 +171,7 @@ static inline gfn_info_t *mem_sharing_gf
     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);
+    list_add(&gfn_info->list, &page->sharing->gfns);
 
     /* Increment our number of shared pges. */
     atomic_inc(&d->shr_pages);
@@ -220,14 +220,14 @@ static void mem_sharing_audit(void)
 
     list_for_each_rcu(ae, &shr_audit_list)
     {
-        struct page_sharing_info *shared_info;
+        struct page_sharing_info *pg_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;
+        pg_shared_info = list_entry(ae, struct page_sharing_info, entry);
+        pg = pg_shared_info->pg;
         mfn = page_to_mfn(pg);
 
         /* If we can't lock it, it's definitely not a shared page */
@@ -265,7 +265,7 @@ static void mem_sharing_audit(void)
         }
 
         /* Check we have a list */
-        if ( (!pg->shared_info) || (list_empty(&pg->shared_info->gfns)) )
+        if ( (!pg->sharing) || (list_empty(&pg->sharing->gfns)) )
         {
            MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
                              mfn_x(mfn));
@@ -277,7 +277,7 @@ static void mem_sharing_audit(void)
         count_found++;
 
         /* Check if all GFNs map to the MFN, and the p2m types */
-        list_for_each(le, &pg->shared_info->gfns)
+        list_for_each(le, &pg->sharing->gfns)
         {
             struct domain *d;
             p2m_type_t t;
@@ -630,7 +630,7 @@ int mem_sharing_nominate_page(struct dom
                         "grab page %lx dom %d\n", gfn, mfn_x(mfn), d->domain_id);
             BUG();
         }
-        *phandle = pg->shared_info->handle;
+        *phandle = pg->sharing->handle;
         ret = 0;
         mem_sharing_page_unlock(pg);
         goto out;
@@ -655,24 +655,24 @@ int mem_sharing_nominate_page(struct dom
 
     /* Initialize the shared state */
     ret = -ENOMEM;
-    if ( (page->shared_info = 
+    if ( (page->sharing = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
         /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
-    page->shared_info->pg = page;
-    INIT_LIST_HEAD(&page->shared_info->gfns);
+    page->sharing->pg = page;
+    INIT_LIST_HEAD(&page->sharing->gfns);
 
     /* Create the handle */
-    page->shared_info->handle = get_next_handle();  
+    page->sharing->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;
+        xfree(page->sharing);
+        page->sharing = NULL;
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
@@ -685,8 +685,8 @@ int mem_sharing_nominate_page(struct dom
          * 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(d, gfn_info);
-        xfree(page->shared_info);
-        page->shared_info = NULL;
+        xfree(page->sharing);
+        page->sharing = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
@@ -698,7 +698,7 @@ int mem_sharing_nominate_page(struct dom
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
-    *phandle = page->shared_info->handle;
+    *phandle = page->sharing->handle;
     audit_add_list(page);
     mem_sharing_page_unlock(page);
     ret = 0;
@@ -769,14 +769,14 @@ int mem_sharing_share_pages(struct domai
     ASSERT(cmfn_type == p2m_ram_shared);
 
     /* Check that the handles match */
-    if ( spage->shared_info->handle != sh )
+    if ( spage->sharing->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 )
+    if ( cpage->sharing->handle != ch )
     {
         ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
@@ -785,7 +785,7 @@ int mem_sharing_share_pages(struct domai
     }
 
     /* Merge the lists together */
-    list_for_each_safe(le, te, &cpage->shared_info->gfns)
+    list_for_each_safe(le, te, &cpage->sharing->gfns)
     {
         gfn = list_entry(le, gfn_info_t, list);
         /* Get the source page and type, this should never fail: 
@@ -793,18 +793,18 @@ int mem_sharing_share_pages(struct domai
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
         /* Move the gfn_info from client list to source list */
         list_del(&gfn->list);
-        list_add(&gfn->list, &spage->shared_info->gfns);
+        list_add(&gfn->list, &spage->sharing->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, smfn) == 0);
         put_domain(d);
     }
-    ASSERT(list_empty(&cpage->shared_info->gfns));
+    ASSERT(list_empty(&cpage->sharing->gfns));
 
     /* Clear the rest of the shared state */
     audit_del_list(cpage);
-    cpage->shared_info = NULL;
+    cpage->sharing = NULL;
 
     mem_sharing_page_unlock(secondpg);
     mem_sharing_page_unlock(firstpg);
@@ -848,7 +848,7 @@ int mem_sharing_add_to_physmap(struct do
     ASSERT(smfn_type == p2m_ram_shared);
 
     /* Check that the handles match */
-    if ( spage->shared_info->handle != sh )
+    if ( spage->sharing->handle != sh )
         goto err_unlock;
 
     /* Make sure the target page is a hole in the physmap */
@@ -920,7 +920,7 @@ int mem_sharing_unshare_page(struct doma
         BUG();
     }
 
-    list_for_each(le, &page->shared_info->gfns)
+    list_for_each(le, &page->sharing->gfns)
     {
         gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
@@ -933,13 +933,13 @@ int mem_sharing_unshare_page(struct doma
 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);
+    last_gfn = list_has_one_entry(&page->sharing->gfns);
     mem_sharing_gfn_destroy(d, gfn_info);
     if ( last_gfn )
     {
         /* Clean up shared state */
         audit_del_list(page);
-        page->shared_info = NULL;
+        page->sharing = NULL;
         atomic_dec(&nr_shared_mfns);
     }
     else
diff -r 88856b776fcf -r f09f62ae92b7 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -57,7 +57,7 @@ struct page_info
          * 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;
+        struct page_sharing_info *sharing;
     };
 
     /* Reference count and various PGC_xxx flags and fields. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG09-0001J2-3k; Thu, 26 Jan 2012 03:27:53 +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 1RqG07-0001Gp-4e
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:51 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327548463!12572113!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzc3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6395 invoked from network); 26 Jan 2012 03:27:44 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-4.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:27:44 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 2C3807EC074;
	Wed, 25 Jan 2012 19:27:43 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=DJf7BytrYwJhfjQW8iQsxeHpYPg50FnMBNuVH0e8/uDH
	7ct+02bXrXp4I2Kuo/Xh7Q2lemdZk43O8t70r91sNEkfq1gMoD+Ry107n3D3/rjN
	WG8UN/kFBNPZqa1aMEX9qSCBgKIq0JJ7avTuWTUPh4Qvlq1NuoyGXBblcYLO2K4=
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=seiG6k8ESTZpAI6z06hOm+MEbi0=; b=bxlrDxCG+Sy
	xyXAHcGJt7QZSbzBvXq1Qs6vYyGywp0vrDkLrrrjbA6Upa2uC04mlNgLOJG9RIEH
	+LgOhz3kXRdjc90FPWr+RgMxWMKnR+SPCh6DydSNyPEihVDkieSgTwFAS8gfWpM7
	fnyQygLujryDJkAu/CePr9RjAoJLbG/Y=
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 1F6BA7EC072; 
	Wed, 25 Jan 2012 19:27:42 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: e66fe1c0b893873cda6738b16425e8bed0542232
Message-Id: <e66fe1c0b893873cda67.1327548748@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:28 -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 13] x86/mm: Enforce lock ordering for
	sharing page locks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 |  16 ++++++++++++++++
 xen/arch/x86/mm/mm-locks.h    |  18 +++++++++++++++++-
 xen/include/asm-x86/mm.h      |   3 ++-
 3 files changed, 35 insertions(+), 2 deletions(-)


Use the ordering constructs in mm-locks.h to enforce an order
for the p2m and page locks in the sharing code. Applies to either
the global sharing lock (in audit mode) or the per page locks.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scanneell <adin@scannell.ca>

diff -r f5e3c94b2066 -r e66fe1c0b893 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -37,6 +37,13 @@
 
 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_PER_CPU(pg_lock_data_t, __pld);
+
 #if MEM_SHARING_AUDIT
 
 static mm_lock_t shr_lock;
@@ -85,16 +92,25 @@ static inline int mem_sharing_page_lock(
 static inline int mem_sharing_page_lock(struct page_info *pg)
 {
     int rc;
+    pg_lock_data_t *pld = &(this_cpu(__pld));
+
+    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 = &(this_cpu(__pld));
+
+    page_sharing_mm_unlock(pld->mm_unlock_level, 
+                           &pld->recurse_count);
     preempt_enable();
     page_unlock(pg);
 }
diff -r f5e3c94b2066 -r e66fe1c0b893 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -156,7 +156,23 @@ declare_mm_lock(shr)
 
 #else
 
-/* We use an efficient per-page lock when AUDIT is not enabled. */
+/* 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 */
 
diff -r f5e3c94b2066 -r e66fe1c0b893 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -351,7 +351,8 @@ void clear_superpage_mark(struct page_in
  * 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. 
+ * 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0L-0001U4-GA; Thu, 26 Jan 2012 03:28: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 1RqG0J-0001Mn-3e
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:28:03 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327548476!12572124!1
X-Originating-IP: [208.97.132.74]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi43NCA9PiAxNjcxNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6812 invoked from network); 26 Jan 2012 03:27:56 -0000
Received: from caiajhbdcahe.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.74) by server-4.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:27:56 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 66F6E7EC072;
	Wed, 25 Jan 2012 19:27:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=rVndpLX6hGbypu0WQKbOoYR3G/PKZQoxsWag+v0fS5GI
	womI2dCVjfP/oRKiTnHfl+zEy7QvT6PUYxyXb5AatwTfrnpHeV7b08WqULFjGKxe
	NKz5zadxc2AewZm+8sOj2YSPA4TlyRuk5FC1aWwi1tOyyvb0/LUkBfRWFz23KqI=
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=pffAOozVUeDYKHSwIFwpDH75nZU=; b=rkMHGWv65ys
	Ni54ncrmKcpmg3B5ddDbBT6cWPKpbTvYuS/qSgk8nJYbMLxhjmrJKLwnAQVdeBoI
	mah078WrbN79Sn6Fk4BVvlBpmIE3c6sWwedt3OFgBmhUnOcke57C49C7sHve/LjN
	OIliGTHJwfdCnFwJE/JURJ2xQsG+D2sk=
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 653BB7EC069; 
	Wed, 25 Jan 2012 19:27:54 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f09f62ae92b7a8be9989dc3ced8eb839fa3bd8b2
Message-Id: <f09f62ae92b7a8be9989.1327548757@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 13 of 13] x86/mm: Sharing overhaul style
	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

 xen/arch/x86/mm/mem_sharing.c |  64 +++++++++++++++++++++---------------------
 xen/include/asm-x86/mm.h      |   2 +-
 2 files changed, 33 insertions(+), 33 deletions(-)


The name 'shared_info' for the list of shared pages backed by a share frame
collided with the identifier also used for a domain's shared info page. To
avoid grep/cscope/etc aliasing, rename the shared memory token to 'sharing.

This patch only addresses style, and performs no functional changes. To ease
reviwing, the patch was left as a stand-alone last-slot addition to the queue
to avoid propagating changes throughout the whole series.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 88856b776fcf -r f09f62ae92b7 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -64,19 +64,19 @@ static void _free_pg_shared_info(struct 
 
 static inline void audit_add_list(struct page_info *page)
 {
-    INIT_LIST_HEAD(&page->shared_info->entry);
+    INIT_LIST_HEAD(&page->sharing->entry);
     spin_lock(&shr_audit_lock);
-    list_add_rcu(&page->shared_info->entry, &shr_audit_list);
+    list_add_rcu(&page->sharing->entry, &shr_audit_list);
     spin_unlock(&shr_audit_lock);
 }
 
 static inline void audit_del_list(struct page_info *page)
 {
     spin_lock(&shr_audit_lock);
-    list_del_rcu(&page->shared_info->entry);
+    list_del_rcu(&page->sharing->entry);
     spin_unlock(&shr_audit_lock);
-    INIT_RCU_HEAD(&page->shared_info->rcu_head);
-    call_rcu(&page->shared_info->rcu_head, _free_pg_shared_info);
+    INIT_RCU_HEAD(&page->sharing->rcu_head);
+    call_rcu(&page->sharing->rcu_head, _free_pg_shared_info);
 }
 
 #else
@@ -86,7 +86,7 @@ static inline void audit_del_list(struct
 #define audit_add_list(p)  ((void)0)
 static inline void audit_del_list(struct page_info *page)
 {
-    xfree(page->shared_info);
+    xfree(page->sharing);
 }
 
 #endif /* MEM_SHARING_AUDIT */
@@ -171,7 +171,7 @@ static inline gfn_info_t *mem_sharing_gf
     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);
+    list_add(&gfn_info->list, &page->sharing->gfns);
 
     /* Increment our number of shared pges. */
     atomic_inc(&d->shr_pages);
@@ -220,14 +220,14 @@ static void mem_sharing_audit(void)
 
     list_for_each_rcu(ae, &shr_audit_list)
     {
-        struct page_sharing_info *shared_info;
+        struct page_sharing_info *pg_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;
+        pg_shared_info = list_entry(ae, struct page_sharing_info, entry);
+        pg = pg_shared_info->pg;
         mfn = page_to_mfn(pg);
 
         /* If we can't lock it, it's definitely not a shared page */
@@ -265,7 +265,7 @@ static void mem_sharing_audit(void)
         }
 
         /* Check we have a list */
-        if ( (!pg->shared_info) || (list_empty(&pg->shared_info->gfns)) )
+        if ( (!pg->sharing) || (list_empty(&pg->sharing->gfns)) )
         {
            MEM_SHARING_DEBUG("mfn %lx shared, but empty gfn list!\n",
                              mfn_x(mfn));
@@ -277,7 +277,7 @@ static void mem_sharing_audit(void)
         count_found++;
 
         /* Check if all GFNs map to the MFN, and the p2m types */
-        list_for_each(le, &pg->shared_info->gfns)
+        list_for_each(le, &pg->sharing->gfns)
         {
             struct domain *d;
             p2m_type_t t;
@@ -630,7 +630,7 @@ int mem_sharing_nominate_page(struct dom
                         "grab page %lx dom %d\n", gfn, mfn_x(mfn), d->domain_id);
             BUG();
         }
-        *phandle = pg->shared_info->handle;
+        *phandle = pg->sharing->handle;
         ret = 0;
         mem_sharing_page_unlock(pg);
         goto out;
@@ -655,24 +655,24 @@ int mem_sharing_nominate_page(struct dom
 
     /* Initialize the shared state */
     ret = -ENOMEM;
-    if ( (page->shared_info = 
+    if ( (page->sharing = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
         /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
-    page->shared_info->pg = page;
-    INIT_LIST_HEAD(&page->shared_info->gfns);
+    page->sharing->pg = page;
+    INIT_LIST_HEAD(&page->sharing->gfns);
 
     /* Create the handle */
-    page->shared_info->handle = get_next_handle();  
+    page->sharing->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;
+        xfree(page->sharing);
+        page->sharing = NULL;
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
@@ -685,8 +685,8 @@ int mem_sharing_nominate_page(struct dom
          * 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(d, gfn_info);
-        xfree(page->shared_info);
-        page->shared_info = NULL;
+        xfree(page->sharing);
+        page->sharing = NULL;
         /* NOTE: We haven't yet added this to the audit list. */
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
@@ -698,7 +698,7 @@ int mem_sharing_nominate_page(struct dom
     /* Update m2p entry to SHARED_M2P_ENTRY */
     set_gpfn_from_mfn(mfn_x(mfn), SHARED_M2P_ENTRY);
 
-    *phandle = page->shared_info->handle;
+    *phandle = page->sharing->handle;
     audit_add_list(page);
     mem_sharing_page_unlock(page);
     ret = 0;
@@ -769,14 +769,14 @@ int mem_sharing_share_pages(struct domai
     ASSERT(cmfn_type == p2m_ram_shared);
 
     /* Check that the handles match */
-    if ( spage->shared_info->handle != sh )
+    if ( spage->sharing->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 )
+    if ( cpage->sharing->handle != ch )
     {
         ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
@@ -785,7 +785,7 @@ int mem_sharing_share_pages(struct domai
     }
 
     /* Merge the lists together */
-    list_for_each_safe(le, te, &cpage->shared_info->gfns)
+    list_for_each_safe(le, te, &cpage->sharing->gfns)
     {
         gfn = list_entry(le, gfn_info_t, list);
         /* Get the source page and type, this should never fail: 
@@ -793,18 +793,18 @@ int mem_sharing_share_pages(struct domai
         BUG_ON(!get_page_and_type(spage, dom_cow, PGT_shared_page));
         /* Move the gfn_info from client list to source list */
         list_del(&gfn->list);
-        list_add(&gfn->list, &spage->shared_info->gfns);
+        list_add(&gfn->list, &spage->sharing->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, smfn) == 0);
         put_domain(d);
     }
-    ASSERT(list_empty(&cpage->shared_info->gfns));
+    ASSERT(list_empty(&cpage->sharing->gfns));
 
     /* Clear the rest of the shared state */
     audit_del_list(cpage);
-    cpage->shared_info = NULL;
+    cpage->sharing = NULL;
 
     mem_sharing_page_unlock(secondpg);
     mem_sharing_page_unlock(firstpg);
@@ -848,7 +848,7 @@ int mem_sharing_add_to_physmap(struct do
     ASSERT(smfn_type == p2m_ram_shared);
 
     /* Check that the handles match */
-    if ( spage->shared_info->handle != sh )
+    if ( spage->sharing->handle != sh )
         goto err_unlock;
 
     /* Make sure the target page is a hole in the physmap */
@@ -920,7 +920,7 @@ int mem_sharing_unshare_page(struct doma
         BUG();
     }
 
-    list_for_each(le, &page->shared_info->gfns)
+    list_for_each(le, &page->sharing->gfns)
     {
         gfn_info = list_entry(le, gfn_info_t, list);
         if ( (gfn_info->gfn == gfn) && (gfn_info->domain == d->domain_id) )
@@ -933,13 +933,13 @@ int mem_sharing_unshare_page(struct doma
 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);
+    last_gfn = list_has_one_entry(&page->sharing->gfns);
     mem_sharing_gfn_destroy(d, gfn_info);
     if ( last_gfn )
     {
         /* Clean up shared state */
         audit_del_list(page);
-        page->shared_info = NULL;
+        page->sharing = NULL;
         atomic_dec(&nr_shared_mfns);
     }
     else
diff -r 88856b776fcf -r f09f62ae92b7 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -57,7 +57,7 @@ struct page_info
          * 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;
+        struct page_sharing_info *sharing;
     };
 
     /* Reference count and various PGC_xxx flags and fields. */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0F-0001O1-Jd; Thu, 26 Jan 2012 03:27:59 +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 1RqG0E-0001KU-Dg
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327548343!50084828!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcwMzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27588 invoked from network); 26 Jan 2012 03:25:43 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 03:25:43 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id DEA687EC072;
	Wed, 25 Jan 2012 19:27: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=dKpoRL7OzRVcF39UmG/UDYHQXZSe7POKfhODX3D1tgwV
	4NZLBptyMVp+ss0ku7o9ow4YdRqaZGj4tL0L3QrWGV2aYLTBkSlxs3E+mKLVOUM9
	NONH7yK62cUMv13IwWD+VoQ7rapcOUF1ftsq+9l89ZpKjCGJlfh/gbicfuXXEa4=
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=QDHmXYr0qo1a4u4e50TMsiBX3xs=; b=HtgmIyWyjFh
	c96YCrHdIHA4KjZz3gaq/p+VGWowN6owdFhl6Vq50MI71pdG3XG6DgI6U4c1qP/G
	k4icPZEBg71dXtY/PORs/zrmOuVctVZWAvpTdmnb6BzVecet9VoA/yNcOaIXgbD8
	IiFalqzN44A2VGonB1306hWbR0uBuCMg=
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 ED4A27EC065; 
	Wed, 25 Jan 2012 19:27:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4cefca5789b11cf62e527d0a6e52885382b60454
Message-Id: <4cefca5789b11cf62e52.1327548755@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:35 -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 13] 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           |  13 ++++++++
 tools/libxl/libxl.c         |   2 +
 tools/libxl/libxl_types.idl |   2 +
 tools/libxl/xl.h            |   1 +
 tools/libxl/xl_cmdimpl.c    |  66 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c   |   5 +++
 6 files changed, 89 insertions(+), 0 deletions(-)


Also add the global sharing statistics to the libxl physinfo.  This is a slight
departure from libxc, but there's no reason libxl physinfo can't include extra
bits of useful and relevant information.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9116fc441ca4 -r 4cefca5789b1 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -410,6 +410,19 @@ Leave domain running after creating the 
 
 =back
 
+=item B<sharing> [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.
+
+=back
 
 =item B<shutdown> [I<OPTIONS>] I<domain-id>
 
diff -r 9116fc441ca4 -r 4cefca5789b1 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2507,6 +2507,8 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->total_pages = xcphysinfo.total_pages;
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
+    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
+    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
     physinfo->phys_cap = xcphysinfo.capabilities;
diff -r 9116fc441ca4 -r 4cefca5789b1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -367,6 +367,8 @@ libxl_physinfo = Struct("physinfo", [
     ("total_pages", uint64),
     ("free_pages", uint64),
     ("scrub_pages", uint64),
+    ("sharing_freed_pages", uint64),
+    ("sharing_used_frames", uint64),
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
diff -r 9116fc441ca4 -r 4cefca5789b1 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 9116fc441ca4 -r 4cefca5789b1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3701,6 +3701,8 @@ static void output_physinfo(void)
         i = (1 << 20) / vinfo->pagesize;
         printf("total_memory           : %"PRIu64"\n", info.total_pages / i);
         printf("free_memory            : %"PRIu64"\n", info.free_pages / i);
+        printf("sharing_freed_memory   : %"PRIu64"\n", info.sharing_freed_pages / i);
+        printf("sharing_used_memory    : %"PRIu64"\n", info.sharing_used_frames / i);
     }
     if (!libxl_get_freecpus(ctx, &cpumap)) {
         libxl_for_each_cpu(i, cpumap)
@@ -3784,6 +3786,70 @@ int main_info(int argc, char **argv)
     return 0;
 }
 
+static void sharing(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);
+    }
+}
+
+int main_sharing(int argc, char **argv)
+{
+    int opt = 0;
+    libxl_dominfo info_buf;
+    libxl_dominfo *info, *info_free = NULL;
+    int nb_domain, rc;
+
+    if ((opt = def_getopt(argc, argv, "", "sharing", 0)) != -1)
+        return opt;
+
+    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(info, nb_domain);
+
+    if (info_free)
+        free(info_free);
+
+    return 0;
+}
+
 static int sched_credit_domain_get(
     int domid, libxl_sched_credit *scinfo)
 {
diff -r 9116fc441ca4 -r 4cefca5789b1 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -189,6 +189,11 @@ 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",
+      "[Domain]", 
+    },
     { "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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0F-0001O1-Jd; Thu, 26 Jan 2012 03:27:59 +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 1RqG0E-0001KU-Dg
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:58 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327548343!50084828!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcwMzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27588 invoked from network); 26 Jan 2012 03:25:43 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-14.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 03:25:43 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id DEA687EC072;
	Wed, 25 Jan 2012 19:27: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=dKpoRL7OzRVcF39UmG/UDYHQXZSe7POKfhODX3D1tgwV
	4NZLBptyMVp+ss0ku7o9ow4YdRqaZGj4tL0L3QrWGV2aYLTBkSlxs3E+mKLVOUM9
	NONH7yK62cUMv13IwWD+VoQ7rapcOUF1ftsq+9l89ZpKjCGJlfh/gbicfuXXEa4=
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=QDHmXYr0qo1a4u4e50TMsiBX3xs=; b=HtgmIyWyjFh
	c96YCrHdIHA4KjZz3gaq/p+VGWowN6owdFhl6Vq50MI71pdG3XG6DgI6U4c1qP/G
	k4icPZEBg71dXtY/PORs/zrmOuVctVZWAvpTdmnb6BzVecet9VoA/yNcOaIXgbD8
	IiFalqzN44A2VGonB1306hWbR0uBuCMg=
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 ED4A27EC065; 
	Wed, 25 Jan 2012 19:27:51 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 4cefca5789b11cf62e527d0a6e52885382b60454
Message-Id: <4cefca5789b11cf62e52.1327548755@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:35 -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 13] 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           |  13 ++++++++
 tools/libxl/libxl.c         |   2 +
 tools/libxl/libxl_types.idl |   2 +
 tools/libxl/xl.h            |   1 +
 tools/libxl/xl_cmdimpl.c    |  66 +++++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/xl_cmdtable.c   |   5 +++
 6 files changed, 89 insertions(+), 0 deletions(-)


Also add the global sharing statistics to the libxl physinfo.  This is a slight
departure from libxc, but there's no reason libxl physinfo can't include extra
bits of useful and relevant information.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 9116fc441ca4 -r 4cefca5789b1 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -410,6 +410,19 @@ Leave domain running after creating the 
 
 =back
 
+=item B<sharing> [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.
+
+=back
 
 =item B<shutdown> [I<OPTIONS>] I<domain-id>
 
diff -r 9116fc441ca4 -r 4cefca5789b1 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2507,6 +2507,8 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     physinfo->total_pages = xcphysinfo.total_pages;
     physinfo->free_pages = xcphysinfo.free_pages;
     physinfo->scrub_pages = xcphysinfo.scrub_pages;
+    physinfo->sharing_freed_pages = xc_sharing_freed_pages(ctx->xch);
+    physinfo->sharing_used_frames = xc_sharing_used_frames(ctx->xch);
     physinfo->nr_nodes = xcphysinfo.nr_nodes;
     memcpy(physinfo->hw_cap,xcphysinfo.hw_cap, sizeof(physinfo->hw_cap));
     physinfo->phys_cap = xcphysinfo.capabilities;
diff -r 9116fc441ca4 -r 4cefca5789b1 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -367,6 +367,8 @@ libxl_physinfo = Struct("physinfo", [
     ("total_pages", uint64),
     ("free_pages", uint64),
     ("scrub_pages", uint64),
+    ("sharing_freed_pages", uint64),
+    ("sharing_used_frames", uint64),
 
     ("nr_nodes", uint32),
     ("hw_cap", libxl_hwcap),
diff -r 9116fc441ca4 -r 4cefca5789b1 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 9116fc441ca4 -r 4cefca5789b1 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3701,6 +3701,8 @@ static void output_physinfo(void)
         i = (1 << 20) / vinfo->pagesize;
         printf("total_memory           : %"PRIu64"\n", info.total_pages / i);
         printf("free_memory            : %"PRIu64"\n", info.free_pages / i);
+        printf("sharing_freed_memory   : %"PRIu64"\n", info.sharing_freed_pages / i);
+        printf("sharing_used_memory    : %"PRIu64"\n", info.sharing_used_frames / i);
     }
     if (!libxl_get_freecpus(ctx, &cpumap)) {
         libxl_for_each_cpu(i, cpumap)
@@ -3784,6 +3786,70 @@ int main_info(int argc, char **argv)
     return 0;
 }
 
+static void sharing(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);
+    }
+}
+
+int main_sharing(int argc, char **argv)
+{
+    int opt = 0;
+    libxl_dominfo info_buf;
+    libxl_dominfo *info, *info_free = NULL;
+    int nb_domain, rc;
+
+    if ((opt = def_getopt(argc, argv, "", "sharing", 0)) != -1)
+        return opt;
+
+    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(info, nb_domain);
+
+    if (info_free)
+        free(info_free);
+
+    return 0;
+}
+
 static int sched_credit_domain_get(
     int domid, libxl_sched_credit *scinfo)
 {
diff -r 9116fc441ca4 -r 4cefca5789b1 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c
+++ b/tools/libxl/xl_cmdtable.c
@@ -189,6 +189,11 @@ 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",
+      "[Domain]", 
+    },
     { "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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG00-0001GD-NP; Thu, 26 Jan 2012 03:27:44 +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 1RqFzy-0001G0-PP
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:43 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327548439!50273171!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcwMzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 26 Jan 2012 03:27:19 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-11.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 03:27:19 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4F0437EC065;
	Wed, 25 Jan 2012 19:27:40 -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=YMMLo/KnOhArQ08ET5Cz3nyslqX4gVLl0f9FhEzn22of
	VebdXL4o4Uq++vr/j1EkLtP9K/5mbWoz8NswPADsy8GREGcnT6c824a0YIgVUEbT
	fXLWoprvuvrioh/eS2jDXwcF66eakeRAdgbG1xoGUAub/cgbNimGYUMoqLur9ew=
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=1v+cp7A+ALTEsFiZbd/CF4WViPc=; b=D4Jz+XVM+TE
	vqM1yoIEAGv2p/hUOdZDK5L4MXCNmuJ0TGMBTs7MSfmJlPZ1LaUReHm+d9ofF6P/
	STUp7sSBg+eryudvNEUChl7lGuWlhC2GCa9l784nR/YxCNfHy2JX4eweglBMyK4n
	ZwitCxvteVqb0C+bpY33ZibTPWYLMNWQ=
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 325A77EC074; 
	Wed, 25 Jan 2012 19:27:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 61e164d6e9566bc5418daef3a3ee9b2227f1d314
Message-Id: <61e164d6e9566bc5418d.1327548746@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 02 of 13] 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   |  13 +++++++++
 2 files changed, 61 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 provides a grant ref and a version. Update interface to handle this
case.

The use case for grant sharing is when sharing from within a backend (e.g.
memshr + blktap2), in which case the backend is only exposed to grant
references.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r bcc4215663e8 -r 61e164d6e956 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -728,18 +728,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 bcc4215663e8 -r 61e164d6e956 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -775,6 +775,19 @@ 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)
 
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed 
+ * to grant references, and this allows sharing of the grefs */
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
+    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
+    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+
 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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG01-0001GK-2i; Thu, 26 Jan 2012 03:27:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqFzy-0001G1-Rr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:43 +0000
Received: from [85.158.138.51:61912] by server-3.bemta-3.messagelabs.com id
	09/1B-26314-E28C02F4; Thu, 26 Jan 2012 03:27:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327548459!8842575!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzc3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12139 invoked from network); 26 Jan 2012 03:27:39 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-15.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:27:39 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id EB2657EC072;
	Wed, 25 Jan 2012 19:27:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=KcvEiszmRxR376uzImWYkDJJiFaiN6/5b0FcK7e6iYmI
	NSKluMFeXH8SAYEcqjp6fOsfQ38XBVgflCp4t0SCt3CBx4BFZtNjC/4+3nKSk9Vj
	Qlym0mcsR+NOMvVjXe8uIUhX8WCcU2tH551Rff4ODNkOymURq+lFUUWeEJgJxMw=
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=V2XwecOD2ePUpotqGyT9msFoHSg=; b=glqgMPkWaqX
	XZV5IhJPm8o/SpoOs9wM64lxSo/J0l0OMdvB31HL9rOjWQucZwE6GRJubWtB40VC
	RMQLDkgkFSulwZDoH9RqrOvl2CIXQsSX7IyzP4pzch5TI3Q/bZHhfuSvKr1dhnOh
	8fGNnXO0uuPJdFABZqnNfYOFB6E8w1oc=
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 99E0A7EC065; 
	Wed, 25 Jan 2012 19:27:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bcc4215663e86e06f005daf2530a1271e2bde2a4
Message-Id: <bcc4215663e86e06f005.1327548745@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 01 of 13] 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     |  539 ++++++++++++++++++-------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 4 files changed, 294 insertions(+), 278 deletions(-)


Eliminate the sharing hastable mechanism 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 3f8338e68164 -r bcc4215663e8 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,27 @@
 
 #include "mm-locks.h"
 
-/* Auditing of memory sharing code? */
-#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)
+static struct list_head shr_audit_list;
+
+static inline void audit_add_list(struct page_info *page)
+{
+    INIT_LIST_HEAD(&page->shared_info->entry);
+    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)
+#define mem_sharing_audit() ((void)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 +71,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,164 +91,149 @@ 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);
+
+    /* Increment our number of shared pges. */
+    atomic_inc(&d->shr_pages);
+
+    return gfn_info;
 }
 
-static shr_hash_entry_t *mem_sharing_hash_alloc(void)
+static inline void mem_sharing_gfn_destroy(struct domain *d,
+                                           gfn_info_t *gfn_info)
 {
-    return xmalloc(shr_hash_entry_t); 
+    /* Decrement the number of pages. */
+    atomic_dec(&d->shr_pages);
+
+    /* Free the gfn_info structure. */
+    list_del(&gfn_info->list);
+    xfree(gfn_info);
 }
 
-static void mem_sharing_hash_destroy(shr_hash_entry_t *e)
+static struct page_info* mem_sharing_lookup(unsigned long mfn)
 {
-    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)
-{
-    /* Decrement the number of pages, if the gfn was shared before */
-    if ( was_shared )
+    if ( mfn_valid(_mfn(mfn)) )
     {
-        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 )
+        struct page_info* page = mfn_to_page(_mfn(mfn));
+        if ( page_get_owner(page) == dom_cow )
         {
-            atomic_dec(&d->shr_pages);
-            put_domain(d);
+            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
+            return page;
         }
     }
-    xfree(gfn);
-}
-
-static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle)
-{
-    shr_hash_entry_t *e;
-    
-    e = shr_hash[handle % SHR_HASH_LENGTH]; 
-    while(e != NULL)
-    {
-        if(e->handle == handle)
-            return e;
-        e = e->next;
-    }
 
     return NULL;
 }
 
-static shr_hash_entry_t* mem_sharing_hash_insert(shr_handle_t handle, mfn_t mfn)
-{
-    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 (%lx)!\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 (%hu)!\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: %hu, for PFN=%lx, MFN=%lx\n",
+                                  g->domain, g->gfn, mfn_x(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=%hu, PFN=%lx."
+                                  "Expecting MFN=%lx, got %lx\n",
+                                  g->domain, g->gfn, mfn_x(mfn), mfn_x(o_mfn));
+                errors++;
+            }
+            if ( t != p2m_ram_shared )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M type for d=%hu, PFN=%lx MFN=%lx."
+                                  "Expecting t=%d, got %d\n",
+                                  g->domain, g->gfn, mfn_x(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 list %lu, in type_info %lx\n",
+                              mfn_x(mfn), nr_gfns, 
+                              (pg->u.inuse.type_info & PGT_count_mask));
+            errors++;
         }
     }
 }
@@ -383,36 +370,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)
 {
@@ -450,8 +407,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;
@@ -467,7 +422,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;
     }
@@ -481,16 +436,26 @@ 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);
+
+    /* 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;
     }
 
@@ -501,23 +466,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(d, gfn_info);
+        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:
@@ -526,54 +487,82 @@ 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;
+    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 */
+    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);
         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));
+
+    /* 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);
+
+    /* We managed to free a domain page. */
+    atomic_inc(&nr_saved_mfns);
     ret = 0;
     
 err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
     shr_unlock();
-
     return ret;
 }
 
@@ -585,13 +574,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. 
@@ -607,56 +592,62 @@ 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(d, gfn_info);
+    if ( last_gfn )
+    {
+        /* Clean up shared state */
+        audit_del_list(page);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+    }
+    else
+        atomic_dec(&nr_saved_mfns);
     /* 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 = alloc_domheap_page(d, 0);
-    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);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -669,30 +660,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);
 
@@ -749,9 +728,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;
 
@@ -799,6 +787,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 3f8338e68164 -r bcc4215663e8 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 3f8338e68164 -r bcc4215663e8 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 3f8338e68164 -r bcc4215663e8 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 */
+            domid_t          client_domain; /* IN: the client domain id */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
             uint64_aligned_t client_handle; /* IN: handle to the client page */
         } share; 
         struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0A-0001KL-Iq; Thu, 26 Jan 2012 03:27:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG09-0001Ir-2n
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:53 +0000
Received: from [85.158.138.51:13092] by server-8.bemta-3.messagelabs.com id
	7D/AC-31878-838C02F4; Thu, 26 Jan 2012 03:27:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327548470!10692282!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzc3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30013 invoked from network); 26 Jan 2012 03:27:51 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-6.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:27:51 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 773EC7EC072;
	Wed, 25 Jan 2012 19:27: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=US3rMPXZcw8q/7f7oDEPAIzSsfOLbfqDJ/+IyISQQJUL
	W2jVPBmD6I/v50pNBvgOFPNIabE6Rvd1VWLv+ul5dCumF9a0CZovklJdsYTOdWaT
	2UOLjL+jvvla7Sxy6gsml7hrx3m6VXIzNZyzzIna+cOoEQIxOvSsb0f82bf/EGo=
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=365jeHomxKlULdXrXRYb+R/JGe8=; b=JTNigBFjVW6
	e1ISDhBCwVYQkR/7apc6eL9g3lGWWkn1xgiHWikWJzWcXLLeEiVeAc/r1d91FtGT
	8qfVBq6Dc+n0Fv/KByyzJWoBaBREG/niLpme+Fm6l5HFKdTuOZyq1sD1W8F2A/Q0
	F6m4uns7Md1qFf8WhlJItCPboEKTbFdc=
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 279887EC065; 
	Wed, 25 Jan 2012 19:27:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f859c29d4011c2802cd11ef7003a4d5977f2eab1
Message-Id: <f859c29d4011c2802cd1.1327548753@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:33 -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 13] Update memshr API and tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/blktap2/drivers/tapdisk-vbd.c |   6 +-
 tools/blktap2/drivers/tapdisk.h     |   2 +-
 tools/libxc/xc_memshr.c             |  63 ++++++++++++++++++++++++++++++++++--
 tools/libxc/xenctrl.h               |  19 ++++++++++-
 tools/memshr/bidir-daemon.c         |  34 ++++++++++++++-----
 tools/memshr/bidir-hash.h           |  12 ++++--
 tools/memshr/interface.c            |  30 ++++++++++-------
 tools/memshr/memshr.h               |  11 +++++-
 8 files changed, 139 insertions(+), 38 deletions(-)


This patch is the folded version of API updates, along with the associated tool
changes to ensure that the build is always consistent.

API updates:
- The source domain in the sharing calls is no longer assumed to be dom0.
- Previously, 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 and tools need to be updated to recall the share
  functions with the information needed to fetch the page (which they readily
  have).

Tool updates:
The only (in-tree, that we know of) consumer of the mem sharing API is the
memshr tool. This is updated to use the new API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r cf70bc85eb23 -r f859c29d4011 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 cf70bc85eb23 -r f859c29d4011 tools/blktap2/drivers/tapdisk.h
--- a/tools/blktap2/drivers/tapdisk.h
+++ b/tools/blktap2/drivers/tapdisk.h
@@ -140,7 +140,7 @@ struct td_request {
 	void                        *private;
     
 #ifdef MEMSHR
-	uint64_t                     memshr_hnd;
+	share_tuple_t                memshr_hnd;
 #endif
 };
 
diff -r cf70bc85eb23 -r f859c29d4011 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -86,24 +86,79 @@ int xc_memshr_nominate_gref(xc_interface
     return ret;
 }
 
-int xc_memshr_share(xc_interface *xch,
-                    uint64_t source_handle,
-                    uint64_t client_handle)
+int xc_memshr_share_gfns(xc_interface *xch,
+                         domid_t source_domain,
+                         unsigned long source_gfn,
+                         uint64_t source_handle,
+                         domid_t client_domain,
+                         unsigned long client_gfn,
+                         uint64_t client_handle)
 {
     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 = 0;
+    domctl.domain = source_domain;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
+    op->u.share.source_gfn    = source_gfn;
+    op->u.share.client_domain = client_domain;
+    op->u.share.client_gfn    = client_gfn;
     op->u.share.client_handle = client_handle;
 
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_share_grefs(xc_interface *xch,
+                          domid_t source_domain,
+                          grant_ref_t source_gref,
+                          uint64_t source_handle,
+                          domid_t client_domain,
+                          grant_ref_t client_gref,
+                          uint64_t client_handle)
+{
+    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 = source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
+    op->u.share.source_handle = source_handle;
+    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
+    op->u.share.client_domain = client_domain;
+    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
+    op->u.share.client_handle = client_handle;
+
+    return do_domctl(xch, &domctl);
+}
+
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long 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               = source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
+    op->u.share.source_gfn      = source_gfn;
+    op->u.share.source_handle   = source_handle;
+    op->u.share.client_gfn      = client_gfn;
+    op->u.share.client_domain   = client_domain;
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
diff -r cf70bc85eb23 -r f859c29d4011 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1897,9 +1897,26 @@ int xc_memshr_nominate_gref(xc_interface
                             domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
-int xc_memshr_share(xc_interface *xch,
+int xc_memshr_share_gfns(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
                     uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long client_gfn,
                     uint64_t client_handle);
+int xc_memshr_share_grefs(xc_interface *xch,
+                    domid_t source_domain,
+                    grant_ref_t source_gref,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    grant_ref_t client_gref,
+                    uint64_t client_handle);
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long client_gfn);
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,
diff -r cf70bc85eb23 -r f859c29d4011 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 cf70bc85eb23 -r f859c29d4011 tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -20,6 +20,7 @@
 #define __BIDIR_HASH_H__
 
 #include <stdint.h>
+#include <string.h>
 #include "memshr-priv.h"
 
 typedef struct vbdblk {
@@ -81,15 +82,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 +99,15 @@ 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 ( !memcmp(&h1, &h2, sizeof(share_tuple_t)) );
 }
 #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 cf70bc85eb23 -r f859c29d4011 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_grefs(vbd_info.xc_handle, source_st.domain, source_st.frame, 
+                                    source_st.handle, vbd_info.domid, gref, c_hnd);
         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 cf70bc85eb23 -r f859c29d4011 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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG01-0001GK-2i; Thu, 26 Jan 2012 03:27:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqFzy-0001G1-Rr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:43 +0000
Received: from [85.158.138.51:61912] by server-3.bemta-3.messagelabs.com id
	09/1B-26314-E28C02F4; Thu, 26 Jan 2012 03:27:42 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327548459!8842575!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzc3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12139 invoked from network); 26 Jan 2012 03:27:39 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-15.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:27:39 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id EB2657EC072;
	Wed, 25 Jan 2012 19:27:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=KcvEiszmRxR376uzImWYkDJJiFaiN6/5b0FcK7e6iYmI
	NSKluMFeXH8SAYEcqjp6fOsfQ38XBVgflCp4t0SCt3CBx4BFZtNjC/4+3nKSk9Vj
	Qlym0mcsR+NOMvVjXe8uIUhX8WCcU2tH551Rff4ODNkOymURq+lFUUWeEJgJxMw=
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=V2XwecOD2ePUpotqGyT9msFoHSg=; b=glqgMPkWaqX
	XZV5IhJPm8o/SpoOs9wM64lxSo/J0l0OMdvB31HL9rOjWQucZwE6GRJubWtB40VC
	RMQLDkgkFSulwZDoH9RqrOvl2CIXQsSX7IyzP4pzch5TI3Q/bZHhfuSvKr1dhnOh
	8fGNnXO0uuPJdFABZqnNfYOFB6E8w1oc=
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 99E0A7EC065; 
	Wed, 25 Jan 2012 19:27:37 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: bcc4215663e86e06f005daf2530a1271e2bde2a4
Message-Id: <bcc4215663e86e06f005.1327548745@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 01 of 13] 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     |  539 ++++++++++++++++++-------------------
 xen/include/asm-x86/mem_sharing.h |   19 +-
 xen/include/asm-x86/mm.h          |   11 +-
 xen/include/public/domctl.h       |    3 +
 4 files changed, 294 insertions(+), 278 deletions(-)


Eliminate the sharing hastable mechanism 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 3f8338e68164 -r bcc4215663e8 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,27 @@
 
 #include "mm-locks.h"
 
-/* Auditing of memory sharing code? */
-#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)
+static struct list_head shr_audit_list;
+
+static inline void audit_add_list(struct page_info *page)
+{
+    INIT_LIST_HEAD(&page->shared_info->entry);
+    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)
+#define mem_sharing_audit() ((void)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 +71,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,164 +91,149 @@ 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);
+
+    /* Increment our number of shared pges. */
+    atomic_inc(&d->shr_pages);
+
+    return gfn_info;
 }
 
-static shr_hash_entry_t *mem_sharing_hash_alloc(void)
+static inline void mem_sharing_gfn_destroy(struct domain *d,
+                                           gfn_info_t *gfn_info)
 {
-    return xmalloc(shr_hash_entry_t); 
+    /* Decrement the number of pages. */
+    atomic_dec(&d->shr_pages);
+
+    /* Free the gfn_info structure. */
+    list_del(&gfn_info->list);
+    xfree(gfn_info);
 }
 
-static void mem_sharing_hash_destroy(shr_hash_entry_t *e)
+static struct page_info* mem_sharing_lookup(unsigned long mfn)
 {
-    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)
-{
-    /* Decrement the number of pages, if the gfn was shared before */
-    if ( was_shared )
+    if ( mfn_valid(_mfn(mfn)) )
     {
-        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 )
+        struct page_info* page = mfn_to_page(_mfn(mfn));
+        if ( page_get_owner(page) == dom_cow )
         {
-            atomic_dec(&d->shr_pages);
-            put_domain(d);
+            ASSERT(page->u.inuse.type_info & PGT_type_mask); 
+            ASSERT(get_gpfn_from_mfn(mfn) == SHARED_M2P_ENTRY); 
+            return page;
         }
     }
-    xfree(gfn);
-}
-
-static shr_hash_entry_t* mem_sharing_hash_lookup(shr_handle_t handle)
-{
-    shr_hash_entry_t *e;
-    
-    e = shr_hash[handle % SHR_HASH_LENGTH]; 
-    while(e != NULL)
-    {
-        if(e->handle == handle)
-            return e;
-        e = e->next;
-    }
 
     return NULL;
 }
 
-static shr_hash_entry_t* mem_sharing_hash_insert(shr_handle_t handle, mfn_t mfn)
-{
-    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 (%lx)!\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 (%hu)!\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: %hu, for PFN=%lx, MFN=%lx\n",
+                                  g->domain, g->gfn, mfn_x(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=%hu, PFN=%lx."
+                                  "Expecting MFN=%lx, got %lx\n",
+                                  g->domain, g->gfn, mfn_x(mfn), mfn_x(o_mfn));
+                errors++;
+            }
+            if ( t != p2m_ram_shared )
+            {
+                MEM_SHARING_DEBUG("Incorrect P2M type for d=%hu, PFN=%lx MFN=%lx."
+                                  "Expecting t=%d, got %d\n",
+                                  g->domain, g->gfn, mfn_x(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 list %lu, in type_info %lx\n",
+                              mfn_x(mfn), nr_gfns, 
+                              (pg->u.inuse.type_info & PGT_count_mask));
+            errors++;
         }
     }
 }
@@ -383,36 +370,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)
 {
@@ -450,8 +407,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;
@@ -467,7 +422,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;
     }
@@ -481,16 +436,26 @@ 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);
+
+    /* 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;
     }
 
@@ -501,23 +466,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(d, gfn_info);
+        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:
@@ -526,54 +487,82 @@ 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;
+    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 */
+    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);
         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));
+
+    /* 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);
+
+    /* We managed to free a domain page. */
+    atomic_inc(&nr_saved_mfns);
     ret = 0;
     
 err_out:
+    put_gfn(cd, cgfn);
+    put_gfn(sd, sgfn);
     shr_unlock();
-
     return ret;
 }
 
@@ -585,13 +574,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. 
@@ -607,56 +592,62 @@ 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(d, gfn_info);
+    if ( last_gfn )
+    {
+        /* Clean up shared state */
+        audit_del_list(page);
+        xfree(page->shared_info);
+        page->shared_info = NULL;
+    }
+    else
+        atomic_dec(&nr_saved_mfns);
     /* 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 = alloc_domheap_page(d, 0);
-    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);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -669,30 +660,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);
 
@@ -749,9 +728,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;
 
@@ -799,6 +787,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 3f8338e68164 -r bcc4215663e8 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 3f8338e68164 -r bcc4215663e8 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 3f8338e68164 -r bcc4215663e8 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 */
+            domid_t          client_domain; /* IN: the client domain id */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
             uint64_aligned_t client_handle; /* IN: handle to the client page */
         } share; 
         struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG00-0001GD-NP; Thu, 26 Jan 2012 03:27:44 +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 1RqFzy-0001G0-PP
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:43 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327548439!50273171!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcwMzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17435 invoked from network); 26 Jan 2012 03:27:19 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-11.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 03:27:19 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 4F0437EC065;
	Wed, 25 Jan 2012 19:27:40 -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=YMMLo/KnOhArQ08ET5Cz3nyslqX4gVLl0f9FhEzn22of
	VebdXL4o4Uq++vr/j1EkLtP9K/5mbWoz8NswPADsy8GREGcnT6c824a0YIgVUEbT
	fXLWoprvuvrioh/eS2jDXwcF66eakeRAdgbG1xoGUAub/cgbNimGYUMoqLur9ew=
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=1v+cp7A+ALTEsFiZbd/CF4WViPc=; b=D4Jz+XVM+TE
	vqM1yoIEAGv2p/hUOdZDK5L4MXCNmuJ0TGMBTs7MSfmJlPZ1LaUReHm+d9ofF6P/
	STUp7sSBg+eryudvNEUChl7lGuWlhC2GCa9l784nR/YxCNfHy2JX4eweglBMyK4n
	ZwitCxvteVqb0C+bpY33ZibTPWYLMNWQ=
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 325A77EC074; 
	Wed, 25 Jan 2012 19:27:39 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 61e164d6e9566bc5418daef3a3ee9b2227f1d314
Message-Id: <61e164d6e9566bc5418d.1327548746@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 02 of 13] 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   |  13 +++++++++
 2 files changed, 61 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 provides a grant ref and a version. Update interface to handle this
case.

The use case for grant sharing is when sharing from within a backend (e.g.
memshr + blktap2), in which case the backend is only exposed to grant
references.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r bcc4215663e8 -r 61e164d6e956 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -728,18 +728,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 bcc4215663e8 -r 61e164d6e956 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -775,6 +775,19 @@ 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)
 
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed 
+ * to grant references, and this allows sharing of the grefs */
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
+    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
+#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
+    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+
 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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0A-0001KL-Iq; Thu, 26 Jan 2012 03:27:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG09-0001Ir-2n
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:53 +0000
Received: from [85.158.138.51:13092] by server-8.bemta-3.messagelabs.com id
	7D/AC-31878-838C02F4; Thu, 26 Jan 2012 03:27:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327548470!10692282!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzc3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30013 invoked from network); 26 Jan 2012 03:27:51 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-6.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:27:51 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 773EC7EC072;
	Wed, 25 Jan 2012 19:27: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=US3rMPXZcw8q/7f7oDEPAIzSsfOLbfqDJ/+IyISQQJUL
	W2jVPBmD6I/v50pNBvgOFPNIabE6Rvd1VWLv+ul5dCumF9a0CZovklJdsYTOdWaT
	2UOLjL+jvvla7Sxy6gsml7hrx3m6VXIzNZyzzIna+cOoEQIxOvSsb0f82bf/EGo=
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=365jeHomxKlULdXrXRYb+R/JGe8=; b=JTNigBFjVW6
	e1ISDhBCwVYQkR/7apc6eL9g3lGWWkn1xgiHWikWJzWcXLLeEiVeAc/r1d91FtGT
	8qfVBq6Dc+n0Fv/KByyzJWoBaBREG/niLpme+Fm6l5HFKdTuOZyq1sD1W8F2A/Q0
	F6m4uns7Md1qFf8WhlJItCPboEKTbFdc=
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 279887EC065; 
	Wed, 25 Jan 2012 19:27:49 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f859c29d4011c2802cd11ef7003a4d5977f2eab1
Message-Id: <f859c29d4011c2802cd1.1327548753@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32:33 -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 13] Update memshr API and tools
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/blktap2/drivers/tapdisk-vbd.c |   6 +-
 tools/blktap2/drivers/tapdisk.h     |   2 +-
 tools/libxc/xc_memshr.c             |  63 ++++++++++++++++++++++++++++++++++--
 tools/libxc/xenctrl.h               |  19 ++++++++++-
 tools/memshr/bidir-daemon.c         |  34 ++++++++++++++-----
 tools/memshr/bidir-hash.h           |  12 ++++--
 tools/memshr/interface.c            |  30 ++++++++++-------
 tools/memshr/memshr.h               |  11 +++++-
 8 files changed, 139 insertions(+), 38 deletions(-)


This patch is the folded version of API updates, along with the associated tool
changes to ensure that the build is always consistent.

API updates:
- The source domain in the sharing calls is no longer assumed to be dom0.
- Previously, 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 and tools need to be updated to recall the share
  functions with the information needed to fetch the page (which they readily
  have).

Tool updates:
The only (in-tree, that we know of) consumer of the mem sharing API is the
memshr tool. This is updated to use the new API.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>
Acked-by: Ian Campbell <ian.campbell@citrix.com>

diff -r cf70bc85eb23 -r f859c29d4011 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 cf70bc85eb23 -r f859c29d4011 tools/blktap2/drivers/tapdisk.h
--- a/tools/blktap2/drivers/tapdisk.h
+++ b/tools/blktap2/drivers/tapdisk.h
@@ -140,7 +140,7 @@ struct td_request {
 	void                        *private;
     
 #ifdef MEMSHR
-	uint64_t                     memshr_hnd;
+	share_tuple_t                memshr_hnd;
 #endif
 };
 
diff -r cf70bc85eb23 -r f859c29d4011 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -86,24 +86,79 @@ int xc_memshr_nominate_gref(xc_interface
     return ret;
 }
 
-int xc_memshr_share(xc_interface *xch,
-                    uint64_t source_handle,
-                    uint64_t client_handle)
+int xc_memshr_share_gfns(xc_interface *xch,
+                         domid_t source_domain,
+                         unsigned long source_gfn,
+                         uint64_t source_handle,
+                         domid_t client_domain,
+                         unsigned long client_gfn,
+                         uint64_t client_handle)
 {
     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 = 0;
+    domctl.domain = source_domain;
     op = &(domctl.u.mem_sharing_op);
     op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
     op->u.share.source_handle = source_handle;
+    op->u.share.source_gfn    = source_gfn;
+    op->u.share.client_domain = client_domain;
+    op->u.share.client_gfn    = client_gfn;
     op->u.share.client_handle = client_handle;
 
     return do_domctl(xch, &domctl);
 }
 
+int xc_memshr_share_grefs(xc_interface *xch,
+                          domid_t source_domain,
+                          grant_ref_t source_gref,
+                          uint64_t source_handle,
+                          domid_t client_domain,
+                          grant_ref_t client_gref,
+                          uint64_t client_handle)
+{
+    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 = source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
+    op->u.share.source_handle = source_handle;
+    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
+    op->u.share.client_domain = client_domain;
+    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
+    op->u.share.client_handle = client_handle;
+
+    return do_domctl(xch, &domctl);
+}
+
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long 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               = source_domain;
+    op = &(domctl.u.mem_sharing_op);
+    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
+    op->u.share.source_gfn      = source_gfn;
+    op->u.share.source_handle   = source_handle;
+    op->u.share.client_gfn      = client_gfn;
+    op->u.share.client_domain   = client_domain;
+
+    return do_domctl(xch, &domctl);
+}
+
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
diff -r cf70bc85eb23 -r f859c29d4011 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1897,9 +1897,26 @@ int xc_memshr_nominate_gref(xc_interface
                             domid_t domid,
                             grant_ref_t gref,
                             uint64_t *handle);
-int xc_memshr_share(xc_interface *xch,
+int xc_memshr_share_gfns(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
                     uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long client_gfn,
                     uint64_t client_handle);
+int xc_memshr_share_grefs(xc_interface *xch,
+                    domid_t source_domain,
+                    grant_ref_t source_gref,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    grant_ref_t client_gref,
+                    uint64_t client_handle);
+int xc_memshr_add_to_physmap(xc_interface *xch,
+                    domid_t source_domain,
+                    unsigned long source_gfn,
+                    uint64_t source_handle,
+                    domid_t client_domain,
+                    unsigned long client_gfn);
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid);
 int xc_memshr_debug_gfn(xc_interface *xch,
diff -r cf70bc85eb23 -r f859c29d4011 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 cf70bc85eb23 -r f859c29d4011 tools/memshr/bidir-hash.h
--- a/tools/memshr/bidir-hash.h
+++ b/tools/memshr/bidir-hash.h
@@ -20,6 +20,7 @@
 #define __BIDIR_HASH_H__
 
 #include <stdint.h>
+#include <string.h>
 #include "memshr-priv.h"
 
 typedef struct vbdblk {
@@ -81,15 +82,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 +99,15 @@ 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 ( !memcmp(&h1, &h2, sizeof(share_tuple_t)) );
 }
 #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 cf70bc85eb23 -r f859c29d4011 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_grefs(vbd_info.xc_handle, source_st.domain, source_st.frame, 
+                                    source_st.handle, vbd_info.domid, gref, c_hnd);
         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 cf70bc85eb23 -r f859c29d4011 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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0J-0001Rk-1m; Thu, 26 Jan 2012 03:28:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG0H-0001LU-A8
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:28:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327548472!12608930!3
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE3OTEw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 521 invoked from network); 26 Jan 2012 03:27:54 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-5.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:27:54 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 256F77EC065;
	Wed, 25 Jan 2012 19:27: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=AUO/ngwv07Fkoi7LiUQS8MBttxAF+V4SPlot6MfjOBzd
	bKhTMg81LU9MCk1LNw90OLiumAs1phLNdHX7txJzR9WZN6kdfLVjSVcZyCbNPrpD
	hJhOHUyldEBivcKc8qK0blzQc/RyS5+SriSTvXVVs4Lmx9IgkjQ7Ar3z5xS4e+k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=5uD/jlCqUAkpGqibgtxPNL6W3p8=; b=pqKs3lpLvfv
	YB2vyx/FpKFIRnprciXpZCkpeiUMikUfFQkfcbmwJQLsDzzHPxd3tH8D62yzMVzm
	JiZ0+nic1oQ6d6kmL0YS3AcxJ0z37SHKamnWOoFLvhABFY9tHozw8sfbpsznvCBj
	LZSPTBuExWgFXFQzNldQkQd0WET7bTIY=
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 28CE07EC076; 
	Wed, 25 Jan 2012 19:27:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 88856b776fcfc5b3d0ce556d45f8f48e41748c08
Message-Id: <88856b776fcfc5b3d0ce.1327548756@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 12 of 13] Memshrtool: tool to test and exercise
 the sharing subsystem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/tests/mem-sharing/Makefile     |   26 +++++
 tools/tests/mem-sharing/memshrtool.c |  165 +++++++++++++++++++++++++++++++++++
 2 files changed, 191 insertions(+), 0 deletions(-)


This is demo code meant to showcase how to perform sharing
operations. It is useful for testing. We submit it so others in
the list can have unlimited sharing fun, but not necessarily
expecting it be added to the tree.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4cefca5789b1 -r 88856b776fcf tools/tests/mem-sharing/Makefile
--- /dev/null
+++ b/tools/tests/mem-sharing/Makefile
@@ -0,0 +1,26 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS += -Werror
+
+CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_xeninclude)
+
+TARGETS-y := 
+TARGETS-$(CONFIG_X86) += memshrtool
+TARGETS := $(TARGETS-y)
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: $(TARGETS)
+
+.PHONY: clean
+clean:
+	$(RM) *.o $(TARGETS) *~ $(DEPS)
+
+memshrtool: memshrtool.o
+	$(CC) -o $@ $< $(LDFLAGS) $(LDLIBS_libxenctrl)
+
+-include $(DEPS)
diff -r 4cefca5789b1 -r 88856b776fcf tools/tests/mem-sharing/memshrtool.c
--- /dev/null
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -0,0 +1,165 @@
+/*
+ * memshrtool.c
+ *
+ * Copyright 2011 GridCentric Inc. (Adin Scannell, Andres Lagar-Cavilla)
+ */
+
+#include <stdio.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <errno.h>
+#include <string.h>
+#include <sys/mman.h>
+
+#include "xenctrl.h"
+
+static int usage(const char* prog)
+{
+    printf("usage: %s <command> [args...]\n", prog);
+    printf("where <command> may be:\n");
+    printf("  info                    - Display total sharing info.\n");
+    printf("  enable                  - Enable sharing on a domain.\n");
+    printf("  disable                 - Disable sharing on a domain.\n");
+    printf("  nominate <domid> <gfn>  - Nominate a page for sharing.\n");
+    printf("  share <domid> <gfn> <handle> <source> <source-gfn> <source-handle>\n");
+    printf("                          - Share two pages.\n");
+    printf("  unshare <domid> <gfn>   - Unshare a page by grabbing a writable map.\n");
+    printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
+    printf("                          - Populate a page in a domain with a shared page.\n");
+    printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    return 1;
+}
+
+#define R(f) do { \
+    int rc = f; \
+    if ( rc < 0 ) { \
+        printf("error executing %s: %s\n", #f, \
+                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                "problem with client handle" :\
+                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                "problem with source handle" : strerror(errno)); \
+        return rc; \
+    } \
+} while(0)
+
+int main(int argc, const char** argv)
+{
+    const char* cmd = NULL;
+    xc_interface *xch = xc_interface_open(0, 0, 0);
+
+    if( argc < 2 )
+        return usage(argv[0]);
+
+    cmd = argv[1];
+
+    if( !strcasecmp(cmd, "info") )
+    {
+        if( argc != 2 )
+            return usage(argv[0]);
+
+        printf("used = %ld\n", xc_sharing_used_frames(xch));
+        printf("freed = %ld\n", xc_sharing_freed_pages(xch));
+    }
+    else if( !strcasecmp(cmd, "enable") )
+    {
+        domid_t domid;
+
+        if( argc != 3 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        R(xc_memshr_control(xch, domid, 1));
+    }
+    else if( !strcasecmp(cmd, "disable") )
+    {
+        domid_t domid;
+
+        if( argc != 3 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        R(xc_memshr_control(xch, domid, 0));
+    }
+    else if( !strcasecmp(cmd, "nominate") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        uint64_t handle;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        R(xc_memshr_nominate_gfn(xch, domid, gfn, &handle));
+        printf("handle = 0x%08llx\n", (unsigned long long) handle);
+    }
+    else if( !strcasecmp(cmd, "share") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        uint64_t handle;
+        domid_t source_domid;
+        unsigned long source_gfn;
+        uint64_t source_handle;
+
+        if( argc != 8 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        handle = strtol(argv[4], NULL, 0);
+        source_domid = strtol(argv[5], NULL, 0);
+        source_gfn = strtol(argv[6], NULL, 0);
+        source_handle = strtol(argv[7], NULL, 0);
+        R(xc_memshr_share_gfns(xch, source_domid, source_gfn, source_handle, domid, gfn, handle));
+    }
+    else if( !strcasecmp(cmd, "unshare") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        void *map;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        map = xc_map_foreign_range(xch, domid, 4096, PROT_WRITE, gfn);
+        if( map )
+            munmap(map, 4096);
+        R((int)!map);
+    }
+    else if( !strcasecmp(cmd, "add-to-physmap") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        domid_t source_domid;
+        unsigned long source_gfn;
+        uint64_t source_handle;
+
+        if( argc != 7 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        source_domid = strtol(argv[4], NULL, 0);
+        source_gfn = strtol(argv[5], NULL, 0);
+        source_handle = strtol(argv[6], NULL, 0);
+        R(xc_memshr_add_to_physmap(xch, source_domid, source_gfn, source_handle, domid, gfn));
+    }
+    else if( !strcasecmp(cmd, "debug-gfn") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        R(xc_memshr_debug_gfn(xch, domid, gfn));
+    }
+
+    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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0J-0001Rk-1m; Thu, 26 Jan 2012 03:28:03 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG0H-0001LU-A8
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:28:02 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327548472!12608930!3
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE3OTEw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 521 invoked from network); 26 Jan 2012 03:27:54 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-5.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:27:54 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 256F77EC065;
	Wed, 25 Jan 2012 19:27: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=AUO/ngwv07Fkoi7LiUQS8MBttxAF+V4SPlot6MfjOBzd
	bKhTMg81LU9MCk1LNw90OLiumAs1phLNdHX7txJzR9WZN6kdfLVjSVcZyCbNPrpD
	hJhOHUyldEBivcKc8qK0blzQc/RyS5+SriSTvXVVs4Lmx9IgkjQ7Ar3z5xS4e+k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h=
	content-type:mime-version:content-transfer-encoding:subject
	:message-id:in-reply-to:references:date:from:to:cc; s=
	lagarcavilla.org; bh=5uD/jlCqUAkpGqibgtxPNL6W3p8=; b=pqKs3lpLvfv
	YB2vyx/FpKFIRnprciXpZCkpeiUMikUfFQkfcbmwJQLsDzzHPxd3tH8D62yzMVzm
	JiZ0+nic1oQ6d6kmL0YS3AcxJ0z37SHKamnWOoFLvhABFY9tHozw8sfbpsznvCBj
	LZSPTBuExWgFXFQzNldQkQd0WET7bTIY=
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 28CE07EC076; 
	Wed, 25 Jan 2012 19:27:53 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 88856b776fcfc5b3d0ce556d45f8f48e41748c08
Message-Id: <88856b776fcfc5b3d0ce.1327548756@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 12 of 13] Memshrtool: tool to test and exercise
 the sharing subsystem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/tests/mem-sharing/Makefile     |   26 +++++
 tools/tests/mem-sharing/memshrtool.c |  165 +++++++++++++++++++++++++++++++++++
 2 files changed, 191 insertions(+), 0 deletions(-)


This is demo code meant to showcase how to perform sharing
operations. It is useful for testing. We submit it so others in
the list can have unlimited sharing fun, but not necessarily
expecting it be added to the tree.

Signed-off-by: Adin Scannell <adin@scannell.ca>
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 4cefca5789b1 -r 88856b776fcf tools/tests/mem-sharing/Makefile
--- /dev/null
+++ b/tools/tests/mem-sharing/Makefile
@@ -0,0 +1,26 @@
+XEN_ROOT=$(CURDIR)/../../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS += -Werror
+
+CFLAGS += $(CFLAGS_libxenctrl)
+CFLAGS += $(CFLAGS_xeninclude)
+
+TARGETS-y := 
+TARGETS-$(CONFIG_X86) += memshrtool
+TARGETS := $(TARGETS-y)
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: $(TARGETS)
+
+.PHONY: clean
+clean:
+	$(RM) *.o $(TARGETS) *~ $(DEPS)
+
+memshrtool: memshrtool.o
+	$(CC) -o $@ $< $(LDFLAGS) $(LDLIBS_libxenctrl)
+
+-include $(DEPS)
diff -r 4cefca5789b1 -r 88856b776fcf tools/tests/mem-sharing/memshrtool.c
--- /dev/null
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -0,0 +1,165 @@
+/*
+ * memshrtool.c
+ *
+ * Copyright 2011 GridCentric Inc. (Adin Scannell, Andres Lagar-Cavilla)
+ */
+
+#include <stdio.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <errno.h>
+#include <string.h>
+#include <sys/mman.h>
+
+#include "xenctrl.h"
+
+static int usage(const char* prog)
+{
+    printf("usage: %s <command> [args...]\n", prog);
+    printf("where <command> may be:\n");
+    printf("  info                    - Display total sharing info.\n");
+    printf("  enable                  - Enable sharing on a domain.\n");
+    printf("  disable                 - Disable sharing on a domain.\n");
+    printf("  nominate <domid> <gfn>  - Nominate a page for sharing.\n");
+    printf("  share <domid> <gfn> <handle> <source> <source-gfn> <source-handle>\n");
+    printf("                          - Share two pages.\n");
+    printf("  unshare <domid> <gfn>   - Unshare a page by grabbing a writable map.\n");
+    printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
+    printf("                          - Populate a page in a domain with a shared page.\n");
+    printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    return 1;
+}
+
+#define R(f) do { \
+    int rc = f; \
+    if ( rc < 0 ) { \
+        printf("error executing %s: %s\n", #f, \
+                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                "problem with client handle" :\
+                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                "problem with source handle" : strerror(errno)); \
+        return rc; \
+    } \
+} while(0)
+
+int main(int argc, const char** argv)
+{
+    const char* cmd = NULL;
+    xc_interface *xch = xc_interface_open(0, 0, 0);
+
+    if( argc < 2 )
+        return usage(argv[0]);
+
+    cmd = argv[1];
+
+    if( !strcasecmp(cmd, "info") )
+    {
+        if( argc != 2 )
+            return usage(argv[0]);
+
+        printf("used = %ld\n", xc_sharing_used_frames(xch));
+        printf("freed = %ld\n", xc_sharing_freed_pages(xch));
+    }
+    else if( !strcasecmp(cmd, "enable") )
+    {
+        domid_t domid;
+
+        if( argc != 3 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        R(xc_memshr_control(xch, domid, 1));
+    }
+    else if( !strcasecmp(cmd, "disable") )
+    {
+        domid_t domid;
+
+        if( argc != 3 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        R(xc_memshr_control(xch, domid, 0));
+    }
+    else if( !strcasecmp(cmd, "nominate") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        uint64_t handle;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        R(xc_memshr_nominate_gfn(xch, domid, gfn, &handle));
+        printf("handle = 0x%08llx\n", (unsigned long long) handle);
+    }
+    else if( !strcasecmp(cmd, "share") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        uint64_t handle;
+        domid_t source_domid;
+        unsigned long source_gfn;
+        uint64_t source_handle;
+
+        if( argc != 8 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        handle = strtol(argv[4], NULL, 0);
+        source_domid = strtol(argv[5], NULL, 0);
+        source_gfn = strtol(argv[6], NULL, 0);
+        source_handle = strtol(argv[7], NULL, 0);
+        R(xc_memshr_share_gfns(xch, source_domid, source_gfn, source_handle, domid, gfn, handle));
+    }
+    else if( !strcasecmp(cmd, "unshare") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        void *map;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        map = xc_map_foreign_range(xch, domid, 4096, PROT_WRITE, gfn);
+        if( map )
+            munmap(map, 4096);
+        R((int)!map);
+    }
+    else if( !strcasecmp(cmd, "add-to-physmap") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+        domid_t source_domid;
+        unsigned long source_gfn;
+        uint64_t source_handle;
+
+        if( argc != 7 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        source_domid = strtol(argv[4], NULL, 0);
+        source_gfn = strtol(argv[5], NULL, 0);
+        source_handle = strtol(argv[6], NULL, 0);
+        R(xc_memshr_add_to_physmap(xch, source_domid, source_gfn, source_handle, domid, gfn));
+    }
+    else if( !strcasecmp(cmd, "debug-gfn") )
+    {
+        domid_t domid;
+        unsigned long gfn;
+
+        if( argc != 4 )
+            return usage(argv[0]);
+
+        domid = strtol(argv[2], NULL, 0);
+        gfn = strtol(argv[3], NULL, 0);
+        R(xc_memshr_debug_gfn(xch, domid, gfn));
+    }
+
+    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 Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG08-0001It-N1; Thu, 26 Jan 2012 03:27:52 +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 1RqG06-0001GC-3m
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327548462!9856117!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTgxMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3877 invoked from network); 26 Jan 2012 03:27:43 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.177) by server-12.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 03:27:43 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E50027EC069;
	Wed, 25 Jan 2012 19:27: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=EGiZR/LV6nZyfoaO6lf+g5H0s6oM9J/B9tYdDYuN2z4q
	xaF4dbD4NI/Co/8Syztm6ZNkL4NQRwalB9f1I0ViAMZcVfDbLDeZmzwivGCYKVik
	xKKJmYUBfAenTHedF7rJYb12qvxWQ19f6SZJBKM+SOXflVXAR6dvNK+lHM8lnY4=
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=zjlAj2TwtNaJsNRr5SqnTGhWxeQ=; b=vAgH/g9zTMB
	2YfKovTQ8mPhGmtAGMdhxIaMeqAWrXS9prkduoAzGwum9WFoph+nGzDHPVWnpXvF
	MpYVtV0dTScp93aunYiswHfxnR+xuiFoV3n9XvmSXPsFd2cO2yZxR5casLfGw1O5
	LdhVcniwCjnuYVtuBHgmiQ2JK8lc0iTs=
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 866767EC074; 
	Wed, 25 Jan 2012 19:27:40 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f5e3c94b206629878ad71d76b0a97842d430c09a
Message-Id: <f5e3c94b206629878ad7.1327548747@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 03 of 13] 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 |  257 ++++++++++++++++++++++++++++++++++++++---
 xen/arch/x86/mm/mm-locks.h    |   15 +-
 xen/include/asm-x86/mm.h      |   27 +++-
 4 files changed, 275 insertions(+), 98 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.

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>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 61e164d6e956 -r f5e3c94b2066 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1719,7 +1719,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;
 
@@ -1736,7 +1736,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;
 
@@ -4295,76 +4295,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 61e164d6e956 -r f5e3c94b2066 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,21 @@
 
 #include "mm-locks.h"
 
+static shr_handle_t next_handle = 1;
+
 #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 void mem_sharing_audit(void);
+
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+
 static struct list_head shr_audit_list;
 
 static inline void audit_add_list(struct page_info *page)
@@ -51,11 +62,53 @@ 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)
+
 #define mem_sharing_audit() ((void)0)
 
 #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;
+    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) \
@@ -68,7 +121,6 @@ static inline void audit_del_list(struct
 #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); 
 
 typedef struct gfn_info
@@ -78,8 +130,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)
 {
@@ -398,6 +448,113 @@ 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)
+{
+    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);
+
+#ifndef MEM_SHARING_AUDIT
+    /* Now that we've dropped the type, we can unlock */
+    mem_sharing_page_unlock(page);
+#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)
+{
+    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,
@@ -405,7 +562,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;
 
@@ -420,10 +577,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;
     }
 
@@ -432,15 +596,24 @@ 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) )
+        goto out;
+
     /* Initialize the shared state */
     ret = -ENOMEM;
     if ( (page->shared_info = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
+        /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
@@ -448,7 +621,7 @@ int mem_sharing_nominate_page(struct dom
     INIT_LIST_HEAD(&page->shared_info->gfns);
 
     /* 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 )
@@ -479,6 +652,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:
@@ -490,7 +664,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;
@@ -505,26 +679,63 @@ 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 )
+    /* This tricky business is to avoid two callers deadlocking if 
+     * grabbing pages in opposite client/source order */
+    if( mfn_x(smfn) == mfn_x(cmfn) )
+    {
+        /* The pages are already the same.  We could return some
+         * kind of error here, but no matter how you look at it,
+         * the pages are already 'shared'.  It possibly represents
+         * a big problem somewhere else, but as far as sharing is
+         * concerned: great success! */
+        ret = 0;
         goto err_out;
+    }
+    else 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;
     }
 
@@ -551,6 +762,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);
@@ -592,7 +806,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: "
@@ -628,18 +842,20 @@ 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);
         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 )
     {
+        /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;
     }
@@ -648,6 +864,7 @@ gfn_found:
     page = alloc_domheap_page(d, 0);
     if ( !page ) 
     {
+        mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -661,6 +878,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);
     put_page_and_type(old_page);
 
 private_page_found:    
@@ -678,6 +896,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;
@@ -826,8 +1045,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 61e164d6e956 -r f5e3c94b2066 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,22 @@ 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
+
+/* We use an efficient per-page lock when AUDIT is not enabled. */
+
+#endif /* MEM_SHARING_AUDIT */
 
 /* Nested P2M lock (per-domain)
  *
diff -r 61e164d6e956 -r f5e3c94b2066 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -337,6 +337,29 @@ 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. 
+ *
+ * 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 +611,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 Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG08-0001It-N1; Thu, 26 Jan 2012 03:27:52 +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 1RqG06-0001GC-3m
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327548462!9856117!1
X-Originating-IP: [208.97.132.177]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNzcgPT4gMTgxMDc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3877 invoked from network); 26 Jan 2012 03:27:43 -0000
Received: from caiajhbdcbhh.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.177) by server-12.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 03:27:43 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id E50027EC069;
	Wed, 25 Jan 2012 19:27: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=EGiZR/LV6nZyfoaO6lf+g5H0s6oM9J/B9tYdDYuN2z4q
	xaF4dbD4NI/Co/8Syztm6ZNkL4NQRwalB9f1I0ViAMZcVfDbLDeZmzwivGCYKVik
	xKKJmYUBfAenTHedF7rJYb12qvxWQ19f6SZJBKM+SOXflVXAR6dvNK+lHM8lnY4=
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=zjlAj2TwtNaJsNRr5SqnTGhWxeQ=; b=vAgH/g9zTMB
	2YfKovTQ8mPhGmtAGMdhxIaMeqAWrXS9prkduoAzGwum9WFoph+nGzDHPVWnpXvF
	MpYVtV0dTScp93aunYiswHfxnR+xuiFoV3n9XvmSXPsFd2cO2yZxR5casLfGw1O5
	LdhVcniwCjnuYVtuBHgmiQ2JK8lc0iTs=
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 866767EC074; 
	Wed, 25 Jan 2012 19:27:40 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: f5e3c94b206629878ad71d76b0a97842d430c09a
Message-Id: <f5e3c94b206629878ad7.1327548747@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 03 of 13] 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 |  257 ++++++++++++++++++++++++++++++++++++++---
 xen/arch/x86/mm/mm-locks.h    |   15 +-
 xen/include/asm-x86/mm.h      |   27 +++-
 4 files changed, 275 insertions(+), 98 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.

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>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 61e164d6e956 -r f5e3c94b2066 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1719,7 +1719,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;
 
@@ -1736,7 +1736,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;
 
@@ -4295,76 +4295,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 61e164d6e956 -r f5e3c94b2066 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,21 @@
 
 #include "mm-locks.h"
 
+static shr_handle_t next_handle = 1;
+
 #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 void mem_sharing_audit(void);
+
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
+
 static struct list_head shr_audit_list;
 
 static inline void audit_add_list(struct page_info *page)
@@ -51,11 +62,53 @@ 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)
+
 #define mem_sharing_audit() ((void)0)
 
 #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;
+    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) \
@@ -68,7 +121,6 @@ static inline void audit_del_list(struct
 #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); 
 
 typedef struct gfn_info
@@ -78,8 +130,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)
 {
@@ -398,6 +448,113 @@ 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)
+{
+    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);
+
+#ifndef MEM_SHARING_AUDIT
+    /* Now that we've dropped the type, we can unlock */
+    mem_sharing_page_unlock(page);
+#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)
+{
+    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,
@@ -405,7 +562,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;
 
@@ -420,10 +577,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;
     }
 
@@ -432,15 +596,24 @@ 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) )
+        goto out;
+
     /* Initialize the shared state */
     ret = -ENOMEM;
     if ( (page->shared_info = 
             xmalloc(struct page_sharing_info)) == NULL )
     {
+        /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto out;
     }
@@ -448,7 +621,7 @@ int mem_sharing_nominate_page(struct dom
     INIT_LIST_HEAD(&page->shared_info->gfns);
 
     /* 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 )
@@ -479,6 +652,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:
@@ -490,7 +664,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;
@@ -505,26 +679,63 @@ 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 )
+    /* This tricky business is to avoid two callers deadlocking if 
+     * grabbing pages in opposite client/source order */
+    if( mfn_x(smfn) == mfn_x(cmfn) )
+    {
+        /* The pages are already the same.  We could return some
+         * kind of error here, but no matter how you look at it,
+         * the pages are already 'shared'.  It possibly represents
+         * a big problem somewhere else, but as far as sharing is
+         * concerned: great success! */
+        ret = 0;
         goto err_out;
+    }
+    else 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;
     }
 
@@ -551,6 +762,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);
@@ -592,7 +806,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: "
@@ -628,18 +842,20 @@ 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);
         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 )
     {
+        /* Making a page private atomically unlocks it */
         BUG_ON(page_make_private(d, page) != 0);
         goto private_page_found;
     }
@@ -648,6 +864,7 @@ gfn_found:
     page = alloc_domheap_page(d, 0);
     if ( !page ) 
     {
+        mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
         shr_unlock();
@@ -661,6 +878,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);
     put_page_and_type(old_page);
 
 private_page_found:    
@@ -678,6 +896,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;
@@ -826,8 +1045,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 61e164d6e956 -r f5e3c94b2066 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,22 @@ 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
+
+/* We use an efficient per-page lock when AUDIT is not enabled. */
+
+#endif /* MEM_SHARING_AUDIT */
 
 /* Nested P2M lock (per-domain)
  *
diff -r 61e164d6e956 -r f5e3c94b2066 xen/include/asm-x86/mm.h
--- a/xen/include/asm-x86/mm.h
+++ b/xen/include/asm-x86/mm.h
@@ -337,6 +337,29 @@ 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. 
+ *
+ * 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 +611,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 Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqFzx-0001Fv-UL; Thu, 26 Jan 2012 03:27:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqFzw-0001Fq-Am
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:40 +0000
Received: from [85.158.139.83:50850] by server-8.bemta-5.messagelabs.com id
	D9/0B-20787-B28C02F4; Thu, 26 Jan 2012 03:27:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327548458!12406489!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzc3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29507 invoked from network); 26 Jan 2012 03:27:38 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-6.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:27:38 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 6A3217EC069;
	Wed, 25 Jan 2012 19:27:37 -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=gZ+HsLugP2fhEzpU9jFDAd
	H+DVTcXvl2C0dUDHlkZrTruc0UJj6c0uCu03ov5DYaygpVyc3HZRTIUqRw4NiD9x
	8jN6BP3hEc7RhWnEocreC10aUWPZx7GY8PuCcxW+Nc1jW0Dlz+1OURf4Oh9kuMWT
	+ROitr4/5cumu2s9uw7qI=
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=XGTNIpHUr8Ya
	0H39YaFcrjXNvSE=; b=RiwJIRZp/h4ummBEhMBQvneth/F607vQDfIzoO3uSZ47
	5hy+RJmsfCTiB1pNFeef5gGkjPzxr/Ax00VwFAQfpCDtWb0+Thp6ueBLToJ2SYGO
	tj9JoqV3Y6uKXilYddDKQhwSBJh4ITgaZ/Db2ySwhTXJ3Xub0xkBxXXoUXkZlPc=
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 0B6BA7EC065; 
	Wed, 25 Jan 2012 19:27:35 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 00 of 13] Sharing overhaul 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

Changes from sharing overhaul v3 posted Jan 16th

- Patches 1,2: Improved description in header

- Patch 1:
  + Changed mem_sharing audit from int to void
  + Fixed format of audit debugtrace printk's

Patch 2: added comment to code explaining grant sharing raison-d'etre

Patches 4 (mainly), but 6 and 8 as well: 
  + Using a per-cpu static struct instead of stack var for lock
    order and deadlock detection book-keeping.

Patches 7, 9, 11: Added Acked-by's
 (all the major tools patches acked-by tools maintainers now)

Patch 8:
  + Fixed off-by-one audit type accounting caused by PGT_locked bumping
    the page type count

New patch 13: rename shared_info to sharing so that grep/cscope/etc
              don't alias it with the unrelated shared info page.

Regular description follows...
--------------------

This patch series brings about a set of changes to the sharing support
in the hypervisor and tools. Specifically:

- Granular scalable locking: lock mfn's individually when sharing/unsharing
  them. Do not rely on a global lock. Use RCU to maintain a list of all
  shared frames for audit purposes.

- Refreshed stats: they now work (tm), and are accesible via libxc
  and console.

- libxl/xl support to get sharing stats.

- New sharing command "add to physmap", to directly populate a new domain
  with shared frames.

- Toolstack and memshr kept in sync.

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.

Patches 9, 10 11 are tools patches. Patches 1 to 8 are x86/mm.
Patch 12 is a simple testing tool. Patch 13 is a style fix, no
functional changes.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/mem_sharing.c        |  539 +++++++++++++++++-----------------
 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          |   13 +
 xen/arch/x86/mm.c                    |   74 +----
 xen/arch/x86/mm/mem_sharing.c        |  257 +++++++++++++++-
 xen/arch/x86/mm/mm-locks.h           |   15 +-
 xen/include/asm-x86/mm.h             |   27 +-
 xen/arch/x86/mm/mem_sharing.c        |   16 +
 xen/arch/x86/mm/mm-locks.h           |   18 +-
 xen/include/asm-x86/mm.h             |    3 +-
 xen/arch/x86/mm.c                    |    6 -
 xen/arch/x86/mm/mem_sharing.c        |   25 +
 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/mem_sharing.c        |  103 ++++++
 xen/include/public/domctl.h          |    3 +-
 xen/arch/ia64/xen/mm.c               |    5 +
 xen/arch/x86/mm.c                    |   14 +
 xen/common/keyhandler.c              |    7 +-
 xen/include/xen/mm.h                 |    3 +
 xen/arch/x86/mm/mem_sharing.c        |   93 ++---
 xen/arch/x86/mm/mm-locks.h           |   18 -
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 tools/blktap2/drivers/tapdisk-vbd.c  |    6 +-
 tools/blktap2/drivers/tapdisk.h      |    2 +-
 tools/libxc/xc_memshr.c              |   63 +++-
 tools/libxc/xenctrl.h                |   19 +-
 tools/memshr/bidir-daemon.c          |   34 +-
 tools/memshr/bidir-hash.h            |   12 +-
 tools/memshr/interface.c             |   30 +-
 tools/memshr/memshr.h                |   11 +-
 tools/libxc/xc_memshr.c              |   10 +
 tools/libxc/xenctrl.h                |   17 +
 docs/man/xl.pod.1                    |   13 +
 tools/libxl/libxl.c                  |    2 +
 tools/libxl/libxl_types.idl          |    2 +
 tools/libxl/xl.h                     |    1 +
 tools/libxl/xl_cmdimpl.c             |   66 ++++
 tools/libxl/xl_cmdtable.c            |    5 +
 tools/tests/mem-sharing/Makefile     |   26 +
 tools/tests/mem-sharing/memshrtool.c |  165 ++++++++++
 xen/arch/x86/mm/mem_sharing.c        |   64 ++--
 xen/include/asm-x86/mm.h             |    2 +-
 48 files changed, 1360 insertions(+), 537 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqFzx-0001Fv-UL; Thu, 26 Jan 2012 03:27:41 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqFzw-0001Fq-Am
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:40 +0000
Received: from [85.158.139.83:50850] by server-8.bemta-5.messagelabs.com id
	D9/0B-20787-B28C02F4; Thu, 26 Jan 2012 03:27:39 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327548458!12406489!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzc3Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29507 invoked from network); 26 Jan 2012 03:27:38 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.83) by server-6.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:27:38 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 6A3217EC069;
	Wed, 25 Jan 2012 19:27:37 -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=gZ+HsLugP2fhEzpU9jFDAd
	H+DVTcXvl2C0dUDHlkZrTruc0UJj6c0uCu03ov5DYaygpVyc3HZRTIUqRw4NiD9x
	8jN6BP3hEc7RhWnEocreC10aUWPZx7GY8PuCcxW+Nc1jW0Dlz+1OURf4Oh9kuMWT
	+ROitr4/5cumu2s9uw7qI=
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=XGTNIpHUr8Ya
	0H39YaFcrjXNvSE=; b=RiwJIRZp/h4ummBEhMBQvneth/F607vQDfIzoO3uSZ47
	5hy+RJmsfCTiB1pNFeef5gGkjPzxr/Ax00VwFAQfpCDtWb0+Thp6ueBLToJ2SYGO
	tj9JoqV3Y6uKXilYddDKQhwSBJh4ITgaZ/Db2ySwhTXJ3Xub0xkBxXXoUXkZlPc=
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 0B6BA7EC065; 
	Wed, 25 Jan 2012 19:27:35 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 00 of 13] Sharing overhaul 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

Changes from sharing overhaul v3 posted Jan 16th

- Patches 1,2: Improved description in header

- Patch 1:
  + Changed mem_sharing audit from int to void
  + Fixed format of audit debugtrace printk's

Patch 2: added comment to code explaining grant sharing raison-d'etre

Patches 4 (mainly), but 6 and 8 as well: 
  + Using a per-cpu static struct instead of stack var for lock
    order and deadlock detection book-keeping.

Patches 7, 9, 11: Added Acked-by's
 (all the major tools patches acked-by tools maintainers now)

Patch 8:
  + Fixed off-by-one audit type accounting caused by PGT_locked bumping
    the page type count

New patch 13: rename shared_info to sharing so that grep/cscope/etc
              don't alias it with the unrelated shared info page.

Regular description follows...
--------------------

This patch series brings about a set of changes to the sharing support
in the hypervisor and tools. Specifically:

- Granular scalable locking: lock mfn's individually when sharing/unsharing
  them. Do not rely on a global lock. Use RCU to maintain a list of all
  shared frames for audit purposes.

- Refreshed stats: they now work (tm), and are accesible via libxc
  and console.

- libxl/xl support to get sharing stats.

- New sharing command "add to physmap", to directly populate a new domain
  with shared frames.

- Toolstack and memshr kept in sync.

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.

Patches 9, 10 11 are tools patches. Patches 1 to 8 are x86/mm.
Patch 12 is a simple testing tool. Patch 13 is a style fix, no
functional changes.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 xen/arch/x86/mm/mem_sharing.c        |  539 +++++++++++++++++-----------------
 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          |   13 +
 xen/arch/x86/mm.c                    |   74 +----
 xen/arch/x86/mm/mem_sharing.c        |  257 +++++++++++++++-
 xen/arch/x86/mm/mm-locks.h           |   15 +-
 xen/include/asm-x86/mm.h             |   27 +-
 xen/arch/x86/mm/mem_sharing.c        |   16 +
 xen/arch/x86/mm/mm-locks.h           |   18 +-
 xen/include/asm-x86/mm.h             |    3 +-
 xen/arch/x86/mm.c                    |    6 -
 xen/arch/x86/mm/mem_sharing.c        |   25 +
 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/mem_sharing.c        |  103 ++++++
 xen/include/public/domctl.h          |    3 +-
 xen/arch/ia64/xen/mm.c               |    5 +
 xen/arch/x86/mm.c                    |   14 +
 xen/common/keyhandler.c              |    7 +-
 xen/include/xen/mm.h                 |    3 +
 xen/arch/x86/mm/mem_sharing.c        |   93 ++---
 xen/arch/x86/mm/mm-locks.h           |   18 -
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 tools/blktap2/drivers/tapdisk-vbd.c  |    6 +-
 tools/blktap2/drivers/tapdisk.h      |    2 +-
 tools/libxc/xc_memshr.c              |   63 +++-
 tools/libxc/xenctrl.h                |   19 +-
 tools/memshr/bidir-daemon.c          |   34 +-
 tools/memshr/bidir-hash.h            |   12 +-
 tools/memshr/interface.c             |   30 +-
 tools/memshr/memshr.h                |   11 +-
 tools/libxc/xc_memshr.c              |   10 +
 tools/libxc/xenctrl.h                |   17 +
 docs/man/xl.pod.1                    |   13 +
 tools/libxl/libxl.c                  |    2 +
 tools/libxl/libxl_types.idl          |    2 +
 tools/libxl/xl.h                     |    1 +
 tools/libxl/xl_cmdimpl.c             |   66 ++++
 tools/libxl/xl_cmdtable.c            |    5 +
 tools/tests/mem-sharing/Makefile     |   26 +
 tools/tests/mem-sharing/memshrtool.c |  165 ++++++++++
 xen/arch/x86/mm/mem_sharing.c        |   64 ++--
 xen/include/asm-x86/mm.h             |    2 +-
 48 files changed, 1360 insertions(+), 537 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:28:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0A-0001Ju-3i; Thu, 26 Jan 2012 03:27:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG07-0001I6-MX
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:52 +0000
Received: from [85.158.138.51:62113] by server-2.bemta-3.messagelabs.com id
	A3/98-24515-638C02F4; Thu, 26 Jan 2012 03:27:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327548469!10703115!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE3OTEw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14096 invoked from network); 26 Jan 2012 03:27:49 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:27:49 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id EB5167EC069;
	Wed, 25 Jan 2012 19:27: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=DTdBuQ1GPQq6gsEO+lQAGh2sEMCDCZ6kAmuC+ZE85o1H
	rvgJSGLswmVEBzQ9q6i1D7AvQVD16lYPSqFp/NWm+2596l5LMRQNsXkbfqBCTUj1
	jmCr4R5S8jhJod88mGpkafb9lf6c6MIwITS9WS7dF/fJ5I1Nd0YGCJpzU2FYqjI=
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=e1za3Ha4SMA5bUyBaeeJb7g1gA8=; b=Z6Qz/lTGmBE
	woKNLPC6oKefl6fEXOsqY6Av3L3bLSECDc3a9OD5xhFQo7qQfWchHrmXBNemoddK
	tZ/6M8m9EXgVqXqgpdCf3QHljM8JRUN0cmdL6YviAmb2YH54lJF993U0CGyj0hjN
	EDs+eLdRC/7OCeOvQ6kn8FoUK7h+q8Ds=
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 8E1407EC065; 
	Wed, 25 Jan 2012 19:27:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: cf70bc85eb234d58a19a8e5bd177705dcd3e752b
Message-Id: <cf70bc85eb234d58a19a.1327548752@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 08 of 13] 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     |  93 ++++++++++++++++++--------------------
 xen/arch/x86/mm/mm-locks.h        |  18 -------
 xen/include/asm-x86/mem_sharing.h |   1 +
 3 files changed, 44 insertions(+), 68 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r a45fb86e2419 -r cf70bc85eb23 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"
 
@@ -46,48 +47,49 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
 #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 void mem_sharing_audit(void);
 
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 
 static struct list_head shr_audit_list;
+static spinlock_t shr_audit_lock;
+DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
+
+/* 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)
 {
     INIT_LIST_HEAD(&page->shared_info->entry);
-    list_add(&page->shared_info->entry, &shr_audit_list);
+    spin_lock(&shr_audit_lock);
+    list_add_rcu(&page->shared_info->entry, &shr_audit_list);
+    spin_unlock(&shr_audit_lock);
 }
 
 static inline void audit_del_list(struct page_info *page)
 {
-    list_del(&page->shared_info->entry);
+    spin_lock(&shr_audit_lock);
+    list_del_rcu(&page->shared_info->entry);
+    spin_unlock(&shr_audit_lock);
+    INIT_RCU_HEAD(&page->shared_info->rcu_head);
+    call_rcu(&page->shared_info->rcu_head, _free_pg_shared_info);
 }
 
-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)
-
 #define mem_sharing_audit() ((void)0)
 
 #define audit_add_list(p)  ((void)0)
-#define audit_del_list(p)  ((void)0)
+static inline void audit_del_list(struct page_info *page)
+{
+    xfree(page->shared_info);
+}
+
+#endif /* MEM_SHARING_AUDIT */
 
 static inline int mem_sharing_page_lock(struct page_info *pg)
 {
@@ -125,7 +127,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)
@@ -213,10 +214,11 @@ static void mem_sharing_audit(void)
     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)
+    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;
@@ -228,6 +230,15 @@ static void 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) )
+        {
+           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) )
         {
@@ -300,7 +311,8 @@ static void mem_sharing_audit(void)
             put_domain(d);
             nr_gfns++;
         }
-        if ( nr_gfns != (pg->u.inuse.type_info & PGT_count_mask) )
+        /* The type count has an extra ref because we have locked the page */
+        if ( (nr_gfns + 1) != (pg->u.inuse.type_info & PGT_count_mask) )
         {
             MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
                               "nr_gfns in list %lu, in type_info %lx\n",
@@ -308,8 +320,12 @@ static void mem_sharing_audit(void)
                               (pg->u.inuse.type_info & PGT_count_mask));
             errors++;
         }
+
+        mem_sharing_page_unlock(pg);
     }
 
+    rcu_read_unlock(&shr_audit_read_lock);
+
     if ( count_found != count_expected )
     {
         MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
@@ -533,14 +549,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);
@@ -551,10 +563,8 @@ static int page_make_private(struct doma
     /* Drop the final typecount */
     put_page_and_type(page);
 
-#ifndef MEM_SHARING_AUDIT
     /* Now that we've dropped the type, we can unlock */
     mem_sharing_page_unlock(page);
-#endif
 
     /* Change the owner */
     ASSERT(page_get_owner(page) == dom_cow);
@@ -604,7 +614,6 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = 0UL;
 
-    shr_lock(); 
     mfn = get_gfn(d, gfn, &p2mt);
 
     /* Check if mfn is valid */
@@ -696,7 +705,6 @@ int mem_sharing_nominate_page(struct dom
 
 out:
     put_gfn(d, gfn);
-    shr_unlock();
     return ret;
 }
 
@@ -711,8 +719,6 @@ int mem_sharing_share_pages(struct domai
     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);
@@ -798,7 +804,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);
@@ -816,7 +821,6 @@ int mem_sharing_share_pages(struct domai
 err_out:
     put_gfn(cd, cgfn);
     put_gfn(sd, sgfn);
-    shr_unlock();
     return ret;
 }
 
@@ -899,17 +903,12 @@ int mem_sharing_unshare_page(struct doma
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
    
-    /* 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();
     mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
     if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
-        shr_unlock();
         return 0;
     }
 
@@ -940,7 +939,6 @@ gfn_found:
     {
         /* Clean up shared state */
         audit_del_list(page);
-        xfree(page->shared_info);
         page->shared_info = NULL;
         atomic_dec(&nr_shared_mfns);
     }
@@ -956,7 +954,6 @@ gfn_found:
             test_and_clear_bit(_PGC_allocated, &page->count_info) ) 
             put_page(page);
         put_gfn(d, gfn);
-        shr_unlock();
 
         return 0;
     }
@@ -975,7 +972,6 @@ gfn_found:
         mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
-        shr_unlock();
         return -ENOMEM;
     }
 
@@ -1006,7 +1002,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;
 }
 
@@ -1179,9 +1174,7 @@ int mem_sharing_domctl(struct domain *d,
             break;
     }
 
-    shr_lock();
     mem_sharing_audit();
-    shr_unlock();
 
     return rc;
 }
@@ -1190,7 +1183,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 a45fb86e2419 -r cf70bc85eb23 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 a45fb86e2419 -r cf70bc85eb23 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -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 Thu Jan 26 03:28:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqG0A-0001Ju-3i; Thu, 26 Jan 2012 03:27:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqG07-0001I6-MX
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:27:52 +0000
Received: from [85.158.138.51:62113] by server-2.bemta-3.messagelabs.com id
	A3/98-24515-638C02F4; Thu, 26 Jan 2012 03:27:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327548469!10703115!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE3OTEw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14096 invoked from network); 26 Jan 2012 03:27:49 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.5) by server-10.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:27:49 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id EB5167EC069;
	Wed, 25 Jan 2012 19:27: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=DTdBuQ1GPQq6gsEO+lQAGh2sEMCDCZ6kAmuC+ZE85o1H
	rvgJSGLswmVEBzQ9q6i1D7AvQVD16lYPSqFp/NWm+2596l5LMRQNsXkbfqBCTUj1
	jmCr4R5S8jhJod88mGpkafb9lf6c6MIwITS9WS7dF/fJ5I1Nd0YGCJpzU2FYqjI=
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=e1za3Ha4SMA5bUyBaeeJb7g1gA8=; b=Z6Qz/lTGmBE
	woKNLPC6oKefl6fEXOsqY6Av3L3bLSECDc3a9OD5xhFQo7qQfWchHrmXBNemoddK
	tZ/6M8m9EXgVqXqgpdCf3QHljM8JRUN0cmdL6YviAmb2YH54lJF993U0CGyj0hjN
	EDs+eLdRC/7OCeOvQ6kn8FoUK7h+q8Ds=
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 8E1407EC065; 
	Wed, 25 Jan 2012 19:27:47 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: cf70bc85eb234d58a19a8e5bd177705dcd3e752b
Message-Id: <cf70bc85eb234d58a19a.1327548752@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327548744@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:32: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 08 of 13] 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     |  93 ++++++++++++++++++--------------------
 xen/arch/x86/mm/mm-locks.h        |  18 -------
 xen/include/asm-x86/mem_sharing.h |   1 +
 3 files changed, 44 insertions(+), 68 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r a45fb86e2419 -r cf70bc85eb23 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"
 
@@ -46,48 +47,49 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
 #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 void mem_sharing_audit(void);
 
 #define MEM_SHARING_DEBUG(_f, _a...)                                  \
     debugtrace_printk("mem_sharing_debug: %s(): " _f, __func__, ##_a)
 
 static struct list_head shr_audit_list;
+static spinlock_t shr_audit_lock;
+DEFINE_RCU_READ_LOCK(shr_audit_read_lock);
+
+/* 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)
 {
     INIT_LIST_HEAD(&page->shared_info->entry);
-    list_add(&page->shared_info->entry, &shr_audit_list);
+    spin_lock(&shr_audit_lock);
+    list_add_rcu(&page->shared_info->entry, &shr_audit_list);
+    spin_unlock(&shr_audit_lock);
 }
 
 static inline void audit_del_list(struct page_info *page)
 {
-    list_del(&page->shared_info->entry);
+    spin_lock(&shr_audit_lock);
+    list_del_rcu(&page->shared_info->entry);
+    spin_unlock(&shr_audit_lock);
+    INIT_RCU_HEAD(&page->shared_info->rcu_head);
+    call_rcu(&page->shared_info->rcu_head, _free_pg_shared_info);
 }
 
-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)
-
 #define mem_sharing_audit() ((void)0)
 
 #define audit_add_list(p)  ((void)0)
-#define audit_del_list(p)  ((void)0)
+static inline void audit_del_list(struct page_info *page)
+{
+    xfree(page->shared_info);
+}
+
+#endif /* MEM_SHARING_AUDIT */
 
 static inline int mem_sharing_page_lock(struct page_info *pg)
 {
@@ -125,7 +127,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)
@@ -213,10 +214,11 @@ static void mem_sharing_audit(void)
     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)
+    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;
@@ -228,6 +230,15 @@ static void 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) )
+        {
+           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) )
         {
@@ -300,7 +311,8 @@ static void mem_sharing_audit(void)
             put_domain(d);
             nr_gfns++;
         }
-        if ( nr_gfns != (pg->u.inuse.type_info & PGT_count_mask) )
+        /* The type count has an extra ref because we have locked the page */
+        if ( (nr_gfns + 1) != (pg->u.inuse.type_info & PGT_count_mask) )
         {
             MEM_SHARING_DEBUG("Mismatched counts for MFN=%lx."
                               "nr_gfns in list %lu, in type_info %lx\n",
@@ -308,8 +320,12 @@ static void mem_sharing_audit(void)
                               (pg->u.inuse.type_info & PGT_count_mask));
             errors++;
         }
+
+        mem_sharing_page_unlock(pg);
     }
 
+    rcu_read_unlock(&shr_audit_read_lock);
+
     if ( count_found != count_expected )
     {
         MEM_SHARING_DEBUG("Expected %ld shared mfns, found %ld.",
@@ -533,14 +549,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);
@@ -551,10 +563,8 @@ static int page_make_private(struct doma
     /* Drop the final typecount */
     put_page_and_type(page);
 
-#ifndef MEM_SHARING_AUDIT
     /* Now that we've dropped the type, we can unlock */
     mem_sharing_page_unlock(page);
-#endif
 
     /* Change the owner */
     ASSERT(page_get_owner(page) == dom_cow);
@@ -604,7 +614,6 @@ int mem_sharing_nominate_page(struct dom
 
     *phandle = 0UL;
 
-    shr_lock(); 
     mfn = get_gfn(d, gfn, &p2mt);
 
     /* Check if mfn is valid */
@@ -696,7 +705,6 @@ int mem_sharing_nominate_page(struct dom
 
 out:
     put_gfn(d, gfn);
-    shr_unlock();
     return ret;
 }
 
@@ -711,8 +719,6 @@ int mem_sharing_share_pages(struct domai
     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);
@@ -798,7 +804,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);
@@ -816,7 +821,6 @@ int mem_sharing_share_pages(struct domai
 err_out:
     put_gfn(cd, cgfn);
     put_gfn(sd, sgfn);
-    shr_unlock();
     return ret;
 }
 
@@ -899,17 +903,12 @@ int mem_sharing_unshare_page(struct doma
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
    
-    /* 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();
     mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
     if ( !p2m_is_shared(p2mt) ) {
         put_gfn(d, gfn);
-        shr_unlock();
         return 0;
     }
 
@@ -940,7 +939,6 @@ gfn_found:
     {
         /* Clean up shared state */
         audit_del_list(page);
-        xfree(page->shared_info);
         page->shared_info = NULL;
         atomic_dec(&nr_shared_mfns);
     }
@@ -956,7 +954,6 @@ gfn_found:
             test_and_clear_bit(_PGC_allocated, &page->count_info) ) 
             put_page(page);
         put_gfn(d, gfn);
-        shr_unlock();
 
         return 0;
     }
@@ -975,7 +972,6 @@ gfn_found:
         mem_sharing_page_unlock(old_page);
         put_gfn(d, gfn);
         mem_sharing_notify_helper(d, gfn);
-        shr_unlock();
         return -ENOMEM;
     }
 
@@ -1006,7 +1002,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;
 }
 
@@ -1179,9 +1174,7 @@ int mem_sharing_domctl(struct domain *d,
             break;
     }
 
-    shr_lock();
     mem_sharing_audit();
-    shr_unlock();
 
     return rc;
 }
@@ -1190,7 +1183,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 a45fb86e2419 -r cf70bc85eb23 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 a45fb86e2419 -r cf70bc85eb23 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -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 Thu Jan 26 03:48:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqGJq-0003cQ-TO; Thu, 26 Jan 2012 03:48:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJo-0003c0-Pi
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:12 +0000
Received: from [85.158.139.83:40485] by server-11.bemta-5.messagelabs.com id
	2F/D8-18383-CFCC02F4; Thu, 26 Jan 2012 03:48:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327549690!5084472!2
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjAxNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2413 invoked from network); 26 Jan 2012 03:48:11 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:11 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 1B0004B008F;
	Wed, 25 Jan 2012 19:48:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JPl8aVFwUhF8sd8mDgGfj43z046KNYE5hONEBAtwhFv7
	MTdLncW+3Y8DFwuAWyjbdjY0roaPp79aWQTpjr6PWoXDqMVtd+SrCQH6m0oBe8EC
	FqAbAUJOn8sqJldKVSF3V1QTtID7PE/oaYwiBpFulg+qS1Ji0jArWAi3W2n2btg=
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=a6On01e2ekROjELTxHygV5Yj8nQ=; b=GrVJioTBusH
	7fnyGGgbOxmRrOevyopznoyLkievOyfYuLj5c38G9TlfofuAhK07kWjQW23YlkLT
	jUKIrai2Qka2hTeh0IP3HsEuG4SpAjeUUMyIOkr1ih+rj9F1+a+d4PzWLPfPjDZi
	QXjp2wls6YB5oJ0Um4siFW6yxLzvhjHM=
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 6B6984B007C; 
	Wed, 25 Jan 2012 19:48:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 39e2fc847c57ba4d4a143ae07a1c93c3b027fbab
Message-Id: <39e2fc847c57ba4d4a14.1327550008@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 8] x86/mm: Output domain count of paged
	pages in 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/common/keyhandler.c |  6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c4b96d2cba06 -r 39e2fc847c57 xen/common/keyhandler.c
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -250,8 +250,10 @@ 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 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("    nr_pages=%d xenheap_pages=%d shared_pages=%u paged_pages=%u "
+               "dirty_cpus=%s max_pages=%u\n", d->tot_pages, d->xenheap_pages, 
+                atomic_read(&d->shr_pages), atomic_read(&d->paged_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],

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03:48:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqGJq-0003cQ-TO; Thu, 26 Jan 2012 03:48:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJo-0003c0-Pi
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:12 +0000
Received: from [85.158.139.83:40485] by server-11.bemta-5.messagelabs.com id
	2F/D8-18383-CFCC02F4; Thu, 26 Jan 2012 03:48:12 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327549690!5084472!2
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjAxNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2413 invoked from network); 26 Jan 2012 03:48:11 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:11 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 1B0004B008F;
	Wed, 25 Jan 2012 19:48:11 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=JPl8aVFwUhF8sd8mDgGfj43z046KNYE5hONEBAtwhFv7
	MTdLncW+3Y8DFwuAWyjbdjY0roaPp79aWQTpjr6PWoXDqMVtd+SrCQH6m0oBe8EC
	FqAbAUJOn8sqJldKVSF3V1QTtID7PE/oaYwiBpFulg+qS1Ji0jArWAi3W2n2btg=
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=a6On01e2ekROjELTxHygV5Yj8nQ=; b=GrVJioTBusH
	7fnyGGgbOxmRrOevyopznoyLkievOyfYuLj5c38G9TlfofuAhK07kWjQW23YlkLT
	jUKIrai2Qka2hTeh0IP3HsEuG4SpAjeUUMyIOkr1ih+rj9F1+a+d4PzWLPfPjDZi
	QXjp2wls6YB5oJ0Um4siFW6yxLzvhjHM=
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 6B6984B007C; 
	Wed, 25 Jan 2012 19:48:10 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 39e2fc847c57ba4d4a143ae07a1c93c3b027fbab
Message-Id: <39e2fc847c57ba4d4a14.1327550008@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:28 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 4 of 8] x86/mm: Output domain count of paged
	pages in 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/common/keyhandler.c |  6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c4b96d2cba06 -r 39e2fc847c57 xen/common/keyhandler.c
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -250,8 +250,10 @@ 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 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("    nr_pages=%d xenheap_pages=%d shared_pages=%u paged_pages=%u "
+               "dirty_cpus=%s max_pages=%u\n", d->tot_pages, d->xenheap_pages, 
+                atomic_read(&d->shr_pages), atomic_read(&d->paged_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],

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJr-0003ce-AJ; Thu, 26 Jan 2012 03:48:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJq-0003c0-3G
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:14 +0000
Received: from [85.158.139.83:51477] by server-11.bemta-5.messagelabs.com id
	72/E8-18383-DFCC02F4; Thu, 26 Jan 2012 03:48:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327549692!12405445!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTkyMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6556 invoked from network); 26 Jan 2012 03:48:13 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.119) by server-10.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:13 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 10EE54B0084;
	Wed, 25 Jan 2012 19:48:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=dh+u+GnOUgKXH08A4olwsSSCp0dALmOyB2uj1MmUqewt
	R+DlQ6809XT69p1bSbXWIyAlh2mPZyflvymfB58uXF3L5yNRTbYqzDwKGo7cYRb/
	QOVm4UdQs5f3oYNqAUE19jaI/PVDIBbiuDEOH8rexiRIAIZG4Z9KyH39EOLHZrM=
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=3vp0IDdjTDWGo+UxDafefDtHGJY=; b=I3S8KeozqJg
	37WyibBJ1imX7UnYxmBGL6SHKzEyuV+sZFBrXv30BXCpQITc+8Ru82Xml6zJ19Ex
	vQjfr9LRnlPZGM3M2f+7qyrDXbEC9Hi0g6YSIgz8FuNJOqU8XnKKu4nfKG2TQdAJ
	OK8q00tFiQFx8t+pqDLDao9tD7Vjs+jM=
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 842604B007C; 
	Wed, 25 Jan 2012 19:48:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c41436e555cd65f4512e74cc91053301fb9d7afd
Message-Id: <c41436e555cd65f4512e.1327550009@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:29 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 8] x86/mm: Remove stale variable from
 debugtrace printk in p2m 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/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 39e2fc847c57 -r c41436e555cd xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1534,8 +1534,8 @@ void audit_p2m(struct domain *d,
         }
         __put_gfn(p2m, gfn);
 
-        P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
-                       mfn, gfn, mfn_x(p2mfn), lp2mfn);
+        P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx\n",
+                       mfn, gfn, mfn_x(p2mfn));
     }
     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 Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJr-0003ce-AJ; Thu, 26 Jan 2012 03:48:15 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJq-0003c0-3G
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:14 +0000
Received: from [85.158.139.83:51477] by server-11.bemta-5.messagelabs.com id
	72/E8-18383-DFCC02F4; Thu, 26 Jan 2012 03:48:13 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327549692!12405445!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTkyMzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6556 invoked from network); 26 Jan 2012 03:48:13 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.119) by server-10.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:13 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 10EE54B0084;
	Wed, 25 Jan 2012 19:48:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=dh+u+GnOUgKXH08A4olwsSSCp0dALmOyB2uj1MmUqewt
	R+DlQ6809XT69p1bSbXWIyAlh2mPZyflvymfB58uXF3L5yNRTbYqzDwKGo7cYRb/
	QOVm4UdQs5f3oYNqAUE19jaI/PVDIBbiuDEOH8rexiRIAIZG4Z9KyH39EOLHZrM=
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=3vp0IDdjTDWGo+UxDafefDtHGJY=; b=I3S8KeozqJg
	37WyibBJ1imX7UnYxmBGL6SHKzEyuV+sZFBrXv30BXCpQITc+8Ru82Xml6zJ19Ex
	vQjfr9LRnlPZGM3M2f+7qyrDXbEC9Hi0g6YSIgz8FuNJOqU8XnKKu4nfKG2TQdAJ
	OK8q00tFiQFx8t+pqDLDao9tD7Vjs+jM=
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 842604B007C; 
	Wed, 25 Jan 2012 19:48:11 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c41436e555cd65f4512e74cc91053301fb9d7afd
Message-Id: <c41436e555cd65f4512e.1327550009@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:29 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 5 of 8] x86/mm: Remove stale variable from
 debugtrace printk in p2m 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/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 39e2fc847c57 -r c41436e555cd xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1534,8 +1534,8 @@ void audit_p2m(struct domain *d,
         }
         __put_gfn(p2m, gfn);
 
-        P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx, lp2mfn=%#lx\n",
-                       mfn, gfn, mfn_x(p2mfn), lp2mfn);
+        P2M_PRINTK("OK: mfn=%#lx, gfn=%#lx, p2mfn=%#lx\n",
+                       mfn, gfn, mfn_x(p2mfn));
     }
     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 Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJv-0003eY-CS; Thu, 26 Jan 2012 03:48: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 1RqGJt-0003bu-94
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327549690!13937798!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcwMzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16865 invoked from network); 26 Jan 2012 03:48:11 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:48:11 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 3752A4B0084;
	Wed, 25 Jan 2012 19:48: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=QCgkEf9YHPkuaW/iSSJUBU2ackzUEtFDvAwuQf/fgaTj
	Iz/3vS+xARl91xe7ZUzsaAouw3CIwGvCwApc4aLsQg7tWT3zb4iiEF/pJOPUNCbV
	LSRgmV4JSs+nNGTSjawEzgYk5ceajJRFX53tpNR/2rEhhLapABJN79De6LKrfRo=
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=iqJ3LQMTTxKIkJUuON/+LCD+DjM=; b=cpeflNtFpRF
	LOF5XYPScmAH6MA24lMCPSxed8UYgf6dlYAop+cAilvXNAa41/kgGM/fOKK1yCOm
	pP48rYdbDVqyWNJgK7bXLYlzjHeTJNSML5bVrKXwcqtbR0JMCoq577Q0G7PM7WTw
	QcVjgHYlAyoMEJ0/E9fQxlqjmEc54Sbc=
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 A5B584B007C; 
	Wed, 25 Jan 2012 19:48:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c4b96d2cba065cfa2eef0d61fa5996908ff110fd
Message-Id: <c4b96d2cba065cfa2eef.1327550007@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 8] x86/mm: Allow foreign read-only mappings
 of 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

 xen/arch/x86/mm.c |  8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)


Because shared pages are owned by dom_cow, the ownership test
while foreign mapping fails.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2e7c77585adb -r c4b96d2cba06 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -878,7 +878,8 @@ get_page_from_l1e(
         return 1;
     }
 
-    if ( unlikely(real_pg_owner != pg_owner) )
+    if ( unlikely( (real_pg_owner != pg_owner) &&
+                   (real_pg_owner != dom_cow) ) )
     {
         /*
          * Let privileged domains transfer the right to map their target
@@ -892,6 +893,11 @@ get_page_from_l1e(
         pg_owner = real_pg_owner;
     }
 
+    /* Extra paranoid check for shared memory. Writable mappings 
+     * disallowed (unshare first!) */
+    if ( (l1f & _PAGE_RW) && (real_pg_owner == dom_cow) )
+        goto could_not_pin;
+
     /* Foreign mappings into guests in shadow external mode don't
      * contribute to writeable mapping refcounts.  (This allows the
      * qemu-dm helper process in dom0 to map the domain's memory without

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJv-0003eY-CS; Thu, 26 Jan 2012 03:48: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 1RqGJt-0003bu-94
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327549690!13937798!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcwMzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16865 invoked from network); 26 Jan 2012 03:48:11 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.202) by server-2.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:48:11 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 3752A4B0084;
	Wed, 25 Jan 2012 19:48: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=QCgkEf9YHPkuaW/iSSJUBU2ackzUEtFDvAwuQf/fgaTj
	Iz/3vS+xARl91xe7ZUzsaAouw3CIwGvCwApc4aLsQg7tWT3zb4iiEF/pJOPUNCbV
	LSRgmV4JSs+nNGTSjawEzgYk5ceajJRFX53tpNR/2rEhhLapABJN79De6LKrfRo=
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=iqJ3LQMTTxKIkJUuON/+LCD+DjM=; b=cpeflNtFpRF
	LOF5XYPScmAH6MA24lMCPSxed8UYgf6dlYAop+cAilvXNAa41/kgGM/fOKK1yCOm
	pP48rYdbDVqyWNJgK7bXLYlzjHeTJNSML5bVrKXwcqtbR0JMCoq577Q0G7PM7WTw
	QcVjgHYlAyoMEJ0/E9fQxlqjmEc54Sbc=
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 A5B584B007C; 
	Wed, 25 Jan 2012 19:48:09 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: c4b96d2cba065cfa2eef0d61fa5996908ff110fd
Message-Id: <c4b96d2cba065cfa2eef.1327550007@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:27 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 3 of 8] x86/mm: Allow foreign read-only mappings
 of 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

 xen/arch/x86/mm.c |  8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)


Because shared pages are owned by dom_cow, the ownership test
while foreign mapping fails.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2e7c77585adb -r c4b96d2cba06 xen/arch/x86/mm.c
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -878,7 +878,8 @@ get_page_from_l1e(
         return 1;
     }
 
-    if ( unlikely(real_pg_owner != pg_owner) )
+    if ( unlikely( (real_pg_owner != pg_owner) &&
+                   (real_pg_owner != dom_cow) ) )
     {
         /*
          * Let privileged domains transfer the right to map their target
@@ -892,6 +893,11 @@ get_page_from_l1e(
         pg_owner = real_pg_owner;
     }
 
+    /* Extra paranoid check for shared memory. Writable mappings 
+     * disallowed (unshare first!) */
+    if ( (l1f & _PAGE_RW) && (real_pg_owner == dom_cow) )
+        goto could_not_pin;
+
     /* Foreign mappings into guests in shadow external mode don't
      * contribute to writeable mapping refcounts.  (This allows the
      * qemu-dm helper process in dom0 to map the domain's memory without

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJs-0003dF-O9; Thu, 26 Jan 2012 03:48:16 +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 1RqGJr-0003bf-CW
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327549688!11990881!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzMzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29036 invoked from network); 26 Jan 2012 03:48:09 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-13.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:48:09 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id E732D4B0084;
	Wed, 25 Jan 2012 19:48:07 -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=qXNki4/pbU9tzG7nDxuHZS
	mOH6nK8hUhpwiTDaM1NA5+SEV2AdV9aDd9D44PE7P7IU0cmDBh+GH/zuTDxw0i6I
	y2d/WJtjBrWyA9QbXAjIcXIXA8UeQS+pYWWoTHboYPaljsoDWYlsnb2zk3IoEjTL
	NbG1Y3NOzdApriScZeaHQ=
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=7uzKUa+rlfih
	2J7qzx+bqGYqgHs=; b=nM4Z09U8K3Vg9iczIee6Y5arFpiTkfD3D78Vr6sgGLQ0
	5Bq79uItEx4UQmqorD/wQXfvjTQ+thY60sjDdh6gMVbKEmfdu3G2AoP16DcMePb7
	DMLxrzasaracpTxchxFQSBJERssDO0x26AI1MfaO8RG2/VceYAXDh+vJMQBbdXY=
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 5B7E04B007C; 
	Wed, 25 Jan 2012 19:48:07 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 8] x86/mm 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 patch series aggregates a number of fixes:
- Fix the paging load operation to correct the m2p entry, and
  promote the p2m entry to the final guest-accessible type
- Fix locking around p2m_teardown
- Fix read-only mapping of shared pages
- Output to the console the per-domain count of shared pages
- Eliminate a stale var from a p2m audit debugtrace printk
- Correct accounting of paged out pages when a paging-out is
  interrupted by a guest access
- Simplify (and in some cases eliminate) use of p2m get_gfn*_unlocked
- Allow for recursive locking in the mm-locks.h deadlock detection
  scheme

Patches 1, 4 and 6 involve paging, cc'ed Olaf Hering.

Patches 2, 7 and 8 lay more groundwork in preparation of fully
synchronized p2m access.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/p2m.c         |  18 ++++++++----------
 xen/arch/x86/mm/p2m.c         |   4 ++--
 xen/arch/x86/mm.c             |   8 +++++++-
 xen/common/keyhandler.c       |   6 ++++--
 xen/arch/x86/mm/p2m.c         |   4 ++--
 xen/arch/x86/mm/p2m.c         |   3 ++-
 xen/arch/x86/hvm/emulate.c    |  35 ++++++++++++++++++++++++++++-------
 xen/arch/x86/hvm/hvm.c        |   5 ++++-
 xen/arch/x86/hvm/stdvga.c     |  12 ++++++++++--
 xen/arch/x86/hvm/vmx/vmx.c    |   2 +-
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 xen/arch/x86/mm/mm-locks.h    |   3 ++-
 12 files changed, 71 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 Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJp-0003c6-3g; Thu, 26 Jan 2012 03:48:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJn-0003bl-Hx
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:11 +0000
Received: from [85.158.138.51:53124] by server-5.bemta-3.messagelabs.com id
	26/38-02363-AFCC02F4; Thu, 26 Jan 2012 03:48:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327549689!10491336!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE5OTgw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE5OTgw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14201 invoked from network); 26 Jan 2012 03:48:09 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-14.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:48:09 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id AD8694B0089;
	Wed, 25 Jan 2012 19:48:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=IxSDJuiQkUioAWH2e3bRkzpvgJ70Uc1dp0uUQp2ZoTcc
	UNpGwZ9/tRMX7kuZFoNlBR3frD4qgRRneAolaYjWO6R8MsHgHadmT/tRJie02clC
	E3G0SCwyL0XlqyakQNmTd8oAoF7kkGaIO4uyQvCFmThE40KhDqtOcSVkNpBbpqo=
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=wKrcQ5s+PfZkORoA2kGJTeWYGsI=; b=M+JC6Q9036M
	dTVqzbMcl0Uf6H2HzGvSLAZG5FRYRhT5WftgpIxJygoJxWxSroZEKfi511QTzF98
	Rf7clb5vtK2vZOMuYN1wyWfUhGoCa1XrKIyfu73+x1ruHcwEzWqZeUM6ioUebO1d
	kyqSEQSvwexqSysLNCsSvhEcssMzqJPo=
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 215D24B007C; 
	Wed, 25 Jan 2012 19:48:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 143e4982c9bf0da5d8fed75de3ce1423a40ed93c
Message-Id: <143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix 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

 xen/arch/x86/mm/p2m.c |  18 ++++++++----------
 1 files changed, 8 insertions(+), 10 deletions(-)


When restoring a p2m entry in the paging_load path, we were not updating the
m2p entry correctly.

Also take advantage of this to act on an old suggestion: once done with the
load, promote the p2m entry to the final guest accessible type. This simplifies
logic.

Tested to work with xenpaging.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f09f62ae92b7 -r 143e4982c9bf xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -975,7 +975,7 @@ void p2m_mem_paging_populate(struct doma
 int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 {
     struct page_info *page;
-    p2m_type_t p2mt, target_p2mt;
+    p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1033,15 +1033,13 @@ int p2m_mem_paging_prep(struct domain *d
         }
     }
 
-    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
-        /* If we kicked the pager with a populate event, the pager will send
-         * a resume event back */
-        p2m_ram_paging_in :
-        /* If this was called asynchronously by the pager, then we can 
-         * transition directly to the final guest-accessible type */
-        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
-    /* Fix p2m mapping */
-    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
+    /* Make the page already guest-accessible. If the pager still has a
+     * pending resume operation, it will be idempotent p2m entry-wise,
+     * but will unpause the vcpu */
+    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, 
+                    paging_mode_log_dirty(d) ? p2m_ram_logdirty : 
+                    p2m_ram_rw, a);
+    set_gpfn_from_mfn(mfn_x(mfn), gfn);
 
     atomic_dec(&d->paged_pages);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJs-0003dF-O9; Thu, 26 Jan 2012 03:48:16 +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 1RqGJr-0003bf-CW
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327549688!11990881!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzMzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29036 invoked from network); 26 Jan 2012 03:48:09 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-13.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 03:48:09 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id E732D4B0084;
	Wed, 25 Jan 2012 19:48:07 -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=qXNki4/pbU9tzG7nDxuHZS
	mOH6nK8hUhpwiTDaM1NA5+SEV2AdV9aDd9D44PE7P7IU0cmDBh+GH/zuTDxw0i6I
	y2d/WJtjBrWyA9QbXAjIcXIXA8UeQS+pYWWoTHboYPaljsoDWYlsnb2zk3IoEjTL
	NbG1Y3NOzdApriScZeaHQ=
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=7uzKUa+rlfih
	2J7qzx+bqGYqgHs=; b=nM4Z09U8K3Vg9iczIee6Y5arFpiTkfD3D78Vr6sgGLQ0
	5Bq79uItEx4UQmqorD/wQXfvjTQ+thY60sjDdh6gMVbKEmfdu3G2AoP16DcMePb7
	DMLxrzasaracpTxchxFQSBJERssDO0x26AI1MfaO8RG2/VceYAXDh+vJMQBbdXY=
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 5B7E04B007C; 
	Wed, 25 Jan 2012 19:48:07 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:24 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 8] x86/mm 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 patch series aggregates a number of fixes:
- Fix the paging load operation to correct the m2p entry, and
  promote the p2m entry to the final guest-accessible type
- Fix locking around p2m_teardown
- Fix read-only mapping of shared pages
- Output to the console the per-domain count of shared pages
- Eliminate a stale var from a p2m audit debugtrace printk
- Correct accounting of paged out pages when a paging-out is
  interrupted by a guest access
- Simplify (and in some cases eliminate) use of p2m get_gfn*_unlocked
- Allow for recursive locking in the mm-locks.h deadlock detection
  scheme

Patches 1, 4 and 6 involve paging, cc'ed Olaf Hering.

Patches 2, 7 and 8 lay more groundwork in preparation of fully
synchronized p2m access.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

 xen/arch/x86/mm/p2m.c         |  18 ++++++++----------
 xen/arch/x86/mm/p2m.c         |   4 ++--
 xen/arch/x86/mm.c             |   8 +++++++-
 xen/common/keyhandler.c       |   6 ++++--
 xen/arch/x86/mm/p2m.c         |   4 ++--
 xen/arch/x86/mm/p2m.c         |   3 ++-
 xen/arch/x86/hvm/emulate.c    |  35 ++++++++++++++++++++++++++++-------
 xen/arch/x86/hvm/hvm.c        |   5 ++++-
 xen/arch/x86/hvm/stdvga.c     |  12 ++++++++++--
 xen/arch/x86/hvm/vmx/vmx.c    |   2 +-
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 xen/arch/x86/mm/mm-locks.h    |   3 ++-
 12 files changed, 71 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 Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJp-0003c6-3g; Thu, 26 Jan 2012 03:48:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJn-0003bl-Hx
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:11 +0000
Received: from [85.158.138.51:53124] by server-5.bemta-3.messagelabs.com id
	26/38-02363-AFCC02F4; Thu, 26 Jan 2012 03:48:10 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327549689!10491336!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE5OTgw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDE5OTgw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14201 invoked from network); 26 Jan 2012 03:48:09 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.81) by server-14.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:48:09 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id AD8694B0089;
	Wed, 25 Jan 2012 19:48:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=IxSDJuiQkUioAWH2e3bRkzpvgJ70Uc1dp0uUQp2ZoTcc
	UNpGwZ9/tRMX7kuZFoNlBR3frD4qgRRneAolaYjWO6R8MsHgHadmT/tRJie02clC
	E3G0SCwyL0XlqyakQNmTd8oAoF7kkGaIO4uyQvCFmThE40KhDqtOcSVkNpBbpqo=
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=wKrcQ5s+PfZkORoA2kGJTeWYGsI=; b=M+JC6Q9036M
	dTVqzbMcl0Uf6H2HzGvSLAZG5FRYRhT5WftgpIxJygoJxWxSroZEKfi511QTzF98
	Rf7clb5vtK2vZOMuYN1wyWfUhGoCa1XrKIyfu73+x1ruHcwEzWqZeUM6ioUebO1d
	kyqSEQSvwexqSysLNCsSvhEcssMzqJPo=
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 215D24B007C; 
	Wed, 25 Jan 2012 19:48:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 143e4982c9bf0da5d8fed75de3ce1423a40ed93c
Message-Id: <143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:25 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix 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

 xen/arch/x86/mm/p2m.c |  18 ++++++++----------
 1 files changed, 8 insertions(+), 10 deletions(-)


When restoring a p2m entry in the paging_load path, we were not updating the
m2p entry correctly.

Also take advantage of this to act on an old suggestion: once done with the
load, promote the p2m entry to the final guest accessible type. This simplifies
logic.

Tested to work with xenpaging.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r f09f62ae92b7 -r 143e4982c9bf xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -975,7 +975,7 @@ void p2m_mem_paging_populate(struct doma
 int p2m_mem_paging_prep(struct domain *d, unsigned long gfn, uint64_t buffer)
 {
     struct page_info *page;
-    p2m_type_t p2mt, target_p2mt;
+    p2m_type_t p2mt;
     p2m_access_t a;
     mfn_t mfn;
     struct p2m_domain *p2m = p2m_get_hostp2m(d);
@@ -1033,15 +1033,13 @@ int p2m_mem_paging_prep(struct domain *d
         }
     }
 
-    target_p2mt = (p2mt == p2m_ram_paging_in_start) ?
-        /* If we kicked the pager with a populate event, the pager will send
-         * a resume event back */
-        p2m_ram_paging_in :
-        /* If this was called asynchronously by the pager, then we can 
-         * transition directly to the final guest-accessible type */
-        (paging_mode_log_dirty(d) ? p2m_ram_logdirty : p2m_ram_rw);
-    /* Fix p2m mapping */
-    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, target_p2mt, a);
+    /* Make the page already guest-accessible. If the pager still has a
+     * pending resume operation, it will be idempotent p2m entry-wise,
+     * but will unpause the vcpu */
+    set_p2m_entry(p2m, gfn, mfn, PAGE_ORDER_4K, 
+                    paging_mode_log_dirty(d) ? p2m_ram_logdirty : 
+                    p2m_ram_rw, a);
+    set_gpfn_from_mfn(mfn_x(mfn), gfn);
 
     atomic_dec(&d->paged_pages);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJu-0003e9-K6; Thu, 26 Jan 2012 03:48:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJs-0003dA-Vm
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:17 +0000
Received: from [85.158.138.51:53244] by server-4.bemta-3.messagelabs.com id
	89/5B-32238-00DC02F4; Thu, 26 Jan 2012 03:48:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327549694!5544433!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzMzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8636 invoked from network); 26 Jan 2012 03:48:15 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-13.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:48:15 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 418274B0089;
	Wed, 25 Jan 2012 19:48:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=oyu3kBplxB5pXRz0yl/wxiA0t+HWSOnnuFJXsuK/MRVU
	anuNPUQVGF/Bn4lM+y0pW71/BFcfjmskoiJslb/Rc62eq7PHF0n7ZrJjfSmFGQUR
	6lqJRvsmRnbqpXJizNtAuP2aOtyo+Edxxxx4cqClzk3t8dmCCCegFpOSIxR/s8s=
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=642Yd6JlrRvdoiE1zA4Ju37fc7I=; b=jSzkY5+zkQX
	iJ7T+QNiKQ01g8p3MZIato3M8SDDmGFTFei6zD5cI4iWXxfgZOwSCcD2H9ocH/Eh
	uOB2sannoHwCDWW3HkQ8P9iN1+zliTa5rZ8a+5DzzxSa2itiqH5eOO/0YRKVywD3
	4/tbKMaI+UcJcWzI3u3DKdHVz5KK53cM=
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 AF7384B007C; 
	Wed, 25 Jan 2012 19:48:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 409f0f368ae3c87f82d606b3d5bdc07f09180f84
Message-Id: <409f0f368ae3c87f82d6.1327550012@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:32 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 8] x86/mm: Avoid spurious deadlock panic
	trigger
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mm-locks.h |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


In the mm layer, if we take lock A, then lock B, and the recursively lock A,
the deadlock detector panics. This is not a deadlock risk because we
already 'own' the outer lock (A), so we will not contend for that resource.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2dc0ef05662e -r 409f0f368ae3 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -61,7 +61,8 @@ do {                                \
 
 static inline void _mm_lock(mm_lock_t *l, const char *func, int level, int rec)
 {
-    __check_lock_level(level);
+    if ( !((mm_locked_by_me(l)) && rec) ) 
+        __check_lock_level(level);
     spin_lock_recursive(&l->lock);
     if ( l->lock.recurse_cnt == 1 )
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJu-0003ds-5n; Thu, 26 Jan 2012 03:48:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJr-0003ci-TA
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:16 +0000
Received: from [85.158.139.83:40557] by server-6.bemta-5.messagelabs.com id
	5F/37-21889-FFCC02F4; Thu, 26 Jan 2012 03:48:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327549694!12405447!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTkzNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6606 invoked from network); 26 Jan 2012 03:48:14 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.207) by server-10.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:14 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id C22D84B008F;
	Wed, 25 Jan 2012 19:48:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=PZB2RtWNnaA4sALPl8lOwevJXs+jBNs9RGjnzhjgQzlL
	/4Af2c3aWsB6hcoU2Y8ocGqGSW8xJXI72+c6JjhTbGrHKaTpurvf//LMMhFFI3ln
	MqLOGl26QB88eZk1HZuduvSNF7FZsnU6HE7+l+92MvzQBG+8DiKyJ6RS55cxU04=
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=GCJlGzHJntKNLVshbzkay8tIC08=; b=uIUiuKRTh9/
	ixeWDjR7gh5iHntSyqur/F1MtCpaOOgzPvIHqQVOWvZfb45lgelK7icUS9/kWUAx
	W5Oc5MKlKVzUHhSVj0cGMHqQAt/8amSpKUro4iu3WRedyn85M33WmPBfGwD4ON5D
	bJ5AqdFaDDhFLPAOHU/OWdvNSINB4hcM=
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 3E3B44B007C; 
	Wed, 25 Jan 2012 19:48:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d4336e35f0bcb4fcb060f1c17129421ecccb9997
Message-Id: <d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:30 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for 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

 xen/arch/x86/mm/p2m.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


If we hit the page after nominate but before paging it out, don't decrement the
domain count of paged out pages.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c41436e555cd -r d4336e35f0bc xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1041,7 +1041,8 @@ int p2m_mem_paging_prep(struct domain *d
                     p2m_ram_rw, a);
     set_gpfn_from_mfn(mfn_x(mfn), gfn);
 
-    atomic_dec(&d->paged_pages);
+    if ( !page_extant )
+        atomic_dec(&d->paged_pages);
 
     ret = 0;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJu-0003ds-5n; Thu, 26 Jan 2012 03:48:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJr-0003ci-TA
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:16 +0000
Received: from [85.158.139.83:40557] by server-6.bemta-5.messagelabs.com id
	5F/37-21889-FFCC02F4; Thu, 26 Jan 2012 03:48:15 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327549694!12405447!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTkzNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6606 invoked from network); 26 Jan 2012 03:48:14 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.207) by server-10.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:14 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id C22D84B008F;
	Wed, 25 Jan 2012 19:48:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=PZB2RtWNnaA4sALPl8lOwevJXs+jBNs9RGjnzhjgQzlL
	/4Af2c3aWsB6hcoU2Y8ocGqGSW8xJXI72+c6JjhTbGrHKaTpurvf//LMMhFFI3ln
	MqLOGl26QB88eZk1HZuduvSNF7FZsnU6HE7+l+92MvzQBG+8DiKyJ6RS55cxU04=
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=GCJlGzHJntKNLVshbzkay8tIC08=; b=uIUiuKRTh9/
	ixeWDjR7gh5iHntSyqur/F1MtCpaOOgzPvIHqQVOWvZfb45lgelK7icUS9/kWUAx
	W5Oc5MKlKVzUHhSVj0cGMHqQAt/8amSpKUro4iu3WRedyn85M33WmPBfGwD4ON5D
	bJ5AqdFaDDhFLPAOHU/OWdvNSINB4hcM=
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 3E3B44B007C; 
	Wed, 25 Jan 2012 19:48:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d4336e35f0bcb4fcb060f1c17129421ecccb9997
Message-Id: <d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:30 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for 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

 xen/arch/x86/mm/p2m.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


If we hit the page after nominate but before paging it out, don't decrement the
domain count of paged out pages.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r c41436e555cd -r d4336e35f0bc xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1041,7 +1041,8 @@ int p2m_mem_paging_prep(struct domain *d
                     p2m_ram_rw, a);
     set_gpfn_from_mfn(mfn_x(mfn), gfn);
 
-    atomic_dec(&d->paged_pages);
+    if ( !page_extant )
+        atomic_dec(&d->paged_pages);
 
     ret = 0;
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJu-0003e9-K6; Thu, 26 Jan 2012 03:48:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJs-0003dA-Vm
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:17 +0000
Received: from [85.158.138.51:53244] by server-4.bemta-3.messagelabs.com id
	89/5B-32238-00DC02F4; Thu, 26 Jan 2012 03:48:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327549694!5544433!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzMzMg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8636 invoked from network); 26 Jan 2012 03:48:15 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.66) by server-13.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 03:48:15 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 418274B0089;
	Wed, 25 Jan 2012 19:48:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=oyu3kBplxB5pXRz0yl/wxiA0t+HWSOnnuFJXsuK/MRVU
	anuNPUQVGF/Bn4lM+y0pW71/BFcfjmskoiJslb/Rc62eq7PHF0n7ZrJjfSmFGQUR
	6lqJRvsmRnbqpXJizNtAuP2aOtyo+Edxxxx4cqClzk3t8dmCCCegFpOSIxR/s8s=
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=642Yd6JlrRvdoiE1zA4Ju37fc7I=; b=jSzkY5+zkQX
	iJ7T+QNiKQ01g8p3MZIato3M8SDDmGFTFei6zD5cI4iWXxfgZOwSCcD2H9ocH/Eh
	uOB2sannoHwCDWW3HkQ8P9iN1+zliTa5rZ8a+5DzzxSa2itiqH5eOO/0YRKVywD3
	4/tbKMaI+UcJcWzI3u3DKdHVz5KK53cM=
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 AF7384B007C; 
	Wed, 25 Jan 2012 19:48:13 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 409f0f368ae3c87f82d606b3d5bdc07f09180f84
Message-Id: <409f0f368ae3c87f82d6.1327550012@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:32 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 8 of 8] x86/mm: Avoid spurious deadlock panic
	trigger
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/mm-locks.h |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


In the mm layer, if we take lock A, then lock B, and the recursively lock A,
the deadlock detector panics. This is not a deadlock risk because we
already 'own' the outer lock (A), so we will not contend for that resource.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2dc0ef05662e -r 409f0f368ae3 xen/arch/x86/mm/mm-locks.h
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -61,7 +61,8 @@ do {                                \
 
 static inline void _mm_lock(mm_lock_t *l, const char *func, int level, int rec)
 {
-    __check_lock_level(level);
+    if ( !((mm_locked_by_me(l)) && rec) ) 
+        __check_lock_level(level);
     spin_lock_recursive(&l->lock);
     if ( l->lock.recurse_cnt == 1 )
     {

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJu-0003eK-Vz; Thu, 26 Jan 2012 03:48:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJs-0003dB-Up
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:17 +0000
Received: from [85.158.139.83:40563] by server-1.bemta-5.messagelabs.com id
	50/97-18433-00DC02F4; Thu, 26 Jan 2012 03:48:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327549693!4986802!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTkzNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32697 invoked from network); 26 Jan 2012 03:48:14 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:14 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 7F2AF4B0084;
	Wed, 25 Jan 2012 19:48:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=hU5YIhhy84sV2pxuNhKRPf8ZPZNZJx7UT3i887PV4C+/
	LsPMraixT/xsQG/PtzijsotiNk0avXilJAV/mI0dWUmDOWhkZ5PwZo2TbtUUwqbD
	pJBrEe2GLWLAPrWhf1nsV68ZOSwk8XRUHx3v7+XwPvq6FIeW1OOGglPTOtVFj9A=
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=hUdwADMv+xCPWPemhCn+rpxL3mA=; b=j8/SzieHejF
	qTBuQsq/5U/IG0MAFDtD+G1ipnBStvBQ3ad/fOJDslBWXlx3LfP2Nu6AYTm3Scda
	XPD6B4fnu7fbsFtT0lWFnSO0x6GNVmsSZ5VLeR1iLsuK7MZuRW0Jr/1v1boKfCYO
	eMDtl2otRNWs21YLos+QcC6dNa4FuwSU=
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 E58874B007C; 
	Wed, 25 Jan 2012 19:48:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2dc0ef05662e5a327350f18542fb854fa22bf988
Message-Id: <2dc0ef05662e5a327350.1327550011@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:31 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 8] x86/mm: clean use of p2m unlocked queries
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c    |  35 ++++++++++++++++++++++++++++-------
 xen/arch/x86/hvm/hvm.c        |   5 ++++-
 xen/arch/x86/hvm/stdvga.c     |  12 ++++++++++--
 xen/arch/x86/hvm/vmx/vmx.c    |   2 +-
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 5 files changed, 44 insertions(+), 12 deletions(-)


Limit such queries only to p2m_query types. This is more compatible
with the name and intended semantics: perform only a lookup, and explicitly
in an unlocked way.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -660,7 +660,7 @@ static int hvmemul_rep_movs(
 {
     struct hvm_emulate_ctxt *hvmemul_ctxt =
         container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-    unsigned long saddr, daddr, bytes;
+    unsigned long saddr, daddr, bytes, sgfn, dgfn;
     paddr_t sgpa, dgpa;
     uint32_t pfec = PFEC_page_present;
     p2m_type_t p2mt;
@@ -693,17 +693,28 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    /* Unlocked works here because we get_gfn for real in whatever
-     * we call later. */
-    (void)get_gfn_unlocked(current->domain, sgpa >> PAGE_SHIFT, &p2mt);
+    /* XXX In a fine-grained p2m locking scenario, we need to sort this
+     * get_gfn's, or else we might deadlock */
+    sgfn = sgpa >> PAGE_SHIFT;
+    (void)get_gfn(current->domain, sgfn, &p2mt);
     if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
-        return hvmemul_do_mmio(
+    {
+        rc = hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
+        put_gfn(current->domain, sgfn);
+        return rc;
+    }
 
-    (void)get_gfn_unlocked(current->domain, dgpa >> PAGE_SHIFT, &p2mt);
+    dgfn = dgpa >> PAGE_SHIFT;
+    (void)get_gfn(current->domain, dgfn, &p2mt);
     if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
-        return hvmemul_do_mmio(
+    {
+        rc = hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
+        put_gfn(current->domain, sgfn);
+        put_gfn(current->domain, dgfn);
+        return rc;
+    }
 
     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
     bytes = *reps * bytes_per_rep;
@@ -718,7 +729,11 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
+    {
+        put_gfn(current->domain, sgfn);
+        put_gfn(current->domain, dgfn);
         return X86EMUL_UNHANDLEABLE;
+    }
 
     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -727,7 +742,11 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
+    {
+        put_gfn(current->domain, sgfn);
+        put_gfn(current->domain, dgfn);
         return X86EMUL_UNHANDLEABLE;
+    }
 
     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -738,6 +757,8 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
+    put_gfn(current->domain, sgfn);
+    put_gfn(current->domain, dgfn);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3975,7 +3975,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
         rc = -EINVAL;
         if ( is_hvm_domain(d) )
         {
-            get_gfn_unshare_unlocked(d, a.pfn, &t);
+            /* Use get_gfn query as we are interested in the current 
+             * type, not in allocating or unsharing. That'll happen 
+             * on access. */
+            get_gfn_query_unlocked(d, a.pfn, &t);
             if ( p2m_is_mmio(t) )
                 a.mem_type =  HVMMEM_mmio_dm;
             else if ( p2m_is_readonly(t) )
diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/hvm/stdvga.c
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -482,15 +482,19 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_to_guest_phys(data, &tmp, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn_unlocked(d, data >> PAGE_SHIFT, &p2mt);
+                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
                     /*
                      * The only case we handle is vga_mem <-> vga_mem.
                      * Anything else disables caching and leaves it to qemu-dm.
                      */
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+                    {
+                        put_gfn(d, data >> PAGE_SHIFT);
                         return 0;
+                    }
                     stdvga_mem_write(data, tmp, p->size);
+                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 data += sign * p->size;
                 addr += sign * p->size;
@@ -504,11 +508,15 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_from_guest_phys(&tmp, data, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn_unlocked(d, data >> PAGE_SHIFT, &p2mt);
+                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+                    {
+                        put_gfn(d, data >> PAGE_SHIFT);
                         return 0;
+                    }
                     tmp = stdvga_mem_read(data, p->size);
+                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 stdvga_mem_write(addr, tmp, p->size);
                 data += sign * p->size;
diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2112,7 +2112,7 @@ static void ept_handle_violation(unsigne
         return;
 
     /* Everything else is an error. */
-    mfn = get_gfn_guest_unlocked(d, gfn, &p2mt);
+    mfn = get_gfn_query_unlocked(d, gfn, &p2mt);
     gdprintk(XENLOG_ERR, "EPT violation %#lx (%c%c%c/%c%c%c), "
              "gpa %#"PRIpaddr", mfn %#lx, type %i.\n", 
              qualification, 
diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -421,7 +421,7 @@ int mem_sharing_debug_gfn(struct domain 
     p2m_type_t p2mt;
     mfn_t mfn;
 
-    mfn = get_gfn_unlocked(d, gfn, &p2mt);
+    mfn = get_gfn_query_unlocked(d, gfn, &p2mt);
 
     gdprintk(XENLOG_DEBUG, "Debug for domain=%d, gfn=%lx, ", 
                d->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 Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJu-0003eK-Vz; Thu, 26 Jan 2012 03:48:18 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJs-0003dB-Up
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:17 +0000
Received: from [85.158.139.83:40563] by server-1.bemta-5.messagelabs.com id
	50/97-18433-00DC02F4; Thu, 26 Jan 2012 03:48:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327549693!4986802!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTkzNDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32697 invoked from network); 26 Jan 2012 03:48:14 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.207) by server-8.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:14 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 7F2AF4B0084;
	Wed, 25 Jan 2012 19:48:13 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=hU5YIhhy84sV2pxuNhKRPf8ZPZNZJx7UT3i887PV4C+/
	LsPMraixT/xsQG/PtzijsotiNk0avXilJAV/mI0dWUmDOWhkZ5PwZo2TbtUUwqbD
	pJBrEe2GLWLAPrWhf1nsV68ZOSwk8XRUHx3v7+XwPvq6FIeW1OOGglPTOtVFj9A=
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=hUdwADMv+xCPWPemhCn+rpxL3mA=; b=j8/SzieHejF
	qTBuQsq/5U/IG0MAFDtD+G1ipnBStvBQ3ad/fOJDslBWXlx3LfP2Nu6AYTm3Scda
	XPD6B4fnu7fbsFtT0lWFnSO0x6GNVmsSZ5VLeR1iLsuK7MZuRW0Jr/1v1boKfCYO
	eMDtl2otRNWs21YLos+QcC6dNa4FuwSU=
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 E58874B007C; 
	Wed, 25 Jan 2012 19:48:12 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2dc0ef05662e5a327350f18542fb854fa22bf988
Message-Id: <2dc0ef05662e5a327350.1327550011@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:31 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 7 of 8] x86/mm: clean use of p2m unlocked queries
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/hvm/emulate.c    |  35 ++++++++++++++++++++++++++++-------
 xen/arch/x86/hvm/hvm.c        |   5 ++++-
 xen/arch/x86/hvm/stdvga.c     |  12 ++++++++++--
 xen/arch/x86/hvm/vmx/vmx.c    |   2 +-
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 5 files changed, 44 insertions(+), 12 deletions(-)


Limit such queries only to p2m_query types. This is more compatible
with the name and intended semantics: perform only a lookup, and explicitly
in an unlocked way.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/hvm/emulate.c
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -660,7 +660,7 @@ static int hvmemul_rep_movs(
 {
     struct hvm_emulate_ctxt *hvmemul_ctxt =
         container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
-    unsigned long saddr, daddr, bytes;
+    unsigned long saddr, daddr, bytes, sgfn, dgfn;
     paddr_t sgpa, dgpa;
     uint32_t pfec = PFEC_page_present;
     p2m_type_t p2mt;
@@ -693,17 +693,28 @@ static int hvmemul_rep_movs(
     if ( rc != X86EMUL_OKAY )
         return rc;
 
-    /* Unlocked works here because we get_gfn for real in whatever
-     * we call later. */
-    (void)get_gfn_unlocked(current->domain, sgpa >> PAGE_SHIFT, &p2mt);
+    /* XXX In a fine-grained p2m locking scenario, we need to sort this
+     * get_gfn's, or else we might deadlock */
+    sgfn = sgpa >> PAGE_SHIFT;
+    (void)get_gfn(current->domain, sgfn, &p2mt);
     if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
-        return hvmemul_do_mmio(
+    {
+        rc = hvmemul_do_mmio(
             sgpa, reps, bytes_per_rep, dgpa, IOREQ_READ, df, NULL);
+        put_gfn(current->domain, sgfn);
+        return rc;
+    }
 
-    (void)get_gfn_unlocked(current->domain, dgpa >> PAGE_SHIFT, &p2mt);
+    dgfn = dgpa >> PAGE_SHIFT;
+    (void)get_gfn(current->domain, dgfn, &p2mt);
     if ( !p2m_is_ram(p2mt) && !p2m_is_grant(p2mt) )
-        return hvmemul_do_mmio(
+    {
+        rc = hvmemul_do_mmio(
             dgpa, reps, bytes_per_rep, sgpa, IOREQ_WRITE, df, NULL);
+        put_gfn(current->domain, sgfn);
+        put_gfn(current->domain, dgfn);
+        return rc;
+    }
 
     /* RAM-to-RAM copy: emulate as equivalent of memmove(dgpa, sgpa, bytes). */
     bytes = *reps * bytes_per_rep;
@@ -718,7 +729,11 @@ static int hvmemul_rep_movs(
      * can be emulated by a source-to-buffer-to-destination block copy.
      */
     if ( ((dgpa + bytes_per_rep) > sgpa) && (dgpa < (sgpa + bytes)) )
+    {
+        put_gfn(current->domain, sgfn);
+        put_gfn(current->domain, dgfn);
         return X86EMUL_UNHANDLEABLE;
+    }
 
     /* Adjust destination address for reverse copy. */
     if ( df )
@@ -727,7 +742,11 @@ static int hvmemul_rep_movs(
     /* Allocate temporary buffer. Fall back to slow emulation if this fails. */
     buf = xmalloc_bytes(bytes);
     if ( buf == NULL )
+    {
+        put_gfn(current->domain, sgfn);
+        put_gfn(current->domain, dgfn);
         return X86EMUL_UNHANDLEABLE;
+    }
 
     /*
      * We do a modicum of checking here, just for paranoia's sake and to
@@ -738,6 +757,8 @@ static int hvmemul_rep_movs(
         rc = hvm_copy_to_guest_phys(dgpa, buf, bytes);
 
     xfree(buf);
+    put_gfn(current->domain, sgfn);
+    put_gfn(current->domain, dgfn);
 
     if ( rc == HVMCOPY_gfn_paged_out )
         return X86EMUL_RETRY;
diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3975,7 +3975,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
         rc = -EINVAL;
         if ( is_hvm_domain(d) )
         {
-            get_gfn_unshare_unlocked(d, a.pfn, &t);
+            /* Use get_gfn query as we are interested in the current 
+             * type, not in allocating or unsharing. That'll happen 
+             * on access. */
+            get_gfn_query_unlocked(d, a.pfn, &t);
             if ( p2m_is_mmio(t) )
                 a.mem_type =  HVMMEM_mmio_dm;
             else if ( p2m_is_readonly(t) )
diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/hvm/stdvga.c
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -482,15 +482,19 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_to_guest_phys(data, &tmp, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn_unlocked(d, data >> PAGE_SHIFT, &p2mt);
+                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
                     /*
                      * The only case we handle is vga_mem <-> vga_mem.
                      * Anything else disables caching and leaves it to qemu-dm.
                      */
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+                    {
+                        put_gfn(d, data >> PAGE_SHIFT);
                         return 0;
+                    }
                     stdvga_mem_write(data, tmp, p->size);
+                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 data += sign * p->size;
                 addr += sign * p->size;
@@ -504,11 +508,15 @@ static int mmio_move(struct hvm_hw_stdvg
                 if ( hvm_copy_from_guest_phys(&tmp, data, p->size) !=
                      HVMCOPY_okay )
                 {
-                    (void)get_gfn_unlocked(d, data >> PAGE_SHIFT, &p2mt);
+                    (void)get_gfn(d, data >> PAGE_SHIFT, &p2mt);
                     if ( (p2mt != p2m_mmio_dm) || (data < VGA_MEM_BASE) ||
                          ((data + p->size) > (VGA_MEM_BASE + VGA_MEM_SIZE)) )
+                    {
+                        put_gfn(d, data >> PAGE_SHIFT);
                         return 0;
+                    }
                     tmp = stdvga_mem_read(data, p->size);
+                    put_gfn(d, data >> PAGE_SHIFT);
                 }
                 stdvga_mem_write(addr, tmp, p->size);
                 data += sign * p->size;
diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2112,7 +2112,7 @@ static void ept_handle_violation(unsigne
         return;
 
     /* Everything else is an error. */
-    mfn = get_gfn_guest_unlocked(d, gfn, &p2mt);
+    mfn = get_gfn_query_unlocked(d, gfn, &p2mt);
     gdprintk(XENLOG_ERR, "EPT violation %#lx (%c%c%c/%c%c%c), "
              "gpa %#"PRIpaddr", mfn %#lx, type %i.\n", 
              qualification, 
diff -r d4336e35f0bc -r 2dc0ef05662e xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -421,7 +421,7 @@ int mem_sharing_debug_gfn(struct domain 
     p2m_type_t p2mt;
     mfn_t mfn;
 
-    mfn = get_gfn_unlocked(d, gfn, &p2mt);
+    mfn = get_gfn_query_unlocked(d, gfn, &p2mt);
 
     gdprintk(XENLOG_DEBUG, "Debug for domain=%d, gfn=%lx, ", 
                d->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 Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJp-0003cD-Fh; Thu, 26 Jan 2012 03:48:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJn-0003bp-Ug
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:12 +0000
Received: from [85.158.139.83:40457] by server-3.bemta-5.messagelabs.com id
	0C/F4-16424-BFCC02F4; Thu, 26 Jan 2012 03:48:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327549690!5084472!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjAxNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2397 invoked from network); 26 Jan 2012 03:48:10 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:10 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 7875D4B008F;
	Wed, 25 Jan 2012 19:48: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=RsxEulNZleGhxfGC5p/3JptAjx4bp1+QrYVzomnGLZDL
	rq+Io7Lljqq4hmT4MWRJay385gQbXtP20FkLptpzZBDQgJtLnFnO4W6foYGXvD8w
	zywE7XaHVnxYLHIcmbo9dMAiIUpvjd0kSektW+LKBridi5Oz2o+G2MwXNzKOcds=
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=aC44ozl5dIzCuXv3jJTsflbNjJU=; b=Voi6K35MCCo
	Fy2A82iUgT7/lF/FTthB2670KIlkuiXbB32MOd5WrBPN5mjhbfmorNShhomXn9BY
	mIW2ddwgHrU+BCW6fqR4/hokrEFWQhLWzFuqUDCxMmG/Q/Y7mMQQNCYdT5jjoNWc
	/sVfdKL2HP8cnsMsRHFXYHe2QEhOsuiI=
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 E10A14B007C; 
	Wed, 25 Jan 2012 19:48:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2e7c77585adbb6aa3f0470286368fbbd1b2baa6b
Message-Id: <2e7c77585adbb6aa3f04.1327550006@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 8] x86/mm: Fix p2m teardown locking
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Holding the p2m lock during a p2m teardown, while unsharing entries pointing to
shared frames, causes a locking inversion and deadlock panic.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 143e4982c9bf -r 2e7c77585adb xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -343,8 +343,6 @@ void p2m_teardown(struct p2m_domain *p2m
     if (p2m == NULL)
         return;
 
-    p2m_lock(p2m);
-
 #ifdef __x86_64__
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
@@ -358,6 +356,8 @@ void p2m_teardown(struct p2m_domain *p2m
     }
 #endif
 
+    p2m_lock(p2m);
+
     p2m->phys_table = pagetable_null();
 
     while ( (pg = page_list_remove_head(&p2m->pages)) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 03:48:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 03: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 1RqGJp-0003cD-Fh; Thu, 26 Jan 2012 03:48:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqGJn-0003bp-Ug
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 03:48:12 +0000
Received: from [85.158.139.83:40457] by server-3.bemta-5.messagelabs.com id
	0C/F4-16424-BFCC02F4; Thu, 26 Jan 2012 03:48:11 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327549690!5084472!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMjAxNjY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2397 invoked from network); 26 Jan 2012 03:48:10 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a23.g.dreamhost.com)
	(208.97.132.145) by server-16.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 03:48:10 -0000
Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 7875D4B008F;
	Wed, 25 Jan 2012 19:48: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=RsxEulNZleGhxfGC5p/3JptAjx4bp1+QrYVzomnGLZDL
	rq+Io7Lljqq4hmT4MWRJay385gQbXtP20FkLptpzZBDQgJtLnFnO4W6foYGXvD8w
	zywE7XaHVnxYLHIcmbo9dMAiIUpvjd0kSektW+LKBridi5Oz2o+G2MwXNzKOcds=
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=aC44ozl5dIzCuXv3jJTsflbNjJU=; b=Voi6K35MCCo
	Fy2A82iUgT7/lF/FTthB2670KIlkuiXbB32MOd5WrBPN5mjhbfmorNShhomXn9BY
	mIW2ddwgHrU+BCW6fqR4/hokrEFWQhLWzFuqUDCxMmG/Q/Y7mMQQNCYdT5jjoNWc
	/sVfdKL2HP8cnsMsRHFXYHe2QEhOsuiI=
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 E10A14B007C; 
	Wed, 25 Jan 2012 19:48:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 2e7c77585adbb6aa3f0470286368fbbd1b2baa6b
Message-Id: <2e7c77585adbb6aa3f04.1327550006@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Wed, 25 Jan 2012 22:53:26 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: olaf@aepfle.de, tim@xen.org, andres@gridcentric.ca, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 8] x86/mm: Fix p2m teardown locking
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 xen/arch/x86/mm/p2m.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Holding the p2m lock during a p2m teardown, while unsharing entries pointing to
shared frames, causes a locking inversion and deadlock panic.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 143e4982c9bf -r 2e7c77585adb xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -343,8 +343,6 @@ void p2m_teardown(struct p2m_domain *p2m
     if (p2m == NULL)
         return;
 
-    p2m_lock(p2m);
-
 #ifdef __x86_64__
     for ( gfn=0; gfn < p2m->max_mapped_pfn; gfn++ )
     {
@@ -358,6 +356,8 @@ void p2m_teardown(struct p2m_domain *p2m
     }
 #endif
 
+    p2m_lock(p2m);
+
     p2m->phys_table = pagetable_null();
 
     while ( (pg = page_list_remove_head(&p2m->pages)) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 06:16:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 06: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 1RqIcx-0007gI-Vy; Thu, 26 Jan 2012 06:16:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqIcw-0007gC-S6
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 06:16:07 +0000
Received: from [85.158.138.51:41606] by server-5.bemta-3.messagelabs.com id
	1C/7B-02363-5AFE02F4; Thu, 26 Jan 2012 06:16:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327558565!10720277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDcyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10710 invoked from network); 26 Jan 2012 06:16:05 -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;
	26 Jan 2012 06:16:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10294841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 06:16: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, 26 Jan 2012 06:16: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 1RqIcu-0005rN-8W;
	Thu, 26 Jan 2012 06:16:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqIcu-0006It-7x;
	Thu, 26 Jan 2012 06:16:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11601-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 06:16:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11601: 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 11601 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11601/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11600

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4271634e4c86
baseline version:
 xen                  4271634e4c86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Thu Jan 26 06:16:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 06: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 1RqIcx-0007gI-Vy; Thu, 26 Jan 2012 06:16:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqIcw-0007gC-S6
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 06:16:07 +0000
Received: from [85.158.138.51:41606] by server-5.bemta-3.messagelabs.com id
	1C/7B-02363-5AFE02F4; Thu, 26 Jan 2012 06:16:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327558565!10720277!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDcyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10710 invoked from network); 26 Jan 2012 06:16:05 -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;
	26 Jan 2012 06:16:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10294841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 06:16: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, 26 Jan 2012 06:16: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 1RqIcu-0005rN-8W;
	Thu, 26 Jan 2012 06:16:04 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqIcu-0006It-7x;
	Thu, 26 Jan 2012 06:16:04 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11601-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 06:16:04 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11601: 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 11601 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11601/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11600

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-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-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-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4271634e4c86
baseline version:
 xen                  4271634e4c86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             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 Thu Jan 26 08:20:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 08: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 1RqKYY-0001QW-Ge; Thu, 26 Jan 2012 08:19:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RqKYX-0001QM-IF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 08:19:41 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327565974!9881093!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22478 invoked from network); 26 Jan 2012 08:19:35 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-12.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 08:19:35 -0000
Received: (qmail 8084 invoked from network); 26 Jan 2012 09:19:33 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	26 Jan 2012 09:19:33 +0100
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 09:19:33 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252148.43195.pavel@netsafe.cz>
	<1327526963.2452.41.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327526963.2452.41.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201260919.33402.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PiBPbiBXZWQsIDIwMTItMDEtMjUgYXQgMjE6NDggKzAxMDAsIFBhdmVsIE1hdMSbamEgd3JvdGU6
Cj4gQWgsIG9rLCBzbyBpbiB5b3VyIGNhc2UsIHRoZSB2QklPUyBkb2Vzbid0IGFjdHVhbGx5IHdv
cmssIGFuZCB5b3UgZG9uJ3QKPiBnZXQgYW55IG91dHB1dCB1bnRpbCB0aGUgT1MgZHJpdmVycyBs
b2FkPyAgQnV0IHlvdSBuZWVkIHRvIGxvYWQgdGhlCj4gcHJvcGVyIGJpb3MgdG8gZ3Vlc3QgbWVt
b3J5IGFueXdheSBiZWNhdXNlIHRoZSBkcml2ZXJzIGRlcGVuZCBvbiBpdD8KCkkgZG8gZ2V0IHRo
ZSBCSU9TIG91dHB1dC4gSnVzdCBvbiB3cm9uZyBjYXJkLgo7KQoKQlRXOiBUaGVyZSBpcyBxZW11
LWNsYWltLXZnYS1jeWNsZS1mb3Itc2Vjb25kYXJ5LWdmeC1wYXNzdGhyb3VnaC5wYXRjaDoKaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20vYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAwOS0wOC9i
aW5mR0VKQWlSOFpBLmJpbgp3aGljaCBkb2VzIHRoZSBWR0EgRW5hYmxlIGJpdCB0aGluZ3Mgbm90
IHVzaW5nIExpbnV4IHZnYWFyYi4KQnV0IEkgdGhpbmsgdGhlIHBhcnQgd2l0aCBQQ0lfSE9TVF9C
UklER0VfSUdEX1ZHQV9ESVNBQkxFIGlzIGZvciBJbnRlbCAKY2hpcHNldC4KLS0gClBhdmVsIE1h
dGVqYQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8v
bGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Jan 26 08:20:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 08: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 1RqKYY-0001QW-Ge; Thu, 26 Jan 2012 08:19:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pavel@netsafe.cz>) id 1RqKYX-0001QM-IF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 08:19:41 +0000
X-Env-Sender: pavel@netsafe.cz
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327565974!9881093!1
X-Originating-IP: [83.223.49.132]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22478 invoked from network); 26 Jan 2012 08:19:35 -0000
Received: from gate1.netsafe.cz (HELO gate1.netsafe.cz) (83.223.49.132)
	by server-12.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 08:19:35 -0000
Received: (qmail 8084 invoked from network); 26 Jan 2012 09:19:33 +0100
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on webgate.netsafe.cz
X-Spam-Level: 
X-Spam-Status: No, score=-106.8 required=5.0 tests=ALL_TRUSTED,BAYES_00,
	USER_IN_WHITELIST autolearn=ham version=3.2.5
Received: from unknown (HELO nudel.localnet) (10.64.1.132)
	by webgate.netsafe.cz with AES256-SHA encrypted SMTP;
	26 Jan 2012 09:19:33 +0100
From: Pavel Mateja <pavel@netsafe.cz>
Organization: Netsafe
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 09:19:33 +0100
User-Agent: KMail/1.13.7 (Linux/3.2.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201252148.43195.pavel@netsafe.cz>
	<1327526963.2452.41.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327526963.2452.41.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201260919.33402.pavel@netsafe.cz>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PiBPbiBXZWQsIDIwMTItMDEtMjUgYXQgMjE6NDggKzAxMDAsIFBhdmVsIE1hdMSbamEgd3JvdGU6
Cj4gQWgsIG9rLCBzbyBpbiB5b3VyIGNhc2UsIHRoZSB2QklPUyBkb2Vzbid0IGFjdHVhbGx5IHdv
cmssIGFuZCB5b3UgZG9uJ3QKPiBnZXQgYW55IG91dHB1dCB1bnRpbCB0aGUgT1MgZHJpdmVycyBs
b2FkPyAgQnV0IHlvdSBuZWVkIHRvIGxvYWQgdGhlCj4gcHJvcGVyIGJpb3MgdG8gZ3Vlc3QgbWVt
b3J5IGFueXdheSBiZWNhdXNlIHRoZSBkcml2ZXJzIGRlcGVuZCBvbiBpdD8KCkkgZG8gZ2V0IHRo
ZSBCSU9TIG91dHB1dC4gSnVzdCBvbiB3cm9uZyBjYXJkLgo7KQoKQlRXOiBUaGVyZSBpcyBxZW11
LWNsYWltLXZnYS1jeWNsZS1mb3Itc2Vjb25kYXJ5LWdmeC1wYXNzdGhyb3VnaC5wYXRjaDoKaHR0
cDovL2xpc3RzLnhlbnNvdXJjZS5jb20vYXJjaGl2ZXMvaHRtbC94ZW4tZGV2ZWwvMjAwOS0wOC9i
aW5mR0VKQWlSOFpBLmJpbgp3aGljaCBkb2VzIHRoZSBWR0EgRW5hYmxlIGJpdCB0aGluZ3Mgbm90
IHVzaW5nIExpbnV4IHZnYWFyYi4KQnV0IEkgdGhpbmsgdGhlIHBhcnQgd2l0aCBQQ0lfSE9TVF9C
UklER0VfSUdEX1ZHQV9ESVNBQkxFIGlzIGZvciBJbnRlbCAKY2hpcHNldC4KLS0gClBhdmVsIE1h
dGVqYQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVu
LWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8v
bGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Thu Jan 26 08:26:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 08:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqKeZ-0001hZ-Bs; Thu, 26 Jan 2012 08:25: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 1RqKeY-0001hK-CQ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 08:25:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327566306!57501479!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDcyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31455 invoked from network); 26 Jan 2012 08:25:07 -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;
	26 Jan 2012 08:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10296400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 08:25: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;
	Thu, 26 Jan 2012 08:25:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 08:25:47 +0000
In-Reply-To: <a7776e38447d4e633a45.1327512253@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<a7776e38447d4e633a45.1327512253@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327566347.26983.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 9] libxl: remove libxl_button_press in
 favour of libxl_send_trigger
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 17:24 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1327510508 0
> # Node ID a7776e38447d4e633a45b926295f7923c046fbc9
> # Parent  b9973edc7528e5233698fefd234be19dd6d6bcee
> libxl: remove libxl_button_press in favour of libxl_send_trigger.
> 
> send_trigger already included all the operations covered by button_press.
> 
> Rework send_trigger to take an enum instead of a string.
> 
> I stopped short at removing the xl "button-press" command but instead have
> marked it as deprecated.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

V2: update messages from xl destroy/reboot when no PV mechanism is
present.

8<-------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327510508 0
# Node ID a7776e38447d4e633a45b926295f7923c046fbc9
# Parent  b9973edc7528e5233698fefd234be19dd6d6bcee
libxl: remove libxl_button_press in favour of libxl_send_trigger.

send_trigger already included all the operations covered by button_press.

Rework send_trigger to take an enum instead of a string.

I stopped short at removing the xl "button-press" command but instead have
marked it as deprecated.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b9973edc7528 -r a7776e38447d docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jan 25 16:55:08 2012 +0000
+++ b/docs/man/xl.pod.1	Wed Jan 25 16:55:08 2012 +0000
@@ -86,6 +86,8 @@ previously, most commands take I<domain-
 
 =item B<button-press> I<domain-id> I<button>
 
+I<This command is deprecated. Please use C<xl trigger> in preference>
+
 Indicate an ACPI button press to the domain. I<button> is may be 'power' or
 'sleep'. This command is only available for HVM domains.
 
@@ -448,7 +450,7 @@ It can be used to send SysRq requests to
 your Linux Kernel sources for more information.
 It requires PV drivers to be installed in your guest OS.
 
-=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
+=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep|s3resume> [I<VCPU>]
 
 Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
 or sleep.  Optionally a specific vcpu number can be passed as an argument.
diff -r b9973edc7528 -r a7776e38447d tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/gentypes.py	Wed Jan 25 16:55:08 2012 +0000
@@ -32,6 +32,9 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, idl.Aggregate):
+        if isinstance(ty, idl.KeyedUnion):
+            s += libxl_C_instance_of(ty.keyvar_type, ty.keyvar_name) + ";\n"
+            
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
diff -r b9973edc7528 -r a7776e38447d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Jan 25 16:55:08 2012 +0000
@@ -2477,24 +2477,6 @@ out:
     return 0;
 }
 
-int libxl_button_press(libxl_ctx *ctx, uint32_t domid, libxl_button button)
-{
-    int rc = -1;
-
-    switch (button) {
-    case LIBXL_BUTTON_POWER:
-        rc = xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_POWER, 0);
-        break;
-    case LIBXL_BUTTON_SLEEP:
-        rc = xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_SLEEP, 0);
-        break;
-    default:
-        break;
-    }
-
-    return rc;
-}
-
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 {
     xc_physinfo_t xcphysinfo = { 0 };
@@ -2876,44 +2858,46 @@ int libxl_sched_sedf_domain_set(libxl_ct
     return 0;
 }
 
-static int trigger_type_from_string(char *trigger_name)
+int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
+                       libxl_trigger trigger, uint32_t vcpuid)
 {
-    if (!strcmp(trigger_name, "nmi"))
-        return XEN_DOMCTL_SENDTRIGGER_NMI;
-    else if (!strcmp(trigger_name, "reset"))
-        return XEN_DOMCTL_SENDTRIGGER_RESET;
-    else if (!strcmp(trigger_name, "init"))
-        return XEN_DOMCTL_SENDTRIGGER_INIT;
-    else if (!strcmp(trigger_name, "power"))
-        return XEN_DOMCTL_SENDTRIGGER_POWER;
-    else if (!strcmp(trigger_name, "sleep"))
-        return XEN_DOMCTL_SENDTRIGGER_SLEEP;
-    else
-        return -1;
-}
-
-int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint32_t vcpuid)
-{
-    int rc = -1;
-    int trigger_type = -1;
-
-    if (!strcmp(trigger_name, "s3resume")) {
+    int rc;
+
+    switch (trigger) {
+    case LIBXL_TRIGGER_POWER:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_POWER, vcpuid);
+        break;
+    case LIBXL_TRIGGER_SLEEP:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_SLEEP, vcpuid);
+        break;
+    case LIBXL_TRIGGER_NMI:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_NMI, vcpuid);
+        break;
+    case LIBXL_TRIGGER_INIT:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_INIT, vcpuid);
+        break;
+    case LIBXL_TRIGGER_RESET:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_RESET, vcpuid);
+        break;
+    case LIBXL_TRIGGER_S3RESUME:
         xc_set_hvm_param(ctx->xch, domid, HVM_PARAM_ACPI_S_STATE, 0);
-        return 0;
+        rc = 0;
+        break;
+    default:
+        rc = EINVAL;
+        break;
     }
 
-    trigger_type = trigger_type_from_string(trigger_name);
-    if (trigger_type == -1) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
-            "Invalid trigger, valid triggers are <nmi|reset|init|power|sleep>");
-        return ERROR_INVAL;
-    }
-
-    rc = xc_domain_send_trigger(ctx->xch, domid, trigger_type, vcpuid);
     if (rc != 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
-            "Send trigger '%s' failed", trigger_name);
-        return ERROR_FAIL;
+                            "Send trigger '%s' failed",
+                            libxl_trigger_to_string(trigger));
+        rc = ERROR_FAIL;
     }
 
     return 0;
diff -r b9973edc7528 -r a7776e38447d tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Jan 25 16:55:08 2012 +0000
@@ -547,8 +547,6 @@ int libxl_userdata_retrieve(libxl_ctx *c
    * On error return, *data_r and *datalen_r are undefined.
    */
 
-int libxl_button_press(libxl_ctx *ctx, uint32_t domid, libxl_button button);
-
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
 int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
@@ -573,7 +571,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
                                 libxl_sched_sedf *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
-                       char *trigger_name, uint32_t vcpuid);
+                       libxl_trigger trigger, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
 int libxl_send_debug_keys(libxl_ctx *ctx, char *keys);
 
diff -r b9973edc7528 -r a7776e38447d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 25 16:55:08 2012 +0000
@@ -80,9 +80,14 @@ libxl_event_type = Enumeration("event_ty
     (2, "DISK_EJECT"),
     ])
 
-libxl_button = Enumeration("button", [
+libxl_trigger = Enumeration("trigger", [
+    (0, "UNKNOWN"),
     (1, "POWER"),
     (2, "SLEEP"),
+    (3, "NMI"),
+    (4, "INIT"),
+    (5, "RESET"),
+    (6, "S3RESUME"),
     ])
 
 libxl_tsc_mode = Enumeration("tsc_mode", [
@@ -203,7 +208,6 @@ libxl_domain_build_info = Struct("domain
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
-    ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
diff -r b9973edc7528 -r a7776e38447d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:55:08 2012 +0000
@@ -3318,26 +3318,29 @@ int main_create(int argc, char **argv)
 
 static void button_press(const char *p, const char *b)
 {
-    libxl_button button;
+    libxl_trigger trigger;
 
     find_domain(p);
 
     if (!strcmp(b, "power")) {
-        button = LIBXL_BUTTON_POWER;
+        trigger = LIBXL_TRIGGER_POWER;
     } else if (!strcmp(b, "sleep")) {
-        button = LIBXL_BUTTON_SLEEP;
+        trigger = LIBXL_TRIGGER_SLEEP;
     } else {
         fprintf(stderr, "%s is an invalid button identifier\n", b);
         exit(2);
     }
 
-    libxl_button_press(ctx, domid, button);
+    libxl_send_trigger(ctx, domid, trigger, 0);
 }
 
 int main_button_press(int argc, char **argv)
 {
     int opt;
 
+    fprintf(stderr, "WARNING: \"button-press\" is deprecated. "
+            "Please use \"trigger\"\n");
+
     if ((opt = def_getopt(argc, argv, "", "button-press", 2)) != -1)
         return opt;
 
@@ -4322,10 +4325,11 @@ int main_rename(int argc, char **argv)
 int main_trigger(int argc, char **argv)
 {
     int opt;
-    char *trigger_name = NULL;
     char *endptr = NULL;
     const char *dom = NULL;
     int vcpuid = 0;
+    const char *trigger_name = NULL;
+    libxl_trigger trigger;
 
     if ((opt = def_getopt(argc, argv, "", "trigger", 2)) != -1)
         return opt;
@@ -4335,6 +4339,10 @@ int main_trigger(int argc, char **argv)
     find_domain(dom);
 
     trigger_name = argv[optind++];
+    if (libxl_trigger_from_string(trigger_name, &trigger)) {
+        fprintf(stderr, "Invalid trigger \"%s\"\n", trigger_name);
+        return -1;
+    }
 
     if (argv[optind]) {
         vcpuid = strtol(argv[optind], &endptr, 10);
@@ -4343,7 +4351,7 @@ int main_trigger(int argc, char **argv)
         }
     }
 
-    libxl_send_trigger(ctx, domid, trigger_name, vcpuid);
+    libxl_send_trigger(ctx, domid, trigger, vcpuid);
 
     return 0;
 }
diff -r b9973edc7528 -r a7776e38447d tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight.ml.in	Wed Jan 25 16:55:08 2012 +0000
@@ -29,10 +29,8 @@ module Topologyinfo = struct
 	external get : unit -> t = "stub_xl_topologyinfo"
 end
 
-external button_press : domid -> button -> unit = "stub_xl_button_press"
 
-
-external send_trigger : domid -> string -> int -> unit = "stub_xl_send_trigger"
+external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
 
diff -r b9973edc7528 -r a7776e38447d tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight.mli.in	Wed Jan 25 16:55:08 2012 +0000
@@ -29,8 +29,6 @@ module Topologyinfo : sig
 	external get : unit -> t = "stub_xl_topologyinfo"
 end
 
-external button_press : domid -> button -> unit = "stub_xl_button_press"
-
-external send_trigger : domid -> string -> int -> unit = "stub_xl_send_trigger"
+external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff -r b9973edc7528 -r a7776e38447d tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Wed Jan 25 16:55:08 2012 +0000
@@ -432,21 +432,6 @@ value stub_xl_device_pci_remove(value in
 	CAMLreturn(Val_unit);
 }
 
-value stub_xl_button_press(value domid, value button)
-{
-	CAMLparam2(domid, button);
-	int ret;
-	INIT_STRUCT();
-
-	INIT_CTX();
-	ret = libxl_button_press(ctx, Int_val(domid), Int_val(button) + LIBXL_BUTTON_POWER);
-	if (ret != 0)
-		failwith_xl("button_press", &lg);
-	FREE_CTX();
-
-	CAMLreturn(Val_unit);
-}
-
 value stub_xl_physinfo_get(value unit)
 {
 	CAMLparam1(unit);
@@ -523,10 +508,10 @@ value stub_xl_send_trigger(value domid, 
 {
 	CAMLparam3(domid, trigger, vcpuid);
 	int ret;
-	char *c_trigger;
+	libxl_trigger c_trigger = LIBXL_TRIGGER_UNKNOWN;
 	INIT_STRUCT();
 
-	c_trigger = dup_String_val(&gc, trigger);
+	trigger_val(&gc, &lg, &c_trigger, trigger);
 
 	INIT_CTX();
 	ret = libxl_send_trigger(ctx, Int_val(domid), c_trigger, Int_val(vcpuid));



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 08:26:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 08:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqKeZ-0001hZ-Bs; Thu, 26 Jan 2012 08:25: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 1RqKeY-0001hK-CQ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 08:25:54 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327566306!57501479!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDcyNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31455 invoked from network); 26 Jan 2012 08:25:07 -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;
	26 Jan 2012 08:25:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10296400"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 08:25: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;
	Thu, 26 Jan 2012 08:25:48 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 08:25:47 +0000
In-Reply-To: <a7776e38447d4e633a45.1327512253@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<a7776e38447d4e633a45.1327512253@cosworth.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327566347.26983.3.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 9] libxl: remove libxl_button_press in
 favour of libxl_send_trigger
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 17:24 +0000, Ian Campbell wrote:
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1327510508 0
> # Node ID a7776e38447d4e633a45b926295f7923c046fbc9
> # Parent  b9973edc7528e5233698fefd234be19dd6d6bcee
> libxl: remove libxl_button_press in favour of libxl_send_trigger.
> 
> send_trigger already included all the operations covered by button_press.
> 
> Rework send_trigger to take an enum instead of a string.
> 
> I stopped short at removing the xl "button-press" command but instead have
> marked it as deprecated.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

V2: update messages from xl destroy/reboot when no PV mechanism is
present.

8<-------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327510508 0
# Node ID a7776e38447d4e633a45b926295f7923c046fbc9
# Parent  b9973edc7528e5233698fefd234be19dd6d6bcee
libxl: remove libxl_button_press in favour of libxl_send_trigger.

send_trigger already included all the operations covered by button_press.

Rework send_trigger to take an enum instead of a string.

I stopped short at removing the xl "button-press" command but instead have
marked it as deprecated.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r b9973edc7528 -r a7776e38447d docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jan 25 16:55:08 2012 +0000
+++ b/docs/man/xl.pod.1	Wed Jan 25 16:55:08 2012 +0000
@@ -86,6 +86,8 @@ previously, most commands take I<domain-
 
 =item B<button-press> I<domain-id> I<button>
 
+I<This command is deprecated. Please use C<xl trigger> in preference>
+
 Indicate an ACPI button press to the domain. I<button> is may be 'power' or
 'sleep'. This command is only available for HVM domains.
 
@@ -448,7 +450,7 @@ It can be used to send SysRq requests to
 your Linux Kernel sources for more information.
 It requires PV drivers to be installed in your guest OS.
 
-=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
+=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep|s3resume> [I<VCPU>]
 
 Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
 or sleep.  Optionally a specific vcpu number can be passed as an argument.
diff -r b9973edc7528 -r a7776e38447d tools/libxl/gentypes.py
--- a/tools/libxl/gentypes.py	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/gentypes.py	Wed Jan 25 16:55:08 2012 +0000
@@ -32,6 +32,9 @@ def libxl_C_type_define(ty, indent = "")
             s += "} %s" % ty.typename
 
     elif isinstance(ty, idl.Aggregate):
+        if isinstance(ty, idl.KeyedUnion):
+            s += libxl_C_instance_of(ty.keyvar_type, ty.keyvar_name) + ";\n"
+            
         if ty.typename is None:
             s += "%s {\n" % ty.kind
         else:
diff -r b9973edc7528 -r a7776e38447d tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/libxl.c	Wed Jan 25 16:55:08 2012 +0000
@@ -2477,24 +2477,6 @@ out:
     return 0;
 }
 
-int libxl_button_press(libxl_ctx *ctx, uint32_t domid, libxl_button button)
-{
-    int rc = -1;
-
-    switch (button) {
-    case LIBXL_BUTTON_POWER:
-        rc = xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_POWER, 0);
-        break;
-    case LIBXL_BUTTON_SLEEP:
-        rc = xc_domain_send_trigger(ctx->xch, domid, XEN_DOMCTL_SENDTRIGGER_SLEEP, 0);
-        break;
-    default:
-        break;
-    }
-
-    return rc;
-}
-
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo)
 {
     xc_physinfo_t xcphysinfo = { 0 };
@@ -2876,44 +2858,46 @@ int libxl_sched_sedf_domain_set(libxl_ct
     return 0;
 }
 
-static int trigger_type_from_string(char *trigger_name)
+int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
+                       libxl_trigger trigger, uint32_t vcpuid)
 {
-    if (!strcmp(trigger_name, "nmi"))
-        return XEN_DOMCTL_SENDTRIGGER_NMI;
-    else if (!strcmp(trigger_name, "reset"))
-        return XEN_DOMCTL_SENDTRIGGER_RESET;
-    else if (!strcmp(trigger_name, "init"))
-        return XEN_DOMCTL_SENDTRIGGER_INIT;
-    else if (!strcmp(trigger_name, "power"))
-        return XEN_DOMCTL_SENDTRIGGER_POWER;
-    else if (!strcmp(trigger_name, "sleep"))
-        return XEN_DOMCTL_SENDTRIGGER_SLEEP;
-    else
-        return -1;
-}
-
-int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid, char *trigger_name, uint32_t vcpuid)
-{
-    int rc = -1;
-    int trigger_type = -1;
-
-    if (!strcmp(trigger_name, "s3resume")) {
+    int rc;
+
+    switch (trigger) {
+    case LIBXL_TRIGGER_POWER:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_POWER, vcpuid);
+        break;
+    case LIBXL_TRIGGER_SLEEP:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_SLEEP, vcpuid);
+        break;
+    case LIBXL_TRIGGER_NMI:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_NMI, vcpuid);
+        break;
+    case LIBXL_TRIGGER_INIT:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_INIT, vcpuid);
+        break;
+    case LIBXL_TRIGGER_RESET:
+        rc = xc_domain_send_trigger(ctx->xch, domid,
+                                    XEN_DOMCTL_SENDTRIGGER_RESET, vcpuid);
+        break;
+    case LIBXL_TRIGGER_S3RESUME:
         xc_set_hvm_param(ctx->xch, domid, HVM_PARAM_ACPI_S_STATE, 0);
-        return 0;
+        rc = 0;
+        break;
+    default:
+        rc = EINVAL;
+        break;
     }
 
-    trigger_type = trigger_type_from_string(trigger_name);
-    if (trigger_type == -1) {
-        LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, -1,
-            "Invalid trigger, valid triggers are <nmi|reset|init|power|sleep>");
-        return ERROR_INVAL;
-    }
-
-    rc = xc_domain_send_trigger(ctx->xch, domid, trigger_type, vcpuid);
     if (rc != 0) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc,
-            "Send trigger '%s' failed", trigger_name);
-        return ERROR_FAIL;
+                            "Send trigger '%s' failed",
+                            libxl_trigger_to_string(trigger));
+        rc = ERROR_FAIL;
     }
 
     return 0;
diff -r b9973edc7528 -r a7776e38447d tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/libxl.h	Wed Jan 25 16:55:08 2012 +0000
@@ -547,8 +547,6 @@ int libxl_userdata_retrieve(libxl_ctx *c
    * On error return, *data_r and *datalen_r are undefined.
    */
 
-int libxl_button_press(libxl_ctx *ctx, uint32_t domid, libxl_button button);
-
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
 int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
@@ -573,7 +571,7 @@ int libxl_sched_sedf_domain_get(libxl_ct
 int libxl_sched_sedf_domain_set(libxl_ctx *ctx, uint32_t domid,
                                 libxl_sched_sedf *scinfo);
 int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
-                       char *trigger_name, uint32_t vcpuid);
+                       libxl_trigger trigger, uint32_t vcpuid);
 int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
 int libxl_send_debug_keys(libxl_ctx *ctx, char *keys);
 
diff -r b9973edc7528 -r a7776e38447d tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Wed Jan 25 16:55:08 2012 +0000
@@ -80,9 +80,14 @@ libxl_event_type = Enumeration("event_ty
     (2, "DISK_EJECT"),
     ])
 
-libxl_button = Enumeration("button", [
+libxl_trigger = Enumeration("trigger", [
+    (0, "UNKNOWN"),
     (1, "POWER"),
     (2, "SLEEP"),
+    (3, "NMI"),
+    (4, "INIT"),
+    (5, "RESET"),
+    (6, "S3RESUME"),
     ])
 
 libxl_tsc_mode = Enumeration("tsc_mode", [
@@ -203,7 +208,6 @@ libxl_domain_build_info = Struct("domain
     ("shadow_memkb",    uint32),
     ("disable_migrate", bool),
     ("cpuid",           libxl_cpuid_policy_list),
-    ("type",            libxl_domain_type),
     
     ("device_model_version", libxl_device_model_version),
     ("device_model_stubdomain", bool),
diff -r b9973edc7528 -r a7776e38447d tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:55:08 2012 +0000
@@ -3318,26 +3318,29 @@ int main_create(int argc, char **argv)
 
 static void button_press(const char *p, const char *b)
 {
-    libxl_button button;
+    libxl_trigger trigger;
 
     find_domain(p);
 
     if (!strcmp(b, "power")) {
-        button = LIBXL_BUTTON_POWER;
+        trigger = LIBXL_TRIGGER_POWER;
     } else if (!strcmp(b, "sleep")) {
-        button = LIBXL_BUTTON_SLEEP;
+        trigger = LIBXL_TRIGGER_SLEEP;
     } else {
         fprintf(stderr, "%s is an invalid button identifier\n", b);
         exit(2);
     }
 
-    libxl_button_press(ctx, domid, button);
+    libxl_send_trigger(ctx, domid, trigger, 0);
 }
 
 int main_button_press(int argc, char **argv)
 {
     int opt;
 
+    fprintf(stderr, "WARNING: \"button-press\" is deprecated. "
+            "Please use \"trigger\"\n");
+
     if ((opt = def_getopt(argc, argv, "", "button-press", 2)) != -1)
         return opt;
 
@@ -4322,10 +4325,11 @@ int main_rename(int argc, char **argv)
 int main_trigger(int argc, char **argv)
 {
     int opt;
-    char *trigger_name = NULL;
     char *endptr = NULL;
     const char *dom = NULL;
     int vcpuid = 0;
+    const char *trigger_name = NULL;
+    libxl_trigger trigger;
 
     if ((opt = def_getopt(argc, argv, "", "trigger", 2)) != -1)
         return opt;
@@ -4335,6 +4339,10 @@ int main_trigger(int argc, char **argv)
     find_domain(dom);
 
     trigger_name = argv[optind++];
+    if (libxl_trigger_from_string(trigger_name, &trigger)) {
+        fprintf(stderr, "Invalid trigger \"%s\"\n", trigger_name);
+        return -1;
+    }
 
     if (argv[optind]) {
         vcpuid = strtol(argv[optind], &endptr, 10);
@@ -4343,7 +4351,7 @@ int main_trigger(int argc, char **argv)
         }
     }
 
-    libxl_send_trigger(ctx, domid, trigger_name, vcpuid);
+    libxl_send_trigger(ctx, domid, trigger, vcpuid);
 
     return 0;
 }
diff -r b9973edc7528 -r a7776e38447d tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight.ml.in	Wed Jan 25 16:55:08 2012 +0000
@@ -29,10 +29,8 @@ module Topologyinfo = struct
 	external get : unit -> t = "stub_xl_topologyinfo"
 end
 
-external button_press : domid -> button -> unit = "stub_xl_button_press"
 
-
-external send_trigger : domid -> string -> int -> unit = "stub_xl_send_trigger"
+external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
 
diff -r b9973edc7528 -r a7776e38447d tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight.mli.in	Wed Jan 25 16:55:08 2012 +0000
@@ -29,8 +29,6 @@ module Topologyinfo : sig
 	external get : unit -> t = "stub_xl_topologyinfo"
 end
 
-external button_press : domid -> button -> unit = "stub_xl_button_press"
-
-external send_trigger : domid -> string -> int -> unit = "stub_xl_send_trigger"
+external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff -r b9973edc7528 -r a7776e38447d tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Wed Jan 25 16:55:08 2012 +0000
@@ -432,21 +432,6 @@ value stub_xl_device_pci_remove(value in
 	CAMLreturn(Val_unit);
 }
 
-value stub_xl_button_press(value domid, value button)
-{
-	CAMLparam2(domid, button);
-	int ret;
-	INIT_STRUCT();
-
-	INIT_CTX();
-	ret = libxl_button_press(ctx, Int_val(domid), Int_val(button) + LIBXL_BUTTON_POWER);
-	if (ret != 0)
-		failwith_xl("button_press", &lg);
-	FREE_CTX();
-
-	CAMLreturn(Val_unit);
-}
-
 value stub_xl_physinfo_get(value unit)
 {
 	CAMLparam1(unit);
@@ -523,10 +508,10 @@ value stub_xl_send_trigger(value domid, 
 {
 	CAMLparam3(domid, trigger, vcpuid);
 	int ret;
-	char *c_trigger;
+	libxl_trigger c_trigger = LIBXL_TRIGGER_UNKNOWN;
 	INIT_STRUCT();
 
-	c_trigger = dup_String_val(&gc, trigger);
+	trigger_val(&gc, &lg, &c_trigger, trigger);
 
 	INIT_CTX();
 	ret = libxl_send_trigger(ctx, Int_val(domid), c_trigger, Int_val(vcpuid));



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 08:45:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 08: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 1RqKxS-0001wH-D1; Thu, 26 Jan 2012 08:45:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqKxQ-0001wC-Bs
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 08:45:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327567517!10288773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14691 invoked from network); 26 Jan 2012 08:45:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 08:45:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10296743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 08:45:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 08:45:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 08:45:16 +0000
In-Reply-To: <osstest-11601-mainreport@xen.org>
References: <osstest-11601-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327567516.26983.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] [xen-unstable test] 11601: 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

On Thu, 2012-01-26 at 06:16 +0000, xen.org wrote:
[...]
> Tests which did not succeed, but are not blocking:
>  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 are failing with:
        2012-01-26 05:08:15 Z toolstack xl
        Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13.
        2012-01-26 05:08:15 Z executing ssh ... root@10.80.249.57 xl create 
        Config file not specified and none in save file
        2012-01-26 05:08:15 Z command nonzero waitstatus 1536: ssh -o StrictHostKeyChecking=no \
        	-o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 \
        	-o PasswordAuthentication=no -o ChallengeResponseAuthentication=no \
        	-o UserKnownHostsFile=tmp/t.known_hosts_11601.test-amd64-i386-rhel6hvm-amd root@10.80.249.57 xl create 
        
Which is presumably a harness failure.

I'm not sure I 100% follow things but it seems that
"toolstack()->{CfgPathVar}" is going to be "xlpath" rather than
"cfgpath" but that Osstest.pm:selectguest is only setting up cfgpath.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 08:45:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 08: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 1RqKxS-0001wH-D1; Thu, 26 Jan 2012 08:45:26 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqKxQ-0001wC-Bs
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 08:45:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327567517!10288773!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14691 invoked from network); 26 Jan 2012 08:45:17 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 08:45:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10296743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 08:45:16 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 08:45:16 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 08:45:16 +0000
In-Reply-To: <osstest-11601-mainreport@xen.org>
References: <osstest-11601-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327567516.26983.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] [xen-unstable test] 11601: 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

On Thu, 2012-01-26 at 06:16 +0000, xen.org wrote:
[...]
> Tests which did not succeed, but are not blocking:
>  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 are failing with:
        2012-01-26 05:08:15 Z toolstack xl
        Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13.
        2012-01-26 05:08:15 Z executing ssh ... root@10.80.249.57 xl create 
        Config file not specified and none in save file
        2012-01-26 05:08:15 Z command nonzero waitstatus 1536: ssh -o StrictHostKeyChecking=no \
        	-o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 \
        	-o PasswordAuthentication=no -o ChallengeResponseAuthentication=no \
        	-o UserKnownHostsFile=tmp/t.known_hosts_11601.test-amd64-i386-rhel6hvm-amd root@10.80.249.57 xl create 
        
Which is presumably a harness failure.

I'm not sure I 100% follow things but it seems that
"toolstack()->{CfgPathVar}" is going to be "xlpath" rather than
"cfgpath" but that Osstest.pm:selectguest is only setting up cfgpath.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 09:16:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLRO-0002Rj-4C; Thu, 26 Jan 2012 09:16:22 +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 1RqLRN-0002Qx-7G
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:16:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327569374!12024141!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 893 invoked from network); 26 Jan 2012 09:16:15 -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; 26 Jan 2012 09:16:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 09:16:14 +0000
Message-Id: <4F212835020000780006F264@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 09:17:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
	<CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
	<20120125163910.GC23999@phenom.dumpdata.com>
	<20120125212214.GA29571@phenom.dumpdata.com>
In-Reply-To: <20120125212214.GA29571@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, socketpair@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Fwd: BUG in
 linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.01.12 at 22:22, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -206,8 +206,9 @@ static int xen_pcibk_publish_pci_dev(struct 
> xen_pcibk_device *pdev,
>  		goto out;
>  	}
>  
> +	/* TODO: implement feature-use-decimal-for-devfn */
>  	err = xenbus_printf(XBT_NIL, pdev->xdev->nodename, str,
> -			    "%04x:%02x:%02x.%02x", domain, bus,
> +			    "%04x:%02x:%02x.%1x", domain, bus,
>  			    PCI_SLOT(devfn), PCI_FUNC(devfn));
>  
>  out:

If you are concerned about compatibility (as the added comment
suggests), then removing the leading zero is not an option either.

However, as long as all parsers of the string use plain %x or %d,
there's no issue here and you could as well use %d here too (as
PCI functions are always in the 0-7 range, which is identically
represented in octal [important for the case of a leading zero],
decimal, and hex).

Bottom line - just add the comment here, and leave the format
unchanged, or change the format to %d right away.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 09:16:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:16:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLRO-0002Rj-4C; Thu, 26 Jan 2012 09:16:22 +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 1RqLRN-0002Qx-7G
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:16:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327569374!12024141!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 893 invoked from network); 26 Jan 2012 09:16:15 -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; 26 Jan 2012 09:16:15 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 09:16:14 +0000
Message-Id: <4F212835020000780006F264@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 09:17:25 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
	<CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
	<20120125163910.GC23999@phenom.dumpdata.com>
	<20120125212214.GA29571@phenom.dumpdata.com>
In-Reply-To: <20120125212214.GA29571@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, socketpair@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Fwd: BUG in
 linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 25.01.12 at 22:22, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> --- a/drivers/xen/xen-pciback/xenbus.c
> +++ b/drivers/xen/xen-pciback/xenbus.c
> @@ -206,8 +206,9 @@ static int xen_pcibk_publish_pci_dev(struct 
> xen_pcibk_device *pdev,
>  		goto out;
>  	}
>  
> +	/* TODO: implement feature-use-decimal-for-devfn */
>  	err = xenbus_printf(XBT_NIL, pdev->xdev->nodename, str,
> -			    "%04x:%02x:%02x.%02x", domain, bus,
> +			    "%04x:%02x:%02x.%1x", domain, bus,
>  			    PCI_SLOT(devfn), PCI_FUNC(devfn));
>  
>  out:

If you are concerned about compatibility (as the added comment
suggests), then removing the leading zero is not an option either.

However, as long as all parsers of the string use plain %x or %d,
there's no issue here and you could as well use %d here too (as
PCI functions are always in the 0-7 range, which is identically
represented in octal [important for the case of a leading zero],
decimal, and hex).

Bottom line - just add the comment here, and leave the format
unchanged, or change the format to %d right away.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 09:19:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09: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 1RqLTe-0002mS-Li; Thu, 26 Jan 2012 09:18: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 1RqLTc-0002m7-Pk
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:18:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327569505!8680077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25022 invoked from network); 26 Jan 2012 09:18:34 -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;
	26 Jan 2012 09:18:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10297908"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 09:18: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, 26 Jan 2012 09:18:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 26 Jan 2012 09:18:25 +0000
In-Reply-To: <CAP8mzPMed1A_BVCgoAKfcuPhRr910j8uJQFuQ_x9t9PHx0iifA@mail.gmail.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
	<1327489725.24561.284.camel@zakaz.uk.xensource.com>
	<CAP8mzPMed1A_BVCgoAKfcuPhRr910j8uJQFuQ_x9t9PHx0iifA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327569505.26983.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model
 suspend/resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 23:07 +0000, Shriram Rajagopalan wrote:
> On Wed, Jan 25, 2012 at 3:08 AM, Ian Campbell 

>         > -        libxl__xs_write(gc, XBT_NULL, path, "save");
>         > -        libxl__wait_for_device_model(gc, domid, "paused",
>         NULL, NULL, NULL);
>         > +        /* For Remus,we issue suspend_qemu call separately
>         */
>         
>         
>         Why?
>         
> 
> In remus, save and transmit device model phases are decoupled. This
> code (sending the saved device model to the target) is executed after
> the domain is resumed.
> 
> The control flow in current Remus is like this:
> 1 suspend vm
>   1.1 suspend qemu (save command, that saves the device model to a
> file)
> 2 copy out dirty memory into a buffer
> 3 resume vm 
>   3.1 resume qemu
> 4 send the data in the buffer
> 5  send the saved device model
>     (xc_domain_restore extracts this from the tailbuf)

Is this basic flow incompatible with regular save? Isn't it equivalent
to to omitting phase 3? (I know regular save is structured a bit
different right now, but it could be done this way to minimise the
amount of Remus specific code).

Which "struct save_callbacks" members do each of these stages correspond
to?

I think a high level overview of the ordering of operations and the
usage of these hooks would make an ideal comment just above the
definition of "struct save_callbacks", what do you think?

>         How does this interact with Stefano's XC_SAVEID_TOOLSTACK
>         patches?
>         
> 
>  I couldnt find anything online by this name. Can you point me to the
> patch series? 

"libxl: save/restore qemu physmap" posted last Friday.

We would also like to see the qemu restore done in a callback hook for
symmetry with the save hook.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 09:19:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09: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 1RqLTe-0002mS-Li; Thu, 26 Jan 2012 09:18: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 1RqLTc-0002m7-Pk
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:18:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327569505!8680077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25022 invoked from network); 26 Jan 2012 09:18:34 -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;
	26 Jan 2012 09:18:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10297908"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 09:18: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, 26 Jan 2012 09:18:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 26 Jan 2012 09:18:25 +0000
In-Reply-To: <CAP8mzPMed1A_BVCgoAKfcuPhRr910j8uJQFuQ_x9t9PHx0iifA@mail.gmail.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<11fb1dfda7de4d6759de.1327358786@athos.nss.cs.ubc.ca>
	<1327489725.24561.284.camel@zakaz.uk.xensource.com>
	<CAP8mzPMed1A_BVCgoAKfcuPhRr910j8uJQFuQ_x9t9PHx0iifA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327569505.26983.22.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model
 suspend/resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 23:07 +0000, Shriram Rajagopalan wrote:
> On Wed, Jan 25, 2012 at 3:08 AM, Ian Campbell 

>         > -        libxl__xs_write(gc, XBT_NULL, path, "save");
>         > -        libxl__wait_for_device_model(gc, domid, "paused",
>         NULL, NULL, NULL);
>         > +        /* For Remus,we issue suspend_qemu call separately
>         */
>         
>         
>         Why?
>         
> 
> In remus, save and transmit device model phases are decoupled. This
> code (sending the saved device model to the target) is executed after
> the domain is resumed.
> 
> The control flow in current Remus is like this:
> 1 suspend vm
>   1.1 suspend qemu (save command, that saves the device model to a
> file)
> 2 copy out dirty memory into a buffer
> 3 resume vm 
>   3.1 resume qemu
> 4 send the data in the buffer
> 5  send the saved device model
>     (xc_domain_restore extracts this from the tailbuf)

Is this basic flow incompatible with regular save? Isn't it equivalent
to to omitting phase 3? (I know regular save is structured a bit
different right now, but it could be done this way to minimise the
amount of Remus specific code).

Which "struct save_callbacks" members do each of these stages correspond
to?

I think a high level overview of the ordering of operations and the
usage of these hooks would make an ideal comment just above the
definition of "struct save_callbacks", what do you think?

>         How does this interact with Stefano's XC_SAVEID_TOOLSTACK
>         patches?
>         
> 
>  I couldnt find anything online by this name. Can you point me to the
> patch series? 

"libxl: save/restore qemu physmap" posted last Friday.

We would also like to see the qemu restore done in a callback hook for
symmetry with the save hook.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 09:22:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:22:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLWa-0002vC-8S; Thu, 26 Jan 2012 09:21:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqLWY-0002ux-2H
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327569695!12599653!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9452 invoked from network); 26 Jan 2012 09:21:36 -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;
	26 Jan 2012 09:21:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10297985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 09:21:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 09:21:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 09:21:35 +0000
In-Reply-To: <osstest-11601-mainreport@xen.org>
References: <osstest-11601-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327569695.26983.23.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] 11601: 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

On Thu, 2012-01-26 at 06:16 +0000, xen.org wrote:
[...]
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

These are all:
        2012-01-26 03:35:19 Z executing ssh ... root@10.80.249.148 xl shutdown -w win.guest.osstest
        PV control interface not available: external graceful shutdown not possible.
        Use "xl button-press <dom> power" or "xl destroy <dom>".
        shutdown failed (rc=-10)

If you are not amenable to having the harness fallback to xl
button-press/trigger power automatically how about something like the
following patch with the proviso that it is up to the harness to ensure
that a guest is configured appropriately such that ACPI power and reset
events map to shutdown and reboot respectively?

(patch applies on top of my updated"libxl: remove libxl_button_press in
favour of libxl_send_trigger" patch from earlier in the week)

Ian.

8<-------------------------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327569659 0
# Node ID c1aeef6cd4c832ddb97a7160be7ab6cb1037d3b8
# Parent  a7776e38447d4e633a45b926295f7923c046fbc9
xl: allow enable automatic fallback to ACPI events if PV control not available.

Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
reset event to be sent to the guest in the event that the guest does not
support the PV control interface.

This is not the default because the response to these triggers is an
guest-internal configuration.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a7776e38447d -r c1aeef6cd4c8 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jan 25 16:55:08 2012 +0000
+++ b/docs/man/xl.pod.1	Thu Jan 26 09:20:59 2012 +0000
@@ -365,13 +365,28 @@ domain actually reboots.
 
 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.
+to behave appropriately you may be able to use the I<-F> option
+trigger a reset 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
 domain was created.
 
+B<OPTIONS>
+
+=over 4
+
+=item B<-F>
+
+If the guest does not support PV reboot control then fallback to
+sending an ACPI power event (equivalent to the I<reset> option to
+I<trigger>.
+
+You should ensure that the guest is configured to behave as expected
+in response to this event.
+
+=back
+
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
 Build a domain from an B<xl save> state file.  See B<save> for more info.
@@ -422,8 +437,8 @@ 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.
+to behave appropriately you may be able to use the I<-F> option
+trigger a power button press.
 
 The command returns immediately after signally the domain unless that
 B<-w> flag is used.
@@ -440,6 +455,15 @@ B<OPTIONS>
 
 Wait for the domain to complete shutdown before returning.
 
+=item B<-F>
+
+If the guest does not support PV shutdown control then fallback to
+sending an ACPI power event (equivalent to the I<power> option to
+I<trigger>.
+
+You should ensure that the guest is configured to behave as expected
+in response to this event.
+
 =back
 
 =item B<sysrq> I<domain-id> I<letter>
diff -r a7776e38447d -r c1aeef6cd4c8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 26 09:20:59 2012 +0000
@@ -2259,19 +2259,24 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait)
+static void shutdown_domain(const char *p, int wait, int fallback_trigger)
 {
     int rc;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) {
-        if (rc == ERROR_NOPARAVIRT) {
+    if (rc == ERROR_NOPARAVIRT) {
+        if (fallback_trigger) {
+            fprintf(stderr, "PV control interface not available:"
+                    " sending ACPI power button event.\n");
+            rc = libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_POWER, 0);
+        } else {
             fprintf(stderr, "PV control interface not available:"
                     " external graceful shutdown not possible.\n");
-            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
-                    " \"xl destroy <dom>\".\n");
+            fprintf(stderr, "Use \"-F\" to fallback to ACPI power event.\n");
         }
+    }
+    if (rc) {
         fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
     }
 
@@ -2310,19 +2315,25 @@ static void shutdown_domain(const char *
     }
 }
 
-static void reboot_domain(const char *p)
+static void reboot_domain(const char *p, int fallback_trigger)
 {
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) {
-        if (rc == ERROR_NOPARAVIRT) {
+    if (rc == ERROR_NOPARAVIRT) {
+        if (fallback_trigger) {
+            fprintf(stderr, "PV control interface not available:"
+                    " sending ACPI reset button event.\n");
+            rc = libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_RESET, 0);
+        } else {
             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, "Use \"-F\" to fallback to ACPI reset event.\n");
         }
-        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    }
+    if (rc) {
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
+    }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)
@@ -3106,29 +3117,41 @@ int main_shutdown(int argc, char **argv)
 {
     int opt;
     int wait = 0;
-
-    while ((opt = def_getopt(argc, argv, "w", "shutdown", 1)) != -1) {
+    int fallback_trigger = 0;
+
+    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
         case 'w':
             wait = 1;
             break;
+        case 'F':
+            fallback_trigger = 1;
+            break;
         }
     }
 
-    shutdown_domain(argv[optind], wait);
+    shutdown_domain(argv[optind], wait, fallback_trigger);
     return 0;
 }
 
 int main_reboot(int argc, char **argv)
 {
     int opt;
-
-    if ((opt = def_getopt(argc, argv, "", "reboot", 1)) != -1)
-        return opt;
-
-    reboot_domain(argv[optind]);
+    int fallback_trigger = 0;
+
+    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+        case 'F':
+            fallback_trigger = 1;
+            break;
+        }
+    }
+
+    reboot_domain(argv[optind], fallback_trigger);
     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 Jan 26 09:22:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:22:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLWa-0002vC-8S; Thu, 26 Jan 2012 09:21:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqLWY-0002ux-2H
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:21:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327569695!12599653!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9452 invoked from network); 26 Jan 2012 09:21:36 -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;
	26 Jan 2012 09:21:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10297985"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 09:21:35 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 09:21:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 09:21:35 +0000
In-Reply-To: <osstest-11601-mainreport@xen.org>
References: <osstest-11601-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327569695.26983.23.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] 11601: 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

On Thu, 2012-01-26 at 06:16 +0000, xen.org wrote:
[...]
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

These are all:
        2012-01-26 03:35:19 Z executing ssh ... root@10.80.249.148 xl shutdown -w win.guest.osstest
        PV control interface not available: external graceful shutdown not possible.
        Use "xl button-press <dom> power" or "xl destroy <dom>".
        shutdown failed (rc=-10)

If you are not amenable to having the harness fallback to xl
button-press/trigger power automatically how about something like the
following patch with the proviso that it is up to the harness to ensure
that a guest is configured appropriately such that ACPI power and reset
events map to shutdown and reboot respectively?

(patch applies on top of my updated"libxl: remove libxl_button_press in
favour of libxl_send_trigger" patch from earlier in the week)

Ian.

8<-------------------------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327569659 0
# Node ID c1aeef6cd4c832ddb97a7160be7ab6cb1037d3b8
# Parent  a7776e38447d4e633a45b926295f7923c046fbc9
xl: allow enable automatic fallback to ACPI events if PV control not available.

Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
reset event to be sent to the guest in the event that the guest does not
support the PV control interface.

This is not the default because the response to these triggers is an
guest-internal configuration.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a7776e38447d -r c1aeef6cd4c8 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jan 25 16:55:08 2012 +0000
+++ b/docs/man/xl.pod.1	Thu Jan 26 09:20:59 2012 +0000
@@ -365,13 +365,28 @@ domain actually reboots.
 
 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.
+to behave appropriately you may be able to use the I<-F> option
+trigger a reset 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
 domain was created.
 
+B<OPTIONS>
+
+=over 4
+
+=item B<-F>
+
+If the guest does not support PV reboot control then fallback to
+sending an ACPI power event (equivalent to the I<reset> option to
+I<trigger>.
+
+You should ensure that the guest is configured to behave as expected
+in response to this event.
+
+=back
+
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
 Build a domain from an B<xl save> state file.  See B<save> for more info.
@@ -422,8 +437,8 @@ 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.
+to behave appropriately you may be able to use the I<-F> option
+trigger a power button press.
 
 The command returns immediately after signally the domain unless that
 B<-w> flag is used.
@@ -440,6 +455,15 @@ B<OPTIONS>
 
 Wait for the domain to complete shutdown before returning.
 
+=item B<-F>
+
+If the guest does not support PV shutdown control then fallback to
+sending an ACPI power event (equivalent to the I<power> option to
+I<trigger>.
+
+You should ensure that the guest is configured to behave as expected
+in response to this event.
+
 =back
 
 =item B<sysrq> I<domain-id> I<letter>
diff -r a7776e38447d -r c1aeef6cd4c8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 26 09:20:59 2012 +0000
@@ -2259,19 +2259,24 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait)
+static void shutdown_domain(const char *p, int wait, int fallback_trigger)
 {
     int rc;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) {
-        if (rc == ERROR_NOPARAVIRT) {
+    if (rc == ERROR_NOPARAVIRT) {
+        if (fallback_trigger) {
+            fprintf(stderr, "PV control interface not available:"
+                    " sending ACPI power button event.\n");
+            rc = libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_POWER, 0);
+        } else {
             fprintf(stderr, "PV control interface not available:"
                     " external graceful shutdown not possible.\n");
-            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
-                    " \"xl destroy <dom>\".\n");
+            fprintf(stderr, "Use \"-F\" to fallback to ACPI power event.\n");
         }
+    }
+    if (rc) {
         fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
     }
 
@@ -2310,19 +2315,25 @@ static void shutdown_domain(const char *
     }
 }
 
-static void reboot_domain(const char *p)
+static void reboot_domain(const char *p, int fallback_trigger)
 {
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) {
-        if (rc == ERROR_NOPARAVIRT) {
+    if (rc == ERROR_NOPARAVIRT) {
+        if (fallback_trigger) {
+            fprintf(stderr, "PV control interface not available:"
+                    " sending ACPI reset button event.\n");
+            rc = libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_RESET, 0);
+        } else {
             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, "Use \"-F\" to fallback to ACPI reset event.\n");
         }
-        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    }
+    if (rc) {
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
+    }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)
@@ -3106,29 +3117,41 @@ int main_shutdown(int argc, char **argv)
 {
     int opt;
     int wait = 0;
-
-    while ((opt = def_getopt(argc, argv, "w", "shutdown", 1)) != -1) {
+    int fallback_trigger = 0;
+
+    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
         case 'w':
             wait = 1;
             break;
+        case 'F':
+            fallback_trigger = 1;
+            break;
         }
     }
 
-    shutdown_domain(argv[optind], wait);
+    shutdown_domain(argv[optind], wait, fallback_trigger);
     return 0;
 }
 
 int main_reboot(int argc, char **argv)
 {
     int opt;
-
-    if ((opt = def_getopt(argc, argv, "", "reboot", 1)) != -1)
-        return opt;
-
-    reboot_domain(argv[optind]);
+    int fallback_trigger = 0;
+
+    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+        case 'F':
+            fallback_trigger = 1;
+            break;
+        }
+    }
+
+    reboot_domain(argv[optind], fallback_trigger);
     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 Jan 26 09:23:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:23:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLYC-00032C-OI; Thu, 26 Jan 2012 09:23:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqLYB-00031o-Oe
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:23:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327569797!12607212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14649 invoked from network); 26 Jan 2012 09:23: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;
	26 Jan 2012 09:23:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10298030"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 09:23:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 09:23:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 26 Jan 2012 09:23:17 +0000
In-Reply-To: <CAP8mzPNgZVUYh_Rgwsfin2-kBLniBAccrnvp6nrq0iedsQhrTQ@mail.gmail.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
	<1327490558.24561.294.camel@zakaz.uk.xensource.com>
	<CAP8mzPNgZVUYh_Rgwsfin2-kBLniBAccrnvp6nrq0iedsQhrTQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327569797.26983.25.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] tools/libxl:
 suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 23:15 +0000, Shriram Rajagopalan wrote:
> On Wed, Jan 25, 2012 at 3:22 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
>         On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
>         > # HG changeset patch
>         > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
>         > # Date 1327358640 28800
>         > # Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef
>         > # Parent  11fb1dfda7de4d6759dec87d80cd16cf137f7369
>         > tools/libxl: suspend/postflush/commit callbacks
>         >
>         >  * Add libxl callbacks for Remus checkpoint suspend,
>         postflush (aka resume)
>         >    and checkpoint commit callbacks.
>         >  * suspend callback just bounces off
>         libxl__domain_suspend_common_callback
>         >  * resume callback directly calls xc_domain_resume instead
>         of re-using
>         >    libxl_domain_resume (as the latter does not set the fast
>         suspend argument
>         >    to xc_domain_resume - aka suspend_cancel support).
>         >  * commit callback just sleeps for the checkpoint interval
>         (for the moment).
>         >
>         >  * Future patches will augument these callbacks with more
>         functionalities like
>         >    issuing network buffer plug/unplug commands, disk
>         checkpoint commands, etc.
>         >
>         > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>         >
>         
>         
>         
>         > +static int libxl__remus_domain_resume_callback(void *data)
>         > +{
>         > +    struct suspendinfo *si = data;
>         > +    libxl_ctx *ctx = libxl__gc_owner(si->gc);
>         > +
>         > +    /* Assumes that SUSPEND_CANCEL is available - just like
>         > +     * xm version of Remus. Without that, remus wont work.
>         > +     * Since libxl_domain_resume calls xc_domain_resume
>         with
>         > +     * fast_suspend = 0, we cant re-use that api.
>         
>         
>         You could modify that API which would be better than
>         duplicating its
>         content. I think the "fast" flag is useful to expose to users
>         of libxl
>         but if not then you could refactor into an internal function
>         which takes
>         the flag and call it from both here and libxl_domain_resume.
>         
>         
> 
> I didnt want to touch any existing public interfaces, structures, etc,
> especially something so common like domain_resume.

Until Xen 4.2 it is fine to improve the public interface of libxl,
including adding a new parameter here if you think that is best.

>  While users of xl resume (or unpause) wont see any difference, other
> libraries using the libxl API might be affected.

So long as they can still ask for the current behaviour that is fine.

>  But I am in favor of "exposing" the flag instead of hiding it in an
> internal function,  if there are no objections :).

None.

Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 09:23:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:23:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLYC-00032C-OI; Thu, 26 Jan 2012 09:23:24 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqLYB-00031o-Oe
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:23:23 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327569797!12607212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14649 invoked from network); 26 Jan 2012 09:23: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;
	26 Jan 2012 09:23:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10298030"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 09:23:17 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 09:23:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 26 Jan 2012 09:23:17 +0000
In-Reply-To: <CAP8mzPNgZVUYh_Rgwsfin2-kBLniBAccrnvp6nrq0iedsQhrTQ@mail.gmail.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<0446591bee86eb4e767d.1327358787@athos.nss.cs.ubc.ca>
	<1327490558.24561.294.camel@zakaz.uk.xensource.com>
	<CAP8mzPNgZVUYh_Rgwsfin2-kBLniBAccrnvp6nrq0iedsQhrTQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327569797.26983.25.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 3] tools/libxl:
 suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 23:15 +0000, Shriram Rajagopalan wrote:
> On Wed, Jan 25, 2012 at 3:22 AM, Ian Campbell
> <Ian.Campbell@citrix.com> wrote:
>         On Mon, 2012-01-23 at 22:46 +0000, rshriram@cs.ubc.ca wrote:
>         > # HG changeset patch
>         > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
>         > # Date 1327358640 28800
>         > # Node ID 0446591bee86eb4e767d75b70c885549c7a3cfef
>         > # Parent  11fb1dfda7de4d6759dec87d80cd16cf137f7369
>         > tools/libxl: suspend/postflush/commit callbacks
>         >
>         >  * Add libxl callbacks for Remus checkpoint suspend,
>         postflush (aka resume)
>         >    and checkpoint commit callbacks.
>         >  * suspend callback just bounces off
>         libxl__domain_suspend_common_callback
>         >  * resume callback directly calls xc_domain_resume instead
>         of re-using
>         >    libxl_domain_resume (as the latter does not set the fast
>         suspend argument
>         >    to xc_domain_resume - aka suspend_cancel support).
>         >  * commit callback just sleeps for the checkpoint interval
>         (for the moment).
>         >
>         >  * Future patches will augument these callbacks with more
>         functionalities like
>         >    issuing network buffer plug/unplug commands, disk
>         checkpoint commands, etc.
>         >
>         > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>         >
>         
>         
>         
>         > +static int libxl__remus_domain_resume_callback(void *data)
>         > +{
>         > +    struct suspendinfo *si = data;
>         > +    libxl_ctx *ctx = libxl__gc_owner(si->gc);
>         > +
>         > +    /* Assumes that SUSPEND_CANCEL is available - just like
>         > +     * xm version of Remus. Without that, remus wont work.
>         > +     * Since libxl_domain_resume calls xc_domain_resume
>         with
>         > +     * fast_suspend = 0, we cant re-use that api.
>         
>         
>         You could modify that API which would be better than
>         duplicating its
>         content. I think the "fast" flag is useful to expose to users
>         of libxl
>         but if not then you could refactor into an internal function
>         which takes
>         the flag and call it from both here and libxl_domain_resume.
>         
>         
> 
> I didnt want to touch any existing public interfaces, structures, etc,
> especially something so common like domain_resume.

Until Xen 4.2 it is fine to improve the public interface of libxl,
including adding a new parameter here if you think that is best.

>  While users of xl resume (or unpause) wont see any difference, other
> libraries using the libxl API might be affected.

So long as they can still ask for the current behaviour that is fine.

>  But I am in favor of "exposing" the flag instead of hiding it in an
> internal function,  if there are no objections :).

None.

Ian.





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 09:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLuv-0003g6-Na; Thu, 26 Jan 2012 09:46:53 +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 1RqLuu-0003fx-7A
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:46:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327571204!3147247!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13038 invoked from network); 26 Jan 2012 09:46:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 09:46:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327571203; l=281;
	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=2cc34LVhH5m1D5t3TdrK2Kt8l3c=;
	b=Lsh4s7Q0VgXUO5w4lmlkD9PbYN9SGEKVoBG1AEa1pII16Bgd7xJi9LcHivxJGVOp/zG
	44m/n9CkgQsz5OkoT/iPi4BS6H1RJ2HlKset5dt9f4GKDaoC7n0OZwFISF25vweW1FlmO
	QYMFiRGu+SZWxeoLCvso0eoX5gUh9hdybfA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (cohen mo14) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d05bfeo0Q8vFYj ;
	Thu, 26 Jan 2012 10:46:19 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 64BBF18637; Thu, 26 Jan 2012 10:46:21 +0100 (CET)
Date: Thu, 26 Jan 2012 10:46:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126094621.GA21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <143e4982c9bf0da5d8fe.1327550005@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix 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 Wed, Jan 25, Andres Lagar-Cavilla wrote:

> When restoring a p2m entry in the paging_load path, we were not updating the
> m2p entry correctly.

Thats a good one.

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

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 Thu Jan 26 09:47:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:47:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLuv-0003g6-Na; Thu, 26 Jan 2012 09:46:53 +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 1RqLuu-0003fx-7A
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:46:52 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327571204!3147247!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13038 invoked from network); 26 Jan 2012 09:46:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 09:46:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327571203; l=281;
	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=2cc34LVhH5m1D5t3TdrK2Kt8l3c=;
	b=Lsh4s7Q0VgXUO5w4lmlkD9PbYN9SGEKVoBG1AEa1pII16Bgd7xJi9LcHivxJGVOp/zG
	44m/n9CkgQsz5OkoT/iPi4BS6H1RJ2HlKset5dt9f4GKDaoC7n0OZwFISF25vweW1FlmO
	QYMFiRGu+SZWxeoLCvso0eoX5gUh9hdybfA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (cohen mo14) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d05bfeo0Q8vFYj ;
	Thu, 26 Jan 2012 10:46:19 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 64BBF18637; Thu, 26 Jan 2012 10:46:21 +0100 (CET)
Date: Thu, 26 Jan 2012 10:46:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126094621.GA21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <143e4982c9bf0da5d8fe.1327550005@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix 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 Wed, Jan 25, Andres Lagar-Cavilla wrote:

> When restoring a p2m entry in the paging_load path, we were not updating the
> m2p entry correctly.

Thats a good one.

> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

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 Thu Jan 26 09:47:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLvS-0003ma-4s; Thu, 26 Jan 2012 09:47:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqLvR-0003mQ-G4
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:47:25 +0000
Received: from [85.158.138.51:10961] by server-9.bemta-3.messagelabs.com id
	07/EF-31168-C21212F4; Thu, 26 Jan 2012 09:47:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327571243!10665650!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11315 invoked from network); 26 Jan 2012 09:47:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 09:47:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327571243; l=250;
	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=vmzmNtwBD60qbjgg3hr/U9yjR0o=;
	b=WUmMm//7X2UGm20fXJBgW7AKuVemHoSrOf3uATpcH5lF+Z8B6HK9E9RneZcSiHh87nC
	FNzfuxCHzrQoxof6AxP7GZrGgm9reVe3yoLWeFhgu0r+1hgV9aARHLIjxI3cxPxUguZvZ
	iwGkIumidym1+lCeU9/IeZy0UuTi2IFW0Ms=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo12) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N073ebo0Q9fXJv ;
	Thu, 26 Jan 2012 10:47:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C606018637; Thu, 26 Jan 2012 10:47:18 +0100 (CET)
Date: Thu, 26 Jan 2012 10:47:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126094718.GB21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<39e2fc847c57ba4d4a14.1327550008@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <39e2fc847c57ba4d4a14.1327550008@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 8] x86/mm: Output domain count of paged
 pages in 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

On Wed, Jan 25, Andres Lagar-Cavilla wrote:

>  xen/common/keyhandler.c |  6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

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 Thu Jan 26 09:47:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09:47:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqLvS-0003ma-4s; Thu, 26 Jan 2012 09:47:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqLvR-0003mQ-G4
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:47:25 +0000
Received: from [85.158.138.51:10961] by server-9.bemta-3.messagelabs.com id
	07/EF-31168-C21212F4; Thu, 26 Jan 2012 09:47:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327571243!10665650!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11315 invoked from network); 26 Jan 2012 09:47:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-3.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 09:47:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327571243; l=250;
	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=vmzmNtwBD60qbjgg3hr/U9yjR0o=;
	b=WUmMm//7X2UGm20fXJBgW7AKuVemHoSrOf3uATpcH5lF+Z8B6HK9E9RneZcSiHh87nC
	FNzfuxCHzrQoxof6AxP7GZrGgm9reVe3yoLWeFhgu0r+1hgV9aARHLIjxI3cxPxUguZvZ
	iwGkIumidym1+lCeU9/IeZy0UuTi2IFW0Ms=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo12) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id N073ebo0Q9fXJv ;
	Thu, 26 Jan 2012 10:47:16 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id C606018637; Thu, 26 Jan 2012 10:47:18 +0100 (CET)
Date: Thu, 26 Jan 2012 10:47:18 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126094718.GB21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<39e2fc847c57ba4d4a14.1327550008@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <39e2fc847c57ba4d4a14.1327550008@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 4 of 8] x86/mm: Output domain count of paged
 pages in 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

On Wed, Jan 25, Andres Lagar-Cavilla wrote:

>  xen/common/keyhandler.c |  6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> 
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

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 Thu Jan 26 09:54:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09: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 1RqM2E-0004GH-94; Thu, 26 Jan 2012 09:54:26 +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 1RqM2C-0004GC-Py
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:54:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327571608!51797156!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13802 invoked from network); 26 Jan 2012 09:53:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 09:53:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327571657; l=958;
	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=mv80n75p9gwPztANosuvTgMaDB8=;
	b=Etp13vfTR6KwY4FXWtPWRZ/20PzpLHA7rTasNBIrM9ajklDoEs+AvVUx4lgAjYfchvg
	X1PS3ct/N5iaHQomWe1yfUKBTIlL57tH1Pn5WKDGMZjuNeovCUpOFK3Gx5dldFLpwqyzS
	0u9Yhp0Dw0vSY++Lzj7FPbZYnmGTPZW0utQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by post.strato.de (mrclete mo35) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a013c3o0Q8a2kE ;
	Thu, 26 Jan 2012 10:53:59 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 8E76718637; Thu, 26 Jan 2012 10:54:01 +0100 (CET)
Date: Thu, 26 Jan 2012 10:54:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126095401.GC21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d4336e35f0bcb4fcb060.1327550010@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for 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 Wed, Jan 25, Andres Lagar-Cavilla wrote:

>  xen/arch/x86/mm/p2m.c |  3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> 
> If we hit the page after nominate but before paging it out, don't decrement the
> domain count of paged out pages.

The meaning of paged_pages is to track released pages.
In p2m_mem_paging_evict() it gets incremented once the page is removed
from the domain, and in p2m_mem_paging_prep() it should be decremented
right after the alloc_domheap_page() call.
So the patch should move the atomic_dec() call after successful page
allocation.

Olaf

> diff -r c41436e555cd -r d4336e35f0bc xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1041,7 +1041,8 @@ int p2m_mem_paging_prep(struct domain *d
>                      p2m_ram_rw, a);
>      set_gpfn_from_mfn(mfn_x(mfn), gfn);
>  
> -    atomic_dec(&d->paged_pages);
> +    if ( !page_extant )
> +        atomic_dec(&d->paged_pages);
>  
>      ret = 0;
>  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 09:54:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 09: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 1RqM2E-0004GH-94; Thu, 26 Jan 2012 09:54:26 +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 1RqM2C-0004GC-Py
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 09:54:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327571608!51797156!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13802 invoked from network); 26 Jan 2012 09:53:30 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 09:53:30 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327571657; l=958;
	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=mv80n75p9gwPztANosuvTgMaDB8=;
	b=Etp13vfTR6KwY4FXWtPWRZ/20PzpLHA7rTasNBIrM9ajklDoEs+AvVUx4lgAjYfchvg
	X1PS3ct/N5iaHQomWe1yfUKBTIlL57tH1Pn5WKDGMZjuNeovCUpOFK3Gx5dldFLpwqyzS
	0u9Yhp0Dw0vSY++Lzj7FPbZYnmGTPZW0utQ=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by post.strato.de (mrclete mo35) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a013c3o0Q8a2kE ;
	Thu, 26 Jan 2012 10:53:59 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 8E76718637; Thu, 26 Jan 2012 10:54:01 +0100 (CET)
Date: Thu, 26 Jan 2012 10:54:01 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126095401.GC21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <d4336e35f0bcb4fcb060.1327550010@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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for 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 Wed, Jan 25, Andres Lagar-Cavilla wrote:

>  xen/arch/x86/mm/p2m.c |  3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> 
> If we hit the page after nominate but before paging it out, don't decrement the
> domain count of paged out pages.

The meaning of paged_pages is to track released pages.
In p2m_mem_paging_evict() it gets incremented once the page is removed
from the domain, and in p2m_mem_paging_prep() it should be decremented
right after the alloc_domheap_page() call.
So the patch should move the atomic_dec() call after successful page
allocation.

Olaf

> diff -r c41436e555cd -r d4336e35f0bc xen/arch/x86/mm/p2m.c
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1041,7 +1041,8 @@ int p2m_mem_paging_prep(struct domain *d
>                      p2m_ram_rw, a);
>      set_gpfn_from_mfn(mfn_x(mfn), gfn);
>  
> -    atomic_dec(&d->paged_pages);
> +    if ( !page_extant )
> +        atomic_dec(&d->paged_pages);
>  
>      ret = 0;
>  

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:38:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMhv-0005A7-EW; Thu, 26 Jan 2012 10:37:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqMht-0005A2-VJ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:37:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327574243!12614858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3516 invoked from network); 26 Jan 2012 10:37:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 10:37:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10300204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 10: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;
	Thu, 26 Jan 2012 10:37:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 26 Jan 2012 10:37:23 +0000
In-Reply-To: <CAP8mzPN3R=39smy2Ysd1GR6LiZ6z1BnDpEwRojTNtUJkXOS1mA@mail.gmail.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
	<1327492324.24561.309.camel@zakaz.uk.xensource.com>
	<CAP8mzPN3R=39smy2Ysd1GR6LiZ6z1BnDpEwRojTNtUJkXOS1mA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327574243.26983.57.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/libxl: xl remus/remus-receive
 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 Thu, 2012-01-26 at 00:09 +0000, Shriram Rajagopalan wrote:
> On Wed, Jan 25, 2012 at 3:52 AM, Ian Campbell 
> 
> Sorry my bad. I should have sent it out as a separate patch. Well, if
> you look at the control flow in the create_domain function , you would
> realize that this is a bug.
> 
> create_domain() 
> {
>  int daemonize = dom_info->daemonize;
>  ....
>  int need_daemon = daemonize;
> 
>  restore_domain() or create_new()
> 
>  if (!daemonize && !monitor) goto out;
>  
>  if (need_daemon) {
>     fork()
>     daemon()..
>     need_daemon = 0;
>  }
>  ...
> out:
>          /* If we have daemonized then do not return to the caller -- this has
>          * already happened in the parent.
>          */
>         if ( !need_daemon )
>          exit()
> 
> }
> 
> 
> So, even if one explicitly sets daemonize to 0, the function will never return to the
> caller. I needed it to return to the caller (remus_receiver() ), to take further actions.

Makes sense.

Although the default for remus-receive should be to daemonize otherwise
when the domain is resumed you won't get any automatic reboot/shutdown
handling etc.

>         >          exit(ret);
>         >
>         >      return ret;
>         > @@ -5853,6 +5853,175 @@
>         >      return ret;
>         >  }
>         >
>         > +int main_remus_receive(int argc, char **argv)
>         
>         
>         Can this not be done as a flag to migrate-receive? Likewise is
>         there common code between the remus migrate and regular
>         migration?
>         
> 
> It can but it would basically terminate after the create_domain() call
> in the migrate_receive function. I would have to have something like
>  if (remus) {
>    dont wait for permission to start domain
>    try renaming domain
>    unpause domain
>    return
>  }

I think actually it becomes 
	if (!remus)
		wait for permission to start domain
	try renaming domain
	unpause domain

However I take your point that there isn't that much in common after
create_domain once you remove the post migration interlock protocol.

> and a bunch of if (remus) flags peppered around the migrate receive
> function.
> 
> Having it in a separate function allows me to add support for creating
> a TCP channel that receives the checkpoints,

If this is useful for Remus then I can't see any reason it wouldn't also
be useful for regular migration.

> This add hooks or call external libraries/binaries that allows the
> user to check for split-brain before resuming the domain.

Hooks are OK, if they are not used by standard migration they can be
NULL. They should of course be properly documented...

>         > +{
>         > +    int rc;
>         > +    char *migration_domname;
>         > +    struct domain_create dom_info;
>         > +
>         > +    signal(SIGPIPE, SIG_IGN);
>         > +    memset(&dom_info, 0, sizeof(dom_info));
>         > +    dom_info.debug = 1;

BTW, this should be an option.

>         > +    dom_info.no_incr_generationid = 1;
>         > +    dom_info.restore_file = "incoming checkpoint stream";
>         > +    dom_info.migrate_fd = 0; /* stdin - will change in
>         future*/
>         > +    dom_info.migration_domname_r = &migration_domname;
>         > +
>         > +    rc = create_domain(&dom_info);
>         
>         
>         I'm totally failing to see where the Remus'ness of this
>         create_domain comes from.

> dom_info.daemonize = 0, .monitor = 0 and .paused = 0;

And how do those options combine to == Remus?

migrate doesn't currently have a "paused" option but it is not beyond
the realms of possibility that such a thing might be desirable in the
future.

> As I said earlier, this part is probably the only duplication between
> migrate-receive and remus-receive. With Xend, there was no separate
> remus receiver, to control what happens on the backup host. Now that I
> have an opportunity to incorporate remus into the toolstack from
> start, I thought I will keep the remus control flow as separate as
> possible and not have to worry about breaking live migration (nor
> complicate its code).

I think this is the wrong approach and motivation. We want to combine
the two as much as possible to reduce the amount of Remus specific code
which requires maintenance. I don't think supporting Remus via the
migration code paths will unduly complicate things.

[...]

>         > +    while ((opt = def_getopt(argc, argv, "bui:s:", "remus",
>         2)) != -1) {
>         
>         
>         main_migrate handles a bunch of other options which might also
>         be
>         interesting in the Remus case? Better would be to add all this
>         as an option to the std migrate.
> 
> 
> Negative. It would look totally unintuitive to have a checkpoint
> interval option (or blackhole replication option) in a live migration
> command. To an end user, remus is just a HA system and live migration
> is for moving VMs around. What is the point in trying to educate
> him/her that remus is basically "continuous live migration" ? 

You've convinced me on the user interface point.

However I think in terms of implementation we should aim for as much
common code as possible.

Likewise even if xl remus and xl migrate are separate commands they
should support the same common options where appropriate (e.g. -F,-d,-e,
possible -C etc).

I'm undecided where *-receive (which is not user visible) should be
separate or not -- this is the sort of thing which could in principle be
negotiated as part of the protocol. Based on the above it's not clear
how much code sharing there would actually be. I expect we can revisit
this once the bits which can should be shared actually are.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:38:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:38:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMhv-0005A7-EW; Thu, 26 Jan 2012 10:37:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqMht-0005A2-VJ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:37:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327574243!12614858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3516 invoked from network); 26 Jan 2012 10:37:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 10:37:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10300204"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 10: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;
	Thu, 26 Jan 2012 10:37:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Thu, 26 Jan 2012 10:37:23 +0000
In-Reply-To: <CAP8mzPN3R=39smy2Ysd1GR6LiZ6z1BnDpEwRojTNtUJkXOS1mA@mail.gmail.com>
References: <patchbomb.1327358785@athos.nss.cs.ubc.ca>
	<822536df4aeced5aee00.1327358788@athos.nss.cs.ubc.ca>
	<1327492324.24561.309.camel@zakaz.uk.xensource.com>
	<CAP8mzPN3R=39smy2Ysd1GR6LiZ6z1BnDpEwRojTNtUJkXOS1mA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327574243.26983.57.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 3] tools/libxl: xl remus/remus-receive
 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 Thu, 2012-01-26 at 00:09 +0000, Shriram Rajagopalan wrote:
> On Wed, Jan 25, 2012 at 3:52 AM, Ian Campbell 
> 
> Sorry my bad. I should have sent it out as a separate patch. Well, if
> you look at the control flow in the create_domain function , you would
> realize that this is a bug.
> 
> create_domain() 
> {
>  int daemonize = dom_info->daemonize;
>  ....
>  int need_daemon = daemonize;
> 
>  restore_domain() or create_new()
> 
>  if (!daemonize && !monitor) goto out;
>  
>  if (need_daemon) {
>     fork()
>     daemon()..
>     need_daemon = 0;
>  }
>  ...
> out:
>          /* If we have daemonized then do not return to the caller -- this has
>          * already happened in the parent.
>          */
>         if ( !need_daemon )
>          exit()
> 
> }
> 
> 
> So, even if one explicitly sets daemonize to 0, the function will never return to the
> caller. I needed it to return to the caller (remus_receiver() ), to take further actions.

Makes sense.

Although the default for remus-receive should be to daemonize otherwise
when the domain is resumed you won't get any automatic reboot/shutdown
handling etc.

>         >          exit(ret);
>         >
>         >      return ret;
>         > @@ -5853,6 +5853,175 @@
>         >      return ret;
>         >  }
>         >
>         > +int main_remus_receive(int argc, char **argv)
>         
>         
>         Can this not be done as a flag to migrate-receive? Likewise is
>         there common code between the remus migrate and regular
>         migration?
>         
> 
> It can but it would basically terminate after the create_domain() call
> in the migrate_receive function. I would have to have something like
>  if (remus) {
>    dont wait for permission to start domain
>    try renaming domain
>    unpause domain
>    return
>  }

I think actually it becomes 
	if (!remus)
		wait for permission to start domain
	try renaming domain
	unpause domain

However I take your point that there isn't that much in common after
create_domain once you remove the post migration interlock protocol.

> and a bunch of if (remus) flags peppered around the migrate receive
> function.
> 
> Having it in a separate function allows me to add support for creating
> a TCP channel that receives the checkpoints,

If this is useful for Remus then I can't see any reason it wouldn't also
be useful for regular migration.

> This add hooks or call external libraries/binaries that allows the
> user to check for split-brain before resuming the domain.

Hooks are OK, if they are not used by standard migration they can be
NULL. They should of course be properly documented...

>         > +{
>         > +    int rc;
>         > +    char *migration_domname;
>         > +    struct domain_create dom_info;
>         > +
>         > +    signal(SIGPIPE, SIG_IGN);
>         > +    memset(&dom_info, 0, sizeof(dom_info));
>         > +    dom_info.debug = 1;

BTW, this should be an option.

>         > +    dom_info.no_incr_generationid = 1;
>         > +    dom_info.restore_file = "incoming checkpoint stream";
>         > +    dom_info.migrate_fd = 0; /* stdin - will change in
>         future*/
>         > +    dom_info.migration_domname_r = &migration_domname;
>         > +
>         > +    rc = create_domain(&dom_info);
>         
>         
>         I'm totally failing to see where the Remus'ness of this
>         create_domain comes from.

> dom_info.daemonize = 0, .monitor = 0 and .paused = 0;

And how do those options combine to == Remus?

migrate doesn't currently have a "paused" option but it is not beyond
the realms of possibility that such a thing might be desirable in the
future.

> As I said earlier, this part is probably the only duplication between
> migrate-receive and remus-receive. With Xend, there was no separate
> remus receiver, to control what happens on the backup host. Now that I
> have an opportunity to incorporate remus into the toolstack from
> start, I thought I will keep the remus control flow as separate as
> possible and not have to worry about breaking live migration (nor
> complicate its code).

I think this is the wrong approach and motivation. We want to combine
the two as much as possible to reduce the amount of Remus specific code
which requires maintenance. I don't think supporting Remus via the
migration code paths will unduly complicate things.

[...]

>         > +    while ((opt = def_getopt(argc, argv, "bui:s:", "remus",
>         2)) != -1) {
>         
>         
>         main_migrate handles a bunch of other options which might also
>         be
>         interesting in the Remus case? Better would be to add all this
>         as an option to the std migrate.
> 
> 
> Negative. It would look totally unintuitive to have a checkpoint
> interval option (or blackhole replication option) in a live migration
> command. To an end user, remus is just a HA system and live migration
> is for moving VMs around. What is the point in trying to educate
> him/her that remus is basically "continuous live migration" ? 

You've convinced me on the user interface point.

However I think in terms of implementation we should aim for as much
common code as possible.

Likewise even if xl remus and xl migrate are separate commands they
should support the same common options where appropriate (e.g. -F,-d,-e,
possible -C etc).

I'm undecided where *-receive (which is not user visible) should be
separate or not -- this is the sort of thing which could in principle be
negotiated as part of the protocol. Based on the above it's not clear
how much code sharing there would actually be. I expect we can revisit
this once the bits which can should be shared actually are.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:47:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMrZ-0005MA-HX; Thu, 26 Jan 2012 10:47:29 +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 1RqMrY-0005M4-5u
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:47:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327574841!12659670!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcyNDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18095 invoked from network); 26 Jan 2012 10:47:21 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 10:47:21 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 07A8E7EC069;
	Thu, 26 Jan 2012 02:47: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=uie0dtvBoeNUV6Aw8WCouGZvrlzrcf4mNv/pTPusOn1y
	xLfIr11Zy3aTOAwqC2RejsJEteHTkw/w+PPUDHn6w+zR4gOvsKjkPrNr9bxM6GNr
	HiTY/6mTa4apTmhDTjvO3b6veNjkJ+3g1hSvb1qEAeDnROoZB9ejpQl98cWmCUY=
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=XYwSPUzVpP2jXl8Ez/L2MFFKov4=; b=ixv+Rbsr
	dHpuVsci7w6Ejwlauxfebz+bc8heNAlkTt285RSFpwG/Y9Dva/Mjv1MsURXZP/82
	TXlX8cMojIKFzWcmkMDi5uQuf0QzGwHxv7i0ggSe7lQd5pgJepbpYwaiX1N+iEmB
	I918g3NlLFtb0fhgK/1AFHFRcgjB0SWZhLs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 8F8597EC065; 
	Thu, 26 Jan 2012 02:47:20 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 02:47:20 -0800
Message-ID: <fa3478fb74da9017012ef302f1c21dfc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126095401.GC21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
	<20120126095401.GC21629@aepfle.de>
Date: Thu, 26 Jan 2012 02:47: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: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for paged
	out 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

> On Wed, Jan 25, Andres Lagar-Cavilla wrote:
>
>>  xen/arch/x86/mm/p2m.c |  3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>>
>> If we hit the page after nominate but before paging it out, don't
>> decrement the
>> domain count of paged out pages.
>
> The meaning of paged_pages is to track released pages.
> In p2m_mem_paging_evict() it gets incremented once the page is removed
> from the domain, and in p2m_mem_paging_prep() it should be decremented
> right after the alloc_domheap_page() call.
> So the patch should move the atomic_dec() call after successful page
> allocation.
>
> Olaf

Hi Olaf,

there is a put_page in case things go wrong, after the alloc_domheap_page
call. So doing the decrement at alloc is a bit too soon.

Thanks
Andres
>
>> diff -r c41436e555cd -r d4336e35f0bc xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1041,7 +1041,8 @@ int p2m_mem_paging_prep(struct domain *d
>>                      p2m_ram_rw, a);
>>      set_gpfn_from_mfn(mfn_x(mfn), gfn);
>>
>> -    atomic_dec(&d->paged_pages);
>> +    if ( !page_extant )
>> +        atomic_dec(&d->paged_pages);
>>
>>      ret = 0;
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:47:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:47:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMrZ-0005MA-HX; Thu, 26 Jan 2012 10:47:29 +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 1RqMrY-0005M4-5u
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:47:28 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327574841!12659670!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTcyNDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18095 invoked from network); 26 Jan 2012 10:47:21 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a20.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 10:47:21 -0000
Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 07A8E7EC069;
	Thu, 26 Jan 2012 02:47: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=uie0dtvBoeNUV6Aw8WCouGZvrlzrcf4mNv/pTPusOn1y
	xLfIr11Zy3aTOAwqC2RejsJEteHTkw/w+PPUDHn6w+zR4gOvsKjkPrNr9bxM6GNr
	HiTY/6mTa4apTmhDTjvO3b6veNjkJ+3g1hSvb1qEAeDnROoZB9ejpQl98cWmCUY=
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=XYwSPUzVpP2jXl8Ez/L2MFFKov4=; b=ixv+Rbsr
	dHpuVsci7w6Ejwlauxfebz+bc8heNAlkTt285RSFpwG/Y9Dva/Mjv1MsURXZP/82
	TXlX8cMojIKFzWcmkMDi5uQuf0QzGwHxv7i0ggSe7lQd5pgJepbpYwaiX1N+iEmB
	I918g3NlLFtb0fhgK/1AFHFRcgjB0SWZhLs=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 8F8597EC065; 
	Thu, 26 Jan 2012 02:47:20 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 02:47:20 -0800
Message-ID: <fa3478fb74da9017012ef302f1c21dfc.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126095401.GC21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
	<20120126095401.GC21629@aepfle.de>
Date: Thu, 26 Jan 2012 02:47: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: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for paged
	out 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

> On Wed, Jan 25, Andres Lagar-Cavilla wrote:
>
>>  xen/arch/x86/mm/p2m.c |  3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>>
>> If we hit the page after nominate but before paging it out, don't
>> decrement the
>> domain count of paged out pages.
>
> The meaning of paged_pages is to track released pages.
> In p2m_mem_paging_evict() it gets incremented once the page is removed
> from the domain, and in p2m_mem_paging_prep() it should be decremented
> right after the alloc_domheap_page() call.
> So the patch should move the atomic_dec() call after successful page
> allocation.
>
> Olaf

Hi Olaf,

there is a put_page in case things go wrong, after the alloc_domheap_page
call. So doing the decrement at alloc is a bit too soon.

Thanks
Andres
>
>> diff -r c41436e555cd -r d4336e35f0bc xen/arch/x86/mm/p2m.c
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1041,7 +1041,8 @@ int p2m_mem_paging_prep(struct domain *d
>>                      p2m_ram_rw, a);
>>      set_gpfn_from_mfn(mfn_x(mfn), gfn);
>>
>> -    atomic_dec(&d->paged_pages);
>> +    if ( !page_extant )
>> +        atomic_dec(&d->paged_pages);
>>
>>      ret = 0;
>>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:49:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:49:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMtE-0005Zl-1f; Thu, 26 Jan 2012 10:49:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqMtB-0005Zb-Cp
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:49:10 +0000
Received: from [85.158.138.51:37649] by server-2.bemta-3.messagelabs.com id
	EB/C8-24515-4AF212F4; Thu, 26 Jan 2012 10:49:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327574947!10719303!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzkzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31503 invoked from network); 26 Jan 2012 10:49:08 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 10:49:08 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 70D5F714070;
	Thu, 26 Jan 2012 02:49:07 -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=mQFJ6zF14J/JPetUXKvEHZ01ElDx24QqXv3tnsRJoNa3
	1+dXl79dA7zn7PXFI8FJBSELskeDalzuCFS/MVGy+aWb+6EYlizxAAx1oJddR8kp
	wkjUNCZmAjuzMtTq/TYK6lofw2QNfKVFgbRrqlm07lwPzvH7oO8g9/Oc6L9hQZQ=
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=ZKmxUIwyNGMjWRVWtFu0hQTQmC8=; b=XTmz2r7q
	NN3QM2HOoZ9737Eco56NpCSx/dy8cqoM0lX96DAR0qh+rZsSu3lrhpNyuandquC4
	022mhNfYTlyjTJVtPn46tbHRmihwqDB5o5MIF4lQ/gkfj3SGiE7lsLOr2UuPsBTG
	BAQMa6JOrnFYczaTbTA914AWr3g40PN+QDU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 1B5FB71406B; 
	Thu, 26 Jan 2012 02:49:07 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 02:49:07 -0800
Message-ID: <01c35254dd14ced855caac42bdfcccf0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126094621.GA21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
	<20120126094621.GA21629@aepfle.de>
Date: Thu, 26 Jan 2012 02:49:07 -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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Jan 25, Andres Lagar-Cavilla wrote:
>
>> When restoring a p2m entry in the paging_load path, we were not updating
>> the
>> m2p entry correctly.
>
> Thats a good one.
>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Acked-by: Olaf Hering <olaf@aepfle.de>
>
Great!

Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
provide feedback as to whether
1. remove p2m_ram_paging_in
2. rename p2m_ram_paging_in_start to p2m_ram_paging_in

sounds like a good plan?

Cheers!
Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:49:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:49:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMtE-0005Zl-1f; Thu, 26 Jan 2012 10:49:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqMtB-0005Zb-Cp
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:49:10 +0000
Received: from [85.158.138.51:37649] by server-2.bemta-3.messagelabs.com id
	EB/C8-24515-4AF212F4; Thu, 26 Jan 2012 10:49:08 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327574947!10719303!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzkzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31503 invoked from network); 26 Jan 2012 10:49:08 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a12.g.dreamhost.com)
	(208.97.132.83) by server-8.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 10:49:08 -0000
Received: from homiemail-a12.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTP id 70D5F714070;
	Thu, 26 Jan 2012 02:49:07 -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=mQFJ6zF14J/JPetUXKvEHZ01ElDx24QqXv3tnsRJoNa3
	1+dXl79dA7zn7PXFI8FJBSELskeDalzuCFS/MVGy+aWb+6EYlizxAAx1oJddR8kp
	wkjUNCZmAjuzMtTq/TYK6lofw2QNfKVFgbRrqlm07lwPzvH7oO8g9/Oc6L9hQZQ=
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=ZKmxUIwyNGMjWRVWtFu0hQTQmC8=; b=XTmz2r7q
	NN3QM2HOoZ9737Eco56NpCSx/dy8cqoM0lX96DAR0qh+rZsSu3lrhpNyuandquC4
	022mhNfYTlyjTJVtPn46tbHRmihwqDB5o5MIF4lQ/gkfj3SGiE7lsLOr2UuPsBTG
	BAQMa6JOrnFYczaTbTA914AWr3g40PN+QDU=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a12.g.dreamhost.com (Postfix) with ESMTPA id 1B5FB71406B; 
	Thu, 26 Jan 2012 02:49:07 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 02:49:07 -0800
Message-ID: <01c35254dd14ced855caac42bdfcccf0.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126094621.GA21629@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
	<20120126094621.GA21629@aepfle.de>
Date: Thu, 26 Jan 2012 02:49:07 -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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Wed, Jan 25, Andres Lagar-Cavilla wrote:
>
>> When restoring a p2m entry in the paging_load path, we were not updating
>> the
>> m2p entry correctly.
>
> Thats a good one.
>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> Acked-by: Olaf Hering <olaf@aepfle.de>
>
Great!

Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
provide feedback as to whether
1. remove p2m_ram_paging_in
2. rename p2m_ram_paging_in_start to p2m_ram_paging_in

sounds like a good plan?

Cheers!
Andres



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:53:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:53:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMx2-0005rZ-N3; Thu, 26 Jan 2012 10:53:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RqMx1-0005rQ-BP
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:53:07 +0000
Received: from [85.158.138.51:10579] by server-1.bemta-3.messagelabs.com id
	A3/36-09565-290312F4; Thu, 26 Jan 2012 10:53:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327575185!10759107!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17408 invoked from network); 26 Jan 2012 10:53:05 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Jan 2012 10:53:05 -0000
Received: from mail104-db3-R.bigfish.com (10.3.81.243) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 10:53:05 +0000
Received: from mail104-db3 (localhost [127.0.0.1])	by
	mail104-db3-R.bigfish.com (Postfix) with ESMTP id 0EC0D3A03E3;
	Thu, 26 Jan 2012 10:53:05 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VPS-4(zzc85dh4015Lzz1202hzz8275bhz2dhc1bhc31hc1ahc1bhc31hc1ah668h839h34h)
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 1327575183238040_10866;
	Thu, 26 Jan 2012 10:53:03 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.252])	by
	mail104-db3.bigfish.com (Postfix) with ESMTP id 339A2400276;
	Thu, 26 Jan 2012 10:53:03 +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; Thu, 26 Jan 2012 10:53:02 +0000
X-WSS-ID: 0LYEJK8-02-H90-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 2D516C80E3;	Thu, 26 Jan 2012 04:52:55 -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;
	Thu, 26 Jan 2012 04:53:14 -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;
	Thu, 26 Jan 2012 04:52:59 -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, 26 Jan 2012
	05:52:58 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8505B49C34C; Thu, 26 Jan 2012
	10:52:57 +0000 (GMT)
Message-ID: <4F213167.3010400@amd.com>
Date: Thu, 26 Jan 2012 11:56:39 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------020609020903090001090704"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on non-iommu
	systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------020609020903090001090704
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Introduce a new flag to disable iommu emulation on old iommu systems.
This patch is taken from my v4 patch queue, which is till pending, to 
make old or non-iommu system to run cleanly without interfered by 
iommuv2 codes. This might be helpful to isolate iommuv2 code in 
debugging unstable regressions. The reset part of v4 will be re-based.

Thanks,
Wei

Signed-off-by: Wei Wang <wei.wang2@amd.com>



--------------020609020903090001090704
Content-Type: text/x-patch; name="iommuv2_flag.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="iommuv2_flag.patch"
Content-Description: iommuv2_flag.patch

diff -r a2a8089b1ffb xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 24 16:46:17 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Jan 26 11:50:02 2012 +0100
@@ -805,6 +805,9 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
+    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
+        return 0;
+
     if ( !iommu )
         return -EACCES;
 
@@ -867,7 +870,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) || !iommu_enabled || !iommuv2_enabled )
         return 0;
 
     iommu = xzalloc(struct guest_iommu);
@@ -893,7 +896,7 @@ void guest_iommu_destroy(struct domain *
 {
     struct guest_iommu *iommu;
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
         return;
 
     iommu = domain_iommu(d);
diff -r a2a8089b1ffb xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 24 16:46:17 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Jan 26 11:50:02 2012 +0100
@@ -38,6 +38,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 = 0;
 
 static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
@@ -887,6 +888,9 @@ static int __init amd_iommu_init_one(str
 
     get_iommu_features(iommu);
 
+    if ( iommu->features )
+        iommuv2_enabled = 1;
+
     if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
@@ -950,6 +954,7 @@ static void __init amd_iommu_init_cleanu
     iommu_enabled = 0;
     iommu_passthrough = 0;
     iommu_intremap = 0;
+    iommuv2_enabled = 0;
 }
 
 /*
diff -r a2a8089b1ffb xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Jan 24 16:46:17 2012 +0000
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Jan 26 11:50:02 2012 +0100
@@ -182,4 +182,6 @@ struct guest_iommu {
     struct guest_iommu_msi  msi;
 };
 
+extern bool_t iommuv2_enabled;
+
 #endif /* _ASM_X86_64_AMD_IOMMU_H */


--------------020609020903090001090704
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------020609020903090001090704--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:53:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:53:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMx2-0005rZ-N3; Thu, 26 Jan 2012 10:53:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Wei.Wang2@amd.com>) id 1RqMx1-0005rQ-BP
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:53:07 +0000
Received: from [85.158.138.51:10579] by server-1.bemta-3.messagelabs.com id
	A3/36-09565-290312F4; Thu, 26 Jan 2012 10:53:06 +0000
X-Env-Sender: Wei.Wang2@amd.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327575185!10759107!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17408 invoked from network); 26 Jan 2012 10:53:05 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE001.bigfish.com) (213.199.154.139)
	by server-9.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Jan 2012 10:53:05 -0000
Received: from mail104-db3-R.bigfish.com (10.3.81.243) by
	DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 10:53:05 +0000
Received: from mail104-db3 (localhost [127.0.0.1])	by
	mail104-db3-R.bigfish.com (Postfix) with ESMTP id 0EC0D3A03E3;
	Thu, 26 Jan 2012 10:53:05 +0000 (UTC)
X-SpamScore: -4
X-BigFish: VPS-4(zzc85dh4015Lzz1202hzz8275bhz2dhc1bhc31hc1ahc1bhc31hc1ah668h839h34h)
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 1327575183238040_10866;
	Thu, 26 Jan 2012 10:53:03 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.252])	by
	mail104-db3.bigfish.com (Postfix) with ESMTP id 339A2400276;
	Thu, 26 Jan 2012 10:53:03 +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; Thu, 26 Jan 2012 10:53:02 +0000
X-WSS-ID: 0LYEJK8-02-H90-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 2D516C80E3;	Thu, 26 Jan 2012 04:52:55 -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;
	Thu, 26 Jan 2012 04:53:14 -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;
	Thu, 26 Jan 2012 04:52:59 -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, 26 Jan 2012
	05:52:58 -0500
Received: from [165.204.15.57] (gran.osrc.amd.com [165.204.15.57])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8505B49C34C; Thu, 26 Jan 2012
	10:52:57 +0000 (GMT)
Message-ID: <4F213167.3010400@amd.com>
Date: Thu, 26 Jan 2012 11:56:39 +0100
From: Wei Wang <wei.wang2@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Keir
	Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>, Ian Campbell
	<Ian.Campbell@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Content-Type: multipart/mixed; boundary="------------020609020903090001090704"
X-OriginatorOrg: amd.com
Subject: [Xen-devel] [PATCH] amd iommu: disable iommu emulation on non-iommu
	systems
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------020609020903090001090704
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Introduce a new flag to disable iommu emulation on old iommu systems.
This patch is taken from my v4 patch queue, which is till pending, to 
make old or non-iommu system to run cleanly without interfered by 
iommuv2 codes. This might be helpful to isolate iommuv2 code in 
debugging unstable regressions. The reset part of v4 will be re-based.

Thanks,
Wei

Signed-off-by: Wei Wang <wei.wang2@amd.com>



--------------020609020903090001090704
Content-Type: text/x-patch; name="iommuv2_flag.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="iommuv2_flag.patch"
Content-Description: iommuv2_flag.patch

diff -r a2a8089b1ffb xen/drivers/passthrough/amd/iommu_guest.c
--- a/xen/drivers/passthrough/amd/iommu_guest.c	Tue Jan 24 16:46:17 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_guest.c	Thu Jan 26 11:50:02 2012 +0100
@@ -805,6 +805,9 @@ int guest_iommu_set_base(struct domain *
     p2m_type_t t;
     struct guest_iommu *iommu = domain_iommu(d);
 
+    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
+        return 0;
+
     if ( !iommu )
         return -EACCES;
 
@@ -867,7 +870,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) || !iommu_enabled || !iommuv2_enabled )
         return 0;
 
     iommu = xzalloc(struct guest_iommu);
@@ -893,7 +896,7 @@ void guest_iommu_destroy(struct domain *
 {
     struct guest_iommu *iommu;
 
-    if ( !is_hvm_domain(d) )
+    if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled )
         return;
 
     iommu = domain_iommu(d);
diff -r a2a8089b1ffb xen/drivers/passthrough/amd/iommu_init.c
--- a/xen/drivers/passthrough/amd/iommu_init.c	Tue Jan 24 16:46:17 2012 +0000
+++ b/xen/drivers/passthrough/amd/iommu_init.c	Thu Jan 26 11:50:02 2012 +0100
@@ -38,6 +38,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 = 0;
 
 static int iommu_has_ht_flag(struct amd_iommu *iommu, u8 mask)
 {
@@ -887,6 +888,9 @@ static int __init amd_iommu_init_one(str
 
     get_iommu_features(iommu);
 
+    if ( iommu->features )
+        iommuv2_enabled = 1;
+
     if ( allocate_cmd_buffer(iommu) == NULL )
         goto error_out;
 
@@ -950,6 +954,7 @@ static void __init amd_iommu_init_cleanu
     iommu_enabled = 0;
     iommu_passthrough = 0;
     iommu_intremap = 0;
+    iommuv2_enabled = 0;
 }
 
 /*
diff -r a2a8089b1ffb xen/include/asm-x86/amd-iommu.h
--- a/xen/include/asm-x86/amd-iommu.h	Tue Jan 24 16:46:17 2012 +0000
+++ b/xen/include/asm-x86/amd-iommu.h	Thu Jan 26 11:50:02 2012 +0100
@@ -182,4 +182,6 @@ struct guest_iommu {
     struct guest_iommu_msi  msi;
 };
 
+extern bool_t iommuv2_enabled;
+
 #endif /* _ASM_X86_64_AMD_IOMMU_H */


--------------020609020903090001090704
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------020609020903090001090704--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:55:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMyi-0005zH-VP; Thu, 26 Jan 2012 10:54: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 1RqMyg-0005yb-E6
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:54:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327575283!12661733!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4MTU5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25475 invoked from network); 26 Jan 2012 10:54:44 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-5.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 10:54:44 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 295B41A8083;
	Thu, 26 Jan 2012 02:54: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=YVOuoQaX55hkCJxnz3Xq97XjT78AKoiHOLvTeU3z6E/N
	uXq625wiOjLAq5Xc0zL8a51ROewB8Xr76BO663wzVY6grv+cd8BasrZ6sg8O5/s3
	nuc2tgSJJPzGY4F3e9w3rraGRGeiY00TbFeRFdaUnntE7ugfQ+tAgh9yndJmnjY=
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=qllfWSabfHrgNVDz7eNY9rM8HmU=; b=KrjgKcBH
	dMIok56iuMXAYSFp1zLvJ0DjgLYgX9gSnxkjmNRubkGTumPUQsZH/0Q6Tx5bQ1kY
	5OPxHEETM8c/ez518Lp51EDC3TcrjtdpWSPd7mczGkP96RfqYY3TgBaYNJ/dTE2e
	XSV1C4zEeK2BwCl046tV0HkkEZoAlmyHSL4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id D5B341A8063; 
	Thu, 26 Jan 2012 02:54:42 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 02:54:43 -0800
Message-ID: <8e3be650305a4d7539c144716ad42840.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.761.1326908012.1471.xen-devel@lists.xensource.com>
References: <mailman.761.1326908012.1471.xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 02:54:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: fix error handling in
	xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Wed, 18 Jan 2012 18:15:24 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] tools/libxc: fix error handling in
> 	xc_mem_paging_load
> Message-ID: <1821b0e1ce16d0015542.1326906924@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1326906775 -3600
> # Node ID 1821b0e1ce16d0015542d4164505d97f130f09d7
> # Parent  15ab61865ecbd146f6ce65fbea5bf49bfd9c6cb1
> tools/libxc: fix error handling in xc_mem_paging_load
>
> xc_mem_paging_load() does not pass errors in errno and the actual errno
> from xc_mem_event_control() is overwritten by munlock().
> xenpaging_populate_page() needs to check errno, but with the switch to
> xc_mem_paging_load() it could not receive ENOMEM anymore.
>
> Update xc_mem_paging_load() to return -1 and preserve errno during
> munlock().
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Bump on this one. It's a simple and necessary fix.
And:
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks,
Andres
>
> diff -r 15ab61865ecb -r 1821b0e1ce16 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -68,23 +68,28 @@ int xc_mem_paging_prep(xc_interface *xch
>  int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
>                                  unsigned long gfn, void *buffer)
>  {
> -    int rc;
> +    int rc, old_errno;
> +
> +    errno = -EINVAL;
>
>      if ( !buffer )
> -        return -EINVAL;
> +        return -1;
>
>      if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
> -        return -EINVAL;
> +        return -1;
>
>      if ( mlock(buffer, XC_PAGE_SIZE) )
> -        return -errno;
> +        return -1;
>
>      rc = xc_mem_event_control(xch, domain_id,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>                                  buffer, NULL, gfn);
>
> -    (void)munlock(buffer, XC_PAGE_SIZE);
> +    old_errno = errno;
> +    munlock(buffer, XC_PAGE_SIZE);
> +    errno = old_errno;
> +
>      return rc;
>  }
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Jan 2012 17:13:31 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in
> 	minios stubdom
> Message-ID: <20246.64955.717774.909586@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/18] xenstored: support
> running in minios stubdom"):
>> One thing which might help is to provide nop versions of functions
>> instead of idef'ing both the definition and callsite. e.g.
>>  static void write_pidfile(const char *pidfile)
>> +#ifndef __MINIOS__
>>      stuff
>> +#else
>> +    nothing
>> +endif
>
> I would normally prefer:
>
>> +#ifndef __MINIOS__
>>  static void write_pidfile(const char *pidfile)
>>      stuff
>>  }
>> +#else
>> +static void write_pidfile(const char *pidfile)
>> +}
>> +endif
>
> I think this is fairly easy to read; the only hard part is figuring
> out which version is being used, which can often be done by putting
> the relevant bits in a separate file.
>
> Ian.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 18 Jan 2012 17:33:24 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 3/9] libxl: New event generation API
> Message-ID: <1326908004.14689.296.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 2012-01-13 at 19:25 +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.
>>
>> The new "libxl_event" structure is blacklisted in the ocaml bindings
>> for two reasons:
>>   - It has a field name "type" (which is a keyword in ocaml);
>>     the ocaml idl generator should massage this field name on
>>     output, to "type_" perhaps.
>>   - The ocaml idl generator does not support KeyedUnion.
>>
>> 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      |  236 ++++++++++++++++++++++++++---
>>  tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
>>  tools/libxl/libxl_internal.h   |   77 +++++++++-
>>  tools/libxl/libxl_types.idl    |   34 ++++-
>>  tools/libxl/xl_cmdimpl.c       |  270 +++++++++++++++++++--------------
>>  tools/ocaml/libs/xl/genwrap.py |    1 +
>>  8 files changed, 908 insertions(+), 277 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 413b684..19ff12c 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -95,6 +115,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);
>
> Why a helper for deaths but not ejects?
>
> [...]
>
>> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
>> index ec66340..621a7cc 100644
>> --- a/tools/libxl/libxl_event.c
>> +++ b/tools/libxl/libxl_event.c
>
>>
>>  /*
>> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
>> index 63ef65e..0e83800 100644
>> --- a/tools/libxl/libxl_event.h
>> +++ b/tools/libxl/libxl_event.h
>
>> +#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;
>
> libxl_event_{wait,check} and LIBXL_EVENTMASK_ALL have an unsigned long
> mask. Are they not the same set of bits?
>
> [...]
>
>> + * 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.
>
> Does anything actually guarantee that sizeof(uint64_t) >
> sizeof(intptr_t)? I'm sure it's true in practice and I'm happy to rely
> on it. Just interested.
>
>> + *[...]
>
>> + * 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.  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.
>> + */
> [...]
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index 574dec7..a6dac79 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
>>      ("extratime", integer),
>>      ("weight", integer),
>>      ], dispose_fn=None)
>> +
>> +libxl_event_type = Enumeration("event_type", [
>> +    (1, "DOMAIN_SHUTDOWN"),
>> +    (2, "DOMAIN_DESTROY"),
>> +    (3, "DISK_EJECT"),
>> +    ])
>> +
>> +libxl_ev_user = UInt(64)
>
> The other option here would be Builtin(...) and an entry in the builtin
> table in the wrapper generator.
>
> Arguably the idl could be improved by causing Number() to have a width
> field. Currently it has a signedness and width is a property of UInt but
> the latter could be pushed up the hierarchy.
>
> You'd still end up with
> 	FOO = Number("FOO", width=X)
> which isn't really much better.
>
> Or the ocaml generate could handle Number as the biggest int.
>
> Hrm. None of that seems all that much better than what you have. Chalk
> it up to potential future work.
>
>> +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE,
>> private=True)
>> +
>> +libxl_event = Struct("event",[
>> +    ("link",     libxl_ev_link,0),
>
> This "0" == "const=False" which is the default. I don't think it is
> necessary.
>
> [...]
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 8c30de1..e292bfc 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>
>> @@ -1702,92 +1729,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);
>
> I didn't see this getting freed on the exit path.
>
>> +        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;
>> +    }
>
> This is all (I think) safe for num_disks == 0 but why waste the effort?
>
> Incidentally we have libxl_device_disk.removable which might be an
> opportunity to optimise? Assuming it is meaningful in that way. I think
> in reality only emulated CD-ROM devices ever generate this event but
> perhaps exposing that in the API overcomplicates things.
>
> [...]
>
> Ian.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 288
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 10:55:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 10:55:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqMyi-0005zH-VP; Thu, 26 Jan 2012 10:54: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 1RqMyg-0005yb-E6
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 10:54:50 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327575283!12661733!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4MTU5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25475 invoked from network); 26 Jan 2012 10:54:44 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a22.g.dreamhost.com)
	(208.97.132.5) by server-5.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 10:54:44 -0000
Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 295B41A8083;
	Thu, 26 Jan 2012 02:54: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=YVOuoQaX55hkCJxnz3Xq97XjT78AKoiHOLvTeU3z6E/N
	uXq625wiOjLAq5Xc0zL8a51ROewB8Xr76BO663wzVY6grv+cd8BasrZ6sg8O5/s3
	nuc2tgSJJPzGY4F3e9w3rraGRGeiY00TbFeRFdaUnntE7ugfQ+tAgh9yndJmnjY=
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=qllfWSabfHrgNVDz7eNY9rM8HmU=; b=KrjgKcBH
	dMIok56iuMXAYSFp1zLvJ0DjgLYgX9gSnxkjmNRubkGTumPUQsZH/0Q6Tx5bQ1kY
	5OPxHEETM8c/ez518Lp51EDC3TcrjtdpWSPd7mczGkP96RfqYY3TgBaYNJ/dTE2e
	XSV1C4zEeK2BwCl046tV0HkkEZoAlmyHSL4=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id D5B341A8063; 
	Thu, 26 Jan 2012 02:54:42 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 02:54:43 -0800
Message-ID: <8e3be650305a4d7539c144716ad42840.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.761.1326908012.1471.xen-devel@lists.xensource.com>
References: <mailman.761.1326908012.1471.xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 02:54:43 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: olaf@aepfle.de, tim@xen.org, ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: fix error handling in
	xc_mem_paging_load
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Date: Wed, 18 Jan 2012 18:15:24 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] tools/libxc: fix error handling in
> 	xc_mem_paging_load
> Message-ID: <1821b0e1ce16d0015542.1326906924@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1326906775 -3600
> # Node ID 1821b0e1ce16d0015542d4164505d97f130f09d7
> # Parent  15ab61865ecbd146f6ce65fbea5bf49bfd9c6cb1
> tools/libxc: fix error handling in xc_mem_paging_load
>
> xc_mem_paging_load() does not pass errors in errno and the actual errno
> from xc_mem_event_control() is overwritten by munlock().
> xenpaging_populate_page() needs to check errno, but with the switch to
> xc_mem_paging_load() it could not receive ENOMEM anymore.
>
> Update xc_mem_paging_load() to return -1 and preserve errno during
> munlock().
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Bump on this one. It's a simple and necessary fix.
And:
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks,
Andres
>
> diff -r 15ab61865ecb -r 1821b0e1ce16 tools/libxc/xc_mem_paging.c
> --- a/tools/libxc/xc_mem_paging.c
> +++ b/tools/libxc/xc_mem_paging.c
> @@ -68,23 +68,28 @@ int xc_mem_paging_prep(xc_interface *xch
>  int xc_mem_paging_load(xc_interface *xch, domid_t domain_id,
>                                  unsigned long gfn, void *buffer)
>  {
> -    int rc;
> +    int rc, old_errno;
> +
> +    errno = -EINVAL;
>
>      if ( !buffer )
> -        return -EINVAL;
> +        return -1;
>
>      if ( ((unsigned long) buffer) & (XC_PAGE_SIZE - 1) )
> -        return -EINVAL;
> +        return -1;
>
>      if ( mlock(buffer, XC_PAGE_SIZE) )
> -        return -errno;
> +        return -1;
>
>      rc = xc_mem_event_control(xch, domain_id,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
>                                  XEN_DOMCTL_MEM_EVENT_OP_PAGING,
>                                  buffer, NULL, gfn);
>
> -    (void)munlock(buffer, XC_PAGE_SIZE);
> +    old_errno = errno;
> +    munlock(buffer, XC_PAGE_SIZE);
> +    errno = old_errno;
> +
>      return rc;
>  }
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Jan 2012 17:13:31 +0000
> From: Ian Jackson <Ian.Jackson@eu.citrix.com>
> To: Ian Campbell <Ian.Campbell@citrix.com>
> Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
> 	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 13/18] xenstored: support running in
> 	minios stubdom
> Message-ID: <20246.64955.717774.909586@mariner.uk.xensource.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13/18] xenstored: support
> running in minios stubdom"):
>> One thing which might help is to provide nop versions of functions
>> instead of idef'ing both the definition and callsite. e.g.
>>  static void write_pidfile(const char *pidfile)
>> +#ifndef __MINIOS__
>>      stuff
>> +#else
>> +    nothing
>> +endif
>
> I would normally prefer:
>
>> +#ifndef __MINIOS__
>>  static void write_pidfile(const char *pidfile)
>>      stuff
>>  }
>> +#else
>> +static void write_pidfile(const char *pidfile)
>> +}
>> +endif
>
> I think this is fairly easy to read; the only hard part is figuring
> out which version is being used, which can often be done by putting
> the relevant bits in a separate file.
>
> Ian.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 18 Jan 2012 17:33:24 +0000
> From: Ian Campbell <Ian.Campbell@citrix.com>
> To: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
> Subject: Re: [Xen-devel] [PATCH 3/9] libxl: New event generation API
> Message-ID: <1326908004.14689.296.camel@zakaz.uk.xensource.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Fri, 2012-01-13 at 19:25 +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.
>>
>> The new "libxl_event" structure is blacklisted in the ocaml bindings
>> for two reasons:
>>   - It has a field name "type" (which is a keyword in ocaml);
>>     the ocaml idl generator should massage this field name on
>>     output, to "type_" perhaps.
>>   - The ocaml idl generator does not support KeyedUnion.
>>
>> 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      |  236 ++++++++++++++++++++++++++---
>>  tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
>>  tools/libxl/libxl_internal.h   |   77 +++++++++-
>>  tools/libxl/libxl_types.idl    |   34 ++++-
>>  tools/libxl/xl_cmdimpl.c       |  270 +++++++++++++++++++--------------
>>  tools/ocaml/libs/xl/genwrap.py |    1 +
>>  8 files changed, 908 insertions(+), 277 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index 413b684..19ff12c 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -95,6 +115,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);
>
> Why a helper for deaths but not ejects?
>
> [...]
>
>> diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
>> index ec66340..621a7cc 100644
>> --- a/tools/libxl/libxl_event.c
>> +++ b/tools/libxl/libxl_event.c
>
>>
>>  /*
>> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
>> index 63ef65e..0e83800 100644
>> --- a/tools/libxl/libxl_event.h
>> +++ b/tools/libxl/libxl_event.h
>
>> +#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;
>
> libxl_event_{wait,check} and LIBXL_EVENTMASK_ALL have an unsigned long
> mask. Are they not the same set of bits?
>
> [...]
>
>> + * 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.
>
> Does anything actually guarantee that sizeof(uint64_t) >
> sizeof(intptr_t)? I'm sure it's true in practice and I'm happy to rely
> on it. Just interested.
>
>> + *[...]
>
>> + * 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.  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.
>> + */
> [...]
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index 574dec7..a6dac79 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
>>      ("extratime", integer),
>>      ("weight", integer),
>>      ], dispose_fn=None)
>> +
>> +libxl_event_type = Enumeration("event_type", [
>> +    (1, "DOMAIN_SHUTDOWN"),
>> +    (2, "DOMAIN_DESTROY"),
>> +    (3, "DISK_EJECT"),
>> +    ])
>> +
>> +libxl_ev_user = UInt(64)
>
> The other option here would be Builtin(...) and an entry in the builtin
> table in the wrapper generator.
>
> Arguably the idl could be improved by causing Number() to have a width
> field. Currently it has a signedness and width is a property of UInt but
> the latter could be pushed up the hierarchy.
>
> You'd still end up with
> 	FOO = Number("FOO", width=X)
> which isn't really much better.
>
> Or the ocaml generate could handle Number as the biggest int.
>
> Hrm. None of that seems all that much better than what you have. Chalk
> it up to potential future work.
>
>> +libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE,
>> private=True)
>> +
>> +libxl_event = Struct("event",[
>> +    ("link",     libxl_ev_link,0),
>
> This "0" == "const=False" which is the default. I don't think it is
> necessary.
>
> [...]
>> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> index 8c30de1..e292bfc 100644
>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>
>> @@ -1702,92 +1729,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);
>
> I didn't see this getting freed on the exit path.
>
>> +        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;
>> +    }
>
> This is all (I think) safe for num_disks == 0 but why waste the effort?
>
> Incidentally we have libxl_device_disk.removable which might be an
> opportunity to optimise? Assuming it is meaningful in that way. I think
> in reality only emulated CD-ROM devices ever generate this event but
> perhaps exposing that in the API overcomplicates things.
>
> [...]
>
> Ian.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
> End of Xen-devel Digest, Vol 83, Issue 288
> ******************************************
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 11:31:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 11:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqNY2-0007GC-02; Thu, 26 Jan 2012 11:31:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqNY0-0007G3-4L
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 11:31:20 +0000
Received: from [85.158.138.51:43873] by server-8.bemta-3.messagelabs.com id
	86/0D-31878-789312F4; Thu, 26 Jan 2012 11:31:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327577478!10548265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18982 invoked from network); 26 Jan 2012 11:31:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 11:31:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10301684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 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;
	Thu, 26 Jan 2012 11:31:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Florian Heigl <florian.heigl@gmail.com>
Date: Thu, 26 Jan 2012 11:31:18 +0000
In-Reply-To: <CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510462.24561.351.camel@zakaz.uk.xensource.com>
	<CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327577478.26983.73.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Sandi
	Romih <romihs.forums@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Doug Magee <djmagee@mageenet.net>, Konrad
	Rzeszutek Wilk <konrad@darnok.org>,
	Likarpenkov Alexander <al@ohosting.org.ua>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 19:43 +0000, Florian Heigl wrote:
> How about if we assemble a list of Xen features in xm/xend and those
> that you have implemented in xl. Right now it's just guesswork and a
> lot double effort since one doesn't just have to track which parts are
> gone, but we even have to constantly read all threads on the lists to
> find out if a feature is suddenly coming back or being deprecated.

I agree that a list of features which xl supports would be a useful
thing to have. I have just made a start on updating
http://wiki.xen.org/wiki/XL with such a list (as well as some more
highlevel blurb). Further contributions welcomed ;-)

However I don't think it will be feasible or useful to construct a list
of all the features of xm/xend, since there is no one around who knows
what they all are. Even if we did we would have to know which of them
were actually useful to users (some are obvious) and which would be a
wasted effort (which could be better spent elsewhere) to reimplement.

Therefore we chose to go straight to the horses mouth and ask users to
try xl and report which features that they actually use and require are
missing. IIRC we have been doing this since the early 4.1 rc's, have
continued to do so throughout the 4.2 development cycle and will no
doubt continue to to do so through the 4.3 release cycle, if not beyond.

Perhaps we need to be a bit more vocal to our users about the "report
missing features which you require" part of this.

I should note that we are not aiming for 100% feature parity between xl
and xend. As I discussed above some features of xend are unused and
there are others (the main one being managed domains) which we have
explicitly decided that xl will not support.

As with all Open Source software there is also an element of scratching
one's own itch here. We are trying to respond to user requests and as
the xl feature-set rounds out we will no doubt be considering more and
more "minority" features but there are only so many of us and only so
many hours in the day. So ultimately if you need or want a feature then
we are more than happy to accept new features which people feel are
valuable and to help with the work that might be necessary.

[...]

> But maybe we can have a somewhat reliable roadmap where one can see xm
> will be kicked in 4.4 *and* we're planning to have the following 1234
> features supported by then.
> That way interested parties have a chance to put ressources into
> getting missing features "back in" 

>From this point of view you should assume that xend has already gone and
put resources into this _now_, there is no reason to wait for some
arbitrary deadline.

Once we are satisfied that we have covered the necessary and desirable
use cases will we actually remove xend. It is very likely that this will
happen soon.

Even though xend is still in tree it is unmaintained and deprecated and
we strongly recommend that users switch to xl and give us feedback where
features are found to be lacking.

In contrast xl was production ready in 4.1 and will continue to gain
features in 4.2 and beyond.

[...]

> p.s.: I am aware I will have to make up for this mail in beer once
> there is an opportunity.

I will certainly take you up on that ;-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 11:31:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 11:31:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqNY2-0007GC-02; Thu, 26 Jan 2012 11:31:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqNY0-0007G3-4L
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 11:31:20 +0000
Received: from [85.158.138.51:43873] by server-8.bemta-3.messagelabs.com id
	86/0D-31878-789312F4; Thu, 26 Jan 2012 11:31:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327577478!10548265!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18982 invoked from network); 26 Jan 2012 11:31:19 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 11:31:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,573,1320624000"; d="scan'208";a="10301684"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 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;
	Thu, 26 Jan 2012 11:31:18 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Florian Heigl <florian.heigl@gmail.com>
Date: Thu, 26 Jan 2012 11:31:18 +0000
In-Reply-To: <CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510462.24561.351.camel@zakaz.uk.xensource.com>
	<CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327577478.26983.73.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Sandi
	Romih <romihs.forums@gmail.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Doug Magee <djmagee@mageenet.net>, Konrad
	Rzeszutek Wilk <konrad@darnok.org>,
	Likarpenkov Alexander <al@ohosting.org.ua>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-25 at 19:43 +0000, Florian Heigl wrote:
> How about if we assemble a list of Xen features in xm/xend and those
> that you have implemented in xl. Right now it's just guesswork and a
> lot double effort since one doesn't just have to track which parts are
> gone, but we even have to constantly read all threads on the lists to
> find out if a feature is suddenly coming back or being deprecated.

I agree that a list of features which xl supports would be a useful
thing to have. I have just made a start on updating
http://wiki.xen.org/wiki/XL with such a list (as well as some more
highlevel blurb). Further contributions welcomed ;-)

However I don't think it will be feasible or useful to construct a list
of all the features of xm/xend, since there is no one around who knows
what they all are. Even if we did we would have to know which of them
were actually useful to users (some are obvious) and which would be a
wasted effort (which could be better spent elsewhere) to reimplement.

Therefore we chose to go straight to the horses mouth and ask users to
try xl and report which features that they actually use and require are
missing. IIRC we have been doing this since the early 4.1 rc's, have
continued to do so throughout the 4.2 development cycle and will no
doubt continue to to do so through the 4.3 release cycle, if not beyond.

Perhaps we need to be a bit more vocal to our users about the "report
missing features which you require" part of this.

I should note that we are not aiming for 100% feature parity between xl
and xend. As I discussed above some features of xend are unused and
there are others (the main one being managed domains) which we have
explicitly decided that xl will not support.

As with all Open Source software there is also an element of scratching
one's own itch here. We are trying to respond to user requests and as
the xl feature-set rounds out we will no doubt be considering more and
more "minority" features but there are only so many of us and only so
many hours in the day. So ultimately if you need or want a feature then
we are more than happy to accept new features which people feel are
valuable and to help with the work that might be necessary.

[...]

> But maybe we can have a somewhat reliable roadmap where one can see xm
> will be kicked in 4.4 *and* we're planning to have the following 1234
> features supported by then.
> That way interested parties have a chance to put ressources into
> getting missing features "back in" 

>From this point of view you should assume that xend has already gone and
put resources into this _now_, there is no reason to wait for some
arbitrary deadline.

Once we are satisfied that we have covered the necessary and desirable
use cases will we actually remove xend. It is very likely that this will
happen soon.

Even though xend is still in tree it is unmaintained and deprecated and
we strongly recommend that users switch to xl and give us feedback where
features are found to be lacking.

In contrast xl was production ready in 4.1 and will continue to gain
features in 4.2 and beyond.

[...]

> p.s.: I am aware I will have to make up for this mail in beer once
> there is an opportunity.

I will certainly take you up on that ;-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 11:49:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 11:49:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqNoq-00087d-EL; Thu, 26 Jan 2012 11:48:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqNoo-00087V-V7; Thu, 26 Jan 2012 11:48:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327578516!12661404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6245 invoked from network); 26 Jan 2012 11:48:36 -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;
	26 Jan 2012 11:48:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10302299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:48:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 11:48:36 +0000
Date: Thu, 26 Jan 2012 11:49:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Florian Heigl <florian.heigl@gmail.com>
In-Reply-To: <CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201261055360.3196@kaball-desktop>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510462.24561.351.camel@zakaz.uk.xensource.com>
	<CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
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>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Likarpenkov Alexander <al@ohosting.org.ua>,
	Doug Magee <djmagee@mageenet.net>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Florian Heigl wrote:
> > This was announced in the Xen 4.1 release notes[1] and the upgrade
> > guide[2]. In Xen 4.2 we have ended up formally deprecating xend rather
> > than removing it but you should expect that xend will be removed in a
> > future release of Xen and begin planning your transition to xl (or one
> > of the other alternative toolstacks), testing the features which matter
> > to you and reporting bugs/submitting patches as appropriate.
> 
> I think it would be a nice move if this wasn't just left to us users,
> especially since it is a process of suddenly finding missing parts or
> large changes in functionality in something like an easter egg hunt.
> 
> How about if we assemble a list of Xen features in xm/xend and those
> that you have implemented in xl. Right now it's just guesswork and a
> lot double effort since one doesn't just have to track which parts are
> gone, but we even have to constantly read all threads on the lists to
> find out if a feature is suddenly coming back or being deprecated.

The only features that we know are missing in Xl, and we have no current
plan of implementing them, are in the list below.
Please do tell if you find any other features that you need, currently
in xend, but missing in Xl.


> i.e. take something like Remus that had officially become a part of
> Xen some time back but isn't possible to use with PV domUs with any
> reasonable amount of effort. And not by formal decision, after a
> "heads up" mail, but just by chance. A few months I was still thinking
> I would be able to use it in a hosting product but "whoops" not
> working anymore.

Now we are more agressive at deprecating components that haven't been
properly maintained.
In the case of Remus, fortunately Shriram stepped up to the task.


> Back to xl:
> Probably noone really objects removing xm by now since it's not really
> working anymore once the system has xl support and the two are not
> compatible. It has to be in everyones interest that there is no
> unneeded code to maintain and that the core devs LIKE that code and
> that people can rely on it being maintained for the years to come.
> It doesn't matter if we type 'xl' or 'xm', it has to *work* :)
> 
> But maybe we can have a somewhat reliable roadmap where one can see xm
> will be kicked in 4.4 *and* we're planning to have the following 1234
> features supported by then.
> That way interested parties have a chance to put ressources into
> getting missing features "back in" and other projects know how much
> time they have to clean up their code. I.e. cobbler/koan is suddenly
> broken after 4 years and people can't install domUs anymore. :)

This is a reasonable request.
I would also like to mention that we have a wiki page regarding
migration to 4.1 with a few notes about Xl:
http://wiki.xen.org/xenwiki/MigrationGuideToXen4.1%2B
Also Ian just wrote an Xl feature list:
http://wiki.xen.org/wiki/XL


Features missing in Xl, with no current plan to introduce them (as usual
contributions are welcome and encouraged):

- python support in VM config files;
- an RPC interface;
- managed domain;
- pv-usb;
- netchannel2;
- pv-scsi;


Features missing in Xl, work in progress:

- Remus;
- machine parsable output from xl create.



Considering that pv-usb, pv-scsi and netchannel2 are not upstream in
Linux, the only feature that I believe people might miss is managed
domains. However it should be pretty easy to script that feature on top
of Xl and I believe that Debian might even be already doing something
like that with xend.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 11:49:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 11:49:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqNoq-00087d-EL; Thu, 26 Jan 2012 11:48:44 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqNoo-00087V-V7; Thu, 26 Jan 2012 11:48:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327578516!12661404!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6245 invoked from network); 26 Jan 2012 11:48:36 -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;
	26 Jan 2012 11:48:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10302299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:48:36 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 11:48:36 +0000
Date: Thu, 26 Jan 2012 11:49:24 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Florian Heigl <florian.heigl@gmail.com>
In-Reply-To: <CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201261055360.3196@kaball-desktop>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>
	<1327318778.24561.74.camel@zakaz.uk.xensource.com>
	<201201231417.43018.tobias.geiger@vido.info>
	<20120124015021.GB24204@andromeda.dapyr.net>
	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>
	<3758972BBA474BCBB9CA5D1D316892E7@nobody>
	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>
	<EE3AE950D047481283FF742510029D1E@nobody>
	<1327510462.24561.351.camel@zakaz.uk.xensource.com>
	<CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
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>,
	Sandi Romih <romihs.forums@gmail.com>, chris <tknchris@gmail.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Likarpenkov Alexander <al@ohosting.org.ua>,
	Doug Magee <djmagee@mageenet.net>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Florian Heigl wrote:
> > This was announced in the Xen 4.1 release notes[1] and the upgrade
> > guide[2]. In Xen 4.2 we have ended up formally deprecating xend rather
> > than removing it but you should expect that xend will be removed in a
> > future release of Xen and begin planning your transition to xl (or one
> > of the other alternative toolstacks), testing the features which matter
> > to you and reporting bugs/submitting patches as appropriate.
> 
> I think it would be a nice move if this wasn't just left to us users,
> especially since it is a process of suddenly finding missing parts or
> large changes in functionality in something like an easter egg hunt.
> 
> How about if we assemble a list of Xen features in xm/xend and those
> that you have implemented in xl. Right now it's just guesswork and a
> lot double effort since one doesn't just have to track which parts are
> gone, but we even have to constantly read all threads on the lists to
> find out if a feature is suddenly coming back or being deprecated.

The only features that we know are missing in Xl, and we have no current
plan of implementing them, are in the list below.
Please do tell if you find any other features that you need, currently
in xend, but missing in Xl.


> i.e. take something like Remus that had officially become a part of
> Xen some time back but isn't possible to use with PV domUs with any
> reasonable amount of effort. And not by formal decision, after a
> "heads up" mail, but just by chance. A few months I was still thinking
> I would be able to use it in a hosting product but "whoops" not
> working anymore.

Now we are more agressive at deprecating components that haven't been
properly maintained.
In the case of Remus, fortunately Shriram stepped up to the task.


> Back to xl:
> Probably noone really objects removing xm by now since it's not really
> working anymore once the system has xl support and the two are not
> compatible. It has to be in everyones interest that there is no
> unneeded code to maintain and that the core devs LIKE that code and
> that people can rely on it being maintained for the years to come.
> It doesn't matter if we type 'xl' or 'xm', it has to *work* :)
> 
> But maybe we can have a somewhat reliable roadmap where one can see xm
> will be kicked in 4.4 *and* we're planning to have the following 1234
> features supported by then.
> That way interested parties have a chance to put ressources into
> getting missing features "back in" and other projects know how much
> time they have to clean up their code. I.e. cobbler/koan is suddenly
> broken after 4 years and people can't install domUs anymore. :)

This is a reasonable request.
I would also like to mention that we have a wiki page regarding
migration to 4.1 with a few notes about Xl:
http://wiki.xen.org/xenwiki/MigrationGuideToXen4.1%2B
Also Ian just wrote an Xl feature list:
http://wiki.xen.org/wiki/XL


Features missing in Xl, with no current plan to introduce them (as usual
contributions are welcome and encouraged):

- python support in VM config files;
- an RPC interface;
- managed domain;
- pv-usb;
- netchannel2;
- pv-scsi;


Features missing in Xl, work in progress:

- Remus;
- machine parsable output from xl create.



Considering that pv-usb, pv-scsi and netchannel2 are not upstream in
Linux, the only feature that I believe people might miss is managed
domains. However it should be pretty easy to script that feature on top
of Xl and I believe that Debian might even be already doing something
like that with xend.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 11:49:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 11:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqNpc-0008B0-Mu; Thu, 26 Jan 2012 11:49: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 1RqNpb-0008AU-21; Thu, 26 Jan 2012 11:49:31 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327578564!12672299!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12530 invoked from network); 26 Jan 2012 11:49:24 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-9.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 11:49:24 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 057EFD347C3;
	Thu, 26 Jan 2012 12:49:23 +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 U5A4c0Ay+nXl; Thu, 26 Jan 2012 12:49:20 +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 05B38D346AA;
	Thu, 26 Jan 2012 12:49:20 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Doug Magee <djmagee@mageenet.net>
Date: Thu, 26 Jan 2012 12:49:18 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201251039.54148.tobias.geiger@vido.info>
	<1327512187.2452.28.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327512187.2452.28.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201261249.19142.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGksCgp5ZXMsIG15IE1vdGhlcmJvYXJkIChEWDU4U08pIGFubm91bmNlcyAiRkxSIENhcGFiaWxp
dHkiIC0gYXQgbGVhc3QgaXQncyBhY3RpdmUgCmluIEJJT1M6CgpCSU9TOgpYRCBUZWNobm9sb2d5
IDxFbmFibGU+CkludGVsIFZUICAgICAgICAgICA8RW5hYmxlPgpJbnRlbCBWVCBmb3IgRGlyZWN0
IEkvTyAoVlQtZCkgPEVuYWJsZT4KSW50ZXJydXB0IFJlbWFwcGluZyA8RW5hYmxlPgpGTFIgQ2Fw
YWJpbGl0eSA8RW5hYmxlPgoKQnV0IGxzcGNpIC12diBzaG93cyBmb3IgdGhlIEFUSSBDYXJkOgog
ICAgICAgICAgICAgICAgICAgICAgICBFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQoKCk9UT0ggeW91ciBsc3BjaSBhbHNvIHNob3dzICJGTFJlc2V0LSIgLSBi
dXQgRG9tVSBSZWJvb3RzIHdvcmsgZm9yIHlvdSwgc28gdGhpcyAKbWlnaHQgbm90IGJlIHRoZSBj
YXVzZSBvZiBteSBwcm9ibGVtLi4uLgoKClVudGlsIG5vdyAoYXMgeW91IHNhaWQgaXRzIHdvcmtp
bmcgaW4geW91ciBzZXR1cCkgaSB0aG91Z2h0IGl0IGhhcyBzb21ldGhpbmcgCnRvIGRvIHdpdGgg
dGhlICIgRkxSIGNvbXBsaWNhdGlvbiIgLCBtYWlubHkgIuKAkyBOZWVkIHRvIHNhdmUvcmVzdG9y
ZSBjZXJ0YWluIApNTUlPIHJlZ2lzdGVycyBhY3Jvc3MgRkxS4oCZcyIgLSAgQWxsZW4gTS4gS2F5
IG1lbnRpb25zIG9uIFBhZ2UgMTEgb2YgdGhpcyBTbGlkZSAKaGVyZToKaHR0cDovL3d3dy5saW51
eC1rdm0ub3JnL3dpa2kvaW1hZ2VzL2IvYmUvMjAxMS1mb3J1bS0lMjRncmFwaGljcy1kaXJlY3Qt
CmFzc2lnbm1lbnQucGRmCgpCdXQgdGhhdHMganVzdCBhIHdpbGQgZ3Vlc3MgYnkgbWUgLi4uCgpB
bnkgb3RoZXIgaGludHMvdGhvdWdodHMgb24gdGhpcz8KCkdyZWV0aW5ncyEKVG9iaWFzCgoKQW0g
TWl0dHdvY2gsIDI1LiBKYW51YXIgMjAxMiwgMTg6MjM6MDcgc2NocmllYiBEb3VnIE1hZ2VlOgo+
IE9uIFdlZCwgMjAxMi0wMS0yNSBhdCAwNDozOSAtMDUwMCwgVG9iaWFzIEdlaWdlciB3cm90ZToK
PiA+IEhlbGxvIERvdWchCj4gPiAKPiA+IHNlZSBiZWxvdyAuLi4uCj4gPiAKPiA+IEFtIERpZW5z
dGFnLCAyNC4gSmFudWFyIDIwMTIsIDE5OjMxOjQ1IHNjaHJpZWIgRG91ZyBNYWdlZToKPiA+ID4g
T24gVHVlLCAyMDEyLTAxLTI0IGF0IDA5OjM3IC0wNTAwLCBUb2JpYXMgR2VpZ2VyIHdyb3RlOgo+
ID4gPiA+ID4gPiA+IEJvdGggc2V0dXAgaGF2ZSB0aGUgImZsYXciIHRoYXQgdGhleSBvbmx5IHdv
cmsgb25jZSAtCj4gPiAKPiA+IG1lYW5pbmcKPiA+IAo+ID4gPiA+IHlvdQo+ID4gPiA+IAo+ID4g
PiA+ID4gPiBjYW4ndCByZWJvb3QKPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4geW91ciBEb21V
ICwgY2F1c2UgYWZ0ZXIgdGhlIHJlYm9vdCB0aGUgcGFzc2VkLXRocm91Z2ggQ2FyZAo+ID4gPiA+
IAo+ID4gPiA+IGRvZXNudAo+ID4gPiA+IAo+ID4gPiA+ID4gPiBoYXZlIGNvcnJlY3QKPiA+ID4g
PiA+ID4gCj4gPiA+ID4gPiA+ID4gM0QtQWNjZWxsZXJhdGlvbiBhbnkgbW9yZSAod2FzL2lzIHRo
ZSBjYXNlIHdpdGggTlZJRElBIGFuZAo+ID4gCj4gPiBBVEksCj4gPiAKPiA+ID4gPiA+ID4gV2lu
ZG93cyBYUCBhbmQKPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gV2luZG93czcgKQo+ID4gPiA+
ID4gPiAKPiA+ID4gPiA+ID4gRm9yIG1lIGl0IHdhcyB3aXRoIEFUSSB3aXRoIFdpbmRvd3M3LiBI
YWRuJ3QgdHJpZWQgb3RoZXIgT1Nlcy4KPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+IEFueWJvZHkg
aGFkIGx1Y2sgd2l0aCBwYXNzaW5nIHRoZSBjYXJkIG1vcmUgdGhhbiBvbmNlIHRvIGEKPiA+IAo+
ID4gZ3Vlc3Q/Cj4gPiAKPiA+ID4gPiBXaXRoCj4gPiA+ID4gCj4gPiA+ID4gPiA+IGFueSByYW5k
b20gc2V0IG9mIHBhdGNoZXM/Cj4gPiA+ID4gCj4gPiA+ID4gSSB3YXMgYSBiaXQgdW4tcGVyY2lj
ZSByZWdhcmRpbmcgdGhlICJyZWJvb3QiIGlzc3VlOgo+ID4gPiA+IAo+ID4gPiA+IFRoZSBwYXNz
aW5nLXRocm91Z2ggaXRzZWxmIHdvcmtzIGV2ZW4gYWZ0ZXIgYSByZWJvb3Qgb2YgRG9tVSAtIHRo
ZQo+ID4gPiA+IHJlYm9vdGVkCj4gPiA+ID4gU3lzdGVtIHNwaXRzIG91dCBpdHMgR3JhcGhpY3Mg
bm9ybWFseSB0aHJvdWdoIHRoZSBwYXNzZWQtdGhyb3VnaAo+ID4gCj4gPiBDYXJkCj4gPiAKPiA+
ID4gPiAoTlZJREEKPiA+ID4gPiBvciBBVEkgZG9lc250IG1hdHRlciBoZXJlKSA7IEJVVDoKPiA+
ID4gPiBBZnRlciBhIHJlYm9vdCBpdCBkb2Vzbid0IHdvcmsgcHJvcGVybHkuIE1lYW5pbmc6IFNs
b3cgM2QKPiA+IAo+ID4gUGVyZm9ybWFuY2UsCj4gPiAKPiA+ID4gPiBpLmUuCj4gPiA+ID4gdW5z
YWJsZSBmb3IgcmVhbCAzZCBhcHBzLCBldmVuIGEgM2QgRGVza3RvcDsKPiA+ID4gPiBGb3IgZXhh
bXBsZSwgd2hlbiB0aGUgQ2FyZCBnaXZlcyB5b3UgNzBmcHMgaW4gYSBCZW5jaG1hcmsgYWZ0ZXIg
YQo+ID4gPiA+IGZyZXNoIENvbGQKPiA+ID4gPiBCb290LCBpdCBvbmx5IGdpdmVzIHlvdSA1LTEw
ZnBzIGFmdGVyIGEgcmVib290LCB0aGlzIHdpbGwgYmUgdGhhdAo+ID4gCj4gPiBsb3cKPiA+IAo+
ID4gPiA+IHVudGlsCj4gPiA+ID4geW91IHJlYm9vdCBEb20wIGFsc28sIG5vdCBvbmx5IERvbVU7
Cj4gPiA+ID4gCj4gPiA+ID4gaG9wZWZ1bGx5IGkgZGVzY3JpYmVkIHRoZSBzY2VuYXJpbyBiZXR0
ZXIgbm93Li4uCj4gPiA+IAo+ID4gPiBBaCwgZ290IGl0LiAgSSBoYWRuJ3QgYmVlbiBkb2luZyBh
bnl0aGluZyAzRCBpbnRlbnNpdmUsIG9ubHkgcnVubmluZwo+ID4gCj4gPiB0aGUKPiA+IAo+ID4g
PiBBZXJvIGRlc2t0b3AuICBJIGluc3RhbGxlZCAzRE1hcmsgVmFudGFnZSBhbmQgcmFuIGEgY291
cGxlIG9mIHRlc3RzLgo+ID4gCj4gPiBJCj4gPiAKPiA+ID4gZ2V0IHRoZSBzYW1lIHJlc3VsdHMg
KHdpdGhpbiBhIGZyYWN0aW9uIG9mIGEgJSkgYWZ0ZXIgYSBjb2xkIGJvb3QgYXMKPiA+IAo+ID4g
aQo+ID4gCj4gPiA+IGRvIGFmdGVyIHJlYm9vdGluZyBtdWx0aXBsZSB0aW1lcywgYW5kIGFsd2F5
cyB2ZXJ5IGNsb3NlIHRvIG5hdGl2ZS4KPiA+IAo+ID4gSXQKPiA+IAo+ID4gPiBzZWVtcyBpIGRv
bid0IGhhdmUgdGhlIHByb2JsZW0geW91J3JlIGhhdmluZy4KPiA+ID4gCj4gPiA+IERvIHlvdSBn
ZXQgYW55IGRpZmZlcmVudCBsb2cgbWVzc2FnZXMgYWZ0ZXIgYSByZWJvb3QgKHhsIGRtZXNnLCBk
b20wCj4gPiA+IGRtZXNnLCBxZW11IGxvZyk/ICBIYXZlIHlvdSB0cmllZCB3aXRoIGlvbW11PXZl
cmJvc2UgdG8gc2VlIGlmCj4gPiAKPiA+IHRoZXJlJ3MKPiA+IAo+ID4gPiBhbnkgbW9yZSB1c2Vm
dWwgaW5mb3JtYXRpb24gdGhlcmU/Cj4gPiAKPiA+IENvb2wuIEZpbmFsbHkgc29tZW9uZSBOT1Qg
c3VmZmVyaW5nIHRoZQo+ID4gcmVib290LXBlcmZvcm1hbmNlLXJlZ3Jlc3Npb24tUHJvYmxlbQo+
ID4gCj4gPiA6KQo+ID4gCj4gPiBJIHNlYXJjaGVkIGJhY2sgYW5kIGZvcnRoLCByZWJvb3RlZCBE
b21VIGxpa2UgY3JhenksIGRpZmYnZWQgdGhlCj4gPiBkbWVzZy94bGRtZXNnL3FlbXUtZG0gLSBi
dXQgbm8gZGlmZmVyZW5jZSA6KAo+ID4gCj4gPiBXaGF0IGtpbmQgb2YgQVRJIENhcmQgYXJlIHlv
dSBwYXNzaW5nIHRocm91Z2g/Cj4gCj4gSXQncyBhbiBISVMgaW5jYXJuYXRpb24gb2YgdGhlIFJh
ZGVvbiA0NzcwLiBsc3BjaSAtdnZ2IG91dHB1dCBhdCB0aGUKPiBib3R0b20gb2YgdGhlIG1lc3Nh
Z2UuCj4gCj4gPiBXb3VsZCBiZSBuaWNlIHRvIGZpbmQgb3V0IHdoYXRzIGNhdXNpbmcgdGhpcy4u
Lgo+IAo+IERvZXMgeW91ciBkZXZpY2UvYnVzIHN1cHBvcnQgRkxSPyAgRG8geW91IGdldCBhbnkg
bWVzc2FnZXMgbGlrZSB0aGUKPiBmb2xsb3dpbmcgd2hlbiB5b3UgdXNlIHhsIGNyZWF0ZS94bCBw
Y2ktYXR0YWNoPwo+IAo+IGxpYnhsOiBlcnJvcjogbGlieGxfcGNpLmM6Li4uIFRoZSBrZXJuZWwg
ZG9lc24ndCBzdXBwb3J0IHJlc2V0IGZyb20KPiBzeXNmcyBmb3IgUENJIGRldmljZSAuLi4KPiAK
PiA+IEdyZWV0aW5ncyEKPiA+IFRvYmlhcwo+IAo+IDAxOjAwLjAgVkdBIGNvbXBhdGlibGUgY29u
dHJvbGxlcjogQVRJIFRlY2hub2xvZ2llcyBJbmMgUmFkZW9uIEhEIDQ3NzAKPiBbUlY3NDBdIChw
cm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pCj4gCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIDBkMDAKPiAJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLQo+IFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQo+IAlTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LQo+IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0KPiAJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwo+IAlJbnRlcnJ1cHQ6
IHBpbiBBIHJvdXRlZCB0byBJUlEgMTYKPiAJUmVnaW9uIDA6IE1lbW9yeSBhdCBkMDAwMDAwMCAo
NjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTI1Nk1dCj4gCVJlZ2lvbiAyOiBNZW1vcnkgYXQg
ZmJiMjAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NjRLXQo+IAlSZWdpb24g
NDogSS9PIHBvcnRzIGF0IGUwMDAgW3NpemU9MjU2XQo+IAlFeHBhbnNpb24gUk9NIGF0IGZiYjAw
MDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10KPiAJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1h
bmFnZW1lbnQgdmVyc2lvbiAzCj4gCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3Vy
cmVudD0wbUEKPiBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCj4gCQlTdGF0dXM6IEQw
IE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KPiAJQ2FwYWJpbGl0
aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdhY3kgRW5kcG9pbnQsIE1TSSAwMAo+IAkJRGV2Q2Fw
OglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw0dXMsIEwx
Cj4gdW5saW1pdGVkCj4gCQkJRXh0VGFnKyBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsg
RkxSZXNldC0KPiAJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRh
bC0gRmF0YWwtIApVbnN1cHBvcnRlZC0KPiAJCQlSbHhkT3JkLSBFeHRUYWcrIFBoYW50RnVuYy0g
QXV4UHdyLSBOb1Nub29wKwo+IAkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEy
OCBieXRlcwo+IAkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS
ZXEtIEF1eFB3ci0gClRyYW5zUGVuZC0KPiAJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAKPiA8NjRucywgTDEgPDF1cwo+IAkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtCj4gCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKPiAJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCj4gCQlMbmtTdGE6CVNw
ZWVkIDVHVC9zLCBXaWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtCj4g
QldNZ210LSBBQldNZ210LQo+IAkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3Vw
cG9ydGVkLCBUaW1lb3V0RGlzLQo+IAkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVz
IHRvIDUwbXMsIFRpbWVvdXREaXMtCj4gCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdU
L3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLAo+IFNlbGVjdGFibGUgRGUtZW1waGFzaXM6
IC02ZEIKPiAJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCAKRW50
ZXJNb2RpZmllZENvbXBsaWFuY2UtCj4gQ29tcGxpYW5jZVNPUy0KPiAJCQkgQ29tcGxpYW5jZSBE
ZS1lbXBoYXNpczogLTZkQgo+IAkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDog
LTZkQgo+IAlDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQrCj4gCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAwNDM4ICBEYXRhOiAwMDAwCj4gCUNh
cGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAx
IFJldj0xCj4gTGVuPTAxMCA8Pz4KPiAJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sKPiAJ
S2VybmVsIG1vZHVsZXM6IHJhZGVvbgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 26 11:49:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 11:49:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqNpc-0008B0-Mu; Thu, 26 Jan 2012 11:49: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 1RqNpb-0008AU-21; Thu, 26 Jan 2012 11:49:31 +0000
X-Env-Sender: tobias.geiger@vido.info
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327578564!12672299!1
X-Originating-IP: [78.47.43.171]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12530 invoked from network); 26 Jan 2012 11:49:24 -0000
Received: from www.vido.info (HELO mail.vido.info) (78.47.43.171)
	by server-9.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 11:49:24 -0000
Received: from localhost (ip6-localhost [127.0.0.1])
	by mail.vido.info (Postfix) with ESMTP id 057EFD347C3;
	Thu, 26 Jan 2012 12:49:23 +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 U5A4c0Ay+nXl; Thu, 26 Jan 2012 12:49:20 +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 05B38D346AA;
	Thu, 26 Jan 2012 12:49:20 +0100 (CET)
From: Tobias Geiger <tobias.geiger@vido.info>
Organization: VIDO IT-Service
To: Doug Magee <djmagee@mageenet.net>
Date: Thu, 26 Jan 2012 12:49:18 +0100
User-Agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<201201251039.54148.tobias.geiger@vido.info>
	<1327512187.2452.28.camel@mnetdjm5.mageenet.host>
In-Reply-To: <1327512187.2452.28.camel@mnetdjm5.mageenet.host>
MIME-Version: 1.0
Message-Id: <201201261249.19142.tobias.geiger@vido.info>
Cc: xen-devel@lists.xensource.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>, xen-users@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad@darnok.org>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGksCgp5ZXMsIG15IE1vdGhlcmJvYXJkIChEWDU4U08pIGFubm91bmNlcyAiRkxSIENhcGFiaWxp
dHkiIC0gYXQgbGVhc3QgaXQncyBhY3RpdmUgCmluIEJJT1M6CgpCSU9TOgpYRCBUZWNobm9sb2d5
IDxFbmFibGU+CkludGVsIFZUICAgICAgICAgICA8RW5hYmxlPgpJbnRlbCBWVCBmb3IgRGlyZWN0
IEkvTyAoVlQtZCkgPEVuYWJsZT4KSW50ZXJydXB0IFJlbWFwcGluZyA8RW5hYmxlPgpGTFIgQ2Fw
YWJpbGl0eSA8RW5hYmxlPgoKQnV0IGxzcGNpIC12diBzaG93cyBmb3IgdGhlIEFUSSBDYXJkOgog
ICAgICAgICAgICAgICAgICAgICAgICBFeHRUYWcrIEF0dG5CdG4tIEF0dG5JbmQtIFB3ckluZC0g
UkJFKyBGTFJlc2V0LQoKCk9UT0ggeW91ciBsc3BjaSBhbHNvIHNob3dzICJGTFJlc2V0LSIgLSBi
dXQgRG9tVSBSZWJvb3RzIHdvcmsgZm9yIHlvdSwgc28gdGhpcyAKbWlnaHQgbm90IGJlIHRoZSBj
YXVzZSBvZiBteSBwcm9ibGVtLi4uLgoKClVudGlsIG5vdyAoYXMgeW91IHNhaWQgaXRzIHdvcmtp
bmcgaW4geW91ciBzZXR1cCkgaSB0aG91Z2h0IGl0IGhhcyBzb21ldGhpbmcgCnRvIGRvIHdpdGgg
dGhlICIgRkxSIGNvbXBsaWNhdGlvbiIgLCBtYWlubHkgIuKAkyBOZWVkIHRvIHNhdmUvcmVzdG9y
ZSBjZXJ0YWluIApNTUlPIHJlZ2lzdGVycyBhY3Jvc3MgRkxS4oCZcyIgLSAgQWxsZW4gTS4gS2F5
IG1lbnRpb25zIG9uIFBhZ2UgMTEgb2YgdGhpcyBTbGlkZSAKaGVyZToKaHR0cDovL3d3dy5saW51
eC1rdm0ub3JnL3dpa2kvaW1hZ2VzL2IvYmUvMjAxMS1mb3J1bS0lMjRncmFwaGljcy1kaXJlY3Qt
CmFzc2lnbm1lbnQucGRmCgpCdXQgdGhhdHMganVzdCBhIHdpbGQgZ3Vlc3MgYnkgbWUgLi4uCgpB
bnkgb3RoZXIgaGludHMvdGhvdWdodHMgb24gdGhpcz8KCkdyZWV0aW5ncyEKVG9iaWFzCgoKQW0g
TWl0dHdvY2gsIDI1LiBKYW51YXIgMjAxMiwgMTg6MjM6MDcgc2NocmllYiBEb3VnIE1hZ2VlOgo+
IE9uIFdlZCwgMjAxMi0wMS0yNSBhdCAwNDozOSAtMDUwMCwgVG9iaWFzIEdlaWdlciB3cm90ZToK
PiA+IEhlbGxvIERvdWchCj4gPiAKPiA+IHNlZSBiZWxvdyAuLi4uCj4gPiAKPiA+IEFtIERpZW5z
dGFnLCAyNC4gSmFudWFyIDIwMTIsIDE5OjMxOjQ1IHNjaHJpZWIgRG91ZyBNYWdlZToKPiA+ID4g
T24gVHVlLCAyMDEyLTAxLTI0IGF0IDA5OjM3IC0wNTAwLCBUb2JpYXMgR2VpZ2VyIHdyb3RlOgo+
ID4gPiA+ID4gPiA+IEJvdGggc2V0dXAgaGF2ZSB0aGUgImZsYXciIHRoYXQgdGhleSBvbmx5IHdv
cmsgb25jZSAtCj4gPiAKPiA+IG1lYW5pbmcKPiA+IAo+ID4gPiA+IHlvdQo+ID4gPiA+IAo+ID4g
PiA+ID4gPiBjYW4ndCByZWJvb3QKPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4geW91ciBEb21V
ICwgY2F1c2UgYWZ0ZXIgdGhlIHJlYm9vdCB0aGUgcGFzc2VkLXRocm91Z2ggQ2FyZAo+ID4gPiA+
IAo+ID4gPiA+IGRvZXNudAo+ID4gPiA+IAo+ID4gPiA+ID4gPiBoYXZlIGNvcnJlY3QKPiA+ID4g
PiA+ID4gCj4gPiA+ID4gPiA+ID4gM0QtQWNjZWxsZXJhdGlvbiBhbnkgbW9yZSAod2FzL2lzIHRo
ZSBjYXNlIHdpdGggTlZJRElBIGFuZAo+ID4gCj4gPiBBVEksCj4gPiAKPiA+ID4gPiA+ID4gV2lu
ZG93cyBYUCBhbmQKPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gV2luZG93czcgKQo+ID4gPiA+
ID4gPiAKPiA+ID4gPiA+ID4gRm9yIG1lIGl0IHdhcyB3aXRoIEFUSSB3aXRoIFdpbmRvd3M3LiBI
YWRuJ3QgdHJpZWQgb3RoZXIgT1Nlcy4KPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+IEFueWJvZHkg
aGFkIGx1Y2sgd2l0aCBwYXNzaW5nIHRoZSBjYXJkIG1vcmUgdGhhbiBvbmNlIHRvIGEKPiA+IAo+
ID4gZ3Vlc3Q/Cj4gPiAKPiA+ID4gPiBXaXRoCj4gPiA+ID4gCj4gPiA+ID4gPiA+IGFueSByYW5k
b20gc2V0IG9mIHBhdGNoZXM/Cj4gPiA+ID4gCj4gPiA+ID4gSSB3YXMgYSBiaXQgdW4tcGVyY2lj
ZSByZWdhcmRpbmcgdGhlICJyZWJvb3QiIGlzc3VlOgo+ID4gPiA+IAo+ID4gPiA+IFRoZSBwYXNz
aW5nLXRocm91Z2ggaXRzZWxmIHdvcmtzIGV2ZW4gYWZ0ZXIgYSByZWJvb3Qgb2YgRG9tVSAtIHRo
ZQo+ID4gPiA+IHJlYm9vdGVkCj4gPiA+ID4gU3lzdGVtIHNwaXRzIG91dCBpdHMgR3JhcGhpY3Mg
bm9ybWFseSB0aHJvdWdoIHRoZSBwYXNzZWQtdGhyb3VnaAo+ID4gCj4gPiBDYXJkCj4gPiAKPiA+
ID4gPiAoTlZJREEKPiA+ID4gPiBvciBBVEkgZG9lc250IG1hdHRlciBoZXJlKSA7IEJVVDoKPiA+
ID4gPiBBZnRlciBhIHJlYm9vdCBpdCBkb2Vzbid0IHdvcmsgcHJvcGVybHkuIE1lYW5pbmc6IFNs
b3cgM2QKPiA+IAo+ID4gUGVyZm9ybWFuY2UsCj4gPiAKPiA+ID4gPiBpLmUuCj4gPiA+ID4gdW5z
YWJsZSBmb3IgcmVhbCAzZCBhcHBzLCBldmVuIGEgM2QgRGVza3RvcDsKPiA+ID4gPiBGb3IgZXhh
bXBsZSwgd2hlbiB0aGUgQ2FyZCBnaXZlcyB5b3UgNzBmcHMgaW4gYSBCZW5jaG1hcmsgYWZ0ZXIg
YQo+ID4gPiA+IGZyZXNoIENvbGQKPiA+ID4gPiBCb290LCBpdCBvbmx5IGdpdmVzIHlvdSA1LTEw
ZnBzIGFmdGVyIGEgcmVib290LCB0aGlzIHdpbGwgYmUgdGhhdAo+ID4gCj4gPiBsb3cKPiA+IAo+
ID4gPiA+IHVudGlsCj4gPiA+ID4geW91IHJlYm9vdCBEb20wIGFsc28sIG5vdCBvbmx5IERvbVU7
Cj4gPiA+ID4gCj4gPiA+ID4gaG9wZWZ1bGx5IGkgZGVzY3JpYmVkIHRoZSBzY2VuYXJpbyBiZXR0
ZXIgbm93Li4uCj4gPiA+IAo+ID4gPiBBaCwgZ290IGl0LiAgSSBoYWRuJ3QgYmVlbiBkb2luZyBh
bnl0aGluZyAzRCBpbnRlbnNpdmUsIG9ubHkgcnVubmluZwo+ID4gCj4gPiB0aGUKPiA+IAo+ID4g
PiBBZXJvIGRlc2t0b3AuICBJIGluc3RhbGxlZCAzRE1hcmsgVmFudGFnZSBhbmQgcmFuIGEgY291
cGxlIG9mIHRlc3RzLgo+ID4gCj4gPiBJCj4gPiAKPiA+ID4gZ2V0IHRoZSBzYW1lIHJlc3VsdHMg
KHdpdGhpbiBhIGZyYWN0aW9uIG9mIGEgJSkgYWZ0ZXIgYSBjb2xkIGJvb3QgYXMKPiA+IAo+ID4g
aQo+ID4gCj4gPiA+IGRvIGFmdGVyIHJlYm9vdGluZyBtdWx0aXBsZSB0aW1lcywgYW5kIGFsd2F5
cyB2ZXJ5IGNsb3NlIHRvIG5hdGl2ZS4KPiA+IAo+ID4gSXQKPiA+IAo+ID4gPiBzZWVtcyBpIGRv
bid0IGhhdmUgdGhlIHByb2JsZW0geW91J3JlIGhhdmluZy4KPiA+ID4gCj4gPiA+IERvIHlvdSBn
ZXQgYW55IGRpZmZlcmVudCBsb2cgbWVzc2FnZXMgYWZ0ZXIgYSByZWJvb3QgKHhsIGRtZXNnLCBk
b20wCj4gPiA+IGRtZXNnLCBxZW11IGxvZyk/ICBIYXZlIHlvdSB0cmllZCB3aXRoIGlvbW11PXZl
cmJvc2UgdG8gc2VlIGlmCj4gPiAKPiA+IHRoZXJlJ3MKPiA+IAo+ID4gPiBhbnkgbW9yZSB1c2Vm
dWwgaW5mb3JtYXRpb24gdGhlcmU/Cj4gPiAKPiA+IENvb2wuIEZpbmFsbHkgc29tZW9uZSBOT1Qg
c3VmZmVyaW5nIHRoZQo+ID4gcmVib290LXBlcmZvcm1hbmNlLXJlZ3Jlc3Npb24tUHJvYmxlbQo+
ID4gCj4gPiA6KQo+ID4gCj4gPiBJIHNlYXJjaGVkIGJhY2sgYW5kIGZvcnRoLCByZWJvb3RlZCBE
b21VIGxpa2UgY3JhenksIGRpZmYnZWQgdGhlCj4gPiBkbWVzZy94bGRtZXNnL3FlbXUtZG0gLSBi
dXQgbm8gZGlmZmVyZW5jZSA6KAo+ID4gCj4gPiBXaGF0IGtpbmQgb2YgQVRJIENhcmQgYXJlIHlv
dSBwYXNzaW5nIHRocm91Z2g/Cj4gCj4gSXQncyBhbiBISVMgaW5jYXJuYXRpb24gb2YgdGhlIFJh
ZGVvbiA0NzcwLiBsc3BjaSAtdnZ2IG91dHB1dCBhdCB0aGUKPiBib3R0b20gb2YgdGhlIG1lc3Nh
Z2UuCj4gCj4gPiBXb3VsZCBiZSBuaWNlIHRvIGZpbmQgb3V0IHdoYXRzIGNhdXNpbmcgdGhpcy4u
Lgo+IAo+IERvZXMgeW91ciBkZXZpY2UvYnVzIHN1cHBvcnQgRkxSPyAgRG8geW91IGdldCBhbnkg
bWVzc2FnZXMgbGlrZSB0aGUKPiBmb2xsb3dpbmcgd2hlbiB5b3UgdXNlIHhsIGNyZWF0ZS94bCBw
Y2ktYXR0YWNoPwo+IAo+IGxpYnhsOiBlcnJvcjogbGlieGxfcGNpLmM6Li4uIFRoZSBrZXJuZWwg
ZG9lc24ndCBzdXBwb3J0IHJlc2V0IGZyb20KPiBzeXNmcyBmb3IgUENJIGRldmljZSAuLi4KPiAK
PiA+IEdyZWV0aW5ncyEKPiA+IFRvYmlhcwo+IAo+IDAxOjAwLjAgVkdBIGNvbXBhdGlibGUgY29u
dHJvbGxlcjogQVRJIFRlY2hub2xvZ2llcyBJbmMgUmFkZW9uIEhEIDQ3NzAKPiBbUlY3NDBdIChw
cm9nLWlmIDAwIFtWR0EgY29udHJvbGxlcl0pCj4gCVN1YnN5c3RlbTogQVRJIFRlY2hub2xvZ2ll
cyBJbmMgRGV2aWNlIDBkMDAKPiAJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5
Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLQo+IFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJC
LSBEaXNJTlR4LQo+IAlTdGF0dXM6IENhcCsgNjZNSHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBE
RVZTRUw9ZmFzdCA+VEFib3J0LSA8VEFib3J0LQo+IDxNQWJvcnQtID5TRVJSLSA8UEVSUi0gSU5U
eC0KPiAJTGF0ZW5jeTogMCwgQ2FjaGUgTGluZSBTaXplOiA2NCBieXRlcwo+IAlJbnRlcnJ1cHQ6
IHBpbiBBIHJvdXRlZCB0byBJUlEgMTYKPiAJUmVnaW9uIDA6IE1lbW9yeSBhdCBkMDAwMDAwMCAo
NjQtYml0LCBwcmVmZXRjaGFibGUpIFtzaXplPTI1Nk1dCj4gCVJlZ2lvbiAyOiBNZW1vcnkgYXQg
ZmJiMjAwMDAgKDY0LWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NjRLXQo+IAlSZWdpb24g
NDogSS9PIHBvcnRzIGF0IGUwMDAgW3NpemU9MjU2XQo+IAlFeHBhbnNpb24gUk9NIGF0IGZiYjAw
MDAwIFtkaXNhYmxlZF0gW3NpemU9MTI4S10KPiAJQ2FwYWJpbGl0aWVzOiBbNTBdIFBvd2VyIE1h
bmFnZW1lbnQgdmVyc2lvbiAzCj4gCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxKyBEMisgQXV4Q3Vy
cmVudD0wbUEKPiBQTUUoRDAtLEQxLSxEMi0sRDNob3QtLEQzY29sZC0pCj4gCQlTdGF0dXM6IEQw
IE5vU29mdFJzdC0gUE1FLUVuYWJsZS0gRFNlbD0wIERTY2FsZT0wIFBNRS0KPiAJQ2FwYWJpbGl0
aWVzOiBbNThdIEV4cHJlc3MgKHYyKSBMZWdhY3kgRW5kcG9pbnQsIE1TSSAwMAo+IAkJRGV2Q2Fw
OglNYXhQYXlsb2FkIDEyOCBieXRlcywgUGhhbnRGdW5jIDAsIExhdGVuY3kgTDBzIDw0dXMsIEwx
Cj4gdW5saW1pdGVkCj4gCQkJRXh0VGFnKyBBdHRuQnRuLSBBdHRuSW5kLSBQd3JJbmQtIFJCRSsg
RkxSZXNldC0KPiAJCURldkN0bDoJUmVwb3J0IGVycm9yczogQ29ycmVjdGFibGUtIE5vbi1GYXRh
bC0gRmF0YWwtIApVbnN1cHBvcnRlZC0KPiAJCQlSbHhkT3JkLSBFeHRUYWcrIFBoYW50RnVuYy0g
QXV4UHdyLSBOb1Nub29wKwo+IAkJCU1heFBheWxvYWQgMTI4IGJ5dGVzLCBNYXhSZWFkUmVxIDEy
OCBieXRlcwo+IAkJRGV2U3RhOglDb3JyRXJyLSBVbmNvcnJFcnItIEZhdGFsRXJyLSBVbnN1cHBS
ZXEtIEF1eFB3ci0gClRyYW5zUGVuZC0KPiAJCUxua0NhcDoJUG9ydCAjMCwgU3BlZWQgNUdUL3Ms
IFdpZHRoIHgxNiwgQVNQTSBMMHMgTDEsIExhdGVuY3kgTDAKPiA8NjRucywgTDEgPDF1cwo+IAkJ
CUNsb2NrUE0tIFN1cnByaXNlLSBMTEFjdFJlcC0gQndOb3QtCj4gCQlMbmtDdGw6CUFTUE0gRGlz
YWJsZWQ7IFJDQiA2NCBieXRlcyBEaXNhYmxlZC0gUmV0cmFpbi0gQ29tbUNsaysKPiAJCQlFeHRT
eW5jaC0gQ2xvY2tQTS0gQXV0V2lkRGlzLSBCV0ludC0gQXV0QldJbnQtCj4gCQlMbmtTdGE6CVNw
ZWVkIDVHVC9zLCBXaWR0aCB4MTYsIFRyRXJyLSBUcmFpbi0gU2xvdENsaysgRExBY3RpdmUtCj4g
QldNZ210LSBBQldNZ210LQo+IAkJRGV2Q2FwMjogQ29tcGxldGlvbiBUaW1lb3V0OiBOb3QgU3Vw
cG9ydGVkLCBUaW1lb3V0RGlzLQo+IAkJRGV2Q3RsMjogQ29tcGxldGlvbiBUaW1lb3V0OiA1MHVz
IHRvIDUwbXMsIFRpbWVvdXREaXMtCj4gCQlMbmtDdGwyOiBUYXJnZXQgTGluayBTcGVlZDogNUdU
L3MsIEVudGVyQ29tcGxpYW5jZS0gU3BlZWREaXMtLAo+IFNlbGVjdGFibGUgRGUtZW1waGFzaXM6
IC02ZEIKPiAJCQkgVHJhbnNtaXQgTWFyZ2luOiBOb3JtYWwgT3BlcmF0aW5nIFJhbmdlLCAKRW50
ZXJNb2RpZmllZENvbXBsaWFuY2UtCj4gQ29tcGxpYW5jZVNPUy0KPiAJCQkgQ29tcGxpYW5jZSBE
ZS1lbXBoYXNpczogLTZkQgo+IAkJTG5rU3RhMjogQ3VycmVudCBEZS1lbXBoYXNpcyBMZXZlbDog
LTZkQgo+IAlDYXBhYmlsaXRpZXM6IFthMF0gTVNJOiBFbmFibGUrIENvdW50PTEvMSBNYXNrYWJs
ZS0gNjRiaXQrCj4gCQlBZGRyZXNzOiAwMDAwMDAwMGZlZTAwNDM4ICBEYXRhOiAwMDAwCj4gCUNh
cGFiaWxpdGllczogWzEwMCB2MV0gVmVuZG9yIFNwZWNpZmljIEluZm9ybWF0aW9uOiBJRD0wMDAx
IFJldj0xCj4gTGVuPTAxMCA8Pz4KPiAJS2VybmVsIGRyaXZlciBpbiB1c2U6IHBjaWJhY2sKPiAJ
S2VybmVsIG1vZHVsZXM6IHJhZGVvbgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhl
bnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:05:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqO53-0000rh-Vf; Thu, 26 Jan 2012 12:05:29 +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 1RqO51-0000rY-RZ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:05:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327579520!12600991!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10135 invoked from network); 26 Jan 2012 12:05:21 -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; 26 Jan 2012 12:05:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327579520; l=1865;
	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=78USlq5s9XgBUHCFMRJ0UbY6ctk=;
	b=ZM79j/G1KQ3lg3SxofDLRLhnMPco67yzqsMRIm2K4Dr267o7S1mscZp2rtxP3QrCe7v
	9bb47Na/zEH0qyHdR11lOwUNqLhlE7uaWazSM/w7ucnUF89NQACE7BS32sVj3VxrIimaR
	4t7xNWqXhY4jxjuH42jEcZu3HphAmK8EX6s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo35) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a00c8bo0QBhfac ;
	Thu, 26 Jan 2012 13:05:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B39B318637; Thu, 26 Jan 2012 13:05:06 +0100 (CET)
Date: Thu, 26 Jan 2012 13:05:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126120506.GA545@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
	<20120126094621.GA21629@aepfle.de>
	<01c35254dd14ced855caac42bdfcccf0.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <01c35254dd14ced855caac42bdfcccf0.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix 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, Jan 26, Andres Lagar-Cavilla wrote:

> Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
> provide feedback as to whether
> 1. remove p2m_ram_paging_in
> 2. rename p2m_ram_paging_in_start to p2m_ram_paging_in
> 
> sounds like a good plan?

In my opinion the common case is that evicted pages get populated, an
request is sent. Later an response is expected to make room in the ring.

If p2m_mem_paging_populate allocates a page for the guest, it can let
the pager know that it did so (or failed to allocate one).
If there is a page already, the pager can copy the gfn content into a
buffer, put a pointer to it in the response and let
p2m_mem_paging_resume() handle both the ring accounting (as it does now)
and also the copy_from_user.
If page allocation failed, the pager has to allocate one via
p2m_mem_paging_prep() as it is done now, as an intermediate step.

The buffer page handling in the pager is probably simple, it needs to
maintain RING_SIZE() buffers. There cant be more than that in flight
because thats the limit of requests as well. In other words, the pager
does not need to wait for p2m_mem_paging_resume() to run and pull the
buffer content.


If the "populate - allocate - put_request - get_request - fill_buffer -
put_response - resume  get_response - copy_from_buffer - resume_vcpu"
cycle works, it would reduce the overall amount of work to be done
during paging, even if the hypercalls itself are not the bottleneck.
It all depends on the possibility to allocate a page in the various
contexts where p2m_mem_paging_populate is called.

The resume part could be done via eventchannel and
XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME could be removed.

Also the question is if freeing one p2mt is more important than reducing
the number if hypercalls to execute at runtime.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:05:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqO53-0000rh-Vf; Thu, 26 Jan 2012 12:05:29 +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 1RqO51-0000rY-RZ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:05:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327579520!12600991!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10135 invoked from network); 26 Jan 2012 12:05:21 -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; 26 Jan 2012 12:05:21 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327579520; l=1865;
	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=78USlq5s9XgBUHCFMRJ0UbY6ctk=;
	b=ZM79j/G1KQ3lg3SxofDLRLhnMPco67yzqsMRIm2K4Dr267o7S1mscZp2rtxP3QrCe7v
	9bb47Na/zEH0qyHdR11lOwUNqLhlE7uaWazSM/w7ucnUF89NQACE7BS32sVj3VxrIimaR
	4t7xNWqXhY4jxjuH42jEcZu3HphAmK8EX6s=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo35) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a00c8bo0QBhfac ;
	Thu, 26 Jan 2012 13:05:04 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B39B318637; Thu, 26 Jan 2012 13:05:06 +0100 (CET)
Date: Thu, 26 Jan 2012 13:05:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126120506.GA545@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
	<20120126094621.GA21629@aepfle.de>
	<01c35254dd14ced855caac42bdfcccf0.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <01c35254dd14ced855caac42bdfcccf0.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix 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, Jan 26, Andres Lagar-Cavilla wrote:

> Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
> provide feedback as to whether
> 1. remove p2m_ram_paging_in
> 2. rename p2m_ram_paging_in_start to p2m_ram_paging_in
> 
> sounds like a good plan?

In my opinion the common case is that evicted pages get populated, an
request is sent. Later an response is expected to make room in the ring.

If p2m_mem_paging_populate allocates a page for the guest, it can let
the pager know that it did so (or failed to allocate one).
If there is a page already, the pager can copy the gfn content into a
buffer, put a pointer to it in the response and let
p2m_mem_paging_resume() handle both the ring accounting (as it does now)
and also the copy_from_user.
If page allocation failed, the pager has to allocate one via
p2m_mem_paging_prep() as it is done now, as an intermediate step.

The buffer page handling in the pager is probably simple, it needs to
maintain RING_SIZE() buffers. There cant be more than that in flight
because thats the limit of requests as well. In other words, the pager
does not need to wait for p2m_mem_paging_resume() to run and pull the
buffer content.


If the "populate - allocate - put_request - get_request - fill_buffer -
put_response - resume  get_response - copy_from_buffer - resume_vcpu"
cycle works, it would reduce the overall amount of work to be done
during paging, even if the hypercalls itself are not the bottleneck.
It all depends on the possibility to allocate a page in the various
contexts where p2m_mem_paging_populate is called.

The resume part could be done via eventchannel and
XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME could be removed.

Also the question is if freeing one p2mt is more important than reducing
the number if hypercalls to execute at runtime.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:12:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOAx-000111-Pd; Thu, 26 Jan 2012 12:11:35 +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 1RqOAw-00010s-4y
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:11:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327579844!61816549!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11778 invoked from network); 26 Jan 2012 12:10:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 12:10:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327579886; l=493;
	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=1izr2qDJevyKCM9Dy4e7ahbPNW0=;
	b=DwQwmnBa6UlPz3svEFchGRTQcu+xkxx9VQohCpekwHSLIZ5XIsvYBNOS42qNJ+fpdXg
	rDRvhUhd/z9QLzyeCxnijiYtV3oVT0B9C/Tn+ZK46I0TwvVUba/E97edZMKvbYK/iViom
	Xdn6Gz1gjKZAqrBUMyKWU9EUW0xvENDr/Cw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by post.strato.de (mrclete mo8) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f025f5o0QC8QVa ;
	Thu, 26 Jan 2012 13:11:03 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 273FF18637; Thu, 26 Jan 2012 13:11:06 +0100 (CET)
Date: Thu, 26 Jan 2012 13:11:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126121105.GB545@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
	<20120126095401.GC21629@aepfle.de>
	<fa3478fb74da9017012ef302f1c21dfc.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fa3478fb74da9017012ef302f1c21dfc.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for 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 Thu, Jan 26, Andres Lagar-Cavilla wrote:

> there is a put_page in case things go wrong, after the alloc_domheap_page
> call. So doing the decrement at alloc is a bit too soon.

Thats probably true.

But in the case of failure the guest will likely hang soon. Is the
copy_from_user() (and p2m_mem_paging_prep itself) restartable? If not,
the guest should probably be crashed.  The way xenpaging_populate_page()
is written right now, it will just exit, EFAULT isnt caught.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:12:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:12:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOAx-000111-Pd; Thu, 26 Jan 2012 12:11:35 +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 1RqOAw-00010s-4y
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:11:34 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327579844!61816549!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAzMzcwOTc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11778 invoked from network); 26 Jan 2012 12:10:45 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-9.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 12:10:45 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327579886; l=493;
	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=1izr2qDJevyKCM9Dy4e7ahbPNW0=;
	b=DwQwmnBa6UlPz3svEFchGRTQcu+xkxx9VQohCpekwHSLIZ5XIsvYBNOS42qNJ+fpdXg
	rDRvhUhd/z9QLzyeCxnijiYtV3oVT0B9C/Tn+ZK46I0TwvVUba/E97edZMKvbYK/iViom
	Xdn6Gz1gjKZAqrBUMyKWU9EUW0xvENDr/Cw=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by post.strato.de (mrclete mo8) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id f025f5o0QC8QVa ;
	Thu, 26 Jan 2012 13:11:03 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 273FF18637; Thu, 26 Jan 2012 13:11:06 +0100 (CET)
Date: Thu, 26 Jan 2012 13:11:06 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126121105.GB545@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
	<20120126095401.GC21629@aepfle.de>
	<fa3478fb74da9017012ef302f1c21dfc.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <fa3478fb74da9017012ef302f1c21dfc.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for 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 Thu, Jan 26, Andres Lagar-Cavilla wrote:

> there is a put_page in case things go wrong, after the alloc_domheap_page
> call. So doing the decrement at alloc is a bit too soon.

Thats probably true.

But in the case of failure the guest will likely hang soon. Is the
copy_from_user() (and p2m_mem_paging_prep itself) restartable? If not,
the guest should probably be crashed.  The way xenpaging_populate_page()
is written right now, it will just exit, EFAULT isnt caught.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:20:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOJE-0001UC-RO; Thu, 26 Jan 2012 12:20:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RqOJD-0001U7-IV
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:20:07 +0000
Received: from [85.158.138.51:19227] by server-1.bemta-3.messagelabs.com id
	69/F4-09565-6F4412F4; Thu, 26 Jan 2012 12:20:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327580399!10735706!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10423 invoked from network); 26 Jan 2012 12:20:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:20:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179186275"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 07:19:59 -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, 26 Jan 2012
	07:19:59 -0500
Message-ID: <4F2144EE.9040808@citrix.com>
Date: Thu, 26 Jan 2012 12:19: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------020509060709040701050600"
Subject: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------020509060709040701050600
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

XenServer by default boots without a serial console (buggy hardware
reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
writing to the vga text area looks ugly whilst dom0 is trying to set up
non-text mode and display  the splash screen.

We have been using "console=" to prevent this behavior for a while, but
presented herewith is a patch to fix the problem correctly.

~Andrew


--------------020509060709040701050600
Content-Type: text/x-patch; name="console-param-none.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="console-param-none.patch"

Console: introduce console=none command line parameter

Currenty, not specifying 'console=<foo>' on the command line causes
Xen to default to 'vga'.  Alternativly, the user can explicitly
specifiy 'console=vga|com1|com2'.

However, there is no way to specify that neither vga nor serial should
be used.  Specifying 'console=' does have the effect that neither vga
nor serial is set up, but at the cost of an "Bad console= option ''"
warning.

Therefore, expliticly support a 'console=none' option which does not
set up vga and does not set up serial, but does not trigger the bad
console warning.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a2a8089b1ffb xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -549,6 +549,8 @@ void __init console_init_preirq(void)
             p++;
         if ( !strncmp(p, "vga", 3) )
             vga_init();
+        else if ( !strncmp(p, "none", 4) )
+            continue;
         else if ( strncmp(p, "com", 3) ||
                   (sercon_handle = serial_parse_handle(p)) == -1 )
         {

--------------020509060709040701050600
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------020509060709040701050600--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:20:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOJE-0001UC-RO; Thu, 26 Jan 2012 12:20:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RqOJD-0001U7-IV
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:20:07 +0000
Received: from [85.158.138.51:19227] by server-1.bemta-3.messagelabs.com id
	69/F4-09565-6F4412F4; Thu, 26 Jan 2012 12:20:06 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327580399!10735706!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10423 invoked from network); 26 Jan 2012 12:20:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:20:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179186275"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 07:19:59 -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, 26 Jan 2012
	07:19:59 -0500
Message-ID: <4F2144EE.9040808@citrix.com>
Date: Thu, 26 Jan 2012 12:19: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.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------020509060709040701050600"
Subject: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------020509060709040701050600
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

XenServer by default boots without a serial console (buggy hardware
reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
writing to the vga text area looks ugly whilst dom0 is trying to set up
non-text mode and display  the splash screen.

We have been using "console=" to prevent this behavior for a while, but
presented herewith is a patch to fix the problem correctly.

~Andrew


--------------020509060709040701050600
Content-Type: text/x-patch; name="console-param-none.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="console-param-none.patch"

Console: introduce console=none command line parameter

Currenty, not specifying 'console=<foo>' on the command line causes
Xen to default to 'vga'.  Alternativly, the user can explicitly
specifiy 'console=vga|com1|com2'.

However, there is no way to specify that neither vga nor serial should
be used.  Specifying 'console=' does have the effect that neither vga
nor serial is set up, but at the cost of an "Bad console= option ''"
warning.

Therefore, expliticly support a 'console=none' option which does not
set up vga and does not set up serial, but does not trigger the bad
console warning.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a2a8089b1ffb xen/drivers/char/console.c
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -549,6 +549,8 @@ void __init console_init_preirq(void)
             p++;
         if ( !strncmp(p, "vga", 3) )
             vga_init();
+        else if ( !strncmp(p, "none", 4) )
+            continue;
         else if ( strncmp(p, "com", 3) ||
                   (sercon_handle = serial_parse_handle(p)) == -1 )
         {

--------------020509060709040701050600
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------020509060709040701050600--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:23:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOMK-0001aG-Ej; Thu, 26 Jan 2012 12:23: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 1RqOMJ-0001a4-0r
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:23:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327580591!4114126!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzkzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25888 invoked from network); 26 Jan 2012 12:23:12 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 12:23:12 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id E69E276C073;
	Thu, 26 Jan 2012 04:23:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MMxgciC8oRqNfrIhm3G9Mk5mELUqaZLejpNswX3fLZtG
	kBARjSjQtT53oaWZnqpIm7idgPi166DrQAAZah6tuei7YpprEyyBeulskUj2dn9x
	f9FJRo2mu6cmYbhnMR+4xTfl0DrPnazFEKZrNfyMDncuLuFDMzp8BCX0r+CvWF8=
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=C3mKDfHrgXMrnsYLNfUNz610mKE=; b=Quwl0vea
	7pqokUXGf6dkjB2F/nbeVqbhBopSnO/mR91SN1lRvQOhZaqNc0Anr7jPz56g2V0e
	twGyPObylNuE5WEu6GER3J83LcWiAUDkxQ7AsTiZm6jj/WVq5FF5E4WTHmTnHUX3
	Gjnk0OsyAb9ebSujlLyAyy6QEt/b7awuNis=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id A237376C06F; 
	Thu, 26 Jan 2012 04:23:10 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 04:23:10 -0800
Message-ID: <251543dc172738014ff5bd13c5614c3d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126120506.GA545@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
	<20120126094621.GA21629@aepfle.de>
	<01c35254dd14ced855caac42bdfcccf0.squirrel@webmail.lagarcavilla.org>
	<20120126120506.GA545@aepfle.de>
Date: Thu, 26 Jan 2012 04:23:10 -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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix paging_load
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, Jan 26, Andres Lagar-Cavilla wrote:
>
>> Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
>> provide feedback as to whether
>> 1. remove p2m_ram_paging_in
>> 2. rename p2m_ram_paging_in_start to p2m_ram_paging_in
>>
>> sounds like a good plan?
>
> In my opinion the common case is that evicted pages get populated, an
> request is sent. Later an response is expected to make room in the ring.
>
> If p2m_mem_paging_populate allocates a page for the guest, it can let
> the pager know that it did so (or failed to allocate one).
> If there is a page already, the pager can copy the gfn content into a
> buffer, put a pointer to it in the response and let
> p2m_mem_paging_resume() handle both the ring accounting (as it does now)
> and also the copy_from_user.

So, this would bounce the page contents twice for the case when the page
hasn't yet been evicted?

> If page allocation failed, the pager has to allocate one via
> p2m_mem_paging_prep() as it is done now, as an intermediate step.

The issue of failed allocations is more pervasive. It also affects mem
sharing. And even PoD. What I'm trying to say is that even though your
solution seems to work (as long as the pager does dom0 ballooning to free
up some memory in between populate and prep!), we need a more generic
mechanism. Something along the lines of an ENOMEM mem_event ring, and a
matching dom0 daemon.

>
> The buffer page handling in the pager is probably simple, it needs to
> maintain RING_SIZE() buffers. There cant be more than that in flight
> because thats the limit of requests as well. In other words, the pager
> does not need to wait for p2m_mem_paging_resume() to run and pull the
> buffer content.
>
>
> If the "populate - allocate - put_request - get_request - fill_buffer -
> put_response - resume  get_response - copy_from_buffer - resume_vcpu"
> cycle works, it would reduce the overall amount of work to be done
> during paging, even if the hypercalls itself are not the bottleneck.
> It all depends on the possibility to allocate a page in the various
> contexts where p2m_mem_paging_populate is called.

The gist here is that the paging_load call would be removed?

I like the general direction, but one excellent property of paging_resume
is that it doesn't fail. This is particularly important since we already
do resumes via ring responses and event channel kicks (see below). So, if
resume needs to propagate failures back to the pager, things get icky.

(paging_load is restartable, see other email)

>
> The resume part could be done via eventchannel and
> XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME could be removed.

This is already the case. I'm not eager to remove the domctl, but resuming
via event channel kick only is in place.

>
> Also the question is if freeing one p2mt is more important than reducing
> the number if hypercalls to execute at runtime.

Agreed. However, eliminating code complexity is also useful, and these two
ram_paging_in states cause everyone headaches.

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 Jan 26 12:23:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:23:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOMK-0001aG-Ej; Thu, 26 Jan 2012 12:23: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 1RqOMJ-0001a4-0r
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:23:19 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327580591!4114126!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzkzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25888 invoked from network); 26 Jan 2012 12:23:12 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.83) by server-2.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 12:23:12 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id E69E276C073;
	Thu, 26 Jan 2012 04:23:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=MMxgciC8oRqNfrIhm3G9Mk5mELUqaZLejpNswX3fLZtG
	kBARjSjQtT53oaWZnqpIm7idgPi166DrQAAZah6tuei7YpprEyyBeulskUj2dn9x
	f9FJRo2mu6cmYbhnMR+4xTfl0DrPnazFEKZrNfyMDncuLuFDMzp8BCX0r+CvWF8=
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=C3mKDfHrgXMrnsYLNfUNz610mKE=; b=Quwl0vea
	7pqokUXGf6dkjB2F/nbeVqbhBopSnO/mR91SN1lRvQOhZaqNc0Anr7jPz56g2V0e
	twGyPObylNuE5WEu6GER3J83LcWiAUDkxQ7AsTiZm6jj/WVq5FF5E4WTHmTnHUX3
	Gjnk0OsyAb9ebSujlLyAyy6QEt/b7awuNis=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id A237376C06F; 
	Thu, 26 Jan 2012 04:23:10 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 04:23:10 -0800
Message-ID: <251543dc172738014ff5bd13c5614c3d.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126120506.GA545@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
	<20120126094621.GA21629@aepfle.de>
	<01c35254dd14ced855caac42bdfcccf0.squirrel@webmail.lagarcavilla.org>
	<20120126120506.GA545@aepfle.de>
Date: Thu, 26 Jan 2012 04:23:10 -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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix paging_load
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, Jan 26, Andres Lagar-Cavilla wrote:
>
>> Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
>> provide feedback as to whether
>> 1. remove p2m_ram_paging_in
>> 2. rename p2m_ram_paging_in_start to p2m_ram_paging_in
>>
>> sounds like a good plan?
>
> In my opinion the common case is that evicted pages get populated, an
> request is sent. Later an response is expected to make room in the ring.
>
> If p2m_mem_paging_populate allocates a page for the guest, it can let
> the pager know that it did so (or failed to allocate one).
> If there is a page already, the pager can copy the gfn content into a
> buffer, put a pointer to it in the response and let
> p2m_mem_paging_resume() handle both the ring accounting (as it does now)
> and also the copy_from_user.

So, this would bounce the page contents twice for the case when the page
hasn't yet been evicted?

> If page allocation failed, the pager has to allocate one via
> p2m_mem_paging_prep() as it is done now, as an intermediate step.

The issue of failed allocations is more pervasive. It also affects mem
sharing. And even PoD. What I'm trying to say is that even though your
solution seems to work (as long as the pager does dom0 ballooning to free
up some memory in between populate and prep!), we need a more generic
mechanism. Something along the lines of an ENOMEM mem_event ring, and a
matching dom0 daemon.

>
> The buffer page handling in the pager is probably simple, it needs to
> maintain RING_SIZE() buffers. There cant be more than that in flight
> because thats the limit of requests as well. In other words, the pager
> does not need to wait for p2m_mem_paging_resume() to run and pull the
> buffer content.
>
>
> If the "populate - allocate - put_request - get_request - fill_buffer -
> put_response - resume  get_response - copy_from_buffer - resume_vcpu"
> cycle works, it would reduce the overall amount of work to be done
> during paging, even if the hypercalls itself are not the bottleneck.
> It all depends on the possibility to allocate a page in the various
> contexts where p2m_mem_paging_populate is called.

The gist here is that the paging_load call would be removed?

I like the general direction, but one excellent property of paging_resume
is that it doesn't fail. This is particularly important since we already
do resumes via ring responses and event channel kicks (see below). So, if
resume needs to propagate failures back to the pager, things get icky.

(paging_load is restartable, see other email)

>
> The resume part could be done via eventchannel and
> XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME could be removed.

This is already the case. I'm not eager to remove the domctl, but resuming
via event channel kick only is in place.

>
> Also the question is if freeing one p2mt is more important than reducing
> the number if hypercalls to execute at runtime.

Agreed. However, eliminating code complexity is also useful, and these two
ram_paging_in states cause everyone headaches.

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 Jan 26 12:26:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOP6-0001iZ-21; Thu, 26 Jan 2012 12:26:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqOP4-0001iO-8G
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:26:11 +0000
Received: from [85.158.139.83:24017] by server-6.bemta-5.messagelabs.com id
	C5/13-21889-E56412F4; Thu, 26 Jan 2012 12:26:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327580763!12477230!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4MTU5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19603 invoked from network); 26 Jan 2012 12:26:04 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 12:26:04 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 874AF5EC080;
	Thu, 26 Jan 2012 04:26: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=Zy+qL+qi10dInxsTcowytAlFFL0d0xJJR3LJo7IGh0ib
	Dg2ZYDMl7CUuhOrJNNcdkROqAymhFsL70oucxM4g9SRQ7ECCHR+9DUGevGO8IQ4q
	u7z8MYNzSgd0VLW2xzLJzm7nl9WUgj4+EuDgz24YVByLE2qdy76mzgYIH2NG6TE=
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=j3kiQqUGU9GJD9yQDR8RLhq84+Q=; b=bHEMhBYE
	fh8EL7/PpoCx8RgD6YQ1xStqOq9ZeIxKfak7bYAipvU0pl8mcGh2sNO8KFNxavXZ
	k+Rff8bHKHvqrdpVQThdsf+tS23d24pTX4JdyNcJH7ZV545dXVXDnJlWIFlzxD2G
	kqabLBJyKXKaAlSgDAQTJp3fGbgMUfsAIm0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 2A4575EC072; 
	Thu, 26 Jan 2012 04:26:03 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 04:26:03 -0800
Message-ID: <710a4eb4ec5c371e2120edf5cebb6976.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126121105.GB545@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
	<20120126095401.GC21629@aepfle.de>
	<fa3478fb74da9017012ef302f1c21dfc.squirrel@webmail.lagarcavilla.org>
	<20120126121105.GB545@aepfle.de>
Date: Thu, 26 Jan 2012 04:26:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for paged
	out 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

> On Thu, Jan 26, Andres Lagar-Cavilla wrote:
>
>> there is a put_page in case things go wrong, after the
>> alloc_domheap_page
>> call. So doing the decrement at alloc is a bit too soon.
>
> Thats probably true.
>
> But in the case of failure the guest will likely hang soon. Is the
> copy_from_user() (and p2m_mem_paging_prep itself) restartable? If not,
> the guest should probably be crashed.  The way xenpaging_populate_page()
> is written right now, it will just exit, EFAULT isnt caught.

p2m_mem_paging_prep is restartable, afaict. It cleanly undoes its deeds.

xenpaging not handling EFAULT ... that's a different issue/patch altogether.

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 Jan 26 12:26:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOP6-0001iZ-21; Thu, 26 Jan 2012 12:26:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqOP4-0001iO-8G
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:26:11 +0000
Received: from [85.158.139.83:24017] by server-6.bemta-5.messagelabs.com id
	C5/13-21889-E56412F4; Thu, 26 Jan 2012 12:26:06 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327580763!12477230!1
X-Originating-IP: [208.97.132.5]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi41ID0+IDE4MTU5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19603 invoked from network); 26 Jan 2012 12:26:04 -0000
Received: from mailbigip.dreamhost.com (HELO homiemail-a75.g.dreamhost.com)
	(208.97.132.5) by server-12.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 12:26:04 -0000
Received: from homiemail-a75.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTP id 874AF5EC080;
	Thu, 26 Jan 2012 04:26: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=Zy+qL+qi10dInxsTcowytAlFFL0d0xJJR3LJo7IGh0ib
	Dg2ZYDMl7CUuhOrJNNcdkROqAymhFsL70oucxM4g9SRQ7ECCHR+9DUGevGO8IQ4q
	u7z8MYNzSgd0VLW2xzLJzm7nl9WUgj4+EuDgz24YVByLE2qdy76mzgYIH2NG6TE=
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=j3kiQqUGU9GJD9yQDR8RLhq84+Q=; b=bHEMhBYE
	fh8EL7/PpoCx8RgD6YQ1xStqOq9ZeIxKfak7bYAipvU0pl8mcGh2sNO8KFNxavXZ
	k+Rff8bHKHvqrdpVQThdsf+tS23d24pTX4JdyNcJH7ZV545dXVXDnJlWIFlzxD2G
	kqabLBJyKXKaAlSgDAQTJp3fGbgMUfsAIm0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a75.g.dreamhost.com (Postfix) with ESMTPA id 2A4575EC072; 
	Thu, 26 Jan 2012 04:26:03 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 04:26:03 -0800
Message-ID: <710a4eb4ec5c371e2120edf5cebb6976.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126121105.GB545@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
	<20120126095401.GC21629@aepfle.de>
	<fa3478fb74da9017012ef302f1c21dfc.squirrel@webmail.lagarcavilla.org>
	<20120126121105.GB545@aepfle.de>
Date: Thu, 26 Jan 2012 04:26:03 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Olaf Hering" <olaf@aepfle.de>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: andres@gridcentric.ca, xen-devel@lists.xensource.com, tim@xen.org,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for paged
	out 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

> On Thu, Jan 26, Andres Lagar-Cavilla wrote:
>
>> there is a put_page in case things go wrong, after the
>> alloc_domheap_page
>> call. So doing the decrement at alloc is a bit too soon.
>
> Thats probably true.
>
> But in the case of failure the guest will likely hang soon. Is the
> copy_from_user() (and p2m_mem_paging_prep itself) restartable? If not,
> the guest should probably be crashed.  The way xenpaging_populate_page()
> is written right now, it will just exit, EFAULT isnt caught.

p2m_mem_paging_prep is restartable, afaict. It cleanly undoes its deeds.

xenpaging not handling EFAULT ... that's a different issue/patch altogether.

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 Jan 26 12:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOQZ-0001pD-HU; Thu, 26 Jan 2012 12:27:43 +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 1RqOQX-0001p3-UO
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:27:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327580729!50152224!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15727 invoked from network); 26 Jan 2012 12:25:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:25:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; 
	d="diff'223?scan'223,208,223";a="179186926"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 07:27: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; Thu, 26 Jan 2012 07:27:38 -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 q0QCRaq1009117;
	Thu, 26 Jan 2012 04:27:37 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <94f71dded5ab5a31224b.1326376371@probook.site>
References: <94f71dded5ab5a31224b.1326376371@probook.site>
Content-Type: multipart/mixed; boundary="=-/91XICmGKy4o3Wk2rVkr"
Date: Thu, 26 Jan 2012 12:27:35 +0000
Message-ID: <1327580855.24345.1.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit
	build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--=-/91XICmGKy4o3Wk2rVkr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

How about this patch instead?  It makes the base variable "long", so
that we don't need the extra intermediate cast.

 -George

On Thu, 2012-01-12 at 13:52 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1326374876 -3600
> # Node ID 94f71dded5ab5a31224b852aac6b238b590b7b25
> # Parent  223e8ad4c7557960e29a7c294bb94723b2cd7f09
> xenalyze: add missing casts to fix 64bit build
> 
> xenalyze.c: In function 'hvm_mmio_summary':
> xenalyze.c:3728: error: cast from pointer to integer of different size
> xenalyze.c: In function 'hvm_mmio_assist_postprocess':
> xenalyze.c:3743: error: cast to pointer from integer of different size
> xenalyze.c:3747: error: cast to pointer from integer of different size
> xenalyze.c:3759: error: cast to pointer from integer of different size
> xenalyze.c: In function 'hvm_cr_write_summary':
> xenalyze.c:4251: error: cast from pointer to integer of different size
> xenalyze.c: In function 'hvm_generic_summary':
> xenalyze.c:4800: error: cast from pointer to integer of different size
> xenalyze.c: In function 'hvm_generic_postprocess':
> xenalyze.c:4871: error: cast to pointer from integer of different size
> make: *** [xenalyze] Error 1
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 223e8ad4c755 -r 94f71dded5ab xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -3725,7 +3725,7 @@ void enumerate_mmio(struct hvm_data *h)
>  
>  void hvm_mmio_summary(struct hvm_data *h, void *data)
>  {
> -    int reason=(int)data;
> +    int reason=(long)data;
>  
>      PRINT_SUMMARY(h->summary.mmio[reason],
>                    "   mmio ");
> @@ -3740,11 +3740,11 @@ void hvm_mmio_assist_postprocess(struct 
>      case VMEXIT_NPF:
>      case EXIT_REASON_EPT_VIOLATION:
>          reason=NONPF_MMIO_NPF;
> -        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
> +        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
>          break;
>      case EXIT_REASON_APIC_ACCESS:
>          reason=NONPF_MMIO_APIC;
> -        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
> +        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
>          break;
>      default:
>      {
> @@ -3756,7 +3756,7 @@ void hvm_mmio_assist_postprocess(struct 
>              warned=1;
>          }
>          reason=NONPF_MMIO_UNKNOWN;
> -        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
> +        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
>          break;
>      }
>      }
> @@ -4248,7 +4248,7 @@ void hvm_cr3_write_summary(struct hvm_da
>  
>  void hvm_cr_write_summary(struct hvm_data *h, void *data)
>  {
> -    int cr=(int)data;
> +    int cr=(long)data;
>  
>      PRINT_SUMMARY(h->summary.cr_write[cr],
>                    "   cr%d ", cr);
> @@ -4797,7 +4797,7 @@ void hvm_rdtsc_process(struct record_inf
>  
>  void hvm_generic_summary(struct hvm_data *h, void *data)
>  {
> -    int evt = (int)data;
> +    int evt = (long)data;
>  
>      assert(evt < HVM_EVENT_HANDLER_MAX);
>  
> @@ -4868,7 +4868,7 @@ void hvm_generic_postprocess(struct hvm_
>          else
>          {
>              int ret;
> -            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)evt)))
> +            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)(long)evt)))
>                  fprintf(stderr, "%s: hvm_set_summary_handler returned %d\n",
>                          __func__, ret);
>              registered[evt]=h->exit_reason+1;


--=-/91XICmGKy4o3Wk2rVkr
Content-Disposition: attachment; filename="pointer-casts-long.diff"
Content-Type: text/x-patch; name="pointer-casts-long.diff"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

>From olaf@aepfle.de Thu Jan 12 13:53:15 2012
Received: from SMTP.EU.CITRIX.COM (10.31.1.27) by LONPMAILMX02.citrite.net
 (10.30.203.163) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Jan 2012
 13:53:15 +0000
Received: from mo-p00-ob.rzone.de ([81.169.146.161])  by SMTP.EU.CITRIX.COM
 with ESMTP/TLS/EDH-RSA-DES-CBC3-SHA; 12 Jan 2012 13:53:15 +0000
Received: from probook.site	(dslb-088-065-110-122.pools.arcor-ip.net
 [88.65.110.122])	by smtp.strato.de (fruni mo6) (RZmta 27.3 DYNA|AUTH)	with
 (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z02699o0CDYeUs ;	Thu, 12 Jan
 2012 14:52:52 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])	by probook.site
 (Postfix) with ESMTP id CB15318634;	Thu, 12 Jan 2012 14:52:51 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
CC: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 12 Jan 2012 13:52:51 +0000
Subject: [PATCH] xenalyze: add missing casts to fix 64bit build
Thread-Topic: [PATCH] xenalyze: add missing casts to fix 64bit build
Thread-Index: AczRMYilUkKqxSPMTEShuD89quR++A==
Message-ID: <94f71dded5ab5a31224b.1326376371@probook.site>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: LONPMAILMX02.citrite.net
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-sbrs: 4.1
x-mesageid: 9971216
x-ironport-server: LONPIP01.CITRITE.NET
x-remote-ip: 81.169.146.161
x-policy: $ACCEPTED
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result:
 Av4BAC/lDk9RqZKhjWdsb2JhbABDrQkiAQEBAQkJCwkSBSKCIBMGOQE7FR8uM4d8pTeSBweJAYMcmlCMfw
x-ironport-av: E=Sophos;i="4.71,498,1320624000";    d="scan'208";a="9971216"
dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326376394; l=2969;
 s=domk; d=aepfle.de;
 h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
 Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;	bh=X6Rg3zN9hR3a7o+4QJ3b3HFlrL4=;
 b=RcH7lQSvp2kGDWRXGFz1E40PbfO1PoHdjMME7T8HAdtB1mqhT6K6IWFhRHH+Hf4OGtU
 xcWSK9jxQs13YdFzUOVXZhXnodRlFPorCXKzZ2Hikbs9qrZR7F0qT2V1XFzHzdEPRK1kR
 Tt2x7tJWIqguMAx/Jx/Ve4IOxfrAeOmyBIk=
user-agent: Mercurial-patchbomb/1.7.5
x-rzg-class-id: mo00
x-rzg-auth: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
x-mercurial-node: 94f71dded5ab5a31224b852aac6b238b590b7b25
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Evolution-Source: imap://georged@lonpmailmx01.citrite.net/
Content-Transfer-Encoding: 8bit

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326374876 -3600
# Node ID 94f71dded5ab5a31224b852aac6b238b590b7b25
# Parent  223e8ad4c7557960e29a7c294bb94723b2cd7f09
xenalyze: Use long to cast into and out of pointers

64-bit compileers will complain when casting into our out of 
a pointer if the integer is not of the same size; so make all things
which are cast into or out of pointers "long", which translates
to 32-bit on 32-bit systems and 64-bit on 64-bit systems.

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 223e8ad4c755 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Thu Jan 26 12:25:31 2012 +0000
@@ -3725,7 +3725,7 @@ void enumerate_mmio(struct hvm_data *h)
 
 void hvm_mmio_summary(struct hvm_data *h, void *data)
 {
-    int reason=(int)data;
+    long reason=(long)data;
 
     PRINT_SUMMARY(h->summary.mmio[reason],
                   "   mmio ");
@@ -3733,7 +3733,7 @@ void hvm_mmio_summary(struct hvm_data *h
 
 void hvm_mmio_assist_postprocess(struct hvm_data *h)
 {
-    int reason;
+    long reason;
 
     switch(h->exit_reason)
     {
@@ -4248,10 +4248,10 @@ void hvm_cr3_write_summary(struct hvm_da
 
 void hvm_cr_write_summary(struct hvm_data *h, void *data)
 {
-    int cr=(int)data;
+    long cr=(long)data;
 
     PRINT_SUMMARY(h->summary.cr_write[cr],
-                  "   cr%d ", cr);
+                  "   cr%ld ", cr);
     if ( cr==3 )
         hvm_cr3_write_summary(h);
 }
@@ -4797,7 +4797,7 @@ void hvm_rdtsc_process(struct record_inf
 
 void hvm_generic_summary(struct hvm_data *h, void *data)
 {
-    int evt = (int)data;
+    long evt = (long)data;
 
     assert(evt < HVM_EVENT_HANDLER_MAX);
 
@@ -4808,7 +4808,7 @@ void hvm_generic_summary(struct hvm_data
 
 void hvm_generic_postprocess(struct hvm_data *h)
 {
-    int evt = 0;
+    long evt = 0;
     static unsigned registered[HVM_EVENT_HANDLER_MAX] = { 0 };
 
     if ( h->inflight.generic.event )
@@ -4860,7 +4860,7 @@ void hvm_generic_postprocess(struct hvm_
             static unsigned warned[HVM_EXIT_REASON_MAX] = { 0 };
             if ( registered[evt] != h->exit_reason+1 && !warned[h->exit_reason])
             {
-                fprintf(warn, "%s: HVM evt %x in %x and %x!\n",
+                fprintf(warn, "%s: HVM evt %lx in %x and %x!\n",
                         __func__, evt, registered[evt]-1, h->exit_reason);
                 warned[h->exit_reason]=1;
             }

--=-/91XICmGKy4o3Wk2rVkr
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=-/91XICmGKy4o3Wk2rVkr--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:28:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:28:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOQZ-0001pD-HU; Thu, 26 Jan 2012 12:27:43 +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 1RqOQX-0001p3-UO
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:27:42 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327580729!50152224!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15727 invoked from network); 26 Jan 2012 12:25:30 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:25:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; 
	d="diff'223?scan'223,208,223";a="179186926"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 07:27: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; Thu, 26 Jan 2012 07:27:38 -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 q0QCRaq1009117;
	Thu, 26 Jan 2012 04:27:37 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <94f71dded5ab5a31224b.1326376371@probook.site>
References: <94f71dded5ab5a31224b.1326376371@probook.site>
Content-Type: multipart/mixed; boundary="=-/91XICmGKy4o3Wk2rVkr"
Date: Thu, 26 Jan 2012 12:27:35 +0000
Message-ID: <1327580855.24345.1.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit
	build
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--=-/91XICmGKy4o3Wk2rVkr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

How about this patch instead?  It makes the base variable "long", so
that we don't need the extra intermediate cast.

 -George

On Thu, 2012-01-12 at 13:52 +0000, Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1326374876 -3600
> # Node ID 94f71dded5ab5a31224b852aac6b238b590b7b25
> # Parent  223e8ad4c7557960e29a7c294bb94723b2cd7f09
> xenalyze: add missing casts to fix 64bit build
> 
> xenalyze.c: In function 'hvm_mmio_summary':
> xenalyze.c:3728: error: cast from pointer to integer of different size
> xenalyze.c: In function 'hvm_mmio_assist_postprocess':
> xenalyze.c:3743: error: cast to pointer from integer of different size
> xenalyze.c:3747: error: cast to pointer from integer of different size
> xenalyze.c:3759: error: cast to pointer from integer of different size
> xenalyze.c: In function 'hvm_cr_write_summary':
> xenalyze.c:4251: error: cast from pointer to integer of different size
> xenalyze.c: In function 'hvm_generic_summary':
> xenalyze.c:4800: error: cast from pointer to integer of different size
> xenalyze.c: In function 'hvm_generic_postprocess':
> xenalyze.c:4871: error: cast to pointer from integer of different size
> make: *** [xenalyze] Error 1
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 223e8ad4c755 -r 94f71dded5ab xenalyze.c
> --- a/xenalyze.c
> +++ b/xenalyze.c
> @@ -3725,7 +3725,7 @@ void enumerate_mmio(struct hvm_data *h)
>  
>  void hvm_mmio_summary(struct hvm_data *h, void *data)
>  {
> -    int reason=(int)data;
> +    int reason=(long)data;
>  
>      PRINT_SUMMARY(h->summary.mmio[reason],
>                    "   mmio ");
> @@ -3740,11 +3740,11 @@ void hvm_mmio_assist_postprocess(struct 
>      case VMEXIT_NPF:
>      case EXIT_REASON_EPT_VIOLATION:
>          reason=NONPF_MMIO_NPF;
> -        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
> +        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
>          break;
>      case EXIT_REASON_APIC_ACCESS:
>          reason=NONPF_MMIO_APIC;
> -        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
> +        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
>          break;
>      default:
>      {
> @@ -3756,7 +3756,7 @@ void hvm_mmio_assist_postprocess(struct 
>              warned=1;
>          }
>          reason=NONPF_MMIO_UNKNOWN;
> -        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)reason);
> +        hvm_set_summary_handler(h, hvm_mmio_summary, (void *)(long)reason);
>          break;
>      }
>      }
> @@ -4248,7 +4248,7 @@ void hvm_cr3_write_summary(struct hvm_da
>  
>  void hvm_cr_write_summary(struct hvm_data *h, void *data)
>  {
> -    int cr=(int)data;
> +    int cr=(long)data;
>  
>      PRINT_SUMMARY(h->summary.cr_write[cr],
>                    "   cr%d ", cr);
> @@ -4797,7 +4797,7 @@ void hvm_rdtsc_process(struct record_inf
>  
>  void hvm_generic_summary(struct hvm_data *h, void *data)
>  {
> -    int evt = (int)data;
> +    int evt = (long)data;
>  
>      assert(evt < HVM_EVENT_HANDLER_MAX);
>  
> @@ -4868,7 +4868,7 @@ void hvm_generic_postprocess(struct hvm_
>          else
>          {
>              int ret;
> -            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)evt)))
> +            if((ret=__hvm_set_summary_handler(h, hvm_generic_summary, (void *)(long)evt)))
>                  fprintf(stderr, "%s: hvm_set_summary_handler returned %d\n",
>                          __func__, ret);
>              registered[evt]=h->exit_reason+1;


--=-/91XICmGKy4o3Wk2rVkr
Content-Disposition: attachment; filename="pointer-casts-long.diff"
Content-Type: text/x-patch; name="pointer-casts-long.diff"; charset="UTF-8"
Content-Transfer-Encoding: 7bit

>From olaf@aepfle.de Thu Jan 12 13:53:15 2012
Received: from SMTP.EU.CITRIX.COM (10.31.1.27) by LONPMAILMX02.citrite.net
 (10.30.203.163) with Microsoft SMTP Server id 8.3.213.0; Thu, 12 Jan 2012
 13:53:15 +0000
Received: from mo-p00-ob.rzone.de ([81.169.146.161])  by SMTP.EU.CITRIX.COM
 with ESMTP/TLS/EDH-RSA-DES-CBC3-SHA; 12 Jan 2012 13:53:15 +0000
Received: from probook.site	(dslb-088-065-110-122.pools.arcor-ip.net
 [88.65.110.122])	by smtp.strato.de (fruni mo6) (RZmta 27.3 DYNA|AUTH)	with
 (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id z02699o0CDYeUs ;	Thu, 12 Jan
 2012 14:52:52 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])	by probook.site
 (Postfix) with ESMTP id CB15318634;	Thu, 12 Jan 2012 14:52:51 +0100 (CET)
From: Olaf Hering <olaf@aepfle.de>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
CC: George Dunlap <George.Dunlap@eu.citrix.com>
Date: Thu, 12 Jan 2012 13:52:51 +0000
Subject: [PATCH] xenalyze: add missing casts to fix 64bit build
Thread-Topic: [PATCH] xenalyze: add missing casts to fix 64bit build
Thread-Index: AczRMYilUkKqxSPMTEShuD89quR++A==
Message-ID: <94f71dded5ab5a31224b.1326376371@probook.site>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: LONPMAILMX02.citrite.net
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-sbrs: 4.1
x-mesageid: 9971216
x-ironport-server: LONPIP01.CITRITE.NET
x-remote-ip: 81.169.146.161
x-policy: $ACCEPTED
x-ironport-anti-spam-filtered: true
x-ironport-anti-spam-result:
 Av4BAC/lDk9RqZKhjWdsb2JhbABDrQkiAQEBAQkJCwkSBSKCIBMGOQE7FR8uM4d8pTeSBweJAYMcmlCMfw
x-ironport-av: E=Sophos;i="4.71,498,1320624000";    d="scan'208";a="9971216"
dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1326376394; l=2969;
 s=domk; d=aepfle.de;
 h=Cc:To:From:Date:Subject:Content-Transfer-Encoding:MIME-Version:
 Content-Type:X-RZG-CLASS-ID:X-RZG-AUTH;	bh=X6Rg3zN9hR3a7o+4QJ3b3HFlrL4=;
 b=RcH7lQSvp2kGDWRXGFz1E40PbfO1PoHdjMME7T8HAdtB1mqhT6K6IWFhRHH+Hf4OGtU
 xcWSK9jxQs13YdFzUOVXZhXnodRlFPorCXKzZ2Hikbs9qrZR7F0qT2V1XFzHzdEPRK1kR
 Tt2x7tJWIqguMAx/Jx/Ve4IOxfrAeOmyBIk=
user-agent: Mercurial-patchbomb/1.7.5
x-rzg-class-id: mo00
x-rzg-auth: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFPjzMQEiX0jA==
x-mercurial-node: 94f71dded5ab5a31224b852aac6b238b590b7b25
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Evolution-Source: imap://georged@lonpmailmx01.citrite.net/
Content-Transfer-Encoding: 8bit

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1326374876 -3600
# Node ID 94f71dded5ab5a31224b852aac6b238b590b7b25
# Parent  223e8ad4c7557960e29a7c294bb94723b2cd7f09
xenalyze: Use long to cast into and out of pointers

64-bit compileers will complain when casting into our out of 
a pointer if the integer is not of the same size; so make all things
which are cast into or out of pointers "long", which translates
to 32-bit on 32-bit systems and 64-bit on 64-bit systems.

Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 223e8ad4c755 xenalyze.c
--- a/xenalyze.c	Mon Nov 28 16:16:23 2011 +0000
+++ b/xenalyze.c	Thu Jan 26 12:25:31 2012 +0000
@@ -3725,7 +3725,7 @@ void enumerate_mmio(struct hvm_data *h)
 
 void hvm_mmio_summary(struct hvm_data *h, void *data)
 {
-    int reason=(int)data;
+    long reason=(long)data;
 
     PRINT_SUMMARY(h->summary.mmio[reason],
                   "   mmio ");
@@ -3733,7 +3733,7 @@ void hvm_mmio_summary(struct hvm_data *h
 
 void hvm_mmio_assist_postprocess(struct hvm_data *h)
 {
-    int reason;
+    long reason;
 
     switch(h->exit_reason)
     {
@@ -4248,10 +4248,10 @@ void hvm_cr3_write_summary(struct hvm_da
 
 void hvm_cr_write_summary(struct hvm_data *h, void *data)
 {
-    int cr=(int)data;
+    long cr=(long)data;
 
     PRINT_SUMMARY(h->summary.cr_write[cr],
-                  "   cr%d ", cr);
+                  "   cr%ld ", cr);
     if ( cr==3 )
         hvm_cr3_write_summary(h);
 }
@@ -4797,7 +4797,7 @@ void hvm_rdtsc_process(struct record_inf
 
 void hvm_generic_summary(struct hvm_data *h, void *data)
 {
-    int evt = (int)data;
+    long evt = (long)data;
 
     assert(evt < HVM_EVENT_HANDLER_MAX);
 
@@ -4808,7 +4808,7 @@ void hvm_generic_summary(struct hvm_data
 
 void hvm_generic_postprocess(struct hvm_data *h)
 {
-    int evt = 0;
+    long evt = 0;
     static unsigned registered[HVM_EVENT_HANDLER_MAX] = { 0 };
 
     if ( h->inflight.generic.event )
@@ -4860,7 +4860,7 @@ void hvm_generic_postprocess(struct hvm_
             static unsigned warned[HVM_EXIT_REASON_MAX] = { 0 };
             if ( registered[evt] != h->exit_reason+1 && !warned[h->exit_reason])
             {
-                fprintf(warn, "%s: HVM evt %x in %x and %x!\n",
+                fprintf(warn, "%s: HVM evt %lx in %x and %x!\n",
                         __func__, evt, registered[evt]-1, h->exit_reason);
                 warned[h->exit_reason]=1;
             }

--=-/91XICmGKy4o3Wk2rVkr
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--=-/91XICmGKy4o3Wk2rVkr--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:42:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOeQ-00027e-74; Thu, 26 Jan 2012 12:42:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqOeO-00027Z-8k
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:42:00 +0000
Received: from [85.158.138.51:20161] by server-10.bemta-3.messagelabs.com id
	E6/AF-20948-71A412F4; Thu, 26 Jan 2012 12:41:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327581718!10710834!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10372 invoked from network); 26 Jan 2012 12:41:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:41:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10303737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:41:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:41:58 +0000
Date: Thu, 26 Jan 2012 12:42:46 +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.1201261233050.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] Xen (PV and HVM) multiple PV consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series (sent before a few times) achieves two goals:

- make PV consoles work for PV on HVM guests;

- implement support for multiple PV consoles for PV and PV on HVM guests.


It has been tested with pv and hvm guests, with console=ttyS0,
console=hvc0, and earlyprintk=xen, with and without serial='pty' in the
VM config file.


Stefano Stabellini (2):
      hvc_xen: support PV on HVM consoles
      hvc_xen: implement multiconsole support

 drivers/tty/hvc/hvc_xen.c          |  461 ++++++++++++++++++++++++++++++++---
 include/xen/interface/hvm/params.h |    6 +-
 2 files changed, 426 insertions(+), 41 deletions(-)

A branch with these patches based on 3.2 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.2-multiconsole

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 Jan 26 12:42:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOeQ-00027e-74; Thu, 26 Jan 2012 12:42:02 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqOeO-00027Z-8k
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:42:00 +0000
Received: from [85.158.138.51:20161] by server-10.bemta-3.messagelabs.com id
	E6/AF-20948-71A412F4; Thu, 26 Jan 2012 12:41:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327581718!10710834!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10372 invoked from network); 26 Jan 2012 12:41:58 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:41:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10303737"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:41:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:41:58 +0000
Date: Thu, 26 Jan 2012 12:42:46 +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.1201261233050.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 0/2] Xen (PV and HVM) multiple PV consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series (sent before a few times) achieves two goals:

- make PV consoles work for PV on HVM guests;

- implement support for multiple PV consoles for PV and PV on HVM guests.


It has been tested with pv and hvm guests, with console=ttyS0,
console=hvc0, and earlyprintk=xen, with and without serial='pty' in the
VM config file.


Stefano Stabellini (2):
      hvc_xen: support PV on HVM consoles
      hvc_xen: implement multiconsole support

 drivers/tty/hvc/hvc_xen.c          |  461 ++++++++++++++++++++++++++++++++---
 include/xen/interface/hvm/params.h |    6 +-
 2 files changed, 426 insertions(+), 41 deletions(-)

A branch with these patches based on 3.2 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.2-multiconsole

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 Jan 26 12:43:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:43:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOfG-0002AS-LC; Thu, 26 Jan 2012 12:42:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqOfF-0002AI-D8
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:42:53 +0000
Received: from [85.158.138.51:9979] by server-6.bemta-3.messagelabs.com id
	CB/DF-31032-C4A412F4; Thu, 26 Jan 2012 12:42:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327581769!5613861!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11032 invoked from network); 26 Jan 2012 12:42:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:42:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21302861"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 07:42:49 -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, 26 Jan 2012 07:42: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 q0QCgfL1009171;
	Thu, 26 Jan 2012 04:42:41 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 12:43:26 +0000
Message-ID: <1327581807-17276-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.1201261233050.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c          |   86 +++++++++++++++++++++++++++++-------
 include/xen/interface/hvm/params.h |    6 ++-
 2 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 52fdf60..dd6641f 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -24,9 +24,12 @@
 #include <linux/init.h>
 #include <linux/types.h>
 
+#include <asm/io.h>
 #include <asm/xen/hypervisor.h>
 
 #include <xen/xen.h>
+#include <xen/interface/xen.h>
+#include <xen/hvm.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
@@ -42,9 +45,13 @@ static int xencons_irq;
 /* ------------------------------------------------------------------ */
 
 static unsigned long console_pfn = ~0ul;
+static unsigned int console_evtchn = ~0ul;
+static struct xencons_interface *xencons_if = NULL;
 
 static inline struct xencons_interface *xencons_interface(void)
 {
+	if (xencons_if != NULL)
+		return xencons_if;
 	if (console_pfn == ~0ul)
 		return mfn_to_virt(xen_start_info->console.domU.mfn);
 	else
@@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
 static inline void notify_daemon(void)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
+	if (console_evtchn == ~0ul)
+		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
+	else
+		notify_remote_via_evtchn(console_evtchn);
 }
 
 static int __write_console(const char *data, int len)
@@ -157,28 +167,65 @@ static struct hv_ops dom0_hvc_ops = {
 	.notifier_hangup = notifier_hangup_irq,
 };
 
+static int xen_hvm_console_init(void)
+{
+	int r;
+	uint64_t v = 0;
+	unsigned long mfn;
+
+	if (!xen_hvm_domain())
+		return -ENODEV;
+
+	if (xencons_if != NULL)
+		return -EBUSY;
+
+	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
+	if (r < 0)
+		return -ENODEV;
+	console_evtchn = v;
+	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
+	if (r < 0)
+		return -ENODEV;
+	mfn = v;
+	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (xencons_if == NULL)
+		return -ENODEV;
+
+	return 0;
+}
+
 static int __init xen_hvc_init(void)
 {
 	struct hvc_struct *hp;
 	struct hv_ops *ops;
+	int r;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
+		return -ENODEV;
+
+	if (xen_pv_domain() && !xen_initial_domain() &&
+			!xen_start_info->console.domU.evtchn)
 		return -ENODEV;
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
 		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
 	} else {
-		if (!xen_start_info->console.domU.evtchn)
-			return -ENODEV;
-
 		ops = &domU_hvc_ops;
-		xencons_irq = bind_evtchn_to_irq(xen_start_info->console.domU.evtchn);
+		if (xen_pv_domain()) {
+			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
+			console_evtchn = xen_start_info->console.domU.evtchn;
+		} else {
+			r = xen_hvm_console_init();
+			if (r < 0)
+				return r;
+		}
+		xencons_irq = bind_evtchn_to_irq(console_evtchn);
+		if (xencons_irq < 0)
+			xencons_irq = 0; /* NO_IRQ */
+		else
+			irq_set_noprobe(xencons_irq);
 	}
-	if (xencons_irq < 0)
-		xencons_irq = 0; /* NO_IRQ */
-	else
-		irq_set_noprobe(xencons_irq);
 
 	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
 	if (IS_ERR(hp))
@@ -186,15 +233,13 @@ static int __init xen_hvc_init(void)
 
 	hvc = hp;
 
-	console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-
 	return 0;
 }
 
 void xen_console_resume(void)
 {
 	if (xencons_irq)
-		rebind_evtchn_irq(xen_start_info->console.domU.evtchn, xencons_irq);
+		rebind_evtchn_irq(console_evtchn, xencons_irq);
 }
 
 static void __exit xen_hvc_fini(void)
@@ -205,16 +250,22 @@ static void __exit xen_hvc_fini(void)
 
 static int xen_cons_init(void)
 {
-	struct hv_ops *ops;
+	const struct hv_ops *ops;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return 0;
 
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
-	else
+	else {
 		ops = &domU_hvc_ops;
 
+		if (xen_pv_domain())
+			console_evtchn = xen_start_info->console.domU.evtchn;
+		else
+			xen_hvm_console_init();
+	}
+
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
@@ -230,6 +281,9 @@ static void xenboot_write_console(struct console *console, const char *string,
 	unsigned int linelen, off = 0;
 	const char *pos;
 
+	if (!xen_pv_domain())
+		return;
+
 	dom0_write_console(0, string, len);
 
 	if (xen_initial_domain())
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index 1888d8c..1b4f923 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -90,6 +90,10 @@
 /* Boolean: Enable aligning all periodic vpts to reduce interrupts */
 #define HVM_PARAM_VPT_ALIGN    16
 
-#define HVM_NR_PARAMS          17
+/* Console debug shared memory ring and event channel */
+#define HVM_PARAM_CONSOLE_PFN    17
+#define HVM_PARAM_CONSOLE_EVTCHN 18
+
+#define HVM_NR_PARAMS          19
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_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 Jan 26 12:43:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:43:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOfG-0002AS-LC; Thu, 26 Jan 2012 12:42:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqOfF-0002AI-D8
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:42:53 +0000
Received: from [85.158.138.51:9979] by server-6.bemta-3.messagelabs.com id
	CB/DF-31032-C4A412F4; Thu, 26 Jan 2012 12:42:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327581769!5613861!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11032 invoked from network); 26 Jan 2012 12:42:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:42:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21302861"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 07:42:49 -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, 26 Jan 2012 07:42: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 q0QCgfL1009171;
	Thu, 26 Jan 2012 04:42:41 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 12:43:26 +0000
Message-ID: <1327581807-17276-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.1201261233050.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c          |   86 +++++++++++++++++++++++++++++-------
 include/xen/interface/hvm/params.h |    6 ++-
 2 files changed, 75 insertions(+), 17 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 52fdf60..dd6641f 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -24,9 +24,12 @@
 #include <linux/init.h>
 #include <linux/types.h>
 
+#include <asm/io.h>
 #include <asm/xen/hypervisor.h>
 
 #include <xen/xen.h>
+#include <xen/interface/xen.h>
+#include <xen/hvm.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
@@ -42,9 +45,13 @@ static int xencons_irq;
 /* ------------------------------------------------------------------ */
 
 static unsigned long console_pfn = ~0ul;
+static unsigned int console_evtchn = ~0ul;
+static struct xencons_interface *xencons_if = NULL;
 
 static inline struct xencons_interface *xencons_interface(void)
 {
+	if (xencons_if != NULL)
+		return xencons_if;
 	if (console_pfn == ~0ul)
 		return mfn_to_virt(xen_start_info->console.domU.mfn);
 	else
@@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
 static inline void notify_daemon(void)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
+	if (console_evtchn == ~0ul)
+		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
+	else
+		notify_remote_via_evtchn(console_evtchn);
 }
 
 static int __write_console(const char *data, int len)
@@ -157,28 +167,65 @@ static struct hv_ops dom0_hvc_ops = {
 	.notifier_hangup = notifier_hangup_irq,
 };
 
+static int xen_hvm_console_init(void)
+{
+	int r;
+	uint64_t v = 0;
+	unsigned long mfn;
+
+	if (!xen_hvm_domain())
+		return -ENODEV;
+
+	if (xencons_if != NULL)
+		return -EBUSY;
+
+	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
+	if (r < 0)
+		return -ENODEV;
+	console_evtchn = v;
+	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
+	if (r < 0)
+		return -ENODEV;
+	mfn = v;
+	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (xencons_if == NULL)
+		return -ENODEV;
+
+	return 0;
+}
+
 static int __init xen_hvc_init(void)
 {
 	struct hvc_struct *hp;
 	struct hv_ops *ops;
+	int r;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
+		return -ENODEV;
+
+	if (xen_pv_domain() && !xen_initial_domain() &&
+			!xen_start_info->console.domU.evtchn)
 		return -ENODEV;
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
 		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
 	} else {
-		if (!xen_start_info->console.domU.evtchn)
-			return -ENODEV;
-
 		ops = &domU_hvc_ops;
-		xencons_irq = bind_evtchn_to_irq(xen_start_info->console.domU.evtchn);
+		if (xen_pv_domain()) {
+			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
+			console_evtchn = xen_start_info->console.domU.evtchn;
+		} else {
+			r = xen_hvm_console_init();
+			if (r < 0)
+				return r;
+		}
+		xencons_irq = bind_evtchn_to_irq(console_evtchn);
+		if (xencons_irq < 0)
+			xencons_irq = 0; /* NO_IRQ */
+		else
+			irq_set_noprobe(xencons_irq);
 	}
-	if (xencons_irq < 0)
-		xencons_irq = 0; /* NO_IRQ */
-	else
-		irq_set_noprobe(xencons_irq);
 
 	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
 	if (IS_ERR(hp))
@@ -186,15 +233,13 @@ static int __init xen_hvc_init(void)
 
 	hvc = hp;
 
-	console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-
 	return 0;
 }
 
 void xen_console_resume(void)
 {
 	if (xencons_irq)
-		rebind_evtchn_irq(xen_start_info->console.domU.evtchn, xencons_irq);
+		rebind_evtchn_irq(console_evtchn, xencons_irq);
 }
 
 static void __exit xen_hvc_fini(void)
@@ -205,16 +250,22 @@ static void __exit xen_hvc_fini(void)
 
 static int xen_cons_init(void)
 {
-	struct hv_ops *ops;
+	const struct hv_ops *ops;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return 0;
 
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
-	else
+	else {
 		ops = &domU_hvc_ops;
 
+		if (xen_pv_domain())
+			console_evtchn = xen_start_info->console.domU.evtchn;
+		else
+			xen_hvm_console_init();
+	}
+
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
@@ -230,6 +281,9 @@ static void xenboot_write_console(struct console *console, const char *string,
 	unsigned int linelen, off = 0;
 	const char *pos;
 
+	if (!xen_pv_domain())
+		return;
+
 	dom0_write_console(0, string, len);
 
 	if (xen_initial_domain())
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index 1888d8c..1b4f923 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -90,6 +90,10 @@
 /* Boolean: Enable aligning all periodic vpts to reduce interrupts */
 #define HVM_PARAM_VPT_ALIGN    16
 
-#define HVM_NR_PARAMS          17
+/* Console debug shared memory ring and event channel */
+#define HVM_PARAM_CONSOLE_PFN    17
+#define HVM_PARAM_CONSOLE_EVTCHN 18
+
+#define HVM_NR_PARAMS          19
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_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 Jan 26 12:43:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOfU-0002Bk-2h; Thu, 26 Jan 2012 12:43:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqOfR-0002BS-T9
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:43:06 +0000
Received: from [85.158.139.83:30743] by server-9.bemta-5.messagelabs.com id
	4A/F1-24580-85A412F4; Thu, 26 Jan 2012 12:43:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327581775!5154694!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12511 invoked from network); 26 Jan 2012 12:42:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:42:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179188629"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 07:42:55 -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, 26 Jan 2012 07:42:55 -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 q0QCgfL2009171;
	Thu, 26 Jan 2012 04:42:43 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 12:43:27 +0000
Message-ID: <1327581807-17276-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.1201261233050.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements support for multiple consoles:
consoles other than the first one are setup using the traditional xenbus
and grant-table based mechanism.
We use a list to keep track of the allocated consoles, we don't
expect too many of them anyway.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 383 insertions(+), 56 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index dd6641f..97732fb 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -23,6 +23,7 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/types.h>
+#include <linux/list.h>
 
 #include <asm/io.h>
 #include <asm/xen/hypervisor.h>
@@ -30,47 +31,69 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/hvm.h>
+#include <xen/grant_table.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
 #include <xen/hvc-console.h>
+#include <xen/xenbus.h>
 
 #include "hvc_console.h"
 
 #define HVC_COOKIE   0x58656e /* "Xen" in hex */
 
-static struct hvc_struct *hvc;
-static int xencons_irq;
+struct xencons_info {
+	struct list_head list;
+	struct xenbus_device *xbdev;
+	struct xencons_interface *intf;
+	unsigned int evtchn;
+	struct hvc_struct *hvc;
+	int irq;
+	int vtermno;
+	grant_ref_t gntref;
+};
+
+static LIST_HEAD(xenconsoles);
+static DEFINE_SPINLOCK(xencons_lock);
+static struct xenbus_driver xencons_driver;
 
 /* ------------------------------------------------------------------ */
 
-static unsigned long console_pfn = ~0ul;
-static unsigned int console_evtchn = ~0ul;
-static struct xencons_interface *xencons_if = NULL;
+static struct xencons_info *vtermno_to_xencons(int vtermno)
+{
+	struct xencons_info *entry, *ret = NULL;
+
+	if (list_empty(&xenconsoles))
+			return NULL;
 
-static inline struct xencons_interface *xencons_interface(void)
+	spin_lock(&xencons_lock);
+	list_for_each_entry(entry, &xenconsoles, list) {
+		if (entry->vtermno == vtermno) {
+			ret  = entry;
+			break;
+		}
+	}
+	spin_unlock(&xencons_lock);
+
+	return ret;
+}
+
+static inline int xenbus_devid_to_vtermno(int devid)
 {
-	if (xencons_if != NULL)
-		return xencons_if;
-	if (console_pfn == ~0ul)
-		return mfn_to_virt(xen_start_info->console.domU.mfn);
-	else
-		return __va(console_pfn << PAGE_SHIFT);
+	return devid + HVC_COOKIE;
 }
 
-static inline void notify_daemon(void)
+static inline void notify_daemon(struct xencons_info *cons)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	if (console_evtchn == ~0ul)
-		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
-	else
-		notify_remote_via_evtchn(console_evtchn);
+	notify_remote_via_evtchn(cons->evtchn);
 }
 
-static int __write_console(const char *data, int len)
+static int __write_console(struct xencons_info *xencons,
+		const char *data, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
 	XENCONS_RING_IDX cons, prod;
+	struct xencons_interface *intf = xencons->intf;
 	int sent = 0;
 
 	cons = intf->out_cons;
@@ -85,13 +108,16 @@ static int __write_console(const char *data, int len)
 	intf->out_prod = prod;
 
 	if (sent)
-		notify_daemon();
+		notify_daemon(xencons);
 	return sent;
 }
 
 static int domU_write_console(uint32_t vtermno, const char *data, int len)
 {
 	int ret = len;
+	struct xencons_info *cons = vtermno_to_xencons(vtermno);
+	if (cons == NULL)
+		return -EINVAL;
 
 	/*
 	 * Make sure the whole buffer is emitted, polling if
@@ -100,7 +126,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 	 * kernel is crippled.
 	 */
 	while (len) {
-		int sent = __write_console(data, len);
+		int sent = __write_console(cons, data, len);
 		
 		data += sent;
 		len -= sent;
@@ -114,9 +140,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 
 static int domU_read_console(uint32_t vtermno, char *buf, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
+	struct xencons_interface *intf;
 	XENCONS_RING_IDX cons, prod;
 	int recv = 0;
+	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
+	if (xencons == NULL)
+		return -EINVAL;
+	intf = xencons->intf;
 
 	cons = intf->in_cons;
 	prod = intf->in_prod;
@@ -129,7 +159,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
 	mb();			/* read ring before consuming */
 	intf->in_cons = cons;
 
-	notify_daemon();
+	notify_daemon(xencons);
 	return recv;
 }
 
@@ -172,33 +202,109 @@ static int xen_hvm_console_init(void)
 	int r;
 	uint64_t v = 0;
 	unsigned long mfn;
+	struct xencons_info *info;
 
 	if (!xen_hvm_domain())
 		return -ENODEV;
 
-	if (xencons_if != NULL)
-		return -EBUSY;
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
 
 	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
-	console_evtchn = v;
+	}
+	info->evtchn = v;
 	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
+	}
 	mfn = v;
-	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
-	if (xencons_if == NULL)
+	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (info->intf == NULL) {
+		kfree(info);
+		return -ENODEV;
+	}
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_pv_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_pv_domain())
 		return -ENODEV;
 
+	if (!xen_start_info->console.domU.evtchn)
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
+
+	info->evtchn = xen_start_info->console.domU.evtchn;
+	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_initial_domain_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
 	return 0;
 }
 
 static int __init xen_hvc_init(void)
 {
-	struct hvc_struct *hp;
-	struct hv_ops *ops;
 	int r;
+	struct xencons_info *info;
+	const struct hv_ops *ops;
 
 	if (!xen_domain())
 		return -ENODEV;
@@ -209,43 +315,251 @@ static int __init xen_hvc_init(void)
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
-		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+		r = xen_initial_domain_console_init();
+		if (r < 0)
+			return r;
+		info = vtermno_to_xencons(HVC_COOKIE);
 	} else {
 		ops = &domU_hvc_ops;
-		if (xen_pv_domain()) {
-			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-			console_evtchn = xen_start_info->console.domU.evtchn;
-		} else {
+		if (xen_hvm_domain())
 			r = xen_hvm_console_init();
-			if (r < 0)
-				return r;
-		}
-		xencons_irq = bind_evtchn_to_irq(console_evtchn);
-		if (xencons_irq < 0)
-			xencons_irq = 0; /* NO_IRQ */
 		else
-			irq_set_noprobe(xencons_irq);
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
+
+		info = vtermno_to_xencons(HVC_COOKIE);
+		info->irq = bind_evtchn_to_irq(info->evtchn);
+	}
+	if (info->irq < 0)
+		info->irq = 0; /* NO_IRQ */
+	else
+		irq_set_noprobe(info->irq);
+
+	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
+	if (IS_ERR(info->hvc)) {
+		r = PTR_ERR(info->hvc);
+		spin_lock(&xencons_lock);
+		list_del(&info->list);
+		spin_unlock(&xencons_lock);
+		if (info->irq)
+			unbind_from_irqhandler(info->irq, NULL);
+		kfree(info);
+		return r;
 	}
 
-	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
-	if (IS_ERR(hp))
-		return PTR_ERR(hp);
+	return xenbus_register_frontend(&xencons_driver);
+}
 
-	hvc = hp;
+void xen_console_resume(void)
+{
+	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
+	if (info != NULL && info->irq)
+		rebind_evtchn_irq(info->evtchn, info->irq);
+}
 
+static void xencons_disconnect_backend(struct xencons_info *info)
+{
+	if (info->irq > 0)
+		unbind_from_irqhandler(info->irq, NULL);
+	info->irq = 0;
+	if (info->evtchn > 0)
+		xenbus_free_evtchn(info->xbdev, info->evtchn);
+	info->evtchn = 0;
+	if (info->gntref > 0)
+		gnttab_free_grant_references(info->gntref);
+	info->gntref = 0;
+	if (info->hvc != NULL)
+		hvc_remove(info->hvc);
+	info->hvc = NULL;
+}
+
+static void xencons_free(struct xencons_info *info)
+{
+	xencons_disconnect_backend(info);
+	free_page((unsigned long)info->intf);
+	info->intf = NULL;
+	info->vtermno = 0;
+	kfree(info);
+}
+
+static int xencons_remove(struct xenbus_device *dev)
+{
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	spin_lock(&xencons_lock);
+	list_del(&info->list);
+	spin_unlock(&xencons_lock);
+	xencons_free(info);
 	return 0;
 }
 
-void xen_console_resume(void)
+static int xencons_connect_backend(struct xenbus_device *dev,
+				  struct xencons_info *info)
+{
+	int ret, evtchn, devid, ref, irq;
+	struct xenbus_transaction xbt;
+	grant_ref_t gref_head;
+	unsigned long mfn;
+
+	ret = xenbus_alloc_evtchn(dev, &evtchn);
+	if (ret)
+		return ret;
+	info->evtchn = evtchn;
+	irq = bind_evtchn_to_irq(evtchn);
+	if (irq < 0)
+		return irq;
+	info->irq = irq;
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
+			irq, &domU_hvc_ops, 256);
+	if (IS_ERR(info->hvc))
+		return PTR_ERR(info->hvc);
+	if (xen_pv_domain())
+		mfn = virt_to_mfn(info->intf);
+	else
+		mfn = __pa(info->intf) >> PAGE_SHIFT;
+	ret = gnttab_alloc_grant_references(1, &gref_head);
+	if (ret < 0)
+		return ret;
+	info->gntref = gref_head;
+	ref = gnttab_claim_grant_reference(&gref_head);
+	if (ref < 0)
+		return ref;
+	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
+			mfn, 0);
+
+ again:
+	ret = xenbus_transaction_start(&xbt);
+	if (ret) {
+		xenbus_dev_fatal(dev, ret, "starting transaction");
+		return ret;
+	}
+	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
+			    evtchn);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_transaction_end(xbt, 0);
+	if (ret) {
+		if (ret == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, ret, "completing transaction");
+		return ret;
+	}
+
+	xenbus_switch_state(dev, XenbusStateInitialised);
+	return 0;
+
+ error_xenbus:
+	xenbus_transaction_end(xbt, 1);
+	xenbus_dev_fatal(dev, ret, "writing xenstore");
+	return ret;
+}
+
+static int __devinit xencons_probe(struct xenbus_device *dev,
+				  const struct xenbus_device_id *id)
 {
-	if (xencons_irq)
-		rebind_evtchn_irq(console_evtchn, xencons_irq);
+	int ret, devid;
+	struct xencons_info *info;
+
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	if (devid == 0)
+		return -ENODEV;
+
+	info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+	if (!info)
+		goto error_nomem;
+	dev_set_drvdata(&dev->dev, info);
+	info->xbdev = dev;
+	info->vtermno = xenbus_devid_to_vtermno(devid);
+	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+	if (!info->intf)
+		goto error_nomem;
+
+	ret = xencons_connect_backend(dev, info);
+	if (ret < 0)
+		goto error;
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+
+ error_nomem:
+	ret = -ENOMEM;
+	xenbus_dev_fatal(dev, ret, "allocating device memory");
+ error:
+	xencons_free(info);
+	return ret;
+}
+
+static int xencons_resume(struct xenbus_device *dev)
+{
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	xencons_disconnect_backend(info);
+	memset(info->intf, 0, PAGE_SIZE);
+	return xencons_connect_backend(dev, info);
 }
 
+static void xencons_backend_changed(struct xenbus_device *dev,
+				   enum xenbus_state backend_state)
+{
+	switch (backend_state) {
+	case XenbusStateReconfiguring:
+	case XenbusStateReconfigured:
+	case XenbusStateInitialising:
+	case XenbusStateInitialised:
+	case XenbusStateUnknown:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitWait:
+		break;
+
+	case XenbusStateConnected:
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateClosing:
+		xenbus_frontend_closed(dev);
+		break;
+	}
+}
+
+static const struct xenbus_device_id xencons_ids[] = {
+	{ "console" },
+	{ "" }
+};
+
+
 static void __exit xen_hvc_fini(void)
 {
-	if (hvc)
-		hvc_remove(hvc);
+	struct xencons_info *entry, *next;
+
+	if (list_empty(&xenconsoles))
+			return;
+
+	spin_lock(&xencons_lock);
+	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
+		list_del(&entry->list);
+		if (entry->xbdev)
+			xencons_remove(entry->xbdev);
+		else {
+			if (entry->irq > 0)
+				unbind_from_irqhandler(entry->irq, NULL);
+			if (entry->hvc);
+				hvc_remove(entry->hvc);
+			kfree(entry);
+		}
+	}
+	spin_unlock(&xencons_lock);
 }
 
 static int xen_cons_init(void)
@@ -258,18 +572,31 @@ static int xen_cons_init(void)
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
 	else {
+		int r;
 		ops = &domU_hvc_ops;
 
-		if (xen_pv_domain())
-			console_evtchn = xen_start_info->console.domU.evtchn;
+		if (xen_hvm_domain())
+			r = xen_hvm_console_init();
 		else
-			xen_hvm_console_init();
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
 	}
 
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
 
+static struct xenbus_driver xencons_driver = {
+	.name = "xenconsole",
+	.owner = THIS_MODULE,
+	.ids = xencons_ids,
+	.probe = xencons_probe,
+	.remove = xencons_remove,
+	.resume = xencons_resume,
+	.otherend_changed = xencons_backend_changed,
+};
+
 module_init(xen_hvc_init);
 module_exit(xen_hvc_fini);
 console_initcall(xen_cons_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:43:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOfU-0002Bk-2h; Thu, 26 Jan 2012 12:43:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqOfR-0002BS-T9
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:43:06 +0000
Received: from [85.158.139.83:30743] by server-9.bemta-5.messagelabs.com id
	4A/F1-24580-85A412F4; Thu, 26 Jan 2012 12:43:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327581775!5154694!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12511 invoked from network); 26 Jan 2012 12:42:57 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 12:42:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179188629"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 07:42:55 -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, 26 Jan 2012 07:42:55 -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 q0QCgfL2009171;
	Thu, 26 Jan 2012 04:42:43 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 12:43:27 +0000
Message-ID: <1327581807-17276-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.1201261233050.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements support for multiple consoles:
consoles other than the first one are setup using the traditional xenbus
and grant-table based mechanism.
We use a list to keep track of the allocated consoles, we don't
expect too many of them anyway.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 383 insertions(+), 56 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index dd6641f..97732fb 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -23,6 +23,7 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/types.h>
+#include <linux/list.h>
 
 #include <asm/io.h>
 #include <asm/xen/hypervisor.h>
@@ -30,47 +31,69 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/hvm.h>
+#include <xen/grant_table.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
 #include <xen/hvc-console.h>
+#include <xen/xenbus.h>
 
 #include "hvc_console.h"
 
 #define HVC_COOKIE   0x58656e /* "Xen" in hex */
 
-static struct hvc_struct *hvc;
-static int xencons_irq;
+struct xencons_info {
+	struct list_head list;
+	struct xenbus_device *xbdev;
+	struct xencons_interface *intf;
+	unsigned int evtchn;
+	struct hvc_struct *hvc;
+	int irq;
+	int vtermno;
+	grant_ref_t gntref;
+};
+
+static LIST_HEAD(xenconsoles);
+static DEFINE_SPINLOCK(xencons_lock);
+static struct xenbus_driver xencons_driver;
 
 /* ------------------------------------------------------------------ */
 
-static unsigned long console_pfn = ~0ul;
-static unsigned int console_evtchn = ~0ul;
-static struct xencons_interface *xencons_if = NULL;
+static struct xencons_info *vtermno_to_xencons(int vtermno)
+{
+	struct xencons_info *entry, *ret = NULL;
+
+	if (list_empty(&xenconsoles))
+			return NULL;
 
-static inline struct xencons_interface *xencons_interface(void)
+	spin_lock(&xencons_lock);
+	list_for_each_entry(entry, &xenconsoles, list) {
+		if (entry->vtermno == vtermno) {
+			ret  = entry;
+			break;
+		}
+	}
+	spin_unlock(&xencons_lock);
+
+	return ret;
+}
+
+static inline int xenbus_devid_to_vtermno(int devid)
 {
-	if (xencons_if != NULL)
-		return xencons_if;
-	if (console_pfn == ~0ul)
-		return mfn_to_virt(xen_start_info->console.domU.mfn);
-	else
-		return __va(console_pfn << PAGE_SHIFT);
+	return devid + HVC_COOKIE;
 }
 
-static inline void notify_daemon(void)
+static inline void notify_daemon(struct xencons_info *cons)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	if (console_evtchn == ~0ul)
-		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
-	else
-		notify_remote_via_evtchn(console_evtchn);
+	notify_remote_via_evtchn(cons->evtchn);
 }
 
-static int __write_console(const char *data, int len)
+static int __write_console(struct xencons_info *xencons,
+		const char *data, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
 	XENCONS_RING_IDX cons, prod;
+	struct xencons_interface *intf = xencons->intf;
 	int sent = 0;
 
 	cons = intf->out_cons;
@@ -85,13 +108,16 @@ static int __write_console(const char *data, int len)
 	intf->out_prod = prod;
 
 	if (sent)
-		notify_daemon();
+		notify_daemon(xencons);
 	return sent;
 }
 
 static int domU_write_console(uint32_t vtermno, const char *data, int len)
 {
 	int ret = len;
+	struct xencons_info *cons = vtermno_to_xencons(vtermno);
+	if (cons == NULL)
+		return -EINVAL;
 
 	/*
 	 * Make sure the whole buffer is emitted, polling if
@@ -100,7 +126,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 	 * kernel is crippled.
 	 */
 	while (len) {
-		int sent = __write_console(data, len);
+		int sent = __write_console(cons, data, len);
 		
 		data += sent;
 		len -= sent;
@@ -114,9 +140,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 
 static int domU_read_console(uint32_t vtermno, char *buf, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
+	struct xencons_interface *intf;
 	XENCONS_RING_IDX cons, prod;
 	int recv = 0;
+	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
+	if (xencons == NULL)
+		return -EINVAL;
+	intf = xencons->intf;
 
 	cons = intf->in_cons;
 	prod = intf->in_prod;
@@ -129,7 +159,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
 	mb();			/* read ring before consuming */
 	intf->in_cons = cons;
 
-	notify_daemon();
+	notify_daemon(xencons);
 	return recv;
 }
 
@@ -172,33 +202,109 @@ static int xen_hvm_console_init(void)
 	int r;
 	uint64_t v = 0;
 	unsigned long mfn;
+	struct xencons_info *info;
 
 	if (!xen_hvm_domain())
 		return -ENODEV;
 
-	if (xencons_if != NULL)
-		return -EBUSY;
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
 
 	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
-	console_evtchn = v;
+	}
+	info->evtchn = v;
 	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
+	}
 	mfn = v;
-	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
-	if (xencons_if == NULL)
+	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (info->intf == NULL) {
+		kfree(info);
+		return -ENODEV;
+	}
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_pv_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_pv_domain())
 		return -ENODEV;
 
+	if (!xen_start_info->console.domU.evtchn)
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
+
+	info->evtchn = xen_start_info->console.domU.evtchn;
+	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_initial_domain_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
 	return 0;
 }
 
 static int __init xen_hvc_init(void)
 {
-	struct hvc_struct *hp;
-	struct hv_ops *ops;
 	int r;
+	struct xencons_info *info;
+	const struct hv_ops *ops;
 
 	if (!xen_domain())
 		return -ENODEV;
@@ -209,43 +315,251 @@ static int __init xen_hvc_init(void)
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
-		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+		r = xen_initial_domain_console_init();
+		if (r < 0)
+			return r;
+		info = vtermno_to_xencons(HVC_COOKIE);
 	} else {
 		ops = &domU_hvc_ops;
-		if (xen_pv_domain()) {
-			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-			console_evtchn = xen_start_info->console.domU.evtchn;
-		} else {
+		if (xen_hvm_domain())
 			r = xen_hvm_console_init();
-			if (r < 0)
-				return r;
-		}
-		xencons_irq = bind_evtchn_to_irq(console_evtchn);
-		if (xencons_irq < 0)
-			xencons_irq = 0; /* NO_IRQ */
 		else
-			irq_set_noprobe(xencons_irq);
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
+
+		info = vtermno_to_xencons(HVC_COOKIE);
+		info->irq = bind_evtchn_to_irq(info->evtchn);
+	}
+	if (info->irq < 0)
+		info->irq = 0; /* NO_IRQ */
+	else
+		irq_set_noprobe(info->irq);
+
+	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
+	if (IS_ERR(info->hvc)) {
+		r = PTR_ERR(info->hvc);
+		spin_lock(&xencons_lock);
+		list_del(&info->list);
+		spin_unlock(&xencons_lock);
+		if (info->irq)
+			unbind_from_irqhandler(info->irq, NULL);
+		kfree(info);
+		return r;
 	}
 
-	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
-	if (IS_ERR(hp))
-		return PTR_ERR(hp);
+	return xenbus_register_frontend(&xencons_driver);
+}
 
-	hvc = hp;
+void xen_console_resume(void)
+{
+	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
+	if (info != NULL && info->irq)
+		rebind_evtchn_irq(info->evtchn, info->irq);
+}
 
+static void xencons_disconnect_backend(struct xencons_info *info)
+{
+	if (info->irq > 0)
+		unbind_from_irqhandler(info->irq, NULL);
+	info->irq = 0;
+	if (info->evtchn > 0)
+		xenbus_free_evtchn(info->xbdev, info->evtchn);
+	info->evtchn = 0;
+	if (info->gntref > 0)
+		gnttab_free_grant_references(info->gntref);
+	info->gntref = 0;
+	if (info->hvc != NULL)
+		hvc_remove(info->hvc);
+	info->hvc = NULL;
+}
+
+static void xencons_free(struct xencons_info *info)
+{
+	xencons_disconnect_backend(info);
+	free_page((unsigned long)info->intf);
+	info->intf = NULL;
+	info->vtermno = 0;
+	kfree(info);
+}
+
+static int xencons_remove(struct xenbus_device *dev)
+{
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	spin_lock(&xencons_lock);
+	list_del(&info->list);
+	spin_unlock(&xencons_lock);
+	xencons_free(info);
 	return 0;
 }
 
-void xen_console_resume(void)
+static int xencons_connect_backend(struct xenbus_device *dev,
+				  struct xencons_info *info)
+{
+	int ret, evtchn, devid, ref, irq;
+	struct xenbus_transaction xbt;
+	grant_ref_t gref_head;
+	unsigned long mfn;
+
+	ret = xenbus_alloc_evtchn(dev, &evtchn);
+	if (ret)
+		return ret;
+	info->evtchn = evtchn;
+	irq = bind_evtchn_to_irq(evtchn);
+	if (irq < 0)
+		return irq;
+	info->irq = irq;
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
+			irq, &domU_hvc_ops, 256);
+	if (IS_ERR(info->hvc))
+		return PTR_ERR(info->hvc);
+	if (xen_pv_domain())
+		mfn = virt_to_mfn(info->intf);
+	else
+		mfn = __pa(info->intf) >> PAGE_SHIFT;
+	ret = gnttab_alloc_grant_references(1, &gref_head);
+	if (ret < 0)
+		return ret;
+	info->gntref = gref_head;
+	ref = gnttab_claim_grant_reference(&gref_head);
+	if (ref < 0)
+		return ref;
+	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
+			mfn, 0);
+
+ again:
+	ret = xenbus_transaction_start(&xbt);
+	if (ret) {
+		xenbus_dev_fatal(dev, ret, "starting transaction");
+		return ret;
+	}
+	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
+			    evtchn);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_transaction_end(xbt, 0);
+	if (ret) {
+		if (ret == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, ret, "completing transaction");
+		return ret;
+	}
+
+	xenbus_switch_state(dev, XenbusStateInitialised);
+	return 0;
+
+ error_xenbus:
+	xenbus_transaction_end(xbt, 1);
+	xenbus_dev_fatal(dev, ret, "writing xenstore");
+	return ret;
+}
+
+static int __devinit xencons_probe(struct xenbus_device *dev,
+				  const struct xenbus_device_id *id)
 {
-	if (xencons_irq)
-		rebind_evtchn_irq(console_evtchn, xencons_irq);
+	int ret, devid;
+	struct xencons_info *info;
+
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	if (devid == 0)
+		return -ENODEV;
+
+	info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+	if (!info)
+		goto error_nomem;
+	dev_set_drvdata(&dev->dev, info);
+	info->xbdev = dev;
+	info->vtermno = xenbus_devid_to_vtermno(devid);
+	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+	if (!info->intf)
+		goto error_nomem;
+
+	ret = xencons_connect_backend(dev, info);
+	if (ret < 0)
+		goto error;
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+
+ error_nomem:
+	ret = -ENOMEM;
+	xenbus_dev_fatal(dev, ret, "allocating device memory");
+ error:
+	xencons_free(info);
+	return ret;
+}
+
+static int xencons_resume(struct xenbus_device *dev)
+{
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	xencons_disconnect_backend(info);
+	memset(info->intf, 0, PAGE_SIZE);
+	return xencons_connect_backend(dev, info);
 }
 
+static void xencons_backend_changed(struct xenbus_device *dev,
+				   enum xenbus_state backend_state)
+{
+	switch (backend_state) {
+	case XenbusStateReconfiguring:
+	case XenbusStateReconfigured:
+	case XenbusStateInitialising:
+	case XenbusStateInitialised:
+	case XenbusStateUnknown:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitWait:
+		break;
+
+	case XenbusStateConnected:
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateClosing:
+		xenbus_frontend_closed(dev);
+		break;
+	}
+}
+
+static const struct xenbus_device_id xencons_ids[] = {
+	{ "console" },
+	{ "" }
+};
+
+
 static void __exit xen_hvc_fini(void)
 {
-	if (hvc)
-		hvc_remove(hvc);
+	struct xencons_info *entry, *next;
+
+	if (list_empty(&xenconsoles))
+			return;
+
+	spin_lock(&xencons_lock);
+	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
+		list_del(&entry->list);
+		if (entry->xbdev)
+			xencons_remove(entry->xbdev);
+		else {
+			if (entry->irq > 0)
+				unbind_from_irqhandler(entry->irq, NULL);
+			if (entry->hvc);
+				hvc_remove(entry->hvc);
+			kfree(entry);
+		}
+	}
+	spin_unlock(&xencons_lock);
 }
 
 static int xen_cons_init(void)
@@ -258,18 +572,31 @@ static int xen_cons_init(void)
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
 	else {
+		int r;
 		ops = &domU_hvc_ops;
 
-		if (xen_pv_domain())
-			console_evtchn = xen_start_info->console.domU.evtchn;
+		if (xen_hvm_domain())
+			r = xen_hvm_console_init();
 		else
-			xen_hvm_console_init();
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
 	}
 
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
 
+static struct xenbus_driver xencons_driver = {
+	.name = "xenconsole",
+	.owner = THIS_MODULE,
+	.ids = xencons_ids,
+	.probe = xencons_probe,
+	.remove = xencons_remove,
+	.resume = xencons_resume,
+	.otherend_changed = xencons_backend_changed,
+};
+
 module_init(xen_hvc_init);
 module_exit(xen_hvc_fini);
 console_initcall(xen_cons_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:43:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:43:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOfh-0002E0-GX; Thu, 26 Jan 2012 12:43:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqOff-0002Da-1b
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:43:19 +0000
Received: from [85.158.139.83:37959] by server-11.bemta-5.messagelabs.com id
	B0/30-18383-46A412F4; Thu, 26 Jan 2012 12:43:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327581795!12503170!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1115 invoked from network); 26 Jan 2012 12:43:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 12:43:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327581794; l=4525;
	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=sQuop6gW5GzNB75AAxtKiS8mUbM=;
	b=kiumT8Tb4/HD4YtpY0etM25acwvQtb1LUeNphEj8NRXytmBKJ+f9x6DQa9eG7AJe4rK
	yIXibzy/WTcauRYdimSr/BPYB7BhzADS5EhKh6borE8Kztu/fbH1Xnau8XGuaT+5WEtzy
	uOj2Us2GoKZZdtBnwjuvXzd/M79Em7NGiA0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo49) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y014e6o0QBYY2I ;
	Thu, 26 Jan 2012 13:43:01 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 57EE418637; Thu, 26 Jan 2012 13:43:04 +0100 (CET)
Date: Thu, 26 Jan 2012 13:43:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126124304.GA3355@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
	<20120126094621.GA21629@aepfle.de>
	<01c35254dd14ced855caac42bdfcccf0.squirrel@webmail.lagarcavilla.org>
	<20120126120506.GA545@aepfle.de>
	<251543dc172738014ff5bd13c5614c3d.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <251543dc172738014ff5bd13c5614c3d.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix 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, Jan 26, Andres Lagar-Cavilla wrote:

> > On Thu, Jan 26, Andres Lagar-Cavilla wrote:
> >
> >> Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
> >> provide feedback as to whether
> >> 1. remove p2m_ram_paging_in
> >> 2. rename p2m_ram_paging_in_start to p2m_ram_paging_in
> >>
> >> sounds like a good plan?
> >
> > In my opinion the common case is that evicted pages get populated, an
> > request is sent. Later an response is expected to make room in the ring.
> >
> > If p2m_mem_paging_populate allocates a page for the guest, it can let
> > the pager know that it did so (or failed to allocate one).
> > If there is a page already, the pager can copy the gfn content into a
> > buffer, put a pointer to it in the response and let
> > p2m_mem_paging_resume() handle both the ring accounting (as it does now)
> > and also the copy_from_user.
> 
> So, this would bounce the page contents twice for the case when the page
> hasn't yet been evicted?

If it was not evicted, then nothing has to be done. In theory the page
could be resumed right away. But you wanted the notification, so a
kind-of dummy request has to be sent. The pager itself will figure out
quickly that the page was not evicted yet, so all it can do is to send a
dummy response.
I'm not sure what you mean with bouncing it twice. The pager itself has
likely written the page, so some IO happend. The hypervisor will find a
mfn for the gfn, right now it does nothing but doing p2mt changes.

> > If page allocation failed, the pager has to allocate one via
> > p2m_mem_paging_prep() as it is done now, as an intermediate step.
> 
> The issue of failed allocations is more pervasive. It also affects mem
> sharing. And even PoD. What I'm trying to say is that even though your
> solution seems to work (as long as the pager does dom0 ballooning to free
> up some memory in between populate and prep!), we need a more generic
> mechanism. Something along the lines of an ENOMEM mem_event ring, and a
> matching dom0 daemon.

I'm not sure how all that relates to putting an alloc_domheap_page()
into p2m_mem_paging_populate() and let the pager know about the results.

> >
> > The buffer page handling in the pager is probably simple, it needs to
> > maintain RING_SIZE() buffers. There cant be more than that in flight
> > because thats the limit of requests as well. In other words, the pager
> > does not need to wait for p2m_mem_paging_resume() to run and pull the
> > buffer content.
> >
> >
> > If the "populate - allocate - put_request - get_request - fill_buffer -
> > put_response - resume  get_response - copy_from_buffer - resume_vcpu"
> > cycle works, it would reduce the overall amount of work to be done
> > during paging, even if the hypercalls itself are not the bottleneck.
> > It all depends on the possibility to allocate a page in the various
> > contexts where p2m_mem_paging_populate is called.
> 
> The gist here is that the paging_load call would be removed?

No, it is required if alloc_domheap_page() in
p2m_mem_paging_populate() fails. Then the pager has to take the "slow
path" and try until it gets a page, like it does now.

> I like the general direction, but one excellent property of paging_resume
> is that it doesn't fail. This is particularly important since we already
> do resumes via ring responses and event channel kicks (see below). So, if
> resume needs to propagate failures back to the pager, things get icky.
> 
> (paging_load is restartable, see other email)

Once the request is sent, all what can happen is that the copy_from_user
fails. And in that case the guest is in an undefined state. Perhaps such
copy_from_user handling can be fixed to be reliable. In that case of
course my idea wont work.

> > The resume part could be done via eventchannel and
> > XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME could be removed.
> 
> This is already the case. I'm not eager to remove the domctl, but resuming
> via event channel kick only is in place.

It looks to me like resume is currently called twice in xenpaging, once
per ioctl and once per event channel.

> > Also the question is if freeing one p2mt is more important than reducing
> > the number if hypercalls to execute at runtime.
> 
> Agreed. However, eliminating code complexity is also useful, and these two
> ram_paging_in states cause everyone headaches.

Well, its not so alien to me after starring at and tracing it long
enough.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:43:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:43:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOfh-0002E0-GX; Thu, 26 Jan 2012 12:43:21 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqOff-0002Da-1b
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:43:19 +0000
Received: from [85.158.139.83:37959] by server-11.bemta-5.messagelabs.com id
	B0/30-18383-46A412F4; Thu, 26 Jan 2012 12:43:16 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327581795!12503170!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1115 invoked from network); 26 Jan 2012 12:43:15 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 12:43:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327581794; l=4525;
	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=sQuop6gW5GzNB75AAxtKiS8mUbM=;
	b=kiumT8Tb4/HD4YtpY0etM25acwvQtb1LUeNphEj8NRXytmBKJ+f9x6DQa9eG7AJe4rK
	yIXibzy/WTcauRYdimSr/BPYB7BhzADS5EhKh6borE8Kztu/fbH1Xnau8XGuaT+5WEtzy
	uOj2Us2GoKZZdtBnwjuvXzd/M79Em7NGiA0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo49) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y014e6o0QBYY2I ;
	Thu, 26 Jan 2012 13:43:01 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 57EE418637; Thu, 26 Jan 2012 13:43:04 +0100 (CET)
Date: Thu, 26 Jan 2012 13:43:04 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126124304.GA3355@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<143e4982c9bf0da5d8fe.1327550005@xdev.gridcentric.ca>
	<20120126094621.GA21629@aepfle.de>
	<01c35254dd14ced855caac42bdfcccf0.squirrel@webmail.lagarcavilla.org>
	<20120126120506.GA545@aepfle.de>
	<251543dc172738014ff5bd13c5614c3d.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <251543dc172738014ff5bd13c5614c3d.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 1 of 8] x86/mm: Fix 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, Jan 26, Andres Lagar-Cavilla wrote:

> > On Thu, Jan 26, Andres Lagar-Cavilla wrote:
> >
> >> Now, afaict, the p2m_ram_paging_in state is not needed anymore. Can you
> >> provide feedback as to whether
> >> 1. remove p2m_ram_paging_in
> >> 2. rename p2m_ram_paging_in_start to p2m_ram_paging_in
> >>
> >> sounds like a good plan?
> >
> > In my opinion the common case is that evicted pages get populated, an
> > request is sent. Later an response is expected to make room in the ring.
> >
> > If p2m_mem_paging_populate allocates a page for the guest, it can let
> > the pager know that it did so (or failed to allocate one).
> > If there is a page already, the pager can copy the gfn content into a
> > buffer, put a pointer to it in the response and let
> > p2m_mem_paging_resume() handle both the ring accounting (as it does now)
> > and also the copy_from_user.
> 
> So, this would bounce the page contents twice for the case when the page
> hasn't yet been evicted?

If it was not evicted, then nothing has to be done. In theory the page
could be resumed right away. But you wanted the notification, so a
kind-of dummy request has to be sent. The pager itself will figure out
quickly that the page was not evicted yet, so all it can do is to send a
dummy response.
I'm not sure what you mean with bouncing it twice. The pager itself has
likely written the page, so some IO happend. The hypervisor will find a
mfn for the gfn, right now it does nothing but doing p2mt changes.

> > If page allocation failed, the pager has to allocate one via
> > p2m_mem_paging_prep() as it is done now, as an intermediate step.
> 
> The issue of failed allocations is more pervasive. It also affects mem
> sharing. And even PoD. What I'm trying to say is that even though your
> solution seems to work (as long as the pager does dom0 ballooning to free
> up some memory in between populate and prep!), we need a more generic
> mechanism. Something along the lines of an ENOMEM mem_event ring, and a
> matching dom0 daemon.

I'm not sure how all that relates to putting an alloc_domheap_page()
into p2m_mem_paging_populate() and let the pager know about the results.

> >
> > The buffer page handling in the pager is probably simple, it needs to
> > maintain RING_SIZE() buffers. There cant be more than that in flight
> > because thats the limit of requests as well. In other words, the pager
> > does not need to wait for p2m_mem_paging_resume() to run and pull the
> > buffer content.
> >
> >
> > If the "populate - allocate - put_request - get_request - fill_buffer -
> > put_response - resume  get_response - copy_from_buffer - resume_vcpu"
> > cycle works, it would reduce the overall amount of work to be done
> > during paging, even if the hypercalls itself are not the bottleneck.
> > It all depends on the possibility to allocate a page in the various
> > contexts where p2m_mem_paging_populate is called.
> 
> The gist here is that the paging_load call would be removed?

No, it is required if alloc_domheap_page() in
p2m_mem_paging_populate() fails. Then the pager has to take the "slow
path" and try until it gets a page, like it does now.

> I like the general direction, but one excellent property of paging_resume
> is that it doesn't fail. This is particularly important since we already
> do resumes via ring responses and event channel kicks (see below). So, if
> resume needs to propagate failures back to the pager, things get icky.
> 
> (paging_load is restartable, see other email)

Once the request is sent, all what can happen is that the copy_from_user
fails. And in that case the guest is in an undefined state. Perhaps such
copy_from_user handling can be fixed to be reliable. In that case of
course my idea wont work.

> > The resume part could be done via eventchannel and
> > XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME could be removed.
> 
> This is already the case. I'm not eager to remove the domctl, but resuming
> via event channel kick only is in place.

It looks to me like resume is currently called twice in xenpaging, once
per ioctl and once per event channel.

> > Also the question is if freeing one p2mt is more important than reducing
> > the number if hypercalls to execute at runtime.
> 
> Agreed. However, eliminating code complexity is also useful, and these two
> ram_paging_in states cause everyone headaches.

Well, its not so alien to me after starring at and tracing it long
enough.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:55:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOqg-00034W-2J; Thu, 26 Jan 2012 12:54:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqOqe-00034R-6S
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:54:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327582443!49886816!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18195 invoked from network); 26 Jan 2012 12:54:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 12:54:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqOqZ-000KN8-TJ; Thu, 26 Jan 2012 12:54:35 +0000
Date: Thu, 26 Jan 2012 12:54:35 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126125435.GB74165@ocelot.phlegethon.org>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1327548744@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 00 of 13] Sharing overhaul 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

At 22:32 -0500 on 25 Jan (1327530744), Andres Lagar-Cavilla wrote:
> This patch series brings about a set of changes to the sharing support
> in the hypervisor and tools. Specifically:
> 
> - Granular scalable locking: lock mfn's individually when sharing/unsharing
>   them. Do not rely on a global lock. Use RCU to maintain a list of all
>   shared frames for audit purposes.
> 
> - Refreshed stats: they now work (tm), and are accesible via libxc
>   and console.
> 
> - libxl/xl support to get sharing stats.
> 
> - New sharing command "add to physmap", to directly populate a new domain
>   with shared frames.
> 
> - Toolstack and memshr kept in sync.

Applied all except #12; thank you.

Tools maintainers, I think it would be a good idea to take #12 as well,
in spite of the commit message saying 'not necessarily expecting it be
added to the tree', in order to have an in-tree consumer of these
interfaces.

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 Jan 26 12:55:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12: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 1RqOqg-00034W-2J; Thu, 26 Jan 2012 12:54:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqOqe-00034R-6S
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:54:40 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327582443!49886816!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18195 invoked from network); 26 Jan 2012 12:54:03 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 12:54:03 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqOqZ-000KN8-TJ; Thu, 26 Jan 2012 12:54:35 +0000
Date: Thu, 26 Jan 2012 12:54:35 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126125435.GB74165@ocelot.phlegethon.org>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1327548744@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 00 of 13] Sharing overhaul 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

At 22:32 -0500 on 25 Jan (1327530744), Andres Lagar-Cavilla wrote:
> This patch series brings about a set of changes to the sharing support
> in the hypervisor and tools. Specifically:
> 
> - Granular scalable locking: lock mfn's individually when sharing/unsharing
>   them. Do not rely on a global lock. Use RCU to maintain a list of all
>   shared frames for audit purposes.
> 
> - Refreshed stats: they now work (tm), and are accesible via libxc
>   and console.
> 
> - libxl/xl support to get sharing stats.
> 
> - New sharing command "add to physmap", to directly populate a new domain
>   with shared frames.
> 
> - Toolstack and memshr kept in sync.

Applied all except #12; thank you.

Tools maintainers, I think it would be a good idea to take #12 as well,
in spite of the commit message saying 'not necessarily expecting it be
added to the tree', in order to have an in-tree consumer of these
interfaces.

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 Jan 26 12:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:58:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOtg-0003Dq-3x; Thu, 26 Jan 2012 12:57: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 1RqOte-0003Dg-2H
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:57:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327582659!12641675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30347 invoked from network); 26 Jan 2012 12:57:39 -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;
	26 Jan 2012 12:57:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10304162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:57: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, 26 Jan 2012 12:57: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 1RqOtW-0008Rp-0m;
	Thu, 26 Jan 2012 12:57:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqOtW-0005De-08;
	Thu, 26 Jan 2012 12:57:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11603-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 12:57:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11603: 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 11603 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11603/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  d8f280c78544
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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-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:   24568:d8f280c78544
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Jan 26 11:06:40 2012 +0000
    
    seabios: update to 1.6.3.1 release
    
    This is the latest seabios stable release.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24567:2998b3dbad7e
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Thu Jan 26 11:06:06 2012 +0000
    
    README: add upstream qemu dependecies
    
    Upstream Qemu, just added to the Xen build system, needs GLib 2.0 and
    pkg-config to compile.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24566:d5b706214616
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Jan 26 11:04:59 2012 +0000
    
    tools/libxc: fix error handling in xc_mem_paging_load
    
    xc_mem_paging_load() does not pass errors in errno and the actual
    errno from xc_mem_event_control() is overwritten by munlock().
    xenpaging_populate_page() needs to check errno, but with the switch to
    xc_mem_paging_load() it could not receive ENOMEM anymore.
    
    Update xc_mem_paging_load() to return -1 and preserve errno during
    munlock().
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24565:1e27e827e6a8
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Jan 26 11:03:50 2012 +0000
    
    xenoprof: Make the escape code consistent across 32 and  64-bit xen
    
    At the moment, the xenoprof escape code is defined as "~0UL".
    Unfortunately, this expands to 0xffffffff on 32-bit systems
    and 0xffffffffffffffff on 64-bit systems; with the result that
    while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
    "compat mode") is broken.
    
    This patch makes the definition consistent across architectures.
    In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
    but this was seen as an acceptable thing to do.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24564:768c932ea8da
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Jan 26 11:03:23 2012 +0000
    
    xenoprof: Use uint64_t explicitly for internal calls
    
    A recent changeset to make XENOPROF_ESCAPE_CODE consistent across
    32- and 64-bit builds caused a build failure, because values were
    passed through functions as "unsigned long".  Replace these with
    uint64_t explicitly.
    
    Also remove redundant function prototype from perfmon.c, now that
    it's in a header file.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24563:4271634e4c86
user:        Keir Fraser <keir@xen.org>
date:        Wed Jan 25 15:52:47 2012 +0000
    
    docs: Remove outdated LaTex documentation.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Jan 26 12:58:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:58:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOtg-0003Dq-3x; Thu, 26 Jan 2012 12:57: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 1RqOte-0003Dg-2H
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:57:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327582659!12641675!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30347 invoked from network); 26 Jan 2012 12:57:39 -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;
	26 Jan 2012 12:57:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10304162"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:57: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, 26 Jan 2012 12:57: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 1RqOtW-0008Rp-0m;
	Thu, 26 Jan 2012 12:57:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqOtW-0005De-08;
	Thu, 26 Jan 2012 12:57:38 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11603-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 12:57:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11603: 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 11603 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11603/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  d8f280c78544
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

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-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:   24568:d8f280c78544
tag:         tip
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Thu Jan 26 11:06:40 2012 +0000
    
    seabios: update to 1.6.3.1 release
    
    This is the latest seabios stable release.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24567:2998b3dbad7e
user:        Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date:        Thu Jan 26 11:06:06 2012 +0000
    
    README: add upstream qemu dependecies
    
    Upstream Qemu, just added to the Xen build system, needs GLib 2.0 and
    pkg-config to compile.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24566:d5b706214616
user:        Olaf Hering <olaf@aepfle.de>
date:        Thu Jan 26 11:04:59 2012 +0000
    
    tools/libxc: fix error handling in xc_mem_paging_load
    
    xc_mem_paging_load() does not pass errors in errno and the actual
    errno from xc_mem_event_control() is overwritten by munlock().
    xenpaging_populate_page() needs to check errno, but with the switch to
    xc_mem_paging_load() it could not receive ENOMEM anymore.
    
    Update xc_mem_paging_load() to return -1 and preserve errno during
    munlock().
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24565:1e27e827e6a8
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Jan 26 11:03:50 2012 +0000
    
    xenoprof: Make the escape code consistent across 32 and  64-bit xen
    
    At the moment, the xenoprof escape code is defined as "~0UL".
    Unfortunately, this expands to 0xffffffff on 32-bit systems
    and 0xffffffffffffffff on 64-bit systems; with the result that
    while 32-on-32 and 64-in-64 work fine, 32-on-64 (also known as
    "compat mode") is broken.
    
    This patch makes the definition consistent across architectures.
    In so doing, it will break old-32-bit-on-new-Xen, and vice versa;
    but this was seen as an acceptable thing to do.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24564:768c932ea8da
user:        George Dunlap <george.dunlap@eu.citrix.com>
date:        Thu Jan 26 11:03:23 2012 +0000
    
    xenoprof: Use uint64_t explicitly for internal calls
    
    A recent changeset to make XENOPROF_ESCAPE_CODE consistent across
    32- and 64-bit builds caused a build failure, because values were
    passed through functions as "unsigned long".  Replace these with
    uint64_t explicitly.
    
    Also remove redundant function prototype from perfmon.c, now that
    it's in a header file.
    
    Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
    Committed-by: Keir Fraser <keir@xen.org>
    
    
changeset:   24563:4271634e4c86
user:        Keir Fraser <keir@xen.org>
date:        Wed Jan 25 15:52:47 2012 +0000
    
    docs: Remove outdated LaTex documentation.
    
    Signed-off-by: Keir Fraser <keir@xen.org>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Jan 26 12:58:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:58:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOtn-0003ER-Gg; Thu, 26 Jan 2012 12:57: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 1RqOtm-0003Dx-Dn
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:57:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327582668!12684029!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21491 invoked from network); 26 Jan 2012 12:57:48 -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; 26 Jan 2012 12:57:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqOte-000KOJ-A9; Thu, 26 Jan 2012 12:57:46 +0000
Date: Thu, 26 Jan 2012 12:57:46 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126125746.GC74165@ocelot.phlegethon.org>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
	<20120112144325.GE8324@aepfle.de>
	<e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, andres@gridcentric.ca,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
	and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:04 -0800 on 12 Jan (1326355474), Andres Lagar-Cavilla wrote:
> > On Wed, Jan 11, Andres Lagar-Cavilla wrote:
> >
> >> +++ b/xen/include/public/domctl.h
> >
> >> +/* Use for teardown/setup of helper<->hypervisor interface for paging,
> >> + * access and sharing.*/
> >>  struct xen_domctl_mem_event_op {
> >>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
> >>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
> >>
> >> -    union {
> >> -        /* OP_ENABLE IN:  Virtual address of shared page */
> >> -        uint64_aligned_t shared_addr;
> >> -        /* PAGING_PREP IN: buffer to immediately fill page in */
> >> -        uint64_aligned_t buffer;
> >> -    } u;
> >> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
> >> page */
> >>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page
> >> */
> >>
> >> -    /* Other OPs */
> >> -    uint64_aligned_t gfn;          /* IN:  gfn of page being operated
> >> on */
> >> +    /* For binary backwards compatibility */
> >> +    uint64_aligned_t pad;
> >>  };
> >
> > Assuming this struct is routed through libxc, and libxc gets a new
> > SONAME for every release, doesnt this mean that every old binary has to
> > be recompiled anyway for the new release?
> > If so, the padding is not needed.
> Agreed, basically. Waiting to hear from tools maintainers about best
> approach to libxc.
> 
> It seems that there aren't that many users relying on a fixed ABI, so we
> can (still, until 4.2) change things. But obviously I want to be careful.

Ping?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 12:58:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 12:58:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOtn-0003ER-Gg; Thu, 26 Jan 2012 12:57: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 1RqOtm-0003Dx-Dn
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 12:57:54 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327582668!12684029!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21491 invoked from network); 26 Jan 2012 12:57:48 -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; 26 Jan 2012 12:57:48 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqOte-000KOJ-A9; Thu, 26 Jan 2012 12:57:46 +0000
Date: Thu, 26 Jan 2012 12:57:46 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126125746.GC74165@ocelot.phlegethon.org>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
	<20120112144325.GE8324@aepfle.de>
	<e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
User-Agent: Mutt/1.4.2.1i
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, andres@gridcentric.ca,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
	and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 08:04 -0800 on 12 Jan (1326355474), Andres Lagar-Cavilla wrote:
> > On Wed, Jan 11, Andres Lagar-Cavilla wrote:
> >
> >> +++ b/xen/include/public/domctl.h
> >
> >> +/* Use for teardown/setup of helper<->hypervisor interface for paging,
> >> + * access and sharing.*/
> >>  struct xen_domctl_mem_event_op {
> >>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
> >>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
> >>
> >> -    union {
> >> -        /* OP_ENABLE IN:  Virtual address of shared page */
> >> -        uint64_aligned_t shared_addr;
> >> -        /* PAGING_PREP IN: buffer to immediately fill page in */
> >> -        uint64_aligned_t buffer;
> >> -    } u;
> >> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
> >> page */
> >>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page
> >> */
> >>
> >> -    /* Other OPs */
> >> -    uint64_aligned_t gfn;          /* IN:  gfn of page being operated
> >> on */
> >> +    /* For binary backwards compatibility */
> >> +    uint64_aligned_t pad;
> >>  };
> >
> > Assuming this struct is routed through libxc, and libxc gets a new
> > SONAME for every release, doesnt this mean that every old binary has to
> > be recompiled anyway for the new release?
> > If so, the padding is not needed.
> Agreed, basically. Waiting to hear from tools maintainers about best
> approach to libxc.
> 
> It seems that there aren't that many users relying on a fixed ABI, so we
> can (still, until 4.2) change things. But obviously I want to be careful.

Ping?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:00:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:00:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOwM-0003Tf-3e; Thu, 26 Jan 2012 13:00: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 1RqOwK-0003TP-4q
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:00:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327582824!3183048!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTg0ODA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24975 invoked from network); 26 Jan 2012 13:00:25 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 13:00:25 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 43BAE604061;
	Thu, 26 Jan 2012 05:00: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=ZjNE4y4QuikfN8W7IpJ6EZZvhnbYeThilLn/PioZsRfX
	HUsMDMOX8n2PHgBzgh6SACHGAIcnVBc/dBEbOekpWCnAwZtWHiMx8E2mnXiOCoxw
	bOMjcJxO+NiePHnkbv6hiFY0VPXUd/6z8WCWnZA+d93SsguVwHL2NXk9MvqYd+s=
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=76uj2xteDC062vyllCU65ZM+fVM=; b=GJPRGagM
	d549AQZY1tTZdgbLET7ZG2MXgXS8fitpkbPkk2Q8+kP0Mr9mGOKAMICeuVx5ytLA
	R93VlPbn+tpEcdAw2JhBIKKJ3pj5q9Wwsks51xqew7zx8tExOK6Seb2W4Pr5swFr
	RyiAh3f+xQmnYOExs1Ma0XVeJm+eGdlGlP0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id EBDA5604084; 
	Thu, 26 Jan 2012 05:00:23 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 05:00:24 -0800
Message-ID: <f5022e2232ca5ccaa9552f9333dff0e6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126125746.GC74165@ocelot.phlegethon.org>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
	<20120112144325.GE8324@aepfle.de>
	<e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
	<20120126125746.GC74165@ocelot.phlegethon.org>
Date: Thu, 26 Jan 2012 05:00:24 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, andres@gridcentric.ca,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 08:04 -0800 on 12 Jan (1326355474), Andres Lagar-Cavilla wrote:
>> > On Wed, Jan 11, Andres Lagar-Cavilla wrote:
>> >
>> >> +++ b/xen/include/public/domctl.h
>> >
>> >> +/* Use for teardown/setup of helper<->hypervisor interface for
>> paging,
>> >> + * access and sharing.*/
>> >>  struct xen_domctl_mem_event_op {
>> >>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
>> >>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
>> >>
>> >> -    union {
>> >> -        /* OP_ENABLE IN:  Virtual address of shared page */
>> >> -        uint64_aligned_t shared_addr;
>> >> -        /* PAGING_PREP IN: buffer to immediately fill page in */
>> >> -        uint64_aligned_t buffer;
>> >> -    } u;
>> >> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
>> >> page */
>> >>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring
>> page
>> >> */
>> >>
>> >> -    /* Other OPs */
>> >> -    uint64_aligned_t gfn;          /* IN:  gfn of page being
>> operated
>> >> on */
>> >> +    /* For binary backwards compatibility */
>> >> +    uint64_aligned_t pad;
>> >>  };
>> >
>> > Assuming this struct is routed through libxc, and libxc gets a new
>> > SONAME for every release, doesnt this mean that every old binary has
>> to
>> > be recompiled anyway for the new release?
>> > If so, the padding is not needed.
>> Agreed, basically. Waiting to hear from tools maintainers about best
>> approach to libxc.
>>
>> It seems that there aren't that many users relying on a fixed ABI, so we
>> can (still, until 4.2) change things. But obviously I want to be
>> careful.
>
> Ping?

I have working code. Except that it blue-screened W7 once, so it's been
put in the back-burner for next week.

I can repost for review. Ok, I will.

I have not heard any objections thus far to the ABI change.

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 Jan 26 13:00:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:00:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqOwM-0003Tf-3e; Thu, 26 Jan 2012 13:00: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 1RqOwK-0003TP-4q
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:00:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327582824!3183048!1
X-Originating-IP: [208.97.132.119]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xMTkgPT4gMTg0ODA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24975 invoked from network); 26 Jan 2012 13:00:25 -0000
Received: from caiajhbdcbbj.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.119) by server-4.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 13:00:25 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 43BAE604061;
	Thu, 26 Jan 2012 05:00: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=ZjNE4y4QuikfN8W7IpJ6EZZvhnbYeThilLn/PioZsRfX
	HUsMDMOX8n2PHgBzgh6SACHGAIcnVBc/dBEbOekpWCnAwZtWHiMx8E2mnXiOCoxw
	bOMjcJxO+NiePHnkbv6hiFY0VPXUd/6z8WCWnZA+d93SsguVwHL2NXk9MvqYd+s=
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=76uj2xteDC062vyllCU65ZM+fVM=; b=GJPRGagM
	d549AQZY1tTZdgbLET7ZG2MXgXS8fitpkbPkk2Q8+kP0Mr9mGOKAMICeuVx5ytLA
	R93VlPbn+tpEcdAw2JhBIKKJ3pj5q9Wwsks51xqew7zx8tExOK6Seb2W4Pr5swFr
	RyiAh3f+xQmnYOExs1Ma0XVeJm+eGdlGlP0=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id EBDA5604084; 
	Thu, 26 Jan 2012 05:00:23 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 05:00:24 -0800
Message-ID: <f5022e2232ca5ccaa9552f9333dff0e6.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126125746.GC74165@ocelot.phlegethon.org>
References: <ed4d429d7026a3cd2b33.1326307372@xdev.gridcentric.ca>
	<20120112144325.GE8324@aepfle.de>
	<e49cd516cd6a874de6cb624e15a95694.squirrel@webmail.lagarcavilla.org>
	<20120126125746.GC74165@ocelot.phlegethon.org>
Date: Thu, 26 Jan 2012 05:00:24 -0800
From: "Andres Lagar-Cavilla" <andres@lagarcavilla.org>
To: "Tim Deegan" <tim@xen.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Cc: Olaf Hering <olaf@aepfle.de>, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, andres@gridcentric.ca,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH] RFC: Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 08:04 -0800 on 12 Jan (1326355474), Andres Lagar-Cavilla wrote:
>> > On Wed, Jan 11, Andres Lagar-Cavilla wrote:
>> >
>> >> +++ b/xen/include/public/domctl.h
>> >
>> >> +/* Use for teardown/setup of helper<->hypervisor interface for
>> paging,
>> >> + * access and sharing.*/
>> >>  struct xen_domctl_mem_event_op {
>> >>      uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
>> >>      uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
>> >>
>> >> -    union {
>> >> -        /* OP_ENABLE IN:  Virtual address of shared page */
>> >> -        uint64_aligned_t shared_addr;
>> >> -        /* PAGING_PREP IN: buffer to immediately fill page in */
>> >> -        uint64_aligned_t buffer;
>> >> -    } u;
>> >> +    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared
>> >> page */
>> >>      uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring
>> page
>> >> */
>> >>
>> >> -    /* Other OPs */
>> >> -    uint64_aligned_t gfn;          /* IN:  gfn of page being
>> operated
>> >> on */
>> >> +    /* For binary backwards compatibility */
>> >> +    uint64_aligned_t pad;
>> >>  };
>> >
>> > Assuming this struct is routed through libxc, and libxc gets a new
>> > SONAME for every release, doesnt this mean that every old binary has
>> to
>> > be recompiled anyway for the new release?
>> > If so, the padding is not needed.
>> Agreed, basically. Waiting to hear from tools maintainers about best
>> approach to libxc.
>>
>> It seems that there aren't that many users relying on a fixed ABI, so we
>> can (still, until 4.2) change things. But obviously I want to be
>> careful.
>
> Ping?

I have working code. Except that it blue-screened W7 once, so it's been
put in the back-burner for next week.

I can repost for review. Ok, I will.

I have not heard any objections thus far to the ABI change.

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 Jan 26 13:05:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13: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 1RqP0t-0003ir-UQ; Thu, 26 Jan 2012 13:05:15 +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 1RqP0s-0003iZ-3K
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:05:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327583106!12685056!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzkzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12695 invoked from network); 26 Jan 2012 13:05:07 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-9.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 13:05:07 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 33E4E300064;
	Thu, 26 Jan 2012 05:05:06 -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=W0rHX0J1oOnxTVE0sK+QXT
	hscqk319e9Q6ZtTfUivQSBPB2uKYqPRlftQGliWr1EjdbdC0UtyoMSvUkpndq0wo
	sp78JTlURFZ8KCNFKN0LeNsfa2tJQMLNgfc9jrMW/tt3JQNYKkyB9IJmPAXs4WzY
	/M6uT8OYWiqdYgMWFy4sk=
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=CVR3f+8Jmt+S
	ENO3sX4Vty0EcQ8=; b=nT9k2InWr19HbTILmTN5amQwTNKM8CyDAeI8x/jEfRla
	H/Z/+CBcGvaKN3EEhx+46QD5NyQSey9lab0Mhi05JqtUdw+Es8JX+u7/kX6nNsGE
	aP5skndhS47FSwCF9NnAKFvibdG4ewh+RJyDWYSLX5xb3EZdpg3bgxLykeGDLWM=
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 C9349300059; 
	Thu, 26 Jan 2012 05:05:04 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1327583323@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 26 Jan 2012 08:08:43 -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, olaf@apefle.de,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] RFC Switch mem event ABI from domctl to
	memops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Swith mem event per page operations from domctl to XENMEM_* interface. Improve
scalabilty.

Looking for further feedback on the proposed ABI change.

This code has been tested to work generally well, save for a few blue screens.
It might be that removing the global domctl lock uncovers hidden races.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |  101 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 tools/libxc/xc_memshr.c              |   11 ++
 tools/libxc/xenctrl.h                |    1 +
 tools/tests/mem-sharing/memshrtool.c |   11 ++
 xen/arch/x86/mm/mem_sharing.c        |   13 +-
 xen/arch/x86/x86_64/compat/mm.c      |    3 +
 xen/arch/x86/x86_64/mm.c             |    2 +
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 xen/include/public/memory.h          |    1 +
 28 files changed, 460 insertions(+), 284 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:05:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13: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 1RqP0t-0003ir-UQ; Thu, 26 Jan 2012 13:05:15 +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 1RqP0s-0003iZ-3K
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:05:14 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327583106!12685056!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzkzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12695 invoked from network); 26 Jan 2012 13:05:07 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-9.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 13:05:07 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 33E4E300064;
	Thu, 26 Jan 2012 05:05:06 -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=W0rHX0J1oOnxTVE0sK+QXT
	hscqk319e9Q6ZtTfUivQSBPB2uKYqPRlftQGliWr1EjdbdC0UtyoMSvUkpndq0wo
	sp78JTlURFZ8KCNFKN0LeNsfa2tJQMLNgfc9jrMW/tt3JQNYKkyB9IJmPAXs4WzY
	/M6uT8OYWiqdYgMWFy4sk=
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=CVR3f+8Jmt+S
	ENO3sX4Vty0EcQ8=; b=nT9k2InWr19HbTILmTN5amQwTNKM8CyDAeI8x/jEfRla
	H/Z/+CBcGvaKN3EEhx+46QD5NyQSey9lab0Mhi05JqtUdw+Es8JX+u7/kX6nNsGE
	aP5skndhS47FSwCF9NnAKFvibdG4ewh+RJyDWYSLX5xb3EZdpg3bgxLykeGDLWM=
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 C9349300059; 
	Thu, 26 Jan 2012 05:05:04 -0800 (PST)
MIME-Version: 1.0
Message-Id: <patchbomb.1327583323@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 26 Jan 2012 08:08:43 -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, olaf@apefle.de,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 0 of 2] RFC Switch mem event ABI from domctl to
	memops
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Swith mem event per page operations from domctl to XENMEM_* interface. Improve
scalabilty.

Looking for further feedback on the proposed ABI change.

This code has been tested to work generally well, save for a few blue screens.
It might be that removing the global domctl lock uncovers hidden races.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |  101 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 tools/libxc/xc_memshr.c              |   11 ++
 tools/libxc/xenctrl.h                |    1 +
 tools/tests/mem-sharing/memshrtool.c |   11 ++
 xen/arch/x86/mm/mem_sharing.c        |   13 +-
 xen/arch/x86/x86_64/compat/mm.c      |    3 +
 xen/arch/x86/x86_64/mm.c             |    2 +
 xen/include/asm-x86/mem_sharing.h    |    3 +-
 xen/include/public/memory.h          |    1 +
 28 files changed, 460 insertions(+), 284 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:05:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:05:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqP0v-0003j7-AN; Thu, 26 Jan 2012 13:05:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqP0u-0003ie-8L
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:05:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327583108!12686970!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzA4NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13712 invoked from network); 26 Jan 2012 13:05:09 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 13:05:09 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id ABD9A300059;
	Thu, 26 Jan 2012 05:05:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=IBvdWyPel5J40QaakfHNJOswFzfKUoHSBJwO2J9u8NqX
	j9yU+ie7pN2TJlirHFLjk5mj75ADUXFHTXmUqQmC0uSGMaxm9/yuakBkEtzOD2EV
	V91W45LjKh7gYNXlYQ4qWsNWfK2EnDUOcniT/wN8jUxyI0mqD3tHKKbKWMstIYE=
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=TFyn0Ly+QdAn816bVjiMxMcrLA0=; b=fXwKy+U5UmP
	H/WFfcgSO+VlzWKksuTp66jAqq8gff4o35kHz6W1sUnyZBE49FBnFi2J1ylV/yL+
	NWPNZrepJ/2xdbM03hmM+uTDbICYJduc5jlzz8/Gy9ZfOs04yUbPb6DWLmEb0JyC
	zsGaSvznQXpLfVF5DthSPRN6oFNKO0zY=
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 5FC9E30006C; 
	Thu, 26 Jan 2012 05:05:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 94e407f39c38c2fd8ea1a43d7d6ce28d7e139a4f
Message-Id: <94e407f39c38c2fd8ea1.1327583324@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327583323@xdev.gridcentric.ca>
References: <patchbomb.1327583323@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 26 Jan 2012 08:08:44 -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, olaf@apefle.de,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |  101 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 20 files changed, 423 insertions(+), 276 deletions(-)


Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 196824008493 -r 94e407f39c38 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -30,7 +30,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -38,15 +38,15 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_access_op_resume,
+                                XENMEM_access_op,
+                                gfn, NULL);
 }
 
 /*
diff -r 196824008493 -r 94e407f39c38 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,8 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page,
-                         void *ring_page, unsigned long gfn)
+                         unsigned int mode, void *page, void *ring_page)
 {
     DECLARE_DOMCTL;
 
@@ -34,11 +33,25 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
+    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
-
-    domctl.u.mem_event_op.gfn = gfn;
     
     return do_domctl(xch, &domctl);
 }
 
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer)
+{
+    xen_mem_event_op_t meo;
+
+    memset(&meo, 0, sizeof(meo));
+
+    meo.op      = op;
+    meo.domain  = domain_id;
+    meo.gfn     = gfn;
+    meo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, mode, &meo, sizeof(meo));
+}
+
diff -r 196824008493 -r 94e407f39c38 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -30,7 +30,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -38,31 +38,31 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_nominate,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_evict,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
@@ -79,10 +79,10 @@ int xc_mem_paging_load(xc_interface *xch
     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);
+    rc = xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, buffer);
 
     (void)munlock(buffer, XC_PAGE_SIZE);
     return rc;
@@ -90,10 +90,10 @@ int xc_mem_paging_load(xc_interface *xch
 
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_resume,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 
diff -r 196824008493 -r 94e407f39c38 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -36,32 +36,38 @@ int xc_memshr_control(xc_interface *xch,
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
     domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
+    op->op = XEN_DOMCTL_MEM_SHARING_CONTROL;
     op->u.enable = enable;
 
     return do_domctl(xch, &domctl);
 }
 
+static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
+                            xen_mem_sharing_op_t *mso)
+{
+    mso->domain = domid;
+
+    return do_memory_op(xch, XENMEM_sharing_op, mso, sizeof(*mso));
+}
+
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
-    op->u.nominate.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gfn;
+    mso.u.nominate.u.gfn = gfn; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
@@ -69,21 +75,19 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
-    op->u.nominate.u.grant_ref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gref;
+    mso.u.nominate.u.grant_ref = gref; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_share_gfns(xc_interface *xch,
@@ -94,21 +98,19 @@ int xc_memshr_share_gfns(xc_interface *x
                          unsigned long client_gfn,
                          uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    op->u.share.source_gfn    = source_gfn;
-    op->u.share.client_domain = client_domain;
-    op->u.share.client_gfn    = client_gfn;
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_share_grefs(xc_interface *xch,
@@ -119,21 +121,19 @@ int xc_memshr_share_grefs(xc_interface *
                           grant_ref_t client_gref,
                           uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
-    op->u.share.client_domain = client_domain;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.source_gfn, source_gref);
+    mso.u.share.client_domain = client_domain;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.client_gfn, client_gref);
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_add_to_physmap(xc_interface *xch,
@@ -143,86 +143,72 @@ int xc_memshr_add_to_physmap(xc_interfac
                     domid_t client_domain,
                     unsigned long client_gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain               = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
-    op->u.share.source_gfn      = source_gfn;
-    op->u.share.source_handle   = source_handle;
-    op->u.share.client_gfn      = client_gfn;
-    op->u.share.client_domain   = client_domain;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_add_physmap;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_resume;
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
-    op->u.debug.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gfn;
+    mso.u.debug.u.gfn = gfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long mfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
-    op->u.debug.u.mfn = mfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_mfn;
+    mso.u.debug.u.mfn = mfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
-    op->u.debug.u.gref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gref;
+    mso.u.debug.u.gref = gref; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 long xc_sharing_freed_pages(xc_interface *xch)
diff -r 196824008493 -r 94e407f39c38 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1879,8 +1879,10 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
-                          void *ring_page, unsigned long gfn);
+                         unsigned int mode, void *shared_page, void *ring_page);
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 196824008493 -r 94e407f39c38 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -186,12 +186,12 @@ int memshr_vbd_issue_ro_request(char *bu
            remove the relevant ones from the map */
         switch(ret)
         {
-            case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_S_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
                 if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
                                     source_st.domain, source_st.frame, source_st.handle);
                 break;
-            case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_C_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
                 if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
                                     client_st.domain, client_st.frame, client_st.handle);
diff -r 196824008493 -r 94e407f39c38 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -34,9 +34,9 @@ static int usage(const char* prog)
     int rc = f; \
     if ( rc < 0 ) { \
         printf("error executing %s: %s\n", #f, \
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_S_HANDLE_INVALID) ? \
                 "problem with client handle" :\
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_C_HANDLE_INVALID) ? \
                 "problem with source handle" : strerror(errno)); \
         return rc; \
     } \
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1463,7 +1463,6 @@ long arch_do_domctl(
             if ( !ret )
                 ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
         } 
     }
     break;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -25,14 +25,13 @@
 #include <asm/mem_event.h>
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
 {
     int rc;
 
-    switch( mec->op )
+    switch( meo->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
+    case XENMEM_access_op_resume:
     {
         p2m_mem_access_resume(d);
         rc = 0;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -28,6 +28,7 @@
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
+#include <asm/mem_sharing.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -49,7 +50,7 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->u.shared_addr;
+    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
@@ -455,6 +456,54 @@ static void mem_access_notification(stru
     p2m_mem_access_resume(v->domain);
 }
 
+struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
+{
+    struct domain *d;
+
+    /* Get the target domain */
+    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
+    if ( *rc != 0 )
+        return NULL;
+
+    /* Not dying? */
+    if ( d->is_dying )
+    {
+        rcu_unlock_domain(d);
+        *rc = -EINVAL;
+        return NULL;
+    }
+    
+    return d;
+}
+
+int do_mem_event_op(int op, uint32_t domain, void *arg)
+{
+    int ret;
+    struct domain *d;
+
+    d = get_mem_event_op_target(domain, &ret);
+    if ( !d )
+        return ret;
+
+    switch (op)
+    {
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_access_op:
+            ret = mem_access_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+        default:
+            ret = -ENOSYS;
+    }
+
+    rcu_unlock_domain(d);
+    return ret;
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -528,11 +577,8 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_paging_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
@@ -567,14 +613,14 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_access_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
+
+    default:
+        rc = -ENOSYS;
     }
 
     return rc;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,33 +25,32 @@
 #include <asm/mem_event.h>
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
     switch( mec->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE:
+    case XENMEM_paging_op_nominate:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT:
+    case XENMEM_paging_op_evict:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
+    case XENMEM_paging_op_prep:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
+        return p2m_mem_paging_prep(d, gfn, mec->buffer);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME:
+    case XENMEM_paging_op_resume:
     {
         p2m_mem_paging_resume(d);
         return 0;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -738,12 +738,12 @@ int mem_sharing_share_pages(struct domai
     }
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = firstpg = __grab_shared_page(smfn);
         if ( spage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = secondpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
         {
@@ -751,12 +751,12 @@ int mem_sharing_share_pages(struct domai
             goto err_out;
         }
     } else {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = firstpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = secondpg = __grab_shared_page(smfn);
         if ( spage == NULL )
         {
@@ -771,14 +771,14 @@ int mem_sharing_share_pages(struct domai
     /* Check that the handles match */
     if ( spage->sharing->handle != sh )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
     if ( cpage->sharing->handle != ch )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
@@ -841,7 +841,7 @@ int mem_sharing_add_to_physmap(struct do
     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;
+    ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
     spage = __grab_shared_page(smfn);
     if ( spage == NULL )
         goto err_out;
@@ -855,7 +855,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( mfn_valid(cmfn) ||
          (!(p2m_is_ram(cmfn_type))) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
     }
 
@@ -1005,9 +1005,9 @@ private_page_found:
     return 0;
 }
 
-int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
-    int rc;
+    int rc = 0;
 
     /* Only HAP is supported */
     if ( !hap_enabled(d) )
@@ -1015,14 +1015,7 @@ int mem_sharing_domctl(struct domain *d,
 
     switch(mec->op)
     {
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL:
-        {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
-            rc = 0;
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN:
+        case XENMEM_sharing_op_nominate_gfn:
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
@@ -1033,7 +1026,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF:
+        case XENMEM_sharing_op_nominate_gref:
         {
             grant_ref_t gref = mec->u.nominate.u.grant_ref;
             unsigned long gfn;
@@ -1048,47 +1041,48 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
+        case XENMEM_sharing_op_share:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
             shr_handle_t sh, ch;
+            int rc;
 
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.source_gfn));
                 if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
                 sgfn  = mec->u.share.source_gfn;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.client_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.client_gfn));
                 if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
@@ -1100,33 +1094,34 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        case XENMEM_sharing_op_add_physmap:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
             shr_handle_t sh;
+            int rc;
 
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 /* Cannot add a gref to the physmap */
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
@@ -1136,11 +1131,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
+        case XENMEM_sharing_op_resume:
         {
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
@@ -1148,21 +1143,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN:
+        case XENMEM_sharing_op_debug_gfn:
         {
             unsigned long gfn = mec->u.debug.u.gfn;
             rc = mem_sharing_debug_gfn(d, gfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
+        case XENMEM_sharing_op_debug_mfn:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
             rc = mem_sharing_debug_mfn(mfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF:
+        case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;
             rc = mem_sharing_debug_gref(d, gref);
@@ -1179,6 +1174,30 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+{
+    int rc;
+
+    /* Only HAP is supported */
+    if ( !hap_enabled(d) )
+         return -ENODEV;
+
+    switch(mec->op)
+    {
+        case XEN_DOMCTL_MEM_SHARING_CONTROL:
+        {
+            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
+            rc = 0;
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -2,6 +2,7 @@
 #include <xen/multicall.h>
 #include <compat/memory.h>
 #include <compat/xen.h>
+#include <asm/mem_event.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -211,6 +212,28 @@ int compat_arch_memory_op(int op, XEN_GU
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_event.h>
 #include <asm/mem_sharing.h>
 #include <public/memory.h>
 
@@ -1100,6 +1101,28 @@ long subarch_memory_op(int op, XEN_GUEST
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 196824008493 -r 94e407f39c38 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 196824008493 -r 94e407f39c38 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -39,6 +39,8 @@ void mem_event_put_request(struct domain
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
+struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
+int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
 
diff -r 196824008493 -r 94e407f39c38 xen/include/asm-x86/mem_paging.h
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 196824008493 -r 94e407f39c38 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -23,6 +23,7 @@
 #define __MEM_SHARING_H__
 
 #include <public/domctl.h>
+#include <public/memory.h>
 
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 0
@@ -56,6 +57,8 @@ int mem_sharing_unshare_page(struct doma
                              unsigned long gfn, 
                              uint16_t flags);
 int mem_sharing_sharing_resume(struct domain *d);
+int mem_sharing_memop(struct domain *d, 
+                       xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
 void mem_sharing_init(void);
diff -r 196824008493 -r 94e407f39c38 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -711,47 +711,43 @@ struct xen_domctl_gdbsx_domstatus {
 
 /*
 * Domain memory paging
- * Page memory in and out. 
+ * Page memory in and out.
+ * Domctl interface to set up and tear down the 
+ * pager<->hypervisor interface. Use XENMEM_paging_op*
+ * to perform per-page operations.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE   2
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
 
 /*
  * Access permissions.
  *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
  * There are HVM hypercalls to set the per-page access permissions of every
  * page in a domain.  When one of these permissions--independent, read, 
  * write, and execute--is violated, the VCPU is paused and a memory event 
- * is sent with what happened.  (See public/mem_event.h)  The memory event 
- * handler can then resume the VCPU and redo the access with an 
- * ACCESS_RESUME mode for the following domctl.
+ * is sent with what happened.  (See public/mem_event.h) .
+ *
+ * The memory event handler can then resume the VCPU and redo the access 
+ * with a XENMEM_access_op_resume hypercall.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME     2
 
+/* Use for teardown/setup of helper<->hypervisor interface for paging, 
+ * access and sharing.*/
 struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    union {
-        /* OP_ENABLE IN:  Virtual address of shared page */
-        uint64_aligned_t shared_addr;  
-        /* PAGING_PREP IN: buffer to immediately fill page in */
-        uint64_aligned_t buffer;
-    } u;
+    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
-
-    /* Other OPs */
-    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
@@ -759,63 +755,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 /*
  * Memory sharing operations
  */
-/* XEN_DOMCTL_mem_sharing_op */
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING                3
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL        0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN   1
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF  2
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE          3
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME         4
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
-
-#define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
-#define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
-
-/* The following allows sharing of grant refs. This is useful
- * for sharing utilities sitting as "filters" in IO backends
- * (e.g. memshr + blktap(2)). The IO backend is only exposed 
- * to grant references, and this allows sharing of the grefs */
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
-
-#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
-    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
-    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
-    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+/* XEN_DOMCTL_mem_sharing_op.
+ * The CONTROL sub-domctl is used for bringup/teardown. */
+#define XEN_DOMCTL_MEM_SHARING_CONTROL          0
 
 struct xen_domctl_mem_sharing_op {
-    uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
+    uint8_t op; /* XEN_DOMCTL_MEM_SHARING_* */
 
     union {
-        uint8_t enable;                   /* OP_CONTROL                */
-
-        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
-            union {
-                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
-                uint32_t      grant_ref;  /* IN: grant ref to nominate */
-            } u;
-            uint64_aligned_t  handle;     /* OUT: the handle           */
-        } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
-            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
-            uint64_aligned_t source_handle; /* IN: handle to the source page */
-            domid_t          client_domain; /* IN: the client domain id */
-            uint64_aligned_t client_gfn;    /* IN: the client gfn */
-            uint64_aligned_t client_handle; /* IN: handle to the client page */
-        } share; 
-        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
-            union {
-                uint64_aligned_t gfn;      /* IN: gfn to debug          */
-                uint64_aligned_t mfn;      /* IN: mfn to debug          */
-                grant_ref_t    gref;       /* IN: gref to debug         */
-            } u;
-        } debug;
+        uint8_t enable;                   /* CONTROL */
     } u;
 };
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
diff -r 196824008493 -r 94e407f39c38 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -289,6 +289,12 @@ struct xen_pod_target {
 };
 typedef struct xen_pod_target xen_pod_target_t;
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
 /*
  * Get the number of MFNs saved through memory sharing.
  * The call never fails. 
@@ -296,6 +302,87 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_get_sharing_freed_pages    18
 #define XENMEM_get_sharing_shared_pages   19
 
+#define XENMEM_paging_op                    20
+#define XENMEM_paging_op_nominate           0
+#define XENMEM_paging_op_evict              1
+#define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_resume             3
+
+#define XENMEM_access_op                    21
+#define XENMEM_access_op_resume             0
+
+struct xen_mem_event_op {
+    uint8_t     op;         /* XENMEM_*_op_* */
+    domid_t     domain;
+    
+
+    /* PAGING_PREP IN: buffer to immediately fill page in */
+    uint64_aligned_t    buffer;
+    /* Other OPs */
+    uint64_aligned_t    gfn;           /* IN:  gfn of page being operated on */
+};
+typedef struct xen_mem_event_op xen_mem_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op_t);
+
+#define XENMEM_sharing_op                   22
+#define XENMEM_sharing_op_nominate_gfn      0
+#define XENMEM_sharing_op_nominate_gref     1
+#define XENMEM_sharing_op_share             2
+#define XENMEM_sharing_op_resume            3
+#define XENMEM_sharing_op_debug_gfn         4
+#define XENMEM_sharing_op_debug_mfn         5
+#define XENMEM_sharing_op_debug_gref        6
+#define XENMEM_sharing_op_add_physmap       7
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
+
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed 
+ * to grant references, and this allows sharing of the grefs */
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field)         \
+    ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field)        \
+    ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+    uint8_t     op;     /* XENMEM_sharing_op_* */
+    domid_t     domain;
+
+    union {
+        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
+            union {
+                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
+                uint32_t      grant_ref;  /* IN: grant ref to nominate */
+            } u;
+            uint64_aligned_t  handle;     /* OUT: the handle           */
+        } nominate;
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
+            uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
+            uint64_aligned_t client_handle; /* IN: handle to the client page */
+            domid_t  client_domain; /* IN: the client domain id */
+        } share; 
+        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
+            union {
+                uint64_aligned_t gfn;      /* IN: gfn to debug          */
+                uint64_aligned_t mfn;      /* IN: mfn to debug          */
+                uint32_t gref;     /* IN: gref to debug         */
+            } u;
+        } debug;
+    } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:05:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:05:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqP0v-0003j7-AN; Thu, 26 Jan 2012 13:05:17 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqP0u-0003ie-8L
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:05:16 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327583108!12686970!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzA4NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13712 invoked from network); 26 Jan 2012 13:05:09 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.66) by server-5.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 13:05:09 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id ABD9A300059;
	Thu, 26 Jan 2012 05:05:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=IBvdWyPel5J40QaakfHNJOswFzfKUoHSBJwO2J9u8NqX
	j9yU+ie7pN2TJlirHFLjk5mj75ADUXFHTXmUqQmC0uSGMaxm9/yuakBkEtzOD2EV
	V91W45LjKh7gYNXlYQ4qWsNWfK2EnDUOcniT/wN8jUxyI0mqD3tHKKbKWMstIYE=
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=TFyn0Ly+QdAn816bVjiMxMcrLA0=; b=fXwKy+U5UmP
	H/WFfcgSO+VlzWKksuTp66jAqq8gff4o35kHz6W1sUnyZBE49FBnFi2J1ylV/yL+
	NWPNZrepJ/2xdbM03hmM+uTDbICYJduc5jlzz8/Gy9ZfOs04yUbPb6DWLmEb0JyC
	zsGaSvznQXpLfVF5DthSPRN6oFNKO0zY=
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 5FC9E30006C; 
	Thu, 26 Jan 2012 05:05:06 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 94e407f39c38c2fd8ea1a43d7d6ce28d7e139a4f
Message-Id: <94e407f39c38c2fd8ea1.1327583324@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327583323@xdev.gridcentric.ca>
References: <patchbomb.1327583323@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 26 Jan 2012 08:08:44 -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, olaf@apefle.de,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 1 of 2] Use memops for mem paging, sharing,
 and access, instead of domctls
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_mem_access.c          |   12 +-
 tools/libxc/xc_mem_event.c           |   23 +++-
 tools/libxc/xc_mem_paging.c          |   44 ++++----
 tools/libxc/xc_memshr.c              |  182 ++++++++++++++++------------------
 tools/libxc/xenctrl.h                |    6 +-
 tools/memshr/interface.c             |    4 +-
 tools/tests/mem-sharing/memshrtool.c |    4 +-
 xen/arch/x86/domctl.c                |    1 -
 xen/arch/x86/mm/mem_access.c         |    7 +-
 xen/arch/x86/mm/mem_event.c          |   68 ++++++++++--
 xen/arch/x86/mm/mem_paging.c         |   13 +-
 xen/arch/x86/mm/mem_sharing.c        |  101 +++++++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   23 ++++
 xen/arch/x86/x86_64/mm.c             |   23 ++++
 xen/include/asm-x86/mem_access.h     |    3 +-
 xen/include/asm-x86/mem_event.h      |    2 +
 xen/include/asm-x86/mem_paging.h     |    3 +-
 xen/include/asm-x86/mem_sharing.h    |    3 +
 xen/include/public/domctl.h          |   90 +++-------------
 xen/include/public/memory.h          |   87 ++++++++++++++++
 20 files changed, 423 insertions(+), 276 deletions(-)


Per page operations in the paging, sharing, and access tracking subsystems are
all implemented with domctls (e.g. a domctl to evict one page, or to share one
page).

Under heavy load, the domctl path reveals a lack of scalability. The domctl
lock serializes dom0's vcpus in the hypervisor. When performing thousands of
per-page operations on dozens of domains, these vcpus will spin in the
hypervisor. Beyond the aggressive locking, an added inefficiency of blocking
vcpus in the domctl lock is that dom0 is prevented from re-scheduling any of
its other work-starved processes.

We retain the domctl interface for setting up and tearing down
paging/sharing/mem access for a domain. But we migrate all the per page
operations to use the memory_op hypercalls (e.g XENMEM_*).

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 196824008493 -r 94e407f39c38 tools/libxc/xc_mem_access.c
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -30,7 +30,7 @@ int xc_mem_access_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_access_disable(xc_interface *xch, domid_t domain_id)
@@ -38,15 +38,15 @@ int xc_mem_access_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_access_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_ACCESS,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_access_op_resume,
+                                XENMEM_access_op,
+                                gfn, NULL);
 }
 
 /*
diff -r 196824008493 -r 94e407f39c38 tools/libxc/xc_mem_event.c
--- a/tools/libxc/xc_mem_event.c
+++ b/tools/libxc/xc_mem_event.c
@@ -24,8 +24,7 @@
 #include "xc_private.h"
 
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *page,
-                         void *ring_page, unsigned long gfn)
+                         unsigned int mode, void *page, void *ring_page)
 {
     DECLARE_DOMCTL;
 
@@ -34,11 +33,25 @@ int xc_mem_event_control(xc_interface *x
     domctl.u.mem_event_op.op = op;
     domctl.u.mem_event_op.mode = mode;
 
-    domctl.u.mem_event_op.u.shared_addr = (unsigned long)page;
+    domctl.u.mem_event_op.shared_addr = (unsigned long)page;
     domctl.u.mem_event_op.ring_addr = (unsigned long)ring_page;
-
-    domctl.u.mem_event_op.gfn = gfn;
     
     return do_domctl(xch, &domctl);
 }
 
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer)
+{
+    xen_mem_event_op_t meo;
+
+    memset(&meo, 0, sizeof(meo));
+
+    meo.op      = op;
+    meo.domain  = domain_id;
+    meo.gfn     = gfn;
+    meo.buffer  = (unsigned long) buffer;
+
+    return do_memory_op(xch, mode, &meo, sizeof(meo));
+}
+
diff -r 196824008493 -r 94e407f39c38 tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -30,7 +30,7 @@ int xc_mem_paging_enable(xc_interface *x
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                shared_page, ring_page, INVALID_MFN);
+                                shared_page, ring_page);
 }
 
 int xc_mem_paging_disable(xc_interface *xch, domid_t domain_id)
@@ -38,31 +38,31 @@ int xc_mem_paging_disable(xc_interface *
     return xc_mem_event_control(xch, domain_id,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE,
                                 XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, INVALID_MFN);
+                                NULL, NULL);
 }
 
 int xc_mem_paging_nominate(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_nominate,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_evict(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_evict,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_prep(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 int xc_mem_paging_load(xc_interface *xch, domid_t domain_id, 
@@ -79,10 +79,10 @@ int xc_mem_paging_load(xc_interface *xch
     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);
+    rc = xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_prep,
+                                XENMEM_paging_op,
+                                gfn, buffer);
 
     (void)munlock(buffer, XC_PAGE_SIZE);
     return rc;
@@ -90,10 +90,10 @@ int xc_mem_paging_load(xc_interface *xch
 
 int xc_mem_paging_resume(xc_interface *xch, domid_t domain_id, unsigned long gfn)
 {
-    return xc_mem_event_control(xch, domain_id,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME,
-                                XEN_DOMCTL_MEM_EVENT_OP_PAGING,
-                                NULL, NULL, gfn);
+    return xc_mem_event_memop(xch, domain_id,
+                                XENMEM_paging_op_resume,
+                                XENMEM_paging_op,
+                                gfn, NULL);
 }
 
 
diff -r 196824008493 -r 94e407f39c38 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -36,32 +36,38 @@ int xc_memshr_control(xc_interface *xch,
     domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
     domctl.domain = domid;
     op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL;
+    op->op = XEN_DOMCTL_MEM_SHARING_CONTROL;
     op->u.enable = enable;
 
     return do_domctl(xch, &domctl);
 }
 
+static int xc_memshr_memop(xc_interface *xch, domid_t domid, 
+                            xen_mem_sharing_op_t *mso)
+{
+    mso->domain = domid;
+
+    return do_memory_op(xch, XENMEM_sharing_op, mso, sizeof(*mso));
+}
+
 int xc_memshr_nominate_gfn(xc_interface *xch,
                            domid_t domid,
                            unsigned long gfn,
                            uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN;
-    op->u.nominate.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gfn;
+    mso.u.nominate.u.gfn = gfn; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_nominate_gref(xc_interface *xch,
@@ -69,21 +75,19 @@ int xc_memshr_nominate_gref(xc_interface
                             grant_ref_t gref,
                             uint64_t *handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
-    int ret;
+    int rc;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF;
-    op->u.nominate.u.grant_ref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    ret = do_domctl(xch, &domctl);
-    if(!ret) *handle = op->u.nominate.handle; 
+    mso.op = XENMEM_sharing_op_nominate_gref;
+    mso.u.nominate.u.grant_ref = gref; 
 
-    return ret;
+    rc = xc_memshr_memop(xch, domid, &mso);
+
+    if (!rc) *handle = mso.u.nominate.handle; 
+
+    return rc;
 }
 
 int xc_memshr_share_gfns(xc_interface *xch,
@@ -94,21 +98,19 @@ int xc_memshr_share_gfns(xc_interface *x
                          unsigned long client_gfn,
                          uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    op->u.share.source_gfn    = source_gfn;
-    op->u.share.client_domain = client_domain;
-    op->u.share.client_gfn    = client_gfn;
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_share_grefs(xc_interface *xch,
@@ -119,21 +121,19 @@ int xc_memshr_share_grefs(xc_interface *
                           grant_ref_t client_gref,
                           uint64_t client_handle)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE;
-    op->u.share.source_handle = source_handle;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.source_gfn, source_gref);
-    op->u.share.client_domain = client_domain;
-    XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(op->u.share.client_gfn, client_gref);
-    op->u.share.client_handle = client_handle;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_share;
+
+    mso.u.share.source_handle = source_handle;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.source_gfn, source_gref);
+    mso.u.share.client_domain = client_domain;
+    XENMEM_SHARING_OP_FIELD_MAKE_GREF(mso.u.share.client_gfn, client_gref);
+    mso.u.share.client_handle = client_handle;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_add_to_physmap(xc_interface *xch,
@@ -143,86 +143,72 @@ int xc_memshr_add_to_physmap(xc_interfac
                     domid_t client_domain,
                     unsigned long client_gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd                  = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version    = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain               = source_domain;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP;
-    op->u.share.source_gfn      = source_gfn;
-    op->u.share.source_handle   = source_handle;
-    op->u.share.client_gfn      = client_gfn;
-    op->u.share.client_domain   = client_domain;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_add_physmap;
+
+    mso.u.share.source_handle = source_handle;
+    mso.u.share.source_gfn    = source_gfn;
+    mso.u.share.client_domain = client_domain;
+    mso.u.share.client_gfn    = client_gfn;
+
+    return xc_memshr_memop(xch, source_domain, &mso);
 }
 
 int xc_memshr_domain_resume(xc_interface *xch,
                             domid_t domid)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_resume;
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long gfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN;
-    op->u.debug.u.gfn = gfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gfn;
+    mso.u.debug.u.gfn = gfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_mfn(xc_interface *xch,
                         domid_t domid,
                         unsigned long mfn)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN;
-    op->u.debug.u.mfn = mfn;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_mfn;
+    mso.u.debug.u.mfn = mfn; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref)
 {
-    DECLARE_DOMCTL;
-    struct xen_domctl_mem_sharing_op *op;
+    xen_mem_sharing_op_t mso;
 
-    domctl.cmd = XEN_DOMCTL_mem_sharing_op;
-    domctl.interface_version = XEN_DOMCTL_INTERFACE_VERSION;
-    domctl.domain = domid;
-    op = &(domctl.u.mem_sharing_op);
-    op->op = XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF;
-    op->u.debug.u.gref = gref;
+    memset(&mso, 0, sizeof(mso));
 
-    return do_domctl(xch, &domctl);
+    mso.op = XENMEM_sharing_op_debug_gref;
+    mso.u.debug.u.gref = gref; 
+
+    return xc_memshr_memop(xch, domid, &mso);
 }
 
 long xc_sharing_freed_pages(xc_interface *xch)
diff -r 196824008493 -r 94e407f39c38 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1879,8 +1879,10 @@ int xc_tmem_restore_extra(xc_interface *
  * mem_event operations
  */
 int xc_mem_event_control(xc_interface *xch, domid_t domain_id, unsigned int op,
-                         unsigned int mode, void *shared_page,
-                          void *ring_page, unsigned long gfn);
+                         unsigned int mode, void *shared_page, void *ring_page);
+int xc_mem_event_memop(xc_interface *xch, domid_t domain_id, 
+                        unsigned int op, unsigned int mode,
+                        uint64_t gfn, void *buffer);
 
 int xc_mem_paging_enable(xc_interface *xch, domid_t domain_id,
                         void *shared_page, void *ring_page);
diff -r 196824008493 -r 94e407f39c38 tools/memshr/interface.c
--- a/tools/memshr/interface.c
+++ b/tools/memshr/interface.c
@@ -186,12 +186,12 @@ int memshr_vbd_issue_ro_request(char *bu
            remove the relevant ones from the map */
         switch(ret)
         {
-            case XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_S_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, source_st, NULL);
                 if(ret) DPRINTF("Could not rm invl s_hnd: %u %"PRId64" %"PRId64"\n", 
                                     source_st.domain, source_st.frame, source_st.handle);
                 break;
-            case XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID:
+            case XENMEM_SHARING_OP_C_HANDLE_INVALID:
                 ret = blockshr_shrhnd_remove(memshr.blks, client_st, NULL);
                 if(ret) DPRINTF("Could not rm invl c_hnd: %u %"PRId64" %"PRId64"\n", 
                                     client_st.domain, client_st.frame, client_st.handle);
diff -r 196824008493 -r 94e407f39c38 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -34,9 +34,9 @@ static int usage(const char* prog)
     int rc = f; \
     if ( rc < 0 ) { \
         printf("error executing %s: %s\n", #f, \
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_S_HANDLE_INVALID) ? \
                 "problem with client handle" :\
-                ((errno * -1) == XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID) ? \
+                ((errno * -1) == XENMEM_SHARING_OP_C_HANDLE_INVALID) ? \
                 "problem with source handle" : strerror(errno)); \
         return rc; \
     } \
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/domctl.c
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1463,7 +1463,6 @@ long arch_do_domctl(
             if ( !ret )
                 ret = mem_sharing_domctl(d, &domctl->u.mem_sharing_op);
             rcu_unlock_domain(d);
-            copy_to_guest(u_domctl, domctl, 1);
         } 
     }
     break;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/mm/mem_access.c
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -25,14 +25,13 @@
 #include <asm/mem_event.h>
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
 {
     int rc;
 
-    switch( mec->op )
+    switch( meo->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME:
+    case XENMEM_access_op_resume:
     {
         p2m_mem_access_resume(d);
         rc = 0;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/mm/mem_event.c
--- a/xen/arch/x86/mm/mem_event.c
+++ b/xen/arch/x86/mm/mem_event.c
@@ -28,6 +28,7 @@
 #include <asm/mem_event.h>
 #include <asm/mem_paging.h>
 #include <asm/mem_access.h>
+#include <asm/mem_sharing.h>
 
 /* for public/io/ring.h macros */
 #define xen_mb()   mb()
@@ -49,7 +50,7 @@ static int mem_event_enable(
     struct domain *dom_mem_event = current->domain;
     struct vcpu *v = current;
     unsigned long ring_addr = mec->ring_addr;
-    unsigned long shared_addr = mec->u.shared_addr;
+    unsigned long shared_addr = mec->shared_addr;
     l1_pgentry_t l1e;
     unsigned long shared_gfn = 0, ring_gfn = 0; /* gcc ... */
     p2m_type_t p2mt;
@@ -455,6 +456,54 @@ static void mem_access_notification(stru
     p2m_mem_access_resume(v->domain);
 }
 
+struct domain *get_mem_event_op_target(uint32_t domain, int *rc)
+{
+    struct domain *d;
+
+    /* Get the target domain */
+    *rc = rcu_lock_remote_target_domain_by_id(domain, &d);
+    if ( *rc != 0 )
+        return NULL;
+
+    /* Not dying? */
+    if ( d->is_dying )
+    {
+        rcu_unlock_domain(d);
+        *rc = -EINVAL;
+        return NULL;
+    }
+    
+    return d;
+}
+
+int do_mem_event_op(int op, uint32_t domain, void *arg)
+{
+    int ret;
+    struct domain *d;
+
+    d = get_mem_event_op_target(domain, &ret);
+    if ( !d )
+        return ret;
+
+    switch (op)
+    {
+        case XENMEM_paging_op:
+            ret = mem_paging_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_access_op:
+            ret = mem_access_memop(d, (xen_mem_event_op_t *) arg);
+            break;
+        case XENMEM_sharing_op:
+            ret = mem_sharing_memop(d, (xen_mem_sharing_op_t *) arg);
+            break;
+        default:
+            ret = -ENOSYS;
+    }
+
+    rcu_unlock_domain(d);
+    return ret;
+}
+
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl)
 {
@@ -528,11 +577,8 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_paging_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
@@ -567,14 +613,14 @@ int mem_event_domctl(struct domain *d, x
         break;
 
         default:
-        {
-            if ( med->ring_page )
-                rc = mem_access_domctl(d, mec, u_domctl);
-        }
-        break;
+            rc = -ENOSYS;
+            break;
         }
     }
     break;
+
+    default:
+        rc = -ENOSYS;
     }
 
     return rc;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/mm/mem_paging.c
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -25,33 +25,32 @@
 #include <asm/mem_event.h>
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl)
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *mec)
 {
     switch( mec->op )
     {
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE:
+    case XENMEM_paging_op_nominate:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_nominate(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT:
+    case XENMEM_paging_op_evict:
     {
         unsigned long gfn = mec->gfn;
         return p2m_mem_paging_evict(d, gfn);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP:
+    case XENMEM_paging_op_prep:
     {
         unsigned long gfn = mec->gfn;
-        return p2m_mem_paging_prep(d, gfn, mec->u.buffer);
+        return p2m_mem_paging_prep(d, gfn, mec->buffer);
     }
     break;
 
-    case XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME:
+    case XENMEM_paging_op_resume:
     {
         p2m_mem_paging_resume(d);
         return 0;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -738,12 +738,12 @@ int mem_sharing_share_pages(struct domai
     }
     else if ( mfn_x(smfn) < mfn_x(cmfn) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = firstpg = __grab_shared_page(smfn);
         if ( spage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = secondpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
         {
@@ -751,12 +751,12 @@ int mem_sharing_share_pages(struct domai
             goto err_out;
         }
     } else {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         cpage = firstpg = __grab_shared_page(cmfn);
         if ( cpage == NULL )
             goto err_out;
 
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         spage = secondpg = __grab_shared_page(smfn);
         if ( spage == NULL )
         {
@@ -771,14 +771,14 @@ int mem_sharing_share_pages(struct domai
     /* Check that the handles match */
     if ( spage->sharing->handle != sh )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
     }
     if ( cpage->sharing->handle != ch )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         mem_sharing_page_unlock(secondpg);
         mem_sharing_page_unlock(firstpg);
         goto err_out;
@@ -841,7 +841,7 @@ int mem_sharing_add_to_physmap(struct do
     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;
+    ret = XENMEM_SHARING_OP_S_HANDLE_INVALID;
     spage = __grab_shared_page(smfn);
     if ( spage == NULL )
         goto err_out;
@@ -855,7 +855,7 @@ int mem_sharing_add_to_physmap(struct do
     if ( mfn_valid(cmfn) ||
          (!(p2m_is_ram(cmfn_type))) )
     {
-        ret = XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID;
+        ret = XENMEM_SHARING_OP_C_HANDLE_INVALID;
         goto err_unlock;
     }
 
@@ -1005,9 +1005,9 @@ private_page_found:
     return 0;
 }
 
-int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+int mem_sharing_memop(struct domain *d, xen_mem_sharing_op_t *mec)
 {
-    int rc;
+    int rc = 0;
 
     /* Only HAP is supported */
     if ( !hap_enabled(d) )
@@ -1015,14 +1015,7 @@ int mem_sharing_domctl(struct domain *d,
 
     switch(mec->op)
     {
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL:
-        {
-            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
-            rc = 0;
-        }
-        break;
-
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN:
+        case XENMEM_sharing_op_nominate_gfn:
         {
             unsigned long gfn = mec->u.nominate.u.gfn;
             shr_handle_t handle;
@@ -1033,7 +1026,7 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF:
+        case XENMEM_sharing_op_nominate_gref:
         {
             grant_ref_t gref = mec->u.nominate.u.grant_ref;
             unsigned long gfn;
@@ -1048,47 +1041,48 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE:
+        case XENMEM_sharing_op_share:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
             shr_handle_t sh, ch;
+            int rc;
 
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.source_gfn));
                 if ( mem_sharing_gref_to_gfn(d, gref, &sgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
                 sgfn  = mec->u.share.source_gfn;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.client_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.client_gfn) )
             {
                 grant_ref_t gref = (grant_ref_t) 
-                                    (XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(
+                                    (XENMEM_SHARING_OP_FIELD_GET_GREF(
                                         mec->u.share.client_gfn));
                 if ( mem_sharing_gref_to_gfn(cd, gref, &cgfn) < 0 )
                 {
-                    put_domain(cd);
+                    rcu_unlock_domain(cd);
                     return -EINVAL;
                 }
             } else {
@@ -1100,33 +1094,34 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_share_pages(d, sgfn, sh, cd, cgfn, ch); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP:
+        case XENMEM_sharing_op_add_physmap:
         {
             unsigned long sgfn, cgfn;
             struct domain *cd;
             shr_handle_t sh;
+            int rc;
 
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
 
-            cd = get_domain_by_id(mec->u.share.client_domain);
+            cd = get_mem_event_op_target(mec->u.share.client_domain, &rc);
             if ( !cd )
-                return -ESRCH;
+                return rc;
 
             if ( !mem_sharing_enabled(cd) )
             {
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
-            if ( XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(mec->u.share.source_gfn) )
+            if ( XENMEM_SHARING_OP_FIELD_IS_GREF(mec->u.share.source_gfn) )
             {
                 /* Cannot add a gref to the physmap */
-                put_domain(cd);
+                rcu_unlock_domain(cd);
                 return -EINVAL;
             }
 
@@ -1136,11 +1131,11 @@ int mem_sharing_domctl(struct domain *d,
 
             rc = mem_sharing_add_to_physmap(d, sgfn, sh, cd, cgfn); 
 
-            put_domain(cd);
+            rcu_unlock_domain(cd);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME:
+        case XENMEM_sharing_op_resume:
         {
             if ( !mem_sharing_enabled(d) )
                 return -EINVAL;
@@ -1148,21 +1143,21 @@ int mem_sharing_domctl(struct domain *d,
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN:
+        case XENMEM_sharing_op_debug_gfn:
         {
             unsigned long gfn = mec->u.debug.u.gfn;
             rc = mem_sharing_debug_gfn(d, gfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN:
+        case XENMEM_sharing_op_debug_mfn:
         {
             unsigned long mfn = mec->u.debug.u.mfn;
             rc = mem_sharing_debug_mfn(mfn);
         }
         break;
 
-        case XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF:
+        case XENMEM_sharing_op_debug_gref:
         {
             grant_ref_t gref = mec->u.debug.u.gref;
             rc = mem_sharing_debug_gref(d, gref);
@@ -1179,6 +1174,30 @@ int mem_sharing_domctl(struct domain *d,
     return rc;
 }
 
+int mem_sharing_domctl(struct domain *d, xen_domctl_mem_sharing_op_t *mec)
+{
+    int rc;
+
+    /* Only HAP is supported */
+    if ( !hap_enabled(d) )
+         return -ENODEV;
+
+    switch(mec->op)
+    {
+        case XEN_DOMCTL_MEM_SHARING_CONTROL:
+        {
+            d->arch.hvm_domain.mem_sharing_enabled = mec->u.enable;
+            rc = 0;
+        }
+        break;
+
+        default:
+            rc = -ENOSYS;
+    }
+
+    return rc;
+}
+
 void __init mem_sharing_init(void)
 {
     printk("Initing memory sharing.\n");
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -2,6 +2,7 @@
 #include <xen/multicall.h>
 #include <compat/memory.h>
 #include <compat/xen.h>
+#include <asm/mem_event.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -211,6 +212,28 @@ int compat_arch_memory_op(int op, XEN_GU
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 196824008493 -r 94e407f39c38 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -34,6 +34,7 @@
 #include <asm/msr.h>
 #include <asm/setup.h>
 #include <asm/numa.h>
+#include <asm/mem_event.h>
 #include <asm/mem_sharing.h>
 #include <public/memory.h>
 
@@ -1100,6 +1101,28 @@ long subarch_memory_op(int op, XEN_GUEST
     case XENMEM_get_sharing_shared_pages:
         return mem_sharing_get_nr_shared_mfns();
 
+    case XENMEM_paging_op:
+    case XENMEM_access_op:
+    {
+        xen_mem_event_op_t meo;
+        if ( copy_from_guest(&meo, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, meo.domain, (void *) &meo);
+        if ( !rc && copy_to_guest(arg, &meo, 1) )
+            return -EFAULT;
+        break;
+    }
+    case XENMEM_sharing_op:
+    {
+        xen_mem_sharing_op_t mso;
+        if ( copy_from_guest(&mso, arg, 1) )
+            return -EFAULT;
+        rc = do_mem_event_op(op, mso.domain, (void *) &mso);
+        if ( !rc && copy_to_guest(arg, &mso, 1) )
+            return -EFAULT;
+        break;
+    }
+
     default:
         rc = -ENOSYS;
         break;
diff -r 196824008493 -r 94e407f39c38 xen/include/asm-x86/mem_access.h
--- a/xen/include/asm-x86/mem_access.h
+++ b/xen/include/asm-x86/mem_access.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_access_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 196824008493 -r 94e407f39c38 xen/include/asm-x86/mem_event.h
--- a/xen/include/asm-x86/mem_event.h
+++ b/xen/include/asm-x86/mem_event.h
@@ -39,6 +39,8 @@ void mem_event_put_request(struct domain
 int mem_event_get_response(struct domain *d, struct mem_event_domain *med,
                            mem_event_response_t *rsp);
 
+struct domain *get_mem_event_op_target(uint32_t domain, int *rc);
+int do_mem_event_op(int op, uint32_t domain, void *arg);
 int mem_event_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
                      XEN_GUEST_HANDLE(void) u_domctl);
 
diff -r 196824008493 -r 94e407f39c38 xen/include/asm-x86/mem_paging.h
--- a/xen/include/asm-x86/mem_paging.h
+++ b/xen/include/asm-x86/mem_paging.h
@@ -21,8 +21,7 @@
  */
 
 
-int mem_paging_domctl(struct domain *d, xen_domctl_mem_event_op_t *mec,
-                      XEN_GUEST_HANDLE(void) u_domctl);
+int mem_paging_memop(struct domain *d, xen_mem_event_op_t *meo);
 
 
 /*
diff -r 196824008493 -r 94e407f39c38 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -23,6 +23,7 @@
 #define __MEM_SHARING_H__
 
 #include <public/domctl.h>
+#include <public/memory.h>
 
 /* Auditing of memory sharing code? */
 #define MEM_SHARING_AUDIT 0
@@ -56,6 +57,8 @@ int mem_sharing_unshare_page(struct doma
                              unsigned long gfn, 
                              uint16_t flags);
 int mem_sharing_sharing_resume(struct domain *d);
+int mem_sharing_memop(struct domain *d, 
+                       xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
 void mem_sharing_init(void);
diff -r 196824008493 -r 94e407f39c38 xen/include/public/domctl.h
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -711,47 +711,43 @@ struct xen_domctl_gdbsx_domstatus {
 
 /*
 * Domain memory paging
- * Page memory in and out. 
+ * Page memory in and out.
+ * Domctl interface to set up and tear down the 
+ * pager<->hypervisor interface. Use XENMEM_paging_op*
+ * to perform per-page operations.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING            1
 
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_NOMINATE   2
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_EVICT      3
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_PREP       4
-#define XEN_DOMCTL_MEM_EVENT_OP_PAGING_RESUME     5
 
 /*
  * Access permissions.
  *
+ * As with paging, use the domctl for teardown/setup of the
+ * helper<->hypervisor interface.
+ *
  * There are HVM hypercalls to set the per-page access permissions of every
  * page in a domain.  When one of these permissions--independent, read, 
  * write, and execute--is violated, the VCPU is paused and a memory event 
- * is sent with what happened.  (See public/mem_event.h)  The memory event 
- * handler can then resume the VCPU and redo the access with an 
- * ACCESS_RESUME mode for the following domctl.
+ * is sent with what happened.  (See public/mem_event.h) .
+ *
+ * The memory event handler can then resume the VCPU and redo the access 
+ * with a XENMEM_access_op_resume hypercall.
  */
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS            2
 
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_ENABLE     0
 #define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_DISABLE    1
-#define XEN_DOMCTL_MEM_EVENT_OP_ACCESS_RESUME     2
 
+/* Use for teardown/setup of helper<->hypervisor interface for paging, 
+ * access and sharing.*/
 struct xen_domctl_mem_event_op {
     uint32_t       op;           /* XEN_DOMCTL_MEM_EVENT_OP_*_* */
     uint32_t       mode;         /* XEN_DOMCTL_MEM_EVENT_OP_* */
 
-    union {
-        /* OP_ENABLE IN:  Virtual address of shared page */
-        uint64_aligned_t shared_addr;  
-        /* PAGING_PREP IN: buffer to immediately fill page in */
-        uint64_aligned_t buffer;
-    } u;
+    uint64_aligned_t shared_addr;  /* IN:  Virtual address of shared page */
     uint64_aligned_t ring_addr;    /* IN:  Virtual address of ring page */
-
-    /* Other OPs */
-    uint64_aligned_t gfn;          /* IN:  gfn of page being operated on */
 };
 typedef struct xen_domctl_mem_event_op xen_domctl_mem_event_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_event_op_t);
@@ -759,63 +755,15 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_e
 /*
  * Memory sharing operations
  */
-/* XEN_DOMCTL_mem_sharing_op */
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING                3
-
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_CONTROL        0
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GFN   1
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_NOMINATE_GREF  2
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_SHARE          3
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_RESUME         4
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GFN      5
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_MFN      6
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_DEBUG_GREF     7
-#define XEN_DOMCTL_MEM_EVENT_OP_SHARING_ADD_PHYSMAP    8
-
-#define XEN_DOMCTL_MEM_SHARING_S_HANDLE_INVALID  (-10)
-#define XEN_DOMCTL_MEM_SHARING_C_HANDLE_INVALID  (-9)
-
-/* The following allows sharing of grant refs. This is useful
- * for sharing utilities sitting as "filters" in IO backends
- * (e.g. memshr + blktap(2)). The IO backend is only exposed 
- * to grant references, and this allows sharing of the grefs */
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG   (1ULL << 62)
-
-#define XEN_DOMCTL_MEM_SHARING_FIELD_MAKE_GREF(field, val)  \
-    (field) = (XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG | val)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF(field)         \
-    ((field) & XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG)
-#define XEN_DOMCTL_MEM_SHARING_FIELD_GET_GREF(field)        \
-    ((field) & (~XEN_DOMCTL_MEM_SHARING_FIELD_IS_GREF_FLAG))
+/* XEN_DOMCTL_mem_sharing_op.
+ * The CONTROL sub-domctl is used for bringup/teardown. */
+#define XEN_DOMCTL_MEM_SHARING_CONTROL          0
 
 struct xen_domctl_mem_sharing_op {
-    uint8_t op; /* XEN_DOMCTL_MEM_EVENT_OP_* */
+    uint8_t op; /* XEN_DOMCTL_MEM_SHARING_* */
 
     union {
-        uint8_t enable;                   /* OP_CONTROL                */
-
-        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
-            union {
-                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
-                uint32_t      grant_ref;  /* IN: grant ref to nominate */
-            } u;
-            uint64_aligned_t  handle;     /* OUT: the handle           */
-        } nominate;
-        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
-            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
-            uint64_aligned_t source_handle; /* IN: handle to the source page */
-            domid_t          client_domain; /* IN: the client domain id */
-            uint64_aligned_t client_gfn;    /* IN: the client gfn */
-            uint64_aligned_t client_handle; /* IN: handle to the client page */
-        } share; 
-        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
-            union {
-                uint64_aligned_t gfn;      /* IN: gfn to debug          */
-                uint64_aligned_t mfn;      /* IN: mfn to debug          */
-                grant_ref_t    gref;       /* IN: gref to debug         */
-            } u;
-        } debug;
+        uint8_t enable;                   /* CONTROL */
     } u;
 };
 typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
diff -r 196824008493 -r 94e407f39c38 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -289,6 +289,12 @@ struct xen_pod_target {
 };
 typedef struct xen_pod_target xen_pod_target_t;
 
+#if defined(__XEN__) || defined(__XEN_TOOLS__)
+
+#ifndef uint64_aligned_t
+#define uint64_aligned_t uint64_t
+#endif
+
 /*
  * Get the number of MFNs saved through memory sharing.
  * The call never fails. 
@@ -296,6 +302,87 @@ typedef struct xen_pod_target xen_pod_ta
 #define XENMEM_get_sharing_freed_pages    18
 #define XENMEM_get_sharing_shared_pages   19
 
+#define XENMEM_paging_op                    20
+#define XENMEM_paging_op_nominate           0
+#define XENMEM_paging_op_evict              1
+#define XENMEM_paging_op_prep               2
+#define XENMEM_paging_op_resume             3
+
+#define XENMEM_access_op                    21
+#define XENMEM_access_op_resume             0
+
+struct xen_mem_event_op {
+    uint8_t     op;         /* XENMEM_*_op_* */
+    domid_t     domain;
+    
+
+    /* PAGING_PREP IN: buffer to immediately fill page in */
+    uint64_aligned_t    buffer;
+    /* Other OPs */
+    uint64_aligned_t    gfn;           /* IN:  gfn of page being operated on */
+};
+typedef struct xen_mem_event_op xen_mem_event_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op_t);
+
+#define XENMEM_sharing_op                   22
+#define XENMEM_sharing_op_nominate_gfn      0
+#define XENMEM_sharing_op_nominate_gref     1
+#define XENMEM_sharing_op_share             2
+#define XENMEM_sharing_op_resume            3
+#define XENMEM_sharing_op_debug_gfn         4
+#define XENMEM_sharing_op_debug_mfn         5
+#define XENMEM_sharing_op_debug_gref        6
+#define XENMEM_sharing_op_add_physmap       7
+
+#define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
+#define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)
+
+/* The following allows sharing of grant refs. This is useful
+ * for sharing utilities sitting as "filters" in IO backends
+ * (e.g. memshr + blktap(2)). The IO backend is only exposed 
+ * to grant references, and this allows sharing of the grefs */
+#define XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG   (1ULL << 62)
+
+#define XENMEM_SHARING_OP_FIELD_MAKE_GREF(field, val)  \
+    (field) = (XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG | val)
+#define XENMEM_SHARING_OP_FIELD_IS_GREF(field)         \
+    ((field) & XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG)
+#define XENMEM_SHARING_OP_FIELD_GET_GREF(field)        \
+    ((field) & (~XENMEM_SHARING_OP_FIELD_IS_GREF_FLAG))
+
+struct xen_mem_sharing_op {
+    uint8_t     op;     /* XENMEM_sharing_op_* */
+    domid_t     domain;
+
+    union {
+        struct mem_sharing_op_nominate {  /* OP_NOMINATE_xxx           */
+            union {
+                uint64_aligned_t gfn;     /* IN: gfn to nominate       */
+                uint32_t      grant_ref;  /* IN: grant ref to nominate */
+            } u;
+            uint64_aligned_t  handle;     /* OUT: the handle           */
+        } nominate;
+        struct mem_sharing_op_share {     /* OP_SHARE/ADD_PHYSMAP */
+            uint64_aligned_t source_gfn;    /* IN: the gfn of the source page */
+            uint64_aligned_t source_handle; /* IN: handle to the source page */
+            uint64_aligned_t client_gfn;    /* IN: the client gfn */
+            uint64_aligned_t client_handle; /* IN: handle to the client page */
+            domid_t  client_domain; /* IN: the client domain id */
+        } share; 
+        struct mem_sharing_op_debug {     /* OP_DEBUG_xxx */
+            union {
+                uint64_aligned_t gfn;      /* IN: gfn to debug          */
+                uint64_aligned_t mfn;      /* IN: mfn to debug          */
+                uint32_t gref;     /* IN: gref to debug         */
+            } u;
+        } debug;
+    } u;
+};
+typedef struct xen_mem_sharing_op xen_mem_sharing_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_mem_sharing_op_t);
+
+#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:06:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqP1c-0003p4-V3; Thu, 26 Jan 2012 13:06:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqP1b-0003mR-1Q
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:05:59 +0000
Received: from [85.158.139.83:18610] by server-12.bemta-5.messagelabs.com id
	84/A1-18193-D8F412F4; Thu, 26 Jan 2012 13:05:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327583109!12479712!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzkzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2709 invoked from network); 26 Jan 2012 13:05:09 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-6.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 13:05:09 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id E0A8A30006C;
	Thu, 26 Jan 2012 05:05:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ffspXcvWpVrN2cJhGPnQHJ2WucrkWb8phWdM5EKG73wV
	HwaqUxXG40GcH7dgLo3eCPdD5hZUNgpHT73AVdX3S/77BsJGZWgF368/MHA0GgQT
	iigiqQu3g0PSZLMNMhapEjV0kiyoVVy+23VN2pC0ZVEEqqh7GvK0ZUlXDMJY1M8=
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=l1kFOcxnH2otrDnaZF0JgClbnk0=; b=aZ43hwPSS7y
	e4yEmLAzv/IKQ16Hd3Pfxh753x9esMTyDgV6B5Snif32RCasMjzoIAg3rMiog/JK
	vee+9KXQHYs4uBzoSSXXf59anTimo3/470TcFaRCCdWy+l4tN4b1r3xxZ+YQfSfY
	39uR80FPb6Mqxutsmyha561vaRmeMjLI=
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 E3F37300064; 
	Thu, 26 Jan 2012 05:05:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d84b12d13ad68607dd98510e471d35b76143d6cb
Message-Id: <d84b12d13ad68607dd98.1327583325@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327583323@xdev.gridcentric.ca>
References: <patchbomb.1327583323@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 26 Jan 2012 08:08:45 -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, olaf@apefle.de,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: New sharing audit memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c              |  11 +++++++++++
 tools/libxc/xenctrl.h                |   1 +
 tools/tests/mem-sharing/memshrtool.c |  11 +++++++++++
 xen/arch/x86/mm/mem_sharing.c        |  13 ++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   3 +++
 xen/arch/x86/x86_64/mm.c             |   2 ++
 xen/include/asm-x86/mem_sharing.h    |   3 ++-
 xen/include/public/memory.h          |   1 +
 8 files changed, 37 insertions(+), 8 deletions(-)


Remove costly mem_sharting audits from the inline path, and instead make them
callable as a memop.

Have the audit function return the number of errors detected.

Update memshrtool to be able to trigger audits.

Set sharing audits as enabled by default.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 94e407f39c38 -r d84b12d13ad6 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,6 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_audit(xc_interface *xch)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_audit;
+
+    return do_memory_op(xch, XENMEM_sharing_op, &mso, sizeof(mso));
+}
+
 long xc_sharing_freed_pages(xc_interface *xch)
 {
     return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
diff -r 94e407f39c38 -r d84b12d13ad6 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1947,6 +1947,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
diff -r 94e407f39c38 -r d84b12d13ad6 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -27,6 +27,7 @@ static int usage(const char* prog)
     printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
     printf("                          - Populate a page in a domain with a shared page.\n");
     printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    printf("  audit                   - Audit the sharing subsytem in Xen.\n");
     return 1;
 }
 
@@ -160,6 +161,16 @@ int main(int argc, const char** argv)
         gfn = strtol(argv[3], NULL, 0);
         R(xc_memshr_debug_gfn(xch, domid, gfn));
     }
+    else if( !strcasecmp(cmd, "audit") )
+    {
+        int rc = xc_memshr_audit(xch);
+        if ( rc < 0 )
+        {
+            printf("error executing xc_memshr_audit: %s\n", strerror(errno));
+            return rc;
+        }
+        printf("Audit returned %d errors.\n", rc);
+    }
 
     return 0;
 }
diff -r 94e407f39c38 -r d84b12d13ad6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -47,8 +47,6 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
 #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)
 
@@ -81,7 +79,10 @@ static inline void audit_del_list(struct
 
 #else
 
-#define mem_sharing_audit() ((void)0)
+int mem_sharing_audit(void)
+{
+    return -ENOSYS;
+}
 
 #define audit_add_list(p)  ((void)0)
 static inline void audit_del_list(struct page_info *page)
@@ -207,7 +208,7 @@ static struct page_info* mem_sharing_loo
 }
 
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
+int mem_sharing_audit(void)
 {
     int errors = 0;
     unsigned long count_expected;
@@ -333,6 +334,7 @@ static void mem_sharing_audit(void)
         errors++;
     }
 
+    return errors;
 }
 #endif
 
@@ -903,7 +905,6 @@ int mem_sharing_unshare_page(struct doma
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
    
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1169,8 +1170,6 @@ int mem_sharing_memop(struct domain *d, 
             break;
     }
 
-    mem_sharing_audit();
-
     return rc;
 }
 
diff -r 94e407f39c38 -r d84b12d13ad6 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -3,6 +3,7 @@
 #include <compat/memory.h>
 #include <compat/xen.h>
 #include <asm/mem_event.h>
+#include <asm/mem_sharing.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -228,6 +229,8 @@ int compat_arch_memory_op(int op, XEN_GU
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r 94e407f39c38 -r d84b12d13ad6 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1117,6 +1117,8 @@ long subarch_memory_op(int op, XEN_GUEST
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r 94e407f39c38 -r d84b12d13ad6 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -26,7 +26,7 @@
 #include <public/memory.h>
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
+#define MEM_SHARING_AUDIT 1
 
 typedef uint64_t shr_handle_t; 
 
@@ -61,6 +61,7 @@ int mem_sharing_memop(struct domain *d,
                        xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
+int mem_sharing_audit(void);
 void mem_sharing_init(void);
 
 #else 
diff -r 94e407f39c38 -r d84b12d13ad6 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -333,6 +333,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op
 #define XENMEM_sharing_op_debug_mfn         5
 #define XENMEM_sharing_op_debug_gref        6
 #define XENMEM_sharing_op_add_physmap       7
+#define XENMEM_sharing_op_audit             8
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:06:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqP1c-0003p4-V3; Thu, 26 Jan 2012 13:06:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqP1b-0003mR-1Q
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:05:59 +0000
Received: from [85.158.139.83:18610] by server-12.bemta-5.messagelabs.com id
	84/A1-18193-D8F412F4; Thu, 26 Jan 2012 13:05:17 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327583109!12479712!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxNzkzNQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2709 invoked from network); 26 Jan 2012 13:05:09 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-6.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 13:05:09 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id E0A8A30006C;
	Thu, 26 Jan 2012 05:05:08 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=content-type
	:mime-version:content-transfer-encoding:subject:message-id
	:in-reply-to:references:date:from:to:cc; q=dns; s=
	lagarcavilla.org; b=ffspXcvWpVrN2cJhGPnQHJ2WucrkWb8phWdM5EKG73wV
	HwaqUxXG40GcH7dgLo3eCPdD5hZUNgpHT73AVdX3S/77BsJGZWgF368/MHA0GgQT
	iigiqQu3g0PSZLMNMhapEjV0kiyoVVy+23VN2pC0ZVEEqqh7GvK0ZUlXDMJY1M8=
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=l1kFOcxnH2otrDnaZF0JgClbnk0=; b=aZ43hwPSS7y
	e4yEmLAzv/IKQ16Hd3Pfxh753x9esMTyDgV6B5Snif32RCasMjzoIAg3rMiog/JK
	vee+9KXQHYs4uBzoSSXXf59anTimo3/470TcFaRCCdWy+l4tN4b1r3xxZ+YQfSfY
	39uR80FPb6Mqxutsmyha561vaRmeMjLI=
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 E3F37300064; 
	Thu, 26 Jan 2012 05:05:07 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: d84b12d13ad68607dd98510e471d35b76143d6cb
Message-Id: <d84b12d13ad68607dd98.1327583325@xdev.gridcentric.ca>
In-Reply-To: <patchbomb.1327583323@xdev.gridcentric.ca>
References: <patchbomb.1327583323@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Thu, 26 Jan 2012 08:08:45 -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, olaf@apefle.de,
	keir.xen@gmail.com, ian.jackson@citrix.com, adin@gridcentric.ca
Subject: [Xen-devel] [PATCH 2 of 2] x86/mm: New sharing audit memop
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 tools/libxc/xc_memshr.c              |  11 +++++++++++
 tools/libxc/xenctrl.h                |   1 +
 tools/tests/mem-sharing/memshrtool.c |  11 +++++++++++
 xen/arch/x86/mm/mem_sharing.c        |  13 ++++++-------
 xen/arch/x86/x86_64/compat/mm.c      |   3 +++
 xen/arch/x86/x86_64/mm.c             |   2 ++
 xen/include/asm-x86/mem_sharing.h    |   3 ++-
 xen/include/public/memory.h          |   1 +
 8 files changed, 37 insertions(+), 8 deletions(-)


Remove costly mem_sharting audits from the inline path, and instead make them
callable as a memop.

Have the audit function return the number of errors detected.

Update memshrtool to be able to trigger audits.

Set sharing audits as enabled by default.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Adin Scannell <adin@scannell.ca>

diff -r 94e407f39c38 -r d84b12d13ad6 tools/libxc/xc_memshr.c
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -211,6 +211,17 @@ int xc_memshr_debug_gref(xc_interface *x
     return xc_memshr_memop(xch, domid, &mso);
 }
 
+int xc_memshr_audit(xc_interface *xch)
+{
+    xen_mem_sharing_op_t mso;
+
+    memset(&mso, 0, sizeof(mso));
+
+    mso.op = XENMEM_sharing_op_audit;
+
+    return do_memory_op(xch, XENMEM_sharing_op, &mso, sizeof(mso));
+}
+
 long xc_sharing_freed_pages(xc_interface *xch)
 {
     return do_memory_op(xch, XENMEM_get_sharing_freed_pages, NULL, 0);
diff -r 94e407f39c38 -r d84b12d13ad6 tools/libxc/xenctrl.h
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -1947,6 +1947,7 @@ int xc_memshr_debug_mfn(xc_interface *xc
 int xc_memshr_debug_gref(xc_interface *xch,
                          domid_t domid,
                          grant_ref_t gref);
+int xc_memshr_audit(xc_interface *xch);
 
 int xc_flask_load(xc_interface *xc_handle, char *buf, uint32_t size);
 int xc_flask_context_to_sid(xc_interface *xc_handle, char *buf, uint32_t size, uint32_t *sid);
diff -r 94e407f39c38 -r d84b12d13ad6 tools/tests/mem-sharing/memshrtool.c
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -27,6 +27,7 @@ static int usage(const char* prog)
     printf("  add-to-physmap <domid> <gfn> <source> <source-gfn> <source-handle>\n");
     printf("                          - Populate a page in a domain with a shared page.\n");
     printf("  debug-gfn <domid> <gfn> - Debug a particular domain and gfn.\n");
+    printf("  audit                   - Audit the sharing subsytem in Xen.\n");
     return 1;
 }
 
@@ -160,6 +161,16 @@ int main(int argc, const char** argv)
         gfn = strtol(argv[3], NULL, 0);
         R(xc_memshr_debug_gfn(xch, domid, gfn));
     }
+    else if( !strcasecmp(cmd, "audit") )
+    {
+        int rc = xc_memshr_audit(xch);
+        if ( rc < 0 )
+        {
+            printf("error executing xc_memshr_audit: %s\n", strerror(errno));
+            return rc;
+        }
+        printf("Audit returned %d errors.\n", rc);
+    }
 
     return 0;
 }
diff -r 94e407f39c38 -r d84b12d13ad6 xen/arch/x86/mm/mem_sharing.c
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -47,8 +47,6 @@ DEFINE_PER_CPU(pg_lock_data_t, __pld);
 
 #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)
 
@@ -81,7 +79,10 @@ static inline void audit_del_list(struct
 
 #else
 
-#define mem_sharing_audit() ((void)0)
+int mem_sharing_audit(void)
+{
+    return -ENOSYS;
+}
 
 #define audit_add_list(p)  ((void)0)
 static inline void audit_del_list(struct page_info *page)
@@ -207,7 +208,7 @@ static struct page_info* mem_sharing_loo
 }
 
 #if MEM_SHARING_AUDIT
-static void mem_sharing_audit(void)
+int mem_sharing_audit(void)
 {
     int errors = 0;
     unsigned long count_expected;
@@ -333,6 +334,7 @@ static void mem_sharing_audit(void)
         errors++;
     }
 
+    return errors;
 }
 #endif
 
@@ -903,7 +905,6 @@ int mem_sharing_unshare_page(struct doma
     gfn_info_t *gfn_info = NULL;
     struct list_head *le;
    
-    mem_sharing_audit();
     mfn = get_gfn(d, gfn, &p2mt);
     
     /* Has someone already unshared it? */
@@ -1169,8 +1170,6 @@ int mem_sharing_memop(struct domain *d, 
             break;
     }
 
-    mem_sharing_audit();
-
     return rc;
 }
 
diff -r 94e407f39c38 -r d84b12d13ad6 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -3,6 +3,7 @@
 #include <compat/memory.h>
 #include <compat/xen.h>
 #include <asm/mem_event.h>
+#include <asm/mem_sharing.h>
 
 int compat_set_gdt(XEN_GUEST_HANDLE(uint) frame_list, unsigned int entries)
 {
@@ -228,6 +229,8 @@ int compat_arch_memory_op(int op, XEN_GU
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r 94e407f39c38 -r d84b12d13ad6 xen/arch/x86/x86_64/mm.c
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1117,6 +1117,8 @@ long subarch_memory_op(int op, XEN_GUEST
         xen_mem_sharing_op_t mso;
         if ( copy_from_guest(&mso, arg, 1) )
             return -EFAULT;
+        if ( mso.op == XENMEM_sharing_op_audit )
+            return mem_sharing_audit(); 
         rc = do_mem_event_op(op, mso.domain, (void *) &mso);
         if ( !rc && copy_to_guest(arg, &mso, 1) )
             return -EFAULT;
diff -r 94e407f39c38 -r d84b12d13ad6 xen/include/asm-x86/mem_sharing.h
--- a/xen/include/asm-x86/mem_sharing.h
+++ b/xen/include/asm-x86/mem_sharing.h
@@ -26,7 +26,7 @@
 #include <public/memory.h>
 
 /* Auditing of memory sharing code? */
-#define MEM_SHARING_AUDIT 0
+#define MEM_SHARING_AUDIT 1
 
 typedef uint64_t shr_handle_t; 
 
@@ -61,6 +61,7 @@ int mem_sharing_memop(struct domain *d,
                        xen_mem_sharing_op_t *mec);
 int mem_sharing_domctl(struct domain *d, 
                        xen_domctl_mem_sharing_op_t *mec);
+int mem_sharing_audit(void);
 void mem_sharing_init(void);
 
 #else 
diff -r 94e407f39c38 -r d84b12d13ad6 xen/include/public/memory.h
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -333,6 +333,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_mem_event_op
 #define XENMEM_sharing_op_debug_mfn         5
 #define XENMEM_sharing_op_debug_gref        6
 #define XENMEM_sharing_op_add_physmap       7
+#define XENMEM_sharing_op_audit             8
 
 #define XENMEM_SHARING_OP_S_HANDLE_INVALID  (-10)
 #define XENMEM_SHARING_OP_C_HANDLE_INVALID  (-9)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:08:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqP47-00044J-Hp; Thu, 26 Jan 2012 13:08:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqP45-000443-2u
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:08:33 +0000
Received: from [85.158.139.83:43787] by server-3.bemta-5.messagelabs.com id
	F9/AF-16424-050512F4; Thu, 26 Jan 2012 13:08:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327583311!12469939!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk2NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22589 invoked from network); 26 Jan 2012 13:08:31 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-4.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 13:08:31 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 0E8A245807C;
	Thu, 26 Jan 2012 05:08: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=JuBA+qilPts0kEJJKObl6ru2FnaThUMLTYSvlgxPSYZg
	uxXgP6I6LN8YHjxb6V36ClLB5hWMHh+R8WwACLe1r2dWHsL8JtOPh3Gm8B0xnnl3
	i4dAgZPhLYM+jvk1F3NqBLajkulYqd4jeLseqMl5nv3nid87kGba10KPykQYGiU=
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=8GPg0fdnBt5qqUU19N+T/MJXutg=; b=H/w2Uz3s
	XtJgfLFCUyzrc2q/IFHjXHxgTl6klut5/ajc9X4dqFjLUpgCntUz2aVHnok4otDr
	uBnGch2qpwx8ht0/RQLDLqjIZneUPyZIR1uWK+yNAYiPedY7CKuq1vvlWb9il7KH
	AMdRKiTpfPibOux0WnQixHeQ0pNZb/0pkWo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 2FFD5458071; 
	Thu, 26 Jan 2012 05:08:30 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 05:08:30 -0800
Message-ID: <179809993fc3f368ab813d31f07d5940.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126125435.GB74165@ocelot.phlegethon.org>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
	<20120126125435.GB74165@ocelot.phlegethon.org>
Date: Thu, 26 Jan 2012 05:08:30 -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 00 of 13] Sharing overhaul V4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:32 -0500 on 25 Jan (1327530744), Andres Lagar-Cavilla wrote:
>> This patch series brings about a set of changes to the sharing support
>> in the hypervisor and tools. Specifically:
>>
>> - Granular scalable locking: lock mfn's individually when
>> sharing/unsharing
>>   them. Do not rely on a global lock. Use RCU to maintain a list of all
>>   shared frames for audit purposes.
>>
>> - Refreshed stats: they now work (tm), and are accesible via libxc
>>   and console.
>>
>> - libxl/xl support to get sharing stats.
>>
>> - New sharing command "add to physmap", to directly populate a new
>> domain
>>   with shared frames.
>>
>> - Toolstack and memshr kept in sync.
>
> Applied all except #12; thank you.
>
> Tools maintainers, I think it would be a good idea to take #12 as well,
> in spite of the commit message saying 'not necessarily expecting it be
> added to the tree', in order to have an in-tree consumer of these
> interfaces.

Excellent, thanks. Patch 12 is demo code. Nice to have, but neither
critical nor particularly clean...

Cheers,
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 Jan 26 13:08:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:08:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqP47-00044J-Hp; Thu, 26 Jan 2012 13:08:35 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqP45-000443-2u
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:08:33 +0000
Received: from [85.158.139.83:43787] by server-3.bemta-5.messagelabs.com id
	F9/AF-16424-050512F4; Thu, 26 Jan 2012 13:08:32 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327583311!12469939!1
X-Originating-IP: [208.97.132.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDcgPT4gMTk2NzA=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22589 invoked from network); 26 Jan 2012 13:08:31 -0000
Received: from caiajhbdccah.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.207) by server-4.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 13:08:31 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 0E8A245807C;
	Thu, 26 Jan 2012 05:08: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=JuBA+qilPts0kEJJKObl6ru2FnaThUMLTYSvlgxPSYZg
	uxXgP6I6LN8YHjxb6V36ClLB5hWMHh+R8WwACLe1r2dWHsL8JtOPh3Gm8B0xnnl3
	i4dAgZPhLYM+jvk1F3NqBLajkulYqd4jeLseqMl5nv3nid87kGba10KPykQYGiU=
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=8GPg0fdnBt5qqUU19N+T/MJXutg=; b=H/w2Uz3s
	XtJgfLFCUyzrc2q/IFHjXHxgTl6klut5/ajc9X4dqFjLUpgCntUz2aVHnok4otDr
	uBnGch2qpwx8ht0/RQLDLqjIZneUPyZIR1uWK+yNAYiPedY7CKuq1vvlWb9il7KH
	AMdRKiTpfPibOux0WnQixHeQ0pNZb/0pkWo=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 2FFD5458071; 
	Thu, 26 Jan 2012 05:08:30 -0800 (PST)
Received: from 69.165.145.231 (proxying for 69.165.145.231)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 05:08:30 -0800
Message-ID: <179809993fc3f368ab813d31f07d5940.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126125435.GB74165@ocelot.phlegethon.org>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
	<20120126125435.GB74165@ocelot.phlegethon.org>
Date: Thu, 26 Jan 2012 05:08:30 -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 00 of 13] Sharing overhaul V4
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> At 22:32 -0500 on 25 Jan (1327530744), Andres Lagar-Cavilla wrote:
>> This patch series brings about a set of changes to the sharing support
>> in the hypervisor and tools. Specifically:
>>
>> - Granular scalable locking: lock mfn's individually when
>> sharing/unsharing
>>   them. Do not rely on a global lock. Use RCU to maintain a list of all
>>   shared frames for audit purposes.
>>
>> - Refreshed stats: they now work (tm), and are accesible via libxc
>>   and console.
>>
>> - libxl/xl support to get sharing stats.
>>
>> - New sharing command "add to physmap", to directly populate a new
>> domain
>>   with shared frames.
>>
>> - Toolstack and memshr kept in sync.
>
> Applied all except #12; thank you.
>
> Tools maintainers, I think it would be a good idea to take #12 as well,
> in spite of the commit message saying 'not necessarily expecting it be
> added to the tree', in order to have an in-tree consumer of these
> interfaces.

Excellent, thanks. Patch 12 is demo code. Nice to have, but neither
critical nor particularly clean...

Cheers,
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 Jan 26 13:09:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqP4o-00049I-06; Thu, 26 Jan 2012 13:09:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqP4m-000495-LF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:09:16 +0000
Received: from [85.158.138.51:39381] by server-5.bemta-3.messagelabs.com id
	E0/4F-02363-B70512F4; Thu, 26 Jan 2012 13:09:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327583354!10702257!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32200 invoked from network); 26 Jan 2012 13:09:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 13:09:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327583353; l=266;
	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=tYf6gdWY5USfjfNV7FJ4xiQ7mWw=;
	b=J2I6rrqiZSKmPhqEuCrv4TuIFw5NkqwoZ7l4CF+6FchaV3o+qovB65w1KWwrsHL/Kuf
	X+csweImoO4p8l7imBmbImF/lphGWtJR0zSQ1QUkvauSLbb4ll5lJmndd0VMvVdq5Aa1B
	xuFyVIOpMMQiqonww9dSJlt8vi6vM6Z0v0E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (cohen mo51) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a0030bo0QC1L9P ;
	Thu, 26 Jan 2012 14:08:48 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3F23D18637; Thu, 26 Jan 2012 14:08:51 +0100 (CET)
Date: Thu, 26 Jan 2012 14:08:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126130851.GB3355@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
	<20120126095401.GC21629@aepfle.de>
	<fa3478fb74da9017012ef302f1c21dfc.squirrel@webmail.lagarcavilla.org>
	<20120126121105.GB545@aepfle.de>
	<710a4eb4ec5c371e2120edf5cebb6976.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <710a4eb4ec5c371e2120edf5cebb6976.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for 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 Thu, Jan 26, Andres Lagar-Cavilla wrote:

> xenpaging not handling EFAULT ... that's a different issue/patch altogether.

I'm not sure wether EFAULT is something an app can or should catch. I
will have a look.


Other than that, the patch is ok.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:09:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:09:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqP4o-00049I-06; Thu, 26 Jan 2012 13:09:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqP4m-000495-LF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:09:16 +0000
Received: from [85.158.138.51:39381] by server-5.bemta-3.messagelabs.com id
	E0/4F-02363-B70512F4; Thu, 26 Jan 2012 13:09:15 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327583354!10702257!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32200 invoked from network); 26 Jan 2012 13:09:14 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 13:09:14 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327583353; l=266;
	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=tYf6gdWY5USfjfNV7FJ4xiQ7mWw=;
	b=J2I6rrqiZSKmPhqEuCrv4TuIFw5NkqwoZ7l4CF+6FchaV3o+qovB65w1KWwrsHL/Kuf
	X+csweImoO4p8l7imBmbImF/lphGWtJR0zSQ1QUkvauSLbb4ll5lJmndd0VMvVdq5Aa1B
	xuFyVIOpMMQiqonww9dSJlt8vi6vM6Z0v0E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (cohen mo51) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a0030bo0QC1L9P ;
	Thu, 26 Jan 2012 14:08:48 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 3F23D18637; Thu, 26 Jan 2012 14:08:51 +0100 (CET)
Date: Thu, 26 Jan 2012 14:08:51 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126130851.GB3355@aepfle.de>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
	<d4336e35f0bcb4fcb060.1327550010@xdev.gridcentric.ca>
	<20120126095401.GC21629@aepfle.de>
	<fa3478fb74da9017012ef302f1c21dfc.squirrel@webmail.lagarcavilla.org>
	<20120126121105.GB545@aepfle.de>
	<710a4eb4ec5c371e2120edf5cebb6976.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <710a4eb4ec5c371e2120edf5cebb6976.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,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 6 of 8] x86/mm: Properly account for 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 Thu, Jan 26, Andres Lagar-Cavilla wrote:

> xenpaging not handling EFAULT ... that's a different issue/patch altogether.

I'm not sure wether EFAULT is something an app can or should catch. I
will have a look.


Other than that, the patch is ok.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:17:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13: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 1RqPCC-0004XX-Vr; Thu, 26 Jan 2012 13:16:56 +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 1RqPCB-0004XS-Hr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:16:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327583790!64017814!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29417 invoked from network); 26 Jan 2012 13:16:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 13:16:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327583811; l=538;
	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=uN47sRNf2IJbDB2TV4bdEbqGe7I=;
	b=jXwixZjzqXqkgj10+wkpEKJLTuxclGbgnELZt6vqqi0x8W7FVvxs1Bebe/JF5wsw+05
	iNsByWGOXEbh2wbIkyh1iRrUlkrl6+DpNPLNQJTk1zijZhgjdppe2OonuYTx3CnsVB9ya
	Rv0h/6ddAa7+v0RqPLPBY+Yx70GC2D7Ce4E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (cohen mo12) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N05a7fo0QCxvhs ;
	Thu, 26 Jan 2012 14:16:43 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id ADFD818637; Thu, 26 Jan 2012 14:16:45 +0100 (CET)
Date: Thu, 26 Jan 2012 14:16:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120126131645.GA4156@aepfle.de>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
	<20120126125435.GB74165@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120126125435.GB74165@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, 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 00 of 13] Sharing overhaul 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 Thu, Jan 26, Tim Deegan wrote:

> Applied all except #12; thank you.
> 
> Tools maintainers, I think it would be a good idea to take #12 as well,
> in spite of the commit message saying 'not necessarily expecting it be
> added to the tree', in order to have an in-tree consumer of these
> interfaces.

I havent looked at the tool, but I think that having some sort of (easy
to run) test vehicle for the features we have is always good. So also
that other tool Andres sent to test access is good to have in the tree.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:17:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13: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 1RqPCC-0004XX-Vr; Thu, 26 Jan 2012 13:16:56 +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 1RqPCB-0004XS-Hr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:16:55 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327583790!64017814!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29417 invoked from network); 26 Jan 2012 13:16:31 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 13:16:31 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327583811; l=538;
	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=uN47sRNf2IJbDB2TV4bdEbqGe7I=;
	b=jXwixZjzqXqkgj10+wkpEKJLTuxclGbgnELZt6vqqi0x8W7FVvxs1Bebe/JF5wsw+05
	iNsByWGOXEbh2wbIkyh1iRrUlkrl6+DpNPLNQJTk1zijZhgjdppe2OonuYTx3CnsVB9ya
	Rv0h/6ddAa7+v0RqPLPBY+Yx70GC2D7Ce4E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (cohen mo12) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id N05a7fo0QCxvhs ;
	Thu, 26 Jan 2012 14:16:43 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id ADFD818637; Thu, 26 Jan 2012 14:16:45 +0100 (CET)
Date: Thu, 26 Jan 2012 14:16:45 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120126131645.GA4156@aepfle.de>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
	<20120126125435.GB74165@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120126125435.GB74165@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, 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 00 of 13] Sharing overhaul 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 Thu, Jan 26, Tim Deegan wrote:

> Applied all except #12; thank you.
> 
> Tools maintainers, I think it would be a good idea to take #12 as well,
> in spite of the commit message saying 'not necessarily expecting it be
> added to the tree', in order to have an in-tree consumer of these
> interfaces.

I havent looked at the tool, but I think that having some sort of (easy
to run) test vehicle for the features we have is always good. So also
that other tool Andres sent to test access is good to have in the tree.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:31:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPQ6-00050d-Eb; Thu, 26 Jan 2012 13:31:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqPQ4-00050Y-WD
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:31:17 +0000
Received: from [85.158.138.51:50335] by server-6.bemta-3.messagelabs.com id
	28/C5-31032-4A5512F4; Thu, 26 Jan 2012 13:31:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327584675!10784458!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15356 invoked from network); 26 Jan 2012 13:31:15 -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; 26 Jan 2012 13:31:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqPQ1-000KWT-G5; Thu, 26 Jan 2012 13:31:13 +0000
Date: Thu, 26 Jan 2012 13:31:13 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126133113.GD74165@ocelot.phlegethon.org>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 8] x86/mm fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:53 -0500 on 25 Jan (1327532004), Andres Lagar-Cavilla wrote:
> This patch series aggregates a number of fixes:
> - Fix the paging load operation to correct the m2p entry, and
>   promote the p2m entry to the final guest-accessible type
> - Fix locking around p2m_teardown
> - Fix read-only mapping of shared pages
> - Output to the console the per-domain count of shared pages
> - Eliminate a stale var from a p2m audit debugtrace printk
> - Correct accounting of paged out pages when a paging-out is
>   interrupted by a guest access
> - Simplify (and in some cases eliminate) use of p2m get_gfn*_unlocked
> - Allow for recursive locking in the mm-locks.h deadlock detection
>   scheme

All 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 Jan 26 13:31:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:31:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPQ6-00050d-Eb; Thu, 26 Jan 2012 13:31:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqPQ4-00050Y-WD
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:31:17 +0000
Received: from [85.158.138.51:50335] by server-6.bemta-3.messagelabs.com id
	28/C5-31032-4A5512F4; Thu, 26 Jan 2012 13:31:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327584675!10784458!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15356 invoked from network); 26 Jan 2012 13:31:15 -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; 26 Jan 2012 13:31:15 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqPQ1-000KWT-G5; Thu, 26 Jan 2012 13:31:13 +0000
Date: Thu, 26 Jan 2012 13:31:13 +0000
From: Tim Deegan <tim@xen.org>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126133113.GD74165@ocelot.phlegethon.org>
References: <patchbomb.1327550004@xdev.gridcentric.ca>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <patchbomb.1327550004@xdev.gridcentric.ca>
User-Agent: Mutt/1.4.2.1i
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, andres@gridcentric.ca,
	adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 0 of 8] x86/mm fixes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 22:53 -0500 on 25 Jan (1327532004), Andres Lagar-Cavilla wrote:
> This patch series aggregates a number of fixes:
> - Fix the paging load operation to correct the m2p entry, and
>   promote the p2m entry to the final guest-accessible type
> - Fix locking around p2m_teardown
> - Fix read-only mapping of shared pages
> - Output to the console the per-domain count of shared pages
> - Eliminate a stale var from a p2m audit debugtrace printk
> - Correct accounting of paged out pages when a paging-out is
>   interrupted by a guest access
> - Simplify (and in some cases eliminate) use of p2m get_gfn*_unlocked
> - Allow for recursive locking in the mm-locks.h deadlock detection
>   scheme

All 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 Jan 26 13:37:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPVq-0005Bg-FN; Thu, 26 Jan 2012 13:37:14 +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 1RqPVp-0005BQ-Eg
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:37:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327585002!3189240!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1031 invoked from network); 26 Jan 2012 13:36:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 13:36:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327585001; l=1374;
	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=Y1MEg2k1l+6a7T++Z0H3SPeZwoo=;
	b=OlqeA473MwOl/w0GgVlnrWJj8OVyvLHWaaepKyOruE08TbdZAXmgeg9sP3dYdioN/Rr
	noy3Dz59PLUCLbRWH8D1oed3B3u+hXNuQNGCVPDKBOCQ0rWSjlcHSY3pRWtdZ9o3Uq4tV
	BZAu+JFjhEwna7qlPGK7fq/kcOtAedGIZ04=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo58) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p01a23o0QCrEaY
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 14:36:29 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C276A18634
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 14:36:31 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: aa0d678fece208975984e8e59ca223c07fc50c06
Message-Id: <aa0d678fece208975984.1327584990@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Jan 2012 14:36:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: handle fallback in
 linux_privcmd_map_foreign_bulk properly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327584962 -3600
# Node ID aa0d678fece208975984e8e59ca223c07fc50c06
# Parent  89fdabcf315fdaabeebf05c51a6b3b6dd4c20e85
tools/libxc: handle fallback in linux_privcmd_map_foreign_bulk properly

If the first ioctl fails with ENOENT it means the command is known. If a
second attempt to map each gfn happens to fail then there is no need to
run the fallback code. Some gfns are paged and the fallback code would
not fix the failure. Instead return the EINVAL to the caller.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 89fdabcf315f -r aa0d678fece2 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -217,6 +217,7 @@ static void *linux_privcmd_map_foreign_b
 
     rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
 
+    /* Command was recognized, some gfn in arr are in paging state */
     if ( rc < 0 && errno == ENOENT )
     {
         for ( i = rc = 0; rc == 0 && i < num; i++ )
@@ -235,8 +236,8 @@ static void *linux_privcmd_map_foreign_b
             } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
         }
     }
-
-    if ( rc < 0 && errno == EINVAL && (int)num > 0 )
+    /* Command was not recognized, use fall back */
+    else if ( rc < 0 && errno == EINVAL && (int)num > 0 )
     {
         /*
          * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:37:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:37:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPVq-0005Bg-FN; Thu, 26 Jan 2012 13:37:14 +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 1RqPVp-0005BQ-Eg
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:37:13 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327585002!3189240!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1031 invoked from network); 26 Jan 2012 13:36:42 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-4.tower-21.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 13:36:42 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327585001; l=1374;
	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=Y1MEg2k1l+6a7T++Z0H3SPeZwoo=;
	b=OlqeA473MwOl/w0GgVlnrWJj8OVyvLHWaaepKyOruE08TbdZAXmgeg9sP3dYdioN/Rr
	noy3Dz59PLUCLbRWH8D1oed3B3u+hXNuQNGCVPDKBOCQ0rWSjlcHSY3pRWtdZ9o3Uq4tV
	BZAu+JFjhEwna7qlPGK7fq/kcOtAedGIZ04=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo58) (RZmta 27.5 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id p01a23o0QCrEaY
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 14:36:29 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C276A18634
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 14:36:31 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: aa0d678fece208975984e8e59ca223c07fc50c06
Message-Id: <aa0d678fece208975984.1327584990@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Jan 2012 14:36:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: handle fallback in
 linux_privcmd_map_foreign_bulk properly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327584962 -3600
# Node ID aa0d678fece208975984e8e59ca223c07fc50c06
# Parent  89fdabcf315fdaabeebf05c51a6b3b6dd4c20e85
tools/libxc: handle fallback in linux_privcmd_map_foreign_bulk properly

If the first ioctl fails with ENOENT it means the command is known. If a
second attempt to map each gfn happens to fail then there is no need to
run the fallback code. Some gfns are paged and the fallback code would
not fix the failure. Instead return the EINVAL to the caller.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 89fdabcf315f -r aa0d678fece2 tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -217,6 +217,7 @@ static void *linux_privcmd_map_foreign_b
 
     rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
 
+    /* Command was recognized, some gfn in arr are in paging state */
     if ( rc < 0 && errno == ENOENT )
     {
         for ( i = rc = 0; rc == 0 && i < num; i++ )
@@ -235,8 +236,8 @@ static void *linux_privcmd_map_foreign_b
             } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
         }
     }
-
-    if ( rc < 0 && errno == EINVAL && (int)num > 0 )
+    /* Command was not recognized, use fall back */
+    else if ( rc < 0 && errno == EINVAL && (int)num > 0 )
     {
         /*
          * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:41:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPZF-0005Ix-4W; Thu, 26 Jan 2012 13:40:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqPZE-0005Il-0D
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:40:44 +0000
Received: from [85.158.139.83:34875] by server-4.bemta-5.messagelabs.com id
	E4/F5-09697-7D7512F4; Thu, 26 Jan 2012 13:40:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327585230!12484772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26474 invoked from network); 26 Jan 2012 13:40:30 -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;
	26 Jan 2012 13:40:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10305181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 13:40:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 13:40:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 13:40:28 +0000
In-Reply-To: <osstest-11603-mainreport@xen.org>
References: <osstest-11603-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327585228.26983.85.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] 11603: 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 Thu, 2012-01-26 at 12:57 +0000, xen.org wrote:
> flight 11603 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11603/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 11601
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
>  build-i386                    4 xen-build                 fail REGR. vs. 11601
[...]
> ------------------------------------------------------------
> changeset:   24568:d8f280c78544
> tag:         tip
> user:        Ian Campbell <ian.campbell@citrix.com>
> date:        Thu Jan 26 11:06:40 2012 +0000
> 
>     seabios: update to 1.6.3.1 release
> 
>     This is the latest seabios stable release.
> 
>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
> 
        GIT=git /home/osstest/build.11603.build-amd64/xen-unstable/tools/firmware/../../scripts/git-checkout.sh http://xenbits.xen.org/git-http/seabios.git rel-1.6.3.1 seabios-dir
        using cache /volatile/git-cache...
        using cache /volatile/git-cache...
        locked cache /volatile/git-cache...
        processing /usr/local/bin/git clone http://xenbits.xen.org/git-http/seabios.git seabios-dir-remote.tmp...
        Cloning into seabios-dir-remote.tmp...
        updating cache /volatile/git-cache seabios-dir-remote.tmp...
        running /usr/bin/git checkout -b dummy rel-1.6.3.1...
        fatal: git checkout: updating paths is incompatible with switching branches.
        Did you intend to checkout 'rel-1.6.3.1' which can not be resolved as commit?
        
Clearly my push to seabios.git was not as successful as I thought -- I'm
investigating.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:41:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:41:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPZF-0005Ix-4W; Thu, 26 Jan 2012 13:40:45 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqPZE-0005Il-0D
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:40:44 +0000
Received: from [85.158.139.83:34875] by server-4.bemta-5.messagelabs.com id
	E4/F5-09697-7D7512F4; Thu, 26 Jan 2012 13:40:39 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327585230!12484772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26474 invoked from network); 26 Jan 2012 13:40:30 -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;
	26 Jan 2012 13:40:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10305181"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 13:40:28 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 13:40:28 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 13:40:28 +0000
In-Reply-To: <osstest-11603-mainreport@xen.org>
References: <osstest-11603-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327585228.26983.85.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] 11603: 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 Thu, 2012-01-26 at 12:57 +0000, xen.org wrote:
> flight 11603 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11603/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 11601
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
>  build-i386                    4 xen-build                 fail REGR. vs. 11601
[...]
> ------------------------------------------------------------
> changeset:   24568:d8f280c78544
> tag:         tip
> user:        Ian Campbell <ian.campbell@citrix.com>
> date:        Thu Jan 26 11:06:40 2012 +0000
> 
>     seabios: update to 1.6.3.1 release
> 
>     This is the latest seabios stable release.
> 
>     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>     Committed-by: Keir Fraser <keir@xen.org>
> 
        GIT=git /home/osstest/build.11603.build-amd64/xen-unstable/tools/firmware/../../scripts/git-checkout.sh http://xenbits.xen.org/git-http/seabios.git rel-1.6.3.1 seabios-dir
        using cache /volatile/git-cache...
        using cache /volatile/git-cache...
        locked cache /volatile/git-cache...
        processing /usr/local/bin/git clone http://xenbits.xen.org/git-http/seabios.git seabios-dir-remote.tmp...
        Cloning into seabios-dir-remote.tmp...
        updating cache /volatile/git-cache seabios-dir-remote.tmp...
        running /usr/bin/git checkout -b dummy rel-1.6.3.1...
        fatal: git checkout: updating paths is incompatible with switching branches.
        Did you intend to checkout 'rel-1.6.3.1' which can not be resolved as commit?
        
Clearly my push to seabios.git was not as successful as I thought -- I'm
investigating.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:44:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPcP-0005U9-2e; Thu, 26 Jan 2012 13:44:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqPcN-0005Tl-BF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:43:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327585432!12654637!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4557 invoked from network); 26 Jan 2012 13:43:53 -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;
	26 Jan 2012 13:43:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10305282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 13:43: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, 26 Jan 2012 13:43:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 13:43:52 +0000
In-Reply-To: <1327585228.26983.85.camel@zakaz.uk.xensource.com>
References: <osstest-11603-mainreport@xen.org>
	<1327585228.26983.85.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327585432.26983.86.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] 11603: 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 Thu, 2012-01-26 at 13:40 +0000, Ian Campbell wrote:
> On Thu, 2012-01-26 at 12:57 +0000, xen.org wrote:
> > flight 11603 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11603/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  build-amd64                   4 xen-build                 fail REGR. vs. 11601
> >  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
> >  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
> >  build-i386                    4 xen-build                 fail REGR. vs. 11601
> [...]
> > ------------------------------------------------------------
> > changeset:   24568:d8f280c78544
> > tag:         tip
> > user:        Ian Campbell <ian.campbell@citrix.com>
> > date:        Thu Jan 26 11:06:40 2012 +0000
> > 
> >     seabios: update to 1.6.3.1 release
> > 
> >     This is the latest seabios stable release.
> > 
> >     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >     Committed-by: Keir Fraser <keir@xen.org>
> > 
>         GIT=git /home/osstest/build.11603.build-amd64/xen-unstable/tools/firmware/../../scripts/git-checkout.sh http://xenbits.xen.org/git-http/seabios.git rel-1.6.3.1 seabios-dir
>         using cache /volatile/git-cache...
>         using cache /volatile/git-cache...
>         locked cache /volatile/git-cache...
>         processing /usr/local/bin/git clone http://xenbits.xen.org/git-http/seabios.git seabios-dir-remote.tmp...
>         Cloning into seabios-dir-remote.tmp...
>         updating cache /volatile/git-cache seabios-dir-remote.tmp...
>         running /usr/bin/git checkout -b dummy rel-1.6.3.1...
>         fatal: git checkout: updating paths is incompatible with switching branches.
>         Did you intend to checkout 'rel-1.6.3.1' which can not be resolved as commit?
>         
> Clearly my push to seabios.git was not as successful as I thought -- I'm
> investigating.

This was an http clone and I'd forgotten to run "git update-server-info"
on the server side. Is there a good way to automate that?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:44:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:44:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPcP-0005U9-2e; Thu, 26 Jan 2012 13:44:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqPcN-0005Tl-BF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:43:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327585432!12654637!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4557 invoked from network); 26 Jan 2012 13:43:53 -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;
	26 Jan 2012 13:43:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10305282"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 13:43: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, 26 Jan 2012 13:43:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 13:43:52 +0000
In-Reply-To: <1327585228.26983.85.camel@zakaz.uk.xensource.com>
References: <osstest-11603-mainreport@xen.org>
	<1327585228.26983.85.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327585432.26983.86.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] 11603: 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 Thu, 2012-01-26 at 13:40 +0000, Ian Campbell wrote:
> On Thu, 2012-01-26 at 12:57 +0000, xen.org wrote:
> > flight 11603 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11603/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  build-amd64                   4 xen-build                 fail REGR. vs. 11601
> >  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
> >  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
> >  build-i386                    4 xen-build                 fail REGR. vs. 11601
> [...]
> > ------------------------------------------------------------
> > changeset:   24568:d8f280c78544
> > tag:         tip
> > user:        Ian Campbell <ian.campbell@citrix.com>
> > date:        Thu Jan 26 11:06:40 2012 +0000
> > 
> >     seabios: update to 1.6.3.1 release
> > 
> >     This is the latest seabios stable release.
> > 
> >     Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> >     Committed-by: Keir Fraser <keir@xen.org>
> > 
>         GIT=git /home/osstest/build.11603.build-amd64/xen-unstable/tools/firmware/../../scripts/git-checkout.sh http://xenbits.xen.org/git-http/seabios.git rel-1.6.3.1 seabios-dir
>         using cache /volatile/git-cache...
>         using cache /volatile/git-cache...
>         locked cache /volatile/git-cache...
>         processing /usr/local/bin/git clone http://xenbits.xen.org/git-http/seabios.git seabios-dir-remote.tmp...
>         Cloning into seabios-dir-remote.tmp...
>         updating cache /volatile/git-cache seabios-dir-remote.tmp...
>         running /usr/bin/git checkout -b dummy rel-1.6.3.1...
>         fatal: git checkout: updating paths is incompatible with switching branches.
>         Did you intend to checkout 'rel-1.6.3.1' which can not be resolved as commit?
>         
> Clearly my push to seabios.git was not as successful as I thought -- I'm
> investigating.

This was an http clone and I'd forgotten to run "git update-server-info"
on the server side. Is there a good way to automate that?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:49:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:49:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPhO-0005uG-Ff; Thu, 26 Jan 2012 13:49:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqPhN-0005tr-2g
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:49:09 +0000
Received: from [85.158.139.83:35164] by server-4.bemta-5.messagelabs.com id
	C1/82-09697-0D9512F4; Thu, 26 Jan 2012 13:49:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327585741!12486838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31735 invoked from network); 26 Jan 2012 13:49:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 13:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10305531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 13:49: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;
	Thu, 26 Jan 2012 13:49:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 13:49:00 +0000
In-Reply-To: <1327585432.26983.86.camel@zakaz.uk.xensource.com>
References: <osstest-11603-mainreport@xen.org>
	<1327585228.26983.85.camel@zakaz.uk.xensource.com>
	<1327585432.26983.86.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327585740.26983.87.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] 11603: 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 Thu, 2012-01-26 at 13:43 +0000, Ian Campbell wrote:
> This was an http clone and I'd forgotten to run "git update-server-info"
> on the server side. Is there a good way to automate that?

To answer my own question:
http://www.bluishcoder.co.nz/2007/09/how-to-publish-git-repository.html
suggests "mv hooks/post-update.sample hooks/post-update" which I've now
done. We'll see next time I suppose.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 13:49:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 13:49:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqPhO-0005uG-Ff; Thu, 26 Jan 2012 13:49:10 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqPhN-0005tr-2g
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 13:49:09 +0000
Received: from [85.158.139.83:35164] by server-4.bemta-5.messagelabs.com id
	C1/82-09697-0D9512F4; Thu, 26 Jan 2012 13:49:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327585741!12486838!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31735 invoked from network); 26 Jan 2012 13:49:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 13:49:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10305531"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 13:49: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;
	Thu, 26 Jan 2012 13:49:01 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 13:49:00 +0000
In-Reply-To: <1327585432.26983.86.camel@zakaz.uk.xensource.com>
References: <osstest-11603-mainreport@xen.org>
	<1327585228.26983.85.camel@zakaz.uk.xensource.com>
	<1327585432.26983.86.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327585740.26983.87.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] 11603: 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 Thu, 2012-01-26 at 13:43 +0000, Ian Campbell wrote:
> This was an http clone and I'd forgotten to run "git update-server-info"
> on the server side. Is there a good way to automate that?

To answer my own question:
http://www.bluishcoder.co.nz/2007/09/how-to-publish-git-repository.html
suggests "mv hooks/post-update.sample hooks/post-update" which I've now
done. We'll see next time I suppose.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:29:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14: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 1RqQJZ-0007Fx-Gp; Thu, 26 Jan 2012 14:28:37 +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 1RqQJX-0007Fp-TB
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:28:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327588041!62596744!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26488 invoked from network); 26 Jan 2012 14:27:22 -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;
	26 Jan 2012 14:27:22 -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
	q0QERasJ009798; Thu, 26 Jan 2012 14:27:36 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 q0QERXKA015451; 
	Thu, 26 Jan 2012 09:27:34 -0500
Message-ID: <4F2162D6.40701@tycho.nsa.gov>
Date: Thu, 26 Jan 2012 09:27:34 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Roderick Colenbrander <thunderbird2k@gmail.com>
References: <CAEc3jaAJP7g6hA8_QC5vLq7vd0tKKwWR9ZR3ckkHf-izgjFceQ@mail.gmail.com>
In-Reply-To: <CAEc3jaAJP7g6hA8_QC5vLq7vd0tKKwWR9ZR3ckkHf-izgjFceQ@mail.gmail.com>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Race condition in gntdev 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 01/25/2012 08:49 PM, Roderick Colenbrander wrote:
> Hi Daniel and Konrad,
> 
> In an email thread at the end of last year ('Questions about GPLPV
> stability tests'), I mentioned a certain bug in the gntdev driver. I
> think I found the bug and would like your opinion. Since Daniel did a
> lot of work on gntdev recently, I think he is most familiar with the
> code.
> 
> The systems on which I see this bug run Xen 4.1.2 and Linux 2.6.32.48
> (pvops), but the same bug should be in Linux 3.x since the code is
> similar.
> 
> Let me summarize the problem. At some point in time a DomU is
> shutdown. Apparently shutdown takes too long according to Xend,
> causing it to SIGKILL qemu-dm:
> [2012-01-16 14:54:34 3419] INFO (XendDomainInfo:2078) Domain has
> shutdown: name=win7-1 id=7581 reason=poweroff.
> [2012-01-16 14:54:34 3419] DEBUG (XendDomainInfo:3071)
> XendDomainInfo.destroy: domid=7581
> [2012-01-16 14:54:36 3419] DEBUG (XendDomainInfo:2401) Destroying device model
> [2012-01-16 14:54:46 3419] WARNING (image:649) DeviceModel 31742 took
> more than 10s to terminate: sending SIGKILL
> 
> This triggers the following Oops:
> [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!
> 
> 
> Below I attached the in my opinion relevant part of the gntdev driver:
> static int gntdev_open(struct inode *inode, struct file *flip)
> {
> ...
> ...
> 	priv->mm = get_task_mm(current);
> 	if (!priv->mm) {
> 		kfree(priv);
> 		return -ENOMEM;
> 	}
> 	priv->mn.ops = &gntdev_mmu_ops;
> 	mmu_notifier_register(&priv->mn, priv->mm);
> 	mmput(priv->mm);
> 
> 	flip->private_data = priv;
> ...
> }
> 
> static int gntdev_release(struct inode *inode, struct file *flip)
> {
> 	struct gntdev_priv *priv = flip->private_data;
> ...
> 	mmu_notifier_unregister(&priv->mn, priv->mm);
> 	kfree(priv);
> 	return 0;
> }
> 
> I think the bug is due to gntdev not handling reference counting
> (mm->mm_users) in combination with a race condition. The function
> gntdev_open calls get_task_mm (which increases mm_users) but straight
> after storing 'mm' in 'priv' it performs a mmput which again decreases
> the reference count. Since mmu_notifier_register also increases the
> reference count, the count is definitely positive after gntdev_open. I
> suspect that due to a race condition (after 10 seconds, xend performed
> a SIGKILL) the mm structure already got freed somehow. This causes a
> bug in mmu_notifier_unregister.
> 
> If this is correct then the the 'mmput' line should be moved to
> gntdev_release and placed after mmu_notifier_unregister. What do you
> think? If this is correct, I will send a patch for this.
> 
> Regards,
> Roderick Colenbrander

If this is correct, I think it's a bug in mmu_notifier_register - it
already increments mm->mm_count and there is a note in the function
description suggesting that this suffices to run mmu_notifier_unregister
later.

I'm not very familiar with the MMU notifier (my changes were made for the
case where it was not used) so it might be assuming the extra reference
you are proposing - especially if that change fixes the bug.

-- 
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 Jan 26 14:29:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14: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 1RqQJZ-0007Fx-Gp; Thu, 26 Jan 2012 14:28:37 +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 1RqQJX-0007Fp-TB
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:28:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327588041!62596744!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26488 invoked from network); 26 Jan 2012 14:27:22 -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;
	26 Jan 2012 14:27:22 -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
	q0QERasJ009798; Thu, 26 Jan 2012 14:27:36 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 q0QERXKA015451; 
	Thu, 26 Jan 2012 09:27:34 -0500
Message-ID: <4F2162D6.40701@tycho.nsa.gov>
Date: Thu, 26 Jan 2012 09:27:34 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Roderick Colenbrander <thunderbird2k@gmail.com>
References: <CAEc3jaAJP7g6hA8_QC5vLq7vd0tKKwWR9ZR3ckkHf-izgjFceQ@mail.gmail.com>
In-Reply-To: <CAEc3jaAJP7g6hA8_QC5vLq7vd0tKKwWR9ZR3ckkHf-izgjFceQ@mail.gmail.com>
X-Enigmail-Version: 1.3.4
Cc: Konrad Rzeszutek Wilk <konrad@darnok.org>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Race condition in gntdev 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 01/25/2012 08:49 PM, Roderick Colenbrander wrote:
> Hi Daniel and Konrad,
> 
> In an email thread at the end of last year ('Questions about GPLPV
> stability tests'), I mentioned a certain bug in the gntdev driver. I
> think I found the bug and would like your opinion. Since Daniel did a
> lot of work on gntdev recently, I think he is most familiar with the
> code.
> 
> The systems on which I see this bug run Xen 4.1.2 and Linux 2.6.32.48
> (pvops), but the same bug should be in Linux 3.x since the code is
> similar.
> 
> Let me summarize the problem. At some point in time a DomU is
> shutdown. Apparently shutdown takes too long according to Xend,
> causing it to SIGKILL qemu-dm:
> [2012-01-16 14:54:34 3419] INFO (XendDomainInfo:2078) Domain has
> shutdown: name=win7-1 id=7581 reason=poweroff.
> [2012-01-16 14:54:34 3419] DEBUG (XendDomainInfo:3071)
> XendDomainInfo.destroy: domid=7581
> [2012-01-16 14:54:36 3419] DEBUG (XendDomainInfo:2401) Destroying device model
> [2012-01-16 14:54:46 3419] WARNING (image:649) DeviceModel 31742 took
> more than 10s to terminate: sending SIGKILL
> 
> This triggers the following Oops:
> [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!
> 
> 
> Below I attached the in my opinion relevant part of the gntdev driver:
> static int gntdev_open(struct inode *inode, struct file *flip)
> {
> ...
> ...
> 	priv->mm = get_task_mm(current);
> 	if (!priv->mm) {
> 		kfree(priv);
> 		return -ENOMEM;
> 	}
> 	priv->mn.ops = &gntdev_mmu_ops;
> 	mmu_notifier_register(&priv->mn, priv->mm);
> 	mmput(priv->mm);
> 
> 	flip->private_data = priv;
> ...
> }
> 
> static int gntdev_release(struct inode *inode, struct file *flip)
> {
> 	struct gntdev_priv *priv = flip->private_data;
> ...
> 	mmu_notifier_unregister(&priv->mn, priv->mm);
> 	kfree(priv);
> 	return 0;
> }
> 
> I think the bug is due to gntdev not handling reference counting
> (mm->mm_users) in combination with a race condition. The function
> gntdev_open calls get_task_mm (which increases mm_users) but straight
> after storing 'mm' in 'priv' it performs a mmput which again decreases
> the reference count. Since mmu_notifier_register also increases the
> reference count, the count is definitely positive after gntdev_open. I
> suspect that due to a race condition (after 10 seconds, xend performed
> a SIGKILL) the mm structure already got freed somehow. This causes a
> bug in mmu_notifier_unregister.
> 
> If this is correct then the the 'mmput' line should be moved to
> gntdev_release and placed after mmu_notifier_unregister. What do you
> think? If this is correct, I will send a patch for this.
> 
> Regards,
> Roderick Colenbrander

If this is correct, I think it's a bug in mmu_notifier_register - it
already increments mm->mm_count and there is a note in the function
description suggesting that this suffices to run mmu_notifier_unregister
later.

I'm not very familiar with the MMU notifier (my changes were made for the
case where it was not used) so it might be assuming the extra reference
you are proposing - especially if that change fixes the bug.

-- 
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 Jan 26 14:36:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQR0-0007SE-JS; Thu, 26 Jan 2012 14:36:18 +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 1RqQQy-0007Ry-LF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:36:16 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327588570!12084797!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19099 invoked from network); 26 Jan 2012 14:36:10 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE004.bigfish.com) (213.199.154.207)
	by server-13.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Jan 2012 14:36:10 -0000
Received: from mail98-am1-R.bigfish.com (10.3.201.242) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 14:36:09 +0000
Received: from mail98-am1 (localhost [127.0.0.1])	by mail98-am1-R.bigfish.com
	(Postfix) with ESMTP id BC313802A1	for
	<xen-devel@lists.xensource.com>; Thu,
	26 Jan 2012 14:36:09 +0000 (UTC)
X-SpamScore: 4
X-BigFish: VPS4(z33fclzzz1202hzzz2dhc1bhc31hc1ah668h839h)
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 mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1
	(MessageSwitch) id 132758856713333_9934; Thu, 26 Jan 2012 14:36:07 +0000
	(UTC)
Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.245])	by
	mail98-am1.bigfish.com (Postfix) with ESMTP id E7F5E60044	for
	<xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 14:36:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 14:36:03 +0000
X-WSS-ID: 0LYETVW-01-H96-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 2497210280BB	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:35:56 -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, 26 Jan 2012 08:36:15 -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;
	Thu, 26 Jan 2012 08:36:00 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Jan 2012
	09:35:59 -0500
Message-ID: <4F2164CE.6070609@amd.com>
Date: Thu, 26 Jan 2012 15:35:58 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] seabios build 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


gmake[6]: Entering directory tools/firmware/seabios-dir-remote
   Building ld scripts (version "1.6.3.1-20120126_152501")
env: python: No such file or directory
gmake[6]: *** [out/romlayout16.lds] Error 127


The python scripts must be invoked with $(PYTHON) as done
throughout the build system.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:36:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:36:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQR0-0007SE-JS; Thu, 26 Jan 2012 14:36:18 +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 1RqQQy-0007Ry-LF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:36:16 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327588570!12084797!1
X-Originating-IP: [213.199.154.207]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19099 invoked from network); 26 Jan 2012 14:36:10 -0000
Received: from am1ehsobe004.messaging.microsoft.com (HELO
	AM1EHSOBE004.bigfish.com) (213.199.154.207)
	by server-13.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Jan 2012 14:36:10 -0000
Received: from mail98-am1-R.bigfish.com (10.3.201.242) by
	AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 14:36:09 +0000
Received: from mail98-am1 (localhost [127.0.0.1])	by mail98-am1-R.bigfish.com
	(Postfix) with ESMTP id BC313802A1	for
	<xen-devel@lists.xensource.com>; Thu,
	26 Jan 2012 14:36:09 +0000 (UTC)
X-SpamScore: 4
X-BigFish: VPS4(z33fclzzz1202hzzz2dhc1bhc31hc1ah668h839h)
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 mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1
	(MessageSwitch) id 132758856713333_9934; Thu, 26 Jan 2012 14:36:07 +0000
	(UTC)
Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.245])	by
	mail98-am1.bigfish.com (Postfix) with ESMTP id E7F5E60044	for
	<xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 14:36:06 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 14:36:03 +0000
X-WSS-ID: 0LYETVW-01-H96-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 2497210280BB	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:35:56 -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, 26 Jan 2012 08:36:15 -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;
	Thu, 26 Jan 2012 08:36:00 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Jan 2012
	09:35:59 -0500
Message-ID: <4F2164CE.6070609@amd.com>
Date: Thu, 26 Jan 2012 15:35:58 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-OriginatorOrg: amd.com
Subject: [Xen-devel] seabios build 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


gmake[6]: Entering directory tools/firmware/seabios-dir-remote
   Building ld scripts (version "1.6.3.1-20120126_152501")
env: python: No such file or directory
gmake[6]: *** [out/romlayout16.lds] Error 127


The python scripts must be invoked with $(PYTHON) as done
throughout the build system.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:41:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQVE-0007cU-HD; Thu, 26 Jan 2012 14:40:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RqQVD-0007cO-Fp
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:40:39 +0000
Received: from [85.158.138.51:49545] by server-9.bemta-3.messagelabs.com id
	D9/B7-31168-6E5612F4; Thu, 26 Jan 2012 14:40:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327588837!10764190!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17139 invoked from network); 26 Jan 2012 14:40:38 -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; 26 Jan 2012 14:40:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 14:40:37 +0000
Message-Id: <4F21743C020000780006F3AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 14:41:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F2144EE.9040808@citrix.com>
In-Reply-To: <4F2144EE.9040808@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> XenServer by default boots without a serial console (buggy hardware
> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
> writing to the vga text area looks ugly whilst dom0 is trying to set up
> non-text mode and display  the splash screen.
> 
> We have been using "console=" to prevent this behavior for a while, but
> presented herewith is a patch to fix the problem correctly.

While I don't mind the patch, I'm completely confused by the description:
Where is it that Xen writes to VGA text area after control was passed to
Dom0?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:41:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:41:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQVE-0007cU-HD; Thu, 26 Jan 2012 14:40:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RqQVD-0007cO-Fp
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:40:39 +0000
Received: from [85.158.138.51:49545] by server-9.bemta-3.messagelabs.com id
	D9/B7-31168-6E5612F4; Thu, 26 Jan 2012 14:40:38 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327588837!10764190!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17139 invoked from network); 26 Jan 2012 14:40:38 -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; 26 Jan 2012 14:40:38 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 14:40:37 +0000
Message-Id: <4F21743C020000780006F3AA@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 14:41:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F2144EE.9040808@citrix.com>
In-Reply-To: <4F2144EE.9040808@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> XenServer by default boots without a serial console (buggy hardware
> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
> writing to the vga text area looks ugly whilst dom0 is trying to set up
> non-text mode and display  the splash screen.
> 
> We have been using "console=" to prevent this behavior for a while, but
> presented herewith is a patch to fix the problem correctly.

While I don't mind the patch, I'm completely confused by the description:
Where is it that Xen writes to VGA text area after control was passed to
Dom0?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:48:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQco-000866-ED; Thu, 26 Jan 2012 14:48:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqQco-00085y-1S
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:48:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327589173!50177640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7417 invoked from network); 26 Jan 2012 14:46:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 14:46:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10307403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 14:48:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 14:48: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
	1RqQch-0000g8-Io; Thu, 26 Jan 2012 14:48:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqQch-0003cu-HN;
	Thu, 26 Jan 2012 14:48:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.26551.525634.216845@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 14:48:23 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327567516.26983.9.camel@zakaz.uk.xensource.com>
References: <osstest-11601-mainreport@xen.org>
	<1327567516.26983.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] [xen-unstable test] 11601: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> Both of these are failing with:
>         2012-01-26 05:08:15 Z toolstack xl
>         Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13.
>         2012-01-26 05:08:15 Z executing ssh ... root@10.80.249.57 xl create 
>         Config file not specified and none in save file
>         2012-01-26 05:08:15 Z command nonzero waitstatus 1536: ssh -o StrictHostKeyChecking=no \
>         	-o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 \
>         	-o PasswordAuthentication=no -o ChallengeResponseAuthentication=no \
>         	-o UserKnownHostsFile=tmp/t.known_hosts_11601.test-amd64-i386-rhel6hvm-amd root@10.80.249.57 xl create 
>         
> Which is presumably a harness failure.

Yes.

> I'm not sure I 100% follow things but it seems that
> "toolstack()->{CfgPathVar}" is going to be "xlpath" rather than
> "cfgpath" but that Osstest.pm:selectguest is only setting up cfgpath.

This is an obsolete feature from when libxl didn't support the same
config files as xend.  I have switched this to using the .cfg file
rather than expecting a different file.

This may break 4.0 I guess, but if so I'll deal with that then.  4.0's
xl is pretty ropey 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 Jan 26 14:48:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:48:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQco-000866-ED; Thu, 26 Jan 2012 14:48:30 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqQco-00085y-1S
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:48:30 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327589173!50177640!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7417 invoked from network); 26 Jan 2012 14:46:14 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 14:46:14 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10307403"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 14:48:23 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 14:48: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
	1RqQch-0000g8-Io; Thu, 26 Jan 2012 14:48:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqQch-0003cu-HN;
	Thu, 26 Jan 2012 14:48:23 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.26551.525634.216845@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 14:48:23 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327567516.26983.9.camel@zakaz.uk.xensource.com>
References: <osstest-11601-mainreport@xen.org>
	<1327567516.26983.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] [xen-unstable test] 11601: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> Both of these are failing with:
>         2012-01-26 05:08:15 Z toolstack xl
>         Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13.
>         2012-01-26 05:08:15 Z executing ssh ... root@10.80.249.57 xl create 
>         Config file not specified and none in save file
>         2012-01-26 05:08:15 Z command nonzero waitstatus 1536: ssh -o StrictHostKeyChecking=no \
>         	-o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 \
>         	-o PasswordAuthentication=no -o ChallengeResponseAuthentication=no \
>         	-o UserKnownHostsFile=tmp/t.known_hosts_11601.test-amd64-i386-rhel6hvm-amd root@10.80.249.57 xl create 
>         
> Which is presumably a harness failure.

Yes.

> I'm not sure I 100% follow things but it seems that
> "toolstack()->{CfgPathVar}" is going to be "xlpath" rather than
> "cfgpath" but that Osstest.pm:selectguest is only setting up cfgpath.

This is an obsolete feature from when libxl didn't support the same
config files as xend.  I have switched this to using the .cfg file
rather than expecting a different file.

This may break 4.0 I guess, but if so I'll deal with that then.  4.0's
xl is pretty ropey 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 Jan 26 14:51:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:51:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQfL-0008Ch-0D; Thu, 26 Jan 2012 14:51:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqQfJ-0008CW-7P
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:51:05 +0000
Received: from [85.158.138.51:7651] by server-2.bemta-3.messagelabs.com id
	03/34-24515-858612F4; Thu, 26 Jan 2012 14:51:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327589463!10617453!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23198 invoked from network); 26 Jan 2012 14:51:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 14:51:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327589463; l=3237;
	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=WMMn1+j1vhyit2Bsl2/I+skfSS4=;
	b=J2NLK2FLmKt9vZfQctQrJs4vS8wQHUW6dMb6k3Mc/zn/GUS+VDM08jldoqpzjNB7CTp
	n7LFc4ilqc621BQBBEMTYovwqExZOAsjT0LmZ3zKfSwse5/2hVu90mz2GTpRv56H0l/0+
	CROz+KDm9b6qGBIi9VnY3wKTzOZgvMI+PmY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (jimi mo52) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id B00c6eo0QEa42x
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 15:51:01 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E93A618634
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 15:51:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bace47d7623cb92d5b080c54d3850642b8c52b46
Message-Id: <bace47d7623cb92d5b08.1327589462@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Jan 2012 15:51:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: send page-in requests in batches
 in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327589312 -3600
# Node ID bace47d7623cb92d5b080c54d3850642b8c52b46
# Parent  a87cbe503fed9e15d90d0bf6645d835331ec8874
tools/libxc: send page-in requests in batches in linux_privcmd_map_foreign_bulk

One of the bottlenecks with foreign page-in request is the poor retry
handling in linux_privcmd_map_foreign_bulk(). It sends one request per
paged gfn at a time and it waits until the gfn is accessible. This
causes long delays in mmap requests from qemu-dm and xc_save.

Instead of sending one request at a time, walk the entire gfn list and
send batches of mmap requests. They will eventually end up in the pagers
request ring (if it has room again), and will fill up this ring so that
in turn the pager can also process page-in in batches.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a87cbe503fed -r bace47d7623c tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -191,6 +191,59 @@ static void *linux_privcmd_map_foreign_b
     return addr;
 }
 
+/*
+ * Retry mmap of paged gfns in batches
+ * retuns < 0 on fatal error
+ * returns 0 if all gfns left paging state
+ * returns > 0 if some gfns are still in paging state
+ *
+ * Walk all gfns are assemble blocks of gfns in paging state.
+ * This will keep the request ring full and avoids delays.
+ */
+static int retry_paged(int fd, uint32_t dom, void *addr,
+                       const xen_pfn_t *arr, int *err, unsigned int num)
+{
+    privcmd_mmapbatch_v2_t ioctlx;
+    int rc, paged = 0, i = 0;
+    
+    do
+    {
+        /* Skip gfns not in paging state */
+        if ( err[i] != -ENOENT )
+        {
+            i++;
+            continue;
+        }
+
+        paged++;
+
+        /* At least one gfn is still in paging state */
+        ioctlx.num = 1;
+        ioctlx.dom = dom;
+        ioctlx.addr = (unsigned long)addr + ((unsigned long)i<<XC_PAGE_SHIFT);
+        ioctlx.arr = arr + i;
+        ioctlx.err = err + i;
+        
+        /* Assemble a batch of requests */
+        while ( ++i < num )
+        {
+            if ( err[i] != -ENOENT )
+                break;
+            ioctlx.num++;
+        }
+        
+        /* Send request and abort on fatal error */
+        rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
+        if ( rc < 0 && errno != ENOENT )
+            goto out;
+
+    } while ( i < num );
+    
+    rc = paged;
+out:
+    return rc;
+}
+
 static void *linux_privcmd_map_foreign_bulk(xc_interface *xch, xc_osdep_handle h,
                                             uint32_t dom, int prot,
                                             const xen_pfn_t *arr, int *err, unsigned int num)
@@ -220,21 +273,10 @@ static void *linux_privcmd_map_foreign_b
     /* Command was recognized, some gfn in arr are in paging state */
     if ( rc < 0 && errno == ENOENT )
     {
-        for ( i = rc = 0; rc == 0 && i < num; i++ )
-        {
-            if ( err[i] != -ENOENT )
-                continue;
-
-            ioctlx.num = 1;
-            ioctlx.dom = dom;
-            ioctlx.addr = (unsigned long)addr + ((unsigned long)i<<XC_PAGE_SHIFT);
-            ioctlx.arr = arr + i;
-            ioctlx.err = err + i;
-            do {
-                usleep(100);
-                rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
-            } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
-        }
+        do {
+            usleep(100);
+            rc = retry_paged(fd, dom, addr, arr, err, num);
+        } while ( rc > 0 );
     }
     /* Command was not recognized, use fall back */
     else if ( rc < 0 && errno == EINVAL && (int)num > 0 )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:51:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:51:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQfL-0008Ch-0D; Thu, 26 Jan 2012 14:51:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqQfJ-0008CW-7P
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:51:05 +0000
Received: from [85.158.138.51:7651] by server-2.bemta-3.messagelabs.com id
	03/34-24515-858612F4; Thu, 26 Jan 2012 14:51:04 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327589463!10617453!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAzMjYzNzg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23198 invoked from network); 26 Jan 2012 14:51:03 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 14:51:03 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327589463; l=3237;
	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=WMMn1+j1vhyit2Bsl2/I+skfSS4=;
	b=J2NLK2FLmKt9vZfQctQrJs4vS8wQHUW6dMb6k3Mc/zn/GUS+VDM08jldoqpzjNB7CTp
	n7LFc4ilqc621BQBBEMTYovwqExZOAsjT0LmZ3zKfSwse5/2hVu90mz2GTpRv56H0l/0+
	CROz+KDm9b6qGBIi9VnY3wKTzOZgvMI+PmY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (jimi mo52) (RZmta 27.5 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id B00c6eo0QEa42x
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 15:51:01 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id E93A618634
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 15:51:03 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: bace47d7623cb92d5b080c54d3850642b8c52b46
Message-Id: <bace47d7623cb92d5b08.1327589462@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Jan 2012 15:51:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: send page-in requests in batches
 in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327589312 -3600
# Node ID bace47d7623cb92d5b080c54d3850642b8c52b46
# Parent  a87cbe503fed9e15d90d0bf6645d835331ec8874
tools/libxc: send page-in requests in batches in linux_privcmd_map_foreign_bulk

One of the bottlenecks with foreign page-in request is the poor retry
handling in linux_privcmd_map_foreign_bulk(). It sends one request per
paged gfn at a time and it waits until the gfn is accessible. This
causes long delays in mmap requests from qemu-dm and xc_save.

Instead of sending one request at a time, walk the entire gfn list and
send batches of mmap requests. They will eventually end up in the pagers
request ring (if it has room again), and will fill up this ring so that
in turn the pager can also process page-in in batches.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r a87cbe503fed -r bace47d7623c tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -191,6 +191,59 @@ static void *linux_privcmd_map_foreign_b
     return addr;
 }
 
+/*
+ * Retry mmap of paged gfns in batches
+ * retuns < 0 on fatal error
+ * returns 0 if all gfns left paging state
+ * returns > 0 if some gfns are still in paging state
+ *
+ * Walk all gfns are assemble blocks of gfns in paging state.
+ * This will keep the request ring full and avoids delays.
+ */
+static int retry_paged(int fd, uint32_t dom, void *addr,
+                       const xen_pfn_t *arr, int *err, unsigned int num)
+{
+    privcmd_mmapbatch_v2_t ioctlx;
+    int rc, paged = 0, i = 0;
+    
+    do
+    {
+        /* Skip gfns not in paging state */
+        if ( err[i] != -ENOENT )
+        {
+            i++;
+            continue;
+        }
+
+        paged++;
+
+        /* At least one gfn is still in paging state */
+        ioctlx.num = 1;
+        ioctlx.dom = dom;
+        ioctlx.addr = (unsigned long)addr + ((unsigned long)i<<XC_PAGE_SHIFT);
+        ioctlx.arr = arr + i;
+        ioctlx.err = err + i;
+        
+        /* Assemble a batch of requests */
+        while ( ++i < num )
+        {
+            if ( err[i] != -ENOENT )
+                break;
+            ioctlx.num++;
+        }
+        
+        /* Send request and abort on fatal error */
+        rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
+        if ( rc < 0 && errno != ENOENT )
+            goto out;
+
+    } while ( i < num );
+    
+    rc = paged;
+out:
+    return rc;
+}
+
 static void *linux_privcmd_map_foreign_bulk(xc_interface *xch, xc_osdep_handle h,
                                             uint32_t dom, int prot,
                                             const xen_pfn_t *arr, int *err, unsigned int num)
@@ -220,21 +273,10 @@ static void *linux_privcmd_map_foreign_b
     /* Command was recognized, some gfn in arr are in paging state */
     if ( rc < 0 && errno == ENOENT )
     {
-        for ( i = rc = 0; rc == 0 && i < num; i++ )
-        {
-            if ( err[i] != -ENOENT )
-                continue;
-
-            ioctlx.num = 1;
-            ioctlx.dom = dom;
-            ioctlx.addr = (unsigned long)addr + ((unsigned long)i<<XC_PAGE_SHIFT);
-            ioctlx.arr = arr + i;
-            ioctlx.err = err + i;
-            do {
-                usleep(100);
-                rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
-            } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
-        }
+        do {
+            usleep(100);
+            rc = retry_paged(fd, dom, addr, arr, err, num);
+        } while ( rc > 0 );
     }
     /* Command was not recognized, use fall back */
     else if ( rc < 0 && errno == EINVAL && (int)num > 0 )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:51:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQfi-0008Er-Jp; Thu, 26 Jan 2012 14:51: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 1RqQfg-0008EI-LI
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:51:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327589481!3766748!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14010 invoked from network); 26 Jan 2012 14:51:21 -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;
	26 Jan 2012 14:51:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10307474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 14:51:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 14:51:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Thu, 26 Jan 2012 14:51:21 +0000
In-Reply-To: <4F2164CE.6070609@amd.com>
References: <4F2164CE.6070609@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327589481.26983.95.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] seabios build 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 Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
>    Building ld scripts (version "1.6.3.1-20120126_152501")
> env: python: No such file or directory
> gmake[6]: *** [out/romlayout16.lds] Error 127
> 
> 
> The python scripts must be invoked with $(PYTHON) as done
> throughout the build system.

SeaBIOS uses:
$ rgrep -i python tools/firmware/seabios-dir
tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install python-serial
tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python

Does this not work? Should python be on your $PATH?

Since SeaBIOS is third party code we are not so much at liberty to make
the same sorts of policy decisions as we would for our own code.

You could perhaps attempt to work around this by invoking the recursive
make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
whatever the appropriate runes are.

Or you could try posting a patch to SeaBIOS-devel, I don't know what
their thinking on this sort of thing is.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:51:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:51:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQfi-0008Er-Jp; Thu, 26 Jan 2012 14:51: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 1RqQfg-0008EI-LI
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:51:28 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327589481!3766748!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14010 invoked from network); 26 Jan 2012 14:51:21 -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;
	26 Jan 2012 14:51:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10307474"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 14:51:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 14:51:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Thu, 26 Jan 2012 14:51:21 +0000
In-Reply-To: <4F2164CE.6070609@amd.com>
References: <4F2164CE.6070609@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327589481.26983.95.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] seabios build 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 Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
>    Building ld scripts (version "1.6.3.1-20120126_152501")
> env: python: No such file or directory
> gmake[6]: *** [out/romlayout16.lds] Error 127
> 
> 
> The python scripts must be invoked with $(PYTHON) as done
> throughout the build system.

SeaBIOS uses:
$ rgrep -i python tools/firmware/seabios-dir
tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install python-serial
tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python

Does this not work? Should python be on your $PATH?

Since SeaBIOS is third party code we are not so much at liberty to make
the same sorts of policy decisions as we would for our own code.

You could perhaps attempt to work around this by invoking the recursive
make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
whatever the appropriate runes are.

Or you could try posting a patch to SeaBIOS-devel, I don't know what
their thinking on this sort of thing is.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:57:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:57:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQle-00006x-Dx; Thu, 26 Jan 2012 14:57: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 1RqQlc-00006p-UY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:57:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327589849!12683030!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1143 invoked from network); 26 Jan 2012 14:57:30 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 14:57:30 -0000
Received: by dajs34 with SMTP id s34so4068864daj.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 06:57:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=YtY/vCjDyQ8RLLes/2BftlPlUScKjxNntroMy9tMNWM=;
	b=snjLcyUtfgthShK0O38KhZWS156F+4aY0i3ZNqLaDTAZLhuthbNz6DQ7R6iFn9h/0B
	Q1Ta+PANQTcBjKId/TAlx7LlHNuqEL0nE2eZlelG7HO01lqebWQcRHeV53dmfrbrJKU3
	jlwx5Qnm9QaEhIts2lBr2KirU2k4nSZnVq/IM=
MIME-Version: 1.0
Received: by 10.68.238.229 with SMTP id vn5mr5816948pbc.39.1327589848555; Thu,
	26 Jan 2012 06:57:28 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Thu, 26 Jan 2012 06:57:28 -0800 (PST)
In-Reply-To: <CB45D658.382E7%keir@xen.org>
References: <1327506034.24561.332.camel@zakaz.uk.xensource.com>
	<CB45D658.382E7%keir@xen.org>
Date: Thu, 26 Jan 2012 15:57:28 +0100
X-Google-Sender-Auth: QZezN0Kb1DEN39bHextVEBGhDes
Message-ID: <CAPLaKK5yZ13ogh4sVN_Qkp=beYEaRwG06GQ+YBniJpKY7tJ2Aw@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 <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI1IEtlaXIgRnJhc2VyIDxrZWlyQHhlbi5vcmc+Ogo+IEkndmUgcmVtb3ZlZCB0aGVt
LgoKVGhhbmtzIQoKPiDCoC0tIEtlaXIKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:57:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14:57:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQle-00006x-Dx; Thu, 26 Jan 2012 14:57: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 1RqQlc-00006p-UY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:57:37 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327589849!12683030!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1143 invoked from network); 26 Jan 2012 14:57:30 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 14:57:30 -0000
Received: by dajs34 with SMTP id s34so4068864daj.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 06:57:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=YtY/vCjDyQ8RLLes/2BftlPlUScKjxNntroMy9tMNWM=;
	b=snjLcyUtfgthShK0O38KhZWS156F+4aY0i3ZNqLaDTAZLhuthbNz6DQ7R6iFn9h/0B
	Q1Ta+PANQTcBjKId/TAlx7LlHNuqEL0nE2eZlelG7HO01lqebWQcRHeV53dmfrbrJKU3
	jlwx5Qnm9QaEhIts2lBr2KirU2k4nSZnVq/IM=
MIME-Version: 1.0
Received: by 10.68.238.229 with SMTP id vn5mr5816948pbc.39.1327589848555; Thu,
	26 Jan 2012 06:57:28 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Thu, 26 Jan 2012 06:57:28 -0800 (PST)
In-Reply-To: <CB45D658.382E7%keir@xen.org>
References: <1327506034.24561.332.camel@zakaz.uk.xensource.com>
	<CB45D658.382E7%keir@xen.org>
Date: Thu, 26 Jan 2012 15:57:28 +0100
X-Google-Sender-Auth: QZezN0Kb1DEN39bHextVEBGhDes
Message-ID: <CAPLaKK5yZ13ogh4sVN_Qkp=beYEaRwG06GQ+YBniJpKY7tJ2Aw@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 <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI1IEtlaXIgRnJhc2VyIDxrZWlyQHhlbi5vcmc+Ogo+IEkndmUgcmVtb3ZlZCB0aGVt
LgoKVGhhbmtzIQoKPiDCoC0tIEtlaXIKPgo+CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0
cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Jan 26 14:58:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14: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 1RqQmZ-0000AW-SD; Thu, 26 Jan 2012 14:58:35 +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 1RqQmY-0000A0-Oo
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:58:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327589907!9954752!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17879 invoked from network); 26 Jan 2012 14:58:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 14:58:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179209319"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 09:58: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; Thu, 26 Jan 2012
	09:58:27 -0500
Message-ID: <4F216A12.80602@citrix.com>
Date: Thu, 26 Jan 2012 14:58:26 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>
In-Reply-To: <4F21743C020000780006F3AA@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] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/12 14:41, Jan Beulich wrote:
>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> XenServer by default boots without a serial console (buggy hardware
>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
>> writing to the vga text area looks ugly whilst dom0 is trying to set up
>> non-text mode and display  the splash screen.
>>
>> We have been using "console=" to prevent this behavior for a while, but
>> presented herewith is a patch to fix the problem correctly.
> While I don't mind the patch, I'm completely confused by the description:
> Where is it that Xen writes to VGA text area after control was passed to
> Dom0?
>
> Jan

I have not debugged it that much as I was looking for a clean solution
to our current hack of "console=" (and I have some rather more serious
deadlock bugs to debug), but it all Xen printk's are going into the VGA
text area, even after dom0 has started.  It is possible that Xen is
still writing into the text area after dom0 has switched VGA mode, but I
have no proof of this one way or the other.

-- 
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 Jan 26 14:58:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 14: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 1RqQmZ-0000AW-SD; Thu, 26 Jan 2012 14:58:35 +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 1RqQmY-0000A0-Oo
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 14:58:34 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327589907!9954752!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17879 invoked from network); 26 Jan 2012 14:58:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-12.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 14:58:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179209319"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 09:58: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; Thu, 26 Jan 2012
	09:58:27 -0500
Message-ID: <4F216A12.80602@citrix.com>
Date: Thu, 26 Jan 2012 14:58:26 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>
In-Reply-To: <4F21743C020000780006F3AA@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] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/12 14:41, Jan Beulich wrote:
>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> XenServer by default boots without a serial console (buggy hardware
>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
>> writing to the vga text area looks ugly whilst dom0 is trying to set up
>> non-text mode and display  the splash screen.
>>
>> We have been using "console=" to prevent this behavior for a while, but
>> presented herewith is a patch to fix the problem correctly.
> While I don't mind the patch, I'm completely confused by the description:
> Where is it that Xen writes to VGA text area after control was passed to
> Dom0?
>
> Jan

I have not debugged it that much as I was looking for a clean solution
to our current hack of "console=" (and I have some rather more serious
deadlock bugs to debug), but it all Xen printk's are going into the VGA
text area, even after dom0 has started.  It is possible that Xen is
still writing into the text area after dom0 has switched VGA mode, but I
have no proof of this one way or the other.

-- 
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 Jan 26 15:01:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQpN-0000OI-FH; Thu, 26 Jan 2012 15:01:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RqQpL-0000Nt-PD
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:01:27 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327590080!12580610!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28752 invoked from network); 26 Jan 2012 15:01:21 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-10.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Jan 2012 15:01:21 -0000
Received: from mail106-ch1-R.bigfish.com (10.43.68.241) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 15:01:16 +0000
Received: from mail106-ch1 (localhost [127.0.0.1])	by
	mail106-ch1-R.bigfish.com (Postfix) with ESMTP id E3E5B18011F;
	Thu, 26 Jan 2012 15:01:16 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h93fh)
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 mail106-ch1 (localhost.localdomain [127.0.0.1]) by mail106-ch1
	(MessageSwitch) id 1327590074991173_9282;
	Thu, 26 Jan 2012 15:01:14 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.245])	by mail106-ch1.bigfish.com (Postfix) with ESMTP id
	E62FCE0048;	Thu, 26 Jan 2012 15:01:14 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 15:01:13 +0000
X-WSS-ID: 0LYEV1Z-02-6HK-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 240F9C80DA;	Thu, 26 Jan 2012 09:01:11 -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, 26 Jan 2012 09:01:27 -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, 26 Jan 2012 09:01:12 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Jan 2012
	10:01:10 -0500
Message-ID: <4F216AB4.9020908@amd.com>
Date: Thu, 26 Jan 2012 16:01:08 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F2164CE.6070609@amd.com>
	<1327589481.26983.95.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327589481.26983.95.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] seabios build 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/26/12 15:51, Ian Campbell wrote:
> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
>>     Building ld scripts (version "1.6.3.1-20120126_152501")
>> env: python: No such file or directory
>> gmake[6]: *** [out/romlayout16.lds] Error 127
>>
>>
>> The python scripts must be invoked with $(PYTHON) as done
>> throughout the build system.
>
> SeaBIOS uses:
> $ rgrep -i python tools/firmware/seabios-dir
> tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install python-serial
> tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python
>
> Does this not work? Should python be on your $PATH?

It is. But the python binary on NetBSD's pkgsrc
is called python<version> to allow concurrent installations of different
python versions.
So I can have: python2.5, python2.6, python2.7, python3.1, etc.

Christoph

>
> Since SeaBIOS is third party code we are not so much at liberty to make
> the same sorts of policy decisions as we would for our own code.
>
> You could perhaps attempt to work around this by invoking the recursive
> make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
> whatever the appropriate runes are.
>
> Or you could try posting a patch to SeaBIOS-devel, I don't know what
> their thinking on this sort of thing is.
>
> 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 Thu Jan 26 15:01:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:01:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQpN-0000OI-FH; Thu, 26 Jan 2012 15:01:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RqQpL-0000Nt-PD
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:01:27 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327590080!12580610!1
X-Originating-IP: [216.32.181.182]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28752 invoked from network); 26 Jan 2012 15:01:21 -0000
Received: from ch1ehsobe002.messaging.microsoft.com (HELO
	ch1outboundpool.messaging.microsoft.com) (216.32.181.182)
	by server-10.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	26 Jan 2012 15:01:21 -0000
Received: from mail106-ch1-R.bigfish.com (10.43.68.241) by
	CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 15:01:16 +0000
Received: from mail106-ch1 (localhost [127.0.0.1])	by
	mail106-ch1-R.bigfish.com (Postfix) with ESMTP id E3E5B18011F;
	Thu, 26 Jan 2012 15:01:16 +0000 (UTC)
X-SpamScore: -13
X-BigFish: VPS-13(zzbb2dI936eK1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h93fh)
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 mail106-ch1 (localhost.localdomain [127.0.0.1]) by mail106-ch1
	(MessageSwitch) id 1327590074991173_9282;
	Thu, 26 Jan 2012 15:01:14 +0000 (UTC)
Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com
	[10.43.68.245])	by mail106-ch1.bigfish.com (Postfix) with ESMTP id
	E62FCE0048;	Thu, 26 Jan 2012 15:01:14 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server id
	14.1.225.23; Thu, 26 Jan 2012 15:01:13 +0000
X-WSS-ID: 0LYEV1Z-02-6HK-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 240F9C80DA;	Thu, 26 Jan 2012 09:01:11 -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, 26 Jan 2012 09:01:27 -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, 26 Jan 2012 09:01:12 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Thu, 26 Jan 2012
	10:01:10 -0500
Message-ID: <4F216AB4.9020908@amd.com>
Date: Thu, 26 Jan 2012 16:01:08 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F2164CE.6070609@amd.com>
	<1327589481.26983.95.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327589481.26983.95.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] seabios build 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/26/12 15:51, Ian Campbell wrote:
> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
>>     Building ld scripts (version "1.6.3.1-20120126_152501")
>> env: python: No such file or directory
>> gmake[6]: *** [out/romlayout16.lds] Error 127
>>
>>
>> The python scripts must be invoked with $(PYTHON) as done
>> throughout the build system.
>
> SeaBIOS uses:
> $ rgrep -i python tools/firmware/seabios-dir
> tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
> tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install python-serial
> tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python
>
> Does this not work? Should python be on your $PATH?

It is. But the python binary on NetBSD's pkgsrc
is called python<version> to allow concurrent installations of different
python versions.
So I can have: python2.5, python2.6, python2.7, python3.1, etc.

Christoph

>
> Since SeaBIOS is third party code we are not so much at liberty to make
> the same sorts of policy decisions as we would for our own code.
>
> You could perhaps attempt to work around this by invoking the recursive
> make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
> whatever the appropriate runes are.
>
> Or you could try posting a patch to SeaBIOS-devel, I don't know what
> their thinking on this sort of thing is.
>
> 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 Thu Jan 26 15:06:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQuQ-0000cc-An; Thu, 26 Jan 2012 15:06:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqQuO-0000cK-GV
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:06:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327590264!50181030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25843 invoked from network); 26 Jan 2012 15:04:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 15:04:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10308047"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 15:06: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, 26 Jan 2012 15:06:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Thu, 26 Jan 2012 15:06:33 +0000
In-Reply-To: <4F216AB4.9020908@amd.com>
References: <4F2164CE.6070609@amd.com>
	<1327589481.26983.95.camel@zakaz.uk.xensource.com>
	<4F216AB4.9020908@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327590393.26983.98.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] seabios build 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 Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
> On 01/26/12 15:51, Ian Campbell wrote:
> > On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
> >> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
> >>     Building ld scripts (version "1.6.3.1-20120126_152501")
> >> env: python: No such file or directory
> >> gmake[6]: *** [out/romlayout16.lds] Error 127
> >>
> >>
> >> The python scripts must be invoked with $(PYTHON) as done
> >> throughout the build system.
> >
> > SeaBIOS uses:
> > $ rgrep -i python tools/firmware/seabios-dir
> > tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install python-serial
> > tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python
> >
> > Does this not work? Should python be on your $PATH?
> 
> It is. But the python binary on NetBSD's pkgsrc
> is called python<version> to allow concurrent installations of different
> python versions.
> So I can have: python2.5, python2.6, python2.7, python3.1, etc.

There is no current "python" referring to the default version?

I think this is something you will need to work out with the SeaBIOS
upstream.

Ian.

> 
> Christoph
> 
> >
> > Since SeaBIOS is third party code we are not so much at liberty to make
> > the same sorts of policy decisions as we would for our own code.
> >
> > You could perhaps attempt to work around this by invoking the recursive
> > make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
> > whatever the appropriate runes are.
> >
> > Or you could try posting a patch to SeaBIOS-devel, I don't know what
> > their thinking on this sort of thing is.
> >
> > Ian.
> >
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 15:06:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqQuQ-0000cc-An; Thu, 26 Jan 2012 15:06:42 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqQuO-0000cK-GV
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:06:40 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327590264!50181030!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25843 invoked from network); 26 Jan 2012 15:04:24 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 15:04:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10308047"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 15:06: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, 26 Jan 2012 15:06:33 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Christoph Egger <Christoph.Egger@amd.com>
Date: Thu, 26 Jan 2012 15:06:33 +0000
In-Reply-To: <4F216AB4.9020908@amd.com>
References: <4F2164CE.6070609@amd.com>
	<1327589481.26983.95.camel@zakaz.uk.xensource.com>
	<4F216AB4.9020908@amd.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327590393.26983.98.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] seabios build 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 Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
> On 01/26/12 15:51, Ian Campbell wrote:
> > On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
> >> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
> >>     Building ld scripts (version "1.6.3.1-20120126_152501")
> >> env: python: No such file or directory
> >> gmake[6]: *** [out/romlayout16.lds] Error 127
> >>
> >>
> >> The python scripts must be invoked with $(PYTHON) as done
> >> throughout the build system.
> >
> > SeaBIOS uses:
> > $ rgrep -i python tools/firmware/seabios-dir
> > tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
> > tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install python-serial
> > tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python
> >
> > Does this not work? Should python be on your $PATH?
> 
> It is. But the python binary on NetBSD's pkgsrc
> is called python<version> to allow concurrent installations of different
> python versions.
> So I can have: python2.5, python2.6, python2.7, python3.1, etc.

There is no current "python" referring to the default version?

I think this is something you will need to work out with the SeaBIOS
upstream.

Ian.

> 
> Christoph
> 
> >
> > Since SeaBIOS is third party code we are not so much at liberty to make
> > the same sorts of policy decisions as we would for our own code.
> >
> > You could perhaps attempt to work around this by invoking the recursive
> > make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
> > whatever the appropriate runes are.
> >
> > Or you could try posting a patch to SeaBIOS-devel, I don't know what
> > their thinking on this sort of thing is.
> >
> > Ian.
> >
> >
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 15:36:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqRMt-0001iA-BQ; Thu, 26 Jan 2012 15:36:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RqRMr-0001hu-Cv
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:36:05 +0000
Received: from [85.158.138.51:34999] by server-8.bemta-3.messagelabs.com id
	31/2E-31878-4E2712F4; Thu, 26 Jan 2012 15:36:04 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327592162!10805144!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27603 invoked from network); 26 Jan 2012 15:36:03 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-5.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 15:36:03 -0000
Received: from [164.99.195.47] ([::ffff:164.99.195.47])
	by mail.novell.com with ESMTP; Thu, 26 Jan 2012 08:35:51 -0700
Message-ID: <4F21728A.5030408@suse.com>
Date: Thu, 26 Jan 2012 08:34:34 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>	<1327318778.24561.74.camel@zakaz.uk.xensource.com>	<201201231417.43018.tobias.geiger@vido.info>	<20120124015021.GB24204@andromeda.dapyr.net>	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>	<3758972BBA474BCBB9CA5D1D316892E7@nobody>	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>	<EE3AE950D047481283FF742510029D1E@nobody>	<1327510462.24561.351.camel@zakaz.uk.xensource.com>	<CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
	<alpine.DEB.2.00.1201261055360.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201261055360.3196@kaball-desktop>
Cc: Florian Heigl <florian.heigl@gmail.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	xen-users <xen-users@lists.xensource.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Likarpenkov Alexander <al@ohosting.org.ua>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Doug Magee <djmagee@mageenet.net>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 wrote:
> Considering that pv-usb, pv-scsi and netchannel2 are not upstream in
> Linux, the only feature that I believe people might miss is managed
> domains. However it should be pretty easy to script that feature on top
> of Xl and I believe that Debian might even be already doing something
> like that with xend.
>   

The libvirt libxl driver also provides managed domains, but it does not
yet have feature parity with the legacy xen driver.  Oh, and with all
the changes to the libxl public interface, it wont work with
xen-unstable.  I hope to spend some time on the driver soon, and always
looking for some help :-).

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 15:36:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqRMt-0001iA-BQ; Thu, 26 Jan 2012 15:36:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jfehlig@suse.com>) id 1RqRMr-0001hu-Cv
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:36:05 +0000
Received: from [85.158.138.51:34999] by server-8.bemta-3.messagelabs.com id
	31/2E-31878-4E2712F4; Thu, 26 Jan 2012 15:36:04 +0000
X-Env-Sender: jfehlig@suse.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327592162!10805144!1
X-Originating-IP: [137.65.248.97]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27603 invoked from network); 26 Jan 2012 15:36:03 -0000
Received: from novprvoes0314.provo.novell.com (HELO mail.novell.com)
	(137.65.248.97) by server-5.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 15:36:03 -0000
Received: from [164.99.195.47] ([::ffff:164.99.195.47])
	by mail.novell.com with ESMTP; Thu, 26 Jan 2012 08:35:51 -0700
Message-ID: <4F21728A.5030408@suse.com>
Date: Thu, 26 Jan 2012 08:34:34 -0700
From: Jim Fehlig <jfehlig@suse.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100302)
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>	<CAFoWEVOq70FuOA2cMQqKGyakiqXY8ZsWZu3wdw=dxj+7=-8N6w@mail.gmail.com>	<1327318778.24561.74.camel@zakaz.uk.xensource.com>	<201201231417.43018.tobias.geiger@vido.info>	<20120124015021.GB24204@andromeda.dapyr.net>	<EECC125FCE18E740AF561189E12602851451C6@mnetexch2.adamapps.host>	<3758972BBA474BCBB9CA5D1D316892E7@nobody>	<1327430498.7929.14.camel@mnetdjm5.mageenet.host>	<EE3AE950D047481283FF742510029D1E@nobody>	<1327510462.24561.351.camel@zakaz.uk.xensource.com>	<CAFivhPm4=LBT3rF=K-xw8CUJpSiW_Lx0YqQmZ0ORoQ_KxYtzzQ@mail.gmail.com>
	<alpine.DEB.2.00.1201261055360.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201261055360.3196@kaball-desktop>
Cc: Florian Heigl <florian.heigl@gmail.com>,
	xen-devel <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Sandi Romih <romihs.forums@gmail.com>,
	xen-users <xen-users@lists.xensource.com>,
	Tobias Geiger <tobias.geiger@vido.info>,
	Likarpenkov Alexander <al@ohosting.org.ua>,
	Konrad Rzeszutek Wilk <konrad@darnok.org>,
	Doug Magee <djmagee@mageenet.net>, chris <tknchris@gmail.com>
Subject: Re: [Xen-devel] [Xen-users] Future of xend and xl (Was: Re: VGA
 passthough still not working)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 wrote:
> Considering that pv-usb, pv-scsi and netchannel2 are not upstream in
> Linux, the only feature that I believe people might miss is managed
> domains. However it should be pretty easy to script that feature on top
> of Xl and I believe that Debian might even be already doing something
> like that with xend.
>   

The libvirt libxl driver also provides managed domains, but it does not
yet have feature parity with the legacy xen driver.  Oh, and with all
the changes to the libxl public interface, it wont work with
xen-unstable.  I hope to spend some time on the driver soon, and always
looking for some help :-).

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 15:45:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15: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 1RqRVt-00020D-I8; Thu, 26 Jan 2012 15:45:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqRVs-000208-Cp
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:45:24 +0000
Received: from [85.158.138.51:39796] by server-2.bemta-3.messagelabs.com id
	17/2D-24515-315712F4; Thu, 26 Jan 2012 15:45:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327592705!8941248!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3963 invoked from network); 26 Jan 2012 15:45:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 15:45:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqRVY-000LDE-9z; Thu, 26 Jan 2012 15:45:04 +0000
Date: Thu, 26 Jan 2012 15:45:04 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel <xen-devel@lists.xensource.com>
Message-ID: <20120126154504.GA80228@ocelot.phlegethon.org>
References: <20120119161626.GO66164@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120119161626.GO66164@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Subject: Re: [Xen-devel] RFC PATCH: bring OpenBSD stdarg in line with
	FreeBSD one
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:16 +0000 on 19 Jan (1326989786), Tim Deegan wrote:
> Having an absolute path in a #include confuses distcc's pump mode.
> Since AFAICS OpenBSD's stdarg handling uses the builtins, I think we
> should just treat it like we do NetBSD.
> 
> I don't have an OpenBSD box to test on, though. :(  Any OpenBSD
> enthusiasts care to comment?

No complaints, and the new header compiles on OpenBSD, so I've applied 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 Jan 26 15:45:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15: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 1RqRVt-00020D-I8; Thu, 26 Jan 2012 15:45:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqRVs-000208-Cp
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:45:24 +0000
Received: from [85.158.138.51:39796] by server-2.bemta-3.messagelabs.com id
	17/2D-24515-315712F4; Thu, 26 Jan 2012 15:45:23 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327592705!8941248!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3963 invoked from network); 26 Jan 2012 15:45:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 15:45:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqRVY-000LDE-9z; Thu, 26 Jan 2012 15:45:04 +0000
Date: Thu, 26 Jan 2012 15:45:04 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel <xen-devel@lists.xensource.com>
Message-ID: <20120126154504.GA80228@ocelot.phlegethon.org>
References: <20120119161626.GO66164@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120119161626.GO66164@ocelot.phlegethon.org>
User-Agent: Mutt/1.4.2.1i
Subject: Re: [Xen-devel] RFC PATCH: bring OpenBSD stdarg in line with
	FreeBSD one
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:16 +0000 on 19 Jan (1326989786), Tim Deegan wrote:
> Having an absolute path in a #include confuses distcc's pump mode.
> Since AFAICS OpenBSD's stdarg handling uses the builtins, I think we
> should just treat it like we do NetBSD.
> 
> I don't have an OpenBSD box to test on, though. :(  Any OpenBSD
> enthusiasts care to comment?

No complaints, and the new header compiles on OpenBSD, so I've applied 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 Jan 26 15:47:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15: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 1RqRXY-00025s-21; Thu, 26 Jan 2012 15:47:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqRXW-00025l-KB
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:47:06 +0000
Received: from [85.158.138.51:52316] by server-12.bemta-3.messagelabs.com id
	1A/0E-24557-975712F4; Thu, 26 Jan 2012 15:47:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327592824!10742658!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11414 invoked from network); 26 Jan 2012 15:47:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 15:47:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqRXU-000LDf-9m; Thu, 26 Jan 2012 15:47:04 +0000
Date: Thu, 26 Jan 2012 15:47:04 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120126154704.GB80228@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Subject: [Xen-devel] [PATCH] Get rid of non-static 'inline' modifiers (gcc
	4.2.1 complains)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1327592560 0
# Node ID dba361080715baf5ec2c493190bb69ba04cc633c
# Parent  a08043a997ea550e351ee87cd205f87562c67fcb
Get rid of non-static 'inline' modifiers (gcc 4.2.1 complains)

They seem to have been introduced by accident in 23311:f4585056b9ae
when some 'static inline' functions were moved out of a header

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r a08043a997ea -r dba361080715 xen/arch/x86/xstate.c
--- a/xen/arch/x86/xstate.c	Thu Jan 26 15:35:36 2012 +0000
+++ b/xen/arch/x86/xstate.c	Thu Jan 26 15:42:40 2012 +0000
@@ -40,13 +40,13 @@ static inline void xsetbv(u32 index, u64
             "a" (lo), "d" (hi));
 }
 
-inline void set_xcr0(u64 xfeatures)
+void set_xcr0(u64 xfeatures)
 {
     this_cpu(xcr0) = xfeatures;
     xsetbv(XCR_XFEATURE_ENABLED_MASK, xfeatures);
 }
 
-inline uint64_t get_xcr0(void)
+uint64_t get_xcr0(void)
 {
     return this_cpu(xcr0);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 15:47:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15: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 1RqRXY-00025s-21; Thu, 26 Jan 2012 15:47:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqRXW-00025l-KB
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:47:06 +0000
Received: from [85.158.138.51:52316] by server-12.bemta-3.messagelabs.com id
	1A/0E-24557-975712F4; Thu, 26 Jan 2012 15:47:05 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327592824!10742658!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11414 invoked from network); 26 Jan 2012 15:47:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 15:47:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqRXU-000LDf-9m; Thu, 26 Jan 2012 15:47:04 +0000
Date: Thu, 26 Jan 2012 15:47:04 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120126154704.GB80228@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Subject: [Xen-devel] [PATCH] Get rid of non-static 'inline' modifiers (gcc
	4.2.1 complains)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Tim Deegan <tim@xen.org>
# Date 1327592560 0
# Node ID dba361080715baf5ec2c493190bb69ba04cc633c
# Parent  a08043a997ea550e351ee87cd205f87562c67fcb
Get rid of non-static 'inline' modifiers (gcc 4.2.1 complains)

They seem to have been introduced by accident in 23311:f4585056b9ae
when some 'static inline' functions were moved out of a header

Signed-off-by: Tim Deegan <tim@xen.org>

diff -r a08043a997ea -r dba361080715 xen/arch/x86/xstate.c
--- a/xen/arch/x86/xstate.c	Thu Jan 26 15:35:36 2012 +0000
+++ b/xen/arch/x86/xstate.c	Thu Jan 26 15:42:40 2012 +0000
@@ -40,13 +40,13 @@ static inline void xsetbv(u32 index, u64
             "a" (lo), "d" (hi));
 }
 
-inline void set_xcr0(u64 xfeatures)
+void set_xcr0(u64 xfeatures)
 {
     this_cpu(xcr0) = xfeatures;
     xsetbv(XCR_XFEATURE_ENABLED_MASK, xfeatures);
 }
 
-inline uint64_t get_xcr0(void)
+uint64_t get_xcr0(void)
 {
     return this_cpu(xcr0);
 }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 15:48:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRZ0-0002Ml-6K; Thu, 26 Jan 2012 15:48:38 +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 1RqRYz-0002LM-8k
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:48:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327592910!12588777!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16243 invoked from network); 26 Jan 2012 15:48:30 -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;
	26 Jan 2012 15:48:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10309178"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 15:48: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; Thu, 26 Jan 2012 15:48:27 +0000
Date: Thu, 26 Jan 2012 15:49:16 +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.1201261536051.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 0/2] use pirq_eoi_map in modern Linux kernels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series consists of two patches: a patch for Xen and a
patch for Linux.

The Xen patch implements PHYSDEVOP_pirq_eoi_gmfn_new, a new hypercall
similar to PHYSDEVOP_pirq_eoi_gmfn but it does not change the semantics
of PHYSDEVOP_eoi.

The Linux patch introduces pirq_eoi_map in drivers/xen/events.c, using
PHYSDEVOP_pirq_eoi_gmfn_new.

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 Jan 26 15:48:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:48:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRZ0-0002Ml-6K; Thu, 26 Jan 2012 15:48:38 +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 1RqRYz-0002LM-8k
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:48:37 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327592910!12588777!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16243 invoked from network); 26 Jan 2012 15:48:30 -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;
	26 Jan 2012 15:48:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10309178"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 15:48: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; Thu, 26 Jan 2012 15:48:27 +0000
Date: Thu, 26 Jan 2012 15:49:16 +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.1201261536051.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH 0/2] use pirq_eoi_map in modern Linux kernels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series consists of two patches: a patch for Xen and a
patch for Linux.

The Xen patch implements PHYSDEVOP_pirq_eoi_gmfn_new, a new hypercall
similar to PHYSDEVOP_pirq_eoi_gmfn but it does not change the semantics
of PHYSDEVOP_eoi.

The Linux patch introduces pirq_eoi_map in drivers/xen/events.c, using
PHYSDEVOP_pirq_eoi_gmfn_new.

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 Jan 26 15:49:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15: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 1RqRZP-0002Ti-QD; Thu, 26 Jan 2012 15:49:03 +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 1RqRZN-0002SU-OC
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:49:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327592933!8878708!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21232 invoked from network); 26 Jan 2012 15:48:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 15:48:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21310751"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 10:48:52 -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, 26 Jan 2012 10:48: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 q0QFmhf3009566;
	Thu, 26 Jan 2012 07:48:44 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 15:49:46 +0000
Message-ID: <1327592987-20317-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.1201261536051.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261536051.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, JBeulich@suse.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/2] xen: Introduce PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
hypercall.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/xen/domain.c    |    1 +
 xen/arch/ia64/xen/hypercall.c |    5 ++++-
 xen/arch/x86/domain.c         |    1 +
 xen/arch/x86/physdev.c        |    6 +++++-
 xen/include/asm-ia64/domain.h |    3 +++
 xen/include/asm-x86/domain.h  |    3 +++
 xen/include/public/physdev.h  |    8 ++++++++
 7 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
index 1ea5a90..a31bd32 100644
--- a/xen/arch/ia64/xen/domain.c
+++ b/xen/arch/ia64/xen/domain.c
@@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
 		if (d->arch.pirq_eoi_map != NULL) {
 			put_page(virt_to_page(d->arch.pirq_eoi_map));
 			d->arch.pirq_eoi_map = NULL;
+			d->arch.auto_unmask = 0;
 		}
 
 		/* Tear down shadow mode stuff. */
diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
index 130675e..44c3407 100644
--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
 {
 	if ( pirq < 0 || pirq >= NR_IRQS )
 		return -EINVAL;
-	if ( d->arch.pirq_eoi_map ) {
+	if ( d->arch.pirq_eoi_map  && d->arch.auto_unmask ) {
 		spin_lock(&d->event_lock);
 		evtchn_unmask(pirq_to_evtchn(d, pirq));
 		spin_unlock(&d->event_lock);
@@ -508,6 +508,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case PHYSDEVOP_pirq_eoi_gmfn_new:
     case PHYSDEVOP_pirq_eoi_gmfn: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
@@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         }
 
         current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
+		if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
+			current->domain->arch.auto_unmask = 1;
         ret = 0;
         break;
     }
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 61d83c8..a540af7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
                 put_page_and_type(
                     mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
                 d->arch.pv_domain.pirq_eoi_map = NULL;
+                d->arch.pv_domain.auto_unmask = 0;
             }
         }
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index f280c28..efd517f 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             break;
         }
         if ( !is_hvm_domain(v->domain) &&
-             v->domain->arch.pv_domain.pirq_eoi_map )
+             v->domain->arch.pv_domain.pirq_eoi_map &&
+             v->domain->arch.pv_domain.auto_unmask )
             evtchn_unmask(pirq->evtchn);
         if ( !is_hvm_domain(v->domain) ||
              domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
@@ -293,6 +294,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case PHYSDEVOP_pirq_eoi_gmfn_new:
     case PHYSDEVOP_pirq_eoi_gmfn: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
@@ -329,6 +331,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             ret = -ENOSPC;
             break;
         }
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
+            v->domain->arch.pv_domain.auto_unmask = 1;
 
         put_gfn(current->domain, info.gmfn);
         ret = 0;
diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
index 12dc3bd..8163d67 100644
--- a/xen/include/asm-ia64/domain.h
+++ b/xen/include/asm-ia64/domain.h
@@ -186,6 +186,9 @@ struct arch_domain {
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+	/* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+	 * unmask the event channel */
+	unsigned int auto_unmask;
 
     /* Address of efi_runtime_services_t (placed in domain memory)  */
     void *efi_runtime;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 00bbaeb..b0cbe65 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -231,6 +231,9 @@ struct pv_domain
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    unsigned int auto_unmask;
 
     /* Pseudophysical e820 map (XENMEM_memory_map).  */
     spinlock_t e820_lock;
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index 6e23295..d555719 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -50,6 +50,14 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
  * array indexed by Xen's PIRQ value.
  */
 #define PHYSDEVOP_pirq_eoi_gmfn         17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_new         28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
     xen_pfn_t gmfn;
-- 
1.7.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 Jan 26 15:49:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15: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 1RqRZP-0002Ti-QD; Thu, 26 Jan 2012 15:49:03 +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 1RqRZN-0002SU-OC
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:49:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327592933!8878708!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21232 invoked from network); 26 Jan 2012 15:48:54 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-3.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 15:48:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21310751"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 10:48:52 -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, 26 Jan 2012 10:48: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 q0QFmhf3009566;
	Thu, 26 Jan 2012 07:48:44 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 15:49:46 +0000
Message-ID: <1327592987-20317-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.1201261536051.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261536051.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, JBeulich@suse.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 1/2] xen: Introduce PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
hypercall.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/xen/domain.c    |    1 +
 xen/arch/ia64/xen/hypercall.c |    5 ++++-
 xen/arch/x86/domain.c         |    1 +
 xen/arch/x86/physdev.c        |    6 +++++-
 xen/include/asm-ia64/domain.h |    3 +++
 xen/include/asm-x86/domain.h  |    3 +++
 xen/include/public/physdev.h  |    8 ++++++++
 7 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
index 1ea5a90..a31bd32 100644
--- a/xen/arch/ia64/xen/domain.c
+++ b/xen/arch/ia64/xen/domain.c
@@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
 		if (d->arch.pirq_eoi_map != NULL) {
 			put_page(virt_to_page(d->arch.pirq_eoi_map));
 			d->arch.pirq_eoi_map = NULL;
+			d->arch.auto_unmask = 0;
 		}
 
 		/* Tear down shadow mode stuff. */
diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
index 130675e..44c3407 100644
--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
 {
 	if ( pirq < 0 || pirq >= NR_IRQS )
 		return -EINVAL;
-	if ( d->arch.pirq_eoi_map ) {
+	if ( d->arch.pirq_eoi_map  && d->arch.auto_unmask ) {
 		spin_lock(&d->event_lock);
 		evtchn_unmask(pirq_to_evtchn(d, pirq));
 		spin_unlock(&d->event_lock);
@@ -508,6 +508,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case PHYSDEVOP_pirq_eoi_gmfn_new:
     case PHYSDEVOP_pirq_eoi_gmfn: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
@@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         }
 
         current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
+		if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
+			current->domain->arch.auto_unmask = 1;
         ret = 0;
         break;
     }
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 61d83c8..a540af7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
                 put_page_and_type(
                     mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
                 d->arch.pv_domain.pirq_eoi_map = NULL;
+                d->arch.pv_domain.auto_unmask = 0;
             }
         }
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index f280c28..efd517f 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             break;
         }
         if ( !is_hvm_domain(v->domain) &&
-             v->domain->arch.pv_domain.pirq_eoi_map )
+             v->domain->arch.pv_domain.pirq_eoi_map &&
+             v->domain->arch.pv_domain.auto_unmask )
             evtchn_unmask(pirq->evtchn);
         if ( !is_hvm_domain(v->domain) ||
              domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
@@ -293,6 +294,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
+    case PHYSDEVOP_pirq_eoi_gmfn_new:
     case PHYSDEVOP_pirq_eoi_gmfn: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
@@ -329,6 +331,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             ret = -ENOSPC;
             break;
         }
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
+            v->domain->arch.pv_domain.auto_unmask = 1;
 
         put_gfn(current->domain, info.gmfn);
         ret = 0;
diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
index 12dc3bd..8163d67 100644
--- a/xen/include/asm-ia64/domain.h
+++ b/xen/include/asm-ia64/domain.h
@@ -186,6 +186,9 @@ struct arch_domain {
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+	/* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+	 * unmask the event channel */
+	unsigned int auto_unmask;
 
     /* Address of efi_runtime_services_t (placed in domain memory)  */
     void *efi_runtime;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 00bbaeb..b0cbe65 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -231,6 +231,9 @@ struct pv_domain
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    unsigned int auto_unmask;
 
     /* Pseudophysical e820 map (XENMEM_memory_map).  */
     spinlock_t e820_lock;
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index 6e23295..d555719 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -50,6 +50,14 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
  * array indexed by Xen's PIRQ value.
  */
 #define PHYSDEVOP_pirq_eoi_gmfn         17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_new         28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
     xen_pfn_t gmfn;
-- 
1.7.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 Jan 26 15:49:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:49:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRZl-0002a1-8H; Thu, 26 Jan 2012 15:49: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 1RqRZj-0002X5-Lr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:49:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327592955!10098788!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4537 invoked from network); 26 Jan 2012 15:49:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 15:49:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179219856"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 10:48:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 10:48:58 -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 q0QFmhf4009566;
	Thu, 26 Jan 2012 07:48:47 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 15:49:47 +0000
Message-ID: <1327592987-20317-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.1201261536051.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261536051.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, JBeulich@suse.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/2] linux/xen: support pirq_eoi_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>
Content-Type: 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 pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
be EOI'd without having to issue an hypercall every time.
We use the new PHYSDEVOP_pirq_eoi_gmfn_new to map the bitmap, so that
Xen does not change the semantics of PHYSDEVOP_eoi behind our backs.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c            |   17 ++++++++++++++++-
 include/xen/interface/physdev.h |   22 ++++++++++++++++++++++
 2 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..2bca0b7 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -37,6 +37,7 @@
 #include <asm/idle.h>
 #include <asm/io_apic.h>
 #include <asm/sync_bitops.h>
+#include <asm/xen/page.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -108,6 +109,7 @@ struct irq_info {
 #define PIRQ_SHAREABLE	(1 << 1)
 
 static int *evtchn_to_irq;
+static unsigned long *pirq_eoi_map;
 
 static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
 		      cpu_evtchn_mask);
@@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
 
 	BUG_ON(info->type != IRQT_PIRQ);
 
+	if (pirq_eoi_map != NULL)
+		return test_bit(irq, pirq_eoi_map);
+
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
@@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
 
 void __init xen_init_IRQ(void)
 {
-	int i;
+	int i, rc;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		struct physdev_pirq_eoi_gmfn eoi_gmfn;
+
 		irq_ctx_init(smp_processor_id());
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
+
+		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_new, &eoi_gmfn);
+		if (rc != 0) {
+			free_page((unsigned long) pirq_eoi_map);
+			pirq_eoi_map = NULL;
+		}
 	}
 }
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index c1080d9..ba11907 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -39,6 +39,28 @@ struct physdev_eoi {
 };
 
 /*
+ * Register a shared page for the hypervisor to indicate whether the guest
+ * must issue PHYSDEVOP_eoi. The semantics of PHYSDEVOP_eoi change slightly
+ * once the guest used this function in that the associated event channel
+ * will automatically get unmasked. The page registered is used as a bit
+ * array indexed by Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn         17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_new         28
+struct physdev_pirq_eoi_gmfn {
+    /* IN */
+    unsigned long gmfn;
+};
+
+
+/*
  * Query the status of an IRQ line.
  * @arg == pointer to physdev_irq_status_query structure.
  */
-- 
1.7.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 Jan 26 15:49:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:49:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRZl-0002a1-8H; Thu, 26 Jan 2012 15:49: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 1RqRZj-0002X5-Lr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:49:23 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327592955!10098788!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4537 invoked from network); 26 Jan 2012 15:49:17 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 15:49:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179219856"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 10:48:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 10:48:58 -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 q0QFmhf4009566;
	Thu, 26 Jan 2012 07:48:47 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 15:49:47 +0000
Message-ID: <1327592987-20317-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.1201261536051.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261536051.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, JBeulich@suse.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH 2/2] linux/xen: support pirq_eoi_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>
Content-Type: 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 pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
be EOI'd without having to issue an hypercall every time.
We use the new PHYSDEVOP_pirq_eoi_gmfn_new to map the bitmap, so that
Xen does not change the semantics of PHYSDEVOP_eoi behind our backs.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c            |   17 ++++++++++++++++-
 include/xen/interface/physdev.h |   22 ++++++++++++++++++++++
 2 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..2bca0b7 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -37,6 +37,7 @@
 #include <asm/idle.h>
 #include <asm/io_apic.h>
 #include <asm/sync_bitops.h>
+#include <asm/xen/page.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -108,6 +109,7 @@ struct irq_info {
 #define PIRQ_SHAREABLE	(1 << 1)
 
 static int *evtchn_to_irq;
+static unsigned long *pirq_eoi_map;
 
 static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
 		      cpu_evtchn_mask);
@@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
 
 	BUG_ON(info->type != IRQT_PIRQ);
 
+	if (pirq_eoi_map != NULL)
+		return test_bit(irq, pirq_eoi_map);
+
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
@@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
 
 void __init xen_init_IRQ(void)
 {
-	int i;
+	int i, rc;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		struct physdev_pirq_eoi_gmfn eoi_gmfn;
+
 		irq_ctx_init(smp_processor_id());
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
+
+		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_new, &eoi_gmfn);
+		if (rc != 0) {
+			free_page((unsigned long) pirq_eoi_map);
+			pirq_eoi_map = NULL;
+		}
 	}
 }
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index c1080d9..ba11907 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -39,6 +39,28 @@ struct physdev_eoi {
 };
 
 /*
+ * Register a shared page for the hypervisor to indicate whether the guest
+ * must issue PHYSDEVOP_eoi. The semantics of PHYSDEVOP_eoi change slightly
+ * once the guest used this function in that the associated event channel
+ * will automatically get unmasked. The page registered is used as a bit
+ * array indexed by Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn         17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_new         28
+struct physdev_pirq_eoi_gmfn {
+    /* IN */
+    unsigned long gmfn;
+};
+
+
+/*
  * Query the status of an IRQ line.
  * @arg == pointer to physdev_irq_status_query structure.
  */
-- 
1.7.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 Jan 26 15:58:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRig-0003Lt-Bf; Thu, 26 Jan 2012 15:58:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqRie-0003Ln-FJ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:58:36 +0000
Received: from [85.158.138.51:10240] by server-4.bemta-3.messagelabs.com id
	AB/66-32238-B28712F4; Thu, 26 Jan 2012 15:58:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327593514!6582180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12129 invoked from network); 26 Jan 2012 15:58: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;
	26 Jan 2012 15:58:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10309503"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 15:58:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 15:58:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RqRic-00019F-26;
	Thu, 26 Jan 2012 15:58:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqRic-0003qk-0h;
	Thu, 26 Jan 2012 15:58:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11609-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 15:58:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11609: 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 11609 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11609/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  570d0ea0ad2f
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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-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.

(No revision log; it would be 437 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 Jan 26 15:58:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:58:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRig-0003Lt-Bf; Thu, 26 Jan 2012 15:58:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqRie-0003Ln-FJ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:58:36 +0000
Received: from [85.158.138.51:10240] by server-4.bemta-3.messagelabs.com id
	AB/66-32238-B28712F4; Thu, 26 Jan 2012 15:58:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327593514!6582180!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12129 invoked from network); 26 Jan 2012 15:58: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;
	26 Jan 2012 15:58:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10309503"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 15:58:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 15:58:34 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RqRic-00019F-26;
	Thu, 26 Jan 2012 15:58:34 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqRic-0003qk-0h;
	Thu, 26 Jan 2012 15:58:34 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11609-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 15:58:34 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11609: 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 11609 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11609/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  570d0ea0ad2f
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

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-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.

(No revision log; it would be 437 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 Jan 26 15:59:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:59:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRjB-0003O1-Pe; Thu, 26 Jan 2012 15:59:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqRjA-0003Nn-6k
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:59:08 +0000
Received: from [85.158.139.83:25030] by server-5.bemta-5.messagelabs.com id
	92/3E-12374-B48712F4; Thu, 26 Jan 2012 15:59:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327593546!12535991!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4922 invoked from network); 26 Jan 2012 15:59:06 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 15:59:06 -0000
Received: by wgbdt11 with SMTP id dt11so687048wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 07:59: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=6wD6JdHfwlMxbMGz8yfWWPD0YY3meJp7ibz69QjzHV0=;
	b=qqWHbzjMiFKKXp9vd8od0K4dDkfwypAL2KK1+DHw3nfQORSM/s65cuFUErC8Jz2w4X
	uTQFPoiBQL2++4zqYTMl97o77ALQcL9vyUjWGMhMPvQVsUGRoYDwxQwa11v2EzY4xgs/
	tHgHwdtX0zZ8dJ9Z+Z89kN1nNZsBHP5Y4/Ga0=
Received: by 10.180.96.230 with SMTP id dv6mr4549770wib.11.1327593546354;
	Thu, 26 Jan 2012 07:59:06 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q7sm6138928wix.5.2012.01.26.07.59.04
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 07:59:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 15:59:02 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB4728C6.29A7A%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Get rid of non-static 'inline' modifiers
	(gcc 4.2.1 complains)
Thread-Index: AczcQ2wDXj7k4hVgBUq4VSK/FAHdyA==
In-Reply-To: <20120126154704.GB80228@ocelot.phlegethon.org>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Get rid of non-static 'inline' modifiers
 (gcc 4.2.1 complains)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 15:47, "Tim Deegan" <tim@xen.org> wrote:

> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1327592560 0
> # Node ID dba361080715baf5ec2c493190bb69ba04cc633c
> # Parent  a08043a997ea550e351ee87cd205f87562c67fcb
> Get rid of non-static 'inline' modifiers (gcc 4.2.1 complains)
> 
> They seem to have been introduced by accident in 23311:f4585056b9ae
> when some 'static inline' functions were moved out of a header
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Keir Fraser <keir@xen.org>

> diff -r a08043a997ea -r dba361080715 xen/arch/x86/xstate.c
> --- a/xen/arch/x86/xstate.c Thu Jan 26 15:35:36 2012 +0000
> +++ b/xen/arch/x86/xstate.c Thu Jan 26 15:42:40 2012 +0000
> @@ -40,13 +40,13 @@ static inline void xsetbv(u32 index, u64
>              "a" (lo), "d" (hi));
>  }
>  
> -inline void set_xcr0(u64 xfeatures)
> +void set_xcr0(u64 xfeatures)
>  {
>      this_cpu(xcr0) = xfeatures;
>      xsetbv(XCR_XFEATURE_ENABLED_MASK, xfeatures);
>  }
>  
> -inline uint64_t get_xcr0(void)
> +uint64_t get_xcr0(void)
>  {
>      return this_cpu(xcr0);
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 26 15:59:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:59:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRjB-0003O1-Pe; Thu, 26 Jan 2012 15:59:09 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqRjA-0003Nn-6k
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:59:08 +0000
Received: from [85.158.139.83:25030] by server-5.bemta-5.messagelabs.com id
	92/3E-12374-B48712F4; Thu, 26 Jan 2012 15:59:07 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327593546!12535991!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4922 invoked from network); 26 Jan 2012 15:59:06 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 15:59:06 -0000
Received: by wgbdt11 with SMTP id dt11so687048wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 07:59: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=6wD6JdHfwlMxbMGz8yfWWPD0YY3meJp7ibz69QjzHV0=;
	b=qqWHbzjMiFKKXp9vd8od0K4dDkfwypAL2KK1+DHw3nfQORSM/s65cuFUErC8Jz2w4X
	uTQFPoiBQL2++4zqYTMl97o77ALQcL9vyUjWGMhMPvQVsUGRoYDwxQwa11v2EzY4xgs/
	tHgHwdtX0zZ8dJ9Z+Z89kN1nNZsBHP5Y4/Ga0=
Received: by 10.180.96.230 with SMTP id dv6mr4549770wib.11.1327593546354;
	Thu, 26 Jan 2012 07:59:06 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q7sm6138928wix.5.2012.01.26.07.59.04
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 07:59:05 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 15:59:02 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB4728C6.29A7A%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] Get rid of non-static 'inline' modifiers
	(gcc 4.2.1 complains)
Thread-Index: AczcQ2wDXj7k4hVgBUq4VSK/FAHdyA==
In-Reply-To: <20120126154704.GB80228@ocelot.phlegethon.org>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] Get rid of non-static 'inline' modifiers
 (gcc 4.2.1 complains)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 15:47, "Tim Deegan" <tim@xen.org> wrote:

> # HG changeset patch
> # User Tim Deegan <tim@xen.org>
> # Date 1327592560 0
> # Node ID dba361080715baf5ec2c493190bb69ba04cc633c
> # Parent  a08043a997ea550e351ee87cd205f87562c67fcb
> Get rid of non-static 'inline' modifiers (gcc 4.2.1 complains)
> 
> They seem to have been introduced by accident in 23311:f4585056b9ae
> when some 'static inline' functions were moved out of a header
> 
> Signed-off-by: Tim Deegan <tim@xen.org>

Acked-by: Keir Fraser <keir@xen.org>

> diff -r a08043a997ea -r dba361080715 xen/arch/x86/xstate.c
> --- a/xen/arch/x86/xstate.c Thu Jan 26 15:35:36 2012 +0000
> +++ b/xen/arch/x86/xstate.c Thu Jan 26 15:42:40 2012 +0000
> @@ -40,13 +40,13 @@ static inline void xsetbv(u32 index, u64
>              "a" (lo), "d" (hi));
>  }
>  
> -inline void set_xcr0(u64 xfeatures)
> +void set_xcr0(u64 xfeatures)
>  {
>      this_cpu(xcr0) = xfeatures;
>      xsetbv(XCR_XFEATURE_ENABLED_MASK, xfeatures);
>  }
>  
> -inline uint64_t get_xcr0(void)
> +uint64_t get_xcr0(void)
>  {
>      return this_cpu(xcr0);
>  }
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 26 15:59:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:59:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRjU-0003QL-6W; Thu, 26 Jan 2012 15:59:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RqRjR-0003PI-V2
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:59:26 +0000
Received: from [85.158.139.83:28339] by server-1.bemta-5.messagelabs.com id
	C7/2B-18433-D58712F4; Thu, 26 Jan 2012 15:59:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327593564!11973710!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 441 invoked from network); 26 Jan 2012 15:59:25 -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; 26 Jan 2012 15:59:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 15:59:24 +0000
Message-Id: <4F2186B4020000780006F429@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 16:00:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>
	<4F216A12.80602@citrix.com>
In-Reply-To: <4F216A12.80602@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 26/01/12 14:41, Jan Beulich wrote:
>>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> XenServer by default boots without a serial console (buggy hardware
>>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
>>> writing to the vga text area looks ugly whilst dom0 is trying to set up
>>> non-text mode and display  the splash screen.
>>>
>>> We have been using "console=" to prevent this behavior for a while, but
>>> presented herewith is a patch to fix the problem correctly.
>> While I don't mind the patch, I'm completely confused by the description:
>> Where is it that Xen writes to VGA text area after control was passed to
>> Dom0?
>>
>> Jan
> 
> I have not debugged it that much as I was looking for a clean solution
> to our current hack of "console=" (and I have some rather more serious
> deadlock bugs to debug), but it all Xen printk's are going into the VGA
> text area, even after dom0 has started.  It is possible that Xen is
> still writing into the text area after dom0 has switched VGA mode, but I
> have no proof of this one way or the other.

Just take a look at vga_endboot() - the output routine gets pointed to
vga_noop_puts() unless vgacon_keep. Beyond that point nothing
can possibly get printed to the VGA text screen, or if it does, then I'd
suspect there's some other change in XenServer that makes it so.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 15:59:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 15:59:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRjU-0003QL-6W; Thu, 26 Jan 2012 15:59:28 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RqRjR-0003PI-V2
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 15:59:26 +0000
Received: from [85.158.139.83:28339] by server-1.bemta-5.messagelabs.com id
	C7/2B-18433-D58712F4; Thu, 26 Jan 2012 15:59:25 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327593564!11973710!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 441 invoked from network); 26 Jan 2012 15:59:25 -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; 26 Jan 2012 15:59:25 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 15:59:24 +0000
Message-Id: <4F2186B4020000780006F429@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 16:00:36 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Andrew Cooper" <andrew.cooper3@citrix.com>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>
	<4F216A12.80602@citrix.com>
In-Reply-To: <4F216A12.80602@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 26/01/12 14:41, Jan Beulich wrote:
>>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>> XenServer by default boots without a serial console (buggy hardware
>>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
>>> writing to the vga text area looks ugly whilst dom0 is trying to set up
>>> non-text mode and display  the splash screen.
>>>
>>> We have been using "console=" to prevent this behavior for a while, but
>>> presented herewith is a patch to fix the problem correctly.
>> While I don't mind the patch, I'm completely confused by the description:
>> Where is it that Xen writes to VGA text area after control was passed to
>> Dom0?
>>
>> Jan
> 
> I have not debugged it that much as I was looking for a clean solution
> to our current hack of "console=" (and I have some rather more serious
> deadlock bugs to debug), but it all Xen printk's are going into the VGA
> text area, even after dom0 has started.  It is possible that Xen is
> still writing into the text area after dom0 has switched VGA mode, but I
> have no proof of this one way or the other.

Just take a look at vga_endboot() - the output routine gets pointed to
vga_noop_puts() unless vgacon_keep. Beyond that point nothing
can possibly get printed to the VGA text screen, or if it does, then I'd
suspect there's some other change in XenServer that makes it so.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:07:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRqk-0004I9-Df; Thu, 26 Jan 2012 16:06:58 +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 1RqRqj-0004I4-HY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:06:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327594011!12681719!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32414 invoked from network); 26 Jan 2012 16:06:51 -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; 26 Jan 2012 16:06:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqRqc-000LK4-L5; Thu, 26 Jan 2012 16:06:50 +0000
Date: Thu, 26 Jan 2012 16:06:50 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120126160650.GC80228@ocelot.phlegethon.org>
References: <osstest-11609-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-11609-mainreport@xen.org>
User-Agent: Mutt/1.4.2.1i
Subject: Re: [Xen-devel] [xen-unstable test] 11609: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:58 +0000 on 26 Jan (1327593514), xen. org wrote:
> flight 11609 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11609/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 11601
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
>  build-i386                    4 xen-build                 fail REGR. vs. 11601
> 

Should be fixed by 24589:266a12304601 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:07:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:07:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRqk-0004I9-Df; Thu, 26 Jan 2012 16:06:58 +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 1RqRqj-0004I4-HY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:06:57 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327594011!12681719!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32414 invoked from network); 26 Jan 2012 16:06:51 -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; 26 Jan 2012 16:06:51 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqRqc-000LK4-L5; Thu, 26 Jan 2012 16:06:50 +0000
Date: Thu, 26 Jan 2012 16:06:50 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120126160650.GC80228@ocelot.phlegethon.org>
References: <osstest-11609-mainreport@xen.org>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <osstest-11609-mainreport@xen.org>
User-Agent: Mutt/1.4.2.1i
Subject: Re: [Xen-devel] [xen-unstable test] 11609: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 15:58 +0000 on 26 Jan (1327593514), xen. org wrote:
> flight 11609 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11609/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 11601
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
>  build-i386                    4 xen-build                 fail REGR. vs. 11601
> 

Should be fixed by 24589:266a12304601 

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:08:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRrs-0004Ll-SI; Thu, 26 Jan 2012 16:08:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqRrr-0004LX-6x
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:08:07 +0000
Received: from [85.158.139.83:29086] by server-5.bemta-5.messagelabs.com id
	21/4E-12374-66A712F4; Thu, 26 Jan 2012 16:08:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327594085!12528823!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17558 invoked from network); 26 Jan 2012 16:08:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 16:08:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqRrk-000LKU-Nr; Thu, 26 Jan 2012 16:08:00 +0000
Date: Thu, 26 Jan 2012 16:08:00 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120126160800.GD80228@ocelot.phlegethon.org>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>
	<4F216A12.80602@citrix.com>
	<4F2186B4020000780006F429@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F2186B4020000780006F429@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:00 +0000 on 26 Jan (1327593636), Jan Beulich wrote:
> >>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 26/01/12 14:41, Jan Beulich wrote:
> >>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>> XenServer by default boots without a serial console (buggy hardware
> >>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
> >>> writing to the vga text area looks ugly whilst dom0 is trying to set up
> >>> non-text mode and display  the splash screen.
> >>>
> >>> We have been using "console=" to prevent this behavior for a while, but
> >>> presented herewith is a patch to fix the problem correctly.
> >> While I don't mind the patch, I'm completely confused by the description:
> >> Where is it that Xen writes to VGA text area after control was passed to
> >> Dom0?
> >>
> >> Jan
> > 
> > I have not debugged it that much as I was looking for a clean solution
> > to our current hack of "console=" (and I have some rather more serious
> > deadlock bugs to debug), but it all Xen printk's are going into the VGA
> > text area, even after dom0 has started.  It is possible that Xen is
> > still writing into the text area after dom0 has switched VGA mode, but I
> > have no proof of this one way or the other.
> 
> Just take a look at vga_endboot() - the output routine gets pointed to
> vga_noop_puts() unless vgacon_keep. Beyond that point nothing
> can possibly get printed to the VGA text screen, or if it does, then I'd
> suspect there's some other change in XenServer that makes it so.

IIRC in some XenServer versions the bootloader also puts up a
splashscreen; that may be causing some confusion.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:08:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:08:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRrs-0004Ll-SI; Thu, 26 Jan 2012 16:08:08 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqRrr-0004LX-6x
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:08:07 +0000
Received: from [85.158.139.83:29086] by server-5.bemta-5.messagelabs.com id
	21/4E-12374-66A712F4; Thu, 26 Jan 2012 16:08:06 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327594085!12528823!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17558 invoked from network); 26 Jan 2012 16:08:05 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-3.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 16:08:05 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqRrk-000LKU-Nr; Thu, 26 Jan 2012 16:08:00 +0000
Date: Thu, 26 Jan 2012 16:08:00 +0000
From: Tim Deegan <tim@xen.org>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120126160800.GD80228@ocelot.phlegethon.org>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>
	<4F216A12.80602@citrix.com>
	<4F2186B4020000780006F429@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F2186B4020000780006F429@nat28.tlf.novell.com>
User-Agent: Mutt/1.4.2.1i
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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:00 +0000 on 26 Jan (1327593636), Jan Beulich wrote:
> >>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 26/01/12 14:41, Jan Beulich wrote:
> >>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>> XenServer by default boots without a serial console (buggy hardware
> >>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
> >>> writing to the vga text area looks ugly whilst dom0 is trying to set up
> >>> non-text mode and display  the splash screen.
> >>>
> >>> We have been using "console=" to prevent this behavior for a while, but
> >>> presented herewith is a patch to fix the problem correctly.
> >> While I don't mind the patch, I'm completely confused by the description:
> >> Where is it that Xen writes to VGA text area after control was passed to
> >> Dom0?
> >>
> >> Jan
> > 
> > I have not debugged it that much as I was looking for a clean solution
> > to our current hack of "console=" (and I have some rather more serious
> > deadlock bugs to debug), but it all Xen printk's are going into the VGA
> > text area, even after dom0 has started.  It is possible that Xen is
> > still writing into the text area after dom0 has switched VGA mode, but I
> > have no proof of this one way or the other.
> 
> Just take a look at vga_endboot() - the output routine gets pointed to
> vga_noop_puts() unless vgacon_keep. Beyond that point nothing
> can possibly get printed to the VGA text screen, or if it does, then I'd
> suspect there's some other change in XenServer that makes it so.

IIRC in some XenServer versions the bootloader also puts up a
splashscreen; that may be causing some confusion.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:08:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:08:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRsL-0004OW-9p; Thu, 26 Jan 2012 16:08:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RqRsJ-0004OH-Ck
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:08:35 +0000
Received: from [85.158.139.83:31108] by server-8.bemta-5.messagelabs.com id
	34/CA-31172-28A712F4; Thu, 26 Jan 2012 16:08:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327594113!5091263!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19997 invoked from network); 26 Jan 2012 16:08:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 16:08:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 16:08:33 +0000
Message-Id: <4F2188D7020000780006F43B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 16:09:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201261536051.3196@kaball-desktop>
	<1327592987-20317-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327592987-20317-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 16:49, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
> Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
> PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
> hypercall.

I keep forgetting why you think the auto-unmasking does any harm.
It was done that way to avoid an extra hypercall.

> @@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>          }
>  
>          current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
> +		if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
> +			current->domain->arch.auto_unmask = 1;

Indentation.,

>          ret = 0;
>          break;
>      }
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>              break;
>          }
>          if ( !is_hvm_domain(v->domain) &&
> -             v->domain->arch.pv_domain.pirq_eoi_map )
> +             v->domain->arch.pv_domain.pirq_eoi_map &&
> +             v->domain->arch.pv_domain.auto_unmask )

Could you not avoid the checking of v->domain->arch.pv_domain.pirq_eoi_map
by making sure v->domain->arch.pv_domain.auto_unmask gets cleared
when the map gets destroyed (not sure if that is permitted at all).

>              evtchn_unmask(pirq->evtchn);
>          if ( !is_hvm_domain(v->domain) ||
>               domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -231,6 +231,9 @@ struct pv_domain
>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>      unsigned long *pirq_eoi_map;
>      unsigned long pirq_eoi_map_mfn;
> +    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
> +     * unmask the event channel */
> +    unsigned int auto_unmask;

bool_t?

Jan

>  
>      /* Pseudophysical e820 map (XENMEM_memory_map).  */
>      spinlock_t e820_lock;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:08:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:08:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRsL-0004OW-9p; Thu, 26 Jan 2012 16:08:37 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RqRsJ-0004OH-Ck
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:08:35 +0000
Received: from [85.158.139.83:31108] by server-8.bemta-5.messagelabs.com id
	34/CA-31172-28A712F4; Thu, 26 Jan 2012 16:08:34 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327594113!5091263!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19997 invoked from network); 26 Jan 2012 16:08:33 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 16:08:33 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 16:08:33 +0000
Message-Id: <4F2188D7020000780006F43B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 16:09:43 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201261536051.3196@kaball-desktop>
	<1327592987-20317-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327592987-20317-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: xen-devel@lists.xensource.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 16:49, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
> Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
> PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
> hypercall.

I keep forgetting why you think the auto-unmasking does any harm.
It was done that way to avoid an extra hypercall.

> @@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>          }
>  
>          current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
> +		if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
> +			current->domain->arch.auto_unmask = 1;

Indentation.,

>          ret = 0;
>          break;
>      }
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>              break;
>          }
>          if ( !is_hvm_domain(v->domain) &&
> -             v->domain->arch.pv_domain.pirq_eoi_map )
> +             v->domain->arch.pv_domain.pirq_eoi_map &&
> +             v->domain->arch.pv_domain.auto_unmask )

Could you not avoid the checking of v->domain->arch.pv_domain.pirq_eoi_map
by making sure v->domain->arch.pv_domain.auto_unmask gets cleared
when the map gets destroyed (not sure if that is permitted at all).

>              evtchn_unmask(pirq->evtchn);
>          if ( !is_hvm_domain(v->domain) ||
>               domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -231,6 +231,9 @@ struct pv_domain
>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>      unsigned long *pirq_eoi_map;
>      unsigned long pirq_eoi_map_mfn;
> +    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
> +     * unmask the event channel */
> +    unsigned int auto_unmask;

bool_t?

Jan

>  
>      /* Pseudophysical e820 map (XENMEM_memory_map).  */
>      spinlock_t e820_lock;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:09:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRst-0004T7-NB; Thu, 26 Jan 2012 16:09:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqRss-0004Sq-Lx
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:09:10 +0000
Received: from [85.158.139.83:35643] by server-12.bemta-5.messagelabs.com id
	6E/F7-18193-5AA712F4; Thu, 26 Jan 2012 16:09:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327594149!5190208!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27165 invoked from network); 26 Jan 2012 16:09:09 -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;
	26 Jan 2012 16:09:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10309865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:09:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 16:09:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 26 Jan 2012 16:09:08 +0000
In-Reply-To: <4F2186B4020000780006F429@nat28.tlf.novell.com>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>	<4F216A12.80602@citrix.com>
	<4F2186B4020000780006F429@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327594148.26983.101.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 16:00 +0000, Jan Beulich wrote:
> >>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 26/01/12 14:41, Jan Beulich wrote:
> >>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>> XenServer by default boots without a serial console (buggy hardware
> >>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
> >>> writing to the vga text area looks ugly whilst dom0 is trying to set up
> >>> non-text mode and display  the splash screen.
> >>>
> >>> We have been using "console=" to prevent this behavior for a while, but
> >>> presented herewith is a patch to fix the problem correctly.
> >> While I don't mind the patch, I'm completely confused by the description:
> >> Where is it that Xen writes to VGA text area after control was passed to
> >> Dom0?
> >>
> >> Jan
> > 
> > I have not debugged it that much as I was looking for a clean solution
> > to our current hack of "console=" (and I have some rather more serious
> > deadlock bugs to debug), but it all Xen printk's are going into the VGA
> > text area, even after dom0 has started.  It is possible that Xen is
> > still writing into the text area after dom0 has switched VGA mode, but I
> > have no proof of this one way or the other.
> 
> Just take a look at vga_endboot() - the output routine gets pointed to
> vga_noop_puts() unless vgacon_keep. Beyond that point nothing
> can possibly get printed to the VGA text screen, or if it does, then I'd
> suspect there's some other change in XenServer that makes it so.

IIRC the original purpose of this patch was to stop Xen from displaying
anything at all on the VGA, not just after dom0 handover but right from
start of day.

This was so that the splash screen (placed by the bootloader) didn't get
overwritten until dom0 comes up and takes over with the boot progress
meter thing.

Maybe that's changed in the meantime but that's my recollection.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:09:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:09:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqRst-0004T7-NB; Thu, 26 Jan 2012 16:09:11 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqRss-0004Sq-Lx
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:09:10 +0000
Received: from [85.158.139.83:35643] by server-12.bemta-5.messagelabs.com id
	6E/F7-18193-5AA712F4; Thu, 26 Jan 2012 16:09:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327594149!5190208!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27165 invoked from network); 26 Jan 2012 16:09:09 -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;
	26 Jan 2012 16:09:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10309865"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:09:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 16:09:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Date: Thu, 26 Jan 2012 16:09:08 +0000
In-Reply-To: <4F2186B4020000780006F429@nat28.tlf.novell.com>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>	<4F216A12.80602@citrix.com>
	<4F2186B4020000780006F429@nat28.tlf.novell.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327594148.26983.101.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 16:00 +0000, Jan Beulich wrote:
> >>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> > On 26/01/12 14:41, Jan Beulich wrote:
> >>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >>> XenServer by default boots without a serial console (buggy hardware
> >>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
> >>> writing to the vga text area looks ugly whilst dom0 is trying to set up
> >>> non-text mode and display  the splash screen.
> >>>
> >>> We have been using "console=" to prevent this behavior for a while, but
> >>> presented herewith is a patch to fix the problem correctly.
> >> While I don't mind the patch, I'm completely confused by the description:
> >> Where is it that Xen writes to VGA text area after control was passed to
> >> Dom0?
> >>
> >> Jan
> > 
> > I have not debugged it that much as I was looking for a clean solution
> > to our current hack of "console=" (and I have some rather more serious
> > deadlock bugs to debug), but it all Xen printk's are going into the VGA
> > text area, even after dom0 has started.  It is possible that Xen is
> > still writing into the text area after dom0 has switched VGA mode, but I
> > have no proof of this one way or the other.
> 
> Just take a look at vga_endboot() - the output routine gets pointed to
> vga_noop_puts() unless vgacon_keep. Beyond that point nothing
> can possibly get printed to the VGA text screen, or if it does, then I'd
> suspect there's some other change in XenServer that makes it so.

IIRC the original purpose of this patch was to stop Xen from displaying
anything at all on the VGA, not just after dom0 handover but right from
start of day.

This was so that the splash screen (placed by the bootloader) didn't get
overwritten until dom0 comes up and takes over with the boot progress
meter thing.

Maybe that's changed in the meantime but that's my recollection.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:11:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqRv0-0004iG-8l; Thu, 26 Jan 2012 16:11:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqRuy-0004i2-V0
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:11:21 +0000
Received: from [85.158.138.51:13951] by server-9.bemta-3.messagelabs.com id
	B1/BF-31168-82B712F4; Thu, 26 Jan 2012 16:11:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327594278!8945373!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 302 invoked from network); 26 Jan 2012 16:11:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:11:18 -0000
Received: by werb14 with SMTP id b14so1764452wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:11: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=oFBmH/zBAVvfKC+pFcDvIkayIynTraIvAk5b0d5DRLo=;
	b=vyeoxXvxElaINl5ho7PWiu4+Af4OCdGRsP/Wip3i7U6I64kfgTok13RRA2stlm1uA5
	JWKlkHUK3Vy61bkLPwkn9UR5ZS6blfryFilQZQNikKwNnCzgh9wMlRBWFiSl7BWFmvcB
	MS7Ydh42ggrE5/+kpe7qL6A4511iSVe8Ig7tc=
Received: by 10.180.87.8 with SMTP id t8mr5325797wiz.15.1327594277956;
	Thu, 26 Jan 2012 08:11:17 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id m8sm13921581wia.11.2012.01.26.08.11.16
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 08:11:17 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 16:11:08 +0000
From: Keir Fraser <keir@xen.org>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB472B9C.38573%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
Thread-Index: AczcRRy+q/MAago7IE6d2nUJ4nR9xQ==
In-Reply-To: <1327592987-20317-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-version: 1.0
Cc: JBeulich@suse.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 15:49, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
wrote:

> PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
> Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
> PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
> hypercall.

It's nasty that pirq_eoi_gmfn has the side effect. I suggest add a PHYSDEVOP
to explicitly enable/disable unmask-on-eoi (i.e., the command accepts a
boolean parameter). Once it is explicitly enabled/disabled in this way,
pirq_eoi_gmfn no longer has the side effect (regardless of whether it is
called before or after the explicit setting). So e.g., pv_domain.auto_unmask
becomes an int where 0/1 means no/yes, and -1 means default (i.e., old
behavour where it depends on whether PHYSDEVOP_pirq_eoi_gmfn has been
called).

This seems to me to move a bad interface in a better direction.

 -- Keir

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/ia64/xen/domain.c    |    1 +
>  xen/arch/ia64/xen/hypercall.c |    5 ++++-
>  xen/arch/x86/domain.c         |    1 +
>  xen/arch/x86/physdev.c        |    6 +++++-
>  xen/include/asm-ia64/domain.h |    3 +++
>  xen/include/asm-x86/domain.h  |    3 +++
>  xen/include/public/physdev.h  |    8 ++++++++
>  7 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
> index 1ea5a90..a31bd32 100644
> --- a/xen/arch/ia64/xen/domain.c
> +++ b/xen/arch/ia64/xen/domain.c
> @@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
> if (d->arch.pirq_eoi_map != NULL) {
> put_page(virt_to_page(d->arch.pirq_eoi_map));
> d->arch.pirq_eoi_map = NULL;
> +   d->arch.auto_unmask = 0;
> }
>  
> /* Tear down shadow mode stuff. */
> diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
> index 130675e..44c3407 100644
> --- a/xen/arch/ia64/xen/hypercall.c
> +++ b/xen/arch/ia64/xen/hypercall.c
> @@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
>  {
> if ( pirq < 0 || pirq >= NR_IRQS )
> return -EINVAL;
> - if ( d->arch.pirq_eoi_map ) {
> + if ( d->arch.pirq_eoi_map  && d->arch.auto_unmask ) {
> spin_lock(&d->event_lock);
> evtchn_unmask(pirq_to_evtchn(d, pirq));
> spin_unlock(&d->event_lock);
> @@ -508,6 +508,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case PHYSDEVOP_pirq_eoi_gmfn_new:
>      case PHYSDEVOP_pirq_eoi_gmfn: {
>          struct physdev_pirq_eoi_gmfn info;
>          unsigned long mfn;
> @@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>          }
>  
>          current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
> +  if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
> +   current->domain->arch.auto_unmask = 1;
>          ret = 0;
>          break;
>      }
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 61d83c8..a540af7 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
>                  put_page_and_type(
>                      mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
>                  d->arch.pv_domain.pirq_eoi_map = NULL;
> +                d->arch.pv_domain.auto_unmask = 0;
>              }
>          }
>  
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index f280c28..efd517f 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>              break;
>          }
>          if ( !is_hvm_domain(v->domain) &&
> -             v->domain->arch.pv_domain.pirq_eoi_map )
> +             v->domain->arch.pv_domain.pirq_eoi_map &&
> +             v->domain->arch.pv_domain.auto_unmask )
>              evtchn_unmask(pirq->evtchn);
>          if ( !is_hvm_domain(v->domain) ||
>               domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
> @@ -293,6 +294,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case PHYSDEVOP_pirq_eoi_gmfn_new:
>      case PHYSDEVOP_pirq_eoi_gmfn: {
>          struct physdev_pirq_eoi_gmfn info;
>          unsigned long mfn;
> @@ -329,6 +331,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>              ret = -ENOSPC;
>              break;
>          }
> +        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
> +            v->domain->arch.pv_domain.auto_unmask = 1;
>  
>          put_gfn(current->domain, info.gmfn);
>          ret = 0;
> diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
> index 12dc3bd..8163d67 100644
> --- a/xen/include/asm-ia64/domain.h
> +++ b/xen/include/asm-ia64/domain.h
> @@ -186,6 +186,9 @@ struct arch_domain {
>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>      unsigned long *pirq_eoi_map;
>      unsigned long pirq_eoi_map_mfn;
> + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
> +  * unmask the event channel */
> + unsigned int auto_unmask;
>  
>      /* Address of efi_runtime_services_t (placed in domain memory)  */
>      void *efi_runtime;
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 00bbaeb..b0cbe65 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -231,6 +231,9 @@ struct pv_domain
>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>      unsigned long *pirq_eoi_map;
>      unsigned long pirq_eoi_map_mfn;
> +    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
> +     * unmask the event channel */
> +    unsigned int auto_unmask;
>  
>      /* Pseudophysical e820 map (XENMEM_memory_map).  */
>      spinlock_t e820_lock;
> diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
> index 6e23295..d555719 100644
> --- a/xen/include/public/physdev.h
> +++ b/xen/include/public/physdev.h
> @@ -50,6 +50,14 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
>   * array indexed by Xen's PIRQ value.
>   */
>  #define PHYSDEVOP_pirq_eoi_gmfn         17
> +/*
> + * Register a shared page for the hypervisor to indicate whether the
> + * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
> + * PHYSDEVOP_pirq_eoi_gmfn but it doesn't change the semantics of
> + * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
> + * Xen's PIRQ value.
> + */
> +#define PHYSDEVOP_pirq_eoi_gmfn_new         28
>  struct physdev_pirq_eoi_gmfn {
>      /* IN */
>      xen_pfn_t gmfn;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:11:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqRv0-0004iG-8l; Thu, 26 Jan 2012 16:11:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqRuy-0004i2-V0
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:11:21 +0000
Received: from [85.158.138.51:13951] by server-9.bemta-3.messagelabs.com id
	B1/BF-31168-82B712F4; Thu, 26 Jan 2012 16:11:20 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327594278!8945373!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 302 invoked from network); 26 Jan 2012 16:11:18 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:11:18 -0000
Received: by werb14 with SMTP id b14so1764452wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:11: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=oFBmH/zBAVvfKC+pFcDvIkayIynTraIvAk5b0d5DRLo=;
	b=vyeoxXvxElaINl5ho7PWiu4+Af4OCdGRsP/Wip3i7U6I64kfgTok13RRA2stlm1uA5
	JWKlkHUK3Vy61bkLPwkn9UR5ZS6blfryFilQZQNikKwNnCzgh9wMlRBWFiSl7BWFmvcB
	MS7Ydh42ggrE5/+kpe7qL6A4511iSVe8Ig7tc=
Received: by 10.180.87.8 with SMTP id t8mr5325797wiz.15.1327594277956;
	Thu, 26 Jan 2012 08:11:17 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id m8sm13921581wia.11.2012.01.26.08.11.16
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 08:11:17 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 16:11:08 +0000
From: Keir Fraser <keir@xen.org>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB472B9C.38573%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
Thread-Index: AczcRRy+q/MAago7IE6d2nUJ4nR9xQ==
In-Reply-To: <1327592987-20317-1-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-version: 1.0
Cc: JBeulich@suse.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 15:49, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
wrote:

> PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
> Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
> PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
> hypercall.

It's nasty that pirq_eoi_gmfn has the side effect. I suggest add a PHYSDEVOP
to explicitly enable/disable unmask-on-eoi (i.e., the command accepts a
boolean parameter). Once it is explicitly enabled/disabled in this way,
pirq_eoi_gmfn no longer has the side effect (regardless of whether it is
called before or after the explicit setting). So e.g., pv_domain.auto_unmask
becomes an int where 0/1 means no/yes, and -1 means default (i.e., old
behavour where it depends on whether PHYSDEVOP_pirq_eoi_gmfn has been
called).

This seems to me to move a bad interface in a better direction.

 -- Keir

> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  xen/arch/ia64/xen/domain.c    |    1 +
>  xen/arch/ia64/xen/hypercall.c |    5 ++++-
>  xen/arch/x86/domain.c         |    1 +
>  xen/arch/x86/physdev.c        |    6 +++++-
>  xen/include/asm-ia64/domain.h |    3 +++
>  xen/include/asm-x86/domain.h  |    3 +++
>  xen/include/public/physdev.h  |    8 ++++++++
>  7 files changed, 25 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
> index 1ea5a90..a31bd32 100644
> --- a/xen/arch/ia64/xen/domain.c
> +++ b/xen/arch/ia64/xen/domain.c
> @@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
> if (d->arch.pirq_eoi_map != NULL) {
> put_page(virt_to_page(d->arch.pirq_eoi_map));
> d->arch.pirq_eoi_map = NULL;
> +   d->arch.auto_unmask = 0;
> }
>  
> /* Tear down shadow mode stuff. */
> diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
> index 130675e..44c3407 100644
> --- a/xen/arch/ia64/xen/hypercall.c
> +++ b/xen/arch/ia64/xen/hypercall.c
> @@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
>  {
> if ( pirq < 0 || pirq >= NR_IRQS )
> return -EINVAL;
> - if ( d->arch.pirq_eoi_map ) {
> + if ( d->arch.pirq_eoi_map  && d->arch.auto_unmask ) {
> spin_lock(&d->event_lock);
> evtchn_unmask(pirq_to_evtchn(d, pirq));
> spin_unlock(&d->event_lock);
> @@ -508,6 +508,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case PHYSDEVOP_pirq_eoi_gmfn_new:
>      case PHYSDEVOP_pirq_eoi_gmfn: {
>          struct physdev_pirq_eoi_gmfn info;
>          unsigned long mfn;
> @@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>          }
>  
>          current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
> +  if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
> +   current->domain->arch.auto_unmask = 1;
>          ret = 0;
>          break;
>      }
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 61d83c8..a540af7 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
>                  put_page_and_type(
>                      mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
>                  d->arch.pv_domain.pirq_eoi_map = NULL;
> +                d->arch.pv_domain.auto_unmask = 0;
>              }
>          }
>  
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index f280c28..efd517f 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>              break;
>          }
>          if ( !is_hvm_domain(v->domain) &&
> -             v->domain->arch.pv_domain.pirq_eoi_map )
> +             v->domain->arch.pv_domain.pirq_eoi_map &&
> +             v->domain->arch.pv_domain.auto_unmask )
>              evtchn_unmask(pirq->evtchn);
>          if ( !is_hvm_domain(v->domain) ||
>               domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
> @@ -293,6 +294,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>          break;
>      }
>  
> +    case PHYSDEVOP_pirq_eoi_gmfn_new:
>      case PHYSDEVOP_pirq_eoi_gmfn: {
>          struct physdev_pirq_eoi_gmfn info;
>          unsigned long mfn;
> @@ -329,6 +331,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>              ret = -ENOSPC;
>              break;
>          }
> +        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
> +            v->domain->arch.pv_domain.auto_unmask = 1;
>  
>          put_gfn(current->domain, info.gmfn);
>          ret = 0;
> diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
> index 12dc3bd..8163d67 100644
> --- a/xen/include/asm-ia64/domain.h
> +++ b/xen/include/asm-ia64/domain.h
> @@ -186,6 +186,9 @@ struct arch_domain {
>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>      unsigned long *pirq_eoi_map;
>      unsigned long pirq_eoi_map_mfn;
> + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
> +  * unmask the event channel */
> + unsigned int auto_unmask;
>  
>      /* Address of efi_runtime_services_t (placed in domain memory)  */
>      void *efi_runtime;
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 00bbaeb..b0cbe65 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -231,6 +231,9 @@ struct pv_domain
>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>      unsigned long *pirq_eoi_map;
>      unsigned long pirq_eoi_map_mfn;
> +    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
> +     * unmask the event channel */
> +    unsigned int auto_unmask;
>  
>      /* Pseudophysical e820 map (XENMEM_memory_map).  */
>      spinlock_t e820_lock;
> diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
> index 6e23295..d555719 100644
> --- a/xen/include/public/physdev.h
> +++ b/xen/include/public/physdev.h
> @@ -50,6 +50,14 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
>   * array indexed by Xen's PIRQ value.
>   */
>  #define PHYSDEVOP_pirq_eoi_gmfn         17
> +/*
> + * Register a shared page for the hypervisor to indicate whether the
> + * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
> + * PHYSDEVOP_pirq_eoi_gmfn but it doesn't change the semantics of
> + * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
> + * Xen's PIRQ value.
> + */
> +#define PHYSDEVOP_pirq_eoi_gmfn_new         28
>  struct physdev_pirq_eoi_gmfn {
>      /* IN */
>      xen_pfn_t gmfn;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqRx8-0004w8-SL; Thu, 26 Jan 2012 16:13: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 1RqRx6-0004vu-UA
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:13:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327594370!57587574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6256 invoked from network); 26 Jan 2012 16:12:50 -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;
	26 Jan 2012 16:12:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10310012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:13:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 16:13:31 +0000
Date: Thu, 26 Jan 2012 16:14:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F2188D7020000780006F43B@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201261610510.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261536051.3196@kaball-desktop>
	<1327592987-20317-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F2188D7020000780006F43B@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>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Jan Beulich wrote:
> >>> On 26.01.12 at 16:49, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
> > Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
> > PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
> > hypercall.
> 
> I keep forgetting why you think the auto-unmasking does any harm.
> It was done that way to avoid an extra hypercall.

We let Linux mask/unmask the event channel whenever it would make/unmask
the irq, so an automatic unmask is equivalent to unmasking an irq
without Linux knowing or wanting to do so.


> > @@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
> >          }
> >  
> >          current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
> > +		if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
> > +			current->domain->arch.auto_unmask = 1;
> 
> Indentation.,
>
> >          ret = 0;
> >          break;
> >      }
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
> >              break;
> >          }
> >          if ( !is_hvm_domain(v->domain) &&
> > -             v->domain->arch.pv_domain.pirq_eoi_map )
> > +             v->domain->arch.pv_domain.pirq_eoi_map &&
> > +             v->domain->arch.pv_domain.auto_unmask )
> 
> Could you not avoid the checking of v->domain->arch.pv_domain.pirq_eoi_map
> by making sure v->domain->arch.pv_domain.auto_unmask gets cleared
> when the map gets destroyed (not sure if that is permitted at all).

I think I can, I'll change it that way.


> >              evtchn_unmask(pirq->evtchn);
> >          if ( !is_hvm_domain(v->domain) ||
> >               domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
> > --- a/xen/include/asm-x86/domain.h
> > +++ b/xen/include/asm-x86/domain.h
> > @@ -231,6 +231,9 @@ struct pv_domain
> >      /* Shared page for notifying that explicit PIRQ EOI is required. */
> >      unsigned long *pirq_eoi_map;
> >      unsigned long pirq_eoi_map_mfn;
> > +    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
> > +     * unmask the event channel */
> > +    unsigned int auto_unmask;
> 
> bool_t?

good idea


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqRx8-0004w8-SL; Thu, 26 Jan 2012 16:13: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 1RqRx6-0004vu-UA
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:13:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327594370!57587574!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6256 invoked from network); 26 Jan 2012 16:12:50 -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;
	26 Jan 2012 16:12:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10310012"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:13:31 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 16:13:31 +0000
Date: Thu, 26 Jan 2012 16:14:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F2188D7020000780006F43B@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201261610510.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261536051.3196@kaball-desktop>
	<1327592987-20317-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F2188D7020000780006F43B@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>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Jan Beulich wrote:
> >>> On 26.01.12 at 16:49, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
> > Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
> > PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
> > hypercall.
> 
> I keep forgetting why you think the auto-unmasking does any harm.
> It was done that way to avoid an extra hypercall.

We let Linux mask/unmask the event channel whenever it would make/unmask
the irq, so an automatic unmask is equivalent to unmasking an irq
without Linux knowing or wanting to do so.


> > @@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
> >          }
> >  
> >          current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
> > +		if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
> > +			current->domain->arch.auto_unmask = 1;
> 
> Indentation.,
>
> >          ret = 0;
> >          break;
> >      }
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
> >              break;
> >          }
> >          if ( !is_hvm_domain(v->domain) &&
> > -             v->domain->arch.pv_domain.pirq_eoi_map )
> > +             v->domain->arch.pv_domain.pirq_eoi_map &&
> > +             v->domain->arch.pv_domain.auto_unmask )
> 
> Could you not avoid the checking of v->domain->arch.pv_domain.pirq_eoi_map
> by making sure v->domain->arch.pv_domain.auto_unmask gets cleared
> when the map gets destroyed (not sure if that is permitted at all).

I think I can, I'll change it that way.


> >              evtchn_unmask(pirq->evtchn);
> >          if ( !is_hvm_domain(v->domain) ||
> >               domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
> > --- a/xen/include/asm-x86/domain.h
> > +++ b/xen/include/asm-x86/domain.h
> > @@ -231,6 +231,9 @@ struct pv_domain
> >      /* Shared page for notifying that explicit PIRQ EOI is required. */
> >      unsigned long *pirq_eoi_map;
> >      unsigned long pirq_eoi_map_mfn;
> > +    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
> > +     * unmask the event channel */
> > +    unsigned int auto_unmask;
> 
> bool_t?

good idea


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:20:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqS3M-0005SP-Nu; Thu, 26 Jan 2012 16:20:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqS3K-0005SH-Do
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:19:59 +0000
Received: from [85.158.139.83:31989] by server-4.bemta-5.messagelabs.com id
	0B/04-09697-D2D712F4; Thu, 26 Jan 2012 16:19:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327594796!12519245!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTk3Nzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16145 invoked from network); 26 Jan 2012 16:19:56 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-2.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 16:19:56 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id DA0FB30008D;
	Thu, 26 Jan 2012 08:19: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=vpczBwV0AAaJGq3MZfpVgjUo50LzhnGRRByWNNJiM4Vg
	ok2jDNMhlEM1WEy13373OrxwkdRL3PIe5Dl2LDHt6fAMhgEo0v6oYMz/o/COLwpI
	YiK59jCO3JU+bI3vCCmON+k9Z6JB70SOOUkoo6/hRWDTa0UvFMBO19Evfxoa2PY=
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=IZytg1CNjhz1RnLpEHOMzR/4cpU=; b=JCXuZeWG
	fkRq+X+KElOWbwZqYDrSl3mYUXipMogzEATtc4BUcD4tRa/r1adSD9jcFd+5/C6v
	k5lc/WthnziSZaXN9d07wlkuFo3VGd7G8IL6z2JmzwYBSgbdnGc7JxuOddRMki3z
	LULNZZZm/yMinhtjWojfa5Bxzi79l4nMePk=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 6E1A130007B; 
	Thu, 26 Jan 2012 08:19: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, 26 Jan 2012 08:19:55 -0800
Message-ID: <b288b972af18d0e1607ff99bd6848834.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1637.1327585244.1471.xen-devel@lists.xensource.com>
References: <mailman.1637.1327585244.1471.xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 08:19:55 -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] tools/libxc: handle fallback in
 linux_privcmd_map_foreign_bulk properly
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, 26 Jan 2012 14:36:30 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] tools/libxc: handle fallback in
> 	linux_privcmd_map_foreign_bulk properly
> Message-ID: <aa0d678fece208975984.1327584990@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327584962 -3600
> # Node ID aa0d678fece208975984e8e59ca223c07fc50c06
> # Parent  89fdabcf315fdaabeebf05c51a6b3b6dd4c20e85
> tools/libxc: handle fallback in linux_privcmd_map_foreign_bulk properly
>
> If the first ioctl fails with ENOENT it means the command is known. If a
> second attempt to map each gfn happens to fail then there is no need to
> run the fallback code. Some gfns are paged and the fallback code would
> not fix the failure. Instead return the EINVAL to the caller.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks,
Andres
>
> diff -r 89fdabcf315f -r aa0d678fece2 tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -217,6 +217,7 @@ static void *linux_privcmd_map_foreign_b
>
>      rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
>
> +    /* Command was recognized, some gfn in arr are in paging state */
>      if ( rc < 0 && errno == ENOENT )
>      {
>          for ( i = rc = 0; rc == 0 && i < num; i++ )
> @@ -235,8 +236,8 @@ static void *linux_privcmd_map_foreign_b
>              } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
>          }
>      }
> -
> -    if ( rc < 0 && errno == EINVAL && (int)num > 0 )
> +    /* Command was not recognized, use fall back */
> +    else if ( rc < 0 && errno == EINVAL && (int)num > 0 )
>      {
>          /*
>           * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:20:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:20:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqS3M-0005SP-Nu; Thu, 26 Jan 2012 16:20:00 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqS3K-0005SH-Do
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:19:59 +0000
Received: from [85.158.139.83:31989] by server-4.bemta-5.messagelabs.com id
	0B/04-09697-D2D712F4; Thu, 26 Jan 2012 16:19:57 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327594796!12519245!1
X-Originating-IP: [208.97.132.145]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4xNDUgPT4gMTk3Nzc=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16145 invoked from network); 26 Jan 2012 16:19:56 -0000
Received: from caiajhbdcbef.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.145) by server-2.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 16:19:56 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id DA0FB30008D;
	Thu, 26 Jan 2012 08:19: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=vpczBwV0AAaJGq3MZfpVgjUo50LzhnGRRByWNNJiM4Vg
	ok2jDNMhlEM1WEy13373OrxwkdRL3PIe5Dl2LDHt6fAMhgEo0v6oYMz/o/COLwpI
	YiK59jCO3JU+bI3vCCmON+k9Z6JB70SOOUkoo6/hRWDTa0UvFMBO19Evfxoa2PY=
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=IZytg1CNjhz1RnLpEHOMzR/4cpU=; b=JCXuZeWG
	fkRq+X+KElOWbwZqYDrSl3mYUXipMogzEATtc4BUcD4tRa/r1adSD9jcFd+5/C6v
	k5lc/WthnziSZaXN9d07wlkuFo3VGd7G8IL6z2JmzwYBSgbdnGc7JxuOddRMki3z
	LULNZZZm/yMinhtjWojfa5Bxzi79l4nMePk=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTPA id 6E1A130007B; 
	Thu, 26 Jan 2012 08:19: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, 26 Jan 2012 08:19:55 -0800
Message-ID: <b288b972af18d0e1607ff99bd6848834.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1637.1327585244.1471.xen-devel@lists.xensource.com>
References: <mailman.1637.1327585244.1471.xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 08:19:55 -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] tools/libxc: handle fallback in
 linux_privcmd_map_foreign_bulk properly
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, 26 Jan 2012 14:36:30 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] tools/libxc: handle fallback in
> 	linux_privcmd_map_foreign_bulk properly
> Message-ID: <aa0d678fece208975984.1327584990@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327584962 -3600
> # Node ID aa0d678fece208975984e8e59ca223c07fc50c06
> # Parent  89fdabcf315fdaabeebf05c51a6b3b6dd4c20e85
> tools/libxc: handle fallback in linux_privcmd_map_foreign_bulk properly
>
> If the first ioctl fails with ENOENT it means the command is known. If a
> second attempt to map each gfn happens to fail then there is no need to
> run the fallback code. Some gfns are paged and the fallback code would
> not fix the failure. Instead return the EINVAL to the caller.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

Thanks,
Andres
>
> diff -r 89fdabcf315f -r aa0d678fece2 tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -217,6 +217,7 @@ static void *linux_privcmd_map_foreign_b
>
>      rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
>
> +    /* Command was recognized, some gfn in arr are in paging state */
>      if ( rc < 0 && errno == ENOENT )
>      {
>          for ( i = rc = 0; rc == 0 && i < num; i++ )
> @@ -235,8 +236,8 @@ static void *linux_privcmd_map_foreign_b
>              } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
>          }
>      }
> -
> -    if ( rc < 0 && errno == EINVAL && (int)num > 0 )
> +    /* Command was not recognized, use fall back */
> +    else if ( rc < 0 && errno == EINVAL && (int)num > 0 )
>      {
>          /*
>           * IOCTL_PRIVCMD_MMAPBATCH_V2 is not supported - fall back to
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:26:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqS9l-0005gN-PI; Thu, 26 Jan 2012 16:26:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqS9k-0005gI-2r
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:26:36 +0000
Received: from [85.158.138.51:16446] by server-12.bemta-3.messagelabs.com id
	DC/B2-24557-BBE712F4; Thu, 26 Jan 2012 16:26:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327595183!10782500!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4176 invoked from network); 26 Jan 2012 16:26:23 -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; 26 Jan 2012 16:26:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqS9V-000LPU-Gm; Thu, 26 Jan 2012 16:26:21 +0000
Date: Thu, 26 Jan 2012 16:26:21 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com,
	ian.jackson@citrix.com
Message-ID: <20120126162621.GE80228@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

We seem to have agreement that we can start checking in the Xen 
ARMv7-with-Virtualization-Extensions patches that Stefano has been
posting. 

It's been suggested that Ian Campbell be made a committer for 
the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
http://www.xen.org/projects/governance.html, I hereby nominate him.

Keir, Ian, Jan, please respond with your integer of choice.

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 Jan 26 16:26:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqS9l-0005gN-PI; Thu, 26 Jan 2012 16:26:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1RqS9k-0005gI-2r
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:26:36 +0000
Received: from [85.158.138.51:16446] by server-12.bemta-3.messagelabs.com id
	DC/B2-24557-BBE712F4; Thu, 26 Jan 2012 16:26:35 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327595183!10782500!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4176 invoked from network); 26 Jan 2012 16:26:23 -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; 26 Jan 2012 16:26:23 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RqS9V-000LPU-Gm; Thu, 26 Jan 2012 16:26:21 +0000
Date: Thu, 26 Jan 2012 16:26:21 +0000
From: Tim Deegan <tim@xen.org>
To: xen-devel@lists.xensource.com, keir@xen.org, JBeulich@suse.com,
	ian.jackson@citrix.com
Message-ID: <20120126162621.GE80228@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Cc: Ian.Campbell@citrix.com
Subject: [Xen-devel] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

We seem to have agreement that we can start checking in the Xen 
ARMv7-with-Virtualization-Extensions patches that Stefano has been
posting. 

It's been suggested that Ian Campbell be made a committer for 
the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
http://www.xen.org/projects/governance.html, I hereby nominate him.

Keir, Ian, Jan, please respond with your integer of choice.

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 Jan 26 16:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqSA1-0005hb-6r; Thu, 26 Jan 2012 16:26: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 1RqS9z-0005h3-4Z
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:26:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327595078!50193080!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27919 invoked from network); 26 Jan 2012 16:24:38 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:24:38 -0000
Received: by wibhm2 with SMTP id hm2so1801411wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:26: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=k5zpRzWwBvGh5YsSSwr/RBbj2jXy6+/WanYyOnHBp1I=;
	b=FayymGe/Aa/8EgQbPHQvR3lC0H2fG0F5JYMU+hIXwmXtbFuWvHWreQiFsMLD6Uxa1+
	1Zl+BSCi2/iUHRHiCVh12E1Ogt1xY+Qi0tCdf4XpAMxsmC1tWjZYQU1GKxhTPv7LhiPj
	qin/EMnlbXqRak40xTTcVpAg4FQ5Ohali+yjk=
Received: by 10.180.106.33 with SMTP id gr1mr4795717wib.6.1327595208380;
	Thu, 26 Jan 2012 08:26:48 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id bj10sm6242144wib.9.2012.01.26.08.26.46
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 08:26:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 16:26:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB472F43.29AA2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
Thread-Index: AczcRRy+q/MAago7IE6d2nUJ4nR9xQAAi1Me
In-Reply-To: <CB472B9C.38573%keir@xen.org>
Mime-version: 1.0
Cc: JBeulich@suse.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 16:11, "Keir Fraser" <keir@xen.org> wrote:

> On 26/01/2012 15:49, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
> wrote:
> 
>> PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
>> Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
>> PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
>> hypercall.
> 
> It's nasty that pirq_eoi_gmfn has the side effect. I suggest add a PHYSDEVOP
> to explicitly enable/disable unmask-on-eoi (i.e., the command accepts a
> boolean parameter). Once it is explicitly enabled/disabled in this way,
> pirq_eoi_gmfn no longer has the side effect (regardless of whether it is
> called before or after the explicit setting). So e.g., pv_domain.auto_unmask
> becomes an int where 0/1 means no/yes, and -1 means default (i.e., old
> behavour where it depends on whether PHYSDEVOP_pirq_eoi_gmfn has been
> called).
> 
> This seems to me to move a bad interface in a better direction.

...in that the auto-unmask behaviour becomes explicitly selectable, rather
than implicitly, via two different commands for setting *something else*
which only differ in a side effect. That's kind of as gross as what we have
already, or worse.

 -- Keir

>  -- Keir
> 
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> ---
>>  xen/arch/ia64/xen/domain.c    |    1 +
>>  xen/arch/ia64/xen/hypercall.c |    5 ++++-
>>  xen/arch/x86/domain.c         |    1 +
>>  xen/arch/x86/physdev.c        |    6 +++++-
>>  xen/include/asm-ia64/domain.h |    3 +++
>>  xen/include/asm-x86/domain.h  |    3 +++
>>  xen/include/public/physdev.h  |    8 ++++++++
>>  7 files changed, 25 insertions(+), 2 deletions(-)
>> 
>> diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
>> index 1ea5a90..a31bd32 100644
>> --- a/xen/arch/ia64/xen/domain.c
>> +++ b/xen/arch/ia64/xen/domain.c
>> @@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
>> if (d->arch.pirq_eoi_map != NULL) {
>> put_page(virt_to_page(d->arch.pirq_eoi_map));
>> d->arch.pirq_eoi_map = NULL;
>> +   d->arch.auto_unmask = 0;
>> }
>>  
>> /* Tear down shadow mode stuff. */
>> diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
>> index 130675e..44c3407 100644
>> --- a/xen/arch/ia64/xen/hypercall.c
>> +++ b/xen/arch/ia64/xen/hypercall.c
>> @@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
>>  {
>> if ( pirq < 0 || pirq >= NR_IRQS )
>> return -EINVAL;
>> - if ( d->arch.pirq_eoi_map ) {
>> + if ( d->arch.pirq_eoi_map  && d->arch.auto_unmask ) {
>> spin_lock(&d->event_lock);
>> evtchn_unmask(pirq_to_evtchn(d, pirq));
>> spin_unlock(&d->event_lock);
>> @@ -508,6 +508,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>          break;
>>      }
>>  
>> +    case PHYSDEVOP_pirq_eoi_gmfn_new:
>>      case PHYSDEVOP_pirq_eoi_gmfn: {
>>          struct physdev_pirq_eoi_gmfn info;
>>          unsigned long mfn;
>> @@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>          }
>>  
>>          current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
>> +  if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
>> +   current->domain->arch.auto_unmask = 1;
>>          ret = 0;
>>          break;
>>      }
>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>> index 61d83c8..a540af7 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
>>                  put_page_and_type(
>>                      mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
>>                  d->arch.pv_domain.pirq_eoi_map = NULL;
>> +                d->arch.pv_domain.auto_unmask = 0;
>>              }
>>          }
>>  
>> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
>> index f280c28..efd517f 100644
>> --- a/xen/arch/x86/physdev.c
>> +++ b/xen/arch/x86/physdev.c
>> @@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>              break;
>>          }
>>          if ( !is_hvm_domain(v->domain) &&
>> -             v->domain->arch.pv_domain.pirq_eoi_map )
>> +             v->domain->arch.pv_domain.pirq_eoi_map &&
>> +             v->domain->arch.pv_domain.auto_unmask )
>>              evtchn_unmask(pirq->evtchn);
>>          if ( !is_hvm_domain(v->domain) ||
>>               domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
>> @@ -293,6 +294,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>          break;
>>      }
>>  
>> +    case PHYSDEVOP_pirq_eoi_gmfn_new:
>>      case PHYSDEVOP_pirq_eoi_gmfn: {
>>          struct physdev_pirq_eoi_gmfn info;
>>          unsigned long mfn;
>> @@ -329,6 +331,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>              ret = -ENOSPC;
>>              break;
>>          }
>> +        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
>> +            v->domain->arch.pv_domain.auto_unmask = 1;
>>  
>>          put_gfn(current->domain, info.gmfn);
>>          ret = 0;
>> diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
>> index 12dc3bd..8163d67 100644
>> --- a/xen/include/asm-ia64/domain.h
>> +++ b/xen/include/asm-ia64/domain.h
>> @@ -186,6 +186,9 @@ struct arch_domain {
>>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>>      unsigned long *pirq_eoi_map;
>>      unsigned long pirq_eoi_map_mfn;
>> + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
>> +  * unmask the event channel */
>> + unsigned int auto_unmask;
>>  
>>      /* Address of efi_runtime_services_t (placed in domain memory)  */
>>      void *efi_runtime;
>> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
>> index 00bbaeb..b0cbe65 100644
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -231,6 +231,9 @@ struct pv_domain
>>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>>      unsigned long *pirq_eoi_map;
>>      unsigned long pirq_eoi_map_mfn;
>> +    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
>> +     * unmask the event channel */
>> +    unsigned int auto_unmask;
>>  
>>      /* Pseudophysical e820 map (XENMEM_memory_map).  */
>>      spinlock_t e820_lock;
>> diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
>> index 6e23295..d555719 100644
>> --- a/xen/include/public/physdev.h
>> +++ b/xen/include/public/physdev.h
>> @@ -50,6 +50,14 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
>>   * array indexed by Xen's PIRQ value.
>>   */
>>  #define PHYSDEVOP_pirq_eoi_gmfn         17
>> +/*
>> + * Register a shared page for the hypervisor to indicate whether the
>> + * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
>> + * PHYSDEVOP_pirq_eoi_gmfn but it doesn't change the semantics of
>> + * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
>> + * Xen's PIRQ value.
>> + */
>> +#define PHYSDEVOP_pirq_eoi_gmfn_new         28
>>  struct physdev_pirq_eoi_gmfn {
>>      /* IN */
>>      xen_pfn_t gmfn;
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqSA1-0005hb-6r; Thu, 26 Jan 2012 16:26: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 1RqS9z-0005h3-4Z
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:26:51 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327595078!50193080!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27919 invoked from network); 26 Jan 2012 16:24:38 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:24:38 -0000
Received: by wibhm2 with SMTP id hm2so1801411wib.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 08:26: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=k5zpRzWwBvGh5YsSSwr/RBbj2jXy6+/WanYyOnHBp1I=;
	b=FayymGe/Aa/8EgQbPHQvR3lC0H2fG0F5JYMU+hIXwmXtbFuWvHWreQiFsMLD6Uxa1+
	1Zl+BSCi2/iUHRHiCVh12E1Ogt1xY+Qi0tCdf4XpAMxsmC1tWjZYQU1GKxhTPv7LhiPj
	qin/EMnlbXqRak40xTTcVpAg4FQ5Ohali+yjk=
Received: by 10.180.106.33 with SMTP id gr1mr4795717wib.6.1327595208380;
	Thu, 26 Jan 2012 08:26:48 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id bj10sm6242144wib.9.2012.01.26.08.26.46
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 08:26:47 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 16:26:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB472F43.29AA2%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
Thread-Index: AczcRRy+q/MAago7IE6d2nUJ4nR9xQAAi1Me
In-Reply-To: <CB472B9C.38573%keir@xen.org>
Mime-version: 1.0
Cc: JBeulich@suse.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 16:11, "Keir Fraser" <keir@xen.org> wrote:

> On 26/01/2012 15:49, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
> wrote:
> 
>> PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
>> Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
>> PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
>> hypercall.
> 
> It's nasty that pirq_eoi_gmfn has the side effect. I suggest add a PHYSDEVOP
> to explicitly enable/disable unmask-on-eoi (i.e., the command accepts a
> boolean parameter). Once it is explicitly enabled/disabled in this way,
> pirq_eoi_gmfn no longer has the side effect (regardless of whether it is
> called before or after the explicit setting). So e.g., pv_domain.auto_unmask
> becomes an int where 0/1 means no/yes, and -1 means default (i.e., old
> behavour where it depends on whether PHYSDEVOP_pirq_eoi_gmfn has been
> called).
> 
> This seems to me to move a bad interface in a better direction.

...in that the auto-unmask behaviour becomes explicitly selectable, rather
than implicitly, via two different commands for setting *something else*
which only differ in a side effect. That's kind of as gross as what we have
already, or worse.

 -- Keir

>  -- Keir
> 
>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> ---
>>  xen/arch/ia64/xen/domain.c    |    1 +
>>  xen/arch/ia64/xen/hypercall.c |    5 ++++-
>>  xen/arch/x86/domain.c         |    1 +
>>  xen/arch/x86/physdev.c        |    6 +++++-
>>  xen/include/asm-ia64/domain.h |    3 +++
>>  xen/include/asm-x86/domain.h  |    3 +++
>>  xen/include/public/physdev.h  |    8 ++++++++
>>  7 files changed, 25 insertions(+), 2 deletions(-)
>> 
>> diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
>> index 1ea5a90..a31bd32 100644
>> --- a/xen/arch/ia64/xen/domain.c
>> +++ b/xen/arch/ia64/xen/domain.c
>> @@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
>> if (d->arch.pirq_eoi_map != NULL) {
>> put_page(virt_to_page(d->arch.pirq_eoi_map));
>> d->arch.pirq_eoi_map = NULL;
>> +   d->arch.auto_unmask = 0;
>> }
>>  
>> /* Tear down shadow mode stuff. */
>> diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
>> index 130675e..44c3407 100644
>> --- a/xen/arch/ia64/xen/hypercall.c
>> +++ b/xen/arch/ia64/xen/hypercall.c
>> @@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
>>  {
>> if ( pirq < 0 || pirq >= NR_IRQS )
>> return -EINVAL;
>> - if ( d->arch.pirq_eoi_map ) {
>> + if ( d->arch.pirq_eoi_map  && d->arch.auto_unmask ) {
>> spin_lock(&d->event_lock);
>> evtchn_unmask(pirq_to_evtchn(d, pirq));
>> spin_unlock(&d->event_lock);
>> @@ -508,6 +508,7 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>          break;
>>      }
>>  
>> +    case PHYSDEVOP_pirq_eoi_gmfn_new:
>>      case PHYSDEVOP_pirq_eoi_gmfn: {
>>          struct physdev_pirq_eoi_gmfn info;
>>          unsigned long mfn;
>> @@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>          }
>>  
>>          current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
>> +  if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
>> +   current->domain->arch.auto_unmask = 1;
>>          ret = 0;
>>          break;
>>      }
>> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
>> index 61d83c8..a540af7 100644
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
>>                  put_page_and_type(
>>                      mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
>>                  d->arch.pv_domain.pirq_eoi_map = NULL;
>> +                d->arch.pv_domain.auto_unmask = 0;
>>              }
>>          }
>>  
>> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
>> index f280c28..efd517f 100644
>> --- a/xen/arch/x86/physdev.c
>> +++ b/xen/arch/x86/physdev.c
>> @@ -271,7 +271,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>              break;
>>          }
>>          if ( !is_hvm_domain(v->domain) &&
>> -             v->domain->arch.pv_domain.pirq_eoi_map )
>> +             v->domain->arch.pv_domain.pirq_eoi_map &&
>> +             v->domain->arch.pv_domain.auto_unmask )
>>              evtchn_unmask(pirq->evtchn);
>>          if ( !is_hvm_domain(v->domain) ||
>>               domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
>> @@ -293,6 +294,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>          break;
>>      }
>>  
>> +    case PHYSDEVOP_pirq_eoi_gmfn_new:
>>      case PHYSDEVOP_pirq_eoi_gmfn: {
>>          struct physdev_pirq_eoi_gmfn info;
>>          unsigned long mfn;
>> @@ -329,6 +331,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
>>              ret = -ENOSPC;
>>              break;
>>          }
>> +        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn )
>> +            v->domain->arch.pv_domain.auto_unmask = 1;
>>  
>>          put_gfn(current->domain, info.gmfn);
>>          ret = 0;
>> diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
>> index 12dc3bd..8163d67 100644
>> --- a/xen/include/asm-ia64/domain.h
>> +++ b/xen/include/asm-ia64/domain.h
>> @@ -186,6 +186,9 @@ struct arch_domain {
>>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>>      unsigned long *pirq_eoi_map;
>>      unsigned long pirq_eoi_map_mfn;
>> + /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
>> +  * unmask the event channel */
>> + unsigned int auto_unmask;
>>  
>>      /* Address of efi_runtime_services_t (placed in domain memory)  */
>>      void *efi_runtime;
>> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
>> index 00bbaeb..b0cbe65 100644
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -231,6 +231,9 @@ struct pv_domain
>>      /* Shared page for notifying that explicit PIRQ EOI is required. */
>>      unsigned long *pirq_eoi_map;
>>      unsigned long pirq_eoi_map_mfn;
>> +    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
>> +     * unmask the event channel */
>> +    unsigned int auto_unmask;
>>  
>>      /* Pseudophysical e820 map (XENMEM_memory_map).  */
>>      spinlock_t e820_lock;
>> diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
>> index 6e23295..d555719 100644
>> --- a/xen/include/public/physdev.h
>> +++ b/xen/include/public/physdev.h
>> @@ -50,6 +50,14 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
>>   * array indexed by Xen's PIRQ value.
>>   */
>>  #define PHYSDEVOP_pirq_eoi_gmfn         17
>> +/*
>> + * Register a shared page for the hypervisor to indicate whether the
>> + * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
>> + * PHYSDEVOP_pirq_eoi_gmfn but it doesn't change the semantics of
>> + * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
>> + * Xen's PIRQ value.
>> + */
>> +#define PHYSDEVOP_pirq_eoi_gmfn_new         28
>>  struct physdev_pirq_eoi_gmfn {
>>      /* IN */
>>      xen_pfn_t gmfn;
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:29:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSC7-0005s5-Pp; Thu, 26 Jan 2012 16:29:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqSC6-0005rt-OR
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:29:02 +0000
Received: from [85.158.139.83:62881] by server-3.bemta-5.messagelabs.com id
	E6/8D-16424-D4F712F4; Thu, 26 Jan 2012 16:29:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327595340!12513615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 358 invoked from network); 26 Jan 2012 16:29:00 -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;
	26 Jan 2012 16:29:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10310395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:29: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; Thu, 26 Jan 2012 16:29:00 +0000
Date: Thu, 26 Jan 2012 16:29:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CB472B9C.38573%keir@xen.org>
Message-ID: <alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
References: <CB472B9C.38573%keir@xen.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Keir Fraser wrote:
> On 26/01/2012 15:49, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
> wrote:
> 
> > PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
> > Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
> > PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
> > hypercall.
> 
> It's nasty that pirq_eoi_gmfn has the side effect. I suggest add a PHYSDEVOP
> to explicitly enable/disable unmask-on-eoi (i.e., the command accepts a
> boolean parameter). Once it is explicitly enabled/disabled in this way,
> pirq_eoi_gmfn no longer has the side effect (regardless of whether it is
> called before or after the explicit setting). So e.g., pv_domain.auto_unmask
> becomes an int where 0/1 means no/yes, and -1 means default (i.e., old
> behavour where it depends on whether PHYSDEVOP_pirq_eoi_gmfn has been
> called).
> 
> This seems to me to move a bad interface in a better direction.

The problem with this approach is that by default we have an hypercall
(PHYSDEVOP_pirq_eoi_gmfn) changing the behaviour of another one
(PHYSDEVOP_eoi). Not only this but we have an hypercall
(PHYSDEVOP_pirq_eoi_gmfn) violating the public interface of shared_info
as documented in public/xen.h.

Introducing a new hypercall with the same name
(PHYSDEVOP_pirq_eoi_gmfn_new) is the first step in admitting that the
old hypercall was a mistake and should not be used.

I don't think we should ever change the semantics of PHYSDEVOP_eoi with
another hypercall. If we want a PHYSDEVOP that eoi and unmask and event
channel let's introduce PHYSDEVOP_eoi_unmask.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:29:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:29:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSC7-0005s5-Pp; Thu, 26 Jan 2012 16:29:03 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqSC6-0005rt-OR
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:29:02 +0000
Received: from [85.158.139.83:62881] by server-3.bemta-5.messagelabs.com id
	E6/8D-16424-D4F712F4; Thu, 26 Jan 2012 16:29:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327595340!12513615!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 358 invoked from network); 26 Jan 2012 16:29:00 -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;
	26 Jan 2012 16:29:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10310395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:29: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; Thu, 26 Jan 2012 16:29:00 +0000
Date: Thu, 26 Jan 2012 16:29:46 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Keir Fraser <keir@xen.org>
In-Reply-To: <CB472B9C.38573%keir@xen.org>
Message-ID: <alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
References: <CB472B9C.38573%keir@xen.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Keir Fraser wrote:
> On 26/01/2012 15:49, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
> wrote:
> 
> > PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
> > Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
> > PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
> > hypercall.
> 
> It's nasty that pirq_eoi_gmfn has the side effect. I suggest add a PHYSDEVOP
> to explicitly enable/disable unmask-on-eoi (i.e., the command accepts a
> boolean parameter). Once it is explicitly enabled/disabled in this way,
> pirq_eoi_gmfn no longer has the side effect (regardless of whether it is
> called before or after the explicit setting). So e.g., pv_domain.auto_unmask
> becomes an int where 0/1 means no/yes, and -1 means default (i.e., old
> behavour where it depends on whether PHYSDEVOP_pirq_eoi_gmfn has been
> called).
> 
> This seems to me to move a bad interface in a better direction.

The problem with this approach is that by default we have an hypercall
(PHYSDEVOP_pirq_eoi_gmfn) changing the behaviour of another one
(PHYSDEVOP_eoi). Not only this but we have an hypercall
(PHYSDEVOP_pirq_eoi_gmfn) violating the public interface of shared_info
as documented in public/xen.h.

Introducing a new hypercall with the same name
(PHYSDEVOP_pirq_eoi_gmfn_new) is the first step in admitting that the
old hypercall was a mistake and should not be used.

I don't think we should ever change the semantics of PHYSDEVOP_eoi with
another hypercall. If we want a PHYSDEVOP that eoi and unmask and event
channel let's introduce PHYSDEVOP_eoi_unmask.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSDt-00060n-Aj; Thu, 26 Jan 2012 16:30:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqSDs-00060d-36
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:30:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327595429!64053566!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMjUw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMjUw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19685 invoked from network); 26 Jan 2012 16:30:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.81) by server-15.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 16:30:29 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 5D46F604079;
	Thu, 26 Jan 2012 08:30: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=gbS5ju4GDlMv2tzBdAifVOjeSOtGnUihkg0svtg5BTRq
	0ZWSp8R1gu+fLNo2hBAO5Q5QNQw80XHeaS7iSzQDi1QPv68Py2rCWuHOOrhwY59M
	nfABwsLd/xoeJpU5UZetB3LeJy56c3Feo97yTo52XUBRoqIMfqARkygk5L7z+1s=
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=FINsVQ6ZaghtfKfdsnyb6tt4ls8=; b=V0yrRVDu
	8Z+qqa+qsID2MfUVatRtHIwHqbe8MK5iGhQeSEvq8HcWxDj9w6XzjoYECI5BYuhQ
	h6l3W5VRn2wrUGOEae/ZrQj0oo6K7heiwePEIeC25tVRGqOnCnPmsgWDRyB33lVn
	cknRWYVZO6+DyWieNMYa9WU5mr4ixLn+2mY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 1AACD604061; 
	Thu, 26 Jan 2012 08:30:48 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 08:30:49 -0800
Message-ID: <317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 08:30:49 -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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
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, 26 Jan 2012 15:51:02 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] tools/libxc: send page-in requests in
> 	batches in linux_privcmd_map_foreign_bulk
> Message-ID: <bace47d7623cb92d5b08.1327589462@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327589312 -3600
> # Node ID bace47d7623cb92d5b080c54d3850642b8c52b46
> # Parent  a87cbe503fed9e15d90d0bf6645d835331ec8874
> tools/libxc: send page-in requests in batches in
> linux_privcmd_map_foreign_bulk
>
> One of the bottlenecks with foreign page-in request is the poor retry
> handling in linux_privcmd_map_foreign_bulk(). It sends one request per
> paged gfn at a time and it waits until the gfn is accessible. This
> causes long delays in mmap requests from qemu-dm and xc_save.
>
> Instead of sending one request at a time, walk the entire gfn list and
> send batches of mmap requests. They will eventually end up in the pagers
> request ring (if it has room again), and will fill up this ring so that
> in turn the pager can also process page-in in batches.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r a87cbe503fed -r bace47d7623c tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -191,6 +191,59 @@ static void *linux_privcmd_map_foreign_b
>      return addr;
>  }
>
> +/*
> + * Retry mmap of paged gfns in batches
> + * retuns < 0 on fatal error
> + * returns 0 if all gfns left paging state
> + * returns > 0 if some gfns are still in paging state
> + *
> + * Walk all gfns are assemble blocks of gfns in paging state.
> + * This will keep the request ring full and avoids delays.
> + */
> +static int retry_paged(int fd, uint32_t dom, void *addr,
> +                       const xen_pfn_t *arr, int *err, unsigned int num)
> +{
> +    privcmd_mmapbatch_v2_t ioctlx;
> +    int rc, paged = 0, i = 0;
> +
> +    do
> +    {
> +        /* Skip gfns not in paging state */
> +        if ( err[i] != -ENOENT )
> +        {
> +            i++;
> +            continue;
> +        }
> +
> +        paged++;
> +
> +        /* At least one gfn is still in paging state */
> +        ioctlx.num = 1;
> +        ioctlx.dom = dom;
> +        ioctlx.addr = (unsigned long)addr + ((unsigned
> long)i<<XC_PAGE_SHIFT);
> +        ioctlx.arr = arr + i;
> +        ioctlx.err = err + i;
> +
> +        /* Assemble a batch of requests */
> +        while ( ++i < num )
> +        {
> +            if ( err[i] != -ENOENT )
> +                break;
> +            ioctlx.num++;
> +        }

Olaf,
if I get a pattern of errors in the err array of the form:

{ENOENT, EWHATEVER, ENOENT, EWHATEVER}
with EWHATEVER != ENOENT

this patch does not optimize anything.

Why not alloc a separate arr2 array, move the gfn's that failed with
ENOENT there, and retry the whole new arr2 block? You only need to
allocate arr2 once, to size num. That will batch always, everything.

Thanks,
Andres
> +
> +        /* Send request and abort on fatal error */
> +        rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
> +        if ( rc < 0 && errno != ENOENT )
> +            goto out;
> +
> +    } while ( i < num );
> +
> +    rc = paged;
> +out:
> +    return rc;
> +}
> +
>  static void *linux_privcmd_map_foreign_bulk(xc_interface *xch,
> xc_osdep_handle h,
>                                              uint32_t dom, int prot,
>                                              const xen_pfn_t *arr, int
> *err, unsigned int num)
> @@ -220,21 +273,10 @@ static void *linux_privcmd_map_foreign_b
>      /* Command was recognized, some gfn in arr are in paging state */
>      if ( rc < 0 && errno == ENOENT )
>      {
> -        for ( i = rc = 0; rc == 0 && i < num; i++ )
> -        {
> -            if ( err[i] != -ENOENT )
> -                continue;
> -
> -            ioctlx.num = 1;
> -            ioctlx.dom = dom;
> -            ioctlx.addr = (unsigned long)addr + ((unsigned
> long)i<<XC_PAGE_SHIFT);
> -            ioctlx.arr = arr + i;
> -            ioctlx.err = err + i;
> -            do {
> -                usleep(100);
> -                rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
> -            } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
> -        }
> +        do {
> +            usleep(100);
> +            rc = retry_paged(fd, dom, addr, arr, err, num);
> +        } while ( rc > 0 );
>      }
>      /* Command was not recognized, use fall back */
>      else if ( rc < 0 && errno == EINVAL && (int)num > 0 )
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:31:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:31:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSDt-00060n-Aj; Thu, 26 Jan 2012 16:30:53 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqSDs-00060d-36
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:30:52 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327595429!64053566!1
X-Originating-IP: [208.97.132.81]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMjUw\n,sa_preprocessor: 
	QmFkIElQOiAyMDguOTcuMTMyLjgxID0+IDIwMjUw\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19685 invoked from network); 26 Jan 2012 16:30:29 -0000
Received: from caiajhbdcaib.dreamhost.com (HELO homiemail-a19.g.dreamhost.com)
	(208.97.132.81) by server-15.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 16:30:29 -0000
Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 5D46F604079;
	Thu, 26 Jan 2012 08:30: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=gbS5ju4GDlMv2tzBdAifVOjeSOtGnUihkg0svtg5BTRq
	0ZWSp8R1gu+fLNo2hBAO5Q5QNQw80XHeaS7iSzQDi1QPv68Py2rCWuHOOrhwY59M
	nfABwsLd/xoeJpU5UZetB3LeJy56c3Feo97yTo52XUBRoqIMfqARkygk5L7z+1s=
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=FINsVQ6ZaghtfKfdsnyb6tt4ls8=; b=V0yrRVDu
	8Z+qqa+qsID2MfUVatRtHIwHqbe8MK5iGhQeSEvq8HcWxDj9w6XzjoYECI5BYuhQ
	h6l3W5VRn2wrUGOEae/ZrQj0oo6K7heiwePEIeC25tVRGqOnCnPmsgWDRyB33lVn
	cknRWYVZO6+DyWieNMYa9WU5mr4ixLn+2mY=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 1AACD604061; 
	Thu, 26 Jan 2012 08:30:48 -0800 (PST)
Received: from 206.223.182.18 (proxying for 206.223.182.18)
	(SquirrelMail authenticated user andres@lagarcavilla.com)
	by webmail.lagarcavilla.org with HTTP;
	Thu, 26 Jan 2012 08:30:49 -0800
Message-ID: <317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 08:30:49 -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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
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, 26 Jan 2012 15:51:02 +0100
> From: Olaf Hering <olaf@aepfle.de>
> To: xen-devel@lists.xensource.com
> Subject: [Xen-devel] [PATCH] tools/libxc: send page-in requests in
> 	batches in linux_privcmd_map_foreign_bulk
> Message-ID: <bace47d7623cb92d5b08.1327589462@probook.site>
> Content-Type: text/plain; charset="us-ascii"
>
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327589312 -3600
> # Node ID bace47d7623cb92d5b080c54d3850642b8c52b46
> # Parent  a87cbe503fed9e15d90d0bf6645d835331ec8874
> tools/libxc: send page-in requests in batches in
> linux_privcmd_map_foreign_bulk
>
> One of the bottlenecks with foreign page-in request is the poor retry
> handling in linux_privcmd_map_foreign_bulk(). It sends one request per
> paged gfn at a time and it waits until the gfn is accessible. This
> causes long delays in mmap requests from qemu-dm and xc_save.
>
> Instead of sending one request at a time, walk the entire gfn list and
> send batches of mmap requests. They will eventually end up in the pagers
> request ring (if it has room again), and will fill up this ring so that
> in turn the pager can also process page-in in batches.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
>
> diff -r a87cbe503fed -r bace47d7623c tools/libxc/xc_linux_osdep.c
> --- a/tools/libxc/xc_linux_osdep.c
> +++ b/tools/libxc/xc_linux_osdep.c
> @@ -191,6 +191,59 @@ static void *linux_privcmd_map_foreign_b
>      return addr;
>  }
>
> +/*
> + * Retry mmap of paged gfns in batches
> + * retuns < 0 on fatal error
> + * returns 0 if all gfns left paging state
> + * returns > 0 if some gfns are still in paging state
> + *
> + * Walk all gfns are assemble blocks of gfns in paging state.
> + * This will keep the request ring full and avoids delays.
> + */
> +static int retry_paged(int fd, uint32_t dom, void *addr,
> +                       const xen_pfn_t *arr, int *err, unsigned int num)
> +{
> +    privcmd_mmapbatch_v2_t ioctlx;
> +    int rc, paged = 0, i = 0;
> +
> +    do
> +    {
> +        /* Skip gfns not in paging state */
> +        if ( err[i] != -ENOENT )
> +        {
> +            i++;
> +            continue;
> +        }
> +
> +        paged++;
> +
> +        /* At least one gfn is still in paging state */
> +        ioctlx.num = 1;
> +        ioctlx.dom = dom;
> +        ioctlx.addr = (unsigned long)addr + ((unsigned
> long)i<<XC_PAGE_SHIFT);
> +        ioctlx.arr = arr + i;
> +        ioctlx.err = err + i;
> +
> +        /* Assemble a batch of requests */
> +        while ( ++i < num )
> +        {
> +            if ( err[i] != -ENOENT )
> +                break;
> +            ioctlx.num++;
> +        }

Olaf,
if I get a pattern of errors in the err array of the form:

{ENOENT, EWHATEVER, ENOENT, EWHATEVER}
with EWHATEVER != ENOENT

this patch does not optimize anything.

Why not alloc a separate arr2 array, move the gfn's that failed with
ENOENT there, and retry the whole new arr2 block? You only need to
allocate arr2 once, to size num. That will batch always, everything.

Thanks,
Andres
> +
> +        /* Send request and abort on fatal error */
> +        rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
> +        if ( rc < 0 && errno != ENOENT )
> +            goto out;
> +
> +    } while ( i < num );
> +
> +    rc = paged;
> +out:
> +    return rc;
> +}
> +
>  static void *linux_privcmd_map_foreign_bulk(xc_interface *xch,
> xc_osdep_handle h,
>                                              uint32_t dom, int prot,
>                                              const xen_pfn_t *arr, int
> *err, unsigned int num)
> @@ -220,21 +273,10 @@ static void *linux_privcmd_map_foreign_b
>      /* Command was recognized, some gfn in arr are in paging state */
>      if ( rc < 0 && errno == ENOENT )
>      {
> -        for ( i = rc = 0; rc == 0 && i < num; i++ )
> -        {
> -            if ( err[i] != -ENOENT )
> -                continue;
> -
> -            ioctlx.num = 1;
> -            ioctlx.dom = dom;
> -            ioctlx.addr = (unsigned long)addr + ((unsigned
> long)i<<XC_PAGE_SHIFT);
> -            ioctlx.arr = arr + i;
> -            ioctlx.err = err + i;
> -            do {
> -                usleep(100);
> -                rc = ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH_V2, &ioctlx);
> -            } while ( rc < 0 && errno == ENOENT && err[i] == -ENOENT );
> -        }
> +        do {
> +            usleep(100);
> +            rc = retry_paged(fd, dom, addr, arr, err, num);
> +        } while ( rc > 0 );
>      }
>      /* Command was not recognized, use fall back */
>      else if ( rc < 0 && errno == EINVAL && (int)num > 0 )
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:33:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqSGd-0006CK-30; Thu, 26 Jan 2012 16:33:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RqSGb-0006CD-CL
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:33:41 +0000
Received: from [85.158.138.51:59309] by server-10.bemta-3.messagelabs.com id
	FA/54-20948-460812F4; Thu, 26 Jan 2012 16:33:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327595618!10811597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27846 invoked from network); 26 Jan 2012 16:33:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:33:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179232377"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:33:33 -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, 26 Jan 2012
	11:33:33 -0500
Message-ID: <4F21805C.9060801@citrix.com>
Date: Thu, 26 Jan 2012 16:33:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>
	<4F216A12.80602@citrix.com>
	<4F2186B4020000780006F429@nat28.tlf.novell.com>
In-Reply-To: <4F2186B4020000780006F429@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 26/01/12 16:00, Jan Beulich wrote:
>>>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 26/01/12 14:41, Jan Beulich wrote:
>>>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> XenServer by default boots without a serial console (buggy hardware
>>>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
>>>> writing to the vga text area looks ugly whilst dom0 is trying to set up
>>>> non-text mode and display  the splash screen.
>>>>
>>>> We have been using "console=" to prevent this behavior for a while, but
>>>> presented herewith is a patch to fix the problem correctly.
>>> While I don't mind the patch, I'm completely confused by the description:
>>> Where is it that Xen writes to VGA text area after control was passed to
>>> Dom0?
>>>
>>> Jan
>> I have not debugged it that much as I was looking for a clean solution
>> to our current hack of "console=" (and I have some rather more serious
>> deadlock bugs to debug), but it all Xen printk's are going into the VGA
>> text area, even after dom0 has started.  It is possible that Xen is
>> still writing into the text area after dom0 has switched VGA mode, but I
>> have no proof of this one way or the other.
> Just take a look at vga_endboot() - the output routine gets pointed to
> vga_noop_puts() unless vgacon_keep. Beyond that point nothing
> can possibly get printed to the VGA text screen, or if it does, then I'd
> suspect there's some other change in XenServer that makes it so.
>
> Jan

I have just been debugging this, and found that it got up to my debug
message of switching back to vga_noop_puts().

I know that this was called before dom0 started booting, but that it
appeared as if it was being written while dom0 was booting

It turns out that the problem is that after vesa_endboot zeros the
linear framebuffer, it does not call lfb_flush(), meaning that an sfence
does not occur, and presumably the actual linear framebuffer still has
Xen console text in it when dom0 takes over and sets it up.

Hacking an sfence into vesa_endboot() fixes the issue completely.

I shall roll a patch using lfb_flush() and post it shortly.

-- 
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 Jan 26 16:33:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqSGd-0006CK-30; Thu, 26 Jan 2012 16:33:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RqSGb-0006CD-CL
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:33:41 +0000
Received: from [85.158.138.51:59309] by server-10.bemta-3.messagelabs.com id
	FA/54-20948-460812F4; Thu, 26 Jan 2012 16:33:40 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327595618!10811597!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27846 invoked from network); 26 Jan 2012 16:33:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:33:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179232377"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:33:33 -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, 26 Jan 2012
	11:33:33 -0500
Message-ID: <4F21805C.9060801@citrix.com>
Date: Thu, 26 Jan 2012 16:33:32 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Jan Beulich <JBeulich@suse.com>
References: <4F2144EE.9040808@citrix.com>
	<4F21743C020000780006F3AA@nat28.tlf.novell.com>
	<4F216A12.80602@citrix.com>
	<4F2186B4020000780006F429@nat28.tlf.novell.com>
In-Reply-To: <4F2186B4020000780006F429@nat28.tlf.novell.com>
X-Enigmail-Version: 1.1.2
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [Xen-devel] console: introduce console=none option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com



On 26/01/12 16:00, Jan Beulich wrote:
>>>> On 26.01.12 at 15:58, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 26/01/12 14:41, Jan Beulich wrote:
>>>>>> On 26.01.12 at 13:19, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>>>> XenServer by default boots without a serial console (buggy hardware
>>>> reasons) and dom0 displays a splash screen.  Unfortunately, having Xen
>>>> writing to the vga text area looks ugly whilst dom0 is trying to set up
>>>> non-text mode and display  the splash screen.
>>>>
>>>> We have been using "console=" to prevent this behavior for a while, but
>>>> presented herewith is a patch to fix the problem correctly.
>>> While I don't mind the patch, I'm completely confused by the description:
>>> Where is it that Xen writes to VGA text area after control was passed to
>>> Dom0?
>>>
>>> Jan
>> I have not debugged it that much as I was looking for a clean solution
>> to our current hack of "console=" (and I have some rather more serious
>> deadlock bugs to debug), but it all Xen printk's are going into the VGA
>> text area, even after dom0 has started.  It is possible that Xen is
>> still writing into the text area after dom0 has switched VGA mode, but I
>> have no proof of this one way or the other.
> Just take a look at vga_endboot() - the output routine gets pointed to
> vga_noop_puts() unless vgacon_keep. Beyond that point nothing
> can possibly get printed to the VGA text screen, or if it does, then I'd
> suspect there's some other change in XenServer that makes it so.
>
> Jan

I have just been debugging this, and found that it got up to my debug
message of switching back to vga_noop_puts().

I know that this was called before dom0 started booting, but that it
appeared as if it was being written while dom0 was booting

It turns out that the problem is that after vesa_endboot zeros the
linear framebuffer, it does not call lfb_flush(), meaning that an sfence
does not occur, and presumably the actual linear framebuffer still has
Xen console text in it when dom0 takes over and sets it up.

Hacking an sfence into vesa_endboot() fixes the issue completely.

I shall roll a patch using lfb_flush() and post it shortly.

-- 
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 Jan 26 16:37:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSKH-0006OQ-US; Thu, 26 Jan 2012 16:37:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqSKF-0006OH-Lv
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:37:27 +0000
Received: from [85.158.139.83:31558] by server-6.bemta-5.messagelabs.com id
	54/5D-21889-641812F4; Thu, 26 Jan 2012 16:37:26 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327595844!12541085!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6820 invoked from network); 26 Jan 2012 16:37:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:37:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179233184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:37:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 11:37:23 -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 q0QGbKq7009690;
	Thu, 26 Jan 2012 08:37:21 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1326903894.5856.35.camel@Solace>
References: <1326903221.5856.33.camel@Solace> <1326903894.5856.35.camel@Solace>
Date: Thu, 26 Jan 2012 16:37:19 +0000
Message-ID: <1327595839.24345.63.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>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1] sched: rework locking for dump
	debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-18 at 16:24 +0000, Dario Faggioli wrote:
> As in all other paths, locking should be dealt with in the
> specific schedulers, not in schedule.c.

I think this looks right.  But you should probably add a comment at the
top of credit1 and sedf to say that now the locking order must be
private -> schedule, to avoid deadlock.

(Before I don't think there was an ordering.)

Thanks,
 -George

> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 15ab61865ecb xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/common/sched_credit.c	Wed Jan 18 15:02:30 2012 +0000
> @@ -1451,11 +1451,16 @@ static void
>  csched_dump_pcpu(const struct scheduler *ops, int cpu)
>  {
>      struct list_head *runq, *iter;
> +    struct csched_private *prv = CSCHED_PRIV(ops);
>      struct csched_pcpu *spc;
>      struct csched_vcpu *svc;
> +    unsigned long flags;
>      int loop;
>  #define cpustr keyhandler_scratch
>  
> +    /* Domains' parameters are changed under csched_priv lock */
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      spc = CSCHED_PCPU(cpu);
>      runq = &spc->runq;
>  
> @@ -1464,6 +1469,12 @@ csched_dump_pcpu(const struct scheduler 
>      cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
>      printk("core=%s\n", cpustr);
>  
> +    /*
> +     * We need runq lock as well, and as there's one runq per CPU,
> +     * this is the correct one to take for this CPU/runq.
> +     */
> +    pcpu_schedule_lock(cpu);
> +
>      /* current VCPU */
>      svc = CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
>      if ( svc )
> @@ -1482,6 +1493,9 @@ csched_dump_pcpu(const struct scheduler 
>              csched_dump_vcpu(svc);
>          }
>      }
> +
> +    pcpu_schedule_unlock(cpu);
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  #undef cpustr
>  }
>  
> @@ -1493,7 +1507,7 @@ csched_dump(const struct scheduler *ops)
>      int loop;
>      unsigned long flags;
>  
> -    spin_lock_irqsave(&(prv->lock), flags);
> +    spin_lock_irqsave(&prv->lock, flags);
>  
>  #define idlers_buf keyhandler_scratch
>  
> @@ -1537,12 +1551,14 @@ csched_dump(const struct scheduler *ops)
>              svc = list_entry(iter_svc, struct csched_vcpu, active_vcpu_elem);
>  
>              printk("\t%3d: ", ++loop);
> +            vcpu_schedule_lock(svc->vcpu);
>              csched_dump_vcpu(svc);
> +            vcpu_schedule_unlock(svc->vcpu);
>          }
>      }
>  #undef idlers_buf
>  
> -    spin_unlock_irqrestore(&(prv->lock), flags);
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
>  static int
> diff -r 15ab61865ecb xen/common/sched_credit2.c
> --- a/xen/common/sched_credit2.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/common/sched_credit2.c	Wed Jan 18 15:02:30 2012 +0000
> @@ -53,8 +53,6 @@
>   * credit2 wiki page:
>   *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
>   * TODO:
> - * + Immediate bug-fixes
> - *  - Do per-runqueue, grab proper lock for dump debugkey
>   * + Multiple sockets
>   *  - Detect cpu layout and make runqueue map, one per L2 (make_runq_map())
>   *  - Simple load balancer / runqueue assignment
> @@ -1759,12 +1757,16 @@ csched_dump_vcpu(struct csched_vcpu *svc
>  static void
>  csched_dump_pcpu(const struct scheduler *ops, int cpu)
>  {
> +    struct csched_private *prv = CSCHED_PRIV(ops);
>      struct list_head *runq, *iter;
>      struct csched_vcpu *svc;
> +    unsigned long flags;
> +    spinlock_t *lock;
>      int loop;
>      char cpustr[100];
>  
> -    /* FIXME: Do locking properly for access to runqueue structures */
> +    /* Domains' parameters are changed under csched_priv lock */
> +    spin_lock_irqsave(&prv->lock, flags);
>  
>      runq = &RQD(ops, cpu)->runq;
>  
> @@ -1773,6 +1775,13 @@ csched_dump_pcpu(const struct scheduler 
>      cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
>      printk("core=%s\n", cpustr);
>  
> +    /*
> +     * We need runq lock as well, and here's how we get to it
> +     * for the requested cpu.
> +     */
> +    lock = per_cpu(schedule_data, cpu).schedule_lock;
> +    spin_lock(lock);
> +
>      /* current VCPU */
>      svc = CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
>      if ( svc )
> @@ -1791,6 +1800,9 @@ csched_dump_pcpu(const struct scheduler 
>              csched_dump_vcpu(svc);
>          }
>      }
> +
> +    spin_unlock(lock);
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
>  static void
> @@ -1798,8 +1810,11 @@ csched_dump(const struct scheduler *ops)
>  {
>      struct list_head *iter_sdom, *iter_svc;
>      struct csched_private *prv = CSCHED_PRIV(ops);
> +    unsigned long flags;
>      int i, loop;
>  
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      printk("Active queues: %d\n"
>             "\tdefault-weight     = %d\n",
>             cpumask_weight(&prv->active_queues),
> @@ -1822,7 +1837,6 @@ csched_dump(const struct scheduler *ops)
>                 fraction);
>  
>      }
> -    /* FIXME: Locking! */
>  
>      printk("Domain info:\n");
>      loop = 0;
> @@ -1831,10 +1845,10 @@ csched_dump(const struct scheduler *ops)
>          struct csched_dom *sdom;
>          sdom = list_entry(iter_sdom, struct csched_dom, sdom_elem);
>  
> -       printk("\tDomain: %d w %d v %d\n\t", 
> -              sdom->dom->domain_id, 
> -              sdom->weight, 
> -              sdom->nr_vcpus);
> +        printk("\tDomain: %d w %d v %d\n\t", 
> +               sdom->dom->domain_id, 
> +               sdom->weight, 
> +               sdom->nr_vcpus);
>  
>          list_for_each( iter_svc, &sdom->vcpu )
>          {
> @@ -1842,9 +1856,13 @@ csched_dump(const struct scheduler *ops)
>              svc = list_entry(iter_svc, struct csched_vcpu, sdom_elem);
>  
>              printk("\t%3d: ", ++loop);
> +            vcpu_schedule_lock(svc->vcpu);
>              csched_dump_vcpu(svc);
> +            vcpu_schedule_unlock(svc->vcpu);
>          }
>      }
> +
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
>  static void activate_runqueue(struct csched_private *prv, int rqi)
> diff -r 15ab61865ecb xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/common/sched_sedf.c	Wed Jan 18 15:02:30 2012 +0000
> @@ -1219,13 +1219,25 @@ static void sedf_dump_domain(struct vcpu
>  /* Dumps all domains on the specified cpu */
>  static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
>  {
> +    struct sedf_priv_info *prv = SEDF_PRIV(ops);
>      struct list_head      *list, *queue, *tmp;
>      struct sedf_vcpu_info *d_inf;
>      struct domain         *d;
>      struct vcpu    *ed;
> +    unsigned long flags;
>      int loop = 0;
> +
> +    /* Domains' parameters are changed under scheduler lock */
> +    spin_lock_irqsave(&prv->lock, flags);
>   
>      printk("now=%"PRIu64"\n",NOW());
> +
> +    /*
> +     * We need runq lock as well, and as there's one runq per CPU,
> +     * this is the correct one to take for this CPU/runq.
> +     */
> +    pcpu_schedule_lock(i);
> +
>      queue = RUNQ(i);
>      printk("RUNQ rq %lx   n: %lx, p: %lx\n",  (unsigned long)queue,
>             (unsigned long) queue->next, (unsigned long) queue->prev);
> @@ -1288,6 +1300,9 @@ static void sedf_dump_cpu_state(const st
>          }
>      }
>      rcu_read_unlock(&domlist_read_lock);
> +
> +    pcpu_schedule_unlock(i);
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
> 
> diff -r 15ab61865ecb xen/common/schedule.c
> --- a/xen/common/schedule.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/common/schedule.c	Wed Jan 18 15:02:30 2012 +0000
> @@ -1417,6 +1417,7 @@ void schedule_dump(struct cpupool *c)
>      struct scheduler *sched;
>      cpumask_t        *cpus;
>  
> +    /* Proper locking is provided by each scheduler */
>      sched = (c == NULL) ? &ops : c->sched;
>      cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
>      printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
> @@ -1424,10 +1425,8 @@ void schedule_dump(struct cpupool *c)
>  
>      for_each_cpu (i, cpus)
>      {
> -        pcpu_schedule_lock(i);
>          printk("CPU[%02d] ", i);
>          SCHED_OP(sched, dump_cpu_state, i);
> -        pcpu_schedule_unlock(i);
>      }
>  }
>  
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:37:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:37:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSKH-0006OQ-US; Thu, 26 Jan 2012 16:37:29 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqSKF-0006OH-Lv
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:37:27 +0000
Received: from [85.158.139.83:31558] by server-6.bemta-5.messagelabs.com id
	54/5D-21889-641812F4; Thu, 26 Jan 2012 16:37:26 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327595844!12541085!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6820 invoked from network); 26 Jan 2012 16:37:25 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:37:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179233184"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:37:23 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 11:37:23 -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 q0QGbKq7009690;
	Thu, 26 Jan 2012 08:37:21 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Dario Faggioli <raistlin@linux.it>
In-Reply-To: <1326903894.5856.35.camel@Solace>
References: <1326903221.5856.33.camel@Solace> <1326903894.5856.35.camel@Solace>
Date: Thu, 26 Jan 2012 16:37:19 +0000
Message-ID: <1327595839.24345.63.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>, "Keir
	\(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1] sched: rework locking for dump
	debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 2012-01-18 at 16:24 +0000, Dario Faggioli wrote:
> As in all other paths, locking should be dealt with in the
> specific schedulers, not in schedule.c.

I think this looks right.  But you should probably add a comment at the
top of credit1 and sedf to say that now the locking order must be
private -> schedule, to avoid deadlock.

(Before I don't think there was an ordering.)

Thanks,
 -George

> 
> Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> diff -r 15ab61865ecb xen/common/sched_credit.c
> --- a/xen/common/sched_credit.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/common/sched_credit.c	Wed Jan 18 15:02:30 2012 +0000
> @@ -1451,11 +1451,16 @@ static void
>  csched_dump_pcpu(const struct scheduler *ops, int cpu)
>  {
>      struct list_head *runq, *iter;
> +    struct csched_private *prv = CSCHED_PRIV(ops);
>      struct csched_pcpu *spc;
>      struct csched_vcpu *svc;
> +    unsigned long flags;
>      int loop;
>  #define cpustr keyhandler_scratch
>  
> +    /* Domains' parameters are changed under csched_priv lock */
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      spc = CSCHED_PCPU(cpu);
>      runq = &spc->runq;
>  
> @@ -1464,6 +1469,12 @@ csched_dump_pcpu(const struct scheduler 
>      cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
>      printk("core=%s\n", cpustr);
>  
> +    /*
> +     * We need runq lock as well, and as there's one runq per CPU,
> +     * this is the correct one to take for this CPU/runq.
> +     */
> +    pcpu_schedule_lock(cpu);
> +
>      /* current VCPU */
>      svc = CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
>      if ( svc )
> @@ -1482,6 +1493,9 @@ csched_dump_pcpu(const struct scheduler 
>              csched_dump_vcpu(svc);
>          }
>      }
> +
> +    pcpu_schedule_unlock(cpu);
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  #undef cpustr
>  }
>  
> @@ -1493,7 +1507,7 @@ csched_dump(const struct scheduler *ops)
>      int loop;
>      unsigned long flags;
>  
> -    spin_lock_irqsave(&(prv->lock), flags);
> +    spin_lock_irqsave(&prv->lock, flags);
>  
>  #define idlers_buf keyhandler_scratch
>  
> @@ -1537,12 +1551,14 @@ csched_dump(const struct scheduler *ops)
>              svc = list_entry(iter_svc, struct csched_vcpu, active_vcpu_elem);
>  
>              printk("\t%3d: ", ++loop);
> +            vcpu_schedule_lock(svc->vcpu);
>              csched_dump_vcpu(svc);
> +            vcpu_schedule_unlock(svc->vcpu);
>          }
>      }
>  #undef idlers_buf
>  
> -    spin_unlock_irqrestore(&(prv->lock), flags);
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
>  static int
> diff -r 15ab61865ecb xen/common/sched_credit2.c
> --- a/xen/common/sched_credit2.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/common/sched_credit2.c	Wed Jan 18 15:02:30 2012 +0000
> @@ -53,8 +53,6 @@
>   * credit2 wiki page:
>   *  http://wiki.xen.org/wiki/Credit2_Scheduler_Development
>   * TODO:
> - * + Immediate bug-fixes
> - *  - Do per-runqueue, grab proper lock for dump debugkey
>   * + Multiple sockets
>   *  - Detect cpu layout and make runqueue map, one per L2 (make_runq_map())
>   *  - Simple load balancer / runqueue assignment
> @@ -1759,12 +1757,16 @@ csched_dump_vcpu(struct csched_vcpu *svc
>  static void
>  csched_dump_pcpu(const struct scheduler *ops, int cpu)
>  {
> +    struct csched_private *prv = CSCHED_PRIV(ops);
>      struct list_head *runq, *iter;
>      struct csched_vcpu *svc;
> +    unsigned long flags;
> +    spinlock_t *lock;
>      int loop;
>      char cpustr[100];
>  
> -    /* FIXME: Do locking properly for access to runqueue structures */
> +    /* Domains' parameters are changed under csched_priv lock */
> +    spin_lock_irqsave(&prv->lock, flags);
>  
>      runq = &RQD(ops, cpu)->runq;
>  
> @@ -1773,6 +1775,13 @@ csched_dump_pcpu(const struct scheduler 
>      cpumask_scnprintf(cpustr, sizeof(cpustr), per_cpu(cpu_core_mask, cpu));
>      printk("core=%s\n", cpustr);
>  
> +    /*
> +     * We need runq lock as well, and here's how we get to it
> +     * for the requested cpu.
> +     */
> +    lock = per_cpu(schedule_data, cpu).schedule_lock;
> +    spin_lock(lock);
> +
>      /* current VCPU */
>      svc = CSCHED_VCPU(per_cpu(schedule_data, cpu).curr);
>      if ( svc )
> @@ -1791,6 +1800,9 @@ csched_dump_pcpu(const struct scheduler 
>              csched_dump_vcpu(svc);
>          }
>      }
> +
> +    spin_unlock(lock);
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
>  static void
> @@ -1798,8 +1810,11 @@ csched_dump(const struct scheduler *ops)
>  {
>      struct list_head *iter_sdom, *iter_svc;
>      struct csched_private *prv = CSCHED_PRIV(ops);
> +    unsigned long flags;
>      int i, loop;
>  
> +    spin_lock_irqsave(&prv->lock, flags);
> +
>      printk("Active queues: %d\n"
>             "\tdefault-weight     = %d\n",
>             cpumask_weight(&prv->active_queues),
> @@ -1822,7 +1837,6 @@ csched_dump(const struct scheduler *ops)
>                 fraction);
>  
>      }
> -    /* FIXME: Locking! */
>  
>      printk("Domain info:\n");
>      loop = 0;
> @@ -1831,10 +1845,10 @@ csched_dump(const struct scheduler *ops)
>          struct csched_dom *sdom;
>          sdom = list_entry(iter_sdom, struct csched_dom, sdom_elem);
>  
> -       printk("\tDomain: %d w %d v %d\n\t", 
> -              sdom->dom->domain_id, 
> -              sdom->weight, 
> -              sdom->nr_vcpus);
> +        printk("\tDomain: %d w %d v %d\n\t", 
> +               sdom->dom->domain_id, 
> +               sdom->weight, 
> +               sdom->nr_vcpus);
>  
>          list_for_each( iter_svc, &sdom->vcpu )
>          {
> @@ -1842,9 +1856,13 @@ csched_dump(const struct scheduler *ops)
>              svc = list_entry(iter_svc, struct csched_vcpu, sdom_elem);
>  
>              printk("\t%3d: ", ++loop);
> +            vcpu_schedule_lock(svc->vcpu);
>              csched_dump_vcpu(svc);
> +            vcpu_schedule_unlock(svc->vcpu);
>          }
>      }
> +
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
>  static void activate_runqueue(struct csched_private *prv, int rqi)
> diff -r 15ab61865ecb xen/common/sched_sedf.c
> --- a/xen/common/sched_sedf.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/common/sched_sedf.c	Wed Jan 18 15:02:30 2012 +0000
> @@ -1219,13 +1219,25 @@ static void sedf_dump_domain(struct vcpu
>  /* Dumps all domains on the specified cpu */
>  static void sedf_dump_cpu_state(const struct scheduler *ops, int i)
>  {
> +    struct sedf_priv_info *prv = SEDF_PRIV(ops);
>      struct list_head      *list, *queue, *tmp;
>      struct sedf_vcpu_info *d_inf;
>      struct domain         *d;
>      struct vcpu    *ed;
> +    unsigned long flags;
>      int loop = 0;
> +
> +    /* Domains' parameters are changed under scheduler lock */
> +    spin_lock_irqsave(&prv->lock, flags);
>   
>      printk("now=%"PRIu64"\n",NOW());
> +
> +    /*
> +     * We need runq lock as well, and as there's one runq per CPU,
> +     * this is the correct one to take for this CPU/runq.
> +     */
> +    pcpu_schedule_lock(i);
> +
>      queue = RUNQ(i);
>      printk("RUNQ rq %lx   n: %lx, p: %lx\n",  (unsigned long)queue,
>             (unsigned long) queue->next, (unsigned long) queue->prev);
> @@ -1288,6 +1300,9 @@ static void sedf_dump_cpu_state(const st
>          }
>      }
>      rcu_read_unlock(&domlist_read_lock);
> +
> +    pcpu_schedule_unlock(i);
> +    spin_unlock_irqrestore(&prv->lock, flags);
>  }
>  
> 
> diff -r 15ab61865ecb xen/common/schedule.c
> --- a/xen/common/schedule.c	Tue Jan 17 12:40:52 2012 +0000
> +++ b/xen/common/schedule.c	Wed Jan 18 15:02:30 2012 +0000
> @@ -1417,6 +1417,7 @@ void schedule_dump(struct cpupool *c)
>      struct scheduler *sched;
>      cpumask_t        *cpus;
>  
> +    /* Proper locking is provided by each scheduler */
>      sched = (c == NULL) ? &ops : c->sched;
>      cpus = (c == NULL) ? &cpupool_free_cpus : c->cpu_valid;
>      printk("Scheduler: %s (%s)\n", sched->name, sched->opt_name);
> @@ -1424,10 +1425,8 @@ void schedule_dump(struct cpupool *c)
>  
>      for_each_cpu (i, cpus)
>      {
> -        pcpu_schedule_lock(i);
>          printk("CPU[%02d] ", i);
>          SCHED_OP(sched, dump_cpu_state, i);
> -        pcpu_schedule_unlock(i);
>      }
>  }
>  
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:38:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqSLA-0006TQ-Im; Thu, 26 Jan 2012 16:38: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 1RqSL8-0006Sf-Ia
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:38:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327595896!12596887!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19736 invoked from network); 26 Jan 2012 16:38:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 16:38:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327595896; l=703;
	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=9+VXgbzhS43m0T6n7KWq+jvlotc=;
	b=QlTCuCc9cHs4y6vRyGG+a8GiPNIupmmKvaDgZdQxJgA2EACIYORbf+meEdbII6evNKC
	sFqRPkPiAJqmfoAQXozpplD1HlHwcpxXFtyws6yUsnxa3Om0j/ynDe3B/LKe0IrAQ+CEA
	7rcubDzFA54qjSuyhJP+U1U4Mfujr6/BXck=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (fruni mo49) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y04f89o0QFYEI3 ;
	Thu, 26 Jan 2012 17:38:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7E33F18637; Thu, 26 Jan 2012 17:38:10 +0100 (CET)
Date: Thu, 26 Jan 2012 17:38:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126163810.GA9137@aepfle.de>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
	<317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <317844de67b9293a2e45ecd879a1c58a.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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, Andres Lagar-Cavilla wrote:

> Olaf,
> if I get a pattern of errors in the err array of the form:
> 
> {ENOENT, EWHATEVER, ENOENT, EWHATEVER}
> with EWHATEVER != ENOENT
> 
> this patch does not optimize anything.

It will poke all gfns instead of a single one before going to sleep.

> Why not alloc a separate arr2 array, move the gfn's that failed with
> ENOENT there, and retry the whole new arr2 block? You only need to
> allocate arr2 once, to size num. That will batch always, everything.

The errors for gfns are most likely fragmented. Merging the gfns means
they will get a different addr. So the overall layout of arr and err
needs to remain the same.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:38:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqSLA-0006TQ-Im; Thu, 26 Jan 2012 16:38: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 1RqSL8-0006Sf-Ia
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:38:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327595896!12596887!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19736 invoked from network); 26 Jan 2012 16:38:16 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-10.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 16:38:16 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327595896; l=703;
	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=9+VXgbzhS43m0T6n7KWq+jvlotc=;
	b=QlTCuCc9cHs4y6vRyGG+a8GiPNIupmmKvaDgZdQxJgA2EACIYORbf+meEdbII6evNKC
	sFqRPkPiAJqmfoAQXozpplD1HlHwcpxXFtyws6yUsnxa3Om0j/ynDe3B/LKe0IrAQ+CEA
	7rcubDzFA54qjSuyhJP+U1U4Mfujr6/BXck=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (fruni mo49) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id Y04f89o0QFYEI3 ;
	Thu, 26 Jan 2012 17:38:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7E33F18637; Thu, 26 Jan 2012 17:38:10 +0100 (CET)
Date: Thu, 26 Jan 2012 17:38:10 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126163810.GA9137@aepfle.de>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
	<317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <317844de67b9293a2e45ecd879a1c58a.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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, Andres Lagar-Cavilla wrote:

> Olaf,
> if I get a pattern of errors in the err array of the form:
> 
> {ENOENT, EWHATEVER, ENOENT, EWHATEVER}
> with EWHATEVER != ENOENT
> 
> this patch does not optimize anything.

It will poke all gfns instead of a single one before going to sleep.

> Why not alloc a separate arr2 array, move the gfn's that failed with
> ENOENT there, and retry the whole new arr2 block? You only need to
> allocate arr2 once, to size num. That will batch always, everything.

The errors for gfns are most likely fragmented. Merging the gfns means
they will get a different addr. So the overall layout of arr and err
needs to remain the same.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:41:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSOT-0006ha-79; Thu, 26 Jan 2012 16:41:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RqSOR-0006hQ-BI
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:41:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327595976!50195191!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19320 invoked from network); 26 Jan 2012 16:39:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 16:39:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 16:41:46 +0000
Message-Id: <4F2190A2020000780006F49A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 16:42:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <20120126162621.GE80228@ocelot.phlegethon.org>
In-Reply-To: <20120126162621.GE80228@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 17:26, Tim Deegan <tim@xen.org> wrote:
> Hi,
> 
> We seem to have agreement that we can start checking in the Xen 
> ARMv7-with-Virtualization-Extensions patches that Stefano has been
> posting. 
> 
> It's been suggested that Ian Campbell be made a committer for 
> the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
> http://www.xen.org/projects/governance.html, I hereby nominate him.
> 
> Keir, Ian, Jan, please respond with your integer of choice.

+1

> 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 Jan 26 16:41:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:41:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSOT-0006ha-79; Thu, 26 Jan 2012 16:41:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RqSOR-0006hQ-BI
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:41:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327595976!50195191!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19320 invoked from network); 26 Jan 2012 16:39:36 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 16:39:36 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Thu, 26 Jan 2012 16:41:46 +0000
Message-Id: <4F2190A2020000780006F49A@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Thu, 26 Jan 2012 16:42:58 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Tim Deegan" <tim@xen.org>
References: <20120126162621.GE80228@ocelot.phlegethon.org>
In-Reply-To: <20120126162621.GE80228@ocelot.phlegethon.org>
Mime-Version: 1.0
Content-Disposition: inline
Cc: ian.jackson@citrix.com, xen-devel@lists.xensource.com, keir@xen.org,
	Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 17:26, Tim Deegan <tim@xen.org> wrote:
> Hi,
> 
> We seem to have agreement that we can start checking in the Xen 
> ARMv7-with-Virtualization-Extensions patches that Stefano has been
> posting. 
> 
> It's been suggested that Ian Campbell be made a committer for 
> the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
> http://www.xen.org/projects/governance.html, I hereby nominate him.
> 
> Keir, Ian, Jan, please respond with your integer of choice.

+1

> 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 Jan 26 16:42:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSPB-0006lH-KR; Thu, 26 Jan 2012 16:42: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 1RqSPA-0006kt-DY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327596146!12700923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27045 invoked from network); 26 Jan 2012 16:42:26 -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;
	26 Jan 2012 16:42:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10310776"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:42:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 16:42:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 26 Jan 2012 16:42:25 +0000
In-Reply-To: <alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
References: <CB472B9C.38573%keir@xen.org>
	<alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327596145.26983.105.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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 16:29 +0000, Stefano Stabellini wrote:
> 
> Introducing a new hypercall with the same name
> (PHYSDEVOP_pirq_eoi_gmfn_new) is the first step in admitting that the
> old hypercall was a mistake and should not be used. 

If that's the case then there is precedent (e.g. sched_op, physdev_op,
evtchn_op) for renaming the existing thing FOO_compat and taking over
the name with the new semantics.

That's certainly better than _new->_newer->really_new etc. If you must
go down that route then adding a number seems preferable.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:42:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:42:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSPB-0006lH-KR; Thu, 26 Jan 2012 16:42: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 1RqSPA-0006kt-DY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:42:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327596146!12700923!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27045 invoked from network); 26 Jan 2012 16:42:26 -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;
	26 Jan 2012 16:42:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10310776"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:42:25 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 16:42:25 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Thu, 26 Jan 2012 16:42:25 +0000
In-Reply-To: <alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
References: <CB472B9C.38573%keir@xen.org>
	<alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327596145.26983.105.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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 16:29 +0000, Stefano Stabellini wrote:
> 
> Introducing a new hypercall with the same name
> (PHYSDEVOP_pirq_eoi_gmfn_new) is the first step in admitting that the
> old hypercall was a mistake and should not be used. 

If that's the case then there is precedent (e.g. sched_op, physdev_op,
evtchn_op) for renaming the existing thing FOO_compat and taking over
the name with the new semantics.

That's certainly better than _new->_newer->really_new etc. If you must
go down that route then adding a number seems preferable.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:43:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqSQB-0006sL-3d; Thu, 26 Jan 2012 16:43:35 +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 1RqSQ9-0006ro-A7
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:43:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327596206!12150703!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9012 invoked from network); 26 Jan 2012 16:43:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 16:43:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327596206; l=204;
	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=Q0ezez7gKBGDDWkiAoybCf9Z9MQ=;
	b=ISEC2Aqbbt+CX0C27viEjzNXtAtUaHufqFrnPsue83r5N9nmozlCs1cWwSWGHotm7a9
	d8KujtqMMWCGdCZcP9E1pu15Tvtl4ziaLU+CKtg0iqFA142fiu+6MVLSke9p5lyhI+dxC
	laj7T4RwAh2pLRnOYhyYrN08w8NqIPKDCCY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo64) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t01ffeo0QFdprJ ;
	Thu, 26 Jan 2012 17:43:21 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 07D8F18637; Thu, 26 Jan 2012 17:43:23 +0100 (CET)
Date: Thu, 26 Jan 2012 17:43:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <george.dunlap@citrix.com>
Message-ID: <20120126164323.GA9886@aepfle.de>
References: <94f71dded5ab5a31224b.1326376371@probook.site>
	<1327580855.24345.1.camel@elijah>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327580855.24345.1.camel@elijah>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit
	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

On Thu, Jan 26, George Dunlap wrote:

> How about this patch instead?  It makes the base variable "long", so
> that we don't need the extra intermediate cast.

Compiles ok for me.

Thanks.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:43:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqSQB-0006sL-3d; Thu, 26 Jan 2012 16:43:35 +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 1RqSQ9-0006ro-A7
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:43:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327596206!12150703!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9012 invoked from network); 26 Jan 2012 16:43:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-14.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 16:43:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327596206; l=204;
	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=Q0ezez7gKBGDDWkiAoybCf9Z9MQ=;
	b=ISEC2Aqbbt+CX0C27viEjzNXtAtUaHufqFrnPsue83r5N9nmozlCs1cWwSWGHotm7a9
	d8KujtqMMWCGdCZcP9E1pu15Tvtl4ziaLU+CKtg0iqFA142fiu+6MVLSke9p5lyhI+dxC
	laj7T4RwAh2pLRnOYhyYrN08w8NqIPKDCCY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (klopstock mo64) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id t01ffeo0QFdprJ ;
	Thu, 26 Jan 2012 17:43:21 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 07D8F18637; Thu, 26 Jan 2012 17:43:23 +0100 (CET)
Date: Thu, 26 Jan 2012 17:43:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: George Dunlap <george.dunlap@citrix.com>
Message-ID: <20120126164323.GA9886@aepfle.de>
References: <94f71dded5ab5a31224b.1326376371@probook.site>
	<1327580855.24345.1.camel@elijah>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327580855.24345.1.camel@elijah>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit
	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

On Thu, Jan 26, George Dunlap wrote:

> How about this patch instead?  It makes the base variable "long", so
> that we don't need the extra intermediate cast.

Compiles ok for me.

Thanks.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:44:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqSR6-00070K-JR; Thu, 26 Jan 2012 16:44:32 +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 1RqSR4-0006z8-JQ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:44:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327596264!12713966!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23859 invoked from network); 26 Jan 2012 16:44:24 -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;
	26 Jan 2012 16:44:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10310840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:44:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 16:44:24 +0000
Date: Thu, 26 Jan 2012 16:45: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: <1327596145.26983.105.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201261644320.3196@kaball-desktop>
References: <CB472B9C.38573%keir@xen.org>
	<alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
	<1327596145.26983.105.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-26 at 16:29 +0000, Stefano Stabellini wrote:
> > 
> > Introducing a new hypercall with the same name
> > (PHYSDEVOP_pirq_eoi_gmfn_new) is the first step in admitting that the
> > old hypercall was a mistake and should not be used. 
> 
> If that's the case then there is precedent (e.g. sched_op, physdev_op,
> evtchn_op) for renaming the existing thing FOO_compat and taking over
> the name with the new semantics.
> 
> That's certainly better than _new->_newer->really_new etc. If you must
> go down that route then adding a number seems preferable.

In that case, I vote for taking over the existing name with the new
hypercall.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:44:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqSR6-00070K-JR; Thu, 26 Jan 2012 16:44:32 +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 1RqSR4-0006z8-JQ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:44:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327596264!12713966!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23859 invoked from network); 26 Jan 2012 16:44:24 -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;
	26 Jan 2012 16:44:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10310840"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 16:44:23 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 16:44:24 +0000
Date: Thu, 26 Jan 2012 16:45: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: <1327596145.26983.105.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201261644320.3196@kaball-desktop>
References: <CB472B9C.38573%keir@xen.org>
	<alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
	<1327596145.26983.105.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"Keir \(Xen.org\)" <keir@xen.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Ian Campbell wrote:
> On Thu, 2012-01-26 at 16:29 +0000, Stefano Stabellini wrote:
> > 
> > Introducing a new hypercall with the same name
> > (PHYSDEVOP_pirq_eoi_gmfn_new) is the first step in admitting that the
> > old hypercall was a mistake and should not be used. 
> 
> If that's the case then there is precedent (e.g. sched_op, physdev_op,
> evtchn_op) for renaming the existing thing FOO_compat and taking over
> the name with the new semantics.
> 
> That's certainly better than _new->_newer->really_new etc. If you must
> go down that route then adding a number seems preferable.

In that case, I vote for taking over the existing name with the new
hypercall.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:45:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqSRn-00078I-0E; Thu, 26 Jan 2012 16:45:15 +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 1RqSRm-00077M-E1
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:45:14 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327596306!12651334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9935 invoked from network); 26 Jan 2012 16:45:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:45:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179234742"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:45:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 11:45:05 -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 q0QGj3Ce009699;
	Thu, 26 Jan 2012 08:45:04 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120126164323.GA9886@aepfle.de>
References: <94f71dded5ab5a31224b.1326376371@probook.site>
	<1327580855.24345.1.camel@elijah>  <20120126164323.GA9886@aepfle.de>
Date: Thu, 26 Jan 2012 16:45:03 +0000
Message-ID: <1327596303.24345.64.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit
	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

OK, I've applied it.
 -George

On Thu, 2012-01-26 at 16:43 +0000, Olaf Hering wrote:
> On Thu, Jan 26, George Dunlap wrote:
> 
> > How about this patch instead?  It makes the base variable "long", so
> > that we don't need the extra intermediate cast.
> 
> Compiles ok for me.
> 
> Thanks.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:45:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16: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 1RqSRn-00078I-0E; Thu, 26 Jan 2012 16:45:15 +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 1RqSRm-00077M-E1
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:45:14 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327596306!12651334!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9935 invoked from network); 26 Jan 2012 16:45:08 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:45:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179234742"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:45:06 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 11:45:05 -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 q0QGj3Ce009699;
	Thu, 26 Jan 2012 08:45:04 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
In-Reply-To: <20120126164323.GA9886@aepfle.de>
References: <94f71dded5ab5a31224b.1326376371@probook.site>
	<1327580855.24345.1.camel@elijah>  <20120126164323.GA9886@aepfle.de>
Date: Thu, 26 Jan 2012 16:45:03 +0000
Message-ID: <1327596303.24345.64.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] xenalyze: add missing casts to fix 64bit
	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

OK, I've applied it.
 -George

On Thu, 2012-01-26 at 16:43 +0000, Olaf Hering wrote:
> On Thu, Jan 26, George Dunlap wrote:
> 
> > How about this patch instead?  It makes the base variable "long", so
> > that we don't need the extra intermediate cast.
> 
> Compiles ok for me.
> 
> Thanks.
> 
> Olaf



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:55:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:55:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSbN-0007tD-8R; Thu, 26 Jan 2012 16:55:09 +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 1RqSbL-0007t8-LF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:55:07 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327596900!3789116!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17765 invoked from network); 26 Jan 2012 16:55:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:55:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21314133"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:54:59 -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, 26 Jan 2012 11:54:59 -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 q0QGsulx009711;
	Thu, 26 Jan 2012 08:54:57 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
Date: Thu, 26 Jan 2012 16:54:56 +0000
Message-ID: <1327596896.24345.66.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> x86's vMCE implementation lets a guest know of as many MCE reporting
> >> banks as there are in the host. While a PV guest could be expected to
> >> deal with this number changing (particularly decreasing) during migration
> >> (not currently handled anywhere afaict), for HVM guests this is certainly
> >> wrong.
> >>
> >> At least to me it isn't, however, clear how to properly handle this. The
> >> easiest would appear to be to save and restore the number of banks
> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
> >> silently tolerate accesses between the host and guest values.
> > 
> > We ran into this in the XS 6.0 release as well.  I think that the
> > ideal thing to do would be to have a parameter that can be set at
> > boot, to say how many vMCE banks a guest has, defaulting to the number
> > of MCE banks on the host.  This parameter would be preserved across
> > migration.  Ideally, a pool-aware toolstack like xapi would then set
> > this value to be the value of the host in the pool with the largest
> > number of banks, allowing a guest to access all the banks on any host
> > to which it migrates.
> > 
> > What do you think?
> 
> That sounds like the way to go.

So should we put this on IanC's to-do-be-done list?  Are you going to
put it on your to-do list? :-)

 -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:55:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:55:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSbN-0007tD-8R; Thu, 26 Jan 2012 16:55:09 +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 1RqSbL-0007t8-LF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:55:07 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327596900!3789116!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17765 invoked from network); 26 Jan 2012 16:55:01 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 16:55:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21314133"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 11:54:59 -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, 26 Jan 2012 11:54:59 -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 q0QGsulx009711;
	Thu, 26 Jan 2012 08:54:57 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
Date: Thu, 26 Jan 2012 16:54:56 +0000
Message-ID: <1327596896.24345.66.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> x86's vMCE implementation lets a guest know of as many MCE reporting
> >> banks as there are in the host. While a PV guest could be expected to
> >> deal with this number changing (particularly decreasing) during migration
> >> (not currently handled anywhere afaict), for HVM guests this is certainly
> >> wrong.
> >>
> >> At least to me it isn't, however, clear how to properly handle this. The
> >> easiest would appear to be to save and restore the number of banks
> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
> >> silently tolerate accesses between the host and guest values.
> > 
> > We ran into this in the XS 6.0 release as well.  I think that the
> > ideal thing to do would be to have a parameter that can be set at
> > boot, to say how many vMCE banks a guest has, defaulting to the number
> > of MCE banks on the host.  This parameter would be preserved across
> > migration.  Ideally, a pool-aware toolstack like xapi would then set
> > this value to be the value of the host in the pool with the largest
> > number of banks, allowing a guest to access all the banks on any host
> > to which it migrates.
> > 
> > What do you think?
> 
> That sounds like the way to go.

So should we put this on IanC's to-do-be-done list?  Are you going to
put it on your to-do list? :-)

 -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:56:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqScJ-0007w1-NK; Thu, 26 Jan 2012 16:56:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RqScI-0007vp-4e
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:56:06 +0000
Received: from [85.158.138.51:13254] by server-7.bemta-3.messagelabs.com id
	9F/17-31267-5A5812F4; Thu, 26 Jan 2012 16:56:05 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327596963!10817596!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3501 invoked from network); 26 Jan 2012 16:56:04 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 16:56:04 -0000
Received: from [213.136.143.192] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75049635; Thu, 26 Jan 2012 17:56:03 +0100
Message-ID: <1327596957.16090.24.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@citrix.com>
Date: Thu, 26 Jan 2012 17:55:57 +0100
In-Reply-To: <1327595839.24345.63.camel@elijah>
References: <1326903221.5856.33.camel@Solace>
	<1326903894.5856.35.camel@Solace> <1327595839.24345.63.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>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1] sched: rework locking for dump
	debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0193462394970281978=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0193462394970281978==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IZzNQlmZXYnAF4nVPYqj"


--=-IZzNQlmZXYnAF4nVPYqj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-01-26 at 16:37 +0000, George Dunlap wrote:=20
> On Wed, 2012-01-18 at 16:24 +0000, Dario Faggioli wrote:
> > As in all other paths, locking should be dealt with in the
> > specific schedulers, not in schedule.c.
>=20
> I think this looks right. =20
>
Glad to hear that. :-)

> But you should probably add a comment at the
> top of credit1 and sedf to say that now the locking order must be
> private -> schedule, to avoid deadlock.
>=20
Right, will do.

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-IZzNQlmZXYnAF4nVPYqj
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)

iEYEABECAAYFAk8hhZ0ACgkQk4XaBE3IOsSxMwCeKKUpGzOKx8siHTj1c3oKOsRj
AUUAoJfibXg6PsX+Db6FHH2ONWcSSJf8
=VvZ6
-----END PGP SIGNATURE-----

--=-IZzNQlmZXYnAF4nVPYqj--



--===============0193462394970281978==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0193462394970281978==--



From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:56:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:56:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqScJ-0007w1-NK; Thu, 26 Jan 2012 16:56:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <raistlin@linux.it>) id 1RqScI-0007vp-4e
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:56:06 +0000
Received: from [85.158.138.51:13254] by server-7.bemta-3.messagelabs.com id
	9F/17-31267-5A5812F4; Thu, 26 Jan 2012 16:56:05 +0000
X-Env-Sender: raistlin@linux.it
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327596963!10817596!1
X-Originating-IP: [193.205.80.99]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3501 invoked from network); 26 Jan 2012 16:56:04 -0000
Received: from ms01.sssup.it (HELO sssup.it) (193.205.80.99)
	by server-11.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 16:56:04 -0000
Received: from [213.136.143.192] (account d.faggioli@sssup.it HELO
	[192.168.0.20]) by sssup.it (CommuniGate Pro SMTP 5.3.14)
	with ESMTPSA id 75049635; Thu, 26 Jan 2012 17:56:03 +0100
Message-ID: <1327596957.16090.24.camel@Abyss>
From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@citrix.com>
Date: Thu, 26 Jan 2012 17:55:57 +0100
In-Reply-To: <1327595839.24345.63.camel@elijah>
References: <1326903221.5856.33.camel@Solace>
	<1326903894.5856.35.camel@Solace> <1327595839.24345.63.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>,
	"Keir \(Xen.org\)" <keir@xen.org>
Subject: Re: [Xen-devel] [PATCH 1 of 1] sched: rework locking for dump
	debugkey.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0193462394970281978=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


--===============0193462394970281978==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-IZzNQlmZXYnAF4nVPYqj"


--=-IZzNQlmZXYnAF4nVPYqj
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2012-01-26 at 16:37 +0000, George Dunlap wrote:=20
> On Wed, 2012-01-18 at 16:24 +0000, Dario Faggioli wrote:
> > As in all other paths, locking should be dealt with in the
> > specific schedulers, not in schedule.c.
>=20
> I think this looks right. =20
>
Glad to hear that. :-)

> But you should probably add a comment at the
> top of credit1 and sedf to say that now the locking order must be
> private -> schedule, to avoid deadlock.
>=20
Right, will do.

Thanks,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=-IZzNQlmZXYnAF4nVPYqj
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)

iEYEABECAAYFAk8hhZ0ACgkQk4XaBE3IOsSxMwCeKKUpGzOKx8siHTj1c3oKOsRj
AUUAoJfibXg6PsX+Db6FHH2ONWcSSJf8
=VvZ6
-----END PGP SIGNATURE-----

--=-IZzNQlmZXYnAF4nVPYqj--



--===============0193462394970281978==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0193462394970281978==--



From xen-devel-bounces@lists.xensource.com Thu Jan 26 16:58:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSeG-00086J-Ej; Thu, 26 Jan 2012 16:58: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 1RqSeF-000862-GF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:58:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327597036!51720627!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzA4NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22982 invoked from network); 26 Jan 2012 16:57:16 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-6.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 16:57:16 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 9048276C073;
	Thu, 26 Jan 2012 08:58:02 -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=HtGoByYC3DUn5EVK6aR9/hSLl2ey1SUBAPZrNwP/ka98
	D6i9WcdOWUUBaidjOmxIKXJrKc13AR7ekuoNW5AOSs+m3DCx2mdUPPp8BHQZDCsc
	V691eXv/mI/c13ZuWgoQh8DUAdTSvrUxMA//6rtSnsIjr/nA74DFhYjOTcfL5KU=
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=fz2BzJRAtlejIj4CvAMzNy8nsqg=; b=ZyUuJJSU
	499Pu1bGc6cMQc4yzoR1VvBg0gDTmh+YcSYYG3Gi3t8t7eGziojfSpgxLiMT+MSC
	UVizNIafXtNxu30ZK/lIDmFDxGTUCVU5TRPOIBdrmuvi9rzDR1b3RvyYljft94I7
	nkdC8MM4/rsswKppyQjgC50mLmwibI/A9Qw=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 3BC5176C072; 
	Thu, 26 Jan 2012 08:58:02 -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, 26 Jan 2012 08:58:02 -0800
Message-ID: <55d685d4f7e551ab7c854c509a63f895.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126163810.GA9137@aepfle.de>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
	<317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
	<20120126163810.GA9137@aepfle.de>
Date: Thu, 26 Jan 2012 08:58:02 -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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
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, Jan 26, Andres Lagar-Cavilla wrote:
>
>> Olaf,
>> if I get a pattern of errors in the err array of the form:
>>
>> {ENOENT, EWHATEVER, ENOENT, EWHATEVER}
>> with EWHATEVER != ENOENT
>>
>> this patch does not optimize anything.
>
> It will poke all gfns instead of a single one before going to sleep.

All gfns that are contiguous in the arr array and have all failed with
ENOENT.

>
>> Why not alloc a separate arr2 array, move the gfn's that failed with
>> ENOENT there, and retry the whole new arr2 block? You only need to
>> allocate arr2 once, to size num. That will batch always, everything.
>
> The errors for gfns are most likely fragmented. Merging the gfns means
> they will get a different addr. So the overall layout of arr and err
> needs to remain the same.

Ummh yeah, addr is the problem. But as you say, the error for the gfns are
fragmented, so that seriously limits your batching abilities.

You could pass the whole arr sub-segment encompassing the first and last
gfn that failed with ENOENT. Successful maps within that array will be
re-done by the hypervisor, at no correctness cost. I would imagine that
the extra work is offset by the gains, but that remains to be seen.

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 Jan 26 16:58:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 16:58:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqSeG-00086J-Ej; Thu, 26 Jan 2012 16:58: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 1RqSeF-000862-GF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 16:58:07 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327597036!51720627!1
X-Originating-IP: [208.97.132.66]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi42NiA9PiAxNzA4NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22982 invoked from network); 26 Jan 2012 16:57:16 -0000
Received: from caiajhbdcagg.dreamhost.com (HELO homiemail-a15.g.dreamhost.com)
	(208.97.132.66) by server-6.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 16:57:16 -0000
Received: from homiemail-a15.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTP id 9048276C073;
	Thu, 26 Jan 2012 08:58:02 -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=HtGoByYC3DUn5EVK6aR9/hSLl2ey1SUBAPZrNwP/ka98
	D6i9WcdOWUUBaidjOmxIKXJrKc13AR7ekuoNW5AOSs+m3DCx2mdUPPp8BHQZDCsc
	V691eXv/mI/c13ZuWgoQh8DUAdTSvrUxMA//6rtSnsIjr/nA74DFhYjOTcfL5KU=
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=fz2BzJRAtlejIj4CvAMzNy8nsqg=; b=ZyUuJJSU
	499Pu1bGc6cMQc4yzoR1VvBg0gDTmh+YcSYYG3Gi3t8t7eGziojfSpgxLiMT+MSC
	UVizNIafXtNxu30ZK/lIDmFDxGTUCVU5TRPOIBdrmuvi9rzDR1b3RvyYljft94I7
	nkdC8MM4/rsswKppyQjgC50mLmwibI/A9Qw=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a15.g.dreamhost.com (Postfix) with ESMTPA id 3BC5176C072; 
	Thu, 26 Jan 2012 08:58:02 -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, 26 Jan 2012 08:58:02 -0800
Message-ID: <55d685d4f7e551ab7c854c509a63f895.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20120126163810.GA9137@aepfle.de>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
	<317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
	<20120126163810.GA9137@aepfle.de>
Date: Thu, 26 Jan 2012 08:58:02 -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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
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, Jan 26, Andres Lagar-Cavilla wrote:
>
>> Olaf,
>> if I get a pattern of errors in the err array of the form:
>>
>> {ENOENT, EWHATEVER, ENOENT, EWHATEVER}
>> with EWHATEVER != ENOENT
>>
>> this patch does not optimize anything.
>
> It will poke all gfns instead of a single one before going to sleep.

All gfns that are contiguous in the arr array and have all failed with
ENOENT.

>
>> Why not alloc a separate arr2 array, move the gfn's that failed with
>> ENOENT there, and retry the whole new arr2 block? You only need to
>> allocate arr2 once, to size num. That will batch always, everything.
>
> The errors for gfns are most likely fragmented. Merging the gfns means
> they will get a different addr. So the overall layout of arr and err
> needs to remain the same.

Ummh yeah, addr is the problem. But as you say, the error for the gfns are
fragmented, so that seriously limits your batching abilities.

You could pass the whole arr sub-segment encompassing the first and last
gfn that failed with ENOENT. Successful maps within that array will be
re-done by the hypervisor, at no correctness cost. I would imagine that
the extra work is offset by the gains, but that remains to be seen.

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 Jan 26 17:02:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqSiP-0008Nc-5H; Thu, 26 Jan 2012 17:02:25 +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 1RqSiN-0008NV-VK
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:02:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327597337!8843880!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16695 invoked from network); 26 Jan 2012 17:02:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 17:02:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327597337; l=987;
	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=gJJsfTnebaWzSgH9IHn7N2aWcC4=;
	b=Fkxh4rWnaqLhYipoG+Is3K8tQ/U7F5MPpNE3WDEf0Q11NxLmQ0GXYKZ/ZP4pmAhrO3+
	txV0aGdhBlv85UtB07xOiKpMeo7jUCRm6S2IqvcrPmk6KUaa88tIKbrJ7TZ2DDBTHrAtW
	+zZPzCCm3EzQB/q2xm9dPJ+bGgxUE6zPOfY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (fruni mo40) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L049b4o0QGtKp4 ;
	Thu, 26 Jan 2012 18:02:15 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id AB5B218637; Thu, 26 Jan 2012 18:02:17 +0100 (CET)
Date: Thu, 26 Jan 2012 18:02:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126170217.GA13007@aepfle.de>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
	<317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
	<20120126163810.GA9137@aepfle.de>
	<55d685d4f7e551ab7c854c509a63f895.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <55d685d4f7e551ab7c854c509a63f895.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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, Andres Lagar-Cavilla wrote:

> >> Why not alloc a separate arr2 array, move the gfn's that failed with
> >> ENOENT there, and retry the whole new arr2 block? You only need to
> >> allocate arr2 once, to size num. That will batch always, everything.
> >
> > The errors for gfns are most likely fragmented. Merging the gfns means
> > they will get a different addr. So the overall layout of arr and err
> > needs to remain the same.
> 
> Ummh yeah, addr is the problem. But as you say, the error for the gfns are
> fragmented, so that seriously limits your batching abilities.
 
> You could pass the whole arr sub-segment encompassing the first and last
> gfn that failed with ENOENT. Successful maps within that array will be
> re-done by the hypervisor, at no correctness cost. I would imagine that
> the extra work is offset by the gains, but that remains to be seen.

Isnt that what the patch does, find a range of ENOENTs and try that
again?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:02:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqSiP-0008Nc-5H; Thu, 26 Jan 2012 17:02:25 +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 1RqSiN-0008NV-VK
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:02:24 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327597337!8843880!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16695 invoked from network); 26 Jan 2012 17:02:18 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 26 Jan 2012 17:02:18 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327597337; l=987;
	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=gJJsfTnebaWzSgH9IHn7N2aWcC4=;
	b=Fkxh4rWnaqLhYipoG+Is3K8tQ/U7F5MPpNE3WDEf0Q11NxLmQ0GXYKZ/ZP4pmAhrO3+
	txV0aGdhBlv85UtB07xOiKpMeo7jUCRm6S2IqvcrPmk6KUaa88tIKbrJ7TZ2DDBTHrAtW
	+zZPzCCm3EzQB/q2xm9dPJ+bGgxUE6zPOfY=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (fruni mo40) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L049b4o0QGtKp4 ;
	Thu, 26 Jan 2012 18:02:15 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id AB5B218637; Thu, 26 Jan 2012 18:02:17 +0100 (CET)
Date: Thu, 26 Jan 2012 18:02:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120126170217.GA13007@aepfle.de>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
	<317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
	<20120126163810.GA9137@aepfle.de>
	<55d685d4f7e551ab7c854c509a63f895.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <55d685d4f7e551ab7c854c509a63f895.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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, Andres Lagar-Cavilla wrote:

> >> Why not alloc a separate arr2 array, move the gfn's that failed with
> >> ENOENT there, and retry the whole new arr2 block? You only need to
> >> allocate arr2 once, to size num. That will batch always, everything.
> >
> > The errors for gfns are most likely fragmented. Merging the gfns means
> > they will get a different addr. So the overall layout of arr and err
> > needs to remain the same.
> 
> Ummh yeah, addr is the problem. But as you say, the error for the gfns are
> fragmented, so that seriously limits your batching abilities.
 
> You could pass the whole arr sub-segment encompassing the first and last
> gfn that failed with ENOENT. Successful maps within that array will be
> re-done by the hypervisor, at no correctness cost. I would imagine that
> the extra work is offset by the gains, but that remains to be seen.

Isnt that what the patch does, find a range of ENOENTs and try that
again?

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:09:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqSol-00006V-5A; Thu, 26 Jan 2012 17:08:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RqSok-00006Q-27
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:08:58 +0000
Received: from [85.158.138.51:32351] by server-8.bemta-3.messagelabs.com id
	DB/EE-31878-9A8812F4; Thu, 26 Jan 2012 17:08:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327597734!8953785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16903 invoked from network); 26 Jan 2012 17:08:56 -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;
	26 Jan 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315174"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:08:54 -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, 26 Jan 2012
	12:08:53 -0500
Message-ID: <4F2188A4.50506@citrix.com>
Date: Thu, 26 Jan 2012 17:08:52 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------060203090201060809080405"
Cc: Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] vesa: flush lfb when releasing VGA 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

--------------060203090201060809080405
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit



--------------060203090201060809080405
Content-Type: text/x-patch; name="vesa-endboot-flush.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="vesa-endboot-flush.patch"

# HG changeset patch
# Parent a2a8089b1ffbf5757ca3191cb8f74a5f1ed7fed1
vesa: flush lfb after zeroing

If Xen is going to relinquish the VGA console, flush the linear frame
buffer after zeroing it in vesa_endboot().

Failing to do so in some circumstances leads to the actual linear
framebuffer on the graphics card still containing the output of the
Xen boot console can lead to ugly graphics output when dom0 is setting
up the graphics card for its own use.

While the patch is quite large, it is mostly just code motion to
prevent having to forward declare lfb_flush().  The only functional
change to vesa_endboot() is to insert a call to lbf_flush().

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a2a8089b1ffb xen/drivers/video/vesa.c
--- a/xen/drivers/video/vesa.c
+++ b/xen/drivers/video/vesa.c
@@ -151,24 +151,6 @@ void __init vesa_init(void)
     xfree(line_len);
 }
 
-void __init vesa_endboot(bool_t keep)
-{
-    if ( keep )
-    {
-        xpos = 0;
-        vga_puts = vesa_scroll_puts;
-    }
-    else
-    {
-        unsigned int i, bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
-        for ( i = 0; i < vlfb_info.height; i++ )
-            memset(lfb + i * vlfb_info.bytes_per_line, 0,
-                   vlfb_info.width * bpp);
-    }
-
-    xfree(line_len);
-}
-
 #if defined(CONFIG_X86)
 
 #include <asm/mtrr.h>
@@ -215,6 +197,25 @@ static void lfb_flush(void)
 
 #endif
 
+void __init vesa_endboot(bool_t keep)
+{
+    if ( keep )
+    {
+        xpos = 0;
+        vga_puts = vesa_scroll_puts;
+    }
+    else
+    {
+        unsigned int i, bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
+        for ( i = 0; i < vlfb_info.height; i++ )
+            memset(lfb + i * vlfb_info.bytes_per_line, 0,
+                   vlfb_info.width * bpp);
+        lfb_flush();
+    }
+
+    xfree(line_len);
+}
+
 /* Render one line of text to given linear framebuffer line. */
 static void vesa_show_line(
     const unsigned char *text_line,

--------------060203090201060809080405
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060203090201060809080405--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:09:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqSol-00006V-5A; Thu, 26 Jan 2012 17:08:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Andrew.Cooper3@citrix.com>) id 1RqSok-00006Q-27
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:08:58 +0000
Received: from [85.158.138.51:32351] by server-8.bemta-3.messagelabs.com id
	DB/EE-31878-9A8812F4; Thu, 26 Jan 2012 17:08:57 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327597734!8953785!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16903 invoked from network); 26 Jan 2012 17:08:56 -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;
	26 Jan 2012 17:08:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315174"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:08:54 -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, 26 Jan 2012
	12:08:53 -0500
Message-ID: <4F2188A4.50506@citrix.com>
Date: Thu, 26 Jan 2012 17:08:52 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/mixed; boundary="------------060203090201060809080405"
Cc: Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] vesa: flush lfb when releasing VGA 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

--------------060203090201060809080405
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit



--------------060203090201060809080405
Content-Type: text/x-patch; name="vesa-endboot-flush.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="vesa-endboot-flush.patch"

# HG changeset patch
# Parent a2a8089b1ffbf5757ca3191cb8f74a5f1ed7fed1
vesa: flush lfb after zeroing

If Xen is going to relinquish the VGA console, flush the linear frame
buffer after zeroing it in vesa_endboot().

Failing to do so in some circumstances leads to the actual linear
framebuffer on the graphics card still containing the output of the
Xen boot console can lead to ugly graphics output when dom0 is setting
up the graphics card for its own use.

While the patch is quite large, it is mostly just code motion to
prevent having to forward declare lfb_flush().  The only functional
change to vesa_endboot() is to insert a call to lbf_flush().

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff -r a2a8089b1ffb xen/drivers/video/vesa.c
--- a/xen/drivers/video/vesa.c
+++ b/xen/drivers/video/vesa.c
@@ -151,24 +151,6 @@ void __init vesa_init(void)
     xfree(line_len);
 }
 
-void __init vesa_endboot(bool_t keep)
-{
-    if ( keep )
-    {
-        xpos = 0;
-        vga_puts = vesa_scroll_puts;
-    }
-    else
-    {
-        unsigned int i, bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
-        for ( i = 0; i < vlfb_info.height; i++ )
-            memset(lfb + i * vlfb_info.bytes_per_line, 0,
-                   vlfb_info.width * bpp);
-    }
-
-    xfree(line_len);
-}
-
 #if defined(CONFIG_X86)
 
 #include <asm/mtrr.h>
@@ -215,6 +197,25 @@ static void lfb_flush(void)
 
 #endif
 
+void __init vesa_endboot(bool_t keep)
+{
+    if ( keep )
+    {
+        xpos = 0;
+        vga_puts = vesa_scroll_puts;
+    }
+    else
+    {
+        unsigned int i, bpp = (vlfb_info.bits_per_pixel + 7) >> 3;
+        for ( i = 0; i < vlfb_info.height; i++ )
+            memset(lfb + i * vlfb_info.bytes_per_line, 0,
+                   vlfb_info.width * bpp);
+        lfb_flush();
+    }
+
+    xfree(line_len);
+}
+
 /* Render one line of text to given linear framebuffer line. */
 static void vesa_show_line(
     const unsigned char *text_line,

--------------060203090201060809080405
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--------------060203090201060809080405--


From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:14:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqStR-0000Fd-U8; Thu, 26 Jan 2012 17:13:49 +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 1RqStQ-0000FR-Ck
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:13:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327598022!12686735!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17698 invoked from network); 26 Jan 2012 17:13:42 -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;
	26 Jan 2012 17:13:42 -0000
Received: by wgbdt11 with SMTP id dt11so768859wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 09:13:41 -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=LCZFHHijZ+w5E6KZx7MvQLjrXvX4mgTsuaaXY828PzY=;
	b=IXjNTpJttFTqWvR8FwoeIO4WOMXjkH2LL7IN7RdF+0/ICm+XE4eskDUZO/4zdPUVOB
	E/+65A427uJwyOSrJEut/i11FJhK6pYTbStX+feEBpY65UljCUGZ2fmftBzZmOXc2wyC
	v4h0SWNmFThX46lTePsgAws6SaeZaxvTpI1m4=
Received: by 10.180.81.66 with SMTP id y2mr5089452wix.20.1327598021949;
	Thu, 26 Jan 2012 09:13:41 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l8sm14506068wiy.5.2012.01.26.09.13.40
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 09:13:41 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 17:13:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB473A40.29ABD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
Thread-Index: AczcTda5UFbTAGgFxE+3KlMGChHubw==
In-Reply-To: <alpine.DEB.2.00.1201261644320.3196@kaball-desktop>
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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 16:45, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

>> If that's the case then there is precedent (e.g. sched_op, physdev_op,
>> evtchn_op) for renaming the existing thing FOO_compat and taking over
>> the name with the new semantics.
>> 
>> That's certainly better than _new->_newer->really_new etc. If you must
>> go down that route then adding a number seems preferable.
> 
> In that case, I vote for taking over the existing name with the new
> hypercall.

Agreed, but you have to be careful because other codebases expect to be able
to sync with our public headers without subtle side effects.

The correct thing to do here is probably to rename the old command to
PHYSDEVOP_pirq_eoi_gmfn_v1, and your new one ..._v2.

Then you bump XEN_LATEST_INTERFACE_VERSION to 0x00040200 (somewhat
arbitrarily!), and at the end of physdev.h you put something like:
#if __XEN_INTERFACE_VERSION < 0x00040200
#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
#else
#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
#endif

Perfect, those who want the explicitly versioned command can use it. Old
codebases can sync with new headers safely. Or codebases can be updated for
latest XEN_INTERFACE_VERSION and default to the latest sanest command
versions.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:14:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:14:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqStR-0000Fd-U8; Thu, 26 Jan 2012 17:13:49 +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 1RqStQ-0000FR-Ck
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:13:48 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327598022!12686735!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17698 invoked from network); 26 Jan 2012 17:13:42 -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;
	26 Jan 2012 17:13:42 -0000
Received: by wgbdt11 with SMTP id dt11so768859wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 09:13:41 -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=LCZFHHijZ+w5E6KZx7MvQLjrXvX4mgTsuaaXY828PzY=;
	b=IXjNTpJttFTqWvR8FwoeIO4WOMXjkH2LL7IN7RdF+0/ICm+XE4eskDUZO/4zdPUVOB
	E/+65A427uJwyOSrJEut/i11FJhK6pYTbStX+feEBpY65UljCUGZ2fmftBzZmOXc2wyC
	v4h0SWNmFThX46lTePsgAws6SaeZaxvTpI1m4=
Received: by 10.180.81.66 with SMTP id y2mr5089452wix.20.1327598021949;
	Thu, 26 Jan 2012 09:13:41 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id l8sm14506068wiy.5.2012.01.26.09.13.40
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 09:13:41 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 17:13:36 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <CB473A40.29ABD%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
Thread-Index: AczcTda5UFbTAGgFxE+3KlMGChHubw==
In-Reply-To: <alpine.DEB.2.00.1201261644320.3196@kaball-desktop>
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>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 16:45, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

>> If that's the case then there is precedent (e.g. sched_op, physdev_op,
>> evtchn_op) for renaming the existing thing FOO_compat and taking over
>> the name with the new semantics.
>> 
>> That's certainly better than _new->_newer->really_new etc. If you must
>> go down that route then adding a number seems preferable.
> 
> In that case, I vote for taking over the existing name with the new
> hypercall.

Agreed, but you have to be careful because other codebases expect to be able
to sync with our public headers without subtle side effects.

The correct thing to do here is probably to rename the old command to
PHYSDEVOP_pirq_eoi_gmfn_v1, and your new one ..._v2.

Then you bump XEN_LATEST_INTERFACE_VERSION to 0x00040200 (somewhat
arbitrarily!), and at the end of physdev.h you put something like:
#if __XEN_INTERFACE_VERSION < 0x00040200
#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
#else
#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
#endif

Perfect, those who want the explicitly versioned command can use it. Old
codebases can sync with new headers safely. Or codebases can be updated for
latest XEN_INTERFACE_VERSION and default to the latest sanest command
versions.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:14:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:14:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqStk-0000H0-BR; Thu, 26 Jan 2012 17:14:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqStj-0000Gp-Pi
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:14:07 +0000
Received: from [85.158.138.51:9464] by server-9.bemta-3.messagelabs.com id
	17/4D-31168-FD9812F4; Thu, 26 Jan 2012 17:14:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327597999!8954385!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28335 invoked from network); 26 Jan 2012 17:13:20 -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;
	26 Jan 2012 17:13:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17: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; Thu, 26 Jan 2012 17:12:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqSsY-0001Z7-Dp; Thu, 26 Jan 2012 17:12:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqSsX-0007Me-H1;
	Thu, 26 Jan 2012 17:12:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.35220.805676.300538@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:12:52 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120126162621.GE80228@ocelot.phlegethon.org>
References: <20120126162621.GE80228@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan writes ("Proposed new committer for ARMv7+VE"):
> We seem to have agreement that we can start checking in the Xen 
> ARMv7-with-Virtualization-Extensions patches that Stefano has been
> posting. 
> 
> It's been suggested that Ian Campbell be made a committer for 
> the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
> http://www.xen.org/projects/governance.html, I hereby nominate him.
> 
> Keir, Ian, Jan, please respond with your integer of choice.

Sounds good to me.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:14:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:14:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqStk-0000H0-BR; Thu, 26 Jan 2012 17:14:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqStj-0000Gp-Pi
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:14:07 +0000
Received: from [85.158.138.51:9464] by server-9.bemta-3.messagelabs.com id
	17/4D-31168-FD9812F4; Thu, 26 Jan 2012 17:14:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327597999!8954385!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28335 invoked from network); 26 Jan 2012 17:13:20 -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;
	26 Jan 2012 17:13:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311787"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17: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; Thu, 26 Jan 2012 17:12:54 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqSsY-0001Z7-Dp; Thu, 26 Jan 2012 17:12:54 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqSsX-0007Me-H1;
	Thu, 26 Jan 2012 17:12:54 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.35220.805676.300538@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:12:52 +0000
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120126162621.GE80228@ocelot.phlegethon.org>
References: <20120126162621.GE80228@ocelot.phlegethon.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Keir
	\(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Tim Deegan writes ("Proposed new committer for ARMv7+VE"):
> We seem to have agreement that we can start checking in the Xen 
> ARMv7-with-Virtualization-Extensions patches that Stefano has been
> posting. 
> 
> It's been suggested that Ian Campbell be made a committer for 
> the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
> http://www.xen.org/projects/governance.html, I hereby nominate him.
> 
> Keir, Ian, Jan, please respond with your integer of choice.

Sounds good to me.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:14:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqSu7-0000Jp-P6; Thu, 26 Jan 2012 17:14:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqSu6-0000Jf-M7
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:14:30 +0000
Received: from [85.158.139.83:6701] by server-8.bemta-5.messagelabs.com id
	CB/19-31172-5F9812F4; Thu, 26 Jan 2012 17:14:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327598068!12470724!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2495 invoked from network); 26 Jan 2012 17:14:29 -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;
	26 Jan 2012 17:14:29 -0000
Received: by wgbdt11 with SMTP id dt11so769751wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 09:14:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HX4b7xOgRTIRyWR9VlDpUExZ/EDA2tackVPRfdJDYXs=;
	b=nOzuSqOgm+SWBSsDfwrG8bVNaIKLktcddcrI6sSovh9VJSiXlh/e1y2iYr99IYSbgg
	7cDf4V/LHpDhBq3idJqOJ7SAhcvtqX/+RyZSHW564mpWG76tFXtfIzxhCa7/b64R3G3c
	MJNbStzwHC4YGgtnbW6R2lRCAjlj1dqfb/FYQ=
Received: by 10.180.103.97 with SMTP id fv1mr5169763wib.17.1327598068314;
	Thu, 26 Jan 2012 09:14:28 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id m8sm14446326wia.11.2012.01.26.09.14.26
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 09:14:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 17:14:24 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <CB473A70.29ABE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
Thread-Index: AczcTfNWfkK50wbtw0+NIaNxvKt3KQ==
In-Reply-To: <alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 16:29, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> On Thu, 26 Jan 2012, Keir Fraser wrote:
>> On 26/01/2012 15:49, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
>> wrote:
>> 
>>> PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
>>> Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
>>> PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
>>> hypercall.
>> 
>> It's nasty that pirq_eoi_gmfn has the side effect. I suggest add a PHYSDEVOP
>> to explicitly enable/disable unmask-on-eoi (i.e., the command accepts a
>> boolean parameter). Once it is explicitly enabled/disabled in this way,
>> pirq_eoi_gmfn no longer has the side effect (regardless of whether it is
>> called before or after the explicit setting). So e.g., pv_domain.auto_unmask
>> becomes an int where 0/1 means no/yes, and -1 means default (i.e., old
>> behavour where it depends on whether PHYSDEVOP_pirq_eoi_gmfn has been
>> called).
>> 
>> This seems to me to move a bad interface in a better direction.
> 
> The problem with this approach is that by default we have an hypercall
> (PHYSDEVOP_pirq_eoi_gmfn) changing the behaviour of another one
> (PHYSDEVOP_eoi). Not only this but we have an hypercall
> (PHYSDEVOP_pirq_eoi_gmfn) violating the public interface of shared_info
> as documented in public/xen.h.
> 
> Introducing a new hypercall with the same name
> (PHYSDEVOP_pirq_eoi_gmfn_new) is the first step in admitting that the
> old hypercall was a mistake and should not be used.
> 
> I don't think we should ever change the semantics of PHYSDEVOP_eoi with
> another hypercall. If we want a PHYSDEVOP that eoi and unmask and event
> channel let's introduce PHYSDEVOP_eoi_unmask.

Okay, fine by me. See my comments on naming in the email I sent just a sec
ago.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:14:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqSu7-0000Jp-P6; Thu, 26 Jan 2012 17:14:31 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqSu6-0000Jf-M7
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:14:30 +0000
Received: from [85.158.139.83:6701] by server-8.bemta-5.messagelabs.com id
	CB/19-31172-5F9812F4; Thu, 26 Jan 2012 17:14:29 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327598068!12470724!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2495 invoked from network); 26 Jan 2012 17:14:29 -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;
	26 Jan 2012 17:14:29 -0000
Received: by wgbdt11 with SMTP id dt11so769751wgb.24
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 09:14:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=HX4b7xOgRTIRyWR9VlDpUExZ/EDA2tackVPRfdJDYXs=;
	b=nOzuSqOgm+SWBSsDfwrG8bVNaIKLktcddcrI6sSovh9VJSiXlh/e1y2iYr99IYSbgg
	7cDf4V/LHpDhBq3idJqOJ7SAhcvtqX/+RyZSHW564mpWG76tFXtfIzxhCa7/b64R3G3c
	MJNbStzwHC4YGgtnbW6R2lRCAjlj1dqfb/FYQ=
Received: by 10.180.103.97 with SMTP id fv1mr5169763wib.17.1327598068314;
	Thu, 26 Jan 2012 09:14:28 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id m8sm14446326wia.11.2012.01.26.09.14.26
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 09:14:27 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 17:14:24 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <CB473A70.29ABE%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH 1/2] xen: Introduce
	PHYSDEVOP_pirq_eoi_gmfn_new
Thread-Index: AczcTfNWfkK50wbtw0+NIaNxvKt3KQ==
In-Reply-To: <alpine.DEB.2.00.1201261623380.3196@kaball-desktop>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 16:29, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
wrote:

> On Thu, 26 Jan 2012, Keir Fraser wrote:
>> On 26/01/2012 15:49, "Stefano Stabellini" <Stefano.Stabellini@eu.citrix.com>
>> wrote:
>> 
>>> PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
>>> Introduce PHYSDEVOP_pirq_eoi_gmfn_new, that is like
>>> PHYSDEVOP_pirq_eoi_gmfn but it doesn't modify the behaviour of another
>>> hypercall.
>> 
>> It's nasty that pirq_eoi_gmfn has the side effect. I suggest add a PHYSDEVOP
>> to explicitly enable/disable unmask-on-eoi (i.e., the command accepts a
>> boolean parameter). Once it is explicitly enabled/disabled in this way,
>> pirq_eoi_gmfn no longer has the side effect (regardless of whether it is
>> called before or after the explicit setting). So e.g., pv_domain.auto_unmask
>> becomes an int where 0/1 means no/yes, and -1 means default (i.e., old
>> behavour where it depends on whether PHYSDEVOP_pirq_eoi_gmfn has been
>> called).
>> 
>> This seems to me to move a bad interface in a better direction.
> 
> The problem with this approach is that by default we have an hypercall
> (PHYSDEVOP_pirq_eoi_gmfn) changing the behaviour of another one
> (PHYSDEVOP_eoi). Not only this but we have an hypercall
> (PHYSDEVOP_pirq_eoi_gmfn) violating the public interface of shared_info
> as documented in public/xen.h.
> 
> Introducing a new hypercall with the same name
> (PHYSDEVOP_pirq_eoi_gmfn_new) is the first step in admitting that the
> old hypercall was a mistake and should not be used.
> 
> I don't think we should ever change the semantics of PHYSDEVOP_eoi with
> another hypercall. If we want a PHYSDEVOP that eoi and unmask and event
> channel let's introduce PHYSDEVOP_eoi_unmask.

Okay, fine by me. See my comments on naming in the email I sent just a sec
ago.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:17:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqSwS-0000ao-An; Thu, 26 Jan 2012 17:16:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqSwQ-0000aj-NX
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:16:55 +0000
Received: from [85.158.138.51:39669] by server-7.bemta-3.messagelabs.com id
	5F/FE-31267-68A812F4; Thu, 26 Jan 2012 17:16:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327598211!10640624!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14324 invoked from network); 26 Jan 2012 17:16:51 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:16:51 -0000
Received: by werb14 with SMTP id b14so1905146wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 09:16: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=pYHBShnJQ9HsC18b7tS23X3n/islLrRc96EdYl+oHa4=;
	b=g12u/gVr8l9D2S9JKcuY1WhQqNlZrOa1I5W572lmXSAhCiQnpi6oroDTGitTmxvhxA
	XXlBv4GEkQR06Ns+RhDGOEh4hmug2ZE5A2foRhpiLSFlkeYgljLn0XGokmDlBlNsyJDl
	Aq6REe7KiPWpKVCtxG6Me4vKDMv1ATOAQ8ws8=
Received: by 10.180.75.212 with SMTP id e20mr5150549wiw.11.1327598210513;
	Thu, 26 Jan 2012 09:16:50 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id df2sm6494540wib.4.2012.01.26.09.16.46
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 09:16:50 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 17:16:41 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>, <xen-devel@lists.xensource.com>,
	<JBeulich@suse.com>, <ian.jackson@citrix.com>
Message-ID: <CB473AF9.29AC3%keir.xen@gmail.com>
Thread-Topic: Proposed new committer for ARMv7+VE
Thread-Index: AczcTkT+XpNuVTemIE2eZA9nmfhRIQ==
In-Reply-To: <20120126162621.GE80228@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 16:26, "Tim Deegan" <tim@xen.org> wrote:

> Hi,
> 
> We seem to have agreement that we can start checking in the Xen
> ARMv7-with-Virtualization-Extensions patches that Stefano has been
> posting. 
> 
> It's been suggested that Ian Campbell be made a committer for
> the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
> http://www.xen.org/projects/governance.html, I hereby nominate him.
> 
> Keir, Ian, Jan, please respond with your integer of choice.

+1

> 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 Jan 26 17:17:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqSwS-0000ao-An; Thu, 26 Jan 2012 17:16:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqSwQ-0000aj-NX
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:16:55 +0000
Received: from [85.158.138.51:39669] by server-7.bemta-3.messagelabs.com id
	5F/FE-31267-68A812F4; Thu, 26 Jan 2012 17:16:54 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327598211!10640624!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14324 invoked from network); 26 Jan 2012 17:16:51 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:16:51 -0000
Received: by werb14 with SMTP id b14so1905146wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 09:16: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=pYHBShnJQ9HsC18b7tS23X3n/islLrRc96EdYl+oHa4=;
	b=g12u/gVr8l9D2S9JKcuY1WhQqNlZrOa1I5W572lmXSAhCiQnpi6oroDTGitTmxvhxA
	XXlBv4GEkQR06Ns+RhDGOEh4hmug2ZE5A2foRhpiLSFlkeYgljLn0XGokmDlBlNsyJDl
	Aq6REe7KiPWpKVCtxG6Me4vKDMv1ATOAQ8ws8=
Received: by 10.180.75.212 with SMTP id e20mr5150549wiw.11.1327598210513;
	Thu, 26 Jan 2012 09:16:50 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id df2sm6494540wib.4.2012.01.26.09.16.46
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 09:16:50 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 17:16:41 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Tim Deegan <tim@xen.org>, <xen-devel@lists.xensource.com>,
	<JBeulich@suse.com>, <ian.jackson@citrix.com>
Message-ID: <CB473AF9.29AC3%keir.xen@gmail.com>
Thread-Topic: Proposed new committer for ARMv7+VE
Thread-Index: AczcTkT+XpNuVTemIE2eZA9nmfhRIQ==
In-Reply-To: <20120126162621.GE80228@ocelot.phlegethon.org>
Mime-version: 1.0
Cc: Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 26/01/2012 16:26, "Tim Deegan" <tim@xen.org> wrote:

> Hi,
> 
> We seem to have agreement that we can start checking in the Xen
> ARMv7-with-Virtualization-Extensions patches that Stefano has been
> posting. 
> 
> It's been suggested that Ian Campbell be made a committer for
> the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
> http://www.xen.org/projects/governance.html, I hereby nominate him.
> 
> Keir, Ian, Jan, please respond with your integer of choice.

+1

> 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 Jan 26 17:20:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT00-00017j-Vh; Thu, 26 Jan 2012 17:20:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RqSzz-00017a-T0
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:20:36 +0000
Received: from [85.158.139.83:49718] by server-3.bemta-5.messagelabs.com id
	21/F1-16424-36B812F4; Thu, 26 Jan 2012 17:20:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327598424!12527855!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5977 invoked from network); 26 Jan 2012 17:20:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:20:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315887"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:20:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:20:13 -0500
Received: from leeni.uk.xensource.com (leeni.uk.xensource.com [10.80.2.50])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0QHK8K3009800;
	Thu, 26 Jan 2012 09:20:08 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org
Date: Thu, 26 Jan 2012 17:20:07 +0000
Message-ID: <1327598408-16214-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.8.3
MIME-Version: 1.0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] netback: fix multi page ring size calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 drivers/net/xen-netback/common.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 477e5ab..f3d95b3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -60,9 +60,9 @@ struct xenvif_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 #define NETBK_TX_RING_SIZE(_nr_pages)					\
-	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE) * (_nr_pages))
+	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages)))
 #define NETBK_RX_RING_SIZE(_nr_pages)					\
-	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE) * (_nr_pages))
+	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages)))
 
 #define NETBK_MAX_RING_PAGE_ORDER 2
 #define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:20:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT00-00017j-Vh; Thu, 26 Jan 2012 17:20:36 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RqSzz-00017a-T0
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:20:36 +0000
Received: from [85.158.139.83:49718] by server-3.bemta-5.messagelabs.com id
	21/F1-16424-36B812F4; Thu, 26 Jan 2012 17:20:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327598424!12527855!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5977 invoked from network); 26 Jan 2012 17:20:28 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-2.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:20:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315887"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:20:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:20:13 -0500
Received: from leeni.uk.xensource.com (leeni.uk.xensource.com [10.80.2.50])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0QHK8K3009800;
	Thu, 26 Jan 2012 09:20:08 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org
Date: Thu, 26 Jan 2012 17:20:07 +0000
Message-ID: <1327598408-16214-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.8.3
MIME-Version: 1.0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] netback: fix multi page ring size calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

---
 drivers/net/xen-netback/common.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 477e5ab..f3d95b3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -60,9 +60,9 @@ struct xenvif_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 #define NETBK_TX_RING_SIZE(_nr_pages)					\
-	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE) * (_nr_pages))
+	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages)))
 #define NETBK_RX_RING_SIZE(_nr_pages)					\
-	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE) * (_nr_pages))
+	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages)))
 
 #define NETBK_MAX_RING_PAGE_ORDER 2
 #define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:21:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0W-0001Bn-Fl; Thu, 26 Jan 2012 17:21:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0V-0001BS-5e
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:07 +0000
Received: from [85.158.138.51:14328] by server-8.bemta-3.messagelabs.com id
	8F/84-31878-28B812F4; Thu, 26 Jan 2012 17:21:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598465!10789843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27367 invoked from network); 26 Jan 2012 17:21:05 -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;
	26 Jan 2012 17:21:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT0S-0001c3-Tu; Thu, 26 Jan 2012 17:21:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0S-0007Pa-TC;
	Thu, 26 Jan 2012 17:21:04 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:47 +0000
Message-ID: <1327598457-28261-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] .gitignore/.hgignore: New names for ioemu
	dirs, seabios
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 new seabios clone directories to .gitignore.
* Add new qemu clone directories to .gitignore.
* Remove old tools/ioemu (long-obsolete) from .gitignore and .hgignore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 .gitignore |   27 +++++++++------------------
 .hgignore  |   14 --------------
 2 files changed, 9 insertions(+), 32 deletions(-)

diff --git a/.gitignore b/.gitignore
index 297191e..18f4ce5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,8 +15,6 @@ TAGS
 .config
 
 dist
-tools/ioemu-dir
-tools/ioemu-remote
 stubdom/*.tar.gz
 
 build-*
@@ -162,20 +160,6 @@ tools/hotplug/common/hotplugpath.sh
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-tools/ioemu/.pc/*
-tools/ioemu/config-host.h
-tools/ioemu/config-host.mak
-tools/ioemu/i386-dm/Makefile
-tools/ioemu/i386-dm/config.h
-tools/ioemu/i386-dm/config.mak
-tools/ioemu/i386-dm/qemu-dm
-tools/ioemu/qemu-doc.html
-tools/ioemu/qemu-img.1
-tools/ioemu/qemu-img.pod
-tools/ioemu/qemu-tech.html
-tools/ioemu/qemu.1
-tools/ioemu/qemu.pod
-tools/ioemu/tapdisk-ioemu
 tools/libxc/ia64/asm/*.h
 tools/libxc/ia64/acpi/*.h
 tools/libxc/ia64/acpi/platform/*.h
@@ -285,8 +269,6 @@ tools/xm-test/*/Makefile(.in)*
 tools/xm-test/lib/XmTestLib/config.py
 tools/xm-test/lib/XmTestReport/xmtest.py
 tools/xm-test/tests/*.test
-tools/ioemu-remote
-tools/ioemu-dir
 tools/ocaml-xenstored*
 xen/.banner*
 xen/BLOG
@@ -325,6 +307,15 @@ unmodified_drivers/linux-2.6/*.ko
 unmodified_drivers/linux-2.6/*.mod.c
 LibVNCServer*
 
+tools/qemu-xen-dir-remote
+tools/qemu-xen-dir
+
+tools/qemu-xen-traditional-dir-remote
+tools/qemu-xen-traditional-dir
+
+tools/firmware/seabios-dir-remote
+tools/firmware/seabios-dir
+
 tools/firmware/rombios/_rombios_.c
 tools/firmware/rombios/rombios.s
 tools/firmware/rombios/rombios.sym
diff --git a/.hgignore b/.hgignore
index 64b440e..9d9264a 100644
--- a/.hgignore
+++ b/.hgignore
@@ -163,20 +163,6 @@
 ^tools/include/xen/.*$
 ^tools/include/xen-foreign/.*\.(c|h|size)$
 ^tools/include/xen-foreign/checker$
-^tools/ioemu/\.pc/.*$
-^tools/ioemu/config-host\.h$
-^tools/ioemu/config-host\.mak$
-^tools/ioemu/i386-dm/Makefile$
-^tools/ioemu/i386-dm/config\.h$
-^tools/ioemu/i386-dm/config\.mak$
-^tools/ioemu/i386-dm/qemu-dm$
-^tools/ioemu/qemu-doc\.html$
-^tools/ioemu/qemu-img\.1$
-^tools/ioemu/qemu-img\.pod$
-^tools/ioemu/qemu-tech\.html$
-^tools/ioemu/qemu\.1$
-^tools/ioemu/qemu\.pod$
-^tools/ioemu/tapdisk-ioemu$
 ^tools/libxc/ia64/asm/.*\.h$
 ^tools/libxc/ia64/acpi/.*\.h$
 ^tools/libxc/ia64/acpi/platform/.*\.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 Jan 26 17:21:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0W-0001Bn-Fl; Thu, 26 Jan 2012 17:21:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0V-0001BS-5e
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:07 +0000
Received: from [85.158.138.51:14328] by server-8.bemta-3.messagelabs.com id
	8F/84-31878-28B812F4; Thu, 26 Jan 2012 17:21:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598465!10789843!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27367 invoked from network); 26 Jan 2012 17:21:05 -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;
	26 Jan 2012 17:21:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT0S-0001c3-Tu; Thu, 26 Jan 2012 17:21:04 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0S-0007Pa-TC;
	Thu, 26 Jan 2012 17:21:04 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:47 +0000
Message-ID: <1327598457-28261-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] .gitignore/.hgignore: New names for ioemu
	dirs, seabios
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 new seabios clone directories to .gitignore.
* Add new qemu clone directories to .gitignore.
* Remove old tools/ioemu (long-obsolete) from .gitignore and .hgignore.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 .gitignore |   27 +++++++++------------------
 .hgignore  |   14 --------------
 2 files changed, 9 insertions(+), 32 deletions(-)

diff --git a/.gitignore b/.gitignore
index 297191e..18f4ce5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,8 +15,6 @@ TAGS
 .config
 
 dist
-tools/ioemu-dir
-tools/ioemu-remote
 stubdom/*.tar.gz
 
 build-*
@@ -162,20 +160,6 @@ tools/hotplug/common/hotplugpath.sh
 tools/include/xen/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-tools/ioemu/.pc/*
-tools/ioemu/config-host.h
-tools/ioemu/config-host.mak
-tools/ioemu/i386-dm/Makefile
-tools/ioemu/i386-dm/config.h
-tools/ioemu/i386-dm/config.mak
-tools/ioemu/i386-dm/qemu-dm
-tools/ioemu/qemu-doc.html
-tools/ioemu/qemu-img.1
-tools/ioemu/qemu-img.pod
-tools/ioemu/qemu-tech.html
-tools/ioemu/qemu.1
-tools/ioemu/qemu.pod
-tools/ioemu/tapdisk-ioemu
 tools/libxc/ia64/asm/*.h
 tools/libxc/ia64/acpi/*.h
 tools/libxc/ia64/acpi/platform/*.h
@@ -285,8 +269,6 @@ tools/xm-test/*/Makefile(.in)*
 tools/xm-test/lib/XmTestLib/config.py
 tools/xm-test/lib/XmTestReport/xmtest.py
 tools/xm-test/tests/*.test
-tools/ioemu-remote
-tools/ioemu-dir
 tools/ocaml-xenstored*
 xen/.banner*
 xen/BLOG
@@ -325,6 +307,15 @@ unmodified_drivers/linux-2.6/*.ko
 unmodified_drivers/linux-2.6/*.mod.c
 LibVNCServer*
 
+tools/qemu-xen-dir-remote
+tools/qemu-xen-dir
+
+tools/qemu-xen-traditional-dir-remote
+tools/qemu-xen-traditional-dir
+
+tools/firmware/seabios-dir-remote
+tools/firmware/seabios-dir
+
 tools/firmware/rombios/_rombios_.c
 tools/firmware/rombios/rombios.s
 tools/firmware/rombios/rombios.sym
diff --git a/.hgignore b/.hgignore
index 64b440e..9d9264a 100644
--- a/.hgignore
+++ b/.hgignore
@@ -163,20 +163,6 @@
 ^tools/include/xen/.*$
 ^tools/include/xen-foreign/.*\.(c|h|size)$
 ^tools/include/xen-foreign/checker$
-^tools/ioemu/\.pc/.*$
-^tools/ioemu/config-host\.h$
-^tools/ioemu/config-host\.mak$
-^tools/ioemu/i386-dm/Makefile$
-^tools/ioemu/i386-dm/config\.h$
-^tools/ioemu/i386-dm/config\.mak$
-^tools/ioemu/i386-dm/qemu-dm$
-^tools/ioemu/qemu-doc\.html$
-^tools/ioemu/qemu-img\.1$
-^tools/ioemu/qemu-img\.pod$
-^tools/ioemu/qemu-tech\.html$
-^tools/ioemu/qemu\.1$
-^tools/ioemu/qemu\.pod$
-^tools/ioemu/tapdisk-ioemu$
 ^tools/libxc/ia64/asm/.*\.h$
 ^tools/libxc/ia64/acpi/.*\.h$
 ^tools/libxc/ia64/acpi/platform/.*\.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 Jan 26 17:21:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0g-0001Dd-Sx; Thu, 26 Jan 2012 17:21: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 1RqT0f-0001CW-B1
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327598462!12693677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16336 invoked from network); 26 Jan 2012 17:21:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:21:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17: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; Thu, 26 Jan 2012 17: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
	1RqT0P-0001by-Le; Thu, 26 Jan 2012 17:21:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0P-0007PQ-KU;
	Thu, 26 Jan 2012 17:21:01 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 17:20:46 +0000
Message-ID: <1327598457-28261-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 v8 00/11] libxl: 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

There are a couple of hopefully uncontroversial new patches on the
front of this series:

 01/11 .gitignore/.hgignore: New names for ioemu dirs, seabios
 02/11 xl: fix a couple of memory leaks

The remainder of the series is very similar to previous versions.
 - Changes have been made as discussed on the list, plus:
 - One memory leak (missing GC_FREE) is fixed;
 - I have moved a some of the destruction in xl's domain_create to
   reduce false positives from valgrind;
 - Fixed the ocaml stubs to pass the new ao argument (currently
   these stubs are synchronous, which is not ideal but it's not
   clear what an ocaml caller would want).

 03/11 libxl: New API for providing OS events to libxl
 04/11 ocaml, libxl: support "private" fields
 05/11 libxl: New event generation API
 06/11 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
 07/11 libxl: Permit multithreaded event waiting
 08/11 libxl: Asynchronous/long-running operation infrastructure
 09/11 libxl: New convenience macro CONTAINER_OF
 10/11 libxl: Introduce libxl__ev_devstate
 11/11 libxl: Convert to asynchronous: device removal

The series has also been rebased and retested.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:21:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0g-0001Dd-Sx; Thu, 26 Jan 2012 17:21: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 1RqT0f-0001CW-B1
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327598462!12693677!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16336 invoked from network); 26 Jan 2012 17:21:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:21:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311970"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17: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; Thu, 26 Jan 2012 17: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
	1RqT0P-0001by-Le; Thu, 26 Jan 2012 17:21:01 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0P-0007PQ-KU;
	Thu, 26 Jan 2012 17:21:01 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 17:20:46 +0000
Message-ID: <1327598457-28261-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 v8 00/11] libxl: 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

There are a couple of hopefully uncontroversial new patches on the
front of this series:

 01/11 .gitignore/.hgignore: New names for ioemu dirs, seabios
 02/11 xl: fix a couple of memory leaks

The remainder of the series is very similar to previous versions.
 - Changes have been made as discussed on the list, plus:
 - One memory leak (missing GC_FREE) is fixed;
 - I have moved a some of the destruction in xl's domain_create to
   reduce false positives from valgrind;
 - Fixed the ocaml stubs to pass the new ao argument (currently
   these stubs are synchronous, which is not ideal but it's not
   clear what an ocaml caller would want).

 03/11 libxl: New API for providing OS events to libxl
 04/11 ocaml, libxl: support "private" fields
 05/11 libxl: New event generation API
 06/11 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
 07/11 libxl: Permit multithreaded event waiting
 08/11 libxl: Asynchronous/long-running operation infrastructure
 09/11 libxl: New convenience macro CONTAINER_OF
 10/11 libxl: Introduce libxl__ev_devstate
 11/11 libxl: Convert to asynchronous: device removal

The series has also been rebased and retested.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:21:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0n-0001Fj-9S; Thu, 26 Jan 2012 17:21:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0m-0001Dl-IN
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327598431!51723979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31068 invoked from network); 26 Jan 2012 17:20: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;
	26 Jan 2012 17:20:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqT0f-0001cB-VE; Thu, 26 Jan 2012 17:21:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0f-0007Pp-UE;
	Thu, 26 Jan 2012 17:21:17 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 17:20:48 +0000
Message-ID: <1327598457-28261-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] xl: fix a couple of memory leaks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* dolog leaked the log message (!)

* main() leaked the config_data (perhaps a false positive from valgrind,
  but it's nicer to tidy it up).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/xl.c         |    1 +
 tools/libxl/xl_cmdimpl.c |    3 ++-
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 7b9d2c8..02a6803 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -135,6 +135,7 @@ int main(int argc, char **argv)
                 config_file, strerror(errno));
     parse_global_config(config_file, config_data, config_len);
     free(config_file);
+    free(config_data);
 
     /* Reset options for per-command use of getopt. */
     argv += optind;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7dbd812..87413c8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -278,7 +278,7 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
 static void dolog(const char *file, int line, const char *func, char *fmt, ...)
 {
     va_list ap;
-    char *s;
+    char *s = NULL;
     int rc;
 
     va_start(ap, fmt);
@@ -286,6 +286,7 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
     va_end(ap);
     if (rc >= 0)
         libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
+    free(s);
 }
 
 static void printf_info(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 Thu Jan 26 17:21:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0n-0001Fj-9S; Thu, 26 Jan 2012 17:21:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0m-0001Dl-IN
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:24 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327598431!51723979!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31068 invoked from network); 26 Jan 2012 17:20: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;
	26 Jan 2012 17:20:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311977"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21:18 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqT0f-0001cB-VE; Thu, 26 Jan 2012 17:21:18 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0f-0007Pp-UE;
	Thu, 26 Jan 2012 17:21:17 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 17:20:48 +0000
Message-ID: <1327598457-28261-3-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] xl: fix a couple of memory leaks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

* dolog leaked the log message (!)

* main() leaked the config_data (perhaps a false positive from valgrind,
  but it's nicer to tidy it up).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/xl.c         |    1 +
 tools/libxl/xl_cmdimpl.c |    3 ++-
 2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 7b9d2c8..02a6803 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -135,6 +135,7 @@ int main(int argc, char **argv)
                 config_file, strerror(errno));
     parse_global_config(config_file, config_data, config_len);
     free(config_file);
+    free(config_data);
 
     /* Reset options for per-command use of getopt. */
     argv += optind;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7dbd812..87413c8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -278,7 +278,7 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
 static void dolog(const char *file, int line, const char *func, char *fmt, ...)
 {
     va_list ap;
-    char *s;
+    char *s = NULL;
     int rc;
 
     va_start(ap, fmt);
@@ -286,6 +286,7 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
     va_end(ap);
     if (rc >= 0)
         libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
+    free(s);
 }
 
 static void printf_info(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 Thu Jan 26 17:21:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT0p-0001Gt-Ms; Thu, 26 Jan 2012 17:21:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0o-0001Fw-7W
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:26 +0000
Received: from [85.158.138.51:40035] by server-7.bemta-3.messagelabs.com id
	92/E6-31267-59B812F4; Thu, 26 Jan 2012 17:21:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28389 invoked from network); 26 Jan 2012 17:21:24 -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;
	26 Jan 2012 17:21:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT0l-0001cE-P3; Thu, 26 Jan 2012 17:21:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0l-0007Pw-Nn;
	Thu, 26 Jan 2012 17:21:23 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:49 +0000
Message-ID: <1327598457-28261-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] 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    |  750 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  205 ++++++++++++
 tools/libxl/libxl_internal.h |  277 +++++++++++++++-
 6 files changed, 1267 insertions(+), 3 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 3c3661b..b58c43e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -49,7 +49,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 169fc97..413b684 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,6 +45,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_rindex = 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);
@@ -79,9 +89,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_rindex);
+    free(ctx->watch_slots);
+
+    GC_FREE;
     free(ctx);
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 723eac2..b067724 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"
@@ -223,6 +224,9 @@ enum {
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
     ERROR_NOPARAVIRT = -10,
+    ERROR_NOT_READY = -11,
+    ERROR_OSEVENT_REG_FAIL = -12,
+    ERROR_BUFFERFULL = -13,
 };
 
 #define LIBXL_VERSION 0
@@ -648,6 +652,8 @@ const char *libxl_xenpaging_dir_path(void);
 /* misc */
 int libxl_fd_set_cloexec(int fd);
 
+#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..ec66340
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,750 @@
+/*
+ * 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->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;
+
+ 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__egc *egc, libxl__ev_fd *ev,
+                             int fd, short events, short revents)
+{
+    EGC_GC;
+
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "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(egc, 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);
+        w->slotnum = -1;
+    }
+
+    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 rc;
+
+    /*
+     * 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_rindex
+         * 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_rindex.
+         */
+
+        int maxfd = 0;
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+            if (!efd->events)
+                continue;
+            if (efd->fd >= maxfd)
+                maxfd = efd->fd + 1;
+        }
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_rindex_allocd < maxfd) {
+            assert(maxfd < INT_MAX / sizeof(int) / 2);
+            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+            memset(newarray + CTX->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
+            CTX->fd_rindex = newarray;
+            CTX->fd_rindex_allocd = maxfd;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            assert(efd->fd < CTX->fd_rindex_allocd);
+            CTX->fd_rindex[efd->fd] = used;
+        }
+        used++;
+    }
+    rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    *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;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static int afterpoll_check_fd(libxl_ctx *ctx,
+                              const struct pollfd *fds, int nfds,
+                              int fd, int events)
+    /* returns mask of events which were requested and occurred */
+{
+    if (fd >= ctx->fd_rindex_allocd)
+        /* added after we went into poll, have to try again */
+        return 0;
+
+    int slot = ctx->fd_rindex[fd];
+
+    if (slot >= nfds)
+        /* stale slot entry; again, added afterwards */
+        return 0;
+
+    if (fds[slot].fd != fd)
+        /* again, stale slot entry */
+        return 0;
+
+    int revents = fds[slot].revents & events;
+    /* we mask in case requested events have changed */
+
+    return revents;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    libxl__ev_fd *efd;
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+
+        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        if (revents)
+            efd->func(egc, 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(egc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    EGC_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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(egc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+{
+    libxl__ev_time *ev = for_libxl;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(egc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func)
+{
+    EGC_GC;
+
+    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);
+}
+
+void libxl__egc_cleanup(libxl__egc *egc)
+{
+    libxl__free_all(&egc->gc);
+}
+
+/*
+ * 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..63ef65e
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,205 @@
+/*
+ * 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.
+ *
+ * (Callers inside libxl may not call libxl_osevent_... functions.)
+ */
+
+struct pollfd;
+
+/* 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);
+
+/* nfds and fds[0..nfds] must be from the most recent call to
+ * _beforepoll, as modified by poll.  (It is therefore not possible
+ * to have multiple threads simultaneously polling using this
+ * interface.)
+ *
+ * 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.
+ */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+
+
+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;
+
+/* 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.
+ */
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+
+/* 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);
+
+/* 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.
+ */
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+
+#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 3c8da45..26a6147 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -35,6 +35,7 @@
 #include <unistd.h>
 
 #include <sys/mman.h>
+#include <sys/poll.h>
 #include <sys/select.h>
 #include <sys/stat.h>
 #include <sys/time.h>
@@ -111,6 +112,71 @@ _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__egc libxl__egc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    int fd;
+    short events;
+    libxl__ev_fd_callback *func;
+    /* remainder is private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    void *for_app_reg;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__egc *egc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    libxl__ev_time_callback *func;
+    /* remainder is 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;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+    /* remainder is private for libxl__ev_xswatch... */
+    int slotnum; /* registered iff slotnum >= 0 */
+    uint32_t counterval;
+};
+
+/*
+ * 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;
@@ -129,6 +195,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_rindex_allocd;
+    int *fd_rindex; /* 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 */
@@ -159,12 +242,17 @@ 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;
+};
+
+struct libxl__egc {
+    /* for event-generating functions only */
+    struct libxl__gc gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -236,6 +324,140 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _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.
+ *      FUNC will be called with the context locked (with CTX_LOCK).
+ *
+ *  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.
+ * The ctx will be locked on entry to each FUNC and FUNC should not
+ * unlock it.
+ *
+ * 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; }
+
+
+/*
+ * 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).
+ */
+_hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line,
+                                   const char *func);
+#define LIBXL__EVENT_DISASTER(egc, msg, errnoval, type) \
+    libxl__event_disaster(egc, 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);
@@ -602,6 +824,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)
 
@@ -739,6 +963,55 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 
 /*
+ * Calling context and GC for event-generating functions:
+ *
+ * These are for use by parts of libxl which directly or indirectly
+ * call libxl__event_occurred.  These contain a gc but also a list of
+ * deferred events.
+ *
+ * You should never need to initialise an egc unless you are part of
+ * the event machinery itself.  Otherwise you will always be given an
+ * egc if you need one.  Even functions which generate specific kinds
+ * of events don't need to - rather, they will be passed an egc into
+ * their own callback function and should just use the one they're
+ * given.
+ *
+ * Functions using LIBXL__INIT_EGC may *not* generally be called from
+ * within libxl, because libxl__egc_cleanup may call back into the
+ * application.  This should be documented near the function
+ * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
+ * should in any case not find it necessary to call egc-creators from
+ * within libxl.
+ *
+ * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
+ * with the ctx *unlocked*.  So the right pattern has the EGC_...
+ * macro calls on the outside of the CTX_... ones.
+ */
+
+/* useful for all functions which take an egc: */
+
+#define EGC_GC                                  \
+    libxl__gc *const gc = &egc->gc
+
+/* egc initialisation and destruction: */
+
+#define LIBXL_INIT_EGC(egc,ctx) do{             \
+        LIBXL_INIT_GC((egc).gc,ctx);            \
+        /* list of occurred events tbd */       \
+    } while(0)
+
+_hidden void libxl__egc_cleanup(libxl__egc *egc);
+
+/* convenience macros: */
+
+#define EGC_INIT(ctx)                       \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
+    EGC_GC
+
+#define EGC_FREE           libxl__egc_cleanup(egc)
+
+
+/*
  * Convenience macros.
  */
 
-- 
1.7.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 Jan 26 17:21:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT0p-0001Gt-Ms; Thu, 26 Jan 2012 17:21:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0o-0001Fw-7W
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:26 +0000
Received: from [85.158.138.51:40035] by server-7.bemta-3.messagelabs.com id
	92/E6-31267-59B812F4; Thu, 26 Jan 2012 17:21:25 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28389 invoked from network); 26 Jan 2012 17:21:24 -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;
	26 Jan 2012 17:21:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311982"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT0l-0001cE-P3; Thu, 26 Jan 2012 17:21:23 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0l-0007Pw-Nn;
	Thu, 26 Jan 2012 17:21:23 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:49 +0000
Message-ID: <1327598457-28261-4-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] 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    |  750 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_event.h    |  205 ++++++++++++
 tools/libxl/libxl_internal.h |  277 +++++++++++++++-
 6 files changed, 1267 insertions(+), 3 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 3c3661b..b58c43e 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -49,7 +49,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 169fc97..413b684 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,6 +45,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_rindex = 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);
@@ -79,9 +89,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_rindex);
+    free(ctx->watch_slots);
+
+    GC_FREE;
     free(ctx);
     return 0;
 }
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 723eac2..b067724 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"
@@ -223,6 +224,9 @@ enum {
     ERROR_GUEST_TIMEDOUT = -8,
     ERROR_TIMEDOUT = -9,
     ERROR_NOPARAVIRT = -10,
+    ERROR_NOT_READY = -11,
+    ERROR_OSEVENT_REG_FAIL = -12,
+    ERROR_BUFFERFULL = -13,
 };
 
 #define LIBXL_VERSION 0
@@ -648,6 +652,8 @@ const char *libxl_xenpaging_dir_path(void);
 /* misc */
 int libxl_fd_set_cloexec(int fd);
 
+#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..ec66340
--- /dev/null
+++ b/tools/libxl/libxl_event.c
@@ -0,0 +1,750 @@
+/*
+ * 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->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;
+
+ 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__egc *egc, libxl__ev_fd *ev,
+                             int fd, short events, short revents)
+{
+    EGC_GC;
+
+    for (;;) {
+        char **event = xs_check_watch(CTX->xsh);
+        if (!event) {
+            if (errno == EAGAIN) break;
+            if (errno == EINTR) continue;
+            LIBXL__EVENT_DISASTER(egc, "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(egc, 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);
+        w->slotnum = -1;
+    }
+
+    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 rc;
+
+    /*
+     * 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_rindex
+         * 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_rindex.
+         */
+
+        int maxfd = 0;
+        LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+            if (!efd->events)
+                continue;
+            if (efd->fd >= maxfd)
+                maxfd = efd->fd + 1;
+        }
+        /* make sure our array is as big as *nfds_io */
+        if (CTX->fd_rindex_allocd < maxfd) {
+            assert(maxfd < INT_MAX / sizeof(int) / 2);
+            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            if (!newarray) { rc = ERROR_NOMEM; goto out; }
+            memset(newarray + CTX->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
+            CTX->fd_rindex = newarray;
+            CTX->fd_rindex_allocd = maxfd;
+        }
+    }
+
+    int used = 0;
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+        if (used < *nfds_io) {
+            fds[used].fd = efd->fd;
+            fds[used].events = efd->events;
+            fds[used].revents = 0;
+            assert(efd->fd < CTX->fd_rindex_allocd);
+            CTX->fd_rindex[efd->fd] = used;
+        }
+        used++;
+    }
+    rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
+
+    *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;
+    }
+
+ out:
+    CTX_UNLOCK;
+    GC_FREE;
+    return rc;
+}
+
+static int afterpoll_check_fd(libxl_ctx *ctx,
+                              const struct pollfd *fds, int nfds,
+                              int fd, int events)
+    /* returns mask of events which were requested and occurred */
+{
+    if (fd >= ctx->fd_rindex_allocd)
+        /* added after we went into poll, have to try again */
+        return 0;
+
+    int slot = ctx->fd_rindex[fd];
+
+    if (slot >= nfds)
+        /* stale slot entry; again, added afterwards */
+        return 0;
+
+    if (fds[slot].fd != fd)
+        /* again, stale slot entry */
+        return 0;
+
+    int revents = fds[slot].revents & events;
+    /* we mask in case requested events have changed */
+
+    return revents;
+}
+
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    libxl__ev_fd *efd;
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
+        if (!efd->events)
+            continue;
+
+        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        if (revents)
+            efd->func(egc, 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(egc, etime, &etime->abs);
+    }
+
+    CTX_UNLOCK;
+    EGC_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;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(fd == ev->fd);
+    revents &= ev->events;
+    if (revents)
+        ev->func(egc, ev, fd, ev->events, revents);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl)
+{
+    libxl__ev_time *ev = for_libxl;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    assert(!CTX->osevent_in_hook);
+
+    assert(!ev->infinite);
+    LIBXL_TAILQ_REMOVE(&CTX->etimes, ev, entry);
+    ev->func(egc, ev, &ev->abs);
+
+    CTX_UNLOCK;
+    EGC_FREE;
+}
+
+void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
+                           libxl_event_type type /* may be 0 */,
+                           const char *file, int line, const char *func)
+{
+    EGC_GC;
+
+    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);
+}
+
+void libxl__egc_cleanup(libxl__egc *egc)
+{
+    libxl__free_all(&egc->gc);
+}
+
+/*
+ * 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..63ef65e
--- /dev/null
+++ b/tools/libxl/libxl_event.h
@@ -0,0 +1,205 @@
+/*
+ * 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.
+ *
+ * (Callers inside libxl may not call libxl_osevent_... functions.)
+ */
+
+struct pollfd;
+
+/* 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);
+
+/* nfds and fds[0..nfds] must be from the most recent call to
+ * _beforepoll, as modified by poll.  (It is therefore not possible
+ * to have multiple threads simultaneously polling using this
+ * interface.)
+ *
+ * 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.
+ */
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now);
+
+
+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;
+
+/* 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.
+ */
+void libxl_osevent_register_hooks(libxl_ctx *ctx,
+                                  const libxl_osevent_hooks *hooks,
+                                  void *user);
+
+/* 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);
+
+/* 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.
+ */
+void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
+
+#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 3c8da45..26a6147 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -35,6 +35,7 @@
 #include <unistd.h>
 
 #include <sys/mman.h>
+#include <sys/poll.h>
 #include <sys/select.h>
 #include <sys/stat.h>
 #include <sys/time.h>
@@ -111,6 +112,71 @@ _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__egc libxl__egc;
+
+typedef struct libxl__ev_fd libxl__ev_fd;
+typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
+                                   int fd, short events, short revents);
+struct libxl__ev_fd {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    int fd;
+    short events;
+    libxl__ev_fd_callback *func;
+    /* remainder is private for libxl__ev_fd... */
+    LIBXL_LIST_ENTRY(libxl__ev_fd) entry;
+    void *for_app_reg;
+};
+
+
+typedef struct libxl__ev_time libxl__ev_time;
+typedef void libxl__ev_time_callback(libxl__egc *egc, libxl__ev_time *ev,
+                                     const struct timeval *requested_abs);
+struct libxl__ev_time {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    libxl__ev_time_callback *func;
+    /* remainder is 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;
+};
+
+typedef struct libxl__ev_xswatch libxl__ev_xswatch;
+typedef void libxl__ev_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch*,
+                            const char *watch_path, const char *event_path);
+struct libxl__ev_xswatch {
+    /* caller should include this in their own struct */
+    /* read-only for caller, who may read only when registered: */
+    char *path;
+    libxl__ev_xswatch_callback *callback;
+    /* remainder is private for libxl__ev_xswatch... */
+    int slotnum; /* registered iff slotnum >= 0 */
+    uint32_t counterval;
+};
+
+/*
+ * 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;
@@ -129,6 +195,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_rindex_allocd;
+    int *fd_rindex; /* 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 */
@@ -159,12 +242,17 @@ 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;
+};
+
+struct libxl__egc {
+    /* for event-generating functions only */
+    struct libxl__gc gc;
+};
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
         (gc).alloc_maxsize = 0;                 \
@@ -236,6 +324,140 @@ _hidden bool libxl__xs_mkdir(libxl__gc *gc, xs_transaction_t t,
 
 _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.
+ *      FUNC will be called with the context locked (with CTX_LOCK).
+ *
+ *  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.
+ * The ctx will be locked on entry to each FUNC and FUNC should not
+ * unlock it.
+ *
+ * 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; }
+
+
+/*
+ * 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).
+ */
+_hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
+                                   libxl_event_type type /* may be 0 */,
+                                   const char *file, int line,
+                                   const char *func);
+#define LIBXL__EVENT_DISASTER(egc, msg, errnoval, type) \
+    libxl__event_disaster(egc, 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);
@@ -602,6 +824,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)
 
@@ -739,6 +963,55 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 
 /*
+ * Calling context and GC for event-generating functions:
+ *
+ * These are for use by parts of libxl which directly or indirectly
+ * call libxl__event_occurred.  These contain a gc but also a list of
+ * deferred events.
+ *
+ * You should never need to initialise an egc unless you are part of
+ * the event machinery itself.  Otherwise you will always be given an
+ * egc if you need one.  Even functions which generate specific kinds
+ * of events don't need to - rather, they will be passed an egc into
+ * their own callback function and should just use the one they're
+ * given.
+ *
+ * Functions using LIBXL__INIT_EGC may *not* generally be called from
+ * within libxl, because libxl__egc_cleanup may call back into the
+ * application.  This should be documented near the function
+ * prototype(s) for callers of LIBXL__INIT_EGC and EGC_INIT.  You
+ * should in any case not find it necessary to call egc-creators from
+ * within libxl.
+ *
+ * For the same reason libxl__egc_cleanup (or EGC_FREE) must be called
+ * with the ctx *unlocked*.  So the right pattern has the EGC_...
+ * macro calls on the outside of the CTX_... ones.
+ */
+
+/* useful for all functions which take an egc: */
+
+#define EGC_GC                                  \
+    libxl__gc *const gc = &egc->gc
+
+/* egc initialisation and destruction: */
+
+#define LIBXL_INIT_EGC(egc,ctx) do{             \
+        LIBXL_INIT_GC((egc).gc,ctx);            \
+        /* list of occurred events tbd */       \
+    } while(0)
+
+_hidden void libxl__egc_cleanup(libxl__egc *egc);
+
+/* convenience macros: */
+
+#define EGC_INIT(ctx)                       \
+    libxl__egc egc[1]; LIBXL_INIT_EGC(egc[0],ctx);      \
+    EGC_GC
+
+#define EGC_FREE           libxl__egc_cleanup(egc)
+
+
+/*
  * Convenience macros.
  */
 
-- 
1.7.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 Jan 26 17:21:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0t-0001JE-MJ; Thu, 26 Jan 2012 17:21:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0q-0001HM-NZ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:29 +0000
Received: from [85.158.138.51:15704] by server-4.bemta-3.messagelabs.com id
	55/6F-32238-79B812F4; Thu, 26 Jan 2012 17:21:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28620 invoked from network); 26 Jan 2012 17:21:27 -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;
	26 Jan 2012 17:21:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqT0o-0001cK-Ly; Thu, 26 Jan 2012 17:21:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0o-0007Q4-L2;
	Thu, 26 Jan 2012 17:21:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:51 +0000
Message-ID: <1327598457-28261-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] 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.

The new "libxl_event" structure is blacklisted in the ocaml bindings
for two reasons:
  - It has a field name "type" (which is a keyword in ocaml);
    the ocaml idl generator should massage this field name on
    output, to "type_" perhaps.
  - The ocaml idl generator does not support KeyedUnion.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c            |  328 +++++++++++++++++++++++++++++-----------
 tools/libxl/libxl.h            |   55 +------
 tools/libxl/libxl_event.c      |  236 ++++++++++++++++++++++++++---
 tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
 tools/libxl/libxl_internal.h   |   77 +++++++++-
 tools/libxl/libxl_types.idl    |   34 ++++-
 tools/libxl/xl_cmdimpl.c       |  289 +++++++++++++++++++++--------------
 tools/ocaml/libs/xl/genwrap.py |    1 +
 8 files changed, 927 insertions(+), 276 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 413b684..59d5114 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,8 +45,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_rindex = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -55,6 +58,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);
@@ -86,6 +92,20 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return rc;
 }
 
+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;
@@ -95,6 +115,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);
@@ -108,9 +135,12 @@ 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_rindex);
     free(ctx->watch_slots);
 
+    discard_events(&ctx->occurred);
+
     GC_FREE;
     free(ctx);
     return 0;
@@ -646,117 +676,177 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
     return ret;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    EGC_GC;
+    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;
+
+    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(egc, "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(egc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(egc, 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(egc, 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(egc, 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_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
-{
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
     GC_INIT(ctx);
-    int i, rc = -1;
-    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    libxl_evgen_domain_death *evg, *evg_search;
+    int rc;
+    
+    CTX_LOCK;
 
-    if (!domid)
-        domid = guest_domid;
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->domid = domid;
+    evg->user = user;
 
-    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)
-            goto out;
-        xs_watch(ctx->xsh, waiter[i].path, waiter[i].token);
+    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; }
     }
+
+    *evgen_out = evg;
     rc = 0;
-out:
+
+ out:
+    CTX_UNLOCK;
     GC_FREE;
     return rc;
-}
+};
 
-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;
-    }
-    event->path = strdup(events[XS_WATCH_PATH]);
-    event->token = strdup(events[XS_WATCH_TOKEN]);
-    event->type = atoi(event->token);
-    free(events);
-    return 0;
-}
+void libxl__evdisable_domain_death(libxl__gc *gc,
+                                   libxl_evgen_domain_death *evg) {
+    CTX_LOCK;
 
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter)
-{
-    if (!xs_unwatch(ctx->xsh, waiter->path, waiter->token))
-        return ERROR_FAIL;
+    if (!evg->death_reported)
+        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
     else
-        return 0;
-}
+        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
 
-int libxl_free_event(libxl_event *event)
-{
-    free(event->path);
-    free(event->token);
-    return 0;
-}
+    free(evg);
 
-int libxl_free_waiter(libxl_waiter *waiter)
-{
-    free(waiter->path);
-    free(waiter->token);
-    return 0;
-}
-
-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 (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
+        libxl__ev_xswatch_isregistered(&CTX->death_watch))
+        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
 
-    if (info->running || (!info->shutdown && !info->dying))
-        return ERROR_INVAL;
-
-    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__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    EGC_GC;
+    libxl_evgen_disk_eject *evg = (void*)w;
     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(egc, "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(egc, 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")) {
@@ -765,19 +855,83 @@ 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(egc, 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;
+
+    *evgen_out = evg;
+    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)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b067724..4d3391f 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"
@@ -300,51 +308,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 ec66340..69ad318 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -510,9 +510,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_internal(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -524,9 +524,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_rindex
@@ -593,8 +590,18 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
     }
 
  out:
+    return rc;
+}
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
-    GC_FREE;
+    EGC_FREE;
     return rc;
 }
 
@@ -623,11 +630,11 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now)
+static void afterpoll_internal(libxl__egc *egc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now)
 {
-    EGC_INIT(ctx);
-    CTX_LOCK;
+    EGC_GC;
     libxl__ev_fd *efd;
 
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
@@ -653,12 +660,18 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(egc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_internal(egc, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -723,11 +736,10 @@ void libxl__event_disaster(libxl__egc *egc, 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";
@@ -736,9 +748,197 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
     exit(-1);
 }
 
+static void egc_run_callbacks(libxl__egc *egc)
+{
+    EGC_GC;
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
+}
+
 void libxl__egc_cleanup(libxl__egc *egc)
 {
-    libxl__free_all(&egc->gc);
+    EGC_GC;
+    libxl__free_all(gc);
+
+    egc_run_callbacks(egc);
+}
+
+/*
+ * 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__egc *egc, libxl_event *event)
+{
+    EGC_GC;
+
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__egc_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(&egc->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__egc *egc,
+                              libxl_event_type type, uint32_t domid)
+{
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_internal(libxl__egc *egc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user)
+{
+    EGC_GC;
+    libxl_event *ev;
+    int rc;
+
+    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
+        if (!(typemask & ((uint64_t)1 << 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,
+                      uint64_t typemask,
+                      libxl_event_predicate *pred, void *pred_user)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+static int eventloop_iteration(libxl__egc *egc) {
+    EGC_GC;
+    int rc;
+    struct timeval now;
+    
+    CTX_LOCK;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) goto out;
+
+    int timeout;
+
+    for (;;) {
+        int nfds = CTX->fd_polls_allocd;
+        timeout = -1;
+        rc = beforepoll_internal(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)
+            return 0; /* will go round again if caller requires */
+
+        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_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+    CTX_UNLOCK;
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     uint64_t typemask,
+                     libxl_event_predicate *pred, void *pred_user)
+{
+    int rc;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = eventloop_iteration(egc);
+        if (rc) goto out;
+
+        /* we unlock and cleanup the egc 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__egc_cleanup(egc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
 }
 
 /*
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 63ef65e..f889115 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,181 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ *
+ * (Callers inside libxl may not call libxl_event_check or _wait.)
+ */
+
+#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,
+                      uint64_t 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,
+                     uint64_t 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.  The event_occurs and disaster callbacks may occur on
+   * any thread in which the application calls libxl.
+   *
+   * 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 +211,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.h b/tools/libxl/libxl_internal.h
index 26a6147..8e80f24 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -177,11 +177,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 libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -195,12 +229,16 @@ 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_rindex_allocd;
     int *fd_rindex; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -212,6 +250,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 */
@@ -252,6 +297,7 @@ struct libxl__gc {
 struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
+    struct libxl__event_list occurred_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -396,6 +442,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.
  */
 
 
@@ -439,6 +488,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__egc*, 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__egc*, 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(egc, type, domid)                              \
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
+/*
  * In general, call this via the macro LIBXL__EVENT_DISASTER.
  *
  * Event-generating functions may call this if they might have wanted
@@ -995,12 +1063,15 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 /* egc initialisation and destruction: */
 
-#define LIBXL_INIT_EGC(egc,ctx) do{             \
-        LIBXL_INIT_GC((egc).gc,ctx);            \
-        /* list of occurred events tbd */       \
+#define LIBXL_INIT_EGC(egc,ctx) do{                     \
+        LIBXL_INIT_GC((egc).gc,ctx);                    \
+        LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
+  /* Frees memory allocated within this egc's gc, and and report all
+   * occurred events via callback, if applicable.  May reenter the
+   * application; see restrictions above. */
 
 /* convenience macros: */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 574dec7..35b53d6 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"),
@@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = UInt(64)
+
+libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
+
+libxl_event = Struct("event",[
+    ("link",     libxl_ev_link),
+     # 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 87413c8..71126de 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1226,14 +1226,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;
@@ -1250,11 +1252,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;
@@ -1319,7 +1324,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;
@@ -1432,6 +1437,40 @@ 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 void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
+                                 int num_disks)
+{
+    int i;
+
+    for (i = 0; i < num_disks; i++) {
+        if (diskws[i])
+            libxl_evdisable_disk_eject(ctx, diskws[i]);
+        diskws[i] = NULL;
+    }
+}
+
 static int create_domain(struct domain_create *dom_info)
 {
     libxl_domain_config d_config;
@@ -1445,10 +1484,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;
@@ -1661,14 +1701,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;
@@ -1705,92 +1745,105 @@ 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++) {
+        if (d_config.disks[i].removable) {
+            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;
+                evdisable_disk_ejects(diskws, d_config.num_disks);
+                /* 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;
-            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);
+                if (ret != ERROR_NOT_READY) {
+                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
+                        ret);
                 }
-                break;
+
+                /*
+                 * 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:
@@ -1811,6 +1864,13 @@ waitpid_out:
             waitpid(child_console_pid, &status, 0) < 0 && errno == EINTR)
         goto waitpid_out;
 
+    if (deathw)
+        libxl_evdisable_domain_death(ctx, deathw);
+    if (diskws) {
+        evdisable_disk_ejects(diskws, d_config.num_disks);
+        free(diskws);
+    }
+
     /*
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
@@ -2273,6 +2333,7 @@ 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);
@@ -2287,37 +2348,39 @@ static void shutdown_domain(const char *p, int wait)
     }
 
     if (wait) {
-        libxl_waiter waiter;
-        int fd;
-
-        libxl_wait_for_domain_death(ctx, domid, &waiter);
-
-        libxl_get_wait_fd(ctx, &fd);
+        libxl_evgen_domain_death *deathw;
 
-        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);
     }
 }
 
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 00583d2..b46ee10 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -275,6 +275,7 @@ if __name__ == '__main__':
         "device_model_info",
         "vcpuinfo",
         "topologyinfo",
+        "event",
         ]
 
     for t in blacklist:
-- 
1.7.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 Jan 26 17:21:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0t-0001JE-MJ; Thu, 26 Jan 2012 17:21:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0q-0001HM-NZ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:29 +0000
Received: from [85.158.138.51:15704] by server-4.bemta-3.messagelabs.com id
	55/6F-32238-79B812F4; Thu, 26 Jan 2012 17:21:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!3
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28620 invoked from network); 26 Jan 2012 17:21:27 -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;
	26 Jan 2012 17:21:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311984"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21:27 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqT0o-0001cK-Ly; Thu, 26 Jan 2012 17:21:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0o-0007Q4-L2;
	Thu, 26 Jan 2012 17:21:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:51 +0000
Message-ID: <1327598457-28261-6-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] 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.

The new "libxl_event" structure is blacklisted in the ocaml bindings
for two reasons:
  - It has a field name "type" (which is a keyword in ocaml);
    the ocaml idl generator should massage this field name on
    output, to "type_" perhaps.
  - The ocaml idl generator does not support KeyedUnion.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c            |  328 +++++++++++++++++++++++++++++-----------
 tools/libxl/libxl.h            |   55 +------
 tools/libxl/libxl_event.c      |  236 ++++++++++++++++++++++++++---
 tools/libxl/libxl_event.h      |  183 ++++++++++++++++++++++-
 tools/libxl/libxl_internal.h   |   77 +++++++++-
 tools/libxl/libxl_types.idl    |   34 ++++-
 tools/libxl/xl_cmdimpl.c       |  289 +++++++++++++++++++++--------------
 tools/ocaml/libs/xl/genwrap.py |    1 +
 8 files changed, 927 insertions(+), 276 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 413b684..59d5114 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -45,8 +45,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_rindex = 0;
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
@@ -55,6 +58,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);
@@ -86,6 +92,20 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     return rc;
 }
 
+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;
@@ -95,6 +115,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);
@@ -108,9 +135,12 @@ 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_rindex);
     free(ctx->watch_slots);
 
+    discard_events(&ctx->occurred);
+
     GC_FREE;
     free(ctx);
     return 0;
@@ -646,117 +676,177 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
     return ret;
 }
 
-int libxl_get_wait_fd(libxl_ctx *ctx, int *fd)
-{
-    *fd = xs_fileno(ctx->xsh);
-    return 0;
-}
+static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    EGC_GC;
+    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;
+
+    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(egc, "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(egc, DOMAIN_DESTROY, evg->domid);
+                if (!ev) goto out;
+
+                libxl__event_occurred(egc, 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(egc, 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(egc, 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_wait_for_disk_ejects(libxl_ctx *ctx, uint32_t guest_domid, libxl_device_disk *disks, int num_disks, libxl_waiter *waiter)
-{
+int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t domid,
+                libxl_ev_user user, libxl_evgen_domain_death **evgen_out) {
     GC_INIT(ctx);
-    int i, rc = -1;
-    uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
+    libxl_evgen_domain_death *evg, *evg_search;
+    int rc;
+    
+    CTX_LOCK;
 
-    if (!domid)
-        domid = guest_domid;
+    evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
+    memset(evg, 0, sizeof(*evg));
+    evg->domid = domid;
+    evg->user = user;
 
-    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)
-            goto out;
-        xs_watch(ctx->xsh, waiter[i].path, waiter[i].token);
+    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; }
     }
+
+    *evgen_out = evg;
     rc = 0;
-out:
+
+ out:
+    CTX_UNLOCK;
     GC_FREE;
     return rc;
-}
+};
 
-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;
-    }
-    event->path = strdup(events[XS_WATCH_PATH]);
-    event->token = strdup(events[XS_WATCH_TOKEN]);
-    event->type = atoi(event->token);
-    free(events);
-    return 0;
-}
+void libxl__evdisable_domain_death(libxl__gc *gc,
+                                   libxl_evgen_domain_death *evg) {
+    CTX_LOCK;
 
-int libxl_stop_waiting(libxl_ctx *ctx, libxl_waiter *waiter)
-{
-    if (!xs_unwatch(ctx->xsh, waiter->path, waiter->token))
-        return ERROR_FAIL;
+    if (!evg->death_reported)
+        LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
     else
-        return 0;
-}
+        LIBXL_TAILQ_REMOVE(&CTX->death_reported, evg, entry);
 
-int libxl_free_event(libxl_event *event)
-{
-    free(event->path);
-    free(event->token);
-    return 0;
-}
+    free(evg);
 
-int libxl_free_waiter(libxl_waiter *waiter)
-{
-    free(waiter->path);
-    free(waiter->token);
-    return 0;
-}
-
-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 (!LIBXL_TAILQ_FIRST(&CTX->death_list) &&
+        libxl__ev_xswatch_isregistered(&CTX->death_watch))
+        libxl__ev_xswatch_deregister(gc, &CTX->death_watch);
 
-    if (info->running || (!info->shutdown && !info->dying))
-        return ERROR_INVAL;
-
-    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__egc *egc, libxl__ev_xswatch *w,
+                                        const char *wpath, const char *epath) {
+    EGC_GC;
+    libxl_evgen_disk_eject *evg = (void*)w;
     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(egc, "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(egc, 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")) {
@@ -765,19 +855,83 @@ 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(egc, 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;
+
+    *evgen_out = evg;
+    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)
 {
     GC_INIT(ctx);
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index b067724..4d3391f 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"
@@ -300,51 +308,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 ec66340..69ad318 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -510,9 +510,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_internal(libxl__gc *gc, int *nfds_io,
+                               struct pollfd *fds, int *timeout_upd,
+                               struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -524,9 +524,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_rindex
@@ -593,8 +590,18 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
     }
 
  out:
+    return rc;
+}
+
+int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
+                             struct pollfd *fds, int *timeout_upd,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
-    GC_FREE;
+    EGC_FREE;
     return rc;
 }
 
@@ -623,11 +630,11 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
-                             struct timeval now)
+static void afterpoll_internal(libxl__egc *egc,
+                               int nfds, const struct pollfd *fds,
+                               struct timeval now)
 {
-    EGC_INIT(ctx);
-    CTX_LOCK;
+    EGC_GC;
     libxl__ev_fd *efd;
 
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
@@ -653,12 +660,18 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 
         etime->func(egc, etime, &etime->abs);
     }
+}
 
+void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
+                             struct timeval now)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    afterpoll_internal(egc, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
 
-
 /*
  * osevent hook and callback machinery
  */
@@ -723,11 +736,10 @@ void libxl__event_disaster(libxl__egc *egc, 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";
@@ -736,9 +748,197 @@ void libxl__event_disaster(libxl__egc *egc, const char *msg, int errnoval,
     exit(-1);
 }
 
+static void egc_run_callbacks(libxl__egc *egc)
+{
+    EGC_GC;
+    libxl_event *ev, *ev_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
+        CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
+    }
+}
+
 void libxl__egc_cleanup(libxl__egc *egc)
 {
-    libxl__free_all(&egc->gc);
+    EGC_GC;
+    libxl__free_all(gc);
+
+    egc_run_callbacks(egc);
+}
+
+/*
+ * 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__egc *egc, libxl_event *event)
+{
+    EGC_GC;
+
+    if (CTX->event_hooks &&
+        (CTX->event_hooks->event_occurs_mask & (1UL << event->type))) {
+        /* libxl__egc_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(&egc->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__egc *egc,
+                              libxl_event_type type, uint32_t domid)
+{
+    libxl_event *ev;
+
+    ev = malloc(sizeof(*ev));
+    if (!ev) {
+        LIBXL__EVENT_DISASTER(egc, "allocate new event", errno, type);
+        return NULL;
+    }
+
+    memset(ev, 0, sizeof(*ev));
+    ev->type = type;
+    ev->domid = domid;
+
+    return ev;
+}
+
+static int event_check_internal(libxl__egc *egc, libxl_event **event_r,
+                                unsigned long typemask,
+                                libxl_event_predicate *pred, void *pred_user)
+{
+    EGC_GC;
+    libxl_event *ev;
+    int rc;
+
+    LIBXL_TAILQ_FOREACH(ev, &CTX->occurred, link) {
+        if (!(typemask & ((uint64_t)1 << 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,
+                      uint64_t typemask,
+                      libxl_event_predicate *pred, void *pred_user)
+{
+    EGC_INIT(ctx);
+    CTX_LOCK;
+    int rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
+}
+
+static int eventloop_iteration(libxl__egc *egc) {
+    EGC_GC;
+    int rc;
+    struct timeval now;
+    
+    CTX_LOCK;
+
+    rc = libxl__gettimeofday(gc, &now);
+    if (rc) goto out;
+
+    int timeout;
+
+    for (;;) {
+        int nfds = CTX->fd_polls_allocd;
+        timeout = -1;
+        rc = beforepoll_internal(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)
+            return 0; /* will go round again if caller requires */
+
+        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_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+
+    CTX_UNLOCK;
+
+    rc = 0;
+ out:
+    return rc;
+}
+
+int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
+                     uint64_t typemask,
+                     libxl_event_predicate *pred, void *pred_user)
+{
+    int rc;
+
+    EGC_INIT(ctx);
+    CTX_LOCK;
+
+    for (;;) {
+        rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
+        if (rc != ERROR_NOT_READY) goto out;
+
+        rc = eventloop_iteration(egc);
+        if (rc) goto out;
+
+        /* we unlock and cleanup the egc 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__egc_cleanup(egc);
+        CTX_LOCK;
+    }
+
+ out:
+    CTX_UNLOCK;
+    EGC_FREE;
+    return rc;
 }
 
 /*
diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index 63ef65e..f889115 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -18,6 +18,181 @@
 
 #include <libxl.h>
 
+/*======================================================================*/
+
+/*
+ * Domain event handling - getting Xen events from libxl
+ *
+ * (Callers inside libxl may not call libxl_event_check or _wait.)
+ */
+
+#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,
+                      uint64_t 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,
+                     uint64_t 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.  The event_occurs and disaster callbacks may occur on
+   * any thread in which the application calls libxl.
+   *
+   * 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 +211,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.h b/tools/libxl/libxl_internal.h
index 26a6147..8e80f24 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -177,11 +177,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 libxl__ctx_lock and _unlock (or the convenience
        * macors CTX_LOCK and CTX_UNLOCK) to manipulate this.
@@ -195,12 +229,16 @@ 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_rindex_allocd;
     int *fd_rindex; /* see libxl_osevent_beforepoll */
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
@@ -212,6 +250,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 */
@@ -252,6 +297,7 @@ struct libxl__gc {
 struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
+    struct libxl__event_list occurred_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -396,6 +442,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.
  */
 
 
@@ -439,6 +488,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__egc*, 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__egc*, 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(egc, type, domid)                              \
+    libxl__event_new((egc), LIBXL_EVENT_TYPE_##type, (domid));
+    /* Convenience macro. */
+
+/*
  * In general, call this via the macro LIBXL__EVENT_DISASTER.
  *
  * Event-generating functions may call this if they might have wanted
@@ -995,12 +1063,15 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 
 /* egc initialisation and destruction: */
 
-#define LIBXL_INIT_EGC(egc,ctx) do{             \
-        LIBXL_INIT_GC((egc).gc,ctx);            \
-        /* list of occurred events tbd */       \
+#define LIBXL_INIT_EGC(egc,ctx) do{                     \
+        LIBXL_INIT_GC((egc).gc,ctx);                    \
+        LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
+  /* Frees memory allocated within this egc's gc, and and report all
+   * occurred events via callback, if applicable.  May reenter the
+   * application; see restrictions above. */
 
 /* convenience macros: */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 574dec7..35b53d6 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"),
@@ -395,3 +390,32 @@ libxl_sched_sedf = Struct("sched_sedf", [
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_event_type = Enumeration("event_type", [
+    (1, "DOMAIN_SHUTDOWN"),
+    (2, "DOMAIN_DESTROY"),
+    (3, "DISK_EJECT"),
+    ])
+
+libxl_ev_user = UInt(64)
+
+libxl_ev_link = Builtin("ev_link", passby=PASS_BY_REFERENCE, private=True)
+
+libxl_event = Struct("event",[
+    ("link",     libxl_ev_link),
+     # 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 87413c8..71126de 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1226,14 +1226,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;
@@ -1250,11 +1252,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;
@@ -1319,7 +1324,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;
@@ -1432,6 +1437,40 @@ 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 void evdisable_disk_ejects(libxl_evgen_disk_eject **diskws,
+                                 int num_disks)
+{
+    int i;
+
+    for (i = 0; i < num_disks; i++) {
+        if (diskws[i])
+            libxl_evdisable_disk_eject(ctx, diskws[i]);
+        diskws[i] = NULL;
+    }
+}
+
 static int create_domain(struct domain_create *dom_info)
 {
     libxl_domain_config d_config;
@@ -1445,10 +1484,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;
@@ -1661,14 +1701,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;
@@ -1705,92 +1745,105 @@ 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++) {
+        if (d_config.disks[i].removable) {
+            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;
+                evdisable_disk_ejects(diskws, d_config.num_disks);
+                /* 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;
-            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);
+                if (ret != ERROR_NOT_READY) {
+                    LOG("warning, libxl_event_check (cleanup) failed (rc=%d)",
+                        ret);
                 }
-                break;
+
+                /*
+                 * 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:
@@ -1811,6 +1864,13 @@ waitpid_out:
             waitpid(child_console_pid, &status, 0) < 0 && errno == EINTR)
         goto waitpid_out;
 
+    if (deathw)
+        libxl_evdisable_domain_death(ctx, deathw);
+    if (diskws) {
+        evdisable_disk_ejects(diskws, d_config.num_disks);
+        free(diskws);
+    }
+
     /*
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
@@ -2273,6 +2333,7 @@ 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);
@@ -2287,37 +2348,39 @@ static void shutdown_domain(const char *p, int wait)
     }
 
     if (wait) {
-        libxl_waiter waiter;
-        int fd;
-
-        libxl_wait_for_domain_death(ctx, domid, &waiter);
-
-        libxl_get_wait_fd(ctx, &fd);
+        libxl_evgen_domain_death *deathw;
 
-        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);
     }
 }
 
diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 00583d2..b46ee10 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -275,6 +275,7 @@ if __name__ == '__main__':
         "device_model_info",
         "vcpuinfo",
         "topologyinfo",
+        "event",
         ]
 
     for t in blacklist:
-- 
1.7.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 Jan 26 17:21:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0t-0001It-9v; Thu, 26 Jan 2012 17:21:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RqT0r-0001Fw-Dv
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:29 +0000
Received: from [85.158.138.51:15743] by server-7.bemta-3.messagelabs.com id
	0B/F6-31267-99B812F4; Thu, 26 Jan 2012 17:21:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28687 invoked from network); 26 Jan 2012 17:21:28 -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;
	26 Jan 2012 17:21:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21:28 +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;
	Thu, 26 Jan 2012 17:21:28 +0000
Message-ID: <1327598488.2585.7.camel@leeni.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Date: Thu, 26 Jan 2012 17:21:28 +0000
In-Reply-To: <1327598408-16214-1-git-send-email-wei.liu2@citrix.com>
References: <1327598408-16214-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] netback: fix multi page ring size
	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry for the noise, I accidently sent the wrong patch.

Wei.

On Thu, 2012-01-26 at 17:20 +0000, Wei Liu wrote:
> ---
>  drivers/net/xen-netback/common.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index 477e5ab..f3d95b3 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -60,9 +60,9 @@ struct xenvif_rx_meta {
>  #define MAX_BUFFER_OFFSET PAGE_SIZE
>  
>  #define NETBK_TX_RING_SIZE(_nr_pages)					\
> -	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE) * (_nr_pages))
> +	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages)))
>  #define NETBK_RX_RING_SIZE(_nr_pages)					\
> -	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE) * (_nr_pages))
> +	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages)))
>  
>  #define NETBK_MAX_RING_PAGE_ORDER 2
>  #define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:21:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0u-0001JU-2v; Thu, 26 Jan 2012 17:21:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0r-0001He-J2
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:29 +0000
Received: from [85.158.138.51:15640] by server-9.bemta-3.messagelabs.com id
	1D/3A-31168-89B812F4; Thu, 26 Jan 2012 17:21:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28555 invoked from network); 26 Jan 2012 17:21:26 -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;
	26 Jan 2012 17:21:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:21: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
	1RqT0o-0001cH-19; Thu, 26 Jan 2012 17:21:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0o-0007Q0-0K;
	Thu, 26 Jan 2012 17:21:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 17:20:50 +0000
Message-ID: <1327598457-28261-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] ocaml, libxl: support "private" fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The changeset
  24378:b4365e2c2595  libxl: idl: support new "private" type attribute
is not complete.  Actually using this feature does not work because
the ocaml idl generator does not know about it.

So add that support.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/ocaml/libs/xl/genwrap.py |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 2e65aec..00583d2 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -93,6 +93,8 @@ def gen_ocaml_ml(ty, interface, indent=""):
             s += "\t{\n"
             
         for f in ty.fields:
+            if f.type.private:
+                continue
             x = ocaml_instance_of(f.type, f.name)
             x = x.replace("\n", "\n\t\t")
             s += "\t\t" + x + ";\n"
@@ -148,6 +150,8 @@ def c_val(ty, c, o, indent="", parent = None):
     elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
+            if f.type.private:
+                continue
             s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
             n = n + 1
     else:
@@ -212,6 +216,8 @@ def ocaml_Val(ty, o, c, indent="", parent = None):
         
         n = 0
         for f in ty.fields:
+            if f.type.private:
+                continue
             s += "\n"
             s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
             s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
@@ -290,6 +296,8 @@ if __name__ == '__main__':
     cinc.write(autogen_header("/*", "*/"))
 
     for ty in types:
+        if ty.private:
+            continue
         #sys.stdout.write(" TYPE    %-20s " % ty.rawname)
         ml.write(gen_ocaml_ml(ty, False))
         ml.write("\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 Thu Jan 26 17:21:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0t-0001It-9v; Thu, 26 Jan 2012 17:21:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RqT0r-0001Fw-Dv
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:29 +0000
Received: from [85.158.138.51:15743] by server-7.bemta-3.messagelabs.com id
	0B/F6-31267-99B812F4; Thu, 26 Jan 2012 17:21:29 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!4
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28687 invoked from network); 26 Jan 2012 17:21:28 -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;
	26 Jan 2012 17:21:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311986"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21:28 +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;
	Thu, 26 Jan 2012 17:21:28 +0000
Message-ID: <1327598488.2585.7.camel@leeni.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Date: Thu, 26 Jan 2012 17:21:28 +0000
In-Reply-To: <1327598408-16214-1-git-send-email-wei.liu2@citrix.com>
References: <1327598408-16214-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH] netback: fix multi page ring size
	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Sorry for the noise, I accidently sent the wrong patch.

Wei.

On Thu, 2012-01-26 at 17:20 +0000, Wei Liu wrote:
> ---
>  drivers/net/xen-netback/common.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index 477e5ab..f3d95b3 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -60,9 +60,9 @@ struct xenvif_rx_meta {
>  #define MAX_BUFFER_OFFSET PAGE_SIZE
>  
>  #define NETBK_TX_RING_SIZE(_nr_pages)					\
> -	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE) * (_nr_pages))
> +	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages)))
>  #define NETBK_RX_RING_SIZE(_nr_pages)					\
> -	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE) * (_nr_pages))
> +	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages)))
>  
>  #define NETBK_MAX_RING_PAGE_ORDER 2
>  #define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:21:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0u-0001JU-2v; Thu, 26 Jan 2012 17:21:32 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0r-0001He-J2
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:29 +0000
Received: from [85.158.138.51:15640] by server-9.bemta-3.messagelabs.com id
	1D/3A-31168-89B812F4; Thu, 26 Jan 2012 17:21:28 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28555 invoked from network); 26 Jan 2012 17:21:26 -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;
	26 Jan 2012 17:21:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311983"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:21: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
	1RqT0o-0001cH-19; Thu, 26 Jan 2012 17:21:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0o-0007Q0-0K;
	Thu, 26 Jan 2012 17:21:26 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 17:20:50 +0000
Message-ID: <1327598457-28261-5-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] ocaml, libxl: support "private" fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The changeset
  24378:b4365e2c2595  libxl: idl: support new "private" type attribute
is not complete.  Actually using this feature does not work because
the ocaml idl generator does not know about it.

So add that support.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/ocaml/libs/xl/genwrap.py |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
index 2e65aec..00583d2 100644
--- a/tools/ocaml/libs/xl/genwrap.py
+++ b/tools/ocaml/libs/xl/genwrap.py
@@ -93,6 +93,8 @@ def gen_ocaml_ml(ty, interface, indent=""):
             s += "\t{\n"
             
         for f in ty.fields:
+            if f.type.private:
+                continue
             x = ocaml_instance_of(f.type, f.name)
             x = x.replace("\n", "\n\t\t")
             s += "\t\t" + x + ";\n"
@@ -148,6 +150,8 @@ def c_val(ty, c, o, indent="", parent = None):
     elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
         n = 0
         for f in ty.fields:
+            if f.type.private:
+                continue
             s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
             n = n + 1
     else:
@@ -212,6 +216,8 @@ def ocaml_Val(ty, o, c, indent="", parent = None):
         
         n = 0
         for f in ty.fields:
+            if f.type.private:
+                continue
             s += "\n"
             s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
             s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
@@ -290,6 +296,8 @@ if __name__ == '__main__':
     cinc.write(autogen_header("/*", "*/"))
 
     for ty in types:
+        if ty.private:
+            continue
         #sys.stdout.write(" TYPE    %-20s " % ty.rawname)
         ml.write(gen_ocaml_ml(ty, False))
         ml.write("\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 Thu Jan 26 17:21:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT0w-0001M5-NK; Thu, 26 Jan 2012 17:21:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0v-0001Js-0m
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:33 +0000
Received: from [85.158.138.51:15852] by server-6.bemta-3.messagelabs.com id
	13/4E-31032-C9B812F4; Thu, 26 Jan 2012 17:21:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28779 invoked from network); 26 Jan 2012 17:21:30 -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;
	26 Jan 2012 17:21:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT0r-0001cN-Sy; Thu, 26 Jan 2012 17:21:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0r-0007Q8-SC;
	Thu, 26 Jan 2012 17:21:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:52 +0000
Message-ID: <1327598457-28261-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: introduce libxl_fd_set_nonblock,
	rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 want a function for setting fds to nonblocking, so introduce one.

This is a very similar requirement to that for libxl_fd_set_cloexec,
so make it common with that.

While we're at it, fix a few deficiences that make this latter
function less desirable than it could be:
 * Change the return from 0/-1 (like a syscall) to a libxl error code
 * Take a boolean parameter for turning the flag on and off
 * Log on error (and so, take a ctx for this purpose)

Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
such errors are highly unlikely.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c      |   33 ++++++++++++++++++++++++++-------
 tools/libxl/libxl.h      |    7 ++++++-
 tools/libxl/libxl_qmp.c  |    3 ++-
 tools/libxl/xl_cmdimpl.c |    3 ++-
 4 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59d5114..0094541 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3656,19 +3656,38 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
-int libxl_fd_set_cloexec(int fd)
+static int fd_set_flags(libxl_ctx *ctx, int fd,
+                        int fcntlgetop, int fcntlsetop, const char *fl,
+                        int flagmask, int set_p)
 {
-    int flags = 0;
+    int flags, r;
 
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
+    flags = fcntl(fd, fcntlgetop);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_GET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
+
+    if (set_p)
+        flags |= flagmask;
+    else
+        flags &= ~flagmask;
+
+    r = fcntl(fd, fcntlsetop, flags);
+    if (r == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_SET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+
+    return 0;
 }
 
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
+  { return fd_set_flags(ctx,fd, F_GETFD,F_SETFD,"FD", FD_CLOEXEC, cloexec); }
+
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
+  { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 4d3391f..e32881b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -613,7 +613,12 @@ const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
 /* misc */
-int libxl_fd_set_cloexec(int fd);
+
+/* Each of these sets or clears the flag according to whether the
+ * 2nd parameter is nonzero.  On failure, they log, and
+ * return ERROR_FAIL, but also leave errno valid. */
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
 
 #include <libxl_event.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 6d401b7..f125b17 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -325,7 +325,8 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl_fd_set_cloexec(qmp->qmp_fd);
+    ret = libxl_fd_set_cloexec(qmp->ctx, qmp->qmp_fd, 1);
+    if (ret) return -1;
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 71126de..92bb275 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1509,7 +1509,8 @@ static int create_domain(struct domain_create *dom_info)
             restore_fd = migrate_fd;
         } else {
             restore_fd = open(restore_file, O_RDONLY);
-            libxl_fd_set_cloexec(restore_fd);
+            rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
+            if (rc) return rc;
         }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
-- 
1.7.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 Jan 26 17:21:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT0w-0001M5-NK; Thu, 26 Jan 2012 17:21:34 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0v-0001Js-0m
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:33 +0000
Received: from [85.158.138.51:15852] by server-6.bemta-3.messagelabs.com id
	13/4E-31032-C9B812F4; Thu, 26 Jan 2012 17:21:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!5
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28779 invoked from network); 26 Jan 2012 17:21:30 -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;
	26 Jan 2012 17:21:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311987"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT0r-0001cN-Sy; Thu, 26 Jan 2012 17:21:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0r-0007Q8-SC;
	Thu, 26 Jan 2012 17:21:29 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:52 +0000
Message-ID: <1327598457-28261-7-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: introduce libxl_fd_set_nonblock,
	rationalise _cloexec
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 want a function for setting fds to nonblocking, so introduce one.

This is a very similar requirement to that for libxl_fd_set_cloexec,
so make it common with that.

While we're at it, fix a few deficiences that make this latter
function less desirable than it could be:
 * Change the return from 0/-1 (like a syscall) to a libxl error code
 * Take a boolean parameter for turning the flag on and off
 * Log on error (and so, take a ctx for this purpose)

Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
such errors are highly unlikely.)

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl.c      |   33 ++++++++++++++++++++++++++-------
 tools/libxl/libxl.h      |    7 ++++++-
 tools/libxl/libxl_qmp.c  |    3 ++-
 tools/libxl/xl_cmdimpl.c |    3 ++-
 4 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59d5114..0094541 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3656,19 +3656,38 @@ int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t domid)
     return 0;
 }
 
-int libxl_fd_set_cloexec(int fd)
+static int fd_set_flags(libxl_ctx *ctx, int fd,
+                        int fcntlgetop, int fcntlsetop, const char *fl,
+                        int flagmask, int set_p)
 {
-    int flags = 0;
+    int flags, r;
 
-    if ((flags = fcntl(fd, F_GETFD)) == -1) {
-        flags = 0;
+    flags = fcntl(fd, fcntlgetop);
+    if (flags == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_GET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    if ((flags & FD_CLOEXEC)) {
-        return 0;
+
+    if (set_p)
+        flags |= flagmask;
+    else
+        flags &= ~flagmask;
+
+    r = fcntl(fd, fcntlsetop, flags);
+    if (r == -1) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "fcntl(,F_SET%s) failed",fl);
+        return ERROR_FAIL;
     }
-    return fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
+
+    return 0;
 }
 
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec)
+  { return fd_set_flags(ctx,fd, F_GETFD,F_SETFD,"FD", FD_CLOEXEC, cloexec); }
+
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock)
+  { return fd_set_flags(ctx,fd, F_GETFL,F_SETFL,"FL", O_NONBLOCK, nonblock); }
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 4d3391f..e32881b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -613,7 +613,12 @@ const char *libxl_run_dir_path(void);
 const char *libxl_xenpaging_dir_path(void);
 
 /* misc */
-int libxl_fd_set_cloexec(int fd);
+
+/* Each of these sets or clears the flag according to whether the
+ * 2nd parameter is nonzero.  On failure, they log, and
+ * return ERROR_FAIL, but also leave errno valid. */
+int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
+int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
 
 #include <libxl_event.h>
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 6d401b7..f125b17 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -325,7 +325,8 @@ static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
     if (fcntl(qmp->qmp_fd, F_SETFL, flags | O_NONBLOCK) == -1) {
         return -1;
     }
-    libxl_fd_set_cloexec(qmp->qmp_fd);
+    ret = libxl_fd_set_cloexec(qmp->ctx, qmp->qmp_fd, 1);
+    if (ret) return -1;
 
     memset(&qmp->addr, 0, sizeof (&qmp->addr));
     qmp->addr.sun_family = AF_UNIX;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 71126de..92bb275 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1509,7 +1509,8 @@ static int create_domain(struct domain_create *dom_info)
             restore_fd = migrate_fd;
         } else {
             restore_fd = open(restore_file, O_RDONLY);
-            libxl_fd_set_cloexec(restore_fd);
+            rc = libxl_fd_set_cloexec(ctx, restore_fd, 1);
+            if (rc) return rc;
         }
 
         CHK_ERRNO( libxl_read_exactly(ctx, restore_fd, &hdr,
-- 
1.7.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 Jan 26 17:21:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0x-0001Mr-8q; Thu, 26 Jan 2012 17:21:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0v-0001Kl-I0
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:33 +0000
Received: from [85.158.138.51:19916] by server-2.bemta-3.messagelabs.com id
	9B/03-24515-C9B812F4; Thu, 26 Jan 2012 17:21:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28847 invoked from network); 26 Jan 2012 17:21:32 -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;
	26 Jan 2012 17:21:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT0t-0001cQ-FQ; Thu, 26 Jan 2012 17:21:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0t-0007QC-Ek;
	Thu, 26 Jan 2012 17:21:31 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:53 +0000
Message-ID: <1327598457-28261-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: Permit multithreaded event waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, the context would be locked whenever we were waiting in
libxl's own call to poll (waiting for operating system events).

This would mean that multiple simultaneous calls to libxl_event_wait
in different threads with different parameters would not work
properly.

If we simply unlock the context, it would be possible for another
thread to discover the occurrence of the event we were waiting for,
without us even waking up, and we would remain in poll.  So we need a
way to wake up other threads: a pipe, one for each thread in poll.

We also need to move some variables from globals in the ctx to be
per-polling-thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   18 +++-
 tools/libxl/libxl_event.c    |  196 ++++++++++++++++++++++++++++++++++--------
 tools/libxl/libxl_internal.h |   50 ++++++++++-
 3 files changed, 218 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0094541..59e8cb8 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -49,8 +49,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->osevent_hooks = 0;
 
-    ctx->fd_polls = 0;
-    ctx->fd_rindex = 0;
+    LIBXL_LIST_INIT(&ctx->pollers_event);
+    LIBXL_LIST_INIT(&ctx->pollers_idle);
+
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
 
@@ -61,6 +62,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    rc = libxl__poller_init(ctx, &ctx->poller_app);
+    if (rc) goto out;
+
     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);
@@ -135,8 +139,14 @@ 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_rindex);
+    libxl__poller_dispose(&ctx->poller_app);
+    assert(LIBXL_LIST_EMPTY(&ctx->pollers_event));
+    libxl__poller *poller, *poller_tmp;
+    LIBXL_LIST_FOREACH_SAFE(poller, &ctx->pollers_idle, entry, poller_tmp) {
+        libxl__poller_dispose(poller);
+        free(poller);
+    }
+
     free(ctx->watch_slots);
 
     discard_events(&ctx->occurred);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 69ad318..73dfd9d 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -510,9 +510,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
  * osevent poll
  */
 
-static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
-                               struct pollfd *fds, int *timeout_upd,
-                               struct timeval now)
+static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
+                               int *nfds_io, struct pollfd *fds,
+                               int *timeout_upd, struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -534,7 +534,7 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = 0;
+        int maxfd = poller->wakeup_pipe[0] + 1;
         LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
             if (!efd->events)
                 continue;
@@ -542,30 +542,39 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
                 maxfd = efd->fd + 1;
         }
         /* make sure our array is as big as *nfds_io */
-        if (CTX->fd_rindex_allocd < maxfd) {
+        if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
             if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + CTX->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
-            CTX->fd_rindex = newarray;
-            CTX->fd_rindex_allocd = maxfd;
+            memset(newarray + poller->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
+            poller->fd_rindex = newarray;
+            poller->fd_rindex_allocd = maxfd;
         }
     }
 
     int used = 0;
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-        if (!efd->events)
-            continue;
-        if (used < *nfds_io) {
-            fds[used].fd = efd->fd;
-            fds[used].events = efd->events;
-            fds[used].revents = 0;
-            assert(efd->fd < CTX->fd_rindex_allocd);
-            CTX->fd_rindex[efd->fd] = used;
-        }
-        used++;
-    }
+
+#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
+        if ((req_events)) {                                     \
+            if (used < *nfds_io) {                              \
+                fds[used].fd = (req_fd);                        \
+                fds[used].events = (req_events);                \
+                fds[used].revents = 0;                          \
+                assert((req_fd) < poller->fd_rindex_allocd);    \
+                poller->fd_rindex[(req_fd)] = used;             \
+            }                                                   \
+            used++;                                             \
+        }                                                       \
+    }while(0)
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
+        REQUIRE_FD(efd->fd, efd->events, efd);
+
+    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
+
+#undef REQUIRE_FD
+
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
     *nfds_io = used;
@@ -599,22 +608,23 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
+    int rc = beforepoll_internal(gc, &ctx->poller_app,
+                                 nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
 }
 
-static int afterpoll_check_fd(libxl_ctx *ctx,
+static int afterpoll_check_fd(libxl__poller *poller,
                               const struct pollfd *fds, int nfds,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= ctx->fd_rindex_allocd)
+    if (fd >= poller->fd_rindex_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = ctx->fd_rindex[fd];
+    int slot = poller->fd_rindex[fd];
 
     if (slot >= nfds)
         /* stale slot entry; again, added afterwards */
@@ -630,22 +640,31 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-static void afterpoll_internal(libxl__egc *egc,
+static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
     EGC_GC;
     libxl__ev_fd *efd;
 
+
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
 
-        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        int revents = afterpoll_check_fd(poller,fds,nfds, efd->fd,efd->events);
         if (revents)
             efd->func(egc, efd, efd->fd, efd->events, revents);
     }
 
+    if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
+        char buf[256];
+        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
+        if (r < 0)
+            if (errno != EINTR && errno != EWOULDBLOCK)
+                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+    }
+
     for (;;) {
         libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
         if (!etime)
@@ -667,7 +686,7 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    afterpoll_internal(egc, nfds, fds, now);
+    afterpoll_internal(egc, &ctx->poller_app, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
@@ -790,7 +809,10 @@ void libxl__event_occurred(libxl__egc *egc, libxl_event *event)
         LIBXL_TAILQ_INSERT_TAIL(&egc->occurred_for_callback, event, link);
         return;
     } else {
+        libxl__poller *poller;
         LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+        LIBXL_LIST_FOREACH(poller, &CTX->pollers_event, entry)
+            libxl__poller_wakeup(egc, poller);
     }
 }
 
@@ -858,7 +880,94 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
-static int eventloop_iteration(libxl__egc *egc) {
+/*
+ * Manipulation of pollers
+ */
+
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
+{
+    int r, rc;
+    p->fd_polls = 0;
+    p->fd_rindex = 0;
+
+    r = pipe(p->wakeup_pipe);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
+    if (rc) goto out;
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__poller_dispose(p);
+    return rc;
+}
+
+void libxl__poller_dispose(libxl__poller *p)
+{
+    if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
+    if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
+    free(p->fd_polls);
+    free(p->fd_rindex);
+}
+
+libxl__poller *libxl__poller_get(libxl_ctx *ctx)
+{
+    /* must be called with ctx locked */
+    int rc;
+
+    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
+    if (p)
+        return p;
+
+    p = malloc(sizeof(*p));
+    if (!p) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
+        return 0;
+    }
+    memset(p, 0, sizeof(*p));
+
+    rc = libxl__poller_init(ctx, p);
+    if (rc) return NULL;
+
+    return p;
+}
+
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
+{
+    LIBXL_LIST_INSERT_HEAD(&ctx->pollers_idle, p, entry);
+}
+
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
+{
+    static const char buf[1] = "";
+
+    for (;;) {
+        int r = write(p->wakeup_pipe[1], buf, 1);
+        if (r==1) return;
+        assert(r==-1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return;
+        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
+        return;
+    }
+}
+
+/*
+ * Main event loop iteration
+ */
+
+static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
+    /* The CTX must be locked EXACTLY ONCE so that this function
+     * can unlock it when it polls.
+     */
     EGC_GC;
     int rc;
     struct timeval now;
@@ -871,23 +980,27 @@ static int eventloop_iteration(libxl__egc *egc) {
     int timeout;
 
     for (;;) {
-        int nfds = CTX->fd_polls_allocd;
+        int nfds = poller->fd_polls_allocd;
         timeout = -1;
-        rc = beforepoll_internal(gc, &nfds, CTX->fd_polls, &timeout, now);
+        rc = beforepoll_internal(gc, poller, &nfds, poller->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);
+            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
 
         if (!newarray) { rc = ERROR_NOMEM; goto out; }
 
-        CTX->fd_polls = newarray;
-        CTX->fd_polls_allocd = nfds;
+        poller->fd_polls = newarray;
+        poller->fd_polls_allocd = nfds;
     }
 
-    rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+    CTX_UNLOCK;
+    rc = poll(poller->fd_polls, poller->fd_polls_allocd, timeout);
+    CTX_LOCK;
+
     if (rc < 0) {
         if (errno == EINTR)
             return 0; /* will go round again if caller requires */
@@ -900,7 +1013,8 @@ static int eventloop_iteration(libxl__egc *egc) {
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
-    afterpoll_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+    afterpoll_internal(egc, poller,
+                       poller->fd_polls_allocd, poller->fd_polls, now);
 
     CTX_UNLOCK;
 
@@ -914,15 +1028,19 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      libxl_event_predicate *pred, void *pred_user)
 {
     int rc;
+    libxl__poller *poller = NULL;
 
     EGC_INIT(ctx);
     CTX_LOCK;
 
+    poller = libxl__poller_get(ctx);
+    if (!poller) { rc = ERROR_FAIL; goto out; }
+
     for (;;) {
         rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
         if (rc != ERROR_NOT_READY) goto out;
 
-        rc = eventloop_iteration(egc);
+        rc = eventloop_iteration(egc, poller);
         if (rc) goto out;
 
         /* we unlock and cleanup the egc each time we go through this loop,
@@ -936,6 +1054,8 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     }
 
  out:
+    libxl__poller_put(ctx, poller);
+
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8e80f24..d1b96c1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -207,6 +207,33 @@ struct libxl__evgen_disk_eject {
 _hidden void
 libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
 
+typedef struct libxl__poller libxl__poller;
+struct libxl__poller {
+    /*
+     * These are used to allow other threads to wake up a thread which
+     * may be stuck in poll, because whatever it was waiting for
+     * hadn't happened yet.  Threads which generate events will write
+     * a byte to each pipe.  A thread which is waiting will empty its
+     * own pipe, and put its poller on the pollers_event list, before
+     * releasing the ctx lock and going into poll; when it comes out
+     * of poll it will take the poller off the pollers_event list.
+     *
+     * When a thread is done with a poller it should put it onto
+     * pollers_idle, where it can be reused later.
+     *
+     * The "poller_app" is never idle, but is sometimes on
+     * pollers_event.
+     */
+    LIBXL_LIST_ENTRY(libxl__poller) entry;
+
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
+    int fd_rindex_allocd;
+    int *fd_rindex; /* see libxl_osevent_beforepoll */
+
+    int wakeup_pipe[2]; /* 0 means no fd allocated */
+};
 
 struct libxl__ctx {
     xentoollog_logger *lg;
@@ -237,10 +264,9 @@ struct libxl__ctx {
       /* 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_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    libxl__poller poller_app; /* libxl_osevent_beforepoll and _afterpoll */
+    LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
+
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
     LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
 
@@ -526,6 +552,22 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
     libxl__event_disaster(egc, msg, errnoval, type, __FILE__,__LINE__,__func__)
 
 
+/* Fills in, or disposes of, the resources held by, a poller whose
+ * space the caller has allocated.  ctx must be locked. */
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+void libxl__poller_dispose(libxl__poller *p);
+
+/* Obtain a fresh poller from malloc or the idle list, and put it
+ * away again afterwards.  _get can fail, returning NULL.
+ * ctx must be locked. */
+libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
+
+/* Notifies whoever is polling using p that they should wake up.
+ * ctx must be locked. */
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
+
+
 /* 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);
-- 
1.7.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 Jan 26 17:21:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT0x-0001Mr-8q; Thu, 26 Jan 2012 17:21:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT0v-0001Kl-I0
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:33 +0000
Received: from [85.158.138.51:19916] by server-2.bemta-3.messagelabs.com id
	9B/03-24515-C9B812F4; Thu, 26 Jan 2012 17:21:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!6
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28847 invoked from network); 26 Jan 2012 17:21:32 -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;
	26 Jan 2012 17:21:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311988"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT0t-0001cQ-FQ; Thu, 26 Jan 2012 17:21:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0t-0007QC-Ek;
	Thu, 26 Jan 2012 17:21:31 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:53 +0000
Message-ID: <1327598457-28261-8-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: Permit multithreaded event waiting
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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, the context would be locked whenever we were waiting in
libxl's own call to poll (waiting for operating system events).

This would mean that multiple simultaneous calls to libxl_event_wait
in different threads with different parameters would not work
properly.

If we simply unlock the context, it would be possible for another
thread to discover the occurrence of the event we were waiting for,
without us even waking up, and we would remain in poll.  So we need a
way to wake up other threads: a pipe, one for each thread in poll.

We also need to move some variables from globals in the ctx to be
per-polling-thread.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c          |   18 +++-
 tools/libxl/libxl_event.c    |  196 ++++++++++++++++++++++++++++++++++--------
 tools/libxl/libxl_internal.h |   50 ++++++++++-
 3 files changed, 218 insertions(+), 46 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0094541..59e8cb8 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -49,8 +49,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
     ctx->osevent_hooks = 0;
 
-    ctx->fd_polls = 0;
-    ctx->fd_rindex = 0;
+    LIBXL_LIST_INIT(&ctx->pollers_event);
+    LIBXL_LIST_INIT(&ctx->pollers_idle);
+
     LIBXL_LIST_INIT(&ctx->efds);
     LIBXL_TAILQ_INIT(&ctx->etimes);
 
@@ -61,6 +62,9 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
     LIBXL_TAILQ_INIT(&ctx->death_list);
     libxl__ev_xswatch_init(&ctx->death_watch);
 
+    rc = libxl__poller_init(ctx, &ctx->poller_app);
+    if (rc) goto out;
+
     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);
@@ -135,8 +139,14 @@ 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_rindex);
+    libxl__poller_dispose(&ctx->poller_app);
+    assert(LIBXL_LIST_EMPTY(&ctx->pollers_event));
+    libxl__poller *poller, *poller_tmp;
+    LIBXL_LIST_FOREACH_SAFE(poller, &ctx->pollers_idle, entry, poller_tmp) {
+        libxl__poller_dispose(poller);
+        free(poller);
+    }
+
     free(ctx->watch_slots);
 
     discard_events(&ctx->occurred);
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 69ad318..73dfd9d 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -510,9 +510,9 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
  * osevent poll
  */
 
-static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
-                               struct pollfd *fds, int *timeout_upd,
-                               struct timeval now)
+static int beforepoll_internal(libxl__gc *gc, libxl__poller *poller,
+                               int *nfds_io, struct pollfd *fds,
+                               int *timeout_upd, struct timeval now)
 {
     libxl__ev_fd *efd;
     int rc;
@@ -534,7 +534,7 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
          * not to mess with fd_rindex.
          */
 
-        int maxfd = 0;
+        int maxfd = poller->wakeup_pipe[0] + 1;
         LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
             if (!efd->events)
                 continue;
@@ -542,30 +542,39 @@ static int beforepoll_internal(libxl__gc *gc, int *nfds_io,
                 maxfd = efd->fd + 1;
         }
         /* make sure our array is as big as *nfds_io */
-        if (CTX->fd_rindex_allocd < maxfd) {
+        if (poller->fd_rindex_allocd < maxfd) {
             assert(maxfd < INT_MAX / sizeof(int) / 2);
-            int *newarray = realloc(CTX->fd_rindex, sizeof(int) * maxfd);
+            int *newarray = realloc(poller->fd_rindex, sizeof(int) * maxfd);
             if (!newarray) { rc = ERROR_NOMEM; goto out; }
-            memset(newarray + CTX->fd_rindex_allocd, 0,
-                   sizeof(int) * (maxfd - CTX->fd_rindex_allocd));
-            CTX->fd_rindex = newarray;
-            CTX->fd_rindex_allocd = maxfd;
+            memset(newarray + poller->fd_rindex_allocd, 0,
+                   sizeof(int) * (maxfd - poller->fd_rindex_allocd));
+            poller->fd_rindex = newarray;
+            poller->fd_rindex_allocd = maxfd;
         }
     }
 
     int used = 0;
-    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
-        if (!efd->events)
-            continue;
-        if (used < *nfds_io) {
-            fds[used].fd = efd->fd;
-            fds[used].events = efd->events;
-            fds[used].revents = 0;
-            assert(efd->fd < CTX->fd_rindex_allocd);
-            CTX->fd_rindex[efd->fd] = used;
-        }
-        used++;
-    }
+
+#define REQUIRE_FD(req_fd, req_events, efd) do{                 \
+        if ((req_events)) {                                     \
+            if (used < *nfds_io) {                              \
+                fds[used].fd = (req_fd);                        \
+                fds[used].events = (req_events);                \
+                fds[used].revents = 0;                          \
+                assert((req_fd) < poller->fd_rindex_allocd);    \
+                poller->fd_rindex[(req_fd)] = used;             \
+            }                                                   \
+            used++;                                             \
+        }                                                       \
+    }while(0)
+
+    LIBXL_LIST_FOREACH(efd, &CTX->efds, entry)
+        REQUIRE_FD(efd->fd, efd->events, efd);
+
+    REQUIRE_FD(poller->wakeup_pipe[0], POLLIN, 0);
+
+#undef REQUIRE_FD
+
     rc = used <= *nfds_io ? 0 : ERROR_BUFFERFULL;
 
     *nfds_io = used;
@@ -599,22 +608,23 @@ int libxl_osevent_beforepoll(libxl_ctx *ctx, int *nfds_io,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    int rc = beforepoll_internal(gc, nfds_io, fds, timeout_upd, now);
+    int rc = beforepoll_internal(gc, &ctx->poller_app,
+                                 nfds_io, fds, timeout_upd, now);
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
 }
 
-static int afterpoll_check_fd(libxl_ctx *ctx,
+static int afterpoll_check_fd(libxl__poller *poller,
                               const struct pollfd *fds, int nfds,
                               int fd, int events)
     /* returns mask of events which were requested and occurred */
 {
-    if (fd >= ctx->fd_rindex_allocd)
+    if (fd >= poller->fd_rindex_allocd)
         /* added after we went into poll, have to try again */
         return 0;
 
-    int slot = ctx->fd_rindex[fd];
+    int slot = poller->fd_rindex[fd];
 
     if (slot >= nfds)
         /* stale slot entry; again, added afterwards */
@@ -630,22 +640,31 @@ static int afterpoll_check_fd(libxl_ctx *ctx,
     return revents;
 }
 
-static void afterpoll_internal(libxl__egc *egc,
+static void afterpoll_internal(libxl__egc *egc, libxl__poller *poller,
                                int nfds, const struct pollfd *fds,
                                struct timeval now)
 {
     EGC_GC;
     libxl__ev_fd *efd;
 
+
     LIBXL_LIST_FOREACH(efd, &CTX->efds, entry) {
         if (!efd->events)
             continue;
 
-        int revents = afterpoll_check_fd(CTX,fds,nfds, efd->fd,efd->events);
+        int revents = afterpoll_check_fd(poller,fds,nfds, efd->fd,efd->events);
         if (revents)
             efd->func(egc, efd, efd->fd, efd->events, revents);
     }
 
+    if (afterpoll_check_fd(poller,fds,nfds, poller->wakeup_pipe[0],POLLIN)) {
+        char buf[256];
+        int r = read(poller->wakeup_pipe[0], buf, sizeof(buf));
+        if (r < 0)
+            if (errno != EINTR && errno != EWOULDBLOCK)
+                LIBXL__EVENT_DISASTER(egc, "read wakeup", errno, 0);
+    }
+
     for (;;) {
         libxl__ev_time *etime = LIBXL_TAILQ_FIRST(&CTX->etimes);
         if (!etime)
@@ -667,7 +686,7 @@ void libxl_osevent_afterpoll(libxl_ctx *ctx, int nfds, const struct pollfd *fds,
 {
     EGC_INIT(ctx);
     CTX_LOCK;
-    afterpoll_internal(egc, nfds, fds, now);
+    afterpoll_internal(egc, &ctx->poller_app, nfds, fds, now);
     CTX_UNLOCK;
     EGC_FREE;
 }
@@ -790,7 +809,10 @@ void libxl__event_occurred(libxl__egc *egc, libxl_event *event)
         LIBXL_TAILQ_INSERT_TAIL(&egc->occurred_for_callback, event, link);
         return;
     } else {
+        libxl__poller *poller;
         LIBXL_TAILQ_INSERT_TAIL(&CTX->occurred, event, link);
+        LIBXL_LIST_FOREACH(poller, &CTX->pollers_event, entry)
+            libxl__poller_wakeup(egc, poller);
     }
 }
 
@@ -858,7 +880,94 @@ int libxl_event_check(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
-static int eventloop_iteration(libxl__egc *egc) {
+/*
+ * Manipulation of pollers
+ */
+
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p)
+{
+    int r, rc;
+    p->fd_polls = 0;
+    p->fd_rindex = 0;
+
+    r = pipe(p->wakeup_pipe);
+    if (r) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot create poller pipe");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[0], 1);
+    if (rc) goto out;
+
+    rc = libxl_fd_set_nonblock(ctx, p->wakeup_pipe[1], 1);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__poller_dispose(p);
+    return rc;
+}
+
+void libxl__poller_dispose(libxl__poller *p)
+{
+    if (p->wakeup_pipe[1] > 0) close(p->wakeup_pipe[1]);
+    if (p->wakeup_pipe[0] > 0) close(p->wakeup_pipe[0]);
+    free(p->fd_polls);
+    free(p->fd_rindex);
+}
+
+libxl__poller *libxl__poller_get(libxl_ctx *ctx)
+{
+    /* must be called with ctx locked */
+    int rc;
+
+    libxl__poller *p = LIBXL_LIST_FIRST(&ctx->pollers_idle);
+    if (p)
+        return p;
+
+    p = malloc(sizeof(*p));
+    if (!p) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "cannot allocate poller");
+        return 0;
+    }
+    memset(p, 0, sizeof(*p));
+
+    rc = libxl__poller_init(ctx, p);
+    if (rc) return NULL;
+
+    return p;
+}
+
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p)
+{
+    LIBXL_LIST_INSERT_HEAD(&ctx->pollers_idle, p, entry);
+}
+
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p)
+{
+    static const char buf[1] = "";
+
+    for (;;) {
+        int r = write(p->wakeup_pipe[1], buf, 1);
+        if (r==1) return;
+        assert(r==-1);
+        if (errno == EINTR) continue;
+        if (errno == EWOULDBLOCK) return;
+        LIBXL__EVENT_DISASTER(egc, "cannot poke watch pipe", errno, 0);
+        return;
+    }
+}
+
+/*
+ * Main event loop iteration
+ */
+
+static int eventloop_iteration(libxl__egc *egc, libxl__poller *poller) {
+    /* The CTX must be locked EXACTLY ONCE so that this function
+     * can unlock it when it polls.
+     */
     EGC_GC;
     int rc;
     struct timeval now;
@@ -871,23 +980,27 @@ static int eventloop_iteration(libxl__egc *egc) {
     int timeout;
 
     for (;;) {
-        int nfds = CTX->fd_polls_allocd;
+        int nfds = poller->fd_polls_allocd;
         timeout = -1;
-        rc = beforepoll_internal(gc, &nfds, CTX->fd_polls, &timeout, now);
+        rc = beforepoll_internal(gc, poller, &nfds, poller->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);
+            realloc(poller->fd_polls, sizeof(*newarray) * nfds);
 
         if (!newarray) { rc = ERROR_NOMEM; goto out; }
 
-        CTX->fd_polls = newarray;
-        CTX->fd_polls_allocd = nfds;
+        poller->fd_polls = newarray;
+        poller->fd_polls_allocd = nfds;
     }
 
-    rc = poll(CTX->fd_polls, CTX->fd_polls_allocd, timeout);
+    CTX_UNLOCK;
+    rc = poll(poller->fd_polls, poller->fd_polls_allocd, timeout);
+    CTX_LOCK;
+
     if (rc < 0) {
         if (errno == EINTR)
             return 0; /* will go round again if caller requires */
@@ -900,7 +1013,8 @@ static int eventloop_iteration(libxl__egc *egc) {
     rc = libxl__gettimeofday(gc, &now);
     if (rc) goto out;
 
-    afterpoll_internal(egc, CTX->fd_polls_allocd, CTX->fd_polls, now);
+    afterpoll_internal(egc, poller,
+                       poller->fd_polls_allocd, poller->fd_polls, now);
 
     CTX_UNLOCK;
 
@@ -914,15 +1028,19 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
                      libxl_event_predicate *pred, void *pred_user)
 {
     int rc;
+    libxl__poller *poller = NULL;
 
     EGC_INIT(ctx);
     CTX_LOCK;
 
+    poller = libxl__poller_get(ctx);
+    if (!poller) { rc = ERROR_FAIL; goto out; }
+
     for (;;) {
         rc = event_check_internal(egc, event_r, typemask, pred, pred_user);
         if (rc != ERROR_NOT_READY) goto out;
 
-        rc = eventloop_iteration(egc);
+        rc = eventloop_iteration(egc, poller);
         if (rc) goto out;
 
         /* we unlock and cleanup the egc each time we go through this loop,
@@ -936,6 +1054,8 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     }
 
  out:
+    libxl__poller_put(ctx, poller);
+
     CTX_UNLOCK;
     EGC_FREE;
     return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8e80f24..d1b96c1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -207,6 +207,33 @@ struct libxl__evgen_disk_eject {
 _hidden void
 libxl__evdisable_disk_eject(libxl__gc*, libxl_evgen_disk_eject*);
 
+typedef struct libxl__poller libxl__poller;
+struct libxl__poller {
+    /*
+     * These are used to allow other threads to wake up a thread which
+     * may be stuck in poll, because whatever it was waiting for
+     * hadn't happened yet.  Threads which generate events will write
+     * a byte to each pipe.  A thread which is waiting will empty its
+     * own pipe, and put its poller on the pollers_event list, before
+     * releasing the ctx lock and going into poll; when it comes out
+     * of poll it will take the poller off the pollers_event list.
+     *
+     * When a thread is done with a poller it should put it onto
+     * pollers_idle, where it can be reused later.
+     *
+     * The "poller_app" is never idle, but is sometimes on
+     * pollers_event.
+     */
+    LIBXL_LIST_ENTRY(libxl__poller) entry;
+
+    struct pollfd *fd_polls;
+    int fd_polls_allocd;
+
+    int fd_rindex_allocd;
+    int *fd_rindex; /* see libxl_osevent_beforepoll */
+
+    int wakeup_pipe[2]; /* 0 means no fd allocated */
+};
 
 struct libxl__ctx {
     xentoollog_logger *lg;
@@ -237,10 +264,9 @@ struct libxl__ctx {
       /* 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_rindex_allocd;
-    int *fd_rindex; /* see libxl_osevent_beforepoll */
+    libxl__poller poller_app; /* libxl_osevent_beforepoll and _afterpoll */
+    LIBXL_LIST_HEAD(, libxl__poller) pollers_event, pollers_idle;
+
     LIBXL_LIST_HEAD(, libxl__ev_fd) efds;
     LIBXL_TAILQ_HEAD(, libxl__ev_time) etimes;
 
@@ -526,6 +552,22 @@ _hidden void libxl__event_disaster(libxl__egc*, const char *msg, int errnoval,
     libxl__event_disaster(egc, msg, errnoval, type, __FILE__,__LINE__,__func__)
 
 
+/* Fills in, or disposes of, the resources held by, a poller whose
+ * space the caller has allocated.  ctx must be locked. */
+int libxl__poller_init(libxl_ctx *ctx, libxl__poller *p);
+void libxl__poller_dispose(libxl__poller *p);
+
+/* Obtain a fresh poller from malloc or the idle list, and put it
+ * away again afterwards.  _get can fail, returning NULL.
+ * ctx must be locked. */
+libxl__poller *libxl__poller_get(libxl_ctx *ctx);
+void libxl__poller_put(libxl_ctx *ctx, libxl__poller *p);
+
+/* Notifies whoever is polling using p that they should wake up.
+ * ctx must be locked. */
+void libxl__poller_wakeup(libxl__egc *egc, libxl__poller *p);
+
+
 /* 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);
-- 
1.7.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 Jan 26 17:21:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT12-0001TZ-VP; Thu, 26 Jan 2012 17:21:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT10-0001QN-H4
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:38 +0000
Received: from [85.158.138.51:40859] by server-9.bemta-3.messagelabs.com id
	53/8A-31168-1AB812F4; Thu, 26 Jan 2012 17:21:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29062 invoked from network); 26 Jan 2012 17:21:37 -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;
	26 Jan 2012 17:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:21:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqT0y-0001cX-LQ; Thu, 26 Jan 2012 17:21:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0y-0007QJ-Kf;
	Thu, 26 Jan 2012 17:21:36 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:54 +0000
Message-ID: <1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: Asynchronous/long-running
	operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide a new set of machinery for writing public libxl functions
which may take a long time.  The application gets to decide whether
they want the function to be synchronous, or whether they'd prefer to
get a callback, or an event, when the operation is complete.

User(s) of this machinery will be introduced in later patch(es).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   53 ++++++++++++
 tools/libxl/libxl_event.c    |  188 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |  107 ++++++++++++++++++++++++
 tools/libxl/libxl_types.idl  |    4 +
 4 files changed, 352 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e32881b..fa79c24 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -237,6 +237,59 @@ enum {
     ERROR_BUFFERFULL = -13,
 };
 
+
+/*
+ * Some libxl operations can take a long time.  These functions take a
+ * parameter to control their concurrency:
+ *     libxl_asyncop_how *ao_how
+ *
+ * If ao_how==NULL, the function will be synchronous.
+ *
+ * If ao_how!=NULL, the function will set the operation going, and if
+ * this is successful will return 0.  In this case the zero error
+ * response does NOT mean that the operation was successful; it just
+ * means that it has been successfully started.  It will finish later,
+ * perhaps with an error.
+ *
+ * If ao_how->callback!=NULL, the callback will be called when the
+ * operation completes.  The same rules as for libxl_event_hooks
+ * apply, including the reentrancy rules and the possibility of
+ * "disaster", except that libxl calls ao_how->callback instead of
+ * libxl_event_hooks.event_occurs.  (See libxl_event.h.)
+ *
+ * If ao_how->callback==NULL, a libxl_event will be generated which
+ * can be obtained from libxl_event_wait or libxl_event_check.  The
+ * event will have type OPERATION_COMPLETE (which is not used
+ * elsewhere).
+ *
+ * Note that it is possible for an asynchronous operation which is to
+ * result in a callback to complete during its initiating function
+ * call.  In this case the initiating function will return 0
+ * indicating the at the operation is "in progress", even though by
+ * the time it returns the operation is complete and the callback has
+ * already happened.
+ *
+ * The application must set and use ao_how->for_event (which will be
+ * copied into libxl_event.for_user) or ao_how->for_callback (passed
+ * to the callback) to determine which operation finished, and it must
+ * of course check the rc value for errors.
+ *
+ * *ao_how does not need to remain valid after the initiating function
+ * returns.
+ *
+ * Callbacks may occur on any thread in which the application calls
+ * libxl.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
+    union {
+        libxl_ev_user for_event; /* used if callback==NULL */
+        void *for_callback; /* passed to callback */
+    } u;
+} libxl_asyncop_how;
+
+
 #define LIBXL_VERSION 0
 
 typedef struct {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 73dfd9d..9e1ab56 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -771,10 +771,21 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
+
+    libxl__ao *ao, *ao_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
+                             entry_for_callback, ao_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
+        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        ao->notified = 1;
+        if (!ao->in_initiator)
+            libxl__ao__destroy(CTX, ao);
+    }
 }
 
 void libxl__egc_cleanup(libxl__egc *egc)
@@ -1061,6 +1072,183 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
+
+
+/*
+ * The two possible state flow of an ao:
+ *
+ * Completion before initiator return:
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_inprogress              |
+ *     - if synchronous, run event loop           |
+ *       until the ao completes                   |
+ *                              - ao completes on some thread
+ *                              - completing thread releases the lock
+ *                     <--------------'
+ *     - ao_inprogress takes the lock
+ *     - destroy the ao
+ *
+ *
+ * Completion after initiator return (asynch. only):
+ *
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_inprogress              |
+ *     - observes event not yet done,             |
+ *     - returns to caller                        |
+ *                                                |
+ *                              - ao completes on some thread
+ *                              - generate the event or call the callback
+ *                              - destroy the ao
+ */
+
+void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao)
+{
+    if (!ao) return;
+    if (ao->poller) libxl__poller_put(ctx, ao->poller);
+    ao->magic = LIBXL__AO_MAGIC_DESTROYED;
+    libxl__free_all(&ao->gc);
+    free(ao);
+}
+
+void libxl__ao_abort(libxl__ao *ao)
+{
+    AO_GC;
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+    assert(!ao->complete);
+    libxl__ao__destroy(CTX, ao);
+}
+
+void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
+{
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(!ao->complete);
+    ao->complete = 1;
+    ao->rc = rc;
+
+    if (ao->poller) {
+        assert(ao->in_initiator);
+        libxl__poller_wakeup(egc, ao->poller);
+    } else if (ao->how.callback) {
+        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
+    } else {
+        libxl_event *ev;
+        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
+        if (ev) {
+            ev->for_user = ao->how.u.for_event;
+            ev->u.operation_complete.rc = ao->rc;
+            libxl__event_occurred(egc, ev);
+        }
+        ao->notified = 1;
+    }
+    if (!ao->in_initiator && ao->notified)
+        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
+}
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how)
+{
+    libxl__ao *ao;
+
+    ao = calloc(1, sizeof(*ao));
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+int libxl__ao_inprogress(libxl__ao *ao)
+{
+    AO_GC;
+    int rc;
+
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+
+    if (ao->poller) {
+        /* Caller wants it done synchronously. */
+        /* We use a fresh gc, so that we can free things
+         * each time round the loop. */
+        libxl__egc egc;
+        LIBXL_INIT_EGC(egc,CTX);
+
+        for (;;) {
+            assert(ao->magic == LIBXL__AO_MAGIC);
+
+            if (ao->complete) {
+                rc = ao->rc;
+                ao->notified = 1;
+                break;
+            }
+
+            rc = eventloop_iteration(&egc,ao->poller);
+            if (rc) {
+                /* Oh dear, this is quite unfortunate. */
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
+                           " event during long-running operation (rc=%d)", rc);
+                sleep(1);
+                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
+                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
+                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
+                 * cancellation ability. */
+            }
+
+            CTX_UNLOCK;
+            libxl__egc_cleanup(&egc);
+            CTX_LOCK;
+        }
+    } else {
+        rc = 0;
+    }
+
+    ao->in_initiator = 0;
+
+    if (ao->notified) {
+        assert(ao->complete);
+        libxl__ao__destroy(CTX,ao);
+    }
+
+    return rc;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d1b96c1..044eeb4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -114,6 +114,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
+typedef struct libxl__ao libxl__ao;
 
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
@@ -218,6 +219,10 @@ struct libxl__poller {
      * releasing the ctx lock and going into poll; when it comes out
      * of poll it will take the poller off the pollers_event list.
      *
+     * A thread which is waiting for completion of a synchronous ao
+     * will allocate a poller and record it in the ao, so that other
+     * threads can wake it up.
+     *
      * When a thread is done with a poller it should put it onto
      * pollers_idle, where it can be reused later.
      *
@@ -324,6 +329,21 @@ struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+};
+
+#define LIBXL__AO_MAGIC              0xA0FACE00ul
+#define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
+
+struct libxl__ao {
+    uint32_t magic;
+    unsigned in_initiator:1, complete:1, notified:1;
+    int rc;
+    libxl__gc gc;
+    libxl_asyncop_how how;
+    libxl__poller *poller;
+    uint32_t domid;
+    LIBXL_TAILQ_ENTRY(libxl__ao) entry_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -1108,6 +1128,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define LIBXL_INIT_EGC(egc,ctx) do{                     \
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
+        LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1125,6 +1146,92 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 
 
 /*
+ * Machinery for asynchronous operations ("ao")
+ *
+ * All "slow" functions (includes anything that might block on a
+ * guest or an external script) need to use the asynchronous
+ * operation ("ao") machinery.  The function should take a parameter
+ * const libxl_asyncop_how *ao_how and must start with a call to
+ * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
+ * outside libxl, because they can cause reentrancy callbacks.
+ *
+ * Lifecycle of an ao:
+ *
+ * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
+ *
+ * - After creation, can be used by code which implements
+ *   the operation as follows:
+ *      - the ao's gc, for allocating memory for the lifetime
+ *        of the operation (possibly with the help of the AO_GC
+ *        macro to introduce the gc into scope)
+ *      - the ao itself may be passed about to sub-functions
+ *        so that they can stash it away etc.
+ *      - in particular, the ao pointer must be stashed in some
+ *        per-operation structure which is also passed as a user
+ *        pointer to the internal event generation request routines
+ *        libxl__evgen_FOO, so that at some point a CALLBACK will be
+ *        made when the operation is complete.
+ *
+ * - If initiation is successful, the initiating function needs
+ *   to run libxl__ao_inprogress right before unlocking and
+ *   returning, and return whatever it returns (AO_INPROGRESS macro).
+ *
+ * - If the initiation is unsuccessful, the initiating function must
+ *   call libxl__ao_abort before unlocking and returning whatever
+ *   error code is appropriate (AO_ABORT macro).
+ *
+ * - Later, some callback function, whose callback has been requested
+ *   directly or indirectly, should call libxl__ao_complete (with the
+ *   ctx locked, as it will generally already be in any event callback
+ *   function).  This must happen exactly once for each ao (and not if
+ *   the ao has been destroyed, obviously), and it may not happen
+ *   until libxl__ao_inprogress has been called on the ao.
+ *
+ * - Note that during callback functions, two gcs are available:
+ *    - The one in egc, whose lifetime is only this callback
+ *    - The one in ao, whose lifetime is the asynchronous operation
+ *   Usually callback function should use CONTAINER_OF
+ *   to obtain its own structure, containing a pointer to the ao,
+ *   and then use the gc from that ao.
+ */
+
+#define AO_CREATE(ctx, domid, ao_how)                           \
+    libxl__ctx_lock(ctx);                                       \
+    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
+    if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
+    AO_GC;
+
+#define AO_INPROGRESS ({                                        \
+        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        int ao__rc = libxl__ao_inprogress(ao);                  \
+        libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        (ao__rc);                                               \
+   })
+
+#define AO_ABORT(rc) ({                                         \
+        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        assert(rc);                                             \
+        libxl__ao_abort(ao);                                    \
+        libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        (rc);                                                   \
+    })
+
+#define AO_GC                                   \
+    libxl__gc *const gc = &ao->gc
+
+
+/* All of these MUST be called with the ctx locked.
+ * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
+_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
+                                    const libxl_asyncop_how*);
+_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden void libxl__ao_abort(libxl__ao *ao);
+_hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
+
+/* For use by ao machinery ONLY */
+_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+
+/*
  * Convenience macros.
  */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 35b53d6..8871c17 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -395,6 +395,7 @@ libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DESTROY"),
     (3, "DISK_EJECT"),
+    (4, "OPERATION_COMPLETE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -418,4 +419,7 @@ libxl_event = Struct("event",[
                                         ("vdev", string),
                                         ("disk", libxl_device_disk),
                                  ])),
+           ("operation_complete", Struct(None, [
+                                        ("rc", integer),
+                                 ])),
            ]))])
-- 
1.7.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 Jan 26 17:21:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT12-0001TZ-VP; Thu, 26 Jan 2012 17:21:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT10-0001QN-H4
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:38 +0000
Received: from [85.158.138.51:40859] by server-9.bemta-3.messagelabs.com id
	53/8A-31168-1AB812F4; Thu, 26 Jan 2012 17:21:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!7
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29062 invoked from network); 26 Jan 2012 17:21:37 -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;
	26 Jan 2012 17:21:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21:37 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:21:37 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqT0y-0001cX-LQ; Thu, 26 Jan 2012 17:21:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT0y-0007QJ-Kf;
	Thu, 26 Jan 2012 17:21:36 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:54 +0000
Message-ID: <1327598457-28261-9-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: Asynchronous/long-running
	operation infrastructure
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Provide a new set of machinery for writing public libxl functions
which may take a long time.  The application gets to decide whether
they want the function to be synchronous, or whether they'd prefer to
get a callback, or an event, when the operation is complete.

User(s) of this machinery will be introduced in later patch(es).

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.h          |   53 ++++++++++++
 tools/libxl/libxl_event.c    |  188 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |  107 ++++++++++++++++++++++++
 tools/libxl/libxl_types.idl  |    4 +
 4 files changed, 352 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e32881b..fa79c24 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -237,6 +237,59 @@ enum {
     ERROR_BUFFERFULL = -13,
 };
 
+
+/*
+ * Some libxl operations can take a long time.  These functions take a
+ * parameter to control their concurrency:
+ *     libxl_asyncop_how *ao_how
+ *
+ * If ao_how==NULL, the function will be synchronous.
+ *
+ * If ao_how!=NULL, the function will set the operation going, and if
+ * this is successful will return 0.  In this case the zero error
+ * response does NOT mean that the operation was successful; it just
+ * means that it has been successfully started.  It will finish later,
+ * perhaps with an error.
+ *
+ * If ao_how->callback!=NULL, the callback will be called when the
+ * operation completes.  The same rules as for libxl_event_hooks
+ * apply, including the reentrancy rules and the possibility of
+ * "disaster", except that libxl calls ao_how->callback instead of
+ * libxl_event_hooks.event_occurs.  (See libxl_event.h.)
+ *
+ * If ao_how->callback==NULL, a libxl_event will be generated which
+ * can be obtained from libxl_event_wait or libxl_event_check.  The
+ * event will have type OPERATION_COMPLETE (which is not used
+ * elsewhere).
+ *
+ * Note that it is possible for an asynchronous operation which is to
+ * result in a callback to complete during its initiating function
+ * call.  In this case the initiating function will return 0
+ * indicating the at the operation is "in progress", even though by
+ * the time it returns the operation is complete and the callback has
+ * already happened.
+ *
+ * The application must set and use ao_how->for_event (which will be
+ * copied into libxl_event.for_user) or ao_how->for_callback (passed
+ * to the callback) to determine which operation finished, and it must
+ * of course check the rc value for errors.
+ *
+ * *ao_how does not need to remain valid after the initiating function
+ * returns.
+ *
+ * Callbacks may occur on any thread in which the application calls
+ * libxl.
+ */
+
+typedef struct {
+    void (*callback)(libxl_ctx *ctx, int rc, void *for_callback);
+    union {
+        libxl_ev_user for_event; /* used if callback==NULL */
+        void *for_callback; /* passed to callback */
+    } u;
+} libxl_asyncop_how;
+
+
 #define LIBXL_VERSION 0
 
 typedef struct {
diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 73dfd9d..9e1ab56 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -771,10 +771,21 @@ static void egc_run_callbacks(libxl__egc *egc)
 {
     EGC_GC;
     libxl_event *ev, *ev_tmp;
+
     LIBXL_TAILQ_FOREACH_SAFE(ev, &egc->occurred_for_callback, link, ev_tmp) {
         LIBXL_TAILQ_REMOVE(&egc->occurred_for_callback, ev, link);
         CTX->event_hooks->event_occurs(CTX->event_hooks_user, ev);
     }
+
+    libxl__ao *ao, *ao_tmp;
+    LIBXL_TAILQ_FOREACH_SAFE(ao, &egc->aos_for_callback,
+                             entry_for_callback, ao_tmp) {
+        LIBXL_TAILQ_REMOVE(&egc->aos_for_callback, ao, entry_for_callback);
+        ao->how.callback(CTX, ao->rc, ao->how.u.for_callback);
+        ao->notified = 1;
+        if (!ao->in_initiator)
+            libxl__ao__destroy(CTX, ao);
+    }
 }
 
 void libxl__egc_cleanup(libxl__egc *egc)
@@ -1061,6 +1072,183 @@ int libxl_event_wait(libxl_ctx *ctx, libxl_event **event_r,
     return rc;
 }
 
+
+
+/*
+ * The two possible state flow of an ao:
+ *
+ * Completion before initiator return:
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_inprogress              |
+ *     - if synchronous, run event loop           |
+ *       until the ao completes                   |
+ *                              - ao completes on some thread
+ *                              - completing thread releases the lock
+ *                     <--------------'
+ *     - ao_inprogress takes the lock
+ *     - destroy the ao
+ *
+ *
+ * Completion after initiator return (asynch. only):
+ *
+ *
+ *     Initiator thread                       Possible other threads
+ *
+ *   * ao_create allocates memory and
+ *     initialises the struct
+ *
+ *   * the initiator function does its
+ *     work, setting up various internal
+ *     asynchronous operations -----------> * asynchronous operations
+ *                                            start to take place and
+ *                                            might cause ao completion
+ *                                                |
+ *   * initiator calls ao_inprogress              |
+ *     - observes event not yet done,             |
+ *     - returns to caller                        |
+ *                                                |
+ *                              - ao completes on some thread
+ *                              - generate the event or call the callback
+ *                              - destroy the ao
+ */
+
+void libxl__ao__destroy(libxl_ctx *ctx, libxl__ao *ao)
+{
+    if (!ao) return;
+    if (ao->poller) libxl__poller_put(ctx, ao->poller);
+    ao->magic = LIBXL__AO_MAGIC_DESTROYED;
+    libxl__free_all(&ao->gc);
+    free(ao);
+}
+
+void libxl__ao_abort(libxl__ao *ao)
+{
+    AO_GC;
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+    assert(!ao->complete);
+    libxl__ao__destroy(CTX, ao);
+}
+
+void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc)
+{
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(!ao->complete);
+    ao->complete = 1;
+    ao->rc = rc;
+
+    if (ao->poller) {
+        assert(ao->in_initiator);
+        libxl__poller_wakeup(egc, ao->poller);
+    } else if (ao->how.callback) {
+        LIBXL_TAILQ_INSERT_TAIL(&egc->aos_for_callback, ao, entry_for_callback);
+    } else {
+        libxl_event *ev;
+        ev = NEW_EVENT(egc, OPERATION_COMPLETE, ao->domid);
+        if (ev) {
+            ev->for_user = ao->how.u.for_event;
+            ev->u.operation_complete.rc = ao->rc;
+            libxl__event_occurred(egc, ev);
+        }
+        ao->notified = 1;
+    }
+    if (!ao->in_initiator && ao->notified)
+        libxl__ao__destroy(libxl__gc_owner(&egc->gc), ao);
+}
+
+libxl__ao *libxl__ao_create(libxl_ctx *ctx, uint32_t domid,
+                            const libxl_asyncop_how *how)
+{
+    libxl__ao *ao;
+
+    ao = calloc(1, sizeof(*ao));
+    if (!ao) goto out;
+
+    ao->magic = LIBXL__AO_MAGIC;
+    ao->in_initiator = 1;
+    ao->poller = 0;
+    ao->domid = domid;
+    LIBXL_INIT_GC(ao->gc, ctx);
+
+    if (how) {
+        ao->how = *how;
+    } else {
+        ao->poller = libxl__poller_get(ctx);
+        if (!ao->poller) goto out;
+    }
+    return ao;
+
+ out:
+    if (ao) libxl__ao__destroy(ctx, ao);
+    return NULL;
+}
+
+int libxl__ao_inprogress(libxl__ao *ao)
+{
+    AO_GC;
+    int rc;
+
+    assert(ao->magic == LIBXL__AO_MAGIC);
+    assert(ao->in_initiator);
+
+    if (ao->poller) {
+        /* Caller wants it done synchronously. */
+        /* We use a fresh gc, so that we can free things
+         * each time round the loop. */
+        libxl__egc egc;
+        LIBXL_INIT_EGC(egc,CTX);
+
+        for (;;) {
+            assert(ao->magic == LIBXL__AO_MAGIC);
+
+            if (ao->complete) {
+                rc = ao->rc;
+                ao->notified = 1;
+                break;
+            }
+
+            rc = eventloop_iteration(&egc,ao->poller);
+            if (rc) {
+                /* Oh dear, this is quite unfortunate. */
+                LIBXL__LOG(CTX, LIBXL__LOG_ERROR, "Error waiting for"
+                           " event during long-running operation (rc=%d)", rc);
+                sleep(1);
+                /* It's either this or return ERROR_I_DONT_KNOW_WHETHER
+                 * _THE_THING_YOU_ASKED_FOR_WILL_BE_DONE_LATER_WHEN
+                 * _YOU_DIDNT_EXPECT_IT, since we don't have any kind of
+                 * cancellation ability. */
+            }
+
+            CTX_UNLOCK;
+            libxl__egc_cleanup(&egc);
+            CTX_LOCK;
+        }
+    } else {
+        rc = 0;
+    }
+
+    ao->in_initiator = 0;
+
+    if (ao->notified) {
+        assert(ao->complete);
+        libxl__ao__destroy(CTX,ao);
+    }
+
+    return rc;
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index d1b96c1..044eeb4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -114,6 +114,7 @@ _hidden void libxl__log(libxl_ctx *ctx, xentoollog_level msglevel, int errnoval,
 
 typedef struct libxl__gc libxl__gc;
 typedef struct libxl__egc libxl__egc;
+typedef struct libxl__ao libxl__ao;
 
 typedef struct libxl__ev_fd libxl__ev_fd;
 typedef void libxl__ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev,
@@ -218,6 +219,10 @@ struct libxl__poller {
      * releasing the ctx lock and going into poll; when it comes out
      * of poll it will take the poller off the pollers_event list.
      *
+     * A thread which is waiting for completion of a synchronous ao
+     * will allocate a poller and record it in the ao, so that other
+     * threads can wake it up.
+     *
      * When a thread is done with a poller it should put it onto
      * pollers_idle, where it can be reused later.
      *
@@ -324,6 +329,21 @@ struct libxl__egc {
     /* for event-generating functions only */
     struct libxl__gc gc;
     struct libxl__event_list occurred_for_callback;
+    LIBXL_TAILQ_HEAD(, libxl__ao) aos_for_callback;
+};
+
+#define LIBXL__AO_MAGIC              0xA0FACE00ul
+#define LIBXL__AO_MAGIC_DESTROYED    0xA0DEAD00ul
+
+struct libxl__ao {
+    uint32_t magic;
+    unsigned in_initiator:1, complete:1, notified:1;
+    int rc;
+    libxl__gc gc;
+    libxl_asyncop_how how;
+    libxl__poller *poller;
+    uint32_t domid;
+    LIBXL_TAILQ_ENTRY(libxl__ao) entry_for_callback;
 };
 
 #define LIBXL_INIT_GC(gc,ctx) do{               \
@@ -1108,6 +1128,7 @@ libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
 #define LIBXL_INIT_EGC(egc,ctx) do{                     \
         LIBXL_INIT_GC((egc).gc,ctx);                    \
         LIBXL_TAILQ_INIT(&(egc).occurred_for_callback); \
+        LIBXL_TAILQ_INIT(&(egc).aos_for_callback);      \
     } while(0)
 
 _hidden void libxl__egc_cleanup(libxl__egc *egc);
@@ -1125,6 +1146,92 @@ _hidden void libxl__egc_cleanup(libxl__egc *egc);
 
 
 /*
+ * Machinery for asynchronous operations ("ao")
+ *
+ * All "slow" functions (includes anything that might block on a
+ * guest or an external script) need to use the asynchronous
+ * operation ("ao") machinery.  The function should take a parameter
+ * const libxl_asyncop_how *ao_how and must start with a call to
+ * AO_INITIATOR_ENTRY.  These functions MAY NOT be called from
+ * outside libxl, because they can cause reentrancy callbacks.
+ *
+ * Lifecycle of an ao:
+ *
+ * - Created by libxl__ao_create (or the AO_CREATE convenience macro).
+ *
+ * - After creation, can be used by code which implements
+ *   the operation as follows:
+ *      - the ao's gc, for allocating memory for the lifetime
+ *        of the operation (possibly with the help of the AO_GC
+ *        macro to introduce the gc into scope)
+ *      - the ao itself may be passed about to sub-functions
+ *        so that they can stash it away etc.
+ *      - in particular, the ao pointer must be stashed in some
+ *        per-operation structure which is also passed as a user
+ *        pointer to the internal event generation request routines
+ *        libxl__evgen_FOO, so that at some point a CALLBACK will be
+ *        made when the operation is complete.
+ *
+ * - If initiation is successful, the initiating function needs
+ *   to run libxl__ao_inprogress right before unlocking and
+ *   returning, and return whatever it returns (AO_INPROGRESS macro).
+ *
+ * - If the initiation is unsuccessful, the initiating function must
+ *   call libxl__ao_abort before unlocking and returning whatever
+ *   error code is appropriate (AO_ABORT macro).
+ *
+ * - Later, some callback function, whose callback has been requested
+ *   directly or indirectly, should call libxl__ao_complete (with the
+ *   ctx locked, as it will generally already be in any event callback
+ *   function).  This must happen exactly once for each ao (and not if
+ *   the ao has been destroyed, obviously), and it may not happen
+ *   until libxl__ao_inprogress has been called on the ao.
+ *
+ * - Note that during callback functions, two gcs are available:
+ *    - The one in egc, whose lifetime is only this callback
+ *    - The one in ao, whose lifetime is the asynchronous operation
+ *   Usually callback function should use CONTAINER_OF
+ *   to obtain its own structure, containing a pointer to the ao,
+ *   and then use the gc from that ao.
+ */
+
+#define AO_CREATE(ctx, domid, ao_how)                           \
+    libxl__ctx_lock(ctx);                                       \
+    libxl__ao *ao = libxl__ao_create(ctx, domid, ao_how);       \
+    if (!ao) { libxl__ctx_unlock(ctx); return ERROR_NOMEM; }    \
+    AO_GC;
+
+#define AO_INPROGRESS ({                                        \
+        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        int ao__rc = libxl__ao_inprogress(ao);                  \
+        libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        (ao__rc);                                               \
+   })
+
+#define AO_ABORT(rc) ({                                         \
+        libxl_ctx *ao__ctx = libxl__gc_owner(&ao->gc);          \
+        assert(rc);                                             \
+        libxl__ao_abort(ao);                                    \
+        libxl__ctx_unlock(ao__ctx); /* gc is now invalid */     \
+        (rc);                                                   \
+    })
+
+#define AO_GC                                   \
+    libxl__gc *const gc = &ao->gc
+
+
+/* All of these MUST be called with the ctx locked.
+ * libxl__ao_inprogress MUST be called with the ctx locked exactly once. */
+_hidden libxl__ao *libxl__ao_create(libxl_ctx*, uint32_t domid,
+                                    const libxl_asyncop_how*);
+_hidden int libxl__ao_inprogress(libxl__ao *ao);
+_hidden void libxl__ao_abort(libxl__ao *ao);
+_hidden void libxl__ao_complete(libxl__egc *egc, libxl__ao *ao, int rc);
+
+/* For use by ao machinery ONLY */
+_hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
+
+/*
  * Convenience macros.
  */
 
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 35b53d6..8871c17 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -395,6 +395,7 @@ libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
     (2, "DOMAIN_DESTROY"),
     (3, "DISK_EJECT"),
+    (4, "OPERATION_COMPLETE"),
     ])
 
 libxl_ev_user = UInt(64)
@@ -418,4 +419,7 @@ libxl_event = Struct("event",[
                                         ("vdev", string),
                                         ("disk", libxl_device_disk),
                                  ])),
+           ("operation_complete", Struct(None, [
+                                        ("rc", integer),
+                                 ])),
            ]))])
-- 
1.7.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 Jan 26 17:21:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT14-0001Uw-D9; Thu, 26 Jan 2012 17:21:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT13-0001TO-4t
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:41 +0000
Received: from [85.158.138.51:40989] by server-12.bemta-3.messagelabs.com id
	06/ED-24557-4AB812F4; Thu, 26 Jan 2012 17:21:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29152 invoked from network); 26 Jan 2012 17:21:40 -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;
	26 Jan 2012 17:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT11-0001ca-Fg; Thu, 26 Jan 2012 17:21:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT11-0007QN-F0;
	Thu, 26 Jan 2012 17:21:39 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:55 +0000
Message-ID: <1327598457-28261-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: New convenience macro CONTAINER_OF
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a convenient and type-safe wrapper which does the correct
dance to subtract offsetof.  This is very similar to the
"container_of" macro in the Linux kernel, but it has an additional
feature that instead of the type argument you may also pass an
expression of that type; this makes initialising a variable with
CONTAINER_OF easier.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 044eeb4..095dbce 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1235,6 +1235,35 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
  * Convenience macros.
  */
 
+/*
+ * CONTAINER_OF work like this.  Given:
+ *    typedef struct {
+ *      ...
+ *      member_type member_name;
+ *      ...
+ *    } outer_type;
+ *    outer_type outer, *outer_var;
+ *    member_type *inner_ptr = &outer->member_name;
+ *
+ * Then, effectively:
+ *    outer_type *CONTAINER_OF(member_type *inner_ptr,
+ *                             *outer_var, // or type name for outer_type
+ *                             member_name);
+ *
+ * So that:
+ *    CONTAINER_OF(inner_ptr, *outer_var, member_name) == &outer
+ *    CONTAINER_OF(inner_ptr, outer_type, member_name) == &outer
+ */
+#define CONTAINER_OF(inner_ptr, outer, member_name)                     \
+    ({                                                                  \
+        typeof(outer) *container_of_;                                   \
+        container_of_ = (void*)((char*)(inner_ptr) -                    \
+                                offsetof(typeof(outer), member_name));  \
+        (void)(&container_of_->member_name ==                           \
+               (typeof(inner_ptr))0) /* type check */;                  \
+        container_of_;                                                  \
+    })
+
 
 /*
  * All of these assume (or define)
-- 
1.7.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 Jan 26 17:21:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT14-0001Uw-D9; Thu, 26 Jan 2012 17:21:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT13-0001TO-4t
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:41 +0000
Received: from [85.158.138.51:40989] by server-12.bemta-3.messagelabs.com id
	06/ED-24557-4AB812F4; Thu, 26 Jan 2012 17:21:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!8
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29152 invoked from network); 26 Jan 2012 17:21:40 -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;
	26 Jan 2012 17:21:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311992"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT11-0001ca-Fg; Thu, 26 Jan 2012 17:21:39 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT11-0007QN-F0;
	Thu, 26 Jan 2012 17:21:39 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:55 +0000
Message-ID: <1327598457-28261-10-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: New convenience macro CONTAINER_OF
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a convenient and type-safe wrapper which does the correct
dance to subtract offsetof.  This is very similar to the
"container_of" macro in the Linux kernel, but it has an additional
feature that instead of the type argument you may also pass an
expression of that type; this makes initialising a variable with
CONTAINER_OF easier.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 044eeb4..095dbce 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1235,6 +1235,35 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
  * Convenience macros.
  */
 
+/*
+ * CONTAINER_OF work like this.  Given:
+ *    typedef struct {
+ *      ...
+ *      member_type member_name;
+ *      ...
+ *    } outer_type;
+ *    outer_type outer, *outer_var;
+ *    member_type *inner_ptr = &outer->member_name;
+ *
+ * Then, effectively:
+ *    outer_type *CONTAINER_OF(member_type *inner_ptr,
+ *                             *outer_var, // or type name for outer_type
+ *                             member_name);
+ *
+ * So that:
+ *    CONTAINER_OF(inner_ptr, *outer_var, member_name) == &outer
+ *    CONTAINER_OF(inner_ptr, outer_type, member_name) == &outer
+ */
+#define CONTAINER_OF(inner_ptr, outer, member_name)                     \
+    ({                                                                  \
+        typeof(outer) *container_of_;                                   \
+        container_of_ = (void*)((char*)(inner_ptr) -                    \
+                                offsetof(typeof(outer), member_name));  \
+        (void)(&container_of_->member_name ==                           \
+               (typeof(inner_ptr))0) /* type check */;                  \
+        container_of_;                                                  \
+    })
+
 
 /*
  * All of these assume (or define)
-- 
1.7.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 Jan 26 17:21:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT16-0001XJ-QT; Thu, 26 Jan 2012 17:21:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT15-0001VJ-BY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:43 +0000
Received: from [85.158.138.51:20459] by server-4.bemta-3.messagelabs.com id
	1B/CF-32238-6AB812F4; Thu, 26 Jan 2012 17:21:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29217 invoked from network); 26 Jan 2012 17:21:42 -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;
	26 Jan 2012 17:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311994"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:21: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
	1RqT13-0001cd-OQ; Thu, 26 Jan 2012 17:21:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT13-0007QU-Nm;
	Thu, 26 Jan 2012 17:21:41 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 17:20:56 +0000
Message-ID: <1327598457-28261-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a new-style asynchronous facility for waiting for device
states on xenbus.  This will replace libxl__wait_for_device_state,
after the callers have been updated in later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   75 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   41 +++++++++++++++++++++++
 2 files changed, 116 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 9e1ab56..271949a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -507,6 +507,81 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
 }
 
 /*
+ * waiting for device state
+ */
+
+static void devstate_watch_callback(libxl__egc *egc, libxl__ev_xswatch *watch,
+                                const char *watch_path, const char *event_path)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(watch, *ds, watch);
+    int rc;
+
+    char *sstate = libxl__xs_read(gc, XBT_NULL, watch_path);
+    if (!sstate) {
+        if (errno == ENOENT) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " but it was removed", watch_path, ds->wanted);
+            rc = ERROR_INVAL;
+        } else {
+            LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "backend %s wanted state"
+                             " %d but read failed", watch_path, ds->wanted);
+            rc = ERROR_FAIL;
+        }
+    } else {
+        int got = atoi(sstate);
+        if (got == ds->wanted) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d ok",
+                       watch_path, ds->wanted);
+            rc = 0;
+        } else {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " still waiting state %d", watch_path, ds->wanted, got);
+            return;
+        }
+    }
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, rc);
+}
+
+static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+               " timed out", ds->watch.path, ds->wanted);
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, ERROR_TIMEDOUT);
+}
+
+int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                            libxl__ev_devstate_callback cb,
+                            const char *state_path, int state, int milliseconds)
+{
+    int rc;
+
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+    ds->wanted = state;
+    ds->callback = cb;
+
+    rc = libxl__ev_time_register_rel(gc, &ds->timeout, devstate_timeout,
+                                     milliseconds);
+    if (rc) goto out;
+
+    rc = libxl__ev_xswatch_register(gc, &ds->watch, devstate_watch_callback,
+                                    state_path);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__ev_devstate_cancel(gc, ds);
+    return rc;
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 095dbce..87490c1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -686,6 +686,47 @@ _hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
                                          libxl__device_state_handler handler);
 
 /*
+ * libxl__ev_devstate - waits a given time for a device to
+ * reach a given state.  Follows the libxl_ev_* conventions.
+ * Will generate only one event, and after that is automatically
+ * cancelled.
+ */
+typedef struct libxl__ev_devstate libxl__ev_devstate;
+typedef void libxl__ev_devstate_callback(libxl__egc *egc, libxl__ev_devstate*,
+                                         int rc);
+  /* rc will be 0, ERROR_TIMEDOUT, ERROR_INVAL (meaning path was removed),
+   * or ERROR_FAIL if other stuff went wrong (in which latter case, logged) */
+
+struct libxl__ev_devstate {
+    /* read-only for caller, who may read only when waiting: */
+    int wanted;
+    libxl__ev_devstate_callback *callback;
+    /* as for the remainder, read-only public parts may also be
+     * read by the caller (notably, watch.path), but only when waiting: */
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+};
+
+static inline void libxl__ev_devstate_init(libxl__ev_devstate *ds)
+{
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+}
+
+static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
+                                             libxl__ev_devstate *ds)
+{
+    libxl__ev_time_deregister(gc,&ds->timeout);
+    libxl__ev_xswatch_deregister(gc,&ds->watch);
+}
+
+_hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                                    libxl__ev_devstate_callback cb,
+                                    const char *state_path,
+                                    int state, int milliseconds);
+
+
+/*
  * 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
-- 
1.7.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 Jan 26 17:21:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:21:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT16-0001XJ-QT; Thu, 26 Jan 2012 17:21:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT15-0001VJ-BY
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:43 +0000
Received: from [85.158.138.51:20459] by server-4.bemta-3.messagelabs.com id
	1B/CF-32238-6AB812F4; Thu, 26 Jan 2012 17:21:42 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!9
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29217 invoked from network); 26 Jan 2012 17:21:42 -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;
	26 Jan 2012 17:21:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311994"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21:42 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:21: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
	1RqT13-0001cd-OQ; Thu, 26 Jan 2012 17:21:41 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT13-0007QU-Nm;
	Thu, 26 Jan 2012 17:21:41 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 17:20:56 +0000
Message-ID: <1327598457-28261-11-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: Introduce libxl__ev_devstate
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 a new-style asynchronous facility for waiting for device
states on xenbus.  This will replace libxl__wait_for_device_state,
after the callers have been updated in later patches.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_event.c    |   75 ++++++++++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h |   41 +++++++++++++++++++++++
 2 files changed, 116 insertions(+), 0 deletions(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 9e1ab56..271949a 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -507,6 +507,81 @@ void libxl__ev_xswatch_deregister(libxl__gc *gc, libxl__ev_xswatch *w)
 }
 
 /*
+ * waiting for device state
+ */
+
+static void devstate_watch_callback(libxl__egc *egc, libxl__ev_xswatch *watch,
+                                const char *watch_path, const char *event_path)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(watch, *ds, watch);
+    int rc;
+
+    char *sstate = libxl__xs_read(gc, XBT_NULL, watch_path);
+    if (!sstate) {
+        if (errno == ENOENT) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " but it was removed", watch_path, ds->wanted);
+            rc = ERROR_INVAL;
+        } else {
+            LIBXL__LOG_ERRNO(CTX, LIBXL__LOG_ERROR, "backend %s wanted state"
+                             " %d but read failed", watch_path, ds->wanted);
+            rc = ERROR_FAIL;
+        }
+    } else {
+        int got = atoi(sstate);
+        if (got == ds->wanted) {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d ok",
+                       watch_path, ds->wanted);
+            rc = 0;
+        } else {
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d"
+                       " still waiting state %d", watch_path, ds->wanted, got);
+            return;
+        }
+    }
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, rc);
+}
+
+static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
+                             const struct timeval *requested_abs)
+{
+    EGC_GC;
+    libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
+               " timed out", ds->watch.path, ds->wanted);
+    libxl__ev_devstate_cancel(gc, ds);
+    ds->callback(egc, ds, ERROR_TIMEDOUT);
+}
+
+int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                            libxl__ev_devstate_callback cb,
+                            const char *state_path, int state, int milliseconds)
+{
+    int rc;
+
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+    ds->wanted = state;
+    ds->callback = cb;
+
+    rc = libxl__ev_time_register_rel(gc, &ds->timeout, devstate_timeout,
+                                     milliseconds);
+    if (rc) goto out;
+
+    rc = libxl__ev_xswatch_register(gc, &ds->watch, devstate_watch_callback,
+                                    state_path);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    libxl__ev_devstate_cancel(gc, ds);
+    return rc;
+}
+
+/*
  * osevent poll
  */
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 095dbce..87490c1 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -686,6 +686,47 @@ _hidden int libxl__wait_for_device_state(libxl__gc *gc, struct timeval *tv,
                                          libxl__device_state_handler handler);
 
 /*
+ * libxl__ev_devstate - waits a given time for a device to
+ * reach a given state.  Follows the libxl_ev_* conventions.
+ * Will generate only one event, and after that is automatically
+ * cancelled.
+ */
+typedef struct libxl__ev_devstate libxl__ev_devstate;
+typedef void libxl__ev_devstate_callback(libxl__egc *egc, libxl__ev_devstate*,
+                                         int rc);
+  /* rc will be 0, ERROR_TIMEDOUT, ERROR_INVAL (meaning path was removed),
+   * or ERROR_FAIL if other stuff went wrong (in which latter case, logged) */
+
+struct libxl__ev_devstate {
+    /* read-only for caller, who may read only when waiting: */
+    int wanted;
+    libxl__ev_devstate_callback *callback;
+    /* as for the remainder, read-only public parts may also be
+     * read by the caller (notably, watch.path), but only when waiting: */
+    libxl__ev_xswatch watch;
+    libxl__ev_time timeout;
+};
+
+static inline void libxl__ev_devstate_init(libxl__ev_devstate *ds)
+{
+    libxl__ev_time_init(&ds->timeout);
+    libxl__ev_xswatch_init(&ds->watch);
+}
+
+static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
+                                             libxl__ev_devstate *ds)
+{
+    libxl__ev_time_deregister(gc,&ds->timeout);
+    libxl__ev_xswatch_deregister(gc,&ds->watch);
+}
+
+_hidden int libxl__ev_devstate_wait(libxl__gc *gc, libxl__ev_devstate *ds,
+                                    libxl__ev_devstate_callback cb,
+                                    const char *state_path,
+                                    int state, int milliseconds);
+
+
+/*
  * 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
-- 
1.7.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 Jan 26 17:21:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT1A-0001c6-Vk; Thu, 26 Jan 2012 17:21:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT18-0001Z8-Tn
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:47 +0000
Received: from [85.158.138.51:41373] by server-5.bemta-3.messagelabs.com id
	CB/97-02363-AAB812F4; Thu, 26 Jan 2012 17:21:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29312 invoked from network); 26 Jan 2012 17:21:45 -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;
	26 Jan 2012 17:21:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT16-0001cg-FC; Thu, 26 Jan 2012 17:21:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT16-0007QY-ET;
	Thu, 26 Jan 2012 17:21:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:57 +0000
Message-ID: <1327598457-28261-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: Convert to asynchronous: device
	removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Convert libxl_FOO_device_remove, and the function which does the bulk
of the work, libxl__device_remove, to the new async ops scheme.

Adjust all callers.

Also remove libxl__wait_for_device_state which is now obsolete.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c                  |   60 +++++++++++-------
 tools/libxl/libxl.h                  |   16 ++++-
 tools/libxl/libxl_device.c           |  113 +++++++++------------------------
 tools/libxl/libxl_internal.h         |   30 ++--------
 tools/libxl/xl_cmdimpl.c             |    4 +-
 tools/ocaml/libs/xl/xenlight_stubs.c |    8 +-
 6 files changed, 92 insertions(+), 139 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59e8cb8..ec7b3ee 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1311,19 +1311,23 @@ out:
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
-                             libxl_device_disk *disk)
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    return AO_ABORT(rc);
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -1537,11 +1541,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 
     ret = 0;
 
-    libxl_device_disk_remove(ctx, domid, disks + i);
+    libxl_device_disk_remove(ctx, domid, disks + i, 0);
     libxl_device_disk_add(ctx, domid, disk);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
-        libxl_device_disk_remove(ctx, stubdomid, disks + i);
+        libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
         libxl_device_disk_add(ctx, stubdomid, disk);
     }
 out:
@@ -1760,19 +1764,23 @@ out:
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_nic *nic)
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    return AO_ABORT(rc);
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2100,19 +2108,23 @@ out:
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vkb *vkb)
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    return AO_ABORT(rc);
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2217,19 +2229,23 @@ out:
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vfb *vfb)
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    return AO_ABORT(rc);
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index fa79c24..508f9a5 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -467,7 +467,9 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
 /* Disks */
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
-int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -491,7 +493,9 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 /* Network Interfaces */
 int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
-int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -501,13 +505,17 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 /* Keyboard */
 int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
-int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
-int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5d05e90..9af1a17 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -357,85 +357,36 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
-/*
- * Returns 0 if a device is removed, ERROR_* if an error
- * or timeout occurred.
- */
-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;
-    unsigned int n;
-    fd_set rfds;
-    char **l1 = NULL;
-
-start:
-    rc = 1;
-    nfds = xs_fileno(ctx->xsh) + 1;
-    FD_ZERO(&rfds);
-    FD_SET(xs_fileno(ctx->xsh), &rfds);
-    switch (select(nfds, &rfds, NULL, NULL, tv)) {
-        case -1:
-            if (errno == EINTR)
-                goto start;
-            rc = ERROR_FAIL;
-            break;
-        case 0:
-            rc = ERROR_TIMEDOUT;
-            break;
-        default:
-            l1 = xs_read_watch(ctx->xsh, &n);
-            if (l1 != NULL) {
-                char *sstate = libxl__xs_read(gc, XBT_NULL,
-                                             l1[XS_WATCH_PATH]);
-                if (!sstate || atoi(sstate) == state) {
-                    /* Call handler function if present */
-                    if (handler)
-                        rc = handler(gc, l1, sstate);
-                } else {
-                    /* State is different than expected, continue waiting... */
-                    goto start;
-                }
-                free(l1);
-            } else {
-                rc = ERROR_FAIL;
-            }
-            break;
-    }
-    return rc;
-}
 
-/*
- * 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]);
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+} libxl__ao_device_remove;
+
+static void device_remove_cleanup(libxl__gc *gc,
+                                  libxl__ao_device_remove *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
 
-    return 0;
+static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                   int rc) {
+    libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl__ao_complete(egc, aorm->ao, rc);
+    device_remove_cleanup(gc, aorm);
 }
 
-/*
- * Returns 0 (device already destroyed) or 1 (caller must
- * wait_for_dev_destroy) on success, ERROR_* on fail.
- */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state = libxl__xs_read(gc, XBT_NULL, state_path);
     int rc = 0;
+    libxl__ao_device_remove *aorm = 0;
 
     if (!state)
         goto out;
@@ -458,23 +409,21 @@ retry_transaction:
         }
     }
 
-    xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    libxl__ev_devstate_init(&aorm->ds);
 
-out:
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
+                                 state_path, XenbusStateClosed,
+                                 LIBXL_DESTROY_TIMEOUT * 1000);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    device_remove_cleanup(gc, aorm);
     return rc;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 87490c1..3834c5c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -655,35 +655,15 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
-/* 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);
+/* Arranges that dev will be removed from its guest.  When
+ * this is done, the ao will be completed.  An error
+ * return from libxl__initiate_device_remove means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 92bb275..b42f296 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4646,7 +4646,7 @@ int main_networkdetach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_remove(ctx, domid, &nic)) {
+    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_del failed.\n");
         return 1;
     }
@@ -4741,7 +4741,7 @@ int main_blockdetach(int argc, char **argv)
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
     }
-    if (libxl_device_disk_remove(ctx, domid, &disk)) {
+    if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     }
     return 0;
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c b/tools/ocaml/libs/xl/xenlight_stubs.c
index 0944c56..59329f1 100644
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -247,7 +247,7 @@ value stub_xl_device_disk_del(value info, value domid)
 	device_disk_val(&gc, &lg, &c_info, info);
 
 	INIT_CTX();
-	ret = libxl_device_disk_remove(ctx, Int_val(domid), &c_info);
+	ret = libxl_device_disk_remove(ctx, Int_val(domid), &c_info, 0);
 	if (ret != 0)
 		failwith_xl("disk_del", &lg);
 	FREE_CTX();
@@ -281,7 +281,7 @@ value stub_xl_device_nic_del(value info, value domid)
 	device_nic_val(&gc, &lg, &c_info, info);
 
 	INIT_CTX();
-	ret = libxl_device_nic_remove(ctx, Int_val(domid), &c_info);
+	ret = libxl_device_nic_remove(ctx, Int_val(domid), &c_info, 0);
 	if (ret != 0)
 		failwith_xl("nic_del", &lg);
 	FREE_CTX();
@@ -316,7 +316,7 @@ value stub_xl_device_vkb_remove(value info, value domid)
 	device_vkb_val(&gc, &lg, &c_info, info);
 
 	INIT_CTX();
-	ret = libxl_device_vkb_remove(ctx, Int_val(domid), &c_info);
+	ret = libxl_device_vkb_remove(ctx, Int_val(domid), &c_info, 0);
 	if (ret != 0)
 		failwith_xl("vkb_clean_shutdown", &lg);
 	FREE_CTX();
@@ -370,7 +370,7 @@ value stub_xl_device_vfb_remove(value info, value domid)
 	device_vfb_val(&gc, &lg, &c_info, info);
 
 	INIT_CTX();
-	ret = libxl_device_vfb_remove(ctx, Int_val(domid), &c_info);
+	ret = libxl_device_vfb_remove(ctx, Int_val(domid), &c_info, 0);
 	if (ret != 0)
 		failwith_xl("vfb_clean_shutdown", &lg);
 	FREE_CTX();
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:21:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT1A-0001c6-Vk; Thu, 26 Jan 2012 17:21:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqT18-0001Z8-Tn
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:21:47 +0000
Received: from [85.158.138.51:41373] by server-5.bemta-3.messagelabs.com id
	CB/97-02363-AAB812F4; Thu, 26 Jan 2012 17:21:46 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327598484!10789891!10
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29312 invoked from network); 26 Jan 2012 17:21:45 -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;
	26 Jan 2012 17:21:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10311998"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:21: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, 26 Jan 2012 17:21: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
	1RqT16-0001cg-FC; Thu, 26 Jan 2012 17:21:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT16-0007QY-ET;
	Thu, 26 Jan 2012 17:21:44 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 17:20:57 +0000
Message-ID: <1327598457-28261-12-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-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/11] libxl: Convert to asynchronous: device
	removal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Convert libxl_FOO_device_remove, and the function which does the bulk
of the work, libxl__device_remove, to the new async ops scheme.

Adjust all callers.

Also remove libxl__wait_for_device_state which is now obsolete.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c                  |   60 +++++++++++-------
 tools/libxl/libxl.h                  |   16 ++++-
 tools/libxl/libxl_device.c           |  113 +++++++++------------------------
 tools/libxl/libxl_internal.h         |   30 ++--------
 tools/libxl/xl_cmdimpl.c             |    4 +-
 tools/ocaml/libs/xl/xenlight_stubs.c |    8 +-
 6 files changed, 92 insertions(+), 139 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59e8cb8..ec7b3ee 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1311,19 +1311,23 @@ out:
 }
 
 int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
-                             libxl_device_disk *disk)
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_disk(gc, domid, disk, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    return AO_ABORT(rc);
 }
 
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -1537,11 +1541,11 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk)
 
     ret = 0;
 
-    libxl_device_disk_remove(ctx, domid, disks + i);
+    libxl_device_disk_remove(ctx, domid, disks + i, 0);
     libxl_device_disk_add(ctx, domid, disk);
     stubdomid = libxl_get_stubdom_id(ctx, domid);
     if (stubdomid) {
-        libxl_device_disk_remove(ctx, stubdomid, disks + i);
+        libxl_device_disk_remove(ctx, stubdomid, disks + i, 0);
         libxl_device_disk_add(ctx, stubdomid, disk);
     }
 out:
@@ -1760,19 +1764,23 @@ out:
 }
 
 int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_nic *nic)
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_nic(gc, domid, nic, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    return AO_ABORT(rc);
 }
 
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2100,19 +2108,23 @@ out:
 }
 
 int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vkb *vkb)
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vkb(gc, domid, vkb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    return AO_ABORT(rc);
 }
 
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
@@ -2217,19 +2229,23 @@ out:
 }
 
 int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
-                            libxl_device_vfb *vfb)
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how)
 {
-    GC_INIT(ctx);
+    AO_CREATE(ctx, domid, ao_how);
     libxl__device device;
     int rc;
 
     rc = libxl__device_from_vfb(gc, domid, vfb, &device);
     if (rc != 0) goto out;
 
-    rc = libxl__device_remove(gc, &device, 1);
+    rc = libxl__initiate_device_remove(ao, &device);
+    if (rc) goto out;
+
+    return AO_INPROGRESS;
+
 out:
-    GC_FREE;
-    return rc;
+    return AO_ABORT(rc);
 }
 
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index fa79c24..508f9a5 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -467,7 +467,9 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm);
 /* Disks */
 int libxl_device_disk_init(libxl_ctx *ctx, libxl_device_disk *disk);
 int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
-int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk);
+int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
+                             libxl_device_disk *disk,
+                             const libxl_asyncop_how *ao_how);
 int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
                               libxl_device_disk *disk);
 
@@ -491,7 +493,9 @@ int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk *disk);
 /* Network Interfaces */
 int libxl_device_nic_init(libxl_ctx *ctx, libxl_device_nic *nic);
 int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
-int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
+int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_nic *nic,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_nic *nic);
 
 libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid, int *num);
@@ -501,13 +505,17 @@ int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
 /* Keyboard */
 int libxl_device_vkb_init(libxl_ctx *ctx, libxl_device_vkb *vkb);
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
-int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
+int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vkb *vkb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb);
 
 /* Framebuffer */
 int libxl_device_vfb_init(libxl_ctx *ctx, libxl_device_vfb *vfb);
 int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
-int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
+int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vfb *vfb,
+                            const libxl_asyncop_how *ao_how);
 int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb *vfb);
 
 /* PCI Passthrough */
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5d05e90..9af1a17 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -357,85 +357,36 @@ int libxl__device_disk_dev_number(const char *virtpath, int *pdisk,
     return -1;
 }
 
-/*
- * Returns 0 if a device is removed, ERROR_* if an error
- * or timeout occurred.
- */
-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;
-    unsigned int n;
-    fd_set rfds;
-    char **l1 = NULL;
-
-start:
-    rc = 1;
-    nfds = xs_fileno(ctx->xsh) + 1;
-    FD_ZERO(&rfds);
-    FD_SET(xs_fileno(ctx->xsh), &rfds);
-    switch (select(nfds, &rfds, NULL, NULL, tv)) {
-        case -1:
-            if (errno == EINTR)
-                goto start;
-            rc = ERROR_FAIL;
-            break;
-        case 0:
-            rc = ERROR_TIMEDOUT;
-            break;
-        default:
-            l1 = xs_read_watch(ctx->xsh, &n);
-            if (l1 != NULL) {
-                char *sstate = libxl__xs_read(gc, XBT_NULL,
-                                             l1[XS_WATCH_PATH]);
-                if (!sstate || atoi(sstate) == state) {
-                    /* Call handler function if present */
-                    if (handler)
-                        rc = handler(gc, l1, sstate);
-                } else {
-                    /* State is different than expected, continue waiting... */
-                    goto start;
-                }
-                free(l1);
-            } else {
-                rc = ERROR_FAIL;
-            }
-            break;
-    }
-    return rc;
-}
 
-/*
- * 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]);
+typedef struct {
+    libxl__ao *ao;
+    libxl__ev_devstate ds;
+} libxl__ao_device_remove;
+
+static void device_remove_cleanup(libxl__gc *gc,
+                                  libxl__ao_device_remove *aorm) {
+    if (!aorm) return;
+    libxl__ev_devstate_cancel(gc, &aorm->ds);
+}
 
-    return 0;
+static void device_remove_callback(libxl__egc *egc, libxl__ev_devstate *ds,
+                                   int rc) {
+    libxl__ao_device_remove *aorm = CONTAINER_OF(ds, *aorm, ds);
+    libxl__gc *gc = &aorm->ao->gc;
+    libxl__ao_complete(egc, aorm->ao, rc);
+    device_remove_cleanup(gc, aorm);
 }
 
-/*
- * Returns 0 (device already destroyed) or 1 (caller must
- * wait_for_dev_destroy) on success, ERROR_* on fail.
- */
-int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait)
+int libxl__initiate_device_remove(libxl__ao *ao, libxl__device *dev)
 {
+    AO_GC;
     libxl_ctx *ctx = libxl__gc_owner(gc);
     xs_transaction_t t;
     char *be_path = libxl__device_backend_path(gc, dev);
     char *state_path = libxl__sprintf(gc, "%s/state", be_path);
     char *state = libxl__xs_read(gc, XBT_NULL, state_path);
     int rc = 0;
+    libxl__ao_device_remove *aorm = 0;
 
     if (!state)
         goto out;
@@ -458,23 +409,21 @@ retry_transaction:
         }
     }
 
-    xs_watch(ctx->xsh, state_path, be_path);
     libxl__device_destroy_tapdisk(gc, be_path);
 
-    if (wait) {
-        struct timeval tv;
-        tv.tv_sec = LIBXL_DESTROY_TIMEOUT;
-        tv.tv_usec = 0;
-        rc = libxl__wait_for_device_state(gc, &tv, XenbusStateClosed,
-                                          destroy_device);
-        if (rc < 0) /* an error or timeout occurred, clear watches */
-            xs_unwatch(ctx->xsh, state_path, be_path);
-        xs_rm(ctx->xsh, XBT_NULL, libxl__device_frontend_path(gc, dev));
-    } else {
-        rc = 1; /* Caller must wait_for_dev_destroy */
-    }
+    aorm = libxl__zalloc(gc, sizeof(*aorm));
+    aorm->ao = ao;
+    libxl__ev_devstate_init(&aorm->ds);
 
-out:
+    rc = libxl__ev_devstate_wait(gc, &aorm->ds, device_remove_callback,
+                                 state_path, XenbusStateClosed,
+                                 LIBXL_DESTROY_TIMEOUT * 1000);
+    if (rc) goto out;
+
+    return 0;
+
+ out:
+    device_remove_cleanup(gc, aorm);
     return rc;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 87490c1..3834c5c 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -655,35 +655,15 @@ _hidden char *libxl__device_backend_path(libxl__gc *gc, libxl__device *device);
 _hidden char *libxl__device_frontend_path(libxl__gc *gc, libxl__device *device);
 _hidden int libxl__parse_backend_path(libxl__gc *gc, const char *path,
                                       libxl__device *dev);
-_hidden int libxl__device_remove(libxl__gc *gc, libxl__device *dev, int wait);
 _hidden int libxl__device_destroy(libxl__gc *gc, libxl__device *dev);
 _hidden int libxl__devices_destroy(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__wait_for_backend(libxl__gc *gc, char *be_path, char *state);
 
-/* 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);
+/* Arranges that dev will be removed from its guest.  When
+ * this is done, the ao will be completed.  An error
+ * return from libxl__initiate_device_remove means that the ao
+ * will _not_ be completed and the caller must do so. */
+_hidden int libxl__initiate_device_remove(libxl__ao*, libxl__device *dev);
 
 /*
  * libxl__ev_devstate - waits a given time for a device to
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 92bb275..b42f296 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4646,7 +4646,7 @@ int main_networkdetach(int argc, char **argv)
             return 1;
         }
     }
-    if (libxl_device_nic_remove(ctx, domid, &nic)) {
+    if (libxl_device_nic_remove(ctx, domid, &nic, 0)) {
         fprintf(stderr, "libxl_device_nic_del failed.\n");
         return 1;
     }
@@ -4741,7 +4741,7 @@ int main_blockdetach(int argc, char **argv)
         fprintf(stderr, "Error: Device %s not connected.\n", argv[optind+1]);
         return 1;
     }
-    if (libxl_device_disk_remove(ctx, domid, &disk)) {
+    if (libxl_device_disk_remove(ctx, domid, &disk, 0)) {
         fprintf(stderr, "libxl_device_disk_remove failed.\n");
     }
     return 0;
diff --git a/tools/ocaml/libs/xl/xenlight_stubs.c b/tools/ocaml/libs/xl/xenlight_stubs.c
index 0944c56..59329f1 100644
--- a/tools/ocaml/libs/xl/xenlight_stubs.c
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c
@@ -247,7 +247,7 @@ value stub_xl_device_disk_del(value info, value domid)
 	device_disk_val(&gc, &lg, &c_info, info);
 
 	INIT_CTX();
-	ret = libxl_device_disk_remove(ctx, Int_val(domid), &c_info);
+	ret = libxl_device_disk_remove(ctx, Int_val(domid), &c_info, 0);
 	if (ret != 0)
 		failwith_xl("disk_del", &lg);
 	FREE_CTX();
@@ -281,7 +281,7 @@ value stub_xl_device_nic_del(value info, value domid)
 	device_nic_val(&gc, &lg, &c_info, info);
 
 	INIT_CTX();
-	ret = libxl_device_nic_remove(ctx, Int_val(domid), &c_info);
+	ret = libxl_device_nic_remove(ctx, Int_val(domid), &c_info, 0);
 	if (ret != 0)
 		failwith_xl("nic_del", &lg);
 	FREE_CTX();
@@ -316,7 +316,7 @@ value stub_xl_device_vkb_remove(value info, value domid)
 	device_vkb_val(&gc, &lg, &c_info, info);
 
 	INIT_CTX();
-	ret = libxl_device_vkb_remove(ctx, Int_val(domid), &c_info);
+	ret = libxl_device_vkb_remove(ctx, Int_val(domid), &c_info, 0);
 	if (ret != 0)
 		failwith_xl("vkb_clean_shutdown", &lg);
 	FREE_CTX();
@@ -370,7 +370,7 @@ value stub_xl_device_vfb_remove(value info, value domid)
 	device_vfb_val(&gc, &lg, &c_info, info);
 
 	INIT_CTX();
-	ret = libxl_device_vfb_remove(ctx, Int_val(domid), &c_info);
+	ret = libxl_device_vfb_remove(ctx, Int_val(domid), &c_info, 0);
 	if (ret != 0)
 		failwith_xl("vfb_clean_shutdown", &lg);
 	FREE_CTX();
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT1t-00029J-EU; Thu, 26 Jan 2012 17:22: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 1RqT1r-00024U-Q1
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327598542!14058190!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13076 invoked from network); 26 Jan 2012 17:22: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;
	26 Jan 2012 17:22:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:22:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:22:22 +0000
Date: Thu, 26 Jan 2012 17:23:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
Message-ID: <alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
References: <patchbomb.1326880685@loki.upc.es>
	<b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
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 09 of 13 RFC] libxl: destroy devices before
 device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 18 Jan 2012, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1326728472 -3600
> # Node ID b5d63cf90d4ef8d222ae282e279b90b7f73f18c3
> # Parent  5849bf7c4507edbe900de00332f1218de2d9f45f
> libxl: destroy devices before device model
> 
> Destroying the device model before unplugging the devices prevented
> from doing a clean unplug, since libxl was waiting for dm  devices
> to shutdown when the userspace process was already killed.

I think that this change is correct but have you tested it with any
backends running in qemu?


> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 5849bf7c4507 -r b5d63cf90d4e tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 16 16:40:40 2012 +0100
> +++ b/tools/libxl/libxl.c	Mon Jan 16 16:41:12 2012 +0100
> @@ -802,15 +802,15 @@ int libxl_domain_destroy(libxl_ctx *ctx,
>      if (rc < 0) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
>      }
> +    if (libxl__devices_destroy(gc, domid) < 0)
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
> +                   "libxl__devices_destroy failed for %d", domid);
>      if (dm_present) {
>          if (libxl__destroy_device_model(gc, domid) < 0)
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
>  
>          libxl__qmp_cleanup(gc, domid);
>      }
> -    if (libxl__devices_destroy(gc, domid) < 0)
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
> -                   "libxl__devices_destroy failed for %d", domid);
>  
>      vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
>      if (vm_path)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT1t-00029J-EU; Thu, 26 Jan 2012 17:22: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 1RqT1r-00024U-Q1
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327598542!14058190!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13076 invoked from network); 26 Jan 2012 17:22: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;
	26 Jan 2012 17:22:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312018"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:22:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:22:22 +0000
Date: Thu, 26 Jan 2012 17:23:11 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
Message-ID: <alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
References: <patchbomb.1326880685@loki.upc.es>
	<b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
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 09 of 13 RFC] libxl: destroy devices before
 device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 18 Jan 2012, Roger Pau Monne wrote:
> # HG changeset patch
> # User Roger Pau Monne <roger.pau@entel.upc.edu>
> # Date 1326728472 -3600
> # Node ID b5d63cf90d4ef8d222ae282e279b90b7f73f18c3
> # Parent  5849bf7c4507edbe900de00332f1218de2d9f45f
> libxl: destroy devices before device model
> 
> Destroying the device model before unplugging the devices prevented
> from doing a clean unplug, since libxl was waiting for dm  devices
> to shutdown when the userspace process was already killed.

I think that this change is correct but have you tested it with any
backends running in qemu?


> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
> 
> diff -r 5849bf7c4507 -r b5d63cf90d4e tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 16 16:40:40 2012 +0100
> +++ b/tools/libxl/libxl.c	Mon Jan 16 16:41:12 2012 +0100
> @@ -802,15 +802,15 @@ int libxl_domain_destroy(libxl_ctx *ctx,
>      if (rc < 0) {
>          LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, rc, "xc_domain_pause failed for %d", domid);
>      }
> +    if (libxl__devices_destroy(gc, domid) < 0)
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
> +                   "libxl__devices_destroy failed for %d", domid);
>      if (dm_present) {
>          if (libxl__destroy_device_model(gc, domid) < 0)
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "libxl__destroy_device_model failed for %d", domid);
>  
>          libxl__qmp_cleanup(gc, domid);
>      }
> -    if (libxl__devices_destroy(gc, domid) < 0)
> -        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, 
> -                   "libxl__devices_destroy failed for %d", domid);
>  
>      vm_path = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc, "%s/vm", dom_path));
>      if (vm_path)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT27-0002Hy-U9; Thu, 26 Jan 2012 17:22:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT26-0002Gn-Dr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:46 +0000
Received: from [85.158.139.83:48052] by server-2.bemta-5.messagelabs.com id
	B8/11-07121-5EB812F4; Thu, 26 Jan 2012 17:22:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19016 invoked from network); 26 Jan 2012 17:22:44 -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;
	26 Jan 2012 17:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315950"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:22:42 -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 q0QHMdRq009803;
	Thu, 26 Jan 2012 09:22:41 -0800
MIME-Version: 1.0
X-Mercurial-Node: f8c3c44be309ab584c67c835a3a2db05dd3d7bd0
Message-ID: <f8c3c44be309ab584c67.1327598458@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:20:58 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 8] xenalyze: Improve record-sorting
	algorithm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 old method of finding the next record was to search through
all active pcpus to find the one with the lowest tsc value.  This
was simple but incredibly wasteful, especially as frequently the
same cpu had several records to process in a row, and only a small
subset of pcpus was active at any one time.

This patch introduces a sorted list, s.t. the top of the list is
always the next record to process.  After that record is processed,
the next record is found, and the record is then "bubbled down" to
its appropriate place on the list.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r d8c1c4df4535 -r f8c3c44be309 xenalyze.c
--- a/xenalyze.c	Thu Jan 12 14:27:56 2012 +0100
+++ b/xenalyze.c	Thu Jan 26 17:11:34 2012 +0000
@@ -6522,7 +6522,7 @@ void shadow_process(struct pcpu_info *p)
         if(sevt.minor <= PF_XEN_LAST_FAULT) {
             shadow_fault_generic_process(ri, h);
         } else {
-            fprintf(warn, "Warning: processing shadow as generic\n");
+            warn_once("Warning: processing shadow as generic\n");
             process_generic(ri);
         }
         break;
@@ -8558,6 +8558,10 @@ void base_process(struct pcpu_info *p) {
 
 
 /* Non-compat only */
+void record_order_insert(struct pcpu_info *new);
+void record_order_remove(struct pcpu_info *rem);
+void record_order_bubble(struct pcpu_info *last);
+
 struct cpu_change_data {
     int cpu;
     unsigned window_size;
@@ -8624,6 +8628,8 @@ loff_t scan_for_new_pcpu(loff_t offset) 
         p->file_offset = offset;
         p->next_cpu_change_offset = offset;
 
+        record_order_insert(p);
+
         offset += r + cd->window_size;
 
         sched_default_vcpu_activate(p);
@@ -8675,6 +8681,9 @@ void deactivate_pcpu(struct pcpu_info *p
         lose_vcpu(p->current, p->last_tsc);
     }
     p->active = 0;
+
+    record_order_remove(p);
+
     if ( p->pid == P.max_active_pcpu )
     {
         int i, max_active_pcpu = -1;
@@ -8840,11 +8849,6 @@ void process_cpu_change(struct pcpu_info
         if(r->cpu > P.max_active_pcpu)
             P.max_active_pcpu = r->cpu;
 
-        fprintf(warn, "%s: Activating pcpu %d at offset %lld\n",
-                __func__, r->cpu, (unsigned long long)p->file_offset);
-        
-        sched_default_vcpu_activate(p2);
-
         /* Taking this record as the first record should make everything
          * run swimmingly. */
         p2->ri = *ri;
@@ -8852,6 +8856,13 @@ void process_cpu_change(struct pcpu_info
         p2->ri.d = p2->ri.rec.u.notsc.data;
         p2->file_offset = p->file_offset;
         p2->next_cpu_change_offset = p->file_offset;
+
+        fprintf(warn, "%s: Activating pcpu %d at offset %lld\n",
+                __func__, r->cpu, (unsigned long long)p->file_offset);
+        
+        record_order_insert(p2);
+
+        sched_default_vcpu_activate(p2);
     }
 
     p->last_cpu_change_pid = r->cpu;
@@ -8979,6 +8990,7 @@ int toplevel_assert_check(int toplevel, 
         if ( ! (v->data_type == VCPU_DATA_NONE
                 || v->data_type == mask.vcpu_data_mode) )
         {
+            /* This may happen for track_dirty_vram, which causes a SHADOW_WRMAP_BF trace f/ dom0 */
             fprintf(warn, "WARNING: Unexpected vcpu data type for d%dv%d on proc %d! Expected %d got %d. Not processing\n",
                     v->d->did, v->vid, p->pid,
                     mask.vcpu_data_mode,
@@ -9317,31 +9329,102 @@ char * pcpu_string(int pcpu)
     return s;
 }
 
+/* Null terminated */
+struct pcpu_info *record_order[MAX_CPUS+1] = { 0 };
+
+/* In the case of identical tsc values, the old algorithm would favor the
+ * pcpu with the lowest number.  By default the new algorithm favors the
+ * pcpu which has been processed most recently.
+ *
+ * I think the second way is better; but it's good to be able to use the
+ * old ordering, at very lest to verify that there are no (other) ordering
+ * differences.  Enabling the below flag will cause the insertion / bubble
+ * routines to order by pcpu id as well as tsc, preserving the old order. */
+//#define PRESERVE_PCPU_ORDERING
+
+/* Steady state:
+ * + Entire list is in order, except (potentially) for the first entry
+ * + last is pointing to the first entry.
+ */
+void record_order_bubble(struct pcpu_info *last)
+{
+    int i;
+
+    /* Find the pcpu to "bubble".  This is usually the
+     * first one, but if other pcpus have been activated, it may
+     * not be. */
+    for(i=0; record_order[i] && record_order[i]!=last; i++);
+
+    assert(record_order[i]);
+
+    /* Now bubble it down */
+    for( ;
+        record_order[i+1]
+             && ( record_order[i+1]->order_tsc < last->order_tsc
+#ifdef PRESERVE_PCPU_ORDERING
+                  || ( record_order[i+1]->order_tsc == last->order_tsc
+                       && record_order[i+1]->pid < last->pid )
+#endif
+                 ) ;
+        i++)
+        record_order[i]=record_order[i+1];
+    record_order[i]=last;
+}
+
+void record_order_insert(struct pcpu_info *new)
+{
+    int i;
+    struct pcpu_info *p=NULL, *t=NULL;
+
+    /* Sanity check: Make sure it's not already in there */
+    for(i=0; record_order[i]; i++)
+        assert(record_order[i]!=new);
+
+    /* Find where to insert it */
+    for(i=0;
+        record_order[i]
+             && ( record_order[i]->order_tsc < new->order_tsc
+#ifdef PRESERVE_PCPU_ORDERING
+                  || ( record_order[i]->order_tsc == new->order_tsc
+                       && record_order[i]->pid < new->pid )
+#endif
+                 ) ;
+        i++)
+        ;
+
+    /* And insert it */
+    for( p=new; p ; i++)
+    {
+        t=record_order[i];
+        record_order[i]=p;
+        p=t;
+    }
+}
+
+void record_order_remove(struct pcpu_info *rem)
+{
+    int i;
+
+    /* Find where the record is */
+    for(i=0; record_order[i] && record_order[i]!=rem; i++)
+        ;
+
+    /* Sanity check: Make sure it's actually there! */
+    assert(record_order[i]);
+
+    /* And move everyone forward */
+    for(; (record_order[i]=record_order[i+1]); i++) 
+        ;
+}
+
 struct pcpu_info * choose_next_record(void)
 {
-    int i;
-    struct pcpu_info * p, *min_p=NULL;
-    loff_t min_offset = 0;
-
-    /* Need to:
-     * - find the pcpu with the lowest order_tsc
-     * - Find the lowest file offset
-     */
-    for(i=0; i<=P.max_active_pcpu; i++)
-    {
-        p = P.pcpu+i;
-        if(!p->active)
-            continue;
-
-        if(!min_p || p->order_tsc < min_p->order_tsc)
-            min_p = p;
-
-        if(!min_offset || p->file_offset < min_offset)
-            min_offset = p->file_offset;
-    }
-
-    if(opt.progress && min_offset >= G.progress.update_offset)
-        progress_update(min_offset);
+    struct pcpu_info *min_p=NULL;
+
+    min_p=record_order[0];
+
+    if(opt.progress && min_p && min_p->file_offset >= G.progress.update_offset)
+        progress_update(min_p->file_offset);
 
     /* If there are active pcpus, make sure we chose one */
     assert(min_p || (P.max_active_pcpu==-1));
@@ -9372,6 +9455,9 @@ void process_records(void) {
         else
             read_record(G.fd, p);
 
+        /* Update this pcpu in the processing order */
+        if ( p->active )
+            record_order_bubble(p);
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT27-0002Hy-U9; Thu, 26 Jan 2012 17:22:47 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT26-0002Gn-Dr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:46 +0000
Received: from [85.158.139.83:48052] by server-2.bemta-5.messagelabs.com id
	B8/11-07121-5EB812F4; Thu, 26 Jan 2012 17:22:45 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19016 invoked from network); 26 Jan 2012 17:22:44 -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;
	26 Jan 2012 17:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315950"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:42 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:22:42 -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 q0QHMdRq009803;
	Thu, 26 Jan 2012 09:22:41 -0800
MIME-Version: 1.0
X-Mercurial-Node: f8c3c44be309ab584c67c835a3a2db05dd3d7bd0
Message-ID: <f8c3c44be309ab584c67.1327598458@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:20:58 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 1 of 8] xenalyze: Improve record-sorting
	algorithm
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 old method of finding the next record was to search through
all active pcpus to find the one with the lowest tsc value.  This
was simple but incredibly wasteful, especially as frequently the
same cpu had several records to process in a row, and only a small
subset of pcpus was active at any one time.

This patch introduces a sorted list, s.t. the top of the list is
always the next record to process.  After that record is processed,
the next record is found, and the record is then "bubbled down" to
its appropriate place on the list.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r d8c1c4df4535 -r f8c3c44be309 xenalyze.c
--- a/xenalyze.c	Thu Jan 12 14:27:56 2012 +0100
+++ b/xenalyze.c	Thu Jan 26 17:11:34 2012 +0000
@@ -6522,7 +6522,7 @@ void shadow_process(struct pcpu_info *p)
         if(sevt.minor <= PF_XEN_LAST_FAULT) {
             shadow_fault_generic_process(ri, h);
         } else {
-            fprintf(warn, "Warning: processing shadow as generic\n");
+            warn_once("Warning: processing shadow as generic\n");
             process_generic(ri);
         }
         break;
@@ -8558,6 +8558,10 @@ void base_process(struct pcpu_info *p) {
 
 
 /* Non-compat only */
+void record_order_insert(struct pcpu_info *new);
+void record_order_remove(struct pcpu_info *rem);
+void record_order_bubble(struct pcpu_info *last);
+
 struct cpu_change_data {
     int cpu;
     unsigned window_size;
@@ -8624,6 +8628,8 @@ loff_t scan_for_new_pcpu(loff_t offset) 
         p->file_offset = offset;
         p->next_cpu_change_offset = offset;
 
+        record_order_insert(p);
+
         offset += r + cd->window_size;
 
         sched_default_vcpu_activate(p);
@@ -8675,6 +8681,9 @@ void deactivate_pcpu(struct pcpu_info *p
         lose_vcpu(p->current, p->last_tsc);
     }
     p->active = 0;
+
+    record_order_remove(p);
+
     if ( p->pid == P.max_active_pcpu )
     {
         int i, max_active_pcpu = -1;
@@ -8840,11 +8849,6 @@ void process_cpu_change(struct pcpu_info
         if(r->cpu > P.max_active_pcpu)
             P.max_active_pcpu = r->cpu;
 
-        fprintf(warn, "%s: Activating pcpu %d at offset %lld\n",
-                __func__, r->cpu, (unsigned long long)p->file_offset);
-        
-        sched_default_vcpu_activate(p2);
-
         /* Taking this record as the first record should make everything
          * run swimmingly. */
         p2->ri = *ri;
@@ -8852,6 +8856,13 @@ void process_cpu_change(struct pcpu_info
         p2->ri.d = p2->ri.rec.u.notsc.data;
         p2->file_offset = p->file_offset;
         p2->next_cpu_change_offset = p->file_offset;
+
+        fprintf(warn, "%s: Activating pcpu %d at offset %lld\n",
+                __func__, r->cpu, (unsigned long long)p->file_offset);
+        
+        record_order_insert(p2);
+
+        sched_default_vcpu_activate(p2);
     }
 
     p->last_cpu_change_pid = r->cpu;
@@ -8979,6 +8990,7 @@ int toplevel_assert_check(int toplevel, 
         if ( ! (v->data_type == VCPU_DATA_NONE
                 || v->data_type == mask.vcpu_data_mode) )
         {
+            /* This may happen for track_dirty_vram, which causes a SHADOW_WRMAP_BF trace f/ dom0 */
             fprintf(warn, "WARNING: Unexpected vcpu data type for d%dv%d on proc %d! Expected %d got %d. Not processing\n",
                     v->d->did, v->vid, p->pid,
                     mask.vcpu_data_mode,
@@ -9317,31 +9329,102 @@ char * pcpu_string(int pcpu)
     return s;
 }
 
+/* Null terminated */
+struct pcpu_info *record_order[MAX_CPUS+1] = { 0 };
+
+/* In the case of identical tsc values, the old algorithm would favor the
+ * pcpu with the lowest number.  By default the new algorithm favors the
+ * pcpu which has been processed most recently.
+ *
+ * I think the second way is better; but it's good to be able to use the
+ * old ordering, at very lest to verify that there are no (other) ordering
+ * differences.  Enabling the below flag will cause the insertion / bubble
+ * routines to order by pcpu id as well as tsc, preserving the old order. */
+//#define PRESERVE_PCPU_ORDERING
+
+/* Steady state:
+ * + Entire list is in order, except (potentially) for the first entry
+ * + last is pointing to the first entry.
+ */
+void record_order_bubble(struct pcpu_info *last)
+{
+    int i;
+
+    /* Find the pcpu to "bubble".  This is usually the
+     * first one, but if other pcpus have been activated, it may
+     * not be. */
+    for(i=0; record_order[i] && record_order[i]!=last; i++);
+
+    assert(record_order[i]);
+
+    /* Now bubble it down */
+    for( ;
+        record_order[i+1]
+             && ( record_order[i+1]->order_tsc < last->order_tsc
+#ifdef PRESERVE_PCPU_ORDERING
+                  || ( record_order[i+1]->order_tsc == last->order_tsc
+                       && record_order[i+1]->pid < last->pid )
+#endif
+                 ) ;
+        i++)
+        record_order[i]=record_order[i+1];
+    record_order[i]=last;
+}
+
+void record_order_insert(struct pcpu_info *new)
+{
+    int i;
+    struct pcpu_info *p=NULL, *t=NULL;
+
+    /* Sanity check: Make sure it's not already in there */
+    for(i=0; record_order[i]; i++)
+        assert(record_order[i]!=new);
+
+    /* Find where to insert it */
+    for(i=0;
+        record_order[i]
+             && ( record_order[i]->order_tsc < new->order_tsc
+#ifdef PRESERVE_PCPU_ORDERING
+                  || ( record_order[i]->order_tsc == new->order_tsc
+                       && record_order[i]->pid < new->pid )
+#endif
+                 ) ;
+        i++)
+        ;
+
+    /* And insert it */
+    for( p=new; p ; i++)
+    {
+        t=record_order[i];
+        record_order[i]=p;
+        p=t;
+    }
+}
+
+void record_order_remove(struct pcpu_info *rem)
+{
+    int i;
+
+    /* Find where the record is */
+    for(i=0; record_order[i] && record_order[i]!=rem; i++)
+        ;
+
+    /* Sanity check: Make sure it's actually there! */
+    assert(record_order[i]);
+
+    /* And move everyone forward */
+    for(; (record_order[i]=record_order[i+1]); i++) 
+        ;
+}
+
 struct pcpu_info * choose_next_record(void)
 {
-    int i;
-    struct pcpu_info * p, *min_p=NULL;
-    loff_t min_offset = 0;
-
-    /* Need to:
-     * - find the pcpu with the lowest order_tsc
-     * - Find the lowest file offset
-     */
-    for(i=0; i<=P.max_active_pcpu; i++)
-    {
-        p = P.pcpu+i;
-        if(!p->active)
-            continue;
-
-        if(!min_p || p->order_tsc < min_p->order_tsc)
-            min_p = p;
-
-        if(!min_offset || p->file_offset < min_offset)
-            min_offset = p->file_offset;
-    }
-
-    if(opt.progress && min_offset >= G.progress.update_offset)
-        progress_update(min_offset);
+    struct pcpu_info *min_p=NULL;
+
+    min_p=record_order[0];
+
+    if(opt.progress && min_p && min_p->file_offset >= G.progress.update_offset)
+        progress_update(min_p->file_offset);
 
     /* If there are active pcpus, make sure we chose one */
     assert(min_p || (P.max_active_pcpu==-1));
@@ -9372,6 +9455,9 @@ void process_records(void) {
         else
             read_record(G.fd, p);
 
+        /* Update this pcpu in the processing order */
+        if ( p->active )
+            record_order_bubble(p);
     }
 }
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT29-0002JS-5e; Thu, 26 Jan 2012 17:22:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT27-0002Hi-TJ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:48 +0000
Received: from [85.158.139.83:48187] by server-4.bemta-5.messagelabs.com id
	82/9B-09697-7EB812F4; Thu, 26 Jan 2012 17:22:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19180 invoked from network); 26 Jan 2012 17:22:46 -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;
	26 Jan 2012 17:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315952"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:22:45 -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 q0QHMdRu009803;
	Thu, 26 Jan 2012 09:22:44 -0800
MIME-Version: 1.0
X-Mercurial-Node: 4b3639bd32550d40bfc4b6bbca971c624118f108
Message-ID: <4b3639bd32550d40bfc4.1327598462@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:02 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 5 of 8] xenalyze: Rework math to remove two
	64-bit divisions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

abs_cycles_to_time is called on every record for dump mode; it has
four 64-bit divisions (well, 3 divisions and 1 mod), which map to
library functions on a 32-bit platform.  A simple rework of the math
can eliminate two of those.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 0663e3e8f69d -r 4b3639bd3255 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:16:59 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:17:19 2012 +0000
@@ -1976,16 +1976,19 @@ void cpumask_union(cpu_mask_t *d, const 
 /* -- Time code -- */
 
 void cycles_to_time(unsigned long long c, struct time_struct *t) {
-    t->time = ((c) * 1000) / (opt.cpu_hz / 1000000 );    
-    t->s = t->time / 1000000000;                        
-    t->ns = t->time % 1000000000;                       
+    t->time = ((c - P.f.first_tsc) * 1000 * 1000000) / opt.cpu_hz;
+    t->s = t->time / 1000000000;
+    t->ns = t->time - (t->s * 1000000000);
 }
 
 void abs_cycles_to_time(unsigned long long ac, struct time_struct *t) {
     if(ac > P.f.first_tsc) {
-        t->time = ((ac - P.f.first_tsc) * 1000) / (opt.cpu_hz / 1000000 );    
-        t->s = t->time / 1000000000;                        
-        t->ns = t->time % 1000000000;
+        /* t->time = ((ac - P.f.first_tsc) * 1000) / (opt.cpu_hz / 1000000 );     */
+        /* t->s = t->time / 1000000000;                         */
+        /* t->ns = t->time % 1000000000; */
+        t->time = ((ac - P.f.first_tsc) * 1000 * 1000000) / opt.cpu_hz;
+        t->s = t->time / 1000000000;
+        t->ns = t->time - (t->s * 1000000000);
     } else {
         t->time = t->s = t->ns = 0;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT29-0002JS-5e; Thu, 26 Jan 2012 17:22:49 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT27-0002Hi-TJ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:48 +0000
Received: from [85.158.139.83:48187] by server-4.bemta-5.messagelabs.com id
	82/9B-09697-7EB812F4; Thu, 26 Jan 2012 17:22:47 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19180 invoked from network); 26 Jan 2012 17:22:46 -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;
	26 Jan 2012 17:22:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315952"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:22:45 -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 q0QHMdRu009803;
	Thu, 26 Jan 2012 09:22:44 -0800
MIME-Version: 1.0
X-Mercurial-Node: 4b3639bd32550d40bfc4b6bbca971c624118f108
Message-ID: <4b3639bd32550d40bfc4.1327598462@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:02 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 5 of 8] xenalyze: Rework math to remove two
	64-bit divisions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

abs_cycles_to_time is called on every record for dump mode; it has
four 64-bit divisions (well, 3 divisions and 1 mod), which map to
library functions on a 32-bit platform.  A simple rework of the math
can eliminate two of those.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 0663e3e8f69d -r 4b3639bd3255 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:16:59 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:17:19 2012 +0000
@@ -1976,16 +1976,19 @@ void cpumask_union(cpu_mask_t *d, const 
 /* -- Time code -- */
 
 void cycles_to_time(unsigned long long c, struct time_struct *t) {
-    t->time = ((c) * 1000) / (opt.cpu_hz / 1000000 );    
-    t->s = t->time / 1000000000;                        
-    t->ns = t->time % 1000000000;                       
+    t->time = ((c - P.f.first_tsc) * 1000 * 1000000) / opt.cpu_hz;
+    t->s = t->time / 1000000000;
+    t->ns = t->time - (t->s * 1000000000);
 }
 
 void abs_cycles_to_time(unsigned long long ac, struct time_struct *t) {
     if(ac > P.f.first_tsc) {
-        t->time = ((ac - P.f.first_tsc) * 1000) / (opt.cpu_hz / 1000000 );    
-        t->s = t->time / 1000000000;                        
-        t->ns = t->time % 1000000000;
+        /* t->time = ((ac - P.f.first_tsc) * 1000) / (opt.cpu_hz / 1000000 );     */
+        /* t->s = t->time / 1000000000;                         */
+        /* t->ns = t->time % 1000000000; */
+        t->time = ((ac - P.f.first_tsc) * 1000 * 1000000) / opt.cpu_hz;
+        t->s = t->time / 1000000000;
+        t->ns = t->time - (t->s * 1000000000);
     } else {
         t->time = t->s = t->ns = 0;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqT28-0002IX-Fg; Thu, 26 Jan 2012 17:22:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT26-0002Gx-NP
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:47 +0000
Received: from [85.158.139.83:48132] by server-7.bemta-5.messagelabs.com id
	E2/24-26429-6EB812F4; Thu, 26 Jan 2012 17:22:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19078 invoked from network); 26 Jan 2012 17:22:44 -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;
	26 Jan 2012 17:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315951"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:44 -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, 26 Jan 2012 12:22:44 -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 q0QHMdRs009803;
	Thu, 26 Jan 2012 09:22:43 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6772e9e46ab2d444aa70135e4bd118f287e47e5f
Message-ID: <6772e9e46ab2d444aa70.1327598460@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:00 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 8] xenalyze: Remove --dump-cooked
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Remove a vestigal option that hasn't been used or maintained in years.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 2ab3da778828 -r 6772e9e46ab2 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:16:32 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:16:35 2012 +0000
@@ -156,7 +156,6 @@ struct {
         scatterplot_irq:1,
         histogram_interrupt_eip:1,
         interval_mode:1,
-        dump_cooked:1,
         dump_all:1,
         dump_raw_process:1,
         dump_raw_reads:1,
@@ -231,7 +230,6 @@ struct {
     .scatterplot_rdtsc=0,
     .scatterplot_irq=0,
     .histogram_interrupt_eip=0,
-    .dump_cooked = 0,
     .dump_all = 0,
     .dump_raw_process = 0,
     .dump_raw_reads = 0,
@@ -3425,30 +3423,6 @@ void hvm_pf_xen_postprocess(struct hvm_d
         /* Set summary handler */
         hvm_set_summary_handler(h, hvm_pf_xen_summary, NULL);
     }
-
-    if(opt.dump_cooked)
-    {
-        switch(e->pf_case)
-        {
-        case PF_XEN_EMULATE:
-            printf(" %s pf_xen:emulate va %llx ec %x eip %llx%s lvl %d corr %llx\n",
-                   h->dump_header, e->va, e->error_code,
-                   h->rip, find_symbol(h->rip),
-                   e->pt_level, e->corresponding_va);
-            break;
-        case PF_XEN_MMIO:
-            printf(" %s pf_xen:mmio va %llx ec %x eip %llx%s data %x\n",
-                   h->dump_header, e->va, e->error_code,
-                   h->rip, find_symbol(h->rip),
-                   e->data);
-            break;
-        default:
-            printf(" %s pf_xen va %llx ec %x eip %llx%s\n",
-                   h->dump_header, e->va, e->error_code,
-                   h->rip, find_symbol(h->rip));
-            break;
-        }
-    }
 }
 
 void hvm_pf_xen_process(struct record_info *ri, struct hvm_data *h) {
@@ -3610,7 +3584,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
 
         o->count++;
 
-        if((opt.dump_all || opt.dump_cooked)
+        if((opt.dump_all)
 #if 0
            && (ov->runstate.state != RUNSTATE_RUNNING
                || ov->hvm.vmexit_valid) 
@@ -3624,7 +3598,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
     }
 
     if(m->is_write) {
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             printf("              [vla] d%dv%d icr vec %d %s\n",
                    h->v->d->did, h->v->vid,
                    icr.vec,
@@ -3655,7 +3629,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
         }
     } else {
         /* Read */
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             printf("              [vla] d%dv%d icr status %s\n",
                    h->v->d->did, h->v->vid,
                    icr.delivery_status?"pending":"idle");
@@ -3683,7 +3657,7 @@ void hvm_vlapic_inject(struct vcpu_data 
 }
 
 void hvm_vlapic_eoi_handler(struct hvm_data *h) {
-    if(opt.dump_all || opt.dump_cooked)
+    if(opt.dump_all)
         printf("              [vla] d%dv%d eoi\n",
                h->v->d->did, h->v->vid);
 }
@@ -3834,7 +3808,7 @@ void hvm_inj_virq_process(struct record_
         int vector, fake;
     } *r = (typeof(r))h->d;
 
-    if(opt.dump_cooked | opt.dump_all) {
+    if(opt.dump_all) {
         printf(" %s inj_virq vec %u  %s\n",
                ri->dump_header,
                r->vector, r->fake?"fake":"real");
@@ -3956,24 +3930,12 @@ void hvm_io_address_summary(struct io_ad
 
 void hvm_io_write_postprocess(struct hvm_data *h)
 {
-    if(opt.dump_cooked)
-    {
-        printf(" %s io_write port %x val %x\n",
-               h->dump_header, h->inflight.io.port,
-               h->inflight.io.val);
-    }
     if(opt.with_pio_enumeration)
         update_io_address(&h->summary.io.pio, h->inflight.io.port, 1, h->arc_cycles, 0);
 }
 
 void hvm_io_read_postprocess(struct hvm_data *h)
 {
-    if(opt.dump_cooked)
-    {
-        printf(" %s io_read port %x val %x\n",
-               h->dump_header, h->inflight.io.port,
-               h->inflight.io.val);
-    }
     if(opt.with_pio_enumeration)
         update_io_address(&h->summary.io.pio, h->inflight.io.port, 0, h->arc_cycles, 0);
     if(opt.scatterplot_io && h->inflight.io.port == opt.scatterplot_io_port)
@@ -4275,24 +4237,6 @@ void hvm_cr_write_postprocess(struct hvm
                 }
                 flush=1;
             }
-
-            if(opt.dump_cooked)
-            {
-                printf(" %s cr_write cr3 val %llx oval %llx (%d resyncs) %s\n",
-                       h->dump_header, 
-                       new_val,
-                       oval,
-                       h->resyncs,
-                       flush?"flush":"");
-            }
-        } else {
-            if(opt.dump_cooked)
-            {
-                printf(" %s cr_write cr3 val %llx (%d resyncs)\n",
-                       h->dump_header, 
-                       h->inflight.cr_write.val,
-                       h->resyncs);
-            }
         }
 
         if(opt.summary_info) {
@@ -4313,14 +4257,6 @@ void hvm_cr_write_postprocess(struct hvm
         if(!flush)
             cr3_switch(new_val, h);
     } else {
-        if(opt.dump_cooked)
-        {
-            printf(" %s cr_write cr%d val %llx\n",
-                   h->dump_header, 
-                   h->inflight.cr_write.cr,
-                   h->inflight.cr_write.val);
-        }
-
         if(opt.summary_info)
         {
             if(h->inflight.cr_write.cr < CR_MAX)
@@ -4420,14 +4356,6 @@ void hvm_msr_write_summary(struct hvm_da
 
 void hvm_msr_write_postprocess(struct hvm_data *h)
 {
-    if(opt.dump_cooked)
-    {
-        printf(" %s msr_write msr %d val %llx\n",
-               h->dump_header, 
-               h->inflight.msr.addr,
-               h->inflight.msr.val);
-    }
-
     if(opt.summary_info) {
     }
 
@@ -4466,14 +4394,6 @@ void hvm_msr_read_summary(struct hvm_dat
 
 void hvm_msr_read_postprocess(struct hvm_data *h)
 {
-    if(opt.dump_cooked)
-    {
-        printf(" %s msr_read msr %d val %llx\n",
-               h->dump_header, 
-               h->inflight.msr.addr,
-               h->inflight.msr.val);
-    }
-
     if(opt.summary_info) {
     }
 
@@ -4564,7 +4484,7 @@ void hvm_inj_exc_process(struct record_i
         unsigned vec, ec;
     } *r = (typeof(r))h->d;
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
         if(r->vec < HVM_TRAP_MAX)
             printf(" %3u.%09u %s inj_exc trap %s ec %x\n",
@@ -4620,7 +4540,7 @@ void hvm_intr_process(struct hvm_data *h
 
     h->inflight.intr.vec = vec;
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
         if ( vec < EXTERNAL_INTERRUPT_MAX &&
              hvm_extint_vector_name[vec] )
@@ -4742,7 +4662,7 @@ void hvm_pf_inject_process(struct record
         ec = r->x32.ec;
     }
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
             printf(" %3u.%09u %s pf_inject%s guest_cr2 %llx  guest_ec %x\n",
                    ri->t.s, ri->t.ns, pcpu_string(ri->cpu),
@@ -4938,7 +4858,7 @@ void hvm_handler_process(struct record_i
         hvm_pf_inject_process(ri, h);
         break;
     case TRC_HVM_REINJ_VIRQ:
-        if ( opt.dump_cooked || opt.dump_all )
+        if ( opt.dump_all )
         {
             printf(" %3u.%09u %s inj_virq vec %u\n",
                    ri->t.s, ri->t.ns, pcpu_string(ri->cpu),
@@ -4964,7 +4884,7 @@ void hvm_handler_process(struct record_i
         } else if(opt.with_cr3_enumeration) {
             fprintf(warn, "Warning: destroy_proc: don't know current cr3\n");
         }
-        if ( opt.dump_cooked || opt.dump_all )
+        if ( opt.dump_all )
         {
             printf(" %3u.%09u %s destroy_proc cur_cr3 %llx\n",
                    ri->t.s, ri->t.ns, pcpu_string(ri->cpu), h->v->cr3.val);
@@ -5681,18 +5601,6 @@ void shadow_emulate_postprocess(struct h
         hvm_update_short_summary(h, HVM_SHORT_SUMMARY_EMULATE);
     }
 
-    if ( opt.dump_cooked )
-    {
-        printf(" %s emulate va %llx eip %llx%s lvl %d/%d corr %llx wval %llx flags %s\n",
-               h->dump_header, e->va,
-               h->rip, find_symbol(h->rip),
-               e->pt_level, h->v->guest_paging_levels,
-               e->corresponding_va,
-               e->wval,
-               flag_string(e));
-    }
-
-
     if(opt.scatterplot_unpin_promote) {
         if(e->flag_early_unshadow)
             scatterplot_vs_time(h->exit_tsc, -10);
@@ -5906,14 +5814,6 @@ void shadow_unsync_postprocess(struct hv
             update_summary(&h->summary.pf_xen_unsync[h->resyncs],
                            h->arc_cycles);
     }
-
-    if(opt.dump_cooked)
-    {
-        printf(" %s unsync gfn %llx %s (%d resyncs)\n",
-               h->dump_header, e->gfn,
-               h->resyncs?"(resync)":"",
-               h->resyncs);
-    }
 }
 
 
@@ -6013,17 +5913,6 @@ void shadow_fixup_postprocess(struct hvm
             hvm_update_short_summary(h, HVM_SHORT_SUMMARY_FIXUP);
     }
 
-    if ( opt.dump_cooked )
-    {
-        printf(" %s fixup%s va %llx eip %llx%s gl1e %llx flags %s\n",
-               h->dump_header,
-               e->flag_unsync?":unsync":"",
-               e->va,
-               h->rip, find_symbol(h->rip),
-               e->gl1e,
-               flag_string(e));
-    }
-
     if(opt.scatterplot_unpin_promote) {
         if(h->prealloc_unpin)
             scatterplot_vs_time(h->exit_tsc, 0);
@@ -6133,8 +6022,6 @@ void shadow_fixup_process(struct record_
 void shadow_mmio_postprocess(struct hvm_data *h)
 {
     struct pf_xen_extra *e = &h->inflight.pf_xen;
-    struct mmio_info *m = &h->inflight.mmio;
-
     if ( opt.summary_info )
     {
         if(e->pf_case)
@@ -6148,28 +6035,6 @@ void shadow_mmio_postprocess(struct hvm_
 
     if(opt.with_mmio_enumeration)
         enumerate_mmio(h);
-
-    if ( opt.dump_cooked )
-    {
-        if(m->data_valid)
-            printf(" %s %smmio %s va %llx eip %llx%s gpa %llx data %x\n",
-                   h->dump_header,
-                   (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
-                   m->is_write?"write":"read",
-                   e->va,
-                   h->rip, find_symbol(h->rip),
-                   m->gpa,
-                   m->data);
-        else
-            printf(" %s %smmio %s va %llx eip %llx%s gpa %llx (no data)\n",
-                   h->dump_header,
-                   (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
-                   m->is_write?"write":"read",
-                   m->va,
-                   h->rip, find_symbol(h->rip),
-                   m->gpa);
-    }
-
 }
 
 void shadow_mmio_process(struct record_info *ri, struct hvm_data *h)
@@ -6403,7 +6268,7 @@ void shadow_resync_process(struct record
         unsigned long long gfn;
     } *r = (typeof(r))ri->d;
 
-    if(opt.dump_all || opt.dump_cooked)
+    if(opt.dump_all)
         printf(" %s oos resync %s gfn %llx\n",
                ri->dump_header,
                (ri->event == TRC_SHADOW_RESYNC_FULL)?"full":"only",
@@ -6417,7 +6282,7 @@ void shadow_prealloc_unpin_process(struc
         unsigned long long gfn;
     } *r = (typeof(r))ri->d;
 
-    if(opt.dump_all || opt.dump_cooked)
+    if(opt.dump_all)
         printf(" %s prealloc-unpin gfn %llx\n",
                ri->dump_header, r->gfn);
 
@@ -6435,7 +6300,7 @@ void shadow_wrmap_bf_process(struct reco
         unsigned long long gfn;
     } *r = (typeof(r))ri->d;
 
-    if(opt.dump_all || opt.dump_cooked)
+    if(opt.dump_all)
         printf(" %s wrmap-bf gfn %llx\n",
                ri->dump_header, r->gfn);
 
@@ -6569,7 +6434,7 @@ void pv_hypercall_process(struct record_
             pv->hypercall_count[eax]++;
     }
 
-    if(opt.dump_cooked || opt.dump_all) {
+    if(opt.dump_all) {
         if(eax < HYPERCALL_MAX)
             printf(" %s hypercall %2x (%s) eip %llx\n",
                    ri->dump_header, eax,
@@ -6616,7 +6481,7 @@ void pv_trap_process(struct record_info 
             pv->trap_count[trapnr]++;
     }
 
-    if(opt.dump_cooked || opt.dump_all) {
+    if(opt.dump_all) {
         printf(" %s trap %x eip %llx",
                ri->dump_header, trapnr, eip);
         if(use_ec)
@@ -6673,7 +6538,7 @@ void pv_ptwr_emulation_process(struct re
         return;
     }
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
         printf(" %s ptwr l1e %llx eip %llx addr %llx\n",
                ri->dump_header,
@@ -6711,7 +6576,7 @@ void pv_update_va_mapping_process(struct
         e.flags = r->x32.flags;
     }
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
         printf(" %s update_va_mapping l1e %llx va %llx flags %llx\n",
                ri->dump_header,
@@ -6721,7 +6586,7 @@ void pv_update_va_mapping_process(struct
 
 void pv_generic_process(struct record_info *ri, struct pv_data *pv) {
     union pv_event pevt = { .event = ri->event };
-    if ( opt.dump_cooked || opt.dump_all ) {
+    if ( opt.dump_all ) {
         if(pevt.minor < PV_MAX && pv_name[pevt.minor])
             printf(" %s %s",
                    ri->dump_header,
@@ -7145,7 +7010,7 @@ void sched_runstate_process(struct pcpu_
 
     perfctrs = (ri->extra_words == 5);
 
-    if(opt.dump_cooked || opt.dump_all) {
+    if(opt.dump_all) {
         if( perfctrs ) {
             printf(" %s %s {%lld,%lld} d%uv%u %s->%s\n",
                    ri->dump_header,
@@ -7199,9 +7064,6 @@ void sched_runstate_process(struct pcpu_
     if(sevt.new_runstate == RUNSTATE_RUNNABLE
        && v->data_type == VCPU_DATA_HVM
        && v->hvm.vmexit_valid) {
-        if(opt.dump_cooked)
-            printf("%s: d%dv%d changing to state runnable, closing vmexit\n",
-                   __func__, r->dom, r->vcpu);
         hvm_close_vmexit(&v->hvm, ri->tsc);
     }
      
@@ -7408,7 +7270,7 @@ update:
 
             cpi = ((double)run_cycles) / run_instr;
 
-            if(opt.dump_cooked || opt.dump_all) {
+            if(opt.dump_all) {
                 printf("   cpi: %2.2lf ( %lld / %lld )\n",
                        cpi, run_cycles, run_instr);
             }
@@ -7485,7 +7347,7 @@ void sched_switch_process(struct pcpu_in
         unsigned int prev_dom, prev_vcpu, next_dom, next_vcpu;
     } * r = (typeof(r))ri->d;
 
-    if(opt.dump_cooked || opt.dump_all)
+    if(opt.dump_all)
         printf("%s sched_switch prev d%uv%u next d%uv%u\n",
                ri->dump_header,
                r->prev_dom, r->prev_vcpu,
@@ -7786,7 +7648,7 @@ void mem_process(struct pcpu_info *p) {
         mem_pod_superpage_splinter_process(p);
         break;
     default:
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             dump_generic(stdout, ri);
         }
 
@@ -7848,7 +7710,7 @@ void pm_process(struct pcpu_info *p) {
         pcpu_string_draw(p);
         break;
     default:
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             dump_generic(stdout, ri);
         }
         break;
@@ -8209,7 +8071,7 @@ void irq_process(struct pcpu_info *p) {
     case TRC_HW_IRQ_CLEAR_VECTOR:
     case TRC_HW_IRQ_MOVE_FINISH :
     default:
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             dump_generic(stdout, ri);
         }
         break;
@@ -8311,7 +8173,7 @@ void process_generic(struct record_info 
 
     error(ERR_STRICT, ri);
 
-    if(opt.dump_cooked || opt.dump_all) {
+    if(opt.dump_all) {
         dump_generic(stdout, ri);
     }
 }
@@ -8384,7 +8246,7 @@ void process_lost_records(struct pcpu_in
 
     first_tsc = r->first_tsc;
 
-    if(opt.dump_cooked || opt.dump_all)
+    if(opt.dump_all)
     {
         if(p->current)
             printf(" %s lost_records count %d d%uv%u (cur d%dv%d) first_tsc %lld\n",
@@ -8490,7 +8352,7 @@ void process_lost_records_end(struct pcp
      * Update the information. */
     if(ri->tsc > p->lost_record.tsc)
     {
-        if(opt.dump_cooked || opt.dump_all)
+        if(opt.dump_all)
             printf("               %s lost_records end ---\n",
                    pcpu_string(p->pid));
 
@@ -8500,7 +8362,7 @@ void process_lost_records_end(struct pcp
             int did = p->lost_record.did,
                 vid = p->lost_record.vid;
 
-            if(opt.dump_cooked || opt.dump_all)
+            if(opt.dump_all)
                 printf("               %s lost_records end d%dv%d---\n",
                        pcpu_string(p->pid),
                        did, vid);
@@ -8523,7 +8385,7 @@ void process_lost_records_end(struct pcp
             p->lost_record.seen_valid_schedule=0; /* Let next vcpu_next_update know that
                                                      this one was inferred */
         } else {
-            if(opt.dump_cooked || opt.dump_all)
+            if(opt.dump_all)
                 printf("               %s lost_records end (domain invalid)---\n",
                        pcpu_string(p->pid));
         }
@@ -9026,7 +8888,7 @@ void process_record(struct pcpu_info *p)
 
     process_record_tsc(p->order_tsc, ri);
 
-    if(opt.dump_cooked || opt.dump_all) 
+    if(opt.dump_all) 
         create_dump_header(ri, p);
 
 
@@ -9592,7 +9454,6 @@ void init_pcpus(void) {
 enum {
     OPT_NULL=0,
     /* Dumping info */
-    OPT_DUMP_COOKED,
     OPT_DUMP_RAW_READS,
     OPT_DUMP_RAW_PROCESS,
     OPT_DUMP_NO_PROCESSING,
@@ -9765,10 +9626,6 @@ error_t cmd_parser(int key, char *arg, s
     switch (key)
     {
         /* Dump group */
-    case OPT_DUMP_COOKED:
-        opt.dump_cooked = 1;
-        G.output_defined = 1;
-        break;
     case OPT_DUMP_ALL:
         opt.dump_all = 1;
         G.output_defined = 1;
@@ -10157,11 +10014,6 @@ error_t cmd_parser(int key, char *arg, s
 
 const struct argp_option cmd_opts[] =  {
     /* Dump group */
-    { .name = "dump-cooked",
-      .key = OPT_DUMP_COOKED,
-      .group = OPT_GROUP_DUMP,
-      .doc = "Dump a sanitized summary of vmexit/vmentry.", },
-
     { .name = "dump-all",
       .key = OPT_DUMP_ALL,
       .group = OPT_GROUP_DUMP,
@@ -10453,7 +10305,7 @@ int main(int argc, char *argv[]) {
     if (G.symbol_file != NULL)
         parse_symbol_file(G.symbol_file);
 
-    if(opt.dump_cooked || opt.dump_all)
+    if(opt.dump_all)
         warn = stdout;
         
     init_pcpus();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 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 1RqT28-0002IX-Fg; Thu, 26 Jan 2012 17:22:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT26-0002Gx-NP
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:47 +0000
Received: from [85.158.139.83:48132] by server-7.bemta-5.messagelabs.com id
	E2/24-26429-6EB812F4; Thu, 26 Jan 2012 17:22:46 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19078 invoked from network); 26 Jan 2012 17:22:44 -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;
	26 Jan 2012 17:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315951"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:44 -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, 26 Jan 2012 12:22:44 -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 q0QHMdRs009803;
	Thu, 26 Jan 2012 09:22:43 -0800
MIME-Version: 1.0
X-Mercurial-Node: 6772e9e46ab2d444aa70135e4bd118f287e47e5f
Message-ID: <6772e9e46ab2d444aa70.1327598460@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:00 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 3 of 8] xenalyze: Remove --dump-cooked
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Remove a vestigal option that hasn't been used or maintained in years.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 2ab3da778828 -r 6772e9e46ab2 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:16:32 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:16:35 2012 +0000
@@ -156,7 +156,6 @@ struct {
         scatterplot_irq:1,
         histogram_interrupt_eip:1,
         interval_mode:1,
-        dump_cooked:1,
         dump_all:1,
         dump_raw_process:1,
         dump_raw_reads:1,
@@ -231,7 +230,6 @@ struct {
     .scatterplot_rdtsc=0,
     .scatterplot_irq=0,
     .histogram_interrupt_eip=0,
-    .dump_cooked = 0,
     .dump_all = 0,
     .dump_raw_process = 0,
     .dump_raw_reads = 0,
@@ -3425,30 +3423,6 @@ void hvm_pf_xen_postprocess(struct hvm_d
         /* Set summary handler */
         hvm_set_summary_handler(h, hvm_pf_xen_summary, NULL);
     }
-
-    if(opt.dump_cooked)
-    {
-        switch(e->pf_case)
-        {
-        case PF_XEN_EMULATE:
-            printf(" %s pf_xen:emulate va %llx ec %x eip %llx%s lvl %d corr %llx\n",
-                   h->dump_header, e->va, e->error_code,
-                   h->rip, find_symbol(h->rip),
-                   e->pt_level, e->corresponding_va);
-            break;
-        case PF_XEN_MMIO:
-            printf(" %s pf_xen:mmio va %llx ec %x eip %llx%s data %x\n",
-                   h->dump_header, e->va, e->error_code,
-                   h->rip, find_symbol(h->rip),
-                   e->data);
-            break;
-        default:
-            printf(" %s pf_xen va %llx ec %x eip %llx%s\n",
-                   h->dump_header, e->va, e->error_code,
-                   h->rip, find_symbol(h->rip));
-            break;
-        }
-    }
 }
 
 void hvm_pf_xen_process(struct record_info *ri, struct hvm_data *h) {
@@ -3610,7 +3584,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
 
         o->count++;
 
-        if((opt.dump_all || opt.dump_cooked)
+        if((opt.dump_all)
 #if 0
            && (ov->runstate.state != RUNSTATE_RUNNING
                || ov->hvm.vmexit_valid) 
@@ -3624,7 +3598,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
     }
 
     if(m->is_write) {
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             printf("              [vla] d%dv%d icr vec %d %s\n",
                    h->v->d->did, h->v->vid,
                    icr.vec,
@@ -3655,7 +3629,7 @@ void hvm_vlapic_icr_handler(struct hvm_d
         }
     } else {
         /* Read */
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             printf("              [vla] d%dv%d icr status %s\n",
                    h->v->d->did, h->v->vid,
                    icr.delivery_status?"pending":"idle");
@@ -3683,7 +3657,7 @@ void hvm_vlapic_inject(struct vcpu_data 
 }
 
 void hvm_vlapic_eoi_handler(struct hvm_data *h) {
-    if(opt.dump_all || opt.dump_cooked)
+    if(opt.dump_all)
         printf("              [vla] d%dv%d eoi\n",
                h->v->d->did, h->v->vid);
 }
@@ -3834,7 +3808,7 @@ void hvm_inj_virq_process(struct record_
         int vector, fake;
     } *r = (typeof(r))h->d;
 
-    if(opt.dump_cooked | opt.dump_all) {
+    if(opt.dump_all) {
         printf(" %s inj_virq vec %u  %s\n",
                ri->dump_header,
                r->vector, r->fake?"fake":"real");
@@ -3956,24 +3930,12 @@ void hvm_io_address_summary(struct io_ad
 
 void hvm_io_write_postprocess(struct hvm_data *h)
 {
-    if(opt.dump_cooked)
-    {
-        printf(" %s io_write port %x val %x\n",
-               h->dump_header, h->inflight.io.port,
-               h->inflight.io.val);
-    }
     if(opt.with_pio_enumeration)
         update_io_address(&h->summary.io.pio, h->inflight.io.port, 1, h->arc_cycles, 0);
 }
 
 void hvm_io_read_postprocess(struct hvm_data *h)
 {
-    if(opt.dump_cooked)
-    {
-        printf(" %s io_read port %x val %x\n",
-               h->dump_header, h->inflight.io.port,
-               h->inflight.io.val);
-    }
     if(opt.with_pio_enumeration)
         update_io_address(&h->summary.io.pio, h->inflight.io.port, 0, h->arc_cycles, 0);
     if(opt.scatterplot_io && h->inflight.io.port == opt.scatterplot_io_port)
@@ -4275,24 +4237,6 @@ void hvm_cr_write_postprocess(struct hvm
                 }
                 flush=1;
             }
-
-            if(opt.dump_cooked)
-            {
-                printf(" %s cr_write cr3 val %llx oval %llx (%d resyncs) %s\n",
-                       h->dump_header, 
-                       new_val,
-                       oval,
-                       h->resyncs,
-                       flush?"flush":"");
-            }
-        } else {
-            if(opt.dump_cooked)
-            {
-                printf(" %s cr_write cr3 val %llx (%d resyncs)\n",
-                       h->dump_header, 
-                       h->inflight.cr_write.val,
-                       h->resyncs);
-            }
         }
 
         if(opt.summary_info) {
@@ -4313,14 +4257,6 @@ void hvm_cr_write_postprocess(struct hvm
         if(!flush)
             cr3_switch(new_val, h);
     } else {
-        if(opt.dump_cooked)
-        {
-            printf(" %s cr_write cr%d val %llx\n",
-                   h->dump_header, 
-                   h->inflight.cr_write.cr,
-                   h->inflight.cr_write.val);
-        }
-
         if(opt.summary_info)
         {
             if(h->inflight.cr_write.cr < CR_MAX)
@@ -4420,14 +4356,6 @@ void hvm_msr_write_summary(struct hvm_da
 
 void hvm_msr_write_postprocess(struct hvm_data *h)
 {
-    if(opt.dump_cooked)
-    {
-        printf(" %s msr_write msr %d val %llx\n",
-               h->dump_header, 
-               h->inflight.msr.addr,
-               h->inflight.msr.val);
-    }
-
     if(opt.summary_info) {
     }
 
@@ -4466,14 +4394,6 @@ void hvm_msr_read_summary(struct hvm_dat
 
 void hvm_msr_read_postprocess(struct hvm_data *h)
 {
-    if(opt.dump_cooked)
-    {
-        printf(" %s msr_read msr %d val %llx\n",
-               h->dump_header, 
-               h->inflight.msr.addr,
-               h->inflight.msr.val);
-    }
-
     if(opt.summary_info) {
     }
 
@@ -4564,7 +4484,7 @@ void hvm_inj_exc_process(struct record_i
         unsigned vec, ec;
     } *r = (typeof(r))h->d;
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
         if(r->vec < HVM_TRAP_MAX)
             printf(" %3u.%09u %s inj_exc trap %s ec %x\n",
@@ -4620,7 +4540,7 @@ void hvm_intr_process(struct hvm_data *h
 
     h->inflight.intr.vec = vec;
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
         if ( vec < EXTERNAL_INTERRUPT_MAX &&
              hvm_extint_vector_name[vec] )
@@ -4742,7 +4662,7 @@ void hvm_pf_inject_process(struct record
         ec = r->x32.ec;
     }
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
             printf(" %3u.%09u %s pf_inject%s guest_cr2 %llx  guest_ec %x\n",
                    ri->t.s, ri->t.ns, pcpu_string(ri->cpu),
@@ -4938,7 +4858,7 @@ void hvm_handler_process(struct record_i
         hvm_pf_inject_process(ri, h);
         break;
     case TRC_HVM_REINJ_VIRQ:
-        if ( opt.dump_cooked || opt.dump_all )
+        if ( opt.dump_all )
         {
             printf(" %3u.%09u %s inj_virq vec %u\n",
                    ri->t.s, ri->t.ns, pcpu_string(ri->cpu),
@@ -4964,7 +4884,7 @@ void hvm_handler_process(struct record_i
         } else if(opt.with_cr3_enumeration) {
             fprintf(warn, "Warning: destroy_proc: don't know current cr3\n");
         }
-        if ( opt.dump_cooked || opt.dump_all )
+        if ( opt.dump_all )
         {
             printf(" %3u.%09u %s destroy_proc cur_cr3 %llx\n",
                    ri->t.s, ri->t.ns, pcpu_string(ri->cpu), h->v->cr3.val);
@@ -5681,18 +5601,6 @@ void shadow_emulate_postprocess(struct h
         hvm_update_short_summary(h, HVM_SHORT_SUMMARY_EMULATE);
     }
 
-    if ( opt.dump_cooked )
-    {
-        printf(" %s emulate va %llx eip %llx%s lvl %d/%d corr %llx wval %llx flags %s\n",
-               h->dump_header, e->va,
-               h->rip, find_symbol(h->rip),
-               e->pt_level, h->v->guest_paging_levels,
-               e->corresponding_va,
-               e->wval,
-               flag_string(e));
-    }
-
-
     if(opt.scatterplot_unpin_promote) {
         if(e->flag_early_unshadow)
             scatterplot_vs_time(h->exit_tsc, -10);
@@ -5906,14 +5814,6 @@ void shadow_unsync_postprocess(struct hv
             update_summary(&h->summary.pf_xen_unsync[h->resyncs],
                            h->arc_cycles);
     }
-
-    if(opt.dump_cooked)
-    {
-        printf(" %s unsync gfn %llx %s (%d resyncs)\n",
-               h->dump_header, e->gfn,
-               h->resyncs?"(resync)":"",
-               h->resyncs);
-    }
 }
 
 
@@ -6013,17 +5913,6 @@ void shadow_fixup_postprocess(struct hvm
             hvm_update_short_summary(h, HVM_SHORT_SUMMARY_FIXUP);
     }
 
-    if ( opt.dump_cooked )
-    {
-        printf(" %s fixup%s va %llx eip %llx%s gl1e %llx flags %s\n",
-               h->dump_header,
-               e->flag_unsync?":unsync":"",
-               e->va,
-               h->rip, find_symbol(h->rip),
-               e->gl1e,
-               flag_string(e));
-    }
-
     if(opt.scatterplot_unpin_promote) {
         if(h->prealloc_unpin)
             scatterplot_vs_time(h->exit_tsc, 0);
@@ -6133,8 +6022,6 @@ void shadow_fixup_process(struct record_
 void shadow_mmio_postprocess(struct hvm_data *h)
 {
     struct pf_xen_extra *e = &h->inflight.pf_xen;
-    struct mmio_info *m = &h->inflight.mmio;
-
     if ( opt.summary_info )
     {
         if(e->pf_case)
@@ -6148,28 +6035,6 @@ void shadow_mmio_postprocess(struct hvm_
 
     if(opt.with_mmio_enumeration)
         enumerate_mmio(h);
-
-    if ( opt.dump_cooked )
-    {
-        if(m->data_valid)
-            printf(" %s %smmio %s va %llx eip %llx%s gpa %llx data %x\n",
-                   h->dump_header,
-                   (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
-                   m->is_write?"write":"read",
-                   e->va,
-                   h->rip, find_symbol(h->rip),
-                   m->gpa,
-                   m->data);
-        else
-            printf(" %s %smmio %s va %llx eip %llx%s gpa %llx (no data)\n",
-                   h->dump_header,
-                   (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
-                   m->is_write?"write":"read",
-                   m->va,
-                   h->rip, find_symbol(h->rip),
-                   m->gpa);
-    }
-
 }
 
 void shadow_mmio_process(struct record_info *ri, struct hvm_data *h)
@@ -6403,7 +6268,7 @@ void shadow_resync_process(struct record
         unsigned long long gfn;
     } *r = (typeof(r))ri->d;
 
-    if(opt.dump_all || opt.dump_cooked)
+    if(opt.dump_all)
         printf(" %s oos resync %s gfn %llx\n",
                ri->dump_header,
                (ri->event == TRC_SHADOW_RESYNC_FULL)?"full":"only",
@@ -6417,7 +6282,7 @@ void shadow_prealloc_unpin_process(struc
         unsigned long long gfn;
     } *r = (typeof(r))ri->d;
 
-    if(opt.dump_all || opt.dump_cooked)
+    if(opt.dump_all)
         printf(" %s prealloc-unpin gfn %llx\n",
                ri->dump_header, r->gfn);
 
@@ -6435,7 +6300,7 @@ void shadow_wrmap_bf_process(struct reco
         unsigned long long gfn;
     } *r = (typeof(r))ri->d;
 
-    if(opt.dump_all || opt.dump_cooked)
+    if(opt.dump_all)
         printf(" %s wrmap-bf gfn %llx\n",
                ri->dump_header, r->gfn);
 
@@ -6569,7 +6434,7 @@ void pv_hypercall_process(struct record_
             pv->hypercall_count[eax]++;
     }
 
-    if(opt.dump_cooked || opt.dump_all) {
+    if(opt.dump_all) {
         if(eax < HYPERCALL_MAX)
             printf(" %s hypercall %2x (%s) eip %llx\n",
                    ri->dump_header, eax,
@@ -6616,7 +6481,7 @@ void pv_trap_process(struct record_info 
             pv->trap_count[trapnr]++;
     }
 
-    if(opt.dump_cooked || opt.dump_all) {
+    if(opt.dump_all) {
         printf(" %s trap %x eip %llx",
                ri->dump_header, trapnr, eip);
         if(use_ec)
@@ -6673,7 +6538,7 @@ void pv_ptwr_emulation_process(struct re
         return;
     }
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
         printf(" %s ptwr l1e %llx eip %llx addr %llx\n",
                ri->dump_header,
@@ -6711,7 +6576,7 @@ void pv_update_va_mapping_process(struct
         e.flags = r->x32.flags;
     }
 
-    if ( opt.dump_cooked || opt.dump_all )
+    if ( opt.dump_all )
     {
         printf(" %s update_va_mapping l1e %llx va %llx flags %llx\n",
                ri->dump_header,
@@ -6721,7 +6586,7 @@ void pv_update_va_mapping_process(struct
 
 void pv_generic_process(struct record_info *ri, struct pv_data *pv) {
     union pv_event pevt = { .event = ri->event };
-    if ( opt.dump_cooked || opt.dump_all ) {
+    if ( opt.dump_all ) {
         if(pevt.minor < PV_MAX && pv_name[pevt.minor])
             printf(" %s %s",
                    ri->dump_header,
@@ -7145,7 +7010,7 @@ void sched_runstate_process(struct pcpu_
 
     perfctrs = (ri->extra_words == 5);
 
-    if(opt.dump_cooked || opt.dump_all) {
+    if(opt.dump_all) {
         if( perfctrs ) {
             printf(" %s %s {%lld,%lld} d%uv%u %s->%s\n",
                    ri->dump_header,
@@ -7199,9 +7064,6 @@ void sched_runstate_process(struct pcpu_
     if(sevt.new_runstate == RUNSTATE_RUNNABLE
        && v->data_type == VCPU_DATA_HVM
        && v->hvm.vmexit_valid) {
-        if(opt.dump_cooked)
-            printf("%s: d%dv%d changing to state runnable, closing vmexit\n",
-                   __func__, r->dom, r->vcpu);
         hvm_close_vmexit(&v->hvm, ri->tsc);
     }
      
@@ -7408,7 +7270,7 @@ update:
 
             cpi = ((double)run_cycles) / run_instr;
 
-            if(opt.dump_cooked || opt.dump_all) {
+            if(opt.dump_all) {
                 printf("   cpi: %2.2lf ( %lld / %lld )\n",
                        cpi, run_cycles, run_instr);
             }
@@ -7485,7 +7347,7 @@ void sched_switch_process(struct pcpu_in
         unsigned int prev_dom, prev_vcpu, next_dom, next_vcpu;
     } * r = (typeof(r))ri->d;
 
-    if(opt.dump_cooked || opt.dump_all)
+    if(opt.dump_all)
         printf("%s sched_switch prev d%uv%u next d%uv%u\n",
                ri->dump_header,
                r->prev_dom, r->prev_vcpu,
@@ -7786,7 +7648,7 @@ void mem_process(struct pcpu_info *p) {
         mem_pod_superpage_splinter_process(p);
         break;
     default:
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             dump_generic(stdout, ri);
         }
 
@@ -7848,7 +7710,7 @@ void pm_process(struct pcpu_info *p) {
         pcpu_string_draw(p);
         break;
     default:
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             dump_generic(stdout, ri);
         }
         break;
@@ -8209,7 +8071,7 @@ void irq_process(struct pcpu_info *p) {
     case TRC_HW_IRQ_CLEAR_VECTOR:
     case TRC_HW_IRQ_MOVE_FINISH :
     default:
-        if(opt.dump_all || opt.dump_cooked) {
+        if(opt.dump_all) {
             dump_generic(stdout, ri);
         }
         break;
@@ -8311,7 +8173,7 @@ void process_generic(struct record_info 
 
     error(ERR_STRICT, ri);
 
-    if(opt.dump_cooked || opt.dump_all) {
+    if(opt.dump_all) {
         dump_generic(stdout, ri);
     }
 }
@@ -8384,7 +8246,7 @@ void process_lost_records(struct pcpu_in
 
     first_tsc = r->first_tsc;
 
-    if(opt.dump_cooked || opt.dump_all)
+    if(opt.dump_all)
     {
         if(p->current)
             printf(" %s lost_records count %d d%uv%u (cur d%dv%d) first_tsc %lld\n",
@@ -8490,7 +8352,7 @@ void process_lost_records_end(struct pcp
      * Update the information. */
     if(ri->tsc > p->lost_record.tsc)
     {
-        if(opt.dump_cooked || opt.dump_all)
+        if(opt.dump_all)
             printf("               %s lost_records end ---\n",
                    pcpu_string(p->pid));
 
@@ -8500,7 +8362,7 @@ void process_lost_records_end(struct pcp
             int did = p->lost_record.did,
                 vid = p->lost_record.vid;
 
-            if(opt.dump_cooked || opt.dump_all)
+            if(opt.dump_all)
                 printf("               %s lost_records end d%dv%d---\n",
                        pcpu_string(p->pid),
                        did, vid);
@@ -8523,7 +8385,7 @@ void process_lost_records_end(struct pcp
             p->lost_record.seen_valid_schedule=0; /* Let next vcpu_next_update know that
                                                      this one was inferred */
         } else {
-            if(opt.dump_cooked || opt.dump_all)
+            if(opt.dump_all)
                 printf("               %s lost_records end (domain invalid)---\n",
                        pcpu_string(p->pid));
         }
@@ -9026,7 +8888,7 @@ void process_record(struct pcpu_info *p)
 
     process_record_tsc(p->order_tsc, ri);
 
-    if(opt.dump_cooked || opt.dump_all) 
+    if(opt.dump_all) 
         create_dump_header(ri, p);
 
 
@@ -9592,7 +9454,6 @@ void init_pcpus(void) {
 enum {
     OPT_NULL=0,
     /* Dumping info */
-    OPT_DUMP_COOKED,
     OPT_DUMP_RAW_READS,
     OPT_DUMP_RAW_PROCESS,
     OPT_DUMP_NO_PROCESSING,
@@ -9765,10 +9626,6 @@ error_t cmd_parser(int key, char *arg, s
     switch (key)
     {
         /* Dump group */
-    case OPT_DUMP_COOKED:
-        opt.dump_cooked = 1;
-        G.output_defined = 1;
-        break;
     case OPT_DUMP_ALL:
         opt.dump_all = 1;
         G.output_defined = 1;
@@ -10157,11 +10014,6 @@ error_t cmd_parser(int key, char *arg, s
 
 const struct argp_option cmd_opts[] =  {
     /* Dump group */
-    { .name = "dump-cooked",
-      .key = OPT_DUMP_COOKED,
-      .group = OPT_GROUP_DUMP,
-      .doc = "Dump a sanitized summary of vmexit/vmentry.", },
-
     { .name = "dump-all",
       .key = OPT_DUMP_ALL,
       .group = OPT_GROUP_DUMP,
@@ -10453,7 +10305,7 @@ int main(int argc, char *argv[]) {
     if (G.symbol_file != NULL)
         parse_symbol_file(G.symbol_file);
 
-    if(opt.dump_cooked || opt.dump_all)
+    if(opt.dump_all)
         warn = stdout;
         
     init_pcpus();

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2A-0002Kx-Ir; Thu, 26 Jan 2012 17:22:50 +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 1RqT29-0002Fq-Bu
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:49 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327598561!8770385!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24209 invoked from network); 26 Jan 2012 17:22: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;
	26 Jan 2012 17:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179243347"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22: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; Thu, 26 Jan 2012 12:22:41 -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 q0QHMdRp009803;
	Thu, 26 Jan 2012 09:22:40 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:20:57 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 8] xenalyze: Optimizations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 series of optimizations to xenalyze.  The optimizations in
this series can speed up the summary-mode analysis of my 700MiB test
file from over 100 seconds down to around 10 seconds.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2A-0002Kx-Ir; Thu, 26 Jan 2012 17:22:50 +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 1RqT29-0002Fq-Bu
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:49 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327598561!8770385!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24209 invoked from network); 26 Jan 2012 17:22: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;
	26 Jan 2012 17:22:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179243347"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22: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; Thu, 26 Jan 2012 12:22:41 -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 q0QHMdRp009803;
	Thu, 26 Jan 2012 09:22:40 -0800
MIME-Version: 1.0
Message-ID: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:20:57 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 0 of 8] xenalyze: Optimizations
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 series of optimizations to xenalyze.  The optimizations in
this series can speed up the summary-mode analysis of my 700MiB test
file from over 100 seconds down to around 10 seconds.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2C-0002Mp-2m; Thu, 26 Jan 2012 17:22:52 +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 1RqT2A-0002GC-4K
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327598561!8770385!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24251 invoked from network); 26 Jan 2012 17:22:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179243350"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:43 -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, 26 Jan 2012 12:22:43 -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 q0QHMdRr009803;
	Thu, 26 Jan 2012 09:22:42 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2ab3da778828dd481df5419e8b3c63d7f989915f
Message-ID: <2ab3da778828dd481df5.1327598459@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:20:59 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 8] xenalyze: Remove spurious dump_header
	construction
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 h->dump_header information was being filled out on summary
runs, even though it's not used.  Use it only if opt.dump_all is
enabled.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r f8c3c44be309 -r 2ab3da778828 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:11:34 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:16:32 2012 +0000
@@ -5327,7 +5327,7 @@ void hvm_vmexit_process(struct record_in
     h->post_process = hvm_generic_postprocess;
     h->inflight.generic.event = 0;
   
-    {
+    if ( opt.dump_all) {
         struct time_struct t;
         char * c;
         int len, r;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2C-0002Mp-2m; Thu, 26 Jan 2012 17:22:52 +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 1RqT2A-0002GC-4K
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327598561!8770385!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24251 invoked from network); 26 Jan 2012 17:22:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:22:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179243350"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:43 -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, 26 Jan 2012 12:22:43 -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 q0QHMdRr009803;
	Thu, 26 Jan 2012 09:22:42 -0800
MIME-Version: 1.0
X-Mercurial-Node: 2ab3da778828dd481df5419e8b3c63d7f989915f
Message-ID: <2ab3da778828dd481df5.1327598459@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:20:59 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 2 of 8] xenalyze: Remove spurious dump_header
	construction
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 h->dump_header information was being filled out on summary
runs, even though it's not used.  Use it only if opt.dump_all is
enabled.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r f8c3c44be309 -r 2ab3da778828 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:11:34 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:16:32 2012 +0000
@@ -5327,7 +5327,7 @@ void hvm_vmexit_process(struct record_in
     h->post_process = hvm_generic_postprocess;
     h->inflight.generic.event = 0;
   
-    {
+    if ( opt.dump_all) {
         struct time_struct t;
         char * c;
         int len, r;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2D-0002Od-4X; Thu, 26 Jan 2012 17:22:53 +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 1RqT2B-0002Gv-IS
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:51 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327598561!8770385!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24333 invoked from network); 26 Jan 2012 17:22:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:22:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179243353"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:22:44 -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 q0QHMdRt009803;
	Thu, 26 Jan 2012 09:22:43 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0663e3e8f69d4af558eb0d7905a33845cef9ac90
Message-ID: <0663e3e8f69d4af558eb.1327598461@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:01 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 8] xenalyze: Enable -O2 optimization level
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

-O3 is marginally better, but the automatic inlining
obscures where the guest is spending its time.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6772e9e46ab2 -r 0663e3e8f69d Makefile
--- a/Makefile	Thu Jan 26 17:16:35 2012 +0000
+++ b/Makefile	Thu Jan 26 17:16:59 2012 +0000
@@ -1,6 +1,6 @@
 CC = gcc
 
-CFLAGS += -g
+CFLAGS += -g -O2
 CFLAGS += -fno-strict-aliasing
 CFLAGS += -std=gnu99
 CFLAGS += -Wall -Wstrict-prototypes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2D-0002Od-4X; Thu, 26 Jan 2012 17:22:53 +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 1RqT2B-0002Gv-IS
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:51 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327598561!8770385!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24333 invoked from network); 26 Jan 2012 17:22:45 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:22:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179243353"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:22:44 -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 q0QHMdRt009803;
	Thu, 26 Jan 2012 09:22:43 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0663e3e8f69d4af558eb0d7905a33845cef9ac90
Message-ID: <0663e3e8f69d4af558eb.1327598461@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:01 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 4 of 8] xenalyze: Enable -O2 optimization level
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

-O3 is marginally better, but the automatic inlining
obscures where the guest is spending its time.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 6772e9e46ab2 -r 0663e3e8f69d Makefile
--- a/Makefile	Thu Jan 26 17:16:35 2012 +0000
+++ b/Makefile	Thu Jan 26 17:16:59 2012 +0000
@@ -1,6 +1,6 @@
 CC = gcc
 
-CFLAGS += -g
+CFLAGS += -g -O2
 CFLAGS += -fno-strict-aliasing
 CFLAGS += -std=gnu99
 CFLAGS += -Wall -Wstrict-prototypes

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2C-0002Na-Fl; Thu, 26 Jan 2012 17:22:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT2A-0002K9-7P
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:50 +0000
Received: from [85.158.139.83:3489] by server-5.bemta-5.messagelabs.com id
	8D/79-12374-9EB812F4; Thu, 26 Jan 2012 17:22:49 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19253 invoked from network); 26 Jan 2012 17:22:48 -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;
	26 Jan 2012 17:22:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315953"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:47 -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, 26 Jan 2012 12:22:47 -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 q0QHMdRw009803;
	Thu, 26 Jan 2012 09:22:46 -0800
MIME-Version: 1.0
X-Mercurial-Node: f86ebfe663843e5ea497043b99a3fd972fe1df55
Message-ID: <f86ebfe663843e5ea497.1327598464@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:04 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 7 of 8] xenalyze: Introduce more efficient read
	mechanism
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 pread functionality was convenient for reading at arbitrary
offsets within a file, but it was incredibly inefficient; after
recent optimizations, a summary analysis was spending 30% of its
time doing system calls, and indications were that a big chunk
of the rest of the overhead was due to cache misses coming out of
that path.

This patch introduces a read using mmap.  Because the file may
be too big to map on 32-bit systems, I use a "mapcache" of 8
different 2MiB buffers.  If an offset is in what's already mapped,
I just copy it; if not, I unmap one of the buffers and map it instead.

This optimization alone took the summary processing time for my test
trace from 34s down to 10s.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 108d02354403 -r f86ebfe66384 Makefile
--- a/Makefile	Thu Jan 26 17:17:53 2012 +0000
+++ b/Makefile	Thu Jan 26 17:18:13 2012 +0000
@@ -13,7 +13,7 @@ CFLAGS  += -Werror
 
 BIN      = xenalyze dump-raw
 
-HDRS = trace.h analyze.h
+HDRS = trace.h analyze.h mread.h
 
 all: $(BIN)
 
@@ -23,3 +23,6 @@ clean:
 
 %: %.c $(HDRS) Makefile
 	$(CC) $(CFLAGS) -o $@ $<
+
+xenalyze: xenalyze.o mread.o
+	$(CC) $(CFLAGS) -o $@ $^
diff -r 108d02354403 -r f86ebfe66384 mread.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/mread.c	Thu Jan 26 17:18:13 2012 +0000
@@ -0,0 +1,160 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <strings.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <errno.h>
+#include "mread.h"
+
+mread_handle_t mread_init(int fd)
+{
+    struct stat64 s;
+    mread_handle_t h;
+    
+    h=malloc(sizeof(struct mread_ctrl));
+
+    if (!h)
+    {
+        perror("malloc");
+        exit(1);
+    }
+
+    bzero(h, sizeof(struct mread_ctrl));
+
+    h->fd = fd;
+
+    fstat64(fd, &s);
+    h->file_size = s.st_size;
+
+    return h;
+}
+
+ssize_t mread64(mread_handle_t h, void *rec, ssize_t len, loff_t offset)
+{
+    /* Idea: have a "cache" of N mmaped regions.  If the offset is
+     * in one of the regions, just copy it.  If not, evict one of the
+     * regions and map the appropriate range.
+     *
+     * Basic algorithm:
+     *  - See if the offset is in one of the regions
+     *    - If not, map it
+     *       - evict an old region
+     *       - map the new region
+     *  - Copy
+     */
+    char * b=NULL;
+    int bind=-1;
+    loff_t boffset=0;
+    ssize_t bsize;
+
+#define dprintf(x...)
+//#define dprintf fprintf
+
+    dprintf(warn, "%s: offset %llx len %d\n", __func__,
+            offset, len);
+    if ( offset > h->file_size )
+    {
+        dprintf(warn, " offset > file size %llx, returning 0\n",
+                h->file_size);
+        return 0;
+    }
+    if ( offset + len > h->file_size )
+    {
+        dprintf(warn, " offset+len > file size %llx, truncating\n",
+                h->file_size);
+        len = h->file_size - offset;
+    }
+
+    /* Try to find the offset in our range */
+    dprintf(warn, " Trying last, %d\n", last);
+    if ( h->map[h->last].buffer
+         && (offset & MREAD_BUF_MASK) == h->map[h->last].start_offset )
+    {
+        bind=h->last;
+        goto copy;
+    }
+
+    /* Scan to see if it's anywhere else */
+    dprintf(warn, " Scanning\n");
+    for(bind=0; bind<MREAD_MAPS; bind++)
+        if ( h->map[bind].buffer
+             && (offset & MREAD_BUF_MASK) == h->map[bind].start_offset )
+        {
+            dprintf(warn, "  Found, index %d\n", bind);
+            break;
+        }
+
+    /* If we didn't find it, evict someone and map it */
+    if ( bind == MREAD_MAPS )
+    {
+        dprintf(warn, " Clock\n");
+        while(1)
+        {
+            h->clock++;
+            if(h->clock >= MREAD_MAPS)
+                h->clock=0;
+            dprintf(warn, "  %d\n", h->clock);
+            if(h->map[h->clock].buffer == NULL)
+            {
+                dprintf(warn, "  Buffer null, using\n");
+                break;
+            }
+            if(!h->map[h->clock].accessed)
+            {
+                dprintf(warn, "  Not accessed, using\n");
+                break;
+            }
+            h->map[h->clock].accessed=0;
+        }
+        if(h->map[h->clock].buffer)
+        {
+            dprintf(warn, "  Unmapping\n");
+            munmap(h->map[h->clock].buffer, MREAD_BUF_SIZE);
+        }
+        /* FIXME: Try MAP_HUGETLB? */
+        /* FIXME: Make sure this works on large files... */
+        h->map[h->clock].start_offset = offset & MREAD_BUF_MASK;
+        dprintf(warn, "  Mapping %llx from offset %llx\n",
+                MREAD_BUF_SIZE, h->map[h->clock].start_offset);
+        h->map[h->clock].buffer = mmap(NULL, MREAD_BUF_SIZE, PROT_READ,
+                                  MAP_SHARED,
+                                  h->fd,
+                                  h->map[h->clock].start_offset);
+        dprintf(warn, "   mmap returned %p\n", h->map[h->clock].buffer);
+        if ( h->map[h->clock].buffer == MAP_FAILED )
+        {
+            h->map[h->clock].buffer = NULL;
+            perror("mmap");
+            exit(1);
+        }
+        bind = h->clock;
+    }
+
+    h->last=bind;
+copy:
+    h->map[bind].accessed=1;
+    b=h->map[bind].buffer;
+    boffset=offset - h->map[bind].start_offset;
+    if ( boffset + len > MREAD_BUF_SIZE )
+        bsize = MREAD_BUF_SIZE - boffset;
+    else
+        bsize = len;
+    dprintf(warn, " Using index %d, buffer at %p, buffer offset %llx len %d\n",
+            bind, b, boffset, bsize);
+
+    bcopy(b+boffset, rec, len);
+
+    /* Handle the boundary case; make sure this is after doing anything
+     * with the static variables*/
+    if ( len > bsize )
+    {
+        dprintf(warn, "  Finishing up by reading l %d o %llx\n",
+                len-bsize, offset+bsize);
+        mread64(h, rec+bsize, len-bsize, offset+bsize);
+    }
+
+    /* FIXME: ?? */
+    return len;
+#undef dprintf
+}
diff -r 108d02354403 -r f86ebfe66384 mread.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/mread.h	Thu Jan 26 17:18:13 2012 +0000
@@ -0,0 +1,18 @@
+#define MREAD_MAPS 8
+#define MREAD_BUF_SHIFT 9
+#define PAGE_SHIFT 12
+#define MREAD_BUF_SIZE (1ULL<<(PAGE_SHIFT+MREAD_BUF_SHIFT))
+#define MREAD_BUF_MASK (~(MREAD_BUF_SIZE-1))
+typedef struct mread_ctrl {
+    int fd;
+    loff_t file_size;
+    struct mread_buffer {
+        char * buffer;
+        loff_t start_offset;
+        int accessed;
+    } map[MREAD_MAPS];
+    int clock, last;
+} *mread_handle_t;
+
+mread_handle_t mread_init(int fd);
+ssize_t mread64(mread_handle_t h, void *dst, ssize_t len, loff_t offset);
diff -r 108d02354403 -r f86ebfe66384 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:17:53 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:18:13 2012 +0000
@@ -31,11 +31,15 @@
 #include <unistd.h>
 #include "trace.h"
 #include "analyze.h"
+#include "mread.h"
 #include <errno.h>
 #include <strings.h>
 #include <string.h>
 #include <assert.h>
 
+struct mread_ctrl;
+
+
 typedef unsigned long long tsc_t;
 
 #define DEFAULT_CPU_HZ 2400000000LL
@@ -60,6 +64,7 @@ struct array_struct {
 /* -- Global variables -- */
 struct {
     int fd;
+    struct mread_ctrl *mh;
     struct symbol_struct * symbols;
     char * symbol_file;
     char * trace_file;
@@ -257,18 +262,23 @@ struct {
 
 /* -- on-disk trace buffer definitions -- */
 struct trace_record {
-    unsigned event:28,
-        extra_words:3,
-        cycle_flag:1;
     union {
         struct {
-            uint32_t tsc_lo, tsc_hi;
-            uint32_t data[7];
-        } tsc;
-        struct {
-            uint32_t data[7];
-        } notsc;
-    } u;
+            unsigned event:28,
+                extra_words:3,
+                cycle_flag:1;
+            union {
+                struct {
+                    uint32_t tsc_lo, tsc_hi;
+                    uint32_t data[7];
+                } tsc;
+                struct {
+                    uint32_t data[7];
+                } notsc;
+            } u;
+        };
+        uint32_t raw[8];
+    };
 };
 
 FILE *warn = NULL;
@@ -1943,7 +1953,7 @@ char * pcpu_string(int pcpu);
 void pcpu_string_draw(struct pcpu_info *p);
 void process_generic(struct record_info *ri);
 void dump_generic(FILE *f, struct record_info *ri);
-ssize_t __read_record(int fd, struct trace_record *rec, loff_t offset);
+ssize_t __read_record(struct trace_record *rec, loff_t offset);
 void error(enum error_level l, struct record_info *ri);
 void update_io_address(struct io_address ** list, unsigned int pa, int dir,
                        tsc_t arc_cycles, unsigned int va);
@@ -8123,17 +8133,26 @@ void dump_raw(char * s, struct record_in
     int i;
 
     if(ri->rec.cycle_flag)
-        printf("%s %x %d %lld [",
+        printf("%s %7x %d %14lld [",
                s, ri->event, ri->extra_words, ri->tsc);
     else
-        printf("%s %x %d - [",
-               s, ri->event, ri->extra_words);
-
-    for(i=0; i<ri->extra_words; i++) {
-        printf(" %x", ri->d[i]);
+        printf("%s %7x %d %14s [",
+               s, ri->event, ri->extra_words, "-");
+
+    for(i=0; i<7; i++) {
+        if ( i < ri->extra_words )
+            printf(" %8x", ri->d[i]);
+        else
+            printf("         ");
     }
         
-    printf(" ]\n");
+    printf(" ] | ");
+
+    for (i=0; i<8; i++) {
+        printf(" %08x", ri->rec.raw[i]);
+    }
+
+    printf(" |\n");
 }
 
 void error(enum error_level l, struct record_info *ri)
@@ -8455,7 +8474,7 @@ loff_t scan_for_new_pcpu(loff_t offset) 
     struct trace_record rec;
     struct cpu_change_data *cd;
     
-    r=__read_record(G.fd, &rec, offset);
+    r=__read_record(&rec, offset);
 
     if(r==0)
         return 0;
@@ -9028,11 +9047,11 @@ void progress_finish(void) {
     }
 }
 
-ssize_t __read_record(int fd, struct trace_record *rec, loff_t offset)
+ssize_t __read_record(struct trace_record *rec, loff_t offset)
 {
     ssize_t r, rsize;
 
-    r=pread64(G.fd, rec, sizeof(*rec), offset);
+    r=mread64(G.mh, rec, sizeof(*rec), offset);
 
     if(r < 0) {
         /* Read error */
@@ -9110,14 +9129,14 @@ void __fill_in_record_info(struct pcpu_i
     ri->cpu = p->pid;
 }
 
-ssize_t read_record(int fd, struct pcpu_info * p) {
+ssize_t read_record(struct pcpu_info * p) {
     loff_t * offset;
     struct record_info *ri;
 
     offset = &p->file_offset;
     ri = &p->ri;
 
-    ri->size = __read_record(fd, &ri->rec, *offset);
+    ri->size = __read_record(&ri->rec, *offset);
     if(ri->size)
     {
         __fill_in_record_info(p);
@@ -9317,7 +9336,7 @@ void process_records(void) {
             }
         }
         else
-            read_record(G.fd, p);
+            read_record(p);
 
         /* Update this pcpu in the processing order */
         if ( p->active )
@@ -10304,6 +10323,10 @@ int main(int argc, char *argv[]) {
         fstat64(G.fd, &s);
         G.file_size = s.st_size;
     }
+
+    if ( (G.mh = mread_init(G.fd)) == NULL )
+        perror("mread");
+
     if (G.symbol_file != NULL)
         parse_symbol_file(G.symbol_file);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2C-0002Na-Fl; Thu, 26 Jan 2012 17:22:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT2A-0002K9-7P
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:50 +0000
Received: from [85.158.139.83:3489] by server-5.bemta-5.messagelabs.com id
	8D/79-12374-9EB812F4; Thu, 26 Jan 2012 17:22:49 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19253 invoked from network); 26 Jan 2012 17:22:48 -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;
	26 Jan 2012 17:22:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315953"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:47 -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, 26 Jan 2012 12:22:47 -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 q0QHMdRw009803;
	Thu, 26 Jan 2012 09:22:46 -0800
MIME-Version: 1.0
X-Mercurial-Node: f86ebfe663843e5ea497043b99a3fd972fe1df55
Message-ID: <f86ebfe663843e5ea497.1327598464@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:04 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 7 of 8] xenalyze: Introduce more efficient read
	mechanism
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 pread functionality was convenient for reading at arbitrary
offsets within a file, but it was incredibly inefficient; after
recent optimizations, a summary analysis was spending 30% of its
time doing system calls, and indications were that a big chunk
of the rest of the overhead was due to cache misses coming out of
that path.

This patch introduces a read using mmap.  Because the file may
be too big to map on 32-bit systems, I use a "mapcache" of 8
different 2MiB buffers.  If an offset is in what's already mapped,
I just copy it; if not, I unmap one of the buffers and map it instead.

This optimization alone took the summary processing time for my test
trace from 34s down to 10s.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 108d02354403 -r f86ebfe66384 Makefile
--- a/Makefile	Thu Jan 26 17:17:53 2012 +0000
+++ b/Makefile	Thu Jan 26 17:18:13 2012 +0000
@@ -13,7 +13,7 @@ CFLAGS  += -Werror
 
 BIN      = xenalyze dump-raw
 
-HDRS = trace.h analyze.h
+HDRS = trace.h analyze.h mread.h
 
 all: $(BIN)
 
@@ -23,3 +23,6 @@ clean:
 
 %: %.c $(HDRS) Makefile
 	$(CC) $(CFLAGS) -o $@ $<
+
+xenalyze: xenalyze.o mread.o
+	$(CC) $(CFLAGS) -o $@ $^
diff -r 108d02354403 -r f86ebfe66384 mread.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/mread.c	Thu Jan 26 17:18:13 2012 +0000
@@ -0,0 +1,160 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <strings.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <errno.h>
+#include "mread.h"
+
+mread_handle_t mread_init(int fd)
+{
+    struct stat64 s;
+    mread_handle_t h;
+    
+    h=malloc(sizeof(struct mread_ctrl));
+
+    if (!h)
+    {
+        perror("malloc");
+        exit(1);
+    }
+
+    bzero(h, sizeof(struct mread_ctrl));
+
+    h->fd = fd;
+
+    fstat64(fd, &s);
+    h->file_size = s.st_size;
+
+    return h;
+}
+
+ssize_t mread64(mread_handle_t h, void *rec, ssize_t len, loff_t offset)
+{
+    /* Idea: have a "cache" of N mmaped regions.  If the offset is
+     * in one of the regions, just copy it.  If not, evict one of the
+     * regions and map the appropriate range.
+     *
+     * Basic algorithm:
+     *  - See if the offset is in one of the regions
+     *    - If not, map it
+     *       - evict an old region
+     *       - map the new region
+     *  - Copy
+     */
+    char * b=NULL;
+    int bind=-1;
+    loff_t boffset=0;
+    ssize_t bsize;
+
+#define dprintf(x...)
+//#define dprintf fprintf
+
+    dprintf(warn, "%s: offset %llx len %d\n", __func__,
+            offset, len);
+    if ( offset > h->file_size )
+    {
+        dprintf(warn, " offset > file size %llx, returning 0\n",
+                h->file_size);
+        return 0;
+    }
+    if ( offset + len > h->file_size )
+    {
+        dprintf(warn, " offset+len > file size %llx, truncating\n",
+                h->file_size);
+        len = h->file_size - offset;
+    }
+
+    /* Try to find the offset in our range */
+    dprintf(warn, " Trying last, %d\n", last);
+    if ( h->map[h->last].buffer
+         && (offset & MREAD_BUF_MASK) == h->map[h->last].start_offset )
+    {
+        bind=h->last;
+        goto copy;
+    }
+
+    /* Scan to see if it's anywhere else */
+    dprintf(warn, " Scanning\n");
+    for(bind=0; bind<MREAD_MAPS; bind++)
+        if ( h->map[bind].buffer
+             && (offset & MREAD_BUF_MASK) == h->map[bind].start_offset )
+        {
+            dprintf(warn, "  Found, index %d\n", bind);
+            break;
+        }
+
+    /* If we didn't find it, evict someone and map it */
+    if ( bind == MREAD_MAPS )
+    {
+        dprintf(warn, " Clock\n");
+        while(1)
+        {
+            h->clock++;
+            if(h->clock >= MREAD_MAPS)
+                h->clock=0;
+            dprintf(warn, "  %d\n", h->clock);
+            if(h->map[h->clock].buffer == NULL)
+            {
+                dprintf(warn, "  Buffer null, using\n");
+                break;
+            }
+            if(!h->map[h->clock].accessed)
+            {
+                dprintf(warn, "  Not accessed, using\n");
+                break;
+            }
+            h->map[h->clock].accessed=0;
+        }
+        if(h->map[h->clock].buffer)
+        {
+            dprintf(warn, "  Unmapping\n");
+            munmap(h->map[h->clock].buffer, MREAD_BUF_SIZE);
+        }
+        /* FIXME: Try MAP_HUGETLB? */
+        /* FIXME: Make sure this works on large files... */
+        h->map[h->clock].start_offset = offset & MREAD_BUF_MASK;
+        dprintf(warn, "  Mapping %llx from offset %llx\n",
+                MREAD_BUF_SIZE, h->map[h->clock].start_offset);
+        h->map[h->clock].buffer = mmap(NULL, MREAD_BUF_SIZE, PROT_READ,
+                                  MAP_SHARED,
+                                  h->fd,
+                                  h->map[h->clock].start_offset);
+        dprintf(warn, "   mmap returned %p\n", h->map[h->clock].buffer);
+        if ( h->map[h->clock].buffer == MAP_FAILED )
+        {
+            h->map[h->clock].buffer = NULL;
+            perror("mmap");
+            exit(1);
+        }
+        bind = h->clock;
+    }
+
+    h->last=bind;
+copy:
+    h->map[bind].accessed=1;
+    b=h->map[bind].buffer;
+    boffset=offset - h->map[bind].start_offset;
+    if ( boffset + len > MREAD_BUF_SIZE )
+        bsize = MREAD_BUF_SIZE - boffset;
+    else
+        bsize = len;
+    dprintf(warn, " Using index %d, buffer at %p, buffer offset %llx len %d\n",
+            bind, b, boffset, bsize);
+
+    bcopy(b+boffset, rec, len);
+
+    /* Handle the boundary case; make sure this is after doing anything
+     * with the static variables*/
+    if ( len > bsize )
+    {
+        dprintf(warn, "  Finishing up by reading l %d o %llx\n",
+                len-bsize, offset+bsize);
+        mread64(h, rec+bsize, len-bsize, offset+bsize);
+    }
+
+    /* FIXME: ?? */
+    return len;
+#undef dprintf
+}
diff -r 108d02354403 -r f86ebfe66384 mread.h
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/mread.h	Thu Jan 26 17:18:13 2012 +0000
@@ -0,0 +1,18 @@
+#define MREAD_MAPS 8
+#define MREAD_BUF_SHIFT 9
+#define PAGE_SHIFT 12
+#define MREAD_BUF_SIZE (1ULL<<(PAGE_SHIFT+MREAD_BUF_SHIFT))
+#define MREAD_BUF_MASK (~(MREAD_BUF_SIZE-1))
+typedef struct mread_ctrl {
+    int fd;
+    loff_t file_size;
+    struct mread_buffer {
+        char * buffer;
+        loff_t start_offset;
+        int accessed;
+    } map[MREAD_MAPS];
+    int clock, last;
+} *mread_handle_t;
+
+mread_handle_t mread_init(int fd);
+ssize_t mread64(mread_handle_t h, void *dst, ssize_t len, loff_t offset);
diff -r 108d02354403 -r f86ebfe66384 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:17:53 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:18:13 2012 +0000
@@ -31,11 +31,15 @@
 #include <unistd.h>
 #include "trace.h"
 #include "analyze.h"
+#include "mread.h"
 #include <errno.h>
 #include <strings.h>
 #include <string.h>
 #include <assert.h>
 
+struct mread_ctrl;
+
+
 typedef unsigned long long tsc_t;
 
 #define DEFAULT_CPU_HZ 2400000000LL
@@ -60,6 +64,7 @@ struct array_struct {
 /* -- Global variables -- */
 struct {
     int fd;
+    struct mread_ctrl *mh;
     struct symbol_struct * symbols;
     char * symbol_file;
     char * trace_file;
@@ -257,18 +262,23 @@ struct {
 
 /* -- on-disk trace buffer definitions -- */
 struct trace_record {
-    unsigned event:28,
-        extra_words:3,
-        cycle_flag:1;
     union {
         struct {
-            uint32_t tsc_lo, tsc_hi;
-            uint32_t data[7];
-        } tsc;
-        struct {
-            uint32_t data[7];
-        } notsc;
-    } u;
+            unsigned event:28,
+                extra_words:3,
+                cycle_flag:1;
+            union {
+                struct {
+                    uint32_t tsc_lo, tsc_hi;
+                    uint32_t data[7];
+                } tsc;
+                struct {
+                    uint32_t data[7];
+                } notsc;
+            } u;
+        };
+        uint32_t raw[8];
+    };
 };
 
 FILE *warn = NULL;
@@ -1943,7 +1953,7 @@ char * pcpu_string(int pcpu);
 void pcpu_string_draw(struct pcpu_info *p);
 void process_generic(struct record_info *ri);
 void dump_generic(FILE *f, struct record_info *ri);
-ssize_t __read_record(int fd, struct trace_record *rec, loff_t offset);
+ssize_t __read_record(struct trace_record *rec, loff_t offset);
 void error(enum error_level l, struct record_info *ri);
 void update_io_address(struct io_address ** list, unsigned int pa, int dir,
                        tsc_t arc_cycles, unsigned int va);
@@ -8123,17 +8133,26 @@ void dump_raw(char * s, struct record_in
     int i;
 
     if(ri->rec.cycle_flag)
-        printf("%s %x %d %lld [",
+        printf("%s %7x %d %14lld [",
                s, ri->event, ri->extra_words, ri->tsc);
     else
-        printf("%s %x %d - [",
-               s, ri->event, ri->extra_words);
-
-    for(i=0; i<ri->extra_words; i++) {
-        printf(" %x", ri->d[i]);
+        printf("%s %7x %d %14s [",
+               s, ri->event, ri->extra_words, "-");
+
+    for(i=0; i<7; i++) {
+        if ( i < ri->extra_words )
+            printf(" %8x", ri->d[i]);
+        else
+            printf("         ");
     }
         
-    printf(" ]\n");
+    printf(" ] | ");
+
+    for (i=0; i<8; i++) {
+        printf(" %08x", ri->rec.raw[i]);
+    }
+
+    printf(" |\n");
 }
 
 void error(enum error_level l, struct record_info *ri)
@@ -8455,7 +8474,7 @@ loff_t scan_for_new_pcpu(loff_t offset) 
     struct trace_record rec;
     struct cpu_change_data *cd;
     
-    r=__read_record(G.fd, &rec, offset);
+    r=__read_record(&rec, offset);
 
     if(r==0)
         return 0;
@@ -9028,11 +9047,11 @@ void progress_finish(void) {
     }
 }
 
-ssize_t __read_record(int fd, struct trace_record *rec, loff_t offset)
+ssize_t __read_record(struct trace_record *rec, loff_t offset)
 {
     ssize_t r, rsize;
 
-    r=pread64(G.fd, rec, sizeof(*rec), offset);
+    r=mread64(G.mh, rec, sizeof(*rec), offset);
 
     if(r < 0) {
         /* Read error */
@@ -9110,14 +9129,14 @@ void __fill_in_record_info(struct pcpu_i
     ri->cpu = p->pid;
 }
 
-ssize_t read_record(int fd, struct pcpu_info * p) {
+ssize_t read_record(struct pcpu_info * p) {
     loff_t * offset;
     struct record_info *ri;
 
     offset = &p->file_offset;
     ri = &p->ri;
 
-    ri->size = __read_record(fd, &ri->rec, *offset);
+    ri->size = __read_record(&ri->rec, *offset);
     if(ri->size)
     {
         __fill_in_record_info(p);
@@ -9317,7 +9336,7 @@ void process_records(void) {
             }
         }
         else
-            read_record(G.fd, p);
+            read_record(p);
 
         /* Update this pcpu in the processing order */
         if ( p->active )
@@ -10304,6 +10323,10 @@ int main(int argc, char *argv[]) {
         fstat64(G.fd, &s);
         G.file_size = s.st_size;
     }
+
+    if ( (G.mh = mread_init(G.fd)) == NULL )
+        perror("mread");
+
     if (G.symbol_file != NULL)
         parse_symbol_file(G.symbol_file);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2E-0002Qk-JT; Thu, 26 Jan 2012 17:22:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT2C-0002Kg-Gj
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:52 +0000
Received: from [85.158.139.83:3522] by server-12.bemta-5.messagelabs.com id
	42/A0-18193-AEB812F4; Thu, 26 Jan 2012 17:22:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19308 invoked from network); 26 Jan 2012 17:22:49 -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;
	26 Jan 2012 17:22:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315954"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22: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; Thu, 26 Jan 2012 12:22:48 -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 q0QHMdRx009803;
	Thu, 26 Jan 2012 09:22:47 -0800
MIME-Version: 1.0
X-Mercurial-Node: 84d9c7ac3cbfe1c7aec30ed949c8604da75e8fbe
Message-ID: <84d9c7ac3cbfe1c7aec3.1327598465@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:05 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 8 of 8] xenalyze: Get rid of redundant hvm
	dump_header
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 need to have a second dump_header.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r f86ebfe66384 -r 84d9c7ac3cbf xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:18:13 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:18:43 2012 +0000
@@ -1435,7 +1435,6 @@ struct hvm_data {
     tsc_t exit_tsc, arc_cycles, entry_tsc;
     unsigned long long rip;
     unsigned exit_reason, event_handler;
-    char dump_header[256];
     int short_summary_done:1, prealloc_unpin:1, wrmap_bf:1;
 
     /* Immediate processing */
@@ -3800,11 +3799,11 @@ void hvm_mmio_assist_process(struct reco
     {
         if(m->data_valid)
             printf("]%s mmio_assist %c gpa %llx data %x\n",
-                   h->dump_header,
+                   ri->dump_header,
                    mevt.write?'w':'r',
                    m->gpa, m->data);
         else
-            printf("]%s mmio_assist %c gpa %llx (no data)\n", h->dump_header,
+            printf("]%s mmio_assist %c gpa %llx (no data)\n", ri->dump_header,
                    mevt.write?'w':'r', m->gpa);
     }
 
@@ -3995,7 +3994,7 @@ void hvm_io_assist_process(struct record
     if(opt.dump_all)
     {
         printf(" %s io %s port %x val %x\n",
-               h->dump_header,
+               ri->dump_header,
                mevt.write?"write":"read",
                r->x32.port,
                r->x32.data);
@@ -4348,13 +4347,13 @@ void hvm_cr_write_process(struct record_
     {
         if(cr == 3 && h->v->cr3.val) {
             printf("]%s cr_write cr3 val %llx oval %llx %s\n",
-                   h->dump_header, 
+                   ri->dump_header, 
                    val,
                    h->v->cr3.val,
                    (h->v->cr3.val == val)?"flush":"switch");
         } else {
             printf(" %s cr_write cr%d val %llx\n",
-                   h->dump_header, 
+                   ri->dump_header, 
                    cr, val);
 
         }
@@ -4392,7 +4391,7 @@ void hvm_msr_write_process(struct record
     if(opt.dump_all)
     {
         printf(" %s msr_write addr %x val %llx\n",
-               h->dump_header,
+               ri->dump_header,
                r->addr, r->val);
     }
 
@@ -4430,7 +4429,7 @@ void hvm_msr_read_process(struct record_
     if(opt.dump_all)
     {
         printf(" %s msr_read addr %x val %llx\n",
-               h->dump_header,
+               ri->dump_header,
                r->addr, r->val);
     }
 
@@ -4476,12 +4475,12 @@ void hvm_vmcall_process(struct record_in
     if(opt.dump_all) {
         if(r->eax < HYPERCALL_MAX)
             printf(" %s vmcall %2x (%s)\n",
-                   h->dump_header,
+                   ri->dump_header,
                    r->eax,
                    hypercall_name[r->eax]);
         else
             printf(" %s vmcall %2x\n",
-                   h->dump_header,
+                   ri->dump_header,
                    r->eax);
     }
 
@@ -4534,7 +4533,7 @@ void hvm_intr_summary(struct hvm_data *h
 }
 
 
-void hvm_intr_process(struct hvm_data *h)
+void hvm_intr_process(struct record_info *ri, struct hvm_data *h)
 {
     unsigned vec = *(unsigned *)h->d;
 
@@ -4558,12 +4557,12 @@ void hvm_intr_process(struct hvm_data *h
         if ( vec < EXTERNAL_INTERRUPT_MAX &&
              hvm_extint_vector_name[vec] )
             printf(" %s intr vec %s(%x)\n",
-                   h->dump_header,
+                   ri->dump_header,
                    hvm_extint_vector_name[vec],
                    vec);
         else
             printf(" %s intr vec %x\n",
-                   h->dump_header, vec);
+                   ri->dump_header, vec);
     }
 
     if(opt.scatterplot_interrupt_eip
@@ -4695,7 +4694,7 @@ void hvm_npf_process(struct record_info 
 
     if ( opt.dump_all )
         printf(" %s npf gpa %llx q %x mfn %llx t %d\n",
-               h->dump_header,
+               ri->dump_header,
                (unsigned long long)r->gpa, r->qualification,
                (unsigned long long)r->mfn, r->p2mt);
 }
@@ -4708,7 +4707,7 @@ void hvm_rdtsc_process(struct record_inf
 
     if ( opt.dump_all )
         printf(" %s rdtsc %llx %lld %s\n",
-               h->dump_header,
+               ri->dump_header,
                (unsigned long long)r->tsc,
                (unsigned long long)r->tsc,
                h->last_rdtsc > r->tsc ? "BACKWARDS" : "");
@@ -4922,7 +4921,7 @@ needs_vmexit:
     switch(ri->event) {
         /* Records adding to the vmexit reason */
     case TRC_HVM_INTR:
-        hvm_intr_process(h);
+        hvm_intr_process(ri, h);
         break;
     case TRC_HVM_PF_XEN:
     case TRC_HVM_PF_XEN64:
@@ -5259,50 +5258,6 @@ void hvm_vmexit_process(struct record_in
 
     h->post_process = hvm_generic_postprocess;
     h->inflight.generic.event = 0;
-  
-    if ( opt.dump_all) {
-        struct time_struct t;
-        char * c;
-        int len, r;
-
-        abs_cycles_to_time(h->exit_tsc, &t);
-
-        len = DUMP_HEADER_MAX;
-        c = h->dump_header;
-
-        if ( t.time )
-        {
-            r=snprintf(c, len, "%3u.%09u", t.s, t.ns);
-            c+=r;
-            len-=r;
-        }
-        else
-        {
-            r=snprintf(c,
-                       len,
-                       "              ");
-            c+=r;
-            len-=r;
-        }
-        
-        r = snprintf(c, len, " %s", pcpu_string(ri->cpu));
-        c+=r;
-        len-=r;
-        
-        if ( v )
-        {
-            r = snprintf(c, len, " d%dv%d", v->d->did, v->vid);
-            c+=r;
-            len-=r;
-        }
-        else
-        {
-            r = snprintf(c, len, " d?v?");
-            c+=r;
-            len-=r;
-        }
-        
-    }
 }
 
 void hvm_close_vmexit(struct hvm_data *h, tsc_t tsc) {
@@ -5844,7 +5799,7 @@ void shadow_unsync_process(struct record
 
     if(opt.dump_all)
         printf("]%s shadow unsync gmfn %llx va %llx pt_level %d corr %llx\n",
-               h->dump_header,
+               ri->dump_header,
                e->gmfn,
                e->va,
                e->pt_level,
@@ -5873,7 +5828,7 @@ void shadow_emulate_other_process(struct
 
     if(opt.dump_all)
         printf("]%s shadow %s gfn %llx va %llx\n",
-               h->dump_header,
+               ri->dump_header,
                pf_xen_name[sevt.minor],
                e->gfn,
                e->va);
@@ -6016,14 +5971,14 @@ void shadow_fixup_process(struct record_
     {
         if ( e->flag_unsync )
             printf("]%s fixup:unsync va %llx gl1e %llx corr %llx flags (%x)%s\n",
-                   h->dump_header,
+                   ri->dump_header,
                    e->va, e->gl1e,
                    e->corresponding_va,
                    e->flags,
                    flag_string(e));
         else
             printf("]%s fixup va %llx gl1e %llx flags (%x)%s\n",
-                   h->dump_header,
+                   ri->dump_header,
                    e->va, e->gl1e, e->flags,
                    flag_string(e));
     }
@@ -6103,7 +6058,7 @@ void shadow_mmio_process(struct record_i
 
     if(opt.dump_all)
         printf("]%s %smmio va %llx\n",
-                h->dump_header,
+                ri->dump_header,
                 (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
                 e->va);
 
@@ -6200,7 +6155,7 @@ void shadow_propagate_process(struct rec
 
     if(opt.dump_all)
         printf("]%s propagate va %llx gl1e %llx flags (%x)%s\n",
-               h->dump_header,
+               ri->dump_header,
                e->va, e->gl1e, e->flags,
                flag_string(e));
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2E-0002Qk-JT; Thu, 26 Jan 2012 17:22:54 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RqT2C-0002Kg-Gj
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:52 +0000
Received: from [85.158.139.83:3522] by server-12.bemta-5.messagelabs.com id
	42/A0-18193-AEB812F4; Thu, 26 Jan 2012 17:22:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327598562!12500102!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19308 invoked from network); 26 Jan 2012 17:22:49 -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;
	26 Jan 2012 17:22:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315954"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22: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; Thu, 26 Jan 2012 12:22:48 -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 q0QHMdRx009803;
	Thu, 26 Jan 2012 09:22:47 -0800
MIME-Version: 1.0
X-Mercurial-Node: 84d9c7ac3cbfe1c7aec30ed949c8604da75e8fbe
Message-ID: <84d9c7ac3cbfe1c7aec3.1327598465@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:05 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 8 of 8] xenalyze: Get rid of redundant hvm
	dump_header
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 need to have a second dump_header.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r f86ebfe66384 -r 84d9c7ac3cbf xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:18:13 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:18:43 2012 +0000
@@ -1435,7 +1435,6 @@ struct hvm_data {
     tsc_t exit_tsc, arc_cycles, entry_tsc;
     unsigned long long rip;
     unsigned exit_reason, event_handler;
-    char dump_header[256];
     int short_summary_done:1, prealloc_unpin:1, wrmap_bf:1;
 
     /* Immediate processing */
@@ -3800,11 +3799,11 @@ void hvm_mmio_assist_process(struct reco
     {
         if(m->data_valid)
             printf("]%s mmio_assist %c gpa %llx data %x\n",
-                   h->dump_header,
+                   ri->dump_header,
                    mevt.write?'w':'r',
                    m->gpa, m->data);
         else
-            printf("]%s mmio_assist %c gpa %llx (no data)\n", h->dump_header,
+            printf("]%s mmio_assist %c gpa %llx (no data)\n", ri->dump_header,
                    mevt.write?'w':'r', m->gpa);
     }
 
@@ -3995,7 +3994,7 @@ void hvm_io_assist_process(struct record
     if(opt.dump_all)
     {
         printf(" %s io %s port %x val %x\n",
-               h->dump_header,
+               ri->dump_header,
                mevt.write?"write":"read",
                r->x32.port,
                r->x32.data);
@@ -4348,13 +4347,13 @@ void hvm_cr_write_process(struct record_
     {
         if(cr == 3 && h->v->cr3.val) {
             printf("]%s cr_write cr3 val %llx oval %llx %s\n",
-                   h->dump_header, 
+                   ri->dump_header, 
                    val,
                    h->v->cr3.val,
                    (h->v->cr3.val == val)?"flush":"switch");
         } else {
             printf(" %s cr_write cr%d val %llx\n",
-                   h->dump_header, 
+                   ri->dump_header, 
                    cr, val);
 
         }
@@ -4392,7 +4391,7 @@ void hvm_msr_write_process(struct record
     if(opt.dump_all)
     {
         printf(" %s msr_write addr %x val %llx\n",
-               h->dump_header,
+               ri->dump_header,
                r->addr, r->val);
     }
 
@@ -4430,7 +4429,7 @@ void hvm_msr_read_process(struct record_
     if(opt.dump_all)
     {
         printf(" %s msr_read addr %x val %llx\n",
-               h->dump_header,
+               ri->dump_header,
                r->addr, r->val);
     }
 
@@ -4476,12 +4475,12 @@ void hvm_vmcall_process(struct record_in
     if(opt.dump_all) {
         if(r->eax < HYPERCALL_MAX)
             printf(" %s vmcall %2x (%s)\n",
-                   h->dump_header,
+                   ri->dump_header,
                    r->eax,
                    hypercall_name[r->eax]);
         else
             printf(" %s vmcall %2x\n",
-                   h->dump_header,
+                   ri->dump_header,
                    r->eax);
     }
 
@@ -4534,7 +4533,7 @@ void hvm_intr_summary(struct hvm_data *h
 }
 
 
-void hvm_intr_process(struct hvm_data *h)
+void hvm_intr_process(struct record_info *ri, struct hvm_data *h)
 {
     unsigned vec = *(unsigned *)h->d;
 
@@ -4558,12 +4557,12 @@ void hvm_intr_process(struct hvm_data *h
         if ( vec < EXTERNAL_INTERRUPT_MAX &&
              hvm_extint_vector_name[vec] )
             printf(" %s intr vec %s(%x)\n",
-                   h->dump_header,
+                   ri->dump_header,
                    hvm_extint_vector_name[vec],
                    vec);
         else
             printf(" %s intr vec %x\n",
-                   h->dump_header, vec);
+                   ri->dump_header, vec);
     }
 
     if(opt.scatterplot_interrupt_eip
@@ -4695,7 +4694,7 @@ void hvm_npf_process(struct record_info 
 
     if ( opt.dump_all )
         printf(" %s npf gpa %llx q %x mfn %llx t %d\n",
-               h->dump_header,
+               ri->dump_header,
                (unsigned long long)r->gpa, r->qualification,
                (unsigned long long)r->mfn, r->p2mt);
 }
@@ -4708,7 +4707,7 @@ void hvm_rdtsc_process(struct record_inf
 
     if ( opt.dump_all )
         printf(" %s rdtsc %llx %lld %s\n",
-               h->dump_header,
+               ri->dump_header,
                (unsigned long long)r->tsc,
                (unsigned long long)r->tsc,
                h->last_rdtsc > r->tsc ? "BACKWARDS" : "");
@@ -4922,7 +4921,7 @@ needs_vmexit:
     switch(ri->event) {
         /* Records adding to the vmexit reason */
     case TRC_HVM_INTR:
-        hvm_intr_process(h);
+        hvm_intr_process(ri, h);
         break;
     case TRC_HVM_PF_XEN:
     case TRC_HVM_PF_XEN64:
@@ -5259,50 +5258,6 @@ void hvm_vmexit_process(struct record_in
 
     h->post_process = hvm_generic_postprocess;
     h->inflight.generic.event = 0;
-  
-    if ( opt.dump_all) {
-        struct time_struct t;
-        char * c;
-        int len, r;
-
-        abs_cycles_to_time(h->exit_tsc, &t);
-
-        len = DUMP_HEADER_MAX;
-        c = h->dump_header;
-
-        if ( t.time )
-        {
-            r=snprintf(c, len, "%3u.%09u", t.s, t.ns);
-            c+=r;
-            len-=r;
-        }
-        else
-        {
-            r=snprintf(c,
-                       len,
-                       "              ");
-            c+=r;
-            len-=r;
-        }
-        
-        r = snprintf(c, len, " %s", pcpu_string(ri->cpu));
-        c+=r;
-        len-=r;
-        
-        if ( v )
-        {
-            r = snprintf(c, len, " d%dv%d", v->d->did, v->vid);
-            c+=r;
-            len-=r;
-        }
-        else
-        {
-            r = snprintf(c, len, " d?v?");
-            c+=r;
-            len-=r;
-        }
-        
-    }
 }
 
 void hvm_close_vmexit(struct hvm_data *h, tsc_t tsc) {
@@ -5844,7 +5799,7 @@ void shadow_unsync_process(struct record
 
     if(opt.dump_all)
         printf("]%s shadow unsync gmfn %llx va %llx pt_level %d corr %llx\n",
-               h->dump_header,
+               ri->dump_header,
                e->gmfn,
                e->va,
                e->pt_level,
@@ -5873,7 +5828,7 @@ void shadow_emulate_other_process(struct
 
     if(opt.dump_all)
         printf("]%s shadow %s gfn %llx va %llx\n",
-               h->dump_header,
+               ri->dump_header,
                pf_xen_name[sevt.minor],
                e->gfn,
                e->va);
@@ -6016,14 +5971,14 @@ void shadow_fixup_process(struct record_
     {
         if ( e->flag_unsync )
             printf("]%s fixup:unsync va %llx gl1e %llx corr %llx flags (%x)%s\n",
-                   h->dump_header,
+                   ri->dump_header,
                    e->va, e->gl1e,
                    e->corresponding_va,
                    e->flags,
                    flag_string(e));
         else
             printf("]%s fixup va %llx gl1e %llx flags (%x)%s\n",
-                   h->dump_header,
+                   ri->dump_header,
                    e->va, e->gl1e, e->flags,
                    flag_string(e));
     }
@@ -6103,7 +6058,7 @@ void shadow_mmio_process(struct record_i
 
     if(opt.dump_all)
         printf("]%s %smmio va %llx\n",
-                h->dump_header,
+                ri->dump_header,
                 (e->pf_case==PF_XEN_FAST_MMIO)?"fast ":"",
                 e->va);
 
@@ -6200,7 +6155,7 @@ void shadow_propagate_process(struct rec
 
     if(opt.dump_all)
         printf("]%s propagate va %llx gl1e %llx flags (%x)%s\n",
-               h->dump_header,
+               ri->dump_header,
                e->va, e->gl1e, e->flags,
                flag_string(e));
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2G-0002UI-9O; Thu, 26 Jan 2012 17:22:56 +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 1RqT2E-0002Ix-7m
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327598561!8770385!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24480 invoked from network); 26 Jan 2012 17:22:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:22:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179243360"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:22:46 -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 q0QHMdRv009803;
	Thu, 26 Jan 2012 09:22:45 -0800
MIME-Version: 1.0
X-Mercurial-Node: 108d0235440318d51a3360a9cfba43753f04df54
Message-ID: <108d0235440318d51a33.1327598463@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:03 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 6 of 8] xenalyze: Eliminate unnecessary
	cycles_to_time	calculation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The time elements are only really accessed in dump mode, but they
cost a significant amount to calculate per record.  Only calculate
them if we're in dump mode.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 4b3639bd3255 -r 108d02354403 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:17:19 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:17:53 2012 +0000
@@ -8601,9 +8601,6 @@ void process_record_tsc(tsc_t order_tsc,
 
         P.now = tsc;
     }
-    
-    /* Convert to s/ns once for convenience */
-    abs_cycles_to_time(ri->tsc, &ri->t);
 }
 
 /* Standardized part of dump output */
@@ -8615,6 +8612,8 @@ void create_dump_header(struct record_in
     len = DUMP_HEADER_MAX;
     c = ri->dump_header;
 
+    abs_cycles_to_time(ri->tsc, &ri->t);
+
     if ( ri->t.time )
     {
         r=snprintf(c, len, "%3u.%09u", ri->t.s, ri->t.ns);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:22:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:22:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2G-0002UI-9O; Thu, 26 Jan 2012 17:22:56 +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 1RqT2E-0002Ix-7m
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:22:54 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327598561!8770385!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjU3NTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24480 invoked from network); 26 Jan 2012 17:22:48 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:22:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="179243360"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:22:46 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:22:46 -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 q0QHMdRv009803;
	Thu, 26 Jan 2012 09:22:45 -0800
MIME-Version: 1.0
X-Mercurial-Node: 108d0235440318d51a3360a9cfba43753f04df54
Message-ID: <108d0235440318d51a33.1327598463@elijah>
In-Reply-To: <patchbomb.1327598457@elijah>
References: <patchbomb.1327598457@elijah>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Thu, 26 Jan 2012 17:21:03 +0000
From: George Dunlap <george.dunlap@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: george.dunlap@eu.citrix.com
Subject: [Xen-devel] [PATCH 6 of 8] xenalyze: Eliminate unnecessary
	cycles_to_time	calculation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The time elements are only really accessed in dump mode, but they
cost a significant amount to calculate per record.  Only calculate
them if we're in dump mode.

Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>

diff -r 4b3639bd3255 -r 108d02354403 xenalyze.c
--- a/xenalyze.c	Thu Jan 26 17:17:19 2012 +0000
+++ b/xenalyze.c	Thu Jan 26 17:17:53 2012 +0000
@@ -8601,9 +8601,6 @@ void process_record_tsc(tsc_t order_tsc,
 
         P.now = tsc;
     }
-    
-    /* Convert to s/ns once for convenience */
-    abs_cycles_to_time(ri->tsc, &ri->t);
 }
 
 /* Standardized part of dump output */
@@ -8615,6 +8612,8 @@ void create_dump_header(struct record_in
     len = DUMP_HEADER_MAX;
     c = ri->dump_header;
 
+    abs_cycles_to_time(ri->tsc, &ri->t);
+
     if ( ri->t.time )
     {
         r=snprintf(c, len, "%3u.%09u", ri->t.s, ri->t.ns);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:23:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2s-0003Aj-UI; Thu, 26 Jan 2012 17:23:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RqT2q-00034V-Tg
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:23:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327598475!50201002!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23703 invoked from network); 26 Jan 2012 17:21:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:21:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315972"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:23:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:23:24 -0500
Received: from leeni.uk.xensource.com (leeni.uk.xensource.com [10.80.2.50])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0QHNMac009825;
	Thu, 26 Jan 2012 09:23:23 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org
Date: Thu, 26 Jan 2012 17:23:23 +0000
Message-ID: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.8.3
MIME-Version: 1.0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] xen-netfront: correct MAX_TX_TARGET calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 38f9c95..01f589d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -68,7 +68,7 @@ struct netfront_cb {
 
 #define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
 #define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-#define TX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
 
 struct netfront_stats {
 	u64			rx_packets;
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:23:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:23:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT2s-0003Aj-UI; Thu, 26 Jan 2012 17:23:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RqT2q-00034V-Tg
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:23:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1327598475!50201002!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23703 invoked from network); 26 Jan 2012 17:21:16 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:21:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21315972"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:23:25 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 12:23:24 -0500
Received: from leeni.uk.xensource.com (leeni.uk.xensource.com [10.80.2.50])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0QHNMac009825;
	Thu, 26 Jan 2012 09:23:23 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org
Date: Thu, 26 Jan 2012 17:23:23 +0000
Message-ID: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.8.3
MIME-Version: 1.0
Cc: jeremy@goop.org, xen-devel@lists.xensource.com,
	Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH] xen-netfront: correct MAX_TX_TARGET calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 38f9c95..01f589d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -68,7 +68,7 @@ struct netfront_cb {
 
 #define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
 #define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-#define TX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
 
 struct netfront_stats {
 	u64			rx_packets;
-- 
1.7.8.3


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:24:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT3P-0003aB-J2; Thu, 26 Jan 2012 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.Jackson@eu.citrix.com>) id 1RqT3O-0003VD-0s
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:24:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327598632!12603234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18606 invoked from network); 26 Jan 2012 17:23:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:23:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:23: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 1RqT39-0001dZ-CW;
	Thu, 26 Jan 2012 17:23:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqT39-0004qP-B6;
	Thu, 26 Jan 2012 17:23:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RqT39-0004qP-B6@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 17:23:51 +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://xenbits.xen.org/staging/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:  d5b706214616
  Bug not present: 1e27e827e6a8


  changeset:   24566:d5b706214616
  user:        Olaf Hering <olaf@aepfle.de>
  date:        Thu Jan 26 11:04:59 2012 +0000
      
      tools/libxc: fix error handling in xc_mem_paging_load
      
      xc_mem_paging_load() does not pass errors in errno and the actual
      errno from xc_mem_event_control() is overwritten by munlock().
      xenpaging_populate_page() needs to check errno, but with the switch to
      xc_mem_paging_load() it could not receive ENOMEM anymore.
      
      Update xc_mem_paging_load() to return -1 and preserve errno during
      munlock().
      
      Signed-off-by: Olaf Hering <olaf@aepfle.de>
      Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


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:
 11609 fail [host=moss-bug] / 11601 ok.
Failure / basis pass flights: 11609 / 11601
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest bb36d632e4cabf47882adff07a45c6702c4a5b30 570d0ea0ad2f
Basis pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/staging/qemu-xen-unstable.git#bb36d632e4cabf47882adff07a45c6702c4a5b30-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#4271634e4c86-570d0ea0ad2f
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 127 nodes in revision graph
Searching for test results:
 11600 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
 11601 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
 11603 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d8f280c78544
 11604 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
 11606 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d8f280c78544
 11607 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 1e27e827e6a8
 11611 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d5b706214616
 11612 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 1e27e827e6a8
 11609 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 570d0ea0ad2f
 11613 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d5b706214616
 11614 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
 11615 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 570d0ea0ad2f
 11616 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 1e27e827e6a8
 11617 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d5b706214616
Searching for interesting versions
 Result found: flight 11600 (pass), for basis pass
 Result found: flight 11609 (fail), for basis failure
 Repro found: flight 11614 (pass), for basis pass
 Repro found: flight 11615 (fail), for basis failure
 0 revisions at bb36d632e4cabf47882adff07a45c6702c4a5b30 1e27e827e6a8
No revisions left to test, checking graph state.
 Result found: flight 11607 (pass), for last pass
 Result found: flight 11611 (fail), for first failure
 Repro found: flight 11612 (pass), for last pass
 Repro found: flight 11613 (fail), for first failure
 Repro found: flight 11616 (pass), for last pass
 Repro found: flight 11617 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  d5b706214616
  Bug not present: 1e27e827e6a8

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24566:d5b706214616
  user:        Olaf Hering <olaf@aepfle.de>
  date:        Thu Jan 26 11:04:59 2012 +0000
      
      tools/libxc: fix error handling in xc_mem_paging_load
      
      xc_mem_paging_load() does not pass errors in errno and the actual
      errno from xc_mem_event_control() is overwritten by munlock().
      xenpaging_populate_page() needs to check errno, but with the switch to
      xc_mem_paging_load() it could not receive ENOMEM anymore.
      
      Update xc_mem_paging_load() to return -1 and preserve errno during
      munlock().
      
      Signed-off-by: Olaf Hering <olaf@aepfle.de>
      Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}.
----------------------------------------
11617: ALL FAIL

flight 11617 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11617/


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 Thu Jan 26 17:24:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqT3P-0003aB-J2; Thu, 26 Jan 2012 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.Jackson@eu.citrix.com>) id 1RqT3O-0003VD-0s
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:24:06 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327598632!12603234!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18606 invoked from network); 26 Jan 2012 17:23:52 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:23:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:23:51 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:23: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 1RqT39-0001dZ-CW;
	Thu, 26 Jan 2012 17:23:51 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqT39-0004qP-B6;
	Thu, 26 Jan 2012 17:23:51 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <E1RqT39-0004qP-B6@woking.xci-test.com>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 17:23:51 +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://xenbits.xen.org/staging/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:  d5b706214616
  Bug not present: 1e27e827e6a8


  changeset:   24566:d5b706214616
  user:        Olaf Hering <olaf@aepfle.de>
  date:        Thu Jan 26 11:04:59 2012 +0000
      
      tools/libxc: fix error handling in xc_mem_paging_load
      
      xc_mem_paging_load() does not pass errors in errno and the actual
      errno from xc_mem_event_control() is overwritten by munlock().
      xenpaging_populate_page() needs to check errno, but with the switch to
      xc_mem_paging_load() it could not receive ENOMEM anymore.
      
      Update xc_mem_paging_load() to return -1 and preserve errno during
      munlock().
      
      Signed-off-by: Olaf Hering <olaf@aepfle.de>
      Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
      Committed-by: Keir Fraser <keir@xen.org>
      
      


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:
 11609 fail [host=moss-bug] / 11601 ok.
Failure / basis pass flights: 11609 / 11601
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest bb36d632e4cabf47882adff07a45c6702c4a5b30 570d0ea0ad2f
Basis pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
Generating revisions with ./adhoc-revtuple-generator  git://xenbits.xen.org/staging/qemu-xen-unstable.git#bb36d632e4cabf47882adff07a45c6702c4a5b30-bb36d632e4cabf47882adff07a45c6702c4a5b30 http://xenbits.xen.org/staging/xen-unstable.hg#4271634e4c86-570d0ea0ad2f
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 127 nodes in revision graph
Searching for test results:
 11600 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
 11601 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
 11603 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d8f280c78544
 11604 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
 11606 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d8f280c78544
 11607 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 1e27e827e6a8
 11611 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d5b706214616
 11612 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 1e27e827e6a8
 11609 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 570d0ea0ad2f
 11613 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d5b706214616
 11614 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 4271634e4c86
 11615 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 570d0ea0ad2f
 11616 pass bb36d632e4cabf47882adff07a45c6702c4a5b30 1e27e827e6a8
 11617 fail bb36d632e4cabf47882adff07a45c6702c4a5b30 d5b706214616
Searching for interesting versions
 Result found: flight 11600 (pass), for basis pass
 Result found: flight 11609 (fail), for basis failure
 Repro found: flight 11614 (pass), for basis pass
 Repro found: flight 11615 (fail), for basis failure
 0 revisions at bb36d632e4cabf47882adff07a45c6702c4a5b30 1e27e827e6a8
No revisions left to test, checking graph state.
 Result found: flight 11607 (pass), for last pass
 Result found: flight 11611 (fail), for first failure
 Repro found: flight 11612 (pass), for last pass
 Repro found: flight 11613 (fail), for first failure
 Repro found: flight 11616 (pass), for last pass
 Repro found: flight 11617 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
  Bug introduced:  d5b706214616
  Bug not present: 1e27e827e6a8

pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found

  changeset:   24566:d5b706214616
  user:        Olaf Hering <olaf@aepfle.de>
  date:        Thu Jan 26 11:04:59 2012 +0000
      
      tools/libxc: fix error handling in xc_mem_paging_load
      
      xc_mem_paging_load() does not pass errors in errno and the actual
      errno from xc_mem_event_control() is overwritten by munlock().
      xenpaging_populate_page() needs to check errno, but with the switch to
      xc_mem_paging_load() it could not receive ENOMEM anymore.
      
      Update xc_mem_paging_load() to return -1 and preserve errno during
      munlock().
      
      Signed-off-by: Olaf Hering <olaf@aepfle.de>
      Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
      Committed-by: Keir Fraser <keir@xen.org>
      
      

Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.build-amd64.xen-build.{dot,ps,png,html}.
----------------------------------------
11617: ALL FAIL

flight 11617 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11617/


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 Thu Jan 26 17:28:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT7W-0005Ei-CW; Thu, 26 Jan 2012 17:28: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 1RqT7V-0005EG-C3
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:28:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327598894!12730063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7974 invoked from network); 26 Jan 2012 17:28:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:28:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:27: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, 26 Jan 2012 17:27: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
	1RqT6z-0001fL-CO; Thu, 26 Jan 2012 17:27:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT6z-0007Re-BU;
	Thu, 26 Jan 2012 17:27:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.36117.343474.863135@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:27:49 +0000
To: Olaf Hering <olaf@aepfle.de>, Andres Lagar-Cavilla
	<andres@lagarcavilla.org>, Keir Fraser <keir@xen.org>
In-Reply-To: <E1RqT39-0004qP-B6@woking.xci-test.com>
References: <E1RqT39-0004qP-B6@woking.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [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

xen.org writes ("[xen-unstable bisection] complete build-amd64"):
> branch xen-unstable
> xen branch xen-unstable
> job build-amd64
> test xen-build
> 
> Tree: qemu git://xenbits.xen.org/staging/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:  d5b706214616
>   Bug not present: 1e27e827e6a8
> 
> 
>   changeset:   24566:d5b706214616
>   user:        Olaf Hering <olaf@aepfle.de>
>   date:        Thu Jan 26 11:04:59 2012 +0000
>       
>       tools/libxc: fix error handling in xc_mem_paging_load
>       
>       xc_mem_paging_load() does not pass errors in errno and the actual
>       errno from xc_mem_event_control() is overwritten by munlock().
>       xenpaging_populate_page() needs to check errno, but with the switch to
>       xc_mem_paging_load() it could not receive ENOMEM anymore.
>       
>       Update xc_mem_paging_load() to return -1 and preserve errno during
>       munlock().
>       
>       Signed-off-by: Olaf Hering <olaf@aepfle.de>
>       Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>       Committed-by: Keir Fraser <keir@xen.org>

cc1: warnings being treated as errors
xc_mem_paging.c: In function 'xc_mem_paging_load':
xc_mem_paging.c:90: error: statement with no effect
make[3]: *** [xc_mem_paging.o] Error 1
make[3]: Leaving directory `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
make[1]: *** [libxc-x86_64/libxenctrl.a] Error 2
make[1]: *** Waiting for unfinished jobs....

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:28:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqT7W-0005Ei-CW; Thu, 26 Jan 2012 17:28: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 1RqT7V-0005EG-C3
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:28:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327598894!12730063!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7974 invoked from network); 26 Jan 2012 17:28:15 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:28:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:27: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, 26 Jan 2012 17:27: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
	1RqT6z-0001fL-CO; Thu, 26 Jan 2012 17:27:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqT6z-0007Re-BU;
	Thu, 26 Jan 2012 17:27:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.36117.343474.863135@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:27:49 +0000
To: Olaf Hering <olaf@aepfle.de>, Andres Lagar-Cavilla
	<andres@lagarcavilla.org>, Keir Fraser <keir@xen.org>
In-Reply-To: <E1RqT39-0004qP-B6@woking.xci-test.com>
References: <E1RqT39-0004qP-B6@woking.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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [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

xen.org writes ("[xen-unstable bisection] complete build-amd64"):
> branch xen-unstable
> xen branch xen-unstable
> job build-amd64
> test xen-build
> 
> Tree: qemu git://xenbits.xen.org/staging/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:  d5b706214616
>   Bug not present: 1e27e827e6a8
> 
> 
>   changeset:   24566:d5b706214616
>   user:        Olaf Hering <olaf@aepfle.de>
>   date:        Thu Jan 26 11:04:59 2012 +0000
>       
>       tools/libxc: fix error handling in xc_mem_paging_load
>       
>       xc_mem_paging_load() does not pass errors in errno and the actual
>       errno from xc_mem_event_control() is overwritten by munlock().
>       xenpaging_populate_page() needs to check errno, but with the switch to
>       xc_mem_paging_load() it could not receive ENOMEM anymore.
>       
>       Update xc_mem_paging_load() to return -1 and preserve errno during
>       munlock().
>       
>       Signed-off-by: Olaf Hering <olaf@aepfle.de>
>       Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>       Committed-by: Keir Fraser <keir@xen.org>

cc1: warnings being treated as errors
xc_mem_paging.c: In function 'xc_mem_paging_load':
xc_mem_paging.c:90: error: statement with no effect
make[3]: *** [xc_mem_paging.o] Error 1
make[3]: Leaving directory `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
make[2]: *** [build] Error 2
make[2]: Leaving directory `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
make[1]: *** [libxc-x86_64/libxenctrl.a] Error 2
make[1]: *** Waiting for unfinished jobs....

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:37:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTFv-0005Qv-QQ; Thu, 26 Jan 2012 17:37:03 +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 1RqTFv-0005Qq-4D
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:37:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327599417!8483856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13478 invoked from network); 26 Jan 2012 17:36:57 -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;
	26 Jan 2012 17:36:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:36: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, 26 Jan 2012 17:36:57 +0000
Date: Thu, 26 Jan 2012 17:37:47 +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: <CB473A40.29ABD%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
References: <CB473A40.29ABD%keir.xen@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Keir Fraser wrote:
> On 26/01/2012 16:45, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
> wrote:
> 
> >> If that's the case then there is precedent (e.g. sched_op, physdev_op,
> >> evtchn_op) for renaming the existing thing FOO_compat and taking over
> >> the name with the new semantics.
> >> 
> >> That's certainly better than _new->_newer->really_new etc. If you must
> >> go down that route then adding a number seems preferable.
> > 
> > In that case, I vote for taking over the existing name with the new
> > hypercall.
> 
> Agreed, but you have to be careful because other codebases expect to be able
> to sync with our public headers without subtle side effects.
> 
> The correct thing to do here is probably to rename the old command to
> PHYSDEVOP_pirq_eoi_gmfn_v1, and your new one ..._v2.
> 
> Then you bump XEN_LATEST_INTERFACE_VERSION to 0x00040200 (somewhat
> arbitrarily!), and at the end of physdev.h you put something like:
> #if __XEN_INTERFACE_VERSION < 0x00040200
> #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
> #else
> #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
> #endif
> 
> Perfect, those who want the explicitly versioned command can use it. Old
> codebases can sync with new headers safely. Or codebases can be updated for
> latest XEN_INTERFACE_VERSION and default to the latest sanest command
> versions.

Great, I'll make the change and repost.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:37:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:37:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTFv-0005Qv-QQ; Thu, 26 Jan 2012 17:37:03 +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 1RqTFv-0005Qq-4D
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:37:03 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327599417!8483856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13478 invoked from network); 26 Jan 2012 17:36:57 -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;
	26 Jan 2012 17:36:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312471"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:36: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, 26 Jan 2012 17:36:57 +0000
Date: Thu, 26 Jan 2012 17:37:47 +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: <CB473A40.29ABD%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
References: <CB473A40.29ABD%keir.xen@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH 1/2] xen: Introduce
 PHYSDEVOP_pirq_eoi_gmfn_new
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Keir Fraser wrote:
> On 26/01/2012 16:45, "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
> wrote:
> 
> >> If that's the case then there is precedent (e.g. sched_op, physdev_op,
> >> evtchn_op) for renaming the existing thing FOO_compat and taking over
> >> the name with the new semantics.
> >> 
> >> That's certainly better than _new->_newer->really_new etc. If you must
> >> go down that route then adding a number seems preferable.
> > 
> > In that case, I vote for taking over the existing name with the new
> > hypercall.
> 
> Agreed, but you have to be careful because other codebases expect to be able
> to sync with our public headers without subtle side effects.
> 
> The correct thing to do here is probably to rename the old command to
> PHYSDEVOP_pirq_eoi_gmfn_v1, and your new one ..._v2.
> 
> Then you bump XEN_LATEST_INTERFACE_VERSION to 0x00040200 (somewhat
> arbitrarily!), and at the end of physdev.h you put something like:
> #if __XEN_INTERFACE_VERSION < 0x00040200
> #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
> #else
> #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
> #endif
> 
> Perfect, those who want the explicitly versioned command can use it. Old
> codebases can sync with new headers safely. Or codebases can be updated for
> latest XEN_INTERFACE_VERSION and default to the latest sanest command
> versions.

Great, I'll make the change and repost.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:38:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTHF-0005W2-Vm; Thu, 26 Jan 2012 17:38:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqTHE-0005Vs-Ai
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:38:24 +0000
Received: from [85.158.138.51:33441] by server-11.bemta-3.messagelabs.com id
	BD/76-26051-F8F812F4; Thu, 26 Jan 2012 17:38:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327599502!10823104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14534 invoked from network); 26 Jan 2012 17:38:22 -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;
	26 Jan 2012 17:38:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:38: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, 26 Jan 2012 17:38: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
	1RqTH2-0001id-3P; Thu, 26 Jan 2012 17:38:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqTH2-0007Sb-2X;
	Thu, 26 Jan 2012 17:38:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.36740.66832.65035@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:38:12 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <58c924a72ab7af658a88.1326455852@loki.upc.es>
References: <58c924a72ab7af658a88.1326455852@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] libxl: fix parse_backend_path and
 device_backend_path to be mutual
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] libxl: fix parse_backend_path and device_backend_path to be mutual"):
> libxl: fix parse_backend_path and device_backend_path to be mutual

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 Jan 26 17:38:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:38:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTHF-0005W2-Vm; Thu, 26 Jan 2012 17:38:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqTHE-0005Vs-Ai
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:38:24 +0000
Received: from [85.158.138.51:33441] by server-11.bemta-3.messagelabs.com id
	BD/76-26051-F8F812F4; Thu, 26 Jan 2012 17:38:23 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327599502!10823104!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14534 invoked from network); 26 Jan 2012 17:38:22 -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;
	26 Jan 2012 17:38:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312499"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:38: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, 26 Jan 2012 17:38: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
	1RqTH2-0001id-3P; Thu, 26 Jan 2012 17:38:12 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqTH2-0007Sb-2X;
	Thu, 26 Jan 2012 17:38:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.36740.66832.65035@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:38:12 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <58c924a72ab7af658a88.1326455852@loki.upc.es>
References: <58c924a72ab7af658a88.1326455852@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] libxl: fix parse_backend_path and
 device_backend_path to be mutual
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] libxl: fix parse_backend_path and device_backend_path to be mutual"):
> libxl: fix parse_backend_path and device_backend_path to be mutual

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 Jan 26 17:39:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqTHi-0005aX-Dj; Thu, 26 Jan 2012 17:38:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqTHh-0005aG-H9
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:38:53 +0000
Received: from [85.158.138.51:7296] by server-11.bemta-3.messagelabs.com id
	E8/27-26051-CAF812F4; Thu, 26 Jan 2012 17:38:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327599532!10822543!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8170 invoked from network); 26 Jan 2012 17:38:52 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:38:52 -0000
Received: by werb14 with SMTP id b14so1953278wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 09:38: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=w7D1ZOlTrEcilg2PdgA64IgToWwxo434dMG/dQ5NYT4=;
	b=AVPs9kgfj2ohXGoc3zRXit73lycmcGv3Fs6/CowbyF1VftuKO6wbtzLHOIbFhZftsj
	38K7BJI2aQNpGPiZ2tNdHATb+y9f9N/qkhpfas1j5BcIeybu97wLbSjxoOyOtgFQIOub
	1AgQY0EVg9p5HzrhFoc/XipDTX9IbQyx+MrwI=
Received: by 10.216.136.70 with SMTP id v48mr1313757wei.48.1327599531974;
	Thu, 26 Jan 2012 09:38:51 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fr8sm14664946wib.10.2012.01.26.09.38.47
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 09:38:51 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 17:38:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB474023.29C50%keir.xen@gmail.com>
Thread-Topic: [xen-unstable bisection] complete build-amd64
Thread-Index: AczcUVj3VFWidkMa/0atiDzALUY1Dg==
In-Reply-To: <20257.36117.343474.863135@mariner.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-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

On 26/01/2012 17:27, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> xen.org writes ("[xen-unstable bisection] complete build-amd64"):
>> branch xen-unstable
>> xen branch xen-unstable
>> job build-amd64
>> test xen-build
>> 
>> Tree: qemu git://xenbits.xen.org/staging/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:  d5b706214616
>>   Bug not present: 1e27e827e6a8
>> 
>> 
>>   changeset:   24566:d5b706214616
>>   user:        Olaf Hering <olaf@aepfle.de>
>>   date:        Thu Jan 26 11:04:59 2012 +0000
>>       
>>       tools/libxc: fix error handling in xc_mem_paging_load
>>       
>>       xc_mem_paging_load() does not pass errors in errno and the actual
>>       errno from xc_mem_event_control() is overwritten by munlock().
>>       xenpaging_populate_page() needs to check errno, but with the switch to
>>       xc_mem_paging_load() it could not receive ENOMEM anymore.
>>       
>>       Update xc_mem_paging_load() to return -1 and preserve errno during
>>       munlock().
>>       
>>       Signed-off-by: Olaf Hering <olaf@aepfle.de>
>>       Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>       Committed-by: Keir Fraser <keir@xen.org>
> 
> cc1: warnings being treated as errors
> xc_mem_paging.c: In function 'xc_mem_paging_load':
> xc_mem_paging.c:90: error: statement with no effect
> make[3]: *** [xc_mem_paging.o] Error 1
> make[3]: Leaving directory
> `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
> make[2]: *** [build] Error 2
> make[2]: Leaving directory
> `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
> make[1]: *** [libxc-x86_64/libxenctrl.a] Error 2
> make[1]: *** Waiting for unfinished jobs....

Tim already fixed it.

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:39:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqTHi-0005aX-Dj; Thu, 26 Jan 2012 17:38:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RqTHh-0005aG-H9
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:38:53 +0000
Received: from [85.158.138.51:7296] by server-11.bemta-3.messagelabs.com id
	E8/27-26051-CAF812F4; Thu, 26 Jan 2012 17:38:52 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327599532!10822543!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8170 invoked from network); 26 Jan 2012 17:38:52 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-5.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:38:52 -0000
Received: by werb14 with SMTP id b14so1953278wer.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 09:38: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=w7D1ZOlTrEcilg2PdgA64IgToWwxo434dMG/dQ5NYT4=;
	b=AVPs9kgfj2ohXGoc3zRXit73lycmcGv3Fs6/CowbyF1VftuKO6wbtzLHOIbFhZftsj
	38K7BJI2aQNpGPiZ2tNdHATb+y9f9N/qkhpfas1j5BcIeybu97wLbSjxoOyOtgFQIOub
	1AgQY0EVg9p5HzrhFoc/XipDTX9IbQyx+MrwI=
Received: by 10.216.136.70 with SMTP id v48mr1313757wei.48.1327599531974;
	Thu, 26 Jan 2012 09:38:51 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fr8sm14664946wib.10.2012.01.26.09.38.47
	(version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 09:38:51 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Thu, 26 Jan 2012 17:38:43 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <CB474023.29C50%keir.xen@gmail.com>
Thread-Topic: [xen-unstable bisection] complete build-amd64
Thread-Index: AczcUVj3VFWidkMa/0atiDzALUY1Dg==
In-Reply-To: <20257.36117.343474.863135@mariner.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-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

On 26/01/2012 17:27, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:

> xen.org writes ("[xen-unstable bisection] complete build-amd64"):
>> branch xen-unstable
>> xen branch xen-unstable
>> job build-amd64
>> test xen-build
>> 
>> Tree: qemu git://xenbits.xen.org/staging/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:  d5b706214616
>>   Bug not present: 1e27e827e6a8
>> 
>> 
>>   changeset:   24566:d5b706214616
>>   user:        Olaf Hering <olaf@aepfle.de>
>>   date:        Thu Jan 26 11:04:59 2012 +0000
>>       
>>       tools/libxc: fix error handling in xc_mem_paging_load
>>       
>>       xc_mem_paging_load() does not pass errors in errno and the actual
>>       errno from xc_mem_event_control() is overwritten by munlock().
>>       xenpaging_populate_page() needs to check errno, but with the switch to
>>       xc_mem_paging_load() it could not receive ENOMEM anymore.
>>       
>>       Update xc_mem_paging_load() to return -1 and preserve errno during
>>       munlock().
>>       
>>       Signed-off-by: Olaf Hering <olaf@aepfle.de>
>>       Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>>       Committed-by: Keir Fraser <keir@xen.org>
> 
> cc1: warnings being treated as errors
> xc_mem_paging.c: In function 'xc_mem_paging_load':
> xc_mem_paging.c:90: error: statement with no effect
> make[3]: *** [xc_mem_paging.o] Error 1
> make[3]: Leaving directory
> `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
> make[2]: *** [build] Error 2
> make[2]: Leaving directory
> `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
> make[1]: *** [libxc-x86_64/libxenctrl.a] Error 2
> make[1]: *** Waiting for unfinished jobs....

Tim already fixed it.

 -- Keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTIU-0005pV-TR; Thu, 26 Jan 2012 17:39:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqTIT-0005p9-El
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:39:41 +0000
Received: from [85.158.139.83:4856] by server-5.bemta-5.messagelabs.com id
	5E/FE-12374-CDF812F4; Thu, 26 Jan 2012 17:39:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327599579!5202925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32035 invoked from network); 26 Jan 2012 17:39:40 -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;
	26 Jan 2012 17:39:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:39:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:39: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
	1RqTIQ-0001jE-KB; Thu, 26 Jan 2012 17:39:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqTIQ-0007TN-JJ;
	Thu, 26 Jan 2012 17:39:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.36826.585338.693922@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:39:38 +0000
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB474023.29C50%keir.xen@gmail.com>
References: <20257.36117.343474.863135@mariner.uk.xensource.com>
	<CB474023.29C50%keir.xen@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>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [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

Keir Fraser writes ("Re: [xen-unstable bisection] complete build-amd64"):
> Tim already fixed it.

Yes, so Ian points out to me...

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:39:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:39:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTIU-0005pV-TR; Thu, 26 Jan 2012 17:39:42 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqTIT-0005p9-El
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:39:41 +0000
Received: from [85.158.139.83:4856] by server-5.bemta-5.messagelabs.com id
	5E/FE-12374-CDF812F4; Thu, 26 Jan 2012 17:39:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327599579!5202925!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32035 invoked from network); 26 Jan 2012 17:39:40 -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;
	26 Jan 2012 17:39:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312530"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:39:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:39: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
	1RqTIQ-0001jE-KB; Thu, 26 Jan 2012 17:39:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqTIQ-0007TN-JJ;
	Thu, 26 Jan 2012 17:39:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.36826.585338.693922@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:39:38 +0000
To: Keir Fraser <keir.xen@gmail.com>
In-Reply-To: <CB474023.29C50%keir.xen@gmail.com>
References: <20257.36117.343474.863135@mariner.uk.xensource.com>
	<CB474023.29C50%keir.xen@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>,
	Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [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

Keir Fraser writes ("Re: [xen-unstable bisection] complete build-amd64"):
> Tim already fixed it.

Yes, so Ian points out to me...

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:41:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqTKJ-0006EX-Ek; Thu, 26 Jan 2012 17:41: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 1RqTKH-0006DI-4N
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:41:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327599686!3795440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27776 invoked from network); 26 Jan 2012 17:41:27 -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;
	26 Jan 2012 17:41:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:41:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:41:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqTKA-0001k1-9D; Thu, 26 Jan 2012 17:41:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqTKA-0007Tk-8O;
	Thu, 26 Jan 2012 17:41:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.36934.246893.233669@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:41:26 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bb6b01995d64f7c2887b.1326460363@loki.upc.es>
References: <bb6b01995d64f7c2887b.1326460363@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] 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

Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: fix mutex initialization"):
> +    pthread_mutexattr_t attr;
> +
> +    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(lock, &attr) != 0) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
> +                         "Failed to init mutex\n");
> +        return ERROR_FAIL;
> +    }
> +    return 0;

This leaks the contents of attr.  You need to call
pthread_mutexattr_destroy on all the exit paths (except the one where
_init failed).

What a horrible API for passing in some trivial flags!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:41:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqTKJ-0006EX-Ek; Thu, 26 Jan 2012 17:41: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 1RqTKH-0006DI-4N
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:41:33 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327599686!3795440!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27776 invoked from network); 26 Jan 2012 17:41:27 -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;
	26 Jan 2012 17:41:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312573"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:41:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:41:26 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqTKA-0001k1-9D; Thu, 26 Jan 2012 17:41:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqTKA-0007Tk-8O;
	Thu, 26 Jan 2012 17:41:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.36934.246893.233669@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:41:26 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <bb6b01995d64f7c2887b.1326460363@loki.upc.es>
References: <bb6b01995d64f7c2887b.1326460363@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] 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

Roger Pau Monne writes ("[Xen-devel] [PATCH] libxl: fix mutex initialization"):
> +    pthread_mutexattr_t attr;
> +
> +    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(lock, &attr) != 0) {
> +        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
> +                         "Failed to init mutex\n");
> +        return ERROR_FAIL;
> +    }
> +    return 0;

This leaks the contents of attr.  You need to call
pthread_mutexattr_destroy on all the exit paths (except the one where
_init failed).

What a horrible API for passing in some trivial flags!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 17:44:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTMs-0006cE-6m; Thu, 26 Jan 2012 17:44: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 1RqTMr-0006bf-BX
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:44:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327599847!10116852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18888 invoked from network); 26 Jan 2012 17:44:07 -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;
	26 Jan 2012 17:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312610"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:43:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:43: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
	1RqTMI-0001kk-LE; Thu, 26 Jan 2012 17:43:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqTMI-0007UT-KL;
	Thu, 26 Jan 2012 17:43:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.37066.614082.699163@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:43:38 +0000
To: Jim Fehlig <jfehlig@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <77587801a436ce36eb29.1326476888@jfehlig1.provo.novell.com>
References: <77587801a436ce36eb29.1326476888@jfehlig1.provo.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix setting XENSTORED_ROOTDIR in xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jim Fehlig writes ("[Xen-devel] [PATCH] Fix setting XENSTORED_ROOTDIR in xencommons"):
> Fix setting XENSTORED_ROOTDIR in xencommons

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 Jan 26 17:44:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17:44:23 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTMs-0006cE-6m; Thu, 26 Jan 2012 17:44: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 1RqTMr-0006bf-BX
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:44:13 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327599847!10116852!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18888 invoked from network); 26 Jan 2012 17:44:07 -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;
	26 Jan 2012 17:44:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312610"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:43:39 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Thu, 26 Jan 2012 17:43: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
	1RqTMI-0001kk-LE; Thu, 26 Jan 2012 17:43:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqTMI-0007UT-KL;
	Thu, 26 Jan 2012 17:43:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20257.37066.614082.699163@mariner.uk.xensource.com>
Date: Thu, 26 Jan 2012 17:43:38 +0000
To: Jim Fehlig <jfehlig@suse.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <77587801a436ce36eb29.1326476888@jfehlig1.provo.novell.com>
References: <77587801a436ce36eb29.1326476888@jfehlig1.provo.novell.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] Fix setting XENSTORED_ROOTDIR in xencommons
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Jim Fehlig writes ("[Xen-devel] [PATCH] Fix setting XENSTORED_ROOTDIR in xencommons"):
> Fix setting XENSTORED_ROOTDIR in xencommons

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 Jan 26 17:58:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqTal-00075w-N8; Thu, 26 Jan 2012 17:58:35 +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 1RqTak-00075r-6y
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:58:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327600708!4173055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26387 invoked from network); 26 Jan 2012 17:58:28 -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;
	26 Jan 2012 17:58:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:58: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; Thu, 26 Jan 2012 17:58:28 +0000
Date: Thu, 26 Jan 2012 17:59:18 +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.1201261749190.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v2 0/2] use pirq_eoi_map in modern Linux kernels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series consists of two patches: a patch for Xen and a
patch for Linux.

The Xen patch implements PHYSDEVOP_pirq_eoi_gmfn_v2, a new version of
PHYSDEVOP_pirq_eoi_gmfn that does not change the semantics of
PHYSDEVOP_eoi.

The Linux patch introduces pirq_eoi_map in drivers/xen/events.c, using
PHYSDEVOP_pirq_eoi_gmfn_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 Thu Jan 26 17:58:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 17: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 1RqTal-00075w-N8; Thu, 26 Jan 2012 17:58:35 +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 1RqTak-00075r-6y
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:58:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327600708!4173055!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26387 invoked from network); 26 Jan 2012 17:58:28 -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;
	26 Jan 2012 17:58:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320624000"; d="scan'208";a="10312797"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 17:58: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; Thu, 26 Jan 2012 17:58:28 +0000
Date: Thu, 26 Jan 2012 17:59:18 +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.1201261749190.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v2 0/2] use pirq_eoi_map in modern Linux kernels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series consists of two patches: a patch for Xen and a
patch for Linux.

The Xen patch implements PHYSDEVOP_pirq_eoi_gmfn_v2, a new version of
PHYSDEVOP_pirq_eoi_gmfn that does not change the semantics of
PHYSDEVOP_eoi.

The Linux patch introduces pirq_eoi_map in drivers/xen/events.c, using
PHYSDEVOP_pirq_eoi_gmfn_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 Thu Jan 26 18:00:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTc6-0007Ab-Ll; Thu, 26 Jan 2012 17:59:58 +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 1RqTc5-0007A4-El
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:59:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327600784!10118764!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6054 invoked from network); 26 Jan 2012 17:59:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:59:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21317062"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:59:50 -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, 26 Jan 2012 12:59: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 q0QHxZH4009946;
	Thu, 26 Jan 2012 09:59:38 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 18:00:39 +0000
Message-ID: <1327600839-23469-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.1201261736580.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org,
	Ian.Campbell@citrix.com, JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: 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 pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
be EOI'd without having to issue an hypercall every time.
We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
succeed, we use pirq_eoi_map to check whether pirqs need eoi.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c            |   17 ++++++++++++++++-
 include/xen/interface/physdev.h |   12 ++++++++++++
 2 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..7fdc738 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -37,6 +37,7 @@
 #include <asm/idle.h>
 #include <asm/io_apic.h>
 #include <asm/sync_bitops.h>
+#include <asm/xen/page.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -108,6 +109,7 @@ struct irq_info {
 #define PIRQ_SHAREABLE	(1 << 1)
 
 static int *evtchn_to_irq;
+static unsigned long *pirq_eoi_map;
 
 static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
 		      cpu_evtchn_mask);
@@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
 
 	BUG_ON(info->type != IRQT_PIRQ);
 
+	if (pirq_eoi_map != NULL)
+		return test_bit(irq, pirq_eoi_map);
+
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
@@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
 
 void __init xen_init_IRQ(void)
 {
-	int i;
+	int i, rc;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		struct physdev_pirq_eoi_gmfn eoi_gmfn;
+
 		irq_ctx_init(smp_processor_id());
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
+
+		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);
+		if (rc != 0) {
+			free_page((unsigned long) pirq_eoi_map);
+			pirq_eoi_map = NULL;
+		}
 	}
 }
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index c1080d9..132c61f 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -39,6 +39,18 @@ struct physdev_eoi {
 };
 
 /*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
+ * array indexed by Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn      28
+struct physdev_pirq_eoi_gmfn {
+    /* IN */
+    unsigned long gmfn;
+};
+
+
+/*
  * Query the status of an IRQ line.
  * @arg == pointer to physdev_irq_status_query structure.
  */
-- 
1.7.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 Jan 26 18:00:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTc6-0007Ab-Ll; Thu, 26 Jan 2012 17:59:58 +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 1RqTc5-0007A4-El
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:59:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327600784!10118764!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6054 invoked from network); 26 Jan 2012 17:59:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:59:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21317062"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:59:50 -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, 26 Jan 2012 12:59: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 q0QHxZH4009946;
	Thu, 26 Jan 2012 09:59:38 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 18:00:39 +0000
Message-ID: <1327600839-23469-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.1201261736580.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org,
	Ian.Campbell@citrix.com, JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: 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 pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
be EOI'd without having to issue an hypercall every time.
We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
succeed, we use pirq_eoi_map to check whether pirqs need eoi.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c            |   17 ++++++++++++++++-
 include/xen/interface/physdev.h |   12 ++++++++++++
 2 files changed, 28 insertions(+), 1 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..7fdc738 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -37,6 +37,7 @@
 #include <asm/idle.h>
 #include <asm/io_apic.h>
 #include <asm/sync_bitops.h>
+#include <asm/xen/page.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -108,6 +109,7 @@ struct irq_info {
 #define PIRQ_SHAREABLE	(1 << 1)
 
 static int *evtchn_to_irq;
+static unsigned long *pirq_eoi_map;
 
 static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
 		      cpu_evtchn_mask);
@@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
 
 	BUG_ON(info->type != IRQT_PIRQ);
 
+	if (pirq_eoi_map != NULL)
+		return test_bit(irq, pirq_eoi_map);
+
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
 }
 
@@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
 
 void __init xen_init_IRQ(void)
 {
-	int i;
+	int i, rc;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		struct physdev_pirq_eoi_gmfn eoi_gmfn;
+
 		irq_ctx_init(smp_processor_id());
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
+
+		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);
+		if (rc != 0) {
+			free_page((unsigned long) pirq_eoi_map);
+			pirq_eoi_map = NULL;
+		}
 	}
 }
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index c1080d9..132c61f 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -39,6 +39,18 @@ struct physdev_eoi {
 };
 
 /*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
+ * array indexed by Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn      28
+struct physdev_pirq_eoi_gmfn {
+    /* IN */
+    unsigned long gmfn;
+};
+
+
+/*
  * Query the status of an IRQ line.
  * @arg == pointer to physdev_irq_status_query structure.
  */
-- 
1.7.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 Jan 26 18:00:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTc2-0007AE-8O; Thu, 26 Jan 2012 17:59:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqTc0-00079i-19
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:59:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327600784!10118764!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5788 invoked from network); 26 Jan 2012 17:59:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21317059"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:59:44 -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, 26 Jan 2012 12:59: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 q0QHxZH3009946;
	Thu, 26 Jan 2012 09:59:36 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 18:00:38 +0000
Message-ID: <1327600839-23469-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.1201261736580.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org,
	Ian.Campbell@citrix.com, JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v2 1/2] xen: introduce PHYSDEVOP_pirq_eoi_gmfn_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

PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
In order to improve the interface this patch:

- renames PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1;

- introduces PHYSDEVOP_pirq_eoi_gmfn_v2, that is like
  PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't modify the behaviour of
  another hypercall;

- bump __XEN_LATEST_INTERFACE_VERSION__;

- #define PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1 or
  PHYSDEVOP_pirq_eoi_gmfn_v2 depending on the __XEN_INTERFACE_VERSION.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/xen/domain.c      |    1 +
 xen/arch/ia64/xen/hypercall.c   |    7 +++++--
 xen/arch/x86/domain.c           |    1 +
 xen/arch/x86/physdev.c          |    7 +++++--
 xen/include/asm-ia64/domain.h   |    3 +++
 xen/include/asm-x86/domain.h    |    3 +++
 xen/include/public/physdev.h    |   16 +++++++++++++++-
 xen/include/public/xen-compat.h |    2 +-
 8 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
index 1ea5a90..a31bd32 100644
--- a/xen/arch/ia64/xen/domain.c
+++ b/xen/arch/ia64/xen/domain.c
@@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
 		if (d->arch.pirq_eoi_map != NULL) {
 			put_page(virt_to_page(d->arch.pirq_eoi_map));
 			d->arch.pirq_eoi_map = NULL;
+			d->arch.auto_unmask = 0;
 		}
 
 		/* Tear down shadow mode stuff. */
diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
index 130675e..18930bf 100644
--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
 {
 	if ( pirq < 0 || pirq >= NR_IRQS )
 		return -EINVAL;
-	if ( d->arch.pirq_eoi_map ) {
+	if ( d->arch.auto_unmask ) {
 		spin_lock(&d->event_lock);
 		evtchn_unmask(pirq_to_evtchn(d, pirq));
 		spin_unlock(&d->event_lock);
@@ -508,7 +508,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
-    case PHYSDEVOP_pirq_eoi_gmfn: {
+    case PHYSDEVOP_pirq_eoi_gmfn_v1:
+    case PHYSDEVOP_pirq_eoi_gmfn_v2: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
 
@@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         }
 
         current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
+            current->domain->arch.auto_unmask = 1;
         ret = 0;
         break;
     }
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 61d83c8..a540af7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
                 put_page_and_type(
                     mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
                 d->arch.pv_domain.pirq_eoi_map = NULL;
+                d->arch.pv_domain.auto_unmask = 0;
             }
         }
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index f280c28..df92cc7 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -271,7 +271,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             break;
         }
         if ( !is_hvm_domain(v->domain) &&
-             v->domain->arch.pv_domain.pirq_eoi_map )
+             v->domain->arch.pv_domain.auto_unmask )
             evtchn_unmask(pirq->evtchn);
         if ( !is_hvm_domain(v->domain) ||
              domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
@@ -293,7 +293,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
-    case PHYSDEVOP_pirq_eoi_gmfn: {
+    case PHYSDEVOP_pirq_eoi_gmfn_v2:
+    case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
 
@@ -329,6 +330,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             ret = -ENOSPC;
             break;
         }
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
+            v->domain->arch.pv_domain.auto_unmask = 1;
 
         put_gfn(current->domain, info.gmfn);
         ret = 0;
diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
index 12dc3bd..31d7d32 100644
--- a/xen/include/asm-ia64/domain.h
+++ b/xen/include/asm-ia64/domain.h
@@ -186,6 +186,9 @@ struct arch_domain {
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    bool_t auto_unmask;
 
     /* Address of efi_runtime_services_t (placed in domain memory)  */
     void *efi_runtime;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 00bbaeb..fb2cfd2 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -231,6 +231,9 @@ struct pv_domain
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    bool_t auto_unmask;
 
     /* Pseudophysical e820 map (XENMEM_memory_map).  */
     spinlock_t e820_lock;
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index 6e23295..16d800f 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -49,7 +49,15 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
  * will automatically get unmasked. The page registered is used as a bit
  * array indexed by Xen's PIRQ value.
  */
-#define PHYSDEVOP_pirq_eoi_gmfn         17
+#define PHYSDEVOP_pirq_eoi_gmfn_v1       17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v2       28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
     xen_pfn_t gmfn;
@@ -325,6 +333,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
 #define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi
 #define PHYSDEVOP_IRQ_SHARED             XENIRQSTAT_shared
 
+#if __XEN_INTERFACE_VERSION < 0x00040200
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
+#else
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
+#endif
+
 #endif /* __XEN_PUBLIC_PHYSDEV_H__ */
 
 /*
diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 2e38003..d8c55bf 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x0003020a
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.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 Jan 26 18:00:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:00:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTc2-0007AE-8O; Thu, 26 Jan 2012 17:59:54 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqTc0-00079i-19
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 17:59:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327600784!10118764!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTc1NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5788 invoked from network); 26 Jan 2012 17:59:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-13.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 17:59:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,574,1320642000"; d="scan'208";a="21317059"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 12:59:44 -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, 26 Jan 2012 12:59: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 q0QHxZH3009946;
	Thu, 26 Jan 2012 09:59:36 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Thu, 26 Jan 2012 18:00:38 +0000
Message-ID: <1327600839-23469-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.1201261736580.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org,
	Ian.Campbell@citrix.com, JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v2 1/2] xen: introduce PHYSDEVOP_pirq_eoi_gmfn_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

PHYSDEVOP_pirq_eoi_gmfn changes the semantics of PHYSDEVOP_eoi.
In order to improve the interface this patch:

- renames PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1;

- introduces PHYSDEVOP_pirq_eoi_gmfn_v2, that is like
  PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't modify the behaviour of
  another hypercall;

- bump __XEN_LATEST_INTERFACE_VERSION__;

- #define PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1 or
  PHYSDEVOP_pirq_eoi_gmfn_v2 depending on the __XEN_INTERFACE_VERSION.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/xen/domain.c      |    1 +
 xen/arch/ia64/xen/hypercall.c   |    7 +++++--
 xen/arch/x86/domain.c           |    1 +
 xen/arch/x86/physdev.c          |    7 +++++--
 xen/include/asm-ia64/domain.h   |    3 +++
 xen/include/asm-x86/domain.h    |    3 +++
 xen/include/public/physdev.h    |   16 +++++++++++++++-
 xen/include/public/xen-compat.h |    2 +-
 8 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
index 1ea5a90..a31bd32 100644
--- a/xen/arch/ia64/xen/domain.c
+++ b/xen/arch/ia64/xen/domain.c
@@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
 		if (d->arch.pirq_eoi_map != NULL) {
 			put_page(virt_to_page(d->arch.pirq_eoi_map));
 			d->arch.pirq_eoi_map = NULL;
+			d->arch.auto_unmask = 0;
 		}
 
 		/* Tear down shadow mode stuff. */
diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
index 130675e..18930bf 100644
--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
 {
 	if ( pirq < 0 || pirq >= NR_IRQS )
 		return -EINVAL;
-	if ( d->arch.pirq_eoi_map ) {
+	if ( d->arch.auto_unmask ) {
 		spin_lock(&d->event_lock);
 		evtchn_unmask(pirq_to_evtchn(d, pirq));
 		spin_unlock(&d->event_lock);
@@ -508,7 +508,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
-    case PHYSDEVOP_pirq_eoi_gmfn: {
+    case PHYSDEVOP_pirq_eoi_gmfn_v1:
+    case PHYSDEVOP_pirq_eoi_gmfn_v2: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
 
@@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         }
 
         current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
+            current->domain->arch.auto_unmask = 1;
         ret = 0;
         break;
     }
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 61d83c8..a540af7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
                 put_page_and_type(
                     mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
                 d->arch.pv_domain.pirq_eoi_map = NULL;
+                d->arch.pv_domain.auto_unmask = 0;
             }
         }
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index f280c28..df92cc7 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -271,7 +271,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             break;
         }
         if ( !is_hvm_domain(v->domain) &&
-             v->domain->arch.pv_domain.pirq_eoi_map )
+             v->domain->arch.pv_domain.auto_unmask )
             evtchn_unmask(pirq->evtchn);
         if ( !is_hvm_domain(v->domain) ||
              domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
@@ -293,7 +293,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
-    case PHYSDEVOP_pirq_eoi_gmfn: {
+    case PHYSDEVOP_pirq_eoi_gmfn_v2:
+    case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
 
@@ -329,6 +330,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             ret = -ENOSPC;
             break;
         }
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
+            v->domain->arch.pv_domain.auto_unmask = 1;
 
         put_gfn(current->domain, info.gmfn);
         ret = 0;
diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
index 12dc3bd..31d7d32 100644
--- a/xen/include/asm-ia64/domain.h
+++ b/xen/include/asm-ia64/domain.h
@@ -186,6 +186,9 @@ struct arch_domain {
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    bool_t auto_unmask;
 
     /* Address of efi_runtime_services_t (placed in domain memory)  */
     void *efi_runtime;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 00bbaeb..fb2cfd2 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -231,6 +231,9 @@ struct pv_domain
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    bool_t auto_unmask;
 
     /* Pseudophysical e820 map (XENMEM_memory_map).  */
     spinlock_t e820_lock;
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index 6e23295..16d800f 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -49,7 +49,15 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
  * will automatically get unmasked. The page registered is used as a bit
  * array indexed by Xen's PIRQ value.
  */
-#define PHYSDEVOP_pirq_eoi_gmfn         17
+#define PHYSDEVOP_pirq_eoi_gmfn_v1       17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v2       28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
     xen_pfn_t gmfn;
@@ -325,6 +333,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
 #define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi
 #define PHYSDEVOP_IRQ_SHARED             XENIRQSTAT_shared
 
+#if __XEN_INTERFACE_VERSION < 0x00040200
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
+#else
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
+#endif
+
 #endif /* __XEN_PUBLIC_PHYSDEV_H__ */
 
 /*
diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 2e38003..d8c55bf 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x0003020a
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.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 Jan 26 18:22:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:22:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTx3-00084l-MN; Thu, 26 Jan 2012 18:21:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqTx2-00084Q-8f
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 18:21:36 +0000
Received: from [85.158.138.51:63892] by server-3.bemta-3.messagelabs.com id
	E1/ED-26314-FA9912F4; Thu, 26 Jan 2012 18:21:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327602093!10647941!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwODE3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10910 invoked from network); 26 Jan 2012 18:21:34 -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; 26 Jan 2012 18:21:34 -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
	q0QILPF2013417
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Jan 2012 18:21:29 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
	q0QILNY4012517
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Jan 2012 18:21:24 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0QILLNZ003486; Thu, 26 Jan 2012 12:21:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 10:21:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0ADD940157; Thu, 26 Jan 2012 13:19:01 -0500 (EST)
Date: Thu, 26 Jan 2012 13:19:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120126181900.GB25572@phenom.dumpdata.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F2199A9.0159,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: correct MAX_TX_TARGET
	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 05:23:23PM +0000, Wei Liu wrote:

Can you give some more details please? What is the impact of
not having this? Should it be backported to stable?

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netfront.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 38f9c95..01f589d 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -68,7 +68,7 @@ struct netfront_cb {
>  
>  #define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
>  #define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> -#define TX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
>  
>  struct netfront_stats {
>  	u64			rx_packets;
> -- 
> 1.7.8.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 18:22:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:22:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqTx3-00084l-MN; Thu, 26 Jan 2012 18:21:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqTx2-00084Q-8f
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 18:21:36 +0000
Received: from [85.158.138.51:63892] by server-3.bemta-3.messagelabs.com id
	E1/ED-26314-FA9912F4; Thu, 26 Jan 2012 18:21:35 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327602093!10647941!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwODE3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10910 invoked from network); 26 Jan 2012 18:21:34 -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; 26 Jan 2012 18:21:34 -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
	q0QILPF2013417
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Jan 2012 18:21:29 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
	q0QILNY4012517
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Jan 2012 18:21:24 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0QILLNZ003486; Thu, 26 Jan 2012 12:21:21 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 10:21:21 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0ADD940157; Thu, 26 Jan 2012 13:19:01 -0500 (EST)
Date: Thu, 26 Jan 2012 13:19:00 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120126181900.GB25572@phenom.dumpdata.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090209.4F2199A9.0159,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: correct MAX_TX_TARGET
	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 05:23:23PM +0000, Wei Liu wrote:

Can you give some more details please? What is the impact of
not having this? Should it be backported to stable?

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netfront.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 38f9c95..01f589d 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -68,7 +68,7 @@ struct netfront_cb {
>  
>  #define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
>  #define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> -#define TX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> +#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
>  
>  struct netfront_stats {
>  	u64			rx_packets;
> -- 
> 1.7.8.3

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 18:46:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqUL7-0000A2-Sa; Thu, 26 Jan 2012 18:46:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RqUL5-00009x-NC
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 18:46:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327603579!12696604!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16438 invoked from network); 26 Jan 2012 18:46:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 18:46:21 -0000
Received: by pbdx13 with SMTP id x13so6659317pbd.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 10:46: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=g6WZCN8OZsOFiirAJ/1etxTcD5OJVx7meowCYXgV7Ak=;
	b=Kq2kS2K6tZfdOnY15WJ4RfDjG+8oUGwZ3eGj1dIzaX2WAjUZGlWIgJGoO1XJfKeV35
	/Lxh1Ze20bX51eYvRuS7bzyejVN2gvxmpmgh6Or+iH9QchZff7YBk6VARkRvfKCanWEv
	7wQ+VvGZbEm66vcZpLxvPVIki2eMdtnQmvnnM=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr7385941pbc.5.1327603579425; Thu,
	26 Jan 2012 10:46:19 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Thu, 26 Jan 2012 10:46:19 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
References: <patchbomb.1326880685@loki.upc.es>
	<b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
	<alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
Date: Thu, 26 Jan 2012 19:46:19 +0100
X-Google-Sender-Auth: DntAzC4s7bnXo2O7KqdpggTigx8
Message-ID: <CAPLaKK6kCLCPtk8WvT9dLPA298_xGvPqg9GP=_tmsuh54eUeUA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 13 RFC] libxl: destroy devices before
 device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI2IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Ogo+IE9uIFdlZCwgMTggSmFuIDIwMTIsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzI2NzI4NDcyIC0zNjAwCj4+ICMgTm9kZSBJRCBi
NWQ2M2NmOTBkNGVmOGQyMjJhZTI4MmUyNzliOTBiN2Y3M2YxOGMzCj4+ICMgUGFyZW50IMKgNTg0
OWJmN2M0NTA3ZWRiZTkwMGRlMDAzMzJmMTIxOGRlMmQ5ZjQ1Zgo+PiBsaWJ4bDogZGVzdHJveSBk
ZXZpY2VzIGJlZm9yZSBkZXZpY2UgbW9kZWwKPj4KPj4gRGVzdHJveWluZyB0aGUgZGV2aWNlIG1v
ZGVsIGJlZm9yZSB1bnBsdWdnaW5nIHRoZSBkZXZpY2VzIHByZXZlbnRlZAo+PiBmcm9tIGRvaW5n
IGEgY2xlYW4gdW5wbHVnLCBzaW5jZSBsaWJ4bCB3YXMgd2FpdGluZyBmb3IgZG0gwqBkZXZpY2Vz
Cj4+IHRvIHNodXRkb3duIHdoZW4gdGhlIHVzZXJzcGFjZSBwcm9jZXNzIHdhcyBhbHJlYWR5IGtp
bGxlZC4KPgo+IEkgdGhpbmsgdGhhdCB0aGlzIGNoYW5nZSBpcyBjb3JyZWN0IGJ1dCBoYXZlIHlv
dSB0ZXN0ZWQgaXQgd2l0aCBhbnkKPiBiYWNrZW5kcyBydW5uaW5nIGluIHFlbXU/CgpJJ3ZlIHRy
aWVkIHdpdGggcWRpc2sgYW5kIGNvbnNvbGUgYmFja2VuZHMgd2l0aCBhIFBWIERvbVUgKEkgd2ls
bCB0cnkKd2l0aCBhIEhWTSBndWVzdCB0b28sIHRvbW9ycm93IG1vcm5pbmcpLCBhbnl3YXksIHRo
aXMgcGF0Y2ggaXQncyBxdWl0ZQp1c2VsZXNzIG9uIGl0J3Mgb3duLCBpdCdzIHRoZSBjb21iaW5h
dGlvbiBvZiB0aGlzIG9uZSBhbmQ6CgpxZW11OiByZWFjdCB0byBYZW5idXNTdGF0ZUNsb3NpbmcK
CnRoYXQgbWFrZXMgcWVtdSBkZXZpY2UgbW9kZWwgZGVzdHJ1Y3Rpb24gc3VjY2Vzc2Z1bCAoZGV2
aWNlcyBhcmUKZGlzY29ubmVjdGVkIGJlZm9yZSBiYWNrZW5kIHJlbW92YWwpLiBCVFcgWGVuIFFl
bXUgY29kZSBpbiBxZW11LXhlbiBpcwphbiBpbmRlbnRhdGlvbiBtZXNzLCBJJ3ZlIHRyaWVkIHRv
IGtlZXAgaXQgYXMgc2ltaWxhciBhcyBwb3NzaWJsZS4KCj4KPj4gU2lnbmVkLW9mZi1ieTogUm9n
ZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gZGlmZiAtciA1ODQ5
YmY3YzQ1MDcgLXIgYjVkNjNjZjkwZDRlIHRvb2xzL2xpYnhsL2xpYnhsLmMKPj4gLS0tIGEvdG9v
bHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gSmFuIDE2IDE2OjQwOjQwIDIwMTIgKzAxMDAKPj4g
KysrIGIvdG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gSmFuIDE2IDE2OjQxOjEyIDIwMTIg
KzAxMDAKPj4gQEAgLTgwMiwxNSArODAyLDE1IEBAIGludCBsaWJ4bF9kb21haW5fZGVzdHJveShs
aWJ4bF9jdHggKmN0eCwKPj4gwqAgwqAgwqBpZiAocmMgPCAwKSB7Cj4+IMKgIMKgIMKgIMKgIMKg
TElCWExfX0xPR19FUlJOT1ZBTChjdHgsIExJQlhMX19MT0dfRVJST1IsIHJjLCAieGNfZG9tYWlu
X3BhdXNlIGZhaWxlZCBmb3IgJWQiLCBkb21pZCk7Cj4+IMKgIMKgIMKgfQo+PiArIMKgIMKgaWYg
KGxpYnhsX19kZXZpY2VzX2Rlc3Ryb3koZ2MsIGRvbWlkKSA8IDApCj4+ICsgwqAgwqAgwqAgwqBM
SUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCAibGlieGxfX2RldmljZXNfZGVzdHJveSBmYWlsZWQgZm9yICVkIiwgZG9taWQpOwo+
PiDCoCDCoCDCoGlmIChkbV9wcmVzZW50KSB7Cj4+IMKgIMKgIMKgIMKgIMKgaWYgKGxpYnhsX19k
ZXN0cm95X2RldmljZV9tb2RlbChnYywgZG9taWQpIDwgMCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAg
wqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwgImxpYnhsX19kZXN0cm95X2Rldmlj
ZV9tb2RlbCBmYWlsZWQgZm9yICVkIiwgZG9taWQpOwo+Pgo+PiDCoCDCoCDCoCDCoCDCoGxpYnhs
X19xbXBfY2xlYW51cChnYywgZG9taWQpOwo+PiDCoCDCoCDCoH0KPj4gLSDCoCDCoGlmIChsaWJ4
bF9fZGV2aWNlc19kZXN0cm95KGdjLCBkb21pZCkgPCAwKQo+PiAtIMKgIMKgIMKgIMKgTElCWExf
X0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsCj4+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgImxpYnhsX19kZXZpY2VzX2Rlc3Ryb3kgZmFpbGVkIGZvciAlZCIsIGRvbWlkKTsKPj4KPj4g
wqAgwqAgwqB2bV9wYXRoID0gbGlieGxfX3hzX3JlYWQoZ2MsIFhCVF9OVUxMLCBsaWJ4bF9fc3By
aW50ZihnYywgIiVzL3ZtIiwgZG9tX3BhdGgpKTsKPj4gwqAgwqAgwqBpZiAodm1fcGF0aCkKPj4K
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVu
LWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+PiBo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPj4KPgo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlz
dAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Jan 26 18:46:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:46:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqUL7-0000A2-Sa; Thu, 26 Jan 2012 18:46:29 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RqUL5-00009x-NC
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 18:46:27 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327603579!12696604!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16438 invoked from network); 26 Jan 2012 18:46:21 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 18:46:21 -0000
Received: by pbdx13 with SMTP id x13so6659317pbd.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 10:46: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=g6WZCN8OZsOFiirAJ/1etxTcD5OJVx7meowCYXgV7Ak=;
	b=Kq2kS2K6tZfdOnY15WJ4RfDjG+8oUGwZ3eGj1dIzaX2WAjUZGlWIgJGoO1XJfKeV35
	/Lxh1Ze20bX51eYvRuS7bzyejVN2gvxmpmgh6Or+iH9QchZff7YBk6VARkRvfKCanWEv
	7wQ+VvGZbEm66vcZpLxvPVIki2eMdtnQmvnnM=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr7385941pbc.5.1327603579425; Thu,
	26 Jan 2012 10:46:19 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Thu, 26 Jan 2012 10:46:19 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
References: <patchbomb.1326880685@loki.upc.es>
	<b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
	<alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
Date: Thu, 26 Jan 2012 19:46:19 +0100
X-Google-Sender-Auth: DntAzC4s7bnXo2O7KqdpggTigx8
Message-ID: <CAPLaKK6kCLCPtk8WvT9dLPA298_xGvPqg9GP=_tmsuh54eUeUA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 13 RFC] libxl: destroy devices before
 device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI2IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Ogo+IE9uIFdlZCwgMTggSmFuIDIwMTIsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzI2NzI4NDcyIC0zNjAwCj4+ICMgTm9kZSBJRCBi
NWQ2M2NmOTBkNGVmOGQyMjJhZTI4MmUyNzliOTBiN2Y3M2YxOGMzCj4+ICMgUGFyZW50IMKgNTg0
OWJmN2M0NTA3ZWRiZTkwMGRlMDAzMzJmMTIxOGRlMmQ5ZjQ1Zgo+PiBsaWJ4bDogZGVzdHJveSBk
ZXZpY2VzIGJlZm9yZSBkZXZpY2UgbW9kZWwKPj4KPj4gRGVzdHJveWluZyB0aGUgZGV2aWNlIG1v
ZGVsIGJlZm9yZSB1bnBsdWdnaW5nIHRoZSBkZXZpY2VzIHByZXZlbnRlZAo+PiBmcm9tIGRvaW5n
IGEgY2xlYW4gdW5wbHVnLCBzaW5jZSBsaWJ4bCB3YXMgd2FpdGluZyBmb3IgZG0gwqBkZXZpY2Vz
Cj4+IHRvIHNodXRkb3duIHdoZW4gdGhlIHVzZXJzcGFjZSBwcm9jZXNzIHdhcyBhbHJlYWR5IGtp
bGxlZC4KPgo+IEkgdGhpbmsgdGhhdCB0aGlzIGNoYW5nZSBpcyBjb3JyZWN0IGJ1dCBoYXZlIHlv
dSB0ZXN0ZWQgaXQgd2l0aCBhbnkKPiBiYWNrZW5kcyBydW5uaW5nIGluIHFlbXU/CgpJJ3ZlIHRy
aWVkIHdpdGggcWRpc2sgYW5kIGNvbnNvbGUgYmFja2VuZHMgd2l0aCBhIFBWIERvbVUgKEkgd2ls
bCB0cnkKd2l0aCBhIEhWTSBndWVzdCB0b28sIHRvbW9ycm93IG1vcm5pbmcpLCBhbnl3YXksIHRo
aXMgcGF0Y2ggaXQncyBxdWl0ZQp1c2VsZXNzIG9uIGl0J3Mgb3duLCBpdCdzIHRoZSBjb21iaW5h
dGlvbiBvZiB0aGlzIG9uZSBhbmQ6CgpxZW11OiByZWFjdCB0byBYZW5idXNTdGF0ZUNsb3NpbmcK
CnRoYXQgbWFrZXMgcWVtdSBkZXZpY2UgbW9kZWwgZGVzdHJ1Y3Rpb24gc3VjY2Vzc2Z1bCAoZGV2
aWNlcyBhcmUKZGlzY29ubmVjdGVkIGJlZm9yZSBiYWNrZW5kIHJlbW92YWwpLiBCVFcgWGVuIFFl
bXUgY29kZSBpbiBxZW11LXhlbiBpcwphbiBpbmRlbnRhdGlvbiBtZXNzLCBJJ3ZlIHRyaWVkIHRv
IGtlZXAgaXQgYXMgc2ltaWxhciBhcyBwb3NzaWJsZS4KCj4KPj4gU2lnbmVkLW9mZi1ieTogUm9n
ZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gZGlmZiAtciA1ODQ5
YmY3YzQ1MDcgLXIgYjVkNjNjZjkwZDRlIHRvb2xzL2xpYnhsL2xpYnhsLmMKPj4gLS0tIGEvdG9v
bHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gSmFuIDE2IDE2OjQwOjQwIDIwMTIgKzAxMDAKPj4g
KysrIGIvdG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gSmFuIDE2IDE2OjQxOjEyIDIwMTIg
KzAxMDAKPj4gQEAgLTgwMiwxNSArODAyLDE1IEBAIGludCBsaWJ4bF9kb21haW5fZGVzdHJveShs
aWJ4bF9jdHggKmN0eCwKPj4gwqAgwqAgwqBpZiAocmMgPCAwKSB7Cj4+IMKgIMKgIMKgIMKgIMKg
TElCWExfX0xPR19FUlJOT1ZBTChjdHgsIExJQlhMX19MT0dfRVJST1IsIHJjLCAieGNfZG9tYWlu
X3BhdXNlIGZhaWxlZCBmb3IgJWQiLCBkb21pZCk7Cj4+IMKgIMKgIMKgfQo+PiArIMKgIMKgaWYg
KGxpYnhsX19kZXZpY2VzX2Rlc3Ryb3koZ2MsIGRvbWlkKSA8IDApCj4+ICsgwqAgwqAgwqAgwqBM
SUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKPj4gKyDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCDCoCAibGlieGxfX2RldmljZXNfZGVzdHJveSBmYWlsZWQgZm9yICVkIiwgZG9taWQpOwo+
PiDCoCDCoCDCoGlmIChkbV9wcmVzZW50KSB7Cj4+IMKgIMKgIMKgIMKgIMKgaWYgKGxpYnhsX19k
ZXN0cm95X2RldmljZV9tb2RlbChnYywgZG9taWQpIDwgMCkKPj4gwqAgwqAgwqAgwqAgwqAgwqAg
wqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwgImxpYnhsX19kZXN0cm95X2Rldmlj
ZV9tb2RlbCBmYWlsZWQgZm9yICVkIiwgZG9taWQpOwo+Pgo+PiDCoCDCoCDCoCDCoCDCoGxpYnhs
X19xbXBfY2xlYW51cChnYywgZG9taWQpOwo+PiDCoCDCoCDCoH0KPj4gLSDCoCDCoGlmIChsaWJ4
bF9fZGV2aWNlc19kZXN0cm95KGdjLCBkb21pZCkgPCAwKQo+PiAtIMKgIMKgIMKgIMKgTElCWExf
X0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsCj4+IC0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgImxpYnhsX19kZXZpY2VzX2Rlc3Ryb3kgZmFpbGVkIGZvciAlZCIsIGRvbWlkKTsKPj4KPj4g
wqAgwqAgwqB2bV9wYXRoID0gbGlieGxfX3hzX3JlYWQoZ2MsIFhCVF9OVUxMLCBsaWJ4bF9fc3By
aW50ZihnYywgIiVzL3ZtIiwgZG9tX3BhdGgpKTsKPj4gwqAgwqAgwqBpZiAodm1fcGF0aCkKPj4K
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gWGVu
LWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQo+PiBo
dHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPj4KPgo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxpbmcgbGlz
dAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2Uu
Y29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Thu Jan 26 18:51:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqUPg-0000Qh-Pt; Thu, 26 Jan 2012 18:51:12 +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 1RqUPf-0000QQ-7N
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 18:51:11 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327603863!12702372!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4737 invoked from network); 26 Jan 2012 18:51:05 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 18:51:05 -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 q0QImvP8002802
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 26 Jan 2012 10:48:58 -0800
Date: Thu, 26 Jan 2012 13:48:57 -0500 (EST)
Message-Id: <20120126.134857.546484845577613526.davem@davemloft.net>
To: wei.liu2@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.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]);
	Thu, 26 Jan 2012 10:48:59 -0800 (PST)
Cc: netdev@vger.kernel.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: correct MAX_TX_TARGET
	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 26 Jan 2012 17:23:23 +0000

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Pretty obvious and straightforward, applied, thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 18:51:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18:51:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqUPg-0000Qh-Pt; Thu, 26 Jan 2012 18:51:12 +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 1RqUPf-0000QQ-7N
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 18:51:11 +0000
X-Env-Sender: davem@davemloft.net
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327603863!12702372!1
X-Originating-IP: [198.137.202.13]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4737 invoked from network); 26 Jan 2012 18:51:05 -0000
Received: from shards.monkeyblade.net (HELO shards.monkeyblade.net)
	(198.137.202.13)
	by server-15.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 26 Jan 2012 18:51:05 -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 q0QImvP8002802
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 26 Jan 2012 10:48:58 -0800
Date: Thu, 26 Jan 2012 13:48:57 -0500 (EST)
Message-Id: <20120126.134857.546484845577613526.davem@davemloft.net>
To: wei.liu2@citrix.com
From: David Miller <davem@davemloft.net>
In-Reply-To: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.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]);
	Thu, 26 Jan 2012 10:48:59 -0800 (PST)
Cc: netdev@vger.kernel.org, jeremy@goop.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen-netfront: correct MAX_TX_TARGET
	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Wei Liu <wei.liu2@citrix.com>
Date: Thu, 26 Jan 2012 17:23:23 +0000

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Pretty obvious and straightforward, applied, thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 18:54:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18: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 1RqUSv-0000gc-DD; Thu, 26 Jan 2012 18:54: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 1RqUSt-0000dH-UZ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 18:54:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327604064!8856554!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA2NTYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18320 invoked from network); 26 Jan 2012 18:54:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 18:54: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
	q0QIsIhX007014
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Jan 2012 18:54:19 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
	q0QIsH4v001750
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Jan 2012 18:54:17 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
	q0QIsGxZ021014; Thu, 26 Jan 2012 12:54:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 10:54:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 176BE40183; Thu, 26 Jan 2012 13:51:56 -0500 (EST)
Date: Thu, 26 Jan 2012 13:51:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120126185155.GA24768@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
	<1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F21A15C.0038,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> be EOI'd without having to issue an hypercall every time.
> We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/xen/events.c            |   17 ++++++++++++++++-
>  include/xen/interface/physdev.h |   12 ++++++++++++
>  2 files changed, 28 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 6e075cd..7fdc738 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -37,6 +37,7 @@
>  #include <asm/idle.h>
>  #include <asm/io_apic.h>
>  #include <asm/sync_bitops.h>
> +#include <asm/xen/page.h>
>  #include <asm/xen/pci.h>
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/hypervisor.h>
> @@ -108,6 +109,7 @@ struct irq_info {
>  #define PIRQ_SHAREABLE	(1 << 1)
>  
>  static int *evtchn_to_irq;
> +static unsigned long *pirq_eoi_map;
>  
>  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
>  		      cpu_evtchn_mask);
> @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
>  
>  	BUG_ON(info->type != IRQT_PIRQ);
>  
> +	if (pirq_eoi_map != NULL)
> +		return test_bit(irq, pirq_eoi_map);
> +

How about just having a different function called
pirq_needs_eoi_v2 which will just do

 return test_bit(irq, pirq_eoi_map)?

And then set the pirq_needs_eoi_v2 in the function table?


>  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
>  }
>  
> @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
>  
>  void __init xen_init_IRQ(void)
>  {
> -	int i;
> +	int i, rc;
>  
>  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
>  				    GFP_KERNEL);
> @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
>  		 * __acpi_register_gsi can point at the right function */
>  		pci_xen_hvm_init();
>  	} else {
> +		struct physdev_pirq_eoi_gmfn eoi_gmfn;
> +
>  		irq_ctx_init(smp_processor_id());
>  		if (xen_initial_domain())
>  			pci_xen_initial_domain();
> +
> +		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> +		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> +		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);


Don't we want the v2 version?

> +		if (rc != 0) {
> +			free_page((unsigned long) pirq_eoi_map);
> +			pirq_eoi_map = NULL;
> +		}
>  	}
>  }
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index c1080d9..132c61f 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -39,6 +39,18 @@ struct physdev_eoi {
>  };
>  
>  /*
> + * Register a shared page for the hypervisor to indicate whether the
> + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> + * array indexed by Xen's PIRQ value.
> + */
> +#define PHYSDEVOP_pirq_eoi_gmfn      28

Ah, the number is right, but the name is the generic one.

We should really mention that this is different from v1 or just

#define PHYSDEVOP_pirq_eoi_gmfn_v2 28
and use that in the code?

> +struct physdev_pirq_eoi_gmfn {
> +    /* IN */
> +    unsigned long gmfn;
> +};
> +
> +
> +/*
>   * Query the status of an IRQ line.
>   * @arg == pointer to physdev_irq_status_query structure.
>   */
> -- 
> 1.7.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 Jan 26 18:54:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 18: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 1RqUSv-0000gc-DD; Thu, 26 Jan 2012 18:54: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 1RqUSt-0000dH-UZ
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 18:54:32 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327604064!8856554!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA2NTYz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18320 invoked from network); 26 Jan 2012 18:54:25 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 18:54: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
	q0QIsIhX007014
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Jan 2012 18:54:19 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
	q0QIsH4v001750
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Jan 2012 18:54:17 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
	q0QIsGxZ021014; Thu, 26 Jan 2012 12:54:16 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 10:54:16 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 176BE40183; Thu, 26 Jan 2012 13:51:56 -0500 (EST)
Date: Thu, 26 Jan 2012 13:51:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120126185155.GA24768@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
	<1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090202.4F21A15C.0038,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, keir@xen.org, Ian.Campbell@citrix.com,
	JBeulich@suse.com
Subject: Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> be EOI'd without having to issue an hypercall every time.
> We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/xen/events.c            |   17 ++++++++++++++++-
>  include/xen/interface/physdev.h |   12 ++++++++++++
>  2 files changed, 28 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> index 6e075cd..7fdc738 100644
> --- a/drivers/xen/events.c
> +++ b/drivers/xen/events.c
> @@ -37,6 +37,7 @@
>  #include <asm/idle.h>
>  #include <asm/io_apic.h>
>  #include <asm/sync_bitops.h>
> +#include <asm/xen/page.h>
>  #include <asm/xen/pci.h>
>  #include <asm/xen/hypercall.h>
>  #include <asm/xen/hypervisor.h>
> @@ -108,6 +109,7 @@ struct irq_info {
>  #define PIRQ_SHAREABLE	(1 << 1)
>  
>  static int *evtchn_to_irq;
> +static unsigned long *pirq_eoi_map;
>  
>  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
>  		      cpu_evtchn_mask);
> @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
>  
>  	BUG_ON(info->type != IRQT_PIRQ);
>  
> +	if (pirq_eoi_map != NULL)
> +		return test_bit(irq, pirq_eoi_map);
> +

How about just having a different function called
pirq_needs_eoi_v2 which will just do

 return test_bit(irq, pirq_eoi_map)?

And then set the pirq_needs_eoi_v2 in the function table?


>  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
>  }
>  
> @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
>  
>  void __init xen_init_IRQ(void)
>  {
> -	int i;
> +	int i, rc;
>  
>  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
>  				    GFP_KERNEL);
> @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
>  		 * __acpi_register_gsi can point at the right function */
>  		pci_xen_hvm_init();
>  	} else {
> +		struct physdev_pirq_eoi_gmfn eoi_gmfn;
> +
>  		irq_ctx_init(smp_processor_id());
>  		if (xen_initial_domain())
>  			pci_xen_initial_domain();
> +
> +		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> +		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> +		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);


Don't we want the v2 version?

> +		if (rc != 0) {
> +			free_page((unsigned long) pirq_eoi_map);
> +			pirq_eoi_map = NULL;
> +		}
>  	}
>  }
> diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> index c1080d9..132c61f 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -39,6 +39,18 @@ struct physdev_eoi {
>  };
>  
>  /*
> + * Register a shared page for the hypervisor to indicate whether the
> + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> + * array indexed by Xen's PIRQ value.
> + */
> +#define PHYSDEVOP_pirq_eoi_gmfn      28

Ah, the number is right, but the name is the generic one.

We should really mention that this is different from v1 or just

#define PHYSDEVOP_pirq_eoi_gmfn_v2 28
and use that in the code?

> +struct physdev_pirq_eoi_gmfn {
> +    /* IN */
> +    unsigned long gmfn;
> +};
> +
> +
> +/*
>   * Query the status of an IRQ line.
>   * @arg == pointer to physdev_irq_status_query structure.
>   */
> -- 
> 1.7.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 Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGX-0002Im-VG; Thu, 26 Jan 2012 19:45:49 +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 1RqVGV-0002DG-RW
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327607140!12701927!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22634 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjdQG026842
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHk005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:51 -0500
Message-Id: <1327607111-15394-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/24] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 8001a91..904fb45 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -264,6 +264,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index acf9c8a..d99f886 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGX-0002Im-VG; Thu, 26 Jan 2012 19:45:49 +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 1RqVGV-0002DG-RW
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327607140!12701927!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22634 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjdQG026842
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHk005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:51 -0500
Message-Id: <1327607111-15394-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/24] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 8001a91..904fb45 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -264,6 +264,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index acf9c8a..d99f886 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGU-0002FB-IO; Thu, 26 Jan 2012 19:45:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DY-Sh
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
Received: from [85.158.138.51:10213] by server-9.bemta-3.messagelabs.com id
	97/47-31168-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327607141!10820897!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28420 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeQG026866
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI6005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:11 -0500
Message-Id: <1327607111-15394-25-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 24/24] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   44 ++++++++++++++
 tools/xenstore/Makefile                  |    9 ++-
 tools/xenstore/init-xenstore-domain.c    |   94 ++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..bbee8c6
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,44 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index be892fd..2fce994 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
@@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..f6c31d0
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,94 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+	if (rv < 0) return rv;
+	snprintf(cmdline, 512, "--event %d", rv);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGW-0002GG-19; Thu, 26 Jan 2012 19:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DZ-VF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
Received: from [85.158.138.51:9146] by server-5.bemta-3.messagelabs.com id
	F3/D3-02363-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327607140!10770039!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24587 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeLe009010
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHs005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:59 -0500
Message-Id: <1327607111-15394-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 12/24] mini-os: make frontends and xenbus
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds compile-time logic to disable certain frontends in mini-os:
 - pcifront is disabled by default, enabled for ioemu
 - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default
 - xenbus is required for any frontend, and is enabled by default

If all frontends and xenbus are disabled, mini-os will run without
needing to communicate with xenstore, making it suitable to run the
xenstore daemon. The console frontend is not required for the initial
console, only consoles opened via openpt or ptmx.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile               |   32 ++++-
 extras/mini-os/console/console.c      |    5 -
 extras/mini-os/console/console.h      |    2 +
 extras/mini-os/console/xenbus.c       |  197 +++++++++++++++++++++++++++++++++
 extras/mini-os/console/xencons_ring.c |  182 +------------------------------
 extras/mini-os/include/lib.h          |    2 +
 extras/mini-os/include/xenbus.h       |   12 ++
 extras/mini-os/kernel.c               |    4 -
 extras/mini-os/lib/sys.c              |   43 +++++++
 extras/mini-os/main.c                 |    6 +-
 stubdom/ioemu-minios.cfg              |    1 +
 11 files changed, 289 insertions(+), 197 deletions(-)
 create mode 100644 extras/mini-os/console/console.h
 create mode 100644 extras/mini-os/console/xenbus.c

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index 96c661a..ea5d0b5 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -19,11 +19,25 @@ endif
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
+CONFIG_PCIFRONT ?= n
+CONFIG_BLKFRONT ?= y
+CONFIG_NETFRONT ?= y
+CONFIG_FBFRONT ?= y
+CONFIG_KBDFRONT ?= y
+CONFIG_CONSFRONT ?= y
+CONFIG_XENBUS ?= y
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
+flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
+flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
+flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
+flags-$(CONFIG_CONSFRONT) += -DCONFIG_CONSFRONT
+flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 
 DEF_CFLAGS += $(flags-y)
 
@@ -49,10 +63,10 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
-src-y += blkfront.c
+src-$(CONFIG_BLKFRONT) += blkfront.c
 src-y += daytime.c
 src-y += events.c
-src-y += fbfront.c
+src-$(CONFIG_FBFRONT) += fbfront.c
 src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
@@ -60,8 +74,8 @@ src-y += kernel.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
-src-y += netfront.c
-src-y += pcifront.c
+src-$(CONFIG_NETFRONT) += netfront.c
+src-$(CONFIG_PCIFRONT) += pcifront.c
 src-y += sched.c
 src-$(CONFIG_TEST) += test.c
 
@@ -72,12 +86,13 @@ src-y += lib/stack_chk_fail.c
 src-y += lib/string.c
 src-y += lib/sys.c
 src-y += lib/xmalloc.c
-src-y += lib/xs.c
+src-$(CONFIG_XENBUS) += lib/xs.c
 
-src-y += xenbus/xenbus.c
+src-$(CONFIG_XENBUS) += xenbus/xenbus.c
 
 src-y += console/console.c
 src-y += console/xencons_ring.c
+src-$(CONFIG_CONSFRONT) += console/xenbus.c
 
 # The common mini-os objects to build.
 APP_OBJS :=
@@ -108,7 +123,10 @@ ifeq ($(lwip),y)
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
 LWO	:= $(patsubst %.c,%.o,$(LWC))
-LWO	+= $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
+LWO	+= $(OBJ_DIR)/lwip-arch.o
+ifeq ($(CONFIG_NETFRONT),y)
+LWO += $(OBJ_DIR)/lwip-net.o
+endif
 
 $(OBJ_DIR)/lwip.a: $(LWO)
 	$(RM) $@
diff --git a/extras/mini-os/console/console.c b/extras/mini-os/console/console.c
index 2b4ed9f..fec3791 100644
--- a/extras/mini-os/console/console.c
+++ b/extras/mini-os/console/console.c
@@ -158,8 +158,3 @@ void init_console(void)
     /* This is also required to notify the daemon */
     printk("done.\n");
 }
-
-void fini_console(struct consfront_dev *dev)
-{
-    if (dev) free_consfront(dev);
-}
diff --git a/extras/mini-os/console/console.h b/extras/mini-os/console/console.h
new file mode 100644
index 0000000..e85147a
--- /dev/null
+++ b/extras/mini-os/console/console.h
@@ -0,0 +1,2 @@
+
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data);
diff --git a/extras/mini-os/console/xenbus.c b/extras/mini-os/console/xenbus.c
new file mode 100644
index 0000000..a7c517d
--- /dev/null
+++ b/extras/mini-os/console/xenbus.c
@@ -0,0 +1,197 @@
+#include <mini-os/types.h>
+#include <mini-os/wait.h>
+#include <mini-os/mm.h>
+#include <mini-os/hypervisor.h>
+#include <mini-os/events.h>
+#include <mini-os/os.h>
+#include <mini-os/lib.h>
+#include <mini-os/xenbus.h>
+#include <xen/io/console.h>
+#include <xen/io/protocols.h>
+#include <xen/io/ring.h>
+#include <mini-os/xmalloc.h>
+#include <mini-os/gnttab.h>
+#include "console.h"
+
+void free_consfront(struct consfront_dev *dev)
+{
+    char* err = NULL;
+    XenbusState state;
+
+    char path[strlen(dev->backend) + 1 + 5 + 1];
+    char nodename[strlen(dev->nodename) + 1 + 5 + 1];
+
+    snprintf(path, sizeof(path), "%s/state", dev->backend);
+    snprintf(nodename, sizeof(nodename), "%s/state", dev->nodename);
+
+    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosing)) != NULL) {
+        printk("free_consfront: error changing state to %d: %s\n",
+                XenbusStateClosing, err);
+        goto close;
+    }
+    state = xenbus_read_integer(path);
+    while (err == NULL && state < XenbusStateClosing)
+        err = xenbus_wait_for_state_change(path, &state, &dev->events);
+    if (err) free(err);
+
+    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosed)) != NULL) {
+        printk("free_consfront: error changing state to %d: %s\n",
+                XenbusStateClosed, err);
+        goto close;
+    }
+
+close:
+    if (err) free(err);
+    xenbus_unwatch_path_token(XBT_NIL, path, path);
+
+    mask_evtchn(dev->evtchn);
+    unbind_evtchn(dev->evtchn);
+    free(dev->backend);
+    free(dev->nodename);
+
+    gnttab_end_access(dev->ring_ref);
+
+    free_page(dev->ring);
+    free(dev);
+}
+
+struct consfront_dev *init_consfront(char *_nodename)
+{
+    xenbus_transaction_t xbt;
+    char* err;
+    char* message=NULL;
+    int retry=0;
+    char* msg = NULL;
+    char nodename[256];
+    char path[256];
+    static int consfrontends = 3;
+    struct consfront_dev *dev;
+    int res;
+
+    if (!_nodename)
+        snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
+    else
+        strncpy(nodename, _nodename, sizeof(nodename));
+
+    printk("******************* CONSFRONT for %s **********\n\n\n", nodename);
+
+    consfrontends++;
+    dev = malloc(sizeof(*dev));
+    memset(dev, 0, sizeof(*dev));
+    dev->nodename = strdup(nodename);
+#ifdef HAVE_LIBC
+    dev->fd = -1;
+#endif
+
+    snprintf(path, sizeof(path), "%s/backend-id", nodename);
+    if ((res = xenbus_read_integer(path)) < 0) 
+        return NULL;
+    else
+        dev->dom = res;
+    evtchn_alloc_unbound(dev->dom, console_handle_input, dev, &dev->evtchn);
+
+    dev->ring = (struct xencons_interface *) alloc_page();
+    memset(dev->ring, 0, PAGE_SIZE);
+    dev->ring_ref = gnttab_grant_access(dev->dom, virt_to_mfn(dev->ring), 0);
+
+    dev->events = NULL;
+
+again:
+    err = xenbus_transaction_start(&xbt);
+    if (err) {
+        printk("starting transaction\n");
+        free(err);
+    }
+
+    err = xenbus_printf(xbt, nodename, "ring-ref","%u",
+                dev->ring_ref);
+    if (err) {
+        message = "writing ring-ref";
+        goto abort_transaction;
+    }
+    err = xenbus_printf(xbt, nodename,
+                "port", "%u", dev->evtchn);
+    if (err) {
+        message = "writing event-channel";
+        goto abort_transaction;
+    }
+    err = xenbus_printf(xbt, nodename,
+                "protocol", "%s", XEN_IO_PROTO_ABI_NATIVE);
+    if (err) {
+        message = "writing protocol";
+        goto abort_transaction;
+    }
+
+    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
+    if (err) {
+        message = "writing type";
+        goto abort_transaction;
+    }
+
+    snprintf(path, sizeof(path), "%s/state", nodename);
+    err = xenbus_switch_state(xbt, path, XenbusStateConnected);
+    if (err) {
+        message = "switching state";
+        goto abort_transaction;
+    }
+
+
+    err = xenbus_transaction_end(xbt, 0, &retry);
+    if (err) free(err);
+    if (retry) {
+            goto again;
+        printk("completing transaction\n");
+    }
+
+    goto done;
+
+abort_transaction:
+    free(err);
+    err = xenbus_transaction_end(xbt, 1, &retry);
+    goto error;
+
+done:
+
+    snprintf(path, sizeof(path), "%s/backend", nodename);
+    msg = xenbus_read(XBT_NIL, path, &dev->backend);
+    if (msg) {
+        printk("Error %s when reading the backend path %s\n", msg, path);
+        goto error;
+    }
+
+    printk("backend at %s\n", dev->backend);
+
+    {
+        XenbusState state;
+        char path[strlen(dev->backend) + 1 + 19 + 1];
+        snprintf(path, sizeof(path), "%s/state", dev->backend);
+        
+	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
+        msg = NULL;
+        state = xenbus_read_integer(path);
+        while (msg == NULL && state < XenbusStateConnected)
+            msg = xenbus_wait_for_state_change(path, &state, &dev->events);
+        if (msg != NULL || state != XenbusStateConnected) {
+            printk("backend not available, state=%d\n", state);
+            xenbus_unwatch_path_token(XBT_NIL, path, path);
+            goto error;
+        }
+    }
+    unmask_evtchn(dev->evtchn);
+
+    printk("**************************\n");
+
+    return dev;
+
+error:
+    free(msg);
+    free(err);
+    free_consfront(dev);
+    return NULL;
+}
+
+void fini_console(struct consfront_dev *dev)
+{
+    if (dev) free_consfront(dev);
+}
+
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index af0afed..81c8e99 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -11,6 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
+#include "console.h"
 
 DECLARE_WAIT_QUEUE_HEAD(console_queue);
 
@@ -70,7 +71,7 @@ int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
 
 
 
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
 	struct consfront_dev *dev = (struct consfront_dev *) data;
 #ifdef HAVE_LIBC
@@ -173,7 +174,7 @@ struct consfront_dev *xencons_ring_init(void)
 	dev->evtchn = start_info.console.domU.evtchn;
 	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
 
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
+	err = bind_evtchn(dev->evtchn, console_handle_input, dev);
 	if (err <= 0) {
 		printk("XEN console request chn bind failed %i\n", err);
                 free(dev);
@@ -187,183 +188,6 @@ struct consfront_dev *xencons_ring_init(void)
 	return dev;
 }
 
-void free_consfront(struct consfront_dev *dev)
-{
-    char* err = NULL;
-    XenbusState state;
-
-    char path[strlen(dev->backend) + 1 + 5 + 1];
-    char nodename[strlen(dev->nodename) + 1 + 5 + 1];
-
-    snprintf(path, sizeof(path), "%s/state", dev->backend);
-    snprintf(nodename, sizeof(nodename), "%s/state", dev->nodename);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosing)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosing, err);
-        goto close;
-    }
-    state = xenbus_read_integer(path);
-    while (err == NULL && state < XenbusStateClosing)
-        err = xenbus_wait_for_state_change(path, &state, &dev->events);
-    if (err) free(err);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosed)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosed, err);
-        goto close;
-    }
-
-close:
-    if (err) free(err);
-    xenbus_unwatch_path_token(XBT_NIL, path, path);
-
-    mask_evtchn(dev->evtchn);
-    unbind_evtchn(dev->evtchn);
-    free(dev->backend);
-    free(dev->nodename);
-
-    gnttab_end_access(dev->ring_ref);
-
-    free_page(dev->ring);
-    free(dev);
-}
-
-struct consfront_dev *init_consfront(char *_nodename)
-{
-    xenbus_transaction_t xbt;
-    char* err;
-    char* message=NULL;
-    int retry=0;
-    char* msg = NULL;
-    char nodename[256];
-    char path[256];
-    static int consfrontends = 3;
-    struct consfront_dev *dev;
-    int res;
-
-    if (!_nodename)
-        snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
-    else
-        strncpy(nodename, _nodename, sizeof(nodename));
-
-    printk("******************* CONSFRONT for %s **********\n\n\n", nodename);
-
-    consfrontends++;
-    dev = malloc(sizeof(*dev));
-    memset(dev, 0, sizeof(*dev));
-    dev->nodename = strdup(nodename);
-#ifdef HAVE_LIBC
-    dev->fd = -1;
-#endif
-
-    snprintf(path, sizeof(path), "%s/backend-id", nodename);
-    if ((res = xenbus_read_integer(path)) < 0) 
-        return NULL;
-    else
-        dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
-
-    dev->ring = (struct xencons_interface *) alloc_page();
-    memset(dev->ring, 0, PAGE_SIZE);
-    dev->ring_ref = gnttab_grant_access(dev->dom, virt_to_mfn(dev->ring), 0);
-
-    dev->events = NULL;
-
-again:
-    err = xenbus_transaction_start(&xbt);
-    if (err) {
-        printk("starting transaction\n");
-        free(err);
-    }
-
-    err = xenbus_printf(xbt, nodename, "ring-ref","%u",
-                dev->ring_ref);
-    if (err) {
-        message = "writing ring-ref";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "port", "%u", dev->evtchn);
-    if (err) {
-        message = "writing event-channel";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "protocol", "%s", XEN_IO_PROTO_ABI_NATIVE);
-    if (err) {
-        message = "writing protocol";
-        goto abort_transaction;
-    }
-
-    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
-    if (err) {
-        message = "writing type";
-        goto abort_transaction;
-    }
-
-    snprintf(path, sizeof(path), "%s/state", nodename);
-    err = xenbus_switch_state(xbt, path, XenbusStateConnected);
-    if (err) {
-        message = "switching state";
-        goto abort_transaction;
-    }
-
-
-    err = xenbus_transaction_end(xbt, 0, &retry);
-    if (err) free(err);
-    if (retry) {
-            goto again;
-        printk("completing transaction\n");
-    }
-
-    goto done;
-
-abort_transaction:
-    free(err);
-    err = xenbus_transaction_end(xbt, 1, &retry);
-    goto error;
-
-done:
-
-    snprintf(path, sizeof(path), "%s/backend", nodename);
-    msg = xenbus_read(XBT_NIL, path, &dev->backend);
-    if (msg) {
-        printk("Error %s when reading the backend path %s\n", msg, path);
-        goto error;
-    }
-
-    printk("backend at %s\n", dev->backend);
-
-    {
-        XenbusState state;
-        char path[strlen(dev->backend) + 1 + 19 + 1];
-        snprintf(path, sizeof(path), "%s/state", dev->backend);
-        
-	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
-        msg = NULL;
-        state = xenbus_read_integer(path);
-        while (msg == NULL && state < XenbusStateConnected)
-            msg = xenbus_wait_for_state_change(path, &state, &dev->events);
-        if (msg != NULL || state != XenbusStateConnected) {
-            printk("backend not available, state=%d\n", state);
-            xenbus_unwatch_path_token(XBT_NIL, path, path);
-            goto error;
-        }
-    }
-    unmask_evtchn(dev->evtchn);
-
-    printk("**************************\n");
-
-    return dev;
-
-error:
-    free(msg);
-    free(err);
-    free_consfront(dev);
-    return NULL;
-}
-
 void xencons_resume(void)
 {
 	(void)xencons_ring_init();
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 12070c3..9c69440 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -182,11 +182,13 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
              * FD.  */
             xenbus_event_queue events;
         } xenbus;
+#endif
     };
     int read;	/* maybe available for read */
 } files[];
diff --git a/extras/mini-os/include/xenbus.h b/extras/mini-os/include/xenbus.h
index de618fc..cd6316e 100644
--- a/extras/mini-os/include/xenbus.h
+++ b/extras/mini-os/include/xenbus.h
@@ -6,8 +6,14 @@
 typedef unsigned long xenbus_transaction_t;
 #define XBT_NIL ((xenbus_transaction_t)0)
 
+#ifdef CONFIG_XENBUS
 /* Initialize the XenBus system. */
 void init_xenbus(void);
+#else
+static inline void init_xenbus(void)
+{
+}
+#endif
 
 /* Read the value associated with a path.  Returns a malloc'd error
    string on failure and sets *value to NULL.  On success, *value is
@@ -98,7 +104,13 @@ char* xenbus_printf(xenbus_transaction_t xbt,
 /* Utility function to figure out our domain id */
 domid_t xenbus_get_self_id(void);
 
+#ifdef CONFIG_XENBUS
 /* Reset the XenBus system. */
 void fini_xenbus(void);
+#else
+static inline void fini_xenbus(void)
+{
+}
+#endif
 
 #endif /* XENBUS_H__ */
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index c8b9b8c..a8dfe6d 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -142,10 +142,6 @@ void stop_kernel(void)
     /* Reset grant tables */
     fini_gnttab();
 
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
     /* Reset XenBus */
     fini_xenbus();
 
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index b7b3aff..dcdf096 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -164,6 +164,7 @@ int mkdir(const char *pathname, mode_t mode)
     return -1;
 }
 
+#ifdef CONFIG_CONSFRONT
 int posix_openpt(int flags)
 {
     struct consfront_dev *dev;
@@ -192,6 +193,18 @@ int open_savefile(const char *path, int save)
     printk("fd(%d) = open_savefile\n", dev->fd);
     return(dev->fd);
 }
+#else
+int posix_openpt(int flags)
+{
+	errno = EIO;
+	return -1;
+}
+int open_savefile(const char *path, int save)
+{
+	errno = EIO;
+	return -1;
+}
+#endif
 
 int open(const char *pathname, int flags, ...)
 {
@@ -241,6 +254,7 @@ int read(int fd, void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_read(files[fd].socket.fd, buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP: {
 	    ssize_t ret;
 	    ret = netfront_receive(files[fd].tap.dev, buf, nbytes);
@@ -250,6 +264,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret;
 	}
+#endif
+#ifdef CONFIG_KBDFRONT
         case FTYPE_KBD: {
             int ret, n;
             n = nbytes / sizeof(union xenkbd_in_event);
@@ -260,6 +276,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenkbd_in_event);
         }
+#endif
+#ifdef CONFIG_FBFRONT
         case FTYPE_FB: {
             int ret, n;
             n = nbytes / sizeof(union xenfb_in_event);
@@ -270,6 +288,7 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenfb_in_event);
         }
+#endif
 	default:
 	    break;
     }
@@ -297,9 +316,11 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_write(files[fd].socket.fd, (void*) buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
+#endif
 	default:
 	    break;
     }
@@ -326,9 +347,11 @@ int close(int fd)
         default:
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
             xs_daemon_close((void*)(intptr_t) fd);
             return 0;
+#endif
 #ifdef HAVE_LWIP
 	case FTYPE_SOCKET: {
 	    int res = lwip_close(files[fd].socket.fd);
@@ -345,27 +368,37 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_BLKFRONT
 	case FTYPE_BLK:
             shutdown_blkfront(files[fd].blk.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_FBFRONT
 	case FTYPE_FB:
             shutdown_fbfront(files[fd].fb.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_CONSFRONT
         case FTYPE_SAVEFILE:
         case FTYPE_CONSOLE:
             fini_console(files[fd].cons.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
 	case FTYPE_NONE:
 	    break;
     }
@@ -611,6 +644,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
                 n++;
 	    FD_CLR(i, exceptfds);
 	    break;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
 	    if (FD_ISSET(i, readfds)) {
                 if (files[i].xenbus.events)
@@ -621,6 +655,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
 	    FD_CLR(i, writefds);
 	    FD_CLR(i, exceptfds);
 	    break;
+#endif
 	case FTYPE_EVTCHN:
 	case FTYPE_TAP:
 	case FTYPE_BLK:
@@ -727,11 +762,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
+#ifdef CONFIG_NETFRONT
     add_waiter(w1, netfront_queue);
+#endif
     add_waiter(w2, event_queue);
+#ifdef CONFIG_BLKFRONT
     add_waiter(w3, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     add_waiter(w4, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     add_waiter(w5, kbdfront_queue);
+#endif
     add_waiter(w6, console_queue);
 
     if (readfds)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index aeda548..73eb6fb 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -63,10 +63,12 @@ static void call_main(void *p)
 #ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #endif
-#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK) && defined(CONFIG_NETFRONT)
     start_networking();
 #endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
@@ -169,7 +171,7 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
-#ifdef HAVE_LWIP
+#if defined(HAVE_LWIP) && defined(CONFIG_NETFRONT)
     stop_networking();
 #endif
     stop_kernel();
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
index 7ea1d2f..e3a96da 100644
--- a/stubdom/ioemu-minios.cfg
+++ b/stubdom/ioemu-minios.cfg
@@ -1 +1,2 @@
 CONFIG_QEMU_XS_ARGS=y
+CONFIG_PCIFRONT=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGW-0002GG-19; Thu, 26 Jan 2012 19:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DZ-VF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
Received: from [85.158.138.51:9146] by server-5.bemta-3.messagelabs.com id
	F3/D3-02363-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327607140!10770039!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24587 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeLe009010
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHs005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:59 -0500
Message-Id: <1327607111-15394-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 12/24] mini-os: make frontends and xenbus
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds compile-time logic to disable certain frontends in mini-os:
 - pcifront is disabled by default, enabled for ioemu
 - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default
 - xenbus is required for any frontend, and is enabled by default

If all frontends and xenbus are disabled, mini-os will run without
needing to communicate with xenstore, making it suitable to run the
xenstore daemon. The console frontend is not required for the initial
console, only consoles opened via openpt or ptmx.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile               |   32 ++++-
 extras/mini-os/console/console.c      |    5 -
 extras/mini-os/console/console.h      |    2 +
 extras/mini-os/console/xenbus.c       |  197 +++++++++++++++++++++++++++++++++
 extras/mini-os/console/xencons_ring.c |  182 +------------------------------
 extras/mini-os/include/lib.h          |    2 +
 extras/mini-os/include/xenbus.h       |   12 ++
 extras/mini-os/kernel.c               |    4 -
 extras/mini-os/lib/sys.c              |   43 +++++++
 extras/mini-os/main.c                 |    6 +-
 stubdom/ioemu-minios.cfg              |    1 +
 11 files changed, 289 insertions(+), 197 deletions(-)
 create mode 100644 extras/mini-os/console/console.h
 create mode 100644 extras/mini-os/console/xenbus.c

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index 96c661a..ea5d0b5 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -19,11 +19,25 @@ endif
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
+CONFIG_PCIFRONT ?= n
+CONFIG_BLKFRONT ?= y
+CONFIG_NETFRONT ?= y
+CONFIG_FBFRONT ?= y
+CONFIG_KBDFRONT ?= y
+CONFIG_CONSFRONT ?= y
+CONFIG_XENBUS ?= y
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
+flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
+flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
+flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
+flags-$(CONFIG_CONSFRONT) += -DCONFIG_CONSFRONT
+flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 
 DEF_CFLAGS += $(flags-y)
 
@@ -49,10 +63,10 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
-src-y += blkfront.c
+src-$(CONFIG_BLKFRONT) += blkfront.c
 src-y += daytime.c
 src-y += events.c
-src-y += fbfront.c
+src-$(CONFIG_FBFRONT) += fbfront.c
 src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
@@ -60,8 +74,8 @@ src-y += kernel.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
-src-y += netfront.c
-src-y += pcifront.c
+src-$(CONFIG_NETFRONT) += netfront.c
+src-$(CONFIG_PCIFRONT) += pcifront.c
 src-y += sched.c
 src-$(CONFIG_TEST) += test.c
 
@@ -72,12 +86,13 @@ src-y += lib/stack_chk_fail.c
 src-y += lib/string.c
 src-y += lib/sys.c
 src-y += lib/xmalloc.c
-src-y += lib/xs.c
+src-$(CONFIG_XENBUS) += lib/xs.c
 
-src-y += xenbus/xenbus.c
+src-$(CONFIG_XENBUS) += xenbus/xenbus.c
 
 src-y += console/console.c
 src-y += console/xencons_ring.c
+src-$(CONFIG_CONSFRONT) += console/xenbus.c
 
 # The common mini-os objects to build.
 APP_OBJS :=
@@ -108,7 +123,10 @@ ifeq ($(lwip),y)
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
 LWO	:= $(patsubst %.c,%.o,$(LWC))
-LWO	+= $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
+LWO	+= $(OBJ_DIR)/lwip-arch.o
+ifeq ($(CONFIG_NETFRONT),y)
+LWO += $(OBJ_DIR)/lwip-net.o
+endif
 
 $(OBJ_DIR)/lwip.a: $(LWO)
 	$(RM) $@
diff --git a/extras/mini-os/console/console.c b/extras/mini-os/console/console.c
index 2b4ed9f..fec3791 100644
--- a/extras/mini-os/console/console.c
+++ b/extras/mini-os/console/console.c
@@ -158,8 +158,3 @@ void init_console(void)
     /* This is also required to notify the daemon */
     printk("done.\n");
 }
-
-void fini_console(struct consfront_dev *dev)
-{
-    if (dev) free_consfront(dev);
-}
diff --git a/extras/mini-os/console/console.h b/extras/mini-os/console/console.h
new file mode 100644
index 0000000..e85147a
--- /dev/null
+++ b/extras/mini-os/console/console.h
@@ -0,0 +1,2 @@
+
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data);
diff --git a/extras/mini-os/console/xenbus.c b/extras/mini-os/console/xenbus.c
new file mode 100644
index 0000000..a7c517d
--- /dev/null
+++ b/extras/mini-os/console/xenbus.c
@@ -0,0 +1,197 @@
+#include <mini-os/types.h>
+#include <mini-os/wait.h>
+#include <mini-os/mm.h>
+#include <mini-os/hypervisor.h>
+#include <mini-os/events.h>
+#include <mini-os/os.h>
+#include <mini-os/lib.h>
+#include <mini-os/xenbus.h>
+#include <xen/io/console.h>
+#include <xen/io/protocols.h>
+#include <xen/io/ring.h>
+#include <mini-os/xmalloc.h>
+#include <mini-os/gnttab.h>
+#include "console.h"
+
+void free_consfront(struct consfront_dev *dev)
+{
+    char* err = NULL;
+    XenbusState state;
+
+    char path[strlen(dev->backend) + 1 + 5 + 1];
+    char nodename[strlen(dev->nodename) + 1 + 5 + 1];
+
+    snprintf(path, sizeof(path), "%s/state", dev->backend);
+    snprintf(nodename, sizeof(nodename), "%s/state", dev->nodename);
+
+    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosing)) != NULL) {
+        printk("free_consfront: error changing state to %d: %s\n",
+                XenbusStateClosing, err);
+        goto close;
+    }
+    state = xenbus_read_integer(path);
+    while (err == NULL && state < XenbusStateClosing)
+        err = xenbus_wait_for_state_change(path, &state, &dev->events);
+    if (err) free(err);
+
+    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosed)) != NULL) {
+        printk("free_consfront: error changing state to %d: %s\n",
+                XenbusStateClosed, err);
+        goto close;
+    }
+
+close:
+    if (err) free(err);
+    xenbus_unwatch_path_token(XBT_NIL, path, path);
+
+    mask_evtchn(dev->evtchn);
+    unbind_evtchn(dev->evtchn);
+    free(dev->backend);
+    free(dev->nodename);
+
+    gnttab_end_access(dev->ring_ref);
+
+    free_page(dev->ring);
+    free(dev);
+}
+
+struct consfront_dev *init_consfront(char *_nodename)
+{
+    xenbus_transaction_t xbt;
+    char* err;
+    char* message=NULL;
+    int retry=0;
+    char* msg = NULL;
+    char nodename[256];
+    char path[256];
+    static int consfrontends = 3;
+    struct consfront_dev *dev;
+    int res;
+
+    if (!_nodename)
+        snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
+    else
+        strncpy(nodename, _nodename, sizeof(nodename));
+
+    printk("******************* CONSFRONT for %s **********\n\n\n", nodename);
+
+    consfrontends++;
+    dev = malloc(sizeof(*dev));
+    memset(dev, 0, sizeof(*dev));
+    dev->nodename = strdup(nodename);
+#ifdef HAVE_LIBC
+    dev->fd = -1;
+#endif
+
+    snprintf(path, sizeof(path), "%s/backend-id", nodename);
+    if ((res = xenbus_read_integer(path)) < 0) 
+        return NULL;
+    else
+        dev->dom = res;
+    evtchn_alloc_unbound(dev->dom, console_handle_input, dev, &dev->evtchn);
+
+    dev->ring = (struct xencons_interface *) alloc_page();
+    memset(dev->ring, 0, PAGE_SIZE);
+    dev->ring_ref = gnttab_grant_access(dev->dom, virt_to_mfn(dev->ring), 0);
+
+    dev->events = NULL;
+
+again:
+    err = xenbus_transaction_start(&xbt);
+    if (err) {
+        printk("starting transaction\n");
+        free(err);
+    }
+
+    err = xenbus_printf(xbt, nodename, "ring-ref","%u",
+                dev->ring_ref);
+    if (err) {
+        message = "writing ring-ref";
+        goto abort_transaction;
+    }
+    err = xenbus_printf(xbt, nodename,
+                "port", "%u", dev->evtchn);
+    if (err) {
+        message = "writing event-channel";
+        goto abort_transaction;
+    }
+    err = xenbus_printf(xbt, nodename,
+                "protocol", "%s", XEN_IO_PROTO_ABI_NATIVE);
+    if (err) {
+        message = "writing protocol";
+        goto abort_transaction;
+    }
+
+    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
+    if (err) {
+        message = "writing type";
+        goto abort_transaction;
+    }
+
+    snprintf(path, sizeof(path), "%s/state", nodename);
+    err = xenbus_switch_state(xbt, path, XenbusStateConnected);
+    if (err) {
+        message = "switching state";
+        goto abort_transaction;
+    }
+
+
+    err = xenbus_transaction_end(xbt, 0, &retry);
+    if (err) free(err);
+    if (retry) {
+            goto again;
+        printk("completing transaction\n");
+    }
+
+    goto done;
+
+abort_transaction:
+    free(err);
+    err = xenbus_transaction_end(xbt, 1, &retry);
+    goto error;
+
+done:
+
+    snprintf(path, sizeof(path), "%s/backend", nodename);
+    msg = xenbus_read(XBT_NIL, path, &dev->backend);
+    if (msg) {
+        printk("Error %s when reading the backend path %s\n", msg, path);
+        goto error;
+    }
+
+    printk("backend at %s\n", dev->backend);
+
+    {
+        XenbusState state;
+        char path[strlen(dev->backend) + 1 + 19 + 1];
+        snprintf(path, sizeof(path), "%s/state", dev->backend);
+        
+	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
+        msg = NULL;
+        state = xenbus_read_integer(path);
+        while (msg == NULL && state < XenbusStateConnected)
+            msg = xenbus_wait_for_state_change(path, &state, &dev->events);
+        if (msg != NULL || state != XenbusStateConnected) {
+            printk("backend not available, state=%d\n", state);
+            xenbus_unwatch_path_token(XBT_NIL, path, path);
+            goto error;
+        }
+    }
+    unmask_evtchn(dev->evtchn);
+
+    printk("**************************\n");
+
+    return dev;
+
+error:
+    free(msg);
+    free(err);
+    free_consfront(dev);
+    return NULL;
+}
+
+void fini_console(struct consfront_dev *dev)
+{
+    if (dev) free_consfront(dev);
+}
+
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index af0afed..81c8e99 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -11,6 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
+#include "console.h"
 
 DECLARE_WAIT_QUEUE_HEAD(console_queue);
 
@@ -70,7 +71,7 @@ int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
 
 
 
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
 	struct consfront_dev *dev = (struct consfront_dev *) data;
 #ifdef HAVE_LIBC
@@ -173,7 +174,7 @@ struct consfront_dev *xencons_ring_init(void)
 	dev->evtchn = start_info.console.domU.evtchn;
 	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
 
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
+	err = bind_evtchn(dev->evtchn, console_handle_input, dev);
 	if (err <= 0) {
 		printk("XEN console request chn bind failed %i\n", err);
                 free(dev);
@@ -187,183 +188,6 @@ struct consfront_dev *xencons_ring_init(void)
 	return dev;
 }
 
-void free_consfront(struct consfront_dev *dev)
-{
-    char* err = NULL;
-    XenbusState state;
-
-    char path[strlen(dev->backend) + 1 + 5 + 1];
-    char nodename[strlen(dev->nodename) + 1 + 5 + 1];
-
-    snprintf(path, sizeof(path), "%s/state", dev->backend);
-    snprintf(nodename, sizeof(nodename), "%s/state", dev->nodename);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosing)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosing, err);
-        goto close;
-    }
-    state = xenbus_read_integer(path);
-    while (err == NULL && state < XenbusStateClosing)
-        err = xenbus_wait_for_state_change(path, &state, &dev->events);
-    if (err) free(err);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosed)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosed, err);
-        goto close;
-    }
-
-close:
-    if (err) free(err);
-    xenbus_unwatch_path_token(XBT_NIL, path, path);
-
-    mask_evtchn(dev->evtchn);
-    unbind_evtchn(dev->evtchn);
-    free(dev->backend);
-    free(dev->nodename);
-
-    gnttab_end_access(dev->ring_ref);
-
-    free_page(dev->ring);
-    free(dev);
-}
-
-struct consfront_dev *init_consfront(char *_nodename)
-{
-    xenbus_transaction_t xbt;
-    char* err;
-    char* message=NULL;
-    int retry=0;
-    char* msg = NULL;
-    char nodename[256];
-    char path[256];
-    static int consfrontends = 3;
-    struct consfront_dev *dev;
-    int res;
-
-    if (!_nodename)
-        snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
-    else
-        strncpy(nodename, _nodename, sizeof(nodename));
-
-    printk("******************* CONSFRONT for %s **********\n\n\n", nodename);
-
-    consfrontends++;
-    dev = malloc(sizeof(*dev));
-    memset(dev, 0, sizeof(*dev));
-    dev->nodename = strdup(nodename);
-#ifdef HAVE_LIBC
-    dev->fd = -1;
-#endif
-
-    snprintf(path, sizeof(path), "%s/backend-id", nodename);
-    if ((res = xenbus_read_integer(path)) < 0) 
-        return NULL;
-    else
-        dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
-
-    dev->ring = (struct xencons_interface *) alloc_page();
-    memset(dev->ring, 0, PAGE_SIZE);
-    dev->ring_ref = gnttab_grant_access(dev->dom, virt_to_mfn(dev->ring), 0);
-
-    dev->events = NULL;
-
-again:
-    err = xenbus_transaction_start(&xbt);
-    if (err) {
-        printk("starting transaction\n");
-        free(err);
-    }
-
-    err = xenbus_printf(xbt, nodename, "ring-ref","%u",
-                dev->ring_ref);
-    if (err) {
-        message = "writing ring-ref";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "port", "%u", dev->evtchn);
-    if (err) {
-        message = "writing event-channel";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "protocol", "%s", XEN_IO_PROTO_ABI_NATIVE);
-    if (err) {
-        message = "writing protocol";
-        goto abort_transaction;
-    }
-
-    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
-    if (err) {
-        message = "writing type";
-        goto abort_transaction;
-    }
-
-    snprintf(path, sizeof(path), "%s/state", nodename);
-    err = xenbus_switch_state(xbt, path, XenbusStateConnected);
-    if (err) {
-        message = "switching state";
-        goto abort_transaction;
-    }
-
-
-    err = xenbus_transaction_end(xbt, 0, &retry);
-    if (err) free(err);
-    if (retry) {
-            goto again;
-        printk("completing transaction\n");
-    }
-
-    goto done;
-
-abort_transaction:
-    free(err);
-    err = xenbus_transaction_end(xbt, 1, &retry);
-    goto error;
-
-done:
-
-    snprintf(path, sizeof(path), "%s/backend", nodename);
-    msg = xenbus_read(XBT_NIL, path, &dev->backend);
-    if (msg) {
-        printk("Error %s when reading the backend path %s\n", msg, path);
-        goto error;
-    }
-
-    printk("backend at %s\n", dev->backend);
-
-    {
-        XenbusState state;
-        char path[strlen(dev->backend) + 1 + 19 + 1];
-        snprintf(path, sizeof(path), "%s/state", dev->backend);
-        
-	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
-        msg = NULL;
-        state = xenbus_read_integer(path);
-        while (msg == NULL && state < XenbusStateConnected)
-            msg = xenbus_wait_for_state_change(path, &state, &dev->events);
-        if (msg != NULL || state != XenbusStateConnected) {
-            printk("backend not available, state=%d\n", state);
-            xenbus_unwatch_path_token(XBT_NIL, path, path);
-            goto error;
-        }
-    }
-    unmask_evtchn(dev->evtchn);
-
-    printk("**************************\n");
-
-    return dev;
-
-error:
-    free(msg);
-    free(err);
-    free_consfront(dev);
-    return NULL;
-}
-
 void xencons_resume(void)
 {
 	(void)xencons_ring_init();
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 12070c3..9c69440 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -182,11 +182,13 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
              * FD.  */
             xenbus_event_queue events;
         } xenbus;
+#endif
     };
     int read;	/* maybe available for read */
 } files[];
diff --git a/extras/mini-os/include/xenbus.h b/extras/mini-os/include/xenbus.h
index de618fc..cd6316e 100644
--- a/extras/mini-os/include/xenbus.h
+++ b/extras/mini-os/include/xenbus.h
@@ -6,8 +6,14 @@
 typedef unsigned long xenbus_transaction_t;
 #define XBT_NIL ((xenbus_transaction_t)0)
 
+#ifdef CONFIG_XENBUS
 /* Initialize the XenBus system. */
 void init_xenbus(void);
+#else
+static inline void init_xenbus(void)
+{
+}
+#endif
 
 /* Read the value associated with a path.  Returns a malloc'd error
    string on failure and sets *value to NULL.  On success, *value is
@@ -98,7 +104,13 @@ char* xenbus_printf(xenbus_transaction_t xbt,
 /* Utility function to figure out our domain id */
 domid_t xenbus_get_self_id(void);
 
+#ifdef CONFIG_XENBUS
 /* Reset the XenBus system. */
 void fini_xenbus(void);
+#else
+static inline void fini_xenbus(void)
+{
+}
+#endif
 
 #endif /* XENBUS_H__ */
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index c8b9b8c..a8dfe6d 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -142,10 +142,6 @@ void stop_kernel(void)
     /* Reset grant tables */
     fini_gnttab();
 
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
     /* Reset XenBus */
     fini_xenbus();
 
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index b7b3aff..dcdf096 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -164,6 +164,7 @@ int mkdir(const char *pathname, mode_t mode)
     return -1;
 }
 
+#ifdef CONFIG_CONSFRONT
 int posix_openpt(int flags)
 {
     struct consfront_dev *dev;
@@ -192,6 +193,18 @@ int open_savefile(const char *path, int save)
     printk("fd(%d) = open_savefile\n", dev->fd);
     return(dev->fd);
 }
+#else
+int posix_openpt(int flags)
+{
+	errno = EIO;
+	return -1;
+}
+int open_savefile(const char *path, int save)
+{
+	errno = EIO;
+	return -1;
+}
+#endif
 
 int open(const char *pathname, int flags, ...)
 {
@@ -241,6 +254,7 @@ int read(int fd, void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_read(files[fd].socket.fd, buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP: {
 	    ssize_t ret;
 	    ret = netfront_receive(files[fd].tap.dev, buf, nbytes);
@@ -250,6 +264,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret;
 	}
+#endif
+#ifdef CONFIG_KBDFRONT
         case FTYPE_KBD: {
             int ret, n;
             n = nbytes / sizeof(union xenkbd_in_event);
@@ -260,6 +276,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenkbd_in_event);
         }
+#endif
+#ifdef CONFIG_FBFRONT
         case FTYPE_FB: {
             int ret, n;
             n = nbytes / sizeof(union xenfb_in_event);
@@ -270,6 +288,7 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenfb_in_event);
         }
+#endif
 	default:
 	    break;
     }
@@ -297,9 +316,11 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_write(files[fd].socket.fd, (void*) buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
+#endif
 	default:
 	    break;
     }
@@ -326,9 +347,11 @@ int close(int fd)
         default:
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
             xs_daemon_close((void*)(intptr_t) fd);
             return 0;
+#endif
 #ifdef HAVE_LWIP
 	case FTYPE_SOCKET: {
 	    int res = lwip_close(files[fd].socket.fd);
@@ -345,27 +368,37 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_BLKFRONT
 	case FTYPE_BLK:
             shutdown_blkfront(files[fd].blk.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_FBFRONT
 	case FTYPE_FB:
             shutdown_fbfront(files[fd].fb.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_CONSFRONT
         case FTYPE_SAVEFILE:
         case FTYPE_CONSOLE:
             fini_console(files[fd].cons.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
 	case FTYPE_NONE:
 	    break;
     }
@@ -611,6 +644,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
                 n++;
 	    FD_CLR(i, exceptfds);
 	    break;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
 	    if (FD_ISSET(i, readfds)) {
                 if (files[i].xenbus.events)
@@ -621,6 +655,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
 	    FD_CLR(i, writefds);
 	    FD_CLR(i, exceptfds);
 	    break;
+#endif
 	case FTYPE_EVTCHN:
 	case FTYPE_TAP:
 	case FTYPE_BLK:
@@ -727,11 +762,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
+#ifdef CONFIG_NETFRONT
     add_waiter(w1, netfront_queue);
+#endif
     add_waiter(w2, event_queue);
+#ifdef CONFIG_BLKFRONT
     add_waiter(w3, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     add_waiter(w4, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     add_waiter(w5, kbdfront_queue);
+#endif
     add_waiter(w6, console_queue);
 
     if (readfds)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index aeda548..73eb6fb 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -63,10 +63,12 @@ static void call_main(void *p)
 #ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #endif
-#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK) && defined(CONFIG_NETFRONT)
     start_networking();
 #endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
@@ -169,7 +171,7 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
-#ifdef HAVE_LWIP
+#if defined(HAVE_LWIP) && defined(CONFIG_NETFRONT)
     stop_networking();
 #endif
     stop_kernel();
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
index 7ea1d2f..e3a96da 100644
--- a/stubdom/ioemu-minios.cfg
+++ b/stubdom/ioemu-minios.cfg
@@ -1 +1,2 @@
 CONFIG_QEMU_XS_ARGS=y
+CONFIG_PCIFRONT=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGX-0002IA-Ia; Thu, 26 Jan 2012 19:45:49 +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 1RqVGV-0002DB-Ed
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327607072!62637757!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26656 invoked from network); 26 Jan 2012 19:44:33 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:44:33 -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
	q0QJjdQG026846
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHq005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:57 -0500
Message-Id: <1327607111-15394-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 10/24] mini-os: create app-specific configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile  |   52 ++++++++++++++++++++++++++++++++++++++++-----
 extras/mini-os/main.c    |   16 +++++++-------
 extras/mini-os/minios.mk |    4 +-
 stubdom/Makefile         |    8 +++---
 stubdom/grub/minios.cfg  |    2 +
 stubdom/ioemu-minios.cfg |    1 +
 6 files changed, 63 insertions(+), 20 deletions(-)
 create mode 100644 stubdom/c/minios.cfg
 create mode 100644 stubdom/caml/minios.cfg
 create mode 100644 stubdom/grub/minios.cfg
 create mode 100644 stubdom/ioemu-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c2ee062..be38170 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,10 +8,25 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(MINIOS_CONFIG),)
 include Config.mk
+else
+EXTRA_DEPS += $(MINIOS_CONFIG)
+include $(MINIOS_CONFIG)
 endif
 
+# Configuration defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+CONFIG_QEMU_XS_ARGS ?= n
+
+# Export config items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
 # Include common mini-os makerules.
 include minios.mk
 
@@ -34,13 +49,38 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e9dbf02..d4da2bb 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/grub/minios.cfg b/stubdom/grub/minios.cfg
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/stubdom/grub/minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
new file mode 100644
index 0000000..7ea1d2f
--- /dev/null
+++ b/stubdom/ioemu-minios.cfg
@@ -0,0 +1 @@
+CONFIG_QEMU_XS_ARGS=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGV-0002Fc-CJ; Thu, 26 Jan 2012 19:45:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGS-0002Dv-6h
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327607073!62637758!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26677 invoked from network); 26 Jan 2012 19:44:33 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:44:33 -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
	q0QJjeQG026865
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI5005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:10 -0500
Message-Id: <1327607111-15394-24-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 23/24] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index f254947..2894f1b 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1825,6 +1825,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1838,6 +1839,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1903,6 +1905,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 22fe126b..151e088 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -263,7 +263,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGT-0002EW-A2; Thu, 26 Jan 2012 19:45:45 +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 1RqVGR-0002DO-FN
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327607121!64074836!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19652 invoked from network); 26 Jan 2012 19:45:21 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:45:21 -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
	q0QJjeQG026853; Thu, 26 Jan 2012 19:45: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 q0QJjcHw005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:03 -0500
Message-Id: <1327607111-15394-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 16/24] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Add option for compiling xenstored without unix sockets to support
running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c |   28 +++++++++++++++++++++++-----
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0e7d43f..c1ee932 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
-	set_fd(sock,               inset, &max);
-	set_fd(ro_sock,            inset, &max);
+	if (sock != -1)
+		set_fd(sock, inset, &max);
+	if (ro_sock != -1)
+		set_fd(ro_sock, inset, &max);
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -1345,6 +1349,11 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifdef NO_SOCKETS
+static void accept_connection(int sock, bool canwrite)
+{
+}
+#else
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1399,6 +1408,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1698,6 +1708,13 @@ static void daemonize(void)
 	umask(0);
 }
 
+#ifdef NO_SOCKETS
+static void init_sockets(int **psock, int **pro_sock)
+{
+	static int minus_one = -1;
+	*psock = *pro_sock = &minus_one;
+}
+#else
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
@@ -1743,6 +1760,7 @@ static void init_sockets(int **psock, int **pro_sock)
 
 
 }
+#endif
 
 static void usage(void)
 {
@@ -1938,10 +1956,10 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
-		if (FD_ISSET(*sock, &inset))
+		if (*sock != -1 && FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
-		if (FD_ISSET(*ro_sock, &inset))
+		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGU-0002FB-IO; Thu, 26 Jan 2012 19:45:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DY-Sh
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
Received: from [85.158.138.51:10213] by server-9.bemta-3.messagelabs.com id
	97/47-31168-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327607141!10820897!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28420 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeQG026866
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI6005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:11 -0500
Message-Id: <1327607111-15394-25-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 24/24] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   44 ++++++++++++++
 tools/xenstore/Makefile                  |    9 ++-
 tools/xenstore/init-xenstore-domain.c    |   94 ++++++++++++++++++++++++++++++
 3 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..bbee8c6
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,44 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index be892fd..2fce994 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -26,7 +26,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
@@ -50,6 +50,11 @@ xenstored_probes.o: xenstored_solaris.o
 CFLAGS += -DHAVE_DTRACE=1
 endif
 
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -85,7 +90,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..f6c31d0
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,94 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+	if (rv < 0) return rv;
+	snprintf(cmdline, 512, "--event %d", rv);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGT-0002EW-A2; Thu, 26 Jan 2012 19:45:45 +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 1RqVGR-0002DO-FN
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327607121!64074836!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19652 invoked from network); 26 Jan 2012 19:45:21 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-15.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:45:21 -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
	q0QJjeQG026853; Thu, 26 Jan 2012 19:45: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 q0QJjcHw005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:03 -0500
Message-Id: <1327607111-15394-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 16/24] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Add option for compiling xenstored without unix sockets to support
running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c |   28 +++++++++++++++++++++++-----
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0e7d43f..c1ee932 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
-	set_fd(sock,               inset, &max);
-	set_fd(ro_sock,            inset, &max);
+	if (sock != -1)
+		set_fd(sock, inset, &max);
+	if (ro_sock != -1)
+		set_fd(ro_sock, inset, &max);
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -1345,6 +1349,11 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifdef NO_SOCKETS
+static void accept_connection(int sock, bool canwrite)
+{
+}
+#else
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1399,6 +1408,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1698,6 +1708,13 @@ static void daemonize(void)
 	umask(0);
 }
 
+#ifdef NO_SOCKETS
+static void init_sockets(int **psock, int **pro_sock)
+{
+	static int minus_one = -1;
+	*psock = *pro_sock = &minus_one;
+}
+#else
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
@@ -1743,6 +1760,7 @@ static void init_sockets(int **psock, int **pro_sock)
 
 
 }
+#endif
 
 static void usage(void)
 {
@@ -1938,10 +1956,10 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
-		if (FD_ISSET(*sock, &inset))
+		if (*sock != -1 && FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
-		if (FD_ISSET(*ro_sock, &inset))
+		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGa-0002LR-1e; Thu, 26 Jan 2012 19:45:52 +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 1RqVGW-0002Dl-VF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327607141!12745899!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7801 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjdQG026838; Thu, 26 Jan 2012 19:45: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 q0QJjcHh005952; 
	Thu, 26 Jan 2012 14:45:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:48 -0500
Message-Id: <1327607111-15394-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/24] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/compat/memory.c  |   14 ++++++++++++++
 xen/common/memory.c         |   37 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-ia64/mm.h   |    1 +
 xen/include/public/memory.h |   16 ++++++++++++++++
 xen/include/xlat.lst        |    1 +
 xen/include/xsm/xsm.h       |    6 ++++++
 xen/xsm/dummy.c             |    6 ++++++
 xen/xsm/flask/hooks.c       |    6 ++++++
 8 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 2402984..e7257cc 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -25,6 +25,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             XEN_GUEST_HANDLE(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
+            struct xen_remove_from_physmap *xrfp;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
@@ -179,6 +180,18 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             nat.hnd = compat;
             break;
 
+        case XENMEM_remove_from_physmap:
+        {
+            struct compat_remove_from_physmap cmp;
+
+            if ( copy_from_guest(&cmp, compat, 1) )
+                return -EFAULT;
+
+            XLAT_remove_from_physmap(nat.xrfp, &cmp);
+
+            break;
+        }
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -284,6 +297,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
         case XENMEM_current_reservation:
         case XENMEM_maximum_reservation:
         case XENMEM_maximum_gpfn:
+        case XENMEM_remove_from_physmap:
             break;
 
         default:
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8d45439..53886ce 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -659,6 +659,43 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
 
         break;
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+        else
+            rc = -ENOENT;
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     default:
         rc = arch_memory_op(op, arg);
         break;
diff --git a/xen/include/asm-ia64/mm.h b/xen/include/asm-ia64/mm.h
index d09c363..a2bfc02 100644
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -550,6 +550,7 @@ extern u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__,
 #define gmfn_to_mfn(_d, gpfn)			\
     gmfn_to_mfn_foreign((_d), (gpfn))
 
+#define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
 #define put_gfn(d, g)   ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index f602155..3d4f1e3 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -60,6 +60,7 @@
 !	memory_map			memory.h
 !	memory_reservation		memory.h
 !	pod_target			memory.h
+!	remove_from_physmap		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGW-0002H6-Lr; Thu, 26 Jan 2012 19:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGS-0002DZ-Rm
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:45 +0000
Received: from [85.158.138.51:10243] by server-5.bemta-3.messagelabs.com id
	C4/D3-02363-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327607141!10770042!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24631 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjdLe009006; Thu, 26 Jan 2012 19:45: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 q0QJjcHn005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:54 -0500
Message-Id: <1327607111-15394-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 07/24] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  158 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 210 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..5f609de 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,163 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    gnttab_setup_table_t setup;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+    unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+    if (gmfnp == NULL)
+        return -1;
+
+    setup.dom = domid;
+    setup.nr_frames = 1;
+    set_xen_guest_handle(setup.frame_list, gmfnp);
+    setup.status = 0;
+
+    rc = xc_gnttab_op(xch, GNTTABOP_setup_table, &setup, sizeof(setup), 1);
+    gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+        .domid = domid,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..8bee684 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..3bd5549 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3828c62..28646e0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -224,7 +224,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -250,6 +252,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -263,7 +269,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -296,6 +303,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -349,7 +358,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -387,7 +398,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGY-0002Jf-OC; Thu, 26 Jan 2012 19:45:50 +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 1RqVGW-0002DI-5O
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327607141!12672400!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24002 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeLe009014
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHt005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:00 -0500
Message-Id: <1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The symbol _LINUX_LIST_H collides with other header files.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGa-0002LR-1e; Thu, 26 Jan 2012 19:45:52 +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 1RqVGW-0002Dl-VF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327607141!12745899!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7801 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-5.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjdQG026838; Thu, 26 Jan 2012 19:45: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 q0QJjcHh005952; 
	Thu, 26 Jan 2012 14:45:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:48 -0500
Message-Id: <1327607111-15394-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Subject: [Xen-devel] [PATCH 01/24] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/common/compat/memory.c  |   14 ++++++++++++++
 xen/common/memory.c         |   37 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-ia64/mm.h   |    1 +
 xen/include/public/memory.h |   16 ++++++++++++++++
 xen/include/xlat.lst        |    1 +
 xen/include/xsm/xsm.h       |    6 ++++++
 xen/xsm/dummy.c             |    6 ++++++
 xen/xsm/flask/hooks.c       |    6 ++++++
 8 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 2402984..e7257cc 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -25,6 +25,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             XEN_GUEST_HANDLE(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
+            struct xen_remove_from_physmap *xrfp;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
@@ -179,6 +180,18 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             nat.hnd = compat;
             break;
 
+        case XENMEM_remove_from_physmap:
+        {
+            struct compat_remove_from_physmap cmp;
+
+            if ( copy_from_guest(&cmp, compat, 1) )
+                return -EFAULT;
+
+            XLAT_remove_from_physmap(nat.xrfp, &cmp);
+
+            break;
+        }
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -284,6 +297,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
         case XENMEM_current_reservation:
         case XENMEM_maximum_reservation:
         case XENMEM_maximum_gpfn:
+        case XENMEM_remove_from_physmap:
             break;
 
         default:
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8d45439..53886ce 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -659,6 +659,43 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
 
         break;
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+        else
+            rc = -ENOENT;
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     default:
         rc = arch_memory_op(op, arg);
         break;
diff --git a/xen/include/asm-ia64/mm.h b/xen/include/asm-ia64/mm.h
index d09c363..a2bfc02 100644
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -550,6 +550,7 @@ extern u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__,
 #define gmfn_to_mfn(_d, gpfn)			\
     gmfn_to_mfn_foreign((_d), (gpfn))
 
+#define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
 #define put_gfn(d, g)   ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index f602155..3d4f1e3 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -60,6 +60,7 @@
 !	memory_map			memory.h
 !	memory_reservation		memory.h
 !	pod_target			memory.h
+!	remove_from_physmap		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGR-0002DQ-3c; Thu, 26 Jan 2012 19:45:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGQ-0002D8-6T
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:42 +0000
Received: from [85.158.139.83:52183] by server-4.bemta-5.messagelabs.com id
	2D/26-09697-56DA12F4; Thu, 26 Jan 2012 19:45:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327607139!5214863!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4401 invoked from network); 26 Jan 2012 19:45:40 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 19:45:40 -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
	q0QJjcLe009002
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHg005952
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 14:45:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:47 -0500
Message-Id: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Subject: [Xen-devel] [PATCH v5 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v4:
 - Add --internal-db flag to use TDB_INTERNAL on non-stubdom
 - Fewer #ifdefs

Changes from v3:
 - mini-os configuration files moved into stubdom/
 - mini-os extra console support now a config option
 - Fewer #ifdefs
 - grant table setup uses hypercall bounce
 - Xenstore stub domain syslog support re-enabled

Changes from v2:
 - configuration support added to mini-os build system
 - add mini-os support for conditionally compiling frontends, xenbus
 - XENMEM_remove_from_physmap moved out of arch-specific code
 - use uint32_t for virqs
 - warn when dropping grant v2-only flags when switching versions
 - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
 - ioctl now returns -EEXIST if xenstored has already been connected
 - various cosmetic cleanups, shuffling

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

Other notes:

The console for xenstored is not currently set up by
init-xenstore-domain. If the hypervisor is compiled with VERBOSE or
debug=y, output from xenstored will be visible on the hypervisor serial
console (or ring buffer if enabled with console_to_ring). The xenstore
stub domain itself supports console output, and init-xenstore-domain
could be extended to daemonize and spool this output to a log file. The
normal xenconsole daemon cannot be used here due to the possibility of a
deadlock.

----

[PATCH 01/24] xen: reinstate previously unused
[PATCH 02/24] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/24] xen: change virq parameters from int to uint32_t
[PATCH 04/24] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 05/24] xen: Preserve reserved grant entries when switching

[PATCH 06/24] tools/libxl: pull xenstore/console domids from
[PATCH 07/24] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 08/24] mini-os: avoid crash if no console is provided
[PATCH 09/24] mini-os: remove per-fd evtchn limit
[PATCH 10/24] mini-os: create app-specific configuration
[PATCH 11/24] mini-os: Move test functions into test.c
[PATCH 12/24] mini-os: make frontends and xenbus optional
[PATCH 13/24] mini-os: fix list.h include guard name

[PATCH 14/24] xenstored: use grant references instead of
[PATCH 15/24] xenstored: refactor socket setup code
[PATCH 16/24] xenstored: add NO_SOCKETS compilation option
[PATCH 17/24] xenstored: support for tdb_copy with TDB_INTERNAL
[PATCH 18/24] xenstored: add --internal-db flag
[PATCH 19/24] xenstored: support running in minios stubdom
[PATCH 20/24] stubdom: enable xenstored build
[PATCH 21/24] xenstored: add --event parameter for bootstrapping
[PATCH 22/24] xenstored: use domain_is_unprivileged instead of
[PATCH 23/24] xenstored: add --priv-domid parameter
[PATCH 24/24] xenstored: Add stub domain builder

Linux patch unchanged since v3, not reposted this time:
[PATCH] xenbus: Add support for xenbus backend in stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGT-0002Eg-Ma; Thu, 26 Jan 2012 19:45:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DP-Gf
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:43 +0000
Received: from [85.158.138.51:10194] by server-8.bemta-3.messagelabs.com id
	39/32-31878-66DA12F4; Thu, 26 Jan 2012 19:45:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327607141!10655008!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17942 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-16.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeQG026864
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI2005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:07 -0500
Message-Id: <1327607111-15394-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 20/24] stubdom: enable xenstored 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>
MIME-Version: 1.0
Content-Type: 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>
---
 stubdom/Makefile            |   29 ++++++++++++++++++++++++++---
 stubdom/xenstore-minios.cfg |    9 +++++++++
 2 files changed, 35 insertions(+), 3 deletions(-)
 create mode 100644 stubdom/xenstore-minios.cfg

diff --git a/stubdom/Makefile b/stubdom/Makefile
index d4da2bb..5c02464 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg
new file mode 100644
index 0000000..ab7338f
--- /dev/null
+++ b/stubdom/xenstore-minios.cfg
@@ -0,0 +1,9 @@
+CONFIG_BLKFRONT=n
+CONFIG_NETFRONT=n
+CONFIG_FBFRONT=n
+CONFIG_KBDFRONT=n
+CONFIG_CONSFRONT=n
+CONFIG_XENBUS=n
+
+lwip=n
+DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS))
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGX-0002IA-Ia; Thu, 26 Jan 2012 19:45:49 +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 1RqVGV-0002DB-Ed
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:47 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327607072!62637757!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26656 invoked from network); 26 Jan 2012 19:44:33 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:44:33 -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
	q0QJjdQG026846
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHq005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:57 -0500
Message-Id: <1327607111-15394-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 10/24] mini-os: create app-specific configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile  |   52 ++++++++++++++++++++++++++++++++++++++++-----
 extras/mini-os/main.c    |   16 +++++++-------
 extras/mini-os/minios.mk |    4 +-
 stubdom/Makefile         |    8 +++---
 stubdom/grub/minios.cfg  |    2 +
 stubdom/ioemu-minios.cfg |    1 +
 6 files changed, 63 insertions(+), 20 deletions(-)
 create mode 100644 stubdom/c/minios.cfg
 create mode 100644 stubdom/caml/minios.cfg
 create mode 100644 stubdom/grub/minios.cfg
 create mode 100644 stubdom/ioemu-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c2ee062..be38170 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,10 +8,25 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(MINIOS_CONFIG),)
 include Config.mk
+else
+EXTRA_DEPS += $(MINIOS_CONFIG)
+include $(MINIOS_CONFIG)
 endif
 
+# Configuration defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+CONFIG_QEMU_XS_ARGS ?= n
+
+# Export config items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
 # Include common mini-os makerules.
 include minios.mk
 
@@ -34,13 +49,38 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e9dbf02..d4da2bb 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/grub/minios.cfg b/stubdom/grub/minios.cfg
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/stubdom/grub/minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
new file mode 100644
index 0000000..7ea1d2f
--- /dev/null
+++ b/stubdom/ioemu-minios.cfg
@@ -0,0 +1 @@
+CONFIG_QEMU_XS_ARGS=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGY-0002Jf-OC; Thu, 26 Jan 2012 19:45:50 +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 1RqVGW-0002DI-5O
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327607141!12672400!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24002 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeLe009014
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHt005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:00 -0500
Message-Id: <1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The symbol _LINUX_LIST_H collides with other header files.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/include/list.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
index a60ae23..4e6a2ac 100644
--- a/extras/mini-os/include/list.h
+++ b/extras/mini-os/include/list.h
@@ -1,5 +1,5 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
+#ifndef _MINIOS_LIST_H
+#define _MINIOS_LIST_H
 
 /*
  * Simple doubly linked list implementation.
@@ -186,5 +186,5 @@ static __inline__ void minios_list_splice(struct minios_list_head *list, struct
 		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
 	     &pos->member != (head); 					\
 	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
+#endif /* _MINIOS_LIST_H */
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGX-0002Ha-3u; Thu, 26 Jan 2012 19:45:49 +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 1RqVGT-0002DA-JA
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327607093!51737380!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17956 invoked from network); 26 Jan 2012 19:44:53 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:44:53 -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
	q0QJjdLe009005
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHj005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:50 -0500
Message-Id: <1327607111-15394-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/24] xen: change virq parameters from int to
	uint32_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c   |   10 +++++-----
 xen/include/asm-ia64/event.h |    2 +-
 xen/include/asm-x86/event.h  |    2 +-
 xen/include/xen/event.h      |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43bd167..f784254 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,11 +104,11 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 
 static int evtchn_set_pending(struct vcpu *v, int port);
 
-static int virq_is_global(int virq)
+static int virq_is_global(uint32_t virq)
 {
     int rc;
 
-    ASSERT((virq >= 0) && (virq < NR_VIRQS));
+    ASSERT(virq < NR_VIRQS);
 
     switch ( virq )
     {
@@ -665,12 +665,12 @@ static int evtchn_set_pending(struct vcpu *v, int port)
     return 0;
 }
 
-int guest_enabled_event(struct vcpu *v, int virq)
+int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
 }
 
-void send_guest_vcpu_virq(struct vcpu *v, int virq)
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 {
     unsigned long flags;
     int port;
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
     unsigned long flags;
     int port;
diff --git a/xen/include/asm-ia64/event.h b/xen/include/asm-ia64/event.h
index c99babd..4463cb3 100644
--- a/xen/include/asm-ia64/event.h
+++ b/xen/include/asm-ia64/event.h
@@ -63,7 +63,7 @@ static inline void local_event_delivery_enable(void)
     current->vcpu_info->evtchn_upcall_mask = 0;
 }
 
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     int rc;
 
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index 606ec6d..06057c7 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -39,7 +39,7 @@ static inline void local_event_delivery_enable(void)
 }
 
 /* No arch specific virq definition now. Default to global. */
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     return 1;
 }
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 40b8a7a..22fc6a3 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,7 @@
  *  @v:        VCPU to which virtual IRQ should be sent
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_vcpu_virq(struct vcpu *v, int virq);
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
  * send_global_virq: Notify the domain handling a global VIRQ.
@@ -65,7 +65,7 @@ void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
 /* Query if event channel is in use by the guest */
-int guest_enabled_event(struct vcpu *v, int virq);
+int guest_enabled_event(struct vcpu *v, uint32_t virq);
 
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGR-0002DQ-3c; Thu, 26 Jan 2012 19:45:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGQ-0002D8-6T
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:42 +0000
Received: from [85.158.139.83:52183] by server-4.bemta-5.messagelabs.com id
	2D/26-09697-56DA12F4; Thu, 26 Jan 2012 19:45:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327607139!5214863!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4401 invoked from network); 26 Jan 2012 19:45:40 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 19:45:40 -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
	q0QJjcLe009002
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHg005952
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 14:45:38 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:47 -0500
Message-Id: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Subject: [Xen-devel] [PATCH v5 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v4:
 - Add --internal-db flag to use TDB_INTERNAL on non-stubdom
 - Fewer #ifdefs

Changes from v3:
 - mini-os configuration files moved into stubdom/
 - mini-os extra console support now a config option
 - Fewer #ifdefs
 - grant table setup uses hypercall bounce
 - Xenstore stub domain syslog support re-enabled

Changes from v2:
 - configuration support added to mini-os build system
 - add mini-os support for conditionally compiling frontends, xenbus
 - XENMEM_remove_from_physmap moved out of arch-specific code
 - use uint32_t for virqs
 - warn when dropping grant v2-only flags when switching versions
 - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
 - ioctl now returns -EEXIST if xenstored has already been connected
 - various cosmetic cleanups, shuffling

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

Other notes:

The console for xenstored is not currently set up by
init-xenstore-domain. If the hypervisor is compiled with VERBOSE or
debug=y, output from xenstored will be visible on the hypervisor serial
console (or ring buffer if enabled with console_to_ring). The xenstore
stub domain itself supports console output, and init-xenstore-domain
could be extended to daemonize and spool this output to a log file. The
normal xenconsole daemon cannot be used here due to the possibility of a
deadlock.

----

[PATCH 01/24] xen: reinstate previously unused
[PATCH 02/24] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/24] xen: change virq parameters from int to uint32_t
[PATCH 04/24] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 05/24] xen: Preserve reserved grant entries when switching

[PATCH 06/24] tools/libxl: pull xenstore/console domids from
[PATCH 07/24] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 08/24] mini-os: avoid crash if no console is provided
[PATCH 09/24] mini-os: remove per-fd evtchn limit
[PATCH 10/24] mini-os: create app-specific configuration
[PATCH 11/24] mini-os: Move test functions into test.c
[PATCH 12/24] mini-os: make frontends and xenbus optional
[PATCH 13/24] mini-os: fix list.h include guard name

[PATCH 14/24] xenstored: use grant references instead of
[PATCH 15/24] xenstored: refactor socket setup code
[PATCH 16/24] xenstored: add NO_SOCKETS compilation option
[PATCH 17/24] xenstored: support for tdb_copy with TDB_INTERNAL
[PATCH 18/24] xenstored: add --internal-db flag
[PATCH 19/24] xenstored: support running in minios stubdom
[PATCH 20/24] stubdom: enable xenstored build
[PATCH 21/24] xenstored: add --event parameter for bootstrapping
[PATCH 22/24] xenstored: use domain_is_unprivileged instead of
[PATCH 23/24] xenstored: add --priv-domid parameter
[PATCH 24/24] xenstored: Add stub domain builder

Linux patch unchanged since v3, not reposted this time:
[PATCH] xenbus: Add support for xenbus backend in stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGV-0002Fc-CJ; Thu, 26 Jan 2012 19:45:47 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGS-0002Dv-6h
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327607073!62637758!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26677 invoked from network); 26 Jan 2012 19:44:33 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:44:33 -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
	q0QJjeQG026865
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI5005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:10 -0500
Message-Id: <1327607111-15394-24-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 23/24] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index f254947..2894f1b 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1825,6 +1825,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1838,6 +1839,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1903,6 +1905,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index d3040ba..03e2e48 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 22fe126b..151e088 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -263,7 +263,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGT-0002Eg-Ma; Thu, 26 Jan 2012 19:45:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DP-Gf
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:43 +0000
Received: from [85.158.138.51:10194] by server-8.bemta-3.messagelabs.com id
	39/32-31878-66DA12F4; Thu, 26 Jan 2012 19:45:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327607141!10655008!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17942 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-16.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeQG026864
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI2005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:07 -0500
Message-Id: <1327607111-15394-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 20/24] stubdom: enable xenstored 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>
MIME-Version: 1.0
Content-Type: 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>
---
 stubdom/Makefile            |   29 ++++++++++++++++++++++++++---
 stubdom/xenstore-minios.cfg |    9 +++++++++
 2 files changed, 35 insertions(+), 3 deletions(-)
 create mode 100644 stubdom/xenstore-minios.cfg

diff --git a/stubdom/Makefile b/stubdom/Makefile
index d4da2bb..5c02464 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ LWIPDIR=$(CURDIR)/lwip xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg
new file mode 100644
index 0000000..ab7338f
--- /dev/null
+++ b/stubdom/xenstore-minios.cfg
@@ -0,0 +1,9 @@
+CONFIG_BLKFRONT=n
+CONFIG_NETFRONT=n
+CONFIG_FBFRONT=n
+CONFIG_KBDFRONT=n
+CONFIG_CONSFRONT=n
+CONFIG_XENBUS=n
+
+lwip=n
+DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS))
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGX-0002Ha-3u; Thu, 26 Jan 2012 19:45:49 +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 1RqVGT-0002DA-JA
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:45 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327607093!51737380!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17956 invoked from network); 26 Jan 2012 19:44:53 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:44:53 -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
	q0QJjdLe009005
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHj005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:50 -0500
Message-Id: <1327607111-15394-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/24] xen: change virq parameters from int to
	uint32_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c   |   10 +++++-----
 xen/include/asm-ia64/event.h |    2 +-
 xen/include/asm-x86/event.h  |    2 +-
 xen/include/xen/event.h      |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43bd167..f784254 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,11 +104,11 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 
 static int evtchn_set_pending(struct vcpu *v, int port);
 
-static int virq_is_global(int virq)
+static int virq_is_global(uint32_t virq)
 {
     int rc;
 
-    ASSERT((virq >= 0) && (virq < NR_VIRQS));
+    ASSERT(virq < NR_VIRQS);
 
     switch ( virq )
     {
@@ -665,12 +665,12 @@ static int evtchn_set_pending(struct vcpu *v, int port)
     return 0;
 }
 
-int guest_enabled_event(struct vcpu *v, int virq)
+int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
 }
 
-void send_guest_vcpu_virq(struct vcpu *v, int virq)
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 {
     unsigned long flags;
     int port;
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
     unsigned long flags;
     int port;
diff --git a/xen/include/asm-ia64/event.h b/xen/include/asm-ia64/event.h
index c99babd..4463cb3 100644
--- a/xen/include/asm-ia64/event.h
+++ b/xen/include/asm-ia64/event.h
@@ -63,7 +63,7 @@ static inline void local_event_delivery_enable(void)
     current->vcpu_info->evtchn_upcall_mask = 0;
 }
 
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     int rc;
 
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index 606ec6d..06057c7 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -39,7 +39,7 @@ static inline void local_event_delivery_enable(void)
 }
 
 /* No arch specific virq definition now. Default to global. */
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     return 1;
 }
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 40b8a7a..22fc6a3 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,7 @@
  *  @v:        VCPU to which virtual IRQ should be sent
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_vcpu_virq(struct vcpu *v, int virq);
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
  * send_global_virq: Notify the domain handling a global VIRQ.
@@ -65,7 +65,7 @@ void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
 /* Query if event channel is in use by the guest */
-int guest_enabled_event(struct vcpu *v, int virq);
+int guest_enabled_event(struct vcpu *v, uint32_t virq);
 
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGW-0002H6-Lr; Thu, 26 Jan 2012 19:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGS-0002DZ-Rm
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:45 +0000
Received: from [85.158.138.51:10243] by server-5.bemta-3.messagelabs.com id
	C4/D3-02363-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327607141!10770042!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24631 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-12.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjdLe009006; Thu, 26 Jan 2012 19:45: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 q0QJjcHn005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:54 -0500
Message-Id: <1327607111-15394-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 07/24] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/libxc/xc_dom.h              |   13 +++
 tools/libxc/xc_dom_boot.c         |  158 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 210 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..6c36403 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -106,7 +106,9 @@ struct xc_dom_image {
     /* misc xen domain config stuff */
     unsigned long flags;
     unsigned int console_evtchn;
+    unsigned int console_domid;
     unsigned int xenstore_evtchn;
+    unsigned int xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +202,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gmfn,
+                           unsigned long xenstore_gmfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..5f609de 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,163 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static unsigned long xc_dom_gnttab_setup(xc_interface *xch, uint32_t domid)
+{
+    gnttab_setup_table_t setup;
+    DECLARE_HYPERCALL_BUFFER(unsigned long, gmfnp);
+    int rc;
+    unsigned long gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+    if (gmfnp == NULL)
+        return -1;
+
+    setup.dom = domid;
+    setup.nr_frames = 1;
+    set_xen_guest_handle(setup.frame_list, gmfnp);
+    setup.status = 0;
+
+    rc = xc_gnttab_op(xch, GNTTABOP_setup_table, &setup, sizeof(setup), 1);
+    gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, uint32_t domid,
+                       unsigned long console_gmfn,
+                       unsigned long xenstore_gmfn,
+                       uint32_t console_domid,
+                       uint32_t xenstore_domid)
+{
+
+    unsigned long gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, uint32_t domid,
+                           unsigned long console_gpfn,
+                           unsigned long xenstore_gpfn,
+                           uint32_t console_domid,
+                           uint32_t xenstore_domid)
+{
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+        .domid = domid,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    unsigned long console_gmfn;
+    unsigned long xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..8bee684 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..3bd5549 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      uint32_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, uint32_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3828c62..28646e0 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -224,7 +224,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -250,6 +252,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -263,7 +269,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                uint32_t store_domid, uint32_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -296,6 +303,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -349,7 +358,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -387,7 +398,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVGU-0002FM-W8; Thu, 26 Jan 2012 19:45:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGS-0002DX-43
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
Received: from [85.158.138.51:10223] by server-4.bemta-3.messagelabs.com id
	12/AD-32238-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327607141!10621176!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20402 invoked from network); 26 Jan 2012 19:45:42 -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;
	26 Jan 2012 19:45:42 -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
	q0QJjeLe009015; Thu, 26 Jan 2012 19:45: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 q0QJjcHu005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:01 -0500
Message-Id: <1327607111-15394-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 14/24] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_domain.c |   54 ++++++++++++++++++++++++++++++++----
 1 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..c521e52 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
 	return len;
 }
 
+static void *map_interface(domid_t domid, unsigned long mfn)
+{
+	if (*xcg_handle >= 0) {
+		/* this is the preferred method */
+		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	} else {
+		return xc_map_foreign_range(*xc_handle, domid,
+			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+	}
+}
+
+static void unmap_interface(void *interface)
+{
+	if (*xcg_handle >= 0)
+		xc_gnttab_munmap(*xcg_handle, interface, 1);
+	else
+		munmap(interface, getpagesize());
+}
+
 static int destroy_domain(void *_domain)
 {
 	struct domain *domain = _domain;
@@ -174,8 +196,14 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		/* Domain 0 was mapped by dom0_init, so it must be unmapped
+		   using munmap() and not the grant unmap call. */
+		if (domain->domid == 0)
+			munmap(domain->interface, getpagesize());
+		else
+			unmap_interface(domain->interface);
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +372,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		interface = map_interface(domid, mfn);
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +380,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			unmap_interface(interface);
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +578,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +635,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVGU-0002FM-W8; Thu, 26 Jan 2012 19:45:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGS-0002DX-43
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
Received: from [85.158.138.51:10223] by server-4.bemta-3.messagelabs.com id
	12/AD-32238-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327607141!10621176!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20402 invoked from network); 26 Jan 2012 19:45:42 -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;
	26 Jan 2012 19:45:42 -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
	q0QJjeLe009015; Thu, 26 Jan 2012 19:45: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 q0QJjcHu005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:01 -0500
Message-Id: <1327607111-15394-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 14/24] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_domain.c |   54 ++++++++++++++++++++++++++++++++----
 1 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..c521e52 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
 	return len;
 }
 
+static void *map_interface(domid_t domid, unsigned long mfn)
+{
+	if (*xcg_handle >= 0) {
+		/* this is the preferred method */
+		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	} else {
+		return xc_map_foreign_range(*xc_handle, domid,
+			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+	}
+}
+
+static void unmap_interface(void *interface)
+{
+	if (*xcg_handle >= 0)
+		xc_gnttab_munmap(*xcg_handle, interface, 1);
+	else
+		munmap(interface, getpagesize());
+}
+
 static int destroy_domain(void *_domain)
 {
 	struct domain *domain = _domain;
@@ -174,8 +196,14 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		/* Domain 0 was mapped by dom0_init, so it must be unmapped
+		   using munmap() and not the grant unmap call. */
+		if (domain->domid == 0)
+			munmap(domain->interface, getpagesize());
+		else
+			unmap_interface(domain->interface);
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +372,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		interface = map_interface(domid, mfn);
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +380,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			unmap_interface(interface);
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +578,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +635,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVGU-0002F0-5l; Thu, 26 Jan 2012 19:45:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DW-Qw
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
Received: from [85.158.139.83:9759] by server-9.bemta-5.messagelabs.com id
	7B/9B-24580-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327607141!12512846!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20671 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeLe009016
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHv005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:02 -0500
Message-Id: <1327607111-15394-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/24] xenstored: refactor socket 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>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/xenstore/xenstored_core.c |   85 +++++++++++++++++++++------------------
 1 files changed, 46 insertions(+), 39 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..0e7d43f 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -343,13 +343,6 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
-static int destroy_fd(void *_fd)
-{
-	int *fd = _fd;
-	close(*fd);
-	return 0;
-}
-
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
 {
@@ -1705,6 +1698,51 @@ static void daemonize(void)
 	umask(0);
 }
 
+static int destroy_fd(void *_fd)
+{
+	int *fd = _fd;
+	close(*fd);
+	return 0;
+}
+
+static void init_sockets(int **psock, int **pro_sock)
+{
+	struct sockaddr_un addr;
+	int *sock, *ro_sock;
+	/* Create sockets for them to listen to. */
+	*psock = sock = talloc(talloc_autofree_context(), int);
+	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*sock < 0)
+		barf_perror("Could not create socket");
+	*pro_sock = ro_sock = talloc(talloc_autofree_context(), int);
+	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*ro_sock < 0)
+		barf_perror("Could not create socket");
+	talloc_set_destructor(sock, destroy_fd);
+	talloc_set_destructor(ro_sock, destroy_fd);
+
+	/* FIXME: Be more sophisticated, don't mug running daemon. */
+	unlink(xs_daemon_socket());
+	unlink(xs_daemon_socket_ro());
+
+	addr.sun_family = AF_UNIX;
+	strcpy(addr.sun_path, xs_daemon_socket());
+	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s", xs_daemon_socket());
+	strcpy(addr.sun_path, xs_daemon_socket_ro());
+	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s",
+			    xs_daemon_socket_ro());
+	if (chmod(xs_daemon_socket(), 0600) != 0
+	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
+		barf_perror("Could not chmod sockets");
+
+	if (listen(*sock, 1) != 0
+	    || listen(*ro_sock, 1) != 0)
+		barf_perror("Could not listen on sockets");
+
+
+}
 
 static void usage(void)
 {
@@ -1753,7 +1791,6 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
-	struct sockaddr_un addr;
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,40 +1874,10 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
-	/* Create sockets for them to listen to. */
-	sock = talloc(talloc_autofree_context(), int);
-	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*sock < 0)
-		barf_perror("Could not create socket");
-	ro_sock = talloc(talloc_autofree_context(), int);
-	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*ro_sock < 0)
-		barf_perror("Could not create socket");
-	talloc_set_destructor(sock, destroy_fd);
-	talloc_set_destructor(ro_sock, destroy_fd);
-
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
-	/* FIXME: Be more sophisticated, don't mug running daemon. */
-	unlink(xs_daemon_socket());
-	unlink(xs_daemon_socket_ro());
-
-	addr.sun_family = AF_UNIX;
-	strcpy(addr.sun_path, xs_daemon_socket());
-	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s", xs_daemon_socket());
-	strcpy(addr.sun_path, xs_daemon_socket_ro());
-	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s",
-			    xs_daemon_socket_ro());
-	if (chmod(xs_daemon_socket(), 0600) != 0
-	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
-		barf_perror("Could not chmod sockets");
-
-	if (listen(*sock, 1) != 0
-	    || listen(*ro_sock, 1) != 0)
-		barf_perror("Could not listen on sockets");
+	init_sockets(&sock, &ro_sock);
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVGU-0002F0-5l; Thu, 26 Jan 2012 19:45:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DW-Qw
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:44 +0000
Received: from [85.158.139.83:9759] by server-9.bemta-5.messagelabs.com id
	7B/9B-24580-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327607141!12512846!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20671 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeLe009016
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHv005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:02 -0500
Message-Id: <1327607111-15394-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 15/24] xenstored: refactor socket 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>
MIME-Version: 1.0
Content-Type: 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>
---
 tools/xenstore/xenstored_core.c |   85 +++++++++++++++++++++------------------
 1 files changed, 46 insertions(+), 39 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..0e7d43f 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -343,13 +343,6 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
-static int destroy_fd(void *_fd)
-{
-	int *fd = _fd;
-	close(*fd);
-	return 0;
-}
-
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
 {
@@ -1705,6 +1698,51 @@ static void daemonize(void)
 	umask(0);
 }
 
+static int destroy_fd(void *_fd)
+{
+	int *fd = _fd;
+	close(*fd);
+	return 0;
+}
+
+static void init_sockets(int **psock, int **pro_sock)
+{
+	struct sockaddr_un addr;
+	int *sock, *ro_sock;
+	/* Create sockets for them to listen to. */
+	*psock = sock = talloc(talloc_autofree_context(), int);
+	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*sock < 0)
+		barf_perror("Could not create socket");
+	*pro_sock = ro_sock = talloc(talloc_autofree_context(), int);
+	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*ro_sock < 0)
+		barf_perror("Could not create socket");
+	talloc_set_destructor(sock, destroy_fd);
+	talloc_set_destructor(ro_sock, destroy_fd);
+
+	/* FIXME: Be more sophisticated, don't mug running daemon. */
+	unlink(xs_daemon_socket());
+	unlink(xs_daemon_socket_ro());
+
+	addr.sun_family = AF_UNIX;
+	strcpy(addr.sun_path, xs_daemon_socket());
+	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s", xs_daemon_socket());
+	strcpy(addr.sun_path, xs_daemon_socket_ro());
+	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s",
+			    xs_daemon_socket_ro());
+	if (chmod(xs_daemon_socket(), 0600) != 0
+	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
+		barf_perror("Could not chmod sockets");
+
+	if (listen(*sock, 1) != 0
+	    || listen(*ro_sock, 1) != 0)
+		barf_perror("Could not listen on sockets");
+
+
+}
 
 static void usage(void)
 {
@@ -1753,7 +1791,6 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
-	struct sockaddr_un addr;
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,40 +1874,10 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
-	/* Create sockets for them to listen to. */
-	sock = talloc(talloc_autofree_context(), int);
-	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*sock < 0)
-		barf_perror("Could not create socket");
-	ro_sock = talloc(talloc_autofree_context(), int);
-	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*ro_sock < 0)
-		barf_perror("Could not create socket");
-	talloc_set_destructor(sock, destroy_fd);
-	talloc_set_destructor(ro_sock, destroy_fd);
-
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
-	/* FIXME: Be more sophisticated, don't mug running daemon. */
-	unlink(xs_daemon_socket());
-	unlink(xs_daemon_socket_ro());
-
-	addr.sun_family = AF_UNIX;
-	strcpy(addr.sun_path, xs_daemon_socket());
-	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s", xs_daemon_socket());
-	strcpy(addr.sun_path, xs_daemon_socket_ro());
-	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s",
-			    xs_daemon_socket_ro());
-	if (chmod(xs_daemon_socket(), 0600) != 0
-	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
-		barf_perror("Could not chmod sockets");
-
-	if (listen(*sock, 1) != 0
-	    || listen(*ro_sock, 1) != 0)
-		barf_perror("Could not listen on sockets");
+	init_sockets(&sock, &ro_sock);
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVGR-0002Dh-Gv; Thu, 26 Jan 2012 19:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGQ-0002D9-KV
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:42 +0000
Received: from [85.158.138.51:10139] by server-10.bemta-3.messagelabs.com id
	77/8D-20948-56DA12F4; Thu, 26 Jan 2012 19:45:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327607140!10819901!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27752 invoked from network); 26 Jan 2012 19:45:40 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45:40 -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
	q0QJjdLe009007
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHo005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:55 -0500
Message-Id: <1327607111-15394-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/24] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..af0afed 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+        if (!intf)
+            return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVGR-0002Dh-Gv; Thu, 26 Jan 2012 19:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGQ-0002D9-KV
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:42 +0000
Received: from [85.158.138.51:10139] by server-10.bemta-3.messagelabs.com id
	77/8D-20948-56DA12F4; Thu, 26 Jan 2012 19:45:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327607140!10819901!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27752 invoked from network); 26 Jan 2012 19:45:40 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-174.messagelabs.com with SMTP;
	26 Jan 2012 19:45:40 -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
	q0QJjdLe009007
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHo005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:55 -0500
Message-Id: <1327607111-15394-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/24] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..af0afed 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+        if (!intf)
+            return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGa-0002Lv-EN; Thu, 26 Jan 2012 19:45:52 +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 1RqVGX-0002E0-E8
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327607141!2775113!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24012 invoked from network); 26 Jan 2012 19:45:42 -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;
	26 Jan 2012 19:45:42 -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
	q0QJjeQG026854; Thu, 26 Jan 2012 19:45: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 q0QJjcHx005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:04 -0500
Message-Id: <1327607111-15394-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 17/24] xenstored: support for tdb_copy with
	TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
databases; this is required to run in mini-os which does not use a
filesystem.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/tdb.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..3ecd3fc 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,41 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+		return copy;
+intfail:
+		talloc_free(copy);
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGa-0002Lv-EN; Thu, 26 Jan 2012 19:45:52 +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 1RqVGX-0002E0-E8
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327607141!2775113!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24012 invoked from network); 26 Jan 2012 19:45:42 -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;
	26 Jan 2012 19:45:42 -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
	q0QJjeQG026854; Thu, 26 Jan 2012 19:45: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 q0QJjcHx005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:04 -0500
Message-Id: <1327607111-15394-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 17/24] xenstored: support for tdb_copy with
	TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
databases; this is required to run in mini-os which does not use a
filesystem.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/tdb.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..3ecd3fc 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,41 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+		return copy;
+intfail:
+		talloc_free(copy);
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGZ-0002Ke-Gv; Thu, 26 Jan 2012 19:45:51 +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 1RqVGW-0002Dd-Pl
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327607141!4184194!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15780 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjeLe009025
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI3005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:08 -0500
Message-Id: <1327607111-15394-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 21/24] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   11 +++++++++++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0b9d4f2..89b3422 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1822,6 +1822,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1836,6 +1837,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1898,6 +1900,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 4243f91..f525d65 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -604,6 +604,17 @@ void restore_existing_connections(void)
 #ifdef __MINIOS__
 static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGZ-0002Ke-Gv; Thu, 26 Jan 2012 19:45:51 +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 1RqVGW-0002Dd-Pl
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327607141!4184194!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15780 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjeLe009025
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI3005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:08 -0500
Message-Id: <1327607111-15394-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 21/24] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |   11 +++++++++++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0b9d4f2..89b3422 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1822,6 +1822,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1836,6 +1837,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1898,6 +1900,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..d3040ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 4243f91..f525d65 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -604,6 +604,17 @@ void restore_existing_connections(void)
 #ifdef __MINIOS__
 static int dom0_init(void)
 {
+	struct domain *domain;
+	int domid = 0;
+	evtchn_port_t port = dom0_event;
+
+	domain = new_domain(NULL, domid, port);
+	domain->interface = xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	talloc_steal(domain->conn, domain);
+
+	xc_evtchn_notify(xce_handle, domain->port);
+
 	return 0;
 }
 #else
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGS-0002EL-Uo; Thu, 26 Jan 2012 19:45:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DJ-6z
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:43 +0000
Received: from [85.158.139.83:52224] by server-12.bemta-5.messagelabs.com id
	AC/EA-18193-66DA12F4; Thu, 26 Jan 2012 19:45:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327607140!12534133!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13056 invoked from network); 26 Jan 2012 19:45: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;
	26 Jan 2012 19:45: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
	q0QJjdQG026844
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHm005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:53 -0500
Message-Id: <1327607111-15394-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/24] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..3828c62 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -64,6 +64,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -95,9 +96,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c8da45..965dbd0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -243,9 +243,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGa-0002MO-QD; Thu, 26 Jan 2012 19:45:52 +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 1RqVGX-0002Dx-90
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327607141!8787657!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27662 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeLe009008
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHr005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:58 -0500
Message-Id: <1327607111-15394-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 11/24] mini-os: Move test functions into test.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

While useful, these test functions should not be compiled into every
mini-os instance that we compile.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile |    1 +
 extras/mini-os/kernel.c |  414 -----------------------------------------
 extras/mini-os/test.c   |  469 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/c/minios.cfg    |    1 +
 stubdom/caml/minios.cfg |    1 +
 5 files changed, 472 insertions(+), 414 deletions(-)
 create mode 100644 extras/mini-os/test.c

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index be38170..96c661a 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -63,6 +63,7 @@ src-y += mm.c
 src-y += netfront.c
 src-y += pcifront.c
 src-y += sched.c
+src-$(CONFIG_TEST) += test.c
 
 src-y += lib/ctype.c
 src-y += lib/math.c
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index 2875bf1..c8b9b8c 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -46,8 +46,6 @@
 #include <xen/features.h>
 #include <xen/version.h>
 
-static struct netfront_dev *net_dev;
-
 uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
 
 void setup_xen_features(void)
@@ -66,407 +64,10 @@ void setup_xen_features(void)
     }
 }
 
-void test_xenbus(void);
-
-static void xenbus_tester(void *p)
-{
-    printk("Xenbus tests disabled, because of a Xend bug.\n");
-    /* test_xenbus(); */
-}
-
-static void periodic_thread(void *p)
-{
-    struct timeval tv;
-    printk("Periodic thread started.\n");
-    for(;;)
-    {
-        gettimeofday(&tv, NULL);
-        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
-        msleep(1000);
-    }
-}
-
-static void netfront_thread(void *p)
-{
-    net_dev = init_netfront(NULL, NULL, NULL, NULL);
-}
-
-static struct blkfront_dev *blk_dev;
-static struct blkfront_info blk_info;
-static uint64_t blk_size_read;
-static uint64_t blk_size_write;
-
-struct blk_req {
-    struct blkfront_aiocb aiocb;
-    int rand_value;
-    struct blk_req *next;
-};
-
-#ifdef BLKTEST_WRITE
-static struct blk_req *blk_to_read;
-#endif
-
-static struct blk_req *blk_alloc_req(uint64_t sector)
-{
-    struct blk_req *req = xmalloc(struct blk_req);
-    req->aiocb.aio_dev = blk_dev;
-    req->aiocb.aio_buf = _xmalloc(blk_info.sector_size, blk_info.sector_size);
-    req->aiocb.aio_nbytes = blk_info.sector_size;
-    req->aiocb.aio_offset = sector * blk_info.sector_size;
-    req->aiocb.data = req;
-    req->next = NULL;
-    return req;
-}
-
-static void blk_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret)
-        printk("got error code %d when reading at offset %ld\n", ret, aiocb->aio_offset);
-    else
-        blk_size_read += blk_info.sector_size;
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_read_sector(uint64_t sector)
-{
-    struct blk_req *req;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_read_completed;
-
-    blkfront_aio_read(&req->aiocb);
-}
-
-#ifdef BLKTEST_WRITE
-static void blk_write_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    int rand_value;
-    int i;
-    int *buf;
-
-    if (ret) {
-        printk("got error code %d when reading back at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_read += blk_info.sector_size;
-    buf = (int*) aiocb->aio_buf;
-    rand_value = req->rand_value;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        if (buf[i] != rand_value) {
-            printk("bogus data at offset %ld\n", aiocb->aio_offset + i);
-            break;
-        }
-        rand_value *= RAND_MIX;
-    }
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_write_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret) {
-        printk("got error code %d when writing at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_write += blk_info.sector_size;
-    /* Push write check */
-    req->next = blk_to_read;
-    blk_to_read = req;
-}
-
-static void blk_write_sector(uint64_t sector)
-{
-    struct blk_req *req;
-    int rand_value;
-    int i;
-    int *buf;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_write_completed;
-    req->rand_value = rand_value = rand();
-
-    buf = (int*) req->aiocb.aio_buf;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        buf[i] = rand_value;
-        rand_value *= RAND_MIX;
-    }
-
-    blkfront_aio_write(&req->aiocb);
-}
-#endif
-
-static void blkfront_thread(void *p)
-{
-    time_t lasttime = 0;
-
-    blk_dev = init_blkfront(NULL, &blk_info);
-    if (!blk_dev)
-        return;
-
-    if (blk_info.info & VDISK_CDROM)
-        printk("Block device is a CDROM\n");
-    if (blk_info.info & VDISK_REMOVABLE)
-        printk("Block device is removable\n");
-    if (blk_info.info & VDISK_READONLY)
-        printk("Block device is read-only\n");
-
-#ifdef BLKTEST_WRITE
-    if (blk_info.mode == O_RDWR) {
-        blk_write_sector(0);
-        blk_write_sector(blk_info.sectors-1);
-    } else
-#endif
-    {
-        blk_read_sector(0);
-        blk_read_sector(blk_info.sectors-1);
-    }
-
-    while (1) {
-        uint64_t sector = rand() % blk_info.sectors;
-        struct timeval tv;
-#ifdef BLKTEST_WRITE
-        if (blk_info.mode == O_RDWR)
-            blk_write_sector(sector);
-        else
-#endif
-            blk_read_sector(sector);
-        blkfront_aio_poll(blk_dev);
-        gettimeofday(&tv, NULL);
-        if (tv.tv_sec > lasttime + 10) {
-            printk("%llu read, %llu write\n", blk_size_read, blk_size_write);
-            lasttime = tv.tv_sec;
-        }
-
-#ifdef BLKTEST_WRITE
-        while (blk_to_read) {
-            struct blk_req *req = blk_to_read;
-            blk_to_read = blk_to_read->next;
-            req->aiocb.aio_cb = blk_write_read_completed;
-            blkfront_aio_read(&req->aiocb);
-        }
-#endif
-    }
-}
-
-#define WIDTH 800
-#define HEIGHT 600
-#define DEPTH 32
-
-static uint32_t *fb;
-static int refresh_period = 50;
-static struct fbfront_dev *fb_dev;
-static struct semaphore fbfront_sem = __SEMAPHORE_INITIALIZER(fbfront_sem, 0);
-
-static void fbfront_drawvert(int x, int y1, int y2, uint32_t color)
-{
-    int y;
-    if (x < 0)
-        return;
-    if (x >= WIDTH)
-        return;
-    if (y1 < 0)
-        y1 = 0;
-    if (y2 >= HEIGHT)
-        y2 = HEIGHT-1;
-    for (y = y1; y <= y2; y++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_drawhoriz(int x1, int x2, int y, uint32_t color)
-{
-    int x;
-    if (y < 0)
-        return;
-    if (y >= HEIGHT)
-        return;
-    if (x1 < 0)
-        x1 = 0;
-    if (x2 >= WIDTH)
-        x2 = WIDTH-1;
-    for (x = x1; x <= x2; x++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_thread(void *p)
-{
-    size_t line_length = WIDTH * (DEPTH / 8);
-    size_t memsize = HEIGHT * line_length;
-    unsigned long *mfns;
-    int i, n = (memsize + PAGE_SIZE-1) / PAGE_SIZE;
-
-    memsize = n * PAGE_SIZE;
-    fb = _xmalloc(memsize, PAGE_SIZE);
-    memset(fb, 0, memsize);
-    mfns = xmalloc_array(unsigned long, n);
-    for (i = 0; i < n; i++)
-        mfns[i] = virtual_to_mfn((char *) fb + i * PAGE_SIZE);
-    fb_dev = init_fbfront(NULL, mfns, WIDTH, HEIGHT, DEPTH, line_length, n);
-    xfree(mfns);
-    if (!fb_dev) {
-        xfree(fb);
-        return;
-    }
-    up(&fbfront_sem);
-}
-
-static void clip_cursor(int *x, int *y)
-{
-    if (*x < 0)
-        *x = 0;
-    if (*x >= WIDTH)
-        *x = WIDTH - 1;
-    if (*y < 0)
-        *y = 0;
-    if (*y >= HEIGHT)
-        *y = HEIGHT - 1;
-}
-
-static void refresh_cursor(int new_x, int new_y)
-{
-    static int old_x = -1, old_y = -1;
-
-    if (!refresh_period)
-        return;
-
-    if (old_x != -1 && old_y != -1) {
-        fbfront_drawvert(old_x, old_y + 1, old_y + 8, 0xffffffff);
-        fbfront_drawhoriz(old_x + 1, old_x + 8, old_y, 0xffffffff);
-        fbfront_update(fb_dev, old_x, old_y, 9, 9);
-    }
-    old_x = new_x;
-    old_y = new_y;
-    fbfront_drawvert(new_x, new_y + 1, new_y + 8, 0xffffffff);
-    fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
-    fbfront_update(fb_dev, new_x, new_y, 9, 9);
-}
-
-static struct kbdfront_dev *kbd_dev;
-static void kbdfront_thread(void *p)
-{
-    DEFINE_WAIT(w);
-    DEFINE_WAIT(w2);
-    int x = WIDTH / 2, y = HEIGHT / 2, z = 0;
-
-    kbd_dev = init_kbdfront(NULL, 1);
-    if (!kbd_dev)
-        return;
-
-    down(&fbfront_sem);
-    refresh_cursor(x, y);
-    while (1) {
-        union xenkbd_in_event kbdevent;
-        union xenfb_in_event fbevent;
-        int sleep = 1;
-
-        add_waiter(w, kbdfront_queue);
-        add_waiter(w2, fbfront_queue);
-
-        while (kbdfront_receive(kbd_dev, &kbdevent, 1) != 0) {
-            sleep = 0;
-            switch(kbdevent.type) {
-            case XENKBD_TYPE_MOTION:
-                printk("motion x:%d y:%d z:%d\n",
-                        kbdevent.motion.rel_x,
-                        kbdevent.motion.rel_y,
-                        kbdevent.motion.rel_z);
-                x += kbdevent.motion.rel_x;
-                y += kbdevent.motion.rel_y;
-                z += kbdevent.motion.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_POS:
-                printk("pos x:%d y:%d dz:%d\n",
-                        kbdevent.pos.abs_x,
-                        kbdevent.pos.abs_y,
-                        kbdevent.pos.rel_z);
-                x = kbdevent.pos.abs_x;
-                y = kbdevent.pos.abs_y;
-                z = kbdevent.pos.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_KEY:
-                printk("key %d %s\n",
-                        kbdevent.key.keycode,
-                        kbdevent.key.pressed ? "pressed" : "released");
-                if (kbdevent.key.keycode == BTN_LEFT) {
-                    printk("mouse %s at (%d,%d,%d)\n",
-                            kbdevent.key.pressed ? "clic" : "release", x, y, z);
-                    if (kbdevent.key.pressed) {
-                        uint32_t color = rand();
-                        fbfront_drawvert(x - 16, y - 16, y + 15, color);
-                        fbfront_drawhoriz(x - 16, x + 15, y + 16, color);
-                        fbfront_drawvert(x + 16, y - 15, y + 16, color);
-                        fbfront_drawhoriz(x - 15, x + 16, y - 16, color);
-                        fbfront_update(fb_dev, x - 16, y - 16, 33, 33);
-                    }
-                } else if (kbdevent.key.keycode == KEY_Q) {
-                    struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_poweroff };
-                    HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-                    do_exit();
-                }
-                break;
-            }
-        }
-        while (fbfront_receive(fb_dev, &fbevent, 1) != 0) {
-            sleep = 0;
-            switch(fbevent.type) {
-            case XENFB_TYPE_REFRESH_PERIOD:
-                refresh_period = fbevent.refresh_period.period;
-                printk("refresh period %d\n", refresh_period);
-                refresh_cursor(x, y);
-                break;
-            }
-        }
-        if (sleep)
-            schedule();
-    }
-}
-
-static struct pcifront_dev *pci_dev;
-
-static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
-{
-    unsigned int vendor, device, rev, class;
-
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x00, 2, &vendor);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x02, 2, &device);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x08, 1, &rev);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x0a, 2, &class);
-
-    printk("%04x:%02x:%02x.%02x %04x: %04x:%04x (rev %02x)\n", domain, bus, slot, fun, class, vendor, device, rev);
-}
-
-static void pcifront_thread(void *p)
-{
-    pcifront_watches(NULL);
-    pci_dev = init_pcifront(NULL);
-    if (!pci_dev)
-        return;
-    printk("PCI devices:\n");
-    pcifront_scan(pci_dev, print_pcidev);
-}
-
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
 {
     printk("Dummy main: start_info=%p\n", si);
-    create_thread("xenbus_tester", xenbus_tester, si);
-    create_thread("periodic_thread", periodic_thread, si);
-    create_thread("netfront", netfront_thread, si);
-    create_thread("blkfront", blkfront_thread, si);
-    create_thread("fbfront", fbfront_thread, si);
-    create_thread("kbdfront", kbdfront_thread, si);
-    create_thread("pcifront", pcifront_thread, si);
     return 0;
 }
 
@@ -534,21 +135,6 @@ void start_kernel(start_info_t *si)
 
 void stop_kernel(void)
 {
-    if (net_dev)
-        shutdown_netfront(net_dev);
-
-    if (blk_dev)
-        shutdown_blkfront(blk_dev);
-
-    if (fb_dev)
-        shutdown_fbfront(fb_dev);
-
-    if (kbd_dev)
-        shutdown_kbdfront(kbd_dev);
-
-    if (pci_dev)
-        shutdown_pcifront(pci_dev);
-
     /* TODO: fs import */
 
     local_irq_disable();
diff --git a/extras/mini-os/test.c b/extras/mini-os/test.c
new file mode 100644
index 0000000..9039cb3
--- /dev/null
+++ b/extras/mini-os/test.c
@@ -0,0 +1,469 @@
+/******************************************************************************
+ * test.c
+ * 
+ * Test code for all the various frontends; split from kernel.c
+ * 
+ * Copyright (c) 2002-2003, K A Fraser & R Neugebauer
+ * Copyright (c) 2005, Grzegorz Milos, Intel Research Cambridge
+ * Copyright (c) 2006, Robert Kaiser, FH Wiesbaden
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ * 
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ * 
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include <mini-os/os.h>
+#include <mini-os/hypervisor.h>
+#include <mini-os/mm.h>
+#include <mini-os/events.h>
+#include <mini-os/time.h>
+#include <mini-os/types.h>
+#include <mini-os/lib.h>
+#include <mini-os/sched.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/gnttab.h>
+#include <mini-os/netfront.h>
+#include <mini-os/blkfront.h>
+#include <mini-os/fbfront.h>
+#include <mini-os/pcifront.h>
+#include <mini-os/xmalloc.h>
+#include <fcntl.h>
+#include <xen/features.h>
+#include <xen/version.h>
+
+static struct netfront_dev *net_dev;
+
+void test_xenbus(void);
+
+static void xenbus_tester(void *p)
+{
+    printk("Xenbus tests disabled, because of a Xend bug.\n");
+    /* test_xenbus(); */
+}
+
+static void periodic_thread(void *p)
+{
+    struct timeval tv;
+    printk("Periodic thread started.\n");
+    for(;;)
+    {
+        gettimeofday(&tv, NULL);
+        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
+        msleep(1000);
+    }
+}
+
+static void netfront_thread(void *p)
+{
+    net_dev = init_netfront(NULL, NULL, NULL, NULL);
+}
+
+static struct blkfront_dev *blk_dev;
+static struct blkfront_info blk_info;
+static uint64_t blk_size_read;
+static uint64_t blk_size_write;
+
+struct blk_req {
+    struct blkfront_aiocb aiocb;
+    int rand_value;
+    struct blk_req *next;
+};
+
+#ifdef BLKTEST_WRITE
+static struct blk_req *blk_to_read;
+#endif
+
+static struct blk_req *blk_alloc_req(uint64_t sector)
+{
+    struct blk_req *req = xmalloc(struct blk_req);
+    req->aiocb.aio_dev = blk_dev;
+    req->aiocb.aio_buf = _xmalloc(blk_info.sector_size, blk_info.sector_size);
+    req->aiocb.aio_nbytes = blk_info.sector_size;
+    req->aiocb.aio_offset = sector * blk_info.sector_size;
+    req->aiocb.data = req;
+    req->next = NULL;
+    return req;
+}
+
+static void blk_read_completed(struct blkfront_aiocb *aiocb, int ret)
+{
+    struct blk_req *req = aiocb->data;
+    if (ret)
+        printk("got error code %d when reading at offset %ld\n", ret, aiocb->aio_offset);
+    else
+        blk_size_read += blk_info.sector_size;
+    free(aiocb->aio_buf);
+    free(req);
+}
+
+static void blk_read_sector(uint64_t sector)
+{
+    struct blk_req *req;
+
+    req = blk_alloc_req(sector);
+    req->aiocb.aio_cb = blk_read_completed;
+
+    blkfront_aio_read(&req->aiocb);
+}
+
+#ifdef BLKTEST_WRITE
+static void blk_write_read_completed(struct blkfront_aiocb *aiocb, int ret)
+{
+    struct blk_req *req = aiocb->data;
+    int rand_value;
+    int i;
+    int *buf;
+
+    if (ret) {
+        printk("got error code %d when reading back at offset %ld\n", ret, aiocb->aio_offset);
+        free(aiocb->aio_buf);
+        free(req);
+        return;
+    }
+    blk_size_read += blk_info.sector_size;
+    buf = (int*) aiocb->aio_buf;
+    rand_value = req->rand_value;
+    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
+        if (buf[i] != rand_value) {
+            printk("bogus data at offset %ld\n", aiocb->aio_offset + i);
+            break;
+        }
+        rand_value *= RAND_MIX;
+    }
+    free(aiocb->aio_buf);
+    free(req);
+}
+
+static void blk_write_completed(struct blkfront_aiocb *aiocb, int ret)
+{
+    struct blk_req *req = aiocb->data;
+    if (ret) {
+        printk("got error code %d when writing at offset %ld\n", ret, aiocb->aio_offset);
+        free(aiocb->aio_buf);
+        free(req);
+        return;
+    }
+    blk_size_write += blk_info.sector_size;
+    /* Push write check */
+    req->next = blk_to_read;
+    blk_to_read = req;
+}
+
+static void blk_write_sector(uint64_t sector)
+{
+    struct blk_req *req;
+    int rand_value;
+    int i;
+    int *buf;
+
+    req = blk_alloc_req(sector);
+    req->aiocb.aio_cb = blk_write_completed;
+    req->rand_value = rand_value = rand();
+
+    buf = (int*) req->aiocb.aio_buf;
+    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
+        buf[i] = rand_value;
+        rand_value *= RAND_MIX;
+    }
+
+    blkfront_aio_write(&req->aiocb);
+}
+#endif
+
+static void blkfront_thread(void *p)
+{
+    time_t lasttime = 0;
+
+    blk_dev = init_blkfront(NULL, &blk_info);
+    if (!blk_dev)
+        return;
+
+    if (blk_info.info & VDISK_CDROM)
+        printk("Block device is a CDROM\n");
+    if (blk_info.info & VDISK_REMOVABLE)
+        printk("Block device is removable\n");
+    if (blk_info.info & VDISK_READONLY)
+        printk("Block device is read-only\n");
+
+#ifdef BLKTEST_WRITE
+    if (blk_info.mode == O_RDWR) {
+        blk_write_sector(0);
+        blk_write_sector(blk_info.sectors-1);
+    } else
+#endif
+    {
+        blk_read_sector(0);
+        blk_read_sector(blk_info.sectors-1);
+    }
+
+    while (1) {
+        uint64_t sector = rand() % blk_info.sectors;
+        struct timeval tv;
+#ifdef BLKTEST_WRITE
+        if (blk_info.mode == O_RDWR)
+            blk_write_sector(sector);
+        else
+#endif
+            blk_read_sector(sector);
+        blkfront_aio_poll(blk_dev);
+        gettimeofday(&tv, NULL);
+        if (tv.tv_sec > lasttime + 10) {
+            printk("%llu read, %llu write\n", blk_size_read, blk_size_write);
+            lasttime = tv.tv_sec;
+        }
+
+#ifdef BLKTEST_WRITE
+        while (blk_to_read) {
+            struct blk_req *req = blk_to_read;
+            blk_to_read = blk_to_read->next;
+            req->aiocb.aio_cb = blk_write_read_completed;
+            blkfront_aio_read(&req->aiocb);
+        }
+#endif
+    }
+}
+
+#define WIDTH 800
+#define HEIGHT 600
+#define DEPTH 32
+
+static uint32_t *fb;
+static int refresh_period = 50;
+static struct fbfront_dev *fb_dev;
+static struct semaphore fbfront_sem = __SEMAPHORE_INITIALIZER(fbfront_sem, 0);
+
+static void fbfront_drawvert(int x, int y1, int y2, uint32_t color)
+{
+    int y;
+    if (x < 0)
+        return;
+    if (x >= WIDTH)
+        return;
+    if (y1 < 0)
+        y1 = 0;
+    if (y2 >= HEIGHT)
+        y2 = HEIGHT-1;
+    for (y = y1; y <= y2; y++)
+        fb[x + y*WIDTH] ^= color;
+}
+
+static void fbfront_drawhoriz(int x1, int x2, int y, uint32_t color)
+{
+    int x;
+    if (y < 0)
+        return;
+    if (y >= HEIGHT)
+        return;
+    if (x1 < 0)
+        x1 = 0;
+    if (x2 >= WIDTH)
+        x2 = WIDTH-1;
+    for (x = x1; x <= x2; x++)
+        fb[x + y*WIDTH] ^= color;
+}
+
+static void fbfront_thread(void *p)
+{
+    size_t line_length = WIDTH * (DEPTH / 8);
+    size_t memsize = HEIGHT * line_length;
+    unsigned long *mfns;
+    int i, n = (memsize + PAGE_SIZE-1) / PAGE_SIZE;
+
+    memsize = n * PAGE_SIZE;
+    fb = _xmalloc(memsize, PAGE_SIZE);
+    memset(fb, 0, memsize);
+    mfns = xmalloc_array(unsigned long, n);
+    for (i = 0; i < n; i++)
+        mfns[i] = virtual_to_mfn((char *) fb + i * PAGE_SIZE);
+    fb_dev = init_fbfront(NULL, mfns, WIDTH, HEIGHT, DEPTH, line_length, n);
+    xfree(mfns);
+    if (!fb_dev) {
+        xfree(fb);
+        return;
+    }
+    up(&fbfront_sem);
+}
+
+static void clip_cursor(int *x, int *y)
+{
+    if (*x < 0)
+        *x = 0;
+    if (*x >= WIDTH)
+        *x = WIDTH - 1;
+    if (*y < 0)
+        *y = 0;
+    if (*y >= HEIGHT)
+        *y = HEIGHT - 1;
+}
+
+static void refresh_cursor(int new_x, int new_y)
+{
+    static int old_x = -1, old_y = -1;
+
+    if (!refresh_period)
+        return;
+
+    if (old_x != -1 && old_y != -1) {
+        fbfront_drawvert(old_x, old_y + 1, old_y + 8, 0xffffffff);
+        fbfront_drawhoriz(old_x + 1, old_x + 8, old_y, 0xffffffff);
+        fbfront_update(fb_dev, old_x, old_y, 9, 9);
+    }
+    old_x = new_x;
+    old_y = new_y;
+    fbfront_drawvert(new_x, new_y + 1, new_y + 8, 0xffffffff);
+    fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
+    fbfront_update(fb_dev, new_x, new_y, 9, 9);
+}
+
+static struct kbdfront_dev *kbd_dev;
+static void kbdfront_thread(void *p)
+{
+    DEFINE_WAIT(w);
+    DEFINE_WAIT(w2);
+    int x = WIDTH / 2, y = HEIGHT / 2, z = 0;
+
+    kbd_dev = init_kbdfront(NULL, 1);
+    if (!kbd_dev)
+        return;
+
+    down(&fbfront_sem);
+    refresh_cursor(x, y);
+    while (1) {
+        union xenkbd_in_event kbdevent;
+        union xenfb_in_event fbevent;
+        int sleep = 1;
+
+        add_waiter(w, kbdfront_queue);
+        add_waiter(w2, fbfront_queue);
+
+        while (kbdfront_receive(kbd_dev, &kbdevent, 1) != 0) {
+            sleep = 0;
+            switch(kbdevent.type) {
+            case XENKBD_TYPE_MOTION:
+                printk("motion x:%d y:%d z:%d\n",
+                        kbdevent.motion.rel_x,
+                        kbdevent.motion.rel_y,
+                        kbdevent.motion.rel_z);
+                x += kbdevent.motion.rel_x;
+                y += kbdevent.motion.rel_y;
+                z += kbdevent.motion.rel_z;
+                clip_cursor(&x, &y);
+                refresh_cursor(x, y);
+                break;
+            case XENKBD_TYPE_POS:
+                printk("pos x:%d y:%d dz:%d\n",
+                        kbdevent.pos.abs_x,
+                        kbdevent.pos.abs_y,
+                        kbdevent.pos.rel_z);
+                x = kbdevent.pos.abs_x;
+                y = kbdevent.pos.abs_y;
+                z = kbdevent.pos.rel_z;
+                clip_cursor(&x, &y);
+                refresh_cursor(x, y);
+                break;
+            case XENKBD_TYPE_KEY:
+                printk("key %d %s\n",
+                        kbdevent.key.keycode,
+                        kbdevent.key.pressed ? "pressed" : "released");
+                if (kbdevent.key.keycode == BTN_LEFT) {
+                    printk("mouse %s at (%d,%d,%d)\n",
+                            kbdevent.key.pressed ? "clic" : "release", x, y, z);
+                    if (kbdevent.key.pressed) {
+                        uint32_t color = rand();
+                        fbfront_drawvert(x - 16, y - 16, y + 15, color);
+                        fbfront_drawhoriz(x - 16, x + 15, y + 16, color);
+                        fbfront_drawvert(x + 16, y - 15, y + 16, color);
+                        fbfront_drawhoriz(x - 15, x + 16, y - 16, color);
+                        fbfront_update(fb_dev, x - 16, y - 16, 33, 33);
+                    }
+                } else if (kbdevent.key.keycode == KEY_Q) {
+                    struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_poweroff };
+                    HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
+                    do_exit();
+                }
+                break;
+            }
+        }
+        while (fbfront_receive(fb_dev, &fbevent, 1) != 0) {
+            sleep = 0;
+            switch(fbevent.type) {
+            case XENFB_TYPE_REFRESH_PERIOD:
+                refresh_period = fbevent.refresh_period.period;
+                printk("refresh period %d\n", refresh_period);
+                refresh_cursor(x, y);
+                break;
+            }
+        }
+        if (sleep)
+            schedule();
+    }
+}
+
+static struct pcifront_dev *pci_dev;
+
+static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
+{
+    unsigned int vendor, device, rev, class;
+
+    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x00, 2, &vendor);
+    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x02, 2, &device);
+    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x08, 1, &rev);
+    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x0a, 2, &class);
+
+    printk("%04x:%02x:%02x.%02x %04x: %04x:%04x (rev %02x)\n", domain, bus, slot, fun, class, vendor, device, rev);
+}
+
+static void pcifront_thread(void *p)
+{
+    pcifront_watches(NULL);
+    pci_dev = init_pcifront(NULL);
+    if (!pci_dev)
+        return;
+    printk("PCI devices:\n");
+    pcifront_scan(pci_dev, print_pcidev);
+}
+
+int app_main(start_info_t *si)
+{
+    printk("Test main: start_info=%p\n", si);
+    create_thread("xenbus_tester", xenbus_tester, si);
+    create_thread("periodic_thread", periodic_thread, si);
+    create_thread("netfront", netfront_thread, si);
+    create_thread("blkfront", blkfront_thread, si);
+    create_thread("fbfront", fbfront_thread, si);
+    create_thread("kbdfront", kbdfront_thread, si);
+    create_thread("pcifront", pcifront_thread, si);
+    return 0;
+}
+
+void shutdown_frontends(void)
+{
+    if (net_dev)
+        shutdown_netfront(net_dev);
+
+    if (blk_dev)
+        shutdown_blkfront(blk_dev);
+
+    if (fb_dev)
+        shutdown_fbfront(fb_dev);
+
+    if (kbd_dev)
+        shutdown_kbdfront(kbd_dev);
+
+    if (pci_dev)
+        shutdown_pcifront(pci_dev);
+}
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/c/minios.cfg
+++ b/stubdom/c/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/caml/minios.cfg
+++ b/stubdom/caml/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGZ-0002K8-40; Thu, 26 Jan 2012 19:45:51 +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 1RqVGW-0002DT-GA
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327607141!12701929!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22653 invoked from network); 26 Jan 2012 19:45:42 -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;
	26 Jan 2012 19:45:42 -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
	q0QJjeLe009026
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI4005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:09 -0500
Message-Id: <1327607111-15394-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 22/24] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 89b3422..f254947 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -462,7 +462,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -800,11 +800,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index f525d65..22fe126b 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -358,7 +358,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -422,7 +422,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -474,7 +474,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -511,7 +511,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGa-0002MO-QD; Thu, 26 Jan 2012 19:45:52 +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 1RqVGX-0002Dx-90
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327607141!8787657!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27662 invoked from network); 26 Jan 2012 19:45:41 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-21.messagelabs.com with SMTP;
	26 Jan 2012 19:45: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
	q0QJjeLe009008
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHr005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:58 -0500
Message-Id: <1327607111-15394-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 11/24] mini-os: Move test functions into test.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

While useful, these test functions should not be compiled into every
mini-os instance that we compile.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 extras/mini-os/Makefile |    1 +
 extras/mini-os/kernel.c |  414 -----------------------------------------
 extras/mini-os/test.c   |  469 +++++++++++++++++++++++++++++++++++++++++++++++
 stubdom/c/minios.cfg    |    1 +
 stubdom/caml/minios.cfg |    1 +
 5 files changed, 472 insertions(+), 414 deletions(-)
 create mode 100644 extras/mini-os/test.c

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index be38170..96c661a 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -63,6 +63,7 @@ src-y += mm.c
 src-y += netfront.c
 src-y += pcifront.c
 src-y += sched.c
+src-$(CONFIG_TEST) += test.c
 
 src-y += lib/ctype.c
 src-y += lib/math.c
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index 2875bf1..c8b9b8c 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -46,8 +46,6 @@
 #include <xen/features.h>
 #include <xen/version.h>
 
-static struct netfront_dev *net_dev;
-
 uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
 
 void setup_xen_features(void)
@@ -66,407 +64,10 @@ void setup_xen_features(void)
     }
 }
 
-void test_xenbus(void);
-
-static void xenbus_tester(void *p)
-{
-    printk("Xenbus tests disabled, because of a Xend bug.\n");
-    /* test_xenbus(); */
-}
-
-static void periodic_thread(void *p)
-{
-    struct timeval tv;
-    printk("Periodic thread started.\n");
-    for(;;)
-    {
-        gettimeofday(&tv, NULL);
-        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
-        msleep(1000);
-    }
-}
-
-static void netfront_thread(void *p)
-{
-    net_dev = init_netfront(NULL, NULL, NULL, NULL);
-}
-
-static struct blkfront_dev *blk_dev;
-static struct blkfront_info blk_info;
-static uint64_t blk_size_read;
-static uint64_t blk_size_write;
-
-struct blk_req {
-    struct blkfront_aiocb aiocb;
-    int rand_value;
-    struct blk_req *next;
-};
-
-#ifdef BLKTEST_WRITE
-static struct blk_req *blk_to_read;
-#endif
-
-static struct blk_req *blk_alloc_req(uint64_t sector)
-{
-    struct blk_req *req = xmalloc(struct blk_req);
-    req->aiocb.aio_dev = blk_dev;
-    req->aiocb.aio_buf = _xmalloc(blk_info.sector_size, blk_info.sector_size);
-    req->aiocb.aio_nbytes = blk_info.sector_size;
-    req->aiocb.aio_offset = sector * blk_info.sector_size;
-    req->aiocb.data = req;
-    req->next = NULL;
-    return req;
-}
-
-static void blk_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret)
-        printk("got error code %d when reading at offset %ld\n", ret, aiocb->aio_offset);
-    else
-        blk_size_read += blk_info.sector_size;
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_read_sector(uint64_t sector)
-{
-    struct blk_req *req;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_read_completed;
-
-    blkfront_aio_read(&req->aiocb);
-}
-
-#ifdef BLKTEST_WRITE
-static void blk_write_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    int rand_value;
-    int i;
-    int *buf;
-
-    if (ret) {
-        printk("got error code %d when reading back at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_read += blk_info.sector_size;
-    buf = (int*) aiocb->aio_buf;
-    rand_value = req->rand_value;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        if (buf[i] != rand_value) {
-            printk("bogus data at offset %ld\n", aiocb->aio_offset + i);
-            break;
-        }
-        rand_value *= RAND_MIX;
-    }
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_write_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret) {
-        printk("got error code %d when writing at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_write += blk_info.sector_size;
-    /* Push write check */
-    req->next = blk_to_read;
-    blk_to_read = req;
-}
-
-static void blk_write_sector(uint64_t sector)
-{
-    struct blk_req *req;
-    int rand_value;
-    int i;
-    int *buf;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_write_completed;
-    req->rand_value = rand_value = rand();
-
-    buf = (int*) req->aiocb.aio_buf;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        buf[i] = rand_value;
-        rand_value *= RAND_MIX;
-    }
-
-    blkfront_aio_write(&req->aiocb);
-}
-#endif
-
-static void blkfront_thread(void *p)
-{
-    time_t lasttime = 0;
-
-    blk_dev = init_blkfront(NULL, &blk_info);
-    if (!blk_dev)
-        return;
-
-    if (blk_info.info & VDISK_CDROM)
-        printk("Block device is a CDROM\n");
-    if (blk_info.info & VDISK_REMOVABLE)
-        printk("Block device is removable\n");
-    if (blk_info.info & VDISK_READONLY)
-        printk("Block device is read-only\n");
-
-#ifdef BLKTEST_WRITE
-    if (blk_info.mode == O_RDWR) {
-        blk_write_sector(0);
-        blk_write_sector(blk_info.sectors-1);
-    } else
-#endif
-    {
-        blk_read_sector(0);
-        blk_read_sector(blk_info.sectors-1);
-    }
-
-    while (1) {
-        uint64_t sector = rand() % blk_info.sectors;
-        struct timeval tv;
-#ifdef BLKTEST_WRITE
-        if (blk_info.mode == O_RDWR)
-            blk_write_sector(sector);
-        else
-#endif
-            blk_read_sector(sector);
-        blkfront_aio_poll(blk_dev);
-        gettimeofday(&tv, NULL);
-        if (tv.tv_sec > lasttime + 10) {
-            printk("%llu read, %llu write\n", blk_size_read, blk_size_write);
-            lasttime = tv.tv_sec;
-        }
-
-#ifdef BLKTEST_WRITE
-        while (blk_to_read) {
-            struct blk_req *req = blk_to_read;
-            blk_to_read = blk_to_read->next;
-            req->aiocb.aio_cb = blk_write_read_completed;
-            blkfront_aio_read(&req->aiocb);
-        }
-#endif
-    }
-}
-
-#define WIDTH 800
-#define HEIGHT 600
-#define DEPTH 32
-
-static uint32_t *fb;
-static int refresh_period = 50;
-static struct fbfront_dev *fb_dev;
-static struct semaphore fbfront_sem = __SEMAPHORE_INITIALIZER(fbfront_sem, 0);
-
-static void fbfront_drawvert(int x, int y1, int y2, uint32_t color)
-{
-    int y;
-    if (x < 0)
-        return;
-    if (x >= WIDTH)
-        return;
-    if (y1 < 0)
-        y1 = 0;
-    if (y2 >= HEIGHT)
-        y2 = HEIGHT-1;
-    for (y = y1; y <= y2; y++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_drawhoriz(int x1, int x2, int y, uint32_t color)
-{
-    int x;
-    if (y < 0)
-        return;
-    if (y >= HEIGHT)
-        return;
-    if (x1 < 0)
-        x1 = 0;
-    if (x2 >= WIDTH)
-        x2 = WIDTH-1;
-    for (x = x1; x <= x2; x++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_thread(void *p)
-{
-    size_t line_length = WIDTH * (DEPTH / 8);
-    size_t memsize = HEIGHT * line_length;
-    unsigned long *mfns;
-    int i, n = (memsize + PAGE_SIZE-1) / PAGE_SIZE;
-
-    memsize = n * PAGE_SIZE;
-    fb = _xmalloc(memsize, PAGE_SIZE);
-    memset(fb, 0, memsize);
-    mfns = xmalloc_array(unsigned long, n);
-    for (i = 0; i < n; i++)
-        mfns[i] = virtual_to_mfn((char *) fb + i * PAGE_SIZE);
-    fb_dev = init_fbfront(NULL, mfns, WIDTH, HEIGHT, DEPTH, line_length, n);
-    xfree(mfns);
-    if (!fb_dev) {
-        xfree(fb);
-        return;
-    }
-    up(&fbfront_sem);
-}
-
-static void clip_cursor(int *x, int *y)
-{
-    if (*x < 0)
-        *x = 0;
-    if (*x >= WIDTH)
-        *x = WIDTH - 1;
-    if (*y < 0)
-        *y = 0;
-    if (*y >= HEIGHT)
-        *y = HEIGHT - 1;
-}
-
-static void refresh_cursor(int new_x, int new_y)
-{
-    static int old_x = -1, old_y = -1;
-
-    if (!refresh_period)
-        return;
-
-    if (old_x != -1 && old_y != -1) {
-        fbfront_drawvert(old_x, old_y + 1, old_y + 8, 0xffffffff);
-        fbfront_drawhoriz(old_x + 1, old_x + 8, old_y, 0xffffffff);
-        fbfront_update(fb_dev, old_x, old_y, 9, 9);
-    }
-    old_x = new_x;
-    old_y = new_y;
-    fbfront_drawvert(new_x, new_y + 1, new_y + 8, 0xffffffff);
-    fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
-    fbfront_update(fb_dev, new_x, new_y, 9, 9);
-}
-
-static struct kbdfront_dev *kbd_dev;
-static void kbdfront_thread(void *p)
-{
-    DEFINE_WAIT(w);
-    DEFINE_WAIT(w2);
-    int x = WIDTH / 2, y = HEIGHT / 2, z = 0;
-
-    kbd_dev = init_kbdfront(NULL, 1);
-    if (!kbd_dev)
-        return;
-
-    down(&fbfront_sem);
-    refresh_cursor(x, y);
-    while (1) {
-        union xenkbd_in_event kbdevent;
-        union xenfb_in_event fbevent;
-        int sleep = 1;
-
-        add_waiter(w, kbdfront_queue);
-        add_waiter(w2, fbfront_queue);
-
-        while (kbdfront_receive(kbd_dev, &kbdevent, 1) != 0) {
-            sleep = 0;
-            switch(kbdevent.type) {
-            case XENKBD_TYPE_MOTION:
-                printk("motion x:%d y:%d z:%d\n",
-                        kbdevent.motion.rel_x,
-                        kbdevent.motion.rel_y,
-                        kbdevent.motion.rel_z);
-                x += kbdevent.motion.rel_x;
-                y += kbdevent.motion.rel_y;
-                z += kbdevent.motion.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_POS:
-                printk("pos x:%d y:%d dz:%d\n",
-                        kbdevent.pos.abs_x,
-                        kbdevent.pos.abs_y,
-                        kbdevent.pos.rel_z);
-                x = kbdevent.pos.abs_x;
-                y = kbdevent.pos.abs_y;
-                z = kbdevent.pos.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_KEY:
-                printk("key %d %s\n",
-                        kbdevent.key.keycode,
-                        kbdevent.key.pressed ? "pressed" : "released");
-                if (kbdevent.key.keycode == BTN_LEFT) {
-                    printk("mouse %s at (%d,%d,%d)\n",
-                            kbdevent.key.pressed ? "clic" : "release", x, y, z);
-                    if (kbdevent.key.pressed) {
-                        uint32_t color = rand();
-                        fbfront_drawvert(x - 16, y - 16, y + 15, color);
-                        fbfront_drawhoriz(x - 16, x + 15, y + 16, color);
-                        fbfront_drawvert(x + 16, y - 15, y + 16, color);
-                        fbfront_drawhoriz(x - 15, x + 16, y - 16, color);
-                        fbfront_update(fb_dev, x - 16, y - 16, 33, 33);
-                    }
-                } else if (kbdevent.key.keycode == KEY_Q) {
-                    struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_poweroff };
-                    HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-                    do_exit();
-                }
-                break;
-            }
-        }
-        while (fbfront_receive(fb_dev, &fbevent, 1) != 0) {
-            sleep = 0;
-            switch(fbevent.type) {
-            case XENFB_TYPE_REFRESH_PERIOD:
-                refresh_period = fbevent.refresh_period.period;
-                printk("refresh period %d\n", refresh_period);
-                refresh_cursor(x, y);
-                break;
-            }
-        }
-        if (sleep)
-            schedule();
-    }
-}
-
-static struct pcifront_dev *pci_dev;
-
-static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
-{
-    unsigned int vendor, device, rev, class;
-
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x00, 2, &vendor);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x02, 2, &device);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x08, 1, &rev);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x0a, 2, &class);
-
-    printk("%04x:%02x:%02x.%02x %04x: %04x:%04x (rev %02x)\n", domain, bus, slot, fun, class, vendor, device, rev);
-}
-
-static void pcifront_thread(void *p)
-{
-    pcifront_watches(NULL);
-    pci_dev = init_pcifront(NULL);
-    if (!pci_dev)
-        return;
-    printk("PCI devices:\n");
-    pcifront_scan(pci_dev, print_pcidev);
-}
-
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
 {
     printk("Dummy main: start_info=%p\n", si);
-    create_thread("xenbus_tester", xenbus_tester, si);
-    create_thread("periodic_thread", periodic_thread, si);
-    create_thread("netfront", netfront_thread, si);
-    create_thread("blkfront", blkfront_thread, si);
-    create_thread("fbfront", fbfront_thread, si);
-    create_thread("kbdfront", kbdfront_thread, si);
-    create_thread("pcifront", pcifront_thread, si);
     return 0;
 }
 
@@ -534,21 +135,6 @@ void start_kernel(start_info_t *si)
 
 void stop_kernel(void)
 {
-    if (net_dev)
-        shutdown_netfront(net_dev);
-
-    if (blk_dev)
-        shutdown_blkfront(blk_dev);
-
-    if (fb_dev)
-        shutdown_fbfront(fb_dev);
-
-    if (kbd_dev)
-        shutdown_kbdfront(kbd_dev);
-
-    if (pci_dev)
-        shutdown_pcifront(pci_dev);
-
     /* TODO: fs import */
 
     local_irq_disable();
diff --git a/extras/mini-os/test.c b/extras/mini-os/test.c
new file mode 100644
index 0000000..9039cb3
--- /dev/null
+++ b/extras/mini-os/test.c
@@ -0,0 +1,469 @@
+/******************************************************************************
+ * test.c
+ * 
+ * Test code for all the various frontends; split from kernel.c
+ * 
+ * Copyright (c) 2002-2003, K A Fraser & R Neugebauer
+ * Copyright (c) 2005, Grzegorz Milos, Intel Research Cambridge
+ * Copyright (c) 2006, Robert Kaiser, FH Wiesbaden
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ * 
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ * 
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include <mini-os/os.h>
+#include <mini-os/hypervisor.h>
+#include <mini-os/mm.h>
+#include <mini-os/events.h>
+#include <mini-os/time.h>
+#include <mini-os/types.h>
+#include <mini-os/lib.h>
+#include <mini-os/sched.h>
+#include <mini-os/xenbus.h>
+#include <mini-os/gnttab.h>
+#include <mini-os/netfront.h>
+#include <mini-os/blkfront.h>
+#include <mini-os/fbfront.h>
+#include <mini-os/pcifront.h>
+#include <mini-os/xmalloc.h>
+#include <fcntl.h>
+#include <xen/features.h>
+#include <xen/version.h>
+
+static struct netfront_dev *net_dev;
+
+void test_xenbus(void);
+
+static void xenbus_tester(void *p)
+{
+    printk("Xenbus tests disabled, because of a Xend bug.\n");
+    /* test_xenbus(); */
+}
+
+static void periodic_thread(void *p)
+{
+    struct timeval tv;
+    printk("Periodic thread started.\n");
+    for(;;)
+    {
+        gettimeofday(&tv, NULL);
+        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
+        msleep(1000);
+    }
+}
+
+static void netfront_thread(void *p)
+{
+    net_dev = init_netfront(NULL, NULL, NULL, NULL);
+}
+
+static struct blkfront_dev *blk_dev;
+static struct blkfront_info blk_info;
+static uint64_t blk_size_read;
+static uint64_t blk_size_write;
+
+struct blk_req {
+    struct blkfront_aiocb aiocb;
+    int rand_value;
+    struct blk_req *next;
+};
+
+#ifdef BLKTEST_WRITE
+static struct blk_req *blk_to_read;
+#endif
+
+static struct blk_req *blk_alloc_req(uint64_t sector)
+{
+    struct blk_req *req = xmalloc(struct blk_req);
+    req->aiocb.aio_dev = blk_dev;
+    req->aiocb.aio_buf = _xmalloc(blk_info.sector_size, blk_info.sector_size);
+    req->aiocb.aio_nbytes = blk_info.sector_size;
+    req->aiocb.aio_offset = sector * blk_info.sector_size;
+    req->aiocb.data = req;
+    req->next = NULL;
+    return req;
+}
+
+static void blk_read_completed(struct blkfront_aiocb *aiocb, int ret)
+{
+    struct blk_req *req = aiocb->data;
+    if (ret)
+        printk("got error code %d when reading at offset %ld\n", ret, aiocb->aio_offset);
+    else
+        blk_size_read += blk_info.sector_size;
+    free(aiocb->aio_buf);
+    free(req);
+}
+
+static void blk_read_sector(uint64_t sector)
+{
+    struct blk_req *req;
+
+    req = blk_alloc_req(sector);
+    req->aiocb.aio_cb = blk_read_completed;
+
+    blkfront_aio_read(&req->aiocb);
+}
+
+#ifdef BLKTEST_WRITE
+static void blk_write_read_completed(struct blkfront_aiocb *aiocb, int ret)
+{
+    struct blk_req *req = aiocb->data;
+    int rand_value;
+    int i;
+    int *buf;
+
+    if (ret) {
+        printk("got error code %d when reading back at offset %ld\n", ret, aiocb->aio_offset);
+        free(aiocb->aio_buf);
+        free(req);
+        return;
+    }
+    blk_size_read += blk_info.sector_size;
+    buf = (int*) aiocb->aio_buf;
+    rand_value = req->rand_value;
+    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
+        if (buf[i] != rand_value) {
+            printk("bogus data at offset %ld\n", aiocb->aio_offset + i);
+            break;
+        }
+        rand_value *= RAND_MIX;
+    }
+    free(aiocb->aio_buf);
+    free(req);
+}
+
+static void blk_write_completed(struct blkfront_aiocb *aiocb, int ret)
+{
+    struct blk_req *req = aiocb->data;
+    if (ret) {
+        printk("got error code %d when writing at offset %ld\n", ret, aiocb->aio_offset);
+        free(aiocb->aio_buf);
+        free(req);
+        return;
+    }
+    blk_size_write += blk_info.sector_size;
+    /* Push write check */
+    req->next = blk_to_read;
+    blk_to_read = req;
+}
+
+static void blk_write_sector(uint64_t sector)
+{
+    struct blk_req *req;
+    int rand_value;
+    int i;
+    int *buf;
+
+    req = blk_alloc_req(sector);
+    req->aiocb.aio_cb = blk_write_completed;
+    req->rand_value = rand_value = rand();
+
+    buf = (int*) req->aiocb.aio_buf;
+    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
+        buf[i] = rand_value;
+        rand_value *= RAND_MIX;
+    }
+
+    blkfront_aio_write(&req->aiocb);
+}
+#endif
+
+static void blkfront_thread(void *p)
+{
+    time_t lasttime = 0;
+
+    blk_dev = init_blkfront(NULL, &blk_info);
+    if (!blk_dev)
+        return;
+
+    if (blk_info.info & VDISK_CDROM)
+        printk("Block device is a CDROM\n");
+    if (blk_info.info & VDISK_REMOVABLE)
+        printk("Block device is removable\n");
+    if (blk_info.info & VDISK_READONLY)
+        printk("Block device is read-only\n");
+
+#ifdef BLKTEST_WRITE
+    if (blk_info.mode == O_RDWR) {
+        blk_write_sector(0);
+        blk_write_sector(blk_info.sectors-1);
+    } else
+#endif
+    {
+        blk_read_sector(0);
+        blk_read_sector(blk_info.sectors-1);
+    }
+
+    while (1) {
+        uint64_t sector = rand() % blk_info.sectors;
+        struct timeval tv;
+#ifdef BLKTEST_WRITE
+        if (blk_info.mode == O_RDWR)
+            blk_write_sector(sector);
+        else
+#endif
+            blk_read_sector(sector);
+        blkfront_aio_poll(blk_dev);
+        gettimeofday(&tv, NULL);
+        if (tv.tv_sec > lasttime + 10) {
+            printk("%llu read, %llu write\n", blk_size_read, blk_size_write);
+            lasttime = tv.tv_sec;
+        }
+
+#ifdef BLKTEST_WRITE
+        while (blk_to_read) {
+            struct blk_req *req = blk_to_read;
+            blk_to_read = blk_to_read->next;
+            req->aiocb.aio_cb = blk_write_read_completed;
+            blkfront_aio_read(&req->aiocb);
+        }
+#endif
+    }
+}
+
+#define WIDTH 800
+#define HEIGHT 600
+#define DEPTH 32
+
+static uint32_t *fb;
+static int refresh_period = 50;
+static struct fbfront_dev *fb_dev;
+static struct semaphore fbfront_sem = __SEMAPHORE_INITIALIZER(fbfront_sem, 0);
+
+static void fbfront_drawvert(int x, int y1, int y2, uint32_t color)
+{
+    int y;
+    if (x < 0)
+        return;
+    if (x >= WIDTH)
+        return;
+    if (y1 < 0)
+        y1 = 0;
+    if (y2 >= HEIGHT)
+        y2 = HEIGHT-1;
+    for (y = y1; y <= y2; y++)
+        fb[x + y*WIDTH] ^= color;
+}
+
+static void fbfront_drawhoriz(int x1, int x2, int y, uint32_t color)
+{
+    int x;
+    if (y < 0)
+        return;
+    if (y >= HEIGHT)
+        return;
+    if (x1 < 0)
+        x1 = 0;
+    if (x2 >= WIDTH)
+        x2 = WIDTH-1;
+    for (x = x1; x <= x2; x++)
+        fb[x + y*WIDTH] ^= color;
+}
+
+static void fbfront_thread(void *p)
+{
+    size_t line_length = WIDTH * (DEPTH / 8);
+    size_t memsize = HEIGHT * line_length;
+    unsigned long *mfns;
+    int i, n = (memsize + PAGE_SIZE-1) / PAGE_SIZE;
+
+    memsize = n * PAGE_SIZE;
+    fb = _xmalloc(memsize, PAGE_SIZE);
+    memset(fb, 0, memsize);
+    mfns = xmalloc_array(unsigned long, n);
+    for (i = 0; i < n; i++)
+        mfns[i] = virtual_to_mfn((char *) fb + i * PAGE_SIZE);
+    fb_dev = init_fbfront(NULL, mfns, WIDTH, HEIGHT, DEPTH, line_length, n);
+    xfree(mfns);
+    if (!fb_dev) {
+        xfree(fb);
+        return;
+    }
+    up(&fbfront_sem);
+}
+
+static void clip_cursor(int *x, int *y)
+{
+    if (*x < 0)
+        *x = 0;
+    if (*x >= WIDTH)
+        *x = WIDTH - 1;
+    if (*y < 0)
+        *y = 0;
+    if (*y >= HEIGHT)
+        *y = HEIGHT - 1;
+}
+
+static void refresh_cursor(int new_x, int new_y)
+{
+    static int old_x = -1, old_y = -1;
+
+    if (!refresh_period)
+        return;
+
+    if (old_x != -1 && old_y != -1) {
+        fbfront_drawvert(old_x, old_y + 1, old_y + 8, 0xffffffff);
+        fbfront_drawhoriz(old_x + 1, old_x + 8, old_y, 0xffffffff);
+        fbfront_update(fb_dev, old_x, old_y, 9, 9);
+    }
+    old_x = new_x;
+    old_y = new_y;
+    fbfront_drawvert(new_x, new_y + 1, new_y + 8, 0xffffffff);
+    fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
+    fbfront_update(fb_dev, new_x, new_y, 9, 9);
+}
+
+static struct kbdfront_dev *kbd_dev;
+static void kbdfront_thread(void *p)
+{
+    DEFINE_WAIT(w);
+    DEFINE_WAIT(w2);
+    int x = WIDTH / 2, y = HEIGHT / 2, z = 0;
+
+    kbd_dev = init_kbdfront(NULL, 1);
+    if (!kbd_dev)
+        return;
+
+    down(&fbfront_sem);
+    refresh_cursor(x, y);
+    while (1) {
+        union xenkbd_in_event kbdevent;
+        union xenfb_in_event fbevent;
+        int sleep = 1;
+
+        add_waiter(w, kbdfront_queue);
+        add_waiter(w2, fbfront_queue);
+
+        while (kbdfront_receive(kbd_dev, &kbdevent, 1) != 0) {
+            sleep = 0;
+            switch(kbdevent.type) {
+            case XENKBD_TYPE_MOTION:
+                printk("motion x:%d y:%d z:%d\n",
+                        kbdevent.motion.rel_x,
+                        kbdevent.motion.rel_y,
+                        kbdevent.motion.rel_z);
+                x += kbdevent.motion.rel_x;
+                y += kbdevent.motion.rel_y;
+                z += kbdevent.motion.rel_z;
+                clip_cursor(&x, &y);
+                refresh_cursor(x, y);
+                break;
+            case XENKBD_TYPE_POS:
+                printk("pos x:%d y:%d dz:%d\n",
+                        kbdevent.pos.abs_x,
+                        kbdevent.pos.abs_y,
+                        kbdevent.pos.rel_z);
+                x = kbdevent.pos.abs_x;
+                y = kbdevent.pos.abs_y;
+                z = kbdevent.pos.rel_z;
+                clip_cursor(&x, &y);
+                refresh_cursor(x, y);
+                break;
+            case XENKBD_TYPE_KEY:
+                printk("key %d %s\n",
+                        kbdevent.key.keycode,
+                        kbdevent.key.pressed ? "pressed" : "released");
+                if (kbdevent.key.keycode == BTN_LEFT) {
+                    printk("mouse %s at (%d,%d,%d)\n",
+                            kbdevent.key.pressed ? "clic" : "release", x, y, z);
+                    if (kbdevent.key.pressed) {
+                        uint32_t color = rand();
+                        fbfront_drawvert(x - 16, y - 16, y + 15, color);
+                        fbfront_drawhoriz(x - 16, x + 15, y + 16, color);
+                        fbfront_drawvert(x + 16, y - 15, y + 16, color);
+                        fbfront_drawhoriz(x - 15, x + 16, y - 16, color);
+                        fbfront_update(fb_dev, x - 16, y - 16, 33, 33);
+                    }
+                } else if (kbdevent.key.keycode == KEY_Q) {
+                    struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_poweroff };
+                    HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
+                    do_exit();
+                }
+                break;
+            }
+        }
+        while (fbfront_receive(fb_dev, &fbevent, 1) != 0) {
+            sleep = 0;
+            switch(fbevent.type) {
+            case XENFB_TYPE_REFRESH_PERIOD:
+                refresh_period = fbevent.refresh_period.period;
+                printk("refresh period %d\n", refresh_period);
+                refresh_cursor(x, y);
+                break;
+            }
+        }
+        if (sleep)
+            schedule();
+    }
+}
+
+static struct pcifront_dev *pci_dev;
+
+static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
+{
+    unsigned int vendor, device, rev, class;
+
+    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x00, 2, &vendor);
+    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x02, 2, &device);
+    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x08, 1, &rev);
+    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x0a, 2, &class);
+
+    printk("%04x:%02x:%02x.%02x %04x: %04x:%04x (rev %02x)\n", domain, bus, slot, fun, class, vendor, device, rev);
+}
+
+static void pcifront_thread(void *p)
+{
+    pcifront_watches(NULL);
+    pci_dev = init_pcifront(NULL);
+    if (!pci_dev)
+        return;
+    printk("PCI devices:\n");
+    pcifront_scan(pci_dev, print_pcidev);
+}
+
+int app_main(start_info_t *si)
+{
+    printk("Test main: start_info=%p\n", si);
+    create_thread("xenbus_tester", xenbus_tester, si);
+    create_thread("periodic_thread", periodic_thread, si);
+    create_thread("netfront", netfront_thread, si);
+    create_thread("blkfront", blkfront_thread, si);
+    create_thread("fbfront", fbfront_thread, si);
+    create_thread("kbdfront", kbdfront_thread, si);
+    create_thread("pcifront", pcifront_thread, si);
+    return 0;
+}
+
+void shutdown_frontends(void)
+{
+    if (net_dev)
+        shutdown_netfront(net_dev);
+
+    if (blk_dev)
+        shutdown_blkfront(blk_dev);
+
+    if (fb_dev)
+        shutdown_fbfront(fb_dev);
+
+    if (kbd_dev)
+        shutdown_kbdfront(kbd_dev);
+
+    if (pci_dev)
+        shutdown_pcifront(pci_dev);
+}
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/c/minios.cfg
+++ b/stubdom/c/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/caml/minios.cfg
+++ b/stubdom/caml/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGZ-0002K8-40; Thu, 26 Jan 2012 19:45:51 +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 1RqVGW-0002DT-GA
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327607141!12701929!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22653 invoked from network); 26 Jan 2012 19:45:42 -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;
	26 Jan 2012 19:45:42 -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
	q0QJjeLe009026
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI4005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:09 -0500
Message-Id: <1327607111-15394-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 22/24] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 89b3422..f254947 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -462,7 +462,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -800,11 +800,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index f525d65..22fe126b 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -358,7 +358,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -422,7 +422,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -474,7 +474,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -511,7 +511,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGS-0002EL-Uo; Thu, 26 Jan 2012 19:45:44 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVGR-0002DJ-6z
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:43 +0000
Received: from [85.158.139.83:52224] by server-12.bemta-5.messagelabs.com id
	AC/EA-18193-66DA12F4; Thu, 26 Jan 2012 19:45:42 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327607140!12534133!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13056 invoked from network); 26 Jan 2012 19:45: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;
	26 Jan 2012 19:45: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
	q0QJjdQG026844
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHm005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:53 -0500
Message-Id: <1327607111-15394-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/24] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..3828c62 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -64,6 +64,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -95,9 +96,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c8da45..965dbd0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -243,9 +243,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGb-0002Mp-6Q; Thu, 26 Jan 2012 19:45:53 +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 1RqVGX-0002Dz-DF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327607142!12701930!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22678 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjeQG026863; Thu, 26 Jan 2012 19:45: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 q0QJjcI1005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:06 -0500
Message-Id: <1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/Makefile           |    9 ++++-
 tools/xenstore/utils.h            |    2 +
 tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
 tools/xenstore/xenstored_domain.c |   11 +++++
 4 files changed, 68 insertions(+), 28 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..be892fd 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4b12cf2..0b9d4f2 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -224,7 +224,6 @@ static void reopen_log(void)
 	}
 }
 
-
 static bool write_messages(struct connection *conn)
 {
 	int ret;
@@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 		set_fd(sock, inset, &max);
 	if (ro_sock != -1)
 		set_fd(ro_sock, inset, &max);
-	set_fd(reopen_log_pipe[0], inset, &max);
+	if (reopen_log_pipe[0] != -1)
+		set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifdef __MINIOS__
+static void write_pidfile(const char *pidfile)
+{
+}
+
+static void daemonize(void)
+{
+}
+
+static void finish_daemonize(void)
+{
+}
+#else
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1711,6 +1724,19 @@ static void daemonize(void)
 	umask(0);
 }
 
+static void finish_daemonize(void)
+{
+	int devnull = open("/dev/null", O_RDWR);
+	if (devnull == -1)
+		barf_perror("Could not open /dev/null\n");
+	dup2(devnull, STDIN_FILENO);
+	dup2(devnull, STDOUT_FILENO);
+	dup2(devnull, STDERR_FILENO);
+	close(devnull);
+	xprintf = trace;
+}
+#endif
+
 #ifdef NO_SOCKETS
 static void init_sockets(int **psock, int **pro_sock)
 {
@@ -1822,6 +1848,11 @@ int main(int argc, char *argv[])
 	int evtchn_fd = -1;
 	struct timeval *timeout;
 
+#ifdef __MINIOS__
+	/* minios always uses internal DB */
+	tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
+#endif
+
 	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
 				  NULL)) != -1) {
 		switch (opt) {
@@ -1874,20 +1905,10 @@ int main(int argc, char *argv[])
 
 	reopen_log();
 
-	/* make sure xenstored directory exists */
-	if (mkdir(xs_daemon_rundir(), 0755)) {
-		if (errno != EEXIST) {
-			perror("error: mkdir daemon rundir");
-			exit(-1);
-		}
-	}
-
-	if (mkdir(xs_daemon_rootdir(), 0755)) {
-		if (errno != EEXIST) {
-			perror("error: mkdir daemon rootdir");
-			exit(-1);
-		}
-	}
+	/* make sure xenstored directories exist */
+	/* Errors ignored here, will be reported when we open files */
+	mkdir(xs_daemon_rundir(), 0755);
+	mkdir(xs_daemon_rootdir(), 0755);
 
 	if (dofork) {
 		openlog("xenstored", 0, LOG_DAEMON);
@@ -1905,9 +1926,14 @@ int main(int argc, char *argv[])
 
 	init_sockets(&sock, &ro_sock);
 
+#ifdef __MINIOS__
+	reopen_log_pipe[0] = -1;
+	reopen_log_pipe[1] = -1;
+#else
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1925,16 +1951,8 @@ int main(int argc, char *argv[])
 	}
 
 	/* redirect to /dev/null now we're ready to accept connections */
-	if (dofork) {
-		int devnull = open("/dev/null", O_RDWR);
-		if (devnull == -1)
-			barf_perror("Could not open /dev/null\n");
-		dup2(devnull, STDIN_FILENO);
-		dup2(devnull, STDOUT_FILENO);
-		dup2(devnull, STDERR_FILENO);
-		close(devnull);
-		xprintf = trace;
-	}
+	if (dofork)
+		finish_daemonize();
 
 	signal(SIGHUP, trigger_reopen_log);
 
@@ -1944,8 +1962,10 @@ int main(int argc, char *argv[])
 	/* Get ready to listen to the tools. */
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1957,7 +1977,7 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
-		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
+		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index c521e52..4243f91 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -197,12 +197,16 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		unmap_interface(domain->interface);
+#else
 		/* Domain 0 was mapped by dom0_init, so it must be unmapped
 		   using munmap() and not the grant unmap call. */
 		if (domain->domid == 0)
 			munmap(domain->interface, getpagesize());
 		else
 			unmap_interface(domain->interface);
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
@@ -597,6 +601,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static int dom0_init(void)
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -620,6 +630,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:46:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVGb-0002Mp-6Q; Thu, 26 Jan 2012 19:45:53 +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 1RqVGX-0002Dz-DF
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327607142!12701930!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22678 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-6.tower-216.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjeQG026863; Thu, 26 Jan 2012 19:45: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 q0QJjcI1005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:06 -0500
Message-Id: <1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/xenstore/Makefile           |    9 ++++-
 tools/xenstore/utils.h            |    2 +
 tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
 tools/xenstore/xenstored_domain.c |   11 +++++
 4 files changed, 68 insertions(+), 28 deletions(-)

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..be892fd 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -28,6 +28,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4b12cf2..0b9d4f2 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -224,7 +224,6 @@ static void reopen_log(void)
 	}
 }
 
-
 static bool write_messages(struct connection *conn)
 {
 	int ret;
@@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 		set_fd(sock, inset, &max);
 	if (ro_sock != -1)
 		set_fd(ro_sock, inset, &max);
-	set_fd(reopen_log_pipe[0], inset, &max);
+	if (reopen_log_pipe[0] != -1)
+		set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
+#ifdef __MINIOS__
+static void write_pidfile(const char *pidfile)
+{
+}
+
+static void daemonize(void)
+{
+}
+
+static void finish_daemonize(void)
+{
+}
+#else
 static void write_pidfile(const char *pidfile)
 {
 	char buf[100];
@@ -1711,6 +1724,19 @@ static void daemonize(void)
 	umask(0);
 }
 
+static void finish_daemonize(void)
+{
+	int devnull = open("/dev/null", O_RDWR);
+	if (devnull == -1)
+		barf_perror("Could not open /dev/null\n");
+	dup2(devnull, STDIN_FILENO);
+	dup2(devnull, STDOUT_FILENO);
+	dup2(devnull, STDERR_FILENO);
+	close(devnull);
+	xprintf = trace;
+}
+#endif
+
 #ifdef NO_SOCKETS
 static void init_sockets(int **psock, int **pro_sock)
 {
@@ -1822,6 +1848,11 @@ int main(int argc, char *argv[])
 	int evtchn_fd = -1;
 	struct timeval *timeout;
 
+#ifdef __MINIOS__
+	/* minios always uses internal DB */
+	tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
+#endif
+
 	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
 				  NULL)) != -1) {
 		switch (opt) {
@@ -1874,20 +1905,10 @@ int main(int argc, char *argv[])
 
 	reopen_log();
 
-	/* make sure xenstored directory exists */
-	if (mkdir(xs_daemon_rundir(), 0755)) {
-		if (errno != EEXIST) {
-			perror("error: mkdir daemon rundir");
-			exit(-1);
-		}
-	}
-
-	if (mkdir(xs_daemon_rootdir(), 0755)) {
-		if (errno != EEXIST) {
-			perror("error: mkdir daemon rootdir");
-			exit(-1);
-		}
-	}
+	/* make sure xenstored directories exist */
+	/* Errors ignored here, will be reported when we open files */
+	mkdir(xs_daemon_rundir(), 0755);
+	mkdir(xs_daemon_rootdir(), 0755);
 
 	if (dofork) {
 		openlog("xenstored", 0, LOG_DAEMON);
@@ -1905,9 +1926,14 @@ int main(int argc, char *argv[])
 
 	init_sockets(&sock, &ro_sock);
 
+#ifdef __MINIOS__
+	reopen_log_pipe[0] = -1;
+	reopen_log_pipe[1] = -1;
+#else
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
 	}
+#endif
 
 	/* Setup the database */
 	setup_structure();
@@ -1925,16 +1951,8 @@ int main(int argc, char *argv[])
 	}
 
 	/* redirect to /dev/null now we're ready to accept connections */
-	if (dofork) {
-		int devnull = open("/dev/null", O_RDWR);
-		if (devnull == -1)
-			barf_perror("Could not open /dev/null\n");
-		dup2(devnull, STDIN_FILENO);
-		dup2(devnull, STDOUT_FILENO);
-		dup2(devnull, STDERR_FILENO);
-		close(devnull);
-		xprintf = trace;
-	}
+	if (dofork)
+		finish_daemonize();
 
 	signal(SIGHUP, trigger_reopen_log);
 
@@ -1944,8 +1962,10 @@ int main(int argc, char *argv[])
 	/* Get ready to listen to the tools. */
 	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
 
+#ifndef __MINIOS__
 	/* Tell the kernel we're up and running. */
 	xenbus_notify_running();
+#endif
 
 	/* Main loop. */
 	for (;;) {
@@ -1957,7 +1977,7 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
-		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
+		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index c521e52..4243f91 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -197,12 +197,16 @@ static int destroy_domain(void *_domain)
 	}
 
 	if (domain->interface) {
+#ifdef __MINIOS__
+		unmap_interface(domain->interface);
+#else
 		/* Domain 0 was mapped by dom0_init, so it must be unmapped
 		   using munmap() and not the grant unmap call. */
 		if (domain->domid == 0)
 			munmap(domain->interface, getpagesize());
 		else
 			unmap_interface(domain->interface);
+#endif
 	}
 
 	fire_watches(NULL, "@releaseDomain", false);
@@ -597,6 +601,12 @@ void restore_existing_connections(void)
 {
 }
 
+#ifdef __MINIOS__
+static int dom0_init(void)
+{
+	return 0;
+}
+#else
 static int dom0_init(void) 
 { 
 	evtchn_port_t port;
@@ -620,6 +630,7 @@ static int dom0_init(void)
 
 	return 0; 
 }
+#endif
 
 void domain_init(void)
 {
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVGY-0002JI-Bo; Thu, 26 Jan 2012 19:45: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 1RqVGV-0002DH-TL
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327607094!51737382!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17990 invoked from network); 26 Jan 2012 19:44:54 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:44:54 -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
	q0QJjeLe009019
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI0005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:05 -0500
Message-Id: <1327607111-15394-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/24] xenstored: add --internal-db flag
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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/xenstore/xenstored_core.c |   20 ++++++++++++++------
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index c1ee932..4b12cf2 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -63,7 +63,7 @@ static bool recovery = true;
 static bool remove_local = true;
 static int reopen_log_pipe[2];
 static char *tracefile = NULL;
-static TDB_CONTEXT *tdb_ctx;
+static TDB_CONTEXT *tdb_ctx = NULL;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
@@ -92,8 +92,9 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
-	if (rename(newname, xs_daemon_tdb()) != 0)
-		return false;
+	if (!(tdb_ctx->flags & TDB_INTERNAL))
+		if (rename(newname, xs_daemon_tdb()) != 0)
+			return false;
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -1410,7 +1411,7 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
-#define TDB_FLAGS 0
+static int tdb_flags;
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1435,7 +1436,9 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
-	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+
+	if (!(tdb_flags & TDB_INTERNAL))
+		tdb_ctx = tdb_open(tdbname, 0, tdb_flags, O_RDWR, 0);
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1466,7 +1469,7 @@ static void setup_structure(void)
 		talloc_free(tlocal);
 	}
 	else {
-		tdb_ctx = tdb_open(tdbname, 7919, TDB_FLAGS, O_RDWR|O_CREAT,
+		tdb_ctx = tdb_open(tdbname, 7919, tdb_flags, O_RDWR|O_CREAT,
 				   0640);
 		if (!tdb_ctx)
 			barf_perror("Could not create tdb file %s", tdbname);
@@ -1783,6 +1786,7 @@ static void usage(void)
 "  --transaction <nb>  limit the number of transaction allowed per domain,\n"
 "  --no-recovery       to request that no recovery should be attempted when\n"
 "                      the store is corrupted (debug only),\n"
+"  --internal-db       store database in memory, not on disk\n"
 "  --preserve-local    to request that /local is preserved on start-up,\n"
 "  --verbose           to request verbose execution.\n");
 }
@@ -1800,6 +1804,7 @@ static struct option options[] = {
 	{ "transaction", 1, NULL, 't' },
 	{ "no-recovery", 0, NULL, 'R' },
 	{ "preserve-local", 0, NULL, 'L' },
+	{ "internal-db", 0, NULL, 'I' },
 	{ "verbose", 0, NULL, 'V' },
 	{ "watch-nb", 1, NULL, 'W' },
 	{ NULL, 0, NULL, 0 } };
@@ -1853,6 +1858,9 @@ int main(int argc, char *argv[])
 		case 'T':
 			tracefile = optarg;
 			break;
+		case 'I':
+			tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
+			break;
 		case 'V':
 			verbose = true;
 			break;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:46:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVGY-0002JI-Bo; Thu, 26 Jan 2012 19:45: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 1RqVGV-0002DH-TL
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:45:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327607094!51737382!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17990 invoked from network); 26 Jan 2012 19:44:54 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:44:54 -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
	q0QJjeLe009019
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcI0005952; 
	Thu, 26 Jan 2012 14:45:40 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:45:05 -0500
Message-Id: <1327607111-15394-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 18/24] xenstored: add --internal-db flag
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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/xenstore/xenstored_core.c |   20 ++++++++++++++------
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index c1ee932..4b12cf2 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -63,7 +63,7 @@ static bool recovery = true;
 static bool remove_local = true;
 static int reopen_log_pipe[2];
 static char *tracefile = NULL;
-static TDB_CONTEXT *tdb_ctx;
+static TDB_CONTEXT *tdb_ctx = NULL;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
@@ -92,8 +92,9 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
-	if (rename(newname, xs_daemon_tdb()) != 0)
-		return false;
+	if (!(tdb_ctx->flags & TDB_INTERNAL))
+		if (rename(newname, xs_daemon_tdb()) != 0)
+			return false;
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -1410,7 +1411,7 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
-#define TDB_FLAGS 0
+static int tdb_flags;
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1435,7 +1436,9 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
-	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+
+	if (!(tdb_flags & TDB_INTERNAL))
+		tdb_ctx = tdb_open(tdbname, 0, tdb_flags, O_RDWR, 0);
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1466,7 +1469,7 @@ static void setup_structure(void)
 		talloc_free(tlocal);
 	}
 	else {
-		tdb_ctx = tdb_open(tdbname, 7919, TDB_FLAGS, O_RDWR|O_CREAT,
+		tdb_ctx = tdb_open(tdbname, 7919, tdb_flags, O_RDWR|O_CREAT,
 				   0640);
 		if (!tdb_ctx)
 			barf_perror("Could not create tdb file %s", tdbname);
@@ -1783,6 +1786,7 @@ static void usage(void)
 "  --transaction <nb>  limit the number of transaction allowed per domain,\n"
 "  --no-recovery       to request that no recovery should be attempted when\n"
 "                      the store is corrupted (debug only),\n"
+"  --internal-db       store database in memory, not on disk\n"
 "  --preserve-local    to request that /local is preserved on start-up,\n"
 "  --verbose           to request verbose execution.\n");
 }
@@ -1800,6 +1804,7 @@ static struct option options[] = {
 	{ "transaction", 1, NULL, 't' },
 	{ "no-recovery", 0, NULL, 'R' },
 	{ "preserve-local", 0, NULL, 'L' },
+	{ "internal-db", 0, NULL, 'I' },
 	{ "verbose", 0, NULL, 'V' },
 	{ "watch-nb", 1, NULL, 'W' },
 	{ NULL, 0, NULL, 0 } };
@@ -1853,6 +1858,9 @@ int main(int argc, char *argv[])
 		case 'T':
 			tracefile = optarg;
 			break;
+		case 'I':
+			tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
+			break;
 		case 'V':
 			verbose = true;
 			break;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:52:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVMa-0005gs-IT; Thu, 26 Jan 2012 19:52:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVMY-0005gI-Cd
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:52:02 +0000
Received: from [85.158.139.83:52284] by server-1.bemta-5.messagelabs.com id
	15/32-18433-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327607141!12524984!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3575 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjdQG026841; Thu, 26 Jan 2012 19:45: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 q0QJjcHi005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:49 -0500
Message-Id: <1327607111-15394-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/24] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   66 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 154 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 37b0fd6..2ffdd85 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -749,6 +749,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index fd20210..500c7a2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -86,7 +86,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -480,7 +480,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -621,7 +621,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -680,7 +680,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 5b0fc4a..8001a91 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -995,6 +995,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..43bd167 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,68 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++)
+    {
+        if (global_virq_handlers[virq] == d)
+        {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count)
+    {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1222,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..6560182 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -288,7 +288,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -315,7 +315,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 232d50e..40b8a7a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,11 +23,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..e3cae60 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..acf9c8a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..543dc77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:52:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19: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 1RqVMa-0005gs-IT; Thu, 26 Jan 2012 19:52:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RqVMY-0005gI-Cd
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:52:02 +0000
Received: from [85.158.139.83:52284] by server-1.bemta-5.messagelabs.com id
	15/32-18433-76DA12F4; Thu, 26 Jan 2012 19:45:43 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327607141!12524984!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3575 invoked from network); 26 Jan 2012 19:45:42 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-182.messagelabs.com with SMTP;
	26 Jan 2012 19:45:42 -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
	q0QJjdQG026841; Thu, 26 Jan 2012 19:45: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 q0QJjcHi005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:49 -0500
Message-Id: <1327607111-15394-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 02/24] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   66 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 154 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 37b0fd6..2ffdd85 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -749,6 +749,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index fd20210..500c7a2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -86,7 +86,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -480,7 +480,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -621,7 +621,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -680,7 +680,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 5b0fc4a..8001a91 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -995,6 +995,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..43bd167 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,68 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++)
+    {
+        if (global_virq_handlers[virq] == d)
+        {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count)
+    {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1222,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..6560182 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -288,7 +288,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -315,7 +315,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 232d50e..40b8a7a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,11 +23,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..e3cae60 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..acf9c8a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..543dc77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVN2-0005nx-2O; Thu, 26 Jan 2012 19:52:32 +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 1RqVMz-0005lp-D7
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:52:29 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327607141!2775112!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24005 invoked from network); 26 Jan 2012 19:45:42 -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;
	26 Jan 2012 19:45:42 -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
	q0QJjdQG026845; Thu, 26 Jan 2012 19:45: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 q0QJjcHp005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:56 -0500
Message-Id: <1327607111-15394-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/24] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This changes the minios evtchn implementation to use a list instead of
an array which ahis allows it to grow as necessary to support any number
of ports, only limited by Xen (NR_EVS is 1024, should be enough for now).

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:52:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:52:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVN2-0005nx-2O; Thu, 26 Jan 2012 19:52:32 +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 1RqVMz-0005lp-D7
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:52:29 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327607141!2775112!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24005 invoked from network); 26 Jan 2012 19:45:42 -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;
	26 Jan 2012 19:45:42 -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
	q0QJjdQG026845; Thu, 26 Jan 2012 19:45: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 q0QJjcHp005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:56 -0500
Message-Id: <1327607111-15394-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: [Xen-devel] [PATCH 09/24] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This changes the minios evtchn implementation to use a list instead of
an array which ahis allows it to grow as necessary to support any number
of ports, only limited by Xen (NR_EVS is 1024, should be enough for now).

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
 extras/mini-os/include/lib.h |   16 +++---
 tools/libxc/xc_minios.c      |  139 ++++++++++++++++++++++--------------------
 2 files changed, 81 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..12070c3 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -53,6 +53,7 @@
 #include <xen/xen.h>
 #include <xen/event_channel.h>
 #include "gntmap.h"
+#include "list.h"
 
 #ifdef HAVE_LIBC
 #include <stdio.h>
@@ -143,7 +144,12 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+struct evtchn_port_info {
+        struct minios_list_head list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +164,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct minios_list_head ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..29cce63 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -210,15 +210,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    minios_list_add(&port_info->list, &files[fd].evtchn.ports);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    minios_list_del(&port_info->list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    MINIOS_INIT_LIST_HEAD(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +250,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    minios_list_for_each_entry_safe(port_info, tmp, &files[fd].evtchn.ports, list)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +275,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +297,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +311,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +325,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +339,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +352,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +393,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    minios_list_for_each_entry(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:56:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVQv-0006OA-2F; Thu, 26 Jan 2012 19:56:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqVQs-0006O3-Qq
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:56:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327607740!51891380!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16522 invoked from network); 26 Jan 2012 19:55:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 19:55:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327607789; l=1854;
	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=iVktZBFPLypi7nutb2jN971veQI=;
	b=QGzjHFSRzOoyWmcWpbAISLxH6vTxnesDHKL5JBCbnltnBdgT/h9EAbWkEMykCEFSQ6O
	SX9FT4oNyCEpweJoUCOxTQofIbaTY5fl8YcK0qSlsfCFl/mYrdJYXPScbmN2FVo6OUvYN
	4IgJk+fA2knzGjhFLLJApPQE3kNwmH5WFKs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (jimi mo45) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 6020b4o0QJfpU1
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 20:56:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3432618634
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 20:56:18 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ebc68ae15103061fa554745efb652b7d7e7b8e89
Message-Id: <ebc68ae15103061fa554.1327607777@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Jan 2012 20:56:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: unify return value in nominate and
	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 1327607757 -3600
# Node ID ebc68ae15103061fa554745efb652b7d7e7b8e89
# Parent  266a12304601226213a57e39cc11aa075acdfb58
xenpaging: unify return value in nominate and evict

Let p2m_mem_paging_nominate and p2m_mem_paging_evict return just one
error number. EINVAL is not very helpful in case of nominate, it can
happen if the pager tries to nominate a ballooned page. In this case the
gfn is not backed by a mfn, the pager can not know that.  Similar with
evict, anything can happen between nominate and evict.

This change helps the pager to decide if the returned error is from the
function itself, or if it happend earlier. In the latter case, it is
most likely fatal and should be handled as such.
nominate returns EAGAIN, evict EBUSY.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 266a12304601 -r ebc68ae15103 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)) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:56:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:56:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVQv-0006OA-2F; Thu, 26 Jan 2012 19:56:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RqVQs-0006O3-Qq
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:56:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327607740!51891380!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMDgxNzI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16522 invoked from network); 26 Jan 2012 19:55:41 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 19:55:41 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327607789; l=1854;
	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=iVktZBFPLypi7nutb2jN971veQI=;
	b=QGzjHFSRzOoyWmcWpbAISLxH6vTxnesDHKL5JBCbnltnBdgT/h9EAbWkEMykCEFSQ6O
	SX9FT4oNyCEpweJoUCOxTQofIbaTY5fl8YcK0qSlsfCFl/mYrdJYXPScbmN2FVo6OUvYN
	4IgJk+fA2knzGjhFLLJApPQE3kNwmH5WFKs=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0PGhXC
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-197.pools.arcor-ip.net [88.65.94.197])
	by smtp.strato.de (jimi mo45) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id 6020b4o0QJfpU1
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 20:56:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3432618634
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 20:56:18 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: ebc68ae15103061fa554745efb652b7d7e7b8e89
Message-Id: <ebc68ae15103061fa554.1327607777@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Thu, 26 Jan 2012 20:56:17 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: unify return value in nominate and
	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 1327607757 -3600
# Node ID ebc68ae15103061fa554745efb652b7d7e7b8e89
# Parent  266a12304601226213a57e39cc11aa075acdfb58
xenpaging: unify return value in nominate and evict

Let p2m_mem_paging_nominate and p2m_mem_paging_evict return just one
error number. EINVAL is not very helpful in case of nominate, it can
happen if the pager tries to nominate a ballooned page. In this case the
gfn is not backed by a mfn, the pager can not know that.  Similar with
evict, anything can happen between nominate and evict.

This change helps the pager to decide if the returned error is from the
function itself, or if it happend earlier. In the latter case, it is
most likely fatal and should be handled as such.
nominate returns EAGAIN, evict EBUSY.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 266a12304601 -r ebc68ae15103 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)) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:58:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVSX-0006Vg-Hr; Thu, 26 Jan 2012 19:58:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RqVSV-0006VO-TG
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:58:12 +0000
Received: from [85.158.138.51:49165] by server-12.bemta-3.messagelabs.com id
	76/D4-24557-350B12F4; Thu, 26 Jan 2012 19:58:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327607889!10840467!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=1.0 required=7.0 tests=DATE_IN_PAST_03_06, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30801 invoked from network); 26 Jan 2012 19:58:10 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 19:58:10 -0000
Received: by eekb45 with SMTP id b45so5022819eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 11:58: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:user-agent:date:from:to:cc;
	bh=FgIWZAambw9In+tSs4oQ6xKLMPWXc478qL6IQApKr4c=;
	b=S50C0BEA0dmZKy+WHVUkNA6/4/Td4xhxWQbw7UdJdJ6VTZpcQRd/MfdR7TUMhMGU7U
	mQFKNbkeesYhJgBsxyF8Rd1NNZYOz5cfp/6wOqSzvOiU/eqhhPfwDti5LT0WksibNrn/
	KgBARp5dmnQx1TofyU7+AY+BqhDmdK8F3oi0g=
Received: by 10.14.9.28 with SMTP id 28mr1201252ees.93.1327607889522;
	Thu, 26 Jan 2012 11:58:09 -0800 (PST)
Received: from debian.localdomain (81.184.59.225.dyn.user.ono.com.
	[81.184.59.225])
	by mx.google.com with ESMTPS id 40sm19333570ees.10.2012.01.26.11.58.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Jan 2012 11:58:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 259112aee618753552056e398f940d1fd9fcc6f7
Message-Id: <259112aee61875355205.1327595099@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 26 Jan 2012 17:24:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH v2] 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 1326564288 -3600
# Node ID 259112aee618753552056e398f940d1fd9fcc6f7
# Parent  f581bb82fecd51e8fbd9c2e4ae9e76b08a695587
libxl: fix mutex initialization

The macro PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is not defined on
NetBSD, so define mutex attributes manually.

Changes since v1:

 * Fix leak of mutex attr.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f581bb82fecd -r 259112aee618 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
@@ -26,7 +26,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, in
 {
     libxl_ctx *ctx = NULL;
     struct stat stat_buf;
-    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
     int rc;
 
     if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }
@@ -40,10 +39,10 @@ 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 (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        return ERROR_FAIL;
+    }
 
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
diff -r f581bb82fecd -r 259112aee618 tools/libxl/libxl_internal.c
--- a/tools/libxl/libxl_internal.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_internal.c	Sat Jan 14 19:04:48 2012 +0100
@@ -296,6 +296,33 @@ int libxl__file_reference_unmap(libxl_fi
     return 0;
 }
 
+_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock)
+{
+    pthread_mutexattr_t attr;
+    int rc = 0;
+
+    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");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (pthread_mutex_init(lock, &attr) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to init mutex\n");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+out:
+    pthread_mutexattr_destroy(&attr);
+    return rc;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff -r f581bb82fecd -r 259112aee618 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
@@ -640,6 +640,8 @@ struct libxl__xen_console_reader {
 _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);
+/* init a recursive mutex */
+_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock);
 
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 19:58:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 19:58:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVSX-0006Vg-Hr; Thu, 26 Jan 2012 19:58:13 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RqVSV-0006VO-TG
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 19:58:12 +0000
Received: from [85.158.138.51:49165] by server-12.bemta-3.messagelabs.com id
	76/D4-24557-350B12F4; Thu, 26 Jan 2012 19:58:11 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327607889!10840467!1
X-Originating-IP: [74.125.83.43]
X-SpamReason: No, hits=1.0 required=7.0 tests=DATE_IN_PAST_03_06, RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30801 invoked from network); 26 Jan 2012 19:58:10 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	26 Jan 2012 19:58:10 -0000
Received: by eekb45 with SMTP id b45so5022819eek.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 11:58: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:user-agent:date:from:to:cc;
	bh=FgIWZAambw9In+tSs4oQ6xKLMPWXc478qL6IQApKr4c=;
	b=S50C0BEA0dmZKy+WHVUkNA6/4/Td4xhxWQbw7UdJdJ6VTZpcQRd/MfdR7TUMhMGU7U
	mQFKNbkeesYhJgBsxyF8Rd1NNZYOz5cfp/6wOqSzvOiU/eqhhPfwDti5LT0WksibNrn/
	KgBARp5dmnQx1TofyU7+AY+BqhDmdK8F3oi0g=
Received: by 10.14.9.28 with SMTP id 28mr1201252ees.93.1327607889522;
	Thu, 26 Jan 2012 11:58:09 -0800 (PST)
Received: from debian.localdomain (81.184.59.225.dyn.user.ono.com.
	[81.184.59.225])
	by mx.google.com with ESMTPS id 40sm19333570ees.10.2012.01.26.11.58.07
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 26 Jan 2012 11:58:08 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 259112aee618753552056e398f940d1fd9fcc6f7
Message-Id: <259112aee61875355205.1327595099@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Thu, 26 Jan 2012 17:24:59 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH v2] 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 1326564288 -3600
# Node ID 259112aee618753552056e398f940d1fd9fcc6f7
# Parent  f581bb82fecd51e8fbd9c2e4ae9e76b08a695587
libxl: fix mutex initialization

The macro PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP is not defined on
NetBSD, so define mutex attributes manually.

Changes since v1:

 * Fix leak of mutex attr.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r f581bb82fecd -r 259112aee618 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl.c	Sat Jan 14 19:04:48 2012 +0100
@@ -26,7 +26,6 @@ int libxl_ctx_alloc(libxl_ctx **pctx, in
 {
     libxl_ctx *ctx = NULL;
     struct stat stat_buf;
-    const pthread_mutex_t mutex_value = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;
     int rc;
 
     if (version != LIBXL_VERSION) { rc = ERROR_VERSION; goto out; }
@@ -40,10 +39,10 @@ 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 (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
+        return ERROR_FAIL;
+    }
 
     if ( stat(XENSTORE_PID_FILE, &stat_buf) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Is xenstore daemon running?\n"
diff -r f581bb82fecd -r 259112aee618 tools/libxl/libxl_internal.c
--- a/tools/libxl/libxl_internal.c	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_internal.c	Sat Jan 14 19:04:48 2012 +0100
@@ -296,6 +296,33 @@ int libxl__file_reference_unmap(libxl_fi
     return 0;
 }
 
+_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock)
+{
+    pthread_mutexattr_t attr;
+    int rc = 0;
+
+    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");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+    if (pthread_mutex_init(lock, &attr) != 0) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, 
+                         "Failed to init mutex\n");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+out:
+    pthread_mutexattr_destroy(&attr);
+    return rc;
+}
+
 libxl_device_model_version libxl__device_model_version_running(libxl__gc *gc,
                                                                uint32_t domid)
 {
diff -r f581bb82fecd -r 259112aee618 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
+++ b/tools/libxl/libxl_internal.h	Sat Jan 14 19:04:48 2012 +0100
@@ -640,6 +640,8 @@ struct libxl__xen_console_reader {
 _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);
+/* init a recursive mutex */
+_hidden int libxl__init_recursive_mutex(libxl_ctx *ctx, pthread_mutex_t *lock);
 
 #define STRINGIFY(x) #x
 #define TOSTRING(x) STRINGIFY(x)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 20:01:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 20:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVV5-0006ke-GW; Thu, 26 Jan 2012 20:00:51 +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 1RqVV3-0006kC-Io
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 20:00:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327607989!54204372!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29324 invoked from network); 26 Jan 2012 19:59:50 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:59:50 -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
	q0QJjdQG026843
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHl005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:52 -0500
Message-Id: <1327607111-15394-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/24] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to preserve v2-only features such as sub-page grants will
produce a warning and invalidate the resulting v1 grant entry.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
 xen/include/public/grant_table.h |    7 +++++
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0c55fd1..6f24a94 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2131,7 +2132,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2156,15 +2157,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1)
+    {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    }
+    else if (gt->gt_version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)
+            {
+                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
+                       d->domain_id, reserved_entries[i].flags, i);
+                reserved_entries[i].flags = GTF_invalid;
+            }
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1)
     {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    }
+    else if (gt->gt_version != 0 && op.version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 54d9551..292d724 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,13 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* The first few grant table entries will be preserved across grant table
+ * version changes and may be pre-populated at domain creation by tools.
+ */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 20:01:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 20:01:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVV5-0006ke-GW; Thu, 26 Jan 2012 20:00:51 +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 1RqVV3-0006kC-Io
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 20:00:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327607989!54204372!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29324 invoked from network); 26 Jan 2012 19:59:50 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-27.messagelabs.com with SMTP;
	26 Jan 2012 19:59:50 -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
	q0QJjdQG026843
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 19:45: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 q0QJjcHl005952; 
	Thu, 26 Jan 2012 14:45:39 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Thu, 26 Jan 2012 14:44:52 -0500
Message-Id: <1327607111-15394-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/24] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to preserve v2-only features such as sub-page grants will
produce a warning and invalidate the resulting v1 grant entry.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
 xen/include/public/grant_table.h |    7 +++++
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0c55fd1..6f24a94 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2131,7 +2132,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     /* (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2156,15 +2157,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version == 1)
+    {
+        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
+    }
+    else if (gt->gt_version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
+            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            reserved_entries[i].flags |= status_entry(gt, i);
+            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)
+            {
+                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
+                       d->domain_id, reserved_entries[i].flags, i);
+                reserved_entries[i].flags = GTF_invalid;
+            }
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if (gt->gt_version != 0 && op.version == 1)
     {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
+    }
+    else if (gt->gt_version != 0 && op.version == 2)
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 54d9551..292d724 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,13 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* The first few grant table entries will be preserved across grant table
+ * version changes and may be pre-populated at domain creation by tools.
+ */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 20:11:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 20:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVfb-0007Du-Dy; Thu, 26 Jan 2012 20:11:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqVfZ-0007Dp-Gr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 20:11:41 +0000
Received: from [85.158.139.83:13728] by server-2.bemta-5.messagelabs.com id
	FB/5E-07121-C73B12F4; Thu, 26 Jan 2012 20:11:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327608698!5116900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19174 invoked from network); 26 Jan 2012 20:11:39 -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;
	26 Jan 2012 20:11:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="10314568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 20:11: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, 26 Jan 2012 20:11: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 1RqVfV-0002ci-Uc;
	Thu, 26 Jan 2012 20:11:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqVfV-0005Bp-U4;
	Thu, 26 Jan 2012 20:11:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11627-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 20:11:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11627: 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 11627 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11627/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  e2722b24dc09
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 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.

(No revision log; it would be 503 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 Jan 26 20:11:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 20:11:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqVfb-0007Du-Dy; Thu, 26 Jan 2012 20:11:43 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqVfZ-0007Dp-Gr
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 20:11:41 +0000
Received: from [85.158.139.83:13728] by server-2.bemta-5.messagelabs.com id
	FB/5E-07121-C73B12F4; Thu, 26 Jan 2012 20:11:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327608698!5116900!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19174 invoked from network); 26 Jan 2012 20:11:39 -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;
	26 Jan 2012 20:11:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="10314568"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 20:11: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, 26 Jan 2012 20:11: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 1RqVfV-0002ci-Uc;
	Thu, 26 Jan 2012 20:11:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqVfV-0005Bp-U4;
	Thu, 26 Jan 2012 20:11:37 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11627-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 20:11:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11627: 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 11627 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11627/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-amd64-pvops             4 kernel-build              fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  e2722b24dc09
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 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.

(No revision log; it would be 503 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 Jan 26 20:50:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 20: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 1RqWGj-00085h-RR; Thu, 26 Jan 2012 20:50:05 +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 1RqWGi-00085Z-MP
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 20:50:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327610998!12749085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22070 invoked from network); 26 Jan 2012 20:49:58 -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;
	26 Jan 2012 20:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="10314864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 20:49: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, 26 Jan 2012 20:49:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RqWGb-0002pM-T4;
	Thu, 26 Jan 2012 20:49:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqWGb-0000MC-OA;
	Thu, 26 Jan 2012 20:49:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11628-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 20:49:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11628: trouble:
	blocked/broken/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 11628 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11628/


jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 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-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


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 Jan 26 20:50:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 20: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 1RqWGj-00085h-RR; Thu, 26 Jan 2012 20:50:05 +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 1RqWGi-00085Z-MP
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 20:50:04 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327610998!12749085!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22070 invoked from network); 26 Jan 2012 20:49:58 -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;
	26 Jan 2012 20:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="10314864"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 20:49: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, 26 Jan 2012 20:49:58 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RqWGb-0002pM-T4;
	Thu, 26 Jan 2012 20:49:57 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqWGb-0000MC-OA;
	Thu, 26 Jan 2012 20:49:57 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11628-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 20:49:57 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [qemu-upstream-unstable test] 11628: trouble:
	blocked/broken/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 11628 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11628/


jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 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-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


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 Jan 26 20:56:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 20:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqWME-0000DF-RA; Thu, 26 Jan 2012 20:55:46 +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 1RqWMD-0000Cf-9P
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 20:55:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327611337!8915186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16231 invoked from network); 26 Jan 2012 20:55:38 -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;
	26 Jan 2012 20:55:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="10314906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 20:55: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, 26 Jan 2012 20:55: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 1RqWM5-0002rW-5g;
	Thu, 26 Jan 2012 20:55:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqWM5-0000n6-57;
	Thu, 26 Jan 2012 20:55:37 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11631-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 20:55:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11631: regressions - trouble:
	blocked/broken/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 11631 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11631/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  e2722b24dc09
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 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-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.

(No revision log; it would be 503 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 Jan 26 20:56:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 20:56:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqWME-0000DF-RA; Thu, 26 Jan 2012 20:55:46 +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 1RqWMD-0000Cf-9P
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 20:55:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327611337!8915186!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16231 invoked from network); 26 Jan 2012 20:55:38 -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;
	26 Jan 2012 20:55:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="10314906"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 20:55: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, 26 Jan 2012 20:55: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 1RqWM5-0002rW-5g;
	Thu, 26 Jan 2012 20:55:37 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqWM5-0000n6-57;
	Thu, 26 Jan 2012 20:55:37 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11631-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Thu, 26 Jan 2012 20:55:37 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11631: regressions - trouble:
	blocked/broken/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 11631 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11631/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  e2722b24dc09
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 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-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.

(No revision log; it would be 503 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 Jan 26 21:42:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 21:42:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqX4c-0001n8-3L; Thu, 26 Jan 2012 21:41:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RqX4a-0001n3-A9
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 21:41:36 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327614087!2784442!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwOTQyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27875 invoked from network); 26 Jan 2012 21:41:28 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 21:41:28 -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
	q0QLfOLH024117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 21:41:25 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
	q0QLfO7L019798
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 21:41:24 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
	q0QLfNoS000711
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 15:41:23 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 13:41:23 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9c05e938466b46d79fa9cf09d9b3d2e939e3c142
Message-Id: <9c05e938466b46d79fa9.1327614136@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Thu, 26 Jan 2012 16:42:16 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F21C885.0030,ss=1,re=0.000,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] disable downloading qemu traditional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1327614102 18000
# Node ID 9c05e938466b46d79fa9cf09d9b3d2e939e3c142
# Parent  4271634e4c86568b6bf2241ebf9be4a82ab430bf
disable downloading qemu traditional

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r 4271634e4c86 -r 9c05e938466b Makefile
--- a/Makefile	Wed Jan 25 15:52:47 2012 +0000
+++ b/Makefile	Thu Jan 26 16:41:42 2012 -0500
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir
+	install-tools: tools/qemu-xen-dir
 endif
 
 .PHONY: install-kernels

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 21:42:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 21:42:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqX4c-0001n8-3L; Thu, 26 Jan 2012 21:41:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RqX4a-0001n3-A9
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 21:41:36 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327614087!2784442!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwOTQyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27875 invoked from network); 26 Jan 2012 21:41:28 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 26 Jan 2012 21:41:28 -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
	q0QLfOLH024117
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 21:41:25 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
	q0QLfO7L019798
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 21:41:24 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
	q0QLfNoS000711
	for <xen-devel@lists.xensource.com>; Thu, 26 Jan 2012 15:41:23 -0600
Received: from zhigang.cn.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 13:41:23 -0800
MIME-Version: 1.0
X-Mercurial-Node: 9c05e938466b46d79fa9cf09d9b3d2e939e3c142
Message-Id: <9c05e938466b46d79fa9.1327614136@zhigang.us.oracle.com>
User-Agent: Mercurial-patchbomb/1.9+29-ad6a58581ecd
Date: Thu, 26 Jan 2012 16:42:16 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
To: xen-devel <xen-devel@lists.xensource.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090202.4F21C885.0030,ss=1,re=0.000,fgs=0
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: [Xen-devel] [PATCH] disable downloading qemu traditional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Zhigang Wang <zhigang.x.wang@oracle.com>
# Date 1327614102 18000
# Node ID 9c05e938466b46d79fa9cf09d9b3d2e939e3c142
# Parent  4271634e4c86568b6bf2241ebf9be4a82ab430bf
disable downloading qemu traditional

Signed-off-by: Zhigang Wang <zhigang.x.wang@oracle.com>

diff -r 4271634e4c86 -r 9c05e938466b Makefile
--- a/Makefile	Wed Jan 25 15:52:47 2012 +0000
+++ b/Makefile	Thu Jan 26 16:41:42 2012 -0500
@@ -70,7 +70,7 @@ install-tools:
 	$(MAKE) -C tools install
 
 ifeq ($(CONFIG_IOEMU),y)
-install-tools: tools/qemu-xen-traditional-dir tools/qemu-xen-dir
+	install-tools: tools/qemu-xen-dir
 endif
 
 .PHONY: install-kernels

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 22:04:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 22: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 1RqXQN-0002XA-3f; Thu, 26 Jan 2012 22:04:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqXQM-0002X5-4E
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 22:04:06 +0000
Received: from [85.158.139.83:33323] by server-4.bemta-5.messagelabs.com id
	5F/38-09697-5DDC12F4; Thu, 26 Jan 2012 22:04:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327615444!12551031!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32097 invoked from network); 26 Jan 2012 22:04:04 -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;
	26 Jan 2012 22:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="10315608"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 22:04:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 22:04:04 +0000
Message-ID: <1327615443.16448.1.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 26 Jan 2012 22:04:03 +0000
In-Reply-To: <9c05e938466b46d79fa9.1327614136@zhigang.us.oracle.com>
References: <9c05e938466b46d79fa9.1327614136@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] disable downloading qemu traditional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 21:42 +0000, Zhigang Wang wrote:
> disable downloading qemu traditional

Why?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 22:04:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 22: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 1RqXQN-0002XA-3f; Thu, 26 Jan 2012 22:04:07 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqXQM-0002X5-4E
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 22:04:06 +0000
Received: from [85.158.139.83:33323] by server-4.bemta-5.messagelabs.com id
	5F/38-09697-5DDC12F4; Thu, 26 Jan 2012 22:04:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327615444!12551031!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NDg1MA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32097 invoked from network); 26 Jan 2012 22:04:04 -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;
	26 Jan 2012 22:04:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,575,1320624000"; d="scan'208";a="10315608"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	26 Jan 2012 22:04:04 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Thu, 26 Jan 2012 22:04:04 +0000
Message-ID: <1327615443.16448.1.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Zhigang Wang <zhigang.x.wang@oracle.com>
Date: Thu, 26 Jan 2012 22:04:03 +0000
In-Reply-To: <9c05e938466b46d79fa9.1327614136@zhigang.us.oracle.com>
References: <9c05e938466b46d79fa9.1327614136@zhigang.us.oracle.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] disable downloading qemu traditional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 21:42 +0000, Zhigang Wang wrote:
> disable downloading qemu traditional

Why?



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 22:33:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 22:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqXsb-00035i-Lc; Thu, 26 Jan 2012 22:33:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RqXsZ-00035d-Mc
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 22:33:15 +0000
Received: from [85.158.138.51:49509] by server-6.bemta-3.messagelabs.com id
	E0/AE-31032-AA4D12F4; Thu, 26 Jan 2012 22:33:14 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327617192!8981623!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwODE3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27409 invoked from network); 26 Jan 2012 22:33:14 -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; 26 Jan 2012 22:33:14 -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
	q0QMX9Q3027248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Jan 2012 22:33:10 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
	q0QMX7WZ021871
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Jan 2012 22:33:08 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
	q0QMX7SN032153; Thu, 26 Jan 2012 16:33:07 -0600
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 14:33:07 -0800
Message-ID: <4F21D4E2.7040805@oracle.com>
Date: Thu, 26 Jan 2012 17:34:10 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <9c05e938466b46d79fa9.1327614136@zhigang.us.oracle.com>
	<1327615443.16448.1.camel@dagon.hellion.org.uk>
In-Reply-To: <1327615443.16448.1.camel@dagon.hellion.org.uk>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F21D4A6.00BF,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] disable downloading qemu traditional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/26/2012 05:04 PM, Ian Campbell wrote:
> On Thu, 2012-01-26 at 21:42 +0000, Zhigang Wang wrote:
>> disable downloading qemu traditional
> 
> Why?
> 
> 

Please ignore this patch for now. It seems I loss track of the status...



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Thu Jan 26 22:33:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Thu, 26 Jan 2012 22:33:45 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqXsb-00035i-Lc; Thu, 26 Jan 2012 22:33:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <zhigang.x.wang@oracle.com>) id 1RqXsZ-00035d-Mc
	for xen-devel@lists.xensource.com; Thu, 26 Jan 2012 22:33:15 +0000
Received: from [85.158.138.51:49509] by server-6.bemta-3.messagelabs.com id
	E0/AE-31032-AA4D12F4; Thu, 26 Jan 2012 22:33:14 +0000
X-Env-Sender: zhigang.x.wang@oracle.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327617192!8981623!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwODE3NA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27409 invoked from network); 26 Jan 2012 22:33:14 -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; 26 Jan 2012 22:33:14 -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
	q0QMX9Q3027248
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 26 Jan 2012 22:33:10 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
	q0QMX7WZ021871
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 26 Jan 2012 22:33:08 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
	q0QMX7SN032153; Thu, 26 Jan 2012 16:33:07 -0600
Received: from zhigang.us.oracle.com (/10.149.236.110)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 14:33:07 -0800
Message-ID: <4F21D4E2.7040805@oracle.com>
Date: Thu, 26 Jan 2012 17:34:10 -0500
From: Zhigang Wang <zhigang.x.wang@oracle.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <9c05e938466b46d79fa9.1327614136@zhigang.us.oracle.com>
	<1327615443.16448.1.camel@dagon.hellion.org.uk>
In-Reply-To: <1327615443.16448.1.camel@dagon.hellion.org.uk>
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090208.4F21D4A6.00BF,ss=1,re=0.000,fgs=0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] disable downloading qemu traditional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/26/2012 05:04 PM, Ian Campbell wrote:
> On Thu, 2012-01-26 at 21:42 +0000, Zhigang Wang wrote:
>> disable downloading qemu traditional
> 
> Why?
> 
> 

Please ignore this patch for now. It seems I loss track of the status...



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 00:08:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 00: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 1RqZMK-0005Ir-JT; Fri, 27 Jan 2012 00:08:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@suse.de>) id 1RqZMI-0005Im-Tl
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 00:08:03 +0000
Received: from [85.158.138.51:64062] by server-11.bemta-3.messagelabs.com id
	5B/34-26051-2EAE12F4; Fri, 27 Jan 2012 00:08:02 +0000
X-Env-Sender: gregkh@suse.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327622881!10852733!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10462 invoked from network); 27 Jan 2012 00:08:01 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 00:08:01 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 754768FC93;
	Fri, 27 Jan 2012 01:08:00 +0100 (CET)
Date: Thu, 26 Jan 2012 16:06:12 -0800
From: Greg KH <gregkh@suse.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	kay.sievers@vrfy.org
Message-ID: <20120127000612.GA14678@suse.de>
References: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	bp@amd64.org, mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
> 
> [   14.484206] SMP alternatives: switching to UP code
> [   14.514287] ------------[ cut here ]------------
> [   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [   14.514586] Call Trace:
> [   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
> [   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
> [   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
> [   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
> [   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
> [   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [   14.515094] ---[ end trace 8f70af51a2e2611f ]---
> 
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date:   Mon Jan 16 14:40:28 2012 -0800
> 
>     mce: fix warning messages about static struct mce_device
> "
> 
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?
> 
> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> the privilige of being the first? Oh, I hadn't done a full bisection
> but v3.2 does not have this.

Kay, this is a mess.

This cpu system device is is interconnected with the different arches
and their cpu-specific structures.  Some arches have a static array,
some allocate a huge structure (struct arch_cpu * NUM_CPUS), and others
try to do the right thing with DECLARE_PER_CPU() but don't quite get it
right, making that a static array per cpu.

To unwind all of this, is much beyond 3.3 material, as I'm sure I'll get
it wrong, and have a bunch of non-x86-64 build problems along the way.

Any objection to me just doing the "hack" of the empty release function
at the moment to get rid of this warning, and then clean it all up
properly for 3.4?

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 00:08:45 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 00: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 1RqZMK-0005Ir-JT; Fri, 27 Jan 2012 00:08:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@suse.de>) id 1RqZMI-0005Im-Tl
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 00:08:03 +0000
Received: from [85.158.138.51:64062] by server-11.bemta-3.messagelabs.com id
	5B/34-26051-2EAE12F4; Fri, 27 Jan 2012 00:08:02 +0000
X-Env-Sender: gregkh@suse.de
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327622881!10852733!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10462 invoked from network); 27 Jan 2012 00:08:01 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 00:08:01 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 754768FC93;
	Fri, 27 Jan 2012 01:08:00 +0100 (CET)
Date: Thu, 26 Jan 2012 16:06:12 -0800
From: Greg KH <gregkh@suse.de>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	kay.sievers@vrfy.org
Message-ID: <20120127000612.GA14678@suse.de>
References: <20120123180601.GA24553@phenom.dumpdata.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120123180601.GA24553@phenom.dumpdata.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com, x86@kernel.org, linux-kernel@vger.kernel.org,
	bp@amd64.org, mingo@redhat.com, hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> When I bring a CPU down in a guest (which should be the same as bringing a
> CPU down using the ACPI framework), I get this:
> 
> [   14.484206] SMP alternatives: switching to UP code
> [   14.514287] ------------[ cut here ]------------
> [   14.514318] WARNING: at /home/konrad/linux-linus/drivers/base/core.c:194 device_release+0x82/0x90()
> [   14.514354] Device 'cpu1' does not have a release() function, it is broken and must be fixed.
> [   14.514386] Modules linked in: radeon fbcon tileblit font ttm bitblit softcursor drm_kms_helper xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea xen_kbdfront xenfs xen_privcmd
> [   14.514557] Pid: 22, comm: xenwatch Not tainted 3.3.0-rc1 #1
> [   14.514586] Call Trace:
> [   14.515094]  [<ffffffff810897fa>] warn_slowpath_common+0x7a/0xb0
> [   14.515094]  [<ffffffff810898d1>] warn_slowpath_fmt+0x41/0x50
> [   14.515094]  [<ffffffff813dea02>] device_release+0x82/0x90
> [   14.515094]  [<ffffffff812dfb85>] kobject_release+0x45/0x90
> [   14.515094]  [<ffffffff812dfa4c>] kobject_put+0x2c/0x60
> [   14.515094]  [<ffffffff813de6a2>] put_device+0x12/0x20
> [   14.515094]  [<ffffffff813df409>] device_unregister+0x19/0x20
> [   14.515094]  [<ffffffff813e4edf>] unregister_cpu+0x4f/0x80
> [   14.515094]  [<ffffffff81052c7c>] arch_unregister_cpu+0x1c/0x20
> [   14.515094]  [<ffffffff8137f787>] handle_vcpu_hotplug_event+0xc7/0xd0
> [   14.515094]  [<ffffffff8137b900>] xenwatch_thread+0xb0/0x180
> [   14.515094]  [<ffffffff810ad3f0>] ? wake_up_bit+0x40/0x40
> [   14.515094]  [<ffffffff8137b850>] ? split+0xf0/0xf0
> [   14.515094]  [<ffffffff810acd16>] kthread+0x96/0xa0
> [   14.515094]  [<ffffffff816151e4>] kernel_thread_helper+0x4/0x10
> [   14.515094]  [<ffffffff8160cc80>] ? retint_restore_args+0x5/0x6
> [   14.515094]  [<ffffffff816151e0>] ? gs_change+0x13/0x13
> [   14.515094] ---[ end trace 8f70af51a2e2611f ]---
> 
> Looking at "commit e032d80774315869aa2285b217fdbbfed86c0b49
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Date:   Mon Jan 16 14:40:28 2012 -0800
> 
>     mce: fix warning messages about static struct mce_device
> "
> 
> it looks like the corret fix is to make the 'cpu_devices' in
> arch/x86/kernel/topology.c to be changed to be more dynamic
> (or perhaps have an empty release function)?
> 
> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> the privilige of being the first? Oh, I hadn't done a full bisection
> but v3.2 does not have this.

Kay, this is a mess.

This cpu system device is is interconnected with the different arches
and their cpu-specific structures.  Some arches have a static array,
some allocate a huge structure (struct arch_cpu * NUM_CPUS), and others
try to do the right thing with DECLARE_PER_CPU() but don't quite get it
right, making that a static array per cpu.

To unwind all of this, is much beyond 3.3 material, as I'm sure I'll get
it wrong, and have a bunch of non-x86-64 build problems along the way.

Any objection to me just doing the "hack" of the empty release function
at the moment to get rid of this warning, and then clean it all up
properly for 3.4?

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 00:23:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 00:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqZay-0005pN-2m; Fri, 27 Jan 2012 00:23:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kay.sievers@vrfy.org>) id 1RqZaw-0005pF-FR
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 00:23:10 +0000
Received: from [85.158.139.83:2498] by server-8.bemta-5.messagelabs.com id
	BA/4F-31172-D6EE12F4; Fri, 27 Jan 2012 00:23:09 +0000
X-Env-Sender: kay.sievers@vrfy.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327623787!12503393!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32330 invoked from network); 27 Jan 2012 00:23:08 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 00:23:08 -0000
Received: by iaeh11 with SMTP id h11so6957488iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 16:23:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrfy.org; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=6pSNCSbSFa+1VC1TSsK2gEsiU2aRvhDdV3s59tLMlok=;
	b=BBMSXA6WGwm0VB0xPnYCsY7PkZCODNa6oHGIfcNRooW5mckhN+YWOmW5G2TBA+xBiu
	mhTo+IpIuQJNzPeGCrfSNU3PYh8FiDmGAu7c8Lb3gVRrAXCC1g8xRX4Cc13DrCZKD7dz
	XOuM0rfwRycWHbrhntjlbT5r1gSzUEI0OqH7g=
Received: by 10.43.51.66 with SMTP id vh2mr3439415icb.39.1327623787196; Thu,
	26 Jan 2012 16:23:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.54.4 with HTTP; Thu, 26 Jan 2012 16:22:46 -0800 (PST)
In-Reply-To: <20120127000612.GA14678@suse.de>
References: <20120123180601.GA24553@phenom.dumpdata.com>
	<20120127000612.GA14678@suse.de>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Fri, 27 Jan 2012 01:22:46 +0100
Message-ID: <CAPXgP134gz6baAiVPPfhdaQsYZ5hDncZfb4C_Wj=iC51=Uqixw@mail.gmail.com>
To: Greg KH <gregkh@suse.de>
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBKYW4gMjcsIDIwMTIgYXQgMDE6MDYsIEdyZWcgS0ggPGdyZWdraEBzdXNlLmRlPiB3
cm90ZToKPiBPbiBNb24sIEphbiAyMywgMjAxMiBhdCAwMTowNjowMVBNIC0wNTAwLCBLb25yYWQg
Unplc3p1dGVrIFdpbGsgd3JvdGU6Cgo+PiBJcyBhbnlib2R5IGVsc2UgaGl0dGluZyB0aGlzIHdp
dGggQUNQSSBDUFUgaG90LXVucGx1Zz8gT3IgZG8gSSBoYXZlCj4+IHRoZSBwcml2aWxpZ2Ugb2Yg
YmVpbmcgdGhlIGZpcnN0PyBPaCwgSSBoYWRuJ3QgZG9uZSBhIGZ1bGwgYmlzZWN0aW9uCj4+IGJ1
dCB2My4yIGRvZXMgbm90IGhhdmUgdGhpcy4KPgo+IEtheSwgdGhpcyBpcyBhIG1lc3MuCj4KPiBU
aGlzIGNwdSBzeXN0ZW0gZGV2aWNlIGlzIGlzIGludGVyY29ubmVjdGVkIHdpdGggdGhlIGRpZmZl
cmVudCBhcmNoZXMKPiBhbmQgdGhlaXIgY3B1LXNwZWNpZmljIHN0cnVjdHVyZXMuIMKgU29tZSBh
cmNoZXMgaGF2ZSBhIHN0YXRpYyBhcnJheSwKPiBzb21lIGFsbG9jYXRlIGEgaHVnZSBzdHJ1Y3R1
cmUgKHN0cnVjdCBhcmNoX2NwdSAqIE5VTV9DUFVTKSwgYW5kIG90aGVycwo+IHRyeSB0byBkbyB0
aGUgcmlnaHQgdGhpbmcgd2l0aCBERUNMQVJFX1BFUl9DUFUoKSBidXQgZG9uJ3QgcXVpdGUgZ2V0
IGl0Cj4gcmlnaHQsIG1ha2luZyB0aGF0IGEgc3RhdGljIGFycmF5IHBlciBjcHUuCj4KPiBUbyB1
bndpbmQgYWxsIG9mIHRoaXMsIGlzIG11Y2ggYmV5b25kIDMuMyBtYXRlcmlhbCwgYXMgSSdtIHN1
cmUgSSdsbCBnZXQKPiBpdCB3cm9uZywgYW5kIGhhdmUgYSBidW5jaCBvZiBub24teDg2LTY0IGJ1
aWxkIHByb2JsZW1zIGFsb25nIHRoZSB3YXkuCj4KPiBBbnkgb2JqZWN0aW9uIHRvIG1lIGp1c3Qg
ZG9pbmcgdGhlICJoYWNrIiBvZiB0aGUgZW1wdHkgcmVsZWFzZSBmdW5jdGlvbgo+IGF0IHRoZSBt
b21lbnQgdG8gZ2V0IHJpZCBvZiB0aGlzIHdhcm5pbmcsIGFuZCB0aGVuIGNsZWFuIGl0IGFsbCB1
cAo+IHByb3Blcmx5IGZvciAzLjQ/CgpObyBwcm9ibGVtIGF0IGFsbC4KCkl0IHdvdWxkIGJlIG5p
Y2UgaWYgd2UgZ2V0IGFsbCB0aGF0IHRvIHRoZSB1c3VhbCBtb2RlbCBzb21lIGRheSwgYnV0IEkK
Y2FuIHRvdGFsbHkgc2VlIHRoYXQgQ1BVIGRldmljZXMgdHJ5IHRvIGRlYWwgd2l0aCBzdGF0aWNh
bGx5IGFsbG9jYXRlZApwZXItY3B1IG1lbW9yeS4gSXQgc2VlbXMgZmluZSwgYXMgbG9uZyBhcyB0
aGV5IGtub3cgd2hhdCB0aGV5IGFyZQpkb2luZy4KCkp1c3Qgc2lsZW5jaW5nIHRoZSBkcml2ZXIt
Y29yZSB3YXJuaW5nIGhlcmUgc291bmRzIGZpbmUgdG8gbWUuCgpUaGFua3MsCktheQoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 27 00:23:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 00:23:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqZay-0005pN-2m; Fri, 27 Jan 2012 00:23:12 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <kay.sievers@vrfy.org>) id 1RqZaw-0005pF-FR
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 00:23:10 +0000
Received: from [85.158.139.83:2498] by server-8.bemta-5.messagelabs.com id
	BA/4F-31172-D6EE12F4; Fri, 27 Jan 2012 00:23:09 +0000
X-Env-Sender: kay.sievers@vrfy.org
X-Msg-Ref: server-15.tower-182.messagelabs.com!1327623787!12503393!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32330 invoked from network); 27 Jan 2012 00:23:08 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-15.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 00:23:08 -0000
Received: by iaeh11 with SMTP id h11so6957488iae.30
	for <xen-devel@lists.xensource.com>;
	Thu, 26 Jan 2012 16:23:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrfy.org; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type:content-transfer-encoding;
	bh=6pSNCSbSFa+1VC1TSsK2gEsiU2aRvhDdV3s59tLMlok=;
	b=BBMSXA6WGwm0VB0xPnYCsY7PkZCODNa6oHGIfcNRooW5mckhN+YWOmW5G2TBA+xBiu
	mhTo+IpIuQJNzPeGCrfSNU3PYh8FiDmGAu7c8Lb3gVRrAXCC1g8xRX4Cc13DrCZKD7dz
	XOuM0rfwRycWHbrhntjlbT5r1gSzUEI0OqH7g=
Received: by 10.43.51.66 with SMTP id vh2mr3439415icb.39.1327623787196; Thu,
	26 Jan 2012 16:23:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.54.4 with HTTP; Thu, 26 Jan 2012 16:22:46 -0800 (PST)
In-Reply-To: <20120127000612.GA14678@suse.de>
References: <20120123180601.GA24553@phenom.dumpdata.com>
	<20120127000612.GA14678@suse.de>
From: Kay Sievers <kay.sievers@vrfy.org>
Date: Fri, 27 Jan 2012 01:22:46 +0100
Message-ID: <CAPXgP134gz6baAiVPPfhdaQsYZ5hDncZfb4C_Wj=iC51=Uqixw@mail.gmail.com>
To: Greg KH <gregkh@suse.de>
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

T24gRnJpLCBKYW4gMjcsIDIwMTIgYXQgMDE6MDYsIEdyZWcgS0ggPGdyZWdraEBzdXNlLmRlPiB3
cm90ZToKPiBPbiBNb24sIEphbiAyMywgMjAxMiBhdCAwMTowNjowMVBNIC0wNTAwLCBLb25yYWQg
Unplc3p1dGVrIFdpbGsgd3JvdGU6Cgo+PiBJcyBhbnlib2R5IGVsc2UgaGl0dGluZyB0aGlzIHdp
dGggQUNQSSBDUFUgaG90LXVucGx1Zz8gT3IgZG8gSSBoYXZlCj4+IHRoZSBwcml2aWxpZ2Ugb2Yg
YmVpbmcgdGhlIGZpcnN0PyBPaCwgSSBoYWRuJ3QgZG9uZSBhIGZ1bGwgYmlzZWN0aW9uCj4+IGJ1
dCB2My4yIGRvZXMgbm90IGhhdmUgdGhpcy4KPgo+IEtheSwgdGhpcyBpcyBhIG1lc3MuCj4KPiBU
aGlzIGNwdSBzeXN0ZW0gZGV2aWNlIGlzIGlzIGludGVyY29ubmVjdGVkIHdpdGggdGhlIGRpZmZl
cmVudCBhcmNoZXMKPiBhbmQgdGhlaXIgY3B1LXNwZWNpZmljIHN0cnVjdHVyZXMuIMKgU29tZSBh
cmNoZXMgaGF2ZSBhIHN0YXRpYyBhcnJheSwKPiBzb21lIGFsbG9jYXRlIGEgaHVnZSBzdHJ1Y3R1
cmUgKHN0cnVjdCBhcmNoX2NwdSAqIE5VTV9DUFVTKSwgYW5kIG90aGVycwo+IHRyeSB0byBkbyB0
aGUgcmlnaHQgdGhpbmcgd2l0aCBERUNMQVJFX1BFUl9DUFUoKSBidXQgZG9uJ3QgcXVpdGUgZ2V0
IGl0Cj4gcmlnaHQsIG1ha2luZyB0aGF0IGEgc3RhdGljIGFycmF5IHBlciBjcHUuCj4KPiBUbyB1
bndpbmQgYWxsIG9mIHRoaXMsIGlzIG11Y2ggYmV5b25kIDMuMyBtYXRlcmlhbCwgYXMgSSdtIHN1
cmUgSSdsbCBnZXQKPiBpdCB3cm9uZywgYW5kIGhhdmUgYSBidW5jaCBvZiBub24teDg2LTY0IGJ1
aWxkIHByb2JsZW1zIGFsb25nIHRoZSB3YXkuCj4KPiBBbnkgb2JqZWN0aW9uIHRvIG1lIGp1c3Qg
ZG9pbmcgdGhlICJoYWNrIiBvZiB0aGUgZW1wdHkgcmVsZWFzZSBmdW5jdGlvbgo+IGF0IHRoZSBt
b21lbnQgdG8gZ2V0IHJpZCBvZiB0aGlzIHdhcm5pbmcsIGFuZCB0aGVuIGNsZWFuIGl0IGFsbCB1
cAo+IHByb3Blcmx5IGZvciAzLjQ/CgpObyBwcm9ibGVtIGF0IGFsbC4KCkl0IHdvdWxkIGJlIG5p
Y2UgaWYgd2UgZ2V0IGFsbCB0aGF0IHRvIHRoZSB1c3VhbCBtb2RlbCBzb21lIGRheSwgYnV0IEkK
Y2FuIHRvdGFsbHkgc2VlIHRoYXQgQ1BVIGRldmljZXMgdHJ5IHRvIGRlYWwgd2l0aCBzdGF0aWNh
bGx5IGFsbG9jYXRlZApwZXItY3B1IG1lbW9yeS4gSXQgc2VlbXMgZmluZSwgYXMgbG9uZyBhcyB0
aGV5IGtub3cgd2hhdCB0aGV5IGFyZQpkb2luZy4KCkp1c3Qgc2lsZW5jaW5nIHRoZSBkcml2ZXIt
Y29yZSB3YXJuaW5nIGhlcmUgc291bmRzIGZpbmUgdG8gbWUuCgpUaGFua3MsCktheQoKX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxp
bmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291
cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Fri Jan 27 00:55:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 00:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqa5o-000637-Ot; Fri, 27 Jan 2012 00:55:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@suse.de>) id 1Rqa5n-000632-Bg
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 00:55:03 +0000
Received: from [85.158.139.83:38966] by server-11.bemta-5.messagelabs.com id
	83/42-18383-6E5F12F4; Fri, 27 Jan 2012 00:55:02 +0000
X-Env-Sender: gregkh@suse.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327625701!12544955!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17353 invoked from network); 27 Jan 2012 00:55:01 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 00:55:01 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 0EEE68891E;
	Fri, 27 Jan 2012 01:54:59 +0100 (CET)
Date: Thu, 26 Jan 2012 16:53:45 -0800
From: Greg KH <gregkh@suse.de>
To: Kay Sievers <kay.sievers@vrfy.org>
Message-ID: <20120127005345.GA13278@suse.de>
References: <20120123180601.GA24553@phenom.dumpdata.com>
	<20120127000612.GA14678@suse.de>
	<CAPXgP134gz6baAiVPPfhdaQsYZ5hDncZfb4C_Wj=iC51=Uqixw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPXgP134gz6baAiVPPfhdaQsYZ5hDncZfb4C_Wj=iC51=Uqixw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 27, 2012 at 01:22:46AM +0100, Kay Sievers wrote:
> On Fri, Jan 27, 2012 at 01:06, Greg KH <gregkh@suse.de> wrote:
> > On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> =

> >> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> >> the privilige of being the first? Oh, I hadn't done a full bisection
> >> but v3.2 does not have this.
> >
> > Kay, this is a mess.
> >
> > This cpu system device is is interconnected with the different arches
> > and their cpu-specific structures. =A0Some arches have a static array,
> > some allocate a huge structure (struct arch_cpu * NUM_CPUS), and others
> > try to do the right thing with DECLARE_PER_CPU() but don't quite get it
> > right, making that a static array per cpu.
> >
> > To unwind all of this, is much beyond 3.3 material, as I'm sure I'll get
> > it wrong, and have a bunch of non-x86-64 build problems along the way.
> >
> > Any objection to me just doing the "hack" of the empty release function
> > at the moment to get rid of this warning, and then clean it all up
> > properly for 3.4?
> =

> No problem at all.
> =

> It would be nice if we get all that to the usual model some day, but I
> can totally see that CPU devices try to deal with statically allocated
> per-cpu memory. It seems fine, as long as they know what they are
> doing.
> =

> Just silencing the driver-core warning here sounds fine to me.

Ok, I'll do that tomorrow and send a patch out and then start working on
making all of this dynamic, as it really should be.

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 00:55:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 00:55:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqa5o-000637-Ot; Fri, 27 Jan 2012 00:55:04 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gregkh@suse.de>) id 1Rqa5n-000632-Bg
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 00:55:03 +0000
Received: from [85.158.139.83:38966] by server-11.bemta-5.messagelabs.com id
	83/42-18383-6E5F12F4; Fri, 27 Jan 2012 00:55:02 +0000
X-Env-Sender: gregkh@suse.de
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327625701!12544955!1
X-Originating-IP: [195.135.220.15]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17353 invoked from network); 27 Jan 2012 00:55:01 -0000
Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15)
	by server-4.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 00:55:01 -0000
Received: from relay2.suse.de (unknown [195.135.220.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx2.suse.de (Postfix) with ESMTP id 0EEE68891E;
	Fri, 27 Jan 2012 01:54:59 +0100 (CET)
Date: Thu, 26 Jan 2012 16:53:45 -0800
From: Greg KH <gregkh@suse.de>
To: Kay Sievers <kay.sievers@vrfy.org>
Message-ID: <20120127005345.GA13278@suse.de>
References: <20120123180601.GA24553@phenom.dumpdata.com>
	<20120127000612.GA14678@suse.de>
	<CAPXgP134gz6baAiVPPfhdaQsYZ5hDncZfb4C_Wj=iC51=Uqixw@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPXgP134gz6baAiVPPfhdaQsYZ5hDncZfb4C_Wj=iC51=Uqixw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, x86@kernel.org,
	linux-kernel@vger.kernel.org, bp@amd64.org, mingo@redhat.com,
	hpa@zytor.com, tglx@linutronix.de,
	Linus Torvalds <torvalds@linux-foundation.org>, lenb@kernel.org
Subject: Re: [Xen-devel] WARN... Device 'cpu1' does not have a release()
 function,
 it is broken and must be fixed. when doing 'xl vcpu-set <guest_id> 1'
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="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, Jan 27, 2012 at 01:22:46AM +0100, Kay Sievers wrote:
> On Fri, Jan 27, 2012 at 01:06, Greg KH <gregkh@suse.de> wrote:
> > On Mon, Jan 23, 2012 at 01:06:01PM -0500, Konrad Rzeszutek Wilk wrote:
> =

> >> Is anybody else hitting this with ACPI CPU hot-unplug? Or do I have
> >> the privilige of being the first? Oh, I hadn't done a full bisection
> >> but v3.2 does not have this.
> >
> > Kay, this is a mess.
> >
> > This cpu system device is is interconnected with the different arches
> > and their cpu-specific structures. =A0Some arches have a static array,
> > some allocate a huge structure (struct arch_cpu * NUM_CPUS), and others
> > try to do the right thing with DECLARE_PER_CPU() but don't quite get it
> > right, making that a static array per cpu.
> >
> > To unwind all of this, is much beyond 3.3 material, as I'm sure I'll get
> > it wrong, and have a bunch of non-x86-64 build problems along the way.
> >
> > Any objection to me just doing the "hack" of the empty release function
> > at the moment to get rid of this warning, and then clean it all up
> > properly for 3.4?
> =

> No problem at all.
> =

> It would be nice if we get all that to the usual model some day, but I
> can totally see that CPU devices try to deal with statically allocated
> per-cpu memory. It seems fine, as long as they know what they are
> doing.
> =

> Just silencing the driver-core warning here sounds fine to me.

Ok, I'll do that tomorrow and send a patch out and then start working on
making all of this dynamic, as it really should be.

thanks,

greg k-h

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 02:41:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 02: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 1RqbkI-00032E-3J; Fri, 27 Jan 2012 02:40:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqbkF-000329-VW
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 02:40:56 +0000
Received: from [85.158.139.83:39917] by server-5.bemta-5.messagelabs.com id
	1B/FF-12374-7BE022F4; Fri, 27 Jan 2012 02:40:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327632054!12579378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8983 invoked from network); 27 Jan 2012 02:40: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;
	27 Jan 2012 02:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,577,1320624000"; d="scan'208";a="10317347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 02:40:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 02:40: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 1RqbkD-0004kU-Kk;
	Fri, 27 Jan 2012 02:40:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqbkD-00039a-CR;
	Fri, 27 Jan 2012 02:40:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11637-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 02:40:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11637: regressions - trouble:
	blocked/broken/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 11637 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11637/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  e2722b24dc09
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 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-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.

(No revision log; it would be 503 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 Jan 27 02:41:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 02: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 1RqbkI-00032E-3J; Fri, 27 Jan 2012 02:40:58 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqbkF-000329-VW
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 02:40:56 +0000
Received: from [85.158.139.83:39917] by server-5.bemta-5.messagelabs.com id
	1B/FF-12374-7BE022F4; Fri, 27 Jan 2012 02:40:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327632054!12579378!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8983 invoked from network); 27 Jan 2012 02:40: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;
	27 Jan 2012 02:40:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,577,1320624000"; d="scan'208";a="10317347"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 02:40:53 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 02:40: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 1RqbkD-0004kU-Kk;
	Fri, 27 Jan 2012 02:40:53 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqbkD-00039a-CR;
	Fri, 27 Jan 2012 02:40:53 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11637-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 02:40:53 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11637: regressions - trouble:
	blocked/broken/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 11637 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11637/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64                   4 xen-build                 fail REGR. vs. 11601
 build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
 build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
 build-i386                    4 xen-build                 fail REGR. vs. 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  e2722b24dc09
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 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-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.

(No revision log; it would be 503 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 Jan 27 02:45:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 02: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 1RqboV-00038w-QL; Fri, 27 Jan 2012 02:45:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqboU-00038j-NY
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 02:45:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327632311!12155189!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11236 invoked from network); 27 Jan 2012 02:45:12 -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;
	27 Jan 2012 02:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,577,1320624000"; d="scan'208";a="10317359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 02:45: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, 27 Jan 2012 02:45:11 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RqboN-0004lq-2v;
	Fri, 27 Jan 2012 02:45:11 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqboN-0007hB-2J;
	Fri, 27 Jan 2012 02:45:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11638-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 02:45:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11638: regressions - trouble:
	blocked/broken/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 11638 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11638/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 10764
 build-amd64                   4 xen-build                 fail REGR. vs. 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    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-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-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-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 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-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.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 02:45:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 02: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 1RqboV-00038w-QL; Fri, 27 Jan 2012 02:45:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqboU-00038j-NY
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 02:45:19 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327632311!12155189!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11236 invoked from network); 27 Jan 2012 02:45:12 -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;
	27 Jan 2012 02:45:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,577,1320624000"; d="scan'208";a="10317359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 02:45: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, 27 Jan 2012 02:45:11 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RqboN-0004lq-2v;
	Fri, 27 Jan 2012 02:45:11 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RqboN-0007hB-2J;
	Fri, 27 Jan 2012 02:45:11 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11638-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 02:45:11 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11638: regressions - trouble:
	blocked/broken/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 11638 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11638/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386                    4 xen-build                 fail REGR. vs. 10764
 build-amd64                   4 xen-build                 fail REGR. vs. 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    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-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-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-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 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-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.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 03:25:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 03:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqcQL-0004D1-Ky; Fri, 27 Jan 2012 03:24: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 1RqcQJ-0004Cw-7X
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 03:24:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327633679!8323854!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwOTQyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20161 invoked from network); 27 Jan 2012 03:08:01 -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; 27 Jan 2012 03:08:01 -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
	q0R37vhR017951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 03:07:57 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0R37tTc024651
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 03:07:56 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
	q0R37t3I006192; Thu, 26 Jan 2012 21:07:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 19:07:55 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3193E40183; Thu, 26 Jan 2012 22:05:33 -0500 (EST)
Date: Thu, 26 Jan 2012 22:05:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120127030533.GA20352@phenom.dumpdata.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
	<CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
	<20120125163910.GC23999@phenom.dumpdata.com>
	<20120125212214.GA29571@phenom.dumpdata.com>
	<4F212835020000780006F264@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F212835020000780006F264@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F22150D.00DF,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, socketpair@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Fwd: BUG in
 linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 09:17:25AM +0000, Jan Beulich wrote:
> >>> On 25.01.12 at 22:22, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > --- a/drivers/xen/xen-pciback/xenbus.c
> > +++ b/drivers/xen/xen-pciback/xenbus.c
> > @@ -206,8 +206,9 @@ static int xen_pcibk_publish_pci_dev(struct 
> > xen_pcibk_device *pdev,
> >  		goto out;
> >  	}
> >  
> > +	/* TODO: implement feature-use-decimal-for-devfn */
> >  	err = xenbus_printf(XBT_NIL, pdev->xdev->nodename, str,
> > -			    "%04x:%02x:%02x.%02x", domain, bus,
> > +			    "%04x:%02x:%02x.%1x", domain, bus,
> >  			    PCI_SLOT(devfn), PCI_FUNC(devfn));
> >  
> >  out:
> 
> If you are concerned about compatibility (as the added comment
> suggests), then removing the leading zero is not an option either.
> 
> However, as long as all parsers of the string use plain %x or %d,
> there's no issue here and you could as well use %d here too (as
> PCI functions are always in the 0-7 range, which is identically
> represented in octal [important for the case of a leading zero],
> decimal, and hex).
> 
> Bottom line - just add the comment here, and leave the format
> unchanged, or change the format to %d right away.

Yeah, I was thinking of leaving it as is. I think I got a bit overzealous
on changing all the patch sites and ignored my own comment.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 03:25:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 03:25:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqcQL-0004D1-Ky; Fri, 27 Jan 2012 03:24: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 1RqcQJ-0004Cw-7X
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 03:24:23 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327633679!8323854!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUwOTQyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20161 invoked from network); 27 Jan 2012 03:08:01 -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; 27 Jan 2012 03:08:01 -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
	q0R37vhR017951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 03:07:57 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0R37tTc024651
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 03:07:56 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
	q0R37t3I006192; Thu, 26 Jan 2012 21:07:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Thu, 26 Jan 2012 19:07:55 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3193E40183; Thu, 26 Jan 2012 22:05:33 -0500 (EST)
Date: Thu, 26 Jan 2012 22:05:33 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Message-ID: <20120127030533.GA20352@phenom.dumpdata.com>
References: <CAEmTpZHkKB29FLWqs0R=uD1zXBOJkfSstGgMM=8bA1VVXGT+wQ@mail.gmail.com>
	<CAEmTpZH+OeQO=RNBFh_+j_QCmPa8sGhV_OOqqsiKUMmjhBwESw@mail.gmail.com>
	<20120125163910.GC23999@phenom.dumpdata.com>
	<20120125212214.GA29571@phenom.dumpdata.com>
	<4F212835020000780006F264@nat28.tlf.novell.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F212835020000780006F264@nat28.tlf.novell.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090201.4F22150D.00DF,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, socketpair@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] Fwd: BUG in
 linux+v3.2.1/drivers/xen/xen-pciback/pci_stub.c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 09:17:25AM +0000, Jan Beulich wrote:
> >>> On 25.01.12 at 22:22, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > --- a/drivers/xen/xen-pciback/xenbus.c
> > +++ b/drivers/xen/xen-pciback/xenbus.c
> > @@ -206,8 +206,9 @@ static int xen_pcibk_publish_pci_dev(struct 
> > xen_pcibk_device *pdev,
> >  		goto out;
> >  	}
> >  
> > +	/* TODO: implement feature-use-decimal-for-devfn */
> >  	err = xenbus_printf(XBT_NIL, pdev->xdev->nodename, str,
> > -			    "%04x:%02x:%02x.%02x", domain, bus,
> > +			    "%04x:%02x:%02x.%1x", domain, bus,
> >  			    PCI_SLOT(devfn), PCI_FUNC(devfn));
> >  
> >  out:
> 
> If you are concerned about compatibility (as the added comment
> suggests), then removing the leading zero is not an option either.
> 
> However, as long as all parsers of the string use plain %x or %d,
> there's no issue here and you could as well use %d here too (as
> PCI functions are always in the 0-7 range, which is identically
> represented in octal [important for the case of a leading zero],
> decimal, and hex).
> 
> Bottom line - just add the comment here, and leave the format
> unchanged, or change the format to %d right away.

Yeah, I was thinking of leaving it as is. I think I got a bit overzealous
on changing all the patch sites and ignored my own comment.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 08:44:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 08:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqhOw-0000B8-Dd; Fri, 27 Jan 2012 08:43:18 +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 1RqhOu-0000B0-2A
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 08:43:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327653787!2396070!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14085 invoked from network); 27 Jan 2012 08:43:09 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 08:43:09 -0000
Received: by pbdx13 with SMTP id x13so10887835pbd.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 00:43: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;
	bh=ypjTt1HzSoFqna2fCJSn4syjK5frFbWoh12PmaW6Csc=;
	b=XNjtHZd5ugFtx1Qd2cIRhDg1sEnlhGcjiE9OHHF8YUC8ClPZy3URXtXBhpXxYKM7jV
	VHLhhQHod6isrHf9IxQPpAvrL/1eg3CuMAbl4WzT+8eJ87kVufZAldtbeNeI2w2Lk98x
	jLPpiFcuy52+I0IdUoyTCuo2eg/f+/8X0LxdY=
MIME-Version: 1.0
Received: by 10.68.120.72 with SMTP id la8mr12910402pbb.56.1327653787344; Fri,
	27 Jan 2012 00:43:07 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Fri, 27 Jan 2012 00:43:07 -0800 (PST)
In-Reply-To: <CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
Date: Fri, 27 Jan 2012 09:43:07 +0100
X-Google-Sender-Auth: Zra9YnKlt5L4VVbpO7uhxSDRZ1E
Message-ID: <CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 have a question regarding driver domains and root hard disks, if the
root hard disk (the one containing the kernel and ramdisk) is on a
driver domain, how can we pass the kernel to the Dom0? libvchan seems
like a good option to pass the kernel and ramdisk from driver domains
to Dom0, but I would like to hear opinions about that.

If kernel and ramdisk passing is not implemented, the only way to boot
from hard disk stored on driver domains is to extract the kernel and
ramdisk and store them on the Dom0.

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 Jan 27 08:44:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 08:44:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqhOw-0000B8-Dd; Fri, 27 Jan 2012 08:43:18 +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 1RqhOu-0000B0-2A
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 08:43:16 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327653787!2396070!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14085 invoked from network); 27 Jan 2012 08:43:09 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 08:43:09 -0000
Received: by pbdx13 with SMTP id x13so10887835pbd.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 00:43: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;
	bh=ypjTt1HzSoFqna2fCJSn4syjK5frFbWoh12PmaW6Csc=;
	b=XNjtHZd5ugFtx1Qd2cIRhDg1sEnlhGcjiE9OHHF8YUC8ClPZy3URXtXBhpXxYKM7jV
	VHLhhQHod6isrHf9IxQPpAvrL/1eg3CuMAbl4WzT+8eJ87kVufZAldtbeNeI2w2Lk98x
	jLPpiFcuy52+I0IdUoyTCuo2eg/f+/8X0LxdY=
MIME-Version: 1.0
Received: by 10.68.120.72 with SMTP id la8mr12910402pbb.56.1327653787344; Fri,
	27 Jan 2012 00:43:07 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Fri, 27 Jan 2012 00:43:07 -0800 (PST)
In-Reply-To: <CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<CAPLaKK6RsLQgVLCrnrjiLhmkPUHMdZe3K6Nvj7=UtfXmvi7COQ@mail.gmail.com>
	<20229.59079.535980.830271@mariner.uk.xensource.com>
	<CAPLaKK4KDTmOjudDJ9XUM1id3VTBibAomXTDw2AHX0g8Bs2Fpw@mail.gmail.com>
	<alpine.DEB.2.00.1201091211450.3150@kaball-desktop>
	<20235.9838.103514.619546@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101448030.3150@kaball-desktop>
	<20236.24780.865152.458124@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101619460.3150@kaball-desktop>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
Date: Fri, 27 Jan 2012 09:43:07 +0100
X-Google-Sender-Auth: Zra9YnKlt5L4VVbpO7uhxSDRZ1E
Message-ID: <CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 have a question regarding driver domains and root hard disks, if the
root hard disk (the one containing the kernel and ramdisk) is on a
driver domain, how can we pass the kernel to the Dom0? libvchan seems
like a good option to pass the kernel and ramdisk from driver domains
to Dom0, but I would like to hear opinions about that.

If kernel and ramdisk passing is not implemented, the only way to boot
from hard disk stored on driver domains is to extract the kernel and
ramdisk and store them on the Dom0.

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 Jan 27 09:30:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09:30:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqi7y-0001Cu-IA; Fri, 27 Jan 2012 09:29:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqi7w-0001CA-QF
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:29:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327656578!8405961!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32533 invoked from network); 27 Jan 2012 09:29:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 09:29:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 09:29: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, 27 Jan 2012 09:29:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 09:29:42 +0000
In-Reply-To: <osstest-11631-mainreport@xen.org>
References: <osstest-11631-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327656582.26983.124.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] 11631: regressions - trouble:
 blocked/broken/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 Thu, 2012-01-26 at 20:55 +0000, xen.org wrote:
> flight 11631 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11631/

Not relating to the failure but I've noticed these in the logs a few
times recently:
        Use of uninitialized value $r{"tree_linux"} in length at ./ts-xen-build line 31.
        Use of uninitialized value $r{"revision_seabios"} in length at ./ts-xen-build line 36.
        Use of uninitialized value $r{"tree_linux"} in length at ./ts-xen-build line 36.
        Use of uninitialized value $r{"revision_linux"} in length at ./ts-xen-build line 36.
        
Ian.

> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 11601
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
>  build-i386                    4 xen-build                 fail REGR. vs. 11601
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-win7-amd64  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
>  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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
> 
> version targeted for testing:
>  xen                  e2722b24dc09
> baseline version:
>  xen                  4271634e4c86
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Adin Scanneell <adin@scannell.ca>
>   Adin Scannell <adin@scannell.ca>
>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Andres Lagar-Cavilla <andres@scannell.ca>
>   George Dunlap <george.dunlap@eu.citrix.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Jim Fehlig <jfehlig@suse.com>
>   Keir Fraser <keir@xen.org>
>   Olaf Hering <olaf@aepfle.de>
>   Roger Pau Monne <roger.pau@entel.upc.edu>
>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Tim Deegan <tim@xen.org>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  broken  
>  build-i386                                                   broken  
>  build-amd64-oldkern                                          broken  
>  build-i386-oldkern                                           broken  
>  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-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.
> 
> (No revision log; it would be 503 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 Jan 27 09:30:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09:30:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqi7y-0001Cu-IA; Fri, 27 Jan 2012 09:29:50 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqi7w-0001CA-QF
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:29:49 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327656578!8405961!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32533 invoked from network); 27 Jan 2012 09:29:42 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 09:29:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322105"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 09:29: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, 27 Jan 2012 09:29:42 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 09:29:42 +0000
In-Reply-To: <osstest-11631-mainreport@xen.org>
References: <osstest-11631-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327656582.26983.124.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] 11631: regressions - trouble:
 blocked/broken/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 Thu, 2012-01-26 at 20:55 +0000, xen.org wrote:
> flight 11631 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11631/

Not relating to the failure but I've noticed these in the logs a few
times recently:
        Use of uninitialized value $r{"tree_linux"} in length at ./ts-xen-build line 31.
        Use of uninitialized value $r{"revision_seabios"} in length at ./ts-xen-build line 36.
        Use of uninitialized value $r{"tree_linux"} in length at ./ts-xen-build line 36.
        Use of uninitialized value $r{"revision_linux"} in length at ./ts-xen-build line 36.
        
Ian.

> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 11601
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
>  build-i386                    4 xen-build                 fail REGR. vs. 11601
> 
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pv           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
>  test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-sedf-pin  1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
>  test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
>  test-amd64-i386-xl-win7-amd64  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
>  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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
> 
> version targeted for testing:
>  xen                  e2722b24dc09
> baseline version:
>  xen                  4271634e4c86
> 
> ------------------------------------------------------------
> People who touched revisions under test:
>   Adin Scanneell <adin@scannell.ca>
>   Adin Scannell <adin@scannell.ca>
>   Andres Lagar-Cavilla <andres@lagarcavilla.org>
>   Andres Lagar-Cavilla <andres@scannell.ca>
>   George Dunlap <george.dunlap@eu.citrix.com>
>   Ian Campbell <ian.campbell@citrix.com>
>   Ian Jackson <ian.jackson@eu.citrix.com>
>   Jan Beulich <jbeulich@suse.com>
>   Jim Fehlig <jfehlig@suse.com>
>   Keir Fraser <keir@xen.org>
>   Olaf Hering <olaf@aepfle.de>
>   Roger Pau Monne <roger.pau@entel.upc.edu>
>   Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>   Tim Deegan <tim@xen.org>
> ------------------------------------------------------------
> 
> jobs:
>  build-amd64                                                  broken  
>  build-i386                                                   broken  
>  build-amd64-oldkern                                          broken  
>  build-i386-oldkern                                           broken  
>  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-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.
> 
> (No revision log; it would be 503 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 Jan 27 09:30:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09:30:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqi7t-0001CF-VM; Fri, 27 Jan 2012 09:29: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 1Rqi7s-0001C9-Fb
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:29:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327656578!8405961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32315 invoked from network); 27 Jan 2012 09:29:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 09:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 09:29:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 09:29:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>
Date: Fri, 27 Jan 2012 09:29:37 +0000
In-Reply-To: <osstest-11627-mainreport@xen.org>
References: <osstest-11627-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327656578.26983.123.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] 11627: 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

On Thu, 2012-01-26 at 20:11 +0000, xen.org wrote:
> flight 11627 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11627/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 11601
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
>  build-i386                    4 xen-build                 fail REGR. vs. 11601

These are all:
        version mismatch! revision_qemuu requested=85a4ca797dbe25f27df0a66aa4df1cab63245cd3 built=6dd84c71dff047f9e492d67e7c99928d09202760
        BROKEN: version mismatches (1); marked 11627.build-i386-oldkern broken at Osstest.pm line 441.

85a4ca797dbe25f27df0a66aa4df1cab63245cd3 is the current head and
6dd84c71dff047f9e492d67e7c99928d09202760 was quite some time ago.

The clone was an http based one, so normally I would expect this to be a
missing "git update-server-info" but I checked this with Stefano
yesterday and confirmed that the correct post-update hook was in place.

I manually cloned the tree and saw the same behaviour.

I've just noticed that this was a clone of the non-staging tree (and I
propagated that via cut and paste into my test). I suppose it is
possible that the script which pushes from staging->main is not updating
the server info or that there has been some manual activity while things
were getting set up.

I've done "git update-server-info" in both the staging and non-staging
qemu-upstream-xen.git and my manual clone has come up with the correct
HEAD.

Stefano, next time you have cause to push please could you do a quick
manual clone via the http URL just to check that things are working
correctly.

>  build-amd64-pvops             4 kernel-build              fail REGR. vs. 11601

This one is:
        + git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux
        using cache /volatile/git-cache...
        using cache /volatile/git-cache...
        locked cache /volatile/git-cache...
        processing /usr/local/bin/git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux...
        Cloning into linux...
        fatal: The remote end hung up unexpectedly
        
Which is presumably an external failure which also explains the
subsequent linux test failure. Everything looks OK to me now so I assume
it was a transient issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 09:30:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09:30:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqi7t-0001CF-VM; Fri, 27 Jan 2012 09:29: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 1Rqi7s-0001C9-Fb
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:29:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327656578!8405961!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32315 invoked from network); 27 Jan 2012 09:29:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 09:29:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322104"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 09:29:38 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 09:29:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>, Stefano Stabellini
	<stefano.stabellini@citrix.com>
Date: Fri, 27 Jan 2012 09:29:37 +0000
In-Reply-To: <osstest-11627-mainreport@xen.org>
References: <osstest-11627-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327656578.26983.123.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] 11627: 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

On Thu, 2012-01-26 at 20:11 +0000, xen.org wrote:
> flight 11627 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11627/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   4 xen-build                 fail REGR. vs. 11601
>  build-amd64-oldkern           4 xen-build                 fail REGR. vs. 11601
>  build-i386-oldkern            4 xen-build                 fail REGR. vs. 11601
>  build-i386                    4 xen-build                 fail REGR. vs. 11601

These are all:
        version mismatch! revision_qemuu requested=85a4ca797dbe25f27df0a66aa4df1cab63245cd3 built=6dd84c71dff047f9e492d67e7c99928d09202760
        BROKEN: version mismatches (1); marked 11627.build-i386-oldkern broken at Osstest.pm line 441.

85a4ca797dbe25f27df0a66aa4df1cab63245cd3 is the current head and
6dd84c71dff047f9e492d67e7c99928d09202760 was quite some time ago.

The clone was an http based one, so normally I would expect this to be a
missing "git update-server-info" but I checked this with Stefano
yesterday and confirmed that the correct post-update hook was in place.

I manually cloned the tree and saw the same behaviour.

I've just noticed that this was a clone of the non-staging tree (and I
propagated that via cut and paste into my test). I suppose it is
possible that the script which pushes from staging->main is not updating
the server info or that there has been some manual activity while things
were getting set up.

I've done "git update-server-info" in both the staging and non-staging
qemu-upstream-xen.git and my manual clone has come up with the correct
HEAD.

Stefano, next time you have cause to push please could you do a quick
manual clone via the http URL just to check that things are working
correctly.

>  build-amd64-pvops             4 kernel-build              fail REGR. vs. 11601

This one is:
        + git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux
        using cache /volatile/git-cache...
        using cache /volatile/git-cache...
        locked cache /volatile/git-cache...
        processing /usr/local/bin/git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux...
        Cloning into linux...
        fatal: The remote end hung up unexpectedly
        
Which is presumably an external failure which also explains the
subsequent linux test failure. Everything looks OK to me now so I assume
it was a transient issue.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 09:30:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09:30:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqi86-0001Du-VA; Fri, 27 Jan 2012 09:29: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 1Rqi85-0001DC-NC
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:29:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327656571!64133989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32378 invoked from network); 27 Jan 2012 09:29:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 09:29:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 09:29: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, 27 Jan 2012 09:29:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 09:29:51 +0000
In-Reply-To: <osstest-11628-mainreport@xen.org>
References: <osstest-11628-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327656591.26983.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] [qemu-upstream-unstable test] 11628: trouble:
 blocked/broken/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 Thu, 2012-01-26 at 20:49 +0000, xen.org wrote:
> flight 11628 qemu-upstream-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11628/
> 
> 
> jobs:
>  build-amd64                                                  broken  
>  build-i386                                                   broken  
>  build-amd64-oldkern                                          broken  
>  build-i386-oldkern                                           broken  

These are the same version mismatch as I described on the xen-unstable
test failure.

I did notice that this one was also cloning the non-staging tree. Is
this not the push gateway test?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 09:30:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09:30:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqi86-0001Du-VA; Fri, 27 Jan 2012 09:29: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 1Rqi85-0001DC-NC
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:29:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327656571!64133989!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32378 invoked from network); 27 Jan 2012 09:29:31 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 09:29:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 09:29: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, 27 Jan 2012 09:29:51 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 09:29:51 +0000
In-Reply-To: <osstest-11628-mainreport@xen.org>
References: <osstest-11628-mainreport@xen.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327656591.26983.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] [qemu-upstream-unstable test] 11628: trouble:
 blocked/broken/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 Thu, 2012-01-26 at 20:49 +0000, xen.org wrote:
> flight 11628 qemu-upstream-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11628/
> 
> 
> jobs:
>  build-amd64                                                  broken  
>  build-i386                                                   broken  
>  build-amd64-oldkern                                          broken  
>  build-i386-oldkern                                           broken  

These are the same version mismatch as I described on the xen-unstable
test failure.

I did notice that this one was also cloning the non-staging tree. Is
this not the push gateway test?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 09:52:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09:52:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqiT0-0001uH-Lz; Fri, 27 Jan 2012 09:51:34 +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 1RqiSy-0001uC-Rq
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:51:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327657839!51953085!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2061 invoked from network); 27 Jan 2012 09:50:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Jan 2012 09:50:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327657887; l=974;
	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=P4FElrXnejxK8bZCOmO6/eks2mc=;
	b=G1nr+PNFRrGpKKNgP3GMvpNAhWonsdsByhJTQFe+dzJTiWfncKCe5UTAaweTGpkcK0I
	cU0XLPMtlyZUC/l7n5actrpfto9sV8GFm3V1muBW2ukStDkwvYSW/7mQTkIVYT5dRkXiU
	3a04hfMaKTtC6r3cKkMT0sLirsx/O/pXFkA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhy0MFy6a
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-099-249.pools.arcor-ip.net [88.65.99.249])
	by smtp.strato.de (fruni mo28) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 30401bo0R9EqFZ ;
	Fri, 27 Jan 2012 10:51:18 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7047218637; Fri, 27 Jan 2012 10:51:20 +0100 (CET)
Date: Fri, 27 Jan 2012 10:51:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120127095120.GA12283@aepfle.de>
References: <E1RqT39-0004qP-B6@woking.xci-test.com>
	<20257.36117.343474.863135@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20257.36117.343474.863135@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [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

On Thu, Jan 26, Ian Jackson wrote:

> cc1: warnings being treated as errors
> xc_mem_paging.c: In function 'xc_mem_paging_load':
> xc_mem_paging.c:90: error: statement with no effect
> make[3]: *** [xc_mem_paging.o] Error 1
> make[3]: Leaving directory `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
> make[2]: *** [build] Error 2
> make[2]: Leaving directory `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
> make[1]: *** [libxc-x86_64/libxenctrl.a] Error 2
> make[1]: *** Waiting for unfinished jobs....

As Andrew Morton put it once: "We code in C, not in cpp".

extras/mini-os/include/posix/sys/mman.h:19:#define munlock(addr, len) ((void)(addr), (void)(len), 0)

As such, that define should be "static inline munlock(const void *addr, size_t len) { return 0; }".
And now that I actually look at that header, mlock should be changed as
well. All this "(void)fn()" mess is really confusing.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 09:52:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09:52:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqiT0-0001uH-Lz; Fri, 27 Jan 2012 09:51:34 +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 1RqiSy-0001uC-Rq
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:51:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327657839!51953085!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2061 invoked from network); 27 Jan 2012 09:50:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Jan 2012 09:50:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327657887; l=974;
	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=P4FElrXnejxK8bZCOmO6/eks2mc=;
	b=G1nr+PNFRrGpKKNgP3GMvpNAhWonsdsByhJTQFe+dzJTiWfncKCe5UTAaweTGpkcK0I
	cU0XLPMtlyZUC/l7n5actrpfto9sV8GFm3V1muBW2ukStDkwvYSW/7mQTkIVYT5dRkXiU
	3a04hfMaKTtC6r3cKkMT0sLirsx/O/pXFkA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhy0MFy6a
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-099-249.pools.arcor-ip.net [88.65.99.249])
	by smtp.strato.de (fruni mo28) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 30401bo0R9EqFZ ;
	Fri, 27 Jan 2012 10:51:18 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 7047218637; Fri, 27 Jan 2012 10:51:20 +0100 (CET)
Date: Fri, 27 Jan 2012 10:51:20 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <20120127095120.GA12283@aepfle.de>
References: <E1RqT39-0004qP-B6@woking.xci-test.com>
	<20257.36117.343474.863135@mariner.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20257.36117.343474.863135@mariner.uk.xensource.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, Andres Lagar-Cavilla <andres@lagarcavilla.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [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

On Thu, Jan 26, Ian Jackson wrote:

> cc1: warnings being treated as errors
> xc_mem_paging.c: In function 'xc_mem_paging_load':
> xc_mem_paging.c:90: error: statement with no effect
> make[3]: *** [xc_mem_paging.o] Error 1
> make[3]: Leaving directory `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
> make[2]: *** [build] Error 2
> make[2]: Leaving directory `/home/osstest/build.11617.build-amd64/xen-unstable/stubdom/libxc-x86_64'
> make[1]: *** [libxc-x86_64/libxenctrl.a] Error 2
> make[1]: *** Waiting for unfinished jobs....

As Andrew Morton put it once: "We code in C, not in cpp".

extras/mini-os/include/posix/sys/mman.h:19:#define munlock(addr, len) ((void)(addr), (void)(len), 0)

As such, that define should be "static inline munlock(const void *addr, size_t len) { return 0; }".
And now that I actually look at that header, mlock should be changed as
well. All this "(void)fn()" mess is really confusing.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 09:54:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09: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 1RqiVg-00020A-85; Fri, 27 Jan 2012 09:54:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqiVf-0001zz-AG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:54:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327658051!10200512!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30462 invoked from network); 27 Jan 2012 09:54:11 -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;
	27 Jan 2012 09:54:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 09:54: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;
	Fri, 27 Jan 2012 09:54:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 09:54:10 +0000
In-Reply-To: <1327607111-15394-6-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-6-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327658050.26983.142.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 05/24] xen: Preserve reserved grant entries
 when switching 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

It would be worth CCing the relevant maintainers for each patch in the
series. e.g. Keir in this case.

On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> In order for the toolstack to use reserved grant table entries, the
> grant table for a guest must be initialized prior to the guest's boot.
> When the guest switches grant table versions (necessary if the guest is
> using v2 grant tables, or on kexec if switching grant versions), these
> initial grants will be cleared. Instead of clearing them, preserve
> the grants across the type change.
> 
> Attempting to preserve v2-only features such as sub-page grants will
> produce a warning and invalidate the resulting v1 grant entry.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
>  xen/include/public/grant_table.h |    7 +++++
>  2 files changed, 49 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 0c55fd1..6f24a94 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      struct domain *d = current->domain;
>      struct grant_table *gt = d->grant_table;
>      struct active_grant_entry *act;
> +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
>      long res;
>      int i;
>  
> @@ -2131,7 +2132,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      /* (You need to change the version number for e.g. kexec.) */
>      if ( gt->gt_version != 0 )
>      {
> -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )

The comment just prior says:
    /* Make sure that the grant table isn't currently in use when we
       change the version number. */
I think this needs updating to note that we do allow reserved entries to
be active during the switch over and we will correctly preserve
flags/status/mapped-ness etc.

>          {
>              act = &active_entry(gt, i);
>              if ( act->pin != 0 )
> @@ -2156,15 +2157,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>              goto out_unlock;
>      }
>  
> +    /* Preserve the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version == 1)

Xen coding style has extra spaces just inside the braces (and again
below a few more times).

> +    {
> +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));

Shouldn't that be either "gt->shared_v1" or "&gt->shared_v1[0]" ?

> +    }
> +    else if (gt->gt_version == 2)
> +    {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
> +        {
> +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> +            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
> +            reserved_entries[i].flags |= status_entry(gt, i);
> +            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)

In effect this only allows GTF_permit_access or GTF_invalid, which is
good. It would be more obvious/explicit to do
	if ((shared_entry_v2(gt, i).hdr.flags & GTF_type_mask) != GTF_invalid &&
	    (shared_entry_v2(gt, i).hdr.flags & GTF_type_mask) != GTF_permit_access)
		memset-whole-entry and continue;
at the top or even a switch().

> +            {
> +                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
> +                       d->domain_id, reserved_entries[i].flags, i);
> +                reserved_entries[i].flags = GTF_invalid;
> +            }
> +        }
> +    }
> +
>      if ( op.version < 2 && gt->gt_version == 2 )
>          gnttab_unpopulate_status_frames(d, gt);
>  
> -    if ( op.version != gt->gt_version )
> +    /* Make sure there's no crud left over in the table from the
> +       old version. */
> +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +
> +    /* Restore the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version != 0 && op.version == 1)
>      {
> -        /* Make sure there's no crud left over in the table from the
> -           old version. */
> -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> +    }
> +    else if (gt->gt_version != 0 && op.version == 2)
> +    {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> +        {
> +            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);

> +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> +            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
> +        }
>      }
>  
>      gt->gt_version = op.version;
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 54d9551..292d724 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -117,6 +117,13 @@ struct grant_entry_v1 {
>  };
>  typedef struct grant_entry_v1 grant_entry_v1_t;
>  
> +/* The first few grant table entries will be preserved across grant table
> + * version changes and may be pre-populated at domain creation by tools.
> + */
> +#define GNTTAB_NR_RESERVED_ENTRIES     8
> +#define GNTTAB_RESERVED_CONSOLE        0
> +#define GNTTAB_RESERVED_XENSTORE       1
> +
>  /*
>   * Type of grant entry.
>   *  GTF_invalid: This grant entry grants no privileges.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 09:54:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 09: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 1RqiVg-00020A-85; Fri, 27 Jan 2012 09:54:20 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqiVf-0001zz-AG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 09:54:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327658051!10200512!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30462 invoked from network); 27 Jan 2012 09:54:11 -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;
	27 Jan 2012 09:54:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322673"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 09:54: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;
	Fri, 27 Jan 2012 09:54:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 09:54:10 +0000
In-Reply-To: <1327607111-15394-6-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-6-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327658050.26983.142.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 05/24] xen: Preserve reserved grant entries
 when switching 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

It would be worth CCing the relevant maintainers for each patch in the
series. e.g. Keir in this case.

On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> In order for the toolstack to use reserved grant table entries, the
> grant table for a guest must be initialized prior to the guest's boot.
> When the guest switches grant table versions (necessary if the guest is
> using v2 grant tables, or on kexec if switching grant versions), these
> initial grants will be cleared. Instead of clearing them, preserve
> the grants across the type change.
> 
> Attempting to preserve v2-only features such as sub-page grants will
> produce a warning and invalidate the resulting v1 grant entry.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> ---
>  xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
>  xen/include/public/grant_table.h |    7 +++++
>  2 files changed, 49 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 0c55fd1..6f24a94 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      struct domain *d = current->domain;
>      struct grant_table *gt = d->grant_table;
>      struct active_grant_entry *act;
> +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
>      long res;
>      int i;
>  
> @@ -2131,7 +2132,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>      /* (You need to change the version number for e.g. kexec.) */
>      if ( gt->gt_version != 0 )
>      {
> -        for ( i = 0; i < nr_grant_entries(gt); i++ )
> +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )

The comment just prior says:
    /* Make sure that the grant table isn't currently in use when we
       change the version number. */
I think this needs updating to note that we do allow reserved entries to
be active during the switch over and we will correctly preserve
flags/status/mapped-ness etc.

>          {
>              act = &active_entry(gt, i);
>              if ( act->pin != 0 )
> @@ -2156,15 +2157,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>              goto out_unlock;
>      }
>  
> +    /* Preserve the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version == 1)

Xen coding style has extra spaces just inside the braces (and again
below a few more times).

> +    {
> +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));

Shouldn't that be either "gt->shared_v1" or "&gt->shared_v1[0]" ?

> +    }
> +    else if (gt->gt_version == 2)
> +    {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
> +        {
> +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
> +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
> +            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
> +            reserved_entries[i].flags |= status_entry(gt, i);
> +            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)

In effect this only allows GTF_permit_access or GTF_invalid, which is
good. It would be more obvious/explicit to do
	if ((shared_entry_v2(gt, i).hdr.flags & GTF_type_mask) != GTF_invalid &&
	    (shared_entry_v2(gt, i).hdr.flags & GTF_type_mask) != GTF_permit_access)
		memset-whole-entry and continue;
at the top or even a switch().

> +            {
> +                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
> +                       d->domain_id, reserved_entries[i].flags, i);
> +                reserved_entries[i].flags = GTF_invalid;
> +            }
> +        }
> +    }
> +
>      if ( op.version < 2 && gt->gt_version == 2 )
>          gnttab_unpopulate_status_frames(d, gt);
>  
> -    if ( op.version != gt->gt_version )
> +    /* Make sure there's no crud left over in the table from the
> +       old version. */
> +    for ( i = 0; i < nr_grant_frames(gt); i++ )
> +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +
> +    /* Restore the first 8 entries (toolstack reserved grants) */
> +    if (gt->gt_version != 0 && op.version == 1)
>      {
> -        /* Make sure there's no crud left over in the table from the
> -           old version. */
> -        for ( i = 0; i < nr_grant_frames(gt); i++ )
> -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
> +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
> +    }
> +    else if (gt->gt_version != 0 && op.version == 2)
> +    {
> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
> +        {
> +            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
> +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);

> +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
> +            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
> +        }
>      }
>  
>      gt->gt_version = op.version;
> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
> index 54d9551..292d724 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -117,6 +117,13 @@ struct grant_entry_v1 {
>  };
>  typedef struct grant_entry_v1 grant_entry_v1_t;
>  
> +/* The first few grant table entries will be preserved across grant table
> + * version changes and may be pre-populated at domain creation by tools.
> + */
> +#define GNTTAB_NR_RESERVED_ENTRIES     8
> +#define GNTTAB_RESERVED_CONSOLE        0
> +#define GNTTAB_RESERVED_XENSTORE       1
> +
>  /*
>   * Type of grant entry.
>   *  GTF_invalid: This grant entry grants no privileges.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:01:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:01:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqicF-0002HX-4G; Fri, 27 Jan 2012 10:01: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 1RqicD-0002HR-OZ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:01:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327658459!12747985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7382 invoked from network); 27 Jan 2012 10:00:59 -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;
	27 Jan 2012 10:00:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:00: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, 27 Jan 2012 10:00:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:00:58 +0000
In-Reply-To: <1327607111-15394-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-8-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327658459.26983.146.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/24] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> This patch claims one reserved grant entry for the console and another
> for the xenstore. It modifies the builder to fill in the grant table
> entries for the console and the xenstore.
> 
> Previous versions of this patch have been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

If you use domid_t and xen_pfn_t where appropriate (includes mfn, gmfn
etc) then:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Also moving the scratch pfn #define into a header (may as well be
xc_dom.h until/unless somewhere move appropriate comes up) still seems
like a good idea.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:01:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:01:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqicF-0002HX-4G; Fri, 27 Jan 2012 10:01: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 1RqicD-0002HR-OZ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:01:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327658459!12747985!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTI5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7382 invoked from network); 27 Jan 2012 10:00:59 -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;
	27 Jan 2012 10:00:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322831"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:00: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, 27 Jan 2012 10:00:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:00:58 +0000
In-Reply-To: <1327607111-15394-8-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-8-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327658459.26983.146.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 07/24] lib{xc,
 xl}: Seed grant tables with xenstore and console 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 Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> 
> This patch claims one reserved grant entry for the console and another
> for the xenstore. It modifies the builder to fill in the grant table
> entries for the console and the xenstore.
> 
> Previous versions of this patch have been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

If you use domid_t and xen_pfn_t where appropriate (includes mfn, gmfn
etc) then:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Also moving the scratch pfn #define into a header (may as well be
xc_dom.h until/unless somewhere move appropriate comes up) still seems
like a good idea.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:04:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqifb-0002O4-PF; Fri, 27 Jan 2012 10:04: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 1Rqifa-0002Ny-1f
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:04:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327658648!50474047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32471 invoked from network); 27 Jan 2012 10:04:08 -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;
	27 Jan 2012 10:04:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322922"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:04: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, 27 Jan 2012 10:04:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:04:29 +0000
In-Reply-To: <1327607111-15394-11-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-11-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327658669.26983.148.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 10/24] mini-os: create app-specific
 configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
> code, create CONFIG_ items for features and use application-specific
> configuration files to enable or disable the features.
> 
> The configuration flags are currently added to the compiler command
> line; as the number of flags grows this may need to move to a header.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
> new file mode 100644
> index 0000000..e69de29
> diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
> new file mode 100644
> index 0000000..e69de29

These are new empty files? That's ok -- just wanted to check there
wasn't some patch weirdness happening.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:04:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqifb-0002O4-PF; Fri, 27 Jan 2012 10:04: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 1Rqifa-0002Ny-1f
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:04:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327658648!50474047!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32471 invoked from network); 27 Jan 2012 10:04:08 -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;
	27 Jan 2012 10:04:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322922"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:04: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, 27 Jan 2012 10:04:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:04:29 +0000
In-Reply-To: <1327607111-15394-11-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-11-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327658669.26983.148.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 10/24] mini-os: create app-specific
 configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
> code, create CONFIG_ items for features and use application-specific
> configuration files to enable or disable the features.
> 
> The configuration flags are currently added to the compiler command
> line; as the number of flags grows this may need to move to a header.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
> new file mode 100644
> index 0000000..e69de29
> diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
> new file mode 100644
> index 0000000..e69de29

These are new empty files? That's ok -- just wanted to check there
wasn't some patch weirdness happening.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:06:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:06:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqigx-0002VO-Ed; Fri, 27 Jan 2012 10:05:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqigw-0002VE-Ly
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:05:58 +0000
Received: from [85.158.138.51:45240] by server-10.bemta-3.messagelabs.com id
	2D/91-20948-507722F4; Fri, 27 Jan 2012 10:05:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327658756!10906026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28675 invoked from network); 27 Jan 2012 10:05:57 -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;
	27 Jan 2012 10:05:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:05:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 10:05:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:05:55 +0000
In-Reply-To: <1327607111-15394-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327658755.26983.149.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 11/24] mini-os: Move test functions into
 test.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 Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> While useful, these test functions should not be compiled into every
> mini-os instance that we compile.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

On the assumption that this is pure code motion and minimal changes to
support the new location I didn't look closely but:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:06:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:06:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqigx-0002VO-Ed; Fri, 27 Jan 2012 10:05:59 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqigw-0002VE-Ly
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:05:58 +0000
Received: from [85.158.138.51:45240] by server-10.bemta-3.messagelabs.com id
	2D/91-20948-507722F4; Fri, 27 Jan 2012 10:05:57 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327658756!10906026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28675 invoked from network); 27 Jan 2012 10:05:57 -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;
	27 Jan 2012 10:05:57 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10322964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:05:56 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 10:05:56 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:05:55 +0000
In-Reply-To: <1327607111-15394-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-12-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327658755.26983.149.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 11/24] mini-os: Move test functions into
 test.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 Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> While useful, these test functions should not be compiled into every
> mini-os instance that we compile.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

On the assumption that this is pure code motion and minimal changes to
support the new location I didn't look closely but:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:09:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqikG-0002if-2f; Fri, 27 Jan 2012 10:09:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RqikE-0002iO-FP
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:09:22 +0000
Received: from [85.158.139.83:31560] by server-8.bemta-5.messagelabs.com id
	3C/60-31172-1D7722F4; Fri, 27 Jan 2012 10:09:21 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327658961!5283183!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21483 invoked from network); 27 Jan 2012 10:09:21 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.206)
	by server-16.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Jan 2012 10:09:21 -0000
Received: from mail33-am1-R.bigfish.com (10.3.201.228) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 27 Jan 2012 10:09:20 +0000
Received: from mail33-am1 (localhost [127.0.0.1])	by mail33-am1-R.bigfish.com
	(Postfix) with ESMTP id DE4351A0647;
	Fri, 27 Jan 2012 10:09:20 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail33-am1 (localhost.localdomain [127.0.0.1]) by mail33-am1
	(MessageSwitch) id 1327658958144292_28014;
	Fri, 27 Jan 2012 10:09:18 +0000 (UTC)
Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.233])	by
	mail33-am1.bigfish.com (Postfix) with ESMTP id 1D397120046;
	Fri, 27 Jan 2012 10:09:18 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS019.bigfish.com (10.3.206.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 27 Jan 2012 10:09:17 +0000
X-WSS-ID: 0LYGC7G-01-2SX-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 2CA0F10280BD;	Fri, 27 Jan 2012 04:09: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;
	Fri, 27 Jan 2012 04:09:33 -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, 27 Jan 2012 04:09: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; Fri, 27 Jan 2012
	05:09:15 -0500
Message-ID: <4F2277C9.10207@amd.com>
Date: Fri, 27 Jan 2012 11:09:13 +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: Tim Deegan <tim@xen.org>
References: <20120119161626.GO66164@ocelot.phlegethon.org>
	<20120126154504.GA80228@ocelot.phlegethon.org>
In-Reply-To: <20120126154504.GA80228@ocelot.phlegethon.org>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] RFC PATCH: bring OpenBSD stdarg in line with
 FreeBSD one
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/26/12 16:45, Tim Deegan wrote:
> At 16:16 +0000 on 19 Jan (1326989786), Tim Deegan wrote:
>> Having an absolute path in a #include confuses distcc's pump mode.
>> Since AFAICS OpenBSD's stdarg handling uses the builtins, I think we
>> should just treat it like we do NetBSD.
>>
>> I don't have an OpenBSD box to test on, though. :(  Any OpenBSD
>> enthusiasts care to comment?
>
> No complaints, and the new header compiles on OpenBSD, so I've applied it.

... the commit message does not match what the actually patch does.
You mixed up FreeBSD with NetBSD. :-)

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:09:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqikG-0002if-2f; Fri, 27 Jan 2012 10:09:24 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RqikE-0002iO-FP
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:09:22 +0000
Received: from [85.158.139.83:31560] by server-8.bemta-5.messagelabs.com id
	3C/60-31172-1D7722F4; Fri, 27 Jan 2012 10:09:21 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327658961!5283183!1
X-Originating-IP: [213.199.154.206]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21483 invoked from network); 27 Jan 2012 10:09:21 -0000
Received: from am1ehsobe003.messaging.microsoft.com (HELO
	AM1EHSOBE001.bigfish.com) (213.199.154.206)
	by server-16.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Jan 2012 10:09:21 -0000
Received: from mail33-am1-R.bigfish.com (10.3.201.228) by
	AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 27 Jan 2012 10:09:20 +0000
Received: from mail33-am1 (localhost [127.0.0.1])	by mail33-am1-R.bigfish.com
	(Postfix) with ESMTP id DE4351A0647;
	Fri, 27 Jan 2012 10:09:20 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h)
X-Forefront-Antispam-Report: CIP:163.181.249.108; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp01.amd.com; RD:none; EFVD:NLI
Received: from mail33-am1 (localhost.localdomain [127.0.0.1]) by mail33-am1
	(MessageSwitch) id 1327658958144292_28014;
	Fri, 27 Jan 2012 10:09:18 +0000 (UTC)
Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.233])	by
	mail33-am1.bigfish.com (Postfix) with ESMTP id 1D397120046;
	Fri, 27 Jan 2012 10:09:18 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS019.bigfish.com (10.3.206.22) with Microsoft SMTP Server id
	14.1.225.23; Fri, 27 Jan 2012 10:09:17 +0000
X-WSS-ID: 0LYGC7G-01-2SX-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 2CA0F10280BD;	Fri, 27 Jan 2012 04:09: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;
	Fri, 27 Jan 2012 04:09:33 -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, 27 Jan 2012 04:09: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; Fri, 27 Jan 2012
	05:09:15 -0500
Message-ID: <4F2277C9.10207@amd.com>
Date: Fri, 27 Jan 2012 11:09:13 +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: Tim Deegan <tim@xen.org>
References: <20120119161626.GO66164@ocelot.phlegethon.org>
	<20120126154504.GA80228@ocelot.phlegethon.org>
In-Reply-To: <20120126154504.GA80228@ocelot.phlegethon.org>
X-OriginatorOrg: amd.com
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] RFC PATCH: bring OpenBSD stdarg in line with
 FreeBSD one
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/26/12 16:45, Tim Deegan wrote:
> At 16:16 +0000 on 19 Jan (1326989786), Tim Deegan wrote:
>> Having an absolute path in a #include confuses distcc's pump mode.
>> Since AFAICS OpenBSD's stdarg handling uses the builtins, I think we
>> should just treat it like we do NetBSD.
>>
>> I don't have an OpenBSD box to test on, though. :(  Any OpenBSD
>> enthusiasts care to comment?
>
> No complaints, and the new header compiles on OpenBSD, so I've applied it.

... the commit message does not match what the actually patch does.
You mixed up FreeBSD with NetBSD. :-)

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:12:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqin4-0002s8-NY; Fri, 27 Jan 2012 10:12: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 1Rqin3-0002ry-Bo
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:12:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327659131!8572960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4221 invoked from network); 27 Jan 2012 10:12:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:12:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323149"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:12: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;
	Fri, 27 Jan 2012 10:12:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:12:10 +0000
In-Reply-To: <1327607111-15394-13-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-13-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327659130.26983.153.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/24] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> This adds compile-time logic to disable certain frontends in mini-os:
>  - pcifront is disabled by default, enabled for ioemu
>  - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default
>  - xenbus is required for any frontend, and is enabled by default
> 
> If all frontends and xenbus are disabled, mini-os will run without
> needing to communicate with xenstore, making it suitable to run the
> xenstore daemon. The console frontend is not required for the initial
> console, only consoles opened via openpt or ptmx.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

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 Jan 27 10:12:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:12:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqin4-0002s8-NY; Fri, 27 Jan 2012 10:12: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 1Rqin3-0002ry-Bo
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:12:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327659131!8572960!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4221 invoked from network); 27 Jan 2012 10:12:11 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:12:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323149"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:12: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;
	Fri, 27 Jan 2012 10:12:11 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:12:10 +0000
In-Reply-To: <1327607111-15394-13-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-13-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327659130.26983.153.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/24] mini-os: make frontends and xenbus
 optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
> This adds compile-time logic to disable certain frontends in mini-os:
>  - pcifront is disabled by default, enabled for ioemu
>  - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default
>  - xenbus is required for any frontend, and is enabled by default
> 
> If all frontends and xenbus are disabled, mini-os will run without
> needing to communicate with xenstore, making it suitable to run the
> xenstore daemon. The console frontend is not required for the initial
> console, only consoles opened via openpt or ptmx.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

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 Jan 27 10:17:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqirk-00034s-Ec; Fri, 27 Jan 2012 10:17:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqiri-00034l-Da
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:17:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327659403!50476829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28695 invoked from network); 27 Jan 2012 10:16:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:16:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10: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;
	Fri, 27 Jan 2012 10:17:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:17:03 +0000
In-Reply-To: <1327607111-15394-16-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-16-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327659425.26983.154.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/24] xenstored: refactor socket 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

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:17:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqirk-00034s-Ec; Fri, 27 Jan 2012 10:17:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqiri-00034l-Da
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:17:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327659403!50476829!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28695 invoked from network); 27 Jan 2012 10:16:43 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:16:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323273"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10: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;
	Fri, 27 Jan 2012 10:17:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:17:03 +0000
In-Reply-To: <1327607111-15394-16-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-16-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327659425.26983.154.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/24] xenstored: refactor socket 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

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:21:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqivW-0003DC-3X; Fri, 27 Jan 2012 10:21:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqivT-0003D5-Mm
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:20:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327659611!51806858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3278 invoked from network); 27 Jan 2012 10:20:11 -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;
	27 Jan 2012 10:20:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323364"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:20: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, 27 Jan 2012 10:20:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:20:58 +0000
In-Reply-To: <1327607111-15394-17-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-17-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327659658.26983.156.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 16/24] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Add option for compiling xenstored without unix sockets to support
> running on mini-OS
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

The lack of error return/handling from accept_connection seems odd to me
but that was there already.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:21:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqivW-0003DC-3X; Fri, 27 Jan 2012 10:21:02 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqivT-0003D5-Mm
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:20:59 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1327659611!51806858!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3278 invoked from network); 27 Jan 2012 10:20:11 -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;
	27 Jan 2012 10:20:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323364"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:20: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, 27 Jan 2012 10:20:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:20:58 +0000
In-Reply-To: <1327607111-15394-17-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-17-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327659658.26983.156.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 16/24] xenstored: add NO_SOCKETS compilation
 option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Add option for compiling xenstored without unix sockets to support
> running on mini-OS
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

The lack of error return/handling from accept_connection seems odd to me
but that was there already.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:21:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:21:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqivj-0003Eo-Gt; Fri, 27 Jan 2012 10:21: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 1Rqivh-0003Dx-Ks
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:21:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327659662!4263232!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12071 invoked from network); 27 Jan 2012 10:21:07 -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;
	27 Jan 2012 10:21:07 -0000
Received: by dajs34 with SMTP id s34so9946897daj.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 02:21: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=x5VDMgf9BmEx0lhySaxe72Q5/KkGfweg2pxex/+6mjc=;
	b=UNc4V9d3IKWZ8q/VchwqqWlkoshYY1Jj4h802h0k3txaJj8JYae6wy2NHnIvRh9ju1
	8rDxV9arbFjk8RAnpJKnhyxw8/k2mZvxoNVQHqQsYoU6x0yNKeaZYbVrOI+1UJLAePfn
	KNJVxxp9pd66JMkKamfCKtLmJCtkmHCjX4LRw=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr13586218pbc.5.1327659661792; Fri,
	27 Jan 2012 02:21:01 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Fri, 27 Jan 2012 02:21:01 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
References: <patchbomb.1326880685@loki.upc.es>
	<b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
	<alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
Date: Fri, 27 Jan 2012 11:21:01 +0100
X-Google-Sender-Auth: ltRHQyH3F-N5LonS5IhEPvqOvEQ
Message-ID: <CAPLaKK6oY4ReczaaYcz63oMooageqzBaoYs3h=Z5AaemU3sUFA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 13 RFC] libxl: destroy devices before
 device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI2IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Ogo+IE9uIFdlZCwgMTggSmFuIDIwMTIsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzI2NzI4NDcyIC0zNjAwCj4+ICMgTm9kZSBJRCBi
NWQ2M2NmOTBkNGVmOGQyMjJhZTI4MmUyNzliOTBiN2Y3M2YxOGMzCj4+ICMgUGFyZW50IMKgNTg0
OWJmN2M0NTA3ZWRiZTkwMGRlMDAzMzJmMTIxOGRlMmQ5ZjQ1Zgo+PiBsaWJ4bDogZGVzdHJveSBk
ZXZpY2VzIGJlZm9yZSBkZXZpY2UgbW9kZWwKPj4KPj4gRGVzdHJveWluZyB0aGUgZGV2aWNlIG1v
ZGVsIGJlZm9yZSB1bnBsdWdnaW5nIHRoZSBkZXZpY2VzIHByZXZlbnRlZAo+PiBmcm9tIGRvaW5n
IGEgY2xlYW4gdW5wbHVnLCBzaW5jZSBsaWJ4bCB3YXMgd2FpdGluZyBmb3IgZG0gwqBkZXZpY2Vz
Cj4+IHRvIHNodXRkb3duIHdoZW4gdGhlIHVzZXJzcGFjZSBwcm9jZXNzIHdhcyBhbHJlYWR5IGtp
bGxlZC4KPgo+IEkgdGhpbmsgdGhhdCB0aGlzIGNoYW5nZSBpcyBjb3JyZWN0IGJ1dCBoYXZlIHlv
dSB0ZXN0ZWQgaXQgd2l0aCBhbnkKPiBiYWNrZW5kcyBydW5uaW5nIGluIHFlbXU/CgpUZXN0ZWQg
dW5kZXIgTmV0QlNEIERvbTAgd2l0aCBIVk0gRG9tVSBhbmQgd2l0aCBEZWJpYW4gRG9tMCBhbmQg
UFYKRG9tVSB3aXRoIHFkaXNrIGFuZCBjb25zb2xlIGJhY2tlbmRzLiBTb3JyeSwgYnV0IEknbSB1
bmFibGUgdG8gdGVzdCBvbgpEZWJpYW4gd2l0aCBIVk0sIEkgZG9uJ3QgaGF2ZSBhbnkgRGViaWFu
IHNlcnZlcnMgd2l0aCB2aXJ0dWFsaXphdGlvbgpleHRlbnNpb25zLgoKPj4gU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gZGlmZiAt
ciA1ODQ5YmY3YzQ1MDcgLXIgYjVkNjNjZjkwZDRlIHRvb2xzL2xpYnhsL2xpYnhsLmMKPj4gLS0t
IGEvdG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gSmFuIDE2IDE2OjQwOjQwIDIwMTIgKzAx
MDAKPj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gSmFuIDE2IDE2OjQxOjEy
IDIwMTIgKzAxMDAKPj4gQEAgLTgwMiwxNSArODAyLDE1IEBAIGludCBsaWJ4bF9kb21haW5fZGVz
dHJveShsaWJ4bF9jdHggKmN0eCwKPj4gwqAgwqAgwqBpZiAocmMgPCAwKSB7Cj4+IMKgIMKgIMKg
IMKgIMKgTElCWExfX0xPR19FUlJOT1ZBTChjdHgsIExJQlhMX19MT0dfRVJST1IsIHJjLCAieGNf
ZG9tYWluX3BhdXNlIGZhaWxlZCBmb3IgJWQiLCBkb21pZCk7Cj4+IMKgIMKgIMKgfQo+PiArIMKg
IMKgaWYgKGxpYnhsX19kZXZpY2VzX2Rlc3Ryb3koZ2MsIGRvbWlkKSA8IDApCj4+ICsgwqAgwqAg
wqAgwqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKPj4gKyDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCAibGlieGxfX2RldmljZXNfZGVzdHJveSBmYWlsZWQgZm9yICVkIiwgZG9t
aWQpOwo+PiDCoCDCoCDCoGlmIChkbV9wcmVzZW50KSB7Cj4+IMKgIMKgIMKgIMKgIMKgaWYgKGxp
YnhsX19kZXN0cm95X2RldmljZV9tb2RlbChnYywgZG9taWQpIDwgMCkKPj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwgImxpYnhsX19kZXN0cm95
X2RldmljZV9tb2RlbCBmYWlsZWQgZm9yICVkIiwgZG9taWQpOwo+Pgo+PiDCoCDCoCDCoCDCoCDC
oGxpYnhsX19xbXBfY2xlYW51cChnYywgZG9taWQpOwo+PiDCoCDCoCDCoH0KPj4gLSDCoCDCoGlm
IChsaWJ4bF9fZGV2aWNlc19kZXN0cm95KGdjLCBkb21pZCkgPCAwKQo+PiAtIMKgIMKgIMKgIMKg
TElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsCj4+IC0gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgImxpYnhsX19kZXZpY2VzX2Rlc3Ryb3kgZmFpbGVkIGZvciAlZCIsIGRvbWlkKTsK
Pj4KPj4gwqAgwqAgwqB2bV9wYXRoID0gbGlieGxfX3hzX3JlYWQoZ2MsIFhCVF9OVUxMLCBsaWJ4
bF9fc3ByaW50ZihnYywgIiVzL3ZtIiwgZG9tX3BhdGgpKTsKPj4gwqAgwqAgwqBpZiAodm1fcGF0
aCkKPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
Pj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQo+PiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPj4KPgo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhl
bnNvdXJjZS5jb20veGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:21:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:21:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqivj-0003Eo-Gt; Fri, 27 Jan 2012 10:21: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 1Rqivh-0003Dx-Ks
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:21:13 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327659662!4263232!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12071 invoked from network); 27 Jan 2012 10:21:07 -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;
	27 Jan 2012 10:21:07 -0000
Received: by dajs34 with SMTP id s34so9946897daj.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 02:21: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=x5VDMgf9BmEx0lhySaxe72Q5/KkGfweg2pxex/+6mjc=;
	b=UNc4V9d3IKWZ8q/VchwqqWlkoshYY1Jj4h802h0k3txaJj8JYae6wy2NHnIvRh9ju1
	8rDxV9arbFjk8RAnpJKnhyxw8/k2mZvxoNVQHqQsYoU6x0yNKeaZYbVrOI+1UJLAePfn
	KNJVxxp9pd66JMkKamfCKtLmJCtkmHCjX4LRw=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr13586218pbc.5.1327659661792; Fri,
	27 Jan 2012 02:21:01 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Fri, 27 Jan 2012 02:21:01 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
References: <patchbomb.1326880685@loki.upc.es>
	<b5d63cf90d4ef8d222ae.1326880694@loki.upc.es>
	<alpine.DEB.2.00.1201261721450.3196@kaball-desktop>
Date: Fri, 27 Jan 2012 11:21:01 +0100
X-Google-Sender-Auth: ltRHQyH3F-N5LonS5IhEPvqOvEQ
Message-ID: <CAPLaKK6oY4ReczaaYcz63oMooageqzBaoYs3h=Z5AaemU3sUFA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 09 of 13 RFC] libxl: destroy devices before
 device model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

MjAxMi8xLzI2IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3RlZmFuby5zdGFiZWxsaW5pQGV1LmNpdHJp
eC5jb20+Ogo+IE9uIFdlZCwgMTggSmFuIDIwMTIsIFJvZ2VyIFBhdSBNb25uZSB3cm90ZToKPj4g
IyBIRyBjaGFuZ2VzZXQgcGF0Y2gKPj4gIyBVc2VyIFJvZ2VyIFBhdSBNb25uZSA8cm9nZXIucGF1
QGVudGVsLnVwYy5lZHU+Cj4+ICMgRGF0ZSAxMzI2NzI4NDcyIC0zNjAwCj4+ICMgTm9kZSBJRCBi
NWQ2M2NmOTBkNGVmOGQyMjJhZTI4MmUyNzliOTBiN2Y3M2YxOGMzCj4+ICMgUGFyZW50IMKgNTg0
OWJmN2M0NTA3ZWRiZTkwMGRlMDAzMzJmMTIxOGRlMmQ5ZjQ1Zgo+PiBsaWJ4bDogZGVzdHJveSBk
ZXZpY2VzIGJlZm9yZSBkZXZpY2UgbW9kZWwKPj4KPj4gRGVzdHJveWluZyB0aGUgZGV2aWNlIG1v
ZGVsIGJlZm9yZSB1bnBsdWdnaW5nIHRoZSBkZXZpY2VzIHByZXZlbnRlZAo+PiBmcm9tIGRvaW5n
IGEgY2xlYW4gdW5wbHVnLCBzaW5jZSBsaWJ4bCB3YXMgd2FpdGluZyBmb3IgZG0gwqBkZXZpY2Vz
Cj4+IHRvIHNodXRkb3duIHdoZW4gdGhlIHVzZXJzcGFjZSBwcm9jZXNzIHdhcyBhbHJlYWR5IGtp
bGxlZC4KPgo+IEkgdGhpbmsgdGhhdCB0aGlzIGNoYW5nZSBpcyBjb3JyZWN0IGJ1dCBoYXZlIHlv
dSB0ZXN0ZWQgaXQgd2l0aCBhbnkKPiBiYWNrZW5kcyBydW5uaW5nIGluIHFlbXU/CgpUZXN0ZWQg
dW5kZXIgTmV0QlNEIERvbTAgd2l0aCBIVk0gRG9tVSBhbmQgd2l0aCBEZWJpYW4gRG9tMCBhbmQg
UFYKRG9tVSB3aXRoIHFkaXNrIGFuZCBjb25zb2xlIGJhY2tlbmRzLiBTb3JyeSwgYnV0IEknbSB1
bmFibGUgdG8gdGVzdCBvbgpEZWJpYW4gd2l0aCBIVk0sIEkgZG9uJ3QgaGF2ZSBhbnkgRGViaWFu
IHNlcnZlcnMgd2l0aCB2aXJ0dWFsaXphdGlvbgpleHRlbnNpb25zLgoKPj4gU2lnbmVkLW9mZi1i
eTogUm9nZXIgUGF1IE1vbm5lIDxyb2dlci5wYXVAZW50ZWwudXBjLmVkdT4KPj4KPj4gZGlmZiAt
ciA1ODQ5YmY3YzQ1MDcgLXIgYjVkNjNjZjkwZDRlIHRvb2xzL2xpYnhsL2xpYnhsLmMKPj4gLS0t
IGEvdG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gSmFuIDE2IDE2OjQwOjQwIDIwMTIgKzAx
MDAKPj4gKysrIGIvdG9vbHMvbGlieGwvbGlieGwuYyDCoCDCoCBNb24gSmFuIDE2IDE2OjQxOjEy
IDIwMTIgKzAxMDAKPj4gQEAgLTgwMiwxNSArODAyLDE1IEBAIGludCBsaWJ4bF9kb21haW5fZGVz
dHJveShsaWJ4bF9jdHggKmN0eCwKPj4gwqAgwqAgwqBpZiAocmMgPCAwKSB7Cj4+IMKgIMKgIMKg
IMKgIMKgTElCWExfX0xPR19FUlJOT1ZBTChjdHgsIExJQlhMX19MT0dfRVJST1IsIHJjLCAieGNf
ZG9tYWluX3BhdXNlIGZhaWxlZCBmb3IgJWQiLCBkb21pZCk7Cj4+IMKgIMKgIMKgfQo+PiArIMKg
IMKgaWYgKGxpYnhsX19kZXZpY2VzX2Rlc3Ryb3koZ2MsIGRvbWlkKSA8IDApCj4+ICsgwqAgwqAg
wqAgwqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwKPj4gKyDCoCDCoCDCoCDCoCDC
oCDCoCDCoCDCoCDCoCAibGlieGxfX2RldmljZXNfZGVzdHJveSBmYWlsZWQgZm9yICVkIiwgZG9t
aWQpOwo+PiDCoCDCoCDCoGlmIChkbV9wcmVzZW50KSB7Cj4+IMKgIMKgIMKgIMKgIMKgaWYgKGxp
YnhsX19kZXN0cm95X2RldmljZV9tb2RlbChnYywgZG9taWQpIDwgMCkKPj4gwqAgwqAgwqAgwqAg
wqAgwqAgwqBMSUJYTF9fTE9HKGN0eCwgTElCWExfX0xPR19FUlJPUiwgImxpYnhsX19kZXN0cm95
X2RldmljZV9tb2RlbCBmYWlsZWQgZm9yICVkIiwgZG9taWQpOwo+Pgo+PiDCoCDCoCDCoCDCoCDC
oGxpYnhsX19xbXBfY2xlYW51cChnYywgZG9taWQpOwo+PiDCoCDCoCDCoH0KPj4gLSDCoCDCoGlm
IChsaWJ4bF9fZGV2aWNlc19kZXN0cm95KGdjLCBkb21pZCkgPCAwKQo+PiAtIMKgIMKgIMKgIMKg
TElCWExfX0xPRyhjdHgsIExJQlhMX19MT0dfRVJST1IsCj4+IC0gwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgImxpYnhsX19kZXZpY2VzX2Rlc3Ryb3kgZmFpbGVkIGZvciAlZCIsIGRvbWlkKTsK
Pj4KPj4gwqAgwqAgwqB2bV9wYXRoID0gbGlieGxfX3hzX3JlYWQoZ2MsIFhCVF9OVUxMLCBsaWJ4
bF9fc3ByaW50ZihnYywgIiVzL3ZtIiwgZG9tX3BhdGgpKTsKPj4gwqAgwqAgwqBpZiAodm1fcGF0
aCkKPj4KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
Pj4gWGVuLWRldmVsIG1haWxpbmcgbGlzdAo+PiBYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNv
bQo+PiBodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwKPj4KPgo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gWGVuLWRldmVsIG1haWxp
bmcgbGlzdAo+IFhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCj4gaHR0cDovL2xpc3RzLnhl
bnNvdXJjZS5jb20veGVuLWRldmVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5z
b3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5zb3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:26:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqj15-0003YH-9J; Fri, 27 Jan 2012 10:26:47 +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 1Rqj13-0003Y0-Gb
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:26:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327659999!8576004!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 526 invoked from network); 27 Jan 2012 10:26:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 10:26:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rqj0u-0002ya-Fp; Fri, 27 Jan 2012 10:26:36 +0000
Date: Fri, 27 Jan 2012 10:26:35 +0000
From: Tim Deegan <tim@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120127102635.GA11163@ocelot.phlegethon.org>
References: <20120119161626.GO66164@ocelot.phlegethon.org>
	<20120126154504.GA80228@ocelot.phlegethon.org>
	<4F2277C9.10207@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F2277C9.10207@amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] RFC PATCH: bring OpenBSD stdarg in line with
	FreeBSD one
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 11:09 +0100 on 27 Jan (1327662553), Christoph Egger wrote:
> On 01/26/12 16:45, Tim Deegan wrote:
> >At 16:16 +0000 on 19 Jan (1326989786), Tim Deegan wrote:
> >>Having an absolute path in a #include confuses distcc's pump mode.
> >>Since AFAICS OpenBSD's stdarg handling uses the builtins, I think we
> >>should just treat it like we do NetBSD.
> >>
> >>I don't have an OpenBSD box to test on, though. :(  Any OpenBSD
> >>enthusiasts care to comment?
> >
> >No complaints, and the new header compiles on OpenBSD, so I've applied it.
> 
> ... the commit message does not match what the actually patch does.
> You mixed up FreeBSD with NetBSD. :-)

Augh, so I have!

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:26:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqj15-0003YH-9J; Fri, 27 Jan 2012 10:26:47 +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 1Rqj13-0003Y0-Gb
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:26:45 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327659999!8576004!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 526 invoked from network); 27 Jan 2012 10:26:39 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 10:26:39 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rqj0u-0002ya-Fp; Fri, 27 Jan 2012 10:26:36 +0000
Date: Fri, 27 Jan 2012 10:26:35 +0000
From: Tim Deegan <tim@xen.org>
To: Christoph Egger <Christoph.Egger@amd.com>
Message-ID: <20120127102635.GA11163@ocelot.phlegethon.org>
References: <20120119161626.GO66164@ocelot.phlegethon.org>
	<20120126154504.GA80228@ocelot.phlegethon.org>
	<4F2277C9.10207@amd.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4F2277C9.10207@amd.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] RFC PATCH: bring OpenBSD stdarg in line with
	FreeBSD one
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

At 11:09 +0100 on 27 Jan (1327662553), Christoph Egger wrote:
> On 01/26/12 16:45, Tim Deegan wrote:
> >At 16:16 +0000 on 19 Jan (1326989786), Tim Deegan wrote:
> >>Having an absolute path in a #include confuses distcc's pump mode.
> >>Since AFAICS OpenBSD's stdarg handling uses the builtins, I think we
> >>should just treat it like we do NetBSD.
> >>
> >>I don't have an OpenBSD box to test on, though. :(  Any OpenBSD
> >>enthusiasts care to comment?
> >
> >No complaints, and the new header compiles on OpenBSD, so I've applied it.
> 
> ... the commit message does not match what the actually patch does.
> You mixed up FreeBSD with NetBSD. :-)

Augh, so I have!

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:30:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:30:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqj4k-0003ot-UL; Fri, 27 Jan 2012 10:30:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqj4j-0003of-SP
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:30:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327660227!12365938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18213 invoked from network); 27 Jan 2012 10:30:28 -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;
	27 Jan 2012 10:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:30: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, 27 Jan 2012 10:30:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 10:30:26 +0000
In-Reply-To: <1327598457-28261-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660226.26983.157.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/11] xl: fix a couple of memory leaks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> * dolog leaked the log message (!)
> 
> * main() leaked the config_data (perhaps a false positive from valgrind,
>   but it's nicer to tidy it up).
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/xl.c         |    1 +
>  tools/libxl/xl_cmdimpl.c |    3 ++-
>  2 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index 7b9d2c8..02a6803 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -135,6 +135,7 @@ int main(int argc, char **argv)
>                  config_file, strerror(errno));
>      parse_global_config(config_file, config_data, config_len);
>      free(config_file);
> +    free(config_data);
>  
>      /* Reset options for per-command use of getopt. */
>      argv += optind;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 7dbd812..87413c8 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -278,7 +278,7 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
>  static void dolog(const char *file, int line, const char *func, char *fmt, ...)
>  {
>      va_list ap;
> -    char *s;
> +    char *s = NULL;
>      int rc;
>  
>      va_start(ap, fmt);
> @@ -286,6 +286,7 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
>      va_end(ap);
>      if (rc >= 0)
>          libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
> +    free(s);
>  }
>  
>  static void printf_info(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 Jan 27 10:30:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:30:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqj4k-0003ot-UL; Fri, 27 Jan 2012 10:30:34 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqj4j-0003of-SP
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:30:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327660227!12365938!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18213 invoked from network); 27 Jan 2012 10:30:28 -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;
	27 Jan 2012 10:30:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323848"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:30: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, 27 Jan 2012 10:30:26 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 10:30:26 +0000
In-Reply-To: <1327598457-28261-3-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-3-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660226.26983.157.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/11] xl: fix a couple of memory leaks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> * dolog leaked the log message (!)
> 
> * main() leaked the config_data (perhaps a false positive from valgrind,
>   but it's nicer to tidy it up).
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/libxl/xl.c         |    1 +
>  tools/libxl/xl_cmdimpl.c |    3 ++-
>  2 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
> index 7b9d2c8..02a6803 100644
> --- a/tools/libxl/xl.c
> +++ b/tools/libxl/xl.c
> @@ -135,6 +135,7 @@ int main(int argc, char **argv)
>                  config_file, strerror(errno));
>      parse_global_config(config_file, config_data, config_len);
>      free(config_file);
> +    free(config_data);
>  
>      /* Reset options for per-command use of getopt. */
>      argv += optind;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 7dbd812..87413c8 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -278,7 +278,7 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
>  static void dolog(const char *file, int line, const char *func, char *fmt, ...)
>  {
>      va_list ap;
> -    char *s;
> +    char *s = NULL;
>      int rc;
>  
>      va_start(ap, fmt);
> @@ -286,6 +286,7 @@ static void dolog(const char *file, int line, const char *func, char *fmt, ...)
>      va_end(ap);
>      if (rc >= 0)
>          libxl_write_exactly(NULL, logfile, s, rc, NULL, NULL);
> +    free(s);
>  }
>  
>  static void printf_info(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 Jan 27 10:31:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqj5k-0003tU-DL; Fri, 27 Jan 2012 10:31:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqj5i-0003tI-SD
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:31:35 +0000
Received: from [85.158.138.51:2448] by server-1.bemta-3.messagelabs.com id
	57/FE-09565-50D722F4; Fri, 27 Jan 2012 10:31:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327660293!6682809!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15852 invoked from network); 27 Jan 2012 10:31:33 -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;
	27 Jan 2012 10:31:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:31:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 10:31:33 +0000
Date: Fri, 27 Jan 2012 10:32:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
Message-ID: <alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
References: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
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] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 16 Jan 2012, Roger Pau Monne wrote:
> Qemu was not reacting when setting xenstore state of a device to
> XenbusStateClosing (5). This patch makes qemu react to this state and
> close the appropiate device.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Please send a version of this patch against upstream qemu and CC
qemu-devel as well.


> ---
>  hw/xen_backend.c |   18 ++++++++++++++++--
>  1 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xen_backend.c b/hw/xen_backend.c
> index 64dc93a..4e4dd77 100644
> --- a/hw/xen_backend.c
> +++ b/hw/xen_backend.c
> @@ -285,11 +285,23 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
>   */
>  static void xen_be_backend_changed(struct XenDevice *xendev, const char *node)
>  {
> +    int be_state;
> +
>      if (node == NULL  ||  strcmp(node, "online") == 0) {
>  	if (xenstore_read_be_int(xendev, "online", &xendev->online) == -1)
>  	    xendev->online = 0;
>      }
>  
> +    if (node != NULL && strcmp(node, "state") == 0) {
> +        if (xenstore_read_be_int(xendev, "state", &be_state) == -1) {
> +            xendev->be_state = XenbusStateUnknown;
> +        } else if (xendev->be_state == be_state) {
> +            return;
> +        } else {
> +            xendev->be_state = be_state;
> +        }
> +    }
> +
>      if (node) {
>  	xen_be_printf(xendev, 2, "backend update: %s\n", node);
>  	if (xendev->ops->backend_changed)
> @@ -461,8 +473,7 @@ static void xen_be_try_connected(struct XenDevice *xendev)
>   */
>  static void xen_be_disconnect(struct XenDevice *xendev, enum xenbus_state state)
>  {
> -    if (xendev->be_state != XenbusStateClosing &&
> -        xendev->be_state != XenbusStateClosed  &&
> +    if (xendev->be_state != XenbusStateClosed  &&
>          xendev->ops->disconnect)
>  	xendev->ops->disconnect(xendev);
>      if (xendev->be_state != state)
> @@ -513,6 +524,9 @@ void xen_be_check_state(struct XenDevice *xendev)
>  	    xen_be_try_connected(xendev);
>  	    rc = -1;
>  	    break;
> +    case XenbusStateClosing:
> +        xen_be_disconnect(xendev, XenbusStateClosed);
> +        break;
>          case XenbusStateClosed:
>              rc = xen_be_try_reset(xendev);
>              break;
> -- 
> 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 Jan 27 10:31:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqj5k-0003tU-DL; Fri, 27 Jan 2012 10:31:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqj5i-0003tI-SD
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:31:35 +0000
Received: from [85.158.138.51:2448] by server-1.bemta-3.messagelabs.com id
	57/FE-09565-50D722F4; Fri, 27 Jan 2012 10:31:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327660293!6682809!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15852 invoked from network); 27 Jan 2012 10:31:33 -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;
	27 Jan 2012 10:31:33 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323881"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:31:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 10:31:33 +0000
Date: Fri, 27 Jan 2012 10:32:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
Message-ID: <alpine.DEB.2.00.1201271031520.3196@kaball-desktop>
References: <1326726936-8885-1-git-send-email-roger.pau@entel.upc.edu>
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] qemu: react to XenbusStateClosing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 16 Jan 2012, Roger Pau Monne wrote:
> Qemu was not reacting when setting xenstore state of a device to
> XenbusStateClosing (5). This patch makes qemu react to this state and
> close the appropiate device.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

Please send a version of this patch against upstream qemu and CC
qemu-devel as well.


> ---
>  hw/xen_backend.c |   18 ++++++++++++++++--
>  1 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xen_backend.c b/hw/xen_backend.c
> index 64dc93a..4e4dd77 100644
> --- a/hw/xen_backend.c
> +++ b/hw/xen_backend.c
> @@ -285,11 +285,23 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
>   */
>  static void xen_be_backend_changed(struct XenDevice *xendev, const char *node)
>  {
> +    int be_state;
> +
>      if (node == NULL  ||  strcmp(node, "online") == 0) {
>  	if (xenstore_read_be_int(xendev, "online", &xendev->online) == -1)
>  	    xendev->online = 0;
>      }
>  
> +    if (node != NULL && strcmp(node, "state") == 0) {
> +        if (xenstore_read_be_int(xendev, "state", &be_state) == -1) {
> +            xendev->be_state = XenbusStateUnknown;
> +        } else if (xendev->be_state == be_state) {
> +            return;
> +        } else {
> +            xendev->be_state = be_state;
> +        }
> +    }
> +
>      if (node) {
>  	xen_be_printf(xendev, 2, "backend update: %s\n", node);
>  	if (xendev->ops->backend_changed)
> @@ -461,8 +473,7 @@ static void xen_be_try_connected(struct XenDevice *xendev)
>   */
>  static void xen_be_disconnect(struct XenDevice *xendev, enum xenbus_state state)
>  {
> -    if (xendev->be_state != XenbusStateClosing &&
> -        xendev->be_state != XenbusStateClosed  &&
> +    if (xendev->be_state != XenbusStateClosed  &&
>          xendev->ops->disconnect)
>  	xendev->ops->disconnect(xendev);
>      if (xendev->be_state != state)
> @@ -513,6 +524,9 @@ void xen_be_check_state(struct XenDevice *xendev)
>  	    xen_be_try_connected(xendev);
>  	    rc = -1;
>  	    break;
> +    case XenbusStateClosing:
> +        xen_be_disconnect(xendev, XenbusStateClosed);
> +        break;
>          case XenbusStateClosed:
>              rc = xen_be_try_reset(xendev);
>              break;
> -- 
> 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 Jan 27 10:32:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqj6J-0003xf-1i; Fri, 27 Jan 2012 10:32:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqj6H-0003xK-4O
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:32:09 +0000
Received: from [85.158.138.51:12426] by server-2.bemta-3.messagelabs.com id
	D9/4B-24515-82D722F4; Fri, 27 Jan 2012 10:32:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327660327!10908583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21298 invoked from network); 27 Jan 2012 10:32:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:32:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:32: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;
	Fri, 27 Jan 2012 10:32:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:32:07 +0000
In-Reply-To: <1327607111-15394-19-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-19-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660327.26983.158.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 18/24] xenstored: add --internal-db flag
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:

You forgot your S-o-b.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_core.c |   20 ++++++++++++++------
>  1 files changed, 14 insertions(+), 6 deletions(-)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:32:23 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1Rqj6J-0003xf-1i; Fri, 27 Jan 2012 10:32:11 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqj6H-0003xK-4O
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:32:09 +0000
Received: from [85.158.138.51:12426] by server-2.bemta-3.messagelabs.com id
	D9/4B-24515-82D722F4; Fri, 27 Jan 2012 10:32:08 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327660327!10908583!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21298 invoked from network); 27 Jan 2012 10:32:07 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:32:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323899"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:32: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;
	Fri, 27 Jan 2012 10:32:07 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:32:07 +0000
In-Reply-To: <1327607111-15394-19-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-19-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660327.26983.158.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 18/24] xenstored: add --internal-db flag
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:

You forgot your S-o-b.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_core.c |   20 ++++++++++++++------
>  1 files changed, 14 insertions(+), 6 deletions(-)
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:34:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqj8o-0004Ep-Pv; Fri, 27 Jan 2012 10:34:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqj8m-0004Do-Lg
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:34:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327660478!8368817!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12763 invoked from network); 27 Jan 2012 10:34:38 -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;
	27 Jan 2012 10:34:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:34: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, 27 Jan 2012 10:34:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:34:37 +0000
In-Reply-To: <1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660477.26983.159.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/Makefile           |    9 ++++-
>  tools/xenstore/utils.h            |    2 +
>  tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
>  tools/xenstore/xenstored_domain.c |   11 +++++
>  4 files changed, 68 insertions(+), 28 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:34:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:34:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqj8o-0004Ep-Pv; Fri, 27 Jan 2012 10:34:46 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqj8m-0004Do-Lg
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:34:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327660478!8368817!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12763 invoked from network); 27 Jan 2012 10:34:38 -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;
	27 Jan 2012 10:34:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10323974"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:34: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, 27 Jan 2012 10:34:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:34:37 +0000
In-Reply-To: <1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660477.26983.159.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/Makefile           |    9 ++++-
>  tools/xenstore/utils.h            |    2 +
>  tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
>  tools/xenstore/xenstored_domain.c |   11 +++++
>  4 files changed, 68 insertions(+), 28 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:36:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:36:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqjA4-0004T6-9l; Fri, 27 Jan 2012 10:36: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 1RqjA2-0004Ro-6K
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:36:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327660555!4266280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10999 invoked from network); 27 Jan 2012 10:35:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:35:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 10:35:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:35:55 +0000
In-Reply-To: <1327607111-15394-21-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-21-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660555.26983.160.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 20/24] stubdom: enable xenstored 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

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg
> new file mode 100644
> index 0000000..ab7338f
> --- /dev/null
> +++ b/stubdom/xenstore-minios.cfg
> @@ -0,0 +1,9 @@
> +CONFIG_BLKFRONT=n
> +CONFIG_NETFRONT=n
> +CONFIG_FBFRONT=n
> +CONFIG_KBDFRONT=n
> +CONFIG_CONSFRONT=n
> +CONFIG_XENBUS=n
> +
> +lwip=n
> +DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS)) 

This suggests that we should have CONFIG_LWIP.

Otherwise:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:36:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:36:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqjA4-0004T6-9l; Fri, 27 Jan 2012 10:36: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 1RqjA2-0004Ro-6K
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:36:02 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327660555!4266280!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10999 invoked from network); 27 Jan 2012 10:35:56 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:35:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:35:55 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 10:35:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:35:55 +0000
In-Reply-To: <1327607111-15394-21-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-21-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660555.26983.160.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 20/24] stubdom: enable xenstored 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

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg
> new file mode 100644
> index 0000000..ab7338f
> --- /dev/null
> +++ b/stubdom/xenstore-minios.cfg
> @@ -0,0 +1,9 @@
> +CONFIG_BLKFRONT=n
> +CONFIG_NETFRONT=n
> +CONFIG_FBFRONT=n
> +CONFIG_KBDFRONT=n
> +CONFIG_CONSFRONT=n
> +CONFIG_XENBUS=n
> +
> +lwip=n
> +DEF_CPPFLAGS := $(filter-out -DHAVE_LWIP,$(DEF_CPPFLAGS)) 

This suggests that we should have CONFIG_LWIP.

Otherwise:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:36:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqjAX-0004ZQ-OV; Fri, 27 Jan 2012 10:36:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RqjAW-0004Yv-Ec
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:36:32 +0000
Received: from [85.158.138.51:46588] by server-4.bemta-3.messagelabs.com id
	07/03-32238-F2E722F4; Fri, 27 Jan 2012 10:36:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327660590!5750910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32592 invoked from network); 27 Jan 2012 10:36:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:36:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:36:30 +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;
	Fri, 27 Jan 2012 10:36:30 +0000
Message-ID: <1327660589.2585.14.camel@leeni.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 27 Jan 2012 10:36:29 +0000
In-Reply-To: <20120126181900.GB25572@phenom.dumpdata.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
	<20120126181900.GB25572@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: correct MAX_TX_TARGET
	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 18:19 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 26, 2012 at 05:23:23PM +0000, Wei Liu wrote:
> 
> Can you give some more details please? What is the impact of
> not having this? Should it be backported to stable?
> 

I think it will not cause crash, only the scratch space size is
affected, thus impacting tx batching a bit.

As the tx structure is bigger than rx structure. I think scratch space
size is likely to shrink after correction.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:36:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10:36:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqjAX-0004ZQ-OV; Fri, 27 Jan 2012 10:36:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RqjAW-0004Yv-Ec
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:36:32 +0000
Received: from [85.158.138.51:46588] by server-4.bemta-3.messagelabs.com id
	07/03-32238-F2E722F4; Fri, 27 Jan 2012 10:36:31 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327660590!5750910!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32592 invoked from network); 27 Jan 2012 10:36:31 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:36:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324037"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:36:30 +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;
	Fri, 27 Jan 2012 10:36:30 +0000
Message-ID: <1327660589.2585.14.camel@leeni.uk.xensource.com>
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 27 Jan 2012 10:36:29 +0000
In-Reply-To: <20120126181900.GB25572@phenom.dumpdata.com>
References: <1327598603-16398-1-git-send-email-wei.liu2@citrix.com>
	<20120126181900.GB25572@phenom.dumpdata.com>
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"jeremy@goop.org" <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen-netfront: correct MAX_TX_TARGET
	calculation.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 18:19 +0000, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 26, 2012 at 05:23:23PM +0000, Wei Liu wrote:
> 
> Can you give some more details please? What is the impact of
> not having this? Should it be backported to stable?
> 

I think it will not cause crash, only the scratch space size is
affected, thus impacting tx batching a bit.

As the tx structure is bigger than rx structure. I think scratch space
size is likely to shrink after correction.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:38:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqjCR-0004wN-9h; Fri, 27 Jan 2012 10:38:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqjCP-0004vX-52
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:38:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327660702!12785270!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29003 invoked from network); 27 Jan 2012 10:38:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:38:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324080"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:37: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, 27 Jan 2012 10:37:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:37:49 +0000
In-Reply-To: <1327607111-15394-23-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-23-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660669.26983.162.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 22/24] xenstored: use domain_is_unprivileged
 instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> This centralizes all the permission checking for privileged domains in
> preparation for allowing domains other than dom0 to be privileged.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I still can't get my head round the double negatives etc but your
explanation last time round convinced me that you have so:

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 Jan 27 10:38:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqjCR-0004wN-9h; Fri, 27 Jan 2012 10:38:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqjCP-0004vX-52
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:38:29 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327660702!12785270!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29003 invoked from network); 27 Jan 2012 10:38:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:38:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324080"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:37: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, 27 Jan 2012 10:37:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:37:49 +0000
In-Reply-To: <1327607111-15394-23-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-23-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660669.26983.162.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 22/24] xenstored: use domain_is_unprivileged
 instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> This centralizes all the permission checking for privileged domains in
> preparation for allowing domains other than dom0 to be privileged.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

I still can't get my head round the double negatives etc but your
explanation last time round convinced me that you have so:

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 Jan 27 10:38:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqjCS-0004wh-NH; Fri, 27 Jan 2012 10:38:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqjCR-0004vo-Lx
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:38:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327660702!12785270!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29137 invoked from network); 27 Jan 2012 10:38:25 -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 Jan 2012 10:38:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:38: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, 27 Jan 2012 10:38:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:38:18 +0000
In-Reply-To: <1327607111-15394-24-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-24-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660698.26983.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 23/24] xenstored: add --priv-domid 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

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> This parameter identifies an alternative service domain which has
> superuser access to the xenstore database, which is currently required
> to set up a new domain's xenstore entries.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_core.c   |    5 +++++
>  tools/xenstore/xenstored_core.h   |    1 +
>  tools/xenstore/xenstored_domain.c |    2 +-
>  3 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index f254947..2894f1b 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -1825,6 +1825,7 @@ static struct option options[] = {
>  	{ "event", 1, NULL, 'e' },
>  	{ "help", 0, NULL, 'H' },
>  	{ "no-fork", 0, NULL, 'N' },
> +	{ "priv-domid", 1, NULL, 'p' },
>  	{ "output-pid", 0, NULL, 'P' },
>  	{ "entry-size", 1, NULL, 'S' },
>  	{ "trace-file", 1, NULL, 'T' },
> @@ -1838,6 +1839,7 @@ static struct option options[] = {
>  
>  extern void dump_conn(struct connection *conn); 
>  int dom0_event = 0;
> +int priv_domid = 0;
>  
>  int main(int argc, char *argv[])
>  {
> @@ -1903,6 +1905,9 @@ int main(int argc, char *argv[])
>  		case 'e':
>  			dom0_event = strtol(optarg, NULL, 10);
>  			break;
> +		case 'p':
> +			priv_domid = strtol(optarg, NULL, 10);
> +			break;
>  		}
>  	}
>  	if (optind != argc)
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index d3040ba..03e2e48 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>  
>  extern int event_fd;
>  extern int dom0_event;
> +extern int priv_domid;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 22fe126b..151e088 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -263,7 +263,7 @@ bool domain_can_read(struct connection *conn)
>  
>  bool domain_is_unprivileged(struct connection *conn)
>  {
> -	return (conn && conn->domain && conn->domain->domid != 0);
> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
>  }
>  
>  bool domain_can_write(struct connection *conn)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:38:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqjCS-0004wh-NH; Fri, 27 Jan 2012 10:38:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqjCR-0004vo-Lx
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:38:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327660702!12785270!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29137 invoked from network); 27 Jan 2012 10:38:25 -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 Jan 2012 10:38:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324098"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:38: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, 27 Jan 2012 10:38:19 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:38:18 +0000
In-Reply-To: <1327607111-15394-24-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-24-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660698.26983.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 23/24] xenstored: add --priv-domid 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

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> This parameter identifies an alternative service domain which has
> superuser access to the xenstore database, which is currently required
> to set up a new domain's xenstore entries.
> 
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
>  tools/xenstore/xenstored_core.c   |    5 +++++
>  tools/xenstore/xenstored_core.h   |    1 +
>  tools/xenstore/xenstored_domain.c |    2 +-
>  3 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index f254947..2894f1b 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -1825,6 +1825,7 @@ static struct option options[] = {
>  	{ "event", 1, NULL, 'e' },
>  	{ "help", 0, NULL, 'H' },
>  	{ "no-fork", 0, NULL, 'N' },
> +	{ "priv-domid", 1, NULL, 'p' },
>  	{ "output-pid", 0, NULL, 'P' },
>  	{ "entry-size", 1, NULL, 'S' },
>  	{ "trace-file", 1, NULL, 'T' },
> @@ -1838,6 +1839,7 @@ static struct option options[] = {
>  
>  extern void dump_conn(struct connection *conn); 
>  int dom0_event = 0;
> +int priv_domid = 0;
>  
>  int main(int argc, char *argv[])
>  {
> @@ -1903,6 +1905,9 @@ int main(int argc, char *argv[])
>  		case 'e':
>  			dom0_event = strtol(optarg, NULL, 10);
>  			break;
> +		case 'p':
> +			priv_domid = strtol(optarg, NULL, 10);
> +			break;
>  		}
>  	}
>  	if (optind != argc)
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index d3040ba..03e2e48 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
>  
>  extern int event_fd;
>  extern int dom0_event;
> +extern int priv_domid;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index 22fe126b..151e088 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -263,7 +263,7 @@ bool domain_can_read(struct connection *conn)
>  
>  bool domain_is_unprivileged(struct connection *conn)
>  {
> -	return (conn && conn->domain && conn->domain->domid != 0);
> +	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
>  }
>  
>  bool domain_can_write(struct connection *conn)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 10:39:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqjDI-00057c-6U; Fri, 27 Jan 2012 10:39:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqjDG-00057H-Tx
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:39:23 +0000
Received: from [85.158.138.51:32250] by server-7.bemta-3.messagelabs.com id
	0F/5E-31267-9DE722F4; Fri, 27 Jan 2012 10:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327660761!10895210!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28738 invoked from network); 27 Jan 2012 10:39:21 -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;
	27 Jan 2012 10:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:39:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 10:39:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 10:39:20 +0000
In-Reply-To: <1327598457-28261-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660761.26983.164.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 01/11] .gitignore/.hgignore: New names for
 ioemu dirs, seabios
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> * Add new seabios clone directories to .gitignore.
> * Add new qemu clone directories to .gitignore.
> * Remove old tools/ioemu (long-obsolete) from .gitignore and .hgignore.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Hardly seems worth it but:
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 Jan 27 10:39:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 10: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 1RqjDI-00057c-6U; Fri, 27 Jan 2012 10:39:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqjDG-00057H-Tx
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:39:23 +0000
Received: from [85.158.138.51:32250] by server-7.bemta-3.messagelabs.com id
	0F/5E-31267-9DE722F4; Fri, 27 Jan 2012 10:39:21 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1327660761!10895210!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28738 invoked from network); 27 Jan 2012 10:39:21 -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;
	27 Jan 2012 10:39:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324136"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:39:21 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 10:39:21 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 10:39:20 +0000
In-Reply-To: <1327598457-28261-2-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327660761.26983.164.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 01/11] .gitignore/.hgignore: New names for
 ioemu dirs, seabios
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> * Add new seabios clone directories to .gitignore.
> * Add new qemu clone directories to .gitignore.
> * Remove old tools/ioemu (long-obsolete) from .gitignore and .hgignore.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Hardly seems worth it but:
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 Jan 27 11:00:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 11: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 1RqjX7-0006LB-4t; Fri, 27 Jan 2012 10:59:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqjX5-0006L3-NQ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:59:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327661794!9040936!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14942 invoked from network); 27 Jan 2012 10:56:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:56:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:56:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 10:56:34 +0000
Date: Fri, 27 Jan 2012 10:57:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-133763992-1327661330=:3196"
Content-ID: <alpine.DEB.2.00.1201271050120.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-133763992-1327661330=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1201271050121.3196@kaball-desktop>

On Fri, 27 Jan 2012, Roger Pau Monné wrote:
> Hello,
> 
> I have a question regarding driver domains and root hard disks, if the
> root hard disk (the one containing the kernel and ramdisk) is on a
> driver domain, how can we pass the kernel to the Dom0? libvchan seems
> like a good option to pass the kernel and ramdisk from driver domains
> to Dom0, but I would like to hear opinions about that.
> 
> If kernel and ramdisk passing is not implemented, the only way to boot
> from hard disk stored on driver domains is to extract the kernel and
> ramdisk and store them on the Dom0.

Let me describe in more details this scenario for you:
we are using a storage driver domain (the storage controller is assigned
to a domain other than dom0), and dom0 is still responsible for creating
all the other VMs, including the storage driver domain.

How can dom0 create the storage driver domain if the kernel and initrd
of the storage driver domain are on the hard disk?

A simple solution would be having the storage driver domain kernel and
initrd inside dom0 initrd or passed to dom0 through multiboot by the
bootloader as an additional payload (better).
Dom0 should be capable of freeing the memory used this way after
creating the storage driver domain.
--8323329-133763992-1327661330=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-133763992-1327661330=:3196--


From xen-devel-bounces@lists.xensource.com Fri Jan 27 11:00:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 11: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 1RqjX7-0006LB-4t; Fri, 27 Jan 2012 10:59:53 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqjX5-0006L3-NQ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 10:59:51 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327661794!9040936!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14942 invoked from network); 27 Jan 2012 10:56:35 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 10:56:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324647"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 10:56:33 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 10:56:34 +0000
Date: Fri, 27 Jan 2012 10:57:31 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-133763992-1327661330=:3196"
Content-ID: <alpine.DEB.2.00.1201271050120.3196@kaball-desktop>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-133763992-1327661330=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.2.00.1201271050121.3196@kaball-desktop>

On Fri, 27 Jan 2012, Roger Pau Monné wrote:
> Hello,
> 
> I have a question regarding driver domains and root hard disks, if the
> root hard disk (the one containing the kernel and ramdisk) is on a
> driver domain, how can we pass the kernel to the Dom0? libvchan seems
> like a good option to pass the kernel and ramdisk from driver domains
> to Dom0, but I would like to hear opinions about that.
> 
> If kernel and ramdisk passing is not implemented, the only way to boot
> from hard disk stored on driver domains is to extract the kernel and
> ramdisk and store them on the Dom0.

Let me describe in more details this scenario for you:
we are using a storage driver domain (the storage controller is assigned
to a domain other than dom0), and dom0 is still responsible for creating
all the other VMs, including the storage driver domain.

How can dom0 create the storage driver domain if the kernel and initrd
of the storage driver domain are on the hard disk?

A simple solution would be having the storage driver domain kernel and
initrd inside dom0 initrd or passed to dom0 through multiboot by the
bootloader as an additional payload (better).
Dom0 should be capable of freeing the memory used this way after
creating the storage driver domain.
--8323329-133763992-1327661330=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-133763992-1327661330=:3196--


From xen-devel-bounces@lists.xensource.com Fri Jan 27 11:03:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 11: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 1RqjZu-0006TX-OQ; Fri, 27 Jan 2012 11:02:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqjZs-0006TP-L3
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 11:02:44 +0000
Received: from [85.158.138.51:62977] by server-6.bemta-3.messagelabs.com id
	0C/E1-31032-354822F4; Fri, 27 Jan 2012 11:02:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327662163!10915543!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 417 invoked from network); 27 Jan 2012 11:02:43 -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;
	27 Jan 2012 11:02:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 11:02: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, 27 Jan 2012 11:02:43 +0000
Date: Fri, 27 Jan 2012 11:03:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120126185155.GA24768@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201271058090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
	<1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120126185155.GA24768@phenom.dumpdata.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>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> > The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> > be EOI'd without having to issue an hypercall every time.
> > We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> > succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  drivers/xen/events.c            |   17 ++++++++++++++++-
> >  include/xen/interface/physdev.h |   12 ++++++++++++
> >  2 files changed, 28 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 6e075cd..7fdc738 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -37,6 +37,7 @@
> >  #include <asm/idle.h>
> >  #include <asm/io_apic.h>
> >  #include <asm/sync_bitops.h>
> > +#include <asm/xen/page.h>
> >  #include <asm/xen/pci.h>
> >  #include <asm/xen/hypercall.h>
> >  #include <asm/xen/hypervisor.h>
> > @@ -108,6 +109,7 @@ struct irq_info {
> >  #define PIRQ_SHAREABLE	(1 << 1)
> >  
> >  static int *evtchn_to_irq;
> > +static unsigned long *pirq_eoi_map;
> >  
> >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> >  		      cpu_evtchn_mask);
> > @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
> >  
> >  	BUG_ON(info->type != IRQT_PIRQ);
> >  
> > +	if (pirq_eoi_map != NULL)
> > +		return test_bit(irq, pirq_eoi_map);
> > +
> 
> How about just having a different function called
> pirq_needs_eoi_v2 which will just do
> 
>  return test_bit(irq, pirq_eoi_map)?
> 
> And then set the pirq_needs_eoi_v2 in the function table?

Ok, but the name "pirq_needs_eoi_v2" is misleading because
PHYSDEVOP_pirq_eoi_gmfn only works for PV guests at the moment.
How about I call the new function "pirq_check_eoi_map" and rename the old
one "pirq_needs_eoi_flag" and the generic name of the function pointer
would remain "pirq_needs_eoi"?


> >  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> >  }
> >  
> > @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
> >  
> >  void __init xen_init_IRQ(void)
> >  {
> > -	int i;
> > +	int i, rc;
> >  
> >  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
> >  				    GFP_KERNEL);
> > @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
> >  		 * __acpi_register_gsi can point at the right function */
> >  		pci_xen_hvm_init();
> >  	} else {
> > +		struct physdev_pirq_eoi_gmfn eoi_gmfn;
> > +
> >  		irq_ctx_init(smp_processor_id());
> >  		if (xen_initial_domain())
> >  			pci_xen_initial_domain();
> > +
> > +		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> > +		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> > +		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);
> 
> 
> Don't we want the v2 version?
> 
> > +		if (rc != 0) {
> > +			free_page((unsigned long) pirq_eoi_map);
> > +			pirq_eoi_map = NULL;
> > +		}
> >  	}
> >  }
> > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > index c1080d9..132c61f 100644
> > --- a/include/xen/interface/physdev.h
> > +++ b/include/xen/interface/physdev.h
> > @@ -39,6 +39,18 @@ struct physdev_eoi {
> >  };
> >  
> >  /*
> > + * Register a shared page for the hypervisor to indicate whether the
> > + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> > + * array indexed by Xen's PIRQ value.
> > + */
> > +#define PHYSDEVOP_pirq_eoi_gmfn      28
> 
> Ah, the number is right, but the name is the generic one.
> 
> We should really mention that this is different from v1 or just
> 
> #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> and use that in the code?

Maybe we should:

#define PHYSDEVOP_pirq_eoi_gmfn_v2 28

in order not to hide the fact that there are two versions of this
hypercall.
Then we do:

/* we use the second version of the hypercall */
#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2


This way we just have PHYSDEVOP_pirq_eoi_gmfn in the code but we don't
hide the version with are using.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 11:03:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 11: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 1RqjZu-0006TX-OQ; Fri, 27 Jan 2012 11:02:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqjZs-0006TP-L3
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 11:02:44 +0000
Received: from [85.158.138.51:62977] by server-6.bemta-3.messagelabs.com id
	0C/E1-31032-354822F4; Fri, 27 Jan 2012 11:02:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327662163!10915543!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 417 invoked from network); 27 Jan 2012 11:02:43 -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;
	27 Jan 2012 11:02:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10324812"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 11:02: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, 27 Jan 2012 11:02:43 +0000
Date: Fri, 27 Jan 2012 11:03:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120126185155.GA24768@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201271058090.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
	<1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120126185155.GA24768@phenom.dumpdata.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>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> > The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> > be EOI'd without having to issue an hypercall every time.
> > We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> > succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  drivers/xen/events.c            |   17 ++++++++++++++++-
> >  include/xen/interface/physdev.h |   12 ++++++++++++
> >  2 files changed, 28 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > index 6e075cd..7fdc738 100644
> > --- a/drivers/xen/events.c
> > +++ b/drivers/xen/events.c
> > @@ -37,6 +37,7 @@
> >  #include <asm/idle.h>
> >  #include <asm/io_apic.h>
> >  #include <asm/sync_bitops.h>
> > +#include <asm/xen/page.h>
> >  #include <asm/xen/pci.h>
> >  #include <asm/xen/hypercall.h>
> >  #include <asm/xen/hypervisor.h>
> > @@ -108,6 +109,7 @@ struct irq_info {
> >  #define PIRQ_SHAREABLE	(1 << 1)
> >  
> >  static int *evtchn_to_irq;
> > +static unsigned long *pirq_eoi_map;
> >  
> >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> >  		      cpu_evtchn_mask);
> > @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
> >  
> >  	BUG_ON(info->type != IRQT_PIRQ);
> >  
> > +	if (pirq_eoi_map != NULL)
> > +		return test_bit(irq, pirq_eoi_map);
> > +
> 
> How about just having a different function called
> pirq_needs_eoi_v2 which will just do
> 
>  return test_bit(irq, pirq_eoi_map)?
> 
> And then set the pirq_needs_eoi_v2 in the function table?

Ok, but the name "pirq_needs_eoi_v2" is misleading because
PHYSDEVOP_pirq_eoi_gmfn only works for PV guests at the moment.
How about I call the new function "pirq_check_eoi_map" and rename the old
one "pirq_needs_eoi_flag" and the generic name of the function pointer
would remain "pirq_needs_eoi"?


> >  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> >  }
> >  
> > @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
> >  
> >  void __init xen_init_IRQ(void)
> >  {
> > -	int i;
> > +	int i, rc;
> >  
> >  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
> >  				    GFP_KERNEL);
> > @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
> >  		 * __acpi_register_gsi can point at the right function */
> >  		pci_xen_hvm_init();
> >  	} else {
> > +		struct physdev_pirq_eoi_gmfn eoi_gmfn;
> > +
> >  		irq_ctx_init(smp_processor_id());
> >  		if (xen_initial_domain())
> >  			pci_xen_initial_domain();
> > +
> > +		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> > +		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> > +		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);
> 
> 
> Don't we want the v2 version?
> 
> > +		if (rc != 0) {
> > +			free_page((unsigned long) pirq_eoi_map);
> > +			pirq_eoi_map = NULL;
> > +		}
> >  	}
> >  }
> > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > index c1080d9..132c61f 100644
> > --- a/include/xen/interface/physdev.h
> > +++ b/include/xen/interface/physdev.h
> > @@ -39,6 +39,18 @@ struct physdev_eoi {
> >  };
> >  
> >  /*
> > + * Register a shared page for the hypervisor to indicate whether the
> > + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> > + * array indexed by Xen's PIRQ value.
> > + */
> > +#define PHYSDEVOP_pirq_eoi_gmfn      28
> 
> Ah, the number is right, but the name is the generic one.
> 
> We should really mention that this is different from v1 or just
> 
> #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> and use that in the code?

Maybe we should:

#define PHYSDEVOP_pirq_eoi_gmfn_v2 28

in order not to hide the fact that there are two versions of this
hypercall.
Then we do:

/* we use the second version of the hypercall */
#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2


This way we just have PHYSDEVOP_pirq_eoi_gmfn in the code but we don't
hide the version with are using.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 11:21:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 11: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 1Rqjrt-0007Ec-2K; Fri, 27 Jan 2012 11:21:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqjrr-0007EX-NS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 11:21:20 +0000
Received: from [85.158.138.51:13096] by server-6.bemta-3.messagelabs.com id
	F5/38-31032-EA8822F4; Fri, 27 Jan 2012 11:21:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327663277!9053449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4196 invoked from network); 27 Jan 2012 11:21:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 11:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10325277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 11:21: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, 27 Jan 2012 11:21:17 +0000
Date: Fri, 27 Jan 2012 11:22:16 +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: <1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

The patch series is definitely going in the right direction.


> +
>  .PHONY: all
>  all: $(ALL_TARGETS)
>  
> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
>  
>  CFLAGS += -DHAVE_DTRACE=1
>  endif
> - 
> +
>  xenstored: $(XENSTORED_OBJS)
>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
> +xenstored.a: $(XENSTORED_OBJS)
> +	$(AR) cr $@ $^
> +
>  $(CLIENTS): xenstore
>  	ln -f xenstore $@
>  
> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
> index f378343..2effd17 100644
> --- a/tools/xenstore/utils.h
> +++ b/tools/xenstore/utils.h
> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>  	return streq(a + strlen(a) - strlen(b), b);
>  }
>  
> +#ifndef ARRAY_SIZE
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
>  
>  void barf(const char *fmt, ...) __attribute__((noreturn));
>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 4b12cf2..0b9d4f2 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -224,7 +224,6 @@ static void reopen_log(void)
>  	}
>  }
>  
> -
>  static bool write_messages(struct connection *conn)
>  {
>  	int ret;
> @@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  		set_fd(sock, inset, &max);
>  	if (ro_sock != -1)
>  		set_fd(ro_sock, inset, &max);
> -	set_fd(reopen_log_pipe[0], inset, &max);
> +	if (reopen_log_pipe[0] != -1)
> +		set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
>  
>  
> +#ifdef __MINIOS__
> +static void write_pidfile(const char *pidfile)
> +{
> +}
> +
> +static void daemonize(void)
> +{
> +}
> +
> +static void finish_daemonize(void)
> +{
> +}
> +#else
>  static void write_pidfile(const char *pidfile)
>  {
>  	char buf[100];
> @@ -1711,6 +1724,19 @@ static void daemonize(void)
>  	umask(0);
>  }
>  
> +static void finish_daemonize(void)
> +{
> +	int devnull = open("/dev/null", O_RDWR);
> +	if (devnull == -1)
> +		barf_perror("Could not open /dev/null\n");
> +	dup2(devnull, STDIN_FILENO);
> +	dup2(devnull, STDOUT_FILENO);
> +	dup2(devnull, STDERR_FILENO);
> +	close(devnull);
> +	xprintf = trace;
> +}
> +#endif
> +
>  #ifdef NO_SOCKETS
>  static void init_sockets(int **psock, int **pro_sock)
>  {

At this point we could have the MiniOS version of write_pidfile,
daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and the
Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c.


> ---
>  tools/xenstore/Makefile           |    9 ++++-
>  tools/xenstore/utils.h            |    2 +
>  tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
>  tools/xenstore/xenstored_domain.c |   11 +++++
>  4 files changed, 68 insertions(+), 28 deletions(-)
> 
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 4facb62..be892fd 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -28,6 +28,10 @@ endif
>  
>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>  
> +ifdef CONFIG_STUBDOM
> +CFLAGS += -DNO_SOCKETS=1
> +endif

> @@ -1822,6 +1848,11 @@ int main(int argc, char *argv[])
>  	int evtchn_fd = -1;
>  	struct timeval *timeout;
>  
> +#ifdef __MINIOS__
> +	/* minios always uses internal DB */
> +	tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
> +#endif

can you use the "internal-db" command line option?


>  	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
>  				  NULL)) != -1) {
>  		switch (opt) {
> @@ -1874,20 +1905,10 @@ int main(int argc, char *argv[])
>  
>  	reopen_log();
>  
> -	/* make sure xenstored directory exists */
> -	if (mkdir(xs_daemon_rundir(), 0755)) {
> -		if (errno != EEXIST) {
> -			perror("error: mkdir daemon rundir");
> -			exit(-1);
> -		}
> -	}
> -
> -	if (mkdir(xs_daemon_rootdir(), 0755)) {
> -		if (errno != EEXIST) {
> -			perror("error: mkdir daemon rootdir");
> -			exit(-1);
> -		}
> -	}
> +	/* make sure xenstored directories exist */
> +	/* Errors ignored here, will be reported when we open files */
> +	mkdir(xs_daemon_rundir(), 0755);
> +	mkdir(xs_daemon_rootdir(), 0755);
>  
>  	if (dofork) {
>  		openlog("xenstored", 0, LOG_DAEMON);
> @@ -1905,9 +1926,14 @@ int main(int argc, char *argv[])
>  
>  	init_sockets(&sock, &ro_sock);
>  
> +#ifdef __MINIOS__
> +	reopen_log_pipe[0] = -1;
> +	reopen_log_pipe[1] = -1;
> +#else
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
>  	}
> +#endif

maybe we could have open/read/write_log_pipe functions?


>  	/* Setup the database */
>  	setup_structure();
> @@ -1925,16 +1951,8 @@ int main(int argc, char *argv[])
>  	}
>  
>  	/* redirect to /dev/null now we're ready to accept connections */
> -	if (dofork) {
> -		int devnull = open("/dev/null", O_RDWR);
> -		if (devnull == -1)
> -			barf_perror("Could not open /dev/null\n");
> -		dup2(devnull, STDIN_FILENO);
> -		dup2(devnull, STDOUT_FILENO);
> -		dup2(devnull, STDERR_FILENO);
> -		close(devnull);
> -		xprintf = trace;
> -	}
> +	if (dofork)
> +		finish_daemonize();
>  
>  	signal(SIGHUP, trigger_reopen_log);
>  
> @@ -1944,8 +1962,10 @@ int main(int argc, char *argv[])
>  	/* Get ready to listen to the tools. */
>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>  
> +#ifndef __MINIOS__
>  	/* Tell the kernel we're up and running. */
>  	xenbus_notify_running();
> +#endif
>  
>  	/* Main loop. */
>  	for (;;) {
> @@ -1957,7 +1977,7 @@ int main(int argc, char *argv[])
>  			barf_perror("Select failed");
>  		}
>  
> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>  			char c;
>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>  				barf_perror("read failed");
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index c521e52..4243f91 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -197,12 +197,16 @@ static int destroy_domain(void *_domain)
>  	}
>  
>  	if (domain->interface) {
> +#ifdef __MINIOS__
> +		unmap_interface(domain->interface);
> +#else
>  		/* Domain 0 was mapped by dom0_init, so it must be unmapped
>  		   using munmap() and not the grant unmap call. */
>  		if (domain->domid == 0)
>  			munmap(domain->interface, getpagesize());
>  		else
>  			unmap_interface(domain->interface);
> +#endif
>  	}
>  
>  	fire_watches(NULL, "@releaseDomain", false);
> @@ -597,6 +601,12 @@ void restore_existing_connections(void)
>  {
>  }
>  
> +#ifdef __MINIOS__
> +static int dom0_init(void)
> +{
> +	return 0;
> +}
> +#else
>  static int dom0_init(void) 
>  { 
>  	evtchn_port_t port;
> @@ -620,6 +630,7 @@ static int dom0_init(void)
>  
>  	return 0; 
>  }
> +#endif

another candidate to be moved to xenstored_minios/linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 11:21:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 11: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 1Rqjrt-0007Ec-2K; Fri, 27 Jan 2012 11:21:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqjrr-0007EX-NS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 11:21:20 +0000
Received: from [85.158.138.51:13096] by server-6.bemta-3.messagelabs.com id
	F5/38-31032-EA8822F4; Fri, 27 Jan 2012 11:21:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327663277!9053449!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4196 invoked from network); 27 Jan 2012 11:21:18 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 11:21:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10325277"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 11:21: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, 27 Jan 2012 11:21:17 +0000
Date: Fri, 27 Jan 2012 11:22:16 +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: <1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 26 Jan 2012, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
> 
> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

The patch series is definitely going in the right direction.


> +
>  .PHONY: all
>  all: $(ALL_TARGETS)
>  
> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
>  
>  CFLAGS += -DHAVE_DTRACE=1
>  endif
> - 
> +
>  xenstored: $(XENSTORED_OBJS)
>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
> +xenstored.a: $(XENSTORED_OBJS)
> +	$(AR) cr $@ $^
> +
>  $(CLIENTS): xenstore
>  	ln -f xenstore $@
>  
> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
> index f378343..2effd17 100644
> --- a/tools/xenstore/utils.h
> +++ b/tools/xenstore/utils.h
> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>  	return streq(a + strlen(a) - strlen(b), b);
>  }
>  
> +#ifndef ARRAY_SIZE
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
>  
>  void barf(const char *fmt, ...) __attribute__((noreturn));
>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 4b12cf2..0b9d4f2 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -224,7 +224,6 @@ static void reopen_log(void)
>  	}
>  }
>  
> -
>  static bool write_messages(struct connection *conn)
>  {
>  	int ret;
> @@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  		set_fd(sock, inset, &max);
>  	if (ro_sock != -1)
>  		set_fd(ro_sock, inset, &max);
> -	set_fd(reopen_log_pipe[0], inset, &max);
> +	if (reopen_log_pipe[0] != -1)
> +		set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
>  
>  
> +#ifdef __MINIOS__
> +static void write_pidfile(const char *pidfile)
> +{
> +}
> +
> +static void daemonize(void)
> +{
> +}
> +
> +static void finish_daemonize(void)
> +{
> +}
> +#else
>  static void write_pidfile(const char *pidfile)
>  {
>  	char buf[100];
> @@ -1711,6 +1724,19 @@ static void daemonize(void)
>  	umask(0);
>  }
>  
> +static void finish_daemonize(void)
> +{
> +	int devnull = open("/dev/null", O_RDWR);
> +	if (devnull == -1)
> +		barf_perror("Could not open /dev/null\n");
> +	dup2(devnull, STDIN_FILENO);
> +	dup2(devnull, STDOUT_FILENO);
> +	dup2(devnull, STDERR_FILENO);
> +	close(devnull);
> +	xprintf = trace;
> +}
> +#endif
> +
>  #ifdef NO_SOCKETS
>  static void init_sockets(int **psock, int **pro_sock)
>  {

At this point we could have the MiniOS version of write_pidfile,
daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and the
Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c.


> ---
>  tools/xenstore/Makefile           |    9 ++++-
>  tools/xenstore/utils.h            |    2 +
>  tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
>  tools/xenstore/xenstored_domain.c |   11 +++++
>  4 files changed, 68 insertions(+), 28 deletions(-)
> 
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 4facb62..be892fd 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -28,6 +28,10 @@ endif
>  
>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>  
> +ifdef CONFIG_STUBDOM
> +CFLAGS += -DNO_SOCKETS=1
> +endif

> @@ -1822,6 +1848,11 @@ int main(int argc, char *argv[])
>  	int evtchn_fd = -1;
>  	struct timeval *timeout;
>  
> +#ifdef __MINIOS__
> +	/* minios always uses internal DB */
> +	tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
> +#endif

can you use the "internal-db" command line option?


>  	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
>  				  NULL)) != -1) {
>  		switch (opt) {
> @@ -1874,20 +1905,10 @@ int main(int argc, char *argv[])
>  
>  	reopen_log();
>  
> -	/* make sure xenstored directory exists */
> -	if (mkdir(xs_daemon_rundir(), 0755)) {
> -		if (errno != EEXIST) {
> -			perror("error: mkdir daemon rundir");
> -			exit(-1);
> -		}
> -	}
> -
> -	if (mkdir(xs_daemon_rootdir(), 0755)) {
> -		if (errno != EEXIST) {
> -			perror("error: mkdir daemon rootdir");
> -			exit(-1);
> -		}
> -	}
> +	/* make sure xenstored directories exist */
> +	/* Errors ignored here, will be reported when we open files */
> +	mkdir(xs_daemon_rundir(), 0755);
> +	mkdir(xs_daemon_rootdir(), 0755);
>  
>  	if (dofork) {
>  		openlog("xenstored", 0, LOG_DAEMON);
> @@ -1905,9 +1926,14 @@ int main(int argc, char *argv[])
>  
>  	init_sockets(&sock, &ro_sock);
>  
> +#ifdef __MINIOS__
> +	reopen_log_pipe[0] = -1;
> +	reopen_log_pipe[1] = -1;
> +#else
>  	if (pipe(reopen_log_pipe)) {
>  		barf_perror("pipe");
>  	}
> +#endif

maybe we could have open/read/write_log_pipe functions?


>  	/* Setup the database */
>  	setup_structure();
> @@ -1925,16 +1951,8 @@ int main(int argc, char *argv[])
>  	}
>  
>  	/* redirect to /dev/null now we're ready to accept connections */
> -	if (dofork) {
> -		int devnull = open("/dev/null", O_RDWR);
> -		if (devnull == -1)
> -			barf_perror("Could not open /dev/null\n");
> -		dup2(devnull, STDIN_FILENO);
> -		dup2(devnull, STDOUT_FILENO);
> -		dup2(devnull, STDERR_FILENO);
> -		close(devnull);
> -		xprintf = trace;
> -	}
> +	if (dofork)
> +		finish_daemonize();
>  
>  	signal(SIGHUP, trigger_reopen_log);
>  
> @@ -1944,8 +1962,10 @@ int main(int argc, char *argv[])
>  	/* Get ready to listen to the tools. */
>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>  
> +#ifndef __MINIOS__
>  	/* Tell the kernel we're up and running. */
>  	xenbus_notify_running();
> +#endif
>  
>  	/* Main loop. */
>  	for (;;) {
> @@ -1957,7 +1977,7 @@ int main(int argc, char *argv[])
>  			barf_perror("Select failed");
>  		}
>  
> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>  			char c;
>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>  				barf_perror("read failed");
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index c521e52..4243f91 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -197,12 +197,16 @@ static int destroy_domain(void *_domain)
>  	}
>  
>  	if (domain->interface) {
> +#ifdef __MINIOS__
> +		unmap_interface(domain->interface);
> +#else
>  		/* Domain 0 was mapped by dom0_init, so it must be unmapped
>  		   using munmap() and not the grant unmap call. */
>  		if (domain->domid == 0)
>  			munmap(domain->interface, getpagesize());
>  		else
>  			unmap_interface(domain->interface);
> +#endif
>  	}
>  
>  	fire_watches(NULL, "@releaseDomain", false);
> @@ -597,6 +601,12 @@ void restore_existing_connections(void)
>  {
>  }
>  
> +#ifdef __MINIOS__
> +static int dom0_init(void)
> +{
> +	return 0;
> +}
> +#else
>  static int dom0_init(void) 
>  { 
>  	evtchn_port_t port;
> @@ -620,6 +630,7 @@ static int dom0_init(void)
>  
>  	return 0; 
>  }
> +#endif

another candidate to be moved to xenstored_minios/linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 11:50:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 11: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 1RqkJB-0007je-GA; Fri, 27 Jan 2012 11:49:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqkJA-0007jZ-9z
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 11:49:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327664960!2870706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8823 invoked from network); 27 Jan 2012 11:49:20 -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;
	27 Jan 2012 11:49:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10326038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 11:49:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 11:49:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 27 Jan 2012 11:49:19 +0000
In-Reply-To: <alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327664960.26983.165.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 11:22 +0000, Stefano Stabellini wrote:
> 
> >  #ifdef NO_SOCKETS
> >  static void init_sockets(int **psock, int **pro_sock)
> >  {
> 
> At this point we could have the MiniOS version of write_pidfile,
> daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and
> the Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c. 

xenstored_linux would be a terribly misleading name.

Better xenstored_posix or something like that.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 11:50:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 11: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 1RqkJB-0007je-GA; Fri, 27 Jan 2012 11:49:33 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqkJA-0007jZ-9z
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 11:49:32 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327664960!2870706!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8823 invoked from network); 27 Jan 2012 11:49:20 -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;
	27 Jan 2012 11:49:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10326038"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 11:49:20 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 11:49:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 27 Jan 2012 11:49:19 +0000
In-Reply-To: <alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327664960.26983.165.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Alex Zeffertt <alex.zeffertt@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Diego Ongaro <diego.ongaro@citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 11:22 +0000, Stefano Stabellini wrote:
> 
> >  #ifdef NO_SOCKETS
> >  static void init_sockets(int **psock, int **pro_sock)
> >  {
> 
> At this point we could have the MiniOS version of write_pidfile,
> daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and
> the Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c. 

xenstored_linux would be a terribly misleading name.

Better xenstored_posix or something like that.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:25:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqkrm-0000IE-Pw; Fri, 27 Jan 2012 12:25:18 +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 1Rqkrl-0000Hu-CT
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:25:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327667110!8438768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28086 invoked from network); 27 Jan 2012 12:25:11 -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;
	27 Jan 2012 12:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10327066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 12:25: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; Fri, 27 Jan 2012 12:25:09 +0000
Date: Fri, 27 Jan 2012 12:26:08 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/5] prevent Qemu from waking up needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents Qemu from waking up needlessly on Xen
several times a second in order to check some timers.


The first patch stops Qemu from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that Qemu doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.



Shortlog and diffstat follow:

Stefano Stabellini (5):
      xen: do not initialize the interval timer emulator
      xen: disable rtc_clock
      xen: introduce an event channel for buffered io event notifications
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      qemu_calculate_timeout: increase minimum timeout to 1h

 hw/pc.c      |    7 +++++--
 qemu-timer.c |   12 +++++-------
 xen-all.c    |   43 +++++++++++++++++++++++++++++++++++++------
 3 files changed, 47 insertions(+), 15 deletions(-)


A git tree available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:25:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:25:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqkrm-0000IE-Pw; Fri, 27 Jan 2012 12:25:18 +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 1Rqkrl-0000Hu-CT
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:25:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327667110!8438768!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28086 invoked from network); 27 Jan 2012 12:25:11 -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;
	27 Jan 2012 12:25:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320624000"; d="scan'208";a="10327066"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 12:25: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; Fri, 27 Jan 2012 12:25:09 +0000
Date: Fri, 27 Jan 2012 12:26:08 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/5] prevent Qemu from waking up needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents Qemu from waking up needlessly on Xen
several times a second in order to check some timers.


The first patch stops Qemu from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that Qemu doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.



Shortlog and diffstat follow:

Stefano Stabellini (5):
      xen: do not initialize the interval timer emulator
      xen: disable rtc_clock
      xen: introduce an event channel for buffered io event notifications
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      qemu_calculate_timeout: increase minimum timeout to 1h

 hw/pc.c      |    7 +++++--
 qemu-timer.c |   12 +++++-------
 xen-all.c    |   43 +++++++++++++++++++++++++++++++++++++------
 3 files changed, 47 insertions(+), 15 deletions(-)


A git tree available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqksT-0000MV-7v; Fri, 27 Jan 2012 12:26:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqksS-0000Lk-El
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327667152!2438532!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27954 invoked from network); 27 Jan 2012 12:25:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 12:25:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="21340887"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:25:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:25:51 -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 q0RCPhWZ012742;
	Fri, 27 Jan 2012 04:25:44 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:51 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/5] xen: do not initialize the interval
	timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 85304cf..7a7ce98 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -43,6 +43,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     DriveInfo *fd[MAX_FD];
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-    pit = pit_init(isa_bus, 0x40, 0);
+    if (!xen_available()) {
+        pit = pit_init(isa_bus, 0x40, 0);
+    }
     pcspk_init(pit);
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:26:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqksT-0000MV-7v; Fri, 27 Jan 2012 12:26:01 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqksS-0000Lk-El
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:00 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327667152!2438532!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27954 invoked from network); 27 Jan 2012 12:25:53 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 12:25:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="21340887"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:25:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:25:51 -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 q0RCPhWZ012742;
	Fri, 27 Jan 2012 04:25:44 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:51 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/5] xen: do not initialize the interval
	timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 85304cf..7a7ce98 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -43,6 +43,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     DriveInfo *fd[MAX_FD];
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-    pit = pit_init(isa_bus, 0x40, 0);
+    if (!xen_available()) {
+        pit = pit_init(isa_bus, 0x40, 0);
+    }
     pcspk_init(pit);
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqksY-0000NY-LG; Fri, 27 Jan 2012 12:26:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqksX-0000MH-04
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327667152!2438532!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28491 invoked from network); 27 Jan 2012 12:25:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 12:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="21340889"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:25:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:25: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 q0RCPhWa012742;
	Fri, 27 Jan 2012 04:25:46 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:52 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index d1fc597..bf183f7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -513,6 +513,7 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    qemu_clock_enable(rtc_clock, false);
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:26:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqksY-0000NY-LG; Fri, 27 Jan 2012 12:26:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqksX-0000MH-04
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:05 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327667152!2438532!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28491 invoked from network); 27 Jan 2012 12:25:58 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 12:25:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="21340889"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:25:58 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:25: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 q0RCPhWa012742;
	Fri, 27 Jan 2012 04:25:46 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:52 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index d1fc597..bf183f7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -513,6 +513,7 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    qemu_clock_enable(rtc_clock, false);
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqksg-0000Q7-SC; Fri, 27 Jan 2012 12:26:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqksf-0000PH-1L
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:13 +0000
Received: from [85.158.139.83:45419] by server-6.bemta-5.messagelabs.com id
	82/0E-21889-1E7922F4; Fri, 27 Jan 2012 12:26:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327667167!12607433!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7383 invoked from network); 27 Jan 2012 12:26:08 -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;
	27 Jan 2012 12:26:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="179352802"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:25:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:25: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 q0RCPhWb012742;
	Fri, 27 Jan 2012 04:25:47 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:53 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 3/5] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   42 ++++++++++++++++++++++++++++++++++++------
 1 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bf183f7..bfec4c1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -77,6 +77,8 @@ typedef struct XenIOState {
     QEMUTimer *buffered_io_timer;
     /* the evtchn port for polling the notification, */
     evtchn_port_t *ioreq_local_port;
+    /* evtchn local port for buffered io */
+    evtchn_port_t bufioreq_local_port;
     /* the evtchn fd for polling */
     XenEvtchn xce_handle;
     /* which vcpu we are serving */
@@ -545,6 +547,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(state->xce_handle);
+    if (port == state->bufioreq_local_port) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+        return NULL;
+    }
+
     if (port != -1) {
         for (i = 0; i < smp_cpus; i++) {
             if (state->ioreq_local_port[i] == port) {
@@ -693,16 +701,18 @@ static void handle_ioreq(ioreq_t *req)
     }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!state->buffered_io_page) {
-        return;
+        return 0;
     }
 
+    memset(&req, 0x00, sizeof(req));
+
     while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {
         buf_req = &state->buffered_io_page->buf_ioreq[
             state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -727,15 +737,21 @@ static void handle_buffered_iopage(XenIOState *state)
         xen_mb();
         state->buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     XenIOState *state = opaque;
 
-    handle_buffered_iopage(state);
-    qemu_mod_timer(state->buffered_io_timer,
-                   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    if (handle_buffered_iopage(state)) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    } else {
+        qemu_del_timer(state->buffered_io_timer);
+        xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -865,7 +881,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
     state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
                                                  state);
-    qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -917,6 +932,7 @@ int xen_hvm_init(void)
 {
     int i, rc;
     unsigned long ioreq_pfn;
+    unsigned long bufioreq_evtchn;
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -966,6 +982,20 @@ int xen_hvm_init(void)
         state->ioreq_local_port[i] = rc;
     }
 
+    rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+            &bufioreq_evtchn);
+    if (rc < 0) {
+        fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+        return -1;
+    }
+    rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+            (uint32_t)bufioreq_evtchn);
+    if (rc == -1) {
+        fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+        return -1;
+    }
+    state->bufioreq_local_port = rc;
+
     /* Init RAM management */
     xen_map_cache_init();
     xen_ram_init(ram_size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:26:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqksg-0000Q7-SC; Fri, 27 Jan 2012 12:26:14 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqksf-0000PH-1L
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:13 +0000
Received: from [85.158.139.83:45419] by server-6.bemta-5.messagelabs.com id
	82/0E-21889-1E7922F4; Fri, 27 Jan 2012 12:26:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327667167!12607433!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7383 invoked from network); 27 Jan 2012 12:26:08 -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;
	27 Jan 2012 12:26:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="179352802"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:25:59 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:25: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 q0RCPhWb012742;
	Fri, 27 Jan 2012 04:25:47 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:53 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 3/5] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   42 ++++++++++++++++++++++++++++++++++++------
 1 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bf183f7..bfec4c1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -77,6 +77,8 @@ typedef struct XenIOState {
     QEMUTimer *buffered_io_timer;
     /* the evtchn port for polling the notification, */
     evtchn_port_t *ioreq_local_port;
+    /* evtchn local port for buffered io */
+    evtchn_port_t bufioreq_local_port;
     /* the evtchn fd for polling */
     XenEvtchn xce_handle;
     /* which vcpu we are serving */
@@ -545,6 +547,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(state->xce_handle);
+    if (port == state->bufioreq_local_port) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+        return NULL;
+    }
+
     if (port != -1) {
         for (i = 0; i < smp_cpus; i++) {
             if (state->ioreq_local_port[i] == port) {
@@ -693,16 +701,18 @@ static void handle_ioreq(ioreq_t *req)
     }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!state->buffered_io_page) {
-        return;
+        return 0;
     }
 
+    memset(&req, 0x00, sizeof(req));
+
     while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {
         buf_req = &state->buffered_io_page->buf_ioreq[
             state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -727,15 +737,21 @@ static void handle_buffered_iopage(XenIOState *state)
         xen_mb();
         state->buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     XenIOState *state = opaque;
 
-    handle_buffered_iopage(state);
-    qemu_mod_timer(state->buffered_io_timer,
-                   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    if (handle_buffered_iopage(state)) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    } else {
+        qemu_del_timer(state->buffered_io_timer);
+        xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -865,7 +881,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
     state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
                                                  state);
-    qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -917,6 +932,7 @@ int xen_hvm_init(void)
 {
     int i, rc;
     unsigned long ioreq_pfn;
+    unsigned long bufioreq_evtchn;
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -966,6 +982,20 @@ int xen_hvm_init(void)
         state->ioreq_local_port[i] = rc;
     }
 
+    rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+            &bufioreq_evtchn);
+    if (rc < 0) {
+        fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+        return -1;
+    }
+    rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+            (uint32_t)bufioreq_evtchn);
+    if (rc == -1) {
+        fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+        return -1;
+    }
+    state->bufioreq_local_port = rc;
+
     /* Init RAM management */
     xen_map_cache_init();
     xen_ram_init(ram_size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12: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 1Rqksf-0000PM-3L; Fri, 27 Jan 2012 12:26:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqksc-0000OU-Rm
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:11 +0000
Received: from [85.158.139.83:45503] by server-10.bemta-5.messagelabs.com id
	87/28-18919-2E7922F4; Fri, 27 Jan 2012 12:26:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327667167!12607433!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7438 invoked from network); 27 Jan 2012 12:26:09 -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;
	27 Jan 2012 12:26:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="179352805"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:26:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:26: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 q0RCPhWc012742;
	Fri, 27 Jan 2012 04:25:49 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:54 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index cd026c6..648db1d 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12: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 1Rqksf-0000PM-3L; Fri, 27 Jan 2012 12:26:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqksc-0000OU-Rm
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:11 +0000
Received: from [85.158.139.83:45503] by server-10.bemta-5.messagelabs.com id
	87/28-18919-2E7922F4; Fri, 27 Jan 2012 12:26:10 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327667167!12607433!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7438 invoked from network); 27 Jan 2012 12:26:09 -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;
	27 Jan 2012 12:26:09 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="179352805"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:26:01 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:26: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 q0RCPhWc012742;
	Fri, 27 Jan 2012 04:25:49 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:54 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index cd026c6..648db1d 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:26:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqksf-0000Pc-GA; Fri, 27 Jan 2012 12:26:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqkse-0000Ow-7x
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:12 +0000
Received: from [85.158.139.83:45557] by server-3.bemta-5.messagelabs.com id
	65/13-16424-3E7922F4; Fri, 27 Jan 2012 12:26:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327667167!12607433!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7517 invoked from network); 27 Jan 2012 12:26:10 -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;
	27 Jan 2012 12:26:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="179352800"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:25:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:25: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 q0RCPhWd012742;
	Fri, 27 Jan 2012 04:25:50 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:55 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase minimum
	timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 648db1d..b792a32 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -844,6 +844,6 @@ fail:
 
 int qemu_calculate_timeout(void)
 {
-    return 1000;
+    return 1000*60*60;
 }
 
-- 
1.7.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 Jan 27 12:26:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:26:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqksf-0000Pc-GA; Fri, 27 Jan 2012 12:26:13 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rqkse-0000Ow-7x
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:26:12 +0000
Received: from [85.158.139.83:45557] by server-3.bemta-5.messagelabs.com id
	65/13-16424-3E7922F4; Fri, 27 Jan 2012 12:26:11 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327667167!12607433!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7517 invoked from network); 27 Jan 2012 12:26:10 -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;
	27 Jan 2012 12:26:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,579,1320642000"; d="scan'208";a="179352800"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 07:25:57 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 07:25: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 q0RCPhWd012742;
	Fri, 27 Jan 2012 04:25:50 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 12:26:55 +0000
Message-ID: <1327667215-5411-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.1201271211400.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
MIME-Version: 1.0
Cc: xen-devel@lists.xensource.com, avi@redhat.com, anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase minimum
	timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 648db1d..b792a32 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -844,6 +844,6 @@ fail:
 
 int qemu_calculate_timeout(void)
 {
-    return 1000;
+    return 1000*60*60;
 }
 
-- 
1.7.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 Jan 27 12:36:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rql2B-0001T8-VU; Fri, 27 Jan 2012 12:36:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rql29-0001T0-Go
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:36:02 +0000
Received: from [85.158.138.51:27015] by server-3.bemta-3.messagelabs.com id
	AF/B6-26314-03A922F4; Fri, 27 Jan 2012 12:36:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327667759!9066971!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19164 invoked from network); 27 Jan 2012 12:35:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Jan 2012 12:35:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327667759; l=584;
	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=tFOLqx4HLLlPZIAFYY+J0cV2+iI=;
	b=cnc2QFWQjiQnStUsoq/uEEs2WBSSpZzN0LnZpvgY0sD/SHU+zh4inqXEhfRCe9QX7tT
	Z6PElB/4BBJuCzHj2exHHjr0YR+LhXppaKfiBrp74H1iuzLYaEqpsU0Dytpz1dpTgUGqo
	8nNI7rDECobGPnbYGWsTi1Q8uhW2ovyhaVI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhy0MFy6a
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-099-249.pools.arcor-ip.net [88.65.99.249])
	by post.strato.de (mrclete mo47) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id K04b18o0RBaSak ;
	Fri, 27 Jan 2012 13:35:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 72DE418637; Fri, 27 Jan 2012 13:35:53 +0100 (CET)
Date: Fri, 27 Jan 2012 13:35:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120127123553.GA28750@aepfle.de>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
	<317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
	<20120126163810.GA9137@aepfle.de>
	<55d685d4f7e551ab7c854c509a63f895.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <55d685d4f7e551ab7c854c509a63f895.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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, Andres Lagar-Cavilla wrote:

> You could pass the whole arr sub-segment encompassing the first and last
> gfn that failed with ENOENT. Successful maps within that array will be
> re-done by the hypervisor, at no correctness cost. I would imagine that
> the extra work is offset by the gains, but that remains to be seen.

I just tried it once again, and as xenpaging is written now a live
migration of an idle 512MB guest with 90MB paging target was done in
less than a minute. Previously it took a very long time, 2MB/sec. were
sent over the wire.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 12:36:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 12:36:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rql2B-0001T8-VU; Fri, 27 Jan 2012 12:36:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rql29-0001T0-Go
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 12:36:02 +0000
Received: from [85.158.138.51:27015] by server-3.bemta-3.messagelabs.com id
	AF/B6-26314-03A922F4; Fri, 27 Jan 2012 12:36:00 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327667759!9066971!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19164 invoked from network); 27 Jan 2012 12:35:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Jan 2012 12:35:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327667759; l=584;
	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=tFOLqx4HLLlPZIAFYY+J0cV2+iI=;
	b=cnc2QFWQjiQnStUsoq/uEEs2WBSSpZzN0LnZpvgY0sD/SHU+zh4inqXEhfRCe9QX7tT
	Z6PElB/4BBJuCzHj2exHHjr0YR+LhXppaKfiBrp74H1iuzLYaEqpsU0Dytpz1dpTgUGqo
	8nNI7rDECobGPnbYGWsTi1Q8uhW2ovyhaVI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhy0MFy6a
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-099-249.pools.arcor-ip.net [88.65.99.249])
	by post.strato.de (mrclete mo47) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id K04b18o0RBaSak ;
	Fri, 27 Jan 2012 13:35:50 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 72DE418637; Fri, 27 Jan 2012 13:35:53 +0100 (CET)
Date: Fri, 27 Jan 2012 13:35:53 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Message-ID: <20120127123553.GA28750@aepfle.de>
References: <mailman.1648.1327589466.1471.xen-devel@lists.xensource.com>
	<317844de67b9293a2e45ecd879a1c58a.squirrel@webmail.lagarcavilla.org>
	<20120126163810.GA9137@aepfle.de>
	<55d685d4f7e551ab7c854c509a63f895.squirrel@webmail.lagarcavilla.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <55d685d4f7e551ab7c854c509a63f895.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] tools/libxc: send page-in requests in
 batches in linux_privcmd_map_foreign_bulk
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, Andres Lagar-Cavilla wrote:

> You could pass the whole arr sub-segment encompassing the first and last
> gfn that failed with ENOENT. Successful maps within that array will be
> re-done by the hypervisor, at no correctness cost. I would imagine that
> the extra work is offset by the gains, but that remains to be seen.

I just tried it once again, and as xenpaging is written now a live
migration of an idle 512MB guest with 90MB paging target was done in
less than a minute. Previously it took a very long time, 2MB/sec. were
sent over the wire.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 13:06:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqlVS-00034g-P5; Fri, 27 Jan 2012 13:06: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 1RqlVQ-00034S-Sp
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:06:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327669570!12823796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1338 invoked from network); 27 Jan 2012 13:06:10 -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;
	27 Jan 2012 13:06:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10328011"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:06: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, 27 Jan 2012 13:06:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 13:06:08 +0000
In-Reply-To: <1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327669569.26983.178.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/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> The symbol _LINUX_LIST_H collides with other header files.

Hrm mini-os is supposed to have been BSD licensed since
19712:7a215fae6f1f and that symbol name is *rather* suspicious.

The thread associated with that commit[0] suggests that everything GPL
had been rewritten but I suspect that due to the lack of GPL header this
file was missed.

This effectively means that any work combined with mini-os was GPL
rather than BSD as might reasonably have been expected. I believe
everything in-tree which we link with mini-os (the stubdom/ tree) is GPL
or GPL-compatible but this has laid rather a nasty trap for anyone else
using mini-os and I think we should fix it ASAP. Below is a patch which
switches to using the same BSD sys/queue.h list macros as we use in
libxl.

Presumably you came across another file which used _LINUX_LIST_H which
clashed? Out of interest what was it?

Ian.

8<------------------------------------------------------------------------

[0] http://lists.xen.org/archives/html/xen-devel/2009-06/msg00123.html

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327669492 0
# Node ID 72f001fd2bc43d18a63c1db6202d830b42b53d95
# Parent  b78b11c15aa818f81cb77324938c6293edeed63d
mini-os: use BSD sys/queue.h instead of Linux list.h

The latter is GPL which makes the whole of mini-os GPL rather than BSD
as intended. In tree users are all GPL or GPL-compatible but we should
fix this so that mini-os is BSD. Do so by using the same BSD
sys/queue.h as we use in libxl.

Tested with the builtin mini-os test app and qemu stubdomain, both of which
appear to still function as expected.

Move tools/libxl/external and the associated sed script to
tools/include/xen-external to allow more sensible access from mini-os.

Also add s/NULL/0/ in the sed script due to NULL not always being
defined in stubdom code when mini-os/wait.h is included.

As well as the obvious ABI changes there are a few API updates
associated with the change:

  - struct rw_semaphore.wait_list is unused
  - remove_waiter needs to take the wait_queue_head

The latter requires a qemu update which I will post separately. Please
apply first and update QEMU_TAG as appropriate.

I sprinkled some extra-emacs local variables around the files I edited
which didn't have them.

I think this should be backported to the stable branches since
external users of mini-os may have been mislead into thinking they
could safely link mini-os against GPL-incompatible code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -62,6 +62,7 @@
 ^docs/xen-api/xenapi-datamodel-graph.eps$
 ^docs/xen-api/xenapi.out$
 ^extras/mini-os/arch/ia64/gen_off.s$
+^extras/mini-os/include/list\.h$
 ^extras/mini-os/include/mini-os$
 ^extras/mini-os/include/ia64/mini-os$
 ^extras/mini-os/include/ia64/offsets.h$
diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -52,8 +52,12 @@ ifneq ($(ARCH_LINKS),)
 	$(arch_links)
 endif
 
+include/list.h: $(XEN_ROOT)/tools/include/xen-external/bsd-sys-queue-h-seddery $(XEN_ROOT)/tools/include/xen-external/bsd-sys-queue.h
+	perl $^ --prefix=minios  >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 .PHONY: links
-links:	$(ARCH_LINKS)
+links: include/list.h $(ARCH_LINKS)
 	[ -e include/xen ] || ln -sf ../../../xen/include/public include/xen
 	[ -e include/mini-os ] || ln -sf . include/mini-os
 	[ -e include/$(TARGET_ARCH_FAM)/mini-os ] || ln -sf . include/$(TARGET_ARCH_FAM)/mini-os
@@ -97,7 +101,7 @@ ifneq ($(APP_OBJS),)
 APP_O=$(OBJ_DIR)/$(TARGET)_app.o 
 endif
 
-$(OBJ_DIR)/$(TARGET): links $(OBJS) $(APP_O) arch_lib
+$(OBJ_DIR)/$(TARGET): links include/list.h $(OBJS) $(APP_O) arch_lib
 	$(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(APP_O) $(OBJS) $(LDARCHLIB) $(LDLIBS) -o $@.o
 	$(OBJCOPY) -w -G $(GLOBAL_PREFIX)* -G _start $@.o $@.o
 	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@
@@ -112,6 +116,7 @@ clean:	arch_clean
 	for dir in $(addprefix $(OBJ_DIR)/,$(SUBDIRS)); do \
 		rm -f $$dir/*.o; \
 	done
+	rm -f include/list.h
 	rm -f $(OBJ_DIR)/*.o *~ $(OBJ_DIR)/core $(OBJ_DIR)/$(TARGET).elf $(OBJ_DIR)/$(TARGET).raw $(OBJ_DIR)/$(TARGET) $(OBJ_DIR)/$(TARGET).gz
 	find . $(OBJ_DIR) -type l | xargs rm -f
 	$(RM) $(OBJ_DIR)/lwip.a $(LWO)
diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -323,7 +323,7 @@ static void blkfront_wait_slot(struct bl
 	    schedule();
 	    local_irq_save(flags);
 	}
-	remove_waiter(w);
+	remove_waiter(w, blkfront_queue);
 	local_irq_restore(flags);
     }
 }
@@ -414,7 +414,7 @@ void blkfront_io(struct blkfront_aiocb *
 	schedule();
 	local_irq_save(flags);
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
     local_irq_restore(flags);
 }
 
@@ -470,7 +470,7 @@ void blkfront_sync(struct blkfront_dev *
 	schedule();
 	local_irq_save(flags);
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
     local_irq_restore(flags);
 }
 
diff --git a/extras/mini-os/fbfront.c b/extras/mini-os/fbfront.c
--- a/extras/mini-os/fbfront.c
+++ b/extras/mini-os/fbfront.c
@@ -569,7 +569,7 @@ static void fbfront_out_event(struct fbf
     add_waiter(w, fbfront_queue);
     while (page->out_prod - page->out_cons == XENFB_OUT_RING_LEN)
         schedule();
-    remove_waiter(w);
+    remove_waiter(w, fbfront_queue);
 
     prod = page->out_prod;
     mb(); /* ensure ring space available */
diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
deleted file mode 100644
--- a/extras/mini-os/include/list.h
+++ /dev/null
@@ -1,190 +0,0 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
-
-/*
- * Simple doubly linked list implementation.
- *
- * Some of the internal functions ("__xxx") are useful when
- * manipulating whole lists rather than single entries, as
- * sometimes we already know the next/prev entries and we can
- * generate better code by using them directly rather than
- * using the generic single-entry routines.
- */
-
-struct minios_list_head {
-	struct minios_list_head *next, *prev;
-};
-
-#define MINIOS_LIST_HEAD_INIT(name) { &(name), &(name) }
-
-#define MINIOS_LIST_HEAD(name) \
-	struct minios_list_head name = MINIOS_LIST_HEAD_INIT(name)
-
-#define MINIOS_INIT_LIST_HEAD(ptr) do { \
-	(ptr)->next = (ptr); (ptr)->prev = (ptr); \
-} while (0)
-
-#define minios_list_top(head, type, member)					  \
-({ 									  \
-	struct minios_list_head *_head = (head);				  \
-	minios_list_empty(_head) ? NULL : minios_list_entry(_head->next, type, member); \
-})
-
-/*
- * Insert a new entry between two known consecutive entries. 
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static __inline__ void __minios_list_add(struct minios_list_head * new,
-	struct minios_list_head * prev,
-	struct minios_list_head * next)
-{
-	next->prev = new;
-	new->next = next;
-	new->prev = prev;
-	prev->next = new;
-}
-
-/**
- * minios_list_add - add a new entry
- * @new: new entry to be added
- * @head: list head to add it after
- *
- * Insert a new entry after the specified head.
- * This is good for implementing stacks.
- */
-static __inline__ void minios_list_add(struct minios_list_head *new, struct minios_list_head *head)
-{
-	__minios_list_add(new, head, head->next);
-}
-
-/**
- * minios_list_add_tail - add a new entry
- * @new: new entry to be added
- * @head: list head to add it before
- *
- * Insert a new entry before the specified head.
- * This is useful for implementing queues.
- */
-static __inline__ void minios_list_add_tail(struct minios_list_head *new, struct minios_list_head *head)
-{
-	__minios_list_add(new, head->prev, head);
-}
-
-/*
- * Delete a list entry by making the prev/next entries
- * point to each other.
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static __inline__ void __minios_list_del(struct minios_list_head * prev,
-				  struct minios_list_head * next)
-{
-	next->prev = prev;
-	prev->next = next;
-}
-
-/**
- * minios_list_del - deletes entry from list.
- * @entry: the element to delete from the list.
- * Note: minios_list_empty on entry does not return true after this, the entry is in an undefined state.
- */
-static __inline__ void minios_list_del(struct minios_list_head *entry)
-{
-	__minios_list_del(entry->prev, entry->next);
-}
-
-/**
- * minios_list_del_init - deletes entry from list and reinitialize it.
- * @entry: the element to delete from the list.
- */
-static __inline__ void minios_list_del_init(struct minios_list_head *entry)
-{
-	__minios_list_del(entry->prev, entry->next);
-	MINIOS_INIT_LIST_HEAD(entry); 
-}
-
-/**
- * minios_list_empty - tests whether a list is empty
- * @head: the list to test.
- */
-static __inline__ int minios_list_empty(struct minios_list_head *head)
-{
-	return head->next == head;
-}
-
-/**
- * minios_list_splice - join two lists
- * @list: the new list to add.
- * @head: the place to add it in the first list.
- */
-static __inline__ void minios_list_splice(struct minios_list_head *list, struct minios_list_head *head)
-{
-	struct minios_list_head *first = list->next;
-
-	if (first != list) {
-		struct minios_list_head *last = list->prev;
-		struct minios_list_head *at = head->next;
-
-		first->prev = head;
-		head->next = first;
-
-		last->next = at;
-		at->prev = last;
-	}
-}
-
-/**
- * minios_list_entry - get the struct for this entry
- * @ptr:	the &struct minios_list_head pointer.
- * @type:	the type of the struct this is embedded in.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_entry(ptr, type, member) \
-	((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))
-
-/**
- * minios_list_for_each	-	iterate over a list
- * @pos:	the &struct minios_list_head to use as a loop counter.
- * @head:	the head for your list.
- */
-#define minios_list_for_each(pos, head) \
-	for (pos = (head)->next; pos != (head); pos = pos->next)
-        	
-/**
- * minios_list_for_each_safe	-	iterate over a list safe against removal of list entry
- * @pos:	the &struct minios_list_head to use as a loop counter.
- * @n:		another &struct minios_list_head to use as temporary storage
- * @head:	the head for your list.
- */
-#define minios_list_for_each_safe(pos, n, head) \
-	for (pos = (head)->next, n = pos->next; pos != (head); \
-		pos = n, n = pos->next)
-
-/**
- * minios_list_for_each_entry	-	iterate over list of given type
- * @pos:	the type * to use as a loop counter.
- * @head:	the head for your list.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_for_each_entry(pos, head, member)				\
-	for (pos = minios_list_entry((head)->next, typeof(*pos), member);	\
-	     &pos->member != (head); 					\
-	     pos = minios_list_entry(pos->member.next, typeof(*pos), member))
-
-/**
- * minios_list_for_each_entry_safe - iterate over list of given type safe against removal of list entry
- * @pos:	the type * to use as a loop counter.
- * @n:		another type * to use as temporary storage
- * @head:	the head for your list.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_for_each_entry_safe(pos, n, head, member)			\
-	for (pos = minios_list_entry((head)->next, typeof(*pos), member),	\
-		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
-	     &pos->member != (head); 					\
-	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
-
diff --git a/extras/mini-os/include/sched.h b/extras/mini-os/include/sched.h
--- a/extras/mini-os/include/sched.h
+++ b/extras/mini-os/include/sched.h
@@ -19,7 +19,7 @@ struct thread
 #else /* !defined(__ia64__) */
     thread_regs_t regs;
 #endif /* !defined(__ia64__) */
-    struct minios_list_head thread_list;
+    MINIOS_TAILQ_ENTRY(struct thread) thread_list;
     uint32_t flags;
     s_time_t wakeup_time;
 #ifdef HAVE_LIBC
diff --git a/extras/mini-os/include/semaphore.h b/extras/mini-os/include/semaphore.h
--- a/extras/mini-os/include/semaphore.h
+++ b/extras/mini-os/include/semaphore.h
@@ -21,7 +21,6 @@ struct semaphore
 struct rw_semaphore {
 	signed long		count;
 	spinlock_t		wait_lock;
-	struct minios_list_head	wait_list;
 	int			debug;
 };
 
diff --git a/extras/mini-os/include/wait.h b/extras/mini-os/include/wait.h
--- a/extras/mini-os/include/wait.h
+++ b/extras/mini-os/include/wait.h
@@ -5,47 +5,47 @@
 #include <mini-os/os.h>
 #include <mini-os/waittypes.h>
 
-#define DEFINE_WAIT(name)                               \
-struct wait_queue name = {                              \
-    .thread       = get_current(),                            \
-    .thread_list  = MINIOS_LIST_HEAD_INIT((name).thread_list), \
+#define DEFINE_WAIT(name)                          \
+struct wait_queue name = {                         \
+    .thread       = get_current(),                 \
+    .waiting      = 0,                             \
 }
 
 
 static inline void init_waitqueue_head(struct wait_queue_head *h)
 {
-  MINIOS_INIT_LIST_HEAD(&h->thread_list);
+    MINIOS_STAILQ_INIT(h);
 }
 
 static inline void init_waitqueue_entry(struct wait_queue *q, struct thread *thread)
 {
     q->thread = thread;
-    MINIOS_INIT_LIST_HEAD(&q->thread_list);
+    q->waiting = 0;
 }
 
-
 static inline void add_wait_queue(struct wait_queue_head *h, struct wait_queue *q)
 {
-    if (minios_list_empty(&q->thread_list))
-        minios_list_add(&q->thread_list, &h->thread_list);   
+    if (!q->waiting) {
+        MINIOS_STAILQ_INSERT_HEAD(h, q, thread_list);
+        q->waiting = 1;
+    }
 }
 
-static inline void remove_wait_queue(struct wait_queue *q)
+static inline void remove_wait_queue(struct wait_queue_head *h, struct wait_queue *q)
 {
-    minios_list_del(&q->thread_list);
+    if (q->waiting) {
+        MINIOS_STAILQ_REMOVE(h, q, struct wait_queue, thread_list);
+        q->waiting = 0;
+    }
 }
 
 static inline void wake_up(struct wait_queue_head *head)
 {
     unsigned long flags;
-    struct minios_list_head *tmp, *next;
+    struct wait_queue *curr, *tmp;
     local_irq_save(flags);
-    minios_list_for_each_safe(tmp, next, &head->thread_list)
-    {
-         struct wait_queue *curr;
-         curr = minios_list_entry(tmp, struct wait_queue, thread_list);
+    MINIOS_STAILQ_FOREACH_SAFE(curr, head, thread_list, tmp)
          wake(curr->thread);
-    }
     local_irq_restore(flags);
 }
 
@@ -57,11 +57,11 @@ static inline void wake_up(struct wait_q
     local_irq_restore(flags);   \
 } while (0)
 
-#define remove_waiter(w) do {   \
-    unsigned long flags;        \
-    local_irq_save(flags);      \
-    remove_wait_queue(&w);      \
-    local_irq_restore(flags);   \
+#define remove_waiter(w, wq) do {  \
+    unsigned long flags;           \
+    local_irq_save(flags);         \
+    remove_wait_queue(&wq, &w);    \
+    local_irq_restore(flags);      \
 } while (0)
 
 #define wait_event_deadline(wq, condition, deadline) do {       \
@@ -84,7 +84,7 @@ static inline void wake_up(struct wait_q
     local_irq_save(flags);                                      \
     /* need to wake up */                                       \
     wake(get_current());                                        \
-    remove_wait_queue(&__wait);                                 \
+    remove_wait_queue(&wq, &__wait);                            \
     local_irq_restore(flags);                                   \
 } while(0) 
 
@@ -93,3 +93,13 @@ static inline void wake_up(struct wait_q
 
 
 #endif /* __WAIT_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/include/waittypes.h b/extras/mini-os/include/waittypes.h
--- a/extras/mini-os/include/waittypes.h
+++ b/extras/mini-os/include/waittypes.h
@@ -6,21 +6,27 @@
 struct thread;
 struct wait_queue
 {
+    int waiting;
     struct thread *thread;
-    struct minios_list_head thread_list;
+    MINIOS_STAILQ_ENTRY(struct wait_queue) thread_list;
 };
 
-struct wait_queue_head
-{
-    /* TODO - lock required? */
-    struct minios_list_head thread_list;
-};
+/* TODO - lock required? */
+MINIOS_STAILQ_HEAD(wait_queue_head, struct wait_queue);
 
 #define DECLARE_WAIT_QUEUE_HEAD(name) \
-   struct wait_queue_head name =     \
-        { .thread_list = { &(name).thread_list, &(name).thread_list} }
+    struct wait_queue_head name = MINIOS_STAILQ_HEAD_INITIALIZER(name)
 
-#define __WAIT_QUEUE_HEAD_INITIALIZER(name) {                           \
-    .thread_list      = { &(name).thread_list, &(name).thread_list } }
+#define __WAIT_QUEUE_HEAD_INITIALIZER(name) MINIOS_STAILQ_HEAD_INITIALIZER(name)
 
 #endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -234,7 +234,7 @@ int read(int fd, void *buf, size_t nbyte
                     break;
                 schedule();
             }
-            remove_waiter(w);
+            remove_waiter(w, console_queue);
             return ret;
         }
 #ifdef HAVE_LWIP
@@ -705,12 +705,12 @@ int select(int nfds, fd_set *readfds, fd
     fd_set myread, mywrite, myexcept;
     struct thread *thread = get_current();
     s_time_t start = NOW(), stop;
-    DEFINE_WAIT(w1);
-    DEFINE_WAIT(w2);
-    DEFINE_WAIT(w3);
-    DEFINE_WAIT(w4);
-    DEFINE_WAIT(w5);
-    DEFINE_WAIT(w6);
+    DEFINE_WAIT(netfront_w);
+    DEFINE_WAIT(event_w);
+    DEFINE_WAIT(blkfront_w);
+    DEFINE_WAIT(xenbus_watch_w);
+    DEFINE_WAIT(kbdfront_w);
+    DEFINE_WAIT(console_w);
 
     assert(thread == main_thread);
 
@@ -727,12 +727,12 @@ int select(int nfds, fd_set *readfds, fd
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
-    add_waiter(w1, netfront_queue);
-    add_waiter(w2, event_queue);
-    add_waiter(w3, blkfront_queue);
-    add_waiter(w4, xenbus_watch_queue);
-    add_waiter(w5, kbdfront_queue);
-    add_waiter(w6, console_queue);
+    add_waiter(netfront_w, netfront_queue);
+    add_waiter(event_w, event_queue);
+    add_waiter(blkfront_w, blkfront_queue);
+    add_waiter(xenbus_watch_w, xenbus_watch_queue);
+    add_waiter(kbdfront_w, kbdfront_queue);
+    add_waiter(console_w, console_queue);
 
     if (readfds)
         myread = *readfds;
@@ -814,12 +814,12 @@ int select(int nfds, fd_set *readfds, fd
     ret = -1;
 
 out:
-    remove_waiter(w1);
-    remove_waiter(w2);
-    remove_waiter(w3);
-    remove_waiter(w4);
-    remove_waiter(w5);
-    remove_waiter(w6);
+    remove_waiter(netfront_w, netfront_queue);
+    remove_waiter(event_w, event_queue);
+    remove_waiter(blkfront_w, blkfront_queue);
+    remove_waiter(xenbus_watch_w, xenbus_watch_queue);
+    remove_waiter(kbdfront_w, kbdfront_queue);
+    remove_waiter(console_w, console_queue);
     return ret;
 }
 
diff --git a/extras/mini-os/lib/xmalloc.c b/extras/mini-os/lib/xmalloc.c
--- a/extras/mini-os/lib/xmalloc.c
+++ b/extras/mini-os/lib/xmalloc.c
@@ -44,16 +44,18 @@
 #include <mini-os/xmalloc.h>
 
 #ifndef HAVE_LIBC
-static MINIOS_LIST_HEAD(freelist);
 /* static spinlock_t freelist_lock = SPIN_LOCK_UNLOCKED; */
 
 struct xmalloc_hdr
 {
     /* Total including this hdr, unused padding and second hdr. */
     size_t size;
-    struct minios_list_head freelist;
+    MINIOS_TAILQ_ENTRY(struct xmalloc_hdr) freelist;
 } __cacheline_aligned;
 
+static MINIOS_TAILQ_HEAD(,struct xmalloc_hdr) freelist =
+	MINIOS_TAILQ_HEAD_INITIALIZER(freelist);
+
 /* Unused padding data between the two hdrs. */
 
 struct xmalloc_pad
@@ -82,7 +84,7 @@ static void maybe_split(struct xmalloc_h
         extra = (struct xmalloc_hdr *)((unsigned long)hdr + size);
         extra->size = leftover;
         /* spin_lock_irqsave(&freelist_lock, flags); */
-        minios_list_add(&extra->freelist, &freelist);
+        MINIOS_TAILQ_INSERT_HEAD(&freelist, extra, freelist);
         /* spin_unlock_irqrestore(&freelist_lock, flags); */
     }
     else
@@ -91,8 +93,6 @@ static void maybe_split(struct xmalloc_h
     }
 
     hdr->size = size;
-    /* Debugging aid. */
-    hdr->freelist.next = hdr->freelist.prev = NULL;
 }
 
 static struct xmalloc_hdr *xmalloc_new_page(size_t size)
@@ -128,8 +128,6 @@ static void *xmalloc_whole_pages(size_t 
         return NULL;
 
     hdr->size = (1UL << (pageorder + PAGE_SHIFT));
-    /* Debugging aid. */
-    hdr->freelist.next = hdr->freelist.prev = NULL;
 
     ret = (char*)hdr + hdr_size;
     pad = (struct xmalloc_pad *) ret - 1;
@@ -155,14 +153,14 @@ void *_xmalloc(size_t size, size_t align
 
     /* Search free list. */
     /* spin_lock_irqsave(&freelist_lock, flags); */
-    minios_list_for_each_entry_safe( i, tmp, &freelist, freelist )
+    MINIOS_TAILQ_FOREACH_SAFE(i, &freelist, freelist, tmp)
     {
         data_begin = align_up((uintptr_t)i + hdr_size, align);
 
         if ( data_begin + size > (uintptr_t)i + i->size )
             continue;
 
-        minios_list_del(&i->freelist);
+        MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
         /* spin_unlock_irqrestore(&freelist_lock, flags); */
 
         uintptr_t size_before = (data_begin - hdr_size) - (uintptr_t)i;
@@ -173,7 +171,7 @@ void *_xmalloc(size_t size, size_t align
             new_i->size = i->size - size_before;
             i->size = size_before;
             /* spin_lock_irqsave(&freelist_lock, flags); */
-            minios_list_add(&i->freelist, &freelist);
+            MINIOS_TAILQ_INSERT_HEAD(&freelist, i, freelist);
             /* spin_unlock_irqrestore(&freelist_lock, flags); */
             i = new_i;
         }
@@ -224,16 +222,9 @@ void xfree(const void *p)
         *(int*)0=0;
     }
 
-    /* Not previously freed. */
-    if(hdr->freelist.next || hdr->freelist.prev)
-    {
-        printk("Should not be previously freed\n");
-        *(int*)0=0;
-    }
-
     /* Merge with other free block, or put in list. */
     /* spin_lock_irqsave(&freelist_lock, flags); */
-    minios_list_for_each_entry_safe( i, tmp, &freelist, freelist )
+    MINIOS_TAILQ_FOREACH_SAFE(i, &freelist, freelist, tmp)
     {
         unsigned long _i   = (unsigned long)i;
         unsigned long _hdr = (unsigned long)hdr;
@@ -245,7 +236,7 @@ void xfree(const void *p)
         /* We follow this block?  Swallow it. */
         if ( (_i + i->size) == _hdr )
         {
-            minios_list_del(&i->freelist);
+            MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
             i->size += hdr->size;
             hdr = i;
         }
@@ -253,7 +244,7 @@ void xfree(const void *p)
         /* We precede this block? Swallow it. */
         if ( (_hdr + hdr->size) == _i )
         {
-            minios_list_del(&i->freelist);
+            MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
             hdr->size += i->size;
         }
     }
@@ -270,7 +261,7 @@ void xfree(const void *p)
     }
     else
     {
-        minios_list_add(&hdr->freelist, &freelist);
+        MINIOS_TAILQ_INSERT_HEAD(&freelist, hdr, freelist);
     }
 
     /* spin_unlock_irqrestore(&freelist_lock, flags); */
@@ -306,3 +297,13 @@ void *_realloc(void *ptr, size_t size)
     return new;
 }
 #endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/sched.c b/extras/mini-os/sched.c
--- a/extras/mini-os/sched.c
+++ b/extras/mini-os/sched.c
@@ -54,19 +54,20 @@
 #define DEBUG(_f, _a...)    ((void)0)
 #endif
 
+MINIOS_TAILQ_HEAD(thread_list, struct thread);
+
 struct thread *idle_thread = NULL;
-MINIOS_LIST_HEAD(exited_threads);
+static struct thread_list exited_threads = MINIOS_TAILQ_HEAD_INITIALIZER(exited_threads);
+static struct thread_list thread_list = MINIOS_TAILQ_HEAD_INITIALIZER(thread_list);
 static int threads_started;
 
 struct thread *main_thread;
 
 void inline print_runqueue(void)
 {
-    struct minios_list_head *it;
     struct thread *th;
-    minios_list_for_each(it, &idle_thread->thread_list)
+    MINIOS_TAILQ_FOREACH(th, &thread_list, thread_list)
     {
-        th = minios_list_entry(it, struct thread, thread_list);
         printk("   Thread \"%s\", runnable=%d\n", th->name, is_runnable(th));
     }
     printk("\n");
@@ -74,8 +75,7 @@ void inline print_runqueue(void)
 
 void schedule(void)
 {
-    struct thread *prev, *next, *thread;
-    struct minios_list_head *iterator, *next_iterator;
+    struct thread *prev, *next, *thread, *tmp;
     unsigned long flags;
 
     prev = current;
@@ -96,10 +96,9 @@ void schedule(void)
            time when the next timeout expires, else use 10 seconds. */
         s_time_t now = NOW();
         s_time_t min_wakeup_time = now + SECONDS(10);
-        next = NULL;   
-        minios_list_for_each_safe(iterator, next_iterator, &idle_thread->thread_list)
+        next = NULL;
+        MINIOS_TAILQ_FOREACH_SAFE(thread, &thread_list, thread_list, tmp)
         {
-            thread = minios_list_entry(iterator, struct thread, thread_list);
             if (!is_runnable(thread) && thread->wakeup_time != 0LL)
             {
                 if (thread->wakeup_time <= now)
@@ -111,8 +110,8 @@ void schedule(void)
             {
                 next = thread;
                 /* Put this thread on the end of the list */
-                minios_list_del(&thread->thread_list);
-                minios_list_add_tail(&thread->thread_list, &idle_thread->thread_list);
+                MINIOS_TAILQ_REMOVE(&thread_list, thread, thread_list);
+                MINIOS_TAILQ_INSERT_TAIL(&thread_list, thread, thread_list);
                 break;
             }
         }
@@ -128,12 +127,11 @@ void schedule(void)
        inturrupted at the return instruction. And therefore at safe point. */
     if(prev != next) switch_threads(prev, next);
 
-    minios_list_for_each_safe(iterator, next_iterator, &exited_threads)
+    MINIOS_TAILQ_FOREACH_SAFE(thread, &exited_threads, thread_list, tmp)
     {
-        thread = minios_list_entry(iterator, struct thread, thread_list);
         if(thread != prev)
         {
-            minios_list_del(&thread->thread_list);
+            MINIOS_TAILQ_REMOVE(&exited_threads, thread, thread_list);
             free_pages(thread->stack, STACK_SIZE_PAGE_ORDER);
             xfree(thread);
         }
@@ -154,13 +152,7 @@ struct thread* create_thread(char *name,
 #endif
     set_runnable(thread);
     local_irq_save(flags);
-    if(idle_thread != NULL) {
-        minios_list_add_tail(&thread->thread_list, &idle_thread->thread_list); 
-    } else if(function != idle_thread_fn)
-    {
-        printk("BUG: Not allowed to create thread before initialising scheduler.\n");
-        BUG();
-    }
+    MINIOS_TAILQ_INSERT_TAIL(&thread_list, thread, thread_list);
     local_irq_restore(flags);
     return thread;
 }
@@ -208,10 +200,10 @@ void exit_thread(void)
     printk("Thread \"%s\" exited.\n", thread->name);
     local_irq_save(flags);
     /* Remove from the thread list */
-    minios_list_del(&thread->thread_list);
+    MINIOS_TAILQ_REMOVE(&thread_list, thread, thread_list);
     clear_runnable(thread);
     /* Put onto exited list */
-    minios_list_add(&thread->thread_list, &exited_threads);
+    MINIOS_TAILQ_INSERT_HEAD(&exited_threads, thread, thread_list);
     local_irq_restore(flags);
     /* Schedule will free the resources */
     while(1)
@@ -296,6 +288,14 @@ void init_sched(void)
     _REENT_INIT_PTR((&callback_reent))
 #endif
     idle_thread = create_thread("Idle", idle_thread_fn, NULL);
-    MINIOS_INIT_LIST_HEAD(&idle_thread->thread_list);
 }
 
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c
+++ b/extras/mini-os/xenbus/xenbus.c
@@ -85,7 +85,7 @@ char **xenbus_wait_for_watch_return(xenb
         add_waiter(w, xenbus_watch_queue);
         schedule();
     }
-    remove_waiter(w);
+    remove_waiter(w, xenbus_watch_queue);
     *queue = event->next;
     return &event->path;
 }
@@ -441,7 +441,7 @@ xenbus_msg_reply(int type,
     xb_write(type, id, trans, io, nr_reqs);
 
     schedule();
-    remove_waiter(w);
+    remove_waiter(w, req_info[id].waitq);
     wake(current);
 
     rep = req_info[id].reply;
diff --git a/tools/libxl/external/README b/tools/include/xen-external/README
rename from tools/libxl/external/README
rename to tools/include/xen-external/README
--- a/tools/libxl/external/README
+++ b/tools/include/xen-external/README
@@ -1,5 +1,5 @@
-WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
------------------------------------------------------------------------
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY
+----------------------------------------------
 
 These files were obtained elsewhere and should only be updated by
 copying new versions from the source location, as documented below:
@@ -12,3 +12,13 @@ bsd-queue.3
     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
+
+Exceptions:
+
+README
+
+  This file
+
+bsd-sys-queue-h-seddery
+
+  Script to transform the above into a new namespace.
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/include/xen-external/bsd-COPYRIGHT
rename from tools/libxl/external/bsd-COPYRIGHT
rename to tools/include/xen-external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/include/xen-external/bsd-queue.3
rename from tools/libxl/external/bsd-queue.3
rename to tools/include/xen-external/bsd-queue.3
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/include/xen-external/bsd-sys-queue-h-seddery
rename from tools/libxl/bsd-sys-queue-h-seddery
rename to tools/include/xen-external/bsd-sys-queue-h-seddery
--- a/tools/libxl/bsd-sys-queue-h-seddery
+++ b/tools/include/xen-external/bsd-sys-queue-h-seddery
@@ -68,3 +68,5 @@ s/\b(
 s/\b struct \s+ type \b/type/xg;
 
 s,^\#include.*sys/cdefs.*,/* $& */,xg;
+
+s/\b( NULL )/0/xg;
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/include/xen-external/bsd-sys-queue.h
rename from tools/libxl/external/bsd-sys-queue.h
rename to tools/include/xen-external/bsd-sys-queue.h
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -93,8 +93,8 @@ _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
+_libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
+	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
 libxl_paths.c: _libxl_paths.h



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 13:06:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:06:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqlVS-00034g-P5; Fri, 27 Jan 2012 13:06: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 1RqlVQ-00034S-Sp
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:06:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327669570!12823796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1338 invoked from network); 27 Jan 2012 13:06:10 -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;
	27 Jan 2012 13:06:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10328011"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:06: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, 27 Jan 2012 13:06:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Ian Jackson
	<Ian.Jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 13:06:08 +0000
In-Reply-To: <1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327669569.26983.178.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/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> The symbol _LINUX_LIST_H collides with other header files.

Hrm mini-os is supposed to have been BSD licensed since
19712:7a215fae6f1f and that symbol name is *rather* suspicious.

The thread associated with that commit[0] suggests that everything GPL
had been rewritten but I suspect that due to the lack of GPL header this
file was missed.

This effectively means that any work combined with mini-os was GPL
rather than BSD as might reasonably have been expected. I believe
everything in-tree which we link with mini-os (the stubdom/ tree) is GPL
or GPL-compatible but this has laid rather a nasty trap for anyone else
using mini-os and I think we should fix it ASAP. Below is a patch which
switches to using the same BSD sys/queue.h list macros as we use in
libxl.

Presumably you came across another file which used _LINUX_LIST_H which
clashed? Out of interest what was it?

Ian.

8<------------------------------------------------------------------------

[0] http://lists.xen.org/archives/html/xen-devel/2009-06/msg00123.html

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327669492 0
# Node ID 72f001fd2bc43d18a63c1db6202d830b42b53d95
# Parent  b78b11c15aa818f81cb77324938c6293edeed63d
mini-os: use BSD sys/queue.h instead of Linux list.h

The latter is GPL which makes the whole of mini-os GPL rather than BSD
as intended. In tree users are all GPL or GPL-compatible but we should
fix this so that mini-os is BSD. Do so by using the same BSD
sys/queue.h as we use in libxl.

Tested with the builtin mini-os test app and qemu stubdomain, both of which
appear to still function as expected.

Move tools/libxl/external and the associated sed script to
tools/include/xen-external to allow more sensible access from mini-os.

Also add s/NULL/0/ in the sed script due to NULL not always being
defined in stubdom code when mini-os/wait.h is included.

As well as the obvious ABI changes there are a few API updates
associated with the change:

  - struct rw_semaphore.wait_list is unused
  - remove_waiter needs to take the wait_queue_head

The latter requires a qemu update which I will post separately. Please
apply first and update QEMU_TAG as appropriate.

I sprinkled some extra-emacs local variables around the files I edited
which didn't have them.

I think this should be backported to the stable branches since
external users of mini-os may have been mislead into thinking they
could safely link mini-os against GPL-incompatible code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff --git a/.hgignore b/.hgignore
--- a/.hgignore
+++ b/.hgignore
@@ -62,6 +62,7 @@
 ^docs/xen-api/xenapi-datamodel-graph.eps$
 ^docs/xen-api/xenapi.out$
 ^extras/mini-os/arch/ia64/gen_off.s$
+^extras/mini-os/include/list\.h$
 ^extras/mini-os/include/mini-os$
 ^extras/mini-os/include/ia64/mini-os$
 ^extras/mini-os/include/ia64/offsets.h$
diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -52,8 +52,12 @@ ifneq ($(ARCH_LINKS),)
 	$(arch_links)
 endif
 
+include/list.h: $(XEN_ROOT)/tools/include/xen-external/bsd-sys-queue-h-seddery $(XEN_ROOT)/tools/include/xen-external/bsd-sys-queue.h
+	perl $^ --prefix=minios  >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 .PHONY: links
-links:	$(ARCH_LINKS)
+links: include/list.h $(ARCH_LINKS)
 	[ -e include/xen ] || ln -sf ../../../xen/include/public include/xen
 	[ -e include/mini-os ] || ln -sf . include/mini-os
 	[ -e include/$(TARGET_ARCH_FAM)/mini-os ] || ln -sf . include/$(TARGET_ARCH_FAM)/mini-os
@@ -97,7 +101,7 @@ ifneq ($(APP_OBJS),)
 APP_O=$(OBJ_DIR)/$(TARGET)_app.o 
 endif
 
-$(OBJ_DIR)/$(TARGET): links $(OBJS) $(APP_O) arch_lib
+$(OBJ_DIR)/$(TARGET): links include/list.h $(OBJS) $(APP_O) arch_lib
 	$(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(APP_O) $(OBJS) $(LDARCHLIB) $(LDLIBS) -o $@.o
 	$(OBJCOPY) -w -G $(GLOBAL_PREFIX)* -G _start $@.o $@.o
 	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@
@@ -112,6 +116,7 @@ clean:	arch_clean
 	for dir in $(addprefix $(OBJ_DIR)/,$(SUBDIRS)); do \
 		rm -f $$dir/*.o; \
 	done
+	rm -f include/list.h
 	rm -f $(OBJ_DIR)/*.o *~ $(OBJ_DIR)/core $(OBJ_DIR)/$(TARGET).elf $(OBJ_DIR)/$(TARGET).raw $(OBJ_DIR)/$(TARGET) $(OBJ_DIR)/$(TARGET).gz
 	find . $(OBJ_DIR) -type l | xargs rm -f
 	$(RM) $(OBJ_DIR)/lwip.a $(LWO)
diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -323,7 +323,7 @@ static void blkfront_wait_slot(struct bl
 	    schedule();
 	    local_irq_save(flags);
 	}
-	remove_waiter(w);
+	remove_waiter(w, blkfront_queue);
 	local_irq_restore(flags);
     }
 }
@@ -414,7 +414,7 @@ void blkfront_io(struct blkfront_aiocb *
 	schedule();
 	local_irq_save(flags);
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
     local_irq_restore(flags);
 }
 
@@ -470,7 +470,7 @@ void blkfront_sync(struct blkfront_dev *
 	schedule();
 	local_irq_save(flags);
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
     local_irq_restore(flags);
 }
 
diff --git a/extras/mini-os/fbfront.c b/extras/mini-os/fbfront.c
--- a/extras/mini-os/fbfront.c
+++ b/extras/mini-os/fbfront.c
@@ -569,7 +569,7 @@ static void fbfront_out_event(struct fbf
     add_waiter(w, fbfront_queue);
     while (page->out_prod - page->out_cons == XENFB_OUT_RING_LEN)
         schedule();
-    remove_waiter(w);
+    remove_waiter(w, fbfront_queue);
 
     prod = page->out_prod;
     mb(); /* ensure ring space available */
diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
deleted file mode 100644
--- a/extras/mini-os/include/list.h
+++ /dev/null
@@ -1,190 +0,0 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
-
-/*
- * Simple doubly linked list implementation.
- *
- * Some of the internal functions ("__xxx") are useful when
- * manipulating whole lists rather than single entries, as
- * sometimes we already know the next/prev entries and we can
- * generate better code by using them directly rather than
- * using the generic single-entry routines.
- */
-
-struct minios_list_head {
-	struct minios_list_head *next, *prev;
-};
-
-#define MINIOS_LIST_HEAD_INIT(name) { &(name), &(name) }
-
-#define MINIOS_LIST_HEAD(name) \
-	struct minios_list_head name = MINIOS_LIST_HEAD_INIT(name)
-
-#define MINIOS_INIT_LIST_HEAD(ptr) do { \
-	(ptr)->next = (ptr); (ptr)->prev = (ptr); \
-} while (0)
-
-#define minios_list_top(head, type, member)					  \
-({ 									  \
-	struct minios_list_head *_head = (head);				  \
-	minios_list_empty(_head) ? NULL : minios_list_entry(_head->next, type, member); \
-})
-
-/*
- * Insert a new entry between two known consecutive entries. 
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static __inline__ void __minios_list_add(struct minios_list_head * new,
-	struct minios_list_head * prev,
-	struct minios_list_head * next)
-{
-	next->prev = new;
-	new->next = next;
-	new->prev = prev;
-	prev->next = new;
-}
-
-/**
- * minios_list_add - add a new entry
- * @new: new entry to be added
- * @head: list head to add it after
- *
- * Insert a new entry after the specified head.
- * This is good for implementing stacks.
- */
-static __inline__ void minios_list_add(struct minios_list_head *new, struct minios_list_head *head)
-{
-	__minios_list_add(new, head, head->next);
-}
-
-/**
- * minios_list_add_tail - add a new entry
- * @new: new entry to be added
- * @head: list head to add it before
- *
- * Insert a new entry before the specified head.
- * This is useful for implementing queues.
- */
-static __inline__ void minios_list_add_tail(struct minios_list_head *new, struct minios_list_head *head)
-{
-	__minios_list_add(new, head->prev, head);
-}
-
-/*
- * Delete a list entry by making the prev/next entries
- * point to each other.
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static __inline__ void __minios_list_del(struct minios_list_head * prev,
-				  struct minios_list_head * next)
-{
-	next->prev = prev;
-	prev->next = next;
-}
-
-/**
- * minios_list_del - deletes entry from list.
- * @entry: the element to delete from the list.
- * Note: minios_list_empty on entry does not return true after this, the entry is in an undefined state.
- */
-static __inline__ void minios_list_del(struct minios_list_head *entry)
-{
-	__minios_list_del(entry->prev, entry->next);
-}
-
-/**
- * minios_list_del_init - deletes entry from list and reinitialize it.
- * @entry: the element to delete from the list.
- */
-static __inline__ void minios_list_del_init(struct minios_list_head *entry)
-{
-	__minios_list_del(entry->prev, entry->next);
-	MINIOS_INIT_LIST_HEAD(entry); 
-}
-
-/**
- * minios_list_empty - tests whether a list is empty
- * @head: the list to test.
- */
-static __inline__ int minios_list_empty(struct minios_list_head *head)
-{
-	return head->next == head;
-}
-
-/**
- * minios_list_splice - join two lists
- * @list: the new list to add.
- * @head: the place to add it in the first list.
- */
-static __inline__ void minios_list_splice(struct minios_list_head *list, struct minios_list_head *head)
-{
-	struct minios_list_head *first = list->next;
-
-	if (first != list) {
-		struct minios_list_head *last = list->prev;
-		struct minios_list_head *at = head->next;
-
-		first->prev = head;
-		head->next = first;
-
-		last->next = at;
-		at->prev = last;
-	}
-}
-
-/**
- * minios_list_entry - get the struct for this entry
- * @ptr:	the &struct minios_list_head pointer.
- * @type:	the type of the struct this is embedded in.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_entry(ptr, type, member) \
-	((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))
-
-/**
- * minios_list_for_each	-	iterate over a list
- * @pos:	the &struct minios_list_head to use as a loop counter.
- * @head:	the head for your list.
- */
-#define minios_list_for_each(pos, head) \
-	for (pos = (head)->next; pos != (head); pos = pos->next)
-        	
-/**
- * minios_list_for_each_safe	-	iterate over a list safe against removal of list entry
- * @pos:	the &struct minios_list_head to use as a loop counter.
- * @n:		another &struct minios_list_head to use as temporary storage
- * @head:	the head for your list.
- */
-#define minios_list_for_each_safe(pos, n, head) \
-	for (pos = (head)->next, n = pos->next; pos != (head); \
-		pos = n, n = pos->next)
-
-/**
- * minios_list_for_each_entry	-	iterate over list of given type
- * @pos:	the type * to use as a loop counter.
- * @head:	the head for your list.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_for_each_entry(pos, head, member)				\
-	for (pos = minios_list_entry((head)->next, typeof(*pos), member);	\
-	     &pos->member != (head); 					\
-	     pos = minios_list_entry(pos->member.next, typeof(*pos), member))
-
-/**
- * minios_list_for_each_entry_safe - iterate over list of given type safe against removal of list entry
- * @pos:	the type * to use as a loop counter.
- * @n:		another type * to use as temporary storage
- * @head:	the head for your list.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_for_each_entry_safe(pos, n, head, member)			\
-	for (pos = minios_list_entry((head)->next, typeof(*pos), member),	\
-		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
-	     &pos->member != (head); 					\
-	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
-
diff --git a/extras/mini-os/include/sched.h b/extras/mini-os/include/sched.h
--- a/extras/mini-os/include/sched.h
+++ b/extras/mini-os/include/sched.h
@@ -19,7 +19,7 @@ struct thread
 #else /* !defined(__ia64__) */
     thread_regs_t regs;
 #endif /* !defined(__ia64__) */
-    struct minios_list_head thread_list;
+    MINIOS_TAILQ_ENTRY(struct thread) thread_list;
     uint32_t flags;
     s_time_t wakeup_time;
 #ifdef HAVE_LIBC
diff --git a/extras/mini-os/include/semaphore.h b/extras/mini-os/include/semaphore.h
--- a/extras/mini-os/include/semaphore.h
+++ b/extras/mini-os/include/semaphore.h
@@ -21,7 +21,6 @@ struct semaphore
 struct rw_semaphore {
 	signed long		count;
 	spinlock_t		wait_lock;
-	struct minios_list_head	wait_list;
 	int			debug;
 };
 
diff --git a/extras/mini-os/include/wait.h b/extras/mini-os/include/wait.h
--- a/extras/mini-os/include/wait.h
+++ b/extras/mini-os/include/wait.h
@@ -5,47 +5,47 @@
 #include <mini-os/os.h>
 #include <mini-os/waittypes.h>
 
-#define DEFINE_WAIT(name)                               \
-struct wait_queue name = {                              \
-    .thread       = get_current(),                            \
-    .thread_list  = MINIOS_LIST_HEAD_INIT((name).thread_list), \
+#define DEFINE_WAIT(name)                          \
+struct wait_queue name = {                         \
+    .thread       = get_current(),                 \
+    .waiting      = 0,                             \
 }
 
 
 static inline void init_waitqueue_head(struct wait_queue_head *h)
 {
-  MINIOS_INIT_LIST_HEAD(&h->thread_list);
+    MINIOS_STAILQ_INIT(h);
 }
 
 static inline void init_waitqueue_entry(struct wait_queue *q, struct thread *thread)
 {
     q->thread = thread;
-    MINIOS_INIT_LIST_HEAD(&q->thread_list);
+    q->waiting = 0;
 }
 
-
 static inline void add_wait_queue(struct wait_queue_head *h, struct wait_queue *q)
 {
-    if (minios_list_empty(&q->thread_list))
-        minios_list_add(&q->thread_list, &h->thread_list);   
+    if (!q->waiting) {
+        MINIOS_STAILQ_INSERT_HEAD(h, q, thread_list);
+        q->waiting = 1;
+    }
 }
 
-static inline void remove_wait_queue(struct wait_queue *q)
+static inline void remove_wait_queue(struct wait_queue_head *h, struct wait_queue *q)
 {
-    minios_list_del(&q->thread_list);
+    if (q->waiting) {
+        MINIOS_STAILQ_REMOVE(h, q, struct wait_queue, thread_list);
+        q->waiting = 0;
+    }
 }
 
 static inline void wake_up(struct wait_queue_head *head)
 {
     unsigned long flags;
-    struct minios_list_head *tmp, *next;
+    struct wait_queue *curr, *tmp;
     local_irq_save(flags);
-    minios_list_for_each_safe(tmp, next, &head->thread_list)
-    {
-         struct wait_queue *curr;
-         curr = minios_list_entry(tmp, struct wait_queue, thread_list);
+    MINIOS_STAILQ_FOREACH_SAFE(curr, head, thread_list, tmp)
          wake(curr->thread);
-    }
     local_irq_restore(flags);
 }
 
@@ -57,11 +57,11 @@ static inline void wake_up(struct wait_q
     local_irq_restore(flags);   \
 } while (0)
 
-#define remove_waiter(w) do {   \
-    unsigned long flags;        \
-    local_irq_save(flags);      \
-    remove_wait_queue(&w);      \
-    local_irq_restore(flags);   \
+#define remove_waiter(w, wq) do {  \
+    unsigned long flags;           \
+    local_irq_save(flags);         \
+    remove_wait_queue(&wq, &w);    \
+    local_irq_restore(flags);      \
 } while (0)
 
 #define wait_event_deadline(wq, condition, deadline) do {       \
@@ -84,7 +84,7 @@ static inline void wake_up(struct wait_q
     local_irq_save(flags);                                      \
     /* need to wake up */                                       \
     wake(get_current());                                        \
-    remove_wait_queue(&__wait);                                 \
+    remove_wait_queue(&wq, &__wait);                            \
     local_irq_restore(flags);                                   \
 } while(0) 
 
@@ -93,3 +93,13 @@ static inline void wake_up(struct wait_q
 
 
 #endif /* __WAIT_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/include/waittypes.h b/extras/mini-os/include/waittypes.h
--- a/extras/mini-os/include/waittypes.h
+++ b/extras/mini-os/include/waittypes.h
@@ -6,21 +6,27 @@
 struct thread;
 struct wait_queue
 {
+    int waiting;
     struct thread *thread;
-    struct minios_list_head thread_list;
+    MINIOS_STAILQ_ENTRY(struct wait_queue) thread_list;
 };
 
-struct wait_queue_head
-{
-    /* TODO - lock required? */
-    struct minios_list_head thread_list;
-};
+/* TODO - lock required? */
+MINIOS_STAILQ_HEAD(wait_queue_head, struct wait_queue);
 
 #define DECLARE_WAIT_QUEUE_HEAD(name) \
-   struct wait_queue_head name =     \
-        { .thread_list = { &(name).thread_list, &(name).thread_list} }
+    struct wait_queue_head name = MINIOS_STAILQ_HEAD_INITIALIZER(name)
 
-#define __WAIT_QUEUE_HEAD_INITIALIZER(name) {                           \
-    .thread_list      = { &(name).thread_list, &(name).thread_list } }
+#define __WAIT_QUEUE_HEAD_INITIALIZER(name) MINIOS_STAILQ_HEAD_INITIALIZER(name)
 
 #endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -234,7 +234,7 @@ int read(int fd, void *buf, size_t nbyte
                     break;
                 schedule();
             }
-            remove_waiter(w);
+            remove_waiter(w, console_queue);
             return ret;
         }
 #ifdef HAVE_LWIP
@@ -705,12 +705,12 @@ int select(int nfds, fd_set *readfds, fd
     fd_set myread, mywrite, myexcept;
     struct thread *thread = get_current();
     s_time_t start = NOW(), stop;
-    DEFINE_WAIT(w1);
-    DEFINE_WAIT(w2);
-    DEFINE_WAIT(w3);
-    DEFINE_WAIT(w4);
-    DEFINE_WAIT(w5);
-    DEFINE_WAIT(w6);
+    DEFINE_WAIT(netfront_w);
+    DEFINE_WAIT(event_w);
+    DEFINE_WAIT(blkfront_w);
+    DEFINE_WAIT(xenbus_watch_w);
+    DEFINE_WAIT(kbdfront_w);
+    DEFINE_WAIT(console_w);
 
     assert(thread == main_thread);
 
@@ -727,12 +727,12 @@ int select(int nfds, fd_set *readfds, fd
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
-    add_waiter(w1, netfront_queue);
-    add_waiter(w2, event_queue);
-    add_waiter(w3, blkfront_queue);
-    add_waiter(w4, xenbus_watch_queue);
-    add_waiter(w5, kbdfront_queue);
-    add_waiter(w6, console_queue);
+    add_waiter(netfront_w, netfront_queue);
+    add_waiter(event_w, event_queue);
+    add_waiter(blkfront_w, blkfront_queue);
+    add_waiter(xenbus_watch_w, xenbus_watch_queue);
+    add_waiter(kbdfront_w, kbdfront_queue);
+    add_waiter(console_w, console_queue);
 
     if (readfds)
         myread = *readfds;
@@ -814,12 +814,12 @@ int select(int nfds, fd_set *readfds, fd
     ret = -1;
 
 out:
-    remove_waiter(w1);
-    remove_waiter(w2);
-    remove_waiter(w3);
-    remove_waiter(w4);
-    remove_waiter(w5);
-    remove_waiter(w6);
+    remove_waiter(netfront_w, netfront_queue);
+    remove_waiter(event_w, event_queue);
+    remove_waiter(blkfront_w, blkfront_queue);
+    remove_waiter(xenbus_watch_w, xenbus_watch_queue);
+    remove_waiter(kbdfront_w, kbdfront_queue);
+    remove_waiter(console_w, console_queue);
     return ret;
 }
 
diff --git a/extras/mini-os/lib/xmalloc.c b/extras/mini-os/lib/xmalloc.c
--- a/extras/mini-os/lib/xmalloc.c
+++ b/extras/mini-os/lib/xmalloc.c
@@ -44,16 +44,18 @@
 #include <mini-os/xmalloc.h>
 
 #ifndef HAVE_LIBC
-static MINIOS_LIST_HEAD(freelist);
 /* static spinlock_t freelist_lock = SPIN_LOCK_UNLOCKED; */
 
 struct xmalloc_hdr
 {
     /* Total including this hdr, unused padding and second hdr. */
     size_t size;
-    struct minios_list_head freelist;
+    MINIOS_TAILQ_ENTRY(struct xmalloc_hdr) freelist;
 } __cacheline_aligned;
 
+static MINIOS_TAILQ_HEAD(,struct xmalloc_hdr) freelist =
+	MINIOS_TAILQ_HEAD_INITIALIZER(freelist);
+
 /* Unused padding data between the two hdrs. */
 
 struct xmalloc_pad
@@ -82,7 +84,7 @@ static void maybe_split(struct xmalloc_h
         extra = (struct xmalloc_hdr *)((unsigned long)hdr + size);
         extra->size = leftover;
         /* spin_lock_irqsave(&freelist_lock, flags); */
-        minios_list_add(&extra->freelist, &freelist);
+        MINIOS_TAILQ_INSERT_HEAD(&freelist, extra, freelist);
         /* spin_unlock_irqrestore(&freelist_lock, flags); */
     }
     else
@@ -91,8 +93,6 @@ static void maybe_split(struct xmalloc_h
     }
 
     hdr->size = size;
-    /* Debugging aid. */
-    hdr->freelist.next = hdr->freelist.prev = NULL;
 }
 
 static struct xmalloc_hdr *xmalloc_new_page(size_t size)
@@ -128,8 +128,6 @@ static void *xmalloc_whole_pages(size_t 
         return NULL;
 
     hdr->size = (1UL << (pageorder + PAGE_SHIFT));
-    /* Debugging aid. */
-    hdr->freelist.next = hdr->freelist.prev = NULL;
 
     ret = (char*)hdr + hdr_size;
     pad = (struct xmalloc_pad *) ret - 1;
@@ -155,14 +153,14 @@ void *_xmalloc(size_t size, size_t align
 
     /* Search free list. */
     /* spin_lock_irqsave(&freelist_lock, flags); */
-    minios_list_for_each_entry_safe( i, tmp, &freelist, freelist )
+    MINIOS_TAILQ_FOREACH_SAFE(i, &freelist, freelist, tmp)
     {
         data_begin = align_up((uintptr_t)i + hdr_size, align);
 
         if ( data_begin + size > (uintptr_t)i + i->size )
             continue;
 
-        minios_list_del(&i->freelist);
+        MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
         /* spin_unlock_irqrestore(&freelist_lock, flags); */
 
         uintptr_t size_before = (data_begin - hdr_size) - (uintptr_t)i;
@@ -173,7 +171,7 @@ void *_xmalloc(size_t size, size_t align
             new_i->size = i->size - size_before;
             i->size = size_before;
             /* spin_lock_irqsave(&freelist_lock, flags); */
-            minios_list_add(&i->freelist, &freelist);
+            MINIOS_TAILQ_INSERT_HEAD(&freelist, i, freelist);
             /* spin_unlock_irqrestore(&freelist_lock, flags); */
             i = new_i;
         }
@@ -224,16 +222,9 @@ void xfree(const void *p)
         *(int*)0=0;
     }
 
-    /* Not previously freed. */
-    if(hdr->freelist.next || hdr->freelist.prev)
-    {
-        printk("Should not be previously freed\n");
-        *(int*)0=0;
-    }
-
     /* Merge with other free block, or put in list. */
     /* spin_lock_irqsave(&freelist_lock, flags); */
-    minios_list_for_each_entry_safe( i, tmp, &freelist, freelist )
+    MINIOS_TAILQ_FOREACH_SAFE(i, &freelist, freelist, tmp)
     {
         unsigned long _i   = (unsigned long)i;
         unsigned long _hdr = (unsigned long)hdr;
@@ -245,7 +236,7 @@ void xfree(const void *p)
         /* We follow this block?  Swallow it. */
         if ( (_i + i->size) == _hdr )
         {
-            minios_list_del(&i->freelist);
+            MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
             i->size += hdr->size;
             hdr = i;
         }
@@ -253,7 +244,7 @@ void xfree(const void *p)
         /* We precede this block? Swallow it. */
         if ( (_hdr + hdr->size) == _i )
         {
-            minios_list_del(&i->freelist);
+            MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
             hdr->size += i->size;
         }
     }
@@ -270,7 +261,7 @@ void xfree(const void *p)
     }
     else
     {
-        minios_list_add(&hdr->freelist, &freelist);
+        MINIOS_TAILQ_INSERT_HEAD(&freelist, hdr, freelist);
     }
 
     /* spin_unlock_irqrestore(&freelist_lock, flags); */
@@ -306,3 +297,13 @@ void *_realloc(void *ptr, size_t size)
     return new;
 }
 #endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/sched.c b/extras/mini-os/sched.c
--- a/extras/mini-os/sched.c
+++ b/extras/mini-os/sched.c
@@ -54,19 +54,20 @@
 #define DEBUG(_f, _a...)    ((void)0)
 #endif
 
+MINIOS_TAILQ_HEAD(thread_list, struct thread);
+
 struct thread *idle_thread = NULL;
-MINIOS_LIST_HEAD(exited_threads);
+static struct thread_list exited_threads = MINIOS_TAILQ_HEAD_INITIALIZER(exited_threads);
+static struct thread_list thread_list = MINIOS_TAILQ_HEAD_INITIALIZER(thread_list);
 static int threads_started;
 
 struct thread *main_thread;
 
 void inline print_runqueue(void)
 {
-    struct minios_list_head *it;
     struct thread *th;
-    minios_list_for_each(it, &idle_thread->thread_list)
+    MINIOS_TAILQ_FOREACH(th, &thread_list, thread_list)
     {
-        th = minios_list_entry(it, struct thread, thread_list);
         printk("   Thread \"%s\", runnable=%d\n", th->name, is_runnable(th));
     }
     printk("\n");
@@ -74,8 +75,7 @@ void inline print_runqueue(void)
 
 void schedule(void)
 {
-    struct thread *prev, *next, *thread;
-    struct minios_list_head *iterator, *next_iterator;
+    struct thread *prev, *next, *thread, *tmp;
     unsigned long flags;
 
     prev = current;
@@ -96,10 +96,9 @@ void schedule(void)
            time when the next timeout expires, else use 10 seconds. */
         s_time_t now = NOW();
         s_time_t min_wakeup_time = now + SECONDS(10);
-        next = NULL;   
-        minios_list_for_each_safe(iterator, next_iterator, &idle_thread->thread_list)
+        next = NULL;
+        MINIOS_TAILQ_FOREACH_SAFE(thread, &thread_list, thread_list, tmp)
         {
-            thread = minios_list_entry(iterator, struct thread, thread_list);
             if (!is_runnable(thread) && thread->wakeup_time != 0LL)
             {
                 if (thread->wakeup_time <= now)
@@ -111,8 +110,8 @@ void schedule(void)
             {
                 next = thread;
                 /* Put this thread on the end of the list */
-                minios_list_del(&thread->thread_list);
-                minios_list_add_tail(&thread->thread_list, &idle_thread->thread_list);
+                MINIOS_TAILQ_REMOVE(&thread_list, thread, thread_list);
+                MINIOS_TAILQ_INSERT_TAIL(&thread_list, thread, thread_list);
                 break;
             }
         }
@@ -128,12 +127,11 @@ void schedule(void)
        inturrupted at the return instruction. And therefore at safe point. */
     if(prev != next) switch_threads(prev, next);
 
-    minios_list_for_each_safe(iterator, next_iterator, &exited_threads)
+    MINIOS_TAILQ_FOREACH_SAFE(thread, &exited_threads, thread_list, tmp)
     {
-        thread = minios_list_entry(iterator, struct thread, thread_list);
         if(thread != prev)
         {
-            minios_list_del(&thread->thread_list);
+            MINIOS_TAILQ_REMOVE(&exited_threads, thread, thread_list);
             free_pages(thread->stack, STACK_SIZE_PAGE_ORDER);
             xfree(thread);
         }
@@ -154,13 +152,7 @@ struct thread* create_thread(char *name,
 #endif
     set_runnable(thread);
     local_irq_save(flags);
-    if(idle_thread != NULL) {
-        minios_list_add_tail(&thread->thread_list, &idle_thread->thread_list); 
-    } else if(function != idle_thread_fn)
-    {
-        printk("BUG: Not allowed to create thread before initialising scheduler.\n");
-        BUG();
-    }
+    MINIOS_TAILQ_INSERT_TAIL(&thread_list, thread, thread_list);
     local_irq_restore(flags);
     return thread;
 }
@@ -208,10 +200,10 @@ void exit_thread(void)
     printk("Thread \"%s\" exited.\n", thread->name);
     local_irq_save(flags);
     /* Remove from the thread list */
-    minios_list_del(&thread->thread_list);
+    MINIOS_TAILQ_REMOVE(&thread_list, thread, thread_list);
     clear_runnable(thread);
     /* Put onto exited list */
-    minios_list_add(&thread->thread_list, &exited_threads);
+    MINIOS_TAILQ_INSERT_HEAD(&exited_threads, thread, thread_list);
     local_irq_restore(flags);
     /* Schedule will free the resources */
     while(1)
@@ -296,6 +288,14 @@ void init_sched(void)
     _REENT_INIT_PTR((&callback_reent))
 #endif
     idle_thread = create_thread("Idle", idle_thread_fn, NULL);
-    MINIOS_INIT_LIST_HEAD(&idle_thread->thread_list);
 }
 
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
--- a/extras/mini-os/xenbus/xenbus.c
+++ b/extras/mini-os/xenbus/xenbus.c
@@ -85,7 +85,7 @@ char **xenbus_wait_for_watch_return(xenb
         add_waiter(w, xenbus_watch_queue);
         schedule();
     }
-    remove_waiter(w);
+    remove_waiter(w, xenbus_watch_queue);
     *queue = event->next;
     return &event->path;
 }
@@ -441,7 +441,7 @@ xenbus_msg_reply(int type,
     xb_write(type, id, trans, io, nr_reqs);
 
     schedule();
-    remove_waiter(w);
+    remove_waiter(w, req_info[id].waitq);
     wake(current);
 
     rep = req_info[id].reply;
diff --git a/tools/libxl/external/README b/tools/include/xen-external/README
rename from tools/libxl/external/README
rename to tools/include/xen-external/README
--- a/tools/libxl/external/README
+++ b/tools/include/xen-external/README
@@ -1,5 +1,5 @@
-WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
------------------------------------------------------------------------
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY
+----------------------------------------------
 
 These files were obtained elsewhere and should only be updated by
 copying new versions from the source location, as documented below:
@@ -12,3 +12,13 @@ bsd-queue.3
     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
+
+Exceptions:
+
+README
+
+  This file
+
+bsd-sys-queue-h-seddery
+
+  Script to transform the above into a new namespace.
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/include/xen-external/bsd-COPYRIGHT
rename from tools/libxl/external/bsd-COPYRIGHT
rename to tools/include/xen-external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/include/xen-external/bsd-queue.3
rename from tools/libxl/external/bsd-queue.3
rename to tools/include/xen-external/bsd-queue.3
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/include/xen-external/bsd-sys-queue-h-seddery
rename from tools/libxl/bsd-sys-queue-h-seddery
rename to tools/include/xen-external/bsd-sys-queue-h-seddery
--- a/tools/libxl/bsd-sys-queue-h-seddery
+++ b/tools/include/xen-external/bsd-sys-queue-h-seddery
@@ -68,3 +68,5 @@ s/\b(
 s/\b struct \s+ type \b/type/xg;
 
 s,^\#include.*sys/cdefs.*,/* $& */,xg;
+
+s/\b( NULL )/0/xg;
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/include/xen-external/bsd-sys-queue.h
rename from tools/libxl/external/bsd-sys-queue.h
rename to tools/include/xen-external/bsd-sys-queue.h
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -93,8 +93,8 @@ _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
+_libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
+	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
 libxl_paths.c: _libxl_paths.h



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 13:10:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqlZ9-0003Hp-Kh; Fri, 27 Jan 2012 13:10: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 1RqlZ7-0003HZ-W6
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:10:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327669799!12781157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2938 invoked from network); 27 Jan 2012 13:10:00 -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;
	27 Jan 2012 13:10:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10328083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:09: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, 27 Jan 2012 13:10:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 13:09:59 +0000
In-Reply-To: <1327669569.26983.178.camel@zakaz.uk.xensource.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1327669569.26983.178.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327669799.26983.179.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 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 13:06 +0000, Ian Campbell wrote:
> 
> As well as the obvious ABI changes there are a few API updates
> associated with the change:
> 
>   - struct rw_semaphore.wait_list is unused
>   - remove_waiter needs to take the wait_queue_head
> 
> The latter requires a qemu update which I will post separately. Please
> apply first and update QEMU_TAG as appropriate. 

8<----------------------------------------------------------------------

>From ab35cca68024f077ca5dbd8d099605e2df830b22 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 27 Jan 2012 12:54:57 +0000
Subject: [PATCH] block-vbd: update to new mini-os wait queue API

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 block-vbd.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/block-vbd.c b/block-vbd.c
index 56794f6..71f1731 100644
--- a/block-vbd.c
+++ b/block-vbd.c
@@ -144,7 +144,7 @@ void qemu_aio_wait(void)
 	    break;
 	schedule();
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
 }
 
 static void vbd_do_aio(struct blkfront_aiocb *aiocbp, int ret) {
-- 
1.7.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 Jan 27 13:10:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:10:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqlZ9-0003Hp-Kh; Fri, 27 Jan 2012 13:10: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 1RqlZ7-0003HZ-W6
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:10:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327669799!12781157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2938 invoked from network); 27 Jan 2012 13:10:00 -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;
	27 Jan 2012 13:10:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10328083"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:09: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, 27 Jan 2012 13:10:00 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 13:09:59 +0000
In-Reply-To: <1327669569.26983.178.camel@zakaz.uk.xensource.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1327669569.26983.178.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327669799.26983.179.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 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 13:06 +0000, Ian Campbell wrote:
> 
> As well as the obvious ABI changes there are a few API updates
> associated with the change:
> 
>   - struct rw_semaphore.wait_list is unused
>   - remove_waiter needs to take the wait_queue_head
> 
> The latter requires a qemu update which I will post separately. Please
> apply first and update QEMU_TAG as appropriate. 

8<----------------------------------------------------------------------

>From ab35cca68024f077ca5dbd8d099605e2df830b22 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Fri, 27 Jan 2012 12:54:57 +0000
Subject: [PATCH] block-vbd: update to new mini-os wait queue API

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 block-vbd.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/block-vbd.c b/block-vbd.c
index 56794f6..71f1731 100644
--- a/block-vbd.c
+++ b/block-vbd.c
@@ -144,7 +144,7 @@ void qemu_aio_wait(void)
 	    break;
 	schedule();
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
 }
 
 static void vbd_do_aio(struct blkfront_aiocb *aiocbp, int ret) {
-- 
1.7.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 Jan 27 13:12:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:12:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqlbU-0003RY-6D; Fri, 27 Jan 2012 13:12:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqlbS-0003R9-R9
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:12:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327669943!8962871!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30718 invoked from network); 27 Jan 2012 13:12:24 -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;
	27 Jan 2012 13:12:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320642000"; d="scan'208";a="179357860"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 08:12: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; Fri, 27 Jan 2012 08:12:22 -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
	q0RDCLHs012869;	Fri, 27 Jan 2012 05:12:21 -0800
MIME-Version: 1.0
X-Mercurial-Node: f16bb1c3117a12acb1ed057b2941c39e68054fa1
Message-ID: <f16bb1c3117a12acb1ed.1327669940@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 27 Jan 2012 13:12:20 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, stefano.stabellini@citrix.com
Subject: [Xen-devel] [PATCH] libxl: fix upstream qemu binary name to what we
 actually install
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327669937 0
# Node ID f16bb1c3117a12acb1ed057b2941c39e68054fa1
# Parent  72f001fd2bc43d18a63c1db6202d830b42b53d95
libxl: fix upstream qemu binary name to what we actually install

Binary is always qemu-system-i386 even for a 64 bit build.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 72f001fd2bc4 -r f16bb1c3117a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Jan 27 13:04:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Jan 27 13:12:17 2012 +0000
@@ -50,7 +50,7 @@ const char *libxl__domain_device_model(l
             dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());
+            dm = libxl__abs_path(gc, "qemu-system-i386", libxl_libexec_path());
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 13:12:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:12:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqlbU-0003RY-6D; Fri, 27 Jan 2012 13:12:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqlbS-0003R9-R9
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:12:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327669943!8962871!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30718 invoked from network); 27 Jan 2012 13:12:24 -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;
	27 Jan 2012 13:12:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320642000"; d="scan'208";a="179357860"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 08:12: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; Fri, 27 Jan 2012 08:12:22 -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
	q0RDCLHs012869;	Fri, 27 Jan 2012 05:12:21 -0800
MIME-Version: 1.0
X-Mercurial-Node: f16bb1c3117a12acb1ed057b2941c39e68054fa1
Message-ID: <f16bb1c3117a12acb1ed.1327669940@cosworth.uk.xensource.com>
User-Agent: Mercurial-patchbomb/1.6.4
Date: Fri, 27 Jan 2012 13:12:20 +0000
From: Ian Campbell <ian.campbell@citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, stefano.stabellini@citrix.com
Subject: [Xen-devel] [PATCH] libxl: fix upstream qemu binary name to what we
 actually install
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327669937 0
# Node ID f16bb1c3117a12acb1ed057b2941c39e68054fa1
# Parent  72f001fd2bc43d18a63c1db6202d830b42b53d95
libxl: fix upstream qemu binary name to what we actually install

Binary is always qemu-system-i386 even for a 64 bit build.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r 72f001fd2bc4 -r f16bb1c3117a tools/libxl/libxl_dm.c
--- a/tools/libxl/libxl_dm.c	Fri Jan 27 13:04:52 2012 +0000
+++ b/tools/libxl/libxl_dm.c	Fri Jan 27 13:12:17 2012 +0000
@@ -50,7 +50,7 @@ const char *libxl__domain_device_model(l
             dm = libxl__abs_path(gc, "qemu-dm", libxl_libexec_path());
             break;
         case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-            dm = libxl__abs_path(gc, "qemu", libxl_libexec_path());
+            dm = libxl__abs_path(gc, "qemu-system-i386", libxl_libexec_path());
             break;
         default:
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 13:32:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqlue-0003uu-2R; Fri, 27 Jan 2012 13:32:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1Rqluc-0003up-Ok
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:32:19 +0000
Received: from [85.158.138.51:41713] by server-10.bemta-3.messagelabs.com id
	C0/BF-20948-267A22F4; Fri, 27 Jan 2012 13:32:18 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327671135!10762118!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8416 invoked from network); 27 Jan 2012 13:32:17 -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;
	27 Jan 2012 13:32:17 -0000
Received: by iaeh11 with SMTP id h11so12442848iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 05:32:15 -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=0m74yoOahEmw2TuKbpXxmBtGFOI9YhDTGiAHlkrpJoo=;
	b=iKUz9ucjuVOOvXOM+fS05LaVgPOlBRYJIbtZYp6aXjLa/Mr4wcQ2N9pGokmKefCHrX
	cdA2kGla0yJ+8RLgrN9aH4WLMMYBI/v6WVmanf3w1J2W2mvMdVmN5NE9J3Z4i3s+Uy1a
	EK3Oxh0qG2iMEjSElD2UMbMYhOFIfzqVMwtE4=
Received: by 10.50.180.233 with SMTP id dr9mr7009117igc.11.1327671135271; Fri,
	27 Jan 2012 05:32:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.36.35 with HTTP; Fri, 27 Jan 2012 05:31:55 -0800 (PST)
From: William Dauchy <wdauchy@gmail.com>
Date: Fri, 27 Jan 2012 14:31:55 +0100
Message-ID: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I have some troubles loading the IOATDMA module under xen4.1.2 and a
linux dom0 3.3

CONFIG_INTEL_IOATDMA=m
CONFIG_IGB=y

It was working with linux 3.1.5. The regression seems to be since
linux 3.2. I tried to do a `git bisect` but I'm facing other
regressions which make the debug harder.

Here is the call trace when loading the module in dom0:

dca service started, version 1.12.1
ioatdma: Intel(R) QuickData Technology Driver 4.00
ioatdma 0000:00:16.0: enabling device (0000 -> 0002)
xen: registering gsi 43 triggering 0 polarity 1
xen: --> pirq=43 -> irq=43 (gsi=43)
------------[ cut here ]------------
kernel BUG at /linux-3.3/drivers/dma/ioat/dma_v2.c:163!
invalid opcode: 0000 [#1] SMP
Modules linked in: ioatdma(+) dca ebt_ip6 ebt_dnat ebt_ip
ebtable_broute ebt_snat ebtable_nat ebtable_filter ebtables bridge stp
llc ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod
button

Pid: 0, comm: swapper/0 Not tainted 3.3.0-dom0-6357-i386+ #24 Dell
  C6100           /0D61XP
EIP: 0061:[<f512c524>] EFLAGS: 00010246 CPU: 0
EIP is at __cleanup+0x154/0x160 [ioatdma]
EAX: 00000000 EBX: e9dd44c0 ECX: 769ed7af EDX: 00000002
ESI: e90fe48c EDI: 00000002 EBP: eb40bf9c ESP: eb40bf7c
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
Process swapper/0 (pid: 0, ti=eb40a000 task=c1401ee0 task.ti=c13fc000)
Stack:
 eadc8040 00010002 18ae4040 00000002 0000bf9c e90fe48c e90fe4bc 00000006
 eb40bfb0 f512c770 18ae4040 00000000 e90fe4f8 eb40bfc0 c10347cb 00000001
 00000018 eb40bff8 c10350ab 00000000 00000000 00000000 00000000 00000000
Call Trace:
 [<f512c770>] ioat2_cleanup_event+0x30/0x50 [ioatdma]
 [<c10347cb>] tasklet_action+0x9b/0xb0
 [<c10350ab>] __do_softirq+0x7b/0x110
 [<c1035030>] ? irq_enter+0x70/0x70
 <IRQ>
 [<c1034e7e>] ? irq_exit+0x6e/0xa0
 [<c11bde70>] ? xen_evtchn_do_upcall+0x20/0x30
 [<c1322907>] ? xen_do_upcall+0x7/0xc
 [<c10013a7>] ? hypercall_page+0x3a7/0x1000
 [<c1006172>] ? xen_safe_halt+0x12/0x20
 [<c1010582>] ? default_idle+0x32/0x60
 [<c1008596>] ? cpu_idle+0x66/0xa0
 [<c130bd58>] ? rest_init+0x58/0x60
 [<c14237d2>] ? start_kernel+0x2e4/0x2ea
 [<c142331d>] ? kernel_init+0x11b/0x11b
 [<c14230ba>] ? i386_start_kernel+0xa9/0xb0
 [<c1426abb>] ? xen_start_kernel+0x5a2/0x5aa
Code: 00 e8 41 7a f0 cb 8b 15 40 1a 40 c1 8d 14 10 8d 46 3c e8 60 ea
f0 cb 83 c4 14 5b 5e 5f c9 c3 31 d2 89 df 31 c0 eb a2 84 c0 75 b5 <0f>
0b eb fe 90 8d b4 26 00 00 00 00 55 89 e5 57 56 53 89 c3 83
EIP: [<f512c524>] __cleanup+0x154/0x160 [ioatdma] SS:ESP 0069:eb40bf7c
---[ end trace 902e93593e49fa50 ]---
Kernel panic - not syncing: Fatal exception in interrupt


Does anybody have any clue?

Regards,
-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 13:32:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:32:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqlue-0003uu-2R; Fri, 27 Jan 2012 13:32:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1Rqluc-0003up-Ok
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:32:19 +0000
Received: from [85.158.138.51:41713] by server-10.bemta-3.messagelabs.com id
	C0/BF-20948-267A22F4; Fri, 27 Jan 2012 13:32:18 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327671135!10762118!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
	ML_RADAR_SPEW_LINKS_14,RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8416 invoked from network); 27 Jan 2012 13:32:17 -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;
	27 Jan 2012 13:32:17 -0000
Received: by iaeh11 with SMTP id h11so12442848iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 05:32:15 -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=0m74yoOahEmw2TuKbpXxmBtGFOI9YhDTGiAHlkrpJoo=;
	b=iKUz9ucjuVOOvXOM+fS05LaVgPOlBRYJIbtZYp6aXjLa/Mr4wcQ2N9pGokmKefCHrX
	cdA2kGla0yJ+8RLgrN9aH4WLMMYBI/v6WVmanf3w1J2W2mvMdVmN5NE9J3Z4i3s+Uy1a
	EK3Oxh0qG2iMEjSElD2UMbMYhOFIfzqVMwtE4=
Received: by 10.50.180.233 with SMTP id dr9mr7009117igc.11.1327671135271; Fri,
	27 Jan 2012 05:32:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.36.35 with HTTP; Fri, 27 Jan 2012 05:31:55 -0800 (PST)
From: William Dauchy <wdauchy@gmail.com>
Date: Fri, 27 Jan 2012 14:31:55 +0100
Message-ID: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hello,

I have some troubles loading the IOATDMA module under xen4.1.2 and a
linux dom0 3.3

CONFIG_INTEL_IOATDMA=m
CONFIG_IGB=y

It was working with linux 3.1.5. The regression seems to be since
linux 3.2. I tried to do a `git bisect` but I'm facing other
regressions which make the debug harder.

Here is the call trace when loading the module in dom0:

dca service started, version 1.12.1
ioatdma: Intel(R) QuickData Technology Driver 4.00
ioatdma 0000:00:16.0: enabling device (0000 -> 0002)
xen: registering gsi 43 triggering 0 polarity 1
xen: --> pirq=43 -> irq=43 (gsi=43)
------------[ cut here ]------------
kernel BUG at /linux-3.3/drivers/dma/ioat/dma_v2.c:163!
invalid opcode: 0000 [#1] SMP
Modules linked in: ioatdma(+) dca ebt_ip6 ebt_dnat ebt_ip
ebtable_broute ebt_snat ebtable_nat ebtable_filter ebtables bridge stp
llc ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod
button

Pid: 0, comm: swapper/0 Not tainted 3.3.0-dom0-6357-i386+ #24 Dell
  C6100           /0D61XP
EIP: 0061:[<f512c524>] EFLAGS: 00010246 CPU: 0
EIP is at __cleanup+0x154/0x160 [ioatdma]
EAX: 00000000 EBX: e9dd44c0 ECX: 769ed7af EDX: 00000002
ESI: e90fe48c EDI: 00000002 EBP: eb40bf9c ESP: eb40bf7c
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
Process swapper/0 (pid: 0, ti=eb40a000 task=c1401ee0 task.ti=c13fc000)
Stack:
 eadc8040 00010002 18ae4040 00000002 0000bf9c e90fe48c e90fe4bc 00000006
 eb40bfb0 f512c770 18ae4040 00000000 e90fe4f8 eb40bfc0 c10347cb 00000001
 00000018 eb40bff8 c10350ab 00000000 00000000 00000000 00000000 00000000
Call Trace:
 [<f512c770>] ioat2_cleanup_event+0x30/0x50 [ioatdma]
 [<c10347cb>] tasklet_action+0x9b/0xb0
 [<c10350ab>] __do_softirq+0x7b/0x110
 [<c1035030>] ? irq_enter+0x70/0x70
 <IRQ>
 [<c1034e7e>] ? irq_exit+0x6e/0xa0
 [<c11bde70>] ? xen_evtchn_do_upcall+0x20/0x30
 [<c1322907>] ? xen_do_upcall+0x7/0xc
 [<c10013a7>] ? hypercall_page+0x3a7/0x1000
 [<c1006172>] ? xen_safe_halt+0x12/0x20
 [<c1010582>] ? default_idle+0x32/0x60
 [<c1008596>] ? cpu_idle+0x66/0xa0
 [<c130bd58>] ? rest_init+0x58/0x60
 [<c14237d2>] ? start_kernel+0x2e4/0x2ea
 [<c142331d>] ? kernel_init+0x11b/0x11b
 [<c14230ba>] ? i386_start_kernel+0xa9/0xb0
 [<c1426abb>] ? xen_start_kernel+0x5a2/0x5aa
Code: 00 e8 41 7a f0 cb 8b 15 40 1a 40 c1 8d 14 10 8d 46 3c e8 60 ea
f0 cb 83 c4 14 5b 5e 5f c9 c3 31 d2 89 df 31 c0 eb a2 84 c0 75 b5 <0f>
0b eb fe 90 8d b4 26 00 00 00 00 55 89 e5 57 56 53 89 c3 83
EIP: [<f512c524>] __cleanup+0x154/0x160 [ioatdma] SS:ESP 0069:eb40bf7c
---[ end trace 902e93593e49fa50 ]---
Kernel panic - not syncing: Fatal exception in interrupt


Does anybody have any clue?

Regards,
-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 13:54:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqmFI-0004JG-Vv; Fri, 27 Jan 2012 13:53:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqmFH-0004JB-Sx
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:53:40 +0000
Received: from [85.158.138.51:16252] by server-1.bemta-3.messagelabs.com id
	82/FF-09565-26CA22F4; Fri, 27 Jan 2012 13:53:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327672416!10943318!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA5NTA4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26586 invoked from network); 27 Jan 2012 13:53:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 13:53:38 -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
	q0RDrVfC000362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 13:53:32 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
	q0RDrUPb028958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 13:53:30 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
	q0RDrTfv006609; Fri, 27 Jan 2012 07:53:29 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 05:53:29 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CFA0E4019E; Fri, 27 Jan 2012 08:51:05 -0500 (EST)
Date: Fri, 27 Jan 2012 08:51:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127135105.GA16187@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
	<1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120126185155.GA24768@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201271058090.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201271058090.3196@kaball-desktop>
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.0A090206.4F22AC5C.00DD,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 11:03:41AM +0000, Stefano Stabellini wrote:
> On Thu, 26 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> > > The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> > > be EOI'd without having to issue an hypercall every time.
> > > We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> > > succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  drivers/xen/events.c            |   17 ++++++++++++++++-
> > >  include/xen/interface/physdev.h |   12 ++++++++++++
> > >  2 files changed, 28 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 6e075cd..7fdc738 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -37,6 +37,7 @@
> > >  #include <asm/idle.h>
> > >  #include <asm/io_apic.h>
> > >  #include <asm/sync_bitops.h>
> > > +#include <asm/xen/page.h>
> > >  #include <asm/xen/pci.h>
> > >  #include <asm/xen/hypercall.h>
> > >  #include <asm/xen/hypervisor.h>
> > > @@ -108,6 +109,7 @@ struct irq_info {
> > >  #define PIRQ_SHAREABLE	(1 << 1)
> > >  
> > >  static int *evtchn_to_irq;
> > > +static unsigned long *pirq_eoi_map;
> > >  
> > >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > >  		      cpu_evtchn_mask);
> > > @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
> > >  
> > >  	BUG_ON(info->type != IRQT_PIRQ);
> > >  
> > > +	if (pirq_eoi_map != NULL)
> > > +		return test_bit(irq, pirq_eoi_map);
> > > +
> > 
> > How about just having a different function called
> > pirq_needs_eoi_v2 which will just do
> > 
> >  return test_bit(irq, pirq_eoi_map)?
> > 
> > And then set the pirq_needs_eoi_v2 in the function table?
> 
> Ok, but the name "pirq_needs_eoi_v2" is misleading because
> PHYSDEVOP_pirq_eoi_gmfn only works for PV guests at the moment.
> How about I call the new function "pirq_check_eoi_map" and rename the old
> one "pirq_needs_eoi_flag" and the generic name of the function pointer
> would remain "pirq_needs_eoi"?

Even better!
> 
> 
> > >  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> > >  }
> > >  
> > > @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
> > >  
> > >  void __init xen_init_IRQ(void)
> > >  {
> > > -	int i;
> > > +	int i, rc;
> > >  
> > >  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
> > >  				    GFP_KERNEL);
> > > @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
> > >  		 * __acpi_register_gsi can point at the right function */
> > >  		pci_xen_hvm_init();
> > >  	} else {
> > > +		struct physdev_pirq_eoi_gmfn eoi_gmfn;
> > > +
> > >  		irq_ctx_init(smp_processor_id());
> > >  		if (xen_initial_domain())
> > >  			pci_xen_initial_domain();
> > > +
> > > +		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> > > +		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> > > +		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);
> > 
> > 
> > Don't we want the v2 version?
> > 
> > > +		if (rc != 0) {
> > > +			free_page((unsigned long) pirq_eoi_map);
> > > +			pirq_eoi_map = NULL;
> > > +		}
> > >  	}
> > >  }
> > > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > > index c1080d9..132c61f 100644
> > > --- a/include/xen/interface/physdev.h
> > > +++ b/include/xen/interface/physdev.h
> > > @@ -39,6 +39,18 @@ struct physdev_eoi {
> > >  };
> > >  
> > >  /*
> > > + * Register a shared page for the hypervisor to indicate whether the
> > > + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> > > + * array indexed by Xen's PIRQ value.
> > > + */
> > > +#define PHYSDEVOP_pirq_eoi_gmfn      28
> > 
> > Ah, the number is right, but the name is the generic one.
> > 
> > We should really mention that this is different from v1 or just
> > 
> > #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> > and use that in the code?
> 
> Maybe we should:
> 
> #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> 
> in order not to hide the fact that there are two versions of this
> hypercall.
> Then we do:
> 
> /* we use the second version of the hypercall */
> #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
> 
> 
> This way we just have PHYSDEVOP_pirq_eoi_gmfn in the code but we don't
> hide the version with are using.

That could work. However using a v2 everywhere will clearly show to
to somebody why it won't work with say Xen 4.0 (if they are trying to run it
under it and wonder why that hypercall did not work). Which reminds me, once the
hypervisor patch is in, we should definitly mention that in this git commit.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 13:54:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 13:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqmFI-0004JG-Vv; Fri, 27 Jan 2012 13:53:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqmFH-0004JB-Sx
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 13:53:40 +0000
Received: from [85.158.138.51:16252] by server-1.bemta-3.messagelabs.com id
	82/FF-09565-26CA22F4; Fri, 27 Jan 2012 13:53:38 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327672416!10943318!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA5NTA4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26586 invoked from network); 27 Jan 2012 13:53:38 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 13:53:38 -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
	q0RDrVfC000362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 13:53:32 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
	q0RDrUPb028958
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 13:53:30 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
	q0RDrTfv006609; Fri, 27 Jan 2012 07:53:29 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 05:53:29 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id CFA0E4019E; Fri, 27 Jan 2012 08:51:05 -0500 (EST)
Date: Fri, 27 Jan 2012 08:51:05 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127135105.GA16187@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
	<1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120126185155.GA24768@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201271058090.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201271058090.3196@kaball-desktop>
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.0A090206.4F22AC5C.00DD,ss=1,re=0.000,fgs=0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>,
	"JBeulich@suse.com" <JBeulich@suse.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 11:03:41AM +0000, Stefano Stabellini wrote:
> On Thu, 26 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> > > The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> > > be EOI'd without having to issue an hypercall every time.
> > > We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> > > succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> > > 
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  drivers/xen/events.c            |   17 ++++++++++++++++-
> > >  include/xen/interface/physdev.h |   12 ++++++++++++
> > >  2 files changed, 28 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 6e075cd..7fdc738 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -37,6 +37,7 @@
> > >  #include <asm/idle.h>
> > >  #include <asm/io_apic.h>
> > >  #include <asm/sync_bitops.h>
> > > +#include <asm/xen/page.h>
> > >  #include <asm/xen/pci.h>
> > >  #include <asm/xen/hypercall.h>
> > >  #include <asm/xen/hypervisor.h>
> > > @@ -108,6 +109,7 @@ struct irq_info {
> > >  #define PIRQ_SHAREABLE	(1 << 1)
> > >  
> > >  static int *evtchn_to_irq;
> > > +static unsigned long *pirq_eoi_map;
> > >  
> > >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > >  		      cpu_evtchn_mask);
> > > @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
> > >  
> > >  	BUG_ON(info->type != IRQT_PIRQ);
> > >  
> > > +	if (pirq_eoi_map != NULL)
> > > +		return test_bit(irq, pirq_eoi_map);
> > > +
> > 
> > How about just having a different function called
> > pirq_needs_eoi_v2 which will just do
> > 
> >  return test_bit(irq, pirq_eoi_map)?
> > 
> > And then set the pirq_needs_eoi_v2 in the function table?
> 
> Ok, but the name "pirq_needs_eoi_v2" is misleading because
> PHYSDEVOP_pirq_eoi_gmfn only works for PV guests at the moment.
> How about I call the new function "pirq_check_eoi_map" and rename the old
> one "pirq_needs_eoi_flag" and the generic name of the function pointer
> would remain "pirq_needs_eoi"?

Even better!
> 
> 
> > >  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> > >  }
> > >  
> > > @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
> > >  
> > >  void __init xen_init_IRQ(void)
> > >  {
> > > -	int i;
> > > +	int i, rc;
> > >  
> > >  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
> > >  				    GFP_KERNEL);
> > > @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
> > >  		 * __acpi_register_gsi can point at the right function */
> > >  		pci_xen_hvm_init();
> > >  	} else {
> > > +		struct physdev_pirq_eoi_gmfn eoi_gmfn;
> > > +
> > >  		irq_ctx_init(smp_processor_id());
> > >  		if (xen_initial_domain())
> > >  			pci_xen_initial_domain();
> > > +
> > > +		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> > > +		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> > > +		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);
> > 
> > 
> > Don't we want the v2 version?
> > 
> > > +		if (rc != 0) {
> > > +			free_page((unsigned long) pirq_eoi_map);
> > > +			pirq_eoi_map = NULL;
> > > +		}
> > >  	}
> > >  }
> > > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > > index c1080d9..132c61f 100644
> > > --- a/include/xen/interface/physdev.h
> > > +++ b/include/xen/interface/physdev.h
> > > @@ -39,6 +39,18 @@ struct physdev_eoi {
> > >  };
> > >  
> > >  /*
> > > + * Register a shared page for the hypervisor to indicate whether the
> > > + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> > > + * array indexed by Xen's PIRQ value.
> > > + */
> > > +#define PHYSDEVOP_pirq_eoi_gmfn      28
> > 
> > Ah, the number is right, but the name is the generic one.
> > 
> > We should really mention that this is different from v1 or just
> > 
> > #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> > and use that in the code?
> 
> Maybe we should:
> 
> #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> 
> in order not to hide the fact that there are two versions of this
> hypercall.
> Then we do:
> 
> /* we use the second version of the hypercall */
> #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
> 
> 
> This way we just have PHYSDEVOP_pirq_eoi_gmfn in the code but we don't
> hide the version with are using.

That could work. However using a v2 everywhere will clearly show to
to somebody why it won't work with say Xen 4.0 (if they are trying to run it
under it and wonder why that hypercall did not work). Which reminds me, once the
hypervisor patch is in, we should definitly mention that in this git commit.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:07:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqmRs-0004Xq-Bi; Fri, 27 Jan 2012 14:06:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqmRq-0004Xl-JT
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:06:38 +0000
Received: from [85.158.138.51:52302] by server-7.bemta-3.messagelabs.com id
	95/D8-31267-D6FA22F4; Fri, 27 Jan 2012 14:06:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327673195!5786137!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMTEzNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 940 invoked from network); 27 Jan 2012 14:06:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 14:06:36 -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
	q0RE5HhS012911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 14:05:46 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0RE4wVe017101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 14:04:59 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0RE4vTr008891; Fri, 27 Jan 2012 08:04:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 06:04:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 508694019E; Fri, 27 Jan 2012 09:02:34 -0500 (EST)
Date: Fri, 27 Jan 2012 09:02:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127140234.GA32469@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327581807-17276-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020206.4F22AF52.01C4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 12:43:26PM +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/tty/hvc/hvc_xen.c          |   86 +++++++++++++++++++++++++++++-------
>  include/xen/interface/hvm/params.h |    6 ++-
>  2 files changed, 75 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 52fdf60..dd6641f 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -24,9 +24,12 @@
>  #include <linux/init.h>
>  #include <linux/types.h>
>  
> +#include <asm/io.h>
>  #include <asm/xen/hypervisor.h>
>  
>  #include <xen/xen.h>
> +#include <xen/interface/xen.h>
> +#include <xen/hvm.h>
>  #include <xen/page.h>
>  #include <xen/events.h>
>  #include <xen/interface/io/console.h>
> @@ -42,9 +45,13 @@ static int xencons_irq;
>  /* ------------------------------------------------------------------ */
>  
>  static unsigned long console_pfn = ~0ul;
> +static unsigned int console_evtchn = ~0ul;
> +static struct xencons_interface *xencons_if = NULL;
>  
>  static inline struct xencons_interface *xencons_interface(void)
>  {
> +	if (xencons_if != NULL)
> +		return xencons_if;
>  	if (console_pfn == ~0ul)
>  		return mfn_to_virt(xen_start_info->console.domU.mfn);
>  	else
> @@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
>  static inline void notify_daemon(void)
>  {
>  	/* Use evtchn: this is called early, before irq is set up. */
> -	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> +	if (console_evtchn == ~0ul)
> +		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> +	else
> +		notify_remote_via_evtchn(console_evtchn);
>  }
>  
>  static int __write_console(const char *data, int len)
> @@ -157,28 +167,65 @@ static struct hv_ops dom0_hvc_ops = {
>  	.notifier_hangup = notifier_hangup_irq,
>  };
>  
> +static int xen_hvm_console_init(void)
> +{
> +	int r;
> +	uint64_t v = 0;
> +	unsigned long mfn;
> +
> +	if (!xen_hvm_domain())
> +		return -ENODEV;
> +
> +	if (xencons_if != NULL)
> +		return -EBUSY;
> +
> +	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> +	if (r < 0)
> +		return -ENODEV;
> +	console_evtchn = v;
> +	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> +	if (r < 0)
> +		return -ENODEV;

If we fail here, the console_evtchn is still going to be set
meaning that "notify_daemon"  will use the event channel. Thought
I can't think of the notify daemon being called after the init had
failed so this might not be an issue.

> +	mfn = v;
> +	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	if (xencons_if == NULL)
> +		return -ENODEV;

Ditto. If we fail, we have the 'console_evtchn' set to something
else than ~0UL.

> +
> +	return 0;
> +}
> +
>  static int __init xen_hvc_init(void)
>  {
>  	struct hvc_struct *hp;
>  	struct hv_ops *ops;
> +	int r;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	if (xen_pv_domain() && !xen_initial_domain() &&
> +			!xen_start_info->console.domU.evtchn)

Ewww.. What about just leaving the check:
>  		return -ENODEV;
>  
>  	if (xen_initial_domain()) {
>  		ops = &dom0_hvc_ops;
>  		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
>  	} else {
> -		if (!xen_start_info->console.domU.evtchn)
> -			return -ENODEV;

this one as 'if (xen_pv_domain()) && !xen-..)

That might make the code nicer to read?

> -
>  		ops = &domU_hvc_ops;
> -		xencons_irq = bind_evtchn_to_irq(xen_start_info->console.domU.evtchn);
> +		if (xen_pv_domain()) {
> +			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> +			console_evtchn = xen_start_info->console.domU.evtchn;
> +		} else {
> +			r = xen_hvm_console_init();
> +			if (r < 0)
> +				return r;
> +		}
> +		xencons_irq = bind_evtchn_to_irq(console_evtchn);
> +		if (xencons_irq < 0)
> +			xencons_irq = 0; /* NO_IRQ */
> +		else
> +			irq_set_noprobe(xencons_irq);
>  	}
> -	if (xencons_irq < 0)
> -		xencons_irq = 0; /* NO_IRQ */
> -	else
> -		irq_set_noprobe(xencons_irq);
>  
>  	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
>  	if (IS_ERR(hp))
> @@ -186,15 +233,13 @@ static int __init xen_hvc_init(void)
>  
>  	hvc = hp;
>  
> -	console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> -
>  	return 0;
>  }
>  
>  void xen_console_resume(void)
>  {
>  	if (xencons_irq)
> -		rebind_evtchn_irq(xen_start_info->console.domU.evtchn, xencons_irq);
> +		rebind_evtchn_irq(console_evtchn, xencons_irq);
>  }
>  
>  static void __exit xen_hvc_fini(void)
> @@ -205,16 +250,22 @@ static void __exit xen_hvc_fini(void)
>  
>  static int xen_cons_init(void)
>  {
> -	struct hv_ops *ops;
> +	const struct hv_ops *ops;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return 0;
>  
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
> -	else
> +	else {
>  		ops = &domU_hvc_ops;
>  
> +		if (xen_pv_domain())
> +			console_evtchn = xen_start_info->console.domU.evtchn;
> +		else
> +			xen_hvm_console_init();
> +	}
> +
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
> @@ -230,6 +281,9 @@ static void xenboot_write_console(struct console *console, const char *string,
>  	unsigned int linelen, off = 0;
>  	const char *pos;
>  
> +	if (!xen_pv_domain())
> +		return;
> +
>  	dom0_write_console(0, string, len);
>  
>  	if (xen_initial_domain())
> diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
> index 1888d8c..1b4f923 100644
> --- a/include/xen/interface/hvm/params.h
> +++ b/include/xen/interface/hvm/params.h
> @@ -90,6 +90,10 @@
>  /* Boolean: Enable aligning all periodic vpts to reduce interrupts */
>  #define HVM_PARAM_VPT_ALIGN    16
>  
> -#define HVM_NR_PARAMS          17
> +/* Console debug shared memory ring and event channel */
> +#define HVM_PARAM_CONSOLE_PFN    17
> +#define HVM_PARAM_CONSOLE_EVTCHN 18
> +
> +#define HVM_NR_PARAMS          19
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_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 Jan 27 14:07:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:07:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqmRs-0004Xq-Bi; Fri, 27 Jan 2012 14:06:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqmRq-0004Xl-JT
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:06:38 +0000
Received: from [85.158.138.51:52302] by server-7.bemta-3.messagelabs.com id
	95/D8-31267-D6FA22F4; Fri, 27 Jan 2012 14:06:37 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327673195!5786137!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMTEzNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 940 invoked from network); 27 Jan 2012 14:06:36 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 14:06:36 -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
	q0RE5HhS012911
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 14:05:46 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158])
	by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0RE4wVe017101
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 14:04:59 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57])
	by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0RE4vTr008891; Fri, 27 Jan 2012 08:04:58 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 06:04:57 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 508694019E; Fri, 27 Jan 2012 09:02:34 -0500 (EST)
Date: Fri, 27 Jan 2012 09:02:34 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127140234.GA32469@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327581807-17276-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A020206.4F22AF52.01C4,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 12:43:26PM +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/tty/hvc/hvc_xen.c          |   86 +++++++++++++++++++++++++++++-------
>  include/xen/interface/hvm/params.h |    6 ++-
>  2 files changed, 75 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 52fdf60..dd6641f 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -24,9 +24,12 @@
>  #include <linux/init.h>
>  #include <linux/types.h>
>  
> +#include <asm/io.h>
>  #include <asm/xen/hypervisor.h>
>  
>  #include <xen/xen.h>
> +#include <xen/interface/xen.h>
> +#include <xen/hvm.h>
>  #include <xen/page.h>
>  #include <xen/events.h>
>  #include <xen/interface/io/console.h>
> @@ -42,9 +45,13 @@ static int xencons_irq;
>  /* ------------------------------------------------------------------ */
>  
>  static unsigned long console_pfn = ~0ul;
> +static unsigned int console_evtchn = ~0ul;
> +static struct xencons_interface *xencons_if = NULL;
>  
>  static inline struct xencons_interface *xencons_interface(void)
>  {
> +	if (xencons_if != NULL)
> +		return xencons_if;
>  	if (console_pfn == ~0ul)
>  		return mfn_to_virt(xen_start_info->console.domU.mfn);
>  	else
> @@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
>  static inline void notify_daemon(void)
>  {
>  	/* Use evtchn: this is called early, before irq is set up. */
> -	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> +	if (console_evtchn == ~0ul)
> +		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> +	else
> +		notify_remote_via_evtchn(console_evtchn);
>  }
>  
>  static int __write_console(const char *data, int len)
> @@ -157,28 +167,65 @@ static struct hv_ops dom0_hvc_ops = {
>  	.notifier_hangup = notifier_hangup_irq,
>  };
>  
> +static int xen_hvm_console_init(void)
> +{
> +	int r;
> +	uint64_t v = 0;
> +	unsigned long mfn;
> +
> +	if (!xen_hvm_domain())
> +		return -ENODEV;
> +
> +	if (xencons_if != NULL)
> +		return -EBUSY;
> +
> +	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> +	if (r < 0)
> +		return -ENODEV;
> +	console_evtchn = v;
> +	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> +	if (r < 0)
> +		return -ENODEV;

If we fail here, the console_evtchn is still going to be set
meaning that "notify_daemon"  will use the event channel. Thought
I can't think of the notify daemon being called after the init had
failed so this might not be an issue.

> +	mfn = v;
> +	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	if (xencons_if == NULL)
> +		return -ENODEV;

Ditto. If we fail, we have the 'console_evtchn' set to something
else than ~0UL.

> +
> +	return 0;
> +}
> +
>  static int __init xen_hvc_init(void)
>  {
>  	struct hvc_struct *hp;
>  	struct hv_ops *ops;
> +	int r;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
> +		return -ENODEV;
> +
> +	if (xen_pv_domain() && !xen_initial_domain() &&
> +			!xen_start_info->console.domU.evtchn)

Ewww.. What about just leaving the check:
>  		return -ENODEV;
>  
>  	if (xen_initial_domain()) {
>  		ops = &dom0_hvc_ops;
>  		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
>  	} else {
> -		if (!xen_start_info->console.domU.evtchn)
> -			return -ENODEV;

this one as 'if (xen_pv_domain()) && !xen-..)

That might make the code nicer to read?

> -
>  		ops = &domU_hvc_ops;
> -		xencons_irq = bind_evtchn_to_irq(xen_start_info->console.domU.evtchn);
> +		if (xen_pv_domain()) {
> +			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> +			console_evtchn = xen_start_info->console.domU.evtchn;
> +		} else {
> +			r = xen_hvm_console_init();
> +			if (r < 0)
> +				return r;
> +		}
> +		xencons_irq = bind_evtchn_to_irq(console_evtchn);
> +		if (xencons_irq < 0)
> +			xencons_irq = 0; /* NO_IRQ */
> +		else
> +			irq_set_noprobe(xencons_irq);
>  	}
> -	if (xencons_irq < 0)
> -		xencons_irq = 0; /* NO_IRQ */
> -	else
> -		irq_set_noprobe(xencons_irq);
>  
>  	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
>  	if (IS_ERR(hp))
> @@ -186,15 +233,13 @@ static int __init xen_hvc_init(void)
>  
>  	hvc = hp;
>  
> -	console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> -
>  	return 0;
>  }
>  
>  void xen_console_resume(void)
>  {
>  	if (xencons_irq)
> -		rebind_evtchn_irq(xen_start_info->console.domU.evtchn, xencons_irq);
> +		rebind_evtchn_irq(console_evtchn, xencons_irq);
>  }
>  
>  static void __exit xen_hvc_fini(void)
> @@ -205,16 +250,22 @@ static void __exit xen_hvc_fini(void)
>  
>  static int xen_cons_init(void)
>  {
> -	struct hv_ops *ops;
> +	const struct hv_ops *ops;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return 0;
>  
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
> -	else
> +	else {
>  		ops = &domU_hvc_ops;
>  
> +		if (xen_pv_domain())
> +			console_evtchn = xen_start_info->console.domU.evtchn;
> +		else
> +			xen_hvm_console_init();
> +	}
> +
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
> @@ -230,6 +281,9 @@ static void xenboot_write_console(struct console *console, const char *string,
>  	unsigned int linelen, off = 0;
>  	const char *pos;
>  
> +	if (!xen_pv_domain())
> +		return;
> +
>  	dom0_write_console(0, string, len);
>  
>  	if (xen_initial_domain())
> diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
> index 1888d8c..1b4f923 100644
> --- a/include/xen/interface/hvm/params.h
> +++ b/include/xen/interface/hvm/params.h
> @@ -90,6 +90,10 @@
>  /* Boolean: Enable aligning all periodic vpts to reduce interrupts */
>  #define HVM_PARAM_VPT_ALIGN    16
>  
> -#define HVM_NR_PARAMS          17
> +/* Console debug shared memory ring and event channel */
> +#define HVM_PARAM_CONSOLE_PFN    17
> +#define HVM_PARAM_CONSOLE_EVTCHN 18
> +
> +#define HVM_NR_PARAMS          19
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_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 Jan 27 14:09:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqmUf-0004dO-V6; Fri, 27 Jan 2012 14:09:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqmUd-0004dH-FH
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:09:31 +0000
Received: from [85.158.138.51:20385] by server-9.bemta-3.messagelabs.com id
	B5/80-31168-A10B22F4; Fri, 27 Jan 2012 14:09:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327673369!10733426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20183 invoked from network); 27 Jan 2012 14:09:30 -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;
	27 Jan 2012 14:09:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10330667"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 14:09: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; Fri, 27 Jan 2012 14:09:29 +0000
Date: Fri, 27 Jan 2012 14:10:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120127135105.GA16187@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201271410050.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
	<1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120126185155.GA24768@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201271058090.3196@kaball-desktop>
	<20120127135105.GA16187@phenom.dumpdata.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>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 27, 2012 at 11:03:41AM +0000, Stefano Stabellini wrote:
> > On Thu, 26 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> > > > The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> > > > be EOI'd without having to issue an hypercall every time.
> > > > We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> > > > succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > ---
> > > >  drivers/xen/events.c            |   17 ++++++++++++++++-
> > > >  include/xen/interface/physdev.h |   12 ++++++++++++
> > > >  2 files changed, 28 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > > index 6e075cd..7fdc738 100644
> > > > --- a/drivers/xen/events.c
> > > > +++ b/drivers/xen/events.c
> > > > @@ -37,6 +37,7 @@
> > > >  #include <asm/idle.h>
> > > >  #include <asm/io_apic.h>
> > > >  #include <asm/sync_bitops.h>
> > > > +#include <asm/xen/page.h>
> > > >  #include <asm/xen/pci.h>
> > > >  #include <asm/xen/hypercall.h>
> > > >  #include <asm/xen/hypervisor.h>
> > > > @@ -108,6 +109,7 @@ struct irq_info {
> > > >  #define PIRQ_SHAREABLE	(1 << 1)
> > > >  
> > > >  static int *evtchn_to_irq;
> > > > +static unsigned long *pirq_eoi_map;
> > > >  
> > > >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > > >  		      cpu_evtchn_mask);
> > > > @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
> > > >  
> > > >  	BUG_ON(info->type != IRQT_PIRQ);
> > > >  
> > > > +	if (pirq_eoi_map != NULL)
> > > > +		return test_bit(irq, pirq_eoi_map);
> > > > +
> > > 
> > > How about just having a different function called
> > > pirq_needs_eoi_v2 which will just do
> > > 
> > >  return test_bit(irq, pirq_eoi_map)?
> > > 
> > > And then set the pirq_needs_eoi_v2 in the function table?
> > 
> > Ok, but the name "pirq_needs_eoi_v2" is misleading because
> > PHYSDEVOP_pirq_eoi_gmfn only works for PV guests at the moment.
> > How about I call the new function "pirq_check_eoi_map" and rename the old
> > one "pirq_needs_eoi_flag" and the generic name of the function pointer
> > would remain "pirq_needs_eoi"?
> 
> Even better!
> > 
> > 
> > > >  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> > > >  }
> > > >  
> > > > @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
> > > >  
> > > >  void __init xen_init_IRQ(void)
> > > >  {
> > > > -	int i;
> > > > +	int i, rc;
> > > >  
> > > >  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
> > > >  				    GFP_KERNEL);
> > > > @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
> > > >  		 * __acpi_register_gsi can point at the right function */
> > > >  		pci_xen_hvm_init();
> > > >  	} else {
> > > > +		struct physdev_pirq_eoi_gmfn eoi_gmfn;
> > > > +
> > > >  		irq_ctx_init(smp_processor_id());
> > > >  		if (xen_initial_domain())
> > > >  			pci_xen_initial_domain();
> > > > +
> > > > +		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> > > > +		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> > > > +		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);
> > > 
> > > 
> > > Don't we want the v2 version?
> > > 
> > > > +		if (rc != 0) {
> > > > +			free_page((unsigned long) pirq_eoi_map);
> > > > +			pirq_eoi_map = NULL;
> > > > +		}
> > > >  	}
> > > >  }
> > > > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > > > index c1080d9..132c61f 100644
> > > > --- a/include/xen/interface/physdev.h
> > > > +++ b/include/xen/interface/physdev.h
> > > > @@ -39,6 +39,18 @@ struct physdev_eoi {
> > > >  };
> > > >  
> > > >  /*
> > > > + * Register a shared page for the hypervisor to indicate whether the
> > > > + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> > > > + * array indexed by Xen's PIRQ value.
> > > > + */
> > > > +#define PHYSDEVOP_pirq_eoi_gmfn      28
> > > 
> > > Ah, the number is right, but the name is the generic one.
> > > 
> > > We should really mention that this is different from v1 or just
> > > 
> > > #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> > > and use that in the code?
> > 
> > Maybe we should:
> > 
> > #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> > 
> > in order not to hide the fact that there are two versions of this
> > hypercall.
> > Then we do:
> > 
> > /* we use the second version of the hypercall */
> > #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
> > 
> > 
> > This way we just have PHYSDEVOP_pirq_eoi_gmfn in the code but we don't
> > hide the version with are using.
> 
> That could work. However using a v2 everywhere will clearly show to
> to somebody why it won't work with say Xen 4.0 (if they are trying to run it
> under it and wonder why that hypercall did not work). Which reminds me, once the
> hypervisor patch is in, we should definitly mention that in this git commit.

OK then, let's go with PHYSDEVOP_pirq_eoi_gmfn_v2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:09:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqmUf-0004dO-V6; Fri, 27 Jan 2012 14:09:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqmUd-0004dH-FH
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:09:31 +0000
Received: from [85.158.138.51:20385] by server-9.bemta-3.messagelabs.com id
	B5/80-31168-A10B22F4; Fri, 27 Jan 2012 14:09:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327673369!10733426!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20183 invoked from network); 27 Jan 2012 14:09:30 -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;
	27 Jan 2012 14:09:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10330667"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 14:09: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; Fri, 27 Jan 2012 14:09:29 +0000
Date: Fri, 27 Jan 2012 14:10:25 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120127135105.GA16187@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201271410050.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261736580.3196@kaball-desktop>
	<1327600839-23469-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120126185155.GA24768@phenom.dumpdata.com>
	<alpine.DEB.2.00.1201271058090.3196@kaball-desktop>
	<20120127135105.GA16187@phenom.dumpdata.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>,
	"JBeulich@suse.com" <JBeulich@suse.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] linux/xen: support pirq_eoi_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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 27, 2012 at 11:03:41AM +0000, Stefano Stabellini wrote:
> > On Thu, 26 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jan 26, 2012 at 06:00:39PM +0000, Stefano Stabellini wrote:
> > > > The pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
> > > > be EOI'd without having to issue an hypercall every time.
> > > > We use PHYSDEVOP_pirq_eoi_gmfn (v2) to map the bitmap, then, if we
> > > > succeed, we use pirq_eoi_map to check whether pirqs need eoi.
> > > > 
> > > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > > ---
> > > >  drivers/xen/events.c            |   17 ++++++++++++++++-
> > > >  include/xen/interface/physdev.h |   12 ++++++++++++
> > > >  2 files changed, 28 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > > index 6e075cd..7fdc738 100644
> > > > --- a/drivers/xen/events.c
> > > > +++ b/drivers/xen/events.c
> > > > @@ -37,6 +37,7 @@
> > > >  #include <asm/idle.h>
> > > >  #include <asm/io_apic.h>
> > > >  #include <asm/sync_bitops.h>
> > > > +#include <asm/xen/page.h>
> > > >  #include <asm/xen/pci.h>
> > > >  #include <asm/xen/hypercall.h>
> > > >  #include <asm/xen/hypervisor.h>
> > > > @@ -108,6 +109,7 @@ struct irq_info {
> > > >  #define PIRQ_SHAREABLE	(1 << 1)
> > > >  
> > > >  static int *evtchn_to_irq;
> > > > +static unsigned long *pirq_eoi_map;
> > > >  
> > > >  static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > > >  		      cpu_evtchn_mask);
> > > > @@ -274,6 +276,9 @@ static bool pirq_needs_eoi(unsigned irq)
> > > >  
> > > >  	BUG_ON(info->type != IRQT_PIRQ);
> > > >  
> > > > +	if (pirq_eoi_map != NULL)
> > > > +		return test_bit(irq, pirq_eoi_map);
> > > > +
> > > 
> > > How about just having a different function called
> > > pirq_needs_eoi_v2 which will just do
> > > 
> > >  return test_bit(irq, pirq_eoi_map)?
> > > 
> > > And then set the pirq_needs_eoi_v2 in the function table?
> > 
> > Ok, but the name "pirq_needs_eoi_v2" is misleading because
> > PHYSDEVOP_pirq_eoi_gmfn only works for PV guests at the moment.
> > How about I call the new function "pirq_check_eoi_map" and rename the old
> > one "pirq_needs_eoi_flag" and the generic name of the function pointer
> > would remain "pirq_needs_eoi"?
> 
> Even better!
> > 
> > 
> > > >  	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> > > >  }
> > > >  
> > > > @@ -1693,7 +1698,7 @@ void xen_callback_vector(void) {}
> > > >  
> > > >  void __init xen_init_IRQ(void)
> > > >  {
> > > > -	int i;
> > > > +	int i, rc;
> > > >  
> > > >  	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
> > > >  				    GFP_KERNEL);
> > > > @@ -1714,8 +1719,18 @@ void __init xen_init_IRQ(void)
> > > >  		 * __acpi_register_gsi can point at the right function */
> > > >  		pci_xen_hvm_init();
> > > >  	} else {
> > > > +		struct physdev_pirq_eoi_gmfn eoi_gmfn;
> > > > +
> > > >  		irq_ctx_init(smp_processor_id());
> > > >  		if (xen_initial_domain())
> > > >  			pci_xen_initial_domain();
> > > > +
> > > > +		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
> > > > +		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
> > > > +		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn, &eoi_gmfn);
> > > 
> > > 
> > > Don't we want the v2 version?
> > > 
> > > > +		if (rc != 0) {
> > > > +			free_page((unsigned long) pirq_eoi_map);
> > > > +			pirq_eoi_map = NULL;
> > > > +		}
> > > >  	}
> > > >  }
> > > > diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
> > > > index c1080d9..132c61f 100644
> > > > --- a/include/xen/interface/physdev.h
> > > > +++ b/include/xen/interface/physdev.h
> > > > @@ -39,6 +39,18 @@ struct physdev_eoi {
> > > >  };
> > > >  
> > > >  /*
> > > > + * Register a shared page for the hypervisor to indicate whether the
> > > > + * guest must issue PHYSDEVOP_eoi. The page registered is used as a bit
> > > > + * array indexed by Xen's PIRQ value.
> > > > + */
> > > > +#define PHYSDEVOP_pirq_eoi_gmfn      28
> > > 
> > > Ah, the number is right, but the name is the generic one.
> > > 
> > > We should really mention that this is different from v1 or just
> > > 
> > > #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> > > and use that in the code?
> > 
> > Maybe we should:
> > 
> > #define PHYSDEVOP_pirq_eoi_gmfn_v2 28
> > 
> > in order not to hide the fact that there are two versions of this
> > hypercall.
> > Then we do:
> > 
> > /* we use the second version of the hypercall */
> > #define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
> > 
> > 
> > This way we just have PHYSDEVOP_pirq_eoi_gmfn in the code but we don't
> > hide the version with are using.
> 
> That could work. However using a v2 everywhere will clearly show to
> to somebody why it won't work with say Xen 4.0 (if they are trying to run it
> under it and wonder why that hypercall did not work). Which reminds me, once the
> hypervisor patch is in, we should definitly mention that in this git commit.

OK then, let's go with PHYSDEVOP_pirq_eoi_gmfn_v2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:20:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14: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 1Rqmf4-000564-Ed; Fri, 27 Jan 2012 14:20:18 +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 1Rqmf3-00055w-22
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:20:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327674006!12815664!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31834 invoked from network); 27 Jan 2012 14:20:10 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE001.bigfish.com) (65.55.88.11)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Jan 2012 14:20:10 -0000
Received: from mail52-tx2-R.bigfish.com (10.9.14.238) by
	TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 27 Jan 2012 14:20:03 +0000
Received: from mail52-tx2 (localhost [127.0.0.1])	by mail52-tx2-R.bigfish.com
	(Postfix) with ESMTP id 203E7E0199;
	Fri, 27 Jan 2012 14:20:03 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zzbb2dI936eK98bK1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h93fh)
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-tx2 (localhost.localdomain [127.0.0.1]) by mail52-tx2
	(MessageSwitch) id 1327674001175959_3521;
	Fri, 27 Jan 2012 14:20:01 +0000 (UTC)
Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.245])	by
	mail52-tx2.bigfish.com (Postfix) with ESMTP id 265AE120046;
	Fri, 27 Jan 2012 14:20:01 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server id
	14.1.225.23; Fri, 27 Jan 2012 14:19:58 +0000
X-WSS-ID: 0LYGNT4-02-515-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 2ECD2FCC046;	Fri, 27 Jan 2012 08:19:51 -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;
	Fri, 27 Jan 2012 08:20:14 -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;
	Fri, 27 Jan 2012 08:19:56 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 27 Jan 2012
	09:19:55 -0500
Message-ID: <4F22B28A.6050609@amd.com>
Date: Fri, 27 Jan 2012 15:19:54 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F2164CE.6070609@amd.com>
	<1327589481.26983.95.camel@zakaz.uk.xensource.com>
	<4F216AB4.9020908@amd.com>
	<1327590393.26983.98.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327590393.26983.98.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] seabios build 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/26/12 16:06, Ian Campbell wrote:
> On Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
>> On 01/26/12 15:51, Ian Campbell wrote:
>>> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
>>>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
>>>>      Building ld scripts (version "1.6.3.1-20120126_152501")
>>>> env: python: No such file or directory
>>>> gmake[6]: *** [out/romlayout16.lds] Error 127
>>>>
>>>>
>>>> The python scripts must be invoked with $(PYTHON) as done
>>>> throughout the build system.
>>>
>>> SeaBIOS uses:
>>> $ rgrep -i python tools/firmware/seabios-dir
>>> tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install python-serial
>>> tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python
>>>
>>> Does this not work? Should python be on your $PATH?
>>
>> It is. But the python binary on NetBSD's pkgsrc
>> is called python<version>  to allow concurrent installations of different
>> python versions.
>> So I can have: python2.5, python2.6, python2.7, python3.1, etc.
>
> There is no current "python" referring to the default version?
>
> I think this is something you will need to work out with the SeaBIOS
> upstream.
>
> Ian.
>
>>
>> Christoph
>>
>>>
>>> Since SeaBIOS is third party code we are not so much at liberty to make
>>> the same sorts of policy decisions as we would for our own code.
>>>
>>> You could perhaps attempt to work around this by invoking the recursive
>>> make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
>>> whatever the appropriate runes are.
>>>
>>> Or you could try posting a patch to SeaBIOS-devel, I don't know what
>>> their thinking on this sort of thing is.

I see.

What python version does SeaBIOS require?
I have python 2.5 installed.

I manually created a python symlink to that version and then I get this 
failure:

gmake[6]: Entering directory 'tools/firmware/seabios-dir-remote'
   Building ld scripts (version "1.6.3.1-20120127_151243")
Fixed space: 0xe05b-0x10000  total: 8101  slack: 5 Percent slack: 0.1%
16bit size:           46336
32bit segmented size: 2005
32bit flat size:      14699
32bit flat init size: 53888
Traceback (most recent call last):
   File "./tools/layoutrom.py", line 579, in <module>
     main()
   File "./tools/layoutrom.py", line 576, in main
     writeLinkerScripts(sections, entrysym, genreloc, out16, out32seg, 
out32flag)
   File "./tools/layoutrom.py", line 257, in writeLinkerScripts
     + COMMONTRAILER
TypeError: int argument required
gmake[6]: *** [out/romlayout16.lds] Error 1


Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:20:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14: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 1Rqmf4-000564-Ed; Fri, 27 Jan 2012 14:20:18 +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 1Rqmf3-00055w-22
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:20:17 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327674006!12815664!1
X-Originating-IP: [65.55.88.11]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31834 invoked from network); 27 Jan 2012 14:20:10 -0000
Received: from tx2ehsobe001.messaging.microsoft.com (HELO
	TX2EHSOBE001.bigfish.com) (65.55.88.11)
	by server-6.tower-216.messagelabs.com with AES128-SHA encrypted SMTP;
	27 Jan 2012 14:20:10 -0000
Received: from mail52-tx2-R.bigfish.com (10.9.14.238) by
	TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id
	14.1.225.23; Fri, 27 Jan 2012 14:20:03 +0000
Received: from mail52-tx2 (localhost [127.0.0.1])	by mail52-tx2-R.bigfish.com
	(Postfix) with ESMTP id 203E7E0199;
	Fri, 27 Jan 2012 14:20:03 +0000 (UTC)
X-SpamScore: -16
X-BigFish: VPS-16(zzbb2dI936eK98bK1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h93fh)
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-tx2 (localhost.localdomain [127.0.0.1]) by mail52-tx2
	(MessageSwitch) id 1327674001175959_3521;
	Fri, 27 Jan 2012 14:20:01 +0000 (UTC)
Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.245])	by
	mail52-tx2.bigfish.com (Postfix) with ESMTP id 265AE120046;
	Fri, 27 Jan 2012 14:20:01 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server id
	14.1.225.23; Fri, 27 Jan 2012 14:19:58 +0000
X-WSS-ID: 0LYGNT4-02-515-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 2ECD2FCC046;	Fri, 27 Jan 2012 08:19:51 -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;
	Fri, 27 Jan 2012 08:20:14 -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;
	Fri, 27 Jan 2012 08:19:56 -0600
Received: from rhodium.osrc.amd.com (165.204.15.173) by storexhtp02.amd.com
	(172.24.4.4) with Microsoft SMTP Server id 8.3.213.0; Fri, 27 Jan 2012
	09:19:55 -0500
Message-ID: <4F22B28A.6050609@amd.com>
Date: Fri, 27 Jan 2012 15:19:54 +0100
From: Christoph Egger <Christoph.Egger@amd.com>
User-Agent: Mozilla/5.0 (X11; NetBSD amd64;
	rv:8.0) Gecko/20111114 Thunderbird/8.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <4F2164CE.6070609@amd.com>
	<1327589481.26983.95.camel@zakaz.uk.xensource.com>
	<4F216AB4.9020908@amd.com>
	<1327590393.26983.98.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327590393.26983.98.camel@zakaz.uk.xensource.com>
X-OriginatorOrg: amd.com
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] seabios build 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/26/12 16:06, Ian Campbell wrote:
> On Thu, 2012-01-26 at 15:01 +0000, Christoph Egger wrote:
>> On 01/26/12 15:51, Ian Campbell wrote:
>>> On Thu, 2012-01-26 at 14:35 +0000, Christoph Egger wrote:
>>>> gmake[6]: Entering directory tools/firmware/seabios-dir-remote
>>>>      Building ld scripts (version "1.6.3.1-20120126_152501")
>>>> env: python: No such file or directory
>>>> gmake[6]: *** [out/romlayout16.lds] Error 127
>>>>
>>>>
>>>> The python scripts must be invoked with $(PYTHON) as done
>>>> throughout the build system.
>>>
>>> SeaBIOS uses:
>>> $ rgrep -i python tools/firmware/seabios-dir
>>> tools/firmware/seabios-dir/tools/transdump.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/buildrom.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/checkstack.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/encodeint.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/layoutrom.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/checkrom.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/readserial.py:#!/usr/bin/env python
>>> tools/firmware/seabios-dir/tools/readserial.py:Or: apt-get install python-serial
>>> tools/firmware/seabios-dir/tools/checksum.py:#!/usr/bin/env python
>>>
>>> Does this not work? Should python be on your $PATH?
>>
>> It is. But the python binary on NetBSD's pkgsrc
>> is called python<version>  to allow concurrent installations of different
>> python versions.
>> So I can have: python2.5, python2.6, python2.7, python3.1, etc.
>
> There is no current "python" referring to the default version?
>
> I think this is something you will need to work out with the SeaBIOS
> upstream.
>
> Ian.
>
>>
>> Christoph
>>
>>>
>>> Since SeaBIOS is third party code we are not so much at liberty to make
>>> the same sorts of policy decisions as we would for our own code.
>>>
>>> You could perhaps attempt to work around this by invoking the recursive
>>> make into the seabios directory with PATH=$(dir-only $(PYTHON):$PATH or
>>> whatever the appropriate runes are.
>>>
>>> Or you could try posting a patch to SeaBIOS-devel, I don't know what
>>> their thinking on this sort of thing is.

I see.

What python version does SeaBIOS require?
I have python 2.5 installed.

I manually created a python symlink to that version and then I get this 
failure:

gmake[6]: Entering directory 'tools/firmware/seabios-dir-remote'
   Building ld scripts (version "1.6.3.1-20120127_151243")
Fixed space: 0xe05b-0x10000  total: 8101  slack: 5 Percent slack: 0.1%
16bit size:           46336
32bit segmented size: 2005
32bit flat size:      14699
32bit flat init size: 53888
Traceback (most recent call last):
   File "./tools/layoutrom.py", line 579, in <module>
     main()
   File "./tools/layoutrom.py", line 576, in main
     writeLinkerScripts(sections, entrysym, genreloc, out16, out32seg, 
out32flag)
   File "./tools/layoutrom.py", line 257, in writeLinkerScripts
     + COMMONTRAILER
TypeError: int argument required
gmake[6]: *** [out/romlayout16.lds] Error 1


Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:28:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqmn5-0005Fo-FH; Fri, 27 Jan 2012 14:28:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqmn3-0005Fg-PO
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:28:34 +0000
Received: from [85.158.138.51:63157] by server-6.bemta-3.messagelabs.com id
	B1/B4-31032-094B22F4; Fri, 27 Jan 2012 14:28:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327674512!9086125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6408 invoked from network); 27 Jan 2012 14:28:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 14:28:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10331418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 14:28: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, 27 Jan 2012 14:28: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
	1Rqmn1-0003o5-1M; Fri, 27 Jan 2012 14:28:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqmn0-0000Nn-Uc;
	Fri, 27 Jan 2012 14:28:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.46222.937948.124567@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 14:28:30 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327656578.26983.123.camel@zakaz.uk.xensource.com>
References: <osstest-11627-mainreport@xen.org>
	<1327656578.26983.123.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] [xen-unstable test] 11627: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11627: regressions - trouble: blocked/broken/fail/pass"):
> I've just noticed that this was a clone of the non-staging tree (and I
> propagated that via cut and paste into my test). I suppose it is
> possible that the script which pushes from staging->main is not updating
> the server info or that there has been some manual activity while things
> were getting set up.

The current state of that branch was not a result of an automatic test
push; I had just forgotten to run git-update-server-info in it,
although I had enabled the hook.

> I've done "git update-server-info" in both the staging and non-staging
> qemu-upstream-xen.git and my manual clone has come up with the correct
> HEAD.

Thanks.

> Stefano, next time you have cause to push please could you do a quick
> manual clone via the http URL just to check that things are working
> correctly.

I think it will be fine now.

> >  build-amd64-pvops             4 kernel-build              fail REGR. vs. 11601
> 
> This one is:
>         + git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux
>         using cache /volatile/git-cache...
>         using cache /volatile/git-cache...
>         locked cache /volatile/git-cache...
>         processing /usr/local/bin/git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux...
>         Cloning into linux...
>         fatal: The remote end hung up unexpectedly
>         
> Which is presumably an external failure which also explains the
> subsequent linux test failure. Everything looks OK to me now so I assume
> it was a transient issue.

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 Jan 27 14:28:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:28:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqmn5-0005Fo-FH; Fri, 27 Jan 2012 14:28:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqmn3-0005Fg-PO
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:28:34 +0000
Received: from [85.158.138.51:63157] by server-6.bemta-3.messagelabs.com id
	B1/B4-31032-094B22F4; Fri, 27 Jan 2012 14:28:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327674512!9086125!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6408 invoked from network); 27 Jan 2012 14:28:32 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 14:28:32 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10331418"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 14:28: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, 27 Jan 2012 14:28: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
	1Rqmn1-0003o5-1M; Fri, 27 Jan 2012 14:28:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqmn0-0000Nn-Uc;
	Fri, 27 Jan 2012 14:28:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.46222.937948.124567@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 14:28:30 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327656578.26983.123.camel@zakaz.uk.xensource.com>
References: <osstest-11627-mainreport@xen.org>
	<1327656578.26983.123.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] [xen-unstable test] 11627: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11627: regressions - trouble: blocked/broken/fail/pass"):
> I've just noticed that this was a clone of the non-staging tree (and I
> propagated that via cut and paste into my test). I suppose it is
> possible that the script which pushes from staging->main is not updating
> the server info or that there has been some manual activity while things
> were getting set up.

The current state of that branch was not a result of an automatic test
push; I had just forgotten to run git-update-server-info in it,
although I had enabled the hook.

> I've done "git update-server-info" in both the staging and non-staging
> qemu-upstream-xen.git and my manual clone has come up with the correct
> HEAD.

Thanks.

> Stefano, next time you have cause to push please could you do a quick
> manual clone via the http URL just to check that things are working
> correctly.

I think it will be fine now.

> >  build-amd64-pvops             4 kernel-build              fail REGR. vs. 11601
> 
> This one is:
>         + git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux
>         using cache /volatile/git-cache...
>         using cache /volatile/git-cache...
>         locked cache /volatile/git-cache...
>         processing /usr/local/bin/git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux...
>         Cloning into linux...
>         fatal: The remote end hung up unexpectedly
>         
> Which is presumably an external failure which also explains the
> subsequent linux test failure. Everything looks OK to me now so I assume
> it was a transient issue.

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 Jan 27 14:35:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqmtR-0005Pf-Bl; Fri, 27 Jan 2012 14:35: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 1RqmtP-0005PZ-Km
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:35:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327674879!50518499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28788 invoked from network); 27 Jan 2012 14:34:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 14:34:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10332023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 14:35:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 14:35: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
	1RqmtI-0003qD-S9; Fri, 27 Jan 2012 14:35:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqmtI-0000PH-RL;
	Fri, 27 Jan 2012 14:35:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.46612.673833.365233@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 14:35:00 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327656582.26983.124.camel@zakaz.uk.xensource.com>,
	<1327656591.26983.125.camel@zakaz.uk.xensource.com>
References: <osstest-11628-mainreport@xen.org>
	<1327656591.26983.125.camel@zakaz.uk.xensource.com>
	<osstest-11631-mainreport@xen.org>
	<1327656582.26983.124.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] 11631: regressions - trouble:
 blocked/broken/pass [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] [qemu-upstream-unstable test] 11628: trouble: blocked/broken/pass"):
> On Thu, 2012-01-26 at 20:49 +0000, xen.org wrote:
> > flight 11628 qemu-upstream-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11628/
> > 
> > 
> > jobs:
> >  build-amd64                                                  broken  
> >  build-i386                                                   broken  
> >  build-amd64-oldkern                                          broken  
> >  build-i386-oldkern                                           broken  
> 
> These are the same version mismatch as I described on the xen-unstable
> test failure.
> 
> I did notice that this one was also cloning the non-staging tree. Is
> this not the push gateway test?

Yes, it should be using the non-staging tree.  In fact as it happens
all of my test runs are supposed to clone from the non-staging tree
and explicitly reset to a specific version.  That avoids having
multiple tree urls floating about.  But in this particular case I
hadn't quite managed to plumb it all through quite right.  (Not helped
by some of the Config.mk variables being renamed since I did this
originally...)

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11631: regressions - trouble: blocked/broken/pass"):
> On Thu, 2012-01-26 at 20:55 +0000, xen.org wrote:
> > flight 11631 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11631/
> 
> Not relating to the failure but I've noticed these in the logs a few
> times recently:
>         Use of uninitialized value $r{"tree_linux"} in length at ./ts-xen-build line 31.
>         Use of uninitialized value $r{"revision_seabios"} in length at ./ts-xen-build line 36.
>         Use of uninitialized value $r{"tree_linux"} in length at ./ts-xen-build line 36.
>         Use of uninitialized value $r{"revision_linux"} in length at ./ts-xen-build line 36.

These are harmless but ugly.  I will fix them.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:35:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:35:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqmtR-0005Pf-Bl; Fri, 27 Jan 2012 14:35: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 1RqmtP-0005PZ-Km
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:35:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327674879!50518499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28788 invoked from network); 27 Jan 2012 14:34:39 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 14:34:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10332023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 14:35:01 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 14:35: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
	1RqmtI-0003qD-S9; Fri, 27 Jan 2012 14:35:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqmtI-0000PH-RL;
	Fri, 27 Jan 2012 14:35:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.46612.673833.365233@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 14:35:00 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327656582.26983.124.camel@zakaz.uk.xensource.com>,
	<1327656591.26983.125.camel@zakaz.uk.xensource.com>
References: <osstest-11628-mainreport@xen.org>
	<1327656591.26983.125.camel@zakaz.uk.xensource.com>
	<osstest-11631-mainreport@xen.org>
	<1327656582.26983.124.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] 11631: regressions - trouble:
 blocked/broken/pass [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] [qemu-upstream-unstable test] 11628: trouble: blocked/broken/pass"):
> On Thu, 2012-01-26 at 20:49 +0000, xen.org wrote:
> > flight 11628 qemu-upstream-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11628/
> > 
> > 
> > jobs:
> >  build-amd64                                                  broken  
> >  build-i386                                                   broken  
> >  build-amd64-oldkern                                          broken  
> >  build-i386-oldkern                                           broken  
> 
> These are the same version mismatch as I described on the xen-unstable
> test failure.
> 
> I did notice that this one was also cloning the non-staging tree. Is
> this not the push gateway test?

Yes, it should be using the non-staging tree.  In fact as it happens
all of my test runs are supposed to clone from the non-staging tree
and explicitly reset to a specific version.  That avoids having
multiple tree urls floating about.  But in this particular case I
hadn't quite managed to plumb it all through quite right.  (Not helped
by some of the Config.mk variables being renamed since I did this
originally...)

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11631: regressions - trouble: blocked/broken/pass"):
> On Thu, 2012-01-26 at 20:55 +0000, xen.org wrote:
> > flight 11631 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/11631/
> 
> Not relating to the failure but I've noticed these in the logs a few
> times recently:
>         Use of uninitialized value $r{"tree_linux"} in length at ./ts-xen-build line 31.
>         Use of uninitialized value $r{"revision_seabios"} in length at ./ts-xen-build line 36.
>         Use of uninitialized value $r{"tree_linux"} in length at ./ts-xen-build line 36.
>         Use of uninitialized value $r{"revision_linux"} in length at ./ts-xen-build line 36.

These are harmless but ugly.  I will fix them.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:43:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqn0u-0005ZN-9m; Fri, 27 Jan 2012 14:42:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rqn0t-0005ZI-75
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:42:51 +0000
Received: from [85.158.139.83:50392] by server-6.bemta-5.messagelabs.com id
	89/F7-21889-AE7B22F4; Fri, 27 Jan 2012 14:42:50 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327675368!12112761!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23747 invoked from network); 27 Jan 2012 14:42:49 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 14:42:49 -0000
Received: by qabg1 with SMTP id g1so4475176qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 06:42:48 -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:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=2o751HOHpVGscaFKOkSAuOBiHqjykM0Djbp8CZjZJtI=;
	b=XKqQy/ntnTR0JT8HLffbOBYje3V1utvxzoDQ0YDOmSGb/l3sMgColXQnAJ5aL3seAu
	aJJokslWGwRfHQG437qNRlTUBujXF/hLVil0lHmkEGFlpL41NYuf1cE/TXaoQSTK9mx5
	Z+6AumFFq4qBDos8ewMBnj6FVvBertt9ac2EM=
Received: by 10.224.181.11 with SMTP id bw11mr8662785qab.51.1327675368390;
	Fri, 27 Jan 2012 06:42:48 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id g9sm15467463qad.16.2012.01.27.06.42.46
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 27 Jan 2012 06:42:47 -0800 (PST)
Message-ID: <4F22B7E2.9070902@redhat.com>
Date: Fri, 27 Jan 2012 15:42:42 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.xen.devel,gmane.comp.emulators.qemu
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, anthony@codemonkey.ws,
	avi@redhat.com
Subject: Re: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
 expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> default to INT64_MAX instead of INT32_MAX.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   qemu-timer.c |   10 ++++------
>   1 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index cd026c6..648db1d 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
>
>   static int64_t qemu_next_alarm_deadline(void)
>   {
> -    int64_t delta;
> +    int64_t delta = INT64_MAX;

I'm worried of overflows elsewhere...

>       int64_t rtdelta;
>
> -    if (!use_icount&&  vm_clock->active_timers) {
> +    if (!use_icount&&  vm_clock->enabled&&  vm_clock->active_timers) {
>           delta = vm_clock->active_timers->expire_time -
>                        qemu_get_clock_ns(vm_clock);
> -    } else {
> -        delta = INT32_MAX;
>       }
> -    if (host_clock->active_timers) {
> +    if (host_clock->enabled&&  host_clock->active_timers) {
>           int64_t hdelta = host_clock->active_timers->expire_time -
>                    qemu_get_clock_ns(host_clock);
>           if (hdelta<  delta) {
>               delta = hdelta;
>           }
>       }
> -    if (rt_clock->active_timers) {
> +    if (rt_clock->enabled&&  rt_clock->active_timers) {
>           rtdelta = (rt_clock->active_timers->expire_time -
>                    qemu_get_clock_ns(rt_clock));
>           if (rtdelta<  delta) {

The patch is otherwise okay, but without looking more closely at the 
callers I'm not quite ready to give my Reviewed-by.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:43:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:43:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqn0u-0005ZN-9m; Fri, 27 Jan 2012 14:42:52 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rqn0t-0005ZI-75
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:42:51 +0000
Received: from [85.158.139.83:50392] by server-6.bemta-5.messagelabs.com id
	89/F7-21889-AE7B22F4; Fri, 27 Jan 2012 14:42:50 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327675368!12112761!1
X-Originating-IP: [209.85.216.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23747 invoked from network); 27 Jan 2012 14:42:49 -0000
Received: from mail-qw0-f43.google.com (HELO mail-qw0-f43.google.com)
	(209.85.216.43)
	by server-13.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 14:42:49 -0000
Received: by qabg1 with SMTP id g1so4475176qab.9
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 06:42:48 -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:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=2o751HOHpVGscaFKOkSAuOBiHqjykM0Djbp8CZjZJtI=;
	b=XKqQy/ntnTR0JT8HLffbOBYje3V1utvxzoDQ0YDOmSGb/l3sMgColXQnAJ5aL3seAu
	aJJokslWGwRfHQG437qNRlTUBujXF/hLVil0lHmkEGFlpL41NYuf1cE/TXaoQSTK9mx5
	Z+6AumFFq4qBDos8ewMBnj6FVvBertt9ac2EM=
Received: by 10.224.181.11 with SMTP id bw11mr8662785qab.51.1327675368390;
	Fri, 27 Jan 2012 06:42:48 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id g9sm15467463qad.16.2012.01.27.06.42.46
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 27 Jan 2012 06:42:47 -0800 (PST)
Message-ID: <4F22B7E2.9070902@redhat.com>
Date: Fri, 27 Jan 2012 15:42:42 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.xen.devel,gmane.comp.emulators.qemu
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, anthony@codemonkey.ws,
	avi@redhat.com
Subject: Re: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
 expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> default to INT64_MAX instead of INT32_MAX.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   qemu-timer.c |   10 ++++------
>   1 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index cd026c6..648db1d 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
>
>   static int64_t qemu_next_alarm_deadline(void)
>   {
> -    int64_t delta;
> +    int64_t delta = INT64_MAX;

I'm worried of overflows elsewhere...

>       int64_t rtdelta;
>
> -    if (!use_icount&&  vm_clock->active_timers) {
> +    if (!use_icount&&  vm_clock->enabled&&  vm_clock->active_timers) {
>           delta = vm_clock->active_timers->expire_time -
>                        qemu_get_clock_ns(vm_clock);
> -    } else {
> -        delta = INT32_MAX;
>       }
> -    if (host_clock->active_timers) {
> +    if (host_clock->enabled&&  host_clock->active_timers) {
>           int64_t hdelta = host_clock->active_timers->expire_time -
>                    qemu_get_clock_ns(host_clock);
>           if (hdelta<  delta) {
>               delta = hdelta;
>           }
>       }
> -    if (rt_clock->active_timers) {
> +    if (rt_clock->enabled&&  rt_clock->active_timers) {
>           rtdelta = (rt_clock->active_timers->expire_time -
>                    qemu_get_clock_ns(rt_clock));
>           if (rtdelta<  delta) {

The patch is otherwise okay, but without looking more closely at the 
callers I'm not quite ready to give my Reviewed-by.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:44:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqn1y-0005dI-Oa; Fri, 27 Jan 2012 14:43:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rqn1x-0005d9-MN
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:43:57 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327675317!61475486!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2898 invoked from network); 27 Jan 2012 14:41:59 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 14:41:59 -0000
Received: by qcsd15 with SMTP id d15so13610076qcs.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 06:43:55 -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:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=P26yh2nrpUJhqB47mBvkq7G6HzPGhMPlPx/D2NXvRzY=;
	b=O4lFJeEuUcuNqzf6181jL5pAj2+lRwn4vpRhcOYdzhheCl16zhhIpD5wvrsMfOF7js
	orLVTYd0izEb1LSfQ5ZrV4nEWPv+ARS+gUFdXcx8jvw1Aiwi0KxgdVMm9INuJCh1uqOH
	cCIqlFGXRFggsdKOoY4pEaF2YWdJsL2bz3tnk=
Received: by 10.224.200.197 with SMTP id ex5mr8583691qab.88.1327675435000;
	Fri, 27 Jan 2012 06:43:55 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id eb5sm15498781qab.10.2012.01.27.06.43.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 27 Jan 2012 06:43:54 -0800 (PST)
Message-ID: <4F22B81E.1030407@redhat.com>
Date: Fri, 27 Jan 2012 15:43:42 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu,gmane.comp.emulators.xen.devel
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, avi@redhat.com
Subject: Re: [Xen-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> There is no reason why the minimum timeout should be 1sec, it could
> easily be 1h and we would save lots of cpu cycles.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   qemu-timer.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index 648db1d..b792a32 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -844,6 +844,6 @@ fail:
>
>   int qemu_calculate_timeout(void)
>   {
> -    return 1000;
> +    return 1000*60*60;
>   }
>

This might break Windows networking, but I'm going to fix it before 1.1 
anyway.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:44:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:44:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqn1y-0005dI-Oa; Fri, 27 Jan 2012 14:43:58 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rqn1x-0005d9-MN
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:43:57 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327675317!61475486!1
X-Originating-IP: [209.85.216.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2898 invoked from network); 27 Jan 2012 14:41:59 -0000
Received: from mail-qy0-f171.google.com (HELO mail-qy0-f171.google.com)
	(209.85.216.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 14:41:59 -0000
Received: by qcsd15 with SMTP id d15so13610076qcs.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 06:43:55 -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:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=P26yh2nrpUJhqB47mBvkq7G6HzPGhMPlPx/D2NXvRzY=;
	b=O4lFJeEuUcuNqzf6181jL5pAj2+lRwn4vpRhcOYdzhheCl16zhhIpD5wvrsMfOF7js
	orLVTYd0izEb1LSfQ5ZrV4nEWPv+ARS+gUFdXcx8jvw1Aiwi0KxgdVMm9INuJCh1uqOH
	cCIqlFGXRFggsdKOoY4pEaF2YWdJsL2bz3tnk=
Received: by 10.224.200.197 with SMTP id ex5mr8583691qab.88.1327675435000;
	Fri, 27 Jan 2012 06:43:55 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id eb5sm15498781qab.10.2012.01.27.06.43.53
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 27 Jan 2012 06:43:54 -0800 (PST)
Message-ID: <4F22B81E.1030407@redhat.com>
Date: Fri, 27 Jan 2012 15:43:42 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu,gmane.comp.emulators.xen.devel
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, avi@redhat.com
Subject: Re: [Xen-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> There is no reason why the minimum timeout should be 1sec, it could
> easily be 1h and we would save lots of cpu cycles.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   qemu-timer.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index 648db1d..b792a32 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -844,6 +844,6 @@ fail:
>
>   int qemu_calculate_timeout(void)
>   {
> -    return 1000;
> +    return 1000*60*60;
>   }
>

This might break Windows networking, but I'm going to fix it before 1.1 
anyway.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:48:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqn5m-000624-Da; Fri, 27 Jan 2012 14:47:54 +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 1Rqn5k-00061d-EF
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:47:52 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327675663!12793123!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5663 invoked from network); 27 Jan 2012 14:47:44 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 14:47: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
	q0RElcWV029593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 27 Jan 2012 09:47:38 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0RElcgb029591;
	Fri, 27 Jan 2012 09:47:38 -0500
Date: Fri, 27 Jan 2012 10:47:37 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120127144737.GA27750@andromeda.dapyr.net>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 02:31:55PM +0100, William Dauchy wrote:
> Hello,
> 
> I have some troubles loading the IOATDMA module under xen4.1.2 and a
> linux dom0 3.3

So you are using the rc1 version? What exact git commit are you using?

> 
> CONFIG_INTEL_IOATDMA=m
> CONFIG_IGB=y
> 
> It was working with linux 3.1.5. The regression seems to be since
> linux 3.2. I tried to do a `git bisect` but I'm facing other

3.2 you say? This below is 3.3?

> regressions which make the debug harder.

Such as?

> 
> Here is the call trace when loading the module in dom0:

Is the problem present with baremetal (same exact kernel?)
Do you see this if you run a 64-bit dom0?

> 
> dca service started, version 1.12.1
> ioatdma: Intel(R) QuickData Technology Driver 4.00
> ioatdma 0000:00:16.0: enabling device (0000 -> 0002)
> xen: registering gsi 43 triggering 0 polarity 1
> xen: --> pirq=43 -> irq=43 (gsi=43)
> ------------[ cut here ]------------
> kernel BUG at /linux-3.3/drivers/dma/ioat/dma_v2.c:163!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: ioatdma(+) dca ebt_ip6 ebt_dnat ebt_ip
> ebtable_broute ebt_snat ebtable_nat ebtable_filter ebtables bridge stp
> llc ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod
> button
> 
> Pid: 0, comm: swapper/0 Not tainted 3.3.0-dom0-6357-i386+ #24 Dell
>   C6100           /0D61XP
> EIP: 0061:[<f512c524>] EFLAGS: 00010246 CPU: 0
> EIP is at __cleanup+0x154/0x160 [ioatdma]
> EAX: 00000000 EBX: e9dd44c0 ECX: 769ed7af EDX: 00000002
> ESI: e90fe48c EDI: 00000002 EBP: eb40bf9c ESP: eb40bf7c
>  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
> Process swapper/0 (pid: 0, ti=eb40a000 task=c1401ee0 task.ti=c13fc000)
> Stack:
>  eadc8040 00010002 18ae4040 00000002 0000bf9c e90fe48c e90fe4bc 00000006
>  eb40bfb0 f512c770 18ae4040 00000000 e90fe4f8 eb40bfc0 c10347cb 00000001
>  00000018 eb40bff8 c10350ab 00000000 00000000 00000000 00000000 00000000
> Call Trace:
>  [<f512c770>] ioat2_cleanup_event+0x30/0x50 [ioatdma]
>  [<c10347cb>] tasklet_action+0x9b/0xb0
>  [<c10350ab>] __do_softirq+0x7b/0x110
>  [<c1035030>] ? irq_enter+0x70/0x70
>  <IRQ>
>  [<c1034e7e>] ? irq_exit+0x6e/0xa0
>  [<c11bde70>] ? xen_evtchn_do_upcall+0x20/0x30
>  [<c1322907>] ? xen_do_upcall+0x7/0xc
>  [<c10013a7>] ? hypercall_page+0x3a7/0x1000
>  [<c1006172>] ? xen_safe_halt+0x12/0x20
>  [<c1010582>] ? default_idle+0x32/0x60
>  [<c1008596>] ? cpu_idle+0x66/0xa0
>  [<c130bd58>] ? rest_init+0x58/0x60
>  [<c14237d2>] ? start_kernel+0x2e4/0x2ea
>  [<c142331d>] ? kernel_init+0x11b/0x11b
>  [<c14230ba>] ? i386_start_kernel+0xa9/0xb0
>  [<c1426abb>] ? xen_start_kernel+0x5a2/0x5aa
> Code: 00 e8 41 7a f0 cb 8b 15 40 1a 40 c1 8d 14 10 8d 46 3c e8 60 ea
> f0 cb 83 c4 14 5b 5e 5f c9 c3 31 d2 89 df 31 c0 eb a2 84 c0 75 b5 <0f>
> 0b eb fe 90 8d b4 26 00 00 00 00 55 89 e5 57 56 53 89 c3 83
> EIP: [<f512c524>] __cleanup+0x154/0x160 [ioatdma] SS:ESP 0069:eb40bf7c
> ---[ end trace 902e93593e49fa50 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> 
> 
> Does anybody have any clue?
> 
> Regards,
> -- 
> William
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 27 14:48:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:48:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqn5m-000624-Da; Fri, 27 Jan 2012 14:47:54 +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 1Rqn5k-00061d-EF
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:47:52 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327675663!12793123!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5663 invoked from network); 27 Jan 2012 14:47:44 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-11.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 14:47: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
	q0RElcWV029593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 27 Jan 2012 09:47:38 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0RElcgb029591;
	Fri, 27 Jan 2012 09:47:38 -0500
Date: Fri, 27 Jan 2012 10:47:37 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: William Dauchy <wdauchy@gmail.com>
Message-ID: <20120127144737.GA27750@andromeda.dapyr.net>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 02:31:55PM +0100, William Dauchy wrote:
> Hello,
> 
> I have some troubles loading the IOATDMA module under xen4.1.2 and a
> linux dom0 3.3

So you are using the rc1 version? What exact git commit are you using?

> 
> CONFIG_INTEL_IOATDMA=m
> CONFIG_IGB=y
> 
> It was working with linux 3.1.5. The regression seems to be since
> linux 3.2. I tried to do a `git bisect` but I'm facing other

3.2 you say? This below is 3.3?

> regressions which make the debug harder.

Such as?

> 
> Here is the call trace when loading the module in dom0:

Is the problem present with baremetal (same exact kernel?)
Do you see this if you run a 64-bit dom0?

> 
> dca service started, version 1.12.1
> ioatdma: Intel(R) QuickData Technology Driver 4.00
> ioatdma 0000:00:16.0: enabling device (0000 -> 0002)
> xen: registering gsi 43 triggering 0 polarity 1
> xen: --> pirq=43 -> irq=43 (gsi=43)
> ------------[ cut here ]------------
> kernel BUG at /linux-3.3/drivers/dma/ioat/dma_v2.c:163!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: ioatdma(+) dca ebt_ip6 ebt_dnat ebt_ip
> ebtable_broute ebt_snat ebtable_nat ebtable_filter ebtables bridge stp
> llc ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi scsi_mod
> button
> 
> Pid: 0, comm: swapper/0 Not tainted 3.3.0-dom0-6357-i386+ #24 Dell
>   C6100           /0D61XP
> EIP: 0061:[<f512c524>] EFLAGS: 00010246 CPU: 0
> EIP is at __cleanup+0x154/0x160 [ioatdma]
> EAX: 00000000 EBX: e9dd44c0 ECX: 769ed7af EDX: 00000002
> ESI: e90fe48c EDI: 00000002 EBP: eb40bf9c ESP: eb40bf7c
>  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
> Process swapper/0 (pid: 0, ti=eb40a000 task=c1401ee0 task.ti=c13fc000)
> Stack:
>  eadc8040 00010002 18ae4040 00000002 0000bf9c e90fe48c e90fe4bc 00000006
>  eb40bfb0 f512c770 18ae4040 00000000 e90fe4f8 eb40bfc0 c10347cb 00000001
>  00000018 eb40bff8 c10350ab 00000000 00000000 00000000 00000000 00000000
> Call Trace:
>  [<f512c770>] ioat2_cleanup_event+0x30/0x50 [ioatdma]
>  [<c10347cb>] tasklet_action+0x9b/0xb0
>  [<c10350ab>] __do_softirq+0x7b/0x110
>  [<c1035030>] ? irq_enter+0x70/0x70
>  <IRQ>
>  [<c1034e7e>] ? irq_exit+0x6e/0xa0
>  [<c11bde70>] ? xen_evtchn_do_upcall+0x20/0x30
>  [<c1322907>] ? xen_do_upcall+0x7/0xc
>  [<c10013a7>] ? hypercall_page+0x3a7/0x1000
>  [<c1006172>] ? xen_safe_halt+0x12/0x20
>  [<c1010582>] ? default_idle+0x32/0x60
>  [<c1008596>] ? cpu_idle+0x66/0xa0
>  [<c130bd58>] ? rest_init+0x58/0x60
>  [<c14237d2>] ? start_kernel+0x2e4/0x2ea
>  [<c142331d>] ? kernel_init+0x11b/0x11b
>  [<c14230ba>] ? i386_start_kernel+0xa9/0xb0
>  [<c1426abb>] ? xen_start_kernel+0x5a2/0x5aa
> Code: 00 e8 41 7a f0 cb 8b 15 40 1a 40 c1 8d 14 10 8d 46 3c e8 60 ea
> f0 cb 83 c4 14 5b 5e 5f c9 c3 31 d2 89 df 31 c0 eb a2 84 c0 75 b5 <0f>
> 0b eb fe 90 8d b4 26 00 00 00 00 55 89 e5 57 56 53 89 c3 83
> EIP: [<f512c524>] __cleanup+0x154/0x160 [ioatdma] SS:ESP 0069:eb40bf7c
> ---[ end trace 902e93593e49fa50 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> 
> 
> Does anybody have any clue?
> 
> Regards,
> -- 
> William
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 27 14:50:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14: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 1Rqn8D-0006DD-5f; Fri, 27 Jan 2012 14:50:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Rqn8B-0006Cv-Ho
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:50:23 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327675757!58684094!1
X-Originating-IP: [80.91.229.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9534 invoked from network); 27 Jan 2012 14:49:17 -0000
Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12)
	by server-2.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 14:49:17 -0000
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Rqn81-0004ao-Ce
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:50:13 +0100
Received: from 93-34-182-16.ip50.fastwebnet.it ([93.34.182.16])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 15:50:13 +0100
Received: from pbonzini by 93-34-182-16.ip50.fastwebnet.it with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 15:50:13 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 27 Jan 2012 15:42:42 +0100
Lines: 49
Message-ID: <4F22B7E2.9070902@redhat.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 93-34-182-16.ip50.fastwebnet.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
In-Reply-To: <1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
 expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> default to INT64_MAX instead of INT32_MAX.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   qemu-timer.c |   10 ++++------
>   1 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index cd026c6..648db1d 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
>
>   static int64_t qemu_next_alarm_deadline(void)
>   {
> -    int64_t delta;
> +    int64_t delta = INT64_MAX;

I'm worried of overflows elsewhere...

>       int64_t rtdelta;
>
> -    if (!use_icount&&  vm_clock->active_timers) {
> +    if (!use_icount&&  vm_clock->enabled&&  vm_clock->active_timers) {
>           delta = vm_clock->active_timers->expire_time -
>                        qemu_get_clock_ns(vm_clock);
> -    } else {
> -        delta = INT32_MAX;
>       }
> -    if (host_clock->active_timers) {
> +    if (host_clock->enabled&&  host_clock->active_timers) {
>           int64_t hdelta = host_clock->active_timers->expire_time -
>                    qemu_get_clock_ns(host_clock);
>           if (hdelta<  delta) {
>               delta = hdelta;
>           }
>       }
> -    if (rt_clock->active_timers) {
> +    if (rt_clock->enabled&&  rt_clock->active_timers) {
>           rtdelta = (rt_clock->active_timers->expire_time -
>                    qemu_get_clock_ns(rt_clock));
>           if (rtdelta<  delta) {

The patch is otherwise okay, but without looking more closely at the 
callers I'm not quite ready to give my Reviewed-by.

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:50:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14: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 1Rqn8D-0006DD-5f; Fri, 27 Jan 2012 14:50:25 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Rqn8B-0006Cv-Ho
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:50:23 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327675757!58684094!1
X-Originating-IP: [80.91.229.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9534 invoked from network); 27 Jan 2012 14:49:17 -0000
Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12)
	by server-2.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 14:49:17 -0000
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1Rqn81-0004ao-Ce
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:50:13 +0100
Received: from 93-34-182-16.ip50.fastwebnet.it ([93.34.182.16])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 15:50:13 +0100
Received: from pbonzini by 93-34-182-16.ip50.fastwebnet.it with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 15:50:13 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 27 Jan 2012 15:42:42 +0100
Lines: 49
Message-ID: <4F22B7E2.9070902@redhat.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 93-34-182-16.ip50.fastwebnet.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
In-Reply-To: <1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
 expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> default to INT64_MAX instead of INT32_MAX.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   qemu-timer.c |   10 ++++------
>   1 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index cd026c6..648db1d 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
>
>   static int64_t qemu_next_alarm_deadline(void)
>   {
> -    int64_t delta;
> +    int64_t delta = INT64_MAX;

I'm worried of overflows elsewhere...

>       int64_t rtdelta;
>
> -    if (!use_icount&&  vm_clock->active_timers) {
> +    if (!use_icount&&  vm_clock->enabled&&  vm_clock->active_timers) {
>           delta = vm_clock->active_timers->expire_time -
>                        qemu_get_clock_ns(vm_clock);
> -    } else {
> -        delta = INT32_MAX;
>       }
> -    if (host_clock->active_timers) {
> +    if (host_clock->enabled&&  host_clock->active_timers) {
>           int64_t hdelta = host_clock->active_timers->expire_time -
>                    qemu_get_clock_ns(host_clock);
>           if (hdelta<  delta) {
>               delta = hdelta;
>           }
>       }
> -    if (rt_clock->active_timers) {
> +    if (rt_clock->enabled&&  rt_clock->active_timers) {
>           rtdelta = (rt_clock->active_timers->expire_time -
>                    qemu_get_clock_ns(rt_clock));
>           if (rtdelta<  delta) {

The patch is otherwise okay, but without looking more closely at the 
callers I'm not quite ready to give my Reviewed-by.

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:55:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:55:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqnCu-0006PG-UR; Fri, 27 Jan 2012 14:55:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1RqnCt-0006PA-0Z
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:55:15 +0000
Received: from [85.158.138.51:42737] by server-9.bemta-3.messagelabs.com id
	5B/B8-31168-2DAB22F4; Fri, 27 Jan 2012 14:55:14 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327676112!10954278!1
X-Originating-IP: [80.91.229.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7053 invoked from network); 27 Jan 2012 14:55:13 -0000
Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12)
	by server-5.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 14:55:13 -0000
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1RqnCm-0006zl-HH
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:55:08 +0100
Received: from 93-34-182-16.ip50.fastwebnet.it ([93.34.182.16])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 15:55:08 +0100
Received: from pbonzini by 93-34-182-16.ip50.fastwebnet.it with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 15:55:08 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 27 Jan 2012 15:43:42 +0100
Lines: 28
Message-ID: <4F22B81E.1030407@redhat.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 93-34-182-16.ip50.fastwebnet.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
In-Reply-To: <1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> There is no reason why the minimum timeout should be 1sec, it could
> easily be 1h and we would save lots of cpu cycles.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   qemu-timer.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index 648db1d..b792a32 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -844,6 +844,6 @@ fail:
>
>   int qemu_calculate_timeout(void)
>   {
> -    return 1000;
> +    return 1000*60*60;
>   }
>

This might break Windows networking, but I'm going to fix it before 1.1 
anyway.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 14:55:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 14:55:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqnCu-0006PG-UR; Fri, 27 Jan 2012 14:55:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1RqnCt-0006PA-0Z
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 14:55:15 +0000
Received: from [85.158.138.51:42737] by server-9.bemta-3.messagelabs.com id
	5B/B8-31168-2DAB22F4; Fri, 27 Jan 2012 14:55:14 +0000
X-Env-Sender: gcvxd-xen-devel@m.gmane.org
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327676112!10954278!1
X-Originating-IP: [80.91.229.12]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7053 invoked from network); 27 Jan 2012 14:55:13 -0000
Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12)
	by server-5.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 14:55:13 -0000
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gcvxd-xen-devel@m.gmane.org>) id 1RqnCm-0006zl-HH
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:55:08 +0100
Received: from 93-34-182-16.ip50.fastwebnet.it ([93.34.182.16])
	by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
	id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 15:55:08 +0100
Received: from pbonzini by 93-34-182-16.ip50.fastwebnet.it with local (Gmexim
	0.1 (Debian)) id 1AlnuQ-0007hv-00
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 15:55:08 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: xen-devel@lists.xensource.com
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri, 27 Jan 2012 15:43:42 +0100
Lines: 28
Message-ID: <4F22B81E.1030407@redhat.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: 93-34-182-16.ip50.fastwebnet.it
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
In-Reply-To: <1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> There is no reason why the minimum timeout should be 1sec, it could
> easily be 1h and we would save lots of cpu cycles.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   qemu-timer.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/qemu-timer.c b/qemu-timer.c
> index 648db1d..b792a32 100644
> --- a/qemu-timer.c
> +++ b/qemu-timer.c
> @@ -844,6 +844,6 @@ fail:
>
>   int qemu_calculate_timeout(void)
>   {
> -    return 1000;
> +    return 1000*60*60;
>   }
>

This might break Windows networking, but I'm going to fix it before 1.1 
anyway.

Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:03:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqnKC-0006bl-Sk; Fri, 27 Jan 2012 15:02:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1RqnKB-0006bg-2V
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:02:47 +0000
Received: from [85.158.139.83:30115] by server-8.bemta-5.messagelabs.com id
	B5/26-31172-69CB22F4; Fri, 27 Jan 2012 15:02:46 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327676564!12652511!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32472 invoked from network); 27 Jan 2012 15:02:45 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 15:02:45 -0000
Received: by iaeh11 with SMTP id h11so12939735iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 07:02:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=PEEkX2M+YwTYRi0JAL1drIGoE+dbrbxIQX9kSjGvuU4=;
	b=oIEAwAlHwooV/JOzbc44pZYBo3Psi8eo69hKoJfnwrR07PyeF2P9oax+5FFQ5KugK9
	0cSwolJ8foxZwA/a6Fj2tQAJCot9h1ooQIZou3chm34xlFrohi/LvOIrpEsYXB8s9dnB
	JV3v0PRkg+uHt8CywpS51FqaH9YL6CAnBakhU=
Received: by 10.42.246.71 with SMTP id lx7mr5366863icb.54.1327676564200; Fri,
	27 Jan 2012 07:02:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.36.35 with HTTP; Fri, 27 Jan 2012 07:02:24 -0800 (PST)
In-Reply-To: <20120127144737.GA27750@andromeda.dapyr.net>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
	<20120127144737.GA27750@andromeda.dapyr.net>
From: William Dauchy <wdauchy@gmail.com>
Date: Fri, 27 Jan 2012 16:02:24 +0100
Message-ID: <CAJ75kXagCmHNbwMS2hPr_qwn54QJdqq9h0d8ga6sUZhMRehiTA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 3:47 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> So you are using the rc1 version? What exact git commit are you using?

I pulled the last revision 74ea15d

> 3.2 you say? This below is 3.3?

Yes. I was using 3.1 kernel. After an upgrade to 3.2 I got the problem
and thought it was good to report the problem with the last 3.3-rc
kernel

> Is the problem present with baremetal (same exact kernel?)

I indeed tested with a baremetal kernel and didn't got any problem. So
it seems to come from a Xen problem.

> Do you see this if you run a 64-bit dom0?

I didn't test this.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:03:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:03:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqnKC-0006bl-Sk; Fri, 27 Jan 2012 15:02:48 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wdauchy@gmail.com>) id 1RqnKB-0006bg-2V
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:02:47 +0000
Received: from [85.158.139.83:30115] by server-8.bemta-5.messagelabs.com id
	B5/26-31172-69CB22F4; Fri, 27 Jan 2012 15:02:46 +0000
X-Env-Sender: wdauchy@gmail.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327676564!12652511!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32472 invoked from network); 27 Jan 2012 15:02:45 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-6.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 15:02:45 -0000
Received: by iaeh11 with SMTP id h11so12939735iae.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 07:02:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=PEEkX2M+YwTYRi0JAL1drIGoE+dbrbxIQX9kSjGvuU4=;
	b=oIEAwAlHwooV/JOzbc44pZYBo3Psi8eo69hKoJfnwrR07PyeF2P9oax+5FFQ5KugK9
	0cSwolJ8foxZwA/a6Fj2tQAJCot9h1ooQIZou3chm34xlFrohi/LvOIrpEsYXB8s9dnB
	JV3v0PRkg+uHt8CywpS51FqaH9YL6CAnBakhU=
Received: by 10.42.246.71 with SMTP id lx7mr5366863icb.54.1327676564200; Fri,
	27 Jan 2012 07:02:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.36.35 with HTTP; Fri, 27 Jan 2012 07:02:24 -0800 (PST)
In-Reply-To: <20120127144737.GA27750@andromeda.dapyr.net>
References: <CAJ75kXZ-2vWZpG7Uz3firg6ew4y_DdorXotkAkUGSK0GWLMUQQ@mail.gmail.com>
	<20120127144737.GA27750@andromeda.dapyr.net>
From: William Dauchy <wdauchy@gmail.com>
Date: Fri, 27 Jan 2012 16:02:24 +0100
Message-ID: <CAJ75kXagCmHNbwMS2hPr_qwn54QJdqq9h0d8ga6sUZhMRehiTA@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] regression ioatdma 3.3
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 3:47 PM, Konrad Rzeszutek Wilk
<konrad@darnok.org> wrote:
> So you are using the rc1 version? What exact git commit are you using?

I pulled the last revision 74ea15d

> 3.2 you say? This below is 3.3?

Yes. I was using 3.1 kernel. After an upgrade to 3.2 I got the problem
and thought it was good to report the problem with the last 3.3-rc
kernel

> Is the problem present with baremetal (same exact kernel?)

I indeed tested with a baremetal kernel and didn't got any problem. So
it seems to come from a Xen problem.

> Do you see this if you run a 64-bit dom0?

I didn't test this.

-- 
William

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:13:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15: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 1RqnU5-0006lm-W3; Fri, 27 Jan 2012 15:13:01 +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 1RqnU4-0006lh-Hd
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:13:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327677119!58687997!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26257 invoked from network); 27 Jan 2012 15:11:59 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 15:11:59 -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
	q0RFCuok006337; Fri, 27 Jan 2012 15:12:56 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 q0RFCuqX031521; 
	Fri, 27 Jan 2012 10:12:56 -0500
Message-ID: <4F22BEF9.6080209@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:12:57 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-6-git-send-email-dgdegra@tycho.nsa.gov>
	<1327658050.26983.142.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327658050.26983.142.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 05/24] xen: Preserve reserved grant entries
 when switching 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 01/27/2012 04:54 AM, Ian Campbell wrote:
> It would be worth CCing the relevant maintainers for each patch in the
> series. e.g. Keir in this case.

OK, will do that for v6.

> On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
>> In order for the toolstack to use reserved grant table entries, the
>> grant table for a guest must be initialized prior to the guest's boot.
>> When the guest switches grant table versions (necessary if the guest is
>> using v2 grant tables, or on kexec if switching grant versions), these
>> initial grants will be cleared. Instead of clearing them, preserve
>> the grants across the type change.
>>
>> Attempting to preserve v2-only features such as sub-page grants will
>> produce a warning and invalidate the resulting v1 grant entry.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
>>  xen/include/public/grant_table.h |    7 +++++
>>  2 files changed, 49 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> index 0c55fd1..6f24a94 100644
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>>      struct domain *d = current->domain;
>>      struct grant_table *gt = d->grant_table;
>>      struct active_grant_entry *act;
>> +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
>>      long res;
>>      int i;
>>  
>> @@ -2131,7 +2132,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>>      /* (You need to change the version number for e.g. kexec.) */
>>      if ( gt->gt_version != 0 )
>>      {
>> -        for ( i = 0; i < nr_grant_entries(gt); i++ )
>> +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
> 
> The comment just prior says:
>     /* Make sure that the grant table isn't currently in use when we
>        change the version number. */
> I think this needs updating to note that we do allow reserved entries to
> be active during the switch over and we will correctly preserve
> flags/status/mapped-ness etc.

Right.

>>          {
>>              act = &active_entry(gt, i);
>>              if ( act->pin != 0 )
>> @@ -2156,15 +2157,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>>              goto out_unlock;
>>      }
>>  
>> +    /* Preserve the first 8 entries (toolstack reserved grants) */
>> +    if (gt->gt_version == 1)
> 
> Xen coding style has extra spaces just inside the braces (and again
> below a few more times).
> 
>> +    {
>> +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> 
> Shouldn't that be either "gt->shared_v1" or "&gt->shared_v1[0]" ?
> 

No, [0] means this is copying from the first page; the first entry would be
gt->shared_v1[0][0]. &shared_entry_v1(gt, 0) may be clearer here; I'll use that.

>> +    }
>> +    else if (gt->gt_version == 2)
>> +    {
>> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
>> +        {
>> +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
>> +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
>> +            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
>> +            reserved_entries[i].flags |= status_entry(gt, i);
>> +            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)
> 
> In effect this only allows GTF_permit_access or GTF_invalid, which is
> good. It would be more obvious/explicit to do
> 	if ((shared_entry_v2(gt, i).hdr.flags & GTF_type_mask) != GTF_invalid &&
> 	    (shared_entry_v2(gt, i).hdr.flags & GTF_type_mask) != GTF_permit_access)
> 		memset-whole-entry and continue;
> at the top or even a switch().

In that case I think it would be clearer to only populate the entry if GTF_permit_access
and clear it otherwise (warning if not already GTF_invalid).

>> +            {
>> +                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
>> +                       d->domain_id, reserved_entries[i].flags, i);
>> +                reserved_entries[i].flags = GTF_invalid;
>> +            }
>> +        }
>> +    }
>> +
>>      if ( op.version < 2 && gt->gt_version == 2 )
>>          gnttab_unpopulate_status_frames(d, gt);
>>  
>> -    if ( op.version != gt->gt_version )
>> +    /* Make sure there's no crud left over in the table from the
>> +       old version. */
>> +    for ( i = 0; i < nr_grant_frames(gt); i++ )
>> +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
>> +
>> +    /* Restore the first 8 entries (toolstack reserved grants) */
>> +    if (gt->gt_version != 0 && op.version == 1)
>>      {
>> -        /* Make sure there's no crud left over in the table from the
>> -           old version. */
>> -        for ( i = 0; i < nr_grant_frames(gt); i++ )
>> -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
>> +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
>> +    }
>> +    else if (gt->gt_version != 0 && op.version == 2)
>> +    {
>> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
>> +        {
>> +            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
>> +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
>> +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
>> +            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
>> +        }
>>      }
>>  
>>      gt->gt_version = op.version;
>> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
>> index 54d9551..292d724 100644
>> --- a/xen/include/public/grant_table.h
>> +++ b/xen/include/public/grant_table.h
>> @@ -117,6 +117,13 @@ struct grant_entry_v1 {
>>  };
>>  typedef struct grant_entry_v1 grant_entry_v1_t;
>>  
>> +/* The first few grant table entries will be preserved across grant table
>> + * version changes and may be pre-populated at domain creation by tools.
>> + */
>> +#define GNTTAB_NR_RESERVED_ENTRIES     8
>> +#define GNTTAB_RESERVED_CONSOLE        0
>> +#define GNTTAB_RESERVED_XENSTORE       1
>> +
>>  /*
>>   * Type of grant entry.
>>   *  GTF_invalid: This grant entry grants no privileges.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:13:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15: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 1RqnU5-0006lm-W3; Fri, 27 Jan 2012 15:13:01 +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 1RqnU4-0006lh-Hd
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:13:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327677119!58687997!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26257 invoked from network); 27 Jan 2012 15:11:59 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 15:11:59 -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
	q0RFCuok006337; Fri, 27 Jan 2012 15:12:56 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 q0RFCuqX031521; 
	Fri, 27 Jan 2012 10:12:56 -0500
Message-ID: <4F22BEF9.6080209@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:12:57 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-6-git-send-email-dgdegra@tycho.nsa.gov>
	<1327658050.26983.142.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327658050.26983.142.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 05/24] xen: Preserve reserved grant entries
 when switching 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 01/27/2012 04:54 AM, Ian Campbell wrote:
> It would be worth CCing the relevant maintainers for each patch in the
> series. e.g. Keir in this case.

OK, will do that for v6.

> On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
>> In order for the toolstack to use reserved grant table entries, the
>> grant table for a guest must be initialized prior to the guest's boot.
>> When the guest switches grant table versions (necessary if the guest is
>> using v2 grant tables, or on kexec if switching grant versions), these
>> initial grants will be cleared. Instead of clearing them, preserve
>> the grants across the type change.
>>
>> Attempting to preserve v2-only features such as sub-page grants will
>> produce a warning and invalidate the resulting v1 grant entry.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
>> ---
>>  xen/common/grant_table.c         |   48 +++++++++++++++++++++++++++++++++----
>>  xen/include/public/grant_table.h |    7 +++++
>>  2 files changed, 49 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
>> index 0c55fd1..6f24a94 100644
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/grant_table.c
>> @@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>>      struct domain *d = current->domain;
>>      struct grant_table *gt = d->grant_table;
>>      struct active_grant_entry *act;
>> +    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
>>      long res;
>>      int i;
>>  
>> @@ -2131,7 +2132,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>>      /* (You need to change the version number for e.g. kexec.) */
>>      if ( gt->gt_version != 0 )
>>      {
>> -        for ( i = 0; i < nr_grant_entries(gt); i++ )
>> +        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
> 
> The comment just prior says:
>     /* Make sure that the grant table isn't currently in use when we
>        change the version number. */
> I think this needs updating to note that we do allow reserved entries to
> be active during the switch over and we will correctly preserve
> flags/status/mapped-ness etc.

Right.

>>          {
>>              act = &active_entry(gt, i);
>>              if ( act->pin != 0 )
>> @@ -2156,15 +2157,50 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
>>              goto out_unlock;
>>      }
>>  
>> +    /* Preserve the first 8 entries (toolstack reserved grants) */
>> +    if (gt->gt_version == 1)
> 
> Xen coding style has extra spaces just inside the braces (and again
> below a few more times).
> 
>> +    {
>> +        memcpy(reserved_entries, gt->shared_v1[0], sizeof(reserved_entries));
> 
> Shouldn't that be either "gt->shared_v1" or "&gt->shared_v1[0]" ?
> 

No, [0] means this is copying from the first page; the first entry would be
gt->shared_v1[0][0]. &shared_entry_v1(gt, 0) may be clearer here; I'll use that.

>> +    }
>> +    else if (gt->gt_version == 2)
>> +    {
>> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
>> +        {
>> +            reserved_entries[i].flags = shared_entry_v2(gt, i).hdr.flags;
>> +            reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
>> +            reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
>> +            reserved_entries[i].flags |= status_entry(gt, i);
>> +            if ((reserved_entries[i].flags & GTF_type_mask) > GTF_permit_access)
> 
> In effect this only allows GTF_permit_access or GTF_invalid, which is
> good. It would be more obvious/explicit to do
> 	if ((shared_entry_v2(gt, i).hdr.flags & GTF_type_mask) != GTF_invalid &&
> 	    (shared_entry_v2(gt, i).hdr.flags & GTF_type_mask) != GTF_permit_access)
> 		memset-whole-entry and continue;
> at the top or even a switch().

In that case I think it would be clearer to only populate the entry if GTF_permit_access
and clear it otherwise (warning if not already GTF_invalid).

>> +            {
>> +                gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
>> +                       d->domain_id, reserved_entries[i].flags, i);
>> +                reserved_entries[i].flags = GTF_invalid;
>> +            }
>> +        }
>> +    }
>> +
>>      if ( op.version < 2 && gt->gt_version == 2 )
>>          gnttab_unpopulate_status_frames(d, gt);
>>  
>> -    if ( op.version != gt->gt_version )
>> +    /* Make sure there's no crud left over in the table from the
>> +       old version. */
>> +    for ( i = 0; i < nr_grant_frames(gt); i++ )
>> +        memset(gt->shared_raw[i], 0, PAGE_SIZE);
>> +
>> +    /* Restore the first 8 entries (toolstack reserved grants) */
>> +    if (gt->gt_version != 0 && op.version == 1)
>>      {
>> -        /* Make sure there's no crud left over in the table from the
>> -           old version. */
>> -        for ( i = 0; i < nr_grant_frames(gt); i++ )
>> -            memset(gt->shared_raw[i], 0, PAGE_SIZE);
>> +        memcpy(gt->shared_v1[0], reserved_entries, sizeof(reserved_entries));
>> +    }
>> +    else if (gt->gt_version != 0 && op.version == 2)
>> +    {
>> +        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
>> +        {
>> +            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
>> +            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
>> +            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
>> +            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
>> +        }
>>      }
>>  
>>      gt->gt_version = op.version;
>> diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
>> index 54d9551..292d724 100644
>> --- a/xen/include/public/grant_table.h
>> +++ b/xen/include/public/grant_table.h
>> @@ -117,6 +117,13 @@ struct grant_entry_v1 {
>>  };
>>  typedef struct grant_entry_v1 grant_entry_v1_t;
>>  
>> +/* The first few grant table entries will be preserved across grant table
>> + * version changes and may be pre-populated at domain creation by tools.
>> + */
>> +#define GNTTAB_NR_RESERVED_ENTRIES     8
>> +#define GNTTAB_RESERVED_CONSOLE        0
>> +#define GNTTAB_RESERVED_XENSTORE       1
>> +
>>  /*
>>   * Type of grant entry.
>>   *  GTF_invalid: This grant entry grants no privileges.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:15:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15: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 1RqnWW-0006qs-II; Fri, 27 Jan 2012 15:15:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqnWV-0006qf-HG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:15:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327677282!62003796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7472 invoked from network); 27 Jan 2012 15:14:42 -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;
	27 Jan 2012 15:14:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:15: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;
	Fri, 27 Jan 2012 15:15:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:15:23 +0000
In-Reply-To: <1327077375-7623-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
	<1327077375-7623-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327677323.26983.182.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 07/27] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:35 +0000, Stefano Stabellini wrote:
> - make the compilation of ns16550.c depend upon HAS_NS16550;
> 
> - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> 
> - make the compilation of pci depend upon HAS_PCI;
> 
> - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> 
> - make the compilation of kexec depend upon HAS_KEXEC.

This appears to be the only non-ARM patch in this series which hasn't
gone in.

Is there a problem with it or was it overlooked?

> 
> 
> 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 9fc6d42..65275af 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -3,6 +3,11 @@
>  
>  HAS_ACPI := y
>  HAS_VGA  := y
> +HAS_CPUFREQ := y
> +HAS_PCI := y
> +HAS_PASSTHROUGH := y
> +HAS_NS16550 := y
> +HAS_KEXEC := y
>  xenoprof := y
>  
>  #
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 1d85e65..9249845 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -8,7 +8,7 @@ obj-y += grant_table.o
>  obj-y += irq.o
>  obj-y += kernel.o
>  obj-y += keyhandler.o
> -obj-y += kexec.o
> +obj-$(HAS_KEXEC) += kexec.o
>  obj-y += lib.o
>  obj-y += memory.o
>  obj-y += multicall.o
> diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
> index e356e86..b18ef5d 100644
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -6,7 +6,9 @@
>  #include <xen/delay.h>
>  #include <xen/shutdown.h>
>  #include <xen/console.h>
> +#ifdef CONFIG_KEXEC
>  #include <xen/kexec.h>
> +#endif
>  #include <asm/debugger.h>
>  #include <public/sched.h>
>  
> @@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
>      case SHUTDOWN_watchdog:
>      {
>          printk("Domain 0 shutdown: watchdog rebooting machine.\n");
> +#ifdef CONFIG_KEXEC
>          kexec_crash();
> +#endif
>          machine_restart(0);
>          break; /* not reached */
>      }
> diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
> index eb4fb61..7239375 100644
> --- a/xen/drivers/Makefile
> +++ b/xen/drivers/Makefile
> @@ -1,6 +1,6 @@
>  subdir-y += char
> -subdir-y += cpufreq
> -subdir-y += pci
> -subdir-y += passthrough
> +subdir-$(HAS_CPUFREQ) += cpufreq
> +subdir-$(HAS_PCI) += pci
> +subdir-$(HAS_PASSTHROUGH) += passthrough
>  subdir-$(HAS_ACPI) += acpi
>  subdir-$(HAS_VGA) += video
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index ded9a94..19250c8 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -1,3 +1,3 @@
>  obj-y += console.o
> -obj-y += ns16550.o
> +obj-$(HAS_NS16550) += ns16550.o
>  obj-y += serial.o
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 89cf4f8..19f021c 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -22,7 +22,9 @@
>  #include <xen/guest_access.h>
>  #include <xen/shutdown.h>
>  #include <xen/vga.h>
> +#ifdef CONFIG_KEXEC
>  #include <xen/kexec.h>
> +#endif
>  #include <asm/debugger.h>
>  #include <asm/div64.h>
>  #include <xen/hypercall.h> /* for do_console_io */
> @@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
>  
>      debugger_trap_immediate();
>  
> +#ifdef CONFIG_KEXEC
>      kexec_crash();
> +#endif
>  
>      if ( opt_noreboot )
>      {
> diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
> index 0173487..6e9fc98 100644
> --- a/xen/include/asm-ia64/config.h
> +++ b/xen/include/asm-ia64/config.h
> @@ -20,6 +20,7 @@
>  #define CONFIG_EFI
>  #define CONFIG_EFI_PCDP
>  #define CONFIG_SERIAL_SGI_L1_CONSOLE
> +#define CONFIG_KEXEC 1
>  #define CONFIG_XENOPROF 1
>  
>  #define CONFIG_XEN_SMP
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 18d0a05..28f5e29 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -49,6 +49,7 @@
>  #define CONFIG_HOTPLUG_CPU 1
>  
>  #define CONFIG_XENOPROF 1
> +#define CONFIG_KEXEC 1
>  
>  #define HZ 100
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:15:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15: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 1RqnWW-0006qs-II; Fri, 27 Jan 2012 15:15:32 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqnWV-0006qf-HG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:15:31 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327677282!62003796!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7472 invoked from network); 27 Jan 2012 15:14:42 -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;
	27 Jan 2012 15:14:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334406"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:15: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;
	Fri, 27 Jan 2012 15:15:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:15:23 +0000
In-Reply-To: <1327077375-7623-7-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201605370.3196@kaball-desktop>
	<1327077375-7623-7-git-send-email-stefano.stabellini@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327677323.26983.182.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Keir Fraser <keir@xen.org>, "Tim Deegan \(3P\)" <Tim.Deegan@citrix.com>
Subject: Re: [Xen-devel] [PATCH v6 07/27] xen/common/Makefile: introduce
 HAS_CPUFREQ, HAS_PCI, HAS_PASSTHROUGH, HAS_NS16550, HAS_KEXEC
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-20 at 16:35 +0000, Stefano Stabellini wrote:
> - make the compilation of ns16550.c depend upon HAS_NS16550;
> 
> - make the compilation of cpufreq depend upon HAS_CPUFREQ;
> 
> - make the compilation of pci depend upon HAS_PCI;
> 
> - make the compilation of passthrough depend upon HAS_PASSTHROUGH;
> 
> - make the compilation of kexec depend upon HAS_KEXEC.

This appears to be the only non-ARM patch in this series which hasn't
gone in.

Is there a problem with it or was it overlooked?

> 
> 
> 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 9fc6d42..65275af 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -3,6 +3,11 @@
>  
>  HAS_ACPI := y
>  HAS_VGA  := y
> +HAS_CPUFREQ := y
> +HAS_PCI := y
> +HAS_PASSTHROUGH := y
> +HAS_NS16550 := y
> +HAS_KEXEC := y
>  xenoprof := y
>  
>  #
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 1d85e65..9249845 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -8,7 +8,7 @@ obj-y += grant_table.o
>  obj-y += irq.o
>  obj-y += kernel.o
>  obj-y += keyhandler.o
> -obj-y += kexec.o
> +obj-$(HAS_KEXEC) += kexec.o
>  obj-y += lib.o
>  obj-y += memory.o
>  obj-y += multicall.o
> diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c
> index e356e86..b18ef5d 100644
> --- a/xen/common/shutdown.c
> +++ b/xen/common/shutdown.c
> @@ -6,7 +6,9 @@
>  #include <xen/delay.h>
>  #include <xen/shutdown.h>
>  #include <xen/console.h>
> +#ifdef CONFIG_KEXEC
>  #include <xen/kexec.h>
> +#endif
>  #include <asm/debugger.h>
>  #include <public/sched.h>
>  
> @@ -58,7 +60,9 @@ void dom0_shutdown(u8 reason)
>      case SHUTDOWN_watchdog:
>      {
>          printk("Domain 0 shutdown: watchdog rebooting machine.\n");
> +#ifdef CONFIG_KEXEC
>          kexec_crash();
> +#endif
>          machine_restart(0);
>          break; /* not reached */
>      }
> diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
> index eb4fb61..7239375 100644
> --- a/xen/drivers/Makefile
> +++ b/xen/drivers/Makefile
> @@ -1,6 +1,6 @@
>  subdir-y += char
> -subdir-y += cpufreq
> -subdir-y += pci
> -subdir-y += passthrough
> +subdir-$(HAS_CPUFREQ) += cpufreq
> +subdir-$(HAS_PCI) += pci
> +subdir-$(HAS_PASSTHROUGH) += passthrough
>  subdir-$(HAS_ACPI) += acpi
>  subdir-$(HAS_VGA) += video
> diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile
> index ded9a94..19250c8 100644
> --- a/xen/drivers/char/Makefile
> +++ b/xen/drivers/char/Makefile
> @@ -1,3 +1,3 @@
>  obj-y += console.o
> -obj-y += ns16550.o
> +obj-$(HAS_NS16550) += ns16550.o
>  obj-y += serial.o
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 89cf4f8..19f021c 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -22,7 +22,9 @@
>  #include <xen/guest_access.h>
>  #include <xen/shutdown.h>
>  #include <xen/vga.h>
> +#ifdef CONFIG_KEXEC
>  #include <xen/kexec.h>
> +#endif
>  #include <asm/debugger.h>
>  #include <asm/div64.h>
>  #include <xen/hypercall.h> /* for do_console_io */
> @@ -961,7 +963,9 @@ void panic(const char *fmt, ...)
>  
>      debugger_trap_immediate();
>  
> +#ifdef CONFIG_KEXEC
>      kexec_crash();
> +#endif
>  
>      if ( opt_noreboot )
>      {
> diff --git a/xen/include/asm-ia64/config.h b/xen/include/asm-ia64/config.h
> index 0173487..6e9fc98 100644
> --- a/xen/include/asm-ia64/config.h
> +++ b/xen/include/asm-ia64/config.h
> @@ -20,6 +20,7 @@
>  #define CONFIG_EFI
>  #define CONFIG_EFI_PCDP
>  #define CONFIG_SERIAL_SGI_L1_CONSOLE
> +#define CONFIG_KEXEC 1
>  #define CONFIG_XENOPROF 1
>  
>  #define CONFIG_XEN_SMP
> diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
> index 18d0a05..28f5e29 100644
> --- a/xen/include/asm-x86/config.h
> +++ b/xen/include/asm-x86/config.h
> @@ -49,6 +49,7 @@
>  #define CONFIG_HOTPLUG_CPU 1
>  
>  #define CONFIG_XENOPROF 1
> +#define CONFIG_KEXEC 1
>  
>  #define HZ 100
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:22:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15: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 1RqndB-0007Hv-EK; Fri, 27 Jan 2012 15:22:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqnd9-0007Hq-8C
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:22:23 +0000
Received: from [85.158.138.51:57923] by server-12.bemta-3.messagelabs.com id
	D2/B3-24557-E21C22F4; Fri, 27 Jan 2012 15:22:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327677741!10883580!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30321 invoked from network); 27 Jan 2012 15:22:21 -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;
	27 Jan 2012 15:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334702"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:22: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, 27 Jan 2012 15:22:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:22:20 +0000
In-Reply-To: <1327598457-28261-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327677740.26983.183.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/11] ocaml, libxl: support "private" fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> The changeset
>   24378:b4365e2c2595  libxl: idl: support new "private" type attribute
> is not complete.  Actually using this feature does not work because
> the ocaml idl generator does not know about it.
> 
> So add that support.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

I acked this one last time round.

Ian.

> ---
>  tools/ocaml/libs/xl/genwrap.py |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
> index 2e65aec..00583d2 100644
> --- a/tools/ocaml/libs/xl/genwrap.py
> +++ b/tools/ocaml/libs/xl/genwrap.py
> @@ -93,6 +93,8 @@ def gen_ocaml_ml(ty, interface, indent=""):
>              s += "\t{\n"
>              
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              x = ocaml_instance_of(f.type, f.name)
>              x = x.replace("\n", "\n\t\t")
>              s += "\t\t" + x + ";\n"
> @@ -148,6 +150,8 @@ def c_val(ty, c, o, indent="", parent = None):
>      elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
>          n = 0
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
>              n = n + 1
>      else:
> @@ -212,6 +216,8 @@ def ocaml_Val(ty, o, c, indent="", parent = None):
>          
>          n = 0
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              s += "\n"
>              s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
>              s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
> @@ -290,6 +296,8 @@ if __name__ == '__main__':
>      cinc.write(autogen_header("/*", "*/"))
>  
>      for ty in types:
> +        if ty.private:
> +            continue
>          #sys.stdout.write(" TYPE    %-20s " % ty.rawname)
>          ml.write(gen_ocaml_ml(ty, False))
>          ml.write("\n")



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:22:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15: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 1RqndB-0007Hv-EK; Fri, 27 Jan 2012 15:22:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rqnd9-0007Hq-8C
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:22:23 +0000
Received: from [85.158.138.51:57923] by server-12.bemta-3.messagelabs.com id
	D2/B3-24557-E21C22F4; Fri, 27 Jan 2012 15:22:22 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327677741!10883580!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30321 invoked from network); 27 Jan 2012 15:22:21 -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;
	27 Jan 2012 15:22:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334702"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:22: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, 27 Jan 2012 15:22:20 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:22:20 +0000
In-Reply-To: <1327598457-28261-5-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-5-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327677740.26983.183.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/11] ocaml, libxl: support "private" fields
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> The changeset
>   24378:b4365e2c2595  libxl: idl: support new "private" type attribute
> is not complete.  Actually using this feature does not work because
> the ocaml idl generator does not know about it.
> 
> So add that support.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

I acked this one last time round.

Ian.

> ---
>  tools/ocaml/libs/xl/genwrap.py |    8 ++++++++
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/ocaml/libs/xl/genwrap.py b/tools/ocaml/libs/xl/genwrap.py
> index 2e65aec..00583d2 100644
> --- a/tools/ocaml/libs/xl/genwrap.py
> +++ b/tools/ocaml/libs/xl/genwrap.py
> @@ -93,6 +93,8 @@ def gen_ocaml_ml(ty, interface, indent=""):
>              s += "\t{\n"
>              
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              x = ocaml_instance_of(f.type, f.name)
>              x = x.replace("\n", "\n\t\t")
>              s += "\t\t" + x + ";\n"
> @@ -148,6 +150,8 @@ def c_val(ty, c, o, indent="", parent = None):
>      elif isinstance(ty, libxltypes.Aggregate) and (parent is None):
>          n = 0
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              s += "%s\n" % c_val(f.type, "%s->%s" % (c, f.name), "Field(%s, %d)" % (o,n), parent="%s->" % (c))
>              n = n + 1
>      else:
> @@ -212,6 +216,8 @@ def ocaml_Val(ty, o, c, indent="", parent = None):
>          
>          n = 0
>          for f in ty.fields:
> +            if f.type.private:
> +                continue
>              s += "\n"
>              s += "\t%s\n" % ocaml_Val(f.type, "%s_field" % ty.rawname, "%s->%s" % (c,f.name), parent="%s->" % c)
>              s += "\tStore_field(%s, %d, %s);\n" % (o, n, "%s_field" % ty.rawname)
> @@ -290,6 +296,8 @@ if __name__ == '__main__':
>      cinc.write(autogen_header("/*", "*/"))
>  
>      for ty in types:
> +        if ty.private:
> +            continue
>          #sys.stdout.write(" TYPE    %-20s " % ty.rawname)
>          ml.write(gen_ocaml_ml(ty, False))
>          ml.write("\n")



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:23:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:23:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqneK-0007MZ-2f; Fri, 27 Jan 2012 15:23:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqneI-0007M6-FR
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:23:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327677759!52013241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21153 invoked from network); 27 Jan 2012 15:22:39 -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;
	27 Jan 2012 15:22:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:22: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, 27 Jan 2012 15:22:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:22:55 +0000
In-Reply-To: <1327598457-28261-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327677775.26983.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 09/11] libxl: New convenience macro
 CONTAINER_OF
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> Provide a convenient and type-safe wrapper which does the correct
> dance to subtract offsetof.  This is very similar to the
> "container_of" macro in the Linux kernel, but it has an additional
> feature that instead of the type argument you may also pass an
> expression of that type; this makes initialising a variable with
> CONTAINER_OF easier.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked.

> ---
>  tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 044eeb4..095dbce 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1235,6 +1235,35 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
>   * Convenience macros.
>   */
>  
> +/*
> + * CONTAINER_OF work like this.  Given:
> + *    typedef struct {
> + *      ...
> + *      member_type member_name;
> + *      ...
> + *    } outer_type;
> + *    outer_type outer, *outer_var;
> + *    member_type *inner_ptr = &outer->member_name;
> + *
> + * Then, effectively:
> + *    outer_type *CONTAINER_OF(member_type *inner_ptr,
> + *                             *outer_var, // or type name for outer_type
> + *                             member_name);
> + *
> + * So that:
> + *    CONTAINER_OF(inner_ptr, *outer_var, member_name) == &outer
> + *    CONTAINER_OF(inner_ptr, outer_type, member_name) == &outer
> + */
> +#define CONTAINER_OF(inner_ptr, outer, member_name)                     \
> +    ({                                                                  \
> +        typeof(outer) *container_of_;                                   \
> +        container_of_ = (void*)((char*)(inner_ptr) -                    \
> +                                offsetof(typeof(outer), member_name));  \
> +        (void)(&container_of_->member_name ==                           \
> +               (typeof(inner_ptr))0) /* type check */;                  \
> +        container_of_;                                                  \
> +    })
> +
>  
>  /*
>   * All of these assume (or define)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:23:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:23:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqneK-0007MZ-2f; Fri, 27 Jan 2012 15:23:36 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqneI-0007M6-FR
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:23:34 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327677759!52013241!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21153 invoked from network); 27 Jan 2012 15:22:39 -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;
	27 Jan 2012 15:22:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334736"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:22: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, 27 Jan 2012 15:22:55 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:22:55 +0000
In-Reply-To: <1327598457-28261-10-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327598457-28261-10-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327677775.26983.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 09/11] libxl: New convenience macro
 CONTAINER_OF
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> Provide a convenient and type-safe wrapper which does the correct
> dance to subtract offsetof.  This is very similar to the
> "container_of" macro in the Linux kernel, but it has an additional
> feature that instead of the type argument you may also pass an
> expression of that type; this makes initialising a variable with
> CONTAINER_OF easier.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked.

> ---
>  tools/libxl/libxl_internal.h |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 044eeb4..095dbce 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1235,6 +1235,35 @@ _hidden void libxl__ao__destroy(libxl_ctx*, libxl__ao *ao);
>   * Convenience macros.
>   */
>  
> +/*
> + * CONTAINER_OF work like this.  Given:
> + *    typedef struct {
> + *      ...
> + *      member_type member_name;
> + *      ...
> + *    } outer_type;
> + *    outer_type outer, *outer_var;
> + *    member_type *inner_ptr = &outer->member_name;
> + *
> + * Then, effectively:
> + *    outer_type *CONTAINER_OF(member_type *inner_ptr,
> + *                             *outer_var, // or type name for outer_type
> + *                             member_name);
> + *
> + * So that:
> + *    CONTAINER_OF(inner_ptr, *outer_var, member_name) == &outer
> + *    CONTAINER_OF(inner_ptr, outer_type, member_name) == &outer
> + */
> +#define CONTAINER_OF(inner_ptr, outer, member_name)                     \
> +    ({                                                                  \
> +        typeof(outer) *container_of_;                                   \
> +        container_of_ = (void*)((char*)(inner_ptr) -                    \
> +                                offsetof(typeof(outer), member_name));  \
> +        (void)(&container_of_->member_name ==                           \
> +               (typeof(inner_ptr))0) /* type check */;                  \
> +        container_of_;                                                  \
> +    })
> +
>  
>  /*
>   * All of these assume (or define)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:25:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqngQ-0007W1-M2; Fri, 27 Jan 2012 15:25:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqngP-0007Vq-Gf
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:25:45 +0000
Received: from [85.158.139.83:33087] by server-2.bemta-5.messagelabs.com id
	66/EE-07121-8F1C22F4; Fri, 27 Jan 2012 15:25:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327677944!12683018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19370 invoked from network); 27 Jan 2012 15:25:44 -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;
	27 Jan 2012 15:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:25: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, 27 Jan 2012 15:25:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:25:43 +0000
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327677943.26983.186.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 v8 00/11] libxl: 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, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> There are a couple of hopefully uncontroversial new patches on the
> front of this series:
> 
>  01/11 .gitignore/.hgignore: New names for ioemu dirs, seabios
>  02/11 xl: fix a couple of memory leaks
> 
> The remainder of the series is very similar to previous versions.
>  - Changes have been made as discussed on the list, plus:

Given that I'm happy to:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

>  - One memory leak (missing GC_FREE) is fixed;
>  - I have moved a some of the destruction in xl's domain_create to
>    reduce false positives from valgrind;
>  - Fixed the ocaml stubs to pass the new ao argument (currently
>    these stubs are synchronous, which is not ideal but it's not
>    clear what an ocaml caller would want).
> 
>  03/11 libxl: New API for providing OS events to libxl
>  04/11 ocaml, libxl: support "private" fields
>  05/11 libxl: New event generation API
>  06/11 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
>  07/11 libxl: Permit multithreaded event waiting
>  08/11 libxl: Asynchronous/long-running operation infrastructure
>  09/11 libxl: New convenience macro CONTAINER_OF
>  10/11 libxl: Introduce libxl__ev_devstate
>  11/11 libxl: Convert to asynchronous: device removal
> 
> The series has also been rebased and retested.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 27 15:25:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:25:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqngQ-0007W1-M2; Fri, 27 Jan 2012 15:25:46 +0000
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RqngP-0007Vq-Gf
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:25:45 +0000
Received: from [85.158.139.83:33087] by server-2.bemta-5.messagelabs.com id
	66/EE-07121-8F1C22F4; Fri, 27 Jan 2012 15:25:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327677944!12683018!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19370 invoked from network); 27 Jan 2012 15:25:44 -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;
	27 Jan 2012 15:25:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334819"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:25: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, 27 Jan 2012 15:25:44 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:25:43 +0000
In-Reply-To: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327677943.26983.186.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 v8 00/11] libxl: 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, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> There are a couple of hopefully uncontroversial new patches on the
> front of this series:
> 
>  01/11 .gitignore/.hgignore: New names for ioemu dirs, seabios
>  02/11 xl: fix a couple of memory leaks
> 
> The remainder of the series is very similar to previous versions.
>  - Changes have been made as discussed on the list, plus:

Given that I'm happy to:
Acked-by: Ian Campbell <ian.campbell@citrix.com>

>  - One memory leak (missing GC_FREE) is fixed;
>  - I have moved a some of the destruction in xl's domain_create to
>    reduce false positives from valgrind;
>  - Fixed the ocaml stubs to pass the new ao argument (currently
>    these stubs are synchronous, which is not ideal but it's not
>    clear what an ocaml caller would want).
> 
>  03/11 libxl: New API for providing OS events to libxl
>  04/11 ocaml, libxl: support "private" fields
>  05/11 libxl: New event generation API
>  06/11 libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
>  07/11 libxl: Permit multithreaded event waiting
>  08/11 libxl: Asynchronous/long-running operation infrastructure
>  09/11 libxl: New convenience macro CONTAINER_OF
>  10/11 libxl: Introduce libxl__ev_devstate
>  11/11 libxl: Convert to asynchronous: device removal
> 
> The series has also been rebased and retested.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 27 15:26:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:26:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqnhL-0007bR-3z; Fri, 27 Jan 2012 15:26:43 +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 1RqnhJ-0007ae-Og
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:26:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327677994!8422161!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29101 invoked from network); 27 Jan 2012 15:26:34 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-21.messagelabs.com with SMTP;
	27 Jan 2012 15:26:34 -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
	q0RFQWok010047; Fri, 27 Jan 2012 15:26:32 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 q0RFQW7T032312; 
	Fri, 27 Jan 2012 10:26:32 -0500
Message-ID: <4F22C229.5070508@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:26:33 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-11-git-send-email-dgdegra@tycho.nsa.gov>
	<1327658669.26983.148.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327658669.26983.148.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/24] mini-os: create app-specific
	configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/27/2012 05:04 AM, Ian Campbell wrote:
> On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
>> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
>> code, create CONFIG_ items for features and use application-specific
>> configuration files to enable or disable the features.
>>
>> The configuration flags are currently added to the compiler command
>> line; as the number of flags grows this may need to move to a header.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
>> diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
>> new file mode 100644
>> index 0000000..e69de29
>> diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
>> new file mode 100644
>> index 0000000..e69de29
> 
> These are new empty files? That's ok -- just wanted to check there
> wasn't some patch weirdness happening.
> 
> Ian.
> 
> 

Yes; the C and CAML stub domains just use the defaults.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:26:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:26:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqnhL-0007bR-3z; Fri, 27 Jan 2012 15:26:43 +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 1RqnhJ-0007ae-Og
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:26:41 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327677994!8422161!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29101 invoked from network); 27 Jan 2012 15:26:34 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-6.tower-21.messagelabs.com with SMTP;
	27 Jan 2012 15:26:34 -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
	q0RFQWok010047; Fri, 27 Jan 2012 15:26:32 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 q0RFQW7T032312; 
	Fri, 27 Jan 2012 10:26:32 -0500
Message-ID: <4F22C229.5070508@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:26:33 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-11-git-send-email-dgdegra@tycho.nsa.gov>
	<1327658669.26983.148.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327658669.26983.148.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 10/24] mini-os: create app-specific
	configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/27/2012 05:04 AM, Ian Campbell wrote:
> On Thu, 2012-01-26 at 19:44 +0000, Daniel De Graaf wrote:
>> Instead of using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
>> code, create CONFIG_ items for features and use application-specific
>> configuration files to enable or disable the features.
>>
>> The configuration flags are currently added to the compiler command
>> line; as the number of flags grows this may need to move to a header.
>>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
>> diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
>> new file mode 100644
>> index 0000000..e69de29
>> diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
>> new file mode 100644
>> index 0000000..e69de29
> 
> These are new empty files? That's ok -- just wanted to check there
> wasn't some patch weirdness happening.
> 
> Ian.
> 
> 

Yes; the C and CAML stub domains just use the defaults.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:28:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:28:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqnj5-0007mU-L1; Fri, 27 Jan 2012 15:28: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 1Rqnj4-0007ls-5g
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:28:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327678103!8472003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8812 invoked from network); 27 Jan 2012 15:28:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 15:28:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:28:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 15:28:05 +0000
Date: Fri, 27 Jan 2012 15:29:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120127140234.GA32469@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201271427080.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120127140234.GA32469@phenom.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 26, 2012 at 12:43:26PM +0000, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  drivers/tty/hvc/hvc_xen.c          |   86 +++++++++++++++++++++++++++++-------
> >  include/xen/interface/hvm/params.h |    6 ++-
> >  2 files changed, 75 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index 52fdf60..dd6641f 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -24,9 +24,12 @@
> >  #include <linux/init.h>
> >  #include <linux/types.h>
> >  
> > +#include <asm/io.h>
> >  #include <asm/xen/hypervisor.h>
> >  
> >  #include <xen/xen.h>
> > +#include <xen/interface/xen.h>
> > +#include <xen/hvm.h>
> >  #include <xen/page.h>
> >  #include <xen/events.h>
> >  #include <xen/interface/io/console.h>
> > @@ -42,9 +45,13 @@ static int xencons_irq;
> >  /* ------------------------------------------------------------------ */
> >  
> >  static unsigned long console_pfn = ~0ul;
> > +static unsigned int console_evtchn = ~0ul;
> > +static struct xencons_interface *xencons_if = NULL;
> >  
> >  static inline struct xencons_interface *xencons_interface(void)
> >  {
> > +	if (xencons_if != NULL)
> > +		return xencons_if;
> >  	if (console_pfn == ~0ul)
> >  		return mfn_to_virt(xen_start_info->console.domU.mfn);
> >  	else
> > @@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
> >  static inline void notify_daemon(void)
> >  {
> >  	/* Use evtchn: this is called early, before irq is set up. */
> > -	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> > +	if (console_evtchn == ~0ul)
> > +		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> > +	else
> > +		notify_remote_via_evtchn(console_evtchn);
> >  }
> >  
> >  static int __write_console(const char *data, int len)
> > @@ -157,28 +167,65 @@ static struct hv_ops dom0_hvc_ops = {
> >  	.notifier_hangup = notifier_hangup_irq,
> >  };
> >  
> > +static int xen_hvm_console_init(void)
> > +{
> > +	int r;
> > +	uint64_t v = 0;
> > +	unsigned long mfn;
> > +
> > +	if (!xen_hvm_domain())
> > +		return -ENODEV;
> > +
> > +	if (xencons_if != NULL)
> > +		return -EBUSY;
> > +
> > +	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> > +	if (r < 0)
> > +		return -ENODEV;
> > +	console_evtchn = v;
> > +	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> > +	if (r < 0)
> > +		return -ENODEV;
> 
> If we fail here, the console_evtchn is still going to be set
> meaning that "notify_daemon"  will use the event channel. Thought
> I can't think of the notify daemon being called after the init had
> failed so this might not be an issue.
> 
> > +	mfn = v;
> > +	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > +	if (xencons_if == NULL)
> > +		return -ENODEV;
> 
> Ditto. If we fail, we have the 'console_evtchn' set to something
> else than ~0UL.

Like you wrote, I think it doesn't matter.



> > +	return 0;
> > +}
> > +
> >  static int __init xen_hvc_init(void)
> >  {
> >  	struct hvc_struct *hp;
> >  	struct hv_ops *ops;
> > +	int r;
> >  
> > -	if (!xen_pv_domain())
> > +	if (!xen_domain())
> > +		return -ENODEV;
> > +
> > +	if (xen_pv_domain() && !xen_initial_domain() &&
> > +			!xen_start_info->console.domU.evtchn)
> 
> Ewww.. What about just leaving the check:
> >  		return -ENODEV;
> >  
> >  	if (xen_initial_domain()) {
> >  		ops = &dom0_hvc_ops;
> >  		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> >  	} else {
> > -		if (!xen_start_info->console.domU.evtchn)
> > -			return -ENODEV;
> 
> this one as 'if (xen_pv_domain()) && !xen-..)
> 
> That might make the code nicer to read?

Yes, good idea.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:28:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:28:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqnj5-0007mU-L1; Fri, 27 Jan 2012 15:28: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 1Rqnj4-0007ls-5g
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:28:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327678103!8472003!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8812 invoked from network); 27 Jan 2012 15:28:24 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 15:28:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10334879"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:28:06 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 15:28:05 +0000
Date: Fri, 27 Jan 2012 15:29:06 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120127140234.GA32469@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201271427080.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120127140234.GA32469@phenom.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 26, 2012 at 12:43:26PM +0000, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  drivers/tty/hvc/hvc_xen.c          |   86 +++++++++++++++++++++++++++++-------
> >  include/xen/interface/hvm/params.h |    6 ++-
> >  2 files changed, 75 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index 52fdf60..dd6641f 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -24,9 +24,12 @@
> >  #include <linux/init.h>
> >  #include <linux/types.h>
> >  
> > +#include <asm/io.h>
> >  #include <asm/xen/hypervisor.h>
> >  
> >  #include <xen/xen.h>
> > +#include <xen/interface/xen.h>
> > +#include <xen/hvm.h>
> >  #include <xen/page.h>
> >  #include <xen/events.h>
> >  #include <xen/interface/io/console.h>
> > @@ -42,9 +45,13 @@ static int xencons_irq;
> >  /* ------------------------------------------------------------------ */
> >  
> >  static unsigned long console_pfn = ~0ul;
> > +static unsigned int console_evtchn = ~0ul;
> > +static struct xencons_interface *xencons_if = NULL;
> >  
> >  static inline struct xencons_interface *xencons_interface(void)
> >  {
> > +	if (xencons_if != NULL)
> > +		return xencons_if;
> >  	if (console_pfn == ~0ul)
> >  		return mfn_to_virt(xen_start_info->console.domU.mfn);
> >  	else
> > @@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
> >  static inline void notify_daemon(void)
> >  {
> >  	/* Use evtchn: this is called early, before irq is set up. */
> > -	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> > +	if (console_evtchn == ~0ul)
> > +		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> > +	else
> > +		notify_remote_via_evtchn(console_evtchn);
> >  }
> >  
> >  static int __write_console(const char *data, int len)
> > @@ -157,28 +167,65 @@ static struct hv_ops dom0_hvc_ops = {
> >  	.notifier_hangup = notifier_hangup_irq,
> >  };
> >  
> > +static int xen_hvm_console_init(void)
> > +{
> > +	int r;
> > +	uint64_t v = 0;
> > +	unsigned long mfn;
> > +
> > +	if (!xen_hvm_domain())
> > +		return -ENODEV;
> > +
> > +	if (xencons_if != NULL)
> > +		return -EBUSY;
> > +
> > +	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> > +	if (r < 0)
> > +		return -ENODEV;
> > +	console_evtchn = v;
> > +	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> > +	if (r < 0)
> > +		return -ENODEV;
> 
> If we fail here, the console_evtchn is still going to be set
> meaning that "notify_daemon"  will use the event channel. Thought
> I can't think of the notify daemon being called after the init had
> failed so this might not be an issue.
> 
> > +	mfn = v;
> > +	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > +	if (xencons_if == NULL)
> > +		return -ENODEV;
> 
> Ditto. If we fail, we have the 'console_evtchn' set to something
> else than ~0UL.

Like you wrote, I think it doesn't matter.



> > +	return 0;
> > +}
> > +
> >  static int __init xen_hvc_init(void)
> >  {
> >  	struct hvc_struct *hp;
> >  	struct hv_ops *ops;
> > +	int r;
> >  
> > -	if (!xen_pv_domain())
> > +	if (!xen_domain())
> > +		return -ENODEV;
> > +
> > +	if (xen_pv_domain() && !xen_initial_domain() &&
> > +			!xen_start_info->console.domU.evtchn)
> 
> Ewww.. What about just leaving the check:
> >  		return -ENODEV;
> >  
> >  	if (xen_initial_domain()) {
> >  		ops = &dom0_hvc_ops;
> >  		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> >  	} else {
> > -		if (!xen_start_info->console.domU.evtchn)
> > -			return -ENODEV;
> 
> this one as 'if (xen_pv_domain()) && !xen-..)
> 
> That might make the code nicer to read?

Yes, good idea.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:43:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqnx4-00084z-3e; Fri, 27 Jan 2012 15:42: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 1Rqnx2-00084u-Ti
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:42:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327678970!12255612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24648 invoked from network); 27 Jan 2012 15:42:50 -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;
	27 Jan 2012 15:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10335605"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:42:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 15:42:49 +0000
Date: Fri, 27 Jan 2012 15:43:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F22B7E2.9070902@redhat.com>
Message-ID: <alpine.DEB.2.00.1201271540241.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22B7E2.9070902@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
 expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> > default to INT64_MAX instead of INT32_MAX.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > ---
> >   qemu-timer.c |   10 ++++------
> >   1 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/qemu-timer.c b/qemu-timer.c
> > index cd026c6..648db1d 100644
> > --- a/qemu-timer.c
> > +++ b/qemu-timer.c
> > @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
> >
> >   static int64_t qemu_next_alarm_deadline(void)
> >   {
> > -    int64_t delta;
> > +    int64_t delta = INT64_MAX;
> 
> I'm worried of overflows elsewhere...

I think that you are right: mm_rearm_timer and win32_rearm_timer would
overflow.
I'll just repost the patch using INT32_MAX.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:43:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:43:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqnx4-00084z-3e; Fri, 27 Jan 2012 15:42: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 1Rqnx2-00084u-Ti
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:42:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327678970!12255612!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24648 invoked from network); 27 Jan 2012 15:42:50 -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;
	27 Jan 2012 15:42:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10335605"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:42:49 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 15:42:49 +0000
Date: Fri, 27 Jan 2012 15:43:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F22B7E2.9070902@redhat.com>
Message-ID: <alpine.DEB.2.00.1201271540241.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22B7E2.9070902@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
 expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> > default to INT64_MAX instead of INT32_MAX.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > ---
> >   qemu-timer.c |   10 ++++------
> >   1 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/qemu-timer.c b/qemu-timer.c
> > index cd026c6..648db1d 100644
> > --- a/qemu-timer.c
> > +++ b/qemu-timer.c
> > @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
> >
> >   static int64_t qemu_next_alarm_deadline(void)
> >   {
> > -    int64_t delta;
> > +    int64_t delta = INT64_MAX;
> 
> I'm worried of overflows elsewhere...

I think that you are right: mm_rearm_timer and win32_rearm_timer would
overflow.
I'll just repost the patch using INT32_MAX.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:44:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:44:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqnxz-00087h-I8; Fri, 27 Jan 2012 15:43:55 +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 1Rqnxx-00087D-HX
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:43:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327679027!12592951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1313 invoked from network); 27 Jan 2012 15:43:47 -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;
	27 Jan 2012 15:43:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10335743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:43: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; Fri, 27 Jan 2012 15:43:46 +0000
Date: Fri, 27 Jan 2012 15:44:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F22B81E.1030407@redhat.com>
Message-ID: <alpine.DEB.2.00.1201271544390.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22B81E.1030407@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > There is no reason why the minimum timeout should be 1sec, it could
> > easily be 1h and we would save lots of cpu cycles.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > ---
> >   qemu-timer.c |    2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/qemu-timer.c b/qemu-timer.c
> > index 648db1d..b792a32 100644
> > --- a/qemu-timer.c
> > +++ b/qemu-timer.c
> > @@ -844,6 +844,6 @@ fail:
> >
> >   int qemu_calculate_timeout(void)
> >   {
> > -    return 1000;
> > +    return 1000*60*60;
> >   }
> >
> 
> This might break Windows networking, but I'm going to fix it before 1.1 
> anyway.
> 
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
 
Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:44:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:44:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqnxz-00087h-I8; Fri, 27 Jan 2012 15:43:55 +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 1Rqnxx-00087D-HX
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:43:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327679027!12592951!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1313 invoked from network); 27 Jan 2012 15:43:47 -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;
	27 Jan 2012 15:43:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10335743"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:43: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; Fri, 27 Jan 2012 15:43:46 +0000
Date: Fri, 27 Jan 2012 15:44:47 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F22B81E.1030407@redhat.com>
Message-ID: <alpine.DEB.2.00.1201271544390.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-5-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22B81E.1030407@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 5/5] qemu_calculate_timeout: increase
 minimum timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > There is no reason why the minimum timeout should be 1sec, it could
> > easily be 1h and we would save lots of cpu cycles.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > ---
> >   qemu-timer.c |    2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/qemu-timer.c b/qemu-timer.c
> > index 648db1d..b792a32 100644
> > --- a/qemu-timer.c
> > +++ b/qemu-timer.c
> > @@ -844,6 +844,6 @@ fail:
> >
> >   int qemu_calculate_timeout(void)
> >   {
> > -    return 1000;
> > +    return 1000*60*60;
> >   }
> >
> 
> This might break Windows networking, but I'm going to fix it before 1.1 
> anyway.
> 
> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
 
Thanks!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:49:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqo2t-0008Pi-Dd; Fri, 27 Jan 2012 15:48: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 1Rqo2s-0008PH-Oj
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:48:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327679332!12685868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27245 invoked from network); 27 Jan 2012 15:48:52 -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;
	27 Jan 2012 15:48:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10336014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:48: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, 27 Jan 2012 15:48: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 1Rqo2g-0004NO-Bm;
	Fri, 27 Jan 2012 15:48:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rqo2g-00022V-3h;
	Fri, 27 Jan 2012 15:48:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11643-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:48:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11643: 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 11643 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11643/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 11601
 test-i386-i386-win           14 guest-start.2                fail   like 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 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  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e2722b24dc09
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e2722b24dc09
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 e2722b24dc09
+ branch=xen-unstable
+ revision=e2722b24dc09
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e2722b24dc09 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 30 changesets with 70 changes to 42 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:49:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:49:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqo2t-0008Pi-Dd; Fri, 27 Jan 2012 15:48: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 1Rqo2s-0008PH-Oj
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:48:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327679332!12685868!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27245 invoked from network); 27 Jan 2012 15:48:52 -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;
	27 Jan 2012 15:48:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10336014"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:48: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, 27 Jan 2012 15:48: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 1Rqo2g-0004NO-Bm;
	Fri, 27 Jan 2012 15:48:46 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rqo2g-00022V-3h;
	Fri, 27 Jan 2012 15:48:46 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11643-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 15:48:46 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11643: 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 11643 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11643/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin 14 guest-localmigrate/x10    fail REGR. vs. 11601
 test-i386-i386-win           14 guest-start.2                fail   like 11601

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 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  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  e2722b24dc09
baseline version:
 xen                  4271634e4c86

------------------------------------------------------------
People who touched revisions under test:
  Adin Scanneell <adin@scannell.ca>
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andres Lagar-Cavilla <andres@scannell.ca>
  George Dunlap <george.dunlap@eu.citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Tim Deegan <tim@xen.org>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 fail    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable
+ revision=e2722b24dc09
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 e2722b24dc09
+ branch=xen-unstable
+ revision=e2722b24dc09
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-unstable.hg
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-unstable.hg
+ hg push -r e2722b24dc09 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 30 changesets with 70 changes to 42 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:50:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqo3o-0008VX-2u; Fri, 27 Jan 2012 15:49: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 1Rqo3m-0008V0-BO
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327679386!12300000!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28798 invoked from network); 27 Jan 2012 15:49:47 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 15:49:46 -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
	q0RFnhok016268; Fri, 27 Jan 2012 15:49: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 q0RFnhJv001267; 
	Fri, 27 Jan 2012 10:49:43 -0500
Message-ID: <4F22C798.2080801@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:49:44 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1327669569.26983.178.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327669569.26983.178.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/27/2012 08:06 AM, Ian Campbell wrote:
> On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
>> The symbol _LINUX_LIST_H collides with other header files.
> 
> Hrm mini-os is supposed to have been BSD licensed since
> 19712:7a215fae6f1f and that symbol name is *rather* suspicious.
> 
> The thread associated with that commit[0] suggests that everything GPL
> had been rewritten but I suspect that due to the lack of GPL header this
> file was missed.
> 
> This effectively means that any work combined with mini-os was GPL
> rather than BSD as might reasonably have been expected. I believe
> everything in-tree which we link with mini-os (the stubdom/ tree) is GPL
> or GPL-compatible but this has laid rather a nasty trap for anyone else
> using mini-os and I think we should fix it ASAP. Below is a patch which
> switches to using the same BSD sys/queue.h list macros as we use in
> libxl.

I'm assuming you are going to push this patch in prior to my series, so I'll
try to rebase on top of it. Currently, the Makefile changes seem to be broken:

make[3]: *** No rule to make target `/home/daniel/git/xen/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery', needed by `_libxl_list.h'.  Stop.

> 
> Presumably you came across another file which used _LINUX_LIST_H which
> clashed? Out of interest what was it?
> 
> Ian.

This symbol is used as the include guard in tools/xenstore/list.h.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:50:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:50:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqo3o-0008VX-2u; Fri, 27 Jan 2012 15:49: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 1Rqo3m-0008V0-BO
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:49:54 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327679386!12300000!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28798 invoked from network); 27 Jan 2012 15:49:47 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 15:49:46 -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
	q0RFnhok016268; Fri, 27 Jan 2012 15:49: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 q0RFnhJv001267; 
	Fri, 27 Jan 2012 10:49:43 -0500
Message-ID: <4F22C798.2080801@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 10:49:44 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Ian Campbell <Ian.Campbell@citrix.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1327669569.26983.178.camel@zakaz.uk.xensource.com>
In-Reply-To: <1327669569.26983.178.camel@zakaz.uk.xensource.com>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/27/2012 08:06 AM, Ian Campbell wrote:
> On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
>> The symbol _LINUX_LIST_H collides with other header files.
> 
> Hrm mini-os is supposed to have been BSD licensed since
> 19712:7a215fae6f1f and that symbol name is *rather* suspicious.
> 
> The thread associated with that commit[0] suggests that everything GPL
> had been rewritten but I suspect that due to the lack of GPL header this
> file was missed.
> 
> This effectively means that any work combined with mini-os was GPL
> rather than BSD as might reasonably have been expected. I believe
> everything in-tree which we link with mini-os (the stubdom/ tree) is GPL
> or GPL-compatible but this has laid rather a nasty trap for anyone else
> using mini-os and I think we should fix it ASAP. Below is a patch which
> switches to using the same BSD sys/queue.h list macros as we use in
> libxl.

I'm assuming you are going to push this patch in prior to my series, so I'll
try to rebase on top of it. Currently, the Makefile changes seem to be broken:

make[3]: *** No rule to make target `/home/daniel/git/xen/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery', needed by `_libxl_list.h'.  Stop.

> 
> Presumably you came across another file which used _LINUX_LIST_H which
> clashed? Out of interest what was it?
> 
> Ian.

This symbol is used as the include guard in tools/xenstore/list.h.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:52:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqo6P-0000S9-Ld; Fri, 27 Jan 2012 15:52: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 1Rqo6O-0000Rs-3q
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:52:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327679549!12664310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7022 invoked from network); 27 Jan 2012 15:52:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 15:52:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10336466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:52: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; Fri, 27 Jan 2012 15:52:29 +0000
Date: Fri, 27 Jan 2012 15:53:30 +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.1201271540241.3196@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201271551140.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22B7E2.9070902@redhat.com>
	<alpine.DEB.2.00.1201271540241.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
 expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Stefano Stabellini wrote:
> On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> > On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > > Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> > > default to INT64_MAX instead of INT32_MAX.
> > >
> > > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > > ---
> > >   qemu-timer.c |   10 ++++------
> > >   1 files changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/qemu-timer.c b/qemu-timer.c
> > > index cd026c6..648db1d 100644
> > > --- a/qemu-timer.c
> > > +++ b/qemu-timer.c
> > > @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
> > >
> > >   static int64_t qemu_next_alarm_deadline(void)
> > >   {
> > > -    int64_t delta;
> > > +    int64_t delta = INT64_MAX;
> > 
> > I'm worried of overflows elsewhere...
> 
> I think that you are right: mm_rearm_timer and win32_rearm_timer would
> overflow.
> I'll just repost the patch using INT32_MAX.
 
Actually it is better to fix mm_rearm_timer and win32_rearm_timer so
that they won't overflow anymore.
I'll add a patch to do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:52:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:52:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqo6P-0000S9-Ld; Fri, 27 Jan 2012 15:52: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 1Rqo6O-0000Rs-3q
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:52:36 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327679549!12664310!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7022 invoked from network); 27 Jan 2012 15:52:30 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 15:52:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10336466"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:52: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; Fri, 27 Jan 2012 15:52:29 +0000
Date: Fri, 27 Jan 2012 15:53:30 +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.1201271540241.3196@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201271551140.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-4-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22B7E2.9070902@redhat.com>
	<alpine.DEB.2.00.1201271540241.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"anthony@codemonkey.ws" <anthony@codemonkey.ws>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v2 4/5] qemu_next_alarm_deadline: check the
 expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Stefano Stabellini wrote:
> On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> > On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > > Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
> > > default to INT64_MAX instead of INT32_MAX.
> > >
> > > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > > ---
> > >   qemu-timer.c |   10 ++++------
> > >   1 files changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/qemu-timer.c b/qemu-timer.c
> > > index cd026c6..648db1d 100644
> > > --- a/qemu-timer.c
> > > +++ b/qemu-timer.c
> > > @@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
> > >
> > >   static int64_t qemu_next_alarm_deadline(void)
> > >   {
> > > -    int64_t delta;
> > > +    int64_t delta = INT64_MAX;
> > 
> > I'm worried of overflows elsewhere...
> 
> I think that you are right: mm_rearm_timer and win32_rearm_timer would
> overflow.
> I'll just repost the patch using INT32_MAX.
 
Actually it is better to fix mm_rearm_timer and win32_rearm_timer so
that they won't overflow anymore.
I'll add a patch to do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:54:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:54:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqo7F-0000X8-3e; Fri, 27 Jan 2012 15:53: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 1Rqo7D-0000WX-OB
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:53:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327679580!63572803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6260 invoked from network); 27 Jan 2012 15:53:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 15:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10336485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:53:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 15:53:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 15:53:08 +0000
In-Reply-To: <4F22C798.2080801@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1327669569.26983.178.camel@zakaz.uk.xensource.com>
	<4F22C798.2080801@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327679589.26983.191.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 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 15:49 +0000, Daniel De Graaf wrote:
> On 01/27/2012 08:06 AM, Ian Campbell wrote:
> > On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> >> The symbol _LINUX_LIST_H collides with other header files.
> > 
> > Hrm mini-os is supposed to have been BSD licensed since
> > 19712:7a215fae6f1f and that symbol name is *rather* suspicious.
> > 
> > The thread associated with that commit[0] suggests that everything GPL
> > had been rewritten but I suspect that due to the lack of GPL header this
> > file was missed.
> > 
> > This effectively means that any work combined with mini-os was GPL
> > rather than BSD as might reasonably have been expected. I believe
> > everything in-tree which we link with mini-os (the stubdom/ tree) is GPL
> > or GPL-compatible but this has laid rather a nasty trap for anyone else
> > using mini-os and I think we should fix it ASAP. Below is a patch which
> > switches to using the same BSD sys/queue.h list macros as we use in
> > libxl.
> 
> I'm assuming you are going to push this patch in prior to my series, so I'll
> try to rebase on top of it. Currently, the Makefile changes seem to be broken:
> 
> make[3]: *** No rule to make target `/home/daniel/git/xen/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery', needed by `_libxl_list.h'.  Stop.

Did you use a version of patch which handles renames? Does
tools/include/xen-external/... etc exist after you applied the patch?

> > Presumably you came across another file which used _LINUX_LIST_H which
> > clashed? Out of interest what was it?
> > 
> > Ian.
> 
> This symbol is used as the include guard in tools/xenstore/list.h.

That thing is everywhere...

At least xenstore is (L)GPL...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 15:54:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 15:54:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqo7F-0000X8-3e; Fri, 27 Jan 2012 15:53: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 1Rqo7D-0000WX-OB
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 15:53:27 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1327679580!63572803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6260 invoked from network); 27 Jan 2012 15:53:01 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 15:53:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10336485"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 15:53:09 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Fri, 27 Jan 2012 15:53:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 15:53:08 +0000
In-Reply-To: <4F22C798.2080801@tycho.nsa.gov>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1327669569.26983.178.camel@zakaz.uk.xensource.com>
	<4F22C798.2080801@tycho.nsa.gov>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327679589.26983.191.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 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 15:49 +0000, Daniel De Graaf wrote:
> On 01/27/2012 08:06 AM, Ian Campbell wrote:
> > On Thu, 2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:
> >> The symbol _LINUX_LIST_H collides with other header files.
> > 
> > Hrm mini-os is supposed to have been BSD licensed since
> > 19712:7a215fae6f1f and that symbol name is *rather* suspicious.
> > 
> > The thread associated with that commit[0] suggests that everything GPL
> > had been rewritten but I suspect that due to the lack of GPL header this
> > file was missed.
> > 
> > This effectively means that any work combined with mini-os was GPL
> > rather than BSD as might reasonably have been expected. I believe
> > everything in-tree which we link with mini-os (the stubdom/ tree) is GPL
> > or GPL-compatible but this has laid rather a nasty trap for anyone else
> > using mini-os and I think we should fix it ASAP. Below is a patch which
> > switches to using the same BSD sys/queue.h list macros as we use in
> > libxl.
> 
> I'm assuming you are going to push this patch in prior to my series, so I'll
> try to rebase on top of it. Currently, the Makefile changes seem to be broken:
> 
> make[3]: *** No rule to make target `/home/daniel/git/xen/tools/libxl/../../tools/include/xen-external/bsd-sys-queue-h-seddery', needed by `_libxl_list.h'.  Stop.

Did you use a version of patch which handles renames? Does
tools/include/xen-external/... etc exist after you applied the patch?

> > Presumably you came across another file which used _LINUX_LIST_H which
> > clashed? Out of interest what was it?
> > 
> > Ian.
> 
> This symbol is used as the include guard in tools/xenstore/list.h.

That thing is everywhere...

At least xenstore is (L)GPL...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 16:04:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 16:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqoHc-0002GN-GU; Fri, 27 Jan 2012 16:04:12 +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 1RqoHa-0002GI-AP
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 16:04:10 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327680241!3381922!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25244 invoked from network); 27 Jan 2012 16:04:02 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 16:04:02 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q0RG3uPr002286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 27 Jan 2012 11:03:56 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0RG3tEg002284;
	Fri, 27 Jan 2012 11:03:55 -0500
Date: Fri, 27 Jan 2012 12:03:55 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127160355.GA566@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 12:43:27PM +0000, Stefano Stabellini wrote:
> This patch implements support for multiple consoles:
> consoles other than the first one are setup using the traditional xenbus
> and grant-table based mechanism.
> We use a list to keep track of the allocated consoles, we don't
> expect too many of them anyway.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
>  1 files changed, 383 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index dd6641f..97732fb 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -23,6 +23,7 @@
>  #include <linux/err.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
> +#include <linux/list.h>
>  
>  #include <asm/io.h>
>  #include <asm/xen/hypervisor.h>
> @@ -30,47 +31,69 @@
>  #include <xen/xen.h>
>  #include <xen/interface/xen.h>
>  #include <xen/hvm.h>
> +#include <xen/grant_table.h>
>  #include <xen/page.h>
>  #include <xen/events.h>
>  #include <xen/interface/io/console.h>
>  #include <xen/hvc-console.h>
> +#include <xen/xenbus.h>
>  
>  #include "hvc_console.h"
>  
>  #define HVC_COOKIE   0x58656e /* "Xen" in hex */
>  
> -static struct hvc_struct *hvc;
> -static int xencons_irq;
> +struct xencons_info {
> +	struct list_head list;
> +	struct xenbus_device *xbdev;
> +	struct xencons_interface *intf;
> +	unsigned int evtchn;
> +	struct hvc_struct *hvc;
> +	int irq;
> +	int vtermno;
> +	grant_ref_t gntref;
> +};
> +
> +static LIST_HEAD(xenconsoles);
> +static DEFINE_SPINLOCK(xencons_lock);
> +static struct xenbus_driver xencons_driver;
>  
>  /* ------------------------------------------------------------------ */
>  
> -static unsigned long console_pfn = ~0ul;
> -static unsigned int console_evtchn = ~0ul;
> -static struct xencons_interface *xencons_if = NULL;
> +static struct xencons_info *vtermno_to_xencons(int vtermno)
> +{
> +	struct xencons_info *entry, *ret = NULL;
> +
> +	if (list_empty(&xenconsoles))
> +			return NULL;
>  
> -static inline struct xencons_interface *xencons_interface(void)
> +	spin_lock(&xencons_lock);

This spinlock gets hit everytime something is typed or written on the
console right? Isn't there an spinlock already in the hvc driver...

Or are we protected by the vtermnos being checked for -1?


> +	list_for_each_entry(entry, &xenconsoles, list) {
> +		if (entry->vtermno == vtermno) {
> +			ret  = entry;
> +			break;
> +		}
> +	}
> +	spin_unlock(&xencons_lock);
> +
> +	return ret;
> +}
> +
> +static inline int xenbus_devid_to_vtermno(int devid)
>  {
> -	if (xencons_if != NULL)
> -		return xencons_if;
> -	if (console_pfn == ~0ul)
> -		return mfn_to_virt(xen_start_info->console.domU.mfn);
> -	else
> -		return __va(console_pfn << PAGE_SHIFT);
> +	return devid + HVC_COOKIE;
>  }
>  
> -static inline void notify_daemon(void)
> +static inline void notify_daemon(struct xencons_info *cons)
>  {
>  	/* Use evtchn: this is called early, before irq is set up. */
> -	if (console_evtchn == ~0ul)
> -		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> -	else
> -		notify_remote_via_evtchn(console_evtchn);
> +	notify_remote_via_evtchn(cons->evtchn);
>  }
>  
> -static int __write_console(const char *data, int len)
> +static int __write_console(struct xencons_info *xencons,
> +		const char *data, int len)
>  {
> -	struct xencons_interface *intf = xencons_interface();
>  	XENCONS_RING_IDX cons, prod;
> +	struct xencons_interface *intf = xencons->intf;
>  	int sent = 0;
>  
>  	cons = intf->out_cons;
> @@ -85,13 +108,16 @@ static int __write_console(const char *data, int len)
>  	intf->out_prod = prod;
>  
>  	if (sent)
> -		notify_daemon();
> +		notify_daemon(xencons);
>  	return sent;
>  }
>  
>  static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  {
>  	int ret = len;
> +	struct xencons_info *cons = vtermno_to_xencons(vtermno);
> +	if (cons == NULL)
> +		return -EINVAL;
>  
>  	/*
>  	 * Make sure the whole buffer is emitted, polling if
> @@ -100,7 +126,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  	 * kernel is crippled.
>  	 */
>  	while (len) {
> -		int sent = __write_console(data, len);
> +		int sent = __write_console(cons, data, len);
>  		
>  		data += sent;
>  		len -= sent;
> @@ -114,9 +140,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  
>  static int domU_read_console(uint32_t vtermno, char *buf, int len)
>  {
> -	struct xencons_interface *intf = xencons_interface();
> +	struct xencons_interface *intf;
>  	XENCONS_RING_IDX cons, prod;
>  	int recv = 0;
> +	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
> +	if (xencons == NULL)
> +		return -EINVAL;
> +	intf = xencons->intf;
>  
>  	cons = intf->in_cons;
>  	prod = intf->in_prod;
> @@ -129,7 +159,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
>  	mb();			/* read ring before consuming */
>  	intf->in_cons = cons;
>  
> -	notify_daemon();
> +	notify_daemon(xencons);
>  	return recv;
>  }
>  
> @@ -172,33 +202,109 @@ static int xen_hvm_console_init(void)
>  	int r;
>  	uint64_t v = 0;
>  	unsigned long mfn;
> +	struct xencons_info *info;
>  
>  	if (!xen_hvm_domain())
>  		return -ENODEV;
>  
> -	if (xencons_if != NULL)
> -		return -EBUSY;
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	/* already configured */
> +	if (info->intf != NULL)
> +		return 0;
>  
>  	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> -	if (r < 0)
> +	if (r < 0) {
> +		kfree(info);
>  		return -ENODEV;
> -	console_evtchn = v;
> +	}
> +	info->evtchn = v;
>  	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> -	if (r < 0)
> +	if (r < 0) {
> +		kfree(info);
>  		return -ENODEV;
> +	}
>  	mfn = v;
> -	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> -	if (xencons_if == NULL)
> +	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	if (info->intf == NULL) {
> +		kfree(info);
> +		return -ENODEV;
> +	}
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +}
> +
> +static int xen_pv_console_init(void)
> +{
> +	struct xencons_info *info;
> +
> +	if (!xen_pv_domain())
>  		return -ENODEV;
>  
> +	if (!xen_start_info->console.domU.evtchn)
> +		return -ENODEV;
> +
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);

Ugh. Use kzalloc here. Especially as you are testing it below (and
kmalloc with certain CONFIG_DEBUG.. can make the the returned memory
have bogus data.

> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	/* already configured */
> +	if (info->intf != NULL)
> +		return 0;
> +
> +	info->evtchn = xen_start_info->console.domU.evtchn;
> +	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +}
> +
> +static int xen_initial_domain_console_init(void)
> +{
> +	struct xencons_info *info;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);

Ditto
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
>  	return 0;
>  }
>  
>  static int __init xen_hvc_init(void)
>  {
> -	struct hvc_struct *hp;
> -	struct hv_ops *ops;
>  	int r;
> +	struct xencons_info *info;
> +	const struct hv_ops *ops;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
> @@ -209,43 +315,251 @@ static int __init xen_hvc_init(void)
>  
>  	if (xen_initial_domain()) {
>  		ops = &dom0_hvc_ops;
> -		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> +		r = xen_initial_domain_console_init();
> +		if (r < 0)
> +			return r;
> +		info = vtermno_to_xencons(HVC_COOKIE);
>  	} else {
>  		ops = &domU_hvc_ops;
> -		if (xen_pv_domain()) {
> -			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> -		} else {
> +		if (xen_hvm_domain())
>  			r = xen_hvm_console_init();
> -			if (r < 0)
> -				return r;
> -		}
> -		xencons_irq = bind_evtchn_to_irq(console_evtchn);
> -		if (xencons_irq < 0)
> -			xencons_irq = 0; /* NO_IRQ */
>  		else
> -			irq_set_noprobe(xencons_irq);
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
> +
> +		info = vtermno_to_xencons(HVC_COOKIE);
> +		info->irq = bind_evtchn_to_irq(info->evtchn);
> +	}
> +	if (info->irq < 0)
> +		info->irq = 0; /* NO_IRQ */
> +	else
> +		irq_set_noprobe(info->irq);
> +
> +	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
> +	if (IS_ERR(info->hvc)) {
> +		r = PTR_ERR(info->hvc);
> +		spin_lock(&xencons_lock);
> +		list_del(&info->list);
> +		spin_unlock(&xencons_lock);
> +		if (info->irq)
> +			unbind_from_irqhandler(info->irq, NULL);
> +		kfree(info);
> +		return r;
>  	}
>  
> -	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
> -	if (IS_ERR(hp))
> -		return PTR_ERR(hp);
> +	return xenbus_register_frontend(&xencons_driver);
> +}
>  
> -	hvc = hp;
> +void xen_console_resume(void)
> +{
> +	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
> +	if (info != NULL && info->irq)
> +		rebind_evtchn_irq(info->evtchn, info->irq);
> +}
>  
> +static void xencons_disconnect_backend(struct xencons_info *info)
> +{
> +	if (info->irq > 0)
> +		unbind_from_irqhandler(info->irq, NULL);
> +	info->irq = 0;
> +	if (info->evtchn > 0)
> +		xenbus_free_evtchn(info->xbdev, info->evtchn);
> +	info->evtchn = 0;
> +	if (info->gntref > 0)
> +		gnttab_free_grant_references(info->gntref);
> +	info->gntref = 0;
> +	if (info->hvc != NULL)
> +		hvc_remove(info->hvc);
> +	info->hvc = NULL;
> +}
> +
> +static void xencons_free(struct xencons_info *info)
> +{
> +	xencons_disconnect_backend(info);
> +	free_page((unsigned long)info->intf);
> +	info->intf = NULL;
> +	info->vtermno = 0;
> +	kfree(info);
> +}
> +
> +static int xencons_remove(struct xenbus_device *dev)
> +{
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +
> +	spin_lock(&xencons_lock);
> +	list_del(&info->list);
> +	spin_unlock(&xencons_lock);
> +	xencons_free(info);
>  	return 0;
>  }
>  
> -void xen_console_resume(void)
> +static int xencons_connect_backend(struct xenbus_device *dev,
> +				  struct xencons_info *info)
> +{
> +	int ret, evtchn, devid, ref, irq;
> +	struct xenbus_transaction xbt;
> +	grant_ref_t gref_head;
> +	unsigned long mfn;
> +
> +	ret = xenbus_alloc_evtchn(dev, &evtchn);
> +	if (ret)
> +		return ret;
> +	info->evtchn = evtchn;
> +	irq = bind_evtchn_to_irq(evtchn);
> +	if (irq < 0)
> +		return irq;
> +	info->irq = irq;
> +	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
> +	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
> +			irq, &domU_hvc_ops, 256);
> +	if (IS_ERR(info->hvc))
> +		return PTR_ERR(info->hvc);
> +	if (xen_pv_domain())
> +		mfn = virt_to_mfn(info->intf);
> +	else
> +		mfn = __pa(info->intf) >> PAGE_SHIFT;
> +	ret = gnttab_alloc_grant_references(1, &gref_head);
> +	if (ret < 0)
> +		return ret;
> +	info->gntref = gref_head;
> +	ref = gnttab_claim_grant_reference(&gref_head);
> +	if (ref < 0)
> +		return ref;
> +	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
> +			mfn, 0);
> +
> + again:
> +	ret = xenbus_transaction_start(&xbt);
> +	if (ret) {
> +		xenbus_dev_fatal(dev, ret, "starting transaction");
> +		return ret;
> +	}
> +	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
> +			    evtchn);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_transaction_end(xbt, 0);
> +	if (ret) {
> +		if (ret == -EAGAIN)
> +			goto again;
> +		xenbus_dev_fatal(dev, ret, "completing transaction");
> +		return ret;
> +	}
> +
> +	xenbus_switch_state(dev, XenbusStateInitialised);
> +	return 0;
> +
> + error_xenbus:
> +	xenbus_transaction_end(xbt, 1);
> +	xenbus_dev_fatal(dev, ret, "writing xenstore");
> +	return ret;
> +}
> +
> +static int __devinit xencons_probe(struct xenbus_device *dev,
> +				  const struct xenbus_device_id *id)
>  {
> -	if (xencons_irq)
> -		rebind_evtchn_irq(console_evtchn, xencons_irq);
> +	int ret, devid;
> +	struct xencons_info *info;
> +
> +	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
> +	if (devid == 0)
> +		return -ENODEV;
> +
> +	info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +	if (!info)
> +		goto error_nomem;
> +	dev_set_drvdata(&dev->dev, info);
> +	info->xbdev = dev;
> +	info->vtermno = xenbus_devid_to_vtermno(devid);
> +	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> +	if (!info->intf)
> +		goto error_nomem;
> +
> +	ret = xencons_connect_backend(dev, info);
> +	if (ret < 0)
> +		goto error;
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +
> + error_nomem:
> +	ret = -ENOMEM;
> +	xenbus_dev_fatal(dev, ret, "allocating device memory");
> + error:
> +	xencons_free(info);
> +	return ret;
> +}
> +
> +static int xencons_resume(struct xenbus_device *dev)
> +{
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +
> +	xencons_disconnect_backend(info);
> +	memset(info->intf, 0, PAGE_SIZE);
> +	return xencons_connect_backend(dev, info);
>  }
>  
> +static void xencons_backend_changed(struct xenbus_device *dev,
> +				   enum xenbus_state backend_state)
> +{
> +	switch (backend_state) {
> +	case XenbusStateReconfiguring:
> +	case XenbusStateReconfigured:
> +	case XenbusStateInitialising:
> +	case XenbusStateInitialised:
> +	case XenbusStateUnknown:
> +	case XenbusStateClosed:
> +		break;
> +
> +	case XenbusStateInitWait:
> +		break;
> +
> +	case XenbusStateConnected:
> +		xenbus_switch_state(dev, XenbusStateConnected);
> +		break;
> +
> +	case XenbusStateClosing:
> +		xenbus_frontend_closed(dev);
> +		break;
> +	}
> +}
> +
> +static const struct xenbus_device_id xencons_ids[] = {
> +	{ "console" },
> +	{ "" }
> +};
> +
> +
>  static void __exit xen_hvc_fini(void)
>  {
> -	if (hvc)
> -		hvc_remove(hvc);
> +	struct xencons_info *entry, *next;
> +
> +	if (list_empty(&xenconsoles))
> +			return;
> +
> +	spin_lock(&xencons_lock);
> +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> +		list_del(&entry->list);
> +		if (entry->xbdev)
> +			xencons_remove(entry->xbdev);
> +		else {
> +			if (entry->irq > 0)
> +				unbind_from_irqhandler(entry->irq, NULL);
> +			if (entry->hvc);
> +				hvc_remove(entry->hvc);
> +			kfree(entry);
> +		}
> +	}
> +	spin_unlock(&xencons_lock);
>  }
>  
>  static int xen_cons_init(void)
> @@ -258,18 +572,31 @@ static int xen_cons_init(void)
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
>  	else {
> +		int r;
>  		ops = &domU_hvc_ops;
>  
> -		if (xen_pv_domain())
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> +		if (xen_hvm_domain())
> +			r = xen_hvm_console_init();
>  		else
> -			xen_hvm_console_init();
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
>  	}
>  
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
>  
> +static struct xenbus_driver xencons_driver = {
> +	.name = "xenconsole",
> +	.owner = THIS_MODULE,
> +	.ids = xencons_ids,
> +	.probe = xencons_probe,
> +	.remove = xencons_remove,
> +	.resume = xencons_resume,
> +	.otherend_changed = xencons_backend_changed,
> +};
> +
>  module_init(xen_hvc_init);
>  module_exit(xen_hvc_fini);
>  console_initcall(xen_cons_init);
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 16:04:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 16:04:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqoHc-0002GN-GU; Fri, 27 Jan 2012 16:04:12 +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 1RqoHa-0002GI-AP
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 16:04:10 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327680241!3381922!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25244 invoked from network); 27 Jan 2012 16:04:02 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-4.tower-21.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 16:04:02 -0000
Received: from andromeda.dapyr.net (darnok@localhost [127.0.0.1])
	by andromeda.dapyr.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	q0RG3uPr002286
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 27 Jan 2012 11:03:56 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0RG3tEg002284;
	Fri, 27 Jan 2012 11:03:55 -0500
Date: Fri, 27 Jan 2012 12:03:55 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127160355.GA566@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, Jan 26, 2012 at 12:43:27PM +0000, Stefano Stabellini wrote:
> This patch implements support for multiple consoles:
> consoles other than the first one are setup using the traditional xenbus
> and grant-table based mechanism.
> We use a list to keep track of the allocated consoles, we don't
> expect too many of them anyway.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
>  1 files changed, 383 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index dd6641f..97732fb 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -23,6 +23,7 @@
>  #include <linux/err.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
> +#include <linux/list.h>
>  
>  #include <asm/io.h>
>  #include <asm/xen/hypervisor.h>
> @@ -30,47 +31,69 @@
>  #include <xen/xen.h>
>  #include <xen/interface/xen.h>
>  #include <xen/hvm.h>
> +#include <xen/grant_table.h>
>  #include <xen/page.h>
>  #include <xen/events.h>
>  #include <xen/interface/io/console.h>
>  #include <xen/hvc-console.h>
> +#include <xen/xenbus.h>
>  
>  #include "hvc_console.h"
>  
>  #define HVC_COOKIE   0x58656e /* "Xen" in hex */
>  
> -static struct hvc_struct *hvc;
> -static int xencons_irq;
> +struct xencons_info {
> +	struct list_head list;
> +	struct xenbus_device *xbdev;
> +	struct xencons_interface *intf;
> +	unsigned int evtchn;
> +	struct hvc_struct *hvc;
> +	int irq;
> +	int vtermno;
> +	grant_ref_t gntref;
> +};
> +
> +static LIST_HEAD(xenconsoles);
> +static DEFINE_SPINLOCK(xencons_lock);
> +static struct xenbus_driver xencons_driver;
>  
>  /* ------------------------------------------------------------------ */
>  
> -static unsigned long console_pfn = ~0ul;
> -static unsigned int console_evtchn = ~0ul;
> -static struct xencons_interface *xencons_if = NULL;
> +static struct xencons_info *vtermno_to_xencons(int vtermno)
> +{
> +	struct xencons_info *entry, *ret = NULL;
> +
> +	if (list_empty(&xenconsoles))
> +			return NULL;
>  
> -static inline struct xencons_interface *xencons_interface(void)
> +	spin_lock(&xencons_lock);

This spinlock gets hit everytime something is typed or written on the
console right? Isn't there an spinlock already in the hvc driver...

Or are we protected by the vtermnos being checked for -1?


> +	list_for_each_entry(entry, &xenconsoles, list) {
> +		if (entry->vtermno == vtermno) {
> +			ret  = entry;
> +			break;
> +		}
> +	}
> +	spin_unlock(&xencons_lock);
> +
> +	return ret;
> +}
> +
> +static inline int xenbus_devid_to_vtermno(int devid)
>  {
> -	if (xencons_if != NULL)
> -		return xencons_if;
> -	if (console_pfn == ~0ul)
> -		return mfn_to_virt(xen_start_info->console.domU.mfn);
> -	else
> -		return __va(console_pfn << PAGE_SHIFT);
> +	return devid + HVC_COOKIE;
>  }
>  
> -static inline void notify_daemon(void)
> +static inline void notify_daemon(struct xencons_info *cons)
>  {
>  	/* Use evtchn: this is called early, before irq is set up. */
> -	if (console_evtchn == ~0ul)
> -		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> -	else
> -		notify_remote_via_evtchn(console_evtchn);
> +	notify_remote_via_evtchn(cons->evtchn);
>  }
>  
> -static int __write_console(const char *data, int len)
> +static int __write_console(struct xencons_info *xencons,
> +		const char *data, int len)
>  {
> -	struct xencons_interface *intf = xencons_interface();
>  	XENCONS_RING_IDX cons, prod;
> +	struct xencons_interface *intf = xencons->intf;
>  	int sent = 0;
>  
>  	cons = intf->out_cons;
> @@ -85,13 +108,16 @@ static int __write_console(const char *data, int len)
>  	intf->out_prod = prod;
>  
>  	if (sent)
> -		notify_daemon();
> +		notify_daemon(xencons);
>  	return sent;
>  }
>  
>  static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  {
>  	int ret = len;
> +	struct xencons_info *cons = vtermno_to_xencons(vtermno);
> +	if (cons == NULL)
> +		return -EINVAL;
>  
>  	/*
>  	 * Make sure the whole buffer is emitted, polling if
> @@ -100,7 +126,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  	 * kernel is crippled.
>  	 */
>  	while (len) {
> -		int sent = __write_console(data, len);
> +		int sent = __write_console(cons, data, len);
>  		
>  		data += sent;
>  		len -= sent;
> @@ -114,9 +140,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
>  
>  static int domU_read_console(uint32_t vtermno, char *buf, int len)
>  {
> -	struct xencons_interface *intf = xencons_interface();
> +	struct xencons_interface *intf;
>  	XENCONS_RING_IDX cons, prod;
>  	int recv = 0;
> +	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
> +	if (xencons == NULL)
> +		return -EINVAL;
> +	intf = xencons->intf;
>  
>  	cons = intf->in_cons;
>  	prod = intf->in_prod;
> @@ -129,7 +159,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
>  	mb();			/* read ring before consuming */
>  	intf->in_cons = cons;
>  
> -	notify_daemon();
> +	notify_daemon(xencons);
>  	return recv;
>  }
>  
> @@ -172,33 +202,109 @@ static int xen_hvm_console_init(void)
>  	int r;
>  	uint64_t v = 0;
>  	unsigned long mfn;
> +	struct xencons_info *info;
>  
>  	if (!xen_hvm_domain())
>  		return -ENODEV;
>  
> -	if (xencons_if != NULL)
> -		return -EBUSY;
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	/* already configured */
> +	if (info->intf != NULL)
> +		return 0;
>  
>  	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> -	if (r < 0)
> +	if (r < 0) {
> +		kfree(info);
>  		return -ENODEV;
> -	console_evtchn = v;
> +	}
> +	info->evtchn = v;
>  	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> -	if (r < 0)
> +	if (r < 0) {
> +		kfree(info);
>  		return -ENODEV;
> +	}
>  	mfn = v;
> -	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> -	if (xencons_if == NULL)
> +	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	if (info->intf == NULL) {
> +		kfree(info);
> +		return -ENODEV;
> +	}
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +}
> +
> +static int xen_pv_console_init(void)
> +{
> +	struct xencons_info *info;
> +
> +	if (!xen_pv_domain())
>  		return -ENODEV;
>  
> +	if (!xen_start_info->console.domU.evtchn)
> +		return -ENODEV;
> +
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);

Ugh. Use kzalloc here. Especially as you are testing it below (and
kmalloc with certain CONFIG_DEBUG.. can make the the returned memory
have bogus data.

> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	/* already configured */
> +	if (info->intf != NULL)
> +		return 0;
> +
> +	info->evtchn = xen_start_info->console.domU.evtchn;
> +	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +}
> +
> +static int xen_initial_domain_console_init(void)
> +{
> +	struct xencons_info *info;
> +
> +	if (!xen_initial_domain())
> +		return -ENODEV;
> +
> +	info = vtermno_to_xencons(HVC_COOKIE);
> +	if (!info) {
> +		info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);

Ditto
> +		if (!info)
> +			return -ENOMEM;
> +	}
> +
> +	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> +	info->vtermno = HVC_COOKIE;
> +
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
>  	return 0;
>  }
>  
>  static int __init xen_hvc_init(void)
>  {
> -	struct hvc_struct *hp;
> -	struct hv_ops *ops;
>  	int r;
> +	struct xencons_info *info;
> +	const struct hv_ops *ops;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
> @@ -209,43 +315,251 @@ static int __init xen_hvc_init(void)
>  
>  	if (xen_initial_domain()) {
>  		ops = &dom0_hvc_ops;
> -		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
> +		r = xen_initial_domain_console_init();
> +		if (r < 0)
> +			return r;
> +		info = vtermno_to_xencons(HVC_COOKIE);
>  	} else {
>  		ops = &domU_hvc_ops;
> -		if (xen_pv_domain()) {
> -			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> -		} else {
> +		if (xen_hvm_domain())
>  			r = xen_hvm_console_init();
> -			if (r < 0)
> -				return r;
> -		}
> -		xencons_irq = bind_evtchn_to_irq(console_evtchn);
> -		if (xencons_irq < 0)
> -			xencons_irq = 0; /* NO_IRQ */
>  		else
> -			irq_set_noprobe(xencons_irq);
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
> +
> +		info = vtermno_to_xencons(HVC_COOKIE);
> +		info->irq = bind_evtchn_to_irq(info->evtchn);
> +	}
> +	if (info->irq < 0)
> +		info->irq = 0; /* NO_IRQ */
> +	else
> +		irq_set_noprobe(info->irq);
> +
> +	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
> +	if (IS_ERR(info->hvc)) {
> +		r = PTR_ERR(info->hvc);
> +		spin_lock(&xencons_lock);
> +		list_del(&info->list);
> +		spin_unlock(&xencons_lock);
> +		if (info->irq)
> +			unbind_from_irqhandler(info->irq, NULL);
> +		kfree(info);
> +		return r;
>  	}
>  
> -	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
> -	if (IS_ERR(hp))
> -		return PTR_ERR(hp);
> +	return xenbus_register_frontend(&xencons_driver);
> +}
>  
> -	hvc = hp;
> +void xen_console_resume(void)
> +{
> +	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
> +	if (info != NULL && info->irq)
> +		rebind_evtchn_irq(info->evtchn, info->irq);
> +}
>  
> +static void xencons_disconnect_backend(struct xencons_info *info)
> +{
> +	if (info->irq > 0)
> +		unbind_from_irqhandler(info->irq, NULL);
> +	info->irq = 0;
> +	if (info->evtchn > 0)
> +		xenbus_free_evtchn(info->xbdev, info->evtchn);
> +	info->evtchn = 0;
> +	if (info->gntref > 0)
> +		gnttab_free_grant_references(info->gntref);
> +	info->gntref = 0;
> +	if (info->hvc != NULL)
> +		hvc_remove(info->hvc);
> +	info->hvc = NULL;
> +}
> +
> +static void xencons_free(struct xencons_info *info)
> +{
> +	xencons_disconnect_backend(info);
> +	free_page((unsigned long)info->intf);
> +	info->intf = NULL;
> +	info->vtermno = 0;
> +	kfree(info);
> +}
> +
> +static int xencons_remove(struct xenbus_device *dev)
> +{
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +
> +	spin_lock(&xencons_lock);
> +	list_del(&info->list);
> +	spin_unlock(&xencons_lock);
> +	xencons_free(info);
>  	return 0;
>  }
>  
> -void xen_console_resume(void)
> +static int xencons_connect_backend(struct xenbus_device *dev,
> +				  struct xencons_info *info)
> +{
> +	int ret, evtchn, devid, ref, irq;
> +	struct xenbus_transaction xbt;
> +	grant_ref_t gref_head;
> +	unsigned long mfn;
> +
> +	ret = xenbus_alloc_evtchn(dev, &evtchn);
> +	if (ret)
> +		return ret;
> +	info->evtchn = evtchn;
> +	irq = bind_evtchn_to_irq(evtchn);
> +	if (irq < 0)
> +		return irq;
> +	info->irq = irq;
> +	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
> +	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
> +			irq, &domU_hvc_ops, 256);
> +	if (IS_ERR(info->hvc))
> +		return PTR_ERR(info->hvc);
> +	if (xen_pv_domain())
> +		mfn = virt_to_mfn(info->intf);
> +	else
> +		mfn = __pa(info->intf) >> PAGE_SHIFT;
> +	ret = gnttab_alloc_grant_references(1, &gref_head);
> +	if (ret < 0)
> +		return ret;
> +	info->gntref = gref_head;
> +	ref = gnttab_claim_grant_reference(&gref_head);
> +	if (ref < 0)
> +		return ref;
> +	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
> +			mfn, 0);
> +
> + again:
> +	ret = xenbus_transaction_start(&xbt);
> +	if (ret) {
> +		xenbus_dev_fatal(dev, ret, "starting transaction");
> +		return ret;
> +	}
> +	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
> +			    evtchn);
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
> +	if (ret)
> +		goto error_xenbus;
> +	ret = xenbus_transaction_end(xbt, 0);
> +	if (ret) {
> +		if (ret == -EAGAIN)
> +			goto again;
> +		xenbus_dev_fatal(dev, ret, "completing transaction");
> +		return ret;
> +	}
> +
> +	xenbus_switch_state(dev, XenbusStateInitialised);
> +	return 0;
> +
> + error_xenbus:
> +	xenbus_transaction_end(xbt, 1);
> +	xenbus_dev_fatal(dev, ret, "writing xenstore");
> +	return ret;
> +}
> +
> +static int __devinit xencons_probe(struct xenbus_device *dev,
> +				  const struct xenbus_device_id *id)
>  {
> -	if (xencons_irq)
> -		rebind_evtchn_irq(console_evtchn, xencons_irq);
> +	int ret, devid;
> +	struct xencons_info *info;
> +
> +	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
> +	if (devid == 0)
> +		return -ENODEV;
> +
> +	info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> +	if (!info)
> +		goto error_nomem;
> +	dev_set_drvdata(&dev->dev, info);
> +	info->xbdev = dev;
> +	info->vtermno = xenbus_devid_to_vtermno(devid);
> +	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
> +	if (!info->intf)
> +		goto error_nomem;
> +
> +	ret = xencons_connect_backend(dev, info);
> +	if (ret < 0)
> +		goto error;
> +	spin_lock(&xencons_lock);
> +	list_add_tail(&info->list, &xenconsoles);
> +	spin_unlock(&xencons_lock);
> +
> +	return 0;
> +
> + error_nomem:
> +	ret = -ENOMEM;
> +	xenbus_dev_fatal(dev, ret, "allocating device memory");
> + error:
> +	xencons_free(info);
> +	return ret;
> +}
> +
> +static int xencons_resume(struct xenbus_device *dev)
> +{
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +
> +	xencons_disconnect_backend(info);
> +	memset(info->intf, 0, PAGE_SIZE);
> +	return xencons_connect_backend(dev, info);
>  }
>  
> +static void xencons_backend_changed(struct xenbus_device *dev,
> +				   enum xenbus_state backend_state)
> +{
> +	switch (backend_state) {
> +	case XenbusStateReconfiguring:
> +	case XenbusStateReconfigured:
> +	case XenbusStateInitialising:
> +	case XenbusStateInitialised:
> +	case XenbusStateUnknown:
> +	case XenbusStateClosed:
> +		break;
> +
> +	case XenbusStateInitWait:
> +		break;
> +
> +	case XenbusStateConnected:
> +		xenbus_switch_state(dev, XenbusStateConnected);
> +		break;
> +
> +	case XenbusStateClosing:
> +		xenbus_frontend_closed(dev);
> +		break;
> +	}
> +}
> +
> +static const struct xenbus_device_id xencons_ids[] = {
> +	{ "console" },
> +	{ "" }
> +};
> +
> +
>  static void __exit xen_hvc_fini(void)
>  {
> -	if (hvc)
> -		hvc_remove(hvc);
> +	struct xencons_info *entry, *next;
> +
> +	if (list_empty(&xenconsoles))
> +			return;
> +
> +	spin_lock(&xencons_lock);
> +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> +		list_del(&entry->list);
> +		if (entry->xbdev)
> +			xencons_remove(entry->xbdev);
> +		else {
> +			if (entry->irq > 0)
> +				unbind_from_irqhandler(entry->irq, NULL);
> +			if (entry->hvc);
> +				hvc_remove(entry->hvc);
> +			kfree(entry);
> +		}
> +	}
> +	spin_unlock(&xencons_lock);
>  }
>  
>  static int xen_cons_init(void)
> @@ -258,18 +572,31 @@ static int xen_cons_init(void)
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
>  	else {
> +		int r;
>  		ops = &domU_hvc_ops;
>  
> -		if (xen_pv_domain())
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> +		if (xen_hvm_domain())
> +			r = xen_hvm_console_init();
>  		else
> -			xen_hvm_console_init();
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
>  	}
>  
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
>  
> +static struct xenbus_driver xencons_driver = {
> +	.name = "xenconsole",
> +	.owner = THIS_MODULE,
> +	.ids = xencons_ids,
> +	.probe = xencons_probe,
> +	.remove = xencons_remove,
> +	.resume = xencons_resume,
> +	.otherend_changed = xencons_backend_changed,
> +};
> +
>  module_init(xen_hvc_init);
>  module_exit(xen_hvc_fini);
>  console_initcall(xen_cons_init);
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 16:12:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 16:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqoOn-0002TX-Lj; Fri, 27 Jan 2012 16:11: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 1RqoOm-0002TR-CL
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 16:11:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327680689!12809627!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6036 invoked from network); 27 Jan 2012 16:11:29 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 16:11: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
	q0RGBP7S017571; Fri, 27 Jan 2012 16:11: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 q0RGBPW8003173; 
	Fri, 27 Jan 2012 11:11:25 -0500
Message-ID: <4F22CCAE.3000808@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 11:11:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 06:22 AM, Stefano Stabellini wrote:
> On Thu, 26 Jan 2012, Daniel De Graaf wrote:
>> A previous versions of this patch has been sent to xen-devel. See
>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
>>
>> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> The patch series is definitely going in the right direction.
> 
> 
>> +
>>  .PHONY: all
>>  all: $(ALL_TARGETS)
>>  
>> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
>>  
>>  CFLAGS += -DHAVE_DTRACE=1
>>  endif
>> - 
>> +
>>  xenstored: $(XENSTORED_OBJS)
>>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>>  
>> +xenstored.a: $(XENSTORED_OBJS)
>> +	$(AR) cr $@ $^
>> +
>>  $(CLIENTS): xenstore
>>  	ln -f xenstore $@
>>  
>> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
>> index f378343..2effd17 100644
>> --- a/tools/xenstore/utils.h
>> +++ b/tools/xenstore/utils.h
>> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>>  	return streq(a + strlen(a) - strlen(b), b);
>>  }
>>  
>> +#ifndef ARRAY_SIZE
>>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
>> +#endif
>>  
>>  void barf(const char *fmt, ...) __attribute__((noreturn));
>>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index 4b12cf2..0b9d4f2 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -224,7 +224,6 @@ static void reopen_log(void)
>>  	}
>>  }
>>  
>> -
>>  static bool write_messages(struct connection *conn)
>>  {
>>  	int ret;
>> @@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>>  		set_fd(sock, inset, &max);
>>  	if (ro_sock != -1)
>>  		set_fd(ro_sock, inset, &max);
>> -	set_fd(reopen_log_pipe[0], inset, &max);
>> +	if (reopen_log_pipe[0] != -1)
>> +		set_fd(reopen_log_pipe[0], inset, &max);
>>  
>>  	if (xce_handle != NULL)
>>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
>> @@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>>  }
>>  
>>  
>> +#ifdef __MINIOS__
>> +static void write_pidfile(const char *pidfile)
>> +{
>> +}
>> +
>> +static void daemonize(void)
>> +{
>> +}
>> +
>> +static void finish_daemonize(void)
>> +{
>> +}
>> +#else
>>  static void write_pidfile(const char *pidfile)
>>  {
>>  	char buf[100];
>> @@ -1711,6 +1724,19 @@ static void daemonize(void)
>>  	umask(0);
>>  }
>>  
>> +static void finish_daemonize(void)
>> +{
>> +	int devnull = open("/dev/null", O_RDWR);
>> +	if (devnull == -1)
>> +		barf_perror("Could not open /dev/null\n");
>> +	dup2(devnull, STDIN_FILENO);
>> +	dup2(devnull, STDOUT_FILENO);
>> +	dup2(devnull, STDERR_FILENO);
>> +	close(devnull);
>> +	xprintf = trace;
>> +}
>> +#endif
>> +
>>  #ifdef NO_SOCKETS
>>  static void init_sockets(int **psock, int **pro_sock)
>>  {
> 
> At this point we could have the MiniOS version of write_pidfile,
> daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and the
> Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c.
> 

Are you suggesting this for just these functions, or all functions that are
different on minios?

Since we already have xenstored_{linux,netbsd,solaris}.c, should the POSIX
versions be duplicated or placed in a common POSIX file (as Ian suggested)?

> 
>> ---
>>  tools/xenstore/Makefile           |    9 ++++-
>>  tools/xenstore/utils.h            |    2 +
>>  tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
>>  tools/xenstore/xenstored_domain.c |   11 +++++
>>  4 files changed, 68 insertions(+), 28 deletions(-)
>>
>> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
>> index 4facb62..be892fd 100644
>> --- a/tools/xenstore/Makefile
>> +++ b/tools/xenstore/Makefile
>> @@ -28,6 +28,10 @@ endif
>>  
>>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>>  
>> +ifdef CONFIG_STUBDOM
>> +CFLAGS += -DNO_SOCKETS=1
>> +endif
> 
>> @@ -1822,6 +1848,11 @@ int main(int argc, char *argv[])
>>  	int evtchn_fd = -1;
>>  	struct timeval *timeout;
>>  
>> +#ifdef __MINIOS__
>> +	/* minios always uses internal DB */
>> +	tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
>> +#endif
> 
> can you use the "internal-db" command line option?
> 

Yes, but that begins to clutter up the xenstore stub domain's command line
with mandatory options (which seems self-contradictory).

> 
>>  	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
>>  				  NULL)) != -1) {
>>  		switch (opt) {
>> @@ -1874,20 +1905,10 @@ int main(int argc, char *argv[])
>>  
>>  	reopen_log();
>>  
>> -	/* make sure xenstored directory exists */
>> -	if (mkdir(xs_daemon_rundir(), 0755)) {
>> -		if (errno != EEXIST) {
>> -			perror("error: mkdir daemon rundir");
>> -			exit(-1);
>> -		}
>> -	}
>> -
>> -	if (mkdir(xs_daemon_rootdir(), 0755)) {
>> -		if (errno != EEXIST) {
>> -			perror("error: mkdir daemon rootdir");
>> -			exit(-1);
>> -		}
>> -	}
>> +	/* make sure xenstored directories exist */
>> +	/* Errors ignored here, will be reported when we open files */
>> +	mkdir(xs_daemon_rundir(), 0755);
>> +	mkdir(xs_daemon_rootdir(), 0755);
>>  
>>  	if (dofork) {
>>  		openlog("xenstored", 0, LOG_DAEMON);
>> @@ -1905,9 +1926,14 @@ int main(int argc, char *argv[])
>>  
>>  	init_sockets(&sock, &ro_sock);
>>  
>> +#ifdef __MINIOS__
>> +	reopen_log_pipe[0] = -1;
>> +	reopen_log_pipe[1] = -1;
>> +#else
>>  	if (pipe(reopen_log_pipe)) {
>>  		barf_perror("pipe");
>>  	}
>> +#endif
> 
> maybe we could have open/read/write_log_pipe functions?

That would be useless here, since the pipe is only used to receive signals
(which minios can't do) in order to reopen a log file that minios doesn't open.

> 
>>  	/* Setup the database */
>>  	setup_structure();
>> @@ -1925,16 +1951,8 @@ int main(int argc, char *argv[])
>>  	}
>>  
>>  	/* redirect to /dev/null now we're ready to accept connections */
>> -	if (dofork) {
>> -		int devnull = open("/dev/null", O_RDWR);
>> -		if (devnull == -1)
>> -			barf_perror("Could not open /dev/null\n");
>> -		dup2(devnull, STDIN_FILENO);
>> -		dup2(devnull, STDOUT_FILENO);
>> -		dup2(devnull, STDERR_FILENO);
>> -		close(devnull);
>> -		xprintf = trace;
>> -	}
>> +	if (dofork)
>> +		finish_daemonize();
>>  
>>  	signal(SIGHUP, trigger_reopen_log);
>>  
>> @@ -1944,8 +1962,10 @@ int main(int argc, char *argv[])
>>  	/* Get ready to listen to the tools. */
>>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>>  
>> +#ifndef __MINIOS__
>>  	/* Tell the kernel we're up and running. */
>>  	xenbus_notify_running();
>> +#endif
>>  
>>  	/* Main loop. */
>>  	for (;;) {
>> @@ -1957,7 +1977,7 @@ int main(int argc, char *argv[])
>>  			barf_perror("Select failed");
>>  		}
>>  
>> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
>> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>>  			char c;
>>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>>  				barf_perror("read failed");
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index c521e52..4243f91 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -197,12 +197,16 @@ static int destroy_domain(void *_domain)
>>  	}
>>  
>>  	if (domain->interface) {
>> +#ifdef __MINIOS__
>> +		unmap_interface(domain->interface);
>> +#else
>>  		/* Domain 0 was mapped by dom0_init, so it must be unmapped
>>  		   using munmap() and not the grant unmap call. */
>>  		if (domain->domid == 0)
>>  			munmap(domain->interface, getpagesize());
>>  		else
>>  			unmap_interface(domain->interface);
>> +#endif
>>  	}
>>  
>>  	fire_watches(NULL, "@releaseDomain", false);
>> @@ -597,6 +601,12 @@ void restore_existing_connections(void)
>>  {
>>  }
>>  
>> +#ifdef __MINIOS__
>> +static int dom0_init(void)
>> +{
>> +	return 0;
>> +}
>> +#else
>>  static int dom0_init(void) 
>>  { 
>>  	evtchn_port_t port;
>> @@ -620,6 +630,7 @@ static int dom0_init(void)
>>  
>>  	return 0; 
>>  }
>> +#endif
> 
> another candidate to be moved to xenstored_minios/linux
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 16:12:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 16:12:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqoOn-0002TX-Lj; Fri, 27 Jan 2012 16:11: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 1RqoOm-0002TR-CL
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 16:11:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327680689!12809627!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6036 invoked from network); 27 Jan 2012 16:11:29 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 16:11: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
	q0RGBP7S017571; Fri, 27 Jan 2012 16:11: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 q0RGBPW8003173; 
	Fri, 27 Jan 2012 11:11:25 -0500
Message-ID: <4F22CCAE.3000808@tycho.nsa.gov>
Date: Fri, 27 Jan 2012 11:11:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Organization: National Security Agency
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
X-Enigmail-Version: 1.3.4
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 06:22 AM, Stefano Stabellini wrote:
> On Thu, 26 Jan 2012, Daniel De Graaf wrote:
>> A previous versions of this patch has been sent to xen-devel. See
>> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html
>>
>> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
>> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
>> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> 
> The patch series is definitely going in the right direction.
> 
> 
>> +
>>  .PHONY: all
>>  all: $(ALL_TARGETS)
>>  
>> @@ -45,10 +49,13 @@ xenstored_probes.o: xenstored_solaris.o
>>  
>>  CFLAGS += -DHAVE_DTRACE=1
>>  endif
>> - 
>> +
>>  xenstored: $(XENSTORED_OBJS)
>>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>>  
>> +xenstored.a: $(XENSTORED_OBJS)
>> +	$(AR) cr $@ $^
>> +
>>  $(CLIENTS): xenstore
>>  	ln -f xenstore $@
>>  
>> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
>> index f378343..2effd17 100644
>> --- a/tools/xenstore/utils.h
>> +++ b/tools/xenstore/utils.h
>> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>>  	return streq(a + strlen(a) - strlen(b), b);
>>  }
>>  
>> +#ifndef ARRAY_SIZE
>>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
>> +#endif
>>  
>>  void barf(const char *fmt, ...) __attribute__((noreturn));
>>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
>> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
>> index 4b12cf2..0b9d4f2 100644
>> --- a/tools/xenstore/xenstored_core.c
>> +++ b/tools/xenstore/xenstored_core.c
>> @@ -224,7 +224,6 @@ static void reopen_log(void)
>>  	}
>>  }
>>  
>> -
>>  static bool write_messages(struct connection *conn)
>>  {
>>  	int ret;
>> @@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>>  		set_fd(sock, inset, &max);
>>  	if (ro_sock != -1)
>>  		set_fd(ro_sock, inset, &max);
>> -	set_fd(reopen_log_pipe[0], inset, &max);
>> +	if (reopen_log_pipe[0] != -1)
>> +		set_fd(reopen_log_pipe[0], inset, &max);
>>  
>>  	if (xce_handle != NULL)
>>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
>> @@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>>  }
>>  
>>  
>> +#ifdef __MINIOS__
>> +static void write_pidfile(const char *pidfile)
>> +{
>> +}
>> +
>> +static void daemonize(void)
>> +{
>> +}
>> +
>> +static void finish_daemonize(void)
>> +{
>> +}
>> +#else
>>  static void write_pidfile(const char *pidfile)
>>  {
>>  	char buf[100];
>> @@ -1711,6 +1724,19 @@ static void daemonize(void)
>>  	umask(0);
>>  }
>>  
>> +static void finish_daemonize(void)
>> +{
>> +	int devnull = open("/dev/null", O_RDWR);
>> +	if (devnull == -1)
>> +		barf_perror("Could not open /dev/null\n");
>> +	dup2(devnull, STDIN_FILENO);
>> +	dup2(devnull, STDOUT_FILENO);
>> +	dup2(devnull, STDERR_FILENO);
>> +	close(devnull);
>> +	xprintf = trace;
>> +}
>> +#endif
>> +
>>  #ifdef NO_SOCKETS
>>  static void init_sockets(int **psock, int **pro_sock)
>>  {
> 
> At this point we could have the MiniOS version of write_pidfile,
> daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and the
> Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c.
> 

Are you suggesting this for just these functions, or all functions that are
different on minios?

Since we already have xenstored_{linux,netbsd,solaris}.c, should the POSIX
versions be duplicated or placed in a common POSIX file (as Ian suggested)?

> 
>> ---
>>  tools/xenstore/Makefile           |    9 ++++-
>>  tools/xenstore/utils.h            |    2 +
>>  tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
>>  tools/xenstore/xenstored_domain.c |   11 +++++
>>  4 files changed, 68 insertions(+), 28 deletions(-)
>>
>> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
>> index 4facb62..be892fd 100644
>> --- a/tools/xenstore/Makefile
>> +++ b/tools/xenstore/Makefile
>> @@ -28,6 +28,10 @@ endif
>>  
>>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>>  
>> +ifdef CONFIG_STUBDOM
>> +CFLAGS += -DNO_SOCKETS=1
>> +endif
> 
>> @@ -1822,6 +1848,11 @@ int main(int argc, char *argv[])
>>  	int evtchn_fd = -1;
>>  	struct timeval *timeout;
>>  
>> +#ifdef __MINIOS__
>> +	/* minios always uses internal DB */
>> +	tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
>> +#endif
> 
> can you use the "internal-db" command line option?
> 

Yes, but that begins to clutter up the xenstore stub domain's command line
with mandatory options (which seems self-contradictory).

> 
>>  	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
>>  				  NULL)) != -1) {
>>  		switch (opt) {
>> @@ -1874,20 +1905,10 @@ int main(int argc, char *argv[])
>>  
>>  	reopen_log();
>>  
>> -	/* make sure xenstored directory exists */
>> -	if (mkdir(xs_daemon_rundir(), 0755)) {
>> -		if (errno != EEXIST) {
>> -			perror("error: mkdir daemon rundir");
>> -			exit(-1);
>> -		}
>> -	}
>> -
>> -	if (mkdir(xs_daemon_rootdir(), 0755)) {
>> -		if (errno != EEXIST) {
>> -			perror("error: mkdir daemon rootdir");
>> -			exit(-1);
>> -		}
>> -	}
>> +	/* make sure xenstored directories exist */
>> +	/* Errors ignored here, will be reported when we open files */
>> +	mkdir(xs_daemon_rundir(), 0755);
>> +	mkdir(xs_daemon_rootdir(), 0755);
>>  
>>  	if (dofork) {
>>  		openlog("xenstored", 0, LOG_DAEMON);
>> @@ -1905,9 +1926,14 @@ int main(int argc, char *argv[])
>>  
>>  	init_sockets(&sock, &ro_sock);
>>  
>> +#ifdef __MINIOS__
>> +	reopen_log_pipe[0] = -1;
>> +	reopen_log_pipe[1] = -1;
>> +#else
>>  	if (pipe(reopen_log_pipe)) {
>>  		barf_perror("pipe");
>>  	}
>> +#endif
> 
> maybe we could have open/read/write_log_pipe functions?

That would be useless here, since the pipe is only used to receive signals
(which minios can't do) in order to reopen a log file that minios doesn't open.

> 
>>  	/* Setup the database */
>>  	setup_structure();
>> @@ -1925,16 +1951,8 @@ int main(int argc, char *argv[])
>>  	}
>>  
>>  	/* redirect to /dev/null now we're ready to accept connections */
>> -	if (dofork) {
>> -		int devnull = open("/dev/null", O_RDWR);
>> -		if (devnull == -1)
>> -			barf_perror("Could not open /dev/null\n");
>> -		dup2(devnull, STDIN_FILENO);
>> -		dup2(devnull, STDOUT_FILENO);
>> -		dup2(devnull, STDERR_FILENO);
>> -		close(devnull);
>> -		xprintf = trace;
>> -	}
>> +	if (dofork)
>> +		finish_daemonize();
>>  
>>  	signal(SIGHUP, trigger_reopen_log);
>>  
>> @@ -1944,8 +1962,10 @@ int main(int argc, char *argv[])
>>  	/* Get ready to listen to the tools. */
>>  	max = initialize_set(&inset, &outset, *sock, *ro_sock, &timeout);
>>  
>> +#ifndef __MINIOS__
>>  	/* Tell the kernel we're up and running. */
>>  	xenbus_notify_running();
>> +#endif
>>  
>>  	/* Main loop. */
>>  	for (;;) {
>> @@ -1957,7 +1977,7 @@ int main(int argc, char *argv[])
>>  			barf_perror("Select failed");
>>  		}
>>  
>> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
>> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>>  			char c;
>>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>>  				barf_perror("read failed");
>> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
>> index c521e52..4243f91 100644
>> --- a/tools/xenstore/xenstored_domain.c
>> +++ b/tools/xenstore/xenstored_domain.c
>> @@ -197,12 +197,16 @@ static int destroy_domain(void *_domain)
>>  	}
>>  
>>  	if (domain->interface) {
>> +#ifdef __MINIOS__
>> +		unmap_interface(domain->interface);
>> +#else
>>  		/* Domain 0 was mapped by dom0_init, so it must be unmapped
>>  		   using munmap() and not the grant unmap call. */
>>  		if (domain->domid == 0)
>>  			munmap(domain->interface, getpagesize());
>>  		else
>>  			unmap_interface(domain->interface);
>> +#endif
>>  	}
>>  
>>  	fire_watches(NULL, "@releaseDomain", false);
>> @@ -597,6 +601,12 @@ void restore_existing_connections(void)
>>  {
>>  }
>>  
>> +#ifdef __MINIOS__
>> +static int dom0_init(void)
>> +{
>> +	return 0;
>> +}
>> +#else
>>  static int dom0_init(void) 
>>  { 
>>  	evtchn_port_t port;
>> @@ -620,6 +630,7 @@ static int dom0_init(void)
>>  
>>  	return 0; 
>>  }
>> +#endif
> 
> another candidate to be moved to xenstored_minios/linux
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 16:36:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 16:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqolm-0003As-MJ; Fri, 27 Jan 2012 16:35:22 +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 1Rqoll-0003A3-5M
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 16:35:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327682067!52023160!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8242 invoked from network); 27 Jan 2012 16:34:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Jan 2012 16:34:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327682116; l=1030;
	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=Oa3b2xFOD1t+Jzoff3yrWE6WrG4=;
	b=LQinCAtQMUZ3SeScYKYtyYTYLL8x6/29VISc/8MaG1OjxUYwL0ubbNsvagH4LBNTNGK
	NF7tXHwWDBfS5ikJTsMa939SCV1xilHHNYg8Hx/2bADhjdxrfjK7RFKGCGdWrEzymI5j0
	BqtsTtMe+Rv0R2o7qR0UbEBNb5Koj43C6oI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhy0MFy6a
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-099-249.pools.arcor-ip.net [88.65.99.249])
	by smtp.strato.de (klopstock mo18) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5003c2o0RGK2OV
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 17:35:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 94A3018634
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 17:35:17 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 34cf64e8b3f099a556b670ca96e0f3f695557a11
Message-Id: <34cf64e8b3f099a556b6.1327682116@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 27 Jan 2012 17:35:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: make file_op largefile aware
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327682076 -3600
# Node ID 34cf64e8b3f099a556b670ca96e0f3f695557a11
# Parent  266a12304601226213a57e39cc11aa075acdfb58
xenpaging: make file_op largefile aware

lseek() takes an off_t, the used "int << shiftsize" does not automatically
convert the int into a larger type. This leads to write errors with pagefiles
larger than 2G. Fix this by shifting an off_t instead of an int.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 266a12304601 -r 34cf64e8b3f0 tools/xenpaging/file_ops.c
--- a/tools/xenpaging/file_ops.c
+++ b/tools/xenpaging/file_ops.c
@@ -26,12 +26,12 @@
 static int file_op(int fd, void *page, int i,
                    ssize_t (*fn)(int, void *, size_t))
 {
-    off_t seek_ret;
+    off_t offset = i;
     int total = 0;
     int bytes;
 
-    seek_ret = lseek(fd, i << PAGE_SHIFT, SEEK_SET);
-    if ( seek_ret == (off_t)-1 )
+    offset = lseek(fd, offset << PAGE_SHIFT, SEEK_SET);
+    if ( offset == (off_t)-1 )
         return -1;
 
     while ( total < PAGE_SIZE )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 16:36:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 16:36:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqolm-0003As-MJ; Fri, 27 Jan 2012 16:35:22 +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 1Rqoll-0003A3-5M
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 16:35:21 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327682067!52023160!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAzMTAxNzY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8242 invoked from network); 27 Jan 2012 16:34:28 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-5.tower-27.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 27 Jan 2012 16:34:28 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327682116; l=1030;
	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=Oa3b2xFOD1t+Jzoff3yrWE6WrG4=;
	b=LQinCAtQMUZ3SeScYKYtyYTYLL8x6/29VISc/8MaG1OjxUYwL0ubbNsvagH4LBNTNGK
	NF7tXHwWDBfS5ikJTsMa939SCV1xilHHNYg8Hx/2bADhjdxrfjK7RFKGCGdWrEzymI5j0
	BqtsTtMe+Rv0R2o7qR0UbEBNb5Koj43C6oI=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHhy0MFy6a
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-099-249.pools.arcor-ip.net [88.65.99.249])
	by smtp.strato.de (klopstock mo18) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 5003c2o0RGK2OV
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 17:35:15 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 94A3018634
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 17:35:17 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 34cf64e8b3f099a556b670ca96e0f3f695557a11
Message-Id: <34cf64e8b3f099a556b6.1327682116@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Fri, 27 Jan 2012 17:35:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: make file_op largefile aware
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327682076 -3600
# Node ID 34cf64e8b3f099a556b670ca96e0f3f695557a11
# Parent  266a12304601226213a57e39cc11aa075acdfb58
xenpaging: make file_op largefile aware

lseek() takes an off_t, the used "int << shiftsize" does not automatically
convert the int into a larger type. This leads to write errors with pagefiles
larger than 2G. Fix this by shifting an off_t instead of an int.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 266a12304601 -r 34cf64e8b3f0 tools/xenpaging/file_ops.c
--- a/tools/xenpaging/file_ops.c
+++ b/tools/xenpaging/file_ops.c
@@ -26,12 +26,12 @@
 static int file_op(int fd, void *page, int i,
                    ssize_t (*fn)(int, void *, size_t))
 {
-    off_t seek_ret;
+    off_t offset = i;
     int total = 0;
     int bytes;
 
-    seek_ret = lseek(fd, i << PAGE_SHIFT, SEEK_SET);
-    if ( seek_ret == (off_t)-1 )
+    offset = lseek(fd, offset << PAGE_SHIFT, SEEK_SET);
+    if ( offset == (off_t)-1 )
         return -1;
 
     while ( total < PAGE_SIZE )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 16:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 16:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqoq3-0003Sx-Cg; Fri, 27 Jan 2012 16:39: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 1Rqoq1-0003Sc-Q5
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 16:39:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327682379!5246518!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23002 invoked from network); 27 Jan 2012 16:39:39 -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;
	27 Jan 2012 16:39:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10337822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 16:39:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 16:39:39 +0000
Date: Fri, 27 Jan 2012 16:40:40 +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: <4F22CCAE.3000808@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201271632430.3196@kaball-desktop>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
	<4F22CCAE.3000808@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Daniel De Graaf wrote:
> >> @@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
> >>  }
> >>  
> >>  
> >> +#ifdef __MINIOS__
> >> +static void write_pidfile(const char *pidfile)
> >> +{
> >> +}
> >> +
> >> +static void daemonize(void)
> >> +{
> >> +}
> >> +
> >> +static void finish_daemonize(void)
> >> +{
> >> +}
> >> +#else
> >>  static void write_pidfile(const char *pidfile)
> >>  {
> >>  	char buf[100];
> >> @@ -1711,6 +1724,19 @@ static void daemonize(void)
> >>  	umask(0);
> >>  }
> >>  
> >> +static void finish_daemonize(void)
> >> +{
> >> +	int devnull = open("/dev/null", O_RDWR);
> >> +	if (devnull == -1)
> >> +		barf_perror("Could not open /dev/null\n");
> >> +	dup2(devnull, STDIN_FILENO);
> >> +	dup2(devnull, STDOUT_FILENO);
> >> +	dup2(devnull, STDERR_FILENO);
> >> +	close(devnull);
> >> +	xprintf = trace;
> >> +}
> >> +#endif
> >> +
> >>  #ifdef NO_SOCKETS
> >>  static void init_sockets(int **psock, int **pro_sock)
> >>  {
> > 
> > At this point we could have the MiniOS version of write_pidfile,
> > daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and the
> > Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c.
> > 
> 
> Are you suggesting this for just these functions, or all functions that are
> different on minios?

All the functions that are different on minios and these three in
particular.


> Since we already have xenstored_{linux,netbsd,solaris}.c, should the POSIX
> versions be duplicated or placed in a common POSIX file (as Ian suggested)?

Better not duplicating code when possible, so I support Ian's idea.



> >> ---
> >>  tools/xenstore/Makefile           |    9 ++++-
> >>  tools/xenstore/utils.h            |    2 +
> >>  tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
> >>  tools/xenstore/xenstored_domain.c |   11 +++++
> >>  4 files changed, 68 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> >> index 4facb62..be892fd 100644
> >> --- a/tools/xenstore/Makefile
> >> +++ b/tools/xenstore/Makefile
> >> @@ -28,6 +28,10 @@ endif
> >>  
> >>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
> >>  
> >> +ifdef CONFIG_STUBDOM
> >> +CFLAGS += -DNO_SOCKETS=1
> >> +endif
> > 
> >> @@ -1822,6 +1848,11 @@ int main(int argc, char *argv[])
> >>  	int evtchn_fd = -1;
> >>  	struct timeval *timeout;
> >>  
> >> +#ifdef __MINIOS__
> >> +	/* minios always uses internal DB */
> >> +	tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
> >> +#endif
> > 
> > can you use the "internal-db" command line option?
> > 
> 
> Yes, but that begins to clutter up the xenstore stub domain's command line
> with mandatory options (which seems self-contradictory).

I can see your point, but they are not mandatory per se: it is possible
to have a fully working POSIX open/read/write interface implementation
on top of Minios one day.  For example the files could reside entirely
in memory, a bit like tmpfs.


> >>  	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
> >>  				  NULL)) != -1) {
> >>  		switch (opt) {
> >> @@ -1874,20 +1905,10 @@ int main(int argc, char *argv[])
> >>  
> >>  	reopen_log();
> >>  
> >> -	/* make sure xenstored directory exists */
> >> -	if (mkdir(xs_daemon_rundir(), 0755)) {
> >> -		if (errno != EEXIST) {
> >> -			perror("error: mkdir daemon rundir");
> >> -			exit(-1);
> >> -		}
> >> -	}
> >> -
> >> -	if (mkdir(xs_daemon_rootdir(), 0755)) {
> >> -		if (errno != EEXIST) {
> >> -			perror("error: mkdir daemon rootdir");
> >> -			exit(-1);
> >> -		}
> >> -	}
> >> +	/* make sure xenstored directories exist */
> >> +	/* Errors ignored here, will be reported when we open files */
> >> +	mkdir(xs_daemon_rundir(), 0755);
> >> +	mkdir(xs_daemon_rootdir(), 0755);
> >>  
> >>  	if (dofork) {
> >>  		openlog("xenstored", 0, LOG_DAEMON);
> >> @@ -1905,9 +1926,14 @@ int main(int argc, char *argv[])
> >>  
> >>  	init_sockets(&sock, &ro_sock);
> >>  
> >> +#ifdef __MINIOS__
> >> +	reopen_log_pipe[0] = -1;
> >> +	reopen_log_pipe[1] = -1;
> >> +#else
> >>  	if (pipe(reopen_log_pipe)) {
> >>  		barf_perror("pipe");
> >>  	}
> >> +#endif
> > 
> > maybe we could have open/read/write_log_pipe functions?
> 
> That would be useless here, since the pipe is only used to receive signals
> (which minios can't do) in order to reopen a log file that minios doesn't open.

In that case Minios' implementaton would just be empty.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 16:40:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 16:40:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqoq3-0003Sx-Cg; Fri, 27 Jan 2012 16:39: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 1Rqoq1-0003Sc-Q5
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 16:39:46 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327682379!5246518!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23002 invoked from network); 27 Jan 2012 16:39:39 -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;
	27 Jan 2012 16:39:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10337822"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 16:39:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 16:39:39 +0000
Date: Fri, 27 Jan 2012 16:40:40 +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: <4F22CCAE.3000808@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201271632430.3196@kaball-desktop>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-20-git-send-email-dgdegra@tycho.nsa.gov>
	<alpine.DEB.2.00.1201271115030.3196@kaball-desktop>
	<4F22CCAE.3000808@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>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
 stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Daniel De Graaf wrote:
> >> @@ -1664,6 +1664,19 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
> >>  }
> >>  
> >>  
> >> +#ifdef __MINIOS__
> >> +static void write_pidfile(const char *pidfile)
> >> +{
> >> +}
> >> +
> >> +static void daemonize(void)
> >> +{
> >> +}
> >> +
> >> +static void finish_daemonize(void)
> >> +{
> >> +}
> >> +#else
> >>  static void write_pidfile(const char *pidfile)
> >>  {
> >>  	char buf[100];
> >> @@ -1711,6 +1724,19 @@ static void daemonize(void)
> >>  	umask(0);
> >>  }
> >>  
> >> +static void finish_daemonize(void)
> >> +{
> >> +	int devnull = open("/dev/null", O_RDWR);
> >> +	if (devnull == -1)
> >> +		barf_perror("Could not open /dev/null\n");
> >> +	dup2(devnull, STDIN_FILENO);
> >> +	dup2(devnull, STDOUT_FILENO);
> >> +	dup2(devnull, STDERR_FILENO);
> >> +	close(devnull);
> >> +	xprintf = trace;
> >> +}
> >> +#endif
> >> +
> >>  #ifdef NO_SOCKETS
> >>  static void init_sockets(int **psock, int **pro_sock)
> >>  {
> > 
> > At this point we could have the MiniOS version of write_pidfile,
> > daemonize, finish_daemonize in tools/xenstore/xenstored_minios.c and the
> > Linux/NetBSD version of them in tools/xenstore/xenstored_linux.c.
> > 
> 
> Are you suggesting this for just these functions, or all functions that are
> different on minios?

All the functions that are different on minios and these three in
particular.


> Since we already have xenstored_{linux,netbsd,solaris}.c, should the POSIX
> versions be duplicated or placed in a common POSIX file (as Ian suggested)?

Better not duplicating code when possible, so I support Ian's idea.



> >> ---
> >>  tools/xenstore/Makefile           |    9 ++++-
> >>  tools/xenstore/utils.h            |    2 +
> >>  tools/xenstore/xenstored_core.c   |   74 +++++++++++++++++++++++-------------
> >>  tools/xenstore/xenstored_domain.c |   11 +++++
> >>  4 files changed, 68 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> >> index 4facb62..be892fd 100644
> >> --- a/tools/xenstore/Makefile
> >> +++ b/tools/xenstore/Makefile
> >> @@ -28,6 +28,10 @@ endif
> >>  
> >>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
> >>  
> >> +ifdef CONFIG_STUBDOM
> >> +CFLAGS += -DNO_SOCKETS=1
> >> +endif
> > 
> >> @@ -1822,6 +1848,11 @@ int main(int argc, char *argv[])
> >>  	int evtchn_fd = -1;
> >>  	struct timeval *timeout;
> >>  
> >> +#ifdef __MINIOS__
> >> +	/* minios always uses internal DB */
> >> +	tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
> >> +#endif
> > 
> > can you use the "internal-db" command line option?
> > 
> 
> Yes, but that begins to clutter up the xenstore stub domain's command line
> with mandatory options (which seems self-contradictory).

I can see your point, but they are not mandatory per se: it is possible
to have a fully working POSIX open/read/write interface implementation
on top of Minios one day.  For example the files could reside entirely
in memory, a bit like tmpfs.


> >>  	while ((opt = getopt_long(argc, argv, "DE:F:HNPS:t:T:RLVW:", options,
> >>  				  NULL)) != -1) {
> >>  		switch (opt) {
> >> @@ -1874,20 +1905,10 @@ int main(int argc, char *argv[])
> >>  
> >>  	reopen_log();
> >>  
> >> -	/* make sure xenstored directory exists */
> >> -	if (mkdir(xs_daemon_rundir(), 0755)) {
> >> -		if (errno != EEXIST) {
> >> -			perror("error: mkdir daemon rundir");
> >> -			exit(-1);
> >> -		}
> >> -	}
> >> -
> >> -	if (mkdir(xs_daemon_rootdir(), 0755)) {
> >> -		if (errno != EEXIST) {
> >> -			perror("error: mkdir daemon rootdir");
> >> -			exit(-1);
> >> -		}
> >> -	}
> >> +	/* make sure xenstored directories exist */
> >> +	/* Errors ignored here, will be reported when we open files */
> >> +	mkdir(xs_daemon_rundir(), 0755);
> >> +	mkdir(xs_daemon_rootdir(), 0755);
> >>  
> >>  	if (dofork) {
> >>  		openlog("xenstored", 0, LOG_DAEMON);
> >> @@ -1905,9 +1926,14 @@ int main(int argc, char *argv[])
> >>  
> >>  	init_sockets(&sock, &ro_sock);
> >>  
> >> +#ifdef __MINIOS__
> >> +	reopen_log_pipe[0] = -1;
> >> +	reopen_log_pipe[1] = -1;
> >> +#else
> >>  	if (pipe(reopen_log_pipe)) {
> >>  		barf_perror("pipe");
> >>  	}
> >> +#endif
> > 
> > maybe we could have open/read/write_log_pipe functions?
> 
> That would be useless here, since the pipe is only used to receive signals
> (which minios can't do) in order to reopen a log file that minios doesn't open.

In that case Minios' implementaton would just be empty.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 17:08:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqpGq-0003zZ-Oq; Fri, 27 Jan 2012 17:07:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqpGo-0003zU-SL
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:07:27 +0000
Received: from [85.158.138.51:10019] by server-4.bemta-3.messagelabs.com id
	DE/50-32238-EC9D22F4; Fri, 27 Jan 2012 17:07:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327684045!10974020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5971 invoked from network); 27 Jan 2012 17:07: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;
	27 Jan 2012 17:07:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10338426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:07:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:07: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
	1RqpGm-0004y9-TG; Fri, 27 Jan 2012 17:07:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqpGm-0004RL-MT;
	Fri, 27 Jan 2012 17:07:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.55756.426756.370852@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 17:07:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327677943.26983.186.camel@zakaz.uk.xensource.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327677943.26983.186.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 v8 00/11] libxl: 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 v8 00/11] libxl: New event API"):
> On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> > There are a couple of hopefully uncontroversial new patches on the
> > front of this series:
> > 
> >  01/11 .gitignore/.hgignore: New names for ioemu dirs, seabios
> >  02/11 xl: fix a couple of memory leaks
> > 
> > The remainder of the series is very similar to previous versions.
> >  - Changes have been made as discussed on the list, plus:
> 
> Given that I'm happy to:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks, I have applied all 11.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 17:08:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17:08:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqpGq-0003zZ-Oq; Fri, 27 Jan 2012 17:07:28 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqpGo-0003zU-SL
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:07:27 +0000
Received: from [85.158.138.51:10019] by server-4.bemta-3.messagelabs.com id
	DE/50-32238-EC9D22F4; Fri, 27 Jan 2012 17:07:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327684045!10974020!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5971 invoked from network); 27 Jan 2012 17:07: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;
	27 Jan 2012 17:07:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10338426"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:07:25 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:07: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
	1RqpGm-0004y9-TG; Fri, 27 Jan 2012 17:07:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqpGm-0004RL-MT;
	Fri, 27 Jan 2012 17:07:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.55756.426756.370852@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 17:07:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327677943.26983.186.camel@zakaz.uk.xensource.com>
References: <1327598457-28261-1-git-send-email-ian.jackson@eu.citrix.com>
	<1327677943.26983.186.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 v8 00/11] libxl: 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 v8 00/11] libxl: New event API"):
> On Thu, 2012-01-26 at 17:20 +0000, Ian Jackson wrote:
> > There are a couple of hopefully uncontroversial new patches on the
> > front of this series:
> > 
> >  01/11 .gitignore/.hgignore: New names for ioemu dirs, seabios
> >  02/11 xl: fix a couple of memory leaks
> > 
> > The remainder of the series is very similar to previous versions.
> >  - Changes have been made as discussed on the list, plus:
> 
> Given that I'm happy to:
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Thanks, I have applied all 11.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 17:09:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17: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 1RqpIZ-00043V-7u; Fri, 27 Jan 2012 17:09:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqpIY-00043P-9a
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:09:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327684100!54339500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9687 invoked from network); 27 Jan 2012 17:08:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 17:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10338456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:09:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:09: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
	1RqpIW-0004yp-VV; Fri, 27 Jan 2012 17:09:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqpIW-0004Ri-Uj;
	Fri, 27 Jan 2012 17:09:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.55864.920645.170102@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 17:09:12 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <f16bb1c3117a12acb1ed.1327669940@cosworth.uk.xensource.com>
References: <f16bb1c3117a12acb1ed.1327669940@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix upstream qemu binary name to
 what we actually install
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] libxl: fix upstream qemu binary name to what we actually install"):
> libxl: fix upstream qemu binary name to what we actually install

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 Jan 27 17:09:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17: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 1RqpIZ-00043V-7u; Fri, 27 Jan 2012 17:09:15 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RqpIY-00043P-9a
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:09:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327684100!54339500!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9687 invoked from network); 27 Jan 2012 17:08:20 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 17:08:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,580,1320624000"; d="scan'208";a="10338456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:09:13 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:09: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
	1RqpIW-0004yp-VV; Fri, 27 Jan 2012 17:09:13 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqpIW-0004Ri-Uj;
	Fri, 27 Jan 2012 17:09:12 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.55864.920645.170102@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 17:09:12 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <f16bb1c3117a12acb1ed.1327669940@cosworth.uk.xensource.com>
References: <f16bb1c3117a12acb1ed.1327669940@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>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] libxl: fix upstream qemu binary name to
 what we actually install
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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] libxl: fix upstream qemu binary name to what we actually install"):
> libxl: fix upstream qemu binary name to what we actually install

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 Jan 27 17:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 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 1RqpOy-0004Kr-Fu; Fri, 27 Jan 2012 17:15:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqpOw-0004Kj-Lz
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:15:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327684544!12759539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6636 invoked from network); 27 Jan 2012 17:15:44 -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;
	27 Jan 2012 17:15:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10338552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:15:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:15:44 +0000
Date: Fri, 27 Jan 2012 17:16:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120127160355.GA566@andromeda.dapyr.net>
Message-ID: <alpine.DEB.2.00.1201271713200.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120127160355.GA566@andromeda.dapyr.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 26, 2012 at 12:43:27PM +0000, Stefano Stabellini wrote:
> > This patch implements support for multiple consoles:
> > consoles other than the first one are setup using the traditional xenbus
> > and grant-table based mechanism.
> > We use a list to keep track of the allocated consoles, we don't
> > expect too many of them anyway.
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
> >  1 files changed, 383 insertions(+), 56 deletions(-)
> >
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index dd6641f..97732fb 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -23,6 +23,7 @@
> >  #include <linux/err.h>
> >  #include <linux/init.h>
> >  #include <linux/types.h>
> > +#include <linux/list.h>
> >
> >  #include <asm/io.h>
> >  #include <asm/xen/hypervisor.h>
> > @@ -30,47 +31,69 @@
> >  #include <xen/xen.h>
> >  #include <xen/interface/xen.h>
> >  #include <xen/hvm.h>
> > +#include <xen/grant_table.h>
> >  #include <xen/page.h>
> >  #include <xen/events.h>
> >  #include <xen/interface/io/console.h>
> >  #include <xen/hvc-console.h>
> > +#include <xen/xenbus.h>
> >
> >  #include "hvc_console.h"
> >
> >  #define HVC_COOKIE   0x58656e /* "Xen" in hex */
> >
> > -static struct hvc_struct *hvc;
> > -static int xencons_irq;
> > +struct xencons_info {
> > +     struct list_head list;
> > +     struct xenbus_device *xbdev;
> > +     struct xencons_interface *intf;
> > +     unsigned int evtchn;
> > +     struct hvc_struct *hvc;
> > +     int irq;
> > +     int vtermno;
> > +     grant_ref_t gntref;
> > +};
> > +
> > +static LIST_HEAD(xenconsoles);
> > +static DEFINE_SPINLOCK(xencons_lock);
> > +static struct xenbus_driver xencons_driver;
> >
> >  /* ------------------------------------------------------------------ */
> >
> > -static unsigned long console_pfn = ~0ul;
> > -static unsigned int console_evtchn = ~0ul;
> > -static struct xencons_interface *xencons_if = NULL;
> > +static struct xencons_info *vtermno_to_xencons(int vtermno)
> > +{
> > +     struct xencons_info *entry, *ret = NULL;
> > +
> > +     if (list_empty(&xenconsoles))
> > +                     return NULL;
> >
> > -static inline struct xencons_interface *xencons_interface(void)
> > +     spin_lock(&xencons_lock);
> 
> This spinlock gets hit everytime something is typed or written on the
> console right? Isn't there an spinlock already in the hvc driver...
> 
> Or are we protected by the vtermnos being checked for -1?

I think you are right: the spinlock is there to protect access to the
list, so we can change list_for_each_entry to list_for_each_entry_safe
in vtermno_to_xencons and we solve the problem. All the other spinlock
acquisitions are done at console creation/destruction.


> > +     list_for_each_entry(entry, &xenconsoles, list) {
> > +             if (entry->vtermno == vtermno) {
> > +                     ret  = entry;
> > +                     break;
> > +             }
> > +     }
> > +     spin_unlock(&xencons_lock);
> > +
> > +     return ret;
> > +}
> > +
> > +static inline int xenbus_devid_to_vtermno(int devid)
> >  {
> > -     if (xencons_if != NULL)
> > -             return xencons_if;
> > -     if (console_pfn == ~0ul)
> > -             return mfn_to_virt(xen_start_info->console.domU.mfn);
> > -     else
> > -             return __va(console_pfn << PAGE_SHIFT);
> > +     return devid + HVC_COOKIE;
> >  }
> >
> > -static inline void notify_daemon(void)
> > +static inline void notify_daemon(struct xencons_info *cons)
> >  {
> >       /* Use evtchn: this is called early, before irq is set up. */
> > -     if (console_evtchn == ~0ul)
> > -             notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> > -     else
> > -             notify_remote_via_evtchn(console_evtchn);
> > +     notify_remote_via_evtchn(cons->evtchn);
> >  }
> >
> > -static int __write_console(const char *data, int len)
> > +static int __write_console(struct xencons_info *xencons,
> > +             const char *data, int len)
> >  {
> > -     struct xencons_interface *intf = xencons_interface();
> >       XENCONS_RING_IDX cons, prod;
> > +     struct xencons_interface *intf = xencons->intf;
> >       int sent = 0;
> >
> >       cons = intf->out_cons;
> > @@ -85,13 +108,16 @@ static int __write_console(const char *data, int len)
> >       intf->out_prod = prod;
> >
> >       if (sent)
> > -             notify_daemon();
> > +             notify_daemon(xencons);
> >       return sent;
> >  }
> >
> >  static int domU_write_console(uint32_t vtermno, const char *data, int len)
> >  {
> >       int ret = len;
> > +     struct xencons_info *cons = vtermno_to_xencons(vtermno);
> > +     if (cons == NULL)
> > +             return -EINVAL;
> >
> >       /*
> >        * Make sure the whole buffer is emitted, polling if
> > @@ -100,7 +126,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
> >        * kernel is crippled.
> >        */
> >       while (len) {
> > -             int sent = __write_console(data, len);
> > +             int sent = __write_console(cons, data, len);
> >
> >               data += sent;
> >               len -= sent;
> > @@ -114,9 +140,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
> >
> >  static int domU_read_console(uint32_t vtermno, char *buf, int len)
> >  {
> > -     struct xencons_interface *intf = xencons_interface();
> > +     struct xencons_interface *intf;
> >       XENCONS_RING_IDX cons, prod;
> >       int recv = 0;
> > +     struct xencons_info *xencons = vtermno_to_xencons(vtermno);
> > +     if (xencons == NULL)
> > +             return -EINVAL;
> > +     intf = xencons->intf;
> >
> >       cons = intf->in_cons;
> >       prod = intf->in_prod;
> > @@ -129,7 +159,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
> >       mb();                   /* read ring before consuming */
> >       intf->in_cons = cons;
> >
> > -     notify_daemon();
> > +     notify_daemon(xencons);
> >       return recv;
> >  }
> >
> > @@ -172,33 +202,109 @@ static int xen_hvm_console_init(void)
> >       int r;
> >       uint64_t v = 0;
> >       unsigned long mfn;
> > +     struct xencons_info *info;
> >
> >       if (!xen_hvm_domain())
> >               return -ENODEV;
> >
> > -     if (xencons_if != NULL)
> > -             return -EBUSY;
> > +     info = vtermno_to_xencons(HVC_COOKIE);
> > +     if (!info) {
> > +             info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> > +             if (!info)
> > +                     return -ENOMEM;
> > +     }
> > +
> > +     /* already configured */
> > +     if (info->intf != NULL)
> > +             return 0;
> >
> >       r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> > -     if (r < 0)
> > +     if (r < 0) {
> > +             kfree(info);
> >               return -ENODEV;
> > -     console_evtchn = v;
> > +     }
> > +     info->evtchn = v;
> >       hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> > -     if (r < 0)
> > +     if (r < 0) {
> > +             kfree(info);
> >               return -ENODEV;
> > +     }
> >       mfn = v;
> > -     xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > -     if (xencons_if == NULL)
> > +     info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > +     if (info->intf == NULL) {
> > +             kfree(info);
> > +             return -ENODEV;
> > +     }
> > +     info->vtermno = HVC_COOKIE;
> > +
> > +     spin_lock(&xencons_lock);
> > +     list_add_tail(&info->list, &xenconsoles);
> > +     spin_unlock(&xencons_lock);
> > +
> > +     return 0;
> > +}
> > +
> > +static int xen_pv_console_init(void)
> > +{
> > +     struct xencons_info *info;
> > +
> > +     if (!xen_pv_domain())
> >               return -ENODEV;
> >
> > +     if (!xen_start_info->console.domU.evtchn)
> > +             return -ENODEV;
> > +
> > +     info = vtermno_to_xencons(HVC_COOKIE);
> > +     if (!info) {
> > +             info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> 
> Ugh. Use kzalloc here. Especially as you are testing it below (and
> kmalloc with certain CONFIG_DEBUG.. can make the the returned memory
> have bogus data.

OK


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 17:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 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 1RqpOy-0004Kr-Fu; Fri, 27 Jan 2012 17:15:52 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqpOw-0004Kj-Lz
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:15:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327684544!12759539!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6636 invoked from network); 27 Jan 2012 17:15:44 -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;
	27 Jan 2012 17:15:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10338552"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:15:44 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:15:44 +0000
Date: Fri, 27 Jan 2012 17:16:45 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad@darnok.org>
In-Reply-To: <20120127160355.GA566@andromeda.dapyr.net>
Message-ID: <alpine.DEB.2.00.1201271713200.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120127160355.GA566@andromeda.dapyr.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 26, 2012 at 12:43:27PM +0000, Stefano Stabellini wrote:
> > This patch implements support for multiple consoles:
> > consoles other than the first one are setup using the traditional xenbus
> > and grant-table based mechanism.
> > We use a list to keep track of the allocated consoles, we don't
> > expect too many of them anyway.
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
> >  1 files changed, 383 insertions(+), 56 deletions(-)
> >
> > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > index dd6641f..97732fb 100644
> > --- a/drivers/tty/hvc/hvc_xen.c
> > +++ b/drivers/tty/hvc/hvc_xen.c
> > @@ -23,6 +23,7 @@
> >  #include <linux/err.h>
> >  #include <linux/init.h>
> >  #include <linux/types.h>
> > +#include <linux/list.h>
> >
> >  #include <asm/io.h>
> >  #include <asm/xen/hypervisor.h>
> > @@ -30,47 +31,69 @@
> >  #include <xen/xen.h>
> >  #include <xen/interface/xen.h>
> >  #include <xen/hvm.h>
> > +#include <xen/grant_table.h>
> >  #include <xen/page.h>
> >  #include <xen/events.h>
> >  #include <xen/interface/io/console.h>
> >  #include <xen/hvc-console.h>
> > +#include <xen/xenbus.h>
> >
> >  #include "hvc_console.h"
> >
> >  #define HVC_COOKIE   0x58656e /* "Xen" in hex */
> >
> > -static struct hvc_struct *hvc;
> > -static int xencons_irq;
> > +struct xencons_info {
> > +     struct list_head list;
> > +     struct xenbus_device *xbdev;
> > +     struct xencons_interface *intf;
> > +     unsigned int evtchn;
> > +     struct hvc_struct *hvc;
> > +     int irq;
> > +     int vtermno;
> > +     grant_ref_t gntref;
> > +};
> > +
> > +static LIST_HEAD(xenconsoles);
> > +static DEFINE_SPINLOCK(xencons_lock);
> > +static struct xenbus_driver xencons_driver;
> >
> >  /* ------------------------------------------------------------------ */
> >
> > -static unsigned long console_pfn = ~0ul;
> > -static unsigned int console_evtchn = ~0ul;
> > -static struct xencons_interface *xencons_if = NULL;
> > +static struct xencons_info *vtermno_to_xencons(int vtermno)
> > +{
> > +     struct xencons_info *entry, *ret = NULL;
> > +
> > +     if (list_empty(&xenconsoles))
> > +                     return NULL;
> >
> > -static inline struct xencons_interface *xencons_interface(void)
> > +     spin_lock(&xencons_lock);
> 
> This spinlock gets hit everytime something is typed or written on the
> console right? Isn't there an spinlock already in the hvc driver...
> 
> Or are we protected by the vtermnos being checked for -1?

I think you are right: the spinlock is there to protect access to the
list, so we can change list_for_each_entry to list_for_each_entry_safe
in vtermno_to_xencons and we solve the problem. All the other spinlock
acquisitions are done at console creation/destruction.


> > +     list_for_each_entry(entry, &xenconsoles, list) {
> > +             if (entry->vtermno == vtermno) {
> > +                     ret  = entry;
> > +                     break;
> > +             }
> > +     }
> > +     spin_unlock(&xencons_lock);
> > +
> > +     return ret;
> > +}
> > +
> > +static inline int xenbus_devid_to_vtermno(int devid)
> >  {
> > -     if (xencons_if != NULL)
> > -             return xencons_if;
> > -     if (console_pfn == ~0ul)
> > -             return mfn_to_virt(xen_start_info->console.domU.mfn);
> > -     else
> > -             return __va(console_pfn << PAGE_SHIFT);
> > +     return devid + HVC_COOKIE;
> >  }
> >
> > -static inline void notify_daemon(void)
> > +static inline void notify_daemon(struct xencons_info *cons)
> >  {
> >       /* Use evtchn: this is called early, before irq is set up. */
> > -     if (console_evtchn == ~0ul)
> > -             notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> > -     else
> > -             notify_remote_via_evtchn(console_evtchn);
> > +     notify_remote_via_evtchn(cons->evtchn);
> >  }
> >
> > -static int __write_console(const char *data, int len)
> > +static int __write_console(struct xencons_info *xencons,
> > +             const char *data, int len)
> >  {
> > -     struct xencons_interface *intf = xencons_interface();
> >       XENCONS_RING_IDX cons, prod;
> > +     struct xencons_interface *intf = xencons->intf;
> >       int sent = 0;
> >
> >       cons = intf->out_cons;
> > @@ -85,13 +108,16 @@ static int __write_console(const char *data, int len)
> >       intf->out_prod = prod;
> >
> >       if (sent)
> > -             notify_daemon();
> > +             notify_daemon(xencons);
> >       return sent;
> >  }
> >
> >  static int domU_write_console(uint32_t vtermno, const char *data, int len)
> >  {
> >       int ret = len;
> > +     struct xencons_info *cons = vtermno_to_xencons(vtermno);
> > +     if (cons == NULL)
> > +             return -EINVAL;
> >
> >       /*
> >        * Make sure the whole buffer is emitted, polling if
> > @@ -100,7 +126,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
> >        * kernel is crippled.
> >        */
> >       while (len) {
> > -             int sent = __write_console(data, len);
> > +             int sent = __write_console(cons, data, len);
> >
> >               data += sent;
> >               len -= sent;
> > @@ -114,9 +140,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
> >
> >  static int domU_read_console(uint32_t vtermno, char *buf, int len)
> >  {
> > -     struct xencons_interface *intf = xencons_interface();
> > +     struct xencons_interface *intf;
> >       XENCONS_RING_IDX cons, prod;
> >       int recv = 0;
> > +     struct xencons_info *xencons = vtermno_to_xencons(vtermno);
> > +     if (xencons == NULL)
> > +             return -EINVAL;
> > +     intf = xencons->intf;
> >
> >       cons = intf->in_cons;
> >       prod = intf->in_prod;
> > @@ -129,7 +159,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
> >       mb();                   /* read ring before consuming */
> >       intf->in_cons = cons;
> >
> > -     notify_daemon();
> > +     notify_daemon(xencons);
> >       return recv;
> >  }
> >
> > @@ -172,33 +202,109 @@ static int xen_hvm_console_init(void)
> >       int r;
> >       uint64_t v = 0;
> >       unsigned long mfn;
> > +     struct xencons_info *info;
> >
> >       if (!xen_hvm_domain())
> >               return -ENODEV;
> >
> > -     if (xencons_if != NULL)
> > -             return -EBUSY;
> > +     info = vtermno_to_xencons(HVC_COOKIE);
> > +     if (!info) {
> > +             info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> > +             if (!info)
> > +                     return -ENOMEM;
> > +     }
> > +
> > +     /* already configured */
> > +     if (info->intf != NULL)
> > +             return 0;
> >
> >       r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> > -     if (r < 0)
> > +     if (r < 0) {
> > +             kfree(info);
> >               return -ENODEV;
> > -     console_evtchn = v;
> > +     }
> > +     info->evtchn = v;
> >       hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> > -     if (r < 0)
> > +     if (r < 0) {
> > +             kfree(info);
> >               return -ENODEV;
> > +     }
> >       mfn = v;
> > -     xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > -     if (xencons_if == NULL)
> > +     info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> > +     if (info->intf == NULL) {
> > +             kfree(info);
> > +             return -ENODEV;
> > +     }
> > +     info->vtermno = HVC_COOKIE;
> > +
> > +     spin_lock(&xencons_lock);
> > +     list_add_tail(&info->list, &xenconsoles);
> > +     spin_unlock(&xencons_lock);
> > +
> > +     return 0;
> > +}
> > +
> > +static int xen_pv_console_init(void)
> > +{
> > +     struct xencons_info *info;
> > +
> > +     if (!xen_pv_domain())
> >               return -ENODEV;
> >
> > +     if (!xen_start_info->console.domU.evtchn)
> > +             return -ENODEV;
> > +
> > +     info = vtermno_to_xencons(HVC_COOKIE);
> > +     if (!info) {
> > +             info = kmalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
> 
> Ugh. Use kzalloc here. Especially as you are testing it below (and
> kmalloc with certain CONFIG_DEBUG.. can make the the returned memory
> have bogus data.

OK


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 17:33:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqpfD-0004no-BE; Fri, 27 Jan 2012 17:32:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jbarnes@virtuousgeek.org>) id 1RqpfB-0004nj-0j
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:32:37 +0000
X-Env-Sender: jbarnes@virtuousgeek.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327685549!12761450!1
X-Originating-IP: [67.222.55.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuNTUuOSA9PiA0MjU5Ng==\n,sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuNTUuOSA9PiA0MjU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21915 invoked from network); 27 Jan 2012 17:32:30 -0000
Received: from oproxy7-pub.bluehost.com (HELO oproxy7-pub.bluehost.com)
	(67.222.55.9) by server-10.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 17:32:30 -0000
Received: (qmail 1111 invoked by uid 0); 27 Jan 2012 17:32:29 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114)
	by oproxy7.bluehost.com with SMTP; 27 Jan 2012 17:32:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=virtuousgeek.org; s=default; 
	h=Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date;
	bh=SfBjHi+gkTKPVkfSOYcxDhyryC7g6FnLEGXyNQBbW5o=; 
	b=BOKu6xEG6wJIoxrlodiVLQ5l8PPJCxp5Ib2+ugoA7Y0mKk76mqASSvYvwGO1uAXp/fzppUmaZ7OOnzlHvYnHRubbrhnxH2Ev2qj7cK2IOTRIYARrPAby8v6II4g+fqX1;
Received: from c-67-161-37-189.hsd1.ca.comcast.net ([67.161.37.189]
	helo=jbarnes-desktop)
	by box514.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.76) (envelope-from <jbarnes@virtuousgeek.org>)
	id 1Rqpf2-00070G-5b; Fri, 27 Jan 2012 10:32:28 -0700
Date: Fri, 27 Jan 2012 09:32:25 -0800
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120127093225.7c1194ae@jbarnes-desktop>
In-Reply-To: <1326388007-19178-2-git-send-email-konrad.wilk@oracle.com>
References: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
	<1326388007-19178-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu)
Mime-Version: 1.0
X-Identified-User: {10642:box514.bluehost.com:virtuous:virtuousgeek.org}
	{sentby:smtp auth 67.161.37.189 authed with
	jbarnes@virtuousgeek.org}
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/2] pci: Introduce
 __pci_reset_function_locked to be used when holding device_lock.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4450737634303452239=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4450737634303452239==
Content-Type: multipart/signed; micalg=PGP-SHA1;
 boundary="Sig_/wOU34tgT+IIj2Ug/yepQ1AI"; protocol="application/pgp-signature"

--Sig_/wOU34tgT+IIj2Ug/yepQ1AI
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 12 Jan 2012 12:06:46 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> The use case of this is when a driver wants to call FLR when a device
> is attached to it using the SysFS "bind" or "unbind" functionality.
>=20
> The call chain when a user does "bind" looks as so:
>=20
>  echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind
>=20
> and ends up calling:
>   driver_bind:
>     device_lock(dev);  <=3D=3D=3D TAKES LOCK
>     XXXX_probe:
>          .. pci_enable_device()
>          ...__pci_reset_function(), which calls
>                  pci_dev_reset(dev, 0):
>                         if (!0) {
>                                 device_lock(dev) <=3D=3D=3D=3D DEADLOCK

I have these two in my -next branch now; but you could also push them
through the Xen tree.  If you have other deps and the Xen tree would be
easier, just let me know and I'll drop them.

Thanks,
--=20
Jesse Barnes, Intel Open Source Technology Center

--Sig_/wOU34tgT+IIj2Ug/yepQ1AI
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJPIt+pAAoJEIEoDkX4Qk9h0uEQAJd6MNnPCNalZFs6c18vFEJb
Tz6rEPPsyPyd9NFrTE1ko2sQmDtPwRCjvqGUOs4e/+eoFwAgC/K4eWNn1plkNaDj
3z0FtP2gK8+qYp+nOah2du6GGiYYo4qRWQk04gAQ/8FI9Mpa5myk7OZM2ALk6fCb
9lcvJaWSSkVljOs6TqgsDLIcjS3tRfrw191KxUKVmEsFyIIkB7Y/6WUkf43YjS1Q
qgsVXJzYM3BWFHI+OOBpna78qaoXWHR8CurchdCINSrBMSpxl4VBSqJqSoYJtSLX
7TyYNLlAwnbefT+cLx7wIj9Bk2HnJApHj4Ez6q8HSKABpKXfCNcuMkBcGo5l67PO
4kWXsZDpkcZKVP96+KW4DQOPP9EVAge+eInXT+cJSseXWcuRS9rBLjDhj+1E6B8t
SWOTB5RRTD8l7/B4PT66GA5oI/Pg4roZuiXe3oti/ZVyyhdRkfJKkC428+qfDaKA
KWzionpARPsHL78WEM6ZkSgYhbW3XW/yECM3fKjNiQ97osq3lyx9jmrj2a13O7Dc
Ys3PMuKY2FED0oFGqQscYBZYP7ScfX76IU3ryxLG/K9BQpGqYaNVpYxFplkVHK7H
hUsD7Nmvj8omVUFyKEDCGBTSgdJyWveZf1RLIlyMaQa+fbYUyPxD8ShVvMuciu7j
5EJxwTUoASaMbzbc82O5
=nf3W
-----END PGP SIGNATURE-----

--Sig_/wOU34tgT+IIj2Ug/yepQ1AI--


--===============4450737634303452239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4450737634303452239==--


From xen-devel-bounces@lists.xensource.com Fri Jan 27 17:33:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17:33:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqpfD-0004no-BE; Fri, 27 Jan 2012 17:32:39 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <jbarnes@virtuousgeek.org>) id 1RqpfB-0004nj-0j
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:32:37 +0000
X-Env-Sender: jbarnes@virtuousgeek.org
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327685549!12761450!1
X-Originating-IP: [67.222.55.9]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuNTUuOSA9PiA0MjU5Ng==\n,sa_preprocessor: 
	QmFkIElQOiA2Ny4yMjIuNTUuOSA9PiA0MjU5Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21915 invoked from network); 27 Jan 2012 17:32:30 -0000
Received: from oproxy7-pub.bluehost.com (HELO oproxy7-pub.bluehost.com)
	(67.222.55.9) by server-10.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 17:32:30 -0000
Received: (qmail 1111 invoked by uid 0); 27 Jan 2012 17:32:29 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114)
	by oproxy7.bluehost.com with SMTP; 27 Jan 2012 17:32:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=virtuousgeek.org; s=default; 
	h=Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date;
	bh=SfBjHi+gkTKPVkfSOYcxDhyryC7g6FnLEGXyNQBbW5o=; 
	b=BOKu6xEG6wJIoxrlodiVLQ5l8PPJCxp5Ib2+ugoA7Y0mKk76mqASSvYvwGO1uAXp/fzppUmaZ7OOnzlHvYnHRubbrhnxH2Ev2qj7cK2IOTRIYARrPAby8v6II4g+fqX1;
Received: from c-67-161-37-189.hsd1.ca.comcast.net ([67.161.37.189]
	helo=jbarnes-desktop)
	by box514.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.76) (envelope-from <jbarnes@virtuousgeek.org>)
	id 1Rqpf2-00070G-5b; Fri, 27 Jan 2012 10:32:28 -0700
Date: Fri, 27 Jan 2012 09:32:25 -0800
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Message-ID: <20120127093225.7c1194ae@jbarnes-desktop>
In-Reply-To: <1326388007-19178-2-git-send-email-konrad.wilk@oracle.com>
References: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
	<1326388007-19178-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: Claws Mail 3.7.6 (GTK+ 2.22.0; x86_64-pc-linux-gnu)
Mime-Version: 1.0
X-Identified-User: {10642:box514.bluehost.com:virtuous:virtuousgeek.org}
	{sentby:smtp auth 67.161.37.189 authed with
	jbarnes@virtuousgeek.org}
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/2] pci: Introduce
 __pci_reset_function_locked to be used when holding device_lock.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4450737634303452239=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4450737634303452239==
Content-Type: multipart/signed; micalg=PGP-SHA1;
 boundary="Sig_/wOU34tgT+IIj2Ug/yepQ1AI"; protocol="application/pgp-signature"

--Sig_/wOU34tgT+IIj2Ug/yepQ1AI
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 12 Jan 2012 12:06:46 -0500
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> The use case of this is when a driver wants to call FLR when a device
> is attached to it using the SysFS "bind" or "unbind" functionality.
>=20
> The call chain when a user does "bind" looks as so:
>=20
>  echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind
>=20
> and ends up calling:
>   driver_bind:
>     device_lock(dev);  <=3D=3D=3D TAKES LOCK
>     XXXX_probe:
>          .. pci_enable_device()
>          ...__pci_reset_function(), which calls
>                  pci_dev_reset(dev, 0):
>                         if (!0) {
>                                 device_lock(dev) <=3D=3D=3D=3D DEADLOCK

I have these two in my -next branch now; but you could also push them
through the Xen tree.  If you have other deps and the Xen tree would be
easier, just let me know and I'll drop them.

Thanks,
--=20
Jesse Barnes, Intel Open Source Technology Center

--Sig_/wOU34tgT+IIj2Ug/yepQ1AI
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJPIt+pAAoJEIEoDkX4Qk9h0uEQAJd6MNnPCNalZFs6c18vFEJb
Tz6rEPPsyPyd9NFrTE1ko2sQmDtPwRCjvqGUOs4e/+eoFwAgC/K4eWNn1plkNaDj
3z0FtP2gK8+qYp+nOah2du6GGiYYo4qRWQk04gAQ/8FI9Mpa5myk7OZM2ALk6fCb
9lcvJaWSSkVljOs6TqgsDLIcjS3tRfrw191KxUKVmEsFyIIkB7Y/6WUkf43YjS1Q
qgsVXJzYM3BWFHI+OOBpna78qaoXWHR8CurchdCINSrBMSpxl4VBSqJqSoYJtSLX
7TyYNLlAwnbefT+cLx7wIj9Bk2HnJApHj4Ez6q8HSKABpKXfCNcuMkBcGo5l67PO
4kWXsZDpkcZKVP96+KW4DQOPP9EVAge+eInXT+cJSseXWcuRS9rBLjDhj+1E6B8t
SWOTB5RRTD8l7/B4PT66GA5oI/Pg4roZuiXe3oti/ZVyyhdRkfJKkC428+qfDaKA
KWzionpARPsHL78WEM6ZkSgYhbW3XW/yECM3fKjNiQ97osq3lyx9jmrj2a13O7Dc
Ys3PMuKY2FED0oFGqQscYBZYP7ScfX76IU3ryxLG/K9BQpGqYaNVpYxFplkVHK7H
hUsD7Nmvj8omVUFyKEDCGBTSgdJyWveZf1RLIlyMaQa+fbYUyPxD8ShVvMuciu7j
5EJxwTUoASaMbzbc82O5
=nf3W
-----END PGP SIGNATURE-----

--Sig_/wOU34tgT+IIj2Ug/yepQ1AI--


--===============4450737634303452239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4450737634303452239==--


From xen-devel-bounces@lists.xensource.com Fri Jan 27 17:49:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17:49:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqpvA-0005C6-S8; Fri, 27 Jan 2012 17:49:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqpv9-0005C1-GR
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:49:07 +0000
Received: from [85.158.138.51:60276] by server-5.bemta-3.messagelabs.com id
	E0/4C-02363-193E22F4; Fri, 27 Jan 2012 17:49:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327686543!9113199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30486 invoked from network); 27 Jan 2012 17:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 17:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10338964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:49:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:49: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
	1Rqpv5-0005IP-6R; Fri, 27 Jan 2012 17:49:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqpv5-0004W3-5W;
	Fri, 27 Jan 2012 17:49:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.58255.8983.808548@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 17:49:03 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <259112aee61875355205.1327595099@debian.localdomain>
References: <259112aee61875355205.1327595099@debian.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] 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

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] libxl: fix mutex initialization"):
> libxl: fix mutex initialization

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 Fri Jan 27 17:49:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17:49:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqpvA-0005C6-S8; Fri, 27 Jan 2012 17:49:08 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqpv9-0005C1-GR
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:49:07 +0000
Received: from [85.158.138.51:60276] by server-5.bemta-3.messagelabs.com id
	E0/4C-02363-193E22F4; Fri, 27 Jan 2012 17:49:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327686543!9113199!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30486 invoked from network); 27 Jan 2012 17:49:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 17:49:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10338964"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:49:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:49: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
	1Rqpv5-0005IP-6R; Fri, 27 Jan 2012 17:49:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqpv5-0004W3-5W;
	Fri, 27 Jan 2012 17:49:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.58255.8983.808548@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 17:49:03 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <259112aee61875355205.1327595099@debian.localdomain>
References: <259112aee61875355205.1327595099@debian.localdomain>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH v2] 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

Roger Pau Monne writes ("[Xen-devel] [PATCH v2] libxl: fix mutex initialization"):
> libxl: fix mutex initialization

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 Fri Jan 27 17:59:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17: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 1Rqq4H-0005MP-VH; Fri, 27 Jan 2012 17:58:33 +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 1Rqq4G-0005MK-HK
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:58:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327687106!12439403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22339 invoked from network); 27 Jan 2012 17:58:26 -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;
	27 Jan 2012 17:58:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:58:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:58: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
	1Rqq4A-0005M6-AH; Fri, 27 Jan 2012 17:58:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqq4A-0004fE-8O;
	Fri, 27 Jan 2012 17:58:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.58818.246243.240338@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 17:58:26 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327507624-1914-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1327507624-1914-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libxl_qmp: fix qmp_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

Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl_qmp: fix qmp_next"):
> qmp_next doesn't handle multiple lines read together in a single buffer
> correctly at the moment.
> This patch fixes 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 Fri Jan 27 17:59:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 17: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 1Rqq4H-0005MP-VH; Fri, 27 Jan 2012 17:58:33 +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 1Rqq4G-0005MK-HK
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 17:58:32 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1327687106!12439403!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22339 invoked from network); 27 Jan 2012 17:58:26 -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;
	27 Jan 2012 17:58:26 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339173"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 17:58:26 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 17:58: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
	1Rqq4A-0005M6-AH; Fri, 27 Jan 2012 17:58:26 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqq4A-0004fE-8O;
	Fri, 27 Jan 2012 17:58:26 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.58818.246243.240338@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 17:58:26 +0000
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327507624-1914-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <1327507624-1914-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: anthony.perard@citrix.com, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] libxl_qmp: fix qmp_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

Stefano Stabellini writes ("[Xen-devel] [PATCH] libxl_qmp: fix qmp_next"):
> qmp_next doesn't handle multiple lines read together in a single buffer
> correctly at the moment.
> This patch fixes 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 Fri Jan 27 18:11:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqG7-0005dK-6p; Fri, 27 Jan 2012 18:10: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 1RqqG5-0005dC-0c
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:10:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327687795!62024782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2248 invoked from network); 27 Jan 2012 18:09:56 -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;
	27 Jan 2012 18:09:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:10: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, 27 Jan 2012 18:10: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
	1RqqFy-0005QM-EA; Fri, 27 Jan 2012 18:10:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqFy-0004gJ-CV;
	Fri, 27 Jan 2012 18:10:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.59550.374377.953444@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:10:38 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@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 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> libxl: expose cpu topology as a single list of cpu->{node,core,socket} maps.
> 
> Rather than the previous tripple list which is more complicated to work with
> and harder for language bindings.

This is plausible.  But:

> +#if 0
>  static void libxl_cpuarray_rand_init(libxl_cpuarray *p)
>  {
>      int i;
> @@ -209,6 +210,7 @@ static void libxl_cpuarray_rand_init(lib
>              p->array[i] = r;
>      }
>  }
> +#endif

You haven't quite finished ?

> +    for (cpu = 0; cpu < nr; cpu++) {
...
> +        libxl_cputopology_dispose(&topology[cpu]);
>      }
>  
> -    libxl_topologyinfo_dispose(&topology);
> -
> +    free(topology);

This is quite ugly to have out here in the caller.  Perhaps we should
provide a helper for this, called libxl_cputopology_free or
something ?

> -    libxl_topologyinfo_dispose(&topology);
> +    for (cpu = 0; cpu < nr_cpus; cpu++)
> +        libxl_cputopology_dispose(&topology[cpu]);
> +    free(topology);

And here it is again, proving my point :-).

> +#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY ~0
...
> +libxl_cputopology = Struct("cputopology", [
> +    ("core", uint32),
> +    ("socket", uint32),
> +    ("node", uint32),

You mean (~(uint32_t)0) I think.  The outer ( ) should be included too!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:11:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:11:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqG7-0005dK-6p; Fri, 27 Jan 2012 18:10: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 1RqqG5-0005dC-0c
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:10:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327687795!62024782!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2248 invoked from network); 27 Jan 2012 18:09:56 -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;
	27 Jan 2012 18:09:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339452"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:10: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, 27 Jan 2012 18:10: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
	1RqqFy-0005QM-EA; Fri, 27 Jan 2012 18:10:38 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqFy-0004gJ-CV;
	Fri, 27 Jan 2012 18:10:38 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.59550.374377.953444@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:10:38 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@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 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> libxl: expose cpu topology as a single list of cpu->{node,core,socket} maps.
> 
> Rather than the previous tripple list which is more complicated to work with
> and harder for language bindings.

This is plausible.  But:

> +#if 0
>  static void libxl_cpuarray_rand_init(libxl_cpuarray *p)
>  {
>      int i;
> @@ -209,6 +210,7 @@ static void libxl_cpuarray_rand_init(lib
>              p->array[i] = r;
>      }
>  }
> +#endif

You haven't quite finished ?

> +    for (cpu = 0; cpu < nr; cpu++) {
...
> +        libxl_cputopology_dispose(&topology[cpu]);
>      }
>  
> -    libxl_topologyinfo_dispose(&topology);
> -
> +    free(topology);

This is quite ugly to have out here in the caller.  Perhaps we should
provide a helper for this, called libxl_cputopology_free or
something ?

> -    libxl_topologyinfo_dispose(&topology);
> +    for (cpu = 0; cpu < nr_cpus; cpu++)
> +        libxl_cputopology_dispose(&topology[cpu]);
> +    free(topology);

And here it is again, proving my point :-).

> +#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY ~0
...
> +libxl_cputopology = Struct("cputopology", [
> +    ("core", uint32),
> +    ("socket", uint32),
> +    ("node", uint32),

You mean (~(uint32_t)0) I think.  The outer ( ) should be included too!

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:12:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqGd-0005eb-KL; Fri, 27 Jan 2012 18:11:19 +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 1RqqGc-0005eO-Hc
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:11:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327687871!10148354!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30937 invoked from network); 27 Jan 2012 18:11:12 -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;
	27 Jan 2012 18:11:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:11: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, 27 Jan 2012 18:11: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
	1RqqGV-0005Qc-2q; Fri, 27 Jan 2012 18:11:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqGV-0004gX-27;
	Fri, 27 Jan 2012 18:11:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.59583.53773.349956@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:11:11 +0000
To: Ian Campbell <ian.campbell@citrix.com>, <xen-devel@lists.xensource.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20258.59550.374377.953444@mariner.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
	<20258.59550.374377.953444@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> This is plausible.  But:
> 
> > +#if 0
...
> > +#endif
> 
> You haven't quite finished ?

Oh I see, this is tidied up in 7/9.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:12:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqGd-0005eb-KL; Fri, 27 Jan 2012 18:11:19 +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 1RqqGc-0005eO-Hc
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:11:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327687871!10148354!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30937 invoked from network); 27 Jan 2012 18:11:12 -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;
	27 Jan 2012 18:11:12 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339456"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:11: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, 27 Jan 2012 18:11: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
	1RqqGV-0005Qc-2q; Fri, 27 Jan 2012 18:11:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqGV-0004gX-27;
	Fri, 27 Jan 2012 18:11:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.59583.53773.349956@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:11:11 +0000
To: Ian Campbell <ian.campbell@citrix.com>, <xen-devel@lists.xensource.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <20258.59550.374377.953444@mariner.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
	<20258.59550.374377.953444@mariner.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Jackson writes ("Re: [Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> This is plausible.  But:
> 
> > +#if 0
...
> > +#endif
> 
> You haven't quite finished ?

Oh I see, this is tidied up in 7/9.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:12:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqHI-0005i0-2I; Fri, 27 Jan 2012 18:12: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 1RqqHG-0005hO-UE
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:11:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327687910!12676232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25117 invoked from network); 27 Jan 2012 18:11:51 -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;
	27 Jan 2012 18:11:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:11:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 18:11:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqqH7-0005Qw-Hg; Fri, 27 Jan 2012 18:11:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqH7-0004gg-Gr;
	Fri, 27 Jan 2012 18:11:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.59621.508941.899911@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:11:49 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0bf43ff297fc2cb4d698.1327512257@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<0bf43ff297fc2cb4d698.1327512257@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
Subject: Re: [Xen-devel] [PATCH 7 of 9] libxl: drop libxl_cpuarray --
 topology was the only 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

Ian Campbell writes ("[Xen-devel] [PATCH 7 of 9] libxl: drop libxl_cpuarray -- t> libxl: drop libxl_cpuarray -- topology was the only user.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Jan 27 18:12:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:12:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqHI-0005i0-2I; Fri, 27 Jan 2012 18:12: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 1RqqHG-0005hO-UE
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:11:59 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327687910!12676232!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25117 invoked from network); 27 Jan 2012 18:11:51 -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;
	27 Jan 2012 18:11:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:11:49 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 18:11:49 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqqH7-0005Qw-Hg; Fri, 27 Jan 2012 18:11:49 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqH7-0004gg-Gr;
	Fri, 27 Jan 2012 18:11:49 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.59621.508941.899911@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:11:49 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <0bf43ff297fc2cb4d698.1327512257@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<0bf43ff297fc2cb4d698.1327512257@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
Subject: Re: [Xen-devel] [PATCH 7 of 9] libxl: drop libxl_cpuarray --
 topology was the only 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

Ian Campbell writes ("[Xen-devel] [PATCH 7 of 9] libxl: drop libxl_cpuarray -- t> libxl: drop libxl_cpuarray -- topology was the only user.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

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 Jan 27 18:16:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:16:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqLP-00061N-OJ; Fri, 27 Jan 2012 18:16: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 1RqqLO-00060o-CY
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:16:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327688168!12696661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11618 invoked from network); 27 Jan 2012 18:16:08 -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;
	27 Jan 2012 18:16:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339509"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:16:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 18:16:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqqLH-0005SD-Py; Fri, 27 Jan 2012 18:16:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqLH-0004hU-P1;
	Fri, 27 Jan 2012 18:16:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.59879.760603.13945@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:16:07 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@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 9] libxl: API updates + xl: JSON
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 9] libxl: API updates + xl: JSON"):
> A random(ish) colletion of libxl patches.
> 
>  - Fixup idl infrastructure naming clash/annoyance
>  - Consolidate libxl_button_press and libxl_send_trigger
>  - Change the way libxl exposes CPU topology information to be a list
>    of CPU (core,node,socket) tuples instead of three lists. This is a
>    more sensible representation but is also a bit easier on the
>    language bindings.

Thanks.

1-5, 7-10: acked.

I had some comments on 6.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:16:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:16:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqLP-00061N-OJ; Fri, 27 Jan 2012 18:16: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 1RqqLO-00060o-CY
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:16:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-182.messagelabs.com!1327688168!12696661!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11618 invoked from network); 27 Jan 2012 18:16:08 -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;
	27 Jan 2012 18:16:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339509"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:16:08 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 18:16:08 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RqqLH-0005SD-Py; Fri, 27 Jan 2012 18:16:07 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqLH-0004hU-P1;
	Fri, 27 Jan 2012 18:16:07 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.59879.760603.13945@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:16:07 +0000
To: Ian Campbell <ian.campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <patchbomb.1327512250@cosworth.uk.xensource.com>
References: <patchbomb.1327512250@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 9] libxl: API updates + xl: JSON
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 9] libxl: API updates + xl: JSON"):
> A random(ish) colletion of libxl patches.
> 
>  - Fixup idl infrastructure naming clash/annoyance
>  - Consolidate libxl_button_press and libxl_send_trigger
>  - Change the way libxl exposes CPU topology information to be a list
>    of CPU (core,node,socket) tuples instead of three lists. This is a
>    more sensible representation but is also a bit easier on the
>    language bindings.

Thanks.

1-5, 7-10: acked.

I had some comments on 6.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:19:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqOS-0006B5-Bw; Fri, 27 Jan 2012 18:19: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 1RqqOQ-0006At-A0
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:19:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327688355!12681715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 891 invoked from network); 27 Jan 2012 18:19:16 -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;
	27 Jan 2012 18:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:19:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 18:19:15 +0000
Date: Fri, 27 Jan 2012 18:20:16 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/6] prevent Qemu from waking up needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents Qemu from waking up needlessly on Xen
several times a second in order to check some timers.



The first patch stops Qemu from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that Qemu doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fifth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.



Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.




Shortlog and diffstat follow:

Stefano Stabellini (6):
      xen: do not initialize the interval timer emulator
      xen: disable rtc_clock
      xen: introduce an event channel for buffered io event notifications
      timers: the rearm function should be able to handle delta = INT64_MAX
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      qemu_calculate_timeout: increase minimum timeout to 1h

 hw/pc.c      |    7 +++++--
 qemu-timer.c |   30 ++++++++++++++++++------------
 xen-all.c    |   43 +++++++++++++++++++++++++++++++++++++------
 3 files changed, 60 insertions(+), 20 deletions(-)


A git tree available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-3

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 Jan 27 18:19:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqOS-0006B5-Bw; Fri, 27 Jan 2012 18:19: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 1RqqOQ-0006At-A0
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:19:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327688355!12681715!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 891 invoked from network); 27 Jan 2012 18:19:16 -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;
	27 Jan 2012 18:19:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339549"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:19:15 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 18:19:15 +0000
Date: Fri, 27 Jan 2012 18:20:16 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Avi Kivity <avi@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/6] prevent Qemu from waking up needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents Qemu from waking up needlessly on Xen
several times a second in order to check some timers.



The first patch stops Qemu from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that Qemu doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fifth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.



Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.




Shortlog and diffstat follow:

Stefano Stabellini (6):
      xen: do not initialize the interval timer emulator
      xen: disable rtc_clock
      xen: introduce an event channel for buffered io event notifications
      timers: the rearm function should be able to handle delta = INT64_MAX
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      qemu_calculate_timeout: increase minimum timeout to 1h

 hw/pc.c      |    7 +++++--
 qemu-timer.c |   30 ++++++++++++++++++------------
 xen-all.c    |   43 +++++++++++++++++++++++++++++++++++++------
 3 files changed, 60 insertions(+), 20 deletions(-)


A git tree available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-3

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 Jan 27 18:21:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPl-0006HH-RW; Fri, 27 Jan 2012 18:20:45 +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 1RqqPk-0006GS-TS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327688435!12656474!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29988 invoked from network); 27 Jan 2012 18:20:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="21360001"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUI013482;
	Fri, 27 Jan 2012 10:20:23 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:33 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/6] xen: do not initialize the interval
	timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 85304cf..7a7ce98 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -43,6 +43,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     DriveInfo *fd[MAX_FD];
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-    pit = pit_init(isa_bus, 0x40, 0);
+    if (!xen_available()) {
+        pit = pit_init(isa_bus, 0x40, 0);
+    }
     pcspk_init(pit);
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPl-0006HH-RW; Fri, 27 Jan 2012 18:20:45 +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 1RqqPk-0006GS-TS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327688435!12656474!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29988 invoked from network); 27 Jan 2012 18:20:38 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="21360001"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUI013482;
	Fri, 27 Jan 2012 10:20:23 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:33 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/6] xen: do not initialize the interval
	timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 85304cf..7a7ce98 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -43,6 +43,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     DriveInfo *fd[MAX_FD];
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-    pit = pit_init(isa_bus, 0x40, 0);
+    if (!xen_available()) {
+        pit = pit_init(isa_bus, 0x40, 0);
+    }
     pcspk_init(pit);
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPp-0006I9-Fa; Fri, 27 Jan 2012 18:20:49 +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 1RqqPn-0006Gh-BN
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327688439!5355374!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16830 invoked from network); 27 Jan 2012 18:20:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179414517"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUM013482;
	Fri, 27 Jan 2012 10:20:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:37 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 5/6] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index a9ba0eb..8c8bbc3 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPp-0006I9-Fa; Fri, 27 Jan 2012 18:20:49 +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 1RqqPn-0006Gh-BN
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:47 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327688439!5355374!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16830 invoked from network); 27 Jan 2012 18:20:40 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179414517"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUM013482;
	Fri, 27 Jan 2012 10:20:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:37 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 5/6] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index a9ba0eb..8c8bbc3 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPp-0006IK-RU; Fri, 27 Jan 2012 18:20:49 +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 1RqqPn-0006Go-QS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327688439!5355374!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16881 invoked from network); 27 Jan 2012 18:20:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179414518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUJ013482;
	Fri, 27 Jan 2012 10:20:26 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:34 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index d1fc597..bf183f7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -513,6 +513,7 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    qemu_clock_enable(rtc_clock, false);
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPq-0006IT-8r; Fri, 27 Jan 2012 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 1RqqPo-0006Gt-TO
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327688435!12656474!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30093 invoked from network); 27 Jan 2012 18:20:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="21360007"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUK013482;
	Fri, 27 Jan 2012 10:20:28 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:35 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 3/6] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   42 ++++++++++++++++++++++++++++++++++++------
 1 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bf183f7..bfec4c1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -77,6 +77,8 @@ typedef struct XenIOState {
     QEMUTimer *buffered_io_timer;
     /* the evtchn port for polling the notification, */
     evtchn_port_t *ioreq_local_port;
+    /* evtchn local port for buffered io */
+    evtchn_port_t bufioreq_local_port;
     /* the evtchn fd for polling */
     XenEvtchn xce_handle;
     /* which vcpu we are serving */
@@ -545,6 +547,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(state->xce_handle);
+    if (port == state->bufioreq_local_port) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+        return NULL;
+    }
+
     if (port != -1) {
         for (i = 0; i < smp_cpus; i++) {
             if (state->ioreq_local_port[i] == port) {
@@ -693,16 +701,18 @@ static void handle_ioreq(ioreq_t *req)
     }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!state->buffered_io_page) {
-        return;
+        return 0;
     }
 
+    memset(&req, 0x00, sizeof(req));
+
     while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {
         buf_req = &state->buffered_io_page->buf_ioreq[
             state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -727,15 +737,21 @@ static void handle_buffered_iopage(XenIOState *state)
         xen_mb();
         state->buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     XenIOState *state = opaque;
 
-    handle_buffered_iopage(state);
-    qemu_mod_timer(state->buffered_io_timer,
-                   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    if (handle_buffered_iopage(state)) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    } else {
+        qemu_del_timer(state->buffered_io_timer);
+        xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -865,7 +881,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
     state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
                                                  state);
-    qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -917,6 +932,7 @@ int xen_hvm_init(void)
 {
     int i, rc;
     unsigned long ioreq_pfn;
+    unsigned long bufioreq_evtchn;
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -966,6 +982,20 @@ int xen_hvm_init(void)
         state->ioreq_local_port[i] = rc;
     }
 
+    rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+            &bufioreq_evtchn);
+    if (rc < 0) {
+        fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+        return -1;
+    }
+    rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+            (uint32_t)bufioreq_evtchn);
+    if (rc == -1) {
+        fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+        return -1;
+    }
+    state->bufioreq_local_port = rc;
+
     /* Init RAM management */
     xen_map_cache_init();
     xen_ram_init(ram_size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPp-0006IK-RU; Fri, 27 Jan 2012 18:20:49 +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 1RqqPn-0006Go-QS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:48 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327688439!5355374!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16881 invoked from network); 27 Jan 2012 18:20:41 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179414518"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:38 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUJ013482;
	Fri, 27 Jan 2012 10:20:26 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:34 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index d1fc597..bf183f7 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -513,6 +513,7 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    qemu_clock_enable(rtc_clock, false);
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPq-0006IT-8r; Fri, 27 Jan 2012 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 1RqqPo-0006Gt-TO
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:49 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327688435!12656474!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30093 invoked from network); 27 Jan 2012 18:20:40 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="21360007"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:40 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUK013482;
	Fri, 27 Jan 2012 10:20:28 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:35 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 3/6] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   42 ++++++++++++++++++++++++++++++++++++------
 1 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index bf183f7..bfec4c1 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -77,6 +77,8 @@ typedef struct XenIOState {
     QEMUTimer *buffered_io_timer;
     /* the evtchn port for polling the notification, */
     evtchn_port_t *ioreq_local_port;
+    /* evtchn local port for buffered io */
+    evtchn_port_t bufioreq_local_port;
     /* the evtchn fd for polling */
     XenEvtchn xce_handle;
     /* which vcpu we are serving */
@@ -545,6 +547,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(state->xce_handle);
+    if (port == state->bufioreq_local_port) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+        return NULL;
+    }
+
     if (port != -1) {
         for (i = 0; i < smp_cpus; i++) {
             if (state->ioreq_local_port[i] == port) {
@@ -693,16 +701,18 @@ static void handle_ioreq(ioreq_t *req)
     }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!state->buffered_io_page) {
-        return;
+        return 0;
     }
 
+    memset(&req, 0x00, sizeof(req));
+
     while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {
         buf_req = &state->buffered_io_page->buf_ioreq[
             state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -727,15 +737,21 @@ static void handle_buffered_iopage(XenIOState *state)
         xen_mb();
         state->buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     XenIOState *state = opaque;
 
-    handle_buffered_iopage(state);
-    qemu_mod_timer(state->buffered_io_timer,
-                   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    if (handle_buffered_iopage(state)) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    } else {
+        qemu_del_timer(state->buffered_io_timer);
+        xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -865,7 +881,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
     state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
                                                  state);
-    qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -917,6 +932,7 @@ int xen_hvm_init(void)
 {
     int i, rc;
     unsigned long ioreq_pfn;
+    unsigned long bufioreq_evtchn;
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -966,6 +982,20 @@ int xen_hvm_init(void)
         state->ioreq_local_port[i] = rc;
     }
 
+    rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+            &bufioreq_evtchn);
+    if (rc < 0) {
+        fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+        return -1;
+    }
+    rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+            (uint32_t)bufioreq_evtchn);
+    if (rc == -1) {
+        fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+        return -1;
+    }
+    state->bufioreq_local_port = rc;
+
     /* Init RAM management */
     xen_map_cache_init();
     xen_ram_init(ram_size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPt-0006Jc-NQ; Fri, 27 Jan 2012 18:20:53 +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 1RqqPr-0006HX-RA
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327688435!12656474!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30293 invoked from network); 27 Jan 2012 18:20:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="21360009"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUN013482;
	Fri, 27 Jan 2012 10:20:33 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:38 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 6/6] qemu_calculate_timeout: increase minimum
	timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 8c8bbc3..3207e40 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -852,6 +852,6 @@ fail:
 
 int qemu_calculate_timeout(void)
 {
-    return 1000;
+    return 1000*60*60;
 }
 
-- 
1.7.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 Jan 27 18:21:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:21:24 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqPt-0006Jc-NQ; Fri, 27 Jan 2012 18:20:53 +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 1RqqPr-0006HX-RA
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:20:52 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327688435!12656474!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTgxNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30293 invoked from network); 27 Jan 2012 18:20:45 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:20:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="21360009"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20:45 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:20: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 q0RIKMUN013482;
	Fri, 27 Jan 2012 10:20:33 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:38 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 6/6] qemu_calculate_timeout: increase minimum
	timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 8c8bbc3..3207e40 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -852,6 +852,6 @@ fail:
 
 int qemu_calculate_timeout(void)
 {
-    return 1000;
+    return 1000*60*60;
 }
 
-- 
1.7.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 Jan 27 18:21:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqQG-0006Pr-50; Fri, 27 Jan 2012 18:21:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqqQF-0006PJ-J7
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:21:15 +0000
Received: from [85.158.138.51:48013] by server-3.bemta-3.messagelabs.com id
	5A/74-26314-A1BE22F4; Fri, 27 Jan 2012 18:21:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327688471!10905436!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7634 invoked from network); 27 Jan 2012 18:21:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:21:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179414540"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20: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; Fri, 27 Jan 2012 13:20: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 q0RIKMUL013482;
	Fri, 27 Jan 2012 10:20:29 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:36 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 4/6] timers: the rearm function should be
	able to handle delta = INT64_MAX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index cd026c6..a9ba0eb 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -725,13 +725,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-    int nearest_delta_ms = (delta + 999999) / 1000000;
+    int64_t nearest_delta_ms = delta / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* UINT_MAX can be 32 bit */
+    if (nearest_delta_ms > UINT_MAX) {
+        nearest_delta_ms = UINT_MAX;
+    }
 
     timeKillEvent(mm_timer);
-    mm_timer = timeSetEvent(nearest_delta_ms,
+    mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
                             mm_period,
                             mm_alarm_handler,
                             (DWORD_PTR)t,
@@ -786,16 +790,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
                               int64_t nearest_delta_ns)
 {
     HANDLE hTimer = t->timer;
-    int nearest_delta_ms;
+    int64_t nearest_delta_ms;
     BOOLEAN success;
 
-    nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
+    nearest_delta_ms = nearest_delta_ns / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* ULONG_MAX can be 32 bit */
+    if (nearest_delta_ms > ULONG_MAX) {
+        nearest_delta_ms = ULONG_MAX;
+    }
     success = ChangeTimerQueueTimer(NULL,
                                     hTimer,
-                                    nearest_delta_ms,
+                                    (unsigned long) nearest_delta_ms,
                                     3600000);
 
     if (!success) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:21:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqQG-0006Pr-50; Fri, 27 Jan 2012 18:21:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqqQF-0006PJ-J7
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:21:15 +0000
Received: from [85.158.138.51:48013] by server-3.bemta-3.messagelabs.com id
	5A/74-26314-A1BE22F4; Fri, 27 Jan 2012 18:21:14 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327688471!10905436!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7634 invoked from network); 27 Jan 2012 18:21:13 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-3.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:21:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179414540"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:20: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; Fri, 27 Jan 2012 13:20: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 q0RIKMUL013482;
	Fri, 27 Jan 2012 10:20:29 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: qemu-devel@nongnu.org
Date: Fri, 27 Jan 2012 18:21:36 +0000
Message-ID: <1327688498-12362-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.1201271814280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
MIME-Version: 1.0
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, avi@redhat.com,
	anthony@codemonkey.ws,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 4/6] timers: the rearm function should be
	able to handle delta = INT64_MAX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index cd026c6..a9ba0eb 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -725,13 +725,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-    int nearest_delta_ms = (delta + 999999) / 1000000;
+    int64_t nearest_delta_ms = delta / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* UINT_MAX can be 32 bit */
+    if (nearest_delta_ms > UINT_MAX) {
+        nearest_delta_ms = UINT_MAX;
+    }
 
     timeKillEvent(mm_timer);
-    mm_timer = timeSetEvent(nearest_delta_ms,
+    mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
                             mm_period,
                             mm_alarm_handler,
                             (DWORD_PTR)t,
@@ -786,16 +790,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
                               int64_t nearest_delta_ns)
 {
     HANDLE hTimer = t->timer;
-    int nearest_delta_ms;
+    int64_t nearest_delta_ms;
     BOOLEAN success;
 
-    nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
+    nearest_delta_ms = nearest_delta_ns / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* ULONG_MAX can be 32 bit */
+    if (nearest_delta_ms > ULONG_MAX) {
+        nearest_delta_ms = ULONG_MAX;
+    }
     success = ChangeTimerQueueTimer(NULL,
                                     hTimer,
-                                    nearest_delta_ms,
+                                    (unsigned long) nearest_delta_ms,
                                     3600000);
 
     if (!success) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:22:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqQs-0006hP-L2; Fri, 27 Jan 2012 18:21:54 +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 1RqqQr-0006eV-1E
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:21:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327688506!12677059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11282 invoked from network); 27 Jan 2012 18:21:47 -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;
	27 Jan 2012 18:21:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:21: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, 27 Jan 2012 18:21: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
	1RqqQk-0005UK-0T; Fri, 27 Jan 2012 18:21:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqQj-00069V-Vd;
	Fri, 27 Jan 2012 18:21:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.60217.969006.279982@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:21:45 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <88856b776fcfc5b3d0ce.1327548756@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
	<88856b776fcfc5b3d0ce.1327548756@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 13] Memshrtool: tool to test and
 exercise the sharing subsystem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 12 of 13] Memshrtool: tool to test and exercise the sharing subsystem"):
> This is demo code meant to showcase how to perform sharing
> operations. It is useful for testing. We submit it so others in
> the list can have unlimited sharing fun, but not necessarily
> expecting it be added to the tree.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

I have applied this.  I would encourage you to submit a patch to wire
it into the tools build system.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:22:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:22:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqQs-0006hP-L2; Fri, 27 Jan 2012 18:21:54 +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 1RqqQr-0006eV-1E
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:21:53 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327688506!12677059!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11282 invoked from network); 27 Jan 2012 18:21:47 -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;
	27 Jan 2012 18:21:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339651"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:21: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, 27 Jan 2012 18:21: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
	1RqqQk-0005UK-0T; Fri, 27 Jan 2012 18:21:46 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqqQj-00069V-Vd;
	Fri, 27 Jan 2012 18:21:45 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.60217.969006.279982@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:21:45 +0000
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <88856b776fcfc5b3d0ce.1327548756@xdev.gridcentric.ca>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
	<88856b776fcfc5b3d0ce.1327548756@xdev.gridcentric.ca>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	JBeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 13] Memshrtool: tool to test and
 exercise the sharing subsystem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 12 of 13] Memshrtool: tool to test and exercise the sharing subsystem"):
> This is demo code meant to showcase how to perform sharing
> operations. It is useful for testing. We submit it so others in
> the list can have unlimited sharing fun, but not necessarily
> expecting it be added to the tree.
> 
> Signed-off-by: Adin Scannell <adin@scannell.ca>
> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

I have applied this.  I would encourage you to submit a patch to wire
it into the tools build system.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:28:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqWh-0007cS-Hp; Fri, 27 Jan 2012 18:27:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqqWf-0007cN-8a
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:27:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327688823!62026092!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc3NzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31280 invoked from network); 27 Jan 2012 18:27:04 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 18:27:04 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 20CB945807C;
	Fri, 27 Jan 2012 10:27:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=QPsikaS1ToiuDGJFhohfZ7duGy3Rh1Ur0+Y8fxKW21ZX
	CYuQ19TctqcN+EE0dCfaAzM67b2+Z71mGt3JZB7mqmxki/E6fQfOCLslLQVOXRHL
	lCithkD2xy0I3HPeHMCk/pZC8EJtEltoLI6DszAuRGkhq3XEW4x+uXvaR4YLp9I=
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=qSsb5caNvQh8tTm0POb+kbtuIEo=; b=G41gDlET
	tM7MDH71+ta1fiK/8+/4p8CMOADiJWULgGn8+mZn3SEX3dkDaTjtcyZ6ixqwn1PU
	21a7CHbqJEV4JB6dsN5HE3GFH10ay/fdvEmi1KXlaRE3CM3CWko+AF6GHsMBH9Pk
	CPtTj4gpjJu5nc82Ym43QETufJ5JbTufm6M=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 8EF60458086; 
	Fri, 27 Jan 2012 10:27: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;
	Fri, 27 Jan 2012 10:27:46 -0800
Message-ID: <2e825403a1a14c3d6d879be85950b638.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20258.60217.969006.279982@mariner.uk.xensource.com>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
	<88856b776fcfc5b3d0ce.1327548756@xdev.gridcentric.ca>
	<20258.60217.969006.279982@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 10:27:46 -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, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 13] Memshrtool: tool to test and
 exercise the sharing subsystem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 12 of 13] Memshrtool:
> tool to test and exercise the sharing subsystem"):
>> This is demo code meant to showcase how to perform sharing
>> operations. It is useful for testing. We submit it so others in
>> the list can have unlimited sharing fun, but not necessarily
>> expecting it be added to the tree.
>>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> I have applied this.  I would encourage you to submit a patch to wire
> it into the tools build system.

Great. Give me a sec
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 Jan 27 18:28:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqWh-0007cS-Hp; Fri, 27 Jan 2012 18:27:55 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <andres@lagarcavilla.org>) id 1RqqWf-0007cN-8a
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:27:53 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327688823!62026092!1
X-Originating-IP: [208.97.132.202]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi4yMDIgPT4gMTc3NzM=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31280 invoked from network); 27 Jan 2012 18:27:04 -0000
Received: from caiajhbdccac.dreamhost.com (HELO homiemail-a76.g.dreamhost.com)
	(208.97.132.202) by server-9.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 18:27:04 -0000
Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 20CB945807C;
	Fri, 27 Jan 2012 10:27:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id
	:in-reply-to:references:date:subject:from:to:cc:reply-to
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	lagarcavilla.org; b=QPsikaS1ToiuDGJFhohfZ7duGy3Rh1Ur0+Y8fxKW21ZX
	CYuQ19TctqcN+EE0dCfaAzM67b2+Z71mGt3JZB7mqmxki/E6fQfOCLslLQVOXRHL
	lCithkD2xy0I3HPeHMCk/pZC8EJtEltoLI6DszAuRGkhq3XEW4x+uXvaR4YLp9I=
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=qSsb5caNvQh8tTm0POb+kbtuIEo=; b=G41gDlET
	tM7MDH71+ta1fiK/8+/4p8CMOADiJWULgGn8+mZn3SEX3dkDaTjtcyZ6ixqwn1PU
	21a7CHbqJEV4JB6dsN5HE3GFH10ay/fdvEmi1KXlaRE3CM3CWko+AF6GHsMBH9Pk
	CPtTj4gpjJu5nc82Ym43QETufJ5JbTufm6M=
Received: from webmail.lagarcavilla.org (caiajhbihbdd.dreamhost.com
	[208.97.187.133]) (Authenticated sender: andres@lagarcavilla.com)
	by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 8EF60458086; 
	Fri, 27 Jan 2012 10:27: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;
	Fri, 27 Jan 2012 10:27:46 -0800
Message-ID: <2e825403a1a14c3d6d879be85950b638.squirrel@webmail.lagarcavilla.org>
In-Reply-To: <20258.60217.969006.279982@mariner.uk.xensource.com>
References: <patchbomb.1327548744@xdev.gridcentric.ca>
	<88856b776fcfc5b3d0ce.1327548756@xdev.gridcentric.ca>
	<20258.60217.969006.279982@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 10:27:46 -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, ian.campbell@citrix.com,
	andres@gridcentric.ca, tim@xen.org, keir.xen@gmail.com,
	jbeulich@suse.com, adin@gridcentric.ca
Subject: Re: [Xen-devel] [PATCH 12 of 13] Memshrtool: tool to test and
 exercise the sharing subsystem
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: andres@lagarcavilla.org
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> Andres Lagar-Cavilla writes ("[Xen-devel] [PATCH 12 of 13] Memshrtool:
> tool to test and exercise the sharing subsystem"):
>> This is demo code meant to showcase how to perform sharing
>> operations. It is useful for testing. We submit it so others in
>> the list can have unlimited sharing fun, but not necessarily
>> expecting it be added to the tree.
>>
>> Signed-off-by: Adin Scannell <adin@scannell.ca>
>> Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
>
> I have applied this.  I would encourage you to submit a patch to wire
> it into the tools build system.

Great. Give me a sec
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 Jan 27 18:28:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqX0-0007db-Ue; Fri, 27 Jan 2012 18:28:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>)
	id 1RqqWz-0007dF-Ns; Fri, 27 Jan 2012 18:28:13 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327688886!12824892!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24832 invoked from network); 27 Jan 2012 18:28:07 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:28:07 -0000
Received: by bkar1 with SMTP id r1so3115621bka.30
	for <multiple recipients>; Fri, 27 Jan 2012 10:28:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.148.83 with SMTP id o19mr3617802bkv.132.1327688886673;
	Fri, 27 Jan 2012 10:28:06 -0800 (PST)
Received: by 10.205.83.74 with HTTP; Fri, 27 Jan 2012 10:28:06 -0800 (PST)
X-Originating-IP: [66.87.4.78]
Received: by 10.205.83.74 with HTTP; Fri, 27 Jan 2012 10:28:06 -0800 (PST)
In-Reply-To: <CAH4C7zGAcPGtMB2muWjxv7U+cXZE5qgSgpiZJ=QhP=Chw=A0vA@mail.gmail.com>
References: <CAH4C7zGAcPGtMB2muWjxv7U+cXZE5qgSgpiZJ=QhP=Chw=A0vA@mail.gmail.com>
Date: Fri, 27 Jan 2012 13:28:06 -0500
Message-ID: <CAH4C7zEDiG0o2a7Mt3-8j7vGZe-hybkwiirccsU84m6oOMc2wg@mail.gmail.com>
From: Keith Coleman <keith.coleman@n2servers.com>
To: xen-users <xen-users@lists.xensource.com>, 
	xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen 3.4.4 released
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1419541268194685577=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1419541268194685577==
Content-Type: multipart/alternative; boundary=0015175cdc5676626c04b786a8b6

--0015175cdc5676626c04b786a8b6
Content-Type: text/plain; charset=ISO-8859-1

Xen 3.4.4 is the latest maintenance release in the 3.4 stable branch. There
are a range of bug fixes since 3.4.3. We recommend users to upgrade.

Xen 3.4.4 includes:
 - Security enhancements including CVE-2011-1583
 - Support for AMD Family 15h (Bulldozer) CPUs
 - Performances and stability improvements
 - Various bux fixes

The source repository can be downloaded from:
http://xenbits.xensource.com/xen-3.4-testing.hg
The release is tagged 'RELEASE-3.4.4'.

Browsing the above URL will show the mercurial changelog.

A source tarball is available for download from:
http://xen.org/download/index_3.4.4.html

And the announcement on the Xen blog:
http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/

Thanks to the many people who have contributed to this release!

Regards,
The Xen Team

--0015175cdc5676626c04b786a8b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>Xen 3.4.4 is the latest maintenance release in the 3.4 stable branch. Th=
ere are a range of bug fixes since 3.4.3. We recommend users to upgrade.</p=
>
<p>Xen 3.4.4 includes:<br>
=A0- Security enhancements including CVE-2011-1583<br>
=A0- Support for AMD Family 15h (Bulldozer) CPUs<br>
=A0- Performances and stability improvements<br>
=A0- Various bux fixes</p>
<p>The source repository can be downloaded from:<br>
<a href=3D"http://xenbits.xensource.com/xen-3.4-testing.hg">http://xenbits.=
xensource.com/xen-3.4-testing.hg</a><br>
The release is tagged &#39;RELEASE-3.4.4&#39;.</p>
<p>Browsing the above URL will show the mercurial changelog.</p>
<p>A source tarball is available for download from:<br>
<a href=3D"http://xen.org/download/index_3.4.4.html">http://xen.org/downloa=
d/index_3.4.4.html</a></p>
<p>And the announcement on the Xen blog:<br>
<a href=3D"http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-releas=
e/">http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/</a><=
/p>
<p>Thanks to the many people who have contributed to this release!</p>
<p>Regards,<br>
The Xen Team</p>

--0015175cdc5676626c04b786a8b6--


--===============1419541268194685577==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1419541268194685577==--


From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:28:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:28:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqX0-0007db-Ue; Fri, 27 Jan 2012 18:28:14 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keith.coleman@n2servers.com>)
	id 1RqqWz-0007dF-Ns; Fri, 27 Jan 2012 18:28:13 +0000
X-Env-Sender: keith.coleman@n2servers.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327688886!12824892!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24832 invoked from network); 27 Jan 2012 18:28:07 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:28:07 -0000
Received: by bkar1 with SMTP id r1so3115621bka.30
	for <multiple recipients>; Fri, 27 Jan 2012 10:28:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.148.83 with SMTP id o19mr3617802bkv.132.1327688886673;
	Fri, 27 Jan 2012 10:28:06 -0800 (PST)
Received: by 10.205.83.74 with HTTP; Fri, 27 Jan 2012 10:28:06 -0800 (PST)
X-Originating-IP: [66.87.4.78]
Received: by 10.205.83.74 with HTTP; Fri, 27 Jan 2012 10:28:06 -0800 (PST)
In-Reply-To: <CAH4C7zGAcPGtMB2muWjxv7U+cXZE5qgSgpiZJ=QhP=Chw=A0vA@mail.gmail.com>
References: <CAH4C7zGAcPGtMB2muWjxv7U+cXZE5qgSgpiZJ=QhP=Chw=A0vA@mail.gmail.com>
Date: Fri, 27 Jan 2012 13:28:06 -0500
Message-ID: <CAH4C7zEDiG0o2a7Mt3-8j7vGZe-hybkwiirccsU84m6oOMc2wg@mail.gmail.com>
From: Keith Coleman <keith.coleman@n2servers.com>
To: xen-users <xen-users@lists.xensource.com>, 
	xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Xen 3.4.4 released
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1419541268194685577=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1419541268194685577==
Content-Type: multipart/alternative; boundary=0015175cdc5676626c04b786a8b6

--0015175cdc5676626c04b786a8b6
Content-Type: text/plain; charset=ISO-8859-1

Xen 3.4.4 is the latest maintenance release in the 3.4 stable branch. There
are a range of bug fixes since 3.4.3. We recommend users to upgrade.

Xen 3.4.4 includes:
 - Security enhancements including CVE-2011-1583
 - Support for AMD Family 15h (Bulldozer) CPUs
 - Performances and stability improvements
 - Various bux fixes

The source repository can be downloaded from:
http://xenbits.xensource.com/xen-3.4-testing.hg
The release is tagged 'RELEASE-3.4.4'.

Browsing the above URL will show the mercurial changelog.

A source tarball is available for download from:
http://xen.org/download/index_3.4.4.html

And the announcement on the Xen blog:
http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/

Thanks to the many people who have contributed to this release!

Regards,
The Xen Team

--0015175cdc5676626c04b786a8b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>Xen 3.4.4 is the latest maintenance release in the 3.4 stable branch. Th=
ere are a range of bug fixes since 3.4.3. We recommend users to upgrade.</p=
>
<p>Xen 3.4.4 includes:<br>
=A0- Security enhancements including CVE-2011-1583<br>
=A0- Support for AMD Family 15h (Bulldozer) CPUs<br>
=A0- Performances and stability improvements<br>
=A0- Various bux fixes</p>
<p>The source repository can be downloaded from:<br>
<a href=3D"http://xenbits.xensource.com/xen-3.4-testing.hg">http://xenbits.=
xensource.com/xen-3.4-testing.hg</a><br>
The release is tagged &#39;RELEASE-3.4.4&#39;.</p>
<p>Browsing the above URL will show the mercurial changelog.</p>
<p>A source tarball is available for download from:<br>
<a href=3D"http://xen.org/download/index_3.4.4.html">http://xen.org/downloa=
d/index_3.4.4.html</a></p>
<p>And the announcement on the Xen blog:<br>
<a href=3D"http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-releas=
e/">http://blog.xen.org/index.php/2012/01/27/xen-3-4-4-update-release/</a><=
/p>
<p>Thanks to the many people who have contributed to this release!</p>
<p>Regards,<br>
The Xen Team</p>

--0015175cdc5676626c04b786a8b6--


--===============1419541268194685577==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1419541268194685577==--


From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:29:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqYF-0007oG-Os; Fri, 27 Jan 2012 18:29:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqqYF-0007o9-2R
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:29:31 +0000
Received: from [85.158.138.51:12512] by server-12.bemta-3.messagelabs.com id
	4C/21-24557-A0DE22F4; Fri, 27 Jan 2012 18:29:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327688969!10803762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16500 invoked from network); 27 Jan 2012 18:29:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:29:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:29: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; Fri, 27 Jan 2012 18:29:29 +0000
Date: Fri, 27 Jan 2012 18:30:30 +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.1201271823240.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/2] Xen (PV and HVM) multiple PV consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series (sent before a few times) achieves two goals:

- make PV consoles work for PV on HVM guests;

- implement support for multiple PV consoles for PV and PV on HVM guests.



Changes in v2:

- nicer safety check in patch #1;

- kzalloc instead of kmalloc;

- removed the spin_lock in vtermno_to_xencons, use
list_for_each_entry_safe.


It has been tested with pv and hvm guests, with console=ttyS0,
console=hvc0, and earlyprintk=xen, with and without serial='pty' in the
VM config file.


Stefano Stabellini (2):
      hvc_xen: support PV on HVM consoles
      hvc_xen: implement multiconsole support

 drivers/tty/hvc/hvc_xen.c          |  455 ++++++++++++++++++++++++++++++++----
 include/xen/interface/hvm/params.h |    6 +-
 2 files changed, 420 insertions(+), 41 deletions(-)


A branch with these patches based on 3.2 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.2-multiconsole-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:29:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqYF-0007oG-Os; Fri, 27 Jan 2012 18:29:31 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqqYF-0007o9-2R
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:29:31 +0000
Received: from [85.158.138.51:12512] by server-12.bemta-3.messagelabs.com id
	4C/21-24557-A0DE22F4; Fri, 27 Jan 2012 18:29:30 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327688969!10803762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16500 invoked from network); 27 Jan 2012 18:29:29 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:29:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339804"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:29: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; Fri, 27 Jan 2012 18:29:29 +0000
Date: Fri, 27 Jan 2012 18:30:30 +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.1201271823240.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 0/2] Xen (PV and HVM) multiple PV consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series (sent before a few times) achieves two goals:

- make PV consoles work for PV on HVM guests;

- implement support for multiple PV consoles for PV and PV on HVM guests.



Changes in v2:

- nicer safety check in patch #1;

- kzalloc instead of kmalloc;

- removed the spin_lock in vtermno_to_xencons, use
list_for_each_entry_safe.


It has been tested with pv and hvm guests, with console=ttyS0,
console=hvc0, and earlyprintk=xen, with and without serial='pty' in the
VM config file.


Stefano Stabellini (2):
      hvc_xen: support PV on HVM consoles
      hvc_xen: implement multiconsole support

 drivers/tty/hvc/hvc_xen.c          |  455 ++++++++++++++++++++++++++++++++----
 include/xen/interface/hvm/params.h |    6 +-
 2 files changed, 420 insertions(+), 41 deletions(-)


A branch with these patches based on 3.2 is available here:

git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 3.2-multiconsole-2

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:30:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:30:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqZI-0007w3-TT; Fri, 27 Jan 2012 18:30:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqqZI-0007ve-7J
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:30:36 +0000
Received: from [85.158.138.51:16672] by server-5.bemta-3.messagelabs.com id
	B0/B2-02363-B4DE22F4; Fri, 27 Jan 2012 18:30:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327689033!10969490!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2153 invoked from network); 27 Jan 2012 18:30:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:30:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179416138"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:30:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:30: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 q0RIUOHC013543;
	Fri, 27 Jan 2012 10:30:25 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 18:31:36 +0000
Message-ID: <1327689097-12788-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.1201271823240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
MIME-Version: 1.0
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c          |   84 +++++++++++++++++++++++++++++-------
 include/xen/interface/hvm/params.h |    6 ++-
 2 files changed, 73 insertions(+), 17 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 52fdf60..d5000aa 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -24,9 +24,12 @@
 #include <linux/init.h>
 #include <linux/types.h>
 
+#include <asm/io.h>
 #include <asm/xen/hypervisor.h>
 
 #include <xen/xen.h>
+#include <xen/interface/xen.h>
+#include <xen/hvm.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
@@ -42,9 +45,13 @@ static int xencons_irq;
 /* ------------------------------------------------------------------ */
 
 static unsigned long console_pfn = ~0ul;
+static unsigned int console_evtchn = ~0ul;
+static struct xencons_interface *xencons_if = NULL;
 
 static inline struct xencons_interface *xencons_interface(void)
 {
+	if (xencons_if != NULL)
+		return xencons_if;
 	if (console_pfn == ~0ul)
 		return mfn_to_virt(xen_start_info->console.domU.mfn);
 	else
@@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
 static inline void notify_daemon(void)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
+	if (console_evtchn == ~0ul)
+		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
+	else
+		notify_remote_via_evtchn(console_evtchn);
 }
 
 static int __write_console(const char *data, int len)
@@ -157,28 +167,63 @@ static struct hv_ops dom0_hvc_ops = {
 	.notifier_hangup = notifier_hangup_irq,
 };
 
+static int xen_hvm_console_init(void)
+{
+	int r;
+	uint64_t v = 0;
+	unsigned long mfn;
+
+	if (!xen_hvm_domain())
+		return -ENODEV;
+
+	if (xencons_if != NULL)
+		return -EBUSY;
+
+	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
+	if (r < 0)
+		return -ENODEV;
+	console_evtchn = v;
+	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
+	if (r < 0)
+		return -ENODEV;
+	mfn = v;
+	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (xencons_if == NULL)
+		return -ENODEV;
+
+	return 0;
+}
+
 static int __init xen_hvc_init(void)
 {
 	struct hvc_struct *hp;
 	struct hv_ops *ops;
+	int r;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
 		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
 	} else {
-		if (!xen_start_info->console.domU.evtchn)
-			return -ENODEV;
-
 		ops = &domU_hvc_ops;
-		xencons_irq = bind_evtchn_to_irq(xen_start_info->console.domU.evtchn);
+		if (xen_pv_domain()) {
+			if (!xen_start_info->console.domU.evtchn)
+				return -ENODEV;
+			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
+			console_evtchn = xen_start_info->console.domU.evtchn;
+		} else {
+			r = xen_hvm_console_init();
+			if (r < 0)
+				return r;
+		}
+		xencons_irq = bind_evtchn_to_irq(console_evtchn);
+		if (xencons_irq < 0)
+			xencons_irq = 0; /* NO_IRQ */
+		else
+			irq_set_noprobe(xencons_irq);
 	}
-	if (xencons_irq < 0)
-		xencons_irq = 0; /* NO_IRQ */
-	else
-		irq_set_noprobe(xencons_irq);
 
 	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
 	if (IS_ERR(hp))
@@ -186,15 +231,13 @@ static int __init xen_hvc_init(void)
 
 	hvc = hp;
 
-	console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-
 	return 0;
 }
 
 void xen_console_resume(void)
 {
 	if (xencons_irq)
-		rebind_evtchn_irq(xen_start_info->console.domU.evtchn, xencons_irq);
+		rebind_evtchn_irq(console_evtchn, xencons_irq);
 }
 
 static void __exit xen_hvc_fini(void)
@@ -205,16 +248,22 @@ static void __exit xen_hvc_fini(void)
 
 static int xen_cons_init(void)
 {
-	struct hv_ops *ops;
+	const struct hv_ops *ops;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return 0;
 
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
-	else
+	else {
 		ops = &domU_hvc_ops;
 
+		if (xen_pv_domain())
+			console_evtchn = xen_start_info->console.domU.evtchn;
+		else
+			xen_hvm_console_init();
+	}
+
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
@@ -230,6 +279,9 @@ static void xenboot_write_console(struct console *console, const char *string,
 	unsigned int linelen, off = 0;
 	const char *pos;
 
+	if (!xen_pv_domain())
+		return;
+
 	dom0_write_console(0, string, len);
 
 	if (xen_initial_domain())
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index 1888d8c..1b4f923 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -90,6 +90,10 @@
 /* Boolean: Enable aligning all periodic vpts to reduce interrupts */
 #define HVM_PARAM_VPT_ALIGN    16
 
-#define HVM_NR_PARAMS          17
+/* Console debug shared memory ring and event channel */
+#define HVM_PARAM_CONSOLE_PFN    17
+#define HVM_PARAM_CONSOLE_EVTCHN 18
+
+#define HVM_NR_PARAMS          19
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_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 Jan 27 18:30:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:30:44 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqZI-0007w3-TT; Fri, 27 Jan 2012 18:30:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqqZI-0007ve-7J
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:30:36 +0000
Received: from [85.158.138.51:16672] by server-5.bemta-3.messagelabs.com id
	B0/B2-02363-B4DE22F4; Fri, 27 Jan 2012 18:30:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327689033!10969490!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2153 invoked from network); 27 Jan 2012 18:30:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:30:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179416138"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:30:32 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:30: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 q0RIUOHC013543;
	Fri, 27 Jan 2012 10:30:25 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 18:31:36 +0000
Message-ID: <1327689097-12788-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.1201271823240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
MIME-Version: 1.0
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c          |   84 +++++++++++++++++++++++++++++-------
 include/xen/interface/hvm/params.h |    6 ++-
 2 files changed, 73 insertions(+), 17 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 52fdf60..d5000aa 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -24,9 +24,12 @@
 #include <linux/init.h>
 #include <linux/types.h>
 
+#include <asm/io.h>
 #include <asm/xen/hypervisor.h>
 
 #include <xen/xen.h>
+#include <xen/interface/xen.h>
+#include <xen/hvm.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
@@ -42,9 +45,13 @@ static int xencons_irq;
 /* ------------------------------------------------------------------ */
 
 static unsigned long console_pfn = ~0ul;
+static unsigned int console_evtchn = ~0ul;
+static struct xencons_interface *xencons_if = NULL;
 
 static inline struct xencons_interface *xencons_interface(void)
 {
+	if (xencons_if != NULL)
+		return xencons_if;
 	if (console_pfn == ~0ul)
 		return mfn_to_virt(xen_start_info->console.domU.mfn);
 	else
@@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
 static inline void notify_daemon(void)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
+	if (console_evtchn == ~0ul)
+		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
+	else
+		notify_remote_via_evtchn(console_evtchn);
 }
 
 static int __write_console(const char *data, int len)
@@ -157,28 +167,63 @@ static struct hv_ops dom0_hvc_ops = {
 	.notifier_hangup = notifier_hangup_irq,
 };
 
+static int xen_hvm_console_init(void)
+{
+	int r;
+	uint64_t v = 0;
+	unsigned long mfn;
+
+	if (!xen_hvm_domain())
+		return -ENODEV;
+
+	if (xencons_if != NULL)
+		return -EBUSY;
+
+	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
+	if (r < 0)
+		return -ENODEV;
+	console_evtchn = v;
+	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
+	if (r < 0)
+		return -ENODEV;
+	mfn = v;
+	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (xencons_if == NULL)
+		return -ENODEV;
+
+	return 0;
+}
+
 static int __init xen_hvc_init(void)
 {
 	struct hvc_struct *hp;
 	struct hv_ops *ops;
+	int r;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return -ENODEV;
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
 		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
 	} else {
-		if (!xen_start_info->console.domU.evtchn)
-			return -ENODEV;
-
 		ops = &domU_hvc_ops;
-		xencons_irq = bind_evtchn_to_irq(xen_start_info->console.domU.evtchn);
+		if (xen_pv_domain()) {
+			if (!xen_start_info->console.domU.evtchn)
+				return -ENODEV;
+			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
+			console_evtchn = xen_start_info->console.domU.evtchn;
+		} else {
+			r = xen_hvm_console_init();
+			if (r < 0)
+				return r;
+		}
+		xencons_irq = bind_evtchn_to_irq(console_evtchn);
+		if (xencons_irq < 0)
+			xencons_irq = 0; /* NO_IRQ */
+		else
+			irq_set_noprobe(xencons_irq);
 	}
-	if (xencons_irq < 0)
-		xencons_irq = 0; /* NO_IRQ */
-	else
-		irq_set_noprobe(xencons_irq);
 
 	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
 	if (IS_ERR(hp))
@@ -186,15 +231,13 @@ static int __init xen_hvc_init(void)
 
 	hvc = hp;
 
-	console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-
 	return 0;
 }
 
 void xen_console_resume(void)
 {
 	if (xencons_irq)
-		rebind_evtchn_irq(xen_start_info->console.domU.evtchn, xencons_irq);
+		rebind_evtchn_irq(console_evtchn, xencons_irq);
 }
 
 static void __exit xen_hvc_fini(void)
@@ -205,16 +248,22 @@ static void __exit xen_hvc_fini(void)
 
 static int xen_cons_init(void)
 {
-	struct hv_ops *ops;
+	const struct hv_ops *ops;
 
-	if (!xen_pv_domain())
+	if (!xen_domain())
 		return 0;
 
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
-	else
+	else {
 		ops = &domU_hvc_ops;
 
+		if (xen_pv_domain())
+			console_evtchn = xen_start_info->console.domU.evtchn;
+		else
+			xen_hvm_console_init();
+	}
+
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
@@ -230,6 +279,9 @@ static void xenboot_write_console(struct console *console, const char *string,
 	unsigned int linelen, off = 0;
 	const char *pos;
 
+	if (!xen_pv_domain())
+		return;
+
 	dom0_write_console(0, string, len);
 
 	if (xen_initial_domain())
diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
index 1888d8c..1b4f923 100644
--- a/include/xen/interface/hvm/params.h
+++ b/include/xen/interface/hvm/params.h
@@ -90,6 +90,10 @@
 /* Boolean: Enable aligning all periodic vpts to reduce interrupts */
 #define HVM_PARAM_VPT_ALIGN    16
 
-#define HVM_NR_PARAMS          17
+/* Console debug shared memory ring and event channel */
+#define HVM_PARAM_CONSOLE_PFN    17
+#define HVM_PARAM_CONSOLE_EVTCHN 18
+
+#define HVM_NR_PARAMS          19
 
 #endif /* __XEN_PUBLIC_HVM_PARAMS_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 Jan 27 18:31:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqZs-00082e-3R; Fri, 27 Jan 2012 18:31:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqqZp-00081t-Rf
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:31:10 +0000
Received: from [85.158.138.51:17860] by server-6.bemta-3.messagelabs.com id
	7E/51-31032-D6DE22F4; Fri, 27 Jan 2012 18:31:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327689066!10948555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12144 invoked from network); 27 Jan 2012 18:31:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:31:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179416156"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:30:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:30: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 q0RIUOHD013543;
	Fri, 27 Jan 2012 10:30:27 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 18:31:37 +0000
Message-ID: <1327689097-12788-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.1201271823240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
MIME-Version: 1.0
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements support for multiple consoles:
consoles other than the first one are setup using the traditional xenbus
and grant-table based mechanism.
We use a list to keep track of the allocated consoles, we don't
expect too many of them anyway.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 381 insertions(+), 58 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index d5000aa..8209293 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -23,6 +23,7 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/types.h>
+#include <linux/list.h>
 
 #include <asm/io.h>
 #include <asm/xen/hypervisor.h>
@@ -30,47 +31,67 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/hvm.h>
+#include <xen/grant_table.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
 #include <xen/hvc-console.h>
+#include <xen/xenbus.h>
 
 #include "hvc_console.h"
 
 #define HVC_COOKIE   0x58656e /* "Xen" in hex */
 
-static struct hvc_struct *hvc;
-static int xencons_irq;
+struct xencons_info {
+	struct list_head list;
+	struct xenbus_device *xbdev;
+	struct xencons_interface *intf;
+	unsigned int evtchn;
+	struct hvc_struct *hvc;
+	int irq;
+	int vtermno;
+	grant_ref_t gntref;
+};
+
+static LIST_HEAD(xenconsoles);
+static DEFINE_SPINLOCK(xencons_lock);
+static struct xenbus_driver xencons_driver;
 
 /* ------------------------------------------------------------------ */
 
-static unsigned long console_pfn = ~0ul;
-static unsigned int console_evtchn = ~0ul;
-static struct xencons_interface *xencons_if = NULL;
+static struct xencons_info *vtermno_to_xencons(int vtermno)
+{
+	struct xencons_info *entry, *n, *ret = NULL;
+
+	if (list_empty(&xenconsoles))
+			return NULL;
 
-static inline struct xencons_interface *xencons_interface(void)
+	list_for_each_entry_safe(entry, n, &xenconsoles, list) {
+		if (entry->vtermno == vtermno) {
+			ret  = entry;
+			break;
+		}
+	}
+
+	return ret;
+}
+
+static inline int xenbus_devid_to_vtermno(int devid)
 {
-	if (xencons_if != NULL)
-		return xencons_if;
-	if (console_pfn == ~0ul)
-		return mfn_to_virt(xen_start_info->console.domU.mfn);
-	else
-		return __va(console_pfn << PAGE_SHIFT);
+	return devid + HVC_COOKIE;
 }
 
-static inline void notify_daemon(void)
+static inline void notify_daemon(struct xencons_info *cons)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	if (console_evtchn == ~0ul)
-		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
-	else
-		notify_remote_via_evtchn(console_evtchn);
+	notify_remote_via_evtchn(cons->evtchn);
 }
 
-static int __write_console(const char *data, int len)
+static int __write_console(struct xencons_info *xencons,
+		const char *data, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
 	XENCONS_RING_IDX cons, prod;
+	struct xencons_interface *intf = xencons->intf;
 	int sent = 0;
 
 	cons = intf->out_cons;
@@ -85,13 +106,16 @@ static int __write_console(const char *data, int len)
 	intf->out_prod = prod;
 
 	if (sent)
-		notify_daemon();
+		notify_daemon(xencons);
 	return sent;
 }
 
 static int domU_write_console(uint32_t vtermno, const char *data, int len)
 {
 	int ret = len;
+	struct xencons_info *cons = vtermno_to_xencons(vtermno);
+	if (cons == NULL)
+		return -EINVAL;
 
 	/*
 	 * Make sure the whole buffer is emitted, polling if
@@ -100,7 +124,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 	 * kernel is crippled.
 	 */
 	while (len) {
-		int sent = __write_console(data, len);
+		int sent = __write_console(cons, data, len);
 		
 		data += sent;
 		len -= sent;
@@ -114,9 +138,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 
 static int domU_read_console(uint32_t vtermno, char *buf, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
+	struct xencons_interface *intf;
 	XENCONS_RING_IDX cons, prod;
 	int recv = 0;
+	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
+	if (xencons == NULL)
+		return -EINVAL;
+	intf = xencons->intf;
 
 	cons = intf->in_cons;
 	prod = intf->in_prod;
@@ -129,7 +157,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
 	mb();			/* read ring before consuming */
 	intf->in_cons = cons;
 
-	notify_daemon();
+	notify_daemon(xencons);
 	return recv;
 }
 
@@ -172,78 +200,360 @@ static int xen_hvm_console_init(void)
 	int r;
 	uint64_t v = 0;
 	unsigned long mfn;
+	struct xencons_info *info;
 
 	if (!xen_hvm_domain())
 		return -ENODEV;
 
-	if (xencons_if != NULL)
-		return -EBUSY;
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
 
 	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
-	console_evtchn = v;
+	}
+	info->evtchn = v;
 	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
+	}
 	mfn = v;
-	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
-	if (xencons_if == NULL)
+	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (info->intf == NULL) {
+		kfree(info);
+		return -ENODEV;
+	}
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_pv_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_pv_domain())
 		return -ENODEV;
 
+	if (!xen_start_info->console.domU.evtchn)
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
+
+	info->evtchn = xen_start_info->console.domU.evtchn;
+	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_initial_domain_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
 	return 0;
 }
 
 static int __init xen_hvc_init(void)
 {
-	struct hvc_struct *hp;
-	struct hv_ops *ops;
 	int r;
+	struct xencons_info *info;
+	const struct hv_ops *ops;
 
 	if (!xen_domain())
 		return -ENODEV;
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
-		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+		r = xen_initial_domain_console_init();
+		if (r < 0)
+			return r;
+		info = vtermno_to_xencons(HVC_COOKIE);
 	} else {
 		ops = &domU_hvc_ops;
-		if (xen_pv_domain()) {
-			if (!xen_start_info->console.domU.evtchn)
-				return -ENODEV;
-			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-			console_evtchn = xen_start_info->console.domU.evtchn;
-		} else {
+		if (xen_hvm_domain())
 			r = xen_hvm_console_init();
-			if (r < 0)
-				return r;
-		}
-		xencons_irq = bind_evtchn_to_irq(console_evtchn);
-		if (xencons_irq < 0)
-			xencons_irq = 0; /* NO_IRQ */
 		else
-			irq_set_noprobe(xencons_irq);
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
+
+		info = vtermno_to_xencons(HVC_COOKIE);
+		info->irq = bind_evtchn_to_irq(info->evtchn);
+	}
+	if (info->irq < 0)
+		info->irq = 0; /* NO_IRQ */
+	else
+		irq_set_noprobe(info->irq);
+
+	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
+	if (IS_ERR(info->hvc)) {
+		r = PTR_ERR(info->hvc);
+		spin_lock(&xencons_lock);
+		list_del(&info->list);
+		spin_unlock(&xencons_lock);
+		if (info->irq)
+			unbind_from_irqhandler(info->irq, NULL);
+		kfree(info);
+		return r;
 	}
 
-	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
-	if (IS_ERR(hp))
-		return PTR_ERR(hp);
+	return xenbus_register_frontend(&xencons_driver);
+}
 
-	hvc = hp;
+void xen_console_resume(void)
+{
+	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
+	if (info != NULL && info->irq)
+		rebind_evtchn_irq(info->evtchn, info->irq);
+}
 
+static void xencons_disconnect_backend(struct xencons_info *info)
+{
+	if (info->irq > 0)
+		unbind_from_irqhandler(info->irq, NULL);
+	info->irq = 0;
+	if (info->evtchn > 0)
+		xenbus_free_evtchn(info->xbdev, info->evtchn);
+	info->evtchn = 0;
+	if (info->gntref > 0)
+		gnttab_free_grant_references(info->gntref);
+	info->gntref = 0;
+	if (info->hvc != NULL)
+		hvc_remove(info->hvc);
+	info->hvc = NULL;
+}
+
+static void xencons_free(struct xencons_info *info)
+{
+	xencons_disconnect_backend(info);
+	free_page((unsigned long)info->intf);
+	info->intf = NULL;
+	info->vtermno = 0;
+	kfree(info);
+}
+
+static int xencons_remove(struct xenbus_device *dev)
+{
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	spin_lock(&xencons_lock);
+	list_del(&info->list);
+	spin_unlock(&xencons_lock);
+	xencons_free(info);
 	return 0;
 }
 
-void xen_console_resume(void)
+static int xencons_connect_backend(struct xenbus_device *dev,
+				  struct xencons_info *info)
+{
+	int ret, evtchn, devid, ref, irq;
+	struct xenbus_transaction xbt;
+	grant_ref_t gref_head;
+	unsigned long mfn;
+
+	ret = xenbus_alloc_evtchn(dev, &evtchn);
+	if (ret)
+		return ret;
+	info->evtchn = evtchn;
+	irq = bind_evtchn_to_irq(evtchn);
+	if (irq < 0)
+		return irq;
+	info->irq = irq;
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
+			irq, &domU_hvc_ops, 256);
+	if (IS_ERR(info->hvc))
+		return PTR_ERR(info->hvc);
+	if (xen_pv_domain())
+		mfn = virt_to_mfn(info->intf);
+	else
+		mfn = __pa(info->intf) >> PAGE_SHIFT;
+	ret = gnttab_alloc_grant_references(1, &gref_head);
+	if (ret < 0)
+		return ret;
+	info->gntref = gref_head;
+	ref = gnttab_claim_grant_reference(&gref_head);
+	if (ref < 0)
+		return ref;
+	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
+			mfn, 0);
+
+ again:
+	ret = xenbus_transaction_start(&xbt);
+	if (ret) {
+		xenbus_dev_fatal(dev, ret, "starting transaction");
+		return ret;
+	}
+	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
+			    evtchn);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_transaction_end(xbt, 0);
+	if (ret) {
+		if (ret == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, ret, "completing transaction");
+		return ret;
+	}
+
+	xenbus_switch_state(dev, XenbusStateInitialised);
+	return 0;
+
+ error_xenbus:
+	xenbus_transaction_end(xbt, 1);
+	xenbus_dev_fatal(dev, ret, "writing xenstore");
+	return ret;
+}
+
+static int __devinit xencons_probe(struct xenbus_device *dev,
+				  const struct xenbus_device_id *id)
 {
-	if (xencons_irq)
-		rebind_evtchn_irq(console_evtchn, xencons_irq);
+	int ret, devid;
+	struct xencons_info *info;
+
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	if (devid == 0)
+		return -ENODEV;
+
+	info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+	if (!info)
+		goto error_nomem;
+	dev_set_drvdata(&dev->dev, info);
+	info->xbdev = dev;
+	info->vtermno = xenbus_devid_to_vtermno(devid);
+	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+	if (!info->intf)
+		goto error_nomem;
+
+	ret = xencons_connect_backend(dev, info);
+	if (ret < 0)
+		goto error;
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+
+ error_nomem:
+	ret = -ENOMEM;
+	xenbus_dev_fatal(dev, ret, "allocating device memory");
+ error:
+	xencons_free(info);
+	return ret;
+}
+
+static int xencons_resume(struct xenbus_device *dev)
+{
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	xencons_disconnect_backend(info);
+	memset(info->intf, 0, PAGE_SIZE);
+	return xencons_connect_backend(dev, info);
 }
 
+static void xencons_backend_changed(struct xenbus_device *dev,
+				   enum xenbus_state backend_state)
+{
+	switch (backend_state) {
+	case XenbusStateReconfiguring:
+	case XenbusStateReconfigured:
+	case XenbusStateInitialising:
+	case XenbusStateInitialised:
+	case XenbusStateUnknown:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitWait:
+		break;
+
+	case XenbusStateConnected:
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateClosing:
+		xenbus_frontend_closed(dev);
+		break;
+	}
+}
+
+static const struct xenbus_device_id xencons_ids[] = {
+	{ "console" },
+	{ "" }
+};
+
+
 static void __exit xen_hvc_fini(void)
 {
-	if (hvc)
-		hvc_remove(hvc);
+	struct xencons_info *entry, *next;
+
+	if (list_empty(&xenconsoles))
+			return;
+
+	spin_lock(&xencons_lock);
+	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
+		list_del(&entry->list);
+		if (entry->xbdev)
+			xencons_remove(entry->xbdev);
+		else {
+			if (entry->irq > 0)
+				unbind_from_irqhandler(entry->irq, NULL);
+			if (entry->hvc);
+				hvc_remove(entry->hvc);
+			kfree(entry);
+		}
+	}
+	spin_unlock(&xencons_lock);
 }
 
 static int xen_cons_init(void)
@@ -256,18 +566,31 @@ static int xen_cons_init(void)
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
 	else {
+		int r;
 		ops = &domU_hvc_ops;
 
-		if (xen_pv_domain())
-			console_evtchn = xen_start_info->console.domU.evtchn;
+		if (xen_hvm_domain())
+			r = xen_hvm_console_init();
 		else
-			xen_hvm_console_init();
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
 	}
 
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
 
+static struct xenbus_driver xencons_driver = {
+	.name = "xenconsole",
+	.owner = THIS_MODULE,
+	.ids = xencons_ids,
+	.probe = xencons_probe,
+	.remove = xencons_remove,
+	.resume = xencons_resume,
+	.otherend_changed = xencons_backend_changed,
+};
+
 module_init(xen_hvc_init);
 module_exit(xen_hvc_fini);
 console_initcall(xen_cons_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:31:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqZs-00082e-3R; Fri, 27 Jan 2012 18:31:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RqqZp-00081t-Rf
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:31:10 +0000
Received: from [85.158.138.51:17860] by server-6.bemta-3.messagelabs.com id
	7E/51-31032-D6DE22F4; Fri, 27 Jan 2012 18:31:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327689066!10948555!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjY1MDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12144 invoked from network); 27 Jan 2012 18:31:07 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-8.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:31:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="179416156"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 13:30:39 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 13:30: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 q0RIUOHD013543;
	Fri, 27 Jan 2012 10:30:27 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 18:31:37 +0000
Message-ID: <1327689097-12788-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.1201271823240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
MIME-Version: 1.0
Cc: konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v2 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements support for multiple consoles:
consoles other than the first one are setup using the traditional xenbus
and grant-table based mechanism.
We use a list to keep track of the allocated consoles, we don't
expect too many of them anyway.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 381 insertions(+), 58 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index d5000aa..8209293 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -23,6 +23,7 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/types.h>
+#include <linux/list.h>
 
 #include <asm/io.h>
 #include <asm/xen/hypervisor.h>
@@ -30,47 +31,67 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/hvm.h>
+#include <xen/grant_table.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
 #include <xen/hvc-console.h>
+#include <xen/xenbus.h>
 
 #include "hvc_console.h"
 
 #define HVC_COOKIE   0x58656e /* "Xen" in hex */
 
-static struct hvc_struct *hvc;
-static int xencons_irq;
+struct xencons_info {
+	struct list_head list;
+	struct xenbus_device *xbdev;
+	struct xencons_interface *intf;
+	unsigned int evtchn;
+	struct hvc_struct *hvc;
+	int irq;
+	int vtermno;
+	grant_ref_t gntref;
+};
+
+static LIST_HEAD(xenconsoles);
+static DEFINE_SPINLOCK(xencons_lock);
+static struct xenbus_driver xencons_driver;
 
 /* ------------------------------------------------------------------ */
 
-static unsigned long console_pfn = ~0ul;
-static unsigned int console_evtchn = ~0ul;
-static struct xencons_interface *xencons_if = NULL;
+static struct xencons_info *vtermno_to_xencons(int vtermno)
+{
+	struct xencons_info *entry, *n, *ret = NULL;
+
+	if (list_empty(&xenconsoles))
+			return NULL;
 
-static inline struct xencons_interface *xencons_interface(void)
+	list_for_each_entry_safe(entry, n, &xenconsoles, list) {
+		if (entry->vtermno == vtermno) {
+			ret  = entry;
+			break;
+		}
+	}
+
+	return ret;
+}
+
+static inline int xenbus_devid_to_vtermno(int devid)
 {
-	if (xencons_if != NULL)
-		return xencons_if;
-	if (console_pfn == ~0ul)
-		return mfn_to_virt(xen_start_info->console.domU.mfn);
-	else
-		return __va(console_pfn << PAGE_SHIFT);
+	return devid + HVC_COOKIE;
 }
 
-static inline void notify_daemon(void)
+static inline void notify_daemon(struct xencons_info *cons)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	if (console_evtchn == ~0ul)
-		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
-	else
-		notify_remote_via_evtchn(console_evtchn);
+	notify_remote_via_evtchn(cons->evtchn);
 }
 
-static int __write_console(const char *data, int len)
+static int __write_console(struct xencons_info *xencons,
+		const char *data, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
 	XENCONS_RING_IDX cons, prod;
+	struct xencons_interface *intf = xencons->intf;
 	int sent = 0;
 
 	cons = intf->out_cons;
@@ -85,13 +106,16 @@ static int __write_console(const char *data, int len)
 	intf->out_prod = prod;
 
 	if (sent)
-		notify_daemon();
+		notify_daemon(xencons);
 	return sent;
 }
 
 static int domU_write_console(uint32_t vtermno, const char *data, int len)
 {
 	int ret = len;
+	struct xencons_info *cons = vtermno_to_xencons(vtermno);
+	if (cons == NULL)
+		return -EINVAL;
 
 	/*
 	 * Make sure the whole buffer is emitted, polling if
@@ -100,7 +124,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 	 * kernel is crippled.
 	 */
 	while (len) {
-		int sent = __write_console(data, len);
+		int sent = __write_console(cons, data, len);
 		
 		data += sent;
 		len -= sent;
@@ -114,9 +138,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 
 static int domU_read_console(uint32_t vtermno, char *buf, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
+	struct xencons_interface *intf;
 	XENCONS_RING_IDX cons, prod;
 	int recv = 0;
+	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
+	if (xencons == NULL)
+		return -EINVAL;
+	intf = xencons->intf;
 
 	cons = intf->in_cons;
 	prod = intf->in_prod;
@@ -129,7 +157,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
 	mb();			/* read ring before consuming */
 	intf->in_cons = cons;
 
-	notify_daemon();
+	notify_daemon(xencons);
 	return recv;
 }
 
@@ -172,78 +200,360 @@ static int xen_hvm_console_init(void)
 	int r;
 	uint64_t v = 0;
 	unsigned long mfn;
+	struct xencons_info *info;
 
 	if (!xen_hvm_domain())
 		return -ENODEV;
 
-	if (xencons_if != NULL)
-		return -EBUSY;
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
 
 	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
-	console_evtchn = v;
+	}
+	info->evtchn = v;
 	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
+	}
 	mfn = v;
-	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
-	if (xencons_if == NULL)
+	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (info->intf == NULL) {
+		kfree(info);
+		return -ENODEV;
+	}
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_pv_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_pv_domain())
 		return -ENODEV;
 
+	if (!xen_start_info->console.domU.evtchn)
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
+
+	info->evtchn = xen_start_info->console.domU.evtchn;
+	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_initial_domain_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_initial_domain())
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
 	return 0;
 }
 
 static int __init xen_hvc_init(void)
 {
-	struct hvc_struct *hp;
-	struct hv_ops *ops;
 	int r;
+	struct xencons_info *info;
+	const struct hv_ops *ops;
 
 	if (!xen_domain())
 		return -ENODEV;
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
-		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+		r = xen_initial_domain_console_init();
+		if (r < 0)
+			return r;
+		info = vtermno_to_xencons(HVC_COOKIE);
 	} else {
 		ops = &domU_hvc_ops;
-		if (xen_pv_domain()) {
-			if (!xen_start_info->console.domU.evtchn)
-				return -ENODEV;
-			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-			console_evtchn = xen_start_info->console.domU.evtchn;
-		} else {
+		if (xen_hvm_domain())
 			r = xen_hvm_console_init();
-			if (r < 0)
-				return r;
-		}
-		xencons_irq = bind_evtchn_to_irq(console_evtchn);
-		if (xencons_irq < 0)
-			xencons_irq = 0; /* NO_IRQ */
 		else
-			irq_set_noprobe(xencons_irq);
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
+
+		info = vtermno_to_xencons(HVC_COOKIE);
+		info->irq = bind_evtchn_to_irq(info->evtchn);
+	}
+	if (info->irq < 0)
+		info->irq = 0; /* NO_IRQ */
+	else
+		irq_set_noprobe(info->irq);
+
+	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
+	if (IS_ERR(info->hvc)) {
+		r = PTR_ERR(info->hvc);
+		spin_lock(&xencons_lock);
+		list_del(&info->list);
+		spin_unlock(&xencons_lock);
+		if (info->irq)
+			unbind_from_irqhandler(info->irq, NULL);
+		kfree(info);
+		return r;
 	}
 
-	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
-	if (IS_ERR(hp))
-		return PTR_ERR(hp);
+	return xenbus_register_frontend(&xencons_driver);
+}
 
-	hvc = hp;
+void xen_console_resume(void)
+{
+	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
+	if (info != NULL && info->irq)
+		rebind_evtchn_irq(info->evtchn, info->irq);
+}
 
+static void xencons_disconnect_backend(struct xencons_info *info)
+{
+	if (info->irq > 0)
+		unbind_from_irqhandler(info->irq, NULL);
+	info->irq = 0;
+	if (info->evtchn > 0)
+		xenbus_free_evtchn(info->xbdev, info->evtchn);
+	info->evtchn = 0;
+	if (info->gntref > 0)
+		gnttab_free_grant_references(info->gntref);
+	info->gntref = 0;
+	if (info->hvc != NULL)
+		hvc_remove(info->hvc);
+	info->hvc = NULL;
+}
+
+static void xencons_free(struct xencons_info *info)
+{
+	xencons_disconnect_backend(info);
+	free_page((unsigned long)info->intf);
+	info->intf = NULL;
+	info->vtermno = 0;
+	kfree(info);
+}
+
+static int xencons_remove(struct xenbus_device *dev)
+{
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	spin_lock(&xencons_lock);
+	list_del(&info->list);
+	spin_unlock(&xencons_lock);
+	xencons_free(info);
 	return 0;
 }
 
-void xen_console_resume(void)
+static int xencons_connect_backend(struct xenbus_device *dev,
+				  struct xencons_info *info)
+{
+	int ret, evtchn, devid, ref, irq;
+	struct xenbus_transaction xbt;
+	grant_ref_t gref_head;
+	unsigned long mfn;
+
+	ret = xenbus_alloc_evtchn(dev, &evtchn);
+	if (ret)
+		return ret;
+	info->evtchn = evtchn;
+	irq = bind_evtchn_to_irq(evtchn);
+	if (irq < 0)
+		return irq;
+	info->irq = irq;
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
+			irq, &domU_hvc_ops, 256);
+	if (IS_ERR(info->hvc))
+		return PTR_ERR(info->hvc);
+	if (xen_pv_domain())
+		mfn = virt_to_mfn(info->intf);
+	else
+		mfn = __pa(info->intf) >> PAGE_SHIFT;
+	ret = gnttab_alloc_grant_references(1, &gref_head);
+	if (ret < 0)
+		return ret;
+	info->gntref = gref_head;
+	ref = gnttab_claim_grant_reference(&gref_head);
+	if (ref < 0)
+		return ref;
+	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
+			mfn, 0);
+
+ again:
+	ret = xenbus_transaction_start(&xbt);
+	if (ret) {
+		xenbus_dev_fatal(dev, ret, "starting transaction");
+		return ret;
+	}
+	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
+			    evtchn);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_transaction_end(xbt, 0);
+	if (ret) {
+		if (ret == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, ret, "completing transaction");
+		return ret;
+	}
+
+	xenbus_switch_state(dev, XenbusStateInitialised);
+	return 0;
+
+ error_xenbus:
+	xenbus_transaction_end(xbt, 1);
+	xenbus_dev_fatal(dev, ret, "writing xenstore");
+	return ret;
+}
+
+static int __devinit xencons_probe(struct xenbus_device *dev,
+				  const struct xenbus_device_id *id)
 {
-	if (xencons_irq)
-		rebind_evtchn_irq(console_evtchn, xencons_irq);
+	int ret, devid;
+	struct xencons_info *info;
+
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	if (devid == 0)
+		return -ENODEV;
+
+	info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+	if (!info)
+		goto error_nomem;
+	dev_set_drvdata(&dev->dev, info);
+	info->xbdev = dev;
+	info->vtermno = xenbus_devid_to_vtermno(devid);
+	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+	if (!info->intf)
+		goto error_nomem;
+
+	ret = xencons_connect_backend(dev, info);
+	if (ret < 0)
+		goto error;
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+
+ error_nomem:
+	ret = -ENOMEM;
+	xenbus_dev_fatal(dev, ret, "allocating device memory");
+ error:
+	xencons_free(info);
+	return ret;
+}
+
+static int xencons_resume(struct xenbus_device *dev)
+{
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	xencons_disconnect_backend(info);
+	memset(info->intf, 0, PAGE_SIZE);
+	return xencons_connect_backend(dev, info);
 }
 
+static void xencons_backend_changed(struct xenbus_device *dev,
+				   enum xenbus_state backend_state)
+{
+	switch (backend_state) {
+	case XenbusStateReconfiguring:
+	case XenbusStateReconfigured:
+	case XenbusStateInitialising:
+	case XenbusStateInitialised:
+	case XenbusStateUnknown:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitWait:
+		break;
+
+	case XenbusStateConnected:
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateClosing:
+		xenbus_frontend_closed(dev);
+		break;
+	}
+}
+
+static const struct xenbus_device_id xencons_ids[] = {
+	{ "console" },
+	{ "" }
+};
+
+
 static void __exit xen_hvc_fini(void)
 {
-	if (hvc)
-		hvc_remove(hvc);
+	struct xencons_info *entry, *next;
+
+	if (list_empty(&xenconsoles))
+			return;
+
+	spin_lock(&xencons_lock);
+	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
+		list_del(&entry->list);
+		if (entry->xbdev)
+			xencons_remove(entry->xbdev);
+		else {
+			if (entry->irq > 0)
+				unbind_from_irqhandler(entry->irq, NULL);
+			if (entry->hvc);
+				hvc_remove(entry->hvc);
+			kfree(entry);
+		}
+	}
+	spin_unlock(&xencons_lock);
 }
 
 static int xen_cons_init(void)
@@ -256,18 +566,31 @@ static int xen_cons_init(void)
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
 	else {
+		int r;
 		ops = &domU_hvc_ops;
 
-		if (xen_pv_domain())
-			console_evtchn = xen_start_info->console.domU.evtchn;
+		if (xen_hvm_domain())
+			r = xen_hvm_console_init();
 		else
-			xen_hvm_console_init();
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
 	}
 
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
 
+static struct xenbus_driver xencons_driver = {
+	.name = "xenconsole",
+	.owner = THIS_MODULE,
+	.ids = xencons_ids,
+	.probe = xencons_probe,
+	.remove = xencons_remove,
+	.resume = xencons_resume,
+	.otherend_changed = xencons_backend_changed,
+};
+
 module_init(xen_hvc_init);
 module_exit(xen_hvc_fini);
 console_initcall(xen_cons_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:33:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1Rqqc6-0000Bo-Nt; Fri, 27 Jan 2012 18:33: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 1Rqqc5-0000AU-DS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:33:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327689202!12849364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13324 invoked from network); 27 Jan 2012 18:33:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:33: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, 27 Jan 2012 18:33: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
	1Rqqbn-0005YL-6Q; Fri, 27 Jan 2012 18:33:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqqbn-0006Fd-5T;
	Fri, 27 Jan 2012 18:33:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.60903.156086.894334@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:33:11 +0000
To: andres@lagarcavilla.org
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b288b972af18d0e1607ff99bd6848834.squirrel@webmail.lagarcavilla.org>
References: <mailman.1637.1327585244.1471.xen-devel@lists.xensource.com>
	<b288b972af18d0e1607ff99bd6848834.squirrel@webmail.lagarcavilla.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: handle fallback in
 linux_privcmd_map_foreign_bulk properly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1327584962 -3600
> > # Node ID aa0d678fece208975984e8e59ca223c07fc50c06
> > # Parent  89fdabcf315fdaabeebf05c51a6b3b6dd4c20e85
> > tools/libxc: handle fallback in linux_privcmd_map_foreign_bulk properly

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 Jan 27 18:33:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1Rqqc6-0000Bo-Nt; Fri, 27 Jan 2012 18:33: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 1Rqqc5-0000AU-DS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:33:29 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327689202!12849364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13324 invoked from network); 27 Jan 2012 18:33:23 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 18:33:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10339871"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 18:33: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, 27 Jan 2012 18:33: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
	1Rqqbn-0005YL-6Q; Fri, 27 Jan 2012 18:33:11 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqqbn-0006Fd-5T;
	Fri, 27 Jan 2012 18:33:11 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.60903.156086.894334@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 18:33:11 +0000
To: andres@lagarcavilla.org
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <b288b972af18d0e1607ff99bd6848834.squirrel@webmail.lagarcavilla.org>
References: <mailman.1637.1327585244.1471.xen-devel@lists.xensource.com>
	<b288b972af18d0e1607ff99bd6848834.squirrel@webmail.lagarcavilla.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: olaf@aepfle.de, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: handle fallback in
 linux_privcmd_map_foreign_bulk properly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1327584962 -3600
> > # Node ID aa0d678fece208975984e8e59ca223c07fc50c06
> > # Parent  89fdabcf315fdaabeebf05c51a6b3b6dd4c20e85
> > tools/libxc: handle fallback in linux_privcmd_map_foreign_bulk properly

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 Jan 27 18:36:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqqem-0000bd-Ji; Fri, 27 Jan 2012 18:36:16 +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 1Rqqek-0000bD-M4
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:36:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327689366!12677156!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1814 invoked from network); 27 Jan 2012 18:36:08 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 18:36: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
	q0RIa2Ir010163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 27 Jan 2012 13:36:02 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0RIa2e0010160;
	Fri, 27 Jan 2012 13:36:02 -0500
Date: Fri, 27 Jan 2012 14:36:02 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127183602.GA9780@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120127160355.GA566@andromeda.dapyr.net>
	<alpine.DEB.2.00.1201271713200.3196@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201271713200.3196@kaball-desktop>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 05:16:45PM +0000, Stefano Stabellini wrote:
> On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 26, 2012 at 12:43:27PM +0000, Stefano Stabellini wrote:
> > > This patch implements support for multiple consoles:
> > > consoles other than the first one are setup using the traditional xenbus
> > > and grant-table based mechanism.
> > > We use a list to keep track of the allocated consoles, we don't
> > > expect too many of them anyway.
> > >
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
> > >  1 files changed, 383 insertions(+), 56 deletions(-)
> > >
> > > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > > index dd6641f..97732fb 100644
> > > --- a/drivers/tty/hvc/hvc_xen.c
> > > +++ b/drivers/tty/hvc/hvc_xen.c
> > > @@ -23,6 +23,7 @@
> > >  #include <linux/err.h>
> > >  #include <linux/init.h>
> > >  #include <linux/types.h>
> > > +#include <linux/list.h>
> > >
> > >  #include <asm/io.h>
> > >  #include <asm/xen/hypervisor.h>
> > > @@ -30,47 +31,69 @@
> > >  #include <xen/xen.h>
> > >  #include <xen/interface/xen.h>
> > >  #include <xen/hvm.h>
> > > +#include <xen/grant_table.h>
> > >  #include <xen/page.h>
> > >  #include <xen/events.h>
> > >  #include <xen/interface/io/console.h>
> > >  #include <xen/hvc-console.h>
> > > +#include <xen/xenbus.h>
> > >
> > >  #include "hvc_console.h"
> > >
> > >  #define HVC_COOKIE   0x58656e /* "Xen" in hex */
> > >
> > > -static struct hvc_struct *hvc;
> > > -static int xencons_irq;
> > > +struct xencons_info {
> > > +     struct list_head list;
> > > +     struct xenbus_device *xbdev;
> > > +     struct xencons_interface *intf;
> > > +     unsigned int evtchn;
> > > +     struct hvc_struct *hvc;
> > > +     int irq;
> > > +     int vtermno;
> > > +     grant_ref_t gntref;
> > > +};
> > > +
> > > +static LIST_HEAD(xenconsoles);
> > > +static DEFINE_SPINLOCK(xencons_lock);
> > > +static struct xenbus_driver xencons_driver;
> > >
> > >  /* ------------------------------------------------------------------ */
> > >
> > > -static unsigned long console_pfn = ~0ul;
> > > -static unsigned int console_evtchn = ~0ul;
> > > -static struct xencons_interface *xencons_if = NULL;
> > > +static struct xencons_info *vtermno_to_xencons(int vtermno)
> > > +{
> > > +     struct xencons_info *entry, *ret = NULL;
> > > +
> > > +     if (list_empty(&xenconsoles))
> > > +                     return NULL;
> > >
> > > -static inline struct xencons_interface *xencons_interface(void)
> > > +     spin_lock(&xencons_lock);
> > 
> > This spinlock gets hit everytime something is typed or written on the
> > console right? Isn't there an spinlock already in the hvc driver...
> > 
> > Or are we protected by the vtermnos being checked for -1?
> 
> I think you are right: the spinlock is there to protect access to the
> list, so we can change list_for_each_entry to list_for_each_entry_safe
> in vtermno_to_xencons and we solve the problem. All the other spinlock
> acquisitions are done at console creation/destruction.

Right. So I think this will work as long as you mkae the call
to hvc_remove _before_ your remove entries from the xenconsoles.

That way hvc_remove will set vtermnos[x] to -1 and inhibit
any callers from calling into us.

This means you will need to redo the xencons_remove and xencons_free
a bit.. Hmm, there looks to be dead-lock there - let me send the
details.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:36:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:36:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqqem-0000bd-Ji; Fri, 27 Jan 2012 18:36:16 +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 1Rqqek-0000bD-M4
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:36:14 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327689366!12677156!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1814 invoked from network); 27 Jan 2012 18:36:08 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 18:36: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
	q0RIa2Ir010163
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 27 Jan 2012 13:36:02 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0RIa2e0010160;
	Fri, 27 Jan 2012 13:36:02 -0500
Date: Fri, 27 Jan 2012 14:36:02 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127183602.GA9780@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120127160355.GA566@andromeda.dapyr.net>
	<alpine.DEB.2.00.1201271713200.3196@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201271713200.3196@kaball-desktop>
User-Agent: Mutt/1.5.9i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 05:16:45PM +0000, Stefano Stabellini wrote:
> On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > On Thu, Jan 26, 2012 at 12:43:27PM +0000, Stefano Stabellini wrote:
> > > This patch implements support for multiple consoles:
> > > consoles other than the first one are setup using the traditional xenbus
> > > and grant-table based mechanism.
> > > We use a list to keep track of the allocated consoles, we don't
> > > expect too many of them anyway.
> > >
> > > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > ---
> > >  drivers/tty/hvc/hvc_xen.c |  439 +++++++++++++++++++++++++++++++++++++++------
> > >  1 files changed, 383 insertions(+), 56 deletions(-)
> > >
> > > diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> > > index dd6641f..97732fb 100644
> > > --- a/drivers/tty/hvc/hvc_xen.c
> > > +++ b/drivers/tty/hvc/hvc_xen.c
> > > @@ -23,6 +23,7 @@
> > >  #include <linux/err.h>
> > >  #include <linux/init.h>
> > >  #include <linux/types.h>
> > > +#include <linux/list.h>
> > >
> > >  #include <asm/io.h>
> > >  #include <asm/xen/hypervisor.h>
> > > @@ -30,47 +31,69 @@
> > >  #include <xen/xen.h>
> > >  #include <xen/interface/xen.h>
> > >  #include <xen/hvm.h>
> > > +#include <xen/grant_table.h>
> > >  #include <xen/page.h>
> > >  #include <xen/events.h>
> > >  #include <xen/interface/io/console.h>
> > >  #include <xen/hvc-console.h>
> > > +#include <xen/xenbus.h>
> > >
> > >  #include "hvc_console.h"
> > >
> > >  #define HVC_COOKIE   0x58656e /* "Xen" in hex */
> > >
> > > -static struct hvc_struct *hvc;
> > > -static int xencons_irq;
> > > +struct xencons_info {
> > > +     struct list_head list;
> > > +     struct xenbus_device *xbdev;
> > > +     struct xencons_interface *intf;
> > > +     unsigned int evtchn;
> > > +     struct hvc_struct *hvc;
> > > +     int irq;
> > > +     int vtermno;
> > > +     grant_ref_t gntref;
> > > +};
> > > +
> > > +static LIST_HEAD(xenconsoles);
> > > +static DEFINE_SPINLOCK(xencons_lock);
> > > +static struct xenbus_driver xencons_driver;
> > >
> > >  /* ------------------------------------------------------------------ */
> > >
> > > -static unsigned long console_pfn = ~0ul;
> > > -static unsigned int console_evtchn = ~0ul;
> > > -static struct xencons_interface *xencons_if = NULL;
> > > +static struct xencons_info *vtermno_to_xencons(int vtermno)
> > > +{
> > > +     struct xencons_info *entry, *ret = NULL;
> > > +
> > > +     if (list_empty(&xenconsoles))
> > > +                     return NULL;
> > >
> > > -static inline struct xencons_interface *xencons_interface(void)
> > > +     spin_lock(&xencons_lock);
> > 
> > This spinlock gets hit everytime something is typed or written on the
> > console right? Isn't there an spinlock already in the hvc driver...
> > 
> > Or are we protected by the vtermnos being checked for -1?
> 
> I think you are right: the spinlock is there to protect access to the
> list, so we can change list_for_each_entry to list_for_each_entry_safe
> in vtermno_to_xencons and we solve the problem. All the other spinlock
> acquisitions are done at console creation/destruction.

Right. So I think this will work as long as you mkae the call
to hvc_remove _before_ your remove entries from the xenconsoles.

That way hvc_remove will set vtermnos[x] to -1 and inhibit
any callers from calling into us.

This means you will need to redo the xencons_remove and xencons_free
a bit.. Hmm, there looks to be dead-lock there - let me send the
details.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:37:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:37:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqgC-0000j0-2j; Fri, 27 Jan 2012 18:37: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 1RqqgB-0000iU-CG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:37:43 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327689456!12141446!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28983 invoked from network); 27 Jan 2012 18:37:37 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 18:37: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
	q0RIbYDF010241
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 27 Jan 2012 13:37:34 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0RIbYll010239;
	Fri, 27 Jan 2012 13:37:34 -0500
Date: Fri, 27 Jan 2012 14:37:34 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127183734.GA10175@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +static int xencons_remove(struct xenbus_device *dev)
> +{
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +
> +	spin_lock(&xencons_lock);
> +	list_del(&info->list);
> +	spin_unlock(&xencons_lock);
> +	xencons_free(info);
>  	return 0;
>  }
.. snip..
>  static void __exit xen_hvc_fini(void)
>  {
> -	if (hvc)
> -		hvc_remove(hvc);
> +	struct xencons_info *entry, *next;
> +
> +	if (list_empty(&xenconsoles))
> +			return;
> +
> +	spin_lock(&xencons_lock);

You take a lock.
> +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> +		list_del(&entry->list);
> +		if (entry->xbdev)
> +			xencons_remove(entry->xbdev);

And then call xencons_remove which also takes the same lock.
> +		else {
> +			if (entry->irq > 0)
> +				unbind_from_irqhandler(entry->irq, NULL);
> +			if (entry->hvc);
> +				hvc_remove(entry->hvc);
> +			kfree(entry);
> +		}
> +	}
> +	spin_unlock(&xencons_lock);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:37:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:37:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqqgC-0000j0-2j; Fri, 27 Jan 2012 18:37: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 1RqqgB-0000iU-CG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:37:43 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327689456!12141446!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28983 invoked from network); 27 Jan 2012 18:37:37 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 27 Jan 2012 18:37: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
	q0RIbYDF010241
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Fri, 27 Jan 2012 13:37:34 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0RIbYll010239;
	Fri, 27 Jan 2012 13:37:34 -0500
Date: Fri, 27 Jan 2012 14:37:34 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127183734.GA10175@andromeda.dapyr.net>
References: <alpine.DEB.2.00.1201261233050.3196@kaball-desktop>
	<1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327581807-17276-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org,
	konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH 2/2] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +static int xencons_remove(struct xenbus_device *dev)
> +{
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +
> +	spin_lock(&xencons_lock);
> +	list_del(&info->list);
> +	spin_unlock(&xencons_lock);
> +	xencons_free(info);
>  	return 0;
>  }
.. snip..
>  static void __exit xen_hvc_fini(void)
>  {
> -	if (hvc)
> -		hvc_remove(hvc);
> +	struct xencons_info *entry, *next;
> +
> +	if (list_empty(&xenconsoles))
> +			return;
> +
> +	spin_lock(&xencons_lock);

You take a lock.
> +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> +		list_del(&entry->list);
> +		if (entry->xbdev)
> +			xencons_remove(entry->xbdev);

And then call xencons_remove which also takes the same lock.
> +		else {
> +			if (entry->irq > 0)
> +				unbind_from_irqhandler(entry->irq, NULL);
> +			if (entry->hvc);
> +				hvc_remove(entry->hvc);
> +			kfree(entry);
> +		}
> +	}
> +	spin_unlock(&xencons_lock);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqqZ-00019d-C8; Fri, 27 Jan 2012 18:48:27 +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 1RqqqX-00019T-Pz
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:48:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327690097!9085219!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMTEzNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12260 invoked from network); 27 Jan 2012 18:48:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 18:48:18 -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
	q0RIm3Id012835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 18:48:07 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
	q0RIm28P020527
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 18:48:03 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
	q0RIm1HH025045; Fri, 27 Jan 2012 12:48:01 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 10:48:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0DC18401B5; Fri, 27 Jan 2012 13:45:39 -0500 (EST)
Date: Fri, 27 Jan 2012 13:45:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127184538.GA18321@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
	<1327689097-12788-2-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327689097-12788-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F22F167.0050,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2 2/2] hvc_xen: implement multiconsole
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +static void xencons_disconnect_backend(struct xencons_info *info)
> +{
> +	if (info->irq > 0)
> +		unbind_from_irqhandler(info->irq, NULL);
> +	info->irq = 0;
> +	if (info->evtchn > 0)
> +		xenbus_free_evtchn(info->xbdev, info->evtchn);
> +	info->evtchn = 0;
> +	if (info->gntref > 0)
> +		gnttab_free_grant_references(info->gntref);
> +	info->gntref = 0;
> +	if (info->hvc != NULL)
> +		hvc_remove(info->hvc);
> +	info->hvc = NULL;
> +}
> +
> +static void xencons_free(struct xencons_info *info)
> +{
> +	xencons_disconnect_backend(info);
> +	free_page((unsigned long)info->intf);
> +	info->intf = NULL;
> +	info->vtermno = 0;
> +	kfree(info);
> +}
> +
> +static int xencons_remove(struct xenbus_device *dev)
> +{
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +

I would say put
	xencons_disconnect_backend(info)

here, that way it calls hvc_remove first, and then this would
delete an "not-called" anymore structure.

> +	spin_lock(&xencons_lock);
> +	list_del(&info->list);
> +	spin_unlock(&xencons_lock);
> +	xencons_free(info);

>  	return 0;
>  }
>

.. snip..
> +
> +static const struct xenbus_device_id xencons_ids[] = {
> +	{ "console" },
> +	{ "" }
> +};
> +
> +
>  static void __exit xen_hvc_fini(void)
>  {
> -	if (hvc)
> -		hvc_remove(hvc);
> +	struct xencons_info *entry, *next;
> +
> +	if (list_empty(&xenconsoles))
> +			return;
> +
> +	spin_lock(&xencons_lock);

Take that spin-lock out.

> +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> +		list_del(&entry->list);
> +		if (entry->xbdev)
> +			xencons_remove(entry->xbdev);

This guy deletes itself from the list..
> +		else {
> +			if (entry->irq > 0)
> +				unbind_from_irqhandler(entry->irq, NULL);
> +			if (entry->hvc);
> +				hvc_remove(entry->hvc);
> +			kfree(entry);

..but this one does not.  You could make xencons_remove just remove
itself from the list and nothing else. Then rename it to 'xencons_remove_itself' perhaps?

After that, introduce a new function 'xencons_delete' that would call
xecons_disconnect_backend, xencons_remove_itself, and xencons_free?

> +		}
> +	}
> +	spin_unlock(&xencons_lock);
>  }
>  
>  static int xen_cons_init(void)
> @@ -256,18 +566,31 @@ static int xen_cons_init(void)
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
>  	else {
> +		int r;
>  		ops = &domU_hvc_ops;
>  
> -		if (xen_pv_domain())
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> +		if (xen_hvm_domain())
> +			r = xen_hvm_console_init();
>  		else
> -			xen_hvm_console_init();
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
>  	}
>  
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
>  
> +static struct xenbus_driver xencons_driver = {

This needs to be wrapped in the new macro that Jan prepared.
DEFINE_XENBUS_DRIVER (73db144b58a32fc39733db6a7e1fe582072ad26a)

> +	.name = "xenconsole",
> +	.owner = THIS_MODULE,
> +	.ids = xencons_ids,
> +	.probe = xencons_probe,
> +	.remove = xencons_remove,
> +	.resume = xencons_resume,
> +	.otherend_changed = xencons_backend_changed,
> +};
> +
>  module_init(xen_hvc_init);
>  module_exit(xen_hvc_fini);
>  console_initcall(xen_cons_init);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:48:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqqZ-00019d-C8; Fri, 27 Jan 2012 18:48:27 +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 1RqqqX-00019T-Pz
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:48:25 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327690097!9085219!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMTEzNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12260 invoked from network); 27 Jan 2012 18:48:18 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 18:48:18 -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
	q0RIm3Id012835
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 18:48:07 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
	q0RIm28P020527
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 18:48:03 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
	q0RIm1HH025045; Fri, 27 Jan 2012 12:48:01 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 10:48:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 0DC18401B5; Fri, 27 Jan 2012 13:45:39 -0500 (EST)
Date: Fri, 27 Jan 2012 13:45:39 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127184538.GA18321@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
	<1327689097-12788-2-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327689097-12788-2-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090202.4F22F167.0050,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2 2/2] hvc_xen: implement multiconsole
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> +static void xencons_disconnect_backend(struct xencons_info *info)
> +{
> +	if (info->irq > 0)
> +		unbind_from_irqhandler(info->irq, NULL);
> +	info->irq = 0;
> +	if (info->evtchn > 0)
> +		xenbus_free_evtchn(info->xbdev, info->evtchn);
> +	info->evtchn = 0;
> +	if (info->gntref > 0)
> +		gnttab_free_grant_references(info->gntref);
> +	info->gntref = 0;
> +	if (info->hvc != NULL)
> +		hvc_remove(info->hvc);
> +	info->hvc = NULL;
> +}
> +
> +static void xencons_free(struct xencons_info *info)
> +{
> +	xencons_disconnect_backend(info);
> +	free_page((unsigned long)info->intf);
> +	info->intf = NULL;
> +	info->vtermno = 0;
> +	kfree(info);
> +}
> +
> +static int xencons_remove(struct xenbus_device *dev)
> +{
> +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> +

I would say put
	xencons_disconnect_backend(info)

here, that way it calls hvc_remove first, and then this would
delete an "not-called" anymore structure.

> +	spin_lock(&xencons_lock);
> +	list_del(&info->list);
> +	spin_unlock(&xencons_lock);
> +	xencons_free(info);

>  	return 0;
>  }
>

.. snip..
> +
> +static const struct xenbus_device_id xencons_ids[] = {
> +	{ "console" },
> +	{ "" }
> +};
> +
> +
>  static void __exit xen_hvc_fini(void)
>  {
> -	if (hvc)
> -		hvc_remove(hvc);
> +	struct xencons_info *entry, *next;
> +
> +	if (list_empty(&xenconsoles))
> +			return;
> +
> +	spin_lock(&xencons_lock);

Take that spin-lock out.

> +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> +		list_del(&entry->list);
> +		if (entry->xbdev)
> +			xencons_remove(entry->xbdev);

This guy deletes itself from the list..
> +		else {
> +			if (entry->irq > 0)
> +				unbind_from_irqhandler(entry->irq, NULL);
> +			if (entry->hvc);
> +				hvc_remove(entry->hvc);
> +			kfree(entry);

..but this one does not.  You could make xencons_remove just remove
itself from the list and nothing else. Then rename it to 'xencons_remove_itself' perhaps?

After that, introduce a new function 'xencons_delete' that would call
xecons_disconnect_backend, xencons_remove_itself, and xencons_free?

> +		}
> +	}
> +	spin_unlock(&xencons_lock);
>  }
>  
>  static int xen_cons_init(void)
> @@ -256,18 +566,31 @@ static int xen_cons_init(void)
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
>  	else {
> +		int r;
>  		ops = &domU_hvc_ops;
>  
> -		if (xen_pv_domain())
> -			console_evtchn = xen_start_info->console.domU.evtchn;
> +		if (xen_hvm_domain())
> +			r = xen_hvm_console_init();
>  		else
> -			xen_hvm_console_init();
> +			r = xen_pv_console_init();
> +		if (r < 0)
> +			return r;
>  	}
>  
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
>  
> +static struct xenbus_driver xencons_driver = {

This needs to be wrapped in the new macro that Jan prepared.
DEFINE_XENBUS_DRIVER (73db144b58a32fc39733db6a7e1fe582072ad26a)

> +	.name = "xenconsole",
> +	.owner = THIS_MODULE,
> +	.ids = xencons_ids,
> +	.probe = xencons_probe,
> +	.remove = xencons_remove,
> +	.resume = xencons_resume,
> +	.otherend_changed = xencons_backend_changed,
> +};
> +
>  module_init(xen_hvc_init);
>  module_exit(xen_hvc_fini);
>  console_initcall(xen_cons_init);
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:48:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqqZ-00019k-OM; Fri, 27 Jan 2012 18:48:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqqqY-00019U-H2
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:48:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327690098!12869507!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA5NTA4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17253 invoked from network); 27 Jan 2012 18:48:20 -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; 27 Jan 2012 18:48:20 -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
	q0RImERG021836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 18:48:15 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
	q0RImDYL001478
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 18:48:14 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
	q0RImDAq020638; Fri, 27 Jan 2012 12:48:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 10:48:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 97134401B5; Fri, 27 Jan 2012 13:45:48 -0500 (EST)
Date: Fri, 27 Jan 2012 13:45:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127184548.GB18321@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
	<1327689097-12788-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327689097-12788-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F22F16F.00A2,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 06:31:36PM +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

applied.

> ---
>  drivers/tty/hvc/hvc_xen.c          |   84 +++++++++++++++++++++++++++++-------
>  include/xen/interface/hvm/params.h |    6 ++-
>  2 files changed, 73 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 52fdf60..d5000aa 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -24,9 +24,12 @@
>  #include <linux/init.h>
>  #include <linux/types.h>
>  
> +#include <asm/io.h>
>  #include <asm/xen/hypervisor.h>
>  
>  #include <xen/xen.h>
> +#include <xen/interface/xen.h>
> +#include <xen/hvm.h>
>  #include <xen/page.h>
>  #include <xen/events.h>
>  #include <xen/interface/io/console.h>
> @@ -42,9 +45,13 @@ static int xencons_irq;
>  /* ------------------------------------------------------------------ */
>  
>  static unsigned long console_pfn = ~0ul;
> +static unsigned int console_evtchn = ~0ul;
> +static struct xencons_interface *xencons_if = NULL;
>  
>  static inline struct xencons_interface *xencons_interface(void)
>  {
> +	if (xencons_if != NULL)
> +		return xencons_if;
>  	if (console_pfn == ~0ul)
>  		return mfn_to_virt(xen_start_info->console.domU.mfn);
>  	else
> @@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
>  static inline void notify_daemon(void)
>  {
>  	/* Use evtchn: this is called early, before irq is set up. */
> -	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> +	if (console_evtchn == ~0ul)
> +		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> +	else
> +		notify_remote_via_evtchn(console_evtchn);
>  }
>  
>  static int __write_console(const char *data, int len)
> @@ -157,28 +167,63 @@ static struct hv_ops dom0_hvc_ops = {
>  	.notifier_hangup = notifier_hangup_irq,
>  };
>  
> +static int xen_hvm_console_init(void)
> +{
> +	int r;
> +	uint64_t v = 0;
> +	unsigned long mfn;
> +
> +	if (!xen_hvm_domain())
> +		return -ENODEV;
> +
> +	if (xencons_if != NULL)
> +		return -EBUSY;
> +
> +	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> +	if (r < 0)
> +		return -ENODEV;
> +	console_evtchn = v;
> +	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> +	if (r < 0)
> +		return -ENODEV;
> +	mfn = v;
> +	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	if (xencons_if == NULL)
> +		return -ENODEV;
> +
> +	return 0;
> +}
> +
>  static int __init xen_hvc_init(void)
>  {
>  	struct hvc_struct *hp;
>  	struct hv_ops *ops;
> +	int r;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return -ENODEV;
>  
>  	if (xen_initial_domain()) {
>  		ops = &dom0_hvc_ops;
>  		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
>  	} else {
> -		if (!xen_start_info->console.domU.evtchn)
> -			return -ENODEV;
> -
>  		ops = &domU_hvc_ops;
> -		xencons_irq = bind_evtchn_to_irq(xen_start_info->console.domU.evtchn);
> +		if (xen_pv_domain()) {
> +			if (!xen_start_info->console.domU.evtchn)
> +				return -ENODEV;
> +			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> +			console_evtchn = xen_start_info->console.domU.evtchn;
> +		} else {
> +			r = xen_hvm_console_init();
> +			if (r < 0)
> +				return r;
> +		}
> +		xencons_irq = bind_evtchn_to_irq(console_evtchn);
> +		if (xencons_irq < 0)
> +			xencons_irq = 0; /* NO_IRQ */
> +		else
> +			irq_set_noprobe(xencons_irq);
>  	}
> -	if (xencons_irq < 0)
> -		xencons_irq = 0; /* NO_IRQ */
> -	else
> -		irq_set_noprobe(xencons_irq);
>  
>  	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
>  	if (IS_ERR(hp))
> @@ -186,15 +231,13 @@ static int __init xen_hvc_init(void)
>  
>  	hvc = hp;
>  
> -	console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> -
>  	return 0;
>  }
>  
>  void xen_console_resume(void)
>  {
>  	if (xencons_irq)
> -		rebind_evtchn_irq(xen_start_info->console.domU.evtchn, xencons_irq);
> +		rebind_evtchn_irq(console_evtchn, xencons_irq);
>  }
>  
>  static void __exit xen_hvc_fini(void)
> @@ -205,16 +248,22 @@ static void __exit xen_hvc_fini(void)
>  
>  static int xen_cons_init(void)
>  {
> -	struct hv_ops *ops;
> +	const struct hv_ops *ops;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return 0;
>  
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
> -	else
> +	else {
>  		ops = &domU_hvc_ops;
>  
> +		if (xen_pv_domain())
> +			console_evtchn = xen_start_info->console.domU.evtchn;
> +		else
> +			xen_hvm_console_init();
> +	}
> +
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
> @@ -230,6 +279,9 @@ static void xenboot_write_console(struct console *console, const char *string,
>  	unsigned int linelen, off = 0;
>  	const char *pos;
>  
> +	if (!xen_pv_domain())
> +		return;
> +
>  	dom0_write_console(0, string, len);
>  
>  	if (xen_initial_domain())
> diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
> index 1888d8c..1b4f923 100644
> --- a/include/xen/interface/hvm/params.h
> +++ b/include/xen/interface/hvm/params.h
> @@ -90,6 +90,10 @@
>  /* Boolean: Enable aligning all periodic vpts to reduce interrupts */
>  #define HVM_PARAM_VPT_ALIGN    16
>  
> -#define HVM_NR_PARAMS          17
> +/* Console debug shared memory ring and event channel */
> +#define HVM_PARAM_CONSOLE_PFN    17
> +#define HVM_PARAM_CONSOLE_EVTCHN 18
> +
> +#define HVM_NR_PARAMS          19
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> -- 
> 1.7.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 Fri Jan 27 18:48:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18: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 1RqqqZ-00019k-OM; Fri, 27 Jan 2012 18:48:27 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqqqY-00019U-H2
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:48:26 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327690098!12869507!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTA5NTA4\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17253 invoked from network); 27 Jan 2012 18:48:20 -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; 27 Jan 2012 18:48:20 -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
	q0RImERG021836
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 18:48:15 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
	q0RImDYL001478
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 18:48:14 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
	q0RImDAq020638; Fri, 27 Jan 2012 12:48:13 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 10:48:13 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 97134401B5; Fri, 27 Jan 2012 13:45:48 -0500 (EST)
Date: Fri, 27 Jan 2012 13:45:48 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120127184548.GB18321@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
	<1327689097-12788-1-git-send-email-stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327689097-12788-1-git-send-email-stefano.stabellini@eu.citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090201.4F22F16F.00A2,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH v2 1/2] hvc_xen: support PV on HVM consoles
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 06:31:36PM +0000, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

applied.

> ---
>  drivers/tty/hvc/hvc_xen.c          |   84 +++++++++++++++++++++++++++++-------
>  include/xen/interface/hvm/params.h |    6 ++-
>  2 files changed, 73 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
> index 52fdf60..d5000aa 100644
> --- a/drivers/tty/hvc/hvc_xen.c
> +++ b/drivers/tty/hvc/hvc_xen.c
> @@ -24,9 +24,12 @@
>  #include <linux/init.h>
>  #include <linux/types.h>
>  
> +#include <asm/io.h>
>  #include <asm/xen/hypervisor.h>
>  
>  #include <xen/xen.h>
> +#include <xen/interface/xen.h>
> +#include <xen/hvm.h>
>  #include <xen/page.h>
>  #include <xen/events.h>
>  #include <xen/interface/io/console.h>
> @@ -42,9 +45,13 @@ static int xencons_irq;
>  /* ------------------------------------------------------------------ */
>  
>  static unsigned long console_pfn = ~0ul;
> +static unsigned int console_evtchn = ~0ul;
> +static struct xencons_interface *xencons_if = NULL;
>  
>  static inline struct xencons_interface *xencons_interface(void)
>  {
> +	if (xencons_if != NULL)
> +		return xencons_if;
>  	if (console_pfn == ~0ul)
>  		return mfn_to_virt(xen_start_info->console.domU.mfn);
>  	else
> @@ -54,7 +61,10 @@ static inline struct xencons_interface *xencons_interface(void)
>  static inline void notify_daemon(void)
>  {
>  	/* Use evtchn: this is called early, before irq is set up. */
> -	notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> +	if (console_evtchn == ~0ul)
> +		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
> +	else
> +		notify_remote_via_evtchn(console_evtchn);
>  }
>  
>  static int __write_console(const char *data, int len)
> @@ -157,28 +167,63 @@ static struct hv_ops dom0_hvc_ops = {
>  	.notifier_hangup = notifier_hangup_irq,
>  };
>  
> +static int xen_hvm_console_init(void)
> +{
> +	int r;
> +	uint64_t v = 0;
> +	unsigned long mfn;
> +
> +	if (!xen_hvm_domain())
> +		return -ENODEV;
> +
> +	if (xencons_if != NULL)
> +		return -EBUSY;
> +
> +	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
> +	if (r < 0)
> +		return -ENODEV;
> +	console_evtchn = v;
> +	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
> +	if (r < 0)
> +		return -ENODEV;
> +	mfn = v;
> +	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
> +	if (xencons_if == NULL)
> +		return -ENODEV;
> +
> +	return 0;
> +}
> +
>  static int __init xen_hvc_init(void)
>  {
>  	struct hvc_struct *hp;
>  	struct hv_ops *ops;
> +	int r;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return -ENODEV;
>  
>  	if (xen_initial_domain()) {
>  		ops = &dom0_hvc_ops;
>  		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
>  	} else {
> -		if (!xen_start_info->console.domU.evtchn)
> -			return -ENODEV;
> -
>  		ops = &domU_hvc_ops;
> -		xencons_irq = bind_evtchn_to_irq(xen_start_info->console.domU.evtchn);
> +		if (xen_pv_domain()) {
> +			if (!xen_start_info->console.domU.evtchn)
> +				return -ENODEV;
> +			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> +			console_evtchn = xen_start_info->console.domU.evtchn;
> +		} else {
> +			r = xen_hvm_console_init();
> +			if (r < 0)
> +				return r;
> +		}
> +		xencons_irq = bind_evtchn_to_irq(console_evtchn);
> +		if (xencons_irq < 0)
> +			xencons_irq = 0; /* NO_IRQ */
> +		else
> +			irq_set_noprobe(xencons_irq);
>  	}
> -	if (xencons_irq < 0)
> -		xencons_irq = 0; /* NO_IRQ */
> -	else
> -		irq_set_noprobe(xencons_irq);
>  
>  	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
>  	if (IS_ERR(hp))
> @@ -186,15 +231,13 @@ static int __init xen_hvc_init(void)
>  
>  	hvc = hp;
>  
> -	console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
> -
>  	return 0;
>  }
>  
>  void xen_console_resume(void)
>  {
>  	if (xencons_irq)
> -		rebind_evtchn_irq(xen_start_info->console.domU.evtchn, xencons_irq);
> +		rebind_evtchn_irq(console_evtchn, xencons_irq);
>  }
>  
>  static void __exit xen_hvc_fini(void)
> @@ -205,16 +248,22 @@ static void __exit xen_hvc_fini(void)
>  
>  static int xen_cons_init(void)
>  {
> -	struct hv_ops *ops;
> +	const struct hv_ops *ops;
>  
> -	if (!xen_pv_domain())
> +	if (!xen_domain())
>  		return 0;
>  
>  	if (xen_initial_domain())
>  		ops = &dom0_hvc_ops;
> -	else
> +	else {
>  		ops = &domU_hvc_ops;
>  
> +		if (xen_pv_domain())
> +			console_evtchn = xen_start_info->console.domU.evtchn;
> +		else
> +			xen_hvm_console_init();
> +	}
> +
>  	hvc_instantiate(HVC_COOKIE, 0, ops);
>  	return 0;
>  }
> @@ -230,6 +279,9 @@ static void xenboot_write_console(struct console *console, const char *string,
>  	unsigned int linelen, off = 0;
>  	const char *pos;
>  
> +	if (!xen_pv_domain())
> +		return;
> +
>  	dom0_write_console(0, string, len);
>  
>  	if (xen_initial_domain())
> diff --git a/include/xen/interface/hvm/params.h b/include/xen/interface/hvm/params.h
> index 1888d8c..1b4f923 100644
> --- a/include/xen/interface/hvm/params.h
> +++ b/include/xen/interface/hvm/params.h
> @@ -90,6 +90,10 @@
>  /* Boolean: Enable aligning all periodic vpts to reduce interrupts */
>  #define HVM_PARAM_VPT_ALIGN    16
>  
> -#define HVM_NR_PARAMS          17
> +/* Console debug shared memory ring and event channel */
> +#define HVM_PARAM_CONSOLE_PFN    17
> +#define HVM_PARAM_CONSOLE_EVTCHN 18
> +
> +#define HVM_NR_PARAMS          19
>  
>  #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */
> -- 
> 1.7.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 Fri Jan 27 18:58:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:58:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqr0U-0001op-SC; Fri, 27 Jan 2012 18:58:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen.list@daevel.fr>) id 1Rqr0S-0001of-O5
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:58:40 +0000
X-Env-Sender: xen.list@daevel.fr
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327690714!12824316!1
X-Originating-IP: [178.32.94.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20113 invoked from network); 27 Jan 2012 18:58:34 -0000
Received: from licorne.daevel.fr (HELO licorne.daevel.fr) (178.32.94.222)
	by server-11.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 18:58:34 -0000
Received: from luuna.daevel.fr ([82.67.37.138] helo=[192.168.1.50])
	by licorne.daevel.fr with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <xen.list@daevel.fr>) id 1Rqr0M-00057a-4h
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:58:34 +0100
Message-ID: <4F22F403.2030104@daevel.fr>
Date: Fri, 27 Jan 2012 19:59:15 +0100
From: "Olivier B." <xen.list@daevel.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Linux 3.2.2 & btrfs, on a DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I switch one of my DomU to a 3.2.2 linux kernel (renamed in 2.6.42.2, for compatibility with some software), and I have some problem with btrfs.

I don't know if it's a btrfs or xen problem, the call trace is :

[56580.320024] INFO: rcu_sched detected stall on CPU 0 (t=15000 jiffies)
[56580.320024] Pid: 11505, comm: btrfs-delayed-m Tainted: G         C   2.6.42.2-dae-xen #2
[56580.320024] Call Trace:
[56580.320024]  <IRQ>  [<ffffffff81084719>] ? __rcu_pending+0x82/0x337
[56580.320024]  [<ffffffff810678bd>] ? tick_nohz_handler+0xbe/0xbe
[56580.320024]  [<ffffffff81084ccc>] ? rcu_check_callbacks+0x7e/0xae
[56580.320024]  [<ffffffff81050d44>] ? update_process_times+0x31/0x63
[56580.320024]  [<ffffffff8106791f>] ? tick_sched_timer+0x62/0x7e
[56580.320024]  [<ffffffff8105e8b4>] ? __run_hrtimer.isra.28+0x52/0xaa
[56580.320024]  [<ffffffff8105ee8c>] ? hrtimer_interrupt+0xd5/0x1a1
[56580.320024]  [<ffffffff8100537e>] ? xen_timer_interrupt+0x28/0x159
[56580.320024]  [<ffffffff81080097>] ? handle_irq_event_percpu+0x24/0x11c
[56580.320024]  [<ffffffff810824b1>] ? handle_percpu_irq+0x35/0x4c
[56580.320024]  [<ffffffff811cbe90>] ? __xen_evtchn_do_upcall+0x154/0x1eb
[56580.320024]  [<ffffffff8100525c>] ? xen_force_evtchn_callback+0x9/0xa
[56580.320024]  [<ffffffff811cd490>] ? xen_evtchn_do_upcall+0x22/0x32
[56580.320024]  [<ffffffff812f863e>] ? xen_do_hypervisor_callback+0x1e/0x30
[56580.320024]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[56580.320024]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[56580.320024]  [<ffffffff811cc7d5>] ? xen_poll_irq_timeout+0x38/0x44
[56580.320024]  [<ffffffff812ee21f>] ? xen_spin_lock_slow+0x86/0xdf
[56580.320024]  [<ffffffff8100688a>] ? __xen_spin_lock+0x32/0x3b
[56580.320024]  [<ffffffff8106bd6a>] ? do_raw_spin_lock+0x5/0x8
[56580.320024]  [<ffffffffa002badd>] ? find_free_extent.constprop.77+0x495/0x94b [btrfs]
[56580.320024]  [<ffffffffa00689fe>] ? btrfs_add_delayed_tree_ref+0x77/0x120 [btrfs]
[56580.320024]  [<ffffffffa002e61b>] ? btrfs_reserve_extent+0xa4/0x148 [btrfs]
[56580.320024]  [<ffffffffa002eadb>] ? btrfs_alloc_free_block+0x15d/0x283 [btrfs]
[56580.320024]  [<ffffffff81005842>] ? check_events+0x12/0x20
[56580.320024]  [<ffffffffa0021f3a>] ? __btrfs_cow_block+0x102/0x32c [btrfs]
[56580.320024]  [<ffffffffa0022257>] ? btrfs_cow_block+0xf3/0x102 [btrfs]
[56580.320024]  [<ffffffffa0024c84>] ? btrfs_search_slot+0x225/0x64e [btrfs]
[56580.320024]  [<ffffffffa00285f2>] ? lookup_inline_extent_backref+0xa8/0x360 [btrfs]
[56580.320024]  [<ffffffffa002a35c>] ? __btrfs_free_extent+0xcb/0x5c8 [btrfs]
[56580.320024]  [<ffffffff812f1dac>] ? __slab_free+0xd6/0x206
[56580.320024]  [<ffffffff810b9c65>] ? arch_local_irq_restore+0x7/0x8
[56580.320024]  [<ffffffffa002d87e>] ? run_clustered_refs+0x65f/0x6a9 [btrfs]
[56580.320024]  [<ffffffff81177fe4>] ? rb_next+0x39/0x3f
[56580.320024]  [<ffffffffa002d991>] ? btrfs_run_delayed_refs+0xc9/0x185 [btrfs]
[56580.320024]  [<ffffffff812ee18a>] ? xen_spin_unlock_slow+0x4d/0x5c
[56580.320024]  [<ffffffffa003b13a>] ? __btrfs_end_transaction+0x90/0x1dd [btrfs]
[56580.320024]  [<ffffffffa006ff08>] ? btrfs_async_run_delayed_node_done+0xf8/0x156 [btrfs]
[56580.320024]  [<ffffffffa005a150>] ? worker_loop+0x16a/0x45a [btrfs]
[56580.320024]  [<ffffffffa0059fe6>] ? btrfs_queue_worker+0x279/0x279 [btrfs]
[56580.320024]  [<ffffffff8105bbba>] ? kthread+0x76/0x7e
[56580.320024]  [<ffffffff812f84f4>] ? kernel_thread_helper+0x4/0x10
[56580.320024]  [<ffffffff812f65b3>] ? int_ret_from_sys_call+0x7/0x1b
[56580.320024]  [<ffffffff812f5cbc>] ? retint_restore_args+0x5/0x6
[56580.320024]  [<ffffffff812f84f0>] ? gs_change+0x13/0x13

I had the problem with 3.2, 3.2.1, then 3.2.2. With and without the renaming to 2.6.42.x.

The Xen version is 4.0.1 (from Debian amd64), and the Dom0 kernel is a 3.1.0 (also from Debian).

Thanks for any advice,

Olivier B.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 18:58:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 18:58:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqr0U-0001op-SC; Fri, 27 Jan 2012 18:58:42 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <xen.list@daevel.fr>) id 1Rqr0S-0001of-O5
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 18:58:40 +0000
X-Env-Sender: xen.list@daevel.fr
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327690714!12824316!1
X-Originating-IP: [178.32.94.222]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20113 invoked from network); 27 Jan 2012 18:58:34 -0000
Received: from licorne.daevel.fr (HELO licorne.daevel.fr) (178.32.94.222)
	by server-11.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 18:58:34 -0000
Received: from luuna.daevel.fr ([82.67.37.138] helo=[192.168.1.50])
	by licorne.daevel.fr with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.72) (envelope-from <xen.list@daevel.fr>) id 1Rqr0M-00057a-4h
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:58:34 +0100
Message-ID: <4F22F403.2030104@daevel.fr>
Date: Fri, 27 Jan 2012 19:59:15 +0100
From: "Olivier B." <xen.list@daevel.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0
MIME-Version: 1.0
To: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Linux 3.2.2 & btrfs, on a DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I switch one of my DomU to a 3.2.2 linux kernel (renamed in 2.6.42.2, for compatibility with some software), and I have some problem with btrfs.

I don't know if it's a btrfs or xen problem, the call trace is :

[56580.320024] INFO: rcu_sched detected stall on CPU 0 (t=15000 jiffies)
[56580.320024] Pid: 11505, comm: btrfs-delayed-m Tainted: G         C   2.6.42.2-dae-xen #2
[56580.320024] Call Trace:
[56580.320024]  <IRQ>  [<ffffffff81084719>] ? __rcu_pending+0x82/0x337
[56580.320024]  [<ffffffff810678bd>] ? tick_nohz_handler+0xbe/0xbe
[56580.320024]  [<ffffffff81084ccc>] ? rcu_check_callbacks+0x7e/0xae
[56580.320024]  [<ffffffff81050d44>] ? update_process_times+0x31/0x63
[56580.320024]  [<ffffffff8106791f>] ? tick_sched_timer+0x62/0x7e
[56580.320024]  [<ffffffff8105e8b4>] ? __run_hrtimer.isra.28+0x52/0xaa
[56580.320024]  [<ffffffff8105ee8c>] ? hrtimer_interrupt+0xd5/0x1a1
[56580.320024]  [<ffffffff8100537e>] ? xen_timer_interrupt+0x28/0x159
[56580.320024]  [<ffffffff81080097>] ? handle_irq_event_percpu+0x24/0x11c
[56580.320024]  [<ffffffff810824b1>] ? handle_percpu_irq+0x35/0x4c
[56580.320024]  [<ffffffff811cbe90>] ? __xen_evtchn_do_upcall+0x154/0x1eb
[56580.320024]  [<ffffffff8100525c>] ? xen_force_evtchn_callback+0x9/0xa
[56580.320024]  [<ffffffff811cd490>] ? xen_evtchn_do_upcall+0x22/0x32
[56580.320024]  [<ffffffff812f863e>] ? xen_do_hypervisor_callback+0x1e/0x30
[56580.320024]  <EOI>  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[56580.320024]  [<ffffffff810013aa>] ? hypercall_page+0x3aa/0x1000
[56580.320024]  [<ffffffff811cc7d5>] ? xen_poll_irq_timeout+0x38/0x44
[56580.320024]  [<ffffffff812ee21f>] ? xen_spin_lock_slow+0x86/0xdf
[56580.320024]  [<ffffffff8100688a>] ? __xen_spin_lock+0x32/0x3b
[56580.320024]  [<ffffffff8106bd6a>] ? do_raw_spin_lock+0x5/0x8
[56580.320024]  [<ffffffffa002badd>] ? find_free_extent.constprop.77+0x495/0x94b [btrfs]
[56580.320024]  [<ffffffffa00689fe>] ? btrfs_add_delayed_tree_ref+0x77/0x120 [btrfs]
[56580.320024]  [<ffffffffa002e61b>] ? btrfs_reserve_extent+0xa4/0x148 [btrfs]
[56580.320024]  [<ffffffffa002eadb>] ? btrfs_alloc_free_block+0x15d/0x283 [btrfs]
[56580.320024]  [<ffffffff81005842>] ? check_events+0x12/0x20
[56580.320024]  [<ffffffffa0021f3a>] ? __btrfs_cow_block+0x102/0x32c [btrfs]
[56580.320024]  [<ffffffffa0022257>] ? btrfs_cow_block+0xf3/0x102 [btrfs]
[56580.320024]  [<ffffffffa0024c84>] ? btrfs_search_slot+0x225/0x64e [btrfs]
[56580.320024]  [<ffffffffa00285f2>] ? lookup_inline_extent_backref+0xa8/0x360 [btrfs]
[56580.320024]  [<ffffffffa002a35c>] ? __btrfs_free_extent+0xcb/0x5c8 [btrfs]
[56580.320024]  [<ffffffff812f1dac>] ? __slab_free+0xd6/0x206
[56580.320024]  [<ffffffff810b9c65>] ? arch_local_irq_restore+0x7/0x8
[56580.320024]  [<ffffffffa002d87e>] ? run_clustered_refs+0x65f/0x6a9 [btrfs]
[56580.320024]  [<ffffffff81177fe4>] ? rb_next+0x39/0x3f
[56580.320024]  [<ffffffffa002d991>] ? btrfs_run_delayed_refs+0xc9/0x185 [btrfs]
[56580.320024]  [<ffffffff812ee18a>] ? xen_spin_unlock_slow+0x4d/0x5c
[56580.320024]  [<ffffffffa003b13a>] ? __btrfs_end_transaction+0x90/0x1dd [btrfs]
[56580.320024]  [<ffffffffa006ff08>] ? btrfs_async_run_delayed_node_done+0xf8/0x156 [btrfs]
[56580.320024]  [<ffffffffa005a150>] ? worker_loop+0x16a/0x45a [btrfs]
[56580.320024]  [<ffffffffa0059fe6>] ? btrfs_queue_worker+0x279/0x279 [btrfs]
[56580.320024]  [<ffffffff8105bbba>] ? kthread+0x76/0x7e
[56580.320024]  [<ffffffff812f84f4>] ? kernel_thread_helper+0x4/0x10
[56580.320024]  [<ffffffff812f65b3>] ? int_ret_from_sys_call+0x7/0x1b
[56580.320024]  [<ffffffff812f5cbc>] ? retint_restore_args+0x5/0x6
[56580.320024]  [<ffffffff812f84f0>] ? gs_change+0x13/0x13

I had the problem with 3.2, 3.2.1, then 3.2.2. With and without the renaming to 2.6.42.x.

The Xen version is 4.0.1 (from Debian amd64), and the Dom0 kernel is a 3.1.0 (also from Debian).

Thanks for any advice,

Olivier B.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 19:04:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19: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 1Rqr5S-0001zU-K8; Fri, 27 Jan 2012 19:03:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqr5R-0001zJ-Vx
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:03:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327691023!12858635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29226 invoked from network); 27 Jan 2012 19:03:44 -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;
	27 Jan 2012 19:03:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10340161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 19:03: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, 27 Jan 2012 19:03: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
	1Rqr5L-0005nk-JJ; Fri, 27 Jan 2012 19:03:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqr5L-0006HH-IJ;
	Fri, 27 Jan 2012 19:03:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.62735.551770.824899@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 19:03:43 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <34cf64e8b3f099a556b6.1327682116@probook.site>
References: <34cf64e8b3f099a556b6.1327682116@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: make file_op largefile aware
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH] xenpaging: make file_op largefile aware"):
> xenpaging: make file_op largefile aware

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 Jan 27 19:04:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19: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 1Rqr5S-0001zU-K8; Fri, 27 Jan 2012 19:03:50 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqr5R-0001zJ-Vx
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:03:50 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327691023!12858635!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29226 invoked from network); 27 Jan 2012 19:03:44 -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;
	27 Jan 2012 19:03:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10340161"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 19:03: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, 27 Jan 2012 19:03: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
	1Rqr5L-0005nk-JJ; Fri, 27 Jan 2012 19:03:43 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqr5L-0006HH-IJ;
	Fri, 27 Jan 2012 19:03:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.62735.551770.824899@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 19:03:43 +0000
To: Olaf Hering <olaf@aepfle.de>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <34cf64e8b3f099a556b6.1327682116@probook.site>
References: <34cf64e8b3f099a556b6.1327682116@probook.site>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: make file_op largefile aware
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Olaf Hering writes ("[Xen-devel] [PATCH] xenpaging: make file_op largefile aware"):
> xenpaging: make file_op largefile aware

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 Jan 27 19:04:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19:04:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqr5d-00020k-6o; Fri, 27 Jan 2012 19:04:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rqr5b-000204-SF
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:04:00 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327691032!12895416!1
X-Originating-IP: [64.78.148.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32063 invoked from network); 27 Jan 2012 19:03:53 -0000
Received: from host212.adamapps.net (HELO host212.adamapps.net) (64.78.148.212)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 19:03:53 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host212.adamapps.net (8.13.8/8.13.8) with ESMTP id q0RJ3ASb023849;
	Fri, 27 Jan 2012 14:03:11 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 27 Jan 2012 14:02:57 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: Aczbi5pS4UQEljXgRDKydrkry+FyIQANK/MAAFlvJWA=
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
From: <djmagee@mageenet.net>
To: "James Harper" <james.harper@bendigoit.com.au>, <lta@akr.fm>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] GPLPV and 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 checked, and no devices are sharing IRQs.  I'll try the
windows2003/ndis5 drivers and see if that makes a difference.  Of
course, the base image for my win7 vms seems to have gotten corrupted,
so I'll have to build a new one.

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of James Harper
> Sent: Wednesday, January 25, 2012 7:23 PM
> To: djmagee@mageenet.net; lta@akr.fm
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] GPLPV and pci passthrough
> 
> >
> > James,
> > 	At least one other person (Lta, included in this message) and I
> have
> > had problems using passthrough pci devices and your GPLPV drivers at
> the
> > same time.  My symptoms are that SMB connections are totally
> unreliable
> > (however, downloading over http seems to work well enough).
> > For example, if I start a video or audio file, playing from the
> network, it will
> > play the first few seconds fine, then the connection drops out.
> > I can confirm that the problems don't exist when not passing through
> any
> > devices.
> >
> > 	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU
> with
> > an ATI 4770, USB controller, and ICE1712 based pci sound card passed
> > through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.
> >
> > 	I tried the -debug drivers, and I see a ton of output in qemu
> log,
> > however, all that output seems to be at initialization.  I do not
see
> any
> > additional output from your drivers after boot, including when I'm
> > experiencing problems.
> >
> > 	I took a quick look at tcpdump output and it does seem the guest
> is
> > ACKing the packets as they come in, so my first guess is that
they're
> getting
> > lost somewhere between the driver and the OS network stack.
> >
> > 	I've never set up a build environment for these drivers so I
> haven't
> > tried adding any extra debug output.  Have you looked into the (or a
> similar)
> > problem before, or have a more verbose debug copy of the net driver
> you've
> > used to diagnose similar problems before?
> >
> > 	I guess the real question is, do you have any idea where we
> should
> > start looking?
> >
> 
> I'd be first looking at interrupt sharing. Maybe GPLPV doesn't like
> sharing interrupts with anything?
> 
> Have a look in device manager and set the view as "Resources by type"
> and see if anything is sharing an interrupt with the "Xen PCI Device
> Driver".
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 27 19:04:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19:04:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqr5d-00020k-6o; Fri, 27 Jan 2012 19:04:01 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rqr5b-000204-SF
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:04:00 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327691032!12895416!1
X-Originating-IP: [64.78.148.212]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32063 invoked from network); 27 Jan 2012 19:03:53 -0000
Received: from host212.adamapps.net (HELO host212.adamapps.net) (64.78.148.212)
	by server-9.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 19:03:53 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host212.adamapps.net (8.13.8/8.13.8) with ESMTP id q0RJ3ASb023849;
	Fri, 27 Jan 2012 14:03:11 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Fri, 27 Jan 2012 14:02:57 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: Aczbi5pS4UQEljXgRDKydrkry+FyIQANK/MAAFlvJWA=
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
From: <djmagee@mageenet.net>
To: "James Harper" <james.harper@bendigoit.com.au>, <lta@akr.fm>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] GPLPV and 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 checked, and no devices are sharing IRQs.  I'll try the
windows2003/ndis5 drivers and see if that makes a difference.  Of
course, the base image for my win7 vms seems to have gotten corrupted,
so I'll have to build a new one.

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of James Harper
> Sent: Wednesday, January 25, 2012 7:23 PM
> To: djmagee@mageenet.net; lta@akr.fm
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] GPLPV and pci passthrough
> 
> >
> > James,
> > 	At least one other person (Lta, included in this message) and I
> have
> > had problems using passthrough pci devices and your GPLPV drivers at
> the
> > same time.  My symptoms are that SMB connections are totally
> unreliable
> > (however, downloading over http seems to work well enough).
> > For example, if I start a video or audio file, playing from the
> network, it will
> > play the first few seconds fine, then the connection drops out.
> > I can confirm that the problems don't exist when not passing through
> any
> > devices.
> >
> > 	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU
> with
> > an ATI 4770, USB controller, and ICE1712 based pci sound card passed
> > through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.
> >
> > 	I tried the -debug drivers, and I see a ton of output in qemu
> log,
> > however, all that output seems to be at initialization.  I do not
see
> any
> > additional output from your drivers after boot, including when I'm
> > experiencing problems.
> >
> > 	I took a quick look at tcpdump output and it does seem the guest
> is
> > ACKing the packets as they come in, so my first guess is that
they're
> getting
> > lost somewhere between the driver and the OS network stack.
> >
> > 	I've never set up a build environment for these drivers so I
> haven't
> > tried adding any extra debug output.  Have you looked into the (or a
> similar)
> > problem before, or have a more verbose debug copy of the net driver
> you've
> > used to diagnose similar problems before?
> >
> > 	I guess the real question is, do you have any idea where we
> should
> > start looking?
> >
> 
> I'd be first looking at interrupt sharing. Maybe GPLPV doesn't like
> sharing interrupts with anything?
> 
> Have a look in device manager and set the view as "Resources by type"
> and see if anything is sharing an interrupt with the "Xen PCI Device
> Driver".
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 27 19:06:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19: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 1Rqr7b-0002De-57; Fri, 27 Jan 2012 19:06: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 1Rqr7Z-0002DJ-Ub
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:06:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327691155!12680096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8208 invoked from network); 27 Jan 2012 19:05:56 -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;
	27 Jan 2012 19:05:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10340189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 19:05:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 19:05:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rqr7T-0005oY-BQ; Fri, 27 Jan 2012 19:05:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqr7T-0006HW-AN;
	Fri, 27 Jan 2012 19:05:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.62867.307721.824533@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 19:05:55 +0000
To: erin.balid@inoutbox.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327426696.16492.140661027458613@webmail.messagingengine.com>
References: <1327426696.16492.140661027458613@webmail.messagingengine.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] Where does xl debug logging info appear?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

erin.balid@inoutbox.com writes ("[Xen-devel] Where does xl debug logging info appear?"):
> Following instructions in another thread, I've added a bunch of "log
> debug ..." breadcrumbs in the vif-bridge script.
> 
> Now I'm trying to *see* those breadcrumbs when I "xl create" a Guest.

/var/log/xen/*hotplug* ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 19:06:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19: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 1Rqr7b-0002De-57; Fri, 27 Jan 2012 19:06: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 1Rqr7Z-0002DJ-Ub
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:06:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327691155!12680096!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8208 invoked from network); 27 Jan 2012 19:05:56 -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;
	27 Jan 2012 19:05:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10340189"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 19:05:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 19:05:55 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rqr7T-0005oY-BQ; Fri, 27 Jan 2012 19:05:55 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rqr7T-0006HW-AN;
	Fri, 27 Jan 2012 19:05:55 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.62867.307721.824533@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 19:05:55 +0000
To: erin.balid@inoutbox.com
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327426696.16492.140661027458613@webmail.messagingengine.com>
References: <1327426696.16492.140661027458613@webmail.messagingengine.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] Where does xl debug logging info appear?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

erin.balid@inoutbox.com writes ("[Xen-devel] Where does xl debug logging info appear?"):
> Following instructions in another thread, I've added a bunch of "log
> debug ..." breadcrumbs in the vif-bridge script.
> 
> Now I'm trying to *see* those breadcrumbs when I "xl create" a Guest.

/var/log/xen/*hotplug* ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 19:09:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqrBG-0002Ux-QZ; Fri, 27 Jan 2012 19:09: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 1RqrBF-0002Uh-6P
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:09:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327691383!5260026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28595 invoked from network); 27 Jan 2012 19:09:43 -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;
	27 Jan 2012 19:09:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10340214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 19:09: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, 27 Jan 2012 19:09: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
	1RqrB8-0005pm-Np; Fri, 27 Jan 2012 19:09:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqrB8-0006Hq-Mq;
	Fri, 27 Jan 2012 19:09:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.63094.694795.399684@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 19:09:42 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a1986ef30b7dab4f60fe.1326606964@alpine.localdomain>
References: <a1986ef30b7dab4f60fe.1326606964@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 v3] 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

Roger Pau Monne writes ("[Xen-devel] [PATCH v3] libxl: add support for yajl 2.x"):
> libxl: add support for yajl 2.x
> 
> This patch adds support for yajl versions 2.x, while retaining 1.x
> compatibility. All the needed ifdefs can be found in libxl_json.h.

Thanks.  I'm afraid this needs a refresh:

 patching file tools/libxl/libxl_json.h
 Hunk #1 FAILED at 16.
 1 out of 1 hunk FAILED -- saving rejects to file tools/libxl/libxl_json.h.rej

Also, while you're at it:
> +static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
> +{
> +    return yajl_gen_alloc(allocFuncs);
> +}
> +#else

A couple of blank lines around this #ifs and #elses might be nice.
And also I would say
  #else /* !HAVE_YAJL_V2 */
and
  #endif /* !HAVE_YAJL_V2 */

(But I would have committed it without those changes if it had applied
cleanly.)

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 Jan 27 19:09:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19:09:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqrBG-0002Ux-QZ; Fri, 27 Jan 2012 19:09: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 1RqrBF-0002Uh-6P
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:09:49 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327691383!5260026!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28595 invoked from network); 27 Jan 2012 19:09:43 -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;
	27 Jan 2012 19:09:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10340214"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 19:09: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, 27 Jan 2012 19:09: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
	1RqrB8-0005pm-Np; Fri, 27 Jan 2012 19:09:42 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqrB8-0006Hq-Mq;
	Fri, 27 Jan 2012 19:09:42 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.63094.694795.399684@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 19:09:42 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <a1986ef30b7dab4f60fe.1326606964@alpine.localdomain>
References: <a1986ef30b7dab4f60fe.1326606964@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 v3] 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

Roger Pau Monne writes ("[Xen-devel] [PATCH v3] libxl: add support for yajl 2.x"):
> libxl: add support for yajl 2.x
> 
> This patch adds support for yajl versions 2.x, while retaining 1.x
> compatibility. All the needed ifdefs can be found in libxl_json.h.

Thanks.  I'm afraid this needs a refresh:

 patching file tools/libxl/libxl_json.h
 Hunk #1 FAILED at 16.
 1 out of 1 hunk FAILED -- saving rejects to file tools/libxl/libxl_json.h.rej

Also, while you're at it:
> +static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
> +{
> +    return yajl_gen_alloc(allocFuncs);
> +}
> +#else

A couple of blank lines around this #ifs and #elses might be nice.
And also I would say
  #else /* !HAVE_YAJL_V2 */
and
  #endif /* !HAVE_YAJL_V2 */

(But I would have committed it without those changes if it had applied
cleanly.)

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 Jan 27 19:10:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqrBK-0002VK-7T; Fri, 27 Jan 2012 19:09:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqrBI-0002VA-Qe
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:09:53 +0000
Received: from [85.158.138.51:10088] by server-1.bemta-3.messagelabs.com id
	F3/5A-09565-086F22F4; Fri, 27 Jan 2012 19:09:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327691390!10984624!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMTEzNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13463 invoked from network); 27 Jan 2012 19:09:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 19:09:51 -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
	q0RJ9lZT005849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 19:09:48 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
	q0RJ9kFl022619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 19:09:46 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
	q0RJ9j9T029578; Fri, 27 Jan 2012 13:09:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 11:09:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 48112401A2; Fri, 27 Jan 2012 14:07:22 -0500 (EST)
Date: Fri, 27 Jan 2012 14:07:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Message-ID: <20120127190722.GA14256@phenom.dumpdata.com>
References: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
	<1326388007-19178-2-git-send-email-konrad.wilk@oracle.com>
	<20120127093225.7c1194ae@jbarnes-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120127093225.7c1194ae@jbarnes-desktop>
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.4F22F67D.0003,ss=1,re=0.000,fgs=0
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/2] pci: Introduce
 __pci_reset_function_locked to be used when holding device_lock.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 09:32:25AM -0800, Jesse Barnes wrote:
> On Thu, 12 Jan 2012 12:06:46 -0500
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > The use case of this is when a driver wants to call FLR when a device
> > is attached to it using the SysFS "bind" or "unbind" functionality.
> > 
> > The call chain when a user does "bind" looks as so:
> > 
> >  echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind
> > 
> > and ends up calling:
> >   driver_bind:
> >     device_lock(dev);  <=== TAKES LOCK
> >     XXXX_probe:
> >          .. pci_enable_device()
> >          ...__pci_reset_function(), which calls
> >                  pci_dev_reset(dev, 0):
> >                         if (!0) {
> >                                 device_lock(dev) <==== DEADLOCK
> 
> I have these two in my -next branch now; but you could also push them
> through the Xen tree.  If you have other deps and the Xen tree would be
> easier, just let me know and I'll drop them.

Thanks! Lets keep them in your tree.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 19:10:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19:10:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqrBK-0002VK-7T; Fri, 27 Jan 2012 19:09:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqrBI-0002VA-Qe
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:09:53 +0000
Received: from [85.158.138.51:10088] by server-1.bemta-3.messagelabs.com id
	F3/5A-09565-086F22F4; Fri, 27 Jan 2012 19:09:52 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327691390!10984624!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMTEzNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13463 invoked from network); 27 Jan 2012 19:09:51 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 19:09:51 -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
	q0RJ9lZT005849
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 19:09:48 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
	q0RJ9kFl022619
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 19:09:46 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
	q0RJ9j9T029578; Fri, 27 Jan 2012 13:09:45 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 11:09:45 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 48112401A2; Fri, 27 Jan 2012 14:07:22 -0500 (EST)
Date: Fri, 27 Jan 2012 14:07:22 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Message-ID: <20120127190722.GA14256@phenom.dumpdata.com>
References: <1326388007-19178-1-git-send-email-konrad.wilk@oracle.com>
	<1326388007-19178-2-git-send-email-konrad.wilk@oracle.com>
	<20120127093225.7c1194ae@jbarnes-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120127093225.7c1194ae@jbarnes-desktop>
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.4F22F67D.0003,ss=1,re=0.000,fgs=0
Cc: linux-pci@vger.kernel.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH 1/2] pci: Introduce
 __pci_reset_function_locked to be used when holding device_lock.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, Jan 27, 2012 at 09:32:25AM -0800, Jesse Barnes wrote:
> On Thu, 12 Jan 2012 12:06:46 -0500
> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > The use case of this is when a driver wants to call FLR when a device
> > is attached to it using the SysFS "bind" or "unbind" functionality.
> > 
> > The call chain when a user does "bind" looks as so:
> > 
> >  echo "0000:01.07.0" > /sys/bus/pci/drivers/XXXX/bind
> > 
> > and ends up calling:
> >   driver_bind:
> >     device_lock(dev);  <=== TAKES LOCK
> >     XXXX_probe:
> >          .. pci_enable_device()
> >          ...__pci_reset_function(), which calls
> >                  pci_dev_reset(dev, 0):
> >                         if (!0) {
> >                                 device_lock(dev) <==== DEADLOCK
> 
> I have these two in my -next branch now; but you could also push them
> through the Xen tree.  If you have other deps and the Xen tree would be
> easier, just let me know and I'll drop them.

Thanks! Lets keep them in your tree.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 19:10:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqrBf-0002YX-Lk; Fri, 27 Jan 2012 19:10:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RqrBe-0002Xn-T0
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:10:15 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327691408!8655260!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzE5OTI5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25872 invoked from network); 27 Jan 2012 19:10:08 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 19:10:08 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q0RJA1fD000492;
	Fri, 27 Jan 2012 20:10:01 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0RJ9xmt029428;
	Fri, 27 Jan 2012 20:09:59 +0100
Message-ID: <4F22F687.40904@siemens.com>
Date: Fri, 27 Jan 2012 20:09:59 +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: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327688498-12362-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	avi@redhat.com
Subject: Re: [Xen-devel] [PATCH v3 1/6] xen: do not initialize the interval
	timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-27 19:21, Stefano Stabellini wrote:
> PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
> this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  hw/pc.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/pc.c b/hw/pc.c
> index 85304cf..7a7ce98 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -43,6 +43,7 @@
>  #include "ui/qemu-spice.h"
>  #include "memory.h"
>  #include "exec-memory.h"
> +#include "arch_init.h"
>  
>  /* output Bochs bios info messages */
>  //#define DEBUG_BIOS
> @@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>      DriveInfo *fd[MAX_FD];
>      qemu_irq rtc_irq = NULL;
>      qemu_irq *a20_line;
> -    ISADevice *i8042, *port92, *vmmouse, *pit;
> +    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
>      qemu_irq *cpu_exit_irq;
>  
>      register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
> @@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>  
>      qemu_register_boot_set(pc_boot_set, *rtc_state);
>  
> -    pit = pit_init(isa_bus, 0x40, 0);
> +    if (!xen_available()) {
> +        pit = pit_init(isa_bus, 0x40, 0);
> +    }
>      pcspk_init(pit);
>  
>      for(i = 0; i < MAX_SERIAL_PORTS; i++) {

Thus as guest accessing to port 0x61 will be able to crash qemu because
pit is NULL? Or do you emulate that port in the kernel? If not, you
likely want to move pcspk_init() under the same umbrella.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 19:10:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19:10:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RqrBf-0002YX-Lk; Fri, 27 Jan 2012 19:10:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1RqrBe-0002Xn-T0
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:10:15 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327691408!8655260!1
X-Originating-IP: [192.35.17.2]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjIgPT4gMzE5OTI5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25872 invoked from network); 27 Jan 2012 19:10:08 -0000
Received: from thoth.sbs.de (HELO thoth.sbs.de) (192.35.17.2)
	by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 19:10:08 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q0RJA1fD000492;
	Fri, 27 Jan 2012 20:10:01 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0RJ9xmt029428;
	Fri, 27 Jan 2012 20:09:59 +0100
Message-ID: <4F22F687.40904@siemens.com>
Date: Fri, 27 Jan 2012 20:09:59 +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: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-1-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327688498-12362-1-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: pbonzini@redhat.com, xen-devel@lists.xensource.com, qemu-devel@nongnu.org,
	avi@redhat.com
Subject: Re: [Xen-devel] [PATCH v3 1/6] xen: do not initialize the interval
	timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-27 19:21, Stefano Stabellini wrote:
> PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
> this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  hw/pc.c |    7 +++++--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/pc.c b/hw/pc.c
> index 85304cf..7a7ce98 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -43,6 +43,7 @@
>  #include "ui/qemu-spice.h"
>  #include "memory.h"
>  #include "exec-memory.h"
> +#include "arch_init.h"
>  
>  /* output Bochs bios info messages */
>  //#define DEBUG_BIOS
> @@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>      DriveInfo *fd[MAX_FD];
>      qemu_irq rtc_irq = NULL;
>      qemu_irq *a20_line;
> -    ISADevice *i8042, *port92, *vmmouse, *pit;
> +    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
>      qemu_irq *cpu_exit_irq;
>  
>      register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
> @@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>  
>      qemu_register_boot_set(pc_boot_set, *rtc_state);
>  
> -    pit = pit_init(isa_bus, 0x40, 0);
> +    if (!xen_available()) {
> +        pit = pit_init(isa_bus, 0x40, 0);
> +    }
>      pcspk_init(pit);
>  
>      for(i = 0; i < MAX_SERIAL_PORTS; i++) {

Thus as guest accessing to port 0x61 will be able to crash qemu because
pit is NULL? Or do you emulate that port in the kernel? If not, you
likely want to move pcspk_init() under the same umbrella.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 19:19:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19: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 1RqrKE-00034X-PF; Fri, 27 Jan 2012 19:19: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 1RqrKD-00034S-Ll
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:19:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327691939!2936172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4109 invoked from network); 27 Jan 2012 19:18: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;
	27 Jan 2012 19:18:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10340279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 19:18:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 19:18: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
	1RqrK7-0005t8-Cr; Fri, 27 Jan 2012 19:18:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqrK7-0006SK-BU;
	Fri, 27 Jan 2012 19:18:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.63649.211615.28392@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 19:18:57 +0000
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327500920.2723.11.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv3 0 of 2] libxl: Extend CPU affinity syntax
 and enable for specifying it in config 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

Dario Faggioli writes ("[Xen-devel] [PATCHv3 0 of 2] libxl: Extend CPU affinity syntax and enable for specifying it in config file."):
> This series slightly extends the current support for specifying CPU
> affinity, basically adding the support for "^<cpuid>" kind of entries
> (i.e., "^6", meaning "not on CPU#6), and enables doing so in a VM's
> config file, like it (probably?) was possible with `xm'.

Thanks, I have applied both of these.

A couple of comments for when you next send patches:

 * Having two patches both titled 1/2 is rather confusing,
   particularly if you then gratuitously repost one of them.

 * There doesn't seem to be any need for you to attach a second copy
   of the patch - in both cases the first one was in fact fine - and
   it would be easier for me if you didn't.

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 Jan 27 19:19:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19: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 1RqrKE-00034X-PF; Fri, 27 Jan 2012 19:19: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 1RqrKD-00034S-Ll
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:19:05 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327691939!2936172!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4109 invoked from network); 27 Jan 2012 19:18: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;
	27 Jan 2012 19:18:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,581,1320624000"; d="scan'208";a="10340279"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 19:18:59 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Fri, 27 Jan 2012 19:18: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
	1RqrK7-0005t8-Cr; Fri, 27 Jan 2012 19:18:59 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RqrK7-0006SK-BU;
	Fri, 27 Jan 2012 19:18:59 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20258.63649.211615.28392@mariner.uk.xensource.com>
Date: Fri, 27 Jan 2012 19:18:57 +0000
To: Dario Faggioli <raistlin@linux.it>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327500920.2723.11.camel@Abyss>
References: <1327500920.2723.11.camel@Abyss>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: "Ian.Campbell" <Ian.Campbell@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	xen-devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCHv3 0 of 2] libxl: Extend CPU affinity syntax
 and enable for specifying it in config 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

Dario Faggioli writes ("[Xen-devel] [PATCHv3 0 of 2] libxl: Extend CPU affinity syntax and enable for specifying it in config file."):
> This series slightly extends the current support for specifying CPU
> affinity, basically adding the support for "^<cpuid>" kind of entries
> (i.e., "^6", meaning "not on CPU#6), and enables doing so in a VM's
> config file, like it (probably?) was possible with `xm'.

Thanks, I have applied both of these.

A couple of comments for when you next send patches:

 * Having two patches both titled 1/2 is rather confusing,
   particularly if you then gratuitously repost one of them.

 * There doesn't seem to be any need for you to attach a second copy
   of the patch - in both cases the first one was in fact fine - and
   it would be easier for me if you didn't.

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 Jan 27 19:25:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19: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 1RqrPl-0003Mh-L3; Fri, 27 Jan 2012 19:24:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqrPj-0003Mc-BS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:24:47 +0000
Received: from [85.158.138.51:49310] by server-10.bemta-3.messagelabs.com id
	75/01-20948-EF9F22F4; Fri, 27 Jan 2012 19:24:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327692284!10985792!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMTEzNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14557 invoked from network); 27 Jan 2012 19:24:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 19:24:45 -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
	q0RJOdS7026394
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 19:24:40 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
	q0RJOck4013903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 19:24:39 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
	q0RJOcOJ011756; Fri, 27 Jan 2012 13:24:38 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 11:24:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 01F1D401A1; Fri, 27 Jan 2012 14:22:14 -0500 (EST)
Date: Fri, 27 Jan 2012 14:22:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120127192214.GA14437@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F22F9F9.0016,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, paul.durrant@citrix.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 01:46:56PM +0000, Wei Liu wrote:
> A new netback implementation which includes three major features:
> 
>  - Global page pool support
>  - NAPI + kthread 1:1 model
>  - Netback internal name changes
> 
> Changes in V2:
>  - Fix minor bugs in V1
>  - Embed pending_tx_info into page pool
>  - Per-cpu scratch space
>  - Notification code path clean up
> 
> This patch series is the foundation of furture work. So it is better
> to get it right first. Patch 1 and 3 have the real meat.

I've been playing with these patches and couple of things
came to my mind: 
 - would it make sense to also register to the shrinker API? This way
   if the host is running low on memory it can squeeze it out of the
   pool code. Perhaps a future TODO..
 - I like the pool code. I was thinking that perhaps (in the future)
   it could be used by blkback as well, as it runs into "not enought
   request structure" with the default setting. And making this dynamic
   would be pretty sweet.
 - This patch set solves the CPU banding problem I've seen with the
   older netback. The older one  I could see X netback threads eating 80%
   of CPU. With this one, the number is down to 13-14%.

So you can definitly stick 'Tested-by: Konrad.." on them. And definitly
Reviewed-by on the first two - hadn't had a chance to look at the rest.

> 
> The first benifit of 1:1 model will be scheduling fairness.
> 
> The rational behind a global page pool is that we need to limit
> overall memory consumed by all vifs.
> 
> Utilization of NAPI enables the possibility to mitigate
> interrupts/events, the code path is cleaned up in a separated patch.
> 
> Netback internal changes cleans up the code structure after switching
> to 1:1 model. It also prepares netback for further code layout
> changes.
> 
> ---
>  drivers/net/xen-netback/Makefile    |    2 +-
>  drivers/net/xen-netback/common.h    |   78 ++--
>  drivers/net/xen-netback/interface.c |  117 ++++--
>  drivers/net/xen-netback/netback.c   |  836 ++++++++++++++---------------------
>  drivers/net/xen-netback/page_pool.c |  185 ++++++++
>  drivers/net/xen-netback/page_pool.h |   66 +++
>  drivers/net/xen-netback/xenbus.c    |    6 +-
>  7 files changed, 704 insertions(+), 586 deletions(-)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 19:25:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 19: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 1RqrPl-0003Mh-L3; Fri, 27 Jan 2012 19:24:49 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RqrPj-0003Mc-BS
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 19:24:47 +0000
Received: from [85.158.138.51:49310] by server-10.bemta-3.messagelabs.com id
	75/01-20948-EF9F22F4; Fri, 27 Jan 2012 19:24:46 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327692284!10985792!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxMTEzNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14557 invoked from network); 27 Jan 2012 19:24:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 19:24:45 -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
	q0RJOdS7026394
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Fri, 27 Jan 2012 19:24:40 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
	q0RJOck4013903
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 27 Jan 2012 19:24:39 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
	q0RJOcOJ011756; Fri, 27 Jan 2012 13:24:38 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Fri, 27 Jan 2012 11:24:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 01F1D401A1; Fri, 27 Jan 2012 14:22:14 -0500 (EST)
Date: Fri, 27 Jan 2012 14:22:14 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120127192214.GA14437@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090203.4F22F9F9.0016,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, paul.durrant@citrix.com, david.vrabel@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 01:46:56PM +0000, Wei Liu wrote:
> A new netback implementation which includes three major features:
> 
>  - Global page pool support
>  - NAPI + kthread 1:1 model
>  - Netback internal name changes
> 
> Changes in V2:
>  - Fix minor bugs in V1
>  - Embed pending_tx_info into page pool
>  - Per-cpu scratch space
>  - Notification code path clean up
> 
> This patch series is the foundation of furture work. So it is better
> to get it right first. Patch 1 and 3 have the real meat.

I've been playing with these patches and couple of things
came to my mind: 
 - would it make sense to also register to the shrinker API? This way
   if the host is running low on memory it can squeeze it out of the
   pool code. Perhaps a future TODO..
 - I like the pool code. I was thinking that perhaps (in the future)
   it could be used by blkback as well, as it runs into "not enought
   request structure" with the default setting. And making this dynamic
   would be pretty sweet.
 - This patch set solves the CPU banding problem I've seen with the
   older netback. The older one  I could see X netback threads eating 80%
   of CPU. With this one, the number is down to 13-14%.

So you can definitly stick 'Tested-by: Konrad.." on them. And definitly
Reviewed-by on the first two - hadn't had a chance to look at the rest.

> 
> The first benifit of 1:1 model will be scheduling fairness.
> 
> The rational behind a global page pool is that we need to limit
> overall memory consumed by all vifs.
> 
> Utilization of NAPI enables the possibility to mitigate
> interrupts/events, the code path is cleaned up in a separated patch.
> 
> Netback internal changes cleans up the code structure after switching
> to 1:1 model. It also prepares netback for further code layout
> changes.
> 
> ---
>  drivers/net/xen-netback/Makefile    |    2 +-
>  drivers/net/xen-netback/common.h    |   78 ++--
>  drivers/net/xen-netback/interface.c |  117 ++++--
>  drivers/net/xen-netback/netback.c   |  836 ++++++++++++++---------------------
>  drivers/net/xen-netback/page_pool.c |  185 ++++++++
>  drivers/net/xen-netback/page_pool.h |   66 +++
>  drivers/net/xen-netback/xenbus.c    |    6 +-
>  7 files changed, 704 insertions(+), 586 deletions(-)
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 20:09:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 20:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqs6P-0003uy-7n; Fri, 27 Jan 2012 20:08:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rqs6O-0003ut-0p
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 20:08:52 +0000
Received: from [85.158.138.51:39782] by server-1.bemta-3.messagelabs.com id
	AE/C2-09565-354032F4; Fri, 27 Jan 2012 20:08:51 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327694930!10989318!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13662 invoked from network); 27 Jan 2012 20:08:50 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 20:08:50 -0000
Received: by eekb45 with SMTP id b45so11082634eek.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 12:08:50 -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:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=VvT1sMWTrDdYrP4xH5REGgjiLh1nWeJtwumbcd4CA9U=;
	b=lIkfSM92zzw7bSOUG0ZC5x+Feogbc/F8jkIBejqsHz6gaghuCkpGYLT2wHjuNvNxBL
	K1DUQs7A9x9+Bl3Fx/dntAepQDFZgfB2IEAgj1ViQfC9ASLt4sw22Elpl5i9dAnyLBuW
	+r29gJasPW5hznAYmr5ACp6OJdWfU3xL2kMC0=
Received: by 10.14.99.132 with SMTP id x4mr2656648eef.74.1327694930343;
	Fri, 27 Jan 2012 12:08:50 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id e12sm33552004eea.5.2012.01.27.12.08.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 27 Jan 2012 12:08:49 -0800 (PST)
Message-ID: <4F23044C.3070209@redhat.com>
Date: Fri, 27 Jan 2012 21:08:44 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu,gmane.comp.emulators.xen.devel
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327688498-12362-2-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, avi@redhat.com
Subject: Re: [Xen-devel] [PATCH v3 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 07:21 PM, Stefano Stabellini wrote:
> rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
> has its own RTC emulator in the hypervisor so we can disable it.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   xen-all.c |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/xen-all.c b/xen-all.c
> index d1fc597..bf183f7 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -513,6 +513,7 @@ void xen_vcpu_init(void)
>           qemu_register_reset(xen_reset_vcpu, first_cpu);
>           xen_reset_vcpu(first_cpu);
>       }
> +    qemu_clock_enable(rtc_clock, false);
>   }
>
>   /* get the ioreq packets from share mem */

I explained why this is wrong.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 20:09:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 20:09:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqs6P-0003uy-7n; Fri, 27 Jan 2012 20:08:53 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rqs6O-0003ut-0p
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 20:08:52 +0000
Received: from [85.158.138.51:39782] by server-1.bemta-3.messagelabs.com id
	AE/C2-09565-354032F4; Fri, 27 Jan 2012 20:08:51 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327694930!10989318!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13662 invoked from network); 27 Jan 2012 20:08:50 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 20:08:50 -0000
Received: by eekb45 with SMTP id b45so11082634eek.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 12:08:50 -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:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=VvT1sMWTrDdYrP4xH5REGgjiLh1nWeJtwumbcd4CA9U=;
	b=lIkfSM92zzw7bSOUG0ZC5x+Feogbc/F8jkIBejqsHz6gaghuCkpGYLT2wHjuNvNxBL
	K1DUQs7A9x9+Bl3Fx/dntAepQDFZgfB2IEAgj1ViQfC9ASLt4sw22Elpl5i9dAnyLBuW
	+r29gJasPW5hznAYmr5ACp6OJdWfU3xL2kMC0=
Received: by 10.14.99.132 with SMTP id x4mr2656648eef.74.1327694930343;
	Fri, 27 Jan 2012 12:08:50 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id e12sm33552004eea.5.2012.01.27.12.08.48
	(version=TLSv1/SSLv3 cipher=OTHER);
	Fri, 27 Jan 2012 12:08:49 -0800 (PST)
Message-ID: <4F23044C.3070209@redhat.com>
Date: Fri, 27 Jan 2012 21:08:44 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu,gmane.comp.emulators.xen.devel
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-2-git-send-email-stefano.stabellini@eu.citrix.com>
In-Reply-To: <1327688498-12362-2-git-send-email-stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, qemu-devel@nongnu.org, avi@redhat.com
Subject: Re: [Xen-devel] [PATCH v3 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/27/2012 07:21 PM, Stefano Stabellini wrote:
> rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
> has its own RTC emulator in the hypervisor so we can disable it.
>
> Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> ---
>   xen-all.c |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/xen-all.c b/xen-all.c
> index d1fc597..bf183f7 100644
> --- a/xen-all.c
> +++ b/xen-all.c
> @@ -513,6 +513,7 @@ void xen_vcpu_init(void)
>           qemu_register_reset(xen_reset_vcpu, first_cpu);
>           xen_reset_vcpu(first_cpu);
>       }
> +    qemu_clock_enable(rtc_clock, false);
>   }
>
>   /* get the ioreq packets from share mem */

I explained why this is wrong.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 20:13:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 20: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 1RqsAY-00046r-3S; Fri, 27 Jan 2012 20:13: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 1RqsAW-00046d-Dt
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 20:13:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327695178!3974872!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3168 invoked from network); 27 Jan 2012 20:13:00 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 20:13:00 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0RKCtMS007395
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 12:12:56 -0800
Received: by bkar1 with SMTP id r1so3261662bka.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 12:12:53 -0800 (PST)
Received: by 10.204.148.84 with SMTP id o20mr3646886bkv.103.1327695173429;
	Fri, 27 Jan 2012 12:12:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Fri, 27 Jan 2012 12:12:13 -0800 (PST)
In-Reply-To: <1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
	<1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 27 Jan 2012 12:12:13 -0800
Message-ID: <CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7206758752035746371=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7206758752035746371==
Content-Type: multipart/alternative; boundary=0015175cac0c2eab0204b7881f5d

--0015175cac0c2eab0204b7881f5d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 20, 2012 at 9:25 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> Introduce a new save_id to save/restore toolstack specific extra
> information.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxc/xc_domain_restore.c |   66
> +++++++++++++++++++++++++++-----------
>  tools/libxc/xc_domain_save.c    |   17 ++++++++++
>  tools/libxc/xenguest.h          |   23 +++++++++++++-
>  tools/libxc/xg_save_restore.h   |    1 +
>  tools/libxl/libxl_dom.c         |    2 +-
>  tools/xcutils/xc_restore.c      |    3 +-
>  6 files changed, 90 insertions(+), 22 deletions(-)
>
> diff --git a/tools/libxc/xc_domain_restore.c
> b/tools/libxc/xc_domain_restore.c
> index 14451d1..72b6d5b 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -702,7 +702,8 @@ static void pagebuf_free(pagebuf_t* buf)
>  }
>
>  static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
> -                           pagebuf_t* buf, int fd, uint32_t dom)
> +                           pagebuf_t* buf, int fd, uint32_t dom,
> +                           struct restore_callbacks* callbacks)
>  {
>     int count, countpages, oldcount, i;
>     void* ptmp;
> @@ -725,7 +726,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>     case XC_SAVE_ID_ENABLE_VERIFY_MODE:
>         DPRINTF("Entering page verify mode\n");
>         buf->verify = 1;
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_VCPU_INFO:
>         buf->new_ctxt_format = 1;
> @@ -736,7 +737,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             return -1;
>         }
>         // DPRINTF("Max VCPU ID: %d, vcpumap: %llx\n", buf->max_vcpu_id,
> buf->vcpumap);
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_HVM_IDENT_PT:
>         /* Skip padding 4 bytes then read the EPT identity PT location. */
> @@ -747,7 +748,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             return -1;
>         }
>         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_HVM_VM86_TSS:
>         /* Skip padding 4 bytes then read the vm86 TSS location. */
> @@ -758,7 +759,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             return -1;
>         }
>         // DPRINTF("VM86 TSS location: %llx\n", buf->vm86_tss);
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_TMEM:
>         DPRINTF("xc_domain_restore start tmem\n");
> @@ -766,14 +767,14 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             PERROR("error reading/restoring tmem");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_TMEM_EXTRA:
>         if ( xc_tmem_restore_extra(xch, dom, fd) ) {
>             PERROR("error reading/restoring tmem extra");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_TSC_INFO:
>     {
> @@ -787,7 +788,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             PERROR("error reading/restoring tsc info");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>     }
>
>     case XC_SAVE_ID_HVM_CONSOLE_PFN :
> @@ -799,12 +800,12 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             return -1;
>         }
>         // DPRINTF("console pfn location: %llx\n", buf->console_pfn);
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_LAST_CHECKPOINT:
>         ctx->last_checkpoint = 1;
>         // DPRINTF("last checkpoint indication received");
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:
>         /* Skip padding 4 bytes then read the acpi ioport location. */
> @@ -814,7 +815,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             PERROR("error read the acpi ioport location");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_HVM_VIRIDIAN:
>         /* Skip padding 4 bytes then read the acpi ioport location. */
> @@ -824,8 +825,33 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             PERROR("error read the viridian flag");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
> +    case XC_SAVE_ID_TOOLSTACK:
> +        {
> +            uint32_t len;
> +            uint8_t *buf2;
> +            RDEXACT(fd, &len, sizeof(len));
> +            buf2 = (uint8_t*) malloc(len);
> +            if ( buf2 == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, buf2, len);
> +            if ( callbacks != NULL && callbacks->toolstack_restore !=
> NULL )
> +            {
> +                if ( callbacks->toolstack_restore(dom,
> +                            buf2, len, callbacks->data) < 0 )
> +                {
>


Pagebuf() shouldnt be modifying any domain state until the entire
memory buffer is obtained, esp the device state. See below.

@@ -1542,7 +1570,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>
>     // DPRINTF("Buffered checkpoint\n");
>
> -    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
> +    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom, callbacks) ) {
>         PERROR("error when buffering batch, finishing");
>         goto finish;
>     }
>

If there is an error in applying the toolstack state, then pagebuf_get
returns -1 and
the rest of the code would still attempt to resume the domain, with possibly
inconsistent device model state.

Also, lets say there was no error in applying the toolstack state. If a
network
error occurs while receiving the next XC_SAVE_ID or so, then again, the
code following
the above snippet would attempt to resume the domain, with a memory state
inconsistent
with the device state.

The right place to call the callbacks->toolstack_restore would be after the
finish_hvm:
label, where currently the old QEMU device state is restored.


shriram

--0015175cac0c2eab0204b7881f5d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Jan 20, 2012 at 9:25 AM, Stefano Stabell=
ini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.co=
m">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

Introduce a new save_id to save/restore toolstack specific extra<br>
information.<br>
<br>
Signed-off-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellini@=
eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>
---<br>
=A0tools/libxc/xc_domain_restore.c | =A0 66 +++++++++++++++++++++++++++----=
-------<br>
=A0tools/libxc/xc_domain_save.c =A0 =A0| =A0 17 ++++++++++<br>
=A0tools/libxc/xenguest.h =A0 =A0 =A0 =A0 =A0| =A0 23 +++++++++++++-<br>
=A0tools/libxc/xg_save_restore.h =A0 | =A0 =A01 +<br>
=A0tools/libxl/libxl_dom.c =A0 =A0 =A0 =A0 | =A0 =A02 +-<br>
=A0tools/xcutils/xc_restore.c =A0 =A0 =A0| =A0 =A03 +-<br>
=A06 files changed, 90 insertions(+), 22 deletions(-)<br>
<br>
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restor=
e.c<br>
index 14451d1..72b6d5b 100644<br>
--- a/tools/libxc/xc_domain_restore.c<br>
+++ b/tools/libxc/xc_domain_restore.c<br>
@@ -702,7 +702,8 @@ static void pagebuf_free(pagebuf_t* buf)<br>
=A0}<br>
<br>
=A0static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,<b=
r>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf_t* buf, int f=
d, uint32_t dom)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf_t* buf, int f=
d, uint32_t dom,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct restore_callba=
cks* callbacks)<br>
=A0{<br>
 =A0 =A0 int count, countpages, oldcount, i;<br>
 =A0 =A0 void* ptmp;<br>
@@ -725,7 +726,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 case XC_SAVE_ID_ENABLE_VERIFY_MODE:<br>
 =A0 =A0 =A0 =A0 DPRINTF(&quot;Entering page verify mode\n&quot;);<br>
 =A0 =A0 =A0 =A0 buf-&gt;verify =3D 1;<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_VCPU_INFO:<br>
 =A0 =A0 =A0 =A0 buf-&gt;new_ctxt_format =3D 1;<br>
@@ -736,7 +737,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;Max VCPU ID: %d, vcpumap: %llx\n&quot;, b=
uf-&gt;max_vcpu_id, buf-&gt;vcpumap);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_IDENT_PT:<br>
 =A0 =A0 =A0 =A0 /* Skip padding 4 bytes then read the EPT identity PT loca=
tion. */<br>
@@ -747,7 +748,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;EPT identity map address: %llx\n&quot;, b=
uf-&gt;identpt);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_VM86_TSS:<br>
 =A0 =A0 =A0 =A0 /* Skip padding 4 bytes then read the vm86 TSS location. *=
/<br>
@@ -758,7 +759,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;VM86 TSS location: %llx\n&quot;, buf-&gt;=
vm86_tss);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_TMEM:<br>
 =A0 =A0 =A0 =A0 DPRINTF(&quot;xc_domain_restore start tmem\n&quot;);<br>
@@ -766,14 +767,14 @@ static int pagebuf_get_one(xc_interface *xch, struct =
restore_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error reading/restoring tmem&quot;);<=
br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_TMEM_EXTRA:<br>
 =A0 =A0 =A0 =A0 if ( xc_tmem_restore_extra(xch, dom, fd) ) {<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error reading/restoring tmem extra&qu=
ot;);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_TSC_INFO:<br>
 =A0 =A0 {<br>
@@ -787,7 +788,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error reading/restoring tsc info&quot=
;);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_CONSOLE_PFN :<br>
@@ -799,12 +800,12 @@ static int pagebuf_get_one(xc_interface *xch, struct =
restore_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;console pfn location: %llx\n&quot;, buf-&=
gt;console_pfn);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_LAST_CHECKPOINT:<br>
 =A0 =A0 =A0 =A0 ctx-&gt;last_checkpoint =3D 1;<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;last checkpoint indication received&quot;=
);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:<br>
 =A0 =A0 =A0 =A0 /* Skip padding 4 bytes then read the acpi ioport location=
. */<br>
@@ -814,7 +815,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error read the acpi ioport location&q=
uot;);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_VIRIDIAN:<br>
 =A0 =A0 =A0 =A0 /* Skip padding 4 bytes then read the acpi ioport location=
. */<br>
@@ -824,8 +825,33 @@ static int pagebuf_get_one(xc_interface *xch, struct r=
estore_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error read the viridian flag&quot;);<=
br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
+ =A0 =A0case XC_SAVE_ID_TOOLSTACK:<br>
+ =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0uint32_t len;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0uint8_t *buf2;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, &amp;len, sizeof(len));<br>
+ =A0 =A0 =A0 =A0 =A0 =A0buf2 =3D (uint8_t*) malloc(len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( buf2 =3D=3D NULL )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error memory allocation&quot;=
);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0}<br>
+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, buf2, len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( callbacks !=3D NULL &amp;&amp; callbacks-&gt;=
toolstack_restore !=3D NULL )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( callbacks-&gt;toolstack_restore(dom,<=
br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0buf2, len, callbac=
ks-&gt;data) &lt; 0 )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{<br></blockquote><div><br><br>Pagebuf() s=
houldnt be modifying any domain state until the entire<br>memory buffer is =
obtained, esp the device state. See below.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">

@@ -1542,7 +1570,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, u=
int32_t dom,<br>
<br>
 =A0 =A0 // DPRINTF(&quot;Buffered checkpoint\n&quot;);<br>
<br>
- =A0 =A0if ( pagebuf_get(xch, ctx, &amp;pagebuf, io_fd, dom) ) {<br>
+ =A0 =A0if ( pagebuf_get(xch, ctx, &amp;pagebuf, io_fd, dom, callbacks) ) =
{<br>
 =A0 =A0 =A0 =A0 PERROR(&quot;error when buffering batch, finishing&quot;);=
<br>
 =A0 =A0 =A0 =A0 goto finish;<br>
 =A0 =A0 }<br></blockquote><div><br>If there is an error in applying the to=
olstack state, then pagebuf_get returns -1 and<br>the rest of the code woul=
d still attempt to resume the domain, with possibly<br>inconsistent device =
model state.<br>

<br>Also, lets say there was no error in applying the toolstack state. If a=
 network<br>error occurs while receiving the next XC_SAVE_ID or so, then ag=
ain, the code following<br>the above snippet would attempt to resume the do=
main, with a memory state inconsistent<br>

with the device state.<br><br>The right place to call the callbacks-&gt;too=
lstack_restore would be after the finish_hvm:<br>label, where currently the=
 old QEMU device state is restored.<br></div></div><br><br>shriram<br>


--0015175cac0c2eab0204b7881f5d--


--===============7206758752035746371==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7206758752035746371==--


From xen-devel-bounces@lists.xensource.com Fri Jan 27 20:13:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 20: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 1RqsAY-00046r-3S; Fri, 27 Jan 2012 20:13: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 1RqsAW-00046d-Dt
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 20:13:08 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327695178!3974872!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3168 invoked from network); 27 Jan 2012 20:13:00 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-16.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 27 Jan 2012 20:13:00 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0RKCtMS007395
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Fri, 27 Jan 2012 12:12:56 -0800
Received: by bkar1 with SMTP id r1so3261662bka.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 12:12:53 -0800 (PST)
Received: by 10.204.148.84 with SMTP id o20mr3646886bkv.103.1327695173429;
	Fri, 27 Jan 2012 12:12:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Fri, 27 Jan 2012 12:12:13 -0800 (PST)
In-Reply-To: <1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
	<1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Fri, 27 Jan 2012 12:12:13 -0800
Message-ID: <CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: rshriram@cs.ubc.ca
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============7206758752035746371=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7206758752035746371==
Content-Type: multipart/alternative; boundary=0015175cac0c2eab0204b7881f5d

--0015175cac0c2eab0204b7881f5d
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 20, 2012 at 9:25 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> Introduce a new save_id to save/restore toolstack specific extra
> information.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxc/xc_domain_restore.c |   66
> +++++++++++++++++++++++++++-----------
>  tools/libxc/xc_domain_save.c    |   17 ++++++++++
>  tools/libxc/xenguest.h          |   23 +++++++++++++-
>  tools/libxc/xg_save_restore.h   |    1 +
>  tools/libxl/libxl_dom.c         |    2 +-
>  tools/xcutils/xc_restore.c      |    3 +-
>  6 files changed, 90 insertions(+), 22 deletions(-)
>
> diff --git a/tools/libxc/xc_domain_restore.c
> b/tools/libxc/xc_domain_restore.c
> index 14451d1..72b6d5b 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -702,7 +702,8 @@ static void pagebuf_free(pagebuf_t* buf)
>  }
>
>  static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
> -                           pagebuf_t* buf, int fd, uint32_t dom)
> +                           pagebuf_t* buf, int fd, uint32_t dom,
> +                           struct restore_callbacks* callbacks)
>  {
>     int count, countpages, oldcount, i;
>     void* ptmp;
> @@ -725,7 +726,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>     case XC_SAVE_ID_ENABLE_VERIFY_MODE:
>         DPRINTF("Entering page verify mode\n");
>         buf->verify = 1;
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_VCPU_INFO:
>         buf->new_ctxt_format = 1;
> @@ -736,7 +737,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             return -1;
>         }
>         // DPRINTF("Max VCPU ID: %d, vcpumap: %llx\n", buf->max_vcpu_id,
> buf->vcpumap);
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_HVM_IDENT_PT:
>         /* Skip padding 4 bytes then read the EPT identity PT location. */
> @@ -747,7 +748,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             return -1;
>         }
>         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_HVM_VM86_TSS:
>         /* Skip padding 4 bytes then read the vm86 TSS location. */
> @@ -758,7 +759,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             return -1;
>         }
>         // DPRINTF("VM86 TSS location: %llx\n", buf->vm86_tss);
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_TMEM:
>         DPRINTF("xc_domain_restore start tmem\n");
> @@ -766,14 +767,14 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             PERROR("error reading/restoring tmem");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_TMEM_EXTRA:
>         if ( xc_tmem_restore_extra(xch, dom, fd) ) {
>             PERROR("error reading/restoring tmem extra");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_TSC_INFO:
>     {
> @@ -787,7 +788,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             PERROR("error reading/restoring tsc info");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>     }
>
>     case XC_SAVE_ID_HVM_CONSOLE_PFN :
> @@ -799,12 +800,12 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             return -1;
>         }
>         // DPRINTF("console pfn location: %llx\n", buf->console_pfn);
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_LAST_CHECKPOINT:
>         ctx->last_checkpoint = 1;
>         // DPRINTF("last checkpoint indication received");
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:
>         /* Skip padding 4 bytes then read the acpi ioport location. */
> @@ -814,7 +815,7 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             PERROR("error read the acpi ioport location");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
>     case XC_SAVE_ID_HVM_VIRIDIAN:
>         /* Skip padding 4 bytes then read the acpi ioport location. */
> @@ -824,8 +825,33 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>             PERROR("error read the viridian flag");
>             return -1;
>         }
> -        return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);
>
> +    case XC_SAVE_ID_TOOLSTACK:
> +        {
> +            uint32_t len;
> +            uint8_t *buf2;
> +            RDEXACT(fd, &len, sizeof(len));
> +            buf2 = (uint8_t*) malloc(len);
> +            if ( buf2 == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, buf2, len);
> +            if ( callbacks != NULL && callbacks->toolstack_restore !=
> NULL )
> +            {
> +                if ( callbacks->toolstack_restore(dom,
> +                            buf2, len, callbacks->data) < 0 )
> +                {
>


Pagebuf() shouldnt be modifying any domain state until the entire
memory buffer is obtained, esp the device state. See below.

@@ -1542,7 +1570,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>
>     // DPRINTF("Buffered checkpoint\n");
>
> -    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
> +    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom, callbacks) ) {
>         PERROR("error when buffering batch, finishing");
>         goto finish;
>     }
>

If there is an error in applying the toolstack state, then pagebuf_get
returns -1 and
the rest of the code would still attempt to resume the domain, with possibly
inconsistent device model state.

Also, lets say there was no error in applying the toolstack state. If a
network
error occurs while receiving the next XC_SAVE_ID or so, then again, the
code following
the above snippet would attempt to resume the domain, with a memory state
inconsistent
with the device state.

The right place to call the callbacks->toolstack_restore would be after the
finish_hvm:
label, where currently the old QEMU device state is restored.


shriram

--0015175cac0c2eab0204b7881f5d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Jan 20, 2012 at 9:25 AM, Stefano Stabell=
ini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.co=
m">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

Introduce a new save_id to save/restore toolstack specific extra<br>
information.<br>
<br>
Signed-off-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellini@=
eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>
---<br>
=A0tools/libxc/xc_domain_restore.c | =A0 66 +++++++++++++++++++++++++++----=
-------<br>
=A0tools/libxc/xc_domain_save.c =A0 =A0| =A0 17 ++++++++++<br>
=A0tools/libxc/xenguest.h =A0 =A0 =A0 =A0 =A0| =A0 23 +++++++++++++-<br>
=A0tools/libxc/xg_save_restore.h =A0 | =A0 =A01 +<br>
=A0tools/libxl/libxl_dom.c =A0 =A0 =A0 =A0 | =A0 =A02 +-<br>
=A0tools/xcutils/xc_restore.c =A0 =A0 =A0| =A0 =A03 +-<br>
=A06 files changed, 90 insertions(+), 22 deletions(-)<br>
<br>
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restor=
e.c<br>
index 14451d1..72b6d5b 100644<br>
--- a/tools/libxc/xc_domain_restore.c<br>
+++ b/tools/libxc/xc_domain_restore.c<br>
@@ -702,7 +702,8 @@ static void pagebuf_free(pagebuf_t* buf)<br>
=A0}<br>
<br>
=A0static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,<b=
r>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf_t* buf, int f=
d, uint32_t dom)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf_t* buf, int f=
d, uint32_t dom,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct restore_callba=
cks* callbacks)<br>
=A0{<br>
 =A0 =A0 int count, countpages, oldcount, i;<br>
 =A0 =A0 void* ptmp;<br>
@@ -725,7 +726,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 case XC_SAVE_ID_ENABLE_VERIFY_MODE:<br>
 =A0 =A0 =A0 =A0 DPRINTF(&quot;Entering page verify mode\n&quot;);<br>
 =A0 =A0 =A0 =A0 buf-&gt;verify =3D 1;<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_VCPU_INFO:<br>
 =A0 =A0 =A0 =A0 buf-&gt;new_ctxt_format =3D 1;<br>
@@ -736,7 +737,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;Max VCPU ID: %d, vcpumap: %llx\n&quot;, b=
uf-&gt;max_vcpu_id, buf-&gt;vcpumap);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_IDENT_PT:<br>
 =A0 =A0 =A0 =A0 /* Skip padding 4 bytes then read the EPT identity PT loca=
tion. */<br>
@@ -747,7 +748,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;EPT identity map address: %llx\n&quot;, b=
uf-&gt;identpt);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_VM86_TSS:<br>
 =A0 =A0 =A0 =A0 /* Skip padding 4 bytes then read the vm86 TSS location. *=
/<br>
@@ -758,7 +759,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;VM86 TSS location: %llx\n&quot;, buf-&gt;=
vm86_tss);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_TMEM:<br>
 =A0 =A0 =A0 =A0 DPRINTF(&quot;xc_domain_restore start tmem\n&quot;);<br>
@@ -766,14 +767,14 @@ static int pagebuf_get_one(xc_interface *xch, struct =
restore_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error reading/restoring tmem&quot;);<=
br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_TMEM_EXTRA:<br>
 =A0 =A0 =A0 =A0 if ( xc_tmem_restore_extra(xch, dom, fd) ) {<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error reading/restoring tmem extra&qu=
ot;);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_TSC_INFO:<br>
 =A0 =A0 {<br>
@@ -787,7 +788,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error reading/restoring tsc info&quot=
;);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
 =A0 =A0 }<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_CONSOLE_PFN :<br>
@@ -799,12 +800,12 @@ static int pagebuf_get_one(xc_interface *xch, struct =
restore_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;console pfn location: %llx\n&quot;, buf-&=
gt;console_pfn);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_LAST_CHECKPOINT:<br>
 =A0 =A0 =A0 =A0 ctx-&gt;last_checkpoint =3D 1;<br>
 =A0 =A0 =A0 =A0 // DPRINTF(&quot;last checkpoint indication received&quot;=
);<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:<br>
 =A0 =A0 =A0 =A0 /* Skip padding 4 bytes then read the acpi ioport location=
. */<br>
@@ -814,7 +815,7 @@ static int pagebuf_get_one(xc_interface *xch, struct re=
store_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error read the acpi ioport location&q=
uot;);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
 =A0 =A0 case XC_SAVE_ID_HVM_VIRIDIAN:<br>
 =A0 =A0 =A0 =A0 /* Skip padding 4 bytes then read the acpi ioport location=
. */<br>
@@ -824,8 +825,33 @@ static int pagebuf_get_one(xc_interface *xch, struct r=
estore_ctx *ctx,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error read the viridian flag&quot;);<=
br>
 =A0 =A0 =A0 =A0 =A0 =A0 return -1;<br>
 =A0 =A0 =A0 =A0 }<br>
- =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
+ =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, callbacks);=
<br>
<br>
+ =A0 =A0case XC_SAVE_ID_TOOLSTACK:<br>
+ =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0uint32_t len;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0uint8_t *buf2;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, &amp;len, sizeof(len));<br>
+ =A0 =A0 =A0 =A0 =A0 =A0buf2 =3D (uint8_t*) malloc(len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( buf2 =3D=3D NULL )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error memory allocation&quot;=
);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0}<br>
+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, buf2, len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( callbacks !=3D NULL &amp;&amp; callbacks-&gt;=
toolstack_restore !=3D NULL )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ( callbacks-&gt;toolstack_restore(dom,<=
br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0buf2, len, callbac=
ks-&gt;data) &lt; 0 )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{<br></blockquote><div><br><br>Pagebuf() s=
houldnt be modifying any domain state until the entire<br>memory buffer is =
obtained, esp the device state. See below.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">

@@ -1542,7 +1570,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, u=
int32_t dom,<br>
<br>
 =A0 =A0 // DPRINTF(&quot;Buffered checkpoint\n&quot;);<br>
<br>
- =A0 =A0if ( pagebuf_get(xch, ctx, &amp;pagebuf, io_fd, dom) ) {<br>
+ =A0 =A0if ( pagebuf_get(xch, ctx, &amp;pagebuf, io_fd, dom, callbacks) ) =
{<br>
 =A0 =A0 =A0 =A0 PERROR(&quot;error when buffering batch, finishing&quot;);=
<br>
 =A0 =A0 =A0 =A0 goto finish;<br>
 =A0 =A0 }<br></blockquote><div><br>If there is an error in applying the to=
olstack state, then pagebuf_get returns -1 and<br>the rest of the code woul=
d still attempt to resume the domain, with possibly<br>inconsistent device =
model state.<br>

<br>Also, lets say there was no error in applying the toolstack state. If a=
 network<br>error occurs while receiving the next XC_SAVE_ID or so, then ag=
ain, the code following<br>the above snippet would attempt to resume the do=
main, with a memory state inconsistent<br>

with the device state.<br><br>The right place to call the callbacks-&gt;too=
lstack_restore would be after the finish_hvm:<br>label, where currently the=
 old QEMU device state is restored.<br></div></div><br><br>shriram<br>


--0015175cac0c2eab0204b7881f5d--


--===============7206758752035746371==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7206758752035746371==--


From xen-devel-bounces@lists.xensource.com Fri Jan 27 20:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 20: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 1Rqsat-0004Y4-Mt; Fri, 27 Jan 2012 20:40:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqsas-0004Xz-AH
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 20:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327696815!3976673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12375 invoked from network); 27 Jan 2012 20:40:16 -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;
	27 Jan 2012 20:40:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="10340897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 20: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; Fri, 27 Jan 2012 20:40: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 1Rqsak-0006Q9-N4;
	Fri, 27 Jan 2012 20:40:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rqsak-0000yX-Gg;
	Fri, 27 Jan 2012 20:40:14 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11644-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 20:40:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11644: 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 11644 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11644/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10764

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 20:40:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 20: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 1Rqsat-0004Y4-Mt; Fri, 27 Jan 2012 20:40:23 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqsas-0004Xz-AH
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 20:40:22 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327696815!3976673!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTQ0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12375 invoked from network); 27 Jan 2012 20:40:16 -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;
	27 Jan 2012 20:40:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,582,1320624000"; d="scan'208";a="10340897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	27 Jan 2012 20: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; Fri, 27 Jan 2012 20:40: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 1Rqsak-0006Q9-N4;
	Fri, 27 Jan 2012 20:40:14 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rqsak-0000yX-Gg;
	Fri, 27 Jan 2012 20:40:14 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11644-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Fri, 27 Jan 2012 20:40:14 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11644: 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 11644 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11644/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764
 test-amd64-amd64-win          7 windows-install           fail REGR. vs. 10764

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 21:16:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 21: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 1Rqt8p-0004ye-JE; Fri, 27 Jan 2012 21:15: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 1Rqt8o-0004yZ-Hd
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 21:15:26 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327698919!12675931!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODMzNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30531 invoked from network); 27 Jan 2012 21:15:19 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-4.tower-182.messagelabs.com with SMTP;
	27 Jan 2012 21:15:19 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 32D3F30006C;
	Fri, 27 Jan 2012 13:15:18 -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=XmeqJbU8Rx12dpefRSj02B
	pcHq9nPYeTxSjTmeCv9uJbq6+Rn8Apx8RlIYf74A+qTIpbyvgl1ML3XSpj3Pnfed
	il4H4ehyfGh5ManvgctqiNLV79o3xiCi4JGUKDEDdwT1k4IjLd4F7rNjWTpWekxc
	jMDA1K3qiVD+Zb7T4EOzo=
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=hL6atke/7HQH
	AjaOkqvd6P3x82I=; b=WaqcjX6JbWm8Xe089Jkp/NDdIJ9Scok3TvrRCrgTWT5V
	HDzdgpdGK5/n6ue8iittarDL6/VQQ3OJEEvOAWofNcUcSarM6NGdDNqdsq5UcOE4
	RrppBdJFs3IYdO7Mk/2vH14eXStviS84IN6MRNZjKJu2QdxBVy7SDwM5xs+3yWo=
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 89081300064; 
	Fri, 27 Jan 2012 13:15:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7d62108a8936266c8f80cad45c0070e0f0ba84a3
Message-Id: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Jan 2012 16:21:02 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 Config.mk            |   1 +
 tools/Makefile       |   1 +
 tools/tests/Makefile |  20 ++++++++++++++++++++
 3 files changed, 22 insertions(+), 0 deletions(-)


Build tests as part of the tools build.

It is enabled with CONFIG_TESTS in Config.mk

Currently disabled build of tests/regressions and tests/xen-access (in 32 bit
mode) as they fail.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2c6ff08e8b5b -r 7d62108a8936 Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -240,6 +240,7 @@ OCAML_TOOLS        ?= y
 CONFIG_MINITERM    ?= n
 CONFIG_LOMOUNT     ?= n
 CONFIG_SYSTEM_LIBAIO ?= y
+CONFIG_TESTS       ?= y
 
 ifeq ($(OCAML_TOOLS),y)
 OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
diff -r 2c6ff08e8b5b -r 7d62108a8936 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -45,6 +45,7 @@ SUBDIRS-y += remus
 SUBDIRS-$(CONFIG_X86) += xenpaging
 SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
 SUBDIRS-$(CONFIG_X86) += debugger/kdd
+SUBDIRS-$(CONFIG_TESTS) += tests
 
 # These don't cross-compile
 ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
diff -r 2c6ff08e8b5b -r 7d62108a8936 tools/tests/Makefile
--- /dev/null
+++ b/tools/tests/Makefile
@@ -0,0 +1,20 @@
+XEN_ROOT = $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS  += $(CFLAGS_libxenctrl)
+LDLIBS += $(LDLIBS_libxenctrl)
+
+SUBDIRS-y :=
+SUBDIRS-y += mce-test
+SUBDIRS-y += mem-sharing
+ifeq ($(XEN_TARGET_ARCH),__fixme__)
+SUBDIRS-y += regression
+endif
+SUBDIRS-y += x86_emulator
+ifneq ($(XEN_TARGET_ARCH),x86_32)
+SUBDIRS-y += xen-access
+endif
+
+.PHONY: all clean install
+all clean install: %: subdirs-%
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 21:16:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 21: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 1Rqt8p-0004ye-JE; Fri, 27 Jan 2012 21:15: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 1Rqt8o-0004yZ-Hd
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 21:15:26 +0000
X-Env-Sender: andres@lagarcavilla.org
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327698919!12675931!1
X-Originating-IP: [208.97.132.83]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA4Ljk3LjEzMi44MyA9PiAxODMzNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30531 invoked from network); 27 Jan 2012 21:15:19 -0000
Received: from caiajhbdcaid.dreamhost.com (HELO homiemail-a21.g.dreamhost.com)
	(208.97.132.83) by server-4.tower-182.messagelabs.com with SMTP;
	27 Jan 2012 21:15:19 -0000
Received: from homiemail-a21.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a21.g.dreamhost.com (Postfix) with ESMTP id 32D3F30006C;
	Fri, 27 Jan 2012 13:15:18 -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=XmeqJbU8Rx12dpefRSj02B
	pcHq9nPYeTxSjTmeCv9uJbq6+Rn8Apx8RlIYf74A+qTIpbyvgl1ML3XSpj3Pnfed
	il4H4ehyfGh5ManvgctqiNLV79o3xiCi4JGUKDEDdwT1k4IjLd4F7rNjWTpWekxc
	jMDA1K3qiVD+Zb7T4EOzo=
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=hL6atke/7HQH
	AjaOkqvd6P3x82I=; b=WaqcjX6JbWm8Xe089Jkp/NDdIJ9Scok3TvrRCrgTWT5V
	HDzdgpdGK5/n6ue8iittarDL6/VQQ3OJEEvOAWofNcUcSarM6NGdDNqdsq5UcOE4
	RrppBdJFs3IYdO7Mk/2vH14eXStviS84IN6MRNZjKJu2QdxBVy7SDwM5xs+3yWo=
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 89081300064; 
	Fri, 27 Jan 2012 13:15:17 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 7d62108a8936266c8f80cad45c0070e0f0ba84a3
Message-Id: <7d62108a8936266c8f80.1327699262@xdev.gridcentric.ca>
User-Agent: Mercurial-patchbomb/1.8.4
Date: Fri, 27 Jan 2012 16:21:02 -0500
From: Andres Lagar-Cavilla <andres@lagarcavilla.org>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@citrix.com, andres@gridcentric.ca, ian.campbell@citrix.com,
	adin@gridcentric.ca
Subject: [Xen-devel] [PATCH] Tools: build tests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

 Config.mk            |   1 +
 tools/Makefile       |   1 +
 tools/tests/Makefile |  20 ++++++++++++++++++++
 3 files changed, 22 insertions(+), 0 deletions(-)


Build tests as part of the tools build.

It is enabled with CONFIG_TESTS in Config.mk

Currently disabled build of tests/regressions and tests/xen-access (in 32 bit
mode) as they fail.

Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>

diff -r 2c6ff08e8b5b -r 7d62108a8936 Config.mk
--- a/Config.mk
+++ b/Config.mk
@@ -240,6 +240,7 @@ OCAML_TOOLS        ?= y
 CONFIG_MINITERM    ?= n
 CONFIG_LOMOUNT     ?= n
 CONFIG_SYSTEM_LIBAIO ?= y
+CONFIG_TESTS       ?= y
 
 ifeq ($(OCAML_TOOLS),y)
 OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
diff -r 2c6ff08e8b5b -r 7d62108a8936 tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -45,6 +45,7 @@ SUBDIRS-y += remus
 SUBDIRS-$(CONFIG_X86) += xenpaging
 SUBDIRS-$(CONFIG_X86) += debugger/gdbsx
 SUBDIRS-$(CONFIG_X86) += debugger/kdd
+SUBDIRS-$(CONFIG_TESTS) += tests
 
 # These don't cross-compile
 ifeq ($(XEN_COMPILE_ARCH),$(XEN_TARGET_ARCH))
diff -r 2c6ff08e8b5b -r 7d62108a8936 tools/tests/Makefile
--- /dev/null
+++ b/tools/tests/Makefile
@@ -0,0 +1,20 @@
+XEN_ROOT = $(CURDIR)/../..
+include $(XEN_ROOT)/tools/Rules.mk
+
+CFLAGS  += $(CFLAGS_libxenctrl)
+LDLIBS += $(LDLIBS_libxenctrl)
+
+SUBDIRS-y :=
+SUBDIRS-y += mce-test
+SUBDIRS-y += mem-sharing
+ifeq ($(XEN_TARGET_ARCH),__fixme__)
+SUBDIRS-y += regression
+endif
+SUBDIRS-y += x86_emulator
+ifneq ($(XEN_TARGET_ARCH),x86_32)
+SUBDIRS-y += xen-access
+endif
+
+.PHONY: all clean install
+all clean install: %: subdirs-%
+

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5W-0005kA-UY; Fri, 27 Jan 2012 22:16:06 +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 1Rqu5U-0005hC-GG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327702557!12154838!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13156 invoked from network); 27 Jan 2012 22:15:57 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-13.tower-182.messagelabs.com with SMTP;
	27 Jan 2012 22:15:57 -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
	q0RMFtgt010111; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhZ026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:40 -0500
Message-Id: <1327702543-25211-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 21/24] stubdom: enable xenstored 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>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/Makefile     |    3 ++-
 stubdom/Makefile            |   29 ++++++++++++++++++++++++++---
 stubdom/xenstore-minios.cfg |    7 +++++++
 3 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 stubdom/xenstore-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index 583f85b..c425f76 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y
 CONFIG_KBDFRONT ?= y
 CONFIG_CONSFRONT ?= y
 CONFIG_XENBUS ?= y
+CONFIG_LWIP ?= $(lwip)
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
@@ -123,7 +124,7 @@ links: include/list.h $(ARCH_LINKS)
 arch_lib:
 	$(MAKE) --directory=$(TARGET_ARCH_DIR) OBJ_DIR=$(OBJ_DIR)/$(TARGET_ARCH_DIR) || exit 1;
 
-ifeq ($(lwip),y)
+ifeq ($(CONFIG_LWIP),y)
 # lwIP library
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
diff --git a/stubdom/Makefile b/stubdom/Makefile
index d4da2bb..b63041e 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg
new file mode 100644
index 0000000..6a09cce
--- /dev/null
+++ b/stubdom/xenstore-minios.cfg
@@ -0,0 +1,7 @@
+CONFIG_BLKFRONT=n
+CONFIG_NETFRONT=n
+CONFIG_FBFRONT=n
+CONFIG_KBDFRONT=n
+CONFIG_CONSFRONT=n
+CONFIG_XENBUS=n
+CONFIG_LWIP=n
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5W-0005kA-UY; Fri, 27 Jan 2012 22:16:06 +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 1Rqu5U-0005hC-GG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327702557!12154838!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13156 invoked from network); 27 Jan 2012 22:15:57 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-13.tower-182.messagelabs.com with SMTP;
	27 Jan 2012 22:15:57 -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
	q0RMFtgt010111; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhZ026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:40 -0500
Message-Id: <1327702543-25211-22-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 21/24] stubdom: enable xenstored 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>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/Makefile     |    3 ++-
 stubdom/Makefile            |   29 ++++++++++++++++++++++++++---
 stubdom/xenstore-minios.cfg |    7 +++++++
 3 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 stubdom/xenstore-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index 583f85b..c425f76 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -27,6 +27,7 @@ CONFIG_FBFRONT ?= y
 CONFIG_KBDFRONT ?= y
 CONFIG_CONSFRONT ?= y
 CONFIG_XENBUS ?= y
+CONFIG_LWIP ?= $(lwip)
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
@@ -123,7 +124,7 @@ links: include/list.h $(ARCH_LINKS)
 arch_lib:
 	$(MAKE) --directory=$(TARGET_ARCH_DIR) OBJ_DIR=$(OBJ_DIR)/$(TARGET_ARCH_DIR) || exit 1;
 
-ifeq ($(lwip),y)
+ifeq ($(CONFIG_LWIP),y)
 # lwIP library
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
diff --git a/stubdom/Makefile b/stubdom/Makefile
index d4da2bb..b63041e 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -74,14 +74,14 @@ TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
 
-TARGETS=ioemu c caml grub
+TARGETS=ioemu c caml grub xenstore
 
 CROSS_MAKE := $(MAKE) DESTDIR=
 
 .PHONY: all
 all: build
 ifeq ($(STUBDOM_SUPPORTED),1)
-build: genpath ioemu-stubdom c-stubdom pv-grub
+build: genpath ioemu-stubdom c-stubdom pv-grub xenstore-stubdom
 else
 build: genpath
 endif
@@ -262,6 +262,11 @@ mk-headers-$(XEN_TARGET_ARCH): ioemu/linkfarm.stamp
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.c . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/*.h . && \
 	  ln -sf $(XEN_ROOT)/tools/libxc/$(XEN_TARGET_ARCH)/Makefile . )
+	mkdir -p xenstore
+	[ -h xenstore/Makefile ] || ( cd xenstore && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.c . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/*.h . && \
+	  ln -sf $(XEN_ROOT)/tools/xenstore/Makefile . )
 	$(CROSS_MAKE) -C $(MINI_OS) links
 	touch mk-headers-$(XEN_TARGET_ARCH)
 
@@ -334,6 +339,14 @@ grub: grub-upstream $(CROSS_ROOT)
 	mkdir -p grub-$(XEN_TARGET_ARCH)
 	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ OBJ_DIR=$(CURDIR)/grub-$(XEN_TARGET_ARCH)
 
+##########
+# xenstore
+##########
+
+.PHONY: xenstore
+xenstore: $(CROSS_ROOT)
+	CPPFLAGS="$(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" $(CROSS_MAKE) -C $@ xenstored.a CONFIG_STUBDOM=y
+
 ########
 # minios
 ########
@@ -355,12 +368,16 @@ c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
 	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
+.PHONY: xenstore-stubdom
+xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore libxc xenstore
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/xenstore-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/xenstore/xenstored.a
+
 #########
 # install
 #########
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: genpath install-readme install-ioemu install-grub
+install: genpath install-readme install-ioemu install-grub install-xenstore
 else
 install: genpath
 endif
@@ -379,6 +396,10 @@ install-grub: pv-grub
 	$(INSTALL_DIR) "$(DESTDIR)$(XENFIRMWAREDIR)"
 	$(INSTALL_DATA) mini-os-$(XEN_TARGET_ARCH)-grub/mini-os.gz "$(DESTDIR)$(XENFIRMWAREDIR)/pv-grub-$(XEN_TARGET_ARCH).gz"
 
+install-xenstore: xenstore-stubdom
+	$(INSTALL_DIR) "$(DESTDIR)/usr/lib/xen/boot"
+	$(INSTALL_PROG) mini-os-$(XEN_TARGET_ARCH)-xenstore/mini-os.gz "$(DESTDIR)/usr/lib/xen/boot/xenstore-stubdom.gz"
+
 #######
 # clean
 #######
@@ -390,12 +411,14 @@ clean:
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-c
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-caml
 	rm -fr mini-os-$(XEN_TARGET_ARCH)-grub
+	rm -fr mini-os-$(XEN_TARGET_ARCH)-xenstore
 	$(CROSS_MAKE) -C caml clean
 	$(CROSS_MAKE) -C c clean
 	rm -fr grub-$(XEN_TARGET_ARCH)
 	rm -f $(STUBDOMPATH)
 	[ ! -d libxc-$(XEN_TARGET_ARCH) ] || $(CROSS_MAKE) -C libxc-$(XEN_TARGET_ARCH) clean
 	-[ ! -d ioemu ] || $(CROSS_MAKE) -C ioemu clean
+	-[ ! -d xenstore ] || $(CROSS_MAKE) -C xenstore clean
 
 # clean the cross-compilation result
 .PHONY: crossclean
diff --git a/stubdom/xenstore-minios.cfg b/stubdom/xenstore-minios.cfg
new file mode 100644
index 0000000..6a09cce
--- /dev/null
+++ b/stubdom/xenstore-minios.cfg
@@ -0,0 +1,7 @@
+CONFIG_BLKFRONT=n
+CONFIG_NETFRONT=n
+CONFIG_FBFRONT=n
+CONFIG_KBDFRONT=n
+CONFIG_CONSFRONT=n
+CONFIG_XENBUS=n
+CONFIG_LWIP=n
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5U-0005iW-Fm; Fri, 27 Jan 2012 22:16:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5S-0005hL-Oa
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327702508!52048436!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23014 invoked from network); 27 Jan 2012 22:15:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:09 -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
	q0RMFtgt010107; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhW026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:37 -0500
Message-Id: <1327702543-25211-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/24] xenstored: add --internal-db flag
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c |   20 ++++++++++++++------
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index c1ee932..4b12cf2 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -63,7 +63,7 @@ static bool recovery = true;
 static bool remove_local = true;
 static int reopen_log_pipe[2];
 static char *tracefile = NULL;
-static TDB_CONTEXT *tdb_ctx;
+static TDB_CONTEXT *tdb_ctx = NULL;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
@@ -92,8 +92,9 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
-	if (rename(newname, xs_daemon_tdb()) != 0)
-		return false;
+	if (!(tdb_ctx->flags & TDB_INTERNAL))
+		if (rename(newname, xs_daemon_tdb()) != 0)
+			return false;
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -1410,7 +1411,7 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
-#define TDB_FLAGS 0
+static int tdb_flags;
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1435,7 +1436,9 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
-	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+
+	if (!(tdb_flags & TDB_INTERNAL))
+		tdb_ctx = tdb_open(tdbname, 0, tdb_flags, O_RDWR, 0);
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1466,7 +1469,7 @@ static void setup_structure(void)
 		talloc_free(tlocal);
 	}
 	else {
-		tdb_ctx = tdb_open(tdbname, 7919, TDB_FLAGS, O_RDWR|O_CREAT,
+		tdb_ctx = tdb_open(tdbname, 7919, tdb_flags, O_RDWR|O_CREAT,
 				   0640);
 		if (!tdb_ctx)
 			barf_perror("Could not create tdb file %s", tdbname);
@@ -1783,6 +1786,7 @@ static void usage(void)
 "  --transaction <nb>  limit the number of transaction allowed per domain,\n"
 "  --no-recovery       to request that no recovery should be attempted when\n"
 "                      the store is corrupted (debug only),\n"
+"  --internal-db       store database in memory, not on disk\n"
 "  --preserve-local    to request that /local is preserved on start-up,\n"
 "  --verbose           to request verbose execution.\n");
 }
@@ -1800,6 +1804,7 @@ static struct option options[] = {
 	{ "transaction", 1, NULL, 't' },
 	{ "no-recovery", 0, NULL, 'R' },
 	{ "preserve-local", 0, NULL, 'L' },
+	{ "internal-db", 0, NULL, 'I' },
 	{ "verbose", 0, NULL, 'V' },
 	{ "watch-nb", 1, NULL, 'W' },
 	{ NULL, 0, NULL, 0 } };
@@ -1853,6 +1858,9 @@ int main(int argc, char *argv[])
 		case 'T':
 			tracefile = optarg;
 			break;
+		case 'I':
+			tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
+			break;
 		case 'V':
 			verbose = true;
 			break;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5U-0005iW-Fm; Fri, 27 Jan 2012 22:16:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5S-0005hL-Oa
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327702508!52048436!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23014 invoked from network); 27 Jan 2012 22:15:09 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:09 -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
	q0RMFtgt010107; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhW026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:37 -0500
Message-Id: <1327702543-25211-19-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 18/24] xenstored: add --internal-db flag
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c |   20 ++++++++++++++------
 1 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index c1ee932..4b12cf2 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -63,7 +63,7 @@ static bool recovery = true;
 static bool remove_local = true;
 static int reopen_log_pipe[2];
 static char *tracefile = NULL;
-static TDB_CONTEXT *tdb_ctx;
+static TDB_CONTEXT *tdb_ctx = NULL;
 
 static void corrupt(struct connection *conn, const char *fmt, ...);
 static void check_store(void);
@@ -92,8 +92,9 @@ TDB_CONTEXT *tdb_context(struct connection *conn)
 
 bool replace_tdb(const char *newname, TDB_CONTEXT *newtdb)
 {
-	if (rename(newname, xs_daemon_tdb()) != 0)
-		return false;
+	if (!(tdb_ctx->flags & TDB_INTERNAL))
+		if (rename(newname, xs_daemon_tdb()) != 0)
+			return false;
 	tdb_close(tdb_ctx);
 	tdb_ctx = talloc_steal(talloc_autofree_context(), newtdb);
 	return true;
@@ -1410,7 +1411,7 @@ static void accept_connection(int sock, bool canwrite)
 }
 #endif
 
-#define TDB_FLAGS 0
+static int tdb_flags;
 
 /* We create initial nodes manually. */
 static void manual_node(const char *name, const char *child)
@@ -1435,7 +1436,9 @@ static void setup_structure(void)
 {
 	char *tdbname;
 	tdbname = talloc_strdup(talloc_autofree_context(), xs_daemon_tdb());
-	tdb_ctx = tdb_open(tdbname, 0, TDB_FLAGS, O_RDWR, 0);
+
+	if (!(tdb_flags & TDB_INTERNAL))
+		tdb_ctx = tdb_open(tdbname, 0, tdb_flags, O_RDWR, 0);
 
 	if (tdb_ctx) {
 		/* XXX When we make xenstored able to restart, this will have
@@ -1466,7 +1469,7 @@ static void setup_structure(void)
 		talloc_free(tlocal);
 	}
 	else {
-		tdb_ctx = tdb_open(tdbname, 7919, TDB_FLAGS, O_RDWR|O_CREAT,
+		tdb_ctx = tdb_open(tdbname, 7919, tdb_flags, O_RDWR|O_CREAT,
 				   0640);
 		if (!tdb_ctx)
 			barf_perror("Could not create tdb file %s", tdbname);
@@ -1783,6 +1786,7 @@ static void usage(void)
 "  --transaction <nb>  limit the number of transaction allowed per domain,\n"
 "  --no-recovery       to request that no recovery should be attempted when\n"
 "                      the store is corrupted (debug only),\n"
+"  --internal-db       store database in memory, not on disk\n"
 "  --preserve-local    to request that /local is preserved on start-up,\n"
 "  --verbose           to request verbose execution.\n");
 }
@@ -1800,6 +1804,7 @@ static struct option options[] = {
 	{ "transaction", 1, NULL, 't' },
 	{ "no-recovery", 0, NULL, 'R' },
 	{ "preserve-local", 0, NULL, 'L' },
+	{ "internal-db", 0, NULL, 'I' },
 	{ "verbose", 0, NULL, 'V' },
 	{ "watch-nb", 1, NULL, 'W' },
 	{ NULL, 0, NULL, 0 } };
@@ -1853,6 +1858,9 @@ int main(int argc, char *argv[])
 		case 'T':
 			tracefile = optarg;
 			break;
+		case 'I':
+			tdb_flags = TDB_INTERNAL|TDB_NOLOCK;
+			break;
 		case 'V':
 			verbose = true;
 			break;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5X-0005kU-Cb; Fri, 27 Jan 2012 22:16:07 +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 1Rqu5U-0005hE-HG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327702557!8667478!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10386 invoked from network); 27 Jan 2012 22:15:58 -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;
	27 Jan 2012 22:15:58 -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
	q0RMFtpV014547; Fri, 27 Jan 2012 22:15:55 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 q0RMFrha026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:41 -0500
Message-Id: <1327702543-25211-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 22/24] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 40e2fc0..66584f5 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -462,7 +462,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -800,11 +800,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 558e5cb..fa9c8fe 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -354,7 +354,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -418,7 +418,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -470,7 +470,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -507,7 +507,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5Z-0005mf-Mz; Fri, 27 Jan 2012 22:16:09 +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 1Rqu5U-0005hQ-SZ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327702557!12668120!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12220 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-182.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFtgt010108; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhX026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:38 -0500
Message-Id: <1327702543-25211-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/Makefile           |   14 ++++-
 tools/xenstore/utils.h            |    2 +
 tools/xenstore/xenstored_core.c   |   88 ++++-----------------------------
 tools/xenstore/xenstored_core.h   |   12 +++++
 tools/xenstore/xenstored_domain.c |    2 +-
 tools/xenstore/xenstored_minios.c |   60 ++++++++++++++++++++++
 tools/xenstore/xenstored_posix.c  |   99 +++++++++++++++++++++++++++++++++++++
 7 files changed, 195 insertions(+), 82 deletions(-)
 create mode 100644 tools/xenstore/xenstored_minios.c
 create mode 100644 tools/xenstore/xenstored_posix.c

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..e510b4f 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -13,9 +13,10 @@ CLIENTS += xenstore-write xenstore-ls xenstore-watch
 
 XENSTORED_OBJS = xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o
 
-XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o
-XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_probes.o
-XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o
+XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o xenstored_posix.o
+XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_posix.o xenstored_probes.o
+XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o xenstored_posix.o
+XENSTORED_OBJS_$(CONFIG_MiniOS) = xenstored_minios.o
 
 XENSTORED_OBJS += $(XENSTORED_OBJS_y)
 
@@ -28,6 +29,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -49,6 +54,9 @@ endif
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4b12cf2..a762db7 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -224,7 +224,6 @@ static void reopen_log(void)
 	}
 }
 
-
 static bool write_messages(struct connection *conn)
 {
 	int ret;
@@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 		set_fd(sock, inset, &max);
 	if (ro_sock != -1)
 		set_fd(ro_sock, inset, &max);
-	set_fd(reopen_log_pipe[0], inset, &max);
+	if (reopen_log_pipe[0] != -1)
+		set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1664,53 +1664,6 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
-static void write_pidfile(const char *pidfile)
-{
-	char buf[100];
-	int len;
-	int fd;
-
-	fd = open(pidfile, O_RDWR | O_CREAT, 0600);
-	if (fd == -1)
-		barf_perror("Opening pid file %s", pidfile);
-
-	/* We exit silently if daemon already running. */
-	if (lockf(fd, F_TLOCK, 0) == -1)
-		exit(0);
-
-	len = snprintf(buf, sizeof(buf), "%ld\n", (long)getpid());
-	if (write(fd, buf, len) != len)
-		barf_perror("Writing pid file %s", pidfile);
-}
-
-/* Stevens. */
-static void daemonize(void)
-{
-	pid_t pid;
-
-	/* Separate from our parent via fork, so init inherits us. */
-	if ((pid = fork()) < 0)
-		barf_perror("Failed to fork daemon");
-	if (pid != 0)
-		exit(0);
-
-	/* Session leader so ^C doesn't whack us. */
-	setsid();
-
-	/* Let session leader exit so child cannot regain CTTY */
-	if ((pid = fork()) < 0)
-		barf_perror("Failed to fork daemon");
-	if (pid != 0)
-		exit(0);
-
-	/* Move off any mount points we might be in. */
-	if (chdir("/") == -1)
-		barf_perror("Failed to chdir");
-
-	/* Discard our parent's old-fashioned umask prejudices. */
-	umask(0);
-}
-
 #ifdef NO_SOCKETS
 static void init_sockets(int **psock, int **pro_sock)
 {
@@ -1874,20 +1827,10 @@ int main(int argc, char *argv[])
 
 	reopen_log();
 
-	/* make sure xenstored directory exists */
-	if (mkdir(xs_daemon_rundir(), 0755)) {
-		if (errno != EEXIST) {
-			perror("error: mkdir daemon rundir");
-			exit(-1);
-		}
-	}
-
-	if (mkdir(xs_daemon_rootdir(), 0755)) {
-		if (errno != EEXIST) {
-			perror("error: mkdir daemon rootdir");
-			exit(-1);
-		}
-	}
+	/* make sure xenstored directories exist */
+	/* Errors ignored here, will be reported when we open files */
+	mkdir(xs_daemon_rundir(), 0755);
+	mkdir(xs_daemon_rootdir(), 0755);
 
 	if (dofork) {
 		openlog("xenstored", 0, LOG_DAEMON);
@@ -1904,10 +1847,7 @@ int main(int argc, char *argv[])
 	signal(SIGPIPE, SIG_IGN);
 
 	init_sockets(&sock, &ro_sock);
-
-	if (pipe(reopen_log_pipe)) {
-		barf_perror("pipe");
-	}
+	init_pipe(reopen_log_pipe);
 
 	/* Setup the database */
 	setup_structure();
@@ -1925,16 +1865,8 @@ int main(int argc, char *argv[])
 	}
 
 	/* redirect to /dev/null now we're ready to accept connections */
-	if (dofork) {
-		int devnull = open("/dev/null", O_RDWR);
-		if (devnull == -1)
-			barf_perror("Could not open /dev/null\n");
-		dup2(devnull, STDIN_FILENO);
-		dup2(devnull, STDOUT_FILENO);
-		dup2(devnull, STDERR_FILENO);
-		close(devnull);
-		xprintf = trace;
-	}
+	if (dofork)
+		finish_daemonize();
 
 	signal(SIGHUP, trigger_reopen_log);
 
@@ -1957,7 +1889,7 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
-		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
+		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..f074955 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -171,6 +171,7 @@ extern int event_fd;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
+void unmap_xenbus(void *interface);
 
 /* Return the event channel used by xenbus. */
 evtchn_port_t xenbus_evtchn(void);
@@ -178,6 +179,17 @@ evtchn_port_t xenbus_evtchn(void);
 /* Tell the kernel xenstored is running. */
 void xenbus_notify_running(void);
 
+/* Write out the pidfile */
+void write_pidfile(const char *pidfile);
+
+/* Fork but do not close terminal FDs */
+void daemonize(void);
+/* Close stdin/stdout/stderr to complete daemonize */
+void finish_daemonize(void);
+
+/* Open a pipe for signal handling */
+void init_pipe(int reopen_log_pipe[2]);
+
 #endif /* _XENSTORED_CORE_H */
 
 /*
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index c521e52..6206961 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -200,7 +200,7 @@ static int destroy_domain(void *_domain)
 		/* Domain 0 was mapped by dom0_init, so it must be unmapped
 		   using munmap() and not the grant unmap call. */
 		if (domain->domid == 0)
-			munmap(domain->interface, getpagesize());
+			unmap_xenbus(domain->interface);
 		else
 			unmap_interface(domain->interface);
 	}
diff --git a/tools/xenstore/xenstored_minios.c b/tools/xenstore/xenstored_minios.c
new file mode 100644
index 0000000..c8700ba
--- /dev/null
+++ b/tools/xenstore/xenstored_minios.c
@@ -0,0 +1,60 @@
+/* 
+    Simple prototype Xen Store Daemon providing simple tree-like database.
+    Copyright (C) 2005 Rusty Russell IBM 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
+*/
+#include <sys/types.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include "xenstored_core.h"
+#include <xen/grant_table.h>
+
+void write_pidfile(const char *pidfile)
+{
+}
+
+void daemonize(void)
+{
+}
+
+void finish_daemonize(void)
+{
+}
+
+void init_pipe(int reopen_log_pipe[2])
+{
+	reopen_log_pipe[0] = -1;
+	reopen_log_pipe[1] = -1;
+}
+
+void xenbus_notify_running(void)
+{
+}
+
+evtchn_port_t xenbus_evtchn(void)
+{
+	return -1;
+}
+
+void *xenbus_map(void)
+{
+	return NULL;
+}
+
+void unmap_xenbus(void *interface)
+{
+}
+
diff --git a/tools/xenstore/xenstored_posix.c b/tools/xenstore/xenstored_posix.c
new file mode 100644
index 0000000..25bdf74
--- /dev/null
+++ b/tools/xenstore/xenstored_posix.c
@@ -0,0 +1,99 @@
+/* 
+    Simple prototype Xen Store Daemon providing simple tree-like database.
+    Copyright (C) 2005 Rusty Russell IBM 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
+*/
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <stdlib.h>
+#include <sys/mman.h>
+
+#include "utils.h"
+#include "xenstored_core.h"
+
+void write_pidfile(const char *pidfile)
+{
+	char buf[100];
+	int len;
+	int fd;
+
+	fd = open(pidfile, O_RDWR | O_CREAT, 0600);
+	if (fd == -1)
+		barf_perror("Opening pid file %s", pidfile);
+
+	/* We exit silently if daemon already running. */
+	if (lockf(fd, F_TLOCK, 0) == -1)
+		exit(0);
+
+	len = snprintf(buf, sizeof(buf), "%ld\n", (long)getpid());
+	if (write(fd, buf, len) != len)
+		barf_perror("Writing pid file %s", pidfile);
+}
+
+/* Stevens. */
+void daemonize(void)
+{
+	pid_t pid;
+
+	/* Separate from our parent via fork, so init inherits us. */
+	if ((pid = fork()) < 0)
+		barf_perror("Failed to fork daemon");
+	if (pid != 0)
+		exit(0);
+
+	/* Session leader so ^C doesn't whack us. */
+	setsid();
+
+	/* Let session leader exit so child cannot regain CTTY */
+	if ((pid = fork()) < 0)
+		barf_perror("Failed to fork daemon");
+	if (pid != 0)
+		exit(0);
+
+	/* Move off any mount points we might be in. */
+	if (chdir("/") == -1)
+		barf_perror("Failed to chdir");
+
+	/* Discard our parent's old-fashioned umask prejudices. */
+	umask(0);
+}
+
+void finish_daemonize(void)
+{
+	int devnull = open("/dev/null", O_RDWR);
+	if (devnull == -1)
+		barf_perror("Could not open /dev/null\n");
+	dup2(devnull, STDIN_FILENO);
+	dup2(devnull, STDOUT_FILENO);
+	dup2(devnull, STDERR_FILENO);
+	close(devnull);
+	xprintf = trace;
+}
+
+void init_pipe(int reopen_log_pipe[2])
+{
+	if (pipe(reopen_log_pipe)) {
+		barf_perror("pipe");
+	}
+}
+
+void unmap_xenbus(void *interface)
+{
+	munmap(interface, getpagesize());
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5Y-0005lr-UI; Fri, 27 Jan 2012 22:16:08 +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 1Rqu5U-0005hO-P6
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327702557!10164912!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13004 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-21.messagelabs.com with SMTP;
	27 Jan 2012 22:15:58 -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
	q0RMFtpV014541; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhU026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:35 -0500
Message-Id: <1327702543-25211-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/24] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Add option for compiling xenstored without unix sockets to support
running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c |   28 +++++++++++++++++++++++-----
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0e7d43f..c1ee932 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
-	set_fd(sock,               inset, &max);
-	set_fd(ro_sock,            inset, &max);
+	if (sock != -1)
+		set_fd(sock, inset, &max);
+	if (ro_sock != -1)
+		set_fd(ro_sock, inset, &max);
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -1345,6 +1349,11 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifdef NO_SOCKETS
+static void accept_connection(int sock, bool canwrite)
+{
+}
+#else
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1399,6 +1408,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1698,6 +1708,13 @@ static void daemonize(void)
 	umask(0);
 }
 
+#ifdef NO_SOCKETS
+static void init_sockets(int **psock, int **pro_sock)
+{
+	static int minus_one = -1;
+	*psock = *pro_sock = &minus_one;
+}
+#else
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
@@ -1743,6 +1760,7 @@ static void init_sockets(int **psock, int **pro_sock)
 
 
 }
+#endif
 
 static void usage(void)
 {
@@ -1938,10 +1956,10 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
-		if (FD_ISSET(*sock, &inset))
+		if (*sock != -1 && FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
-		if (FD_ISSET(*ro_sock, &inset))
+		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5X-0005kU-Cb; Fri, 27 Jan 2012 22:16:07 +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 1Rqu5U-0005hE-HG
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327702557!8667478!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10386 invoked from network); 27 Jan 2012 22:15:58 -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;
	27 Jan 2012 22:15:58 -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
	q0RMFtpV014547; Fri, 27 Jan 2012 22:15:55 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 q0RMFrha026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:41 -0500
Message-Id: <1327702543-25211-23-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 22/24] xenstored: use domain_is_unprivileged
	instead of checking conn->id
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 centralizes all the permission checking for privileged domains in
preparation for allowing domains other than dom0 to be privileged.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c   |    6 +++---
 tools/xenstore/xenstored_domain.c |    8 ++++----
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 40e2fc0..66584f5 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -462,7 +462,7 @@ static enum xs_perm_type perm_for_conn(struct connection *conn,
 		mask &= ~XS_PERM_WRITE;
 
 	/* Owners and tools get it all... */
-	if (!conn->id || perms[0].id == conn->id
+	if (!domain_is_unprivileged(conn) || perms[0].id == conn->id
                 || (conn->target && perms[0].id == conn->target->id))
 		return (XS_PERM_READ|XS_PERM_WRITE|XS_PERM_OWNER) & mask;
 
@@ -800,11 +800,11 @@ static struct node *construct_node(struct connection *conn, const char *name)
 	node->tdb = tdb_context(conn);
 	node->name = talloc_strdup(node, name);
 
-	/* Inherit permissions, except domains own what they create */
+	/* Inherit permissions, except unprivileged domains own what they create */
 	node->num_perms = parent->num_perms;
 	node->perms = talloc_memdup(node, parent->perms,
 				    node->num_perms * sizeof(node->perms[0]));
-	if (conn && conn->id)
+	if (domain_is_unprivileged(conn))
 		node->perms[0].id = conn->id;
 
 	/* No children, no data */
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 558e5cb..fa9c8fe 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -354,7 +354,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -418,7 +418,7 @@ void do_set_target(struct connection *conn, struct buffered_data *in)
 		return;
 	}
 
-	if (conn->id != 0 || !conn->can_write) {
+	if (domain_is_unprivileged(conn) || !conn->can_write) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -470,7 +470,7 @@ void do_release(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
@@ -507,7 +507,7 @@ void do_resume(struct connection *conn, const char *domid_str)
 		return;
 	}
 
-	if (conn->id != 0) {
+	if (domain_is_unprivileged(conn)) {
 		send_error(conn, EACCES);
 		return;
 	}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5Y-0005lr-UI; Fri, 27 Jan 2012 22:16:08 +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 1Rqu5U-0005hO-P6
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-21.messagelabs.com!1327702557!10164912!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13004 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-21.messagelabs.com with SMTP;
	27 Jan 2012 22:15:58 -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
	q0RMFtpV014541; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhU026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:35 -0500
Message-Id: <1327702543-25211-17-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 16/24] xenstored: add NO_SOCKETS compilation
	option
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

Add option for compiling xenstored without unix sockets to support
running on mini-OS

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c |   28 +++++++++++++++++++++++-----
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 0e7d43f..c1ee932 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -19,9 +19,11 @@
 
 #include <sys/types.h>
 #include <sys/stat.h>
-#include <sys/socket.h>
 #include <sys/select.h>
+#ifndef NO_SOCKETS
+#include <sys/socket.h>
 #include <sys/un.h>
+#endif
 #include <sys/time.h>
 #include <time.h>
 #include <unistd.h>
@@ -320,8 +322,10 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	FD_ZERO(inset);
 	FD_ZERO(outset);
 
-	set_fd(sock,               inset, &max);
-	set_fd(ro_sock,            inset, &max);
+	if (sock != -1)
+		set_fd(sock, inset, &max);
+	if (ro_sock != -1)
+		set_fd(ro_sock, inset, &max);
 	set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
@@ -1345,6 +1349,11 @@ struct connection *new_connection(connwritefn_t *write, connreadfn_t *read)
 	return new;
 }
 
+#ifdef NO_SOCKETS
+static void accept_connection(int sock, bool canwrite)
+{
+}
+#else
 static int writefd(struct connection *conn, const void *data, unsigned int len)
 {
 	int rc;
@@ -1399,6 +1408,7 @@ static void accept_connection(int sock, bool canwrite)
 	} else
 		close(fd);
 }
+#endif
 
 #define TDB_FLAGS 0
 
@@ -1698,6 +1708,13 @@ static void daemonize(void)
 	umask(0);
 }
 
+#ifdef NO_SOCKETS
+static void init_sockets(int **psock, int **pro_sock)
+{
+	static int minus_one = -1;
+	*psock = *pro_sock = &minus_one;
+}
+#else
 static int destroy_fd(void *_fd)
 {
 	int *fd = _fd;
@@ -1743,6 +1760,7 @@ static void init_sockets(int **psock, int **pro_sock)
 
 
 }
+#endif
 
 static void usage(void)
 {
@@ -1938,10 +1956,10 @@ int main(int argc, char *argv[])
 			reopen_log();
 		}
 
-		if (FD_ISSET(*sock, &inset))
+		if (*sock != -1 && FD_ISSET(*sock, &inset))
 			accept_connection(*sock, true);
 
-		if (FD_ISSET(*ro_sock, &inset))
+		if (*ro_sock != -1 && FD_ISSET(*ro_sock, &inset))
 			accept_connection(*ro_sock, false);
 
 		if (evtchn_fd != -1 && FD_ISSET(evtchn_fd, &inset))
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5Z-0005mf-Mz; Fri, 27 Jan 2012 22:16:09 +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 1Rqu5U-0005hQ-SZ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-11.tower-182.messagelabs.com!1327702557!12668120!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12220 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-11.tower-182.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFtgt010108; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhX026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:38 -0500
Message-Id: <1327702543-25211-20-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
	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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A previous versions of this patch has been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/Makefile           |   14 ++++-
 tools/xenstore/utils.h            |    2 +
 tools/xenstore/xenstored_core.c   |   88 ++++-----------------------------
 tools/xenstore/xenstored_core.h   |   12 +++++
 tools/xenstore/xenstored_domain.c |    2 +-
 tools/xenstore/xenstored_minios.c |   60 ++++++++++++++++++++++
 tools/xenstore/xenstored_posix.c  |   99 +++++++++++++++++++++++++++++++++++++
 7 files changed, 195 insertions(+), 82 deletions(-)
 create mode 100644 tools/xenstore/xenstored_minios.c
 create mode 100644 tools/xenstore/xenstored_posix.c

diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index 4facb62..e510b4f 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -13,9 +13,10 @@ CLIENTS += xenstore-write xenstore-ls xenstore-watch
 
 XENSTORED_OBJS = xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o
 
-XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o
-XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_probes.o
-XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o
+XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o xenstored_posix.o
+XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_posix.o xenstored_probes.o
+XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o xenstored_posix.o
+XENSTORED_OBJS_$(CONFIG_MiniOS) = xenstored_minios.o
 
 XENSTORED_OBJS += $(XENSTORED_OBJS_y)
 
@@ -28,6 +29,10 @@ endif
 
 ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
 
+ifdef CONFIG_STUBDOM
+CFLAGS += -DNO_SOCKETS=1
+endif
+
 .PHONY: all
 all: $(ALL_TARGETS)
 
@@ -49,6 +54,9 @@ endif
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
+xenstored.a: $(XENSTORED_OBJS)
+	$(AR) cr $@ $^
+
 $(CLIENTS): xenstore
 	ln -f xenstore $@
 
diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
index f378343..2effd17 100644
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
 	return streq(a + strlen(a) - strlen(b), b);
 }
 
+#ifndef ARRAY_SIZE
 #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
 
 void barf(const char *fmt, ...) __attribute__((noreturn));
 void barf_perror(const char *fmt, ...) __attribute__((noreturn));
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 4b12cf2..a762db7 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -224,7 +224,6 @@ static void reopen_log(void)
 	}
 }
 
-
 static bool write_messages(struct connection *conn)
 {
 	int ret;
@@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 		set_fd(sock, inset, &max);
 	if (ro_sock != -1)
 		set_fd(ro_sock, inset, &max);
-	set_fd(reopen_log_pipe[0], inset, &max);
+	if (reopen_log_pipe[0] != -1)
+		set_fd(reopen_log_pipe[0], inset, &max);
 
 	if (xce_handle != NULL)
 		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
@@ -1664,53 +1664,6 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
 }
 
 
-static void write_pidfile(const char *pidfile)
-{
-	char buf[100];
-	int len;
-	int fd;
-
-	fd = open(pidfile, O_RDWR | O_CREAT, 0600);
-	if (fd == -1)
-		barf_perror("Opening pid file %s", pidfile);
-
-	/* We exit silently if daemon already running. */
-	if (lockf(fd, F_TLOCK, 0) == -1)
-		exit(0);
-
-	len = snprintf(buf, sizeof(buf), "%ld\n", (long)getpid());
-	if (write(fd, buf, len) != len)
-		barf_perror("Writing pid file %s", pidfile);
-}
-
-/* Stevens. */
-static void daemonize(void)
-{
-	pid_t pid;
-
-	/* Separate from our parent via fork, so init inherits us. */
-	if ((pid = fork()) < 0)
-		barf_perror("Failed to fork daemon");
-	if (pid != 0)
-		exit(0);
-
-	/* Session leader so ^C doesn't whack us. */
-	setsid();
-
-	/* Let session leader exit so child cannot regain CTTY */
-	if ((pid = fork()) < 0)
-		barf_perror("Failed to fork daemon");
-	if (pid != 0)
-		exit(0);
-
-	/* Move off any mount points we might be in. */
-	if (chdir("/") == -1)
-		barf_perror("Failed to chdir");
-
-	/* Discard our parent's old-fashioned umask prejudices. */
-	umask(0);
-}
-
 #ifdef NO_SOCKETS
 static void init_sockets(int **psock, int **pro_sock)
 {
@@ -1874,20 +1827,10 @@ int main(int argc, char *argv[])
 
 	reopen_log();
 
-	/* make sure xenstored directory exists */
-	if (mkdir(xs_daemon_rundir(), 0755)) {
-		if (errno != EEXIST) {
-			perror("error: mkdir daemon rundir");
-			exit(-1);
-		}
-	}
-
-	if (mkdir(xs_daemon_rootdir(), 0755)) {
-		if (errno != EEXIST) {
-			perror("error: mkdir daemon rootdir");
-			exit(-1);
-		}
-	}
+	/* make sure xenstored directories exist */
+	/* Errors ignored here, will be reported when we open files */
+	mkdir(xs_daemon_rundir(), 0755);
+	mkdir(xs_daemon_rootdir(), 0755);
 
 	if (dofork) {
 		openlog("xenstored", 0, LOG_DAEMON);
@@ -1904,10 +1847,7 @@ int main(int argc, char *argv[])
 	signal(SIGPIPE, SIG_IGN);
 
 	init_sockets(&sock, &ro_sock);
-
-	if (pipe(reopen_log_pipe)) {
-		barf_perror("pipe");
-	}
+	init_pipe(reopen_log_pipe);
 
 	/* Setup the database */
 	setup_structure();
@@ -1925,16 +1865,8 @@ int main(int argc, char *argv[])
 	}
 
 	/* redirect to /dev/null now we're ready to accept connections */
-	if (dofork) {
-		int devnull = open("/dev/null", O_RDWR);
-		if (devnull == -1)
-			barf_perror("Could not open /dev/null\n");
-		dup2(devnull, STDIN_FILENO);
-		dup2(devnull, STDOUT_FILENO);
-		dup2(devnull, STDERR_FILENO);
-		close(devnull);
-		xprintf = trace;
-	}
+	if (dofork)
+		finish_daemonize();
 
 	signal(SIGHUP, trigger_reopen_log);
 
@@ -1957,7 +1889,7 @@ int main(int argc, char *argv[])
 			barf_perror("Select failed");
 		}
 
-		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
+		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
 			char c;
 			if (read(reopen_log_pipe[0], &c, 1) != 1)
 				barf_perror("read failed");
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index c487089..f074955 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -171,6 +171,7 @@ extern int event_fd;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
+void unmap_xenbus(void *interface);
 
 /* Return the event channel used by xenbus. */
 evtchn_port_t xenbus_evtchn(void);
@@ -178,6 +179,17 @@ evtchn_port_t xenbus_evtchn(void);
 /* Tell the kernel xenstored is running. */
 void xenbus_notify_running(void);
 
+/* Write out the pidfile */
+void write_pidfile(const char *pidfile);
+
+/* Fork but do not close terminal FDs */
+void daemonize(void);
+/* Close stdin/stdout/stderr to complete daemonize */
+void finish_daemonize(void);
+
+/* Open a pipe for signal handling */
+void init_pipe(int reopen_log_pipe[2]);
+
 #endif /* _XENSTORED_CORE_H */
 
 /*
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index c521e52..6206961 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -200,7 +200,7 @@ static int destroy_domain(void *_domain)
 		/* Domain 0 was mapped by dom0_init, so it must be unmapped
 		   using munmap() and not the grant unmap call. */
 		if (domain->domid == 0)
-			munmap(domain->interface, getpagesize());
+			unmap_xenbus(domain->interface);
 		else
 			unmap_interface(domain->interface);
 	}
diff --git a/tools/xenstore/xenstored_minios.c b/tools/xenstore/xenstored_minios.c
new file mode 100644
index 0000000..c8700ba
--- /dev/null
+++ b/tools/xenstore/xenstored_minios.c
@@ -0,0 +1,60 @@
+/* 
+    Simple prototype Xen Store Daemon providing simple tree-like database.
+    Copyright (C) 2005 Rusty Russell IBM 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
+*/
+#include <sys/types.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include "xenstored_core.h"
+#include <xen/grant_table.h>
+
+void write_pidfile(const char *pidfile)
+{
+}
+
+void daemonize(void)
+{
+}
+
+void finish_daemonize(void)
+{
+}
+
+void init_pipe(int reopen_log_pipe[2])
+{
+	reopen_log_pipe[0] = -1;
+	reopen_log_pipe[1] = -1;
+}
+
+void xenbus_notify_running(void)
+{
+}
+
+evtchn_port_t xenbus_evtchn(void)
+{
+	return -1;
+}
+
+void *xenbus_map(void)
+{
+	return NULL;
+}
+
+void unmap_xenbus(void *interface)
+{
+}
+
diff --git a/tools/xenstore/xenstored_posix.c b/tools/xenstore/xenstored_posix.c
new file mode 100644
index 0000000..25bdf74
--- /dev/null
+++ b/tools/xenstore/xenstored_posix.c
@@ -0,0 +1,99 @@
+/* 
+    Simple prototype Xen Store Daemon providing simple tree-like database.
+    Copyright (C) 2005 Rusty Russell IBM 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
+*/
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <stdlib.h>
+#include <sys/mman.h>
+
+#include "utils.h"
+#include "xenstored_core.h"
+
+void write_pidfile(const char *pidfile)
+{
+	char buf[100];
+	int len;
+	int fd;
+
+	fd = open(pidfile, O_RDWR | O_CREAT, 0600);
+	if (fd == -1)
+		barf_perror("Opening pid file %s", pidfile);
+
+	/* We exit silently if daemon already running. */
+	if (lockf(fd, F_TLOCK, 0) == -1)
+		exit(0);
+
+	len = snprintf(buf, sizeof(buf), "%ld\n", (long)getpid());
+	if (write(fd, buf, len) != len)
+		barf_perror("Writing pid file %s", pidfile);
+}
+
+/* Stevens. */
+void daemonize(void)
+{
+	pid_t pid;
+
+	/* Separate from our parent via fork, so init inherits us. */
+	if ((pid = fork()) < 0)
+		barf_perror("Failed to fork daemon");
+	if (pid != 0)
+		exit(0);
+
+	/* Session leader so ^C doesn't whack us. */
+	setsid();
+
+	/* Let session leader exit so child cannot regain CTTY */
+	if ((pid = fork()) < 0)
+		barf_perror("Failed to fork daemon");
+	if (pid != 0)
+		exit(0);
+
+	/* Move off any mount points we might be in. */
+	if (chdir("/") == -1)
+		barf_perror("Failed to chdir");
+
+	/* Discard our parent's old-fashioned umask prejudices. */
+	umask(0);
+}
+
+void finish_daemonize(void)
+{
+	int devnull = open("/dev/null", O_RDWR);
+	if (devnull == -1)
+		barf_perror("Could not open /dev/null\n");
+	dup2(devnull, STDIN_FILENO);
+	dup2(devnull, STDOUT_FILENO);
+	dup2(devnull, STDERR_FILENO);
+	close(devnull);
+	xprintf = trace;
+}
+
+void init_pipe(int reopen_log_pipe[2])
+{
+	if (pipe(reopen_log_pipe)) {
+		barf_perror("pipe");
+	}
+}
+
+void unmap_xenbus(void *interface)
+{
+	munmap(interface, getpagesize());
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5V-0005jV-Id; Fri, 27 Jan 2012 22:16:05 +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 1Rqu5T-0005h8-8B
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327702555!12690346!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28193 invoked from network); 27 Jan 2012 22:15:56 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-182.messagelabs.com with SMTP;
	27 Jan 2012 22:15:56 -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
	q0RMFsgt010087; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhH026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:22 -0500
Message-Id: <1327702543-25211-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 03/24] xen: change virq parameters from int to
	uint32_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/event_channel.c   |   10 +++++-----
 xen/include/asm-ia64/event.h |    2 +-
 xen/include/asm-x86/event.h  |    2 +-
 xen/include/xen/event.h      |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43bd167..f784254 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,11 +104,11 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 
 static int evtchn_set_pending(struct vcpu *v, int port);
 
-static int virq_is_global(int virq)
+static int virq_is_global(uint32_t virq)
 {
     int rc;
 
-    ASSERT((virq >= 0) && (virq < NR_VIRQS));
+    ASSERT(virq < NR_VIRQS);
 
     switch ( virq )
     {
@@ -665,12 +665,12 @@ static int evtchn_set_pending(struct vcpu *v, int port)
     return 0;
 }
 
-int guest_enabled_event(struct vcpu *v, int virq)
+int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
 }
 
-void send_guest_vcpu_virq(struct vcpu *v, int virq)
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 {
     unsigned long flags;
     int port;
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
     unsigned long flags;
     int port;
diff --git a/xen/include/asm-ia64/event.h b/xen/include/asm-ia64/event.h
index c99babd..4463cb3 100644
--- a/xen/include/asm-ia64/event.h
+++ b/xen/include/asm-ia64/event.h
@@ -63,7 +63,7 @@ static inline void local_event_delivery_enable(void)
     current->vcpu_info->evtchn_upcall_mask = 0;
 }
 
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     int rc;
 
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index 606ec6d..06057c7 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -39,7 +39,7 @@ static inline void local_event_delivery_enable(void)
 }
 
 /* No arch specific virq definition now. Default to global. */
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     return 1;
 }
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 40b8a7a..22fc6a3 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,7 @@
  *  @v:        VCPU to which virtual IRQ should be sent
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_vcpu_virq(struct vcpu *v, int virq);
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
  * send_global_virq: Notify the domain handling a global VIRQ.
@@ -65,7 +65,7 @@ void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
 /* Query if event channel is in use by the guest */
-int guest_enabled_event(struct vcpu *v, int virq);
+int guest_enabled_event(struct vcpu *v, uint32_t virq);
 
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:16:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu5V-0005jV-Id; Fri, 27 Jan 2012 22:16:05 +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 1Rqu5T-0005h8-8B
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327702555!12690346!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28193 invoked from network); 27 Jan 2012 22:15:56 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-10.tower-182.messagelabs.com with SMTP;
	27 Jan 2012 22:15:56 -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
	q0RMFsgt010087; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhH026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:22 -0500
Message-Id: <1327702543-25211-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: [Xen-devel] [PATCH 03/24] xen: change virq parameters from int to
	uint32_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/event_channel.c   |   10 +++++-----
 xen/include/asm-ia64/event.h |    2 +-
 xen/include/asm-x86/event.h  |    2 +-
 xen/include/xen/event.h      |    4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 43bd167..f784254 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -104,11 +104,11 @@ static uint8_t get_xen_consumer(xen_event_channel_notification_t fn)
 
 static int evtchn_set_pending(struct vcpu *v, int port);
 
-static int virq_is_global(int virq)
+static int virq_is_global(uint32_t virq)
 {
     int rc;
 
-    ASSERT((virq >= 0) && (virq < NR_VIRQS));
+    ASSERT(virq < NR_VIRQS);
 
     switch ( virq )
     {
@@ -665,12 +665,12 @@ static int evtchn_set_pending(struct vcpu *v, int port)
     return 0;
 }
 
-int guest_enabled_event(struct vcpu *v, int virq)
+int guest_enabled_event(struct vcpu *v, uint32_t virq)
 {
     return ((v != NULL) && (v->virq_to_evtchn[virq] != 0));
 }
 
-void send_guest_vcpu_virq(struct vcpu *v, int virq)
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq)
 {
     unsigned long flags;
     int port;
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-static void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, uint32_t virq)
 {
     unsigned long flags;
     int port;
diff --git a/xen/include/asm-ia64/event.h b/xen/include/asm-ia64/event.h
index c99babd..4463cb3 100644
--- a/xen/include/asm-ia64/event.h
+++ b/xen/include/asm-ia64/event.h
@@ -63,7 +63,7 @@ static inline void local_event_delivery_enable(void)
     current->vcpu_info->evtchn_upcall_mask = 0;
 }
 
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     int rc;
 
diff --git a/xen/include/asm-x86/event.h b/xen/include/asm-x86/event.h
index 606ec6d..06057c7 100644
--- a/xen/include/asm-x86/event.h
+++ b/xen/include/asm-x86/event.h
@@ -39,7 +39,7 @@ static inline void local_event_delivery_enable(void)
 }
 
 /* No arch specific virq definition now. Default to global. */
-static inline int arch_virq_is_global(int virq)
+static inline int arch_virq_is_global(uint32_t virq)
 {
     return 1;
 }
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 40b8a7a..22fc6a3 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -20,7 +20,7 @@
  *  @v:        VCPU to which virtual IRQ should be sent
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_vcpu_virq(struct vcpu *v, int virq);
+void send_guest_vcpu_virq(struct vcpu *v, uint32_t virq);
 
 /*
  * send_global_virq: Notify the domain handling a global VIRQ.
@@ -65,7 +65,7 @@ void free_xen_event_channel(
     struct vcpu *local_vcpu, int port);
 
 /* Query if event channel is in use by the guest */
-int guest_enabled_event(struct vcpu *v, int virq);
+int guest_enabled_event(struct vcpu *v, uint32_t virq);
 
 /* Notify remote end of a Xen-attached event channel.*/
 void notify_via_xen_event_channel(struct domain *ld, int lport);
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5U-0005iP-3C; Fri, 27 Jan 2012 22:16:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5S-0005hB-8h
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327702503!54360178!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19037 invoked from network); 27 Jan 2012 22:15:03 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:03 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0RMFtpV014538; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhM026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:27 -0500
Message-Id: <1327702543-25211-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/24] mini-os: use BSD sys/queue.h instead of
	Linux 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>
MIME-Version: 1.0
Content-Type: text/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>

The latter is GPL which makes the whole of mini-os GPL rather than BSD
as intended. In tree users are all GPL or GPL-compatible but we should
fix this so that mini-os is BSD. Do so by using the same BSD
sys/queue.h as we use in libxl.

Tested with the builtin mini-os test app and qemu stubdomain, both of which
appear to still function as expected.

Move tools/libxl/external and the associated sed script to
tools/include/xen-external to allow more sensible access from mini-os.

Also add s/NULL/0/ in the sed script due to NULL not always being
defined in stubdom code when mini-os/wait.h is included.

As well as the obvious ABI changes there are a few API updates
associated with the change:

  - struct rw_semaphore.wait_list is unused
  - remove_waiter needs to take the wait_queue_head

The latter requires a qemu update which I will post separately. Please
apply first and update QEMU_TAG as appropriate.

I sprinkled some extra-emacs local variables around the files I edited
which didn't have them.

I think this should be backported to the stable branches since
external users of mini-os may have been mislead into thinking they
could safely link mini-os against GPL-incompatible code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 .hgignore                                          |    1 +
 extras/mini-os/Makefile                            |    9 +-
 extras/mini-os/blkfront.c                          |    6 +-
 extras/mini-os/fbfront.c                           |    2 +-
 extras/mini-os/include/list.h                      |  190 --------------------
 extras/mini-os/include/sched.h                     |    2 +-
 extras/mini-os/include/semaphore.h                 |    1 -
 extras/mini-os/include/wait.h                      |   56 ++++---
 extras/mini-os/include/waittypes.h                 |   26 ++-
 extras/mini-os/lib/sys.c                           |   38 ++--
 extras/mini-os/lib/xmalloc.c                       |   43 +++---
 extras/mini-os/sched.c                             |   48 +++---
 extras/mini-os/xenbus/xenbus.c                     |    4 +-
 .../external => include/xen-external}/README       |   14 ++-
 .../xen-external}/bsd-COPYRIGHT                    |    0
 .../external => include/xen-external}/bsd-queue.3  |    0
 .../xen-external}/bsd-sys-queue-h-seddery          |    2 +
 .../xen-external}/bsd-sys-queue.h                  |    0
 tools/libxl/Makefile                               |    4 +-
 19 files changed, 145 insertions(+), 301 deletions(-)
 delete mode 100644 extras/mini-os/include/list.h
 rename tools/{libxl/external => include/xen-external}/README (69%)
 rename tools/{libxl/external => include/xen-external}/bsd-COPYRIGHT (100%)
 rename tools/{libxl/external => include/xen-external}/bsd-queue.3 (100%)
 rename tools/{libxl => include/xen-external}/bsd-sys-queue-h-seddery (99%)
 rename tools/{libxl/external => include/xen-external}/bsd-sys-queue.h (100%)

diff --git a/.hgignore b/.hgignore
index 64b440e..e295c00 100644
--- a/.hgignore
+++ b/.hgignore
@@ -62,6 +62,7 @@
 ^docs/xen-api/xenapi-datamodel-graph.eps$
 ^docs/xen-api/xenapi.out$
 ^extras/mini-os/arch/ia64/gen_off.s$
+^extras/mini-os/include/list\.h$
 ^extras/mini-os/include/mini-os$
 ^extras/mini-os/include/ia64/mini-os$
 ^extras/mini-os/include/ia64/offsets.h$
diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c2ee062..c4d26f0 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -52,8 +52,12 @@ $(ARCH_LINKS):
 	$(arch_links)
 endif
 
+include/list.h: $(XEN_ROOT)/tools/include/xen-external/bsd-sys-queue-h-seddery $(XEN_ROOT)/tools/include/xen-external/bsd-sys-queue.h
+	perl $^ --prefix=minios  >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 .PHONY: links
-links:	$(ARCH_LINKS)
+links: include/list.h $(ARCH_LINKS)
 	[ -e include/xen ] || ln -sf ../../../xen/include/public include/xen
 	[ -e include/mini-os ] || ln -sf . include/mini-os
 	[ -e include/$(TARGET_ARCH_FAM)/mini-os ] || ln -sf . include/$(TARGET_ARCH_FAM)/mini-os
@@ -97,7 +101,7 @@ ifneq ($(APP_OBJS),)
 APP_O=$(OBJ_DIR)/$(TARGET)_app.o 
 endif
 
-$(OBJ_DIR)/$(TARGET): links $(OBJS) $(APP_O) arch_lib
+$(OBJ_DIR)/$(TARGET): links include/list.h $(OBJS) $(APP_O) arch_lib
 	$(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(APP_O) $(OBJS) $(LDARCHLIB) $(LDLIBS) -o $@.o
 	$(OBJCOPY) -w -G $(GLOBAL_PREFIX)* -G _start $@.o $@.o
 	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@
@@ -112,6 +116,7 @@ clean:	arch_clean
 	for dir in $(addprefix $(OBJ_DIR)/,$(SUBDIRS)); do \
 		rm -f $$dir/*.o; \
 	done
+	rm -f include/list.h
 	rm -f $(OBJ_DIR)/*.o *~ $(OBJ_DIR)/core $(OBJ_DIR)/$(TARGET).elf $(OBJ_DIR)/$(TARGET).raw $(OBJ_DIR)/$(TARGET) $(OBJ_DIR)/$(TARGET).gz
 	find . $(OBJ_DIR) -type l | xargs rm -f
 	$(RM) $(OBJ_DIR)/lwip.a $(LWO)
diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
index 695d8e6..bb3d91e 100644
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -323,7 +323,7 @@ static void blkfront_wait_slot(struct blkfront_dev *dev)
 	    schedule();
 	    local_irq_save(flags);
 	}
-	remove_waiter(w);
+	remove_waiter(w, blkfront_queue);
 	local_irq_restore(flags);
     }
 }
@@ -414,7 +414,7 @@ void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
 	schedule();
 	local_irq_save(flags);
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
     local_irq_restore(flags);
 }
 
@@ -470,7 +470,7 @@ void blkfront_sync(struct blkfront_dev *dev)
 	schedule();
 	local_irq_save(flags);
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
     local_irq_restore(flags);
 }
 
diff --git a/extras/mini-os/fbfront.c b/extras/mini-os/fbfront.c
index 8d03e5b..9889376 100644
--- a/extras/mini-os/fbfront.c
+++ b/extras/mini-os/fbfront.c
@@ -569,7 +569,7 @@ static void fbfront_out_event(struct fbfront_dev *dev, union xenfb_out_event *ev
     add_waiter(w, fbfront_queue);
     while (page->out_prod - page->out_cons == XENFB_OUT_RING_LEN)
         schedule();
-    remove_waiter(w);
+    remove_waiter(w, fbfront_queue);
 
     prod = page->out_prod;
     mb(); /* ensure ring space available */
diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
deleted file mode 100644
index a60ae23..0000000
--- a/extras/mini-os/include/list.h
+++ /dev/null
@@ -1,190 +0,0 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
-
-/*
- * Simple doubly linked list implementation.
- *
- * Some of the internal functions ("__xxx") are useful when
- * manipulating whole lists rather than single entries, as
- * sometimes we already know the next/prev entries and we can
- * generate better code by using them directly rather than
- * using the generic single-entry routines.
- */
-
-struct minios_list_head {
-	struct minios_list_head *next, *prev;
-};
-
-#define MINIOS_LIST_HEAD_INIT(name) { &(name), &(name) }
-
-#define MINIOS_LIST_HEAD(name) \
-	struct minios_list_head name = MINIOS_LIST_HEAD_INIT(name)
-
-#define MINIOS_INIT_LIST_HEAD(ptr) do { \
-	(ptr)->next = (ptr); (ptr)->prev = (ptr); \
-} while (0)
-
-#define minios_list_top(head, type, member)					  \
-({ 									  \
-	struct minios_list_head *_head = (head);				  \
-	minios_list_empty(_head) ? NULL : minios_list_entry(_head->next, type, member); \
-})
-
-/*
- * Insert a new entry between two known consecutive entries. 
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static __inline__ void __minios_list_add(struct minios_list_head * new,
-	struct minios_list_head * prev,
-	struct minios_list_head * next)
-{
-	next->prev = new;
-	new->next = next;
-	new->prev = prev;
-	prev->next = new;
-}
-
-/**
- * minios_list_add - add a new entry
- * @new: new entry to be added
- * @head: list head to add it after
- *
- * Insert a new entry after the specified head.
- * This is good for implementing stacks.
- */
-static __inline__ void minios_list_add(struct minios_list_head *new, struct minios_list_head *head)
-{
-	__minios_list_add(new, head, head->next);
-}
-
-/**
- * minios_list_add_tail - add a new entry
- * @new: new entry to be added
- * @head: list head to add it before
- *
- * Insert a new entry before the specified head.
- * This is useful for implementing queues.
- */
-static __inline__ void minios_list_add_tail(struct minios_list_head *new, struct minios_list_head *head)
-{
-	__minios_list_add(new, head->prev, head);
-}
-
-/*
- * Delete a list entry by making the prev/next entries
- * point to each other.
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static __inline__ void __minios_list_del(struct minios_list_head * prev,
-				  struct minios_list_head * next)
-{
-	next->prev = prev;
-	prev->next = next;
-}
-
-/**
- * minios_list_del - deletes entry from list.
- * @entry: the element to delete from the list.
- * Note: minios_list_empty on entry does not return true after this, the entry is in an undefined state.
- */
-static __inline__ void minios_list_del(struct minios_list_head *entry)
-{
-	__minios_list_del(entry->prev, entry->next);
-}
-
-/**
- * minios_list_del_init - deletes entry from list and reinitialize it.
- * @entry: the element to delete from the list.
- */
-static __inline__ void minios_list_del_init(struct minios_list_head *entry)
-{
-	__minios_list_del(entry->prev, entry->next);
-	MINIOS_INIT_LIST_HEAD(entry); 
-}
-
-/**
- * minios_list_empty - tests whether a list is empty
- * @head: the list to test.
- */
-static __inline__ int minios_list_empty(struct minios_list_head *head)
-{
-	return head->next == head;
-}
-
-/**
- * minios_list_splice - join two lists
- * @list: the new list to add.
- * @head: the place to add it in the first list.
- */
-static __inline__ void minios_list_splice(struct minios_list_head *list, struct minios_list_head *head)
-{
-	struct minios_list_head *first = list->next;
-
-	if (first != list) {
-		struct minios_list_head *last = list->prev;
-		struct minios_list_head *at = head->next;
-
-		first->prev = head;
-		head->next = first;
-
-		last->next = at;
-		at->prev = last;
-	}
-}
-
-/**
- * minios_list_entry - get the struct for this entry
- * @ptr:	the &struct minios_list_head pointer.
- * @type:	the type of the struct this is embedded in.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_entry(ptr, type, member) \
-	((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))
-
-/**
- * minios_list_for_each	-	iterate over a list
- * @pos:	the &struct minios_list_head to use as a loop counter.
- * @head:	the head for your list.
- */
-#define minios_list_for_each(pos, head) \
-	for (pos = (head)->next; pos != (head); pos = pos->next)
-        	
-/**
- * minios_list_for_each_safe	-	iterate over a list safe against removal of list entry
- * @pos:	the &struct minios_list_head to use as a loop counter.
- * @n:		another &struct minios_list_head to use as temporary storage
- * @head:	the head for your list.
- */
-#define minios_list_for_each_safe(pos, n, head) \
-	for (pos = (head)->next, n = pos->next; pos != (head); \
-		pos = n, n = pos->next)
-
-/**
- * minios_list_for_each_entry	-	iterate over list of given type
- * @pos:	the type * to use as a loop counter.
- * @head:	the head for your list.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_for_each_entry(pos, head, member)				\
-	for (pos = minios_list_entry((head)->next, typeof(*pos), member);	\
-	     &pos->member != (head); 					\
-	     pos = minios_list_entry(pos->member.next, typeof(*pos), member))
-
-/**
- * minios_list_for_each_entry_safe - iterate over list of given type safe against removal of list entry
- * @pos:	the type * to use as a loop counter.
- * @n:		another type * to use as temporary storage
- * @head:	the head for your list.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_for_each_entry_safe(pos, n, head, member)			\
-	for (pos = minios_list_entry((head)->next, typeof(*pos), member),	\
-		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
-	     &pos->member != (head); 					\
-	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
-
diff --git a/extras/mini-os/include/sched.h b/extras/mini-os/include/sched.h
index 538bed5..ea3239d 100644
--- a/extras/mini-os/include/sched.h
+++ b/extras/mini-os/include/sched.h
@@ -19,7 +19,7 @@ struct thread
 #else /* !defined(__ia64__) */
     thread_regs_t regs;
 #endif /* !defined(__ia64__) */
-    struct minios_list_head thread_list;
+    MINIOS_TAILQ_ENTRY(struct thread) thread_list;
     uint32_t flags;
     s_time_t wakeup_time;
 #ifdef HAVE_LIBC
diff --git a/extras/mini-os/include/semaphore.h b/extras/mini-os/include/semaphore.h
index 8236046..47470c5 100644
--- a/extras/mini-os/include/semaphore.h
+++ b/extras/mini-os/include/semaphore.h
@@ -21,7 +21,6 @@ struct semaphore
 struct rw_semaphore {
 	signed long		count;
 	spinlock_t		wait_lock;
-	struct minios_list_head	wait_list;
 	int			debug;
 };
 
diff --git a/extras/mini-os/include/wait.h b/extras/mini-os/include/wait.h
index 10b9f29..bffa3c4 100644
--- a/extras/mini-os/include/wait.h
+++ b/extras/mini-os/include/wait.h
@@ -5,47 +5,47 @@
 #include <mini-os/os.h>
 #include <mini-os/waittypes.h>
 
-#define DEFINE_WAIT(name)                               \
-struct wait_queue name = {                              \
-    .thread       = get_current(),                            \
-    .thread_list  = MINIOS_LIST_HEAD_INIT((name).thread_list), \
+#define DEFINE_WAIT(name)                          \
+struct wait_queue name = {                         \
+    .thread       = get_current(),                 \
+    .waiting      = 0,                             \
 }
 
 
 static inline void init_waitqueue_head(struct wait_queue_head *h)
 {
-  MINIOS_INIT_LIST_HEAD(&h->thread_list);
+    MINIOS_STAILQ_INIT(h);
 }
 
 static inline void init_waitqueue_entry(struct wait_queue *q, struct thread *thread)
 {
     q->thread = thread;
-    MINIOS_INIT_LIST_HEAD(&q->thread_list);
+    q->waiting = 0;
 }
 
-
 static inline void add_wait_queue(struct wait_queue_head *h, struct wait_queue *q)
 {
-    if (minios_list_empty(&q->thread_list))
-        minios_list_add(&q->thread_list, &h->thread_list);   
+    if (!q->waiting) {
+        MINIOS_STAILQ_INSERT_HEAD(h, q, thread_list);
+        q->waiting = 1;
+    }
 }
 
-static inline void remove_wait_queue(struct wait_queue *q)
+static inline void remove_wait_queue(struct wait_queue_head *h, struct wait_queue *q)
 {
-    minios_list_del(&q->thread_list);
+    if (q->waiting) {
+        MINIOS_STAILQ_REMOVE(h, q, struct wait_queue, thread_list);
+        q->waiting = 0;
+    }
 }
 
 static inline void wake_up(struct wait_queue_head *head)
 {
     unsigned long flags;
-    struct minios_list_head *tmp, *next;
+    struct wait_queue *curr, *tmp;
     local_irq_save(flags);
-    minios_list_for_each_safe(tmp, next, &head->thread_list)
-    {
-         struct wait_queue *curr;
-         curr = minios_list_entry(tmp, struct wait_queue, thread_list);
+    MINIOS_STAILQ_FOREACH_SAFE(curr, head, thread_list, tmp)
          wake(curr->thread);
-    }
     local_irq_restore(flags);
 }
 
@@ -57,11 +57,11 @@ static inline void wake_up(struct wait_queue_head *head)
     local_irq_restore(flags);   \
 } while (0)
 
-#define remove_waiter(w) do {   \
-    unsigned long flags;        \
-    local_irq_save(flags);      \
-    remove_wait_queue(&w);      \
-    local_irq_restore(flags);   \
+#define remove_waiter(w, wq) do {  \
+    unsigned long flags;           \
+    local_irq_save(flags);         \
+    remove_wait_queue(&wq, &w);    \
+    local_irq_restore(flags);      \
 } while (0)
 
 #define wait_event_deadline(wq, condition, deadline) do {       \
@@ -84,7 +84,7 @@ static inline void wake_up(struct wait_queue_head *head)
     local_irq_save(flags);                                      \
     /* need to wake up */                                       \
     wake(get_current());                                        \
-    remove_wait_queue(&__wait);                                 \
+    remove_wait_queue(&wq, &__wait);                            \
     local_irq_restore(flags);                                   \
 } while(0) 
 
@@ -93,3 +93,13 @@ static inline void wake_up(struct wait_queue_head *head)
 
 
 #endif /* __WAIT_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/include/waittypes.h b/extras/mini-os/include/waittypes.h
index 1215ffe..78d91c1 100644
--- a/extras/mini-os/include/waittypes.h
+++ b/extras/mini-os/include/waittypes.h
@@ -6,21 +6,27 @@
 struct thread;
 struct wait_queue
 {
+    int waiting;
     struct thread *thread;
-    struct minios_list_head thread_list;
+    MINIOS_STAILQ_ENTRY(struct wait_queue) thread_list;
 };
 
-struct wait_queue_head
-{
-    /* TODO - lock required? */
-    struct minios_list_head thread_list;
-};
+/* TODO - lock required? */
+MINIOS_STAILQ_HEAD(wait_queue_head, struct wait_queue);
 
 #define DECLARE_WAIT_QUEUE_HEAD(name) \
-   struct wait_queue_head name =     \
-        { .thread_list = { &(name).thread_list, &(name).thread_list} }
+    struct wait_queue_head name = MINIOS_STAILQ_HEAD_INITIALIZER(name)
 
-#define __WAIT_QUEUE_HEAD_INITIALIZER(name) {                           \
-    .thread_list      = { &(name).thread_list, &(name).thread_list } }
+#define __WAIT_QUEUE_HEAD_INITIALIZER(name) MINIOS_STAILQ_HEAD_INITIALIZER(name)
 
 #endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index b7b3aff..2329a78 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -234,7 +234,7 @@ int read(int fd, void *buf, size_t nbytes)
                     break;
                 schedule();
             }
-            remove_waiter(w);
+            remove_waiter(w, console_queue);
             return ret;
         }
 #ifdef HAVE_LWIP
@@ -705,12 +705,12 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     fd_set myread, mywrite, myexcept;
     struct thread *thread = get_current();
     s_time_t start = NOW(), stop;
-    DEFINE_WAIT(w1);
-    DEFINE_WAIT(w2);
-    DEFINE_WAIT(w3);
-    DEFINE_WAIT(w4);
-    DEFINE_WAIT(w5);
-    DEFINE_WAIT(w6);
+    DEFINE_WAIT(netfront_w);
+    DEFINE_WAIT(event_w);
+    DEFINE_WAIT(blkfront_w);
+    DEFINE_WAIT(xenbus_watch_w);
+    DEFINE_WAIT(kbdfront_w);
+    DEFINE_WAIT(console_w);
 
     assert(thread == main_thread);
 
@@ -727,12 +727,12 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
-    add_waiter(w1, netfront_queue);
-    add_waiter(w2, event_queue);
-    add_waiter(w3, blkfront_queue);
-    add_waiter(w4, xenbus_watch_queue);
-    add_waiter(w5, kbdfront_queue);
-    add_waiter(w6, console_queue);
+    add_waiter(netfront_w, netfront_queue);
+    add_waiter(event_w, event_queue);
+    add_waiter(blkfront_w, blkfront_queue);
+    add_waiter(xenbus_watch_w, xenbus_watch_queue);
+    add_waiter(kbdfront_w, kbdfront_queue);
+    add_waiter(console_w, console_queue);
 
     if (readfds)
         myread = *readfds;
@@ -814,12 +814,12 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     ret = -1;
 
 out:
-    remove_waiter(w1);
-    remove_waiter(w2);
-    remove_waiter(w3);
-    remove_waiter(w4);
-    remove_waiter(w5);
-    remove_waiter(w6);
+    remove_waiter(netfront_w, netfront_queue);
+    remove_waiter(event_w, event_queue);
+    remove_waiter(blkfront_w, blkfront_queue);
+    remove_waiter(xenbus_watch_w, xenbus_watch_queue);
+    remove_waiter(kbdfront_w, kbdfront_queue);
+    remove_waiter(console_w, console_queue);
     return ret;
 }
 
diff --git a/extras/mini-os/lib/xmalloc.c b/extras/mini-os/lib/xmalloc.c
index c7d3fc1..015cd31 100644
--- a/extras/mini-os/lib/xmalloc.c
+++ b/extras/mini-os/lib/xmalloc.c
@@ -44,16 +44,18 @@
 #include <mini-os/xmalloc.h>
 
 #ifndef HAVE_LIBC
-static MINIOS_LIST_HEAD(freelist);
 /* static spinlock_t freelist_lock = SPIN_LOCK_UNLOCKED; */
 
 struct xmalloc_hdr
 {
     /* Total including this hdr, unused padding and second hdr. */
     size_t size;
-    struct minios_list_head freelist;
+    MINIOS_TAILQ_ENTRY(struct xmalloc_hdr) freelist;
 } __cacheline_aligned;
 
+static MINIOS_TAILQ_HEAD(,struct xmalloc_hdr) freelist =
+	MINIOS_TAILQ_HEAD_INITIALIZER(freelist);
+
 /* Unused padding data between the two hdrs. */
 
 struct xmalloc_pad
@@ -82,7 +84,7 @@ static void maybe_split(struct xmalloc_hdr *hdr, size_t size, size_t block)
         extra = (struct xmalloc_hdr *)((unsigned long)hdr + size);
         extra->size = leftover;
         /* spin_lock_irqsave(&freelist_lock, flags); */
-        minios_list_add(&extra->freelist, &freelist);
+        MINIOS_TAILQ_INSERT_HEAD(&freelist, extra, freelist);
         /* spin_unlock_irqrestore(&freelist_lock, flags); */
     }
     else
@@ -91,8 +93,6 @@ static void maybe_split(struct xmalloc_hdr *hdr, size_t size, size_t block)
     }
 
     hdr->size = size;
-    /* Debugging aid. */
-    hdr->freelist.next = hdr->freelist.prev = NULL;
 }
 
 static struct xmalloc_hdr *xmalloc_new_page(size_t size)
@@ -128,8 +128,6 @@ static void *xmalloc_whole_pages(size_t size, size_t align)
         return NULL;
 
     hdr->size = (1UL << (pageorder + PAGE_SHIFT));
-    /* Debugging aid. */
-    hdr->freelist.next = hdr->freelist.prev = NULL;
 
     ret = (char*)hdr + hdr_size;
     pad = (struct xmalloc_pad *) ret - 1;
@@ -155,14 +153,14 @@ void *_xmalloc(size_t size, size_t align)
 
     /* Search free list. */
     /* spin_lock_irqsave(&freelist_lock, flags); */
-    minios_list_for_each_entry_safe( i, tmp, &freelist, freelist )
+    MINIOS_TAILQ_FOREACH_SAFE(i, &freelist, freelist, tmp)
     {
         data_begin = align_up((uintptr_t)i + hdr_size, align);
 
         if ( data_begin + size > (uintptr_t)i + i->size )
             continue;
 
-        minios_list_del(&i->freelist);
+        MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
         /* spin_unlock_irqrestore(&freelist_lock, flags); */
 
         uintptr_t size_before = (data_begin - hdr_size) - (uintptr_t)i;
@@ -173,7 +171,7 @@ void *_xmalloc(size_t size, size_t align)
             new_i->size = i->size - size_before;
             i->size = size_before;
             /* spin_lock_irqsave(&freelist_lock, flags); */
-            minios_list_add(&i->freelist, &freelist);
+            MINIOS_TAILQ_INSERT_HEAD(&freelist, i, freelist);
             /* spin_unlock_irqrestore(&freelist_lock, flags); */
             i = new_i;
         }
@@ -224,16 +222,9 @@ void xfree(const void *p)
         *(int*)0=0;
     }
 
-    /* Not previously freed. */
-    if(hdr->freelist.next || hdr->freelist.prev)
-    {
-        printk("Should not be previously freed\n");
-        *(int*)0=0;
-    }
-
     /* Merge with other free block, or put in list. */
     /* spin_lock_irqsave(&freelist_lock, flags); */
-    minios_list_for_each_entry_safe( i, tmp, &freelist, freelist )
+    MINIOS_TAILQ_FOREACH_SAFE(i, &freelist, freelist, tmp)
     {
         unsigned long _i   = (unsigned long)i;
         unsigned long _hdr = (unsigned long)hdr;
@@ -245,7 +236,7 @@ void xfree(const void *p)
         /* We follow this block?  Swallow it. */
         if ( (_i + i->size) == _hdr )
         {
-            minios_list_del(&i->freelist);
+            MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
             i->size += hdr->size;
             hdr = i;
         }
@@ -253,7 +244,7 @@ void xfree(const void *p)
         /* We precede this block? Swallow it. */
         if ( (_hdr + hdr->size) == _i )
         {
-            minios_list_del(&i->freelist);
+            MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
             hdr->size += i->size;
         }
     }
@@ -270,7 +261,7 @@ void xfree(const void *p)
     }
     else
     {
-        minios_list_add(&hdr->freelist, &freelist);
+        MINIOS_TAILQ_INSERT_HEAD(&freelist, hdr, freelist);
     }
 
     /* spin_unlock_irqrestore(&freelist_lock, flags); */
@@ -306,3 +297,13 @@ void *_realloc(void *ptr, size_t size)
     return new;
 }
 #endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/sched.c b/extras/mini-os/sched.c
index c0229c5..2d27bfa 100644
--- a/extras/mini-os/sched.c
+++ b/extras/mini-os/sched.c
@@ -54,19 +54,20 @@
 #define DEBUG(_f, _a...)    ((void)0)
 #endif
 
+MINIOS_TAILQ_HEAD(thread_list, struct thread);
+
 struct thread *idle_thread = NULL;
-MINIOS_LIST_HEAD(exited_threads);
+static struct thread_list exited_threads = MINIOS_TAILQ_HEAD_INITIALIZER(exited_threads);
+static struct thread_list thread_list = MINIOS_TAILQ_HEAD_INITIALIZER(thread_list);
 static int threads_started;
 
 struct thread *main_thread;
 
 void inline print_runqueue(void)
 {
-    struct minios_list_head *it;
     struct thread *th;
-    minios_list_for_each(it, &idle_thread->thread_list)
+    MINIOS_TAILQ_FOREACH(th, &thread_list, thread_list)
     {
-        th = minios_list_entry(it, struct thread, thread_list);
         printk("   Thread \"%s\", runnable=%d\n", th->name, is_runnable(th));
     }
     printk("\n");
@@ -74,8 +75,7 @@ void inline print_runqueue(void)
 
 void schedule(void)
 {
-    struct thread *prev, *next, *thread;
-    struct minios_list_head *iterator, *next_iterator;
+    struct thread *prev, *next, *thread, *tmp;
     unsigned long flags;
 
     prev = current;
@@ -96,10 +96,9 @@ void schedule(void)
            time when the next timeout expires, else use 10 seconds. */
         s_time_t now = NOW();
         s_time_t min_wakeup_time = now + SECONDS(10);
-        next = NULL;   
-        minios_list_for_each_safe(iterator, next_iterator, &idle_thread->thread_list)
+        next = NULL;
+        MINIOS_TAILQ_FOREACH_SAFE(thread, &thread_list, thread_list, tmp)
         {
-            thread = minios_list_entry(iterator, struct thread, thread_list);
             if (!is_runnable(thread) && thread->wakeup_time != 0LL)
             {
                 if (thread->wakeup_time <= now)
@@ -111,8 +110,8 @@ void schedule(void)
             {
                 next = thread;
                 /* Put this thread on the end of the list */
-                minios_list_del(&thread->thread_list);
-                minios_list_add_tail(&thread->thread_list, &idle_thread->thread_list);
+                MINIOS_TAILQ_REMOVE(&thread_list, thread, thread_list);
+                MINIOS_TAILQ_INSERT_TAIL(&thread_list, thread, thread_list);
                 break;
             }
         }
@@ -128,12 +127,11 @@ void schedule(void)
        inturrupted at the return instruction. And therefore at safe point. */
     if(prev != next) switch_threads(prev, next);
 
-    minios_list_for_each_safe(iterator, next_iterator, &exited_threads)
+    MINIOS_TAILQ_FOREACH_SAFE(thread, &exited_threads, thread_list, tmp)
     {
-        thread = minios_list_entry(iterator, struct thread, thread_list);
         if(thread != prev)
         {
-            minios_list_del(&thread->thread_list);
+            MINIOS_TAILQ_REMOVE(&exited_threads, thread, thread_list);
             free_pages(thread->stack, STACK_SIZE_PAGE_ORDER);
             xfree(thread);
         }
@@ -154,13 +152,7 @@ struct thread* create_thread(char *name, void (*function)(void *), void *data)
 #endif
     set_runnable(thread);
     local_irq_save(flags);
-    if(idle_thread != NULL) {
-        minios_list_add_tail(&thread->thread_list, &idle_thread->thread_list); 
-    } else if(function != idle_thread_fn)
-    {
-        printk("BUG: Not allowed to create thread before initialising scheduler.\n");
-        BUG();
-    }
+    MINIOS_TAILQ_INSERT_TAIL(&thread_list, thread, thread_list);
     local_irq_restore(flags);
     return thread;
 }
@@ -208,10 +200,10 @@ void exit_thread(void)
     printk("Thread \"%s\" exited.\n", thread->name);
     local_irq_save(flags);
     /* Remove from the thread list */
-    minios_list_del(&thread->thread_list);
+    MINIOS_TAILQ_REMOVE(&thread_list, thread, thread_list);
     clear_runnable(thread);
     /* Put onto exited list */
-    minios_list_add(&thread->thread_list, &exited_threads);
+    MINIOS_TAILQ_INSERT_HEAD(&exited_threads, thread, thread_list);
     local_irq_restore(flags);
     /* Schedule will free the resources */
     while(1)
@@ -296,6 +288,14 @@ void init_sched(void)
     _REENT_INIT_PTR((&callback_reent))
 #endif
     idle_thread = create_thread("Idle", idle_thread_fn, NULL);
-    MINIOS_INIT_LIST_HEAD(&idle_thread->thread_list);
 }
 
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
index a8081fd..f404eff 100644
--- a/extras/mini-os/xenbus/xenbus.c
+++ b/extras/mini-os/xenbus/xenbus.c
@@ -85,7 +85,7 @@ char **xenbus_wait_for_watch_return(xenbus_event_queue *queue)
         add_waiter(w, xenbus_watch_queue);
         schedule();
     }
-    remove_waiter(w);
+    remove_waiter(w, xenbus_watch_queue);
     *queue = event->next;
     return &event->path;
 }
@@ -441,7 +441,7 @@ xenbus_msg_reply(int type,
     xb_write(type, id, trans, io, nr_reqs);
 
     schedule();
-    remove_waiter(w);
+    remove_waiter(w, req_info[id].waitq);
     wake(current);
 
     rep = req_info[id].reply;
diff --git a/tools/libxl/external/README b/tools/include/xen-external/README
similarity index 69%
rename from tools/libxl/external/README
rename to tools/include/xen-external/README
index 8c8beea..93c2bc9 100644
--- a/tools/libxl/external/README
+++ b/tools/include/xen-external/README
@@ -1,5 +1,5 @@
-WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
------------------------------------------------------------------------
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY
+----------------------------------------------
 
 These files were obtained elsewhere and should only be updated by
 copying new versions from the source location, as documented below:
@@ -12,3 +12,13 @@ bsd-queue.3
     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
+
+Exceptions:
+
+README
+
+  This file
+
+bsd-sys-queue-h-seddery
+
+  Script to transform the above into a new namespace.
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/include/xen-external/bsd-COPYRIGHT
similarity index 100%
rename from tools/libxl/external/bsd-COPYRIGHT
rename to tools/include/xen-external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/include/xen-external/bsd-queue.3
similarity index 100%
rename from tools/libxl/external/bsd-queue.3
rename to tools/include/xen-external/bsd-queue.3
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/include/xen-external/bsd-sys-queue-h-seddery
similarity index 99%
rename from tools/libxl/bsd-sys-queue-h-seddery
rename to tools/include/xen-external/bsd-sys-queue-h-seddery
index c0aa079..7a957e3 100755
--- a/tools/libxl/bsd-sys-queue-h-seddery
+++ b/tools/include/xen-external/bsd-sys-queue-h-seddery
@@ -68,3 +68,5 @@ s/\b(
 s/\b struct \s+ type \b/type/xg;
 
 s,^\#include.*sys/cdefs.*,/* $& */,xg;
+
+s/\b( NULL )/0/xg;
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/include/xen-external/bsd-sys-queue.h
similarity index 100%
rename from tools/libxl/external/bsd-sys-queue.h
rename to tools/include/xen-external/bsd-sys-queue.h
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3c3661b..fcc021a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -93,8 +93,8 @@ _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
+_libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
+	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
 libxl_paths.c: _libxl_paths.h
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5T-0005hz-Ak; Fri, 27 Jan 2012 22:16:03 +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 1Rqu5S-0005h4-EL
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327702555!12696955!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20566 invoked from network); 27 Jan 2012 22:15:56 -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;
	27 Jan 2012 22:15:56 -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
	q0RMFsgt010089; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhJ026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:24 -0500
Message-Id: <1327702543-25211-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/24] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to preserve v2-only features such as sub-page grants will
produce a warning and clear the resulting v1 grant entry.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/grant_table.c         |   58 ++++++++++++++++++++++++++++++++-----
 xen/include/public/grant_table.h |    7 ++++
 2 files changed, 57 insertions(+), 8 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0c55fd1..858d991 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2127,11 +2128,12 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
 
     spin_lock(&gt->lock);
     /* Make sure that the grant table isn't currently in use when we
-       change the version number. */
-    /* (You need to change the version number for e.g. kexec.) */
+       change the version number, except for the first 8 entries which
+       are allowed to be in use (xenstore/xenconsole keeps them mapped).
+       (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2156,15 +2158,55 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if ( gt->gt_version == 1 )
+    {
+        memcpy(reserved_entries, &shared_entry_v1(gt, 0), sizeof(reserved_entries));
+    }
+    else if ( gt->gt_version == 2 )
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            int flags = status_entry(gt, i);
+            flags |= shared_entry_v2(gt, i).hdr.flags;
+            if ((flags & GTF_type_mask) == GTF_permit_access)
+            {
+                reserved_entries[i].flags = flags;
+                reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+                reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            }
+            else
+            {
+                if ((flags & GTF_type_mask) != GTF_invalid)
+                    gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
+                           d->domain_id, flags, i);
+                memset(&reserved_entries[i], 0, sizeof(reserved_entries[i]));
+            }
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if ( gt->gt_version != 0 && op.version == 1 )
     {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+        memcpy(&shared_entry_v1(gt, 0), reserved_entries, sizeof(reserved_entries));
+    }
+    else if ( gt->gt_version != 0 && op.version == 2 )
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 54d9551..292d724 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,13 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* The first few grant table entries will be preserved across grant table
+ * version changes and may be pre-populated at domain creation by tools.
+ */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5a-0005n4-2l; Fri, 27 Jan 2012 22:16:10 +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 1Rqu5U-0005hP-SD
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327702557!9099362!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17775 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-21.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFtgt010093; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhL026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:26 -0500
Message-Id: <1327702543-25211-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/24] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_dom.h              |   16 ++++
 tools/libxc/xc_dom_boot.c         |  156 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 211 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..2aef64a 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -18,6 +18,9 @@
 
 #define INVALID_P2M_ENTRY   ((xen_pfn_t)-1)
 
+/* Scrach PFN for temporary mappings in HVM */
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
 /* --- typedefs and structs ---------------------------------------- */
 
 typedef uint64_t xen_vaddr_t;
@@ -107,6 +110,8 @@ struct xc_dom_image {
     unsigned long flags;
     unsigned int console_evtchn;
     unsigned int xenstore_evtchn;
+    domid_t console_domid;
+    domid_t xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +205,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
+                           xen_pfn_t console_gmfn,
+                           xen_pfn_t xenstore_gmfn,
+                           domid_t console_domid,
+                           domid_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+                       xen_pfn_t console_gmfn,
+                       xen_pfn_t xenstore_gmfn,
+                       domid_t console_domid,
+                       domid_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..a9a868c 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,161 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, domid_t domid)
+{
+    gnttab_setup_table_t setup;
+    DECLARE_HYPERCALL_BUFFER(xen_pfn_t, gmfnp);
+    int rc;
+    xen_pfn_t gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+    if (gmfnp == NULL)
+        return -1;
+
+    setup.dom = domid;
+    setup.nr_frames = 1;
+    set_xen_guest_handle(setup.frame_list, gmfnp);
+    setup.status = 0;
+
+    rc = xc_gnttab_op(xch, GNTTABOP_setup_table, &setup, sizeof(setup), 1);
+    gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+                       xen_pfn_t console_gmfn,
+                       xen_pfn_t xenstore_gmfn,
+                       domid_t console_domid,
+                       domid_t xenstore_domid)
+{
+
+    xen_pfn_t gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
+                           xen_pfn_t console_gpfn,
+                           xen_pfn_t xenstore_gpfn,
+                           domid_t console_domid,
+                           domid_t xenstore_domid)
+{
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+        .domid = domid,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    xen_pfn_t console_gmfn;
+    xen_pfn_t xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..06bea86 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..533e702 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3828c62..1d00227 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -224,7 +224,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -250,6 +252,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -263,7 +269,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                domid_t store_domid, domid_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -296,6 +303,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -349,7 +358,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -387,7 +398,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5X-0005l2-Q0; Fri, 27 Jan 2012 22:16:07 +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 1Rqu5U-0005hD-HW
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327702557!12895680!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3245 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15:58 -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
	q0RMFtpV014548; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhb026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:42 -0500
Message-Id: <1327702543-25211-24-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/24] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 66584f5..a42f552 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1752,6 +1752,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1765,6 +1766,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1825,6 +1827,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index e1c2be7..92c27ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index fa9c8fe..f8c822f 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -259,7 +259,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5T-0005hz-Ak; Fri, 27 Jan 2012 22:16:03 +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 1Rqu5S-0005h4-EL
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327702555!12696955!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20566 invoked from network); 27 Jan 2012 22:15:56 -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;
	27 Jan 2012 22:15:56 -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
	q0RMFsgt010089; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhJ026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:24 -0500
Message-Id: <1327702543-25211-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 05/24] xen: Preserve reserved grant entries when
	switching 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In order for the toolstack to use reserved grant table entries, the
grant table for a guest must be initialized prior to the guest's boot.
When the guest switches grant table versions (necessary if the guest is
using v2 grant tables, or on kexec if switching grant versions), these
initial grants will be cleared. Instead of clearing them, preserve
the grants across the type change.

Attempting to preserve v2-only features such as sub-page grants will
produce a warning and clear the resulting v1 grant entry.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/grant_table.c         |   58 ++++++++++++++++++++++++++++++++-----
 xen/include/public/grant_table.h |    7 ++++
 2 files changed, 57 insertions(+), 8 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0c55fd1..858d991 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2111,6 +2111,7 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
     struct domain *d = current->domain;
     struct grant_table *gt = d->grant_table;
     struct active_grant_entry *act;
+    grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
     long res;
     int i;
 
@@ -2127,11 +2128,12 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
 
     spin_lock(&gt->lock);
     /* Make sure that the grant table isn't currently in use when we
-       change the version number. */
-    /* (You need to change the version number for e.g. kexec.) */
+       change the version number, except for the first 8 entries which
+       are allowed to be in use (xenstore/xenconsole keeps them mapped).
+       (You need to change the version number for e.g. kexec.) */
     if ( gt->gt_version != 0 )
     {
-        for ( i = 0; i < nr_grant_entries(gt); i++ )
+        for ( i = GNTTAB_NR_RESERVED_ENTRIES; i < nr_grant_entries(gt); i++ )
         {
             act = &active_entry(gt, i);
             if ( act->pin != 0 )
@@ -2156,15 +2158,55 @@ gnttab_set_version(XEN_GUEST_HANDLE(gnttab_set_version_t uop))
             goto out_unlock;
     }
 
+    /* Preserve the first 8 entries (toolstack reserved grants) */
+    if ( gt->gt_version == 1 )
+    {
+        memcpy(reserved_entries, &shared_entry_v1(gt, 0), sizeof(reserved_entries));
+    }
+    else if ( gt->gt_version == 2 )
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES && i < nr_grant_entries(gt); i++ )
+        {
+            int flags = status_entry(gt, i);
+            flags |= shared_entry_v2(gt, i).hdr.flags;
+            if ((flags & GTF_type_mask) == GTF_permit_access)
+            {
+                reserved_entries[i].flags = flags;
+                reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
+                reserved_entries[i].frame = shared_entry_v2(gt, i).full_page.frame;
+            }
+            else
+            {
+                if ((flags & GTF_type_mask) != GTF_invalid)
+                    gdprintk(XENLOG_INFO, "d%d: bad flags %x in grant %d when switching grant version\n",
+                           d->domain_id, flags, i);
+                memset(&reserved_entries[i], 0, sizeof(reserved_entries[i]));
+            }
+        }
+    }
+
     if ( op.version < 2 && gt->gt_version == 2 )
         gnttab_unpopulate_status_frames(d, gt);
 
-    if ( op.version != gt->gt_version )
+    /* Make sure there's no crud left over in the table from the
+       old version. */
+    for ( i = 0; i < nr_grant_frames(gt); i++ )
+        memset(gt->shared_raw[i], 0, PAGE_SIZE);
+
+    /* Restore the first 8 entries (toolstack reserved grants) */
+    if ( gt->gt_version != 0 && op.version == 1 )
     {
-        /* Make sure there's no crud left over in the table from the
-           old version. */
-        for ( i = 0; i < nr_grant_frames(gt); i++ )
-            memset(gt->shared_raw[i], 0, PAGE_SIZE);
+        memcpy(&shared_entry_v1(gt, 0), reserved_entries, sizeof(reserved_entries));
+    }
+    else if ( gt->gt_version != 0 && op.version == 2 )
+    {
+        for ( i = 0; i < GNTTAB_NR_RESERVED_ENTRIES; i++ )
+        {
+            status_entry(gt, i) = reserved_entries[i].flags & (GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.flags = reserved_entries[i].flags & ~(GTF_reading|GTF_writing);
+            shared_entry_v2(gt, i).hdr.domid = reserved_entries[i].domid;
+            shared_entry_v2(gt, i).full_page.frame = reserved_entries[i].frame;
+        }
     }
 
     gt->gt_version = op.version;
diff --git a/xen/include/public/grant_table.h b/xen/include/public/grant_table.h
index 54d9551..292d724 100644
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -117,6 +117,13 @@ struct grant_entry_v1 {
 };
 typedef struct grant_entry_v1 grant_entry_v1_t;
 
+/* The first few grant table entries will be preserved across grant table
+ * version changes and may be pre-populated at domain creation by tools.
+ */
+#define GNTTAB_NR_RESERVED_ENTRIES     8
+#define GNTTAB_RESERVED_CONSOLE        0
+#define GNTTAB_RESERVED_XENSTORE       1
+
 /*
  * Type of grant entry.
  *  GTF_invalid: This grant entry grants no privileges.
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5Z-0005mE-BA; Fri, 27 Jan 2012 22:16: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 1Rqu5U-0005hA-LN
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327702557!4358438!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8642 invoked from network); 27 Jan 2012 22:15:57 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-21.messagelabs.com with SMTP;
	27 Jan 2012 22:15:57 -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
	q0RMFtgt010094; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhN026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:28 -0500
Message-Id: <1327702543-25211-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/24] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..af0afed 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+        if (!intf)
+            return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5a-0005n4-2l; Fri, 27 Jan 2012 22:16:10 +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 1Rqu5U-0005hP-SD
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327702557!9099362!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17775 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-21.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFtgt010093; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhL026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:26 -0500
Message-Id: <1327702543-25211-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 07/24] lib{xc,
	xl}: Seed grant tables with xenstore and console 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: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch claims one reserved grant entry for the console and another
for the xenstore. It modifies the builder to fill in the grant table
entries for the console and the xenstore.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01491.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_dom.h              |   16 ++++
 tools/libxc/xc_dom_boot.c         |  156 +++++++++++++++++++++++++++++++++++++
 tools/libxc/xc_dom_compat_linux.c |    2 +
 tools/libxc/xc_domain_restore.c   |   19 ++++-
 tools/libxc/xenguest.h            |    3 +-
 tools/libxl/libxl_dom.c           |   18 ++++-
 tools/xcutils/xc_restore.c        |    4 +-
 7 files changed, 211 insertions(+), 7 deletions(-)

diff --git a/tools/libxc/xc_dom.h b/tools/libxc/xc_dom.h
index e72f066..2aef64a 100644
--- a/tools/libxc/xc_dom.h
+++ b/tools/libxc/xc_dom.h
@@ -18,6 +18,9 @@
 
 #define INVALID_P2M_ENTRY   ((xen_pfn_t)-1)
 
+/* Scrach PFN for temporary mappings in HVM */
+#define SCRATCH_PFN_GNTTAB 0xFFFFE
+
 /* --- typedefs and structs ---------------------------------------- */
 
 typedef uint64_t xen_vaddr_t;
@@ -107,6 +110,8 @@ struct xc_dom_image {
     unsigned long flags;
     unsigned int console_evtchn;
     unsigned int xenstore_evtchn;
+    domid_t console_domid;
+    domid_t xenstore_domid;
     xen_pfn_t shared_info_mfn;
 
     xc_interface *xch;
@@ -200,6 +205,17 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, xen_pfn_t pfn,
                            xen_pfn_t count);
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
+int xc_dom_gnttab_init(struct xc_dom_image *dom);
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
+                           xen_pfn_t console_gmfn,
+                           xen_pfn_t xenstore_gmfn,
+                           domid_t console_domid,
+                           domid_t xenstore_domid);
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+                       xen_pfn_t console_gmfn,
+                       xen_pfn_t xenstore_gmfn,
+                       domid_t console_domid,
+                       domid_t xenstore_domid);
 
 /* --- debugging bits ---------------------------------------------- */
 
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 65f60df..a9a868c 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -34,6 +34,7 @@
 #include "xg_private.h"
 #include "xc_dom.h"
 #include <xen/hvm/params.h>
+#include <xen/grant_table.h>
 
 /* ------------------------------------------------------------------------ */
 
@@ -275,6 +276,161 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
     return rc;
 }
 
+static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, domid_t domid)
+{
+    gnttab_setup_table_t setup;
+    DECLARE_HYPERCALL_BUFFER(xen_pfn_t, gmfnp);
+    int rc;
+    xen_pfn_t gmfn;
+
+    gmfnp = xc_hypercall_buffer_alloc(xch, gmfnp, sizeof(*gmfnp));
+    if (gmfnp == NULL)
+        return -1;
+
+    setup.dom = domid;
+    setup.nr_frames = 1;
+    set_xen_guest_handle(setup.frame_list, gmfnp);
+    setup.status = 0;
+
+    rc = xc_gnttab_op(xch, GNTTABOP_setup_table, &setup, sizeof(setup), 1);
+    gmfn = *gmfnp;
+    xc_hypercall_buffer_free(xch, gmfnp);
+
+    if ( rc != 0 || setup.status != GNTST_okay )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to setup domU grant table "
+                     "[errno=%d, status=%" PRId16 "]\n",
+                     __FUNCTION__, rc != 0 ? errno : 0, setup.status);
+        return -1;
+    }
+
+    return gmfn;
+}
+
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+                       xen_pfn_t console_gmfn,
+                       xen_pfn_t xenstore_gmfn,
+                       domid_t console_domid,
+                       domid_t xenstore_domid)
+{
+
+    xen_pfn_t gnttab_gmfn;
+    grant_entry_v1_t *gnttab;
+
+    gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
+    if ( gnttab_gmfn == -1 )
+        return -1;
+
+    gnttab = xc_map_foreign_range(xch,
+                                  domid,
+                                  PAGE_SIZE,
+                                  PROT_READ|PROT_WRITE,
+                                  gnttab_gmfn);
+    if ( gnttab == NULL )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to map domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    if ( domid != console_domid  && console_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
+        gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
+    }
+    if ( domid != xenstore_domid && xenstore_gmfn != -1)
+    {
+        gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
+        gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
+        gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
+    }
+
+    if ( munmap(gnttab, PAGE_SIZE) == -1 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to unmap domU grant table "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
+                           xen_pfn_t console_gpfn,
+                           xen_pfn_t xenstore_gpfn,
+                           domid_t console_domid,
+                           domid_t xenstore_domid)
+{
+    int rc;
+    struct xen_add_to_physmap xatp = {
+        .domid = domid,
+        .space = XENMAPSPACE_grant_table,
+        .idx   = 0,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+    struct xen_remove_from_physmap xrfp = {
+        .domid = domid,
+        .gpfn  = SCRATCH_PFN_GNTTAB
+    };
+
+    rc = do_memory_op(xch, XENMEM_add_to_physmap, &xatp, sizeof(xatp));
+    if ( rc != 0 )
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to add gnttab to physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    rc = xc_dom_gnttab_seed(xch, domid,
+                            console_gpfn, xenstore_gpfn,
+                            console_domid, xenstore_domid);
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to seed gnttab entries\n",
+                     __FUNCTION__);
+        (void) do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+        return -1;
+    }
+
+    rc = do_memory_op(xch, XENMEM_remove_from_physmap, &xrfp, sizeof(xrfp));
+    if (rc != 0)
+    {
+        xc_dom_panic(xch, XC_INTERNAL_ERROR,
+                     "%s: failed to remove gnttab from physmap "
+                     "[errno=%d]\n",
+                     __FUNCTION__, errno);
+        return -1;
+    }
+
+    return 0;
+}
+
+int xc_dom_gnttab_init(struct xc_dom_image *dom)
+{
+    xen_pfn_t console_gmfn;
+    xen_pfn_t xenstore_gmfn;
+    int autotranslated;
+
+    autotranslated = xc_dom_feature_translated(dom);
+    console_gmfn = autotranslated ?
+           dom->console_pfn : xc_dom_p2m_host(dom, dom->console_pfn);
+    xenstore_gmfn = autotranslated ?
+           dom->xenstore_pfn : xc_dom_p2m_host(dom, dom->xenstore_pfn);
+
+    return xc_dom_gnttab_seed(dom->xch, dom->guest_domid,
+                              console_gmfn, xenstore_gmfn,
+                              dom->console_domid, dom->xenstore_domid);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index 0e78842..2183a3b 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -62,6 +62,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
         goto out;
     if ( (rc = xc_dom_boot_image(dom)) != 0 )
         goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
 
     *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..06bea86 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -1259,7 +1259,8 @@ static int apply_batch(xc_interface *xch, uint32_t dom, struct restore_ctx *ctx,
 
 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,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
                       unsigned long *vm_generationid_addr)
@@ -2018,6 +2019,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         memcpy(ctx->live_p2m, ctx->p2m, dinfo->p2m_size * sizeof(xen_pfn_t));
     munmap(ctx->live_p2m, P2M_FL_ENTRIES * PAGE_SIZE);
 
+    rc = xc_dom_gnttab_seed(xch, dom, *console_mfn, *store_mfn,
+                            console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     DPRINTF("Domain ready to be built.\n");
     rc = 0;
     goto out;
@@ -2076,6 +2085,14 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         goto out;
     }
 
+    rc = xc_dom_gnttab_hvm_seed(xch, dom, *console_mfn, *store_mfn,
+                                console_domid, store_domid);
+    if (rc != 0)
+    {
+        ERROR("error seeding grant table");
+        goto out;
+    }
+
     /* HVM success! */
     rc = 0;
 
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..533e702 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -79,7 +79,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  */
 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,
+                      domid_t store_domid, unsigned int console_evtchn,
+                      unsigned long *console_mfn, domid_t console_domid,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
 		      unsigned long *vm_generationid_addr);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 3828c62..1d00227 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -224,7 +224,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 
     dom->flags = flags;
     dom->console_evtchn = state->console_port;
+    dom->console_domid = state->console_domid;
     dom->xenstore_evtchn = state->store_port;
+    dom->xenstore_domid = state->store_domid;
 
     if ( (ret = xc_dom_boot_xen_init(dom, ctx->xch, domid)) != 0 ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_xen_init failed");
@@ -250,6 +252,10 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_boot_image failed");
         goto out;
     }
+    if ( (ret = xc_dom_gnttab_init(dom)) != 0 ) {
+        LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "xc_dom_gnttab_init failed");
+        goto out;
+    }
 
     state->console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
     state->store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
@@ -263,7 +269,8 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
                                 libxl_domain_build_info *info,
                                 int store_evtchn, unsigned long *store_mfn,
-                                int console_evtchn, unsigned long *console_mfn)
+                                int console_evtchn, unsigned long *console_mfn,
+                                domid_t store_domid, domid_t console_domid)
 {
     struct hvm_info_table *va_hvm;
     uint8_t *va_map, sum;
@@ -296,6 +303,8 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
     xc_set_hvm_param(handle, domid, HVM_PARAM_NESTEDHVM, info->u.hvm.nested_hvm);
     xc_set_hvm_param(handle, domid, HVM_PARAM_STORE_EVTCHN, store_evtchn);
     xc_set_hvm_param(handle, domid, HVM_PARAM_CONSOLE_EVTCHN, console_evtchn);
+
+    xc_dom_gnttab_hvm_seed(handle, domid, *console_mfn, *store_mfn, console_domid, store_domid);
     return 0;
 }
 
@@ -349,7 +358,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
         goto out;
     }
     ret = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
-                               &state->store_mfn, state->console_port, &state->console_mfn);
+                               &state->store_mfn, state->console_port,
+                               &state->console_mfn, state->store_domid,
+                               state->console_domid);
     if (ret) {
         LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, ret, "hvm build set params failed");
         goto out;
@@ -387,7 +398,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     }
     rc = xc_domain_restore(ctx->xch, fd, domid,
                            state->store_port, &state->store_mfn,
-                           state->console_port, &state->console_mfn,
+                           state->store_domid, state->console_port,
+                           &state->console_mfn, state->console_domid,
                            hvm, pae, superpages, no_incr_generationid,
                            &state->vm_generationid_addr);
     if ( rc ) {
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..e41a133 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -45,8 +45,8 @@ main(int argc, char **argv)
     else
 	    superpages = !!hvm;
 
-    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
-                            console_evtchn, &console_mfn, hvm, pae, superpages,
+    ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn, 0,
+                            console_evtchn, &console_mfn, 0, hvm, pae, superpages,
                             0, NULL);
 
     if ( ret == 0 )
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5W-0005jk-Au; Fri, 27 Jan 2012 22:16:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5T-0005hW-Eo
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327702504!54360180!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19061 invoked from network); 27 Jan 2012 22:15:05 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:05 -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
	q0RMFtgt010097; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhQ026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:31 -0500
Message-Id: <1327702543-25211-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/24] mini-os: Move test functions into test.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

While useful, these test functions should not be compiled into every
mini-os instance that we compile.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/Makefile             |    2 +
 extras/mini-os/kernel.c             |  414 -----------------------------------
 extras/mini-os/{kernel.c => test.c} |  139 +-----------
 stubdom/c/minios.cfg                |    1 +
 stubdom/caml/minios.cfg             |    1 +
 5 files changed, 9 insertions(+), 548 deletions(-)
 copy extras/mini-os/{kernel.c => test.c} (80%)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index 48d0d21..b4a9eb4 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -19,6 +19,7 @@ endif
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
+CONFIG_TEST ?= n
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
@@ -63,6 +64,7 @@ src-y += mm.c
 src-y += netfront.c
 src-y += pcifront.c
 src-y += sched.c
+src-$(CONFIG_TEST) += test.c
 
 src-y += lib/ctype.c
 src-y += lib/math.c
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index 2875bf1..c8b9b8c 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -46,8 +46,6 @@
 #include <xen/features.h>
 #include <xen/version.h>
 
-static struct netfront_dev *net_dev;
-
 uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
 
 void setup_xen_features(void)
@@ -66,407 +64,10 @@ void setup_xen_features(void)
     }
 }
 
-void test_xenbus(void);
-
-static void xenbus_tester(void *p)
-{
-    printk("Xenbus tests disabled, because of a Xend bug.\n");
-    /* test_xenbus(); */
-}
-
-static void periodic_thread(void *p)
-{
-    struct timeval tv;
-    printk("Periodic thread started.\n");
-    for(;;)
-    {
-        gettimeofday(&tv, NULL);
-        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
-        msleep(1000);
-    }
-}
-
-static void netfront_thread(void *p)
-{
-    net_dev = init_netfront(NULL, NULL, NULL, NULL);
-}
-
-static struct blkfront_dev *blk_dev;
-static struct blkfront_info blk_info;
-static uint64_t blk_size_read;
-static uint64_t blk_size_write;
-
-struct blk_req {
-    struct blkfront_aiocb aiocb;
-    int rand_value;
-    struct blk_req *next;
-};
-
-#ifdef BLKTEST_WRITE
-static struct blk_req *blk_to_read;
-#endif
-
-static struct blk_req *blk_alloc_req(uint64_t sector)
-{
-    struct blk_req *req = xmalloc(struct blk_req);
-    req->aiocb.aio_dev = blk_dev;
-    req->aiocb.aio_buf = _xmalloc(blk_info.sector_size, blk_info.sector_size);
-    req->aiocb.aio_nbytes = blk_info.sector_size;
-    req->aiocb.aio_offset = sector * blk_info.sector_size;
-    req->aiocb.data = req;
-    req->next = NULL;
-    return req;
-}
-
-static void blk_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret)
-        printk("got error code %d when reading at offset %ld\n", ret, aiocb->aio_offset);
-    else
-        blk_size_read += blk_info.sector_size;
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_read_sector(uint64_t sector)
-{
-    struct blk_req *req;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_read_completed;
-
-    blkfront_aio_read(&req->aiocb);
-}
-
-#ifdef BLKTEST_WRITE
-static void blk_write_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    int rand_value;
-    int i;
-    int *buf;
-
-    if (ret) {
-        printk("got error code %d when reading back at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_read += blk_info.sector_size;
-    buf = (int*) aiocb->aio_buf;
-    rand_value = req->rand_value;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        if (buf[i] != rand_value) {
-            printk("bogus data at offset %ld\n", aiocb->aio_offset + i);
-            break;
-        }
-        rand_value *= RAND_MIX;
-    }
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_write_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret) {
-        printk("got error code %d when writing at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_write += blk_info.sector_size;
-    /* Push write check */
-    req->next = blk_to_read;
-    blk_to_read = req;
-}
-
-static void blk_write_sector(uint64_t sector)
-{
-    struct blk_req *req;
-    int rand_value;
-    int i;
-    int *buf;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_write_completed;
-    req->rand_value = rand_value = rand();
-
-    buf = (int*) req->aiocb.aio_buf;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        buf[i] = rand_value;
-        rand_value *= RAND_MIX;
-    }
-
-    blkfront_aio_write(&req->aiocb);
-}
-#endif
-
-static void blkfront_thread(void *p)
-{
-    time_t lasttime = 0;
-
-    blk_dev = init_blkfront(NULL, &blk_info);
-    if (!blk_dev)
-        return;
-
-    if (blk_info.info & VDISK_CDROM)
-        printk("Block device is a CDROM\n");
-    if (blk_info.info & VDISK_REMOVABLE)
-        printk("Block device is removable\n");
-    if (blk_info.info & VDISK_READONLY)
-        printk("Block device is read-only\n");
-
-#ifdef BLKTEST_WRITE
-    if (blk_info.mode == O_RDWR) {
-        blk_write_sector(0);
-        blk_write_sector(blk_info.sectors-1);
-    } else
-#endif
-    {
-        blk_read_sector(0);
-        blk_read_sector(blk_info.sectors-1);
-    }
-
-    while (1) {
-        uint64_t sector = rand() % blk_info.sectors;
-        struct timeval tv;
-#ifdef BLKTEST_WRITE
-        if (blk_info.mode == O_RDWR)
-            blk_write_sector(sector);
-        else
-#endif
-            blk_read_sector(sector);
-        blkfront_aio_poll(blk_dev);
-        gettimeofday(&tv, NULL);
-        if (tv.tv_sec > lasttime + 10) {
-            printk("%llu read, %llu write\n", blk_size_read, blk_size_write);
-            lasttime = tv.tv_sec;
-        }
-
-#ifdef BLKTEST_WRITE
-        while (blk_to_read) {
-            struct blk_req *req = blk_to_read;
-            blk_to_read = blk_to_read->next;
-            req->aiocb.aio_cb = blk_write_read_completed;
-            blkfront_aio_read(&req->aiocb);
-        }
-#endif
-    }
-}
-
-#define WIDTH 800
-#define HEIGHT 600
-#define DEPTH 32
-
-static uint32_t *fb;
-static int refresh_period = 50;
-static struct fbfront_dev *fb_dev;
-static struct semaphore fbfront_sem = __SEMAPHORE_INITIALIZER(fbfront_sem, 0);
-
-static void fbfront_drawvert(int x, int y1, int y2, uint32_t color)
-{
-    int y;
-    if (x < 0)
-        return;
-    if (x >= WIDTH)
-        return;
-    if (y1 < 0)
-        y1 = 0;
-    if (y2 >= HEIGHT)
-        y2 = HEIGHT-1;
-    for (y = y1; y <= y2; y++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_drawhoriz(int x1, int x2, int y, uint32_t color)
-{
-    int x;
-    if (y < 0)
-        return;
-    if (y >= HEIGHT)
-        return;
-    if (x1 < 0)
-        x1 = 0;
-    if (x2 >= WIDTH)
-        x2 = WIDTH-1;
-    for (x = x1; x <= x2; x++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_thread(void *p)
-{
-    size_t line_length = WIDTH * (DEPTH / 8);
-    size_t memsize = HEIGHT * line_length;
-    unsigned long *mfns;
-    int i, n = (memsize + PAGE_SIZE-1) / PAGE_SIZE;
-
-    memsize = n * PAGE_SIZE;
-    fb = _xmalloc(memsize, PAGE_SIZE);
-    memset(fb, 0, memsize);
-    mfns = xmalloc_array(unsigned long, n);
-    for (i = 0; i < n; i++)
-        mfns[i] = virtual_to_mfn((char *) fb + i * PAGE_SIZE);
-    fb_dev = init_fbfront(NULL, mfns, WIDTH, HEIGHT, DEPTH, line_length, n);
-    xfree(mfns);
-    if (!fb_dev) {
-        xfree(fb);
-        return;
-    }
-    up(&fbfront_sem);
-}
-
-static void clip_cursor(int *x, int *y)
-{
-    if (*x < 0)
-        *x = 0;
-    if (*x >= WIDTH)
-        *x = WIDTH - 1;
-    if (*y < 0)
-        *y = 0;
-    if (*y >= HEIGHT)
-        *y = HEIGHT - 1;
-}
-
-static void refresh_cursor(int new_x, int new_y)
-{
-    static int old_x = -1, old_y = -1;
-
-    if (!refresh_period)
-        return;
-
-    if (old_x != -1 && old_y != -1) {
-        fbfront_drawvert(old_x, old_y + 1, old_y + 8, 0xffffffff);
-        fbfront_drawhoriz(old_x + 1, old_x + 8, old_y, 0xffffffff);
-        fbfront_update(fb_dev, old_x, old_y, 9, 9);
-    }
-    old_x = new_x;
-    old_y = new_y;
-    fbfront_drawvert(new_x, new_y + 1, new_y + 8, 0xffffffff);
-    fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
-    fbfront_update(fb_dev, new_x, new_y, 9, 9);
-}
-
-static struct kbdfront_dev *kbd_dev;
-static void kbdfront_thread(void *p)
-{
-    DEFINE_WAIT(w);
-    DEFINE_WAIT(w2);
-    int x = WIDTH / 2, y = HEIGHT / 2, z = 0;
-
-    kbd_dev = init_kbdfront(NULL, 1);
-    if (!kbd_dev)
-        return;
-
-    down(&fbfront_sem);
-    refresh_cursor(x, y);
-    while (1) {
-        union xenkbd_in_event kbdevent;
-        union xenfb_in_event fbevent;
-        int sleep = 1;
-
-        add_waiter(w, kbdfront_queue);
-        add_waiter(w2, fbfront_queue);
-
-        while (kbdfront_receive(kbd_dev, &kbdevent, 1) != 0) {
-            sleep = 0;
-            switch(kbdevent.type) {
-            case XENKBD_TYPE_MOTION:
-                printk("motion x:%d y:%d z:%d\n",
-                        kbdevent.motion.rel_x,
-                        kbdevent.motion.rel_y,
-                        kbdevent.motion.rel_z);
-                x += kbdevent.motion.rel_x;
-                y += kbdevent.motion.rel_y;
-                z += kbdevent.motion.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_POS:
-                printk("pos x:%d y:%d dz:%d\n",
-                        kbdevent.pos.abs_x,
-                        kbdevent.pos.abs_y,
-                        kbdevent.pos.rel_z);
-                x = kbdevent.pos.abs_x;
-                y = kbdevent.pos.abs_y;
-                z = kbdevent.pos.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_KEY:
-                printk("key %d %s\n",
-                        kbdevent.key.keycode,
-                        kbdevent.key.pressed ? "pressed" : "released");
-                if (kbdevent.key.keycode == BTN_LEFT) {
-                    printk("mouse %s at (%d,%d,%d)\n",
-                            kbdevent.key.pressed ? "clic" : "release", x, y, z);
-                    if (kbdevent.key.pressed) {
-                        uint32_t color = rand();
-                        fbfront_drawvert(x - 16, y - 16, y + 15, color);
-                        fbfront_drawhoriz(x - 16, x + 15, y + 16, color);
-                        fbfront_drawvert(x + 16, y - 15, y + 16, color);
-                        fbfront_drawhoriz(x - 15, x + 16, y - 16, color);
-                        fbfront_update(fb_dev, x - 16, y - 16, 33, 33);
-                    }
-                } else if (kbdevent.key.keycode == KEY_Q) {
-                    struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_poweroff };
-                    HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-                    do_exit();
-                }
-                break;
-            }
-        }
-        while (fbfront_receive(fb_dev, &fbevent, 1) != 0) {
-            sleep = 0;
-            switch(fbevent.type) {
-            case XENFB_TYPE_REFRESH_PERIOD:
-                refresh_period = fbevent.refresh_period.period;
-                printk("refresh period %d\n", refresh_period);
-                refresh_cursor(x, y);
-                break;
-            }
-        }
-        if (sleep)
-            schedule();
-    }
-}
-
-static struct pcifront_dev *pci_dev;
-
-static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
-{
-    unsigned int vendor, device, rev, class;
-
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x00, 2, &vendor);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x02, 2, &device);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x08, 1, &rev);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x0a, 2, &class);
-
-    printk("%04x:%02x:%02x.%02x %04x: %04x:%04x (rev %02x)\n", domain, bus, slot, fun, class, vendor, device, rev);
-}
-
-static void pcifront_thread(void *p)
-{
-    pcifront_watches(NULL);
-    pci_dev = init_pcifront(NULL);
-    if (!pci_dev)
-        return;
-    printk("PCI devices:\n");
-    pcifront_scan(pci_dev, print_pcidev);
-}
-
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
 {
     printk("Dummy main: start_info=%p\n", si);
-    create_thread("xenbus_tester", xenbus_tester, si);
-    create_thread("periodic_thread", periodic_thread, si);
-    create_thread("netfront", netfront_thread, si);
-    create_thread("blkfront", blkfront_thread, si);
-    create_thread("fbfront", fbfront_thread, si);
-    create_thread("kbdfront", kbdfront_thread, si);
-    create_thread("pcifront", pcifront_thread, si);
     return 0;
 }
 
@@ -534,21 +135,6 @@ void start_kernel(start_info_t *si)
 
 void stop_kernel(void)
 {
-    if (net_dev)
-        shutdown_netfront(net_dev);
-
-    if (blk_dev)
-        shutdown_blkfront(blk_dev);
-
-    if (fb_dev)
-        shutdown_fbfront(fb_dev);
-
-    if (kbd_dev)
-        shutdown_kbdfront(kbd_dev);
-
-    if (pci_dev)
-        shutdown_pcifront(pci_dev);
-
     /* TODO: fs import */
 
     local_irq_disable();
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/test.c
similarity index 80%
copy from extras/mini-os/kernel.c
copy to extras/mini-os/test.c
index 2875bf1..9039cb3 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/test.c
@@ -1,8 +1,7 @@
 /******************************************************************************
- * kernel.c
+ * test.c
  * 
- * Assorted crap goes here, including the initial C entry point, jumped at
- * from head.S.
+ * Test code for all the various frontends; split from kernel.c
  * 
  * Copyright (c) 2002-2003, K A Fraser & R Neugebauer
  * Copyright (c) 2005, Grzegorz Milos, Intel Research Cambridge
@@ -48,24 +47,6 @@
 
 static struct netfront_dev *net_dev;
 
-uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
-
-void setup_xen_features(void)
-{
-    xen_feature_info_t fi;
-    int i, j;
-
-    for (i = 0; i < XENFEAT_NR_SUBMAPS; i++) 
-    {
-        fi.submap_idx = i;
-        if (HYPERVISOR_xen_version(XENVER_get_features, &fi) < 0)
-            break;
-        
-        for (j=0; j<32; j++)
-            xen_features[i*32+j] = !!(fi.submap & 1<<j);
-    }
-}
-
 void test_xenbus(void);
 
 static void xenbus_tester(void *p)
@@ -456,10 +437,9 @@ static void pcifront_thread(void *p)
     pcifront_scan(pci_dev, print_pcidev);
 }
 
-/* This should be overridden by the application we are linked against. */
-__attribute__((weak)) int app_main(start_info_t *si)
+int app_main(start_info_t *si)
 {
-    printk("Dummy main: start_info=%p\n", si);
+    printk("Test main: start_info=%p\n", si);
     create_thread("xenbus_tester", xenbus_tester, si);
     create_thread("periodic_thread", periodic_thread, si);
     create_thread("netfront", netfront_thread, si);
@@ -470,69 +450,7 @@ __attribute__((weak)) int app_main(start_info_t *si)
     return 0;
 }
 
-/*
- * INITIAL C ENTRY POINT.
- */
-void start_kernel(start_info_t *si)
-{
-    static char hello[] = "Bootstrapping...\n";
-
-    (void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
-
-    arch_init(si);
-
-    trap_init();
-
-    /* print out some useful information  */
-    printk("Xen Minimal OS!\n");
-    printk("  start_info: %p(VA)\n", si);
-    printk("    nr_pages: 0x%lx\n", si->nr_pages);
-    printk("  shared_inf: 0x%08lx(MA)\n", si->shared_info);
-    printk("     pt_base: %p(VA)\n", (void *)si->pt_base); 
-    printk("nr_pt_frames: 0x%lx\n", si->nr_pt_frames);
-    printk("    mfn_list: %p(VA)\n", (void *)si->mfn_list); 
-    printk("   mod_start: 0x%lx(VA)\n", si->mod_start);
-    printk("     mod_len: %lu\n", si->mod_len); 
-    printk("       flags: 0x%x\n", (unsigned int)si->flags);
-    printk("    cmd_line: %s\n",  
-           si->cmd_line ? (const char *)si->cmd_line : "NULL");
-
-    /* Set up events. */
-    init_events();
-    
-    /* ENABLE EVENT DELIVERY. This is disabled at start of day. */
-    __sti();
-
-    arch_print_info();
-
-    setup_xen_features();
-
-    /* Init memory management. */
-    init_mm();
-
-    /* Init time and timers. */
-    init_time();
-
-    /* Init the console driver. */
-    init_console();
-
-    /* Init grant tables */
-    init_gnttab();
-    
-    /* Init scheduler. */
-    init_sched();
- 
-    /* Init XenBus */
-    init_xenbus();
-
-    /* Call (possibly overridden) app_main() */
-    app_main(&start_info);
-
-    /* Everything initialised, start idle thread */
-    run_idle_thread();
-}
-
-void stop_kernel(void)
+void shutdown_frontends(void)
 {
     if (net_dev)
         shutdown_netfront(net_dev);
@@ -548,51 +466,4 @@ void stop_kernel(void)
 
     if (pci_dev)
         shutdown_pcifront(pci_dev);
-
-    /* TODO: fs import */
-
-    local_irq_disable();
-
-    /* Reset grant tables */
-    fini_gnttab();
-
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
-    /* Reset XenBus */
-    fini_xenbus();
-
-    /* Reset timers */
-    fini_time();
-
-    /* Reset memory management. */
-    fini_mm();
-
-    /* Reset events. */
-    fini_events();
-
-    /* Reset traps */
-    trap_fini();
-
-    /* Reset arch details */
-    arch_fini();
-}
-
-/*
- * do_exit: This is called whenever an IRET fails in entry.S.
- * This will generally be because an application has got itself into
- * a really bad state (probably a bad CS or SS). It must be killed.
- * Of course, minimal OS doesn't have applications :-)
- */
-
-void do_exit(void)
-{
-    printk("Do_exit called!\n");
-    stack_walk();
-    for( ;; )
-    {
-        struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_crash };
-        HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-    }
 }
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/c/minios.cfg
+++ b/stubdom/c/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/caml/minios.cfg
+++ b/stubdom/caml/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5Z-0005mE-BA; Fri, 27 Jan 2012 22:16: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 1Rqu5U-0005hA-LN
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:05 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327702557!4358438!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8642 invoked from network); 27 Jan 2012 22:15:57 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-21.messagelabs.com with SMTP;
	27 Jan 2012 22:15:57 -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
	q0RMFtgt010094; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhN026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:28 -0500
Message-Id: <1327702543-25211-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 09/24] mini-os: avoid crash if no console is
	provided
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/console/xencons_ring.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index 22fd618..af0afed 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -25,7 +25,10 @@ static inline void notify_daemon(struct consfront_dev *dev)
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-    return mfn_to_virt(start_info.console.domU.mfn);
+    if (start_info.console.domU.evtchn)
+        return mfn_to_virt(start_info.console.domU.mfn);
+    else
+        return NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
@@ -38,6 +41,8 @@ int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, uns
             intf = xencons_interface();
         else
             intf = dev->ring;
+        if (!intf)
+            return sent;
 
 	cons = intf->out_cons;
 	prod = intf->out_prod;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5Y-0005la-IG; Fri, 27 Jan 2012 22:16:08 +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 1Rqu5U-0005hM-NJ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327702557!12906769!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8445 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFtgt010102; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhT026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:34 -0500
Message-Id: <1327702543-25211-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/24] xenstored: refactor socket 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>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c |   85 +++++++++++++++++++++------------------
 1 files changed, 46 insertions(+), 39 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..0e7d43f 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -343,13 +343,6 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
-static int destroy_fd(void *_fd)
-{
-	int *fd = _fd;
-	close(*fd);
-	return 0;
-}
-
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
 {
@@ -1705,6 +1698,51 @@ static void daemonize(void)
 	umask(0);
 }
 
+static int destroy_fd(void *_fd)
+{
+	int *fd = _fd;
+	close(*fd);
+	return 0;
+}
+
+static void init_sockets(int **psock, int **pro_sock)
+{
+	struct sockaddr_un addr;
+	int *sock, *ro_sock;
+	/* Create sockets for them to listen to. */
+	*psock = sock = talloc(talloc_autofree_context(), int);
+	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*sock < 0)
+		barf_perror("Could not create socket");
+	*pro_sock = ro_sock = talloc(talloc_autofree_context(), int);
+	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*ro_sock < 0)
+		barf_perror("Could not create socket");
+	talloc_set_destructor(sock, destroy_fd);
+	talloc_set_destructor(ro_sock, destroy_fd);
+
+	/* FIXME: Be more sophisticated, don't mug running daemon. */
+	unlink(xs_daemon_socket());
+	unlink(xs_daemon_socket_ro());
+
+	addr.sun_family = AF_UNIX;
+	strcpy(addr.sun_path, xs_daemon_socket());
+	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s", xs_daemon_socket());
+	strcpy(addr.sun_path, xs_daemon_socket_ro());
+	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s",
+			    xs_daemon_socket_ro());
+	if (chmod(xs_daemon_socket(), 0600) != 0
+	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
+		barf_perror("Could not chmod sockets");
+
+	if (listen(*sock, 1) != 0
+	    || listen(*ro_sock, 1) != 0)
+		barf_perror("Could not listen on sockets");
+
+
+}
 
 static void usage(void)
 {
@@ -1753,7 +1791,6 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
-	struct sockaddr_un addr;
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,40 +1874,10 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
-	/* Create sockets for them to listen to. */
-	sock = talloc(talloc_autofree_context(), int);
-	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*sock < 0)
-		barf_perror("Could not create socket");
-	ro_sock = talloc(talloc_autofree_context(), int);
-	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*ro_sock < 0)
-		barf_perror("Could not create socket");
-	talloc_set_destructor(sock, destroy_fd);
-	talloc_set_destructor(ro_sock, destroy_fd);
-
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
-	/* FIXME: Be more sophisticated, don't mug running daemon. */
-	unlink(xs_daemon_socket());
-	unlink(xs_daemon_socket_ro());
-
-	addr.sun_family = AF_UNIX;
-	strcpy(addr.sun_path, xs_daemon_socket());
-	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s", xs_daemon_socket());
-	strcpy(addr.sun_path, xs_daemon_socket_ro());
-	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s",
-			    xs_daemon_socket_ro());
-	if (chmod(xs_daemon_socket(), 0600) != 0
-	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
-		barf_perror("Could not chmod sockets");
-
-	if (listen(*sock, 1) != 0
-	    || listen(*ro_sock, 1) != 0)
-		barf_perror("Could not listen on sockets");
+	init_sockets(&sock, &ro_sock);
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5U-0005iP-3C; Fri, 27 Jan 2012 22:16:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5S-0005hB-8h
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327702503!54360178!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19037 invoked from network); 27 Jan 2012 22:15:03 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:03 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0RMFtpV014538; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhM026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:27 -0500
Message-Id: <1327702543-25211-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 08/24] mini-os: use BSD sys/queue.h instead of
	Linux 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>
MIME-Version: 1.0
Content-Type: text/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>

The latter is GPL which makes the whole of mini-os GPL rather than BSD
as intended. In tree users are all GPL or GPL-compatible but we should
fix this so that mini-os is BSD. Do so by using the same BSD
sys/queue.h as we use in libxl.

Tested with the builtin mini-os test app and qemu stubdomain, both of which
appear to still function as expected.

Move tools/libxl/external and the associated sed script to
tools/include/xen-external to allow more sensible access from mini-os.

Also add s/NULL/0/ in the sed script due to NULL not always being
defined in stubdom code when mini-os/wait.h is included.

As well as the obvious ABI changes there are a few API updates
associated with the change:

  - struct rw_semaphore.wait_list is unused
  - remove_waiter needs to take the wait_queue_head

The latter requires a qemu update which I will post separately. Please
apply first and update QEMU_TAG as appropriate.

I sprinkled some extra-emacs local variables around the files I edited
which didn't have them.

I think this should be backported to the stable branches since
external users of mini-os may have been mislead into thinking they
could safely link mini-os against GPL-incompatible code.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 .hgignore                                          |    1 +
 extras/mini-os/Makefile                            |    9 +-
 extras/mini-os/blkfront.c                          |    6 +-
 extras/mini-os/fbfront.c                           |    2 +-
 extras/mini-os/include/list.h                      |  190 --------------------
 extras/mini-os/include/sched.h                     |    2 +-
 extras/mini-os/include/semaphore.h                 |    1 -
 extras/mini-os/include/wait.h                      |   56 ++++---
 extras/mini-os/include/waittypes.h                 |   26 ++-
 extras/mini-os/lib/sys.c                           |   38 ++--
 extras/mini-os/lib/xmalloc.c                       |   43 +++---
 extras/mini-os/sched.c                             |   48 +++---
 extras/mini-os/xenbus/xenbus.c                     |    4 +-
 .../external => include/xen-external}/README       |   14 ++-
 .../xen-external}/bsd-COPYRIGHT                    |    0
 .../external => include/xen-external}/bsd-queue.3  |    0
 .../xen-external}/bsd-sys-queue-h-seddery          |    2 +
 .../xen-external}/bsd-sys-queue.h                  |    0
 tools/libxl/Makefile                               |    4 +-
 19 files changed, 145 insertions(+), 301 deletions(-)
 delete mode 100644 extras/mini-os/include/list.h
 rename tools/{libxl/external => include/xen-external}/README (69%)
 rename tools/{libxl/external => include/xen-external}/bsd-COPYRIGHT (100%)
 rename tools/{libxl/external => include/xen-external}/bsd-queue.3 (100%)
 rename tools/{libxl => include/xen-external}/bsd-sys-queue-h-seddery (99%)
 rename tools/{libxl/external => include/xen-external}/bsd-sys-queue.h (100%)

diff --git a/.hgignore b/.hgignore
index 64b440e..e295c00 100644
--- a/.hgignore
+++ b/.hgignore
@@ -62,6 +62,7 @@
 ^docs/xen-api/xenapi-datamodel-graph.eps$
 ^docs/xen-api/xenapi.out$
 ^extras/mini-os/arch/ia64/gen_off.s$
+^extras/mini-os/include/list\.h$
 ^extras/mini-os/include/mini-os$
 ^extras/mini-os/include/ia64/mini-os$
 ^extras/mini-os/include/ia64/offsets.h$
diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c2ee062..c4d26f0 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -52,8 +52,12 @@ $(ARCH_LINKS):
 	$(arch_links)
 endif
 
+include/list.h: $(XEN_ROOT)/tools/include/xen-external/bsd-sys-queue-h-seddery $(XEN_ROOT)/tools/include/xen-external/bsd-sys-queue.h
+	perl $^ --prefix=minios  >$@.new
+	$(call move-if-changed,$@.new,$@)
+
 .PHONY: links
-links:	$(ARCH_LINKS)
+links: include/list.h $(ARCH_LINKS)
 	[ -e include/xen ] || ln -sf ../../../xen/include/public include/xen
 	[ -e include/mini-os ] || ln -sf . include/mini-os
 	[ -e include/$(TARGET_ARCH_FAM)/mini-os ] || ln -sf . include/$(TARGET_ARCH_FAM)/mini-os
@@ -97,7 +101,7 @@ ifneq ($(APP_OBJS),)
 APP_O=$(OBJ_DIR)/$(TARGET)_app.o 
 endif
 
-$(OBJ_DIR)/$(TARGET): links $(OBJS) $(APP_O) arch_lib
+$(OBJ_DIR)/$(TARGET): links include/list.h $(OBJS) $(APP_O) arch_lib
 	$(LD) -r $(LDFLAGS) $(HEAD_OBJ) $(APP_O) $(OBJS) $(LDARCHLIB) $(LDLIBS) -o $@.o
 	$(OBJCOPY) -w -G $(GLOBAL_PREFIX)* -G _start $@.o $@.o
 	$(LD) $(LDFLAGS) $(LDFLAGS_FINAL) $@.o $(EXTRA_OBJS) -o $@
@@ -112,6 +116,7 @@ clean:	arch_clean
 	for dir in $(addprefix $(OBJ_DIR)/,$(SUBDIRS)); do \
 		rm -f $$dir/*.o; \
 	done
+	rm -f include/list.h
 	rm -f $(OBJ_DIR)/*.o *~ $(OBJ_DIR)/core $(OBJ_DIR)/$(TARGET).elf $(OBJ_DIR)/$(TARGET).raw $(OBJ_DIR)/$(TARGET) $(OBJ_DIR)/$(TARGET).gz
 	find . $(OBJ_DIR) -type l | xargs rm -f
 	$(RM) $(OBJ_DIR)/lwip.a $(LWO)
diff --git a/extras/mini-os/blkfront.c b/extras/mini-os/blkfront.c
index 695d8e6..bb3d91e 100644
--- a/extras/mini-os/blkfront.c
+++ b/extras/mini-os/blkfront.c
@@ -323,7 +323,7 @@ static void blkfront_wait_slot(struct blkfront_dev *dev)
 	    schedule();
 	    local_irq_save(flags);
 	}
-	remove_waiter(w);
+	remove_waiter(w, blkfront_queue);
 	local_irq_restore(flags);
     }
 }
@@ -414,7 +414,7 @@ void blkfront_io(struct blkfront_aiocb *aiocbp, int write)
 	schedule();
 	local_irq_save(flags);
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
     local_irq_restore(flags);
 }
 
@@ -470,7 +470,7 @@ void blkfront_sync(struct blkfront_dev *dev)
 	schedule();
 	local_irq_save(flags);
     }
-    remove_waiter(w);
+    remove_waiter(w, blkfront_queue);
     local_irq_restore(flags);
 }
 
diff --git a/extras/mini-os/fbfront.c b/extras/mini-os/fbfront.c
index 8d03e5b..9889376 100644
--- a/extras/mini-os/fbfront.c
+++ b/extras/mini-os/fbfront.c
@@ -569,7 +569,7 @@ static void fbfront_out_event(struct fbfront_dev *dev, union xenfb_out_event *ev
     add_waiter(w, fbfront_queue);
     while (page->out_prod - page->out_cons == XENFB_OUT_RING_LEN)
         schedule();
-    remove_waiter(w);
+    remove_waiter(w, fbfront_queue);
 
     prod = page->out_prod;
     mb(); /* ensure ring space available */
diff --git a/extras/mini-os/include/list.h b/extras/mini-os/include/list.h
deleted file mode 100644
index a60ae23..0000000
--- a/extras/mini-os/include/list.h
+++ /dev/null
@@ -1,190 +0,0 @@
-#ifndef _LINUX_LIST_H
-#define _LINUX_LIST_H
-
-/*
- * Simple doubly linked list implementation.
- *
- * Some of the internal functions ("__xxx") are useful when
- * manipulating whole lists rather than single entries, as
- * sometimes we already know the next/prev entries and we can
- * generate better code by using them directly rather than
- * using the generic single-entry routines.
- */
-
-struct minios_list_head {
-	struct minios_list_head *next, *prev;
-};
-
-#define MINIOS_LIST_HEAD_INIT(name) { &(name), &(name) }
-
-#define MINIOS_LIST_HEAD(name) \
-	struct minios_list_head name = MINIOS_LIST_HEAD_INIT(name)
-
-#define MINIOS_INIT_LIST_HEAD(ptr) do { \
-	(ptr)->next = (ptr); (ptr)->prev = (ptr); \
-} while (0)
-
-#define minios_list_top(head, type, member)					  \
-({ 									  \
-	struct minios_list_head *_head = (head);				  \
-	minios_list_empty(_head) ? NULL : minios_list_entry(_head->next, type, member); \
-})
-
-/*
- * Insert a new entry between two known consecutive entries. 
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static __inline__ void __minios_list_add(struct minios_list_head * new,
-	struct minios_list_head * prev,
-	struct minios_list_head * next)
-{
-	next->prev = new;
-	new->next = next;
-	new->prev = prev;
-	prev->next = new;
-}
-
-/**
- * minios_list_add - add a new entry
- * @new: new entry to be added
- * @head: list head to add it after
- *
- * Insert a new entry after the specified head.
- * This is good for implementing stacks.
- */
-static __inline__ void minios_list_add(struct minios_list_head *new, struct minios_list_head *head)
-{
-	__minios_list_add(new, head, head->next);
-}
-
-/**
- * minios_list_add_tail - add a new entry
- * @new: new entry to be added
- * @head: list head to add it before
- *
- * Insert a new entry before the specified head.
- * This is useful for implementing queues.
- */
-static __inline__ void minios_list_add_tail(struct minios_list_head *new, struct minios_list_head *head)
-{
-	__minios_list_add(new, head->prev, head);
-}
-
-/*
- * Delete a list entry by making the prev/next entries
- * point to each other.
- *
- * This is only for internal list manipulation where we know
- * the prev/next entries already!
- */
-static __inline__ void __minios_list_del(struct minios_list_head * prev,
-				  struct minios_list_head * next)
-{
-	next->prev = prev;
-	prev->next = next;
-}
-
-/**
- * minios_list_del - deletes entry from list.
- * @entry: the element to delete from the list.
- * Note: minios_list_empty on entry does not return true after this, the entry is in an undefined state.
- */
-static __inline__ void minios_list_del(struct minios_list_head *entry)
-{
-	__minios_list_del(entry->prev, entry->next);
-}
-
-/**
- * minios_list_del_init - deletes entry from list and reinitialize it.
- * @entry: the element to delete from the list.
- */
-static __inline__ void minios_list_del_init(struct minios_list_head *entry)
-{
-	__minios_list_del(entry->prev, entry->next);
-	MINIOS_INIT_LIST_HEAD(entry); 
-}
-
-/**
- * minios_list_empty - tests whether a list is empty
- * @head: the list to test.
- */
-static __inline__ int minios_list_empty(struct minios_list_head *head)
-{
-	return head->next == head;
-}
-
-/**
- * minios_list_splice - join two lists
- * @list: the new list to add.
- * @head: the place to add it in the first list.
- */
-static __inline__ void minios_list_splice(struct minios_list_head *list, struct minios_list_head *head)
-{
-	struct minios_list_head *first = list->next;
-
-	if (first != list) {
-		struct minios_list_head *last = list->prev;
-		struct minios_list_head *at = head->next;
-
-		first->prev = head;
-		head->next = first;
-
-		last->next = at;
-		at->prev = last;
-	}
-}
-
-/**
- * minios_list_entry - get the struct for this entry
- * @ptr:	the &struct minios_list_head pointer.
- * @type:	the type of the struct this is embedded in.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_entry(ptr, type, member) \
-	((type *)((char *)(ptr)-(unsigned long)(&((type *)0)->member)))
-
-/**
- * minios_list_for_each	-	iterate over a list
- * @pos:	the &struct minios_list_head to use as a loop counter.
- * @head:	the head for your list.
- */
-#define minios_list_for_each(pos, head) \
-	for (pos = (head)->next; pos != (head); pos = pos->next)
-        	
-/**
- * minios_list_for_each_safe	-	iterate over a list safe against removal of list entry
- * @pos:	the &struct minios_list_head to use as a loop counter.
- * @n:		another &struct minios_list_head to use as temporary storage
- * @head:	the head for your list.
- */
-#define minios_list_for_each_safe(pos, n, head) \
-	for (pos = (head)->next, n = pos->next; pos != (head); \
-		pos = n, n = pos->next)
-
-/**
- * minios_list_for_each_entry	-	iterate over list of given type
- * @pos:	the type * to use as a loop counter.
- * @head:	the head for your list.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_for_each_entry(pos, head, member)				\
-	for (pos = minios_list_entry((head)->next, typeof(*pos), member);	\
-	     &pos->member != (head); 					\
-	     pos = minios_list_entry(pos->member.next, typeof(*pos), member))
-
-/**
- * minios_list_for_each_entry_safe - iterate over list of given type safe against removal of list entry
- * @pos:	the type * to use as a loop counter.
- * @n:		another type * to use as temporary storage
- * @head:	the head for your list.
- * @member:	the name of the minios_list_struct within the struct.
- */
-#define minios_list_for_each_entry_safe(pos, n, head, member)			\
-	for (pos = minios_list_entry((head)->next, typeof(*pos), member),	\
-		n = minios_list_entry(pos->member.next, typeof(*pos), member);	\
-	     &pos->member != (head); 					\
-	     pos = n, n = minios_list_entry(n->member.next, typeof(*n), member))
-#endif /* _LINUX_LIST_H */
-
diff --git a/extras/mini-os/include/sched.h b/extras/mini-os/include/sched.h
index 538bed5..ea3239d 100644
--- a/extras/mini-os/include/sched.h
+++ b/extras/mini-os/include/sched.h
@@ -19,7 +19,7 @@ struct thread
 #else /* !defined(__ia64__) */
     thread_regs_t regs;
 #endif /* !defined(__ia64__) */
-    struct minios_list_head thread_list;
+    MINIOS_TAILQ_ENTRY(struct thread) thread_list;
     uint32_t flags;
     s_time_t wakeup_time;
 #ifdef HAVE_LIBC
diff --git a/extras/mini-os/include/semaphore.h b/extras/mini-os/include/semaphore.h
index 8236046..47470c5 100644
--- a/extras/mini-os/include/semaphore.h
+++ b/extras/mini-os/include/semaphore.h
@@ -21,7 +21,6 @@ struct semaphore
 struct rw_semaphore {
 	signed long		count;
 	spinlock_t		wait_lock;
-	struct minios_list_head	wait_list;
 	int			debug;
 };
 
diff --git a/extras/mini-os/include/wait.h b/extras/mini-os/include/wait.h
index 10b9f29..bffa3c4 100644
--- a/extras/mini-os/include/wait.h
+++ b/extras/mini-os/include/wait.h
@@ -5,47 +5,47 @@
 #include <mini-os/os.h>
 #include <mini-os/waittypes.h>
 
-#define DEFINE_WAIT(name)                               \
-struct wait_queue name = {                              \
-    .thread       = get_current(),                            \
-    .thread_list  = MINIOS_LIST_HEAD_INIT((name).thread_list), \
+#define DEFINE_WAIT(name)                          \
+struct wait_queue name = {                         \
+    .thread       = get_current(),                 \
+    .waiting      = 0,                             \
 }
 
 
 static inline void init_waitqueue_head(struct wait_queue_head *h)
 {
-  MINIOS_INIT_LIST_HEAD(&h->thread_list);
+    MINIOS_STAILQ_INIT(h);
 }
 
 static inline void init_waitqueue_entry(struct wait_queue *q, struct thread *thread)
 {
     q->thread = thread;
-    MINIOS_INIT_LIST_HEAD(&q->thread_list);
+    q->waiting = 0;
 }
 
-
 static inline void add_wait_queue(struct wait_queue_head *h, struct wait_queue *q)
 {
-    if (minios_list_empty(&q->thread_list))
-        minios_list_add(&q->thread_list, &h->thread_list);   
+    if (!q->waiting) {
+        MINIOS_STAILQ_INSERT_HEAD(h, q, thread_list);
+        q->waiting = 1;
+    }
 }
 
-static inline void remove_wait_queue(struct wait_queue *q)
+static inline void remove_wait_queue(struct wait_queue_head *h, struct wait_queue *q)
 {
-    minios_list_del(&q->thread_list);
+    if (q->waiting) {
+        MINIOS_STAILQ_REMOVE(h, q, struct wait_queue, thread_list);
+        q->waiting = 0;
+    }
 }
 
 static inline void wake_up(struct wait_queue_head *head)
 {
     unsigned long flags;
-    struct minios_list_head *tmp, *next;
+    struct wait_queue *curr, *tmp;
     local_irq_save(flags);
-    minios_list_for_each_safe(tmp, next, &head->thread_list)
-    {
-         struct wait_queue *curr;
-         curr = minios_list_entry(tmp, struct wait_queue, thread_list);
+    MINIOS_STAILQ_FOREACH_SAFE(curr, head, thread_list, tmp)
          wake(curr->thread);
-    }
     local_irq_restore(flags);
 }
 
@@ -57,11 +57,11 @@ static inline void wake_up(struct wait_queue_head *head)
     local_irq_restore(flags);   \
 } while (0)
 
-#define remove_waiter(w) do {   \
-    unsigned long flags;        \
-    local_irq_save(flags);      \
-    remove_wait_queue(&w);      \
-    local_irq_restore(flags);   \
+#define remove_waiter(w, wq) do {  \
+    unsigned long flags;           \
+    local_irq_save(flags);         \
+    remove_wait_queue(&wq, &w);    \
+    local_irq_restore(flags);      \
 } while (0)
 
 #define wait_event_deadline(wq, condition, deadline) do {       \
@@ -84,7 +84,7 @@ static inline void wake_up(struct wait_queue_head *head)
     local_irq_save(flags);                                      \
     /* need to wake up */                                       \
     wake(get_current());                                        \
-    remove_wait_queue(&__wait);                                 \
+    remove_wait_queue(&wq, &__wait);                            \
     local_irq_restore(flags);                                   \
 } while(0) 
 
@@ -93,3 +93,13 @@ static inline void wake_up(struct wait_queue_head *head)
 
 
 #endif /* __WAIT_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/include/waittypes.h b/extras/mini-os/include/waittypes.h
index 1215ffe..78d91c1 100644
--- a/extras/mini-os/include/waittypes.h
+++ b/extras/mini-os/include/waittypes.h
@@ -6,21 +6,27 @@
 struct thread;
 struct wait_queue
 {
+    int waiting;
     struct thread *thread;
-    struct minios_list_head thread_list;
+    MINIOS_STAILQ_ENTRY(struct wait_queue) thread_list;
 };
 
-struct wait_queue_head
-{
-    /* TODO - lock required? */
-    struct minios_list_head thread_list;
-};
+/* TODO - lock required? */
+MINIOS_STAILQ_HEAD(wait_queue_head, struct wait_queue);
 
 #define DECLARE_WAIT_QUEUE_HEAD(name) \
-   struct wait_queue_head name =     \
-        { .thread_list = { &(name).thread_list, &(name).thread_list} }
+    struct wait_queue_head name = MINIOS_STAILQ_HEAD_INITIALIZER(name)
 
-#define __WAIT_QUEUE_HEAD_INITIALIZER(name) {                           \
-    .thread_list      = { &(name).thread_list, &(name).thread_list } }
+#define __WAIT_QUEUE_HEAD_INITIALIZER(name) MINIOS_STAILQ_HEAD_INITIALIZER(name)
 
 #endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index b7b3aff..2329a78 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -234,7 +234,7 @@ int read(int fd, void *buf, size_t nbytes)
                     break;
                 schedule();
             }
-            remove_waiter(w);
+            remove_waiter(w, console_queue);
             return ret;
         }
 #ifdef HAVE_LWIP
@@ -705,12 +705,12 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     fd_set myread, mywrite, myexcept;
     struct thread *thread = get_current();
     s_time_t start = NOW(), stop;
-    DEFINE_WAIT(w1);
-    DEFINE_WAIT(w2);
-    DEFINE_WAIT(w3);
-    DEFINE_WAIT(w4);
-    DEFINE_WAIT(w5);
-    DEFINE_WAIT(w6);
+    DEFINE_WAIT(netfront_w);
+    DEFINE_WAIT(event_w);
+    DEFINE_WAIT(blkfront_w);
+    DEFINE_WAIT(xenbus_watch_w);
+    DEFINE_WAIT(kbdfront_w);
+    DEFINE_WAIT(console_w);
 
     assert(thread == main_thread);
 
@@ -727,12 +727,12 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
-    add_waiter(w1, netfront_queue);
-    add_waiter(w2, event_queue);
-    add_waiter(w3, blkfront_queue);
-    add_waiter(w4, xenbus_watch_queue);
-    add_waiter(w5, kbdfront_queue);
-    add_waiter(w6, console_queue);
+    add_waiter(netfront_w, netfront_queue);
+    add_waiter(event_w, event_queue);
+    add_waiter(blkfront_w, blkfront_queue);
+    add_waiter(xenbus_watch_w, xenbus_watch_queue);
+    add_waiter(kbdfront_w, kbdfront_queue);
+    add_waiter(console_w, console_queue);
 
     if (readfds)
         myread = *readfds;
@@ -814,12 +814,12 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     ret = -1;
 
 out:
-    remove_waiter(w1);
-    remove_waiter(w2);
-    remove_waiter(w3);
-    remove_waiter(w4);
-    remove_waiter(w5);
-    remove_waiter(w6);
+    remove_waiter(netfront_w, netfront_queue);
+    remove_waiter(event_w, event_queue);
+    remove_waiter(blkfront_w, blkfront_queue);
+    remove_waiter(xenbus_watch_w, xenbus_watch_queue);
+    remove_waiter(kbdfront_w, kbdfront_queue);
+    remove_waiter(console_w, console_queue);
     return ret;
 }
 
diff --git a/extras/mini-os/lib/xmalloc.c b/extras/mini-os/lib/xmalloc.c
index c7d3fc1..015cd31 100644
--- a/extras/mini-os/lib/xmalloc.c
+++ b/extras/mini-os/lib/xmalloc.c
@@ -44,16 +44,18 @@
 #include <mini-os/xmalloc.h>
 
 #ifndef HAVE_LIBC
-static MINIOS_LIST_HEAD(freelist);
 /* static spinlock_t freelist_lock = SPIN_LOCK_UNLOCKED; */
 
 struct xmalloc_hdr
 {
     /* Total including this hdr, unused padding and second hdr. */
     size_t size;
-    struct minios_list_head freelist;
+    MINIOS_TAILQ_ENTRY(struct xmalloc_hdr) freelist;
 } __cacheline_aligned;
 
+static MINIOS_TAILQ_HEAD(,struct xmalloc_hdr) freelist =
+	MINIOS_TAILQ_HEAD_INITIALIZER(freelist);
+
 /* Unused padding data between the two hdrs. */
 
 struct xmalloc_pad
@@ -82,7 +84,7 @@ static void maybe_split(struct xmalloc_hdr *hdr, size_t size, size_t block)
         extra = (struct xmalloc_hdr *)((unsigned long)hdr + size);
         extra->size = leftover;
         /* spin_lock_irqsave(&freelist_lock, flags); */
-        minios_list_add(&extra->freelist, &freelist);
+        MINIOS_TAILQ_INSERT_HEAD(&freelist, extra, freelist);
         /* spin_unlock_irqrestore(&freelist_lock, flags); */
     }
     else
@@ -91,8 +93,6 @@ static void maybe_split(struct xmalloc_hdr *hdr, size_t size, size_t block)
     }
 
     hdr->size = size;
-    /* Debugging aid. */
-    hdr->freelist.next = hdr->freelist.prev = NULL;
 }
 
 static struct xmalloc_hdr *xmalloc_new_page(size_t size)
@@ -128,8 +128,6 @@ static void *xmalloc_whole_pages(size_t size, size_t align)
         return NULL;
 
     hdr->size = (1UL << (pageorder + PAGE_SHIFT));
-    /* Debugging aid. */
-    hdr->freelist.next = hdr->freelist.prev = NULL;
 
     ret = (char*)hdr + hdr_size;
     pad = (struct xmalloc_pad *) ret - 1;
@@ -155,14 +153,14 @@ void *_xmalloc(size_t size, size_t align)
 
     /* Search free list. */
     /* spin_lock_irqsave(&freelist_lock, flags); */
-    minios_list_for_each_entry_safe( i, tmp, &freelist, freelist )
+    MINIOS_TAILQ_FOREACH_SAFE(i, &freelist, freelist, tmp)
     {
         data_begin = align_up((uintptr_t)i + hdr_size, align);
 
         if ( data_begin + size > (uintptr_t)i + i->size )
             continue;
 
-        minios_list_del(&i->freelist);
+        MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
         /* spin_unlock_irqrestore(&freelist_lock, flags); */
 
         uintptr_t size_before = (data_begin - hdr_size) - (uintptr_t)i;
@@ -173,7 +171,7 @@ void *_xmalloc(size_t size, size_t align)
             new_i->size = i->size - size_before;
             i->size = size_before;
             /* spin_lock_irqsave(&freelist_lock, flags); */
-            minios_list_add(&i->freelist, &freelist);
+            MINIOS_TAILQ_INSERT_HEAD(&freelist, i, freelist);
             /* spin_unlock_irqrestore(&freelist_lock, flags); */
             i = new_i;
         }
@@ -224,16 +222,9 @@ void xfree(const void *p)
         *(int*)0=0;
     }
 
-    /* Not previously freed. */
-    if(hdr->freelist.next || hdr->freelist.prev)
-    {
-        printk("Should not be previously freed\n");
-        *(int*)0=0;
-    }
-
     /* Merge with other free block, or put in list. */
     /* spin_lock_irqsave(&freelist_lock, flags); */
-    minios_list_for_each_entry_safe( i, tmp, &freelist, freelist )
+    MINIOS_TAILQ_FOREACH_SAFE(i, &freelist, freelist, tmp)
     {
         unsigned long _i   = (unsigned long)i;
         unsigned long _hdr = (unsigned long)hdr;
@@ -245,7 +236,7 @@ void xfree(const void *p)
         /* We follow this block?  Swallow it. */
         if ( (_i + i->size) == _hdr )
         {
-            minios_list_del(&i->freelist);
+            MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
             i->size += hdr->size;
             hdr = i;
         }
@@ -253,7 +244,7 @@ void xfree(const void *p)
         /* We precede this block? Swallow it. */
         if ( (_hdr + hdr->size) == _i )
         {
-            minios_list_del(&i->freelist);
+            MINIOS_TAILQ_REMOVE(&freelist, i, freelist);
             hdr->size += i->size;
         }
     }
@@ -270,7 +261,7 @@ void xfree(const void *p)
     }
     else
     {
-        minios_list_add(&hdr->freelist, &freelist);
+        MINIOS_TAILQ_INSERT_HEAD(&freelist, hdr, freelist);
     }
 
     /* spin_unlock_irqrestore(&freelist_lock, flags); */
@@ -306,3 +297,13 @@ void *_realloc(void *ptr, size_t size)
     return new;
 }
 #endif
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/sched.c b/extras/mini-os/sched.c
index c0229c5..2d27bfa 100644
--- a/extras/mini-os/sched.c
+++ b/extras/mini-os/sched.c
@@ -54,19 +54,20 @@
 #define DEBUG(_f, _a...)    ((void)0)
 #endif
 
+MINIOS_TAILQ_HEAD(thread_list, struct thread);
+
 struct thread *idle_thread = NULL;
-MINIOS_LIST_HEAD(exited_threads);
+static struct thread_list exited_threads = MINIOS_TAILQ_HEAD_INITIALIZER(exited_threads);
+static struct thread_list thread_list = MINIOS_TAILQ_HEAD_INITIALIZER(thread_list);
 static int threads_started;
 
 struct thread *main_thread;
 
 void inline print_runqueue(void)
 {
-    struct minios_list_head *it;
     struct thread *th;
-    minios_list_for_each(it, &idle_thread->thread_list)
+    MINIOS_TAILQ_FOREACH(th, &thread_list, thread_list)
     {
-        th = minios_list_entry(it, struct thread, thread_list);
         printk("   Thread \"%s\", runnable=%d\n", th->name, is_runnable(th));
     }
     printk("\n");
@@ -74,8 +75,7 @@ void inline print_runqueue(void)
 
 void schedule(void)
 {
-    struct thread *prev, *next, *thread;
-    struct minios_list_head *iterator, *next_iterator;
+    struct thread *prev, *next, *thread, *tmp;
     unsigned long flags;
 
     prev = current;
@@ -96,10 +96,9 @@ void schedule(void)
            time when the next timeout expires, else use 10 seconds. */
         s_time_t now = NOW();
         s_time_t min_wakeup_time = now + SECONDS(10);
-        next = NULL;   
-        minios_list_for_each_safe(iterator, next_iterator, &idle_thread->thread_list)
+        next = NULL;
+        MINIOS_TAILQ_FOREACH_SAFE(thread, &thread_list, thread_list, tmp)
         {
-            thread = minios_list_entry(iterator, struct thread, thread_list);
             if (!is_runnable(thread) && thread->wakeup_time != 0LL)
             {
                 if (thread->wakeup_time <= now)
@@ -111,8 +110,8 @@ void schedule(void)
             {
                 next = thread;
                 /* Put this thread on the end of the list */
-                minios_list_del(&thread->thread_list);
-                minios_list_add_tail(&thread->thread_list, &idle_thread->thread_list);
+                MINIOS_TAILQ_REMOVE(&thread_list, thread, thread_list);
+                MINIOS_TAILQ_INSERT_TAIL(&thread_list, thread, thread_list);
                 break;
             }
         }
@@ -128,12 +127,11 @@ void schedule(void)
        inturrupted at the return instruction. And therefore at safe point. */
     if(prev != next) switch_threads(prev, next);
 
-    minios_list_for_each_safe(iterator, next_iterator, &exited_threads)
+    MINIOS_TAILQ_FOREACH_SAFE(thread, &exited_threads, thread_list, tmp)
     {
-        thread = minios_list_entry(iterator, struct thread, thread_list);
         if(thread != prev)
         {
-            minios_list_del(&thread->thread_list);
+            MINIOS_TAILQ_REMOVE(&exited_threads, thread, thread_list);
             free_pages(thread->stack, STACK_SIZE_PAGE_ORDER);
             xfree(thread);
         }
@@ -154,13 +152,7 @@ struct thread* create_thread(char *name, void (*function)(void *), void *data)
 #endif
     set_runnable(thread);
     local_irq_save(flags);
-    if(idle_thread != NULL) {
-        minios_list_add_tail(&thread->thread_list, &idle_thread->thread_list); 
-    } else if(function != idle_thread_fn)
-    {
-        printk("BUG: Not allowed to create thread before initialising scheduler.\n");
-        BUG();
-    }
+    MINIOS_TAILQ_INSERT_TAIL(&thread_list, thread, thread_list);
     local_irq_restore(flags);
     return thread;
 }
@@ -208,10 +200,10 @@ void exit_thread(void)
     printk("Thread \"%s\" exited.\n", thread->name);
     local_irq_save(flags);
     /* Remove from the thread list */
-    minios_list_del(&thread->thread_list);
+    MINIOS_TAILQ_REMOVE(&thread_list, thread, thread_list);
     clear_runnable(thread);
     /* Put onto exited list */
-    minios_list_add(&thread->thread_list, &exited_threads);
+    MINIOS_TAILQ_INSERT_HEAD(&exited_threads, thread, thread_list);
     local_irq_restore(flags);
     /* Schedule will free the resources */
     while(1)
@@ -296,6 +288,14 @@ void init_sched(void)
     _REENT_INIT_PTR((&callback_reent))
 #endif
     idle_thread = create_thread("Idle", idle_thread_fn, NULL);
-    MINIOS_INIT_LIST_HEAD(&idle_thread->thread_list);
 }
 
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/extras/mini-os/xenbus/xenbus.c b/extras/mini-os/xenbus/xenbus.c
index a8081fd..f404eff 100644
--- a/extras/mini-os/xenbus/xenbus.c
+++ b/extras/mini-os/xenbus/xenbus.c
@@ -85,7 +85,7 @@ char **xenbus_wait_for_watch_return(xenbus_event_queue *queue)
         add_waiter(w, xenbus_watch_queue);
         schedule();
     }
-    remove_waiter(w);
+    remove_waiter(w, xenbus_watch_queue);
     *queue = event->next;
     return &event->path;
 }
@@ -441,7 +441,7 @@ xenbus_msg_reply(int type,
     xb_write(type, id, trans, io, nr_reqs);
 
     schedule();
-    remove_waiter(w);
+    remove_waiter(w, req_info[id].waitq);
     wake(current);
 
     rep = req_info[id].reply;
diff --git a/tools/libxl/external/README b/tools/include/xen-external/README
similarity index 69%
rename from tools/libxl/external/README
rename to tools/include/xen-external/README
index 8c8beea..93c2bc9 100644
--- a/tools/libxl/external/README
+++ b/tools/include/xen-external/README
@@ -1,5 +1,5 @@
-WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY (apart from this README)
------------------------------------------------------------------------
+WARNING - DO NOT EDIT THINGS IN THIS DIRECTORY
+----------------------------------------------
 
 These files were obtained elsewhere and should only be updated by
 copying new versions from the source location, as documented below:
@@ -12,3 +12,13 @@ bsd-queue.3
     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
+
+Exceptions:
+
+README
+
+  This file
+
+bsd-sys-queue-h-seddery
+
+  Script to transform the above into a new namespace.
diff --git a/tools/libxl/external/bsd-COPYRIGHT b/tools/include/xen-external/bsd-COPYRIGHT
similarity index 100%
rename from tools/libxl/external/bsd-COPYRIGHT
rename to tools/include/xen-external/bsd-COPYRIGHT
diff --git a/tools/libxl/external/bsd-queue.3 b/tools/include/xen-external/bsd-queue.3
similarity index 100%
rename from tools/libxl/external/bsd-queue.3
rename to tools/include/xen-external/bsd-queue.3
diff --git a/tools/libxl/bsd-sys-queue-h-seddery b/tools/include/xen-external/bsd-sys-queue-h-seddery
similarity index 99%
rename from tools/libxl/bsd-sys-queue-h-seddery
rename to tools/include/xen-external/bsd-sys-queue-h-seddery
index c0aa079..7a957e3 100755
--- a/tools/libxl/bsd-sys-queue-h-seddery
+++ b/tools/include/xen-external/bsd-sys-queue-h-seddery
@@ -68,3 +68,5 @@ s/\b(
 s/\b struct \s+ type \b/type/xg;
 
 s,^\#include.*sys/cdefs.*,/* $& */,xg;
+
+s/\b( NULL )/0/xg;
diff --git a/tools/libxl/external/bsd-sys-queue.h b/tools/include/xen-external/bsd-sys-queue.h
similarity index 100%
rename from tools/libxl/external/bsd-sys-queue.h
rename to tools/include/xen-external/bsd-sys-queue.h
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 3c3661b..fcc021a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -93,8 +93,8 @@ _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
+_libxl_list.h: $(XEN_INCLUDE)/xen-external/bsd-sys-queue-h-seddery $(XEN_INCLUDE)/xen-external/bsd-sys-queue.h
+	perl $^ --prefix=libxl >$@.new
 	$(call move-if-changed,$@.new,$@)
 
 libxl_paths.c: _libxl_paths.h
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5V-0005jc-V0; Fri, 27 Jan 2012 22:16:05 +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 1Rqu5T-0005h7-5R
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327702555!12781667!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4438 invoked from network); 27 Jan 2012 22:15:56 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15:56 -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
	q0RMFspV014510; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhF026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:20 -0500
Message-Id: <1327702543-25211-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/24] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/compat/memory.c  |   14 ++++++++++++++
 xen/common/memory.c         |   37 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-ia64/mm.h   |    1 +
 xen/include/public/memory.h |   16 ++++++++++++++++
 xen/include/xlat.lst        |    1 +
 xen/include/xsm/xsm.h       |    6 ++++++
 xen/xsm/dummy.c             |    6 ++++++
 xen/xsm/flask/hooks.c       |    6 ++++++
 8 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 2402984..e7257cc 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -25,6 +25,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             XEN_GUEST_HANDLE(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
+            struct xen_remove_from_physmap *xrfp;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
@@ -179,6 +180,18 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             nat.hnd = compat;
             break;
 
+        case XENMEM_remove_from_physmap:
+        {
+            struct compat_remove_from_physmap cmp;
+
+            if ( copy_from_guest(&cmp, compat, 1) )
+                return -EFAULT;
+
+            XLAT_remove_from_physmap(nat.xrfp, &cmp);
+
+            break;
+        }
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -284,6 +297,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
         case XENMEM_current_reservation:
         case XENMEM_maximum_reservation:
         case XENMEM_maximum_gpfn:
+        case XENMEM_remove_from_physmap:
             break;
 
         default:
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8d45439..53886ce 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -659,6 +659,43 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
 
         break;
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+        else
+            rc = -ENOENT;
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     default:
         rc = arch_memory_op(op, arg);
         break;
diff --git a/xen/include/asm-ia64/mm.h b/xen/include/asm-ia64/mm.h
index d09c363..a2bfc02 100644
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -550,6 +550,7 @@ extern u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__,
 #define gmfn_to_mfn(_d, gpfn)			\
     gmfn_to_mfn_foreign((_d), (gpfn))
 
+#define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
 #define put_gfn(d, g)   ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index f602155..3d4f1e3 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -60,6 +60,7 @@
 !	memory_map			memory.h
 !	memory_reservation		memory.h
 !	pod_target			memory.h
+!	remove_from_physmap		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5V-0005jc-V0; Fri, 27 Jan 2012 22:16:05 +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 1Rqu5T-0005h7-5R
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327702555!12781667!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4438 invoked from network); 27 Jan 2012 22:15:56 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-10.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15:56 -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
	q0RMFspV014510; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhF026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:20 -0500
Message-Id: <1327702543-25211-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 01/24] xen: reinstate previously unused
	XENMEM_remove_from_physmap 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This patch reinstates the XENMEM_remove_from_physmap hypercall
which was removed in 19041:ee62aaafff46 because it was not used.

However, is now needed in order to support xenstored stub domains.
The xenstored stub domain is not priviliged like dom0 and so cannot
unilaterally map the xenbus page of other guests into it's address
space.  Therefore, before creating a domU the domain builder needs to
seed its grant table with a grant ref allowing the xenstored stub
domain to access the new domU's xenbus page.

At present domU's do not start with their grant table mapped.
Instead it gets mapped when the guest requests a grant table from
the hypervisor.

In order to seed the grant table, the domain builder first needs to
map it into dom0 address space.  But the hypercall to do this
requires a gpfn (guest pfn), which is an mfn for PV guest, but a pfn
for HVM guests.  Therfore, in order to seed the grant table of an
HVM guest, dom0 needs to *temporarily* map it into the guest's
"physical" address space.

Hence the need to reinstate the XENMEM_remove_from_physmap hypercall.

Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/compat/memory.c  |   14 ++++++++++++++
 xen/common/memory.c         |   37 +++++++++++++++++++++++++++++++++++++
 xen/include/asm-ia64/mm.h   |    1 +
 xen/include/public/memory.h |   16 ++++++++++++++++
 xen/include/xlat.lst        |    1 +
 xen/include/xsm/xsm.h       |    6 ++++++
 xen/xsm/dummy.c             |    6 ++++++
 xen/xsm/flask/hooks.c       |    6 ++++++
 8 files changed, 87 insertions(+), 0 deletions(-)

diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index 2402984..e7257cc 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -25,6 +25,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             XEN_GUEST_HANDLE(void) hnd;
             struct xen_memory_reservation *rsrv;
             struct xen_memory_exchange *xchg;
+            struct xen_remove_from_physmap *xrfp;
         } nat;
         union {
             struct compat_memory_reservation rsrv;
@@ -179,6 +180,18 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
             nat.hnd = compat;
             break;
 
+        case XENMEM_remove_from_physmap:
+        {
+            struct compat_remove_from_physmap cmp;
+
+            if ( copy_from_guest(&cmp, compat, 1) )
+                return -EFAULT;
+
+            XLAT_remove_from_physmap(nat.xrfp, &cmp);
+
+            break;
+        }
+
         default:
             return compat_arch_memory_op(cmd, compat);
         }
@@ -284,6 +297,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE(void) compat)
         case XENMEM_current_reservation:
         case XENMEM_maximum_reservation:
         case XENMEM_maximum_gpfn:
+        case XENMEM_remove_from_physmap:
             break;
 
         default:
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 8d45439..53886ce 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -659,6 +659,43 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE(void) arg)
 
         break;
 
+    case XENMEM_remove_from_physmap:
+    {
+        struct xen_remove_from_physmap xrfp;
+        unsigned long mfn;
+        struct domain *d;
+
+        if ( copy_from_guest(&xrfp, arg, 1) )
+            return -EFAULT;
+
+        rc = rcu_lock_target_domain_by_id(xrfp.domid, &d);
+        if ( rc != 0 )
+            return rc;
+
+        if ( xsm_remove_from_physmap(current->domain, d) )
+        {
+            rcu_unlock_domain(d);
+            return -EPERM;
+        }
+
+        domain_lock(d);
+
+        mfn = get_gfn_untyped(d, xrfp.gpfn);
+
+        if ( mfn_valid(mfn) )
+            guest_physmap_remove_page(d, xrfp.gpfn, mfn, PAGE_ORDER_4K);
+        else
+            rc = -ENOENT;
+
+        put_gfn(d, xrfp.gpfn);
+
+        domain_unlock(d);
+
+        rcu_unlock_domain(d);
+
+        break;
+    }
+
     default:
         rc = arch_memory_op(op, arg);
         break;
diff --git a/xen/include/asm-ia64/mm.h b/xen/include/asm-ia64/mm.h
index d09c363..a2bfc02 100644
--- a/xen/include/asm-ia64/mm.h
+++ b/xen/include/asm-ia64/mm.h
@@ -550,6 +550,7 @@ extern u64 translate_domain_pte(u64 pteval, u64 address, u64 itir__,
 #define gmfn_to_mfn(_d, gpfn)			\
     gmfn_to_mfn_foreign((_d), (gpfn))
 
+#define get_gfn_untyped(d, gpfn) gmfn_to_mfn(d, gpfn)
 #define put_gfn(d, g)   ((void)0)
 
 #define __gpfn_invalid(_d, gpfn)			\
diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
index c5b78a8..308deff 100644
--- a/xen/include/public/memory.h
+++ b/xen/include/public/memory.h
@@ -229,6 +229,22 @@ struct xen_add_to_physmap {
 typedef struct xen_add_to_physmap xen_add_to_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_add_to_physmap_t);
 
+/*
+ * Unmaps the page appearing at a particular GPFN from the specified guest's
+ * pseudophysical address space.
+ * arg == addr of xen_remove_from_physmap_t.
+ */
+#define XENMEM_remove_from_physmap      15
+struct xen_remove_from_physmap {
+    /* Which domain to change the mapping for. */
+    domid_t domid;
+
+    /* GPFN of the current mapping of the page. */
+    xen_pfn_t     gpfn;
+};
+typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
+DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
+
 /*** REMOVED ***/
 /*#define XENMEM_translate_gpfn_list  8*/
 
diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst
index f602155..3d4f1e3 100644
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -60,6 +60,7 @@
 !	memory_map			memory.h
 !	memory_reservation		memory.h
 !	pod_target			memory.h
+!	remove_from_physmap		memory.h
 ?	physdev_eoi			physdev.h
 ?	physdev_get_free_pirq		physdev.h
 ?	physdev_irq			physdev.h
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index df6cec2..566c808 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -169,6 +169,7 @@ struct xsm_operations {
     int (*update_va_mapping) (struct domain *d, struct domain *f, 
                                                             l1_pgentry_t pte);
     int (*add_to_physmap) (struct domain *d1, struct domain *d2);
+    int (*remove_from_physmap) (struct domain *d1, struct domain *d2);
     int (*sendtrigger) (struct domain *d);
     int (*bind_pt_irq) (struct domain *d, struct xen_domctl_bind_pt_irq *bind);
     int (*unbind_pt_irq) (struct domain *d);
@@ -738,6 +739,11 @@ static inline int xsm_add_to_physmap(struct domain *d1, struct domain *d2)
     return xsm_call(add_to_physmap(d1, d2));
 }
 
+static inline int xsm_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return xsm_call(remove_from_physmap(d1, d2));
+}
+
 static inline int xsm_sendtrigger(struct domain *d)
 {
     return xsm_call(sendtrigger(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 4bbfbff..65daa4e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -529,6 +529,11 @@ static int dummy_add_to_physmap (struct domain *d1, struct domain *d2)
     return 0;
 }
 
+static int dummy_remove_from_physmap (struct domain *d1, struct domain *d2)
+{
+    return 0;
+}
+
 static int dummy_sendtrigger (struct domain *d)
 {
     return 0;
@@ -690,6 +695,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, mmu_machphys_update);
     set_to_dummy_if_null(ops, update_va_mapping);
     set_to_dummy_if_null(ops, add_to_physmap);
+    set_to_dummy_if_null(ops, remove_from_physmap);
     set_to_dummy_if_null(ops, sendtrigger);
     set_to_dummy_if_null(ops, bind_pt_irq);
     set_to_dummy_if_null(ops, pin_mem_cacheattr);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0d35767..a2020a9 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1283,6 +1283,11 @@ static int flask_add_to_physmap(struct domain *d1, struct domain *d2)
     return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
 }
 
+static int flask_remove_from_physmap(struct domain *d1, struct domain *d2)
+{
+    return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
+}
+
 static int flask_sendtrigger(struct domain *d)
 {
     return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__TRIGGER);
@@ -1550,6 +1555,7 @@ static struct xsm_operations flask_ops = {
     .mmu_machphys_update = flask_mmu_machphys_update,
     .update_va_mapping = flask_update_va_mapping,
     .add_to_physmap = flask_add_to_physmap,
+    .remove_from_physmap = flask_remove_from_physmap,
     .sendtrigger = flask_sendtrigger,
     .get_device_group = flask_get_device_group,
     .test_assign_device = flask_test_assign_device,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5W-0005jk-Au; Fri, 27 Jan 2012 22:16:06 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5T-0005hW-Eo
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:03 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327702504!54360180!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=1.4 required=7.0 tests=INFO_TLD
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19061 invoked from network); 27 Jan 2012 22:15:05 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:05 -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
	q0RMFtgt010097; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhQ026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:31 -0500
Message-Id: <1327702543-25211-13-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 12/24] mini-os: Move test functions into test.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

While useful, these test functions should not be compiled into every
mini-os instance that we compile.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/Makefile             |    2 +
 extras/mini-os/kernel.c             |  414 -----------------------------------
 extras/mini-os/{kernel.c => test.c} |  139 +-----------
 stubdom/c/minios.cfg                |    1 +
 stubdom/caml/minios.cfg             |    1 +
 5 files changed, 9 insertions(+), 548 deletions(-)
 copy extras/mini-os/{kernel.c => test.c} (80%)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index 48d0d21..b4a9eb4 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -19,6 +19,7 @@ endif
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
+CONFIG_TEST ?= n
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
@@ -63,6 +64,7 @@ src-y += mm.c
 src-y += netfront.c
 src-y += pcifront.c
 src-y += sched.c
+src-$(CONFIG_TEST) += test.c
 
 src-y += lib/ctype.c
 src-y += lib/math.c
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index 2875bf1..c8b9b8c 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -46,8 +46,6 @@
 #include <xen/features.h>
 #include <xen/version.h>
 
-static struct netfront_dev *net_dev;
-
 uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
 
 void setup_xen_features(void)
@@ -66,407 +64,10 @@ void setup_xen_features(void)
     }
 }
 
-void test_xenbus(void);
-
-static void xenbus_tester(void *p)
-{
-    printk("Xenbus tests disabled, because of a Xend bug.\n");
-    /* test_xenbus(); */
-}
-
-static void periodic_thread(void *p)
-{
-    struct timeval tv;
-    printk("Periodic thread started.\n");
-    for(;;)
-    {
-        gettimeofday(&tv, NULL);
-        printk("T(s=%ld us=%ld)\n", tv.tv_sec, tv.tv_usec);
-        msleep(1000);
-    }
-}
-
-static void netfront_thread(void *p)
-{
-    net_dev = init_netfront(NULL, NULL, NULL, NULL);
-}
-
-static struct blkfront_dev *blk_dev;
-static struct blkfront_info blk_info;
-static uint64_t blk_size_read;
-static uint64_t blk_size_write;
-
-struct blk_req {
-    struct blkfront_aiocb aiocb;
-    int rand_value;
-    struct blk_req *next;
-};
-
-#ifdef BLKTEST_WRITE
-static struct blk_req *blk_to_read;
-#endif
-
-static struct blk_req *blk_alloc_req(uint64_t sector)
-{
-    struct blk_req *req = xmalloc(struct blk_req);
-    req->aiocb.aio_dev = blk_dev;
-    req->aiocb.aio_buf = _xmalloc(blk_info.sector_size, blk_info.sector_size);
-    req->aiocb.aio_nbytes = blk_info.sector_size;
-    req->aiocb.aio_offset = sector * blk_info.sector_size;
-    req->aiocb.data = req;
-    req->next = NULL;
-    return req;
-}
-
-static void blk_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret)
-        printk("got error code %d when reading at offset %ld\n", ret, aiocb->aio_offset);
-    else
-        blk_size_read += blk_info.sector_size;
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_read_sector(uint64_t sector)
-{
-    struct blk_req *req;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_read_completed;
-
-    blkfront_aio_read(&req->aiocb);
-}
-
-#ifdef BLKTEST_WRITE
-static void blk_write_read_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    int rand_value;
-    int i;
-    int *buf;
-
-    if (ret) {
-        printk("got error code %d when reading back at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_read += blk_info.sector_size;
-    buf = (int*) aiocb->aio_buf;
-    rand_value = req->rand_value;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        if (buf[i] != rand_value) {
-            printk("bogus data at offset %ld\n", aiocb->aio_offset + i);
-            break;
-        }
-        rand_value *= RAND_MIX;
-    }
-    free(aiocb->aio_buf);
-    free(req);
-}
-
-static void blk_write_completed(struct blkfront_aiocb *aiocb, int ret)
-{
-    struct blk_req *req = aiocb->data;
-    if (ret) {
-        printk("got error code %d when writing at offset %ld\n", ret, aiocb->aio_offset);
-        free(aiocb->aio_buf);
-        free(req);
-        return;
-    }
-    blk_size_write += blk_info.sector_size;
-    /* Push write check */
-    req->next = blk_to_read;
-    blk_to_read = req;
-}
-
-static void blk_write_sector(uint64_t sector)
-{
-    struct blk_req *req;
-    int rand_value;
-    int i;
-    int *buf;
-
-    req = blk_alloc_req(sector);
-    req->aiocb.aio_cb = blk_write_completed;
-    req->rand_value = rand_value = rand();
-
-    buf = (int*) req->aiocb.aio_buf;
-    for (i = 0; i < blk_info.sector_size / sizeof(int); i++) {
-        buf[i] = rand_value;
-        rand_value *= RAND_MIX;
-    }
-
-    blkfront_aio_write(&req->aiocb);
-}
-#endif
-
-static void blkfront_thread(void *p)
-{
-    time_t lasttime = 0;
-
-    blk_dev = init_blkfront(NULL, &blk_info);
-    if (!blk_dev)
-        return;
-
-    if (blk_info.info & VDISK_CDROM)
-        printk("Block device is a CDROM\n");
-    if (blk_info.info & VDISK_REMOVABLE)
-        printk("Block device is removable\n");
-    if (blk_info.info & VDISK_READONLY)
-        printk("Block device is read-only\n");
-
-#ifdef BLKTEST_WRITE
-    if (blk_info.mode == O_RDWR) {
-        blk_write_sector(0);
-        blk_write_sector(blk_info.sectors-1);
-    } else
-#endif
-    {
-        blk_read_sector(0);
-        blk_read_sector(blk_info.sectors-1);
-    }
-
-    while (1) {
-        uint64_t sector = rand() % blk_info.sectors;
-        struct timeval tv;
-#ifdef BLKTEST_WRITE
-        if (blk_info.mode == O_RDWR)
-            blk_write_sector(sector);
-        else
-#endif
-            blk_read_sector(sector);
-        blkfront_aio_poll(blk_dev);
-        gettimeofday(&tv, NULL);
-        if (tv.tv_sec > lasttime + 10) {
-            printk("%llu read, %llu write\n", blk_size_read, blk_size_write);
-            lasttime = tv.tv_sec;
-        }
-
-#ifdef BLKTEST_WRITE
-        while (blk_to_read) {
-            struct blk_req *req = blk_to_read;
-            blk_to_read = blk_to_read->next;
-            req->aiocb.aio_cb = blk_write_read_completed;
-            blkfront_aio_read(&req->aiocb);
-        }
-#endif
-    }
-}
-
-#define WIDTH 800
-#define HEIGHT 600
-#define DEPTH 32
-
-static uint32_t *fb;
-static int refresh_period = 50;
-static struct fbfront_dev *fb_dev;
-static struct semaphore fbfront_sem = __SEMAPHORE_INITIALIZER(fbfront_sem, 0);
-
-static void fbfront_drawvert(int x, int y1, int y2, uint32_t color)
-{
-    int y;
-    if (x < 0)
-        return;
-    if (x >= WIDTH)
-        return;
-    if (y1 < 0)
-        y1 = 0;
-    if (y2 >= HEIGHT)
-        y2 = HEIGHT-1;
-    for (y = y1; y <= y2; y++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_drawhoriz(int x1, int x2, int y, uint32_t color)
-{
-    int x;
-    if (y < 0)
-        return;
-    if (y >= HEIGHT)
-        return;
-    if (x1 < 0)
-        x1 = 0;
-    if (x2 >= WIDTH)
-        x2 = WIDTH-1;
-    for (x = x1; x <= x2; x++)
-        fb[x + y*WIDTH] ^= color;
-}
-
-static void fbfront_thread(void *p)
-{
-    size_t line_length = WIDTH * (DEPTH / 8);
-    size_t memsize = HEIGHT * line_length;
-    unsigned long *mfns;
-    int i, n = (memsize + PAGE_SIZE-1) / PAGE_SIZE;
-
-    memsize = n * PAGE_SIZE;
-    fb = _xmalloc(memsize, PAGE_SIZE);
-    memset(fb, 0, memsize);
-    mfns = xmalloc_array(unsigned long, n);
-    for (i = 0; i < n; i++)
-        mfns[i] = virtual_to_mfn((char *) fb + i * PAGE_SIZE);
-    fb_dev = init_fbfront(NULL, mfns, WIDTH, HEIGHT, DEPTH, line_length, n);
-    xfree(mfns);
-    if (!fb_dev) {
-        xfree(fb);
-        return;
-    }
-    up(&fbfront_sem);
-}
-
-static void clip_cursor(int *x, int *y)
-{
-    if (*x < 0)
-        *x = 0;
-    if (*x >= WIDTH)
-        *x = WIDTH - 1;
-    if (*y < 0)
-        *y = 0;
-    if (*y >= HEIGHT)
-        *y = HEIGHT - 1;
-}
-
-static void refresh_cursor(int new_x, int new_y)
-{
-    static int old_x = -1, old_y = -1;
-
-    if (!refresh_period)
-        return;
-
-    if (old_x != -1 && old_y != -1) {
-        fbfront_drawvert(old_x, old_y + 1, old_y + 8, 0xffffffff);
-        fbfront_drawhoriz(old_x + 1, old_x + 8, old_y, 0xffffffff);
-        fbfront_update(fb_dev, old_x, old_y, 9, 9);
-    }
-    old_x = new_x;
-    old_y = new_y;
-    fbfront_drawvert(new_x, new_y + 1, new_y + 8, 0xffffffff);
-    fbfront_drawhoriz(new_x + 1, new_x + 8, new_y, 0xffffffff);
-    fbfront_update(fb_dev, new_x, new_y, 9, 9);
-}
-
-static struct kbdfront_dev *kbd_dev;
-static void kbdfront_thread(void *p)
-{
-    DEFINE_WAIT(w);
-    DEFINE_WAIT(w2);
-    int x = WIDTH / 2, y = HEIGHT / 2, z = 0;
-
-    kbd_dev = init_kbdfront(NULL, 1);
-    if (!kbd_dev)
-        return;
-
-    down(&fbfront_sem);
-    refresh_cursor(x, y);
-    while (1) {
-        union xenkbd_in_event kbdevent;
-        union xenfb_in_event fbevent;
-        int sleep = 1;
-
-        add_waiter(w, kbdfront_queue);
-        add_waiter(w2, fbfront_queue);
-
-        while (kbdfront_receive(kbd_dev, &kbdevent, 1) != 0) {
-            sleep = 0;
-            switch(kbdevent.type) {
-            case XENKBD_TYPE_MOTION:
-                printk("motion x:%d y:%d z:%d\n",
-                        kbdevent.motion.rel_x,
-                        kbdevent.motion.rel_y,
-                        kbdevent.motion.rel_z);
-                x += kbdevent.motion.rel_x;
-                y += kbdevent.motion.rel_y;
-                z += kbdevent.motion.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_POS:
-                printk("pos x:%d y:%d dz:%d\n",
-                        kbdevent.pos.abs_x,
-                        kbdevent.pos.abs_y,
-                        kbdevent.pos.rel_z);
-                x = kbdevent.pos.abs_x;
-                y = kbdevent.pos.abs_y;
-                z = kbdevent.pos.rel_z;
-                clip_cursor(&x, &y);
-                refresh_cursor(x, y);
-                break;
-            case XENKBD_TYPE_KEY:
-                printk("key %d %s\n",
-                        kbdevent.key.keycode,
-                        kbdevent.key.pressed ? "pressed" : "released");
-                if (kbdevent.key.keycode == BTN_LEFT) {
-                    printk("mouse %s at (%d,%d,%d)\n",
-                            kbdevent.key.pressed ? "clic" : "release", x, y, z);
-                    if (kbdevent.key.pressed) {
-                        uint32_t color = rand();
-                        fbfront_drawvert(x - 16, y - 16, y + 15, color);
-                        fbfront_drawhoriz(x - 16, x + 15, y + 16, color);
-                        fbfront_drawvert(x + 16, y - 15, y + 16, color);
-                        fbfront_drawhoriz(x - 15, x + 16, y - 16, color);
-                        fbfront_update(fb_dev, x - 16, y - 16, 33, 33);
-                    }
-                } else if (kbdevent.key.keycode == KEY_Q) {
-                    struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_poweroff };
-                    HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-                    do_exit();
-                }
-                break;
-            }
-        }
-        while (fbfront_receive(fb_dev, &fbevent, 1) != 0) {
-            sleep = 0;
-            switch(fbevent.type) {
-            case XENFB_TYPE_REFRESH_PERIOD:
-                refresh_period = fbevent.refresh_period.period;
-                printk("refresh period %d\n", refresh_period);
-                refresh_cursor(x, y);
-                break;
-            }
-        }
-        if (sleep)
-            schedule();
-    }
-}
-
-static struct pcifront_dev *pci_dev;
-
-static void print_pcidev(unsigned int domain, unsigned int bus, unsigned int slot, unsigned int fun)
-{
-    unsigned int vendor, device, rev, class;
-
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x00, 2, &vendor);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x02, 2, &device);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x08, 1, &rev);
-    pcifront_conf_read(pci_dev, domain, bus, slot, fun, 0x0a, 2, &class);
-
-    printk("%04x:%02x:%02x.%02x %04x: %04x:%04x (rev %02x)\n", domain, bus, slot, fun, class, vendor, device, rev);
-}
-
-static void pcifront_thread(void *p)
-{
-    pcifront_watches(NULL);
-    pci_dev = init_pcifront(NULL);
-    if (!pci_dev)
-        return;
-    printk("PCI devices:\n");
-    pcifront_scan(pci_dev, print_pcidev);
-}
-
 /* This should be overridden by the application we are linked against. */
 __attribute__((weak)) int app_main(start_info_t *si)
 {
     printk("Dummy main: start_info=%p\n", si);
-    create_thread("xenbus_tester", xenbus_tester, si);
-    create_thread("periodic_thread", periodic_thread, si);
-    create_thread("netfront", netfront_thread, si);
-    create_thread("blkfront", blkfront_thread, si);
-    create_thread("fbfront", fbfront_thread, si);
-    create_thread("kbdfront", kbdfront_thread, si);
-    create_thread("pcifront", pcifront_thread, si);
     return 0;
 }
 
@@ -534,21 +135,6 @@ void start_kernel(start_info_t *si)
 
 void stop_kernel(void)
 {
-    if (net_dev)
-        shutdown_netfront(net_dev);
-
-    if (blk_dev)
-        shutdown_blkfront(blk_dev);
-
-    if (fb_dev)
-        shutdown_fbfront(fb_dev);
-
-    if (kbd_dev)
-        shutdown_kbdfront(kbd_dev);
-
-    if (pci_dev)
-        shutdown_pcifront(pci_dev);
-
     /* TODO: fs import */
 
     local_irq_disable();
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/test.c
similarity index 80%
copy from extras/mini-os/kernel.c
copy to extras/mini-os/test.c
index 2875bf1..9039cb3 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/test.c
@@ -1,8 +1,7 @@
 /******************************************************************************
- * kernel.c
+ * test.c
  * 
- * Assorted crap goes here, including the initial C entry point, jumped at
- * from head.S.
+ * Test code for all the various frontends; split from kernel.c
  * 
  * Copyright (c) 2002-2003, K A Fraser & R Neugebauer
  * Copyright (c) 2005, Grzegorz Milos, Intel Research Cambridge
@@ -48,24 +47,6 @@
 
 static struct netfront_dev *net_dev;
 
-uint8_t xen_features[XENFEAT_NR_SUBMAPS * 32];
-
-void setup_xen_features(void)
-{
-    xen_feature_info_t fi;
-    int i, j;
-
-    for (i = 0; i < XENFEAT_NR_SUBMAPS; i++) 
-    {
-        fi.submap_idx = i;
-        if (HYPERVISOR_xen_version(XENVER_get_features, &fi) < 0)
-            break;
-        
-        for (j=0; j<32; j++)
-            xen_features[i*32+j] = !!(fi.submap & 1<<j);
-    }
-}
-
 void test_xenbus(void);
 
 static void xenbus_tester(void *p)
@@ -456,10 +437,9 @@ static void pcifront_thread(void *p)
     pcifront_scan(pci_dev, print_pcidev);
 }
 
-/* This should be overridden by the application we are linked against. */
-__attribute__((weak)) int app_main(start_info_t *si)
+int app_main(start_info_t *si)
 {
-    printk("Dummy main: start_info=%p\n", si);
+    printk("Test main: start_info=%p\n", si);
     create_thread("xenbus_tester", xenbus_tester, si);
     create_thread("periodic_thread", periodic_thread, si);
     create_thread("netfront", netfront_thread, si);
@@ -470,69 +450,7 @@ __attribute__((weak)) int app_main(start_info_t *si)
     return 0;
 }
 
-/*
- * INITIAL C ENTRY POINT.
- */
-void start_kernel(start_info_t *si)
-{
-    static char hello[] = "Bootstrapping...\n";
-
-    (void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
-
-    arch_init(si);
-
-    trap_init();
-
-    /* print out some useful information  */
-    printk("Xen Minimal OS!\n");
-    printk("  start_info: %p(VA)\n", si);
-    printk("    nr_pages: 0x%lx\n", si->nr_pages);
-    printk("  shared_inf: 0x%08lx(MA)\n", si->shared_info);
-    printk("     pt_base: %p(VA)\n", (void *)si->pt_base); 
-    printk("nr_pt_frames: 0x%lx\n", si->nr_pt_frames);
-    printk("    mfn_list: %p(VA)\n", (void *)si->mfn_list); 
-    printk("   mod_start: 0x%lx(VA)\n", si->mod_start);
-    printk("     mod_len: %lu\n", si->mod_len); 
-    printk("       flags: 0x%x\n", (unsigned int)si->flags);
-    printk("    cmd_line: %s\n",  
-           si->cmd_line ? (const char *)si->cmd_line : "NULL");
-
-    /* Set up events. */
-    init_events();
-    
-    /* ENABLE EVENT DELIVERY. This is disabled at start of day. */
-    __sti();
-
-    arch_print_info();
-
-    setup_xen_features();
-
-    /* Init memory management. */
-    init_mm();
-
-    /* Init time and timers. */
-    init_time();
-
-    /* Init the console driver. */
-    init_console();
-
-    /* Init grant tables */
-    init_gnttab();
-    
-    /* Init scheduler. */
-    init_sched();
- 
-    /* Init XenBus */
-    init_xenbus();
-
-    /* Call (possibly overridden) app_main() */
-    app_main(&start_info);
-
-    /* Everything initialised, start idle thread */
-    run_idle_thread();
-}
-
-void stop_kernel(void)
+void shutdown_frontends(void)
 {
     if (net_dev)
         shutdown_netfront(net_dev);
@@ -548,51 +466,4 @@ void stop_kernel(void)
 
     if (pci_dev)
         shutdown_pcifront(pci_dev);
-
-    /* TODO: fs import */
-
-    local_irq_disable();
-
-    /* Reset grant tables */
-    fini_gnttab();
-
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
-    /* Reset XenBus */
-    fini_xenbus();
-
-    /* Reset timers */
-    fini_time();
-
-    /* Reset memory management. */
-    fini_mm();
-
-    /* Reset events. */
-    fini_events();
-
-    /* Reset traps */
-    trap_fini();
-
-    /* Reset arch details */
-    arch_fini();
-}
-
-/*
- * do_exit: This is called whenever an IRET fails in entry.S.
- * This will generally be because an application has got itself into
- * a really bad state (probably a bad CS or SS). It must be killed.
- * Of course, minimal OS doesn't have applications :-)
- */
-
-void do_exit(void)
-{
-    printk("Do_exit called!\n");
-    stack_walk();
-    for( ;; )
-    {
-        struct sched_shutdown sched_shutdown = { .reason = SHUTDOWN_crash };
-        HYPERVISOR_sched_op(SCHEDOP_shutdown, &sched_shutdown);
-    }
 }
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/c/minios.cfg
+++ b/stubdom/c/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
index e69de29..e1faee5 100644
--- a/stubdom/caml/minios.cfg
+++ b/stubdom/caml/minios.cfg
@@ -0,0 +1 @@
+CONFIG_TEST=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5X-0005l2-Q0; Fri, 27 Jan 2012 22:16:07 +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 1Rqu5U-0005hD-HW
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327702557!12895680!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3245 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15:58 -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
	q0RMFtpV014548; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhb026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:42 -0500
Message-Id: <1327702543-25211-24-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 23/24] xenstored: add --priv-domid 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>
MIME-Version: 1.0
Content-Type: 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 parameter identifies an alternative service domain which has
superuser access to the xenstore database, which is currently required
to set up a new domain's xenstore entries.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    1 +
 tools/xenstore/xenstored_domain.c |    2 +-
 3 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 66584f5..a42f552 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1752,6 +1752,7 @@ static struct option options[] = {
 	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
+	{ "priv-domid", 1, NULL, 'p' },
 	{ "output-pid", 0, NULL, 'P' },
 	{ "entry-size", 1, NULL, 'S' },
 	{ "trace-file", 1, NULL, 'T' },
@@ -1765,6 +1766,7 @@ static struct option options[] = {
 
 extern void dump_conn(struct connection *conn); 
 int dom0_event = 0;
+int priv_domid = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1825,6 +1827,9 @@ int main(int argc, char *argv[])
 		case 'e':
 			dom0_event = strtol(optarg, NULL, 10);
 			break;
+		case 'p':
+			priv_domid = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index e1c2be7..92c27ba 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -169,6 +169,7 @@ void dtrace_io(const struct connection *conn, const struct buffered_data *data,
 
 extern int event_fd;
 extern int dom0_event;
+extern int priv_domid;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index fa9c8fe..f8c822f 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -259,7 +259,7 @@ bool domain_can_read(struct connection *conn)
 
 bool domain_is_unprivileged(struct connection *conn)
 {
-	return (conn && conn->domain && conn->domain->domid != 0);
+	return (conn && conn->domain && conn->domain->domid != 0 && conn->domain->domid != priv_domid);
 }
 
 bool domain_can_write(struct connection *conn)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5Y-0005la-IG; Fri, 27 Jan 2012 22:16:08 +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 1Rqu5U-0005hM-NJ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327702557!12906769!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8445 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-5.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFtgt010102; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhT026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:34 -0500
Message-Id: <1327702543-25211-16-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 15/24] xenstored: refactor socket 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>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c |   85 +++++++++++++++++++++------------------
 1 files changed, 46 insertions(+), 39 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index 9e6c2c7..0e7d43f 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -343,13 +343,6 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
 	return max;
 }
 
-static int destroy_fd(void *_fd)
-{
-	int *fd = _fd;
-	close(*fd);
-	return 0;
-}
-
 /* Is child a subnode of parent, or equal? */
 bool is_child(const char *child, const char *parent)
 {
@@ -1705,6 +1698,51 @@ static void daemonize(void)
 	umask(0);
 }
 
+static int destroy_fd(void *_fd)
+{
+	int *fd = _fd;
+	close(*fd);
+	return 0;
+}
+
+static void init_sockets(int **psock, int **pro_sock)
+{
+	struct sockaddr_un addr;
+	int *sock, *ro_sock;
+	/* Create sockets for them to listen to. */
+	*psock = sock = talloc(talloc_autofree_context(), int);
+	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*sock < 0)
+		barf_perror("Could not create socket");
+	*pro_sock = ro_sock = talloc(talloc_autofree_context(), int);
+	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
+	if (*ro_sock < 0)
+		barf_perror("Could not create socket");
+	talloc_set_destructor(sock, destroy_fd);
+	talloc_set_destructor(ro_sock, destroy_fd);
+
+	/* FIXME: Be more sophisticated, don't mug running daemon. */
+	unlink(xs_daemon_socket());
+	unlink(xs_daemon_socket_ro());
+
+	addr.sun_family = AF_UNIX;
+	strcpy(addr.sun_path, xs_daemon_socket());
+	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s", xs_daemon_socket());
+	strcpy(addr.sun_path, xs_daemon_socket_ro());
+	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
+		barf_perror("Could not bind socket to %s",
+			    xs_daemon_socket_ro());
+	if (chmod(xs_daemon_socket(), 0600) != 0
+	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
+		barf_perror("Could not chmod sockets");
+
+	if (listen(*sock, 1) != 0
+	    || listen(*ro_sock, 1) != 0)
+		barf_perror("Could not listen on sockets");
+
+
+}
 
 static void usage(void)
 {
@@ -1753,7 +1791,6 @@ extern void dump_conn(struct connection *conn);
 int main(int argc, char *argv[])
 {
 	int opt, *sock, *ro_sock, max;
-	struct sockaddr_un addr;
 	fd_set inset, outset;
 	bool dofork = true;
 	bool outputpid = false;
@@ -1837,40 +1874,10 @@ int main(int argc, char *argv[])
 	if (!dofork)
 		talloc_enable_leak_report_full();
 
-	/* Create sockets for them to listen to. */
-	sock = talloc(talloc_autofree_context(), int);
-	*sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*sock < 0)
-		barf_perror("Could not create socket");
-	ro_sock = talloc(talloc_autofree_context(), int);
-	*ro_sock = socket(PF_UNIX, SOCK_STREAM, 0);
-	if (*ro_sock < 0)
-		barf_perror("Could not create socket");
-	talloc_set_destructor(sock, destroy_fd);
-	talloc_set_destructor(ro_sock, destroy_fd);
-
 	/* Don't kill us with SIGPIPE. */
 	signal(SIGPIPE, SIG_IGN);
 
-	/* FIXME: Be more sophisticated, don't mug running daemon. */
-	unlink(xs_daemon_socket());
-	unlink(xs_daemon_socket_ro());
-
-	addr.sun_family = AF_UNIX;
-	strcpy(addr.sun_path, xs_daemon_socket());
-	if (bind(*sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s", xs_daemon_socket());
-	strcpy(addr.sun_path, xs_daemon_socket_ro());
-	if (bind(*ro_sock, (struct sockaddr *)&addr, sizeof(addr)) != 0)
-		barf_perror("Could not bind socket to %s",
-			    xs_daemon_socket_ro());
-	if (chmod(xs_daemon_socket(), 0600) != 0
-	    || chmod(xs_daemon_socket_ro(), 0660) != 0)
-		barf_perror("Could not chmod sockets");
-
-	if (listen(*sock, 1) != 0
-	    || listen(*ro_sock, 1) != 0)
-		barf_perror("Could not listen on sockets");
+	init_sockets(&sock, &ro_sock);
 
 	if (pipe(reopen_log_pipe)) {
 		barf_perror("pipe");
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5T-0005iE-NI; Fri, 27 Jan 2012 22:16:03 +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 1Rqu5S-0005h5-Iw
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327702555!10505473!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7383 invoked from network); 27 Jan 2012 22:15:56 -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;
	27 Jan 2012 22:15:56 -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
	q0RMFsgt010084; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhE026810; 
	Fri, 27 Jan 2012 17:15:53 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:19 -0500
Message-Id: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v5:
 - Use BSD queue.h instead of GPL list.h in mini-os
 - Add CONFIG_LWIP to allow simpler disabling of LWIP
 - Typedef fixups
 - Create a xenstored_minios.c for minios-specific functions
 - Formatting cleanup
 - Using --internal-db is now required for a working stubdom

Changes from v4:
 - Add --internal-db flag to use TDB_INTERNAL on non-stubdom
 - Fewer #ifdefs

Changes from v3:
 - mini-os configuration files moved into stubdom/
 - mini-os extra console support now a config option
 - Fewer #ifdefs
 - grant table setup uses hypercall bounce
 - Xenstore stub domain syslog support re-enabled

Changes from v2:
 - configuration support added to mini-os build system
 - add mini-os support for conditionally compiling frontends, xenbus
 - XENMEM_remove_from_physmap moved out of arch-specific code
 - use uint32_t for virqs
 - warn when dropping grant v2-only flags when switching versions
 - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
 - ioctl now returns -EEXIST if xenstored has already been connected
 - various cosmetic cleanups, shuffling

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

Other notes:

The console for xenstored is not currently set up by
init-xenstore-domain. If the hypervisor is compiled with VERBOSE or
debug=y, output from xenstored will be visible on the hypervisor serial
console (or ring buffer if enabled with console_to_ring). The xenstore
stub domain itself supports console output, and init-xenstore-domain
could be extended to daemonize and spool this output to a log file. The
normal xenconsole daemon cannot be used here due to the possibility of a
deadlock.

----

[PATCH 01/24] xen: reinstate previously unused
[PATCH 02/24] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/24] xen: change virq parameters from int to uint32_t
[PATCH 04/24] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 05/24] xen: Preserve reserved grant entries when switching

[PATCH 06/24] tools/libxl: pull xenstore/console domids from
[PATCH 07/24] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 08/24] mini-os: use BSD sys/queue.h instead of Linux list.h
 - New patch by Ian Campbell; requires a qemu tag update with the
   block-vbd.c change posted at the same time.

[PATCH 09/24] mini-os: avoid crash if no console is provided
[PATCH 10/24] mini-os: remove per-fd evtchn limit
[PATCH 11/24] mini-os: create app-specific configuration
[PATCH 12/24] mini-os: Move test functions into test.c
[PATCH 13/24] mini-os: make frontends and xenbus optional
 - Old patch #13 dropped; others shifted due to new #8

[PATCH 14/24] xenstored: use grant references instead of
[PATCH 15/24] xenstored: refactor socket setup code
[PATCH 16/24] xenstored: add NO_SOCKETS compilation option
[PATCH 17/24] xenstored: support for tdb_copy with TDB_INTERNAL
[PATCH 18/24] xenstored: add --internal-db flag
[PATCH 19/24] xenstored: support running in minios stubdom
[PATCH 20/24] xenstored: add --event parameter for bootstrapping
[PATCH 21/24] stubdom: enable xenstored build
[PATCH 22/24] xenstored: use domain_is_unprivileged instead of
[PATCH 23/24] xenstored: add --priv-domid parameter
[PATCH 24/24] xenstored: Add stub domain builder
 - Swapped 20 <-> 21

Linux patch unchanged since v3, not reposted this time:
[PATCH] xenbus: Add support for xenbus backend in stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5T-0005iE-NI; Fri, 27 Jan 2012 22:16:03 +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 1Rqu5S-0005h5-Iw
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327702555!10505473!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7383 invoked from network); 27 Jan 2012 22:15:56 -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;
	27 Jan 2012 22:15:56 -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
	q0RMFsgt010084; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhE026810; 
	Fri, 27 Jan 2012 17:15:53 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:19 -0500
Message-Id: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH v6 00/24] Xenstore stub domain
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 v5:
 - Use BSD queue.h instead of GPL list.h in mini-os
 - Add CONFIG_LWIP to allow simpler disabling of LWIP
 - Typedef fixups
 - Create a xenstored_minios.c for minios-specific functions
 - Formatting cleanup
 - Using --internal-db is now required for a working stubdom

Changes from v4:
 - Add --internal-db flag to use TDB_INTERNAL on non-stubdom
 - Fewer #ifdefs

Changes from v3:
 - mini-os configuration files moved into stubdom/
 - mini-os extra console support now a config option
 - Fewer #ifdefs
 - grant table setup uses hypercall bounce
 - Xenstore stub domain syslog support re-enabled

Changes from v2:
 - configuration support added to mini-os build system
 - add mini-os support for conditionally compiling frontends, xenbus
 - XENMEM_remove_from_physmap moved out of arch-specific code
 - use uint32_t for virqs
 - warn when dropping grant v2-only flags when switching versions
 - IOCTL_XENBUS_BACKEND_SETUP name changed so userspace can implement compat
 - ioctl now returns -EEXIST if xenstored has already been connected
 - various cosmetic cleanups, shuffling

Changes from v1:
 - set_virq_handler implemented in libxc
 - added custom domain builder for xenstored
 - xenstore/console domain IDs now pulled from xenstore
 - migration support when using split xenstored (untested, should work)
 - slightly less intrusive NO_SOCKETS xenstored patch
   (still has many ifdefs to avoid pulling in socket headers or symbols)
 - virq handlers removed from dying domain when clearing event channels
 - dummy XSM module restricts getdomaininfo similar to no-XSM case
 - formatting/type fixups
 - partial ioctl compatibility with legacy IOCTL_XENBUS_ALLOC

To start xenstored, run:

tools/xenstore/init-xenstore-domain stubdom/mini-os-x86_64-xenstore/mini-os 20 system_u:system_r:domU_t

This will populate the xenstore domid key /tool/xenstore/domid

Other notes:

The console for xenstored is not currently set up by
init-xenstore-domain. If the hypervisor is compiled with VERBOSE or
debug=y, output from xenstored will be visible on the hypervisor serial
console (or ring buffer if enabled with console_to_ring). The xenstore
stub domain itself supports console output, and init-xenstore-domain
could be extended to daemonize and spool this output to a log file. The
normal xenconsole daemon cannot be used here due to the possibility of a
deadlock.

----

[PATCH 01/24] xen: reinstate previously unused
[PATCH 02/24] xen: allow global VIRQ handlers to be delegated to
[PATCH 03/24] xen: change virq parameters from int to uint32_t
[PATCH 04/24] xen: use XSM instead of IS_PRIV for getdomaininfo
[PATCH 05/24] xen: Preserve reserved grant entries when switching

[PATCH 06/24] tools/libxl: pull xenstore/console domids from
[PATCH 07/24] lib{xc,xl}: Seed grant tables with xenstore and

[PATCH 08/24] mini-os: use BSD sys/queue.h instead of Linux list.h
 - New patch by Ian Campbell; requires a qemu tag update with the
   block-vbd.c change posted at the same time.

[PATCH 09/24] mini-os: avoid crash if no console is provided
[PATCH 10/24] mini-os: remove per-fd evtchn limit
[PATCH 11/24] mini-os: create app-specific configuration
[PATCH 12/24] mini-os: Move test functions into test.c
[PATCH 13/24] mini-os: make frontends and xenbus optional
 - Old patch #13 dropped; others shifted due to new #8

[PATCH 14/24] xenstored: use grant references instead of
[PATCH 15/24] xenstored: refactor socket setup code
[PATCH 16/24] xenstored: add NO_SOCKETS compilation option
[PATCH 17/24] xenstored: support for tdb_copy with TDB_INTERNAL
[PATCH 18/24] xenstored: add --internal-db flag
[PATCH 19/24] xenstored: support running in minios stubdom
[PATCH 20/24] xenstored: add --event parameter for bootstrapping
[PATCH 21/24] stubdom: enable xenstored build
[PATCH 22/24] xenstored: use domain_is_unprivileged instead of
[PATCH 23/24] xenstored: add --priv-domid parameter
[PATCH 24/24] xenstored: Add stub domain builder
 - Swapped 20 <-> 21

Linux patch unchanged since v3, not reposted this time:
[PATCH] xenbus: Add support for xenbus backend in stub domain

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5U-0005it-Uk; Fri, 27 Jan 2012 22:16:04 +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 1Rqu5S-0005h6-PT
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327702555!12907973!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13877 invoked from network); 27 Jan 2012 22:15:56 -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;
	27 Jan 2012 22:15:56 -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
	q0RMFsgt010088; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhI026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:23 -0500
Message-Id: <1327702543-25211-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/24] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 8001a91..904fb45 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -264,6 +264,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index acf9c8a..d99f886 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5Y-0005lN-5k; Fri, 27 Jan 2012 22:16:08 +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 1Rqu5U-0005hF-HJ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327702557!12334157!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19615 invoked from network); 27 Jan 2012 22:15:57 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15:57 -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
	q0RMFtgt010095; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhO026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:29 -0500
Message-Id: <1327702543-25211-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/24] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This changes the minios evtchn implementation to use a list instead of
an array which ahis allows it to grow as necessary to support any number
of ports, only limited by Xen (NR_EVS is 1024, should be enough for now).

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/include/lib.h |   18 +++---
 tools/libxc/xc_minios.c      |  140 ++++++++++++++++++++++--------------------
 2 files changed, 84 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..3d03cf4 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -52,6 +52,7 @@
 #include <stddef.h>
 #include <xen/xen.h>
 #include <xen/event_channel.h>
+#include <sys/queue.h>
 #include "gntmap.h"
 
 #ifdef HAVE_LIBC
@@ -143,7 +144,14 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+LIST_HEAD(evtchn_port_list, evtchn_port_info);
+
+struct evtchn_port_info {
+        LIST_ENTRY(evtchn_port_info) list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +166,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct evtchn_port_list ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..eacd6f6 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -20,6 +20,7 @@
  */
 
 #undef NDEBUG
+#include "xen-external/bsd-sys-queue.h"
 #include <mini-os/types.h>
 #include <mini-os/os.h>
 #include <mini-os/mm.h>
@@ -210,15 +211,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    LIST_INSERT_HEAD(&files[fd].evtchn.ports, port_info, list);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    LIST_REMOVE(port_info, list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    LIST_INIT(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +251,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    LIST_FOREACH_SAFE(port_info, &files[fd].evtchn.ports, list, tmp)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +276,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    LIST_FOREACH(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +298,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +312,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +326,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +340,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +353,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    LIST_FOREACH(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +394,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    LIST_FOREACH(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5U-0005it-Uk; Fri, 27 Jan 2012 22:16:04 +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 1Rqu5S-0005h6-PT
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:02 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327702555!12907973!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13877 invoked from network); 27 Jan 2012 22:15:56 -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;
	27 Jan 2012 22:15:56 -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
	q0RMFsgt010088; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhI026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:23 -0500
Message-Id: <1327702543-25211-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 04/24] xen: use XSM instead of IS_PRIV for
	getdomaininfo
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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_DOMCTL_getdomaininfo domctl does not allow manipulation of
domains, only basic information such as size and state, so its use
does not fully justify making a domain privileged. XSM modules can also
provide fine-grained control over what domains are visible to domains
that call getdomaininfo.

If XSM is disabled (either at compile time or by using the dummy XSM
module) then there is no change in behavior: only IS_PRIV domains can
use this domctl. If enabled, the XSM module controls access.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>
---
 xen/common/domctl.c |    4 ++++
 xen/xsm/dummy.c     |    2 ++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 8001a91..904fb45 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -264,6 +264,10 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
             return -EPERM;
         break;
     }
+#ifdef XSM_ENABLE
+    case XEN_DOMCTL_getdomaininfo:
+        break;
+#endif
     default:
         if ( !IS_PRIV(current->domain) )
             return -EPERM;
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index acf9c8a..d99f886 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -66,6 +66,8 @@ static int dummy_scheduler (struct domain *d)
 
 static int dummy_getdomaininfo (struct domain *d)
 {
+    if ( !IS_PRIV(current->domain) )
+        return -EPERM;
     return 0;
 }
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:16:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu5Y-0005lN-5k; Fri, 27 Jan 2012 22:16:08 +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 1Rqu5U-0005hF-HJ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:04 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327702557!12334157!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19615 invoked from network); 27 Jan 2012 22:15:57 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15:57 -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
	q0RMFtgt010095; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhO026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:29 -0500
Message-Id: <1327702543-25211-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 10/24] mini-os: remove per-fd evtchn limit
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

This changes the minios evtchn implementation to use a list instead of
an array which ahis allows it to grow as necessary to support any number
of ports, only limited by Xen (NR_EVS is 1024, should be enough for now).

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/include/lib.h |   18 +++---
 tools/libxc/xc_minios.c      |  140 ++++++++++++++++++++++--------------------
 2 files changed, 84 insertions(+), 74 deletions(-)

diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index bd3eeaf..3d03cf4 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -52,6 +52,7 @@
 #include <stddef.h>
 #include <xen/xen.h>
 #include <xen/event_channel.h>
+#include <sys/queue.h>
 #include "gntmap.h"
 
 #ifdef HAVE_LIBC
@@ -143,7 +144,14 @@ enum fd_type {
     FTYPE_SAVEFILE,
 };
 
-#define MAX_EVTCHN_PORTS 16
+LIST_HEAD(evtchn_port_list, evtchn_port_info);
+
+struct evtchn_port_info {
+        LIST_ENTRY(evtchn_port_info) list;
+        evtchn_port_t port;
+        unsigned long pending;
+        int bound;
+};
 
 extern struct file {
     enum fd_type type;
@@ -158,13 +166,7 @@ extern struct file {
 	    off_t offset;
 	} file;
 	struct {
-            /* To each event channel FD is associated a series of ports which
-             * wakes select for this FD. */
-            struct {
-                evtchn_port_t port;
-                unsigned long pending;
-                int bound;
-            } ports[MAX_EVTCHN_PORTS];
+	    struct evtchn_port_list ports;
 	} evtchn;
 	struct gntmap gntmap;
 	struct {
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index 8bbfd18..eacd6f6 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -20,6 +20,7 @@
  */
 
 #undef NDEBUG
+#include "xen-external/bsd-sys-queue.h"
 #include <mini-os/types.h>
 #include <mini-os/os.h>
 #include <mini-os/mm.h>
@@ -210,15 +211,34 @@ static struct xc_osdep_ops minios_privcmd_ops = {
     },
 };
 
+
+/* XXX Note: This is not threadsafe */
+static struct evtchn_port_info* port_alloc(int fd) {
+    struct evtchn_port_info *port_info;
+    port_info = malloc(sizeof(struct evtchn_port_info));
+    if (port_info == NULL)
+        return NULL;
+    port_info->pending = 0;
+    port_info->port = -1;
+    port_info->bound = 0;
+
+    LIST_INSERT_HEAD(&files[fd].evtchn.ports, port_info, list);
+    return port_info;
+}
+
+static void port_dealloc(struct evtchn_port_info *port_info) {
+    if (port_info->bound)
+        unbind_evtchn(port_info->port);
+    LIST_REMOVE(port_info, list);
+    free(port_info);
+}
+
 static xc_osdep_handle minios_evtchn_open(xc_evtchn *xce)
 {
-    int fd = alloc_fd(FTYPE_EVTCHN), i;
+    int fd = alloc_fd(FTYPE_EVTCHN);
     if ( fd == -1 )
         return XC_OSDEP_OPEN_ERROR;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-	files[fd].evtchn.ports[i].port = -1;
-        files[fd].evtchn.ports[i].bound = 0;
-    }
+    LIST_INIT(&files[fd].evtchn.ports);
     printf("evtchn_open() -> %d\n", fd);
     return (xc_osdep_handle)fd;
 }
@@ -231,10 +251,10 @@ static int minios_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
 
 void minios_evtchn_close_fd(int fd)
 {
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-        if (files[fd].evtchn.ports[i].bound)
-            unbind_evtchn(files[fd].evtchn.ports[i].port);
+    struct evtchn_port_info *port_info, *tmp;
+    LIST_FOREACH_SAFE(port_info, &files[fd].evtchn.ports, list, tmp)
+        port_dealloc(port_info);
+
     files[fd].type = FTYPE_NONE;
 }
 
@@ -256,35 +276,21 @@ static int minios_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t
     return ret;
 }
 
-/* XXX Note: This is not threadsafe */
-static int port_alloc(int fd) {
-    int i;
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == -1)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Too many ports in xc handle\n");
-	errno = EMFILE;
-	return -1;
-    }
-    files[fd].evtchn.ports[i].pending = 0;
-    return i;
-}
-
 static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
     int fd = (int)(intptr_t)data;
-    int i;
+    struct evtchn_port_info *port_info;
     assert(files[fd].type == FTYPE_EVTCHN);
     mask_evtchn(port);
-    for (i= 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port)
-	    break;
-    if (i == MAX_EVTCHN_PORTS) {
-	printk("Unknown port for handle %d\n", fd);
-	return;
+    LIST_FOREACH(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port)
+            goto found;
     }
-    files[fd].evtchn.ports[i].pending = 1;
+    printk("Unknown port for handle %d\n", fd);
+    return;
+
+ found:
+    port_info->pending = 1;
     files[fd].read = 1;
     wake_up(&event_queue);
 }
@@ -292,12 +298,13 @@ static void evtchn_handler(evtchn_port_t port, struct pt_regs *regs, void *data)
 static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc_osdep_handle h, int domid)
 {
     int fd = (int)h;
-    int ret, i;
+    struct evtchn_port_info *port_info;
+    int ret;
     evtchn_port_t port;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_unbound_port(%d)", domid);
@@ -305,11 +312,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_unbound_port(xc_evtchn *xce, xc
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -318,12 +326,13 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     evtchn_port_t remote_port)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t local_port;
-    int ret, i;
+    int ret;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
@@ -331,11 +340,12 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
     printf(" = %d\n", ret);
 
     if (ret < 0) {
+	port_dealloc(port_info);
 	errno = -ret;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = local_port;
+    port_info->bound = 1;
+    port_info->port = local_port;
     unmask_evtchn(local_port);
     return local_port;
 }
@@ -343,42 +353,40 @@ static evtchn_port_or_error_t minios_evtchn_bind_interdomain(xc_evtchn *xce, xc_
 static int minios_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t port)
 {
     int fd = (int)h;
-    int i;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++)
-	if (files[fd].evtchn.ports[i].port == port) {
-	    files[fd].evtchn.ports[i].port = -1;
-	    break;
-	}
-    if (i == MAX_EVTCHN_PORTS) {
-	printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
-	errno = -EINVAL;
-	return -1;
+    struct evtchn_port_info *port_info;
+
+    LIST_FOREACH(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port == port) {
+            port_dealloc(port_info);
+            return 0;
+        }
     }
-    files[fd].evtchn.ports[i].bound = 0;
-    unbind_evtchn(port);
-    return 0;
+    printf("Warning: couldn't find port %"PRId32" for xc handle %x\n", port, fd);
+    errno = -EINVAL;
+    return -1;
 }
 
 static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
 {
     int fd = (int)h;
+    struct evtchn_port_info *port_info;
     evtchn_port_t port;
-    int i;
 
     assert(get_current() == main_thread);
-    i = port_alloc(fd);
-    if (i == -1)
+    port_info = port_alloc(fd);
+    if (port_info == NULL)
 	return -1;
 
     printf("xc_evtchn_bind_virq(%d)", virq);
     port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
     if (port < 0) {
+	port_dealloc(port_info);
 	errno = -port;
 	return -1;
     }
-    files[fd].evtchn.ports[i].bound = 1;
-    files[fd].evtchn.ports[i].port = port;
+    port_info->bound = 1;
+    port_info->port = port;
     unmask_evtchn(port);
     return port;
 }
@@ -386,18 +394,18 @@ static evtchn_port_or_error_t minios_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_h
 static evtchn_port_or_error_t minios_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
 {
     int fd = (int)h;
-    int i;
+    struct evtchn_port_info *port_info;
     unsigned long flags;
     evtchn_port_t ret = -1;
 
     local_irq_save(flags);
     files[fd].read = 0;
-    for (i = 0; i < MAX_EVTCHN_PORTS; i++) {
-        evtchn_port_t port = files[fd].evtchn.ports[i].port;
-        if (port != -1 && files[fd].evtchn.ports[i].pending) {
+
+    LIST_FOREACH(port_info, &files[fd].evtchn.ports, list) {
+        if (port_info->port != -1 && port_info->pending) {
             if (ret == -1) {
-                ret = port;
-                files[fd].evtchn.ports[i].pending = 0;
+                ret = port_info->port;
+                port_info->pending = 0;
             } else {
                 files[fd].read = 1;
                 break;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:17:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu6R-0006h2-U9; Fri, 27 Jan 2012 22:17:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5O-0005h9-O4
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:15:59 +0000
Received: from [85.158.138.51:25573] by server-9.bemta-3.messagelabs.com id
	59/5E-31168-D12232F4; Fri, 27 Jan 2012 22:15:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327702555!10963166!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12964 invoked from network); 27 Jan 2012 22:15:56 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 22:15:56 -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
	q0RMFspV014511; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhG026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:21 -0500
Message-Id: <1327702543-25211-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/24] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir Fraser <keir@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   66 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 154 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 37b0fd6..2ffdd85 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -749,6 +749,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index fd20210..500c7a2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -86,7 +86,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -480,7 +480,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -621,7 +621,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -680,7 +680,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 5b0fc4a..8001a91 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -995,6 +995,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..43bd167 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,68 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++)
+    {
+        if (global_virq_handlers[virq] == d)
+        {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count)
+    {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1222,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..6560182 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -288,7 +288,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -315,7 +315,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 232d50e..40b8a7a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,11 +23,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..e3cae60 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..acf9c8a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..543dc77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:17:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:17:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu6R-0006h2-U9; Fri, 27 Jan 2012 22:17:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5O-0005h9-O4
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:15:59 +0000
Received: from [85.158.138.51:25573] by server-9.bemta-3.messagelabs.com id
	59/5E-31168-D12232F4; Fri, 27 Jan 2012 22:15:57 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327702555!10963166!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12964 invoked from network); 27 Jan 2012 22:15:56 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 22:15:56 -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
	q0RMFspV014511; Fri, 27 Jan 2012 22:15:54 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 q0RMFrhG026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:21 -0500
Message-Id: <1327702543-25211-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, Keir Fraser <keir@xen.org>,
	Ian Campbell <ian.campbell@citrix.com>
Subject: [Xen-devel] [PATCH 02/24] xen: allow global VIRQ handlers to be
	delegated to other 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>
MIME-Version: 1.0
Content-Type: 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 sends global VIRQs to a domain designated as the VIRQ handler
instead of sending all global VIRQ events to dom0. This is required in
order to run xenstored in a stubdom, because VIRQ_DOM_EXC must be sent
to xenstored for domain destruction to work properly.

This patch was inspired by the xenstored stubdomain patch series sent to
xen-devel by Alex Zeffertt in 2009.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir Fraser <keir@xen.org>
---
 tools/flask/policy/policy/flask/access_vectors |    1 +
 tools/libxc/xc_domain.c                        |   10 ++++
 tools/libxc/xenctrl.h                          |    9 +++
 xen/arch/x86/cpu/mcheck/amd_nonfatal.c         |    2 +-
 xen/arch/x86/cpu/mcheck/mce.c                  |    2 +-
 xen/arch/x86/cpu/mcheck/mce_intel.c            |    6 +-
 xen/arch/x86/cpu/mcheck/non-fatal.c            |    2 +-
 xen/common/cpu.c                               |    4 +-
 xen/common/domain.c                            |    8 ++--
 xen/common/domctl.c                            |   17 ++++++
 xen/common/event_channel.c                     |   66 +++++++++++++++++++++++-
 xen/common/trace.c                             |    2 +-
 xen/drivers/char/console.c                     |    4 +-
 xen/include/public/domctl.h                    |    8 +++
 xen/include/xen/event.h                        |   12 +++-
 xen/include/xsm/xsm.h                          |    6 ++
 xen/xsm/dummy.c                                |    6 ++
 xen/xsm/flask/hooks.c                          |    6 ++
 xen/xsm/flask/include/av_perm_to_string.h      |    1 +
 xen/xsm/flask/include/av_permissions.h         |    1 +
 20 files changed, 154 insertions(+), 19 deletions(-)

diff --git a/tools/flask/policy/policy/flask/access_vectors b/tools/flask/policy/policy/flask/access_vectors
index 644f2e1..5901911 100644
--- a/tools/flask/policy/policy/flask/access_vectors
+++ b/tools/flask/policy/policy/flask/access_vectors
@@ -85,6 +85,7 @@ class domain
 	getpodtarget
 	setpodtarget
 	set_misc_info
+	set_virq_handler
 }
 
 class hvm
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index ab019b8..d98e68b 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1504,6 +1504,16 @@ int xc_domain_set_access_required(xc_interface *xch,
     return do_domctl(xch, &domctl);
 }
 
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq)
+{
+    DECLARE_DOMCTL;
+
+    domctl.cmd = XEN_DOMCTL_set_virq_handler;
+    domctl.domain = domid;
+    domctl.u.set_virq_handler.virq = virq;
+    return do_domctl(xch, &domctl);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xenctrl.h b/tools/libxc/xenctrl.h
index 37b0fd6..2ffdd85 100644
--- a/tools/libxc/xenctrl.h
+++ b/tools/libxc/xenctrl.h
@@ -749,6 +749,15 @@ int xc_domain_p2m_audit(xc_interface *xch,
 int xc_domain_set_access_required(xc_interface *xch,
 				  uint32_t domid,
 				  unsigned int required);
+/**
+ * This function sets the handler of global VIRQs sent by the hypervisor
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm domid the domain id which will handle the VIRQ
+ * @parm virq the virq number (VIRQ_*)
+ * return 0 on success, -1 on failure
+ */
+int xc_domain_set_virq_handler(xc_interface *xch, uint32_t domid, int virq);
 
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
diff --git a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
index 50288bd..9222098 100644
--- a/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
+++ b/xen/arch/x86/cpu/mcheck/amd_nonfatal.c
@@ -100,7 +100,7 @@ static void mce_amd_checkregs(void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index b592041..c4e4477 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -594,7 +594,7 @@ void mcheck_cmn_handler(struct cpu_user_regs *regs, long error_code,
         if (dom0_vmce_enabled()) {
             if (mctc != NULL)
                 mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mci);
             if (mctc != NULL)
diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 0986025..0894080 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -354,7 +354,7 @@ static void mce_softirq(void)
         /* Step2: Send Log to DOM0 through vIRQ */
         if (dom0_vmce_enabled()) {
             mce_printk(MCE_VERBOSE, "MCE: send MCE# to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         }
     }
 
@@ -1085,7 +1085,7 @@ static void cmci_discover(void)
     if (bs.errcnt && mctc != NULL) {
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
@@ -1205,7 +1205,7 @@ fastcall void smp_cmci_interrupt(struct cpu_user_regs *regs)
         if (dom0_vmce_enabled()) {
             mctelem_commit(mctc);
             mce_printk(MCE_VERBOSE, "CMCI: send CMCI to DOM0 through virq\n");
-            send_guest_global_virq(dom0, VIRQ_MCA);
+            send_global_virq(VIRQ_MCA);
         } else {
             x86_mcinfo_dump(mctelem_dataptr(mctc));
             mctelem_dismiss(mctc);
diff --git a/xen/arch/x86/cpu/mcheck/non-fatal.c b/xen/arch/x86/cpu/mcheck/non-fatal.c
index c57688f..1dded9b 100644
--- a/xen/arch/x86/cpu/mcheck/non-fatal.c
+++ b/xen/arch/x86/cpu/mcheck/non-fatal.c
@@ -55,7 +55,7 @@ static void mce_checkregs (void *info)
 
 		if (dom0_vmce_enabled()) {
 			mctelem_commit(mctc);
-			send_guest_global_virq(dom0, VIRQ_MCA);
+			send_global_virq(VIRQ_MCA);
 		} else if (++dumpcount >= 10) {
 			x86_mcinfo_dump((struct mc_info *)mctelem_dataptr(mctc));
 			mctelem_dismiss(mctc);
diff --git a/xen/common/cpu.c b/xen/common/cpu.c
index 79abdb7..630881e 100644
--- a/xen/common/cpu.c
+++ b/xen/common/cpu.c
@@ -108,7 +108,7 @@ int cpu_down(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_DEAD, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
     cpu_hotplug_done();
     return 0;
 
@@ -148,7 +148,7 @@ int cpu_up(unsigned int cpu)
     notifier_rc = notifier_call_chain(&cpu_chain, CPU_ONLINE, hcpu, NULL);
     BUG_ON(notifier_rc != NOTIFY_DONE);
 
-    send_guest_global_virq(dom0, VIRQ_PCPU_STATE);
+    send_global_virq(VIRQ_PCPU_STATE);
 
     cpu_hotplug_done();
     return 0;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index fd20210..500c7a2 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -86,7 +86,7 @@ static void __domain_finalise_shutdown(struct domain *d)
     if ( (d->shutdown_code == SHUTDOWN_suspend) && d->suspend_evtchn )
         evtchn_send(d, d->suspend_evtchn);
     else
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
 }
 
 static void vcpu_check_shutdown(struct vcpu *v)
@@ -480,7 +480,7 @@ int domain_kill(struct domain *d)
         }
         d->is_dying = DOMDYING_dead;
         put_domain(d);
-        send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+        send_global_virq(VIRQ_DOM_EXC);
         /* fallthrough */
     case DOMDYING_dead:
         break;
@@ -621,7 +621,7 @@ void domain_pause_for_debugger(void)
     for_each_vcpu ( d, v )
         vcpu_sleep_nosync(v);
 
-    send_guest_global_virq(dom0, VIRQ_DEBUGGER);
+    send_global_virq(VIRQ_DEBUGGER);
 }
 
 /* Complete domain destroy after RCU readers are not holding old references. */
@@ -680,7 +680,7 @@ static void complete_domain_destroy(struct rcu_head *head)
     free_cpumask_var(d->domain_dirty_cpumask);
     free_domain_struct(d);
 
-    send_guest_global_virq(dom0, VIRQ_DOM_EXC);
+    send_global_virq(VIRQ_DOM_EXC);
 }
 
 /* Release resources belonging to task @p. */
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 5b0fc4a..8001a91 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -995,6 +995,23 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domctl_t) u_domctl)
     }
     break;
 
+    case XEN_DOMCTL_set_virq_handler:
+    {
+        struct domain *d;
+        uint32_t virq = op->u.set_virq_handler.virq;
+
+        ret = -ESRCH;
+        d = rcu_lock_domain_by_id(op->domain);
+        if ( d != NULL )
+        {
+            ret = xsm_set_virq_handler(d, virq);
+            if ( !ret )
+                ret = set_global_virq_handler(d, virq);
+            rcu_unlock_domain(d);
+        }
+    }
+    break;
+
     default:
         ret = arch_do_domctl(op, u_domctl);
         break;
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 9212042..43bd167 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -689,7 +689,7 @@ void send_guest_vcpu_virq(struct vcpu *v, int virq)
     spin_unlock_irqrestore(&v->virq_lock, flags);
 }
 
-void send_guest_global_virq(struct domain *d, int virq)
+static void send_guest_global_virq(struct domain *d, int virq)
 {
     unsigned long flags;
     int port;
@@ -739,6 +739,68 @@ int send_guest_pirq(struct domain *d, const struct pirq *pirq)
     return evtchn_set_pending(d->vcpu[chn->notify_vcpu_id], port);
 }
 
+static struct domain *global_virq_handlers[NR_VIRQS] __read_mostly;
+
+static DEFINE_SPINLOCK(global_virq_handlers_lock);
+
+void send_global_virq(uint32_t virq)
+{
+    ASSERT(virq < NR_VIRQS);
+    ASSERT(virq_is_global(virq));
+
+    send_guest_global_virq(global_virq_handlers[virq] ?: dom0, virq);
+}
+
+int set_global_virq_handler(struct domain *d, uint32_t virq)
+{
+    struct domain *old;
+
+    if (virq >= NR_VIRQS)
+        return -EINVAL;
+    if (!virq_is_global(virq))
+        return -EINVAL;
+
+    if (global_virq_handlers[virq] == d)
+        return 0;
+
+    if (unlikely(!get_domain(d)))
+        return -EINVAL;
+
+    spin_lock(&global_virq_handlers_lock);
+    old = global_virq_handlers[virq];
+    global_virq_handlers[virq] = d;
+    spin_unlock(&global_virq_handlers_lock);
+
+    if (old != NULL)
+        put_domain(old);
+
+    return 0;
+}
+
+static void clear_global_virq_handlers(struct domain *d)
+{
+    uint32_t virq;
+    int put_count = 0;
+
+    spin_lock(&global_virq_handlers_lock);
+
+    for (virq = 0; virq < NR_VIRQS; virq++)
+    {
+        if (global_virq_handlers[virq] == d)
+        {
+            global_virq_handlers[virq] = NULL;
+            put_count++;
+        }
+    }
+
+    spin_unlock(&global_virq_handlers_lock);
+
+    while (put_count)
+    {
+        put_domain(d);
+        put_count--;
+    }
+}
 
 static long evtchn_status(evtchn_status_t *status)
 {
@@ -1160,6 +1222,8 @@ void evtchn_destroy(struct domain *d)
         d->evtchn[i] = NULL;
     }
     spin_unlock(&d->event_lock);
+
+    clear_global_virq_handlers(d);
 }
 
 
diff --git a/xen/common/trace.c b/xen/common/trace.c
index 5772f24..58cbf39 100644
--- a/xen/common/trace.c
+++ b/xen/common/trace.c
@@ -661,7 +661,7 @@ static inline void insert_lost_records(struct t_buf *buf)
  */
 static void trace_notify_dom0(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_TBUF);
+    send_global_virq(VIRQ_TBUF);
 }
 static DECLARE_SOFTIRQ_TASKLET(trace_notify_dom0_tasklet,
                                trace_notify_dom0, 0);
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 89cf4f8..6560182 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -288,7 +288,7 @@ static void __serial_rx(char c, struct cpu_user_regs *regs)
     if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
         serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
     /* Always notify the guest: prevents receive path from getting stuck. */
-    send_guest_global_virq(dom0, VIRQ_CONSOLE);
+    send_global_virq(VIRQ_CONSOLE);
 }
 
 static void serial_rx(char c, struct cpu_user_regs *regs)
@@ -315,7 +315,7 @@ static void serial_rx(char c, struct cpu_user_regs *regs)
 
 static void notify_dom0_con_ring(unsigned long unused)
 {
-    send_guest_global_virq(dom0, VIRQ_CON_RING);
+    send_global_virq(VIRQ_CON_RING);
 }
 static DECLARE_SOFTIRQ_TASKLET(notify_dom0_con_ring_tasklet,
                                notify_dom0_con_ring, 0);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index c7640aa..75be370 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -813,6 +813,12 @@ struct xen_domctl_audit_p2m {
 typedef struct xen_domctl_audit_p2m xen_domctl_audit_p2m_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_audit_p2m_t);
 
+struct xen_domctl_set_virq_handler {
+    uint32_t virq; /* IN */
+};
+typedef struct xen_domctl_set_virq_handler xen_domctl_set_virq_handler_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_virq_handler_t);
+
 #if defined(__i386__) || defined(__x86_64__)
 /* XEN_DOMCTL_setvcpuextstate */
 /* XEN_DOMCTL_getvcpuextstate */
@@ -912,6 +918,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_set_virq_handler              66
 #define XEN_DOMCTL_gdbsx_guestmemio            1000
 #define XEN_DOMCTL_gdbsx_pausevcpu             1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu           1002
@@ -966,6 +973,7 @@ struct xen_domctl {
 #endif
         struct xen_domctl_set_access_required access_required;
         struct xen_domctl_audit_p2m         audit_p2m;
+        struct xen_domctl_set_virq_handler  set_virq_handler;
         struct xen_domctl_gdbsx_memio       gdbsx_guest_memio;
         struct xen_domctl_gdbsx_pauseunp_vcpu gdbsx_pauseunp_vcpu;
         struct xen_domctl_gdbsx_domstatus   gdbsx_domstatus;
diff --git a/xen/include/xen/event.h b/xen/include/xen/event.h
index 232d50e..40b8a7a 100644
--- a/xen/include/xen/event.h
+++ b/xen/include/xen/event.h
@@ -23,11 +23,17 @@
 void send_guest_vcpu_virq(struct vcpu *v, int virq);
 
 /*
- * send_guest_global_virq: Notify guest via a global VIRQ.
- *  @d:        Domain to which virtual IRQ should be sent
+ * send_global_virq: Notify the domain handling a global VIRQ.
  *  @virq:     Virtual IRQ number (VIRQ_*)
  */
-void send_guest_global_virq(struct domain *d, int virq);
+void send_global_virq(uint32_t virq);
+
+/*
+ * sent_global_virq_handler: Set a global VIRQ handler.
+ *  @d:        New target domain for this VIRQ
+ *  @virq:     Virtual IRQ number (VIRQ_*), must be global
+ */
+int set_global_virq_handler(struct domain *d, uint32_t virq);
 
 /*
  * send_guest_pirq:
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 566c808..e3cae60 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -64,6 +64,7 @@ struct xsm_operations {
     int (*domain_settime) (struct domain *d);
     int (*set_target) (struct domain *d, struct domain *e);
     int (*domctl) (struct domain *d, int cmd);
+    int (*set_virq_handler) (struct domain *d, uint32_t virq);
     int (*tbufcontrol) (void);
     int (*readconsole) (uint32_t clear);
     int (*sched_id) (void);
@@ -265,6 +266,11 @@ static inline int xsm_domctl (struct domain *d, int cmd)
     return xsm_call(domctl(d, cmd));
 }
 
+static inline int xsm_set_virq_handler (struct domain *d, uint32_t virq)
+{
+    return xsm_call(set_virq_handler(d, virq));
+}
+
 static inline int xsm_tbufcontrol (void)
 {
     return xsm_call(tbufcontrol());
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 65daa4e..acf9c8a 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -94,6 +94,11 @@ static int dummy_domctl(struct domain *d, int cmd)
     return 0;
 }
 
+static int dummy_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return 0;
+}
+
 static int dummy_tbufcontrol (void)
 {
     return 0;
@@ -596,6 +601,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, domain_settime);
     set_to_dummy_if_null(ops, set_target);
     set_to_dummy_if_null(ops, domctl);
+    set_to_dummy_if_null(ops, set_virq_handler);
     set_to_dummy_if_null(ops, tbufcontrol);
     set_to_dummy_if_null(ops, readconsole);
     set_to_dummy_if_null(ops, sched_id);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a2020a9..543dc77 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -597,6 +597,11 @@ 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_set_virq_handler(struct domain *d, uint32_t virq)
+{
+    return domain_has_perm(current->domain, d, SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER);
+}
+
 static int flask_tbufcontrol(void)
 {
     return domain_has_xen(current->domain, XEN__TBUFCONTROL);
@@ -1460,6 +1465,7 @@ static struct xsm_operations flask_ops = {
     .domain_settime = flask_domain_settime,
     .set_target = flask_set_target,
     .domctl = flask_domctl,
+    .set_virq_handler = flask_set_virq_handler,
     .tbufcontrol = flask_tbufcontrol,
     .readconsole = flask_readconsole,
     .sched_id = flask_sched_id,
diff --git a/xen/xsm/flask/include/av_perm_to_string.h b/xen/xsm/flask/include/av_perm_to_string.h
index 85cbffc..17a1c36 100644
--- a/xen/xsm/flask/include/av_perm_to_string.h
+++ b/xen/xsm/flask/include/av_perm_to_string.h
@@ -60,6 +60,7 @@
    S_(SECCLASS_DOMAIN, DOMAIN__GETPODTARGET, "getpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SETPODTARGET, "setpodtarget")
    S_(SECCLASS_DOMAIN, DOMAIN__SET_MISC_INFO, "set_misc_info")
+   S_(SECCLASS_DOMAIN, DOMAIN__SET_VIRQ_HANDLER, "set_virq_handler")
    S_(SECCLASS_HVM, HVM__SETHVMC, "sethvmc")
    S_(SECCLASS_HVM, HVM__GETHVMC, "gethvmc")
    S_(SECCLASS_HVM, HVM__SETPARAM, "setparam")
diff --git a/xen/xsm/flask/include/av_permissions.h b/xen/xsm/flask/include/av_permissions.h
index 9e55a86..42eaf81 100644
--- a/xen/xsm/flask/include/av_permissions.h
+++ b/xen/xsm/flask/include/av_permissions.h
@@ -61,6 +61,7 @@
 #define DOMAIN__GETPODTARGET                      0x10000000UL
 #define DOMAIN__SETPODTARGET                      0x20000000UL
 #define DOMAIN__SET_MISC_INFO                     0x40000000UL
+#define DOMAIN__SET_VIRQ_HANDLER                  0x80000000UL
 
 #define HVM__SETHVMC                              0x00000001UL
 #define HVM__GETHVMC                              0x00000002UL
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:17:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu6S-0006he-C0; Fri, 27 Jan 2012 22:17:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5P-0005hK-MZ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:15:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327702516!57760391!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29219 invoked from network); 27 Jan 2012 22:15:16 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:16 -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
	q0RMFtpV014540; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhS026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:33 -0500
Message-Id: <1327702543-25211-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/24] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_domain.c |   54 ++++++++++++++++++++++++++++++++----
 1 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..c521e52 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
 	return len;
 }
 
+static void *map_interface(domid_t domid, unsigned long mfn)
+{
+	if (*xcg_handle >= 0) {
+		/* this is the preferred method */
+		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	} else {
+		return xc_map_foreign_range(*xc_handle, domid,
+			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+	}
+}
+
+static void unmap_interface(void *interface)
+{
+	if (*xcg_handle >= 0)
+		xc_gnttab_munmap(*xcg_handle, interface, 1);
+	else
+		munmap(interface, getpagesize());
+}
+
 static int destroy_domain(void *_domain)
 {
 	struct domain *domain = _domain;
@@ -174,8 +196,14 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		/* Domain 0 was mapped by dom0_init, so it must be unmapped
+		   using munmap() and not the grant unmap call. */
+		if (domain->domid == 0)
+			munmap(domain->interface, getpagesize());
+		else
+			unmap_interface(domain->interface);
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +372,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		interface = map_interface(domid, mfn);
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +380,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			unmap_interface(interface);
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +578,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +635,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:17:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu6S-0006he-C0; Fri, 27 Jan 2012 22:17:04 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5P-0005hK-MZ
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:15:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327702516!57760391!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29219 invoked from network); 27 Jan 2012 22:15:16 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:16 -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
	q0RMFtpV014540; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhS026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:33 -0500
Message-Id: <1327702543-25211-15-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 14/24] xenstored: use grant references instead
	of map_foreign_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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

make xenstored use grantref rather than map_foreign_range (which can
only be used by privileged domains)

This patch modifies the xenstore daemon to use xc_gnttab_map_grant_ref
instead of xc_map_foreign_range where available.

Previous versions of this patch have been sent to xen-devel. See
http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00610.html
http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01492.html

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_domain.c |   54 ++++++++++++++++++++++++++++++++----
 1 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 443af82..c521e52 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -32,8 +32,10 @@
 #include "xenstored_watch.h"
 
 #include <xenctrl.h>
+#include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
+static xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
@@ -163,6 +165,26 @@ static int readchn(struct connection *conn, void *data, unsigned int len)
 	return len;
 }
 
+static void *map_interface(domid_t domid, unsigned long mfn)
+{
+	if (*xcg_handle >= 0) {
+		/* this is the preferred method */
+		return xc_gnttab_map_grant_ref(*xcg_handle, domid,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
+	} else {
+		return xc_map_foreign_range(*xc_handle, domid,
+			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+	}
+}
+
+static void unmap_interface(void *interface)
+{
+	if (*xcg_handle >= 0)
+		xc_gnttab_munmap(*xcg_handle, interface, 1);
+	else
+		munmap(interface, getpagesize());
+}
+
 static int destroy_domain(void *_domain)
 {
 	struct domain *domain = _domain;
@@ -174,8 +196,14 @@ static int destroy_domain(void *_domain)
 			eprintf("> Unbinding port %i failed!\n", domain->port);
 	}
 
-	if (domain->interface)
-		munmap(domain->interface, getpagesize());
+	if (domain->interface) {
+		/* Domain 0 was mapped by dom0_init, so it must be unmapped
+		   using munmap() and not the grant unmap call. */
+		if (domain->domid == 0)
+			munmap(domain->interface, getpagesize());
+		else
+			unmap_interface(domain->interface);
+	}
 
 	fire_watches(NULL, "@releaseDomain", false);
 
@@ -344,9 +372,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 	domain = find_domain_by_domid(domid);
 
 	if (domain == NULL) {
-		interface = xc_map_foreign_range(
-			*xc_handle, domid,
-			getpagesize(), PROT_READ|PROT_WRITE, mfn);
+		interface = map_interface(domid, mfn);
 		if (!interface) {
 			send_error(conn, errno);
 			return;
@@ -354,7 +380,7 @@ void do_introduce(struct connection *conn, struct buffered_data *in)
 		/* Hang domain off "in" until we're finished. */
 		domain = new_domain(in, domid, port);
 		if (!domain) {
-			munmap(interface, getpagesize());
+			unmap_interface(interface);
 			send_error(conn, errno);
 			return;
 		}
@@ -552,6 +578,12 @@ static int close_xc_handle(void *_handle)
 	return 0;
 }
 
+static int close_xcg_handle(void *_handle)
+{
+	xc_gnttab_close(*(xc_gnttab **)_handle);
+	return 0;
+}
+
 /* Returns the implicit path of a connection (only domains have this) */
 const char *get_implicit_path(const struct connection *conn)
 {
@@ -603,6 +635,16 @@ void domain_init(void)
 
 	talloc_set_destructor(xc_handle, close_xc_handle);
 
+	xcg_handle = talloc(talloc_autofree_context(), xc_gnttab*);
+	if (!xcg_handle)
+		barf_perror("Failed to allocate domain gnttab handle");
+
+	*xcg_handle = xc_gnttab_open(NULL, 0);
+	if (*xcg_handle < 0)
+		xprintf("WARNING: Failed to open connection to gnttab\n");
+	else
+		talloc_set_destructor(xcg_handle, close_xcg_handle);
+
 	xce_handle = xc_evtchn_open(NULL, 0);
 
 	if (xce_handle == NULL)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:17:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu6S-0006iB-PC; Fri, 27 Jan 2012 22:17:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5P-0005hN-TE
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:00 +0000
Received: from [85.158.138.51:25618] by server-5.bemta-3.messagelabs.com id
	C2/22-02363-F12232F4; Fri, 27 Jan 2012 22:15:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327702557!6770576!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21466 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFsgt010090; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhK026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:25 -0500
Message-Id: <1327702543-25211-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/24] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..3828c62 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -64,6 +64,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -95,9 +96,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c8da45..965dbd0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -243,9 +243,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:17:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:17:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqu6S-0006iB-PC; Fri, 27 Jan 2012 22:17:04 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5P-0005hN-TE
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:00 +0000
Received: from [85.158.138.51:25618] by server-5.bemta-3.messagelabs.com id
	C2/22-02363-F12232F4; Fri, 27 Jan 2012 22:15:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327702557!6770576!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21466 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFsgt010090; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhK026810; 
	Fri, 27 Jan 2012 17:15:54 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:25 -0500
Message-Id: <1327702543-25211-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 06/24] tools/libxl: pull xenstore/console domids
	from xenstore
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 assuming that xenstored and xenconsoled are running in dom0,
pull the domain IDs from xenstore.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c      |   14 ++++++++++++--
 tools/libxl/libxl_internal.h |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..3828c62 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -64,6 +64,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int tsc_mode;
+    char *xs_domid, *con_domid;
     xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
     xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + LIBXL_MAXMEM_CONSTANT);
     if (info->type == LIBXL_DOMAIN_TYPE_PV)
@@ -95,9 +96,18 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
         xc_shadow_control(ctx->xch, domid, XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION, NULL, 0, &shadow, 0, NULL);
     }
 
-    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
-    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 0);
+    xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL);
+    state->store_domid = xs_domid ? atoi(xs_domid) : 0;
+    free(xs_domid);
+
+    con_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenconsoled/domid", NULL);
+    state->console_domid = con_domid ? atoi(con_domid) : 0;
+    free(con_domid);
+
+    state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid);
+    state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid);
     state->vm_generationid_addr = 0;
+
     return 0;
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 3c8da45..965dbd0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -243,9 +243,11 @@ _hidden int libxl__domain_shutdown_reason(libxl__gc *gc, uint32_t domid);
     libxl__domain_type((gc), (domid)) == LIBXL_DOMAIN_TYPE_##type
 typedef struct {
     uint32_t store_port;
+    uint32_t store_domid;
     unsigned long store_mfn;
 
     uint32_t console_port;
+    uint32_t console_domid;
     unsigned long console_mfn;
     unsigned long vm_generationid_addr;
 } libxl__domain_build_state;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:17:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu6T-0006iZ-63; Fri, 27 Jan 2012 22:17:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5Q-0005hR-3r
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:00 +0000
Received: from [85.158.138.51:25623] by server-4.bemta-3.messagelabs.com id
	06/0D-32238-F12232F4; Fri, 27 Jan 2012 22:15:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327702557!10818634!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31996 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFtgt010096; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhP026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:30 -0500
Message-Id: <1327702543-25211-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/24] mini-os: create app-specific configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/Makefile  |   52 ++++++++++++++++++++++++++++++++++++++++-----
 extras/mini-os/main.c    |   16 +++++++-------
 extras/mini-os/minios.mk |    4 +-
 stubdom/Makefile         |    8 +++---
 stubdom/grub/minios.cfg  |    2 +
 stubdom/ioemu-minios.cfg |    1 +
 6 files changed, 63 insertions(+), 20 deletions(-)
 create mode 100644 stubdom/c/minios.cfg
 create mode 100644 stubdom/caml/minios.cfg
 create mode 100644 stubdom/grub/minios.cfg
 create mode 100644 stubdom/ioemu-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c4d26f0..48d0d21 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,10 +8,25 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(MINIOS_CONFIG),)
 include Config.mk
+else
+EXTRA_DEPS += $(MINIOS_CONFIG)
+include $(MINIOS_CONFIG)
 endif
 
+# Configuration defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+CONFIG_QEMU_XS_ARGS ?= n
+
+# Export config items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
 # Include common mini-os makerules.
 include minios.mk
 
@@ -34,13 +49,38 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e9dbf02..d4da2bb 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/grub/minios.cfg b/stubdom/grub/minios.cfg
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/stubdom/grub/minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
new file mode 100644
index 0000000..7ea1d2f
--- /dev/null
+++ b/stubdom/ioemu-minios.cfg
@@ -0,0 +1 @@
+CONFIG_QEMU_XS_ARGS=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:17:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1Rqu6T-0006iZ-63; Fri, 27 Jan 2012 22:17:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1Rqu5Q-0005hR-3r
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:16:00 +0000
Received: from [85.158.138.51:25623] by server-4.bemta-3.messagelabs.com id
	06/0D-32238-F12232F4; Fri, 27 Jan 2012 22:15:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327702557!10818634!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31996 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-16.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 22:15: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
	q0RMFtgt010096; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhP026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:30 -0500
Message-Id: <1327702543-25211-12-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/24] mini-os: create app-specific configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/Makefile  |   52 ++++++++++++++++++++++++++++++++++++++++-----
 extras/mini-os/main.c    |   16 +++++++-------
 extras/mini-os/minios.mk |    4 +-
 stubdom/Makefile         |    8 +++---
 stubdom/grub/minios.cfg  |    2 +
 stubdom/ioemu-minios.cfg |    1 +
 6 files changed, 63 insertions(+), 20 deletions(-)
 create mode 100644 stubdom/c/minios.cfg
 create mode 100644 stubdom/caml/minios.cfg
 create mode 100644 stubdom/grub/minios.cfg
 create mode 100644 stubdom/ioemu-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c4d26f0..48d0d21 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,10 +8,25 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(MINIOS_CONFIG),)
 include Config.mk
+else
+EXTRA_DEPS += $(MINIOS_CONFIG)
+include $(MINIOS_CONFIG)
 endif
 
+# Configuration defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+CONFIG_QEMU_XS_ARGS ?= n
+
+# Export config items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
 # Include common mini-os makerules.
 include minios.mk
 
@@ -34,13 +49,38 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e9dbf02..d4da2bb 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/grub/minios.cfg b/stubdom/grub/minios.cfg
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/stubdom/grub/minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
new file mode 100644
index 0000000..7ea1d2f
--- /dev/null
+++ b/stubdom/ioemu-minios.cfg
@@ -0,0 +1 @@
+CONFIG_QEMU_XS_ARGS=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:22:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1RquBn-0000bL-6R; Fri, 27 Jan 2012 22:22:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RquBl-0000av-Ab
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:22:33 +0000
Received: from [85.158.138.51:32469] by server-10.bemta-3.messagelabs.com id
	03/47-20948-022232F4; Fri, 27 Jan 2012 22:16:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327702557!10993710!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7654 invoked from network); 27 Jan 2012 22:15:58 -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;
	27 Jan 2012 22:15: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
	q0RMFtgt010109; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhY026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:39 -0500
Message-Id: <1327702543-25211-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/24] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    3 +++
 tools/xenstore/xenstored_domain.c |    2 +-
 tools/xenstore/xenstored_minios.c |    6 ++++--
 4 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index a762db7..40e2fc0 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1749,6 +1749,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1763,6 +1764,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1820,6 +1822,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index f074955..e1c2be7 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
@@ -190,6 +191,8 @@ void finish_daemonize(void);
 /* Open a pipe for signal handling */
 void init_pipe(int reopen_log_pipe[2]);
 
+xc_gnttab **xcg_handle;
+
 #endif /* _XENSTORED_CORE_H */
 
 /*
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 6206961..558e5cb 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -35,7 +35,7 @@
 #include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
-static xc_gnttab **xcg_handle;
+xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
diff --git a/tools/xenstore/xenstored_minios.c b/tools/xenstore/xenstored_minios.c
index c8700ba..1c6f794 100644
--- a/tools/xenstore/xenstored_minios.c
+++ b/tools/xenstore/xenstored_minios.c
@@ -46,15 +46,17 @@ void xenbus_notify_running(void)
 
 evtchn_port_t xenbus_evtchn(void)
 {
-	return -1;
+	return dom0_event;
 }
 
 void *xenbus_map(void)
 {
-	return NULL;
+	return xc_gnttab_map_grant_ref(*xcg_handle, 0,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
 }
 
 void unmap_xenbus(void *interface)
 {
+	xc_gnttab_munmap(*xcg_handle, interface, 1);
 }
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:22:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1RquBn-0000bL-6R; Fri, 27 Jan 2012 22:22:35 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RquBl-0000av-Ab
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:22:33 +0000
Received: from [85.158.138.51:32469] by server-10.bemta-3.messagelabs.com id
	03/47-20948-022232F4; Fri, 27 Jan 2012 22:16:00 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327702557!10993710!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7654 invoked from network); 27 Jan 2012 22:15:58 -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;
	27 Jan 2012 22:15: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
	q0RMFtgt010109; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhY026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:39 -0500
Message-Id: <1327702543-25211-21-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 20/24] xenstored: add --event parameter for
	bootstrapping
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 xenstored is run in a minios domain, it needs a bootstrap
connection to dom0 so that additional domain introduce messages can be
sent to it.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/xenstored_core.c   |    5 +++++
 tools/xenstore/xenstored_core.h   |    3 +++
 tools/xenstore/xenstored_domain.c |    2 +-
 tools/xenstore/xenstored_minios.c |    6 ++++--
 4 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
index a762db7..40e2fc0 100644
--- a/tools/xenstore/xenstored_core.c
+++ b/tools/xenstore/xenstored_core.c
@@ -1749,6 +1749,7 @@ static struct option options[] = {
 	{ "no-domain-init", 0, NULL, 'D' },
 	{ "entry-nb", 1, NULL, 'E' },
 	{ "pid-file", 1, NULL, 'F' },
+	{ "event", 1, NULL, 'e' },
 	{ "help", 0, NULL, 'H' },
 	{ "no-fork", 0, NULL, 'N' },
 	{ "output-pid", 0, NULL, 'P' },
@@ -1763,6 +1764,7 @@ static struct option options[] = {
 	{ NULL, 0, NULL, 0 } };
 
 extern void dump_conn(struct connection *conn); 
+int dom0_event = 0;
 
 int main(int argc, char *argv[])
 {
@@ -1820,6 +1822,9 @@ int main(int argc, char *argv[])
 		case 'W':
 			quota_nb_watch_per_domain = strtol(optarg, NULL, 10);
 			break;
+		case 'e':
+			dom0_event = strtol(optarg, NULL, 10);
+			break;
 		}
 	}
 	if (optind != argc)
diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
index f074955..e1c2be7 100644
--- a/tools/xenstore/xenstored_core.h
+++ b/tools/xenstore/xenstored_core.h
@@ -168,6 +168,7 @@ void trace(const char *fmt, ...);
 void dtrace_io(const struct connection *conn, const struct buffered_data *data, int out);
 
 extern int event_fd;
+extern int dom0_event;
 
 /* Map the kernel's xenstore page. */
 void *xenbus_map(void);
@@ -190,6 +191,8 @@ void finish_daemonize(void);
 /* Open a pipe for signal handling */
 void init_pipe(int reopen_log_pipe[2]);
 
+xc_gnttab **xcg_handle;
+
 #endif /* _XENSTORED_CORE_H */
 
 /*
diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
index 6206961..558e5cb 100644
--- a/tools/xenstore/xenstored_domain.c
+++ b/tools/xenstore/xenstored_domain.c
@@ -35,7 +35,7 @@
 #include <xen/grant_table.h>
 
 static xc_interface **xc_handle;
-static xc_gnttab **xcg_handle;
+xc_gnttab **xcg_handle;
 static evtchn_port_t virq_port;
 
 xc_evtchn *xce_handle = NULL;
diff --git a/tools/xenstore/xenstored_minios.c b/tools/xenstore/xenstored_minios.c
index c8700ba..1c6f794 100644
--- a/tools/xenstore/xenstored_minios.c
+++ b/tools/xenstore/xenstored_minios.c
@@ -46,15 +46,17 @@ void xenbus_notify_running(void)
 
 evtchn_port_t xenbus_evtchn(void)
 {
-	return -1;
+	return dom0_event;
 }
 
 void *xenbus_map(void)
 {
-	return NULL;
+	return xc_gnttab_map_grant_ref(*xcg_handle, 0,
+			GNTTAB_RESERVED_XENSTORE, PROT_READ|PROT_WRITE);
 }
 
 void unmap_xenbus(void *interface)
 {
+	xc_gnttab_munmap(*xcg_handle, interface, 1);
 }
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:22:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1RquBz-0000eP-QL; Fri, 27 Jan 2012 22:22:47 +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 1RquBy-0000cS-4b
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:22:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327702558!12883372!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5880 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15:58 -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
	q0RMFupV014551; Fri, 27 Jan 2012 22:15:56 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 q0RMFrhc026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:43 -0500
Message-Id: <1327702543-25211-25-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 24/24] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   44 ++++++++++++++
 tools/xenstore/Makefile                  |   11 +++-
 tools/xenstore/init-xenstore-domain.c    |   94 ++++++++++++++++++++++++++++++
 3 files changed, 146 insertions(+), 3 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..bbee8c6
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,44 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index e510b4f..ea1b89b 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -27,7 +27,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
@@ -50,7 +50,12 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -86,7 +91,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..f3a4497
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,94 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+	if (rv < 0) return rv;
+	snprintf(cmdline, 512, "--event %d --internal-db", rv);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:22:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22: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 1RquBz-0000eP-QL; Fri, 27 Jan 2012 22:22:47 +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 1RquBy-0000cS-4b
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:22:46 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327702558!12883372!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5880 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-12.tower-216.messagelabs.com with SMTP;
	27 Jan 2012 22:15:58 -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
	q0RMFupV014551; Fri, 27 Jan 2012 22:15:56 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 q0RMFrhc026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:43 -0500
Message-Id: <1327702543-25211-25-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 24/24] xenstored: Add stub domain builder
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/include/xen-sys/Linux/xenbus_dev.h |   44 ++++++++++++++
 tools/xenstore/Makefile                  |   11 +++-
 tools/xenstore/init-xenstore-domain.c    |   94 ++++++++++++++++++++++++++++++
 3 files changed, 146 insertions(+), 3 deletions(-)
 create mode 100644 tools/include/xen-sys/Linux/xenbus_dev.h
 create mode 100644 tools/xenstore/init-xenstore-domain.c

diff --git a/tools/include/xen-sys/Linux/xenbus_dev.h b/tools/include/xen-sys/Linux/xenbus_dev.h
new file mode 100644
index 0000000..bbee8c6
--- /dev/null
+++ b/tools/include/xen-sys/Linux/xenbus_dev.h
@@ -0,0 +1,44 @@
+/******************************************************************************
+ * 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)
+
+#define IOCTL_XENBUS_BACKEND_SETUP			\
+	_IOC(_IOC_NONE, 'B', 1, 0)
+
+#endif /* __LINUX_XEN_XENBUS_DEV_H__ */
diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
index e510b4f..ea1b89b 100644
--- a/tools/xenstore/Makefile
+++ b/tools/xenstore/Makefile
@@ -27,7 +27,7 @@ LIBXENSTORE := libxenstore.a
 xenstore xenstore-control: CFLAGS += -static
 endif
 
-ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
+ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored init-xenstore-domain
 
 ifdef CONFIG_STUBDOM
 CFLAGS += -DNO_SOCKETS=1
@@ -50,7 +50,12 @@ xenstored_probes.o: xenstored_solaris.o
 
 CFLAGS += -DHAVE_DTRACE=1
 endif
- 
+
+init-xenstore-domain.o: CFLAGS += $(CFLAGS_libxenguest)
+
+init-xenstore-domain: init-xenstore-domain.o $(LIBXENSTORE)
+	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(LDLIBS_libxenguest) $(LDLIBS_libxenstore) -o $@ $(APPEND_LDFLAGS)
+
 xenstored: $(XENSTORED_OBJS)
 	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
 
@@ -86,7 +91,7 @@ libxenstore.a: xs.o xs_lib.o
 clean:
 	rm -f *.a *.o *.opic *.so* xenstored_probes.h
 	rm -f xenstored xs_random xs_stress xs_crashme
-	rm -f xs_tdb_dump xenstore-control
+	rm -f xs_tdb_dump xenstore-control init-xenstore-domain
 	rm -f xenstore $(CLIENTS)
 	$(RM) $(DEPS)
 
diff --git a/tools/xenstore/init-xenstore-domain.c b/tools/xenstore/init-xenstore-domain.c
new file mode 100644
index 0000000..f3a4497
--- /dev/null
+++ b/tools/xenstore/init-xenstore-domain.c
@@ -0,0 +1,94 @@
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <sys/ioctl.h>
+#include <sys/mman.h>
+#include <xenctrl.h>
+#include <xc_dom.h>
+#include <xs.h>
+#include <xen/sys/xenbus_dev.h>
+
+static uint32_t domid = -1;
+
+static int build(xc_interface *xch, char** argv)
+{
+	char cmdline[512];
+	uint32_t ssid;
+	xen_domain_handle_t handle = { 0 };
+	int rv;
+	int xs_fd = open("/dev/xen/xenbus_backend", O_RDWR);
+	struct xc_dom_image *dom;
+	int maxmem = atoi(argv[2]);
+	int limit_kb = (maxmem + 1)*1024;
+
+	rv = xc_flask_context_to_sid(xch, argv[3], strlen(argv[3]), &ssid);
+	if (rv) return rv;
+	rv = xc_domain_create(xch, ssid, handle, 0, &domid);
+	if (rv) return rv;
+	rv = xc_domain_max_vcpus(xch, domid, 1);
+	if (rv) return rv;
+	rv = xc_domain_setmaxmem(xch, domid, limit_kb);
+	if (rv) return rv;
+	rv = xc_domain_set_memmap_limit(xch, domid, limit_kb);
+	if (rv) return rv;
+
+	rv = ioctl(xs_fd, IOCTL_XENBUS_BACKEND_SETUP, domid);
+	if (rv < 0) return rv;
+	snprintf(cmdline, 512, "--event %d --internal-db", rv);
+
+	dom = xc_dom_allocate(xch, cmdline, NULL);
+	rv = xc_dom_kernel_file(dom, argv[1]);
+	if (rv) return rv;
+	rv = xc_dom_boot_xen_init(dom, xch, domid);
+	if (rv) return rv;
+	rv = xc_dom_parse_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_mem_init(dom, maxmem);
+	if (rv) return rv;
+	rv = xc_dom_boot_mem_init(dom);
+	if (rv) return rv;
+	rv = xc_dom_build_image(dom);
+	if (rv) return rv;
+	rv = xc_dom_boot_image(dom);
+	if (rv) return rv;
+
+	xc_dom_release(dom);
+
+	rv = xc_domain_set_virq_handler(xch, domid, VIRQ_DOM_EXC);
+	if (rv) return rv;
+	rv = xc_domain_unpause(xch, domid);
+	if (rv) return rv;
+
+	return 0;
+}
+
+int main(int argc, char** argv)
+{
+	xc_interface *xch;
+	struct xs_handle *xsh;
+	char buf[16];
+	int rv;
+
+	if (argc != 4) {
+		printf("Use: %s <xenstore-kernel> <memory_mb> <flask-label>\n", argv[0]);
+		return 2;
+	}
+
+	xch = xc_interface_open(NULL, NULL, 0);
+	if (!xch) return 1;
+
+	rv = build(xch, argv);
+
+	xc_interface_close(xch);
+
+	if (rv) return 1;
+
+	xsh = xs_open(0);
+	rv = snprintf(buf, 16, "%d", domid);
+	xs_write(xsh, XBT_NULL, "/tool/xenstored/domid", buf, rv);
+	xs_daemon_close(xsh);
+
+	return 0;
+}
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RquC1-0000et-7i; Fri, 27 Jan 2012 22:22:49 +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 1RquBz-0000cl-IU
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:22:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327702504!54360181!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19068 invoked from network); 27 Jan 2012 22:15:05 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:05 -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
	q0RMFtpV014539; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhR026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:32 -0500
Message-Id: <1327702543-25211-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/24] mini-os: make frontends and xenbus
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds compile-time logic to disable certain frontends in mini-os:
 - pcifront is disabled by default, enabled for ioemu
 - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default
 - xenbus is required for any frontend, and is enabled by default

If all frontends and xenbus are disabled, mini-os will run without
needing to communicate with xenstore, making it suitable to run the
xenstore daemon. The console frontend is not required for the initial
console, only consoles opened via openpt or ptmx.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/Makefile                            |   32 +++-
 extras/mini-os/console/console.c                   |    5 -
 extras/mini-os/console/console.h                   |    2 +
 .../mini-os/console/{xencons_ring.c => xenbus.c}   |  182 +-------------------
 extras/mini-os/console/xencons_ring.c              |  182 +-------------------
 extras/mini-os/include/lib.h                       |    2 +
 extras/mini-os/include/xenbus.h                    |   12 ++
 extras/mini-os/kernel.c                            |    4 -
 extras/mini-os/lib/sys.c                           |   59 +++++++
 extras/mini-os/main.c                              |    6 +-
 stubdom/ioemu-minios.cfg                           |    1 +
 11 files changed, 112 insertions(+), 375 deletions(-)
 create mode 100644 extras/mini-os/console/console.h
 copy extras/mini-os/console/{xencons_ring.c => xenbus.c} (56%)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index b4a9eb4..583f85b 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -20,11 +20,25 @@ CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
 CONFIG_TEST ?= n
+CONFIG_PCIFRONT ?= n
+CONFIG_BLKFRONT ?= y
+CONFIG_NETFRONT ?= y
+CONFIG_FBFRONT ?= y
+CONFIG_KBDFRONT ?= y
+CONFIG_CONSFRONT ?= y
+CONFIG_XENBUS ?= y
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
+flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
+flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
+flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
+flags-$(CONFIG_CONSFRONT) += -DCONFIG_CONSFRONT
+flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 
 DEF_CFLAGS += $(flags-y)
 
@@ -50,10 +64,10 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
-src-y += blkfront.c
+src-$(CONFIG_BLKFRONT) += blkfront.c
 src-y += daytime.c
 src-y += events.c
-src-y += fbfront.c
+src-$(CONFIG_FBFRONT) += fbfront.c
 src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
@@ -61,8 +75,8 @@ src-y += kernel.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
-src-y += netfront.c
-src-y += pcifront.c
+src-$(CONFIG_NETFRONT) += netfront.c
+src-$(CONFIG_PCIFRONT) += pcifront.c
 src-y += sched.c
 src-$(CONFIG_TEST) += test.c
 
@@ -73,12 +87,13 @@ src-y += lib/stack_chk_fail.c
 src-y += lib/string.c
 src-y += lib/sys.c
 src-y += lib/xmalloc.c
-src-y += lib/xs.c
+src-$(CONFIG_XENBUS) += lib/xs.c
 
-src-y += xenbus/xenbus.c
+src-$(CONFIG_XENBUS) += xenbus/xenbus.c
 
 src-y += console/console.c
 src-y += console/xencons_ring.c
+src-$(CONFIG_CONSFRONT) += console/xenbus.c
 
 # The common mini-os objects to build.
 APP_OBJS :=
@@ -113,7 +128,10 @@ ifeq ($(lwip),y)
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
 LWO	:= $(patsubst %.c,%.o,$(LWC))
-LWO	+= $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
+LWO	+= $(OBJ_DIR)/lwip-arch.o
+ifeq ($(CONFIG_NETFRONT),y)
+LWO += $(OBJ_DIR)/lwip-net.o
+endif
 
 $(OBJ_DIR)/lwip.a: $(LWO)
 	$(RM) $@
diff --git a/extras/mini-os/console/console.c b/extras/mini-os/console/console.c
index 2b4ed9f..fec3791 100644
--- a/extras/mini-os/console/console.c
+++ b/extras/mini-os/console/console.c
@@ -158,8 +158,3 @@ void init_console(void)
     /* This is also required to notify the daemon */
     printk("done.\n");
 }
-
-void fini_console(struct consfront_dev *dev)
-{
-    if (dev) free_consfront(dev);
-}
diff --git a/extras/mini-os/console/console.h b/extras/mini-os/console/console.h
new file mode 100644
index 0000000..e85147a
--- /dev/null
+++ b/extras/mini-os/console/console.h
@@ -0,0 +1,2 @@
+
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data);
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xenbus.c
similarity index 56%
copy from extras/mini-os/console/xencons_ring.c
copy to extras/mini-os/console/xenbus.c
index af0afed..a7c517d 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xenbus.c
@@ -11,181 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
-
-DECLARE_WAIT_QUEUE_HEAD(console_queue);
-
-static inline void notify_daemon(struct consfront_dev *dev)
-{
-    /* Use evtchn: this is called early, before irq is set up. */
-    if (!dev)
-        notify_remote_via_evtchn(start_info.console.domU.evtchn);
-    else
-        notify_remote_via_evtchn(dev->evtchn);
-}
-
-static inline struct xencons_interface *xencons_interface(void)
-{
-    if (start_info.console.domU.evtchn)
-        return mfn_to_virt(start_info.console.domU.mfn);
-    else
-        return NULL;
-} 
- 
-int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
-{	
-    int sent = 0;
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-
-	if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-        if (!intf)
-            return sent;
-
-	cons = intf->out_cons;
-	prod = intf->out_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->out));
-
-	while ((sent < len) && ((prod - cons) < sizeof(intf->out)))
-		intf->out[MASK_XENCONS_IDX(prod++, intf->out)] = data[sent++];
-
-	wmb();
-	intf->out_prod = prod;
-    
-    return sent;
-}
-
-int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
-{
-    int sent;
-
-    sent = xencons_ring_send_no_notify(dev, data, len);
-    notify_daemon(dev);
-
-    return sent;
-}	
-
-
-
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
-{
-	struct consfront_dev *dev = (struct consfront_dev *) data;
-#ifdef HAVE_LIBC
-        int fd = dev ? dev->fd : -1;
-
-        if (fd != -1)
-            files[fd].read = 1;
-
-        wake_up(&console_queue);
-#else
-	struct xencons_interface *intf = xencons_interface();
-	XENCONS_RING_IDX cons, prod;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-	while (cons != prod) {
-		xencons_rx(intf->in+MASK_XENCONS_IDX(cons,intf->in), 1, regs);
-		cons++;
-	}
-
-	mb();
-	intf->in_cons = cons;
-
-	notify_daemon(dev);
-
-	xencons_tx();
-#endif
-}
-
-#ifdef HAVE_LIBC
-int xencons_ring_avail(struct consfront_dev *dev)
-{
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-
-        if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-        return prod - cons;
-}
-
-int xencons_ring_recv(struct consfront_dev *dev, char *data, unsigned len)
-{
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-        unsigned filled = 0;
-
-        if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-        while (filled < len && cons + filled != prod) {
-                data[filled] = *(intf->in + MASK_XENCONS_IDX(cons + filled, intf->in));
-                filled++;
-	}
-
-	mb();
-        intf->in_cons = cons + filled;
-
-	notify_daemon(dev);
-
-        return filled;
-}
-#endif
-
-struct consfront_dev *xencons_ring_init(void)
-{
-	int err;
-	struct consfront_dev *dev;
-
-	if (!start_info.console.domU.evtchn)
-		return 0;
-
-	dev = malloc(sizeof(struct consfront_dev));
-	memset(dev, 0, sizeof(struct consfront_dev));
-	dev->nodename = "device/console";
-	dev->dom = 0;
-	dev->backend = 0;
-	dev->ring_ref = 0;
-
-#ifdef HAVE_LIBC
-	dev->fd = -1;
-#endif
-	dev->evtchn = start_info.console.domU.evtchn;
-	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
-
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
-	if (err <= 0) {
-		printk("XEN console request chn bind failed %i\n", err);
-                free(dev);
-		return NULL;
-	}
-        unmask_evtchn(dev->evtchn);
-
-	/* In case we have in-flight data after save/restore... */
-	notify_daemon(dev);
-
-	return dev;
-}
+#include "console.h"
 
 void free_consfront(struct consfront_dev *dev)
 {
@@ -262,7 +88,7 @@ struct consfront_dev *init_consfront(char *_nodename)
         return NULL;
     else
         dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
+    evtchn_alloc_unbound(dev->dom, console_handle_input, dev, &dev->evtchn);
 
     dev->ring = (struct xencons_interface *) alloc_page();
     memset(dev->ring, 0, PAGE_SIZE);
@@ -364,8 +190,8 @@ error:
     return NULL;
 }
 
-void xencons_resume(void)
+void fini_console(struct consfront_dev *dev)
 {
-	(void)xencons_ring_init();
+    if (dev) free_consfront(dev);
 }
 
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index af0afed..81c8e99 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -11,6 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
+#include "console.h"
 
 DECLARE_WAIT_QUEUE_HEAD(console_queue);
 
@@ -70,7 +71,7 @@ int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
 
 
 
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
 	struct consfront_dev *dev = (struct consfront_dev *) data;
 #ifdef HAVE_LIBC
@@ -173,7 +174,7 @@ struct consfront_dev *xencons_ring_init(void)
 	dev->evtchn = start_info.console.domU.evtchn;
 	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
 
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
+	err = bind_evtchn(dev->evtchn, console_handle_input, dev);
 	if (err <= 0) {
 		printk("XEN console request chn bind failed %i\n", err);
                 free(dev);
@@ -187,183 +188,6 @@ struct consfront_dev *xencons_ring_init(void)
 	return dev;
 }
 
-void free_consfront(struct consfront_dev *dev)
-{
-    char* err = NULL;
-    XenbusState state;
-
-    char path[strlen(dev->backend) + 1 + 5 + 1];
-    char nodename[strlen(dev->nodename) + 1 + 5 + 1];
-
-    snprintf(path, sizeof(path), "%s/state", dev->backend);
-    snprintf(nodename, sizeof(nodename), "%s/state", dev->nodename);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosing)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosing, err);
-        goto close;
-    }
-    state = xenbus_read_integer(path);
-    while (err == NULL && state < XenbusStateClosing)
-        err = xenbus_wait_for_state_change(path, &state, &dev->events);
-    if (err) free(err);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosed)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosed, err);
-        goto close;
-    }
-
-close:
-    if (err) free(err);
-    xenbus_unwatch_path_token(XBT_NIL, path, path);
-
-    mask_evtchn(dev->evtchn);
-    unbind_evtchn(dev->evtchn);
-    free(dev->backend);
-    free(dev->nodename);
-
-    gnttab_end_access(dev->ring_ref);
-
-    free_page(dev->ring);
-    free(dev);
-}
-
-struct consfront_dev *init_consfront(char *_nodename)
-{
-    xenbus_transaction_t xbt;
-    char* err;
-    char* message=NULL;
-    int retry=0;
-    char* msg = NULL;
-    char nodename[256];
-    char path[256];
-    static int consfrontends = 3;
-    struct consfront_dev *dev;
-    int res;
-
-    if (!_nodename)
-        snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
-    else
-        strncpy(nodename, _nodename, sizeof(nodename));
-
-    printk("******************* CONSFRONT for %s **********\n\n\n", nodename);
-
-    consfrontends++;
-    dev = malloc(sizeof(*dev));
-    memset(dev, 0, sizeof(*dev));
-    dev->nodename = strdup(nodename);
-#ifdef HAVE_LIBC
-    dev->fd = -1;
-#endif
-
-    snprintf(path, sizeof(path), "%s/backend-id", nodename);
-    if ((res = xenbus_read_integer(path)) < 0) 
-        return NULL;
-    else
-        dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
-
-    dev->ring = (struct xencons_interface *) alloc_page();
-    memset(dev->ring, 0, PAGE_SIZE);
-    dev->ring_ref = gnttab_grant_access(dev->dom, virt_to_mfn(dev->ring), 0);
-
-    dev->events = NULL;
-
-again:
-    err = xenbus_transaction_start(&xbt);
-    if (err) {
-        printk("starting transaction\n");
-        free(err);
-    }
-
-    err = xenbus_printf(xbt, nodename, "ring-ref","%u",
-                dev->ring_ref);
-    if (err) {
-        message = "writing ring-ref";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "port", "%u", dev->evtchn);
-    if (err) {
-        message = "writing event-channel";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "protocol", "%s", XEN_IO_PROTO_ABI_NATIVE);
-    if (err) {
-        message = "writing protocol";
-        goto abort_transaction;
-    }
-
-    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
-    if (err) {
-        message = "writing type";
-        goto abort_transaction;
-    }
-
-    snprintf(path, sizeof(path), "%s/state", nodename);
-    err = xenbus_switch_state(xbt, path, XenbusStateConnected);
-    if (err) {
-        message = "switching state";
-        goto abort_transaction;
-    }
-
-
-    err = xenbus_transaction_end(xbt, 0, &retry);
-    if (err) free(err);
-    if (retry) {
-            goto again;
-        printk("completing transaction\n");
-    }
-
-    goto done;
-
-abort_transaction:
-    free(err);
-    err = xenbus_transaction_end(xbt, 1, &retry);
-    goto error;
-
-done:
-
-    snprintf(path, sizeof(path), "%s/backend", nodename);
-    msg = xenbus_read(XBT_NIL, path, &dev->backend);
-    if (msg) {
-        printk("Error %s when reading the backend path %s\n", msg, path);
-        goto error;
-    }
-
-    printk("backend at %s\n", dev->backend);
-
-    {
-        XenbusState state;
-        char path[strlen(dev->backend) + 1 + 19 + 1];
-        snprintf(path, sizeof(path), "%s/state", dev->backend);
-        
-	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
-        msg = NULL;
-        state = xenbus_read_integer(path);
-        while (msg == NULL && state < XenbusStateConnected)
-            msg = xenbus_wait_for_state_change(path, &state, &dev->events);
-        if (msg != NULL || state != XenbusStateConnected) {
-            printk("backend not available, state=%d\n", state);
-            xenbus_unwatch_path_token(XBT_NIL, path, path);
-            goto error;
-        }
-    }
-    unmask_evtchn(dev->evtchn);
-
-    printk("**************************\n");
-
-    return dev;
-
-error:
-    free(msg);
-    free(err);
-    free_consfront(dev);
-    return NULL;
-}
-
 void xencons_resume(void)
 {
 	(void)xencons_ring_init();
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 3d03cf4..1af2717 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -184,11 +184,13 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
              * FD.  */
             xenbus_event_queue events;
         } xenbus;
+#endif
     };
     int read;	/* maybe available for read */
 } files[];
diff --git a/extras/mini-os/include/xenbus.h b/extras/mini-os/include/xenbus.h
index de618fc..cd6316e 100644
--- a/extras/mini-os/include/xenbus.h
+++ b/extras/mini-os/include/xenbus.h
@@ -6,8 +6,14 @@
 typedef unsigned long xenbus_transaction_t;
 #define XBT_NIL ((xenbus_transaction_t)0)
 
+#ifdef CONFIG_XENBUS
 /* Initialize the XenBus system. */
 void init_xenbus(void);
+#else
+static inline void init_xenbus(void)
+{
+}
+#endif
 
 /* Read the value associated with a path.  Returns a malloc'd error
    string on failure and sets *value to NULL.  On success, *value is
@@ -98,7 +104,13 @@ char* xenbus_printf(xenbus_transaction_t xbt,
 /* Utility function to figure out our domain id */
 domid_t xenbus_get_self_id(void);
 
+#ifdef CONFIG_XENBUS
 /* Reset the XenBus system. */
 void fini_xenbus(void);
+#else
+static inline void fini_xenbus(void)
+{
+}
+#endif
 
 #endif /* XENBUS_H__ */
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index c8b9b8c..a8dfe6d 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -142,10 +142,6 @@ void stop_kernel(void)
     /* Reset grant tables */
     fini_gnttab();
 
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
     /* Reset XenBus */
     fini_xenbus();
 
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 2329a78..5875797 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -164,6 +164,7 @@ int mkdir(const char *pathname, mode_t mode)
     return -1;
 }
 
+#ifdef CONFIG_CONSFRONT
 int posix_openpt(int flags)
 {
     struct consfront_dev *dev;
@@ -192,6 +193,18 @@ int open_savefile(const char *path, int save)
     printk("fd(%d) = open_savefile\n", dev->fd);
     return(dev->fd);
 }
+#else
+int posix_openpt(int flags)
+{
+	errno = EIO;
+	return -1;
+}
+int open_savefile(const char *path, int save)
+{
+	errno = EIO;
+	return -1;
+}
+#endif
 
 int open(const char *pathname, int flags, ...)
 {
@@ -241,6 +254,7 @@ int read(int fd, void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_read(files[fd].socket.fd, buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP: {
 	    ssize_t ret;
 	    ret = netfront_receive(files[fd].tap.dev, buf, nbytes);
@@ -250,6 +264,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret;
 	}
+#endif
+#ifdef CONFIG_KBDFRONT
         case FTYPE_KBD: {
             int ret, n;
             n = nbytes / sizeof(union xenkbd_in_event);
@@ -260,6 +276,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenkbd_in_event);
         }
+#endif
+#ifdef CONFIG_FBFRONT
         case FTYPE_FB: {
             int ret, n;
             n = nbytes / sizeof(union xenfb_in_event);
@@ -270,6 +288,7 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenfb_in_event);
         }
+#endif
 	default:
 	    break;
     }
@@ -297,9 +316,11 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_write(files[fd].socket.fd, (void*) buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
+#endif
 	default:
 	    break;
     }
@@ -326,9 +347,11 @@ int close(int fd)
         default:
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
             xs_daemon_close((void*)(intptr_t) fd);
             return 0;
+#endif
 #ifdef HAVE_LWIP
 	case FTYPE_SOCKET: {
 	    int res = lwip_close(files[fd].socket.fd);
@@ -345,27 +368,37 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_BLKFRONT
 	case FTYPE_BLK:
             shutdown_blkfront(files[fd].blk.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_FBFRONT
 	case FTYPE_FB:
             shutdown_fbfront(files[fd].fb.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_CONSFRONT
         case FTYPE_SAVEFILE:
         case FTYPE_CONSOLE:
             fini_console(files[fd].cons.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
 	case FTYPE_NONE:
 	    break;
     }
@@ -611,6 +644,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
                 n++;
 	    FD_CLR(i, exceptfds);
 	    break;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
 	    if (FD_ISSET(i, readfds)) {
                 if (files[i].xenbus.events)
@@ -621,6 +655,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
 	    FD_CLR(i, writefds);
 	    FD_CLR(i, exceptfds);
 	    break;
+#endif
 	case FTYPE_EVTCHN:
 	case FTYPE_TAP:
 	case FTYPE_BLK:
@@ -705,11 +740,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     fd_set myread, mywrite, myexcept;
     struct thread *thread = get_current();
     s_time_t start = NOW(), stop;
+#ifdef CONFIG_NETFRONT
     DEFINE_WAIT(netfront_w);
+#endif
     DEFINE_WAIT(event_w);
+#ifdef CONFIG_BLKFRONT
     DEFINE_WAIT(blkfront_w);
+#endif
+#ifdef CONFIG_XENBUS
     DEFINE_WAIT(xenbus_watch_w);
+#endif
+#ifdef CONFIG_KBDFRONT
     DEFINE_WAIT(kbdfront_w);
+#endif
     DEFINE_WAIT(console_w);
 
     assert(thread == main_thread);
@@ -727,11 +770,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
+#ifdef CONFIG_NETFRONT
     add_waiter(netfront_w, netfront_queue);
+#endif
     add_waiter(event_w, event_queue);
+#ifdef CONFIG_BLKFRONT
     add_waiter(blkfront_w, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     add_waiter(xenbus_watch_w, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     add_waiter(kbdfront_w, kbdfront_queue);
+#endif
     add_waiter(console_w, console_queue);
 
     if (readfds)
@@ -814,11 +865,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     ret = -1;
 
 out:
+#ifdef CONFIG_NETFRONT
     remove_waiter(netfront_w, netfront_queue);
+#endif
     remove_waiter(event_w, event_queue);
+#ifdef CONFIG_BLKFRONT
     remove_waiter(blkfront_w, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     remove_waiter(xenbus_watch_w, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     remove_waiter(kbdfront_w, kbdfront_queue);
+#endif
     remove_waiter(console_w, console_queue);
     return ret;
 }
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index aeda548..73eb6fb 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -63,10 +63,12 @@ static void call_main(void *p)
 #ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #endif
-#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK) && defined(CONFIG_NETFRONT)
     start_networking();
 #endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
@@ -169,7 +171,7 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
-#ifdef HAVE_LWIP
+#if defined(HAVE_LWIP) && defined(CONFIG_NETFRONT)
     stop_networking();
 #endif
     stop_kernel();
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
index 7ea1d2f..e3a96da 100644
--- a/stubdom/ioemu-minios.cfg
+++ b/stubdom/ioemu-minios.cfg
@@ -1 +1,2 @@
 CONFIG_QEMU_XS_ARGS=y
+CONFIG_PCIFRONT=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:22:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:22:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RquC1-0000et-7i; Fri, 27 Jan 2012 22:22:49 +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 1RquBz-0000cl-IU
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:22:48 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327702504!54360181!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19068 invoked from network); 27 Jan 2012 22:15:05 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-3.tower-27.messagelabs.com with SMTP;
	27 Jan 2012 22:15:05 -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
	q0RMFtpV014539; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhR026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:32 -0500
Message-Id: <1327702543-25211-14-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 13/24] mini-os: make frontends and xenbus
	optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This adds compile-time logic to disable certain frontends in mini-os:
 - pcifront is disabled by default, enabled for ioemu
 - blkfront, netfront, fbfront, kbdfront, consfront are enabled by default
 - xenbus is required for any frontend, and is enabled by default

If all frontends and xenbus are disabled, mini-os will run without
needing to communicate with xenstore, making it suitable to run the
xenstore daemon. The console frontend is not required for the initial
console, only consoles opened via openpt or ptmx.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 extras/mini-os/Makefile                            |   32 +++-
 extras/mini-os/console/console.c                   |    5 -
 extras/mini-os/console/console.h                   |    2 +
 .../mini-os/console/{xencons_ring.c => xenbus.c}   |  182 +-------------------
 extras/mini-os/console/xencons_ring.c              |  182 +-------------------
 extras/mini-os/include/lib.h                       |    2 +
 extras/mini-os/include/xenbus.h                    |   12 ++
 extras/mini-os/kernel.c                            |    4 -
 extras/mini-os/lib/sys.c                           |   59 +++++++
 extras/mini-os/main.c                              |    6 +-
 stubdom/ioemu-minios.cfg                           |    1 +
 11 files changed, 112 insertions(+), 375 deletions(-)
 create mode 100644 extras/mini-os/console/console.h
 copy extras/mini-os/console/{xencons_ring.c => xenbus.c} (56%)

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index b4a9eb4..583f85b 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -20,11 +20,25 @@ CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
 CONFIG_TEST ?= n
+CONFIG_PCIFRONT ?= n
+CONFIG_BLKFRONT ?= y
+CONFIG_NETFRONT ?= y
+CONFIG_FBFRONT ?= y
+CONFIG_KBDFRONT ?= y
+CONFIG_CONSFRONT ?= y
+CONFIG_XENBUS ?= y
 
 # Export config items as compiler directives
 flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+flags-$(CONFIG_PCIFRONT) += -DCONFIG_PCIFRONT
+flags-$(CONFIG_BLKFRONT) += -DCONFIG_BLKFRONT
+flags-$(CONFIG_NETFRONT) += -DCONFIG_NETFRONT
+flags-$(CONFIG_KBDFRONT) += -DCONFIG_KBDFRONT
+flags-$(CONFIG_FBFRONT) += -DCONFIG_FBFRONT
+flags-$(CONFIG_CONSFRONT) += -DCONFIG_CONSFRONT
+flags-$(CONFIG_XENBUS) += -DCONFIG_XENBUS
 
 DEF_CFLAGS += $(flags-y)
 
@@ -50,10 +64,10 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
-src-y += blkfront.c
+src-$(CONFIG_BLKFRONT) += blkfront.c
 src-y += daytime.c
 src-y += events.c
-src-y += fbfront.c
+src-$(CONFIG_FBFRONT) += fbfront.c
 src-y += gntmap.c
 src-y += gnttab.c
 src-y += hypervisor.c
@@ -61,8 +75,8 @@ src-y += kernel.c
 src-y += lock.c
 src-y += main.c
 src-y += mm.c
-src-y += netfront.c
-src-y += pcifront.c
+src-$(CONFIG_NETFRONT) += netfront.c
+src-$(CONFIG_PCIFRONT) += pcifront.c
 src-y += sched.c
 src-$(CONFIG_TEST) += test.c
 
@@ -73,12 +87,13 @@ src-y += lib/stack_chk_fail.c
 src-y += lib/string.c
 src-y += lib/sys.c
 src-y += lib/xmalloc.c
-src-y += lib/xs.c
+src-$(CONFIG_XENBUS) += lib/xs.c
 
-src-y += xenbus/xenbus.c
+src-$(CONFIG_XENBUS) += xenbus/xenbus.c
 
 src-y += console/console.c
 src-y += console/xencons_ring.c
+src-$(CONFIG_CONSFRONT) += console/xenbus.c
 
 # The common mini-os objects to build.
 APP_OBJS :=
@@ -113,7 +128,10 @@ ifeq ($(lwip),y)
 LWC	:= $(shell find $(LWIPDIR)/ -type f -name '*.c')
 LWC	:= $(filter-out %6.c %ip6_addr.c %ethernetif.c, $(LWC))
 LWO	:= $(patsubst %.c,%.o,$(LWC))
-LWO	+= $(addprefix $(OBJ_DIR)/,lwip-arch.o lwip-net.o)
+LWO	+= $(OBJ_DIR)/lwip-arch.o
+ifeq ($(CONFIG_NETFRONT),y)
+LWO += $(OBJ_DIR)/lwip-net.o
+endif
 
 $(OBJ_DIR)/lwip.a: $(LWO)
 	$(RM) $@
diff --git a/extras/mini-os/console/console.c b/extras/mini-os/console/console.c
index 2b4ed9f..fec3791 100644
--- a/extras/mini-os/console/console.c
+++ b/extras/mini-os/console/console.c
@@ -158,8 +158,3 @@ void init_console(void)
     /* This is also required to notify the daemon */
     printk("done.\n");
 }
-
-void fini_console(struct consfront_dev *dev)
-{
-    if (dev) free_consfront(dev);
-}
diff --git a/extras/mini-os/console/console.h b/extras/mini-os/console/console.h
new file mode 100644
index 0000000..e85147a
--- /dev/null
+++ b/extras/mini-os/console/console.h
@@ -0,0 +1,2 @@
+
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data);
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xenbus.c
similarity index 56%
copy from extras/mini-os/console/xencons_ring.c
copy to extras/mini-os/console/xenbus.c
index af0afed..a7c517d 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xenbus.c
@@ -11,181 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
-
-DECLARE_WAIT_QUEUE_HEAD(console_queue);
-
-static inline void notify_daemon(struct consfront_dev *dev)
-{
-    /* Use evtchn: this is called early, before irq is set up. */
-    if (!dev)
-        notify_remote_via_evtchn(start_info.console.domU.evtchn);
-    else
-        notify_remote_via_evtchn(dev->evtchn);
-}
-
-static inline struct xencons_interface *xencons_interface(void)
-{
-    if (start_info.console.domU.evtchn)
-        return mfn_to_virt(start_info.console.domU.mfn);
-    else
-        return NULL;
-} 
- 
-int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, unsigned len)
-{	
-    int sent = 0;
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-
-	if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-        if (!intf)
-            return sent;
-
-	cons = intf->out_cons;
-	prod = intf->out_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->out));
-
-	while ((sent < len) && ((prod - cons) < sizeof(intf->out)))
-		intf->out[MASK_XENCONS_IDX(prod++, intf->out)] = data[sent++];
-
-	wmb();
-	intf->out_prod = prod;
-    
-    return sent;
-}
-
-int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
-{
-    int sent;
-
-    sent = xencons_ring_send_no_notify(dev, data, len);
-    notify_daemon(dev);
-
-    return sent;
-}	
-
-
-
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
-{
-	struct consfront_dev *dev = (struct consfront_dev *) data;
-#ifdef HAVE_LIBC
-        int fd = dev ? dev->fd : -1;
-
-        if (fd != -1)
-            files[fd].read = 1;
-
-        wake_up(&console_queue);
-#else
-	struct xencons_interface *intf = xencons_interface();
-	XENCONS_RING_IDX cons, prod;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-	while (cons != prod) {
-		xencons_rx(intf->in+MASK_XENCONS_IDX(cons,intf->in), 1, regs);
-		cons++;
-	}
-
-	mb();
-	intf->in_cons = cons;
-
-	notify_daemon(dev);
-
-	xencons_tx();
-#endif
-}
-
-#ifdef HAVE_LIBC
-int xencons_ring_avail(struct consfront_dev *dev)
-{
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-
-        if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-        return prod - cons;
-}
-
-int xencons_ring_recv(struct consfront_dev *dev, char *data, unsigned len)
-{
-	struct xencons_interface *intf;
-	XENCONS_RING_IDX cons, prod;
-        unsigned filled = 0;
-
-        if (!dev)
-            intf = xencons_interface();
-        else
-            intf = dev->ring;
-
-	cons = intf->in_cons;
-	prod = intf->in_prod;
-	mb();
-	BUG_ON((prod - cons) > sizeof(intf->in));
-
-        while (filled < len && cons + filled != prod) {
-                data[filled] = *(intf->in + MASK_XENCONS_IDX(cons + filled, intf->in));
-                filled++;
-	}
-
-	mb();
-        intf->in_cons = cons + filled;
-
-	notify_daemon(dev);
-
-        return filled;
-}
-#endif
-
-struct consfront_dev *xencons_ring_init(void)
-{
-	int err;
-	struct consfront_dev *dev;
-
-	if (!start_info.console.domU.evtchn)
-		return 0;
-
-	dev = malloc(sizeof(struct consfront_dev));
-	memset(dev, 0, sizeof(struct consfront_dev));
-	dev->nodename = "device/console";
-	dev->dom = 0;
-	dev->backend = 0;
-	dev->ring_ref = 0;
-
-#ifdef HAVE_LIBC
-	dev->fd = -1;
-#endif
-	dev->evtchn = start_info.console.domU.evtchn;
-	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
-
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
-	if (err <= 0) {
-		printk("XEN console request chn bind failed %i\n", err);
-                free(dev);
-		return NULL;
-	}
-        unmask_evtchn(dev->evtchn);
-
-	/* In case we have in-flight data after save/restore... */
-	notify_daemon(dev);
-
-	return dev;
-}
+#include "console.h"
 
 void free_consfront(struct consfront_dev *dev)
 {
@@ -262,7 +88,7 @@ struct consfront_dev *init_consfront(char *_nodename)
         return NULL;
     else
         dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
+    evtchn_alloc_unbound(dev->dom, console_handle_input, dev, &dev->evtchn);
 
     dev->ring = (struct xencons_interface *) alloc_page();
     memset(dev->ring, 0, PAGE_SIZE);
@@ -364,8 +190,8 @@ error:
     return NULL;
 }
 
-void xencons_resume(void)
+void fini_console(struct consfront_dev *dev)
 {
-	(void)xencons_ring_init();
+    if (dev) free_consfront(dev);
 }
 
diff --git a/extras/mini-os/console/xencons_ring.c b/extras/mini-os/console/xencons_ring.c
index af0afed..81c8e99 100644
--- a/extras/mini-os/console/xencons_ring.c
+++ b/extras/mini-os/console/xencons_ring.c
@@ -11,6 +11,7 @@
 #include <xen/io/ring.h>
 #include <mini-os/xmalloc.h>
 #include <mini-os/gnttab.h>
+#include "console.h"
 
 DECLARE_WAIT_QUEUE_HEAD(console_queue);
 
@@ -70,7 +71,7 @@ int xencons_ring_send(struct consfront_dev *dev, const char *data, unsigned len)
 
 
 
-static void handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
+void console_handle_input(evtchn_port_t port, struct pt_regs *regs, void *data)
 {
 	struct consfront_dev *dev = (struct consfront_dev *) data;
 #ifdef HAVE_LIBC
@@ -173,7 +174,7 @@ struct consfront_dev *xencons_ring_init(void)
 	dev->evtchn = start_info.console.domU.evtchn;
 	dev->ring = (struct xencons_interface *) mfn_to_virt(start_info.console.domU.mfn);
 
-	err = bind_evtchn(dev->evtchn, handle_input, dev);
+	err = bind_evtchn(dev->evtchn, console_handle_input, dev);
 	if (err <= 0) {
 		printk("XEN console request chn bind failed %i\n", err);
                 free(dev);
@@ -187,183 +188,6 @@ struct consfront_dev *xencons_ring_init(void)
 	return dev;
 }
 
-void free_consfront(struct consfront_dev *dev)
-{
-    char* err = NULL;
-    XenbusState state;
-
-    char path[strlen(dev->backend) + 1 + 5 + 1];
-    char nodename[strlen(dev->nodename) + 1 + 5 + 1];
-
-    snprintf(path, sizeof(path), "%s/state", dev->backend);
-    snprintf(nodename, sizeof(nodename), "%s/state", dev->nodename);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosing)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosing, err);
-        goto close;
-    }
-    state = xenbus_read_integer(path);
-    while (err == NULL && state < XenbusStateClosing)
-        err = xenbus_wait_for_state_change(path, &state, &dev->events);
-    if (err) free(err);
-
-    if ((err = xenbus_switch_state(XBT_NIL, nodename, XenbusStateClosed)) != NULL) {
-        printk("free_consfront: error changing state to %d: %s\n",
-                XenbusStateClosed, err);
-        goto close;
-    }
-
-close:
-    if (err) free(err);
-    xenbus_unwatch_path_token(XBT_NIL, path, path);
-
-    mask_evtchn(dev->evtchn);
-    unbind_evtchn(dev->evtchn);
-    free(dev->backend);
-    free(dev->nodename);
-
-    gnttab_end_access(dev->ring_ref);
-
-    free_page(dev->ring);
-    free(dev);
-}
-
-struct consfront_dev *init_consfront(char *_nodename)
-{
-    xenbus_transaction_t xbt;
-    char* err;
-    char* message=NULL;
-    int retry=0;
-    char* msg = NULL;
-    char nodename[256];
-    char path[256];
-    static int consfrontends = 3;
-    struct consfront_dev *dev;
-    int res;
-
-    if (!_nodename)
-        snprintf(nodename, sizeof(nodename), "device/console/%d", consfrontends);
-    else
-        strncpy(nodename, _nodename, sizeof(nodename));
-
-    printk("******************* CONSFRONT for %s **********\n\n\n", nodename);
-
-    consfrontends++;
-    dev = malloc(sizeof(*dev));
-    memset(dev, 0, sizeof(*dev));
-    dev->nodename = strdup(nodename);
-#ifdef HAVE_LIBC
-    dev->fd = -1;
-#endif
-
-    snprintf(path, sizeof(path), "%s/backend-id", nodename);
-    if ((res = xenbus_read_integer(path)) < 0) 
-        return NULL;
-    else
-        dev->dom = res;
-    evtchn_alloc_unbound(dev->dom, handle_input, dev, &dev->evtchn);
-
-    dev->ring = (struct xencons_interface *) alloc_page();
-    memset(dev->ring, 0, PAGE_SIZE);
-    dev->ring_ref = gnttab_grant_access(dev->dom, virt_to_mfn(dev->ring), 0);
-
-    dev->events = NULL;
-
-again:
-    err = xenbus_transaction_start(&xbt);
-    if (err) {
-        printk("starting transaction\n");
-        free(err);
-    }
-
-    err = xenbus_printf(xbt, nodename, "ring-ref","%u",
-                dev->ring_ref);
-    if (err) {
-        message = "writing ring-ref";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "port", "%u", dev->evtchn);
-    if (err) {
-        message = "writing event-channel";
-        goto abort_transaction;
-    }
-    err = xenbus_printf(xbt, nodename,
-                "protocol", "%s", XEN_IO_PROTO_ABI_NATIVE);
-    if (err) {
-        message = "writing protocol";
-        goto abort_transaction;
-    }
-
-    err = xenbus_printf(xbt, nodename, "type", "%s", "ioemu");
-    if (err) {
-        message = "writing type";
-        goto abort_transaction;
-    }
-
-    snprintf(path, sizeof(path), "%s/state", nodename);
-    err = xenbus_switch_state(xbt, path, XenbusStateConnected);
-    if (err) {
-        message = "switching state";
-        goto abort_transaction;
-    }
-
-
-    err = xenbus_transaction_end(xbt, 0, &retry);
-    if (err) free(err);
-    if (retry) {
-            goto again;
-        printk("completing transaction\n");
-    }
-
-    goto done;
-
-abort_transaction:
-    free(err);
-    err = xenbus_transaction_end(xbt, 1, &retry);
-    goto error;
-
-done:
-
-    snprintf(path, sizeof(path), "%s/backend", nodename);
-    msg = xenbus_read(XBT_NIL, path, &dev->backend);
-    if (msg) {
-        printk("Error %s when reading the backend path %s\n", msg, path);
-        goto error;
-    }
-
-    printk("backend at %s\n", dev->backend);
-
-    {
-        XenbusState state;
-        char path[strlen(dev->backend) + 1 + 19 + 1];
-        snprintf(path, sizeof(path), "%s/state", dev->backend);
-        
-	xenbus_watch_path_token(XBT_NIL, path, path, &dev->events);
-        msg = NULL;
-        state = xenbus_read_integer(path);
-        while (msg == NULL && state < XenbusStateConnected)
-            msg = xenbus_wait_for_state_change(path, &state, &dev->events);
-        if (msg != NULL || state != XenbusStateConnected) {
-            printk("backend not available, state=%d\n", state);
-            xenbus_unwatch_path_token(XBT_NIL, path, path);
-            goto error;
-        }
-    }
-    unmask_evtchn(dev->evtchn);
-
-    printk("**************************\n");
-
-    return dev;
-
-error:
-    free(msg);
-    free(err);
-    free_consfront(dev);
-    return NULL;
-}
-
 void xencons_resume(void)
 {
 	(void)xencons_ring_init();
diff --git a/extras/mini-os/include/lib.h b/extras/mini-os/include/lib.h
index 3d03cf4..1af2717 100644
--- a/extras/mini-os/include/lib.h
+++ b/extras/mini-os/include/lib.h
@@ -184,11 +184,13 @@ extern struct file {
 	struct {
 	    struct consfront_dev *dev;
 	} cons;
+#ifdef CONFIG_XENBUS
         struct {
             /* To each xenbus FD is associated a queue of watch events for this
              * FD.  */
             xenbus_event_queue events;
         } xenbus;
+#endif
     };
     int read;	/* maybe available for read */
 } files[];
diff --git a/extras/mini-os/include/xenbus.h b/extras/mini-os/include/xenbus.h
index de618fc..cd6316e 100644
--- a/extras/mini-os/include/xenbus.h
+++ b/extras/mini-os/include/xenbus.h
@@ -6,8 +6,14 @@
 typedef unsigned long xenbus_transaction_t;
 #define XBT_NIL ((xenbus_transaction_t)0)
 
+#ifdef CONFIG_XENBUS
 /* Initialize the XenBus system. */
 void init_xenbus(void);
+#else
+static inline void init_xenbus(void)
+{
+}
+#endif
 
 /* Read the value associated with a path.  Returns a malloc'd error
    string on failure and sets *value to NULL.  On success, *value is
@@ -98,7 +104,13 @@ char* xenbus_printf(xenbus_transaction_t xbt,
 /* Utility function to figure out our domain id */
 domid_t xenbus_get_self_id(void);
 
+#ifdef CONFIG_XENBUS
 /* Reset the XenBus system. */
 void fini_xenbus(void);
+#else
+static inline void fini_xenbus(void)
+{
+}
+#endif
 
 #endif /* XENBUS_H__ */
diff --git a/extras/mini-os/kernel.c b/extras/mini-os/kernel.c
index c8b9b8c..a8dfe6d 100644
--- a/extras/mini-os/kernel.c
+++ b/extras/mini-os/kernel.c
@@ -142,10 +142,6 @@ void stop_kernel(void)
     /* Reset grant tables */
     fini_gnttab();
 
-    /* Reset the console driver. */
-    fini_console(NULL);
-    /* TODO: record new ring mfn & event in start_info */
-
     /* Reset XenBus */
     fini_xenbus();
 
diff --git a/extras/mini-os/lib/sys.c b/extras/mini-os/lib/sys.c
index 2329a78..5875797 100644
--- a/extras/mini-os/lib/sys.c
+++ b/extras/mini-os/lib/sys.c
@@ -164,6 +164,7 @@ int mkdir(const char *pathname, mode_t mode)
     return -1;
 }
 
+#ifdef CONFIG_CONSFRONT
 int posix_openpt(int flags)
 {
     struct consfront_dev *dev;
@@ -192,6 +193,18 @@ int open_savefile(const char *path, int save)
     printk("fd(%d) = open_savefile\n", dev->fd);
     return(dev->fd);
 }
+#else
+int posix_openpt(int flags)
+{
+	errno = EIO;
+	return -1;
+}
+int open_savefile(const char *path, int save)
+{
+	errno = EIO;
+	return -1;
+}
+#endif
 
 int open(const char *pathname, int flags, ...)
 {
@@ -241,6 +254,7 @@ int read(int fd, void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_read(files[fd].socket.fd, buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP: {
 	    ssize_t ret;
 	    ret = netfront_receive(files[fd].tap.dev, buf, nbytes);
@@ -250,6 +264,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret;
 	}
+#endif
+#ifdef CONFIG_KBDFRONT
         case FTYPE_KBD: {
             int ret, n;
             n = nbytes / sizeof(union xenkbd_in_event);
@@ -260,6 +276,8 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenkbd_in_event);
         }
+#endif
+#ifdef CONFIG_FBFRONT
         case FTYPE_FB: {
             int ret, n;
             n = nbytes / sizeof(union xenfb_in_event);
@@ -270,6 +288,7 @@ int read(int fd, void *buf, size_t nbytes)
 	    }
 	    return ret * sizeof(union xenfb_in_event);
         }
+#endif
 	default:
 	    break;
     }
@@ -297,9 +316,11 @@ int write(int fd, const void *buf, size_t nbytes)
 	case FTYPE_SOCKET:
 	    return lwip_write(files[fd].socket.fd, (void*) buf, nbytes);
 #endif
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    netfront_xmit(files[fd].tap.dev, (void*) buf, nbytes);
 	    return nbytes;
+#endif
 	default:
 	    break;
     }
@@ -326,9 +347,11 @@ int close(int fd)
         default:
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
             xs_daemon_close((void*)(intptr_t) fd);
             return 0;
+#endif
 #ifdef HAVE_LWIP
 	case FTYPE_SOCKET: {
 	    int res = lwip_close(files[fd].socket.fd);
@@ -345,27 +368,37 @@ int close(int fd)
 	case FTYPE_GNTMAP:
 	    minios_gnttab_close_fd(fd);
 	    return 0;
+#ifdef CONFIG_NETFRONT
 	case FTYPE_TAP:
 	    shutdown_netfront(files[fd].tap.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_BLKFRONT
 	case FTYPE_BLK:
             shutdown_blkfront(files[fd].blk.dev);
 	    files[fd].type = FTYPE_NONE;
 	    return 0;
+#endif
+#ifdef CONFIG_KBDFRONT
 	case FTYPE_KBD:
             shutdown_kbdfront(files[fd].kbd.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_FBFRONT
 	case FTYPE_FB:
             shutdown_fbfront(files[fd].fb.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
+#ifdef CONFIG_CONSFRONT
         case FTYPE_SAVEFILE:
         case FTYPE_CONSOLE:
             fini_console(files[fd].cons.dev);
             files[fd].type = FTYPE_NONE;
             return 0;
+#endif
 	case FTYPE_NONE:
 	    break;
     }
@@ -611,6 +644,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
                 n++;
 	    FD_CLR(i, exceptfds);
 	    break;
+#ifdef CONFIG_XENBUS
 	case FTYPE_XENBUS:
 	    if (FD_ISSET(i, readfds)) {
                 if (files[i].xenbus.events)
@@ -621,6 +655,7 @@ static int select_poll(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exce
 	    FD_CLR(i, writefds);
 	    FD_CLR(i, exceptfds);
 	    break;
+#endif
 	case FTYPE_EVTCHN:
 	case FTYPE_TAP:
 	case FTYPE_BLK:
@@ -705,11 +740,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     fd_set myread, mywrite, myexcept;
     struct thread *thread = get_current();
     s_time_t start = NOW(), stop;
+#ifdef CONFIG_NETFRONT
     DEFINE_WAIT(netfront_w);
+#endif
     DEFINE_WAIT(event_w);
+#ifdef CONFIG_BLKFRONT
     DEFINE_WAIT(blkfront_w);
+#endif
+#ifdef CONFIG_XENBUS
     DEFINE_WAIT(xenbus_watch_w);
+#endif
+#ifdef CONFIG_KBDFRONT
     DEFINE_WAIT(kbdfront_w);
+#endif
     DEFINE_WAIT(console_w);
 
     assert(thread == main_thread);
@@ -727,11 +770,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     /* Tell people we're going to sleep before looking at what they are
      * saying, hence letting them wake us if events happen between here and
      * schedule() */
+#ifdef CONFIG_NETFRONT
     add_waiter(netfront_w, netfront_queue);
+#endif
     add_waiter(event_w, event_queue);
+#ifdef CONFIG_BLKFRONT
     add_waiter(blkfront_w, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     add_waiter(xenbus_watch_w, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     add_waiter(kbdfront_w, kbdfront_queue);
+#endif
     add_waiter(console_w, console_queue);
 
     if (readfds)
@@ -814,11 +865,19 @@ int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
     ret = -1;
 
 out:
+#ifdef CONFIG_NETFRONT
     remove_waiter(netfront_w, netfront_queue);
+#endif
     remove_waiter(event_w, event_queue);
+#ifdef CONFIG_BLKFRONT
     remove_waiter(blkfront_w, blkfront_queue);
+#endif
+#ifdef CONFIG_XENBUS
     remove_waiter(xenbus_watch_w, xenbus_watch_queue);
+#endif
+#ifdef CONFIG_KBDFRONT
     remove_waiter(kbdfront_w, kbdfront_queue);
+#endif
     remove_waiter(console_w, console_queue);
     return ret;
 }
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index aeda548..73eb6fb 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -63,10 +63,12 @@ static void call_main(void *p)
 #ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
 #endif
-#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK) && defined(CONFIG_NETFRONT)
     start_networking();
 #endif
+#ifdef CONFIG_PCIFRONT
     create_thread("pcifront", pcifront_watches, NULL);
+#endif
 
 #ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
@@ -169,7 +171,7 @@ void _exit(int ret)
     close_all_files();
     __libc_fini_array();
     printk("main returned %d\n", ret);
-#ifdef HAVE_LWIP
+#if defined(HAVE_LWIP) && defined(CONFIG_NETFRONT)
     stop_networking();
 #endif
     stop_kernel();
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
index 7ea1d2f..e3a96da 100644
--- a/stubdom/ioemu-minios.cfg
+++ b/stubdom/ioemu-minios.cfg
@@ -1 +1,2 @@
 CONFIG_QEMU_XS_ARGS=y
+CONFIG_PCIFRONT=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:22:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RquC3-0000gD-RM; Fri, 27 Jan 2012 22:22:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RquC3-0000fi-0m
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:22:51 +0000
Received: from [85.158.138.51:32470] by server-7.bemta-3.messagelabs.com id
	8F/C0-31267-F12232F4; Fri, 27 Jan 2012 22:15:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327702558!10963170!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13009 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 22:15:58 -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
	q0RMFtpV014544; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhV026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:36 -0500
Message-Id: <1327702543-25211-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/24] xenstored: support for tdb_copy with
	TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
databases; this is required to run in mini-os which does not use a
filesystem.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/tdb.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..3ecd3fc 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,41 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+		return copy;
+intfail:
+		talloc_free(copy);
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 22:22:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 22:22:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RquC3-0000gD-RM; Fri, 27 Jan 2012 22:22:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RquC3-0000fi-0m
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 22:22:51 +0000
Received: from [85.158.138.51:32470] by server-7.bemta-3.messagelabs.com id
	8F/C0-31267-F12232F4; Fri, 27 Jan 2012 22:15:59 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327702558!10963170!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13009 invoked from network); 27 Jan 2012 22:15:58 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-174.messagelabs.com with SMTP;
	27 Jan 2012 22:15:58 -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
	q0RMFtpV014544; Fri, 27 Jan 2012 22:15:55 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 q0RMFrhV026810; 
	Fri, 27 Jan 2012 17:15:55 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Fri, 27 Jan 2012 17:15:36 -0500
Message-Id: <1327702543-25211-18-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 17/24] xenstored: support for tdb_copy with
	TDB_INTERNAL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

From: Alex Zeffertt <alex.zeffertt@eu.citrix.com>

The tdb_copy function should honor the TDB_INTERNAL flag for in-memory
databases; this is required to run in mini-os which does not use a
filesystem.

Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/xenstore/tdb.c |   35 +++++++++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/tools/xenstore/tdb.c b/tools/xenstore/tdb.c
index 63205e1..3ecd3fc 100644
--- a/tools/xenstore/tdb.c
+++ b/tools/xenstore/tdb.c
@@ -2103,6 +2103,41 @@ TDB_CONTEXT *tdb_copy(TDB_CONTEXT *tdb, const char *outfile)
 	int fd, saved_errno;
 	TDB_CONTEXT *copy;
 
+	if (tdb->flags & TDB_INTERNAL) {
+		struct tdb_header *copydb;
+		
+		copy = talloc_zero(outfile, TDB_CONTEXT);
+		if (copy == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copy, tdb, sizeof(TDB_CONTEXT));
+
+		if (copy->name || copy->locked || copy->device || copy->inode) {
+			fprintf(stderr, "tdb_copy assumption(s) failed\n");
+			goto intfail;
+		}
+
+		copydb = talloc_zero_size(copy, copy->map_size);
+		if (copydb == NULL) {
+			errno = ENOMEM;
+			goto intfail;
+		}
+		memcpy(copydb, copy->map_ptr, copy->map_size);
+		copy->map_ptr = (char*) copydb;
+
+		if (tdb_brlock(tdb, GLOBAL_LOCK, F_UNLCK, F_SETLKW, 0) == -1)
+			goto intfail;
+
+		copy->next = tdbs;
+		tdbs = copy;
+
+		return copy;
+intfail:
+		talloc_free(copy);
+		return NULL;
+	}
+
 	fd = open(outfile, O_TRUNC|O_CREAT|O_WRONLY, 0640);
 	if (fd < 0)
 		return NULL;
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 23:20:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 23:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqv5g-0001vl-2L; Fri, 27 Jan 2012 23:20:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paulian@marinca.net>) id 1Rqv5e-0001vg-5A
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 23:20:18 +0000
X-Env-Sender: paulian@marinca.net
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327706380!50093631!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3753 invoked from network); 27 Jan 2012 23:19:40 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 23:19:40 -0000
Received: by werb14 with SMTP id b14so6464850wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 15:20:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.93.85 with SMTP id k63mr3634920wef.5.1327706416731; Fri,
	27 Jan 2012 15:20:16 -0800 (PST)
Received: by 10.216.182.207 with HTTP; Fri, 27 Jan 2012 15:20:16 -0800 (PST)
Date: Fri, 27 Jan 2012 23:20:16 +0000
Message-ID: <CAFFE2avi4ivVEauq=cgCt5Q9Ua3KuyfT0+ZyY1ZLs21F9uMQhg@mail.gmail.com>
From: Paulian Bogdan Marinca <paulian@marinca.net>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 testing intel machine with 4 physical cpus running 64 bit Xen
4.1.3-rc1.

I have a particular linux VM for which at its kernel boot time ( as
domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
console freezes indefinitely). The domU linux kernel is 3.2.1 and has
XEN compiled in.

Trying to find where the problem is, I found this: at the point where
XEN/Dom0 freezes, the physical cpus 0, 1 and 2 are executing the
idle_loop() from xen/arch/x86/domain.c and the cpu 3 spins
indefinitely in the

d->arch.hvm_domain.irq_lock

( where "d" is the domain of my domU )

This is the Xen call trace of the cpu 3, at the point where it spins forever:

(XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
(XEN)    [<ffff82c4801d0814>] hvm_set_callback_irq_level+0x34/0x150
(XEN)    [<ffff82c4801d1245>] hvm_assert_evtchn_irq+0x65/0x90
(XEN)    [<ffff82c48016e505>] vcpu_mark_events_pending+0x35/0x40
(XEN)    [<ffff82c4801073f5>] evtchn_set_pending+0x135/0x1c0
(XEN)    [<ffff82c4801075e7>] send_guest_pirq+0x57/0x70
(XEN)    [<ffff82c4801d04cb>] assert_gsi+0x5b/0x60
(XEN)    [<ffff82c4801d07bb>] hvm_isa_irq_assert+0x9b/0xc0
(XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
(XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107


A history of acquiring d->arch.hvm_domain.irq_lock shows that cpu 3
tries to acquire the same lock twice

first here:

(XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
(XEN)    [<ffff82c4801d0762>] hvm_isa_irq_assert+0x42/0xc0
(XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
(XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107


at hvm_isa_irq_assert()

and then next at hvm_set_callback_irq_level()

and it thus spins indefinitely.  Also, the vcpu 0 of Dom0 is bound to
cpu 3 at that time.

I am not familiar with XEN internals so I don't know the best way to
create a patch for fixing this. That's why I am posting this to the
xen developers list.

All the best,
Paulian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Fri Jan 27 23:20:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Fri, 27 Jan 2012 23:20:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqv5g-0001vl-2L; Fri, 27 Jan 2012 23:20:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paulian@marinca.net>) id 1Rqv5e-0001vg-5A
	for xen-devel@lists.xensource.com; Fri, 27 Jan 2012 23:20:18 +0000
X-Env-Sender: paulian@marinca.net
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327706380!50093631!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3753 invoked from network); 27 Jan 2012 23:19:40 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	27 Jan 2012 23:19:40 -0000
Received: by werb14 with SMTP id b14so6464850wer.30
	for <xen-devel@lists.xensource.com>;
	Fri, 27 Jan 2012 15:20:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.93.85 with SMTP id k63mr3634920wef.5.1327706416731; Fri,
	27 Jan 2012 15:20:16 -0800 (PST)
Received: by 10.216.182.207 with HTTP; Fri, 27 Jan 2012 15:20:16 -0800 (PST)
Date: Fri, 27 Jan 2012 23:20:16 +0000
Message-ID: <CAFFE2avi4ivVEauq=cgCt5Q9Ua3KuyfT0+ZyY1ZLs21F9uMQhg@mail.gmail.com>
From: Paulian Bogdan Marinca <paulian@marinca.net>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 testing intel machine with 4 physical cpus running 64 bit Xen
4.1.3-rc1.

I have a particular linux VM for which at its kernel boot time ( as
domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
console freezes indefinitely). The domU linux kernel is 3.2.1 and has
XEN compiled in.

Trying to find where the problem is, I found this: at the point where
XEN/Dom0 freezes, the physical cpus 0, 1 and 2 are executing the
idle_loop() from xen/arch/x86/domain.c and the cpu 3 spins
indefinitely in the

d->arch.hvm_domain.irq_lock

( where "d" is the domain of my domU )

This is the Xen call trace of the cpu 3, at the point where it spins forever:

(XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
(XEN)    [<ffff82c4801d0814>] hvm_set_callback_irq_level+0x34/0x150
(XEN)    [<ffff82c4801d1245>] hvm_assert_evtchn_irq+0x65/0x90
(XEN)    [<ffff82c48016e505>] vcpu_mark_events_pending+0x35/0x40
(XEN)    [<ffff82c4801073f5>] evtchn_set_pending+0x135/0x1c0
(XEN)    [<ffff82c4801075e7>] send_guest_pirq+0x57/0x70
(XEN)    [<ffff82c4801d04cb>] assert_gsi+0x5b/0x60
(XEN)    [<ffff82c4801d07bb>] hvm_isa_irq_assert+0x9b/0xc0
(XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
(XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107


A history of acquiring d->arch.hvm_domain.irq_lock shows that cpu 3
tries to acquire the same lock twice

first here:

(XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
(XEN)    [<ffff82c4801d0762>] hvm_isa_irq_assert+0x42/0xc0
(XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
(XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107


at hvm_isa_irq_assert()

and then next at hvm_set_callback_irq_level()

and it thus spins indefinitely.  Also, the vcpu 0 of Dom0 is bound to
cpu 3 at that time.

I am not familiar with XEN internals so I don't know the best way to
create a patch for fixing this. That's why I am posting this to the
xen developers list.

All the best,
Paulian

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 02:29:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 02:29:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqy2M-0008J0-EF; Sat, 28 Jan 2012 02:29:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqy2J-0008Iv-Om
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 02:29:04 +0000
Received: from [85.158.138.51:33242] by server-1.bemta-3.messagelabs.com id
	D2/E9-09565-E6D532F4; Sat, 28 Jan 2012 02:29:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327717741!10795993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTcwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18770 invoked from network); 28 Jan 2012 02:29:01 -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;
	28 Jan 2012 02:29:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,583,1320624000"; d="scan'208";a="10342524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 02:29:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 28 Jan 2012 02:29: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 1Rqy2G-0008O2-Am;
	Sat, 28 Jan 2012 02:29:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rqy2F-0002C2-VC;
	Sat, 28 Jan 2012 02:29:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11649-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 02:28:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11649: 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 11649 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11649/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl            18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl-credit2   18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl-multivcpu 18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl           18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl          18 leak-check/check          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl-sedf-pin 18 leak-check/check         fail blocked in 11643
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 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  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  235ac9bf1338
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  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                                          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:   24606:235ac9bf1338
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Fri Jan 27 17:48:14 2012 +0000
    
    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>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24605:8a7e07afe3ed
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Jan 27 17:09:04 2012 +0000
    
    libxl: fix upstream qemu binary name to what we actually install
    
    Binary is always qemu-system-i386 even for a 64 bit build.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24604:47ea714a4e27
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:26 2012 +0000
    
    libxl: Convert to asynchronous: device removal
    
    Convert libxl_FOO_device_remove, and the function which does the bulk
    of the work, libxl__device_remove, to the new async ops scheme.
    
    Adjust all callers.
    
    Also remove libxl__wait_for_device_state which is now obsolete.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24603:0fc994845796
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:25 2012 +0000
    
    libxl: Introduce libxl__ev_devstate
    
    Provide a new-style asynchronous facility for waiting for device
    states on xenbus.  This will replace libxl__wait_for_device_state,
    after the callers have been updated in later patches.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24602:ccc3656225ef
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:24 2012 +0000
    
    libxl: New convenience macro CONTAINER_OF
    
    Provide a convenient and type-safe wrapper which does the correct
    dance to subtract offsetof.  This is very similar to the
    "container_of" macro in the Linux kernel, but it has an additional
    feature that instead of the type argument you may also pass an
    expression of that type; this makes initialising a variable with
    CONTAINER_OF easier.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24601:03152893aba0
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:24 2012 +0000
    
    libxl: Asynchronous/long-running operation infrastructure
    
    Provide a new set of machinery for writing public libxl functions
    which may take a long time.  The application gets to decide whether
    they want the function to be synchronous, or whether they'd prefer to
    get a callback, or an event, when the operation is complete.
    
    User(s) of this machinery will be introduced in later patch(es).
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24600:cd4bff9d4050
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:23 2012 +0000
    
    libxl: Permit multithreaded event waiting
    
    Previously, the context would be locked whenever we were waiting in
    libxl's own call to poll (waiting for operating system events).
    
    This would mean that multiple simultaneous calls to libxl_event_wait
    in different threads with different parameters would not work
    properly.
    
    If we simply unlock the context, it would be possible for another
    thread to discover the occurrence of the event we were waiting for,
    without us even waking up, and we would remain in poll.  So we need a
    way to wake up other threads: a pipe, one for each thread in poll.
    
    We also need to move some variables from globals in the ctx to be
    per-polling-thread.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24599:d503bdfaba23
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:23 2012 +0000
    
    libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
    
    We want a function for setting fds to nonblocking, so introduce one.
    
    This is a very similar requirement to that for libxl_fd_set_cloexec,
    so make it common with that.
    
    While we're at it, fix a few deficiences that make this latter
    function less desirable than it could be:
     * Change the return from 0/-1 (like a syscall) to a libxl error code
     * Take a boolean parameter for turning the flag on and off
     * Log on error (and so, take a ctx for this purpose)
    
    Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
    such errors are highly unlikely.)
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24598:4f3822ee1f43
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:22 2012 +0000
    
    libxl: New event generation API
    
    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.
    
    The new "libxl_event" structure is blacklisted in the ocaml bindings
    for two reasons:
      - It has a field name "type" (which is a keyword in ocaml);
        the ocaml idl generator should massage this field name on
        output, to "type_" perhaps.
      - The ocaml idl generator does not support KeyedUnion.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24597:db9cac5b2489
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:21 2012 +0000
    
    ocaml, libxl: support "private" fields
    
    The changeset
      24378:b4365e2c2595  libxl: idl: support new "private" type attribute
    is not complete.  Actually using this feature does not work because
    the ocaml idl generator does not know about it.
    
    So add that support.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24596:b3387ae40371
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:20 2012 +0000
    
    libxl: New API for providing OS events to libxl
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24595:f204ead7d9e4
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:19 2012 +0000
    
    xl: fix a couple of memory leaks
    
    * dolog leaked the log message (!)
    
    * main() leaked the config_data (perhaps a false positive from valgrind,
      but it's nicer to tidy it up).
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24594:097f5d9c32f9
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:18 2012 +0000
    
    .gitignore/.hgignore: New names for ioemu dirs, seabios
    
    * Add new seabios clone directories to .gitignore.
    * Add new qemu clone directories to .gitignore.
    * Remove old tools/ioemu (long-obsolete) from .gitignore and .hgignore.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24593:e2722b24dc09
user:        Jim Fehlig <jfehlig@suse.com>
date:        Thu Jan 26 17:43:31 2012 +0000
    
    tools: xencommons init script: Fix setting XENSTORED_ROOTDIR
    
    Due to a logic bug, XENSTORED_ROOTDIR was not being set to
    default value when zero length.
    
    Signed-off-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Sat Jan 28 02:29:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 02:29:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rqy2M-0008J0-EF; Sat, 28 Jan 2012 02:29:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rqy2J-0008Iv-Om
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 02:29:04 +0000
Received: from [85.158.138.51:33242] by server-1.bemta-3.messagelabs.com id
	D2/E9-09565-E6D532F4; Sat, 28 Jan 2012 02:29:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327717741!10795993!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTcwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18770 invoked from network); 28 Jan 2012 02:29:01 -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;
	28 Jan 2012 02:29:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,583,1320624000"; d="scan'208";a="10342524"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 02:29:00 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 28 Jan 2012 02:29: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 1Rqy2G-0008O2-Am;
	Sat, 28 Jan 2012 02:29:00 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rqy2F-0002C2-VC;
	Sat, 28 Jan 2012 02:29:00 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11649-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 02:28:59 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11649: 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 11649 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11649/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl            18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl-credit2   18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl-multivcpu 18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl           18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl          18 leak-check/check          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl-sedf-pin 18 leak-check/check         fail blocked in 11643
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 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  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  235ac9bf1338
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  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                                          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:   24606:235ac9bf1338
tag:         tip
user:        Roger Pau Monne <roger.pau@entel.upc.edu>
date:        Fri Jan 27 17:48:14 2012 +0000
    
    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>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24605:8a7e07afe3ed
user:        Ian Campbell <ian.campbell@citrix.com>
date:        Fri Jan 27 17:09:04 2012 +0000
    
    libxl: fix upstream qemu binary name to what we actually install
    
    Binary is always qemu-system-i386 even for a 64 bit build.
    
    Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
changeset:   24604:47ea714a4e27
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:26 2012 +0000
    
    libxl: Convert to asynchronous: device removal
    
    Convert libxl_FOO_device_remove, and the function which does the bulk
    of the work, libxl__device_remove, to the new async ops scheme.
    
    Adjust all callers.
    
    Also remove libxl__wait_for_device_state which is now obsolete.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24603:0fc994845796
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:25 2012 +0000
    
    libxl: Introduce libxl__ev_devstate
    
    Provide a new-style asynchronous facility for waiting for device
    states on xenbus.  This will replace libxl__wait_for_device_state,
    after the callers have been updated in later patches.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24602:ccc3656225ef
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:24 2012 +0000
    
    libxl: New convenience macro CONTAINER_OF
    
    Provide a convenient and type-safe wrapper which does the correct
    dance to subtract offsetof.  This is very similar to the
    "container_of" macro in the Linux kernel, but it has an additional
    feature that instead of the type argument you may also pass an
    expression of that type; this makes initialising a variable with
    CONTAINER_OF easier.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24601:03152893aba0
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:24 2012 +0000
    
    libxl: Asynchronous/long-running operation infrastructure
    
    Provide a new set of machinery for writing public libxl functions
    which may take a long time.  The application gets to decide whether
    they want the function to be synchronous, or whether they'd prefer to
    get a callback, or an event, when the operation is complete.
    
    User(s) of this machinery will be introduced in later patch(es).
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24600:cd4bff9d4050
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:23 2012 +0000
    
    libxl: Permit multithreaded event waiting
    
    Previously, the context would be locked whenever we were waiting in
    libxl's own call to poll (waiting for operating system events).
    
    This would mean that multiple simultaneous calls to libxl_event_wait
    in different threads with different parameters would not work
    properly.
    
    If we simply unlock the context, it would be possible for another
    thread to discover the occurrence of the event we were waiting for,
    without us even waking up, and we would remain in poll.  So we need a
    way to wake up other threads: a pipe, one for each thread in poll.
    
    We also need to move some variables from globals in the ctx to be
    per-polling-thread.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24599:d503bdfaba23
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:23 2012 +0000
    
    libxl: introduce libxl_fd_set_nonblock, rationalise _cloexec
    
    We want a function for setting fds to nonblocking, so introduce one.
    
    This is a very similar requirement to that for libxl_fd_set_cloexec,
    so make it common with that.
    
    While we're at it, fix a few deficiences that make this latter
    function less desirable than it could be:
     * Change the return from 0/-1 (like a syscall) to a libxl error code
     * Take a boolean parameter for turning the flag on and off
     * Log on error (and so, take a ctx for this purpose)
    
    Change callers of libxl_fd_set_cloexec to notice errors.  (Although,
    such errors are highly unlikely.)
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24598:4f3822ee1f43
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:22 2012 +0000
    
    libxl: New event generation API
    
    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.
    
    The new "libxl_event" structure is blacklisted in the ocaml bindings
    for two reasons:
      - It has a field name "type" (which is a keyword in ocaml);
        the ocaml idl generator should massage this field name on
        output, to "type_" perhaps.
      - The ocaml idl generator does not support KeyedUnion.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24597:db9cac5b2489
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:21 2012 +0000
    
    ocaml, libxl: support "private" fields
    
    The changeset
      24378:b4365e2c2595  libxl: idl: support new "private" type attribute
    is not complete.  Actually using this feature does not work because
    the ocaml idl generator does not know about it.
    
    So add that support.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24596:b3387ae40371
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:20 2012 +0000
    
    libxl: New API for providing OS events to libxl
    
    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>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24595:f204ead7d9e4
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:19 2012 +0000
    
    xl: fix a couple of memory leaks
    
    * dolog leaked the log message (!)
    
    * main() leaked the config_data (perhaps a false positive from valgrind,
      but it's nicer to tidy it up).
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24594:097f5d9c32f9
user:        Ian Jackson <ian.jackson@eu.citrix.com>
date:        Fri Jan 27 17:01:18 2012 +0000
    
    .gitignore/.hgignore: New names for ioemu dirs, seabios
    
    * Add new seabios clone directories to .gitignore.
    * Add new qemu clone directories to .gitignore.
    * Remove old tools/ioemu (long-obsolete) from .gitignore and .hgignore.
    
    Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
    
    
changeset:   24593:e2722b24dc09
user:        Jim Fehlig <jfehlig@suse.com>
date:        Thu Jan 26 17:43:31 2012 +0000
    
    tools: xencommons init script: Fix setting XENSTORED_ROOTDIR
    
    Due to a logic bug, XENSTORED_ROOTDIR was not being set to
    default value when zero length.
    
    Signed-off-by: Jim Fehlig <jfehlig@suse.com>
    Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
    Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
    
    
========================================
commit bb36d632e4cabf47882adff07a45c6702c4a5b30
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Jan 5 17:16:46 2012 +0000

    qemu-xen: adjust MSI-X related log messages
    
    Several of these messages we coded using line continuation within a
    string literal. This is generally not recommended and also lead to odd
    sequences of many blanks in the middle of the messages.
    
    The message indicating a discarded write due to MSI-X already being
    enabled doesn't need to be issued when a write doesn't actually modify
    the current value. Adjust the surrounding logic accordingly, and
    eliminate some redundancy as well as the sometimes unnecessary access
    to the physical MSI-X table.
    
    Finally, adjust the wording of a few messages to be more precise and/or
    more useful.
    
    Signed-off-by: Jan Beulich <jbeulich@suse.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 Sat Jan 28 05:19:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 05:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr0gx-0001jQ-4r; Sat, 28 Jan 2012 05: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 1Rr0gv-0001jL-6L
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 05:19:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327727899!52066726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTcwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32074 invoked from network); 28 Jan 2012 05:18:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 05:18:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,583,1320624000"; d="scan'208";a="10343359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 05: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; Sat, 28 Jan 2012 05:19: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 1Rr0gt-0000tu-Bj;
	Sat, 28 Jan 2012 05:19:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rr0gt-0004NA-AL;
	Sat, 28 Jan 2012 05:19:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11651-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 05:19:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11651: 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 11651 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11651/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 11644
 test-amd64-amd64-win          7 windows-install    fail in 11644 pass in 11651

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-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-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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 05:19:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 05:19:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr0gx-0001jQ-4r; Sat, 28 Jan 2012 05: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 1Rr0gv-0001jL-6L
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 05:19:09 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327727899!52066726!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTcwMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32074 invoked from network); 28 Jan 2012 05:18:19 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 05:18:19 -0000
X-IronPort-AV: E=Sophos;i="4.71,583,1320624000"; d="scan'208";a="10343359"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 05: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; Sat, 28 Jan 2012 05:19: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 1Rr0gt-0000tu-Bj;
	Sat, 28 Jan 2012 05:19:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rr0gt-0004NA-AL;
	Sat, 28 Jan 2012 05:19:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11651-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 05:19:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11651: 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 11651 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11651/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-sedf-pin 13 guest-localmigrate.2        fail pass in 11644
 test-amd64-amd64-win          7 windows-install    fail in 11644 pass in 11651

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-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-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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   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                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 08:14:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 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 1Rr3PT-0003la-Ul; Sat, 28 Jan 2012 08:13:19 +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 1Rr3PS-0003lU-EG
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 08:13:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327738360!50117536!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27818 invoked from network); 28 Jan 2012 08:12:40 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 08:12:40 -0000
Received: by wgbdt11 with SMTP id dt11so2407603wgb.24
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 00:13: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=UWylk6lIUh/cfvxoBiTu01HHbH//uYLdK2NzSWDJxPc=;
	b=ryqWls47RxKjB0CM32d73A4aGN2qrzuvKBjmzBQb4/DNdJJBkfkOVa/G/Mq8CSStvc
	jWk4TjjhvS9cj0To4qUhJKN8r4yHQyvzIHygxjX4Xkncfie+XfeYPjWBdWa9sLlTE2JR
	g3XMPw/znjgGdjFO9Vujbm4bHmss3PuZ3xZVA=
Received: by 10.180.86.198 with SMTP id r6mr13993969wiz.2.1327738396796;
	Sat, 28 Jan 2012 00:13:16 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dw7sm2061571wib.4.2012.01.28.00.13.14
	(version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 00:13:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 28 Jan 2012 08:13:12 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paulian Bogdan Marinca <paulian@marinca.net>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB495E98.29F01%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
Thread-Index: AczdlK1X3R+gr3ozBEqHfsLNnRzeAg==
In-Reply-To: <CAFFE2avi4ivVEauq=cgCt5Q9Ua3KuyfT0+ZyY1ZLs21F9uMQhg@mail.gmail.com>
Mime-version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@marinca.net> wrote:

> I have a testing intel machine with 4 physical cpus running 64 bit Xen
> 4.1.3-rc1.
> 
> I have a particular linux VM for which at its kernel boot time ( as
> domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
> console freezes indefinitely). The domU linux kernel is 3.2.1 and has
> XEN compiled in.
> 
> Trying to find where the problem is, I found this: at the point where
> XEN/Dom0 freezes, the physical cpus 0, 1 and 2 are executing the
> idle_loop() from xen/arch/x86/domain.c and the cpu 3 spins
> indefinitely in the

Thanks, the offending patch is xen-unstable:22409, I think. It needs an HVM
guest which maps emulated IRQs onto event channels, but then has event
channel notifications mapped onto an emulated IRQ (rather than 'direct
vector delivery'). An unlikely state of affairs, maybe it's a temporary
setup during guest boot, or maybe it indicates a bug in the guest as well.

In any case, cc'ing the author, Stefano. This ought to be easy to fix. We
could make the irq_lock a recursive lock for example.

 -- Keir

> d->arch.hvm_domain.irq_lock
> 
> ( where "d" is the domain of my domU )
> 
> This is the Xen call trace of the cpu 3, at the point where it spins forever:
> 
> (XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
> (XEN)    [<ffff82c4801d0814>] hvm_set_callback_irq_level+0x34/0x150
> (XEN)    [<ffff82c4801d1245>] hvm_assert_evtchn_irq+0x65/0x90
> (XEN)    [<ffff82c48016e505>] vcpu_mark_events_pending+0x35/0x40
> (XEN)    [<ffff82c4801073f5>] evtchn_set_pending+0x135/0x1c0
> (XEN)    [<ffff82c4801075e7>] send_guest_pirq+0x57/0x70
> (XEN)    [<ffff82c4801d04cb>] assert_gsi+0x5b/0x60
> (XEN)    [<ffff82c4801d07bb>] hvm_isa_irq_assert+0x9b/0xc0
> (XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
> (XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107
> 
> 
> A history of acquiring d->arch.hvm_domain.irq_lock shows that cpu 3
> tries to acquire the same lock twice
> 
> first here:
> 
> (XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
> (XEN)    [<ffff82c4801d0762>] hvm_isa_irq_assert+0x42/0xc0
> (XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
> (XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107
> 
> 
> at hvm_isa_irq_assert()
> 
> and then next at hvm_set_callback_irq_level()
> 
> and it thus spins indefinitely.  Also, the vcpu 0 of Dom0 is bound to
> cpu 3 at that time.
> 
> I am not familiar with XEN internals so I don't know the best way to
> create a patch for fixing this. That's why I am posting this to the
> xen developers list.
> 
> All the best,
> Paulian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 28 08:14:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 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 1Rr3PT-0003la-Ul; Sat, 28 Jan 2012 08:13:19 +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 1Rr3PS-0003lU-EG
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 08:13:18 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327738360!50117536!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27818 invoked from network); 28 Jan 2012 08:12:40 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 08:12:40 -0000
Received: by wgbdt11 with SMTP id dt11so2407603wgb.24
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 00:13: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=UWylk6lIUh/cfvxoBiTu01HHbH//uYLdK2NzSWDJxPc=;
	b=ryqWls47RxKjB0CM32d73A4aGN2qrzuvKBjmzBQb4/DNdJJBkfkOVa/G/Mq8CSStvc
	jWk4TjjhvS9cj0To4qUhJKN8r4yHQyvzIHygxjX4Xkncfie+XfeYPjWBdWa9sLlTE2JR
	g3XMPw/znjgGdjFO9Vujbm4bHmss3PuZ3xZVA=
Received: by 10.180.86.198 with SMTP id r6mr13993969wiz.2.1327738396796;
	Sat, 28 Jan 2012 00:13:16 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id dw7sm2061571wib.4.2012.01.28.00.13.14
	(version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 00:13:14 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 28 Jan 2012 08:13:12 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Paulian Bogdan Marinca <paulian@marinca.net>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB495E98.29F01%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
Thread-Index: AczdlK1X3R+gr3ozBEqHfsLNnRzeAg==
In-Reply-To: <CAFFE2avi4ivVEauq=cgCt5Q9Ua3KuyfT0+ZyY1ZLs21F9uMQhg@mail.gmail.com>
Mime-version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@marinca.net> wrote:

> I have a testing intel machine with 4 physical cpus running 64 bit Xen
> 4.1.3-rc1.
> 
> I have a particular linux VM for which at its kernel boot time ( as
> domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
> console freezes indefinitely). The domU linux kernel is 3.2.1 and has
> XEN compiled in.
> 
> Trying to find where the problem is, I found this: at the point where
> XEN/Dom0 freezes, the physical cpus 0, 1 and 2 are executing the
> idle_loop() from xen/arch/x86/domain.c and the cpu 3 spins
> indefinitely in the

Thanks, the offending patch is xen-unstable:22409, I think. It needs an HVM
guest which maps emulated IRQs onto event channels, but then has event
channel notifications mapped onto an emulated IRQ (rather than 'direct
vector delivery'). An unlikely state of affairs, maybe it's a temporary
setup during guest boot, or maybe it indicates a bug in the guest as well.

In any case, cc'ing the author, Stefano. This ought to be easy to fix. We
could make the irq_lock a recursive lock for example.

 -- Keir

> d->arch.hvm_domain.irq_lock
> 
> ( where "d" is the domain of my domU )
> 
> This is the Xen call trace of the cpu 3, at the point where it spins forever:
> 
> (XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
> (XEN)    [<ffff82c4801d0814>] hvm_set_callback_irq_level+0x34/0x150
> (XEN)    [<ffff82c4801d1245>] hvm_assert_evtchn_irq+0x65/0x90
> (XEN)    [<ffff82c48016e505>] vcpu_mark_events_pending+0x35/0x40
> (XEN)    [<ffff82c4801073f5>] evtchn_set_pending+0x135/0x1c0
> (XEN)    [<ffff82c4801075e7>] send_guest_pirq+0x57/0x70
> (XEN)    [<ffff82c4801d04cb>] assert_gsi+0x5b/0x60
> (XEN)    [<ffff82c4801d07bb>] hvm_isa_irq_assert+0x9b/0xc0
> (XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
> (XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107
> 
> 
> A history of acquiring d->arch.hvm_domain.irq_lock shows that cpu 3
> tries to acquire the same lock twice
> 
> first here:
> 
> (XEN) [<ffff82c480126a06>] _spin_lock+0x56/0x110
> (XEN)    [<ffff82c4801d0762>] hvm_isa_irq_assert+0x42/0xc0
> (XEN)    [<ffff82c4801cd642>] do_hvm_op+0x1982/0x22e0
> (XEN)    [<ffff82c480235ffe>] compat_hypercall+0xae/0x107
> 
> 
> at hvm_isa_irq_assert()
> 
> and then next at hvm_set_callback_irq_level()
> 
> and it thus spins indefinitely.  Also, the vcpu 0 of Dom0 is bound to
> cpu 3 at that time.
> 
> I am not familiar with XEN internals so I don't know the best way to
> create a patch for fixing this. That's why I am posting this to the
> xen developers list.
> 
> All the best,
> Paulian
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 28 10:47:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 10:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr5o5-0005NH-4H; Sat, 28 Jan 2012 10:46:53 +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 1Rr5o3-0005NB-VQ
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 10:46:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327747600!4404291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26207 invoked from network); 28 Jan 2012 10:46:41 -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;
	28 Jan 2012 10:46:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,584,1320624000"; d="scan'208";a="10344857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 10: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; Sat, 28 Jan 2012 10:46: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 1Rr5nq-0002qT-4z;
	Sat, 28 Jan 2012 10:46:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rr5nq-0004K8-39;
	Sat, 28 Jan 2012 10:46:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11660-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 10:46:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11660: 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 11660 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11660/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl            18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl-credit2   18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl-multivcpu 18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl           18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl          18 leak-check/check          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl-sedf-pin 18 leak-check/check         fail blocked in 11643
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 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  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  54000bca7a6a
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  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                                          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.

(No revision log; it would be 384 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 Jan 28 10:47:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 10:47:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr5o5-0005NH-4H; Sat, 28 Jan 2012 10:46:53 +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 1Rr5o3-0005NB-VQ
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 10:46:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327747600!4404291!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26207 invoked from network); 28 Jan 2012 10:46:41 -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;
	28 Jan 2012 10:46:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,584,1320624000"; d="scan'208";a="10344857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 10: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; Sat, 28 Jan 2012 10:46: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 1Rr5nq-0002qT-4z;
	Sat, 28 Jan 2012 10:46:38 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rr5nq-0004K8-39;
	Sat, 28 Jan 2012 10:46:38 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11660-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 10:46:38 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11660: 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 11660 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11660/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-i386-i386-xl            18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl-credit2   18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl-multivcpu 18 leak-check/check          fail REGR. vs. 11643
 test-amd64-i386-xl           18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl          18 leak-check/check          fail REGR. vs. 11643

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl-sedf-pin 18 leak-check/check         fail blocked in 11643
 test-i386-i386-win           14 guest-start.2                fail   like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 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  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  54000bca7a6a
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  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                                          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.

(No revision log; it would be 384 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 Jan 28 10:51:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 10:51:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr5rl-0005TO-Op; Sat, 28 Jan 2012 10:50:41 +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 1Rr5rk-0005TH-CJ
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 10:50:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327747832!4404598!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30445 invoked from network); 28 Jan 2012 10:50:32 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 10:50:32 -0000
Received: by eekb45 with SMTP id b45so14915717eek.30
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 02:50: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:user-agent:date:from:to:cc;
	bh=RxLu4uGF2tA13/sj75tcDa8zvM1KgT6C0iy5i3BMLLU=;
	b=qJpzmWweKod6UOlsJjgXK5jBIXiBNXEd2iVidnarClVR1JnszpgCA9lRt9AWMbu4ce
	vVkZOBmGPwaGUTg73vMUhg1sIhDs2kHMIh9tOy43rj/iQPKZ2YGcWmNl8kpLQorM2mUC
	nhAEsjAAp3tnuDWQE/2DC22f2d08dHF1Ee5/M=
Received: by 10.14.22.16 with SMTP id s16mr663289ees.2.1327747831081;
	Sat, 28 Jan 2012 02:50:31 -0800 (PST)
Received: from debian.localdomain (81.184.59.225.dyn.user.ono.com.
	[81.184.59.225])
	by mx.google.com with ESMTPS id e12sm41903292eea.5.2012.01.28.02.50.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 28 Jan 2012 02:50:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 833bcc6d444eaa6cb62d9fe94e3fc538bc13ec69
Message-Id: <833bcc6d444eaa6cb62d.1327747782@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Sat, 28 Jan 2012 11:49:42 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH v4] 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 1326606960 -3600
# Node ID 833bcc6d444eaa6cb62d9fe94e3fc538bc13ec69
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: add support for yajl 2.x

This patch adds support for yajl versions 2.x, while retaining 1.x
compatibility. All the needed ifdefs can be found in libxl_json.h.

Tested with yajl 2.0.3, 1.0.12 and 1.0.8.

Changes since v3:

 * Updated to apply against current unstable.

Changes since v2:

 * Moved all ifdefs to libxl_json.h, as Ian Jackson suggested.

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 e2722b24dc09 -r 833bcc6d444e Config.mk
--- a/Config.mk	Thu Jan 26 17:43:31 2012 +0000
+++ b/Config.mk	Sun Jan 15 06:56:00 2012 +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 e2722b24dc09 -r 833bcc6d444e tools/check/check_yajl_lib
--- a/tools/check/check_yajl_lib	Thu Jan 26 17:43:31 2012 +0000
+++ /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 e2722b24dc09 -r 833bcc6d444e tools/libxl/Makefile
--- a/tools/libxl/Makefile	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/Makefile	Sun Jan 15 06:56:00 2012 +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 e2722b24dc09 -r 833bcc6d444e tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_json.c	Sun Jan 15 06:56:00 2012 +0100
@@ -517,7 +517,7 @@ static bool is_decimal(const char *s, un
     return false;
 }
 
-static int json_callback_number(void *opaque, const char *s, unsigned int len)
+static int json_callback_number(void *opaque, const char *s, libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     libxl__json_object *obj = NULL;
@@ -574,7 +574,7 @@ out:
 }
 
 static int json_callback_string(void *opaque, const unsigned char *str,
-                                unsigned int len)
+                                libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -607,7 +607,7 @@ static int json_callback_string(void *op
 }
 
 static int json_callback_map_key(void *opaque, const unsigned char *str,
-                                 unsigned int len)
+                                 libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -770,17 +770,13 @@ libxl__json_object *libxl__json_parse(li
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
     if (yajl_ctx.hand == NULL) {
-        yajl_parser_config cfg = {
-            .allowComments = 1,
-            .checkUTF8 = 1,
-        };
-        yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
+        yajl_ctx.hand = libxl__yajl_alloc(&callbacks, NULL, &yajl_ctx);
     }
     status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
     if (status != yajl_status_ok)
         goto out;
 
-    status = yajl_parse_complete(yajl_ctx.hand);
+    status = yajl_complete_parse(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
 
@@ -832,14 +828,13 @@ 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)
 {
-    yajl_gen_config conf = { 1, "    " };
     const unsigned char *buf;
     char *ret = NULL;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
     if (!hand)
         return NULL;
 
diff -r e2722b24dc09 -r 833bcc6d444e tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_json.h	Sun Jan 15 06:56:00 2012 +0100
@@ -16,7 +16,58 @@
 #define LIBXL_JSON_H
 
 #include <yajl/yajl_gen.h>
+#include <yajl/yajl_parse.h>
+
+#ifdef HAVE_YAJL_VERSION
+#  include <yajl/yajl_version.h>
+#endif
 
 #include <_libxl_types_json.h>
 
+/* YAJL version check */
+#if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
+#  define HAVE_YAJL_V2 1
+#endif
+
+#ifdef HAVE_YAJL_V2
+
+typedef size_t libxl_yajl_length;
+
+static inline yajl_handle libxl__yajl_alloc(const yajl_callbacks *callbacks,
+                                            yajl_alloc_funcs *allocFuncs,
+                                            void *ctx)
+{
+    return yajl_alloc(callbacks, allocFuncs, ctx);
+}
+
+static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+{
+    return yajl_gen_alloc(allocFuncs);
+}
+
+#else /* !HAVE_YAJL_V2 */
+
+#define yajl_complete_parse yajl_parse_complete
+
+typedef unsigned int libxl_yajl_length;
+
+static inline yajl_handle libxl__yajl_alloc(const yajl_callbacks *callbacks,
+                                            const yajl_alloc_funcs *allocFuncs,
+                                            void *ctx)
+{
+    yajl_parser_config cfg = {
+        .allowComments = 1,
+        .checkUTF8 = 1,
+    };
+    return yajl_alloc(callbacks, &cfg, allocFuncs, ctx);
+}
+
+static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+{
+    yajl_gen_config conf = { 1, "    " };
+    return yajl_gen_alloc(&conf, allocFuncs);
+}
+
+#endif /* !HAVE_YAJL_V2 */
+
 #endif /* LIBXL_JSON_H */
diff -r e2722b24dc09 -r 833bcc6d444e tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_qmp.c	Sun Jan 15 06:56:00 2012 +0100
@@ -452,15 +452,15 @@ static char *qmp_send_prepare(libxl__gc 
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
-    yajl_gen_config conf = { 0, NULL };
     const unsigned char *buf = NULL;
     char *ret = NULL;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
+
     if (!hand) {
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 10:51:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 10:51:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr5rl-0005TO-Op; Sat, 28 Jan 2012 10:50:41 +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 1Rr5rk-0005TH-CJ
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 10:50:40 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327747832!4404598!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30445 invoked from network); 28 Jan 2012 10:50:32 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-2.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 10:50:32 -0000
Received: by eekb45 with SMTP id b45so14915717eek.30
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 02:50: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:user-agent:date:from:to:cc;
	bh=RxLu4uGF2tA13/sj75tcDa8zvM1KgT6C0iy5i3BMLLU=;
	b=qJpzmWweKod6UOlsJjgXK5jBIXiBNXEd2iVidnarClVR1JnszpgCA9lRt9AWMbu4ce
	vVkZOBmGPwaGUTg73vMUhg1sIhDs2kHMIh9tOy43rj/iQPKZ2YGcWmNl8kpLQorM2mUC
	nhAEsjAAp3tnuDWQE/2DC22f2d08dHF1Ee5/M=
Received: by 10.14.22.16 with SMTP id s16mr663289ees.2.1327747831081;
	Sat, 28 Jan 2012 02:50:31 -0800 (PST)
Received: from debian.localdomain (81.184.59.225.dyn.user.ono.com.
	[81.184.59.225])
	by mx.google.com with ESMTPS id e12sm41903292eea.5.2012.01.28.02.50.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Sat, 28 Jan 2012 02:50:29 -0800 (PST)
MIME-Version: 1.0
X-Mercurial-Node: 833bcc6d444eaa6cb62d9fe94e3fc538bc13ec69
Message-Id: <833bcc6d444eaa6cb62d.1327747782@debian.localdomain>
User-Agent: Mercurial-patchbomb/2.0.2
Date: Sat, 28 Jan 2012 11:49:42 +0100
From: Roger Pau Monne <roger.pau@entel.upc.edu>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [PATCH v4] 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 1326606960 -3600
# Node ID 833bcc6d444eaa6cb62d9fe94e3fc538bc13ec69
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: add support for yajl 2.x

This patch adds support for yajl versions 2.x, while retaining 1.x
compatibility. All the needed ifdefs can be found in libxl_json.h.

Tested with yajl 2.0.3, 1.0.12 and 1.0.8.

Changes since v3:

 * Updated to apply against current unstable.

Changes since v2:

 * Moved all ifdefs to libxl_json.h, as Ian Jackson suggested.

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 e2722b24dc09 -r 833bcc6d444e Config.mk
--- a/Config.mk	Thu Jan 26 17:43:31 2012 +0000
+++ b/Config.mk	Sun Jan 15 06:56:00 2012 +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 e2722b24dc09 -r 833bcc6d444e tools/check/check_yajl_lib
--- a/tools/check/check_yajl_lib	Thu Jan 26 17:43:31 2012 +0000
+++ /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 e2722b24dc09 -r 833bcc6d444e tools/libxl/Makefile
--- a/tools/libxl/Makefile	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/Makefile	Sun Jan 15 06:56:00 2012 +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 e2722b24dc09 -r 833bcc6d444e tools/libxl/libxl_json.c
--- a/tools/libxl/libxl_json.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_json.c	Sun Jan 15 06:56:00 2012 +0100
@@ -517,7 +517,7 @@ static bool is_decimal(const char *s, un
     return false;
 }
 
-static int json_callback_number(void *opaque, const char *s, unsigned int len)
+static int json_callback_number(void *opaque, const char *s, libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     libxl__json_object *obj = NULL;
@@ -574,7 +574,7 @@ out:
 }
 
 static int json_callback_string(void *opaque, const unsigned char *str,
-                                unsigned int len)
+                                libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -607,7 +607,7 @@ static int json_callback_string(void *op
 }
 
 static int json_callback_map_key(void *opaque, const unsigned char *str,
-                                 unsigned int len)
+                                 libxl_yajl_length len)
 {
     libxl__yajl_ctx *ctx = opaque;
     char *t = NULL;
@@ -770,17 +770,13 @@ libxl__json_object *libxl__json_parse(li
     DEBUG_GEN_ALLOC(&yajl_ctx);
 
     if (yajl_ctx.hand == NULL) {
-        yajl_parser_config cfg = {
-            .allowComments = 1,
-            .checkUTF8 = 1,
-        };
-        yajl_ctx.hand = yajl_alloc(&callbacks, &cfg, NULL, &yajl_ctx);
+        yajl_ctx.hand = libxl__yajl_alloc(&callbacks, NULL, &yajl_ctx);
     }
     status = yajl_parse(yajl_ctx.hand, (const unsigned char *)s, strlen(s));
     if (status != yajl_status_ok)
         goto out;
 
-    status = yajl_parse_complete(yajl_ctx.hand);
+    status = yajl_complete_parse(yajl_ctx.hand);
     if (status != yajl_status_ok)
         goto out;
 
@@ -832,14 +828,13 @@ 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)
 {
-    yajl_gen_config conf = { 1, "    " };
     const unsigned char *buf;
     char *ret = NULL;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
     if (!hand)
         return NULL;
 
diff -r e2722b24dc09 -r 833bcc6d444e tools/libxl/libxl_json.h
--- a/tools/libxl/libxl_json.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_json.h	Sun Jan 15 06:56:00 2012 +0100
@@ -16,7 +16,58 @@
 #define LIBXL_JSON_H
 
 #include <yajl/yajl_gen.h>
+#include <yajl/yajl_parse.h>
+
+#ifdef HAVE_YAJL_VERSION
+#  include <yajl/yajl_version.h>
+#endif
 
 #include <_libxl_types_json.h>
 
+/* YAJL version check */
+#if defined(YAJL_MAJOR) && (YAJL_MAJOR > 1)
+#  define HAVE_YAJL_V2 1
+#endif
+
+#ifdef HAVE_YAJL_V2
+
+typedef size_t libxl_yajl_length;
+
+static inline yajl_handle libxl__yajl_alloc(const yajl_callbacks *callbacks,
+                                            yajl_alloc_funcs *allocFuncs,
+                                            void *ctx)
+{
+    return yajl_alloc(callbacks, allocFuncs, ctx);
+}
+
+static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+{
+    return yajl_gen_alloc(allocFuncs);
+}
+
+#else /* !HAVE_YAJL_V2 */
+
+#define yajl_complete_parse yajl_parse_complete
+
+typedef unsigned int libxl_yajl_length;
+
+static inline yajl_handle libxl__yajl_alloc(const yajl_callbacks *callbacks,
+                                            const yajl_alloc_funcs *allocFuncs,
+                                            void *ctx)
+{
+    yajl_parser_config cfg = {
+        .allowComments = 1,
+        .checkUTF8 = 1,
+    };
+    return yajl_alloc(callbacks, &cfg, allocFuncs, ctx);
+}
+
+static inline yajl_gen libxl__yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
+{
+    yajl_gen_config conf = { 1, "    " };
+    return yajl_gen_alloc(&conf, allocFuncs);
+}
+
+#endif /* !HAVE_YAJL_V2 */
+
 #endif /* LIBXL_JSON_H */
diff -r e2722b24dc09 -r 833bcc6d444e tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_qmp.c	Sun Jan 15 06:56:00 2012 +0100
@@ -452,15 +452,15 @@ static char *qmp_send_prepare(libxl__gc 
                               qmp_callback_t callback, void *opaque,
                               qmp_request_context *context)
 {
-    yajl_gen_config conf = { 0, NULL };
     const unsigned char *buf = NULL;
     char *ret = NULL;
-    unsigned int len = 0;
+    libxl_yajl_length len = 0;
     yajl_gen_status s;
     yajl_gen hand;
     callback_id_pair *elm = NULL;
 
-    hand = yajl_gen_alloc(&conf, NULL);
+    hand = libxl__yajl_gen_alloc(NULL);
+
     if (!hand) {
         return NULL;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 11:10:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 11:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr6Aa-0005od-Gy; Sat, 28 Jan 2012 11:10: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 1Rr6AY-0005oR-Bb
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 11:10:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327748998!12379523!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31295 invoked from network); 28 Jan 2012 11:10:00 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 11:10:00 -0000
Received: by dajs34 with SMTP id s34so17531969daj.30
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 03:09: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=pObm4c0tpfrSYIgH5UPob0i07r5jM96I9FTN2PZ8Kmw=;
	b=eDVjqEwA6h+OtuC2CeEi34bKcs5SxEtnNpoNp7Jdh2p6I2xZN0enpjJTlXRlw0FDVy
	3C1SMXEHRGdJvCC0iwiNQe85o2lWYKQZ6WvlgmNtzTINsLNvkE4fcxvFtrMelJoCQ8Qw
	XP2JiwY2AsS9N8nHvHu2Cw1XXpOweT/tfQreU=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr22902819pbc.5.1327748998024; Sat,
	28 Jan 2012 03:09:58 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Sat, 28 Jan 2012 03:09:57 -0800 (PST)
In-Reply-To: <20258.63094.694795.399684@mariner.uk.xensource.com>
References: <a1986ef30b7dab4f60fe.1326606964@alpine.localdomain>
	<20258.63094.694795.399684@mariner.uk.xensource.com>
Date: Sat, 28 Jan 2012 12:09:57 +0100
X-Google-Sender-Auth: lCI6-zSphhpWVGfVo32zA1U8GPY
Message-ID: <CAPLaKK4+uv7HC2ACjjnG+t_9+nQOahdX=gKwc+VtD1AOg1AyLw@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 v3] 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

MjAxMi8xLzI3IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENIIHYzXSBsaWJ4bDogYWRkIHN1
cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+IGxpYnhsOiBhZGQgc3VwcG9ydCBmb3IgeWFqbCAyLngK
Pj4KPj4gVGhpcyBwYXRjaCBhZGRzIHN1cHBvcnQgZm9yIHlhamwgdmVyc2lvbnMgMi54LCB3aGls
ZSByZXRhaW5pbmcgMS54Cj4+IGNvbXBhdGliaWxpdHkuIEFsbCB0aGUgbmVlZGVkIGlmZGVmcyBj
YW4gYmUgZm91bmQgaW4gbGlieGxfanNvbi5oLgo+Cj4gVGhhbmtzLiDCoEknbSBhZnJhaWQgdGhp
cyBuZWVkcyBhIHJlZnJlc2g6Cj4KPiDCoHBhdGNoaW5nIGZpbGUgdG9vbHMvbGlieGwvbGlieGxf
anNvbi5oCj4gwqBIdW5rICMxIEZBSUxFRCBhdCAxNi4KPiDCoDEgb3V0IG9mIDEgaHVuayBGQUlM
RUQgLS0gc2F2aW5nIHJlamVjdHMgdG8gZmlsZSB0b29scy9saWJ4bC9saWJ4bF9qc29uLmgucmVq
Cj4KPiBBbHNvLCB3aGlsZSB5b3UncmUgYXQgaXQ6Cj4+ICtzdGF0aWMgaW5saW5lIHlhamxfZ2Vu
IGxpYnhsX195YWpsX2dlbl9hbGxvYyhjb25zdCB5YWpsX2FsbG9jX2Z1bmNzICphbGxvY0Z1bmNz
KQo+PiArewo+PiArIMKgIMKgcmV0dXJuIHlhamxfZ2VuX2FsbG9jKGFsbG9jRnVuY3MpOwo+PiAr
fQo+PiArI2Vsc2UKPgo+IEEgY291cGxlIG9mIGJsYW5rIGxpbmVzIGFyb3VuZCB0aGlzICNpZnMg
YW5kICNlbHNlcyBtaWdodCBiZSBuaWNlLgo+IEFuZCBhbHNvIEkgd291bGQgc2F5Cj4gwqAjZWxz
ZSAvKiAhSEFWRV9ZQUpMX1YyICovCj4gYW5kCj4gwqAjZW5kaWYgLyogIUhBVkVfWUFKTF9WMiAq
Lwo+Cj4gKEJ1dCBJIHdvdWxkIGhhdmUgY29tbWl0dGVkIGl0IHdpdGhvdXQgdGhvc2UgY2hhbmdl
cyBpZiBpdCBoYWQgYXBwbGllZAo+IGNsZWFubHkuKQoKSSd2ZSBzZW50IGFuZCB1cGRhdGVkIHZl
cnNpb24sIHNvcnJ5IGZvciB0aGUgZGVsYXksIG15IGxvY2FsIG1lcmN1cmlhbApyZXBybyB3YXMg
dG90YWxseSBib3JrZWQsIGRvbid0IGtub3cgd2h5Li4uCgo+IFRoYW5rcywKPiBJYW4uCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Jan 28 11:10:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 11:10:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr6Aa-0005od-Gy; Sat, 28 Jan 2012 11:10: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 1Rr6AY-0005oR-Bb
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 11:10:06 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1327748998!12379523!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31295 invoked from network); 28 Jan 2012 11:10:00 -0000
Received: from mail-pz0-f43.google.com (HELO mail-pz0-f43.google.com)
	(209.85.210.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 11:10:00 -0000
Received: by dajs34 with SMTP id s34so17531969daj.30
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 03:09: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=pObm4c0tpfrSYIgH5UPob0i07r5jM96I9FTN2PZ8Kmw=;
	b=eDVjqEwA6h+OtuC2CeEi34bKcs5SxEtnNpoNp7Jdh2p6I2xZN0enpjJTlXRlw0FDVy
	3C1SMXEHRGdJvCC0iwiNQe85o2lWYKQZ6WvlgmNtzTINsLNvkE4fcxvFtrMelJoCQ8Qw
	XP2JiwY2AsS9N8nHvHu2Cw1XXpOweT/tfQreU=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr22902819pbc.5.1327748998024; Sat,
	28 Jan 2012 03:09:58 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Sat, 28 Jan 2012 03:09:57 -0800 (PST)
In-Reply-To: <20258.63094.694795.399684@mariner.uk.xensource.com>
References: <a1986ef30b7dab4f60fe.1326606964@alpine.localdomain>
	<20258.63094.694795.399684@mariner.uk.xensource.com>
Date: Sat, 28 Jan 2012 12:09:57 +0100
X-Google-Sender-Auth: lCI6-zSphhpWVGfVo32zA1U8GPY
Message-ID: <CAPLaKK4+uv7HC2ACjjnG+t_9+nQOahdX=gKwc+VtD1AOg1AyLw@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 v3] 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

MjAxMi8xLzI3IElhbiBKYWNrc29uIDxJYW4uSmFja3NvbkBldS5jaXRyaXguY29tPjoKPiBSb2dl
ciBQYXUgTW9ubmUgd3JpdGVzICgiW1hlbi1kZXZlbF0gW1BBVENIIHYzXSBsaWJ4bDogYWRkIHN1
cHBvcnQgZm9yIHlhamwgMi54Iik6Cj4+IGxpYnhsOiBhZGQgc3VwcG9ydCBmb3IgeWFqbCAyLngK
Pj4KPj4gVGhpcyBwYXRjaCBhZGRzIHN1cHBvcnQgZm9yIHlhamwgdmVyc2lvbnMgMi54LCB3aGls
ZSByZXRhaW5pbmcgMS54Cj4+IGNvbXBhdGliaWxpdHkuIEFsbCB0aGUgbmVlZGVkIGlmZGVmcyBj
YW4gYmUgZm91bmQgaW4gbGlieGxfanNvbi5oLgo+Cj4gVGhhbmtzLiDCoEknbSBhZnJhaWQgdGhp
cyBuZWVkcyBhIHJlZnJlc2g6Cj4KPiDCoHBhdGNoaW5nIGZpbGUgdG9vbHMvbGlieGwvbGlieGxf
anNvbi5oCj4gwqBIdW5rICMxIEZBSUxFRCBhdCAxNi4KPiDCoDEgb3V0IG9mIDEgaHVuayBGQUlM
RUQgLS0gc2F2aW5nIHJlamVjdHMgdG8gZmlsZSB0b29scy9saWJ4bC9saWJ4bF9qc29uLmgucmVq
Cj4KPiBBbHNvLCB3aGlsZSB5b3UncmUgYXQgaXQ6Cj4+ICtzdGF0aWMgaW5saW5lIHlhamxfZ2Vu
IGxpYnhsX195YWpsX2dlbl9hbGxvYyhjb25zdCB5YWpsX2FsbG9jX2Z1bmNzICphbGxvY0Z1bmNz
KQo+PiArewo+PiArIMKgIMKgcmV0dXJuIHlhamxfZ2VuX2FsbG9jKGFsbG9jRnVuY3MpOwo+PiAr
fQo+PiArI2Vsc2UKPgo+IEEgY291cGxlIG9mIGJsYW5rIGxpbmVzIGFyb3VuZCB0aGlzICNpZnMg
YW5kICNlbHNlcyBtaWdodCBiZSBuaWNlLgo+IEFuZCBhbHNvIEkgd291bGQgc2F5Cj4gwqAjZWxz
ZSAvKiAhSEFWRV9ZQUpMX1YyICovCj4gYW5kCj4gwqAjZW5kaWYgLyogIUhBVkVfWUFKTF9WMiAq
Lwo+Cj4gKEJ1dCBJIHdvdWxkIGhhdmUgY29tbWl0dGVkIGl0IHdpdGhvdXQgdGhvc2UgY2hhbmdl
cyBpZiBpdCBoYWQgYXBwbGllZAo+IGNsZWFubHkuKQoKSSd2ZSBzZW50IGFuZCB1cGRhdGVkIHZl
cnNpb24sIHNvcnJ5IGZvciB0aGUgZGVsYXksIG15IGxvY2FsIG1lcmN1cmlhbApyZXBybyB3YXMg
dG90YWxseSBib3JrZWQsIGRvbid0IGtub3cgd2h5Li4uCgo+IFRoYW5rcywKPiBJYW4uCgpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2ZWwgbWFp
bGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW5zb3VyY2UuY29tCmh0dHA6Ly9saXN0cy54ZW5z
b3VyY2UuY29tL3hlbi1kZXZlbAo=

From xen-devel-bounces@lists.xensource.com Sat Jan 28 13:53:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 13:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr8iH-0007ag-Bg; Sat, 28 Jan 2012 13:53:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rr8iF-0007ab-VY
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 13:53:04 +0000
Received: from [85.158.138.51:63782] by server-4.bemta-3.messagelabs.com id
	0A/92-32238-FBDF32F4; Sat, 28 Jan 2012 13:53:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327758782!11056123!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24679 invoked from network); 28 Jan 2012 13:53:02 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 13:53:02 -0000
Received: by wgbdt11 with SMTP id dt11so2601832wgb.24
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 05:53:02 -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=YVlKHER/fhLrk1b+uXjyjOoM07mGY5aJWeBfrkfldfQ=;
	b=mrnT9g1X3ksP9uLicchCkDV5L1rgaOTURMu3TE7WZ69OHrT8Yf9vh/WtoOeDXFJCYg
	0ni9sdOZsoX79dado+K8oqvu5dSS06g4wiQpHIs7K8e1V9aR9GiQUHv3qeO8prsQFkGT
	JxxaWvB5xWJub076reM6c+di4a1A/gWNFjMfA=
Received: by 10.180.108.232 with SMTP id hn8mr17295106wib.16.1327758782239;
	Sat, 28 Jan 2012 05:53:02 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fv6sm33169158wib.8.2012.01.28.05.52.59
	(version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 05:53:00 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 28 Jan 2012 13:52:55 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CB49AE37.38808%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 13/24] mini-os: fix list.h include guard name
Thread-Index: AczdxCKOddBCnvqEdku4zpuwmd5shg==
In-Reply-To: <1327669569.26983.178.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/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:06, "Ian Campbell" <Ian.Campbell@citrix.com> wrote> On Thu,
2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:

> mini-os: use BSD sys/queue.h instead of Linux list.h
> 
...
> As well as the obvious ABI changes there are a few API updates
> associated with the change:
> 
>   - struct rw_semaphore.wait_list is unused
>   - remove_waiter needs to take the wait_queue_head
> 
> The latter requires a qemu update which I will post separately. Please
> apply first and update QEMU_TAG as appropriate.
> 
> I sprinkled some extra-emacs local variables around the files I edited
> which didn't have them.
> 
> I think this should be backported to the stable branches since
> external users of mini-os may have been mislead into thinking they
> could safely link mini-os against GPL-incompatible code.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

Best applied by Ian Jackson, as it needs synchronising with a change in the
linked qemu repo.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 13:53:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 13:53:56 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr8iH-0007ag-Bg; Sat, 28 Jan 2012 13:53:05 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1Rr8iF-0007ab-VY
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 13:53:04 +0000
Received: from [85.158.138.51:63782] by server-4.bemta-3.messagelabs.com id
	0A/92-32238-FBDF32F4; Sat, 28 Jan 2012 13:53:03 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327758782!11056123!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24679 invoked from network); 28 Jan 2012 13:53:02 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-9.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 13:53:02 -0000
Received: by wgbdt11 with SMTP id dt11so2601832wgb.24
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 05:53:02 -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=YVlKHER/fhLrk1b+uXjyjOoM07mGY5aJWeBfrkfldfQ=;
	b=mrnT9g1X3ksP9uLicchCkDV5L1rgaOTURMu3TE7WZ69OHrT8Yf9vh/WtoOeDXFJCYg
	0ni9sdOZsoX79dado+K8oqvu5dSS06g4wiQpHIs7K8e1V9aR9GiQUHv3qeO8prsQFkGT
	JxxaWvB5xWJub076reM6c+di4a1A/gWNFjMfA=
Received: by 10.180.108.232 with SMTP id hn8mr17295106wib.16.1327758782239;
	Sat, 28 Jan 2012 05:53:02 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id fv6sm33169158wib.8.2012.01.28.05.52.59
	(version=SSLv3 cipher=OTHER); Sat, 28 Jan 2012 05:53:00 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Sat, 28 Jan 2012 13:52:55 +0000
From: Keir Fraser <keir@xen.org>
To: Ian Campbell <Ian.Campbell@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Message-ID: <CB49AE37.38808%keir@xen.org>
Thread-Topic: [Xen-devel] [PATCH 13/24] mini-os: fix list.h include guard name
Thread-Index: AczdxCKOddBCnvqEdku4zpuwmd5shg==
In-Reply-To: <1327669569.26983.178.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/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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/01/2012 13:06, "Ian Campbell" <Ian.Campbell@citrix.com> wrote> On Thu,
2012-01-26 at 19:45 +0000, Daniel De Graaf wrote:

> mini-os: use BSD sys/queue.h instead of Linux list.h
> 
...
> As well as the obvious ABI changes there are a few API updates
> associated with the change:
> 
>   - struct rw_semaphore.wait_list is unused
>   - remove_waiter needs to take the wait_queue_head
> 
> The latter requires a qemu update which I will post separately. Please
> apply first and update QEMU_TAG as appropriate.
> 
> I sprinkled some extra-emacs local variables around the files I edited
> which didn't have them.
> 
> I think this should be backported to the stable branches since
> external users of mini-os may have been mislead into thinking they
> could safely link mini-os against GPL-incompatible code.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

Best applied by Ian Jackson, as it needs synchronising with a change in the
linked qemu repo.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 13:55:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 13: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 1Rr8jc-0007ds-Qq; Sat, 28 Jan 2012 13:54:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rr8jb-0007de-7T
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 13:54:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327758860!3005507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25378 invoked from network); 28 Jan 2012 13:54:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 13:54:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,585,1320624000"; d="scan'208";a="10345765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 13:54: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, 28 Jan 2012 13:54:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rr8jT-00040E-Tm;
	Sat, 28 Jan 2012 13:54:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rr8jT-00088n-TC;
	Sat, 28 Jan 2012 13:54:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11669-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 13:54:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11669: 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 11669 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11669/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-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-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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 13:55:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 13: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 1Rr8jc-0007ds-Qq; Sat, 28 Jan 2012 13:54:28 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rr8jb-0007de-7T
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 13:54:27 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327758860!3005507!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25378 invoked from network); 28 Jan 2012 13:54:21 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 13:54:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,585,1320624000"; d="scan'208";a="10345765"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 13:54: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, 28 Jan 2012 13:54:20 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1Rr8jT-00040E-Tm;
	Sat, 28 Jan 2012 13:54:19 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rr8jT-00088n-TC;
	Sat, 28 Jan 2012 13:54:19 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11669-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 13:54:19 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11669: 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 11669 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11669/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2    7 debian-install            fail REGR. vs. 10764

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2            fail blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-amd64-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-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-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   fail    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 14:51:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 14:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr9c7-0008RH-BP; Sat, 28 Jan 2012 14:50:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rr9c6-0008RA-7B
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 14:50:46 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327762237!12126322!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3213 invoked from network); 28 Jan 2012 14:50:39 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jan 2012 14:50:39 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0SEoFkc018373;
	Sat, 28 Jan 2012 09:50:15 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 28 Jan 2012 09:50:03 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: Aczbi5pS4UQEljXgRDKydrkry+FyIQANK/MAAFlvJWAAKWoZ4A==
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
	<EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
From: <djmagee@mageenet.net>
To: <djmagee@mageenet.net>, "James Harper" <james.harper@bendigoit.com.au>,
	<lta@akr.fm>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] GPLPV and 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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of djmagee@mageenet.net
> Sent: Friday, January 27, 2012 2:03 PM
> To: James Harper; lta@akr.fm
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] GPLPV and pci passthrough
> 
> I checked, and no devices are sharing IRQs.  I'll try the
> windows2003/ndis5 drivers and see if that makes a difference.  Of
> course, the base image for my win7 vms seems to have gotten corrupted,
> so I'll have to build a new one.

Oops, sorry about the top post...

I tried the Win2003 build and it works like a charm, and has native
performance across my gbit network in at least one direction.

> 
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of James Harper
> > Sent: Wednesday, January 25, 2012 7:23 PM
> > To: djmagee@mageenet.net; lta@akr.fm
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] GPLPV and pci passthrough
> >
> > >
> > > James,
> > > 	At least one other person (Lta, included in this message) and I
> > have
> > > had problems using passthrough pci devices and your GPLPV drivers
> at
> > the
> > > same time.  My symptoms are that SMB connections are totally
> > unreliable
> > > (however, downloading over http seems to work well enough).
> > > For example, if I start a video or audio file, playing from the
> > network, it will
> > > play the first few seconds fine, then the connection drops out.
> > > I can confirm that the problems don't exist when not passing
> through
> > any
> > > devices.
> > >
> > > 	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU
> > with
> > > an ATI 4770, USB controller, and ICE1712 based pci sound card
> passed
> > > through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.
> > >
> > > 	I tried the -debug drivers, and I see a ton of output in qemu
> > log,
> > > however, all that output seems to be at initialization.  I do not
> see
> > any
> > > additional output from your drivers after boot, including when I'm
> > > experiencing problems.
> > >
> > > 	I took a quick look at tcpdump output and it does seem the guest
> > is
> > > ACKing the packets as they come in, so my first guess is that
> they're
> > getting
> > > lost somewhere between the driver and the OS network stack.
> > >
> > > 	I've never set up a build environment for these drivers so I
> > haven't
> > > tried adding any extra debug output.  Have you looked into the (or
> a
> > similar)
> > > problem before, or have a more verbose debug copy of the net
driver
> > you've
> > > used to diagnose similar problems before?
> > >
> > > 	I guess the real question is, do you have any idea where we
> > should
> > > start looking?
> > >
> >
> > I'd be first looking at interrupt sharing. Maybe GPLPV doesn't like
> > sharing interrupts with anything?
> >
> > Have a look in device manager and set the view as "Resources by
type"
> > and see if anything is sharing an interrupt with the "Xen PCI Device
> > Driver".
> >
> > James
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@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 Jan 28 14:51:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 14:51:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rr9c7-0008RH-BP; Sat, 28 Jan 2012 14:50:47 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rr9c6-0008RA-7B
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 14:50:46 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-9.tower-182.messagelabs.com!1327762237!12126322!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3213 invoked from network); 28 Jan 2012 14:50:39 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-9.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 28 Jan 2012 14:50:39 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0SEoFkc018373;
	Sat, 28 Jan 2012 09:50:15 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 28 Jan 2012 09:50:03 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: Aczbi5pS4UQEljXgRDKydrkry+FyIQANK/MAAFlvJWAAKWoZ4A==
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
	<EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
From: <djmagee@mageenet.net>
To: <djmagee@mageenet.net>, "James Harper" <james.harper@bendigoit.com.au>,
	<lta@akr.fm>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] GPLPV and 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

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of djmagee@mageenet.net
> Sent: Friday, January 27, 2012 2:03 PM
> To: James Harper; lta@akr.fm
> Cc: xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] GPLPV and pci passthrough
> 
> I checked, and no devices are sharing IRQs.  I'll try the
> windows2003/ndis5 drivers and see if that makes a difference.  Of
> course, the base image for my win7 vms seems to have gotten corrupted,
> so I'll have to build a new one.

Oops, sorry about the top post...

I tried the Win2003 build and it works like a charm, and has native
performance across my gbit network in at least one direction.

> 
> > -----Original Message-----
> > From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> > bounces@lists.xensource.com] On Behalf Of James Harper
> > Sent: Wednesday, January 25, 2012 7:23 PM
> > To: djmagee@mageenet.net; lta@akr.fm
> > Cc: xen-devel@lists.xensource.com
> > Subject: Re: [Xen-devel] GPLPV and pci passthrough
> >
> > >
> > > James,
> > > 	At least one other person (Lta, included in this message) and I
> > have
> > > had problems using passthrough pci devices and your GPLPV drivers
> at
> > the
> > > same time.  My symptoms are that SMB connections are totally
> > unreliable
> > > (however, downloading over http seems to work well enough).
> > > For example, if I start a video or audio file, playing from the
> > network, it will
> > > play the first few seconds fine, then the connection drops out.
> > > I can confirm that the problems don't exist when not passing
> through
> > any
> > > devices.
> > >
> > > 	I'm using xen-unstable c/s 24465, 3.2.1 dom0, win 7 64bit domU
> > with
> > > an ATI 4770, USB controller, and ICE1712 based pci sound card
> passed
> > > through.  I used the gplpv_Vista2008x64_0.11.0.308.msi drivers.
> > >
> > > 	I tried the -debug drivers, and I see a ton of output in qemu
> > log,
> > > however, all that output seems to be at initialization.  I do not
> see
> > any
> > > additional output from your drivers after boot, including when I'm
> > > experiencing problems.
> > >
> > > 	I took a quick look at tcpdump output and it does seem the guest
> > is
> > > ACKing the packets as they come in, so my first guess is that
> they're
> > getting
> > > lost somewhere between the driver and the OS network stack.
> > >
> > > 	I've never set up a build environment for these drivers so I
> > haven't
> > > tried adding any extra debug output.  Have you looked into the (or
> a
> > similar)
> > > problem before, or have a more verbose debug copy of the net
driver
> > you've
> > > used to diagnose similar problems before?
> > >
> > > 	I guess the real question is, do you have any idea where we
> > should
> > > start looking?
> > >
> >
> > I'd be first looking at interrupt sharing. Maybe GPLPV doesn't like
> > sharing interrupts with anything?
> >
> > Have a look in device manager and set the view as "Resources by
type"
> > and see if anything is sharing an interrupt with the "Xen PCI Device
> > Driver".
> >
> > James
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@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 Jan 28 17:52:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 17:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrCRR-0002Ov-Ei; Sat, 28 Jan 2012 17:51:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <Stefan.Kuhne@gmx.net>) id 1RrCRP-0002Om-Pt
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 17:51:56 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327773109!12760537!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAyMTY4NDU=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6418 invoked from network); 28 Jan 2012 17:51:49 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-12.tower-182.messagelabs.com with SMTP;
	28 Jan 2012 17:51:49 -0000
Received: (qmail invoked by alias); 28 Jan 2012 17:51:48 -0000
Received: from xdsl-78-34-140-174.netcologne.de (EHLO Earth.access.denied)
	[78.34.140.174]
	by mail.gmx.net (mp027) with SMTP; 28 Jan 2012 18:51:48 +0100
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX1/ys/d/I1DyawwE2PYj1BHmNhb+/AM6Ei2yFF8eXi
	d2e/JryXLSincv
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>) id 1RrCUB-0000tt-82
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 18:54:47 +0100
Message-ID: <4F243591.4020305@access.denied>
Date: Sat, 28 Jan 2012 18:51:13 +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" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.4
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] compile 2.6.32 and WiKi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2092122555534471404=="
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)
--===============2092122555534471404==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig0A1606A7619061835179B691"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0A1606A7619061835179B691
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hello,

I'll compile a 2.6.32 kernel from xen git.
I follow: http://wiki.xen.org/wiki/Compiling_Kernel_2.6.32

But i get:

git checkout: updating paths is incompatible with switching branches/forc=
ing
Did you intend to checkout 'origin/xen/stable-2.6.32.x' which can not be
resolved as commit?

Any ideas?

Regards,
Stefan Kuhne


--------------enig0A1606A7619061835179B691
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/

iQEcBAEBAgAGBQJPJDWUAAoJEFLNPgL3IBVXOMAH/211QcScJXlB8Hzh7Q00lfWN
lkDEYnadnn0B3cddUvv0Y5otrpdmuhXBYgKRBNlWFyqx1imTqcEMIFG5JSUXvjc+
nREP8+rccPaaR4aqW/9WwUN86D647/vPnPjKrNvrwNkYtlWrpWIG7YBmCU8VhtIa
K5QsaNoYOQF+SBQZbe3uRBFOR4DEqXMpgRFKlIWYcN80yxwy3oLsaViY8LDlSpCq
EViROZqXTvBT6oWK9dhBI84PByXNwNtWHuXbcySjDvVQYjOKNtfjQhdE8VoYSqQ4
ezwIIkxgP1cnxHaKRzvOptd/XAMnBS5fDMV1dXXaIH4nta0s+N1bN1hCJE6dZ5I=
=DKC9
-----END PGP SIGNATURE-----

--------------enig0A1606A7619061835179B691--


--===============2092122555534471404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2092122555534471404==--


From xen-devel-bounces@lists.xensource.com Sat Jan 28 17:52:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 17:52:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrCRR-0002Ov-Ei; Sat, 28 Jan 2012 17:51:57 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <Stefan.Kuhne@gmx.net>) id 1RrCRP-0002Om-Pt
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 17:51:56 +0000
X-Env-Sender: Stefan.Kuhne@gmx.net
X-Msg-Ref: server-12.tower-182.messagelabs.com!1327773109!12760537!1
X-Originating-IP: [213.165.64.23]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjEzLjE2NS42NC4yMyA9PiAyMTY4NDU=\n,
	ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6418 invoked from network); 28 Jan 2012 17:51:49 -0000
Received: from mailout-de.gmx.net (HELO mailout-de.gmx.net) (213.165.64.23)
	by server-12.tower-182.messagelabs.com with SMTP;
	28 Jan 2012 17:51:49 -0000
Received: (qmail invoked by alias); 28 Jan 2012 17:51:48 -0000
Received: from xdsl-78-34-140-174.netcologne.de (EHLO Earth.access.denied)
	[78.34.140.174]
	by mail.gmx.net (mp027) with SMTP; 28 Jan 2012 18:51:48 +0100
X-Authenticated: #6997022
X-Provags-ID: V01U2FsdGVkX1/ys/d/I1DyawwE2PYj1BHmNhb+/AM6Ei2yFF8eXi
	d2e/JryXLSincv
Received: from blackbox.access.denied ([192.168.200.212])
	by Earth.access.denied with esmtpa (Exim 4.77)
	(envelope-from <bloebl@access.denied>) id 1RrCUB-0000tt-82
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 18:54:47 +0100
Message-ID: <4F243591.4020305@access.denied>
Date: Sat, 28 Jan 2012 18:51:13 +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" <xen-devel@lists.xensource.com>
X-Enigmail-Version: 1.3.4
X-Y-GMX-Trusted: 0
Subject: [Xen-devel] compile 2.6.32 and WiKi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2092122555534471404=="
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)
--===============2092122555534471404==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig0A1606A7619061835179B691"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0A1606A7619061835179B691
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hello,

I'll compile a 2.6.32 kernel from xen git.
I follow: http://wiki.xen.org/wiki/Compiling_Kernel_2.6.32

But i get:

git checkout: updating paths is incompatible with switching branches/forc=
ing
Did you intend to checkout 'origin/xen/stable-2.6.32.x' which can not be
resolved as commit?

Any ideas?

Regards,
Stefan Kuhne


--------------enig0A1606A7619061835179B691
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/

iQEcBAEBAgAGBQJPJDWUAAoJEFLNPgL3IBVXOMAH/211QcScJXlB8Hzh7Q00lfWN
lkDEYnadnn0B3cddUvv0Y5otrpdmuhXBYgKRBNlWFyqx1imTqcEMIFG5JSUXvjc+
nREP8+rccPaaR4aqW/9WwUN86D647/vPnPjKrNvrwNkYtlWrpWIG7YBmCU8VhtIa
K5QsaNoYOQF+SBQZbe3uRBFOR4DEqXMpgRFKlIWYcN80yxwy3oLsaViY8LDlSpCq
EViROZqXTvBT6oWK9dhBI84PByXNwNtWHuXbcySjDvVQYjOKNtfjQhdE8VoYSqQ4
ezwIIkxgP1cnxHaKRzvOptd/XAMnBS5fDMV1dXXaIH4nta0s+N1bN1hCJE6dZ5I=
=DKC9
-----END PGP SIGNATURE-----

--------------enig0A1606A7619061835179B691--


--===============2092122555534471404==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2092122555534471404==--


From xen-devel-bounces@lists.xensource.com Sat Jan 28 18:20:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 18: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 1RrCsP-0002lw-Rj; Sat, 28 Jan 2012 18:19:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1RrCsN-0002lP-Qf
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 18:19:48 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327774762!50621905!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29195 invoked from network); 28 Jan 2012 18:19:23 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 18:19:23 -0000
Received: by iaeh11 with SMTP id h11so22925999iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 10:19:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=LKQuGmPYVW6O+489REzw4vPwZ1elmfebOBfpUb7KDus=;
	b=n53xqtVf1QwY0YX9eP+FcsBpfGofg+mNU96vtMBNbLq3P7IQTzGemKsH0N/FIjYY3J
	zlJrkyvlrrxUISsnEg0g/cBKBqRYbpPDFwrc/5rxLVqXjZKDy/SePuv3GgPnMieFq6O3
	D+kPQcczITLmftaUaYKzaoaT/w4glIUNdodEQ=
Received: by 10.42.147.72 with SMTP id m8mr9097336icv.56.1327774784123; Sat,
	28 Jan 2012 10:19:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.6.18 with HTTP; Sat, 28 Jan 2012 10:19:23 -0800 (PST)
In-Reply-To: <20120117161208.GA21545@phenom.dumpdata.com>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
	<20120117161208.GA21545@phenom.dumpdata.com>
From: Todd Deshane <todd.deshane@xen.org>
Date: Sat, 28 Jan 2012 13:19:23 -0500
X-Google-Sender-Auth: u4Bbv-Dn-hvevIIOfG4TKLZI5RY
Message-ID: <CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel mailing list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
>> Hi,
>>
>> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
>> static on the Dom0 system. (I can PCI passthrough the audio card to a
>> DomU and that works). Native sound works fine.
>>
>> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
>> UTC 2012 i686 i686 i386 GNU/Linux
>
> Did you try 64-bit dom0?

64bit Dom0 works perfectly.

> What happens if you do not use 'dom0_mem=' arguments?

I didn't specify these.

> Does your machine have IOMMU?

Yes.

> What is the hypervisor output?

xl dmesg

(XEN) Xen version 4.1.2 (Ubuntu 4.1.2-2.2)
(jenkins@debian32.uk.xensource.com) (gcc version 4.6.1 (Ubuntu/Linaro
4.6.1-9ubuntu3) ) Mon Dec 12 22:34:13 UTC 2011
(XEN) Bootloader: GRUB 1.99-14ubuntu2
(XEN) Command line: placeholder
(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 - 000000000009e800 (usable)
(XEN)  000000000009e800 - 00000000000a0000 (reserved)
(XEN)  00000000000d2000 - 00000000000d4000 (reserved)
(XEN)  00000000000dc000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bb27c000 (usable)
(XEN)  00000000bb27c000 - 00000000bb282000 (reserved)
(XEN)  00000000bb282000 - 00000000bb35f000 (usable)
(XEN)  00000000bb35f000 - 00000000bb371000 (reserved)
(XEN)  00000000bb371000 - 00000000bb3f2000 (ACPI NVS)
(XEN)  00000000bb3f2000 - 00000000bb40f000 (reserved)
(XEN)  00000000bb40f000 - 00000000bb46f000 (usable)
(XEN)  00000000bb46f000 - 00000000bb668000 (reserved)
(XEN)  00000000bb668000 - 00000000bb6e8000 (ACPI NVS)
(XEN)  00000000bb6e8000 - 00000000bb70f000 (reserved)
(XEN)  00000000bb70f000 - 00000000bb717000 (usable)
(XEN)  00000000bb717000 - 00000000bb71f000 (reserved)
(XEN)  00000000bb71f000 - 00000000bb76b000 (usable)
(XEN)  00000000bb76b000 - 00000000bb777000 (ACPI NVS)
(XEN)  00000000bb777000 - 00000000bb77a000 (ACPI data)
(XEN)  00000000bb77a000 - 00000000bb781000 (ACPI NVS)
(XEN)  00000000bb781000 - 00000000bb782000 (ACPI data)
(XEN)  00000000bb782000 - 00000000bb78b000 (ACPI NVS)
(XEN)  00000000bb78b000 - 00000000bb78c000 (ACPI data)
(XEN)  00000000bb78c000 - 00000000bb79f000 (ACPI NVS)
(XEN)  00000000bb79f000 - 00000000bb7ff000 (ACPI data)
(XEN)  00000000bb7ff000 - 00000000bb800000 (usable)
(XEN)  00000000bb800000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000feaff000 - 00000000feb00000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fed00000 - 00000000fed00400 (reserved)
(XEN)  00000000fed1c000 - 00000000fed90000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000138000000 (usable)
(XEN) ACPI: RSDP 000F68F0, 0024 (r2 LENOVO)
(XEN) ACPI: XSDT BB7F0970, 009C (r1 LENOVO TP-6Q        1150  LTP        0)
(XEN) ACPI: FACP BB7F0B00, 00F4 (r4 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: DSDT BB7F0E6B, DD26 (r1 LENOVO TP-6Q        1150 MSFT  3000001)
(XEN) ACPI: FACS BB6E7000, 0040
(XEN) ACPI: SSDT BB7F0CB4, 01B7 (r1 LENOVO TP-6Q        1150 MSFT  3000001)
(XEN) ACPI: ECDT BB7FEB91, 0052 (r1 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: APIC BB7FEBE3, 0084 (r1 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: MCFG BB7FEC9F, 003C (r1 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: HPET BB7FECDB, 0038 (r1 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: ASF! BB7FEDBE, 00A4 (r16 LENOVO TP-6Q        1150 PTL         1)
(XEN) ACPI: SLIC BB7FEE62, 0176 (r1 LENOVO TP-6Q        1150  LTP        0)
(XEN) ACPI: BOOT BB7FEFD8, 0028 (r1 LENOVO TP-6Q        1150  LTP        1)
(XEN) ACPI: SSDT BB6E590A, 085B (r1 LENOVO TP-6Q        1150 INTL 20050513)
(XEN) ACPI: TCPA BB78B000, 0032 (r2    PTL  CRESTLN  6040000          5A52)
(XEN) ACPI: DMAR BB781000, 00B8 (r1 INTEL  CP_DALE         1 INTL        1)
(XEN) ACPI: SSDT BB779000, 09F1 (r1  PmRef    CpuPm     3000 INTL 20050513)
(XEN) ACPI: SSDT BB778000, 0259 (r1  PmRef  Cpu0Tst     3000 INTL 20050513)
(XEN) ACPI: SSDT BB777000, 049F (r1  PmRef    ApTst     3000 INTL 20050513)
(XEN) System RAM: 3891MB (3985072kB)
(XEN) Domain heap initialised
(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 1, 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 2527.076 MHz processor.
(XEN) Initing memory sharing.
(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 14.318MHz HPET
(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: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1c83000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000012c000000->0000000130000000 (923979 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000135f8c000->0000000137fffe00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c1c83000
(XEN)  Init. ramdisk: 00000000c1c83000->00000000c3cf6e00
(XEN)  Phys-Mach map: 00000000c3cf7000->00000000c40956fc
(XEN)  Start info:    00000000c4096000->00000000c40964b4
(XEN)  Page tables:   00000000c4097000->00000000c40bf000
(XEN)  Boot stack:    00000000c40bf000->00000000c40c0000
(XEN)  TOTAL:         00000000c0000000->00000000c4400000
(XEN)  ENTRY ADDRESS: 00000000c1871000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) [VT-D]iommu.c:711: BIOS did not enable IGD for VT properly.
Disabling IGD VT-d engine.
(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 220kB init memory.
(XEN) mm.c:907:d0 Error getting mfn 2c09e (pfn c4319) from L1 entry
000000002c09e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2c09f (pfn c431a) from L1 entry
000000002c09f023 for l1e_owner=0, pg_owner=0
(XEN) ../physdev.c:155: dom0: wrong map_pirq type 3
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 18:20:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 18: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 1RrCsP-0002lw-Rj; Sat, 28 Jan 2012 18:19:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <todd.deshane.xen@gmail.com>) id 1RrCsN-0002lP-Qf
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 18:19:48 +0000
X-Env-Sender: todd.deshane.xen@gmail.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327774762!50621905!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29195 invoked from network); 28 Jan 2012 18:19:23 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 18:19:23 -0000
Received: by iaeh11 with SMTP id h11so22925999iae.30
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 10:19:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:from:date
	:x-google-sender-auth:message-id:subject:to:cc:content-type;
	bh=LKQuGmPYVW6O+489REzw4vPwZ1elmfebOBfpUb7KDus=;
	b=n53xqtVf1QwY0YX9eP+FcsBpfGofg+mNU96vtMBNbLq3P7IQTzGemKsH0N/FIjYY3J
	zlJrkyvlrrxUISsnEg0g/cBKBqRYbpPDFwrc/5rxLVqXjZKDy/SePuv3GgPnMieFq6O3
	D+kPQcczITLmftaUaYKzaoaT/w4glIUNdodEQ=
Received: by 10.42.147.72 with SMTP id m8mr9097336icv.56.1327774784123; Sat,
	28 Jan 2012 10:19:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.42.6.18 with HTTP; Sat, 28 Jan 2012 10:19:23 -0800 (PST)
In-Reply-To: <20120117161208.GA21545@phenom.dumpdata.com>
References: <CAC-_gzBaG9H2k6j1ihq=o6XgMYe-a_B4-wjAmoQ5TY-FRqVRwQ@mail.gmail.com>
	<20120117161208.GA21545@phenom.dumpdata.com>
From: Todd Deshane <todd.deshane@xen.org>
Date: Sat, 28 Jan 2012 13:19:23 -0500
X-Google-Sender-Auth: u4Bbv-Dn-hvevIIOfG4TKLZI5RY
Message-ID: <CAMrPLWLeV0uDX7xA4BGAEd7K0aj9uH-Y5gyjuat7fPhVV=wRhw@mail.gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel mailing list <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] Sound not working properly on Xen Dom0,
	but works on native
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 17, 2012 at 11:12 AM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Sun, Jan 15, 2012 at 07:12:52PM -0500, Todd Deshane wrote:
>> Hi,
>>
>> I'm doing some testing on Ubuntu 12.04 Alpha. All sounds comes out as
>> static on the Dom0 system. (I can PCI passthrough the audio card to a
>> DomU and that works). Native sound works fine.
>>
>> Linux kronos 3.2.0-8-generic-pae #15-Ubuntu SMP Wed Jan 11 15:34:57
>> UTC 2012 i686 i686 i386 GNU/Linux
>
> Did you try 64-bit dom0?

64bit Dom0 works perfectly.

> What happens if you do not use 'dom0_mem=' arguments?

I didn't specify these.

> Does your machine have IOMMU?

Yes.

> What is the hypervisor output?

xl dmesg

(XEN) Xen version 4.1.2 (Ubuntu 4.1.2-2.2)
(jenkins@debian32.uk.xensource.com) (gcc version 4.6.1 (Ubuntu/Linaro
4.6.1-9ubuntu3) ) Mon Dec 12 22:34:13 UTC 2011
(XEN) Bootloader: GRUB 1.99-14ubuntu2
(XEN) Command line: placeholder
(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 - 000000000009e800 (usable)
(XEN)  000000000009e800 - 00000000000a0000 (reserved)
(XEN)  00000000000d2000 - 00000000000d4000 (reserved)
(XEN)  00000000000dc000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000bb27c000 (usable)
(XEN)  00000000bb27c000 - 00000000bb282000 (reserved)
(XEN)  00000000bb282000 - 00000000bb35f000 (usable)
(XEN)  00000000bb35f000 - 00000000bb371000 (reserved)
(XEN)  00000000bb371000 - 00000000bb3f2000 (ACPI NVS)
(XEN)  00000000bb3f2000 - 00000000bb40f000 (reserved)
(XEN)  00000000bb40f000 - 00000000bb46f000 (usable)
(XEN)  00000000bb46f000 - 00000000bb668000 (reserved)
(XEN)  00000000bb668000 - 00000000bb6e8000 (ACPI NVS)
(XEN)  00000000bb6e8000 - 00000000bb70f000 (reserved)
(XEN)  00000000bb70f000 - 00000000bb717000 (usable)
(XEN)  00000000bb717000 - 00000000bb71f000 (reserved)
(XEN)  00000000bb71f000 - 00000000bb76b000 (usable)
(XEN)  00000000bb76b000 - 00000000bb777000 (ACPI NVS)
(XEN)  00000000bb777000 - 00000000bb77a000 (ACPI data)
(XEN)  00000000bb77a000 - 00000000bb781000 (ACPI NVS)
(XEN)  00000000bb781000 - 00000000bb782000 (ACPI data)
(XEN)  00000000bb782000 - 00000000bb78b000 (ACPI NVS)
(XEN)  00000000bb78b000 - 00000000bb78c000 (ACPI data)
(XEN)  00000000bb78c000 - 00000000bb79f000 (ACPI NVS)
(XEN)  00000000bb79f000 - 00000000bb7ff000 (ACPI data)
(XEN)  00000000bb7ff000 - 00000000bb800000 (usable)
(XEN)  00000000bb800000 - 00000000c0000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000feaff000 - 00000000feb00000 (reserved)
(XEN)  00000000fec00000 - 00000000fec10000 (reserved)
(XEN)  00000000fed00000 - 00000000fed00400 (reserved)
(XEN)  00000000fed1c000 - 00000000fed90000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff000000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000138000000 (usable)
(XEN) ACPI: RSDP 000F68F0, 0024 (r2 LENOVO)
(XEN) ACPI: XSDT BB7F0970, 009C (r1 LENOVO TP-6Q        1150  LTP        0)
(XEN) ACPI: FACP BB7F0B00, 00F4 (r4 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: DSDT BB7F0E6B, DD26 (r1 LENOVO TP-6Q        1150 MSFT  3000001)
(XEN) ACPI: FACS BB6E7000, 0040
(XEN) ACPI: SSDT BB7F0CB4, 01B7 (r1 LENOVO TP-6Q        1150 MSFT  3000001)
(XEN) ACPI: ECDT BB7FEB91, 0052 (r1 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: APIC BB7FEBE3, 0084 (r1 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: MCFG BB7FEC9F, 003C (r1 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: HPET BB7FECDB, 0038 (r1 LENOVO TP-6Q        1150 LNVO        1)
(XEN) ACPI: ASF! BB7FEDBE, 00A4 (r16 LENOVO TP-6Q        1150 PTL         1)
(XEN) ACPI: SLIC BB7FEE62, 0176 (r1 LENOVO TP-6Q        1150  LTP        0)
(XEN) ACPI: BOOT BB7FEFD8, 0028 (r1 LENOVO TP-6Q        1150  LTP        1)
(XEN) ACPI: SSDT BB6E590A, 085B (r1 LENOVO TP-6Q        1150 INTL 20050513)
(XEN) ACPI: TCPA BB78B000, 0032 (r2    PTL  CRESTLN  6040000          5A52)
(XEN) ACPI: DMAR BB781000, 00B8 (r1 INTEL  CP_DALE         1 INTL        1)
(XEN) ACPI: SSDT BB779000, 09F1 (r1  PmRef    CpuPm     3000 INTL 20050513)
(XEN) ACPI: SSDT BB778000, 0259 (r1  PmRef  Cpu0Tst     3000 INTL 20050513)
(XEN) ACPI: SSDT BB777000, 049F (r1  PmRef    ApTst     3000 INTL 20050513)
(XEN) System RAM: 3891MB (3985072kB)
(XEN) Domain heap initialised
(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 1, 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 2527.076 MHz processor.
(XEN) Initing memory sharing.
(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 14.318MHz HPET
(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: 64-bit, lsb, compat32
(XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x1c83000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN)  Dom0 alloc.:   000000012c000000->0000000130000000 (923979 pages
to be allocated)
(XEN)  Init. ramdisk: 0000000135f8c000->0000000137fffe00
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN)  Loaded kernel: 00000000c1000000->00000000c1c83000
(XEN)  Init. ramdisk: 00000000c1c83000->00000000c3cf6e00
(XEN)  Phys-Mach map: 00000000c3cf7000->00000000c40956fc
(XEN)  Start info:    00000000c4096000->00000000c40964b4
(XEN)  Page tables:   00000000c4097000->00000000c40bf000
(XEN)  Boot stack:    00000000c40bf000->00000000c40c0000
(XEN)  TOTAL:         00000000c0000000->00000000c4400000
(XEN)  ENTRY ADDRESS: 00000000c1871000
(XEN) Dom0 has maximum 4 VCPUs
(XEN) [VT-D]iommu.c:711: BIOS did not enable IGD for VT properly.
Disabling IGD VT-d engine.
(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 220kB init memory.
(XEN) mm.c:907:d0 Error getting mfn 2c09e (pfn c4319) from L1 entry
000000002c09e023 for l1e_owner=0, pg_owner=0
(XEN) mm.c:907:d0 Error getting mfn 2c09f (pfn c431a) from L1 entry
000000002c09f023 for l1e_owner=0, pg_owner=0
(XEN) ../physdev.c:155: dom0: wrong map_pirq type 3
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.
(XEN) printk: 1 messages suppressed.
(XEN) traps.c:2432:d0 Domain attempted WRMSR 00000000000001ac from
0x0000000000a800c8 to 0x0000000080a880c8.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 19:25:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 19:25:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrDtI-0003fb-4H; Sat, 28 Jan 2012 19:24: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 1RrDtG-0003fT-M0
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 19:24:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327778680!12913135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27735 invoked from network); 28 Jan 2012 19:24: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;
	28 Jan 2012 19:24:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,585,1320624000"; d="scan'208";a="10347806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 19:24:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 28 Jan 2012 19:24:39 +0000
Message-ID: <1327778679.28964.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Kuhne <stefan.kuhne@gmx.net>
Date: Sat, 28 Jan 2012 19:24:39 +0000
In-Reply-To: <4F243591.4020305@access.denied>
References: <4F243591.4020305@access.denied>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Subject: Re: [Xen-devel] compile 2.6.32 and WiKi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-01-28 at 17:51 +0000, Stefan Kuhne wrote:
> Hello,
> 
> I'll compile a 2.6.32 kernel from xen git.
> I follow: http://wiki.xen.org/wiki/Compiling_Kernel_2.6.32
> 
> But i get:
> 
> git checkout: updating paths is incompatible with switching branches/forcing
> Did you intend to checkout 'origin/xen/stable-2.6.32.x' which can not be
> resolved as commit?
> 
> Any ideas?

Is there some reason you want to use 2.6.32 in particular? Although it
is still a longterm maintained kernel upstream I think this is due to
end fairly shortly. If possible you should switch to one of the more
recent upstream kernels e.g. v3.2. You can get these direct from
kernel.org.

If you really think you need 2.6.32.x then you can either:

Use the xen/next-2.6.32 branch of that tree instead. This is the
pre-testing branch which would become xen/stable-2.6.32.x after
automated testing. There is no development on 2.6.32 any more -- only
merges of upstream longterm 2.6.32.y -- so I think that would be
reasonably safe.

-or-

Use git://xenbits.xen.org/linux-pvops.git branch master which is what
would normally be at xen.git xen/stable-2.6.32.x i.e. it's is the tested
branch. This is actually where the tester pushes to, the kernel.org tree
used to be automatically mirrored but that stopped working after the
kernel.org compromise.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 19:25:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 19:25:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrDtI-0003fb-4H; Sat, 28 Jan 2012 19:24: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 1RrDtG-0003fT-M0
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 19:24:46 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327778680!12913135!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27735 invoked from network); 28 Jan 2012 19:24: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;
	28 Jan 2012 19:24:40 -0000
X-IronPort-AV: E=Sophos;i="4.71,585,1320624000"; d="scan'208";a="10347806"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 19:24:40 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sat, 28 Jan 2012 19:24:39 +0000
Message-ID: <1327778679.28964.6.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefan Kuhne <stefan.kuhne@gmx.net>
Date: Sat, 28 Jan 2012 19:24:39 +0000
In-Reply-To: <4F243591.4020305@access.denied>
References: <4F243591.4020305@access.denied>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>
Subject: Re: [Xen-devel] compile 2.6.32 and WiKi
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sat, 2012-01-28 at 17:51 +0000, Stefan Kuhne wrote:
> Hello,
> 
> I'll compile a 2.6.32 kernel from xen git.
> I follow: http://wiki.xen.org/wiki/Compiling_Kernel_2.6.32
> 
> But i get:
> 
> git checkout: updating paths is incompatible with switching branches/forcing
> Did you intend to checkout 'origin/xen/stable-2.6.32.x' which can not be
> resolved as commit?
> 
> Any ideas?

Is there some reason you want to use 2.6.32 in particular? Although it
is still a longterm maintained kernel upstream I think this is due to
end fairly shortly. If possible you should switch to one of the more
recent upstream kernels e.g. v3.2. You can get these direct from
kernel.org.

If you really think you need 2.6.32.x then you can either:

Use the xen/next-2.6.32 branch of that tree instead. This is the
pre-testing branch which would become xen/stable-2.6.32.x after
automated testing. There is no development on 2.6.32 any more -- only
merges of upstream longterm 2.6.32.y -- so I think that would be
reasonably safe.

-or-

Use git://xenbits.xen.org/linux-pvops.git branch master which is what
would normally be at xen.git xen/stable-2.6.32.x i.e. it's is the tested
branch. This is actually where the tester pushes to, the kernel.org tree
used to be automatically mirrored but that stopped working after the
kernel.org compromise.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 19:59:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 19:59:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrEQK-000433-3g; Sat, 28 Jan 2012 19:58:56 +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 1RrEQI-00042y-NN
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 19:58:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327780728!12857772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15820 invoked from network); 28 Jan 2012 19:58:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 19:58:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,585,1320624000"; d="scan'208";a="10347972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 19:58:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 28 Jan 2012 19:58:48 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RrEQB-0005zw-R9;
	Sat, 28 Jan 2012 19:58:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrEQB-0007lv-Qj;
	Sat, 28 Jan 2012 19:58:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11696-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 19:58:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11696: 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 11696 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11696/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl          18 leak-check/check          fail REGR. vs. 11643
 test-i386-i386-xl            18 leak-check/check fail in 11660 REGR. vs. 11643
 test-amd64-i386-xl           18 leak-check/check fail in 11660 REGR. vs. 11643
 test-amd64-i386-xl-multivcpu 18 leak-check/check fail in 11660 REGR. vs. 11643

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl             3 host-install(3)           broken pass in 11660
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 11660
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 11660
 test-i386-i386-pv             3 host-install(3)           broken pass in 11660
 test-amd64-i386-xl            3 host-install(3)           broken pass in 11660
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 11660
 test-amd64-i386-xend-winxpsp3  3 host-install(3)          broken pass in 11660
 test-i386-i386-xl-win         3 host-install(3)           broken pass in 11660
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 11660
 test-i386-i386-win            3 host-install(3)           broken pass in 11660
 test-i386-i386-xl-winxpsp3    3 host-install(3)           broken pass in 11660
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 11660

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl-sedf-pin 18 leak-check/check         fail blocked in 11643
 test-i386-i386-win           14 guest-start.2         fail in 11660 like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-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-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-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11660 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11660 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11660 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11660 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11660 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11660 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11660 never pass

version targeted for testing:
 xen                  54000bca7a6a
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  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                                          fail    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 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                                 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                           broken  
 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                                        broken  
 test-amd64-i386-xend-winxpsp3                                broken  
 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 384 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 Jan 28 19:59:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 19:59:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrEQK-000433-3g; Sat, 28 Jan 2012 19:58:56 +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 1RrEQI-00042y-NN
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 19:58:55 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327780728!12857772!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15820 invoked from network); 28 Jan 2012 19:58:48 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	28 Jan 2012 19:58:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,585,1320624000"; d="scan'208";a="10347972"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 19:58:48 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Sat, 28 Jan 2012 19:58:48 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RrEQB-0005zw-R9;
	Sat, 28 Jan 2012 19:58:47 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrEQB-0007lv-Qj;
	Sat, 28 Jan 2012 19:58:47 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11696-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 19:58:47 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11696: 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 11696 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11696/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-credit2   18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl          18 leak-check/check          fail REGR. vs. 11643
 test-i386-i386-xl            18 leak-check/check fail in 11660 REGR. vs. 11643
 test-amd64-i386-xl           18 leak-check/check fail in 11660 REGR. vs. 11643
 test-amd64-i386-xl-multivcpu 18 leak-check/check fail in 11660 REGR. vs. 11643

Tests which are failing intermittently (not blocking):
 test-i386-i386-xl             3 host-install(3)           broken pass in 11660
 test-amd64-i386-rhel6hvm-intel  3 host-install(3)         broken pass in 11660
 test-amd64-i386-rhel6hvm-amd  3 host-install(3)           broken pass in 11660
 test-i386-i386-pv             3 host-install(3)           broken pass in 11660
 test-amd64-i386-xl            3 host-install(3)           broken pass in 11660
 test-amd64-i386-xl-multivcpu  3 host-install(3)           broken pass in 11660
 test-amd64-i386-xend-winxpsp3  3 host-install(3)          broken pass in 11660
 test-i386-i386-xl-win         3 host-install(3)           broken pass in 11660
 test-amd64-i386-xl-win7-amd64  3 host-install(3)          broken pass in 11660
 test-i386-i386-win            3 host-install(3)           broken pass in 11660
 test-i386-i386-xl-winxpsp3    3 host-install(3)           broken pass in 11660
 test-amd64-i386-xl-winxpsp3-vcpus1  3 host-install(3)     broken pass in 11660

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf     18 leak-check/check          fail REGR. vs. 11643
 test-amd64-amd64-xl-sedf-pin 18 leak-check/check         fail blocked in 11643
 test-i386-i386-win           14 guest-start.2         fail in 11660 like 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-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-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-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11660 never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11660 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11660 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11660 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11660 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11660 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11660 never pass

version targeted for testing:
 xen                  54000bca7a6a
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Dario Faggioli <dario.faggioli@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  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                                          fail    
 test-amd64-i386-xl                                           broken  
 test-i386-i386-xl                                            broken  
 test-amd64-i386-rhel6hvm-amd                                 broken  
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                broken  
 test-amd64-i386-xl-credit2                                   fail    
 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                                 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                           broken  
 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                                        broken  
 test-amd64-i386-xend-winxpsp3                                broken  
 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 384 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 Jan 28 22:50:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 22:50:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrH5D-0005gA-0u; Sat, 28 Jan 2012 22:49:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RrH5C-0005g5-3c
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 22:49:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327790898!54429930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1388 invoked from network); 28 Jan 2012 22:48:18 -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;
	28 Jan 2012 22:48:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,586,1320624000"; d="scan'208";a="10348367"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 22:49: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; Sat, 28 Jan 2012 22:49:11 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RrH54-0006w4-O4;
	Sat, 28 Jan 2012 22:49:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrH54-0007MH-LS;
	Sat, 28 Jan 2012 22:49:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11708-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 22:49:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11708: regressions - trouble:
	blocked/broken/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 11708 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11708/

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 in 11669 REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)           broken pass in 11669
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 11669
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 11669
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 11669
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 11669
 test-amd64-amd64-xl-win       3 host-install(3)           broken pass in 11669
 build-i386-pvops              2 host-install(2)           broken pass in 11669
 test-amd64-amd64-win          3 host-install(3)           broken pass in 11669
 build-i386                    2 host-install(2)           broken pass in 11669
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)        broken pass in 11669
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)         broken pass in 11669
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 11669
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 11669

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2   fail in 11669 blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11669 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11669 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11669 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11669 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11669 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11669 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11669 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11669 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11669 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11669 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 22:50:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 22:50:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrH5D-0005gA-0u; Sat, 28 Jan 2012 22:49:19 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RrH5C-0005g5-3c
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 22:49:18 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327790898!54429930!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgyMw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1388 invoked from network); 28 Jan 2012 22:48:18 -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;
	28 Jan 2012 22:48:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,586,1320624000"; d="scan'208";a="10348367"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	28 Jan 2012 22:49: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; Sat, 28 Jan 2012 22:49:11 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RrH54-0006w4-O4;
	Sat, 28 Jan 2012 22:49:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrH54-0007MH-LS;
	Sat, 28 Jan 2012 22:49:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11708-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sat, 28 Jan 2012 22:49:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11708: regressions - trouble:
	blocked/broken/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 11708 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11708/

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 in 11669 REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)           broken pass in 11669
 test-amd64-amd64-xl           3 host-install(3)           broken pass in 11669
 test-amd64-amd64-xl-sedf      3 host-install(3)           broken pass in 11669
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)           broken pass in 11669
 test-amd64-amd64-pv           3 host-install(3)           broken pass in 11669
 test-amd64-amd64-xl-win       3 host-install(3)           broken pass in 11669
 build-i386-pvops              2 host-install(2)           broken pass in 11669
 test-amd64-amd64-win          3 host-install(3)           broken pass in 11669
 build-i386                    2 host-install(2)           broken pass in 11669
 test-amd64-amd64-xl-pcipt-intel  3 host-install(3)        broken pass in 11669
 test-amd64-amd64-xl-win7-amd64  3 host-install(3)         broken pass in 11669
 test-amd64-amd64-pair         3 host-install/src_host(3)  broken pass in 11669
 test-amd64-amd64-pair         4 host-install/dst_host(4)  broken pass in 11669

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2   fail in 11669 blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11669 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11669 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11669 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11669 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11669 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11669 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11669 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11669 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11669 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11669 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   broken  
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          broken  
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-amd64-xl-win7-amd64                               broken  
 test-amd64-i386-xl-win7-amd64                                blocked 
 test-amd64-i386-xl-credit2                                   blocked 
 test-amd64-amd64-xl-pcipt-intel                              broken  
 test-amd64-i386-rhel6hvm-intel                               blocked 
 test-amd64-i386-xl-multivcpu                                 blocked 
 test-amd64-amd64-pair                                        broken  
 test-amd64-i386-pair                                         blocked 
 test-i386-i386-pair                                          blocked 
 test-amd64-amd64-xl-sedf-pin                                 broken  
 test-amd64-amd64-pv                                          broken  
 test-amd64-i386-pv                                           blocked 
 test-i386-i386-pv                                            blocked 
 test-amd64-amd64-xl-sedf                                     broken  
 test-amd64-i386-win-vcpus1                                   blocked 
 test-amd64-i386-xl-win-vcpus1                                blocked 
 test-amd64-i386-xl-winxpsp3-vcpus1                           blocked 
 test-amd64-amd64-win                                         broken  
 test-amd64-i386-win                                          blocked 
 test-i386-i386-win                                           blocked 
 test-amd64-amd64-xl-win                                      broken  
 test-i386-i386-xl-win                                        blocked 
 test-amd64-i386-xend-winxpsp3                                blocked 
 test-amd64-amd64-xl-winxpsp3                                 broken  
 test-i386-i386-xl-winxpsp3                                   blocked 


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 23:56:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 23:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrI78-0006fX-Tl; Sat, 28 Jan 2012 23:55:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1RrI77-0006fS-QL
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 23:55:22 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327794798!61590791!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3129 invoked from network); 28 Jan 2012 23:53:18 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-8.tower-27.messagelabs.com with SMTP;
	28 Jan 2012 23:53:18 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 57B4F1F880A0
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 18:55:15 -0500 (EST)
Received: (qmail 19722 invoked by uid 108); 28 Jan 2012 18:55:13 -0500
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.25.186.85)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 28 Jan 2012 18:55:13 -0500
Received: by imp.flyn.org (Postfix, from userid 1101)
	id D3993812133; Sat, 28 Jan 2012 17:54:49 -0600 (CST)
Date: Sat, 28 Jan 2012 17:54:49 -0600
From: "W. Michael Petullo" <mike@flyn.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120128235449.GA22022@imp.flyn.org>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] OProfile patch for Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have ported Anil's passive profile-capable OProfile patch to Linux
3.2. I have be able to hobble this patch along to new kernel versions, but
it is in need of additional work if it is to be submitted upstream. Please
see:

http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.2-xen-passive-oprofile.patch.gz

With this patch applied to Linux 3.2, I can perform passive
profiling of an unprivileged Xen domain.

-- 
Mike

:wq

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sat Jan 28 23:56:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sat, 28 Jan 2012 23:56:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrI78-0006fX-Tl; Sat, 28 Jan 2012 23:55:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <mike@flyn.org>) id 1RrI77-0006fS-QL
	for xen-devel@lists.xensource.com; Sat, 28 Jan 2012 23:55:22 +0000
X-Env-Sender: mike@flyn.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327794798!61590791!1
X-Originating-IP: [72.251.202.114]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3129 invoked from network); 28 Jan 2012 23:53:18 -0000
Received: from cust-smtp1.lga6.us.voxel.net (HELO
	cust-smtp1.lga6.us.voxel.net) (72.251.202.114)
	by server-8.tower-27.messagelabs.com with SMTP;
	28 Jan 2012 23:53:18 -0000
Received: from vhost2.lga6.us.voxel.net (vhost2.lga6.us.voxel.net
	[72.251.193.170])
	by cust-smtp1.lga6.us.voxel.net (Postfix) with ESMTP id 57B4F1F880A0
	for <xen-devel@lists.xensource.com>;
	Sat, 28 Jan 2012 18:55:15 -0500 (EST)
Received: (qmail 19722 invoked by uid 108); 28 Jan 2012 18:55:13 -0500
Received: from unknown (HELO imp.flyn.org) (mike@flyn.org@99.25.186.85)
	by vhost2.lga6.us.voxel.net with ESMTPSA; 28 Jan 2012 18:55:13 -0500
Received: by imp.flyn.org (Postfix, from userid 1101)
	id D3993812133; Sat, 28 Jan 2012 17:54:49 -0600 (CST)
Date: Sat, 28 Jan 2012 17:54:49 -0600
From: "W. Michael Petullo" <mike@flyn.org>
To: xen-devel@lists.xensource.com
Message-ID: <20120128235449.GA22022@imp.flyn.org>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Xen-devel] OProfile patch for Linux 3.2
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I have ported Anil's passive profile-capable OProfile patch to Linux
3.2. I have be able to hobble this patch along to new kernel versions, but
it is in need of additional work if it is to be submitted upstream. Please
see:

http://www.flyn.org/patches/linux-xen-passive-oprofile/linux-3.2-xen-passive-oprofile.patch.gz

With this patch applied to Linux 3.2, I can perform passive
profiling of an unprivileged Xen domain.

-- 
Mike

:wq

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 02:38:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 02:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrKdr-000442-Ti; Sun, 29 Jan 2012 02:37:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RrKdq-00043x-6I
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 02:37:18 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327804627!12515031!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22736 invoked from network); 29 Jan 2012 02:37:11 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Jan 2012 02:37:11 -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 1RrKdR-0006HV-06; Sun, 29 Jan 2012 13:36:53 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 29 Jan 2012 13:36:53 +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;
	Sun, 29 Jan 2012 13:36:52 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "djmagee@mageenet.net" <djmagee@mageenet.net>, "lta@akr.fm" <lta@akr.fm>
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: AQHM3SZo9LC4iZ0d50mifymi8U9J8ZYhJYeAgAFx17A=
Date: Sun, 29 Jan 2012 02:36:51 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
	<EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
	<EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Jan 2012 02:36:53.0161 (UTC)
	FILETIME=[DC3AE190:01CCDE2E]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV and 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 checked, and no devices are sharing IRQs.  I'll try the
> > windows2003/ndis5 drivers and see if that makes a difference.  Of
> > course, the base image for my win7 vms seems to have gotten corrupted,
> > so I'll have to build a new one.
> 
> Oops, sorry about the top post...
> 
> I tried the Win2003 build and it works like a charm, and has native
> performance across my gbit network in at least one direction.
> 

Right... so if I understand the problem:

. NDIS5 driver works fine under Windows 7 with PCI passthrough
. NDIS6 driver works fine under Windows 7 with no PCI passthrough
. NDIS6 driver does not work correctly with PCI passthrough

Can you now try turning off all offloads in the DomU and see if starts working at some point?

I'm at a loss to explain how this could happen though.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 02:38:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 02:38:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrKdr-000442-Ti; Sun, 29 Jan 2012 02:37:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <james.harper@bendigoit.com.au>) id 1RrKdq-00043x-6I
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 02:37:18 +0000
X-Env-Sender: james.harper@bendigoit.com.au
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327804627!12515031!1
X-Originating-IP: [203.16.224.4]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22736 invoked from network); 29 Jan 2012 02:37:11 -0000
Received: from smtp1.bendigoit.com.au (HELO smtp1.bendigoit.com.au)
	(203.16.224.4)
	by server-9.tower-216.messagelabs.com with AES256-SHA encrypted SMTP;
	29 Jan 2012 02:37:11 -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 1RrKdR-0006HV-06; Sun, 29 Jan 2012 13:36:53 +1100
Received: from BITCOM1.int.sbss.com.au ([192.168.200.237]) by
	mail.bendigoit.com.au with Microsoft SMTPSVC(6.0.3790.4675); 
	Sun, 29 Jan 2012 13:36:53 +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;
	Sun, 29 Jan 2012 13:36:52 +1100
From: James Harper <james.harper@bendigoit.com.au>
To: "djmagee@mageenet.net" <djmagee@mageenet.net>, "lta@akr.fm" <lta@akr.fm>
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: AQHM3SZo9LC4iZ0d50mifymi8U9J8ZYhJYeAgAFx17A=
Date: Sun, 29 Jan 2012 02:36:51 +0000
Message-ID: <6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
	<EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
	<EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
In-Reply-To: <EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Jan 2012 02:36:53.0161 (UTC)
	FILETIME=[DC3AE190:01CCDE2E]
X-Really-From-Bendigo-IT: magichashvalue
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] GPLPV and 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 checked, and no devices are sharing IRQs.  I'll try the
> > windows2003/ndis5 drivers and see if that makes a difference.  Of
> > course, the base image for my win7 vms seems to have gotten corrupted,
> > so I'll have to build a new one.
> 
> Oops, sorry about the top post...
> 
> I tried the Win2003 build and it works like a charm, and has native
> performance across my gbit network in at least one direction.
> 

Right... so if I understand the problem:

. NDIS5 driver works fine under Windows 7 with PCI passthrough
. NDIS6 driver works fine under Windows 7 with no PCI passthrough
. NDIS6 driver does not work correctly with PCI passthrough

Can you now try turning off all offloads in the DomU and see if starts working at some point?

I'm at a loss to explain how this could happen though.

James

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 09:09:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 09:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrQkX-0008If-UR; Sun, 29 Jan 2012 09:08:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <j.farzin@yahoo.com>) id 1RrQkW-0008Ia-HC
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 09:08:36 +0000
X-Env-Sender: j.farzin@yahoo.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327828109!12527446!1
X-Originating-IP: [72.30.238.203]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6940 invoked from network); 29 Jan 2012 09:08:30 -0000
Received: from nm37-vm3.bullet.mail.bf1.yahoo.com (HELO
	nm37-vm3.bullet.mail.bf1.yahoo.com) (72.30.238.203)
	by server-15.tower-216.messagelabs.com with SMTP;
	29 Jan 2012 09:08:30 -0000
Received: from [98.139.212.146] by nm37.bullet.mail.bf1.yahoo.com with NNFMP;
	29 Jan 2012 09:08:29 -0000
Received: from [98.139.212.204] by tm3.bullet.mail.bf1.yahoo.com with NNFMP;
	29 Jan 2012 09:08:29 -0000
Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP;
	29 Jan 2012 09:08:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 545357.15566.bm@omp1013.mail.bf1.yahoo.com
Received: (qmail 70514 invoked by uid 60001); 29 Jan 2012 09:07:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1327828079; bh=MXaYxVGz/mYryxgJbC0lJk4AVg5o4GieL6ty2T8VMlo=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=rBFgquzAO++0Fqy9faOB6VHKernBUfxeyVRsz+/GcuOfgzSQszs8uGA8nH2AKPN5ySRigFnXnfN8w6Z7uNvXkdHVRmMuBJ/tCIUvbLGPHUMmPjfLPhmHTbImPz0CTraltxOUg7NrWQcXIKJNAIdV5HL7d0dJPsko1Bk945DY3iw=
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=2OxYQ7nF32KyoEUlxw4qRH6/Xl6I5pcoN/E5Fxeh1ALiV//FAa9yepIbfIvgDaAPr/JPQkoBg5eMGSds8DG4+rAEiwwUEmUVJPMOtQiXHp7ylRn1WQtSge6Sg5P9GvpNKW08F2BwTP0FPLQO8TA6RNOqLQJtQgVOLhn7lwMUIwo=;
X-YMail-OSG: n7uRPekVM1k0aD0Do10vYSeEUYyCG7akBrDYUB7q2oFx60r
	xNRRWh1maZ0mjHkr7MYlgfDcv9I63DkXyv6WmfUZsem.KcyuX9dor8XW58kB
	Ikwu17PCOIHjeOXQqKfoJpP.Ff8nH8ug5XBk.ItPPXTC2.Jzl5SSSbxb2Ve.
	iCZjqg1cElWjhs41AV_nExV9CmmLwNG80fTWN82U_9n8JwFlhVfVKBdabRG6
	Vbp4W_G12g8q9xaNAbWYOlh23Gtlr9bno38CVWXGtrYinPWuMelUWQBNMqm5
	LcfE8bXemdD1cihc3DREhVou3R9i4qnt6sGSe9L5q5_wMKEiMUz2dSIFj1nu
	PNSbQupDbxRIc_XHQHX7QO_qRBF12Y4U.uMjvF6yHNC7quN3imRExl8tVKcB
	idACLKtr7BnWd0MTAilEADCLxBoOoTu8YOFNOXWgA40H0TrI.FSfQo0sQT7y
	xKJocB5EyGCi0re1LT7VDRq1QJLE-
Received: from [212.120.210.39] by web161503.mail.bf1.yahoo.com via HTTP;
	Sun, 29 Jan 2012 01:07:59 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.331537
Message-ID: <1327828079.48123.YahooMailClassic@web161503.mail.bf1.yahoo.com>
Date: Sun, 29 Jan 2012 01:07:59 -0800 (PST)
From: Javanshir Farzin <j.farzin@yahoo.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] improve precopy approach
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4065443199779501297=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4065443199779501297==
Content-Type: multipart/alternative; boundary="1524547028-16583284-1327828079=:48123"

--1524547028-16583284-1327828079=:48123
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello
I am the master student in computer science. My thesis subject in the maste=
r is improving the pre-copy approach at virtual machine live migration. I w=
ant to=20
develop this section of XEN. How can I cooperate at Xen Development Project=
s? I want to access some document about XENapproach in memory transfer duri=
ng live migration.
I survey xc_domain_save.c file to understand about some XEN functions, but =
I want to learn more about this. Please help me to achieve more details abo=
ut XEN.


--1524547028-16583284-1327828079=:48123
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><font size=3D"3">Hello<br>I am the master stu=
dent in computer science. My thesis subject in the master is improving the =
pre-copy approach at virtual machine live migration. I want to <br>develop =
this section of XEN. How can I cooperate at Xen Development Projects? I wan=
t to access some document about XENapproach in memory transfer during live =
migration.<br>I survey xc_domain_save.c file to understand about some XEN f=
unctions, but I want to learn more about this. Please help me to achieve mo=
re details about XEN.<br></font><br></td></tr></table>
--1524547028-16583284-1327828079=:48123--


--===============4065443199779501297==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4065443199779501297==--


From xen-devel-bounces@lists.xensource.com Sun Jan 29 09:09:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 09:09:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrQkX-0008If-UR; Sun, 29 Jan 2012 09:08:37 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <j.farzin@yahoo.com>) id 1RrQkW-0008Ia-HC
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 09:08:36 +0000
X-Env-Sender: j.farzin@yahoo.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327828109!12527446!1
X-Originating-IP: [72.30.238.203]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	ML_RADAR_SPEW_LINKS_12,ML_RADAR_SPEW_LINKS_14,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6940 invoked from network); 29 Jan 2012 09:08:30 -0000
Received: from nm37-vm3.bullet.mail.bf1.yahoo.com (HELO
	nm37-vm3.bullet.mail.bf1.yahoo.com) (72.30.238.203)
	by server-15.tower-216.messagelabs.com with SMTP;
	29 Jan 2012 09:08:30 -0000
Received: from [98.139.212.146] by nm37.bullet.mail.bf1.yahoo.com with NNFMP;
	29 Jan 2012 09:08:29 -0000
Received: from [98.139.212.204] by tm3.bullet.mail.bf1.yahoo.com with NNFMP;
	29 Jan 2012 09:08:29 -0000
Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP;
	29 Jan 2012 09:08:29 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 545357.15566.bm@omp1013.mail.bf1.yahoo.com
Received: (qmail 70514 invoked by uid 60001); 29 Jan 2012 09:07:59 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024;
	t=1327828079; bh=MXaYxVGz/mYryxgJbC0lJk4AVg5o4GieL6ty2T8VMlo=;
	h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type;
	b=rBFgquzAO++0Fqy9faOB6VHKernBUfxeyVRsz+/GcuOfgzSQszs8uGA8nH2AKPN5ySRigFnXnfN8w6Z7uNvXkdHVRmMuBJ/tCIUvbLGPHUMmPjfLPhmHTbImPz0CTraltxOUg7NrWQcXIKJNAIdV5HL7d0dJPsko1Bk945DY3iw=
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=2OxYQ7nF32KyoEUlxw4qRH6/Xl6I5pcoN/E5Fxeh1ALiV//FAa9yepIbfIvgDaAPr/JPQkoBg5eMGSds8DG4+rAEiwwUEmUVJPMOtQiXHp7ylRn1WQtSge6Sg5P9GvpNKW08F2BwTP0FPLQO8TA6RNOqLQJtQgVOLhn7lwMUIwo=;
X-YMail-OSG: n7uRPekVM1k0aD0Do10vYSeEUYyCG7akBrDYUB7q2oFx60r
	xNRRWh1maZ0mjHkr7MYlgfDcv9I63DkXyv6WmfUZsem.KcyuX9dor8XW58kB
	Ikwu17PCOIHjeOXQqKfoJpP.Ff8nH8ug5XBk.ItPPXTC2.Jzl5SSSbxb2Ve.
	iCZjqg1cElWjhs41AV_nExV9CmmLwNG80fTWN82U_9n8JwFlhVfVKBdabRG6
	Vbp4W_G12g8q9xaNAbWYOlh23Gtlr9bno38CVWXGtrYinPWuMelUWQBNMqm5
	LcfE8bXemdD1cihc3DREhVou3R9i4qnt6sGSe9L5q5_wMKEiMUz2dSIFj1nu
	PNSbQupDbxRIc_XHQHX7QO_qRBF12Y4U.uMjvF6yHNC7quN3imRExl8tVKcB
	idACLKtr7BnWd0MTAilEADCLxBoOoTu8YOFNOXWgA40H0TrI.FSfQo0sQT7y
	xKJocB5EyGCi0re1LT7VDRq1QJLE-
Received: from [212.120.210.39] by web161503.mail.bf1.yahoo.com via HTTP;
	Sun, 29 Jan 2012 01:07:59 PST
X-Mailer: YahooMailClassic/15.0.4 YahooMailWebService/0.8.116.331537
Message-ID: <1327828079.48123.YahooMailClassic@web161503.mail.bf1.yahoo.com>
Date: Sun, 29 Jan 2012 01:07:59 -0800 (PST)
From: Javanshir Farzin <j.farzin@yahoo.com>
To: xen-devel@lists.xensource.com
MIME-Version: 1.0
Subject: [Xen-devel] improve precopy approach
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4065443199779501297=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4065443199779501297==
Content-Type: multipart/alternative; boundary="1524547028-16583284-1327828079=:48123"

--1524547028-16583284-1327828079=:48123
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello
I am the master student in computer science. My thesis subject in the maste=
r is improving the pre-copy approach at virtual machine live migration. I w=
ant to=20
develop this section of XEN. How can I cooperate at Xen Development Project=
s? I want to access some document about XENapproach in memory transfer duri=
ng live migration.
I survey xc_domain_save.c file to understand about some XEN functions, but =
I want to learn more about this. Please help me to achieve more details abo=
ut XEN.


--1524547028-16583284-1327828079=:48123
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><font size=3D"3">Hello<br>I am the master stu=
dent in computer science. My thesis subject in the master is improving the =
pre-copy approach at virtual machine live migration. I want to <br>develop =
this section of XEN. How can I cooperate at Xen Development Projects? I wan=
t to access some document about XENapproach in memory transfer during live =
migration.<br>I survey xc_domain_save.c file to understand about some XEN f=
unctions, but I want to learn more about this. Please help me to achieve mo=
re details about XEN.<br></font><br></td></tr></table>
--1524547028-16583284-1327828079=:48123--


--===============4065443199779501297==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4065443199779501297==--


From xen-devel-bounces@lists.xensource.com Sun Jan 29 11:05:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 11:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrSYS-00010H-QA; Sun, 29 Jan 2012 11:04: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 1RrSYR-000109-Hb
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 11:04:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327835048!12410385!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20509 invoked from network); 29 Jan 2012 11:04:08 -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;
	29 Jan 2012 11:04:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,587,1320624000"; d="scan'208";a="10351081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jan 2012 11:04: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; Sun, 29 Jan 2012 11:04:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RrSYJ-0002g8-Fa;
	Sun, 29 Jan 2012 11:04:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrSYJ-0008JU-FE;
	Sun, 29 Jan 2012 11:04:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11714-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Jan 2012 11:04:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11714: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11714 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11714/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 11643
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11643
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11643
 build-amd64                   2 host-install(2)         broken REGR. vs. 11643
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11643
 build-i386                    2 host-install(2)         broken REGR. vs. 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  39df93acd408
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

(No revision log; it would be 576 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 Jan 29 11:05:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 11:05:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrSYS-00010H-QA; Sun, 29 Jan 2012 11:04: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 1RrSYR-000109-Hb
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 11:04:15 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327835048!12410385!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20509 invoked from network); 29 Jan 2012 11:04:08 -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;
	29 Jan 2012 11:04:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,587,1320624000"; d="scan'208";a="10351081"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jan 2012 11:04: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; Sun, 29 Jan 2012 11:04:08 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RrSYJ-0002g8-Fa;
	Sun, 29 Jan 2012 11:04:07 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrSYJ-0008JU-FE;
	Sun, 29 Jan 2012 11:04:07 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11714-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Jan 2012 11:04:07 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11714: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11714 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11714/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 11643
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11643
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11643
 build-amd64                   2 host-install(2)         broken REGR. vs. 11643
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11643
 build-i386                    2 host-install(2)         broken REGR. vs. 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-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-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  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
 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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  39df93acd408
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

(No revision log; it would be 576 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 Jan 29 12:05:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 12:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrTUd-0001kP-Io; Sun, 29 Jan 2012 12:04:23 +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 1RrTUb-0001kI-QP
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 12:04:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327838654!12416135!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDkwNTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDkwNTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23769 invoked from network); 29 Jan 2012 12:04:15 -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; 29 Jan 2012 12:04:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327838654; l=1908;
	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=8Kd54wivGYVptuEsAcXf/qPHsyw=;
	b=Mpc/kGZVlf3Nlms+0siwTKXY9WrN3V6wa+kf2qxca3Js6OhZ+USUh800Ga1mRWxd74O
	ayUoDJqidt0ltuudwg3co/GxzIQfDjifZFaA55KPb900E7Ent8ZW3qAOmdesHy7iB8xVd
	VFXG45peSKBHVR2nD9mJOMSrUH8Y+7Uly4E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0MEDq0
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-237.pools.arcor-ip.net [88.65.94.237])
	by post.strato.de (mrclete mo52) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B04e5bo0TBQld6
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 13:04:11 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 76D9418634
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 13:04:15 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b64564ad67ebbbf5ebfceabbd0afa281d950f9a3
Message-Id: <b64564ad67ebbbf5ebfc.1327838654@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 29 Jan 2012 13:04:14 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mini-os: convert mlock macros to C 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 1327838577 -3600
# Node ID b64564ad67ebbbf5ebfceabbd0afa281d950f9a3
# Parent  34cf64e8b3f099a556b670ca96e0f3f695557a11
mini-os: convert mlock macros to C functions

mlock and munlock are implemented as macros in mini-os. Their usage
requires casting in common code.  Convert them to C syntax and provide
an empty dummy function.  Remove the now unneeded (void) cast from two
munlock calls.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 34cf64e8b3f0 -r b64564ad67eb extras/mini-os/include/posix/sys/mman.h
--- a/extras/mini-os/include/posix/sys/mman.h
+++ b/extras/mini-os/include/posix/sys/mman.h
@@ -16,7 +16,7 @@
 
 void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset) asm("mmap64");
 int munmap(void *start, size_t length);
-#define munlock(addr, len) ((void)(addr), (void)(len), 0)
-#define mlock(addr, len) ((void)(addr), (void)(len), 0)
+static inline mlock(const void *addr, size_t len) { return 0; }
+static inline munlock(const void *addr, size_t len) { return 0; }
 
 #endif /* _POSIX_SYS_MMAN_H */
diff -r 34cf64e8b3f0 -r b64564ad67eb tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -106,7 +106,7 @@ static void *linux_privcmd_alloc_hyperca
 
 static void linux_privcmd_free_hypercall_buffer(xc_interface *xch, xc_osdep_handle h, void *ptr, int npages)
 {
-    (void) munlock(ptr, npages * XC_PAGE_SIZE);
+    munlock(ptr, npages * XC_PAGE_SIZE);
     free(ptr);
 }
 
diff -r 34cf64e8b3f0 -r b64564ad67eb tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -87,7 +87,7 @@ int xc_mem_paging_load(xc_interface *xch
                                 buffer, NULL, gfn);
 
     old_errno = errno;
-    (void) munlock(buffer, XC_PAGE_SIZE);
+    munlock(buffer, XC_PAGE_SIZE);
     errno = old_errno;
 
     return rc;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 12:05:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 12:05:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrTUd-0001kP-Io; Sun, 29 Jan 2012 12:04:23 +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 1RrTUb-0001kI-QP
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 12:04:22 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327838654!12416135!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDkwNTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDkwNTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23769 invoked from network); 29 Jan 2012 12:04:15 -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; 29 Jan 2012 12:04:15 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327838654; l=1908;
	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=8Kd54wivGYVptuEsAcXf/qPHsyw=;
	b=Mpc/kGZVlf3Nlms+0siwTKXY9WrN3V6wa+kf2qxca3Js6OhZ+USUh800Ga1mRWxd74O
	ayUoDJqidt0ltuudwg3co/GxzIQfDjifZFaA55KPb900E7Ent8ZW3qAOmdesHy7iB8xVd
	VFXG45peSKBHVR2nD9mJOMSrUH8Y+7Uly4E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmztM8TOFHii0MEDq0
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-088-065-094-237.pools.arcor-ip.net [88.65.94.237])
	by post.strato.de (mrclete mo52) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id B04e5bo0TBQld6
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 13:04:11 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 76D9418634
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 13:04:15 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b64564ad67ebbbf5ebfceabbd0afa281d950f9a3
Message-Id: <b64564ad67ebbbf5ebfc.1327838654@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Sun, 29 Jan 2012 13:04:14 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] mini-os: convert mlock macros to C 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 1327838577 -3600
# Node ID b64564ad67ebbbf5ebfceabbd0afa281d950f9a3
# Parent  34cf64e8b3f099a556b670ca96e0f3f695557a11
mini-os: convert mlock macros to C functions

mlock and munlock are implemented as macros in mini-os. Their usage
requires casting in common code.  Convert them to C syntax and provide
an empty dummy function.  Remove the now unneeded (void) cast from two
munlock calls.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 34cf64e8b3f0 -r b64564ad67eb extras/mini-os/include/posix/sys/mman.h
--- a/extras/mini-os/include/posix/sys/mman.h
+++ b/extras/mini-os/include/posix/sys/mman.h
@@ -16,7 +16,7 @@
 
 void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset) asm("mmap64");
 int munmap(void *start, size_t length);
-#define munlock(addr, len) ((void)(addr), (void)(len), 0)
-#define mlock(addr, len) ((void)(addr), (void)(len), 0)
+static inline mlock(const void *addr, size_t len) { return 0; }
+static inline munlock(const void *addr, size_t len) { return 0; }
 
 #endif /* _POSIX_SYS_MMAN_H */
diff -r 34cf64e8b3f0 -r b64564ad67eb tools/libxc/xc_linux_osdep.c
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -106,7 +106,7 @@ static void *linux_privcmd_alloc_hyperca
 
 static void linux_privcmd_free_hypercall_buffer(xc_interface *xch, xc_osdep_handle h, void *ptr, int npages)
 {
-    (void) munlock(ptr, npages * XC_PAGE_SIZE);
+    munlock(ptr, npages * XC_PAGE_SIZE);
     free(ptr);
 }
 
diff -r 34cf64e8b3f0 -r b64564ad67eb tools/libxc/xc_mem_paging.c
--- a/tools/libxc/xc_mem_paging.c
+++ b/tools/libxc/xc_mem_paging.c
@@ -87,7 +87,7 @@ int xc_mem_paging_load(xc_interface *xch
                                 buffer, NULL, gfn);
 
     old_errno = errno;
-    (void) munlock(buffer, XC_PAGE_SIZE);
+    munlock(buffer, XC_PAGE_SIZE);
     errno = old_errno;
 
     return rc;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 13:55:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 13:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrVCT-0002g2-OP; Sun, 29 Jan 2012 13:53:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrVCR-0002fx-Sr
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 13:53:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327845217!12491144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgzNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23221 invoked from network); 29 Jan 2012 13:53:37 -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;
	29 Jan 2012 13:53:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,587,1320624000"; d="scan'208";a="10351701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jan 2012 13:53:37 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sun, 29 Jan 2012 13:53:36 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120127192214.GA14437@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
Date: Sun, 29 Jan 2012 13:42:41 +0000
Message-ID: <1327844561.2911.5.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2012 at 01:46:56PM +0000, Wei Liu wrote:
> > A new netback implementation which includes three major features:
> > 
> >  - Global page pool support
> >  - NAPI + kthread 1:1 model
> >  - Netback internal name changes
> > 
> > Changes in V2:
> >  - Fix minor bugs in V1
> >  - Embed pending_tx_info into page pool
> >  - Per-cpu scratch space
> >  - Notification code path clean up
> > 
> > This patch series is the foundation of furture work. So it is better
> > to get it right first. Patch 1 and 3 have the real meat.
> 
> I've been playing with these patches and couple of things
> came to my mind: 
>  - would it make sense to also register to the shrinker API? This way
>    if the host is running low on memory it can squeeze it out of the
>    pool code. Perhaps a future TODO..
>  - I like the pool code. I was thinking that perhaps (in the future)
>    it could be used by blkback as well, as it runs into "not enought
>    request structure" with the default setting. And making this dynamic
>    would be pretty sweet.

Interesting thoughts worth adding to TODO list. But I'm focusing on
multi-page ring support and split event channel at the moment, which
should help improve performance on 10G network. Hopefully I can submit
RFC patch V3 in a few days. ;-)

>  - This patch set solves the CPU banding problem I've seen with the
>    older netback. The older one  I could see X netback threads eating 80%
>    of CPU. With this one, the number is down to 13-14%.
> 
> So you can definitly stick 'Tested-by: Konrad.." on them. And definitly
> Reviewed-by on the first two - hadn't had a chance to look at the rest.
> 

Thanks for your extensive test and review.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 13:55:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 13:55:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrVCT-0002g2-OP; Sun, 29 Jan 2012 13:53:45 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrVCR-0002fx-Sr
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 13:53:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327845217!12491144!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgzNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23221 invoked from network); 29 Jan 2012 13:53:37 -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;
	29 Jan 2012 13:53:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,587,1320624000"; d="scan'208";a="10351701"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jan 2012 13:53:37 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Sun, 29 Jan 2012 13:53:36 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120127192214.GA14437@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
Date: Sun, 29 Jan 2012 13:42:41 +0000
Message-ID: <1327844561.2911.5.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 17, 2012 at 01:46:56PM +0000, Wei Liu wrote:
> > A new netback implementation which includes three major features:
> > 
> >  - Global page pool support
> >  - NAPI + kthread 1:1 model
> >  - Netback internal name changes
> > 
> > Changes in V2:
> >  - Fix minor bugs in V1
> >  - Embed pending_tx_info into page pool
> >  - Per-cpu scratch space
> >  - Notification code path clean up
> > 
> > This patch series is the foundation of furture work. So it is better
> > to get it right first. Patch 1 and 3 have the real meat.
> 
> I've been playing with these patches and couple of things
> came to my mind: 
>  - would it make sense to also register to the shrinker API? This way
>    if the host is running low on memory it can squeeze it out of the
>    pool code. Perhaps a future TODO..
>  - I like the pool code. I was thinking that perhaps (in the future)
>    it could be used by blkback as well, as it runs into "not enought
>    request structure" with the default setting. And making this dynamic
>    would be pretty sweet.

Interesting thoughts worth adding to TODO list. But I'm focusing on
multi-page ring support and split event channel at the moment, which
should help improve performance on 10G network. Hopefully I can submit
RFC patch V3 in a few days. ;-)

>  - This patch set solves the CPU banding problem I've seen with the
>    older netback. The older one  I could see X netback threads eating 80%
>    of CPU. With this one, the number is down to 13-14%.
> 
> So you can definitly stick 'Tested-by: Konrad.." on them. And definitly
> Reviewed-by on the first two - hadn't had a chance to look at the rest.
> 

Thanks for your extensive test and review.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 17:08:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 17: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 1RrYDn-0005G3-34; Sun, 29 Jan 2012 17:07:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RrYDl-0005Fy-0w
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 17:07:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327856830!13018246!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgzNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7268 invoked from network); 29 Jan 2012 17:07:11 -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;
	29 Jan 2012 17:07:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,588,1320624000"; d="scan'208";a="10352677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jan 2012 17:07: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; Sun, 29 Jan 2012 17:07:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RrYDe-0004lN-58;
	Sun, 29 Jan 2012 17:07:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrYDe-0007ny-4U;
	Sun, 29 Jan 2012 17:07:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11717-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Jan 2012 17:07:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11717: regressions - trouble:
	blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11717 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11717/

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 in 11669 REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 build-i386-pvops              2 host-install(2)           broken pass in 11669
 build-amd64-pvops             2 host-install(2)           broken pass in 11708
 build-amd64                   2 host-install(2)           broken pass in 11708
 build-i386                    2 host-install(2)           broken pass in 11669
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-pv           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-win       3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-win          3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 11708 pass in 11669

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2   fail in 11669 blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      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-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-pcipt-intel  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-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11669 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11669 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11669 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11669 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11669 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11669 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11669 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11669 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11669 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11669 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 17:08:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 17: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 1RrYDn-0005G3-34; Sun, 29 Jan 2012 17:07:19 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RrYDl-0005Fy-0w
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 17:07:17 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327856830!13018246!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTgzNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7268 invoked from network); 29 Jan 2012 17:07:11 -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;
	29 Jan 2012 17:07:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,588,1320624000"; d="scan'208";a="10352677"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jan 2012 17:07: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; Sun, 29 Jan 2012 17:07:10 +0000
Received: from [10.80.248.135] (helo=woking.xci-test.com)	by
	norwich.cam.xci-test.com with esmtp (Exim 4.72)	(envelope-from
	<ian.jackson@eu.citrix.com>)	id 1RrYDe-0004lN-58;
	Sun, 29 Jan 2012 17:07:10 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrYDe-0007ny-4U;
	Sun, 29 Jan 2012 17:07:10 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11717-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Jan 2012 17:07:10 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11717: regressions - trouble:
	blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11717 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11717/

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 in 11669 REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 build-i386-pvops              2 host-install(2)           broken pass in 11669
 build-amd64-pvops             2 host-install(2)           broken pass in 11708
 build-amd64                   2 host-install(2)           broken pass in 11708
 build-i386                    2 host-install(2)           broken pass in 11669
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-pv           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-win       3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-win          3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 11708 pass in 11669

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2   fail in 11669 blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      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-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-pcipt-intel  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-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11669 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11669 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11669 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11669 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11669 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11669 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11669 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11669 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11669 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11669 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 17:15:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 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 1RrYKt-0005OT-Vv; Sun, 29 Jan 2012 17:14:39 +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 1RrYKt-0005ON-2l
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 17:14:39 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327857216!58851322!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25079 invoked from network); 29 Jan 2012 17:13:37 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jan 2012 17:13:37 -0000
Received: by ghbf1 with SMTP id f1so46773544ghb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 09:14:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Yyg3yxiFc7yvEhhJDSx9sDZcLk3Lg7cC41OHQvd3fWI=;
	b=udAWIpRa6vVfcPhKWfJ4Fsk+VBNL/m10/JTxo87o7Kgj9Iw3rIym02j7hI42fuVnI/
	1NwNLHTPJJugppYOXjxQkAi5ABagi02YBtodkNpriAM5zQVy0Xe+pUJ7rwU/mkbLXZaY
	abzhA4hYC1iq3iujUHUmKp/MNUnW644BS1dfg=
MIME-Version: 1.0
Received: by 10.236.124.172 with SMTP id x32mr21580697yhh.19.1327857276579;
	Sun, 29 Jan 2012 09:14:36 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Sun, 29 Jan 2012 09:14:36 -0800 (PST)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
	<EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
	<EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
Date: Sun, 29 Jan 2012 09:14:36 -0800
Message-ID: <CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"djmagee@mageenet.net" <djmagee@mageenet.net>, "lta@akr.fm" <lta@akr.fm>
Subject: Re: [Xen-devel] GPLPV and 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="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, Jan 28, 2012 at 6:36 PM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> >
>> > I checked, and no devices are sharing IRQs. =A0I'll try the
>> > windows2003/ndis5 drivers and see if that makes a difference. =A0Of
>> > course, the base image for my win7 vms seems to have gotten corrupted,
>> > so I'll have to build a new one.
>>
>> Oops, sorry about the top post...
>>
>> I tried the Win2003 build and it works like a charm, and has native
>> performance across my gbit network in at least one direction.
>>
>
> Right... so if I understand the problem:
>
> . NDIS5 driver works fine under Windows 7 with PCI passthrough
> . NDIS6 driver works fine under Windows 7 with no PCI passthrough
> . NDIS6 driver does not work correctly with PCI passthrough
>
> Can you now try turning off all offloads in the DomU and see if starts wo=
rking at some point?
>
> I'm at a loss to explain how this could happen though.
>
> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

I have had weird network problems as well using the 308 drivers. For
me the 356 drivers from the hg repository do work fine, so something
between 308 and 356 fixed some network bugs. Perhaps put a test build
on the website for him to try?

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 17:15:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 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 1RrYKt-0005OT-Vv; Sun, 29 Jan 2012 17:14:39 +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 1RrYKt-0005ON-2l
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 17:14:39 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327857216!58851322!1
X-Originating-IP: [209.85.160.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25079 invoked from network); 29 Jan 2012 17:13:37 -0000
Received: from mail-gy0-f171.google.com (HELO mail-gy0-f171.google.com)
	(209.85.160.171)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jan 2012 17:13:37 -0000
Received: by ghbf1 with SMTP id f1so46773544ghb.30
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 09:14:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=Yyg3yxiFc7yvEhhJDSx9sDZcLk3Lg7cC41OHQvd3fWI=;
	b=udAWIpRa6vVfcPhKWfJ4Fsk+VBNL/m10/JTxo87o7Kgj9Iw3rIym02j7hI42fuVnI/
	1NwNLHTPJJugppYOXjxQkAi5ABagi02YBtodkNpriAM5zQVy0Xe+pUJ7rwU/mkbLXZaY
	abzhA4hYC1iq3iujUHUmKp/MNUnW644BS1dfg=
MIME-Version: 1.0
Received: by 10.236.124.172 with SMTP id x32mr21580697yhh.19.1327857276579;
	Sun, 29 Jan 2012 09:14:36 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Sun, 29 Jan 2012 09:14:36 -0800 (PST)
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
	<EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
	<EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
Date: Sun, 29 Jan 2012 09:14:36 -0800
Message-ID: <CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: James Harper <james.harper@bendigoit.com.au>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"djmagee@mageenet.net" <djmagee@mageenet.net>, "lta@akr.fm" <lta@akr.fm>
Subject: Re: [Xen-devel] GPLPV and 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="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, Jan 28, 2012 at 6:36 PM, James Harper
<james.harper@bendigoit.com.au> wrote:
>> >
>> > I checked, and no devices are sharing IRQs. =A0I'll try the
>> > windows2003/ndis5 drivers and see if that makes a difference. =A0Of
>> > course, the base image for my win7 vms seems to have gotten corrupted,
>> > so I'll have to build a new one.
>>
>> Oops, sorry about the top post...
>>
>> I tried the Win2003 build and it works like a charm, and has native
>> performance across my gbit network in at least one direction.
>>
>
> Right... so if I understand the problem:
>
> . NDIS5 driver works fine under Windows 7 with PCI passthrough
> . NDIS6 driver works fine under Windows 7 with no PCI passthrough
> . NDIS6 driver does not work correctly with PCI passthrough
>
> Can you now try turning off all offloads in the DomU and see if starts wo=
rking at some point?
>
> I'm at a loss to explain how this could happen though.
>
> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

I have had weird network problems as well using the 308 drivers. For
me the 356 drivers from the hg repository do work fine, so something
between 308 and 356 fixed some network bugs. Perhaps put a test build
on the website for him to try?

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Sun Jan 29 23:06:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 23:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrdp7-0000Tr-Qw; Sun, 29 Jan 2012 23:06:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rrdp5-0000Tj-Lg
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 23:06:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327878364!12873889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15421 invoked from network); 29 Jan 2012 23:06:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jan 2012 23:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,589,1320624000"; d="scan'208";a="10353786"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jan 2012 23: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; Sun, 29 Jan 2012 23:06: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 1Rrdow-0006jj-M8;
	Sun, 29 Jan 2012 23:06:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rrdow-00036Q-Lm;
	Sun, 29 Jan 2012 23:06:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11723-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Jan 2012 23:06:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11723: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11723 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11723/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11643
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11643
 build-amd64                   2 host-install(2)         broken REGR. vs. 11643
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11643
 build-i386                    2 host-install(2)         broken REGR. vs. 11643
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            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-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-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-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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  39df93acd408
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

(No revision log; it would be 576 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 Jan 29 23:06:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Sun, 29 Jan 2012 23:06:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrdp7-0000Tr-Qw; Sun, 29 Jan 2012 23:06:13 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rrdp5-0000Tj-Lg
	for xen-devel@lists.xensource.com; Sun, 29 Jan 2012 23:06:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327878364!12873889!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15421 invoked from network); 29 Jan 2012 23:06:04 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	29 Jan 2012 23:06:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,589,1320624000"; d="scan'208";a="10353786"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	29 Jan 2012 23: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; Sun, 29 Jan 2012 23:06: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 1Rrdow-0006jj-M8;
	Sun, 29 Jan 2012 23:06:02 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rrdow-00036Q-Lm;
	Sun, 29 Jan 2012 23:06:02 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11723-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Sun, 29 Jan 2012 23:06:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11723: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11723 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11723/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11643
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11643
 build-amd64                   2 host-install(2)         broken REGR. vs. 11643
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11643
 build-i386                    2 host-install(2)         broken REGR. vs. 11643
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            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-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-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-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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  39df93acd408
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

(No revision log; it would be 576 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 Jan 30 00:18:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 00:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrewI-0001kt-LP; Mon, 30 Jan 2012 00:17:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RrewH-0001ko-Mv
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 00:17:42 +0000
Received: from [85.158.138.51:41188] by server-7.bemta-3.messagelabs.com id
	D1/A8-31267-4A1E52F4; Mon, 30 Jan 2012 00:17:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327882660!11099011!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIwNjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12168 invoked from network); 30 Jan 2012 00:17:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 00:17:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327882659; l=896;
	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=QRAC2emIJQ0uC/tPMSOlrYcg28Q=;
	b=MHqgPMGa/OnV6+9DArO+7lwbikCqdRR7enOCN9SP+swvhxUOdUwtHrgRZAglUn6T9QG
	mRaY+UDnUzvKqod3pWi24jA9UcAwcexQjdcvhBfp2jOA+wypjGcih2EvTGxgaXTk0yA6i
	DtYwontgW1hnyGD6LxE9+fxTXty5+EDfytk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7ofw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-003.pools.arcor-ip.net [84.57.68.3])
	by post.strato.de (mrclete mo34) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j04399o0TNYJIE
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:17:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C0DA018634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:17:23 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2b11c22c903b52156ebf0cbe0891cc7d8f918633
Message-Id: <2b11c22c903b52156ebf.1327882642@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 01:17:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: fix bitmap_alloc usage in
	xc_ia64_send_vcpumap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327882598 -3600
# Node ID 2b11c22c903b52156ebf0cbe0891cc7d8f918633
# Parent  39df93acd4089eaae138e1decf49aec39fb19417
tools/libxc: fix bitmap_alloc usage in xc_ia64_send_vcpumap

Changeset 23577:607474aeefe1 introduced an error in
xc_ia64_send_vcpumap(), bitmap_alloc() was not used correctly.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 39df93acd408 -r 2b11c22c903b tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c
@@ -195,8 +195,8 @@ xc_ia64_send_vcpumap(xc_interface *xch, 
     uint64_t *vcpumap = NULL;
 
     vcpumap_size = bitmap_size(max_virt_cpus);
-    rc = bitmap_alloc(&vcpumap, max_virt_cpus);
-    if (rc < 0) {
+    vcpumap = bitmap_alloc(max_virt_cpus);
+    if (!vcpumap) {
         ERROR("memory alloc for vcpumap");
         goto out;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 00:18:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 00:18:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrewI-0001kt-LP; Mon, 30 Jan 2012 00:17:42 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RrewH-0001ko-Mv
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 00:17:42 +0000
Received: from [85.158.138.51:41188] by server-7.bemta-3.messagelabs.com id
	D1/A8-31267-4A1E52F4; Mon, 30 Jan 2012 00:17:40 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327882660!11099011!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIwNjI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIwNjI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12168 invoked from network); 30 Jan 2012 00:17:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-12.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 00:17:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327882659; l=896;
	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=QRAC2emIJQ0uC/tPMSOlrYcg28Q=;
	b=MHqgPMGa/OnV6+9DArO+7lwbikCqdRR7enOCN9SP+swvhxUOdUwtHrgRZAglUn6T9QG
	mRaY+UDnUzvKqod3pWi24jA9UcAwcexQjdcvhBfp2jOA+wypjGcih2EvTGxgaXTk0yA6i
	DtYwontgW1hnyGD6LxE9+fxTXty5+EDfytk=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7ofw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-003.pools.arcor-ip.net [84.57.68.3])
	by post.strato.de (mrclete mo34) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id j04399o0TNYJIE
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:17:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id C0DA018634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:17:23 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2b11c22c903b52156ebf0cbe0891cc7d8f918633
Message-Id: <2b11c22c903b52156ebf.1327882642@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 01:17:22 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: fix bitmap_alloc usage in
	xc_ia64_send_vcpumap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327882598 -3600
# Node ID 2b11c22c903b52156ebf0cbe0891cc7d8f918633
# Parent  39df93acd4089eaae138e1decf49aec39fb19417
tools/libxc: fix bitmap_alloc usage in xc_ia64_send_vcpumap

Changeset 23577:607474aeefe1 introduced an error in
xc_ia64_send_vcpumap(), bitmap_alloc() was not used correctly.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 39df93acd408 -r 2b11c22c903b tools/libxc/ia64/xc_ia64_linux_save.c
--- a/tools/libxc/ia64/xc_ia64_linux_save.c
+++ b/tools/libxc/ia64/xc_ia64_linux_save.c
@@ -195,8 +195,8 @@ xc_ia64_send_vcpumap(xc_interface *xch, 
     uint64_t *vcpumap = NULL;
 
     vcpumap_size = bitmap_size(max_virt_cpus);
-    rc = bitmap_alloc(&vcpumap, max_virt_cpus);
-    if (rc < 0) {
+    vcpumap = bitmap_alloc(max_virt_cpus);
+    if (!vcpumap) {
         ERROR("memory alloc for vcpumap");
         goto out;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 00:37:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 00:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrfEY-0001vt-Hn; Mon, 30 Jan 2012 00:36:34 +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 1RrfEW-0001vo-I8
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 00:36:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327883785!5433669!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjUzMjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjUzMjQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30109 invoked from network); 30 Jan 2012 00:36:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 00:36:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327883785; l=2865;
	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=3eF5EGFzyVFGVLLkqJQz5YWPWpE=;
	b=VvBFXFNTOXA8meQMlPwOs/kwHMeiQiT1s/WI3NoQTpo5BHLcI46R2NkWZ42kEBRv7c0
	RfR5el/Zmz1qmGrx8jCM//b7BwIO14YdLkzEg63eUszYAzVelTYurltP4t0UBB9u165C3
	gCJLzNj8saZEl7VRtDTHMoIIyiCmf8pQ560=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7ofw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-003.pools.arcor-ip.net [84.57.68.3])
	by smtp.strato.de (cohen mo14) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d0023do0TNf2Sa
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:36:16 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B4ADC18634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:36:20 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 5da4c273e819d5a1d42f3186f0829f8e00d83132
Message-Id: <5da4c273e819d5a1d42f.1327883776@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 01:36:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for bitmap
 operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327883694 -3600
# Node ID 5da4c273e819d5a1d42f3186f0829f8e00d83132
# Parent  b06617b0398c73c63ce153f39464fd1edac788e5
tools/libxc: make volatile keyword for bitmap operations optional

Except for xc_save, all bitmaps maintained by xc_bitops.h are used in single
threaded applications. So nothing will change the bitmaps content, adding
volatile adds just unneeded memory reloads.

Adjust the bitmap helpers to make the volatile keyword optional. Users of
xc_bitops.h can define XC_BITMAPS_VOLATILE before inclusion to declare all
bitmaps as volatile.

xc_save passes the bitmap to the hypervisor which in turn modifies it. To be
safe, declare the used bitmaps as volatile.

xenpaging uses bitmaps alot and using non-volatile versions will slightly
improve performance.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b06617b0398c -r 5da4c273e819 tools/libxc/xc_bitops.h
--- a/tools/libxc/xc_bitops.h
+++ b/tools/libxc/xc_bitops.h
@@ -3,6 +3,13 @@
 
 /* bitmap operations for single threaded access */
 
+/* Declare bitmaps passed to the hypervisor as volatile */
+#ifdef XC_BITMAPS_VOLATILE
+#define __XC_BITMAP_VOLATILE volatile
+#else
+#define __XC_BITMAP_VOLATILE
+#endif
+
 #include <stdlib.h>
 #include <string.h>
 
@@ -31,29 +38,29 @@ static inline void bitmap_clear(unsigned
     memset(addr, 0, bitmap_size(nr_bits));
 }
 
-static inline int test_bit(int nr, volatile unsigned long *addr)
+static inline int test_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;
 }
 
-static inline void clear_bit(int nr, volatile unsigned long *addr)
+static inline void clear_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     BITMAP_ENTRY(nr, addr) &= ~(1UL << BITMAP_SHIFT(nr));
 }
 
-static inline void set_bit(int nr, volatile unsigned long *addr)
+static inline void set_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     BITMAP_ENTRY(nr, addr) |= (1UL << BITMAP_SHIFT(nr));
 }
 
-static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_clear_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     int oldbit = test_bit(nr, addr);
     clear_bit(nr, addr);
     return oldbit;
 }
 
-static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_set_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     int oldbit = test_bit(nr, addr);
     set_bit(nr, addr);
diff -r b06617b0398c -r 5da4c273e819 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -27,6 +27,7 @@
 #include <sys/time.h>
 
 #include "xc_private.h"
+#define XC_BITMAPS_VOLATILE
 #include "xc_bitops.h"
 #include "xc_dom.h"
 #include "xg_private.h"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 00:37:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 00:37:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrfEY-0001vt-Hn; Mon, 30 Jan 2012 00:36:34 +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 1RrfEW-0001vo-I8
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 00:36:32 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327883785!5433669!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjUzMjQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjUzMjQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30109 invoked from network); 30 Jan 2012 00:36:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-8.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 00:36:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327883785; l=2865;
	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=3eF5EGFzyVFGVLLkqJQz5YWPWpE=;
	b=VvBFXFNTOXA8meQMlPwOs/kwHMeiQiT1s/WI3NoQTpo5BHLcI46R2NkWZ42kEBRv7c0
	RfR5el/Zmz1qmGrx8jCM//b7BwIO14YdLkzEg63eUszYAzVelTYurltP4t0UBB9u165C3
	gCJLzNj8saZEl7VRtDTHMoIIyiCmf8pQ560=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7ofw==
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-003.pools.arcor-ip.net [84.57.68.3])
	by smtp.strato.de (cohen mo14) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id d0023do0TNf2Sa
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:36:16 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B4ADC18634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:36:20 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 5da4c273e819d5a1d42f3186f0829f8e00d83132
Message-Id: <5da4c273e819d5a1d42f.1327883776@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 01:36:16 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for bitmap
 operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327883694 -3600
# Node ID 5da4c273e819d5a1d42f3186f0829f8e00d83132
# Parent  b06617b0398c73c63ce153f39464fd1edac788e5
tools/libxc: make volatile keyword for bitmap operations optional

Except for xc_save, all bitmaps maintained by xc_bitops.h are used in single
threaded applications. So nothing will change the bitmaps content, adding
volatile adds just unneeded memory reloads.

Adjust the bitmap helpers to make the volatile keyword optional. Users of
xc_bitops.h can define XC_BITMAPS_VOLATILE before inclusion to declare all
bitmaps as volatile.

xc_save passes the bitmap to the hypervisor which in turn modifies it. To be
safe, declare the used bitmaps as volatile.

xenpaging uses bitmaps alot and using non-volatile versions will slightly
improve performance.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b06617b0398c -r 5da4c273e819 tools/libxc/xc_bitops.h
--- a/tools/libxc/xc_bitops.h
+++ b/tools/libxc/xc_bitops.h
@@ -3,6 +3,13 @@
 
 /* bitmap operations for single threaded access */
 
+/* Declare bitmaps passed to the hypervisor as volatile */
+#ifdef XC_BITMAPS_VOLATILE
+#define __XC_BITMAP_VOLATILE volatile
+#else
+#define __XC_BITMAP_VOLATILE
+#endif
+
 #include <stdlib.h>
 #include <string.h>
 
@@ -31,29 +38,29 @@ static inline void bitmap_clear(unsigned
     memset(addr, 0, bitmap_size(nr_bits));
 }
 
-static inline int test_bit(int nr, volatile unsigned long *addr)
+static inline int test_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;
 }
 
-static inline void clear_bit(int nr, volatile unsigned long *addr)
+static inline void clear_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     BITMAP_ENTRY(nr, addr) &= ~(1UL << BITMAP_SHIFT(nr));
 }
 
-static inline void set_bit(int nr, volatile unsigned long *addr)
+static inline void set_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     BITMAP_ENTRY(nr, addr) |= (1UL << BITMAP_SHIFT(nr));
 }
 
-static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_clear_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     int oldbit = test_bit(nr, addr);
     clear_bit(nr, addr);
     return oldbit;
 }
 
-static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_set_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
 {
     int oldbit = test_bit(nr, addr);
     set_bit(nr, addr);
diff -r b06617b0398c -r 5da4c273e819 tools/libxc/xc_domain_save.c
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -27,6 +27,7 @@
 #include <sys/time.h>
 
 #include "xc_private.h"
+#define XC_BITMAPS_VOLATILE
 #include "xc_bitops.h"
 #include "xc_dom.h"
 #include "xg_private.h"

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 03:17:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 03:17:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrhjC-0008CY-KT; Mon, 30 Jan 2012 03:16:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RrhjB-00085l-4O
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 03:16:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327893316!58879357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16070 invoked from network); 30 Jan 2012 03:15:16 -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;
	30 Jan 2012 03:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,590,1320624000"; d="scan'208";a="10354799"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 03:16:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 03:16: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 1Rrhj6-00087V-6I;
	Mon, 30 Jan 2012 03:16:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rrhj6-0003wF-5Q;
	Mon, 30 Jan 2012 03:16:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11726-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 03:16:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11726: regressions - trouble:
	blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11726 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11726/

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 in 11669 REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 build-i386-pvops              2 host-install(2)           broken pass in 11669
 build-amd64                   2 host-install(2)           broken pass in 11708
 build-amd64-pvops             2 host-install(2)           broken pass in 11708
 build-i386                    2 host-install(2)           broken pass in 11669
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-pv           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-win       3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-win          3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 11708 pass in 11669

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2   fail in 11669 blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      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-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11669 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11669 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11669 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11669 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11669 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11669 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11669 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11669 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11669 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11669 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 03:17:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 03:17:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrhjC-0008CY-KT; Mon, 30 Jan 2012 03:16:22 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RrhjB-00085l-4O
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 03:16:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327893316!58879357!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg0MQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16070 invoked from network); 30 Jan 2012 03:15:16 -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;
	30 Jan 2012 03:15:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,590,1320624000"; d="scan'208";a="10354799"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 03:16:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 03:16: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 1Rrhj6-00087V-6I;
	Mon, 30 Jan 2012 03:16:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rrhj6-0003wF-5Q;
	Mon, 30 Jan 2012 03:16:16 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11726-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 03:16:16 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11726: regressions - trouble:
	blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11726 linux real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11726/

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 in 11669 REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 build-i386-pvops              2 host-install(2)           broken pass in 11669
 build-amd64                   2 host-install(2)           broken pass in 11708
 build-amd64-pvops             2 host-install(2)           broken pass in 11708
 build-i386                    2 host-install(2)           broken pass in 11669
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-pv           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-win       3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-win          3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 11708 pass in 11669

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2   fail in 11669 blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pv            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl            1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-pair          1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      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-win       1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-win          1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl-win         1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11669 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11669 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11669 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11669 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11669 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11669 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11669 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11669 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11669 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11669 never pass

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 07:33:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 07:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrljC-0003SQ-Hp; Mon, 30 Jan 2012 07:32:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RrljA-0003SK-TJ
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 07:32:37 +0000
Received: from [85.158.138.51:57397] by server-3.bemta-3.messagelabs.com id
	1B/9D-26314-497462F4; Mon, 30 Jan 2012 07:32:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327908755!11127805!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8578 invoked from network); 30 Jan 2012 07:32:35 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 07:32:35 -0000
Received: by wibhm2 with SMTP id hm2so12641160wib.30
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 23:32:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=S7jDHxf5mDfuaj9sZEgE4bVzGXlyxG8PS++g5k0B41Q=;
	b=NCo1R3uZhScd2x4yAZfh/zlavw85b5XiUXLOVnuQ5INaYra5+Gsgy23bLbsk/UV8l3
	OaPvJvjmp2Knz8whYdsvCzq/ZzWL3fiyx37kqYcrqWGUbEotLqJlNDmztlXtaXiM73Z8
	4Ba/b5Xu6fneoG7r61E3MQmGYaYjA+CL1+SUw=
Received: by 10.180.89.71 with SMTP id bm7mr21286971wib.20.1327908755104;
	Sun, 29 Jan 2012 23:32:35 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q7sm28179020wix.5.2012.01.29.23.32.32
	(version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 23:32:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 30 Jan 2012 07:32:31 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB4BF80F.29F55%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
	bitmap operations optional
Thread-Index: AczfIVM4N1a7Y5jFNUiHiezpPcPieQ==
In-Reply-To: <5da4c273e819d5a1d42f.1327883776@probook.site>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
 bitmap operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/01/2012 00:36, "Olaf Hering" <olaf@aepfle.de> wrote:

> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327883694 -3600
> # Node ID 5da4c273e819d5a1d42f3186f0829f8e00d83132
> # Parent  b06617b0398c73c63ce153f39464fd1edac788e5
> tools/libxc: make volatile keyword for bitmap operations optional
> 
> Except for xc_save, all bitmaps maintained by xc_bitops.h are used in single
> threaded applications. So nothing will change the bitmaps content, adding
> volatile adds just unneeded memory reloads.

The bitops aren't threadsafe anyway, as none of them use atomic rmw
instructions. I suspect the volatile declarations are completely pointless
and can just be removed.

 -- Keir

> Adjust the bitmap helpers to make the volatile keyword optional. Users of
> xc_bitops.h can define XC_BITMAPS_VOLATILE before inclusion to declare all
> bitmaps as volatile.
> 
> xc_save passes the bitmap to the hypervisor which in turn modifies it. To be
> safe, declare the used bitmaps as volatile.
> 
> xenpaging uses bitmaps alot and using non-volatile versions will slightly
> improve performance.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r b06617b0398c -r 5da4c273e819 tools/libxc/xc_bitops.h
> --- a/tools/libxc/xc_bitops.h
> +++ b/tools/libxc/xc_bitops.h
> @@ -3,6 +3,13 @@
>  
>  /* bitmap operations for single threaded access */
>  
> +/* Declare bitmaps passed to the hypervisor as volatile */
> +#ifdef XC_BITMAPS_VOLATILE
> +#define __XC_BITMAP_VOLATILE volatile
> +#else
> +#define __XC_BITMAP_VOLATILE
> +#endif
> +
>  #include <stdlib.h>
>  #include <string.h>
>  
> @@ -31,29 +38,29 @@ static inline void bitmap_clear(unsigned
>      memset(addr, 0, bitmap_size(nr_bits));
>  }
>  
> -static inline int test_bit(int nr, volatile unsigned long *addr)
> +static inline int test_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
>  {
>      return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;
>  }
>  
> -static inline void clear_bit(int nr, volatile unsigned long *addr)
> +static inline void clear_bit(int nr, __XC_BITMAP_VOLATILE unsigned long
> *addr)
>  {
>      BITMAP_ENTRY(nr, addr) &= ~(1UL << BITMAP_SHIFT(nr));
>  }
>  
> -static inline void set_bit(int nr, volatile unsigned long *addr)
> +static inline void set_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
>  {
>      BITMAP_ENTRY(nr, addr) |= (1UL << BITMAP_SHIFT(nr));
>  }
>  
> -static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
> +static inline int test_and_clear_bit(int nr, __XC_BITMAP_VOLATILE unsigned
> long *addr)
>  {
>      int oldbit = test_bit(nr, addr);
>      clear_bit(nr, addr);
>      return oldbit;
>  }
>  
> -static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
> +static inline int test_and_set_bit(int nr, __XC_BITMAP_VOLATILE unsigned long
> *addr)
>  {
>      int oldbit = test_bit(nr, addr);
>      set_bit(nr, addr);
> diff -r b06617b0398c -r 5da4c273e819 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -27,6 +27,7 @@
>  #include <sys/time.h>
>  
>  #include "xc_private.h"
> +#define XC_BITMAPS_VOLATILE
>  #include "xc_bitops.h"
>  #include "xc_dom.h"
>  #include "xg_private.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 Jan 30 07:33:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 07:33:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrljC-0003SQ-Hp; Mon, 30 Jan 2012 07:32:38 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <keir.xen@gmail.com>) id 1RrljA-0003SK-TJ
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 07:32:37 +0000
Received: from [85.158.138.51:57397] by server-3.bemta-3.messagelabs.com id
	1B/9D-26314-497462F4; Mon, 30 Jan 2012 07:32:36 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327908755!11127805!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8578 invoked from network); 30 Jan 2012 07:32:35 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-12.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 07:32:35 -0000
Received: by wibhm2 with SMTP id hm2so12641160wib.30
	for <xen-devel@lists.xensource.com>;
	Sun, 29 Jan 2012 23:32:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=user-agent:date:subject:from:to:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=S7jDHxf5mDfuaj9sZEgE4bVzGXlyxG8PS++g5k0B41Q=;
	b=NCo1R3uZhScd2x4yAZfh/zlavw85b5XiUXLOVnuQ5INaYra5+Gsgy23bLbsk/UV8l3
	OaPvJvjmp2Knz8whYdsvCzq/ZzWL3fiyx37kqYcrqWGUbEotLqJlNDmztlXtaXiM73Z8
	4Ba/b5Xu6fneoG7r61E3MQmGYaYjA+CL1+SUw=
Received: by 10.180.89.71 with SMTP id bm7mr21286971wib.20.1327908755104;
	Sun, 29 Jan 2012 23:32:35 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q7sm28179020wix.5.2012.01.29.23.32.32
	(version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 23:32:33 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 30 Jan 2012 07:32:31 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>,
	<xen-devel@lists.xensource.com>
Message-ID: <CB4BF80F.29F55%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
	bitmap operations optional
Thread-Index: AczfIVM4N1a7Y5jFNUiHiezpPcPieQ==
In-Reply-To: <5da4c273e819d5a1d42f.1327883776@probook.site>
Mime-version: 1.0
Subject: Re: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
 bitmap operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/01/2012 00:36, "Olaf Hering" <olaf@aepfle.de> wrote:

> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327883694 -3600
> # Node ID 5da4c273e819d5a1d42f3186f0829f8e00d83132
> # Parent  b06617b0398c73c63ce153f39464fd1edac788e5
> tools/libxc: make volatile keyword for bitmap operations optional
> 
> Except for xc_save, all bitmaps maintained by xc_bitops.h are used in single
> threaded applications. So nothing will change the bitmaps content, adding
> volatile adds just unneeded memory reloads.

The bitops aren't threadsafe anyway, as none of them use atomic rmw
instructions. I suspect the volatile declarations are completely pointless
and can just be removed.

 -- Keir

> Adjust the bitmap helpers to make the volatile keyword optional. Users of
> xc_bitops.h can define XC_BITMAPS_VOLATILE before inclusion to declare all
> bitmaps as volatile.
> 
> xc_save passes the bitmap to the hypervisor which in turn modifies it. To be
> safe, declare the used bitmaps as volatile.
> 
> xenpaging uses bitmaps alot and using non-volatile versions will slightly
> improve performance.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r b06617b0398c -r 5da4c273e819 tools/libxc/xc_bitops.h
> --- a/tools/libxc/xc_bitops.h
> +++ b/tools/libxc/xc_bitops.h
> @@ -3,6 +3,13 @@
>  
>  /* bitmap operations for single threaded access */
>  
> +/* Declare bitmaps passed to the hypervisor as volatile */
> +#ifdef XC_BITMAPS_VOLATILE
> +#define __XC_BITMAP_VOLATILE volatile
> +#else
> +#define __XC_BITMAP_VOLATILE
> +#endif
> +
>  #include <stdlib.h>
>  #include <string.h>
>  
> @@ -31,29 +38,29 @@ static inline void bitmap_clear(unsigned
>      memset(addr, 0, bitmap_size(nr_bits));
>  }
>  
> -static inline int test_bit(int nr, volatile unsigned long *addr)
> +static inline int test_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
>  {
>      return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;
>  }
>  
> -static inline void clear_bit(int nr, volatile unsigned long *addr)
> +static inline void clear_bit(int nr, __XC_BITMAP_VOLATILE unsigned long
> *addr)
>  {
>      BITMAP_ENTRY(nr, addr) &= ~(1UL << BITMAP_SHIFT(nr));
>  }
>  
> -static inline void set_bit(int nr, volatile unsigned long *addr)
> +static inline void set_bit(int nr, __XC_BITMAP_VOLATILE unsigned long *addr)
>  {
>      BITMAP_ENTRY(nr, addr) |= (1UL << BITMAP_SHIFT(nr));
>  }
>  
> -static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
> +static inline int test_and_clear_bit(int nr, __XC_BITMAP_VOLATILE unsigned
> long *addr)
>  {
>      int oldbit = test_bit(nr, addr);
>      clear_bit(nr, addr);
>      return oldbit;
>  }
>  
> -static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
> +static inline int test_and_set_bit(int nr, __XC_BITMAP_VOLATILE unsigned long
> *addr)
>  {
>      int oldbit = test_bit(nr, addr);
>      set_bit(nr, addr);
> diff -r b06617b0398c -r 5da4c273e819 tools/libxc/xc_domain_save.c
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -27,6 +27,7 @@
>  #include <sys/time.h>
>  
>  #include "xc_private.h"
> +#define XC_BITMAPS_VOLATILE
>  #include "xc_bitops.h"
>  #include "xc_dom.h"
>  #include "xg_private.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 Jan 30 07:52:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 07: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 1Rrm2C-0004Ra-3x; Mon, 30 Jan 2012 07:52: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 1Rrm2B-0004RF-D1
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 07:52:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327909929!3158730!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19101 invoked from network); 30 Jan 2012 07:52:09 -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; 30 Jan 2012 07:52:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 07:52:08 +0000
Message-Id: <4F265A34020000780006FCD8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 07:52:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
In-Reply-To: <1327596896.24345.66.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
>> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> x86's vMCE implementation lets a guest know of as many MCE reporting
>> >> banks as there are in the host. While a PV guest could be expected to
>> >> deal with this number changing (particularly decreasing) during migration
>> >> (not currently handled anywhere afaict), for HVM guests this is certainly
>> >> wrong.
>> >>
>> >> At least to me it isn't, however, clear how to properly handle this. The
>> >> easiest would appear to be to save and restore the number of banks
>> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
>> >> silently tolerate accesses between the host and guest values.
>> > 
>> > We ran into this in the XS 6.0 release as well.  I think that the
>> > ideal thing to do would be to have a parameter that can be set at
>> > boot, to say how many vMCE banks a guest has, defaulting to the number
>> > of MCE banks on the host.  This parameter would be preserved across
>> > migration.  Ideally, a pool-aware toolstack like xapi would then set
>> > this value to be the value of the host in the pool with the largest
>> > number of banks, allowing a guest to access all the banks on any host
>> > to which it migrates.
>> > 
>> > What do you think?
>> 
>> That sounds like the way to go.
> 
> So should we put this on IanC's to-do-be-done list?

Would certainly be desirable to get fixed.

> Are you going to put it on your to-do list? :-)

I'll first check with Intel whether the engineers who wrote that code
could make an attempt.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 07:52:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 07: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 1Rrm2C-0004Ra-3x; Mon, 30 Jan 2012 07:52: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 1Rrm2B-0004RF-D1
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 07:52:15 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-21.messagelabs.com!1327909929!3158730!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19101 invoked from network); 30 Jan 2012 07:52:09 -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; 30 Jan 2012 07:52:09 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 07:52:08 +0000
Message-Id: <4F265A34020000780006FCD8@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 07:52:04 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
In-Reply-To: <1327596896.24345.66.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
>> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> x86's vMCE implementation lets a guest know of as many MCE reporting
>> >> banks as there are in the host. While a PV guest could be expected to
>> >> deal with this number changing (particularly decreasing) during migration
>> >> (not currently handled anywhere afaict), for HVM guests this is certainly
>> >> wrong.
>> >>
>> >> At least to me it isn't, however, clear how to properly handle this. The
>> >> easiest would appear to be to save and restore the number of banks
>> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
>> >> silently tolerate accesses between the host and guest values.
>> > 
>> > We ran into this in the XS 6.0 release as well.  I think that the
>> > ideal thing to do would be to have a parameter that can be set at
>> > boot, to say how many vMCE banks a guest has, defaulting to the number
>> > of MCE banks on the host.  This parameter would be preserved across
>> > migration.  Ideally, a pool-aware toolstack like xapi would then set
>> > this value to be the value of the host in the pool with the largest
>> > number of banks, allowing a guest to access all the banks on any host
>> > to which it migrates.
>> > 
>> > What do you think?
>> 
>> That sounds like the way to go.
> 
> So should we put this on IanC's to-do-be-done list?

Would certainly be desirable to get fixed.

> Are you going to put it on your to-do list? :-)

I'll first check with Intel whether the engineers who wrote that code
could make an attempt.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 08:12:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 08: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 1RrmLQ-0005Kx-3M; Mon, 30 Jan 2012 08:12:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RrmLN-0005Kk-JY
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 08:12:06 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327911093!57630558!1
X-Originating-IP: [220.181.15.25]
X-SpamReason: No, hits=1.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNDA=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNDA=\n,BODY_DONG,HTML_40_50,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9842 invoked from network); 30 Jan 2012 08:11:35 -0000
Received: from m15-25.126.com (HELO m15-25.126.com) (220.181.15.25)
	by server-13.tower-27.messagelabs.com with SMTP;
	30 Jan 2012 08:11:35 -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=VDeHI/9QtUpMhpD/EaE8DH8eolxQSpXGok
	J21ZxbI74=; b=HISfNYDg82Rjw7gu+tfP/8p9r5/UWiM0oO44bLIefYU2YuttzB
	ykmoRTWMFoZ9nB1+zmCUxWKgA/6gB4u5SXBrF0Bz0Hs7voGE6k2WbM3c+A9DpO/G
	gw1mnSN8yipZYniLCqISy9cLq2Va+jc9WjmN2SFaQzG8wuKiz6cKDKIkM=
Received: from hxkhust ( [27.16.129.184] ) by ajax-webmail-wmsvr25
	(Coremail) ; Mon, 30 Jan 2012 16:11:59 +0800 (CST)
Date: Mon, 30 Jan 2012 16:11:59 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [27.16.129.184]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: LPpTS2Zvb3Rlcl9odG09MTk5NTo4MQ==
X-CM-TRANSID: GcqowGB5H0HQUCZPuIUGAA--.37208W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiDhRFBU0vGxF1wQACsE
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9051969884286282333=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9051969884286282333==
Content-Type: multipart/alternative; 
	boundary="----=_Part_176973_860871571.1327911119960"

------=_Part_176973_860871571.1327911119960
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,
 
Recently I'm dong some reserch on xen and encounter a problem that I cannot solve temporarily.I need your help very much and the following is the question I would like to ask:
On a physical machine with xen virtualization platform installed ,VM A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM A and VM B's virtual disk image files are based on VM C's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM A get a page data from VM C's virtual disk image file. After that ,VM B also need to get the same page data as VM A got just now.Under this situation, does VMM copy the page data from VM A's memory to VM B's memory or get the page data from VM C's virtual disk image file in the physical disk again? Or if I would like to figure out this problem,what shall I do?
Thank you for reading my email.Your reply including your proposal is precious for me.
 
HXK
Huazhong University of Science and Technology
Wuhan, 430074, China
------=_Part_176973_860871571.1327911119960
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Recently I'm dong some reserch on xen and encounter a problem that&nbsp;I cannot solve temporarily.I need your help very much and the&nbsp;following is the&nbsp;question&nbsp;I would like to ask:</DIV>
<DIV>On a physical machine&nbsp;with xen virtualization platform&nbsp;installed ,VM&nbsp;A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM&nbsp;A and VM B's virtual disk image files are based on VM C's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM&nbsp;A get a page data from VM C's virtual disk image file. After that ,VM&nbsp;B also need to get the same page data as VM&nbsp;A got just now.Under this situation, does VMM copy the page data from VM A's memory to VM B's memory or get the page data from&nbsp;VM C's virtual disk image file in the physical disk again?&nbsp;Or if&nbsp;I would like to figure out this problem,what&nbsp;shall&nbsp;I&nbsp;do?</DIV>
<DIV>Thank you for reading my email.Your&nbsp;reply including your p<SPAN id="result_box" lang="en" class="short_text" c="4" a="undefined" closure_uid_grg2qg="149"><SPAN class="hps" closure_uid_grg2qg="804">roposal</SPAN></SPAN>&nbsp;is p<SPAN id="result_box" lang="en" class="short_text" c="4" a="undefined" closure_uid_grg2qg="149"><SPAN class="hps" closure_uid_grg2qg="750">recious for me.</SPAN></SPAN></DIV>
<DIV><SPAN lang="en" class="short_text" c="4" a="undefined" closure_uid_grg2qg="149"><SPAN class="hps" closure_uid_grg2qg="750"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN lang="en" class="short_text" c="4" a="undefined" closure_uid_grg2qg="149"><SPAN class="hps" closure_uid_grg2qg="750">
<DIV>HXK</DIV>
<DIV>Huazhong University of Science and Technology<BR>Wuhan, 430074, China</DIV></SPAN></SPAN></DIV>
<DIV></DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_176973_860871571.1327911119960--



--===============9051969884286282333==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9051969884286282333==--



From xen-devel-bounces@lists.xensource.com Mon Jan 30 08:12:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 08: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 1RrmLQ-0005Kx-3M; Mon, 30 Jan 2012 08:12:08 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1RrmLN-0005Kk-JY
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 08:12:06 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327911093!57630558!1
X-Originating-IP: [220.181.15.25]
X-SpamReason: No, hits=1.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNDA=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNDA=\n,BODY_DONG,HTML_40_50,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9842 invoked from network); 30 Jan 2012 08:11:35 -0000
Received: from m15-25.126.com (HELO m15-25.126.com) (220.181.15.25)
	by server-13.tower-27.messagelabs.com with SMTP;
	30 Jan 2012 08:11:35 -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=VDeHI/9QtUpMhpD/EaE8DH8eolxQSpXGok
	J21ZxbI74=; b=HISfNYDg82Rjw7gu+tfP/8p9r5/UWiM0oO44bLIefYU2YuttzB
	ykmoRTWMFoZ9nB1+zmCUxWKgA/6gB4u5SXBrF0Bz0Hs7voGE6k2WbM3c+A9DpO/G
	gw1mnSN8yipZYniLCqISy9cLq2Va+jc9WjmN2SFaQzG8wuKiz6cKDKIkM=
Received: from hxkhust ( [27.16.129.184] ) by ajax-webmail-wmsvr25
	(Coremail) ; Mon, 30 Jan 2012 16:11:59 +0800 (CST)
Date: Mon, 30 Jan 2012 16:11:59 +0800 (CST)
From: hxkhust <hxkhust@126.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [27.16.129.184]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: LPpTS2Zvb3Rlcl9odG09MTk5NTo4MQ==
X-CM-TRANSID: GcqowGB5H0HQUCZPuIUGAA--.37208W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiDhRFBU0vGxF1wQACsE
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============9051969884286282333=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============9051969884286282333==
Content-Type: multipart/alternative; 
	boundary="----=_Part_176973_860871571.1327911119960"

------=_Part_176973_860871571.1327911119960
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Hi,
 
Recently I'm dong some reserch on xen and encounter a problem that I cannot solve temporarily.I need your help very much and the following is the question I would like to ask:
On a physical machine with xen virtualization platform installed ,VM A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM A and VM B's virtual disk image files are based on VM C's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM A get a page data from VM C's virtual disk image file. After that ,VM B also need to get the same page data as VM A got just now.Under this situation, does VMM copy the page data from VM A's memory to VM B's memory or get the page data from VM C's virtual disk image file in the physical disk again? Or if I would like to figure out this problem,what shall I do?
Thank you for reading my email.Your reply including your proposal is precious for me.
 
HXK
Huazhong University of Science and Technology
Wuhan, 430074, China
------=_Part_176973_860871571.1327911119960
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Recently I'm dong some reserch on xen and encounter a problem that&nbsp;I cannot solve temporarily.I need your help very much and the&nbsp;following is the&nbsp;question&nbsp;I would like to ask:</DIV>
<DIV>On a physical machine&nbsp;with xen virtualization platform&nbsp;installed ,VM&nbsp;A,VM B are VM C's virtual disks are all image files,among which VM A and VM B's virtual disks are QCOW2 format and VM C's disk is RAW format. And VM&nbsp;A and VM B's virtual disk image files are based on VM C's virtual disk image file.Now these three VMs are running on the same physical machine with xen installed. In the process of running VM&nbsp;A get a page data from VM C's virtual disk image file. After that ,VM&nbsp;B also need to get the same page data as VM&nbsp;A got just now.Under this situation, does VMM copy the page data from VM A's memory to VM B's memory or get the page data from&nbsp;VM C's virtual disk image file in the physical disk again?&nbsp;Or if&nbsp;I would like to figure out this problem,what&nbsp;shall&nbsp;I&nbsp;do?</DIV>
<DIV>Thank you for reading my email.Your&nbsp;reply including your p<SPAN id="result_box" lang="en" class="short_text" c="4" a="undefined" closure_uid_grg2qg="149"><SPAN class="hps" closure_uid_grg2qg="804">roposal</SPAN></SPAN>&nbsp;is p<SPAN id="result_box" lang="en" class="short_text" c="4" a="undefined" closure_uid_grg2qg="149"><SPAN class="hps" closure_uid_grg2qg="750">recious for me.</SPAN></SPAN></DIV>
<DIV><SPAN lang="en" class="short_text" c="4" a="undefined" closure_uid_grg2qg="149"><SPAN class="hps" closure_uid_grg2qg="750"></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN lang="en" class="short_text" c="4" a="undefined" closure_uid_grg2qg="149"><SPAN class="hps" closure_uid_grg2qg="750">
<DIV>HXK</DIV>
<DIV>Huazhong University of Science and Technology<BR>Wuhan, 430074, China</DIV></SPAN></SPAN></DIV>
<DIV></DIV></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_176973_860871571.1327911119960--



--===============9051969884286282333==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============9051969884286282333==--



From xen-devel-bounces@lists.xensource.com Mon Jan 30 08:57:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 08:57:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrn2x-0006Do-EV; Mon, 30 Jan 2012 08:57:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rrn2v-0006DD-Eh
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 08:57:05 +0000
Received: from [85.158.138.51:44615] by server-9.bemta-3.messagelabs.com id
	A4/6B-31168-F5B562F4; Mon, 30 Jan 2012 08:57:03 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327913820!10990632!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6452 invoked from network); 30 Jan 2012 08:57:03 -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;
	30 Jan 2012 08:57:03 -0000
Received: by dajs34 with SMTP id s34so31118514daj.30
	for <multiple recipients>; Mon, 30 Jan 2012 00:57:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=EEthFWJNLun9mkGam7hwSSFwkmM+HZm98/cEo2U4CP0=;
	b=VhBz+kC30NOCGF+DWiMIpHx7DQL5erBCM9ia48fQJ/3gh1GrqM05DVqSC0eRvhV8sH
	Ex+1Do4a8TIKlDls0iesPRyUCB3PeWyiOxrQFgODxjBB3nK3pY0VVRSxzTFil/Bb6C0D
	D06JBPzaZyIL/Xiw6szJzkez6XjteNqPWtHao=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr40630725pbc.5.1327913820040; Mon,
	30 Jan 2012 00:57:00 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Mon, 30 Jan 2012 00:56:59 -0800 (PST)
In-Reply-To: <4F1473A2.4060103@xen.org>
References: <4F1473A2.4060103@xen.org>
Date: Mon, 30 Jan 2012 09:56:59 +0100
X-Google-Sender-Auth: _eYPWKktNYrQl8lZ9aXTtRBxK9w
Message-ID: <CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Lars Kurth <lars.kurth@xen.org>
Cc: xen-arm@lists.xensource.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/16 Lars Kurth <lars.kurth@xen.org>:
> Hi everybody,
>
> I have been asked when we should hold the next Xen Document Day. Rather than
> going through this every single month, I am proposing dates until March.
> I.e.
> - January 30, 2012

Is this still on?

> - Feb 27, 2012
> - March 26, 2012
> Please go to the Xen Document Days etherpad page
> (http://openetherpad.org/TSPGIEOBiS) to propose a new date or to vote for a
> day.
>
> I also listed items that could be worked on, on the etherpad page (and
> removed stuff which has been done). Feel free to add to it. It is actually
> quite incredible how much we (and YOU) did in the last two Xen Document
> Days. I wanted to thank everybody who was involved!
>
> I am also looking for a couple of volunteers (moderators), in particular in
> Asia and/or Australia and in the US who commit to being on the #xendocday
> IRC channels for a few hours and points other participates to this document
> and generally provides advice. If you are interested, please also sign up on
> the Xen Document Days etherpad page.
>
> Best Regards
> Lars
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 30 08:57:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 08:57:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrn2x-0006Do-EV; Mon, 30 Jan 2012 08:57:07 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1Rrn2v-0006DD-Eh
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 08:57:05 +0000
Received: from [85.158.138.51:44615] by server-9.bemta-3.messagelabs.com id
	A4/6B-31168-F5B562F4; Mon, 30 Jan 2012 08:57:03 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327913820!10990632!1
X-Originating-IP: [209.85.210.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6452 invoked from network); 30 Jan 2012 08:57:03 -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;
	30 Jan 2012 08:57:03 -0000
Received: by dajs34 with SMTP id s34so31118514daj.30
	for <multiple recipients>; Mon, 30 Jan 2012 00:57:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=EEthFWJNLun9mkGam7hwSSFwkmM+HZm98/cEo2U4CP0=;
	b=VhBz+kC30NOCGF+DWiMIpHx7DQL5erBCM9ia48fQJ/3gh1GrqM05DVqSC0eRvhV8sH
	Ex+1Do4a8TIKlDls0iesPRyUCB3PeWyiOxrQFgODxjBB3nK3pY0VVRSxzTFil/Bb6C0D
	D06JBPzaZyIL/Xiw6szJzkez6XjteNqPWtHao=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr40630725pbc.5.1327913820040; Mon,
	30 Jan 2012 00:57:00 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Mon, 30 Jan 2012 00:56:59 -0800 (PST)
In-Reply-To: <4F1473A2.4060103@xen.org>
References: <4F1473A2.4060103@xen.org>
Date: Mon, 30 Jan 2012 09:56:59 +0100
X-Google-Sender-Auth: _eYPWKktNYrQl8lZ9aXTtRBxK9w
Message-ID: <CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Lars Kurth <lars.kurth@xen.org>
Cc: xen-arm@lists.xensource.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

2012/1/16 Lars Kurth <lars.kurth@xen.org>:
> Hi everybody,
>
> I have been asked when we should hold the next Xen Document Day. Rather than
> going through this every single month, I am proposing dates until March.
> I.e.
> - January 30, 2012

Is this still on?

> - Feb 27, 2012
> - March 26, 2012
> Please go to the Xen Document Days etherpad page
> (http://openetherpad.org/TSPGIEOBiS) to propose a new date or to vote for a
> day.
>
> I also listed items that could be worked on, on the etherpad page (and
> removed stuff which has been done). Feel free to add to it. It is actually
> quite incredible how much we (and YOU) did in the last two Xen Document
> Days. I wanted to thank everybody who was involved!
>
> I am also looking for a couple of volunteers (moderators), in particular in
> Asia and/or Australia and in the US who commit to being on the #xendocday
> IRC channels for a few hours and points other participates to this document
> and generally provides advice. If you are interested, please also sign up on
> the Xen Document Days etherpad page.
>
> Best Regards
> Lars
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/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 Jan 30 09:10:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09: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 1RrnFW-0006il-SW; Mon, 30 Jan 2012 09:10:06 +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 1RrnFV-0006iX-CN
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:10:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327914598!12455346!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDM4NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDM4NDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32720 invoked from network); 30 Jan 2012 09:09:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 09:09:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327914598; l=946;
	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=01dtGzEbZ2BjBm+JAR4bMCNtTK4=;
	b=wqQ8rIm1jmSmaOa+1UFxKGyEvnu2aZf9n2FPfGo62Av2OYnLn4nb/uPtwdHssFi7KA2
	G/24SpEQ0Ow5T09WoUQ2sBtJBydaqKbF+L57VjTjhTmlExyFU2Tgrwx0rbXPSV0H5eyP3
	4Aezoy459A1graOsmIVeJC+rD3Vc9KJugEE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (cohen mo38) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j0029do0U8RGGj ;
	Mon, 30 Jan 2012 10:09:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1C39E18637; Mon, 30 Jan 2012 10:10:03 +0100 (CET)
Date: Mon, 30 Jan 2012 10:10:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120130091002.GA29543@aepfle.de>
References: <5da4c273e819d5a1d42f.1327883776@probook.site>
	<CB4BF80F.29F55%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CB4BF80F.29F55%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
 bitmap operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, Keir Fraser wrote:

> On 30/01/2012 00:36, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1327883694 -3600
> > # Node ID 5da4c273e819d5a1d42f3186f0829f8e00d83132
> > # Parent  b06617b0398c73c63ce153f39464fd1edac788e5
> > tools/libxc: make volatile keyword for bitmap operations optional
> > 
> > Except for xc_save, all bitmaps maintained by xc_bitops.h are used in single
> > threaded applications. So nothing will change the bitmaps content, adding
> > volatile adds just unneeded memory reloads.
> 
> The bitops aren't threadsafe anyway, as none of them use atomic rmw
> instructions. I suspect the volatile declarations are completely pointless
> and can just be removed.

Will gcc use the right thing if the array is passed to the hyperviso,
and will it reload everything after the hypercall? If yes, the volatile
can indeed go.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:10:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09: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 1RrnFW-0006il-SW; Mon, 30 Jan 2012 09:10:06 +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 1RrnFV-0006iX-CN
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:10:05 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-10.tower-216.messagelabs.com!1327914598!12455346!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDM4NDU=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDM4NDU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32720 invoked from network); 30 Jan 2012 09:09:59 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 09:09:59 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327914598; l=946;
	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=01dtGzEbZ2BjBm+JAR4bMCNtTK4=;
	b=wqQ8rIm1jmSmaOa+1UFxKGyEvnu2aZf9n2FPfGo62Av2OYnLn4nb/uPtwdHssFi7KA2
	G/24SpEQ0Ow5T09WoUQ2sBtJBydaqKbF+L57VjTjhTmlExyFU2Tgrwx0rbXPSV0H5eyP3
	4Aezoy459A1graOsmIVeJC+rD3Vc9KJugEE=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (cohen mo38) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id j0029do0U8RGGj ;
	Mon, 30 Jan 2012 10:09:58 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 1C39E18637; Mon, 30 Jan 2012 10:10:03 +0100 (CET)
Date: Mon, 30 Jan 2012 10:10:02 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120130091002.GA29543@aepfle.de>
References: <5da4c273e819d5a1d42f.1327883776@probook.site>
	<CB4BF80F.29F55%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CB4BF80F.29F55%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
 bitmap operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, Keir Fraser wrote:

> On 30/01/2012 00:36, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > # HG changeset patch
> > # User Olaf Hering <olaf@aepfle.de>
> > # Date 1327883694 -3600
> > # Node ID 5da4c273e819d5a1d42f3186f0829f8e00d83132
> > # Parent  b06617b0398c73c63ce153f39464fd1edac788e5
> > tools/libxc: make volatile keyword for bitmap operations optional
> > 
> > Except for xc_save, all bitmaps maintained by xc_bitops.h are used in single
> > threaded applications. So nothing will change the bitmaps content, adding
> > volatile adds just unneeded memory reloads.
> 
> The bitops aren't threadsafe anyway, as none of them use atomic rmw
> instructions. I suspect the volatile declarations are completely pointless
> and can just be removed.

Will gcc use the right thing if the array is passed to the hyperviso,
and will it reload everything after the hypercall? If yes, the volatile
can indeed go.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:31:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrnZP-000796-RK; Mon, 30 Jan 2012 09:30:39 +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 1RrnZO-000791-8L
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:30:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327915831!12830223!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23602 invoked from network); 30 Jan 2012 09:30:31 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 09:30:31 -0000
Received: by werb14 with SMTP id b14so12790938wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:30:22 -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=SqHyYWxiNASuQKAs7pCRw7jJjt5B/IRKs32cE++fo/A=;
	b=YUklIz2V0riUbTLpUCZwbQAM1Rf8z5udst/bSjnxAI/62zUXSKTQkTEoReLC74028c
	yBmQ6Lfa7x4bZ1/10mf5OPFu07GjDbJq5ywuFS/hhX4b0N5FmOZ3NpGK1kBShZIPXG8P
	7qDIX8SZ9aeJwlC1hfwWz26sx1Uwm+oBeAp/M=
Received: by 10.216.139.205 with SMTP id c55mr6579116wej.31.1327915822411;
	Mon, 30 Jan 2012 01:30:22 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id bj10sm28811792wib.9.2012.01.30.01.30.19
	(version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 01:30:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 30 Jan 2012 09:30:17 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CB4C13A9.29F65%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
	bitmap operations optional
Thread-Index: AczfMcbiXZPyGNR0602xhO4oFc0QGg==
In-Reply-To: <20120130091002.GA29543@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
 bitmap operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/01/2012 09:10, "Olaf Hering" <olaf@aepfle.de> wrote:

>>> tools/libxc: make volatile keyword for bitmap operations optional
>>> 
>>> Except for xc_save, all bitmaps maintained by xc_bitops.h are used in single
>>> threaded applications. So nothing will change the bitmaps content, adding
>>> volatile adds just unneeded memory reloads.
>> 
>> The bitops aren't threadsafe anyway, as none of them use atomic rmw
>> instructions. I suspect the volatile declarations are completely pointless
>> and can just be removed.
> 
> Will gcc use the right thing if the array is passed to the hyperviso,
> and will it reload everything after the hypercall? If yes, the volatile
> can indeed go.

Of course. Lots of things would fail to work if calls to outside the current
linkage unit didn't flush/invalidate cached shared-data accesses. That's a
fundamental C compiler thing.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:31:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09:31:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrnZP-000796-RK; Mon, 30 Jan 2012 09:30:39 +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 1RrnZO-000791-8L
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:30:38 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327915831!12830223!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23602 invoked from network); 30 Jan 2012 09:30:31 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 09:30:31 -0000
Received: by werb14 with SMTP id b14so12790938wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 01:30:22 -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=SqHyYWxiNASuQKAs7pCRw7jJjt5B/IRKs32cE++fo/A=;
	b=YUklIz2V0riUbTLpUCZwbQAM1Rf8z5udst/bSjnxAI/62zUXSKTQkTEoReLC74028c
	yBmQ6Lfa7x4bZ1/10mf5OPFu07GjDbJq5ywuFS/hhX4b0N5FmOZ3NpGK1kBShZIPXG8P
	7qDIX8SZ9aeJwlC1hfwWz26sx1Uwm+oBeAp/M=
Received: by 10.216.139.205 with SMTP id c55mr6579116wej.31.1327915822411;
	Mon, 30 Jan 2012 01:30:22 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id bj10sm28811792wib.9.2012.01.30.01.30.19
	(version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 01:30:21 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 30 Jan 2012 09:30:17 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <CB4C13A9.29F65%keir.xen@gmail.com>
Thread-Topic: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
	bitmap operations optional
Thread-Index: AczfMcbiXZPyGNR0602xhO4oFc0QGg==
In-Reply-To: <20120130091002.GA29543@aepfle.de>
Mime-version: 1.0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
 bitmap operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/01/2012 09:10, "Olaf Hering" <olaf@aepfle.de> wrote:

>>> tools/libxc: make volatile keyword for bitmap operations optional
>>> 
>>> Except for xc_save, all bitmaps maintained by xc_bitops.h are used in single
>>> threaded applications. So nothing will change the bitmaps content, adding
>>> volatile adds just unneeded memory reloads.
>> 
>> The bitops aren't threadsafe anyway, as none of them use atomic rmw
>> instructions. I suspect the volatile declarations are completely pointless
>> and can just be removed.
> 
> Will gcc use the right thing if the array is passed to the hyperviso,
> and will it reload everything after the hypercall? If yes, the volatile
> can indeed go.

Of course. Lots of things would fail to work if calls to outside the current
linkage unit didn't flush/invalidate cached shared-data accesses. That's a
fundamental C compiler thing.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:35:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09:35:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrndj-0007Gk-Ho; Mon, 30 Jan 2012 09:35:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rrndi-0007GY-0O
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:35:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327916099!4587595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15585 invoked from network); 30 Jan 2012 09:35:00 -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;
	30 Jan 2012 09:35:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10358475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09: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;
	Mon, 30 Jan 2012 09:34:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 09:34:54 +0000
In-Reply-To: <20258.59583.53773.349956@mariner.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
	<20258.59550.374377.953444@mariner.uk.xensource.com>
	<20258.59583.53773.349956@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327916098.26983.208.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 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 18:11 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> > This is plausible.  But:
> > 
> > > +#if 0
> ...
> > > +#endif
> > 
> > You haven't quite finished ?
> 
> Oh I see, this is tidied up in 7/9.

Yes, I should have had a comment next to the #if 0.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:35:36 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09:35:36 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrndj-0007Gk-Ho; Mon, 30 Jan 2012 09:35:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rrndi-0007GY-0O
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:35:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327916099!4587595!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15585 invoked from network); 30 Jan 2012 09:35:00 -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;
	30 Jan 2012 09:35:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10358475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09: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;
	Mon, 30 Jan 2012 09:34:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 09:34:54 +0000
In-Reply-To: <20258.59583.53773.349956@mariner.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
	<20258.59550.374377.953444@mariner.uk.xensource.com>
	<20258.59583.53773.349956@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327916098.26983.208.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 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 18:11 +0000, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> > This is plausible.  But:
> > 
> > > +#if 0
> ...
> > > +#endif
> > 
> > You haven't quite finished ?
> 
> Oh I see, this is tidied up in 7/9.

Yes, I should have had a comment next to the #if 0.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:44:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrnmT-0007SG-In; Mon, 30 Jan 2012 09:44:09 +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 1RrnmS-0007SB-PS
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:44:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327916529!61707409!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6067 invoked from network); 30 Jan 2012 09:42:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 09:42:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RrnmP-000POr-DV; Mon, 30 Jan 2012 09:44:05 +0000
Date: Mon, 30 Jan 2012 09:44:04 +0000
From: Tim Deegan <tim@xen.org>
To: Javanshir Farzin <j.farzin@yahoo.com>
Message-ID: <20120130094404.GA96325@ocelot.phlegethon.org>
References: <1327828079.48123.YahooMailClassic@web161503.mail.bf1.yahoo.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327828079.48123.YahooMailClassic@web161503.mail.bf1.yahoo.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] improve precopy approach
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 01:07 -0800 on 29 Jan (1327799279), Javanshir Farzin wrote:
> Hello
> I am the master student in computer science. My thesis subject in the
> master is improving the pre-copy approach at virtual machine live
> migration. I want to develop this section of XEN. How can I cooperate
> at Xen Development Projects?

Start with the liks at the bottom of this page:
http://www.xen.org/projects/xenhv_devs.html

> I want to access some document about
> XENapproach in memory transfer during live migration.  I survey
> xc_domain_save.c file to understand about some XEN functions, but I
> want to learn more about this. Please help me to achieve more details
> about XEN.

Live migration was described in this 2005 paper:
http://www.cl.cam.ac.uk/research/srg/netos/papers/2005-nsdi-migration.pdf
You should proabably also read the Remus papers:
http://nss.cs.ubc.ca/remus/

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:44:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09:44:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrnmT-0007SG-In; Mon, 30 Jan 2012 09:44:09 +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 1RrnmS-0007SB-PS
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:44:09 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327916529!61707409!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6067 invoked from network); 30 Jan 2012 09:42:10 -0000
Received: from ocelot.phlegethon.org (HELO mail.phlegethon.org) (81.29.64.94)
	by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 09:42:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RrnmP-000POr-DV; Mon, 30 Jan 2012 09:44:05 +0000
Date: Mon, 30 Jan 2012 09:44:04 +0000
From: Tim Deegan <tim@xen.org>
To: Javanshir Farzin <j.farzin@yahoo.com>
Message-ID: <20120130094404.GA96325@ocelot.phlegethon.org>
References: <1327828079.48123.YahooMailClassic@web161503.mail.bf1.yahoo.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327828079.48123.YahooMailClassic@web161503.mail.bf1.yahoo.com>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] improve precopy approach
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 01:07 -0800 on 29 Jan (1327799279), Javanshir Farzin wrote:
> Hello
> I am the master student in computer science. My thesis subject in the
> master is improving the pre-copy approach at virtual machine live
> migration. I want to develop this section of XEN. How can I cooperate
> at Xen Development Projects?

Start with the liks at the bottom of this page:
http://www.xen.org/projects/xenhv_devs.html

> I want to access some document about
> XENapproach in memory transfer during live migration.  I survey
> xc_domain_save.c file to understand about some XEN functions, but I
> want to learn more about this. Please help me to achieve more details
> about XEN.

Live migration was described in this 2005 paper:
http://www.cl.cam.ac.uk/research/srg/netos/papers/2005-nsdi-migration.pdf
You should proabably also read the Remus papers:
http://nss.cs.ubc.ca/remus/

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:46:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09: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 1Rrnor-0007au-BB; Mon, 30 Jan 2012 09:46:37 +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 1Rrnop-0007Zg-La; Mon, 30 Jan 2012 09:46:35 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327916719!62984346!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2829 invoked from network); 30 Jan 2012 09:45:19 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 09:45:19 -0000
Received: by wibhm2 with SMTP id hm2so12859370wib.30
	for <multiple recipients>; Mon, 30 Jan 2012 01:46:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=ZXL7wP1sjTv+p9SnEVFPPQX4/ek+mNu1cp3DlfnBaZk=;
	b=WNSPKO5ZpyonXvTk2AjJLV6cUZOlIsHrSoZwrRHZW3uUhw+UmPRV3ESQekBFyUAGim
	Y93Fv0V3THhMzMh9N5ZndZKx3MR6ZE7qYJR1xF7kDMKyt8ObyRgwgld18b7hM4Tf5tHe
	8HRXHyNg8eqpzjvEHtKSWkAUtbXevvuAOYOl4=
Received: by 10.180.80.8 with SMTP id n8mr26335337wix.14.1327916788189;
	Mon, 30 Jan 2012 01:46:28 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id fr8sm50608360wib.10.2012.01.30.01.46.26
	(version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 01:46:27 -0800 (PST)
Message-ID: <4F2666DC.7080601@xen.org>
Date: Mon, 30 Jan 2012 09:46:04 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
References: <4F1473A2.4060103@xen.org>
	<CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
In-Reply-To: <CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
Cc: xen-arm@lists.xensource.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?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="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/01/2012 08:56, Roger Pau Monn=E9 wrote:
> 2012/1/16 Lars Kurth<lars.kurth@xen.org>:
>> Hi everybody,
>>
>> I have been asked when we should hold the next Xen Document Day. Rather =
than
>> going through this every single month, I am proposing dates until March.
>> I.e.
>> - January 30, 2012
> Is this still on?
>
I didn't get any feedback. Going forward, I think we should always hold =

these on the last Monday of the month, starting from Feb.
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:46:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09: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 1Rrnor-0007au-BB; Mon, 30 Jan 2012 09:46:37 +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 1Rrnop-0007Zg-La; Mon, 30 Jan 2012 09:46:35 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327916719!62984346!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2829 invoked from network); 30 Jan 2012 09:45:19 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 09:45:19 -0000
Received: by wibhm2 with SMTP id hm2so12859370wib.30
	for <multiple recipients>; Mon, 30 Jan 2012 01:46:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=ZXL7wP1sjTv+p9SnEVFPPQX4/ek+mNu1cp3DlfnBaZk=;
	b=WNSPKO5ZpyonXvTk2AjJLV6cUZOlIsHrSoZwrRHZW3uUhw+UmPRV3ESQekBFyUAGim
	Y93Fv0V3THhMzMh9N5ZndZKx3MR6ZE7qYJR1xF7kDMKyt8ObyRgwgld18b7hM4Tf5tHe
	8HRXHyNg8eqpzjvEHtKSWkAUtbXevvuAOYOl4=
Received: by 10.180.80.8 with SMTP id n8mr26335337wix.14.1327916788189;
	Mon, 30 Jan 2012 01:46:28 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id fr8sm50608360wib.10.2012.01.30.01.46.26
	(version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 01:46:27 -0800 (PST)
Message-ID: <4F2666DC.7080601@xen.org>
Date: Mon, 30 Jan 2012 09:46:04 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
References: <4F1473A2.4060103@xen.org>
	<CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
In-Reply-To: <CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
Cc: xen-arm@lists.xensource.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?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="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 30/01/2012 08:56, Roger Pau Monn=E9 wrote:
> 2012/1/16 Lars Kurth<lars.kurth@xen.org>:
>> Hi everybody,
>>
>> I have been asked when we should hold the next Xen Document Day. Rather =
than
>> going through this every single month, I am proposing dates until March.
>> I.e.
>> - January 30, 2012
> Is this still on?
>
I didn't get any feedback. Going forward, I think we should always hold =

these on the last Monday of the month, starting from Feb.
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:47:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09: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 1Rrnpi-0007ld-Ft; Mon, 30 Jan 2012 09:47:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rrnph-0007kd-OA
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:47:29 +0000
Received: from [85.158.138.51:20034] by server-4.bemta-3.messagelabs.com id
	43/EB-32238-037662F4; Mon, 30 Jan 2012 09:47:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327916847!11180828!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21392 invoked from network); 30 Jan 2012 09:47:28 -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; 30 Jan 2012 09:47:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rrnpa-000PQB-83; Mon, 30 Jan 2012 09:47:22 +0000
Date: Mon, 30 Jan 2012 09:47:22 +0000
From: Tim Deegan <tim@xen.org>
To: hxkhust <hxkhust@126.com>
Message-ID: <20120130094722.GB96325@ocelot.phlegethon.org>
References: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

At 16:11 +0800 on 30 Jan (1327939919), hxkhust wrote:
> On a physical machine with xen virtualization platform installed ,VM
> A,VM B are VM C's virtual disks are all image files,among which VM A
> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
> format. And VM A and VM B's virtual disk image files are based on VM
> C's virtual disk image file.Now these three VMs are running on the
> same physical machine with xen installed. In the process of running VM
> A get a page data from VM C's virtual disk image file. After that ,VM
> B also need to get the same page data as VM A got just now.Under this
> situation, does VMM copy the page data from VM A's memory to VM B's
> memory or get the page data from VM C's virtual disk image file in the
> physical disk again?

It reads it from the disk again, unless you're using the (prototype)
memory-sharing code that's in blktap.

> Or if I would like to figure out this problem,what shall I do?

Instrument the disk, or read the code.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:47:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09: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 1Rrnpi-0007ld-Ft; Mon, 30 Jan 2012 09:47:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rrnph-0007kd-OA
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:47:29 +0000
Received: from [85.158.138.51:20034] by server-4.bemta-3.messagelabs.com id
	43/EB-32238-037662F4; Mon, 30 Jan 2012 09:47:28 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-8.tower-174.messagelabs.com!1327916847!11180828!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21392 invoked from network); 30 Jan 2012 09:47:28 -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; 30 Jan 2012 09:47:28 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rrnpa-000PQB-83; Mon, 30 Jan 2012 09:47:22 +0000
Date: Mon, 30 Jan 2012 09:47:22 +0000
From: Tim Deegan <tim@xen.org>
To: hxkhust <hxkhust@126.com>
Message-ID: <20120130094722.GB96325@ocelot.phlegethon.org>
References: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

At 16:11 +0800 on 30 Jan (1327939919), hxkhust wrote:
> On a physical machine with xen virtualization platform installed ,VM
> A,VM B are VM C's virtual disks are all image files,among which VM A
> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
> format. And VM A and VM B's virtual disk image files are based on VM
> C's virtual disk image file.Now these three VMs are running on the
> same physical machine with xen installed. In the process of running VM
> A get a page data from VM C's virtual disk image file. After that ,VM
> B also need to get the same page data as VM A got just now.Under this
> situation, does VMM copy the page data from VM A's memory to VM B's
> memory or get the page data from VM C's virtual disk image file in the
> physical disk again?

It reads it from the disk again, unless you're using the (prototype)
memory-sharing code that's in blktap.

> Or if I would like to figure out this problem,what shall I do?

Instrument the disk, or read the code.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:51:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrntg-0008Mo-5X; Mon, 30 Jan 2012 09:51:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rrnte-0008Me-Nu
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:51:34 +0000
Received: from [85.158.138.51:9665] by server-2.bemta-3.messagelabs.com id
	D1/AD-24515-528662F4; Mon, 30 Jan 2012 09:51:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327917092!11000676!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6455 invoked from network); 30 Jan 2012 09:51:33 -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; 30 Jan 2012 09:51:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rrnta-000PRo-OO; Mon, 30 Jan 2012 09:51:30 +0000
Date: Mon, 30 Jan 2012 09:51:29 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120130095129.GC96325@ocelot.phlegethon.org>
References: <ebc68ae15103061fa554.1327607777@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ebc68ae15103061fa554.1327607777@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: unify return value in nominate
	and 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

At 20:56 +0100 on 26 Jan (1327611377), Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327607757 -3600
> # Node ID ebc68ae15103061fa554745efb652b7d7e7b8e89
> # Parent  266a12304601226213a57e39cc11aa075acdfb58
> xenpaging: unify return value in nominate and evict
> 
> Let p2m_mem_paging_nominate and p2m_mem_paging_evict return just one
> error number. EINVAL is not very helpful in case of nominate, it can
> happen if the pager tries to nominate a ballooned page. In this case the
> gfn is not backed by a mfn, the pager can not know that.  Similar with
> evict, anything can happen between nominate and evict.
> 
> This change helps the pager to decide if the returned error is from the
> function itself, or if it happend earlier. In the latter case, it is
> most likely fatal and should be handled as such.
> nominate returns EAGAIN, evict EBUSY.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 266a12304601 -r ebc68ae15103 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;
>  

I don't think EAGAIN is the right thing to return here.  There's no
reason to think that retrying an invalid GFN will work next time. 

I'd be happy for these cases all to return the same code, but maybe
EINVAL would be a better choice. 

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 09:51:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 09:51:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrntg-0008Mo-5X; Mon, 30 Jan 2012 09:51:36 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1Rrnte-0008Me-Nu
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 09:51:34 +0000
Received: from [85.158.138.51:9665] by server-2.bemta-3.messagelabs.com id
	D1/AD-24515-528662F4; Mon, 30 Jan 2012 09:51:33 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327917092!11000676!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6455 invoked from network); 30 Jan 2012 09:51:33 -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; 30 Jan 2012 09:51:33 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1Rrnta-000PRo-OO; Mon, 30 Jan 2012 09:51:30 +0000
Date: Mon, 30 Jan 2012 09:51:29 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120130095129.GC96325@ocelot.phlegethon.org>
References: <ebc68ae15103061fa554.1327607777@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ebc68ae15103061fa554.1327607777@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: unify return value in nominate
	and 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

At 20:56 +0100 on 26 Jan (1327611377), Olaf Hering wrote:
> # HG changeset patch
> # User Olaf Hering <olaf@aepfle.de>
> # Date 1327607757 -3600
> # Node ID ebc68ae15103061fa554745efb652b7d7e7b8e89
> # Parent  266a12304601226213a57e39cc11aa075acdfb58
> xenpaging: unify return value in nominate and evict
> 
> Let p2m_mem_paging_nominate and p2m_mem_paging_evict return just one
> error number. EINVAL is not very helpful in case of nominate, it can
> happen if the pager tries to nominate a ballooned page. In this case the
> gfn is not backed by a mfn, the pager can not know that.  Similar with
> evict, anything can happen between nominate and evict.
> 
> This change helps the pager to decide if the returned error is from the
> function itself, or if it happend earlier. In the latter case, it is
> most likely fatal and should be handled as such.
> nominate returns EAGAIN, evict EBUSY.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> 
> diff -r 266a12304601 -r ebc68ae15103 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;
>  

I don't think EAGAIN is the right thing to return here.  There's no
reason to think that retrying an invalid GFN will work next time. 

I'd be happy for these cases all to return the same code, but maybe
EINVAL would be a better choice. 

Cheers,

Tim.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 10:04:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 10:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rro5Y-0000JV-K5; Mon, 30 Jan 2012 10:03: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 1Rro5X-0000JO-JT
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 10:03:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327917787!57954698!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23624 invoked from network); 30 Jan 2012 10:03:08 -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;
	30 Jan 2012 10:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10359248"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 10:03:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 10:03: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 1Rro4x-00021a-Gl;
	Mon, 30 Jan 2012 10:03:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rro4x-0006MH-By;
	Mon, 30 Jan 2012 10:03:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11728-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 10:03:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11728: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11728 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11728/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11643
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11643
 build-amd64                   2 host-install(2)         broken REGR. vs. 11643
 build-i386                    2 host-install(2)         broken REGR. vs. 11643
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11643
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            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-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-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-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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  39df93acd408
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

(No revision log; it would be 576 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 Jan 30 10:04:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 10:04:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rro5Y-0000JV-K5; Mon, 30 Jan 2012 10:03: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 1Rro5X-0000JO-JT
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 10:03:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327917787!57954698!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23624 invoked from network); 30 Jan 2012 10:03:08 -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;
	30 Jan 2012 10:03:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10359248"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 10:03:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 10:03: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 1Rro4x-00021a-Gl;
	Mon, 30 Jan 2012 10:03:15 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rro4x-0006MH-By;
	Mon, 30 Jan 2012 10:03:15 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11728-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 10:03:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11728: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11728 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11728/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops             2 host-install(2)         broken REGR. vs. 11643
 build-amd64-oldkern           2 host-install(2)         broken REGR. vs. 11643
 build-amd64                   2 host-install(2)         broken REGR. vs. 11643
 build-i386                    2 host-install(2)         broken REGR. vs. 11643
 build-i386-pvops              2 host-install(2)         broken REGR. vs. 11643
 build-i386-oldkern            2 host-install(2)         broken REGR. vs. 11643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-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-credit2    1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pair           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-i386-i386-xl             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-pv             1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-win7-amd64  1 xen-build-check(1)           blocked  n/a
 test-i386-i386-win            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-win       1 xen-build-check(1)           blocked  n/a
 test-i386-i386-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-amd64-i386-win-vcpus1    1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-win           1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-xl-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-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-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)           blocked n/a

version targeted for testing:
 xen                  39df93acd408
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   broken  
 build-amd64-oldkern                                          broken  
 build-i386-oldkern                                           broken  
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           blocked 
 test-i386-i386-xl                                            blocked 
 test-amd64-i386-rhel6hvm-amd                                 blocked 
 test-amd64-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.

(No revision log; it would be 576 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 Jan 30 10:24:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 10: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 1RroPT-0000ex-Fu; Mon, 30 Jan 2012 10:24:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RroPS-0000es-8U
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 10:24:26 +0000
Received: from [85.158.138.51:39224] by server-6.bemta-3.messagelabs.com id
	96/C1-31032-9DF662F4; Mon, 30 Jan 2012 10:24:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327919064!6061195!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6467 invoked from network); 30 Jan 2012 10:24:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 10:24:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327919064; 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=4oxTSkOkfuyS2PlaMUd73JnUfHg=;
	b=iRctiPEJN0sc28clPzkfhkr+s7c46qcYBqjIjik4o1OeVcA6BV01OXN2pO7dWV4Os0d
	InX9iFfdZrTFj+fGLyv1xMkP+TAT1ZwTeXHrBtF6dxTwIsqLWa9CmyWfFj8YUof6Qs2FP
	i8LULNu8UM2MsGO+M0UyaZfuRU2NMehyqz0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (klopstock mo33) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id c00d19o0U9hZmh ;
	Mon, 30 Jan 2012 11:24:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B917A18637; Mon, 30 Jan 2012 11:24:12 +0100 (CET)
Date: Mon, 30 Jan 2012 11:24:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120130102412.GA9935@aepfle.de>
References: <ebc68ae15103061fa554.1327607777@probook.site>
	<20120130095129.GC96325@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120130095129.GC96325@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: unify return value in nominate
 and 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

On Mon, Jan 30, Tim Deegan wrote:

> I don't think EAGAIN is the right thing to return here.  There's no
> reason to think that retrying an invalid GFN will work next time. 
> 
> I'd be happy for these cases all to return the same code, but maybe
> EINVAL would be a better choice. 

EINVAL is returned by upper layers already. I think both nominate and
evict should return EBUSY in case of failure, this is most likely unique
enough to mean "request reached target function, and failed.".

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 10:24:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 10: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 1RroPT-0000ex-Fu; Mon, 30 Jan 2012 10:24:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1RroPS-0000es-8U
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 10:24:26 +0000
Received: from [85.158.138.51:39224] by server-6.bemta-3.messagelabs.com id
	96/C1-31032-9DF662F4; Mon, 30 Jan 2012 10:24:25 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327919064!6061195!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6467 invoked from network); 30 Jan 2012 10:24:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 10:24:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327919064; 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=4oxTSkOkfuyS2PlaMUd73JnUfHg=;
	b=iRctiPEJN0sc28clPzkfhkr+s7c46qcYBqjIjik4o1OeVcA6BV01OXN2pO7dWV4Os0d
	InX9iFfdZrTFj+fGLyv1xMkP+TAT1ZwTeXHrBtF6dxTwIsqLWa9CmyWfFj8YUof6Qs2FP
	i8LULNu8UM2MsGO+M0UyaZfuRU2NMehyqz0=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (klopstock mo33) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id c00d19o0U9hZmh ;
	Mon, 30 Jan 2012 11:24:08 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id B917A18637; Mon, 30 Jan 2012 11:24:12 +0100 (CET)
Date: Mon, 30 Jan 2012 11:24:12 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Tim Deegan <tim@xen.org>
Message-ID: <20120130102412.GA9935@aepfle.de>
References: <ebc68ae15103061fa554.1327607777@probook.site>
	<20120130095129.GC96325@ocelot.phlegethon.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120130095129.GC96325@ocelot.phlegethon.org>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: unify return value in nominate
 and 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

On Mon, Jan 30, Tim Deegan wrote:

> I don't think EAGAIN is the right thing to return here.  There's no
> reason to think that retrying an invalid GFN will work next time. 
> 
> I'd be happy for these cases all to return the same code, but maybe
> EINVAL would be a better choice. 

EINVAL is returned by upper layers already. I think both nominate and
evict should return EBUSY in case of failure, this is most likely unique
enough to mean "request reached target function, and failed.".

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 10:26:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 10:26:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RroRV-0000jc-0a; Mon, 30 Jan 2012 10:26:33 +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 1RroRT-0000jP-Dw
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 10:26:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327919184!12683303!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11546 invoked from network); 30 Jan 2012 10:26:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 10:26:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327919184; l=578;
	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=BMqQBXgeD0dN282VmHkGwUd67Sk=;
	b=Q+Bgjqsmalqp6yDhAywgJAAfa3I+aefZ5GPqf3Lkme5dEpC28ikOQc7PKoL1sOvYoF3
	zRTFncxtbQnNhEpUXIqa3Ve/eGAdRpEAsRBaRluPHn3f7vFFVhJDuOMvx7y0uidFWW2iT
	th0RL4//N8w71bLEho0GUpUc35b0pJZMLl4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (fruni mo16) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L03738o0U9TrKV ;
	Mon, 30 Jan 2012 11:26:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0FE5718637; Mon, 30 Jan 2012 11:26:21 +0100 (CET)
Date: Mon, 30 Jan 2012 11:26:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120130102621.GB9935@aepfle.de>
References: <20120130091002.GA29543@aepfle.de>
	<CB4C13A9.29F65%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CB4C13A9.29F65%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
 bitmap operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, Keir Fraser wrote:

> On 30/01/2012 09:10, "Olaf Hering" <olaf@aepfle.de> wrote:
> > Will gcc use the right thing if the array is passed to the hyperviso,
> > and will it reload everything after the hypercall? If yes, the volatile
> > can indeed go.
> 
> Of course. Lots of things would fail to work if calls to outside the current
> linkage unit didn't flush/invalidate cached shared-data accesses. That's a
> fundamental C compiler thing.

You are right, after thinking about it I came to the same conclusion.
I will send an updated patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 10:26:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 10:26:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RroRV-0000jc-0a; Mon, 30 Jan 2012 10:26:33 +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 1RroRT-0000jP-Dw
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 10:26:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327919184!12683303!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11546 invoked from network); 30 Jan 2012 10:26:25 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-5.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 10:26:25 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327919184; l=578;
	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=BMqQBXgeD0dN282VmHkGwUd67Sk=;
	b=Q+Bgjqsmalqp6yDhAywgJAAfa3I+aefZ5GPqf3Lkme5dEpC28ikOQc7PKoL1sOvYoF3
	zRTFncxtbQnNhEpUXIqa3Ve/eGAdRpEAsRBaRluPHn3f7vFFVhJDuOMvx7y0uidFWW2iT
	th0RL4//N8w71bLEho0GUpUc35b0pJZMLl4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (fruni mo16) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L03738o0U9TrKV ;
	Mon, 30 Jan 2012 11:26:17 +0100 (MET)
Received: by probook.site (Postfix, from userid 1000)
	id 0FE5718637; Mon, 30 Jan 2012 11:26:21 +0100 (CET)
Date: Mon, 30 Jan 2012 11:26:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: Keir Fraser <keir.xen@gmail.com>
Message-ID: <20120130102621.GB9935@aepfle.de>
References: <20120130091002.GA29543@aepfle.de>
	<CB4C13A9.29F65%keir.xen@gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CB4C13A9.29F65%keir.xen@gmail.com>
User-Agent: Mutt/1.5.21.rev5535 (2011-07-01)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] tools/libxc: make volatile keyword for
 bitmap operations optional
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, Keir Fraser wrote:

> On 30/01/2012 09:10, "Olaf Hering" <olaf@aepfle.de> wrote:
> > Will gcc use the right thing if the array is passed to the hyperviso,
> > and will it reload everything after the hypercall? If yes, the volatile
> > can indeed go.
> 
> Of course. Lots of things would fail to work if calls to outside the current
> linkage unit didn't flush/invalidate cached shared-data accesses. That's a
> fundamental C compiler thing.

You are right, after thinking about it I came to the same conclusion.
I will send an updated patch.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 10:37:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 10:37:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrobc-00012Q-4L; Mon, 30 Jan 2012 10:37:00 +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 1Rroba-00012L-Mo
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 10:36:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327919812!8753350!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8557 invoked from network); 30 Jan 2012 10:36:52 -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; 30 Jan 2012 10:36:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RrobT-000PgC-Ii; Mon, 30 Jan 2012 10:36:51 +0000
Date: Mon, 30 Jan 2012 10:36:51 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120130103651.GD96325@ocelot.phlegethon.org>
References: <ebc68ae15103061fa554.1327607777@probook.site>
	<20120130095129.GC96325@ocelot.phlegethon.org>
	<20120130102412.GA9935@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120130102412.GA9935@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: unify return value in nominate
	and 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

At 11:24 +0100 on 30 Jan (1327922652), Olaf Hering wrote:
> On Mon, Jan 30, Tim Deegan wrote:
> 
> > I don't think EAGAIN is the right thing to return here.  There's no
> > reason to think that retrying an invalid GFN will work next time. 
> > 
> > I'd be happy for these cases all to return the same code, but maybe
> > EINVAL would be a better choice. 
> 
> EINVAL is returned by upper layers already. I think both nominate and
> evict should return EBUSY in case of failure, this is most likely unique
> enough to mean "request reached target function, and failed.".

Fair enough; EBUSY will do.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 10:37:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 10:37:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrobc-00012Q-4L; Mon, 30 Jan 2012 10:37:00 +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 1Rroba-00012L-Mo
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 10:36:58 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-15.tower-21.messagelabs.com!1327919812!8753350!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8557 invoked from network); 30 Jan 2012 10:36:52 -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; 30 Jan 2012 10:36:52 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RrobT-000PgC-Ii; Mon, 30 Jan 2012 10:36:51 +0000
Date: Mon, 30 Jan 2012 10:36:51 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120130103651.GD96325@ocelot.phlegethon.org>
References: <ebc68ae15103061fa554.1327607777@probook.site>
	<20120130095129.GC96325@ocelot.phlegethon.org>
	<20120130102412.GA9935@aepfle.de>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20120130102412.GA9935@aepfle.de>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: unify return value in nominate
	and 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

At 11:24 +0100 on 30 Jan (1327922652), Olaf Hering wrote:
> On Mon, Jan 30, Tim Deegan wrote:
> 
> > I don't think EAGAIN is the right thing to return here.  There's no
> > reason to think that retrying an invalid GFN will work next time. 
> > 
> > I'd be happy for these cases all to return the same code, but maybe
> > EINVAL would be a better choice. 
> 
> EINVAL is returned by upper layers already. I think both nominate and
> evict should return EBUSY in case of failure, this is most likely unique
> enough to mean "request reached target function, and failed.".

Fair enough; EBUSY will do.

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:07:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11: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 1Rrp4L-0001TG-J8; Mon, 30 Jan 2012 11:06:41 +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 1Rrp4K-0001TB-EH
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:06:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327921538!58934008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15280 invoked from network); 30 Jan 2012 11:05:39 -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;
	30 Jan 2012 11:05:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10361206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:06:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:06:38 +0000
Date: Mon, 30 Jan 2012 11:08:08 +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: <1327702543-25211-20-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201301107180.3196@kaball-desktop>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327702543-25211-20-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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
	stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

This is exactly what I had in mind.
The patch looks good to me now.


> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/xenstore/Makefile           |   14 ++++-
>  tools/xenstore/utils.h            |    2 +
>  tools/xenstore/xenstored_core.c   |   88 ++++-----------------------------
>  tools/xenstore/xenstored_core.h   |   12 +++++
>  tools/xenstore/xenstored_domain.c |    2 +-
>  tools/xenstore/xenstored_minios.c |   60 ++++++++++++++++++++++
>  tools/xenstore/xenstored_posix.c  |   99 +++++++++++++++++++++++++++++++++++++
>  7 files changed, 195 insertions(+), 82 deletions(-)
>  create mode 100644 tools/xenstore/xenstored_minios.c
>  create mode 100644 tools/xenstore/xenstored_posix.c
> 
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 4facb62..e510b4f 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -13,9 +13,10 @@ CLIENTS += xenstore-write xenstore-ls xenstore-watch
>  
>  XENSTORED_OBJS = xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o
>  
> -XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o
> -XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_probes.o
> -XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o
> +XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o xenstored_posix.o
> +XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_posix.o xenstored_probes.o
> +XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o xenstored_posix.o
> +XENSTORED_OBJS_$(CONFIG_MiniOS) = xenstored_minios.o
>  
>  XENSTORED_OBJS += $(XENSTORED_OBJS_y)
>  
> @@ -28,6 +29,10 @@ endif
>  
>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>  
> +ifdef CONFIG_STUBDOM
> +CFLAGS += -DNO_SOCKETS=1
> +endif
> +
>  .PHONY: all
>  all: $(ALL_TARGETS)
>  
> @@ -49,6 +54,9 @@ endif
>  xenstored: $(XENSTORED_OBJS)
>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
> +xenstored.a: $(XENSTORED_OBJS)
> +	$(AR) cr $@ $^
> +
>  $(CLIENTS): xenstore
>  	ln -f xenstore $@
>  
> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
> index f378343..2effd17 100644
> --- a/tools/xenstore/utils.h
> +++ b/tools/xenstore/utils.h
> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>  	return streq(a + strlen(a) - strlen(b), b);
>  }
>  
> +#ifndef ARRAY_SIZE
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
>  
>  void barf(const char *fmt, ...) __attribute__((noreturn));
>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 4b12cf2..a762db7 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -224,7 +224,6 @@ static void reopen_log(void)
>  	}
>  }
>  
> -
>  static bool write_messages(struct connection *conn)
>  {
>  	int ret;
> @@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  		set_fd(sock, inset, &max);
>  	if (ro_sock != -1)
>  		set_fd(ro_sock, inset, &max);
> -	set_fd(reopen_log_pipe[0], inset, &max);
> +	if (reopen_log_pipe[0] != -1)
> +		set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1664,53 +1664,6 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
>  
>  
> -static void write_pidfile(const char *pidfile)
> -{
> -	char buf[100];
> -	int len;
> -	int fd;
> -
> -	fd = open(pidfile, O_RDWR | O_CREAT, 0600);
> -	if (fd == -1)
> -		barf_perror("Opening pid file %s", pidfile);
> -
> -	/* We exit silently if daemon already running. */
> -	if (lockf(fd, F_TLOCK, 0) == -1)
> -		exit(0);
> -
> -	len = snprintf(buf, sizeof(buf), "%ld\n", (long)getpid());
> -	if (write(fd, buf, len) != len)
> -		barf_perror("Writing pid file %s", pidfile);
> -}
> -
> -/* Stevens. */
> -static void daemonize(void)
> -{
> -	pid_t pid;
> -
> -	/* Separate from our parent via fork, so init inherits us. */
> -	if ((pid = fork()) < 0)
> -		barf_perror("Failed to fork daemon");
> -	if (pid != 0)
> -		exit(0);
> -
> -	/* Session leader so ^C doesn't whack us. */
> -	setsid();
> -
> -	/* Let session leader exit so child cannot regain CTTY */
> -	if ((pid = fork()) < 0)
> -		barf_perror("Failed to fork daemon");
> -	if (pid != 0)
> -		exit(0);
> -
> -	/* Move off any mount points we might be in. */
> -	if (chdir("/") == -1)
> -		barf_perror("Failed to chdir");
> -
> -	/* Discard our parent's old-fashioned umask prejudices. */
> -	umask(0);
> -}
> -
>  #ifdef NO_SOCKETS
>  static void init_sockets(int **psock, int **pro_sock)
>  {
> @@ -1874,20 +1827,10 @@ int main(int argc, char *argv[])
>  
>  	reopen_log();
>  
> -	/* make sure xenstored directory exists */
> -	if (mkdir(xs_daemon_rundir(), 0755)) {
> -		if (errno != EEXIST) {
> -			perror("error: mkdir daemon rundir");
> -			exit(-1);
> -		}
> -	}
> -
> -	if (mkdir(xs_daemon_rootdir(), 0755)) {
> -		if (errno != EEXIST) {
> -			perror("error: mkdir daemon rootdir");
> -			exit(-1);
> -		}
> -	}
> +	/* make sure xenstored directories exist */
> +	/* Errors ignored here, will be reported when we open files */
> +	mkdir(xs_daemon_rundir(), 0755);
> +	mkdir(xs_daemon_rootdir(), 0755);
>  
>  	if (dofork) {
>  		openlog("xenstored", 0, LOG_DAEMON);
> @@ -1904,10 +1847,7 @@ int main(int argc, char *argv[])
>  	signal(SIGPIPE, SIG_IGN);
>  
>  	init_sockets(&sock, &ro_sock);
> -
> -	if (pipe(reopen_log_pipe)) {
> -		barf_perror("pipe");
> -	}
> +	init_pipe(reopen_log_pipe);
>  
>  	/* Setup the database */
>  	setup_structure();
> @@ -1925,16 +1865,8 @@ int main(int argc, char *argv[])
>  	}
>  
>  	/* redirect to /dev/null now we're ready to accept connections */
> -	if (dofork) {
> -		int devnull = open("/dev/null", O_RDWR);
> -		if (devnull == -1)
> -			barf_perror("Could not open /dev/null\n");
> -		dup2(devnull, STDIN_FILENO);
> -		dup2(devnull, STDOUT_FILENO);
> -		dup2(devnull, STDERR_FILENO);
> -		close(devnull);
> -		xprintf = trace;
> -	}
> +	if (dofork)
> +		finish_daemonize();
>  
>  	signal(SIGHUP, trigger_reopen_log);
>  
> @@ -1957,7 +1889,7 @@ int main(int argc, char *argv[])
>  			barf_perror("Select failed");
>  		}
>  
> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>  			char c;
>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>  				barf_perror("read failed");
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index c487089..f074955 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -171,6 +171,7 @@ extern int event_fd;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> +void unmap_xenbus(void *interface);
>  
>  /* Return the event channel used by xenbus. */
>  evtchn_port_t xenbus_evtchn(void);
> @@ -178,6 +179,17 @@ evtchn_port_t xenbus_evtchn(void);
>  /* Tell the kernel xenstored is running. */
>  void xenbus_notify_running(void);
>  
> +/* Write out the pidfile */
> +void write_pidfile(const char *pidfile);
> +
> +/* Fork but do not close terminal FDs */
> +void daemonize(void);
> +/* Close stdin/stdout/stderr to complete daemonize */
> +void finish_daemonize(void);
> +
> +/* Open a pipe for signal handling */
> +void init_pipe(int reopen_log_pipe[2]);
> +
>  #endif /* _XENSTORED_CORE_H */
>  
>  /*
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index c521e52..6206961 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -200,7 +200,7 @@ static int destroy_domain(void *_domain)
>  		/* Domain 0 was mapped by dom0_init, so it must be unmapped
>  		   using munmap() and not the grant unmap call. */
>  		if (domain->domid == 0)
> -			munmap(domain->interface, getpagesize());
> +			unmap_xenbus(domain->interface);
>  		else
>  			unmap_interface(domain->interface);
>  	}
> diff --git a/tools/xenstore/xenstored_minios.c b/tools/xenstore/xenstored_minios.c
> new file mode 100644
> index 0000000..c8700ba
> --- /dev/null
> +++ b/tools/xenstore/xenstored_minios.c
> @@ -0,0 +1,60 @@
> +/* 
> +    Simple prototype Xen Store Daemon providing simple tree-like database.
> +    Copyright (C) 2005 Rusty Russell IBM 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
> +*/
> +#include <sys/types.h>
> +#include <sys/mman.h>
> +#include <xenctrl.h>
> +#include "xenstored_core.h"
> +#include <xen/grant_table.h>
> +
> +void write_pidfile(const char *pidfile)
> +{
> +}
> +
> +void daemonize(void)
> +{
> +}
> +
> +void finish_daemonize(void)
> +{
> +}
> +
> +void init_pipe(int reopen_log_pipe[2])
> +{
> +	reopen_log_pipe[0] = -1;
> +	reopen_log_pipe[1] = -1;
> +}
> +
> +void xenbus_notify_running(void)
> +{
> +}
> +
> +evtchn_port_t xenbus_evtchn(void)
> +{
> +	return -1;
> +}
> +
> +void *xenbus_map(void)
> +{
> +	return NULL;
> +}
> +
> +void unmap_xenbus(void *interface)
> +{
> +}
> +
> diff --git a/tools/xenstore/xenstored_posix.c b/tools/xenstore/xenstored_posix.c
> new file mode 100644
> index 0000000..25bdf74
> --- /dev/null
> +++ b/tools/xenstore/xenstored_posix.c
> @@ -0,0 +1,99 @@
> +/* 
> +    Simple prototype Xen Store Daemon providing simple tree-like database.
> +    Copyright (C) 2005 Rusty Russell IBM 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
> +*/
> +
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <unistd.h>
> +#include <fcntl.h>
> +#include <stdlib.h>
> +#include <sys/mman.h>
> +
> +#include "utils.h"
> +#include "xenstored_core.h"
> +
> +void write_pidfile(const char *pidfile)
> +{
> +	char buf[100];
> +	int len;
> +	int fd;
> +
> +	fd = open(pidfile, O_RDWR | O_CREAT, 0600);
> +	if (fd == -1)
> +		barf_perror("Opening pid file %s", pidfile);
> +
> +	/* We exit silently if daemon already running. */
> +	if (lockf(fd, F_TLOCK, 0) == -1)
> +		exit(0);
> +
> +	len = snprintf(buf, sizeof(buf), "%ld\n", (long)getpid());
> +	if (write(fd, buf, len) != len)
> +		barf_perror("Writing pid file %s", pidfile);
> +}
> +
> +/* Stevens. */
> +void daemonize(void)
> +{
> +	pid_t pid;
> +
> +	/* Separate from our parent via fork, so init inherits us. */
> +	if ((pid = fork()) < 0)
> +		barf_perror("Failed to fork daemon");
> +	if (pid != 0)
> +		exit(0);
> +
> +	/* Session leader so ^C doesn't whack us. */
> +	setsid();
> +
> +	/* Let session leader exit so child cannot regain CTTY */
> +	if ((pid = fork()) < 0)
> +		barf_perror("Failed to fork daemon");
> +	if (pid != 0)
> +		exit(0);
> +
> +	/* Move off any mount points we might be in. */
> +	if (chdir("/") == -1)
> +		barf_perror("Failed to chdir");
> +
> +	/* Discard our parent's old-fashioned umask prejudices. */
> +	umask(0);
> +}
> +
> +void finish_daemonize(void)
> +{
> +	int devnull = open("/dev/null", O_RDWR);
> +	if (devnull == -1)
> +		barf_perror("Could not open /dev/null\n");
> +	dup2(devnull, STDIN_FILENO);
> +	dup2(devnull, STDOUT_FILENO);
> +	dup2(devnull, STDERR_FILENO);
> +	close(devnull);
> +	xprintf = trace;
> +}
> +
> +void init_pipe(int reopen_log_pipe[2])
> +{
> +	if (pipe(reopen_log_pipe)) {
> +		barf_perror("pipe");
> +	}
> +}
> +
> +void unmap_xenbus(void *interface)
> +{
> +	munmap(interface, getpagesize());
> +}
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:07:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11: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 1Rrp4L-0001TG-J8; Mon, 30 Jan 2012 11:06:41 +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 1Rrp4K-0001TB-EH
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:06:40 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327921538!58934008!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15280 invoked from network); 30 Jan 2012 11:05:39 -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;
	30 Jan 2012 11:05:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10361206"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:06:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:06:38 +0000
Date: Mon, 30 Jan 2012 11:08:08 +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: <1327702543-25211-20-git-send-email-dgdegra@tycho.nsa.gov>
Message-ID: <alpine.DEB.2.00.1201301107180.3196@kaball-desktop>
References: <1327702543-25211-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327702543-25211-20-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>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 19/24] xenstored: support running in minios
	stubdom
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Daniel De Graaf wrote:
> A previous versions of this patch has been sent to xen-devel. See
> http://lists.xensource.com/archives/html/xen-devel/2009-03/msg01655.html

This is exactly what I had in mind.
The patch looks good to me now.


> Signed-off-by: Diego Ongaro <diego.ongaro@citrix.com>
> Signed-off-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/xenstore/Makefile           |   14 ++++-
>  tools/xenstore/utils.h            |    2 +
>  tools/xenstore/xenstored_core.c   |   88 ++++-----------------------------
>  tools/xenstore/xenstored_core.h   |   12 +++++
>  tools/xenstore/xenstored_domain.c |    2 +-
>  tools/xenstore/xenstored_minios.c |   60 ++++++++++++++++++++++
>  tools/xenstore/xenstored_posix.c  |   99 +++++++++++++++++++++++++++++++++++++
>  7 files changed, 195 insertions(+), 82 deletions(-)
>  create mode 100644 tools/xenstore/xenstored_minios.c
>  create mode 100644 tools/xenstore/xenstored_posix.c
> 
> diff --git a/tools/xenstore/Makefile b/tools/xenstore/Makefile
> index 4facb62..e510b4f 100644
> --- a/tools/xenstore/Makefile
> +++ b/tools/xenstore/Makefile
> @@ -13,9 +13,10 @@ CLIENTS += xenstore-write xenstore-ls xenstore-watch
>  
>  XENSTORED_OBJS = xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o
>  
> -XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o
> -XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_probes.o
> -XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o
> +XENSTORED_OBJS_$(CONFIG_Linux) = xenstored_linux.o xenstored_posix.o
> +XENSTORED_OBJS_$(CONFIG_SunOS) = xenstored_solaris.o xenstored_posix.o xenstored_probes.o
> +XENSTORED_OBJS_$(CONFIG_NetBSD) = xenstored_netbsd.o xenstored_posix.o
> +XENSTORED_OBJS_$(CONFIG_MiniOS) = xenstored_minios.o
>  
>  XENSTORED_OBJS += $(XENSTORED_OBJS_y)
>  
> @@ -28,6 +29,10 @@ endif
>  
>  ALL_TARGETS = libxenstore.so libxenstore.a clients xs_tdb_dump xenstored
>  
> +ifdef CONFIG_STUBDOM
> +CFLAGS += -DNO_SOCKETS=1
> +endif
> +
>  .PHONY: all
>  all: $(ALL_TARGETS)
>  
> @@ -49,6 +54,9 @@ endif
>  xenstored: $(XENSTORED_OBJS)
>  	$(CC) $(LDFLAGS) $^ $(LDLIBS_libxenctrl) $(SOCKET_LIBS) -o $@ $(APPEND_LDFLAGS)
>  
> +xenstored.a: $(XENSTORED_OBJS)
> +	$(AR) cr $@ $^
> +
>  $(CLIENTS): xenstore
>  	ln -f xenstore $@
>  
> diff --git a/tools/xenstore/utils.h b/tools/xenstore/utils.h
> index f378343..2effd17 100644
> --- a/tools/xenstore/utils.h
> +++ b/tools/xenstore/utils.h
> @@ -19,7 +19,9 @@ static inline bool strends(const char *a, const char *b)
>  	return streq(a + strlen(a) - strlen(b), b);
>  }
>  
> +#ifndef ARRAY_SIZE
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
>  
>  void barf(const char *fmt, ...) __attribute__((noreturn));
>  void barf_perror(const char *fmt, ...) __attribute__((noreturn));
> diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
> index 4b12cf2..a762db7 100644
> --- a/tools/xenstore/xenstored_core.c
> +++ b/tools/xenstore/xenstored_core.c
> @@ -224,7 +224,6 @@ static void reopen_log(void)
>  	}
>  }
>  
> -
>  static bool write_messages(struct connection *conn)
>  {
>  	int ret;
> @@ -327,7 +326,8 @@ static int initialize_set(fd_set *inset, fd_set *outset, int sock, int ro_sock,
>  		set_fd(sock, inset, &max);
>  	if (ro_sock != -1)
>  		set_fd(ro_sock, inset, &max);
> -	set_fd(reopen_log_pipe[0], inset, &max);
> +	if (reopen_log_pipe[0] != -1)
> +		set_fd(reopen_log_pipe[0], inset, &max);
>  
>  	if (xce_handle != NULL)
>  		set_fd(xc_evtchn_fd(xce_handle), inset, &max);
> @@ -1664,53 +1664,6 @@ static void corrupt(struct connection *conn, const char *fmt, ...)
>  }
>  
>  
> -static void write_pidfile(const char *pidfile)
> -{
> -	char buf[100];
> -	int len;
> -	int fd;
> -
> -	fd = open(pidfile, O_RDWR | O_CREAT, 0600);
> -	if (fd == -1)
> -		barf_perror("Opening pid file %s", pidfile);
> -
> -	/* We exit silently if daemon already running. */
> -	if (lockf(fd, F_TLOCK, 0) == -1)
> -		exit(0);
> -
> -	len = snprintf(buf, sizeof(buf), "%ld\n", (long)getpid());
> -	if (write(fd, buf, len) != len)
> -		barf_perror("Writing pid file %s", pidfile);
> -}
> -
> -/* Stevens. */
> -static void daemonize(void)
> -{
> -	pid_t pid;
> -
> -	/* Separate from our parent via fork, so init inherits us. */
> -	if ((pid = fork()) < 0)
> -		barf_perror("Failed to fork daemon");
> -	if (pid != 0)
> -		exit(0);
> -
> -	/* Session leader so ^C doesn't whack us. */
> -	setsid();
> -
> -	/* Let session leader exit so child cannot regain CTTY */
> -	if ((pid = fork()) < 0)
> -		barf_perror("Failed to fork daemon");
> -	if (pid != 0)
> -		exit(0);
> -
> -	/* Move off any mount points we might be in. */
> -	if (chdir("/") == -1)
> -		barf_perror("Failed to chdir");
> -
> -	/* Discard our parent's old-fashioned umask prejudices. */
> -	umask(0);
> -}
> -
>  #ifdef NO_SOCKETS
>  static void init_sockets(int **psock, int **pro_sock)
>  {
> @@ -1874,20 +1827,10 @@ int main(int argc, char *argv[])
>  
>  	reopen_log();
>  
> -	/* make sure xenstored directory exists */
> -	if (mkdir(xs_daemon_rundir(), 0755)) {
> -		if (errno != EEXIST) {
> -			perror("error: mkdir daemon rundir");
> -			exit(-1);
> -		}
> -	}
> -
> -	if (mkdir(xs_daemon_rootdir(), 0755)) {
> -		if (errno != EEXIST) {
> -			perror("error: mkdir daemon rootdir");
> -			exit(-1);
> -		}
> -	}
> +	/* make sure xenstored directories exist */
> +	/* Errors ignored here, will be reported when we open files */
> +	mkdir(xs_daemon_rundir(), 0755);
> +	mkdir(xs_daemon_rootdir(), 0755);
>  
>  	if (dofork) {
>  		openlog("xenstored", 0, LOG_DAEMON);
> @@ -1904,10 +1847,7 @@ int main(int argc, char *argv[])
>  	signal(SIGPIPE, SIG_IGN);
>  
>  	init_sockets(&sock, &ro_sock);
> -
> -	if (pipe(reopen_log_pipe)) {
> -		barf_perror("pipe");
> -	}
> +	init_pipe(reopen_log_pipe);
>  
>  	/* Setup the database */
>  	setup_structure();
> @@ -1925,16 +1865,8 @@ int main(int argc, char *argv[])
>  	}
>  
>  	/* redirect to /dev/null now we're ready to accept connections */
> -	if (dofork) {
> -		int devnull = open("/dev/null", O_RDWR);
> -		if (devnull == -1)
> -			barf_perror("Could not open /dev/null\n");
> -		dup2(devnull, STDIN_FILENO);
> -		dup2(devnull, STDOUT_FILENO);
> -		dup2(devnull, STDERR_FILENO);
> -		close(devnull);
> -		xprintf = trace;
> -	}
> +	if (dofork)
> +		finish_daemonize();
>  
>  	signal(SIGHUP, trigger_reopen_log);
>  
> @@ -1957,7 +1889,7 @@ int main(int argc, char *argv[])
>  			barf_perror("Select failed");
>  		}
>  
> -		if (FD_ISSET(reopen_log_pipe[0], &inset)) {
> +		if (reopen_log_pipe[0] != -1 && FD_ISSET(reopen_log_pipe[0], &inset)) {
>  			char c;
>  			if (read(reopen_log_pipe[0], &c, 1) != 1)
>  				barf_perror("read failed");
> diff --git a/tools/xenstore/xenstored_core.h b/tools/xenstore/xenstored_core.h
> index c487089..f074955 100644
> --- a/tools/xenstore/xenstored_core.h
> +++ b/tools/xenstore/xenstored_core.h
> @@ -171,6 +171,7 @@ extern int event_fd;
>  
>  /* Map the kernel's xenstore page. */
>  void *xenbus_map(void);
> +void unmap_xenbus(void *interface);
>  
>  /* Return the event channel used by xenbus. */
>  evtchn_port_t xenbus_evtchn(void);
> @@ -178,6 +179,17 @@ evtchn_port_t xenbus_evtchn(void);
>  /* Tell the kernel xenstored is running. */
>  void xenbus_notify_running(void);
>  
> +/* Write out the pidfile */
> +void write_pidfile(const char *pidfile);
> +
> +/* Fork but do not close terminal FDs */
> +void daemonize(void);
> +/* Close stdin/stdout/stderr to complete daemonize */
> +void finish_daemonize(void);
> +
> +/* Open a pipe for signal handling */
> +void init_pipe(int reopen_log_pipe[2]);
> +
>  #endif /* _XENSTORED_CORE_H */
>  
>  /*
> diff --git a/tools/xenstore/xenstored_domain.c b/tools/xenstore/xenstored_domain.c
> index c521e52..6206961 100644
> --- a/tools/xenstore/xenstored_domain.c
> +++ b/tools/xenstore/xenstored_domain.c
> @@ -200,7 +200,7 @@ static int destroy_domain(void *_domain)
>  		/* Domain 0 was mapped by dom0_init, so it must be unmapped
>  		   using munmap() and not the grant unmap call. */
>  		if (domain->domid == 0)
> -			munmap(domain->interface, getpagesize());
> +			unmap_xenbus(domain->interface);
>  		else
>  			unmap_interface(domain->interface);
>  	}
> diff --git a/tools/xenstore/xenstored_minios.c b/tools/xenstore/xenstored_minios.c
> new file mode 100644
> index 0000000..c8700ba
> --- /dev/null
> +++ b/tools/xenstore/xenstored_minios.c
> @@ -0,0 +1,60 @@
> +/* 
> +    Simple prototype Xen Store Daemon providing simple tree-like database.
> +    Copyright (C) 2005 Rusty Russell IBM 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
> +*/
> +#include <sys/types.h>
> +#include <sys/mman.h>
> +#include <xenctrl.h>
> +#include "xenstored_core.h"
> +#include <xen/grant_table.h>
> +
> +void write_pidfile(const char *pidfile)
> +{
> +}
> +
> +void daemonize(void)
> +{
> +}
> +
> +void finish_daemonize(void)
> +{
> +}
> +
> +void init_pipe(int reopen_log_pipe[2])
> +{
> +	reopen_log_pipe[0] = -1;
> +	reopen_log_pipe[1] = -1;
> +}
> +
> +void xenbus_notify_running(void)
> +{
> +}
> +
> +evtchn_port_t xenbus_evtchn(void)
> +{
> +	return -1;
> +}
> +
> +void *xenbus_map(void)
> +{
> +	return NULL;
> +}
> +
> +void unmap_xenbus(void *interface)
> +{
> +}
> +
> diff --git a/tools/xenstore/xenstored_posix.c b/tools/xenstore/xenstored_posix.c
> new file mode 100644
> index 0000000..25bdf74
> --- /dev/null
> +++ b/tools/xenstore/xenstored_posix.c
> @@ -0,0 +1,99 @@
> +/* 
> +    Simple prototype Xen Store Daemon providing simple tree-like database.
> +    Copyright (C) 2005 Rusty Russell IBM 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
> +*/
> +
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <unistd.h>
> +#include <fcntl.h>
> +#include <stdlib.h>
> +#include <sys/mman.h>
> +
> +#include "utils.h"
> +#include "xenstored_core.h"
> +
> +void write_pidfile(const char *pidfile)
> +{
> +	char buf[100];
> +	int len;
> +	int fd;
> +
> +	fd = open(pidfile, O_RDWR | O_CREAT, 0600);
> +	if (fd == -1)
> +		barf_perror("Opening pid file %s", pidfile);
> +
> +	/* We exit silently if daemon already running. */
> +	if (lockf(fd, F_TLOCK, 0) == -1)
> +		exit(0);
> +
> +	len = snprintf(buf, sizeof(buf), "%ld\n", (long)getpid());
> +	if (write(fd, buf, len) != len)
> +		barf_perror("Writing pid file %s", pidfile);
> +}
> +
> +/* Stevens. */
> +void daemonize(void)
> +{
> +	pid_t pid;
> +
> +	/* Separate from our parent via fork, so init inherits us. */
> +	if ((pid = fork()) < 0)
> +		barf_perror("Failed to fork daemon");
> +	if (pid != 0)
> +		exit(0);
> +
> +	/* Session leader so ^C doesn't whack us. */
> +	setsid();
> +
> +	/* Let session leader exit so child cannot regain CTTY */
> +	if ((pid = fork()) < 0)
> +		barf_perror("Failed to fork daemon");
> +	if (pid != 0)
> +		exit(0);
> +
> +	/* Move off any mount points we might be in. */
> +	if (chdir("/") == -1)
> +		barf_perror("Failed to chdir");
> +
> +	/* Discard our parent's old-fashioned umask prejudices. */
> +	umask(0);
> +}
> +
> +void finish_daemonize(void)
> +{
> +	int devnull = open("/dev/null", O_RDWR);
> +	if (devnull == -1)
> +		barf_perror("Could not open /dev/null\n");
> +	dup2(devnull, STDIN_FILENO);
> +	dup2(devnull, STDOUT_FILENO);
> +	dup2(devnull, STDERR_FILENO);
> +	close(devnull);
> +	xprintf = trace;
> +}
> +
> +void init_pipe(int reopen_log_pipe[2])
> +{
> +	if (pipe(reopen_log_pipe)) {
> +		barf_perror("pipe");
> +	}
> +}
> +
> +void unmap_xenbus(void *interface)
> +{
> +	munmap(interface, getpagesize());
> +}
> -- 
> 1.7.7.6
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:31:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11: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 1RrpRc-0001ti-U7; Mon, 30 Jan 2012 11:30:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RrpRa-0001td-VZ
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:30:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327923005!50300532!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6769 invoked from network); 30 Jan 2012 11:30:05 -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;
	30 Jan 2012 11:30:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:30: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; Mon, 30 Jan 2012 11:30:41 +0000
Date: Mon, 30 Jan 2012 11:32:11 +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: <CB495E98.29F01%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Paulian Bogdan Marinca <paulian@marinca.net>
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 28 Jan 2012, Keir Fraser wrote:
> On 27/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@marinca.net> wrote:
> 
> > I have a testing intel machine with 4 physical cpus running 64 bit Xen
> > 4.1.3-rc1.
> > 
> > I have a particular linux VM for which at its kernel boot time ( as
> > domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
> > console freezes indefinitely). The domU linux kernel is 3.2.1 and has
> > XEN compiled in.
> > 
> > Trying to find where the problem is, I found this: at the point where
> > XEN/Dom0 freezes, the physical cpus 0, 1 and 2 are executing the
> > idle_loop() from xen/arch/x86/domain.c and the cpu 3 spins
> > indefinitely in the
> 
> Thanks, the offending patch is xen-unstable:22409, I think. It needs an HVM
> guest which maps emulated IRQs onto event channels, but then has event
> channel notifications mapped onto an emulated IRQ (rather than 'direct
> vector delivery'). An unlikely state of affairs, maybe it's a temporary
> setup during guest boot, or maybe it indicates a bug in the guest as well.

That's right, this scenario should not be possible because whenever
XENFEAT_hvm_pirqs is available, XENFEAT_hvm_callback_vector should also
be available.
In any case I'll submit a patch to Linux to make sure this doesn't
happen, explicitly checking for xen_have_vector_callback.
What is your Linux kernel version? Could you please post your kernel
config as well?


> In any case, cc'ing the author, Stefano. This ought to be easy to fix. We
> could make the irq_lock a recursive lock for example.

We could also fail to map irqs into event channels if the delivery
method is not HVMIRQ_callback_vector:


diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index df92cc7..7d89ed6 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
 
     if ( domid == DOMID_SELF && is_hvm_domain(d) )
     {
+        if ( !is_hvm_pv_evtchn_domain(d) )
+        {
+            ret = -EINVAL;
+            goto free_domain;
+        }
         ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
         goto free_domain;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:31:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11: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 1RrpRc-0001ti-U7; Mon, 30 Jan 2012 11:30:44 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RrpRa-0001td-VZ
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:30:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1327923005!50300532!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6769 invoked from network); 30 Jan 2012 11:30:05 -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;
	30 Jan 2012 11:30:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362172"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:30: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; Mon, 30 Jan 2012 11:30:41 +0000
Date: Mon, 30 Jan 2012 11:32:11 +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: <CB495E98.29F01%keir.xen@gmail.com>
Message-ID: <alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Paulian Bogdan Marinca <paulian@marinca.net>
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/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, 28 Jan 2012, Keir Fraser wrote:
> On 27/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@marinca.net> wrote:
> 
> > I have a testing intel machine with 4 physical cpus running 64 bit Xen
> > 4.1.3-rc1.
> > 
> > I have a particular linux VM for which at its kernel boot time ( as
> > domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
> > console freezes indefinitely). The domU linux kernel is 3.2.1 and has
> > XEN compiled in.
> > 
> > Trying to find where the problem is, I found this: at the point where
> > XEN/Dom0 freezes, the physical cpus 0, 1 and 2 are executing the
> > idle_loop() from xen/arch/x86/domain.c and the cpu 3 spins
> > indefinitely in the
> 
> Thanks, the offending patch is xen-unstable:22409, I think. It needs an HVM
> guest which maps emulated IRQs onto event channels, but then has event
> channel notifications mapped onto an emulated IRQ (rather than 'direct
> vector delivery'). An unlikely state of affairs, maybe it's a temporary
> setup during guest boot, or maybe it indicates a bug in the guest as well.

That's right, this scenario should not be possible because whenever
XENFEAT_hvm_pirqs is available, XENFEAT_hvm_callback_vector should also
be available.
In any case I'll submit a patch to Linux to make sure this doesn't
happen, explicitly checking for xen_have_vector_callback.
What is your Linux kernel version? Could you please post your kernel
config as well?


> In any case, cc'ing the author, Stefano. This ought to be easy to fix. We
> could make the irq_lock a recursive lock for example.

We could also fail to map irqs into event channels if the delivery
method is not HVMIRQ_callback_vector:


diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index df92cc7..7d89ed6 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
 
     if ( domid == DOMID_SELF && is_hvm_domain(d) )
     {
+        if ( !is_hvm_pv_evtchn_domain(d) )
+        {
+            ret = -EINVAL;
+            goto free_domain;
+        }
         ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
         goto free_domain;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:38:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11:38:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrpYG-00022o-Od; Mon, 30 Jan 2012 11:37: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 1RrpYG-00022g-1e
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:37:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327923398!54570904!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6065 invoked from network); 30 Jan 2012 11:36:38 -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;
	30 Jan 2012 11:36:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:37:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:37:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RrpYB-0002e9-8B	for xen-devel@lists.xensource.com;
	Mon, 30 Jan 2012 11:37:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RrpYB-0008TI-68	for
	xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:37:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20262.33019.177690.451291@mariner.uk.xensource.com>
Date: Mon, 30 Jan 2012 11:37:31 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11728-mainreport@xen.org>
References: <osstest-11728-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11728: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11728: trouble: blocked/broken"):
> flight 11728 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11728/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-pvops             2 host-install(2)       broken REGR. vs. 11643
>  build-amd64-oldkern           2 host-install(2)       broken REGR. vs. 11643
>  build-amd64                   2 host-install(2)       broken REGR. vs. 11643
>  build-i386                    2 host-install(2)       broken REGR. vs. 11643
>  build-i386-pvops              2 host-install(2)       broken REGR. vs. 11643
>  build-i386-oldkern            2 host-install(2)       broken REGR. vs. 11643

This is due to Debian having updated debian-installer in a way that
makes it not install any more in our setup.  I'll investigate.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:38:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11:38:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrpYG-00022o-Od; Mon, 30 Jan 2012 11:37: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 1RrpYG-00022g-1e
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:37:36 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327923398!54570904!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6065 invoked from network); 30 Jan 2012 11:36:38 -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;
	30 Jan 2012 11:36:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362449"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:37:31 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:37:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RrpYB-0002e9-8B	for xen-devel@lists.xensource.com;
	Mon, 30 Jan 2012 11:37:31 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RrpYB-0008TI-68	for
	xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:37:31 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20262.33019.177690.451291@mariner.uk.xensource.com>
Date: Mon, 30 Jan 2012 11:37:31 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11728-mainreport@xen.org>
References: <osstest-11728-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11728: trouble: blocked/broken
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11728: trouble: blocked/broken"):
> flight 11728 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11728/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64-pvops             2 host-install(2)       broken REGR. vs. 11643
>  build-amd64-oldkern           2 host-install(2)       broken REGR. vs. 11643
>  build-amd64                   2 host-install(2)       broken REGR. vs. 11643
>  build-i386                    2 host-install(2)       broken REGR. vs. 11643
>  build-i386-pvops              2 host-install(2)       broken REGR. vs. 11643
>  build-i386-oldkern            2 host-install(2)       broken REGR. vs. 11643

This is due to Debian having updated debian-installer in a way that
makes it not install any more in our setup.  I'll investigate.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:38:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11:38:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrpYg-00024F-Q6; Mon, 30 Jan 2012 11:38:02 +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 1RrpYe-00023z-T5
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:38:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327923474!2759525!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21937 invoked from network); 30 Jan 2012 11:37:54 -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;
	30 Jan 2012 11:37:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:37:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:37:54 +0000
Date: Mon, 30 Jan 2012 11:39:24 +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: <4F22F687.40904@siemens.com>
Message-ID: <alpine.DEB.2.00.1201301132500.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22F687.40904@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/6] xen: do not initialize the interval
 timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Jan Kiszka wrote:
> On 2012-01-27 19:21, Stefano Stabellini wrote:
> > PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
> > this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  hw/pc.c |    7 +++++--
> >  1 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/pc.c b/hw/pc.c
> > index 85304cf..7a7ce98 100644
> > --- a/hw/pc.c
> > +++ b/hw/pc.c
> > @@ -43,6 +43,7 @@
> >  #include "ui/qemu-spice.h"
> >  #include "memory.h"
> >  #include "exec-memory.h"
> > +#include "arch_init.h"
> >  
> >  /* output Bochs bios info messages */
> >  //#define DEBUG_BIOS
> > @@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
> >      DriveInfo *fd[MAX_FD];
> >      qemu_irq rtc_irq = NULL;
> >      qemu_irq *a20_line;
> > -    ISADevice *i8042, *port92, *vmmouse, *pit;
> > +    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
> >      qemu_irq *cpu_exit_irq;
> >  
> >      register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
> > @@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
> >  
> >      qemu_register_boot_set(pc_boot_set, *rtc_state);
> >  
> > -    pit = pit_init(isa_bus, 0x40, 0);
> > +    if (!xen_available()) {
> > +        pit = pit_init(isa_bus, 0x40, 0);
> > +    }
> >      pcspk_init(pit);
> >  
> >      for(i = 0; i < MAX_SERIAL_PORTS; i++) {
> 
> Thus as guest accessing to port 0x61 will be able to crash qemu because
> pit is NULL? Or do you emulate that port in the kernel? If not, you
> likely want to move pcspk_init() under the same umbrella.

We already emulate both pit and port 0x61 in xen so a guest won't be
able to crash qemu that easily :)
But now that you make me think about it, it makes sense to move
pcspk_init under the same if, like you suggested.
Thanks,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:38:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11:38:22 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrpYg-00024F-Q6; Mon, 30 Jan 2012 11:38:02 +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 1RrpYe-00023z-T5
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:38:01 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327923474!2759525!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21937 invoked from network); 30 Jan 2012 11:37:54 -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;
	30 Jan 2012 11:37:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362463"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:37:54 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:37:54 +0000
Date: Mon, 30 Jan 2012 11:39:24 +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: <4F22F687.40904@siemens.com>
Message-ID: <alpine.DEB.2.00.1201301132500.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22F687.40904@siemens.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/6] xen: do not initialize the interval
 timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Jan Kiszka wrote:
> On 2012-01-27 19:21, Stefano Stabellini wrote:
> > PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
> > this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > ---
> >  hw/pc.c |    7 +++++--
> >  1 files changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/hw/pc.c b/hw/pc.c
> > index 85304cf..7a7ce98 100644
> > --- a/hw/pc.c
> > +++ b/hw/pc.c
> > @@ -43,6 +43,7 @@
> >  #include "ui/qemu-spice.h"
> >  #include "memory.h"
> >  #include "exec-memory.h"
> > +#include "arch_init.h"
> >  
> >  /* output Bochs bios info messages */
> >  //#define DEBUG_BIOS
> > @@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
> >      DriveInfo *fd[MAX_FD];
> >      qemu_irq rtc_irq = NULL;
> >      qemu_irq *a20_line;
> > -    ISADevice *i8042, *port92, *vmmouse, *pit;
> > +    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
> >      qemu_irq *cpu_exit_irq;
> >  
> >      register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
> > @@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
> >  
> >      qemu_register_boot_set(pc_boot_set, *rtc_state);
> >  
> > -    pit = pit_init(isa_bus, 0x40, 0);
> > +    if (!xen_available()) {
> > +        pit = pit_init(isa_bus, 0x40, 0);
> > +    }
> >      pcspk_init(pit);
> >  
> >      for(i = 0; i < MAX_SERIAL_PORTS; i++) {
> 
> Thus as guest accessing to port 0x61 will be able to crash qemu because
> pit is NULL? Or do you emulate that port in the kernel? If not, you
> likely want to move pcspk_init() under the same umbrella.

We already emulate both pit and port 0x61 in xen so a guest won't be
able to crash qemu that easily :)
But now that you make me think about it, it makes sense to move
pcspk_init under the same if, like you suggested.
Thanks,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:50:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11: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 1Rrpkh-0002Uq-BQ; Mon, 30 Jan 2012 11:50: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 1Rrpkg-0002Ul-En
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:50:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327924216!12699297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15619 invoked from network); 30 Jan 2012 11:50:20 -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;
	30 Jan 2012 11:50:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:50:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:50: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 1RrpkW-0002jR-1V;
	Mon, 30 Jan 2012 11:50:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrpkV-0003u7-VF;
	Mon, 30 Jan 2012 11:50:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11732-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 11:50:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11732: trouble: preparing/queued
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11732 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11732/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-i386-i386-pair             <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 build-amd64-pvops             2 host-install(2)          running [st=running!]
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 build-amd64-oldkern           1 hosts-allocate           running [st=running!]
 build-amd64                   1 hosts-allocate           running [st=running!]
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 build-i386                    1 hosts-allocate           running [st=running!]
 build-i386-pvops              1 hosts-allocate           running [st=running!]
 build-i386-oldkern            1 hosts-allocate           running [st=running!]
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued
 test-amd64-i386-xl-win-vcpus1    <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-amd64-i386-win             <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued

version targeted for testing:
 xen                  39df93acd408
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  preparing
 build-i386                                                   preparing
 build-amd64-oldkern                                          preparing
 build-i386-oldkern                                           preparing
 build-amd64-pvops                                            preparing
 build-i386-pvops                                             preparing
 test-amd64-amd64-xl                                          queued  
 test-amd64-i386-xl                                           queued  
 test-i386-i386-xl                                            queued  
 test-amd64-i386-rhel6hvm-amd                                 queued  
 test-amd64-amd64-xl-win7-amd64                               queued  
 test-amd64-i386-xl-win7-amd64                                queued  
 test-amd64-i386-xl-credit2                                   queued  
 test-amd64-amd64-xl-pcipt-intel                              queued  
 test-amd64-i386-rhel6hvm-intel                               queued  
 test-amd64-i386-xl-multivcpu                                 queued  
 test-amd64-amd64-pair                                        queued  
 test-amd64-i386-pair                                         queued  
 test-i386-i386-pair                                          queued  
 test-amd64-amd64-xl-sedf-pin                                 queued  
 test-amd64-amd64-pv                                          queued  
 test-amd64-i386-pv                                           queued  
 test-i386-i386-pv                                            queued  
 test-amd64-amd64-xl-sedf                                     queued  
 test-amd64-i386-win-vcpus1                                   queued  
 test-amd64-i386-xl-win-vcpus1                                queued  
 test-amd64-i386-xl-winxpsp3-vcpus1                           queued  
 test-amd64-amd64-win                                         queued  
 test-amd64-i386-win                                          queued  
 test-i386-i386-win                                           queued  
 test-amd64-amd64-xl-win                                      queued  
 test-i386-i386-xl-win                                        queued  
 test-amd64-i386-xend-winxpsp3                                queued  
 test-amd64-amd64-xl-winxpsp3                                 queued  
 test-i386-i386-xl-winxpsp3                                   queued  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 576 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 Jan 30 11:50:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11: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 1Rrpkh-0002Uq-BQ; Mon, 30 Jan 2012 11:50: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 1Rrpkg-0002Ul-En
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:50:26 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327924216!12699297!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15619 invoked from network); 30 Jan 2012 11:50:20 -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;
	30 Jan 2012 11:50:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362841"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:50:16 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:50: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 1RrpkW-0002jR-1V;
	Mon, 30 Jan 2012 11:50:16 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RrpkV-0003u7-VF;
	Mon, 30 Jan 2012 11:50:15 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11732-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 11:50:15 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-unstable test] 11732: trouble: preparing/queued
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11732 xen-unstable running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11732/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pcipt-intel    <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-amd64-amd64-pv             <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-amd64-xl-sedf        <none executed>              queued
 test-i386-i386-pair             <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-amd64-amd64-xl-sedf-pin    <none executed>              queued
 test-amd64-amd64-xl             <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 build-amd64-pvops             2 host-install(2)          running [st=running!]
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 build-amd64-oldkern           1 hosts-allocate           running [st=running!]
 build-amd64                   1 hosts-allocate           running [st=running!]
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 build-i386                    1 hosts-allocate           running [st=running!]
 build-i386-pvops              1 hosts-allocate           running [st=running!]
 build-i386-oldkern            1 hosts-allocate           running [st=running!]
 test-amd64-amd64-pair           <none executed>              queued
 test-amd64-amd64-xl-win7-amd64    <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 test-amd64-amd64-xl-win         <none executed>              queued
 test-i386-i386-xl-win           <none executed>              queued
 test-amd64-i386-xl-win-vcpus1    <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-amd64-i386-win             <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 test-amd64-amd64-win            <none executed>              queued
 test-amd64-amd64-xl-winxpsp3    <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued

version targeted for testing:
 xen                  39df93acd408
baseline version:
 xen                  e2722b24dc09

------------------------------------------------------------
People who touched revisions under test:
  Adin Scannell <adin@scannell.ca>
  Alex Zeffertt <alex.zeffertt@eu.citrix.com>
  Andres Lagar-Cavilla <andres@lagarcavilla.org>
  Andrew Cooper <andrew.cooper3@citrix.com>
  Daniel De Graaf <dgdegra@tycho.nsa.gov>
  Dario Faggioli <dario.faggioli@citrix.com>
  Diego Ongaro <diego.ongaro@citrix.com>
  Ian Campbell <ian.campbell@citrix.com>
  Ian Jackson <ian.jackson@eu.citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Jim Fehlig <jfehlig@suse.com>
  Keir Fraser <keir@xen.org>
  Olaf Hering <olaf@aepfle.de>
  Roger Pau Monne <roger.pau@entel.upc.edu>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Wei Wang <wei.wang2@amd.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  preparing
 build-i386                                                   preparing
 build-amd64-oldkern                                          preparing
 build-i386-oldkern                                           preparing
 build-amd64-pvops                                            preparing
 build-i386-pvops                                             preparing
 test-amd64-amd64-xl                                          queued  
 test-amd64-i386-xl                                           queued  
 test-i386-i386-xl                                            queued  
 test-amd64-i386-rhel6hvm-amd                                 queued  
 test-amd64-amd64-xl-win7-amd64                               queued  
 test-amd64-i386-xl-win7-amd64                                queued  
 test-amd64-i386-xl-credit2                                   queued  
 test-amd64-amd64-xl-pcipt-intel                              queued  
 test-amd64-i386-rhel6hvm-intel                               queued  
 test-amd64-i386-xl-multivcpu                                 queued  
 test-amd64-amd64-pair                                        queued  
 test-amd64-i386-pair                                         queued  
 test-i386-i386-pair                                          queued  
 test-amd64-amd64-xl-sedf-pin                                 queued  
 test-amd64-amd64-pv                                          queued  
 test-amd64-i386-pv                                           queued  
 test-i386-i386-pv                                            queued  
 test-amd64-amd64-xl-sedf                                     queued  
 test-amd64-i386-win-vcpus1                                   queued  
 test-amd64-i386-xl-win-vcpus1                                queued  
 test-amd64-i386-xl-winxpsp3-vcpus1                           queued  
 test-amd64-amd64-win                                         queued  
 test-amd64-i386-win                                          queued  
 test-i386-i386-win                                           queued  
 test-amd64-amd64-xl-win                                      queued  
 test-i386-i386-xl-win                                        queued  
 test-amd64-i386-xend-winxpsp3                                queued  
 test-amd64-amd64-xl-winxpsp3                                 queued  
 test-i386-i386-xl-winxpsp3                                   queued  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 576 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 Jan 30 11:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11: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 1Rrpl7-0002YC-PQ; Mon, 30 Jan 2012 11:50:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rrpl6-0002Wr-Hm
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:50:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327924246!12670402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 668 invoked from network); 30 Jan 2012 11:50:46 -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;
	30 Jan 2012 11:50:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:50:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:50: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 1Rrpkz-0002jh-Tp;
	Mon, 30 Jan 2012 11:50:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rrpkz-0007pD-Po;
	Mon, 30 Jan 2012 11:50:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11730-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 11:50:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11730: regressions - trouble:
	blocked/broken/preparing/queued
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11730 linux running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11730/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 test-i386-i386-pair             <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-amd64-i386-xl-win-vcpus1    <none executed>              queued
 test-amd64-i386-win             <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 build-i386                    2 host-install(2)          running [st=running!]
 test-i386-i386-xl-win           <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-amd64-i386-xl-credit2    7 debian-install   fail in 11669 REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 build-i386-pvops              2 host-install(2)           broken pass in 11669
 build-amd64                   2 host-install(2)           broken pass in 11708
 build-amd64-pvops             2 host-install(2)           broken pass in 11708
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-pv           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-win       3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-win          3 host-install(3)  broken in 11708 pass in 11669
 build-i386                    2 host-install(2)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 11708 pass in 11669

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2   fail in 11669 blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      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-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-pcipt-intel  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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11669 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11669 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11669 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11669 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11669 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11669 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11669 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11669 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11669 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11669 never pass
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)        blocked in 11708 n/a
 test-i386-i386-xl             1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-pv            1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl            1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)      blocked in 11708 n/a
 test-i386-i386-pv             1 xen-build-check(1)        blocked in 11708 n/a
 test-i386-i386-pair           1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-pair          1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)       blocked in 11708 n/a
 test-amd64-i386-win           1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)       blocked in 11708 n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)        blocked in 11708 n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)  blocked in 11708 n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)       blocked in 11708 n/a
 test-i386-i386-xl-win         1 xen-build-check(1)        blocked in 11708 n/a
 test-i386-i386-win            1 xen-build-check(1)        blocked in 11708 n/a

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   preparing
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           queued  
 test-i386-i386-xl                                            queued  
 test-amd64-i386-rhel6hvm-amd                                 queued  
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                queued  
 test-amd64-i386-xl-credit2                                   queued  
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               queued  
 test-amd64-i386-xl-multivcpu                                 queued  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         queued  
 test-i386-i386-pair                                          queued  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           queued  
 test-i386-i386-pv                                            queued  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   queued  
 test-amd64-i386-xl-win-vcpus1                                queued  
 test-amd64-i386-xl-winxpsp3-vcpus1                           queued  
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          queued  
 test-i386-i386-win                                           queued  
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        queued  
 test-amd64-i386-xend-winxpsp3                                queued  
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   queued  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11: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 1Rrpl7-0002YC-PQ; Mon, 30 Jan 2012 11:50:53 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rrpl6-0002Wr-Hm
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:50:52 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327924246!12670402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 668 invoked from network); 30 Jan 2012 11:50:46 -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;
	30 Jan 2012 11:50:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362856"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:50:46 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:50: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 1Rrpkz-0002jh-Tp;
	Mon, 30 Jan 2012 11:50:45 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1Rrpkz-0007pD-Po;
	Mon, 30 Jan 2012 11:50:45 +0000
To: <xen-devel@lists.xensource.com>
Message-ID: <osstest-11730-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 11:50:45 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [linux test] 11730: regressions - trouble:
	blocked/broken/preparing/queued
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

flight 11730 linux running [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11730/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rhel6hvm-amd    <none executed>              queued
 test-amd64-i386-xl-multivcpu    <none executed>              queued
 test-i386-i386-xl               <none executed>              queued
 test-amd64-i386-pv              <none executed>              queued
 test-amd64-i386-xl              <none executed>              queued
 test-amd64-i386-xl-credit2      <none executed>              queued
 test-amd64-i386-rhel6hvm-intel    <none executed>              queued
 test-i386-i386-pv               <none executed>              queued
 test-i386-i386-pair             <none executed>              queued
 test-amd64-i386-pair            <none executed>              queued
 test-amd64-i386-xl-win-vcpus1    <none executed>              queued
 test-amd64-i386-win             <none executed>              queued
 test-amd64-i386-xl-win7-amd64    <none executed>              queued
 test-amd64-i386-win-vcpus1      <none executed>              queued
 test-i386-i386-xl-winxpsp3      <none executed>              queued
 test-amd64-i386-xl-winxpsp3-vcpus1    <none executed>              queued
 test-amd64-i386-xend-winxpsp3    <none executed>              queued
 build-i386                    2 host-install(2)          running [st=running!]
 test-i386-i386-xl-win           <none executed>              queued
 test-i386-i386-win              <none executed>              queued
 test-amd64-i386-xl-credit2    7 debian-install   fail in 11669 REGR. vs. 10764

Tests which are failing intermittently (not blocking):
 build-i386-pvops              2 host-install(2)           broken pass in 11669
 build-amd64                   2 host-install(2)           broken pass in 11708
 build-amd64-pvops             2 host-install(2)           broken pass in 11708
 test-amd64-amd64-xl-winxpsp3  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf      3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-sedf-pin  3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-pv           3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-win       3 host-install(3)  broken in 11708 pass in 11669
 test-amd64-amd64-win          3 host-install(3)  broken in 11708 pass in 11669
 build-i386                    2 host-install(2)  broken in 11708 pass in 11669
 test-amd64-amd64-xl-pcipt-intel 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-xl-win7-amd64 3 host-install(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 11708 pass in 11669
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 11708 pass in 11669

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2   fail in 11669 blocked in 10764

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-winxpsp3  1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl           1 xen-build-check(1)           blocked  n/a
 test-amd64-amd64-xl-sedf      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-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-pcipt-intel  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-pair         1 xen-build-check(1)           blocked  n/a
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check      fail in 11669 never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check    fail in 11669 never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win          16 leak-check/check      fail in 11669 never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop           fail in 11669 never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check      fail in 11669 never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop      fail in 11669 never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop            fail in 11669 never pass
 test-amd64-amd64-xl-win      13 guest-stop            fail in 11669 never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check     fail in 11669 never pass
 test-amd64-amd64-win         16 leak-check/check      fail in 11669 never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start        fail in 11669 never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop          fail in 11669 never pass
 test-i386-i386-xl-win        13 guest-stop            fail in 11669 never pass
 test-amd64-i386-rhel6hvm-amd  1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-multivcpu  1 xen-build-check(1)        blocked in 11708 n/a
 test-i386-i386-xl             1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-pv            1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl            1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-credit2    1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-rhel6hvm-intel  1 xen-build-check(1)      blocked in 11708 n/a
 test-i386-i386-pv             1 xen-build-check(1)        blocked in 11708 n/a
 test-i386-i386-pair           1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-pair          1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-win-vcpus1  1 xen-build-check(1)       blocked in 11708 n/a
 test-amd64-i386-win           1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-win7-amd64  1 xen-build-check(1)       blocked in 11708 n/a
 test-amd64-i386-win-vcpus1    1 xen-build-check(1)        blocked in 11708 n/a
 test-i386-i386-xl-winxpsp3    1 xen-build-check(1)        blocked in 11708 n/a
 test-amd64-i386-xl-winxpsp3-vcpus1  1 xen-build-check(1)  blocked in 11708 n/a
 test-amd64-i386-xend-winxpsp3  1 xen-build-check(1)       blocked in 11708 n/a
 test-i386-i386-xl-win         1 xen-build-check(1)        blocked in 11708 n/a
 test-i386-i386-win            1 xen-build-check(1)        blocked in 11708 n/a

version targeted for testing:
 linux                1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
baseline version:
 linux                8664c694e49d4d095706524a27b1fc734b9881ce

------------------------------------------------------------
People who touched revisions under test:
------------------------------------------------------------

jobs:
 build-amd64                                                  broken  
 build-i386                                                   preparing
 build-amd64-pvops                                            broken  
 build-i386-pvops                                             broken  
 test-amd64-amd64-xl                                          blocked 
 test-amd64-i386-xl                                           queued  
 test-i386-i386-xl                                            queued  
 test-amd64-i386-rhel6hvm-amd                                 queued  
 test-amd64-amd64-xl-win7-amd64                               blocked 
 test-amd64-i386-xl-win7-amd64                                queued  
 test-amd64-i386-xl-credit2                                   queued  
 test-amd64-amd64-xl-pcipt-intel                              blocked 
 test-amd64-i386-rhel6hvm-intel                               queued  
 test-amd64-i386-xl-multivcpu                                 queued  
 test-amd64-amd64-pair                                        blocked 
 test-amd64-i386-pair                                         queued  
 test-i386-i386-pair                                          queued  
 test-amd64-amd64-xl-sedf-pin                                 blocked 
 test-amd64-amd64-pv                                          blocked 
 test-amd64-i386-pv                                           queued  
 test-i386-i386-pv                                            queued  
 test-amd64-amd64-xl-sedf                                     blocked 
 test-amd64-i386-win-vcpus1                                   queued  
 test-amd64-i386-xl-win-vcpus1                                queued  
 test-amd64-i386-xl-winxpsp3-vcpus1                           queued  
 test-amd64-amd64-win                                         blocked 
 test-amd64-i386-win                                          queued  
 test-i386-i386-win                                           queued  
 test-amd64-amd64-xl-win                                      blocked 
 test-i386-i386-xl-win                                        queued  
 test-amd64-i386-xend-winxpsp3                                queued  
 test-amd64-amd64-xl-winxpsp3                                 blocked 
 test-i386-i386-xl-winxpsp3                                   queued  


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit 1aaf53ee291d9e71d6ec05c0ebdb2854fea175ad
Merge: 8664c69... b16a92f...
Author: Jeremy Fitzhardinge <jeremy@goop.org>
Date:   Thu Jan 26 13:19:51 2012 -0800

    Merge commit 'v2.6.32.55' into xen/next-2.6.32
    
    * commit 'v2.6.32.55': (28 commits)
      Linux 2.6.32.55
      kprobes: initialize before using a hlist
      score: fix off-by-one index into syscall table
      sym53c8xx: Fix NULL pointer dereference in slave_destroy
      ALSA: HDA: Fix internal microphone on Dell Studio 16 XPS 1645
      kernel.h: add printk_ratelimited and pr_<level>_rl
      block: add and use scsi_blk_cmd_ioctl
      USB: Fix 'bad dma' problem on WDM device disconnect
      fix cputime overflow in uptime_proc_show
      USB: cdc-wdm: fix misuse of logical operation in place of bitop
      nfsd: Fix oops when parsing a 0 length export
      svcrpc: destroy server sockets all at once
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode
      V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()
      i2c: Fix error value returned by several bus drivers
      UBI: fix nameless volumes handling
      x86: Fix mmap random address range
      PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB
      ima: free duplicate measurement memory
      xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.
      ...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:55:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrppC-0002qy-Lf; Mon, 30 Jan 2012 11:55:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RrppA-0002qQ-Hr
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:55:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327924498!9334077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4856 invoked from network); 30 Jan 2012 11:54:58 -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;
	30 Jan 2012 11:54:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:54:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:54:58 +0000
Date: Mon, 30 Jan 2012 11:56:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <jfud2p$h6$1@dough.gmane.org>
Message-ID: <alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<jfud2p$h6$1@dough.gmane.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
> > has its own RTC emulator in the hypervisor so we can disable it.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > ---
> >   xen-all.c |    1 +
> >   1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/xen-all.c b/xen-all.c
> > index d1fc597..bf183f7 100644
> > --- a/xen-all.c
> > +++ b/xen-all.c
> > @@ -513,6 +513,7 @@ void xen_vcpu_init(void)
> >           qemu_register_reset(xen_reset_vcpu, first_cpu);
> >           xen_reset_vcpu(first_cpu);
> >       }
> > +    qemu_clock_enable(rtc_clock, false);
> >   }
> >
> >   /* get the ioreq packets from share mem */
> 
> Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.

Good point.
I should check for rtc_clock == host_clock.


> Why do you need to instantiate an RTC at all?

I don't, in fact in previous versions of this patch series I tried to do
that but it is difficult and makes the common code worse, so I followed
Anthony's suggestion of just disabling the rtc_clock.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:55:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11:55:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrppC-0002qy-Lf; Mon, 30 Jan 2012 11:55:06 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RrppA-0002qQ-Hr
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:55:04 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-21.messagelabs.com!1327924498!9334077!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4856 invoked from network); 30 Jan 2012 11:54:58 -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;
	30 Jan 2012 11:54:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10362971"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:54:58 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:54:58 +0000
Date: Mon, 30 Jan 2012 11:56:28 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <jfud2p$h6$1@dough.gmane.org>
Message-ID: <alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<jfud2p$h6$1@dough.gmane.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 01:26 PM, Stefano Stabellini wrote:
> > rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
> > has its own RTC emulator in the hypervisor so we can disable it.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > ---
> >   xen-all.c |    1 +
> >   1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/xen-all.c b/xen-all.c
> > index d1fc597..bf183f7 100644
> > --- a/xen-all.c
> > +++ b/xen-all.c
> > @@ -513,6 +513,7 @@ void xen_vcpu_init(void)
> >           qemu_register_reset(xen_reset_vcpu, first_cpu);
> >           xen_reset_vcpu(first_cpu);
> >       }
> > +    qemu_clock_enable(rtc_clock, false);
> >   }
> >
> >   /* get the ioreq packets from share mem */
> 
> Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.

Good point.
I should check for rtc_clock == host_clock.


> Why do you need to instantiate an RTC at all?

I don't, in fact in previous versions of this patch series I tried to do
that but it is difficult and makes the common code worse, so I followed
Anthony's suggestion of just disabling the rtc_clock.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:57:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrpr2-0002yM-5w; Mon, 30 Jan 2012 11:57:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rrpr0-0002yG-2u
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:56:58 +0000
Received: from [85.158.138.51:20053] by server-10.bemta-3.messagelabs.com id
	8E/28-20948-985862F4; Mon, 30 Jan 2012 11:56:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327924616!11228029!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19655 invoked from network); 30 Jan 2012 11:56:57 -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;
	30 Jan 2012 11:56:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10363027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11: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; Mon, 30 Jan 2012 11:56:56 +0000
Date: Mon, 30 Jan 2012 11:58:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F23044C.3070209@redhat.com>
Message-ID: <alpine.DEB.2.00.1201301156550.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F23044C.3070209@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 07:21 PM, Stefano Stabellini wrote:
> > rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
> > has its own RTC emulator in the hypervisor so we can disable it.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > ---
> >   xen-all.c |    1 +
> >   1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/xen-all.c b/xen-all.c
> > index d1fc597..bf183f7 100644
> > --- a/xen-all.c
> > +++ b/xen-all.c
> > @@ -513,6 +513,7 @@ void xen_vcpu_init(void)
> >           qemu_register_reset(xen_reset_vcpu, first_cpu);
> >           xen_reset_vcpu(first_cpu);
> >       }
> > +    qemu_clock_enable(rtc_clock, false);
> >   }
> >
> >   /* get the ioreq packets from share mem */
> 
> I explained why this is wrong.
 
Thanks for reminding me, I lost your previous email as I wasn't CC'ed...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 11:57:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 11:57:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrpr2-0002yM-5w; Mon, 30 Jan 2012 11:57:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rrpr0-0002yG-2u
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 11:56:58 +0000
Received: from [85.158.138.51:20053] by server-10.bemta-3.messagelabs.com id
	8E/28-20948-985862F4; Mon, 30 Jan 2012 11:56:57 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327924616!11228029!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19655 invoked from network); 30 Jan 2012 11:56:57 -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;
	30 Jan 2012 11:56:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="10363027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11: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; Mon, 30 Jan 2012 11:56:56 +0000
Date: Mon, 30 Jan 2012 11:58:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F23044C.3070209@redhat.com>
Message-ID: <alpine.DEB.2.00.1201301156550.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F23044C.3070209@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "avi@redhat.com" <avi@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Paolo Bonzini wrote:
> On 01/27/2012 07:21 PM, Stefano Stabellini wrote:
> > rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
> > has its own RTC emulator in the hypervisor so we can disable it.
> >
> > Signed-off-by: Stefano Stabellini<stefano.stabellini@eu.citrix.com>
> > ---
> >   xen-all.c |    1 +
> >   1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/xen-all.c b/xen-all.c
> > index d1fc597..bf183f7 100644
> > --- a/xen-all.c
> > +++ b/xen-all.c
> > @@ -513,6 +513,7 @@ void xen_vcpu_init(void)
> >           qemu_register_reset(xen_reset_vcpu, first_cpu);
> >           xen_reset_vcpu(first_cpu);
> >       }
> > +    qemu_clock_enable(rtc_clock, false);
> >   }
> >
> >   /* get the ioreq packets from share mem */
> 
> I explained why this is wrong.
 
Thanks for reminding me, I lost your previous email as I wasn't CC'ed...

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 12:00:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 12: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 1Rrpu1-0003AV-RQ; Mon, 30 Jan 2012 12:00:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Rrptw-00038M-0f
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 12:00:00 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327924793!2763722!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20469 invoked from network); 30 Jan 2012 11:59:53 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	30 Jan 2012 11:59:53 -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 q0UBxoLC021318
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 06:59:50 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-20.ams2.redhat.com
	[10.36.112.20])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0UBxlCp013762; Mon, 30 Jan 2012 06:59:48 -0500
Message-ID: <4F268632.8040801@redhat.com>
Date: Mon, 30 Jan 2012 12:59:46 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<jfud2p$h6$1@dough.gmane.org>
	<alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/30/2012 12:56 PM, Stefano Stabellini wrote:
>> >  Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.
>
> Good point.
> I should check for rtc_clock == host_clock.
>
>> >  Why do you need to instantiate an RTC at all?
> I don't, in fact in previous versions of this patch series I tried to do
> that but it is difficult and makes the common code worse, so I followed
> Anthony's suggestion of just disabling the rtc_clock.

I see.  It shouldn't surprise you that I completely disagree with 
Anthony on this. :)

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 12:00:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 12: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 1Rrpu1-0003AV-RQ; Mon, 30 Jan 2012 12:00:05 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <pbonzini@redhat.com>) id 1Rrptw-00038M-0f
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 12:00:00 +0000
X-Env-Sender: pbonzini@redhat.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327924793!2763722!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE0NDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20469 invoked from network); 30 Jan 2012 11:59:53 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-9.tower-21.messagelabs.com with SMTP;
	30 Jan 2012 11:59:53 -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 q0UBxoLC021318
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 06:59:50 -0500
Received: from yakj.usersys.redhat.com (ovpn-112-20.ams2.redhat.com
	[10.36.112.20])
	by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0UBxlCp013762; Mon, 30 Jan 2012 06:59:48 -0500
Message-ID: <4F268632.8040801@redhat.com>
Date: Mon, 30 Jan 2012 12:59:46 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<jfud2p$h6$1@dough.gmane.org>
	<alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/30/2012 12:56 PM, Stefano Stabellini wrote:
>> >  Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.
>
> Good point.
> I should check for rtc_clock == host_clock.
>
>> >  Why do you need to instantiate an RTC at all?
> I don't, in fact in previous versions of this patch series I tried to do
> that but it is difficult and makes the common code worse, so I followed
> Anthony's suggestion of just disabling the rtc_clock.

I see.  It shouldn't surprise you that I completely disagree with 
Anthony on this. :)

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 12:07:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 12: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 1Rrq1C-0003X4-Rq; Mon, 30 Jan 2012 12:07: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 1Rrq1B-0003Wz-Iu
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 12:07:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327925242!13119640!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19463 invoked from network); 30 Jan 2012 12:07:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 12:07:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327925242; l=1928;
	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=Njm4siI56QJLeq+N4JL1x2AC4OQ=;
	b=aiyyQYGcVYERSHVrV8PIdIdmV/TVqNsxdiB8fG8b05batrCrtnxHXJJzHE2tfdHsEyR
	KAg8HVGYkku0CMSZN9z23Z/3tuka9U+FA0FkgU7XNGIyluA2PHQvqC4E/GaWbP0Ydr4Xy
	dJrtz9ritB3mj0zodB+QDQOCZ5DtRwau3mg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo13) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y0375eo0UBZrjV
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:07:17 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 017BB18634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:07:21 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 17e25c8b6045cd7246e4ee5e914efba6f44a26fd
Message-Id: <17e25c8b6045cd7246e4.1327925241@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 13:07:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: unify return value in nominate and
	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 1327925194 -3600
# Node ID 17e25c8b6045cd7246e4ee5e914efba6f44a26fd
# Parent  2577131785ab86c95e6631a01bff04c664eac876
xenpaging: unify return value in nominate and evict

Let p2m_mem_paging_nominate and p2m_mem_paging_evict return just one
error number. EINVAL is not very helpful in case of nominate, it can
happen if the pager tries to nominate a ballooned page. In this case the
gfn is not backed by a mfn, the pager can not know that.  Similar with
evict, anything can happen between nominate and evict.

This change helps the pager to decide if the returned error is from the
function itself, or if it happend earlier. In the latter case, it is
most likely fatal and should be handled as such.
nominate and evict return EBUSY, which is supposed to mean
"pager request reached target function, and failed."

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2577131785ab -r 17e25c8b6045 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 = -EBUSY;
 
     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)) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 12:07:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 12: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 1Rrq1C-0003X4-Rq; Mon, 30 Jan 2012 12:07: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 1Rrq1B-0003Wz-Iu
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 12:07:29 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327925242!13119640!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19463 invoked from network); 30 Jan 2012 12:07:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-4.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 12:07:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327925242; l=1928;
	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=Njm4siI56QJLeq+N4JL1x2AC4OQ=;
	b=aiyyQYGcVYERSHVrV8PIdIdmV/TVqNsxdiB8fG8b05batrCrtnxHXJJzHE2tfdHsEyR
	KAg8HVGYkku0CMSZN9z23Z/3tuka9U+FA0FkgU7XNGIyluA2PHQvqC4E/GaWbP0Ydr4Xy
	dJrtz9ritB3mj0zodB+QDQOCZ5DtRwau3mg=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo13) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id y0375eo0UBZrjV
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:07:17 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 017BB18634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:07:21 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 17e25c8b6045cd7246e4ee5e914efba6f44a26fd
Message-Id: <17e25c8b6045cd7246e4.1327925241@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 13:07:21 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] xenpaging: unify return value in nominate and
	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 1327925194 -3600
# Node ID 17e25c8b6045cd7246e4ee5e914efba6f44a26fd
# Parent  2577131785ab86c95e6631a01bff04c664eac876
xenpaging: unify return value in nominate and evict

Let p2m_mem_paging_nominate and p2m_mem_paging_evict return just one
error number. EINVAL is not very helpful in case of nominate, it can
happen if the pager tries to nominate a ballooned page. In this case the
gfn is not backed by a mfn, the pager can not know that.  Similar with
evict, anything can happen between nominate and evict.

This change helps the pager to decide if the returned error is from the
function itself, or if it happend earlier. In the latter case, it is
most likely fatal and should be handled as such.
nominate and evict return EBUSY, which is supposed to mean
"pager request reached target function, and failed."

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2577131785ab -r 17e25c8b6045 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 = -EBUSY;
 
     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)) )

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 12:13:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 12:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrq6N-0003fb-Kl; Mon, 30 Jan 2012 12:12:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rrq6L-0003fW-PD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 12:12:50 +0000
Received: from [85.158.138.51:38965] by server-6.bemta-3.messagelabs.com id
	89/DA-31032-049862F4; Mon, 30 Jan 2012 12:12:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327925567!9376888!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20574 invoked from network); 30 Jan 2012 12:12:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 12:12:47 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327925567; l=1818;
	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=TTuqFTGsyWKWN4pI1k+zdbag+Ig=;
	b=n+GkojzjjjXc7RJ5oa9mmV1oqHqT5ReKP1MOqMuSQ4fjRjLgxeNKQhNzxdFM3ChGXfz
	RXVlYPpuq3c96JwrpbObaTN0Fi6TESFAJrukYSnAcDQCKR7ICkECOA1jfBv6hDX0Atd4n
	uMD+4iP3pwJ6zOOQc0itr7Mr8Mkkqzfq10M=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (klopstock mo1) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e073e1o0UBJ5Xa
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:12:33 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3BEA718634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:12:38 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 686f053d460da35f26b42b74e2ef41b6aceb5711
Message-Id: <686f053d460da35f26b4.1327925557@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 13:12:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: remove volatile keyword for bitmap
	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 Olaf Hering <olaf@aepfle.de>
# Date 1327925537 -3600
# Node ID 686f053d460da35f26b42b74e2ef41b6aceb5711
# Parent  4374739bd1428aead1c7f49beac6a28031c8d20b
tools/libxc: remove volatile keyword for bitmap operations

All bitmaps maintained by xc_bitops.h are used in single threaded
applications. So nothing will change the bitmaps content, adding
volatile adds just unneeded memory reloads.

xenpaging uses bitmaps alot and using non-volatile versions will slightly
improve performance.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4374739bd142 -r 686f053d460d tools/libxc/xc_bitops.h
--- a/tools/libxc/xc_bitops.h
+++ b/tools/libxc/xc_bitops.h
@@ -31,29 +31,29 @@ static inline void bitmap_clear(unsigned
     memset(addr, 0, bitmap_size(nr_bits));
 }
 
-static inline int test_bit(int nr, volatile unsigned long *addr)
+static inline int test_bit(int nr, unsigned long *addr)
 {
     return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;
 }
 
-static inline void clear_bit(int nr, volatile unsigned long *addr)
+static inline void clear_bit(int nr, unsigned long *addr)
 {
     BITMAP_ENTRY(nr, addr) &= ~(1UL << BITMAP_SHIFT(nr));
 }
 
-static inline void set_bit(int nr, volatile unsigned long *addr)
+static inline void set_bit(int nr, unsigned long *addr)
 {
     BITMAP_ENTRY(nr, addr) |= (1UL << BITMAP_SHIFT(nr));
 }
 
-static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_clear_bit(int nr, unsigned long *addr)
 {
     int oldbit = test_bit(nr, addr);
     clear_bit(nr, addr);
     return oldbit;
 }
 
-static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_set_bit(int nr, unsigned long *addr)
 {
     int oldbit = test_bit(nr, addr);
     set_bit(nr, addr);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 12:13:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 12:13:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrq6N-0003fb-Kl; Mon, 30 Jan 2012 12:12:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rrq6L-0003fW-PD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 12:12:50 +0000
Received: from [85.158.138.51:38965] by server-6.bemta-3.messagelabs.com id
	89/DA-31032-049862F4; Mon, 30 Jan 2012 12:12:48 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327925567!9376888!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20574 invoked from network); 30 Jan 2012 12:12:47 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-15.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 12:12:47 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327925567; l=1818;
	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=TTuqFTGsyWKWN4pI1k+zdbag+Ig=;
	b=n+GkojzjjjXc7RJ5oa9mmV1oqHqT5ReKP1MOqMuSQ4fjRjLgxeNKQhNzxdFM3ChGXfz
	RXVlYPpuq3c96JwrpbObaTN0Fi6TESFAJrukYSnAcDQCKR7ICkECOA1jfBv6hDX0Atd4n
	uMD+4iP3pwJ6zOOQc0itr7Mr8Mkkqzfq10M=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (klopstock mo1) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id e073e1o0UBJ5Xa
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:12:33 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 3BEA718634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:12:38 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 686f053d460da35f26b42b74e2ef41b6aceb5711
Message-Id: <686f053d460da35f26b4.1327925557@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 13:12:37 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH] tools/libxc: remove volatile keyword for bitmap
	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 Olaf Hering <olaf@aepfle.de>
# Date 1327925537 -3600
# Node ID 686f053d460da35f26b42b74e2ef41b6aceb5711
# Parent  4374739bd1428aead1c7f49beac6a28031c8d20b
tools/libxc: remove volatile keyword for bitmap operations

All bitmaps maintained by xc_bitops.h are used in single threaded
applications. So nothing will change the bitmaps content, adding
volatile adds just unneeded memory reloads.

xenpaging uses bitmaps alot and using non-volatile versions will slightly
improve performance.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4374739bd142 -r 686f053d460d tools/libxc/xc_bitops.h
--- a/tools/libxc/xc_bitops.h
+++ b/tools/libxc/xc_bitops.h
@@ -31,29 +31,29 @@ static inline void bitmap_clear(unsigned
     memset(addr, 0, bitmap_size(nr_bits));
 }
 
-static inline int test_bit(int nr, volatile unsigned long *addr)
+static inline int test_bit(int nr, unsigned long *addr)
 {
     return (BITMAP_ENTRY(nr, addr) >> BITMAP_SHIFT(nr)) & 1;
 }
 
-static inline void clear_bit(int nr, volatile unsigned long *addr)
+static inline void clear_bit(int nr, unsigned long *addr)
 {
     BITMAP_ENTRY(nr, addr) &= ~(1UL << BITMAP_SHIFT(nr));
 }
 
-static inline void set_bit(int nr, volatile unsigned long *addr)
+static inline void set_bit(int nr, unsigned long *addr)
 {
     BITMAP_ENTRY(nr, addr) |= (1UL << BITMAP_SHIFT(nr));
 }
 
-static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_clear_bit(int nr, unsigned long *addr)
 {
     int oldbit = test_bit(nr, addr);
     clear_bit(nr, addr);
     return oldbit;
 }
 
-static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_set_bit(int nr, unsigned long *addr)
 {
     int oldbit = test_bit(nr, addr);
     set_bit(nr, addr);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 12:24:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 12: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 1RrqHr-0004Yo-US; Mon, 30 Jan 2012 12:24:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RrqHq-0004Yj-77
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 12:24:42 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327926275!12541502!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNzIxNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4247 invoked from network); 30 Jan 2012 12:24:36 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 12:24:36 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:Subject:Content-Type:
	Content-Transfer-Encoding;
	b=j7QY5JSJJASmknT8oii6RvU4+NrnkcH/qzCDXZIPegegxcQQgAqUGxXW
	EV1/QjshUl3XIzUqipIDo/Gs789VUAm57NVw6/MLaNN8bfSh00iZRCqR2
	fpik6SADKatF0lwr2tChMYh+sk/aDOr5isj+xHgFr0wem7H245WW/vC+t
	6REumlwu+sMgY6VZvJ06AABg3da1iVDs1jRRwwziY51XEm29J+1aZ0qnm
	fuNnzRN0SsrGSU9aKqFeDwrLKT9Py;
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=1327926276; x=1359462276;
	h=message-id:date:from:mime-version:to:subject:
	content-transfer-encoding;
	bh=FXUkTrnMSMKnGW/PAYQWxS6KMudK4qMSH4TKr23BHrU=;
	b=uZs+1dU2hP7WxsEsI85GupcndYkQ1HuNcR5h6NdbH/L8WsmZfwHrwHWJ
	mhIvumtHXHHpuQ5fnzTooxSadrTYBh2hUdxdqu551ljo2QMXHZX9AFsuV
	lqgiCyC4a67oN2DyXxufsOux2Hzmd61Hu4xjFVqS6mpVqpX8vTZ8dv6mx
	a1/x55Rr9mON94glRgQUtgijlRBzoC7RilAu/Im5PqZVVgVIjiIszABVx
	tMvtgHQ8nvG0EArojRlzVinXpzixP;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,590,1320620400"; d="scan'208";a="100092021"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 30 Jan 2012 13:24:36 +0100
X-IronPort-AV: E=Sophos;i="4.71,591,1320620400"; d="scan'208";a="127690037"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 30 Jan 2012 13:24:35 +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 66702565B0F
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:24:35 +0100 (CET)
Message-ID: <4F268C03.5000003@ts.fujitsu.com>
Date: Mon, 30 Jan 2012 13:24:35 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I've got a question regarding live migration:

We have enabled our mainframe OS BS2000 to run as pv-hvm domain on Xen. Live
migration is working rather fine, but we have timing problems with large
memory (e.g. 128 GB). The reason for the timing problem is our own backend
driver for the BS2000 devices which requires to map all the domain memory to
avoid too many changes in BS2000. The mapping occurs at reconnection to the
backend driver and has to be synchronous. For a 128 GB domain this leads to
a 16 second stall of the domain when it is resuming on the target machine.

To avoid this stall I tried to start a little daemon on the target machine
and watch for a new BS2000 domain to show up due to live migration. I wanted
to map the domain memory as soon as the needed mapping information located in
a fixed guest mfn was transferred. Discovery of the new domain works as
expected, but I'm not capable doing any memory mapping until the restore of
the domain is finished. The mapping ioctl using IOCTL_PRIVCMD_MMAP returns
EINVAL until xc_restore is finished (more or less).

Why can xc_restore do the mapping while I can't? I know xc_restore is using
IOCTL_PRIVCMD_MMAPBATCH_V2, but I can't see a difference which should matter
between those two, as both are using the same hypercall to update the dom0
page tables.

Xen version is 4.0.2, linux kernel is 2.6.32 (both SLES11 SP1), the machine
is a x86_64 INTEL based one.


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 Mon Jan 30 12:24:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 12: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 1RrqHr-0004Yo-US; Mon, 30 Jan 2012 12:24:43 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RrqHq-0004Yj-77
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 12:24:42 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327926275!12541502!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNzIxNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4247 invoked from network); 30 Jan 2012 12:24:36 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-3.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 12:24:36 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:Subject:Content-Type:
	Content-Transfer-Encoding;
	b=j7QY5JSJJASmknT8oii6RvU4+NrnkcH/qzCDXZIPegegxcQQgAqUGxXW
	EV1/QjshUl3XIzUqipIDo/Gs789VUAm57NVw6/MLaNN8bfSh00iZRCqR2
	fpik6SADKatF0lwr2tChMYh+sk/aDOr5isj+xHgFr0wem7H245WW/vC+t
	6REumlwu+sMgY6VZvJ06AABg3da1iVDs1jRRwwziY51XEm29J+1aZ0qnm
	fuNnzRN0SsrGSU9aKqFeDwrLKT9Py;
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=1327926276; x=1359462276;
	h=message-id:date:from:mime-version:to:subject:
	content-transfer-encoding;
	bh=FXUkTrnMSMKnGW/PAYQWxS6KMudK4qMSH4TKr23BHrU=;
	b=uZs+1dU2hP7WxsEsI85GupcndYkQ1HuNcR5h6NdbH/L8WsmZfwHrwHWJ
	mhIvumtHXHHpuQ5fnzTooxSadrTYBh2hUdxdqu551ljo2QMXHZX9AFsuV
	lqgiCyC4a67oN2DyXxufsOux2Hzmd61Hu4xjFVqS6mpVqpX8vTZ8dv6mx
	a1/x55Rr9mON94glRgQUtgijlRBzoC7RilAu/Im5PqZVVgVIjiIszABVx
	tMvtgHQ8nvG0EArojRlzVinXpzixP;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,590,1320620400"; d="scan'208";a="100092021"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 30 Jan 2012 13:24:36 +0100
X-IronPort-AV: E=Sophos;i="4.71,591,1320620400"; d="scan'208";a="127690037"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 30 Jan 2012 13:24:35 +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 66702565B0F
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:24:35 +0100 (CET)
Message-ID: <4F268C03.5000003@ts.fujitsu.com>
Date: Mon, 30 Jan 2012 13:24:35 +0100
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
Organization: Fujitsu Technology Solutions
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111114 Iceowl/1.0b2 Icedove/3.1.16
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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,

I've got a question regarding live migration:

We have enabled our mainframe OS BS2000 to run as pv-hvm domain on Xen. Live
migration is working rather fine, but we have timing problems with large
memory (e.g. 128 GB). The reason for the timing problem is our own backend
driver for the BS2000 devices which requires to map all the domain memory to
avoid too many changes in BS2000. The mapping occurs at reconnection to the
backend driver and has to be synchronous. For a 128 GB domain this leads to
a 16 second stall of the domain when it is resuming on the target machine.

To avoid this stall I tried to start a little daemon on the target machine
and watch for a new BS2000 domain to show up due to live migration. I wanted
to map the domain memory as soon as the needed mapping information located in
a fixed guest mfn was transferred. Discovery of the new domain works as
expected, but I'm not capable doing any memory mapping until the restore of
the domain is finished. The mapping ioctl using IOCTL_PRIVCMD_MMAP returns
EINVAL until xc_restore is finished (more or less).

Why can xc_restore do the mapping while I can't? I know xc_restore is using
IOCTL_PRIVCMD_MMAPBATCH_V2, but I can't see a difference which should matter
between those two, as both are using the same hypercall to update the dom0
page tables.

Xen version is 4.0.2, linux kernel is 2.6.32 (both SLES11 SP1), the machine
is a x86_64 INTEL based one.


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 Mon Jan 30 13:14:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 13: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 1Rrr3b-0004sO-Vh; Mon, 30 Jan 2012 13:14:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paulian@marinca.net>) id 1Rrr3Z-0004sJ-Jn
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 13:14:02 +0000
X-Env-Sender: paulian@marinca.net
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327929183!54588757!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23355 invoked from network); 30 Jan 2012 13:13:03 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 13:13:03 -0000
Received: by wibhm2 with SMTP id hm2so13274587wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 05:13:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.109.198 with SMTP id hu6mr28291141wib.16.1327929236658;
	Mon, 30 Jan 2012 05:13:56 -0800 (PST)
Received: by 10.216.17.83 with HTTP; Mon, 30 Jan 2012 05:13:56 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
	<alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
Date: Mon, 30 Jan 2012 13:13:56 +0000
Message-ID: <CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
From: Paulian Bogdan Marinca <paulian@marinca.net>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Content-Type: multipart/mixed; boundary=e89a8f23505b701ae504b7be9eb0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--e89a8f23505b701ae504b7be9eb0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 30 January 2012 11:32, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Sat, 28 Jan 2012, Keir Fraser wrote:
>> On 27/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@marinca.net> wrot=
e:
>>
>> > I have a testing intel machine with 4 physical cpus running 64 bit Xen
>> > 4.1.3-rc1.
>> >
>> > I have a particular linux VM for which at its kernel boot time ( as
>> > domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
>> > console freezes indefinitely). The domU linux kernel is 3.2.1 and has
[...]
>
> That's right, this scenario should not be possible because whenever
> XENFEAT_hvm_pirqs is available, XENFEAT_hvm_callback_vector should also
> be available.
> In any case I'll submit a patch to Linux to make sure this doesn't
> happen, explicitly checking for xen_have_vector_callback.
> What is your Linux kernel version? Could you please post your kernel
> config as well?

Yes, you are right, this does not happen normally in a booting kernel.
What happens is that I needed to test my own PV drivers in all
possible scenarios,
 so I hacked the domU linux kernel to "believe" that XEN does not have
XENFEAT_hvm_callback_vector, basically I forced a

xen_have_vector_callback =3D 0;

in enlighten.c in domU kernel. This is probably why it triggered this
unusual situation.

I attach my kernel config (btw is actually a 3.0.6 kernel not 3.2.1)

I will try to apply your patch against XEN.

Thanks,
Paulian

>
>> In any case, cc'ing the author, Stefano. This ought to be easy to fix. W=
e
>> could make the irq_lock a recursive lock for example.
>
> We could also fail to map irqs into event channels if the delivery
> method is not HVMIRQ_callback_vector:
>
>
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index df92cc7..7d89ed6 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *ind=
ex, int *pirq_p,
>
> =A0 =A0 if ( domid =3D=3D DOMID_SELF && is_hvm_domain(d) )
> =A0 =A0 {
> + =A0 =A0 =A0 =A0if ( !is_hvm_pv_evtchn_domain(d) )
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0ret =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0goto free_domain;
> + =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 ret =3D physdev_hvm_map_pirq(d, type, index, pirq_p);
> =A0 =A0 =A0 =A0 goto free_domain;
> =A0 =A0 }

--e89a8f23505b701ae504b7be9eb0
Content-Type: application/octet-stream; name=config
Content-Disposition: attachment; filename=config
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gy1iset50

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24ndCBlZGl0CiMgTGlu
dXgveDg2XzY0IDMuMC42IEtlcm5lbCBDb25maWd1cmF0aW9uCiMKQ09ORklHXzY0QklUPXkKIyBD
T05GSUdfWDg2XzMyIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl82ND15CkNPTkZJR19YODY9eQpDT05G
SUdfSU5TVFJVQ1RJT05fREVDT0RFUj15CkNPTkZJR19PVVRQVVRfRk9STUFUPSJlbGY2NC14ODYt
NjQiCkNPTkZJR19BUkNIX0RFRkNPTkZJRz0iYXJjaC94ODYvY29uZmlncy94ODZfNjRfZGVmY29u
ZmlnIgpDT05GSUdfR0VORVJJQ19DTU9TX1VQREFURT15CkNPTkZJR19DTE9DS1NPVVJDRV9XQVRD
SERPRz15CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tF
VkVOVFNfQlJPQURDQVNUPXkKQ09ORklHX0xPQ0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RS
QUNFX1NVUFBPUlQ9eQpDT05GSUdfSEFWRV9MQVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdfTU1V
PXkKQ09ORklHX1pPTkVfRE1BPXkKQ09ORklHX05FRURfRE1BX01BUF9TVEFURT15CkNPTkZJR19O
RUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdfR0VORVJJQ19JU0FfRE1BPXkKQ09ORklHX0dFTkVS
SUNfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19CVUc9eQpDT05GSUdfR0VORVJJQ19CVUdfUkVMQVRJ
VkVfUE9JTlRFUlM9eQpDT05GSUdfR0VORVJJQ19IV0VJR0hUPXkKQ09ORklHX0dFTkVSSUNfR1BJ
Tz15CkNPTkZJR19BUkNIX01BWV9IQVZFX1BDX0ZEQz15CiMgQ09ORklHX1JXU0VNX0dFTkVSSUNf
U1BJTkxPQ0sgaXMgbm90IHNldApDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklUSE09eQpDT05G
SUdfQVJDSF9IQVNfQ1BVX0lETEVfV0FJVD15CkNPTkZJR19HRU5FUklDX0NBTElCUkFURV9ERUxB
WT15CkNPTkZJR19HRU5FUklDX1RJTUVfVlNZU0NBTEw9eQpDT05GSUdfQVJDSF9IQVNfQ1BVX1JF
TEFYPXkKQ09ORklHX0FSQ0hfSEFTX0RFRkFVTFRfSURMRT15CkNPTkZJR19BUkNIX0hBU19DQUNI
RV9MSU5FX1NJWkU9eQpDT05GSUdfSEFWRV9TRVRVUF9QRVJfQ1BVX0FSRUE9eQpDT05GSUdfTkVF
RF9QRVJfQ1BVX0VNQkVEX0ZJUlNUX0NIVU5LPXkKQ09ORklHX05FRURfUEVSX0NQVV9QQUdFX0ZJ
UlNUX0NIVU5LPXkKQ09ORklHX0hBVkVfQ1BVTUFTS19PRl9DUFVfTUFQPXkKQ09ORklHX0FSQ0hf
SElCRVJOQVRJT05fUE9TU0lCTEU9eQpDT05GSUdfQVJDSF9TVVNQRU5EX1BPU1NJQkxFPXkKQ09O
RklHX1pPTkVfRE1BMzI9eQpDT05GSUdfQVJDSF9QT1BVTEFURVNfTk9ERV9NQVA9eQpDT05GSUdf
QVVESVRfQVJDSD15CkNPTkZJR19BUkNIX1NVUFBPUlRTX09QVElNSVpFRF9JTkxJTklORz15CkNP
TkZJR19BUkNIX1NVUFBPUlRTX0RFQlVHX1BBR0VBTExPQz15CkNPTkZJR19IQVZFX0lOVEVMX1RY
VD15CkNPTkZJR19YODZfNjRfU01QPXkKQ09ORklHX1g4Nl9IVD15CkNPTkZJR19BUkNIX0hXRUlH
SFRfQ0ZMQUdTPSItZmNhbGwtc2F2ZWQtcmRpIC1mY2FsbC1zYXZlZC1yc2kgLWZjYWxsLXNhdmVk
LXJkeCAtZmNhbGwtc2F2ZWQtcmN4IC1mY2FsbC1zYXZlZC1yOCAtZmNhbGwtc2F2ZWQtcjkgLWZj
YWxsLXNhdmVkLXIxMCAtZmNhbGwtc2F2ZWQtcjExIgojIENPTkZJR19LVElNRV9TQ0FMQVIgaXMg
bm90IHNldApDT05GSUdfQVJDSF9DUFVfUFJPQkVfUkVMRUFTRT15CkNPTkZJR19ERUZDT05GSUdf
TElTVD0iL2xpYi9tb2R1bGVzLyRVTkFNRV9SRUxFQVNFLy5jb25maWciCkNPTkZJR19IQVZFX0lS
UV9XT1JLPXkKQ09ORklHX0lSUV9XT1JLPXkKCiMKIyBHZW5lcmFsIHNldHVwCiMKQ09ORklHX0VY
UEVSSU1FTlRBTD15CkNPTkZJR19JTklUX0VOVl9BUkdfTElNSVQ9MzIKIyBDT05GSUdfSU5JVF9Q
QVNTX0FMTF9QQVJBTVMgaXMgbm90IHNldApDT05GSUdfQ1JPU1NfQ09NUElMRT0iIgpDT05GSUdf
TE9DQUxWRVJTSU9OPSIiCiMgQ09ORklHX0xPQ0FMVkVSU0lPTl9BVVRPIGlzIG5vdCBzZXQKQ09O
RklHX0hBVkVfS0VSTkVMX0daSVA9eQpDT05GSUdfSEFWRV9LRVJORUxfQlpJUDI9eQpDT05GSUdf
SEFWRV9LRVJORUxfTFpNQT15CkNPTkZJR19IQVZFX0tFUk5FTF9YWj15CkNPTkZJR19IQVZFX0tF
Uk5FTF9MWk89eQpDT05GSUdfS0VSTkVMX0daSVA9eQojIENPTkZJR19LRVJORUxfQlpJUDIgaXMg
bm90IHNldAojIENPTkZJR19LRVJORUxfTFpNQSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9Y
WiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9MWk8gaXMgbm90IHNldApDT05GSUdfREVGQVVM
VF9IT1NUTkFNRT0iKG5vbmUpIgpDT05GSUdfVkVSU0lPTl9TSUdOQVRVUkU9IiIKQ09ORklHX1NX
QVA9eQpDT05GSUdfU1lTVklQQz15CkNPTkZJR19TWVNWSVBDX1NZU0NUTD15CkNPTkZJR19QT1NJ
WF9NUVVFVUU9eQpDT05GSUdfUE9TSVhfTVFVRVVFX1NZU0NUTD15CkNPTkZJR19CU0RfUFJPQ0VT
U19BQ0NUPXkKQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1RfVjM9eQojIENPTkZJR19GSEFORExFIGlz
IG5vdCBzZXQKQ09ORklHX1RBU0tTVEFUUz15CkNPTkZJR19UQVNLX0RFTEFZX0FDQ1Q9eQpDT05G
SUdfVEFTS19YQUNDVD15CkNPTkZJR19UQVNLX0lPX0FDQ09VTlRJTkc9eQpDT05GSUdfQVVESVQ9
eQpDT05GSUdfQVVESVRTWVNDQUxMPXkKQ09ORklHX0FVRElUX1dBVENIPXkKQ09ORklHX0FVRElU
X1RSRUU9eQpDT05GSUdfSEFWRV9HRU5FUklDX0hBUkRJUlFTPXkKCiMKIyBJUlEgc3Vic3lzdGVt
CiMKQ09ORklHX0dFTkVSSUNfSEFSRElSUVM9eQpDT05GSUdfSEFWRV9TUEFSU0VfSVJRPXkKQ09O
RklHX0dFTkVSSUNfSVJRX1BST0JFPXkKQ09ORklHX0dFTkVSSUNfSVJRX1NIT1c9eQpDT05GSUdf
R0VORVJJQ19QRU5ESU5HX0lSUT15CkNPTkZJR19JUlFfRk9SQ0VEX1RIUkVBRElORz15CkNPTkZJ
R19TUEFSU0VfSVJRPXkKCiMKIyBSQ1UgU3Vic3lzdGVtCiMKQ09ORklHX1RSRUVfUkNVPXkKIyBD
T05GSUdfUFJFRU1QVF9SQ1UgaXMgbm90IHNldAojIENPTkZJR19SQ1VfVFJBQ0UgaXMgbm90IHNl
dApDT05GSUdfUkNVX0ZBTk9VVD0zMgojIENPTkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBz
ZXQKIyBDT05GSUdfUkNVX0ZBU1RfTk9fSFogaXMgbm90IHNldAojIENPTkZJR19UUkVFX1JDVV9U
UkFDRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lLQ09ORklHIGlzIG5vdCBzZXQKQ09ORklHX0xPR19C
VUZfU0hJRlQ9MTcKQ09ORklHX0hBVkVfVU5TVEFCTEVfU0NIRURfQ0xPQ0s9eQpDT05GSUdfQ0dS
T1VQUz15CiMgQ09ORklHX0NHUk9VUF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19DR1JPVVBfRlJF
RVpFUj15CkNPTkZJR19DR1JPVVBfREVWSUNFPXkKQ09ORklHX0NQVVNFVFM9eQpDT05GSUdfUFJP
Q19QSURfQ1BVU0VUPXkKQ09ORklHX0NHUk9VUF9DUFVBQ0NUPXkKIyBDT05GSUdfUkVTT1VSQ0Vf
Q09VTlRFUlMgaXMgbm90IHNldAojIENPTkZJR19DR1JPVVBfUEVSRiBpcyBub3Qgc2V0CkNPTkZJ
R19DR1JPVVBfU0NIRUQ9eQpDT05GSUdfRkFJUl9HUk9VUF9TQ0hFRD15CiMgQ09ORklHX1JUX0dS
T1VQX1NDSEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NHUk9VUCBpcyBub3Qgc2V0CkNPTkZJ
R19OQU1FU1BBQ0VTPXkKQ09ORklHX1VUU19OUz15CkNPTkZJR19JUENfTlM9eQpDT05GSUdfVVNF
Ul9OUz15CkNPTkZJR19QSURfTlM9eQpDT05GSUdfTkVUX05TPXkKIyBDT05GSUdfU0NIRURfQVVU
T0dST1VQIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CkNP
TkZJR19SRUxBWT15CkNPTkZJR19CTEtfREVWX0lOSVRSRD15CkNPTkZJR19JTklUUkFNRlNfU09V
UkNFPSIiCkNPTkZJR19SRF9HWklQPXkKIyBDT05GSUdfUkRfQlpJUDIgaXMgbm90IHNldAojIENP
TkZJR19SRF9MWk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfUkRfWFogaXMgbm90IHNldAojIENPTkZJ
R19SRF9MWk8gaXMgbm90IHNldApDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1NJWkU9eQpDT05GSUdf
U1lTQ1RMPXkKQ09ORklHX0FOT05fSU5PREVTPXkKQ09ORklHX0VYUEVSVD15CkNPTkZJR19VSUQx
Nj15CkNPTkZJR19TWVNDVExfU1lTQ0FMTD15CkNPTkZJR19LQUxMU1lNUz15CiMgQ09ORklHX0tB
TExTWU1TX0FMTCBpcyBub3Qgc2V0CkNPTkZJR19IT1RQTFVHPXkKQ09ORklHX1BSSU5USz15CkNP
TkZJR19CVUc9eQpDT05GSUdfRUxGX0NPUkU9eQpDT05GSUdfUENTUEtSX1BMQVRGT1JNPXkKQ09O
RklHX0JBU0VfRlVMTD15CkNPTkZJR19GVVRFWD15CkNPTkZJR19FUE9MTD15CkNPTkZJR19TSUdO
QUxGRD15CkNPTkZJR19USU1FUkZEPXkKQ09ORklHX0VWRU5URkQ9eQpDT05GSUdfU0hNRU09eQpD
T05GSUdfQUlPPXkKIyBDT05GSUdfRU1CRURERUQgaXMgbm90IHNldApDT05GSUdfSEFWRV9QRVJG
X0VWRU5UUz15CgojCiMgS2VybmVsIFBlcmZvcm1hbmNlIEV2ZW50cyBBbmQgQ291bnRlcnMKIwpD
T05GSUdfUEVSRl9FVkVOVFM9eQojIENPTkZJR19QRVJGX0NPVU5URVJTIGlzIG5vdCBzZXQKIyBD
T05GSUdfREVCVUdfUEVSRl9VU0VfVk1BTExPQyBpcyBub3Qgc2V0CkNPTkZJR19WTV9FVkVOVF9D
T1VOVEVSUz15CkNPTkZJR19QQ0lfUVVJUktTPXkKQ09ORklHX1NMVUJfREVCVUc9eQojIENPTkZJ
R19DT01QQVRfQlJLIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xBQiBpcyBub3Qgc2V0CkNPTkZJR19T
TFVCPXkKIyBDT05GSUdfU0xPQiBpcyBub3Qgc2V0CkNPTkZJR19QUk9GSUxJTkc9eQpDT05GSUdf
VFJBQ0VQT0lOVFM9eQpDT05GSUdfT1BST0ZJTEU9bQojIENPTkZJR19PUFJPRklMRV9FVkVOVF9N
VUxUSVBMRVggaXMgbm90IHNldApDT05GSUdfSEFWRV9PUFJPRklMRT15CkNPTkZJR19LUFJPQkVT
PXkKIyBDT05GSUdfSlVNUF9MQUJFTCBpcyBub3Qgc2V0CkNPTkZJR19PUFRQUk9CRVM9eQpDT05G
SUdfSEFWRV9FRkZJQ0lFTlRfVU5BTElHTkVEX0FDQ0VTUz15CkNPTkZJR19LUkVUUFJPQkVTPXkK
Q09ORklHX0hBVkVfSU9SRU1BUF9QUk9UPXkKQ09ORklHX0hBVkVfS1BST0JFUz15CkNPTkZJR19I
QVZFX0tSRVRQUk9CRVM9eQpDT05GSUdfSEFWRV9PUFRQUk9CRVM9eQpDT05GSUdfSEFWRV9BUkNI
X1RSQUNFSE9PSz15CkNPTkZJR19IQVZFX0RNQV9BVFRSUz15CkNPTkZJR19VU0VfR0VORVJJQ19T
TVBfSEVMUEVSUz15CkNPTkZJR19IQVZFX1JFR1NfQU5EX1NUQUNLX0FDQ0VTU19BUEk9eQpDT05G
SUdfSEFWRV9ETUFfQVBJX0RFQlVHPXkKQ09ORklHX0hBVkVfSFdfQlJFQUtQT0lOVD15CkNPTkZJ
R19IQVZFX01JWEVEX0JSRUFLUE9JTlRTX1JFR1M9eQpDT05GSUdfSEFWRV9VU0VSX1JFVFVSTl9O
T1RJRklFUj15CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRTX05NST15CkNPTkZJR19IQVZFX0FSQ0hf
SlVNUF9MQUJFTD15CgojCiMgR0NPVi1iYXNlZCBrZXJuZWwgcHJvZmlsaW5nCiMKIyBDT05GSUdf
R0NPVl9LRVJORUwgaXMgbm90IHNldAojIENPTkZJR19IQVZFX0dFTkVSSUNfRE1BX0NPSEVSRU5U
IGlzIG5vdCBzZXQKQ09ORklHX1NMQUJJTkZPPXkKQ09ORklHX1JUX01VVEVYRVM9eQpDT05GSUdf
QkFTRV9TTUFMTD0wCkNPTkZJR19NT0RVTEVTPXkKQ09ORklHX01PRFVMRV9GT1JDRV9MT0FEPXkK
Q09ORklHX01PRFVMRV9VTkxPQUQ9eQpDT05GSUdfTU9EVUxFX0ZPUkNFX1VOTE9BRD15CkNPTkZJ
R19NT0RWRVJTSU9OUz15CiMgQ09ORklHX01PRFVMRV9TUkNWRVJTSU9OX0FMTCBpcyBub3Qgc2V0
CkNPTkZJR19TVE9QX01BQ0hJTkU9eQpDT05GSUdfQkxPQ0s9eQpDT05GSUdfQkxLX0RFVl9CU0c9
eQpDT05GSUdfQkxLX0RFVl9JTlRFR1JJVFk9eQpDT05GSUdfQkxPQ0tfQ09NUEFUPXkKCiMKIyBJ
TyBTY2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CkNPTkZJR19JT1NDSEVEX0RFQURM
SU5FPXkKQ09ORklHX0lPU0NIRURfQ0ZRPXkKIyBDT05GSUdfREVGQVVMVF9ERUFETElORSBpcyBu
b3Qgc2V0CkNPTkZJR19ERUZBVUxUX0NGUT15CiMgQ09ORklHX0RFRkFVTFRfTk9PUCBpcyBub3Qg
c2V0CkNPTkZJR19ERUZBVUxUX0lPU0NIRUQ9ImNmcSIKIyBDT05GSUdfSU5MSU5FX1NQSU5fVFJZ
TE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX1RSWUxPQ0tfQkggaXMgbm90IHNl
dAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQ
SU5fTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX0xPQ0tfSVJRIGlzIG5v
dCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19JUlFTQVZFIGlzIG5vdCBzZXQKQ09ORklH
X0lOTElORV9TUElOX1VOTE9DSz15CiMgQ09ORklHX0lOTElORV9TUElOX1VOTE9DS19CSCBpcyBu
b3Qgc2V0CkNPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfSVJRPXkKIyBDT05GSUdfSU5MSU5FX1NQ
SU5fVU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfUkVBRF9UUllM
T0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9DSyBpcyBub3Qgc2V0CiMgQ09O
RklHX0lOTElORV9SRUFEX0xPQ0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfUkVBRF9M
T0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfSVJRU0FWRSBpcyBu
b3Qgc2V0CkNPTkZJR19JTkxJTkVfUkVBRF9VTkxPQ0s9eQojIENPTkZJR19JTkxJTkVfUkVBRF9V
TkxPQ0tfQkggaXMgbm90IHNldApDT05GSUdfSU5MSU5FX1JFQURfVU5MT0NLX0lSUT15CiMgQ09O
RklHX0lOTElORV9SRUFEX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5M
SU5FX1dSSVRFX1RSWUxPQ0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVfTE9DSyBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLX0JIIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5MSU5FX1dSSVRFX0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRF
X0xPQ0tfSVJRU0FWRSBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfV1JJVEVfVU5MT0NLPXkKIyBD
T05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19CSCBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfV1JJ
VEVfVU5MT0NLX0lSUT15CiMgQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0tfSVJRUkVTVE9SRSBp
cyBub3Qgc2V0CkNPTkZJR19NVVRFWF9TUElOX09OX09XTkVSPXkKQ09ORklHX0ZSRUVaRVI9eQoK
IwojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcwojCkNPTkZJR19USUNLX09ORVNIT1Q9eQpD
T05GSUdfTk9fSFo9eQpDT05GSUdfSElHSF9SRVNfVElNRVJTPXkKQ09ORklHX0dFTkVSSUNfQ0xP
Q0tFVkVOVFNfQlVJTEQ9eQpDT05GSUdfU01QPXkKQ09ORklHX1g4Nl9NUFBBUlNFPXkKIyBDT05G
SUdfWDg2X0VYVEVOREVEX1BMQVRGT1JNIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9TVVBQT1JUU19N
RU1PUllfRkFJTFVSRT15CkNPTkZJR19TQ0hFRF9PTUlUX0ZSQU1FX1BPSU5URVI9eQpDT05GSUdf
UEFSQVZJUlRfR1VFU1Q9eQpDT05GSUdfWEVOPXkKQ09ORklHX1hFTl9ET00wPXkKQ09ORklHX1hF
Tl9QUklWSUxFR0VEX0dVRVNUPXkKQ09ORklHX1hFTl9QVkhWTT15CkNPTkZJR19YRU5fTUFYX0RP
TUFJTl9NRU1PUlk9MTI4CkNPTkZJR19YRU5fU0FWRV9SRVNUT1JFPXkKQ09ORklHX1hFTl9ERUJV
R19GUz15CkNPTkZJR19YRU5fREVCVUc9eQojIENPTkZJR19LVk1fQ0xPQ0sgaXMgbm90IHNldAoj
IENPTkZJR19LVk1fR1VFU1QgaXMgbm90IHNldApDT05GSUdfUEFSQVZJUlQ9eQojIENPTkZJR19Q
QVJBVklSVF9TUElOTE9DS1MgaXMgbm90IHNldApDT05GSUdfUEFSQVZJUlRfQ0xPQ0s9eQojIENP
TkZJR19QQVJBVklSVF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19OT19CT09UTUVNPXkKIyBDT05G
SUdfTUVNVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX01LOCBpcyBub3Qgc2V0CiMgQ09ORklHX01Q
U0MgaXMgbm90IHNldAojIENPTkZJR19NQ09SRTIgaXMgbm90IHNldAojIENPTkZJR19NQVRPTSBp
cyBub3Qgc2V0CkNPTkZJR19HRU5FUklDX0NQVT15CkNPTkZJR19YODZfSU5URVJOT0RFX0NBQ0hF
X1NISUZUPTYKQ09ORklHX1g4Nl9DTVBYQ0hHPXkKQ09ORklHX0NNUFhDSEdfTE9DQUw9eQpDT05G
SUdfWDg2X0wxX0NBQ0hFX1NISUZUPTYKQ09ORklHX1g4Nl9YQUREPXkKQ09ORklHX1g4Nl9XUF9X
T1JLU19PSz15CkNPTkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpDT05GSUdf
WDg2X0NNT1Y9eQpDT05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT02NApDT05GSUdfWDg2X0RF
QlVHQ1RMTVNSPXkKIyBDT05GSUdfUFJPQ0VTU09SX1NFTEVDVCBpcyBub3Qgc2V0CkNPTkZJR19D
UFVfU1VQX0lOVEVMPXkKQ09ORklHX0NQVV9TVVBfQU1EPXkKQ09ORklHX0NQVV9TVVBfQ0VOVEFV
Uj15CkNPTkZJR19IUEVUX1RJTUVSPXkKQ09ORklHX0RNST15CkNPTkZJR19HQVJUX0lPTU1VPXkK
IyBDT05GSUdfQ0FMR0FSWV9JT01NVSBpcyBub3Qgc2V0CiMgQ09ORklHX0FNRF9JT01NVSBpcyBu
b3Qgc2V0CkNPTkZJR19TV0lPVExCPXkKQ09ORklHX0lPTU1VX0hFTFBFUj15CkNPTkZJR19JT01N
VV9BUEk9eQojIENPTkZJR19NQVhTTVAgaXMgbm90IHNldApDT05GSUdfTlJfQ1BVUz04CkNPTkZJ
R19TQ0hFRF9TTVQ9eQpDT05GSUdfU0NIRURfTUM9eQojIENPTkZJR19JUlFfVElNRV9BQ0NPVU5U
SU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJFRU1QVF9OT05FIGlzIG5vdCBzZXQKQ09ORklHX1BS
RUVNUFRfVk9MVU5UQVJZPXkKIyBDT05GSUdfUFJFRU1QVCBpcyBub3Qgc2V0CkNPTkZJR19YODZf
TE9DQUxfQVBJQz15CkNPTkZJR19YODZfSU9fQVBJQz15CkNPTkZJR19YODZfUkVST1VURV9GT1Jf
QlJPS0VOX0JPT1RfSVJRUz15CkNPTkZJR19YODZfTUNFPXkKQ09ORklHX1g4Nl9NQ0VfSU5URUw9
eQojIENPTkZJR19YODZfTUNFX1hFT043NVhYIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X01DRV9B
TUQgaXMgbm90IHNldApDT05GSUdfWDg2X01DRV9USFJFU0hPTEQ9eQojIENPTkZJR19YODZfTUNF
X0lOSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19YODZfVEhFUk1BTF9WRUNUT1I9eQojIENPTkZJR19J
OEsgaXMgbm90IHNldAojIENPTkZJR19NSUNST0NPREUgaXMgbm90IHNldAojIENPTkZJR19YODZf
TVNSIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X0NQVUlEIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hf
UEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9ETUFfQUREUl9UXzY0QklUPXkKQ09ORklH
X0RJUkVDVF9HQlBBR0VTPXkKIyBDT05GSUdfTlVNQSBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX1NQ
QVJTRU1FTV9FTkFCTEU9eQpDT05GSUdfQVJDSF9TUEFSU0VNRU1fREVGQVVMVD15CkNPTkZJR19B
UkNIX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdfQVJDSF9NRU1PUllfUFJPQkU9eQpDT05G
SUdfQVJDSF9QUk9DX0tDT1JFX1RFWFQ9eQpDT05GSUdfSUxMRUdBTF9QT0lOVEVSX1ZBTFVFPTB4
ZGVhZDAwMDAwMDAwMDAwMApDT05GSUdfU0VMRUNUX01FTU9SWV9NT0RFTD15CkNPTkZJR19TUEFS
U0VNRU1fTUFOVUFMPXkKQ09ORklHX1NQQVJTRU1FTT15CkNPTkZJR19IQVZFX01FTU9SWV9QUkVT
RU5UPXkKQ09ORklHX1NQQVJTRU1FTV9FWFRSRU1FPXkKQ09ORklHX1NQQVJTRU1FTV9WTUVNTUFQ
X0VOQUJMRT15CkNPTkZJR19TUEFSU0VNRU1fQUxMT0NfTUVNX01BUF9UT0dFVEhFUj15CkNPTkZJ
R19TUEFSU0VNRU1fVk1FTU1BUD15CkNPTkZJR19IQVZFX01FTUJMT0NLPXkKQ09ORklHX01FTU9S
WV9IT1RQTFVHPXkKQ09ORklHX01FTU9SWV9IT1RQTFVHX1NQQVJTRT15CkNPTkZJR19NRU1PUllf
SE9UUkVNT1ZFPXkKQ09ORklHX1BBR0VGTEFHU19FWFRFTkRFRD15CkNPTkZJR19TUExJVF9QVExP
Q0tfQ1BVUz00CiMgQ09ORklHX0NPTVBBQ1RJT04gaXMgbm90IHNldApDT05GSUdfTUlHUkFUSU9O
PXkKQ09ORklHX1BIWVNfQUREUl9UXzY0QklUPXkKQ09ORklHX1pPTkVfRE1BX0ZMQUc9MQpDT05G
SUdfQk9VTkNFPXkKQ09ORklHX1ZJUlRfVE9fQlVTPXkKQ09ORklHX01NVV9OT1RJRklFUj15CkNP
TkZJR19LU009eQpDT05GSUdfREVGQVVMVF9NTUFQX01JTl9BRERSPTY1NTM2CkNPTkZJR19BUkNI
X1NVUFBPUlRTX01FTU9SWV9GQUlMVVJFPXkKIyBDT05GSUdfTUVNT1JZX0ZBSUxVUkUgaXMgbm90
IHNldAojIENPTkZJR19UUkFOU1BBUkVOVF9IVUdFUEFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NM
RUFOQ0FDSEUgaXMgbm90IHNldAojIENPTkZJR19YODZfQ0hFQ0tfQklPU19DT1JSVVBUSU9OIGlz
IG5vdCBzZXQKQ09ORklHX1g4Nl9SRVNFUlZFX0xPVz02NApDT05GSUdfTVRSUj15CkNPTkZJR19N
VFJSX1NBTklUSVpFUj15CkNPTkZJR19NVFJSX1NBTklUSVpFUl9FTkFCTEVfREVGQVVMVD0wCkNP
TkZJR19NVFJSX1NBTklUSVpFUl9TUEFSRV9SRUdfTlJfREVGQVVMVD0xCkNPTkZJR19YODZfUEFU
PXkKQ09ORklHX0FSQ0hfVVNFU19QR19VTkNBQ0hFRD15CkNPTkZJR19FRkk9eQpDT05GSUdfU0VD
Q09NUD15CkNPTkZJR19DQ19TVEFDS1BST1RFQ1RPUj15CiMgQ09ORklHX0haXzEwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX0haXzI1MCBpcyBub3Qgc2V0CkNPTkZJR19IWl8zMDA9eQojIENPTkZJR19I
Wl8xMDAwIGlzIG5vdCBzZXQKQ09ORklHX0haPTMwMApDT05GSUdfU0NIRURfSFJUSUNLPXkKQ09O
RklHX0tFWEVDPXkKIyBDT05GSUdfQ1JBU0hfRFVNUCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWEVD
X0pVTVAgaXMgbm90IHNldApDT05GSUdfUEhZU0lDQUxfU1RBUlQ9MHgxMDAwMDAwCkNPTkZJR19S
RUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0weDEwMDAwMDAKQ09ORklHX0hPVFBM
VUdfQ1BVPXkKQ09ORklHX0NPTVBBVF9WRFNPPXkKIyBDT05GSUdfQ01ETElORV9CT09MIGlzIG5v
dCBzZXQKQ09ORklHX0FSQ0hfRU5BQkxFX01FTU9SWV9IT1RQTFVHPXkKQ09ORklHX0FSQ0hfRU5B
QkxFX01FTU9SWV9IT1RSRU1PVkU9eQoKIwojIFBvd2VyIG1hbmFnZW1lbnQgYW5kIEFDUEkgb3B0
aW9ucwojCkNPTkZJR19BUkNIX0hJQkVSTkFUSU9OX0hFQURFUj15CkNPTkZJR19TVVNQRU5EPXkK
Q09ORklHX1NVU1BFTkRfRlJFRVpFUj15CkNPTkZJR19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKQ09O
RklHX0hJQkVSTkFUSU9OPXkKQ09ORklHX1BNX1NURF9QQVJUSVRJT049IiIKQ09ORklHX1BNX1NM
RUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CkNPTkZJR19QTV9SVU5USU1FPXkKQ09ORklHX1BN
PXkKQ09ORklHX1BNX0RFQlVHPXkKIyBDT05GSUdfUE1fQURWQU5DRURfREVCVUcgaXMgbm90IHNl
dAojIENPTkZJR19QTV9URVNUX1NVU1BFTkQgaXMgbm90IHNldApDT05GSUdfQ0FOX1BNX1RSQUNF
PXkKIyBDT05GSUdfUE1fVFJBQ0VfUlRDIGlzIG5vdCBzZXQKQ09ORklHX0FDUEk9eQpDT05GSUdf
QUNQSV9TTEVFUD15CkNPTkZJR19BQ1BJX1BST0NGUz15CiMgQ09ORklHX0FDUElfUFJPQ0ZTX1BP
V0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQSV9FQ19ERUJVR0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfQUNQSV9QUk9DX0VWRU5UIGlzIG5vdCBzZXQKQ09ORklHX0FDUElfQUM9bQpDT05GSUdfQUNQ
SV9CQVRURVJZPW0KQ09ORklHX0FDUElfQlVUVE9OPW0KQ09ORklHX0FDUElfVklERU89bQpDT05G
SUdfQUNQSV9GQU49bQpDT05GSUdfQUNQSV9ET0NLPXkKQ09ORklHX0FDUElfUFJPQ0VTU09SPW0K
Q09ORklHX0FDUElfSE9UUExVR19DUFU9eQpDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRP
Uj1tCkNPTkZJR19BQ1BJX1RIRVJNQUw9bQojIENPTkZJR19BQ1BJX0NVU1RPTV9EU0RUIGlzIG5v
dCBzZXQKQ09ORklHX0FDUElfQkxBQ0tMSVNUX1lFQVI9MAojIENPTkZJR19BQ1BJX0RFQlVHIGlz
IG5vdCBzZXQKQ09ORklHX0FDUElfUENJX1NMT1Q9bQpDT05GSUdfWDg2X1BNX1RJTUVSPXkKQ09O
RklHX0FDUElfQ09OVEFJTkVSPW0KQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlk9bQpDT05GSUdf
QUNQSV9TQlM9bQojIENPTkZJR19BQ1BJX0hFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfQ1VT
VE9NX01FVEhPRCBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfQVBFSSBpcyBub3Qgc2V0CkNPTkZJ
R19TRkk9eQoKIwojIENQVSBGcmVxdWVuY3kgc2NhbGluZwojCkNPTkZJR19DUFVfRlJFUT15CkNP
TkZJR19DUFVfRlJFUV9UQUJMRT15CkNPTkZJR19DUFVfRlJFUV9TVEFUPW0KIyBDT05GSUdfQ1BV
X0ZSRVFfU1RBVF9ERVRBSUxTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9H
T1ZfUEVSRk9STUFOQ0UgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9Q
T1dFUlNBVkUgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9VU0VSU1BB
Q0UgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfT05ERU1BTkQ9eQojIENP
TkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldApDT05GSUdf
Q1BVX0ZSRVFfR09WX1BFUkZPUk1BTkNFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9QT1dFUlNBVkU9
bQpDT05GSUdfQ1BVX0ZSRVFfR09WX1VTRVJTUEFDRT1tCkNPTkZJR19DUFVfRlJFUV9HT1ZfT05E
RU1BTkQ9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTlNFUlZBVElWRT1tCgojCiMgeDg2IENQVSBm
cmVxdWVuY3kgc2NhbGluZyBkcml2ZXJzCiMKIyBDT05GSUdfWDg2X1BDQ19DUFVGUkVRIGlzIG5v
dCBzZXQKQ09ORklHX1g4Nl9BQ1BJX0NQVUZSRVE9bQpDT05GSUdfWDg2X1BPV0VSTk9XX0s4PW0K
Q09ORklHX1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk89bQojIENPTkZJR19YODZfUDRfQ0xPQ0tNT0Qg
aXMgbm90IHNldAoKIwojIHNoYXJlZCBvcHRpb25zCiMKIyBDT05GSUdfWDg2X1NQRUVEU1RFUF9M
SUIgaXMgbm90IHNldApDT05GSUdfQ1BVX0lETEU9eQpDT05GSUdfQ1BVX0lETEVfR09WX0xBRERF
Uj15CkNPTkZJR19DUFVfSURMRV9HT1ZfTUVOVT15CiMgQ09ORklHX0lOVEVMX0lETEUgaXMgbm90
IHNldAoKIwojIE1lbW9yeSBwb3dlciBzYXZpbmdzCiMKIyBDT05GSUdfSTczMDBfSURMRSBpcyBu
b3Qgc2V0CgojCiMgQnVzIG9wdGlvbnMgKFBDSSBldGMuKQojCkNPTkZJR19QQ0k9eQpDT05GSUdf
UENJX0RJUkVDVD15CkNPTkZJR19QQ0lfTU1DT05GSUc9eQpDT05GSUdfUENJX1hFTj15CkNPTkZJ
R19QQ0lfRE9NQUlOUz15CiMgQ09ORklHX1BDSV9DTkIyMExFX1FVSVJLIGlzIG5vdCBzZXQKQ09O
RklHX0RNQVI9eQojIENPTkZJR19ETUFSX0RFRkFVTFRfT04gaXMgbm90IHNldApDT05GSUdfRE1B
Ul9GTE9QUFlfV0E9eQojIENPTkZJR19JTlRSX1JFTUFQIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVQ
T1JUQlVTPXkKQ09ORklHX1BDSUVBRVI9eQojIENPTkZJR19QQ0lFX0VDUkMgaXMgbm90IHNldAoj
IENPTkZJR19QQ0lFQUVSX0lOSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19QQ0lFQVNQTT15CiMgQ09O
RklHX1BDSUVBU1BNX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVfUE1FPXkKQ09ORklHX0FS
Q0hfU1VQUE9SVFNfTVNJPXkKQ09ORklHX1BDSV9NU0k9eQojIENPTkZJR19QQ0lfREVCVUcgaXMg
bm90IHNldAojIENPTkZJR19QQ0lfU1RVQiBpcyBub3Qgc2V0CkNPTkZJR19YRU5fUENJREVWX0ZS
T05URU5EPW0KQ09ORklHX0hUX0lSUT15CkNPTkZJR19QQ0lfSU9WPXkKQ09ORklHX1BDSV9JT0FQ
SUM9eQpDT05GSUdfUENJX0xBQkVMPXkKQ09ORklHX0lTQV9ETUFfQVBJPXkKQ09ORklHX0FNRF9O
Qj15CiMgQ09ORklHX1BDQ0FSRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hPVFBMVUdfUENJIGlzIG5v
dCBzZXQKIyBDT05GSUdfUkFQSURJTyBpcyBub3Qgc2V0CgojCiMgRXhlY3V0YWJsZSBmaWxlIGZv
cm1hdHMgLyBFbXVsYXRpb25zCiMKQ09ORklHX0JJTkZNVF9FTEY9eQpDT05GSUdfQ09NUEFUX0JJ
TkZNVF9FTEY9eQpDT05GSUdfQ09SRV9EVU1QX0RFRkFVTFRfRUxGX0hFQURFUlM9eQojIENPTkZJ
R19IQVZFX0FPVVQgaXMgbm90IHNldApDT05GSUdfQklORk1UX01JU0M9bQpDT05GSUdfSUEzMl9F
TVVMQVRJT049eQojIENPTkZJR19JQTMyX0FPVVQgaXMgbm90IHNldApDT05GSUdfQ09NUEFUPXkK
Q09ORklHX0NPTVBBVF9GT1JfVTY0X0FMSUdOTUVOVD15CkNPTkZJR19TWVNWSVBDX0NPTVBBVD15
CkNPTkZJR19IQVZFX1RFWFRfUE9LRV9TTVA9eQpDT05GSUdfTkVUPXkKCiMKIyBOZXR3b3JraW5n
IG9wdGlvbnMKIwpDT05GSUdfUEFDS0VUPXkKQ09ORklHX1VOSVg9eQpDT05GSUdfWEZSTT15CiMg
Q09ORklHX1hGUk1fVVNFUiBpcyBub3Qgc2V0CkNPTkZJR19YRlJNX1NVQl9QT0xJQ1k9eQpDT05G
SUdfWEZSTV9NSUdSQVRFPXkKIyBDT05GSUdfWEZSTV9TVEFUSVNUSUNTIGlzIG5vdCBzZXQKQ09O
RklHX1hGUk1fSVBDT01QPW0KIyBDT05GSUdfTkVUX0tFWSBpcyBub3Qgc2V0CkNPTkZJR19JTkVU
PXkKQ09ORklHX0lQX01VTFRJQ0FTVD15CkNPTkZJR19JUF9BRFZBTkNFRF9ST1VURVI9eQojIENP
TkZJR19JUF9GSUJfVFJJRV9TVEFUUyBpcyBub3Qgc2V0CkNPTkZJR19JUF9NVUxUSVBMRV9UQUJM
RVM9eQpDT05GSUdfSVBfUk9VVEVfTVVMVElQQVRIPXkKQ09ORklHX0lQX1JPVVRFX1ZFUkJPU0U9
eQpDT05GSUdfSVBfUk9VVEVfQ0xBU1NJRD15CiMgQ09ORklHX0lQX1BOUCBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9JUElQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0lQR1JFX0RFTVVYIGlzIG5v
dCBzZXQKQ09ORklHX0lQX01ST1VURT15CiMgQ09ORklHX0lQX01ST1VURV9NVUxUSVBMRV9UQUJM
RVMgaXMgbm90IHNldApDT05GSUdfSVBfUElNU01fVjE9eQpDT05GSUdfSVBfUElNU01fVjI9eQoj
IENPTkZJR19BUlBEIGlzIG5vdCBzZXQKQ09ORklHX1NZTl9DT09LSUVTPXkKIyBDT05GSUdfSU5F
VF9BSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5F
VF9JUENPTVAgaXMgbm90IHNldAojIENPTkZJR19JTkVUX1hGUk1fVFVOTkVMIGlzIG5vdCBzZXQK
Q09ORklHX0lORVRfVFVOTkVMPW0KIyBDT05GSUdfSU5FVF9YRlJNX01PREVfVFJBTlNQT1JUIGlz
IG5vdCBzZXQKIyBDT05GSUdfSU5FVF9YRlJNX01PREVfVFVOTkVMIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5FVF9YRlJNX01PREVfQkVFVCBpcyBub3Qgc2V0CkNPTkZJR19JTkVUX0xSTz1tCiMgQ09O
RklHX0lORVRfRElBRyBpcyBub3Qgc2V0CkNPTkZJR19UQ1BfQ09OR19BRFZBTkNFRD15CkNPTkZJ
R19UQ1BfQ09OR19CSUM9bQpDT05GSUdfVENQX0NPTkdfQ1VCSUM9eQpDT05GSUdfVENQX0NPTkdf
V0VTVFdPT0Q9bQpDT05GSUdfVENQX0NPTkdfSFRDUD1tCkNPTkZJR19UQ1BfQ09OR19IU1RDUD1t
CkNPTkZJR19UQ1BfQ09OR19IWUJMQT1tCkNPTkZJR19UQ1BfQ09OR19WRUdBUz1tCkNPTkZJR19U
Q1BfQ09OR19TQ0FMQUJMRT1tCkNPTkZJR19UQ1BfQ09OR19MUD1tCkNPTkZJR19UQ1BfQ09OR19W
RU5PPW0KQ09ORklHX1RDUF9DT05HX1lFQUg9bQpDT05GSUdfVENQX0NPTkdfSUxMSU5PSVM9bQpD
T05GSUdfREVGQVVMVF9DVUJJQz15CiMgQ09ORklHX0RFRkFVTFRfUkVOTyBpcyBub3Qgc2V0CkNP
TkZJR19ERUZBVUxUX1RDUF9DT05HPSJjdWJpYyIKQ09ORklHX1RDUF9NRDVTSUc9eQpDT05GSUdf
SVBWNj15CkNPTkZJR19JUFY2X1BSSVZBQ1k9eQpDT05GSUdfSVBWNl9ST1VURVJfUFJFRj15CkNP
TkZJR19JUFY2X1JPVVRFX0lORk89eQpDT05GSUdfSVBWNl9PUFRJTUlTVElDX0RBRD15CkNPTkZJ
R19JTkVUNl9BSD1tCkNPTkZJR19JTkVUNl9FU1A9bQpDT05GSUdfSU5FVDZfSVBDT01QPW0KQ09O
RklHX0lQVjZfTUlQNj15CkNPTkZJR19JTkVUNl9YRlJNX1RVTk5FTD1tCkNPTkZJR19JTkVUNl9U
VU5ORUw9bQpDT05GSUdfSU5FVDZfWEZSTV9NT0RFX1RSQU5TUE9SVD1tCkNPTkZJR19JTkVUNl9Y
RlJNX01PREVfVFVOTkVMPW0KQ09ORklHX0lORVQ2X1hGUk1fTU9ERV9CRUVUPW0KQ09ORklHX0lO
RVQ2X1hGUk1fTU9ERV9ST1VURU9QVElNSVpBVElPTj1tCkNPTkZJR19JUFY2X1NJVD1tCiMgQ09O
RklHX0lQVjZfU0lUXzZSRCBpcyBub3Qgc2V0CkNPTkZJR19JUFY2X05ESVNDX05PREVUWVBFPXkK
Q09ORklHX0lQVjZfVFVOTkVMPW0KQ09ORklHX0lQVjZfTVVMVElQTEVfVEFCTEVTPXkKQ09ORklH
X0lQVjZfU1VCVFJFRVM9eQpDT05GSUdfSVBWNl9NUk9VVEU9eQojIENPTkZJR19JUFY2X01ST1VU
RV9NVUxUSVBMRV9UQUJMRVMgaXMgbm90IHNldApDT05GSUdfSVBWNl9QSU1TTV9WMj15CkNPTkZJ
R19ORVRXT1JLX1NFQ01BUks9eQojIENPTkZJR19ORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgaXMg
bm90IHNldApDT05GSUdfTkVURklMVEVSPXkKIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5v
dCBzZXQKQ09ORklHX05FVEZJTFRFUl9BRFZBTkNFRD15CgojCiMgQ29yZSBOZXRmaWx0ZXIgQ29u
ZmlndXJhdGlvbgojCkNPTkZJR19ORVRGSUxURVJfTkVUTElOSz1tCkNPTkZJR19ORVRGSUxURVJf
TkVUTElOS19RVUVVRT1tCkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19MT0c9bQpDT05GSUdfTkZf
Q09OTlRSQUNLPW0KQ09ORklHX05GX0NPTk5UUkFDS19NQVJLPXkKQ09ORklHX05GX0NPTk5UUkFD
S19TRUNNQVJLPXkKQ09ORklHX05GX0NPTk5UUkFDS19FVkVOVFM9eQojIENPTkZJR19ORl9DT05O
VFJBQ0tfVElNRVNUQU1QIGlzIG5vdCBzZXQKQ09ORklHX05GX0NUX1BST1RPX0RDQ1A9bQpDT05G
SUdfTkZfQ1RfUFJPVE9fR1JFPW0KQ09ORklHX05GX0NUX1BST1RPX1NDVFA9bQpDT05GSUdfTkZf
Q1RfUFJPVE9fVURQTElURT1tCkNPTkZJR19ORl9DT05OVFJBQ0tfQU1BTkRBPW0KQ09ORklHX05G
X0NPTk5UUkFDS19GVFA9bQpDT05GSUdfTkZfQ09OTlRSQUNLX0gzMjM9bQpDT05GSUdfTkZfQ09O
TlRSQUNLX0lSQz1tCkNPTkZJR19ORl9DT05OVFJBQ0tfQlJPQURDQVNUPW0KQ09ORklHX05GX0NP
Tk5UUkFDS19ORVRCSU9TX05TPW0KIyBDT05GSUdfTkZfQ09OTlRSQUNLX1NOTVAgaXMgbm90IHNl
dApDT05GSUdfTkZfQ09OTlRSQUNLX1BQVFA9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NBTkU9bQpD
T05GSUdfTkZfQ09OTlRSQUNLX1NJUD1tCkNPTkZJR19ORl9DT05OVFJBQ0tfVEZUUD1tCkNPTkZJ
R19ORl9DVF9ORVRMSU5LPW0KQ09ORklHX05FVEZJTFRFUl9UUFJPWFk9bQpDT05GSUdfTkVURklM
VEVSX1hUQUJMRVM9bQoKIwojIFh0YWJsZXMgY29tYmluZWQgbW9kdWxlcwojCkNPTkZJR19ORVRG
SUxURVJfWFRfTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfQ09OTk1BUks9bQoKIwojIFh0YWJs
ZXMgdGFyZ2V0cwojCiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQVVESVQgaXMgbm90IHNl
dAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NIRUNLU1VNIGlzIG5vdCBzZXQKQ09ORklH
X05FVEZJTFRFUl9YVF9UQVJHRVRfQ0xBU1NJRlk9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdF
VF9DT05OTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NPTk5TRUNNQVJLPW0KIyBD
T05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9DVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJf
WFRfVEFSR0VUX0RTQ1A9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9ITD1tCiMgQ09ORklH
X05FVEZJTFRFUl9YVF9UQVJHRVRfSURMRVRJTUVSIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfTEVEPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTUFSSz1tCkNPTkZJ
R19ORVRGSUxURVJfWFRfVEFSR0VUX05GTE9HPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRf
TkZRVUVVRT1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05PVFJBQ0s9bQpDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9SQVRFRVNUPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9U
RUUgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUFJPWFk9bQpDT05GSUdf
TkVURklMVEVSX1hUX1RBUkdFVF9UUkFDRT1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1NF
Q01BUks9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BNU1M9bQpDT05GSUdfTkVURklM
VEVSX1hUX1RBUkdFVF9UQ1BPUFRTVFJJUD1tCgojCiMgWHRhYmxlcyBtYXRjaGVzCiMKIyBDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX0FERFJUWVBFIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRF
Ul9YVF9NQVRDSF9DTFVTVEVSPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT01NRU5UPW0K
Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OQllURVM9bQpDT05GSUdfTkVURklMVEVSX1hU
X01BVENIX0NPTk5MSU1JVD1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTk1BUks9bQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5UUkFDSz1tCiMgQ09ORklHX05FVEZJTFRFUl9Y
VF9NQVRDSF9DUFUgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0RDQ1A9bQoj
IENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfREVWR1JPVVAgaXMgbm90IHNldApDT05GSUdfTkVU
RklMVEVSX1hUX01BVENIX0RTQ1A9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VTUD1tCkNP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEFTSExJTUlUPW0KQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9IRUxQRVI9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0hMPW0KQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9JUFJBTkdFPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQVlMg
aXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xFTkdUSD1tCkNPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfTElNSVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz1tCkNP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hf
TVVMVElQT1JUPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9PU0Y9bQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX09XTkVSPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9QT0xJQ1k9bQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX1BLVFRZUEU9bQpDT05GSUdfTkVURklMVEVSX1hUX01B
VENIX1FVT1RBPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9SQVRFRVNUPW0KQ09ORklHX05F
VEZJTFRFUl9YVF9NQVRDSF9SRUFMTT1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVDRU5U
PW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TQ1RQPW0KQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9TT0NLRVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRFPW0KQ09ORklHX05F
VEZJTFRFUl9YVF9NQVRDSF9TVEFUSVNUSUM9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NU
UklORz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVENQTVNTPW0KQ09ORklHX05FVEZJTFRF
Ul9YVF9NQVRDSF9USU1FPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9VMzI9bQojIENPTkZJ
R19JUF9TRVQgaXMgbm90IHNldApDT05GSUdfSVBfVlM9bQpDT05GSUdfSVBfVlNfSVBWNj15CiMg
Q09ORklHX0lQX1ZTX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0lQX1ZTX1RBQl9CSVRTPTEyCgoj
CiMgSVBWUyB0cmFuc3BvcnQgcHJvdG9jb2wgbG9hZCBiYWxhbmNpbmcgc3VwcG9ydAojCkNPTkZJ
R19JUF9WU19QUk9UT19UQ1A9eQpDT05GSUdfSVBfVlNfUFJPVE9fVURQPXkKQ09ORklHX0lQX1ZT
X1BST1RPX0FIX0VTUD15CkNPTkZJR19JUF9WU19QUk9UT19FU1A9eQpDT05GSUdfSVBfVlNfUFJP
VE9fQUg9eQojIENPTkZJR19JUF9WU19QUk9UT19TQ1RQIGlzIG5vdCBzZXQKCiMKIyBJUFZTIHNj
aGVkdWxlcgojCkNPTkZJR19JUF9WU19SUj1tCkNPTkZJR19JUF9WU19XUlI9bQpDT05GSUdfSVBf
VlNfTEM9bQpDT05GSUdfSVBfVlNfV0xDPW0KQ09ORklHX0lQX1ZTX0xCTEM9bQpDT05GSUdfSVBf
VlNfTEJMQ1I9bQpDT05GSUdfSVBfVlNfREg9bQpDT05GSUdfSVBfVlNfU0g9bQpDT05GSUdfSVBf
VlNfU0VEPW0KQ09ORklHX0lQX1ZTX05RPW0KCiMKIyBJUFZTIGFwcGxpY2F0aW9uIGhlbHBlcgoj
CkNPTkZJR19JUF9WU19GVFA9bQpDT05GSUdfSVBfVlNfTkZDVD15CiMgQ09ORklHX0lQX1ZTX1BF
X1NJUCBpcyBub3Qgc2V0CgojCiMgSVA6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKQ09ORklH
X05GX0RFRlJBR19JUFY0PW0KQ09ORklHX05GX0NPTk5UUkFDS19JUFY0PW0KQ09ORklHX05GX0NP
Tk5UUkFDS19QUk9DX0NPTVBBVD15CkNPTkZJR19JUF9ORl9RVUVVRT1tCkNPTkZJR19JUF9ORl9J
UFRBQkxFUz1tCkNPTkZJR19JUF9ORl9NQVRDSF9BSD1tCkNPTkZJR19JUF9ORl9NQVRDSF9FQ049
bQpDT05GSUdfSVBfTkZfTUFUQ0hfVFRMPW0KQ09ORklHX0lQX05GX0ZJTFRFUj1tCkNPTkZJR19J
UF9ORl9UQVJHRVRfUkVKRUNUPW0KQ09ORklHX0lQX05GX1RBUkdFVF9MT0c9bQpDT05GSUdfSVBf
TkZfVEFSR0VUX1VMT0c9bQpDT05GSUdfTkZfTkFUPW0KQ09ORklHX05GX05BVF9ORUVERUQ9eQpD
T05GSUdfSVBfTkZfVEFSR0VUX01BU1FVRVJBREU9bQpDT05GSUdfSVBfTkZfVEFSR0VUX05FVE1B
UD1tCkNPTkZJR19JUF9ORl9UQVJHRVRfUkVESVJFQ1Q9bQpDT05GSUdfTkZfTkFUX1BST1RPX0RD
Q1A9bQpDT05GSUdfTkZfTkFUX1BST1RPX0dSRT1tCkNPTkZJR19ORl9OQVRfUFJPVE9fVURQTElU
RT1tCkNPTkZJR19ORl9OQVRfUFJPVE9fU0NUUD1tCkNPTkZJR19ORl9OQVRfRlRQPW0KQ09ORklH
X05GX05BVF9JUkM9bQpDT05GSUdfTkZfTkFUX1RGVFA9bQpDT05GSUdfTkZfTkFUX0FNQU5EQT1t
CkNPTkZJR19ORl9OQVRfUFBUUD1tCkNPTkZJR19ORl9OQVRfSDMyMz1tCkNPTkZJR19ORl9OQVRf
U0lQPW0KQ09ORklHX0lQX05GX01BTkdMRT1tCkNPTkZJR19JUF9ORl9UQVJHRVRfQ0xVU1RFUklQ
PW0KQ09ORklHX0lQX05GX1RBUkdFVF9FQ049bQpDT05GSUdfSVBfTkZfVEFSR0VUX1RUTD1tCkNP
TkZJR19JUF9ORl9SQVc9bQpDT05GSUdfSVBfTkZfQVJQVEFCTEVTPW0KQ09ORklHX0lQX05GX0FS
UEZJTFRFUj1tCkNPTkZJR19JUF9ORl9BUlBfTUFOR0xFPW0KCiMKIyBJUHY2OiBOZXRmaWx0ZXIg
Q29uZmlndXJhdGlvbgojCkNPTkZJR19ORl9ERUZSQUdfSVBWNj1tCkNPTkZJR19ORl9DT05OVFJB
Q0tfSVBWNj1tCkNPTkZJR19JUDZfTkZfUVVFVUU9bQpDT05GSUdfSVA2X05GX0lQVEFCTEVTPW0K
Q09ORklHX0lQNl9ORl9NQVRDSF9BSD1tCkNPTkZJR19JUDZfTkZfTUFUQ0hfRVVJNjQ9bQpDT05G
SUdfSVA2X05GX01BVENIX0ZSQUc9bQpDT05GSUdfSVA2X05GX01BVENIX09QVFM9bQpDT05GSUdf
SVA2X05GX01BVENIX0hMPW0KQ09ORklHX0lQNl9ORl9NQVRDSF9JUFY2SEVBREVSPW0KQ09ORklH
X0lQNl9ORl9NQVRDSF9NSD1tCkNPTkZJR19JUDZfTkZfTUFUQ0hfUlQ9bQpDT05GSUdfSVA2X05G
X1RBUkdFVF9ITD1tCkNPTkZJR19JUDZfTkZfVEFSR0VUX0xPRz1tCkNPTkZJR19JUDZfTkZfRklM
VEVSPW0KQ09ORklHX0lQNl9ORl9UQVJHRVRfUkVKRUNUPW0KQ09ORklHX0lQNl9ORl9NQU5HTEU9
bQpDT05GSUdfSVA2X05GX1JBVz1tCiMgQ09ORklHX0lQX0RDQ1AgaXMgbm90IHNldAojIENPTkZJ
R19JUF9TQ1RQIGlzIG5vdCBzZXQKIyBDT05GSUdfUkRTIGlzIG5vdCBzZXQKIyBDT05GSUdfVElQ
QyBpcyBub3Qgc2V0CiMgQ09ORklHX0FUTSBpcyBub3Qgc2V0CiMgQ09ORklHX0wyVFAgaXMgbm90
IHNldAojIENPTkZJR19CUklER0UgaXMgbm90IHNldAojIENPTkZJR19ORVRfRFNBIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVkxBTl84MDIxUSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQ05FVCBpcyBub3Qg
c2V0CiMgQ09ORklHX0xMQzIgaXMgbm90IHNldAojIENPTkZJR19JUFggaXMgbm90IHNldAojIENP
TkZJR19BVEFMSyBpcyBub3Qgc2V0CiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0CiMgQ09ORklHX0xB
UEIgaXMgbm90IHNldAojIENPTkZJR19FQ09ORVQgaXMgbm90IHNldAojIENPTkZJR19XQU5fUk9V
VEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhPTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfSUVFRTgw
MjE1NCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfU0NIRUQ9eQoKIwojIFF1ZXVlaW5nL1NjaGVkdWxp
bmcKIwpDT05GSUdfTkVUX1NDSF9DQlE9bQpDT05GSUdfTkVUX1NDSF9IVEI9bQpDT05GSUdfTkVU
X1NDSF9IRlNDPW0KQ09ORklHX05FVF9TQ0hfUFJJTz1tCkNPTkZJR19ORVRfU0NIX01VTFRJUT1t
CkNPTkZJR19ORVRfU0NIX1JFRD1tCiMgQ09ORklHX05FVF9TQ0hfU0ZCIGlzIG5vdCBzZXQKQ09O
RklHX05FVF9TQ0hfU0ZRPW0KQ09ORklHX05FVF9TQ0hfVEVRTD1tCkNPTkZJR19ORVRfU0NIX1RC
Rj1tCkNPTkZJR19ORVRfU0NIX0dSRUQ9bQpDT05GSUdfTkVUX1NDSF9EU01BUks9bQpDT05GSUdf
TkVUX1NDSF9ORVRFTT1tCkNPTkZJR19ORVRfU0NIX0RSUj1tCiMgQ09ORklHX05FVF9TQ0hfTVFQ
UklPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9DSE9LRSBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9TQ0hfUUZRIGlzIG5vdCBzZXQKQ09ORklHX05FVF9TQ0hfSU5HUkVTUz1tCgojCiMgQ2xh
c3NpZmljYXRpb24KIwpDT05GSUdfTkVUX0NMUz15CkNPTkZJR19ORVRfQ0xTX0JBU0lDPW0KQ09O
RklHX05FVF9DTFNfVENJTkRFWD1tCkNPTkZJR19ORVRfQ0xTX1JPVVRFND1tCkNPTkZJR19ORVRf
Q0xTX0ZXPW0KQ09ORklHX05FVF9DTFNfVTMyPW0KQ09ORklHX0NMU19VMzJfUEVSRj15CkNPTkZJ
R19DTFNfVTMyX01BUks9eQpDT05GSUdfTkVUX0NMU19SU1ZQPW0KQ09ORklHX05FVF9DTFNfUlNW
UDY9bQpDT05GSUdfTkVUX0NMU19GTE9XPW0KQ09ORklHX05FVF9DTFNfQ0dST1VQPXkKQ09ORklH
X05FVF9FTUFUQ0g9eQpDT05GSUdfTkVUX0VNQVRDSF9TVEFDSz0zMgpDT05GSUdfTkVUX0VNQVRD
SF9DTVA9bQpDT05GSUdfTkVUX0VNQVRDSF9OQllURT1tCkNPTkZJR19ORVRfRU1BVENIX1UzMj1t
CkNPTkZJR19ORVRfRU1BVENIX01FVEE9bQpDT05GSUdfTkVUX0VNQVRDSF9URVhUPW0KQ09ORklH
X05FVF9DTFNfQUNUPXkKQ09ORklHX05FVF9BQ1RfUE9MSUNFPW0KQ09ORklHX05FVF9BQ1RfR0FD
VD1tCkNPTkZJR19HQUNUX1BST0I9eQpDT05GSUdfTkVUX0FDVF9NSVJSRUQ9bQpDT05GSUdfTkVU
X0FDVF9JUFQ9bQpDT05GSUdfTkVUX0FDVF9OQVQ9bQpDT05GSUdfTkVUX0FDVF9QRURJVD1tCkNP
TkZJR19ORVRfQUNUX1NJTVA9bQpDT05GSUdfTkVUX0FDVF9TS0JFRElUPW0KIyBDT05GSUdfTkVU
X0FDVF9DU1VNIGlzIG5vdCBzZXQKQ09ORklHX05FVF9DTFNfSU5EPXkKQ09ORklHX05FVF9TQ0hf
RklGTz15CkNPTkZJR19EQ0I9eQojIENPTkZJR19CQVRNQU5fQURWIGlzIG5vdCBzZXQKQ09ORklH
X1JQUz15CkNPTkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKQ09ORklHX0hBVkVfQlBGX0pJ
VD15CiMgQ09ORklHX0JQRl9KSVQgaXMgbm90IHNldAoKIwojIE5ldHdvcmsgdGVzdGluZwojCkNP
TkZJR19ORVRfUEtUR0VOPW0KIyBDT05GSUdfTkVUX1RDUFBST0JFIGlzIG5vdCBzZXQKQ09ORklH
X05FVF9EUk9QX01PTklUT1I9eQojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0CiMgQ09ORklH
X0NBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lSREEgaXMgbm90IHNldAojIENPTkZJR19CVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQKQ09ORklHX0ZJQl9SVUxFUz15CiMg
Q09ORklHX1dJUkVMRVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfV0lNQVggaXMgbm90IHNldAojIENP
TkZJR19SRktJTEwgaXMgbm90IHNldAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNldAojIENPTkZJ
R19DQUlGIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNldAoKIwojIERldmlj
ZSBEcml2ZXJzCiMKCiMKIyBHZW5lcmljIERyaXZlciBPcHRpb25zCiMKQ09ORklHX1VFVkVOVF9I
RUxQRVJfUEFUSD0iIgpDT05GSUdfREVWVE1QRlM9eQojIENPTkZJR19ERVZUTVBGU19NT1VOVCBp
cyBub3Qgc2V0CkNPTkZJR19TVEFOREFMT05FPXkKQ09ORklHX1BSRVZFTlRfRklSTVdBUkVfQlVJ
TEQ9eQpDT05GSUdfRldfTE9BREVSPXkKIyBDT05GSUdfRklSTVdBUkVfSU5fS0VSTkVMIGlzIG5v
dCBzZXQKQ09ORklHX0VYVFJBX0ZJUk1XQVJFPSIiCiMgQ09ORklHX0RFQlVHX0RSSVZFUiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RFQlVHX0RFVlJFUyBpcyBub3Qgc2V0CkNPTkZJR19TWVNfSFlQRVJW
SVNPUj15CkNPTkZJR19TUl9SRVBPUlRfVElNRV9MSU1JVD0xMDAKIyBDT05GSUdfQ09OTkVDVE9S
IGlzIG5vdCBzZXQKIyBDT05GSUdfTVREIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFSUE9SVCBpcyBu
b3Qgc2V0CkNPTkZJR19QTlA9eQojIENPTkZJR19QTlBfREVCVUdfTUVTU0FHRVMgaXMgbm90IHNl
dAoKIwojIFByb3RvY29scwojCkNPTkZJR19QTlBBQ1BJPXkKQ09ORklHX0JMS19ERVY9eQojIENP
TkZJR19CTEtfREVWX0ZEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NQUV9EQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfREFD
OTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9VTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdf
QkxLX0RFVl9DT1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD15CiMgQ09O
RklHX0JMS19ERVZfQ1JZUFRPTE9PUCBpcyBub3Qgc2V0CgojCiMgRFJCRCBkaXNhYmxlZCBiZWNh
dXNlIFBST0NfRlMsIElORVQgb3IgQ09OTkVDVE9SIG5vdCBzZWxlY3RlZAojCiMgQ09ORklHX0JM
S19ERVZfTkJEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9TWDggaXMgbm90IHNldAojIENP
TkZJR19CTEtfREVWX1VCIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfUkFNPXkKQ09ORklHX0JM
S19ERVZfUkFNX0NPVU5UPTE2CkNPTkZJR19CTEtfREVWX1JBTV9TSVpFPTY1NTM2CiMgQ09ORklH
X0JMS19ERVZfWElQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0RST01fUEtUQ0RWRCBpcyBub3Qgc2V0
CiMgQ09ORklHX0FUQV9PVkVSX0VUSCBpcyBub3Qgc2V0CkNPTkZJR19YRU5fQkxLREVWX0ZST05U
RU5EPXkKIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfUkJE
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MSVMzTFYwMkQgaXMgbm90IHNldApDT05GSUdf
TUlTQ19ERVZJQ0VTPXkKIyBDT05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90IHNldAojIENPTkZJR19J
Qk1fQVNNIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhBTlRPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
VEVMX01JRF9QVEkgaXMgbm90IHNldAojIENPTkZJR19TR0lfSU9DNCBpcyBub3Qgc2V0CiMgQ09O
RklHX1RJRk1fQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lDUzkzMlM0MDEgaXMgbm90IHNldAoj
IENPTkZJR19FTkNMT1NVUkVfU0VSVklDRVMgaXMgbm90IHNldAojIENPTkZJR19IUF9JTE8gaXMg
bm90IHNldAojIENPTkZJR19BUERTOTgwMkFMUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTTDI5MDAz
IGlzIG5vdCBzZXQKIyBDT05GSUdfSVNMMjkwMjAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X1RTTDI1NTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0JIMTc4MCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BUERTOTkw
WCBpcyBub3Qgc2V0CiMgQ09ORklHX0hNQzYzNTIgaXMgbm90IHNldAojIENPTkZJR19EUzE2ODIg
aXMgbm90IHNldAojIENPTkZJR19WTVdBUkVfQkFMTE9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX0JN
UDA4NSBpcyBub3Qgc2V0CiMgQ09ORklHX1BDSF9QSFVCIGlzIG5vdCBzZXQKIyBDT05GSUdfQzJQ
T1JUIGlzIG5vdCBzZXQKCiMKIyBFRVBST00gc3VwcG9ydAojCkNPTkZJR19FRVBST01fQVQyND1t
CkNPTkZJR19FRVBST01fTEVHQUNZPW0KQ09ORklHX0VFUFJPTV9NQVg2ODc1PW0KQ09ORklHX0VF
UFJPTV85M0NYNj1tCiMgQ09ORklHX0NCNzEwX0NPUkUgaXMgbm90IHNldAoKIwojIFRleGFzIElu
c3RydW1lbnRzIHNoYXJlZCB0cmFuc3BvcnQgbGluZSBkaXNjaXBsaW5lCiMKIyBDT05GSUdfVElf
U1QgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xJUzNfSTJDIGlzIG5vdCBzZXQKQ09ORklH
X0hBVkVfSURFPXkKIyBDT05GSUdfSURFIGlzIG5vdCBzZXQKCiMKIyBTQ1NJIGRldmljZSBzdXBw
b3J0CiMKQ09ORklHX1NDU0lfTU9EPXkKQ09ORklHX1JBSURfQVRUUlM9bQpDT05GSUdfU0NTST15
CkNPTkZJR19TQ1NJX0RNQT15CkNPTkZJR19TQ1NJX1RHVD1tCkNPTkZJR19TQ1NJX05FVExJTks9
eQpDT05GSUdfU0NTSV9QUk9DX0ZTPXkKCiMKIyBTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywgdGFw
ZSwgQ0QtUk9NKQojCiMgQ09ORklHX0JMS19ERVZfU0QgaXMgbm90IHNldAojIENPTkZJR19DSFJf
REVWX1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hSX0RFVl9PU1NUIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkxLX0RFVl9TUiBpcyBub3Qgc2V0CiMgQ09ORklHX0NIUl9ERVZfU0cgaXMgbm90IHNldAoj
IENPTkZJR19DSFJfREVWX1NDSCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CkNP
TkZJR19TQ1NJX0NPTlNUQU5UUz15CkNPTkZJR19TQ1NJX0xPR0dJTkc9eQpDT05GSUdfU0NTSV9T
Q0FOX0FTWU5DPXkKQ09ORklHX1NDU0lfV0FJVF9TQ0FOPW0KCiMKIyBTQ1NJIFRyYW5zcG9ydHMK
IwpDT05GSUdfU0NTSV9TUElfQVRUUlM9bQpDT05GSUdfU0NTSV9GQ19BVFRSUz1tCkNPTkZJR19T
Q1NJX0ZDX1RHVF9BVFRSUz15CkNPTkZJR19TQ1NJX0lTQ1NJX0FUVFJTPW0KQ09ORklHX1NDU0lf
U0FTX0FUVFJTPW0KQ09ORklHX1NDU0lfU0FTX0xJQlNBUz1tCkNPTkZJR19TQ1NJX1NBU19BVEE9
eQpDT05GSUdfU0NTSV9TQVNfSE9TVF9TTVA9eQpDT05GSUdfU0NTSV9TUlBfQVRUUlM9bQpDT05G
SUdfU0NTSV9TUlBfVEdUX0FUVFJTPXkKQ09ORklHX1NDU0lfTE9XTEVWRUw9eQpDT05GSUdfSVND
U0lfVENQPW0KQ09ORklHX0lTQ1NJX0JPT1RfU1lTRlM9bQpDT05GSUdfU0NTSV9DWEdCM19JU0NT
ST1tCiMgQ09ORklHX1NDU0lfQ1hHQjRfSVNDU0kgaXMgbm90IHNldApDT05GSUdfU0NTSV9CTlgy
X0lTQ1NJPW0KIyBDT05GSUdfU0NTSV9CTlgyWF9GQ09FIGlzIG5vdCBzZXQKQ09ORklHX0JFMklT
Q1NJPW0KQ09ORklHX0JMS19ERVZfM1dfWFhYWF9SQUlEPW0KQ09ORklHX1NDU0lfSFBTQT1tCkNP
TkZJR19TQ1NJXzNXXzlYWFg9bQpDT05GSUdfU0NTSV8zV19TQVM9bQpDT05GSUdfU0NTSV9BQ0FS
RD1tCkNPTkZJR19TQ1NJX0FBQ1JBSUQ9bQpDT05GSUdfU0NTSV9BSUM3WFhYPW0KQ09ORklHX0FJ
QzdYWFhfQ01EU19QRVJfREVWSUNFPTgKQ09ORklHX0FJQzdYWFhfUkVTRVRfREVMQVlfTVM9MTUw
MDAKQ09ORklHX0FJQzdYWFhfREVCVUdfRU5BQkxFPXkKQ09ORklHX0FJQzdYWFhfREVCVUdfTUFT
Sz0wCkNPTkZJR19BSUM3WFhYX1JFR19QUkVUVFlfUFJJTlQ9eQpDT05GSUdfU0NTSV9BSUM3WFhY
X09MRD1tCkNPTkZJR19TQ1NJX0FJQzc5WFg9bQpDT05GSUdfQUlDNzlYWF9DTURTX1BFUl9ERVZJ
Q0U9MzIKQ09ORklHX0FJQzc5WFhfUkVTRVRfREVMQVlfTVM9MTUwMDAKQ09ORklHX0FJQzc5WFhf
REVCVUdfRU5BQkxFPXkKQ09ORklHX0FJQzc5WFhfREVCVUdfTUFTSz0wCkNPTkZJR19BSUM3OVhY
X1JFR19QUkVUVFlfUFJJTlQ9eQpDT05GSUdfU0NTSV9BSUM5NFhYPW0KIyBDT05GSUdfQUlDOTRY
WF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX01WU0FTPW0KIyBDT05GSUdfU0NTSV9NVlNB
U19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0RQVF9JMk89bQpDT05GSUdfU0NTSV9BRFZB
TlNZUz1tCkNPTkZJR19TQ1NJX0FSQ01TUj1tCiMgQ09ORklHX1NDU0lfQVJDTVNSX0FFUiBpcyBu
b3Qgc2V0CkNPTkZJR19NRUdBUkFJRF9ORVdHRU49eQpDT05GSUdfTUVHQVJBSURfTU09bQpDT05G
SUdfTUVHQVJBSURfTUFJTEJPWD1tCkNPTkZJR19NRUdBUkFJRF9MRUdBQ1k9bQpDT05GSUdfTUVH
QVJBSURfU0FTPW0KQ09ORklHX1NDU0lfTVBUMlNBUz1tCkNPTkZJR19TQ1NJX01QVDJTQVNfTUFY
X1NHRT0xMjgKIyBDT05GSUdfU0NTSV9NUFQyU0FTX0xPR0dJTkcgaXMgbm90IHNldApDT05GSUdf
U0NTSV9IUFRJT1A9bQpDT05GSUdfU0NTSV9CVVNMT0dJQz1tCkNPTkZJR19WTVdBUkVfUFZTQ1NJ
PW0KQ09ORklHX0xJQkZDPW0KQ09ORklHX0xJQkZDT0U9bQpDT05GSUdfRkNPRT1tCkNPTkZJR19G
Q09FX0ZOSUM9bQpDT05GSUdfU0NTSV9ETVgzMTkxRD1tCkNPTkZJR19TQ1NJX0VBVEE9bQpDT05G
SUdfU0NTSV9FQVRBX1RBR0dFRF9RVUVVRT15CkNPTkZJR19TQ1NJX0VBVEFfTElOS0VEX0NPTU1B
TkRTPXkKQ09ORklHX1NDU0lfRUFUQV9NQVhfVEFHUz0xNgpDT05GSUdfU0NTSV9GVVRVUkVfRE9N
QUlOPW0KQ09ORklHX1NDU0lfR0RUSD1tCiMgQ09ORklHX1NDU0lfSVNDSSBpcyBub3Qgc2V0CkNP
TkZJR19TQ1NJX0lQUz1tCkNPTkZJR19TQ1NJX0lOSVRJTz1tCkNPTkZJR19TQ1NJX0lOSUExMDA9
bQpDT05GSUdfU0NTSV9TVEVYPW0KQ09ORklHX1NDU0lfU1lNNTNDOFhYXzI9bQpDT05GSUdfU0NT
SV9TWU01M0M4WFhfRE1BX0FERFJFU1NJTkdfTU9ERT0xCkNPTkZJR19TQ1NJX1NZTTUzQzhYWF9E
RUZBVUxUX1RBR1M9MTYKQ09ORklHX1NDU0lfU1lNNTNDOFhYX01BWF9UQUdTPTY0CkNPTkZJR19T
Q1NJX1NZTTUzQzhYWF9NTUlPPXkKQ09ORklHX1NDU0lfSVBSPW0KIyBDT05GSUdfU0NTSV9JUFJf
VFJBQ0UgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lQUl9EVU1QIGlzIG5vdCBzZXQKQ09ORklH
X1NDU0lfUUxPR0lDXzEyODA9bQpDT05GSUdfU0NTSV9RTEFfRkM9bQpDT05GSUdfU0NTSV9RTEFf
SVNDU0k9bQpDT05GSUdfU0NTSV9MUEZDPW0KIyBDT05GSUdfU0NTSV9MUEZDX0RFQlVHX0ZTIGlz
IG5vdCBzZXQKQ09ORklHX1NDU0lfREMzOTV4PW0KQ09ORklHX1NDU0lfREMzOTBUPW0KQ09ORklH
X1NDU0lfREVCVUc9bQpDT05GSUdfU0NTSV9QTUNSQUlEPW0KQ09ORklHX1NDU0lfUE04MDAxPW0K
Q09ORklHX1NDU0lfU1JQPW0KQ09ORklHX1NDU0lfQkZBX0ZDPW0KIyBDT05GSUdfU0NTSV9ESCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19B
VEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJP
U0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRy
b2xsZXJzIHdpdGggbm9uLVNGRiBuYXRpdmUgaW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDST15
CiMgQ09ORklHX1NBVEFfQUhDSV9QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfSU5J
QzE2MlggaXMgbm90IHNldAojIENPTkZJR19TQVRBX0FDQVJEX0FIQ0kgaXMgbm90IHNldAojIENP
TkZJR19TQVRBX1NJTDI0IGlzIG5vdCBzZXQKQ09ORklHX0FUQV9TRkY9eQoKIwojIFNGRiBjb250
cm9sbGVycyB3aXRoIGN1c3RvbSBETUEgaW50ZXJmYWNlCiMKIyBDT05GSUdfUERDX0FETUEgaXMg
bm90IHNldAojIENPTkZJR19TQVRBX1FTVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9TWDQg
aXMgbm90IHNldApDT05GSUdfQVRBX0JNRE1BPXkKCiMKIyBTQVRBIFNGRiBjb250cm9sbGVycyB3
aXRoIEJNRE1BCiMKIyBDT05GSUdfQVRBX1BJSVggaXMgbm90IHNldAojIENPTkZJR19TQVRBX01W
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9OViBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfUFJP
TUlTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FU
QV9TSVMgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NWVyBpcyBub3Qgc2V0CiMgQ09ORklHX1NB
VEFfVUxJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9WSUEgaXMgbm90IHNldAojIENPTkZJR19T
QVRBX1ZJVEVTU0UgaXMgbm90IHNldAoKIwojIFBBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1E
TUEKIwojIENPTkZJR19QQVRBX0FMSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQU1EIGlzIG5v
dCBzZXQKIyBDT05GSUdfUEFUQV9BUkFTQU5fQ0YgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0FS
VE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BVElJWFAgaXMgbm90IHNldAojIENPTkZJR19Q
QVRBX0FUUDg2N1ggaXMgbm90IHNldAojIENPTkZJR19QQVRBX0NNRDY0WCBpcyBub3Qgc2V0CiMg
Q09ORklHX1BBVEFfQ1M1NTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9DUzU1MzAgaXMgbm90
IHNldAojIENPTkZJR19QQVRBX0NTNTUzNiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQ1lQUkVT
UyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfRUZBUiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFf
SFBUMzY2IGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9IUFQzN1ggaXMgbm90IHNldAojIENPTkZJ
R19QQVRBX0hQVDNYMk4gaXMgbm90IHNldAojIENPTkZJR19QQVRBX0hQVDNYMyBpcyBub3Qgc2V0
CiMgQ09ORklHX1BBVEFfSVQ4MjEzIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9JVDgyMVggaXMg
bm90IHNldAojIENPTkZJR19QQVRBX0pNSUNST04gaXMgbm90IHNldAojIENPTkZJR19QQVRBX01B
UlZFTEwgaXMgbm90IHNldAojIENPTkZJR19QQVRBX05FVENFTEwgaXMgbm90IHNldAojIENPTkZJ
R19QQVRBX05JTkpBMzIgaXMgbm90IHNldAojIENPTkZJR19QQVRBX05TODc0MTUgaXMgbm90IHNl
dAojIENPTkZJR19QQVRBX09MRFBJSVggaXMgbm90IHNldAojIENPTkZJR19QQVRBX09QVElETUEg
aXMgbm90IHNldAojIENPTkZJR19QQVRBX1BEQzIwMjdYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFU
QV9QRENfT0xEIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9SQURJU1lTIGlzIG5vdCBzZXQKIyBD
T05GSUdfUEFUQV9SREMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1NDMTIwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX1BBVEFfU0NIIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9TRVJWRVJXT1JLUyBp
cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfU0lMNjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9T
SVMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1RPU0hJQkEgaXMgbm90IHNldAojIENPTkZJR19Q
QVRBX1RSSUZMRVggaXMgbm90IHNldAojIENPTkZJR19QQVRBX1ZJQSBpcyBub3Qgc2V0CiMgQ09O
RklHX1BBVEFfV0lOQk9ORCBpcyBub3Qgc2V0CgojCiMgUElPLW9ubHkgU0ZGIGNvbnRyb2xsZXJz
CiMKIyBDT05GSUdfUEFUQV9DTUQ2NDBfUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9NUElJ
WCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfTlM4NzQxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1BB
VEFfT1BUSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfUExBVEZPUk0gaXMgbm90IHNldAojIENP
TkZJR19QQVRBX1JaMTAwMCBpcyBub3Qgc2V0CgojCiMgR2VuZXJpYyBmYWxsYmFjayAvIGxlZ2Fj
eSBkcml2ZXJzCiMKIyBDT05GSUdfUEFUQV9BQ1BJIGlzIG5vdCBzZXQKQ09ORklHX0FUQV9HRU5F
UklDPXkKIyBDT05GSUdfUEFUQV9MRUdBQ1kgaXMgbm90IHNldAojIENPTkZJR19NRCBpcyBub3Qg
c2V0CiMgQ09ORklHX1RBUkdFVF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVTSU9OIGlzIG5v
dCBzZXQKCiMKIyBJRUVFIDEzOTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMKQ09ORklHX0ZJUkVXSVJF
PW0KQ09ORklHX0ZJUkVXSVJFX09IQ0k9bQpDT05GSUdfRklSRVdJUkVfT0hDSV9ERUJVRz15CkNP
TkZJR19GSVJFV0lSRV9TQlAyPW0KQ09ORklHX0ZJUkVXSVJFX05FVD1tCiMgQ09ORklHX0ZJUkVX
SVJFX05PU1kgaXMgbm90IHNldAojIENPTkZJR19JMk8gaXMgbm90IHNldAojIENPTkZJR19NQUNJ
TlRPU0hfRFJJVkVSUyBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZJQ0VTPXkKIyBDT05GSUdfSUZC
IGlzIG5vdCBzZXQKIyBDT05GSUdfRFVNTVkgaXMgbm90IHNldAojIENPTkZJR19CT05ESU5HIGlz
IG5vdCBzZXQKIyBDT05GSUdfTUFDVkxBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0VRVUFMSVpFUiBp
cyBub3Qgc2V0CiMgQ09ORklHX1RVTiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZFVEggaXMgbm90IHNl
dAojIENPTkZJR19ORVRfU0IxMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDTkVUIGlzIG5vdCBz
ZXQKQ09ORklHX01JST15CiMgQ09ORklHX1BIWUxJQiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9F
VEhFUk5FVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZfMTAwMD15CiMgQ09ORklHX0FDRU5JQyBp
cyBub3Qgc2V0CiMgQ09ORklHX0RMMksgaXMgbm90IHNldAojIENPTkZJR19FMTAwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX0UxMDAwRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lQMTAwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX0lHQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lHQlZGIGlzIG5vdCBzZXQKIyBDT05G
SUdfTlM4MzgyMCBpcyBub3Qgc2V0CiMgQ09ORklHX0hBTUFDSEkgaXMgbm90IHNldAojIENPTkZJ
R19ZRUxMT1dGSU4gaXMgbm90IHNldAojIENPTkZJR19SODE2OSBpcyBub3Qgc2V0CiMgQ09ORklH
X1NJUzE5MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NLR0UgaXMgbm90IHNldAojIENPTkZJR19TS1ky
IGlzIG5vdCBzZXQKIyBDT05GSUdfVklBX1ZFTE9DSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfVElH
T04zIGlzIG5vdCBzZXQKQ09ORklHX0JOWDI9bQpDT05GSUdfQ05JQz1tCiMgQ09ORklHX1FMQTNY
WFggaXMgbm90IHNldAojIENPTkZJR19BVEwxIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRMMUUgaXMg
bm90IHNldAojIENPTkZJR19BVEwxQyBpcyBub3Qgc2V0CiMgQ09ORklHX0pNRSBpcyBub3Qgc2V0
CiMgQ09ORklHX1NUTU1BQ19FVEggaXMgbm90IHNldAojIENPTkZJR19QQ0hfR0JFIGlzIG5vdCBz
ZXQKQ09ORklHX05FVERFVl8xMDAwMD15CkNPTkZJR19NRElPPW0KIyBDT05GSUdfQ0hFTFNJT19U
MSBpcyBub3Qgc2V0CkNPTkZJR19DSEVMU0lPX1QzPW0KIyBDT05GSUdfQ0hFTFNJT19UNCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NIRUxTSU9fVDRWRiBpcyBub3Qgc2V0CiMgQ09ORklHX0VOSUMgaXMg
bm90IHNldAojIENPTkZJR19JWEdCRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lYR0JFVkYgaXMgbm90
IHNldAojIENPTkZJR19JWEdCIGlzIG5vdCBzZXQKIyBDT05GSUdfUzJJTyBpcyBub3Qgc2V0CiMg
Q09ORklHX1ZYR0UgaXMgbm90IHNldAojIENPTkZJR19NWVJJMTBHRSBpcyBub3Qgc2V0CiMgQ09O
RklHX05FVFhFTl9OSUMgaXMgbm90IHNldAojIENPTkZJR19OSVUgaXMgbm90IHNldAojIENPTkZJ
R19NTFg0X0VOIGlzIG5vdCBzZXQKIyBDT05GSUdfTUxYNF9DT1JFIGlzIG5vdCBzZXQKIyBDT05G
SUdfVEVIVVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfQk5YMlggaXMgbm90IHNldAojIENPTkZJR19R
TENOSUMgaXMgbm90IHNldAojIENPTkZJR19RTEdFIGlzIG5vdCBzZXQKIyBDT05GSUdfQk5BIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0ZDIGlzIG5vdCBzZXQKIyBDT05GSUdfQkUyTkVUIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVFIgaXMgbm90IHNldAojIENPTkZJR19XTEFOIGlzIG5vdCBzZXQKCiMKIyBF
bmFibGUgV2lNQVggKE5ldHdvcmtpbmcgb3B0aW9ucykgdG8gc2VlIHRoZSBXaU1BWCBkcml2ZXJz
CiMKCiMKIyBVU0IgTmV0d29yayBBZGFwdGVycwojCkNPTkZJR19VU0JfQ0FUQz1tCkNPTkZJR19V
U0JfS0FXRVRIPW0KQ09ORklHX1VTQl9QRUdBU1VTPW0KQ09ORklHX1VTQl9SVEw4MTUwPW0KQ09O
RklHX1VTQl9VU0JORVQ9bQpDT05GSUdfVVNCX05FVF9BWDg4MTdYPW0KQ09ORklHX1VTQl9ORVRf
Q0RDRVRIRVI9bQpDT05GSUdfVVNCX05FVF9DRENfRUVNPW0KQ09ORklHX1VTQl9ORVRfQ0RDX05D
TT1tCkNPTkZJR19VU0JfTkVUX0RNOTYwMT1tCiMgQ09ORklHX1VTQl9ORVRfU01TQzc1WFggaXMg
bm90IHNldApDT05GSUdfVVNCX05FVF9TTVNDOTVYWD1tCkNPTkZJR19VU0JfTkVUX0dMNjIwQT1t
CkNPTkZJR19VU0JfTkVUX05FVDEwODA9bQpDT05GSUdfVVNCX05FVF9QTFVTQj1tCkNPTkZJR19V
U0JfTkVUX01DUzc4MzA9bQpDT05GSUdfVVNCX05FVF9STkRJU19IT1NUPW0KQ09ORklHX1VTQl9O
RVRfQ0RDX1NVQlNFVD1tCkNPTkZJR19VU0JfQUxJX001NjMyPXkKQ09ORklHX1VTQl9BTjI3MjA9
eQpDT05GSUdfVVNCX0JFTEtJTj15CkNPTkZJR19VU0JfQVJNTElOVVg9eQpDT05GSUdfVVNCX0VQ
U09OMjg4OD15CkNPTkZJR19VU0JfS0MyMTkwPXkKQ09ORklHX1VTQl9ORVRfWkFVUlVTPW0KIyBD
T05GSUdfVVNCX05FVF9DWDgyMzEwX0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfS0FM
TUlBIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9ORVRfSU5UNTFYMT1tCkNPTkZJR19VU0JfSVBIRVRI
PW0KIyBDT05GSUdfVVNCX1NJRVJSQV9ORVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfVkw2MDAg
aXMgbm90IHNldAojIENPTkZJR19XQU4gaXMgbm90IHNldAoKIwojIENBSUYgdHJhbnNwb3J0IGRy
aXZlcnMKIwpDT05GSUdfWEVOX05FVERFVl9GUk9OVEVORD15CiMgQ09ORklHX0ZEREkgaXMgbm90
IHNldAojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NMSVAgaXMgbm90IHNldAojIENPTkZJR19ORVRfRkMgaXMgbm90IHNldAojIENPTkZJ
R19ORVRDT05TT0xFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUUE9MTCBpcyBub3Qgc2V0CiMgQ09O
RklHX05FVF9QT0xMX0NPTlRST0xMRVIgaXMgbm90IHNldAojIENPTkZJR19WTVhORVQzIGlzIG5v
dCBzZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CiMgQ09ORklHX1BIT05FIGlzIG5vdCBzZXQK
CiMKIyBJbnB1dCBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJR19JTlBVVD15CkNPTkZJR19JTlBVVF9G
Rl9NRU1MRVNTPW0KQ09ORklHX0lOUFVUX1BPTExERVY9bQojIENPTkZJR19JTlBVVF9TUEFSU0VL
TUFQIGlzIG5vdCBzZXQKCiMKIyBVc2VybGFuZCBpbnRlcmZhY2VzCiMKQ09ORklHX0lOUFVUX01P
VVNFREVWPXkKIyBDT05GSUdfSU5QVVRfTU9VU0VERVZfUFNBVVggaXMgbm90IHNldApDT05GSUdf
SU5QVVRfTU9VU0VERVZfU0NSRUVOX1g9MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVO
X1k9NzY4CiMgQ09ORklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9FVkRF
Vj15CiMgQ09ORklHX0lOUFVUX0VWQlVHIGlzIG5vdCBzZXQKCiMKIyBJbnB1dCBEZXZpY2UgRHJp
dmVycwojCkNPTkZJR19JTlBVVF9LRVlCT0FSRD15CkNPTkZJR19LRVlCT0FSRF9BRFA1NTg4PW0K
IyBDT05GSUdfS0VZQk9BUkRfQURQNTU4OSBpcyBub3Qgc2V0CkNPTkZJR19LRVlCT0FSRF9BVEtC
RD15CiMgQ09ORklHX0tFWUJPQVJEX1FUMTA3MCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJE
X1FUMjE2MCBpcyBub3Qgc2V0CkNPTkZJR19LRVlCT0FSRF9MS0tCRD1tCiMgQ09ORklHX0tFWUJP
QVJEX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9HUElPX1BPTExFRCBpcyBub3Qg
c2V0CiMgQ09ORklHX0tFWUJPQVJEX1RDQTY0MTYgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FS
RF9NQVRSSVggaXMgbm90IHNldApDT05GSUdfS0VZQk9BUkRfTE04MzIzPW0KQ09ORklHX0tFWUJP
QVJEX01BWDczNTk9bQojIENPTkZJR19LRVlCT0FSRF9NQ1MgaXMgbm90IHNldAojIENPTkZJR19L
RVlCT0FSRF9NUFIxMjEgaXMgbm90IHNldApDT05GSUdfS0VZQk9BUkRfTkVXVE9OPW0KQ09ORklH
X0tFWUJPQVJEX09QRU5DT1JFUz1tCkNPTkZJR19LRVlCT0FSRF9TVE9XQVdBWT1tCkNPTkZJR19L
RVlCT0FSRF9TVU5LQkQ9bQpDT05GSUdfS0VZQk9BUkRfWFRLQkQ9bQpDT05GSUdfSU5QVVRfTU9V
U0U9eQpDT05GSUdfTU9VU0VfUFMyPW0KQ09ORklHX01PVVNFX1BTMl9BTFBTPXkKQ09ORklHX01P
VVNFX1BTMl9MT0dJUFMyUFA9eQpDT05GSUdfTU9VU0VfUFMyX1NZTkFQVElDUz15CkNPTkZJR19N
T1VTRV9QUzJfTElGRUJPT0s9eQpDT05GSUdfTU9VU0VfUFMyX1RSQUNLUE9JTlQ9eQpDT05GSUdf
TU9VU0VfUFMyX0VMQU5URUNIPXkKQ09ORklHX01PVVNFX1BTMl9TRU5URUxJQz15CiMgQ09ORklH
X01PVVNFX1BTMl9UT1VDSEtJVCBpcyBub3Qgc2V0CkNPTkZJR19NT1VTRV9TRVJJQUw9bQpDT05G
SUdfTU9VU0VfQVBQTEVUT1VDSD1tCkNPTkZJR19NT1VTRV9CQ001OTc0PW0KQ09ORklHX01PVVNF
X1ZTWFhYQUE9bQojIENPTkZJR19NT1VTRV9HUElPIGlzIG5vdCBzZXQKQ09ORklHX01PVVNFX1NZ
TkFQVElDU19JMkM9bQpDT05GSUdfSU5QVVRfSk9ZU1RJQ0s9eQpDT05GSUdfSk9ZU1RJQ0tfQU5B
TE9HPW0KQ09ORklHX0pPWVNUSUNLX0EzRD1tCkNPTkZJR19KT1lTVElDS19BREk9bQpDT05GSUdf
Sk9ZU1RJQ0tfQ09CUkE9bQpDT05GSUdfSk9ZU1RJQ0tfR0YySz1tCkNPTkZJR19KT1lTVElDS19H
UklQPW0KQ09ORklHX0pPWVNUSUNLX0dSSVBfTVA9bQpDT05GSUdfSk9ZU1RJQ0tfR1VJTExFTU9U
PW0KQ09ORklHX0pPWVNUSUNLX0lOVEVSQUNUPW0KQ09ORklHX0pPWVNUSUNLX1NJREVXSU5ERVI9
bQpDT05GSUdfSk9ZU1RJQ0tfVE1EQz1tCkNPTkZJR19KT1lTVElDS19JRk9SQ0U9bQpDT05GSUdf
Sk9ZU1RJQ0tfSUZPUkNFX1VTQj15CkNPTkZJR19KT1lTVElDS19JRk9SQ0VfMjMyPXkKQ09ORklH
X0pPWVNUSUNLX1dBUlJJT1I9bQpDT05GSUdfSk9ZU1RJQ0tfTUFHRUxMQU49bQpDT05GSUdfSk9Z
U1RJQ0tfU1BBQ0VPUkI9bQpDT05GSUdfSk9ZU1RJQ0tfU1BBQ0VCQUxMPW0KQ09ORklHX0pPWVNU
SUNLX1NUSU5HRVI9bQpDT05GSUdfSk9ZU1RJQ0tfVFdJREpPWT1tCkNPTkZJR19KT1lTVElDS19a
SEVOSFVBPW0KIyBDT05GSUdfSk9ZU1RJQ0tfQVM1MDExIGlzIG5vdCBzZXQKQ09ORklHX0pPWVNU
SUNLX0pPWURVTVA9bQpDT05GSUdfSk9ZU1RJQ0tfWFBBRD1tCkNPTkZJR19KT1lTVElDS19YUEFE
X0ZGPXkKQ09ORklHX0pPWVNUSUNLX1hQQURfTEVEUz15CkNPTkZJR19JTlBVVF9UQUJMRVQ9eQpD
T05GSUdfVEFCTEVUX1VTQl9BQ0VDQUQ9bQpDT05GSUdfVEFCTEVUX1VTQl9BSVBURUs9bQpDT05G
SUdfVEFCTEVUX1VTQl9HVENPPW0KIyBDT05GSUdfVEFCTEVUX1VTQl9IQU5XQU5HIGlzIG5vdCBz
ZXQKQ09ORklHX1RBQkxFVF9VU0JfS0JUQUI9bQpDT05GSUdfVEFCTEVUX1VTQl9XQUNPTT1tCkNP
TkZJR19JTlBVVF9UT1VDSFNDUkVFTj15CkNPTkZJR19UT1VDSFNDUkVFTl9BRDc4Nzk9bQpDT05G
SUdfVE9VQ0hTQ1JFRU5fQUQ3ODc5X0kyQz1tCiMgQ09ORklHX1RPVUNIU0NSRUVOX0FUTUVMX01Y
VCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0JVMjEwMTMgaXMgbm90IHNldAojIENP
TkZJR19UT1VDSFNDUkVFTl9DWThDVE1HMTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JF
RU5fRFlOQVBSTyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0hBTVBTSElSRSBpcyBu
b3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9FRVRJPW0KQ09ORklHX1RPVUNIU0NSRUVOX0ZVSklU
U1U9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fR1VOWkU9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fRUxPPW0K
Q09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4MDAxPW0KIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTUFY
MTE4MDEgaXMgbm90IHNldApDT05GSUdfVE9VQ0hTQ1JFRU5fTUNTNTAwMD1tCkNPTkZJR19UT1VD
SFNDUkVFTl9NVE9VQ0g9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fSU5FWElPPW0KQ09ORklHX1RPVUNI
U0NSRUVOX01LNzEyPW0KQ09ORklHX1RPVUNIU0NSRUVOX1BFTk1PVU5UPW0KQ09ORklHX1RPVUNI
U0NSRUVOX1RPVUNIUklHSFQ9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hXSU49bQpDT05GSUdf
VE9VQ0hTQ1JFRU5fVVNCX0NPTVBPU0lURT1tCkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfRUdBTEFY
PXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9QQU5KSVQ9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNC
XzNNPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9JVE09eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNC
X0VUVVJCTz15CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfR1VOWkU9eQpDT05GSUdfVE9VQ0hTQ1JF
RU5fVVNCX0RNQ19UU0MxMD15CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfSVJUT1VDSD15CkNPTkZJ
R19UT1VDSFNDUkVFTl9VU0JfSURFQUxURUs9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0dFTkVS
QUxfVE9VQ0g9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0dPVE9QPXkKQ09ORklHX1RPVUNIU0NS
RUVOX1VTQl9KQVNURUM9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0UyST15CkNPTkZJR19UT1VD
SFNDUkVFTl9VU0JfWllUUk9OSUM9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0VUVF9UQzQ1VVNC
PXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9ORVhJTz15CkNPTkZJR19UT1VDSFNDUkVFTl9UT1VD
SElUMjEzPW0KQ09ORklHX1RPVUNIU0NSRUVOX1RTQzIwMDc9bQojIENPTkZJR19UT1VDSFNDUkVF
Tl9TVDEyMzIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UUFM2NTA3WCBpcyBub3Qg
c2V0CkNPTkZJR19JTlBVVF9NSVNDPXkKIyBDT05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5vdCBzZXQK
Q09ORklHX0lOUFVUX1BDU1BLUj1tCkNPTkZJR19JTlBVVF9BUEFORUw9bQpDT05GSUdfSU5QVVRf
QVRMQVNfQlROUz1tCkNPTkZJR19JTlBVVF9BVElfUkVNT1RFPW0KQ09ORklHX0lOUFVUX0FUSV9S
RU1PVEUyPW0KQ09ORklHX0lOUFVUX0tFWVNQQU5fUkVNT1RFPW0KQ09ORklHX0lOUFVUX1BPV0VS
TUFURT1tCkNPTkZJR19JTlBVVF9ZRUFMSU5LPW0KQ09ORklHX0lOUFVUX0NNMTA5PW0KQ09ORklH
X0lOUFVUX1VJTlBVVD1tCiMgQ09ORklHX0lOUFVUX1BDRjg1NzQgaXMgbm90IHNldAojIENPTkZJ
R19JTlBVVF9HUElPX1JPVEFSWV9FTkNPREVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQURY
TDM0WCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0NNQTMwMDAgaXMgbm90IHNldApDT05GSUdf
SU5QVVRfWEVOX0tCRERFVl9GUk9OVEVORD15CgojCiMgSGFyZHdhcmUgSS9PIHBvcnRzCiMKQ09O
RklHX1NFUklPPXkKQ09ORklHX1NFUklPX0k4MDQyPXkKQ09ORklHX1NFUklPX1NFUlBPUlQ9bQpD
T05GSUdfU0VSSU9fQ1Q4MkM3MTA9bQpDT05GSUdfU0VSSU9fUENJUFMyPW0KQ09ORklHX1NFUklP
X0xJQlBTMj15CkNPTkZJR19TRVJJT19SQVc9bQojIENPTkZJR19TRVJJT19BTFRFUkFfUFMyIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VSSU9fUFMyTVVMVCBpcyBub3Qgc2V0CkNPTkZJR19HQU1FUE9S
VD1tCkNPTkZJR19HQU1FUE9SVF9OUzU1OD1tCkNPTkZJR19HQU1FUE9SVF9MND1tCkNPTkZJR19H
QU1FUE9SVF9FTVUxMEsxPW0KQ09ORklHX0dBTUVQT1JUX0ZNODAxPW0KCiMKIyBDaGFyYWN0ZXIg
ZGV2aWNlcwojCkNPTkZJR19WVD15CkNPTkZJR19DT05TT0xFX1RSQU5TTEFUSU9OUz15CkNPTkZJ
R19WVF9DT05TT0xFPXkKQ09ORklHX0hXX0NPTlNPTEU9eQpDT05GSUdfVlRfSFdfQ09OU09MRV9C
SU5ESU5HPXkKQ09ORklHX1VOSVg5OF9QVFlTPXkKQ09ORklHX0RFVlBUU19NVUxUSVBMRV9JTlNU
QU5DRVM9eQojIENPTkZJR19MRUdBQ1lfUFRZUyBpcyBub3Qgc2V0CkNPTkZJR19TRVJJQUxfTk9O
U1RBTkRBUkQ9eQojIENPTkZJR19ST0NLRVRQT1JUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1lDTEFE
RVMgaXMgbm90IHNldAojIENPTkZJR19NT1hBX0lOVEVMTElPIGlzIG5vdCBzZXQKIyBDT05GSUdf
TU9YQV9TTUFSVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lOQ0xJTksgaXMgbm90IHNldAojIENP
TkZJR19TWU5DTElOS01QIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lOQ0xJTktfR1QgaXMgbm90IHNl
dAojIENPTkZJR19OT1pPTUkgaXMgbm90IHNldAojIENPTkZJR19JU0kgaXMgbm90IHNldAojIENP
TkZJR19OX0hETEMgaXMgbm90IHNldAojIENPTkZJR19OX0dTTSBpcyBub3Qgc2V0CiMgQ09ORklH
X1RSQUNFX1NJTksgaXMgbm90IHNldAojIENPTkZJR19ERVZLTUVNIGlzIG5vdCBzZXQKQ09ORklH
X1NUQUxEUlY9eQoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NFUklBTF84MjUwPXkKQ09O
RklHX1NFUklBTF84MjUwX0NPTlNPTEU9eQpDT05GSUdfRklYX0VBUkxZQ09OX01FTT15CkNPTkZJ
R19TRVJJQUxfODI1MF9QQ0k9eQpDT05GSUdfU0VSSUFMXzgyNTBfUE5QPXkKQ09ORklHX1NFUklB
TF84MjUwX05SX1VBUlRTPTMyCkNPTkZJR19TRVJJQUxfODI1MF9SVU5USU1FX1VBUlRTPTQKQ09O
RklHX1NFUklBTF84MjUwX0VYVEVOREVEPXkKQ09ORklHX1NFUklBTF84MjUwX01BTllfUE9SVFM9
eQpDT05GSUdfU0VSSUFMXzgyNTBfU0hBUkVfSVJRPXkKIyBDT05GSUdfU0VSSUFMXzgyNTBfREVU
RUNUX0lSUSBpcyBub3Qgc2V0CkNPTkZJR19TRVJJQUxfODI1MF9SU0E9eQoKIwojIE5vbi04MjUw
IHNlcmlhbCBwb3J0IHN1cHBvcnQKIwojIENPTkZJR19TRVJJQUxfTUZEX0hTVSBpcyBub3Qgc2V0
CkNPTkZJR19TRVJJQUxfQ09SRT15CkNPTkZJR19TRVJJQUxfQ09SRV9DT05TT0xFPXkKQ09ORklH
X0NPTlNPTEVfUE9MTD15CiMgQ09ORklHX1NFUklBTF9KU00gaXMgbm90IHNldAojIENPTkZJR19T
RVJJQUxfVElNQkVSREFMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfSlRBR1VB
UlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfQUxURVJBX1VBUlQgaXMgbm90IHNldAojIENP
TkZJR19TRVJJQUxfUENIX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfWElMSU5YX1BT
X1VBUlQgaXMgbm90IHNldAojIENPTkZJR19UVFlfUFJJTlRLIGlzIG5vdCBzZXQKQ09ORklHX0hW
Q19EUklWRVI9eQpDT05GSUdfSFZDX0lSUT15CkNPTkZJR19IVkNfWEVOPXkKIyBDT05GSUdfSVBN
SV9IQU5ETEVSIGlzIG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTT1tCiMgQ09ORklHX0hXX1JBTkRP
TV9USU1FUklPTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfSFdfUkFORE9NX0lOVEVMIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSFdfUkFORE9NX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hXX1JBTkRPTV9W
SUEgaXMgbm90IHNldAojIENPTkZJR19OVlJBTSBpcyBub3Qgc2V0CiMgQ09ORklHX1IzOTY0IGlz
IG5vdCBzZXQKIyBDT05GSUdfQVBQTElDT00gaXMgbm90IHNldAojIENPTkZJR19NV0FWRSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1JBV19EUklWRVIgaXMgbm90IHNldApDT05GSUdfSFBFVD15CkNPTkZJ
R19IUEVUX01NQVA9eQojIENPTkZJR19IQU5HQ0hFQ0tfVElNRVIgaXMgbm90IHNldAojIENPTkZJ
R19UQ0dfVFBNIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVMQ0xPQ0sgaXMgbm90IHNldApDT05GSUdf
REVWUE9SVD15CiMgQ09ORklHX1JBTU9PUFMgaXMgbm90IHNldApDT05GSUdfSTJDPW0KQ09ORklH
X0kyQ19CT0FSRElORk89eQpDT05GSUdfSTJDX0NPTVBBVD15CkNPTkZJR19JMkNfQ0hBUkRFVj1t
CiMgQ09ORklHX0kyQ19NVVggaXMgbm90IHNldApDT05GSUdfSTJDX0hFTFBFUl9BVVRPPXkKQ09O
RklHX0kyQ19TTUJVUz1tCkNPTkZJR19JMkNfQUxHT0JJVD1tCkNPTkZJR19JMkNfQUxHT1BDQT1t
CgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBzdXBwb3J0CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNvbnRy
b2xsZXIgZHJpdmVycwojCkNPTkZJR19JMkNfQUxJMTUzNT1tCkNPTkZJR19JMkNfQUxJMTU2Mz1t
CkNPTkZJR19JMkNfQUxJMTVYMz1tCkNPTkZJR19JMkNfQU1ENzU2PW0KQ09ORklHX0kyQ19BTUQ3
NTZfUzQ4ODI9bQpDT05GSUdfSTJDX0FNRDgxMTE9bQpDT05GSUdfSTJDX0k4MDE9bQpDT05GSUdf
STJDX0lTQ0g9bQpDT05GSUdfSTJDX1BJSVg0PW0KQ09ORklHX0kyQ19ORk9SQ0UyPW0KQ09ORklH
X0kyQ19ORk9SQ0UyX1M0OTg1PW0KQ09ORklHX0kyQ19TSVM1NTk1PW0KQ09ORklHX0kyQ19TSVM2
MzA9bQpDT05GSUdfSTJDX1NJUzk2WD1tCkNPTkZJR19JMkNfVklBPW0KQ09ORklHX0kyQ19WSUFQ
Uk89bQoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJR19JMkNfU0NNST1tCgojCiMgSTJDIHN5c3Rl
bSBidXMgZHJpdmVycyAobW9zdGx5IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05G
SUdfSTJDX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19JMkNfSU5URUxfTUlEIGlzIG5vdCBzZXQK
Q09ORklHX0kyQ19PQ09SRVM9bQpDT05GSUdfSTJDX1BDQV9QTEFURk9STT1tCiMgQ09ORklHX0ky
Q19QWEFfUENJIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19TSU1URUM9bQojIENPTkZJR19JMkNfWElM
SU5YIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0VHMjBUIGlzIG5vdCBzZXQKCiMKIyBFeHRlcm5h
bCBJMkMvU01CdXMgYWRhcHRlciBkcml2ZXJzCiMKIyBDT05GSUdfSTJDX0RJT0xBTl9VMkMgaXMg
bm90IHNldApDT05GSUdfSTJDX1BBUlBPUlRfTElHSFQ9bQpDT05GSUdfSTJDX1RBT1NfRVZNPW0K
Q09ORklHX0kyQ19USU5ZX1VTQj1tCgojCiMgT3RoZXIgSTJDL1NNQnVzIGJ1cyBkcml2ZXJzCiMK
Q09ORklHX0kyQ19TVFVCPW0KIyBDT05GSUdfSTJDX0RFQlVHX0NPUkUgaXMgbm90IHNldAojIENP
TkZJR19JMkNfREVCVUdfQUxHTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19CVVMgaXMg
bm90IHNldAojIENPTkZJR19TUEkgaXMgbm90IHNldAoKIwojIFBQUyBzdXBwb3J0CiMKQ09ORklH
X1BQUz1tCiMgQ09ORklHX1BQU19ERUJVRyBpcyBub3Qgc2V0CgojCiMgUFBTIGNsaWVudHMgc3Vw
cG9ydAojCiMgQ09ORklHX1BQU19DTElFTlRfS1RJTUVSIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBT
X0NMSUVOVF9MRElTQyBpcyBub3Qgc2V0CgojCiMgUFBTIGdlbmVyYXRvcnMgc3VwcG9ydAojCgoj
CiMgUFRQIGNsb2NrIHN1cHBvcnQKIwojIENPTkZJR19QVFBfMTU4OF9DTE9DSyBpcyBub3Qgc2V0
CkNPTkZJR19BUkNIX1dBTlRfT1BUSU9OQUxfR1BJT0xJQj15CkNPTkZJR19HUElPTElCPXkKIyBD
T05GSUdfREVCVUdfR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fU1lTRlMgaXMgbm90IHNl
dAoKIwojIE1lbW9yeSBtYXBwZWQgR1BJTyBkcml2ZXJzOgojCiMgQ09ORklHX0dQSU9fQkFTSUNf
TU1JTyBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fSVQ4NzYxRSBpcyBub3Qgc2V0CiMgQ09ORklH
X0dQSU9fU0NIIGlzIG5vdCBzZXQKCiMKIyBJMkMgR1BJTyBleHBhbmRlcnM6CiMKIyBDT05GSUdf
R1BJT19NQVg3MzAwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19NQVg3MzJYIGlzIG5vdCBzZXQK
IyBDT05GSUdfR1BJT19QQ0E5NTNYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19QQ0Y4NTdYIGlz
IG5vdCBzZXQKIyBDT05GSUdfR1BJT19BRFA1NTg4IGlzIG5vdCBzZXQKCiMKIyBQQ0kgR1BJTyBl
eHBhbmRlcnM6CiMKIyBDT05GSUdfR1BJT19CVDhYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9f
TEFOR1dFTEwgaXMgbm90IHNldAojIENPTkZJR19HUElPX1BDSCBpcyBub3Qgc2V0CiMgQ09ORklH
X0dQSU9fTUxfSU9IIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19SREMzMjFYIGlzIG5vdCBzZXQK
CiMKIyBTUEkgR1BJTyBleHBhbmRlcnM6CiMKCiMKIyBBQzk3IEdQSU8gZXhwYW5kZXJzOgojCgoj
CiMgTU9EVUxidXMgR1BJTyBleHBhbmRlcnM6CiMKIyBDT05GSUdfVzEgaXMgbm90IHNldApDT05G
SUdfUE9XRVJfU1VQUExZPXkKIyBDT05GSUdfUE9XRVJfU1VQUExZX0RFQlVHIGlzIG5vdCBzZXQK
Q09ORklHX1BEQV9QT1dFUj1tCiMgQ09ORklHX1RFU1RfUE9XRVIgaXMgbm90IHNldAojIENPTkZJ
R19CQVRURVJZX0RTMjc4MCBpcyBub3Qgc2V0CkNPTkZJR19CQVRURVJZX0RTMjc4Mj1tCiMgQ09O
RklHX0JBVFRFUllfQlEyMFo3NSBpcyBub3Qgc2V0CkNPTkZJR19CQVRURVJZX0JRMjd4MDA9bQpD
T05GSUdfQkFUVEVSWV9CUTI3WDAwX0kyQz15CkNPTkZJR19CQVRURVJZX0JRMjdYMDBfUExBVEZP
Uk09eQpDT05GSUdfQkFUVEVSWV9NQVgxNzA0MD1tCiMgQ09ORklHX0JBVFRFUllfTUFYMTcwNDIg
aXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX01BWDg5MDMgaXMgbm90IHNldAojIENPTkZJR19D
SEFSR0VSX0dQSU8gaXMgbm90IHNldApDT05GSUdfSFdNT049eQpDT05GSUdfSFdNT05fVklEPW0K
IyBDT05GSUdfSFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgTmF0aXZlIGRyaXZlcnMK
IwpDT05GSUdfU0VOU09SU19BQklUVUdVUlU9bQpDT05GSUdfU0VOU09SU19BQklUVUdVUlUzPW0K
Q09ORklHX1NFTlNPUlNfQUQ3NDE0PW0KQ09ORklHX1NFTlNPUlNfQUQ3NDE4PW0KQ09ORklHX1NF
TlNPUlNfQURNMTAyMT1tCkNPTkZJR19TRU5TT1JTX0FETTEwMjU9bQpDT05GSUdfU0VOU09SU19B
RE0xMDI2PW0KQ09ORklHX1NFTlNPUlNfQURNMTAyOT1tCkNPTkZJR19TRU5TT1JTX0FETTEwMzE9
bQpDT05GSUdfU0VOU09SU19BRE05MjQwPW0KIyBDT05GSUdfU0VOU09SU19BRFQ3NDExIGlzIG5v
dCBzZXQKQ09ORklHX1NFTlNPUlNfQURUNzQ2Mj1tCkNPTkZJR19TRU5TT1JTX0FEVDc0NzA9bQpD
T05GSUdfU0VOU09SU19BRFQ3NDc1PW0KIyBDT05GSUdfU0VOU09SU19BU0M3NjIxIGlzIG5vdCBz
ZXQKQ09ORklHX1NFTlNPUlNfSzhURU1QPW0KQ09ORklHX1NFTlNPUlNfSzEwVEVNUD1tCiMgQ09O
RklHX1NFTlNPUlNfRkFNMTVIX1BPV0VSIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfQVNCMTAw
PW0KQ09ORklHX1NFTlNPUlNfQVRYUDE9bQojIENPTkZJR19TRU5TT1JTX0RTNjIwIGlzIG5vdCBz
ZXQKQ09ORklHX1NFTlNPUlNfRFMxNjIxPW0KQ09ORklHX1NFTlNPUlNfSTVLX0FNQj1tCkNPTkZJ
R19TRU5TT1JTX0Y3MTgwNUY9bQpDT05GSUdfU0VOU09SU19GNzE4ODJGRz1tCkNPTkZJR19TRU5T
T1JTX0Y3NTM3NVM9bQpDT05GSUdfU0VOU09SU19GU0NITUQ9bQpDT05GSUdfU0VOU09SU19HNzYw
QT1tCkNPTkZJR19TRU5TT1JTX0dMNTE4U009bQpDT05GSUdfU0VOU09SU19HTDUyMFNNPW0KIyBD
T05GSUdfU0VOU09SU19HUElPX0ZBTiBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0NPUkVURU1Q
PW0KQ09ORklHX1NFTlNPUlNfSVQ4Nz1tCiMgQ09ORklHX1NFTlNPUlNfSkM0MiBpcyBub3Qgc2V0
CiMgQ09ORklHX1NFTlNPUlNfTElORUFHRSBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0xNNjM9
bQojIENPTkZJR19TRU5TT1JTX0xNNzMgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19MTTc1PW0K
Q09ORklHX1NFTlNPUlNfTE03Nz1tCkNPTkZJR19TRU5TT1JTX0xNNzg9bQpDT05GSUdfU0VOU09S
U19MTTgwPW0KQ09ORklHX1NFTlNPUlNfTE04Mz1tCkNPTkZJR19TRU5TT1JTX0xNODU9bQpDT05G
SUdfU0VOU09SU19MTTg3PW0KQ09ORklHX1NFTlNPUlNfTE05MD1tCkNPTkZJR19TRU5TT1JTX0xN
OTI9bQpDT05GSUdfU0VOU09SU19MTTkzPW0KIyBDT05GSUdfU0VOU09SU19MVEM0MTUxIGlzIG5v
dCBzZXQKQ09ORklHX1NFTlNPUlNfTFRDNDIxNT1tCkNPTkZJR19TRU5TT1JTX0xUQzQyNDU9bQoj
IENPTkZJR19TRU5TT1JTX0xUQzQyNjEgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19MTTk1MjQx
PW0KIyBDT05GSUdfU0VOU09SU19NQVgxNjA2NSBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX01B
WDE2MTk9bQojIENPTkZJR19TRU5TT1JTX01BWDY2MzkgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX01BWDY2NDIgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19NQVg2NjUwPW0KQ09ORklHX1NF
TlNPUlNfUEM4NzM2MD1tCkNPTkZJR19TRU5TT1JTX1BDODc0Mjc9bQpDT05GSUdfU0VOU09SU19Q
Q0Y4NTkxPW0KIyBDT05GSUdfUE1CVVMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NIVDE1
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TSFQyMSBpcyBub3Qgc2V0CkNPTkZJR19TRU5T
T1JTX1NJUzU1OTU9bQojIENPTkZJR19TRU5TT1JTX1NNTTY2NSBpcyBub3Qgc2V0CkNPTkZJR19T
RU5TT1JTX0RNRTE3Mzc9bQojIENPTkZJR19TRU5TT1JTX0VNQzE0MDMgaXMgbm90IHNldAojIENP
TkZJR19TRU5TT1JTX0VNQzIxMDMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0VNQzZXMjAx
IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfU01TQzQ3TTE9bQpDT05GSUdfU0VOU09SU19TTVND
NDdNMTkyPW0KQ09ORklHX1NFTlNPUlNfU01TQzQ3QjM5Nz1tCiMgQ09ORklHX1NFTlNPUlNfU0NI
NTYyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQURTMTAxNSBpcyBub3Qgc2V0CkNPTkZJ
R19TRU5TT1JTX0FEUzc4Mjg9bQojIENPTkZJR19TRU5TT1JTX0FNQzY4MjEgaXMgbm90IHNldApD
T05GSUdfU0VOU09SU19USE1DNTA9bQojIENPTkZJR19TRU5TT1JTX1RNUDEwMiBpcyBub3Qgc2V0
CkNPTkZJR19TRU5TT1JTX1RNUDQwMT1tCkNPTkZJR19TRU5TT1JTX1RNUDQyMT1tCkNPTkZJR19T
RU5TT1JTX1ZJQV9DUFVURU1QPW0KQ09ORklHX1NFTlNPUlNfVklBNjg2QT1tCkNPTkZJR19TRU5T
T1JTX1ZUMTIxMT1tCkNPTkZJR19TRU5TT1JTX1ZUODIzMT1tCkNPTkZJR19TRU5TT1JTX1c4Mzc4
MUQ9bQpDT05GSUdfU0VOU09SU19XODM3OTFEPW0KQ09ORklHX1NFTlNPUlNfVzgzNzkyRD1tCkNP
TkZJR19TRU5TT1JTX1c4Mzc5Mz1tCiMgQ09ORklHX1NFTlNPUlNfVzgzNzk1IGlzIG5vdCBzZXQK
Q09ORklHX1NFTlNPUlNfVzgzTDc4NVRTPW0KQ09ORklHX1NFTlNPUlNfVzgzTDc4Nk5HPW0KQ09O
RklHX1NFTlNPUlNfVzgzNjI3SEY9bQpDT05GSUdfU0VOU09SU19XODM2MjdFSEY9bQpDT05GSUdf
U0VOU09SU19BUFBMRVNNQz1tCgojCiMgQUNQSSBkcml2ZXJzCiMKIyBDT05GSUdfU0VOU09SU19B
Q1BJX1BPV0VSIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfQVRLMDExMD1tCkNPTkZJR19USEVS
TUFMPW0KQ09ORklHX1RIRVJNQUxfSFdNT049eQojIENPTkZJR19XQVRDSERPRyBpcyBub3Qgc2V0
CkNPTkZJR19TU0JfUE9TU0lCTEU9eQoKIwojIFNvbmljcyBTaWxpY29uIEJhY2twbGFuZQojCkNP
TkZJR19TU0I9bQpDT05GSUdfU1NCX1NQUk9NPXkKQ09ORklHX1NTQl9QQ0lIT1NUX1BPU1NJQkxF
PXkKQ09ORklHX1NTQl9QQ0lIT1NUPXkKIyBDT05GSUdfU1NCX0I0M19QQ0lfQlJJREdFIGlzIG5v
dCBzZXQKIyBDT05GSUdfU1NCX1NJTEVOVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NTQl9ERUJVRyBp
cyBub3Qgc2V0CkNPTkZJR19TU0JfRFJJVkVSX1BDSUNPUkVfUE9TU0lCTEU9eQpDT05GSUdfU1NC
X0RSSVZFUl9QQ0lDT1JFPXkKQ09ORklHX0JDTUFfUE9TU0lCTEU9eQoKIwojIEJyb2FkY29tIHNw
ZWNpZmljIEFNQkEKIwojIENPTkZJR19CQ01BIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1NVUFBP
UlQgaXMgbm90IHNldApDT05GSUdfTUZEX0NPUkU9bQpDT05GSUdfTFBDX1NDSD1tCiMgQ09ORklH
X1JFR1VMQVRPUiBpcyBub3Qgc2V0CiMgQ09ORklHX01FRElBX1NVUFBPUlQgaXMgbm90IHNldAoK
IwojIEdyYXBoaWNzIHN1cHBvcnQKIwpDT05GSUdfQUdQPXkKQ09ORklHX0FHUF9BTUQ2ND15CkNP
TkZJR19BR1BfSU5URUw9eQpDT05GSUdfQUdQX1NJUz15CkNPTkZJR19BR1BfVklBPXkKQ09ORklH
X1ZHQV9BUkI9eQpDT05GSUdfVkdBX0FSQl9NQVhfR1BVUz0xNgojIENPTkZJR19WR0FfU1dJVENI
RVJPTyBpcyBub3Qgc2V0CkNPTkZJR19EUk09bQpDT05GSUdfRFJNX0tNU19IRUxQRVI9bQpDT05G
SUdfRFJNX1RUTT1tCkNPTkZJR19EUk1fVERGWD1tCkNPTkZJR19EUk1fUjEyOD1tCkNPTkZJR19E
Uk1fUkFERU9OPW0KIyBDT05GSUdfRFJNX1JBREVPTl9LTVMgaXMgbm90IHNldApDT05GSUdfRFJN
X0k4MTA9bQpDT05GSUdfRFJNX0k5MTU9bQojIENPTkZJR19EUk1fSTkxNV9LTVMgaXMgbm90IHNl
dApDT05GSUdfRFJNX01HQT1tCkNPTkZJR19EUk1fU0lTPW0KQ09ORklHX0RSTV9WSUE9bQpDT05G
SUdfRFJNX1NBVkFHRT1tCiMgQ09ORklHX1NUVUJfUE9VTFNCTyBpcyBub3Qgc2V0CkNPTkZJR19W
R0FTVEFURT1tCkNPTkZJR19WSURFT19PVVRQVVRfQ09OVFJPTD1tCkNPTkZJR19GQj15CkNPTkZJ
R19GSVJNV0FSRV9FRElEPXkKQ09ORklHX0ZCX0REQz1tCkNPTkZJR19GQl9CT09UX1ZFU0FfU1VQ
UE9SVD15CkNPTkZJR19GQl9DRkJfRklMTFJFQ1Q9eQpDT05GSUdfRkJfQ0ZCX0NPUFlBUkVBPXkK
Q09ORklHX0ZCX0NGQl9JTUFHRUJMSVQ9eQojIENPTkZJR19GQl9DRkJfUkVWX1BJWEVMU19JTl9C
WVRFIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NZU19GSUxMUkVDVD15CkNPTkZJR19GQl9TWVNfQ09Q
WUFSRUE9eQpDT05GSUdfRkJfU1lTX0lNQUdFQkxJVD15CiMgQ09ORklHX0ZCX0ZPUkVJR05fRU5E
SUFOIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NZU19GT1BTPXkKIyBDT05GSUdfRkJfV01UX0dFX1JP
UFMgaXMgbm90IHNldApDT05GSUdfRkJfREVGRVJSRURfSU89eQpDT05GSUdfRkJfSEVDVUJBPW0K
Q09ORklHX0ZCX1NWR0FMSUI9bQojIENPTkZJR19GQl9NQUNNT0RFUyBpcyBub3Qgc2V0CkNPTkZJ
R19GQl9CQUNLTElHSFQ9eQpDT05GSUdfRkJfTU9ERV9IRUxQRVJTPXkKQ09ORklHX0ZCX1RJTEVC
TElUVElORz15CgojCiMgRnJhbWUgYnVmZmVyIGhhcmR3YXJlIGRyaXZlcnMKIwpDT05GSUdfRkJf
Q0lSUlVTPW0KQ09ORklHX0ZCX1BNMj1tCkNPTkZJR19GQl9QTTJfRklGT19ESVNDT05ORUNUPXkK
Q09ORklHX0ZCX0NZQkVSMjAwMD1tCkNPTkZJR19GQl9DWUJFUjIwMDBfRERDPXkKQ09ORklHX0ZC
X0FSQz1tCiMgQ09ORklHX0ZCX0FTSUxJQU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfSU1TVFQg
aXMgbm90IHNldApDT05GSUdfRkJfVkdBMTY9bQpDT05GSUdfRkJfVkVTQT15CkNPTkZJR19GQl9F
Rkk9eQpDT05GSUdfRkJfTjQxMT1tCkNPTkZJR19GQl9IR0E9bQpDT05GSUdfRkJfUzFEMTNYWFg9
bQpDT05GSUdfRkJfTlZJRElBPW0KIyBDT05GSUdfRkJfTlZJRElBX0kyQyBpcyBub3Qgc2V0CiMg
Q09ORklHX0ZCX05WSURJQV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GQl9OVklESUFfQkFDS0xJ
R0hUPXkKIyBDT05GSUdfRkJfUklWQSBpcyBub3Qgc2V0CkNPTkZJR19GQl9MRTgwNTc4PW0KQ09O
RklHX0ZCX0NBUklMTE9fUkFOQ0g9bQojIENPTkZJR19GQl9JTlRFTCBpcyBub3Qgc2V0CkNPTkZJ
R19GQl9NQVRST1g9bQpDT05GSUdfRkJfTUFUUk9YX01JTExFTklVTT15CkNPTkZJR19GQl9NQVRS
T1hfTVlTVElRVUU9eQpDT05GSUdfRkJfTUFUUk9YX0c9eQpDT05GSUdfRkJfTUFUUk9YX0kyQz1t
CkNPTkZJR19GQl9NQVRST1hfTUFWRU49bQpDT05GSUdfRkJfUkFERU9OPW0KQ09ORklHX0ZCX1JB
REVPTl9JMkM9eQpDT05GSUdfRkJfUkFERU9OX0JBQ0tMSUdIVD15CiMgQ09ORklHX0ZCX1JBREVP
Tl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GQl9BVFkxMjg9bQpDT05GSUdfRkJfQVRZMTI4X0JB
Q0tMSUdIVD15CkNPTkZJR19GQl9BVFk9bQpDT05GSUdfRkJfQVRZX0NUPXkKIyBDT05GSUdfRkJf
QVRZX0dFTkVSSUNfTENEIGlzIG5vdCBzZXQKQ09ORklHX0ZCX0FUWV9HWD15CkNPTkZJR19GQl9B
VFlfQkFDS0xJR0hUPXkKQ09ORklHX0ZCX1MzPW0KQ09ORklHX0ZCX1MzX0REQz15CkNPTkZJR19G
Ql9TQVZBR0U9bQojIENPTkZJR19GQl9TQVZBR0VfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
U0FWQUdFX0FDQ0VMIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NJUz1tCkNPTkZJR19GQl9TSVNfMzAw
PXkKQ09ORklHX0ZCX1NJU18zMTU9eQpDT05GSUdfRkJfVklBPW0KIyBDT05GSUdfRkJfVklBX0RJ
UkVDVF9QUk9DRlMgaXMgbm90IHNldAojIENPTkZJR19GQl9WSUFfWF9DT01QQVRJQklMSVRZIGlz
IG5vdCBzZXQKQ09ORklHX0ZCX05FT01BR0lDPW0KQ09ORklHX0ZCX0tZUk89bQpDT05GSUdfRkJf
M0RGWD1tCiMgQ09ORklHX0ZCXzNERlhfQUNDRUwgaXMgbm90IHNldApDT05GSUdfRkJfM0RGWF9J
MkM9eQpDT05GSUdfRkJfVk9PRE9PMT1tCkNPTkZJR19GQl9WVDg2MjM9bQpDT05GSUdfRkJfVFJJ
REVOVD1tCkNPTkZJR19GQl9BUks9bQpDT05GSUdfRkJfUE0zPW0KIyBDT05GSUdfRkJfQ0FSTUlO
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0dFT0RFIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVE1J
TyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1VETCBpcyBub3Qgc2V0CkNPTkZJR19GQl9WSVJUVUFM
PW0KQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD15CkNPTkZJR19GQl9NRVRST05PTUU9bQpDT05G
SUdfRkJfTUI4NjJYWD1tCkNPTkZJR19GQl9NQjg2MlhYX1BDSV9HREM9eQpDT05GSUdfRkJfTUI4
NjJYWF9JMkM9eQojIENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKQ09ORklHX0JBQ0tM
SUdIVF9MQ0RfU1VQUE9SVD15CiMgQ09ORklHX0xDRF9DTEFTU19ERVZJQ0UgaXMgbm90IHNldApD
T05GSUdfQkFDS0xJR0hUX0NMQVNTX0RFVklDRT15CiMgQ09ORklHX0JBQ0tMSUdIVF9HRU5FUklD
IGlzIG5vdCBzZXQKQ09ORklHX0JBQ0tMSUdIVF9QUk9HRUFSPW0KIyBDT05GSUdfQkFDS0xJR0hU
X0FQUExFIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFSQSBpcyBub3Qgc2V0CiMg
Q09ORklHX0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0FE
UDg4NzAgaXMgbm90IHNldAoKIwojIERpc3BsYXkgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfRElT
UExBWV9TVVBQT1JUPW0KCiMKIyBEaXNwbGF5IGhhcmR3YXJlIGRyaXZlcnMKIwoKIwojIENvbnNv
bGUgZGlzcGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CiMgQ09ORklH
X1ZHQUNPTl9TT0ZUX1NDUk9MTEJBQ0sgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15
CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNPTEVf
REVURUNUX1BSSU1BUlk9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRV9ST1RBVElPTj15CiMg
Q09ORklHX0ZPTlRTIGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfOHg4PXkKQ09ORklHX0ZPTlRfOHgx
Nj15CiMgQ09ORklHX0xPR08gaXMgbm90IHNldAojIENPTkZJR19TT1VORCBpcyBub3Qgc2V0CkNP
TkZJR19ISURfU1VQUE9SVD15CkNPTkZJR19ISUQ9bQpDT05GSUdfSElEUkFXPXkKCiMKIyBVU0Ig
SW5wdXQgRGV2aWNlcwojCkNPTkZJR19VU0JfSElEPW0KQ09ORklHX0hJRF9QSUQ9eQpDT05GSUdf
VVNCX0hJRERFVj15CgojCiMgVVNCIEhJRCBCb290IFByb3RvY29sIGRyaXZlcnMKIwojIENPTkZJ
R19VU0JfS0JEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01PVVNFIGlzIG5vdCBzZXQKCiMKIyBT
cGVjaWFsIEhJRCBkcml2ZXJzCiMKIyBDT05GSUdfSElEX0E0VEVDSCBpcyBub3Qgc2V0CiMgQ09O
RklHX0hJRF9BQ1JVWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9BUFBMRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0hJRF9CRUxLSU4gaXMgbm90IHNldAojIENPTkZJR19ISURfQ0hFUlJZIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSElEX0NISUNPTlkgaXMgbm90IHNldAojIENPTkZJR19ISURfQ1lQUkVTUyBp
cyBub3Qgc2V0CkNPTkZJR19ISURfRFJBR09OUklTRT1tCkNPTkZJR19EUkFHT05SSVNFX0ZGPXkK
IyBDT05GSUdfSElEX0VNU19GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9FWktFWSBpcyBub3Qg
c2V0CiMgQ09ORklHX0hJRF9LRVlUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9LWUUgaXMg
bm90IHNldAojIENPTkZJR19ISURfVUNMT0dJQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9XQUxU
T1AgaXMgbm90IHNldApDT05GSUdfSElEX0dZUkFUSU9OPW0KQ09ORklHX0hJRF9UV0lOSEFOPW0K
IyBDT05GSUdfSElEX0tFTlNJTkdUT04gaXMgbm90IHNldAojIENPTkZJR19ISURfTENQT1dFUiBp
cyBub3Qgc2V0CiMgQ09ORklHX0hJRF9MT0dJVEVDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9N
SUNST1NPRlQgaXMgbm90IHNldAojIENPTkZJR19ISURfTU9OVEVSRVkgaXMgbm90IHNldAojIENP
TkZJR19ISURfTVVMVElUT1VDSCBpcyBub3Qgc2V0CkNPTkZJR19ISURfTlRSSUc9bQojIENPTkZJ
R19ISURfT1JURUsgaXMgbm90IHNldApDT05GSUdfSElEX1BBTlRIRVJMT1JEPW0KQ09ORklHX1BB
TlRIRVJMT1JEX0ZGPXkKQ09ORklHX0hJRF9QRVRBTFlOWD1tCiMgQ09ORklHX0hJRF9QSUNPTENE
IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1FVQU5UQSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9S
T0NDQVQgaXMgbm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUX0FSVk8gaXMgbm90IHNldAojIENP
TkZJR19ISURfUk9DQ0FUX0tPTkUgaXMgbm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUX0tPTkVQ
TFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1JPQ0NBVF9LT1ZBUExVUyBpcyBub3Qgc2V0CiMg
Q09ORklHX0hJRF9ST0NDQVRfUFlSQSBpcyBub3Qgc2V0CkNPTkZJR19ISURfU0FNU1VORz1tCkNP
TkZJR19ISURfU09OWT1tCkNPTkZJR19ISURfU1VOUExVUz1tCkNPTkZJR19ISURfR1JFRU5BU0lB
PW0KQ09ORklHX0dSRUVOQVNJQV9GRj15CkNPTkZJR19ISURfU01BUlRKT1lQTFVTPW0KQ09ORklH
X1NNQVJUSk9ZUExVU19GRj15CkNPTkZJR19ISURfVE9QU0VFRD1tCkNPTkZJR19ISURfVEhSVVNU
TUFTVEVSPW0KQ09ORklHX1RIUlVTVE1BU1RFUl9GRj15CkNPTkZJR19ISURfWkVST1BMVVM9bQpD
T05GSUdfWkVST1BMVVNfRkY9eQojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldApDT05G
SUdfVVNCX1NVUFBPUlQ9eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0JfQVJD
SF9IQVNfT0hDST15CkNPTkZJR19VU0JfQVJDSF9IQVNfRUhDST15CkNPTkZJR19VU0I9bQojIENP
TkZJR19VU0JfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19VU0JfQU5OT1VOQ0VfTkVXX0RFVklD
RVMgaXMgbm90IHNldAoKIwojIE1pc2NlbGxhbmVvdXMgVVNCIG9wdGlvbnMKIwojIENPTkZJR19V
U0JfREVWSUNFRlMgaXMgbm90IHNldAojIENPTkZJR19VU0JfREVWSUNFX0NMQVNTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX0RZTkFNSUNfTUlOT1JTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NV
U1BFTkQgaXMgbm90IHNldAojIENPTkZJR19VU0JfT1RHX1dISVRFTElTVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9PVEdfQkxBQ0tMSVNUX0hVQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NT04g
aXMgbm90IHNldAojIENPTkZJR19VU0JfV1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9XVVNC
X0NCQUYgaXMgbm90IHNldAoKIwojIFVTQiBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09O
RklHX1VTQl9DNjdYMDBfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1hIQ0lfSENEIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX0VIQ0lfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09YVTIx
MEhQX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMTZYX0hDRCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9JU1AxNzYwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMzYyX0hD
RCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PSENJX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9VSENJX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TTDgxMV9IQ0QgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfUjhBNjY1OTdfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1dIQ0lfSENE
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0hXQV9IQ0QgaXMgbm90IHNldAoKIwojIEVuYWJsZSBI
b3N0IG9yIEdhZGdldCBzdXBwb3J0IHRvIHNlZSBJbnZlbnRyYSBvcHRpb25zCiMKCiMKIyBVU0Ig
RGV2aWNlIENsYXNzIGRyaXZlcnMKIwojIENPTkZJR19VU0JfQUNNIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1BSSU5URVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfV0RNIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1RNQyBpcyBub3Qgc2V0CgojCiMgTk9URTogVVNCX1NUT1JBR0UgZGVwZW5kcyBv
biBTQ1NJIGJ1dCBCTEtfREVWX1NEIG1heQojCgojCiMgYWxzbyBiZSBuZWVkZWQ7IHNlZSBVU0Jf
U1RPUkFHRSBIZWxwIGZvciBtb3JlIGluZm8KIwojIENPTkZJR19VU0JfU1RPUkFHRSBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9VQVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfTElCVVNVQUwgaXMg
bm90IHNldAoKIwojIFVTQiBJbWFnaW5nIGRldmljZXMKIwojIENPTkZJR19VU0JfTURDODAwIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX01JQ1JPVEVLIGlzIG5vdCBzZXQKCiMKIyBVU0IgcG9ydCBk
cml2ZXJzCiMKIyBDT05GSUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxh
bmVvdXMgZHJpdmVycwojCiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9FTUkyNiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENPTkZJ
R19VU0JfU0VWU0VHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9MRUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENEIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVBSRVNTX0NZN0M2
MyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X0lETU9VU0UgaXMgbm90IHNldAojIENPTkZJR19VU0JfRlRESV9FTEFOIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX0FQUExFRElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MRCBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9UUkFOQ0VWSUJSQVRPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9J
T1dBUlJJT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9JU0lHSFRGVyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ZVVJFWCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9HQURHRVQgaXMgbm90IHNldAoKIwojIE9URyBhbmQgcmVsYXRlZCBpbmZyYXN0
cnVjdHVyZQojCiMgQ09ORklHX1VTQl9HUElPX1ZCVVMgaXMgbm90IHNldAojIENPTkZJR19OT1Bf
VVNCX1hDRUlWIGlzIG5vdCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1D
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9
eQpDT05GSUdfTEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xN
MzUzMCBpcyBub3Qgc2V0CkNPTkZJR19MRURTX0FMSVgyPW0KQ09ORklHX0xFRFNfUENBOTUzMj1t
CiMgQ09ORklHX0xFRFNfUENBOTUzMl9HUElPIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19HUElP
IGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfTFAzOTQ0PW0KIyBDT05GSUdfTEVEU19MUDU1MjEgaXMg
bm90IHNldAojIENPTkZJR19MRURTX0xQNTUyMyBpcyBub3Qgc2V0CkNPTkZJR19MRURTX0NMRVZP
X01BSUw9bQpDT05GSUdfTEVEU19QQ0E5NTVYPW0KQ09ORklHX0xFRFNfQkQyODAyPW0KIyBDT05G
SUdfTEVEU19JTlRFTF9TUzQyMDAgaXMgbm90IHNldAojIENPTkZJR19MRURTX0xUMzU5MyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0xFRFNfREVMTF9ORVRCT09LUyBpcyBub3Qgc2V0CkNPTkZJR19MRURT
X1RSSUdHRVJTPXkKCiMKIyBMRUQgVHJpZ2dlcnMKIwpDT05GSUdfTEVEU19UUklHR0VSX1RJTUVS
PW0KQ09ORklHX0xFRFNfVFJJR0dFUl9IRUFSVEJFQVQ9bQpDT05GSUdfTEVEU19UUklHR0VSX0JB
Q0tMSUdIVD1tCiMgQ09ORklHX0xFRFNfVFJJR0dFUl9HUElPIGlzIG5vdCBzZXQKQ09ORklHX0xF
RFNfVFJJR0dFUl9ERUZBVUxUX09OPW0KCiMKIyBpcHRhYmxlcyB0cmlnZ2VyIGlzIHVuZGVyIE5l
dGZpbHRlciBjb25maWcgKExFRCB0YXJnZXQpCiMKIyBDT05GSUdfTkZDX0RFVklDRVMgaXMgbm90
IHNldAojIENPTkZJR19BQ0NFU1NJQklMSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5GSU5JQkFO
RCBpcyBub3Qgc2V0CkNPTkZJR19FREFDPXkKCiMKIyBSZXBvcnRpbmcgc3Vic3lzdGVtcwojCiMg
Q09ORklHX0VEQUNfREVCVUcgaXMgbm90IHNldApDT05GSUdfRURBQ19ERUNPREVfTUNFPW0KIyBD
T05GSUdfRURBQ19NQ0VfSU5KIGlzIG5vdCBzZXQKQ09ORklHX0VEQUNfTU1fRURBQz1tCiMgQ09O
RklHX0VEQUNfQU1ENjQgaXMgbm90IHNldApDT05GSUdfRURBQ19FNzUyWD1tCkNPTkZJR19FREFD
X0k4Mjk3NVg9bQpDT05GSUdfRURBQ19JMzAwMD1tCkNPTkZJR19FREFDX0kzMjAwPW0KQ09ORklH
X0VEQUNfWDM4PW0KQ09ORklHX0VEQUNfSTU0MDA9bQojIENPTkZJR19FREFDX0k3Q09SRSBpcyBu
b3Qgc2V0CkNPTkZJR19FREFDX0k1MDAwPW0KQ09ORklHX0VEQUNfSTUxMDA9bQojIENPTkZJR19F
REFDX0k3MzAwIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19MSUI9eQpDT05GSUdfUlRDX0NMQVNTPXkK
Q09ORklHX1JUQ19IQ1RPU1lTPXkKQ09ORklHX1JUQ19IQ1RPU1lTX0RFVklDRT0icnRjMCIKIyBD
T05GSUdfUlRDX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBSVEMgaW50ZXJmYWNlcwojCkNPTkZJR19S
VENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9QUk9DPXkKQ09ORklHX1JUQ19JTlRGX0RF
Vj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVfRU1VTCBpcyBub3Qgc2V0CiMgQ09ORklHX1JU
Q19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMgSTJDIFJUQyBkcml2ZXJzCiMKIyBDT05GSUdfUlRD
X0RSVl9EUzEzMDcgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTM3NCBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfRFMxNjcyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzMy
MzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX01BWDY5MDAgaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX1JTNUMzNzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0lTTDEyMDggaXMg
bm90IHNldAojIENPTkZJR19SVENfRFJWX0lTTDEyMDIyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD
X0RSVl9YMTIwNSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUENGODU2MyBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfUENGODU4MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQx
VDgwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9CUTMySyBpcyBub3Qgc2V0CiMgQ09ORklH
X1JUQ19EUlZfUzM1MzkwQSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRk0zMTMwIGlzIG5v
dCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SWDg1ODEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW
X1JYODAyNSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRU0zMDI3IGlzIG5vdCBzZXQKIyBD
T05GSUdfUlRDX0RSVl9SVjMwMjlDMiBpcyBub3Qgc2V0CgojCiMgU1BJIFJUQyBkcml2ZXJzCiMK
CiMKIyBQbGF0Zm9ybSBSVEMgZHJpdmVycwojCiMgQ09ORklHX1JUQ19EUlZfQ01PUyBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMjg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9E
UzE1MTEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTU1MyBpcyBub3Qgc2V0CiMgQ09O
RklHX1JUQ19EUlZfRFMxNzQyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9TVEsxN1RBOCBp
cyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD
X0RSVl9NNDhUMzUgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX000OFQ1OSBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfTVNNNjI0MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfQlE0
ODAyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SUDVDMDEgaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX1YzMDIwIGlzIG5vdCBzZXQKCiMKIyBvbi1DUFUgUlRDIGRyaXZlcnMKIwojIENP
TkZJR19ETUFERVZJQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfQVVYRElTUExBWSBpcyBub3Qgc2V0
CkNPTkZJR19VSU89bQojIENPTkZJR19VSU9fQ0lGIGlzIG5vdCBzZXQKIyBDT05GSUdfVUlPX1BE
UlYgaXMgbm90IHNldAojIENPTkZJR19VSU9fUERSVl9HRU5JUlEgaXMgbm90IHNldAojIENPTkZJ
R19VSU9fQUVDIGlzIG5vdCBzZXQKIyBDT05GSUdfVUlPX1NFUkNPUzMgaXMgbm90IHNldAojIENP
TkZJR19VSU9fUENJX0dFTkVSSUMgaXMgbm90IHNldAojIENPTkZJR19VSU9fTkVUWCBpcyBub3Qg
c2V0CgojCiMgWGVuIGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX1hFTl9CQUxMT09OPXkKQ09ORklH
X1hFTl9TQ1JVQl9QQUdFUz15CkNPTkZJR19YRU5fREVWX0VWVENITj15CiMgQ09ORklHX1hFTl9C
QUNLRU5EIGlzIG5vdCBzZXQKQ09ORklHX1hFTkZTPXkKQ09ORklHX1hFTl9DT01QQVRfWEVORlM9
eQpDT05GSUdfWEVOX1NZU19IWVBFUlZJU09SPXkKQ09ORklHX1hFTl9YRU5CVVNfRlJPTlRFTkQ9
eQpDT05GSUdfWEVOX0dOVERFVj15CkNPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DPXkKQ09ORklH
X1hFTl9QTEFURk9STV9QQ0k9bQpDT05GSUdfU1dJT1RMQl9YRU49eQpDT05GSUdfU1RBR0lORz15
CiMgQ09ORklHX1NUQUxMSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNUQUxMSU9OIGlzIG5vdCBz
ZXQKIyBDT05GSUdfRElHSUVQQ0EgaXMgbm90IHNldAojIENPTkZJR19SSVNDT004IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU1BFQ0lBTElYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09NUFVUT05FIGlzIG5v
dCBzZXQKIyBDT05GSUdfRVQxMzFYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xJQ09TUyBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQklQX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19FQ0hPIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQlJDTVVUSUwgaXMgbm90IHNldAojIENPTkZJR19DT01FREkgaXMgbm90IHNl
dAojIENPTkZJR19BU1VTX09MRUQgaXMgbm90IHNldAojIENPTkZJR19SVFNfUFNUT1IgaXMgbm90
IHNldAojIENPTkZJR19SVFM1MTM5IGlzIG5vdCBzZXQKIyBDT05GSUdfVFJBTlpQT1JUIGlzIG5v
dCBzZXQKIyBDT05GSUdfUE9ITUVMRlMgaXMgbm90IHNldAojIENPTkZJR19JREVfUEhJU09OIGlz
IG5vdCBzZXQKIyBDT05GSUdfRFJNX1ZNV0dGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9OT1VW
RUFVIGlzIG5vdCBzZXQKCiMKIyBJMkMgZW5jb2RlciBvciBoZWxwZXIgY2hpcHMKIwpDT05GSUdf
RFJNX0kyQ19DSDcwMDY9bQojIENPTkZJR19EUk1fSTJDX1NJTDE2NCBpcyBub3Qgc2V0CiMgQ09O
RklHX0hZUEVSViBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNRV9CVVMgaXMgbm90IHNldAojIENPTkZJ
R19EWF9TRVAgaXMgbm90IHNldAojIENPTkZJR19JSU8gaXMgbm90IHNldAojIENPTkZJR19YVk1B
TExPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1pSQU0gaXMgbm90IHNldAojIENPTkZJR19GQl9TTTdY
WCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVNUQUxIRCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1hH
SSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfUVVJQ0tTVEFSVCBpcyBub3Qgc2V0CkNPTkZJR19N
QUNIX05PX1dFU1RCUklER0U9eQojIENPTkZJR19VU0JfRU5FU1RPUkFHRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0JDTV9XSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZUMTAwMCBpcyBub3Qgc2V0Cgoj
CiMgU3BlYWt1cCBjb25zb2xlIHNwZWVjaAojCkNPTkZJR19TUEVBS1VQPW0KQ09ORklHX1NQRUFL
VVBfU1lOVEhfQUNOVFNBPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhfQUNOVFBDPW0KQ09ORklHX1NQ
RUFLVVBfU1lOVEhfQVBPTExPPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhfQVVEUFRSPW0KQ09ORklH
X1NQRUFLVVBfU1lOVEhfQk5TPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhfREVDVExLPW0KQ09ORklH
X1NQRUFLVVBfU1lOVEhfREVDRVhUPW0KIyBDT05GSUdfU1BFQUtVUF9TWU5USF9ERUNQQyBpcyBu
b3Qgc2V0CkNPTkZJR19TUEVBS1VQX1NZTlRIX0RUTEs9bQpDT05GSUdfU1BFQUtVUF9TWU5USF9L
RVlQQz1tCkNPTkZJR19TUEVBS1VQX1NZTlRIX0xUTEs9bQpDT05GSUdfU1BFQUtVUF9TWU5USF9T
T0ZUPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhfU1BLT1VUPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhf
VFhQUlQ9bQpDT05GSUdfU1BFQUtVUF9TWU5USF9EVU1NWT1tCiMgQ09ORklHX1RPVUNIU0NSRUVO
X0NMRUFSUEFEX1RNMTIxNyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1NZTkFQVElD
U19JMkNfUk1JNCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QU0IgaXMgbm90IHNldAoKIwojIEFs
dGVyYSBGUEdBIGZpcm13YXJlIGRvd25sb2FkIG1vZHVsZQojCiMgQ09ORklHX0FMVEVSQV9TVEFQ
TCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOVEVMX01FSSBpcyBub3Qgc2V0CkNPTkZJR19YODZfUExB
VEZPUk1fREVWSUNFUz15CiMgQ09ORklHX0FDRVJfV01JIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNF
UkhERiBpcyBub3Qgc2V0CiMgQ09ORklHX0FTVVNfTEFQVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdf
REVMTF9XTUkgaXMgbm90IHNldAojIENPTkZJR19ERUxMX1dNSV9BSU8gaXMgbm90IHNldAojIENP
TkZJR19GVUpJVFNVX0xBUFRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX0hQX0FDQ0VMIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSFBfV01JIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFOQVNPTklDX0xBUFRPUCBp
cyBub3Qgc2V0CiMgQ09ORklHX1RISU5LUEFEX0FDUEkgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX0hEQVBTIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URUxfTUVOTE9XIGlzIG5vdCBzZXQKQ09O
RklHX0FDUElfV01JPW0KIyBDT05GSUdfTVNJX1dNSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElf
QVNVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPUFNUQVJfTEFQVE9QIGlzIG5vdCBzZXQKIyBDT05G
SUdfQUNQSV9UT1NISUJBIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9TSElCQV9CVF9SRktJTEwgaXMg
bm90IHNldAojIENPTkZJR19BQ1BJX0NNUEMgaXMgbm90IHNldAojIENPTkZJR19JTlRFTF9JUFMg
aXMgbm90IHNldAojIENPTkZJR19JQk1fUlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfWE8xNV9FQk9P
SyBpcyBub3Qgc2V0CiMgQ09ORklHX01YTV9XTUkgaXMgbm90IHNldAoKIwojIFVidW50dSBTdXBw
bGllZCBUaGlyZC1QYXJ0eSBEZXZpY2UgRHJpdmVycwojCiMgQ09ORklHX05ESVNXUkFQUEVSIGlz
IG5vdCBzZXQKIyBDT05GSUdfQVZFUkFURUNfNTEwMFAgaXMgbm90IHNldAojIENPTkZJR19QQUNL
QVJEQkVMTF9FNSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZTQU03NDAwIGlzIG5vdCBzZXQKIyBDT05G
SUdfT01OSUJPT0sgaXMgbm90IHNldAojIENPTkZJR19BVUZTX0ZTIGlzIG5vdCBzZXQKCiMKIyBG
aXJtd2FyZSBEcml2ZXJzCiMKIyBDT05GSUdfRUREIGlzIG5vdCBzZXQKQ09ORklHX0ZJUk1XQVJF
X01FTU1BUD15CiMgQ09ORklHX0VGSV9WQVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVMTF9SQlUg
aXMgbm90IHNldAojIENPTkZJR19EQ0RCQVMgaXMgbm90IHNldAojIENPTkZJR19ETUlJRCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RNSV9TWVNGUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTQ1NJX0lCRlRf
RklORCBpcyBub3Qgc2V0CiMgQ09ORklHX1NJR01BIGlzIG5vdCBzZXQKIyBDT05GSUdfR09PR0xF
X0ZJUk1XQVJFIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwpDT05GSUdfRVhUMl9GUz15
CkNPTkZJR19FWFQyX0ZTX1hBVFRSPXkKQ09ORklHX0VYVDJfRlNfUE9TSVhfQUNMPXkKQ09ORklH
X0VYVDJfRlNfU0VDVVJJVFk9eQojIENPTkZJR19FWFQyX0ZTX1hJUCBpcyBub3Qgc2V0CkNPTkZJ
R19FWFQzX0ZTPXkKQ09ORklHX0VYVDNfREVGQVVMVFNfVE9fT1JERVJFRD15CkNPTkZJR19FWFQz
X0ZTX1hBVFRSPXkKQ09ORklHX0VYVDNfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VYVDNfRlNfU0VD
VVJJVFk9eQpDT05GSUdfRVhUNF9GUz15CkNPTkZJR19FWFQ0X0ZTX1hBVFRSPXkKQ09ORklHX0VY
VDRfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VYVDRfRlNfU0VDVVJJVFk9eQojIENPTkZJR19FWFQ0
X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0pCRD15CiMgQ09ORklHX0pCRF9ERUJVRyBpcyBub3Qg
c2V0CkNPTkZJR19KQkQyPXkKIyBDT05GSUdfSkJEMl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19G
U19NQkNBQ0hFPXkKIyBDT05GSUdfUkVJU0VSRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19KRlNf
RlMgaXMgbm90IHNldAojIENPTkZJR19YRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19HRlMyX0ZT
IGlzIG5vdCBzZXQKIyBDT05GSUdfT0NGUzJfRlMgaXMgbm90IHNldAojIENPTkZJR19CVFJGU19G
UyBpcyBub3Qgc2V0CiMgQ09ORklHX05JTEZTMl9GUyBpcyBub3Qgc2V0CkNPTkZJR19GU19QT1NJ
WF9BQ0w9eQpDT05GSUdfRklMRV9MT0NLSU5HPXkKQ09ORklHX0ZTTk9USUZZPXkKQ09ORklHX0RO
T1RJRlk9eQpDT05GSUdfSU5PVElGWV9VU0VSPXkKIyBDT05GSUdfRkFOT1RJRlkgaXMgbm90IHNl
dApDT05GSUdfUVVPVEE9eQpDT05GSUdfUVVPVEFfTkVUTElOS19JTlRFUkZBQ0U9eQpDT05GSUdf
UFJJTlRfUVVPVEFfV0FSTklORz15CiMgQ09ORklHX1FVT1RBX0RFQlVHIGlzIG5vdCBzZXQKIyBD
T05GSUdfUUZNVF9WMSBpcyBub3Qgc2V0CiMgQ09ORklHX1FGTVRfVjIgaXMgbm90IHNldApDT05G
SUdfUVVPVEFDVEw9eQpDT05GSUdfUVVPVEFDVExfQ09NUEFUPXkKIyBDT05GSUdfQVVUT0ZTNF9G
UyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZVU0VfRlMgaXMgbm90IHNldAojIENPTkZJR19PVkVSTEFZ
RlNfRlMgaXMgbm90IHNldApDT05GSUdfR0VORVJJQ19BQ0w9eQoKIwojIENhY2hlcwojCkNPTkZJ
R19GU0NBQ0hFPW0KQ09ORklHX0ZTQ0FDSEVfU1RBVFM9eQojIENPTkZJR19GU0NBQ0hFX0hJU1RP
R1JBTSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZTQ0FDSEVfREVCVUcgaXMgbm90IHNldAojIENPTkZJ
R19GU0NBQ0hFX09CSkVDVF9MSVNUIGlzIG5vdCBzZXQKQ09ORklHX0NBQ0hFRklMRVM9bQojIENP
TkZJR19DQUNIRUZJTEVTX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FDSEVGSUxFU19ISVNU
T0dSQU0gaXMgbm90IHNldAoKIwojIENELVJPTS9EVkQgRmlsZXN5c3RlbXMKIwpDT05GSUdfSVNP
OTY2MF9GUz1tCkNPTkZJR19KT0xJRVQ9eQpDT05GSUdfWklTT0ZTPXkKQ09ORklHX1VERl9GUz1t
CkNPTkZJR19VREZfTkxTPXkKCiMKIyBET1MvRkFUL05UIEZpbGVzeXN0ZW1zCiMKQ09ORklHX0ZB
VF9GUz1tCkNPTkZJR19NU0RPU19GUz1tCkNPTkZJR19WRkFUX0ZTPW0KQ09ORklHX0ZBVF9ERUZB
VUxUX0NPREVQQUdFPTQzNwpDT05GSUdfRkFUX0RFRkFVTFRfSU9DSEFSU0VUPSJ1dGY4IgpDT05G
SUdfTlRGU19GUz1tCiMgQ09ORklHX05URlNfREVCVUcgaXMgbm90IHNldApDT05GSUdfTlRGU19S
Vz15CgojCiMgUHNldWRvIGZpbGVzeXN0ZW1zCiMKQ09ORklHX1BST0NfRlM9eQpDT05GSUdfUFJP
Q19LQ09SRT15CkNPTkZJR19QUk9DX1NZU0NUTD15CkNPTkZJR19QUk9DX1BBR0VfTU9OSVRPUj15
CkNPTkZJR19TWVNGUz15CkNPTkZJR19UTVBGUz15CkNPTkZJR19UTVBGU19QT1NJWF9BQ0w9eQpD
T05GSUdfVE1QRlNfWEFUVFI9eQpDT05GSUdfSFVHRVRMQkZTPXkKQ09ORklHX0hVR0VUTEJfUEFH
RT15CkNPTkZJR19DT05GSUdGU19GUz1tCkNPTkZJR19NSVNDX0ZJTEVTWVNURU1TPXkKIyBDT05G
SUdfQURGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldAojIENPTkZJ
R19IRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19IRlNQTFVTX0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkVGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0VGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xPR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JB
TUZTIGlzIG5vdCBzZXQKIyBDT05GSUdfU1FVQVNIRlMgaXMgbm90IHNldAojIENPTkZJR19WWEZT
X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlOSVhfRlMgaXMgbm90IHNldAojIENPTkZJR19PTUZT
X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSFBGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1FOWDRG
U19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JPTUZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfUFNU
T1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lTVl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VGU19G
UyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVFdPUktfRklMRVNZU1RFTVMgaXMgbm90IHNldAoKIwoj
IFBhcnRpdGlvbiBUeXBlcwojCkNPTkZJR19QQVJUSVRJT05fQURWQU5DRUQ9eQpDT05GSUdfQUNP
Uk5fUEFSVElUSU9OPXkKIyBDT05GSUdfQUNPUk5fUEFSVElUSU9OX0NVTUFOQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0FDT1JOX1BBUlRJVElPTl9FRVNPWCBpcyBub3Qgc2V0CkNPTkZJR19BQ09STl9Q
QVJUSVRJT05fSUNTPXkKIyBDT05GSUdfQUNPUk5fUEFSVElUSU9OX0FERlMgaXMgbm90IHNldAoj
IENPTkZJR19BQ09STl9QQVJUSVRJT05fUE9XRVJURUMgaXMgbm90IHNldApDT05GSUdfQUNPUk5f
UEFSVElUSU9OX1JJU0NJWD15CkNPTkZJR19PU0ZfUEFSVElUSU9OPXkKQ09ORklHX0FNSUdBX1BB
UlRJVElPTj15CkNPTkZJR19BVEFSSV9QQVJUSVRJT049eQpDT05GSUdfTUFDX1BBUlRJVElPTj15
CkNPTkZJR19NU0RPU19QQVJUSVRJT049eQpDT05GSUdfQlNEX0RJU0tMQUJFTD15CkNPTkZJR19N
SU5JWF9TVUJQQVJUSVRJT049eQpDT05GSUdfU09MQVJJU19YODZfUEFSVElUSU9OPXkKQ09ORklH
X1VOSVhXQVJFX0RJU0tMQUJFTD15CkNPTkZJR19MRE1fUEFSVElUSU9OPXkKIyBDT05GSUdfTERN
X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1NHSV9QQVJUSVRJT049eQpDT05GSUdfVUxUUklYX1BB
UlRJVElPTj15CkNPTkZJR19TVU5fUEFSVElUSU9OPXkKQ09ORklHX0tBUk1BX1BBUlRJVElPTj15
CkNPTkZJR19FRklfUEFSVElUSU9OPXkKIyBDT05GSUdfU1lTVjY4X1BBUlRJVElPTiBpcyBub3Qg
c2V0CkNPTkZJR19OTFM9eQpDT05GSUdfTkxTX0RFRkFVTFQ9InV0ZjgiCkNPTkZJR19OTFNfQ09E
RVBBR0VfNDM3PW0KQ09ORklHX05MU19DT0RFUEFHRV83Mzc9bQpDT05GSUdfTkxTX0NPREVQQUdF
Xzc3NT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODUwPW0KQ09ORklHX05MU19DT0RFUEFHRV84NTI9
bQpDT05GSUdfTkxTX0NPREVQQUdFXzg1NT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODU3PW0KQ09O
RklHX05MU19DT0RFUEFHRV84NjA9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2MT1tCkNPTkZJR19O
TFNfQ09ERVBBR0VfODYyPW0KQ09ORklHX05MU19DT0RFUEFHRV84NjM9bQpDT05GSUdfTkxTX0NP
REVQQUdFXzg2ND1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODY1PW0KQ09ORklHX05MU19DT0RFUEFH
RV84NjY9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2OT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfOTM2
PW0KQ09ORklHX05MU19DT0RFUEFHRV85NTA9bQpDT05GSUdfTkxTX0NPREVQQUdFXzkzMj1tCkNP
TkZJR19OTFNfQ09ERVBBR0VfOTQ5PW0KQ09ORklHX05MU19DT0RFUEFHRV84NzQ9bQpDT05GSUdf
TkxTX0lTTzg4NTlfOD1tCkNPTkZJR19OTFNfQ09ERVBBR0VfMTI1MD1tCkNPTkZJR19OTFNfQ09E
RVBBR0VfMTI1MT1tCkNPTkZJR19OTFNfQVNDSUk9bQpDT05GSUdfTkxTX0lTTzg4NTlfMT1tCkNP
TkZJR19OTFNfSVNPODg1OV8yPW0KQ09ORklHX05MU19JU084ODU5XzM9bQpDT05GSUdfTkxTX0lT
Tzg4NTlfND1tCkNPTkZJR19OTFNfSVNPODg1OV81PW0KQ09ORklHX05MU19JU084ODU5XzY9bQpD
T05GSUdfTkxTX0lTTzg4NTlfNz1tCkNPTkZJR19OTFNfSVNPODg1OV85PW0KQ09ORklHX05MU19J
U084ODU5XzEzPW0KQ09ORklHX05MU19JU084ODU5XzE0PW0KQ09ORklHX05MU19JU084ODU5XzE1
PW0KQ09ORklHX05MU19LT0k4X1I9bQpDT05GSUdfTkxTX0tPSThfVT1tCkNPTkZJR19OTFNfVVRG
OD1tCiMgQ09ORklHX0RMTSBpcyBub3Qgc2V0CgojCiMgS2VybmVsIGhhY2tpbmcKIwpDT05GSUdf
VFJBQ0VfSVJRRkxBR1NfU1VQUE9SVD15CkNPTkZJR19QUklOVEtfVElNRT15CkNPTkZJR19ERUZB
VUxUX01FU1NBR0VfTE9HTEVWRUw9NwpDT05GSUdfRU5BQkxFX1dBUk5fREVQUkVDQVRFRD15CkNP
TkZJR19FTkFCTEVfTVVTVF9DSEVDSz15CkNPTkZJR19GUkFNRV9XQVJOPTIwNDgKQ09ORklHX01B
R0lDX1NZU1JRPXkKQ09ORklHX1NUUklQX0FTTV9TWU1TPXkKQ09ORklHX1VOVVNFRF9TWU1CT0xT
PXkKQ09ORklHX0RFQlVHX0ZTPXkKIyBDT05GSUdfSEVBREVSU19DSEVDSyBpcyBub3Qgc2V0CiMg
Q09ORklHX0RFQlVHX1NFQ1RJT05fTUlTTUFUQ0ggaXMgbm90IHNldApDT05GSUdfREVCVUdfS0VS
TkVMPXkKQ09ORklHX0RFQlVHX1NISVJRPXkKIyBDT05GSUdfTE9DS1VQX0RFVEVDVE9SIGlzIG5v
dCBzZXQKIyBDT05GSUdfSEFSRExPQ0tVUF9ERVRFQ1RPUiBpcyBub3Qgc2V0CkNPTkZJR19ERVRF
Q1RfSFVOR19UQVNLPXkKQ09ORklHX0RFRkFVTFRfSFVOR19UQVNLX1RJTUVPVVQ9MTIwCiMgQ09O
RklHX0JPT1RQQVJBTV9IVU5HX1RBU0tfUEFOSUMgaXMgbm90IHNldApDT05GSUdfQk9PVFBBUkFN
X0hVTkdfVEFTS19QQU5JQ19WQUxVRT0wCkNPTkZJR19TQ0hFRF9ERUJVRz15CiMgQ09ORklHX1ND
SEVEU1RBVFMgaXMgbm90IHNldApDT05GSUdfVElNRVJfU1RBVFM9eQojIENPTkZJR19ERUJVR19P
QkpFQ1RTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xVQl9ERUJVR19PTiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NMVUJfU1RBVFMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19SVF9NVVRFWEVTIGlzIG5v
dCBzZXQKIyBDT05GSUdfUlRfTVVURVhfVEVTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdf
U1BJTkxPQ0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19NVVRFWEVTIGlzIG5vdCBzZXQKIyBD
T05GSUdfREVCVUdfTE9DS19BTExPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1BST1ZFX0xPQ0tJTkcg
aXMgbm90IHNldAojIENPTkZJR19TUEFSU0VfUkNVX1BPSU5URVIgaXMgbm90IHNldAojIENPTkZJ
R19MT0NLX1NUQVQgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19TUElOTE9DS19TTEVFUCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RFQlVHX0xPQ0tJTkdfQVBJX1NFTEZURVNUUyBpcyBub3Qgc2V0CkNP
TkZJR19TVEFDS1RSQUNFPXkKIyBDT05GSUdfREVCVUdfU1RBQ0tfVVNBR0UgaXMgbm90IHNldAoj
IENPTkZJR19ERUJVR19LT0JKRUNUIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0JVR1ZFUkJPU0U9
eQpDT05GSUdfREVCVUdfSU5GTz15CiMgQ09ORklHX0RFQlVHX0lORk9fUkVEVUNFRCBpcyBub3Qg
c2V0CiMgQ09ORklHX0RFQlVHX1ZNIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVklSVFVBTCBp
cyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1dSSVRFQ09VTlQgaXMgbm90IHNldAojIENPTkZJR19E
RUJVR19NRU1PUllfSU5JVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0xJU1QgaXMgbm90IHNl
dAojIENPTkZJR19URVNUX0xJU1RfU09SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NHIGlz
IG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTk9USUZJRVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVC
VUdfQ1JFREVOVElBTFMgaXMgbm90IHNldApDT05GSUdfQVJDSF9XQU5UX0ZSQU1FX1BPSU5URVJT
PXkKQ09ORklHX0ZSQU1FX1BPSU5URVI9eQojIENPTkZJR19CT09UX1BSSU5US19ERUxBWSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMgbm90IHNldApDT05GSUdfUkNVX0NQ
VV9TVEFMTF9USU1FT1VUPTYwCkNPTkZJR19LUFJPQkVTX1NBTklUWV9URVNUPXkKIyBDT05GSUdf
QkFDS1RSQUNFX1NFTEZfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0JMT0NLX0VYVF9E
RVZUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfRk9SQ0VfV0VBS19QRVJfQ1BVIGlzIG5vdCBz
ZXQKIyBDT05GSUdfREVCVUdfUEVSX0NQVV9NQVBTIGlzIG5vdCBzZXQKIyBDT05GSUdfTEtEVE0g
aXMgbm90IHNldAojIENPTkZJR19DUFVfTk9USUZJRVJfRVJST1JfSU5KRUNUIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkFVTFRfSU5KRUNUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFURU5DWVRPUCBp
cyBub3Qgc2V0CkNPTkZJR19TWVNDVExfU1lTQ0FMTF9DSEVDSz15CiMgQ09ORklHX0RFQlVHX1BB
R0VBTExPQyBpcyBub3Qgc2V0CkNPTkZJR19VU0VSX1NUQUNLVFJBQ0VfU1VQUE9SVD15CkNPTkZJ
R19OT1BfVFJBQ0VSPXkKQ09ORklHX0hBVkVfRlRSQUNFX05NSV9FTlRFUj15CkNPTkZJR19IQVZF
X0ZVTkNUSU9OX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15CkNP
TkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX0ZQX1RFU1Q9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9U
UkFDRV9NQ09VTlRfVEVTVD15CkNPTkZJR19IQVZFX0RZTkFNSUNfRlRSQUNFPXkKQ09ORklHX0hB
VkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFWRV9TWVNDQUxMX1RSQUNFUE9JTlRT
PXkKQ09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpDT05GSUdfUklOR19CVUZGRVI9eQpDT05G
SUdfRlRSQUNFX05NSV9FTlRFUj15CkNPTkZJR19FVkVOVF9UUkFDSU5HPXkKQ09ORklHX0VWRU5U
X1BPV0VSX1RSQUNJTkdfREVQUkVDQVRFRD15CkNPTkZJR19DT05URVhUX1NXSVRDSF9UUkFDRVI9
eQpDT05GSUdfUklOR19CVUZGRVJfQUxMT1dfU1dBUD15CkNPTkZJR19UUkFDSU5HPXkKQ09ORklH
X0dFTkVSSUNfVFJBQ0VSPXkKQ09ORklHX1RSQUNJTkdfU1VQUE9SVD15CkNPTkZJR19GVFJBQ0U9
eQpDT05GSUdfRlVOQ1RJT05fVFJBQ0VSPXkKQ09ORklHX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15
CiMgQ09ORklHX0lSUVNPRkZfVFJBQ0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NIRURfVFJBQ0VS
IGlzIG5vdCBzZXQKQ09ORklHX0ZUUkFDRV9TWVNDQUxMUz15CkNPTkZJR19CUkFOQ0hfUFJPRklM
RV9OT05FPXkKIyBDT05GSUdfUFJPRklMRV9BTk5PVEFURURfQlJBTkNIRVMgaXMgbm90IHNldAoj
IENPTkZJR19QUk9GSUxFX0FMTF9CUkFOQ0hFUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NUQUNLX1RS
QUNFUiBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0lPX1RSQUNFPXkKQ09ORklHX0tQUk9CRV9F
VkVOVD15CkNPTkZJR19EWU5BTUlDX0ZUUkFDRT15CiMgQ09ORklHX0ZVTkNUSU9OX1BST0ZJTEVS
IGlzIG5vdCBzZXQKQ09ORklHX0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKIyBDT05GSUdfRlRSQUNF
X1NUQVJUVVBfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX01NSU9UUkFDRSBpcyBub3Qgc2V0CiMg
Q09ORklHX1JJTkdfQlVGRkVSX0JFTkNITUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX1BST1ZJREVf
T0hDSTEzOTRfRE1BX0lOSVQgaXMgbm90IHNldAojIENPTkZJR19GSVJFV0lSRV9PSENJX1JFTU9U
RV9ETUEgaXMgbm90IHNldApDT05GSUdfRFlOQU1JQ19ERUJVRz15CiMgQ09ORklHX0RNQV9BUElf
REVCVUcgaXMgbm90IHNldAojIENPTkZJR19BVE9NSUM2NF9TRUxGVEVTVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tHREI9eQpDT05GSUdf
S0dEQj15CkNPTkZJR19LR0RCX1NFUklBTF9DT05TT0xFPXkKQ09ORklHX0tHREJfVEVTVFM9eQpD
T05GSUdfS0dEQl9URVNUU19PTl9CT09UPXkKQ09ORklHX0tHREJfVEVTVFNfQk9PVF9TVFJJTkc9
IlYxRjEwMCIKQ09ORklHX0tHREJfTE9XX0xFVkVMX1RSQVA9eQojIENPTkZJR19LR0RCX0tEQiBp
cyBub3Qgc2V0CkNPTkZJR19IQVZFX0FSQ0hfS01FTUNIRUNLPXkKIyBDT05GSUdfVEVTVF9LU1RS
VE9YIGlzIG5vdCBzZXQKQ09ORklHX1NUUklDVF9ERVZNRU09eQpDT05GSUdfWDg2X1ZFUkJPU0Vf
Qk9PVFVQPXkKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0VBUkxZX1BSSU5US19EQkdQ
IGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU1RBQ0tPVkVSRkxPVyBpcyBub3Qgc2V0CiMgQ09O
RklHX1g4Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9EQVRBPXkKIyBDT05GSUdf
REVCVUdfUk9EQVRBX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19TRVRfTU9EVUxFX1JP
TlggaXMgbm90IHNldAojIENPTkZJR19ERUJVR19OWF9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdf
SU9NTVVfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19JT01NVV9TVFJFU1MgaXMgbm90IHNldApD
T05GSUdfSEFWRV9NTUlPVFJBQ0VfU1VQUE9SVD15CiMgQ09ORklHX1g4Nl9ERUNPREVSX1NFTEZU
RVNUIGlzIG5vdCBzZXQKQ09ORklHX0lPX0RFTEFZX1RZUEVfMFg4MD0wCkNPTkZJR19JT19ERUxB
WV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9VREVMQVk9MgpDT05GSUdfSU9fREVM
QVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9eQojIENPTkZJR19JT19ERUxBWV8w
WEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURFTEFZIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9
MApDT05GSUdfREVCVUdfQk9PVF9QQVJBTVM9eQojIENPTkZJR19DUEFfREVCVUcgaXMgbm90IHNl
dApDT05GSUdfT1BUSU1JWkVfSU5MSU5JTkc9eQojIENPTkZJR19ERUJVR19TVFJJQ1RfVVNFUl9D
T1BZX0NIRUNLUyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1NFQ0NPTVBfRklMVEVSPXkKCiMKIyBT
ZWN1cml0eSBvcHRpb25zCiMKIyBDT05GSUdfS0VZUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VS
SVRZX0RNRVNHX1JFU1RSSUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDQ09NUF9GSUxURVIgaXMg
bm90IHNldAojIENPTkZJR19TRUNVUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZRlMg
aXMgbm90IHNldAojIENPTkZJR19JTlRFTF9UWFQgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9T
RUNVUklUWV9EQUM9eQpDT05GSUdfREVGQVVMVF9TRUNVUklUWT0iIgpDT05GSUdfQ1JZUFRPPXkK
CiMKIyBDcnlwdG8gY29yZSBvciBoZWxwZXIKIwpDT05GSUdfQ1JZUFRPX0FMR0FQST15CkNPTkZJ
R19DUllQVE9fQUxHQVBJMj15CkNPTkZJR19DUllQVE9fQUVBRD1tCkNPTkZJR19DUllQVE9fQUVB
RDI9eQpDT05GSUdfQ1JZUFRPX0JMS0NJUEhFUj1tCkNPTkZJR19DUllQVE9fQkxLQ0lQSEVSMj15
CkNPTkZJR19DUllQVE9fSEFTSD15CkNPTkZJR19DUllQVE9fSEFTSDI9eQpDT05GSUdfQ1JZUFRP
X1JORz1tCkNPTkZJR19DUllQVE9fUk5HMj15CkNPTkZJR19DUllQVE9fUENPTVA9bQpDT05GSUdf
Q1JZUFRPX1BDT01QMj15CkNPTkZJR19DUllQVE9fTUFOQUdFUj15CkNPTkZJR19DUllQVE9fTUFO
QUdFUjI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVJfRElTQUJMRV9URVNUUz15CkNPTkZJR19DUllQ
VE9fR0YxMjhNVUw9bQpDT05GSUdfQ1JZUFRPX05VTEw9bQojIENPTkZJR19DUllQVE9fUENSWVBU
IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19XT1JLUVVFVUU9eQojIENPTkZJR19DUllQVE9fQ1JZ
UFREIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19BVVRIRU5DPW0KQ09ORklHX0NSWVBUT19URVNU
PW0KCiMKIyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEKIwpD
T05GSUdfQ1JZUFRPX0NDTT1tCkNPTkZJR19DUllQVE9fR0NNPW0KQ09ORklHX0NSWVBUT19TRVFJ
Vj1tCgojCiMgQmxvY2sgbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0NCQz1tCkNPTkZJR19DUllQVE9f
Q1RSPW0KQ09ORklHX0NSWVBUT19DVFM9bQpDT05GSUdfQ1JZUFRPX0VDQj1tCkNPTkZJR19DUllQ
VE9fTFJXPW0KQ09ORklHX0NSWVBUT19QQ0JDPW0KQ09ORklHX0NSWVBUT19YVFM9bQoKIwojIEhh
c2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0hNQUM9bQpDT05GSUdfQ1JZUFRPX1hDQkM9bQpDT05G
SUdfQ1JZUFRPX1ZNQUM9bQoKIwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPW0KQ09O
RklHX0NSWVBUT19DUkMzMkNfSU5URUw9bQpDT05GSUdfQ1JZUFRPX0dIQVNIPW0KQ09ORklHX0NS
WVBUT19NRDQ9bQpDT05GSUdfQ1JZUFRPX01ENT15CkNPTkZJR19DUllQVE9fTUlDSEFFTF9NSUM9
bQpDT05GSUdfQ1JZUFRPX1JNRDEyOD1tCkNPTkZJR19DUllQVE9fUk1EMTYwPW0KQ09ORklHX0NS
WVBUT19STUQyNTY9bQpDT05GSUdfQ1JZUFRPX1JNRDMyMD1tCkNPTkZJR19DUllQVE9fU0hBMT1t
CkNPTkZJR19DUllQVE9fU0hBMjU2PW0KQ09ORklHX0NSWVBUT19TSEE1MTI9bQpDT05GSUdfQ1JZ
UFRPX1RHUjE5Mj1tCkNPTkZJR19DUllQVE9fV1A1MTI9bQojIENPTkZJR19DUllQVE9fR0hBU0hf
Q0xNVUxfTklfSU5URUwgaXMgbm90IHNldAoKIwojIENpcGhlcnMKIwpDT05GSUdfQ1JZUFRPX0FF
Uz1tCiMgQ09ORklHX0NSWVBUT19BRVNfWDg2XzY0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRP
X0FFU19OSV9JTlRFTCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fQU5VQklTPW0KQ09ORklHX0NS
WVBUT19BUkM0PW0KQ09ORklHX0NSWVBUT19CTE9XRklTSD1tCkNPTkZJR19DUllQVE9fQ0FNRUxM
SUE9bQpDT05GSUdfQ1JZUFRPX0NBU1Q1PW0KQ09ORklHX0NSWVBUT19DQVNUNj1tCkNPTkZJR19D
UllQVE9fREVTPW0KQ09ORklHX0NSWVBUT19GQ1JZUFQ9bQpDT05GSUdfQ1JZUFRPX0tIQVpBRD1t
CkNPTkZJR19DUllQVE9fU0FMU0EyMD1tCiMgQ09ORklHX0NSWVBUT19TQUxTQTIwX1g4Nl82NCBp
cyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0VFRD1tCkNPTkZJR19DUllQVE9fU0VSUEVOVD1tCkNP
TkZJR19DUllQVE9fVEVBPW0KQ09ORklHX0NSWVBUT19UV09GSVNIPW0KQ09ORklHX0NSWVBUT19U
V09GSVNIX0NPTU1PTj1tCiMgQ09ORklHX0NSWVBUT19UV09GSVNIX1g4Nl82NCBpcyBub3Qgc2V0
CgojCiMgQ29tcHJlc3Npb24KIwpDT05GSUdfQ1JZUFRPX0RFRkxBVEU9bQpDT05GSUdfQ1JZUFRP
X1pMSUI9bQpDT05GSUdfQ1JZUFRPX0xaTz1tCgojCiMgUmFuZG9tIE51bWJlciBHZW5lcmF0aW9u
CiMKQ09ORklHX0NSWVBUT19BTlNJX0NQUk5HPW0KIyBDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX0hB
U0ggaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fVVNFUl9BUElfU0tDSVBIRVIgaXMgbm90IHNl
dApDT05GSUdfQ1JZUFRPX0hXPXkKQ09ORklHX0NSWVBUT19ERVZfUEFETE9DSz1tCkNPTkZJR19D
UllQVE9fREVWX1BBRExPQ0tfQUVTPW0KQ09ORklHX0NSWVBUT19ERVZfUEFETE9DS19TSEE9bQpD
T05GSUdfQ1JZUFRPX0RFVl9ISUZOXzc5NVg9bQpDT05GSUdfQ1JZUFRPX0RFVl9ISUZOXzc5NVhf
Uk5HPXkKQ09ORklHX0hBVkVfS1ZNPXkKQ09ORklHX1ZJUlRVQUxJWkFUSU9OPXkKIyBDT05GSUdf
S1ZNIGlzIG5vdCBzZXQKIyBDT05GSUdfVkhPU1RfTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfVklS
VElPX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJUlRJT19CQUxMT09OIGlzIG5vdCBzZXQKQ09O
RklHX0JJTkFSWV9QUklOVEY9eQoKIwojIExpYnJhcnkgcm91dGluZXMKIwpDT05GSUdfQklUUkVW
RVJTRT15CkNPTkZJR19HRU5FUklDX0ZJTkRfRklSU1RfQklUPXkKQ09ORklHX0NSQ19DQ0lUVD1t
CkNPTkZJR19DUkMxNj15CkNPTkZJR19DUkNfVDEwRElGPW0KQ09ORklHX0NSQ19JVFVfVD1tCkNP
TkZJR19DUkMzMj15CkNPTkZJR19DUkM3PW0KQ09ORklHX0xJQkNSQzMyQz1tCkNPTkZJR19aTElC
X0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPW0KQ09ORklHX0xaT19DT01QUkVTUz15CkNP
TkZJR19MWk9fREVDT01QUkVTUz15CkNPTkZJR19YWl9ERUM9eQpDT05GSUdfWFpfREVDX1g4Nj15
CkNPTkZJR19YWl9ERUNfUE9XRVJQQz15CkNPTkZJR19YWl9ERUNfSUE2ND15CkNPTkZJR19YWl9E
RUNfQVJNPXkKQ09ORklHX1haX0RFQ19BUk1USFVNQj15CkNPTkZJR19YWl9ERUNfU1BBUkM9eQpD
T05GSUdfWFpfREVDX0JDSj15CiMgQ09ORklHX1haX0RFQ19URVNUIGlzIG5vdCBzZXQKQ09ORklH
X0RFQ09NUFJFU1NfR1pJUD15CkNPTkZJR19URVhUU0VBUkNIPXkKQ09ORklHX1RFWFRTRUFSQ0hf
S01QPW0KQ09ORklHX1RFWFRTRUFSQ0hfQk09bQpDT05GSUdfVEVYVFNFQVJDSF9GU009bQpDT05G
SUdfSEFTX0lPTUVNPXkKQ09ORklHX0hBU19JT1BPUlQ9eQpDT05GSUdfSEFTX0RNQT15CkNPTkZJ
R19DSEVDS19TSUdOQVRVUkU9eQpDT05GSUdfQ1BVX1JNQVA9eQpDT05GSUdfTkxBVFRSPXkKQ09O
RklHX0FWRVJBR0U9eQo=
--e89a8f23505b701ae504b7be9eb0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--e89a8f23505b701ae504b7be9eb0--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 13:14:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 13: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 1Rrr3b-0004sO-Vh; Mon, 30 Jan 2012 13:14:03 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paulian@marinca.net>) id 1Rrr3Z-0004sJ-Jn
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 13:14:02 +0000
X-Env-Sender: paulian@marinca.net
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327929183!54588757!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23355 invoked from network); 30 Jan 2012 13:13:03 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 13:13:03 -0000
Received: by wibhm2 with SMTP id hm2so13274587wib.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 05:13:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.109.198 with SMTP id hu6mr28291141wib.16.1327929236658;
	Mon, 30 Jan 2012 05:13:56 -0800 (PST)
Received: by 10.216.17.83 with HTTP; Mon, 30 Jan 2012 05:13:56 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
	<alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
Date: Mon, 30 Jan 2012 13:13:56 +0000
Message-ID: <CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
From: Paulian Bogdan Marinca <paulian@marinca.net>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Content-Type: multipart/mixed; boundary=e89a8f23505b701ae504b7be9eb0
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--e89a8f23505b701ae504b7be9eb0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 30 January 2012 11:32, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Sat, 28 Jan 2012, Keir Fraser wrote:
>> On 27/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@marinca.net> wrot=
e:
>>
>> > I have a testing intel machine with 4 physical cpus running 64 bit Xen
>> > 4.1.3-rc1.
>> >
>> > I have a particular linux VM for which at its kernel boot time ( as
>> > domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
>> > console freezes indefinitely). The domU linux kernel is 3.2.1 and has
[...]
>
> That's right, this scenario should not be possible because whenever
> XENFEAT_hvm_pirqs is available, XENFEAT_hvm_callback_vector should also
> be available.
> In any case I'll submit a patch to Linux to make sure this doesn't
> happen, explicitly checking for xen_have_vector_callback.
> What is your Linux kernel version? Could you please post your kernel
> config as well?

Yes, you are right, this does not happen normally in a booting kernel.
What happens is that I needed to test my own PV drivers in all
possible scenarios,
 so I hacked the domU linux kernel to "believe" that XEN does not have
XENFEAT_hvm_callback_vector, basically I forced a

xen_have_vector_callback =3D 0;

in enlighten.c in domU kernel. This is probably why it triggered this
unusual situation.

I attach my kernel config (btw is actually a 3.0.6 kernel not 3.2.1)

I will try to apply your patch against XEN.

Thanks,
Paulian

>
>> In any case, cc'ing the author, Stefano. This ought to be easy to fix. W=
e
>> could make the irq_lock a recursive lock for example.
>
> We could also fail to map irqs into event channels if the delivery
> method is not HVMIRQ_callback_vector:
>
>
> diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> index df92cc7..7d89ed6 100644
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *ind=
ex, int *pirq_p,
>
> =A0 =A0 if ( domid =3D=3D DOMID_SELF && is_hvm_domain(d) )
> =A0 =A0 {
> + =A0 =A0 =A0 =A0if ( !is_hvm_pv_evtchn_domain(d) )
> + =A0 =A0 =A0 =A0{
> + =A0 =A0 =A0 =A0 =A0 =A0ret =3D -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0goto free_domain;
> + =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 ret =3D physdev_hvm_map_pirq(d, type, index, pirq_p);
> =A0 =A0 =A0 =A0 goto free_domain;
> =A0 =A0 }

--e89a8f23505b701ae504b7be9eb0
Content-Type: application/octet-stream; name=config
Content-Disposition: attachment; filename=config
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gy1iset50

IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24ndCBlZGl0CiMgTGlu
dXgveDg2XzY0IDMuMC42IEtlcm5lbCBDb25maWd1cmF0aW9uCiMKQ09ORklHXzY0QklUPXkKIyBD
T05GSUdfWDg2XzMyIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl82ND15CkNPTkZJR19YODY9eQpDT05G
SUdfSU5TVFJVQ1RJT05fREVDT0RFUj15CkNPTkZJR19PVVRQVVRfRk9STUFUPSJlbGY2NC14ODYt
NjQiCkNPTkZJR19BUkNIX0RFRkNPTkZJRz0iYXJjaC94ODYvY29uZmlncy94ODZfNjRfZGVmY29u
ZmlnIgpDT05GSUdfR0VORVJJQ19DTU9TX1VQREFURT15CkNPTkZJR19DTE9DS1NPVVJDRV9XQVRD
SERPRz15CkNPTkZJR19HRU5FUklDX0NMT0NLRVZFTlRTPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tF
VkVOVFNfQlJPQURDQVNUPXkKQ09ORklHX0xPQ0tERVBfU1VQUE9SVD15CkNPTkZJR19TVEFDS1RS
QUNFX1NVUFBPUlQ9eQpDT05GSUdfSEFWRV9MQVRFTkNZVE9QX1NVUFBPUlQ9eQpDT05GSUdfTU1V
PXkKQ09ORklHX1pPTkVfRE1BPXkKQ09ORklHX05FRURfRE1BX01BUF9TVEFURT15CkNPTkZJR19O
RUVEX1NHX0RNQV9MRU5HVEg9eQpDT05GSUdfR0VORVJJQ19JU0FfRE1BPXkKQ09ORklHX0dFTkVS
SUNfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19CVUc9eQpDT05GSUdfR0VORVJJQ19CVUdfUkVMQVRJ
VkVfUE9JTlRFUlM9eQpDT05GSUdfR0VORVJJQ19IV0VJR0hUPXkKQ09ORklHX0dFTkVSSUNfR1BJ
Tz15CkNPTkZJR19BUkNIX01BWV9IQVZFX1BDX0ZEQz15CiMgQ09ORklHX1JXU0VNX0dFTkVSSUNf
U1BJTkxPQ0sgaXMgbm90IHNldApDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklUSE09eQpDT05G
SUdfQVJDSF9IQVNfQ1BVX0lETEVfV0FJVD15CkNPTkZJR19HRU5FUklDX0NBTElCUkFURV9ERUxB
WT15CkNPTkZJR19HRU5FUklDX1RJTUVfVlNZU0NBTEw9eQpDT05GSUdfQVJDSF9IQVNfQ1BVX1JF
TEFYPXkKQ09ORklHX0FSQ0hfSEFTX0RFRkFVTFRfSURMRT15CkNPTkZJR19BUkNIX0hBU19DQUNI
RV9MSU5FX1NJWkU9eQpDT05GSUdfSEFWRV9TRVRVUF9QRVJfQ1BVX0FSRUE9eQpDT05GSUdfTkVF
RF9QRVJfQ1BVX0VNQkVEX0ZJUlNUX0NIVU5LPXkKQ09ORklHX05FRURfUEVSX0NQVV9QQUdFX0ZJ
UlNUX0NIVU5LPXkKQ09ORklHX0hBVkVfQ1BVTUFTS19PRl9DUFVfTUFQPXkKQ09ORklHX0FSQ0hf
SElCRVJOQVRJT05fUE9TU0lCTEU9eQpDT05GSUdfQVJDSF9TVVNQRU5EX1BPU1NJQkxFPXkKQ09O
RklHX1pPTkVfRE1BMzI9eQpDT05GSUdfQVJDSF9QT1BVTEFURVNfTk9ERV9NQVA9eQpDT05GSUdf
QVVESVRfQVJDSD15CkNPTkZJR19BUkNIX1NVUFBPUlRTX09QVElNSVpFRF9JTkxJTklORz15CkNP
TkZJR19BUkNIX1NVUFBPUlRTX0RFQlVHX1BBR0VBTExPQz15CkNPTkZJR19IQVZFX0lOVEVMX1RY
VD15CkNPTkZJR19YODZfNjRfU01QPXkKQ09ORklHX1g4Nl9IVD15CkNPTkZJR19BUkNIX0hXRUlH
SFRfQ0ZMQUdTPSItZmNhbGwtc2F2ZWQtcmRpIC1mY2FsbC1zYXZlZC1yc2kgLWZjYWxsLXNhdmVk
LXJkeCAtZmNhbGwtc2F2ZWQtcmN4IC1mY2FsbC1zYXZlZC1yOCAtZmNhbGwtc2F2ZWQtcjkgLWZj
YWxsLXNhdmVkLXIxMCAtZmNhbGwtc2F2ZWQtcjExIgojIENPTkZJR19LVElNRV9TQ0FMQVIgaXMg
bm90IHNldApDT05GSUdfQVJDSF9DUFVfUFJPQkVfUkVMRUFTRT15CkNPTkZJR19ERUZDT05GSUdf
TElTVD0iL2xpYi9tb2R1bGVzLyRVTkFNRV9SRUxFQVNFLy5jb25maWciCkNPTkZJR19IQVZFX0lS
UV9XT1JLPXkKQ09ORklHX0lSUV9XT1JLPXkKCiMKIyBHZW5lcmFsIHNldHVwCiMKQ09ORklHX0VY
UEVSSU1FTlRBTD15CkNPTkZJR19JTklUX0VOVl9BUkdfTElNSVQ9MzIKIyBDT05GSUdfSU5JVF9Q
QVNTX0FMTF9QQVJBTVMgaXMgbm90IHNldApDT05GSUdfQ1JPU1NfQ09NUElMRT0iIgpDT05GSUdf
TE9DQUxWRVJTSU9OPSIiCiMgQ09ORklHX0xPQ0FMVkVSU0lPTl9BVVRPIGlzIG5vdCBzZXQKQ09O
RklHX0hBVkVfS0VSTkVMX0daSVA9eQpDT05GSUdfSEFWRV9LRVJORUxfQlpJUDI9eQpDT05GSUdf
SEFWRV9LRVJORUxfTFpNQT15CkNPTkZJR19IQVZFX0tFUk5FTF9YWj15CkNPTkZJR19IQVZFX0tF
Uk5FTF9MWk89eQpDT05GSUdfS0VSTkVMX0daSVA9eQojIENPTkZJR19LRVJORUxfQlpJUDIgaXMg
bm90IHNldAojIENPTkZJR19LRVJORUxfTFpNQSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9Y
WiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFUk5FTF9MWk8gaXMgbm90IHNldApDT05GSUdfREVGQVVM
VF9IT1NUTkFNRT0iKG5vbmUpIgpDT05GSUdfVkVSU0lPTl9TSUdOQVRVUkU9IiIKQ09ORklHX1NX
QVA9eQpDT05GSUdfU1lTVklQQz15CkNPTkZJR19TWVNWSVBDX1NZU0NUTD15CkNPTkZJR19QT1NJ
WF9NUVVFVUU9eQpDT05GSUdfUE9TSVhfTVFVRVVFX1NZU0NUTD15CkNPTkZJR19CU0RfUFJPQ0VT
U19BQ0NUPXkKQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1RfVjM9eQojIENPTkZJR19GSEFORExFIGlz
IG5vdCBzZXQKQ09ORklHX1RBU0tTVEFUUz15CkNPTkZJR19UQVNLX0RFTEFZX0FDQ1Q9eQpDT05G
SUdfVEFTS19YQUNDVD15CkNPTkZJR19UQVNLX0lPX0FDQ09VTlRJTkc9eQpDT05GSUdfQVVESVQ9
eQpDT05GSUdfQVVESVRTWVNDQUxMPXkKQ09ORklHX0FVRElUX1dBVENIPXkKQ09ORklHX0FVRElU
X1RSRUU9eQpDT05GSUdfSEFWRV9HRU5FUklDX0hBUkRJUlFTPXkKCiMKIyBJUlEgc3Vic3lzdGVt
CiMKQ09ORklHX0dFTkVSSUNfSEFSRElSUVM9eQpDT05GSUdfSEFWRV9TUEFSU0VfSVJRPXkKQ09O
RklHX0dFTkVSSUNfSVJRX1BST0JFPXkKQ09ORklHX0dFTkVSSUNfSVJRX1NIT1c9eQpDT05GSUdf
R0VORVJJQ19QRU5ESU5HX0lSUT15CkNPTkZJR19JUlFfRk9SQ0VEX1RIUkVBRElORz15CkNPTkZJ
R19TUEFSU0VfSVJRPXkKCiMKIyBSQ1UgU3Vic3lzdGVtCiMKQ09ORklHX1RSRUVfUkNVPXkKIyBD
T05GSUdfUFJFRU1QVF9SQ1UgaXMgbm90IHNldAojIENPTkZJR19SQ1VfVFJBQ0UgaXMgbm90IHNl
dApDT05GSUdfUkNVX0ZBTk9VVD0zMgojIENPTkZJR19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBz
ZXQKIyBDT05GSUdfUkNVX0ZBU1RfTk9fSFogaXMgbm90IHNldAojIENPTkZJR19UUkVFX1JDVV9U
UkFDRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lLQ09ORklHIGlzIG5vdCBzZXQKQ09ORklHX0xPR19C
VUZfU0hJRlQ9MTcKQ09ORklHX0hBVkVfVU5TVEFCTEVfU0NIRURfQ0xPQ0s9eQpDT05GSUdfQ0dS
T1VQUz15CiMgQ09ORklHX0NHUk9VUF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19DR1JPVVBfRlJF
RVpFUj15CkNPTkZJR19DR1JPVVBfREVWSUNFPXkKQ09ORklHX0NQVVNFVFM9eQpDT05GSUdfUFJP
Q19QSURfQ1BVU0VUPXkKQ09ORklHX0NHUk9VUF9DUFVBQ0NUPXkKIyBDT05GSUdfUkVTT1VSQ0Vf
Q09VTlRFUlMgaXMgbm90IHNldAojIENPTkZJR19DR1JPVVBfUEVSRiBpcyBub3Qgc2V0CkNPTkZJ
R19DR1JPVVBfU0NIRUQ9eQpDT05GSUdfRkFJUl9HUk9VUF9TQ0hFRD15CiMgQ09ORklHX1JUX0dS
T1VQX1NDSEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NHUk9VUCBpcyBub3Qgc2V0CkNPTkZJ
R19OQU1FU1BBQ0VTPXkKQ09ORklHX1VUU19OUz15CkNPTkZJR19JUENfTlM9eQpDT05GSUdfVVNF
Ul9OUz15CkNPTkZJR19QSURfTlM9eQpDT05GSUdfTkVUX05TPXkKIyBDT05GSUdfU0NIRURfQVVU
T0dST1VQIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lTRlNfREVQUkVDQVRFRCBpcyBub3Qgc2V0CkNP
TkZJR19SRUxBWT15CkNPTkZJR19CTEtfREVWX0lOSVRSRD15CkNPTkZJR19JTklUUkFNRlNfU09V
UkNFPSIiCkNPTkZJR19SRF9HWklQPXkKIyBDT05GSUdfUkRfQlpJUDIgaXMgbm90IHNldAojIENP
TkZJR19SRF9MWk1BIGlzIG5vdCBzZXQKIyBDT05GSUdfUkRfWFogaXMgbm90IHNldAojIENPTkZJ
R19SRF9MWk8gaXMgbm90IHNldApDT05GSUdfQ0NfT1BUSU1JWkVfRk9SX1NJWkU9eQpDT05GSUdf
U1lTQ1RMPXkKQ09ORklHX0FOT05fSU5PREVTPXkKQ09ORklHX0VYUEVSVD15CkNPTkZJR19VSUQx
Nj15CkNPTkZJR19TWVNDVExfU1lTQ0FMTD15CkNPTkZJR19LQUxMU1lNUz15CiMgQ09ORklHX0tB
TExTWU1TX0FMTCBpcyBub3Qgc2V0CkNPTkZJR19IT1RQTFVHPXkKQ09ORklHX1BSSU5USz15CkNP
TkZJR19CVUc9eQpDT05GSUdfRUxGX0NPUkU9eQpDT05GSUdfUENTUEtSX1BMQVRGT1JNPXkKQ09O
RklHX0JBU0VfRlVMTD15CkNPTkZJR19GVVRFWD15CkNPTkZJR19FUE9MTD15CkNPTkZJR19TSUdO
QUxGRD15CkNPTkZJR19USU1FUkZEPXkKQ09ORklHX0VWRU5URkQ9eQpDT05GSUdfU0hNRU09eQpD
T05GSUdfQUlPPXkKIyBDT05GSUdfRU1CRURERUQgaXMgbm90IHNldApDT05GSUdfSEFWRV9QRVJG
X0VWRU5UUz15CgojCiMgS2VybmVsIFBlcmZvcm1hbmNlIEV2ZW50cyBBbmQgQ291bnRlcnMKIwpD
T05GSUdfUEVSRl9FVkVOVFM9eQojIENPTkZJR19QRVJGX0NPVU5URVJTIGlzIG5vdCBzZXQKIyBD
T05GSUdfREVCVUdfUEVSRl9VU0VfVk1BTExPQyBpcyBub3Qgc2V0CkNPTkZJR19WTV9FVkVOVF9D
T1VOVEVSUz15CkNPTkZJR19QQ0lfUVVJUktTPXkKQ09ORklHX1NMVUJfREVCVUc9eQojIENPTkZJ
R19DT01QQVRfQlJLIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xBQiBpcyBub3Qgc2V0CkNPTkZJR19T
TFVCPXkKIyBDT05GSUdfU0xPQiBpcyBub3Qgc2V0CkNPTkZJR19QUk9GSUxJTkc9eQpDT05GSUdf
VFJBQ0VQT0lOVFM9eQpDT05GSUdfT1BST0ZJTEU9bQojIENPTkZJR19PUFJPRklMRV9FVkVOVF9N
VUxUSVBMRVggaXMgbm90IHNldApDT05GSUdfSEFWRV9PUFJPRklMRT15CkNPTkZJR19LUFJPQkVT
PXkKIyBDT05GSUdfSlVNUF9MQUJFTCBpcyBub3Qgc2V0CkNPTkZJR19PUFRQUk9CRVM9eQpDT05G
SUdfSEFWRV9FRkZJQ0lFTlRfVU5BTElHTkVEX0FDQ0VTUz15CkNPTkZJR19LUkVUUFJPQkVTPXkK
Q09ORklHX0hBVkVfSU9SRU1BUF9QUk9UPXkKQ09ORklHX0hBVkVfS1BST0JFUz15CkNPTkZJR19I
QVZFX0tSRVRQUk9CRVM9eQpDT05GSUdfSEFWRV9PUFRQUk9CRVM9eQpDT05GSUdfSEFWRV9BUkNI
X1RSQUNFSE9PSz15CkNPTkZJR19IQVZFX0RNQV9BVFRSUz15CkNPTkZJR19VU0VfR0VORVJJQ19T
TVBfSEVMUEVSUz15CkNPTkZJR19IQVZFX1JFR1NfQU5EX1NUQUNLX0FDQ0VTU19BUEk9eQpDT05G
SUdfSEFWRV9ETUFfQVBJX0RFQlVHPXkKQ09ORklHX0hBVkVfSFdfQlJFQUtQT0lOVD15CkNPTkZJ
R19IQVZFX01JWEVEX0JSRUFLUE9JTlRTX1JFR1M9eQpDT05GSUdfSEFWRV9VU0VSX1JFVFVSTl9O
T1RJRklFUj15CkNPTkZJR19IQVZFX1BFUkZfRVZFTlRTX05NST15CkNPTkZJR19IQVZFX0FSQ0hf
SlVNUF9MQUJFTD15CgojCiMgR0NPVi1iYXNlZCBrZXJuZWwgcHJvZmlsaW5nCiMKIyBDT05GSUdf
R0NPVl9LRVJORUwgaXMgbm90IHNldAojIENPTkZJR19IQVZFX0dFTkVSSUNfRE1BX0NPSEVSRU5U
IGlzIG5vdCBzZXQKQ09ORklHX1NMQUJJTkZPPXkKQ09ORklHX1JUX01VVEVYRVM9eQpDT05GSUdf
QkFTRV9TTUFMTD0wCkNPTkZJR19NT0RVTEVTPXkKQ09ORklHX01PRFVMRV9GT1JDRV9MT0FEPXkK
Q09ORklHX01PRFVMRV9VTkxPQUQ9eQpDT05GSUdfTU9EVUxFX0ZPUkNFX1VOTE9BRD15CkNPTkZJ
R19NT0RWRVJTSU9OUz15CiMgQ09ORklHX01PRFVMRV9TUkNWRVJTSU9OX0FMTCBpcyBub3Qgc2V0
CkNPTkZJR19TVE9QX01BQ0hJTkU9eQpDT05GSUdfQkxPQ0s9eQpDT05GSUdfQkxLX0RFVl9CU0c9
eQpDT05GSUdfQkxLX0RFVl9JTlRFR1JJVFk9eQpDT05GSUdfQkxPQ0tfQ09NUEFUPXkKCiMKIyBJ
TyBTY2hlZHVsZXJzCiMKQ09ORklHX0lPU0NIRURfTk9PUD15CkNPTkZJR19JT1NDSEVEX0RFQURM
SU5FPXkKQ09ORklHX0lPU0NIRURfQ0ZRPXkKIyBDT05GSUdfREVGQVVMVF9ERUFETElORSBpcyBu
b3Qgc2V0CkNPTkZJR19ERUZBVUxUX0NGUT15CiMgQ09ORklHX0RFRkFVTFRfTk9PUCBpcyBub3Qg
c2V0CkNPTkZJR19ERUZBVUxUX0lPU0NIRUQ9ImNmcSIKIyBDT05GSUdfSU5MSU5FX1NQSU5fVFJZ
TE9DSyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX1RSWUxPQ0tfQkggaXMgbm90IHNl
dAojIENPTkZJR19JTkxJTkVfU1BJTl9MT0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQ
SU5fTE9DS19CSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9TUElOX0xPQ0tfSVJRIGlzIG5v
dCBzZXQKIyBDT05GSUdfSU5MSU5FX1NQSU5fTE9DS19JUlFTQVZFIGlzIG5vdCBzZXQKQ09ORklH
X0lOTElORV9TUElOX1VOTE9DSz15CiMgQ09ORklHX0lOTElORV9TUElOX1VOTE9DS19CSCBpcyBu
b3Qgc2V0CkNPTkZJR19JTkxJTkVfU1BJTl9VTkxPQ0tfSVJRPXkKIyBDT05GSUdfSU5MSU5FX1NQ
SU5fVU5MT0NLX0lSUVJFU1RPUkUgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfUkVBRF9UUllM
T0NLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1JFQURfTE9DSyBpcyBub3Qgc2V0CiMgQ09O
RklHX0lOTElORV9SRUFEX0xPQ0tfQkggaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfUkVBRF9M
T0NLX0lSUSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9SRUFEX0xPQ0tfSVJRU0FWRSBpcyBu
b3Qgc2V0CkNPTkZJR19JTkxJTkVfUkVBRF9VTkxPQ0s9eQojIENPTkZJR19JTkxJTkVfUkVBRF9V
TkxPQ0tfQkggaXMgbm90IHNldApDT05GSUdfSU5MSU5FX1JFQURfVU5MT0NLX0lSUT15CiMgQ09O
RklHX0lOTElORV9SRUFEX1VOTE9DS19JUlFSRVNUT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5M
SU5FX1dSSVRFX1RSWUxPQ0sgaXMgbm90IHNldAojIENPTkZJR19JTkxJTkVfV1JJVEVfTE9DSyBp
cyBub3Qgc2V0CiMgQ09ORklHX0lOTElORV9XUklURV9MT0NLX0JIIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5MSU5FX1dSSVRFX0xPQ0tfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5MSU5FX1dSSVRF
X0xPQ0tfSVJRU0FWRSBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfV1JJVEVfVU5MT0NLPXkKIyBD
T05GSUdfSU5MSU5FX1dSSVRFX1VOTE9DS19CSCBpcyBub3Qgc2V0CkNPTkZJR19JTkxJTkVfV1JJ
VEVfVU5MT0NLX0lSUT15CiMgQ09ORklHX0lOTElORV9XUklURV9VTkxPQ0tfSVJRUkVTVE9SRSBp
cyBub3Qgc2V0CkNPTkZJR19NVVRFWF9TUElOX09OX09XTkVSPXkKQ09ORklHX0ZSRUVaRVI9eQoK
IwojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcwojCkNPTkZJR19USUNLX09ORVNIT1Q9eQpD
T05GSUdfTk9fSFo9eQpDT05GSUdfSElHSF9SRVNfVElNRVJTPXkKQ09ORklHX0dFTkVSSUNfQ0xP
Q0tFVkVOVFNfQlVJTEQ9eQpDT05GSUdfU01QPXkKQ09ORklHX1g4Nl9NUFBBUlNFPXkKIyBDT05G
SUdfWDg2X0VYVEVOREVEX1BMQVRGT1JNIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9TVVBQT1JUU19N
RU1PUllfRkFJTFVSRT15CkNPTkZJR19TQ0hFRF9PTUlUX0ZSQU1FX1BPSU5URVI9eQpDT05GSUdf
UEFSQVZJUlRfR1VFU1Q9eQpDT05GSUdfWEVOPXkKQ09ORklHX1hFTl9ET00wPXkKQ09ORklHX1hF
Tl9QUklWSUxFR0VEX0dVRVNUPXkKQ09ORklHX1hFTl9QVkhWTT15CkNPTkZJR19YRU5fTUFYX0RP
TUFJTl9NRU1PUlk9MTI4CkNPTkZJR19YRU5fU0FWRV9SRVNUT1JFPXkKQ09ORklHX1hFTl9ERUJV
R19GUz15CkNPTkZJR19YRU5fREVCVUc9eQojIENPTkZJR19LVk1fQ0xPQ0sgaXMgbm90IHNldAoj
IENPTkZJR19LVk1fR1VFU1QgaXMgbm90IHNldApDT05GSUdfUEFSQVZJUlQ9eQojIENPTkZJR19Q
QVJBVklSVF9TUElOTE9DS1MgaXMgbm90IHNldApDT05GSUdfUEFSQVZJUlRfQ0xPQ0s9eQojIENP
TkZJR19QQVJBVklSVF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19OT19CT09UTUVNPXkKIyBDT05G
SUdfTUVNVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX01LOCBpcyBub3Qgc2V0CiMgQ09ORklHX01Q
U0MgaXMgbm90IHNldAojIENPTkZJR19NQ09SRTIgaXMgbm90IHNldAojIENPTkZJR19NQVRPTSBp
cyBub3Qgc2V0CkNPTkZJR19HRU5FUklDX0NQVT15CkNPTkZJR19YODZfSU5URVJOT0RFX0NBQ0hF
X1NISUZUPTYKQ09ORklHX1g4Nl9DTVBYQ0hHPXkKQ09ORklHX0NNUFhDSEdfTE9DQUw9eQpDT05G
SUdfWDg2X0wxX0NBQ0hFX1NISUZUPTYKQ09ORklHX1g4Nl9YQUREPXkKQ09ORklHX1g4Nl9XUF9X
T1JLU19PSz15CkNPTkZJR19YODZfVFNDPXkKQ09ORklHX1g4Nl9DTVBYQ0hHNjQ9eQpDT05GSUdf
WDg2X0NNT1Y9eQpDT05GSUdfWDg2X01JTklNVU1fQ1BVX0ZBTUlMWT02NApDT05GSUdfWDg2X0RF
QlVHQ1RMTVNSPXkKIyBDT05GSUdfUFJPQ0VTU09SX1NFTEVDVCBpcyBub3Qgc2V0CkNPTkZJR19D
UFVfU1VQX0lOVEVMPXkKQ09ORklHX0NQVV9TVVBfQU1EPXkKQ09ORklHX0NQVV9TVVBfQ0VOVEFV
Uj15CkNPTkZJR19IUEVUX1RJTUVSPXkKQ09ORklHX0RNST15CkNPTkZJR19HQVJUX0lPTU1VPXkK
IyBDT05GSUdfQ0FMR0FSWV9JT01NVSBpcyBub3Qgc2V0CiMgQ09ORklHX0FNRF9JT01NVSBpcyBu
b3Qgc2V0CkNPTkZJR19TV0lPVExCPXkKQ09ORklHX0lPTU1VX0hFTFBFUj15CkNPTkZJR19JT01N
VV9BUEk9eQojIENPTkZJR19NQVhTTVAgaXMgbm90IHNldApDT05GSUdfTlJfQ1BVUz04CkNPTkZJ
R19TQ0hFRF9TTVQ9eQpDT05GSUdfU0NIRURfTUM9eQojIENPTkZJR19JUlFfVElNRV9BQ0NPVU5U
SU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJFRU1QVF9OT05FIGlzIG5vdCBzZXQKQ09ORklHX1BS
RUVNUFRfVk9MVU5UQVJZPXkKIyBDT05GSUdfUFJFRU1QVCBpcyBub3Qgc2V0CkNPTkZJR19YODZf
TE9DQUxfQVBJQz15CkNPTkZJR19YODZfSU9fQVBJQz15CkNPTkZJR19YODZfUkVST1VURV9GT1Jf
QlJPS0VOX0JPT1RfSVJRUz15CkNPTkZJR19YODZfTUNFPXkKQ09ORklHX1g4Nl9NQ0VfSU5URUw9
eQojIENPTkZJR19YODZfTUNFX1hFT043NVhYIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X01DRV9B
TUQgaXMgbm90IHNldApDT05GSUdfWDg2X01DRV9USFJFU0hPTEQ9eQojIENPTkZJR19YODZfTUNF
X0lOSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19YODZfVEhFUk1BTF9WRUNUT1I9eQojIENPTkZJR19J
OEsgaXMgbm90IHNldAojIENPTkZJR19NSUNST0NPREUgaXMgbm90IHNldAojIENPTkZJR19YODZf
TVNSIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X0NQVUlEIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hf
UEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfQVJDSF9ETUFfQUREUl9UXzY0QklUPXkKQ09ORklH
X0RJUkVDVF9HQlBBR0VTPXkKIyBDT05GSUdfTlVNQSBpcyBub3Qgc2V0CkNPTkZJR19BUkNIX1NQ
QVJTRU1FTV9FTkFCTEU9eQpDT05GSUdfQVJDSF9TUEFSU0VNRU1fREVGQVVMVD15CkNPTkZJR19B
UkNIX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdfQVJDSF9NRU1PUllfUFJPQkU9eQpDT05G
SUdfQVJDSF9QUk9DX0tDT1JFX1RFWFQ9eQpDT05GSUdfSUxMRUdBTF9QT0lOVEVSX1ZBTFVFPTB4
ZGVhZDAwMDAwMDAwMDAwMApDT05GSUdfU0VMRUNUX01FTU9SWV9NT0RFTD15CkNPTkZJR19TUEFS
U0VNRU1fTUFOVUFMPXkKQ09ORklHX1NQQVJTRU1FTT15CkNPTkZJR19IQVZFX01FTU9SWV9QUkVT
RU5UPXkKQ09ORklHX1NQQVJTRU1FTV9FWFRSRU1FPXkKQ09ORklHX1NQQVJTRU1FTV9WTUVNTUFQ
X0VOQUJMRT15CkNPTkZJR19TUEFSU0VNRU1fQUxMT0NfTUVNX01BUF9UT0dFVEhFUj15CkNPTkZJ
R19TUEFSU0VNRU1fVk1FTU1BUD15CkNPTkZJR19IQVZFX01FTUJMT0NLPXkKQ09ORklHX01FTU9S
WV9IT1RQTFVHPXkKQ09ORklHX01FTU9SWV9IT1RQTFVHX1NQQVJTRT15CkNPTkZJR19NRU1PUllf
SE9UUkVNT1ZFPXkKQ09ORklHX1BBR0VGTEFHU19FWFRFTkRFRD15CkNPTkZJR19TUExJVF9QVExP
Q0tfQ1BVUz00CiMgQ09ORklHX0NPTVBBQ1RJT04gaXMgbm90IHNldApDT05GSUdfTUlHUkFUSU9O
PXkKQ09ORklHX1BIWVNfQUREUl9UXzY0QklUPXkKQ09ORklHX1pPTkVfRE1BX0ZMQUc9MQpDT05G
SUdfQk9VTkNFPXkKQ09ORklHX1ZJUlRfVE9fQlVTPXkKQ09ORklHX01NVV9OT1RJRklFUj15CkNP
TkZJR19LU009eQpDT05GSUdfREVGQVVMVF9NTUFQX01JTl9BRERSPTY1NTM2CkNPTkZJR19BUkNI
X1NVUFBPUlRTX01FTU9SWV9GQUlMVVJFPXkKIyBDT05GSUdfTUVNT1JZX0ZBSUxVUkUgaXMgbm90
IHNldAojIENPTkZJR19UUkFOU1BBUkVOVF9IVUdFUEFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NM
RUFOQ0FDSEUgaXMgbm90IHNldAojIENPTkZJR19YODZfQ0hFQ0tfQklPU19DT1JSVVBUSU9OIGlz
IG5vdCBzZXQKQ09ORklHX1g4Nl9SRVNFUlZFX0xPVz02NApDT05GSUdfTVRSUj15CkNPTkZJR19N
VFJSX1NBTklUSVpFUj15CkNPTkZJR19NVFJSX1NBTklUSVpFUl9FTkFCTEVfREVGQVVMVD0wCkNP
TkZJR19NVFJSX1NBTklUSVpFUl9TUEFSRV9SRUdfTlJfREVGQVVMVD0xCkNPTkZJR19YODZfUEFU
PXkKQ09ORklHX0FSQ0hfVVNFU19QR19VTkNBQ0hFRD15CkNPTkZJR19FRkk9eQpDT05GSUdfU0VD
Q09NUD15CkNPTkZJR19DQ19TVEFDS1BST1RFQ1RPUj15CiMgQ09ORklHX0haXzEwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX0haXzI1MCBpcyBub3Qgc2V0CkNPTkZJR19IWl8zMDA9eQojIENPTkZJR19I
Wl8xMDAwIGlzIG5vdCBzZXQKQ09ORklHX0haPTMwMApDT05GSUdfU0NIRURfSFJUSUNLPXkKQ09O
RklHX0tFWEVDPXkKIyBDT05GSUdfQ1JBU0hfRFVNUCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWEVD
X0pVTVAgaXMgbm90IHNldApDT05GSUdfUEhZU0lDQUxfU1RBUlQ9MHgxMDAwMDAwCkNPTkZJR19S
RUxPQ0FUQUJMRT15CkNPTkZJR19QSFlTSUNBTF9BTElHTj0weDEwMDAwMDAKQ09ORklHX0hPVFBM
VUdfQ1BVPXkKQ09ORklHX0NPTVBBVF9WRFNPPXkKIyBDT05GSUdfQ01ETElORV9CT09MIGlzIG5v
dCBzZXQKQ09ORklHX0FSQ0hfRU5BQkxFX01FTU9SWV9IT1RQTFVHPXkKQ09ORklHX0FSQ0hfRU5B
QkxFX01FTU9SWV9IT1RSRU1PVkU9eQoKIwojIFBvd2VyIG1hbmFnZW1lbnQgYW5kIEFDUEkgb3B0
aW9ucwojCkNPTkZJR19BUkNIX0hJQkVSTkFUSU9OX0hFQURFUj15CkNPTkZJR19TVVNQRU5EPXkK
Q09ORklHX1NVU1BFTkRfRlJFRVpFUj15CkNPTkZJR19ISUJFUk5BVEVfQ0FMTEJBQ0tTPXkKQ09O
RklHX0hJQkVSTkFUSU9OPXkKQ09ORklHX1BNX1NURF9QQVJUSVRJT049IiIKQ09ORklHX1BNX1NM
RUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CkNPTkZJR19QTV9SVU5USU1FPXkKQ09ORklHX1BN
PXkKQ09ORklHX1BNX0RFQlVHPXkKIyBDT05GSUdfUE1fQURWQU5DRURfREVCVUcgaXMgbm90IHNl
dAojIENPTkZJR19QTV9URVNUX1NVU1BFTkQgaXMgbm90IHNldApDT05GSUdfQ0FOX1BNX1RSQUNF
PXkKIyBDT05GSUdfUE1fVFJBQ0VfUlRDIGlzIG5vdCBzZXQKQ09ORklHX0FDUEk9eQpDT05GSUdf
QUNQSV9TTEVFUD15CkNPTkZJR19BQ1BJX1BST0NGUz15CiMgQ09ORklHX0FDUElfUFJPQ0ZTX1BP
V0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNQSV9FQ19ERUJVR0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfQUNQSV9QUk9DX0VWRU5UIGlzIG5vdCBzZXQKQ09ORklHX0FDUElfQUM9bQpDT05GSUdfQUNQ
SV9CQVRURVJZPW0KQ09ORklHX0FDUElfQlVUVE9OPW0KQ09ORklHX0FDUElfVklERU89bQpDT05G
SUdfQUNQSV9GQU49bQpDT05GSUdfQUNQSV9ET0NLPXkKQ09ORklHX0FDUElfUFJPQ0VTU09SPW0K
Q09ORklHX0FDUElfSE9UUExVR19DUFU9eQpDT05GSUdfQUNQSV9QUk9DRVNTT1JfQUdHUkVHQVRP
Uj1tCkNPTkZJR19BQ1BJX1RIRVJNQUw9bQojIENPTkZJR19BQ1BJX0NVU1RPTV9EU0RUIGlzIG5v
dCBzZXQKQ09ORklHX0FDUElfQkxBQ0tMSVNUX1lFQVI9MAojIENPTkZJR19BQ1BJX0RFQlVHIGlz
IG5vdCBzZXQKQ09ORklHX0FDUElfUENJX1NMT1Q9bQpDT05GSUdfWDg2X1BNX1RJTUVSPXkKQ09O
RklHX0FDUElfQ09OVEFJTkVSPW0KQ09ORklHX0FDUElfSE9UUExVR19NRU1PUlk9bQpDT05GSUdf
QUNQSV9TQlM9bQojIENPTkZJR19BQ1BJX0hFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfQ1VT
VE9NX01FVEhPRCBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfQVBFSSBpcyBub3Qgc2V0CkNPTkZJ
R19TRkk9eQoKIwojIENQVSBGcmVxdWVuY3kgc2NhbGluZwojCkNPTkZJR19DUFVfRlJFUT15CkNP
TkZJR19DUFVfRlJFUV9UQUJMRT15CkNPTkZJR19DUFVfRlJFUV9TVEFUPW0KIyBDT05GSUdfQ1BV
X0ZSRVFfU1RBVF9ERVRBSUxTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9H
T1ZfUEVSRk9STUFOQ0UgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9Q
T1dFUlNBVkUgaXMgbm90IHNldAojIENPTkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9VU0VSU1BB
Q0UgaXMgbm90IHNldApDT05GSUdfQ1BVX0ZSRVFfREVGQVVMVF9HT1ZfT05ERU1BTkQ9eQojIENP
TkZJR19DUFVfRlJFUV9ERUZBVUxUX0dPVl9DT05TRVJWQVRJVkUgaXMgbm90IHNldApDT05GSUdf
Q1BVX0ZSRVFfR09WX1BFUkZPUk1BTkNFPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9QT1dFUlNBVkU9
bQpDT05GSUdfQ1BVX0ZSRVFfR09WX1VTRVJTUEFDRT1tCkNPTkZJR19DUFVfRlJFUV9HT1ZfT05E
RU1BTkQ9eQpDT05GSUdfQ1BVX0ZSRVFfR09WX0NPTlNFUlZBVElWRT1tCgojCiMgeDg2IENQVSBm
cmVxdWVuY3kgc2NhbGluZyBkcml2ZXJzCiMKIyBDT05GSUdfWDg2X1BDQ19DUFVGUkVRIGlzIG5v
dCBzZXQKQ09ORklHX1g4Nl9BQ1BJX0NQVUZSRVE9bQpDT05GSUdfWDg2X1BPV0VSTk9XX0s4PW0K
Q09ORklHX1g4Nl9TUEVFRFNURVBfQ0VOVFJJTk89bQojIENPTkZJR19YODZfUDRfQ0xPQ0tNT0Qg
aXMgbm90IHNldAoKIwojIHNoYXJlZCBvcHRpb25zCiMKIyBDT05GSUdfWDg2X1NQRUVEU1RFUF9M
SUIgaXMgbm90IHNldApDT05GSUdfQ1BVX0lETEU9eQpDT05GSUdfQ1BVX0lETEVfR09WX0xBRERF
Uj15CkNPTkZJR19DUFVfSURMRV9HT1ZfTUVOVT15CiMgQ09ORklHX0lOVEVMX0lETEUgaXMgbm90
IHNldAoKIwojIE1lbW9yeSBwb3dlciBzYXZpbmdzCiMKIyBDT05GSUdfSTczMDBfSURMRSBpcyBu
b3Qgc2V0CgojCiMgQnVzIG9wdGlvbnMgKFBDSSBldGMuKQojCkNPTkZJR19QQ0k9eQpDT05GSUdf
UENJX0RJUkVDVD15CkNPTkZJR19QQ0lfTU1DT05GSUc9eQpDT05GSUdfUENJX1hFTj15CkNPTkZJ
R19QQ0lfRE9NQUlOUz15CiMgQ09ORklHX1BDSV9DTkIyMExFX1FVSVJLIGlzIG5vdCBzZXQKQ09O
RklHX0RNQVI9eQojIENPTkZJR19ETUFSX0RFRkFVTFRfT04gaXMgbm90IHNldApDT05GSUdfRE1B
Ul9GTE9QUFlfV0E9eQojIENPTkZJR19JTlRSX1JFTUFQIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVQ
T1JUQlVTPXkKQ09ORklHX1BDSUVBRVI9eQojIENPTkZJR19QQ0lFX0VDUkMgaXMgbm90IHNldAoj
IENPTkZJR19QQ0lFQUVSX0lOSkVDVCBpcyBub3Qgc2V0CkNPTkZJR19QQ0lFQVNQTT15CiMgQ09O
RklHX1BDSUVBU1BNX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1BDSUVfUE1FPXkKQ09ORklHX0FS
Q0hfU1VQUE9SVFNfTVNJPXkKQ09ORklHX1BDSV9NU0k9eQojIENPTkZJR19QQ0lfREVCVUcgaXMg
bm90IHNldAojIENPTkZJR19QQ0lfU1RVQiBpcyBub3Qgc2V0CkNPTkZJR19YRU5fUENJREVWX0ZS
T05URU5EPW0KQ09ORklHX0hUX0lSUT15CkNPTkZJR19QQ0lfSU9WPXkKQ09ORklHX1BDSV9JT0FQ
SUM9eQpDT05GSUdfUENJX0xBQkVMPXkKQ09ORklHX0lTQV9ETUFfQVBJPXkKQ09ORklHX0FNRF9O
Qj15CiMgQ09ORklHX1BDQ0FSRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hPVFBMVUdfUENJIGlzIG5v
dCBzZXQKIyBDT05GSUdfUkFQSURJTyBpcyBub3Qgc2V0CgojCiMgRXhlY3V0YWJsZSBmaWxlIGZv
cm1hdHMgLyBFbXVsYXRpb25zCiMKQ09ORklHX0JJTkZNVF9FTEY9eQpDT05GSUdfQ09NUEFUX0JJ
TkZNVF9FTEY9eQpDT05GSUdfQ09SRV9EVU1QX0RFRkFVTFRfRUxGX0hFQURFUlM9eQojIENPTkZJ
R19IQVZFX0FPVVQgaXMgbm90IHNldApDT05GSUdfQklORk1UX01JU0M9bQpDT05GSUdfSUEzMl9F
TVVMQVRJT049eQojIENPTkZJR19JQTMyX0FPVVQgaXMgbm90IHNldApDT05GSUdfQ09NUEFUPXkK
Q09ORklHX0NPTVBBVF9GT1JfVTY0X0FMSUdOTUVOVD15CkNPTkZJR19TWVNWSVBDX0NPTVBBVD15
CkNPTkZJR19IQVZFX1RFWFRfUE9LRV9TTVA9eQpDT05GSUdfTkVUPXkKCiMKIyBOZXR3b3JraW5n
IG9wdGlvbnMKIwpDT05GSUdfUEFDS0VUPXkKQ09ORklHX1VOSVg9eQpDT05GSUdfWEZSTT15CiMg
Q09ORklHX1hGUk1fVVNFUiBpcyBub3Qgc2V0CkNPTkZJR19YRlJNX1NVQl9QT0xJQ1k9eQpDT05G
SUdfWEZSTV9NSUdSQVRFPXkKIyBDT05GSUdfWEZSTV9TVEFUSVNUSUNTIGlzIG5vdCBzZXQKQ09O
RklHX1hGUk1fSVBDT01QPW0KIyBDT05GSUdfTkVUX0tFWSBpcyBub3Qgc2V0CkNPTkZJR19JTkVU
PXkKQ09ORklHX0lQX01VTFRJQ0FTVD15CkNPTkZJR19JUF9BRFZBTkNFRF9ST1VURVI9eQojIENP
TkZJR19JUF9GSUJfVFJJRV9TVEFUUyBpcyBub3Qgc2V0CkNPTkZJR19JUF9NVUxUSVBMRV9UQUJM
RVM9eQpDT05GSUdfSVBfUk9VVEVfTVVMVElQQVRIPXkKQ09ORklHX0lQX1JPVVRFX1ZFUkJPU0U9
eQpDT05GSUdfSVBfUk9VVEVfQ0xBU1NJRD15CiMgQ09ORklHX0lQX1BOUCBpcyBub3Qgc2V0CiMg
Q09ORklHX05FVF9JUElQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0lQR1JFX0RFTVVYIGlzIG5v
dCBzZXQKQ09ORklHX0lQX01ST1VURT15CiMgQ09ORklHX0lQX01ST1VURV9NVUxUSVBMRV9UQUJM
RVMgaXMgbm90IHNldApDT05GSUdfSVBfUElNU01fVjE9eQpDT05GSUdfSVBfUElNU01fVjI9eQoj
IENPTkZJR19BUlBEIGlzIG5vdCBzZXQKQ09ORklHX1NZTl9DT09LSUVTPXkKIyBDT05GSUdfSU5F
VF9BSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfRVNQIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5F
VF9JUENPTVAgaXMgbm90IHNldAojIENPTkZJR19JTkVUX1hGUk1fVFVOTkVMIGlzIG5vdCBzZXQK
Q09ORklHX0lORVRfVFVOTkVMPW0KIyBDT05GSUdfSU5FVF9YRlJNX01PREVfVFJBTlNQT1JUIGlz
IG5vdCBzZXQKIyBDT05GSUdfSU5FVF9YRlJNX01PREVfVFVOTkVMIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU5FVF9YRlJNX01PREVfQkVFVCBpcyBub3Qgc2V0CkNPTkZJR19JTkVUX0xSTz1tCiMgQ09O
RklHX0lORVRfRElBRyBpcyBub3Qgc2V0CkNPTkZJR19UQ1BfQ09OR19BRFZBTkNFRD15CkNPTkZJ
R19UQ1BfQ09OR19CSUM9bQpDT05GSUdfVENQX0NPTkdfQ1VCSUM9eQpDT05GSUdfVENQX0NPTkdf
V0VTVFdPT0Q9bQpDT05GSUdfVENQX0NPTkdfSFRDUD1tCkNPTkZJR19UQ1BfQ09OR19IU1RDUD1t
CkNPTkZJR19UQ1BfQ09OR19IWUJMQT1tCkNPTkZJR19UQ1BfQ09OR19WRUdBUz1tCkNPTkZJR19U
Q1BfQ09OR19TQ0FMQUJMRT1tCkNPTkZJR19UQ1BfQ09OR19MUD1tCkNPTkZJR19UQ1BfQ09OR19W
RU5PPW0KQ09ORklHX1RDUF9DT05HX1lFQUg9bQpDT05GSUdfVENQX0NPTkdfSUxMSU5PSVM9bQpD
T05GSUdfREVGQVVMVF9DVUJJQz15CiMgQ09ORklHX0RFRkFVTFRfUkVOTyBpcyBub3Qgc2V0CkNP
TkZJR19ERUZBVUxUX1RDUF9DT05HPSJjdWJpYyIKQ09ORklHX1RDUF9NRDVTSUc9eQpDT05GSUdf
SVBWNj15CkNPTkZJR19JUFY2X1BSSVZBQ1k9eQpDT05GSUdfSVBWNl9ST1VURVJfUFJFRj15CkNP
TkZJR19JUFY2X1JPVVRFX0lORk89eQpDT05GSUdfSVBWNl9PUFRJTUlTVElDX0RBRD15CkNPTkZJ
R19JTkVUNl9BSD1tCkNPTkZJR19JTkVUNl9FU1A9bQpDT05GSUdfSU5FVDZfSVBDT01QPW0KQ09O
RklHX0lQVjZfTUlQNj15CkNPTkZJR19JTkVUNl9YRlJNX1RVTk5FTD1tCkNPTkZJR19JTkVUNl9U
VU5ORUw9bQpDT05GSUdfSU5FVDZfWEZSTV9NT0RFX1RSQU5TUE9SVD1tCkNPTkZJR19JTkVUNl9Y
RlJNX01PREVfVFVOTkVMPW0KQ09ORklHX0lORVQ2X1hGUk1fTU9ERV9CRUVUPW0KQ09ORklHX0lO
RVQ2X1hGUk1fTU9ERV9ST1VURU9QVElNSVpBVElPTj1tCkNPTkZJR19JUFY2X1NJVD1tCiMgQ09O
RklHX0lQVjZfU0lUXzZSRCBpcyBub3Qgc2V0CkNPTkZJR19JUFY2X05ESVNDX05PREVUWVBFPXkK
Q09ORklHX0lQVjZfVFVOTkVMPW0KQ09ORklHX0lQVjZfTVVMVElQTEVfVEFCTEVTPXkKQ09ORklH
X0lQVjZfU1VCVFJFRVM9eQpDT05GSUdfSVBWNl9NUk9VVEU9eQojIENPTkZJR19JUFY2X01ST1VU
RV9NVUxUSVBMRV9UQUJMRVMgaXMgbm90IHNldApDT05GSUdfSVBWNl9QSU1TTV9WMj15CkNPTkZJ
R19ORVRXT1JLX1NFQ01BUks9eQojIENPTkZJR19ORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgaXMg
bm90IHNldApDT05GSUdfTkVURklMVEVSPXkKIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5v
dCBzZXQKQ09ORklHX05FVEZJTFRFUl9BRFZBTkNFRD15CgojCiMgQ29yZSBOZXRmaWx0ZXIgQ29u
ZmlndXJhdGlvbgojCkNPTkZJR19ORVRGSUxURVJfTkVUTElOSz1tCkNPTkZJR19ORVRGSUxURVJf
TkVUTElOS19RVUVVRT1tCkNPTkZJR19ORVRGSUxURVJfTkVUTElOS19MT0c9bQpDT05GSUdfTkZf
Q09OTlRSQUNLPW0KQ09ORklHX05GX0NPTk5UUkFDS19NQVJLPXkKQ09ORklHX05GX0NPTk5UUkFD
S19TRUNNQVJLPXkKQ09ORklHX05GX0NPTk5UUkFDS19FVkVOVFM9eQojIENPTkZJR19ORl9DT05O
VFJBQ0tfVElNRVNUQU1QIGlzIG5vdCBzZXQKQ09ORklHX05GX0NUX1BST1RPX0RDQ1A9bQpDT05G
SUdfTkZfQ1RfUFJPVE9fR1JFPW0KQ09ORklHX05GX0NUX1BST1RPX1NDVFA9bQpDT05GSUdfTkZf
Q1RfUFJPVE9fVURQTElURT1tCkNPTkZJR19ORl9DT05OVFJBQ0tfQU1BTkRBPW0KQ09ORklHX05G
X0NPTk5UUkFDS19GVFA9bQpDT05GSUdfTkZfQ09OTlRSQUNLX0gzMjM9bQpDT05GSUdfTkZfQ09O
TlRSQUNLX0lSQz1tCkNPTkZJR19ORl9DT05OVFJBQ0tfQlJPQURDQVNUPW0KQ09ORklHX05GX0NP
Tk5UUkFDS19ORVRCSU9TX05TPW0KIyBDT05GSUdfTkZfQ09OTlRSQUNLX1NOTVAgaXMgbm90IHNl
dApDT05GSUdfTkZfQ09OTlRSQUNLX1BQVFA9bQpDT05GSUdfTkZfQ09OTlRSQUNLX1NBTkU9bQpD
T05GSUdfTkZfQ09OTlRSQUNLX1NJUD1tCkNPTkZJR19ORl9DT05OVFJBQ0tfVEZUUD1tCkNPTkZJ
R19ORl9DVF9ORVRMSU5LPW0KQ09ORklHX05FVEZJTFRFUl9UUFJPWFk9bQpDT05GSUdfTkVURklM
VEVSX1hUQUJMRVM9bQoKIwojIFh0YWJsZXMgY29tYmluZWQgbW9kdWxlcwojCkNPTkZJR19ORVRG
SUxURVJfWFRfTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfQ09OTk1BUks9bQoKIwojIFh0YWJs
ZXMgdGFyZ2V0cwojCiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfQVVESVQgaXMgbm90IHNl
dAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NIRUNLU1VNIGlzIG5vdCBzZXQKQ09ORklH
X05FVEZJTFRFUl9YVF9UQVJHRVRfQ0xBU1NJRlk9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdF
VF9DT05OTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NPTk5TRUNNQVJLPW0KIyBD
T05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9DVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRGSUxURVJf
WFRfVEFSR0VUX0RTQ1A9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9ITD1tCiMgQ09ORklH
X05FVEZJTFRFUl9YVF9UQVJHRVRfSURMRVRJTUVSIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRF
Ul9YVF9UQVJHRVRfTEVEPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRfTUFSSz1tCkNPTkZJ
R19ORVRGSUxURVJfWFRfVEFSR0VUX05GTE9HPW0KQ09ORklHX05FVEZJTFRFUl9YVF9UQVJHRVRf
TkZRVUVVRT1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05PVFJBQ0s9bQpDT05GSUdfTkVU
RklMVEVSX1hUX1RBUkdFVF9SQVRFRVNUPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9U
RUUgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UUFJPWFk9bQpDT05GSUdf
TkVURklMVEVSX1hUX1RBUkdFVF9UUkFDRT1tCkNPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1NF
Q01BUks9bQpDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9UQ1BNU1M9bQpDT05GSUdfTkVURklM
VEVSX1hUX1RBUkdFVF9UQ1BPUFRTVFJJUD1tCgojCiMgWHRhYmxlcyBtYXRjaGVzCiMKIyBDT05G
SUdfTkVURklMVEVSX1hUX01BVENIX0FERFJUWVBFIGlzIG5vdCBzZXQKQ09ORklHX05FVEZJTFRF
Ul9YVF9NQVRDSF9DTFVTVEVSPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT01NRU5UPW0K
Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT05OQllURVM9bQpDT05GSUdfTkVURklMVEVSX1hU
X01BVENIX0NPTk5MSU1JVD1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ09OTk1BUks9bQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5UUkFDSz1tCiMgQ09ORklHX05FVEZJTFRFUl9Y
VF9NQVRDSF9DUFUgaXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0RDQ1A9bQoj
IENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfREVWR1JPVVAgaXMgbm90IHNldApDT05GSUdfTkVU
RklMVEVSX1hUX01BVENIX0RTQ1A9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0VTUD1tCkNP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEFTSExJTUlUPW0KQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9IRUxQRVI9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0hMPW0KQ09ORklHX05FVEZJ
TFRFUl9YVF9NQVRDSF9JUFJBTkdFPW0KIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0lQVlMg
aXMgbm90IHNldApDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xFTkdUSD1tCkNPTkZJR19ORVRG
SUxURVJfWFRfTUFUQ0hfTElNSVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX01BQz1tCkNP
TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfTUFSSz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hf
TVVMVElQT1JUPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9PU0Y9bQpDT05GSUdfTkVURklM
VEVSX1hUX01BVENIX09XTkVSPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9QT0xJQ1k9bQpD
T05GSUdfTkVURklMVEVSX1hUX01BVENIX1BLVFRZUEU9bQpDT05GSUdfTkVURklMVEVSX1hUX01B
VENIX1FVT1RBPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9SQVRFRVNUPW0KQ09ORklHX05F
VEZJTFRFUl9YVF9NQVRDSF9SRUFMTT1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVDRU5U
PW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TQ1RQPW0KQ09ORklHX05FVEZJTFRFUl9YVF9N
QVRDSF9TT0NLRVQ9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NUQVRFPW0KQ09ORklHX05F
VEZJTFRFUl9YVF9NQVRDSF9TVEFUSVNUSUM9bQpDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NU
UklORz1tCkNPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVENQTVNTPW0KQ09ORklHX05FVEZJTFRF
Ul9YVF9NQVRDSF9USU1FPW0KQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9VMzI9bQojIENPTkZJ
R19JUF9TRVQgaXMgbm90IHNldApDT05GSUdfSVBfVlM9bQpDT05GSUdfSVBfVlNfSVBWNj15CiMg
Q09ORklHX0lQX1ZTX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0lQX1ZTX1RBQl9CSVRTPTEyCgoj
CiMgSVBWUyB0cmFuc3BvcnQgcHJvdG9jb2wgbG9hZCBiYWxhbmNpbmcgc3VwcG9ydAojCkNPTkZJ
R19JUF9WU19QUk9UT19UQ1A9eQpDT05GSUdfSVBfVlNfUFJPVE9fVURQPXkKQ09ORklHX0lQX1ZT
X1BST1RPX0FIX0VTUD15CkNPTkZJR19JUF9WU19QUk9UT19FU1A9eQpDT05GSUdfSVBfVlNfUFJP
VE9fQUg9eQojIENPTkZJR19JUF9WU19QUk9UT19TQ1RQIGlzIG5vdCBzZXQKCiMKIyBJUFZTIHNj
aGVkdWxlcgojCkNPTkZJR19JUF9WU19SUj1tCkNPTkZJR19JUF9WU19XUlI9bQpDT05GSUdfSVBf
VlNfTEM9bQpDT05GSUdfSVBfVlNfV0xDPW0KQ09ORklHX0lQX1ZTX0xCTEM9bQpDT05GSUdfSVBf
VlNfTEJMQ1I9bQpDT05GSUdfSVBfVlNfREg9bQpDT05GSUdfSVBfVlNfU0g9bQpDT05GSUdfSVBf
VlNfU0VEPW0KQ09ORklHX0lQX1ZTX05RPW0KCiMKIyBJUFZTIGFwcGxpY2F0aW9uIGhlbHBlcgoj
CkNPTkZJR19JUF9WU19GVFA9bQpDT05GSUdfSVBfVlNfTkZDVD15CiMgQ09ORklHX0lQX1ZTX1BF
X1NJUCBpcyBub3Qgc2V0CgojCiMgSVA6IE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKQ09ORklH
X05GX0RFRlJBR19JUFY0PW0KQ09ORklHX05GX0NPTk5UUkFDS19JUFY0PW0KQ09ORklHX05GX0NP
Tk5UUkFDS19QUk9DX0NPTVBBVD15CkNPTkZJR19JUF9ORl9RVUVVRT1tCkNPTkZJR19JUF9ORl9J
UFRBQkxFUz1tCkNPTkZJR19JUF9ORl9NQVRDSF9BSD1tCkNPTkZJR19JUF9ORl9NQVRDSF9FQ049
bQpDT05GSUdfSVBfTkZfTUFUQ0hfVFRMPW0KQ09ORklHX0lQX05GX0ZJTFRFUj1tCkNPTkZJR19J
UF9ORl9UQVJHRVRfUkVKRUNUPW0KQ09ORklHX0lQX05GX1RBUkdFVF9MT0c9bQpDT05GSUdfSVBf
TkZfVEFSR0VUX1VMT0c9bQpDT05GSUdfTkZfTkFUPW0KQ09ORklHX05GX05BVF9ORUVERUQ9eQpD
T05GSUdfSVBfTkZfVEFSR0VUX01BU1FVRVJBREU9bQpDT05GSUdfSVBfTkZfVEFSR0VUX05FVE1B
UD1tCkNPTkZJR19JUF9ORl9UQVJHRVRfUkVESVJFQ1Q9bQpDT05GSUdfTkZfTkFUX1BST1RPX0RD
Q1A9bQpDT05GSUdfTkZfTkFUX1BST1RPX0dSRT1tCkNPTkZJR19ORl9OQVRfUFJPVE9fVURQTElU
RT1tCkNPTkZJR19ORl9OQVRfUFJPVE9fU0NUUD1tCkNPTkZJR19ORl9OQVRfRlRQPW0KQ09ORklH
X05GX05BVF9JUkM9bQpDT05GSUdfTkZfTkFUX1RGVFA9bQpDT05GSUdfTkZfTkFUX0FNQU5EQT1t
CkNPTkZJR19ORl9OQVRfUFBUUD1tCkNPTkZJR19ORl9OQVRfSDMyMz1tCkNPTkZJR19ORl9OQVRf
U0lQPW0KQ09ORklHX0lQX05GX01BTkdMRT1tCkNPTkZJR19JUF9ORl9UQVJHRVRfQ0xVU1RFUklQ
PW0KQ09ORklHX0lQX05GX1RBUkdFVF9FQ049bQpDT05GSUdfSVBfTkZfVEFSR0VUX1RUTD1tCkNP
TkZJR19JUF9ORl9SQVc9bQpDT05GSUdfSVBfTkZfQVJQVEFCTEVTPW0KQ09ORklHX0lQX05GX0FS
UEZJTFRFUj1tCkNPTkZJR19JUF9ORl9BUlBfTUFOR0xFPW0KCiMKIyBJUHY2OiBOZXRmaWx0ZXIg
Q29uZmlndXJhdGlvbgojCkNPTkZJR19ORl9ERUZSQUdfSVBWNj1tCkNPTkZJR19ORl9DT05OVFJB
Q0tfSVBWNj1tCkNPTkZJR19JUDZfTkZfUVVFVUU9bQpDT05GSUdfSVA2X05GX0lQVEFCTEVTPW0K
Q09ORklHX0lQNl9ORl9NQVRDSF9BSD1tCkNPTkZJR19JUDZfTkZfTUFUQ0hfRVVJNjQ9bQpDT05G
SUdfSVA2X05GX01BVENIX0ZSQUc9bQpDT05GSUdfSVA2X05GX01BVENIX09QVFM9bQpDT05GSUdf
SVA2X05GX01BVENIX0hMPW0KQ09ORklHX0lQNl9ORl9NQVRDSF9JUFY2SEVBREVSPW0KQ09ORklH
X0lQNl9ORl9NQVRDSF9NSD1tCkNPTkZJR19JUDZfTkZfTUFUQ0hfUlQ9bQpDT05GSUdfSVA2X05G
X1RBUkdFVF9ITD1tCkNPTkZJR19JUDZfTkZfVEFSR0VUX0xPRz1tCkNPTkZJR19JUDZfTkZfRklM
VEVSPW0KQ09ORklHX0lQNl9ORl9UQVJHRVRfUkVKRUNUPW0KQ09ORklHX0lQNl9ORl9NQU5HTEU9
bQpDT05GSUdfSVA2X05GX1JBVz1tCiMgQ09ORklHX0lQX0RDQ1AgaXMgbm90IHNldAojIENPTkZJ
R19JUF9TQ1RQIGlzIG5vdCBzZXQKIyBDT05GSUdfUkRTIGlzIG5vdCBzZXQKIyBDT05GSUdfVElQ
QyBpcyBub3Qgc2V0CiMgQ09ORklHX0FUTSBpcyBub3Qgc2V0CiMgQ09ORklHX0wyVFAgaXMgbm90
IHNldAojIENPTkZJR19CUklER0UgaXMgbm90IHNldAojIENPTkZJR19ORVRfRFNBIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVkxBTl84MDIxUSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQ05FVCBpcyBub3Qg
c2V0CiMgQ09ORklHX0xMQzIgaXMgbm90IHNldAojIENPTkZJR19JUFggaXMgbm90IHNldAojIENP
TkZJR19BVEFMSyBpcyBub3Qgc2V0CiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0CiMgQ09ORklHX0xB
UEIgaXMgbm90IHNldAojIENPTkZJR19FQ09ORVQgaXMgbm90IHNldAojIENPTkZJR19XQU5fUk9V
VEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhPTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfSUVFRTgw
MjE1NCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfU0NIRUQ9eQoKIwojIFF1ZXVlaW5nL1NjaGVkdWxp
bmcKIwpDT05GSUdfTkVUX1NDSF9DQlE9bQpDT05GSUdfTkVUX1NDSF9IVEI9bQpDT05GSUdfTkVU
X1NDSF9IRlNDPW0KQ09ORklHX05FVF9TQ0hfUFJJTz1tCkNPTkZJR19ORVRfU0NIX01VTFRJUT1t
CkNPTkZJR19ORVRfU0NIX1JFRD1tCiMgQ09ORklHX05FVF9TQ0hfU0ZCIGlzIG5vdCBzZXQKQ09O
RklHX05FVF9TQ0hfU0ZRPW0KQ09ORklHX05FVF9TQ0hfVEVRTD1tCkNPTkZJR19ORVRfU0NIX1RC
Rj1tCkNPTkZJR19ORVRfU0NIX0dSRUQ9bQpDT05GSUdfTkVUX1NDSF9EU01BUks9bQpDT05GSUdf
TkVUX1NDSF9ORVRFTT1tCkNPTkZJR19ORVRfU0NIX0RSUj1tCiMgQ09ORklHX05FVF9TQ0hfTVFQ
UklPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX1NDSF9DSE9LRSBpcyBub3Qgc2V0CiMgQ09ORklH
X05FVF9TQ0hfUUZRIGlzIG5vdCBzZXQKQ09ORklHX05FVF9TQ0hfSU5HUkVTUz1tCgojCiMgQ2xh
c3NpZmljYXRpb24KIwpDT05GSUdfTkVUX0NMUz15CkNPTkZJR19ORVRfQ0xTX0JBU0lDPW0KQ09O
RklHX05FVF9DTFNfVENJTkRFWD1tCkNPTkZJR19ORVRfQ0xTX1JPVVRFND1tCkNPTkZJR19ORVRf
Q0xTX0ZXPW0KQ09ORklHX05FVF9DTFNfVTMyPW0KQ09ORklHX0NMU19VMzJfUEVSRj15CkNPTkZJ
R19DTFNfVTMyX01BUks9eQpDT05GSUdfTkVUX0NMU19SU1ZQPW0KQ09ORklHX05FVF9DTFNfUlNW
UDY9bQpDT05GSUdfTkVUX0NMU19GTE9XPW0KQ09ORklHX05FVF9DTFNfQ0dST1VQPXkKQ09ORklH
X05FVF9FTUFUQ0g9eQpDT05GSUdfTkVUX0VNQVRDSF9TVEFDSz0zMgpDT05GSUdfTkVUX0VNQVRD
SF9DTVA9bQpDT05GSUdfTkVUX0VNQVRDSF9OQllURT1tCkNPTkZJR19ORVRfRU1BVENIX1UzMj1t
CkNPTkZJR19ORVRfRU1BVENIX01FVEE9bQpDT05GSUdfTkVUX0VNQVRDSF9URVhUPW0KQ09ORklH
X05FVF9DTFNfQUNUPXkKQ09ORklHX05FVF9BQ1RfUE9MSUNFPW0KQ09ORklHX05FVF9BQ1RfR0FD
VD1tCkNPTkZJR19HQUNUX1BST0I9eQpDT05GSUdfTkVUX0FDVF9NSVJSRUQ9bQpDT05GSUdfTkVU
X0FDVF9JUFQ9bQpDT05GSUdfTkVUX0FDVF9OQVQ9bQpDT05GSUdfTkVUX0FDVF9QRURJVD1tCkNP
TkZJR19ORVRfQUNUX1NJTVA9bQpDT05GSUdfTkVUX0FDVF9TS0JFRElUPW0KIyBDT05GSUdfTkVU
X0FDVF9DU1VNIGlzIG5vdCBzZXQKQ09ORklHX05FVF9DTFNfSU5EPXkKQ09ORklHX05FVF9TQ0hf
RklGTz15CkNPTkZJR19EQ0I9eQojIENPTkZJR19CQVRNQU5fQURWIGlzIG5vdCBzZXQKQ09ORklH
X1JQUz15CkNPTkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKQ09ORklHX0hBVkVfQlBGX0pJ
VD15CiMgQ09ORklHX0JQRl9KSVQgaXMgbm90IHNldAoKIwojIE5ldHdvcmsgdGVzdGluZwojCkNP
TkZJR19ORVRfUEtUR0VOPW0KIyBDT05GSUdfTkVUX1RDUFBST0JFIGlzIG5vdCBzZXQKQ09ORklH
X05FVF9EUk9QX01PTklUT1I9eQojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0CiMgQ09ORklH
X0NBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lSREEgaXMgbm90IHNldAojIENPTkZJR19CVCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0FGX1JYUlBDIGlzIG5vdCBzZXQKQ09ORklHX0ZJQl9SVUxFUz15CiMg
Q09ORklHX1dJUkVMRVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfV0lNQVggaXMgbm90IHNldAojIENP
TkZJR19SRktJTEwgaXMgbm90IHNldAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNldAojIENPTkZJ
R19DQUlGIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNldAoKIwojIERldmlj
ZSBEcml2ZXJzCiMKCiMKIyBHZW5lcmljIERyaXZlciBPcHRpb25zCiMKQ09ORklHX1VFVkVOVF9I
RUxQRVJfUEFUSD0iIgpDT05GSUdfREVWVE1QRlM9eQojIENPTkZJR19ERVZUTVBGU19NT1VOVCBp
cyBub3Qgc2V0CkNPTkZJR19TVEFOREFMT05FPXkKQ09ORklHX1BSRVZFTlRfRklSTVdBUkVfQlVJ
TEQ9eQpDT05GSUdfRldfTE9BREVSPXkKIyBDT05GSUdfRklSTVdBUkVfSU5fS0VSTkVMIGlzIG5v
dCBzZXQKQ09ORklHX0VYVFJBX0ZJUk1XQVJFPSIiCiMgQ09ORklHX0RFQlVHX0RSSVZFUiBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RFQlVHX0RFVlJFUyBpcyBub3Qgc2V0CkNPTkZJR19TWVNfSFlQRVJW
SVNPUj15CkNPTkZJR19TUl9SRVBPUlRfVElNRV9MSU1JVD0xMDAKIyBDT05GSUdfQ09OTkVDVE9S
IGlzIG5vdCBzZXQKIyBDT05GSUdfTVREIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFSUE9SVCBpcyBu
b3Qgc2V0CkNPTkZJR19QTlA9eQojIENPTkZJR19QTlBfREVCVUdfTUVTU0FHRVMgaXMgbm90IHNl
dAoKIwojIFByb3RvY29scwojCkNPTkZJR19QTlBBQ1BJPXkKQ09ORklHX0JMS19ERVY9eQojIENP
TkZJR19CTEtfREVWX0ZEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NQUV9EQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0JMS19DUFFfQ0lTU19EQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfREFD
OTYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9VTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdf
QkxLX0RFVl9DT1dfQ09NTU9OIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfTE9PUD15CiMgQ09O
RklHX0JMS19ERVZfQ1JZUFRPTE9PUCBpcyBub3Qgc2V0CgojCiMgRFJCRCBkaXNhYmxlZCBiZWNh
dXNlIFBST0NfRlMsIElORVQgb3IgQ09OTkVDVE9SIG5vdCBzZWxlY3RlZAojCiMgQ09ORklHX0JM
S19ERVZfTkJEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9TWDggaXMgbm90IHNldAojIENP
TkZJR19CTEtfREVWX1VCIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfUkFNPXkKQ09ORklHX0JM
S19ERVZfUkFNX0NPVU5UPTE2CkNPTkZJR19CTEtfREVWX1JBTV9TSVpFPTY1NTM2CiMgQ09ORklH
X0JMS19ERVZfWElQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0RST01fUEtUQ0RWRCBpcyBub3Qgc2V0
CiMgQ09ORklHX0FUQV9PVkVSX0VUSCBpcyBub3Qgc2V0CkNPTkZJR19YRU5fQkxLREVWX0ZST05U
RU5EPXkKIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfUkJE
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MSVMzTFYwMkQgaXMgbm90IHNldApDT05GSUdf
TUlTQ19ERVZJQ0VTPXkKIyBDT05GSUdfQUQ1MjVYX0RQT1QgaXMgbm90IHNldAojIENPTkZJR19J
Qk1fQVNNIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhBTlRPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0lO
VEVMX01JRF9QVEkgaXMgbm90IHNldAojIENPTkZJR19TR0lfSU9DNCBpcyBub3Qgc2V0CiMgQ09O
RklHX1RJRk1fQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lDUzkzMlM0MDEgaXMgbm90IHNldAoj
IENPTkZJR19FTkNMT1NVUkVfU0VSVklDRVMgaXMgbm90IHNldAojIENPTkZJR19IUF9JTE8gaXMg
bm90IHNldAojIENPTkZJR19BUERTOTgwMkFMUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTTDI5MDAz
IGlzIG5vdCBzZXQKIyBDT05GSUdfSVNMMjkwMjAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT
X1RTTDI1NTAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0JIMTc4MCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BUERTOTkw
WCBpcyBub3Qgc2V0CiMgQ09ORklHX0hNQzYzNTIgaXMgbm90IHNldAojIENPTkZJR19EUzE2ODIg
aXMgbm90IHNldAojIENPTkZJR19WTVdBUkVfQkFMTE9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX0JN
UDA4NSBpcyBub3Qgc2V0CiMgQ09ORklHX1BDSF9QSFVCIGlzIG5vdCBzZXQKIyBDT05GSUdfQzJQ
T1JUIGlzIG5vdCBzZXQKCiMKIyBFRVBST00gc3VwcG9ydAojCkNPTkZJR19FRVBST01fQVQyND1t
CkNPTkZJR19FRVBST01fTEVHQUNZPW0KQ09ORklHX0VFUFJPTV9NQVg2ODc1PW0KQ09ORklHX0VF
UFJPTV85M0NYNj1tCiMgQ09ORklHX0NCNzEwX0NPUkUgaXMgbm90IHNldAoKIwojIFRleGFzIElu
c3RydW1lbnRzIHNoYXJlZCB0cmFuc3BvcnQgbGluZSBkaXNjaXBsaW5lCiMKIyBDT05GSUdfVElf
U1QgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xJUzNfSTJDIGlzIG5vdCBzZXQKQ09ORklH
X0hBVkVfSURFPXkKIyBDT05GSUdfSURFIGlzIG5vdCBzZXQKCiMKIyBTQ1NJIGRldmljZSBzdXBw
b3J0CiMKQ09ORklHX1NDU0lfTU9EPXkKQ09ORklHX1JBSURfQVRUUlM9bQpDT05GSUdfU0NTST15
CkNPTkZJR19TQ1NJX0RNQT15CkNPTkZJR19TQ1NJX1RHVD1tCkNPTkZJR19TQ1NJX05FVExJTks9
eQpDT05GSUdfU0NTSV9QUk9DX0ZTPXkKCiMKIyBTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywgdGFw
ZSwgQ0QtUk9NKQojCiMgQ09ORklHX0JMS19ERVZfU0QgaXMgbm90IHNldAojIENPTkZJR19DSFJf
REVWX1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hSX0RFVl9PU1NUIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkxLX0RFVl9TUiBpcyBub3Qgc2V0CiMgQ09ORklHX0NIUl9ERVZfU0cgaXMgbm90IHNldAoj
IENPTkZJR19DSFJfREVWX1NDSCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CkNP
TkZJR19TQ1NJX0NPTlNUQU5UUz15CkNPTkZJR19TQ1NJX0xPR0dJTkc9eQpDT05GSUdfU0NTSV9T
Q0FOX0FTWU5DPXkKQ09ORklHX1NDU0lfV0FJVF9TQ0FOPW0KCiMKIyBTQ1NJIFRyYW5zcG9ydHMK
IwpDT05GSUdfU0NTSV9TUElfQVRUUlM9bQpDT05GSUdfU0NTSV9GQ19BVFRSUz1tCkNPTkZJR19T
Q1NJX0ZDX1RHVF9BVFRSUz15CkNPTkZJR19TQ1NJX0lTQ1NJX0FUVFJTPW0KQ09ORklHX1NDU0lf
U0FTX0FUVFJTPW0KQ09ORklHX1NDU0lfU0FTX0xJQlNBUz1tCkNPTkZJR19TQ1NJX1NBU19BVEE9
eQpDT05GSUdfU0NTSV9TQVNfSE9TVF9TTVA9eQpDT05GSUdfU0NTSV9TUlBfQVRUUlM9bQpDT05G
SUdfU0NTSV9TUlBfVEdUX0FUVFJTPXkKQ09ORklHX1NDU0lfTE9XTEVWRUw9eQpDT05GSUdfSVND
U0lfVENQPW0KQ09ORklHX0lTQ1NJX0JPT1RfU1lTRlM9bQpDT05GSUdfU0NTSV9DWEdCM19JU0NT
ST1tCiMgQ09ORklHX1NDU0lfQ1hHQjRfSVNDU0kgaXMgbm90IHNldApDT05GSUdfU0NTSV9CTlgy
X0lTQ1NJPW0KIyBDT05GSUdfU0NTSV9CTlgyWF9GQ09FIGlzIG5vdCBzZXQKQ09ORklHX0JFMklT
Q1NJPW0KQ09ORklHX0JMS19ERVZfM1dfWFhYWF9SQUlEPW0KQ09ORklHX1NDU0lfSFBTQT1tCkNP
TkZJR19TQ1NJXzNXXzlYWFg9bQpDT05GSUdfU0NTSV8zV19TQVM9bQpDT05GSUdfU0NTSV9BQ0FS
RD1tCkNPTkZJR19TQ1NJX0FBQ1JBSUQ9bQpDT05GSUdfU0NTSV9BSUM3WFhYPW0KQ09ORklHX0FJ
QzdYWFhfQ01EU19QRVJfREVWSUNFPTgKQ09ORklHX0FJQzdYWFhfUkVTRVRfREVMQVlfTVM9MTUw
MDAKQ09ORklHX0FJQzdYWFhfREVCVUdfRU5BQkxFPXkKQ09ORklHX0FJQzdYWFhfREVCVUdfTUFT
Sz0wCkNPTkZJR19BSUM3WFhYX1JFR19QUkVUVFlfUFJJTlQ9eQpDT05GSUdfU0NTSV9BSUM3WFhY
X09MRD1tCkNPTkZJR19TQ1NJX0FJQzc5WFg9bQpDT05GSUdfQUlDNzlYWF9DTURTX1BFUl9ERVZJ
Q0U9MzIKQ09ORklHX0FJQzc5WFhfUkVTRVRfREVMQVlfTVM9MTUwMDAKQ09ORklHX0FJQzc5WFhf
REVCVUdfRU5BQkxFPXkKQ09ORklHX0FJQzc5WFhfREVCVUdfTUFTSz0wCkNPTkZJR19BSUM3OVhY
X1JFR19QUkVUVFlfUFJJTlQ9eQpDT05GSUdfU0NTSV9BSUM5NFhYPW0KIyBDT05GSUdfQUlDOTRY
WF9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX01WU0FTPW0KIyBDT05GSUdfU0NTSV9NVlNB
U19ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX0RQVF9JMk89bQpDT05GSUdfU0NTSV9BRFZB
TlNZUz1tCkNPTkZJR19TQ1NJX0FSQ01TUj1tCiMgQ09ORklHX1NDU0lfQVJDTVNSX0FFUiBpcyBu
b3Qgc2V0CkNPTkZJR19NRUdBUkFJRF9ORVdHRU49eQpDT05GSUdfTUVHQVJBSURfTU09bQpDT05G
SUdfTUVHQVJBSURfTUFJTEJPWD1tCkNPTkZJR19NRUdBUkFJRF9MRUdBQ1k9bQpDT05GSUdfTUVH
QVJBSURfU0FTPW0KQ09ORklHX1NDU0lfTVBUMlNBUz1tCkNPTkZJR19TQ1NJX01QVDJTQVNfTUFY
X1NHRT0xMjgKIyBDT05GSUdfU0NTSV9NUFQyU0FTX0xPR0dJTkcgaXMgbm90IHNldApDT05GSUdf
U0NTSV9IUFRJT1A9bQpDT05GSUdfU0NTSV9CVVNMT0dJQz1tCkNPTkZJR19WTVdBUkVfUFZTQ1NJ
PW0KQ09ORklHX0xJQkZDPW0KQ09ORklHX0xJQkZDT0U9bQpDT05GSUdfRkNPRT1tCkNPTkZJR19G
Q09FX0ZOSUM9bQpDT05GSUdfU0NTSV9ETVgzMTkxRD1tCkNPTkZJR19TQ1NJX0VBVEE9bQpDT05G
SUdfU0NTSV9FQVRBX1RBR0dFRF9RVUVVRT15CkNPTkZJR19TQ1NJX0VBVEFfTElOS0VEX0NPTU1B
TkRTPXkKQ09ORklHX1NDU0lfRUFUQV9NQVhfVEFHUz0xNgpDT05GSUdfU0NTSV9GVVRVUkVfRE9N
QUlOPW0KQ09ORklHX1NDU0lfR0RUSD1tCiMgQ09ORklHX1NDU0lfSVNDSSBpcyBub3Qgc2V0CkNP
TkZJR19TQ1NJX0lQUz1tCkNPTkZJR19TQ1NJX0lOSVRJTz1tCkNPTkZJR19TQ1NJX0lOSUExMDA9
bQpDT05GSUdfU0NTSV9TVEVYPW0KQ09ORklHX1NDU0lfU1lNNTNDOFhYXzI9bQpDT05GSUdfU0NT
SV9TWU01M0M4WFhfRE1BX0FERFJFU1NJTkdfTU9ERT0xCkNPTkZJR19TQ1NJX1NZTTUzQzhYWF9E
RUZBVUxUX1RBR1M9MTYKQ09ORklHX1NDU0lfU1lNNTNDOFhYX01BWF9UQUdTPTY0CkNPTkZJR19T
Q1NJX1NZTTUzQzhYWF9NTUlPPXkKQ09ORklHX1NDU0lfSVBSPW0KIyBDT05GSUdfU0NTSV9JUFJf
VFJBQ0UgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lQUl9EVU1QIGlzIG5vdCBzZXQKQ09ORklH
X1NDU0lfUUxPR0lDXzEyODA9bQpDT05GSUdfU0NTSV9RTEFfRkM9bQpDT05GSUdfU0NTSV9RTEFf
SVNDU0k9bQpDT05GSUdfU0NTSV9MUEZDPW0KIyBDT05GSUdfU0NTSV9MUEZDX0RFQlVHX0ZTIGlz
IG5vdCBzZXQKQ09ORklHX1NDU0lfREMzOTV4PW0KQ09ORklHX1NDU0lfREMzOTBUPW0KQ09ORklH
X1NDU0lfREVCVUc9bQpDT05GSUdfU0NTSV9QTUNSQUlEPW0KQ09ORklHX1NDU0lfUE04MDAxPW0K
Q09ORklHX1NDU0lfU1JQPW0KQ09ORklHX1NDU0lfQkZBX0ZDPW0KIyBDT05GSUdfU0NTSV9ESCBp
cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19B
VEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZFUkJP
U0VfRVJST1I9eQpDT05GSUdfQVRBX0FDUEk9eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRy
b2xsZXJzIHdpdGggbm9uLVNGRiBuYXRpdmUgaW50ZXJmYWNlCiMKQ09ORklHX1NBVEFfQUhDST15
CiMgQ09ORklHX1NBVEFfQUhDSV9QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfSU5J
QzE2MlggaXMgbm90IHNldAojIENPTkZJR19TQVRBX0FDQVJEX0FIQ0kgaXMgbm90IHNldAojIENP
TkZJR19TQVRBX1NJTDI0IGlzIG5vdCBzZXQKQ09ORklHX0FUQV9TRkY9eQoKIwojIFNGRiBjb250
cm9sbGVycyB3aXRoIGN1c3RvbSBETUEgaW50ZXJmYWNlCiMKIyBDT05GSUdfUERDX0FETUEgaXMg
bm90IHNldAojIENPTkZJR19TQVRBX1FTVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9TWDQg
aXMgbm90IHNldApDT05GSUdfQVRBX0JNRE1BPXkKCiMKIyBTQVRBIFNGRiBjb250cm9sbGVycyB3
aXRoIEJNRE1BCiMKIyBDT05GSUdfQVRBX1BJSVggaXMgbm90IHNldAojIENPTkZJR19TQVRBX01W
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9OViBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfUFJP
TUlTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FU
QV9TSVMgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NWVyBpcyBub3Qgc2V0CiMgQ09ORklHX1NB
VEFfVUxJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9WSUEgaXMgbm90IHNldAojIENPTkZJR19T
QVRBX1ZJVEVTU0UgaXMgbm90IHNldAoKIwojIFBBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1E
TUEKIwojIENPTkZJR19QQVRBX0FMSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQU1EIGlzIG5v
dCBzZXQKIyBDT05GSUdfUEFUQV9BUkFTQU5fQ0YgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0FS
VE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BVElJWFAgaXMgbm90IHNldAojIENPTkZJR19Q
QVRBX0FUUDg2N1ggaXMgbm90IHNldAojIENPTkZJR19QQVRBX0NNRDY0WCBpcyBub3Qgc2V0CiMg
Q09ORklHX1BBVEFfQ1M1NTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9DUzU1MzAgaXMgbm90
IHNldAojIENPTkZJR19QQVRBX0NTNTUzNiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQ1lQUkVT
UyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfRUZBUiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFf
SFBUMzY2IGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9IUFQzN1ggaXMgbm90IHNldAojIENPTkZJ
R19QQVRBX0hQVDNYMk4gaXMgbm90IHNldAojIENPTkZJR19QQVRBX0hQVDNYMyBpcyBub3Qgc2V0
CiMgQ09ORklHX1BBVEFfSVQ4MjEzIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9JVDgyMVggaXMg
bm90IHNldAojIENPTkZJR19QQVRBX0pNSUNST04gaXMgbm90IHNldAojIENPTkZJR19QQVRBX01B
UlZFTEwgaXMgbm90IHNldAojIENPTkZJR19QQVRBX05FVENFTEwgaXMgbm90IHNldAojIENPTkZJ
R19QQVRBX05JTkpBMzIgaXMgbm90IHNldAojIENPTkZJR19QQVRBX05TODc0MTUgaXMgbm90IHNl
dAojIENPTkZJR19QQVRBX09MRFBJSVggaXMgbm90IHNldAojIENPTkZJR19QQVRBX09QVElETUEg
aXMgbm90IHNldAojIENPTkZJR19QQVRBX1BEQzIwMjdYIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFU
QV9QRENfT0xEIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9SQURJU1lTIGlzIG5vdCBzZXQKIyBD
T05GSUdfUEFUQV9SREMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1NDMTIwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX1BBVEFfU0NIIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9TRVJWRVJXT1JLUyBp
cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfU0lMNjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9T
SVMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1RPU0hJQkEgaXMgbm90IHNldAojIENPTkZJR19Q
QVRBX1RSSUZMRVggaXMgbm90IHNldAojIENPTkZJR19QQVRBX1ZJQSBpcyBub3Qgc2V0CiMgQ09O
RklHX1BBVEFfV0lOQk9ORCBpcyBub3Qgc2V0CgojCiMgUElPLW9ubHkgU0ZGIGNvbnRyb2xsZXJz
CiMKIyBDT05GSUdfUEFUQV9DTUQ2NDBfUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9NUElJ
WCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfTlM4NzQxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1BB
VEFfT1BUSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfUExBVEZPUk0gaXMgbm90IHNldAojIENP
TkZJR19QQVRBX1JaMTAwMCBpcyBub3Qgc2V0CgojCiMgR2VuZXJpYyBmYWxsYmFjayAvIGxlZ2Fj
eSBkcml2ZXJzCiMKIyBDT05GSUdfUEFUQV9BQ1BJIGlzIG5vdCBzZXQKQ09ORklHX0FUQV9HRU5F
UklDPXkKIyBDT05GSUdfUEFUQV9MRUdBQ1kgaXMgbm90IHNldAojIENPTkZJR19NRCBpcyBub3Qg
c2V0CiMgQ09ORklHX1RBUkdFVF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfRlVTSU9OIGlzIG5v
dCBzZXQKCiMKIyBJRUVFIDEzOTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMKQ09ORklHX0ZJUkVXSVJF
PW0KQ09ORklHX0ZJUkVXSVJFX09IQ0k9bQpDT05GSUdfRklSRVdJUkVfT0hDSV9ERUJVRz15CkNP
TkZJR19GSVJFV0lSRV9TQlAyPW0KQ09ORklHX0ZJUkVXSVJFX05FVD1tCiMgQ09ORklHX0ZJUkVX
SVJFX05PU1kgaXMgbm90IHNldAojIENPTkZJR19JMk8gaXMgbm90IHNldAojIENPTkZJR19NQUNJ
TlRPU0hfRFJJVkVSUyBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZJQ0VTPXkKIyBDT05GSUdfSUZC
IGlzIG5vdCBzZXQKIyBDT05GSUdfRFVNTVkgaXMgbm90IHNldAojIENPTkZJR19CT05ESU5HIGlz
IG5vdCBzZXQKIyBDT05GSUdfTUFDVkxBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0VRVUFMSVpFUiBp
cyBub3Qgc2V0CiMgQ09ORklHX1RVTiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZFVEggaXMgbm90IHNl
dAojIENPTkZJR19ORVRfU0IxMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDTkVUIGlzIG5vdCBz
ZXQKQ09ORklHX01JST15CiMgQ09ORklHX1BIWUxJQiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9F
VEhFUk5FVCBpcyBub3Qgc2V0CkNPTkZJR19ORVRERVZfMTAwMD15CiMgQ09ORklHX0FDRU5JQyBp
cyBub3Qgc2V0CiMgQ09ORklHX0RMMksgaXMgbm90IHNldAojIENPTkZJR19FMTAwMCBpcyBub3Qg
c2V0CiMgQ09ORklHX0UxMDAwRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lQMTAwMCBpcyBub3Qgc2V0
CiMgQ09ORklHX0lHQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lHQlZGIGlzIG5vdCBzZXQKIyBDT05G
SUdfTlM4MzgyMCBpcyBub3Qgc2V0CiMgQ09ORklHX0hBTUFDSEkgaXMgbm90IHNldAojIENPTkZJ
R19ZRUxMT1dGSU4gaXMgbm90IHNldAojIENPTkZJR19SODE2OSBpcyBub3Qgc2V0CiMgQ09ORklH
X1NJUzE5MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NLR0UgaXMgbm90IHNldAojIENPTkZJR19TS1ky
IGlzIG5vdCBzZXQKIyBDT05GSUdfVklBX1ZFTE9DSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfVElH
T04zIGlzIG5vdCBzZXQKQ09ORklHX0JOWDI9bQpDT05GSUdfQ05JQz1tCiMgQ09ORklHX1FMQTNY
WFggaXMgbm90IHNldAojIENPTkZJR19BVEwxIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRMMUUgaXMg
bm90IHNldAojIENPTkZJR19BVEwxQyBpcyBub3Qgc2V0CiMgQ09ORklHX0pNRSBpcyBub3Qgc2V0
CiMgQ09ORklHX1NUTU1BQ19FVEggaXMgbm90IHNldAojIENPTkZJR19QQ0hfR0JFIGlzIG5vdCBz
ZXQKQ09ORklHX05FVERFVl8xMDAwMD15CkNPTkZJR19NRElPPW0KIyBDT05GSUdfQ0hFTFNJT19U
MSBpcyBub3Qgc2V0CkNPTkZJR19DSEVMU0lPX1QzPW0KIyBDT05GSUdfQ0hFTFNJT19UNCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0NIRUxTSU9fVDRWRiBpcyBub3Qgc2V0CiMgQ09ORklHX0VOSUMgaXMg
bm90IHNldAojIENPTkZJR19JWEdCRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lYR0JFVkYgaXMgbm90
IHNldAojIENPTkZJR19JWEdCIGlzIG5vdCBzZXQKIyBDT05GSUdfUzJJTyBpcyBub3Qgc2V0CiMg
Q09ORklHX1ZYR0UgaXMgbm90IHNldAojIENPTkZJR19NWVJJMTBHRSBpcyBub3Qgc2V0CiMgQ09O
RklHX05FVFhFTl9OSUMgaXMgbm90IHNldAojIENPTkZJR19OSVUgaXMgbm90IHNldAojIENPTkZJ
R19NTFg0X0VOIGlzIG5vdCBzZXQKIyBDT05GSUdfTUxYNF9DT1JFIGlzIG5vdCBzZXQKIyBDT05G
SUdfVEVIVVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfQk5YMlggaXMgbm90IHNldAojIENPTkZJR19R
TENOSUMgaXMgbm90IHNldAojIENPTkZJR19RTEdFIGlzIG5vdCBzZXQKIyBDT05GSUdfQk5BIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0ZDIGlzIG5vdCBzZXQKIyBDT05GSUdfQkUyTkVUIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVFIgaXMgbm90IHNldAojIENPTkZJR19XTEFOIGlzIG5vdCBzZXQKCiMKIyBF
bmFibGUgV2lNQVggKE5ldHdvcmtpbmcgb3B0aW9ucykgdG8gc2VlIHRoZSBXaU1BWCBkcml2ZXJz
CiMKCiMKIyBVU0IgTmV0d29yayBBZGFwdGVycwojCkNPTkZJR19VU0JfQ0FUQz1tCkNPTkZJR19V
U0JfS0FXRVRIPW0KQ09ORklHX1VTQl9QRUdBU1VTPW0KQ09ORklHX1VTQl9SVEw4MTUwPW0KQ09O
RklHX1VTQl9VU0JORVQ9bQpDT05GSUdfVVNCX05FVF9BWDg4MTdYPW0KQ09ORklHX1VTQl9ORVRf
Q0RDRVRIRVI9bQpDT05GSUdfVVNCX05FVF9DRENfRUVNPW0KQ09ORklHX1VTQl9ORVRfQ0RDX05D
TT1tCkNPTkZJR19VU0JfTkVUX0RNOTYwMT1tCiMgQ09ORklHX1VTQl9ORVRfU01TQzc1WFggaXMg
bm90IHNldApDT05GSUdfVVNCX05FVF9TTVNDOTVYWD1tCkNPTkZJR19VU0JfTkVUX0dMNjIwQT1t
CkNPTkZJR19VU0JfTkVUX05FVDEwODA9bQpDT05GSUdfVVNCX05FVF9QTFVTQj1tCkNPTkZJR19V
U0JfTkVUX01DUzc4MzA9bQpDT05GSUdfVVNCX05FVF9STkRJU19IT1NUPW0KQ09ORklHX1VTQl9O
RVRfQ0RDX1NVQlNFVD1tCkNPTkZJR19VU0JfQUxJX001NjMyPXkKQ09ORklHX1VTQl9BTjI3MjA9
eQpDT05GSUdfVVNCX0JFTEtJTj15CkNPTkZJR19VU0JfQVJNTElOVVg9eQpDT05GSUdfVVNCX0VQ
U09OMjg4OD15CkNPTkZJR19VU0JfS0MyMTkwPXkKQ09ORklHX1VTQl9ORVRfWkFVUlVTPW0KIyBD
T05GSUdfVVNCX05FVF9DWDgyMzEwX0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfS0FM
TUlBIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9ORVRfSU5UNTFYMT1tCkNPTkZJR19VU0JfSVBIRVRI
PW0KIyBDT05GSUdfVVNCX1NJRVJSQV9ORVQgaXMgbm90IHNldAojIENPTkZJR19VU0JfVkw2MDAg
aXMgbm90IHNldAojIENPTkZJR19XQU4gaXMgbm90IHNldAoKIwojIENBSUYgdHJhbnNwb3J0IGRy
aXZlcnMKIwpDT05GSUdfWEVOX05FVERFVl9GUk9OVEVORD15CiMgQ09ORklHX0ZEREkgaXMgbm90
IHNldAojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0CiMgQ09ORklHX1BQUCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NMSVAgaXMgbm90IHNldAojIENPTkZJR19ORVRfRkMgaXMgbm90IHNldAojIENPTkZJ
R19ORVRDT05TT0xFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUUE9MTCBpcyBub3Qgc2V0CiMgQ09O
RklHX05FVF9QT0xMX0NPTlRST0xMRVIgaXMgbm90IHNldAojIENPTkZJR19WTVhORVQzIGlzIG5v
dCBzZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CiMgQ09ORklHX1BIT05FIGlzIG5vdCBzZXQK
CiMKIyBJbnB1dCBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJR19JTlBVVD15CkNPTkZJR19JTlBVVF9G
Rl9NRU1MRVNTPW0KQ09ORklHX0lOUFVUX1BPTExERVY9bQojIENPTkZJR19JTlBVVF9TUEFSU0VL
TUFQIGlzIG5vdCBzZXQKCiMKIyBVc2VybGFuZCBpbnRlcmZhY2VzCiMKQ09ORklHX0lOUFVUX01P
VVNFREVWPXkKIyBDT05GSUdfSU5QVVRfTU9VU0VERVZfUFNBVVggaXMgbm90IHNldApDT05GSUdf
SU5QVVRfTU9VU0VERVZfU0NSRUVOX1g9MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVO
X1k9NzY4CiMgQ09ORklHX0lOUFVUX0pPWURFViBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9FVkRF
Vj15CiMgQ09ORklHX0lOUFVUX0VWQlVHIGlzIG5vdCBzZXQKCiMKIyBJbnB1dCBEZXZpY2UgRHJp
dmVycwojCkNPTkZJR19JTlBVVF9LRVlCT0FSRD15CkNPTkZJR19LRVlCT0FSRF9BRFA1NTg4PW0K
IyBDT05GSUdfS0VZQk9BUkRfQURQNTU4OSBpcyBub3Qgc2V0CkNPTkZJR19LRVlCT0FSRF9BVEtC
RD15CiMgQ09ORklHX0tFWUJPQVJEX1FUMTA3MCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJE
X1FUMjE2MCBpcyBub3Qgc2V0CkNPTkZJR19LRVlCT0FSRF9MS0tCRD1tCiMgQ09ORklHX0tFWUJP
QVJEX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9HUElPX1BPTExFRCBpcyBub3Qg
c2V0CiMgQ09ORklHX0tFWUJPQVJEX1RDQTY0MTYgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FS
RF9NQVRSSVggaXMgbm90IHNldApDT05GSUdfS0VZQk9BUkRfTE04MzIzPW0KQ09ORklHX0tFWUJP
QVJEX01BWDczNTk9bQojIENPTkZJR19LRVlCT0FSRF9NQ1MgaXMgbm90IHNldAojIENPTkZJR19L
RVlCT0FSRF9NUFIxMjEgaXMgbm90IHNldApDT05GSUdfS0VZQk9BUkRfTkVXVE9OPW0KQ09ORklH
X0tFWUJPQVJEX09QRU5DT1JFUz1tCkNPTkZJR19LRVlCT0FSRF9TVE9XQVdBWT1tCkNPTkZJR19L
RVlCT0FSRF9TVU5LQkQ9bQpDT05GSUdfS0VZQk9BUkRfWFRLQkQ9bQpDT05GSUdfSU5QVVRfTU9V
U0U9eQpDT05GSUdfTU9VU0VfUFMyPW0KQ09ORklHX01PVVNFX1BTMl9BTFBTPXkKQ09ORklHX01P
VVNFX1BTMl9MT0dJUFMyUFA9eQpDT05GSUdfTU9VU0VfUFMyX1NZTkFQVElDUz15CkNPTkZJR19N
T1VTRV9QUzJfTElGRUJPT0s9eQpDT05GSUdfTU9VU0VfUFMyX1RSQUNLUE9JTlQ9eQpDT05GSUdf
TU9VU0VfUFMyX0VMQU5URUNIPXkKQ09ORklHX01PVVNFX1BTMl9TRU5URUxJQz15CiMgQ09ORklH
X01PVVNFX1BTMl9UT1VDSEtJVCBpcyBub3Qgc2V0CkNPTkZJR19NT1VTRV9TRVJJQUw9bQpDT05G
SUdfTU9VU0VfQVBQTEVUT1VDSD1tCkNPTkZJR19NT1VTRV9CQ001OTc0PW0KQ09ORklHX01PVVNF
X1ZTWFhYQUE9bQojIENPTkZJR19NT1VTRV9HUElPIGlzIG5vdCBzZXQKQ09ORklHX01PVVNFX1NZ
TkFQVElDU19JMkM9bQpDT05GSUdfSU5QVVRfSk9ZU1RJQ0s9eQpDT05GSUdfSk9ZU1RJQ0tfQU5B
TE9HPW0KQ09ORklHX0pPWVNUSUNLX0EzRD1tCkNPTkZJR19KT1lTVElDS19BREk9bQpDT05GSUdf
Sk9ZU1RJQ0tfQ09CUkE9bQpDT05GSUdfSk9ZU1RJQ0tfR0YySz1tCkNPTkZJR19KT1lTVElDS19H
UklQPW0KQ09ORklHX0pPWVNUSUNLX0dSSVBfTVA9bQpDT05GSUdfSk9ZU1RJQ0tfR1VJTExFTU9U
PW0KQ09ORklHX0pPWVNUSUNLX0lOVEVSQUNUPW0KQ09ORklHX0pPWVNUSUNLX1NJREVXSU5ERVI9
bQpDT05GSUdfSk9ZU1RJQ0tfVE1EQz1tCkNPTkZJR19KT1lTVElDS19JRk9SQ0U9bQpDT05GSUdf
Sk9ZU1RJQ0tfSUZPUkNFX1VTQj15CkNPTkZJR19KT1lTVElDS19JRk9SQ0VfMjMyPXkKQ09ORklH
X0pPWVNUSUNLX1dBUlJJT1I9bQpDT05GSUdfSk9ZU1RJQ0tfTUFHRUxMQU49bQpDT05GSUdfSk9Z
U1RJQ0tfU1BBQ0VPUkI9bQpDT05GSUdfSk9ZU1RJQ0tfU1BBQ0VCQUxMPW0KQ09ORklHX0pPWVNU
SUNLX1NUSU5HRVI9bQpDT05GSUdfSk9ZU1RJQ0tfVFdJREpPWT1tCkNPTkZJR19KT1lTVElDS19a
SEVOSFVBPW0KIyBDT05GSUdfSk9ZU1RJQ0tfQVM1MDExIGlzIG5vdCBzZXQKQ09ORklHX0pPWVNU
SUNLX0pPWURVTVA9bQpDT05GSUdfSk9ZU1RJQ0tfWFBBRD1tCkNPTkZJR19KT1lTVElDS19YUEFE
X0ZGPXkKQ09ORklHX0pPWVNUSUNLX1hQQURfTEVEUz15CkNPTkZJR19JTlBVVF9UQUJMRVQ9eQpD
T05GSUdfVEFCTEVUX1VTQl9BQ0VDQUQ9bQpDT05GSUdfVEFCTEVUX1VTQl9BSVBURUs9bQpDT05G
SUdfVEFCTEVUX1VTQl9HVENPPW0KIyBDT05GSUdfVEFCTEVUX1VTQl9IQU5XQU5HIGlzIG5vdCBz
ZXQKQ09ORklHX1RBQkxFVF9VU0JfS0JUQUI9bQpDT05GSUdfVEFCTEVUX1VTQl9XQUNPTT1tCkNP
TkZJR19JTlBVVF9UT1VDSFNDUkVFTj15CkNPTkZJR19UT1VDSFNDUkVFTl9BRDc4Nzk9bQpDT05G
SUdfVE9VQ0hTQ1JFRU5fQUQ3ODc5X0kyQz1tCiMgQ09ORklHX1RPVUNIU0NSRUVOX0FUTUVMX01Y
VCBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0JVMjEwMTMgaXMgbm90IHNldAojIENP
TkZJR19UT1VDSFNDUkVFTl9DWThDVE1HMTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JF
RU5fRFlOQVBSTyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0hBTVBTSElSRSBpcyBu
b3Qgc2V0CkNPTkZJR19UT1VDSFNDUkVFTl9FRVRJPW0KQ09ORklHX1RPVUNIU0NSRUVOX0ZVSklU
U1U9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fR1VOWkU9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fRUxPPW0K
Q09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4MDAxPW0KIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTUFY
MTE4MDEgaXMgbm90IHNldApDT05GSUdfVE9VQ0hTQ1JFRU5fTUNTNTAwMD1tCkNPTkZJR19UT1VD
SFNDUkVFTl9NVE9VQ0g9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fSU5FWElPPW0KQ09ORklHX1RPVUNI
U0NSRUVOX01LNzEyPW0KQ09ORklHX1RPVUNIU0NSRUVOX1BFTk1PVU5UPW0KQ09ORklHX1RPVUNI
U0NSRUVOX1RPVUNIUklHSFQ9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fVE9VQ0hXSU49bQpDT05GSUdf
VE9VQ0hTQ1JFRU5fVVNCX0NPTVBPU0lURT1tCkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfRUdBTEFY
PXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9QQU5KSVQ9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNC
XzNNPXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9JVE09eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNC
X0VUVVJCTz15CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfR1VOWkU9eQpDT05GSUdfVE9VQ0hTQ1JF
RU5fVVNCX0RNQ19UU0MxMD15CkNPTkZJR19UT1VDSFNDUkVFTl9VU0JfSVJUT1VDSD15CkNPTkZJ
R19UT1VDSFNDUkVFTl9VU0JfSURFQUxURUs9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0dFTkVS
QUxfVE9VQ0g9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0dPVE9QPXkKQ09ORklHX1RPVUNIU0NS
RUVOX1VTQl9KQVNURUM9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0UyST15CkNPTkZJR19UT1VD
SFNDUkVFTl9VU0JfWllUUk9OSUM9eQpDT05GSUdfVE9VQ0hTQ1JFRU5fVVNCX0VUVF9UQzQ1VVNC
PXkKQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9ORVhJTz15CkNPTkZJR19UT1VDSFNDUkVFTl9UT1VD
SElUMjEzPW0KQ09ORklHX1RPVUNIU0NSRUVOX1RTQzIwMDc9bQojIENPTkZJR19UT1VDSFNDUkVF
Tl9TVDEyMzIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UUFM2NTA3WCBpcyBub3Qg
c2V0CkNPTkZJR19JTlBVVF9NSVNDPXkKIyBDT05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5vdCBzZXQK
Q09ORklHX0lOUFVUX1BDU1BLUj1tCkNPTkZJR19JTlBVVF9BUEFORUw9bQpDT05GSUdfSU5QVVRf
QVRMQVNfQlROUz1tCkNPTkZJR19JTlBVVF9BVElfUkVNT1RFPW0KQ09ORklHX0lOUFVUX0FUSV9S
RU1PVEUyPW0KQ09ORklHX0lOUFVUX0tFWVNQQU5fUkVNT1RFPW0KQ09ORklHX0lOUFVUX1BPV0VS
TUFURT1tCkNPTkZJR19JTlBVVF9ZRUFMSU5LPW0KQ09ORklHX0lOUFVUX0NNMTA5PW0KQ09ORklH
X0lOUFVUX1VJTlBVVD1tCiMgQ09ORklHX0lOUFVUX1BDRjg1NzQgaXMgbm90IHNldAojIENPTkZJ
R19JTlBVVF9HUElPX1JPVEFSWV9FTkNPREVSIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQURY
TDM0WCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0NNQTMwMDAgaXMgbm90IHNldApDT05GSUdf
SU5QVVRfWEVOX0tCRERFVl9GUk9OVEVORD15CgojCiMgSGFyZHdhcmUgSS9PIHBvcnRzCiMKQ09O
RklHX1NFUklPPXkKQ09ORklHX1NFUklPX0k4MDQyPXkKQ09ORklHX1NFUklPX1NFUlBPUlQ9bQpD
T05GSUdfU0VSSU9fQ1Q4MkM3MTA9bQpDT05GSUdfU0VSSU9fUENJUFMyPW0KQ09ORklHX1NFUklP
X0xJQlBTMj15CkNPTkZJR19TRVJJT19SQVc9bQojIENPTkZJR19TRVJJT19BTFRFUkFfUFMyIGlz
IG5vdCBzZXQKIyBDT05GSUdfU0VSSU9fUFMyTVVMVCBpcyBub3Qgc2V0CkNPTkZJR19HQU1FUE9S
VD1tCkNPTkZJR19HQU1FUE9SVF9OUzU1OD1tCkNPTkZJR19HQU1FUE9SVF9MND1tCkNPTkZJR19H
QU1FUE9SVF9FTVUxMEsxPW0KQ09ORklHX0dBTUVQT1JUX0ZNODAxPW0KCiMKIyBDaGFyYWN0ZXIg
ZGV2aWNlcwojCkNPTkZJR19WVD15CkNPTkZJR19DT05TT0xFX1RSQU5TTEFUSU9OUz15CkNPTkZJ
R19WVF9DT05TT0xFPXkKQ09ORklHX0hXX0NPTlNPTEU9eQpDT05GSUdfVlRfSFdfQ09OU09MRV9C
SU5ESU5HPXkKQ09ORklHX1VOSVg5OF9QVFlTPXkKQ09ORklHX0RFVlBUU19NVUxUSVBMRV9JTlNU
QU5DRVM9eQojIENPTkZJR19MRUdBQ1lfUFRZUyBpcyBub3Qgc2V0CkNPTkZJR19TRVJJQUxfTk9O
U1RBTkRBUkQ9eQojIENPTkZJR19ST0NLRVRQT1JUIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1lDTEFE
RVMgaXMgbm90IHNldAojIENPTkZJR19NT1hBX0lOVEVMTElPIGlzIG5vdCBzZXQKIyBDT05GSUdf
TU9YQV9TTUFSVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lOQ0xJTksgaXMgbm90IHNldAojIENP
TkZJR19TWU5DTElOS01QIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lOQ0xJTktfR1QgaXMgbm90IHNl
dAojIENPTkZJR19OT1pPTUkgaXMgbm90IHNldAojIENPTkZJR19JU0kgaXMgbm90IHNldAojIENP
TkZJR19OX0hETEMgaXMgbm90IHNldAojIENPTkZJR19OX0dTTSBpcyBub3Qgc2V0CiMgQ09ORklH
X1RSQUNFX1NJTksgaXMgbm90IHNldAojIENPTkZJR19ERVZLTUVNIGlzIG5vdCBzZXQKQ09ORklH
X1NUQUxEUlY9eQoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NFUklBTF84MjUwPXkKQ09O
RklHX1NFUklBTF84MjUwX0NPTlNPTEU9eQpDT05GSUdfRklYX0VBUkxZQ09OX01FTT15CkNPTkZJ
R19TRVJJQUxfODI1MF9QQ0k9eQpDT05GSUdfU0VSSUFMXzgyNTBfUE5QPXkKQ09ORklHX1NFUklB
TF84MjUwX05SX1VBUlRTPTMyCkNPTkZJR19TRVJJQUxfODI1MF9SVU5USU1FX1VBUlRTPTQKQ09O
RklHX1NFUklBTF84MjUwX0VYVEVOREVEPXkKQ09ORklHX1NFUklBTF84MjUwX01BTllfUE9SVFM9
eQpDT05GSUdfU0VSSUFMXzgyNTBfU0hBUkVfSVJRPXkKIyBDT05GSUdfU0VSSUFMXzgyNTBfREVU
RUNUX0lSUSBpcyBub3Qgc2V0CkNPTkZJR19TRVJJQUxfODI1MF9SU0E9eQoKIwojIE5vbi04MjUw
IHNlcmlhbCBwb3J0IHN1cHBvcnQKIwojIENPTkZJR19TRVJJQUxfTUZEX0hTVSBpcyBub3Qgc2V0
CkNPTkZJR19TRVJJQUxfQ09SRT15CkNPTkZJR19TRVJJQUxfQ09SRV9DT05TT0xFPXkKQ09ORklH
X0NPTlNPTEVfUE9MTD15CiMgQ09ORklHX1NFUklBTF9KU00gaXMgbm90IHNldAojIENPTkZJR19T
RVJJQUxfVElNQkVSREFMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9BTFRFUkFfSlRBR1VB
UlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfQUxURVJBX1VBUlQgaXMgbm90IHNldAojIENP
TkZJR19TRVJJQUxfUENIX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfWElMSU5YX1BT
X1VBUlQgaXMgbm90IHNldAojIENPTkZJR19UVFlfUFJJTlRLIGlzIG5vdCBzZXQKQ09ORklHX0hW
Q19EUklWRVI9eQpDT05GSUdfSFZDX0lSUT15CkNPTkZJR19IVkNfWEVOPXkKIyBDT05GSUdfSVBN
SV9IQU5ETEVSIGlzIG5vdCBzZXQKQ09ORklHX0hXX1JBTkRPTT1tCiMgQ09ORklHX0hXX1JBTkRP
TV9USU1FUklPTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfSFdfUkFORE9NX0lOVEVMIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSFdfUkFORE9NX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hXX1JBTkRPTV9W
SUEgaXMgbm90IHNldAojIENPTkZJR19OVlJBTSBpcyBub3Qgc2V0CiMgQ09ORklHX1IzOTY0IGlz
IG5vdCBzZXQKIyBDT05GSUdfQVBQTElDT00gaXMgbm90IHNldAojIENPTkZJR19NV0FWRSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1JBV19EUklWRVIgaXMgbm90IHNldApDT05GSUdfSFBFVD15CkNPTkZJ
R19IUEVUX01NQVA9eQojIENPTkZJR19IQU5HQ0hFQ0tfVElNRVIgaXMgbm90IHNldAojIENPTkZJ
R19UQ0dfVFBNIGlzIG5vdCBzZXQKIyBDT05GSUdfVEVMQ0xPQ0sgaXMgbm90IHNldApDT05GSUdf
REVWUE9SVD15CiMgQ09ORklHX1JBTU9PUFMgaXMgbm90IHNldApDT05GSUdfSTJDPW0KQ09ORklH
X0kyQ19CT0FSRElORk89eQpDT05GSUdfSTJDX0NPTVBBVD15CkNPTkZJR19JMkNfQ0hBUkRFVj1t
CiMgQ09ORklHX0kyQ19NVVggaXMgbm90IHNldApDT05GSUdfSTJDX0hFTFBFUl9BVVRPPXkKQ09O
RklHX0kyQ19TTUJVUz1tCkNPTkZJR19JMkNfQUxHT0JJVD1tCkNPTkZJR19JMkNfQUxHT1BDQT1t
CgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBzdXBwb3J0CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNvbnRy
b2xsZXIgZHJpdmVycwojCkNPTkZJR19JMkNfQUxJMTUzNT1tCkNPTkZJR19JMkNfQUxJMTU2Mz1t
CkNPTkZJR19JMkNfQUxJMTVYMz1tCkNPTkZJR19JMkNfQU1ENzU2PW0KQ09ORklHX0kyQ19BTUQ3
NTZfUzQ4ODI9bQpDT05GSUdfSTJDX0FNRDgxMTE9bQpDT05GSUdfSTJDX0k4MDE9bQpDT05GSUdf
STJDX0lTQ0g9bQpDT05GSUdfSTJDX1BJSVg0PW0KQ09ORklHX0kyQ19ORk9SQ0UyPW0KQ09ORklH
X0kyQ19ORk9SQ0UyX1M0OTg1PW0KQ09ORklHX0kyQ19TSVM1NTk1PW0KQ09ORklHX0kyQ19TSVM2
MzA9bQpDT05GSUdfSTJDX1NJUzk2WD1tCkNPTkZJR19JMkNfVklBPW0KQ09ORklHX0kyQ19WSUFQ
Uk89bQoKIwojIEFDUEkgZHJpdmVycwojCkNPTkZJR19JMkNfU0NNST1tCgojCiMgSTJDIHN5c3Rl
bSBidXMgZHJpdmVycyAobW9zdGx5IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05G
SUdfSTJDX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19JMkNfSU5URUxfTUlEIGlzIG5vdCBzZXQK
Q09ORklHX0kyQ19PQ09SRVM9bQpDT05GSUdfSTJDX1BDQV9QTEFURk9STT1tCiMgQ09ORklHX0ky
Q19QWEFfUENJIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19TSU1URUM9bQojIENPTkZJR19JMkNfWElM
SU5YIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0VHMjBUIGlzIG5vdCBzZXQKCiMKIyBFeHRlcm5h
bCBJMkMvU01CdXMgYWRhcHRlciBkcml2ZXJzCiMKIyBDT05GSUdfSTJDX0RJT0xBTl9VMkMgaXMg
bm90IHNldApDT05GSUdfSTJDX1BBUlBPUlRfTElHSFQ9bQpDT05GSUdfSTJDX1RBT1NfRVZNPW0K
Q09ORklHX0kyQ19USU5ZX1VTQj1tCgojCiMgT3RoZXIgSTJDL1NNQnVzIGJ1cyBkcml2ZXJzCiMK
Q09ORklHX0kyQ19TVFVCPW0KIyBDT05GSUdfSTJDX0RFQlVHX0NPUkUgaXMgbm90IHNldAojIENP
TkZJR19JMkNfREVCVUdfQUxHTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19CVVMgaXMg
bm90IHNldAojIENPTkZJR19TUEkgaXMgbm90IHNldAoKIwojIFBQUyBzdXBwb3J0CiMKQ09ORklH
X1BQUz1tCiMgQ09ORklHX1BQU19ERUJVRyBpcyBub3Qgc2V0CgojCiMgUFBTIGNsaWVudHMgc3Vw
cG9ydAojCiMgQ09ORklHX1BQU19DTElFTlRfS1RJTUVSIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBT
X0NMSUVOVF9MRElTQyBpcyBub3Qgc2V0CgojCiMgUFBTIGdlbmVyYXRvcnMgc3VwcG9ydAojCgoj
CiMgUFRQIGNsb2NrIHN1cHBvcnQKIwojIENPTkZJR19QVFBfMTU4OF9DTE9DSyBpcyBub3Qgc2V0
CkNPTkZJR19BUkNIX1dBTlRfT1BUSU9OQUxfR1BJT0xJQj15CkNPTkZJR19HUElPTElCPXkKIyBD
T05GSUdfREVCVUdfR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fU1lTRlMgaXMgbm90IHNl
dAoKIwojIE1lbW9yeSBtYXBwZWQgR1BJTyBkcml2ZXJzOgojCiMgQ09ORklHX0dQSU9fQkFTSUNf
TU1JTyBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fSVQ4NzYxRSBpcyBub3Qgc2V0CiMgQ09ORklH
X0dQSU9fU0NIIGlzIG5vdCBzZXQKCiMKIyBJMkMgR1BJTyBleHBhbmRlcnM6CiMKIyBDT05GSUdf
R1BJT19NQVg3MzAwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19NQVg3MzJYIGlzIG5vdCBzZXQK
IyBDT05GSUdfR1BJT19QQ0E5NTNYIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19QQ0Y4NTdYIGlz
IG5vdCBzZXQKIyBDT05GSUdfR1BJT19BRFA1NTg4IGlzIG5vdCBzZXQKCiMKIyBQQ0kgR1BJTyBl
eHBhbmRlcnM6CiMKIyBDT05GSUdfR1BJT19CVDhYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9f
TEFOR1dFTEwgaXMgbm90IHNldAojIENPTkZJR19HUElPX1BDSCBpcyBub3Qgc2V0CiMgQ09ORklH
X0dQSU9fTUxfSU9IIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19SREMzMjFYIGlzIG5vdCBzZXQK
CiMKIyBTUEkgR1BJTyBleHBhbmRlcnM6CiMKCiMKIyBBQzk3IEdQSU8gZXhwYW5kZXJzOgojCgoj
CiMgTU9EVUxidXMgR1BJTyBleHBhbmRlcnM6CiMKIyBDT05GSUdfVzEgaXMgbm90IHNldApDT05G
SUdfUE9XRVJfU1VQUExZPXkKIyBDT05GSUdfUE9XRVJfU1VQUExZX0RFQlVHIGlzIG5vdCBzZXQK
Q09ORklHX1BEQV9QT1dFUj1tCiMgQ09ORklHX1RFU1RfUE9XRVIgaXMgbm90IHNldAojIENPTkZJ
R19CQVRURVJZX0RTMjc4MCBpcyBub3Qgc2V0CkNPTkZJR19CQVRURVJZX0RTMjc4Mj1tCiMgQ09O
RklHX0JBVFRFUllfQlEyMFo3NSBpcyBub3Qgc2V0CkNPTkZJR19CQVRURVJZX0JRMjd4MDA9bQpD
T05GSUdfQkFUVEVSWV9CUTI3WDAwX0kyQz15CkNPTkZJR19CQVRURVJZX0JRMjdYMDBfUExBVEZP
Uk09eQpDT05GSUdfQkFUVEVSWV9NQVgxNzA0MD1tCiMgQ09ORklHX0JBVFRFUllfTUFYMTcwNDIg
aXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX01BWDg5MDMgaXMgbm90IHNldAojIENPTkZJR19D
SEFSR0VSX0dQSU8gaXMgbm90IHNldApDT05GSUdfSFdNT049eQpDT05GSUdfSFdNT05fVklEPW0K
IyBDT05GSUdfSFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgTmF0aXZlIGRyaXZlcnMK
IwpDT05GSUdfU0VOU09SU19BQklUVUdVUlU9bQpDT05GSUdfU0VOU09SU19BQklUVUdVUlUzPW0K
Q09ORklHX1NFTlNPUlNfQUQ3NDE0PW0KQ09ORklHX1NFTlNPUlNfQUQ3NDE4PW0KQ09ORklHX1NF
TlNPUlNfQURNMTAyMT1tCkNPTkZJR19TRU5TT1JTX0FETTEwMjU9bQpDT05GSUdfU0VOU09SU19B
RE0xMDI2PW0KQ09ORklHX1NFTlNPUlNfQURNMTAyOT1tCkNPTkZJR19TRU5TT1JTX0FETTEwMzE9
bQpDT05GSUdfU0VOU09SU19BRE05MjQwPW0KIyBDT05GSUdfU0VOU09SU19BRFQ3NDExIGlzIG5v
dCBzZXQKQ09ORklHX1NFTlNPUlNfQURUNzQ2Mj1tCkNPTkZJR19TRU5TT1JTX0FEVDc0NzA9bQpD
T05GSUdfU0VOU09SU19BRFQ3NDc1PW0KIyBDT05GSUdfU0VOU09SU19BU0M3NjIxIGlzIG5vdCBz
ZXQKQ09ORklHX1NFTlNPUlNfSzhURU1QPW0KQ09ORklHX1NFTlNPUlNfSzEwVEVNUD1tCiMgQ09O
RklHX1NFTlNPUlNfRkFNMTVIX1BPV0VSIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfQVNCMTAw
PW0KQ09ORklHX1NFTlNPUlNfQVRYUDE9bQojIENPTkZJR19TRU5TT1JTX0RTNjIwIGlzIG5vdCBz
ZXQKQ09ORklHX1NFTlNPUlNfRFMxNjIxPW0KQ09ORklHX1NFTlNPUlNfSTVLX0FNQj1tCkNPTkZJ
R19TRU5TT1JTX0Y3MTgwNUY9bQpDT05GSUdfU0VOU09SU19GNzE4ODJGRz1tCkNPTkZJR19TRU5T
T1JTX0Y3NTM3NVM9bQpDT05GSUdfU0VOU09SU19GU0NITUQ9bQpDT05GSUdfU0VOU09SU19HNzYw
QT1tCkNPTkZJR19TRU5TT1JTX0dMNTE4U009bQpDT05GSUdfU0VOU09SU19HTDUyMFNNPW0KIyBD
T05GSUdfU0VOU09SU19HUElPX0ZBTiBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0NPUkVURU1Q
PW0KQ09ORklHX1NFTlNPUlNfSVQ4Nz1tCiMgQ09ORklHX1NFTlNPUlNfSkM0MiBpcyBub3Qgc2V0
CiMgQ09ORklHX1NFTlNPUlNfTElORUFHRSBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX0xNNjM9
bQojIENPTkZJR19TRU5TT1JTX0xNNzMgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19MTTc1PW0K
Q09ORklHX1NFTlNPUlNfTE03Nz1tCkNPTkZJR19TRU5TT1JTX0xNNzg9bQpDT05GSUdfU0VOU09S
U19MTTgwPW0KQ09ORklHX1NFTlNPUlNfTE04Mz1tCkNPTkZJR19TRU5TT1JTX0xNODU9bQpDT05G
SUdfU0VOU09SU19MTTg3PW0KQ09ORklHX1NFTlNPUlNfTE05MD1tCkNPTkZJR19TRU5TT1JTX0xN
OTI9bQpDT05GSUdfU0VOU09SU19MTTkzPW0KIyBDT05GSUdfU0VOU09SU19MVEM0MTUxIGlzIG5v
dCBzZXQKQ09ORklHX1NFTlNPUlNfTFRDNDIxNT1tCkNPTkZJR19TRU5TT1JTX0xUQzQyNDU9bQoj
IENPTkZJR19TRU5TT1JTX0xUQzQyNjEgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19MTTk1MjQx
PW0KIyBDT05GSUdfU0VOU09SU19NQVgxNjA2NSBpcyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX01B
WDE2MTk9bQojIENPTkZJR19TRU5TT1JTX01BWDY2MzkgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX01BWDY2NDIgaXMgbm90IHNldApDT05GSUdfU0VOU09SU19NQVg2NjUwPW0KQ09ORklHX1NF
TlNPUlNfUEM4NzM2MD1tCkNPTkZJR19TRU5TT1JTX1BDODc0Mjc9bQpDT05GSUdfU0VOU09SU19Q
Q0Y4NTkxPW0KIyBDT05GSUdfUE1CVVMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NIVDE1
IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TSFQyMSBpcyBub3Qgc2V0CkNPTkZJR19TRU5T
T1JTX1NJUzU1OTU9bQojIENPTkZJR19TRU5TT1JTX1NNTTY2NSBpcyBub3Qgc2V0CkNPTkZJR19T
RU5TT1JTX0RNRTE3Mzc9bQojIENPTkZJR19TRU5TT1JTX0VNQzE0MDMgaXMgbm90IHNldAojIENP
TkZJR19TRU5TT1JTX0VNQzIxMDMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0VNQzZXMjAx
IGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfU01TQzQ3TTE9bQpDT05GSUdfU0VOU09SU19TTVND
NDdNMTkyPW0KQ09ORklHX1NFTlNPUlNfU01TQzQ3QjM5Nz1tCiMgQ09ORklHX1NFTlNPUlNfU0NI
NTYyNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQURTMTAxNSBpcyBub3Qgc2V0CkNPTkZJ
R19TRU5TT1JTX0FEUzc4Mjg9bQojIENPTkZJR19TRU5TT1JTX0FNQzY4MjEgaXMgbm90IHNldApD
T05GSUdfU0VOU09SU19USE1DNTA9bQojIENPTkZJR19TRU5TT1JTX1RNUDEwMiBpcyBub3Qgc2V0
CkNPTkZJR19TRU5TT1JTX1RNUDQwMT1tCkNPTkZJR19TRU5TT1JTX1RNUDQyMT1tCkNPTkZJR19T
RU5TT1JTX1ZJQV9DUFVURU1QPW0KQ09ORklHX1NFTlNPUlNfVklBNjg2QT1tCkNPTkZJR19TRU5T
T1JTX1ZUMTIxMT1tCkNPTkZJR19TRU5TT1JTX1ZUODIzMT1tCkNPTkZJR19TRU5TT1JTX1c4Mzc4
MUQ9bQpDT05GSUdfU0VOU09SU19XODM3OTFEPW0KQ09ORklHX1NFTlNPUlNfVzgzNzkyRD1tCkNP
TkZJR19TRU5TT1JTX1c4Mzc5Mz1tCiMgQ09ORklHX1NFTlNPUlNfVzgzNzk1IGlzIG5vdCBzZXQK
Q09ORklHX1NFTlNPUlNfVzgzTDc4NVRTPW0KQ09ORklHX1NFTlNPUlNfVzgzTDc4Nk5HPW0KQ09O
RklHX1NFTlNPUlNfVzgzNjI3SEY9bQpDT05GSUdfU0VOU09SU19XODM2MjdFSEY9bQpDT05GSUdf
U0VOU09SU19BUFBMRVNNQz1tCgojCiMgQUNQSSBkcml2ZXJzCiMKIyBDT05GSUdfU0VOU09SU19B
Q1BJX1BPV0VSIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfQVRLMDExMD1tCkNPTkZJR19USEVS
TUFMPW0KQ09ORklHX1RIRVJNQUxfSFdNT049eQojIENPTkZJR19XQVRDSERPRyBpcyBub3Qgc2V0
CkNPTkZJR19TU0JfUE9TU0lCTEU9eQoKIwojIFNvbmljcyBTaWxpY29uIEJhY2twbGFuZQojCkNP
TkZJR19TU0I9bQpDT05GSUdfU1NCX1NQUk9NPXkKQ09ORklHX1NTQl9QQ0lIT1NUX1BPU1NJQkxF
PXkKQ09ORklHX1NTQl9QQ0lIT1NUPXkKIyBDT05GSUdfU1NCX0I0M19QQ0lfQlJJREdFIGlzIG5v
dCBzZXQKIyBDT05GSUdfU1NCX1NJTEVOVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NTQl9ERUJVRyBp
cyBub3Qgc2V0CkNPTkZJR19TU0JfRFJJVkVSX1BDSUNPUkVfUE9TU0lCTEU9eQpDT05GSUdfU1NC
X0RSSVZFUl9QQ0lDT1JFPXkKQ09ORklHX0JDTUFfUE9TU0lCTEU9eQoKIwojIEJyb2FkY29tIHNw
ZWNpZmljIEFNQkEKIwojIENPTkZJR19CQ01BIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1NVUFBP
UlQgaXMgbm90IHNldApDT05GSUdfTUZEX0NPUkU9bQpDT05GSUdfTFBDX1NDSD1tCiMgQ09ORklH
X1JFR1VMQVRPUiBpcyBub3Qgc2V0CiMgQ09ORklHX01FRElBX1NVUFBPUlQgaXMgbm90IHNldAoK
IwojIEdyYXBoaWNzIHN1cHBvcnQKIwpDT05GSUdfQUdQPXkKQ09ORklHX0FHUF9BTUQ2ND15CkNP
TkZJR19BR1BfSU5URUw9eQpDT05GSUdfQUdQX1NJUz15CkNPTkZJR19BR1BfVklBPXkKQ09ORklH
X1ZHQV9BUkI9eQpDT05GSUdfVkdBX0FSQl9NQVhfR1BVUz0xNgojIENPTkZJR19WR0FfU1dJVENI
RVJPTyBpcyBub3Qgc2V0CkNPTkZJR19EUk09bQpDT05GSUdfRFJNX0tNU19IRUxQRVI9bQpDT05G
SUdfRFJNX1RUTT1tCkNPTkZJR19EUk1fVERGWD1tCkNPTkZJR19EUk1fUjEyOD1tCkNPTkZJR19E
Uk1fUkFERU9OPW0KIyBDT05GSUdfRFJNX1JBREVPTl9LTVMgaXMgbm90IHNldApDT05GSUdfRFJN
X0k4MTA9bQpDT05GSUdfRFJNX0k5MTU9bQojIENPTkZJR19EUk1fSTkxNV9LTVMgaXMgbm90IHNl
dApDT05GSUdfRFJNX01HQT1tCkNPTkZJR19EUk1fU0lTPW0KQ09ORklHX0RSTV9WSUE9bQpDT05G
SUdfRFJNX1NBVkFHRT1tCiMgQ09ORklHX1NUVUJfUE9VTFNCTyBpcyBub3Qgc2V0CkNPTkZJR19W
R0FTVEFURT1tCkNPTkZJR19WSURFT19PVVRQVVRfQ09OVFJPTD1tCkNPTkZJR19GQj15CkNPTkZJ
R19GSVJNV0FSRV9FRElEPXkKQ09ORklHX0ZCX0REQz1tCkNPTkZJR19GQl9CT09UX1ZFU0FfU1VQ
UE9SVD15CkNPTkZJR19GQl9DRkJfRklMTFJFQ1Q9eQpDT05GSUdfRkJfQ0ZCX0NPUFlBUkVBPXkK
Q09ORklHX0ZCX0NGQl9JTUFHRUJMSVQ9eQojIENPTkZJR19GQl9DRkJfUkVWX1BJWEVMU19JTl9C
WVRFIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NZU19GSUxMUkVDVD15CkNPTkZJR19GQl9TWVNfQ09Q
WUFSRUE9eQpDT05GSUdfRkJfU1lTX0lNQUdFQkxJVD15CiMgQ09ORklHX0ZCX0ZPUkVJR05fRU5E
SUFOIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NZU19GT1BTPXkKIyBDT05GSUdfRkJfV01UX0dFX1JP
UFMgaXMgbm90IHNldApDT05GSUdfRkJfREVGRVJSRURfSU89eQpDT05GSUdfRkJfSEVDVUJBPW0K
Q09ORklHX0ZCX1NWR0FMSUI9bQojIENPTkZJR19GQl9NQUNNT0RFUyBpcyBub3Qgc2V0CkNPTkZJ
R19GQl9CQUNLTElHSFQ9eQpDT05GSUdfRkJfTU9ERV9IRUxQRVJTPXkKQ09ORklHX0ZCX1RJTEVC
TElUVElORz15CgojCiMgRnJhbWUgYnVmZmVyIGhhcmR3YXJlIGRyaXZlcnMKIwpDT05GSUdfRkJf
Q0lSUlVTPW0KQ09ORklHX0ZCX1BNMj1tCkNPTkZJR19GQl9QTTJfRklGT19ESVNDT05ORUNUPXkK
Q09ORklHX0ZCX0NZQkVSMjAwMD1tCkNPTkZJR19GQl9DWUJFUjIwMDBfRERDPXkKQ09ORklHX0ZC
X0FSQz1tCiMgQ09ORklHX0ZCX0FTSUxJQU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfSU1TVFQg
aXMgbm90IHNldApDT05GSUdfRkJfVkdBMTY9bQpDT05GSUdfRkJfVkVTQT15CkNPTkZJR19GQl9F
Rkk9eQpDT05GSUdfRkJfTjQxMT1tCkNPTkZJR19GQl9IR0E9bQpDT05GSUdfRkJfUzFEMTNYWFg9
bQpDT05GSUdfRkJfTlZJRElBPW0KIyBDT05GSUdfRkJfTlZJRElBX0kyQyBpcyBub3Qgc2V0CiMg
Q09ORklHX0ZCX05WSURJQV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GQl9OVklESUFfQkFDS0xJ
R0hUPXkKIyBDT05GSUdfRkJfUklWQSBpcyBub3Qgc2V0CkNPTkZJR19GQl9MRTgwNTc4PW0KQ09O
RklHX0ZCX0NBUklMTE9fUkFOQ0g9bQojIENPTkZJR19GQl9JTlRFTCBpcyBub3Qgc2V0CkNPTkZJ
R19GQl9NQVRST1g9bQpDT05GSUdfRkJfTUFUUk9YX01JTExFTklVTT15CkNPTkZJR19GQl9NQVRS
T1hfTVlTVElRVUU9eQpDT05GSUdfRkJfTUFUUk9YX0c9eQpDT05GSUdfRkJfTUFUUk9YX0kyQz1t
CkNPTkZJR19GQl9NQVRST1hfTUFWRU49bQpDT05GSUdfRkJfUkFERU9OPW0KQ09ORklHX0ZCX1JB
REVPTl9JMkM9eQpDT05GSUdfRkJfUkFERU9OX0JBQ0tMSUdIVD15CiMgQ09ORklHX0ZCX1JBREVP
Tl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19GQl9BVFkxMjg9bQpDT05GSUdfRkJfQVRZMTI4X0JB
Q0tMSUdIVD15CkNPTkZJR19GQl9BVFk9bQpDT05GSUdfRkJfQVRZX0NUPXkKIyBDT05GSUdfRkJf
QVRZX0dFTkVSSUNfTENEIGlzIG5vdCBzZXQKQ09ORklHX0ZCX0FUWV9HWD15CkNPTkZJR19GQl9B
VFlfQkFDS0xJR0hUPXkKQ09ORklHX0ZCX1MzPW0KQ09ORklHX0ZCX1MzX0REQz15CkNPTkZJR19G
Ql9TQVZBR0U9bQojIENPTkZJR19GQl9TQVZBR0VfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf
U0FWQUdFX0FDQ0VMIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NJUz1tCkNPTkZJR19GQl9TSVNfMzAw
PXkKQ09ORklHX0ZCX1NJU18zMTU9eQpDT05GSUdfRkJfVklBPW0KIyBDT05GSUdfRkJfVklBX0RJ
UkVDVF9QUk9DRlMgaXMgbm90IHNldAojIENPTkZJR19GQl9WSUFfWF9DT01QQVRJQklMSVRZIGlz
IG5vdCBzZXQKQ09ORklHX0ZCX05FT01BR0lDPW0KQ09ORklHX0ZCX0tZUk89bQpDT05GSUdfRkJf
M0RGWD1tCiMgQ09ORklHX0ZCXzNERlhfQUNDRUwgaXMgbm90IHNldApDT05GSUdfRkJfM0RGWF9J
MkM9eQpDT05GSUdfRkJfVk9PRE9PMT1tCkNPTkZJR19GQl9WVDg2MjM9bQpDT05GSUdfRkJfVFJJ
REVOVD1tCkNPTkZJR19GQl9BUks9bQpDT05GSUdfRkJfUE0zPW0KIyBDT05GSUdfRkJfQ0FSTUlO
RSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0dFT0RFIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfVE1J
TyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1VETCBpcyBub3Qgc2V0CkNPTkZJR19GQl9WSVJUVUFM
PW0KQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD15CkNPTkZJR19GQl9NRVRST05PTUU9bQpDT05G
SUdfRkJfTUI4NjJYWD1tCkNPTkZJR19GQl9NQjg2MlhYX1BDSV9HREM9eQpDT05GSUdfRkJfTUI4
NjJYWF9JMkM9eQojIENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKQ09ORklHX0JBQ0tM
SUdIVF9MQ0RfU1VQUE9SVD15CiMgQ09ORklHX0xDRF9DTEFTU19ERVZJQ0UgaXMgbm90IHNldApD
T05GSUdfQkFDS0xJR0hUX0NMQVNTX0RFVklDRT15CiMgQ09ORklHX0JBQ0tMSUdIVF9HRU5FUklD
IGlzIG5vdCBzZXQKQ09ORklHX0JBQ0tMSUdIVF9QUk9HRUFSPW0KIyBDT05GSUdfQkFDS0xJR0hU
X0FQUExFIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX1NBSEFSQSBpcyBub3Qgc2V0CiMg
Q09ORklHX0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0FE
UDg4NzAgaXMgbm90IHNldAoKIwojIERpc3BsYXkgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfRElT
UExBWV9TVVBQT1JUPW0KCiMKIyBEaXNwbGF5IGhhcmR3YXJlIGRyaXZlcnMKIwoKIwojIENvbnNv
bGUgZGlzcGxheSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CiMgQ09ORklH
X1ZHQUNPTl9TT0ZUX1NDUk9MTEJBQ0sgaXMgbm90IHNldApDT05GSUdfRFVNTVlfQ09OU09MRT15
CkNPTkZJR19GUkFNRUJVRkZFUl9DT05TT0xFPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNPTEVf
REVURUNUX1BSSU1BUlk9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRV9ST1RBVElPTj15CiMg
Q09ORklHX0ZPTlRTIGlzIG5vdCBzZXQKQ09ORklHX0ZPTlRfOHg4PXkKQ09ORklHX0ZPTlRfOHgx
Nj15CiMgQ09ORklHX0xPR08gaXMgbm90IHNldAojIENPTkZJR19TT1VORCBpcyBub3Qgc2V0CkNP
TkZJR19ISURfU1VQUE9SVD15CkNPTkZJR19ISUQ9bQpDT05GSUdfSElEUkFXPXkKCiMKIyBVU0Ig
SW5wdXQgRGV2aWNlcwojCkNPTkZJR19VU0JfSElEPW0KQ09ORklHX0hJRF9QSUQ9eQpDT05GSUdf
VVNCX0hJRERFVj15CgojCiMgVVNCIEhJRCBCb290IFByb3RvY29sIGRyaXZlcnMKIwojIENPTkZJ
R19VU0JfS0JEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01PVVNFIGlzIG5vdCBzZXQKCiMKIyBT
cGVjaWFsIEhJRCBkcml2ZXJzCiMKIyBDT05GSUdfSElEX0E0VEVDSCBpcyBub3Qgc2V0CiMgQ09O
RklHX0hJRF9BQ1JVWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9BUFBMRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0hJRF9CRUxLSU4gaXMgbm90IHNldAojIENPTkZJR19ISURfQ0hFUlJZIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSElEX0NISUNPTlkgaXMgbm90IHNldAojIENPTkZJR19ISURfQ1lQUkVTUyBp
cyBub3Qgc2V0CkNPTkZJR19ISURfRFJBR09OUklTRT1tCkNPTkZJR19EUkFHT05SSVNFX0ZGPXkK
IyBDT05GSUdfSElEX0VNU19GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9FWktFWSBpcyBub3Qg
c2V0CiMgQ09ORklHX0hJRF9LRVlUT1VDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9LWUUgaXMg
bm90IHNldAojIENPTkZJR19ISURfVUNMT0dJQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9XQUxU
T1AgaXMgbm90IHNldApDT05GSUdfSElEX0dZUkFUSU9OPW0KQ09ORklHX0hJRF9UV0lOSEFOPW0K
IyBDT05GSUdfSElEX0tFTlNJTkdUT04gaXMgbm90IHNldAojIENPTkZJR19ISURfTENQT1dFUiBp
cyBub3Qgc2V0CiMgQ09ORklHX0hJRF9MT0dJVEVDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9N
SUNST1NPRlQgaXMgbm90IHNldAojIENPTkZJR19ISURfTU9OVEVSRVkgaXMgbm90IHNldAojIENP
TkZJR19ISURfTVVMVElUT1VDSCBpcyBub3Qgc2V0CkNPTkZJR19ISURfTlRSSUc9bQojIENPTkZJ
R19ISURfT1JURUsgaXMgbm90IHNldApDT05GSUdfSElEX1BBTlRIRVJMT1JEPW0KQ09ORklHX1BB
TlRIRVJMT1JEX0ZGPXkKQ09ORklHX0hJRF9QRVRBTFlOWD1tCiMgQ09ORklHX0hJRF9QSUNPTENE
IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1FVQU5UQSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9S
T0NDQVQgaXMgbm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUX0FSVk8gaXMgbm90IHNldAojIENP
TkZJR19ISURfUk9DQ0FUX0tPTkUgaXMgbm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUX0tPTkVQ
TFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1JPQ0NBVF9LT1ZBUExVUyBpcyBub3Qgc2V0CiMg
Q09ORklHX0hJRF9ST0NDQVRfUFlSQSBpcyBub3Qgc2V0CkNPTkZJR19ISURfU0FNU1VORz1tCkNP
TkZJR19ISURfU09OWT1tCkNPTkZJR19ISURfU1VOUExVUz1tCkNPTkZJR19ISURfR1JFRU5BU0lB
PW0KQ09ORklHX0dSRUVOQVNJQV9GRj15CkNPTkZJR19ISURfU01BUlRKT1lQTFVTPW0KQ09ORklH
X1NNQVJUSk9ZUExVU19GRj15CkNPTkZJR19ISURfVE9QU0VFRD1tCkNPTkZJR19ISURfVEhSVVNU
TUFTVEVSPW0KQ09ORklHX1RIUlVTVE1BU1RFUl9GRj15CkNPTkZJR19ISURfWkVST1BMVVM9bQpD
T05GSUdfWkVST1BMVVNfRkY9eQojIENPTkZJR19ISURfWllEQUNST04gaXMgbm90IHNldApDT05G
SUdfVVNCX1NVUFBPUlQ9eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0JfQVJD
SF9IQVNfT0hDST15CkNPTkZJR19VU0JfQVJDSF9IQVNfRUhDST15CkNPTkZJR19VU0I9bQojIENP
TkZJR19VU0JfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19VU0JfQU5OT1VOQ0VfTkVXX0RFVklD
RVMgaXMgbm90IHNldAoKIwojIE1pc2NlbGxhbmVvdXMgVVNCIG9wdGlvbnMKIwojIENPTkZJR19V
U0JfREVWSUNFRlMgaXMgbm90IHNldAojIENPTkZJR19VU0JfREVWSUNFX0NMQVNTIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX0RZTkFNSUNfTUlOT1JTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NV
U1BFTkQgaXMgbm90IHNldAojIENPTkZJR19VU0JfT1RHX1dISVRFTElTVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9PVEdfQkxBQ0tMSVNUX0hVQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NT04g
aXMgbm90IHNldAojIENPTkZJR19VU0JfV1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9XVVNC
X0NCQUYgaXMgbm90IHNldAoKIwojIFVTQiBIb3N0IENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09O
RklHX1VTQl9DNjdYMDBfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1hIQ0lfSENEIGlzIG5v
dCBzZXQKIyBDT05GSUdfVVNCX0VIQ0lfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09YVTIx
MEhQX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMTZYX0hDRCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9JU1AxNzYwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMzYyX0hD
RCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PSENJX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9VSENJX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TTDgxMV9IQ0QgaXMgbm90IHNldAoj
IENPTkZJR19VU0JfUjhBNjY1OTdfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1dIQ0lfSENE
IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0hXQV9IQ0QgaXMgbm90IHNldAoKIwojIEVuYWJsZSBI
b3N0IG9yIEdhZGdldCBzdXBwb3J0IHRvIHNlZSBJbnZlbnRyYSBvcHRpb25zCiMKCiMKIyBVU0Ig
RGV2aWNlIENsYXNzIGRyaXZlcnMKIwojIENPTkZJR19VU0JfQUNNIGlzIG5vdCBzZXQKIyBDT05G
SUdfVVNCX1BSSU5URVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfV0RNIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX1RNQyBpcyBub3Qgc2V0CgojCiMgTk9URTogVVNCX1NUT1JBR0UgZGVwZW5kcyBv
biBTQ1NJIGJ1dCBCTEtfREVWX1NEIG1heQojCgojCiMgYWxzbyBiZSBuZWVkZWQ7IHNlZSBVU0Jf
U1RPUkFHRSBIZWxwIGZvciBtb3JlIGluZm8KIwojIENPTkZJR19VU0JfU1RPUkFHRSBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9VQVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfTElCVVNVQUwgaXMg
bm90IHNldAoKIwojIFVTQiBJbWFnaW5nIGRldmljZXMKIwojIENPTkZJR19VU0JfTURDODAwIGlz
IG5vdCBzZXQKIyBDT05GSUdfVVNCX01JQ1JPVEVLIGlzIG5vdCBzZXQKCiMKIyBVU0IgcG9ydCBk
cml2ZXJzCiMKIyBDT05GSUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxh
bmVvdXMgZHJpdmVycwojCiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VT
Ql9FTUkyNiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENPTkZJ
R19VU0JfU0VWU0VHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9MRUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENEIGlzIG5vdCBz
ZXQKIyBDT05GSUdfVVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVBSRVNTX0NZN0M2
MyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC
X0lETU9VU0UgaXMgbm90IHNldAojIENPTkZJR19VU0JfRlRESV9FTEFOIGlzIG5vdCBzZXQKIyBD
T05GSUdfVVNCX0FQUExFRElTUExBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MRCBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQl9UUkFOQ0VWSUJSQVRPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9J
T1dBUlJJT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklH
X1VTQl9JU0lHSFRGVyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ZVVJFWCBpcyBub3Qgc2V0CiMg
Q09ORklHX1VTQl9HQURHRVQgaXMgbm90IHNldAoKIwojIE9URyBhbmQgcmVsYXRlZCBpbmZyYXN0
cnVjdHVyZQojCiMgQ09ORklHX1VTQl9HUElPX1ZCVVMgaXMgbm90IHNldAojIENPTkZJR19OT1Bf
VVNCX1hDRUlWIGlzIG5vdCBzZXQKIyBDT05GSUdfVVdCIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1D
IGlzIG5vdCBzZXQKIyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9
eQpDT05GSUdfTEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURTX0xN
MzUzMCBpcyBub3Qgc2V0CkNPTkZJR19MRURTX0FMSVgyPW0KQ09ORklHX0xFRFNfUENBOTUzMj1t
CiMgQ09ORklHX0xFRFNfUENBOTUzMl9HUElPIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19HUElP
IGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfTFAzOTQ0PW0KIyBDT05GSUdfTEVEU19MUDU1MjEgaXMg
bm90IHNldAojIENPTkZJR19MRURTX0xQNTUyMyBpcyBub3Qgc2V0CkNPTkZJR19MRURTX0NMRVZP
X01BSUw9bQpDT05GSUdfTEVEU19QQ0E5NTVYPW0KQ09ORklHX0xFRFNfQkQyODAyPW0KIyBDT05G
SUdfTEVEU19JTlRFTF9TUzQyMDAgaXMgbm90IHNldAojIENPTkZJR19MRURTX0xUMzU5MyBpcyBu
b3Qgc2V0CiMgQ09ORklHX0xFRFNfREVMTF9ORVRCT09LUyBpcyBub3Qgc2V0CkNPTkZJR19MRURT
X1RSSUdHRVJTPXkKCiMKIyBMRUQgVHJpZ2dlcnMKIwpDT05GSUdfTEVEU19UUklHR0VSX1RJTUVS
PW0KQ09ORklHX0xFRFNfVFJJR0dFUl9IRUFSVEJFQVQ9bQpDT05GSUdfTEVEU19UUklHR0VSX0JB
Q0tMSUdIVD1tCiMgQ09ORklHX0xFRFNfVFJJR0dFUl9HUElPIGlzIG5vdCBzZXQKQ09ORklHX0xF
RFNfVFJJR0dFUl9ERUZBVUxUX09OPW0KCiMKIyBpcHRhYmxlcyB0cmlnZ2VyIGlzIHVuZGVyIE5l
dGZpbHRlciBjb25maWcgKExFRCB0YXJnZXQpCiMKIyBDT05GSUdfTkZDX0RFVklDRVMgaXMgbm90
IHNldAojIENPTkZJR19BQ0NFU1NJQklMSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5GSU5JQkFO
RCBpcyBub3Qgc2V0CkNPTkZJR19FREFDPXkKCiMKIyBSZXBvcnRpbmcgc3Vic3lzdGVtcwojCiMg
Q09ORklHX0VEQUNfREVCVUcgaXMgbm90IHNldApDT05GSUdfRURBQ19ERUNPREVfTUNFPW0KIyBD
T05GSUdfRURBQ19NQ0VfSU5KIGlzIG5vdCBzZXQKQ09ORklHX0VEQUNfTU1fRURBQz1tCiMgQ09O
RklHX0VEQUNfQU1ENjQgaXMgbm90IHNldApDT05GSUdfRURBQ19FNzUyWD1tCkNPTkZJR19FREFD
X0k4Mjk3NVg9bQpDT05GSUdfRURBQ19JMzAwMD1tCkNPTkZJR19FREFDX0kzMjAwPW0KQ09ORklH
X0VEQUNfWDM4PW0KQ09ORklHX0VEQUNfSTU0MDA9bQojIENPTkZJR19FREFDX0k3Q09SRSBpcyBu
b3Qgc2V0CkNPTkZJR19FREFDX0k1MDAwPW0KQ09ORklHX0VEQUNfSTUxMDA9bQojIENPTkZJR19F
REFDX0k3MzAwIGlzIG5vdCBzZXQKQ09ORklHX1JUQ19MSUI9eQpDT05GSUdfUlRDX0NMQVNTPXkK
Q09ORklHX1JUQ19IQ1RPU1lTPXkKQ09ORklHX1JUQ19IQ1RPU1lTX0RFVklDRT0icnRjMCIKIyBD
T05GSUdfUlRDX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBSVEMgaW50ZXJmYWNlcwojCkNPTkZJR19S
VENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9QUk9DPXkKQ09ORklHX1JUQ19JTlRGX0RF
Vj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVfRU1VTCBpcyBub3Qgc2V0CiMgQ09ORklHX1JU
Q19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMgSTJDIFJUQyBkcml2ZXJzCiMKIyBDT05GSUdfUlRD
X0RSVl9EUzEzMDcgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTM3NCBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfRFMxNjcyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzMy
MzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX01BWDY5MDAgaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX1JTNUMzNzIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0lTTDEyMDggaXMg
bm90IHNldAojIENPTkZJR19SVENfRFJWX0lTTDEyMDIyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD
X0RSVl9YMTIwNSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUENGODU2MyBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfUENGODU4MyBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQx
VDgwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9CUTMySyBpcyBub3Qgc2V0CiMgQ09ORklH
X1JUQ19EUlZfUzM1MzkwQSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRk0zMTMwIGlzIG5v
dCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SWDg1ODEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW
X1JYODAyNSBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRU0zMDI3IGlzIG5vdCBzZXQKIyBD
T05GSUdfUlRDX0RSVl9SVjMwMjlDMiBpcyBub3Qgc2V0CgojCiMgU1BJIFJUQyBkcml2ZXJzCiMK
CiMKIyBQbGF0Zm9ybSBSVEMgZHJpdmVycwojCiMgQ09ORklHX1JUQ19EUlZfQ01PUyBpcyBub3Qg
c2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMjg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9E
UzE1MTEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTU1MyBpcyBub3Qgc2V0CiMgQ09O
RklHX1JUQ19EUlZfRFMxNzQyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9TVEsxN1RBOCBp
cyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDg2IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD
X0RSVl9NNDhUMzUgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX000OFQ1OSBpcyBub3Qgc2V0
CiMgQ09ORklHX1JUQ19EUlZfTVNNNjI0MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfQlE0
ODAyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9SUDVDMDEgaXMgbm90IHNldAojIENPTkZJ
R19SVENfRFJWX1YzMDIwIGlzIG5vdCBzZXQKCiMKIyBvbi1DUFUgUlRDIGRyaXZlcnMKIwojIENP
TkZJR19ETUFERVZJQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfQVVYRElTUExBWSBpcyBub3Qgc2V0
CkNPTkZJR19VSU89bQojIENPTkZJR19VSU9fQ0lGIGlzIG5vdCBzZXQKIyBDT05GSUdfVUlPX1BE
UlYgaXMgbm90IHNldAojIENPTkZJR19VSU9fUERSVl9HRU5JUlEgaXMgbm90IHNldAojIENPTkZJ
R19VSU9fQUVDIGlzIG5vdCBzZXQKIyBDT05GSUdfVUlPX1NFUkNPUzMgaXMgbm90IHNldAojIENP
TkZJR19VSU9fUENJX0dFTkVSSUMgaXMgbm90IHNldAojIENPTkZJR19VSU9fTkVUWCBpcyBub3Qg
c2V0CgojCiMgWGVuIGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX1hFTl9CQUxMT09OPXkKQ09ORklH
X1hFTl9TQ1JVQl9QQUdFUz15CkNPTkZJR19YRU5fREVWX0VWVENITj15CiMgQ09ORklHX1hFTl9C
QUNLRU5EIGlzIG5vdCBzZXQKQ09ORklHX1hFTkZTPXkKQ09ORklHX1hFTl9DT01QQVRfWEVORlM9
eQpDT05GSUdfWEVOX1NZU19IWVBFUlZJU09SPXkKQ09ORklHX1hFTl9YRU5CVVNfRlJPTlRFTkQ9
eQpDT05GSUdfWEVOX0dOVERFVj15CkNPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DPXkKQ09ORklH
X1hFTl9QTEFURk9STV9QQ0k9bQpDT05GSUdfU1dJT1RMQl9YRU49eQpDT05GSUdfU1RBR0lORz15
CiMgQ09ORklHX1NUQUxMSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNUQUxMSU9OIGlzIG5vdCBz
ZXQKIyBDT05GSUdfRElHSUVQQ0EgaXMgbm90IHNldAojIENPTkZJR19SSVNDT004IGlzIG5vdCBz
ZXQKIyBDT05GSUdfU1BFQ0lBTElYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09NUFVUT05FIGlzIG5v
dCBzZXQKIyBDT05GSUdfRVQxMzFYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xJQ09TUyBpcyBub3Qg
c2V0CiMgQ09ORklHX1VTQklQX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19FQ0hPIGlzIG5vdCBz
ZXQKIyBDT05GSUdfQlJDTVVUSUwgaXMgbm90IHNldAojIENPTkZJR19DT01FREkgaXMgbm90IHNl
dAojIENPTkZJR19BU1VTX09MRUQgaXMgbm90IHNldAojIENPTkZJR19SVFNfUFNUT1IgaXMgbm90
IHNldAojIENPTkZJR19SVFM1MTM5IGlzIG5vdCBzZXQKIyBDT05GSUdfVFJBTlpQT1JUIGlzIG5v
dCBzZXQKIyBDT05GSUdfUE9ITUVMRlMgaXMgbm90IHNldAojIENPTkZJR19JREVfUEhJU09OIGlz
IG5vdCBzZXQKIyBDT05GSUdfRFJNX1ZNV0dGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9OT1VW
RUFVIGlzIG5vdCBzZXQKCiMKIyBJMkMgZW5jb2RlciBvciBoZWxwZXIgY2hpcHMKIwpDT05GSUdf
RFJNX0kyQ19DSDcwMDY9bQojIENPTkZJR19EUk1fSTJDX1NJTDE2NCBpcyBub3Qgc2V0CiMgQ09O
RklHX0hZUEVSViBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNRV9CVVMgaXMgbm90IHNldAojIENPTkZJ
R19EWF9TRVAgaXMgbm90IHNldAojIENPTkZJR19JSU8gaXMgbm90IHNldAojIENPTkZJR19YVk1B
TExPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1pSQU0gaXMgbm90IHNldAojIENPTkZJR19GQl9TTTdY
WCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVNUQUxIRCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1hH
SSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElfUVVJQ0tTVEFSVCBpcyBub3Qgc2V0CkNPTkZJR19N
QUNIX05PX1dFU1RCUklER0U9eQojIENPTkZJR19VU0JfRU5FU1RPUkFHRSBpcyBub3Qgc2V0CiMg
Q09ORklHX0JDTV9XSU1BWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZUMTAwMCBpcyBub3Qgc2V0Cgoj
CiMgU3BlYWt1cCBjb25zb2xlIHNwZWVjaAojCkNPTkZJR19TUEVBS1VQPW0KQ09ORklHX1NQRUFL
VVBfU1lOVEhfQUNOVFNBPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhfQUNOVFBDPW0KQ09ORklHX1NQ
RUFLVVBfU1lOVEhfQVBPTExPPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhfQVVEUFRSPW0KQ09ORklH
X1NQRUFLVVBfU1lOVEhfQk5TPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhfREVDVExLPW0KQ09ORklH
X1NQRUFLVVBfU1lOVEhfREVDRVhUPW0KIyBDT05GSUdfU1BFQUtVUF9TWU5USF9ERUNQQyBpcyBu
b3Qgc2V0CkNPTkZJR19TUEVBS1VQX1NZTlRIX0RUTEs9bQpDT05GSUdfU1BFQUtVUF9TWU5USF9L
RVlQQz1tCkNPTkZJR19TUEVBS1VQX1NZTlRIX0xUTEs9bQpDT05GSUdfU1BFQUtVUF9TWU5USF9T
T0ZUPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhfU1BLT1VUPW0KQ09ORklHX1NQRUFLVVBfU1lOVEhf
VFhQUlQ9bQpDT05GSUdfU1BFQUtVUF9TWU5USF9EVU1NWT1tCiMgQ09ORklHX1RPVUNIU0NSRUVO
X0NMRUFSUEFEX1RNMTIxNyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1NZTkFQVElD
U19JMkNfUk1JNCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9QU0IgaXMgbm90IHNldAoKIwojIEFs
dGVyYSBGUEdBIGZpcm13YXJlIGRvd25sb2FkIG1vZHVsZQojCiMgQ09ORklHX0FMVEVSQV9TVEFQ
TCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOVEVMX01FSSBpcyBub3Qgc2V0CkNPTkZJR19YODZfUExB
VEZPUk1fREVWSUNFUz15CiMgQ09ORklHX0FDRVJfV01JIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNF
UkhERiBpcyBub3Qgc2V0CiMgQ09ORklHX0FTVVNfTEFQVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdf
REVMTF9XTUkgaXMgbm90IHNldAojIENPTkZJR19ERUxMX1dNSV9BSU8gaXMgbm90IHNldAojIENP
TkZJR19GVUpJVFNVX0xBUFRPUCBpcyBub3Qgc2V0CiMgQ09ORklHX0hQX0FDQ0VMIGlzIG5vdCBz
ZXQKIyBDT05GSUdfSFBfV01JIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFOQVNPTklDX0xBUFRPUCBp
cyBub3Qgc2V0CiMgQ09ORklHX1RISU5LUEFEX0FDUEkgaXMgbm90IHNldAojIENPTkZJR19TRU5T
T1JTX0hEQVBTIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5URUxfTUVOTE9XIGlzIG5vdCBzZXQKQ09O
RklHX0FDUElfV01JPW0KIyBDT05GSUdfTVNJX1dNSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FDUElf
QVNVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPUFNUQVJfTEFQVE9QIGlzIG5vdCBzZXQKIyBDT05G
SUdfQUNQSV9UT1NISUJBIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9TSElCQV9CVF9SRktJTEwgaXMg
bm90IHNldAojIENPTkZJR19BQ1BJX0NNUEMgaXMgbm90IHNldAojIENPTkZJR19JTlRFTF9JUFMg
aXMgbm90IHNldAojIENPTkZJR19JQk1fUlRMIGlzIG5vdCBzZXQKIyBDT05GSUdfWE8xNV9FQk9P
SyBpcyBub3Qgc2V0CiMgQ09ORklHX01YTV9XTUkgaXMgbm90IHNldAoKIwojIFVidW50dSBTdXBw
bGllZCBUaGlyZC1QYXJ0eSBEZXZpY2UgRHJpdmVycwojCiMgQ09ORklHX05ESVNXUkFQUEVSIGlz
IG5vdCBzZXQKIyBDT05GSUdfQVZFUkFURUNfNTEwMFAgaXMgbm90IHNldAojIENPTkZJR19QQUNL
QVJEQkVMTF9FNSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZTQU03NDAwIGlzIG5vdCBzZXQKIyBDT05G
SUdfT01OSUJPT0sgaXMgbm90IHNldAojIENPTkZJR19BVUZTX0ZTIGlzIG5vdCBzZXQKCiMKIyBG
aXJtd2FyZSBEcml2ZXJzCiMKIyBDT05GSUdfRUREIGlzIG5vdCBzZXQKQ09ORklHX0ZJUk1XQVJF
X01FTU1BUD15CiMgQ09ORklHX0VGSV9WQVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVMTF9SQlUg
aXMgbm90IHNldAojIENPTkZJR19EQ0RCQVMgaXMgbm90IHNldAojIENPTkZJR19ETUlJRCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RNSV9TWVNGUyBpcyBub3Qgc2V0CiMgQ09ORklHX0lTQ1NJX0lCRlRf
RklORCBpcyBub3Qgc2V0CiMgQ09ORklHX1NJR01BIGlzIG5vdCBzZXQKIyBDT05GSUdfR09PR0xF
X0ZJUk1XQVJFIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwpDT05GSUdfRVhUMl9GUz15
CkNPTkZJR19FWFQyX0ZTX1hBVFRSPXkKQ09ORklHX0VYVDJfRlNfUE9TSVhfQUNMPXkKQ09ORklH
X0VYVDJfRlNfU0VDVVJJVFk9eQojIENPTkZJR19FWFQyX0ZTX1hJUCBpcyBub3Qgc2V0CkNPTkZJ
R19FWFQzX0ZTPXkKQ09ORklHX0VYVDNfREVGQVVMVFNfVE9fT1JERVJFRD15CkNPTkZJR19FWFQz
X0ZTX1hBVFRSPXkKQ09ORklHX0VYVDNfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VYVDNfRlNfU0VD
VVJJVFk9eQpDT05GSUdfRVhUNF9GUz15CkNPTkZJR19FWFQ0X0ZTX1hBVFRSPXkKQ09ORklHX0VY
VDRfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VYVDRfRlNfU0VDVVJJVFk9eQojIENPTkZJR19FWFQ0
X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0pCRD15CiMgQ09ORklHX0pCRF9ERUJVRyBpcyBub3Qg
c2V0CkNPTkZJR19KQkQyPXkKIyBDT05GSUdfSkJEMl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19G
U19NQkNBQ0hFPXkKIyBDT05GSUdfUkVJU0VSRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19KRlNf
RlMgaXMgbm90IHNldAojIENPTkZJR19YRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19HRlMyX0ZT
IGlzIG5vdCBzZXQKIyBDT05GSUdfT0NGUzJfRlMgaXMgbm90IHNldAojIENPTkZJR19CVFJGU19G
UyBpcyBub3Qgc2V0CiMgQ09ORklHX05JTEZTMl9GUyBpcyBub3Qgc2V0CkNPTkZJR19GU19QT1NJ
WF9BQ0w9eQpDT05GSUdfRklMRV9MT0NLSU5HPXkKQ09ORklHX0ZTTk9USUZZPXkKQ09ORklHX0RO
T1RJRlk9eQpDT05GSUdfSU5PVElGWV9VU0VSPXkKIyBDT05GSUdfRkFOT1RJRlkgaXMgbm90IHNl
dApDT05GSUdfUVVPVEE9eQpDT05GSUdfUVVPVEFfTkVUTElOS19JTlRFUkZBQ0U9eQpDT05GSUdf
UFJJTlRfUVVPVEFfV0FSTklORz15CiMgQ09ORklHX1FVT1RBX0RFQlVHIGlzIG5vdCBzZXQKIyBD
T05GSUdfUUZNVF9WMSBpcyBub3Qgc2V0CiMgQ09ORklHX1FGTVRfVjIgaXMgbm90IHNldApDT05G
SUdfUVVPVEFDVEw9eQpDT05GSUdfUVVPVEFDVExfQ09NUEFUPXkKIyBDT05GSUdfQVVUT0ZTNF9G
UyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZVU0VfRlMgaXMgbm90IHNldAojIENPTkZJR19PVkVSTEFZ
RlNfRlMgaXMgbm90IHNldApDT05GSUdfR0VORVJJQ19BQ0w9eQoKIwojIENhY2hlcwojCkNPTkZJ
R19GU0NBQ0hFPW0KQ09ORklHX0ZTQ0FDSEVfU1RBVFM9eQojIENPTkZJR19GU0NBQ0hFX0hJU1RP
R1JBTSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZTQ0FDSEVfREVCVUcgaXMgbm90IHNldAojIENPTkZJ
R19GU0NBQ0hFX09CSkVDVF9MSVNUIGlzIG5vdCBzZXQKQ09ORklHX0NBQ0hFRklMRVM9bQojIENP
TkZJR19DQUNIRUZJTEVTX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FDSEVGSUxFU19ISVNU
T0dSQU0gaXMgbm90IHNldAoKIwojIENELVJPTS9EVkQgRmlsZXN5c3RlbXMKIwpDT05GSUdfSVNP
OTY2MF9GUz1tCkNPTkZJR19KT0xJRVQ9eQpDT05GSUdfWklTT0ZTPXkKQ09ORklHX1VERl9GUz1t
CkNPTkZJR19VREZfTkxTPXkKCiMKIyBET1MvRkFUL05UIEZpbGVzeXN0ZW1zCiMKQ09ORklHX0ZB
VF9GUz1tCkNPTkZJR19NU0RPU19GUz1tCkNPTkZJR19WRkFUX0ZTPW0KQ09ORklHX0ZBVF9ERUZB
VUxUX0NPREVQQUdFPTQzNwpDT05GSUdfRkFUX0RFRkFVTFRfSU9DSEFSU0VUPSJ1dGY4IgpDT05G
SUdfTlRGU19GUz1tCiMgQ09ORklHX05URlNfREVCVUcgaXMgbm90IHNldApDT05GSUdfTlRGU19S
Vz15CgojCiMgUHNldWRvIGZpbGVzeXN0ZW1zCiMKQ09ORklHX1BST0NfRlM9eQpDT05GSUdfUFJP
Q19LQ09SRT15CkNPTkZJR19QUk9DX1NZU0NUTD15CkNPTkZJR19QUk9DX1BBR0VfTU9OSVRPUj15
CkNPTkZJR19TWVNGUz15CkNPTkZJR19UTVBGUz15CkNPTkZJR19UTVBGU19QT1NJWF9BQ0w9eQpD
T05GSUdfVE1QRlNfWEFUVFI9eQpDT05GSUdfSFVHRVRMQkZTPXkKQ09ORklHX0hVR0VUTEJfUEFH
RT15CkNPTkZJR19DT05GSUdGU19GUz1tCkNPTkZJR19NSVNDX0ZJTEVTWVNURU1TPXkKIyBDT05G
SUdfQURGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0FGRlNfRlMgaXMgbm90IHNldAojIENPTkZJ
R19IRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19IRlNQTFVTX0ZTIGlzIG5vdCBzZXQKIyBDT05G
SUdfQkVGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklH
X0VGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0xPR0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JB
TUZTIGlzIG5vdCBzZXQKIyBDT05GSUdfU1FVQVNIRlMgaXMgbm90IHNldAojIENPTkZJR19WWEZT
X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlOSVhfRlMgaXMgbm90IHNldAojIENPTkZJR19PTUZT
X0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSFBGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1FOWDRG
U19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1JPTUZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfUFNU
T1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfU1lTVl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VGU19G
UyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVFdPUktfRklMRVNZU1RFTVMgaXMgbm90IHNldAoKIwoj
IFBhcnRpdGlvbiBUeXBlcwojCkNPTkZJR19QQVJUSVRJT05fQURWQU5DRUQ9eQpDT05GSUdfQUNP
Uk5fUEFSVElUSU9OPXkKIyBDT05GSUdfQUNPUk5fUEFSVElUSU9OX0NVTUFOQSBpcyBub3Qgc2V0
CiMgQ09ORklHX0FDT1JOX1BBUlRJVElPTl9FRVNPWCBpcyBub3Qgc2V0CkNPTkZJR19BQ09STl9Q
QVJUSVRJT05fSUNTPXkKIyBDT05GSUdfQUNPUk5fUEFSVElUSU9OX0FERlMgaXMgbm90IHNldAoj
IENPTkZJR19BQ09STl9QQVJUSVRJT05fUE9XRVJURUMgaXMgbm90IHNldApDT05GSUdfQUNPUk5f
UEFSVElUSU9OX1JJU0NJWD15CkNPTkZJR19PU0ZfUEFSVElUSU9OPXkKQ09ORklHX0FNSUdBX1BB
UlRJVElPTj15CkNPTkZJR19BVEFSSV9QQVJUSVRJT049eQpDT05GSUdfTUFDX1BBUlRJVElPTj15
CkNPTkZJR19NU0RPU19QQVJUSVRJT049eQpDT05GSUdfQlNEX0RJU0tMQUJFTD15CkNPTkZJR19N
SU5JWF9TVUJQQVJUSVRJT049eQpDT05GSUdfU09MQVJJU19YODZfUEFSVElUSU9OPXkKQ09ORklH
X1VOSVhXQVJFX0RJU0tMQUJFTD15CkNPTkZJR19MRE1fUEFSVElUSU9OPXkKIyBDT05GSUdfTERN
X0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX1NHSV9QQVJUSVRJT049eQpDT05GSUdfVUxUUklYX1BB
UlRJVElPTj15CkNPTkZJR19TVU5fUEFSVElUSU9OPXkKQ09ORklHX0tBUk1BX1BBUlRJVElPTj15
CkNPTkZJR19FRklfUEFSVElUSU9OPXkKIyBDT05GSUdfU1lTVjY4X1BBUlRJVElPTiBpcyBub3Qg
c2V0CkNPTkZJR19OTFM9eQpDT05GSUdfTkxTX0RFRkFVTFQ9InV0ZjgiCkNPTkZJR19OTFNfQ09E
RVBBR0VfNDM3PW0KQ09ORklHX05MU19DT0RFUEFHRV83Mzc9bQpDT05GSUdfTkxTX0NPREVQQUdF
Xzc3NT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODUwPW0KQ09ORklHX05MU19DT0RFUEFHRV84NTI9
bQpDT05GSUdfTkxTX0NPREVQQUdFXzg1NT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODU3PW0KQ09O
RklHX05MU19DT0RFUEFHRV84NjA9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2MT1tCkNPTkZJR19O
TFNfQ09ERVBBR0VfODYyPW0KQ09ORklHX05MU19DT0RFUEFHRV84NjM9bQpDT05GSUdfTkxTX0NP
REVQQUdFXzg2ND1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODY1PW0KQ09ORklHX05MU19DT0RFUEFH
RV84NjY9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2OT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfOTM2
PW0KQ09ORklHX05MU19DT0RFUEFHRV85NTA9bQpDT05GSUdfTkxTX0NPREVQQUdFXzkzMj1tCkNP
TkZJR19OTFNfQ09ERVBBR0VfOTQ5PW0KQ09ORklHX05MU19DT0RFUEFHRV84NzQ9bQpDT05GSUdf
TkxTX0lTTzg4NTlfOD1tCkNPTkZJR19OTFNfQ09ERVBBR0VfMTI1MD1tCkNPTkZJR19OTFNfQ09E
RVBBR0VfMTI1MT1tCkNPTkZJR19OTFNfQVNDSUk9bQpDT05GSUdfTkxTX0lTTzg4NTlfMT1tCkNP
TkZJR19OTFNfSVNPODg1OV8yPW0KQ09ORklHX05MU19JU084ODU5XzM9bQpDT05GSUdfTkxTX0lT
Tzg4NTlfND1tCkNPTkZJR19OTFNfSVNPODg1OV81PW0KQ09ORklHX05MU19JU084ODU5XzY9bQpD
T05GSUdfTkxTX0lTTzg4NTlfNz1tCkNPTkZJR19OTFNfSVNPODg1OV85PW0KQ09ORklHX05MU19J
U084ODU5XzEzPW0KQ09ORklHX05MU19JU084ODU5XzE0PW0KQ09ORklHX05MU19JU084ODU5XzE1
PW0KQ09ORklHX05MU19LT0k4X1I9bQpDT05GSUdfTkxTX0tPSThfVT1tCkNPTkZJR19OTFNfVVRG
OD1tCiMgQ09ORklHX0RMTSBpcyBub3Qgc2V0CgojCiMgS2VybmVsIGhhY2tpbmcKIwpDT05GSUdf
VFJBQ0VfSVJRRkxBR1NfU1VQUE9SVD15CkNPTkZJR19QUklOVEtfVElNRT15CkNPTkZJR19ERUZB
VUxUX01FU1NBR0VfTE9HTEVWRUw9NwpDT05GSUdfRU5BQkxFX1dBUk5fREVQUkVDQVRFRD15CkNP
TkZJR19FTkFCTEVfTVVTVF9DSEVDSz15CkNPTkZJR19GUkFNRV9XQVJOPTIwNDgKQ09ORklHX01B
R0lDX1NZU1JRPXkKQ09ORklHX1NUUklQX0FTTV9TWU1TPXkKQ09ORklHX1VOVVNFRF9TWU1CT0xT
PXkKQ09ORklHX0RFQlVHX0ZTPXkKIyBDT05GSUdfSEVBREVSU19DSEVDSyBpcyBub3Qgc2V0CiMg
Q09ORklHX0RFQlVHX1NFQ1RJT05fTUlTTUFUQ0ggaXMgbm90IHNldApDT05GSUdfREVCVUdfS0VS
TkVMPXkKQ09ORklHX0RFQlVHX1NISVJRPXkKIyBDT05GSUdfTE9DS1VQX0RFVEVDVE9SIGlzIG5v
dCBzZXQKIyBDT05GSUdfSEFSRExPQ0tVUF9ERVRFQ1RPUiBpcyBub3Qgc2V0CkNPTkZJR19ERVRF
Q1RfSFVOR19UQVNLPXkKQ09ORklHX0RFRkFVTFRfSFVOR19UQVNLX1RJTUVPVVQ9MTIwCiMgQ09O
RklHX0JPT1RQQVJBTV9IVU5HX1RBU0tfUEFOSUMgaXMgbm90IHNldApDT05GSUdfQk9PVFBBUkFN
X0hVTkdfVEFTS19QQU5JQ19WQUxVRT0wCkNPTkZJR19TQ0hFRF9ERUJVRz15CiMgQ09ORklHX1ND
SEVEU1RBVFMgaXMgbm90IHNldApDT05GSUdfVElNRVJfU1RBVFM9eQojIENPTkZJR19ERUJVR19P
QkpFQ1RTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xVQl9ERUJVR19PTiBpcyBub3Qgc2V0CiMgQ09O
RklHX1NMVUJfU1RBVFMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19SVF9NVVRFWEVTIGlzIG5v
dCBzZXQKIyBDT05GSUdfUlRfTVVURVhfVEVTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdf
U1BJTkxPQ0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19NVVRFWEVTIGlzIG5vdCBzZXQKIyBD
T05GSUdfREVCVUdfTE9DS19BTExPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1BST1ZFX0xPQ0tJTkcg
aXMgbm90IHNldAojIENPTkZJR19TUEFSU0VfUkNVX1BPSU5URVIgaXMgbm90IHNldAojIENPTkZJ
R19MT0NLX1NUQVQgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19TUElOTE9DS19TTEVFUCBpcyBu
b3Qgc2V0CiMgQ09ORklHX0RFQlVHX0xPQ0tJTkdfQVBJX1NFTEZURVNUUyBpcyBub3Qgc2V0CkNP
TkZJR19TVEFDS1RSQUNFPXkKIyBDT05GSUdfREVCVUdfU1RBQ0tfVVNBR0UgaXMgbm90IHNldAoj
IENPTkZJR19ERUJVR19LT0JKRUNUIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0JVR1ZFUkJPU0U9
eQpDT05GSUdfREVCVUdfSU5GTz15CiMgQ09ORklHX0RFQlVHX0lORk9fUkVEVUNFRCBpcyBub3Qg
c2V0CiMgQ09ORklHX0RFQlVHX1ZNIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVklSVFVBTCBp
cyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1dSSVRFQ09VTlQgaXMgbm90IHNldAojIENPTkZJR19E
RUJVR19NRU1PUllfSU5JVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0xJU1QgaXMgbm90IHNl
dAojIENPTkZJR19URVNUX0xJU1RfU09SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NHIGlz
IG5vdCBzZXQKIyBDT05GSUdfREVCVUdfTk9USUZJRVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVC
VUdfQ1JFREVOVElBTFMgaXMgbm90IHNldApDT05GSUdfQVJDSF9XQU5UX0ZSQU1FX1BPSU5URVJT
PXkKQ09ORklHX0ZSQU1FX1BPSU5URVI9eQojIENPTkZJR19CT09UX1BSSU5US19ERUxBWSBpcyBu
b3Qgc2V0CiMgQ09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMgbm90IHNldApDT05GSUdfUkNVX0NQ
VV9TVEFMTF9USU1FT1VUPTYwCkNPTkZJR19LUFJPQkVTX1NBTklUWV9URVNUPXkKIyBDT05GSUdf
QkFDS1RSQUNFX1NFTEZfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0JMT0NLX0VYVF9E
RVZUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfRk9SQ0VfV0VBS19QRVJfQ1BVIGlzIG5vdCBz
ZXQKIyBDT05GSUdfREVCVUdfUEVSX0NQVV9NQVBTIGlzIG5vdCBzZXQKIyBDT05GSUdfTEtEVE0g
aXMgbm90IHNldAojIENPTkZJR19DUFVfTk9USUZJRVJfRVJST1JfSU5KRUNUIGlzIG5vdCBzZXQK
IyBDT05GSUdfRkFVTFRfSU5KRUNUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfTEFURU5DWVRPUCBp
cyBub3Qgc2V0CkNPTkZJR19TWVNDVExfU1lTQ0FMTF9DSEVDSz15CiMgQ09ORklHX0RFQlVHX1BB
R0VBTExPQyBpcyBub3Qgc2V0CkNPTkZJR19VU0VSX1NUQUNLVFJBQ0VfU1VQUE9SVD15CkNPTkZJ
R19OT1BfVFJBQ0VSPXkKQ09ORklHX0hBVkVfRlRSQUNFX05NSV9FTlRFUj15CkNPTkZJR19IQVZF
X0ZVTkNUSU9OX1RSQUNFUj15CkNPTkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15CkNP
TkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX0ZQX1RFU1Q9eQpDT05GSUdfSEFWRV9GVU5DVElPTl9U
UkFDRV9NQ09VTlRfVEVTVD15CkNPTkZJR19IQVZFX0RZTkFNSUNfRlRSQUNFPXkKQ09ORklHX0hB
VkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFWRV9TWVNDQUxMX1RSQUNFUE9JTlRT
PXkKQ09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpDT05GSUdfUklOR19CVUZGRVI9eQpDT05G
SUdfRlRSQUNFX05NSV9FTlRFUj15CkNPTkZJR19FVkVOVF9UUkFDSU5HPXkKQ09ORklHX0VWRU5U
X1BPV0VSX1RSQUNJTkdfREVQUkVDQVRFRD15CkNPTkZJR19DT05URVhUX1NXSVRDSF9UUkFDRVI9
eQpDT05GSUdfUklOR19CVUZGRVJfQUxMT1dfU1dBUD15CkNPTkZJR19UUkFDSU5HPXkKQ09ORklH
X0dFTkVSSUNfVFJBQ0VSPXkKQ09ORklHX1RSQUNJTkdfU1VQUE9SVD15CkNPTkZJR19GVFJBQ0U9
eQpDT05GSUdfRlVOQ1RJT05fVFJBQ0VSPXkKQ09ORklHX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15
CiMgQ09ORklHX0lSUVNPRkZfVFJBQ0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NIRURfVFJBQ0VS
IGlzIG5vdCBzZXQKQ09ORklHX0ZUUkFDRV9TWVNDQUxMUz15CkNPTkZJR19CUkFOQ0hfUFJPRklM
RV9OT05FPXkKIyBDT05GSUdfUFJPRklMRV9BTk5PVEFURURfQlJBTkNIRVMgaXMgbm90IHNldAoj
IENPTkZJR19QUk9GSUxFX0FMTF9CUkFOQ0hFUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NUQUNLX1RS
QUNFUiBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0lPX1RSQUNFPXkKQ09ORklHX0tQUk9CRV9F
VkVOVD15CkNPTkZJR19EWU5BTUlDX0ZUUkFDRT15CiMgQ09ORklHX0ZVTkNUSU9OX1BST0ZJTEVS
IGlzIG5vdCBzZXQKQ09ORklHX0ZUUkFDRV9NQ09VTlRfUkVDT1JEPXkKIyBDT05GSUdfRlRSQUNF
X1NUQVJUVVBfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX01NSU9UUkFDRSBpcyBub3Qgc2V0CiMg
Q09ORklHX1JJTkdfQlVGRkVSX0JFTkNITUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX1BST1ZJREVf
T0hDSTEzOTRfRE1BX0lOSVQgaXMgbm90IHNldAojIENPTkZJR19GSVJFV0lSRV9PSENJX1JFTU9U
RV9ETUEgaXMgbm90IHNldApDT05GSUdfRFlOQU1JQ19ERUJVRz15CiMgQ09ORklHX0RNQV9BUElf
REVCVUcgaXMgbm90IHNldAojIENPTkZJR19BVE9NSUM2NF9TRUxGVEVTVCBpcyBub3Qgc2V0CiMg
Q09ORklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNIX0tHREI9eQpDT05GSUdf
S0dEQj15CkNPTkZJR19LR0RCX1NFUklBTF9DT05TT0xFPXkKQ09ORklHX0tHREJfVEVTVFM9eQpD
T05GSUdfS0dEQl9URVNUU19PTl9CT09UPXkKQ09ORklHX0tHREJfVEVTVFNfQk9PVF9TVFJJTkc9
IlYxRjEwMCIKQ09ORklHX0tHREJfTE9XX0xFVkVMX1RSQVA9eQojIENPTkZJR19LR0RCX0tEQiBp
cyBub3Qgc2V0CkNPTkZJR19IQVZFX0FSQ0hfS01FTUNIRUNLPXkKIyBDT05GSUdfVEVTVF9LU1RS
VE9YIGlzIG5vdCBzZXQKQ09ORklHX1NUUklDVF9ERVZNRU09eQpDT05GSUdfWDg2X1ZFUkJPU0Vf
Qk9PVFVQPXkKQ09ORklHX0VBUkxZX1BSSU5USz15CiMgQ09ORklHX0VBUkxZX1BSSU5US19EQkdQ
IGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU1RBQ0tPVkVSRkxPVyBpcyBub3Qgc2V0CiMgQ09O
RklHX1g4Nl9QVERVTVAgaXMgbm90IHNldApDT05GSUdfREVCVUdfUk9EQVRBPXkKIyBDT05GSUdf
REVCVUdfUk9EQVRBX1RFU1QgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19TRVRfTU9EVUxFX1JP
TlggaXMgbm90IHNldAojIENPTkZJR19ERUJVR19OWF9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdf
SU9NTVVfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19JT01NVV9TVFJFU1MgaXMgbm90IHNldApD
T05GSUdfSEFWRV9NTUlPVFJBQ0VfU1VQUE9SVD15CiMgQ09ORklHX1g4Nl9ERUNPREVSX1NFTEZU
RVNUIGlzIG5vdCBzZXQKQ09ORklHX0lPX0RFTEFZX1RZUEVfMFg4MD0wCkNPTkZJR19JT19ERUxB
WV9UWVBFXzBYRUQ9MQpDT05GSUdfSU9fREVMQVlfVFlQRV9VREVMQVk9MgpDT05GSUdfSU9fREVM
QVlfVFlQRV9OT05FPTMKQ09ORklHX0lPX0RFTEFZXzBYODA9eQojIENPTkZJR19JT19ERUxBWV8w
WEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU9fREVMQVlfVURFTEFZIGlzIG5vdCBzZXQKIyBDT05G
SUdfSU9fREVMQVlfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0lPX0RFTEFZX1RZUEU9
MApDT05GSUdfREVCVUdfQk9PVF9QQVJBTVM9eQojIENPTkZJR19DUEFfREVCVUcgaXMgbm90IHNl
dApDT05GSUdfT1BUSU1JWkVfSU5MSU5JTkc9eQojIENPTkZJR19ERUJVR19TVFJJQ1RfVVNFUl9D
T1BZX0NIRUNLUyBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1NFQ0NPTVBfRklMVEVSPXkKCiMKIyBT
ZWN1cml0eSBvcHRpb25zCiMKIyBDT05GSUdfS0VZUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VS
SVRZX0RNRVNHX1JFU1RSSUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VDQ09NUF9GSUxURVIgaXMg
bm90IHNldAojIENPTkZJR19TRUNVUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZRlMg
aXMgbm90IHNldAojIENPTkZJR19JTlRFTF9UWFQgaXMgbm90IHNldApDT05GSUdfREVGQVVMVF9T
RUNVUklUWV9EQUM9eQpDT05GSUdfREVGQVVMVF9TRUNVUklUWT0iIgpDT05GSUdfQ1JZUFRPPXkK
CiMKIyBDcnlwdG8gY29yZSBvciBoZWxwZXIKIwpDT05GSUdfQ1JZUFRPX0FMR0FQST15CkNPTkZJ
R19DUllQVE9fQUxHQVBJMj15CkNPTkZJR19DUllQVE9fQUVBRD1tCkNPTkZJR19DUllQVE9fQUVB
RDI9eQpDT05GSUdfQ1JZUFRPX0JMS0NJUEhFUj1tCkNPTkZJR19DUllQVE9fQkxLQ0lQSEVSMj15
CkNPTkZJR19DUllQVE9fSEFTSD15CkNPTkZJR19DUllQVE9fSEFTSDI9eQpDT05GSUdfQ1JZUFRP
X1JORz1tCkNPTkZJR19DUllQVE9fUk5HMj15CkNPTkZJR19DUllQVE9fUENPTVA9bQpDT05GSUdf
Q1JZUFRPX1BDT01QMj15CkNPTkZJR19DUllQVE9fTUFOQUdFUj15CkNPTkZJR19DUllQVE9fTUFO
QUdFUjI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVJfRElTQUJMRV9URVNUUz15CkNPTkZJR19DUllQ
VE9fR0YxMjhNVUw9bQpDT05GSUdfQ1JZUFRPX05VTEw9bQojIENPTkZJR19DUllQVE9fUENSWVBU
IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19XT1JLUVVFVUU9eQojIENPTkZJR19DUllQVE9fQ1JZ
UFREIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19BVVRIRU5DPW0KQ09ORklHX0NSWVBUT19URVNU
PW0KCiMKIyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gd2l0aCBBc3NvY2lhdGVkIERhdGEKIwpD
T05GSUdfQ1JZUFRPX0NDTT1tCkNPTkZJR19DUllQVE9fR0NNPW0KQ09ORklHX0NSWVBUT19TRVFJ
Vj1tCgojCiMgQmxvY2sgbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0NCQz1tCkNPTkZJR19DUllQVE9f
Q1RSPW0KQ09ORklHX0NSWVBUT19DVFM9bQpDT05GSUdfQ1JZUFRPX0VDQj1tCkNPTkZJR19DUllQ
VE9fTFJXPW0KQ09ORklHX0NSWVBUT19QQ0JDPW0KQ09ORklHX0NSWVBUT19YVFM9bQoKIwojIEhh
c2ggbW9kZXMKIwpDT05GSUdfQ1JZUFRPX0hNQUM9bQpDT05GSUdfQ1JZUFRPX1hDQkM9bQpDT05G
SUdfQ1JZUFRPX1ZNQUM9bQoKIwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPW0KQ09O
RklHX0NSWVBUT19DUkMzMkNfSU5URUw9bQpDT05GSUdfQ1JZUFRPX0dIQVNIPW0KQ09ORklHX0NS
WVBUT19NRDQ9bQpDT05GSUdfQ1JZUFRPX01ENT15CkNPTkZJR19DUllQVE9fTUlDSEFFTF9NSUM9
bQpDT05GSUdfQ1JZUFRPX1JNRDEyOD1tCkNPTkZJR19DUllQVE9fUk1EMTYwPW0KQ09ORklHX0NS
WVBUT19STUQyNTY9bQpDT05GSUdfQ1JZUFRPX1JNRDMyMD1tCkNPTkZJR19DUllQVE9fU0hBMT1t
CkNPTkZJR19DUllQVE9fU0hBMjU2PW0KQ09ORklHX0NSWVBUT19TSEE1MTI9bQpDT05GSUdfQ1JZ
UFRPX1RHUjE5Mj1tCkNPTkZJR19DUllQVE9fV1A1MTI9bQojIENPTkZJR19DUllQVE9fR0hBU0hf
Q0xNVUxfTklfSU5URUwgaXMgbm90IHNldAoKIwojIENpcGhlcnMKIwpDT05GSUdfQ1JZUFRPX0FF
Uz1tCiMgQ09ORklHX0NSWVBUT19BRVNfWDg2XzY0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRP
X0FFU19OSV9JTlRFTCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fQU5VQklTPW0KQ09ORklHX0NS
WVBUT19BUkM0PW0KQ09ORklHX0NSWVBUT19CTE9XRklTSD1tCkNPTkZJR19DUllQVE9fQ0FNRUxM
SUE9bQpDT05GSUdfQ1JZUFRPX0NBU1Q1PW0KQ09ORklHX0NSWVBUT19DQVNUNj1tCkNPTkZJR19D
UllQVE9fREVTPW0KQ09ORklHX0NSWVBUT19GQ1JZUFQ9bQpDT05GSUdfQ1JZUFRPX0tIQVpBRD1t
CkNPTkZJR19DUllQVE9fU0FMU0EyMD1tCiMgQ09ORklHX0NSWVBUT19TQUxTQTIwX1g4Nl82NCBp
cyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0VFRD1tCkNPTkZJR19DUllQVE9fU0VSUEVOVD1tCkNP
TkZJR19DUllQVE9fVEVBPW0KQ09ORklHX0NSWVBUT19UV09GSVNIPW0KQ09ORklHX0NSWVBUT19U
V09GSVNIX0NPTU1PTj1tCiMgQ09ORklHX0NSWVBUT19UV09GSVNIX1g4Nl82NCBpcyBub3Qgc2V0
CgojCiMgQ29tcHJlc3Npb24KIwpDT05GSUdfQ1JZUFRPX0RFRkxBVEU9bQpDT05GSUdfQ1JZUFRP
X1pMSUI9bQpDT05GSUdfQ1JZUFRPX0xaTz1tCgojCiMgUmFuZG9tIE51bWJlciBHZW5lcmF0aW9u
CiMKQ09ORklHX0NSWVBUT19BTlNJX0NQUk5HPW0KIyBDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX0hB
U0ggaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fVVNFUl9BUElfU0tDSVBIRVIgaXMgbm90IHNl
dApDT05GSUdfQ1JZUFRPX0hXPXkKQ09ORklHX0NSWVBUT19ERVZfUEFETE9DSz1tCkNPTkZJR19D
UllQVE9fREVWX1BBRExPQ0tfQUVTPW0KQ09ORklHX0NSWVBUT19ERVZfUEFETE9DS19TSEE9bQpD
T05GSUdfQ1JZUFRPX0RFVl9ISUZOXzc5NVg9bQpDT05GSUdfQ1JZUFRPX0RFVl9ISUZOXzc5NVhf
Uk5HPXkKQ09ORklHX0hBVkVfS1ZNPXkKQ09ORklHX1ZJUlRVQUxJWkFUSU9OPXkKIyBDT05GSUdf
S1ZNIGlzIG5vdCBzZXQKIyBDT05GSUdfVkhPU1RfTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfVklS
VElPX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJUlRJT19CQUxMT09OIGlzIG5vdCBzZXQKQ09O
RklHX0JJTkFSWV9QUklOVEY9eQoKIwojIExpYnJhcnkgcm91dGluZXMKIwpDT05GSUdfQklUUkVW
RVJTRT15CkNPTkZJR19HRU5FUklDX0ZJTkRfRklSU1RfQklUPXkKQ09ORklHX0NSQ19DQ0lUVD1t
CkNPTkZJR19DUkMxNj15CkNPTkZJR19DUkNfVDEwRElGPW0KQ09ORklHX0NSQ19JVFVfVD1tCkNP
TkZJR19DUkMzMj15CkNPTkZJR19DUkM3PW0KQ09ORklHX0xJQkNSQzMyQz1tCkNPTkZJR19aTElC
X0lORkxBVEU9eQpDT05GSUdfWkxJQl9ERUZMQVRFPW0KQ09ORklHX0xaT19DT01QUkVTUz15CkNP
TkZJR19MWk9fREVDT01QUkVTUz15CkNPTkZJR19YWl9ERUM9eQpDT05GSUdfWFpfREVDX1g4Nj15
CkNPTkZJR19YWl9ERUNfUE9XRVJQQz15CkNPTkZJR19YWl9ERUNfSUE2ND15CkNPTkZJR19YWl9E
RUNfQVJNPXkKQ09ORklHX1haX0RFQ19BUk1USFVNQj15CkNPTkZJR19YWl9ERUNfU1BBUkM9eQpD
T05GSUdfWFpfREVDX0JDSj15CiMgQ09ORklHX1haX0RFQ19URVNUIGlzIG5vdCBzZXQKQ09ORklH
X0RFQ09NUFJFU1NfR1pJUD15CkNPTkZJR19URVhUU0VBUkNIPXkKQ09ORklHX1RFWFRTRUFSQ0hf
S01QPW0KQ09ORklHX1RFWFRTRUFSQ0hfQk09bQpDT05GSUdfVEVYVFNFQVJDSF9GU009bQpDT05G
SUdfSEFTX0lPTUVNPXkKQ09ORklHX0hBU19JT1BPUlQ9eQpDT05GSUdfSEFTX0RNQT15CkNPTkZJ
R19DSEVDS19TSUdOQVRVUkU9eQpDT05GSUdfQ1BVX1JNQVA9eQpDT05GSUdfTkxBVFRSPXkKQ09O
RklHX0FWRVJBR0U9eQo=
--e89a8f23505b701ae504b7be9eb0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--e89a8f23505b701ae504b7be9eb0--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 13:48:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 13: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 1Rrra1-0005A3-1a; Mon, 30 Jan 2012 13:47:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RrrZy-00059w-VX
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 13:47:31 +0000
Received: from [85.158.138.51:24872] by server-11.bemta-3.messagelabs.com id
	7C/94-26051-27F962F4; Mon, 30 Jan 2012 13:47:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327931247!11082157!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13300 invoked from network); 30 Jan 2012 13:47: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; 30 Jan 2012 13:47:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 13:47:26 +0000
Message-Id: <4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 13:47:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
In-Reply-To: <1327596896.24345.66.camel@elijah>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE2CC867C.3__="
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE2CC867C.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
>> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> =
wrote:
>> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> =
wrote:
>> >> x86's vMCE implementation lets a guest know of as many MCE reporting
>> >> banks as there are in the host. While a PV guest could be expected =
to
>> >> deal with this number changing (particularly decreasing) during =
migration
>> >> (not currently handled anywhere afaict), for HVM guests this is =
certainly
>> >> wrong.
>> >>
>> >> At least to me it isn't, however, clear how to properly handle this. =
The
>> >> easiest would appear to be to save and restore the number of banks
>> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
>> >> silently tolerate accesses between the host and guest values.
>> >=20
>> > We ran into this in the XS 6.0 release as well.  I think that the
>> > ideal thing to do would be to have a parameter that can be set at
>> > boot, to say how many vMCE banks a guest has, defaulting to the =
number
>> > of MCE banks on the host.  This parameter would be preserved across
>> > migration.  Ideally, a pool-aware toolstack like xapi would then set
>> > this value to be the value of the host in the pool with the largest
>> > number of banks, allowing a guest to access all the banks on any host
>> > to which it migrates.
>> >=20
>> > What do you think?
>>=20
>> That sounds like the way to go.
>=20
> So should we put this on IanC's to-do-be-done list?  Are you going to
> put it on your to-do list? :-)

Below/attached a draft patch (compile tested only), handling save/
restore of the bank count, but not allowing for a config setting to
specify its initial value (yet).

Jan

--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
=20
         domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;
         domctl.domain =3D dom;
+        memset(&domctl.u, 0, sizeof(domctl.u));
         domctl.u.ext_vcpucontext.vcpu =3D i;
         if ( xc_domctl(xch, &domctl) < 0 )
         {
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
            (unsigned long long) p.apic_assist);          =20
 }
=20
+static void dump_vmce_vcpu(void)
+{
+    HVM_SAVE_TYPE(VMCE_VCPU) p;
+    READ(p);
+    printf("    VMCE_VCPU: nr_banks %u\n", p.nr_banks);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -449,6 +456,7 @@ int main(int argc, char **argv)
         case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
         case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); =
break;
         case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;
+        case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -3,6 +3,7 @@
 #define _MCE_H
=20
 #include <xen/init.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <asm/types.h>
 #include <asm/traps.h>
@@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
 u64 mce_cap_init(void);
 extern int firstbank;
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
-int intel_mce_wrmsr(uint32_t msr, uint64_t val);
+int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
=20
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
=20
-static inline int mce_vendor_bank_msr(uint32_t msr)
+static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&
-         msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks) )
+         msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
           return 1;
     return 0;
 }
=20
-static inline int mce_bank_msr(uint32_t msr)
+static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( (msr >=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks=
)) ||
-        mce_vendor_bank_msr(msr) )
+    if ( (msr >=3D MSR_IA32_MC0_CTL &&
+          msr < MSR_IA32_MCx_CTL(v->arch.nr_vmce_banks)) ||
+         mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
 }
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
 }
=20
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(uint32_t msr, uint64_t val)
+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not write this MSR!\n");
@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
     return ret;
 }
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
+int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not read this MSR!\n");
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -10,6 +10,7 @@
 #include <xen/delay.h>
 #include <xen/smp.h>
 #include <xen/mm.h>
+#include <xen/hvm/save.h>
 #include <asm/processor.h>
 #include <public/sysctl.h>
 #include <asm/system.h>
@@ -61,21 +62,26 @@ void vmce_destroy_msr(struct domain *d)
     dom_vmce(d) =3D NULL;
 }
=20
-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t *val)
+void vmce_init_vcpu(struct vcpu *v)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    v->arch.nr_vmce_banks =3D nr_mce_banks;
+}
+
+static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*val)
+{
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -1;
+    *val =3D 0;
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        *val =3D vmce->mci_ctl[bank] &
-            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
+        if ( bank < nr_mce_banks )
+            *val =3D vmce->mci_ctl[bank] &
+                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
                    bank, *val);
         break;
@@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_rdmsr(msr, val);
+            ret =3D intel_mce_rdmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -145,13 +151,13 @@ static int bank_mce_rdmsr(struct domain=20
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    struct domain *d =3D current->domain;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    const struct vcpu *cur =3D current;
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&dom_vmce(d)->lock);
+    spin_lock(&vmce->lock);
=20
     switch ( msr )
     {
@@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
                    *val);
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : =
0;
         break;
     }
=20
-    spin_unlock(&dom_vmce(d)->lock);
+    spin_unlock(&vmce->lock);
     return ret;
 }
=20
-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry =3D NULL;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -EINVAL;
-
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        vmce->mci_ctl[bank] =3D val;
+        if ( bank < nr_mce_banks )
+            vmce->mci_ctl[bank] =3D val;
         break;
     case MSR_IA32_MC0_STATUS:
         /* Give the first entry of the list, it corresponds to current
@@ -202,9 +206,9 @@ static int bank_mce_wrmsr(struct domain=20
          * the guest, this node will be deleted.
          * Only error bank is written. Non-error banks simply return.
          */
-        if ( !list_empty(&dom_vmce(d)->impact_header) )
+        if ( !list_empty(&vmce->impact_header) )
         {
-            entry =3D list_entry(dom_vmce(d)->impact_header.next,
+            entry =3D list_entry(vmce->impact_header.next,
                                struct bank_entry, list);
             if ( entry->bank =3D=3D bank )
                 entry->mci_status =3D val;
@@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_wrmsr(msr, val);
+            ret =3D intel_mce_wrmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -247,9 +251,9 @@ static int bank_mce_wrmsr(struct domain=20
  */
 int vmce_wrmsr(u32 msr, u64 val)
 {
-    struct domain *d =3D current->domain;
+    struct vcpu *cur =3D current;
     struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     if ( !g_mcg_cap )
@@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         vmce->mcg_status =3D val;
         mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);
         /* For HVM guest, this is the point for deleting vMCE injection =
node */
-        if ( d->is_hvm && (vmce->nr_injection > 0) )
+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
         {
             vmce->nr_injection--; /* Should be 0 */
             if ( !list_empty(&vmce->impact_header) )
@@ -293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         ret =3D -1;
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : =
0;
         break;
     }
=20
@@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)
     return ret;
 }
=20
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ) {
+        struct hvm_vmce_vcpu ctxt =3D {
+            .nr_banks =3D v->arch.nr_vmce_banks
+        };
+
+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_vmce_vcpu ctxt;
+    int err;
+
+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
+    {
+        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        return -EINVAL;
+    }
+
+    err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+    if ( !err )
+        v->arch.nr_vmce_banks =3D ctxt.nr_banks;
+
+    return err;
+}
+
+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
 int inject_vmce(struct domain *d)
 {
     int cpu =3D smp_processor_id();
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)
=20
     v->arch.pv_vcpu.ctrlreg[4] =3D real_cr4_to_pv_guest_cr4(mmu_cr4_featur=
es);
=20
+    vmce_init_vcpu(v);
+
     rc =3D is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0;
  done:
     if ( rc )
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,11 +1027,12 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
+            evc->nr_mce_banks =3D v->arch.nr_vmce_banks;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size !=3D sizeof(*evc) )
+            if ( evc->size < offsetof(typeof(*evc), nr_mce_banks) )
                 goto ext_vcpucontext_out;
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
@@ -1059,6 +1060,16 @@ long arch_do_domctl(
                  (evc->syscall32_callback_cs & ~3) ||
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
+
+            if ( evc->size >=3D offsetof(typeof(*evc), mbz[ARRAY_SIZE(evc-=
>mbz)]) )
+            {
+                unsigned int i;
+
+                for ( i =3D 0; i < ARRAY_SIZE(evc->mbz); ++i )
+                    if ( evc->mbz[i] )
+                        goto ext_vcpucontext_out;
+                v->arch.nr_vmce_banks =3D evc->nr_mce_banks;
+            }
         }
=20
         ret =3D 0;
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -488,6 +488,8 @@ struct arch_vcpu
     /* This variable determines whether nonlazy extended state has been =
used,
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
+
+    uint8_t nr_vmce_banks;
    =20
     struct paging_vcpu paging;
=20
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -28,6 +28,7 @@ struct domain_mca_msrs
 /* Guest vMCE MSRs virtualization */
 extern int vmce_init_msr(struct domain *d);
 extern void vmce_destroy_msr(struct domain *d);
+extern void vmce_init_vcpu(struct vcpu *);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
=20
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context)=
;
=20
+struct hvm_vmce_vcpu {
+    uint8_t nr_banks;
+};
+
+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 17
+#define HVM_SAVE_CODE_MAX 18
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
     uint32_t         vcpu;
     /*
      * SET: Size of struct (IN)
-     * GET: Size of struct (OUT)
+     * GET: Size of struct (OUT, up to 128 bytes)
      */
     uint32_t         size;
 #if defined(__i386__) || defined(__x86_64__)
@@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucontext {
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
+    uint8_t          nr_mce_banks;
+    /* This array can be split and used for future extension. */
+    /* It is there just to grow the structure beyond 4.1's size. */
+    uint8_t          mbz[9];
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;


--=__PartE2CC867C.3__=
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-sr.patch"

--- a/tools/libxc/xc_domain_save.c=0A+++ b/tools/libxc/xc_domain_save.c=0A@=
@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in=0A =0A       =
  domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;=0A         domctl.domain =
=3D dom;=0A+        memset(&domctl.u, 0, sizeof(domctl.u));=0A         =
domctl.u.ext_vcpucontext.vcpu =3D i;=0A         if ( xc_domctl(xch, =
&domctl) < 0 )=0A         {=0A--- a/tools/misc/xen-hvmctx.c=0A+++ =
b/tools/misc/xen-hvmctx.c=0A@@ -383,6 +383,13 @@ static void dump_viridian_=
vcpu(void)=0A            (unsigned long long) p.apic_assist);           =
=0A }=0A =0A+static void dump_vmce_vcpu(void)=0A+{=0A+    HVM_SAVE_TYPE(VMC=
E_VCPU) p;=0A+    READ(p);=0A+    printf("    VMCE_VCPU: nr_banks %u\n", =
p.nr_banks);=0A+}=0A+=0A int main(int argc, char **argv)=0A {=0A     int =
entry, domid;=0A@@ -449,6 +456,7 @@ int main(int argc, char **argv)=0A     =
    case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;=0A         case =
HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); break;=0A         =
case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;=0A+        =
case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;=0A         case =
HVM_SAVE_CODE(END): break;=0A         default:=0A             printf(" ** =
Don't understand type %u: skipping\n",=0A--- a/xen/arch/x86/cpu/mcheck/mce.=
h=0A+++ b/xen/arch/x86/cpu/mcheck/mce.h=0A@@ -3,6 +3,7 @@=0A #define =
_MCE_H=0A =0A #include <xen/init.h>=0A+#include <xen/sched.h>=0A #include =
<xen/smp.h>=0A #include <asm/types.h>=0A #include <asm/traps.h>=0A@@ -54,8 =
+55,8 @@ int unmmap_broken_page(struct domain *d,=0A u64 mce_cap_init(void)=
;=0A extern int firstbank;=0A =0A-int intel_mce_rdmsr(uint32_t msr, =
uint64_t *val);=0A-int intel_mce_wrmsr(uint32_t msr, uint64_t val);=0A+int =
intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);=0A+int =
intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);=0A =0A struct =
mcinfo_extended *intel_get_extended_msrs(=0A     struct mcinfo_global =
*mig, struct mc_info *mi);=0A@@ -171,18 +172,20 @@ int vmce_domain_inject(s=
truct mcinfo_ban=0A =0A extern int vmce_init(struct cpuinfo_x86 *c);=0A =
=0A-static inline int mce_vendor_bank_msr(uint32_t msr)=0A+static inline =
int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)=0A {=0A     if =
( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&=0A-         msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks) )=0A+        =
 msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.=
nr_vmce_banks) )=0A           return 1;=0A     return 0;=0A }=0A =0A-static=
 inline int mce_bank_msr(uint32_t msr)=0A+static inline int mce_bank_msr(co=
nst struct vcpu *v, uint32_t msr)=0A {=0A-    if ( (msr >=3D MSR_IA32_MC0_C=
TL && msr < MSR_IA32_MCx_CTL(nr_mce_banks)) ||=0A-        mce_vendor_bank_m=
sr(msr) )=0A+    if ( (msr >=3D MSR_IA32_MC0_CTL &&=0A+          msr < =
MSR_IA32_MCx_CTL(v->arch.nr_vmce_banks)) ||=0A+         mce_vendor_bank_msr=
(v, msr) )=0A         return 1;=0A     return 0;=0A }=0A--- a/xen/arch/x86/=
cpu/mcheck/mce_intel.c=0A+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c=0A@@ =
-1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc=0A }=0A =0A =
/* intel specific MCA MSR */=0A-int intel_mce_wrmsr(uint32_t msr, uint64_t =
val)=0A+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)=0A =
{=0A     int ret =3D 0;=0A =0A-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < =
(MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( msr >=3D MSR_IA32_MC0_CTL2 =
&&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )=0A     =
{=0A         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "=0A =
                 "Guest should not write this MSR!\n");=0A@@ -1435,11 =
+1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64=0A     return ret;=0A =
}=0A =0A-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)=0A+int intel_mce_=
rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)=0A {=0A     int =
ret =3D 0;=0A =0A-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0=
_CTL2 + nr_mce_banks))=0A+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&=0A+       =
  msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )=0A     {=0A         =
mce_printk(MCE_QUIET, "We have disabled CMCI capability, "=0A              =
    "Guest should not read this MSR!\n");=0A--- a/xen/arch/x86/cpu/mcheck/v=
mce.c=0A+++ b/xen/arch/x86/cpu/mcheck/vmce.c=0A@@ -10,6 +10,7 @@=0A =
#include <xen/delay.h>=0A #include <xen/smp.h>=0A #include <xen/mm.h>=0A+#i=
nclude <xen/hvm/save.h>=0A #include <asm/processor.h>=0A #include =
<public/sysctl.h>=0A #include <asm/system.h>=0A@@ -61,21 +62,26 @@ void =
vmce_destroy_msr(struct domain *d)=0A     dom_vmce(d) =3D NULL;=0A }=0A =
=0A-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t =
*val)=0A+void vmce_init_vcpu(struct vcpu *v)=0A {=0A-    int bank, ret =3D =
1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    v->arch.nr_v=
mce_banks =3D nr_mce_banks;=0A+}=0A+=0A+static int bank_mce_rdmsr(const =
struct vcpu *v, uint32_t msr, uint64_t *val)=0A+{=0A+    int ret =3D =
1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     struct =
bank_entry *entry;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A-   =
 if ( bank >=3D nr_mce_banks )=0A-        return -1;=0A+    *val =3D 0;=0A =
=0A     switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A     case =
MSR_IA32_MC0_CTL:=0A-        *val =3D vmce->mci_ctl[bank] &=0A-            =
(h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);=0A+        if ( bank < nr_mce_banks=
 )=0A+            *val =3D vmce->mci_ctl[bank] &=0A+                   =
(h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);=0A         mce_printk(MCE_VERBOSE, =
"MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",=0A                    bank, *val);=0A =
        break;=0A@@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct =
domain =0A         switch ( boot_cpu_data.x86_vendor )=0A         {=0A     =
    case X86_VENDOR_INTEL:=0A-            ret =3D intel_mce_rdmsr(msr, =
val);=0A+            ret =3D intel_mce_rdmsr(v, msr, val);=0A             =
break;=0A         default:=0A             ret =3D 0;=0A@@ -145,13 +151,13 =
@@ static int bank_mce_rdmsr(struct domain =0A  */=0A int vmce_rdmsr(uint32=
_t msr, uint64_t *val)=0A {=0A-    struct domain *d =3D current->domain;=0A=
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    const struct =
vcpu *cur =3D current;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(cur=
->domain);=0A     int ret =3D 1;=0A =0A     *val =3D 0;=0A =0A-    =
spin_lock(&dom_vmce(d)->lock);=0A+    spin_lock(&vmce->lock);=0A =0A     =
switch ( msr )=0A     {=0A@@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t =
msr, uint64_t *v=0A                    *val);=0A         break;=0A     =
default:=0A-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, =
val) : 0;=0A+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, =
msr, val) : 0;=0A         break;=0A     }=0A =0A-    spin_unlock(&dom_vmce(=
d)->lock);=0A+    spin_unlock(&vmce->lock);=0A     return ret;=0A }=0A =
=0A-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)=0A+static=
 int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)=0A {=0A-    int =
bank, ret =3D 1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+  =
  int ret =3D 1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / =
4;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     =
struct bank_entry *entry =3D NULL;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_=
CTL) / 4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        return =
-EINVAL;=0A-=0A     switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A    =
 case MSR_IA32_MC0_CTL:=0A-        vmce->mci_ctl[bank] =3D val;=0A+        =
if ( bank < nr_mce_banks )=0A+            vmce->mci_ctl[bank] =3D val;=0A  =
       break;=0A     case MSR_IA32_MC0_STATUS:=0A         /* Give the =
first entry of the list, it corresponds to current=0A@@ -202,9 +206,9 @@ =
static int bank_mce_wrmsr(struct domain =0A          * the guest, this =
node will be deleted.=0A          * Only error bank is written. Non-error =
banks simply return.=0A          */=0A-        if ( !list_empty(&dom_vmce(d=
)->impact_header) )=0A+        if ( !list_empty(&vmce->impact_header) )=0A =
        {=0A-            entry =3D list_entry(dom_vmce(d)->impact_header.ne=
xt,=0A+            entry =3D list_entry(vmce->impact_header.next,=0A       =
                         struct bank_entry, list);=0A             if ( =
entry->bank =3D=3D bank )=0A                 entry->mci_status =3D =
val;=0A@@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain =0A     =
    switch ( boot_cpu_data.x86_vendor )=0A         {=0A         case =
X86_VENDOR_INTEL:=0A-            ret =3D intel_mce_wrmsr(msr, val);=0A+    =
        ret =3D intel_mce_wrmsr(v, msr, val);=0A             break;=0A     =
    default:=0A             ret =3D 0;=0A@@ -247,9 +251,9 @@ static int =
bank_mce_wrmsr(struct domain =0A  */=0A int vmce_wrmsr(u32 msr, u64 =
val)=0A {=0A-    struct domain *d =3D current->domain;=0A+    struct vcpu =
*cur =3D current;=0A     struct bank_entry *entry =3D NULL;=0A-    struct =
domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    struct domain_mca_msrs *vmce =
=3D dom_vmce(cur->domain);=0A     int ret =3D 1;=0A =0A     if ( !g_mcg_cap=
 )=0A@@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)=0A         =
vmce->mcg_status =3D val;=0A         mce_printk(MCE_VERBOSE, "MCE: wrmsr =
MCG_STATUS %"PRIx64"\n", val);=0A         /* For HVM guest, this is the =
point for deleting vMCE injection node */=0A-        if ( d->is_hvm && =
(vmce->nr_injection > 0) )=0A+        if ( is_hvm_vcpu(cur) && (vmce->nr_in=
jection > 0) )=0A         {=0A             vmce->nr_injection--; /* Should =
be 0 */=0A             if ( !list_empty(&vmce->impact_header) )=0A@@ =
-293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)=0A         ret =3D =
-1;=0A         break;=0A     default:=0A-        ret =3D mce_bank_msr(msr) =
? bank_mce_wrmsr(d, msr, val) : 0;=0A+        ret =3D mce_bank_msr(cur, =
msr) ? bank_mce_wrmsr(cur, msr, val) : 0;=0A         break;=0A     }=0A =
=0A@@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)=0A     return =
ret;=0A }=0A =0A+static int vmce_save_vcpu_ctxt(struct domain *d, =
hvm_domain_context_t *h)=0A+{=0A+    struct vcpu *v;=0A+    int err =3D =
0;=0A+=0A+    for_each_vcpu( d, v ) {=0A+        struct hvm_vmce_vcpu ctxt =
=3D {=0A+            .nr_banks =3D v->arch.nr_vmce_banks=0A+        =
};=0A+=0A+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, =
&ctxt);=0A+        if ( err )=0A+            break;=0A+    }=0A+=0A+    =
return err;=0A+}=0A+=0A+static int vmce_load_vcpu_ctxt(struct domain *d, =
hvm_domain_context_t *h)=0A+{=0A+    unsigned int vcpuid =3D hvm_load_insta=
nce(h);=0A+    struct vcpu *v;=0A+    struct hvm_vmce_vcpu ctxt;=0A+    =
int err;=0A+=0A+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]=
) =3D=3D NULL )=0A+    {=0A+        gdprintk(XENLOG_ERR, "HVM restore: =
domain has no vcpu %u\n", vcpuid);=0A+        return -EINVAL;=0A+    =
}=0A+=0A+    err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);=0A+    if ( !err =
)=0A+        v->arch.nr_vmce_banks =3D ctxt.nr_banks;=0A+=0A+    return =
err;=0A+}=0A+=0A+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,=
=0A+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);=0A+=
=0A int inject_vmce(struct domain *d)=0A {=0A     int cpu =3D smp_processor=
_id();=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=0A@@ =
-468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)=0A =0A     v->arch.pv_=
vcpu.ctrlreg[4] =3D real_cr4_to_pv_guest_cr4(mmu_cr4_features);=0A =0A+    =
vmce_init_vcpu(v);=0A+=0A     rc =3D is_pv_32on64_vcpu(v) ? setup_compat_l4=
(v) : 0;=0A  done:=0A     if ( rc )=0A--- a/xen/arch/x86/domctl.c=0A+++ =
b/xen/arch/x86/domctl.c=0A@@ -1027,11 +1027,12 @@ long arch_do_domctl(=0A  =
               evc->syscall32_callback_eip    =3D 0;=0A                 =
evc->syscall32_disables_events =3D 0;=0A             }=0A+            =
evc->nr_mce_banks =3D v->arch.nr_vmce_banks;=0A         }=0A         =
else=0A         {=0A             ret =3D -EINVAL;=0A-            if ( =
evc->size !=3D sizeof(*evc) )=0A+            if ( evc->size < offsetof(type=
of(*evc), nr_mce_banks) )=0A                 goto ext_vcpucontext_out;=0A =
#ifdef __x86_64__=0A             if ( !is_hvm_domain(d) )=0A@@ -1059,6 =
+1060,16 @@ long arch_do_domctl(=0A                  (evc->syscall32_callba=
ck_cs & ~3) ||=0A                  evc->syscall32_callback_eip )=0A        =
         goto ext_vcpucontext_out;=0A+=0A+            if ( evc->size >=3D =
offsetof(typeof(*evc), mbz[ARRAY_SIZE(evc->mbz)]) )=0A+            {=0A+   =
             unsigned int i;=0A+=0A+                for ( i =3D 0; i < =
ARRAY_SIZE(evc->mbz); ++i )=0A+                    if ( evc->mbz[i] )=0A+  =
                      goto ext_vcpucontext_out;=0A+                =
v->arch.nr_vmce_banks =3D evc->nr_mce_banks;=0A+            }=0A         =
}=0A =0A         ret =3D 0;=0A--- a/xen/include/asm-x86/domain.h=0A+++ =
b/xen/include/asm-x86/domain.h=0A@@ -488,6 +488,8 @@ struct arch_vcpu=0A   =
  /* This variable determines whether nonlazy extended state has been =
used,=0A      * and thus should be saved/restored. */=0A     bool_t =
nonlazy_xstate_used;=0A+=0A+    uint8_t nr_vmce_banks;=0A     =0A     =
struct paging_vcpu paging;=0A =0A--- a/xen/include/asm-x86/mce.h=0A+++ =
b/xen/include/asm-x86/mce.h=0A@@ -28,6 +28,7 @@ struct domain_mca_msrs=0A =
/* Guest vMCE MSRs virtualization */=0A extern int vmce_init_msr(struct =
domain *d);=0A extern void vmce_destroy_msr(struct domain *d);=0A+extern =
void vmce_init_vcpu(struct vcpu *);=0A extern int vmce_wrmsr(uint32_t msr, =
uint64_t val);=0A extern int vmce_rdmsr(uint32_t msr, uint64_t *val);=0A =
=0A--- a/xen/include/public/arch-x86/hvm/save.h=0A+++ b/xen/include/public/=
arch-x86/hvm/save.h=0A@@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context=
 {=0A =0A DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu=
_context);=0A =0A+struct hvm_vmce_vcpu {=0A+    uint8_t nr_banks;=0A+};=0A+=
=0A+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);=0A+=0A /* =
=0A  * Largest type-code in use=0A  */=0A-#define HVM_SAVE_CODE_MAX =
17=0A+#define HVM_SAVE_CODE_MAX 18=0A =0A #endif /* __XEN_PUBLIC_HVM_SAVE_X=
86_H__ */=0A--- a/xen/include/public/domctl.h=0A+++ b/xen/include/public/do=
mctl.h=0A@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {=0A     =
uint32_t         vcpu;=0A     /*=0A      * SET: Size of struct (IN)=0A-    =
 * GET: Size of struct (OUT)=0A+     * GET: Size of struct (OUT, up to 128 =
bytes)=0A      */=0A     uint32_t         size;=0A #if defined(__i386__) =
|| defined(__x86_64__)=0A@@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucon=
text {=0A     uint16_t         sysenter_callback_cs;=0A     uint8_t        =
  syscall32_disables_events;=0A     uint8_t          sysenter_disables_even=
ts;=0A+    uint8_t          nr_mce_banks;=0A+    /* This array can be =
split and used for future extension. */=0A+    /* It is there just to grow =
the structure beyond 4.1's size. */=0A+    uint8_t          mbz[9];=0A =
#endif=0A };=0A typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vc=
pucontext_t;=0A
--=__PartE2CC867C.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

--=__PartE2CC867C.3__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 13:48:22 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 13: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 1Rrra1-0005A3-1a; Mon, 30 Jan 2012 13:47:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RrrZy-00059w-VX
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 13:47:31 +0000
Received: from [85.158.138.51:24872] by server-11.bemta-3.messagelabs.com id
	7C/94-26051-27F962F4; Mon, 30 Jan 2012 13:47:30 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327931247!11082157!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13300 invoked from network); 30 Jan 2012 13:47: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; 30 Jan 2012 13:47:27 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 13:47:26 +0000
Message-Id: <4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 13:47:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
In-Reply-To: <1327596896.24345.66.camel@elijah>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__PartE2CC867C.3__="
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__PartE2CC867C.3__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
>> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> =
wrote:
>> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> =
wrote:
>> >> x86's vMCE implementation lets a guest know of as many MCE reporting
>> >> banks as there are in the host. While a PV guest could be expected =
to
>> >> deal with this number changing (particularly decreasing) during =
migration
>> >> (not currently handled anywhere afaict), for HVM guests this is =
certainly
>> >> wrong.
>> >>
>> >> At least to me it isn't, however, clear how to properly handle this. =
The
>> >> easiest would appear to be to save and restore the number of banks
>> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
>> >> silently tolerate accesses between the host and guest values.
>> >=20
>> > We ran into this in the XS 6.0 release as well.  I think that the
>> > ideal thing to do would be to have a parameter that can be set at
>> > boot, to say how many vMCE banks a guest has, defaulting to the =
number
>> > of MCE banks on the host.  This parameter would be preserved across
>> > migration.  Ideally, a pool-aware toolstack like xapi would then set
>> > this value to be the value of the host in the pool with the largest
>> > number of banks, allowing a guest to access all the banks on any host
>> > to which it migrates.
>> >=20
>> > What do you think?
>>=20
>> That sounds like the way to go.
>=20
> So should we put this on IanC's to-do-be-done list?  Are you going to
> put it on your to-do list? :-)

Below/attached a draft patch (compile tested only), handling save/
restore of the bank count, but not allowing for a config setting to
specify its initial value (yet).

Jan

--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in
=20
         domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;
         domctl.domain =3D dom;
+        memset(&domctl.u, 0, sizeof(domctl.u));
         domctl.u.ext_vcpucontext.vcpu =3D i;
         if ( xc_domctl(xch, &domctl) < 0 )
         {
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -383,6 +383,13 @@ static void dump_viridian_vcpu(void)
            (unsigned long long) p.apic_assist);          =20
 }
=20
+static void dump_vmce_vcpu(void)
+{
+    HVM_SAVE_TYPE(VMCE_VCPU) p;
+    READ(p);
+    printf("    VMCE_VCPU: nr_banks %u\n", p.nr_banks);
+}
+
 int main(int argc, char **argv)
 {
     int entry, domid;
@@ -449,6 +456,7 @@ int main(int argc, char **argv)
         case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;
         case HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); =
break;
         case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;
+        case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;
         case HVM_SAVE_CODE(END): break;
         default:
             printf(" ** Don't understand type %u: skipping\n",
--- a/xen/arch/x86/cpu/mcheck/mce.h
+++ b/xen/arch/x86/cpu/mcheck/mce.h
@@ -3,6 +3,7 @@
 #define _MCE_H
=20
 #include <xen/init.h>
+#include <xen/sched.h>
 #include <xen/smp.h>
 #include <asm/types.h>
 #include <asm/traps.h>
@@ -54,8 +55,8 @@ int unmmap_broken_page(struct domain *d,
 u64 mce_cap_init(void);
 extern int firstbank;
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val);
-int intel_mce_wrmsr(uint32_t msr, uint64_t val);
+int intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);
+int intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
=20
 struct mcinfo_extended *intel_get_extended_msrs(
     struct mcinfo_global *mig, struct mc_info *mi);
@@ -171,18 +172,20 @@ int vmce_domain_inject(struct mcinfo_ban
=20
 extern int vmce_init(struct cpuinfo_x86 *c);
=20
-static inline int mce_vendor_bank_msr(uint32_t msr)
+static inline int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)
 {
     if ( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&
-         msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks) )
+         msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
           return 1;
     return 0;
 }
=20
-static inline int mce_bank_msr(uint32_t msr)
+static inline int mce_bank_msr(const struct vcpu *v, uint32_t msr)
 {
-    if ( (msr >=3D MSR_IA32_MC0_CTL && msr < MSR_IA32_MCx_CTL(nr_mce_banks=
)) ||
-        mce_vendor_bank_msr(msr) )
+    if ( (msr >=3D MSR_IA32_MC0_CTL &&
+          msr < MSR_IA32_MCx_CTL(v->arch.nr_vmce_banks)) ||
+         mce_vendor_bank_msr(v, msr) )
         return 1;
     return 0;
 }
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc
 }
=20
 /* intel specific MCA MSR */
-int intel_mce_wrmsr(uint32_t msr, uint64_t val)
+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not write this MSR!\n");
@@ -1435,11 +1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64
     return ret;
 }
=20
-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)
+int intel_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
 {
     int ret =3D 0;
=20
-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + =
nr_mce_banks))
+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&
+         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )
     {
         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "
                  "Guest should not read this MSR!\n");
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -10,6 +10,7 @@
 #include <xen/delay.h>
 #include <xen/smp.h>
 #include <xen/mm.h>
+#include <xen/hvm/save.h>
 #include <asm/processor.h>
 #include <public/sysctl.h>
 #include <asm/system.h>
@@ -61,21 +62,26 @@ void vmce_destroy_msr(struct domain *d)
     dom_vmce(d) =3D NULL;
 }
=20
-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t *val)
+void vmce_init_vcpu(struct vcpu *v)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    v->arch.nr_vmce_banks =3D nr_mce_banks;
+}
+
+static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t =
*val)
+{
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -1;
+    *val =3D 0;
=20
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        *val =3D vmce->mci_ctl[bank] &
-            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
+        if ( bank < nr_mce_banks )
+            *val =3D vmce->mci_ctl[bank] &
+                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
         mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
                    bank, *val);
         break;
@@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_rdmsr(msr, val);
+            ret =3D intel_mce_rdmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -145,13 +151,13 @@ static int bank_mce_rdmsr(struct domain=20
  */
 int vmce_rdmsr(uint32_t msr, uint64_t *val)
 {
-    struct domain *d =3D current->domain;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    const struct vcpu *cur =3D current;
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     *val =3D 0;
=20
-    spin_lock(&dom_vmce(d)->lock);
+    spin_lock(&vmce->lock);
=20
     switch ( msr )
     {
@@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
                    *val);
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : =
0;
         break;
     }
=20
-    spin_unlock(&dom_vmce(d)->lock);
+    spin_unlock(&vmce->lock);
     return ret;
 }
=20
-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
+static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
 {
-    int bank, ret =3D 1;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    int ret =3D 1;
+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);
     struct bank_entry *entry =3D NULL;
=20
-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;
-    if ( bank >=3D nr_mce_banks )
-        return -EINVAL;
-
     switch ( msr & (MSR_IA32_MC0_CTL | 3) )
     {
     case MSR_IA32_MC0_CTL:
-        vmce->mci_ctl[bank] =3D val;
+        if ( bank < nr_mce_banks )
+            vmce->mci_ctl[bank] =3D val;
         break;
     case MSR_IA32_MC0_STATUS:
         /* Give the first entry of the list, it corresponds to current
@@ -202,9 +206,9 @@ static int bank_mce_wrmsr(struct domain=20
          * the guest, this node will be deleted.
          * Only error bank is written. Non-error banks simply return.
          */
-        if ( !list_empty(&dom_vmce(d)->impact_header) )
+        if ( !list_empty(&vmce->impact_header) )
         {
-            entry =3D list_entry(dom_vmce(d)->impact_header.next,
+            entry =3D list_entry(vmce->impact_header.next,
                                struct bank_entry, list);
             if ( entry->bank =3D=3D bank )
                 entry->mci_status =3D val;
@@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain=20
         switch ( boot_cpu_data.x86_vendor )
         {
         case X86_VENDOR_INTEL:
-            ret =3D intel_mce_wrmsr(msr, val);
+            ret =3D intel_mce_wrmsr(v, msr, val);
             break;
         default:
             ret =3D 0;
@@ -247,9 +251,9 @@ static int bank_mce_wrmsr(struct domain=20
  */
 int vmce_wrmsr(u32 msr, u64 val)
 {
-    struct domain *d =3D current->domain;
+    struct vcpu *cur =3D current;
     struct bank_entry *entry =3D NULL;
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);
+    struct domain_mca_msrs *vmce =3D dom_vmce(cur->domain);
     int ret =3D 1;
=20
     if ( !g_mcg_cap )
@@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         vmce->mcg_status =3D val;
         mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", =
val);
         /* For HVM guest, this is the point for deleting vMCE injection =
node */
-        if ( d->is_hvm && (vmce->nr_injection > 0) )
+        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
         {
             vmce->nr_injection--; /* Should be 0 */
             if ( !list_empty(&vmce->impact_header) )
@@ -293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)
         ret =3D -1;
         break;
     default:
-        ret =3D mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : =
0;
         break;
     }
=20
@@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)
     return ret;
 }
=20
+static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    struct vcpu *v;
+    int err =3D 0;
+
+    for_each_vcpu( d, v ) {
+        struct hvm_vmce_vcpu ctxt =3D {
+            .nr_banks =3D v->arch.nr_vmce_banks
+        };
+
+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
+        if ( err )
+            break;
+    }
+
+    return err;
+}
+
+static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+{
+    unsigned int vcpuid =3D hvm_load_instance(h);
+    struct vcpu *v;
+    struct hvm_vmce_vcpu ctxt;
+    int err;
+
+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]) =3D=3D NULL =
)
+    {
+        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", =
vcpuid);
+        return -EINVAL;
+    }
+
+    err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);
+    if ( !err )
+        v->arch.nr_vmce_banks =3D ctxt.nr_banks;
+
+    return err;
+}
+
+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
+
 int inject_vmce(struct domain *d)
 {
     int cpu =3D smp_processor_id();
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)
=20
     v->arch.pv_vcpu.ctrlreg[4] =3D real_cr4_to_pv_guest_cr4(mmu_cr4_featur=
es);
=20
+    vmce_init_vcpu(v);
+
     rc =3D is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0;
  done:
     if ( rc )
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1027,11 +1027,12 @@ long arch_do_domctl(
                 evc->syscall32_callback_eip    =3D 0;
                 evc->syscall32_disables_events =3D 0;
             }
+            evc->nr_mce_banks =3D v->arch.nr_vmce_banks;
         }
         else
         {
             ret =3D -EINVAL;
-            if ( evc->size !=3D sizeof(*evc) )
+            if ( evc->size < offsetof(typeof(*evc), nr_mce_banks) )
                 goto ext_vcpucontext_out;
 #ifdef __x86_64__
             if ( !is_hvm_domain(d) )
@@ -1059,6 +1060,16 @@ long arch_do_domctl(
                  (evc->syscall32_callback_cs & ~3) ||
                  evc->syscall32_callback_eip )
                 goto ext_vcpucontext_out;
+
+            if ( evc->size >=3D offsetof(typeof(*evc), mbz[ARRAY_SIZE(evc-=
>mbz)]) )
+            {
+                unsigned int i;
+
+                for ( i =3D 0; i < ARRAY_SIZE(evc->mbz); ++i )
+                    if ( evc->mbz[i] )
+                        goto ext_vcpucontext_out;
+                v->arch.nr_vmce_banks =3D evc->nr_mce_banks;
+            }
         }
=20
         ret =3D 0;
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -488,6 +488,8 @@ struct arch_vcpu
     /* This variable determines whether nonlazy extended state has been =
used,
      * and thus should be saved/restored. */
     bool_t nonlazy_xstate_used;
+
+    uint8_t nr_vmce_banks;
    =20
     struct paging_vcpu paging;
=20
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -28,6 +28,7 @@ struct domain_mca_msrs
 /* Guest vMCE MSRs virtualization */
 extern int vmce_init_msr(struct domain *d);
 extern void vmce_destroy_msr(struct domain *d);
+extern void vmce_init_vcpu(struct vcpu *);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
=20
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
=20
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context)=
;
=20
+struct hvm_vmce_vcpu {
+    uint8_t nr_banks;
+};
+
+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
+
 /*=20
  * Largest type-code in use
  */
-#define HVM_SAVE_CODE_MAX 17
+#define HVM_SAVE_CODE_MAX 18
=20
 #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
     uint32_t         vcpu;
     /*
      * SET: Size of struct (IN)
-     * GET: Size of struct (OUT)
+     * GET: Size of struct (OUT, up to 128 bytes)
      */
     uint32_t         size;
 #if defined(__i386__) || defined(__x86_64__)
@@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucontext {
     uint16_t         sysenter_callback_cs;
     uint8_t          syscall32_disables_events;
     uint8_t          sysenter_disables_events;
+    uint8_t          nr_mce_banks;
+    /* This array can be split and used for future extension. */
+    /* It is there just to grow the structure beyond 4.1's size. */
+    uint8_t          mbz[9];
 #endif
 };
 typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;


--=__PartE2CC867C.3__=
Content-Type: text/plain; name="x86-vmce-sr.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="x86-vmce-sr.patch"

--- a/tools/libxc/xc_domain_save.c=0A+++ b/tools/libxc/xc_domain_save.c=0A@=
@ -1879,6 +1879,7 @@ int xc_domain_save(xc_interface *xch, in=0A =0A       =
  domctl.cmd =3D XEN_DOMCTL_get_ext_vcpucontext;=0A         domctl.domain =
=3D dom;=0A+        memset(&domctl.u, 0, sizeof(domctl.u));=0A         =
domctl.u.ext_vcpucontext.vcpu =3D i;=0A         if ( xc_domctl(xch, =
&domctl) < 0 )=0A         {=0A--- a/tools/misc/xen-hvmctx.c=0A+++ =
b/tools/misc/xen-hvmctx.c=0A@@ -383,6 +383,13 @@ static void dump_viridian_=
vcpu(void)=0A            (unsigned long long) p.apic_assist);           =
=0A }=0A =0A+static void dump_vmce_vcpu(void)=0A+{=0A+    HVM_SAVE_TYPE(VMC=
E_VCPU) p;=0A+    READ(p);=0A+    printf("    VMCE_VCPU: nr_banks %u\n", =
p.nr_banks);=0A+}=0A+=0A int main(int argc, char **argv)=0A {=0A     int =
entry, domid;=0A@@ -449,6 +456,7 @@ int main(int argc, char **argv)=0A     =
    case HVM_SAVE_CODE(MTRR): dump_mtrr(); break;=0A         case =
HVM_SAVE_CODE(VIRIDIAN_DOMAIN): dump_viridian_domain(); break;=0A         =
case HVM_SAVE_CODE(VIRIDIAN_VCPU): dump_viridian_vcpu(); break;=0A+        =
case HVM_SAVE_CODE(VMCE_VCPU): dump_vmce_vcpu(); break;=0A         case =
HVM_SAVE_CODE(END): break;=0A         default:=0A             printf(" ** =
Don't understand type %u: skipping\n",=0A--- a/xen/arch/x86/cpu/mcheck/mce.=
h=0A+++ b/xen/arch/x86/cpu/mcheck/mce.h=0A@@ -3,6 +3,7 @@=0A #define =
_MCE_H=0A =0A #include <xen/init.h>=0A+#include <xen/sched.h>=0A #include =
<xen/smp.h>=0A #include <asm/types.h>=0A #include <asm/traps.h>=0A@@ -54,8 =
+55,8 @@ int unmmap_broken_page(struct domain *d,=0A u64 mce_cap_init(void)=
;=0A extern int firstbank;=0A =0A-int intel_mce_rdmsr(uint32_t msr, =
uint64_t *val);=0A-int intel_mce_wrmsr(uint32_t msr, uint64_t val);=0A+int =
intel_mce_rdmsr(const struct vcpu *, uint32_t msr, uint64_t *val);=0A+int =
intel_mce_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);=0A =0A struct =
mcinfo_extended *intel_get_extended_msrs(=0A     struct mcinfo_global =
*mig, struct mc_info *mi);=0A@@ -171,18 +172,20 @@ int vmce_domain_inject(s=
truct mcinfo_ban=0A =0A extern int vmce_init(struct cpuinfo_x86 *c);=0A =
=0A-static inline int mce_vendor_bank_msr(uint32_t msr)=0A+static inline =
int mce_vendor_bank_msr(const struct vcpu *v, uint32_t msr)=0A {=0A     if =
( boot_cpu_data.x86_vendor =3D=3D X86_VENDOR_INTEL &&=0A-         msr >=3D =
MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0_CTL2 + nr_mce_banks) )=0A+        =
 msr >=3D MSR_IA32_MC0_CTL2 &&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.=
nr_vmce_banks) )=0A           return 1;=0A     return 0;=0A }=0A =0A-static=
 inline int mce_bank_msr(uint32_t msr)=0A+static inline int mce_bank_msr(co=
nst struct vcpu *v, uint32_t msr)=0A {=0A-    if ( (msr >=3D MSR_IA32_MC0_C=
TL && msr < MSR_IA32_MCx_CTL(nr_mce_banks)) ||=0A-        mce_vendor_bank_m=
sr(msr) )=0A+    if ( (msr >=3D MSR_IA32_MC0_CTL &&=0A+          msr < =
MSR_IA32_MCx_CTL(v->arch.nr_vmce_banks)) ||=0A+         mce_vendor_bank_msr=
(v, msr) )=0A         return 1;=0A     return 0;=0A }=0A--- a/xen/arch/x86/=
cpu/mcheck/mce_intel.c=0A+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c=0A@@ =
-1421,11 +1421,12 @@ enum mcheck_type intel_mcheck_init(struc=0A }=0A =0A =
/* intel specific MCA MSR */=0A-int intel_mce_wrmsr(uint32_t msr, uint64_t =
val)=0A+int intel_mce_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val)=0A =
{=0A     int ret =3D 0;=0A =0A-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < =
(MSR_IA32_MC0_CTL2 + nr_mce_banks))=0A+    if ( msr >=3D MSR_IA32_MC0_CTL2 =
&&=0A+         msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )=0A     =
{=0A         mce_printk(MCE_QUIET, "We have disabled CMCI capability, "=0A =
                 "Guest should not write this MSR!\n");=0A@@ -1435,11 =
+1436,12 @@ int intel_mce_wrmsr(uint32_t msr, uint64=0A     return ret;=0A =
}=0A =0A-int intel_mce_rdmsr(uint32_t msr, uint64_t *val)=0A+int intel_mce_=
rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)=0A {=0A     int =
ret =3D 0;=0A =0A-    if (msr >=3D MSR_IA32_MC0_CTL2 && msr < (MSR_IA32_MC0=
_CTL2 + nr_mce_banks))=0A+    if ( msr >=3D MSR_IA32_MC0_CTL2 &&=0A+       =
  msr < MSR_IA32_MCx_CTL2(v->arch.nr_vmce_banks) )=0A     {=0A         =
mce_printk(MCE_QUIET, "We have disabled CMCI capability, "=0A              =
    "Guest should not read this MSR!\n");=0A--- a/xen/arch/x86/cpu/mcheck/v=
mce.c=0A+++ b/xen/arch/x86/cpu/mcheck/vmce.c=0A@@ -10,6 +10,7 @@=0A =
#include <xen/delay.h>=0A #include <xen/smp.h>=0A #include <xen/mm.h>=0A+#i=
nclude <xen/hvm/save.h>=0A #include <asm/processor.h>=0A #include =
<public/sysctl.h>=0A #include <asm/system.h>=0A@@ -61,21 +62,26 @@ void =
vmce_destroy_msr(struct domain *d)=0A     dom_vmce(d) =3D NULL;=0A }=0A =
=0A-static int bank_mce_rdmsr(struct domain *d, uint32_t msr, uint64_t =
*val)=0A+void vmce_init_vcpu(struct vcpu *v)=0A {=0A-    int bank, ret =3D =
1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    v->arch.nr_v=
mce_banks =3D nr_mce_banks;=0A+}=0A+=0A+static int bank_mce_rdmsr(const =
struct vcpu *v, uint32_t msr, uint64_t *val)=0A+{=0A+    int ret =3D =
1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A+    =
struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     struct =
bank_entry *entry;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_CTL) / 4;=0A-   =
 if ( bank >=3D nr_mce_banks )=0A-        return -1;=0A+    *val =3D 0;=0A =
=0A     switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A     case =
MSR_IA32_MC0_CTL:=0A-        *val =3D vmce->mci_ctl[bank] &=0A-            =
(h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);=0A+        if ( bank < nr_mce_banks=
 )=0A+            *val =3D vmce->mci_ctl[bank] &=0A+                   =
(h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);=0A         mce_printk(MCE_VERBOSE, =
"MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",=0A                    bank, *val);=0A =
        break;=0A@@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct =
domain =0A         switch ( boot_cpu_data.x86_vendor )=0A         {=0A     =
    case X86_VENDOR_INTEL:=0A-            ret =3D intel_mce_rdmsr(msr, =
val);=0A+            ret =3D intel_mce_rdmsr(v, msr, val);=0A             =
break;=0A         default:=0A             ret =3D 0;=0A@@ -145,13 +151,13 =
@@ static int bank_mce_rdmsr(struct domain =0A  */=0A int vmce_rdmsr(uint32=
_t msr, uint64_t *val)=0A {=0A-    struct domain *d =3D current->domain;=0A=
-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    const struct =
vcpu *cur =3D current;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(cur=
->domain);=0A     int ret =3D 1;=0A =0A     *val =3D 0;=0A =0A-    =
spin_lock(&dom_vmce(d)->lock);=0A+    spin_lock(&vmce->lock);=0A =0A     =
switch ( msr )=0A     {=0A@@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t =
msr, uint64_t *v=0A                    *val);=0A         break;=0A     =
default:=0A-        ret =3D mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, =
val) : 0;=0A+        ret =3D mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, =
msr, val) : 0;=0A         break;=0A     }=0A =0A-    spin_unlock(&dom_vmce(=
d)->lock);=0A+    spin_unlock(&vmce->lock);=0A     return ret;=0A }=0A =
=0A-static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)=0A+static=
 int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)=0A {=0A-    int =
bank, ret =3D 1;=0A-    struct domain_mca_msrs *vmce =3D dom_vmce(d);=0A+  =
  int ret =3D 1;=0A+    unsigned int bank =3D (msr - MSR_IA32_MC0_CTL) / =
4;=0A+    struct domain_mca_msrs *vmce =3D dom_vmce(v->domain);=0A     =
struct bank_entry *entry =3D NULL;=0A =0A-    bank =3D (msr - MSR_IA32_MC0_=
CTL) / 4;=0A-    if ( bank >=3D nr_mce_banks )=0A-        return =
-EINVAL;=0A-=0A     switch ( msr & (MSR_IA32_MC0_CTL | 3) )=0A     {=0A    =
 case MSR_IA32_MC0_CTL:=0A-        vmce->mci_ctl[bank] =3D val;=0A+        =
if ( bank < nr_mce_banks )=0A+            vmce->mci_ctl[bank] =3D val;=0A  =
       break;=0A     case MSR_IA32_MC0_STATUS:=0A         /* Give the =
first entry of the list, it corresponds to current=0A@@ -202,9 +206,9 @@ =
static int bank_mce_wrmsr(struct domain =0A          * the guest, this =
node will be deleted.=0A          * Only error bank is written. Non-error =
banks simply return.=0A          */=0A-        if ( !list_empty(&dom_vmce(d=
)->impact_header) )=0A+        if ( !list_empty(&vmce->impact_header) )=0A =
        {=0A-            entry =3D list_entry(dom_vmce(d)->impact_header.ne=
xt,=0A+            entry =3D list_entry(vmce->impact_header.next,=0A       =
                         struct bank_entry, list);=0A             if ( =
entry->bank =3D=3D bank )=0A                 entry->mci_status =3D =
val;=0A@@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain =0A     =
    switch ( boot_cpu_data.x86_vendor )=0A         {=0A         case =
X86_VENDOR_INTEL:=0A-            ret =3D intel_mce_wrmsr(msr, val);=0A+    =
        ret =3D intel_mce_wrmsr(v, msr, val);=0A             break;=0A     =
    default:=0A             ret =3D 0;=0A@@ -247,9 +251,9 @@ static int =
bank_mce_wrmsr(struct domain =0A  */=0A int vmce_wrmsr(u32 msr, u64 =
val)=0A {=0A-    struct domain *d =3D current->domain;=0A+    struct vcpu =
*cur =3D current;=0A     struct bank_entry *entry =3D NULL;=0A-    struct =
domain_mca_msrs *vmce =3D dom_vmce(d);=0A+    struct domain_mca_msrs *vmce =
=3D dom_vmce(cur->domain);=0A     int ret =3D 1;=0A =0A     if ( !g_mcg_cap=
 )=0A@@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)=0A         =
vmce->mcg_status =3D val;=0A         mce_printk(MCE_VERBOSE, "MCE: wrmsr =
MCG_STATUS %"PRIx64"\n", val);=0A         /* For HVM guest, this is the =
point for deleting vMCE injection node */=0A-        if ( d->is_hvm && =
(vmce->nr_injection > 0) )=0A+        if ( is_hvm_vcpu(cur) && (vmce->nr_in=
jection > 0) )=0A         {=0A             vmce->nr_injection--; /* Should =
be 0 */=0A             if ( !list_empty(&vmce->impact_header) )=0A@@ =
-293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)=0A         ret =3D =
-1;=0A         break;=0A     default:=0A-        ret =3D mce_bank_msr(msr) =
? bank_mce_wrmsr(d, msr, val) : 0;=0A+        ret =3D mce_bank_msr(cur, =
msr) ? bank_mce_wrmsr(cur, msr, val) : 0;=0A         break;=0A     }=0A =
=0A@@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)=0A     return =
ret;=0A }=0A =0A+static int vmce_save_vcpu_ctxt(struct domain *d, =
hvm_domain_context_t *h)=0A+{=0A+    struct vcpu *v;=0A+    int err =3D =
0;=0A+=0A+    for_each_vcpu( d, v ) {=0A+        struct hvm_vmce_vcpu ctxt =
=3D {=0A+            .nr_banks =3D v->arch.nr_vmce_banks=0A+        =
};=0A+=0A+        err =3D hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, =
&ctxt);=0A+        if ( err )=0A+            break;=0A+    }=0A+=0A+    =
return err;=0A+}=0A+=0A+static int vmce_load_vcpu_ctxt(struct domain *d, =
hvm_domain_context_t *h)=0A+{=0A+    unsigned int vcpuid =3D hvm_load_insta=
nce(h);=0A+    struct vcpu *v;=0A+    struct hvm_vmce_vcpu ctxt;=0A+    =
int err;=0A+=0A+    if ( vcpuid >=3D d->max_vcpus || (v =3D d->vcpu[vcpuid]=
) =3D=3D NULL )=0A+    {=0A+        gdprintk(XENLOG_ERR, "HVM restore: =
domain has no vcpu %u\n", vcpuid);=0A+        return -EINVAL;=0A+    =
}=0A+=0A+    err =3D hvm_load_entry(VMCE_VCPU, h, &ctxt);=0A+    if ( !err =
)=0A+        v->arch.nr_vmce_banks =3D ctxt.nr_banks;=0A+=0A+    return =
err;=0A+}=0A+=0A+HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,=
=0A+                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);=0A+=
=0A int inject_vmce(struct domain *d)=0A {=0A     int cpu =3D smp_processor=
_id();=0A--- a/xen/arch/x86/domain.c=0A+++ b/xen/arch/x86/domain.c=0A@@ =
-468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)=0A =0A     v->arch.pv_=
vcpu.ctrlreg[4] =3D real_cr4_to_pv_guest_cr4(mmu_cr4_features);=0A =0A+    =
vmce_init_vcpu(v);=0A+=0A     rc =3D is_pv_32on64_vcpu(v) ? setup_compat_l4=
(v) : 0;=0A  done:=0A     if ( rc )=0A--- a/xen/arch/x86/domctl.c=0A+++ =
b/xen/arch/x86/domctl.c=0A@@ -1027,11 +1027,12 @@ long arch_do_domctl(=0A  =
               evc->syscall32_callback_eip    =3D 0;=0A                 =
evc->syscall32_disables_events =3D 0;=0A             }=0A+            =
evc->nr_mce_banks =3D v->arch.nr_vmce_banks;=0A         }=0A         =
else=0A         {=0A             ret =3D -EINVAL;=0A-            if ( =
evc->size !=3D sizeof(*evc) )=0A+            if ( evc->size < offsetof(type=
of(*evc), nr_mce_banks) )=0A                 goto ext_vcpucontext_out;=0A =
#ifdef __x86_64__=0A             if ( !is_hvm_domain(d) )=0A@@ -1059,6 =
+1060,16 @@ long arch_do_domctl(=0A                  (evc->syscall32_callba=
ck_cs & ~3) ||=0A                  evc->syscall32_callback_eip )=0A        =
         goto ext_vcpucontext_out;=0A+=0A+            if ( evc->size >=3D =
offsetof(typeof(*evc), mbz[ARRAY_SIZE(evc->mbz)]) )=0A+            {=0A+   =
             unsigned int i;=0A+=0A+                for ( i =3D 0; i < =
ARRAY_SIZE(evc->mbz); ++i )=0A+                    if ( evc->mbz[i] )=0A+  =
                      goto ext_vcpucontext_out;=0A+                =
v->arch.nr_vmce_banks =3D evc->nr_mce_banks;=0A+            }=0A         =
}=0A =0A         ret =3D 0;=0A--- a/xen/include/asm-x86/domain.h=0A+++ =
b/xen/include/asm-x86/domain.h=0A@@ -488,6 +488,8 @@ struct arch_vcpu=0A   =
  /* This variable determines whether nonlazy extended state has been =
used,=0A      * and thus should be saved/restored. */=0A     bool_t =
nonlazy_xstate_used;=0A+=0A+    uint8_t nr_vmce_banks;=0A     =0A     =
struct paging_vcpu paging;=0A =0A--- a/xen/include/asm-x86/mce.h=0A+++ =
b/xen/include/asm-x86/mce.h=0A@@ -28,6 +28,7 @@ struct domain_mca_msrs=0A =
/* Guest vMCE MSRs virtualization */=0A extern int vmce_init_msr(struct =
domain *d);=0A extern void vmce_destroy_msr(struct domain *d);=0A+extern =
void vmce_init_vcpu(struct vcpu *);=0A extern int vmce_wrmsr(uint32_t msr, =
uint64_t val);=0A extern int vmce_rdmsr(uint32_t msr, uint64_t *val);=0A =
=0A--- a/xen/include/public/arch-x86/hvm/save.h=0A+++ b/xen/include/public/=
arch-x86/hvm/save.h=0A@@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context=
 {=0A =0A DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu=
_context);=0A =0A+struct hvm_vmce_vcpu {=0A+    uint8_t nr_banks;=0A+};=0A+=
=0A+DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);=0A+=0A /* =
=0A  * Largest type-code in use=0A  */=0A-#define HVM_SAVE_CODE_MAX =
17=0A+#define HVM_SAVE_CODE_MAX 18=0A =0A #endif /* __XEN_PUBLIC_HVM_SAVE_X=
86_H__ */=0A--- a/xen/include/public/domctl.h=0A+++ b/xen/include/public/do=
mctl.h=0A@@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {=0A     =
uint32_t         vcpu;=0A     /*=0A      * SET: Size of struct (IN)=0A-    =
 * GET: Size of struct (OUT)=0A+     * GET: Size of struct (OUT, up to 128 =
bytes)=0A      */=0A     uint32_t         size;=0A #if defined(__i386__) =
|| defined(__x86_64__)=0A@@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucon=
text {=0A     uint16_t         sysenter_callback_cs;=0A     uint8_t        =
  syscall32_disables_events;=0A     uint8_t          sysenter_disables_even=
ts;=0A+    uint8_t          nr_mce_banks;=0A+    /* This array can be =
split and used for future extension. */=0A+    /* It is there just to grow =
the structure beyond 4.1's size. */=0A+    uint8_t          mbz[9];=0A =
#endif=0A };=0A typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vc=
pucontext_t;=0A
--=__PartE2CC867C.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

--=__PartE2CC867C.3__=--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:00:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1Rrrm5-0005O4-KA; Mon, 30 Jan 2012 14:00: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 1Rrrm3-0005N0-OD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:00:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327931970!57696253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27030 invoked from network); 30 Jan 2012 13:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 13:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10366655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 13: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; Mon, 30 Jan 2012 13: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
	1Rrrm2-0003lm-7P	for xen-devel@lists.xensource.com;
	Mon, 30 Jan 2012 13:59:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrrm2-0006Uv-2P	for
	xen-devel@lists.xensource.com; Mon, 30 Jan 2012 13:59:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20262.41566.25707.184425@mariner.uk.xensource.com>
Date: Mon, 30 Jan 2012 13:59:58 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11660-mainreport@xen.org>
References: <osstest-11660-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11660: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11660: regressions - FAIL"):
> flight 11660 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11660/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-xl            18 leak-check/check      fail REGR. vs. 11643

This is mostly my fault and I'm about to post a two-patch
series to fix it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:00:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1Rrrm5-0005O4-KA; Mon, 30 Jan 2012 14:00: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 1Rrrm3-0005N0-OD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:00:00 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327931970!57696253!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27030 invoked from network); 30 Jan 2012 13:59:30 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 13:59:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10366655"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 13: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; Mon, 30 Jan 2012 13: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
	1Rrrm2-0003lm-7P	for xen-devel@lists.xensource.com;
	Mon, 30 Jan 2012 13:59:58 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrrm2-0006Uv-2P	for
	xen-devel@lists.xensource.com; Mon, 30 Jan 2012 13:59:58 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20262.41566.25707.184425@mariner.uk.xensource.com>
Date: Mon, 30 Jan 2012 13:59:58 +0000
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
In-Reply-To: <osstest-11660-mainreport@xen.org>
References: <osstest-11660-mainreport@xen.org>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: Re: [Xen-devel] [xen-unstable test] 11660: regressions - FAIL
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

xen.org writes ("[xen-unstable test] 11660: regressions - FAIL"):
> flight 11660 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/11660/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-i386-i386-xl            18 leak-check/check      fail REGR. vs. 11643

This is mostly my fault and I'm about to post a two-patch
series to fix it.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:02:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1Rrrnd-0005V2-Op; Mon, 30 Jan 2012 14:01:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rrrnc-0005Uq-UR
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:01:37 +0000
Received: from [85.158.138.51:13728] by server-1.bemta-3.messagelabs.com id
	C9/68-09565-FB2A62F4; Mon, 30 Jan 2012 14:01:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327932095!11262665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11942 invoked from network); 30 Jan 2012 14:01:35 -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;
	30 Jan 2012 14:01:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10366719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:01:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 14:01: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
	1Rrrna-0003mX-2i; Mon, 30 Jan 2012 14:01:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrrna-0006Vl-20;
	Mon, 30 Jan 2012 14:01:34 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:01:26 +0000
Message-ID: <1327932087-25001-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20262.41566.25707.184425@mariner.uk.xensource.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxl: domain_death_xswatch_callback: add
	some debug 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>
Content-Type: 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 |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fa358d1..2758d4c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -713,15 +713,28 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
         }
         gotend = &domaininfos[rc];
 
+        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=%p:%"PRIu32"]"
+                   " from domid=%"PRIu32" nentries=%d rc=%d",
+                   evg, evg->domid, domid, nentries, rc);
+
         for (;;) {
-            if (!evg)
+            if (!evg) {
+                LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=0] all reported");
                 goto all_reported;
+            }
+
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=%p:%"PRIu32"]"
+                       "   got=domaininfos[%d] got->domain=%ld",
+                       evg, evg->domid, (int)(got - domaininfos),
+                       got < gotend ? (long)got->domain : -1L);
 
             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__LOG(CTX, LIBXL__LOG_DEBUG, " destroyed");
+
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_DESTROY, evg->domid);
                 if (!ev) goto out;
 
@@ -736,8 +749,10 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
                 continue;
             }
             
-            if (got == gotend)
+            if (got == gotend) {
+                LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " got==gotend");
                 break;
+            }
 
             if (got->domain < evg->domid) {
                 got++;
@@ -745,12 +760,17 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
             }
 
             assert(evg->domid == got->domain);
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " exists shutdown_reported=%d"
+                       " dominf.flags=%x",
+                       evg->shutdown_reported, got->flags);
 
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
                 if (!ev) goto out;
                 
+                LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
+
                 ev->u.domain_shutdown.shutdown_reason =
                     (got->flags >> XEN_DOMINF_shutdownshift) &
                     XEN_DOMINF_shutdownmask;
@@ -767,6 +787,8 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
  all_reported:
  out:
 
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "domain death search done");
+
     CTX_UNLOCK;
 }
 
-- 
1.7.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 Jan 30 14:02:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1Rrrnd-0005V2-Op; Mon, 30 Jan 2012 14:01:37 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rrrnc-0005Uq-UR
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:01:37 +0000
Received: from [85.158.138.51:13728] by server-1.bemta-3.messagelabs.com id
	C9/68-09565-FB2A62F4; Mon, 30 Jan 2012 14:01:35 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327932095!11262665!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11942 invoked from network); 30 Jan 2012 14:01:35 -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;
	30 Jan 2012 14:01:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10366719"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:01:34 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 14:01: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
	1Rrrna-0003mX-2i; Mon, 30 Jan 2012 14:01:34 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrrna-0006Vl-20;
	Mon, 30 Jan 2012 14:01:34 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:01:26 +0000
Message-ID: <1327932087-25001-1-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20262.41566.25707.184425@mariner.uk.xensource.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 1/2] libxl: domain_death_xswatch_callback: add
	some debug 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>
Content-Type: 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 |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index fa358d1..2758d4c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -713,15 +713,28 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
         }
         gotend = &domaininfos[rc];
 
+        LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=%p:%"PRIu32"]"
+                   " from domid=%"PRIu32" nentries=%d rc=%d",
+                   evg, evg->domid, domid, nentries, rc);
+
         for (;;) {
-            if (!evg)
+            if (!evg) {
+                LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=0] all reported");
                 goto all_reported;
+            }
+
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=%p:%"PRIu32"]"
+                       "   got=domaininfos[%d] got->domain=%ld",
+                       evg, evg->domid, (int)(got - domaininfos),
+                       got < gotend ? (long)got->domain : -1L);
 
             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__LOG(CTX, LIBXL__LOG_DEBUG, " destroyed");
+
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_DESTROY, evg->domid);
                 if (!ev) goto out;
 
@@ -736,8 +749,10 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
                 continue;
             }
             
-            if (got == gotend)
+            if (got == gotend) {
+                LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " got==gotend");
                 break;
+            }
 
             if (got->domain < evg->domid) {
                 got++;
@@ -745,12 +760,17 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
             }
 
             assert(evg->domid == got->domain);
+            LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " exists shutdown_reported=%d"
+                       " dominf.flags=%x",
+                       evg->shutdown_reported, got->flags);
 
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
                 if (!ev) goto out;
                 
+                LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " shutdown reporting");
+
                 ev->u.domain_shutdown.shutdown_reason =
                     (got->flags >> XEN_DOMINF_shutdownshift) &
                     XEN_DOMINF_shutdownmask;
@@ -767,6 +787,8 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
  all_reported:
  out:
 
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "domain death search done");
+
     CTX_UNLOCK;
 }
 
-- 
1.7.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 Jan 30 14:02:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:02:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrrng-0005VK-5c; Mon, 30 Jan 2012 14:01:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rrrne-0005V0-3d
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:01:38 +0000
Received: from [85.158.138.51:13888] by server-9.bemta-3.messagelabs.com id
	96/AE-31168-1C2A62F4; Mon, 30 Jan 2012 14:01:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327932095!11262665!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12024 invoked from network); 30 Jan 2012 14:01:36 -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;
	30 Jan 2012 14:01:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10366721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:01:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 14:01: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
	1Rrrnc-0003mb-5J; Mon, 30 Jan 2012 14:01:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrrnc-0006Vp-4J;
	Mon, 30 Jan 2012 14:01:36 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:01:27 +0000
Message-ID: <1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20262.41566.25707.184425@mariner.uk.xensource.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxl: treat "dying" domains as destroyed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Rename the DOMAIN_DESTROY event to DOMAIN_DEATH and have it trigger
when the domain goes into the state indicated by the domaininfo flag
"dying".

This fixes a race which could leak a daemonised xl process, which
would have ignored the domain becoming "dying" and would then wait
forever to be told the domain was destroyed.

After the domain becomes "dying" we can't generate an event when it is
actually destroyed because xenstored will eat the relevant
VIRT_DOM_EXC virq and not generate an @releaseDomain, since xenstored
discards its own record of the domain's existence as soon as it sees
the domain "dying" and will not trigger @releaseDomain watches for
domains it knows nothing about.  Arguably this is a bug in xenstored,
and the whole @releaseDomain machinery is rather poor, but let us not
fix that now.

Anyway, xl does not really want to know when the domain is ultimately
destroyed.  It is enough for xl to know that it is on the way out, in
the "dying" state (which leads later to destruction by Xen).

Also fix a bug where domain_death_xswatch_callback might read one
domain beyond the valid data in its domaininfos array, by correctly
ordering the checks for empty domain list, end of domain list, and our
domain being missing.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c         |   57 ++++++++++++++++++++++++++++--------------
 tools/libxl/libxl_types.idl |    4 +-
 tools/libxl/xl_cmdimpl.c    |    4 +-
 3 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2758d4c..b74a4d9 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -685,6 +685,29 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
     return ret;
 }
 
+static void domain_death_occurred(libxl__egc *egc,
+                                  libxl_evgen_domain_death **evg_upd,
+                                  const char *why) {
+    /* Removes **evg from the list and advances *evg_upd to the next
+     * entry.  Call sites in _xswatch_callback must use "continue". */
+    EGC_GC;
+    libxl_evgen_domain_death *const evg = *evg_upd;
+
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " death %s", why);
+
+    libxl_evgen_domain_death *evg_next = LIBXL_TAILQ_NEXT(evg, entry);
+    *evg_upd = evg_next;
+
+    libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
+    if (!ev) return;
+
+    libxl__event_occurred(egc, ev);
+
+    evg->death_reported = 1;
+    LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+    LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
+}
+
 static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
                                         const char *wpath, const char *epath) {
     EGC_GC;
@@ -728,32 +751,23 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
                        evg, evg->domid, (int)(got - domaininfos),
                        got < gotend ? (long)got->domain : -1L);
 
-            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__LOG(CTX, LIBXL__LOG_DEBUG, " destroyed");
-
-                libxl_event *ev = NEW_EVENT(egc, DOMAIN_DESTROY, evg->domid);
-                if (!ev) goto out;
-
-                libxl__event_occurred(egc, 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;
-
+            if (!rc) {
+                domain_death_occurred(egc, &evg, "empty list");
                 continue;
             }
-            
+
             if (got == gotend) {
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " got==gotend");
                 break;
             }
 
+            if (got->domain > evg->domid) {
+                /* ie, the list doesn't contain evg->domid any more so
+                 * the domain has been destroyed */
+                domain_death_occurred(egc, &evg, "missing from list");
+                continue;
+            }
+
             if (got->domain < evg->domid) {
                 got++;
                 continue;
@@ -764,6 +778,11 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
                        " dominf.flags=%x",
                        evg->shutdown_reported, got->flags);
 
+            if (got->flags & XEN_DOMINF_dying) {
+                domain_death_occurred(egc, &evg, "dying");
+                continue;
+            }
+
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f438c9f..5492ce9 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -396,7 +396,7 @@ libxl_sched_sedf = Struct("sched_sedf", [
 
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
-    (2, "DOMAIN_DESTROY"),
+    (2, "DOMAIN_DEATH"),
     (3, "DISK_EJECT"),
     (4, "OPERATION_COMPLETE"),
     ])
@@ -417,7 +417,7 @@ libxl_event = Struct("event",[
           [("domain_shutdown", Struct(None, [
                                              ("shutdown_reason", uint8),
                                       ])),
-           ("domain_destroy", Struct(None, [])),
+           ("domain_death", 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 8832b5a..d326588 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1909,7 +1909,7 @@ start:
                 abort();
             }
 
-        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+        case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
             LOG("Domain %d has been destroyed.", domid);
             ret = 0;
             goto out;
@@ -2445,7 +2445,7 @@ static void shutdown_domain(const char *p, int wait)
 
             switch (event->type) {
 
-            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
                 LOG("Domain %d has been destroyed", domid);
                 goto done;
 
-- 
1.7.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 Jan 30 14:02:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:02:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrrng-0005VK-5c; Mon, 30 Jan 2012 14:01:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1Rrrne-0005V0-3d
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:01:38 +0000
Received: from [85.158.138.51:13888] by server-9.bemta-3.messagelabs.com id
	96/AE-31168-1C2A62F4; Mon, 30 Jan 2012 14:01:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327932095!11262665!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12024 invoked from network); 30 Jan 2012 14:01:36 -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;
	30 Jan 2012 14:01:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10366721"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:01:36 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 14:01: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
	1Rrrnc-0003mb-5J; Mon, 30 Jan 2012 14:01:36 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrrnc-0006Vp-4J;
	Mon, 30 Jan 2012 14:01:36 +0000
From: Ian Jackson <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:01:27 +0000
Message-ID: <1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <20262.41566.25707.184425@mariner.uk.xensource.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
MIME-Version: 1.0
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Subject: [Xen-devel] [PATCH 2/2] libxl: treat "dying" domains as destroyed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Rename the DOMAIN_DESTROY event to DOMAIN_DEATH and have it trigger
when the domain goes into the state indicated by the domaininfo flag
"dying".

This fixes a race which could leak a daemonised xl process, which
would have ignored the domain becoming "dying" and would then wait
forever to be told the domain was destroyed.

After the domain becomes "dying" we can't generate an event when it is
actually destroyed because xenstored will eat the relevant
VIRT_DOM_EXC virq and not generate an @releaseDomain, since xenstored
discards its own record of the domain's existence as soon as it sees
the domain "dying" and will not trigger @releaseDomain watches for
domains it knows nothing about.  Arguably this is a bug in xenstored,
and the whole @releaseDomain machinery is rather poor, but let us not
fix that now.

Anyway, xl does not really want to know when the domain is ultimately
destroyed.  It is enough for xl to know that it is on the way out, in
the "dying" state (which leads later to destruction by Xen).

Also fix a bug where domain_death_xswatch_callback might read one
domain beyond the valid data in its domaininfos array, by correctly
ordering the checks for empty domain list, end of domain list, and our
domain being missing.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl.c         |   57 ++++++++++++++++++++++++++++--------------
 tools/libxl/libxl_types.idl |    4 +-
 tools/libxl/xl_cmdimpl.c    |    4 +-
 3 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2758d4c..b74a4d9 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -685,6 +685,29 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
     return ret;
 }
 
+static void domain_death_occurred(libxl__egc *egc,
+                                  libxl_evgen_domain_death **evg_upd,
+                                  const char *why) {
+    /* Removes **evg from the list and advances *evg_upd to the next
+     * entry.  Call sites in _xswatch_callback must use "continue". */
+    EGC_GC;
+    libxl_evgen_domain_death *const evg = *evg_upd;
+
+    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " death %s", why);
+
+    libxl_evgen_domain_death *evg_next = LIBXL_TAILQ_NEXT(evg, entry);
+    *evg_upd = evg_next;
+
+    libxl_event *ev = NEW_EVENT(egc, DOMAIN_DEATH, evg->domid);
+    if (!ev) return;
+
+    libxl__event_occurred(egc, ev);
+
+    evg->death_reported = 1;
+    LIBXL_TAILQ_REMOVE(&CTX->death_list, evg, entry);
+    LIBXL_TAILQ_INSERT_HEAD(&CTX->death_reported, evg, entry);
+}
+
 static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
                                         const char *wpath, const char *epath) {
     EGC_GC;
@@ -728,32 +751,23 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
                        evg, evg->domid, (int)(got - domaininfos),
                        got < gotend ? (long)got->domain : -1L);
 
-            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__LOG(CTX, LIBXL__LOG_DEBUG, " destroyed");
-
-                libxl_event *ev = NEW_EVENT(egc, DOMAIN_DESTROY, evg->domid);
-                if (!ev) goto out;
-
-                libxl__event_occurred(egc, 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;
-
+            if (!rc) {
+                domain_death_occurred(egc, &evg, "empty list");
                 continue;
             }
-            
+
             if (got == gotend) {
                 LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " got==gotend");
                 break;
             }
 
+            if (got->domain > evg->domid) {
+                /* ie, the list doesn't contain evg->domid any more so
+                 * the domain has been destroyed */
+                domain_death_occurred(egc, &evg, "missing from list");
+                continue;
+            }
+
             if (got->domain < evg->domid) {
                 got++;
                 continue;
@@ -764,6 +778,11 @@ static void domain_death_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
                        " dominf.flags=%x",
                        evg->shutdown_reported, got->flags);
 
+            if (got->flags & XEN_DOMINF_dying) {
+                domain_death_occurred(egc, &evg, "dying");
+                continue;
+            }
+
             if (!evg->shutdown_reported &&
                 (got->flags & XEN_DOMINF_shutdown)) {
                 libxl_event *ev = NEW_EVENT(egc, DOMAIN_SHUTDOWN, got->domain);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index f438c9f..5492ce9 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -396,7 +396,7 @@ libxl_sched_sedf = Struct("sched_sedf", [
 
 libxl_event_type = Enumeration("event_type", [
     (1, "DOMAIN_SHUTDOWN"),
-    (2, "DOMAIN_DESTROY"),
+    (2, "DOMAIN_DEATH"),
     (3, "DISK_EJECT"),
     (4, "OPERATION_COMPLETE"),
     ])
@@ -417,7 +417,7 @@ libxl_event = Struct("event",[
           [("domain_shutdown", Struct(None, [
                                              ("shutdown_reason", uint8),
                                       ])),
-           ("domain_destroy", Struct(None, [])),
+           ("domain_death", 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 8832b5a..d326588 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1909,7 +1909,7 @@ start:
                 abort();
             }
 
-        case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+        case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
             LOG("Domain %d has been destroyed.", domid);
             ret = 0;
             goto out;
@@ -2445,7 +2445,7 @@ static void shutdown_domain(const char *p, int wait)
 
             switch (event->type) {
 
-            case LIBXL_EVENT_TYPE_DOMAIN_DESTROY:
+            case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
                 LOG("Domain %d has been destroyed", domid);
                 goto done;
 
-- 
1.7.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 Jan 30 14:10:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrrwA-0005tG-8C; Mon, 30 Jan 2012 14:10: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 1Rrrw8-0005tB-2x
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:10:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327932618!13112913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10007 invoked from network); 30 Jan 2012 14:10:18 -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;
	30 Jan 2012 14:10:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10366991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:10: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; Mon, 30 Jan 2012 14:10:18 +0000
Date: Mon, 30 Jan 2012 14:11:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paulian Bogdan Marinca <paulian@marinca.net>
In-Reply-To: <CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201301409470.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
	<alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
	<CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-87990123-1327932724=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-87990123-1327932724=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 30 Jan 2012, Paulian Bogdan Marinca wrote:
> On 30 January 2012 11:32, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Sat, 28 Jan 2012, Keir Fraser wrote:
> >> On 27/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@marinca.net> wrote:
> >>
> >> > I have a testing intel machine with 4 physical cpus running 64 bit Xen
> >> > 4.1.3-rc1.
> >> >
> >> > I have a particular linux VM for which at its kernel boot time ( as
> >> > domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
> >> > console freezes indefinitely). The domU linux kernel is 3.2.1 and has
> [...]
> >
> > That's right, this scenario should not be possible because whenever
> > XENFEAT_hvm_pirqs is available, XENFEAT_hvm_callback_vector should also
> > be available.
> > In any case I'll submit a patch to Linux to make sure this doesn't
> > happen, explicitly checking for xen_have_vector_callback.
> > What is your Linux kernel version? Could you please post your kernel
> > config as well?
> 
> Yes, you are right, this does not happen normally in a booting kernel.
> What happens is that I needed to test my own PV drivers in all
> possible scenarios,
>  so I hacked the domU linux kernel to "believe" that XEN does not have
> XENFEAT_hvm_callback_vector, basically I forced a
> 
> xen_have_vector_callback = 0;
> 
> in enlighten.c in domU kernel. This is probably why it triggered this
> unusual situation.
> 
> I attach my kernel config (btw is actually a 3.0.6 kernel not 3.2.1)
> 
> I will try to apply your patch against XEN.

In that case it is a matter of protecting Xen against misbehaving
guests, so I would rather have the patch below than try to handle the
case correctly.



> > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> > index df92cc7..7d89ed6 100644
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
> >
> >     if ( domid == DOMID_SELF && is_hvm_domain(d) )
> >     {
> > +        if ( !is_hvm_pv_evtchn_domain(d) )
> > +        {
> > +            ret = -EINVAL;
> > +            goto free_domain;
> > +        }
> >         ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
> >         goto free_domain;
> >     }
> 
--8323329-87990123-1327932724=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-87990123-1327932724=:3196--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:10:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrrwA-0005tG-8C; Mon, 30 Jan 2012 14:10: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 1Rrrw8-0005tB-2x
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:10:24 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327932618!13112913!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10007 invoked from network); 30 Jan 2012 14:10:18 -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;
	30 Jan 2012 14:10:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10366991"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:10: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; Mon, 30 Jan 2012 14:10:18 +0000
Date: Mon, 30 Jan 2012 14:11:49 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paulian Bogdan Marinca <paulian@marinca.net>
In-Reply-To: <CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201301409470.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
	<alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
	<CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-87990123-1327932724=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-87990123-1327932724=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 30 Jan 2012, Paulian Bogdan Marinca wrote:
> On 30 January 2012 11:32, Stefano Stabellini
> <stefano.stabellini@eu.citrix.com> wrote:
> > On Sat, 28 Jan 2012, Keir Fraser wrote:
> >> On 27/01/2012 23:20, "Paulian Bogdan Marinca" <paulian@marinca.net> wrote:
> >>
> >> > I have a testing intel machine with 4 physical cpus running 64 bit Xen
> >> > 4.1.3-rc1.
> >> >
> >> > I have a particular linux VM for which at its kernel boot time ( as
> >> > domU ) it makes the XEN and Dom0 unresponsive (even the XEN serial
> >> > console freezes indefinitely). The domU linux kernel is 3.2.1 and has
> [...]
> >
> > That's right, this scenario should not be possible because whenever
> > XENFEAT_hvm_pirqs is available, XENFEAT_hvm_callback_vector should also
> > be available.
> > In any case I'll submit a patch to Linux to make sure this doesn't
> > happen, explicitly checking for xen_have_vector_callback.
> > What is your Linux kernel version? Could you please post your kernel
> > config as well?
> 
> Yes, you are right, this does not happen normally in a booting kernel.
> What happens is that I needed to test my own PV drivers in all
> possible scenarios,
>  so I hacked the domU linux kernel to "believe" that XEN does not have
> XENFEAT_hvm_callback_vector, basically I forced a
> 
> xen_have_vector_callback = 0;
> 
> in enlighten.c in domU kernel. This is probably why it triggered this
> unusual situation.
> 
> I attach my kernel config (btw is actually a 3.0.6 kernel not 3.2.1)
> 
> I will try to apply your patch against XEN.

In that case it is a matter of protecting Xen against misbehaving
guests, so I would rather have the patch below than try to handle the
case correctly.



> > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> > index df92cc7..7d89ed6 100644
> > --- a/xen/arch/x86/physdev.c
> > +++ b/xen/arch/x86/physdev.c
> > @@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
> >
> >     if ( domid == DOMID_SELF && is_hvm_domain(d) )
> >     {
> > +        if ( !is_hvm_pv_evtchn_domain(d) )
> > +        {
> > +            ret = -EINVAL;
> > +            goto free_domain;
> > +        }
> >         ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
> >         goto free_domain;
> >     }
> 
--8323329-87990123-1327932724=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-87990123-1327932724=:3196--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:14:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1Rrs09-00060Y-Sv; Mon, 30 Jan 2012 14:14:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paulian@marinca.net>) id 1Rrs09-00060T-Dt
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:14:33 +0000
X-Env-Sender: paulian@marinca.net
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327932754!61760823!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4026 invoked from network); 30 Jan 2012 14:12:34 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:12:34 -0000
Received: by werb14 with SMTP id b14so13370759wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 06:14:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.138.42 with SMTP id z42mr7330357wei.13.1327932871941; Mon,
	30 Jan 2012 06:14:31 -0800 (PST)
Received: by 10.216.17.83 with HTTP; Mon, 30 Jan 2012 06:14:31 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201301409470.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
	<alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
	<CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
	<alpine.DEB.2.00.1201301409470.3196@kaball-desktop>
Date: Mon, 30 Jan 2012 14:14:31 +0000
Message-ID: <CAFFE2at5kZ3BKTGcxyE--kj_JAaWLVyu6aYHnkfZjq3cmzLaZw@mail.gmail.com>
From: Paulian Bogdan Marinca <paulian@marinca.net>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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 attach my kernel config (btw is actually a 3.0.6 kernel not 3.2.1)
>>
>> I will try to apply your patch against XEN.
>
> In that case it is a matter of protecting Xen against misbehaving
> guests, so I would rather have the patch below than try to handle the
> case correctly.
>
>
>
>> > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
>> > index df92cc7..7d89ed6 100644
>> > --- a/xen/arch/x86/physdev.c
>> > +++ b/xen/arch/x86/physdev.c
>> > @@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *=
index, int *pirq_p,
>> >
>> > =A0 =A0 if ( domid =3D=3D DOMID_SELF && is_hvm_domain(d) )
>> > =A0 =A0 {
>> > + =A0 =A0 =A0 =A0if ( !is_hvm_pv_evtchn_domain(d) )
>> > + =A0 =A0 =A0 =A0{
>> > + =A0 =A0 =A0 =A0 =A0 =A0ret =3D -EINVAL;
>> > + =A0 =A0 =A0 =A0 =A0 =A0goto free_domain;
>> > + =A0 =A0 =A0 =A0}
>> > =A0 =A0 =A0 =A0 ret =3D physdev_hvm_map_pirq(d, type, index, pirq_p);
>> > =A0 =A0 =A0 =A0 goto free_domain;
>> > =A0 =A0 }
>>

I tested the patch and yes, it prevents Xen being locked up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:14:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1Rrs09-00060Y-Sv; Mon, 30 Jan 2012 14:14:33 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paulian@marinca.net>) id 1Rrs09-00060T-Dt
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:14:33 +0000
X-Env-Sender: paulian@marinca.net
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327932754!61760823!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4026 invoked from network); 30 Jan 2012 14:12:34 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:12:34 -0000
Received: by werb14 with SMTP id b14so13370759wer.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 06:14:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.138.42 with SMTP id z42mr7330357wei.13.1327932871941; Mon,
	30 Jan 2012 06:14:31 -0800 (PST)
Received: by 10.216.17.83 with HTTP; Mon, 30 Jan 2012 06:14:31 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201301409470.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
	<alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
	<CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
	<alpine.DEB.2.00.1201301409470.3196@kaball-desktop>
Date: Mon, 30 Jan 2012 14:14:31 +0000
Message-ID: <CAFFE2at5kZ3BKTGcxyE--kj_JAaWLVyu6aYHnkfZjq3cmzLaZw@mail.gmail.com>
From: Paulian Bogdan Marinca <paulian@marinca.net>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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 attach my kernel config (btw is actually a 3.0.6 kernel not 3.2.1)
>>
>> I will try to apply your patch against XEN.
>
> In that case it is a matter of protecting Xen against misbehaving
> guests, so I would rather have the patch below than try to handle the
> case correctly.
>
>
>
>> > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
>> > index df92cc7..7d89ed6 100644
>> > --- a/xen/arch/x86/physdev.c
>> > +++ b/xen/arch/x86/physdev.c
>> > @@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *=
index, int *pirq_p,
>> >
>> > =A0 =A0 if ( domid =3D=3D DOMID_SELF && is_hvm_domain(d) )
>> > =A0 =A0 {
>> > + =A0 =A0 =A0 =A0if ( !is_hvm_pv_evtchn_domain(d) )
>> > + =A0 =A0 =A0 =A0{
>> > + =A0 =A0 =A0 =A0 =A0 =A0ret =3D -EINVAL;
>> > + =A0 =A0 =A0 =A0 =A0 =A0goto free_domain;
>> > + =A0 =A0 =A0 =A0}
>> > =A0 =A0 =A0 =A0 ret =3D physdev_hvm_map_pirq(d, type, index, pirq_p);
>> > =A0 =A0 =A0 =A0 goto free_domain;
>> > =A0 =A0 }
>>

I tested the patch and yes, it prevents Xen being locked up.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:15:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:15:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrs0N-00061M-AB; Mon, 30 Jan 2012 14:14:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rrs0L-00060w-OL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:14:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327932879!13143937!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16369 invoked from network); 30 Jan 2012 14:14:39 -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;
	30 Jan 2012 14:14:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10367110"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:14:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 14:14:39 +0000
Date: Mon, 30 Jan 2012 14:16:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201301220280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
	<1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-ID: <alpine.DEB.2.00.1201301224361.3196@kaball-desktop>
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 v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Shriram Rajagopalan wrote:
> If there is an error in applying the toolstack state, then pagebuf_get returns -1 and
> the rest of the code would still attempt to resume the domain, with possibly
> inconsistent device model state.

This sounds like an unhandled error in the caller of pagebuf_get.
I think that if pagebuf_get returns an error, the error should be
propagated and the migration should be aborted, right?
After all I don't think we can successfully resume the domain if we fail
to read XC_SAVE_ID_TSC_INFO, for example.
I think we need something like this:


@@ -1589,9 +1616,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     // DPRINTF("Buffered checkpoint\n");
 
-    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
+    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
         PERROR("error when buffering batch, finishing");
-        goto finish;
+        goto out;
     }
     memset(&tmptail, 0, sizeof(tmptail));
     tmptail.ishvm = hvm;


> Also, lets say there was no error in applying the toolstack state. If a network
> error occurs while receiving the next XC_SAVE_ID or so, then again, the code following
> the above snippet would attempt to resume the domain, with a memory state inconsistent
> with the device state.

This seems wrong to me, but I am not very familiar with this protocol.
As I wrote above, why should we continue if pagebuf_get returns an
error?


> The right place to call the callbacks->toolstack_restore would be after the finish_hvm:
> label, where currently the old QEMU device state is restored.

Are you suggesting that we should read the toolstack data from
pagebuf_get but only call the callback after finish_hvm?
I can do that but honestly it doesn't make too much sense to me.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:15:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:15:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrs0N-00061M-AB; Mon, 30 Jan 2012 14:14:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rrs0L-00060w-OL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:14:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1327932879!13143937!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16369 invoked from network); 30 Jan 2012 14:14:39 -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;
	30 Jan 2012 14:14:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10367110"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:14:39 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 14:14:39 +0000
Date: Mon, 30 Jan 2012 14:16:10 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201301220280.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
	<1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-ID: <alpine.DEB.2.00.1201301224361.3196@kaball-desktop>
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 v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Shriram Rajagopalan wrote:
> If there is an error in applying the toolstack state, then pagebuf_get returns -1 and
> the rest of the code would still attempt to resume the domain, with possibly
> inconsistent device model state.

This sounds like an unhandled error in the caller of pagebuf_get.
I think that if pagebuf_get returns an error, the error should be
propagated and the migration should be aborted, right?
After all I don't think we can successfully resume the domain if we fail
to read XC_SAVE_ID_TSC_INFO, for example.
I think we need something like this:


@@ -1589,9 +1616,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     // DPRINTF("Buffered checkpoint\n");
 
-    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
+    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
         PERROR("error when buffering batch, finishing");
-        goto finish;
+        goto out;
     }
     memset(&tmptail, 0, sizeof(tmptail));
     tmptail.ishvm = hvm;


> Also, lets say there was no error in applying the toolstack state. If a network
> error occurs while receiving the next XC_SAVE_ID or so, then again, the code following
> the above snippet would attempt to resume the domain, with a memory state inconsistent
> with the device state.

This seems wrong to me, but I am not very familiar with this protocol.
As I wrote above, why should we continue if pagebuf_get returns an
error?


> The right place to call the callbacks->toolstack_restore would be after the finish_hvm:
> label, where currently the old QEMU device state is restored.

Are you suggesting that we should read the toolstack data from
pagebuf_get but only call the callback after finish_hvm?
I can do that but honestly it doesn't make too much sense to me.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:17:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrs2Q-0006FN-W6; Mon, 30 Jan 2012 14:16:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rrs2P-0006F6-Bm
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:16:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327932983!57699260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31963 invoked from network); 30 Jan 2012 14:16:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10367191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:16: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, 30 Jan 2012 14:16:52 +0000
Date: Mon, 30 Jan 2012 14:18:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paulian Bogdan Marinca <paulian@marinca.net>
In-Reply-To: <CAFFE2at5kZ3BKTGcxyE--kj_JAaWLVyu6aYHnkfZjq3cmzLaZw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201301418090.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
	<alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
	<CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
	<alpine.DEB.2.00.1201301409470.3196@kaball-desktop>
	<CAFFE2at5kZ3BKTGcxyE--kj_JAaWLVyu6aYHnkfZjq3cmzLaZw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1119101427-1327933118=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-1119101427-1327933118=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 30 Jan 2012, Paulian Bogdan Marinca wrote:
> >>
> >> I attach my kernel config (btw is actually a 3.0.6 kernel not 3.2.1)
> >>
> >> I will try to apply your patch against XEN.
> >
> > In that case it is a matter of protecting Xen against misbehaving
> > guests, so I would rather have the patch below than try to handle the
> > case correctly.
> >
> >
> >
> >> > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> >> > index df92cc7..7d89ed6 100644
> >> > --- a/xen/arch/x86/physdev.c
> >> > +++ b/xen/arch/x86/physdev.c
> >> > @@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
> >> >
> >> >     if ( domid == DOMID_SELF && is_hvm_domain(d) )
> >> >     {
> >> > +        if ( !is_hvm_pv_evtchn_domain(d) )
> >> > +        {
> >> > +            ret = -EINVAL;
> >> > +            goto free_domain;
> >> > +        }
> >> >         ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
> >> >         goto free_domain;
> >> >     }
> >>
> 
> I tested the patch and yes, it prevents Xen being locked up.
> 

Thanks, I'll resend and add your tested-by
--8323329-1119101427-1327933118=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1119101427-1327933118=:3196--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:17:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:17:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrs2Q-0006FN-W6; Mon, 30 Jan 2012 14:16:54 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1Rrs2P-0006F6-Bm
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:16:53 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327932983!57699260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31963 invoked from network); 30 Jan 2012 14:16:23 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:16:23 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10367191"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:16: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, 30 Jan 2012 14:16:52 +0000
Date: Mon, 30 Jan 2012 14:18:23 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paulian Bogdan Marinca <paulian@marinca.net>
In-Reply-To: <CAFFE2at5kZ3BKTGcxyE--kj_JAaWLVyu6aYHnkfZjq3cmzLaZw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201301418090.3196@kaball-desktop>
References: <CB495E98.29F01%keir.xen@gmail.com>
	<alpine.DEB.2.00.1201301117300.3196@kaball-desktop>
	<CAFFE2as2REe3vq9=CHWbU75vjtxzTyt-5AU7gyebz=mwNipQ5g@mail.gmail.com>
	<alpine.DEB.2.00.1201301409470.3196@kaball-desktop>
	<CAFFE2at5kZ3BKTGcxyE--kj_JAaWLVyu6aYHnkfZjq3cmzLaZw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1119101427-1327933118=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] XEN 4.1.3-rc1 bug, spinlock acquired twice
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-1119101427-1327933118=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 30 Jan 2012, Paulian Bogdan Marinca wrote:
> >>
> >> I attach my kernel config (btw is actually a 3.0.6 kernel not 3.2.1)
> >>
> >> I will try to apply your patch against XEN.
> >
> > In that case it is a matter of protecting Xen against misbehaving
> > guests, so I would rather have the patch below than try to handle the
> > case correctly.
> >
> >
> >
> >> > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
> >> > index df92cc7..7d89ed6 100644
> >> > --- a/xen/arch/x86/physdev.c
> >> > +++ b/xen/arch/x86/physdev.c
> >> > @@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
> >> >
> >> >     if ( domid == DOMID_SELF && is_hvm_domain(d) )
> >> >     {
> >> > +        if ( !is_hvm_pv_evtchn_domain(d) )
> >> > +        {
> >> > +            ret = -EINVAL;
> >> > +            goto free_domain;
> >> > +        }
> >> >         ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
> >> >         goto free_domain;
> >> >     }
> >>
> 
> I tested the patch and yes, it prevents Xen being locked up.
> 

Thanks, I'll resend and add your tested-by
--8323329-1119101427-1327933118=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1119101427-1327933118=:3196--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsBw-0006j8-R4; Mon, 30 Jan 2012 14:26:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RrsBv-0006j0-IW
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:26:43 +0000
Received: from [85.158.138.51:44825] by server-12.bemta-3.messagelabs.com id
	D8/1A-24557-2A8A62F4; Mon, 30 Jan 2012 14:26:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327933601!11255341!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11254 invoked from network); 30 Jan 2012 14:26:42 -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;
	30 Jan 2012 14:26:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10367517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:26: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; Mon, 30 Jan 2012 14:26:41 +0000
Date: Mon, 30 Jan 2012 14:28: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.1201301426270.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, Paulian Bogdan Marinca <paulian@marinca.net>
Subject: [Xen-devel] [PATCH] xen: do not remap pirqs if
	!is_hvm_pv_evtchn_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

If the guest is an HVM guest and it is not using the vector callback
mechanism, refuse to remap pirqs onto event channels.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Paulian Bogdan Marinca <paulian@marinca.net>

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index f280c28..2173097 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
 
     if ( domid == DOMID_SELF && is_hvm_domain(d) )
     {
+        if ( !is_hvm_pv_evtchn_domain(d) )
+        {
+            ret = -EINVAL;
+            goto free_domain;
+        }
         ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
         goto free_domain;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:27:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:27:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsBw-0006j8-R4; Mon, 30 Jan 2012 14:26:44 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RrsBv-0006j0-IW
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:26:43 +0000
Received: from [85.158.138.51:44825] by server-12.bemta-3.messagelabs.com id
	D8/1A-24557-2A8A62F4; Mon, 30 Jan 2012 14:26:42 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-174.messagelabs.com!1327933601!11255341!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11254 invoked from network); 30 Jan 2012 14:26:42 -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;
	30 Jan 2012 14:26:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10367517"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:26: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; Mon, 30 Jan 2012 14:26:41 +0000
Date: Mon, 30 Jan 2012 14:28: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.1201301426270.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Keir Fraser <keir@xen.org>, Paulian Bogdan Marinca <paulian@marinca.net>
Subject: [Xen-devel] [PATCH] xen: do not remap pirqs if
	!is_hvm_pv_evtchn_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

If the guest is an HVM guest and it is not using the vector callback
mechanism, refuse to remap pirqs onto event channels.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Paulian Bogdan Marinca <paulian@marinca.net>

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index f280c28..2173097 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -93,6 +93,11 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int *pirq_p,
 
     if ( domid == DOMID_SELF && is_hvm_domain(d) )
     {
+        if ( !is_hvm_pv_evtchn_domain(d) )
+        {
+            ret = -EINVAL;
+            goto free_domain;
+        }
         ret = physdev_hvm_map_pirq(d, type, index, pirq_p);
         goto free_domain;
     }

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:30:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsFT-0006xP-Hu; Mon, 30 Jan 2012 14:30:23 +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 1RrsFR-0006x2-8k
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:30:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327933815!12690313!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31150 invoked from network); 30 Jan 2012 14:30:15 -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;
	30 Jan 2012 14:30:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10367633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:30: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, 30 Jan 2012 14:30:15 +0000
Date: Mon, 30 Jan 2012 14:31:46 +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.1201301429530.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen pvhvm: do not remap pirqs onto evtchns if
 !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 492ade8..d99346e 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -374,7 +374,7 @@ int __init pci_xen_init(void)
 
 int __init pci_xen_hvm_init(void)
 {
-	if (!xen_feature(XENFEAT_hvm_pirqs))
+	if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
 		return 0;
 
 #ifdef CONFIG_ACPI

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:30:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:30:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsFT-0006xP-Hu; Mon, 30 Jan 2012 14:30:23 +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 1RrsFR-0006x2-8k
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:30:21 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1327933815!12690313!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31150 invoked from network); 30 Jan 2012 14:30:15 -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;
	30 Jan 2012 14:30:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10367633"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:30: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, 30 Jan 2012 14:30:15 +0000
Date: Mon, 30 Jan 2012 14:31:46 +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.1201301429530.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH] xen pvhvm: do not remap pirqs onto evtchns if
 !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
index 492ade8..d99346e 100644
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -374,7 +374,7 @@ int __init pci_xen_init(void)
 
 int __init pci_xen_hvm_init(void)
 {
-	if (!xen_feature(XENFEAT_hvm_pirqs))
+	if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
 		return 0;
 
 #ifdef CONFIG_ACPI

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUK-0007Gb-Cj; Mon, 30 Jan 2012 14:45:44 +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 1RrsUI-0007FL-6Y
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31914 invoked from network); 30 Jan 2012 14:45:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614354"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:35 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTZ029057;
	Mon, 30 Jan 2012 06:45:33 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:20 +0000
Message-ID: <1327934734-8908-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 02/16] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Enables users to unload netback module.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   14 ++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 288b2f3..372c7f5 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -126,6 +126,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index d11205f..3059684 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1670,5 +1670,19 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int i;
+	xenvif_xenbus_exit();
+	for (i = 0; i < xen_netbk_group_nr; i++) {
+		struct xen_netbk *netbk = &xen_netbk[i];
+		del_timer_sync(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+	page_pool_destroy();
+}
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUK-0007Gb-Cj; Mon, 30 Jan 2012 14:45:44 +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 1RrsUI-0007FL-6Y
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31914 invoked from network); 30 Jan 2012 14:45:35 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614354"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:35 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTZ029057;
	Mon, 30 Jan 2012 06:45:33 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:20 +0000
Message-ID: <1327934734-8908-3-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 02/16] netback: add module unload
	function.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Enables users to unload netback module.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |    1 +
 drivers/net/xen-netback/netback.c |   14 ++++++++++++++
 drivers/net/xen-netback/xenbus.c  |    5 +++++
 3 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 288b2f3..372c7f5 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -126,6 +126,7 @@ void xenvif_get(struct xenvif *vif);
 void xenvif_put(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
+void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index d11205f..3059684 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1670,5 +1670,19 @@ failed_init:
 
 module_init(netback_init);
 
+static void __exit netback_exit(void)
+{
+	int i;
+	xenvif_xenbus_exit();
+	for (i = 0; i < xen_netbk_group_nr; i++) {
+		struct xen_netbk *netbk = &xen_netbk[i];
+		del_timer_sync(&netbk->net_timer);
+		kthread_stop(netbk->task);
+	}
+	vfree(xen_netbk);
+	page_pool_destroy();
+}
+module_exit(netback_exit);
+
 MODULE_LICENSE("Dual BSD/GPL");
 MODULE_ALIAS("xen-backend:vif");
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 410018c..65d14f2 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -485,3 +485,8 @@ int xenvif_xenbus_init(void)
 {
 	return xenbus_register_backend(&netback_driver);
 }
+
+void xenvif_xenbus_exit(void)
+{
+	return xenbus_unregister_driver(&netback_driver);
+}
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUK-0007GS-0k; Mon, 30 Jan 2012 14:45:44 +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 1RrsUG-0007FK-J7
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31769 invoked from network); 30 Jan 2012 14:45:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614339"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45:32 -0500
Received: from smtp01.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, 30 Jan 2012 09:45:32 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTX029057;
	Mon, 30 Jan 2012 06:45:30 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:18 +0000
Message-ID: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3] Xen netback / netfront improvement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since this series includes both netback and netfront changes, the
whole series is named as "Xen netback / netfront improvement".

Changes in V3:
 - Rework of per-cpu scratch space
 - Multi page ring support
 - Split event channels
 - Rx protocol stub
 - Fix a minor bug in module_put path

Changes in V2:
 - Fix minor bugs in V1
 - Embed pending_tx_info into page pool
 - Per-cpu scratch space
 - Notification code path clean up

This version has been tested by 
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

V1:
A new netback implementation which includes three major features:

 - Global page pool support
 - NAPI + kthread 1:1 model
 - Netback internal name changes

This patch series is the foundation of furture work. So it is better
to get it right first. Patch 1 and 3 have the real meat.

The first benifit of 1:1 model will be scheduling fairness.

The rational behind a global page pool is that we need to limit
overall memory consumed by all vifs.

Utilization of NAPI enables the possibility to mitigate
interrupts/events, the code path is cleaned up in a separated patch.

Netback internal changes cleans up the code structure after switching
to 1:1 model. It also prepares netback for further code layout
changes.

----
 drivers/net/xen-netback/Makefile              |    2 +-
 drivers/net/xen-netback/common.h              |  149 ++-
 drivers/net/xen-netback/interface.c           |  256 ++++--
 drivers/net/xen-netback/netback.c             | 1344 +++++++------------------
 drivers/net/xen-netback/page_pool.c           |  185 ++++
 drivers/net/xen-netback/page_pool.h           |   66 ++
 drivers/net/xen-netback/xenbus.c              |  185 ++++-
 drivers/net/xen-netback/xenvif_rx_protocol0.c |  616 +++++++++++
 drivers/net/xen-netback/xenvif_rx_protocol0.h |   53 +
 drivers/net/xen-netfront.c                    |  399 ++++++--
 10 files changed, 2062 insertions(+), 1193 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUK-0007GS-0k; Mon, 30 Jan 2012 14:45:44 +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 1RrsUG-0007FK-J7
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31769 invoked from network); 30 Jan 2012 14:45:34 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614339"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45:32 -0500
Received: from smtp01.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, 30 Jan 2012 09:45:32 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTX029057;
	Mon, 30 Jan 2012 06:45:30 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:18 +0000
Message-ID: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
MIME-Version: 1.0
Cc: ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3] Xen netback / netfront improvement
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since this series includes both netback and netfront changes, the
whole series is named as "Xen netback / netfront improvement".

Changes in V3:
 - Rework of per-cpu scratch space
 - Multi page ring support
 - Split event channels
 - Rx protocol stub
 - Fix a minor bug in module_put path

Changes in V2:
 - Fix minor bugs in V1
 - Embed pending_tx_info into page pool
 - Per-cpu scratch space
 - Notification code path clean up

This version has been tested by 
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

V1:
A new netback implementation which includes three major features:

 - Global page pool support
 - NAPI + kthread 1:1 model
 - Netback internal name changes

This patch series is the foundation of furture work. So it is better
to get it right first. Patch 1 and 3 have the real meat.

The first benifit of 1:1 model will be scheduling fairness.

The rational behind a global page pool is that we need to limit
overall memory consumed by all vifs.

Utilization of NAPI enables the possibility to mitigate
interrupts/events, the code path is cleaned up in a separated patch.

Netback internal changes cleans up the code structure after switching
to 1:1 model. It also prepares netback for further code layout
changes.

----
 drivers/net/xen-netback/Makefile              |    2 +-
 drivers/net/xen-netback/common.h              |  149 ++-
 drivers/net/xen-netback/interface.c           |  256 ++++--
 drivers/net/xen-netback/netback.c             | 1344 +++++++------------------
 drivers/net/xen-netback/page_pool.c           |  185 ++++
 drivers/net/xen-netback/page_pool.h           |   66 ++
 drivers/net/xen-netback/xenbus.c              |  185 ++++-
 drivers/net/xen-netback/xenvif_rx_protocol0.c |  616 +++++++++++
 drivers/net/xen-netback/xenvif_rx_protocol0.h |   53 +
 drivers/net/xen-netfront.c                    |  399 ++++++--
 10 files changed, 2062 insertions(+), 1193 deletions(-)



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUL-0007H9-Qr; Mon, 30 Jan 2012 14:45:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUJ-0007GE-VL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:44 +0000
Received: from [85.158.138.51:58590] by server-2.bemta-3.messagelabs.com id
	84/ED-24515-71DA62F4; Mon, 30 Jan 2012 14:45:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16767 invoked from network); 30 Jan 2012 14:45:41 -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;
	30 Jan 2012 14:45:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413498"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:40 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTd029057;
	Mon, 30 Jan 2012 06:45:38 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:24 +0000
Message-ID: <1327934734-8908-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 06/16] netback: melt xen_netbk into xenvif
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, there is no need to keep xen_netbk and xenvif
separated.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   36 +++---
 drivers/net/xen-netback/interface.c |   36 +++----
 drivers/net/xen-netback/netback.c   |  213 +++++++++++++----------------------
 drivers/net/xen-netback/page_pool.c |   10 +-
 drivers/net/xen-netback/page_pool.h |   13 ++-
 5 files changed, 122 insertions(+), 186 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 3b85563..17d4e1a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,34 +45,29 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#include "page_pool.h"
+
 struct netbk_rx_meta {
 	int id;
 	int size;
 	int gso_size;
 };
 
-#define MAX_PENDING_REQS 256
-
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-};
-typedef unsigned int pending_ring_idx_t;
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
 
-struct xen_netbk;
+#define MAX_PENDING_REQS 256
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
-	/* Reference to netback processing backend. */
-	struct xen_netbk *netbk;
-
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -115,6 +110,16 @@ struct xenvif {
 
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
+
+	struct sk_buff_head rx_queue;
+	struct sk_buff_head tx_queue;
+
+	idx_t mmap_pages[MAX_PENDING_REQS];
+
+	pending_ring_idx_t pending_prod;
+	pending_ring_idx_t pending_cons;
+
+	u16 pending_ring[MAX_PENDING_REQS];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +127,6 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
@@ -161,12 +163,8 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-/* Allocate and free xen_netbk structure */
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
-void xen_netbk_free_netbk(struct xen_netbk *netbk);
-
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
-void xen_netbk_rx_action(struct xen_netbk *netbk);
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
+void xen_netbk_rx_action(struct xenvif *vif);
 
 int xen_netbk_kthread(void *data);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 7914f60..3c004fa 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -55,9 +55,6 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (vif->netbk == NULL)
-		return IRQ_NONE;
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
@@ -72,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+	xen_netbk_tx_action(vif, &work_done, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -95,7 +92,8 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	BUG_ON(skb->dev != dev);
 
-	if (vif->netbk == NULL)
+	/* Drop the packet if vif is not ready */
+	if (vif->task == NULL)
 		goto drop;
 
 	/* Drop the packet if the target domain has no receive buffers. */
@@ -257,6 +255,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	int err;
 	struct net_device *dev;
 	struct xenvif *vif;
+	int i;
 	char name[IFNAMSIZ] = {};
 
 	snprintf(name, IFNAMSIZ - 1, "vif%u.%u", domid, handle);
@@ -271,7 +270,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk = NULL;
 
 	vif->can_sg = 1;
 	vif->csum = 1;
@@ -290,6 +288,17 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 
 	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
 
+	skb_queue_head_init(&vif->rx_queue);
+	skb_queue_head_init(&vif->tx_queue);
+
+	vif->pending_cons = 0;
+	vif->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->mmap_pages[i] = INVALID_ENTRY;
+
 	/*
 	 * Initialise a dummy MAC address. We choose the numerically
 	 * largest non-broadcast address to prevent the address getting
@@ -337,14 +346,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	vif->netbk = xen_netbk_alloc_netbk(vif);
-	if (!vif->netbk) {
-		pr_warn("Could not allocate xen_netbk\n");
-		err = -ENOMEM;
-		goto err_unbind;
-	}
-
-
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xen_netbk_kthread,
 				   (void *)vif,
@@ -352,7 +353,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (IS_ERR(vif->task)) {
 		pr_warn("Could not create kthread\n");
 		err = PTR_ERR(vif->task);
-		goto err_free_netbk;
+		goto err_unbind;
 	}
 
 	rtnl_lock();
@@ -367,8 +368,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	wake_up_process(vif->task);
 
 	return 0;
-err_free_netbk:
-	xen_netbk_free_netbk(vif->netbk);
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
@@ -394,9 +393,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	if (vif->task)
 		kthread_stop(vif->task);
 
-	if (vif->netbk)
-		xen_netbk_free_netbk(vif->netbk);
-
 	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1c68afb..0a52bb1 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -59,28 +59,13 @@ struct gnttab_copy *tx_copy_ops;
 struct gnttab_copy *grant_copy_op;
 struct netbk_rx_meta *meta;
 
-
-struct xen_netbk {
-	struct sk_buff_head rx_queue;
-	struct sk_buff_head tx_queue;
-
-	idx_t mmap_pages[MAX_PENDING_REQS];
-
-	pending_ring_idx_t pending_prod;
-	pending_ring_idx_t pending_cons;
-
-	struct xenvif *vif;
-
-	u16 pending_ring[MAX_PENDING_REQS];
-};
-
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
 
-static inline int tx_work_todo(struct xen_netbk *netbk);
-static inline int rx_work_todo(struct xen_netbk *netbk);
+static inline int tx_work_todo(struct xenvif *vif);
+static inline int rx_work_todo(struct xenvif *vif);
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
@@ -89,16 +74,16 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      size,
 					     u16      flags);
 
-static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
+static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
-	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
+	return page_to_pfn(to_page(vif->mmap_pages[idx]));
 }
 
-static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
+static inline unsigned long idx_to_kaddr(struct xenvif *vif,
 					 u16 idx)
 {
-	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
+	return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
 }
 
 /*
@@ -126,10 +111,10 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 	return i & (MAX_PENDING_REQS-1);
 }
 
-static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
+static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 {
 	return MAX_PENDING_REQS -
-		netbk->pending_prod + netbk->pending_cons;
+		vif->pending_prod + vif->pending_cons;
 }
 
 static int max_required_rx_slots(struct xenvif *vif)
@@ -316,9 +301,9 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
-			struct xen_netbk *rnetbk = to_netbk(idx);
+			struct xenvif *rvif = to_vif(idx);
 
-			copy_gop->source.domid = rnetbk->vif->domid;
+			copy_gop->source.domid = rvif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -476,16 +461,13 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xenvif *vif)
 {
-	struct xenvif *vif = netbk->vif;
-
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xen_netbk *netbk)
+void xen_netbk_rx_action(struct xenvif *vif)
 {
-	struct xenvif *vif = NULL;
 	s8 status;
 	u16 flags;
 	struct xen_netif_rx_response *resp;
@@ -511,7 +493,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	count = 0;
 
-	while ((skb = skb_dequeue(&netbk->rx_queue)) != NULL) {
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
 		vif = netdev_priv(skb->dev);
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
@@ -543,8 +525,6 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	while ((skb = __skb_dequeue(&rxq)) != NULL) {
 		sco = (struct skb_cb_overlay *)skb->cb;
 
-		vif = netdev_priv(skb->dev);
-
 		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
@@ -616,8 +596,8 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
 
-	if (!skb_queue_empty(&netbk->rx_queue))
-		xen_netbk_kick_thread(netbk);
+	if (!skb_queue_empty(&vif->rx_queue))
+		xen_netbk_kick_thread(vif);
 
 	put_cpu_ptr(gco);
 	put_cpu_ptr(m);
@@ -625,11 +605,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	struct xen_netbk *netbk = vif->netbk;
+	skb_queue_tail(&vif->rx_queue, skb);
 
-	skb_queue_tail(&netbk->rx_queue, skb);
-
-	xen_netbk_kick_thread(netbk);
+	xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
@@ -728,21 +706,20 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
+static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 					 struct sk_buff *skb,
 					 u16 pending_idx)
 {
 	struct page *page;
 	int idx;
-	page = page_pool_get(netbk, &idx);
+	page = page_pool_get(vif, &idx);
 	if (!page)
 		return NULL;
-	netbk->mmap_pages[pending_idx] = idx;
+	vif->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
-						  struct xenvif *vif,
+static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 						  struct sk_buff *skb,
 						  struct xen_netif_tx_request *txp,
 						  struct gnttab_copy *gop)
@@ -761,13 +738,13 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		int idx;
 		struct pending_tx_info *pending_tx_info;
 
-		index = pending_index(netbk->pending_cons++);
-		pending_idx = netbk->pending_ring[index];
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		gop->source.u.ref = txp->gref;
@@ -791,7 +768,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
+static int xen_netbk_tx_check_gop(struct xenvif *vif,
 				  struct sk_buff *skb,
 				  struct gnttab_copy **gopp)
 {
@@ -799,8 +776,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = netbk->vif;
-
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -810,12 +785,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	err = gop->status;
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		idx = netbk->mmap_pages[index];
+		index = pending_index(vif->pending_prod++);
+		idx = vif->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
+		vif->pending_ring[index] = pending_idx;
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -832,16 +807,16 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(vif, pending_idx);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
+		index = pending_index(vif->pending_prod++);
+		vif->pending_ring[index] = pending_idx;
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -849,10 +824,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -863,7 +838,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
+static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -879,11 +854,11 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
-		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
+		page = virt_to_page(idx_to_kaddr(vif, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
 		skb->data_len += txp->size;
@@ -891,7 +866,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 	}
 }
 
@@ -1052,15 +1027,14 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 					struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
-	struct xenvif *vif = netbk->vif;
 
-	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
+	while ((nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1128,8 +1102,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 			break;
 		}
 
-		index = pending_index(netbk->pending_cons);
-		pending_idx = netbk->pending_ring[index];
+		index = pending_index(vif->pending_cons);
+		pending_idx = vif->pending_ring[index];
 
 		data_len = (txreq.size > PKT_PROT_LEN &&
 			    ret < MAX_SKB_FRAGS) ?
@@ -1159,7 +1133,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
@@ -1179,7 +1153,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 
 		gop++;
 
-		pool_idx = netbk->mmap_pages[pending_idx];
+		pool_idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(pool_idx);
 
 		memcpy(&pending_tx_info->req,
@@ -1199,11 +1173,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
+		__skb_queue_tail(&vif->tx_queue, skb);
 
-		netbk->pending_cons++;
+		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(netbk, vif,
+		request_gop = xen_netbk_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
@@ -1222,16 +1196,15 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 	return gop - tco;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+static void xen_netbk_tx_submit(struct xenvif *vif,
 				struct gnttab_copy *tco,
 				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
-	struct xenvif *vif = netbk->vif;
 
 	while ((*work_done < budget) &&
-	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
 		unsigned data_len;
@@ -1240,13 +1213,13 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		pending_idx = *((u16 *)skb->data);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
+		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1255,7 +1228,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		data_len = skb->len;
 		memcpy(skb->data,
-		       (void *)(idx_to_kaddr(netbk, pending_idx)|txp->offset),
+		       (void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
 		       data_len);
 		if (data_len < txp->size) {
 			/* Append the packet payload as a fragment. */
@@ -1263,7 +1236,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1271,7 +1244,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(netbk, skb);
+		xen_netbk_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1303,53 +1276,52 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 	struct gnttab_copy *tco;
 
-	if (unlikely(!tx_work_todo(netbk)))
+	if (unlikely(!tx_work_todo(vif)))
 		return;
 
 	tco = get_cpu_ptr(tx_copy_ops);
 
-	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+	nr_gops = xen_netbk_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_ptr(tco);
-		return 0;
+		return;
 	}
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, tco, work_done, budget);
+	xen_netbk_tx_submit(vif, tco, work_done, budget);
 	put_cpu_ptr(tco);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
 {
-	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
+	if (vif->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	idx = netbk->mmap_pages[pending_idx];
+	idx = vif->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
-	index = pending_index(netbk->pending_prod++);
-	netbk->pending_ring[index] = pending_idx;
+	index = pending_index(vif->pending_prod++);
+	vif->pending_ring[index] = pending_idx;
 
-	page_pool_put(netbk->mmap_pages[pending_idx]);
+	page_pool_put(vif->mmap_pages[pending_idx]);
 
-	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
+	vif->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1396,15 +1368,15 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 	return resp;
 }
 
-static inline int rx_work_todo(struct xen_netbk *netbk)
+static inline int rx_work_todo(struct xenvif *vif)
 {
-	return !skb_queue_empty(&netbk->rx_queue);
+	return !skb_queue_empty(&vif->rx_queue);
 }
 
-static inline int tx_work_todo(struct xen_netbk *netbk)
+static inline int tx_work_todo(struct xenvif *vif)
 {
-	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
-	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
+	    (nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
@@ -1455,54 +1427,21 @@ err:
 	return err;
 }
 
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
-{
-	int i;
-	struct xen_netbk *netbk;
-
-	netbk = vzalloc(sizeof(struct xen_netbk));
-	if (!netbk) {
-		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return NULL;
-	}
-
-	netbk->vif = vif;
-
-	skb_queue_head_init(&netbk->rx_queue);
-	skb_queue_head_init(&netbk->tx_queue);
-
-	netbk->pending_cons = 0;
-	netbk->pending_prod = MAX_PENDING_REQS;
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->pending_ring[i] = i;
-
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->mmap_pages[i] = INVALID_ENTRY;
-
-	return netbk;
-}
-
-void xen_netbk_free_netbk(struct xen_netbk *netbk)
-{
-	vfree(netbk);
-}
-
 int xen_netbk_kthread(void *data)
 {
 	struct xenvif *vif = data;
-	struct xen_netbk *netbk = vif->netbk;
 
 	while (!kthread_should_stop()) {
 		wait_event_interruptible(vif->wq,
-					 rx_work_todo(netbk) ||
+					 rx_work_todo(vif) ||
 					 kthread_should_stop());
 		cond_resched();
 
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
+		if (rx_work_todo(vif))
+			xen_netbk_rx_action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
index 294f48b..ce00a93 100644
--- a/drivers/net/xen-netback/page_pool.c
+++ b/drivers/net/xen-netback/page_pool.c
@@ -102,7 +102,7 @@ int is_in_pool(struct page *page, int *pidx)
 	return get_page_ext(page, pidx);
 }
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+struct page *page_pool_get(struct xenvif *vif, int *pidx)
 {
 	int idx;
 	struct page *page;
@@ -118,7 +118,7 @@ struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
 	}
 
 	set_page_ext(page, idx);
-	pool[idx].u.netbk = netbk;
+	pool[idx].u.vif = vif;
 	pool[idx].page = page;
 
 	*pidx = idx;
@@ -131,7 +131,7 @@ void page_pool_put(int idx)
 	struct page *page = pool[idx].page;
 
 	pool[idx].page = NULL;
-	pool[idx].u.netbk = NULL;
+	pool[idx].u.vif = NULL;
 	page->mapping = 0;
 	put_page(page);
 	put_free_entry(idx);
@@ -174,9 +174,9 @@ struct page *to_page(int idx)
 	return pool[idx].page;
 }
 
-struct xen_netbk *to_netbk(int idx)
+struct xenvif *to_vif(int idx)
 {
-	return pool[idx].u.netbk;
+	return pool[idx].u.vif;
 }
 
 struct pending_tx_info *to_txinfo(int idx)
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
index 572b037..efae17c 100644
--- a/drivers/net/xen-netback/page_pool.h
+++ b/drivers/net/xen-netback/page_pool.h
@@ -27,7 +27,10 @@
 #ifndef __PAGE_POOL_H__
 #define __PAGE_POOL_H__
 
-#include "common.h"
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+};
+typedef unsigned int pending_ring_idx_t;
 
 typedef uint32_t idx_t;
 
@@ -38,8 +41,8 @@ struct page_pool_entry {
 	struct page *page;
 	struct pending_tx_info tx_info;
 	union {
-		struct xen_netbk *netbk;
-		idx_t             fl;
+		struct xenvif *vif;
+		idx_t          fl;
 	} u;
 };
 
@@ -52,12 +55,12 @@ int  page_pool_init(void);
 void page_pool_destroy(void);
 
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+struct page *page_pool_get(struct xenvif *vif, int *pidx);
 void         page_pool_put(int idx);
 int          is_in_pool(struct page *page, int *pidx);
 
 struct page            *to_page(int idx);
-struct xen_netbk       *to_netbk(int idx);
+struct xenvif          *to_vif(int idx);
 struct pending_tx_info *to_txinfo(int idx);
 
 #endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUN-0007Ij-QZ; Mon, 30 Jan 2012 14:45:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUM-0007H8-99
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:46 +0000
Received: from [85.158.138.51:58833] by server-12.bemta-3.messagelabs.com id
	14/E6-24557-91DA62F4; Mon, 30 Jan 2012 14:45:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16935 invoked from network); 30 Jan 2012 14:45:44 -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;
	30 Jan 2012 14:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413500"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:42 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTf029057;
	Mon, 30 Jan 2012 06:45:41 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:26 +0000
Message-ID: <1327934734-8908-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 08/16] netback: remove unwanted
	notification generation during NAPI processing.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 original implementation, tx_build_gops tends to update req_event
pointer every time it sees tx error or finish one batch. Remove those
code to only update req_event pointer when we really want to shut down
NAPI.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    5 +++--
 drivers/net/xen-netback/netback.c   |    4 +---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index ebed26a..fe37143 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -58,8 +58,8 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
-	if (likely(napi_schedule_prep(&vif->napi)))
-		__napi_schedule(&vif->napi);
+	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
+		napi_schedule(&vif->napi);
 
 	return IRQ_HANDLED;
 }
@@ -74,6 +74,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	if (work_done < budget) {
 		int more_to_do = 0;
 		unsigned long flag;
+
 		local_irq_save(flag);
 
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2a2835e..065cd65 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -662,7 +662,6 @@ static void xenvif_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xenvif_check_rx_xenvif(vif);
 }
 
 static int xenvif_count_requests(struct xenvif *vif,
@@ -1047,7 +1046,7 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
+		work_to_do = RING_HAS_UNCONSUMED_REQUESTS(&vif->tx);
 		if (!work_to_do) {
 			break;
 		}
@@ -1187,7 +1186,6 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xenvif_check_rx_xenvif(vif);
 
 		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
-- 
1.7.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 Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUL-0007H9-Qr; Mon, 30 Jan 2012 14:45:45 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUJ-0007GE-VL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:44 +0000
Received: from [85.158.138.51:58590] by server-2.bemta-3.messagelabs.com id
	84/ED-24515-71DA62F4; Mon, 30 Jan 2012 14:45:43 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16767 invoked from network); 30 Jan 2012 14:45:41 -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;
	30 Jan 2012 14:45:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413498"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:40 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTd029057;
	Mon, 30 Jan 2012 06:45:38 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:24 +0000
Message-ID: <1327934734-8908-7-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 06/16] netback: melt xen_netbk into xenvif
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, there is no need to keep xen_netbk and xenvif
separated.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   36 +++---
 drivers/net/xen-netback/interface.c |   36 +++----
 drivers/net/xen-netback/netback.c   |  213 +++++++++++++----------------------
 drivers/net/xen-netback/page_pool.c |   10 +-
 drivers/net/xen-netback/page_pool.h |   13 ++-
 5 files changed, 122 insertions(+), 186 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 3b85563..17d4e1a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,34 +45,29 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+#include "page_pool.h"
+
 struct netbk_rx_meta {
 	int id;
 	int size;
 	int gso_size;
 };
 
-#define MAX_PENDING_REQS 256
-
 /* Discriminate from any valid pending_idx value. */
 #define INVALID_PENDING_IDX 0xFFFF
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-};
-typedef unsigned int pending_ring_idx_t;
+#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
+#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
 
-struct xen_netbk;
+#define MAX_PENDING_REQS 256
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
-	/* Reference to netback processing backend. */
-	struct xen_netbk *netbk;
-
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -115,6 +110,16 @@ struct xenvif {
 
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
+
+	struct sk_buff_head rx_queue;
+	struct sk_buff_head tx_queue;
+
+	idx_t mmap_pages[MAX_PENDING_REQS];
+
+	pending_ring_idx_t pending_prod;
+	pending_ring_idx_t pending_cons;
+
+	u16 pending_ring[MAX_PENDING_REQS];
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +127,6 @@ static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
 	return to_xenbus_device(vif->dev->dev.parent);
 }
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-
 struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
@@ -161,12 +163,8 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-/* Allocate and free xen_netbk structure */
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
-void xen_netbk_free_netbk(struct xen_netbk *netbk);
-
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
-void xen_netbk_rx_action(struct xen_netbk *netbk);
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
+void xen_netbk_rx_action(struct xenvif *vif);
 
 int xen_netbk_kthread(void *data);
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 7914f60..3c004fa 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -55,9 +55,6 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (vif->netbk == NULL)
-		return IRQ_NONE;
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
@@ -72,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+	xen_netbk_tx_action(vif, &work_done, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -95,7 +92,8 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	BUG_ON(skb->dev != dev);
 
-	if (vif->netbk == NULL)
+	/* Drop the packet if vif is not ready */
+	if (vif->task == NULL)
 		goto drop;
 
 	/* Drop the packet if the target domain has no receive buffers. */
@@ -257,6 +255,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	int err;
 	struct net_device *dev;
 	struct xenvif *vif;
+	int i;
 	char name[IFNAMSIZ] = {};
 
 	snprintf(name, IFNAMSIZ - 1, "vif%u.%u", domid, handle);
@@ -271,7 +270,6 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk = NULL;
 
 	vif->can_sg = 1;
 	vif->csum = 1;
@@ -290,6 +288,17 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 
 	dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
 
+	skb_queue_head_init(&vif->rx_queue);
+	skb_queue_head_init(&vif->tx_queue);
+
+	vif->pending_cons = 0;
+	vif->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->pending_ring[i] = i;
+
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		vif->mmap_pages[i] = INVALID_ENTRY;
+
 	/*
 	 * Initialise a dummy MAC address. We choose the numerically
 	 * largest non-broadcast address to prevent the address getting
@@ -337,14 +346,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	vif->netbk = xen_netbk_alloc_netbk(vif);
-	if (!vif->netbk) {
-		pr_warn("Could not allocate xen_netbk\n");
-		err = -ENOMEM;
-		goto err_unbind;
-	}
-
-
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xen_netbk_kthread,
 				   (void *)vif,
@@ -352,7 +353,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (IS_ERR(vif->task)) {
 		pr_warn("Could not create kthread\n");
 		err = PTR_ERR(vif->task);
-		goto err_free_netbk;
+		goto err_unbind;
 	}
 
 	rtnl_lock();
@@ -367,8 +368,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	wake_up_process(vif->task);
 
 	return 0;
-err_free_netbk:
-	xen_netbk_free_netbk(vif->netbk);
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
@@ -394,9 +393,6 @@ void xenvif_disconnect(struct xenvif *vif)
 	if (vif->task)
 		kthread_stop(vif->task);
 
-	if (vif->netbk)
-		xen_netbk_free_netbk(vif->netbk);
-
 	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 1c68afb..0a52bb1 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -59,28 +59,13 @@ struct gnttab_copy *tx_copy_ops;
 struct gnttab_copy *grant_copy_op;
 struct netbk_rx_meta *meta;
 
-
-struct xen_netbk {
-	struct sk_buff_head rx_queue;
-	struct sk_buff_head tx_queue;
-
-	idx_t mmap_pages[MAX_PENDING_REQS];
-
-	pending_ring_idx_t pending_prod;
-	pending_ring_idx_t pending_cons;
-
-	struct xenvif *vif;
-
-	u16 pending_ring[MAX_PENDING_REQS];
-};
-
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
 
-static inline int tx_work_todo(struct xen_netbk *netbk);
-static inline int rx_work_todo(struct xen_netbk *netbk);
+static inline int tx_work_todo(struct xenvif *vif);
+static inline int rx_work_todo(struct xenvif *vif);
 
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
@@ -89,16 +74,16 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      size,
 					     u16      flags);
 
-static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
+static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
-	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
+	return page_to_pfn(to_page(vif->mmap_pages[idx]));
 }
 
-static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
+static inline unsigned long idx_to_kaddr(struct xenvif *vif,
 					 u16 idx)
 {
-	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
+	return (unsigned long)pfn_to_kaddr(idx_to_pfn(vif, idx));
 }
 
 /*
@@ -126,10 +111,10 @@ static inline pending_ring_idx_t pending_index(unsigned i)
 	return i & (MAX_PENDING_REQS-1);
 }
 
-static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
+static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 {
 	return MAX_PENDING_REQS -
-		netbk->pending_prod + netbk->pending_cons;
+		vif->pending_prod + vif->pending_cons;
 }
 
 static int max_required_rx_slots(struct xenvif *vif)
@@ -316,9 +301,9 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
-			struct xen_netbk *rnetbk = to_netbk(idx);
+			struct xenvif *rvif = to_vif(idx);
 
-			copy_gop->source.domid = rnetbk->vif->domid;
+			copy_gop->source.domid = rvif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -476,16 +461,13 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xenvif *vif)
 {
-	struct xenvif *vif = netbk->vif;
-
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xen_netbk *netbk)
+void xen_netbk_rx_action(struct xenvif *vif)
 {
-	struct xenvif *vif = NULL;
 	s8 status;
 	u16 flags;
 	struct xen_netif_rx_response *resp;
@@ -511,7 +493,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	count = 0;
 
-	while ((skb = skb_dequeue(&netbk->rx_queue)) != NULL) {
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
 		vif = netdev_priv(skb->dev);
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
@@ -543,8 +525,6 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	while ((skb = __skb_dequeue(&rxq)) != NULL) {
 		sco = (struct skb_cb_overlay *)skb->cb;
 
-		vif = netdev_priv(skb->dev);
-
 		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
@@ -616,8 +596,8 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
 
-	if (!skb_queue_empty(&netbk->rx_queue))
-		xen_netbk_kick_thread(netbk);
+	if (!skb_queue_empty(&vif->rx_queue))
+		xen_netbk_kick_thread(vif);
 
 	put_cpu_ptr(gco);
 	put_cpu_ptr(m);
@@ -625,11 +605,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	struct xen_netbk *netbk = vif->netbk;
+	skb_queue_tail(&vif->rx_queue, skb);
 
-	skb_queue_tail(&netbk->rx_queue, skb);
-
-	xen_netbk_kick_thread(netbk);
+	xen_netbk_kick_thread(vif);
 }
 
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
@@ -728,21 +706,20 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
+static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 					 struct sk_buff *skb,
 					 u16 pending_idx)
 {
 	struct page *page;
 	int idx;
-	page = page_pool_get(netbk, &idx);
+	page = page_pool_get(vif, &idx);
 	if (!page)
 		return NULL;
-	netbk->mmap_pages[pending_idx] = idx;
+	vif->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
-						  struct xenvif *vif,
+static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 						  struct sk_buff *skb,
 						  struct xen_netif_tx_request *txp,
 						  struct gnttab_copy *gop)
@@ -761,13 +738,13 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		int idx;
 		struct pending_tx_info *pending_tx_info;
 
-		index = pending_index(netbk->pending_cons++);
-		pending_idx = netbk->pending_ring[index];
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		index = pending_index(vif->pending_cons++);
+		pending_idx = vif->pending_ring[index];
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		gop->source.u.ref = txp->gref;
@@ -791,7 +768,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
+static int xen_netbk_tx_check_gop(struct xenvif *vif,
 				  struct sk_buff *skb,
 				  struct gnttab_copy **gopp)
 {
@@ -799,8 +776,6 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = netbk->vif;
-
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -810,12 +785,12 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	err = gop->status;
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
-		index = pending_index(netbk->pending_prod++);
-		idx = netbk->mmap_pages[index];
+		index = pending_index(vif->pending_prod++);
+		idx = vif->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		netbk->pending_ring[index] = pending_idx;
+		vif->pending_ring[index] = pending_idx;
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -832,16 +807,16 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(netbk, pending_idx);
+				xen_netbk_idx_release(vif, pending_idx);
 			continue;
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
-		index = pending_index(netbk->pending_prod++);
-		netbk->pending_ring[index] = pending_idx;
+		index = pending_index(vif->pending_prod++);
+		vif->pending_ring[index] = pending_idx;
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -849,10 +824,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -863,7 +838,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
+static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -879,11 +854,11 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
-		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
+		page = virt_to_page(idx_to_kaddr(vif, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
 		skb->data_len += txp->size;
@@ -891,7 +866,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(netbk, pending_idx);
+		xen_netbk_idx_release(vif, pending_idx);
 	}
 }
 
@@ -1052,15 +1027,14 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 					struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
-	struct xenvif *vif = netbk->vif;
 
-	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
+	while ((nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1128,8 +1102,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 			break;
 		}
 
-		index = pending_index(netbk->pending_cons);
-		pending_idx = netbk->pending_ring[index];
+		index = pending_index(vif->pending_cons);
+		pending_idx = vif->pending_ring[index];
 
 		data_len = (txreq.size > PKT_PROT_LEN &&
 			    ret < MAX_SKB_FRAGS) ?
@@ -1159,7 +1133,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(netbk, skb, pending_idx);
+		page = xen_netbk_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
@@ -1179,7 +1153,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 
 		gop++;
 
-		pool_idx = netbk->mmap_pages[pending_idx];
+		pool_idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(pool_idx);
 
 		memcpy(&pending_tx_info->req,
@@ -1199,11 +1173,11 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 					     INVALID_PENDING_IDX);
 		}
 
-		__skb_queue_tail(&netbk->tx_queue, skb);
+		__skb_queue_tail(&vif->tx_queue, skb);
 
-		netbk->pending_cons++;
+		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(netbk, vif,
+		request_gop = xen_netbk_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
@@ -1222,16 +1196,15 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
 	return gop - tco;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+static void xen_netbk_tx_submit(struct xenvif *vif,
 				struct gnttab_copy *tco,
 				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
-	struct xenvif *vif = netbk->vif;
 
 	while ((*work_done < budget) &&
-	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
 		unsigned data_len;
@@ -1240,13 +1213,13 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		pending_idx = *((u16 *)skb->data);
 
-		idx = netbk->mmap_pages[pending_idx];
+		idx = vif->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
+		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1255,7 +1228,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 
 		data_len = skb->len;
 		memcpy(skb->data,
-		       (void *)(idx_to_kaddr(netbk, pending_idx)|txp->offset),
+		       (void *)(idx_to_kaddr(vif, pending_idx)|txp->offset),
 		       data_len);
 		if (data_len < txp->size) {
 			/* Append the packet payload as a fragment. */
@@ -1263,7 +1236,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(netbk, pending_idx);
+			xen_netbk_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1271,7 +1244,7 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(netbk, skb);
+		xen_netbk_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1303,53 +1276,52 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk,
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
+void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 	struct gnttab_copy *tco;
 
-	if (unlikely(!tx_work_todo(netbk)))
+	if (unlikely(!tx_work_todo(vif)))
 		return;
 
 	tco = get_cpu_ptr(tx_copy_ops);
 
-	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+	nr_gops = xen_netbk_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_ptr(tco);
-		return 0;
+		return;
 	}
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, tco, work_done, budget);
+	xen_netbk_tx_submit(vif, tco, work_done, budget);
 	put_cpu_ptr(tco);
 }
 
-static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
+static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
 {
-	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
+	if (vif->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	idx = netbk->mmap_pages[pending_idx];
+	idx = vif->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
-	index = pending_index(netbk->pending_prod++);
-	netbk->pending_ring[index] = pending_idx;
+	index = pending_index(vif->pending_prod++);
+	vif->pending_ring[index] = pending_idx;
 
-	page_pool_put(netbk->mmap_pages[pending_idx]);
+	page_pool_put(vif->mmap_pages[pending_idx]);
 
-	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
+	vif->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1396,15 +1368,15 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 	return resp;
 }
 
-static inline int rx_work_todo(struct xen_netbk *netbk)
+static inline int rx_work_todo(struct xenvif *vif)
 {
-	return !skb_queue_empty(&netbk->rx_queue);
+	return !skb_queue_empty(&vif->rx_queue);
 }
 
-static inline int tx_work_todo(struct xen_netbk *netbk)
+static inline int tx_work_todo(struct xenvif *vif)
 {
-	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
-	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&vif->tx)) &&
+	    (nr_pending_reqs(vif) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
@@ -1455,54 +1427,21 @@ err:
 	return err;
 }
 
-struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
-{
-	int i;
-	struct xen_netbk *netbk;
-
-	netbk = vzalloc(sizeof(struct xen_netbk));
-	if (!netbk) {
-		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return NULL;
-	}
-
-	netbk->vif = vif;
-
-	skb_queue_head_init(&netbk->rx_queue);
-	skb_queue_head_init(&netbk->tx_queue);
-
-	netbk->pending_cons = 0;
-	netbk->pending_prod = MAX_PENDING_REQS;
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->pending_ring[i] = i;
-
-	for (i = 0; i < MAX_PENDING_REQS; i++)
-		netbk->mmap_pages[i] = INVALID_ENTRY;
-
-	return netbk;
-}
-
-void xen_netbk_free_netbk(struct xen_netbk *netbk)
-{
-	vfree(netbk);
-}
-
 int xen_netbk_kthread(void *data)
 {
 	struct xenvif *vif = data;
-	struct xen_netbk *netbk = vif->netbk;
 
 	while (!kthread_should_stop()) {
 		wait_event_interruptible(vif->wq,
-					 rx_work_todo(netbk) ||
+					 rx_work_todo(vif) ||
 					 kthread_should_stop());
 		cond_resched();
 
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
+		if (rx_work_todo(vif))
+			xen_netbk_rx_action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
index 294f48b..ce00a93 100644
--- a/drivers/net/xen-netback/page_pool.c
+++ b/drivers/net/xen-netback/page_pool.c
@@ -102,7 +102,7 @@ int is_in_pool(struct page *page, int *pidx)
 	return get_page_ext(page, pidx);
 }
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+struct page *page_pool_get(struct xenvif *vif, int *pidx)
 {
 	int idx;
 	struct page *page;
@@ -118,7 +118,7 @@ struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
 	}
 
 	set_page_ext(page, idx);
-	pool[idx].u.netbk = netbk;
+	pool[idx].u.vif = vif;
 	pool[idx].page = page;
 
 	*pidx = idx;
@@ -131,7 +131,7 @@ void page_pool_put(int idx)
 	struct page *page = pool[idx].page;
 
 	pool[idx].page = NULL;
-	pool[idx].u.netbk = NULL;
+	pool[idx].u.vif = NULL;
 	page->mapping = 0;
 	put_page(page);
 	put_free_entry(idx);
@@ -174,9 +174,9 @@ struct page *to_page(int idx)
 	return pool[idx].page;
 }
 
-struct xen_netbk *to_netbk(int idx)
+struct xenvif *to_vif(int idx)
 {
-	return pool[idx].u.netbk;
+	return pool[idx].u.vif;
 }
 
 struct pending_tx_info *to_txinfo(int idx)
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
index 572b037..efae17c 100644
--- a/drivers/net/xen-netback/page_pool.h
+++ b/drivers/net/xen-netback/page_pool.h
@@ -27,7 +27,10 @@
 #ifndef __PAGE_POOL_H__
 #define __PAGE_POOL_H__
 
-#include "common.h"
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+};
+typedef unsigned int pending_ring_idx_t;
 
 typedef uint32_t idx_t;
 
@@ -38,8 +41,8 @@ struct page_pool_entry {
 	struct page *page;
 	struct pending_tx_info tx_info;
 	union {
-		struct xen_netbk *netbk;
-		idx_t             fl;
+		struct xenvif *vif;
+		idx_t          fl;
 	} u;
 };
 
@@ -52,12 +55,12 @@ int  page_pool_init(void);
 void page_pool_destroy(void);
 
 
-struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+struct page *page_pool_get(struct xenvif *vif, int *pidx);
 void         page_pool_put(int idx);
 int          is_in_pool(struct page *page, int *pidx);
 
 struct page            *to_page(int idx);
-struct xen_netbk       *to_netbk(int idx);
+struct xenvif          *to_vif(int idx);
 struct pending_tx_info *to_txinfo(int idx);
 
 #endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUN-0007Ij-QZ; Mon, 30 Jan 2012 14:45:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUM-0007H8-99
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:46 +0000
Received: from [85.158.138.51:58833] by server-12.bemta-3.messagelabs.com id
	14/E6-24557-91DA62F4; Mon, 30 Jan 2012 14:45:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!5
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16935 invoked from network); 30 Jan 2012 14:45:44 -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;
	30 Jan 2012 14:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413500"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:42 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTf029057;
	Mon, 30 Jan 2012 06:45:41 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:26 +0000
Message-ID: <1327934734-8908-9-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 08/16] netback: remove unwanted
	notification generation during NAPI processing.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 original implementation, tx_build_gops tends to update req_event
pointer every time it sees tx error or finish one batch. Remove those
code to only update req_event pointer when we really want to shut down
NAPI.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    5 +++--
 drivers/net/xen-netback/netback.c   |    4 +---
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index ebed26a..fe37143 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -58,8 +58,8 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
-	if (likely(napi_schedule_prep(&vif->napi)))
-		__napi_schedule(&vif->napi);
+	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
+		napi_schedule(&vif->napi);
 
 	return IRQ_HANDLED;
 }
@@ -74,6 +74,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	if (work_done < budget) {
 		int more_to_do = 0;
 		unsigned long flag;
+
 		local_irq_save(flag);
 
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2a2835e..065cd65 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -662,7 +662,6 @@ static void xenvif_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xenvif_check_rx_xenvif(vif);
 }
 
 static int xenvif_count_requests(struct xenvif *vif,
@@ -1047,7 +1046,7 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
+		work_to_do = RING_HAS_UNCONSUMED_REQUESTS(&vif->tx);
 		if (!work_to_do) {
 			break;
 		}
@@ -1187,7 +1186,6 @@ static unsigned xenvif_tx_build_gops(struct xenvif *vif,
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xenvif_check_rx_xenvif(vif);
 
 		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
-- 
1.7.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 Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUN-0007ID-5Z; Mon, 30 Jan 2012 14:45:47 +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 1RrsUL-0007Ff-Sg
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32147 invoked from network); 30 Jan 2012 14:45:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614368"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:38 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTc029057;
	Mon, 30 Jan 2012 06:45:37 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:23 +0000
Message-ID: <1327934734-8908-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 05/16] netback: add module get/put
	operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If there is vif running and user unloads netback, it will certainly
cause problems -- guest's network interface just mysteriously stops
working.

v2: fix module_put path

disconnect function may get called by the generic framework even
before vif connects.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index dfc04f8..7914f60 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -372,12 +374,14 @@ err_unbind:
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
+	module_put(THIS_MODULE);
 	return err;
 }
 
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+	int need_module_put = 0;
 
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
@@ -397,12 +401,17 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	del_timer_sync(&vif->credit_timeout);
 
-	if (vif->irq)
+	if (vif->irq) {
 		unbind_from_irqhandler(vif->irq, vif);
+		need_module_put = 1;
+	}
 
 	unregister_netdev(vif->dev);
 
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	if (need_module_put)
+		module_put(THIS_MODULE);
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUN-0007ID-5Z; Mon, 30 Jan 2012 14:45:47 +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 1RrsUL-0007Ff-Sg
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:46 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!4
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32147 invoked from network); 30 Jan 2012 14:45:39 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614368"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:38 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTc029057;
	Mon, 30 Jan 2012 06:45:37 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:23 +0000
Message-ID: <1327934734-8908-6-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 05/16] netback: add module get/put
	operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If there is vif running and user unloads netback, it will certainly
cause problems -- guest's network interface just mysteriously stops
working.

v2: fix module_put path

disconnect function may get called by the generic framework even
before vif connects.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index dfc04f8..7914f60 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	if (vif->irq)
 		return 0;
 
+	__module_get(THIS_MODULE);
+
 	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
@@ -372,12 +374,14 @@ err_unbind:
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
+	module_put(THIS_MODULE);
 	return err;
 }
 
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+	int need_module_put = 0;
 
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
@@ -397,12 +401,17 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	del_timer_sync(&vif->credit_timeout);
 
-	if (vif->irq)
+	if (vif->irq) {
 		unbind_from_irqhandler(vif->irq, vif);
+		need_module_put = 1;
+	}
 
 	unregister_netdev(vif->dev);
 
 	xen_netbk_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
+
+	if (need_module_put)
+		module_put(THIS_MODULE);
 }
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUO-0007Iz-6q; Mon, 30 Jan 2012 14:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUL-0007Gr-Lm
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:46 +0000
Received: from [85.158.138.51:58769] by server-4.bemta-3.messagelabs.com id
	FB/85-32238-81DA62F4; Mon, 30 Jan 2012 14:45:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16820 invoked from network); 30 Jan 2012 14:45:43 -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;
	30 Jan 2012 14:45:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413499"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:41 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTe029057;
	Mon, 30 Jan 2012 06:45:40 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:25 +0000
Message-ID: <1327934734-8908-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 07/16] netback: alter internal
	function/structure names.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since we've melted xen_netbk into xenvif, so it is better to give
functions clearer names.

Also alter napi poll handler function prototypes a bit.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   26 ++--
 drivers/net/xen-netback/interface.c |   20 ++--
 drivers/net/xen-netback/netback.c   |  231 ++++++++++++++++++-----------------
 3 files changed, 142 insertions(+), 135 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 17d4e1a..53141c7 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,7 @@
 
 #include "page_pool.h"
 
-struct netbk_rx_meta {
+struct xenvif_rx_meta {
 	int id;
 	int size;
 	int gso_size;
@@ -140,32 +140,32 @@ void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
-int xen_netbk_rx_ring_full(struct xenvif *vif);
+int xenvif_rx_ring_full(struct xenvif *vif);
 
-int xen_netbk_must_stop_queue(struct xenvif *vif);
+int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xenvif *vif);
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
-void xen_netbk_check_rx_xenvif(struct xenvif *vif);
+void xenvif_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
-void xen_netbk_rx_action(struct xenvif *vif);
+int xenvif_tx_action(struct xenvif *vif, int budget);
+void xenvif_rx_action(struct xenvif *vif);
 
-int xen_netbk_kthread(void *data);
+int xenvif_kthread(void *data);
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 3c004fa..ebed26a 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -48,7 +48,7 @@ int xenvif_schedulable(struct xenvif *vif)
 
 static int xenvif_rx_schedulable(struct xenvif *vif)
 {
-	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
+	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
@@ -69,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif, &work_done, budget);
+	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -101,12 +101,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
+	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
 
-	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
 		netif_stop_queue(dev);
 
-	xen_netbk_queue_tx_skb(vif, skb);
+	xenvif_queue_tx_skb(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -137,7 +137,7 @@ static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
@@ -334,7 +334,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
 
@@ -347,7 +347,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	disable_irq(vif->irq);
 
 	init_waitqueue_head(&vif->wq);
-	vif->task = kthread_create(xen_netbk_kthread,
+	vif->task = kthread_create(xenvif_kthread,
 				   (void *)vif,
 				   "vif%d.%d", vif->domid, vif->handle);
 	if (IS_ERR(vif->task)) {
@@ -371,7 +371,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -404,7 +404,7 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0a52bb1..2a2835e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -57,9 +57,9 @@ struct gnttab_copy *tx_copy_ops;
  * straddles two buffers in the frontend.
  */
 struct gnttab_copy *grant_copy_op;
-struct netbk_rx_meta *meta;
+struct xenvif_rx_meta *meta;
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -127,7 +127,7 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xen_netbk_rx_ring_full(struct xenvif *vif)
+int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
@@ -136,16 +136,16 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
 }
 
-int xen_netbk_must_stop_queue(struct xenvif *vif)
+int xenvif_must_stop_queue(struct xenvif *vif)
 {
-	if (!xen_netbk_rx_ring_full(vif))
+	if (!xenvif_rx_ring_full(vif))
 		return 0;
 
 	vif->rx.sring->req_event = vif->rx_req_cons_peek +
 		max_required_rx_slots(vif);
 	mb(); /* request notification /then/ check the queue */
 
-	return xen_netbk_rx_ring_full(vif);
+	return xenvif_rx_ring_full(vif);
 }
 
 /*
@@ -191,9 +191,9 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
 /*
  * Figure out how many ring slots we're going to need to send @skb to
  * the guest. This function is essentially a dry run of
- * netbk_gop_frag_copy.
+ * xenvif_gop_frag_copy.
  */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 {
 	unsigned int count;
 	int i, copy_off;
@@ -232,15 +232,15 @@ struct netrx_pending_operations {
 	unsigned copy_prod, copy_cons;
 	unsigned meta_prod, meta_cons;
 	struct gnttab_copy *copy;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	int copy_off;
 	grant_ref_t copy_gref;
 };
 
-static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-						struct netrx_pending_operations *npo)
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+					struct netrx_pending_operations *npo)
 {
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	struct xen_netif_rx_request *req;
 
 	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
@@ -260,13 +260,13 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				struct netrx_pending_operations *npo,
-				struct page *page, unsigned long size,
-				unsigned long offset, int *head)
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				 struct netrx_pending_operations *npo,
+				 struct page *page, unsigned long size,
+				 unsigned long offset, int *head)
 {
 	struct gnttab_copy *copy_gop;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	/*
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
@@ -345,14 +345,14 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
  * zero GSO descriptors (for non-GSO packets) or one descriptor (for
  * frontend-side LRO).
  */
-static int netbk_gop_skb(struct sk_buff *skb,
-			 struct netrx_pending_operations *npo)
+static int xenvif_gop_skb(struct sk_buff *skb,
+			  struct netrx_pending_operations *npo)
 {
 	struct xenvif *vif = netdev_priv(skb->dev);
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	int i;
 	struct xen_netif_rx_request *req;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	unsigned char *data;
 	int head = 1;
 	int old_meta_prod;
@@ -389,30 +389,30 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     virt_to_page(data), len, offset, &head);
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
-				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				     skb_shinfo(skb)->frags[i].page_offset,
+				     &head);
 	}
 
 	return npo->meta_prod - old_meta_prod;
 }
 
 /*
- * This is a twin to netbk_gop_skb.  Assume that netbk_gop_skb was
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
  * used to set up the operations on the top of
  * netrx_pending_operations, which have since been done.  Check that
  * they didn't give any errors and advance over them.
  */
-static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
-			   struct netrx_pending_operations *npo)
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			    struct netrx_pending_operations *npo)
 {
 	struct gnttab_copy     *copy_op;
 	int status = XEN_NETIF_RSP_OKAY;
@@ -431,9 +431,9 @@ static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
 	return status;
 }
 
-static void netbk_add_frag_responses(struct xenvif *vif, int status,
-				     struct netbk_rx_meta *meta,
-				     int nr_meta_slots)
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				      struct xenvif_rx_meta *meta,
+				      int nr_meta_slots)
 {
 	int i;
 	unsigned long offset;
@@ -461,12 +461,12 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xenvif *vif)
+static void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xenvif *vif)
+void xenvif_rx_action(struct xenvif *vif)
 {
 	s8 status;
 	u16 flags;
@@ -482,7 +482,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 	int need_to_notify = 0;
 
 	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
-	struct netbk_rx_meta *m = get_cpu_ptr(meta);
+	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
 
 	struct netrx_pending_operations npo = {
 		.copy  = gco,
@@ -498,7 +498,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
 		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = netbk_gop_skb(skb, &npo);
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
 
 		count += nr_frags + 1;
 
@@ -543,7 +543,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		vif->dev->stats.tx_bytes += skb->len;
 		vif->dev->stats.tx_packets++;
 
-		status = netbk_check_gop(vif, sco->meta_slots_used, &npo);
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
 
 		if (sco->meta_slots_used == 1)
 			flags = 0;
@@ -579,9 +579,9 @@ void xen_netbk_rx_action(struct xenvif *vif)
 			gso->flags = 0;
 		}
 
-		netbk_add_frag_responses(vif, status,
-					 m + npo.meta_cons + 1,
-					 sco->meta_slots_used);
+		xenvif_add_frag_responses(vif, status,
+					  m + npo.meta_cons + 1,
+					  sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
 		if (ret)
@@ -597,20 +597,20 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		notify_remote_via_irq(vif->irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
-		xen_netbk_kick_thread(vif);
+		xenvif_kick_thread(vif);
 
 	put_cpu_ptr(gco);
 	put_cpu_ptr(m);
 }
 
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(vif);
+	xenvif_kick_thread(vif);
 }
 
-void xen_netbk_check_rx_xenvif(struct xenvif *vif)
+void xenvif_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
@@ -647,11 +647,11 @@ static void tx_credit_callback(unsigned long data)
 {
 	struct xenvif *vif = (struct xenvif *)data;
 	tx_add_credit(vif);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static void netbk_tx_err(struct xenvif *vif,
-			 struct xen_netif_tx_request *txp, RING_IDX end)
+static void xenvif_tx_err(struct xenvif *vif,
+			  struct xen_netif_tx_request *txp, RING_IDX end)
 {
 	RING_IDX cons = vif->tx.req_cons;
 
@@ -662,10 +662,10 @@ static void netbk_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static int netbk_count_requests(struct xenvif *vif,
+static int xenvif_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
 				int work_to_do)
@@ -706,9 +706,9 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xenvif *vif,
-					 struct sk_buff *skb,
-					 u16 pending_idx)
+static struct page *xenvif_alloc_page(struct xenvif *vif,
+				      struct sk_buff *skb,
+				      u16 pending_idx)
 {
 	struct page *page;
 	int idx;
@@ -719,10 +719,10 @@ static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
-						  struct sk_buff *skb,
-						  struct xen_netif_tx_request *txp,
-						  struct gnttab_copy *gop)
+static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+					       struct sk_buff *skb,
+					       struct xen_netif_tx_request *txp,
+					       struct gnttab_copy *gop)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
@@ -740,7 +740,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 
 		index = pending_index(vif->pending_cons++);
 		pending_idx = vif->pending_ring[index];
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -768,9 +768,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xenvif *vif,
-				  struct sk_buff *skb,
-				  struct gnttab_copy **gopp)
+static int xenvif_tx_check_gop(struct xenvif *vif,
+			       struct sk_buff *skb,
+			       struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
@@ -807,7 +807,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(vif, pending_idx);
+				xenvif_idx_release(vif, pending_idx);
 			continue;
 		}
 
@@ -824,10 +824,10 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -838,7 +838,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
+static void xenvif_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -864,15 +864,15 @@ static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
-		/* Take an extra reference to offset xen_netbk_idx_release */
+		/* Take an extra reference to offset xenvif_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 	}
 }
 
-static int xen_netbk_get_extras(struct xenvif *vif,
-				struct xen_netif_extra_info *extras,
-				int work_to_do)
+static int xenvif_get_extras(struct xenvif *vif,
+			     struct xen_netif_extra_info *extras,
+			     int work_to_do)
 {
 	struct xen_netif_extra_info extra;
 	RING_IDX cons = vif->tx.req_cons;
@@ -900,9 +900,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 	return work_to_do;
 }
 
-static int netbk_set_skb_gso(struct xenvif *vif,
-			     struct sk_buff *skb,
-			     struct xen_netif_extra_info *gso)
+static int xenvif_set_skb_gso(struct xenvif *vif,
+			      struct sk_buff *skb,
+			      struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
 		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
@@ -1027,8 +1027,8 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
-					struct gnttab_copy *tco)
+static unsigned xenvif_tx_build_gops(struct xenvif *vif,
+				     struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
@@ -1069,18 +1069,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		memset(extras, 0, sizeof(extras));
 		if (txreq.flags & XEN_NETTXF_extra_info) {
-			work_to_do = xen_netbk_get_extras(vif, extras,
+			work_to_do = xenvif_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
-		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
+		ret = xenvif_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+			xenvif_tx_err(vif, &txreq, idx - ret);
 			break;
 		}
 		idx += ret;
@@ -1088,7 +1088,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(txreq.size < ETH_HLEN)) {
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1098,7 +1098,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1114,7 +1114,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(skb == NULL)) {
 			netdev_dbg(vif->dev,
 				   "Can't allocate a skb in start_xmit.\n");
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1125,18 +1125,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 			struct xen_netif_extra_info *gso;
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
-			if (netbk_set_skb_gso(vif, skb, gso)) {
+			if (xenvif_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1177,17 +1177,17 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(vif,
+		request_gop = xenvif_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xen_netbk_check_rx_xenvif(vif);
+		xenvif_check_rx_xenvif(vif);
 
 		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
@@ -1196,14 +1196,15 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 	return gop - tco;
 }
 
-static void xen_netbk_tx_submit(struct xenvif *vif,
-				struct gnttab_copy *tco,
-				int *work_done, int budget)
+static int xenvif_tx_submit(struct xenvif *vif,
+			    struct gnttab_copy *tco,
+			    int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
+	int work_done = 0;
 
-	while ((*work_done < budget) &&
+	while ((work_done < budget) &&
 	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
@@ -1219,7 +1220,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
+		if (unlikely(xenvif_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1236,7 +1237,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1244,7 +1245,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(vif, skb);
+		xenvif_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1269,39 +1270,45 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
-		(*work_done)++;
+		work_done++;
 
 		xenvif_receive_skb(vif, skb);
 	}
+
+	return work_done;
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
+int xenvif_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 	struct gnttab_copy *tco;
+	int work_done;
 
 	if (unlikely(!tx_work_todo(vif)))
-		return;
+		return 0;
 
 	tco = get_cpu_ptr(tx_copy_ops);
 
-	nr_gops = xen_netbk_tx_build_gops(vif, tco);
+	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_ptr(tco);
-		return;
+		return 0;
 	}
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(vif, tco, work_done, budget);
+	work_done = xenvif_tx_submit(vif, tco, budget);
+
 	put_cpu_ptr(tco);
+
+	return work_done;
 }
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx)
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
@@ -1382,7 +1389,7 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
 		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
@@ -1392,9 +1399,9 @@ void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 					vif->rx.sring);
 }
 
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref)
 {
 	void *addr;
 	struct xen_netif_tx_sring *txs;
@@ -1423,11 +1430,11 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	return 0;
 
 err:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
-int xen_netbk_kthread(void *data)
+int xenvif_kthread(void *data)
 {
 	struct xenvif *vif = data;
 
@@ -1441,7 +1448,7 @@ int xen_netbk_kthread(void *data)
 			break;
 
 		if (rx_work_todo(vif))
-			xen_netbk_rx_action(vif);
+			xenvif_rx_action(vif);
 	}
 
 	return 0;
@@ -1467,9 +1474,9 @@ static int __init netback_init(void)
 	if (!grant_copy_op)
 		goto failed_init_gco;
 
-	meta = __alloc_percpu(sizeof(struct netbk_rx_meta)
+	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
 			      * 2 * XEN_NETIF_RX_RING_SIZE,
-			      __alignof__(struct netbk_rx_meta));
+			      __alignof__(struct xenvif_rx_meta));
 	if (!meta)
 		goto failed_init_meta;
 
-- 
1.7.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 Jan 30 14:45:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUO-0007Iz-6q; Mon, 30 Jan 2012 14:45:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUL-0007Gr-Lm
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:46 +0000
Received: from [85.158.138.51:58769] by server-4.bemta-3.messagelabs.com id
	FB/85-32238-81DA62F4; Mon, 30 Jan 2012 14:45:44 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16820 invoked from network); 30 Jan 2012 14:45:43 -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;
	30 Jan 2012 14:45:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413499"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:41 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTe029057;
	Mon, 30 Jan 2012 06:45:40 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:25 +0000
Message-ID: <1327934734-8908-8-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 07/16] netback: alter internal
	function/structure names.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Since we've melted xen_netbk into xenvif, so it is better to give
functions clearer names.

Also alter napi poll handler function prototypes a bit.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   26 ++--
 drivers/net/xen-netback/interface.c |   20 ++--
 drivers/net/xen-netback/netback.c   |  231 ++++++++++++++++++-----------------
 3 files changed, 142 insertions(+), 135 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 17d4e1a..53141c7 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,7 @@
 
 #include "page_pool.h"
 
-struct netbk_rx_meta {
+struct xenvif_rx_meta {
 	int id;
 	int size;
 	int gso_size;
@@ -140,32 +140,32 @@ void xenvif_xenbus_exit(void);
 
 int xenvif_schedulable(struct xenvif *vif);
 
-int xen_netbk_rx_ring_full(struct xenvif *vif);
+int xenvif_rx_ring_full(struct xenvif *vif);
 
-int xen_netbk_must_stop_queue(struct xenvif *vif);
+int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif);
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xenvif *vif);
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
-void xen_netbk_check_rx_xenvif(struct xenvif *vif);
+void xenvif_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
 /* Notify xenvif that ring now has space to send an skb to the frontend */
 void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget);
-void xen_netbk_rx_action(struct xenvif *vif);
+int xenvif_tx_action(struct xenvif *vif, int budget);
+void xenvif_rx_action(struct xenvif *vif);
 
-int xen_netbk_kthread(void *data);
+int xenvif_kthread(void *data);
 
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 3c004fa..ebed26a 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -48,7 +48,7 @@ int xenvif_schedulable(struct xenvif *vif)
 
 static int xenvif_rx_schedulable(struct xenvif *vif)
 {
-	return xenvif_schedulable(vif) && !xen_netbk_rx_ring_full(vif);
+	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
 }
 
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
@@ -69,7 +69,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
-	xen_netbk_tx_action(vif, &work_done, budget);
+	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
 		int more_to_do = 0;
@@ -101,12 +101,12 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 		goto drop;
 
 	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
+	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
 
-	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
 		netif_stop_queue(dev);
 
-	xen_netbk_queue_tx_skb(vif, skb);
+	xenvif_queue_tx_skb(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -137,7 +137,7 @@ static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
@@ -334,7 +334,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
+	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
 	if (err < 0)
 		goto err;
 
@@ -347,7 +347,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	disable_irq(vif->irq);
 
 	init_waitqueue_head(&vif->wq);
-	vif->task = kthread_create(xen_netbk_kthread,
+	vif->task = kthread_create(xenvif_kthread,
 				   (void *)vif,
 				   "vif%d.%d", vif->domid, vif->handle);
 	if (IS_ERR(vif->task)) {
@@ -371,7 +371,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -404,7 +404,7 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0a52bb1..2a2835e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -57,9 +57,9 @@ struct gnttab_copy *tx_copy_ops;
  * straddles two buffers in the frontend.
  */
 struct gnttab_copy *grant_copy_op;
-struct netbk_rx_meta *meta;
+struct xenvif_rx_meta *meta;
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx);
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
@@ -127,7 +127,7 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xen_netbk_rx_ring_full(struct xenvif *vif)
+int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
@@ -136,16 +136,16 @@ int xen_netbk_rx_ring_full(struct xenvif *vif)
 	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
 }
 
-int xen_netbk_must_stop_queue(struct xenvif *vif)
+int xenvif_must_stop_queue(struct xenvif *vif)
 {
-	if (!xen_netbk_rx_ring_full(vif))
+	if (!xenvif_rx_ring_full(vif))
 		return 0;
 
 	vif->rx.sring->req_event = vif->rx_req_cons_peek +
 		max_required_rx_slots(vif);
 	mb(); /* request notification /then/ check the queue */
 
-	return xen_netbk_rx_ring_full(vif);
+	return xenvif_rx_ring_full(vif);
 }
 
 /*
@@ -191,9 +191,9 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
 /*
  * Figure out how many ring slots we're going to need to send @skb to
  * the guest. This function is essentially a dry run of
- * netbk_gop_frag_copy.
+ * xenvif_gop_frag_copy.
  */
-unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
 {
 	unsigned int count;
 	int i, copy_off;
@@ -232,15 +232,15 @@ struct netrx_pending_operations {
 	unsigned copy_prod, copy_cons;
 	unsigned meta_prod, meta_cons;
 	struct gnttab_copy *copy;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	int copy_off;
 	grant_ref_t copy_gref;
 };
 
-static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-						struct netrx_pending_operations *npo)
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+					struct netrx_pending_operations *npo)
 {
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	struct xen_netif_rx_request *req;
 
 	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
@@ -260,13 +260,13 @@ static struct netbk_rx_meta *get_next_rx_buffer(struct xenvif *vif,
  * Set up the grant operations for this fragment. If it's a flipping
  * interface, we also set up the unmap request from here.
  */
-static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				struct netrx_pending_operations *npo,
-				struct page *page, unsigned long size,
-				unsigned long offset, int *head)
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				 struct netrx_pending_operations *npo,
+				 struct page *page, unsigned long size,
+				 unsigned long offset, int *head)
 {
 	struct gnttab_copy *copy_gop;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	/*
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
@@ -345,14 +345,14 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
  * zero GSO descriptors (for non-GSO packets) or one descriptor (for
  * frontend-side LRO).
  */
-static int netbk_gop_skb(struct sk_buff *skb,
-			 struct netrx_pending_operations *npo)
+static int xenvif_gop_skb(struct sk_buff *skb,
+			  struct netrx_pending_operations *npo)
 {
 	struct xenvif *vif = netdev_priv(skb->dev);
 	int nr_frags = skb_shinfo(skb)->nr_frags;
 	int i;
 	struct xen_netif_rx_request *req;
-	struct netbk_rx_meta *meta;
+	struct xenvif_rx_meta *meta;
 	unsigned char *data;
 	int head = 1;
 	int old_meta_prod;
@@ -389,30 +389,30 @@ static int netbk_gop_skb(struct sk_buff *skb,
 		if (data + len > skb_tail_pointer(skb))
 			len = skb_tail_pointer(skb) - data;
 
-		netbk_gop_frag_copy(vif, skb, npo,
-				    virt_to_page(data), len, offset, &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     virt_to_page(data), len, offset, &head);
 		data += len;
 	}
 
 	for (i = 0; i < nr_frags; i++) {
-		netbk_gop_frag_copy(vif, skb, npo,
-				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				    skb_shinfo(skb)->frags[i].page_offset,
-				    &head);
+		xenvif_gop_frag_copy(vif, skb, npo,
+				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				     skb_shinfo(skb)->frags[i].page_offset,
+				     &head);
 	}
 
 	return npo->meta_prod - old_meta_prod;
 }
 
 /*
- * This is a twin to netbk_gop_skb.  Assume that netbk_gop_skb was
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
  * used to set up the operations on the top of
  * netrx_pending_operations, which have since been done.  Check that
  * they didn't give any errors and advance over them.
  */
-static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
-			   struct netrx_pending_operations *npo)
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			    struct netrx_pending_operations *npo)
 {
 	struct gnttab_copy     *copy_op;
 	int status = XEN_NETIF_RSP_OKAY;
@@ -431,9 +431,9 @@ static int netbk_check_gop(struct xenvif *vif, int nr_meta_slots,
 	return status;
 }
 
-static void netbk_add_frag_responses(struct xenvif *vif, int status,
-				     struct netbk_rx_meta *meta,
-				     int nr_meta_slots)
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				      struct xenvif_rx_meta *meta,
+				      int nr_meta_slots)
 {
 	int i;
 	unsigned long offset;
@@ -461,12 +461,12 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_kick_thread(struct xenvif *vif)
+static void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xen_netbk_rx_action(struct xenvif *vif)
+void xenvif_rx_action(struct xenvif *vif)
 {
 	s8 status;
 	u16 flags;
@@ -482,7 +482,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 	int need_to_notify = 0;
 
 	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
-	struct netbk_rx_meta *m = get_cpu_ptr(meta);
+	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
 
 	struct netrx_pending_operations npo = {
 		.copy  = gco,
@@ -498,7 +498,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		nr_frags = skb_shinfo(skb)->nr_frags;
 
 		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = netbk_gop_skb(skb, &npo);
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
 
 		count += nr_frags + 1;
 
@@ -543,7 +543,7 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		vif->dev->stats.tx_bytes += skb->len;
 		vif->dev->stats.tx_packets++;
 
-		status = netbk_check_gop(vif, sco->meta_slots_used, &npo);
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
 
 		if (sco->meta_slots_used == 1)
 			flags = 0;
@@ -579,9 +579,9 @@ void xen_netbk_rx_action(struct xenvif *vif)
 			gso->flags = 0;
 		}
 
-		netbk_add_frag_responses(vif, status,
-					 m + npo.meta_cons + 1,
-					 sco->meta_slots_used);
+		xenvif_add_frag_responses(vif, status,
+					  m + npo.meta_cons + 1,
+					  sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
 		if (ret)
@@ -597,20 +597,20 @@ void xen_netbk_rx_action(struct xenvif *vif)
 		notify_remote_via_irq(vif->irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
-		xen_netbk_kick_thread(vif);
+		xenvif_kick_thread(vif);
 
 	put_cpu_ptr(gco);
 	put_cpu_ptr(m);
 }
 
-void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
+void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
 
-	xen_netbk_kick_thread(vif);
+	xenvif_kick_thread(vif);
 }
 
-void xen_netbk_check_rx_xenvif(struct xenvif *vif)
+void xenvif_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
@@ -647,11 +647,11 @@ static void tx_credit_callback(unsigned long data)
 {
 	struct xenvif *vif = (struct xenvif *)data;
 	tx_add_credit(vif);
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static void netbk_tx_err(struct xenvif *vif,
-			 struct xen_netif_tx_request *txp, RING_IDX end)
+static void xenvif_tx_err(struct xenvif *vif,
+			  struct xen_netif_tx_request *txp, RING_IDX end)
 {
 	RING_IDX cons = vif->tx.req_cons;
 
@@ -662,10 +662,10 @@ static void netbk_tx_err(struct xenvif *vif,
 		txp = RING_GET_REQUEST(&vif->tx, cons++);
 	} while (1);
 	vif->tx.req_cons = cons;
-	xen_netbk_check_rx_xenvif(vif);
+	xenvif_check_rx_xenvif(vif);
 }
 
-static int netbk_count_requests(struct xenvif *vif,
+static int xenvif_count_requests(struct xenvif *vif,
 				struct xen_netif_tx_request *first,
 				struct xen_netif_tx_request *txp,
 				int work_to_do)
@@ -706,9 +706,9 @@ static int netbk_count_requests(struct xenvif *vif,
 	return frags;
 }
 
-static struct page *xen_netbk_alloc_page(struct xenvif *vif,
-					 struct sk_buff *skb,
-					 u16 pending_idx)
+static struct page *xenvif_alloc_page(struct xenvif *vif,
+				      struct sk_buff *skb,
+				      u16 pending_idx)
 {
 	struct page *page;
 	int idx;
@@ -719,10 +719,10 @@ static struct page *xen_netbk_alloc_page(struct xenvif *vif,
 	return page;
 }
 
-static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
-						  struct sk_buff *skb,
-						  struct xen_netif_tx_request *txp,
-						  struct gnttab_copy *gop)
+static struct gnttab_copy *xenvif_get_requests(struct xenvif *vif,
+					       struct sk_buff *skb,
+					       struct xen_netif_tx_request *txp,
+					       struct gnttab_copy *gop)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	skb_frag_t *frags = shinfo->frags;
@@ -740,7 +740,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 
 		index = pending_index(vif->pending_cons++);
 		pending_idx = vif->pending_ring[index];
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page)
 			return NULL;
 
@@ -768,9 +768,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xenvif *vif,
 	return gop;
 }
 
-static int xen_netbk_tx_check_gop(struct xenvif *vif,
-				  struct sk_buff *skb,
-				  struct gnttab_copy **gopp)
+static int xenvif_tx_check_gop(struct xenvif *vif,
+			       struct sk_buff *skb,
+			       struct gnttab_copy **gopp)
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
@@ -807,7 +807,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 		if (likely(!newerr)) {
 			/* Had a previous error? Invalidate this fragment. */
 			if (unlikely(err))
-				xen_netbk_idx_release(vif, pending_idx);
+				xenvif_idx_release(vif, pending_idx);
 			continue;
 		}
 
@@ -824,10 +824,10 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 
 		/* First error: invalidate header and preceding fragments. */
 		pending_idx = *((u16 *)skb->data);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 		for (j = start; j < i; j++) {
 			pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		/* Remember the error: invalidate all subsequent fragments. */
@@ -838,7 +838,7 @@ static int xen_netbk_tx_check_gop(struct xenvif *vif,
 	return err;
 }
 
-static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
+static void xenvif_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 {
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -864,15 +864,15 @@ static void xen_netbk_fill_frags(struct xenvif *vif, struct sk_buff *skb)
 		skb->data_len += txp->size;
 		skb->truesize += txp->size;
 
-		/* Take an extra reference to offset xen_netbk_idx_release */
+		/* Take an extra reference to offset xenvif_idx_release */
 		get_page(page);
-		xen_netbk_idx_release(vif, pending_idx);
+		xenvif_idx_release(vif, pending_idx);
 	}
 }
 
-static int xen_netbk_get_extras(struct xenvif *vif,
-				struct xen_netif_extra_info *extras,
-				int work_to_do)
+static int xenvif_get_extras(struct xenvif *vif,
+			     struct xen_netif_extra_info *extras,
+			     int work_to_do)
 {
 	struct xen_netif_extra_info extra;
 	RING_IDX cons = vif->tx.req_cons;
@@ -900,9 +900,9 @@ static int xen_netbk_get_extras(struct xenvif *vif,
 	return work_to_do;
 }
 
-static int netbk_set_skb_gso(struct xenvif *vif,
-			     struct sk_buff *skb,
-			     struct xen_netif_extra_info *gso)
+static int xenvif_set_skb_gso(struct xenvif *vif,
+			      struct sk_buff *skb,
+			      struct xen_netif_extra_info *gso)
 {
 	if (!gso->u.gso.size) {
 		netdev_dbg(vif->dev, "GSO size must not be zero.\n");
@@ -1027,8 +1027,8 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
-					struct gnttab_copy *tco)
+static unsigned xenvif_tx_build_gops(struct xenvif *vif,
+				     struct gnttab_copy *tco)
 {
 	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
@@ -1069,18 +1069,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		memset(extras, 0, sizeof(extras));
 		if (txreq.flags & XEN_NETTXF_extra_info) {
-			work_to_do = xen_netbk_get_extras(vif, extras,
+			work_to_do = xenvif_get_extras(vif, extras,
 							  work_to_do);
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
-		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
+		ret = xenvif_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
-			netbk_tx_err(vif, &txreq, idx - ret);
+			xenvif_tx_err(vif, &txreq, idx - ret);
 			break;
 		}
 		idx += ret;
@@ -1088,7 +1088,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(txreq.size < ETH_HLEN)) {
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1098,7 +1098,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 				   "txreq.offset: %x, size: %u, end: %lu\n",
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1114,7 +1114,7 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 		if (unlikely(skb == NULL)) {
 			netdev_dbg(vif->dev,
 				   "Can't allocate a skb in start_xmit.\n");
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1125,18 +1125,18 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 			struct xen_netif_extra_info *gso;
 			gso = &extras[XEN_NETIF_EXTRA_TYPE_GSO - 1];
 
-			if (netbk_set_skb_gso(vif, skb, gso)) {
+			if (xenvif_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
-				netbk_tx_err(vif, &txreq, idx);
+				xenvif_tx_err(vif, &txreq, idx);
 				break;
 			}
 		}
 
 		/* XXX could copy straight to head */
-		page = xen_netbk_alloc_page(vif, skb, pending_idx);
+		page = xenvif_alloc_page(vif, skb, pending_idx);
 		if (!page) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 
@@ -1177,17 +1177,17 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 
 		vif->pending_cons++;
 
-		request_gop = xen_netbk_get_requests(vif,
+		request_gop = xenvif_get_requests(vif,
 						     skb, txfrags, gop);
 		if (request_gop == NULL) {
 			kfree_skb(skb);
-			netbk_tx_err(vif, &txreq, idx);
+			xenvif_tx_err(vif, &txreq, idx);
 			break;
 		}
 		gop = request_gop;
 
 		vif->tx.req_cons = idx;
-		xen_netbk_check_rx_xenvif(vif);
+		xenvif_check_rx_xenvif(vif);
 
 		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
@@ -1196,14 +1196,15 @@ static unsigned xen_netbk_tx_build_gops(struct xenvif *vif,
 	return gop - tco;
 }
 
-static void xen_netbk_tx_submit(struct xenvif *vif,
-				struct gnttab_copy *tco,
-				int *work_done, int budget)
+static int xenvif_tx_submit(struct xenvif *vif,
+			    struct gnttab_copy *tco,
+			    int budget)
 {
 	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
+	int work_done = 0;
 
-	while ((*work_done < budget) &&
+	while ((work_done < budget) &&
 	       (skb = __skb_dequeue(&vif->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
 		u16 pending_idx;
@@ -1219,7 +1220,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
-		if (unlikely(xen_netbk_tx_check_gop(vif, skb, &gop))) {
+		if (unlikely(xenvif_tx_check_gop(vif, skb, &gop))) {
 			netdev_dbg(vif->dev, "netback grant failed.\n");
 			skb_shinfo(skb)->nr_frags = 0;
 			kfree_skb(skb);
@@ -1236,7 +1237,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 			txp->size -= data_len;
 		} else {
 			/* Schedule a response immediately. */
-			xen_netbk_idx_release(vif, pending_idx);
+			xenvif_idx_release(vif, pending_idx);
 		}
 
 		if (txp->flags & XEN_NETTXF_csum_blank)
@@ -1244,7 +1245,7 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		else if (txp->flags & XEN_NETTXF_data_validated)
 			skb->ip_summed = CHECKSUM_UNNECESSARY;
 
-		xen_netbk_fill_frags(vif, skb);
+		xenvif_fill_frags(vif, skb);
 
 		/*
 		 * If the initial fragment was < PKT_PROT_LEN then
@@ -1269,39 +1270,45 @@ static void xen_netbk_tx_submit(struct xenvif *vif,
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
-		(*work_done)++;
+		work_done++;
 
 		xenvif_receive_skb(vif, skb);
 	}
+
+	return work_done;
 }
 
 /* Called after netfront has transmitted */
-void xen_netbk_tx_action(struct xenvif *vif, int *work_done, int budget)
+int xenvif_tx_action(struct xenvif *vif, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 	struct gnttab_copy *tco;
+	int work_done;
 
 	if (unlikely(!tx_work_todo(vif)))
-		return;
+		return 0;
 
 	tco = get_cpu_ptr(tx_copy_ops);
 
-	nr_gops = xen_netbk_tx_build_gops(vif, tco);
+	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
 		put_cpu_ptr(tco);
-		return;
+		return 0;
 	}
 
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(vif, tco, work_done, budget);
+	work_done = xenvif_tx_submit(vif, tco, budget);
+
 	put_cpu_ptr(tco);
+
+	return work_done;
 }
 
-static void xen_netbk_idx_release(struct xenvif *vif, u16 pending_idx)
+static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx)
 {
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
@@ -1382,7 +1389,7 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
 		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
@@ -1392,9 +1399,9 @@ void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 					vif->rx.sring);
 }
 
-int xen_netbk_map_frontend_rings(struct xenvif *vif,
-				 grant_ref_t tx_ring_ref,
-				 grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xenvif *vif,
+			      grant_ref_t tx_ring_ref,
+			      grant_ref_t rx_ring_ref)
 {
 	void *addr;
 	struct xen_netif_tx_sring *txs;
@@ -1423,11 +1430,11 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 	return 0;
 
 err:
-	xen_netbk_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
-int xen_netbk_kthread(void *data)
+int xenvif_kthread(void *data)
 {
 	struct xenvif *vif = data;
 
@@ -1441,7 +1448,7 @@ int xen_netbk_kthread(void *data)
 			break;
 
 		if (rx_work_todo(vif))
-			xen_netbk_rx_action(vif);
+			xenvif_rx_action(vif);
 	}
 
 	return 0;
@@ -1467,9 +1474,9 @@ static int __init netback_init(void)
 	if (!grant_copy_op)
 		goto failed_init_gco;
 
-	meta = __alloc_percpu(sizeof(struct netbk_rx_meta)
+	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
 			      * 2 * XEN_NETIF_RX_RING_SIZE,
-			      __alignof__(struct netbk_rx_meta));
+			      __alignof__(struct xenvif_rx_meta));
 	if (!meta)
 		goto failed_init_meta;
 
-- 
1.7.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 Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUG-0007FY-0T; Mon, 30 Jan 2012 14:45:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUE-0007FR-8u
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:38 +0000
Received: from [85.158.138.51:58088] by server-9.bemta-3.messagelabs.com id
	56/64-31168-11DA62F4; Mon, 30 Jan 2012 14:45:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16414 invoked from network); 30 Jan 2012 14:45:36 -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;
	30 Jan 2012 14:45:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413491"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:33 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTY029057;
	Mon, 30 Jan 2012 06:45:32 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:19 +0000
Message-ID: <1327934734-8908-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 01/16] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A global page pool. Since we are moving to 1:1 model netback, it is
better to limit total RAM consumed by all the vifs.

With this patch, each vif gets page from the pool and puts the page
back when it is finished with the page.

This pool is only meant to access via exported interfaces. Internals
are subject to change when we discover new requirements for the pool.

Current exported interfaces include:

page_pool_init: pool init
page_pool_destroy: pool destruction
page_pool_get: get a page from pool
page_pool_put: put page back to pool
is_in_pool: tell whether a page belongs to the pool

Current implementation has following defects:
 - Global locking
 - No starve prevention mechanism / reservation logic

Global locking tends to cause contention on the pool. No reservation
logic may cause vif to starve. A possible solution to these two
problems will be each vif maintains its local cache and claims a
portion of the pool. However the implementation will be tricky when
coming to pool management, so let's worry about that later.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |    6 +
 drivers/net/xen-netback/netback.c   |  158 ++++++++++++------------------
 drivers/net/xen-netback/page_pool.c |  185 +++++++++++++++++++++++++++++++++++
 drivers/net/xen-netback/page_pool.h |   63 ++++++++++++
 5 files changed, 317 insertions(+), 97 deletions(-)
 create mode 100644 drivers/net/xen-netback/page_pool.c
 create mode 100644 drivers/net/xen-netback/page_pool.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..dc4b8b1 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..288b2f3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,12 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+	struct xenvif *vif;
+};
+typedef unsigned int pending_ring_idx_t;
+
 struct xen_netbk;
 
 struct xenvif {
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 59effac..d11205f 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -33,6 +33,7 @@
  */
 
 #include "common.h"
+#include "page_pool.h"
 
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
@@ -46,12 +47,6 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-	struct xenvif *vif;
-};
-typedef unsigned int pending_ring_idx_t;
-
 struct netbk_rx_meta {
 	int id;
 	int size;
@@ -65,21 +60,6 @@ struct netbk_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-/* extra field used in struct page */
-union page_ext {
-	struct {
-#if BITS_PER_LONG < 64
-#define IDX_WIDTH   8
-#define GROUP_WIDTH (BITS_PER_LONG - IDX_WIDTH)
-		unsigned int group:GROUP_WIDTH;
-		unsigned int idx:IDX_WIDTH;
-#else
-		unsigned int group, idx;
-#endif
-	} e;
-	void *mapping;
-};
-
 struct xen_netbk {
 	wait_queue_head_t wq;
 	struct task_struct *task;
@@ -89,7 +69,7 @@ struct xen_netbk {
 
 	struct timer_list net_timer;
 
-	struct page *mmap_pages[MAX_PENDING_REQS];
+	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
@@ -100,7 +80,6 @@ struct xen_netbk {
 
 	atomic_t netfront_count;
 
-	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
 	u16 pending_ring[MAX_PENDING_REQS];
@@ -160,7 +139,7 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
 				       u16 idx)
 {
-	return page_to_pfn(netbk->mmap_pages[idx]);
+	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
 }
 
 static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
@@ -169,45 +148,6 @@ static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
 	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
 }
 
-/* extra field used in struct page */
-static inline void set_page_ext(struct page *pg, struct xen_netbk *netbk,
-				unsigned int idx)
-{
-	unsigned int group = netbk - xen_netbk;
-	union page_ext ext = { .e = { .group = group + 1, .idx = idx } };
-
-	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
-	pg->mapping = ext.mapping;
-}
-
-static int get_page_ext(struct page *pg,
-			unsigned int *pgroup, unsigned int *pidx)
-{
-	union page_ext ext = { .mapping = pg->mapping };
-	struct xen_netbk *netbk;
-	unsigned int group, idx;
-
-	group = ext.e.group - 1;
-
-	if (group < 0 || group >= xen_netbk_group_nr)
-		return 0;
-
-	netbk = &xen_netbk[group];
-
-	idx = ext.e.idx;
-
-	if ((idx < 0) || (idx >= MAX_PENDING_REQS))
-		return 0;
-
-	if (netbk->mmap_pages[idx] != pg)
-		return 0;
-
-	*pgroup = group;
-	*pidx = idx;
-
-	return 1;
-}
-
 /*
  * This is the amount of packet we copy rather than map, so that the
  * guest can't fiddle with the contents of the headers while we do
@@ -398,8 +338,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
-	unsigned int uninitialized_var(group), uninitialized_var(idx);
-	int foreign = get_page_ext(page, &group, &idx);
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
@@ -427,10 +367,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = &xen_netbk[group];
-			struct pending_tx_info *src_pend;
-
-			src_pend = &netbk->pending_tx_info[idx];
+			struct pending_tx_info *src_pend = to_txinfo(idx);
 
 			copy_gop->source.domid = src_pend->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
@@ -906,11 +843,11 @@ static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
 					 u16 pending_idx)
 {
 	struct page *page;
-	page = alloc_page(GFP_KERNEL|__GFP_COLD);
+	int idx;
+	page = page_pool_get(netbk, &idx);
 	if (!page)
 		return NULL;
-	set_page_ext(page, netbk, pending_idx);
-	netbk->mmap_pages[pending_idx] = page;
+	netbk->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
@@ -931,8 +868,8 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	for (i = start; i < shinfo->nr_frags; i++, txp++) {
 		struct page *page;
 		pending_ring_idx_t index;
-		struct pending_tx_info *pending_tx_info =
-			netbk->pending_tx_info;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		index = pending_index(netbk->pending_cons++);
 		pending_idx = netbk->pending_ring[index];
@@ -940,6 +877,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		if (!page)
 			return NULL;
 
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txp->offset;
@@ -953,9 +893,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 
 		gop++;
 
-		memcpy(&pending_tx_info[pending_idx].req, txp, sizeof(*txp));
+		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
 		xenvif_get(vif);
-		pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -968,8 +908,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
+	struct pending_tx_info *pending_tx_info;
+	int idx;
+	struct xenvif *vif = NULL;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -980,7 +921,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
 		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[index];
+		pending_tx_info = to_txinfo(idx);
+		txp = &pending_tx_info->req;
+		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
 		xenvif_put(vif);
@@ -1005,7 +949,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		txp = &to_txinfo(idx)->req;
+		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
@@ -1042,10 +988,15 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		struct xen_netif_tx_request *txp;
 		struct page *page;
 		u16 pending_idx;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		txp = &pending_tx_info->req;
 		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
@@ -1053,7 +1004,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(netbk->mmap_pages[pending_idx]);
+		get_page(page);
 		xen_netbk_idx_release(netbk, pending_idx);
 	}
 }
@@ -1233,6 +1184,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int work_to_do;
 		unsigned int data_len;
 		pending_ring_idx_t index;
+		int pool_idx;
+		struct pending_tx_info *pending_tx_info;
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
@@ -1347,9 +1300,12 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		gop++;
 
-		memcpy(&netbk->pending_tx_info[pending_idx].req,
+		pool_idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(pool_idx);
+
+		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		netbk->pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1397,10 +1353,16 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = *((u16 *)skb->data);
-		vif = netbk->pending_tx_info[pending_idx].vif;
-		txp = &netbk->pending_tx_info[pending_idx].req;
+
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		vif = pending_tx_info->vif;
+		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
 		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
@@ -1480,12 +1442,14 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
+	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == NULL)
+	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	pending_tx_info = &netbk->pending_tx_info[pending_idx];
+	idx = netbk->mmap_pages[pending_idx];
+	pending_tx_info = to_txinfo(idx);
 
 	vif = pending_tx_info->vif;
 
@@ -1496,9 +1460,9 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	xenvif_put(vif);
 
-	netbk->mmap_pages[pending_idx]->mapping = 0;
-	put_page(netbk->mmap_pages[pending_idx]);
-	netbk->mmap_pages[pending_idx] = NULL;
+	page_pool_put(netbk->mmap_pages[pending_idx]);
+
+	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1681,19 +1645,21 @@ static int __init netback_init(void)
 		wake_up_process(netbk->task);
 	}
 
-	rc = xenvif_xenbus_init();
+	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto pool_failed_init;
+
 	return 0;
 
+pool_failed_init:
+	page_pool_destroy();
 failed_init:
 	while (--group >= 0) {
 		struct xen_netbk *netbk = &xen_netbk[group];
-		for (i = 0; i < MAX_PENDING_REQS; i++) {
-			if (netbk->mmap_pages[i])
-				__free_page(netbk->mmap_pages[i]);
-		}
 		del_timer(&netbk->net_timer);
 		kthread_stop(netbk->task);
 	}
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
new file mode 100644
index 0000000..294f48b
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.c
@@ -0,0 +1,185 @@
+/*
+ * Global page pool for netback.
+ *
+ * Wei Liu <wei.liu2@citrix.com>
+ * Copyright (c) Citrix Systems
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "common.h"
+#include "page_pool.h"
+#include <asm/xen/page.h>
+
+static idx_t free_head;
+static int free_count;
+static unsigned long pool_size;
+static DEFINE_SPINLOCK(pool_lock);
+static struct page_pool_entry *pool;
+
+static int get_free_entry(void)
+{
+	int idx;
+
+	spin_lock(&pool_lock);
+
+	if (free_count == 0) {
+		spin_unlock(&pool_lock);
+		return -ENOSPC;
+	}
+
+	idx = free_head;
+	free_count--;
+	free_head = pool[idx].u.fl;
+	pool[idx].u.fl = INVALID_ENTRY;
+
+	spin_unlock(&pool_lock);
+
+	return idx;
+}
+
+static void put_free_entry(idx_t idx)
+{
+	spin_lock(&pool_lock);
+
+	pool[idx].u.fl = free_head;
+	free_head = idx;
+	free_count++;
+
+	spin_unlock(&pool_lock);
+}
+
+static inline void set_page_ext(struct page *pg, unsigned int idx)
+{
+	union page_ext ext = { .idx = idx };
+
+	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
+	pg->mapping = ext.mapping;
+}
+
+static int get_page_ext(struct page *pg, unsigned int *pidx)
+{
+	union page_ext ext = { .mapping = pg->mapping };
+	int idx;
+
+	idx = ext.idx;
+
+	if ((idx < 0) || (idx >= pool_size))
+		return 0;
+
+	if (pool[idx].page != pg)
+		return 0;
+
+	*pidx = idx;
+
+	return 1;
+}
+
+int is_in_pool(struct page *page, int *pidx)
+{
+	return get_page_ext(page, pidx);
+}
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+{
+	int idx;
+	struct page *page;
+
+	idx = get_free_entry();
+	if (idx < 0)
+		return NULL;
+	page = alloc_page(GFP_ATOMIC);
+
+	if (page == NULL) {
+		put_free_entry(idx);
+		return NULL;
+	}
+
+	set_page_ext(page, idx);
+	pool[idx].u.netbk = netbk;
+	pool[idx].page = page;
+
+	*pidx = idx;
+
+	return page;
+}
+
+void page_pool_put(int idx)
+{
+	struct page *page = pool[idx].page;
+
+	pool[idx].page = NULL;
+	pool[idx].u.netbk = NULL;
+	page->mapping = 0;
+	put_page(page);
+	put_free_entry(idx);
+}
+
+int page_pool_init()
+{
+	int cpus = 0;
+	int i;
+
+	cpus = num_online_cpus();
+	pool_size = cpus * ENTRIES_PER_CPU;
+
+	pool = vzalloc(sizeof(struct page_pool_entry) * pool_size);
+
+	if (!pool)
+		return -ENOMEM;
+
+	for (i = 0; i < pool_size - 1; i++)
+		pool[i].u.fl = i+1;
+	pool[pool_size-1].u.fl = INVALID_ENTRY;
+	free_count = pool_size;
+	free_head = 0;
+
+	return 0;
+}
+
+void page_pool_destroy()
+{
+	int i;
+	for (i = 0; i < pool_size; i++)
+		if (pool[i].page)
+			put_page(pool[i].page);
+
+	vfree(pool);
+}
+
+struct page *to_page(int idx)
+{
+	return pool[idx].page;
+}
+
+struct xen_netbk *to_netbk(int idx)
+{
+	return pool[idx].u.netbk;
+}
+
+struct pending_tx_info *to_txinfo(int idx)
+{
+	return &pool[idx].tx_info;
+}
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
new file mode 100644
index 0000000..572b037
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.h
@@ -0,0 +1,63 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __PAGE_POOL_H__
+#define __PAGE_POOL_H__
+
+#include "common.h"
+
+typedef uint32_t idx_t;
+
+#define ENTRIES_PER_CPU (1024)
+#define INVALID_ENTRY 0xffffffff
+
+struct page_pool_entry {
+	struct page *page;
+	struct pending_tx_info tx_info;
+	union {
+		struct xen_netbk *netbk;
+		idx_t             fl;
+	} u;
+};
+
+union page_ext {
+	idx_t idx;
+	void *mapping;
+};
+
+int  page_pool_init(void);
+void page_pool_destroy(void);
+
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+void         page_pool_put(int idx);
+int          is_in_pool(struct page *page, int *pidx);
+
+struct page            *to_page(int idx);
+struct xen_netbk       *to_netbk(int idx);
+struct pending_tx_info *to_txinfo(int idx);
+
+#endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUM-0007Hm-EN; Mon, 30 Jan 2012 14:45:46 +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 1RrsUK-0007FW-UD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32076 invoked from network); 30 Jan 2012 14:45:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614359"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:36 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTa029057;
	Mon, 30 Jan 2012 06:45:35 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:21 +0000
Message-ID: <1327934734-8908-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 03/16] netback: switch to NAPI + kthread
	model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements 1:1 model netback. We utilizes NAPI and kthread
to do the weight-lifting job:

  - NAPI is used for guest side TX (host side RX)
  - kthread is used for guest side RX (host side TX)

This model provides better scheduling fairness among vifs. It also
lays the foundation for future work.

The major defect for the current implementation is that in the NAPI
poll handler we don't actually disable frontend from generating
interrupt. Any tuning with ring pointers will come in as separated
commit.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   34 ++--
 drivers/net/xen-netback/interface.c |   92 ++++++---
 drivers/net/xen-netback/netback.c   |  367 ++++++++++-------------------------
 drivers/net/xen-netback/xenbus.c    |    1 -
 4 files changed, 186 insertions(+), 308 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 372c7f5..31c331c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,6 @@
 
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
-	struct xenvif *vif;
 };
 typedef unsigned int pending_ring_idx_t;
 
@@ -61,14 +60,17 @@ struct xenvif {
 	/* Reference to netback processing backend. */
 	struct xen_netbk *netbk;
 
+	/* Use NAPI for guest TX */
+	struct napi_struct napi;
+	/* Use kthread for guest RX */
+	struct task_struct *task;
+	wait_queue_head_t wq;
+
 	u8               fe_dev_addr[6];
 
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* List of frontends to notify after a batch of frames sent. */
-	struct list_head notify_list;
-
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
@@ -99,11 +101,7 @@ struct xenvif {
 	unsigned long rx_gso_checksum_fixup;
 
 	/* Miscellaneous private stuff. */
-	struct list_head schedule_list;
-	atomic_t         refcnt;
 	struct net_device *dev;
-
-	wait_queue_head_t waiting_to_free;
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +120,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
-void xenvif_get(struct xenvif *vif);
-void xenvif_put(struct xenvif *vif);
-
 int xenvif_xenbus_init(void);
 void xenvif_xenbus_exit(void);
 
@@ -140,14 +135,6 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 				 grant_ref_t tx_ring_ref,
 				 grant_ref_t rx_ring_ref);
 
-/* (De)Register a xenvif with the netback backend. */
-void xen_netbk_add_xenvif(struct xenvif *vif);
-void xen_netbk_remove_xenvif(struct xenvif *vif);
-
-/* (De)Schedule backend processing for a xenvif */
-void xen_netbk_schedule_xenvif(struct xenvif *vif);
-void xen_netbk_deschedule_xenvif(struct xenvif *vif);
-
 /* Check for SKBs from frontend and schedule backend processing */
 void xen_netbk_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
@@ -161,4 +148,13 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+/* Allocate and free xen_netbk structure */
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
+void xen_netbk_free_netbk(struct xen_netbk *netbk);
+
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
+void xen_netbk_rx_action(struct xen_netbk *netbk);
+
+int xen_netbk_kthread(void *data);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1825629..dfc04f8 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -30,6 +30,7 @@
 
 #include "common.h"
 
+#include <linux/kthread.h>
 #include <linux/ethtool.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
@@ -38,17 +39,7 @@
 #include <asm/xen/hypercall.h>
 
 #define XENVIF_QUEUE_LENGTH 32
-
-void xenvif_get(struct xenvif *vif)
-{
-	atomic_inc(&vif->refcnt);
-}
-
-void xenvif_put(struct xenvif *vif)
-{
-	if (atomic_dec_and_test(&vif->refcnt))
-		wake_up(&vif->waiting_to_free);
-}
+#define XENVIF_NAPI_WEIGHT  64
 
 int xenvif_schedulable(struct xenvif *vif)
 {
@@ -67,14 +58,37 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (vif->netbk == NULL)
 		return IRQ_NONE;
 
-	xen_netbk_schedule_xenvif(vif);
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
+	if (likely(napi_schedule_prep(&vif->napi)))
+		__napi_schedule(&vif->napi);
+
 	return IRQ_HANDLED;
 }
 
+static int xenvif_poll(struct napi_struct *napi, int budget)
+{
+	struct xenvif *vif = container_of(napi, struct xenvif, napi);
+	int work_done = 0;
+
+	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+
+	if (work_done < budget) {
+		int more_to_do = 0;
+		unsigned long flag;
+		local_irq_save(flag);
+
+		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
+		if (!more_to_do)
+			__napi_complete(napi);
+
+		local_irq_restore(flag);
+	}
+
+	return work_done;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -90,7 +104,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Reserve ring slots for the worst-case number of fragments. */
 	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
-	xenvif_get(vif);
 
 	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
 		netif_stop_queue(dev);
@@ -107,7 +120,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	netif_rx_ni(skb);
+	netif_receive_skb(skb);
 }
 
 void xenvif_notify_tx_completion(struct xenvif *vif)
@@ -124,16 +137,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 
 static void xenvif_up(struct xenvif *vif)
 {
-	xen_netbk_add_xenvif(vif);
+	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
+	napi_disable(&vif->napi);
 	disable_irq(vif->irq);
-	xen_netbk_deschedule_xenvif(vif);
-	xen_netbk_remove_xenvif(vif);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -259,14 +271,11 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk  = NULL;
+	vif->netbk = NULL;
+
 	vif->can_sg = 1;
 	vif->csum = 1;
-	atomic_set(&vif->refcnt, 1);
-	init_waitqueue_head(&vif->waiting_to_free);
 	vif->dev = dev;
-	INIT_LIST_HEAD(&vif->schedule_list);
-	INIT_LIST_HEAD(&vif->notify_list);
 
 	vif->credit_bytes = vif->remaining_credit = ~0UL;
 	vif->credit_usec  = 0UL;
@@ -290,6 +299,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	memset(dev->dev_addr, 0xFF, ETH_ALEN);
 	dev->dev_addr[0] &= ~0x01;
 
+	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
+
 	netif_carrier_off(dev);
 
 	err = register_netdev(dev);
@@ -324,7 +335,23 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
+	vif->netbk = xen_netbk_alloc_netbk(vif);
+	if (!vif->netbk) {
+		pr_warn("Could not allocate xen_netbk\n");
+		err = -ENOMEM;
+		goto err_unbind;
+	}
+
+
+	init_waitqueue_head(&vif->wq);
+	vif->task = kthread_create(xen_netbk_kthread,
+				   (void *)vif,
+				   "vif%d.%d", vif->domid, vif->handle);
+	if (IS_ERR(vif->task)) {
+		pr_warn("Could not create kthread\n");
+		err = PTR_ERR(vif->task);
+		goto err_free_netbk;
+	}
 
 	rtnl_lock();
 	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
@@ -335,7 +362,13 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		xenvif_up(vif);
 	rtnl_unlock();
 
+	wake_up_process(vif->task);
+
 	return 0;
+err_free_netbk:
+	xen_netbk_free_netbk(vif->netbk);
+err_unbind:
+	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
@@ -345,17 +378,22 @@ err:
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
 		netif_carrier_off(dev); /* discard queued packets */
 		if (netif_running(dev))
 			xenvif_down(vif);
 		rtnl_unlock();
-		xenvif_put(vif);
 	}
 
-	atomic_dec(&vif->refcnt);
-	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
+	if (vif->task)
+		kthread_stop(vif->task);
+
+	if (vif->netbk)
+		xen_netbk_free_netbk(vif->netbk);
+
+	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3059684..9a72993 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -61,24 +61,15 @@ struct netbk_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
-	wait_queue_head_t wq;
-	struct task_struct *task;
-
 	struct sk_buff_head rx_queue;
 	struct sk_buff_head tx_queue;
 
-	struct timer_list net_timer;
-
 	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
-	struct list_head net_schedule_list;
-
-	/* Protect the net_schedule_list in netif. */
-	spinlock_t net_schedule_list_lock;
 
-	atomic_t netfront_count;
+	struct xenvif *vif;
 
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
@@ -93,42 +84,14 @@ struct xen_netbk {
 	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
-static struct xen_netbk *xen_netbk;
-static int xen_netbk_group_nr;
-
-void xen_netbk_add_xenvif(struct xenvif *vif)
-{
-	int i;
-	int min_netfront_count;
-	int min_group = 0;
-	struct xen_netbk *netbk;
-
-	min_netfront_count = atomic_read(&xen_netbk[0].netfront_count);
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		int netfront_count = atomic_read(&xen_netbk[i].netfront_count);
-		if (netfront_count < min_netfront_count) {
-			min_group = i;
-			min_netfront_count = netfront_count;
-		}
-	}
-
-	netbk = &xen_netbk[min_group];
-
-	vif->netbk = netbk;
-	atomic_inc(&netbk->netfront_count);
-}
-
-void xen_netbk_remove_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	vif->netbk = NULL;
-	atomic_dec(&netbk->netfront_count);
-}
-
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
+
+static inline int tx_work_todo(struct xen_netbk *netbk);
+static inline int rx_work_todo(struct xen_netbk *netbk);
+
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
 					     s8       st,
@@ -179,11 +142,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
 		netbk->pending_prod + netbk->pending_cons;
 }
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
-{
-	wake_up(&netbk->wq);
-}
-
 static int max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
@@ -368,8 +326,9 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
+			struct xen_netbk *rnetbk = to_netbk(idx);
 
-			copy_gop->source.domid = src_pend->vif->domid;
+			copy_gop->source.domid = rnetbk->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -527,11 +486,18 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_rx_action(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xen_netbk *netbk)
 {
-	struct xenvif *vif = NULL, *tmp;
+	struct xenvif *vif = netbk->vif;
+
+	wake_up(&vif->wq);
+}
+
+void xen_netbk_rx_action(struct xen_netbk *netbk)
+{
+	struct xenvif *vif = NULL;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -541,6 +507,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int count;
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
 		.copy  = netbk->grant_copy_op,
@@ -641,25 +608,19 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
-		if (ret && list_empty(&vif->notify_list))
-			list_add_tail(&vif->notify_list, &notify);
+		if (ret)
+			need_to_notify = 1;
 
 		xenvif_notify_tx_completion(vif);
 
-		xenvif_put(vif);
 		npo.meta_cons += sco->meta_slots_used;
 		dev_kfree_skb(skb);
 	}
 
-	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
+	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
-		list_del_init(&vif->notify_list);
-	}
 
-	/* More work to do? */
-	if (!skb_queue_empty(&netbk->rx_queue) &&
-			!timer_pending(&netbk->net_timer))
+	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
 }
 
@@ -672,86 +633,17 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 	xen_netbk_kick_thread(netbk);
 }
 
-static void xen_netbk_alarm(unsigned long data)
-{
-	struct xen_netbk *netbk = (struct xen_netbk *)data;
-	xen_netbk_kick_thread(netbk);
-}
-
-static int __on_net_schedule_list(struct xenvif *vif)
-{
-	return !list_empty(&vif->schedule_list);
-}
-
-/* Must be called with net_schedule_list_lock held */
-static void remove_from_net_schedule_list(struct xenvif *vif)
-{
-	if (likely(__on_net_schedule_list(vif))) {
-		list_del_init(&vif->schedule_list);
-		xenvif_put(vif);
-	}
-}
-
-static struct xenvif *poll_net_schedule_list(struct xen_netbk *netbk)
-{
-	struct xenvif *vif = NULL;
-
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	if (list_empty(&netbk->net_schedule_list))
-		goto out;
-
-	vif = list_first_entry(&netbk->net_schedule_list,
-			       struct xenvif, schedule_list);
-	if (!vif)
-		goto out;
-
-	xenvif_get(vif);
-
-	remove_from_net_schedule_list(vif);
-out:
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-	return vif;
-}
-
-void xen_netbk_schedule_xenvif(struct xenvif *vif)
-{
-	unsigned long flags;
-	struct xen_netbk *netbk = vif->netbk;
-
-	if (__on_net_schedule_list(vif))
-		goto kick;
-
-	spin_lock_irqsave(&netbk->net_schedule_list_lock, flags);
-	if (!__on_net_schedule_list(vif) &&
-	    likely(xenvif_schedulable(vif))) {
-		list_add_tail(&vif->schedule_list, &netbk->net_schedule_list);
-		xenvif_get(vif);
-	}
-	spin_unlock_irqrestore(&netbk->net_schedule_list_lock, flags);
-
-kick:
-	smp_mb();
-	if ((nr_pending_reqs(netbk) < (MAX_PENDING_REQS/2)) &&
-	    !list_empty(&netbk->net_schedule_list))
-		xen_netbk_kick_thread(netbk);
-}
-
-void xen_netbk_deschedule_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	remove_from_net_schedule_list(vif);
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-}
-
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
 	RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
 
+	/* In this check function, we are supposed to do be's rx,
+	 * which means fe's tx */
+
 	if (more_to_do)
-		xen_netbk_schedule_xenvif(vif);
+		napi_schedule(&vif->napi);
 }
 
 static void tx_add_credit(struct xenvif *vif)
@@ -794,7 +686,6 @@ static void netbk_tx_err(struct xenvif *vif,
 	} while (1);
 	vif->tx.req_cons = cons;
 	xen_netbk_check_rx_xenvif(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
@@ -894,8 +785,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		gop++;
 
 		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
-		xenvif_get(vif);
-		pending_tx_info->vif = vif;
+
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -910,7 +800,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = NULL;
+	struct xenvif *vif = netbk->vif;
+
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -924,10 +815,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		idx = netbk->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
-		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -951,11 +840,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		/* Error on this fragment: respond to client with an error. */
 		idx = netbk->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
-		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1171,10 +1058,9 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
+	struct xenvif *vif = netbk->vif;
 
-	while (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-		!list_empty(&netbk->net_schedule_list)) {
-		struct xenvif *vif;
+	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1187,26 +1073,19 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		/* Get a netif from the list with work to do. */
-		vif = poll_net_schedule_list(netbk);
-		if (!vif)
-			continue;
-
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		idx = vif->tx.req_cons;
 		rmb(); /* Ensure that we see the request before we copy it. */
 		memcpy(&txreq, RING_GET_REQUEST(&vif->tx, idx), sizeof(txreq));
 
-		/* Credit-based scheduling. */
+		/* Credit-based traffic shaping. */
 		if (txreq.size > vif->remaining_credit &&
 		    tx_credit_exceeded(vif, txreq.size)) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		vif->remaining_credit -= txreq.size;
@@ -1221,14 +1100,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
 			netbk_tx_err(vif, &txreq, idx - ret);
-			continue;
+			break;
 		}
 		idx += ret;
 
@@ -1236,7 +1115,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
@@ -1246,7 +1125,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		index = pending_index(netbk->pending_cons);
@@ -1275,7 +1154,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			if (netbk_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
@@ -1284,7 +1163,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		gop->source.u.ref = txreq.gref;
@@ -1305,7 +1184,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		pending_tx_info->vif = vif;
+
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1329,7 +1208,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (request_gop == NULL) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 		gop = request_gop;
 
@@ -1343,14 +1222,16 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	return gop - netbk->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk)
+static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = netbk->tx_copy_ops;
 	struct sk_buff *skb;
+	struct xenvif *vif = netbk->vif;
 
-	while ((skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	while ((*work_done < budget) &&
+	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
-		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
 		int idx;
@@ -1361,7 +1242,6 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		idx = netbk->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
-		vif = pending_tx_info->vif;
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
@@ -1415,16 +1295,21 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
+		(*work_done)++;
+
 		xenvif_receive_skb(vif, skb);
 	}
 }
 
 /* Called after netfront has transmitted */
-static void xen_netbk_tx_action(struct xen_netbk *netbk)
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
+	if (unlikely(!tx_work_todo(netbk)))
+		return;
+
 	nr_gops = xen_netbk_tx_build_gops(netbk);
 
 	if (nr_gops == 0)
@@ -1433,13 +1318,12 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 					netbk->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk);
-
+	xen_netbk_tx_submit(netbk, work_done, budget);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 {
-	struct xenvif *vif;
+	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
@@ -1451,15 +1335,11 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	idx = netbk->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
-	vif = pending_tx_info->vif;
-
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
 
-	xenvif_put(vif);
-
 	page_pool_put(netbk->mmap_pages[pending_idx]);
 
 	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
@@ -1516,37 +1396,13 @@ static inline int rx_work_todo(struct xen_netbk *netbk)
 
 static inline int tx_work_todo(struct xen_netbk *netbk)
 {
-
-	if (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-			!list_empty(&netbk->net_schedule_list))
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
+	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
 }
 
-static int xen_netbk_kthread(void *data)
-{
-	struct xen_netbk *netbk = data;
-	while (!kthread_should_stop()) {
-		wait_event_interruptible(netbk->wq,
-				rx_work_todo(netbk) ||
-				tx_work_todo(netbk) ||
-				kthread_should_stop());
-		cond_resched();
-
-		if (kthread_should_stop())
-			break;
-
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
-
-		if (tx_work_todo(netbk))
-			xen_netbk_tx_action(netbk);
-	}
-
-	return 0;
-}
-
 void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
@@ -1592,78 +1448,74 @@ err:
 	return err;
 }
 
-static int __init netback_init(void)
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 {
 	int i;
-	int rc = 0;
-	int group;
-
-	if (!xen_domain())
-		return -ENODEV;
+	struct xen_netbk *netbk;
 
-	xen_netbk_group_nr = num_online_cpus();
-	xen_netbk = vzalloc(sizeof(struct xen_netbk) * xen_netbk_group_nr);
-	if (!xen_netbk) {
+	netbk = vzalloc(sizeof(struct xen_netbk));
+	if (!netbk) {
 		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return -ENOMEM;
+		return NULL;
 	}
 
-	for (group = 0; group < xen_netbk_group_nr; group++) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		skb_queue_head_init(&netbk->rx_queue);
-		skb_queue_head_init(&netbk->tx_queue);
-
-		init_timer(&netbk->net_timer);
-		netbk->net_timer.data = (unsigned long)netbk;
-		netbk->net_timer.function = xen_netbk_alarm;
-
-		netbk->pending_cons = 0;
-		netbk->pending_prod = MAX_PENDING_REQS;
-		for (i = 0; i < MAX_PENDING_REQS; i++)
-			netbk->pending_ring[i] = i;
-
-		init_waitqueue_head(&netbk->wq);
-		netbk->task = kthread_create(xen_netbk_kthread,
-					     (void *)netbk,
-					     "netback/%u", group);
-
-		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_create() fails at netback\n");
-			del_timer(&netbk->net_timer);
-			rc = PTR_ERR(netbk->task);
-			goto failed_init;
-		}
+	netbk->vif = vif;
 
-		kthread_bind(netbk->task, group);
+	skb_queue_head_init(&netbk->rx_queue);
+	skb_queue_head_init(&netbk->tx_queue);
 
-		INIT_LIST_HEAD(&netbk->net_schedule_list);
+	netbk->pending_cons = 0;
+	netbk->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->pending_ring[i] = i;
 
-		spin_lock_init(&netbk->net_schedule_list_lock);
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->mmap_pages[i] = INVALID_ENTRY;
 
-		atomic_set(&netbk->netfront_count, 0);
+	return netbk;
+}
 
-		wake_up_process(netbk->task);
+void xen_netbk_free_netbk(struct xen_netbk *netbk)
+{
+	vfree(netbk);
+}
+
+int xen_netbk_kthread(void *data)
+{
+	struct xenvif *vif = data;
+	struct xen_netbk *netbk = vif->netbk;
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(vif->wq,
+					 rx_work_todo(netbk) ||
+					 kthread_should_stop());
+		cond_resched();
+
+		if (kthread_should_stop())
+			break;
+
+		if (rx_work_todo(netbk))
+			xen_netbk_rx_action(netbk);
 	}
 
+	return 0;
+}
+
+
+static int __init netback_init(void)
+{
+	int rc = 0;
+
+	if (!xen_domain())
+		return -ENODEV;
+
 	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
-	rc = xenvif_xenbus_init();
-	if (rc)
-		goto pool_failed_init;
-
-	return 0;
+	return xenvif_xenbus_init();
 
-pool_failed_init:
-	page_pool_destroy();
 failed_init:
-	while (--group >= 0) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	return rc;
 
 }
@@ -1672,14 +1524,7 @@ module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
-	int i;
 	xenvif_xenbus_exit();
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		struct xen_netbk *netbk = &xen_netbk[i];
-		del_timer_sync(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	page_pool_destroy();
 }
 module_exit(netback_exit);
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..f1e89ca 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -387,7 +387,6 @@ static void connect(struct backend_info *be)
 	netif_wake_queue(be->vif->dev);
 }
 
-
 static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUM-0007Hm-EN; Mon, 30 Jan 2012 14:45:46 +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 1RrsUK-0007FW-UD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:45 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!3
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32076 invoked from network); 30 Jan 2012 14:45:38 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614359"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:36 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTa029057;
	Mon, 30 Jan 2012 06:45:35 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:21 +0000
Message-ID: <1327934734-8908-4-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 03/16] netback: switch to NAPI + kthread
	model
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements 1:1 model netback. We utilizes NAPI and kthread
to do the weight-lifting job:

  - NAPI is used for guest side TX (host side RX)
  - kthread is used for guest side RX (host side TX)

This model provides better scheduling fairness among vifs. It also
lays the foundation for future work.

The major defect for the current implementation is that in the NAPI
poll handler we don't actually disable frontend from generating
interrupt. Any tuning with ring pointers will come in as separated
commit.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   34 ++--
 drivers/net/xen-netback/interface.c |   92 ++++++---
 drivers/net/xen-netback/netback.c   |  367 ++++++++++-------------------------
 drivers/net/xen-netback/xenbus.c    |    1 -
 4 files changed, 186 insertions(+), 308 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 372c7f5..31c331c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -47,7 +47,6 @@
 
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
-	struct xenvif *vif;
 };
 typedef unsigned int pending_ring_idx_t;
 
@@ -61,14 +60,17 @@ struct xenvif {
 	/* Reference to netback processing backend. */
 	struct xen_netbk *netbk;
 
+	/* Use NAPI for guest TX */
+	struct napi_struct napi;
+	/* Use kthread for guest RX */
+	struct task_struct *task;
+	wait_queue_head_t wq;
+
 	u8               fe_dev_addr[6];
 
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* List of frontends to notify after a batch of frames sent. */
-	struct list_head notify_list;
-
 	/* The shared rings and indexes. */
 	struct xen_netif_tx_back_ring tx;
 	struct xen_netif_rx_back_ring rx;
@@ -99,11 +101,7 @@ struct xenvif {
 	unsigned long rx_gso_checksum_fixup;
 
 	/* Miscellaneous private stuff. */
-	struct list_head schedule_list;
-	atomic_t         refcnt;
 	struct net_device *dev;
-
-	wait_queue_head_t waiting_to_free;
 };
 
 static inline struct xenbus_device *xenvif_to_xenbus_device(struct xenvif *vif)
@@ -122,9 +120,6 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		   unsigned long rx_ring_ref, unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
-void xenvif_get(struct xenvif *vif);
-void xenvif_put(struct xenvif *vif);
-
 int xenvif_xenbus_init(void);
 void xenvif_xenbus_exit(void);
 
@@ -140,14 +135,6 @@ int xen_netbk_map_frontend_rings(struct xenvif *vif,
 				 grant_ref_t tx_ring_ref,
 				 grant_ref_t rx_ring_ref);
 
-/* (De)Register a xenvif with the netback backend. */
-void xen_netbk_add_xenvif(struct xenvif *vif);
-void xen_netbk_remove_xenvif(struct xenvif *vif);
-
-/* (De)Schedule backend processing for a xenvif */
-void xen_netbk_schedule_xenvif(struct xenvif *vif);
-void xen_netbk_deschedule_xenvif(struct xenvif *vif);
-
 /* Check for SKBs from frontend and schedule backend processing */
 void xen_netbk_check_rx_xenvif(struct xenvif *vif);
 /* Receive an SKB from the frontend */
@@ -161,4 +148,13 @@ void xenvif_notify_tx_completion(struct xenvif *vif);
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
 
+/* Allocate and free xen_netbk structure */
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif);
+void xen_netbk_free_netbk(struct xen_netbk *netbk);
+
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget);
+void xen_netbk_rx_action(struct xen_netbk *netbk);
+
+int xen_netbk_kthread(void *data);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 1825629..dfc04f8 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -30,6 +30,7 @@
 
 #include "common.h"
 
+#include <linux/kthread.h>
 #include <linux/ethtool.h>
 #include <linux/rtnetlink.h>
 #include <linux/if_vlan.h>
@@ -38,17 +39,7 @@
 #include <asm/xen/hypercall.h>
 
 #define XENVIF_QUEUE_LENGTH 32
-
-void xenvif_get(struct xenvif *vif)
-{
-	atomic_inc(&vif->refcnt);
-}
-
-void xenvif_put(struct xenvif *vif)
-{
-	if (atomic_dec_and_test(&vif->refcnt))
-		wake_up(&vif->waiting_to_free);
-}
+#define XENVIF_NAPI_WEIGHT  64
 
 int xenvif_schedulable(struct xenvif *vif)
 {
@@ -67,14 +58,37 @@ static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 	if (vif->netbk == NULL)
 		return IRQ_NONE;
 
-	xen_netbk_schedule_xenvif(vif);
-
 	if (xenvif_rx_schedulable(vif))
 		netif_wake_queue(vif->dev);
 
+	if (likely(napi_schedule_prep(&vif->napi)))
+		__napi_schedule(&vif->napi);
+
 	return IRQ_HANDLED;
 }
 
+static int xenvif_poll(struct napi_struct *napi, int budget)
+{
+	struct xenvif *vif = container_of(napi, struct xenvif, napi);
+	int work_done = 0;
+
+	xen_netbk_tx_action(vif->netbk, &work_done, budget);
+
+	if (work_done < budget) {
+		int more_to_do = 0;
+		unsigned long flag;
+		local_irq_save(flag);
+
+		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
+		if (!more_to_do)
+			__napi_complete(napi);
+
+		local_irq_restore(flag);
+	}
+
+	return work_done;
+}
+
 static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -90,7 +104,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	/* Reserve ring slots for the worst-case number of fragments. */
 	vif->rx_req_cons_peek += xen_netbk_count_skb_slots(vif, skb);
-	xenvif_get(vif);
 
 	if (vif->can_queue && xen_netbk_must_stop_queue(vif))
 		netif_stop_queue(dev);
@@ -107,7 +120,7 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
 {
-	netif_rx_ni(skb);
+	netif_receive_skb(skb);
 }
 
 void xenvif_notify_tx_completion(struct xenvif *vif)
@@ -124,16 +137,15 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 
 static void xenvif_up(struct xenvif *vif)
 {
-	xen_netbk_add_xenvif(vif);
+	napi_enable(&vif->napi);
 	enable_irq(vif->irq);
 	xen_netbk_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
+	napi_disable(&vif->napi);
 	disable_irq(vif->irq);
-	xen_netbk_deschedule_xenvif(vif);
-	xen_netbk_remove_xenvif(vif);
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -259,14 +271,11 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	vif = netdev_priv(dev);
 	vif->domid  = domid;
 	vif->handle = handle;
-	vif->netbk  = NULL;
+	vif->netbk = NULL;
+
 	vif->can_sg = 1;
 	vif->csum = 1;
-	atomic_set(&vif->refcnt, 1);
-	init_waitqueue_head(&vif->waiting_to_free);
 	vif->dev = dev;
-	INIT_LIST_HEAD(&vif->schedule_list);
-	INIT_LIST_HEAD(&vif->notify_list);
 
 	vif->credit_bytes = vif->remaining_credit = ~0UL;
 	vif->credit_usec  = 0UL;
@@ -290,6 +299,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	memset(dev->dev_addr, 0xFF, ETH_ALEN);
 	dev->dev_addr[0] &= ~0x01;
 
+	netif_napi_add(dev, &vif->napi, xenvif_poll, XENVIF_NAPI_WEIGHT);
+
 	netif_carrier_off(dev);
 
 	err = register_netdev(dev);
@@ -324,7 +335,23 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	vif->irq = err;
 	disable_irq(vif->irq);
 
-	xenvif_get(vif);
+	vif->netbk = xen_netbk_alloc_netbk(vif);
+	if (!vif->netbk) {
+		pr_warn("Could not allocate xen_netbk\n");
+		err = -ENOMEM;
+		goto err_unbind;
+	}
+
+
+	init_waitqueue_head(&vif->wq);
+	vif->task = kthread_create(xen_netbk_kthread,
+				   (void *)vif,
+				   "vif%d.%d", vif->domid, vif->handle);
+	if (IS_ERR(vif->task)) {
+		pr_warn("Could not create kthread\n");
+		err = PTR_ERR(vif->task);
+		goto err_free_netbk;
+	}
 
 	rtnl_lock();
 	if (!vif->can_sg && vif->dev->mtu > ETH_DATA_LEN)
@@ -335,7 +362,13 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 		xenvif_up(vif);
 	rtnl_unlock();
 
+	wake_up_process(vif->task);
+
 	return 0;
+err_free_netbk:
+	xen_netbk_free_netbk(vif->netbk);
+err_unbind:
+	unbind_from_irqhandler(vif->irq, vif);
 err_unmap:
 	xen_netbk_unmap_frontend_rings(vif);
 err:
@@ -345,17 +378,22 @@ err:
 void xenvif_disconnect(struct xenvif *vif)
 {
 	struct net_device *dev = vif->dev;
+
 	if (netif_carrier_ok(dev)) {
 		rtnl_lock();
 		netif_carrier_off(dev); /* discard queued packets */
 		if (netif_running(dev))
 			xenvif_down(vif);
 		rtnl_unlock();
-		xenvif_put(vif);
 	}
 
-	atomic_dec(&vif->refcnt);
-	wait_event(vif->waiting_to_free, atomic_read(&vif->refcnt) == 0);
+	if (vif->task)
+		kthread_stop(vif->task);
+
+	if (vif->netbk)
+		xen_netbk_free_netbk(vif->netbk);
+
+	netif_napi_del(&vif->napi);
 
 	del_timer_sync(&vif->credit_timeout);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 3059684..9a72993 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -61,24 +61,15 @@ struct netbk_rx_meta {
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
-	wait_queue_head_t wq;
-	struct task_struct *task;
-
 	struct sk_buff_head rx_queue;
 	struct sk_buff_head tx_queue;
 
-	struct timer_list net_timer;
-
 	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
-	struct list_head net_schedule_list;
-
-	/* Protect the net_schedule_list in netif. */
-	spinlock_t net_schedule_list_lock;
 
-	atomic_t netfront_count;
+	struct xenvif *vif;
 
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
@@ -93,42 +84,14 @@ struct xen_netbk {
 	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
-static struct xen_netbk *xen_netbk;
-static int xen_netbk_group_nr;
-
-void xen_netbk_add_xenvif(struct xenvif *vif)
-{
-	int i;
-	int min_netfront_count;
-	int min_group = 0;
-	struct xen_netbk *netbk;
-
-	min_netfront_count = atomic_read(&xen_netbk[0].netfront_count);
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		int netfront_count = atomic_read(&xen_netbk[i].netfront_count);
-		if (netfront_count < min_netfront_count) {
-			min_group = i;
-			min_netfront_count = netfront_count;
-		}
-	}
-
-	netbk = &xen_netbk[min_group];
-
-	vif->netbk = netbk;
-	atomic_inc(&netbk->netfront_count);
-}
-
-void xen_netbk_remove_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	vif->netbk = NULL;
-	atomic_dec(&netbk->netfront_count);
-}
-
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
 			     struct xen_netif_tx_request *txp,
 			     s8       st);
+
+static inline int tx_work_todo(struct xen_netbk *netbk);
+static inline int rx_work_todo(struct xen_netbk *netbk);
+
 static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 					     u16      id,
 					     s8       st,
@@ -179,11 +142,6 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xen_netbk *netbk)
 		netbk->pending_prod + netbk->pending_cons;
 }
 
-static void xen_netbk_kick_thread(struct xen_netbk *netbk)
-{
-	wake_up(&netbk->wq);
-}
-
 static int max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
@@ -368,8 +326,9 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
 			struct pending_tx_info *src_pend = to_txinfo(idx);
+			struct xen_netbk *rnetbk = to_netbk(idx);
 
-			copy_gop->source.domid = src_pend->vif->domid;
+			copy_gop->source.domid = rnetbk->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
 			copy_gop->flags |= GNTCOPY_source_gref;
 		} else {
@@ -527,11 +486,18 @@ struct skb_cb_overlay {
 	int meta_slots_used;
 };
 
-static void xen_netbk_rx_action(struct xen_netbk *netbk)
+static void xen_netbk_kick_thread(struct xen_netbk *netbk)
 {
-	struct xenvif *vif = NULL, *tmp;
+	struct xenvif *vif = netbk->vif;
+
+	wake_up(&vif->wq);
+}
+
+void xen_netbk_rx_action(struct xen_netbk *netbk)
+{
+	struct xenvif *vif = NULL;
 	s8 status;
-	u16 irq, flags;
+	u16 flags;
 	struct xen_netif_rx_response *resp;
 	struct sk_buff_head rxq;
 	struct sk_buff *skb;
@@ -541,6 +507,7 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 	int count;
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
 
 	struct netrx_pending_operations npo = {
 		.copy  = netbk->grant_copy_op,
@@ -641,25 +608,19 @@ static void xen_netbk_rx_action(struct xen_netbk *netbk)
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		irq = vif->irq;
-		if (ret && list_empty(&vif->notify_list))
-			list_add_tail(&vif->notify_list, &notify);
+		if (ret)
+			need_to_notify = 1;
 
 		xenvif_notify_tx_completion(vif);
 
-		xenvif_put(vif);
 		npo.meta_cons += sco->meta_slots_used;
 		dev_kfree_skb(skb);
 	}
 
-	list_for_each_entry_safe(vif, tmp, &notify, notify_list) {
+	if (need_to_notify)
 		notify_remote_via_irq(vif->irq);
-		list_del_init(&vif->notify_list);
-	}
 
-	/* More work to do? */
-	if (!skb_queue_empty(&netbk->rx_queue) &&
-			!timer_pending(&netbk->net_timer))
+	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
 }
 
@@ -672,86 +633,17 @@ void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 	xen_netbk_kick_thread(netbk);
 }
 
-static void xen_netbk_alarm(unsigned long data)
-{
-	struct xen_netbk *netbk = (struct xen_netbk *)data;
-	xen_netbk_kick_thread(netbk);
-}
-
-static int __on_net_schedule_list(struct xenvif *vif)
-{
-	return !list_empty(&vif->schedule_list);
-}
-
-/* Must be called with net_schedule_list_lock held */
-static void remove_from_net_schedule_list(struct xenvif *vif)
-{
-	if (likely(__on_net_schedule_list(vif))) {
-		list_del_init(&vif->schedule_list);
-		xenvif_put(vif);
-	}
-}
-
-static struct xenvif *poll_net_schedule_list(struct xen_netbk *netbk)
-{
-	struct xenvif *vif = NULL;
-
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	if (list_empty(&netbk->net_schedule_list))
-		goto out;
-
-	vif = list_first_entry(&netbk->net_schedule_list,
-			       struct xenvif, schedule_list);
-	if (!vif)
-		goto out;
-
-	xenvif_get(vif);
-
-	remove_from_net_schedule_list(vif);
-out:
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-	return vif;
-}
-
-void xen_netbk_schedule_xenvif(struct xenvif *vif)
-{
-	unsigned long flags;
-	struct xen_netbk *netbk = vif->netbk;
-
-	if (__on_net_schedule_list(vif))
-		goto kick;
-
-	spin_lock_irqsave(&netbk->net_schedule_list_lock, flags);
-	if (!__on_net_schedule_list(vif) &&
-	    likely(xenvif_schedulable(vif))) {
-		list_add_tail(&vif->schedule_list, &netbk->net_schedule_list);
-		xenvif_get(vif);
-	}
-	spin_unlock_irqrestore(&netbk->net_schedule_list_lock, flags);
-
-kick:
-	smp_mb();
-	if ((nr_pending_reqs(netbk) < (MAX_PENDING_REQS/2)) &&
-	    !list_empty(&netbk->net_schedule_list))
-		xen_netbk_kick_thread(netbk);
-}
-
-void xen_netbk_deschedule_xenvif(struct xenvif *vif)
-{
-	struct xen_netbk *netbk = vif->netbk;
-	spin_lock_irq(&netbk->net_schedule_list_lock);
-	remove_from_net_schedule_list(vif);
-	spin_unlock_irq(&netbk->net_schedule_list_lock);
-}
-
 void xen_netbk_check_rx_xenvif(struct xenvif *vif)
 {
 	int more_to_do;
 
 	RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
 
+	/* In this check function, we are supposed to do be's rx,
+	 * which means fe's tx */
+
 	if (more_to_do)
-		xen_netbk_schedule_xenvif(vif);
+		napi_schedule(&vif->napi);
 }
 
 static void tx_add_credit(struct xenvif *vif)
@@ -794,7 +686,6 @@ static void netbk_tx_err(struct xenvif *vif,
 	} while (1);
 	vif->tx.req_cons = cons;
 	xen_netbk_check_rx_xenvif(vif);
-	xenvif_put(vif);
 }
 
 static int netbk_count_requests(struct xenvif *vif,
@@ -894,8 +785,7 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		gop++;
 
 		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
-		xenvif_get(vif);
-		pending_tx_info->vif = vif;
+
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -910,7 +800,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	u16 pending_idx = *((u16 *)skb->data);
 	struct pending_tx_info *pending_tx_info;
 	int idx;
-	struct xenvif *vif = NULL;
+	struct xenvif *vif = netbk->vif;
+
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -924,10 +815,8 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		idx = netbk->mmap_pages[index];
 		pending_tx_info = to_txinfo(idx);
 		txp = &pending_tx_info->req;
-		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 	}
 
 	/* Skip first skb fragment if it is on same page as header fragment. */
@@ -951,11 +840,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		/* Error on this fragment: respond to client with an error. */
 		idx = netbk->mmap_pages[pending_idx];
 		txp = &to_txinfo(idx)->req;
-		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
-		xenvif_put(vif);
 
 		/* Not the first error? Preceding frags already invalidated. */
 		if (err)
@@ -1171,10 +1058,9 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
 	struct sk_buff *skb;
 	int ret;
+	struct xenvif *vif = netbk->vif;
 
-	while (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-		!list_empty(&netbk->net_schedule_list)) {
-		struct xenvif *vif;
+	while ((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) {
 		struct xen_netif_tx_request txreq;
 		struct xen_netif_tx_request txfrags[MAX_SKB_FRAGS];
 		struct page *page;
@@ -1187,26 +1073,19 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int pool_idx;
 		struct pending_tx_info *pending_tx_info;
 
-		/* Get a netif from the list with work to do. */
-		vif = poll_net_schedule_list(netbk);
-		if (!vif)
-			continue;
-
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, work_to_do);
 		if (!work_to_do) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		idx = vif->tx.req_cons;
 		rmb(); /* Ensure that we see the request before we copy it. */
 		memcpy(&txreq, RING_GET_REQUEST(&vif->tx, idx), sizeof(txreq));
 
-		/* Credit-based scheduling. */
+		/* Credit-based traffic shaping. */
 		if (txreq.size > vif->remaining_credit &&
 		    tx_credit_exceeded(vif, txreq.size)) {
-			xenvif_put(vif);
-			continue;
+			break;
 		}
 
 		vif->remaining_credit -= txreq.size;
@@ -1221,14 +1100,14 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			idx = vif->tx.req_cons;
 			if (unlikely(work_to_do < 0)) {
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
 		ret = netbk_count_requests(vif, &txreq, txfrags, work_to_do);
 		if (unlikely(ret < 0)) {
 			netbk_tx_err(vif, &txreq, idx - ret);
-			continue;
+			break;
 		}
 		idx += ret;
 
@@ -1236,7 +1115,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			netdev_dbg(vif->dev,
 				   "Bad packet size: %d\n", txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		/* No crossing a page as the payload mustn't fragment. */
@@ -1246,7 +1125,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 				   txreq.offset, txreq.size,
 				   (txreq.offset&~PAGE_MASK) + txreq.size);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		index = pending_index(netbk->pending_cons);
@@ -1275,7 +1154,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 			if (netbk_set_skb_gso(vif, skb, gso)) {
 				kfree_skb(skb);
 				netbk_tx_err(vif, &txreq, idx);
-				continue;
+				break;
 			}
 		}
 
@@ -1284,7 +1163,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (!page) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 
 		gop->source.u.ref = txreq.gref;
@@ -1305,7 +1184,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		pending_tx_info->vif = vif;
+
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1329,7 +1208,7 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		if (request_gop == NULL) {
 			kfree_skb(skb);
 			netbk_tx_err(vif, &txreq, idx);
-			continue;
+			break;
 		}
 		gop = request_gop;
 
@@ -1343,14 +1222,16 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 	return gop - netbk->tx_copy_ops;
 }
 
-static void xen_netbk_tx_submit(struct xen_netbk *netbk)
+static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				int *work_done, int budget)
 {
 	struct gnttab_copy *gop = netbk->tx_copy_ops;
 	struct sk_buff *skb;
+	struct xenvif *vif = netbk->vif;
 
-	while ((skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
+	while ((*work_done < budget) &&
+	       (skb = __skb_dequeue(&netbk->tx_queue)) != NULL) {
 		struct xen_netif_tx_request *txp;
-		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
 		int idx;
@@ -1361,7 +1242,6 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		idx = netbk->mmap_pages[pending_idx];
 		pending_tx_info = to_txinfo(idx);
 
-		vif = pending_tx_info->vif;
 		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
@@ -1415,16 +1295,21 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		vif->dev->stats.rx_bytes += skb->len;
 		vif->dev->stats.rx_packets++;
 
+		(*work_done)++;
+
 		xenvif_receive_skb(vif, skb);
 	}
 }
 
 /* Called after netfront has transmitted */
-static void xen_netbk_tx_action(struct xen_netbk *netbk)
+void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
 
+	if (unlikely(!tx_work_todo(netbk)))
+		return;
+
 	nr_gops = xen_netbk_tx_build_gops(netbk);
 
 	if (nr_gops == 0)
@@ -1433,13 +1318,12 @@ static void xen_netbk_tx_action(struct xen_netbk *netbk)
 					netbk->tx_copy_ops, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk);
-
+	xen_netbk_tx_submit(netbk, work_done, budget);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 {
-	struct xenvif *vif;
+	struct xenvif *vif = netbk->vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
 	int idx;
@@ -1451,15 +1335,11 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	idx = netbk->mmap_pages[pending_idx];
 	pending_tx_info = to_txinfo(idx);
 
-	vif = pending_tx_info->vif;
-
 	make_tx_response(vif, &pending_tx_info->req, XEN_NETIF_RSP_OKAY);
 
 	index = pending_index(netbk->pending_prod++);
 	netbk->pending_ring[index] = pending_idx;
 
-	xenvif_put(vif);
-
 	page_pool_put(netbk->mmap_pages[pending_idx]);
 
 	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
@@ -1516,37 +1396,13 @@ static inline int rx_work_todo(struct xen_netbk *netbk)
 
 static inline int tx_work_todo(struct xen_netbk *netbk)
 {
-
-	if (((nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS) &&
-			!list_empty(&netbk->net_schedule_list))
+	if (likely(RING_HAS_UNCONSUMED_REQUESTS(&netbk->vif->tx)) &&
+	    (nr_pending_reqs(netbk) + MAX_SKB_FRAGS) < MAX_PENDING_REQS)
 		return 1;
 
 	return 0;
 }
 
-static int xen_netbk_kthread(void *data)
-{
-	struct xen_netbk *netbk = data;
-	while (!kthread_should_stop()) {
-		wait_event_interruptible(netbk->wq,
-				rx_work_todo(netbk) ||
-				tx_work_todo(netbk) ||
-				kthread_should_stop());
-		cond_resched();
-
-		if (kthread_should_stop())
-			break;
-
-		if (rx_work_todo(netbk))
-			xen_netbk_rx_action(netbk);
-
-		if (tx_work_todo(netbk))
-			xen_netbk_tx_action(netbk);
-	}
-
-	return 0;
-}
-
 void xen_netbk_unmap_frontend_rings(struct xenvif *vif)
 {
 	if (vif->tx.sring)
@@ -1592,78 +1448,74 @@ err:
 	return err;
 }
 
-static int __init netback_init(void)
+struct xen_netbk *xen_netbk_alloc_netbk(struct xenvif *vif)
 {
 	int i;
-	int rc = 0;
-	int group;
-
-	if (!xen_domain())
-		return -ENODEV;
+	struct xen_netbk *netbk;
 
-	xen_netbk_group_nr = num_online_cpus();
-	xen_netbk = vzalloc(sizeof(struct xen_netbk) * xen_netbk_group_nr);
-	if (!xen_netbk) {
+	netbk = vzalloc(sizeof(struct xen_netbk));
+	if (!netbk) {
 		printk(KERN_ALERT "%s: out of memory\n", __func__);
-		return -ENOMEM;
+		return NULL;
 	}
 
-	for (group = 0; group < xen_netbk_group_nr; group++) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		skb_queue_head_init(&netbk->rx_queue);
-		skb_queue_head_init(&netbk->tx_queue);
-
-		init_timer(&netbk->net_timer);
-		netbk->net_timer.data = (unsigned long)netbk;
-		netbk->net_timer.function = xen_netbk_alarm;
-
-		netbk->pending_cons = 0;
-		netbk->pending_prod = MAX_PENDING_REQS;
-		for (i = 0; i < MAX_PENDING_REQS; i++)
-			netbk->pending_ring[i] = i;
-
-		init_waitqueue_head(&netbk->wq);
-		netbk->task = kthread_create(xen_netbk_kthread,
-					     (void *)netbk,
-					     "netback/%u", group);
-
-		if (IS_ERR(netbk->task)) {
-			printk(KERN_ALERT "kthread_create() fails at netback\n");
-			del_timer(&netbk->net_timer);
-			rc = PTR_ERR(netbk->task);
-			goto failed_init;
-		}
+	netbk->vif = vif;
 
-		kthread_bind(netbk->task, group);
+	skb_queue_head_init(&netbk->rx_queue);
+	skb_queue_head_init(&netbk->tx_queue);
 
-		INIT_LIST_HEAD(&netbk->net_schedule_list);
+	netbk->pending_cons = 0;
+	netbk->pending_prod = MAX_PENDING_REQS;
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->pending_ring[i] = i;
 
-		spin_lock_init(&netbk->net_schedule_list_lock);
+	for (i = 0; i < MAX_PENDING_REQS; i++)
+		netbk->mmap_pages[i] = INVALID_ENTRY;
 
-		atomic_set(&netbk->netfront_count, 0);
+	return netbk;
+}
 
-		wake_up_process(netbk->task);
+void xen_netbk_free_netbk(struct xen_netbk *netbk)
+{
+	vfree(netbk);
+}
+
+int xen_netbk_kthread(void *data)
+{
+	struct xenvif *vif = data;
+	struct xen_netbk *netbk = vif->netbk;
+
+	while (!kthread_should_stop()) {
+		wait_event_interruptible(vif->wq,
+					 rx_work_todo(netbk) ||
+					 kthread_should_stop());
+		cond_resched();
+
+		if (kthread_should_stop())
+			break;
+
+		if (rx_work_todo(netbk))
+			xen_netbk_rx_action(netbk);
 	}
 
+	return 0;
+}
+
+
+static int __init netback_init(void)
+{
+	int rc = 0;
+
+	if (!xen_domain())
+		return -ENODEV;
+
 	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
-	rc = xenvif_xenbus_init();
-	if (rc)
-		goto pool_failed_init;
-
-	return 0;
+	return xenvif_xenbus_init();
 
-pool_failed_init:
-	page_pool_destroy();
 failed_init:
-	while (--group >= 0) {
-		struct xen_netbk *netbk = &xen_netbk[group];
-		del_timer(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	return rc;
 
 }
@@ -1672,14 +1524,7 @@ module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
-	int i;
 	xenvif_xenbus_exit();
-	for (i = 0; i < xen_netbk_group_nr; i++) {
-		struct xen_netbk *netbk = &xen_netbk[i];
-		del_timer_sync(&netbk->net_timer);
-		kthread_stop(netbk->task);
-	}
-	vfree(xen_netbk);
 	page_pool_destroy();
 }
 module_exit(netback_exit);
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 65d14f2..f1e89ca 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -387,7 +387,6 @@ static void connect(struct backend_info *be)
 	netif_wake_queue(be->vif->dev);
 }
 
-
 static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUJ-0007GK-KP; Mon, 30 Jan 2012 14:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUG-0007FX-CV
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:40 +0000
Received: from [85.158.138.51:58278] by server-6.bemta-3.messagelabs.com id
	3F/D5-31032-31DA62F4; Mon, 30 Jan 2012 14:45:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16546 invoked from network); 30 Jan 2012 14:45:38 -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;
	30 Jan 2012 14:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413495"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:37 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTb029057;
	Mon, 30 Jan 2012 06:45:36 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:22 +0000
Message-ID: <1327934734-8908-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 04/16] netback: switch to per-cpu scratch
	space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, given that there are maximum nr_online_cpus netbacks
running, we can use per-cpu scratch space, thus shrinking size of
struct xen_netbk.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |   13 ++++
 drivers/net/xen-netback/netback.c |  134 ++++++++++++++++++++++++-------------
 2 files changed, 100 insertions(+), 47 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 31c331c..3b85563 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,19 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct netbk_rx_meta {
+	int id;
+	int size;
+	int gso_size;
+};
+
+#define MAX_PENDING_REQS 256
+
+/* Discriminate from any valid pending_idx value. */
+#define INVALID_PENDING_IDX 0xFFFF
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
 };
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 9a72993..1c68afb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1,3 +1,4 @@
+
 /*
  * Back-end of the driver for virtual network devices. This portion of the
  * driver exports a 'unified' network-device interface that can be accessed
@@ -47,18 +48,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct netbk_rx_meta {
-	int id;
-	int size;
-	int gso_size;
-};
 
-#define MAX_PENDING_REQS 256
+struct gnttab_copy *tx_copy_ops;
 
-/* Discriminate from any valid pending_idx value. */
-#define INVALID_PENDING_IDX 0xFFFF
+/*
+ * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
+ * head/fragment page uses 2 copy operations because it
+ * straddles two buffers in the frontend.
+ */
+struct gnttab_copy *grant_copy_op;
+struct netbk_rx_meta *meta;
 
-#define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
 	struct sk_buff_head rx_queue;
@@ -71,17 +71,7 @@ struct xen_netbk {
 
 	struct xenvif *vif;
 
-	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
-
 	u16 pending_ring[MAX_PENDING_REQS];
-
-	/*
-	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
-	 * head/fragment page uses 2 copy operations because it
-	 * straddles two buffers in the frontend.
-	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
@@ -509,9 +499,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
 
+	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
+	struct netbk_rx_meta *m = get_cpu_ptr(meta);
+
 	struct netrx_pending_operations npo = {
-		.copy  = netbk->grant_copy_op,
-		.meta  = netbk->meta,
+		.copy  = gco,
+		.meta  = m,
 	};
 
 	skb_queue_head_init(&rxq);
@@ -534,13 +527,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			break;
 	}
 
-	BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
+	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
 
-	if (!npo.copy_prod)
+	if (!npo.copy_prod) {
+		put_cpu_ptr(gco);
+		put_cpu_ptr(m);
 		return;
+	}
 
-	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
+	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
 
@@ -549,14 +545,14 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 		vif = netdev_priv(skb->dev);
 
-		if (netbk->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
 
 			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
 
-			resp->offset = netbk->meta[npo.meta_cons].gso_size;
-			resp->id = netbk->meta[npo.meta_cons].id;
+			resp->offset = m[npo.meta_cons].gso_size;
+			resp->id = m[npo.meta_cons].id;
 			resp->status = sco->meta_slots_used;
 
 			npo.meta_cons++;
@@ -581,12 +577,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			flags |= XEN_NETRXF_data_validated;
 
 		offset = 0;
-		resp = make_rx_response(vif, netbk->meta[npo.meta_cons].id,
+		resp = make_rx_response(vif, m[npo.meta_cons].id,
 					status, offset,
-					netbk->meta[npo.meta_cons].size,
+					m[npo.meta_cons].size,
 					flags);
 
-		if (netbk->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
 			struct xen_netif_extra_info *gso =
 				(struct xen_netif_extra_info *)
 				RING_GET_RESPONSE(&vif->rx,
@@ -594,7 +590,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 			resp->flags |= XEN_NETRXF_extra_info;
 
-			gso->u.gso.size = netbk->meta[npo.meta_cons].gso_size;
+			gso->u.gso.size = m[npo.meta_cons].gso_size;
 			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
 			gso->u.gso.pad = 0;
 			gso->u.gso.features = 0;
@@ -604,7 +600,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 		}
 
 		netbk_add_frag_responses(vif, status,
-					 netbk->meta + npo.meta_cons + 1,
+					 m + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
@@ -622,6 +618,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
+
+	put_cpu_ptr(gco);
+	put_cpu_ptr(m);
 }
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
@@ -1053,9 +1052,10 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
+static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+					struct gnttab_copy *tco)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
+	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
 	struct xenvif *vif = netbk->vif;
@@ -1215,17 +1215,18 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
+		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
 	}
 
-	return gop - netbk->tx_copy_ops;
+	return gop - tco;
 }
 
 static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				struct gnttab_copy *tco,
 				int *work_done, int budget)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops;
+	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
 	struct xenvif *vif = netbk->vif;
 
@@ -1306,19 +1307,25 @@ void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
+	struct gnttab_copy *tco;
 
 	if (unlikely(!tx_work_todo(netbk)))
 		return;
 
-	nr_gops = xen_netbk_tx_build_gops(netbk);
+	tco = get_cpu_ptr(tx_copy_ops);
 
-	if (nr_gops == 0)
-		return;
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
-					netbk->tx_copy_ops, nr_gops);
+	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+
+	if (nr_gops == 0) {
+		put_cpu_ptr(tco);
+		return 0;
+	}
+
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, work_done, budget);
+	xen_netbk_tx_submit(netbk, tco, work_done, budget);
+	put_cpu_ptr(tco);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
@@ -1504,17 +1511,47 @@ int xen_netbk_kthread(void *data)
 
 static int __init netback_init(void)
 {
-	int rc = 0;
+	int rc = -ENOMEM;
 
 	if (!xen_domain())
 		return -ENODEV;
 
+	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
+				     * MAX_PENDING_REQS,
+				     __alignof__(struct gnttab_copy));
+	if (!tx_copy_ops)
+		goto failed_init;
+
+	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
+				       * 2 * XEN_NETIF_RX_RING_SIZE,
+				       __alignof__(struct gnttab_copy));
+	if (!grant_copy_op)
+		goto failed_init_gco;
+
+	meta = __alloc_percpu(sizeof(struct netbk_rx_meta)
+			      * 2 * XEN_NETIF_RX_RING_SIZE,
+			      __alignof__(struct netbk_rx_meta));
+	if (!meta)
+		goto failed_init_meta;
+
 	rc = page_pool_init();
 	if (rc)
-		goto failed_init;
+		goto failed_init_pool;
+
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto failed_init_xenbus;
 
-	return xenvif_xenbus_init();
+	return rc;
 
+failed_init_xenbus:
+	page_pool_destroy();
+failed_init_pool:
+	free_percpu(meta);
+failed_init_meta:
+	free_percpu(grant_copy_op);
+failed_init_gco:
+	free_percpu(tx_copy_ops);
 failed_init:
 	return rc;
 
@@ -1526,6 +1563,9 @@ static void __exit netback_exit(void)
 {
 	xenvif_xenbus_exit();
 	page_pool_destroy();
+	free_percpu(meta);
+	free_percpu(grant_copy_op);
+	free_percpu(tx_copy_ops);
 }
 module_exit(netback_exit);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUG-0007FY-0T; Mon, 30 Jan 2012 14:45:40 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUE-0007FR-8u
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:38 +0000
Received: from [85.158.138.51:58088] by server-9.bemta-3.messagelabs.com id
	56/64-31168-11DA62F4; Mon, 30 Jan 2012 14:45:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16414 invoked from network); 30 Jan 2012 14:45:36 -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;
	30 Jan 2012 14:45:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413491"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:33 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTY029057;
	Mon, 30 Jan 2012 06:45:32 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:19 +0000
Message-ID: <1327934734-8908-2-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 01/16] netback: page pool version 1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

A global page pool. Since we are moving to 1:1 model netback, it is
better to limit total RAM consumed by all the vifs.

With this patch, each vif gets page from the pool and puts the page
back when it is finished with the page.

This pool is only meant to access via exported interfaces. Internals
are subject to change when we discover new requirements for the pool.

Current exported interfaces include:

page_pool_init: pool init
page_pool_destroy: pool destruction
page_pool_get: get a page from pool
page_pool_put: put page back to pool
is_in_pool: tell whether a page belongs to the pool

Current implementation has following defects:
 - Global locking
 - No starve prevention mechanism / reservation logic

Global locking tends to cause contention on the pool. No reservation
logic may cause vif to starve. A possible solution to these two
problems will be each vif maintains its local cache and claims a
portion of the pool. However the implementation will be tricky when
coming to pool management, so let's worry about that later.

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile    |    2 +-
 drivers/net/xen-netback/common.h    |    6 +
 drivers/net/xen-netback/netback.c   |  158 ++++++++++++------------------
 drivers/net/xen-netback/page_pool.c |  185 +++++++++++++++++++++++++++++++++++
 drivers/net/xen-netback/page_pool.h |   63 ++++++++++++
 5 files changed, 317 insertions(+), 97 deletions(-)
 create mode 100644 drivers/net/xen-netback/page_pool.c
 create mode 100644 drivers/net/xen-netback/page_pool.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..dc4b8b1 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 94b79c3..288b2f3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,12 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct pending_tx_info {
+	struct xen_netif_tx_request req;
+	struct xenvif *vif;
+};
+typedef unsigned int pending_ring_idx_t;
+
 struct xen_netbk;
 
 struct xenvif {
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 59effac..d11205f 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -33,6 +33,7 @@
  */
 
 #include "common.h"
+#include "page_pool.h"
 
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
@@ -46,12 +47,6 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct pending_tx_info {
-	struct xen_netif_tx_request req;
-	struct xenvif *vif;
-};
-typedef unsigned int pending_ring_idx_t;
-
 struct netbk_rx_meta {
 	int id;
 	int size;
@@ -65,21 +60,6 @@ struct netbk_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-/* extra field used in struct page */
-union page_ext {
-	struct {
-#if BITS_PER_LONG < 64
-#define IDX_WIDTH   8
-#define GROUP_WIDTH (BITS_PER_LONG - IDX_WIDTH)
-		unsigned int group:GROUP_WIDTH;
-		unsigned int idx:IDX_WIDTH;
-#else
-		unsigned int group, idx;
-#endif
-	} e;
-	void *mapping;
-};
-
 struct xen_netbk {
 	wait_queue_head_t wq;
 	struct task_struct *task;
@@ -89,7 +69,7 @@ struct xen_netbk {
 
 	struct timer_list net_timer;
 
-	struct page *mmap_pages[MAX_PENDING_REQS];
+	idx_t mmap_pages[MAX_PENDING_REQS];
 
 	pending_ring_idx_t pending_prod;
 	pending_ring_idx_t pending_cons;
@@ -100,7 +80,6 @@ struct xen_netbk {
 
 	atomic_t netfront_count;
 
-	struct pending_tx_info pending_tx_info[MAX_PENDING_REQS];
 	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
 
 	u16 pending_ring[MAX_PENDING_REQS];
@@ -160,7 +139,7 @@ static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
 static inline unsigned long idx_to_pfn(struct xen_netbk *netbk,
 				       u16 idx)
 {
-	return page_to_pfn(netbk->mmap_pages[idx]);
+	return page_to_pfn(to_page(netbk->mmap_pages[idx]));
 }
 
 static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
@@ -169,45 +148,6 @@ static inline unsigned long idx_to_kaddr(struct xen_netbk *netbk,
 	return (unsigned long)pfn_to_kaddr(idx_to_pfn(netbk, idx));
 }
 
-/* extra field used in struct page */
-static inline void set_page_ext(struct page *pg, struct xen_netbk *netbk,
-				unsigned int idx)
-{
-	unsigned int group = netbk - xen_netbk;
-	union page_ext ext = { .e = { .group = group + 1, .idx = idx } };
-
-	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
-	pg->mapping = ext.mapping;
-}
-
-static int get_page_ext(struct page *pg,
-			unsigned int *pgroup, unsigned int *pidx)
-{
-	union page_ext ext = { .mapping = pg->mapping };
-	struct xen_netbk *netbk;
-	unsigned int group, idx;
-
-	group = ext.e.group - 1;
-
-	if (group < 0 || group >= xen_netbk_group_nr)
-		return 0;
-
-	netbk = &xen_netbk[group];
-
-	idx = ext.e.idx;
-
-	if ((idx < 0) || (idx >= MAX_PENDING_REQS))
-		return 0;
-
-	if (netbk->mmap_pages[idx] != pg)
-		return 0;
-
-	*pgroup = group;
-	*pidx = idx;
-
-	return 1;
-}
-
 /*
  * This is the amount of packet we copy rather than map, so that the
  * guest can't fiddle with the contents of the headers while we do
@@ -398,8 +338,8 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 	 * These variables are used iff get_page_ext returns true,
 	 * in which case they are guaranteed to be initialized.
 	 */
-	unsigned int uninitialized_var(group), uninitialized_var(idx);
-	int foreign = get_page_ext(page, &group, &idx);
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
 	unsigned long bytes;
 
 	/* Data must not cross a page boundary. */
@@ -427,10 +367,7 @@ static void netbk_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
 		copy_gop = npo->copy + npo->copy_prod++;
 		copy_gop->flags = GNTCOPY_dest_gref;
 		if (foreign) {
-			struct xen_netbk *netbk = &xen_netbk[group];
-			struct pending_tx_info *src_pend;
-
-			src_pend = &netbk->pending_tx_info[idx];
+			struct pending_tx_info *src_pend = to_txinfo(idx);
 
 			copy_gop->source.domid = src_pend->vif->domid;
 			copy_gop->source.u.ref = src_pend->req.gref;
@@ -906,11 +843,11 @@ static struct page *xen_netbk_alloc_page(struct xen_netbk *netbk,
 					 u16 pending_idx)
 {
 	struct page *page;
-	page = alloc_page(GFP_KERNEL|__GFP_COLD);
+	int idx;
+	page = page_pool_get(netbk, &idx);
 	if (!page)
 		return NULL;
-	set_page_ext(page, netbk, pending_idx);
-	netbk->mmap_pages[pending_idx] = page;
+	netbk->mmap_pages[pending_idx] = idx;
 	return page;
 }
 
@@ -931,8 +868,8 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 	for (i = start; i < shinfo->nr_frags; i++, txp++) {
 		struct page *page;
 		pending_ring_idx_t index;
-		struct pending_tx_info *pending_tx_info =
-			netbk->pending_tx_info;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		index = pending_index(netbk->pending_cons++);
 		pending_idx = netbk->pending_ring[index];
@@ -940,6 +877,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 		if (!page)
 			return NULL;
 
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
 		gop->source.u.ref = txp->gref;
 		gop->source.domid = vif->domid;
 		gop->source.offset = txp->offset;
@@ -953,9 +893,9 @@ static struct gnttab_copy *xen_netbk_get_requests(struct xen_netbk *netbk,
 
 		gop++;
 
-		memcpy(&pending_tx_info[pending_idx].req, txp, sizeof(*txp));
+		memcpy(&pending_tx_info->req, txp, sizeof(*txp));
 		xenvif_get(vif);
-		pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		frag_set_pending_idx(&frags[i], pending_idx);
 	}
 
@@ -968,8 +908,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 {
 	struct gnttab_copy *gop = *gopp;
 	u16 pending_idx = *((u16 *)skb->data);
-	struct pending_tx_info *pending_tx_info = netbk->pending_tx_info;
-	struct xenvif *vif = pending_tx_info[pending_idx].vif;
+	struct pending_tx_info *pending_tx_info;
+	int idx;
+	struct xenvif *vif = NULL;
 	struct xen_netif_tx_request *txp;
 	struct skb_shared_info *shinfo = skb_shinfo(skb);
 	int nr_frags = shinfo->nr_frags;
@@ -980,7 +921,10 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 	if (unlikely(err)) {
 		pending_ring_idx_t index;
 		index = pending_index(netbk->pending_prod++);
-		txp = &pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[index];
+		pending_tx_info = to_txinfo(idx);
+		txp = &pending_tx_info->req;
+		vif = pending_tx_info->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		netbk->pending_ring[index] = pending_idx;
 		xenvif_put(vif);
@@ -1005,7 +949,9 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
 		}
 
 		/* Error on this fragment: respond to client with an error. */
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		txp = &to_txinfo(idx)->req;
+		vif = to_txinfo(idx)->vif;
 		make_tx_response(vif, txp, XEN_NETIF_RSP_ERROR);
 		index = pending_index(netbk->pending_prod++);
 		netbk->pending_ring[index] = pending_idx;
@@ -1042,10 +988,15 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		struct xen_netif_tx_request *txp;
 		struct page *page;
 		u16 pending_idx;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = frag_get_pending_idx(frag);
 
-		txp = &netbk->pending_tx_info[pending_idx].req;
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		txp = &pending_tx_info->req;
 		page = virt_to_page(idx_to_kaddr(netbk, pending_idx));
 		__skb_fill_page_desc(skb, i, page, txp->offset, txp->size);
 		skb->len += txp->size;
@@ -1053,7 +1004,7 @@ static void xen_netbk_fill_frags(struct xen_netbk *netbk, struct sk_buff *skb)
 		skb->truesize += txp->size;
 
 		/* Take an extra reference to offset xen_netbk_idx_release */
-		get_page(netbk->mmap_pages[pending_idx]);
+		get_page(page);
 		xen_netbk_idx_release(netbk, pending_idx);
 	}
 }
@@ -1233,6 +1184,8 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		int work_to_do;
 		unsigned int data_len;
 		pending_ring_idx_t index;
+		int pool_idx;
+		struct pending_tx_info *pending_tx_info;
 
 		/* Get a netif from the list with work to do. */
 		vif = poll_net_schedule_list(netbk);
@@ -1347,9 +1300,12 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 
 		gop++;
 
-		memcpy(&netbk->pending_tx_info[pending_idx].req,
+		pool_idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(pool_idx);
+
+		memcpy(&pending_tx_info->req,
 		       &txreq, sizeof(txreq));
-		netbk->pending_tx_info[pending_idx].vif = vif;
+		pending_tx_info->vif = vif;
 		*((u16 *)skb->data) = pending_idx;
 
 		__skb_put(skb, data_len);
@@ -1397,10 +1353,16 @@ static void xen_netbk_tx_submit(struct xen_netbk *netbk)
 		struct xenvif *vif;
 		u16 pending_idx;
 		unsigned data_len;
+		int idx;
+		struct pending_tx_info *pending_tx_info;
 
 		pending_idx = *((u16 *)skb->data);
-		vif = netbk->pending_tx_info[pending_idx].vif;
-		txp = &netbk->pending_tx_info[pending_idx].req;
+
+		idx = netbk->mmap_pages[pending_idx];
+		pending_tx_info = to_txinfo(idx);
+
+		vif = pending_tx_info->vif;
+		txp = &pending_tx_info->req;
 
 		/* Check the remap error code. */
 		if (unlikely(xen_netbk_tx_check_gop(netbk, skb, &gop))) {
@@ -1480,12 +1442,14 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 	struct xenvif *vif;
 	struct pending_tx_info *pending_tx_info;
 	pending_ring_idx_t index;
+	int idx;
 
 	/* Already complete? */
-	if (netbk->mmap_pages[pending_idx] == NULL)
+	if (netbk->mmap_pages[pending_idx] == INVALID_ENTRY)
 		return;
 
-	pending_tx_info = &netbk->pending_tx_info[pending_idx];
+	idx = netbk->mmap_pages[pending_idx];
+	pending_tx_info = to_txinfo(idx);
 
 	vif = pending_tx_info->vif;
 
@@ -1496,9 +1460,9 @@ static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
 
 	xenvif_put(vif);
 
-	netbk->mmap_pages[pending_idx]->mapping = 0;
-	put_page(netbk->mmap_pages[pending_idx]);
-	netbk->mmap_pages[pending_idx] = NULL;
+	page_pool_put(netbk->mmap_pages[pending_idx]);
+
+	netbk->mmap_pages[pending_idx] = INVALID_ENTRY;
 }
 
 static void make_tx_response(struct xenvif *vif,
@@ -1681,19 +1645,21 @@ static int __init netback_init(void)
 		wake_up_process(netbk->task);
 	}
 
-	rc = xenvif_xenbus_init();
+	rc = page_pool_init();
 	if (rc)
 		goto failed_init;
 
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto pool_failed_init;
+
 	return 0;
 
+pool_failed_init:
+	page_pool_destroy();
 failed_init:
 	while (--group >= 0) {
 		struct xen_netbk *netbk = &xen_netbk[group];
-		for (i = 0; i < MAX_PENDING_REQS; i++) {
-			if (netbk->mmap_pages[i])
-				__free_page(netbk->mmap_pages[i]);
-		}
 		del_timer(&netbk->net_timer);
 		kthread_stop(netbk->task);
 	}
diff --git a/drivers/net/xen-netback/page_pool.c b/drivers/net/xen-netback/page_pool.c
new file mode 100644
index 0000000..294f48b
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.c
@@ -0,0 +1,185 @@
+/*
+ * Global page pool for netback.
+ *
+ * Wei Liu <wei.liu2@citrix.com>
+ * Copyright (c) Citrix Systems
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "common.h"
+#include "page_pool.h"
+#include <asm/xen/page.h>
+
+static idx_t free_head;
+static int free_count;
+static unsigned long pool_size;
+static DEFINE_SPINLOCK(pool_lock);
+static struct page_pool_entry *pool;
+
+static int get_free_entry(void)
+{
+	int idx;
+
+	spin_lock(&pool_lock);
+
+	if (free_count == 0) {
+		spin_unlock(&pool_lock);
+		return -ENOSPC;
+	}
+
+	idx = free_head;
+	free_count--;
+	free_head = pool[idx].u.fl;
+	pool[idx].u.fl = INVALID_ENTRY;
+
+	spin_unlock(&pool_lock);
+
+	return idx;
+}
+
+static void put_free_entry(idx_t idx)
+{
+	spin_lock(&pool_lock);
+
+	pool[idx].u.fl = free_head;
+	free_head = idx;
+	free_count++;
+
+	spin_unlock(&pool_lock);
+}
+
+static inline void set_page_ext(struct page *pg, unsigned int idx)
+{
+	union page_ext ext = { .idx = idx };
+
+	BUILD_BUG_ON(sizeof(ext) > sizeof(ext.mapping));
+	pg->mapping = ext.mapping;
+}
+
+static int get_page_ext(struct page *pg, unsigned int *pidx)
+{
+	union page_ext ext = { .mapping = pg->mapping };
+	int idx;
+
+	idx = ext.idx;
+
+	if ((idx < 0) || (idx >= pool_size))
+		return 0;
+
+	if (pool[idx].page != pg)
+		return 0;
+
+	*pidx = idx;
+
+	return 1;
+}
+
+int is_in_pool(struct page *page, int *pidx)
+{
+	return get_page_ext(page, pidx);
+}
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx)
+{
+	int idx;
+	struct page *page;
+
+	idx = get_free_entry();
+	if (idx < 0)
+		return NULL;
+	page = alloc_page(GFP_ATOMIC);
+
+	if (page == NULL) {
+		put_free_entry(idx);
+		return NULL;
+	}
+
+	set_page_ext(page, idx);
+	pool[idx].u.netbk = netbk;
+	pool[idx].page = page;
+
+	*pidx = idx;
+
+	return page;
+}
+
+void page_pool_put(int idx)
+{
+	struct page *page = pool[idx].page;
+
+	pool[idx].page = NULL;
+	pool[idx].u.netbk = NULL;
+	page->mapping = 0;
+	put_page(page);
+	put_free_entry(idx);
+}
+
+int page_pool_init()
+{
+	int cpus = 0;
+	int i;
+
+	cpus = num_online_cpus();
+	pool_size = cpus * ENTRIES_PER_CPU;
+
+	pool = vzalloc(sizeof(struct page_pool_entry) * pool_size);
+
+	if (!pool)
+		return -ENOMEM;
+
+	for (i = 0; i < pool_size - 1; i++)
+		pool[i].u.fl = i+1;
+	pool[pool_size-1].u.fl = INVALID_ENTRY;
+	free_count = pool_size;
+	free_head = 0;
+
+	return 0;
+}
+
+void page_pool_destroy()
+{
+	int i;
+	for (i = 0; i < pool_size; i++)
+		if (pool[i].page)
+			put_page(pool[i].page);
+
+	vfree(pool);
+}
+
+struct page *to_page(int idx)
+{
+	return pool[idx].page;
+}
+
+struct xen_netbk *to_netbk(int idx)
+{
+	return pool[idx].u.netbk;
+}
+
+struct pending_tx_info *to_txinfo(int idx)
+{
+	return &pool[idx].tx_info;
+}
diff --git a/drivers/net/xen-netback/page_pool.h b/drivers/net/xen-netback/page_pool.h
new file mode 100644
index 0000000..572b037
--- /dev/null
+++ b/drivers/net/xen-netback/page_pool.h
@@ -0,0 +1,63 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __PAGE_POOL_H__
+#define __PAGE_POOL_H__
+
+#include "common.h"
+
+typedef uint32_t idx_t;
+
+#define ENTRIES_PER_CPU (1024)
+#define INVALID_ENTRY 0xffffffff
+
+struct page_pool_entry {
+	struct page *page;
+	struct pending_tx_info tx_info;
+	union {
+		struct xen_netbk *netbk;
+		idx_t             fl;
+	} u;
+};
+
+union page_ext {
+	idx_t idx;
+	void *mapping;
+};
+
+int  page_pool_init(void);
+void page_pool_destroy(void);
+
+
+struct page *page_pool_get(struct xen_netbk *netbk, int *pidx);
+void         page_pool_put(int idx);
+int          is_in_pool(struct page *page, int *pidx);
+
+struct page            *to_page(int idx);
+struct xen_netbk       *to_netbk(int idx);
+struct pending_tx_info *to_txinfo(int idx);
+
+#endif /* __PAGE_POOL_H__ */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUJ-0007GK-KP; Mon, 30 Jan 2012 14:45:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUG-0007FX-CV
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:40 +0000
Received: from [85.158.138.51:58278] by server-6.bemta-3.messagelabs.com id
	3F/D5-31032-31DA62F4; Mon, 30 Jan 2012 14:45:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327934734!11265011!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16546 invoked from network); 30 Jan 2012 14:45:38 -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;
	30 Jan 2012 14:45:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413495"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:37 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTb029057;
	Mon, 30 Jan 2012 06:45:36 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:22 +0000
Message-ID: <1327934734-8908-5-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 04/16] netback: switch to per-cpu scratch
	space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

In the 1:1 model, given that there are maximum nr_online_cpus netbacks
running, we can use per-cpu scratch space, thus shrinking size of
struct xen_netbk.

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h  |   13 ++++
 drivers/net/xen-netback/netback.c |  134 ++++++++++++++++++++++++-------------
 2 files changed, 100 insertions(+), 47 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 31c331c..3b85563 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -45,6 +45,19 @@
 #include <xen/grant_table.h>
 #include <xen/xenbus.h>
 
+struct netbk_rx_meta {
+	int id;
+	int size;
+	int gso_size;
+};
+
+#define MAX_PENDING_REQS 256
+
+/* Discriminate from any valid pending_idx value. */
+#define INVALID_PENDING_IDX 0xFFFF
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
 struct pending_tx_info {
 	struct xen_netif_tx_request req;
 };
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 9a72993..1c68afb 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1,3 +1,4 @@
+
 /*
  * Back-end of the driver for virtual network devices. This portion of the
  * driver exports a 'unified' network-device interface that can be accessed
@@ -47,18 +48,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
-struct netbk_rx_meta {
-	int id;
-	int size;
-	int gso_size;
-};
 
-#define MAX_PENDING_REQS 256
+struct gnttab_copy *tx_copy_ops;
 
-/* Discriminate from any valid pending_idx value. */
-#define INVALID_PENDING_IDX 0xFFFF
+/*
+ * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
+ * head/fragment page uses 2 copy operations because it
+ * straddles two buffers in the frontend.
+ */
+struct gnttab_copy *grant_copy_op;
+struct netbk_rx_meta *meta;
 
-#define MAX_BUFFER_OFFSET PAGE_SIZE
 
 struct xen_netbk {
 	struct sk_buff_head rx_queue;
@@ -71,17 +71,7 @@ struct xen_netbk {
 
 	struct xenvif *vif;
 
-	struct gnttab_copy tx_copy_ops[MAX_PENDING_REQS];
-
 	u16 pending_ring[MAX_PENDING_REQS];
-
-	/*
-	 * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
-	 * head/fragment page uses 2 copy operations because it
-	 * straddles two buffers in the frontend.
-	 */
-	struct gnttab_copy grant_copy_op[2*XEN_NETIF_RX_RING_SIZE];
-	struct netbk_rx_meta meta[2*XEN_NETIF_RX_RING_SIZE];
 };
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx);
@@ -509,9 +499,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
 
+	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
+	struct netbk_rx_meta *m = get_cpu_ptr(meta);
+
 	struct netrx_pending_operations npo = {
-		.copy  = netbk->grant_copy_op,
-		.meta  = netbk->meta,
+		.copy  = gco,
+		.meta  = m,
 	};
 
 	skb_queue_head_init(&rxq);
@@ -534,13 +527,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			break;
 	}
 
-	BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
+	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
 
-	if (!npo.copy_prod)
+	if (!npo.copy_prod) {
+		put_cpu_ptr(gco);
+		put_cpu_ptr(m);
 		return;
+	}
 
-	BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
+	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
 
@@ -549,14 +545,14 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 		vif = netdev_priv(skb->dev);
 
-		if (netbk->meta[npo.meta_cons].gso_size && vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
 			resp = RING_GET_RESPONSE(&vif->rx,
 						vif->rx.rsp_prod_pvt++);
 
 			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
 
-			resp->offset = netbk->meta[npo.meta_cons].gso_size;
-			resp->id = netbk->meta[npo.meta_cons].id;
+			resp->offset = m[npo.meta_cons].gso_size;
+			resp->id = m[npo.meta_cons].id;
 			resp->status = sco->meta_slots_used;
 
 			npo.meta_cons++;
@@ -581,12 +577,12 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 			flags |= XEN_NETRXF_data_validated;
 
 		offset = 0;
-		resp = make_rx_response(vif, netbk->meta[npo.meta_cons].id,
+		resp = make_rx_response(vif, m[npo.meta_cons].id,
 					status, offset,
-					netbk->meta[npo.meta_cons].size,
+					m[npo.meta_cons].size,
 					flags);
 
-		if (netbk->meta[npo.meta_cons].gso_size && !vif->gso_prefix) {
+		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
 			struct xen_netif_extra_info *gso =
 				(struct xen_netif_extra_info *)
 				RING_GET_RESPONSE(&vif->rx,
@@ -594,7 +590,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 			resp->flags |= XEN_NETRXF_extra_info;
 
-			gso->u.gso.size = netbk->meta[npo.meta_cons].gso_size;
+			gso->u.gso.size = m[npo.meta_cons].gso_size;
 			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
 			gso->u.gso.pad = 0;
 			gso->u.gso.features = 0;
@@ -604,7 +600,7 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 		}
 
 		netbk_add_frag_responses(vif, status,
-					 netbk->meta + npo.meta_cons + 1,
+					 m + npo.meta_cons + 1,
 					 sco->meta_slots_used);
 
 		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
@@ -622,6 +618,9 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
 
 	if (!skb_queue_empty(&netbk->rx_queue))
 		xen_netbk_kick_thread(netbk);
+
+	put_cpu_ptr(gco);
+	put_cpu_ptr(m);
 }
 
 void xen_netbk_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
@@ -1053,9 +1052,10 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
 	return false;
 }
 
-static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
+static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk,
+					struct gnttab_copy *tco)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops, *request_gop;
+	struct gnttab_copy *gop = tco, *request_gop;
 	struct sk_buff *skb;
 	int ret;
 	struct xenvif *vif = netbk->vif;
@@ -1215,17 +1215,18 @@ static unsigned xen_netbk_tx_build_gops(struct xen_netbk *netbk)
 		vif->tx.req_cons = idx;
 		xen_netbk_check_rx_xenvif(vif);
 
-		if ((gop-netbk->tx_copy_ops) >= ARRAY_SIZE(netbk->tx_copy_ops))
+		if ((gop - tco) >= MAX_PENDING_REQS)
 			break;
 	}
 
-	return gop - netbk->tx_copy_ops;
+	return gop - tco;
 }
 
 static void xen_netbk_tx_submit(struct xen_netbk *netbk,
+				struct gnttab_copy *tco,
 				int *work_done, int budget)
 {
-	struct gnttab_copy *gop = netbk->tx_copy_ops;
+	struct gnttab_copy *gop = tco;
 	struct sk_buff *skb;
 	struct xenvif *vif = netbk->vif;
 
@@ -1306,19 +1307,25 @@ void xen_netbk_tx_action(struct xen_netbk *netbk, int *work_done, int budget)
 {
 	unsigned nr_gops;
 	int ret;
+	struct gnttab_copy *tco;
 
 	if (unlikely(!tx_work_todo(netbk)))
 		return;
 
-	nr_gops = xen_netbk_tx_build_gops(netbk);
+	tco = get_cpu_ptr(tx_copy_ops);
 
-	if (nr_gops == 0)
-		return;
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy,
-					netbk->tx_copy_ops, nr_gops);
+	nr_gops = xen_netbk_tx_build_gops(netbk, tco);
+
+	if (nr_gops == 0) {
+		put_cpu_ptr(tco);
+		return 0;
+	}
+
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, tco, nr_gops);
 	BUG_ON(ret);
 
-	xen_netbk_tx_submit(netbk, work_done, budget);
+	xen_netbk_tx_submit(netbk, tco, work_done, budget);
+	put_cpu_ptr(tco);
 }
 
 static void xen_netbk_idx_release(struct xen_netbk *netbk, u16 pending_idx)
@@ -1504,17 +1511,47 @@ int xen_netbk_kthread(void *data)
 
 static int __init netback_init(void)
 {
-	int rc = 0;
+	int rc = -ENOMEM;
 
 	if (!xen_domain())
 		return -ENODEV;
 
+	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
+				     * MAX_PENDING_REQS,
+				     __alignof__(struct gnttab_copy));
+	if (!tx_copy_ops)
+		goto failed_init;
+
+	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
+				       * 2 * XEN_NETIF_RX_RING_SIZE,
+				       __alignof__(struct gnttab_copy));
+	if (!grant_copy_op)
+		goto failed_init_gco;
+
+	meta = __alloc_percpu(sizeof(struct netbk_rx_meta)
+			      * 2 * XEN_NETIF_RX_RING_SIZE,
+			      __alignof__(struct netbk_rx_meta));
+	if (!meta)
+		goto failed_init_meta;
+
 	rc = page_pool_init();
 	if (rc)
-		goto failed_init;
+		goto failed_init_pool;
+
+	rc = xenvif_xenbus_init();
+	if (rc)
+		goto failed_init_xenbus;
 
-	return xenvif_xenbus_init();
+	return rc;
 
+failed_init_xenbus:
+	page_pool_destroy();
+failed_init_pool:
+	free_percpu(meta);
+failed_init_meta:
+	free_percpu(grant_copy_op);
+failed_init_gco:
+	free_percpu(tx_copy_ops);
 failed_init:
 	return rc;
 
@@ -1526,6 +1563,9 @@ static void __exit netback_exit(void)
 {
 	xenvif_xenbus_exit();
 	page_pool_destroy();
+	free_percpu(meta);
+	free_percpu(grant_copy_op);
+	free_percpu(tx_copy_ops);
 }
 module_exit(netback_exit);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUT-0007NM-SL; Mon, 30 Jan 2012 14:45:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUR-0007HR-Ii
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32403 invoked from network); 30 Jan 2012 14:45:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614385"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:44 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTg029057;
	Mon, 30 Jan 2012 06:45:43 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:27 +0000
Message-ID: <1327934734-8908-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 09/16] netback: nuke xenvif_receive_skb
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 it with direct call to netif_receive_skb.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |    2 --
 drivers/net/xen-netback/interface.c |    5 -----
 drivers/net/xen-netback/netback.c   |    2 +-
 3 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 53141c7..28121f1 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -152,8 +152,6 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_check_rx_xenvif(struct xenvif *vif);
-/* Receive an SKB from the frontend */
-void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
 void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index fe37143..d7a7cd9 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -117,11 +117,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	return NETDEV_TX_OK;
 }
 
-void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
-{
-	netif_receive_skb(skb);
-}
-
 void xenvif_notify_tx_completion(struct xenvif *vif)
 {
 	if (netif_queue_stopped(vif->dev) && xenvif_rx_schedulable(vif))
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 065cd65..a8d58a9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1270,7 +1270,7 @@ static int xenvif_tx_submit(struct xenvif *vif,
 
 		work_done++;
 
-		xenvif_receive_skb(vif, skb);
+		netif_receive_skb(skb);
 	}
 
 	return work_done;
-- 
1.7.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 Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUV-0007OI-Ab; Mon, 30 Jan 2012 14:45:55 +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 1RrsUT-0007J4-M5
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327934746!12887947!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27050 invoked from network); 30 Jan 2012 14:45:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413501"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:45 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTh029057;
	Mon, 30 Jan 2012 06:45:44 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:28 +0000
Message-ID: <1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu scratch
	space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If we allocate large arrays in per-cpu section, multi-page ring
feature is likely to blow up the per-cpu section. So avoid allocating
large arrays, instead we only store pointers to scratch spaces in
per-cpu section.

CPU hotplug event is also taken care of.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |  140 +++++++++++++++++++++++++++----------
 1 files changed, 104 insertions(+), 36 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index a8d58a9..2ac9b84 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -39,6 +39,7 @@
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
 #include <linux/udp.h>
+#include <linux/cpu.h>
 
 #include <net/tcp.h>
 
@@ -49,15 +50,15 @@
 #include <asm/xen/page.h>
 
 
-struct gnttab_copy *tx_copy_ops;
+DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 
 /*
  * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
  * head/fragment page uses 2 copy operations because it
  * straddles two buffers in the frontend.
  */
-struct gnttab_copy *grant_copy_op;
-struct xenvif_rx_meta *meta;
+DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
+DEFINE_PER_CPU(struct xenvif_rx_meta *, meta);
 
 static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
@@ -481,8 +482,8 @@ void xenvif_rx_action(struct xenvif *vif)
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
 
-	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
-	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
+	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
+	struct xenvif_rx_meta *m = get_cpu_var(meta);
 
 	struct netrx_pending_operations npo = {
 		.copy  = gco,
@@ -512,8 +513,8 @@ void xenvif_rx_action(struct xenvif *vif)
 	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
 
 	if (!npo.copy_prod) {
-		put_cpu_ptr(gco);
-		put_cpu_ptr(m);
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
 		return;
 	}
 
@@ -599,8 +600,8 @@ void xenvif_rx_action(struct xenvif *vif)
 	if (!skb_queue_empty(&vif->rx_queue))
 		xenvif_kick_thread(vif);
 
-	put_cpu_ptr(gco);
-	put_cpu_ptr(m);
+	put_cpu_var(grant_copy_op);
+	put_cpu_var(meta);
 }
 
 void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
@@ -1287,12 +1288,12 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
 	if (unlikely(!tx_work_todo(vif)))
 		return 0;
 
-	tco = get_cpu_ptr(tx_copy_ops);
+	tco = get_cpu_var(tx_copy_ops);
 
 	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
-		put_cpu_ptr(tco);
+		put_cpu_var(tx_copy_ops);
 		return 0;
 	}
 
@@ -1301,7 +1302,7 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
 
 	work_done = xenvif_tx_submit(vif, tco, budget);
 
-	put_cpu_ptr(tco);
+	put_cpu_var(tx_copy_ops);
 
 	return work_done;
 }
@@ -1452,31 +1453,97 @@ int xenvif_kthread(void *data)
 	return 0;
 }
 
+static int __create_percpu_scratch_space(unsigned int cpu)
+{
+	per_cpu(tx_copy_ops, cpu) =
+		vzalloc(sizeof(struct gnttab_copy) * MAX_PENDING_REQS);
+
+	per_cpu(grant_copy_op, cpu) =
+		vzalloc(sizeof(struct gnttab_copy)
+			* 2 * XEN_NETIF_RX_RING_SIZE);
+
+	per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
+				     * 2 * XEN_NETIF_RX_RING_SIZE);
+
+	if (!per_cpu(tx_copy_ops, cpu) ||
+	    !per_cpu(grant_copy_op, cpu) ||
+	    !per_cpu(meta, cpu))
+		return -ENOMEM;
+
+	return 0;
+}
+
+static void __free_percpu_scratch_space(unsigned int cpu)
+{
+	/* freeing NULL pointer is legit */
+	vfree(per_cpu(tx_copy_ops, cpu));
+	vfree(per_cpu(grant_copy_op, cpu));
+	vfree(per_cpu(meta, cpu));
+}
+
+static int __netback_percpu_callback(struct notifier_block *nfb,
+				     unsigned long action, void *hcpu)
+{
+	unsigned int cpu = (unsigned long)hcpu;
+	int rc = NOTIFY_DONE;
+
+	switch (action) {
+	case CPU_ONLINE:
+	case CPU_ONLINE_FROZEN:
+		printk(KERN_INFO
+		       "netback: CPU %x online, creating scratch space\n", cpu);
+		rc = __create_percpu_scratch_space(cpu);
+		if (rc) {
+			printk(KERN_ALERT
+			       "netback: failed to create scratch space for CPU"
+			       " %x\n", cpu);
+			/* FIXME: nothing more we can do here, we will
+			 * print out warning message when thread or
+			 * NAPI runs on this cpu. Also stop getting
+			 * called in the future.
+			 */
+			__free_percpu_scratch_space(cpu);
+			rc = NOTIFY_BAD;
+		} else {
+			rc = NOTIFY_OK;
+		}
+		break;
+	case CPU_DEAD:
+	case CPU_DEAD_FROZEN:
+		printk("netback: CPU %x offline, destroying scratch space\n",
+		       cpu);
+		__free_percpu_scratch_space(cpu);
+		rc = NOTIFY_OK;
+		break;
+	default:
+		break;
+	}
+
+	return rc;
+}
+
+static struct notifier_block netback_notifier_block = {
+	.notifier_call = __netback_percpu_callback,
+};
 
 static int __init netback_init(void)
 {
 	int rc = -ENOMEM;
+	int cpu;
 
 	if (!xen_domain())
 		return -ENODEV;
 
-	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
-				     * MAX_PENDING_REQS,
-				     __alignof__(struct gnttab_copy));
-	if (!tx_copy_ops)
-		goto failed_init;
+	/* Don't need to disable preempt here, since nobody else will
+	 * touch these percpu areas during start up. */
+	for_each_online_cpu(cpu) {
+		rc = __create_percpu_scratch_space(cpu);
 
-	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
-				       * 2 * XEN_NETIF_RX_RING_SIZE,
-				       __alignof__(struct gnttab_copy));
-	if (!grant_copy_op)
-		goto failed_init_gco;
+		if (rc)
+			goto failed_init;
+	}
 
-	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
-			      * 2 * XEN_NETIF_RX_RING_SIZE,
-			      __alignof__(struct xenvif_rx_meta));
-	if (!meta)
-		goto failed_init_meta;
+	register_hotcpu_notifier(&netback_notifier_block);
 
 	rc = page_pool_init();
 	if (rc)
@@ -1491,25 +1558,26 @@ static int __init netback_init(void)
 failed_init_xenbus:
 	page_pool_destroy();
 failed_init_pool:
-	free_percpu(meta);
-failed_init_meta:
-	free_percpu(grant_copy_op);
-failed_init_gco:
-	free_percpu(tx_copy_ops);
+	for_each_online_cpu(cpu)
+		__free_percpu_scratch_space(cpu);
 failed_init:
 	return rc;
-
 }
 
 module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
+	int cpu;
+
 	xenvif_xenbus_exit();
 	page_pool_destroy();
-	free_percpu(meta);
-	free_percpu(grant_copy_op);
-	free_percpu(tx_copy_ops);
+
+	unregister_hotcpu_notifier(&netback_notifier_block);
+
+	/* Since we're here, nobody else will touch per-cpu area. */
+	for_each_online_cpu(cpu)
+		__free_percpu_scratch_space(cpu);
 }
 module_exit(netback_exit);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUT-0007NM-SL; Mon, 30 Jan 2012 14:45:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RrsUR-0007HR-Ii
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!5
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32403 invoked from network); 30 Jan 2012 14:45:44 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614385"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:44 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTg029057;
	Mon, 30 Jan 2012 06:45:43 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:27 +0000
Message-ID: <1327934734-8908-10-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 09/16] netback: nuke xenvif_receive_skb
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 it with direct call to netif_receive_skb.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |    2 --
 drivers/net/xen-netback/interface.c |    5 -----
 drivers/net/xen-netback/netback.c   |    2 +-
 3 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 53141c7..28121f1 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -152,8 +152,6 @@ int xenvif_map_frontend_rings(struct xenvif *vif,
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_check_rx_xenvif(struct xenvif *vif);
-/* Receive an SKB from the frontend */
-void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb);
 
 /* Queue an SKB for transmission to the frontend */
 void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index fe37143..d7a7cd9 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -117,11 +117,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	return NETDEV_TX_OK;
 }
 
-void xenvif_receive_skb(struct xenvif *vif, struct sk_buff *skb)
-{
-	netif_receive_skb(skb);
-}
-
 void xenvif_notify_tx_completion(struct xenvif *vif)
 {
 	if (netif_queue_stopped(vif->dev) && xenvif_rx_schedulable(vif))
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 065cd65..a8d58a9 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1270,7 +1270,7 @@ static int xenvif_tx_submit(struct xenvif *vif,
 
 		work_done++;
 
-		xenvif_receive_skb(vif, skb);
+		netif_receive_skb(skb);
 	}
 
 	return work_done;
-- 
1.7.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 Jan 30 14:45:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:45:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUV-0007OI-Ab; Mon, 30 Jan 2012 14:45:55 +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 1RrsUT-0007J4-M5
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327934746!12887947!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27050 invoked from network); 30 Jan 2012 14:45:47 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413501"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:45 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTh029057;
	Mon, 30 Jan 2012 06:45:44 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:28 +0000
Message-ID: <1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu scratch
	space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If we allocate large arrays in per-cpu section, multi-page ring
feature is likely to blow up the per-cpu section. So avoid allocating
large arrays, instead we only store pointers to scratch spaces in
per-cpu section.

CPU hotplug event is also taken care of.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/netback.c |  140 +++++++++++++++++++++++++++----------
 1 files changed, 104 insertions(+), 36 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index a8d58a9..2ac9b84 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -39,6 +39,7 @@
 #include <linux/kthread.h>
 #include <linux/if_vlan.h>
 #include <linux/udp.h>
+#include <linux/cpu.h>
 
 #include <net/tcp.h>
 
@@ -49,15 +50,15 @@
 #include <asm/xen/page.h>
 
 
-struct gnttab_copy *tx_copy_ops;
+DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 
 /*
  * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
  * head/fragment page uses 2 copy operations because it
  * straddles two buffers in the frontend.
  */
-struct gnttab_copy *grant_copy_op;
-struct xenvif_rx_meta *meta;
+DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
+DEFINE_PER_CPU(struct xenvif_rx_meta *, meta);
 
 static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
 static void make_tx_response(struct xenvif *vif,
@@ -481,8 +482,8 @@ void xenvif_rx_action(struct xenvif *vif)
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
 
-	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
-	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
+	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
+	struct xenvif_rx_meta *m = get_cpu_var(meta);
 
 	struct netrx_pending_operations npo = {
 		.copy  = gco,
@@ -512,8 +513,8 @@ void xenvif_rx_action(struct xenvif *vif)
 	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
 
 	if (!npo.copy_prod) {
-		put_cpu_ptr(gco);
-		put_cpu_ptr(m);
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
 		return;
 	}
 
@@ -599,8 +600,8 @@ void xenvif_rx_action(struct xenvif *vif)
 	if (!skb_queue_empty(&vif->rx_queue))
 		xenvif_kick_thread(vif);
 
-	put_cpu_ptr(gco);
-	put_cpu_ptr(m);
+	put_cpu_var(grant_copy_op);
+	put_cpu_var(meta);
 }
 
 void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
@@ -1287,12 +1288,12 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
 	if (unlikely(!tx_work_todo(vif)))
 		return 0;
 
-	tco = get_cpu_ptr(tx_copy_ops);
+	tco = get_cpu_var(tx_copy_ops);
 
 	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 0) {
-		put_cpu_ptr(tco);
+		put_cpu_var(tx_copy_ops);
 		return 0;
 	}
 
@@ -1301,7 +1302,7 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
 
 	work_done = xenvif_tx_submit(vif, tco, budget);
 
-	put_cpu_ptr(tco);
+	put_cpu_var(tx_copy_ops);
 
 	return work_done;
 }
@@ -1452,31 +1453,97 @@ int xenvif_kthread(void *data)
 	return 0;
 }
 
+static int __create_percpu_scratch_space(unsigned int cpu)
+{
+	per_cpu(tx_copy_ops, cpu) =
+		vzalloc(sizeof(struct gnttab_copy) * MAX_PENDING_REQS);
+
+	per_cpu(grant_copy_op, cpu) =
+		vzalloc(sizeof(struct gnttab_copy)
+			* 2 * XEN_NETIF_RX_RING_SIZE);
+
+	per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
+				     * 2 * XEN_NETIF_RX_RING_SIZE);
+
+	if (!per_cpu(tx_copy_ops, cpu) ||
+	    !per_cpu(grant_copy_op, cpu) ||
+	    !per_cpu(meta, cpu))
+		return -ENOMEM;
+
+	return 0;
+}
+
+static void __free_percpu_scratch_space(unsigned int cpu)
+{
+	/* freeing NULL pointer is legit */
+	vfree(per_cpu(tx_copy_ops, cpu));
+	vfree(per_cpu(grant_copy_op, cpu));
+	vfree(per_cpu(meta, cpu));
+}
+
+static int __netback_percpu_callback(struct notifier_block *nfb,
+				     unsigned long action, void *hcpu)
+{
+	unsigned int cpu = (unsigned long)hcpu;
+	int rc = NOTIFY_DONE;
+
+	switch (action) {
+	case CPU_ONLINE:
+	case CPU_ONLINE_FROZEN:
+		printk(KERN_INFO
+		       "netback: CPU %x online, creating scratch space\n", cpu);
+		rc = __create_percpu_scratch_space(cpu);
+		if (rc) {
+			printk(KERN_ALERT
+			       "netback: failed to create scratch space for CPU"
+			       " %x\n", cpu);
+			/* FIXME: nothing more we can do here, we will
+			 * print out warning message when thread or
+			 * NAPI runs on this cpu. Also stop getting
+			 * called in the future.
+			 */
+			__free_percpu_scratch_space(cpu);
+			rc = NOTIFY_BAD;
+		} else {
+			rc = NOTIFY_OK;
+		}
+		break;
+	case CPU_DEAD:
+	case CPU_DEAD_FROZEN:
+		printk("netback: CPU %x offline, destroying scratch space\n",
+		       cpu);
+		__free_percpu_scratch_space(cpu);
+		rc = NOTIFY_OK;
+		break;
+	default:
+		break;
+	}
+
+	return rc;
+}
+
+static struct notifier_block netback_notifier_block = {
+	.notifier_call = __netback_percpu_callback,
+};
 
 static int __init netback_init(void)
 {
 	int rc = -ENOMEM;
+	int cpu;
 
 	if (!xen_domain())
 		return -ENODEV;
 
-	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
-				     * MAX_PENDING_REQS,
-				     __alignof__(struct gnttab_copy));
-	if (!tx_copy_ops)
-		goto failed_init;
+	/* Don't need to disable preempt here, since nobody else will
+	 * touch these percpu areas during start up. */
+	for_each_online_cpu(cpu) {
+		rc = __create_percpu_scratch_space(cpu);
 
-	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
-				       * 2 * XEN_NETIF_RX_RING_SIZE,
-				       __alignof__(struct gnttab_copy));
-	if (!grant_copy_op)
-		goto failed_init_gco;
+		if (rc)
+			goto failed_init;
+	}
 
-	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
-			      * 2 * XEN_NETIF_RX_RING_SIZE,
-			      __alignof__(struct xenvif_rx_meta));
-	if (!meta)
-		goto failed_init_meta;
+	register_hotcpu_notifier(&netback_notifier_block);
 
 	rc = page_pool_init();
 	if (rc)
@@ -1491,25 +1558,26 @@ static int __init netback_init(void)
 failed_init_xenbus:
 	page_pool_destroy();
 failed_init_pool:
-	free_percpu(meta);
-failed_init_meta:
-	free_percpu(grant_copy_op);
-failed_init_gco:
-	free_percpu(tx_copy_ops);
+	for_each_online_cpu(cpu)
+		__free_percpu_scratch_space(cpu);
 failed_init:
 	return rc;
-
 }
 
 module_init(netback_init);
 
 static void __exit netback_exit(void)
 {
+	int cpu;
+
 	xenvif_xenbus_exit();
 	page_pool_destroy();
-	free_percpu(meta);
-	free_percpu(grant_copy_op);
-	free_percpu(tx_copy_ops);
+
+	unregister_hotcpu_notifier(&netback_notifier_block);
+
+	/* Since we're here, nobody else will touch per-cpu area. */
+	for_each_online_cpu(cpu)
+		__free_percpu_scratch_space(cpu);
 }
 module_exit(netback_exit);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:46:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUY-0007Sc-EP; Mon, 30 Jan 2012 14:45:58 +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 1RrsUV-0007Km-Rt
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32697 invoked from network); 30 Jan 2012 14:45:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614399"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:48 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTj029057;
	Mon, 30 Jan 2012 06:45:46 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:30 +0000
Message-ID: <1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Extend netback to support multi-page ring.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   44 ++++++++++---
 drivers/net/xen-netback/interface.c |   33 +++++++--
 drivers/net/xen-netback/netback.c   |  116 +++++++++++++++++++++----------
 drivers/net/xen-netback/xenbus.c    |  129 +++++++++++++++++++++++++++++++++--
 4 files changed, 262 insertions(+), 60 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 28121f1..3cf9b8f 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -58,16 +58,36 @@ struct xenvif_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
+#define NETBK_TX_RING_SIZE(_nr_pages)					\
+	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages)))
+#define NETBK_RX_RING_SIZE(_nr_pages)					\
+	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages)))
 
-#define MAX_PENDING_REQS 256
+#define NETBK_MAX_RING_PAGE_ORDER 2
+#define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
+
+#define NETBK_MAX_TX_RING_SIZE NETBK_TX_RING_SIZE(NETBK_MAX_RING_PAGES)
+#define NETBK_MAX_RX_RING_SIZE NETBK_RX_RING_SIZE(NETBK_MAX_RING_PAGES)
+
+#define INVALID_GRANT_HANDLE ((grant_handle_t)~0U)
+
+#define MAX_PENDING_REQS NETBK_MAX_TX_RING_SIZE
+
+struct xen_comms {
+	struct vm_struct *ring_area;
+	grant_handle_t    shmem_handle[NETBK_MAX_RING_PAGES];
+	unsigned int      nr_handles;
+};
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
+	/* Multi-page ring support */
+	struct xen_comms tx_comms;
+	struct xen_comms rx_comms;
+
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -131,8 +151,10 @@ struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn);
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
+		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
+		   unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -145,10 +167,11 @@ int xenvif_rx_ring_full(struct xenvif *vif);
 int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xenvif_unmap_frontend_rings(struct xenvif *vif);
-int xenvif_map_frontend_rings(struct xenvif *vif,
-			      grant_ref_t tx_ring_ref,
-			      grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xen_comms *comms);
+int xenvif_map_frontend_rings(struct xen_comms *comms,
+			      int domid,
+			      unsigned long ring_ref[],
+			      unsigned int  ring_ref_count);
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_check_rx_xenvif(struct xenvif *vif);
@@ -166,4 +189,7 @@ void xenvif_rx_action(struct xenvif *vif);
 
 int xenvif_kthread(void *data);
 
+extern unsigned int MODPARM_netback_max_tx_ring_page_order;
+extern unsigned int MODPARM_netback_max_rx_ring_page_order;
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index a5de556..29f4fd9 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -322,10 +322,14 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	return vif;
 }
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn)
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
+		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
+		   unsigned int evtchn)
 {
 	int err = -ENOMEM;
+	struct xen_netif_tx_sring *txs;
+	struct xen_netif_rx_sring *rxs;
 
 	/* Already connected through? */
 	if (vif->irq)
@@ -333,15 +337,25 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
-	if (err < 0)
+	err = xenvif_map_frontend_rings(&vif->tx_comms, vif->domid,
+					tx_ring_ref, tx_ring_ref_count);
+	if (err)
 		goto err;
+	txs = (struct xen_netif_tx_sring *)vif->tx_comms.ring_area->addr;
+	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE * tx_ring_ref_count);
+
+	err = xenvif_map_frontend_rings(&vif->rx_comms, vif->domid,
+					rx_ring_ref, rx_ring_ref_count);
+	if (err)
+		goto err_tx_unmap;
+	rxs = (struct xen_netif_rx_sring *)vif->rx_comms.ring_area->addr;
+	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
 
 	err = bind_interdomain_evtchn_to_irqhandler(
 		vif->domid, evtchn, xenvif_interrupt, 0,
 		vif->dev->name, vif);
 	if (err < 0)
-		goto err_unmap;
+		goto err_rx_unmap;
 	vif->irq = err;
 	disable_irq(vif->irq);
 
@@ -369,8 +383,10 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	return 0;
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
-err_unmap:
-	xenvif_unmap_frontend_rings(vif);
+err_rx_unmap:
+	xenvif_unmap_frontend_rings(&vif->rx_comms);
+err_tx_unmap:
+	xenvif_unmap_frontend_rings(&vif->tx_comms);
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -403,7 +419,8 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xenvif_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(&vif->tx_comms);
+	xenvif_unmap_frontend_rings(&vif->rx_comms);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index df63703..96f354c 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -49,6 +49,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
+unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_rx_ring_page_order,
+		   MODPARM_netback_max_rx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_rx_ring_page_order,
+		 "Maximum supported receiver ring page order");
+
+unsigned int MODPARM_netback_max_tx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_tx_ring_page_order,
+		   MODPARM_netback_max_tx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_tx_ring_page_order,
+		 "Maximum supported transmitter ring page order");
 
 DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 
@@ -132,9 +143,11 @@ int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
+	struct xen_comms *comms = &vif->rx_comms;
 
 	return ((vif->rx.sring->req_prod - peek) < needed) ||
-	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
+	       ((vif->rx.rsp_prod_pvt +
+		 NETBK_RX_RING_SIZE(comms->nr_handles) - peek) < needed);
 }
 
 int xenvif_must_stop_queue(struct xenvif *vif)
@@ -481,6 +494,7 @@ void xenvif_rx_action(struct xenvif *vif)
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
+	struct xen_comms *comms = &vif->rx_comms;
 
 	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
 	struct xenvif_rx_meta *m = get_cpu_var(meta);
@@ -515,7 +529,8 @@ void xenvif_rx_action(struct xenvif *vif)
 		__skb_queue_tail(&rxq, skb);
 
 		/* Filled the batch queue? */
-		if (count + MAX_SKB_FRAGS >= XEN_NETIF_RX_RING_SIZE)
+		if (count + MAX_SKB_FRAGS >=
+		    NETBK_RX_RING_SIZE(comms->nr_handles))
 			break;
 	}
 
@@ -527,7 +542,7 @@ void xenvif_rx_action(struct xenvif *vif)
 		return;
 	}
 
-	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	BUG_ON(npo.copy_prod > (2 * NETBK_MAX_RX_RING_SIZE));
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
@@ -1405,48 +1420,77 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xenvif_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xen_comms *comms)
 {
-	if (vif->tx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->tx.sring);
-	if (vif->rx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->rx.sring);
+	struct gnttab_unmap_grant_ref op[NETBK_MAX_RING_PAGES];
+	unsigned int i;
+	unsigned int j;
+
+	if (!comms->ring_area)
+		return;
+
+	j = 0;
+	for (i = 0; i < comms->nr_handles; i++) {
+		unsigned long addr = (unsigned long)comms->ring_area->addr +
+			(i * PAGE_SIZE);
+
+		if (comms->shmem_handle[i] != INVALID_GRANT_HANDLE) {
+			gnttab_set_unmap_op(&op[j++], addr,
+					    GNTMAP_host_map,
+					    comms->shmem_handle[i]);
+			comms->shmem_handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
+
+	comms->nr_handles = 0;
+
+	if (j != 0) {
+		if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+					      op, j))
+			BUG();
+	}
+
+	free_vm_area(comms->ring_area);
 }
 
-int xenvif_map_frontend_rings(struct xenvif *vif,
-			      grant_ref_t tx_ring_ref,
-			      grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xen_comms *comms,
+			      int domid,
+			      unsigned long ring_ref[],
+			      unsigned int  ring_ref_count)
 {
-	void *addr;
-	struct xen_netif_tx_sring *txs;
-	struct xen_netif_rx_sring *rxs;
-
-	int err = -ENOMEM;
+	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
+	unsigned int i;
+	int err = 0;
 
-	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     tx_ring_ref, &addr);
-	if (err)
-		goto err;
+	comms->ring_area = alloc_vm_area(PAGE_SIZE * ring_ref_count, NULL);
+	if (comms->ring_area == NULL)
+		return -ENOMEM;
 
-	txs = (struct xen_netif_tx_sring *)addr;
-	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
+	for (i = 0; i < ring_ref_count; i++) {
+		unsigned long addr = (unsigned long)comms->ring_area->addr +
+			(i * PAGE_SIZE);
+		gnttab_set_map_op(&op[i], addr, GNTMAP_host_map,
+				  ring_ref[i], domid);
+	}
 
-	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     rx_ring_ref, &addr);
-	if (err)
-		goto err;
+	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
+				      &op, ring_ref_count))
+		BUG();
 
-	rxs = (struct xen_netif_rx_sring *)addr;
-	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE);
+	comms->nr_handles = ring_ref_count;
 
-	vif->rx_req_cons_peek = 0;
+	for (i = 0; i < ring_ref_count; i++) {
+		if (op[i].status != 0) {
+			err = op[i].status;
+			comms->shmem_handle[i] = INVALID_GRANT_HANDLE;
+			continue;
+		}
+		comms->shmem_handle[i] = op[i].handle;
+	}
 
-	return 0;
+	if (err != 0)
+		xenvif_unmap_frontend_rings(comms);
 
-err:
-	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
@@ -1477,10 +1521,10 @@ static int __create_percpu_scratch_space(unsigned int cpu)
 
 	per_cpu(grant_copy_op, cpu) =
 		vzalloc(sizeof(struct gnttab_copy)
-			* 2 * XEN_NETIF_RX_RING_SIZE);
+			* 2 * NETBK_MAX_RX_RING_SIZE);
 
 	per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
-				     * 2 * XEN_NETIF_RX_RING_SIZE);
+				     * 2 * NETBK_MAX_RX_RING_SIZE);
 
 	if (!per_cpu(tx_copy_ops, cpu) ||
 	    !per_cpu(grant_copy_op, cpu) ||
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index f1e89ca..79499fc 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -113,6 +113,23 @@ static int netback_probe(struct xenbus_device *dev,
 			message = "writing feature-rx-flip";
 			goto abort_transaction;
 		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-tx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_tx_ring_page_order);
+		if (err) {
+			message = "writing max-tx-ring-page-order";
+			goto abort_transaction;
+		}
+
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-rx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_rx_ring_page_order);
+		if (err) {
+			message = "writing max-rx-ring-page-order";
+			goto abort_transaction;
+		}
 
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
@@ -391,22 +408,108 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned long tx_ring_ref, rx_ring_ref;
 	unsigned int evtchn, rx_copy;
 	int err;
 	int val;
+	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned int  tx_ring_order;
+	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "tx-ring-ref", "%lu", &tx_ring_ref,
-			    "rx-ring-ref", "%lu", &rx_ring_ref,
 			    "event-channel", "%u", &evtchn, NULL);
 	if (err) {
 		xenbus_dev_fatal(dev, err,
-				 "reading %s/ring-ref and event-channel",
+				 "reading %s/event-channel",
 				 dev->otherend);
 		return err;
 	}
 
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
+			   &tx_ring_order);
+	if (err < 0) {
+		tx_ring_order = 0;
+
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-ref", "%lu",
+				   &tx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/tx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (tx_ring_order > MODPARM_netback_max_tx_ring_page_order) {
+			err = -EINVAL;
+
+			xenbus_dev_fatal(dev, err,
+					 "%s/tx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << tx_ring_order); i++) {
+			char ring_ref_name[sizeof("tx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "tx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &tx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-order", "%u",
+			   &rx_ring_order);
+	if (err < 0) {
+		rx_ring_order = 0;
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-ref", "%lu",
+				   &rx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/rx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (rx_ring_order > MODPARM_netback_max_rx_ring_page_order) {
+			err = -EINVAL;
+
+			xenbus_dev_fatal(dev, err,
+					 "%s/rx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << rx_ring_order); i++) {
+			char ring_ref_name[sizeof("rx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "rx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &rx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
 			   &rx_copy);
 	if (err == -ENOENT) {
@@ -453,11 +556,23 @@ static int connect_rings(struct backend_info *be)
 	vif->csum = !val;
 
 	/* Map the shared frame, irq etc. */
-	err = xenvif_connect(vif, tx_ring_ref, rx_ring_ref, evtchn);
+	err = xenvif_connect(vif,
+			     tx_ring_ref, (1U << tx_ring_order),
+			     rx_ring_ref, (1U << rx_ring_order),
+			     evtchn);
 	if (err) {
+		int i;
 		xenbus_dev_fatal(dev, err,
-				 "mapping shared-frames %lu/%lu port %u",
-				 tx_ring_ref, rx_ring_ref, evtchn);
+				 "binding port %u",
+				 evtchn);
+		for (i = 0; i < (1U << tx_ring_order); i++)
+			xenbus_dev_fatal(dev, err,
+					 "mapping tx ring handle: %lu",
+					 tx_ring_ref[i]);
+		for (i = 0; i < (1U << rx_ring_order); i++)
+			xenbus_dev_fatal(dev, err,
+					 "mapping rx ring handle: %lu",
+					 tx_ring_ref[i]);
 		return err;
 	}
 	return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:46:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUY-0007Sc-EP; Mon, 30 Jan 2012 14:45:58 +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 1RrsUV-0007Km-Rt
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:56 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!7
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32697 invoked from network); 30 Jan 2012 14:45:49 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614399"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:48 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTj029057;
	Mon, 30 Jan 2012 06:45:46 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:30 +0000
Message-ID: <1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Extend netback to support multi-page ring.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h    |   44 ++++++++++---
 drivers/net/xen-netback/interface.c |   33 +++++++--
 drivers/net/xen-netback/netback.c   |  116 +++++++++++++++++++++----------
 drivers/net/xen-netback/xenbus.c    |  129 +++++++++++++++++++++++++++++++++--
 4 files changed, 262 insertions(+), 60 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 28121f1..3cf9b8f 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -58,16 +58,36 @@ struct xenvif_rx_meta {
 
 #define MAX_BUFFER_OFFSET PAGE_SIZE
 
-#define XEN_NETIF_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define XEN_NETIF_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
+#define NETBK_TX_RING_SIZE(_nr_pages)					\
+	(__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages)))
+#define NETBK_RX_RING_SIZE(_nr_pages)					\
+	(__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages)))
 
-#define MAX_PENDING_REQS 256
+#define NETBK_MAX_RING_PAGE_ORDER 2
+#define NETBK_MAX_RING_PAGES      (1U << NETBK_MAX_RING_PAGE_ORDER)
+
+#define NETBK_MAX_TX_RING_SIZE NETBK_TX_RING_SIZE(NETBK_MAX_RING_PAGES)
+#define NETBK_MAX_RX_RING_SIZE NETBK_RX_RING_SIZE(NETBK_MAX_RING_PAGES)
+
+#define INVALID_GRANT_HANDLE ((grant_handle_t)~0U)
+
+#define MAX_PENDING_REQS NETBK_MAX_TX_RING_SIZE
+
+struct xen_comms {
+	struct vm_struct *ring_area;
+	grant_handle_t    shmem_handle[NETBK_MAX_RING_PAGES];
+	unsigned int      nr_handles;
+};
 
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
 	unsigned int     handle;
 
+	/* Multi-page ring support */
+	struct xen_comms tx_comms;
+	struct xen_comms rx_comms;
+
 	/* Use NAPI for guest TX */
 	struct napi_struct napi;
 	/* Use kthread for guest RX */
@@ -131,8 +151,10 @@ struct xenvif *xenvif_alloc(struct device *parent,
 			    domid_t domid,
 			    unsigned int handle);
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn);
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
+		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
+		   unsigned int evtchn);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -145,10 +167,11 @@ int xenvif_rx_ring_full(struct xenvif *vif);
 int xenvif_must_stop_queue(struct xenvif *vif);
 
 /* (Un)Map communication rings. */
-void xenvif_unmap_frontend_rings(struct xenvif *vif);
-int xenvif_map_frontend_rings(struct xenvif *vif,
-			      grant_ref_t tx_ring_ref,
-			      grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_rings(struct xen_comms *comms);
+int xenvif_map_frontend_rings(struct xen_comms *comms,
+			      int domid,
+			      unsigned long ring_ref[],
+			      unsigned int  ring_ref_count);
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_check_rx_xenvif(struct xenvif *vif);
@@ -166,4 +189,7 @@ void xenvif_rx_action(struct xenvif *vif);
 
 int xenvif_kthread(void *data);
 
+extern unsigned int MODPARM_netback_max_tx_ring_page_order;
+extern unsigned int MODPARM_netback_max_rx_ring_page_order;
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index a5de556..29f4fd9 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -322,10 +322,14 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 	return vif;
 }
 
-int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
-		   unsigned long rx_ring_ref, unsigned int evtchn)
+int xenvif_connect(struct xenvif *vif,
+		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
+		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
+		   unsigned int evtchn)
 {
 	int err = -ENOMEM;
+	struct xen_netif_tx_sring *txs;
+	struct xen_netif_rx_sring *rxs;
 
 	/* Already connected through? */
 	if (vif->irq)
@@ -333,15 +337,25 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 
 	__module_get(THIS_MODULE);
 
-	err = xenvif_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
-	if (err < 0)
+	err = xenvif_map_frontend_rings(&vif->tx_comms, vif->domid,
+					tx_ring_ref, tx_ring_ref_count);
+	if (err)
 		goto err;
+	txs = (struct xen_netif_tx_sring *)vif->tx_comms.ring_area->addr;
+	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE * tx_ring_ref_count);
+
+	err = xenvif_map_frontend_rings(&vif->rx_comms, vif->domid,
+					rx_ring_ref, rx_ring_ref_count);
+	if (err)
+		goto err_tx_unmap;
+	rxs = (struct xen_netif_rx_sring *)vif->rx_comms.ring_area->addr;
+	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
 
 	err = bind_interdomain_evtchn_to_irqhandler(
 		vif->domid, evtchn, xenvif_interrupt, 0,
 		vif->dev->name, vif);
 	if (err < 0)
-		goto err_unmap;
+		goto err_rx_unmap;
 	vif->irq = err;
 	disable_irq(vif->irq);
 
@@ -369,8 +383,10 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
 	return 0;
 err_unbind:
 	unbind_from_irqhandler(vif->irq, vif);
-err_unmap:
-	xenvif_unmap_frontend_rings(vif);
+err_rx_unmap:
+	xenvif_unmap_frontend_rings(&vif->rx_comms);
+err_tx_unmap:
+	xenvif_unmap_frontend_rings(&vif->tx_comms);
 err:
 	module_put(THIS_MODULE);
 	return err;
@@ -403,7 +419,8 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	unregister_netdev(vif->dev);
 
-	xenvif_unmap_frontend_rings(vif);
+	xenvif_unmap_frontend_rings(&vif->tx_comms);
+	xenvif_unmap_frontend_rings(&vif->rx_comms);
 
 	free_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index df63703..96f354c 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -49,6 +49,17 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
+unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_rx_ring_page_order,
+		   MODPARM_netback_max_rx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_rx_ring_page_order,
+		 "Maximum supported receiver ring page order");
+
+unsigned int MODPARM_netback_max_tx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
+module_param_named(netback_max_tx_ring_page_order,
+		   MODPARM_netback_max_tx_ring_page_order, uint, 0);
+MODULE_PARM_DESC(netback_max_tx_ring_page_order,
+		 "Maximum supported transmitter ring page order");
 
 DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
 
@@ -132,9 +143,11 @@ int xenvif_rx_ring_full(struct xenvif *vif)
 {
 	RING_IDX peek   = vif->rx_req_cons_peek;
 	RING_IDX needed = max_required_rx_slots(vif);
+	struct xen_comms *comms = &vif->rx_comms;
 
 	return ((vif->rx.sring->req_prod - peek) < needed) ||
-	       ((vif->rx.rsp_prod_pvt + XEN_NETIF_RX_RING_SIZE - peek) < needed);
+	       ((vif->rx.rsp_prod_pvt +
+		 NETBK_RX_RING_SIZE(comms->nr_handles) - peek) < needed);
 }
 
 int xenvif_must_stop_queue(struct xenvif *vif)
@@ -481,6 +494,7 @@ void xenvif_rx_action(struct xenvif *vif)
 	unsigned long offset;
 	struct skb_cb_overlay *sco;
 	int need_to_notify = 0;
+	struct xen_comms *comms = &vif->rx_comms;
 
 	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
 	struct xenvif_rx_meta *m = get_cpu_var(meta);
@@ -515,7 +529,8 @@ void xenvif_rx_action(struct xenvif *vif)
 		__skb_queue_tail(&rxq, skb);
 
 		/* Filled the batch queue? */
-		if (count + MAX_SKB_FRAGS >= XEN_NETIF_RX_RING_SIZE)
+		if (count + MAX_SKB_FRAGS >=
+		    NETBK_RX_RING_SIZE(comms->nr_handles))
 			break;
 	}
 
@@ -527,7 +542,7 @@ void xenvif_rx_action(struct xenvif *vif)
 		return;
 	}
 
-	BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
+	BUG_ON(npo.copy_prod > (2 * NETBK_MAX_RX_RING_SIZE));
 	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
 					npo.copy_prod);
 	BUG_ON(ret != 0);
@@ -1405,48 +1420,77 @@ static inline int tx_work_todo(struct xenvif *vif)
 	return 0;
 }
 
-void xenvif_unmap_frontend_rings(struct xenvif *vif)
+void xenvif_unmap_frontend_rings(struct xen_comms *comms)
 {
-	if (vif->tx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->tx.sring);
-	if (vif->rx.sring)
-		xenbus_unmap_ring_vfree(xenvif_to_xenbus_device(vif),
-					vif->rx.sring);
+	struct gnttab_unmap_grant_ref op[NETBK_MAX_RING_PAGES];
+	unsigned int i;
+	unsigned int j;
+
+	if (!comms->ring_area)
+		return;
+
+	j = 0;
+	for (i = 0; i < comms->nr_handles; i++) {
+		unsigned long addr = (unsigned long)comms->ring_area->addr +
+			(i * PAGE_SIZE);
+
+		if (comms->shmem_handle[i] != INVALID_GRANT_HANDLE) {
+			gnttab_set_unmap_op(&op[j++], addr,
+					    GNTMAP_host_map,
+					    comms->shmem_handle[i]);
+			comms->shmem_handle[i] = INVALID_GRANT_HANDLE;
+		}
+	}
+
+	comms->nr_handles = 0;
+
+	if (j != 0) {
+		if (HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+					      op, j))
+			BUG();
+	}
+
+	free_vm_area(comms->ring_area);
 }
 
-int xenvif_map_frontend_rings(struct xenvif *vif,
-			      grant_ref_t tx_ring_ref,
-			      grant_ref_t rx_ring_ref)
+int xenvif_map_frontend_rings(struct xen_comms *comms,
+			      int domid,
+			      unsigned long ring_ref[],
+			      unsigned int  ring_ref_count)
 {
-	void *addr;
-	struct xen_netif_tx_sring *txs;
-	struct xen_netif_rx_sring *rxs;
-
-	int err = -ENOMEM;
+	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
+	unsigned int i;
+	int err = 0;
 
-	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     tx_ring_ref, &addr);
-	if (err)
-		goto err;
+	comms->ring_area = alloc_vm_area(PAGE_SIZE * ring_ref_count, NULL);
+	if (comms->ring_area == NULL)
+		return -ENOMEM;
 
-	txs = (struct xen_netif_tx_sring *)addr;
-	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
+	for (i = 0; i < ring_ref_count; i++) {
+		unsigned long addr = (unsigned long)comms->ring_area->addr +
+			(i * PAGE_SIZE);
+		gnttab_set_map_op(&op[i], addr, GNTMAP_host_map,
+				  ring_ref[i], domid);
+	}
 
-	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
-				     rx_ring_ref, &addr);
-	if (err)
-		goto err;
+	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
+				      &op, ring_ref_count))
+		BUG();
 
-	rxs = (struct xen_netif_rx_sring *)addr;
-	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE);
+	comms->nr_handles = ring_ref_count;
 
-	vif->rx_req_cons_peek = 0;
+	for (i = 0; i < ring_ref_count; i++) {
+		if (op[i].status != 0) {
+			err = op[i].status;
+			comms->shmem_handle[i] = INVALID_GRANT_HANDLE;
+			continue;
+		}
+		comms->shmem_handle[i] = op[i].handle;
+	}
 
-	return 0;
+	if (err != 0)
+		xenvif_unmap_frontend_rings(comms);
 
-err:
-	xenvif_unmap_frontend_rings(vif);
 	return err;
 }
 
@@ -1477,10 +1521,10 @@ static int __create_percpu_scratch_space(unsigned int cpu)
 
 	per_cpu(grant_copy_op, cpu) =
 		vzalloc(sizeof(struct gnttab_copy)
-			* 2 * XEN_NETIF_RX_RING_SIZE);
+			* 2 * NETBK_MAX_RX_RING_SIZE);
 
 	per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
-				     * 2 * XEN_NETIF_RX_RING_SIZE);
+				     * 2 * NETBK_MAX_RX_RING_SIZE);
 
 	if (!per_cpu(tx_copy_ops, cpu) ||
 	    !per_cpu(grant_copy_op, cpu) ||
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index f1e89ca..79499fc 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -113,6 +113,23 @@ static int netback_probe(struct xenbus_device *dev,
 			message = "writing feature-rx-flip";
 			goto abort_transaction;
 		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-tx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_tx_ring_page_order);
+		if (err) {
+			message = "writing max-tx-ring-page-order";
+			goto abort_transaction;
+		}
+
+		err = xenbus_printf(xbt, dev->nodename,
+				    "max-rx-ring-page-order",
+				    "%u",
+				    MODPARM_netback_max_rx_ring_page_order);
+		if (err) {
+			message = "writing max-rx-ring-page-order";
+			goto abort_transaction;
+		}
 
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
@@ -391,22 +408,108 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned long tx_ring_ref, rx_ring_ref;
 	unsigned int evtchn, rx_copy;
 	int err;
 	int val;
+	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
+	unsigned int  tx_ring_order;
+	unsigned int  rx_ring_order;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "tx-ring-ref", "%lu", &tx_ring_ref,
-			    "rx-ring-ref", "%lu", &rx_ring_ref,
 			    "event-channel", "%u", &evtchn, NULL);
 	if (err) {
 		xenbus_dev_fatal(dev, err,
-				 "reading %s/ring-ref and event-channel",
+				 "reading %s/event-channel",
 				 dev->otherend);
 		return err;
 	}
 
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
+			   &tx_ring_order);
+	if (err < 0) {
+		tx_ring_order = 0;
+
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-ref", "%lu",
+				   &tx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/tx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (tx_ring_order > MODPARM_netback_max_tx_ring_page_order) {
+			err = -EINVAL;
+
+			xenbus_dev_fatal(dev, err,
+					 "%s/tx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << tx_ring_order); i++) {
+			char ring_ref_name[sizeof("tx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "tx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &tx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-order", "%u",
+			   &rx_ring_order);
+	if (err < 0) {
+		rx_ring_order = 0;
+		err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-ring-ref", "%lu",
+				   &rx_ring_ref[0]);
+		if (err < 0) {
+			xenbus_dev_fatal(dev, err, "reading %s/rx-ring-ref",
+					 dev->otherend);
+			return err;
+		}
+	} else {
+		unsigned int i;
+
+		if (rx_ring_order > MODPARM_netback_max_rx_ring_page_order) {
+			err = -EINVAL;
+
+			xenbus_dev_fatal(dev, err,
+					 "%s/rx-ring-page-order too big",
+					 dev->otherend);
+			return err;
+		}
+
+		for (i = 0; i < (1U << rx_ring_order); i++) {
+			char ring_ref_name[sizeof("rx-ring-ref") + 2];
+
+			snprintf(ring_ref_name, sizeof(ring_ref_name),
+				 "rx-ring-ref%u", i);
+
+			err = xenbus_scanf(XBT_NIL, dev->otherend,
+					   ring_ref_name, "%lu",
+					   &rx_ring_ref[i]);
+			if (err < 0) {
+				xenbus_dev_fatal(dev, err,
+						 "reading %s/%s",
+						 dev->otherend,
+						 ring_ref_name);
+				return err;
+			}
+		}
+	}
+
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
 			   &rx_copy);
 	if (err == -ENOENT) {
@@ -453,11 +556,23 @@ static int connect_rings(struct backend_info *be)
 	vif->csum = !val;
 
 	/* Map the shared frame, irq etc. */
-	err = xenvif_connect(vif, tx_ring_ref, rx_ring_ref, evtchn);
+	err = xenvif_connect(vif,
+			     tx_ring_ref, (1U << tx_ring_order),
+			     rx_ring_ref, (1U << rx_ring_order),
+			     evtchn);
 	if (err) {
+		int i;
 		xenbus_dev_fatal(dev, err,
-				 "mapping shared-frames %lu/%lu port %u",
-				 tx_ring_ref, rx_ring_ref, evtchn);
+				 "binding port %u",
+				 evtchn);
+		for (i = 0; i < (1U << tx_ring_order); i++)
+			xenbus_dev_fatal(dev, err,
+					 "mapping tx ring handle: %lu",
+					 tx_ring_ref[i]);
+		for (i = 0; i < (1U << rx_ring_order); i++)
+			xenbus_dev_fatal(dev, err,
+					 "mapping rx ring handle: %lu",
+					 tx_ring_ref[i]);
 		return err;
 	}
 	return 0;
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:46:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUV-0007Oc-NE; Mon, 30 Jan 2012 14:45:55 +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 1RrsUT-0007JH-QN
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32597 invoked from network); 30 Jan 2012 14:45:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614395"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:46 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTi029057;
	Mon, 30 Jan 2012 06:45:45 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:29 +0000
Message-ID: <1327934734-8908-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 11/16] netback: print alert and bail when
	scratch space is not 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

CPU online event causes our callback to allocate scratch space for
this CPU, which may fail. The simplest and best action when NAPI or
kthread is scheduled on that CPU is to bail.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    5 ++++-
 drivers/net/xen-netback/netback.c   |   17 +++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index d7a7cd9..a5de556 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -69,6 +69,9 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
+	/* N.B.: work_done may be -ENOMEM, indicating scratch space on
+	 * this CPU is not usable. In this situation, we shutdown
+	 * NAPI. See __napi_complete check below.*/
 	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
@@ -78,7 +81,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 		local_irq_save(flag);
 
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
-		if (!more_to_do)
+		if (!more_to_do || work_done < 0)
 			__napi_complete(napi);
 
 		local_irq_restore(flag);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2ac9b84..df63703 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -490,6 +490,15 @@ void xenvif_rx_action(struct xenvif *vif)
 		.meta  = m,
 	};
 
+	if (gco == NULL || m == NULL) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
+		printk(KERN_ALERT "netback: CPU %x scratch space is not usable,"
+		       " not doing any TX work for vif%u.%u\n",
+		       smp_processor_id(), vif->domid, vif->handle);
+		return;
+	}
+
 	skb_queue_head_init(&rxq);
 
 	count = 0;
@@ -1290,6 +1299,14 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
 
 	tco = get_cpu_var(tx_copy_ops);
 
+	if (tco == NULL) {
+		put_cpu_var(tx_copy_ops);
+		printk(KERN_ALERT "netback: CPU %x scratch space is not usable,"
+		       " not doing any RX work for vif%u.%u\n",
+		       smp_processor_id(), vif->domid, vif->handle);
+		return -ENOMEM;
+	}
+
 	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 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 Mon Jan 30 14:46:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:46:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUV-0007Oc-NE; Mon, 30 Jan 2012 14:45:55 +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 1RrsUT-0007JH-QN
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:54 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!6
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32597 invoked from network); 30 Jan 2012 14:45:47 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614395"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:46 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTi029057;
	Mon, 30 Jan 2012 06:45:45 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:29 +0000
Message-ID: <1327934734-8908-12-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 11/16] netback: print alert and bail when
	scratch space is not 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

CPU online event causes our callback to allocate scratch space for
this CPU, which may fail. The simplest and best action when NAPI or
kthread is scheduled on that CPU is to bail.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/interface.c |    5 ++++-
 drivers/net/xen-netback/netback.c   |   17 +++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index d7a7cd9..a5de556 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -69,6 +69,9 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 	struct xenvif *vif = container_of(napi, struct xenvif, napi);
 	int work_done = 0;
 
+	/* N.B.: work_done may be -ENOMEM, indicating scratch space on
+	 * this CPU is not usable. In this situation, we shutdown
+	 * NAPI. See __napi_complete check below.*/
 	work_done = xenvif_tx_action(vif, budget);
 
 	if (work_done < budget) {
@@ -78,7 +81,7 @@ static int xenvif_poll(struct napi_struct *napi, int budget)
 		local_irq_save(flag);
 
 		RING_FINAL_CHECK_FOR_REQUESTS(&vif->tx, more_to_do);
-		if (!more_to_do)
+		if (!more_to_do || work_done < 0)
 			__napi_complete(napi);
 
 		local_irq_restore(flag);
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2ac9b84..df63703 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -490,6 +490,15 @@ void xenvif_rx_action(struct xenvif *vif)
 		.meta  = m,
 	};
 
+	if (gco == NULL || m == NULL) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
+		printk(KERN_ALERT "netback: CPU %x scratch space is not usable,"
+		       " not doing any TX work for vif%u.%u\n",
+		       smp_processor_id(), vif->domid, vif->handle);
+		return;
+	}
+
 	skb_queue_head_init(&rxq);
 
 	count = 0;
@@ -1290,6 +1299,14 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
 
 	tco = get_cpu_var(tx_copy_ops);
 
+	if (tco == NULL) {
+		put_cpu_var(tx_copy_ops);
+		printk(KERN_ALERT "netback: CPU %x scratch space is not usable,"
+		       " not doing any RX work for vif%u.%u\n",
+		       smp_processor_id(), vif->domid, vif->handle);
+		return -ENOMEM;
+	}
+
 	nr_gops = xenvif_tx_build_gops(vif, tco);
 
 	if (nr_gops == 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 Mon Jan 30 14:46:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUa-0007Vt-Ef; Mon, 30 Jan 2012 14:46:00 +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 1RrsUY-0007MK-2w
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 358 invoked from network); 30 Jan 2012 14:45:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614403"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:49 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTk029057;
	Mon, 30 Jan 2012 06:45:48 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:31 +0000
Message-ID: <1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 13/16] netback: stub for multi receive
	protocol 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

Refactor netback, make stub for mutli receive protocols. Also stub
existing code as protocol 0.

Now the file layout becomes:

 - interface.c: xenvif interfaces
 - xenbus.c: xenbus related functions
 - netback.c: common functions for various protocols

For different protocols:

 - xenvif_rx_protocolX.h: header file for the protocol, including
                          protocol structures and functions
 - xenvif_rx_protocolX.c: implementations

To add a new protocol:

 - include protocol header in common.h
 - modify XENVIF_MAX_RX_PROTOCOL in common.h
 - add protocol structure in xenvif.rx union
 - stub in xenbus.c
 - modify Makefile

A protocol should define five functions:

 - setup: setup frontend / backend ring connections
 - teardown: teardown frontend / backend ring connections
 - start_xmit: host start xmit (i.e. guest need to do rx)
 - event: rx completion event
 - action: prepare host side data for guest rx

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile              |    2 +-
 drivers/net/xen-netback/common.h              |   34 +-
 drivers/net/xen-netback/interface.c           |   49 +-
 drivers/net/xen-netback/netback.c             |  528 +---------------------
 drivers/net/xen-netback/xenbus.c              |    8 +-
 drivers/net/xen-netback/xenvif_rx_protocol0.c |  616 +++++++++++++++++++++++++
 drivers/net/xen-netback/xenvif_rx_protocol0.h |   53 +++
 7 files changed, 732 insertions(+), 558 deletions(-)
 create mode 100644 drivers/net/xen-netback/xenvif_rx_protocol0.c
 create mode 100644 drivers/net/xen-netback/xenvif_rx_protocol0.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index dc4b8b1..fed8add 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o page_pool.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o xenvif_rx_protocol0.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 3cf9b8f..f3d95b3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -46,6 +46,7 @@
 #include <xen/xenbus.h>
 
 #include "page_pool.h"
+#include "xenvif_rx_protocol0.h"
 
 struct xenvif_rx_meta {
 	int id;
@@ -79,6 +80,9 @@ struct xen_comms {
 	unsigned int      nr_handles;
 };
 
+#define XENVIF_MIN_RX_PROTOCOL 0
+#define XENVIF_MAX_RX_PROTOCOL 0
+
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
@@ -99,9 +103,13 @@ struct xenvif {
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* The shared rings and indexes. */
+	/* The shared tx ring and index. */
 	struct xen_netif_tx_back_ring tx;
-	struct xen_netif_rx_back_ring rx;
+
+	/* Multi receive protocol support */
+	union {
+		struct xenvif_rx_protocol0 p0;
+	} rx;
 
 	/* Frontend feature information. */
 	u8 can_sg:1;
@@ -112,13 +120,6 @@ struct xenvif {
 	/* Internal feature information. */
 	u8 can_queue:1;	    /* can queue packets for receiver? */
 
-	/*
-	 * Allow xenvif_start_xmit() to peek ahead in the rx request
-	 * ring.  This is a prediction of what rx_req_cons will be
-	 * once all queued skbs are put on the ring.
-	 */
-	RING_IDX rx_req_cons_peek;
-
 	/* Transmit shaping: allow 'credit_bytes' every 'credit_usec'. */
 	unsigned long   credit_bytes;
 	unsigned long   credit_usec;
@@ -128,6 +129,13 @@ struct xenvif {
 	/* Statistics */
 	unsigned long rx_gso_checksum_fixup;
 
+	/* Hooks for multi receive protocol support */
+	int  (*setup)(struct xenvif *);
+	void (*start_xmit)(struct xenvif *, struct sk_buff *);
+	void (*teardown)(struct xenvif *);
+	void (*event)(struct xenvif *);
+	void (*action)(struct xenvif *);
+
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
 
@@ -154,7 +162,7 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
-		   unsigned int evtchn);
+		   unsigned int evtchn, unsigned int rx_protocol);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -178,8 +186,6 @@ void xenvif_check_rx_xenvif(struct xenvif *vif);
 
 /* Queue an SKB for transmission to the frontend */
 void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
-/* Notify xenvif that ring now has space to send an skb to the frontend */
-void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
@@ -188,7 +194,11 @@ int xenvif_tx_action(struct xenvif *vif, int budget);
 void xenvif_rx_action(struct xenvif *vif);
 
 int xenvif_kthread(void *data);
+void xenvif_kick_thread(struct xenvif *vif);
+
+int xenvif_max_required_rx_slots(struct xenvif *vif);
 
+extern unsigned int MODPARM_netback_max_rx_protocol;
 extern unsigned int MODPARM_netback_max_tx_ring_page_order;
 extern unsigned int MODPARM_netback_max_rx_ring_page_order;
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 29f4fd9..0f05f03 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -46,17 +46,12 @@ int xenvif_schedulable(struct xenvif *vif)
 	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
 }
 
-static int xenvif_rx_schedulable(struct xenvif *vif)
-{
-	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
-}
-
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (xenvif_rx_schedulable(vif))
-		netif_wake_queue(vif->dev);
+	if (xenvif_schedulable(vif) && vif->event != NULL)
+		vif->event(vif);
 
 	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
 		napi_schedule(&vif->napi);
@@ -100,17 +95,11 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	if (vif->task == NULL)
 		goto drop;
 
-	/* Drop the packet if the target domain has no receive buffers. */
-	if (!xenvif_rx_schedulable(vif))
+	/* Drop the packet if vif does not support transmit */
+	if (vif->start_xmit == NULL)
 		goto drop;
 
-	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
-
-	if (vif->can_queue && xenvif_must_stop_queue(vif))
-		netif_stop_queue(dev);
-
-	xenvif_queue_tx_skb(vif, skb);
+	vif->start_xmit(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -120,12 +109,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	return NETDEV_TX_OK;
 }
 
-void xenvif_notify_tx_completion(struct xenvif *vif)
-{
-	if (netif_queue_stopped(vif->dev) && xenvif_rx_schedulable(vif))
-		netif_wake_queue(vif->dev);
-}
-
 static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -325,11 +308,10 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
-		   unsigned int evtchn)
+		   unsigned int evtchn, unsigned int rx_protocol)
 {
 	int err = -ENOMEM;
 	struct xen_netif_tx_sring *txs;
-	struct xen_netif_rx_sring *rxs;
 
 	/* Already connected through? */
 	if (vif->irq)
@@ -348,8 +330,20 @@ int xenvif_connect(struct xenvif *vif,
 					rx_ring_ref, rx_ring_ref_count);
 	if (err)
 		goto err_tx_unmap;
-	rxs = (struct xen_netif_rx_sring *)vif->rx_comms.ring_area->addr;
-	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
+	switch (rx_protocol) {
+	case 0:
+		vif->setup = xenvif_p0_setup;
+		vif->start_xmit = xenvif_p0_start_xmit;
+		vif->teardown = xenvif_p0_teardown;
+		vif->event = xenvif_p0_event;
+		vif->action = xenvif_p0_action;
+		break;
+	default:
+		err = -EOPNOTSUPP;
+		goto err_rx_unmap;
+	}
+	if (vif->setup(vif))
+		goto err_rx_unmap;
 
 	err = bind_interdomain_evtchn_to_irqhandler(
 		vif->domid, evtchn, xenvif_interrupt, 0,
@@ -422,6 +416,9 @@ void xenvif_disconnect(struct xenvif *vif)
 	xenvif_unmap_frontend_rings(&vif->tx_comms);
 	xenvif_unmap_frontend_rings(&vif->rx_comms);
 
+	if (vif->teardown)
+		vif->teardown(vif);
+
 	free_netdev(vif->dev);
 
 	if (need_module_put)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 96f354c..2ea43d4 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -49,6 +49,12 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
+unsigned int MODPARM_netback_max_rx_protocol = XENVIF_MAX_RX_PROTOCOL;
+module_param_named(netback_max_rx_protocol,
+		   MODPARM_netback_max_rx_protocol, uint, 0);
+MODULE_PARM_DESC(netback_max_rx_protocol,
+		 "Maximum supported receiver protocol version");
+
 unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
 module_param_named(netback_max_rx_ring_page_order,
 		   MODPARM_netback_max_rx_ring_page_order, uint, 0);
@@ -79,13 +85,6 @@ static void make_tx_response(struct xenvif *vif,
 static inline int tx_work_todo(struct xenvif *vif);
 static inline int rx_work_todo(struct xenvif *vif);
 
-static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
-					     u16      id,
-					     s8       st,
-					     u16      offset,
-					     u16      size,
-					     u16      flags);
-
 static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
@@ -129,7 +128,7 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 		vif->pending_prod + vif->pending_cons;
 }
 
-static int max_required_rx_slots(struct xenvif *vif)
+int xenvif_max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
 
@@ -139,495 +138,11 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xenvif_rx_ring_full(struct xenvif *vif)
-{
-	RING_IDX peek   = vif->rx_req_cons_peek;
-	RING_IDX needed = max_required_rx_slots(vif);
-	struct xen_comms *comms = &vif->rx_comms;
-
-	return ((vif->rx.sring->req_prod - peek) < needed) ||
-	       ((vif->rx.rsp_prod_pvt +
-		 NETBK_RX_RING_SIZE(comms->nr_handles) - peek) < needed);
-}
-
-int xenvif_must_stop_queue(struct xenvif *vif)
-{
-	if (!xenvif_rx_ring_full(vif))
-		return 0;
-
-	vif->rx.sring->req_event = vif->rx_req_cons_peek +
-		max_required_rx_slots(vif);
-	mb(); /* request notification /then/ check the queue */
-
-	return xenvif_rx_ring_full(vif);
-}
-
-/*
- * Returns true if we should start a new receive buffer instead of
- * adding 'size' bytes to a buffer which currently contains 'offset'
- * bytes.
- */
-static bool start_new_rx_buffer(int offset, unsigned long size, int head)
-{
-	/* simple case: we have completely filled the current buffer. */
-	if (offset == MAX_BUFFER_OFFSET)
-		return true;
-
-	/*
-	 * complex case: start a fresh buffer if the current frag
-	 * would overflow the current buffer but only if:
-	 *     (i)   this frag would fit completely in the next buffer
-	 * and (ii)  there is already some data in the current buffer
-	 * and (iii) this is not the head buffer.
-	 *
-	 * Where:
-	 * - (i) stops us splitting a frag into two copies
-	 *   unless the frag is too large for a single buffer.
-	 * - (ii) stops us from leaving a buffer pointlessly empty.
-	 * - (iii) stops us leaving the first buffer
-	 *   empty. Strictly speaking this is already covered
-	 *   by (ii) but is explicitly checked because
-	 *   netfront relies on the first buffer being
-	 *   non-empty and can crash otherwise.
-	 *
-	 * This means we will effectively linearise small
-	 * frags but do not needlessly split large buffers
-	 * into multiple copies tend to give large frags their
-	 * own buffers as before.
-	 */
-	if ((offset + size > MAX_BUFFER_OFFSET) &&
-	    (size <= MAX_BUFFER_OFFSET) && offset && !head)
-		return true;
-
-	return false;
-}
-
-/*
- * Figure out how many ring slots we're going to need to send @skb to
- * the guest. This function is essentially a dry run of
- * xenvif_gop_frag_copy.
- */
-unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
-{
-	unsigned int count;
-	int i, copy_off;
-
-	count = DIV_ROUND_UP(
-			offset_in_page(skb->data)+skb_headlen(skb), PAGE_SIZE);
-
-	copy_off = skb_headlen(skb) % PAGE_SIZE;
-
-	if (skb_shinfo(skb)->gso_size)
-		count++;
-
-	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
-		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
-		unsigned long bytes;
-		while (size > 0) {
-			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
-
-			if (start_new_rx_buffer(copy_off, size, 0)) {
-				count++;
-				copy_off = 0;
-			}
-
-			bytes = size;
-			if (copy_off + bytes > MAX_BUFFER_OFFSET)
-				bytes = MAX_BUFFER_OFFSET - copy_off;
-
-			copy_off += bytes;
-			size -= bytes;
-		}
-	}
-	return count;
-}
-
-struct netrx_pending_operations {
-	unsigned copy_prod, copy_cons;
-	unsigned meta_prod, meta_cons;
-	struct gnttab_copy *copy;
-	struct xenvif_rx_meta *meta;
-	int copy_off;
-	grant_ref_t copy_gref;
-};
-
-static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-					struct netrx_pending_operations *npo)
-{
-	struct xenvif_rx_meta *meta;
-	struct xen_netif_rx_request *req;
-
-	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
-
-	meta = npo->meta + npo->meta_prod++;
-	meta->gso_size = 0;
-	meta->size = 0;
-	meta->id = req->id;
-
-	npo->copy_off = 0;
-	npo->copy_gref = req->gref;
-
-	return meta;
-}
-
-/*
- * Set up the grant operations for this fragment. If it's a flipping
- * interface, we also set up the unmap request from here.
- */
-static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				 struct netrx_pending_operations *npo,
-				 struct page *page, unsigned long size,
-				 unsigned long offset, int *head)
-{
-	struct gnttab_copy *copy_gop;
-	struct xenvif_rx_meta *meta;
-	/*
-	 * These variables are used iff get_page_ext returns true,
-	 * in which case they are guaranteed to be initialized.
-	 */
-	unsigned int uninitialized_var(idx);
-	int foreign = is_in_pool(page, &idx);
-	unsigned long bytes;
-
-	/* Data must not cross a page boundary. */
-	BUG_ON(size + offset > PAGE_SIZE);
-
-	meta = npo->meta + npo->meta_prod - 1;
-
-	while (size > 0) {
-		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
-
-		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
-			/*
-			 * Netfront requires there to be some data in the head
-			 * buffer.
-			 */
-			BUG_ON(*head);
-
-			meta = get_next_rx_buffer(vif, npo);
-		}
-
-		bytes = size;
-		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
-			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
-
-		copy_gop = npo->copy + npo->copy_prod++;
-		copy_gop->flags = GNTCOPY_dest_gref;
-		if (foreign) {
-			struct pending_tx_info *src_pend = to_txinfo(idx);
-			struct xenvif *rvif = to_vif(idx);
-
-			copy_gop->source.domid = rvif->domid;
-			copy_gop->source.u.ref = src_pend->req.gref;
-			copy_gop->flags |= GNTCOPY_source_gref;
-		} else {
-			void *vaddr = page_address(page);
-			copy_gop->source.domid = DOMID_SELF;
-			copy_gop->source.u.gmfn = virt_to_mfn(vaddr);
-		}
-		copy_gop->source.offset = offset;
-		copy_gop->dest.domid = vif->domid;
-
-		copy_gop->dest.offset = npo->copy_off;
-		copy_gop->dest.u.ref = npo->copy_gref;
-		copy_gop->len = bytes;
-
-		npo->copy_off += bytes;
-		meta->size += bytes;
-
-		offset += bytes;
-		size -= bytes;
-
-		/* Leave a gap for the GSO descriptor. */
-		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
-			vif->rx.req_cons++;
-
-		*head = 0; /* There must be something in this buffer now. */
-
-	}
-}
-
-/*
- * Prepare an SKB to be transmitted to the frontend.
- *
- * This function is responsible for allocating grant operations, meta
- * structures, etc.
- *
- * It returns the number of meta structures consumed. The number of
- * ring slots used is always equal to the number of meta slots used
- * plus the number of GSO descriptors used. Currently, we use either
- * zero GSO descriptors (for non-GSO packets) or one descriptor (for
- * frontend-side LRO).
- */
-static int xenvif_gop_skb(struct sk_buff *skb,
-			  struct netrx_pending_operations *npo)
-{
-	struct xenvif *vif = netdev_priv(skb->dev);
-	int nr_frags = skb_shinfo(skb)->nr_frags;
-	int i;
-	struct xen_netif_rx_request *req;
-	struct xenvif_rx_meta *meta;
-	unsigned char *data;
-	int head = 1;
-	int old_meta_prod;
-
-	old_meta_prod = npo->meta_prod;
-
-	/* Set up a GSO prefix descriptor, if necessary */
-	if (skb_shinfo(skb)->gso_size && vif->gso_prefix) {
-		req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
-		meta = npo->meta + npo->meta_prod++;
-		meta->gso_size = skb_shinfo(skb)->gso_size;
-		meta->size = 0;
-		meta->id = req->id;
-	}
-
-	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
-	meta = npo->meta + npo->meta_prod++;
-
-	if (!vif->gso_prefix)
-		meta->gso_size = skb_shinfo(skb)->gso_size;
-	else
-		meta->gso_size = 0;
-
-	meta->size = 0;
-	meta->id = req->id;
-	npo->copy_off = 0;
-	npo->copy_gref = req->gref;
-
-	data = skb->data;
-	while (data < skb_tail_pointer(skb)) {
-		unsigned int offset = offset_in_page(data);
-		unsigned int len = PAGE_SIZE - offset;
-
-		if (data + len > skb_tail_pointer(skb))
-			len = skb_tail_pointer(skb) - data;
-
-		xenvif_gop_frag_copy(vif, skb, npo,
-				     virt_to_page(data), len, offset, &head);
-		data += len;
-	}
-
-	for (i = 0; i < nr_frags; i++) {
-		xenvif_gop_frag_copy(vif, skb, npo,
-				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				     skb_shinfo(skb)->frags[i].page_offset,
-				     &head);
-	}
-
-	return npo->meta_prod - old_meta_prod;
-}
-
-/*
- * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
- * used to set up the operations on the top of
- * netrx_pending_operations, which have since been done.  Check that
- * they didn't give any errors and advance over them.
- */
-static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
-			    struct netrx_pending_operations *npo)
-{
-	struct gnttab_copy     *copy_op;
-	int status = XEN_NETIF_RSP_OKAY;
-	int i;
-
-	for (i = 0; i < nr_meta_slots; i++) {
-		copy_op = npo->copy + npo->copy_cons++;
-		if (copy_op->status != GNTST_okay) {
-			netdev_dbg(vif->dev,
-				   "Bad status %d from copy to DOM%d.\n",
-				   copy_op->status, vif->domid);
-			status = XEN_NETIF_RSP_ERROR;
-		}
-	}
-
-	return status;
-}
-
-static void xenvif_add_frag_responses(struct xenvif *vif, int status,
-				      struct xenvif_rx_meta *meta,
-				      int nr_meta_slots)
-{
-	int i;
-	unsigned long offset;
-
-	/* No fragments used */
-	if (nr_meta_slots <= 1)
-		return;
-
-	nr_meta_slots--;
-
-	for (i = 0; i < nr_meta_slots; i++) {
-		int flags;
-		if (i == nr_meta_slots - 1)
-			flags = 0;
-		else
-			flags = XEN_NETRXF_more_data;
-
-		offset = 0;
-		make_rx_response(vif, meta[i].id, status, offset,
-				 meta[i].size, flags);
-	}
-}
-
-struct skb_cb_overlay {
-	int meta_slots_used;
-};
-
-static void xenvif_kick_thread(struct xenvif *vif)
+void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xenvif_rx_action(struct xenvif *vif)
-{
-	s8 status;
-	u16 flags;
-	struct xen_netif_rx_response *resp;
-	struct sk_buff_head rxq;
-	struct sk_buff *skb;
-	LIST_HEAD(notify);
-	int ret;
-	int nr_frags;
-	int count;
-	unsigned long offset;
-	struct skb_cb_overlay *sco;
-	int need_to_notify = 0;
-	struct xen_comms *comms = &vif->rx_comms;
-
-	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
-	struct xenvif_rx_meta *m = get_cpu_var(meta);
-
-	struct netrx_pending_operations npo = {
-		.copy  = gco,
-		.meta  = m,
-	};
-
-	if (gco == NULL || m == NULL) {
-		put_cpu_var(grant_copy_op);
-		put_cpu_var(meta);
-		printk(KERN_ALERT "netback: CPU %x scratch space is not usable,"
-		       " not doing any TX work for vif%u.%u\n",
-		       smp_processor_id(), vif->domid, vif->handle);
-		return;
-	}
-
-	skb_queue_head_init(&rxq);
-
-	count = 0;
-
-	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
-		vif = netdev_priv(skb->dev);
-		nr_frags = skb_shinfo(skb)->nr_frags;
-
-		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
-
-		count += nr_frags + 1;
-
-		__skb_queue_tail(&rxq, skb);
-
-		/* Filled the batch queue? */
-		if (count + MAX_SKB_FRAGS >=
-		    NETBK_RX_RING_SIZE(comms->nr_handles))
-			break;
-	}
-
-	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
-
-	if (!npo.copy_prod) {
-		put_cpu_var(grant_copy_op);
-		put_cpu_var(meta);
-		return;
-	}
-
-	BUG_ON(npo.copy_prod > (2 * NETBK_MAX_RX_RING_SIZE));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
-					npo.copy_prod);
-	BUG_ON(ret != 0);
-
-	while ((skb = __skb_dequeue(&rxq)) != NULL) {
-		sco = (struct skb_cb_overlay *)skb->cb;
-
-		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
-			resp = RING_GET_RESPONSE(&vif->rx,
-						vif->rx.rsp_prod_pvt++);
-
-			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
-
-			resp->offset = m[npo.meta_cons].gso_size;
-			resp->id = m[npo.meta_cons].id;
-			resp->status = sco->meta_slots_used;
-
-			npo.meta_cons++;
-			sco->meta_slots_used--;
-		}
-
-
-		vif->dev->stats.tx_bytes += skb->len;
-		vif->dev->stats.tx_packets++;
-
-		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
-
-		if (sco->meta_slots_used == 1)
-			flags = 0;
-		else
-			flags = XEN_NETRXF_more_data;
-
-		if (skb->ip_summed == CHECKSUM_PARTIAL) /* local packet? */
-			flags |= XEN_NETRXF_csum_blank | XEN_NETRXF_data_validated;
-		else if (skb->ip_summed == CHECKSUM_UNNECESSARY)
-			/* remote but checksummed. */
-			flags |= XEN_NETRXF_data_validated;
-
-		offset = 0;
-		resp = make_rx_response(vif, m[npo.meta_cons].id,
-					status, offset,
-					m[npo.meta_cons].size,
-					flags);
-
-		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
-			struct xen_netif_extra_info *gso =
-				(struct xen_netif_extra_info *)
-				RING_GET_RESPONSE(&vif->rx,
-						  vif->rx.rsp_prod_pvt++);
-
-			resp->flags |= XEN_NETRXF_extra_info;
-
-			gso->u.gso.size = m[npo.meta_cons].gso_size;
-			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
-			gso->u.gso.pad = 0;
-			gso->u.gso.features = 0;
-
-			gso->type = XEN_NETIF_EXTRA_TYPE_GSO;
-			gso->flags = 0;
-		}
-
-		xenvif_add_frag_responses(vif, status,
-					  m + npo.meta_cons + 1,
-					  sco->meta_slots_used);
-
-		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		if (ret)
-			need_to_notify = 1;
-
-		xenvif_notify_tx_completion(vif);
-
-		npo.meta_cons += sco->meta_slots_used;
-		dev_kfree_skb(skb);
-	}
-
-	if (need_to_notify)
-		notify_remote_via_irq(vif->irq);
-
-	if (!skb_queue_empty(&vif->rx_queue))
-		xenvif_kick_thread(vif);
-
-	put_cpu_var(grant_copy_op);
-	put_cpu_var(meta);
-}
-
 void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
@@ -1383,29 +898,6 @@ static void make_tx_response(struct xenvif *vif,
 		notify_remote_via_irq(vif->irq);
 }
 
-static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
-					     u16      id,
-					     s8       st,
-					     u16      offset,
-					     u16      size,
-					     u16      flags)
-{
-	RING_IDX i = vif->rx.rsp_prod_pvt;
-	struct xen_netif_rx_response *resp;
-
-	resp = RING_GET_RESPONSE(&vif->rx, i);
-	resp->offset     = offset;
-	resp->flags      = flags;
-	resp->id         = id;
-	resp->status     = (s16)size;
-	if (st < 0)
-		resp->status = (s16)st;
-
-	vif->rx.rsp_prod_pvt = ++i;
-
-	return resp;
-}
-
 static inline int rx_work_todo(struct xenvif *vif)
 {
 	return !skb_queue_empty(&vif->rx_queue);
@@ -1507,8 +999,8 @@ int xenvif_kthread(void *data)
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(vif))
-			xenvif_rx_action(vif);
+		if (rx_work_todo(vif) && vif->action)
+			vif->action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 79499fc..4067286 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -415,6 +415,7 @@ static int connect_rings(struct backend_info *be)
 	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
 	unsigned int  tx_ring_order;
 	unsigned int  rx_ring_order;
+	unsigned int  rx_protocol;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
 			    "event-channel", "%u", &evtchn, NULL);
@@ -510,6 +511,11 @@ static int connect_rings(struct backend_info *be)
 		}
 	}
 
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-protocol",
+			   "%u", &rx_protocol);
+	if (err < 0)
+		rx_protocol = XENVIF_MIN_RX_PROTOCOL;
+
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
 			   &rx_copy);
 	if (err == -ENOENT) {
@@ -559,7 +565,7 @@ static int connect_rings(struct backend_info *be)
 	err = xenvif_connect(vif,
 			     tx_ring_ref, (1U << tx_ring_order),
 			     rx_ring_ref, (1U << rx_ring_order),
-			     evtchn);
+			     evtchn, rx_protocol);
 	if (err) {
 		int i;
 		xenbus_dev_fatal(dev, err,
diff --git a/drivers/net/xen-netback/xenvif_rx_protocol0.c b/drivers/net/xen-netback/xenvif_rx_protocol0.c
new file mode 100644
index 0000000..3c95d65
--- /dev/null
+++ b/drivers/net/xen-netback/xenvif_rx_protocol0.c
@@ -0,0 +1,616 @@
+/*
+ * netback rx protocol 0 implementation.
+ *
+ * Copyright (c) 2012, Citrix Systems Inc.
+ *
+ * Author: Wei Liu <wei.liu2@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "common.h"
+
+#include <xen/events.h>
+#include <xen/interface/memory.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/page.h>
+
+struct xenvif_rx_meta;
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
+DECLARE_PER_CPU(struct gnttab_copy *, grant_copy_op);
+DECLARE_PER_CPU(struct xenvif_rx_meta *, meta);
+
+struct netrx_pending_operations {
+	unsigned copy_prod, copy_cons;
+	unsigned meta_prod, meta_cons;
+	struct gnttab_copy *copy;
+	struct xenvif_rx_meta *meta;
+	int copy_off;
+	grant_ref_t copy_gref;
+};
+
+struct skb_cb_overlay {
+	int meta_slots_used;
+};
+
+static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
+					     u16      id,
+					     s8       st,
+					     u16      offset,
+					     u16      size,
+					     u16      flags)
+{
+	RING_IDX i = vif->rx.p0.back.rsp_prod_pvt;
+	struct xen_netif_rx_response *resp;
+
+	resp = RING_GET_RESPONSE(&vif->rx.p0.back, i);
+	resp->offset     = offset;
+	resp->flags      = flags;
+	resp->id         = id;
+	resp->status     = (s16)size;
+	if (st < 0)
+		resp->status = (s16)st;
+
+	vif->rx.p0.back.rsp_prod_pvt = ++i;
+
+	return resp;
+}
+
+int xenvif_rx_ring_full(struct xenvif *vif)
+{
+	RING_IDX peek   = vif->rx.p0.rx_req_cons_peek;
+	RING_IDX needed = xenvif_max_required_rx_slots(vif);
+	struct xen_comms *comms = &vif->rx_comms;
+
+	return ((vif->rx.p0.back.sring->req_prod - peek) < needed) ||
+		((vif->rx.p0.back.rsp_prod_pvt +
+		  NETBK_RX_RING_SIZE(comms->nr_handles) - peek) < needed);
+}
+
+int xenvif_must_stop_queue(struct xenvif *vif)
+{
+	if (!xenvif_rx_ring_full(vif))
+		return 0;
+
+	vif->rx.p0.back.sring->req_event = vif->rx.p0.rx_req_cons_peek +
+		xenvif_max_required_rx_slots(vif);
+	mb(); /* request notification /then/ check the queue */
+
+	return xenvif_rx_ring_full(vif);
+}
+
+/*
+ * Returns true if we should start a new receive buffer instead of
+ * adding 'size' bytes to a buffer which currently contains 'offset'
+ * bytes.
+ */
+static bool start_new_rx_buffer(int offset, unsigned long size, int head)
+{
+	/* simple case: we have completely filled the current buffer. */
+	if (offset == MAX_BUFFER_OFFSET)
+		return true;
+
+	/*
+	 * complex case: start a fresh buffer if the current frag
+	 * would overflow the current buffer but only if:
+	 *     (i)   this frag would fit completely in the next buffer
+	 * and (ii)  there is already some data in the current buffer
+	 * and (iii) this is not the head buffer.
+	 *
+	 * Where:
+	 * - (i) stops us splitting a frag into two copies
+	 *   unless the frag is too large for a single buffer.
+	 * - (ii) stops us from leaving a buffer pointlessly empty.
+	 * - (iii) stops us leaving the first buffer
+	 *   empty. Strictly speaking this is already covered
+	 *   by (ii) but is explicitly checked because
+	 *   netfront relies on the first buffer being
+	 *   non-empty and can crash otherwise.
+	 *
+	 * This means we will effectively linearise small
+	 * frags but do not needlessly split large buffers
+	 * into multiple copies tend to give large frags their
+	 * own buffers as before.
+	 */
+	if ((offset + size > MAX_BUFFER_OFFSET) &&
+	    (size <= MAX_BUFFER_OFFSET) && offset && !head)
+		return true;
+
+	return false;
+}
+
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+				struct netrx_pending_operations *npo)
+{
+	struct xenvif_rx_meta *meta;
+	struct xen_netif_rx_request *req;
+
+	req = RING_GET_REQUEST(&vif->rx.p0.back, vif->rx.p0.back.req_cons++);
+
+	meta = npo->meta + npo->meta_prod++;
+	meta->gso_size = 0;
+	meta->size = 0;
+	meta->id = req->id;
+
+	npo->copy_off = 0;
+	npo->copy_gref = req->gref;
+
+	return meta;
+}
+
+/*
+ * Set up the grant operations for this fragment. If it's a flipping
+ * interface, we also set up the unmap request from here.
+ */
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				struct netrx_pending_operations *npo,
+				struct page *page, unsigned long size,
+				unsigned long offset, int *head)
+{
+	struct gnttab_copy *copy_gop;
+	struct xenvif_rx_meta *meta;
+	/*
+	 * These variables are used iff get_page_ext returns true,
+	 * in which case they are guaranteed to be initialized.
+	 */
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
+	unsigned long bytes;
+
+	/* Data must not cross a page boundary. */
+	BUG_ON(size + offset > PAGE_SIZE);
+
+	meta = npo->meta + npo->meta_prod - 1;
+
+	while (size > 0) {
+		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
+
+		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
+			/*
+			 * Netfront requires there to be some data in the head
+			 * buffer.
+			 */
+			BUG_ON(*head);
+
+			meta = get_next_rx_buffer(vif, npo);
+		}
+
+		bytes = size;
+		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
+			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
+
+		copy_gop = npo->copy + npo->copy_prod++;
+		copy_gop->flags = GNTCOPY_dest_gref;
+		if (foreign) {
+			struct pending_tx_info *src_pend = to_txinfo(idx);
+			struct xenvif *rvif = to_vif(idx);
+
+			copy_gop->source.domid = rvif->domid;
+			copy_gop->source.u.ref = src_pend->req.gref;
+			copy_gop->flags |= GNTCOPY_source_gref;
+		} else {
+			void *vaddr = page_address(page);
+			copy_gop->source.domid = DOMID_SELF;
+			copy_gop->source.u.gmfn = virt_to_mfn(vaddr);
+		}
+		copy_gop->source.offset = offset;
+		copy_gop->dest.domid = vif->domid;
+
+		copy_gop->dest.offset = npo->copy_off;
+		copy_gop->dest.u.ref = npo->copy_gref;
+		copy_gop->len = bytes;
+
+		npo->copy_off += bytes;
+		meta->size += bytes;
+
+		offset += bytes;
+		size -= bytes;
+
+		/* Leave a gap for the GSO descriptor. */
+		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
+			vif->rx.p0.back.req_cons++;
+
+		*head = 0; /* There must be something in this buffer now. */
+	}
+}
+
+/*
+ * Prepare an SKB to be transmitted to the frontend.
+ *
+ * This function is responsible for allocating grant operations, meta
+ * structures, etc.
+ *
+ * It returns the number of meta structures consumed. The number of
+ * ring slots used is always equal to the number of meta slots used
+ * plus the number of GSO descriptors used. Currently, we use either
+ * zero GSO descriptors (for non-GSO packets) or one descriptor (for
+ * frontend-side LRO).
+ */
+static int xenvif_gop_skb(struct sk_buff *skb,
+			 struct netrx_pending_operations *npo)
+{
+	struct xenvif *vif = netdev_priv(skb->dev);
+	int nr_frags = skb_shinfo(skb)->nr_frags;
+	int i;
+	struct xen_netif_rx_request *req;
+	struct xenvif_rx_meta *meta;
+	unsigned char *data;
+	int head = 1;
+	int old_meta_prod;
+
+	old_meta_prod = npo->meta_prod;
+
+	/* Set up a GSO prefix descriptor, if necessary */
+	if (skb_shinfo(skb)->gso_size && vif->gso_prefix) {
+		req = RING_GET_REQUEST(&vif->rx.p0.back,
+				       vif->rx.p0.back.req_cons++);
+		meta = npo->meta + npo->meta_prod++;
+		meta->gso_size = skb_shinfo(skb)->gso_size;
+		meta->size = 0;
+		meta->id = req->id;
+	}
+
+	req = RING_GET_REQUEST(&vif->rx.p0.back, vif->rx.p0.back.req_cons++);
+	meta = npo->meta + npo->meta_prod++;
+
+	if (!vif->gso_prefix)
+		meta->gso_size = skb_shinfo(skb)->gso_size;
+	else
+		meta->gso_size = 0;
+
+	meta->size = 0;
+	meta->id = req->id;
+	npo->copy_off = 0;
+	npo->copy_gref = req->gref;
+
+	data = skb->data;
+
+	while (data < skb_tail_pointer(skb)) {
+		unsigned int offset = offset_in_page(data);
+		unsigned int len = PAGE_SIZE - offset;
+
+		if (data + len > skb_tail_pointer(skb))
+			len = skb_tail_pointer(skb) - data;
+
+		xenvif_gop_frag_copy(vif, skb, npo,
+				    virt_to_page(data), len, offset, &head);
+		data += len;
+	}
+
+	for (i = 0; i < nr_frags; i++) {
+		xenvif_gop_frag_copy(vif, skb, npo,
+				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				    skb_shinfo(skb)->frags[i].page_offset,
+				    &head);
+	}
+
+	return npo->meta_prod - old_meta_prod;
+}
+
+/*
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
+ * used to set up the operations on the top of
+ * netrx_pending_operations, which have since been done.  Check that
+ * they didn't give any errors and advance over them.
+ */
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			   struct netrx_pending_operations *npo)
+{
+	struct gnttab_copy     *copy_op;
+	int status = XEN_NETIF_RSP_OKAY;
+	int i;
+
+	for (i = 0; i < nr_meta_slots; i++) {
+		copy_op = npo->copy + npo->copy_cons++;
+		if (copy_op->status != GNTST_okay) {
+			netdev_dbg(vif->dev,
+				   "Bad status %d from copy to DOM%d.\n",
+				   copy_op->status, vif->domid);
+			status = XEN_NETIF_RSP_ERROR;
+		}
+	}
+
+	return status;
+}
+
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				     struct xenvif_rx_meta *meta,
+				     int nr_meta_slots)
+{
+	int i;
+	unsigned long offset;
+
+	/* No fragments used */
+	if (nr_meta_slots <= 1)
+		return;
+
+	nr_meta_slots--;
+
+	for (i = 0; i < nr_meta_slots; i++) {
+		int flags;
+		if (i == nr_meta_slots - 1)
+			flags = 0;
+		else
+			flags = XEN_NETRXF_more_data;
+
+		offset = 0;
+		make_rx_response(vif, meta[i].id, status, offset,
+				 meta[i].size, flags);
+	}
+}
+
+/*
+ * Figure out how many ring slots we're going to need to send @skb to
+ * the guest. This function is essentially a dry run of
+ * xenvif_gop_frag_copy.
+ */
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+{
+	unsigned int count;
+	int i, copy_off;
+
+	count = DIV_ROUND_UP(
+			offset_in_page(skb->data)+skb_headlen(skb), PAGE_SIZE);
+
+	copy_off = skb_headlen(skb) % PAGE_SIZE;
+
+	if (skb_shinfo(skb)->gso_size)
+		count++;
+
+	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
+		unsigned long bytes;
+		while (size > 0) {
+			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
+
+			if (start_new_rx_buffer(copy_off, size, 0)) {
+				count++;
+				copy_off = 0;
+			}
+
+			bytes = size;
+			if (copy_off + bytes > MAX_BUFFER_OFFSET)
+				bytes = MAX_BUFFER_OFFSET - copy_off;
+
+			copy_off += bytes;
+			size -= bytes;
+		}
+	}
+	return count;
+}
+
+
+void xenvif_rx_action(struct xenvif *vif)
+{
+	s8 status;
+	u16 flags;
+	struct xen_netif_rx_response *resp;
+	struct sk_buff_head rxq;
+	struct sk_buff *skb;
+	LIST_HEAD(notify);
+	int ret;
+	int nr_frags;
+	int count;
+	unsigned long offset;
+	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
+	struct xen_comms *comms = &vif->rx_comms;
+
+	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
+	struct xenvif_rx_meta *m = get_cpu_var(meta);
+
+	struct netrx_pending_operations npo = {
+		.copy  = gco,
+		.meta  = m,
+	};
+
+	if (gco == NULL || m == NULL) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
+		printk(KERN_ALERT "netback: CPU %x scratch space is not usable,"
+		       " not doing any TX work for vif%u.%u\n",
+		       smp_processor_id(), vif->domid, vif->handle);
+		return;
+	}
+
+	skb_queue_head_init(&rxq);
+
+	count = 0;
+
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
+		vif = netdev_priv(skb->dev);
+		nr_frags = skb_shinfo(skb)->nr_frags;
+
+		sco = (struct skb_cb_overlay *)skb->cb;
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
+
+		count += nr_frags + 1;
+
+		__skb_queue_tail(&rxq, skb);
+
+		/* Filled the batch queue? */
+		if (count + MAX_SKB_FRAGS >=
+		    NETBK_RX_RING_SIZE(comms->nr_handles))
+			break;
+	}
+
+	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
+
+	if (!npo.copy_prod) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
+		return;
+	}
+
+	BUG_ON(npo.copy_prod > (2 * NETBK_MAX_RX_RING_SIZE));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
+					npo.copy_prod);
+	BUG_ON(ret != 0);
+
+	while ((skb = __skb_dequeue(&rxq)) != NULL) {
+		sco = (struct skb_cb_overlay *)skb->cb;
+
+		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
+			resp = RING_GET_RESPONSE(&vif->rx.p0.back,
+					 vif->rx.p0.back.rsp_prod_pvt++);
+
+			resp->flags =
+				XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
+
+			resp->offset = m[npo.meta_cons].gso_size;
+			resp->id = m[npo.meta_cons].id;
+			resp->status = sco->meta_slots_used;
+
+			npo.meta_cons++;
+			sco->meta_slots_used--;
+		}
+
+
+		vif->dev->stats.tx_bytes += skb->len;
+		vif->dev->stats.tx_packets++;
+
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
+
+		if (sco->meta_slots_used == 1)
+			flags = 0;
+		else
+			flags = XEN_NETRXF_more_data;
+
+		if (skb->ip_summed == CHECKSUM_PARTIAL) /* local packet? */
+			flags |= XEN_NETRXF_csum_blank |
+				XEN_NETRXF_data_validated;
+		else if (skb->ip_summed == CHECKSUM_UNNECESSARY)
+			/* remote but checksummed. */
+			flags |= XEN_NETRXF_data_validated;
+
+		offset = 0;
+		resp = make_rx_response(vif, m[npo.meta_cons].id,
+					status, offset,
+					m[npo.meta_cons].size,
+					flags);
+
+		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
+			struct xen_netif_extra_info *gso =
+				(struct xen_netif_extra_info *)
+				RING_GET_RESPONSE(&vif->rx.p0.back,
+					  vif->rx.p0.back.rsp_prod_pvt++);
+
+			resp->flags |= XEN_NETRXF_extra_info;
+
+			gso->u.gso.size = m[npo.meta_cons].gso_size;
+			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
+			gso->u.gso.pad = 0;
+			gso->u.gso.features = 0;
+
+			gso->type = XEN_NETIF_EXTRA_TYPE_GSO;
+			gso->flags = 0;
+		}
+
+		xenvif_add_frag_responses(vif, status,
+					  m + npo.meta_cons + 1,
+					  sco->meta_slots_used);
+
+		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx.p0.back, ret);
+		if (ret)
+			need_to_notify = 1;
+
+		if (netif_queue_stopped(vif->dev) &&
+		    xenvif_schedulable(vif) &&
+		    !xenvif_rx_ring_full(vif))
+			netif_wake_queue(vif->dev);
+
+		npo.meta_cons += sco->meta_slots_used;
+		dev_kfree_skb(skb);
+	}
+
+	if (need_to_notify)
+		notify_remote_via_irq(vif->irq);
+
+	if (!skb_queue_empty(&vif->rx_queue))
+		xenvif_kick_thread(vif);
+
+	put_cpu_var(grant_copy_op);
+	put_cpu_var(meta);
+}
+
+int xenvif_p0_setup(struct xenvif *vif)
+{
+	struct xenvif_rx_protocol0 *p0 = &vif->rx.p0;
+	struct xen_netif_rx_sring *sring;
+
+	p0->rx_req_cons_peek = 0;
+
+	sring = (struct xen_netif_rx_sring *)vif->rx_comms.ring_area->addr;
+	BACK_RING_INIT(&p0->back, sring, PAGE_SIZE * vif->rx_comms.nr_handles);
+
+	return 0;
+}
+
+void xenvif_p0_start_xmit(struct xenvif *vif, struct sk_buff *skb)
+{
+	struct net_device *dev = vif->dev;
+
+	/* Drop the packet if there is no carrier */
+	if (unlikely(!xenvif_schedulable(vif)))
+		goto drop;
+
+	/* Drop the packet if the target domain has no receive buffers. */
+	if (unlikely(xenvif_rx_ring_full(vif)))
+		goto drop;
+
+	/* Reserve ring slots for the worst-case number of fragments. */
+	vif->rx.p0.rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
+
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
+		netif_stop_queue(dev);
+
+	xenvif_queue_tx_skb(vif, skb);
+
+	return;
+
+drop:
+	vif->dev->stats.tx_dropped++;
+	dev_kfree_skb(skb);
+}
+
+void xenvif_p0_teardown(struct xenvif *vif)
+{
+	/* Nothing to teardown, relax */
+}
+
+void xenvif_p0_event(struct xenvif *vif)
+{
+	if (!xenvif_rx_ring_full(vif))
+		netif_wake_queue(vif->dev);
+}
+
+void xenvif_p0_action(struct xenvif *vif)
+{
+	xenvif_rx_action(vif);
+}
diff --git a/drivers/net/xen-netback/xenvif_rx_protocol0.h b/drivers/net/xen-netback/xenvif_rx_protocol0.h
new file mode 100644
index 0000000..aceb2ec
--- /dev/null
+++ b/drivers/net/xen-netback/xenvif_rx_protocol0.h
@@ -0,0 +1,53 @@
+/*
+ * netback rx protocol 0 implementation.
+ *
+ * Copyright (c) 2012, Citrix Systems Inc.
+ *
+ * Author: Wei Liu <wei.liu2@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU 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 __XENVIF_RX_PROTOCOL0_H__
+#define __XENVIF_RX_PROTOCOL0_H__
+
+struct xenvif_rx_protocol0 {
+	struct xen_netif_rx_back_ring back;
+	/*
+	 * Allow xenvif_start_xmit() to peek ahead in the rx request
+	 * ring.  This is a prediction of what rx_req_cons will be
+	 * once all queued skbs are put on the ring.
+	 */
+	RING_IDX rx_req_cons_peek;
+};
+
+
+int  xenvif_p0_setup(struct xenvif *vif);
+void xenvif_p0_start_xmit(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_p0_teardown(struct xenvif *vif);
+void xenvif_p0_event(struct xenvif *vif);
+void xenvif_p0_action(struct xenvif *vif);
+
+#endif /* __XENVIF_RX_PROTOCOL0_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 Jan 30 14:46:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUa-0007Vt-Ef; Mon, 30 Jan 2012 14:46:00 +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 1RrsUY-0007MK-2w
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!8
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 358 invoked from network); 30 Jan 2012 14:45:51 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614403"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45: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; Mon, 30 Jan 2012 09:45:49 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTk029057;
	Mon, 30 Jan 2012 06:45:48 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:31 +0000
Message-ID: <1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 13/16] netback: stub for multi receive
	protocol 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

Refactor netback, make stub for mutli receive protocols. Also stub
existing code as protocol 0.

Now the file layout becomes:

 - interface.c: xenvif interfaces
 - xenbus.c: xenbus related functions
 - netback.c: common functions for various protocols

For different protocols:

 - xenvif_rx_protocolX.h: header file for the protocol, including
                          protocol structures and functions
 - xenvif_rx_protocolX.c: implementations

To add a new protocol:

 - include protocol header in common.h
 - modify XENVIF_MAX_RX_PROTOCOL in common.h
 - add protocol structure in xenvif.rx union
 - stub in xenbus.c
 - modify Makefile

A protocol should define five functions:

 - setup: setup frontend / backend ring connections
 - teardown: teardown frontend / backend ring connections
 - start_xmit: host start xmit (i.e. guest need to do rx)
 - event: rx completion event
 - action: prepare host side data for guest rx

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/Makefile              |    2 +-
 drivers/net/xen-netback/common.h              |   34 +-
 drivers/net/xen-netback/interface.c           |   49 +-
 drivers/net/xen-netback/netback.c             |  528 +---------------------
 drivers/net/xen-netback/xenbus.c              |    8 +-
 drivers/net/xen-netback/xenvif_rx_protocol0.c |  616 +++++++++++++++++++++++++
 drivers/net/xen-netback/xenvif_rx_protocol0.h |   53 +++
 7 files changed, 732 insertions(+), 558 deletions(-)
 create mode 100644 drivers/net/xen-netback/xenvif_rx_protocol0.c
 create mode 100644 drivers/net/xen-netback/xenvif_rx_protocol0.h

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index dc4b8b1..fed8add 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o page_pool.o
+xen-netback-y := netback.o xenbus.o interface.o page_pool.o xenvif_rx_protocol0.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 3cf9b8f..f3d95b3 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -46,6 +46,7 @@
 #include <xen/xenbus.h>
 
 #include "page_pool.h"
+#include "xenvif_rx_protocol0.h"
 
 struct xenvif_rx_meta {
 	int id;
@@ -79,6 +80,9 @@ struct xen_comms {
 	unsigned int      nr_handles;
 };
 
+#define XENVIF_MIN_RX_PROTOCOL 0
+#define XENVIF_MAX_RX_PROTOCOL 0
+
 struct xenvif {
 	/* Unique identifier for this interface. */
 	domid_t          domid;
@@ -99,9 +103,13 @@ struct xenvif {
 	/* Physical parameters of the comms window. */
 	unsigned int     irq;
 
-	/* The shared rings and indexes. */
+	/* The shared tx ring and index. */
 	struct xen_netif_tx_back_ring tx;
-	struct xen_netif_rx_back_ring rx;
+
+	/* Multi receive protocol support */
+	union {
+		struct xenvif_rx_protocol0 p0;
+	} rx;
 
 	/* Frontend feature information. */
 	u8 can_sg:1;
@@ -112,13 +120,6 @@ struct xenvif {
 	/* Internal feature information. */
 	u8 can_queue:1;	    /* can queue packets for receiver? */
 
-	/*
-	 * Allow xenvif_start_xmit() to peek ahead in the rx request
-	 * ring.  This is a prediction of what rx_req_cons will be
-	 * once all queued skbs are put on the ring.
-	 */
-	RING_IDX rx_req_cons_peek;
-
 	/* Transmit shaping: allow 'credit_bytes' every 'credit_usec'. */
 	unsigned long   credit_bytes;
 	unsigned long   credit_usec;
@@ -128,6 +129,13 @@ struct xenvif {
 	/* Statistics */
 	unsigned long rx_gso_checksum_fixup;
 
+	/* Hooks for multi receive protocol support */
+	int  (*setup)(struct xenvif *);
+	void (*start_xmit)(struct xenvif *, struct sk_buff *);
+	void (*teardown)(struct xenvif *);
+	void (*event)(struct xenvif *);
+	void (*action)(struct xenvif *);
+
 	/* Miscellaneous private stuff. */
 	struct net_device *dev;
 
@@ -154,7 +162,7 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
-		   unsigned int evtchn);
+		   unsigned int evtchn, unsigned int rx_protocol);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -178,8 +186,6 @@ void xenvif_check_rx_xenvif(struct xenvif *vif);
 
 /* Queue an SKB for transmission to the frontend */
 void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb);
-/* Notify xenvif that ring now has space to send an skb to the frontend */
-void xenvif_notify_tx_completion(struct xenvif *vif);
 
 /* Returns number of ring slots required to send an skb to the frontend */
 unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb);
@@ -188,7 +194,11 @@ int xenvif_tx_action(struct xenvif *vif, int budget);
 void xenvif_rx_action(struct xenvif *vif);
 
 int xenvif_kthread(void *data);
+void xenvif_kick_thread(struct xenvif *vif);
+
+int xenvif_max_required_rx_slots(struct xenvif *vif);
 
+extern unsigned int MODPARM_netback_max_rx_protocol;
 extern unsigned int MODPARM_netback_max_tx_ring_page_order;
 extern unsigned int MODPARM_netback_max_rx_ring_page_order;
 
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 29f4fd9..0f05f03 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -46,17 +46,12 @@ int xenvif_schedulable(struct xenvif *vif)
 	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
 }
 
-static int xenvif_rx_schedulable(struct xenvif *vif)
-{
-	return xenvif_schedulable(vif) && !xenvif_rx_ring_full(vif);
-}
-
 static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
-	if (xenvif_rx_schedulable(vif))
-		netif_wake_queue(vif->dev);
+	if (xenvif_schedulable(vif) && vif->event != NULL)
+		vif->event(vif);
 
 	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
 		napi_schedule(&vif->napi);
@@ -100,17 +95,11 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	if (vif->task == NULL)
 		goto drop;
 
-	/* Drop the packet if the target domain has no receive buffers. */
-	if (!xenvif_rx_schedulable(vif))
+	/* Drop the packet if vif does not support transmit */
+	if (vif->start_xmit == NULL)
 		goto drop;
 
-	/* Reserve ring slots for the worst-case number of fragments. */
-	vif->rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
-
-	if (vif->can_queue && xenvif_must_stop_queue(vif))
-		netif_stop_queue(dev);
-
-	xenvif_queue_tx_skb(vif, skb);
+	vif->start_xmit(vif, skb);
 
 	return NETDEV_TX_OK;
 
@@ -120,12 +109,6 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	return NETDEV_TX_OK;
 }
 
-void xenvif_notify_tx_completion(struct xenvif *vif)
-{
-	if (netif_queue_stopped(vif->dev) && xenvif_rx_schedulable(vif))
-		netif_wake_queue(vif->dev);
-}
-
 static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 {
 	struct xenvif *vif = netdev_priv(dev);
@@ -325,11 +308,10 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
-		   unsigned int evtchn)
+		   unsigned int evtchn, unsigned int rx_protocol)
 {
 	int err = -ENOMEM;
 	struct xen_netif_tx_sring *txs;
-	struct xen_netif_rx_sring *rxs;
 
 	/* Already connected through? */
 	if (vif->irq)
@@ -348,8 +330,20 @@ int xenvif_connect(struct xenvif *vif,
 					rx_ring_ref, rx_ring_ref_count);
 	if (err)
 		goto err_tx_unmap;
-	rxs = (struct xen_netif_rx_sring *)vif->rx_comms.ring_area->addr;
-	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE * rx_ring_ref_count);
+	switch (rx_protocol) {
+	case 0:
+		vif->setup = xenvif_p0_setup;
+		vif->start_xmit = xenvif_p0_start_xmit;
+		vif->teardown = xenvif_p0_teardown;
+		vif->event = xenvif_p0_event;
+		vif->action = xenvif_p0_action;
+		break;
+	default:
+		err = -EOPNOTSUPP;
+		goto err_rx_unmap;
+	}
+	if (vif->setup(vif))
+		goto err_rx_unmap;
 
 	err = bind_interdomain_evtchn_to_irqhandler(
 		vif->domid, evtchn, xenvif_interrupt, 0,
@@ -422,6 +416,9 @@ void xenvif_disconnect(struct xenvif *vif)
 	xenvif_unmap_frontend_rings(&vif->tx_comms);
 	xenvif_unmap_frontend_rings(&vif->rx_comms);
 
+	if (vif->teardown)
+		vif->teardown(vif);
+
 	free_netdev(vif->dev);
 
 	if (need_module_put)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 96f354c..2ea43d4 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -49,6 +49,12 @@
 #include <asm/xen/hypercall.h>
 #include <asm/xen/page.h>
 
+unsigned int MODPARM_netback_max_rx_protocol = XENVIF_MAX_RX_PROTOCOL;
+module_param_named(netback_max_rx_protocol,
+		   MODPARM_netback_max_rx_protocol, uint, 0);
+MODULE_PARM_DESC(netback_max_rx_protocol,
+		 "Maximum supported receiver protocol version");
+
 unsigned int MODPARM_netback_max_rx_ring_page_order = NETBK_MAX_RING_PAGE_ORDER;
 module_param_named(netback_max_rx_ring_page_order,
 		   MODPARM_netback_max_rx_ring_page_order, uint, 0);
@@ -79,13 +85,6 @@ static void make_tx_response(struct xenvif *vif,
 static inline int tx_work_todo(struct xenvif *vif);
 static inline int rx_work_todo(struct xenvif *vif);
 
-static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
-					     u16      id,
-					     s8       st,
-					     u16      offset,
-					     u16      size,
-					     u16      flags);
-
 static inline unsigned long idx_to_pfn(struct xenvif *vif,
 				       u16 idx)
 {
@@ -129,7 +128,7 @@ static inline pending_ring_idx_t nr_pending_reqs(struct xenvif *vif)
 		vif->pending_prod + vif->pending_cons;
 }
 
-static int max_required_rx_slots(struct xenvif *vif)
+int xenvif_max_required_rx_slots(struct xenvif *vif)
 {
 	int max = DIV_ROUND_UP(vif->dev->mtu, PAGE_SIZE);
 
@@ -139,495 +138,11 @@ static int max_required_rx_slots(struct xenvif *vif)
 	return max;
 }
 
-int xenvif_rx_ring_full(struct xenvif *vif)
-{
-	RING_IDX peek   = vif->rx_req_cons_peek;
-	RING_IDX needed = max_required_rx_slots(vif);
-	struct xen_comms *comms = &vif->rx_comms;
-
-	return ((vif->rx.sring->req_prod - peek) < needed) ||
-	       ((vif->rx.rsp_prod_pvt +
-		 NETBK_RX_RING_SIZE(comms->nr_handles) - peek) < needed);
-}
-
-int xenvif_must_stop_queue(struct xenvif *vif)
-{
-	if (!xenvif_rx_ring_full(vif))
-		return 0;
-
-	vif->rx.sring->req_event = vif->rx_req_cons_peek +
-		max_required_rx_slots(vif);
-	mb(); /* request notification /then/ check the queue */
-
-	return xenvif_rx_ring_full(vif);
-}
-
-/*
- * Returns true if we should start a new receive buffer instead of
- * adding 'size' bytes to a buffer which currently contains 'offset'
- * bytes.
- */
-static bool start_new_rx_buffer(int offset, unsigned long size, int head)
-{
-	/* simple case: we have completely filled the current buffer. */
-	if (offset == MAX_BUFFER_OFFSET)
-		return true;
-
-	/*
-	 * complex case: start a fresh buffer if the current frag
-	 * would overflow the current buffer but only if:
-	 *     (i)   this frag would fit completely in the next buffer
-	 * and (ii)  there is already some data in the current buffer
-	 * and (iii) this is not the head buffer.
-	 *
-	 * Where:
-	 * - (i) stops us splitting a frag into two copies
-	 *   unless the frag is too large for a single buffer.
-	 * - (ii) stops us from leaving a buffer pointlessly empty.
-	 * - (iii) stops us leaving the first buffer
-	 *   empty. Strictly speaking this is already covered
-	 *   by (ii) but is explicitly checked because
-	 *   netfront relies on the first buffer being
-	 *   non-empty and can crash otherwise.
-	 *
-	 * This means we will effectively linearise small
-	 * frags but do not needlessly split large buffers
-	 * into multiple copies tend to give large frags their
-	 * own buffers as before.
-	 */
-	if ((offset + size > MAX_BUFFER_OFFSET) &&
-	    (size <= MAX_BUFFER_OFFSET) && offset && !head)
-		return true;
-
-	return false;
-}
-
-/*
- * Figure out how many ring slots we're going to need to send @skb to
- * the guest. This function is essentially a dry run of
- * xenvif_gop_frag_copy.
- */
-unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
-{
-	unsigned int count;
-	int i, copy_off;
-
-	count = DIV_ROUND_UP(
-			offset_in_page(skb->data)+skb_headlen(skb), PAGE_SIZE);
-
-	copy_off = skb_headlen(skb) % PAGE_SIZE;
-
-	if (skb_shinfo(skb)->gso_size)
-		count++;
-
-	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
-		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
-		unsigned long bytes;
-		while (size > 0) {
-			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
-
-			if (start_new_rx_buffer(copy_off, size, 0)) {
-				count++;
-				copy_off = 0;
-			}
-
-			bytes = size;
-			if (copy_off + bytes > MAX_BUFFER_OFFSET)
-				bytes = MAX_BUFFER_OFFSET - copy_off;
-
-			copy_off += bytes;
-			size -= bytes;
-		}
-	}
-	return count;
-}
-
-struct netrx_pending_operations {
-	unsigned copy_prod, copy_cons;
-	unsigned meta_prod, meta_cons;
-	struct gnttab_copy *copy;
-	struct xenvif_rx_meta *meta;
-	int copy_off;
-	grant_ref_t copy_gref;
-};
-
-static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
-					struct netrx_pending_operations *npo)
-{
-	struct xenvif_rx_meta *meta;
-	struct xen_netif_rx_request *req;
-
-	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
-
-	meta = npo->meta + npo->meta_prod++;
-	meta->gso_size = 0;
-	meta->size = 0;
-	meta->id = req->id;
-
-	npo->copy_off = 0;
-	npo->copy_gref = req->gref;
-
-	return meta;
-}
-
-/*
- * Set up the grant operations for this fragment. If it's a flipping
- * interface, we also set up the unmap request from here.
- */
-static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
-				 struct netrx_pending_operations *npo,
-				 struct page *page, unsigned long size,
-				 unsigned long offset, int *head)
-{
-	struct gnttab_copy *copy_gop;
-	struct xenvif_rx_meta *meta;
-	/*
-	 * These variables are used iff get_page_ext returns true,
-	 * in which case they are guaranteed to be initialized.
-	 */
-	unsigned int uninitialized_var(idx);
-	int foreign = is_in_pool(page, &idx);
-	unsigned long bytes;
-
-	/* Data must not cross a page boundary. */
-	BUG_ON(size + offset > PAGE_SIZE);
-
-	meta = npo->meta + npo->meta_prod - 1;
-
-	while (size > 0) {
-		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
-
-		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
-			/*
-			 * Netfront requires there to be some data in the head
-			 * buffer.
-			 */
-			BUG_ON(*head);
-
-			meta = get_next_rx_buffer(vif, npo);
-		}
-
-		bytes = size;
-		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
-			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
-
-		copy_gop = npo->copy + npo->copy_prod++;
-		copy_gop->flags = GNTCOPY_dest_gref;
-		if (foreign) {
-			struct pending_tx_info *src_pend = to_txinfo(idx);
-			struct xenvif *rvif = to_vif(idx);
-
-			copy_gop->source.domid = rvif->domid;
-			copy_gop->source.u.ref = src_pend->req.gref;
-			copy_gop->flags |= GNTCOPY_source_gref;
-		} else {
-			void *vaddr = page_address(page);
-			copy_gop->source.domid = DOMID_SELF;
-			copy_gop->source.u.gmfn = virt_to_mfn(vaddr);
-		}
-		copy_gop->source.offset = offset;
-		copy_gop->dest.domid = vif->domid;
-
-		copy_gop->dest.offset = npo->copy_off;
-		copy_gop->dest.u.ref = npo->copy_gref;
-		copy_gop->len = bytes;
-
-		npo->copy_off += bytes;
-		meta->size += bytes;
-
-		offset += bytes;
-		size -= bytes;
-
-		/* Leave a gap for the GSO descriptor. */
-		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
-			vif->rx.req_cons++;
-
-		*head = 0; /* There must be something in this buffer now. */
-
-	}
-}
-
-/*
- * Prepare an SKB to be transmitted to the frontend.
- *
- * This function is responsible for allocating grant operations, meta
- * structures, etc.
- *
- * It returns the number of meta structures consumed. The number of
- * ring slots used is always equal to the number of meta slots used
- * plus the number of GSO descriptors used. Currently, we use either
- * zero GSO descriptors (for non-GSO packets) or one descriptor (for
- * frontend-side LRO).
- */
-static int xenvif_gop_skb(struct sk_buff *skb,
-			  struct netrx_pending_operations *npo)
-{
-	struct xenvif *vif = netdev_priv(skb->dev);
-	int nr_frags = skb_shinfo(skb)->nr_frags;
-	int i;
-	struct xen_netif_rx_request *req;
-	struct xenvif_rx_meta *meta;
-	unsigned char *data;
-	int head = 1;
-	int old_meta_prod;
-
-	old_meta_prod = npo->meta_prod;
-
-	/* Set up a GSO prefix descriptor, if necessary */
-	if (skb_shinfo(skb)->gso_size && vif->gso_prefix) {
-		req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
-		meta = npo->meta + npo->meta_prod++;
-		meta->gso_size = skb_shinfo(skb)->gso_size;
-		meta->size = 0;
-		meta->id = req->id;
-	}
-
-	req = RING_GET_REQUEST(&vif->rx, vif->rx.req_cons++);
-	meta = npo->meta + npo->meta_prod++;
-
-	if (!vif->gso_prefix)
-		meta->gso_size = skb_shinfo(skb)->gso_size;
-	else
-		meta->gso_size = 0;
-
-	meta->size = 0;
-	meta->id = req->id;
-	npo->copy_off = 0;
-	npo->copy_gref = req->gref;
-
-	data = skb->data;
-	while (data < skb_tail_pointer(skb)) {
-		unsigned int offset = offset_in_page(data);
-		unsigned int len = PAGE_SIZE - offset;
-
-		if (data + len > skb_tail_pointer(skb))
-			len = skb_tail_pointer(skb) - data;
-
-		xenvif_gop_frag_copy(vif, skb, npo,
-				     virt_to_page(data), len, offset, &head);
-		data += len;
-	}
-
-	for (i = 0; i < nr_frags; i++) {
-		xenvif_gop_frag_copy(vif, skb, npo,
-				     skb_frag_page(&skb_shinfo(skb)->frags[i]),
-				     skb_frag_size(&skb_shinfo(skb)->frags[i]),
-				     skb_shinfo(skb)->frags[i].page_offset,
-				     &head);
-	}
-
-	return npo->meta_prod - old_meta_prod;
-}
-
-/*
- * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
- * used to set up the operations on the top of
- * netrx_pending_operations, which have since been done.  Check that
- * they didn't give any errors and advance over them.
- */
-static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
-			    struct netrx_pending_operations *npo)
-{
-	struct gnttab_copy     *copy_op;
-	int status = XEN_NETIF_RSP_OKAY;
-	int i;
-
-	for (i = 0; i < nr_meta_slots; i++) {
-		copy_op = npo->copy + npo->copy_cons++;
-		if (copy_op->status != GNTST_okay) {
-			netdev_dbg(vif->dev,
-				   "Bad status %d from copy to DOM%d.\n",
-				   copy_op->status, vif->domid);
-			status = XEN_NETIF_RSP_ERROR;
-		}
-	}
-
-	return status;
-}
-
-static void xenvif_add_frag_responses(struct xenvif *vif, int status,
-				      struct xenvif_rx_meta *meta,
-				      int nr_meta_slots)
-{
-	int i;
-	unsigned long offset;
-
-	/* No fragments used */
-	if (nr_meta_slots <= 1)
-		return;
-
-	nr_meta_slots--;
-
-	for (i = 0; i < nr_meta_slots; i++) {
-		int flags;
-		if (i == nr_meta_slots - 1)
-			flags = 0;
-		else
-			flags = XEN_NETRXF_more_data;
-
-		offset = 0;
-		make_rx_response(vif, meta[i].id, status, offset,
-				 meta[i].size, flags);
-	}
-}
-
-struct skb_cb_overlay {
-	int meta_slots_used;
-};
-
-static void xenvif_kick_thread(struct xenvif *vif)
+void xenvif_kick_thread(struct xenvif *vif)
 {
 	wake_up(&vif->wq);
 }
 
-void xenvif_rx_action(struct xenvif *vif)
-{
-	s8 status;
-	u16 flags;
-	struct xen_netif_rx_response *resp;
-	struct sk_buff_head rxq;
-	struct sk_buff *skb;
-	LIST_HEAD(notify);
-	int ret;
-	int nr_frags;
-	int count;
-	unsigned long offset;
-	struct skb_cb_overlay *sco;
-	int need_to_notify = 0;
-	struct xen_comms *comms = &vif->rx_comms;
-
-	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
-	struct xenvif_rx_meta *m = get_cpu_var(meta);
-
-	struct netrx_pending_operations npo = {
-		.copy  = gco,
-		.meta  = m,
-	};
-
-	if (gco == NULL || m == NULL) {
-		put_cpu_var(grant_copy_op);
-		put_cpu_var(meta);
-		printk(KERN_ALERT "netback: CPU %x scratch space is not usable,"
-		       " not doing any TX work for vif%u.%u\n",
-		       smp_processor_id(), vif->domid, vif->handle);
-		return;
-	}
-
-	skb_queue_head_init(&rxq);
-
-	count = 0;
-
-	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
-		vif = netdev_priv(skb->dev);
-		nr_frags = skb_shinfo(skb)->nr_frags;
-
-		sco = (struct skb_cb_overlay *)skb->cb;
-		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
-
-		count += nr_frags + 1;
-
-		__skb_queue_tail(&rxq, skb);
-
-		/* Filled the batch queue? */
-		if (count + MAX_SKB_FRAGS >=
-		    NETBK_RX_RING_SIZE(comms->nr_handles))
-			break;
-	}
-
-	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
-
-	if (!npo.copy_prod) {
-		put_cpu_var(grant_copy_op);
-		put_cpu_var(meta);
-		return;
-	}
-
-	BUG_ON(npo.copy_prod > (2 * NETBK_MAX_RX_RING_SIZE));
-	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
-					npo.copy_prod);
-	BUG_ON(ret != 0);
-
-	while ((skb = __skb_dequeue(&rxq)) != NULL) {
-		sco = (struct skb_cb_overlay *)skb->cb;
-
-		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
-			resp = RING_GET_RESPONSE(&vif->rx,
-						vif->rx.rsp_prod_pvt++);
-
-			resp->flags = XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
-
-			resp->offset = m[npo.meta_cons].gso_size;
-			resp->id = m[npo.meta_cons].id;
-			resp->status = sco->meta_slots_used;
-
-			npo.meta_cons++;
-			sco->meta_slots_used--;
-		}
-
-
-		vif->dev->stats.tx_bytes += skb->len;
-		vif->dev->stats.tx_packets++;
-
-		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
-
-		if (sco->meta_slots_used == 1)
-			flags = 0;
-		else
-			flags = XEN_NETRXF_more_data;
-
-		if (skb->ip_summed == CHECKSUM_PARTIAL) /* local packet? */
-			flags |= XEN_NETRXF_csum_blank | XEN_NETRXF_data_validated;
-		else if (skb->ip_summed == CHECKSUM_UNNECESSARY)
-			/* remote but checksummed. */
-			flags |= XEN_NETRXF_data_validated;
-
-		offset = 0;
-		resp = make_rx_response(vif, m[npo.meta_cons].id,
-					status, offset,
-					m[npo.meta_cons].size,
-					flags);
-
-		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
-			struct xen_netif_extra_info *gso =
-				(struct xen_netif_extra_info *)
-				RING_GET_RESPONSE(&vif->rx,
-						  vif->rx.rsp_prod_pvt++);
-
-			resp->flags |= XEN_NETRXF_extra_info;
-
-			gso->u.gso.size = m[npo.meta_cons].gso_size;
-			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
-			gso->u.gso.pad = 0;
-			gso->u.gso.features = 0;
-
-			gso->type = XEN_NETIF_EXTRA_TYPE_GSO;
-			gso->flags = 0;
-		}
-
-		xenvif_add_frag_responses(vif, status,
-					  m + npo.meta_cons + 1,
-					  sco->meta_slots_used);
-
-		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx, ret);
-		if (ret)
-			need_to_notify = 1;
-
-		xenvif_notify_tx_completion(vif);
-
-		npo.meta_cons += sco->meta_slots_used;
-		dev_kfree_skb(skb);
-	}
-
-	if (need_to_notify)
-		notify_remote_via_irq(vif->irq);
-
-	if (!skb_queue_empty(&vif->rx_queue))
-		xenvif_kick_thread(vif);
-
-	put_cpu_var(grant_copy_op);
-	put_cpu_var(meta);
-}
-
 void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
 {
 	skb_queue_tail(&vif->rx_queue, skb);
@@ -1383,29 +898,6 @@ static void make_tx_response(struct xenvif *vif,
 		notify_remote_via_irq(vif->irq);
 }
 
-static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
-					     u16      id,
-					     s8       st,
-					     u16      offset,
-					     u16      size,
-					     u16      flags)
-{
-	RING_IDX i = vif->rx.rsp_prod_pvt;
-	struct xen_netif_rx_response *resp;
-
-	resp = RING_GET_RESPONSE(&vif->rx, i);
-	resp->offset     = offset;
-	resp->flags      = flags;
-	resp->id         = id;
-	resp->status     = (s16)size;
-	if (st < 0)
-		resp->status = (s16)st;
-
-	vif->rx.rsp_prod_pvt = ++i;
-
-	return resp;
-}
-
 static inline int rx_work_todo(struct xenvif *vif)
 {
 	return !skb_queue_empty(&vif->rx_queue);
@@ -1507,8 +999,8 @@ int xenvif_kthread(void *data)
 		if (kthread_should_stop())
 			break;
 
-		if (rx_work_todo(vif))
-			xenvif_rx_action(vif);
+		if (rx_work_todo(vif) && vif->action)
+			vif->action(vif);
 	}
 
 	return 0;
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 79499fc..4067286 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -415,6 +415,7 @@ static int connect_rings(struct backend_info *be)
 	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
 	unsigned int  tx_ring_order;
 	unsigned int  rx_ring_order;
+	unsigned int  rx_protocol;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
 			    "event-channel", "%u", &evtchn, NULL);
@@ -510,6 +511,11 @@ static int connect_rings(struct backend_info *be)
 		}
 	}
 
+	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-protocol",
+			   "%u", &rx_protocol);
+	if (err < 0)
+		rx_protocol = XENVIF_MIN_RX_PROTOCOL;
+
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
 			   &rx_copy);
 	if (err == -ENOENT) {
@@ -559,7 +565,7 @@ static int connect_rings(struct backend_info *be)
 	err = xenvif_connect(vif,
 			     tx_ring_ref, (1U << tx_ring_order),
 			     rx_ring_ref, (1U << rx_ring_order),
-			     evtchn);
+			     evtchn, rx_protocol);
 	if (err) {
 		int i;
 		xenbus_dev_fatal(dev, err,
diff --git a/drivers/net/xen-netback/xenvif_rx_protocol0.c b/drivers/net/xen-netback/xenvif_rx_protocol0.c
new file mode 100644
index 0000000..3c95d65
--- /dev/null
+++ b/drivers/net/xen-netback/xenvif_rx_protocol0.c
@@ -0,0 +1,616 @@
+/*
+ * netback rx protocol 0 implementation.
+ *
+ * Copyright (c) 2012, Citrix Systems Inc.
+ *
+ * Author: Wei Liu <wei.liu2@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "common.h"
+
+#include <xen/events.h>
+#include <xen/interface/memory.h>
+
+#include <asm/xen/hypercall.h>
+#include <asm/xen/page.h>
+
+struct xenvif_rx_meta;
+
+#define MAX_BUFFER_OFFSET PAGE_SIZE
+
+DECLARE_PER_CPU(struct gnttab_copy *, grant_copy_op);
+DECLARE_PER_CPU(struct xenvif_rx_meta *, meta);
+
+struct netrx_pending_operations {
+	unsigned copy_prod, copy_cons;
+	unsigned meta_prod, meta_cons;
+	struct gnttab_copy *copy;
+	struct xenvif_rx_meta *meta;
+	int copy_off;
+	grant_ref_t copy_gref;
+};
+
+struct skb_cb_overlay {
+	int meta_slots_used;
+};
+
+static struct xen_netif_rx_response *make_rx_response(struct xenvif *vif,
+					     u16      id,
+					     s8       st,
+					     u16      offset,
+					     u16      size,
+					     u16      flags)
+{
+	RING_IDX i = vif->rx.p0.back.rsp_prod_pvt;
+	struct xen_netif_rx_response *resp;
+
+	resp = RING_GET_RESPONSE(&vif->rx.p0.back, i);
+	resp->offset     = offset;
+	resp->flags      = flags;
+	resp->id         = id;
+	resp->status     = (s16)size;
+	if (st < 0)
+		resp->status = (s16)st;
+
+	vif->rx.p0.back.rsp_prod_pvt = ++i;
+
+	return resp;
+}
+
+int xenvif_rx_ring_full(struct xenvif *vif)
+{
+	RING_IDX peek   = vif->rx.p0.rx_req_cons_peek;
+	RING_IDX needed = xenvif_max_required_rx_slots(vif);
+	struct xen_comms *comms = &vif->rx_comms;
+
+	return ((vif->rx.p0.back.sring->req_prod - peek) < needed) ||
+		((vif->rx.p0.back.rsp_prod_pvt +
+		  NETBK_RX_RING_SIZE(comms->nr_handles) - peek) < needed);
+}
+
+int xenvif_must_stop_queue(struct xenvif *vif)
+{
+	if (!xenvif_rx_ring_full(vif))
+		return 0;
+
+	vif->rx.p0.back.sring->req_event = vif->rx.p0.rx_req_cons_peek +
+		xenvif_max_required_rx_slots(vif);
+	mb(); /* request notification /then/ check the queue */
+
+	return xenvif_rx_ring_full(vif);
+}
+
+/*
+ * Returns true if we should start a new receive buffer instead of
+ * adding 'size' bytes to a buffer which currently contains 'offset'
+ * bytes.
+ */
+static bool start_new_rx_buffer(int offset, unsigned long size, int head)
+{
+	/* simple case: we have completely filled the current buffer. */
+	if (offset == MAX_BUFFER_OFFSET)
+		return true;
+
+	/*
+	 * complex case: start a fresh buffer if the current frag
+	 * would overflow the current buffer but only if:
+	 *     (i)   this frag would fit completely in the next buffer
+	 * and (ii)  there is already some data in the current buffer
+	 * and (iii) this is not the head buffer.
+	 *
+	 * Where:
+	 * - (i) stops us splitting a frag into two copies
+	 *   unless the frag is too large for a single buffer.
+	 * - (ii) stops us from leaving a buffer pointlessly empty.
+	 * - (iii) stops us leaving the first buffer
+	 *   empty. Strictly speaking this is already covered
+	 *   by (ii) but is explicitly checked because
+	 *   netfront relies on the first buffer being
+	 *   non-empty and can crash otherwise.
+	 *
+	 * This means we will effectively linearise small
+	 * frags but do not needlessly split large buffers
+	 * into multiple copies tend to give large frags their
+	 * own buffers as before.
+	 */
+	if ((offset + size > MAX_BUFFER_OFFSET) &&
+	    (size <= MAX_BUFFER_OFFSET) && offset && !head)
+		return true;
+
+	return false;
+}
+
+static struct xenvif_rx_meta *get_next_rx_buffer(struct xenvif *vif,
+				struct netrx_pending_operations *npo)
+{
+	struct xenvif_rx_meta *meta;
+	struct xen_netif_rx_request *req;
+
+	req = RING_GET_REQUEST(&vif->rx.p0.back, vif->rx.p0.back.req_cons++);
+
+	meta = npo->meta + npo->meta_prod++;
+	meta->gso_size = 0;
+	meta->size = 0;
+	meta->id = req->id;
+
+	npo->copy_off = 0;
+	npo->copy_gref = req->gref;
+
+	return meta;
+}
+
+/*
+ * Set up the grant operations for this fragment. If it's a flipping
+ * interface, we also set up the unmap request from here.
+ */
+static void xenvif_gop_frag_copy(struct xenvif *vif, struct sk_buff *skb,
+				struct netrx_pending_operations *npo,
+				struct page *page, unsigned long size,
+				unsigned long offset, int *head)
+{
+	struct gnttab_copy *copy_gop;
+	struct xenvif_rx_meta *meta;
+	/*
+	 * These variables are used iff get_page_ext returns true,
+	 * in which case they are guaranteed to be initialized.
+	 */
+	unsigned int uninitialized_var(idx);
+	int foreign = is_in_pool(page, &idx);
+	unsigned long bytes;
+
+	/* Data must not cross a page boundary. */
+	BUG_ON(size + offset > PAGE_SIZE);
+
+	meta = npo->meta + npo->meta_prod - 1;
+
+	while (size > 0) {
+		BUG_ON(npo->copy_off > MAX_BUFFER_OFFSET);
+
+		if (start_new_rx_buffer(npo->copy_off, size, *head)) {
+			/*
+			 * Netfront requires there to be some data in the head
+			 * buffer.
+			 */
+			BUG_ON(*head);
+
+			meta = get_next_rx_buffer(vif, npo);
+		}
+
+		bytes = size;
+		if (npo->copy_off + bytes > MAX_BUFFER_OFFSET)
+			bytes = MAX_BUFFER_OFFSET - npo->copy_off;
+
+		copy_gop = npo->copy + npo->copy_prod++;
+		copy_gop->flags = GNTCOPY_dest_gref;
+		if (foreign) {
+			struct pending_tx_info *src_pend = to_txinfo(idx);
+			struct xenvif *rvif = to_vif(idx);
+
+			copy_gop->source.domid = rvif->domid;
+			copy_gop->source.u.ref = src_pend->req.gref;
+			copy_gop->flags |= GNTCOPY_source_gref;
+		} else {
+			void *vaddr = page_address(page);
+			copy_gop->source.domid = DOMID_SELF;
+			copy_gop->source.u.gmfn = virt_to_mfn(vaddr);
+		}
+		copy_gop->source.offset = offset;
+		copy_gop->dest.domid = vif->domid;
+
+		copy_gop->dest.offset = npo->copy_off;
+		copy_gop->dest.u.ref = npo->copy_gref;
+		copy_gop->len = bytes;
+
+		npo->copy_off += bytes;
+		meta->size += bytes;
+
+		offset += bytes;
+		size -= bytes;
+
+		/* Leave a gap for the GSO descriptor. */
+		if (*head && skb_shinfo(skb)->gso_size && !vif->gso_prefix)
+			vif->rx.p0.back.req_cons++;
+
+		*head = 0; /* There must be something in this buffer now. */
+	}
+}
+
+/*
+ * Prepare an SKB to be transmitted to the frontend.
+ *
+ * This function is responsible for allocating grant operations, meta
+ * structures, etc.
+ *
+ * It returns the number of meta structures consumed. The number of
+ * ring slots used is always equal to the number of meta slots used
+ * plus the number of GSO descriptors used. Currently, we use either
+ * zero GSO descriptors (for non-GSO packets) or one descriptor (for
+ * frontend-side LRO).
+ */
+static int xenvif_gop_skb(struct sk_buff *skb,
+			 struct netrx_pending_operations *npo)
+{
+	struct xenvif *vif = netdev_priv(skb->dev);
+	int nr_frags = skb_shinfo(skb)->nr_frags;
+	int i;
+	struct xen_netif_rx_request *req;
+	struct xenvif_rx_meta *meta;
+	unsigned char *data;
+	int head = 1;
+	int old_meta_prod;
+
+	old_meta_prod = npo->meta_prod;
+
+	/* Set up a GSO prefix descriptor, if necessary */
+	if (skb_shinfo(skb)->gso_size && vif->gso_prefix) {
+		req = RING_GET_REQUEST(&vif->rx.p0.back,
+				       vif->rx.p0.back.req_cons++);
+		meta = npo->meta + npo->meta_prod++;
+		meta->gso_size = skb_shinfo(skb)->gso_size;
+		meta->size = 0;
+		meta->id = req->id;
+	}
+
+	req = RING_GET_REQUEST(&vif->rx.p0.back, vif->rx.p0.back.req_cons++);
+	meta = npo->meta + npo->meta_prod++;
+
+	if (!vif->gso_prefix)
+		meta->gso_size = skb_shinfo(skb)->gso_size;
+	else
+		meta->gso_size = 0;
+
+	meta->size = 0;
+	meta->id = req->id;
+	npo->copy_off = 0;
+	npo->copy_gref = req->gref;
+
+	data = skb->data;
+
+	while (data < skb_tail_pointer(skb)) {
+		unsigned int offset = offset_in_page(data);
+		unsigned int len = PAGE_SIZE - offset;
+
+		if (data + len > skb_tail_pointer(skb))
+			len = skb_tail_pointer(skb) - data;
+
+		xenvif_gop_frag_copy(vif, skb, npo,
+				    virt_to_page(data), len, offset, &head);
+		data += len;
+	}
+
+	for (i = 0; i < nr_frags; i++) {
+		xenvif_gop_frag_copy(vif, skb, npo,
+				    skb_frag_page(&skb_shinfo(skb)->frags[i]),
+				    skb_frag_size(&skb_shinfo(skb)->frags[i]),
+				    skb_shinfo(skb)->frags[i].page_offset,
+				    &head);
+	}
+
+	return npo->meta_prod - old_meta_prod;
+}
+
+/*
+ * This is a twin to xenvif_gop_skb.  Assume that xenvif_gop_skb was
+ * used to set up the operations on the top of
+ * netrx_pending_operations, which have since been done.  Check that
+ * they didn't give any errors and advance over them.
+ */
+static int xenvif_check_gop(struct xenvif *vif, int nr_meta_slots,
+			   struct netrx_pending_operations *npo)
+{
+	struct gnttab_copy     *copy_op;
+	int status = XEN_NETIF_RSP_OKAY;
+	int i;
+
+	for (i = 0; i < nr_meta_slots; i++) {
+		copy_op = npo->copy + npo->copy_cons++;
+		if (copy_op->status != GNTST_okay) {
+			netdev_dbg(vif->dev,
+				   "Bad status %d from copy to DOM%d.\n",
+				   copy_op->status, vif->domid);
+			status = XEN_NETIF_RSP_ERROR;
+		}
+	}
+
+	return status;
+}
+
+static void xenvif_add_frag_responses(struct xenvif *vif, int status,
+				     struct xenvif_rx_meta *meta,
+				     int nr_meta_slots)
+{
+	int i;
+	unsigned long offset;
+
+	/* No fragments used */
+	if (nr_meta_slots <= 1)
+		return;
+
+	nr_meta_slots--;
+
+	for (i = 0; i < nr_meta_slots; i++) {
+		int flags;
+		if (i == nr_meta_slots - 1)
+			flags = 0;
+		else
+			flags = XEN_NETRXF_more_data;
+
+		offset = 0;
+		make_rx_response(vif, meta[i].id, status, offset,
+				 meta[i].size, flags);
+	}
+}
+
+/*
+ * Figure out how many ring slots we're going to need to send @skb to
+ * the guest. This function is essentially a dry run of
+ * xenvif_gop_frag_copy.
+ */
+unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
+{
+	unsigned int count;
+	int i, copy_off;
+
+	count = DIV_ROUND_UP(
+			offset_in_page(skb->data)+skb_headlen(skb), PAGE_SIZE);
+
+	copy_off = skb_headlen(skb) % PAGE_SIZE;
+
+	if (skb_shinfo(skb)->gso_size)
+		count++;
+
+	for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+		unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
+		unsigned long bytes;
+		while (size > 0) {
+			BUG_ON(copy_off > MAX_BUFFER_OFFSET);
+
+			if (start_new_rx_buffer(copy_off, size, 0)) {
+				count++;
+				copy_off = 0;
+			}
+
+			bytes = size;
+			if (copy_off + bytes > MAX_BUFFER_OFFSET)
+				bytes = MAX_BUFFER_OFFSET - copy_off;
+
+			copy_off += bytes;
+			size -= bytes;
+		}
+	}
+	return count;
+}
+
+
+void xenvif_rx_action(struct xenvif *vif)
+{
+	s8 status;
+	u16 flags;
+	struct xen_netif_rx_response *resp;
+	struct sk_buff_head rxq;
+	struct sk_buff *skb;
+	LIST_HEAD(notify);
+	int ret;
+	int nr_frags;
+	int count;
+	unsigned long offset;
+	struct skb_cb_overlay *sco;
+	int need_to_notify = 0;
+	struct xen_comms *comms = &vif->rx_comms;
+
+	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
+	struct xenvif_rx_meta *m = get_cpu_var(meta);
+
+	struct netrx_pending_operations npo = {
+		.copy  = gco,
+		.meta  = m,
+	};
+
+	if (gco == NULL || m == NULL) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
+		printk(KERN_ALERT "netback: CPU %x scratch space is not usable,"
+		       " not doing any TX work for vif%u.%u\n",
+		       smp_processor_id(), vif->domid, vif->handle);
+		return;
+	}
+
+	skb_queue_head_init(&rxq);
+
+	count = 0;
+
+	while ((skb = skb_dequeue(&vif->rx_queue)) != NULL) {
+		vif = netdev_priv(skb->dev);
+		nr_frags = skb_shinfo(skb)->nr_frags;
+
+		sco = (struct skb_cb_overlay *)skb->cb;
+		sco->meta_slots_used = xenvif_gop_skb(skb, &npo);
+
+		count += nr_frags + 1;
+
+		__skb_queue_tail(&rxq, skb);
+
+		/* Filled the batch queue? */
+		if (count + MAX_SKB_FRAGS >=
+		    NETBK_RX_RING_SIZE(comms->nr_handles))
+			break;
+	}
+
+	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
+
+	if (!npo.copy_prod) {
+		put_cpu_var(grant_copy_op);
+		put_cpu_var(meta);
+		return;
+	}
+
+	BUG_ON(npo.copy_prod > (2 * NETBK_MAX_RX_RING_SIZE));
+	ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, gco,
+					npo.copy_prod);
+	BUG_ON(ret != 0);
+
+	while ((skb = __skb_dequeue(&rxq)) != NULL) {
+		sco = (struct skb_cb_overlay *)skb->cb;
+
+		if (m[npo.meta_cons].gso_size && vif->gso_prefix) {
+			resp = RING_GET_RESPONSE(&vif->rx.p0.back,
+					 vif->rx.p0.back.rsp_prod_pvt++);
+
+			resp->flags =
+				XEN_NETRXF_gso_prefix | XEN_NETRXF_more_data;
+
+			resp->offset = m[npo.meta_cons].gso_size;
+			resp->id = m[npo.meta_cons].id;
+			resp->status = sco->meta_slots_used;
+
+			npo.meta_cons++;
+			sco->meta_slots_used--;
+		}
+
+
+		vif->dev->stats.tx_bytes += skb->len;
+		vif->dev->stats.tx_packets++;
+
+		status = xenvif_check_gop(vif, sco->meta_slots_used, &npo);
+
+		if (sco->meta_slots_used == 1)
+			flags = 0;
+		else
+			flags = XEN_NETRXF_more_data;
+
+		if (skb->ip_summed == CHECKSUM_PARTIAL) /* local packet? */
+			flags |= XEN_NETRXF_csum_blank |
+				XEN_NETRXF_data_validated;
+		else if (skb->ip_summed == CHECKSUM_UNNECESSARY)
+			/* remote but checksummed. */
+			flags |= XEN_NETRXF_data_validated;
+
+		offset = 0;
+		resp = make_rx_response(vif, m[npo.meta_cons].id,
+					status, offset,
+					m[npo.meta_cons].size,
+					flags);
+
+		if (m[npo.meta_cons].gso_size && !vif->gso_prefix) {
+			struct xen_netif_extra_info *gso =
+				(struct xen_netif_extra_info *)
+				RING_GET_RESPONSE(&vif->rx.p0.back,
+					  vif->rx.p0.back.rsp_prod_pvt++);
+
+			resp->flags |= XEN_NETRXF_extra_info;
+
+			gso->u.gso.size = m[npo.meta_cons].gso_size;
+			gso->u.gso.type = XEN_NETIF_GSO_TYPE_TCPV4;
+			gso->u.gso.pad = 0;
+			gso->u.gso.features = 0;
+
+			gso->type = XEN_NETIF_EXTRA_TYPE_GSO;
+			gso->flags = 0;
+		}
+
+		xenvif_add_frag_responses(vif, status,
+					  m + npo.meta_cons + 1,
+					  sco->meta_slots_used);
+
+		RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->rx.p0.back, ret);
+		if (ret)
+			need_to_notify = 1;
+
+		if (netif_queue_stopped(vif->dev) &&
+		    xenvif_schedulable(vif) &&
+		    !xenvif_rx_ring_full(vif))
+			netif_wake_queue(vif->dev);
+
+		npo.meta_cons += sco->meta_slots_used;
+		dev_kfree_skb(skb);
+	}
+
+	if (need_to_notify)
+		notify_remote_via_irq(vif->irq);
+
+	if (!skb_queue_empty(&vif->rx_queue))
+		xenvif_kick_thread(vif);
+
+	put_cpu_var(grant_copy_op);
+	put_cpu_var(meta);
+}
+
+int xenvif_p0_setup(struct xenvif *vif)
+{
+	struct xenvif_rx_protocol0 *p0 = &vif->rx.p0;
+	struct xen_netif_rx_sring *sring;
+
+	p0->rx_req_cons_peek = 0;
+
+	sring = (struct xen_netif_rx_sring *)vif->rx_comms.ring_area->addr;
+	BACK_RING_INIT(&p0->back, sring, PAGE_SIZE * vif->rx_comms.nr_handles);
+
+	return 0;
+}
+
+void xenvif_p0_start_xmit(struct xenvif *vif, struct sk_buff *skb)
+{
+	struct net_device *dev = vif->dev;
+
+	/* Drop the packet if there is no carrier */
+	if (unlikely(!xenvif_schedulable(vif)))
+		goto drop;
+
+	/* Drop the packet if the target domain has no receive buffers. */
+	if (unlikely(xenvif_rx_ring_full(vif)))
+		goto drop;
+
+	/* Reserve ring slots for the worst-case number of fragments. */
+	vif->rx.p0.rx_req_cons_peek += xenvif_count_skb_slots(vif, skb);
+
+	if (vif->can_queue && xenvif_must_stop_queue(vif))
+		netif_stop_queue(dev);
+
+	xenvif_queue_tx_skb(vif, skb);
+
+	return;
+
+drop:
+	vif->dev->stats.tx_dropped++;
+	dev_kfree_skb(skb);
+}
+
+void xenvif_p0_teardown(struct xenvif *vif)
+{
+	/* Nothing to teardown, relax */
+}
+
+void xenvif_p0_event(struct xenvif *vif)
+{
+	if (!xenvif_rx_ring_full(vif))
+		netif_wake_queue(vif->dev);
+}
+
+void xenvif_p0_action(struct xenvif *vif)
+{
+	xenvif_rx_action(vif);
+}
diff --git a/drivers/net/xen-netback/xenvif_rx_protocol0.h b/drivers/net/xen-netback/xenvif_rx_protocol0.h
new file mode 100644
index 0000000..aceb2ec
--- /dev/null
+++ b/drivers/net/xen-netback/xenvif_rx_protocol0.h
@@ -0,0 +1,53 @@
+/*
+ * netback rx protocol 0 implementation.
+ *
+ * Copyright (c) 2012, Citrix Systems Inc.
+ *
+ * Author: Wei Liu <wei.liu2@citrix.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU 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 __XENVIF_RX_PROTOCOL0_H__
+#define __XENVIF_RX_PROTOCOL0_H__
+
+struct xenvif_rx_protocol0 {
+	struct xen_netif_rx_back_ring back;
+	/*
+	 * Allow xenvif_start_xmit() to peek ahead in the rx request
+	 * ring.  This is a prediction of what rx_req_cons will be
+	 * once all queued skbs are put on the ring.
+	 */
+	RING_IDX rx_req_cons_peek;
+};
+
+
+int  xenvif_p0_setup(struct xenvif *vif);
+void xenvif_p0_start_xmit(struct xenvif *vif, struct sk_buff *skb);
+void xenvif_p0_teardown(struct xenvif *vif);
+void xenvif_p0_event(struct xenvif *vif);
+void xenvif_p0_action(struct xenvif *vif);
+
+#endif /* __XENVIF_RX_PROTOCOL0_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 Jan 30 14:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUb-0007Wg-0b; Mon, 30 Jan 2012 14:46:01 +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 1RrsUY-0007MP-5P
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327934746!12887947!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27245 invoked from network); 30 Jan 2012 14:45:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413504"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 09:45:50 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTl029057;
	Mon, 30 Jan 2012 06:45:49 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:32 +0000
Message-ID: <1327934734-8908-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 14/16] netback: split event channels
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Originally, netback and netfront only use one event channel to do tx /
rx notification. This may cause unnecessary wake-up of NAPI / kthread.

When guest tx is completed, netback will only notify tx_irq.

Also modify xenvif_protocol0 to reflect this change. Rx protocol
only notifies rx_irq.

If split-event-channels feature is not activated, rx_irq = tx_irq, so
RX protocol will just work as expected.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h              |    9 ++-
 drivers/net/xen-netback/interface.c           |   90 ++++++++++++++++++++-----
 drivers/net/xen-netback/netback.c             |    2 +-
 drivers/net/xen-netback/xenbus.c              |   52 ++++++++++++---
 drivers/net/xen-netback/xenvif_rx_protocol0.c |    2 +-
 5 files changed, 123 insertions(+), 32 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index f3d95b3..376f0bf 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -100,8 +100,10 @@ struct xenvif {
 
 	u8               fe_dev_addr[6];
 
-	/* Physical parameters of the comms window. */
-	unsigned int     irq;
+	/* when split_irq == 0, only use tx_irq */
+	int              split_irq;
+	unsigned int     tx_irq;
+	unsigned int     rx_irq;
 
 	/* The shared tx ring and index. */
 	struct xen_netif_tx_back_ring tx;
@@ -162,7 +164,8 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
-		   unsigned int evtchn, unsigned int rx_protocol);
+		   unsigned int evtchn[], int split_evtchn,
+		   unsigned int rx_protocol);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 0f05f03..afccd5d 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -46,15 +46,31 @@ int xenvif_schedulable(struct xenvif *vif)
 	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
 }
 
-static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+static irqreturn_t xenvif_tx_interrupt(int irq, void *dev_id)
+{
+	struct xenvif *vif = dev_id;
+
+	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
+		napi_schedule(&vif->napi);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
 	if (xenvif_schedulable(vif) && vif->event != NULL)
 		vif->event(vif);
 
-	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
-		napi_schedule(&vif->napi);
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+{
+	xenvif_tx_interrupt(0, dev_id);
+
+	xenvif_rx_interrupt(0, dev_id);
 
 	return IRQ_HANDLED;
 }
@@ -118,14 +134,24 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
-	enable_irq(vif->irq);
+	if (!vif->split_irq)
+		enable_irq(vif->tx_irq);
+	else {
+		enable_irq(vif->tx_irq);
+		enable_irq(vif->rx_irq);
+	}
 	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
 	napi_disable(&vif->napi);
-	disable_irq(vif->irq);
+	if (!vif->split_irq)
+		disable_irq(vif->tx_irq);
+	else {
+		disable_irq(vif->tx_irq);
+		disable_irq(vif->rx_irq);
+	}
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -308,13 +334,14 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
-		   unsigned int evtchn, unsigned int rx_protocol)
+		   unsigned int evtchn[], int split_evtchn,
+		   unsigned int rx_protocol)
 {
 	int err = -ENOMEM;
 	struct xen_netif_tx_sring *txs;
 
 	/* Already connected through? */
-	if (vif->irq)
+	if (vif->tx_irq)
 		return 0;
 
 	__module_get(THIS_MODULE);
@@ -345,13 +372,35 @@ int xenvif_connect(struct xenvif *vif,
 	if (vif->setup(vif))
 		goto err_rx_unmap;
 
-	err = bind_interdomain_evtchn_to_irqhandler(
-		vif->domid, evtchn, xenvif_interrupt, 0,
-		vif->dev->name, vif);
-	if (err < 0)
-		goto err_rx_unmap;
-	vif->irq = err;
-	disable_irq(vif->irq);
+	if (!split_evtchn) {
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, evtchn[0], xenvif_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = vif->rx_irq = err;
+		disable_irq(vif->tx_irq);
+		vif->split_irq = 0;
+	} else {
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, evtchn[0], xenvif_tx_interrupt,
+			0, vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = err;
+		disable_irq(vif->tx_irq);
+
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, evtchn[1], xenvif_rx_interrupt,
+			0, vif->dev->name, vif);
+		if (err < 0) {
+			unbind_from_irqhandler(vif->tx_irq, vif);
+			goto err_rx_unmap;
+		}
+		vif->rx_irq = err;
+		disable_irq(vif->rx_irq);
+		vif->split_irq = 1;
+	}
 
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xenvif_kthread,
@@ -376,7 +425,12 @@ int xenvif_connect(struct xenvif *vif,
 
 	return 0;
 err_unbind:
-	unbind_from_irqhandler(vif->irq, vif);
+	if (!vif->split_irq)
+		unbind_from_irqhandler(vif->tx_irq, vif);
+	else {
+		unbind_from_irqhandler(vif->tx_irq, vif);
+		unbind_from_irqhandler(vif->rx_irq, vif);
+	}
 err_rx_unmap:
 	xenvif_unmap_frontend_rings(&vif->rx_comms);
 err_tx_unmap:
@@ -406,10 +460,12 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	del_timer_sync(&vif->credit_timeout);
 
-	if (vif->irq) {
-		unbind_from_irqhandler(vif->irq, vif);
+	if (vif->tx_irq) {
+		unbind_from_irqhandler(vif->tx_irq, vif);
 		need_module_put = 1;
 	}
+	if (vif->split_irq && vif->rx_irq)
+		unbind_from_irqhandler(vif->rx_irq, vif);
 
 	unregister_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2ea43d4..f4ec292 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -895,7 +895,7 @@ static void make_tx_response(struct xenvif *vif,
 	vif->tx.rsp_prod_pvt = ++i;
 	RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->tx, notify);
 	if (notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->tx_irq);
 }
 
 static inline int rx_work_todo(struct xenvif *vif)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 4067286..c5a3b27 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -131,6 +131,14 @@ static int netback_probe(struct xenbus_device *dev,
 			goto abort_transaction;
 		}
 
+		err = xenbus_printf(xbt, dev->nodename,
+				    "split-event-channels",
+				    "%u", 1);
+		if (err) {
+			message = "writing split-event-channels";
+			goto abort_transaction;
+		}
+
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
 
@@ -408,7 +416,7 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned int evtchn, rx_copy;
+	unsigned int evtchn[2], split_evtchn, rx_copy;
 	int err;
 	int val;
 	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
@@ -418,12 +426,31 @@ static int connect_rings(struct backend_info *be)
 	unsigned int  rx_protocol;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "event-channel", "%u", &evtchn, NULL);
+			    "event-channel", "%u", &evtchn[0], NULL);
 	if (err) {
-		xenbus_dev_fatal(dev, err,
-				 "reading %s/event-channel",
-				 dev->otherend);
-		return err;
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-tx", "%u", &evtchn[0],
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel-tx",
+					 dev->otherend);
+			return err;
+		}
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-rx", "%u", &evtchn[1],
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel-rx",
+					 dev->otherend);
+			return err;
+		}
+		split_evtchn = 1;
+		dev_info(&dev->dev, "split event channels\n");
+	} else {
+		split_evtchn = 0;
+		dev_info(&dev->dev, "single event channel\n");
 	}
 
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
@@ -565,12 +592,17 @@ static int connect_rings(struct backend_info *be)
 	err = xenvif_connect(vif,
 			     tx_ring_ref, (1U << tx_ring_order),
 			     rx_ring_ref, (1U << rx_ring_order),
-			     evtchn, rx_protocol);
+			     evtchn, split_evtchn, rx_protocol);
 	if (err) {
 		int i;
-		xenbus_dev_fatal(dev, err,
-				 "binding port %u",
-				 evtchn);
+		if (!split_evtchn)
+			xenbus_dev_fatal(dev, err,
+					 "binding port %u",
+					 evtchn[0]);
+		else
+			xenbus_dev_fatal(dev, err,
+					 "binding tx port %u, rx port %u",
+					 evtchn[0], evtchn[1]);
 		for (i = 0; i < (1U << tx_ring_order); i++)
 			xenbus_dev_fatal(dev, err,
 					 "mapping tx ring handle: %lu",
diff --git a/drivers/net/xen-netback/xenvif_rx_protocol0.c b/drivers/net/xen-netback/xenvif_rx_protocol0.c
index 3c95d65..6959a1d 100644
--- a/drivers/net/xen-netback/xenvif_rx_protocol0.c
+++ b/drivers/net/xen-netback/xenvif_rx_protocol0.c
@@ -550,7 +550,7 @@ void xenvif_rx_action(struct xenvif *vif)
 	}
 
 	if (need_to_notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->rx_irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
 		xenvif_kick_thread(vif);
-- 
1.7.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 Jan 30 14:46:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:46:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUb-0007Wg-0b; Mon, 30 Jan 2012 14:46:01 +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 1RrsUY-0007MP-5P
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:45:58 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1327934746!12887947!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27245 invoked from network); 30 Jan 2012 14:45:51 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21413504"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45:51 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 09:45:50 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTl029057;
	Mon, 30 Jan 2012 06:45:49 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:32 +0000
Message-ID: <1327934734-8908-15-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 14/16] netback: split event channels
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Originally, netback and netfront only use one event channel to do tx /
rx notification. This may cause unnecessary wake-up of NAPI / kthread.

When guest tx is completed, netback will only notify tx_irq.

Also modify xenvif_protocol0 to reflect this change. Rx protocol
only notifies rx_irq.

If split-event-channels feature is not activated, rx_irq = tx_irq, so
RX protocol will just work as expected.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netback/common.h              |    9 ++-
 drivers/net/xen-netback/interface.c           |   90 ++++++++++++++++++++-----
 drivers/net/xen-netback/netback.c             |    2 +-
 drivers/net/xen-netback/xenbus.c              |   52 ++++++++++++---
 drivers/net/xen-netback/xenvif_rx_protocol0.c |    2 +-
 5 files changed, 123 insertions(+), 32 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index f3d95b3..376f0bf 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -100,8 +100,10 @@ struct xenvif {
 
 	u8               fe_dev_addr[6];
 
-	/* Physical parameters of the comms window. */
-	unsigned int     irq;
+	/* when split_irq == 0, only use tx_irq */
+	int              split_irq;
+	unsigned int     tx_irq;
+	unsigned int     rx_irq;
 
 	/* The shared tx ring and index. */
 	struct xen_netif_tx_back_ring tx;
@@ -162,7 +164,8 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
-		   unsigned int evtchn, unsigned int rx_protocol);
+		   unsigned int evtchn[], int split_evtchn,
+		   unsigned int rx_protocol);
 void xenvif_disconnect(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 0f05f03..afccd5d 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -46,15 +46,31 @@ int xenvif_schedulable(struct xenvif *vif)
 	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
 }
 
-static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+static irqreturn_t xenvif_tx_interrupt(int irq, void *dev_id)
+{
+	struct xenvif *vif = dev_id;
+
+	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
+		napi_schedule(&vif->napi);
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
 {
 	struct xenvif *vif = dev_id;
 
 	if (xenvif_schedulable(vif) && vif->event != NULL)
 		vif->event(vif);
 
-	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
-		napi_schedule(&vif->napi);
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
+{
+	xenvif_tx_interrupt(0, dev_id);
+
+	xenvif_rx_interrupt(0, dev_id);
 
 	return IRQ_HANDLED;
 }
@@ -118,14 +134,24 @@ static struct net_device_stats *xenvif_get_stats(struct net_device *dev)
 static void xenvif_up(struct xenvif *vif)
 {
 	napi_enable(&vif->napi);
-	enable_irq(vif->irq);
+	if (!vif->split_irq)
+		enable_irq(vif->tx_irq);
+	else {
+		enable_irq(vif->tx_irq);
+		enable_irq(vif->rx_irq);
+	}
 	xenvif_check_rx_xenvif(vif);
 }
 
 static void xenvif_down(struct xenvif *vif)
 {
 	napi_disable(&vif->napi);
-	disable_irq(vif->irq);
+	if (!vif->split_irq)
+		disable_irq(vif->tx_irq);
+	else {
+		disable_irq(vif->tx_irq);
+		disable_irq(vif->rx_irq);
+	}
 }
 
 static int xenvif_open(struct net_device *dev)
@@ -308,13 +334,14 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
 int xenvif_connect(struct xenvif *vif,
 		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
 		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
-		   unsigned int evtchn, unsigned int rx_protocol)
+		   unsigned int evtchn[], int split_evtchn,
+		   unsigned int rx_protocol)
 {
 	int err = -ENOMEM;
 	struct xen_netif_tx_sring *txs;
 
 	/* Already connected through? */
-	if (vif->irq)
+	if (vif->tx_irq)
 		return 0;
 
 	__module_get(THIS_MODULE);
@@ -345,13 +372,35 @@ int xenvif_connect(struct xenvif *vif,
 	if (vif->setup(vif))
 		goto err_rx_unmap;
 
-	err = bind_interdomain_evtchn_to_irqhandler(
-		vif->domid, evtchn, xenvif_interrupt, 0,
-		vif->dev->name, vif);
-	if (err < 0)
-		goto err_rx_unmap;
-	vif->irq = err;
-	disable_irq(vif->irq);
+	if (!split_evtchn) {
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, evtchn[0], xenvif_interrupt, 0,
+			vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = vif->rx_irq = err;
+		disable_irq(vif->tx_irq);
+		vif->split_irq = 0;
+	} else {
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, evtchn[0], xenvif_tx_interrupt,
+			0, vif->dev->name, vif);
+		if (err < 0)
+			goto err_rx_unmap;
+		vif->tx_irq = err;
+		disable_irq(vif->tx_irq);
+
+		err = bind_interdomain_evtchn_to_irqhandler(
+			vif->domid, evtchn[1], xenvif_rx_interrupt,
+			0, vif->dev->name, vif);
+		if (err < 0) {
+			unbind_from_irqhandler(vif->tx_irq, vif);
+			goto err_rx_unmap;
+		}
+		vif->rx_irq = err;
+		disable_irq(vif->rx_irq);
+		vif->split_irq = 1;
+	}
 
 	init_waitqueue_head(&vif->wq);
 	vif->task = kthread_create(xenvif_kthread,
@@ -376,7 +425,12 @@ int xenvif_connect(struct xenvif *vif,
 
 	return 0;
 err_unbind:
-	unbind_from_irqhandler(vif->irq, vif);
+	if (!vif->split_irq)
+		unbind_from_irqhandler(vif->tx_irq, vif);
+	else {
+		unbind_from_irqhandler(vif->tx_irq, vif);
+		unbind_from_irqhandler(vif->rx_irq, vif);
+	}
 err_rx_unmap:
 	xenvif_unmap_frontend_rings(&vif->rx_comms);
 err_tx_unmap:
@@ -406,10 +460,12 @@ void xenvif_disconnect(struct xenvif *vif)
 
 	del_timer_sync(&vif->credit_timeout);
 
-	if (vif->irq) {
-		unbind_from_irqhandler(vif->irq, vif);
+	if (vif->tx_irq) {
+		unbind_from_irqhandler(vif->tx_irq, vif);
 		need_module_put = 1;
 	}
+	if (vif->split_irq && vif->rx_irq)
+		unbind_from_irqhandler(vif->rx_irq, vif);
 
 	unregister_netdev(vif->dev);
 
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 2ea43d4..f4ec292 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -895,7 +895,7 @@ static void make_tx_response(struct xenvif *vif,
 	vif->tx.rsp_prod_pvt = ++i;
 	RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&vif->tx, notify);
 	if (notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->tx_irq);
 }
 
 static inline int rx_work_todo(struct xenvif *vif)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 4067286..c5a3b27 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -131,6 +131,14 @@ static int netback_probe(struct xenbus_device *dev,
 			goto abort_transaction;
 		}
 
+		err = xenbus_printf(xbt, dev->nodename,
+				    "split-event-channels",
+				    "%u", 1);
+		if (err) {
+			message = "writing split-event-channels";
+			goto abort_transaction;
+		}
+
 		err = xenbus_transaction_end(xbt, 0);
 	} while (err == -EAGAIN);
 
@@ -408,7 +416,7 @@ static int connect_rings(struct backend_info *be)
 {
 	struct xenvif *vif = be->vif;
 	struct xenbus_device *dev = be->dev;
-	unsigned int evtchn, rx_copy;
+	unsigned int evtchn[2], split_evtchn, rx_copy;
 	int err;
 	int val;
 	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
@@ -418,12 +426,31 @@ static int connect_rings(struct backend_info *be)
 	unsigned int  rx_protocol;
 
 	err = xenbus_gather(XBT_NIL, dev->otherend,
-			    "event-channel", "%u", &evtchn, NULL);
+			    "event-channel", "%u", &evtchn[0], NULL);
 	if (err) {
-		xenbus_dev_fatal(dev, err,
-				 "reading %s/event-channel",
-				 dev->otherend);
-		return err;
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-tx", "%u", &evtchn[0],
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel-tx",
+					 dev->otherend);
+			return err;
+		}
+		err = xenbus_gather(XBT_NIL, dev->otherend,
+				    "event-channel-rx", "%u", &evtchn[1],
+				    NULL);
+		if (err) {
+			xenbus_dev_fatal(dev, err,
+					 "reading %s/event-channel-rx",
+					 dev->otherend);
+			return err;
+		}
+		split_evtchn = 1;
+		dev_info(&dev->dev, "split event channels\n");
+	} else {
+		split_evtchn = 0;
+		dev_info(&dev->dev, "single event channel\n");
 	}
 
 	err = xenbus_scanf(XBT_NIL, dev->otherend, "tx-ring-order", "%u",
@@ -565,12 +592,17 @@ static int connect_rings(struct backend_info *be)
 	err = xenvif_connect(vif,
 			     tx_ring_ref, (1U << tx_ring_order),
 			     rx_ring_ref, (1U << rx_ring_order),
-			     evtchn, rx_protocol);
+			     evtchn, split_evtchn, rx_protocol);
 	if (err) {
 		int i;
-		xenbus_dev_fatal(dev, err,
-				 "binding port %u",
-				 evtchn);
+		if (!split_evtchn)
+			xenbus_dev_fatal(dev, err,
+					 "binding port %u",
+					 evtchn[0]);
+		else
+			xenbus_dev_fatal(dev, err,
+					 "binding tx port %u, rx port %u",
+					 evtchn[0], evtchn[1]);
 		for (i = 0; i < (1U << tx_ring_order); i++)
 			xenbus_dev_fatal(dev, err,
 					 "mapping tx ring handle: %lu",
diff --git a/drivers/net/xen-netback/xenvif_rx_protocol0.c b/drivers/net/xen-netback/xenvif_rx_protocol0.c
index 3c95d65..6959a1d 100644
--- a/drivers/net/xen-netback/xenvif_rx_protocol0.c
+++ b/drivers/net/xen-netback/xenvif_rx_protocol0.c
@@ -550,7 +550,7 @@ void xenvif_rx_action(struct xenvif *vif)
 	}
 
 	if (need_to_notify)
-		notify_remote_via_irq(vif->irq);
+		notify_remote_via_irq(vif->rx_irq);
 
 	if (!skb_queue_empty(&vif->rx_queue))
 		xenvif_kick_thread(vif);
-- 
1.7.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 Jan 30 14:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUd-0007ZI-5X; Mon, 30 Jan 2012 14:46:03 +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 1RrsUb-0007Op-8J
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:46:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!10
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 674 invoked from network); 30 Jan 2012 14:45:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614416"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 09:45:53 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTn029057;
	Mon, 30 Jan 2012 06:45:51 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:34 +0000
Message-ID: <1327934734-8908-17-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 16/16] netfront: split event channels
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If this feature is not activated, rx_irq = tx_irq. See corresponding
netback change log for details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  147 ++++++++++++++++++++++++++++++++++----------
 1 files changed, 115 insertions(+), 32 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 32ec212..72c0429 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -98,7 +98,9 @@ struct netfront_info {
 
 	unsigned long rx_gso_checksum_fixup;
 
-	unsigned int evtchn;
+	unsigned int split_evtchn;
+	unsigned int tx_evtchn, rx_evtchn;
+	unsigned int tx_irq, rx_irq;
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
@@ -344,7 +346,7 @@ no_skb:
  push:
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->rx_irq);
 }
 
 static int xennet_open(struct net_device *dev)
@@ -577,7 +579,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->tx_irq);
 
 	u64_stats_update_begin(&stats->syncp);
 	stats->tx_bytes += skb->len;
@@ -1242,22 +1244,35 @@ static int xennet_set_features(struct net_device *dev, u32 features)
 	return 0;
 }
 
-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+static irqreturn_t xennet_tx_interrupt(int irq, void *dev_id)
 {
-	struct net_device *dev = dev_id;
-	struct netfront_info *np = netdev_priv(dev);
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
 	unsigned long flags;
 
 	spin_lock_irqsave(&np->tx_lock, flags);
+	xennet_tx_buf_gc(dev);
+	spin_unlock_irqrestore(&np->tx_lock, flags);
 
-	if (likely(netif_carrier_ok(dev))) {
-		xennet_tx_buf_gc(dev);
-		/* Under tx_lock: protects access to rx shared-ring indexes. */
-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
-			napi_schedule(&np->napi);
-	}
+	return IRQ_HANDLED;
+}
 
-	spin_unlock_irqrestore(&np->tx_lock, flags);
+static irqreturn_t xennet_rx_interrupt(int irq, void *dev_id)
+{
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
+
+	if (likely(netif_carrier_ok(dev)) &&
+	    RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
+		napi_schedule(&np->napi);
+
+	return IRQ_HANDLED;
+}
+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+{
+	xennet_tx_interrupt(0, dev_id);
+
+	xennet_rx_interrupt(0, dev_id);
 
 	return IRQ_HANDLED;
 }
@@ -1436,9 +1451,14 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 	spin_unlock_irq(&info->tx_lock);
 	spin_unlock_bh(&info->rx_lock);
 
-	if (info->netdev->irq)
-		unbind_from_irqhandler(info->netdev->irq, info->netdev);
-	info->evtchn = info->netdev->irq = 0;
+	if (info->tx_irq && (info->tx_irq == info->rx_irq))
+		unbind_from_irqhandler(info->tx_irq, info);
+	if (info->tx_irq && (info->tx_irq != info->rx_irq)) {
+		unbind_from_irqhandler(info->tx_irq, info);
+		unbind_from_irqhandler(info->rx_irq, info);
+	}
+	info->tx_evtchn = info->tx_irq = 0;
+	info->rx_evtchn = info->rx_irq = 0;
 
 	for (i = 0; i < info->tx_ring_pages; i++) {
 		int ref = info->tx_ring_ref[i];
@@ -1507,6 +1527,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	int err;
 	struct net_device *netdev = info->netdev;
 	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
+	unsigned int split_evtchn;
 	int i, j;
 
 	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
@@ -1515,7 +1536,6 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	}
 	info->rx.sring = NULL;
 	info->tx.sring = NULL;
-	netdev->irq = 0;
 
 	err = xen_net_read_mac(dev, netdev->dev_addr);
 	if (err) {
@@ -1524,6 +1544,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	}
 
 	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "split-event-channels", "%u",
+			   &split_evtchn);
+	if (err < 0)
+		split_evtchn = 0;
+
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
 			   "max-tx-ring-page-order", "%u",
 			   &max_tx_ring_page_order);
 	if (err < 0) {
@@ -1589,20 +1615,59 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		info->rx_ring_ref[j] = err;
 	}
 
-	err = xenbus_alloc_evtchn(dev, &info->evtchn);
-	if (err)
-		goto alloc_evtchn_fail;
+	if (!split_evtchn) {
+		err = xenbus_alloc_evtchn(dev, &info->tx_evtchn);
+		if (err)
+			goto alloc_evtchn_fail;
 
-	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
-					0, netdev->name, netdev);
-	if (err < 0)
-		goto bind_fail;
-	netdev->irq = err;
+		err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+						xennet_interrupt,
+						0, netdev->name, info);
+		if (err < 0)
+			goto bind_fail;
+		info->rx_evtchn = info->tx_evtchn;
+		info->tx_irq = info->rx_irq = err;
+		info->split_evtchn = 0;
+		dev_info(&dev->dev, "single event channel, irq = %d\n",
+			 info->tx_irq);
+	} else {
+		err = xenbus_alloc_evtchn(dev, &info->tx_evtchn);
+		if (err)
+			goto alloc_evtchn_fail;
+		err = xenbus_alloc_evtchn(dev, &info->rx_evtchn);
+		if (err) {
+			xenbus_free_evtchn(dev, info->tx_evtchn);
+			goto alloc_evtchn_fail;
+		}
+		err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+						xennet_tx_interrupt,
+						0, netdev->name, info);
+		if (err < 0)
+			goto bind_fail;
+		info->tx_irq = err;
+		err = bind_evtchn_to_irqhandler(info->rx_evtchn,
+						xennet_rx_interrupt,
+						0, netdev->name, info);
+		if (err < 0) {
+			unbind_from_irqhandler(info->tx_irq, info);
+			goto bind_fail;
+		}
+		info->rx_irq = err;
+		info->split_evtchn = 1;
+		dev_info(&dev->dev, "split event channels,"
+			 " tx_irq = %d, rx_irq = %d\n",
+			 info->tx_irq, info->rx_irq);
+	}
 
 	return 0;
 
 bind_fail:
-	xenbus_free_evtchn(dev, info->evtchn);
+	if (!split_evtchn)
+		xenbus_free_evtchn(dev, info->tx_evtchn);
+	else {
+		xenbus_free_evtchn(dev, info->tx_evtchn);
+		xenbus_free_evtchn(dev, info->rx_evtchn);
+	}
 alloc_evtchn_fail:
 	for (; j >= 0; j--) {
 		int ref = info->rx_ring_ref[j];
@@ -1690,11 +1755,27 @@ again:
 		}
 	}
 
-	err = xenbus_printf(xbt, dev->nodename,
-			    "event-channel", "%u", info->evtchn);
-	if (err) {
-		message = "writing event-channel";
-		goto abort_transaction;
+
+	if (!info->split_evtchn) {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-tx", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel-tx";
+			goto abort_transaction;
+		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-rx", "%u", info->rx_evtchn);
+		if (err) {
+			message = "writing event-channel-rx";
+			goto abort_transaction;
+		}
 	}
 
 	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
@@ -1808,7 +1889,9 @@ static int xennet_connect(struct net_device *dev)
 	 * packets.
 	 */
 	netif_carrier_on(np->netdev);
-	notify_remote_via_irq(np->netdev->irq);
+	notify_remote_via_irq(np->tx_irq);
+	if (np->split_evtchn)
+		notify_remote_via_irq(np->rx_irq);
 	xennet_tx_buf_gc(dev);
 	xennet_alloc_rx_buffers(dev);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:46:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14:46:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrsUd-0007ZI-5X; Mon, 30 Jan 2012 14:46:03 +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 1RrsUb-0007Op-8J
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:46:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!10
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 674 invoked from network); 30 Jan 2012 14:45:55 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614416"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45:54 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 09:45:53 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTn029057;
	Mon, 30 Jan 2012 06:45:51 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:34 +0000
Message-ID: <1327934734-8908-17-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 16/16] netfront: split event channels
	support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If this feature is not activated, rx_irq = tx_irq. See corresponding
netback change log for details.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  147 ++++++++++++++++++++++++++++++++++----------
 1 files changed, 115 insertions(+), 32 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 32ec212..72c0429 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -98,7 +98,9 @@ struct netfront_info {
 
 	unsigned long rx_gso_checksum_fixup;
 
-	unsigned int evtchn;
+	unsigned int split_evtchn;
+	unsigned int tx_evtchn, rx_evtchn;
+	unsigned int tx_irq, rx_irq;
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
@@ -344,7 +346,7 @@ no_skb:
  push:
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->rx_irq);
 }
 
 static int xennet_open(struct net_device *dev)
@@ -577,7 +579,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 
 	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
 	if (notify)
-		notify_remote_via_irq(np->netdev->irq);
+		notify_remote_via_irq(np->tx_irq);
 
 	u64_stats_update_begin(&stats->syncp);
 	stats->tx_bytes += skb->len;
@@ -1242,22 +1244,35 @@ static int xennet_set_features(struct net_device *dev, u32 features)
 	return 0;
 }
 
-static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+static irqreturn_t xennet_tx_interrupt(int irq, void *dev_id)
 {
-	struct net_device *dev = dev_id;
-	struct netfront_info *np = netdev_priv(dev);
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
 	unsigned long flags;
 
 	spin_lock_irqsave(&np->tx_lock, flags);
+	xennet_tx_buf_gc(dev);
+	spin_unlock_irqrestore(&np->tx_lock, flags);
 
-	if (likely(netif_carrier_ok(dev))) {
-		xennet_tx_buf_gc(dev);
-		/* Under tx_lock: protects access to rx shared-ring indexes. */
-		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
-			napi_schedule(&np->napi);
-	}
+	return IRQ_HANDLED;
+}
 
-	spin_unlock_irqrestore(&np->tx_lock, flags);
+static irqreturn_t xennet_rx_interrupt(int irq, void *dev_id)
+{
+	struct netfront_info *np = dev_id;
+	struct net_device *dev = np->netdev;
+
+	if (likely(netif_carrier_ok(dev)) &&
+	    RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
+		napi_schedule(&np->napi);
+
+	return IRQ_HANDLED;
+}
+static irqreturn_t xennet_interrupt(int irq, void *dev_id)
+{
+	xennet_tx_interrupt(0, dev_id);
+
+	xennet_rx_interrupt(0, dev_id);
 
 	return IRQ_HANDLED;
 }
@@ -1436,9 +1451,14 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 	spin_unlock_irq(&info->tx_lock);
 	spin_unlock_bh(&info->rx_lock);
 
-	if (info->netdev->irq)
-		unbind_from_irqhandler(info->netdev->irq, info->netdev);
-	info->evtchn = info->netdev->irq = 0;
+	if (info->tx_irq && (info->tx_irq == info->rx_irq))
+		unbind_from_irqhandler(info->tx_irq, info);
+	if (info->tx_irq && (info->tx_irq != info->rx_irq)) {
+		unbind_from_irqhandler(info->tx_irq, info);
+		unbind_from_irqhandler(info->rx_irq, info);
+	}
+	info->tx_evtchn = info->tx_irq = 0;
+	info->rx_evtchn = info->rx_irq = 0;
 
 	for (i = 0; i < info->tx_ring_pages; i++) {
 		int ref = info->tx_ring_ref[i];
@@ -1507,6 +1527,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	int err;
 	struct net_device *netdev = info->netdev;
 	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
+	unsigned int split_evtchn;
 	int i, j;
 
 	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
@@ -1515,7 +1536,6 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	}
 	info->rx.sring = NULL;
 	info->tx.sring = NULL;
-	netdev->irq = 0;
 
 	err = xen_net_read_mac(dev, netdev->dev_addr);
 	if (err) {
@@ -1524,6 +1544,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	}
 
 	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "split-event-channels", "%u",
+			   &split_evtchn);
+	if (err < 0)
+		split_evtchn = 0;
+
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
 			   "max-tx-ring-page-order", "%u",
 			   &max_tx_ring_page_order);
 	if (err < 0) {
@@ -1589,20 +1615,59 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		info->rx_ring_ref[j] = err;
 	}
 
-	err = xenbus_alloc_evtchn(dev, &info->evtchn);
-	if (err)
-		goto alloc_evtchn_fail;
+	if (!split_evtchn) {
+		err = xenbus_alloc_evtchn(dev, &info->tx_evtchn);
+		if (err)
+			goto alloc_evtchn_fail;
 
-	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
-					0, netdev->name, netdev);
-	if (err < 0)
-		goto bind_fail;
-	netdev->irq = err;
+		err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+						xennet_interrupt,
+						0, netdev->name, info);
+		if (err < 0)
+			goto bind_fail;
+		info->rx_evtchn = info->tx_evtchn;
+		info->tx_irq = info->rx_irq = err;
+		info->split_evtchn = 0;
+		dev_info(&dev->dev, "single event channel, irq = %d\n",
+			 info->tx_irq);
+	} else {
+		err = xenbus_alloc_evtchn(dev, &info->tx_evtchn);
+		if (err)
+			goto alloc_evtchn_fail;
+		err = xenbus_alloc_evtchn(dev, &info->rx_evtchn);
+		if (err) {
+			xenbus_free_evtchn(dev, info->tx_evtchn);
+			goto alloc_evtchn_fail;
+		}
+		err = bind_evtchn_to_irqhandler(info->tx_evtchn,
+						xennet_tx_interrupt,
+						0, netdev->name, info);
+		if (err < 0)
+			goto bind_fail;
+		info->tx_irq = err;
+		err = bind_evtchn_to_irqhandler(info->rx_evtchn,
+						xennet_rx_interrupt,
+						0, netdev->name, info);
+		if (err < 0) {
+			unbind_from_irqhandler(info->tx_irq, info);
+			goto bind_fail;
+		}
+		info->rx_irq = err;
+		info->split_evtchn = 1;
+		dev_info(&dev->dev, "split event channels,"
+			 " tx_irq = %d, rx_irq = %d\n",
+			 info->tx_irq, info->rx_irq);
+	}
 
 	return 0;
 
 bind_fail:
-	xenbus_free_evtchn(dev, info->evtchn);
+	if (!split_evtchn)
+		xenbus_free_evtchn(dev, info->tx_evtchn);
+	else {
+		xenbus_free_evtchn(dev, info->tx_evtchn);
+		xenbus_free_evtchn(dev, info->rx_evtchn);
+	}
 alloc_evtchn_fail:
 	for (; j >= 0; j--) {
 		int ref = info->rx_ring_ref[j];
@@ -1690,11 +1755,27 @@ again:
 		}
 	}
 
-	err = xenbus_printf(xbt, dev->nodename,
-			    "event-channel", "%u", info->evtchn);
-	if (err) {
-		message = "writing event-channel";
-		goto abort_transaction;
+
+	if (!info->split_evtchn) {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel";
+			goto abort_transaction;
+		}
+	} else {
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-tx", "%u", info->tx_evtchn);
+		if (err) {
+			message = "writing event-channel-tx";
+			goto abort_transaction;
+		}
+		err = xenbus_printf(xbt, dev->nodename,
+				    "event-channel-rx", "%u", info->rx_evtchn);
+		if (err) {
+			message = "writing event-channel-rx";
+			goto abort_transaction;
+		}
 	}
 
 	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
@@ -1808,7 +1889,9 @@ static int xennet_connect(struct net_device *dev)
 	 * packets.
 	 */
 	netif_carrier_on(np->netdev);
-	notify_remote_via_irq(np->netdev->irq);
+	notify_remote_via_irq(np->tx_irq);
+	if (np->split_evtchn)
+		notify_remote_via_irq(np->rx_irq);
 	xennet_tx_buf_gc(dev);
 	xennet_alloc_rx_buffers(dev);
 
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:46:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUc-0007YP-Jl; Mon, 30 Jan 2012 14:46:02 +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 1RrsUZ-0007Nd-Jo
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:46:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 501 invoked from network); 30 Jan 2012 14:45:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614411"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 09:45:51 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTm029057;
	Mon, 30 Jan 2012 06:45:50 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:33 +0000
Message-ID: <1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use DMA API to allocate ring pages, because we need to get machine
contiginous memory.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  258 ++++++++++++++++++++++++++++++++------------
 1 files changed, 187 insertions(+), 71 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 01f589d..32ec212 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -66,9 +66,18 @@ struct netfront_cb {
 
 #define GRANT_INVALID_REF	0
 
-#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
+#define XENNET_MAX_RING_PAGE_ORDER 2
+#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
+
+#define NET_TX_RING_SIZE(_nr_pages)					\
+	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
+#define NET_RX_RING_SIZE(_nr_pages)					\
+	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
+
+#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
+#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
+
+#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE
 
 struct netfront_stats {
 	u64			rx_packets;
@@ -84,12 +93,20 @@ struct netfront_info {
 
 	struct napi_struct napi;
 
+	/* Statistics */
+	struct netfront_stats __percpu *stats;
+
+	unsigned long rx_gso_checksum_fixup;
+
 	unsigned int evtchn;
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
 	struct xen_netif_tx_front_ring tx;
-	int tx_ring_ref;
+	dma_addr_t tx_ring_dma_handle;
+	int tx_ring_ref[XENNET_MAX_RING_PAGES];
+	int tx_ring_page_order;
+	int tx_ring_pages;
 
 	/*
 	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
@@ -103,36 +120,34 @@ struct netfront_info {
 	union skb_entry {
 		struct sk_buff *skb;
 		unsigned long link;
-	} tx_skbs[NET_TX_RING_SIZE];
+	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
 	grant_ref_t gref_tx_head;
-	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
+	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
 	unsigned tx_skb_freelist;
 
 	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
 	struct xen_netif_rx_front_ring rx;
-	int rx_ring_ref;
+	dma_addr_t rx_ring_dma_handle;
+	int rx_ring_ref[XENNET_MAX_RING_PAGES];
+	int rx_ring_page_order;
+	int rx_ring_pages;
 
 	/* Receive-ring batched refills. */
 #define RX_MIN_TARGET 8
 #define RX_DFL_MIN_TARGET 64
-#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+#define RX_MAX_TARGET XENNET_MAX_RX_RING_SIZE
 	unsigned rx_min_target, rx_max_target, rx_target;
 	struct sk_buff_head rx_batch;
 
 	struct timer_list rx_refill_timer;
 
-	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
+	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
 	grant_ref_t gref_rx_head;
-	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
-
-	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
-	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
-	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
-
-	/* Statistics */
-	struct netfront_stats __percpu *stats;
+	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
 
-	unsigned long rx_gso_checksum_fixup;
+	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
+	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
+	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
 };
 
 struct netfront_rx_info {
@@ -170,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
 	return id;
 }
 
-static int xennet_rxidx(RING_IDX idx)
+static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
 {
-	return idx & (NET_RX_RING_SIZE - 1);
+	return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
 }
 
 static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 					 RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	struct sk_buff *skb = np->rx_skbs[i];
 	np->rx_skbs[i] = NULL;
 	return skb;
@@ -187,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
 					    RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	grant_ref_t ref = np->grant_rx_ref[i];
 	np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	return ref;
@@ -300,7 +315,7 @@ no_skb:
 
 		skb->dev = dev;
 
-		id = xennet_rxidx(req_prod + i);
+		id = xennet_rxidx(req_prod + i, np);
 
 		BUG_ON(np->rx_skbs[id]);
 		np->rx_skbs[id] = skb;
@@ -596,7 +611,7 @@ static int xennet_close(struct net_device *dev)
 static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
 				grant_ref_t ref)
 {
-	int new = xennet_rxidx(np->rx.req_prod_pvt);
+	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
 
 	BUG_ON(np->rx_skbs[new]);
 	np->rx_skbs[new] = skb;
@@ -1089,7 +1104,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
 	struct sk_buff *skb;
 	int i;
 
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
 		/* Skip over entries which are actually freelist references */
 		if (skb_entry_is_link(&np->tx_skbs[i]))
 			continue;
@@ -1123,7 +1138,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
 
 	spin_lock_bh(&np->rx_lock);
 
-	for (id = 0; id < NET_RX_RING_SIZE; id++) {
+	for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
 		ref = np->grant_rx_ref[id];
 		if (ref == GRANT_INVALID_REF) {
 			unused++;
@@ -1305,13 +1320,13 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
 
 	/* Initialise tx_skbs as a free chain containing every entry. */
 	np->tx_skb_freelist = 0;
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
 		skb_entry_set_link(&np->tx_skbs[i], i+1);
 		np->grant_tx_ref[i] = GRANT_INVALID_REF;
 	}
 
 	/* Clear out rx_skbs */
-	for (i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
 		np->rx_skbs[i] = NULL;
 		np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	}
@@ -1409,15 +1424,11 @@ static int __devinit netfront_probe(struct xenbus_device *dev,
 	return err;
 }
 
-static void xennet_end_access(int ref, void *page)
-{
-	/* This frees the page as a side-effect */
-	if (ref != GRANT_INVALID_REF)
-		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
-}
-
 static void xennet_disconnect_backend(struct netfront_info *info)
 {
+	int i;
+	struct xenbus_device *dev = info->xbdev;
+
 	/* Stop old i/f to prevent errors whilst we rebuild the state. */
 	spin_lock_bh(&info->rx_lock);
 	spin_lock_irq(&info->tx_lock);
@@ -1429,12 +1440,24 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 		unbind_from_irqhandler(info->netdev->irq, info->netdev);
 	info->evtchn = info->netdev->irq = 0;
 
-	/* End access and free the pages */
-	xennet_end_access(info->tx_ring_ref, info->tx.sring);
-	xennet_end_access(info->rx_ring_ref, info->rx.sring);
+	for (i = 0; i < info->tx_ring_pages; i++) {
+		int ref = info->tx_ring_ref[i];
+		gnttab_end_foreign_access_ref(ref, 0);
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+	}
+	dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
+			  (void *)info->tx.sring,
+			  info->tx_ring_dma_handle);
+
+	for (i = 0; i < info->rx_ring_pages; i++) {
+		int ref = info->rx_ring_ref[i];
+		gnttab_end_foreign_access_ref(ref, 0);
+		info->rx_ring_ref[i] = GRANT_INVALID_REF;
+	}
+	dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
+			  (void *)info->rx.sring,
+			  info->rx_ring_dma_handle);
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
 	info->tx.sring = NULL;
 	info->rx.sring = NULL;
 }
@@ -1483,9 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_rx_sring *rxs;
 	int err;
 	struct net_device *netdev = info->netdev;
+	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
+	int i, j;
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
+	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+		info->rx_ring_ref[i] = GRANT_INVALID_REF;
+	}
 	info->rx.sring = NULL;
 	info->tx.sring = NULL;
 	netdev->irq = 0;
@@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		goto fail;
 	}
 
-	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-tx-ring-page-order", "%u",
+			   &max_tx_ring_page_order);
+	if (err < 0) {
+		info->tx_ring_page_order = 0;
+		dev_info(&dev->dev, "single tx ring\n");
+	} else {
+		info->tx_ring_page_order = max_tx_ring_page_order;
+		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
+			 max_tx_ring_page_order);
+	}
+	info->tx_ring_pages = (1U << info->tx_ring_page_order);
+
+	txs = (struct xen_netif_tx_sring *)
+		dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
+				   &info->tx_ring_dma_handle,
+				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
 	if (!txs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating tx ring page");
 		goto fail;
 	}
 	SHARED_RING_INIT(txs);
-	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
+
+	for (i = 0; i < info->tx_ring_pages; i++) {
+		void *addr = (void *)((unsigned long)txs + PAGE_SIZE * i);
+		err = xenbus_grant_ring(dev, virt_to_mfn(addr));
+		if (err < 0)
+			goto grant_tx_ring_fail;
+		info->tx_ring_ref[i] = err;
+	}
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-rx-ring-page-order", "%u",
+			   &max_rx_ring_page_order);
 	if (err < 0) {
-		free_page((unsigned long)txs);
-		goto fail;
+		info->rx_ring_page_order = 0;
+		dev_info(&dev->dev, "single rx ring\n");
+	} else {
+		info->rx_ring_page_order = max_rx_ring_page_order;
+		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
+			 max_rx_ring_page_order);
 	}
+	info->rx_ring_pages = (1U << info->rx_ring_page_order);
 
-	info->tx_ring_ref = err;
-	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	rxs = (struct xen_netif_rx_sring *)
+		dma_alloc_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
+				   &info->rx_ring_dma_handle,
+				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
 	if (!rxs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating rx ring page");
-		goto fail;
+		goto alloc_rx_ring_fail;
 	}
 	SHARED_RING_INIT(rxs);
-	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
-
-	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
-	if (err < 0) {
-		free_page((unsigned long)rxs);
-		goto fail;
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
+
+	for (j = 0; j < info->rx_ring_pages; j++) {
+		void *addr = (void *)((unsigned long)rxs + PAGE_SIZE * j);
+		err = xenbus_grant_ring(dev, virt_to_mfn(addr));
+		if (err < 0)
+			goto grant_rx_ring_fail;
+		info->rx_ring_ref[j] = err;
 	}
-	info->rx_ring_ref = err;
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
-		goto fail;
+		goto alloc_evtchn_fail;
 
 	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
 					0, netdev->name, netdev);
 	if (err < 0)
-		goto fail;
+		goto bind_fail;
 	netdev->irq = err;
+
 	return 0;
 
- fail:
+bind_fail:
+	xenbus_free_evtchn(dev, info->evtchn);
+alloc_evtchn_fail:
+	for (; j >= 0; j--) {
+		int ref = info->rx_ring_ref[j];
+		gnttab_end_foreign_access_ref(ref, 0);
+		info->rx_ring_ref[j] = GRANT_INVALID_REF;
+	}
+grant_rx_ring_fail:
+	dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
+			  (void *)rxs, info->rx_ring_dma_handle);
+alloc_rx_ring_fail:
+	for (; i >= 0; i--) {
+		int ref = info->tx_ring_ref[i];
+		gnttab_end_foreign_access_ref(ref, 0);
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+	}
+grant_tx_ring_fail:
+	dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
+			  (void *)txs, info->tx_ring_dma_handle);
+fail:
 	return err;
 }
 
@@ -1550,6 +1632,7 @@ static int talk_to_netback(struct xenbus_device *dev,
 	const char *message;
 	struct xenbus_transaction xbt;
 	int err;
+	int i;
 
 	/* Create shared ring, alloc event channel. */
 	err = setup_netfront(dev, info);
@@ -1563,18 +1646,50 @@ again:
 		goto destroy_ring;
 	}
 
-	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
-			    info->tx_ring_ref);
-	if (err) {
-		message = "writing tx ring-ref";
-		goto abort_transaction;
+	if (info->tx_ring_page_order == 0)
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
+				    info->tx_ring_ref[0]);
+	else {
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
+				    info->tx_ring_page_order);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->tx_ring_pages; i++) {
+			char name[sizeof("tx-ring-ref")+2];
+			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->tx_ring_ref[i]);
+			if (err) {
+				message = "writing tx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
-	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
-			    info->rx_ring_ref);
-	if (err) {
-		message = "writing rx ring-ref";
-		goto abort_transaction;
+
+	if (info->rx_ring_page_order == 0)
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
+				    info->rx_ring_ref[0]);
+	else {
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
+				    info->rx_ring_page_order);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->rx_ring_pages; i++) {
+			char name[sizeof("rx-ring-ref")+2];
+			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->rx_ring_ref[i]);
+			if (err) {
+				message = "writing rx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
+
 	err = xenbus_printf(xbt, dev->nodename,
 			    "event-channel", "%u", info->evtchn);
 	if (err) {
@@ -1661,7 +1776,8 @@ static int xennet_connect(struct net_device *dev)
 	xennet_release_tx_bufs(np);
 
 	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
-	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE(np->rx_ring_pages);
+	     i++) {
 		skb_frag_t *frag;
 		const struct page *page;
 		if (!np->rx_skbs[i])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:46:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsUc-0007YP-Jl; Mon, 30 Jan 2012 14:46:02 +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 1RrsUZ-0007Nd-Jo
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:46:00 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327934733!5629510!9
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 501 invoked from network); 30 Jan 2012 14:45:53 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:45:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179614411"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 09:45:52 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 09:45:51 -0500
Received: from devbox.uk.xensource.com ([10.80.239.132])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UEjUTm029057;
	Mon, 30 Jan 2012 06:45:50 -0800
From: Wei Liu <wei.liu2@citrix.com>
To: netdev@vger.kernel.org, xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 14:45:33 +0000
Message-ID: <1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Cc: Wei Liu <wei.liu2@citrix.com>, ian.campbell@citrix.com,
	konrad.wilk@oracle.com
Subject: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use DMA API to allocate ring pages, because we need to get machine
contiginous memory.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
 drivers/net/xen-netfront.c |  258 ++++++++++++++++++++++++++++++++------------
 1 files changed, 187 insertions(+), 71 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 01f589d..32ec212 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -66,9 +66,18 @@ struct netfront_cb {
 
 #define GRANT_INVALID_REF	0
 
-#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
-#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
-#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
+#define XENNET_MAX_RING_PAGE_ORDER 2
+#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
+
+#define NET_TX_RING_SIZE(_nr_pages)					\
+	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
+#define NET_RX_RING_SIZE(_nr_pages)					\
+	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
+
+#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
+#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
+
+#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE
 
 struct netfront_stats {
 	u64			rx_packets;
@@ -84,12 +93,20 @@ struct netfront_info {
 
 	struct napi_struct napi;
 
+	/* Statistics */
+	struct netfront_stats __percpu *stats;
+
+	unsigned long rx_gso_checksum_fixup;
+
 	unsigned int evtchn;
 	struct xenbus_device *xbdev;
 
 	spinlock_t   tx_lock;
 	struct xen_netif_tx_front_ring tx;
-	int tx_ring_ref;
+	dma_addr_t tx_ring_dma_handle;
+	int tx_ring_ref[XENNET_MAX_RING_PAGES];
+	int tx_ring_page_order;
+	int tx_ring_pages;
 
 	/*
 	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
@@ -103,36 +120,34 @@ struct netfront_info {
 	union skb_entry {
 		struct sk_buff *skb;
 		unsigned long link;
-	} tx_skbs[NET_TX_RING_SIZE];
+	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
 	grant_ref_t gref_tx_head;
-	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
+	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
 	unsigned tx_skb_freelist;
 
 	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
 	struct xen_netif_rx_front_ring rx;
-	int rx_ring_ref;
+	dma_addr_t rx_ring_dma_handle;
+	int rx_ring_ref[XENNET_MAX_RING_PAGES];
+	int rx_ring_page_order;
+	int rx_ring_pages;
 
 	/* Receive-ring batched refills. */
 #define RX_MIN_TARGET 8
 #define RX_DFL_MIN_TARGET 64
-#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
+#define RX_MAX_TARGET XENNET_MAX_RX_RING_SIZE
 	unsigned rx_min_target, rx_max_target, rx_target;
 	struct sk_buff_head rx_batch;
 
 	struct timer_list rx_refill_timer;
 
-	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
+	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
 	grant_ref_t gref_rx_head;
-	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
-
-	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
-	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
-	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
-
-	/* Statistics */
-	struct netfront_stats __percpu *stats;
+	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
 
-	unsigned long rx_gso_checksum_fixup;
+	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
+	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
+	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
 };
 
 struct netfront_rx_info {
@@ -170,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
 	return id;
 }
 
-static int xennet_rxidx(RING_IDX idx)
+static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
 {
-	return idx & (NET_RX_RING_SIZE - 1);
+	return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
 }
 
 static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 					 RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	struct sk_buff *skb = np->rx_skbs[i];
 	np->rx_skbs[i] = NULL;
 	return skb;
@@ -187,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
 static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
 					    RING_IDX ri)
 {
-	int i = xennet_rxidx(ri);
+	int i = xennet_rxidx(ri, np);
 	grant_ref_t ref = np->grant_rx_ref[i];
 	np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	return ref;
@@ -300,7 +315,7 @@ no_skb:
 
 		skb->dev = dev;
 
-		id = xennet_rxidx(req_prod + i);
+		id = xennet_rxidx(req_prod + i, np);
 
 		BUG_ON(np->rx_skbs[id]);
 		np->rx_skbs[id] = skb;
@@ -596,7 +611,7 @@ static int xennet_close(struct net_device *dev)
 static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
 				grant_ref_t ref)
 {
-	int new = xennet_rxidx(np->rx.req_prod_pvt);
+	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
 
 	BUG_ON(np->rx_skbs[new]);
 	np->rx_skbs[new] = skb;
@@ -1089,7 +1104,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
 	struct sk_buff *skb;
 	int i;
 
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
 		/* Skip over entries which are actually freelist references */
 		if (skb_entry_is_link(&np->tx_skbs[i]))
 			continue;
@@ -1123,7 +1138,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
 
 	spin_lock_bh(&np->rx_lock);
 
-	for (id = 0; id < NET_RX_RING_SIZE; id++) {
+	for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
 		ref = np->grant_rx_ref[id];
 		if (ref == GRANT_INVALID_REF) {
 			unused++;
@@ -1305,13 +1320,13 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
 
 	/* Initialise tx_skbs as a free chain containing every entry. */
 	np->tx_skb_freelist = 0;
-	for (i = 0; i < NET_TX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
 		skb_entry_set_link(&np->tx_skbs[i], i+1);
 		np->grant_tx_ref[i] = GRANT_INVALID_REF;
 	}
 
 	/* Clear out rx_skbs */
-	for (i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
 		np->rx_skbs[i] = NULL;
 		np->grant_rx_ref[i] = GRANT_INVALID_REF;
 	}
@@ -1409,15 +1424,11 @@ static int __devinit netfront_probe(struct xenbus_device *dev,
 	return err;
 }
 
-static void xennet_end_access(int ref, void *page)
-{
-	/* This frees the page as a side-effect */
-	if (ref != GRANT_INVALID_REF)
-		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
-}
-
 static void xennet_disconnect_backend(struct netfront_info *info)
 {
+	int i;
+	struct xenbus_device *dev = info->xbdev;
+
 	/* Stop old i/f to prevent errors whilst we rebuild the state. */
 	spin_lock_bh(&info->rx_lock);
 	spin_lock_irq(&info->tx_lock);
@@ -1429,12 +1440,24 @@ static void xennet_disconnect_backend(struct netfront_info *info)
 		unbind_from_irqhandler(info->netdev->irq, info->netdev);
 	info->evtchn = info->netdev->irq = 0;
 
-	/* End access and free the pages */
-	xennet_end_access(info->tx_ring_ref, info->tx.sring);
-	xennet_end_access(info->rx_ring_ref, info->rx.sring);
+	for (i = 0; i < info->tx_ring_pages; i++) {
+		int ref = info->tx_ring_ref[i];
+		gnttab_end_foreign_access_ref(ref, 0);
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+	}
+	dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
+			  (void *)info->tx.sring,
+			  info->tx_ring_dma_handle);
+
+	for (i = 0; i < info->rx_ring_pages; i++) {
+		int ref = info->rx_ring_ref[i];
+		gnttab_end_foreign_access_ref(ref, 0);
+		info->rx_ring_ref[i] = GRANT_INVALID_REF;
+	}
+	dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
+			  (void *)info->rx.sring,
+			  info->rx_ring_dma_handle);
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
 	info->tx.sring = NULL;
 	info->rx.sring = NULL;
 }
@@ -1483,9 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 	struct xen_netif_rx_sring *rxs;
 	int err;
 	struct net_device *netdev = info->netdev;
+	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
+	int i, j;
 
-	info->tx_ring_ref = GRANT_INVALID_REF;
-	info->rx_ring_ref = GRANT_INVALID_REF;
+	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+		info->rx_ring_ref[i] = GRANT_INVALID_REF;
+	}
 	info->rx.sring = NULL;
 	info->tx.sring = NULL;
 	netdev->irq = 0;
@@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
 		goto fail;
 	}
 
-	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-tx-ring-page-order", "%u",
+			   &max_tx_ring_page_order);
+	if (err < 0) {
+		info->tx_ring_page_order = 0;
+		dev_info(&dev->dev, "single tx ring\n");
+	} else {
+		info->tx_ring_page_order = max_tx_ring_page_order;
+		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
+			 max_tx_ring_page_order);
+	}
+	info->tx_ring_pages = (1U << info->tx_ring_page_order);
+
+	txs = (struct xen_netif_tx_sring *)
+		dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
+				   &info->tx_ring_dma_handle,
+				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
 	if (!txs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating tx ring page");
 		goto fail;
 	}
 	SHARED_RING_INIT(txs);
-	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
+	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
+
+	for (i = 0; i < info->tx_ring_pages; i++) {
+		void *addr = (void *)((unsigned long)txs + PAGE_SIZE * i);
+		err = xenbus_grant_ring(dev, virt_to_mfn(addr));
+		if (err < 0)
+			goto grant_tx_ring_fail;
+		info->tx_ring_ref[i] = err;
+	}
 
-	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
+	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
+			   "max-rx-ring-page-order", "%u",
+			   &max_rx_ring_page_order);
 	if (err < 0) {
-		free_page((unsigned long)txs);
-		goto fail;
+		info->rx_ring_page_order = 0;
+		dev_info(&dev->dev, "single rx ring\n");
+	} else {
+		info->rx_ring_page_order = max_rx_ring_page_order;
+		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
+			 max_rx_ring_page_order);
 	}
+	info->rx_ring_pages = (1U << info->rx_ring_page_order);
 
-	info->tx_ring_ref = err;
-	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
+	rxs = (struct xen_netif_rx_sring *)
+		dma_alloc_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
+				   &info->rx_ring_dma_handle,
+				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
 	if (!rxs) {
 		err = -ENOMEM;
 		xenbus_dev_fatal(dev, err, "allocating rx ring page");
-		goto fail;
+		goto alloc_rx_ring_fail;
 	}
 	SHARED_RING_INIT(rxs);
-	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
-
-	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
-	if (err < 0) {
-		free_page((unsigned long)rxs);
-		goto fail;
+	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
+
+	for (j = 0; j < info->rx_ring_pages; j++) {
+		void *addr = (void *)((unsigned long)rxs + PAGE_SIZE * j);
+		err = xenbus_grant_ring(dev, virt_to_mfn(addr));
+		if (err < 0)
+			goto grant_rx_ring_fail;
+		info->rx_ring_ref[j] = err;
 	}
-	info->rx_ring_ref = err;
 
 	err = xenbus_alloc_evtchn(dev, &info->evtchn);
 	if (err)
-		goto fail;
+		goto alloc_evtchn_fail;
 
 	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
 					0, netdev->name, netdev);
 	if (err < 0)
-		goto fail;
+		goto bind_fail;
 	netdev->irq = err;
+
 	return 0;
 
- fail:
+bind_fail:
+	xenbus_free_evtchn(dev, info->evtchn);
+alloc_evtchn_fail:
+	for (; j >= 0; j--) {
+		int ref = info->rx_ring_ref[j];
+		gnttab_end_foreign_access_ref(ref, 0);
+		info->rx_ring_ref[j] = GRANT_INVALID_REF;
+	}
+grant_rx_ring_fail:
+	dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
+			  (void *)rxs, info->rx_ring_dma_handle);
+alloc_rx_ring_fail:
+	for (; i >= 0; i--) {
+		int ref = info->tx_ring_ref[i];
+		gnttab_end_foreign_access_ref(ref, 0);
+		info->tx_ring_ref[i] = GRANT_INVALID_REF;
+	}
+grant_tx_ring_fail:
+	dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
+			  (void *)txs, info->tx_ring_dma_handle);
+fail:
 	return err;
 }
 
@@ -1550,6 +1632,7 @@ static int talk_to_netback(struct xenbus_device *dev,
 	const char *message;
 	struct xenbus_transaction xbt;
 	int err;
+	int i;
 
 	/* Create shared ring, alloc event channel. */
 	err = setup_netfront(dev, info);
@@ -1563,18 +1646,50 @@ again:
 		goto destroy_ring;
 	}
 
-	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
-			    info->tx_ring_ref);
-	if (err) {
-		message = "writing tx ring-ref";
-		goto abort_transaction;
+	if (info->tx_ring_page_order == 0)
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
+				    info->tx_ring_ref[0]);
+	else {
+		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
+				    info->tx_ring_page_order);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->tx_ring_pages; i++) {
+			char name[sizeof("tx-ring-ref")+2];
+			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->tx_ring_ref[i]);
+			if (err) {
+				message = "writing tx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
-	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
-			    info->rx_ring_ref);
-	if (err) {
-		message = "writing rx ring-ref";
-		goto abort_transaction;
+
+	if (info->rx_ring_page_order == 0)
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
+				    info->rx_ring_ref[0]);
+	else {
+		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
+				    info->rx_ring_page_order);
+		if (err) {
+			message = "writing tx ring-ref";
+			goto abort_transaction;
+		}
+		for (i = 0; i < info->rx_ring_pages; i++) {
+			char name[sizeof("rx-ring-ref")+2];
+			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
+			err = xenbus_printf(xbt, dev->nodename, name, "%u",
+					    info->rx_ring_ref[i]);
+			if (err) {
+				message = "writing rx ring-ref";
+				goto abort_transaction;
+			}
+		}
 	}
+
 	err = xenbus_printf(xbt, dev->nodename,
 			    "event-channel", "%u", info->evtchn);
 	if (err) {
@@ -1661,7 +1776,8 @@ static int xennet_connect(struct net_device *dev)
 	xennet_release_tx_bufs(np);
 
 	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
-	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
+	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE(np->rx_ring_pages);
+	     i++) {
 		skb_frag_t *frag;
 		const struct page *page;
 		if (!np->rx_skbs[i])
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsZX-0001M9-M5; Mon, 30 Jan 2012 14:51:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RrsZW-0001Kr-7Q
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:51:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327935058!8955145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17847 invoked from network); 30 Jan 2012 14:50:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:50:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10368325"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:50: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, 30 Jan 2012 14:50:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 14:50:58 +0000
In-Reply-To: <1327932087-25001-1-git-send-email-ian.jackson@eu.citrix.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
	<1327932087-25001-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327935058.26983.229.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] libxl: domain_death_xswatch_callback:
 add some debug 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 14:01 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <Ian.Campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:51:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsZX-0001M9-M5; Mon, 30 Jan 2012 14:51:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RrsZW-0001Kr-7Q
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:51:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-21.messagelabs.com!1327935058!8955145!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17847 invoked from network); 30 Jan 2012 14:50:58 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-10.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 14:50:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10368325"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 14:50: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, 30 Jan 2012 14:50:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 14:50:58 +0000
In-Reply-To: <1327932087-25001-1-git-send-email-ian.jackson@eu.citrix.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
	<1327932087-25001-1-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327935058.26983.229.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] libxl: domain_death_xswatch_callback:
 add some debug 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 14:01 +0000, Ian Jackson wrote:
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Ian Campbell <Ian.Campbell@citrix.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsbX-0001hs-89; Mon, 30 Jan 2012 14:53:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RrsbV-0001hS-Dq
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:53:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327935130!54606816!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTEzNzEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17504 invoked from network); 30 Jan 2012 14:52:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 14:52:11 -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
	q0UEr0SD005372
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 14:53:01 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
	q0UEr0Y2028939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 14:53:00 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0UEqx48016702; Mon, 30 Jan 2012 08:53:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 06:52:59 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AB7A640325; Sun, 29 Jan 2012 16:37:46 -0500 (EST)
Date: Sun, 29 Jan 2012 16:37:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120129213746.GA7164@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327844561.2911.5.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F26AECE.0098,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Jan 29, 2012 at 01:42:41PM +0000, Wei Liu wrote:
> On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 17, 2012 at 01:46:56PM +0000, Wei Liu wrote:
> > > A new netback implementation which includes three major features:
> > > 
> > >  - Global page pool support
> > >  - NAPI + kthread 1:1 model
> > >  - Netback internal name changes
> > > 
> > > Changes in V2:
> > >  - Fix minor bugs in V1
> > >  - Embed pending_tx_info into page pool
> > >  - Per-cpu scratch space
> > >  - Notification code path clean up
> > > 
> > > This patch series is the foundation of furture work. So it is better
> > > to get it right first. Patch 1 and 3 have the real meat.
> > 
> > I've been playing with these patches and couple of things
> > came to my mind: 
> >  - would it make sense to also register to the shrinker API? This way
> >    if the host is running low on memory it can squeeze it out of the
> >    pool code. Perhaps a future TODO..
> >  - I like the pool code. I was thinking that perhaps (in the future)
> >    it could be used by blkback as well, as it runs into "not enought
> >    request structure" with the default setting. And making this dynamic
> >    would be pretty sweet.
> 
> Interesting thoughts worth adding to TODO list. But I'm focusing on
> multi-page ring support and split event channel at the moment, which
> should help improve performance on 10G network. Hopefully I can submit
> RFC patch V3 in a few days. ;-)
> 
> >  - This patch set solves the CPU banding problem I've seen with the
> >    older netback. The older one  I could see X netback threads eating 80%
> >    of CPU. With this one, the number is down to 13-14%.
> > 
> > So you can definitly stick 'Tested-by: Konrad.." on them. And definitly
> > Reviewed-by on the first two - hadn't had a chance to look at the rest.
> > 
> 
> Thanks for your extensive test and review.

Sure. I also did some testing with limiting the amount of CPUs and found
that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> 
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 14:53:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 14: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 1RrsbX-0001hs-89; Mon, 30 Jan 2012 14:53:11 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RrsbV-0001hS-Dq
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 14:53:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1327935130!54606816!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTEzNzEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17504 invoked from network); 30 Jan 2012 14:52:11 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 14:52:11 -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
	q0UEr0SD005372
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 14:53:01 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
	q0UEr0Y2028939
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 14:53:00 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0UEqx48016702; Mon, 30 Jan 2012 08:53:00 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 06:52:59 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id AB7A640325; Sun, 29 Jan 2012 16:37:46 -0500 (EST)
Date: Sun, 29 Jan 2012 16:37:46 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120129213746.GA7164@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327844561.2911.5.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4F26AECE.0098,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, Jan 29, 2012 at 01:42:41PM +0000, Wei Liu wrote:
> On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jan 17, 2012 at 01:46:56PM +0000, Wei Liu wrote:
> > > A new netback implementation which includes three major features:
> > > 
> > >  - Global page pool support
> > >  - NAPI + kthread 1:1 model
> > >  - Netback internal name changes
> > > 
> > > Changes in V2:
> > >  - Fix minor bugs in V1
> > >  - Embed pending_tx_info into page pool
> > >  - Per-cpu scratch space
> > >  - Notification code path clean up
> > > 
> > > This patch series is the foundation of furture work. So it is better
> > > to get it right first. Patch 1 and 3 have the real meat.
> > 
> > I've been playing with these patches and couple of things
> > came to my mind: 
> >  - would it make sense to also register to the shrinker API? This way
> >    if the host is running low on memory it can squeeze it out of the
> >    pool code. Perhaps a future TODO..
> >  - I like the pool code. I was thinking that perhaps (in the future)
> >    it could be used by blkback as well, as it runs into "not enought
> >    request structure" with the default setting. And making this dynamic
> >    would be pretty sweet.
> 
> Interesting thoughts worth adding to TODO list. But I'm focusing on
> multi-page ring support and split event channel at the moment, which
> should help improve performance on 10G network. Hopefully I can submit
> RFC patch V3 in a few days. ;-)
> 
> >  - This patch set solves the CPU banding problem I've seen with the
> >    older netback. The older one  I could see X netback threads eating 80%
> >    of CPU. With this one, the number is down to 13-14%.
> > 
> > So you can definitly stick 'Tested-by: Konrad.." on them. And definitly
> > Reviewed-by on the first two - hadn't had a chance to look at the rest.
> > 
> 
> Thanks for your extensive test and review.

Sure. I also did some testing with limiting the amount of CPUs and found
that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> 
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:02:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrsjn-0001y0-JQ; Mon, 30 Jan 2012 15:01:43 +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 1Rrsjm-0001xv-27
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:01:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327935695!9141498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4755 invoked from network); 30 Jan 2012 15:01:36 -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;
	30 Jan 2012 15:01:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10368634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:01:35 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 15:01:36 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120129213746.GA7164@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
	<20120129213746.GA7164@phenom.dumpdata.com>
Date: Mon, 30 Jan 2012 15:01:47 +0000
Message-ID: <1327935707.5553.27.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-01-29 at 21:37 +0000, Konrad Rzeszutek Wilk wrote:
> Sure. I also did some testing with limiting the amount of CPUs and found
> that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> > 

Any stack trace? Oops message? Did you increase the number of CPUs or
decrease the number?

I didn't pay much attention on the CPU hotplug path TBH. And the V3
series, which I just posted, has a completed different per-cpu scratch
space implementation, which takes care of CPU hotplug events.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:02:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:02:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrsjn-0001y0-JQ; Mon, 30 Jan 2012 15:01:43 +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 1Rrsjm-0001xv-27
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:01:42 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327935695!9141498!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4755 invoked from network); 30 Jan 2012 15:01:36 -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;
	30 Jan 2012 15:01:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10368634"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:01:35 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 15:01:36 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120129213746.GA7164@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
	<20120129213746.GA7164@phenom.dumpdata.com>
Date: Mon, 30 Jan 2012 15:01:47 +0000
Message-ID: <1327935707.5553.27.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-01-29 at 21:37 +0000, Konrad Rzeszutek Wilk wrote:
> Sure. I also did some testing with limiting the amount of CPUs and found
> that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> > 

Any stack trace? Oops message? Did you increase the number of CPUs or
decrease the number?

I didn't pay much attention on the CPU hotplug path TBH. And the V3
series, which I just posted, has a completed different per-cpu scratch
space implementation, which takes care of CPU hotplug events.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:03:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrsl0-00021u-NG; Mon, 30 Jan 2012 15:02:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rrskz-00021b-R0
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:02:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327935771!12706942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6418 invoked from network); 30 Jan 2012 15:02:51 -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;
	30 Jan 2012 15:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10368682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:02: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, 30 Jan 2012 15:02:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 15:02:51 +0000
In-Reply-To: <1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
	<1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327935771.26983.239.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/2] libxl: treat "dying" domains as
 destroyed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 14:01 +0000, Ian Jackson wrote:
> Rename the DOMAIN_DESTROY event to DOMAIN_DEATH and have it trigger
> when the domain goes into the state indicated by the domaininfo flag
> "dying".
> 
> This fixes a race which could leak a daemonised xl process, which
> would have ignored the domain becoming "dying" and would then wait
> forever to be told the domain was destroyed.
> 
> After the domain becomes "dying" we can't generate an event when it is
> actually destroyed because xenstored will eat the relevant
> VIRT_DOM_EXC virq and not generate an @releaseDomain, since xenstored
> discards its own record of the domain's existence as soon as it sees
> the domain "dying" and will not trigger @releaseDomain watches for
> domains it knows nothing about.  Arguably this is a bug in xenstored,
> and the whole @releaseDomain machinery is rather poor, but let us not
> fix that now.
> 
> Anyway, xl does not really want to know when the domain is ultimately
> destroyed.  It is enough for xl to know that it is on the way out, in
> the "dying" state (which leads later to destruction by Xen).
> 
> Also fix a bug where domain_death_xswatch_callback might read one
> domain beyond the valid data in its domaininfos array, by correctly
> ordering the checks for empty domain list, end of domain list, and our
> domain being missing.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

This seems to do what I would expect, I tried with "xl reboot", "xl
shutdown" & "xl destroy" as well as in-guest shutdown (which is no
different in reality from "xl shutdown"). No leaks and in each case it
rebooted, destroyed etc the domain as expected.

> ---
>  tools/libxl/libxl.c         |   57 ++++++++++++++++++++++++++++--------------
>  tools/libxl/libxl_types.idl |    4 +-
>  tools/libxl/xl_cmdimpl.c    |    4 +-
>  3 files changed, 42 insertions(+), 23 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2758d4c..b74a4d9 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -685,6 +685,29 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
>      return ret;
>  }
>  
> +static void domain_death_occurred(libxl__egc *egc,
> +                                  libxl_evgen_domain_death **evg_upd,
> +                                  const char *why) {
> +    /* Removes **evg from the list and advances *evg_upd to the next
> +     * entry.  Call sites in _xswatch_callback must use "continue". */

There's no **evg in this context? ITYM *evg or just evg?

Also it's not clear which list this talks about since there is
death_list and death_reported as well as, presumably, a list of current
domain infos somewhere. Did you mean "moves evg from death_list to
death_reported list and advances *evg_upd ...."?

> +    EGC_GC;
> +    libxl_evgen_domain_death *const evg = *evg_upd;
> +
> +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " death %s", why);

LIBXL__LOG puts a space between the boilerplate and the message so you
end up with two spaces before "death" here.

Also the resultant messages are:
	" death destroyed"
	" death missing"
	" death dying"
in context that is:
        libxl: debug: libxl.c:696:domain_death_occurred:  death dying

Which could do with a noun or something. 

Or, maybe you meant s/death/domain/?

Other than those small nits:

Acked-/Tested-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:03:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:03:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrsl0-00021u-NG; Mon, 30 Jan 2012 15:02:58 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1Rrskz-00021b-R0
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:02:58 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1327935771!12706942!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6418 invoked from network); 30 Jan 2012 15:02:51 -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;
	30 Jan 2012 15:02:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10368682"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:02: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, 30 Jan 2012 15:02:52 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon, 30 Jan 2012 15:02:51 +0000
In-Reply-To: <1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
	<1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327935771.26983.239.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/2] libxl: treat "dying" domains as
 destroyed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 14:01 +0000, Ian Jackson wrote:
> Rename the DOMAIN_DESTROY event to DOMAIN_DEATH and have it trigger
> when the domain goes into the state indicated by the domaininfo flag
> "dying".
> 
> This fixes a race which could leak a daemonised xl process, which
> would have ignored the domain becoming "dying" and would then wait
> forever to be told the domain was destroyed.
> 
> After the domain becomes "dying" we can't generate an event when it is
> actually destroyed because xenstored will eat the relevant
> VIRT_DOM_EXC virq and not generate an @releaseDomain, since xenstored
> discards its own record of the domain's existence as soon as it sees
> the domain "dying" and will not trigger @releaseDomain watches for
> domains it knows nothing about.  Arguably this is a bug in xenstored,
> and the whole @releaseDomain machinery is rather poor, but let us not
> fix that now.
> 
> Anyway, xl does not really want to know when the domain is ultimately
> destroyed.  It is enough for xl to know that it is on the way out, in
> the "dying" state (which leads later to destruction by Xen).
> 
> Also fix a bug where domain_death_xswatch_callback might read one
> domain beyond the valid data in its domaininfos array, by correctly
> ordering the checks for empty domain list, end of domain list, and our
> domain being missing.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

This seems to do what I would expect, I tried with "xl reboot", "xl
shutdown" & "xl destroy" as well as in-guest shutdown (which is no
different in reality from "xl shutdown"). No leaks and in each case it
rebooted, destroyed etc the domain as expected.

> ---
>  tools/libxl/libxl.c         |   57 ++++++++++++++++++++++++++++--------------
>  tools/libxl/libxl_types.idl |    4 +-
>  tools/libxl/xl_cmdimpl.c    |    4 +-
>  3 files changed, 42 insertions(+), 23 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 2758d4c..b74a4d9 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -685,6 +685,29 @@ int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid)
>      return ret;
>  }
>  
> +static void domain_death_occurred(libxl__egc *egc,
> +                                  libxl_evgen_domain_death **evg_upd,
> +                                  const char *why) {
> +    /* Removes **evg from the list and advances *evg_upd to the next
> +     * entry.  Call sites in _xswatch_callback must use "continue". */

There's no **evg in this context? ITYM *evg or just evg?

Also it's not clear which list this talks about since there is
death_list and death_reported as well as, presumably, a list of current
domain infos somewhere. Did you mean "moves evg from death_list to
death_reported list and advances *evg_upd ...."?

> +    EGC_GC;
> +    libxl_evgen_domain_death *const evg = *evg_upd;
> +
> +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " death %s", why);

LIBXL__LOG puts a space between the boilerplate and the message so you
end up with two spaces before "death" here.

Also the resultant messages are:
	" death destroyed"
	" death missing"
	" death dying"
in context that is:
        libxl: debug: libxl.c:696:domain_death_occurred:  death dying

Which could do with a noun or something. 

Or, maybe you meant s/death/domain/?

Other than those small nits:

Acked-/Tested-by: Ian Campbell <ian.campbell@citrix.com>

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:07:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrspE-0002Uf-DL; Mon, 30 Jan 2012 15:07:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RrspC-0002UW-Oj
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:07:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327935977!58980329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4817 invoked from network); 30 Jan 2012 15:06:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10368814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:07: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;
	Mon, 30 Jan 2012 15:07:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 30 Jan 2012 15:07:16 +0000
In-Reply-To: <20120127192214.GA14437@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327936037.26983.241.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> 
>  - This patch set solves the CPU banding problem I've seen with the
>    older netback. The older one  I could see X netback threads eating
> 80%
>    of CPU. With this one, the number is down to 13-14%. 

"CPU banding problem"?

If you had X threads using 80% before do you now see Y threads using
13-14% where Y is bigger or smaller than X? Is 80*X ~= 13*Y?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:07:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:07:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrspE-0002Uf-DL; Mon, 30 Jan 2012 15:07:20 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RrspC-0002UW-Oj
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:07:18 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327935977!58980329!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4817 invoked from network); 30 Jan 2012 15:06:17 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 15:06:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10368814"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:07: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;
	Mon, 30 Jan 2012 15:07:17 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 30 Jan 2012 15:07:16 +0000
In-Reply-To: <20120127192214.GA14437@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327936037.26983.241.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> 
>  - This patch set solves the CPU banding problem I've seen with the
>    older netback. The older one  I could see X netback threads eating
> 80%
>    of CPU. With this one, the number is down to 13-14%. 

"CPU banding problem"?

If you had X threads using 80% before do you now see Y threads using
13-14% where Y is bigger or smaller than X? Is 80*X ~= 13*Y?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:13:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 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 1Rrsus-0002k7-9l; Mon, 30 Jan 2012 15:13:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Rrsur-0002k2-IU
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:13:09 +0000
Received: from [85.158.138.51:51615] by server-2.bemta-3.messagelabs.com id
	DE/47-24515-483B62F4; Mon, 30 Jan 2012 15:13:08 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327936387!11199181!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMxNDgxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12941 invoked from network); 30 Jan 2012 15:13:08 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 15:13:08 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q0UFD1T8007766;
	Mon, 30 Jan 2012 16:13:01 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0UFD0C0016767;
	Mon, 30 Jan 2012 16:13:00 +0100
Message-ID: <4F26B37C.9000607@siemens.com>
Date: Mon, 30 Jan 2012 16:13:00 +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: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22F687.40904@siemens.com>
	<alpine.DEB.2.00.1201301132500.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201301132500.3196@kaball-desktop>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 1/6] xen: do not initialize the interval
	timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-30 12:39, Stefano Stabellini wrote:
> On Fri, 27 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-27 19:21, Stefano Stabellini wrote:
>>> PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
>>> this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> ---
>>>  hw/pc.c |    7 +++++--
>>>  1 files changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/pc.c b/hw/pc.c
>>> index 85304cf..7a7ce98 100644
>>> --- a/hw/pc.c
>>> +++ b/hw/pc.c
>>> @@ -43,6 +43,7 @@
>>>  #include "ui/qemu-spice.h"
>>>  #include "memory.h"
>>>  #include "exec-memory.h"
>>> +#include "arch_init.h"
>>>  
>>>  /* output Bochs bios info messages */
>>>  //#define DEBUG_BIOS
>>> @@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>>>      DriveInfo *fd[MAX_FD];
>>>      qemu_irq rtc_irq = NULL;
>>>      qemu_irq *a20_line;
>>> -    ISADevice *i8042, *port92, *vmmouse, *pit;
>>> +    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
>>>      qemu_irq *cpu_exit_irq;
>>>  
>>>      register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
>>> @@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>>>  
>>>      qemu_register_boot_set(pc_boot_set, *rtc_state);
>>>  
>>> -    pit = pit_init(isa_bus, 0x40, 0);
>>> +    if (!xen_available()) {
>>> +        pit = pit_init(isa_bus, 0x40, 0);
>>> +    }
>>>      pcspk_init(pit);
>>>  
>>>      for(i = 0; i < MAX_SERIAL_PORTS; i++) {
>>
>> Thus as guest accessing to port 0x61 will be able to crash qemu because
>> pit is NULL? Or do you emulate that port in the kernel? If not, you
>> likely want to move pcspk_init() under the same umbrella.
> 
> We already emulate both pit and port 0x61 in xen so a guest won't be
> able to crash qemu that easily :)

Which, btw, most likely breaks sound output via the speaker. We used to
fake 0x61 in the kernel as well, but now we properly emulated it in user
space again (well, upcoming qemu patches will, qemu-kvm is broken in
this regard).

> But now that you make me think about it, it makes sense to move
> pcspk_init under the same if, like you suggested.

Provided there is no use for user space, this would be consistent.

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 Jan 30 15:13:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 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 1Rrsus-0002k7-9l; Mon, 30 Jan 2012 15:13:10 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <jan.kiszka@siemens.com>) id 1Rrsur-0002k2-IU
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:13:09 +0000
Received: from [85.158.138.51:51615] by server-2.bemta-3.messagelabs.com id
	DE/47-24515-483B62F4; Mon, 30 Jan 2012 15:13:08 +0000
X-Env-Sender: jan.kiszka@siemens.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327936387!11199181!1
X-Originating-IP: [192.35.17.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjM1LjE3LjI4ID0+IDMxNDgxNA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12941 invoked from network); 30 Jan 2012 15:13:08 -0000
Received: from goliath.siemens.de (HELO goliath.siemens.de) (192.35.17.28)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 15:13:08 -0000
Received: from mail1.siemens.de (localhost [127.0.0.1])
	by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id q0UFD1T8007766;
	Mon, 30 Jan 2012 16:13:01 +0100
Received: from mchn199C.mchp.siemens.de ([139.25.109.49])
	by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q0UFD0C0016767;
	Mon, 30 Jan 2012 16:13:00 +0100
Message-ID: <4F26B37C.9000607@siemens.com>
Date: Mon, 30 Jan 2012 16:13:00 +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: <alpine.DEB.2.00.1201271814280.3196@kaball-desktop>
	<1327688498-12362-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<4F22F687.40904@siemens.com>
	<alpine.DEB.2.00.1201301132500.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201301132500.3196@kaball-desktop>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v3 1/6] xen: do not initialize the interval
	timer emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-30 12:39, Stefano Stabellini wrote:
> On Fri, 27 Jan 2012, Jan Kiszka wrote:
>> On 2012-01-27 19:21, Stefano Stabellini wrote:
>>> PIT is emulated by the hypervisor so we don't need to emulate it in Qemu:
>>> this patch prevents Qemu from waking up needlessly at PIT_FREQ on Xen.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> ---
>>>  hw/pc.c |    7 +++++--
>>>  1 files changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/pc.c b/hw/pc.c
>>> index 85304cf..7a7ce98 100644
>>> --- a/hw/pc.c
>>> +++ b/hw/pc.c
>>> @@ -43,6 +43,7 @@
>>>  #include "ui/qemu-spice.h"
>>>  #include "memory.h"
>>>  #include "exec-memory.h"
>>> +#include "arch_init.h"
>>>  
>>>  /* output Bochs bios info messages */
>>>  //#define DEBUG_BIOS
>>> @@ -1130,7 +1131,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>>>      DriveInfo *fd[MAX_FD];
>>>      qemu_irq rtc_irq = NULL;
>>>      qemu_irq *a20_line;
>>> -    ISADevice *i8042, *port92, *vmmouse, *pit;
>>> +    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
>>>      qemu_irq *cpu_exit_irq;
>>>  
>>>      register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
>>> @@ -1151,7 +1152,9 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
>>>  
>>>      qemu_register_boot_set(pc_boot_set, *rtc_state);
>>>  
>>> -    pit = pit_init(isa_bus, 0x40, 0);
>>> +    if (!xen_available()) {
>>> +        pit = pit_init(isa_bus, 0x40, 0);
>>> +    }
>>>      pcspk_init(pit);
>>>  
>>>      for(i = 0; i < MAX_SERIAL_PORTS; i++) {
>>
>> Thus as guest accessing to port 0x61 will be able to crash qemu because
>> pit is NULL? Or do you emulate that port in the kernel? If not, you
>> likely want to move pcspk_init() under the same umbrella.
> 
> We already emulate both pit and port 0x61 in xen so a guest won't be
> able to crash qemu that easily :)

Which, btw, most likely breaks sound output via the speaker. We used to
fake 0x61 in the kernel as well, but now we properly emulated it in user
space again (well, upcoming qemu patches will, qemu-kvm is broken in
this regard).

> But now that you make me think about it, it makes sense to move
> pcspk_init under the same if, like you suggested.

Provided there is no use for user space, this would be consistent.

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 Jan 30 15:19:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:19:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrt15-00036n-4E; Mon, 30 Jan 2012 15:19: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 1Rrt14-00036W-Cw
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:19:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327936746!50817285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18642 invoked from network); 30 Jan 2012 15:19:06 -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;
	30 Jan 2012 15:19:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10369271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:19: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, 30 Jan 2012 15:19: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
	1Rrt0x-0004GY-Vr; Mon, 30 Jan 2012 15:19:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrt0x-0006c0-Uw;
	Mon, 30 Jan 2012 15:19:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20262.46335.345850.567037@mariner.uk.xensource.com>
Date: Mon, 30 Jan 2012 15:19:27 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327935771.26983.239.camel@zakaz.uk.xensource.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
	<1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
	<1327935771.26983.239.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/2] libxl: treat "dying" domains as
 destroyed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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/2] libxl: treat "dying" domains as destroyed"):
> This seems to do what I would expect, I tried with "xl reboot", "xl
> shutdown" & "xl destroy" as well as in-guest shutdown (which is no
> different in reality from "xl shutdown"). No leaks and in each case it
> rebooted, destroyed etc the domain as expected.

Yes, great, thanks.

> > +static void domain_death_occurred(libxl__egc *egc,
> > +                                  libxl_evgen_domain_death **evg_upd,
> > +                                  const char *why) {
> > +    /* Removes **evg from the list and advances *evg_upd to the next
> > +     * entry.  Call sites in _xswatch_callback must use "continue". */
> 
> There's no **evg in this context? ITYM *evg or just evg?

I meant **evg_upd.  The actual struct is removed from the list, after
all.

> Also it's not clear which list this talks about since there is
> death_list and death_reported as well as, presumably, a list of current
> domain infos somewhere. Did you mean "moves evg from death_list to
> death_reported list and advances *evg_upd ...."?

Yes.

> > +    EGC_GC;
> > +    libxl_evgen_domain_death *const evg = *evg_upd;
> > +
> > +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " death %s", why);
> 
> LIBXL__LOG puts a space between the boilerplate and the message so you
> end up with two spaces before "death" here.
> 
> Also the resultant messages are:
> 	" death destroyed"
> 	" death missing"
> 	" death dying"
> in context that is:
>         libxl: debug: libxl.c:696:domain_death_occurred:  death dying
> 
> Which could do with a noun or something. 

I'll remove the word "death" (and the extra space).

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 Jan 30 15:19:53 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:19:53 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrt15-00036n-4E; Mon, 30 Jan 2012 15:19: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 1Rrt14-00036W-Cw
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:19:34 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327936746!50817285!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18642 invoked from network); 30 Jan 2012 15:19:06 -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;
	30 Jan 2012 15:19:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10369271"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:19: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, 30 Jan 2012 15:19: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
	1Rrt0x-0004GY-Vr; Mon, 30 Jan 2012 15:19:28 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrt0x-0006c0-Uw;
	Mon, 30 Jan 2012 15:19:27 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20262.46335.345850.567037@mariner.uk.xensource.com>
Date: Mon, 30 Jan 2012 15:19:27 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327935771.26983.239.camel@zakaz.uk.xensource.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
	<1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
	<1327935771.26983.239.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/2] libxl: treat "dying" domains as
 destroyed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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/2] libxl: treat "dying" domains as destroyed"):
> This seems to do what I would expect, I tried with "xl reboot", "xl
> shutdown" & "xl destroy" as well as in-guest shutdown (which is no
> different in reality from "xl shutdown"). No leaks and in each case it
> rebooted, destroyed etc the domain as expected.

Yes, great, thanks.

> > +static void domain_death_occurred(libxl__egc *egc,
> > +                                  libxl_evgen_domain_death **evg_upd,
> > +                                  const char *why) {
> > +    /* Removes **evg from the list and advances *evg_upd to the next
> > +     * entry.  Call sites in _xswatch_callback must use "continue". */
> 
> There's no **evg in this context? ITYM *evg or just evg?

I meant **evg_upd.  The actual struct is removed from the list, after
all.

> Also it's not clear which list this talks about since there is
> death_list and death_reported as well as, presumably, a list of current
> domain infos somewhere. Did you mean "moves evg from death_list to
> death_reported list and advances *evg_upd ...."?

Yes.

> > +    EGC_GC;
> > +    libxl_evgen_domain_death *const evg = *evg_upd;
> > +
> > +    LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, " death %s", why);
> 
> LIBXL__LOG puts a space between the boilerplate and the message so you
> end up with two spaces before "death" here.
> 
> Also the resultant messages are:
> 	" death destroyed"
> 	" death missing"
> 	" death dying"
> in context that is:
>         libxl: debug: libxl.c:696:domain_death_occurred:  death dying
> 
> Which could do with a noun or something. 

I'll remove the word "death" (and the extra space).

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 Jan 30 15:24:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrt59-0003Ji-QD; Mon, 30 Jan 2012 15:23:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rrt57-0003JY-R0
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:23:46 +0000
Received: from [85.158.138.51:37335] by server-2.bemta-3.messagelabs.com id
	2E/5D-24515-006B62F4; Mon, 30 Jan 2012 15:23:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327937022!6117171!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNTM0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17021 invoked from network); 30 Jan 2012 15:23:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 15:23:44 -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
	q0UFNdXX011777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 15:23:40 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0UFNcbv014718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 15:23:39 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0UFNcdJ008011; Mon, 30 Jan 2012 09:23:38 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 07:23:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 33246402B3; Mon, 30 Jan 2012 10:21:09 -0500 (EST)
Date: Mon, 30 Jan 2012 10:21:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120130152109.GA17923@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327936037.26983.241.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327936037.26983.241.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F26B5FD.0068,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 03:07:16PM +0000, Ian Campbell wrote:
> On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> >  - This patch set solves the CPU banding problem I've seen with the
> >    older netback. The older one  I could see X netback threads eating
> > 80%
> >    of CPU. With this one, the number is down to 13-14%. 
> 
> "CPU banding problem"?
> 
> If you had X threads using 80% before do you now see Y threads using
> 13-14% where Y is bigger or smaller than X? Is 80*X ~= 13*Y?

Yes. ~=. The count looked to be the same.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:24:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrt59-0003Ji-QD; Mon, 30 Jan 2012 15:23:47 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1Rrt57-0003JY-R0
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:23:46 +0000
Received: from [85.158.138.51:37335] by server-2.bemta-3.messagelabs.com id
	2E/5D-24515-006B62F4; Mon, 30 Jan 2012 15:23:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327937022!6117171!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNTM0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17021 invoked from network); 30 Jan 2012 15:23:44 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 15:23:44 -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
	q0UFNdXX011777
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 15:23:40 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0UFNcbv014718
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 15:23:39 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0UFNcdJ008011; Mon, 30 Jan 2012 09:23:38 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 07:23:38 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 33246402B3; Mon, 30 Jan 2012 10:21:09 -0500 (EST)
Date: Mon, 30 Jan 2012 10:21:09 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Message-ID: <20120130152109.GA17923@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327936037.26983.241.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327936037.26983.241.camel@zakaz.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090204.4F26B5FD.0068,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 03:07:16PM +0000, Ian Campbell wrote:
> On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> >  - This patch set solves the CPU banding problem I've seen with the
> >    older netback. The older one  I could see X netback threads eating
> > 80%
> >    of CPU. With this one, the number is down to 13-14%. 
> 
> "CPU banding problem"?
> 
> If you had X threads using 80% before do you now see Y threads using
> 13-14% where Y is bigger or smaller than X? Is 80*X ~= 13*Y?

Yes. ~=. The count looked to be the same.

> 
> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:24:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrt5i-0003ND-By; Mon, 30 Jan 2012 15:24:22 +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 1Rrt5h-0003MV-Hc
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:24:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327937055!4656650!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14391 invoked from network); 30 Jan 2012 15:24:15 -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;
	30 Jan 2012 15:24:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10369409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:24:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 15:24:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rrt5a-0004IE-P9; Mon, 30 Jan 2012 15:24:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrt5a-00070D-OF;
	Mon, 30 Jan 2012 15:24:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20262.46622.737998.133475@mariner.uk.xensource.com>
Date: Mon, 30 Jan 2012 15:24:14 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327935771.26983.239.camel@zakaz.uk.xensource.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
	<1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
	<1327935771.26983.239.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/2] libxl: treat "dying" domains as
 destroyed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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/2] libxl: treat "dying" domains as destroyed"):
> Other than those small nits:
> Acked-/Tested-by: Ian Campbell <ian.campbell@citrix.com>

Thanks; having fixed those I've applied both.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:24:37 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:24:37 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrt5i-0003ND-By; Mon, 30 Jan 2012 15:24:22 +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 1Rrt5h-0003MV-Hc
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:24:21 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1327937055!4656650!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14391 invoked from network); 30 Jan 2012 15:24:15 -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;
	30 Jan 2012 15:24:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10369409"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:24:15 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 15:24:15 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1Rrt5a-0004IE-P9; Mon, 30 Jan 2012 15:24:14 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1Rrt5a-00070D-OF;
	Mon, 30 Jan 2012 15:24:14 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20262.46622.737998.133475@mariner.uk.xensource.com>
Date: Mon, 30 Jan 2012 15:24:14 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327935771.26983.239.camel@zakaz.uk.xensource.com>
References: <20262.41566.25707.184425@mariner.uk.xensource.com>
	<1327932087-25001-2-git-send-email-ian.jackson@eu.citrix.com>
	<1327935771.26983.239.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/2] libxl: treat "dying" domains as
 destroyed
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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/2] libxl: treat "dying" domains as destroyed"):
> Other than those small nits:
> Acked-/Tested-by: Ian Campbell <ian.campbell@citrix.com>

Thanks; having fixed those I've applied both.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:32:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtDQ-0003kR-Ao; Mon, 30 Jan 2012 15:32: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 1RrtDP-0003kM-3F
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:32:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327937515!50819450!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6984 invoked from network); 30 Jan 2012 15:31:55 -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;
	30 Jan 2012 15:31:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10369648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:32: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; Mon, 30 Jan 2012 15:32:16 +0000
Date: Mon, 30 Jan 2012 15:33:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120127184538.GA18321@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201301510240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
	<1327689097-12788-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120127184538.GA18321@phenom.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] hvc_xen: implement multiconsole
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > +static void xencons_disconnect_backend(struct xencons_info *info)
> > +{
> > +	if (info->irq > 0)
> > +		unbind_from_irqhandler(info->irq, NULL);
> > +	info->irq = 0;
> > +	if (info->evtchn > 0)
> > +		xenbus_free_evtchn(info->xbdev, info->evtchn);
> > +	info->evtchn = 0;
> > +	if (info->gntref > 0)
> > +		gnttab_free_grant_references(info->gntref);
> > +	info->gntref = 0;
> > +	if (info->hvc != NULL)
> > +		hvc_remove(info->hvc);
> > +	info->hvc = NULL;
> > +}
> > +
> > +static void xencons_free(struct xencons_info *info)
> > +{
> > +	xencons_disconnect_backend(info);
> > +	free_page((unsigned long)info->intf);
> > +	info->intf = NULL;
> > +	info->vtermno = 0;
> > +	kfree(info);
> > +}
> > +
> > +static int xencons_remove(struct xenbus_device *dev)
> > +{
> > +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> > +
> 
> I would say put
> 	xencons_disconnect_backend(info)
> 
> here, that way it calls hvc_remove first, and then this would
> delete an "not-called" anymore structure.
> 
> > +	spin_lock(&xencons_lock);
> > +	list_del(&info->list);
> > +	spin_unlock(&xencons_lock);
> > +	xencons_free(info);
> 
> >  	return 0;
> >  }
> >
> 
> .. snip..
> > +
> > +static const struct xenbus_device_id xencons_ids[] = {
> > +	{ "console" },
> > +	{ "" }
> > +};
> > +
> > +
> >  static void __exit xen_hvc_fini(void)
> >  {
> > -	if (hvc)
> > -		hvc_remove(hvc);
> > +	struct xencons_info *entry, *next;
> > +
> > +	if (list_empty(&xenconsoles))
> > +			return;
> > +
> > +	spin_lock(&xencons_lock);
> 
> Take that spin-lock out.
> 
> > +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> > +		list_del(&entry->list);
> > +		if (entry->xbdev)
> > +			xencons_remove(entry->xbdev);
> 
> This guy deletes itself from the list..
> > +		else {
> > +			if (entry->irq > 0)
> > +				unbind_from_irqhandler(entry->irq, NULL);
> > +			if (entry->hvc);
> > +				hvc_remove(entry->hvc);
> > +			kfree(entry);
> 
> ..but this one does not.  You could make xencons_remove just remove
> itself from the list and nothing else. Then rename it to 'xencons_remove_itself' perhaps?
> 
> After that, introduce a new function 'xencons_delete' that would call
> xecons_disconnect_backend, xencons_remove_itself, and xencons_free?

Thanks for spotting the deadlock and the useful suggestions.
I have reworked the shutdown path a bit, making sure that we don't take
any locks twice and that we call hvc_remove before list_del (see next
version of the patch, to be posted soon).



> >  
> > +static struct xenbus_driver xencons_driver = {
> 
> This needs to be wrapped in the new macro that Jan prepared.
> DEFINE_XENBUS_DRIVER (73db144b58a32fc39733db6a7e1fe582072ad26a)

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:32:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:32:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtDQ-0003kR-Ao; Mon, 30 Jan 2012 15:32: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 1RrtDP-0003kM-3F
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:32:19 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327937515!50819450!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6984 invoked from network); 30 Jan 2012 15:31:55 -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;
	30 Jan 2012 15:31:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10369648"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:32: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; Mon, 30 Jan 2012 15:32:16 +0000
Date: Mon, 30 Jan 2012 15:33:48 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120127184538.GA18321@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201301510240.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271823240.3196@kaball-desktop>
	<1327689097-12788-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<20120127184538.GA18321@phenom.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/2] hvc_xen: implement multiconsole
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 27 Jan 2012, Konrad Rzeszutek Wilk wrote:
> > +static void xencons_disconnect_backend(struct xencons_info *info)
> > +{
> > +	if (info->irq > 0)
> > +		unbind_from_irqhandler(info->irq, NULL);
> > +	info->irq = 0;
> > +	if (info->evtchn > 0)
> > +		xenbus_free_evtchn(info->xbdev, info->evtchn);
> > +	info->evtchn = 0;
> > +	if (info->gntref > 0)
> > +		gnttab_free_grant_references(info->gntref);
> > +	info->gntref = 0;
> > +	if (info->hvc != NULL)
> > +		hvc_remove(info->hvc);
> > +	info->hvc = NULL;
> > +}
> > +
> > +static void xencons_free(struct xencons_info *info)
> > +{
> > +	xencons_disconnect_backend(info);
> > +	free_page((unsigned long)info->intf);
> > +	info->intf = NULL;
> > +	info->vtermno = 0;
> > +	kfree(info);
> > +}
> > +
> > +static int xencons_remove(struct xenbus_device *dev)
> > +{
> > +	struct xencons_info *info = dev_get_drvdata(&dev->dev);
> > +
> 
> I would say put
> 	xencons_disconnect_backend(info)
> 
> here, that way it calls hvc_remove first, and then this would
> delete an "not-called" anymore structure.
> 
> > +	spin_lock(&xencons_lock);
> > +	list_del(&info->list);
> > +	spin_unlock(&xencons_lock);
> > +	xencons_free(info);
> 
> >  	return 0;
> >  }
> >
> 
> .. snip..
> > +
> > +static const struct xenbus_device_id xencons_ids[] = {
> > +	{ "console" },
> > +	{ "" }
> > +};
> > +
> > +
> >  static void __exit xen_hvc_fini(void)
> >  {
> > -	if (hvc)
> > -		hvc_remove(hvc);
> > +	struct xencons_info *entry, *next;
> > +
> > +	if (list_empty(&xenconsoles))
> > +			return;
> > +
> > +	spin_lock(&xencons_lock);
> 
> Take that spin-lock out.
> 
> > +	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
> > +		list_del(&entry->list);
> > +		if (entry->xbdev)
> > +			xencons_remove(entry->xbdev);
> 
> This guy deletes itself from the list..
> > +		else {
> > +			if (entry->irq > 0)
> > +				unbind_from_irqhandler(entry->irq, NULL);
> > +			if (entry->hvc);
> > +				hvc_remove(entry->hvc);
> > +			kfree(entry);
> 
> ..but this one does not.  You could make xencons_remove just remove
> itself from the list and nothing else. Then rename it to 'xencons_remove_itself' perhaps?
> 
> After that, introduce a new function 'xencons_delete' that would call
> xecons_disconnect_backend, xencons_remove_itself, and xencons_free?

Thanks for spotting the deadlock and the useful suggestions.
I have reworked the shutdown path a bit, making sure that we don't take
any locks twice and that we call hvc_remove before list_del (see next
version of the patch, to be posted soon).



> >  
> > +static struct xenbus_driver xencons_driver = {
> 
> This needs to be wrapped in the new macro that Jan prepared.
> DEFINE_XENBUS_DRIVER (73db144b58a32fc39733db6a7e1fe582072ad26a)

OK

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:50:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtUc-0003yk-4g; Mon, 30 Jan 2012 15:50: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 1RrtUa-0003yf-Ew
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:50:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327938598!10604154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15628 invoked from network); 30 Jan 2012 15:49:58 -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;
	30 Jan 2012 15:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10370157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:49: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, 30 Jan 2012 15:49:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 30 Jan 2012 15:49:57 +0000
In-Reply-To: <20120130152109.GA17923@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327936037.26983.241.camel@zakaz.uk.xensource.com>
	<20120130152109.GA17923@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327938597.26983.246.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 15:21 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 03:07:16PM +0000, Ian Campbell wrote:
> > On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> > > 
> > >  - This patch set solves the CPU banding problem I've seen with the
> > >    older netback. The older one  I could see X netback threads eating
> > > 80%
> > >    of CPU. With this one, the number is down to 13-14%. 
> > 
> > "CPU banding problem"?
> > 
> > If you had X threads using 80% before do you now see Y threads using
> > 13-14% where Y is bigger or smaller than X? Is 80*X ~= 13*Y?
> 
> Yes. ~=. The count looked to be the same.

Great, that's as expected, the same work is more fairly distributed -- I
thought you might be suggesting the total had gone down from
X*80%->X*13% which is not what I thought this series would be doing!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:50:25 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:50:25 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtUc-0003yk-4g; Mon, 30 Jan 2012 15:50: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 1RrtUa-0003yf-Ew
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:50:04 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1327938598!10604154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15628 invoked from network); 30 Jan 2012 15:49:58 -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;
	30 Jan 2012 15:49:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10370157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 15:49: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, 30 Jan 2012 15:49:57 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 30 Jan 2012 15:49:57 +0000
In-Reply-To: <20120130152109.GA17923@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327936037.26983.241.camel@zakaz.uk.xensource.com>
	<20120130152109.GA17923@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327938597.26983.246.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Paul Durrant <Paul.Durrant@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 15:21 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 03:07:16PM +0000, Ian Campbell wrote:
> > On Fri, 2012-01-27 at 19:22 +0000, Konrad Rzeszutek Wilk wrote:
> > > 
> > >  - This patch set solves the CPU banding problem I've seen with the
> > >    older netback. The older one  I could see X netback threads eating
> > > 80%
> > >    of CPU. With this one, the number is down to 13-14%. 
> > 
> > "CPU banding problem"?
> > 
> > If you had X threads using 80% before do you now see Y threads using
> > 13-14% where Y is bigger or smaller than X? Is 80*X ~= 13*Y?
> 
> Yes. ~=. The count looked to be the same.

Great, that's as expected, the same work is more fairly distributed -- I
thought you might be suggesting the total had gone down from
X*80%->X*13% which is not what I thought this series would be doing!

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdi-00049o-Ku; Mon, 30 Jan 2012 15:59:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rrtdh-00049c-3x
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:29 +0000
Received: from [85.158.138.51:42077] by server-10.bemta-3.messagelabs.com id
	2F/1F-20948-06EB62F4; Mon, 30 Jan 2012 15:59:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327939166!6123244!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28694 invoked from network); 30 Jan 2012 15:59:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939166; l=8834;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=z8RqgpI4dQJt5F6+cMvdYae5Dv4=;
	b=jUBqrfjyfbStipM5EFQXpwIq6i1cJ9SueeCwqNTRofQK1HYgx//aI5niCHtm+ZXrTOF
	fxye1hx/+OGqK5Mu9ezxOtcLysQUvWDcBq2Ep5nbBb+o9VsnoAHx90UA54o2HJJk6Spe7
	0Qbz+qgxU6jjPGtOcF39zlUDaTbhLvf3L3E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (klopstock mo56) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 501ae4o0UEt1MW
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:21 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B82C81863C
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 649791966e1a8fb5e363d8745250bcd120871800
Message-Id: <649791966e1a8fb5e363.1327939170@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 10] xenpaging: unify 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 1327937800 -3600
# Node ID 649791966e1a8fb5e363d8745250bcd120871800
# Parent  b7906ad28153042726866cfbef40f8adf8dc1520
xenpaging: unify error handling

Update functions to return -1 on error, 0 on success.
Simplify init_page() and make sure errno is assigned.
Adjust PERROR/ERROR usage, use PERROR early because it overwrites errno.
Adjust xenpaging_populate_page() to handle gfn as unsigned long.

Update xenpaging exit code handling. xenpaging_teardown cant possible
fail. Adjust mainloop to indicate possible errors to final exit.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b7906ad28153 -r 649791966e1a tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -98,7 +98,7 @@ static int xenpaging_wait_for_event_or_t
             return 0;
 
         PERROR("Poll exited with an error");
-        return -errno;
+        return -1;
     }
 
     /* First check for guest shutdown */
@@ -116,6 +116,7 @@ static int xenpaging_wait_for_event_or_t
                 {
                     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
                     interrupted = SIGQUIT;
+                    /* No further poll result processing */
                     rc = 0;
                 }
             }
@@ -183,26 +184,20 @@ static int xenpaging_get_tot_pages(struc
 static void *init_page(void)
 {
     void *buffer;
-    int ret;
 
     /* Allocated page memory */
-    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_alloc;
+    errno = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
+    if ( errno != 0 )
+        return NULL;
 
     /* Lock buffer in memory so it can't be paged out */
-    ret = mlock(buffer, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_lock;
+    if ( mlock(buffer, PAGE_SIZE) < 0 )
+    {
+        free(buffer);
+        buffer = NULL;
+    }
 
     return buffer;
-
- out_init:
-    munlock(buffer, PAGE_SIZE);
- out_lock:
-    free(buffer);
- out_alloc:
-    return NULL;
 }
 
 static void usage(void)
@@ -449,7 +444,7 @@ static struct xenpaging *xenpaging_init(
     paging_buffer = init_page();
     if ( !paging_buffer )
     {
-        ERROR("Creating page aligned load buffer");
+        PERROR("Creating page aligned load buffer");
         goto err;
     }
 
@@ -485,18 +480,14 @@ static struct xenpaging *xenpaging_init(
     return NULL;
 }
 
-static int xenpaging_teardown(struct xenpaging *paging)
+static void xenpaging_teardown(struct xenpaging *paging)
 {
     int rc;
-    xc_interface *xch;
-
-    if ( paging == NULL )
-        return 0;
+    xc_interface *xch = paging->xc_handle;
 
     xs_unwatch(paging->xs_handle, watch_target_tot_pages, "");
     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
 
-    xch = paging->xc_handle;
     paging->xc_handle = NULL;
     /* Tear down domain paging in Xen */
     rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id);
@@ -528,13 +519,8 @@ static int xenpaging_teardown(struct xen
     rc = xc_interface_close(xch);
     if ( rc != 0 )
     {
-        PERROR("Error closing connection to xen");
+        ERROR("Error closing connection to xen");
     }
-
-    return 0;
-
- err:
-    return -1;
 }
 
 static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
@@ -684,21 +670,19 @@ static int xenpaging_resume_page(struct 
     return ret;
 }
 
-static int xenpaging_populate_page(struct xenpaging *paging,
-    xen_pfn_t gfn, int fd, int i)
+static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
-    void *page;
     int ret;
     unsigned char oom = 0;
 
-    DPRINTF("populate_page < gfn %"PRI_xen_pfn" pageslot %d\n", gfn, i);
+    DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
     ret = read_page(fd, paging_buffer, i);
     if ( ret != 0 )
     {
-        ERROR("Error reading page");
+        PERROR("Error reading page");
         goto out;
     }
 
@@ -707,17 +691,18 @@ static int xenpaging_populate_page(struc
         /* Tell Xen to allocate a page for the domain */
         ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
                                     paging_buffer);
-        if ( ret != 0 )
+        if ( ret < 0 )
         {
             if ( errno == ENOMEM )
             {
                 if ( oom++ == 0 )
-                    DPRINTF("ENOMEM while preparing gfn %"PRI_xen_pfn"\n", gfn);
+                    DPRINTF("ENOMEM while preparing gfn %lx\n", gfn);
                 sleep(1);
                 continue;
             }
-            PERROR("Error loading %"PRI_xen_pfn" during page-in", gfn);
-            goto out;
+            PERROR("Error loading %lx during page-in", gfn);
+            ret = -1;
+            break;
         }
     }
     while ( ret && !interrupted );
@@ -748,6 +733,11 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
+/* Evict one gfn and write it to the given slot
+ * Returns < 0 on fatal error
+ * Returns 0 on successful evict
+ * Returns > 0 if no gfn can be evicted
+ */
 static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
@@ -771,13 +761,13 @@ static int evict_victim(struct xenpaging
                 xenpaging_mem_paging_flush_ioemu_cache(paging);
                 num_paged_out = paging->num_paged_out;
             }
-            ret = -ENOSPC;
+            ret = ENOSPC;
             goto out;
         }
 
         if ( interrupted )
         {
-            ret = -EINTR;
+            ret = EINTR;
             goto out;
         }
 
@@ -788,7 +778,7 @@ static int evict_victim(struct xenpaging
     while ( ret );
 
     if ( test_and_set_bit(gfn, paging->bitmap) )
-        ERROR("Page has been evicted before");
+        ERROR("Page %lx has been evicted before", gfn);
 
     ret = 0;
 
@@ -796,7 +786,11 @@ static int evict_victim(struct xenpaging
     return ret;
 }
 
-/* Evict a batch of pages and write them to a free slot in the paging file */
+/* Evict a batch of pages and write them to a free slot in the paging file
+ * Returns < 0 on fatal error
+ * Returns 0 if no gfn can be evicted
+ * Returns > 0 on successful evict
+ */
 static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
@@ -809,12 +803,12 @@ static int evict_pages(struct xenpaging 
             continue;
 
         rc = evict_victim(paging, fd, slot);
-        if ( rc == -ENOSPC )
+        if ( rc )
+        {
+            num = rc < 0 ? -1 : num;
             break;
-        if ( rc == -EINTR )
-            break;
-        if ( num && num % 100 == 0 )
-            DPRINTF("%d pages evicted\n", num);
+        }
+
         num++;
     }
     return num;
@@ -829,8 +823,7 @@ int main(int argc, char *argv[])
     int num, prev_num = 0;
     int slot;
     int tot_pages;
-    int rc = -1;
-    int rc1;
+    int rc;
     xc_interface *xch;
 
     int open_flags = O_CREAT | O_TRUNC | O_RDWR;
@@ -875,7 +868,7 @@ int main(int argc, char *argv[])
         rc = xenpaging_wait_for_event_or_timeout(paging);
         if ( rc < 0 )
         {
-            PERROR("Error getting event");
+            ERROR("Error getting event");
             goto out;
         }
         else if ( rc != 0 )
@@ -885,6 +878,9 @@ int main(int argc, char *argv[])
 
         while ( RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
         {
+            /* Indicate possible error */
+            rc = 1;
+
             get_request(&paging->mem_event, &req);
 
             if ( req.gfn > paging->max_pages )
@@ -915,10 +911,9 @@ int main(int argc, char *argv[])
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
-                    if ( rc != 0 )
+                    if ( xenpaging_populate_page(paging, req.gfn, fd, slot) < 0 )
                     {
-                        PERROR("Error populating page %"PRIx64"", req.gfn);
+                        ERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
                     }
                 }
@@ -928,8 +923,7 @@ int main(int argc, char *argv[])
                 rsp.vcpu_id = req.vcpu_id;
                 rsp.flags = req.flags;
 
-                rc = xenpaging_resume_page(paging, &rsp, 1);
-                if ( rc != 0 )
+                if ( xenpaging_resume_page(paging, &rsp, 1) < 0 )
                 {
                     PERROR("Error resuming page %"PRIx64"", req.gfn);
                     goto out;
@@ -955,8 +949,7 @@ int main(int argc, char *argv[])
                     rsp.vcpu_id = req.vcpu_id;
                     rsp.flags = req.flags;
 
-                    rc = xenpaging_resume_page(paging, &rsp, 0);
-                    if ( rc != 0 )
+                    if ( xenpaging_resume_page(paging, &rsp, 0) < 0 )
                     {
                         PERROR("Error resuming page %"PRIx64"", req.gfn);
                         goto out;
@@ -983,6 +976,9 @@ int main(int argc, char *argv[])
         if ( interrupted )
             break;
 
+        /* Indicate possible error */
+        rc = 1;
+
         /* Check if the target has been reached already */
         tot_pages = xenpaging_get_tot_pages(paging);
         if ( tot_pages < 0 )
@@ -1009,7 +1005,8 @@ int main(int argc, char *argv[])
                 paging->use_poll_timeout = 0;
                 num = 42;
             }
-            evict_pages(paging, fd, num);
+            if ( evict_pages(paging, fd, num) < 0 )
+                goto out;
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -1029,6 +1026,10 @@ int main(int argc, char *argv[])
         }
 
     }
+
+    /* No error */
+    rc = 0;
+
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
  out:
@@ -1036,13 +1037,9 @@ int main(int argc, char *argv[])
     unlink_pagefile();
 
     /* Tear down domain paging */
-    rc1 = xenpaging_teardown(paging);
-    if ( rc1 != 0 )
-        fprintf(stderr, "Error tearing down paging");
+    xenpaging_teardown(paging);
 
-    if ( rc == 0 )
-        rc = rc1;
-    return rc;
+    return rc ? 2 : 0;
 }
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdi-00049o-Ku; Mon, 30 Jan 2012 15:59:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rrtdh-00049c-3x
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:29 +0000
Received: from [85.158.138.51:42077] by server-10.bemta-3.messagelabs.com id
	2F/1F-20948-06EB62F4; Mon, 30 Jan 2012 15:59:28 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327939166!6123244!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28694 invoked from network); 30 Jan 2012 15:59:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-13.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939166; l=8834;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=z8RqgpI4dQJt5F6+cMvdYae5Dv4=;
	b=jUBqrfjyfbStipM5EFQXpwIq6i1cJ9SueeCwqNTRofQK1HYgx//aI5niCHtm+ZXrTOF
	fxye1hx/+OGqK5Mu9ezxOtcLysQUvWDcBq2Ep5nbBb+o9VsnoAHx90UA54o2HJJk6Spe7
	0Qbz+qgxU6jjPGtOcF39zlUDaTbhLvf3L3E=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (klopstock mo56) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id 501ae4o0UEt1MW
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:21 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B82C81863C
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 649791966e1a8fb5e363d8745250bcd120871800
Message-Id: <649791966e1a8fb5e363.1327939170@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:30 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 07 of 10] xenpaging: unify 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 1327937800 -3600
# Node ID 649791966e1a8fb5e363d8745250bcd120871800
# Parent  b7906ad28153042726866cfbef40f8adf8dc1520
xenpaging: unify error handling

Update functions to return -1 on error, 0 on success.
Simplify init_page() and make sure errno is assigned.
Adjust PERROR/ERROR usage, use PERROR early because it overwrites errno.
Adjust xenpaging_populate_page() to handle gfn as unsigned long.

Update xenpaging exit code handling. xenpaging_teardown cant possible
fail. Adjust mainloop to indicate possible errors to final exit.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r b7906ad28153 -r 649791966e1a tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -98,7 +98,7 @@ static int xenpaging_wait_for_event_or_t
             return 0;
 
         PERROR("Poll exited with an error");
-        return -errno;
+        return -1;
     }
 
     /* First check for guest shutdown */
@@ -116,6 +116,7 @@ static int xenpaging_wait_for_event_or_t
                 {
                     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
                     interrupted = SIGQUIT;
+                    /* No further poll result processing */
                     rc = 0;
                 }
             }
@@ -183,26 +184,20 @@ static int xenpaging_get_tot_pages(struc
 static void *init_page(void)
 {
     void *buffer;
-    int ret;
 
     /* Allocated page memory */
-    ret = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_alloc;
+    errno = posix_memalign(&buffer, PAGE_SIZE, PAGE_SIZE);
+    if ( errno != 0 )
+        return NULL;
 
     /* Lock buffer in memory so it can't be paged out */
-    ret = mlock(buffer, PAGE_SIZE);
-    if ( ret != 0 )
-        goto out_lock;
+    if ( mlock(buffer, PAGE_SIZE) < 0 )
+    {
+        free(buffer);
+        buffer = NULL;
+    }
 
     return buffer;
-
- out_init:
-    munlock(buffer, PAGE_SIZE);
- out_lock:
-    free(buffer);
- out_alloc:
-    return NULL;
 }
 
 static void usage(void)
@@ -449,7 +444,7 @@ static struct xenpaging *xenpaging_init(
     paging_buffer = init_page();
     if ( !paging_buffer )
     {
-        ERROR("Creating page aligned load buffer");
+        PERROR("Creating page aligned load buffer");
         goto err;
     }
 
@@ -485,18 +480,14 @@ static struct xenpaging *xenpaging_init(
     return NULL;
 }
 
-static int xenpaging_teardown(struct xenpaging *paging)
+static void xenpaging_teardown(struct xenpaging *paging)
 {
     int rc;
-    xc_interface *xch;
-
-    if ( paging == NULL )
-        return 0;
+    xc_interface *xch = paging->xc_handle;
 
     xs_unwatch(paging->xs_handle, watch_target_tot_pages, "");
     xs_unwatch(paging->xs_handle, "@releaseDomain", watch_token);
 
-    xch = paging->xc_handle;
     paging->xc_handle = NULL;
     /* Tear down domain paging in Xen */
     rc = xc_mem_paging_disable(xch, paging->mem_event.domain_id);
@@ -528,13 +519,8 @@ static int xenpaging_teardown(struct xen
     rc = xc_interface_close(xch);
     if ( rc != 0 )
     {
-        PERROR("Error closing connection to xen");
+        ERROR("Error closing connection to xen");
     }
-
-    return 0;
-
- err:
-    return -1;
 }
 
 static void get_request(struct mem_event *mem_event, mem_event_request_t *req)
@@ -684,21 +670,19 @@ static int xenpaging_resume_page(struct 
     return ret;
 }
 
-static int xenpaging_populate_page(struct xenpaging *paging,
-    xen_pfn_t gfn, int fd, int i)
+static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int fd, int i)
 {
     xc_interface *xch = paging->xc_handle;
-    void *page;
     int ret;
     unsigned char oom = 0;
 
-    DPRINTF("populate_page < gfn %"PRI_xen_pfn" pageslot %d\n", gfn, i);
+    DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
     ret = read_page(fd, paging_buffer, i);
     if ( ret != 0 )
     {
-        ERROR("Error reading page");
+        PERROR("Error reading page");
         goto out;
     }
 
@@ -707,17 +691,18 @@ static int xenpaging_populate_page(struc
         /* Tell Xen to allocate a page for the domain */
         ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
                                     paging_buffer);
-        if ( ret != 0 )
+        if ( ret < 0 )
         {
             if ( errno == ENOMEM )
             {
                 if ( oom++ == 0 )
-                    DPRINTF("ENOMEM while preparing gfn %"PRI_xen_pfn"\n", gfn);
+                    DPRINTF("ENOMEM while preparing gfn %lx\n", gfn);
                 sleep(1);
                 continue;
             }
-            PERROR("Error loading %"PRI_xen_pfn" during page-in", gfn);
-            goto out;
+            PERROR("Error loading %lx during page-in", gfn);
+            ret = -1;
+            break;
         }
     }
     while ( ret && !interrupted );
@@ -748,6 +733,11 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
+/* Evict one gfn and write it to the given slot
+ * Returns < 0 on fatal error
+ * Returns 0 on successful evict
+ * Returns > 0 if no gfn can be evicted
+ */
 static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
@@ -771,13 +761,13 @@ static int evict_victim(struct xenpaging
                 xenpaging_mem_paging_flush_ioemu_cache(paging);
                 num_paged_out = paging->num_paged_out;
             }
-            ret = -ENOSPC;
+            ret = ENOSPC;
             goto out;
         }
 
         if ( interrupted )
         {
-            ret = -EINTR;
+            ret = EINTR;
             goto out;
         }
 
@@ -788,7 +778,7 @@ static int evict_victim(struct xenpaging
     while ( ret );
 
     if ( test_and_set_bit(gfn, paging->bitmap) )
-        ERROR("Page has been evicted before");
+        ERROR("Page %lx has been evicted before", gfn);
 
     ret = 0;
 
@@ -796,7 +786,11 @@ static int evict_victim(struct xenpaging
     return ret;
 }
 
-/* Evict a batch of pages and write them to a free slot in the paging file */
+/* Evict a batch of pages and write them to a free slot in the paging file
+ * Returns < 0 on fatal error
+ * Returns 0 if no gfn can be evicted
+ * Returns > 0 on successful evict
+ */
 static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
@@ -809,12 +803,12 @@ static int evict_pages(struct xenpaging 
             continue;
 
         rc = evict_victim(paging, fd, slot);
-        if ( rc == -ENOSPC )
+        if ( rc )
+        {
+            num = rc < 0 ? -1 : num;
             break;
-        if ( rc == -EINTR )
-            break;
-        if ( num && num % 100 == 0 )
-            DPRINTF("%d pages evicted\n", num);
+        }
+
         num++;
     }
     return num;
@@ -829,8 +823,7 @@ int main(int argc, char *argv[])
     int num, prev_num = 0;
     int slot;
     int tot_pages;
-    int rc = -1;
-    int rc1;
+    int rc;
     xc_interface *xch;
 
     int open_flags = O_CREAT | O_TRUNC | O_RDWR;
@@ -875,7 +868,7 @@ int main(int argc, char *argv[])
         rc = xenpaging_wait_for_event_or_timeout(paging);
         if ( rc < 0 )
         {
-            PERROR("Error getting event");
+            ERROR("Error getting event");
             goto out;
         }
         else if ( rc != 0 )
@@ -885,6 +878,9 @@ int main(int argc, char *argv[])
 
         while ( RING_HAS_UNCONSUMED_REQUESTS(&paging->mem_event.back_ring) )
         {
+            /* Indicate possible error */
+            rc = 1;
+
             get_request(&paging->mem_event, &req);
 
             if ( req.gfn > paging->max_pages )
@@ -915,10 +911,9 @@ int main(int argc, char *argv[])
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
-                    if ( rc != 0 )
+                    if ( xenpaging_populate_page(paging, req.gfn, fd, slot) < 0 )
                     {
-                        PERROR("Error populating page %"PRIx64"", req.gfn);
+                        ERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
                     }
                 }
@@ -928,8 +923,7 @@ int main(int argc, char *argv[])
                 rsp.vcpu_id = req.vcpu_id;
                 rsp.flags = req.flags;
 
-                rc = xenpaging_resume_page(paging, &rsp, 1);
-                if ( rc != 0 )
+                if ( xenpaging_resume_page(paging, &rsp, 1) < 0 )
                 {
                     PERROR("Error resuming page %"PRIx64"", req.gfn);
                     goto out;
@@ -955,8 +949,7 @@ int main(int argc, char *argv[])
                     rsp.vcpu_id = req.vcpu_id;
                     rsp.flags = req.flags;
 
-                    rc = xenpaging_resume_page(paging, &rsp, 0);
-                    if ( rc != 0 )
+                    if ( xenpaging_resume_page(paging, &rsp, 0) < 0 )
                     {
                         PERROR("Error resuming page %"PRIx64"", req.gfn);
                         goto out;
@@ -983,6 +976,9 @@ int main(int argc, char *argv[])
         if ( interrupted )
             break;
 
+        /* Indicate possible error */
+        rc = 1;
+
         /* Check if the target has been reached already */
         tot_pages = xenpaging_get_tot_pages(paging);
         if ( tot_pages < 0 )
@@ -1009,7 +1005,8 @@ int main(int argc, char *argv[])
                 paging->use_poll_timeout = 0;
                 num = 42;
             }
-            evict_pages(paging, fd, num);
+            if ( evict_pages(paging, fd, num) < 0 )
+                goto out;
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -1029,6 +1026,10 @@ int main(int argc, char *argv[])
         }
 
     }
+
+    /* No error */
+    rc = 0;
+
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
  out:
@@ -1036,13 +1037,9 @@ int main(int argc, char *argv[])
     unlink_pagefile();
 
     /* Tear down domain paging */
-    rc1 = xenpaging_teardown(paging);
-    if ( rc1 != 0 )
-        fprintf(stderr, "Error tearing down paging");
+    xenpaging_teardown(paging);
 
-    if ( rc == 0 )
-        rc = rc1;
-    return rc;
+    return rc ? 2 : 0;
 }
 
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdm-0004Az-3a; Mon, 30 Jan 2012 15:59:34 +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 1Rrtdl-00049b-3V
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327939166!5642163!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30345 invoked from network); 30 Jan 2012 15:59:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939165; l=2701;
	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=McytFW7fzLVhbakdNhLRTEqaCo4=;
	b=nsnx61io/Iz+bMvVfujrf8R42qVEJyiQxCQQMkTXmDXSIaodE3H9oWwBPvErcMP/8B+
	tMDTqKcIerbigbiUFcIrDblUEI5KDSnAjlcrp3oGzmvftvc7e+9bV7xWeLAI94LC7rcOu
	/MkUP/OBNHP7QXc8FaHV49/BLSwhiiGtcD4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo40) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L0476eo0UFClmQ
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:21 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5D41118634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b7906ad28153042726866cfbef40f8adf8dc1520
Message-Id: <b7906ad2815304272686.1327939169@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in
 policy_choose_victim
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327937798 -3600
# Node ID b7906ad28153042726866cfbef40f8adf8dc1520
# Parent  2e9a4bfaf79d64863f18a519c448afc54315aa1d
xenpaging: improve performance in policy_choose_victim

policy_choose_victim() is one of the bottlenecks in xenpaging. It is called
alot to find free bits in the fragmented bitmaps.

Reduce turnaround time by skipping longs with all bits set.
Adjust wrap detection in loop.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2e9a4bfaf79d -r b7906ad28153 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -80,33 +80,58 @@ int policy_init(struct xenpaging *paging
 unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
-    unsigned long wrap = current_gfn;
+    unsigned long i;
 
-    do
+    /* One iteration over all possible gfns */
+    for ( i = 0; i < max_pages; i++ )
     {
+        /* Try next gfn */
         current_gfn++;
+
+        /* Restart on wrap */
         if ( current_gfn >= max_pages )
             current_gfn = 0;
-        /* Could not nominate any gfn */
-        if ( wrap == current_gfn )
+
+        if ( (current_gfn & (BITS_PER_LONG - 1)) == 0 )
         {
-            paging->use_poll_timeout = 1;
-            /* Count wrap arounds */
-            unconsumed_cleared++;
-            /* Force retry every few seconds (depends on poll() timeout) */
-            if ( unconsumed_cleared > 123)
+            /* All gfns busy */
+            if ( ~bitmap[current_gfn >> ORDER_LONG] == 0 || ~unconsumed[current_gfn >> ORDER_LONG] == 0 )
             {
-                /* Force retry of unconsumed gfns */
-                bitmap_clear(unconsumed, max_pages);
-                unconsumed_cleared = 0;
-                DPRINTF("clearing unconsumed, wrap %lx", wrap);
-                /* One more round before returning ENOSPC */
+                current_gfn += BITS_PER_LONG;
+                i += BITS_PER_LONG;
                 continue;
             }
-            return INVALID_MFN;
         }
+
+        /* gfn busy */
+        if ( test_bit(current_gfn, bitmap) )
+            continue;
+
+        /* gfn already tested */
+        if ( test_bit(current_gfn, bitmap) )
+            continue;
+
+        /* gfn found */
+        break;
     }
-    while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
+
+    /* Could not nominate any gfn */
+    if ( i >= max_pages )
+    {
+        /* No more pages, wait in poll */
+        paging->use_poll_timeout = 1;
+        /* Count wrap arounds */
+        unconsumed_cleared++;
+        /* Force retry every few seconds (depends on poll() timeout) */
+        if ( unconsumed_cleared > 123)
+        {
+            /* Force retry of unconsumed gfns on next call */
+            bitmap_clear(unconsumed, max_pages);
+            unconsumed_cleared = 0;
+            DPRINTF("clearing unconsumed, current_gfn %lx", current_gfn);
+        }
+        return INVALID_MFN;
+    }
 
     set_bit(current_gfn, unconsumed);
     return current_gfn;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdm-0004Az-3a; Mon, 30 Jan 2012 15:59:34 +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 1Rrtdl-00049b-3V
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327939166!5642163!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30345 invoked from network); 30 Jan 2012 15:59:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-16.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939165; l=2701;
	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=McytFW7fzLVhbakdNhLRTEqaCo4=;
	b=nsnx61io/Iz+bMvVfujrf8R42qVEJyiQxCQQMkTXmDXSIaodE3H9oWwBPvErcMP/8B+
	tMDTqKcIerbigbiUFcIrDblUEI5KDSnAjlcrp3oGzmvftvc7e+9bV7xWeLAI94LC7rcOu
	/MkUP/OBNHP7QXc8FaHV49/BLSwhiiGtcD4=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo40) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id L0476eo0UFClmQ
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:21 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 5D41118634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: b7906ad28153042726866cfbef40f8adf8dc1520
Message-Id: <b7906ad2815304272686.1327939169@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:29 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 06 of 10] xenpaging: improve performance in
 policy_choose_victim
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327937798 -3600
# Node ID b7906ad28153042726866cfbef40f8adf8dc1520
# Parent  2e9a4bfaf79d64863f18a519c448afc54315aa1d
xenpaging: improve performance in policy_choose_victim

policy_choose_victim() is one of the bottlenecks in xenpaging. It is called
alot to find free bits in the fragmented bitmaps.

Reduce turnaround time by skipping longs with all bits set.
Adjust wrap detection in loop.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2e9a4bfaf79d -r b7906ad28153 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -80,33 +80,58 @@ int policy_init(struct xenpaging *paging
 unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
-    unsigned long wrap = current_gfn;
+    unsigned long i;
 
-    do
+    /* One iteration over all possible gfns */
+    for ( i = 0; i < max_pages; i++ )
     {
+        /* Try next gfn */
         current_gfn++;
+
+        /* Restart on wrap */
         if ( current_gfn >= max_pages )
             current_gfn = 0;
-        /* Could not nominate any gfn */
-        if ( wrap == current_gfn )
+
+        if ( (current_gfn & (BITS_PER_LONG - 1)) == 0 )
         {
-            paging->use_poll_timeout = 1;
-            /* Count wrap arounds */
-            unconsumed_cleared++;
-            /* Force retry every few seconds (depends on poll() timeout) */
-            if ( unconsumed_cleared > 123)
+            /* All gfns busy */
+            if ( ~bitmap[current_gfn >> ORDER_LONG] == 0 || ~unconsumed[current_gfn >> ORDER_LONG] == 0 )
             {
-                /* Force retry of unconsumed gfns */
-                bitmap_clear(unconsumed, max_pages);
-                unconsumed_cleared = 0;
-                DPRINTF("clearing unconsumed, wrap %lx", wrap);
-                /* One more round before returning ENOSPC */
+                current_gfn += BITS_PER_LONG;
+                i += BITS_PER_LONG;
                 continue;
             }
-            return INVALID_MFN;
         }
+
+        /* gfn busy */
+        if ( test_bit(current_gfn, bitmap) )
+            continue;
+
+        /* gfn already tested */
+        if ( test_bit(current_gfn, bitmap) )
+            continue;
+
+        /* gfn found */
+        break;
     }
-    while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
+
+    /* Could not nominate any gfn */
+    if ( i >= max_pages )
+    {
+        /* No more pages, wait in poll */
+        paging->use_poll_timeout = 1;
+        /* Count wrap arounds */
+        unconsumed_cleared++;
+        /* Force retry every few seconds (depends on poll() timeout) */
+        if ( unconsumed_cleared > 123)
+        {
+            /* Force retry of unconsumed gfns on next call */
+            bitmap_clear(unconsumed, max_pages);
+            unconsumed_cleared = 0;
+            DPRINTF("clearing unconsumed, current_gfn %lx", current_gfn);
+        }
+        return INVALID_MFN;
+    }
 
     set_bit(current_gfn, unconsumed);
     return current_gfn;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdl-0004AS-8F; Mon, 30 Jan 2012 15:59:33 +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 1Rrtdj-00049S-0z
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327939164!12969266!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17732 invoked from network); 30 Jan 2012 15:59:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 15:59:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939164; l=3325;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=wUG/hUgdbzJldELzPN+1mzW5W0g=;
	b=RXTKgX2TBZFG7qmtYWZza+r1XTkpZlwyLDr3EYGbX/uMOR5ATYPy0FUKlshHVlJETEX
	4DcCDSokjJj30gcxEZEi5WtR5DJ560SYIbnuHnLI9tWR9+TEegQFUipSVCuzEi3wHh8rP
	0JjWJqE6RWrQlgBShdZAgFVwlgpQCUvXRdA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (cohen mo40) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L0028eo0UF6pCJ
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:20 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B641518638
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 55b2e9676a5a871833e6c57ec3b424c70f15af2b
Message-Id: <55b2e9676a5a871833e6.1327939165@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:25 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 10] xenpaging: no poll timeout while
 page-out is in progress
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937792 -3600
# Node ID 55b2e9676a5a871833e6c57ec3b424c70f15af2b
# Parent  2d71d8bca0f15d353d28f5a42cc0c4e21002e8d5
xenpaging: no poll timeout while page-out is in progress

The main loop calls xenpaging_wait_for_event_or_timeout() unconditionally
before doing any work. This function calls poll() with a timeout of 100ms. As
a result the page-out process is very slow due to the delay in poll().

Call poll() without timeout so that it returns immediately until the page-out
is done. Page-out is done when either the policy finds no more pages to
nominate or when the requested number of pages is reached.

The condition is cleared when a watch event arrives, so that processing the
new target is not delayed once again by poll().

v2:
- no poll timeout also when large number of evicts is pending

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2d71d8bca0f1 -r 55b2e9676a5a tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -90,6 +90,7 @@ unsigned long policy_choose_victim(struc
         /* Could not nominate any gfn */
         if ( wrap == current_gfn )
         {
+            paging->use_poll_timeout = 1;
             /* Count wrap arounds */
             unconsumed_cleared++;
             /* Force retry every few seconds (depends on poll() timeout) */
diff -r 2d71d8bca0f1 -r 55b2e9676a5a tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -84,6 +84,7 @@ static int xenpaging_wait_for_event_or_t
     struct pollfd fd[2];
     int port;
     int rc;
+    int timeout;
 
     /* Wait for event channel and xenstore */
     fd[0].fd = xc_evtchn_fd(xce);
@@ -91,7 +92,9 @@ static int xenpaging_wait_for_event_or_t
     fd[1].fd = xs_fileno(paging->xs_handle);
     fd[1].events = POLLIN | POLLERR;
 
-    rc = poll(fd, 2, 100);
+    /* No timeout while page-out is still in progress */
+    timeout = paging->use_poll_timeout ? 100 : 0;
+    rc = poll(fd, 2, timeout);
     if ( rc < 0 )
     {
         if (errno == EINTR)
@@ -133,6 +136,8 @@ static int xenpaging_wait_for_event_or_t
                         if ( target_tot_pages < 0 || target_tot_pages > paging->max_pages )
                             target_tot_pages = paging->max_pages;
                         paging->target_tot_pages = target_tot_pages;
+                        /* Disable poll() delay while new target is not yet reached */
+                        paging->use_poll_timeout = 0;
                         DPRINTF("new target_tot_pages %d\n", target_tot_pages);
                     }
                     free(val);
@@ -970,7 +975,10 @@ int main(int argc, char *argv[])
             }
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
+            {
+                paging->use_poll_timeout = 0;
                 num = 42;
+            }
             evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
@@ -984,6 +992,11 @@ int main(int argc, char *argv[])
             }
             resume_pages(paging, num);
         }
+        /* Now target was reached, enable poll() timeout */
+        else
+        {
+            paging->use_poll_timeout = 1;
+        }
 
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
diff -r 2d71d8bca0f1 -r 55b2e9676a5a tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -55,6 +55,7 @@ struct xenpaging {
     int num_paged_out;
     int target_tot_pages;
     int policy_mru_size;
+    int use_poll_timeout;
     int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdl-0004AS-8F; Mon, 30 Jan 2012 15:59:33 +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 1Rrtdj-00049S-0z
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:31 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327939164!12969266!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17732 invoked from network); 30 Jan 2012 15:59:24 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-6.tower-182.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 15:59:24 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939164; l=3325;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=wUG/hUgdbzJldELzPN+1mzW5W0g=;
	b=RXTKgX2TBZFG7qmtYWZza+r1XTkpZlwyLDr3EYGbX/uMOR5ATYPy0FUKlshHVlJETEX
	4DcCDSokjJj30gcxEZEi5WtR5DJ560SYIbnuHnLI9tWR9+TEegQFUipSVCuzEi3wHh8rP
	0JjWJqE6RWrQlgBShdZAgFVwlgpQCUvXRdA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (cohen mo40) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id L0028eo0UF6pCJ
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:20 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id B641518638
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 55b2e9676a5a871833e6c57ec3b424c70f15af2b
Message-Id: <55b2e9676a5a871833e6.1327939165@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:25 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 02 of 10] xenpaging: no poll timeout while
 page-out is in progress
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937792 -3600
# Node ID 55b2e9676a5a871833e6c57ec3b424c70f15af2b
# Parent  2d71d8bca0f15d353d28f5a42cc0c4e21002e8d5
xenpaging: no poll timeout while page-out is in progress

The main loop calls xenpaging_wait_for_event_or_timeout() unconditionally
before doing any work. This function calls poll() with a timeout of 100ms. As
a result the page-out process is very slow due to the delay in poll().

Call poll() without timeout so that it returns immediately until the page-out
is done. Page-out is done when either the policy finds no more pages to
nominate or when the requested number of pages is reached.

The condition is cleared when a watch event arrives, so that processing the
new target is not delayed once again by poll().

v2:
- no poll timeout also when large number of evicts is pending

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 2d71d8bca0f1 -r 55b2e9676a5a tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -90,6 +90,7 @@ unsigned long policy_choose_victim(struc
         /* Could not nominate any gfn */
         if ( wrap == current_gfn )
         {
+            paging->use_poll_timeout = 1;
             /* Count wrap arounds */
             unconsumed_cleared++;
             /* Force retry every few seconds (depends on poll() timeout) */
diff -r 2d71d8bca0f1 -r 55b2e9676a5a tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -84,6 +84,7 @@ static int xenpaging_wait_for_event_or_t
     struct pollfd fd[2];
     int port;
     int rc;
+    int timeout;
 
     /* Wait for event channel and xenstore */
     fd[0].fd = xc_evtchn_fd(xce);
@@ -91,7 +92,9 @@ static int xenpaging_wait_for_event_or_t
     fd[1].fd = xs_fileno(paging->xs_handle);
     fd[1].events = POLLIN | POLLERR;
 
-    rc = poll(fd, 2, 100);
+    /* No timeout while page-out is still in progress */
+    timeout = paging->use_poll_timeout ? 100 : 0;
+    rc = poll(fd, 2, timeout);
     if ( rc < 0 )
     {
         if (errno == EINTR)
@@ -133,6 +136,8 @@ static int xenpaging_wait_for_event_or_t
                         if ( target_tot_pages < 0 || target_tot_pages > paging->max_pages )
                             target_tot_pages = paging->max_pages;
                         paging->target_tot_pages = target_tot_pages;
+                        /* Disable poll() delay while new target is not yet reached */
+                        paging->use_poll_timeout = 0;
                         DPRINTF("new target_tot_pages %d\n", target_tot_pages);
                     }
                     free(val);
@@ -970,7 +975,10 @@ int main(int argc, char *argv[])
             }
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
+            {
+                paging->use_poll_timeout = 0;
                 num = 42;
+            }
             evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
@@ -984,6 +992,11 @@ int main(int argc, char *argv[])
             }
             resume_pages(paging, num);
         }
+        /* Now target was reached, enable poll() timeout */
+        else
+        {
+            paging->use_poll_timeout = 1;
+        }
 
     }
     DPRINTF("xenpaging got signal %d\n", interrupted);
diff -r 2d71d8bca0f1 -r 55b2e9676a5a tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -55,6 +55,7 @@ struct xenpaging {
     int num_paged_out;
     int target_tot_pages;
     int policy_mru_size;
+    int use_poll_timeout;
     int debug;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdf-00049T-78; Mon, 30 Jan 2012 15:59:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rrtdc-00049N-SZ
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:25 +0000
Received: from [85.158.138.51:7984] by server-11.bemta-3.messagelabs.com id
	5B/8F-26051-B5EB62F4; Mon, 30 Jan 2012 15:59:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327939162!11288705!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10857 invoked from network); 30 Jan 2012 15:59:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 15:59:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939162; l=2726;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=cDFrOtcZJWONcTTrZKQ7COa7ZXQ=;
	b=GXwqVvRTCZVXL+Xlb438Ju/lBgdl0EZ6phll94QoZtGjRT8A/D8pXD64TfqKUFeBaqd
	eTFq3qxNDvFjSJ0YtaN0UjYNi2Gc20IJiGXENo58WBj9ZppfrU4p7t3K+edA9fJQRcl3C
	jhYA0QVJNrEEtUdFxlHLNTlyR9cg4ZLOL08=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (jimi mo35) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a01950o0UEtnJo
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:20 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 36ED81863B
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2e9a4bfaf79d64863f18a519c448afc54315aa1d
Message-Id: <2e9a4bfaf79d64863f18.1327939168@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 10] xenpaging: move nominate+evict into
	single function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937797 -3600
# Node ID 2e9a4bfaf79d64863f18a519c448afc54315aa1d
# Parent  e2092e841d281fcef8abb005cc41e23af09f1db3
xenpaging: move nominate+evict into single function

Move all code to evict a single gfn into one function. This simplifies
error handling in caller. The function returns -1 on fatal error, 0 on
success and 1 if the gfn cant be paged.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e2092e841d28 -r 2e9a4bfaf79d tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -571,6 +571,11 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
+/* Evict a given gfn
+ * Returns < 0 on fatal error
+ * Returns 0 on successful evict
+ * Returns > 0 if gfn can not be evicted
+ */
 static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
@@ -580,31 +585,51 @@ static int xenpaging_evict_page(struct x
 
     DECLARE_DOMCTL;
 
+    /* Nominate page */
+    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
+    if ( ret < 0 )
+    {
+        /* unpageable gfn is indicated by EBUSY */
+        if ( errno == EBUSY )
+            ret = 1;
+        else
+            PERROR("Error nominating page %lx", gfn);
+        goto out;
+    }
+
     /* Map page */
-    ret = -EFAULT;
     page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);
+        ret = -1;
         goto out;
     }
 
     /* Copy page */
     ret = write_page(fd, page, slot);
-    if ( ret != 0 )
+    if ( ret < 0 )
     {
         PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
+        ret = -1;
         goto out;
     }
 
+    /* Release page */
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
     ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
-    if ( ret != 0 )
+    if ( ret < 0 )
     {
-        PERROR("Error evicting page %lx", gfn);
+        /* A gfn in use is indicated by EBUSY */
+        if ( errno == EBUSY )
+        {
+                ret = 1;
+                DPRINTF("Nominated page %lx busy", gfn);
+        } else
+            PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
@@ -619,6 +644,8 @@ static int xenpaging_evict_page(struct x
     /* Record number of evicted pages */
     paging->num_paged_out++;
 
+    ret = 0;
+
  out:
     return ret;
 }
@@ -753,9 +780,10 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
-        if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, gfn, fd, slot);
+
+        ret = xenpaging_evict_page(paging, gfn, fd, slot);
+        if ( ret < 0 )
+            goto out;
     }
     while ( ret );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdf-00049T-78; Mon, 30 Jan 2012 15:59:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rrtdc-00049N-SZ
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:25 +0000
Received: from [85.158.138.51:7984] by server-11.bemta-3.messagelabs.com id
	5B/8F-26051-B5EB62F4; Mon, 30 Jan 2012 15:59:23 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-9.tower-174.messagelabs.com!1327939162!11288705!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10857 invoked from network); 30 Jan 2012 15:59:23 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-9.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 15:59:23 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939162; l=2726;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=cDFrOtcZJWONcTTrZKQ7COa7ZXQ=;
	b=GXwqVvRTCZVXL+Xlb438Ju/lBgdl0EZ6phll94QoZtGjRT8A/D8pXD64TfqKUFeBaqd
	eTFq3qxNDvFjSJ0YtaN0UjYNi2Gc20IJiGXENo58WBj9ZppfrU4p7t3K+edA9fJQRcl3C
	jhYA0QVJNrEEtUdFxlHLNTlyR9cg4ZLOL08=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (jimi mo35) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id a01950o0UEtnJo
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:20 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 36ED81863B
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2e9a4bfaf79d64863f18a519c448afc54315aa1d
Message-Id: <2e9a4bfaf79d64863f18.1327939168@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:28 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 05 of 10] xenpaging: move nominate+evict into
	single function
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937797 -3600
# Node ID 2e9a4bfaf79d64863f18a519c448afc54315aa1d
# Parent  e2092e841d281fcef8abb005cc41e23af09f1db3
xenpaging: move nominate+evict into single function

Move all code to evict a single gfn into one function. This simplifies
error handling in caller. The function returns -1 on fatal error, 0 on
success and 1 if the gfn cant be paged.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r e2092e841d28 -r 2e9a4bfaf79d tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -571,6 +571,11 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
+/* Evict a given gfn
+ * Returns < 0 on fatal error
+ * Returns 0 on successful evict
+ * Returns > 0 if gfn can not be evicted
+ */
 static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
@@ -580,31 +585,51 @@ static int xenpaging_evict_page(struct x
 
     DECLARE_DOMCTL;
 
+    /* Nominate page */
+    ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
+    if ( ret < 0 )
+    {
+        /* unpageable gfn is indicated by EBUSY */
+        if ( errno == EBUSY )
+            ret = 1;
+        else
+            PERROR("Error nominating page %lx", gfn);
+        goto out;
+    }
+
     /* Map page */
-    ret = -EFAULT;
     page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);
+        ret = -1;
         goto out;
     }
 
     /* Copy page */
     ret = write_page(fd, page, slot);
-    if ( ret != 0 )
+    if ( ret < 0 )
     {
         PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
+        ret = -1;
         goto out;
     }
 
+    /* Release page */
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
     ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
-    if ( ret != 0 )
+    if ( ret < 0 )
     {
-        PERROR("Error evicting page %lx", gfn);
+        /* A gfn in use is indicated by EBUSY */
+        if ( errno == EBUSY )
+        {
+                ret = 1;
+                DPRINTF("Nominated page %lx busy", gfn);
+        } else
+            PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
@@ -619,6 +644,8 @@ static int xenpaging_evict_page(struct x
     /* Record number of evicted pages */
     paging->num_paged_out++;
 
+    ret = 0;
+
  out:
     return ret;
 }
@@ -753,9 +780,10 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
-        if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, gfn, fd, slot);
+
+        ret = xenpaging_evict_page(paging, gfn, fd, slot);
+        if ( ret < 0 )
+            goto out;
     }
     while ( ret );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdm-0004BC-Gv; Mon, 30 Jan 2012 15:59:34 +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 1Rrtdk-00049h-Vq
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327939107!58989626!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7903 invoked from network); 30 Jan 2012 15:58:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 15:58:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939167; l=10635;
	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=DJ6D+A1Erkt2N1jPtw8wmedyod0=;
	b=dIibR+ivJ42GcwK4ika68y+avuaWJRWO6OCyjLCdtd4NJboC4uc1dApLLHf8jYH/P8q
	aOqeotbM5CAly1//fPGgC90cBtqDxlH2L2sy/VWBGrPh5nfHS44ocNcqEyBihqIg+yxj2
	RdibUpecmevoLdJFM+Lqn1DmHjV5rW0KoXU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (cohen mo30) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n00270o0UEo21a
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 92F0618637
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2d71d8bca0f15d353d28f5a42cc0c4e21002e8d5
Message-Id: <2d71d8bca0f15d353d28.1327939164@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 10] xenpaging: use flat index for pagefile
 and page-in requests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937786 -3600
# Node ID 2d71d8bca0f15d353d28f5a42cc0c4e21002e8d5
# Parent  39df93acd4089eaae138e1decf49aec39fb19417
xenpaging: use flat index for pagefile and page-in requests

This change is based on an idea by <hongkaixing@huawei.com> and
<bicky.shi@huawei.com>.

Scanning the victims[] array is time consuming with a large number of
target pages. Replace the loop to find the slot in the pagefile which
holds the requested gfn with an index.

Remove the victims array and replace it with a flat array. This array
holds the gfn for a given slot in the pagefile. Adjust all users of the
victims array.

Rename variable in main() from i to slot to clearify the meaning.

Update xenpaging_evict_page() to pass a pointer to xen_pfn_t to
xc_map_foreign_pages().

Update policy_choose_victim() to return either a gfn or INVALID_MFN.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 39df93acd408 -r 2d71d8bca0f1 tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -29,7 +29,7 @@
 
 
 int policy_init(struct xenpaging *paging);
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim);
+unsigned long policy_choose_victim(struct xenpaging *paging);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r 39df93acd408 -r 2d71d8bca0f1 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -77,7 +77,7 @@ int policy_init(struct xenpaging *paging
     return rc;
 }
 
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim)
+unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
@@ -102,16 +102,13 @@ int policy_choose_victim(struct xenpagin
                 /* One more round before returning ENOSPC */
                 continue;
             }
-            victim->gfn = INVALID_MFN;
-            return -ENOSPC;
+            return INVALID_MFN;
         }
     }
     while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
 
     set_bit(current_gfn, unconsumed);
-    victim->gfn = current_gfn;
-
-    return 0;
+    return current_gfn;
 }
 
 void policy_notify_paged_out(unsigned long gfn)
diff -r 39df93acd408 -r 2d71d8bca0f1 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -430,6 +430,12 @@ static struct xenpaging *xenpaging_init(
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
+    /* Allocate indicies for pagefile slots */
+    paging->slot_to_gfn = calloc(paging->max_pages, sizeof(*paging->slot_to_gfn));
+    paging->gfn_to_slot = calloc(paging->max_pages, sizeof(*paging->gfn_to_slot));
+    if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -468,6 +474,8 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->slot_to_gfn);
+        free(paging->gfn_to_slot);
         free(paging->bitmap);
         free(paging);
     }
@@ -561,31 +569,29 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
-    unsigned long gfn;
+    xen_pfn_t victim = gfn;
     int ret;
 
     DECLARE_DOMCTL;
 
     /* Map page */
-    gfn = victim->gfn;
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
-                                PROT_READ | PROT_WRITE, &gfn, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ | PROT_WRITE, &victim, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page %lx", victim->gfn);
+        PERROR("Error mapping page %lx", gfn);
         goto out;
     }
 
     /* Copy page */
-    ret = write_page(fd, page, i);
+    ret = write_page(fd, page, slot);
     if ( ret != 0 )
     {
-        PERROR("Error copying page %lx", victim->gfn);
+        PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
         goto out;
     }
@@ -593,17 +599,20 @@ static int xenpaging_evict_page(struct x
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
-                              victim->gfn);
+    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
     if ( ret != 0 )
     {
-        PERROR("Error evicting page %lx", victim->gfn);
+        PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
-    DPRINTF("evict_page > gfn %lx pageslot %d\n", victim->gfn, i);
+    DPRINTF("evict_page > gfn %lx pageslot %d\n", gfn, slot);
     /* Notify policy of page being paged out */
-    policy_notify_paged_out(victim->gfn);
+    policy_notify_paged_out(gfn);
+
+    /* Update index */
+    paging->slot_to_gfn[slot] = gfn;
+    paging->gfn_to_slot[gfn] = slot;
 
     /* Record number of evicted pages */
     paging->num_paged_out++;
@@ -710,19 +719,19 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
-static int evict_victim(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
+    unsigned long gfn;
     int j = 0;
     int ret;
 
     do
     {
-        ret = policy_choose_victim(paging, victim);
-        if ( ret != 0 )
+        gfn = policy_choose_victim(paging);
+        if ( gfn == INVALID_MFN )
         {
-            if ( ret != -ENOSPC )
-                ERROR("Error choosing victim");
+            ret = -ENOSPC;
             goto out;
         }
 
@@ -731,9 +740,9 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, victim->gfn);
+        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, victim, fd, i);
+            ret = xenpaging_evict_page(paging, gfn, fd, slot);
         else
         {
             if ( j++ % 1000 == 0 )
@@ -743,7 +752,7 @@ static int evict_victim(struct xenpaging
     }
     while ( ret );
 
-    if ( test_and_set_bit(victim->gfn, paging->bitmap) )
+    if ( test_and_set_bit(gfn, paging->bitmap) )
         ERROR("Page has been evicted before");
 
     ret = 0;
@@ -753,7 +762,7 @@ static int evict_victim(struct xenpaging
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(struct xenpaging *paging, int fd, struct victim *victims, int num_pages)
+static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -761,10 +770,10 @@ static int evict_pages(struct xenpaging 
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
-        if ( victims[slot].gfn != INVALID_MFN )
+        if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, &victims[slot], fd, slot);
+        rc = evict_victim(paging, fd, slot);
         if ( rc == -ENOSPC )
             break;
         if ( rc == -EINTR )
@@ -780,11 +789,10 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     struct xenpaging *paging;
-    struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int num, prev_num = 0;
-    int i;
+    int slot;
     int tot_pages;
     int rc = -1;
     int rc1;
@@ -813,15 +821,6 @@ int main(int argc, char *argv[])
         return 2;
     }
 
-    /* Allocate upper limit of pages to allow growing and shrinking */
-    victims = calloc(paging->max_pages, sizeof(struct victim));
-    if ( !victims )
-        goto out;
-
-    /* Mark all slots as unallocated */
-    for ( i = 0; i < paging->max_pages; i++ )
-        victims[i].gfn = INVALID_MFN;
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -853,32 +852,35 @@ int main(int argc, char *argv[])
         {
             get_request(&paging->mem_event, &req);
 
+            if ( req.gfn > paging->max_pages )
+            {
+                ERROR("Requested gfn %"PRIx64" higher than max_pages %lx\n", req.gfn, paging->max_pages);
+                goto out;
+            }
+
             /* Check if the page has already been paged in */
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->max_pages; i++ )
+                slot = paging->gfn_to_slot[req.gfn];
+
+                /* Sanity check */
+                if ( paging->slot_to_gfn[slot] != req.gfn )
                 {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->max_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
+                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.gfn, slot, paging->slot_to_gfn[slot]);
                     goto out;
                 }
-                
+
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
-                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, i);
+                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, slot);
                     /* Notify policy of page being dropped */
                     policy_notify_dropped(req.gfn);
                 }
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, i);
+                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
                     if ( rc != 0 )
                     {
                         PERROR("Error populating page %"PRIx64"", req.gfn);
@@ -899,7 +901,7 @@ int main(int argc, char *argv[])
                 }
 
                 /* Clear this pagefile slot */
-                victims[i].gfn = INVALID_MFN;
+                paging->slot_to_gfn[slot] = 0;
             }
             else
             {
@@ -969,7 +971,7 @@ int main(int argc, char *argv[])
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
                 num = 42;
-            evict_pages(paging, fd, victims, num);
+            evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -989,7 +991,6 @@ int main(int argc, char *argv[])
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 39df93acd408 -r 2d71d8bca0f1 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -46,6 +46,9 @@ struct xenpaging {
 
     unsigned long *bitmap;
 
+    unsigned long *slot_to_gfn;
+    int *gfn_to_slot;
+
     struct mem_event mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
@@ -56,13 +59,6 @@ struct xenpaging {
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 
-
-struct victim {
-    /* the gfn of the page to evict */
-    unsigned long gfn;
-};
-
-
 extern void create_page_in_thread(struct xenpaging *paging);
 extern void page_in_trigger(void);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdm-0004BC-Gv; Mon, 30 Jan 2012 15:59:34 +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 1Rrtdk-00049h-Vq
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327939107!58989626!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7903 invoked from network); 30 Jan 2012 15:58:27 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 15:58:27 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939167; l=10635;
	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=DJ6D+A1Erkt2N1jPtw8wmedyod0=;
	b=dIibR+ivJ42GcwK4ika68y+avuaWJRWO6OCyjLCdtd4NJboC4uc1dApLLHf8jYH/P8q
	aOqeotbM5CAly1//fPGgC90cBtqDxlH2L2sy/VWBGrPh5nfHS44ocNcqEyBihqIg+yxj2
	RdibUpecmevoLdJFM+Lqn1DmHjV5rW0KoXU=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (cohen mo30) (RZmta 27.6 DYNA|AUTH)
	with (DHE-RSA-AES256-SHA encrypted) ESMTPA id n00270o0UEo21a
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 92F0618637
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 2d71d8bca0f15d353d28f5a42cc0c4e21002e8d5
Message-Id: <2d71d8bca0f15d353d28.1327939164@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:24 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 01 of 10] xenpaging: use flat index for pagefile
 and page-in requests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937786 -3600
# Node ID 2d71d8bca0f15d353d28f5a42cc0c4e21002e8d5
# Parent  39df93acd4089eaae138e1decf49aec39fb19417
xenpaging: use flat index for pagefile and page-in requests

This change is based on an idea by <hongkaixing@huawei.com> and
<bicky.shi@huawei.com>.

Scanning the victims[] array is time consuming with a large number of
target pages. Replace the loop to find the slot in the pagefile which
holds the requested gfn with an index.

Remove the victims array and replace it with a flat array. This array
holds the gfn for a given slot in the pagefile. Adjust all users of the
victims array.

Rename variable in main() from i to slot to clearify the meaning.

Update xenpaging_evict_page() to pass a pointer to xen_pfn_t to
xc_map_foreign_pages().

Update policy_choose_victim() to return either a gfn or INVALID_MFN.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 39df93acd408 -r 2d71d8bca0f1 tools/xenpaging/policy.h
--- a/tools/xenpaging/policy.h
+++ b/tools/xenpaging/policy.h
@@ -29,7 +29,7 @@
 
 
 int policy_init(struct xenpaging *paging);
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim);
+unsigned long policy_choose_victim(struct xenpaging *paging);
 void policy_notify_paged_out(unsigned long gfn);
 void policy_notify_paged_in(unsigned long gfn);
 void policy_notify_paged_in_nomru(unsigned long gfn);
diff -r 39df93acd408 -r 2d71d8bca0f1 tools/xenpaging/policy_default.c
--- a/tools/xenpaging/policy_default.c
+++ b/tools/xenpaging/policy_default.c
@@ -77,7 +77,7 @@ int policy_init(struct xenpaging *paging
     return rc;
 }
 
-int policy_choose_victim(struct xenpaging *paging, struct victim *victim)
+unsigned long policy_choose_victim(struct xenpaging *paging)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long wrap = current_gfn;
@@ -102,16 +102,13 @@ int policy_choose_victim(struct xenpagin
                 /* One more round before returning ENOSPC */
                 continue;
             }
-            victim->gfn = INVALID_MFN;
-            return -ENOSPC;
+            return INVALID_MFN;
         }
     }
     while ( test_bit(current_gfn, bitmap) || test_bit(current_gfn, unconsumed) );
 
     set_bit(current_gfn, unconsumed);
-    victim->gfn = current_gfn;
-
-    return 0;
+    return current_gfn;
 }
 
 void policy_notify_paged_out(unsigned long gfn)
diff -r 39df93acd408 -r 2d71d8bca0f1 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -430,6 +430,12 @@ static struct xenpaging *xenpaging_init(
     }
     DPRINTF("max_pages = %d\n", paging->max_pages);
 
+    /* Allocate indicies for pagefile slots */
+    paging->slot_to_gfn = calloc(paging->max_pages, sizeof(*paging->slot_to_gfn));
+    paging->gfn_to_slot = calloc(paging->max_pages, sizeof(*paging->gfn_to_slot));
+    if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -468,6 +474,8 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->slot_to_gfn);
+        free(paging->gfn_to_slot);
         free(paging->bitmap);
         free(paging);
     }
@@ -561,31 +569,29 @@ static void put_response(struct mem_even
     RING_PUSH_RESPONSES(back_ring);
 }
 
-static int xenpaging_evict_page(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
-    unsigned long gfn;
+    xen_pfn_t victim = gfn;
     int ret;
 
     DECLARE_DOMCTL;
 
     /* Map page */
-    gfn = victim->gfn;
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id,
-                                PROT_READ | PROT_WRITE, &gfn, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ | PROT_WRITE, &victim, 1);
     if ( page == NULL )
     {
-        PERROR("Error mapping page %lx", victim->gfn);
+        PERROR("Error mapping page %lx", gfn);
         goto out;
     }
 
     /* Copy page */
-    ret = write_page(fd, page, i);
+    ret = write_page(fd, page, slot);
     if ( ret != 0 )
     {
-        PERROR("Error copying page %lx", victim->gfn);
+        PERROR("Error copying page %lx", gfn);
         munmap(page, PAGE_SIZE);
         goto out;
     }
@@ -593,17 +599,20 @@ static int xenpaging_evict_page(struct x
     munmap(page, PAGE_SIZE);
 
     /* Tell Xen to evict page */
-    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id,
-                              victim->gfn);
+    ret = xc_mem_paging_evict(xch, paging->mem_event.domain_id, gfn);
     if ( ret != 0 )
     {
-        PERROR("Error evicting page %lx", victim->gfn);
+        PERROR("Error evicting page %lx", gfn);
         goto out;
     }
 
-    DPRINTF("evict_page > gfn %lx pageslot %d\n", victim->gfn, i);
+    DPRINTF("evict_page > gfn %lx pageslot %d\n", gfn, slot);
     /* Notify policy of page being paged out */
-    policy_notify_paged_out(victim->gfn);
+    policy_notify_paged_out(gfn);
+
+    /* Update index */
+    paging->slot_to_gfn[slot] = gfn;
+    paging->gfn_to_slot[gfn] = slot;
 
     /* Record number of evicted pages */
     paging->num_paged_out++;
@@ -710,19 +719,19 @@ static void resume_pages(struct xenpagin
         page_in_trigger();
 }
 
-static int evict_victim(struct xenpaging *paging, struct victim *victim, int fd, int i)
+static int evict_victim(struct xenpaging *paging, int fd, int slot)
 {
     xc_interface *xch = paging->xc_handle;
+    unsigned long gfn;
     int j = 0;
     int ret;
 
     do
     {
-        ret = policy_choose_victim(paging, victim);
-        if ( ret != 0 )
+        gfn = policy_choose_victim(paging);
+        if ( gfn == INVALID_MFN )
         {
-            if ( ret != -ENOSPC )
-                ERROR("Error choosing victim");
+            ret = -ENOSPC;
             goto out;
         }
 
@@ -731,9 +740,9 @@ static int evict_victim(struct xenpaging
             ret = -EINTR;
             goto out;
         }
-        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, victim->gfn);
+        ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
-            ret = xenpaging_evict_page(paging, victim, fd, i);
+            ret = xenpaging_evict_page(paging, gfn, fd, slot);
         else
         {
             if ( j++ % 1000 == 0 )
@@ -743,7 +752,7 @@ static int evict_victim(struct xenpaging
     }
     while ( ret );
 
-    if ( test_and_set_bit(victim->gfn, paging->bitmap) )
+    if ( test_and_set_bit(gfn, paging->bitmap) )
         ERROR("Page has been evicted before");
 
     ret = 0;
@@ -753,7 +762,7 @@ static int evict_victim(struct xenpaging
 }
 
 /* Evict a batch of pages and write them to a free slot in the paging file */
-static int evict_pages(struct xenpaging *paging, int fd, struct victim *victims, int num_pages)
+static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -761,10 +770,10 @@ static int evict_pages(struct xenpaging 
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
-        if ( victims[slot].gfn != INVALID_MFN )
+        if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, &victims[slot], fd, slot);
+        rc = evict_victim(paging, fd, slot);
         if ( rc == -ENOSPC )
             break;
         if ( rc == -EINTR )
@@ -780,11 +789,10 @@ int main(int argc, char *argv[])
 {
     struct sigaction act;
     struct xenpaging *paging;
-    struct victim *victims;
     mem_event_request_t req;
     mem_event_response_t rsp;
     int num, prev_num = 0;
-    int i;
+    int slot;
     int tot_pages;
     int rc = -1;
     int rc1;
@@ -813,15 +821,6 @@ int main(int argc, char *argv[])
         return 2;
     }
 
-    /* Allocate upper limit of pages to allow growing and shrinking */
-    victims = calloc(paging->max_pages, sizeof(struct victim));
-    if ( !victims )
-        goto out;
-
-    /* Mark all slots as unallocated */
-    for ( i = 0; i < paging->max_pages; i++ )
-        victims[i].gfn = INVALID_MFN;
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -853,32 +852,35 @@ int main(int argc, char *argv[])
         {
             get_request(&paging->mem_event, &req);
 
+            if ( req.gfn > paging->max_pages )
+            {
+                ERROR("Requested gfn %"PRIx64" higher than max_pages %lx\n", req.gfn, paging->max_pages);
+                goto out;
+            }
+
             /* Check if the page has already been paged in */
             if ( test_and_clear_bit(req.gfn, paging->bitmap) )
             {
                 /* Find where in the paging file to read from */
-                for ( i = 0; i < paging->max_pages; i++ )
+                slot = paging->gfn_to_slot[req.gfn];
+
+                /* Sanity check */
+                if ( paging->slot_to_gfn[slot] != req.gfn )
                 {
-                    if ( victims[i].gfn == req.gfn )
-                        break;
-                }
-    
-                if ( i >= paging->max_pages )
-                {
-                    DPRINTF("Couldn't find page %"PRIx64"\n", req.gfn);
+                    ERROR("Expected gfn %"PRIx64" in slot %d, but found gfn %lx\n", req.gfn, slot, paging->slot_to_gfn[slot]);
                     goto out;
                 }
-                
+
                 if ( req.flags & MEM_EVENT_FLAG_DROP_PAGE )
                 {
-                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, i);
+                    DPRINTF("drop_page ^ gfn %"PRIx64" pageslot %d\n", req.gfn, slot);
                     /* Notify policy of page being dropped */
                     policy_notify_dropped(req.gfn);
                 }
                 else
                 {
                     /* Populate the page */
-                    rc = xenpaging_populate_page(paging, req.gfn, fd, i);
+                    rc = xenpaging_populate_page(paging, req.gfn, fd, slot);
                     if ( rc != 0 )
                     {
                         PERROR("Error populating page %"PRIx64"", req.gfn);
@@ -899,7 +901,7 @@ int main(int argc, char *argv[])
                 }
 
                 /* Clear this pagefile slot */
-                victims[i].gfn = INVALID_MFN;
+                paging->slot_to_gfn[slot] = 0;
             }
             else
             {
@@ -969,7 +971,7 @@ int main(int argc, char *argv[])
             /* Limit the number of evicts to be able to process page-in requests */
             if ( num > 42 )
                 num = 42;
-            evict_pages(paging, fd, victims, num);
+            evict_pages(paging, fd, num);
         }
         /* Resume some pages if target not reached */
         else if ( tot_pages < paging->target_tot_pages && paging->num_paged_out )
@@ -989,7 +991,6 @@ int main(int argc, char *argv[])
  out:
     close(fd);
     unlink_pagefile();
-    free(victims);
 
     /* Tear down domain paging */
     rc1 = xenpaging_teardown(paging);
diff -r 39df93acd408 -r 2d71d8bca0f1 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -46,6 +46,9 @@ struct xenpaging {
 
     unsigned long *bitmap;
 
+    unsigned long *slot_to_gfn;
+    int *gfn_to_slot;
+
     struct mem_event mem_event;
     /* number of pages for which data structures were allocated */
     int max_pages;
@@ -56,13 +59,6 @@ struct xenpaging {
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 
-
-struct victim {
-    /* the gfn of the page to evict */
-    unsigned long gfn;
-};
-
-
 extern void create_page_in_thread(struct xenpaging *paging);
 extern void page_in_trigger(void);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdl-0004Ao-Mh; Mon, 30 Jan 2012 15:59:33 +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 1Rrtdk-00049Y-Qu
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327939166!12581276!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31876 invoked from network); 30 Jan 2012 15:59:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939166; l=2390;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=nGAxVAHA1NkI88fi75nzwsMBjc4=;
	b=W58UyWldmEW+gQHAi39jaxplylzWGBxUJEyLIfDR0i5UrXrL7FekS1IvBV8sTeKruPS
	PHwsgYNC1KckFkZ/6uyn7OEyjhEf883hVjX5yyKC1bg4TgcJMW0ABMWJiAXDb9eCUjFbc
	0nfVXtFy5hpNfFhA4Zj1/qOWTkspoRvCFyc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo60) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x05379o0UFOTpR
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:22 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4F0D918639
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9cae410331c3d63bb82e781a5d5475e1135d4d32
Message-Id: <9cae410331c3d63bb82e.1327939173@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 10] xenpaging: implement stack of free
	slots in pagefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937804 -3600
# Node ID 9cae410331c3d63bb82e781a5d5475e1135d4d32
# Parent  3160254dd71365b9e21a47c7253776c9f95bb29c
xenpaging: implement stack of free slots in pagefile

Scanning the slot_to_gfn[] array for a free slot is expensive because
evict_pages() always needs to scan the whole array. Remember the last
slots freed during page-in requests and reuse them in evict_pages().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3160254dd713 -r 9cae410331c3 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -432,6 +432,11 @@ static struct xenpaging *xenpaging_init(
     if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
         goto err;
 
+    /* Allocate stack for known free slots in pagefile */
+    paging->free_slot_stack = calloc(paging->max_pages, sizeof(*paging->free_slot_stack));
+    if ( !paging->free_slot_stack )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -483,6 +488,7 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->free_slot_stack);
         free(paging->slot_to_gfn);
         free(paging->gfn_to_slot);
         free(paging->bitmap);
@@ -807,6 +813,20 @@ static int evict_pages(struct xenpaging 
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
 
+    /* Reuse known free slots */
+    while ( paging->stack_count > 0 && num < num_pages )
+    {
+        slot = paging->free_slot_stack[--paging->stack_count];
+        rc = evict_victim(paging, slot);
+        if ( rc )
+        {
+            num = rc < 0 ? -1 : num;
+            return num;
+        }
+        num++;
+    }
+
+    /* Scan all slots slots for remainders */
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
@@ -930,6 +950,9 @@ int main(int argc, char *argv[])
 
                 /* Clear this pagefile slot */
                 paging->slot_to_gfn[slot] = 0;
+
+                /* Record this free slot */
+                paging->free_slot_stack[paging->stack_count++] = slot;
             }
             else
             {
diff -r 3160254dd713 -r 9cae410331c3 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -60,6 +60,8 @@ struct xenpaging {
     int policy_mru_size;
     int use_poll_timeout;
     int debug;
+    int stack_count;
+    int *free_slot_stack;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdl-0004Ao-Mh; Mon, 30 Jan 2012 15:59:33 +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 1Rrtdk-00049Y-Qu
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:33 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-3.tower-216.messagelabs.com!1327939166!12581276!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31876 invoked from network); 30 Jan 2012 15:59:26 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.161)
	by server-3.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:26 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939166; l=2390;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=nGAxVAHA1NkI88fi75nzwsMBjc4=;
	b=W58UyWldmEW+gQHAi39jaxplylzWGBxUJEyLIfDR0i5UrXrL7FekS1IvBV8sTeKruPS
	PHwsgYNC1KckFkZ/6uyn7OEyjhEf883hVjX5yyKC1bg4TgcJMW0ABMWJiAXDb9eCUjFbc
	0nfVXtFy5hpNfFhA4Zj1/qOWTkspoRvCFyc=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo60) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id x05379o0UFOTpR
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:22 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 4F0D918639
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 9cae410331c3d63bb82e781a5d5475e1135d4d32
Message-Id: <9cae410331c3d63bb82e.1327939173@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:33 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 10 of 10] xenpaging: implement stack of free
	slots in pagefile
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937804 -3600
# Node ID 9cae410331c3d63bb82e781a5d5475e1135d4d32
# Parent  3160254dd71365b9e21a47c7253776c9f95bb29c
xenpaging: implement stack of free slots in pagefile

Scanning the slot_to_gfn[] array for a free slot is expensive because
evict_pages() always needs to scan the whole array. Remember the last
slots freed during page-in requests and reuse them in evict_pages().

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 3160254dd713 -r 9cae410331c3 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -432,6 +432,11 @@ static struct xenpaging *xenpaging_init(
     if ( !paging->slot_to_gfn || !paging->gfn_to_slot )
         goto err;
 
+    /* Allocate stack for known free slots in pagefile */
+    paging->free_slot_stack = calloc(paging->max_pages, sizeof(*paging->free_slot_stack));
+    if ( !paging->free_slot_stack )
+        goto err;
+
     /* Initialise policy */
     rc = policy_init(paging);
     if ( rc != 0 )
@@ -483,6 +488,7 @@ static struct xenpaging *xenpaging_init(
 
         free(dom_path);
         free(watch_target_tot_pages);
+        free(paging->free_slot_stack);
         free(paging->slot_to_gfn);
         free(paging->gfn_to_slot);
         free(paging->bitmap);
@@ -807,6 +813,20 @@ static int evict_pages(struct xenpaging 
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
 
+    /* Reuse known free slots */
+    while ( paging->stack_count > 0 && num < num_pages )
+    {
+        slot = paging->free_slot_stack[--paging->stack_count];
+        rc = evict_victim(paging, slot);
+        if ( rc )
+        {
+            num = rc < 0 ? -1 : num;
+            return num;
+        }
+        num++;
+    }
+
+    /* Scan all slots slots for remainders */
     for ( slot = 0; slot < paging->max_pages && num < num_pages; slot++ )
     {
         /* Slot is allocated */
@@ -930,6 +950,9 @@ int main(int argc, char *argv[])
 
                 /* Clear this pagefile slot */
                 paging->slot_to_gfn[slot] = 0;
+
+                /* Record this free slot */
+                paging->free_slot_stack[paging->stack_count++] = slot;
             }
             else
             {
diff -r 3160254dd713 -r 9cae410331c3 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -60,6 +60,8 @@ struct xenpaging {
     int policy_mru_size;
     int use_poll_timeout;
     int debug;
+    int stack_count;
+    int *free_slot_stack;
     unsigned long pagein_queue[XENPAGING_PAGEIN_QUEUE_SIZE];
 };
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 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 1Rrtdv-0004Fp-I2; Mon, 30 Jan 2012 15:59:43 +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 1Rrtdu-0004CW-AR
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327939146!57718947!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9883 invoked from network); 30 Jan 2012 15:59:07 -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; 30 Jan 2012 15:59:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939175; l=2256;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=b3MAq8MVLXg9DpCL0KWvCb2H+vQ=;
	b=FpQ/O/4xRKVB4z/u/RT0w4E6WyNjvxs4JaJOlnqI/fMytUrrqFX8EOKe5JKw6hnsCoN
	vHzKl0WZFlH3/S5ruxjgfBY6XYpNVTtieol6hMAxIIDczUEu+5CO0qWYjcp2BZg69Btug
	AyBJhkLqzVhF4IDrZvqFH3qhSNS5n8GJ3uo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (fruni mo17) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w03801o0UEuDPQ
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:21 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2AA8118638
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3160254dd71365b9e21a47c7253776c9f95bb29c
Message-Id: <3160254dd71365b9e21a.1327939172@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 10] xenpaging: move page_buffer into
	struct xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327937803 -3600
# Node ID 3160254dd71365b9e21a47c7253776c9f95bb29c
# Parent  4c494f4b99f4da449fe72cd6ba6398e666231d9b
xenpaging: move page_buffer into struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4c494f4b99f4 -r 3160254dd713 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -44,7 +44,6 @@ static char *dom_path;
 static char watch_token[16];
 static char *filename;
 static int interrupted;
-static void *paging_buffer = NULL;
 
 static void unlink_pagefile(void)
 {
@@ -441,8 +440,8 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    paging_buffer = init_page();
-    if ( !paging_buffer )
+    paging->paging_buffer = init_page();
+    if ( !paging->paging_buffer )
     {
         PERROR("Creating page aligned load buffer");
         goto err;
@@ -465,6 +464,11 @@ static struct xenpaging *xenpaging_init(
             xs_close(paging->xs_handle);
         if ( xch )
             xc_interface_close(xch);
+        if ( paging->paging_buffer )
+        {
+            munlock(paging->paging_buffer, PAGE_SIZE);
+            free(paging->paging_buffer);
+        }
         if ( paging->mem_event.shared_page )
         {
             munlock(paging->mem_event.shared_page, PAGE_SIZE);
@@ -687,7 +691,7 @@ static int xenpaging_populate_page(struc
     DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
-    ret = read_page(paging->fd, paging_buffer, i);
+    ret = read_page(paging->fd, paging->paging_buffer, i);
     if ( ret != 0 )
     {
         PERROR("Error reading page");
@@ -697,8 +701,7 @@ static int xenpaging_populate_page(struc
     do
     {
         /* Tell Xen to allocate a page for the domain */
-        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
-                                    paging_buffer);
+        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn, paging->paging_buffer);
         if ( ret < 0 )
         {
             if ( errno == ENOMEM )
diff -r 4c494f4b99f4 -r 3160254dd713 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -49,6 +49,8 @@ struct xenpaging {
     unsigned long *slot_to_gfn;
     int *gfn_to_slot;
 
+    void *paging_buffer;
+
     struct mem_event mem_event;
     int fd;
     /* number of pages for which data structures were allocated */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 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 1Rrtdv-0004Fp-I2; Mon, 30 Jan 2012 15:59:43 +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 1Rrtdu-0004CW-AR
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-27.messagelabs.com!1327939146!57718947!1
X-Originating-IP: [81.169.146.161]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MSA9PiAyNDIzOTQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9883 invoked from network); 30 Jan 2012 15:59:07 -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; 30 Jan 2012 15:59:07 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939175; l=2256;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=b3MAq8MVLXg9DpCL0KWvCb2H+vQ=;
	b=FpQ/O/4xRKVB4z/u/RT0w4E6WyNjvxs4JaJOlnqI/fMytUrrqFX8EOKe5JKw6hnsCoN
	vHzKl0WZFlH3/S5ruxjgfBY6XYpNVTtieol6hMAxIIDczUEu+5CO0qWYjcp2BZg69Btug
	AyBJhkLqzVhF4IDrZvqFH3qhSNS5n8GJ3uo=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (fruni mo17) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w03801o0UEuDPQ
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:21 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 2AA8118638
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 3160254dd71365b9e21a47c7253776c9f95bb29c
Message-Id: <3160254dd71365b9e21a.1327939172@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:32 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 09 of 10] xenpaging: move page_buffer into
	struct xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327937803 -3600
# Node ID 3160254dd71365b9e21a47c7253776c9f95bb29c
# Parent  4c494f4b99f4da449fe72cd6ba6398e666231d9b
xenpaging: move page_buffer into struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 4c494f4b99f4 -r 3160254dd713 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -44,7 +44,6 @@ static char *dom_path;
 static char watch_token[16];
 static char *filename;
 static int interrupted;
-static void *paging_buffer = NULL;
 
 static void unlink_pagefile(void)
 {
@@ -441,8 +440,8 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
-    paging_buffer = init_page();
-    if ( !paging_buffer )
+    paging->paging_buffer = init_page();
+    if ( !paging->paging_buffer )
     {
         PERROR("Creating page aligned load buffer");
         goto err;
@@ -465,6 +464,11 @@ static struct xenpaging *xenpaging_init(
             xs_close(paging->xs_handle);
         if ( xch )
             xc_interface_close(xch);
+        if ( paging->paging_buffer )
+        {
+            munlock(paging->paging_buffer, PAGE_SIZE);
+            free(paging->paging_buffer);
+        }
         if ( paging->mem_event.shared_page )
         {
             munlock(paging->mem_event.shared_page, PAGE_SIZE);
@@ -687,7 +691,7 @@ static int xenpaging_populate_page(struc
     DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
-    ret = read_page(paging->fd, paging_buffer, i);
+    ret = read_page(paging->fd, paging->paging_buffer, i);
     if ( ret != 0 )
     {
         PERROR("Error reading page");
@@ -697,8 +701,7 @@ static int xenpaging_populate_page(struc
     do
     {
         /* Tell Xen to allocate a page for the domain */
-        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn,
-                                    paging_buffer);
+        ret = xc_mem_paging_load(xch, paging->mem_event.domain_id, gfn, paging->paging_buffer);
         if ( ret < 0 )
         {
             if ( errno == ENOMEM )
diff -r 4c494f4b99f4 -r 3160254dd713 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -49,6 +49,8 @@ struct xenpaging {
     unsigned long *slot_to_gfn;
     int *gfn_to_slot;
 
+    void *paging_buffer;
+
     struct mem_event mem_event;
     int fd;
     /* number of pages for which data structures were allocated */

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 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 1Rrtdv-0004FX-4t; Mon, 30 Jan 2012 15:59:43 +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 1Rrtdt-0004C5-MT
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327939174!12430203!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31722 invoked from network); 30 Jan 2012 15:59:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939174; l=2867;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=JhiLspCbNtSs2MO0yy0GZKnKojs=;
	b=aXvn17Rt3+7P/IsOq0n9e7NaQkm+aolFrMCQYkifi5ryPWs0auuQtd+m4Jum86g8Qi4
	jffhFojJyni194tIqjVtbFaJNLzRToFyfaNH18cFfqnMuCp406EczuLw46aUic1lWTK+y
	aZ76nB+PVqctDzIRx4whdLG6WwSImh3PccA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo35) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a04441o0UEotbU
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:20 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0FBF91863A
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e2092e841d281fcef8abb005cc41e23af09f1db3
Message-Id: <e2092e841d281fcef8ab.1327939167@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:27 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 10] xenpaging: reduce number of qemu cache
	flushes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937795 -3600
# Node ID e2092e841d281fcef8abb005cc41e23af09f1db3
# Parent  dcf9cca8e1d5121782ea96dc183f52ff0cee2251
xenpaging: reduce number of qemu cache flushes

Currently the command to flush the qemu cache is called alot if there
are no more pages to evict. This causes churn in the logfiles, and qemu
can not release more pages anyway since the last command.

Fix this by remembering the current number of paged-out gfns, if this
number did not change since the last flush command then sending another
new flush command will not free any more gfns.

Remove return code from xenpaging_mem_paging_flush_ioemu_cache() since
errors do not matter, and will be handled elsewhere. Also failure to
send the flush command is not fatal.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r dcf9cca8e1d5 -r e2092e841d28 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -61,18 +61,15 @@ static void close_handler(int sig)
     unlink_pagefile();
 }
 
-static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
+static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 {
     struct xs_handle *xsh = paging->xs_handle;
     domid_t domain_id = paging->mem_event.domain_id;
     char path[80];
-    bool rc;
 
     sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
 
-    rc = xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
-
-    return rc == true ? 0 : -1;
+    xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
 }
 
 static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
@@ -728,7 +725,7 @@ static int evict_victim(struct xenpaging
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long gfn;
-    int j = 0;
+    static int num_paged_out;
     int ret;
 
     do
@@ -736,6 +733,17 @@ static int evict_victim(struct xenpaging
         gfn = policy_choose_victim(paging);
         if ( gfn == INVALID_MFN )
         {
+            /* If the number did not change after last flush command then
+             * the command did not reach qemu yet, or qemu still processes
+             * the command, or qemu has nothing to release.
+             * Right now there is no need to issue the command again.
+             */
+            if ( num_paged_out != paging->num_paged_out )
+            {
+                DPRINTF("Flushing qemu cache\n");
+                xenpaging_mem_paging_flush_ioemu_cache(paging);
+                num_paged_out = paging->num_paged_out;
+            }
             ret = -ENOSPC;
             goto out;
         }
@@ -748,12 +756,6 @@ static int evict_victim(struct xenpaging
         ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
             ret = xenpaging_evict_page(paging, gfn, fd, slot);
-        else
-        {
-            if ( j++ % 1000 == 0 )
-                if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
-                    PERROR("Error flushing ioemu cache");
-        }
     }
     while ( ret );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 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 1Rrtdv-0004FX-4t; Mon, 30 Jan 2012 15:59:43 +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 1Rrtdt-0004C5-MT
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327939174!12430203!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31722 invoked from network); 30 Jan 2012 15:59:35 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:35 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939174; l=2867;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=JhiLspCbNtSs2MO0yy0GZKnKojs=;
	b=aXvn17Rt3+7P/IsOq0n9e7NaQkm+aolFrMCQYkifi5ryPWs0auuQtd+m4Jum86g8Qi4
	jffhFojJyni194tIqjVtbFaJNLzRToFyfaNH18cFfqnMuCp406EczuLw46aUic1lWTK+y
	aZ76nB+PVqctDzIRx4whdLG6WwSImh3PccA=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo35) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id a04441o0UEotbU
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:20 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 0FBF91863A
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:25 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: e2092e841d281fcef8abb005cc41e23af09f1db3
Message-Id: <e2092e841d281fcef8ab.1327939167@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:27 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 04 of 10] xenpaging: reduce number of qemu cache
	flushes
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-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 1327937795 -3600
# Node ID e2092e841d281fcef8abb005cc41e23af09f1db3
# Parent  dcf9cca8e1d5121782ea96dc183f52ff0cee2251
xenpaging: reduce number of qemu cache flushes

Currently the command to flush the qemu cache is called alot if there
are no more pages to evict. This causes churn in the logfiles, and qemu
can not release more pages anyway since the last command.

Fix this by remembering the current number of paged-out gfns, if this
number did not change since the last flush command then sending another
new flush command will not free any more gfns.

Remove return code from xenpaging_mem_paging_flush_ioemu_cache() since
errors do not matter, and will be handled elsewhere. Also failure to
send the flush command is not fatal.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r dcf9cca8e1d5 -r e2092e841d28 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -61,18 +61,15 @@ static void close_handler(int sig)
     unlink_pagefile();
 }
 
-static int xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
+static void xenpaging_mem_paging_flush_ioemu_cache(struct xenpaging *paging)
 {
     struct xs_handle *xsh = paging->xs_handle;
     domid_t domain_id = paging->mem_event.domain_id;
     char path[80];
-    bool rc;
 
     sprintf(path, "/local/domain/0/device-model/%u/command", domain_id);
 
-    rc = xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
-
-    return rc == true ? 0 : -1;
+    xs_write(xsh, XBT_NULL, path, "flush-cache", strlen("flush-cache")); 
 }
 
 static int xenpaging_wait_for_event_or_timeout(struct xenpaging *paging)
@@ -728,7 +725,7 @@ static int evict_victim(struct xenpaging
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long gfn;
-    int j = 0;
+    static int num_paged_out;
     int ret;
 
     do
@@ -736,6 +733,17 @@ static int evict_victim(struct xenpaging
         gfn = policy_choose_victim(paging);
         if ( gfn == INVALID_MFN )
         {
+            /* If the number did not change after last flush command then
+             * the command did not reach qemu yet, or qemu still processes
+             * the command, or qemu has nothing to release.
+             * Right now there is no need to issue the command again.
+             */
+            if ( num_paged_out != paging->num_paged_out )
+            {
+                DPRINTF("Flushing qemu cache\n");
+                xenpaging_mem_paging_flush_ioemu_cache(paging);
+                num_paged_out = paging->num_paged_out;
+            }
             ret = -ENOSPC;
             goto out;
         }
@@ -748,12 +756,6 @@ static int evict_victim(struct xenpaging
         ret = xc_mem_paging_nominate(xch, paging->mem_event.domain_id, gfn);
         if ( ret == 0 )
             ret = xenpaging_evict_page(paging, gfn, fd, slot);
-        else
-        {
-            if ( j++ % 1000 == 0 )
-                if ( xenpaging_mem_paging_flush_ioemu_cache(paging) )
-                    PERROR("Error flushing ioemu cache");
-        }
     }
     while ( ret );
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrtdw-0004Gq-Ml; Mon, 30 Jan 2012 15:59:44 +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 1Rrtdv-0004D2-GW
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327939177!12430208!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31881 invoked from network); 30 Jan 2012 15:59:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939176; l=854;
	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=0KH3w/RtFhUnKOwaX7fzjy18hzQ=;
	b=Crcm9WFY2Fl/dMhvLRW5CAoMO2a+glX8gI9WOd5T3Thk/vSvDTXYJ9nZ+mh1w5zDyrg
	dHhSp5RI6/lHTgXNTsgD7C2tcyhlM8Nm3BdUqO8sMxPzZgZGmIkkV9OGTUqcgIlhnFao+
	zTIwvfK3TT3jNHIMD01B6BIQtzTEYWtkHE8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (klopstock mo48) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R015dco0UFeq00
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:20 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DDBCB18639
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dcf9cca8e1d5121782ea96dc183f52ff0cee2251
Message-Id: <dcf9cca8e1d5121782ea.1327939166@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 10] xenpaging: mmap guest pages read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327937794 -3600
# Node ID dcf9cca8e1d5121782ea96dc183f52ff0cee2251
# Parent  55b2e9676a5a871833e6c57ec3b424c70f15af2b
xenpaging: mmap guest pages read-only

xenpaging does not write to the gfn, so map the gfn to page-out in
read-only mode.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 55b2e9676a5a -r dcf9cca8e1d5 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -585,7 +585,7 @@ static int xenpaging_evict_page(struct x
 
     /* Map page */
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ | PROT_WRITE, &victim, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrtdw-0004Gq-Ml; Mon, 30 Jan 2012 15:59:44 +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 1Rrtdv-0004D2-GW
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:43 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327939177!12430208!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31881 invoked from network); 30 Jan 2012 15:59:37 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-13.tower-182.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:37 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939176; l=854;
	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=0KH3w/RtFhUnKOwaX7fzjy18hzQ=;
	b=Crcm9WFY2Fl/dMhvLRW5CAoMO2a+glX8gI9WOd5T3Thk/vSvDTXYJ9nZ+mh1w5zDyrg
	dHhSp5RI6/lHTgXNTsgD7C2tcyhlM8Nm3BdUqO8sMxPzZgZGmIkkV9OGTUqcgIlhnFao+
	zTIwvfK3TT3jNHIMD01B6BIQtzTEYWtkHE8=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (klopstock mo48) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id R015dco0UFeq00
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:20 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id DDBCB18639
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:24 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: dcf9cca8e1d5121782ea96dc183f52ff0cee2251
Message-Id: <dcf9cca8e1d5121782ea.1327939166@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:26 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 03 of 10] xenpaging: mmap guest pages read-only
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327937794 -3600
# Node ID dcf9cca8e1d5121782ea96dc183f52ff0cee2251
# Parent  55b2e9676a5a871833e6c57ec3b424c70f15af2b
xenpaging: mmap guest pages read-only

xenpaging does not write to the gfn, so map the gfn to page-out in
read-only mode.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 55b2e9676a5a -r dcf9cca8e1d5 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -585,7 +585,7 @@ static int xenpaging_evict_page(struct x
 
     /* Map page */
     ret = -EFAULT;
-    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ | PROT_WRITE, &victim, 1);
+    page = xc_map_foreign_pages(xch, paging->mem_event.domain_id, PROT_READ, &victim, 1);
     if ( page == NULL )
     {
         PERROR("Error mapping page %lx", gfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrtdv-0004GA-UA; Mon, 30 Jan 2012 15:59:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rrtdu-0004Eh-5H
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:42 +0000
Received: from [85.158.138.51:42989] by server-11.bemta-3.messagelabs.com id
	76/30-26051-D6EB62F4; Mon, 30 Jan 2012 15:59:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327939179!7055905!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5366 invoked from network); 30 Jan 2012 15:59:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939179; l=4898;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=lYdUz+3JQvKX4Dm+EALMhx3SFXQ=;
	b=ErMnPhqS4aVr9f8HUkwZ1zi5aSSBt/4kczFy8Ill2w7v2jAOflPdfk2ndF3DBS9Sd4X
	oFFuuvXM5Dc0PQCu4+583ccHk4x7TE7irFKghqYPrTJnkDUFjzURrISkV98zjcs1bywM/
	DKgkDFfnq1bcPOcqbZkzMPlW64j5VIXl06g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo32) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V042a8o0UFfgxM
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:21 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 00D2218637
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 4c494f4b99f4da449fe72cd6ba6398e666231d9b
Message-Id: <4c494f4b99f4da449fe7.1327939171@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 10] xenpaging: move pagefile
 filedescriptor into struct xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327937802 -3600
# Node ID 4c494f4b99f4da449fe72cd6ba6398e666231d9b
# Parent  649791966e1a8fb5e363d8745250bcd120871800
xenpaging: move pagefile filedescriptor into struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 649791966e1a -r 4c494f4b99f4 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -448,6 +448,14 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
+    /* Open file */
+    paging->fd = open(filename, O_CREAT | O_TRUNC | O_RDWR, S_IRUSR | S_IWUSR);
+    if ( paging->fd < 0 )
+    {
+        PERROR("failed to open file");
+        goto err;
+    }
+
     return paging;
 
  err:
@@ -562,7 +570,7 @@ static void put_response(struct mem_even
  * Returns 0 on successful evict
  * Returns > 0 if gfn can not be evicted
  */
-static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
@@ -593,7 +601,7 @@ static int xenpaging_evict_page(struct x
     }
 
     /* Copy page */
-    ret = write_page(fd, page, slot);
+    ret = write_page(paging->fd, page, slot);
     if ( ret < 0 )
     {
         PERROR("Error copying page %lx", gfn);
@@ -670,7 +678,7 @@ static int xenpaging_resume_page(struct 
     return ret;
 }
 
-static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int fd, int i)
+static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int i)
 {
     xc_interface *xch = paging->xc_handle;
     int ret;
@@ -679,7 +687,7 @@ static int xenpaging_populate_page(struc
     DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
-    ret = read_page(fd, paging_buffer, i);
+    ret = read_page(paging->fd, paging_buffer, i);
     if ( ret != 0 )
     {
         PERROR("Error reading page");
@@ -738,7 +746,7 @@ static void resume_pages(struct xenpagin
  * Returns 0 on successful evict
  * Returns > 0 if no gfn can be evicted
  */
-static int evict_victim(struct xenpaging *paging, int fd, int slot)
+static int evict_victim(struct xenpaging *paging, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long gfn;
@@ -771,7 +779,7 @@ static int evict_victim(struct xenpaging
             goto out;
         }
 
-        ret = xenpaging_evict_page(paging, gfn, fd, slot);
+        ret = xenpaging_evict_page(paging, gfn, slot);
         if ( ret < 0 )
             goto out;
     }
@@ -791,7 +799,7 @@ static int evict_victim(struct xenpaging
  * Returns 0 if no gfn can be evicted
  * Returns > 0 on successful evict
  */
-static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
+static int evict_pages(struct xenpaging *paging, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -802,7 +810,7 @@ static int evict_pages(struct xenpaging 
         if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, fd, slot);
+        rc = evict_victim(paging, slot);
         if ( rc )
         {
             num = rc < 0 ? -1 : num;
@@ -826,10 +834,6 @@ int main(int argc, char *argv[])
     int rc;
     xc_interface *xch;
 
-    int open_flags = O_CREAT | O_TRUNC | O_RDWR;
-    mode_t open_mode = S_IRUSR | S_IWUSR;
-    int fd;
-
     /* Initialise domain paging */
     paging = xenpaging_init(argc, argv);
     if ( paging == NULL )
@@ -841,14 +845,6 @@ int main(int argc, char *argv[])
 
     DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->mem_event.domain_id, filename);
 
-    /* Open file */
-    fd = open(filename, open_flags, open_mode);
-    if ( fd < 0 )
-    {
-        perror("failed to open file");
-        return 2;
-    }
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -911,7 +907,7 @@ int main(int argc, char *argv[])
                 else
                 {
                     /* Populate the page */
-                    if ( xenpaging_populate_page(paging, req.gfn, fd, slot) < 0 )
+                    if ( xenpaging_populate_page(paging, req.gfn, slot) < 0 )
                     {
                         ERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
@@ -1005,7 +1001,7 @@ int main(int argc, char *argv[])
                 paging->use_poll_timeout = 0;
                 num = 42;
             }
-            if ( evict_pages(paging, fd, num) < 0 )
+            if ( evict_pages(paging, num) < 0 )
                 goto out;
         }
         /* Resume some pages if target not reached */
@@ -1033,7 +1029,7 @@ int main(int argc, char *argv[])
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
  out:
-    close(fd);
+    close(paging->fd);
     unlink_pagefile();
 
     /* Tear down domain paging */
diff -r 649791966e1a -r 4c494f4b99f4 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -50,6 +50,7 @@ struct xenpaging {
     int *gfn_to_slot;
 
     struct mem_event mem_event;
+    int fd;
     /* number of pages for which data structures were allocated */
     int max_pages;
     int num_paged_out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15:59:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrtdv-0004GA-UA; Mon, 30 Jan 2012 15:59:43 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <olaf@aepfle.de>) id 1Rrtdu-0004Eh-5H
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:42 +0000
Received: from [85.158.138.51:42989] by server-11.bemta-3.messagelabs.com id
	76/30-26051-D6EB62F4; Mon, 30 Jan 2012 15:59:41 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-174.messagelabs.com!1327939179!7055905!1
X-Originating-IP: [81.169.146.160]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MCA9PiAyNDQyNTI=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5366 invoked from network); 30 Jan 2012 15:59:40 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.160)
	by server-7.tower-174.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:40 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939179; l=4898;
	s=domk; d=aepfle.de;
	h=To:From:Date:References:In-Reply-To:Subject:
	Content-Transfer-Encoding:MIME-Version:Content-Type:X-RZG-CLASS-ID:
	X-RZG-AUTH; bh=lYdUz+3JQvKX4Dm+EALMhx3SFXQ=;
	b=ErMnPhqS4aVr9f8HUkwZ1zi5aSSBt/4kczFy8Ill2w7v2jAOflPdfk2ndF3DBS9Sd4X
	oFFuuvXM5Dc0PQCu4+583ccHk4x7TE7irFKghqYPrTJnkDUFjzURrISkV98zjcs1bywM/
	DKgkDFfnq1bcPOcqbZkzMPlW64j5VIXl06g=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by post.strato.de (mrclete mo32) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id V042a8o0UFfgxM
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:21 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 00D2218637
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:26 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 4c494f4b99f4da449fe72cd6ba6398e666231d9b
Message-Id: <4c494f4b99f4da449fe7.1327939171@probook.site>
In-Reply-To: <patchbomb.1327939163@probook.site>
References: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:31 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 08 of 10] xenpaging: move pagefile
 filedescriptor into struct xenpaging
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Olaf Hering <olaf@aepfle.de>
# Date 1327937802 -3600
# Node ID 4c494f4b99f4da449fe72cd6ba6398e666231d9b
# Parent  649791966e1a8fb5e363d8745250bcd120871800
xenpaging: move pagefile filedescriptor into struct xenpaging

Signed-off-by: Olaf Hering <olaf@aepfle.de>

diff -r 649791966e1a -r 4c494f4b99f4 tools/xenpaging/xenpaging.c
--- a/tools/xenpaging/xenpaging.c
+++ b/tools/xenpaging/xenpaging.c
@@ -448,6 +448,14 @@ static struct xenpaging *xenpaging_init(
         goto err;
     }
 
+    /* Open file */
+    paging->fd = open(filename, O_CREAT | O_TRUNC | O_RDWR, S_IRUSR | S_IWUSR);
+    if ( paging->fd < 0 )
+    {
+        PERROR("failed to open file");
+        goto err;
+    }
+
     return paging;
 
  err:
@@ -562,7 +570,7 @@ static void put_response(struct mem_even
  * Returns 0 on successful evict
  * Returns > 0 if gfn can not be evicted
  */
-static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int fd, int slot)
+static int xenpaging_evict_page(struct xenpaging *paging, unsigned long gfn, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     void *page;
@@ -593,7 +601,7 @@ static int xenpaging_evict_page(struct x
     }
 
     /* Copy page */
-    ret = write_page(fd, page, slot);
+    ret = write_page(paging->fd, page, slot);
     if ( ret < 0 )
     {
         PERROR("Error copying page %lx", gfn);
@@ -670,7 +678,7 @@ static int xenpaging_resume_page(struct 
     return ret;
 }
 
-static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int fd, int i)
+static int xenpaging_populate_page(struct xenpaging *paging, unsigned long gfn, int i)
 {
     xc_interface *xch = paging->xc_handle;
     int ret;
@@ -679,7 +687,7 @@ static int xenpaging_populate_page(struc
     DPRINTF("populate_page < gfn %lx pageslot %d\n", gfn, i);
 
     /* Read page */
-    ret = read_page(fd, paging_buffer, i);
+    ret = read_page(paging->fd, paging_buffer, i);
     if ( ret != 0 )
     {
         PERROR("Error reading page");
@@ -738,7 +746,7 @@ static void resume_pages(struct xenpagin
  * Returns 0 on successful evict
  * Returns > 0 if no gfn can be evicted
  */
-static int evict_victim(struct xenpaging *paging, int fd, int slot)
+static int evict_victim(struct xenpaging *paging, int slot)
 {
     xc_interface *xch = paging->xc_handle;
     unsigned long gfn;
@@ -771,7 +779,7 @@ static int evict_victim(struct xenpaging
             goto out;
         }
 
-        ret = xenpaging_evict_page(paging, gfn, fd, slot);
+        ret = xenpaging_evict_page(paging, gfn, slot);
         if ( ret < 0 )
             goto out;
     }
@@ -791,7 +799,7 @@ static int evict_victim(struct xenpaging
  * Returns 0 if no gfn can be evicted
  * Returns > 0 on successful evict
  */
-static int evict_pages(struct xenpaging *paging, int fd, int num_pages)
+static int evict_pages(struct xenpaging *paging, int num_pages)
 {
     xc_interface *xch = paging->xc_handle;
     int rc, slot, num = 0;
@@ -802,7 +810,7 @@ static int evict_pages(struct xenpaging 
         if ( paging->slot_to_gfn[slot] )
             continue;
 
-        rc = evict_victim(paging, fd, slot);
+        rc = evict_victim(paging, slot);
         if ( rc )
         {
             num = rc < 0 ? -1 : num;
@@ -826,10 +834,6 @@ int main(int argc, char *argv[])
     int rc;
     xc_interface *xch;
 
-    int open_flags = O_CREAT | O_TRUNC | O_RDWR;
-    mode_t open_mode = S_IRUSR | S_IWUSR;
-    int fd;
-
     /* Initialise domain paging */
     paging = xenpaging_init(argc, argv);
     if ( paging == NULL )
@@ -841,14 +845,6 @@ int main(int argc, char *argv[])
 
     DPRINTF("starting %s for domain_id %u with pagefile %s\n", argv[0], paging->mem_event.domain_id, filename);
 
-    /* Open file */
-    fd = open(filename, open_flags, open_mode);
-    if ( fd < 0 )
-    {
-        perror("failed to open file");
-        return 2;
-    }
-
     /* ensure that if we get a signal, we'll do cleanup, then exit */
     act.sa_handler = close_handler;
     act.sa_flags = 0;
@@ -911,7 +907,7 @@ int main(int argc, char *argv[])
                 else
                 {
                     /* Populate the page */
-                    if ( xenpaging_populate_page(paging, req.gfn, fd, slot) < 0 )
+                    if ( xenpaging_populate_page(paging, req.gfn, slot) < 0 )
                     {
                         ERROR("Error populating page %"PRIx64"", req.gfn);
                         goto out;
@@ -1005,7 +1001,7 @@ int main(int argc, char *argv[])
                 paging->use_poll_timeout = 0;
                 num = 42;
             }
-            if ( evict_pages(paging, fd, num) < 0 )
+            if ( evict_pages(paging, num) < 0 )
                 goto out;
         }
         /* Resume some pages if target not reached */
@@ -1033,7 +1029,7 @@ int main(int argc, char *argv[])
     DPRINTF("xenpaging got signal %d\n", interrupted);
 
  out:
-    close(fd);
+    close(paging->fd);
     unlink_pagefile();
 
     /* Tear down domain paging */
diff -r 649791966e1a -r 4c494f4b99f4 tools/xenpaging/xenpaging.h
--- a/tools/xenpaging/xenpaging.h
+++ b/tools/xenpaging/xenpaging.h
@@ -50,6 +50,7 @@ struct xenpaging {
     int *gfn_to_slot;
 
     struct mem_event mem_event;
+    int fd;
     /* number of pages for which data structures were allocated */
     int max_pages;
     int num_paged_out;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdw-0004GW-AD; Mon, 30 Jan 2012 15:59:44 +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 1Rrtdu-0004CV-Aa
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327939175!9318867!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18680 invoked from network); 30 Jan 2012 15:59:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939175; l=1160;
	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=fHIwjtJeZLZ0atRirvtOmjOt1zk=;
	b=zHhpL2l+x+UC6eSUxBhZr1FjfJh0nyobHnnj4kGmiZC2HRgZO7bx8uh21qfHKmV/q+H
	1D9qrWdXDMLKboATlYfsjn3H+vIfWwpWgmvZrNyyoolY41rZQN005xPetPp7FBdidD7it
	YhEkimb/XrFcURh+nqBQYtRm0nhaQaw8W6I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (fruni mo17) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w03801o0UEuDPD
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 661E218634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:24 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and
 performance improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


This series adjusts the error reporting in the various code paths, with
the intention that fatal errors can be detected by callers and handled
properly. During my performance analysis with callgrind I found and
fixed a few bottlenecks in the page-in code paths.

Patches 1, 2 and 3 were already sent earlier. I'm including them here
again since later patches depend on them.

Changes:
xenpaging: use flat index for pagefile and page-in requests
xenpaging: no poll timeout while page-out is in progress
xenpaging: mmap guest pages read-only
xenpaging: reduce number of qemu cache flushes
xenpaging: move nominate+evict into single function
xenpaging: improve performance in policy_choose_victim
xenpaging: unify error handling
xenpaging: move pagefile filedescriptor into struct xenpaging
xenpaging: move page_buffer into struct xenpaging
xenpaging: implement stack of free slots in pagefile

 tools/xenpaging/policy.h         |    2 
 tools/xenpaging/policy_default.c |   63 ++++--
 tools/xenpaging/xenpaging.c      |  353 ++++++++++++++++++++++-----------------
 tools/xenpaging/xenpaging.h      |   16 -
 4 files changed, 261 insertions(+), 173 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 15:59:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 15: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 1Rrtdw-0004GW-AD; Mon, 30 Jan 2012 15:59:44 +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 1Rrtdu-0004CV-Aa
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 15:59:42 +0000
X-Env-Sender: olaf@aepfle.de
X-Msg-Ref: server-7.tower-216.messagelabs.com!1327939175!9318867!1
X-Originating-IP: [81.169.146.162]
X-SpamReason: No, hits=0.5 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,sa_preprocessor: 
	QmFkIElQOiA4MS4xNjkuMTQ2LjE2MiA9PiAyMjU2ODk=\n,BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18680 invoked from network); 30 Jan 2012 15:59:36 -0000
Received: from mo-p00-ob.rzone.de (HELO mo-p00-ob.rzone.de) (81.169.146.162)
	by server-7.tower-216.messagelabs.com with EDH-RSA-DES-CBC3-SHA
	encrypted SMTP; 30 Jan 2012 15:59:36 -0000
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1327939175; l=1160;
	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=fHIwjtJeZLZ0atRirvtOmjOt1zk=;
	b=zHhpL2l+x+UC6eSUxBhZr1FjfJh0nyobHnnj4kGmiZC2HRgZO7bx8uh21qfHKmV/q+H
	1D9qrWdXDMLKboATlYfsjn3H+vIfWwpWgmvZrNyyoolY41rZQN005xPetPp7FBdidD7it
	YhEkimb/XrFcURh+nqBQYtRm0nhaQaw8W6I=
X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+zrwiavkK6tmQaLfmwtM48/lr0c7qFiX5
X-RZG-CLASS-ID: mo00
Received: from probook.site
	(dslb-084-057-068-141.pools.arcor-ip.net [84.57.68.141])
	by smtp.strato.de (fruni mo17) (RZmta 27.6 DYNA|AUTH)
	with (EDH-RSA-DES-CBC3-SHA encrypted) ESMTPA id w03801o0UEuDPD
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:19 +0100 (MET)
Received: from probook.site (localhost [IPv6:::1])
	by probook.site (Postfix) with ESMTP id 661E218634
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 16:59:24 +0100 (CET)
MIME-Version: 1.0
Message-Id: <patchbomb.1327939163@probook.site>
User-Agent: Mercurial-patchbomb/1.7.5
Date: Mon, 30 Jan 2012 16:59:23 +0100
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH 00 of 10] tools/xenpaging: cleanups and
 performance improvements
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com


This series adjusts the error reporting in the various code paths, with
the intention that fatal errors can be detected by callers and handled
properly. During my performance analysis with callgrind I found and
fixed a few bottlenecks in the page-in code paths.

Patches 1, 2 and 3 were already sent earlier. I'm including them here
again since later patches depend on them.

Changes:
xenpaging: use flat index for pagefile and page-in requests
xenpaging: no poll timeout while page-out is in progress
xenpaging: mmap guest pages read-only
xenpaging: reduce number of qemu cache flushes
xenpaging: move nominate+evict into single function
xenpaging: improve performance in policy_choose_victim
xenpaging: unify error handling
xenpaging: move pagefile filedescriptor into struct xenpaging
xenpaging: move page_buffer into struct xenpaging
xenpaging: implement stack of free slots in pagefile

 tools/xenpaging/policy.h         |    2 
 tools/xenpaging/policy_default.c |   63 ++++--
 tools/xenpaging/xenpaging.c      |  353 ++++++++++++++++++++++-----------------
 tools/xenpaging/xenpaging.h      |   16 -
 4 files changed, 261 insertions(+), 173 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:01:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RrtfE-0005Dp-6x; Mon, 30 Jan 2012 16:01: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 1RrtfB-0005Bd-Vg
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:01:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327939254!12622625!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23196 invoked from network); 30 Jan 2012 16:00:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:00:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21417127"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:00:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:00: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 q0UG0j3G029218;
	Mon, 30 Jan 2012 08:00:46 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 16:02:31 +0000
Message-ID: <1327939351-22111-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v3] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements support for multiple consoles:
consoles other than the first one are setup using the traditional xenbus
and grant-table based mechanism.
We use a list to keep track of the allocated consoles, we don't
expect too many of them anyway.


Changes in v3:

- call hvc_remove before removing the console from xenconsoles;
- do not lock xencons_lock twice in the destruction path;
- use the DEFINE_XENBUS_DRIVER macro.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c |  435 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 377 insertions(+), 58 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index d5000aa..26090c7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -23,6 +23,7 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/types.h>
+#include <linux/list.h>
 
 #include <asm/io.h>
 #include <asm/xen/hypervisor.h>
@@ -30,47 +31,67 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/hvm.h>
+#include <xen/grant_table.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
 #include <xen/hvc-console.h>
+#include <xen/xenbus.h>
 
 #include "hvc_console.h"
 
 #define HVC_COOKIE   0x58656e /* "Xen" in hex */
 
-static struct hvc_struct *hvc;
-static int xencons_irq;
+struct xencons_info {
+	struct list_head list;
+	struct xenbus_device *xbdev;
+	struct xencons_interface *intf;
+	unsigned int evtchn;
+	struct hvc_struct *hvc;
+	int irq;
+	int vtermno;
+	grant_ref_t gntref;
+};
+
+static LIST_HEAD(xenconsoles);
+static DEFINE_SPINLOCK(xencons_lock);
+static struct xenbus_driver xencons_driver;
 
 /* ------------------------------------------------------------------ */
 
-static unsigned long console_pfn = ~0ul;
-static unsigned int console_evtchn = ~0ul;
-static struct xencons_interface *xencons_if = NULL;
+static struct xencons_info *vtermno_to_xencons(int vtermno)
+{
+	struct xencons_info *entry, *n, *ret = NULL;
+
+	if (list_empty(&xenconsoles))
+			return NULL;
 
-static inline struct xencons_interface *xencons_interface(void)
+	list_for_each_entry_safe(entry, n, &xenconsoles, list) {
+		if (entry->vtermno == vtermno) {
+			ret  = entry;
+			break;
+		}
+	}
+
+	return ret;
+}
+
+static inline int xenbus_devid_to_vtermno(int devid)
 {
-	if (xencons_if != NULL)
-		return xencons_if;
-	if (console_pfn == ~0ul)
-		return mfn_to_virt(xen_start_info->console.domU.mfn);
-	else
-		return __va(console_pfn << PAGE_SHIFT);
+	return devid + HVC_COOKIE;
 }
 
-static inline void notify_daemon(void)
+static inline void notify_daemon(struct xencons_info *cons)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	if (console_evtchn == ~0ul)
-		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
-	else
-		notify_remote_via_evtchn(console_evtchn);
+	notify_remote_via_evtchn(cons->evtchn);
 }
 
-static int __write_console(const char *data, int len)
+static int __write_console(struct xencons_info *xencons,
+		const char *data, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
 	XENCONS_RING_IDX cons, prod;
+	struct xencons_interface *intf = xencons->intf;
 	int sent = 0;
 
 	cons = intf->out_cons;
@@ -85,13 +106,16 @@ static int __write_console(const char *data, int len)
 	intf->out_prod = prod;
 
 	if (sent)
-		notify_daemon();
+		notify_daemon(xencons);
 	return sent;
 }
 
 static int domU_write_console(uint32_t vtermno, const char *data, int len)
 {
 	int ret = len;
+	struct xencons_info *cons = vtermno_to_xencons(vtermno);
+	if (cons == NULL)
+		return -EINVAL;
 
 	/*
 	 * Make sure the whole buffer is emitted, polling if
@@ -100,7 +124,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 	 * kernel is crippled.
 	 */
 	while (len) {
-		int sent = __write_console(data, len);
+		int sent = __write_console(cons, data, len);
 		
 		data += sent;
 		len -= sent;
@@ -114,9 +138,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 
 static int domU_read_console(uint32_t vtermno, char *buf, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
+	struct xencons_interface *intf;
 	XENCONS_RING_IDX cons, prod;
 	int recv = 0;
+	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
+	if (xencons == NULL)
+		return -EINVAL;
+	intf = xencons->intf;
 
 	cons = intf->in_cons;
 	prod = intf->in_prod;
@@ -129,7 +157,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
 	mb();			/* read ring before consuming */
 	intf->in_cons = cons;
 
-	notify_daemon();
+	notify_daemon(xencons);
 	return recv;
 }
 
@@ -172,78 +200,359 @@ static int xen_hvm_console_init(void)
 	int r;
 	uint64_t v = 0;
 	unsigned long mfn;
+	struct xencons_info *info;
 
 	if (!xen_hvm_domain())
 		return -ENODEV;
 
-	if (xencons_if != NULL)
-		return -EBUSY;
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
 
 	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
-	console_evtchn = v;
+	}
+	info->evtchn = v;
 	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
+	}
 	mfn = v;
-	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
-	if (xencons_if == NULL)
+	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (info->intf == NULL) {
+		kfree(info);
+		return -ENODEV;
+	}
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_pv_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_pv_domain())
+		return -ENODEV;
+
+	if (!xen_start_info->console.domU.evtchn)
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
+
+	info->evtchn = xen_start_info->console.domU.evtchn;
+	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_initial_domain_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_initial_domain())
 		return -ENODEV;
 
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
 	return 0;
 }
 
 static int __init xen_hvc_init(void)
 {
-	struct hvc_struct *hp;
-	struct hv_ops *ops;
 	int r;
+	struct xencons_info *info;
+	const struct hv_ops *ops;
 
 	if (!xen_domain())
 		return -ENODEV;
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
-		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+		r = xen_initial_domain_console_init();
+		if (r < 0)
+			return r;
+		info = vtermno_to_xencons(HVC_COOKIE);
 	} else {
 		ops = &domU_hvc_ops;
-		if (xen_pv_domain()) {
-			if (!xen_start_info->console.domU.evtchn)
-				return -ENODEV;
-			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-			console_evtchn = xen_start_info->console.domU.evtchn;
-		} else {
+		if (xen_hvm_domain())
 			r = xen_hvm_console_init();
-			if (r < 0)
-				return r;
-		}
-		xencons_irq = bind_evtchn_to_irq(console_evtchn);
-		if (xencons_irq < 0)
-			xencons_irq = 0; /* NO_IRQ */
 		else
-			irq_set_noprobe(xencons_irq);
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
+
+		info = vtermno_to_xencons(HVC_COOKIE);
+		info->irq = bind_evtchn_to_irq(info->evtchn);
+	}
+	if (info->irq < 0)
+		info->irq = 0; /* NO_IRQ */
+	else
+		irq_set_noprobe(info->irq);
+
+	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
+	if (IS_ERR(info->hvc)) {
+		r = PTR_ERR(info->hvc);
+		spin_lock(&xencons_lock);
+		list_del(&info->list);
+		spin_unlock(&xencons_lock);
+		if (info->irq)
+			unbind_from_irqhandler(info->irq, NULL);
+		kfree(info);
+		return r;
 	}
 
-	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
-	if (IS_ERR(hp))
-		return PTR_ERR(hp);
+	return xenbus_register_frontend(&xencons_driver);
+}
 
-	hvc = hp;
+void xen_console_resume(void)
+{
+	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
+	if (info != NULL && info->irq)
+		rebind_evtchn_irq(info->evtchn, info->irq);
+}
+
+static void xencons_disconnect_backend(struct xencons_info *info)
+{
+	if (info->irq > 0)
+		unbind_from_irqhandler(info->irq, NULL);
+	info->irq = 0;
+	if (info->evtchn > 0)
+		xenbus_free_evtchn(info->xbdev, info->evtchn);
+	info->evtchn = 0;
+	if (info->gntref > 0)
+		gnttab_free_grant_references(info->gntref);
+	info->gntref = 0;
+	if (info->hvc != NULL)
+		hvc_remove(info->hvc);
+	info->hvc = NULL;
+}
 
+static void xencons_free(struct xencons_info *info)
+{
+	free_page((unsigned long)info->intf);
+	info->intf = NULL;
+	info->vtermno = 0;
+	kfree(info);
+}
+
+static int xen_console_remove(struct xencons_info *info)
+{
+	xencons_disconnect_backend(info);
+	spin_lock(&xencons_lock);
+	list_del(&info->list);
+	spin_unlock(&xencons_lock);
+	if (info->xbdev != NULL)
+		xencons_free(info);
+	else {
+		if (xen_hvm_domain())
+			iounmap(info->intf);
+		kfree(info);
+	}
 	return 0;
 }
 
-void xen_console_resume(void)
+static int xencons_remove(struct xenbus_device *dev)
+{
+	return xen_console_remove(dev_get_drvdata(&dev->dev));
+}
+
+static int xencons_connect_backend(struct xenbus_device *dev,
+				  struct xencons_info *info)
+{
+	int ret, evtchn, devid, ref, irq;
+	struct xenbus_transaction xbt;
+	grant_ref_t gref_head;
+	unsigned long mfn;
+
+	ret = xenbus_alloc_evtchn(dev, &evtchn);
+	if (ret)
+		return ret;
+	info->evtchn = evtchn;
+	irq = bind_evtchn_to_irq(evtchn);
+	if (irq < 0)
+		return irq;
+	info->irq = irq;
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
+			irq, &domU_hvc_ops, 256);
+	if (IS_ERR(info->hvc))
+		return PTR_ERR(info->hvc);
+	if (xen_pv_domain())
+		mfn = virt_to_mfn(info->intf);
+	else
+		mfn = __pa(info->intf) >> PAGE_SHIFT;
+	ret = gnttab_alloc_grant_references(1, &gref_head);
+	if (ret < 0)
+		return ret;
+	info->gntref = gref_head;
+	ref = gnttab_claim_grant_reference(&gref_head);
+	if (ref < 0)
+		return ref;
+	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
+			mfn, 0);
+
+ again:
+	ret = xenbus_transaction_start(&xbt);
+	if (ret) {
+		xenbus_dev_fatal(dev, ret, "starting transaction");
+		return ret;
+	}
+	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
+			    evtchn);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_transaction_end(xbt, 0);
+	if (ret) {
+		if (ret == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, ret, "completing transaction");
+		return ret;
+	}
+
+	xenbus_switch_state(dev, XenbusStateInitialised);
+	return 0;
+
+ error_xenbus:
+	xenbus_transaction_end(xbt, 1);
+	xenbus_dev_fatal(dev, ret, "writing xenstore");
+	return ret;
+}
+
+static int __devinit xencons_probe(struct xenbus_device *dev,
+				  const struct xenbus_device_id *id)
+{
+	int ret, devid;
+	struct xencons_info *info;
+
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	if (devid == 0)
+		return -ENODEV;
+
+	info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+	if (!info)
+		goto error_nomem;
+	dev_set_drvdata(&dev->dev, info);
+	info->xbdev = dev;
+	info->vtermno = xenbus_devid_to_vtermno(devid);
+	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+	if (!info->intf)
+		goto error_nomem;
+
+	ret = xencons_connect_backend(dev, info);
+	if (ret < 0)
+		goto error;
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+
+ error_nomem:
+	ret = -ENOMEM;
+	xenbus_dev_fatal(dev, ret, "allocating device memory");
+ error:
+	xencons_disconnect_backend(info);
+	xencons_free(info);
+	return ret;
+}
+
+static int xencons_resume(struct xenbus_device *dev)
 {
-	if (xencons_irq)
-		rebind_evtchn_irq(console_evtchn, xencons_irq);
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	xencons_disconnect_backend(info);
+	memset(info->intf, 0, PAGE_SIZE);
+	return xencons_connect_backend(dev, info);
 }
 
+static void xencons_backend_changed(struct xenbus_device *dev,
+				   enum xenbus_state backend_state)
+{
+	switch (backend_state) {
+	case XenbusStateReconfiguring:
+	case XenbusStateReconfigured:
+	case XenbusStateInitialising:
+	case XenbusStateInitialised:
+	case XenbusStateUnknown:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitWait:
+		break;
+
+	case XenbusStateConnected:
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateClosing:
+		xenbus_frontend_closed(dev);
+		break;
+	}
+}
+
+static const struct xenbus_device_id xencons_ids[] = {
+	{ "console" },
+	{ "" }
+};
+
+
 static void __exit xen_hvc_fini(void)
 {
-	if (hvc)
-		hvc_remove(hvc);
+	struct xencons_info *entry, *next;
+
+	if (list_empty(&xenconsoles))
+			return;
+
+	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
+		xen_console_remove(entry);
+	}
 }
 
 static int xen_cons_init(void)
@@ -256,18 +565,28 @@ static int xen_cons_init(void)
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
 	else {
+		int r;
 		ops = &domU_hvc_ops;
 
-		if (xen_pv_domain())
-			console_evtchn = xen_start_info->console.domU.evtchn;
+		if (xen_hvm_domain())
+			r = xen_hvm_console_init();
 		else
-			xen_hvm_console_init();
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
 	}
 
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
 
+static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
+	.probe = xencons_probe,
+	.remove = xencons_remove,
+	.resume = xencons_resume,
+	.otherend_changed = xencons_backend_changed,
+);
+
 module_init(xen_hvc_init);
 module_exit(xen_hvc_fini);
 console_initcall(xen_cons_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:01:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RrtfE-0005Dp-6x; Mon, 30 Jan 2012 16:01: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 1RrtfB-0005Bd-Vg
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:01:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-216.messagelabs.com!1327939254!12622625!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23196 invoked from network); 30 Jan 2012 16:00:55 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-6.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:00:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21417127"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:00:53 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:00: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 q0UG0j3G029218;
	Mon, 30 Jan 2012 08:00:46 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 16:02:31 +0000
Message-ID: <1327939351-22111-1-git-send-email-stefano.stabellini@eu.citrix.com>
X-Mailer: git-send-email 1.7.0.4
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	linux-kernel@vger.kernel.org, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v3] hvc_xen: implement multiconsole support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch implements support for multiple consoles:
consoles other than the first one are setup using the traditional xenbus
and grant-table based mechanism.
We use a list to keep track of the allocated consoles, we don't
expect too many of them anyway.


Changes in v3:

- call hvc_remove before removing the console from xenconsoles;
- do not lock xencons_lock twice in the destruction path;
- use the DEFINE_XENBUS_DRIVER macro.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/tty/hvc/hvc_xen.c |  435 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 377 insertions(+), 58 deletions(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index d5000aa..26090c7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -23,6 +23,7 @@
 #include <linux/err.h>
 #include <linux/init.h>
 #include <linux/types.h>
+#include <linux/list.h>
 
 #include <asm/io.h>
 #include <asm/xen/hypervisor.h>
@@ -30,47 +31,67 @@
 #include <xen/xen.h>
 #include <xen/interface/xen.h>
 #include <xen/hvm.h>
+#include <xen/grant_table.h>
 #include <xen/page.h>
 #include <xen/events.h>
 #include <xen/interface/io/console.h>
 #include <xen/hvc-console.h>
+#include <xen/xenbus.h>
 
 #include "hvc_console.h"
 
 #define HVC_COOKIE   0x58656e /* "Xen" in hex */
 
-static struct hvc_struct *hvc;
-static int xencons_irq;
+struct xencons_info {
+	struct list_head list;
+	struct xenbus_device *xbdev;
+	struct xencons_interface *intf;
+	unsigned int evtchn;
+	struct hvc_struct *hvc;
+	int irq;
+	int vtermno;
+	grant_ref_t gntref;
+};
+
+static LIST_HEAD(xenconsoles);
+static DEFINE_SPINLOCK(xencons_lock);
+static struct xenbus_driver xencons_driver;
 
 /* ------------------------------------------------------------------ */
 
-static unsigned long console_pfn = ~0ul;
-static unsigned int console_evtchn = ~0ul;
-static struct xencons_interface *xencons_if = NULL;
+static struct xencons_info *vtermno_to_xencons(int vtermno)
+{
+	struct xencons_info *entry, *n, *ret = NULL;
+
+	if (list_empty(&xenconsoles))
+			return NULL;
 
-static inline struct xencons_interface *xencons_interface(void)
+	list_for_each_entry_safe(entry, n, &xenconsoles, list) {
+		if (entry->vtermno == vtermno) {
+			ret  = entry;
+			break;
+		}
+	}
+
+	return ret;
+}
+
+static inline int xenbus_devid_to_vtermno(int devid)
 {
-	if (xencons_if != NULL)
-		return xencons_if;
-	if (console_pfn == ~0ul)
-		return mfn_to_virt(xen_start_info->console.domU.mfn);
-	else
-		return __va(console_pfn << PAGE_SHIFT);
+	return devid + HVC_COOKIE;
 }
 
-static inline void notify_daemon(void)
+static inline void notify_daemon(struct xencons_info *cons)
 {
 	/* Use evtchn: this is called early, before irq is set up. */
-	if (console_evtchn == ~0ul)
-		notify_remote_via_evtchn(xen_start_info->console.domU.evtchn);
-	else
-		notify_remote_via_evtchn(console_evtchn);
+	notify_remote_via_evtchn(cons->evtchn);
 }
 
-static int __write_console(const char *data, int len)
+static int __write_console(struct xencons_info *xencons,
+		const char *data, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
 	XENCONS_RING_IDX cons, prod;
+	struct xencons_interface *intf = xencons->intf;
 	int sent = 0;
 
 	cons = intf->out_cons;
@@ -85,13 +106,16 @@ static int __write_console(const char *data, int len)
 	intf->out_prod = prod;
 
 	if (sent)
-		notify_daemon();
+		notify_daemon(xencons);
 	return sent;
 }
 
 static int domU_write_console(uint32_t vtermno, const char *data, int len)
 {
 	int ret = len;
+	struct xencons_info *cons = vtermno_to_xencons(vtermno);
+	if (cons == NULL)
+		return -EINVAL;
 
 	/*
 	 * Make sure the whole buffer is emitted, polling if
@@ -100,7 +124,7 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 	 * kernel is crippled.
 	 */
 	while (len) {
-		int sent = __write_console(data, len);
+		int sent = __write_console(cons, data, len);
 		
 		data += sent;
 		len -= sent;
@@ -114,9 +138,13 @@ static int domU_write_console(uint32_t vtermno, const char *data, int len)
 
 static int domU_read_console(uint32_t vtermno, char *buf, int len)
 {
-	struct xencons_interface *intf = xencons_interface();
+	struct xencons_interface *intf;
 	XENCONS_RING_IDX cons, prod;
 	int recv = 0;
+	struct xencons_info *xencons = vtermno_to_xencons(vtermno);
+	if (xencons == NULL)
+		return -EINVAL;
+	intf = xencons->intf;
 
 	cons = intf->in_cons;
 	prod = intf->in_prod;
@@ -129,7 +157,7 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
 	mb();			/* read ring before consuming */
 	intf->in_cons = cons;
 
-	notify_daemon();
+	notify_daemon(xencons);
 	return recv;
 }
 
@@ -172,78 +200,359 @@ static int xen_hvm_console_init(void)
 	int r;
 	uint64_t v = 0;
 	unsigned long mfn;
+	struct xencons_info *info;
 
 	if (!xen_hvm_domain())
 		return -ENODEV;
 
-	if (xencons_if != NULL)
-		return -EBUSY;
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
 
 	r = hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
-	console_evtchn = v;
+	}
+	info->evtchn = v;
 	hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, &v);
-	if (r < 0)
+	if (r < 0) {
+		kfree(info);
 		return -ENODEV;
+	}
 	mfn = v;
-	xencons_if = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
-	if (xencons_if == NULL)
+	info->intf = ioremap(mfn << PAGE_SHIFT, PAGE_SIZE);
+	if (info->intf == NULL) {
+		kfree(info);
+		return -ENODEV;
+	}
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_pv_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_pv_domain())
+		return -ENODEV;
+
+	if (!xen_start_info->console.domU.evtchn)
+		return -ENODEV;
+
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	/* already configured */
+	if (info->intf != NULL)
+		return 0;
+
+	info->evtchn = xen_start_info->console.domU.evtchn;
+	info->intf = mfn_to_virt(xen_start_info->console.domU.mfn);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+}
+
+static int xen_initial_domain_console_init(void)
+{
+	struct xencons_info *info;
+
+	if (!xen_initial_domain())
 		return -ENODEV;
 
+	info = vtermno_to_xencons(HVC_COOKIE);
+	if (!info) {
+		info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+		if (!info)
+			return -ENOMEM;
+	}
+
+	info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+	info->vtermno = HVC_COOKIE;
+
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
 	return 0;
 }
 
 static int __init xen_hvc_init(void)
 {
-	struct hvc_struct *hp;
-	struct hv_ops *ops;
 	int r;
+	struct xencons_info *info;
+	const struct hv_ops *ops;
 
 	if (!xen_domain())
 		return -ENODEV;
 
 	if (xen_initial_domain()) {
 		ops = &dom0_hvc_ops;
-		xencons_irq = bind_virq_to_irq(VIRQ_CONSOLE, 0);
+		r = xen_initial_domain_console_init();
+		if (r < 0)
+			return r;
+		info = vtermno_to_xencons(HVC_COOKIE);
 	} else {
 		ops = &domU_hvc_ops;
-		if (xen_pv_domain()) {
-			if (!xen_start_info->console.domU.evtchn)
-				return -ENODEV;
-			console_pfn = mfn_to_pfn(xen_start_info->console.domU.mfn);
-			console_evtchn = xen_start_info->console.domU.evtchn;
-		} else {
+		if (xen_hvm_domain())
 			r = xen_hvm_console_init();
-			if (r < 0)
-				return r;
-		}
-		xencons_irq = bind_evtchn_to_irq(console_evtchn);
-		if (xencons_irq < 0)
-			xencons_irq = 0; /* NO_IRQ */
 		else
-			irq_set_noprobe(xencons_irq);
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
+
+		info = vtermno_to_xencons(HVC_COOKIE);
+		info->irq = bind_evtchn_to_irq(info->evtchn);
+	}
+	if (info->irq < 0)
+		info->irq = 0; /* NO_IRQ */
+	else
+		irq_set_noprobe(info->irq);
+
+	info->hvc = hvc_alloc(HVC_COOKIE, info->irq, ops, 256);
+	if (IS_ERR(info->hvc)) {
+		r = PTR_ERR(info->hvc);
+		spin_lock(&xencons_lock);
+		list_del(&info->list);
+		spin_unlock(&xencons_lock);
+		if (info->irq)
+			unbind_from_irqhandler(info->irq, NULL);
+		kfree(info);
+		return r;
 	}
 
-	hp = hvc_alloc(HVC_COOKIE, xencons_irq, ops, 256);
-	if (IS_ERR(hp))
-		return PTR_ERR(hp);
+	return xenbus_register_frontend(&xencons_driver);
+}
 
-	hvc = hp;
+void xen_console_resume(void)
+{
+	struct xencons_info *info = vtermno_to_xencons(HVC_COOKIE);
+	if (info != NULL && info->irq)
+		rebind_evtchn_irq(info->evtchn, info->irq);
+}
+
+static void xencons_disconnect_backend(struct xencons_info *info)
+{
+	if (info->irq > 0)
+		unbind_from_irqhandler(info->irq, NULL);
+	info->irq = 0;
+	if (info->evtchn > 0)
+		xenbus_free_evtchn(info->xbdev, info->evtchn);
+	info->evtchn = 0;
+	if (info->gntref > 0)
+		gnttab_free_grant_references(info->gntref);
+	info->gntref = 0;
+	if (info->hvc != NULL)
+		hvc_remove(info->hvc);
+	info->hvc = NULL;
+}
 
+static void xencons_free(struct xencons_info *info)
+{
+	free_page((unsigned long)info->intf);
+	info->intf = NULL;
+	info->vtermno = 0;
+	kfree(info);
+}
+
+static int xen_console_remove(struct xencons_info *info)
+{
+	xencons_disconnect_backend(info);
+	spin_lock(&xencons_lock);
+	list_del(&info->list);
+	spin_unlock(&xencons_lock);
+	if (info->xbdev != NULL)
+		xencons_free(info);
+	else {
+		if (xen_hvm_domain())
+			iounmap(info->intf);
+		kfree(info);
+	}
 	return 0;
 }
 
-void xen_console_resume(void)
+static int xencons_remove(struct xenbus_device *dev)
+{
+	return xen_console_remove(dev_get_drvdata(&dev->dev));
+}
+
+static int xencons_connect_backend(struct xenbus_device *dev,
+				  struct xencons_info *info)
+{
+	int ret, evtchn, devid, ref, irq;
+	struct xenbus_transaction xbt;
+	grant_ref_t gref_head;
+	unsigned long mfn;
+
+	ret = xenbus_alloc_evtchn(dev, &evtchn);
+	if (ret)
+		return ret;
+	info->evtchn = evtchn;
+	irq = bind_evtchn_to_irq(evtchn);
+	if (irq < 0)
+		return irq;
+	info->irq = irq;
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	info->hvc = hvc_alloc(xenbus_devid_to_vtermno(devid),
+			irq, &domU_hvc_ops, 256);
+	if (IS_ERR(info->hvc))
+		return PTR_ERR(info->hvc);
+	if (xen_pv_domain())
+		mfn = virt_to_mfn(info->intf);
+	else
+		mfn = __pa(info->intf) >> PAGE_SHIFT;
+	ret = gnttab_alloc_grant_references(1, &gref_head);
+	if (ret < 0)
+		return ret;
+	info->gntref = gref_head;
+	ref = gnttab_claim_grant_reference(&gref_head);
+	if (ref < 0)
+		return ref;
+	gnttab_grant_foreign_access_ref(ref, info->xbdev->otherend_id,
+			mfn, 0);
+
+ again:
+	ret = xenbus_transaction_start(&xbt);
+	if (ret) {
+		xenbus_dev_fatal(dev, ret, "starting transaction");
+		return ret;
+	}
+	ret = xenbus_printf(xbt, dev->nodename, "ring-ref", "%d", ref);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "port", "%u",
+			    evtchn);
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_printf(xbt, dev->nodename, "type", "ioemu");
+	if (ret)
+		goto error_xenbus;
+	ret = xenbus_transaction_end(xbt, 0);
+	if (ret) {
+		if (ret == -EAGAIN)
+			goto again;
+		xenbus_dev_fatal(dev, ret, "completing transaction");
+		return ret;
+	}
+
+	xenbus_switch_state(dev, XenbusStateInitialised);
+	return 0;
+
+ error_xenbus:
+	xenbus_transaction_end(xbt, 1);
+	xenbus_dev_fatal(dev, ret, "writing xenstore");
+	return ret;
+}
+
+static int __devinit xencons_probe(struct xenbus_device *dev,
+				  const struct xenbus_device_id *id)
+{
+	int ret, devid;
+	struct xencons_info *info;
+
+	devid = dev->nodename[strlen(dev->nodename) - 1] - '0';
+	if (devid == 0)
+		return -ENODEV;
+
+	info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL | __GFP_ZERO);
+	if (!info)
+		goto error_nomem;
+	dev_set_drvdata(&dev->dev, info);
+	info->xbdev = dev;
+	info->vtermno = xenbus_devid_to_vtermno(devid);
+	info->intf = (void *)__get_free_page(GFP_KERNEL | __GFP_ZERO);
+	if (!info->intf)
+		goto error_nomem;
+
+	ret = xencons_connect_backend(dev, info);
+	if (ret < 0)
+		goto error;
+	spin_lock(&xencons_lock);
+	list_add_tail(&info->list, &xenconsoles);
+	spin_unlock(&xencons_lock);
+
+	return 0;
+
+ error_nomem:
+	ret = -ENOMEM;
+	xenbus_dev_fatal(dev, ret, "allocating device memory");
+ error:
+	xencons_disconnect_backend(info);
+	xencons_free(info);
+	return ret;
+}
+
+static int xencons_resume(struct xenbus_device *dev)
 {
-	if (xencons_irq)
-		rebind_evtchn_irq(console_evtchn, xencons_irq);
+	struct xencons_info *info = dev_get_drvdata(&dev->dev);
+
+	xencons_disconnect_backend(info);
+	memset(info->intf, 0, PAGE_SIZE);
+	return xencons_connect_backend(dev, info);
 }
 
+static void xencons_backend_changed(struct xenbus_device *dev,
+				   enum xenbus_state backend_state)
+{
+	switch (backend_state) {
+	case XenbusStateReconfiguring:
+	case XenbusStateReconfigured:
+	case XenbusStateInitialising:
+	case XenbusStateInitialised:
+	case XenbusStateUnknown:
+	case XenbusStateClosed:
+		break;
+
+	case XenbusStateInitWait:
+		break;
+
+	case XenbusStateConnected:
+		xenbus_switch_state(dev, XenbusStateConnected);
+		break;
+
+	case XenbusStateClosing:
+		xenbus_frontend_closed(dev);
+		break;
+	}
+}
+
+static const struct xenbus_device_id xencons_ids[] = {
+	{ "console" },
+	{ "" }
+};
+
+
 static void __exit xen_hvc_fini(void)
 {
-	if (hvc)
-		hvc_remove(hvc);
+	struct xencons_info *entry, *next;
+
+	if (list_empty(&xenconsoles))
+			return;
+
+	list_for_each_entry_safe(entry, next, &xenconsoles, list) {
+		xen_console_remove(entry);
+	}
 }
 
 static int xen_cons_init(void)
@@ -256,18 +565,28 @@ static int xen_cons_init(void)
 	if (xen_initial_domain())
 		ops = &dom0_hvc_ops;
 	else {
+		int r;
 		ops = &domU_hvc_ops;
 
-		if (xen_pv_domain())
-			console_evtchn = xen_start_info->console.domU.evtchn;
+		if (xen_hvm_domain())
+			r = xen_hvm_console_init();
 		else
-			xen_hvm_console_init();
+			r = xen_pv_console_init();
+		if (r < 0)
+			return r;
 	}
 
 	hvc_instantiate(HVC_COOKIE, 0, ops);
 	return 0;
 }
 
+static DEFINE_XENBUS_DRIVER(xencons, "xenconsole",
+	.probe = xencons_probe,
+	.remove = xencons_remove,
+	.resume = xencons_resume,
+	.otherend_changed = xencons_backend_changed,
+);
+
 module_init(xen_hvc_init);
 module_exit(xen_hvc_fini);
 console_initcall(xen_cons_init);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:06:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtkO-0006Qp-5Y; Mon, 30 Jan 2012 16:06:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RrtkM-0006Qh-Jg
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:06:22 +0000
Received: from [85.158.138.51:38832] by server-6.bemta-3.messagelabs.com id
	ED/2A-31032-DFFB62F4; Mon, 30 Jan 2012 16:06:21 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327939579!11106862!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16012 invoked from network); 30 Jan 2012 16:06:21 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:06:21 -0000
Received: by vcbfo11 with SMTP id fo11so9405081vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 08:06:19 -0800 (PST)
Received: by 10.220.108.16 with SMTP id d16mr8971493vcp.65.1327939579605;
	Mon, 30 Jan 2012 08:06:19 -0800 (PST)
Received: from [172.16.0.10] ([205.250.160.181])
	by mx.google.com with ESMTPS id fa4sm15932242vdc.19.2012.01.30.08.06.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Jan 2012 08:06:17 -0800 (PST)
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
	<1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
	<alpine.DEB.2.00.1201301220280.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201301220280.3196@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <F7D7652D-C74F-4921-8662-357CB8671E58@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 30 Jan 2012 08:06:13 -0800
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-30, at 6:16 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 27 Jan 2012, Shriram Rajagopalan wrote:
>> If there is an error in applying the toolstack state, then pagebuf_get returns -1 and
>> the rest of the code would still attempt to resume the domain, with possibly
>> inconsistent device model state.
> 
> This sounds like an unhandled error in the caller of pagebuf_get.

Nope. pagebuf_get is used only when Remus is on. 
It is called after applying the last memory checkpoint.
So when it returns an error, we simply discard whatever we buffered
and wrap up. For migration we
have a special xc_save_id_last_checkpoint
that terminates the code after 
buffering the first pagebuf.

> I think that if pagebuf_get returns an error, the error should be
> propagated and the migration should be aborted, right?
> After all I don't think we can successfully resume the domain if we fail
> to read XC_SAVE_ID_TSC_INFO, for example.
> I think we need something like this:
> 
> 
> @@ -1589,9 +1616,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> 
>     // DPRINTF("Buffered checkpoint\n");
> 
> -    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
> +    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
>         PERROR("error when buffering batch, finishing");
> -        goto finish;
> +        goto out;
>     }
>     memset(&tmptail, 0, sizeof(tmptail));
>     tmptail.ishvm = hvm;
> 
> 
>> Also, lets say there was no error in applying the toolstack state. If a network
>> error occurs while receiving the next XC_SAVE_ID or so, then again, the code following
>> the above snippet would attempt to resume the domain, with a memory state inconsistent
>> with the device state.
> 
> This seems wrong to me, but I am not very familiar with this protocol.
> As I wrote above, why should we continue if pagebuf_get returns an
> error?
> 
> 
>> The right place to call the callbacks->toolstack_restore would be after the finish_hvm:
>> label, where currently the old QEMU device state is restored.
> 
> Are you suggesting that we should read the toolstack data from
> pagebuf_get but only call the callback after finish_hvm?

Yep. I hope the above explanation made some sense.

> I can do that but honestly it doesn't make too much sense to me.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:06:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtkO-0006Qp-5Y; Mon, 30 Jan 2012 16:06:24 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@gmail.com>) id 1RrtkM-0006Qh-Jg
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:06:22 +0000
Received: from [85.158.138.51:38832] by server-6.bemta-3.messagelabs.com id
	ED/2A-31032-DFFB62F4; Mon, 30 Jan 2012 16:06:21 +0000
X-Env-Sender: rshriram@gmail.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1327939579!11106862!1
X-Originating-IP: [209.85.220.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=MIME_QP_LONG_LINE,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16012 invoked from network); 30 Jan 2012 16:06:21 -0000
Received: from mail-vx0-f171.google.com (HELO mail-vx0-f171.google.com)
	(209.85.220.171)
	by server-16.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:06:21 -0000
Received: by vcbfo11 with SMTP id fo11so9405081vcb.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 08:06:19 -0800 (PST)
Received: by 10.220.108.16 with SMTP id d16mr8971493vcp.65.1327939579605;
	Mon, 30 Jan 2012 08:06:19 -0800 (PST)
Received: from [172.16.0.10] ([205.250.160.181])
	by mx.google.com with ESMTPS id fa4sm15932242vdc.19.2012.01.30.08.06.16
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Jan 2012 08:06:17 -0800 (PST)
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
	<1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
	<alpine.DEB.2.00.1201301220280.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201301220280.3196@kaball-desktop>
Mime-Version: 1.0 (1.0)
Message-Id: <F7D7652D-C74F-4921-8662-357CB8671E58@cs.ubc.ca>
X-Mailer: iPhone Mail (9A405)
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 30 Jan 2012 08:06:13 -0800
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 2012-01-30, at 6:16 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:

> On Fri, 27 Jan 2012, Shriram Rajagopalan wrote:
>> If there is an error in applying the toolstack state, then pagebuf_get returns -1 and
>> the rest of the code would still attempt to resume the domain, with possibly
>> inconsistent device model state.
> 
> This sounds like an unhandled error in the caller of pagebuf_get.

Nope. pagebuf_get is used only when Remus is on. 
It is called after applying the last memory checkpoint.
So when it returns an error, we simply discard whatever we buffered
and wrap up. For migration we
have a special xc_save_id_last_checkpoint
that terminates the code after 
buffering the first pagebuf.

> I think that if pagebuf_get returns an error, the error should be
> propagated and the migration should be aborted, right?
> After all I don't think we can successfully resume the domain if we fail
> to read XC_SAVE_ID_TSC_INFO, for example.
> I think we need something like this:
> 
> 
> @@ -1589,9 +1616,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> 
>     // DPRINTF("Buffered checkpoint\n");
> 
> -    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
> +    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
>         PERROR("error when buffering batch, finishing");
> -        goto finish;
> +        goto out;
>     }
>     memset(&tmptail, 0, sizeof(tmptail));
>     tmptail.ishvm = hvm;
> 
> 
>> Also, lets say there was no error in applying the toolstack state. If a network
>> error occurs while receiving the next XC_SAVE_ID or so, then again, the code following
>> the above snippet would attempt to resume the domain, with a memory state inconsistent
>> with the device state.
> 
> This seems wrong to me, but I am not very familiar with this protocol.
> As I wrote above, why should we continue if pagebuf_get returns an
> error?
> 
> 
>> The right place to call the callbacks->toolstack_restore would be after the finish_hvm:
>> label, where currently the old QEMU device state is restored.
> 
> Are you suggesting that we should read the toolstack data from
> pagebuf_get but only call the callback after finish_hvm?

Yep. I hope the above explanation made some sense.

> I can do that but honestly it doesn't make too much sense to me.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:07:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtlL-0006Ui-Kh; Mon, 30 Jan 2012 16:07:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>)
	id 1RrtlJ-0006UQ-TX; Mon, 30 Jan 2012 16:07:22 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327939595!62300387!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1313 invoked from network); 30 Jan 2012 16:06:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:06:36 -0000
Received: by iaeh11 with SMTP id h11so38440944iae.30
	for <multiple recipients>; Mon, 30 Jan 2012 08:07:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=a8+w8u3X3eDm9PbeRFjwf+8qU1elBnhqSJCilIwoRao=;
	b=fo1IQ0XQ8Vwo6zvp1pPiU6K1VIpSbw5cb8m3ikQEAm5sSFpJLd3m4BuhfYWx6t7C4k
	wasE45C2Y6alGFZIKagWBOgMX41eyEGGIX6LeV53B7AkQeBWxecgBeY1r0x9oWjj3tUb
	xCtQXE2FfuUDuHc6UOxsQq8Kuq+A7O4UAEqHo=
MIME-Version: 1.0
Received: by 10.42.145.132 with SMTP id f4mr14543icv.42.1327939638766; Mon, 30
	Jan 2012 08:07:18 -0800 (PST)
Received: by 10.231.8.37 with HTTP; Mon, 30 Jan 2012 08:07:18 -0800 (PST)
In-Reply-To: <4F2666DC.7080601@xen.org>
References: <4F1473A2.4060103@xen.org>
	<CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
	<4F2666DC.7080601@xen.org>
Date: Mon, 30 Jan 2012 17:07:18 +0100
Message-ID: <CAFivhP=cr10B2p=d2is3wO3KtaFG1xD9WSPonM048J8aRB91oA@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Lars Kurth <lars.kurth@xen.org>
Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	xen-arm@lists.xensource.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users]  Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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 all,

2012/1/30 Lars Kurth <lars.kurth@xen.org>:
> On 30/01/2012 08:56, Roger Pau Monn=E9 wrote:

>>> I have been asked when we should hold the next Xen Document Day. Rather
>>> than
>>> going through this every single month, I am proposing dates until March.
>>> I.e.
>>> - January 30, 2012
>>
>> Is this still on?
>>
> I didn't get any feedback. Going forward, I think we should always hold

:((

> these on the last Monday of the month, starting from Feb.

Would it be possible to insert (i.e. quarterly) an extra doc day that
is on a bank holiday or weekend for us with dayjobs?
Of course it won't be fun if it's just me, but there got to be some
more people interested!!!

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:07:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:07:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtlL-0006Ui-Kh; Mon, 30 Jan 2012 16:07:23 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <florian.heigl@gmail.com>)
	id 1RrtlJ-0006UQ-TX; Mon, 30 Jan 2012 16:07:22 +0000
X-Env-Sender: florian.heigl@gmail.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327939595!62300387!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1313 invoked from network); 30 Jan 2012 16:06:36 -0000
Received: from mail-iy0-f171.google.com (HELO mail-iy0-f171.google.com)
	(209.85.210.171)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:06:36 -0000
Received: by iaeh11 with SMTP id h11so38440944iae.30
	for <multiple recipients>; Mon, 30 Jan 2012 08:07:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=a8+w8u3X3eDm9PbeRFjwf+8qU1elBnhqSJCilIwoRao=;
	b=fo1IQ0XQ8Vwo6zvp1pPiU6K1VIpSbw5cb8m3ikQEAm5sSFpJLd3m4BuhfYWx6t7C4k
	wasE45C2Y6alGFZIKagWBOgMX41eyEGGIX6LeV53B7AkQeBWxecgBeY1r0x9oWjj3tUb
	xCtQXE2FfuUDuHc6UOxsQq8Kuq+A7O4UAEqHo=
MIME-Version: 1.0
Received: by 10.42.145.132 with SMTP id f4mr14543icv.42.1327939638766; Mon, 30
	Jan 2012 08:07:18 -0800 (PST)
Received: by 10.231.8.37 with HTTP; Mon, 30 Jan 2012 08:07:18 -0800 (PST)
In-Reply-To: <4F2666DC.7080601@xen.org>
References: <4F1473A2.4060103@xen.org>
	<CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
	<4F2666DC.7080601@xen.org>
Date: Mon, 30 Jan 2012 17:07:18 +0100
Message-ID: <CAFivhP=cr10B2p=d2is3wO3KtaFG1xD9WSPonM048J8aRB91oA@mail.gmail.com>
From: Florian Heigl <florian.heigl@gmail.com>
To: Lars Kurth <lars.kurth@xen.org>
Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	xen-arm@lists.xensource.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users]  Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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 all,

2012/1/30 Lars Kurth <lars.kurth@xen.org>:
> On 30/01/2012 08:56, Roger Pau Monn=E9 wrote:

>>> I have been asked when we should hold the next Xen Document Day. Rather
>>> than
>>> going through this every single month, I am proposing dates until March.
>>> I.e.
>>> - January 30, 2012
>>
>> Is this still on?
>>
> I didn't get any feedback. Going forward, I think we should always hold

:((

> these on the last Monday of the month, starting from Feb.

Would it be possible to insert (i.e. quarterly) an extra doc day that
is on a bank holiday or weekend for us with dayjobs?
Of course it won't be fun if it's just me, but there got to be some
more people interested!!!

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:18:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1Rrtvv-00075Z-Nh; Mon, 30 Jan 2012 16:18: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 1Rrtvv-00075F-0Y
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:18:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327940292!12996658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25913 invoked from network); 30 Jan 2012 16:18:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10370897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:18: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, 30 Jan 2012 16:18:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 30 Jan 2012 16:18:11 +0000
In-Reply-To: <20120126162621.GE80228@ocelot.phlegethon.org>
References: <20120126162621.GE80228@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327940292.26983.256.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] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 16:26 +0000, Tim Deegan wrote:
> Hi,
> 
> We seem to have agreement that we can start checking in the Xen 
> ARMv7-with-Virtualization-Extensions patches that Stefano has been
> posting. 
> 
> It's been suggested that Ian Campbell be made a committer for 
> the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
> http://www.xen.org/projects/governance.html, I hereby nominate him.
> 
> Keir, Ian, Jan, please respond with your integer of choice.

Thanks everyone!

I'm a bit snowed under this week (preparing for FOSDEM etc) but my
intention is to start applying the patches which Stefano has sent out
next week.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:18:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1Rrtvv-00075Z-Nh; Mon, 30 Jan 2012 16:18: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 1Rrtvv-00075F-0Y
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:18:19 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-5.tower-182.messagelabs.com!1327940292!12996658!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25913 invoked from network); 30 Jan 2012 16:18:13 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-5.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:18:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10370897"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:18: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, 30 Jan 2012 16:18:12 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Tim Deegan <tim@xen.org>
Date: Mon, 30 Jan 2012 16:18:11 +0000
In-Reply-To: <20120126162621.GE80228@ocelot.phlegethon.org>
References: <20120126162621.GE80228@ocelot.phlegethon.org>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327940292.26983.256.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] Proposed new committer for ARMv7+VE
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Thu, 2012-01-26 at 16:26 +0000, Tim Deegan wrote:
> Hi,
> 
> We seem to have agreement that we can start checking in the Xen 
> ARMv7-with-Virtualization-Extensions patches that Stefano has been
> posting. 
> 
> It's been suggested that Ian Campbell be made a committer for 
> the ARMv7+VE stuff (arch/arm &c).  Following the procedure at
> http://www.xen.org/projects/governance.html, I hereby nominate him.
> 
> Keir, Ian, Jan, please respond with your integer of choice.

Thanks everyone!

I'm a bit snowed under this week (preparing for FOSDEM etc) but my
intention is to start applying the patches which Stefano has sent out
next week.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:19:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:19:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtwU-00079n-4b; Mon, 30 Jan 2012 16:18:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RrtwS-00079X-H6
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:18:52 +0000
Received: from [85.158.138.51:60813] by server-6.bemta-3.messagelabs.com id
	7E/63-31032-BE2C62F4; Mon, 30 Jan 2012 16:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327940331!11210382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19129 invoked from network); 30 Jan 2012 16:18:51 -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;
	30 Jan 2012 16:18:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10370914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:18: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, 30 Jan 2012 16:18:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: hxkhust <hxkhust@126.com>
Date: Mon, 30 Jan 2012 16:18:49 +0000
In-Reply-To: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
References: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327940330.26983.257.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 08:11 +0000, hxkhust wrote:
> Hi,
>  
> Recently I'm dong some reserch on xen and encounter a problem that I
> cannot solve temporarily.I need your help very much and the following
> is the question I would like to ask:
> On a physical machine with xen virtualization platform installed ,VM
> A,VM B are VM C's virtual disks are all image files,among which VM A
> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
> format. And VM A and VM B's virtual disk image files are based on VM
> C's virtual disk image file.Now these three VMs are running on the
> same physical machine with xen installed.

This is an invalid/dangerous configuration. You can't really safely
write to the backing file (C's raw disk) while there are active users (A
and B's qcow2 images) of it. Imagine e.g. that all three change the same
bit of filesystem metadata in different ways...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:19:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:19:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrtwU-00079n-4b; Mon, 30 Jan 2012 16:18:54 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RrtwS-00079X-H6
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:18:52 +0000
Received: from [85.158.138.51:60813] by server-6.bemta-3.messagelabs.com id
	7E/63-31032-BE2C62F4; Mon, 30 Jan 2012 16:18:51 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1327940331!11210382!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19129 invoked from network); 30 Jan 2012 16:18:51 -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;
	30 Jan 2012 16:18:51 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10370914"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:18: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, 30 Jan 2012 16:18:50 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: hxkhust <hxkhust@126.com>
Date: Mon, 30 Jan 2012 16:18:49 +0000
In-Reply-To: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
References: <298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1327940330.26983.257.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 08:11 +0000, hxkhust wrote:
> Hi,
>  
> Recently I'm dong some reserch on xen and encounter a problem that I
> cannot solve temporarily.I need your help very much and the following
> is the question I would like to ask:
> On a physical machine with xen virtualization platform installed ,VM
> A,VM B are VM C's virtual disks are all image files,among which VM A
> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
> format. And VM A and VM B's virtual disk image files are based on VM
> C's virtual disk image file.Now these three VMs are running on the
> same physical machine with xen installed.

This is an invalid/dangerous configuration. You can't really safely
write to the backing file (C's raw disk) while there are active users (A
and B's qcow2 images) of it. Imagine e.g. that all three change the same
bit of filesystem metadata in different ways...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:19:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrtwl-0007C3-H6; Mon, 30 Jan 2012 16:19:11 +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 1Rrtwj-0007Ai-Ox
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:19:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327940285!58993212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20374 invoked from network); 30 Jan 2012 16:18:05 -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;
	30 Jan 2012 16:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10370920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:19: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; Mon, 30 Jan 2012 16:19:05 +0000
Date: Mon, 30 Jan 2012 16:20:37 +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.1201271837130.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v3 0/2] use pirq_eoi_map in modern Linux kernels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series consists of two patches: a patch for Xen and a
patch for Linux.


The Xen patch implements PHYSDEVOP_pirq_eoi_gmfn_v2, a new version of
PHYSDEVOP_pirq_eoi_gmfn that does not change the semantics of
PHYSDEVOP_eoi.

The Linux patch introduces pirq_eoi_map in drivers/xen/events.c, using
PHYSDEVOP_pirq_eoi_gmfn_v2.


This version of the patch series addresses Konrad's comment to the Linux
patch and fixes a typo in the Xen patch.


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:19:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:19:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrtwl-0007C3-H6; Mon, 30 Jan 2012 16:19:11 +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 1Rrtwj-0007Ai-Ox
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:19:09 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1327940285!58993212!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20374 invoked from network); 30 Jan 2012 16:18:05 -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;
	30 Jan 2012 16:18:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10370920"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:19: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; Mon, 30 Jan 2012 16:19:05 +0000
Date: Mon, 30 Jan 2012 16:20:37 +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.1201271837130.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"Keir \(Xen.org\)" <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH v3 0/2] use pirq_eoi_map in modern Linux kernels
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series consists of two patches: a patch for Xen and a
patch for Linux.


The Xen patch implements PHYSDEVOP_pirq_eoi_gmfn_v2, a new version of
PHYSDEVOP_pirq_eoi_gmfn that does not change the semantics of
PHYSDEVOP_eoi.

The Linux patch introduces pirq_eoi_map in drivers/xen/events.c, using
PHYSDEVOP_pirq_eoi_gmfn_v2.


This version of the patch series addresses Konrad's comment to the Linux
patch and fixes a typo in the Xen patch.


Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:20:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 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 1Rrtxu-0007N9-0k; Mon, 30 Jan 2012 16:20: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 1Rrtxs-0007M7-7W
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:20:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327940411!10810974!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8710 invoked from network); 30 Jan 2012 16:20: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;
	30 Jan 2012 16:20:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179631228"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:20:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:20: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 q0UGK23W029270;
	Mon, 30 Jan 2012 08:20:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 30 Jan 2012 16:21:47 +0000
Message-ID: <1327940508-22734-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.1201271837130.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271837130.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org,
	JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v3 1/2] Introduce PHYSDEVOP_pirq_eoi_gmfn_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

PHYSDEVOP_pirq_eoi_gmfn subtly changes the semantics of PHYSDEVOP_eoi.
In order to improve the interface this patch:

- renames PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1;

- introduces PHYSDEVOP_pirq_eoi_gmfn_v2, that is like
  PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't modify the behaviour of
  another hypercall;

- bump __XEN_LATEST_INTERFACE_VERSION__;

- #define PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1 or
  PHYSDEVOP_pirq_eoi_gmfn_v2 depending on the __XEN_INTERFACE_VERSION.


Changes in v3:

- fix a typo (__XEN_INTERFACE_VERSION instead of
__XEN_INTERFACE_VERSION__).


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/xen/domain.c      |    1 +
 xen/arch/ia64/xen/hypercall.c   |    7 +++++--
 xen/arch/x86/domain.c           |    1 +
 xen/arch/x86/physdev.c          |    7 +++++--
 xen/include/asm-ia64/domain.h   |    3 +++
 xen/include/asm-x86/domain.h    |    3 +++
 xen/include/public/physdev.h    |   16 +++++++++++++++-
 xen/include/public/xen-compat.h |    2 +-
 8 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
index 1ea5a90..a31bd32 100644
--- a/xen/arch/ia64/xen/domain.c
+++ b/xen/arch/ia64/xen/domain.c
@@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
 		if (d->arch.pirq_eoi_map != NULL) {
 			put_page(virt_to_page(d->arch.pirq_eoi_map));
 			d->arch.pirq_eoi_map = NULL;
+			d->arch.auto_unmask = 0;
 		}
 
 		/* Tear down shadow mode stuff. */
diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
index 130675e..18930bf 100644
--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
 {
 	if ( pirq < 0 || pirq >= NR_IRQS )
 		return -EINVAL;
-	if ( d->arch.pirq_eoi_map ) {
+	if ( d->arch.auto_unmask ) {
 		spin_lock(&d->event_lock);
 		evtchn_unmask(pirq_to_evtchn(d, pirq));
 		spin_unlock(&d->event_lock);
@@ -508,7 +508,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
-    case PHYSDEVOP_pirq_eoi_gmfn: {
+    case PHYSDEVOP_pirq_eoi_gmfn_v1:
+    case PHYSDEVOP_pirq_eoi_gmfn_v2: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
 
@@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         }
 
         current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
+            current->domain->arch.auto_unmask = 1;
         ret = 0;
         break;
     }
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 61d83c8..a540af7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
                 put_page_and_type(
                     mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
                 d->arch.pv_domain.pirq_eoi_map = NULL;
+                d->arch.pv_domain.auto_unmask = 0;
             }
         }
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index f280c28..df92cc7 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -271,7 +271,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             break;
         }
         if ( !is_hvm_domain(v->domain) &&
-             v->domain->arch.pv_domain.pirq_eoi_map )
+             v->domain->arch.pv_domain.auto_unmask )
             evtchn_unmask(pirq->evtchn);
         if ( !is_hvm_domain(v->domain) ||
              domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
@@ -293,7 +293,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
-    case PHYSDEVOP_pirq_eoi_gmfn: {
+    case PHYSDEVOP_pirq_eoi_gmfn_v2:
+    case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
 
@@ -329,6 +330,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             ret = -ENOSPC;
             break;
         }
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
+            v->domain->arch.pv_domain.auto_unmask = 1;
 
         put_gfn(current->domain, info.gmfn);
         ret = 0;
diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
index 12dc3bd..31d7d32 100644
--- a/xen/include/asm-ia64/domain.h
+++ b/xen/include/asm-ia64/domain.h
@@ -186,6 +186,9 @@ struct arch_domain {
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    bool_t auto_unmask;
 
     /* Address of efi_runtime_services_t (placed in domain memory)  */
     void *efi_runtime;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 00bbaeb..fb2cfd2 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -231,6 +231,9 @@ struct pv_domain
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    bool_t auto_unmask;
 
     /* Pseudophysical e820 map (XENMEM_memory_map).  */
     spinlock_t e820_lock;
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index 6e23295..b78eeba 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -49,7 +49,15 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
  * will automatically get unmasked. The page registered is used as a bit
  * array indexed by Xen's PIRQ value.
  */
-#define PHYSDEVOP_pirq_eoi_gmfn         17
+#define PHYSDEVOP_pirq_eoi_gmfn_v1       17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v2       28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
     xen_pfn_t gmfn;
@@ -325,6 +333,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
 #define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi
 #define PHYSDEVOP_IRQ_SHARED             XENIRQSTAT_shared
 
+#if __XEN_INTERFACE_VERSION__ < 0x00040200
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
+#else
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
+#endif
+
 #endif /* __XEN_PUBLIC_PHYSDEV_H__ */
 
 /*
diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 2e38003..d8c55bf 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x0003020a
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.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 Jan 30 16:20:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 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 1Rrtxu-0007N9-0k; Mon, 30 Jan 2012 16:20: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 1Rrtxs-0007M7-7W
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:20:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327940411!10810974!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8710 invoked from network); 30 Jan 2012 16:20: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;
	30 Jan 2012 16:20:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179631228"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:20:11 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:20: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 q0UGK23W029270;
	Mon, 30 Jan 2012 08:20:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 30 Jan 2012 16:21:47 +0000
Message-ID: <1327940508-22734-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.1201271837130.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271837130.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org,
	JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v3 1/2] Introduce PHYSDEVOP_pirq_eoi_gmfn_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

PHYSDEVOP_pirq_eoi_gmfn subtly changes the semantics of PHYSDEVOP_eoi.
In order to improve the interface this patch:

- renames PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1;

- introduces PHYSDEVOP_pirq_eoi_gmfn_v2, that is like
  PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't modify the behaviour of
  another hypercall;

- bump __XEN_LATEST_INTERFACE_VERSION__;

- #define PHYSDEVOP_pirq_eoi_gmfn to PHYSDEVOP_pirq_eoi_gmfn_v1 or
  PHYSDEVOP_pirq_eoi_gmfn_v2 depending on the __XEN_INTERFACE_VERSION.


Changes in v3:

- fix a typo (__XEN_INTERFACE_VERSION instead of
__XEN_INTERFACE_VERSION__).


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen/arch/ia64/xen/domain.c      |    1 +
 xen/arch/ia64/xen/hypercall.c   |    7 +++++--
 xen/arch/x86/domain.c           |    1 +
 xen/arch/x86/physdev.c          |    7 +++++--
 xen/include/asm-ia64/domain.h   |    3 +++
 xen/include/asm-x86/domain.h    |    3 +++
 xen/include/public/physdev.h    |   16 +++++++++++++++-
 xen/include/public/xen-compat.h |    2 +-
 8 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/xen/arch/ia64/xen/domain.c b/xen/arch/ia64/xen/domain.c
index 1ea5a90..a31bd32 100644
--- a/xen/arch/ia64/xen/domain.c
+++ b/xen/arch/ia64/xen/domain.c
@@ -1731,6 +1731,7 @@ int domain_relinquish_resources(struct domain *d)
 		if (d->arch.pirq_eoi_map != NULL) {
 			put_page(virt_to_page(d->arch.pirq_eoi_map));
 			d->arch.pirq_eoi_map = NULL;
+			d->arch.auto_unmask = 0;
 		}
 
 		/* Tear down shadow mode stuff. */
diff --git a/xen/arch/ia64/xen/hypercall.c b/xen/arch/ia64/xen/hypercall.c
index 130675e..18930bf 100644
--- a/xen/arch/ia64/xen/hypercall.c
+++ b/xen/arch/ia64/xen/hypercall.c
@@ -65,7 +65,7 @@ static long __do_pirq_guest_eoi(struct domain *d, int pirq)
 {
 	if ( pirq < 0 || pirq >= NR_IRQS )
 		return -EINVAL;
-	if ( d->arch.pirq_eoi_map ) {
+	if ( d->arch.auto_unmask ) {
 		spin_lock(&d->event_lock);
 		evtchn_unmask(pirq_to_evtchn(d, pirq));
 		spin_unlock(&d->event_lock);
@@ -508,7 +508,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
-    case PHYSDEVOP_pirq_eoi_gmfn: {
+    case PHYSDEVOP_pirq_eoi_gmfn_v1:
+    case PHYSDEVOP_pirq_eoi_gmfn_v2: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
 
@@ -531,6 +532,8 @@ long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         }
 
         current->domain->arch.pirq_eoi_map = mfn_to_virt(mfn);
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
+            current->domain->arch.auto_unmask = 1;
         ret = 0;
         break;
     }
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 61d83c8..a540af7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2125,6 +2125,7 @@ int domain_relinquish_resources(struct domain *d)
                 put_page_and_type(
                     mfn_to_page(d->arch.pv_domain.pirq_eoi_map_mfn));
                 d->arch.pv_domain.pirq_eoi_map = NULL;
+                d->arch.pv_domain.auto_unmask = 0;
             }
         }
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index f280c28..df92cc7 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -271,7 +271,7 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             break;
         }
         if ( !is_hvm_domain(v->domain) &&
-             v->domain->arch.pv_domain.pirq_eoi_map )
+             v->domain->arch.pv_domain.auto_unmask )
             evtchn_unmask(pirq->evtchn);
         if ( !is_hvm_domain(v->domain) ||
              domain_pirq_to_irq(v->domain, eoi.irq) > 0 )
@@ -293,7 +293,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
         break;
     }
 
-    case PHYSDEVOP_pirq_eoi_gmfn: {
+    case PHYSDEVOP_pirq_eoi_gmfn_v2:
+    case PHYSDEVOP_pirq_eoi_gmfn_v1: {
         struct physdev_pirq_eoi_gmfn info;
         unsigned long mfn;
 
@@ -329,6 +330,8 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg)
             ret = -ENOSPC;
             break;
         }
+        if ( cmd == PHYSDEVOP_pirq_eoi_gmfn_v1 )
+            v->domain->arch.pv_domain.auto_unmask = 1;
 
         put_gfn(current->domain, info.gmfn);
         ret = 0;
diff --git a/xen/include/asm-ia64/domain.h b/xen/include/asm-ia64/domain.h
index 12dc3bd..31d7d32 100644
--- a/xen/include/asm-ia64/domain.h
+++ b/xen/include/asm-ia64/domain.h
@@ -186,6 +186,9 @@ struct arch_domain {
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    bool_t auto_unmask;
 
     /* Address of efi_runtime_services_t (placed in domain memory)  */
     void *efi_runtime;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 00bbaeb..fb2cfd2 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -231,6 +231,9 @@ struct pv_domain
     /* Shared page for notifying that explicit PIRQ EOI is required. */
     unsigned long *pirq_eoi_map;
     unsigned long pirq_eoi_map_mfn;
+    /* set auto_unmask to 1 if you want PHYSDEVOP_eoi to automatically
+     * unmask the event channel */
+    bool_t auto_unmask;
 
     /* Pseudophysical e820 map (XENMEM_memory_map).  */
     spinlock_t e820_lock;
diff --git a/xen/include/public/physdev.h b/xen/include/public/physdev.h
index 6e23295..b78eeba 100644
--- a/xen/include/public/physdev.h
+++ b/xen/include/public/physdev.h
@@ -49,7 +49,15 @@ DEFINE_XEN_GUEST_HANDLE(physdev_eoi_t);
  * will automatically get unmasked. The page registered is used as a bit
  * array indexed by Xen's PIRQ value.
  */
-#define PHYSDEVOP_pirq_eoi_gmfn         17
+#define PHYSDEVOP_pirq_eoi_gmfn_v1       17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v2       28
 struct physdev_pirq_eoi_gmfn {
     /* IN */
     xen_pfn_t gmfn;
@@ -325,6 +333,12 @@ DEFINE_XEN_GUEST_HANDLE(physdev_pci_device_t);
 #define PHYSDEVOP_IRQ_NEEDS_UNMASK_NOTIFY XENIRQSTAT_needs_eoi
 #define PHYSDEVOP_IRQ_SHARED             XENIRQSTAT_shared
 
+#if __XEN_INTERFACE_VERSION__ < 0x00040200
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v1
+#else
+#define PHYSDEVOP_pirq_eoi_gmfn PHYSDEVOP_pirq_eoi_gmfn_v2
+#endif
+
 #endif /* __XEN_PUBLIC_PHYSDEV_H__ */
 
 /*
diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 2e38003..d8c55bf 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x0003020a
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040200
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.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 Jan 30 16:20:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1Rrty4-0007P0-Em; Mon, 30 Jan 2012 16:20:32 +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 1Rrty3-0007NZ-1u
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:20:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327940411!10810974!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9134 invoked from network); 30 Jan 2012 16:20:18 -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;
	30 Jan 2012 16:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179631240"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:20: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; Mon, 30 Jan 2012 11:20:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UGK23X029270;
	Mon, 30 Jan 2012 08:20:05 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 30 Jan 2012 16:21:48 +0000
Message-ID: <1327940508-22734-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.1201271837130.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271837130.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org,
	JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v3 2/2] linux/xen: support pirq_eoi_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>
Content-Type: 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 pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
be EOI'd without having to issue an hypercall every time.
We use PHYSDEVOP_pirq_eoi_gmfn_v2 to map the bitmap, then if we
succeed we use pirq_eoi_map to check whether pirqs need eoi.


Changes in v3:

- explicitly use PHYSDEVOP_pirq_eoi_gmfn_v2 rather than
PHYSDEVOP_pirq_eoi_gmfn;

- introduce pirq_check_eoi_map, a function to check if a pirq needs an
eoi using the map;

-rename pirq_needs_eoi into pirq_needs_eoi_flag;

- introduce a function pointer called pirq_needs_eoi that is going to be
set to the right implementation depending on the availability of
PHYSDEVOP_pirq_eoi_gmfn_v2.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c            |   26 +++++++++++++++++++++++---
 include/xen/interface/physdev.h |   21 +++++++++++++++++++++
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..cc5fc40 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -37,6 +37,7 @@
 #include <asm/idle.h>
 #include <asm/io_apic.h>
 #include <asm/sync_bitops.h>
+#include <asm/xen/page.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -108,6 +109,8 @@ struct irq_info {
 #define PIRQ_SHAREABLE	(1 << 1)
 
 static int *evtchn_to_irq;
+static unsigned long *pirq_eoi_map;
+static bool (*pirq_needs_eoi)(unsigned irq);
 
 static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
 		      cpu_evtchn_mask);
@@ -268,10 +271,14 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 	return ret;
 }
 
-static bool pirq_needs_eoi(unsigned irq)
+static bool pirq_check_eoi_map(unsigned irq)
 {
-	struct irq_info *info = info_for_irq(irq);
+	return test_bit(irq, pirq_eoi_map);
+}
 
+static bool pirq_needs_eoi_flag(unsigned irq)
+{
+	struct irq_info *info = info_for_irq(irq);
 	BUG_ON(info->type != IRQT_PIRQ);
 
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
@@ -1693,7 +1700,7 @@ void xen_callback_vector(void) {}
 
 void __init xen_init_IRQ(void)
 {
-	int i;
+	int i, rc;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1707,6 +1714,8 @@ void __init xen_init_IRQ(void)
 	for (i = 0; i < NR_EVENT_CHANNELS; i++)
 		mask_evtchn(i);
 
+	pirq_needs_eoi = pirq_needs_eoi_flag;
+
 	if (xen_hvm_domain()) {
 		xen_callback_vector();
 		native_init_IRQ();
@@ -1714,8 +1723,19 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		struct physdev_pirq_eoi_gmfn eoi_gmfn;
+
 		irq_ctx_init(smp_processor_id());
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
+
+		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
+		if (rc != 0) {
+			free_page((unsigned long) pirq_eoi_map);
+			pirq_eoi_map = NULL;
+		} else
+			pirq_needs_eoi = pirq_check_eoi_map;
 	}
 }
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index c1080d9..1775722 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -39,6 +39,27 @@ struct physdev_eoi {
 };
 
 /*
+ * Register a shared page for the hypervisor to indicate whether the guest
+ * must issue PHYSDEVOP_eoi. The semantics of PHYSDEVOP_eoi change slightly
+ * once the guest used this function in that the associated event channel
+ * will automatically get unmasked. The page registered is used as a bit
+ * array indexed by Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v1       17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v2       28
+struct physdev_pirq_eoi_gmfn {
+    /* IN */
+    unsigned long gmfn;
+};
+
+/*
  * Query the status of an IRQ line.
  * @arg == pointer to physdev_irq_status_query structure.
  */
-- 
1.7.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 Jan 30 16:20:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1Rrty4-0007P0-Em; Mon, 30 Jan 2012 16:20:32 +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 1Rrty3-0007NZ-1u
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:20:31 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1327940411!10810974!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9134 invoked from network); 30 Jan 2012 16:20:18 -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;
	30 Jan 2012 16:20:18 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179631240"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:20: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; Mon, 30 Jan 2012 11:20:17 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0UGK23X029270;
	Mon, 30 Jan 2012 08:20:05 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 30 Jan 2012 16:21:48 +0000
Message-ID: <1327940508-22734-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.1201271837130.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271837130.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>, keir@xen.org,
	JBeulich@suse.com, konrad.wilk@oracle.com
Subject: [Xen-devel] [PATCH v3 2/2] linux/xen: support pirq_eoi_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>
Content-Type: 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 pirq_eoi_map is a bitmap offered by Xen to check which pirqs need to
be EOI'd without having to issue an hypercall every time.
We use PHYSDEVOP_pirq_eoi_gmfn_v2 to map the bitmap, then if we
succeed we use pirq_eoi_map to check whether pirqs need eoi.


Changes in v3:

- explicitly use PHYSDEVOP_pirq_eoi_gmfn_v2 rather than
PHYSDEVOP_pirq_eoi_gmfn;

- introduce pirq_check_eoi_map, a function to check if a pirq needs an
eoi using the map;

-rename pirq_needs_eoi into pirq_needs_eoi_flag;

- introduce a function pointer called pirq_needs_eoi that is going to be
set to the right implementation depending on the availability of
PHYSDEVOP_pirq_eoi_gmfn_v2.


Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/events.c            |   26 +++++++++++++++++++++++---
 include/xen/interface/physdev.h |   21 +++++++++++++++++++++
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 6e075cd..cc5fc40 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -37,6 +37,7 @@
 #include <asm/idle.h>
 #include <asm/io_apic.h>
 #include <asm/sync_bitops.h>
+#include <asm/xen/page.h>
 #include <asm/xen/pci.h>
 #include <asm/xen/hypercall.h>
 #include <asm/xen/hypervisor.h>
@@ -108,6 +109,8 @@ struct irq_info {
 #define PIRQ_SHAREABLE	(1 << 1)
 
 static int *evtchn_to_irq;
+static unsigned long *pirq_eoi_map;
+static bool (*pirq_needs_eoi)(unsigned irq);
 
 static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
 		      cpu_evtchn_mask);
@@ -268,10 +271,14 @@ static unsigned int cpu_from_evtchn(unsigned int evtchn)
 	return ret;
 }
 
-static bool pirq_needs_eoi(unsigned irq)
+static bool pirq_check_eoi_map(unsigned irq)
 {
-	struct irq_info *info = info_for_irq(irq);
+	return test_bit(irq, pirq_eoi_map);
+}
 
+static bool pirq_needs_eoi_flag(unsigned irq)
+{
+	struct irq_info *info = info_for_irq(irq);
 	BUG_ON(info->type != IRQT_PIRQ);
 
 	return info->u.pirq.flags & PIRQ_NEEDS_EOI;
@@ -1693,7 +1700,7 @@ void xen_callback_vector(void) {}
 
 void __init xen_init_IRQ(void)
 {
-	int i;
+	int i, rc;
 
 	evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_irq),
 				    GFP_KERNEL);
@@ -1707,6 +1714,8 @@ void __init xen_init_IRQ(void)
 	for (i = 0; i < NR_EVENT_CHANNELS; i++)
 		mask_evtchn(i);
 
+	pirq_needs_eoi = pirq_needs_eoi_flag;
+
 	if (xen_hvm_domain()) {
 		xen_callback_vector();
 		native_init_IRQ();
@@ -1714,8 +1723,19 @@ void __init xen_init_IRQ(void)
 		 * __acpi_register_gsi can point at the right function */
 		pci_xen_hvm_init();
 	} else {
+		struct physdev_pirq_eoi_gmfn eoi_gmfn;
+
 		irq_ctx_init(smp_processor_id());
 		if (xen_initial_domain())
 			pci_xen_initial_domain();
+
+		pirq_eoi_map = (void *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
+		eoi_gmfn.gmfn = virt_to_mfn(pirq_eoi_map);
+		rc = HYPERVISOR_physdev_op(PHYSDEVOP_pirq_eoi_gmfn_v2, &eoi_gmfn);
+		if (rc != 0) {
+			free_page((unsigned long) pirq_eoi_map);
+			pirq_eoi_map = NULL;
+		} else
+			pirq_needs_eoi = pirq_check_eoi_map;
 	}
 }
diff --git a/include/xen/interface/physdev.h b/include/xen/interface/physdev.h
index c1080d9..1775722 100644
--- a/include/xen/interface/physdev.h
+++ b/include/xen/interface/physdev.h
@@ -39,6 +39,27 @@ struct physdev_eoi {
 };
 
 /*
+ * Register a shared page for the hypervisor to indicate whether the guest
+ * must issue PHYSDEVOP_eoi. The semantics of PHYSDEVOP_eoi change slightly
+ * once the guest used this function in that the associated event channel
+ * will automatically get unmasked. The page registered is used as a bit
+ * array indexed by Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v1       17
+/*
+ * Register a shared page for the hypervisor to indicate whether the
+ * guest must issue PHYSDEVOP_eoi. This hypercall is very similar to
+ * PHYSDEVOP_pirq_eoi_gmfn_v1 but it doesn't change the semantics of
+ * PHYSDEVOP_eoi. The page registered is used as a bit array indexed by
+ * Xen's PIRQ value.
+ */
+#define PHYSDEVOP_pirq_eoi_gmfn_v2       28
+struct physdev_pirq_eoi_gmfn {
+    /* IN */
+    unsigned long gmfn;
+};
+
+/*
  * Query the status of an IRQ line.
  * @arg == pointer to physdev_irq_status_query structure.
  */
-- 
1.7.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 Jan 30 16:26:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1Rru3S-00081W-Et; Mon, 30 Jan 2012 16:26:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rru3Q-00081R-PL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:26:04 +0000
Received: from [85.158.138.51:47603] by server-12.bemta-3.messagelabs.com id
	7A/78-24557-B94C62F4; Mon, 30 Jan 2012 16:26:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327940762!6127974!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12000 invoked from network); 30 Jan 2012 16:26:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 16:26:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 16:26:02 +0000
Message-Id: <4F26D2A8020000780006FF2F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 16:26:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <4F268C03.5000003@ts.fujitsu.com>
In-Reply-To: <4F268C03.5000003@ts.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 13:24, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> To avoid this stall I tried to start a little daemon on the target machine
> and watch for a new BS2000 domain to show up due to live migration. I wanted
> to map the domain memory as soon as the needed mapping information located 
> in a fixed guest mfn was transferred. Discovery of the new domain works as
> expected, but I'm not capable doing any memory mapping until the restore of
> the domain is finished. The mapping ioctl using IOCTL_PRIVCMD_MMAP returns
> EINVAL until xc_restore is finished (more or less).
> 
> Why can xc_restore do the mapping while I can't? I know xc_restore is using
> IOCTL_PRIVCMD_MMAPBATCH_V2, but I can't see a difference which should matter
> between those two, as both are using the same hypercall to update the dom0
> page tables.

I cannot immediately think of a reason (and indeed the difference
between the two is only how errors get handled), so I wonder
whether you checked where the - pretty generic - -EINVAL is
coming from. You also didn't mention whether any hypervisor log
entries are associated with you failed attempts.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:26:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1Rru3S-00081W-Et; Mon, 30 Jan 2012 16:26:06 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1Rru3Q-00081R-PL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:26:04 +0000
Received: from [85.158.138.51:47603] by server-12.bemta-3.messagelabs.com id
	7A/78-24557-B94C62F4; Mon, 30 Jan 2012 16:26:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1327940762!6127974!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12000 invoked from network); 30 Jan 2012 16:26:03 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-13.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 16:26:03 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 16:26:02 +0000
Message-Id: <4F26D2A8020000780006FF2F@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 16:26:00 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Juergen Gross" <juergen.gross@ts.fujitsu.com>
References: <4F268C03.5000003@ts.fujitsu.com>
In-Reply-To: <4F268C03.5000003@ts.fujitsu.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 13:24, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
> To avoid this stall I tried to start a little daemon on the target machine
> and watch for a new BS2000 domain to show up due to live migration. I wanted
> to map the domain memory as soon as the needed mapping information located 
> in a fixed guest mfn was transferred. Discovery of the new domain works as
> expected, but I'm not capable doing any memory mapping until the restore of
> the domain is finished. The mapping ioctl using IOCTL_PRIVCMD_MMAP returns
> EINVAL until xc_restore is finished (more or less).
> 
> Why can xc_restore do the mapping while I can't? I know xc_restore is using
> IOCTL_PRIVCMD_MMAPBATCH_V2, but I can't see a difference which should matter
> between those two, as both are using the same hypercall to update the dom0
> page tables.

I cannot immediately think of a reason (and indeed the difference
between the two is only how errors get handled), so I wonder
whether you checked where the - pretty generic - -EINVAL is
coming from. You also didn't mention whether any hypervisor log
entries are associated with you failed attempts.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:27:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1Rru4y-00086D-UJ; Mon, 30 Jan 2012 16:27:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1Rru4x-00085k-GI
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:27:39 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327940852!5646372!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.5 required=7.0 tests=RCVD_BY_IP,UPPERCASE_50_75
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18175 invoked from network); 30 Jan 2012 16:27:33 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:27:33 -0000
Received: by bkar1 with SMTP id r1so7307436bka.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 08:27:32 -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:cc:content-type;
	bh=KL+WEuUrNBSUbsG1tQ7f4y54lbdaUiBYMm4NHPg+15g=;
	b=EhNi+/KFk51HA5OHMe+2Uzy9vt8u3T2HFhXXr0VQy1wZ/DLlJrb/mYzqJDR2m4x2l1
	caMmuW/06xa+gJU9JwEVBuKxwHxTbM/KxvDkA/ESH66KUNwWcidZ7brzinDV3+VUDWl1
	3fXLRZvvmUSEhOc2wYN2k/dECRxmdR6dmU990=
MIME-Version: 1.0
Received: by 10.205.138.136 with SMTP id is8mr8945681bkc.72.1327940852423;
	Mon, 30 Jan 2012 08:27:32 -0800 (PST)
Received: by 10.205.47.197 with HTTP; Mon, 30 Jan 2012 08:27:32 -0800 (PST)
Date: Mon, 30 Jan 2012 11:27:32 -0500
X-Google-Sender-Auth: InwpQN96qfc4ixEQ93dn5ilhtB8
Message-ID: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek <konrad@darnok.org>
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] debugging 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

Konrad, et al.

I'm having an issue with my guests that, when I am running wireless
drivers in dom0, and the PV-on-HVM guest tries to access the network -
I get a hung dom0.

When I turn on
Kernel Hacking->
Spinlock and rw-lock debugging: basic checks

The hang goes away, but does not print out anything terribly useful in
the serial log.


The config file  changes made by this menuconfig setting can be found below:


While I know from other conversations, that Konrad is aware of my
setup, for other's benefit - this is a 64bit dom0 3.2.2 kernel, with a
few of his branches pulled in.

Any thoughts, or suggestions on how best to debug these deadlocks
would be greatly appreciated.


-Ben Guthro


diff --git a/configs/config.ubuntu.amd64 b/configs/config.ubuntu.amd64
index 205b5c6..f7a233f 100644
--- a/configs/config.ubuntu.amd64
+++ b/configs/config.ubuntu.amd64
@@ -257,27 +257,27 @@ CONFIG_PADATA=y
 # 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 is not set
 # CONFIG_INLINE_SPIN_UNLOCK_BH is not set
-CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
+# 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=y
+# CONFIG_INLINE_READ_UNLOCK is not set
 # CONFIG_INLINE_READ_UNLOCK_BH is not set
-CONFIG_INLINE_READ_UNLOCK_IRQ=y
+# 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=y
+# CONFIG_INLINE_WRITE_UNLOCK is not set
 # CONFIG_INLINE_WRITE_UNLOCK_BH is not set
-CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
+# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
 # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
 CONFIG_MUTEX_SPIN_ON_OWNER=y
 CONFIG_FREEZER=y
@@ -398,7 +398,7 @@ 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=4
+CONFIG_SPLIT_PTLOCK_CPUS=999999
 # CONFIG_COMPACTION is not set
 CONFIG_MIGRATION=y
 CONFIG_PHYS_ADDR_T_64BIT=y
@@ -4255,7 +4255,7 @@ CONFIG_TIMER_STATS=y
 # 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_SPINLOCK=y
 # CONFIG_DEBUG_MUTEXES is not set
 # CONFIG_DEBUG_LOCK_ALLOC is not set
 # CONFIG_PROVE_LOCKING 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 Mon Jan 30 16:27:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1Rru4y-00086D-UJ; Mon, 30 Jan 2012 16:27:40 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1Rru4x-00085k-GI
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:27:39 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327940852!5646372!1
X-Originating-IP: [209.85.214.43]
X-SpamReason: No, hits=0.5 required=7.0 tests=RCVD_BY_IP,UPPERCASE_50_75
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18175 invoked from network); 30 Jan 2012 16:27:33 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:27:33 -0000
Received: by bkar1 with SMTP id r1so7307436bka.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 08:27:32 -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:cc:content-type;
	bh=KL+WEuUrNBSUbsG1tQ7f4y54lbdaUiBYMm4NHPg+15g=;
	b=EhNi+/KFk51HA5OHMe+2Uzy9vt8u3T2HFhXXr0VQy1wZ/DLlJrb/mYzqJDR2m4x2l1
	caMmuW/06xa+gJU9JwEVBuKxwHxTbM/KxvDkA/ESH66KUNwWcidZ7brzinDV3+VUDWl1
	3fXLRZvvmUSEhOc2wYN2k/dECRxmdR6dmU990=
MIME-Version: 1.0
Received: by 10.205.138.136 with SMTP id is8mr8945681bkc.72.1327940852423;
	Mon, 30 Jan 2012 08:27:32 -0800 (PST)
Received: by 10.205.47.197 with HTTP; Mon, 30 Jan 2012 08:27:32 -0800 (PST)
Date: Mon, 30 Jan 2012 11:27:32 -0500
X-Google-Sender-Auth: InwpQN96qfc4ixEQ93dn5ilhtB8
Message-ID: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Konrad Rzeszutek <konrad@darnok.org>
Cc: Xen Devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] debugging 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

Konrad, et al.

I'm having an issue with my guests that, when I am running wireless
drivers in dom0, and the PV-on-HVM guest tries to access the network -
I get a hung dom0.

When I turn on
Kernel Hacking->
Spinlock and rw-lock debugging: basic checks

The hang goes away, but does not print out anything terribly useful in
the serial log.


The config file  changes made by this menuconfig setting can be found below:


While I know from other conversations, that Konrad is aware of my
setup, for other's benefit - this is a 64bit dom0 3.2.2 kernel, with a
few of his branches pulled in.

Any thoughts, or suggestions on how best to debug these deadlocks
would be greatly appreciated.


-Ben Guthro


diff --git a/configs/config.ubuntu.amd64 b/configs/config.ubuntu.amd64
index 205b5c6..f7a233f 100644
--- a/configs/config.ubuntu.amd64
+++ b/configs/config.ubuntu.amd64
@@ -257,27 +257,27 @@ CONFIG_PADATA=y
 # 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 is not set
 # CONFIG_INLINE_SPIN_UNLOCK_BH is not set
-CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
+# 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=y
+# CONFIG_INLINE_READ_UNLOCK is not set
 # CONFIG_INLINE_READ_UNLOCK_BH is not set
-CONFIG_INLINE_READ_UNLOCK_IRQ=y
+# 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=y
+# CONFIG_INLINE_WRITE_UNLOCK is not set
 # CONFIG_INLINE_WRITE_UNLOCK_BH is not set
-CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
+# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
 # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
 CONFIG_MUTEX_SPIN_ON_OWNER=y
 CONFIG_FREEZER=y
@@ -398,7 +398,7 @@ 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=4
+CONFIG_SPLIT_PTLOCK_CPUS=999999
 # CONFIG_COMPACTION is not set
 CONFIG_MIGRATION=y
 CONFIG_PHYS_ADDR_T_64BIT=y
@@ -4255,7 +4255,7 @@ CONFIG_TIMER_STATS=y
 # 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_SPINLOCK=y
 # CONFIG_DEBUG_MUTEXES is not set
 # CONFIG_DEBUG_LOCK_ALLOC is not set
 # CONFIG_PROVE_LOCKING 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 Mon Jan 30 16:34:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RruBc-0008O3-S1; Mon, 30 Jan 2012 16:34:32 +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 1RruBb-0008Ny-Tf
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:34:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327941263!3724185!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1794 invoked from network); 30 Jan 2012 16:34:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:34:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179634030"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:34:22 -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, 30 Jan 2012
	11:34:22 -0500
Message-ID: <4F26C68C.7020600@citrix.com>
Date: Mon, 30 Jan 2012 16:34:20 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ben Guthro <ben@guthro.net>
References: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
In-Reply-To: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
X-Enigmail-Version: 1.1.2
Cc: Konrad Rzeszutek <konrad@darnok.org>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] debugging 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 30/01/12 16:27, Ben Guthro wrote:
> Konrad, et al.
>
> I'm having an issue with my guests that, when I am running wireless
> drivers in dom0, and the PV-on-HVM guest tries to access the network -
> I get a hung dom0.
>
> When I turn on
> Kernel Hacking->
> Spinlock and rw-lock debugging: basic checks
>
> The hang goes away, but does not print out anything terribly useful in
> the serial log.
>
>
> The config file  changes made by this menuconfig setting can be found below:
>
>
> While I know from other conversations, that Konrad is aware of my
> setup, for other's benefit - this is a 64bit dom0 3.2.2 kernel, with a
> few of his branches pulled in.
>
> Any thoughts, or suggestions on how best to debug these deadlocks
> would be greatly appreciated.

It looks like
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01917.html might
apply to you.

Does that patch help?

~Andrew

>
> -Ben Guthro
>
>
> diff --git a/configs/config.ubuntu.amd64 b/configs/config.ubuntu.amd64
> index 205b5c6..f7a233f 100644
> --- a/configs/config.ubuntu.amd64
> +++ b/configs/config.ubuntu.amd64
> @@ -257,27 +257,27 @@ CONFIG_PADATA=y
>  # 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 is not set
>  # CONFIG_INLINE_SPIN_UNLOCK_BH is not set
> -CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
> +# 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=y
> +# CONFIG_INLINE_READ_UNLOCK is not set
>  # CONFIG_INLINE_READ_UNLOCK_BH is not set
> -CONFIG_INLINE_READ_UNLOCK_IRQ=y
> +# 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=y
> +# CONFIG_INLINE_WRITE_UNLOCK is not set
>  # CONFIG_INLINE_WRITE_UNLOCK_BH is not set
> -CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
> +# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
>  # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
>  CONFIG_MUTEX_SPIN_ON_OWNER=y
>  CONFIG_FREEZER=y
> @@ -398,7 +398,7 @@ 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=4
> +CONFIG_SPLIT_PTLOCK_CPUS=999999
>  # CONFIG_COMPACTION is not set
>  CONFIG_MIGRATION=y
>  CONFIG_PHYS_ADDR_T_64BIT=y
> @@ -4255,7 +4255,7 @@ CONFIG_TIMER_STATS=y
>  # 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_SPINLOCK=y
>  # CONFIG_DEBUG_MUTEXES is not set
>  # CONFIG_DEBUG_LOCK_ALLOC is not set
>  # CONFIG_PROVE_LOCKING is not set
>
> _______________________________________________
> 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 Mon Jan 30 16:34:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RruBc-0008O3-S1; Mon, 30 Jan 2012 16:34:32 +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 1RruBb-0008Ny-Tf
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:34:32 +0000
X-Env-Sender: Andrew.Cooper3@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327941263!3724185!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjcyMDE=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1794 invoked from network); 30 Jan 2012 16:34:24 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 16:34:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="179634030"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:34:22 -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, 30 Jan 2012
	11:34:22 -0500
Message-ID: <4F26C68C.7020600@citrix.com>
Date: Mon, 30 Jan 2012 16:34:20 +0000
From: Andrew Cooper <andrew.cooper3@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16
MIME-Version: 1.0
To: Ben Guthro <ben@guthro.net>
References: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
In-Reply-To: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
X-Enigmail-Version: 1.1.2
Cc: Konrad Rzeszutek <konrad@darnok.org>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] debugging 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 30/01/12 16:27, Ben Guthro wrote:
> Konrad, et al.
>
> I'm having an issue with my guests that, when I am running wireless
> drivers in dom0, and the PV-on-HVM guest tries to access the network -
> I get a hung dom0.
>
> When I turn on
> Kernel Hacking->
> Spinlock and rw-lock debugging: basic checks
>
> The hang goes away, but does not print out anything terribly useful in
> the serial log.
>
>
> The config file  changes made by this menuconfig setting can be found below:
>
>
> While I know from other conversations, that Konrad is aware of my
> setup, for other's benefit - this is a 64bit dom0 3.2.2 kernel, with a
> few of his branches pulled in.
>
> Any thoughts, or suggestions on how best to debug these deadlocks
> would be greatly appreciated.

It looks like
http://lists.xen.org/archives/html/xen-devel/2012-01/msg01917.html might
apply to you.

Does that patch help?

~Andrew

>
> -Ben Guthro
>
>
> diff --git a/configs/config.ubuntu.amd64 b/configs/config.ubuntu.amd64
> index 205b5c6..f7a233f 100644
> --- a/configs/config.ubuntu.amd64
> +++ b/configs/config.ubuntu.amd64
> @@ -257,27 +257,27 @@ CONFIG_PADATA=y
>  # 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 is not set
>  # CONFIG_INLINE_SPIN_UNLOCK_BH is not set
> -CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
> +# 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=y
> +# CONFIG_INLINE_READ_UNLOCK is not set
>  # CONFIG_INLINE_READ_UNLOCK_BH is not set
> -CONFIG_INLINE_READ_UNLOCK_IRQ=y
> +# 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=y
> +# CONFIG_INLINE_WRITE_UNLOCK is not set
>  # CONFIG_INLINE_WRITE_UNLOCK_BH is not set
> -CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
> +# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
>  # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
>  CONFIG_MUTEX_SPIN_ON_OWNER=y
>  CONFIG_FREEZER=y
> @@ -398,7 +398,7 @@ 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=4
> +CONFIG_SPLIT_PTLOCK_CPUS=999999
>  # CONFIG_COMPACTION is not set
>  CONFIG_MIGRATION=y
>  CONFIG_PHYS_ADDR_T_64BIT=y
> @@ -4255,7 +4255,7 @@ CONFIG_TIMER_STATS=y
>  # 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_SPINLOCK=y
>  # CONFIG_DEBUG_MUTEXES is not set
>  # CONFIG_DEBUG_LOCK_ALLOC is not set
>  # CONFIG_PROVE_LOCKING is not set
>
> _______________________________________________
> 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 Mon Jan 30 16:35:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:35:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RruCk-0008RK-B1; Mon, 30 Jan 2012 16:35:42 +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 1RruCj-0008RA-3d
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:35:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327941294!58030116!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19021 invoked from network); 30 Jan 2012 16:34:54 -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; 30 Jan 2012 16:34:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 16:35:36 +0000
Message-Id: <4F26D4E5020000780006FF41@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 16:35:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> -int xenvif_map_frontend_rings(struct xenvif *vif,
> -			      grant_ref_t tx_ring_ref,
> -			      grant_ref_t rx_ring_ref)
> +int xenvif_map_frontend_rings(struct xen_comms *comms,
> +			      int domid,
> +			      unsigned long ring_ref[],
> +			      unsigned int  ring_ref_count)
>  {
> -	void *addr;
> -	struct xen_netif_tx_sring *txs;
> -	struct xen_netif_rx_sring *rxs;
> -
> -	int err = -ENOMEM;
> +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> +	unsigned int i;
> +	int err = 0;
>  
> -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> -				     tx_ring_ref, &addr);

Any reason why you don't just extend this function (in a prerequisite
patch) rather than open coding a common utility function (twice) here,
so that other backends (blkback!) can benefit later as well.

Jan

> -	if (err)
> -		goto err;
> +	comms->ring_area = alloc_vm_area(PAGE_SIZE * ring_ref_count, NULL);
> +	if (comms->ring_area == NULL)
> +		return -ENOMEM;
>  
> -	txs = (struct xen_netif_tx_sring *)addr;
> -	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
> +	for (i = 0; i < ring_ref_count; i++) {
> +		unsigned long addr = (unsigned long)comms->ring_area->addr +
> +			(i * PAGE_SIZE);
> +		gnttab_set_map_op(&op[i], addr, GNTMAP_host_map,
> +				  ring_ref[i], domid);
> +	}
>  
> -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> -				     rx_ring_ref, &addr);
> -	if (err)
> -		goto err;
> +	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> +				      &op, ring_ref_count))
> +		BUG();
>  
> -	rxs = (struct xen_netif_rx_sring *)addr;
> -	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE);
> +	comms->nr_handles = ring_ref_count;
>  
> -	vif->rx_req_cons_peek = 0;
> +	for (i = 0; i < ring_ref_count; i++) {
> +		if (op[i].status != 0) {
> +			err = op[i].status;
> +			comms->shmem_handle[i] = INVALID_GRANT_HANDLE;
> +			continue;
> +		}
> +		comms->shmem_handle[i] = op[i].handle;
> +	}
>  
> -	return 0;
> +	if (err != 0)
> +		xenvif_unmap_frontend_rings(comms);
>  
> -err:
> -	xenvif_unmap_frontend_rings(vif);
>  	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 Jan 30 16:35:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:35:55 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RruCk-0008RK-B1; Mon, 30 Jan 2012 16:35:42 +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 1RruCj-0008RA-3d
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:35:41 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1327941294!58030116!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19021 invoked from network); 30 Jan 2012 16:34:54 -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; 30 Jan 2012 16:34:54 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 16:35:36 +0000
Message-Id: <4F26D4E5020000780006FF41@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 16:35:33 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
In-Reply-To: <1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> -int xenvif_map_frontend_rings(struct xenvif *vif,
> -			      grant_ref_t tx_ring_ref,
> -			      grant_ref_t rx_ring_ref)
> +int xenvif_map_frontend_rings(struct xen_comms *comms,
> +			      int domid,
> +			      unsigned long ring_ref[],
> +			      unsigned int  ring_ref_count)
>  {
> -	void *addr;
> -	struct xen_netif_tx_sring *txs;
> -	struct xen_netif_rx_sring *rxs;
> -
> -	int err = -ENOMEM;
> +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> +	unsigned int i;
> +	int err = 0;
>  
> -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> -				     tx_ring_ref, &addr);

Any reason why you don't just extend this function (in a prerequisite
patch) rather than open coding a common utility function (twice) here,
so that other backends (blkback!) can benefit later as well.

Jan

> -	if (err)
> -		goto err;
> +	comms->ring_area = alloc_vm_area(PAGE_SIZE * ring_ref_count, NULL);
> +	if (comms->ring_area == NULL)
> +		return -ENOMEM;
>  
> -	txs = (struct xen_netif_tx_sring *)addr;
> -	BACK_RING_INIT(&vif->tx, txs, PAGE_SIZE);
> +	for (i = 0; i < ring_ref_count; i++) {
> +		unsigned long addr = (unsigned long)comms->ring_area->addr +
> +			(i * PAGE_SIZE);
> +		gnttab_set_map_op(&op[i], addr, GNTMAP_host_map,
> +				  ring_ref[i], domid);
> +	}
>  
> -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> -				     rx_ring_ref, &addr);
> -	if (err)
> -		goto err;
> +	if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref,
> +				      &op, ring_ref_count))
> +		BUG();
>  
> -	rxs = (struct xen_netif_rx_sring *)addr;
> -	BACK_RING_INIT(&vif->rx, rxs, PAGE_SIZE);
> +	comms->nr_handles = ring_ref_count;
>  
> -	vif->rx_req_cons_peek = 0;
> +	for (i = 0; i < ring_ref_count; i++) {
> +		if (op[i].status != 0) {
> +			err = op[i].status;
> +			comms->shmem_handle[i] = INVALID_GRANT_HANDLE;
> +			continue;
> +		}
> +		comms->shmem_handle[i] = op[i].handle;
> +	}
>  
> -	return 0;
> +	if (err != 0)
> +		xenvif_unmap_frontend_rings(comms);
>  
> -err:
> -	xenvif_unmap_frontend_rings(vif);
>  	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 Jan 30 16:40:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RruHH-0000GN-1Z; Mon, 30 Jan 2012 16:40:23 +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 1RruHF-0000GF-06
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:40:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327941572!62305716!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12265 invoked from network); 30 Jan 2012 16:39:32 -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; 30 Jan 2012 16:39:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 16:40:15 +0000
Message-Id: <4F26D5FD020000780006FF59@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 16:40:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
In-Reply-To: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek <konrad@darnok.org>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] debugging 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 30.01.12 at 17:27, Ben Guthro <ben@guthro.net> wrote:
> Any thoughts, or suggestions on how best to debug these deadlocks
> would be greatly appreciated.

For Dom0 deadlocks all I generally need are the 'e' and '0' debugkeys
(with, for the latter, stack printing depth being set sufficiently high).
If that turns out insufficient, custom debugging changes to hypervisor
or kernel are the usual next (and final) step.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:40:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:40:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RruHH-0000GN-1Z; Mon, 30 Jan 2012 16:40:23 +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 1RruHF-0000GF-06
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:40:21 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1327941572!62305716!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12265 invoked from network); 30 Jan 2012 16:39:32 -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; 30 Jan 2012 16:39:32 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Mon, 30 Jan 2012 16:40:15 +0000
Message-Id: <4F26D5FD020000780006FF59@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Mon, 30 Jan 2012 16:40:13 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ben Guthro" <ben@guthro.net>
References: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
In-Reply-To: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Konrad Rzeszutek <konrad@darnok.org>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] debugging 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 30.01.12 at 17:27, Ben Guthro <ben@guthro.net> wrote:
> Any thoughts, or suggestions on how best to debug these deadlocks
> would be greatly appreciated.

For Dom0 deadlocks all I generally need are the 'e' and '0' debugkeys
(with, for the latter, stack printing depth being set sufficiently high).
If that turns out insufficient, custom debugging changes to hypervisor
or kernel are the usual next (and final) step.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:42:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RruIt-0000M9-HW; Mon, 30 Jan 2012 16:42:03 +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 1RruIs-0000Lr-1X
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:42:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327941715!12976057!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10858 invoked from network); 30 Jan 2012 16:41:55 -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;
	30 Jan 2012 16:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10371468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:41: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, 30 Jan 2012 16:41:54 +0000
Date: Mon, 30 Jan 2012 16:43:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <F7D7652D-C74F-4921-8662-357CB8671E58@cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1201301643070.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
	<1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
	<alpine.DEB.2.00.1201301220280.3196@kaball-desktop>
	<F7D7652D-C74F-4921-8662-357CB8671E58@cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
> On 2012-01-30, at 6:16 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 27 Jan 2012, Shriram Rajagopalan wrote:
> >> If there is an error in applying the toolstack state, then pagebuf_get returns -1 and
> >> the rest of the code would still attempt to resume the domain, with possibly
> >> inconsistent device model state.
> > 
> > This sounds like an unhandled error in the caller of pagebuf_get.
> 
> Nope. pagebuf_get is used only when Remus is on. 
> It is called after applying the last memory checkpoint.
> So when it returns an error, we simply discard whatever we buffered
> and wrap up. For migration we
> have a special xc_save_id_last_checkpoint
> that terminates the code after 
> buffering the first pagebuf.
> 
> > I think that if pagebuf_get returns an error, the error should be
> > propagated and the migration should be aborted, right?
> > After all I don't think we can successfully resume the domain if we fail
> > to read XC_SAVE_ID_TSC_INFO, for example.
> > I think we need something like this:
> > 
> > 
> > @@ -1589,9 +1616,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > 
> >     // DPRINTF("Buffered checkpoint\n");
> > 
> > -    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
> > +    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
> >         PERROR("error when buffering batch, finishing");
> > -        goto finish;
> > +        goto out;
> >     }
> >     memset(&tmptail, 0, sizeof(tmptail));
> >     tmptail.ishvm = hvm;
> > 
> > 
> >> Also, lets say there was no error in applying the toolstack state. If a network
> >> error occurs while receiving the next XC_SAVE_ID or so, then again, the code following
> >> the above snippet would attempt to resume the domain, with a memory state inconsistent
> >> with the device state.
> > 
> > This seems wrong to me, but I am not very familiar with this protocol.
> > As I wrote above, why should we continue if pagebuf_get returns an
> > error?
> > 
> > 
> >> The right place to call the callbacks->toolstack_restore would be after the finish_hvm:
> >> label, where currently the old QEMU device state is restored.
> > 
> > Are you suggesting that we should read the toolstack data from
> > pagebuf_get but only call the callback after finish_hvm?
> 
> Yep. I hope the above explanation made some sense.

All right, I'll do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:42:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:42:15 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RruIt-0000M9-HW; Mon, 30 Jan 2012 16:42:03 +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 1RruIs-0000Lr-1X
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:42:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327941715!12976057!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10858 invoked from network); 30 Jan 2012 16:41:55 -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;
	30 Jan 2012 16:41:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10371468"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:41: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, 30 Jan 2012 16:41:54 +0000
Date: Mon, 30 Jan 2012 16:43:27 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <F7D7652D-C74F-4921-8662-357CB8671E58@cs.ubc.ca>
Message-ID: <alpine.DEB.2.00.1201301643070.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201201651210.3196@kaball-desktop>
	<1327080331-8931-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPPmQbrNYzSuo9KuM9nzJcLgzA+GvSiQJkd43NAt_-5-KA@mail.gmail.com>
	<alpine.DEB.2.00.1201301220280.3196@kaball-desktop>
	<F7D7652D-C74F-4921-8662-357CB8671E58@cs.ubc.ca>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
> On 2012-01-30, at 6:16 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> 
> > On Fri, 27 Jan 2012, Shriram Rajagopalan wrote:
> >> If there is an error in applying the toolstack state, then pagebuf_get returns -1 and
> >> the rest of the code would still attempt to resume the domain, with possibly
> >> inconsistent device model state.
> > 
> > This sounds like an unhandled error in the caller of pagebuf_get.
> 
> Nope. pagebuf_get is used only when Remus is on. 
> It is called after applying the last memory checkpoint.
> So when it returns an error, we simply discard whatever we buffered
> and wrap up. For migration we
> have a special xc_save_id_last_checkpoint
> that terminates the code after 
> buffering the first pagebuf.
> 
> > I think that if pagebuf_get returns an error, the error should be
> > propagated and the migration should be aborted, right?
> > After all I don't think we can successfully resume the domain if we fail
> > to read XC_SAVE_ID_TSC_INFO, for example.
> > I think we need something like this:
> > 
> > 
> > @@ -1589,9 +1616,10 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> > 
> >     // DPRINTF("Buffered checkpoint\n");
> > 
> > -    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
> > +    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
> >         PERROR("error when buffering batch, finishing");
> > -        goto finish;
> > +        goto out;
> >     }
> >     memset(&tmptail, 0, sizeof(tmptail));
> >     tmptail.ishvm = hvm;
> > 
> > 
> >> Also, lets say there was no error in applying the toolstack state. If a network
> >> error occurs while receiving the next XC_SAVE_ID or so, then again, the code following
> >> the above snippet would attempt to resume the domain, with a memory state inconsistent
> >> with the device state.
> > 
> > This seems wrong to me, but I am not very familiar with this protocol.
> > As I wrote above, why should we continue if pagebuf_get returns an
> > error?
> > 
> > 
> >> The right place to call the callbacks->toolstack_restore would be after the finish_hvm:
> >> label, where currently the old QEMU device state is restored.
> > 
> > Are you suggesting that we should read the toolstack data from
> > pagebuf_get but only call the callback after finish_hvm?
> 
> Yep. I hope the above explanation made some sense.

All right, I'll do that.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:42:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RruJB-0000OG-Uk; Mon, 30 Jan 2012 16:42:21 +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 1RruJ9-0000NG-UR
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:42:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327941733!5554195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26191 invoked from network); 30 Jan 2012 16:42:13 -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;
	30 Jan 2012 16:42:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10371475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:42:13 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 16:42:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 30 Jan 2012 16:42:24 +0000
Message-ID: <1327941744.5553.29.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: wei.liu2@citrix.com
Subject: [Xen-devel] xl: add reference for vcpu-set command.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

exporting patch:
# HG changeset patch
# User Wei Liu <wei.liu2@citrix.com>
# Date 1327941564 0
# Node ID d433a9cb0089683b8f75458807c5437341f2cdcc
# Parent  f31d8d1b534eab54178c2a73112562d46bbd6fcb
xl: add reference for vcpu-set command.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -486,6 +486,9 @@ Attempting to set the VCPUs to a number 
 configured VCPU count is an error.  Trying to set VCPUs to < 1 will be
 quietly ignored.
 
+Some guests may need to actually bring the newly added CPU online
+after B<vcpu-set>, go to B<SEE ALSO> section for information.
+
 =item B<vcpu-list> [I<domain-id>]
 
 Lists VCPU information for a specific domain.  If no domain is
@@ -1067,6 +1070,10 @@ L<http://xenbits.xen.org/docs/unstable/m
 L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
 L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
 
+For systems that don't automatically bring CPU online:
+
+L<http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug>
+
 =head1 BUGS
 
 Send bugs to xen-devel@lists.xensource.com, see



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:42:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RruJB-0000OG-Uk; Mon, 30 Jan 2012 16:42:21 +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 1RruJ9-0000NG-UR
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:42:20 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327941733!5554195!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26191 invoked from network); 30 Jan 2012 16:42:13 -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;
	30 Jan 2012 16:42:13 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10371475"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:42:13 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 16:42:13 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Mon, 30 Jan 2012 16:42:24 +0000
Message-ID: <1327941744.5553.29.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: wei.liu2@citrix.com
Subject: [Xen-devel] xl: add reference for vcpu-set command.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

exporting patch:
# HG changeset patch
# User Wei Liu <wei.liu2@citrix.com>
# Date 1327941564 0
# Node ID d433a9cb0089683b8f75458807c5437341f2cdcc
# Parent  f31d8d1b534eab54178c2a73112562d46bbd6fcb
xl: add reference for vcpu-set command.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -486,6 +486,9 @@ Attempting to set the VCPUs to a number 
 configured VCPU count is an error.  Trying to set VCPUs to < 1 will be
 quietly ignored.
 
+Some guests may need to actually bring the newly added CPU online
+after B<vcpu-set>, go to B<SEE ALSO> section for information.
+
 =item B<vcpu-list> [I<domain-id>]
 
 Lists VCPU information for a specific domain.  If no domain is
@@ -1067,6 +1070,10 @@ L<http://xenbits.xen.org/docs/unstable/m
 L<http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt>
 L<http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt>
 
+For systems that don't automatically bring CPU online:
+
+L<http://wiki.xen.org/wiki/Paravirt_Linux_CPU_Hotplug>
+
 =head1 BUGS
 
 Send bugs to xen-devel@lists.xensource.com, see



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:51:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:51:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RruRz-0000nM-2e; Mon, 30 Jan 2012 16:51: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 1RruRx-0000nH-AD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:51:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327942210!63060779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15649 invoked from network); 30 Jan 2012 16:50:10 -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;
	30 Jan 2012 16:50:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10371708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:51: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; Mon, 30 Jan 2012 16:51:19 +0000
Date: Mon, 30 Jan 2012 16:52: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.1201301647180.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/2] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.


Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (2):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap

 tools/libxc/xc_domain_restore.c |   32 +++++++++-
 tools/libxc/xc_domain_save.c    |   17 +++++
 tools/libxc/xenguest.h          |   23 +++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  132 ++++++++++++++++++++++++++++++++++++++-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 203 insertions(+), 4 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:51:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16:51:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RruRz-0000nM-2e; Mon, 30 Jan 2012 16:51: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 1RruRx-0000nH-AD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:51:25 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327942210!63060779!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15649 invoked from network); 30 Jan 2012 16:50:10 -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;
	30 Jan 2012 16:50:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10371708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 16:51: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; Mon, 30 Jan 2012 16:51:19 +0000
Date: Mon, 30 Jan 2012 16:52: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.1201301647180.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 0/2] libxl: save/restore qemu physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this patch series introduces a new xc_save_id called
XC_SAVE_ID_TOOLSTACK to save/restore toolstack specific information.
Libxl is going to use the new save_id to save and restore qemu's
physmap.


Changes in v3:

- rebased the series;

- xc_domain_restore: read the toolstack data in pagebuf_get_one, call
the callback at finish_hvm;



Changes in v2:

- xc_domain_save frees the buffer allocated by the callback;

- introduce a version number in the libxl save record;

- define libxl__physmap_info and use it to read/store information to the
buffer.


Stefano Stabellini (2):
      libxc: introduce XC_SAVE_ID_TOOLSTACK
      libxl: save/restore qemu's physmap

 tools/libxc/xc_domain_restore.c |   32 +++++++++-
 tools/libxc/xc_domain_save.c    |   17 +++++
 tools/libxc/xenguest.h          |   23 +++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |  132 ++++++++++++++++++++++++++++++++++++++-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 203 insertions(+), 4 deletions(-)

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:52:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RruTG-0000u6-NM; Mon, 30 Jan 2012 16:52: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 1RruTF-0000tb-KL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:52:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327942357!12380249!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19472 invoked from network); 30 Jan 2012 16:52:39 -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;
	30 Jan 2012 16:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21419434"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:52:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:52: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 q0UGqTZa029317;
	Mon, 30 Jan 2012 08:52:30 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 16:54:14 +0000
Message-ID: <1327942455-23587-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.1201301647180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   32 +++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 +++++++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..ead3df4 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -45,6 +45,8 @@ struct restore_ctx {
     int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
     int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
     struct domain_info_context dinfo;
+    uint8_t *toolstack_data;
+    uint32_t toolstack_data_len;
 };
 
 #define HEARTBEAT_MS 1000
@@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &ctx->toolstack_data_len,
+                    sizeof(ctx->toolstack_data_len));
+            ctx->toolstack_data = (uint8_t*) malloc(ctx->toolstack_data_len);
+            if ( ctx->toolstack_data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, ctx->toolstack_data, ctx->toolstack_data_len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1262,7 +1278,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -2023,6 +2040,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom,
+                    ctx->toolstack_data, ctx->toolstack_data_len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(ctx->toolstack_data);
+            goto out;
+        }
+    }
+    free(ctx->toolstack_data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..76aa475 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..2c5eec5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..306a10e 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
                             console_evtchn, &console_mfn, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:52:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RruTG-0000u6-NM; Mon, 30 Jan 2012 16:52: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 1RruTF-0000tb-KL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:52:45 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327942357!12380249!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19472 invoked from network); 30 Jan 2012 16:52:39 -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;
	30 Jan 2012 16:52:39 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21419434"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:52:37 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Mon, 30 Jan 2012 11:52: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 q0UGqTZa029317;
	Mon, 30 Jan 2012 08:52:30 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 16:54:14 +0000
Message-ID: <1327942455-23587-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.1201301647180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Introduce a new save_id to save/restore toolstack specific extra
information.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxc/xc_domain_restore.c |   32 +++++++++++++++++++++++++++++++-
 tools/libxc/xc_domain_save.c    |   17 +++++++++++++++++
 tools/libxc/xenguest.h          |   23 ++++++++++++++++++++++-
 tools/libxc/xg_save_restore.h   |    1 +
 tools/libxl/libxl_dom.c         |    2 +-
 tools/xcutils/xc_restore.c      |    2 +-
 6 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..ead3df4 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -45,6 +45,8 @@ struct restore_ctx {
     int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
     int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
     struct domain_info_context dinfo;
+    uint8_t *toolstack_data;
+    uint32_t toolstack_data_len;
 };
 
 #define HEARTBEAT_MS 1000
@@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
         }
         return pagebuf_get_one(xch, ctx, buf, fd, dom);
 
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &ctx->toolstack_data_len,
+                    sizeof(ctx->toolstack_data_len));
+            ctx->toolstack_data = (uint8_t*) malloc(ctx->toolstack_data_len);
+            if ( ctx->toolstack_data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, ctx->toolstack_data, ctx->toolstack_data_len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        }
+
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
          * since this pagebuf still has uncompressed pages that are yet to
@@ -1262,7 +1278,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -2023,6 +2040,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom,
+                    ctx->toolstack_data, ctx->toolstack_data_len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(ctx->toolstack_data);
+            goto out;
+        }
+    }
+    free(ctx->toolstack_data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..76aa475 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..2c5eec5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..306a10e 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
                             console_evtchn, &console_mfn, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:53:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RruTM-0000uh-4e; Mon, 30 Jan 2012 16:52:52 +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 1RruTK-0000tu-Fe
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:52:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327942357!12380249!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19914 invoked from network); 30 Jan 2012 16:52:43 -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;
	30 Jan 2012 16:52:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21419441"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:52:43 -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, 30 Jan 2012 11:52: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 q0UGqTZb029317;
	Mon, 30 Jan 2012 08:52:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 16:54:15 +0000
Message-ID: <1327942455-23587-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.1201301647180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2c5eec5..a6eb714 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -349,6 +349,66 @@ out:
     return rc;
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+
+    if (size < sizeof(version) + sizeof(count))
+        return -1;
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION)
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, pi->phys_offset), "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, pi->phys_offset), "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -358,6 +418,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -365,6 +426,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = info->u.hvm.pae;
         no_incr_generationid = info->u.hvm.no_incr_generationid;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -379,7 +442,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -534,6 +597,72 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -596,6 +725,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 16:53:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 16: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 1RruTM-0000uh-4e; Mon, 30 Jan 2012 16:52:52 +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 1RruTK-0000tu-Fe
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 16:52:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1327942357!12380249!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg5NDQ=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19914 invoked from network); 30 Jan 2012 16:52:43 -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;
	30 Jan 2012 16:52:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320642000"; d="scan'208";a="21419441"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 11:52:43 -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, 30 Jan 2012 11:52: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 q0UGqTZb029317;
	Mon, 30 Jan 2012 08:52:31 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 16:54:15 +0000
Message-ID: <1327942455-23587-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.1201301647180.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
MIME-Version: 1.0
Cc: rshriram@cs.ubc.ca, Ian.Campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH v3 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Read Qemu's physmap from xenstore and save it using toolstack_save.
Restore Qemu's physmap using toolstack_restore.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 tools/libxl/libxl_dom.c |  132 ++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 131 insertions(+), 1 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 2c5eec5..a6eb714 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -349,6 +349,66 @@ out:
     return rc;
 }
 
+struct libxl__physmap_info {
+    uint64_t phys_offset;
+    uint64_t start_addr;
+    uint64_t size;
+    uint32_t namelen;
+    char name[];
+};
+
+#define TOOLSTACK_SAVE_VERSION 1
+
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
+        uint32_t size, void *data)
+{
+    libxl__gc *gc = (libxl__gc *) data;
+    int i, ret;
+    uint8_t *ptr = buf;
+    uint32_t count = 0, version = 0;
+    struct libxl__physmap_info* pi;
+
+    if (size < sizeof(version) + sizeof(count))
+        return -1;
+
+    memcpy(&version, ptr, sizeof(version));
+    ptr += sizeof(version);
+
+    if (version != TOOLSTACK_SAVE_VERSION)
+        return -1;
+
+    memcpy(&count, ptr, sizeof(count));
+    ptr += sizeof(count);
+ 
+    if (size < sizeof(version) + sizeof(count) +
+            count * (sizeof(struct libxl__physmap_info)))
+        return -1;
+
+    for (i = 0; i < count; i++) {
+        pi = (struct libxl__physmap_info*) ptr;
+        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
+
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
+        if (ret)
+            return -1;
+        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+                    domid, pi->phys_offset), "%"PRIx64, pi->size);
+        if (ret)
+            return -1;
+        if (pi->namelen > 0) {
+            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
+                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+                        domid, pi->phys_offset), "%s", pi->name);
+            if (ret)
+                return -1;
+        }
+    }
+    return 0;
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -358,6 +418,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
     /* read signature */
     int rc;
     int hvm, pae, superpages;
+    struct restore_callbacks callbacks;
     int no_incr_generationid;
     switch (info->type) {
     case LIBXL_DOMAIN_TYPE_HVM:
@@ -365,6 +426,8 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
         superpages = 1;
         pae = info->u.hvm.pae;
         no_incr_generationid = info->u.hvm.no_incr_generationid;
+        callbacks.toolstack_restore = libxl__toolstack_restore;
+        callbacks.data = gc;
         break;
     case LIBXL_DOMAIN_TYPE_PV:
         hvm = 0;
@@ -379,7 +442,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr, NULL);
+                           &state->vm_generationid_addr, &callbacks);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
@@ -534,6 +597,72 @@ static int libxl__domain_suspend_common_callback(void *data)
     return 0;
 }
 
+static int libxl__toolstack_save(uint32_t domid, uint8_t **buf,
+        uint32_t *len, void *data)
+{
+    struct suspendinfo *si = (struct suspendinfo *) data;
+    libxl__gc *gc = (libxl__gc *) si->gc;
+    int i = 0;
+    char *start_addr = NULL, *size = NULL, *phys_offset = NULL, *name = NULL;
+    unsigned int num = 0;
+    uint32_t count = 0, version = TOOLSTACK_SAVE_VERSION, namelen = 0;
+    uint8_t *ptr = NULL;
+    char **entries = NULL;
+    struct libxl__physmap_info *pi;
+
+    entries = libxl__xs_directory(gc, 0, libxl__sprintf(gc,
+                "/local/domain/0/device-model/%d/physmap", domid), &num);
+    count = num;
+
+    *len = sizeof(version) + sizeof(count);
+    *buf = calloc(1, *len);
+    ptr = *buf;
+    if (*buf == NULL)
+        return -1;
+
+    memcpy(ptr, &version, sizeof(version));
+    ptr += sizeof(version);
+    memcpy(ptr, &count, sizeof(count));
+    ptr += sizeof(count);
+
+    for (i = 0; i < count; i++) {
+        unsigned long offset;
+        phys_offset = entries[i];
+        start_addr = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/start_addr",
+                    domid, phys_offset));
+        size = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/size",
+                    domid, phys_offset));
+        name = libxl__xs_read(gc, 0, libxl__sprintf(gc,
+                    "/local/domain/0/device-model/%d/physmap/%s/name",
+                    domid, phys_offset));
+
+        if (start_addr == NULL || size == NULL || phys_offset == NULL)
+            return -1;
+
+        if (name == NULL)
+            namelen = 0;
+        else
+            namelen = strlen(name) + 1;
+        *len += namelen + sizeof(struct libxl__physmap_info);
+        offset = ptr - (*buf);
+        *buf = realloc(*buf, *len);
+        if (*buf == NULL)
+            return -1;
+        ptr = (*buf) + offset;
+        pi = (struct libxl__physmap_info *) ptr;
+        pi->phys_offset = strtoll(phys_offset, NULL, 16);
+        pi->start_addr = strtoll(start_addr, NULL, 16);
+        pi->size = strtoll(size, NULL, 16);
+        pi->namelen = namelen;
+        memcpy(pi->name, name, namelen);
+        ptr += sizeof(struct libxl__physmap_info) + namelen;
+    }
+
+    return 0;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
                                  int live, int debug)
@@ -596,6 +725,7 @@ int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
     memset(&callbacks, 0, sizeof(callbacks));
     callbacks.suspend = libxl__domain_suspend_common_callback;
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
+    callbacks.toolstack_save = libxl__toolstack_save;
     callbacks.data = &si;
 
     rc = xc_domain_save(ctx->xch, fd, domid, 0, 0, flags, &callbacks,
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 17:05:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17:05:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rruf3-0001LP-Dc; Mon, 30 Jan 2012 17:04:57 +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 1Rruf1-0001LJ-5i
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 17:04:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327943089!12979017!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26714 invoked from network); 30 Jan 2012 17:04:49 -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;
	30 Jan 2012 17:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10372060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 17:04:49 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 17:04:48 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Viral Mehta <viral.vkm@gmail.com>
In-Reply-To: <CANX6Dak_1VQ1J8hRK+yd1-FmGOnd75BkNm2uUVKd_TNTiNLtxg@mail.gmail.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-5-git-send-email-wei.liu2@citrix.com>
	<CANX6Dak_1VQ1J8hRK+yd1-FmGOnd75BkNm2uUVKd_TNTiNLtxg@mail.gmail.com>
Date: Mon, 30 Jan 2012 17:05:00 +0000
Message-ID: <1327943100.5553.33.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 04/16] netback: switch to per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 16:49 +0000, Viral Mehta wrote:
> Hi,
> 
> On Mon, Jan 30, 2012 at 9:45 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> >
> >        skb_queue_head_init(&rxq);
> > @@ -534,13 +527,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
> >                        break;
> >        }
> >
> > -       BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
> > +       BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
> 
> While you are already here,
> how about having WARN_ON() ?
> 
> >
> > -       if (!npo.copy_prod)
> > +       if (!npo.copy_prod) {
> > +               put_cpu_ptr(gco);
> > +               put_cpu_ptr(m);
> >                return;
> > +       }
> >
> > -       BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
> > -       ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
> > +       BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
> 
> And may be here, too...
> 
> If there is serious bug, may be system will crash at a later point
> But, IMHO, WARN_ON() is the correct function for drivers at least.
> 

I don't agree. Here BUG_ON means code logic has defects that we haven't
discovered. I won't take the risk of any undefined behavior.

Further more, there are a bunch of drivers use BUG_ON. A simple grep
will show you hundreds (even thousands?) of results.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 17:05:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17:05:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rruf3-0001LP-Dc; Mon, 30 Jan 2012 17:04:57 +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 1Rruf1-0001LJ-5i
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 17:04:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327943089!12979017!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26714 invoked from network); 30 Jan 2012 17:04:49 -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;
	30 Jan 2012 17:04:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10372060"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 17:04:49 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 17:04:48 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Viral Mehta <viral.vkm@gmail.com>
In-Reply-To: <CANX6Dak_1VQ1J8hRK+yd1-FmGOnd75BkNm2uUVKd_TNTiNLtxg@mail.gmail.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-5-git-send-email-wei.liu2@citrix.com>
	<CANX6Dak_1VQ1J8hRK+yd1-FmGOnd75BkNm2uUVKd_TNTiNLtxg@mail.gmail.com>
Date: Mon, 30 Jan 2012 17:05:00 +0000
Message-ID: <1327943100.5553.33.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 04/16] netback: switch to per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 16:49 +0000, Viral Mehta wrote:
> Hi,
> 
> On Mon, Jan 30, 2012 at 9:45 AM, Wei Liu <wei.liu2@citrix.com> wrote:
> >
> >        skb_queue_head_init(&rxq);
> > @@ -534,13 +527,16 @@ void xen_netbk_rx_action(struct xen_netbk *netbk)
> >                        break;
> >        }
> >
> > -       BUG_ON(npo.meta_prod > ARRAY_SIZE(netbk->meta));
> > +       BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
> 
> While you are already here,
> how about having WARN_ON() ?
> 
> >
> > -       if (!npo.copy_prod)
> > +       if (!npo.copy_prod) {
> > +               put_cpu_ptr(gco);
> > +               put_cpu_ptr(m);
> >                return;
> > +       }
> >
> > -       BUG_ON(npo.copy_prod > ARRAY_SIZE(netbk->grant_copy_op));
> > -       ret = HYPERVISOR_grant_table_op(GNTTABOP_copy, &netbk->grant_copy_op,
> > +       BUG_ON(npo.copy_prod > (2 * XEN_NETIF_RX_RING_SIZE));
> 
> And may be here, too...
> 
> If there is serious bug, may be system will crash at a later point
> But, IMHO, WARN_ON() is the correct function for drivers at least.
> 

I don't agree. Here BUG_ON means code logic has defects that we haven't
discovered. I won't take the risk of any undefined behavior.

Further more, there are a bunch of drivers use BUG_ON. A simple grep
will show you hundreds (even thousands?) of results.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 17:06:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17: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 1RrugU-0001PT-VC; Mon, 30 Jan 2012 17:06:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RrugS-0001PK-B1
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 17:06:24 +0000
Received: from [85.158.138.51:46647] by server-7.bemta-3.messagelabs.com id
	06/42-31267-F0EC62F4; Mon, 30 Jan 2012 17:06:23 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327943181!11292159!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15638 invoked from network); 30 Jan 2012 17:06:22 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.139)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	30 Jan 2012 17:06:22 -0000
Received: from mail43-db3-R.bigfish.com (10.3.81.238) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 30 Jan 2012 17:06:21 +0000
Received: from mail43-db3 (localhost [127.0.0.1])	by mail43-db3-R.bigfish.com
	(Postfix) with ESMTP id AFB86E0318;
	Mon, 30 Jan 2012 17:06:21 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail43-db3 (localhost.localdomain [127.0.0.1]) by mail43-db3
	(MessageSwitch) id 1327943179560994_18698;
	Mon, 30 Jan 2012 17:06:19 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.231])	by
	mail43-db3.bigfish.com (Postfix) with ESMTP id 7A7A9C0048;
	Mon, 30 Jan 2012 17:06:19 +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; Mon, 30 Jan 2012 17:06:13 +0000
X-WSS-ID: 0LYMFIA-02-49O-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 2AFF2C80FF;	Mon, 30 Jan 2012 11:06:09 -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;
	Mon, 30 Jan 2012 11:06:16 -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;
	Mon, 30 Jan 2012 11:06:10 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Mon, 30 Jan 2012
	12:06:09 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8DB0349C2B0; Mon, 30 Jan 2012
	17:06:08 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 800E02D202B; Mon,
	30 Jan 2012 18:06:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1361d9895cb17aa8fce1054120311285144b8399
Message-ID: <1361d9895cb17aa8fce1.1327943146@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Mon, 30 Jan 2012 18:05:46 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com, keir@xen.org
Subject: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature in
	guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1327942850 -3600
# Node ID 1361d9895cb17aa8fce1054120311285144b8399
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r e2722b24dc09 -r 1361d9895cb1 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 30 18:00:50 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
diff -r e2722b24dc09 -r 1361d9895cb1 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Mon Jan 30 18:00:50 2012 +0100
@@ -83,6 +83,9 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
 
 static bool_t amd_erratum383_found __read_mostly;
 
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -902,6 +905,60 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
+    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |= 1;
+}
+
+void svm_host_osvw_reset()
+{
+    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status = 0;
+}
+
+void svm_host_osvw_init()
+{
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+         
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len = status = 0;
+
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+    } else
+        osvw_length = osvw_status = 0;
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +987,9 @@ static int svm_vcpu_initialise(struct vc
     }
 
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
 
@@ -1044,6 +1104,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.hvm_svm.osvw.length;
+        else
+            *val = v->arch.hvm_svm.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1175,9 @@ static int svm_cpu_up(void)
     }
 #endif
 
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
 
@@ -1104,6 +1188,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
 
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1474,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1605,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r e2722b24dc09 -r 1361d9895cb1 xen/arch/x86/microcode.c
--- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode.c	Mon Jan 30 18:00:50 2012 +0100
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error = 0;
     info->cpu = cpumask_first(&cpu_online_map);
 
+    if ( microcode_ops->start_update )
+    {
+	ret = microcode_ops->start_update();
+	if ( ret != 0 )
+        {
+	    xfree(info);
+	    return ret;
+	}
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
 }
 
diff -r e2722b24dc09 -r 1361d9895cb1 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode_amd.c	Mon Jan 30 18:00:50 2012 +0100
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
 
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -287,7 +288,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_amd = xmalloc(struct microcode_amd);
@@ -295,7 +297,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error = -ENOMEM;
+        goto out;
     }
 
     error = install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +306,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_old = uci->mc.mc_amd;
@@ -337,13 +341,18 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error == 1)
+    if ( error == 1 )
     {
         xfree(mc_old);
-        return 0;
+        error = 0;
+    } else 
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd = mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd = mc_old;
+
+  out:
+    svm_host_osvw_init();
 
     return error;
 }
@@ -395,11 +404,19 @@ err1:
     return -ENOMEM;
 }
 
+static int start_update(void) 
+{
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops = {
     .microcode_resume_match           = microcode_resume_match,
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
+    .start_update                     = start_update,
 };
 
 static __init int microcode_init_amd(void)
diff -r e2722b24dc09 -r 1361d9895cb1 xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Mon Jan 30 18:00:50 2012 +0100
@@ -166,7 +166,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
 
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        while ( !domctl_lock_acquire() )
+            if ( hypercall_preempt_check() )
+            {
+                ret = hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret = microcode_update(data, op->u.microcode.length);
+        domctl_lock_release();
     }
     break;
 
diff -r e2722b24dc09 -r 1361d9895cb1 xen/include/asm-x86/hvm/svm/svm.h
--- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/svm.h	Mon Jan 30 18:00:50 2012 +0100
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
diff -r e2722b24dc09 -r 1361d9895cb1 xen/include/asm-x86/hvm/svm/vmcb.h
--- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Mon Jan 30 18:00:50 2012 +0100
@@ -516,6 +516,12 @@ struct arch_svm_struct {
     
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
 
 struct vmcb_struct *alloc_vmcb(void);
diff -r e2722b24dc09 -r 1361d9895cb1 xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/microcode.h	Mon Jan 30 18:00:50 2012 +0100
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
 
 struct cpu_signature {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 17:06:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17: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 1RrugU-0001PT-VC; Mon, 30 Jan 2012 17:06:26 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Boris.Ostrovsky@amd.com>) id 1RrugS-0001PK-B1
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 17:06:24 +0000
Received: from [85.158.138.51:46647] by server-7.bemta-3.messagelabs.com id
	06/42-31267-F0EC62F4; Mon, 30 Jan 2012 17:06:23 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327943181!11292159!1
X-Originating-IP: [213.199.154.139]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15638 invoked from network); 30 Jan 2012 17:06:22 -0000
Received: from db3ehsobe001.messaging.microsoft.com (HELO
	DB3EHSOBE003.bigfish.com) (213.199.154.139)
	by server-11.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	30 Jan 2012 17:06:22 -0000
Received: from mail43-db3-R.bigfish.com (10.3.81.238) by
	DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id
	14.1.225.23; Mon, 30 Jan 2012 17:06:21 +0000
Received: from mail43-db3 (localhost [127.0.0.1])	by mail43-db3-R.bigfish.com
	(Postfix) with ESMTP id AFB86E0318;
	Mon, 30 Jan 2012 17:06:21 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail43-db3 (localhost.localdomain [127.0.0.1]) by mail43-db3
	(MessageSwitch) id 1327943179560994_18698;
	Mon, 30 Jan 2012 17:06:19 +0000 (UTC)
Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.231])	by
	mail43-db3.bigfish.com (Postfix) with ESMTP id 7A7A9C0048;
	Mon, 30 Jan 2012 17:06:19 +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; Mon, 30 Jan 2012 17:06:13 +0000
X-WSS-ID: 0LYMFIA-02-49O-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 2AFF2C80FF;	Mon, 30 Jan 2012 11:06:09 -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;
	Mon, 30 Jan 2012 11:06:16 -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;
	Mon, 30 Jan 2012 11:06:10 -0600
Received: from gwo.osrc.amd.com (165.204.16.204) by storexhtp01.amd.com
	(172.24.4.3) with Microsoft SMTP Server id 8.3.213.0; Mon, 30 Jan 2012
	12:06:09 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 8DB0349C2B0; Mon, 30 Jan 2012
	17:06:08 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 800E02D202B; Mon,
	30 Jan 2012 18:06:08 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: 1361d9895cb17aa8fce1054120311285144b8399
Message-ID: <1361d9895cb17aa8fce1.1327943146@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Mon, 30 Jan 2012 18:05:46 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com, keir@xen.org
Subject: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature in
	guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1327942850 -3600
# Node ID 1361d9895cb17aa8fce1054120311285144b8399
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r e2722b24dc09 -r 1361d9895cb1 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_cpuid_x86.c	Mon Jan 30 18:00:50 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
diff -r e2722b24dc09 -r 1361d9895cb1 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Mon Jan 30 18:00:50 2012 +0100
@@ -83,6 +83,9 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
 
 static bool_t amd_erratum383_found __read_mostly;
 
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -902,6 +905,60 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
+    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |= 1;
+}
+
+void svm_host_osvw_reset()
+{
+    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status = 0;
+}
+
+void svm_host_osvw_init()
+{
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+         
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len = status = 0;
+
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+    } else
+        osvw_length = osvw_status = 0;
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +987,9 @@ static int svm_vcpu_initialise(struct vc
     }
 
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
 
@@ -1044,6 +1104,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.hvm_svm.osvw.length;
+        else
+            *val = v->arch.hvm_svm.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1175,9 @@ static int svm_cpu_up(void)
     }
 #endif
 
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
 
@@ -1104,6 +1188,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
 
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1474,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1605,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r e2722b24dc09 -r 1361d9895cb1 xen/arch/x86/microcode.c
--- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode.c	Mon Jan 30 18:00:50 2012 +0100
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error = 0;
     info->cpu = cpumask_first(&cpu_online_map);
 
+    if ( microcode_ops->start_update )
+    {
+	ret = microcode_ops->start_update();
+	if ( ret != 0 )
+        {
+	    xfree(info);
+	    return ret;
+	}
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
 }
 
diff -r e2722b24dc09 -r 1361d9895cb1 xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode_amd.c	Mon Jan 30 18:00:50 2012 +0100
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
 
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -287,7 +288,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_amd = xmalloc(struct microcode_amd);
@@ -295,7 +297,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error = -ENOMEM;
+        goto out;
     }
 
     error = install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +306,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_old = uci->mc.mc_amd;
@@ -337,13 +341,18 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error == 1)
+    if ( error == 1 )
     {
         xfree(mc_old);
-        return 0;
+        error = 0;
+    } else 
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd = mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd = mc_old;
+
+  out:
+    svm_host_osvw_init();
 
     return error;
 }
@@ -395,11 +404,19 @@ err1:
     return -ENOMEM;
 }
 
+static int start_update(void) 
+{
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops = {
     .microcode_resume_match           = microcode_resume_match,
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
+    .start_update                     = start_update,
 };
 
 static __init int microcode_init_amd(void)
diff -r e2722b24dc09 -r 1361d9895cb1 xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Mon Jan 30 18:00:50 2012 +0100
@@ -166,7 +166,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
 
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        while ( !domctl_lock_acquire() )
+            if ( hypercall_preempt_check() )
+            {
+                ret = hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret = microcode_update(data, op->u.microcode.length);
+        domctl_lock_release();
     }
     break;
 
diff -r e2722b24dc09 -r 1361d9895cb1 xen/include/asm-x86/hvm/svm/svm.h
--- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/svm.h	Mon Jan 30 18:00:50 2012 +0100
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
diff -r e2722b24dc09 -r 1361d9895cb1 xen/include/asm-x86/hvm/svm/vmcb.h
--- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Mon Jan 30 18:00:50 2012 +0100
@@ -516,6 +516,12 @@ struct arch_svm_struct {
     
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
 
 struct vmcb_struct *alloc_vmcb(void);
diff -r e2722b24dc09 -r 1361d9895cb1 xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/microcode.h	Mon Jan 30 18:00:50 2012 +0100
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
 
 struct cpu_signature {


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 17:10:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17:10:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrukV-0001f1-QO; Mon, 30 Jan 2012 17:10:35 +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 1RrukU-0001eh-3J
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 17:10:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327943425!4296388!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20744 invoked from network); 30 Jan 2012 17:10:25 -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;
	30 Jan 2012 17:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10372175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 17:10:25 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 17:10:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F26D4E5020000780006FF41@nat28.tlf.novell.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
Date: Mon, 30 Jan 2012 17:10:36 +0000
Message-ID: <1327943436.5553.39.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> > -			      grant_ref_t tx_ring_ref,
> > -			      grant_ref_t rx_ring_ref)
> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> > +			      int domid,
> > +			      unsigned long ring_ref[],
> > +			      unsigned int  ring_ref_count)
> >  {
> > -	void *addr;
> > -	struct xen_netif_tx_sring *txs;
> > -	struct xen_netif_rx_sring *rxs;
> > -
> > -	int err = -ENOMEM;
> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> > +	unsigned int i;
> > +	int err = 0;
> >  
> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> > -				     tx_ring_ref, &addr);
> 
> Any reason why you don't just extend this function (in a prerequisite
> patch) rather than open coding a common utility function (twice) here,
> so that other backends (blkback!) can benefit later as well.
> 
> Jan
> 

I'm mainly focusing on netback stuffs, so the code is slightly coupled
with netback -- NETBK_MAX_RING_PAGES.

To extend xenbus_map_ring_valloc and make more generic, it requires
setting a global maximum page number limits on rings, I think it will
require further investigation and code refactor -- which I have no time
to attend to at the moment. :-/


Wei.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 17:10:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17:10:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrukV-0001f1-QO; Mon, 30 Jan 2012 17:10:35 +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 1RrukU-0001eh-3J
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 17:10:34 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1327943425!4296388!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20744 invoked from network); 30 Jan 2012 17:10:25 -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;
	30 Jan 2012 17:10:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10372175"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 17:10:25 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 17:10:25 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F26D4E5020000780006FF41@nat28.tlf.novell.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
Date: Mon, 30 Jan 2012 17:10:36 +0000
Message-ID: <1327943436.5553.39.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> > -			      grant_ref_t tx_ring_ref,
> > -			      grant_ref_t rx_ring_ref)
> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> > +			      int domid,
> > +			      unsigned long ring_ref[],
> > +			      unsigned int  ring_ref_count)
> >  {
> > -	void *addr;
> > -	struct xen_netif_tx_sring *txs;
> > -	struct xen_netif_rx_sring *rxs;
> > -
> > -	int err = -ENOMEM;
> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> > +	unsigned int i;
> > +	int err = 0;
> >  
> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> > -				     tx_ring_ref, &addr);
> 
> Any reason why you don't just extend this function (in a prerequisite
> patch) rather than open coding a common utility function (twice) here,
> so that other backends (blkback!) can benefit later as well.
> 
> Jan
> 

I'm mainly focusing on netback stuffs, so the code is slightly coupled
with netback -- NETBK_MAX_RING_PAGES.

To extend xenbus_map_ring_valloc and make more generic, it requires
setting a global maximum page number limits on rings, I think it will
require further investigation and code refactor -- which I have no time
to attend to at the moment. :-/


Wei.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 17:33:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17:33:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrv5r-00023p-Ps; Mon, 30 Jan 2012 17:32:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1Rrv5q-00023k-CL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 17:32:38 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327944751!9166642!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 905 invoked from network); 30 Jan 2012 17:32:31 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 17:32:31 -0000
Received: by bkar1 with SMTP id r1so7443182bka.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 09:32:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=GhjnppVRViuojCWG4H89re+X/a7MoxgWsjngMMpeZck=;
	b=ijMHnHh5M6l6fWpySyt5L1HaRFHCVPbKXl6+jedIAN8FVRpRLDHfbOAz5tscD8+F+c
	l9U382pZj7Btzdfzf9lXgGaXa2SZr0jMj3zCrnCRCa7uFBSF+l49CXpFxe1b0r3ScjYo
	vm8xzoFL7V3uAuLp7qCqOXp3vEjIb5cimng0U=
MIME-Version: 1.0
Received: by 10.205.139.76 with SMTP id iv12mr9277447bkc.126.1327944750936;
	Mon, 30 Jan 2012 09:32:30 -0800 (PST)
Received: by 10.205.47.197 with HTTP; Mon, 30 Jan 2012 09:32:30 -0800 (PST)
In-Reply-To: <4F26C68C.7020600@citrix.com>
References: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
	<4F26C68C.7020600@citrix.com>
Date: Mon, 30 Jan 2012 12:32:30 -0500
X-Google-Sender-Auth: 3MU58UQ0Q5GknuEBwkVfVMxchZw
Message-ID: <CAOvdn6VDAJZw6hYAvZ-1CmEg8Ts0-0PB4gVUX4nq2ap=gO0VVQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Konrad Rzeszutek <konrad@darnok.org>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] debugging 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes, it helped a lot!
This seems to have resolved the hang - thanks for pointing it my way!

So - if I'm reading the git log correctly, I should just have to
cherry-pick 7a7546b377bdaa25ac77f33d9433c59f259b9688 from mainline?

It seems like this may be something to CC the -stable queue on, IMHO.

On Mon, Jan 30, 2012 at 11:34 AM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 30/01/12 16:27, Ben Guthro wrote:
>> Konrad, et al.
>>
>> I'm having an issue with my guests that, when I am running wireless
>> drivers in dom0, and the PV-on-HVM guest tries to access the network -
>> I get a hung dom0.
>>
>> When I turn on
>> Kernel Hacking->
>> Spinlock and rw-lock debugging: basic checks
>>
>> The hang goes away, but does not print out anything terribly useful in
>> the serial log.
>>
>>
>> The config file =A0changes made by this menuconfig setting can be found =
below:
>>
>>
>> While I know from other conversations, that Konrad is aware of my
>> setup, for other's benefit - this is a 64bit dom0 3.2.2 kernel, with a
>> few of his branches pulled in.
>>
>> Any thoughts, or suggestions on how best to debug these deadlocks
>> would be greatly appreciated.
>
> It looks like
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01917.html might
> apply to you.
>
> Does that patch help?
>
> ~Andrew
>
>>
>> -Ben Guthro
>>
>>
>> diff --git a/configs/config.ubuntu.amd64 b/configs/config.ubuntu.amd64
>> index 205b5c6..f7a233f 100644
>> --- a/configs/config.ubuntu.amd64
>> +++ b/configs/config.ubuntu.amd64
>> @@ -257,27 +257,27 @@ CONFIG_PADATA=3Dy
>> =A0# CONFIG_INLINE_SPIN_LOCK_BH is not set
>> =A0# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
>> =A0# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
>> -CONFIG_INLINE_SPIN_UNLOCK=3Dy
>> +# CONFIG_INLINE_SPIN_UNLOCK is not set
>> =A0# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
>> -CONFIG_INLINE_SPIN_UNLOCK_IRQ=3Dy
>> +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
>> =A0# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
>> =A0# CONFIG_INLINE_READ_TRYLOCK is not set
>> =A0# CONFIG_INLINE_READ_LOCK is not set
>> =A0# CONFIG_INLINE_READ_LOCK_BH is not set
>> =A0# CONFIG_INLINE_READ_LOCK_IRQ is not set
>> =A0# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
>> -CONFIG_INLINE_READ_UNLOCK=3Dy
>> +# CONFIG_INLINE_READ_UNLOCK is not set
>> =A0# CONFIG_INLINE_READ_UNLOCK_BH is not set
>> -CONFIG_INLINE_READ_UNLOCK_IRQ=3Dy
>> +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
>> =A0# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
>> =A0# CONFIG_INLINE_WRITE_TRYLOCK is not set
>> =A0# CONFIG_INLINE_WRITE_LOCK is not set
>> =A0# CONFIG_INLINE_WRITE_LOCK_BH is not set
>> =A0# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
>> =A0# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
>> -CONFIG_INLINE_WRITE_UNLOCK=3Dy
>> +# CONFIG_INLINE_WRITE_UNLOCK is not set
>> =A0# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
>> -CONFIG_INLINE_WRITE_UNLOCK_IRQ=3Dy
>> +# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
>> =A0# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
>> =A0CONFIG_MUTEX_SPIN_ON_OWNER=3Dy
>> =A0CONFIG_FREEZER=3Dy
>> @@ -398,7 +398,7 @@ CONFIG_HAVE_MEMBLOCK_NODE_MAP=3Dy
>> =A0CONFIG_ARCH_DISCARD_MEMBLOCK=3Dy
>> =A0# CONFIG_MEMORY_HOTPLUG is not set
>> =A0CONFIG_PAGEFLAGS_EXTENDED=3Dy
>> -CONFIG_SPLIT_PTLOCK_CPUS=3D4
>> +CONFIG_SPLIT_PTLOCK_CPUS=3D999999
>> =A0# CONFIG_COMPACTION is not set
>> =A0CONFIG_MIGRATION=3Dy
>> =A0CONFIG_PHYS_ADDR_T_64BIT=3Dy
>> @@ -4255,7 +4255,7 @@ CONFIG_TIMER_STATS=3Dy
>> =A0# CONFIG_DEBUG_KMEMLEAK is not set
>> =A0# CONFIG_DEBUG_RT_MUTEXES is not set
>> =A0# CONFIG_RT_MUTEX_TESTER is not set
>> -# CONFIG_DEBUG_SPINLOCK is not set
>> +CONFIG_DEBUG_SPINLOCK=3Dy
>> =A0# CONFIG_DEBUG_MUTEXES is not set
>> =A0# CONFIG_DEBUG_LOCK_ALLOC is not set
>> =A0# CONFIG_PROVE_LOCKING is not set
>>
>> _______________________________________________
>> 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 Mon Jan 30 17:33:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17:33:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrv5r-00023p-Ps; Mon, 30 Jan 2012 17:32:39 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <ben.guthro@gmail.com>) id 1Rrv5q-00023k-CL
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 17:32:38 +0000
X-Env-Sender: ben.guthro@gmail.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1327944751!9166642!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 905 invoked from network); 30 Jan 2012 17:32:31 -0000
Received: from mail-bk0-f43.google.com (HELO mail-bk0-f43.google.com)
	(209.85.214.43)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 17:32:31 -0000
Received: by bkar1 with SMTP id r1so7443182bka.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 09:32:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=GhjnppVRViuojCWG4H89re+X/a7MoxgWsjngMMpeZck=;
	b=ijMHnHh5M6l6fWpySyt5L1HaRFHCVPbKXl6+jedIAN8FVRpRLDHfbOAz5tscD8+F+c
	l9U382pZj7Btzdfzf9lXgGaXa2SZr0jMj3zCrnCRCa7uFBSF+l49CXpFxe1b0r3ScjYo
	vm8xzoFL7V3uAuLp7qCqOXp3vEjIb5cimng0U=
MIME-Version: 1.0
Received: by 10.205.139.76 with SMTP id iv12mr9277447bkc.126.1327944750936;
	Mon, 30 Jan 2012 09:32:30 -0800 (PST)
Received: by 10.205.47.197 with HTTP; Mon, 30 Jan 2012 09:32:30 -0800 (PST)
In-Reply-To: <4F26C68C.7020600@citrix.com>
References: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>
	<4F26C68C.7020600@citrix.com>
Date: Mon, 30 Jan 2012 12:32:30 -0500
X-Google-Sender-Auth: 3MU58UQ0Q5GknuEBwkVfVMxchZw
Message-ID: <CAOvdn6VDAJZw6hYAvZ-1CmEg8Ts0-0PB4gVUX4nq2ap=gO0VVQ@mail.gmail.com>
From: Ben Guthro <ben@guthro.net>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Konrad Rzeszutek <konrad@darnok.org>,
	Xen Devel <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] debugging 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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Yes, it helped a lot!
This seems to have resolved the hang - thanks for pointing it my way!

So - if I'm reading the git log correctly, I should just have to
cherry-pick 7a7546b377bdaa25ac77f33d9433c59f259b9688 from mainline?

It seems like this may be something to CC the -stable queue on, IMHO.

On Mon, Jan 30, 2012 at 11:34 AM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 30/01/12 16:27, Ben Guthro wrote:
>> Konrad, et al.
>>
>> I'm having an issue with my guests that, when I am running wireless
>> drivers in dom0, and the PV-on-HVM guest tries to access the network -
>> I get a hung dom0.
>>
>> When I turn on
>> Kernel Hacking->
>> Spinlock and rw-lock debugging: basic checks
>>
>> The hang goes away, but does not print out anything terribly useful in
>> the serial log.
>>
>>
>> The config file =A0changes made by this menuconfig setting can be found =
below:
>>
>>
>> While I know from other conversations, that Konrad is aware of my
>> setup, for other's benefit - this is a 64bit dom0 3.2.2 kernel, with a
>> few of his branches pulled in.
>>
>> Any thoughts, or suggestions on how best to debug these deadlocks
>> would be greatly appreciated.
>
> It looks like
> http://lists.xen.org/archives/html/xen-devel/2012-01/msg01917.html might
> apply to you.
>
> Does that patch help?
>
> ~Andrew
>
>>
>> -Ben Guthro
>>
>>
>> diff --git a/configs/config.ubuntu.amd64 b/configs/config.ubuntu.amd64
>> index 205b5c6..f7a233f 100644
>> --- a/configs/config.ubuntu.amd64
>> +++ b/configs/config.ubuntu.amd64
>> @@ -257,27 +257,27 @@ CONFIG_PADATA=3Dy
>> =A0# CONFIG_INLINE_SPIN_LOCK_BH is not set
>> =A0# CONFIG_INLINE_SPIN_LOCK_IRQ is not set
>> =A0# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set
>> -CONFIG_INLINE_SPIN_UNLOCK=3Dy
>> +# CONFIG_INLINE_SPIN_UNLOCK is not set
>> =A0# CONFIG_INLINE_SPIN_UNLOCK_BH is not set
>> -CONFIG_INLINE_SPIN_UNLOCK_IRQ=3Dy
>> +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set
>> =A0# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set
>> =A0# CONFIG_INLINE_READ_TRYLOCK is not set
>> =A0# CONFIG_INLINE_READ_LOCK is not set
>> =A0# CONFIG_INLINE_READ_LOCK_BH is not set
>> =A0# CONFIG_INLINE_READ_LOCK_IRQ is not set
>> =A0# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set
>> -CONFIG_INLINE_READ_UNLOCK=3Dy
>> +# CONFIG_INLINE_READ_UNLOCK is not set
>> =A0# CONFIG_INLINE_READ_UNLOCK_BH is not set
>> -CONFIG_INLINE_READ_UNLOCK_IRQ=3Dy
>> +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set
>> =A0# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set
>> =A0# CONFIG_INLINE_WRITE_TRYLOCK is not set
>> =A0# CONFIG_INLINE_WRITE_LOCK is not set
>> =A0# CONFIG_INLINE_WRITE_LOCK_BH is not set
>> =A0# CONFIG_INLINE_WRITE_LOCK_IRQ is not set
>> =A0# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set
>> -CONFIG_INLINE_WRITE_UNLOCK=3Dy
>> +# CONFIG_INLINE_WRITE_UNLOCK is not set
>> =A0# CONFIG_INLINE_WRITE_UNLOCK_BH is not set
>> -CONFIG_INLINE_WRITE_UNLOCK_IRQ=3Dy
>> +# CONFIG_INLINE_WRITE_UNLOCK_IRQ is not set
>> =A0# CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set
>> =A0CONFIG_MUTEX_SPIN_ON_OWNER=3Dy
>> =A0CONFIG_FREEZER=3Dy
>> @@ -398,7 +398,7 @@ CONFIG_HAVE_MEMBLOCK_NODE_MAP=3Dy
>> =A0CONFIG_ARCH_DISCARD_MEMBLOCK=3Dy
>> =A0# CONFIG_MEMORY_HOTPLUG is not set
>> =A0CONFIG_PAGEFLAGS_EXTENDED=3Dy
>> -CONFIG_SPLIT_PTLOCK_CPUS=3D4
>> +CONFIG_SPLIT_PTLOCK_CPUS=3D999999
>> =A0# CONFIG_COMPACTION is not set
>> =A0CONFIG_MIGRATION=3Dy
>> =A0CONFIG_PHYS_ADDR_T_64BIT=3Dy
>> @@ -4255,7 +4255,7 @@ CONFIG_TIMER_STATS=3Dy
>> =A0# CONFIG_DEBUG_KMEMLEAK is not set
>> =A0# CONFIG_DEBUG_RT_MUTEXES is not set
>> =A0# CONFIG_RT_MUTEX_TESTER is not set
>> -# CONFIG_DEBUG_SPINLOCK is not set
>> +CONFIG_DEBUG_SPINLOCK=3Dy
>> =A0# CONFIG_DEBUG_MUTEXES is not set
>> =A0# CONFIG_DEBUG_LOCK_ALLOC is not set
>> =A0# CONFIG_PROVE_LOCKING is not set
>>
>> _______________________________________________
>> 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 Mon Jan 30 17:41:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17: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 1RrvE1-0002Ha-0P; Mon, 30 Jan 2012 17:41:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RrvDy-0002H4-Kg; Mon, 30 Jan 2012 17:41:02 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327945256!12758802!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15390 invoked from network); 30 Jan 2012 17:40:56 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 17:40:56 -0000
Received: by wibhm2 with SMTP id hm2so13903614wib.30
	for <multiple recipients>; Mon, 30 Jan 2012 09:40:56 -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=3eS4W6WIaFr3/jC7AeKPyccItVrM456yFV3c9tWLBlM=;
	b=qKufBF45faylbunPPZKBP1e0RI3wbVDfxAc97mj4tD7zFt8unbto2Nh4S0QyNZLpCb
	5z8oWRp29XflurFnGZ1aiIQOOR5mrWfR/TfWUAVDK5rnCvx2CA7rt/1tSvr2m/c32fO0
	jnaj/jn/erU/OJmu87QeUe9gE+WBPojDgFTJU=
Received: by 10.180.101.35 with SMTP id fd3mr28778168wib.22.1327945255985;
	Mon, 30 Jan 2012 09:40:55 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id fr8sm54429106wib.10.2012.01.30.09.40.53
	(version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 09:40:54 -0800 (PST)
Message-ID: <4F26D60F.2090307@xen.org>
Date: Mon, 30 Jan 2012 17:40:31 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>
Subject: [Xen-devel] Please welcome Ian Campbell as Committer for Xen
 Hypervisor Project (ARMv7+VE)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5452725129398775358=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============5452725129398775358==
Content-Type: multipart/alternative;
 boundary="------------080506040302050102000004"

This is a multi-part message in MIME format.
--------------080506040302050102000004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Xen Developers,

I wanted to announce that Ian Campbell from Citrix has been nominated 
and elected as Xen Hypervisor committer 
<http://lists.xen.org/archives/html/xen-devel/2012-01/msg02281.html> and 
will be responsible for the ARMv7+VE components in xen-unstable. We have 
seen an increasing number of patches to xen-unstable to enable support 
for the ARMv7 processor with virtualization extensions: 64 to be 
precise. So far, the Xen ARM port in xen-unstable is capable of booting 
a Linux 3.0 based virtual machine (dom0).

Ian has made a tremendous contribution to the project on which he worked 
almost since its creation. Ian was was one of the top contributors to 
the project for the last few years. Let me quote a few stats:

*2010:* 203 patches, changing 13101 lines of code
*2011:* 305 patches, changing 12225 lines of code

Ian also put together a build farm for the project that utilizes 10 
Freescale i.MX53 Loco Quickstart boards. Besides working on the 
Hypervisor, Ian has also made significant contributions to the PVOPS 
project <http://wiki.xen.org/wiki/XenParavirtOps>.

*Congratulations Ian!
*

Best Regards
Lars


--------------080506040302050102000004
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">
    <p>Dear Xen Developers,</p>
    <p>I wanted to announce that Ian Campbell from Citrix has been <a
href="http://lists.xen.org/archives/html/xen-devel/2012-01/msg02281.html">nominated
        and elected as Xen Hypervisor committer</a> and will be
      responsible for the ARMv7+VE components in xen-unstable. We have
      seen an increasing number of patches to xen-unstable to enable
      support for the ARMv7 processor with virtualization extensions: 64
      to be precise. So far, the Xen ARM port in xen-unstable is capable
      of booting a Linux 3.0 based virtual machine (dom0).</p>
    <p>Ian has made a tremendous contribution to the project on which he
      worked almost since its creation. Ian was was one of the top
      contributors to the project for the last few years.&nbsp;Let me quote a
      few stats:</p>
    <p><strong>2010:</strong> 203 patches, changing 13101 lines of code<br>
      <strong>2011:</strong> 305 patches, changing 12225 lines of code</p>
    <p>Ian also put together a build farm for the project that utilizes
      10 Freescale i.MX53 Loco Quickstart boards. Besides working on the
      Hypervisor, Ian has also made significant contributions to the <a
        href="http://wiki.xen.org/wiki/XenParavirtOps">PVOPS project</a>.</p>
    <p><strong>Congratulations Ian!<br>
      </strong></p>
    <p>Best Regards<br>
      Lars<br>
    </p>
  </body>
</html>

--------------080506040302050102000004--


--===============5452725129398775358==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5452725129398775358==--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 17:41:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 17: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 1RrvE1-0002Ha-0P; Mon, 30 Jan 2012 17:41:05 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RrvDy-0002H4-Kg; Mon, 30 Jan 2012 17:41:02 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1327945256!12758802!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15390 invoked from network); 30 Jan 2012 17:40:56 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-5.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 17:40:56 -0000
Received: by wibhm2 with SMTP id hm2so13903614wib.30
	for <multiple recipients>; Mon, 30 Jan 2012 09:40:56 -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=3eS4W6WIaFr3/jC7AeKPyccItVrM456yFV3c9tWLBlM=;
	b=qKufBF45faylbunPPZKBP1e0RI3wbVDfxAc97mj4tD7zFt8unbto2Nh4S0QyNZLpCb
	5z8oWRp29XflurFnGZ1aiIQOOR5mrWfR/TfWUAVDK5rnCvx2CA7rt/1tSvr2m/c32fO0
	jnaj/jn/erU/OJmu87QeUe9gE+WBPojDgFTJU=
Received: by 10.180.101.35 with SMTP id fd3mr28778168wib.22.1327945255985;
	Mon, 30 Jan 2012 09:40:55 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id fr8sm54429106wib.10.2012.01.30.09.40.53
	(version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 09:40:54 -0800 (PST)
Message-ID: <4F26D60F.2090307@xen.org>
Date: Mon, 30 Jan 2012 17:40:31 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>,
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>
Subject: [Xen-devel] Please welcome Ian Campbell as Committer for Xen
 Hypervisor Project (ARMv7+VE)
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5452725129398775358=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============5452725129398775358==
Content-Type: multipart/alternative;
 boundary="------------080506040302050102000004"

This is a multi-part message in MIME format.
--------------080506040302050102000004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Xen Developers,

I wanted to announce that Ian Campbell from Citrix has been nominated 
and elected as Xen Hypervisor committer 
<http://lists.xen.org/archives/html/xen-devel/2012-01/msg02281.html> and 
will be responsible for the ARMv7+VE components in xen-unstable. We have 
seen an increasing number of patches to xen-unstable to enable support 
for the ARMv7 processor with virtualization extensions: 64 to be 
precise. So far, the Xen ARM port in xen-unstable is capable of booting 
a Linux 3.0 based virtual machine (dom0).

Ian has made a tremendous contribution to the project on which he worked 
almost since its creation. Ian was was one of the top contributors to 
the project for the last few years. Let me quote a few stats:

*2010:* 203 patches, changing 13101 lines of code
*2011:* 305 patches, changing 12225 lines of code

Ian also put together a build farm for the project that utilizes 10 
Freescale i.MX53 Loco Quickstart boards. Besides working on the 
Hypervisor, Ian has also made significant contributions to the PVOPS 
project <http://wiki.xen.org/wiki/XenParavirtOps>.

*Congratulations Ian!
*

Best Regards
Lars


--------------080506040302050102000004
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">
    <p>Dear Xen Developers,</p>
    <p>I wanted to announce that Ian Campbell from Citrix has been <a
href="http://lists.xen.org/archives/html/xen-devel/2012-01/msg02281.html">nominated
        and elected as Xen Hypervisor committer</a> and will be
      responsible for the ARMv7+VE components in xen-unstable. We have
      seen an increasing number of patches to xen-unstable to enable
      support for the ARMv7 processor with virtualization extensions: 64
      to be precise. So far, the Xen ARM port in xen-unstable is capable
      of booting a Linux 3.0 based virtual machine (dom0).</p>
    <p>Ian has made a tremendous contribution to the project on which he
      worked almost since its creation. Ian was was one of the top
      contributors to the project for the last few years.&nbsp;Let me quote a
      few stats:</p>
    <p><strong>2010:</strong> 203 patches, changing 13101 lines of code<br>
      <strong>2011:</strong> 305 patches, changing 12225 lines of code</p>
    <p>Ian also put together a build farm for the project that utilizes
      10 Freescale i.MX53 Loco Quickstart boards. Besides working on the
      Hypervisor, Ian has also made significant contributions to the <a
        href="http://wiki.xen.org/wiki/XenParavirtOps">PVOPS project</a>.</p>
    <p><strong>Congratulations Ian!<br>
      </strong></p>
    <p>Best Regards<br>
      Lars<br>
    </p>
  </body>
</html>

--------------080506040302050102000004--


--===============5452725129398775358==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5452725129398775358==--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:04:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrva6-00036v-Rt; Mon, 30 Jan 2012 18:03:54 +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 1Rrva5-00036m-Ab
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:03:53 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327946624!12985675!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5361 invoked from network); 30 Jan 2012 18:03:46 -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; 30 Jan 2012 18:03:46 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0UI3fNg012936
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 30 Jan 2012 10:03:42 -0800
Received: by bkar1 with SMTP id r1so7502547bka.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 10:03:39 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr8831278bkc.13.1327946619716; Mon,
	30 Jan 2012 10:03:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Mon, 30 Jan 2012 10:02:56 -0800 (PST)
In-Reply-To: <1327942455-23587-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-2-git-send-email-stefano.stabellini@eu.citrix.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 30 Jan 2012 10:02:56 -0800
Message-ID: <CAP8mzPMcvs4gD1eTik7HYmjnYBFvzswh2gCOQoiRufgOeHfUCw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 2/2] libxl: save/restore qemu's physmap
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="===============1863908327525484614=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1863908327525484614==
Content-Type: multipart/alternative; boundary=000e0ce040448c852104b7c2aaf8

--000e0ce040448c852104b7c2aaf8
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> +
> +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> +        uint32_t size, void *data)
> +{
> +    libxl__gc *gc = (libxl__gc *) data;
> +    int i, ret;
> +    uint8_t *ptr = buf;
> +    uint32_t count = 0, version = 0;
> +    struct libxl__physmap_info* pi;
> +
> +    if (size < sizeof(version) + sizeof(count))
> +        return -1;
> +
> +    memcpy(&version, ptr, sizeof(version));
> +    ptr += sizeof(version);
> +
> +    if (version != TOOLSTACK_SAVE_VERSION)
> +        return -1;
> +
> +    memcpy(&count, ptr, sizeof(count));
> +    ptr += sizeof(count);
> +
> +    if (size < sizeof(version) + sizeof(count) +
> +            count * (sizeof(struct libxl__physmap_info)))
> +        return -1;
> +
> +    for (i = 0; i < count; i++) {
> +        pi = (struct libxl__physmap_info*) ptr;
> +        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
> +
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +
>  "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
> +                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
> +        if (ret)
> +            return -1;
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +
>  "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +                    domid, pi->phys_offset), "%"PRIx64, pi->size);
> +        if (ret)
> +            return -1;
> +        if (pi->namelen > 0) {
> +            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +
>  "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
> +                        domid, pi->phys_offset), "%s", pi->name);
> +            if (ret)
> +                return -1;
> +        }
> +    }
> +    return 0;
> +}
> +
>


Sorry if this sounds silly. Is the save/restore of Qemu Physmap equivalent
to
save/restore of the Qemu Device Model ?

--000e0ce040448c852104b7c2aaf8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabell=
ini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.co=
m">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

+<br>
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,<br>
+ =A0 =A0 =A0 =A0uint32_t size, void *data)<br>
+{<br>
+ =A0 =A0libxl__gc *gc =3D (libxl__gc *) data;<br>
+ =A0 =A0int i, ret;<br>
+ =A0 =A0uint8_t *ptr =3D buf;<br>
+ =A0 =A0uint32_t count =3D 0, version =3D 0;<br>
+ =A0 =A0struct libxl__physmap_info* pi;<br>
+<br>
+ =A0 =A0if (size &lt; sizeof(version) + sizeof(count))<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0memcpy(&amp;version, ptr, sizeof(version));<br>
+ =A0 =A0ptr +=3D sizeof(version);<br>
+<br>
+ =A0 =A0if (version !=3D TOOLSTACK_SAVE_VERSION)<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0memcpy(&amp;count, ptr, sizeof(count));<br>
+ =A0 =A0ptr +=3D sizeof(count);<br>
+<br>
+ =A0 =A0if (size &lt; sizeof(version) + sizeof(count) +<br>
+ =A0 =A0 =A0 =A0 =A0 =A0count * (sizeof(struct libxl__physmap_info)))<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0for (i =3D 0; i &lt; count; i++) {<br>
+ =A0 =A0 =A0 =A0pi =3D (struct libxl__physmap_info*) ptr;<br>
+ =A0 =A0 =A0 =A0ptr +=3D sizeof(struct libxl__physmap_info) + pi-&gt;namel=
en;<br>
+<br>
+ =A0 =A0 =A0 =A0ret =3D libxl__xs_write(gc, 0, libxl__sprintf(gc,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;/local/domain/0/device-model=
/%d/physmap/%&quot;PRIx64&quot;/start_addr&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid, pi-&gt;phys_offset), &quot;=
%&quot;PRIx64, pi-&gt;start_addr);<br>
+ =A0 =A0 =A0 =A0if (ret)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0ret =3D libxl__xs_write(gc, 0, libxl__sprintf(gc,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;/local/domain/0/device-model=
/%d/physmap/%&quot;PRIx64&quot;/size&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid, pi-&gt;phys_offset), &quot;=
%&quot;PRIx64, pi-&gt;size);<br>
+ =A0 =A0 =A0 =A0if (ret)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0if (pi-&gt;namelen &gt; 0) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0ret =3D libxl__xs_write(gc, 0, libxl__sprintf(gc,<=
br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;/local/domain/0/devi=
ce-model/%d/physmap/%&quot;PRIx64&quot;/name&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid, pi-&gt;phys_offset)=
, &quot;%s&quot;, pi-&gt;name);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if (ret)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0}<br>
+ =A0 =A0return 0;<br>
+}<br>
+<br></blockquote></div><br><br>Sorry if this sounds silly. Is the save/res=
tore of Qemu Physmap equivalent to<br>save/restore of the Qemu Device Model=
 ?<br>

--000e0ce040448c852104b7c2aaf8--


--===============1863908327525484614==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1863908327525484614==--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:04:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:04:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrva6-00036v-Rt; Mon, 30 Jan 2012 18:03:54 +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 1Rrva5-00036m-Ab
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:03:53 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-182.messagelabs.com!1327946624!12985675!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5361 invoked from network); 30 Jan 2012 18:03:46 -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; 30 Jan 2012 18:03:46 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0UI3fNg012936
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 30 Jan 2012 10:03:42 -0800
Received: by bkar1 with SMTP id r1so7502547bka.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 10:03:39 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr8831278bkc.13.1327946619716; Mon,
	30 Jan 2012 10:03:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Mon, 30 Jan 2012 10:02:56 -0800 (PST)
In-Reply-To: <1327942455-23587-2-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-2-git-send-email-stefano.stabellini@eu.citrix.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 30 Jan 2012 10:02:56 -0800
Message-ID: <CAP8mzPMcvs4gD1eTik7HYmjnYBFvzswh2gCOQoiRufgOeHfUCw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 2/2] libxl: save/restore qemu's physmap
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="===============1863908327525484614=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============1863908327525484614==
Content-Type: multipart/alternative; boundary=000e0ce040448c852104b7c2aaf8

--000e0ce040448c852104b7c2aaf8
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> +
> +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
> +        uint32_t size, void *data)
> +{
> +    libxl__gc *gc = (libxl__gc *) data;
> +    int i, ret;
> +    uint8_t *ptr = buf;
> +    uint32_t count = 0, version = 0;
> +    struct libxl__physmap_info* pi;
> +
> +    if (size < sizeof(version) + sizeof(count))
> +        return -1;
> +
> +    memcpy(&version, ptr, sizeof(version));
> +    ptr += sizeof(version);
> +
> +    if (version != TOOLSTACK_SAVE_VERSION)
> +        return -1;
> +
> +    memcpy(&count, ptr, sizeof(count));
> +    ptr += sizeof(count);
> +
> +    if (size < sizeof(version) + sizeof(count) +
> +            count * (sizeof(struct libxl__physmap_info)))
> +        return -1;
> +
> +    for (i = 0; i < count; i++) {
> +        pi = (struct libxl__physmap_info*) ptr;
> +        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
> +
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +
>  "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
> +                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
> +        if (ret)
> +            return -1;
> +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +
>  "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +                    domid, pi->phys_offset), "%"PRIx64, pi->size);
> +        if (ret)
> +            return -1;
> +        if (pi->namelen > 0) {
> +            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
> +
>  "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
> +                        domid, pi->phys_offset), "%s", pi->name);
> +            if (ret)
> +                return -1;
> +        }
> +    }
> +    return 0;
> +}
> +
>


Sorry if this sounds silly. Is the save/restore of Qemu Physmap equivalent
to
save/restore of the Qemu Device Model ?

--000e0ce040448c852104b7c2aaf8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabell=
ini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.co=
m">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

+<br>
+static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,<br>
+ =A0 =A0 =A0 =A0uint32_t size, void *data)<br>
+{<br>
+ =A0 =A0libxl__gc *gc =3D (libxl__gc *) data;<br>
+ =A0 =A0int i, ret;<br>
+ =A0 =A0uint8_t *ptr =3D buf;<br>
+ =A0 =A0uint32_t count =3D 0, version =3D 0;<br>
+ =A0 =A0struct libxl__physmap_info* pi;<br>
+<br>
+ =A0 =A0if (size &lt; sizeof(version) + sizeof(count))<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0memcpy(&amp;version, ptr, sizeof(version));<br>
+ =A0 =A0ptr +=3D sizeof(version);<br>
+<br>
+ =A0 =A0if (version !=3D TOOLSTACK_SAVE_VERSION)<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0memcpy(&amp;count, ptr, sizeof(count));<br>
+ =A0 =A0ptr +=3D sizeof(count);<br>
+<br>
+ =A0 =A0if (size &lt; sizeof(version) + sizeof(count) +<br>
+ =A0 =A0 =A0 =A0 =A0 =A0count * (sizeof(struct libxl__physmap_info)))<br>
+ =A0 =A0 =A0 =A0return -1;<br>
+<br>
+ =A0 =A0for (i =3D 0; i &lt; count; i++) {<br>
+ =A0 =A0 =A0 =A0pi =3D (struct libxl__physmap_info*) ptr;<br>
+ =A0 =A0 =A0 =A0ptr +=3D sizeof(struct libxl__physmap_info) + pi-&gt;namel=
en;<br>
+<br>
+ =A0 =A0 =A0 =A0ret =3D libxl__xs_write(gc, 0, libxl__sprintf(gc,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;/local/domain/0/device-model=
/%d/physmap/%&quot;PRIx64&quot;/start_addr&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid, pi-&gt;phys_offset), &quot;=
%&quot;PRIx64, pi-&gt;start_addr);<br>
+ =A0 =A0 =A0 =A0if (ret)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0ret =3D libxl__xs_write(gc, 0, libxl__sprintf(gc,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;/local/domain/0/device-model=
/%d/physmap/%&quot;PRIx64&quot;/size&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid, pi-&gt;phys_offset), &quot;=
%&quot;PRIx64, pi-&gt;size);<br>
+ =A0 =A0 =A0 =A0if (ret)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0if (pi-&gt;namelen &gt; 0) {<br>
+ =A0 =A0 =A0 =A0 =A0 =A0ret =3D libxl__xs_write(gc, 0, libxl__sprintf(gc,<=
br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&quot;/local/domain/0/devi=
ce-model/%d/physmap/%&quot;PRIx64&quot;/name&quot;,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0domid, pi-&gt;phys_offset)=
, &quot;%s&quot;, pi-&gt;name);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if (ret)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0}<br>
+ =A0 =A0return 0;<br>
+}<br>
+<br></blockquote></div><br><br>Sorry if this sounds silly. Is the save/res=
tore of Qemu Physmap equivalent to<br>save/restore of the Qemu Device Model=
 ?<br>

--000e0ce040448c852104b7c2aaf8--


--===============1863908327525484614==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============1863908327525484614==--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:05:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrvbU-0003BO-B2; Mon, 30 Jan 2012 18:05:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RrvbS-0003BC-UN
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:05:19 +0000
Received: from [85.158.138.51:9685] by server-7.bemta-3.messagelabs.com id
	78/9C-31267-EDBD62F4; Mon, 30 Jan 2012 18:05:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327946717!11269157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26175 invoked from network); 30 Jan 2012 18:05: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;
	30 Jan 2012 18:05:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10373120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 18:05: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; Mon, 30 Jan 2012 18:05:16 +0000
Date: Mon, 30 Jan 2012 18:06:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPMcvs4gD1eTik7HYmjnYBFvzswh2gCOQoiRufgOeHfUCw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201301806200.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMcvs4gD1eTik7HYmjnYBFvzswh2gCOQoiRufgOeHfUCw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1202080671-1327946825=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1202080671-1327946825=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
> On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>       +
>       +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
>       +        uint32_t size, void *data)
>       +{
>       +    libxl__gc *gc = (libxl__gc *) data;
>       +    int i, ret;
>       +    uint8_t *ptr = buf;
>       +    uint32_t count = 0, version = 0;
>       +    struct libxl__physmap_info* pi;
>       +
>       +    if (size < sizeof(version) + sizeof(count))
>       +        return -1;
>       +
>       +    memcpy(&version, ptr, sizeof(version));
>       +    ptr += sizeof(version);
>       +
>       +    if (version != TOOLSTACK_SAVE_VERSION)
>       +        return -1;
>       +
>       +    memcpy(&count, ptr, sizeof(count));
>       +    ptr += sizeof(count);
>       +
>       +    if (size < sizeof(version) + sizeof(count) +
>       +            count * (sizeof(struct libxl__physmap_info)))
>       +        return -1;
>       +
>       +    for (i = 0; i < count; i++) {
>       +        pi = (struct libxl__physmap_info*) ptr;
>       +        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
>       +
>       +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
>       +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
>       +                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
>       +        if (ret)
>       +            return -1;
>       +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
>       +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
>       +                    domid, pi->phys_offset), "%"PRIx64, pi->size);
>       +        if (ret)
>       +            return -1;
>       +        if (pi->namelen > 0) {
>       +            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
>       +                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
>       +                        domid, pi->phys_offset), "%s", pi->name);
>       +            if (ret)
>       +                return -1;
>       +        }
>       +    }
>       +    return 0;
>       +}
>       +
> 
> 
> 
> Sorry if this sounds silly. Is the save/restore of Qemu Physmap equivalent to
> save/restore of the Qemu Device Model ?

Nope, it is in addition to the save/restore of the QEMU device state.
--8323329-1202080671-1327946825=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1202080671-1327946825=:3196--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:05:41 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:05:41 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrvbU-0003BO-B2; Mon, 30 Jan 2012 18:05:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RrvbS-0003BC-UN
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:05:19 +0000
Received: from [85.158.138.51:9685] by server-7.bemta-3.messagelabs.com id
	78/9C-31267-EDBD62F4; Mon, 30 Jan 2012 18:05:18 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327946717!11269157!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26175 invoked from network); 30 Jan 2012 18:05: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;
	30 Jan 2012 18:05:17 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10373120"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 18:05: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; Mon, 30 Jan 2012 18:05:16 +0000
Date: Mon, 30 Jan 2012 18:06:50 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPMcvs4gD1eTik7HYmjnYBFvzswh2gCOQoiRufgOeHfUCw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201301806200.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMcvs4gD1eTik7HYmjnYBFvzswh2gCOQoiRufgOeHfUCw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1202080671-1327946825=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 2/2] libxl: save/restore qemu's physmap
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1202080671-1327946825=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
> On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>       +
>       +static int libxl__toolstack_restore(uint32_t domid, uint8_t *buf,
>       +        uint32_t size, void *data)
>       +{
>       +    libxl__gc *gc = (libxl__gc *) data;
>       +    int i, ret;
>       +    uint8_t *ptr = buf;
>       +    uint32_t count = 0, version = 0;
>       +    struct libxl__physmap_info* pi;
>       +
>       +    if (size < sizeof(version) + sizeof(count))
>       +        return -1;
>       +
>       +    memcpy(&version, ptr, sizeof(version));
>       +    ptr += sizeof(version);
>       +
>       +    if (version != TOOLSTACK_SAVE_VERSION)
>       +        return -1;
>       +
>       +    memcpy(&count, ptr, sizeof(count));
>       +    ptr += sizeof(count);
>       +
>       +    if (size < sizeof(version) + sizeof(count) +
>       +            count * (sizeof(struct libxl__physmap_info)))
>       +        return -1;
>       +
>       +    for (i = 0; i < count; i++) {
>       +        pi = (struct libxl__physmap_info*) ptr;
>       +        ptr += sizeof(struct libxl__physmap_info) + pi->namelen;
>       +
>       +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
>       +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
>       +                    domid, pi->phys_offset), "%"PRIx64, pi->start_addr);
>       +        if (ret)
>       +            return -1;
>       +        ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
>       +                    "/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
>       +                    domid, pi->phys_offset), "%"PRIx64, pi->size);
>       +        if (ret)
>       +            return -1;
>       +        if (pi->namelen > 0) {
>       +            ret = libxl__xs_write(gc, 0, libxl__sprintf(gc,
>       +                        "/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
>       +                        domid, pi->phys_offset), "%s", pi->name);
>       +            if (ret)
>       +                return -1;
>       +        }
>       +    }
>       +    return 0;
>       +}
>       +
> 
> 
> 
> Sorry if this sounds silly. Is the save/restore of Qemu Physmap equivalent to
> save/restore of the Qemu Device Model ?

Nope, it is in addition to the save/restore of the QEMU device state.
--8323329-1202080671-1327946825=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1202080671-1327946825=:3196--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:27:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrvwR-0003qz-VM; Mon, 30 Jan 2012 18:26:59 +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 1RrvwQ-0003qu-Ps
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:26:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327948012!5566744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26529 invoked from network); 30 Jan 2012 18:26:52 -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;
	30 Jan 2012 18:26:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10373360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 18:26:52 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 18:26:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120129213746.GA7164@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
	<20120129213746.GA7164@phenom.dumpdata.com>
Date: Mon, 30 Jan 2012 18:27:04 +0000
Message-ID: <1327948024.5553.43.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-01-29 at 21:37 +0000, Konrad Rzeszutek Wilk wrote:
> 
> Sure. I also did some testing with limiting the amount of CPUs and found
> that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> > 
> > 

I just played with vcpu-set a bit, and I can reproduced this problem.
That's a race condition.

One possible fix is remove cond_resched() in the kernel thread. After
removing that, it fixes the problem (at least for me).


Wei.

--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -994,7 +994,7 @@ int xenvif_kthread(void *data)
                wait_event_interruptible(vif->wq,
                                         rx_work_todo(vif) ||
                                         kthread_should_stop());
-               cond_resched();
+               /* cond_resched(); */
 
                if (kthread_should_stop())
                        break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:27:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:27:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrvwR-0003qz-VM; Mon, 30 Jan 2012 18:26:59 +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 1RrvwQ-0003qu-Ps
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:26:59 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-182.messagelabs.com!1327948012!5566744!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26529 invoked from network); 30 Jan 2012 18:26:52 -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;
	30 Jan 2012 18:26:52 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10373360"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 18:26:52 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 18:26:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120129213746.GA7164@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
	<20120129213746.GA7164@phenom.dumpdata.com>
Date: Mon, 30 Jan 2012 18:27:04 +0000
Message-ID: <1327948024.5553.43.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-01-29 at 21:37 +0000, Konrad Rzeszutek Wilk wrote:
> 
> Sure. I also did some testing with limiting the amount of CPUs and found
> that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> > 
> > 

I just played with vcpu-set a bit, and I can reproduced this problem.
That's a race condition.

One possible fix is remove cond_resched() in the kernel thread. After
removing that, it fixes the problem (at least for me).


Wei.

--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -994,7 +994,7 @@ int xenvif_kthread(void *data)
                wait_event_interruptible(vif->wq,
                                         rx_work_todo(vif) ||
                                         kthread_should_stop());
-               cond_resched();
+               /* cond_resched(); */
 
                if (kthread_should_stop())
                        break;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:31:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrw01-00040u-Qw; Mon, 30 Jan 2012 18:30:41 +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 1Rrw00-00040b-1w
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:30:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327948229!2831728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25993 invoked from network); 30 Jan 2012 18:30:30 -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;
	30 Jan 2012 18:30:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10373401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 18:30:29 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 18:30:29 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1327948024.5553.43.camel@leeds.uk.xensource.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
	<20120129213746.GA7164@phenom.dumpdata.com>
	<1327948024.5553.43.camel@leeds.uk.xensource.com>
Date: Mon, 30 Jan 2012 18:30:41 +0000
Message-ID: <1327948241.5553.44.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 18:27 +0000, Wei Liu (Intern) wrote:
> On Sun, 2012-01-29 at 21:37 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> > Sure. I also did some testing with limiting the amount of CPUs and found
> > that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> > > 
> > > 
> 
> I just played with vcpu-set a bit, and I can reproduced this problem.
> That's a race condition.
> 
> One possible fix is remove cond_resched() in the kernel thread. After
> removing that, it fixes the problem (at least for me).
> 
> 
> Wei.
> 
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -994,7 +994,7 @@ int xenvif_kthread(void *data)
>                 wait_event_interruptible(vif->wq,
>                                          rx_work_todo(vif) ||
>                                          kthread_should_stop());
> -               cond_resched();
> +               /* cond_resched(); */
>  
>                 if (kthread_should_stop())
>                         break;
> 
> 

Hmm... Here it comes again. Ignore this fix. It's more complicated than
I thought.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:31:00 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:31:00 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrw01-00040u-Qw; Mon, 30 Jan 2012 18:30:41 +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 1Rrw00-00040b-1w
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:30:40 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-21.messagelabs.com!1327948229!2831728!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25993 invoked from network); 30 Jan 2012 18:30:30 -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;
	30 Jan 2012 18:30:30 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10373401"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 18:30:29 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 18:30:29 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <1327948024.5553.43.camel@leeds.uk.xensource.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
	<20120129213746.GA7164@phenom.dumpdata.com>
	<1327948024.5553.43.camel@leeds.uk.xensource.com>
Date: Mon, 30 Jan 2012 18:30:41 +0000
Message-ID: <1327948241.5553.44.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 18:27 +0000, Wei Liu (Intern) wrote:
> On Sun, 2012-01-29 at 21:37 +0000, Konrad Rzeszutek Wilk wrote:
> > 
> > Sure. I also did some testing with limiting the amount of CPUs and found
> > that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> > > 
> > > 
> 
> I just played with vcpu-set a bit, and I can reproduced this problem.
> That's a race condition.
> 
> One possible fix is remove cond_resched() in the kernel thread. After
> removing that, it fixes the problem (at least for me).
> 
> 
> Wei.
> 
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -994,7 +994,7 @@ int xenvif_kthread(void *data)
>                 wait_event_interruptible(vif->wq,
>                                          rx_work_todo(vif) ||
>                                          kthread_should_stop());
> -               cond_resched();
> +               /* cond_resched(); */
>  
>                 if (kthread_should_stop())
>                         break;
> 
> 

Hmm... Here it comes again. Ignore this fix. It's more complicated than
I thought.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:43:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:43:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrwBo-0004Dv-4o; Mon, 30 Jan 2012 18:42:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RrwBm-0004Dq-Ji
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:42:51 +0000
Received: from [85.158.138.51:35206] by server-10.bemta-3.messagelabs.com id
	2B/BD-20948-9A4E62F4; Mon, 30 Jan 2012 18:42:49 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327948965!9437890!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10479 invoked from network); 30 Jan 2012 18:42:47 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 18:42:47 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0UIgfFr020316
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 30 Jan 2012 10:42:43 -0800
Received: by bkar1 with SMTP id r1so7577299bka.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 10:42:40 -0800 (PST)
Received: by 10.205.118.4 with SMTP id fo4mr8824110bkc.139.1327948960519; Mon,
	30 Jan 2012 10:42:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Mon, 30 Jan 2012 10:41:59 -0800 (PST)
In-Reply-To: <1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 30 Jan 2012 10:41:59 -0800
Message-ID: <CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============3706926105776435607=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3706926105776435607==
Content-Type: multipart/alternative; boundary=000e0ce0046412561504b7c33629

--000e0ce0046412561504b7c33629
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> Introduce a new save_id to save/restore toolstack specific extra
> information.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxc/xc_domain_restore.c |   32 +++++++++++++++++++++++++++++++-
>  tools/libxc/xc_domain_save.c    |   17 +++++++++++++++++
>  tools/libxc/xenguest.h          |   23 ++++++++++++++++++++++-
>  tools/libxc/xg_save_restore.h   |    1 +
>  tools/libxl/libxl_dom.c         |    2 +-
>  tools/xcutils/xc_restore.c      |    2 +-
>  6 files changed, 73 insertions(+), 4 deletions(-)
>
> diff --git a/tools/libxc/xc_domain_restore.c
> b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..ead3df4 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -45,6 +45,8 @@ struct restore_ctx {
>     int last_checkpoint; /* Set when we should commit to the current
> checkpoint when it completes. */
>     int compressing; /* Set when sender signals that pages would be sent
> compressed (for Remus) */
>     struct domain_info_context dinfo;
> +    uint8_t *toolstack_data;
> +    uint32_t toolstack_data_len;
>  };
>
>
This is still leaking speculative state. You have only moved the restore
code but
you are still reading the (potentially discardable) state into a global ctx
structure.

Take a look at the tailbuf code right below the pagebuf_get() call in
xc_domain_restore().
It reads the tailbuf onto a temporary buffer and then copies it onto the
main one.
This way, if an error occurs while receiving data, one can completely
discard the current
checkpoint (pagebuf & tmptailbuf) and restore from the previous one
(tailbuf).

You could have a similar *consistent buffer* in the xc_domain_restore
function itself, and copy the toolstack
stuff into it before starting to buffer a new checkpoint. Perhaps something
like the snippet below?

+ toolstack_data = realloc(pagebuf.toolstack_data_len)
+ memcpy(toolstack_data, pagebuf.toolstack_data,
pagebuf.toolstack_data_len);
if ( ctx->last_checkpoint )

Though, this would incur two reallocs (once in pagebuf_get and once more in
the main loop).

If there is a maximum size for this buffer, I would suggest mallocing it
once and for all, and just
memcpy it.


@@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>          }
>         return pagebuf_get_one(xch, ctx, buf, fd, dom);
>
> +    case XC_SAVE_ID_TOOLSTACK:
> +        {
> +            RDEXACT(fd, &ctx->toolstack_data_len,
> +                    sizeof(ctx->toolstack_data_len));
> +            ctx->toolstack_data = (uint8_t*)
> malloc(ctx->toolstack_data_len);
> +            if ( ctx->toolstack_data == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, ctx->toolstack_data, ctx->toolstack_data_len);
>

Basically this becomes,
 RDEXACT(fd, &buf->toolstack_data_len,...)
buf->toolstack_data = (uint8_t *)realloc(buf->toolstack_data_len, 0)
RDEXACT(fd, buf->toolstack_data, buf->toolstack_data_len)

And please do realloc. Since the pagebuf_get_one code is called repeatedly
by the main loop, using malloc would result in loads of memory leaks.



> +            return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        }
> +
>     case XC_SAVE_ID_ENABLE_COMPRESSION:
>         /* We cannot set compression flag directly in pagebuf structure,
>          * since this pagebuf still has uncompressed pages that are yet to
> @@ -1262,7 +1278,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
>                        unsigned int hvm, unsigned int pae, int superpages,
>                        int no_incr_generationid,
> -                      unsigned long *vm_generationid_addr)
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks)
>  {
>     DECLARE_DOMCTL;
>     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -2023,6 +2040,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>     goto out;
>
>   finish_hvm:
> +    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
> +    {
> +        if ( callbacks->toolstack_restore(dom,
> +                    ctx->toolstack_data, ctx->toolstack_data_len,
> +                    callbacks->data) < 0 )
> +        {
> +            PERROR("error calling toolstack_restore");
> +            free(ctx->toolstack_data);
> +            goto out;
> +        }
> +    }
> +    free(ctx->toolstack_data);
> +
>     /* Dump the QEMU state to a state file for QEMU to load */
>     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
>         PERROR("Error dumping QEMU state to file");
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index f473dd7..318c433 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd,
> uint32_t dom, uint32_t max_iter
>         }
>     }
>
> +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> +    {
> +        int id = XC_SAVE_ID_TOOLSTACK;
> +        uint8_t *buf;
> +        uint32_t len;
> +
> +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data)
> < 0 )
> +        {
> +            PERROR("Error calling toolstack_save");
> +            goto out;
> +        }
> +        wrexact(io_fd, &id, sizeof(id));
> +        wrexact(io_fd, &len, sizeof(len));
> +        wrexact(io_fd, buf, len);
> +        free(buf);
> +    }
> +
>     if ( !callbacks->checkpoint )
>     {
>         /*
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 6026370..76aa475 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -44,6 +44,14 @@ struct save_callbacks {
>     /* Enable qemu-dm logging dirty pages to xen */
>     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data);
> /* HVM only */
>
> +    /* Save toolstack specific data
> +     * @param buf the buffer with the data to be saved
> +     * @param len the length of the buffer
> +     * The callee allocates the buffer, the caller frees it (buffer must
> +     * be free'able).
> +     */
> +    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len,
> void *data);
> +
>     /* to be provided as the last argument to each callback function */
>     void* data;
>  };
> @@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd,
> uint32_t dom, uint32_t max_iter
>                    unsigned long vm_generationid_addr);
>
>
> +/* callbacks provided by xc_domain_restore */
> +struct restore_callbacks {
> +    /* callback to restore toolstack specific data */
> +    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
> +            uint32_t size, void* data);
> +
> +    /* to be provided as the last argument to each callback function */
> +    void* data;
> +};
> +
>  /**
>  * This function will restore a saved domain.
>  *
> @@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd,
> uint32_t dom, uint32_t max_iter
>   * @parm superpages non-zero to allocate guest memory with superpages
>   * @parm no_incr_generationid non-zero if generation id is NOT to be
> incremented
>  * @parm vm_generationid_addr returned with the address of the generation
> id buffer
> + * @parm callbacks non-NULL to receive a callback to restore toolstack
> + *       specific data
>  * @return 0 on success, -1 on failure
>  */
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> @@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
>                        unsigned int hvm, unsigned int pae, int superpages,
>                        int no_incr_generationid,
> -                     unsigned long *vm_generationid_addr);
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks);
>  /**
>  * xc_domain_restore writes a file to disk that contains the device
>  * model saved state.
> diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
> index 6286b68..46fdeaa 100644
> --- a/tools/libxc/xg_save_restore.h
> +++ b/tools/libxc/xg_save_restore.h
> @@ -254,6 +254,7 @@
>  #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival
> of compressed data */
>  #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression
> logic at receiver side */
>  #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
> +#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific
> info */
>
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 91643a2..2c5eec5 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc,
> uint32_t domid,
>                             state->store_port, &state->store_mfn,
>                            state->console_port, &state->console_mfn,
>                             hvm, pae, superpages, no_incr_generationid,
> -                           &state->vm_generationid_addr);
> +                           &state->vm_generationid_addr, NULL);
>      if ( rc ) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
>         return ERROR_FAIL;
> diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
> index 63d53a8..306a10e 100644
> --- a/tools/xcutils/xc_restore.c
> +++ b/tools/xcutils/xc_restore.c
> @@ -47,7 +47,7 @@ main(int argc, char **argv)
>
>     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
>                              console_evtchn, &console_mfn, hvm, pae,
> superpages,
> -                            0, NULL);
> +                            0, NULL, NULL);
>
>     if ( ret == 0 )
>     {
> --
> 1.7.2.5
>
>

--000e0ce0046412561504b7c33629
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabell=
ini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.co=
m">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

<div class=3D"im">Introduce a new save_id to save/restore toolstack specifi=
c extra<br>
information.<br>
<br>
Signed-off-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellini@=
eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>
---<br>
</div>=A0tools/libxc/xc_domain_restore.c | =A0 32 +++++++++++++++++++++++++=
++++++-<br>
=A0tools/libxc/xc_domain_save.c =A0 =A0| =A0 17 +++++++++++++++++<br>
=A0tools/libxc/xenguest.h =A0 =A0 =A0 =A0 =A0| =A0 23 +++++++++++++++++++++=
+-<br>
<div class=3D"im">=A0tools/libxc/xg_save_restore.h =A0 | =A0 =A01 +<br>
=A0tools/libxl/libxl_dom.c =A0 =A0 =A0 =A0 | =A0 =A02 +-<br>
</div>=A0tools/xcutils/xc_restore.c =A0 =A0 =A0| =A0 =A02 +-<br>
=A06 files changed, 73 insertions(+), 4 deletions(-)<br>
<br>
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restor=
e.c<br>
index 3fda6f8..ead3df4 100644<br>
--- a/tools/libxc/xc_domain_restore.c<br>
+++ b/tools/libxc/xc_domain_restore.c<br>
@@ -45,6 +45,8 @@ struct restore_ctx {<br>
 =A0 =A0 int last_checkpoint; /* Set when we should commit to the current c=
heckpoint when it completes. */<br>
 =A0 =A0 int compressing; /* Set when sender signals that pages would be se=
nt compressed (for Remus) */<br>
 =A0 =A0 struct domain_info_context dinfo;<br>
+ =A0 =A0uint8_t *toolstack_data;<br>
+ =A0 =A0uint32_t toolstack_data_len;<br>
=A0};<br>
<br></blockquote><div><br>This is still leaking speculative state. You have=
 only moved the restore code but<br>you are still reading the (potentially =
discardable) state into a global ctx structure.<br><br>Take a look at the t=
ailbuf code right below the pagebuf_get() call in xc_domain_restore().<br>

It reads the tailbuf onto a temporary buffer and then copies it onto the ma=
in one. <br>This way, if an error occurs while receiving data, one can comp=
letely discard the current<br>checkpoint (pagebuf &amp; tmptailbuf) and res=
tore from the previous one (tailbuf).<br>

<br>You could have a similar *consistent buffer* in the xc_domain_restore f=
unction itself, and copy the toolstack<br>stuff into it before starting to =
buffer a new checkpoint. Perhaps something like the snippet below?<br>
<br>
+ toolstack_data =3D realloc(pagebuf.toolstack_data_len)<br>+ memcpy(toolst=
ack_data, pagebuf.toolstack_data, pagebuf.toolstack_data_len);<br>if ( ctx-=
&gt;last_checkpoint )<br><br>Though, this would incur two reallocs (once in=
 pagebuf_get and once more in the main loop).<br>

<br>If there is a maximum size for this buffer, I would suggest mallocing i=
t once and for all, and just<br>memcpy it.<br><br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">


@@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct r=
estore_ctx *ctx,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
<br>
</div>+ =A0 =A0case XC_SAVE_ID_TOOLSTACK:<br>
+ =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, &amp;ctx-&gt;toolstack_data_len,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(ctx-&gt;toolstack_data_len)=
);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0ctx-&gt;toolstack_data =3D (uint8_t*) malloc(ctx-&=
gt;toolstack_data_len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( ctx-&gt;toolstack_data =3D=3D NULL )<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error memory allocation&quot;=
);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0}<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, ctx-&gt;toolstack_data, ctx-&gt;=
toolstack_data_len);<br></blockquote><div><br>Basically this becomes,<br>=
=A0RDEXACT(fd, &amp;buf-&gt;toolstack_data_len,...)<br>buf-&gt;toolstack_da=
ta =3D (uint8_t *)realloc(buf-&gt;toolstack_data_len, 0)<br>

RDEXACT(fd, buf-&gt;toolstack_data, buf-&gt;toolstack_data_len)<br><br>And =
please do realloc. Since the pagebuf_get_one code is called repeatedly<br>b=
y the main loop, using malloc would result in loads of memory leaks.<br>

<br>=A0</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">
+ =A0 =A0 =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br=
>
+ =A0 =A0 =A0 =A0}<br>
<div class=3D"im">+<br>
 =A0 =A0 case XC_SAVE_ID_ENABLE_COMPRESSION:<br>
 =A0 =A0 =A0 =A0 /* We cannot set compression flag directly in pagebuf stru=
cture,<br>
 =A0 =A0 =A0 =A0 =A0* since this pagebuf still has uncompressed pages that =
are yet to<br>
</div>@@ -1262,7 +1278,8 @@ int xc_domain_restore(xc_interface *xch, int io=
_fd, uint32_t dom,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int=
 console_evtchn, unsigned long *console_mfn,<br>
</div><div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsign=
ed int hvm, unsigned int pae, int superpages,<br>
</div> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int no_incr_generationid=
,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr,<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct resto=
re_callbacks *callbacks)<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>
</div>@@ -2023,6 +2040,19 @@ int xc_domain_restore(xc_interface *xch, int i=
o_fd, uint32_t dom,<br>
 =A0 =A0 goto out;<br>
<br>
 =A0 finish_hvm:<br>
<div class=3D"im">+ =A0 =A0if ( callbacks !=3D NULL &amp;&amp; callbacks-&g=
t;toolstack_restore !=3D NULL )<br>
+ =A0 =A0{<br>
+ =A0 =A0 =A0 =A0if ( callbacks-&gt;toolstack_restore(dom,<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ctx-&gt;toolstack_data, ctx-=
&gt;toolstack_data_len,<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0callbacks-&gt;da=
ta) &lt; 0 )<br>
+ =A0 =A0 =A0 =A0{<br>
</div><div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error calling=
 toolstack_restore&quot;);<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0free(ctx-&gt;toolstack_data);<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0}<br>
</div>+ =A0 =A0free(ctx-&gt;toolstack_data);<br>
+<br>
 =A0 =A0 /* Dump the QEMU state to a state file for QEMU to load */<br>
 =A0 =A0 if ( dump_qemu(xch, dom, &amp;tailbuf.u.hvm) ) {<br>
 =A0 =A0 =A0 =A0 PERROR(&quot;Error dumping QEMU state to file&quot;);<br>
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c<br=
>
index f473dd7..318c433 100644<br>
--- a/tools/libxc/xc_domain_save.c<br>
+++ b/tools/libxc/xc_domain_save.c<br>
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uin=
t32_t dom, uint32_t max_iter<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 }<br>
<br>
+ =A0 =A0if ( callbacks !=3D NULL &amp;&amp; callbacks-&gt;toolstack_save !=
=3D NULL )<br>
+ =A0 =A0{<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0int id =3D XC_SAVE_ID_TOOLSTACK;<br>
+ =A0 =A0 =A0 =A0uint8_t *buf;<br>
+ =A0 =A0 =A0 =A0uint32_t len;<br>
</div>+<br>
+ =A0 =A0 =A0 =A0if ( callbacks-&gt;toolstack_save(dom, &amp;buf, &amp;len,=
 callbacks-&gt;data) &lt; 0 )<br>
+ =A0 =A0 =A0 =A0{<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;Error calling tools=
tack_save&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0 =A0 =A0wrexact(io_fd, &amp;id, sizeof(id));<br>
+ =A0 =A0 =A0 =A0wrexact(io_fd, &amp;len, sizeof(len));<br>
+ =A0 =A0 =A0 =A0wrexact(io_fd, buf, len);<br>
+ =A0 =A0 =A0 =A0free(buf);<br>
+ =A0 =A0}<br>
+<br>
 =A0 =A0 if ( !callbacks-&gt;checkpoint )<br>
 =A0 =A0 {<br>
 =A0 =A0 =A0 =A0 /*<br>
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h<br>
</div>index 6026370..76aa475 100644<br>
<div class=3D"im">--- a/tools/libxc/xenguest.h<br>
+++ b/tools/libxc/xenguest.h<br>
@@ -44,6 +44,14 @@ struct save_callbacks {<br>
 =A0 =A0 /* Enable qemu-dm logging dirty pages to xen */<br>
 =A0 =A0 int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data=
); /* HVM only */<br>
<br>
+ =A0 =A0/* Save toolstack specific data<br>
+ =A0 =A0 * @param buf the buffer with the data to be saved<br>
+ =A0 =A0 * @param len the length of the buffer<br>
+ =A0 =A0 * The callee allocates the buffer, the caller frees it (buffer mu=
st<br>
+ =A0 =A0 * be free&#39;able).<br>
+ =A0 =A0 */<br>
+ =A0 =A0int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len=
, void *data);<br>
+<br>
 =A0 =A0 /* to be provided as the last argument to each callback function *=
/<br>
 =A0 =A0 void* data;<br>
=A0};<br>
</div>@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, u=
int32_t dom, uint32_t max_iter<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long vm_generationid_addr)=
;<br>
<div class=3D"im"><br>
<br>
+/* callbacks provided by xc_domain_restore */<br>
+struct restore_callbacks {<br>
+ =A0 =A0/* callback to restore toolstack specific data */<br>
+ =A0 =A0int (*toolstack_restore)(uint32_t domid, uint8_t *buf,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0uint32_t size, void* data);<br>
+<br>
+ =A0 =A0/* to be provided as the last argument to each callback function *=
/<br>
+ =A0 =A0void* data;<br>
+};<br>
+<br>
=A0/**<br>
 =A0* This function will restore a saved domain.<br>
 =A0*<br>
</div>@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, ui=
nt32_t dom, uint32_t max_iter<br>
<div class=3D"im"> =A0* @parm superpages non-zero to allocate guest memory =
with superpages<br>
</div> =A0* @parm no_incr_generationid non-zero if generation id is NOT to =
be incremented<br>
 =A0* @parm vm_generationid_addr returned with the address of the generatio=
n id buffer<br>
<div class=3D"im">+ * @parm callbacks non-NULL to receive a callback to res=
tore toolstack<br>
+ * =A0 =A0 =A0 specific data<br>
 =A0* @return 0 on success, -1 on failure<br>
 =A0*/<br>
</div><div class=3D"im">=A0int xc_domain_restore(xc_interface *xch, int io_=
fd, uint32_t dom,<br>
</div>@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd=
, uint32_t dom,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int=
 console_evtchn, unsigned long *console_mfn,<br>
</div><div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsign=
ed int hvm, unsigned int pae, int superpages,<br>
</div> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int no_incr_generationid=
,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long *vm_generationid_ad=
dr);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr,<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct resto=
re_callbacks *callbacks);<br>
=A0/**<br>
 =A0* xc_domain_restore writes a file to disk that contains the device<br>
 =A0* model saved state.<br>
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h<=
br>
</div>index 6286b68..46fdeaa 100644<br>
--- a/tools/libxc/xg_save_restore.h<br>
+++ b/tools/libxc/xg_save_restore.h<br>
@@ -254,6 +254,7 @@<br>
<div class=3D"im">=A0#define XC_SAVE_ID_COMPRESSED_DATA =A0 =A0-12 /* Marke=
r to indicate arrival of compressed data */<br>
=A0#define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compressio=
n logic at receiver side */<br>
</div>=A0#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14<br>
+#define XC_SAVE_ID_TOOLSTACK =A0 =A0 =A0 =A0 =A0-15 /* Optional toolstack =
specific info */<br>
<div class=3D"im"><br>
=A0/*<br>
=A0** We process save/restore/migrate in batches of pages; the below<br>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c<br>
</div>index 91643a2..2c5eec5 100644<br>
--- a/tools/libxl/libxl_dom.c<br>
+++ b/tools/libxl/libxl_dom.c<br>
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_=
t domid,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s=
tate-&gt;store_port, &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>
</div> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hvm, pae, sup=
erpages, no_incr_generationid,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;state-&gt;vm_gen=
erationid_addr);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;state-&gt;vm_gen=
erationid_addr, NULL);<br>
<div class=3D"im"> =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>
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c<br>
</div>index 63d53a8..306a10e 100644<br>
--- a/tools/xcutils/xc_restore.c<br>
+++ b/tools/xcutils/xc_restore.c<br>
@@ -47,7 +47,7 @@ main(int argc, char **argv)<br>
<div class=3D"im"><br>
 =A0 =A0 ret =3D xc_domain_restore(xch, io_fd, domid, store_evtchn, &amp;st=
ore_mfn,<br>
</div><div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 console_evtchn, &amp;console_mfn, hvm, pae, superpages,<br>
</div>- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00, NULL);<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00, NULL, NULL);<br=
>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
 =A0 =A0 if ( ret =3D=3D 0 )<br>
 =A0 =A0 {<br>
--<br>
1.7.2.5<br>
<br>
</div></div></blockquote></div><br>

--000e0ce0046412561504b7c33629--


--===============3706926105776435607==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3706926105776435607==--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:43:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:43:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrwBo-0004Dv-4o; Mon, 30 Jan 2012 18:42:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RrwBm-0004Dq-Ji
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:42:51 +0000
Received: from [85.158.138.51:35206] by server-10.bemta-3.messagelabs.com id
	2B/BD-20948-9A4E62F4; Mon, 30 Jan 2012 18:42:49 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-15.tower-174.messagelabs.com!1327948965!9437890!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10479 invoked from network); 30 Jan 2012 18:42:47 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-15.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 18:42:47 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0UIgfFr020316
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Mon, 30 Jan 2012 10:42:43 -0800
Received: by bkar1 with SMTP id r1so7577299bka.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 10:42:40 -0800 (PST)
Received: by 10.205.118.4 with SMTP id fo4mr8824110bkc.139.1327948960519; Mon,
	30 Jan 2012 10:42:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Mon, 30 Jan 2012 10:41:59 -0800 (PST)
In-Reply-To: <1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Mon, 30 Jan 2012 10:41:59 -0800
Message-ID: <CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Campbell@citrix.com
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============3706926105776435607=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3706926105776435607==
Content-Type: multipart/alternative; boundary=000e0ce0046412561504b7c33629

--000e0ce0046412561504b7c33629
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> Introduce a new save_id to save/restore toolstack specific extra
> information.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> ---
>  tools/libxc/xc_domain_restore.c |   32 +++++++++++++++++++++++++++++++-
>  tools/libxc/xc_domain_save.c    |   17 +++++++++++++++++
>  tools/libxc/xenguest.h          |   23 ++++++++++++++++++++++-
>  tools/libxc/xg_save_restore.h   |    1 +
>  tools/libxl/libxl_dom.c         |    2 +-
>  tools/xcutils/xc_restore.c      |    2 +-
>  6 files changed, 73 insertions(+), 4 deletions(-)
>
> diff --git a/tools/libxc/xc_domain_restore.c
> b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..ead3df4 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -45,6 +45,8 @@ struct restore_ctx {
>     int last_checkpoint; /* Set when we should commit to the current
> checkpoint when it completes. */
>     int compressing; /* Set when sender signals that pages would be sent
> compressed (for Remus) */
>     struct domain_info_context dinfo;
> +    uint8_t *toolstack_data;
> +    uint32_t toolstack_data_len;
>  };
>
>
This is still leaking speculative state. You have only moved the restore
code but
you are still reading the (potentially discardable) state into a global ctx
structure.

Take a look at the tailbuf code right below the pagebuf_get() call in
xc_domain_restore().
It reads the tailbuf onto a temporary buffer and then copies it onto the
main one.
This way, if an error occurs while receiving data, one can completely
discard the current
checkpoint (pagebuf & tmptailbuf) and restore from the previous one
(tailbuf).

You could have a similar *consistent buffer* in the xc_domain_restore
function itself, and copy the toolstack
stuff into it before starting to buffer a new checkpoint. Perhaps something
like the snippet below?

+ toolstack_data = realloc(pagebuf.toolstack_data_len)
+ memcpy(toolstack_data, pagebuf.toolstack_data,
pagebuf.toolstack_data_len);
if ( ctx->last_checkpoint )

Though, this would incur two reallocs (once in pagebuf_get and once more in
the main loop).

If there is a maximum size for this buffer, I would suggest mallocing it
once and for all, and just
memcpy it.


@@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct
> restore_ctx *ctx,
>          }
>         return pagebuf_get_one(xch, ctx, buf, fd, dom);
>
> +    case XC_SAVE_ID_TOOLSTACK:
> +        {
> +            RDEXACT(fd, &ctx->toolstack_data_len,
> +                    sizeof(ctx->toolstack_data_len));
> +            ctx->toolstack_data = (uint8_t*)
> malloc(ctx->toolstack_data_len);
> +            if ( ctx->toolstack_data == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, ctx->toolstack_data, ctx->toolstack_data_len);
>

Basically this becomes,
 RDEXACT(fd, &buf->toolstack_data_len,...)
buf->toolstack_data = (uint8_t *)realloc(buf->toolstack_data_len, 0)
RDEXACT(fd, buf->toolstack_data, buf->toolstack_data_len)

And please do realloc. Since the pagebuf_get_one code is called repeatedly
by the main loop, using malloc would result in loads of memory leaks.



> +            return pagebuf_get_one(xch, ctx, buf, fd, dom);
> +        }
> +
>     case XC_SAVE_ID_ENABLE_COMPRESSION:
>         /* We cannot set compression flag directly in pagebuf structure,
>          * since this pagebuf still has uncompressed pages that are yet to
> @@ -1262,7 +1278,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
>                        unsigned int hvm, unsigned int pae, int superpages,
>                        int no_incr_generationid,
> -                      unsigned long *vm_generationid_addr)
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks)
>  {
>     DECLARE_DOMCTL;
>     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -2023,6 +2040,19 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>     goto out;
>
>   finish_hvm:
> +    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
> +    {
> +        if ( callbacks->toolstack_restore(dom,
> +                    ctx->toolstack_data, ctx->toolstack_data_len,
> +                    callbacks->data) < 0 )
> +        {
> +            PERROR("error calling toolstack_restore");
> +            free(ctx->toolstack_data);
> +            goto out;
> +        }
> +    }
> +    free(ctx->toolstack_data);
> +
>     /* Dump the QEMU state to a state file for QEMU to load */
>     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
>         PERROR("Error dumping QEMU state to file");
> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index f473dd7..318c433 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd,
> uint32_t dom, uint32_t max_iter
>         }
>     }
>
> +    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
> +    {
> +        int id = XC_SAVE_ID_TOOLSTACK;
> +        uint8_t *buf;
> +        uint32_t len;
> +
> +        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data)
> < 0 )
> +        {
> +            PERROR("Error calling toolstack_save");
> +            goto out;
> +        }
> +        wrexact(io_fd, &id, sizeof(id));
> +        wrexact(io_fd, &len, sizeof(len));
> +        wrexact(io_fd, buf, len);
> +        free(buf);
> +    }
> +
>     if ( !callbacks->checkpoint )
>     {
>         /*
> diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
> index 6026370..76aa475 100644
> --- a/tools/libxc/xenguest.h
> +++ b/tools/libxc/xenguest.h
> @@ -44,6 +44,14 @@ struct save_callbacks {
>     /* Enable qemu-dm logging dirty pages to xen */
>     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data);
> /* HVM only */
>
> +    /* Save toolstack specific data
> +     * @param buf the buffer with the data to be saved
> +     * @param len the length of the buffer
> +     * The callee allocates the buffer, the caller frees it (buffer must
> +     * be free'able).
> +     */
> +    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len,
> void *data);
> +
>     /* to be provided as the last argument to each callback function */
>     void* data;
>  };
> @@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd,
> uint32_t dom, uint32_t max_iter
>                    unsigned long vm_generationid_addr);
>
>
> +/* callbacks provided by xc_domain_restore */
> +struct restore_callbacks {
> +    /* callback to restore toolstack specific data */
> +    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
> +            uint32_t size, void* data);
> +
> +    /* to be provided as the last argument to each callback function */
> +    void* data;
> +};
> +
>  /**
>  * This function will restore a saved domain.
>  *
> @@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd,
> uint32_t dom, uint32_t max_iter
>   * @parm superpages non-zero to allocate guest memory with superpages
>   * @parm no_incr_generationid non-zero if generation id is NOT to be
> incremented
>  * @parm vm_generationid_addr returned with the address of the generation
> id buffer
> + * @parm callbacks non-NULL to receive a callback to restore toolstack
> + *       specific data
>  * @return 0 on success, -1 on failure
>  */
>  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
> @@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
>                        unsigned int hvm, unsigned int pae, int superpages,
>                        int no_incr_generationid,
> -                     unsigned long *vm_generationid_addr);
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks);
>  /**
>  * xc_domain_restore writes a file to disk that contains the device
>  * model saved state.
> diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
> index 6286b68..46fdeaa 100644
> --- a/tools/libxc/xg_save_restore.h
> +++ b/tools/libxc/xg_save_restore.h
> @@ -254,6 +254,7 @@
>  #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival
> of compressed data */
>  #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression
> logic at receiver side */
>  #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
> +#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific
> info */
>
>  /*
>  ** We process save/restore/migrate in batches of pages; the below
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index 91643a2..2c5eec5 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc,
> uint32_t domid,
>                             state->store_port, &state->store_mfn,
>                            state->console_port, &state->console_mfn,
>                             hvm, pae, superpages, no_incr_generationid,
> -                           &state->vm_generationid_addr);
> +                           &state->vm_generationid_addr, NULL);
>      if ( rc ) {
>         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
>         return ERROR_FAIL;
> diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
> index 63d53a8..306a10e 100644
> --- a/tools/xcutils/xc_restore.c
> +++ b/tools/xcutils/xc_restore.c
> @@ -47,7 +47,7 @@ main(int argc, char **argv)
>
>     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
>                              console_evtchn, &console_mfn, hvm, pae,
> superpages,
> -                            0, NULL);
> +                            0, NULL, NULL);
>
>     if ( ret == 0 )
>     {
> --
> 1.7.2.5
>
>

--000e0ce0046412561504b7c33629
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabell=
ini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.co=
m">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

<div class=3D"im">Introduce a new save_id to save/restore toolstack specifi=
c extra<br>
information.<br>
<br>
Signed-off-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellini@=
eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>
---<br>
</div>=A0tools/libxc/xc_domain_restore.c | =A0 32 +++++++++++++++++++++++++=
++++++-<br>
=A0tools/libxc/xc_domain_save.c =A0 =A0| =A0 17 +++++++++++++++++<br>
=A0tools/libxc/xenguest.h =A0 =A0 =A0 =A0 =A0| =A0 23 +++++++++++++++++++++=
+-<br>
<div class=3D"im">=A0tools/libxc/xg_save_restore.h =A0 | =A0 =A01 +<br>
=A0tools/libxl/libxl_dom.c =A0 =A0 =A0 =A0 | =A0 =A02 +-<br>
</div>=A0tools/xcutils/xc_restore.c =A0 =A0 =A0| =A0 =A02 +-<br>
=A06 files changed, 73 insertions(+), 4 deletions(-)<br>
<br>
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restor=
e.c<br>
index 3fda6f8..ead3df4 100644<br>
--- a/tools/libxc/xc_domain_restore.c<br>
+++ b/tools/libxc/xc_domain_restore.c<br>
@@ -45,6 +45,8 @@ struct restore_ctx {<br>
 =A0 =A0 int last_checkpoint; /* Set when we should commit to the current c=
heckpoint when it completes. */<br>
 =A0 =A0 int compressing; /* Set when sender signals that pages would be se=
nt compressed (for Remus) */<br>
 =A0 =A0 struct domain_info_context dinfo;<br>
+ =A0 =A0uint8_t *toolstack_data;<br>
+ =A0 =A0uint32_t toolstack_data_len;<br>
=A0};<br>
<br></blockquote><div><br>This is still leaking speculative state. You have=
 only moved the restore code but<br>you are still reading the (potentially =
discardable) state into a global ctx structure.<br><br>Take a look at the t=
ailbuf code right below the pagebuf_get() call in xc_domain_restore().<br>

It reads the tailbuf onto a temporary buffer and then copies it onto the ma=
in one. <br>This way, if an error occurs while receiving data, one can comp=
letely discard the current<br>checkpoint (pagebuf &amp; tmptailbuf) and res=
tore from the previous one (tailbuf).<br>

<br>You could have a similar *consistent buffer* in the xc_domain_restore f=
unction itself, and copy the toolstack<br>stuff into it before starting to =
buffer a new checkpoint. Perhaps something like the snippet below?<br>
<br>
+ toolstack_data =3D realloc(pagebuf.toolstack_data_len)<br>+ memcpy(toolst=
ack_data, pagebuf.toolstack_data, pagebuf.toolstack_data_len);<br>if ( ctx-=
&gt;last_checkpoint )<br><br>Though, this would incur two reallocs (once in=
 pagebuf_get and once more in the main loop).<br>

<br>If there is a maximum size for this buffer, I would suggest mallocing i=
t once and for all, and just<br>memcpy it.<br><br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">


@@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct r=
estore_ctx *ctx,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 =A0 =A0 return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>
<br>
</div>+ =A0 =A0case XC_SAVE_ID_TOOLSTACK:<br>
+ =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, &amp;ctx-&gt;toolstack_data_len,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sizeof(ctx-&gt;toolstack_data_len)=
);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0ctx-&gt;toolstack_data =3D (uint8_t*) malloc(ctx-&=
gt;toolstack_data_len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( ctx-&gt;toolstack_data =3D=3D NULL )<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0{<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error memory allocation&quot;=
);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0}<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, ctx-&gt;toolstack_data, ctx-&gt;=
toolstack_data_len);<br></blockquote><div><br>Basically this becomes,<br>=
=A0RDEXACT(fd, &amp;buf-&gt;toolstack_data_len,...)<br>buf-&gt;toolstack_da=
ta =3D (uint8_t *)realloc(buf-&gt;toolstack_data_len, 0)<br>

RDEXACT(fd, buf-&gt;toolstack_data, buf-&gt;toolstack_data_len)<br><br>And =
please do realloc. Since the pagebuf_get_one code is called repeatedly<br>b=
y the main loop, using malloc would result in loads of memory leaks.<br>

<br>=A0</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">
+ =A0 =A0 =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br=
>
+ =A0 =A0 =A0 =A0}<br>
<div class=3D"im">+<br>
 =A0 =A0 case XC_SAVE_ID_ENABLE_COMPRESSION:<br>
 =A0 =A0 =A0 =A0 /* We cannot set compression flag directly in pagebuf stru=
cture,<br>
 =A0 =A0 =A0 =A0 =A0* since this pagebuf still has uncompressed pages that =
are yet to<br>
</div>@@ -1262,7 +1278,8 @@ int xc_domain_restore(xc_interface *xch, int io=
_fd, uint32_t dom,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int=
 console_evtchn, unsigned long *console_mfn,<br>
</div><div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsign=
ed int hvm, unsigned int pae, int superpages,<br>
</div> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int no_incr_generationid=
,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr,<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct resto=
re_callbacks *callbacks)<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>
</div>@@ -2023,6 +2040,19 @@ int xc_domain_restore(xc_interface *xch, int i=
o_fd, uint32_t dom,<br>
 =A0 =A0 goto out;<br>
<br>
 =A0 finish_hvm:<br>
<div class=3D"im">+ =A0 =A0if ( callbacks !=3D NULL &amp;&amp; callbacks-&g=
t;toolstack_restore !=3D NULL )<br>
+ =A0 =A0{<br>
+ =A0 =A0 =A0 =A0if ( callbacks-&gt;toolstack_restore(dom,<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ctx-&gt;toolstack_data, ctx-=
&gt;toolstack_data_len,<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0callbacks-&gt;da=
ta) &lt; 0 )<br>
+ =A0 =A0 =A0 =A0{<br>
</div><div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error calling=
 toolstack_restore&quot;);<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0free(ctx-&gt;toolstack_data);<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0}<br>
</div>+ =A0 =A0free(ctx-&gt;toolstack_data);<br>
+<br>
 =A0 =A0 /* Dump the QEMU state to a state file for QEMU to load */<br>
 =A0 =A0 if ( dump_qemu(xch, dom, &amp;tailbuf.u.hvm) ) {<br>
 =A0 =A0 =A0 =A0 PERROR(&quot;Error dumping QEMU state to file&quot;);<br>
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c<br=
>
index f473dd7..318c433 100644<br>
--- a/tools/libxc/xc_domain_save.c<br>
+++ b/tools/libxc/xc_domain_save.c<br>
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uin=
t32_t dom, uint32_t max_iter<br>
 =A0 =A0 =A0 =A0 }<br>
 =A0 =A0 }<br>
<br>
+ =A0 =A0if ( callbacks !=3D NULL &amp;&amp; callbacks-&gt;toolstack_save !=
=3D NULL )<br>
+ =A0 =A0{<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0int id =3D XC_SAVE_ID_TOOLSTACK;<br>
+ =A0 =A0 =A0 =A0uint8_t *buf;<br>
+ =A0 =A0 =A0 =A0uint32_t len;<br>
</div>+<br>
+ =A0 =A0 =A0 =A0if ( callbacks-&gt;toolstack_save(dom, &amp;buf, &amp;len,=
 callbacks-&gt;data) &lt; 0 )<br>
+ =A0 =A0 =A0 =A0{<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;Error calling tools=
tack_save&quot;);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0 =A0 =A0wrexact(io_fd, &amp;id, sizeof(id));<br>
+ =A0 =A0 =A0 =A0wrexact(io_fd, &amp;len, sizeof(len));<br>
+ =A0 =A0 =A0 =A0wrexact(io_fd, buf, len);<br>
+ =A0 =A0 =A0 =A0free(buf);<br>
+ =A0 =A0}<br>
+<br>
 =A0 =A0 if ( !callbacks-&gt;checkpoint )<br>
 =A0 =A0 {<br>
 =A0 =A0 =A0 =A0 /*<br>
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h<br>
</div>index 6026370..76aa475 100644<br>
<div class=3D"im">--- a/tools/libxc/xenguest.h<br>
+++ b/tools/libxc/xenguest.h<br>
@@ -44,6 +44,14 @@ struct save_callbacks {<br>
 =A0 =A0 /* Enable qemu-dm logging dirty pages to xen */<br>
 =A0 =A0 int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data=
); /* HVM only */<br>
<br>
+ =A0 =A0/* Save toolstack specific data<br>
+ =A0 =A0 * @param buf the buffer with the data to be saved<br>
+ =A0 =A0 * @param len the length of the buffer<br>
+ =A0 =A0 * The callee allocates the buffer, the caller frees it (buffer mu=
st<br>
+ =A0 =A0 * be free&#39;able).<br>
+ =A0 =A0 */<br>
+ =A0 =A0int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len=
, void *data);<br>
+<br>
 =A0 =A0 /* to be provided as the last argument to each callback function *=
/<br>
 =A0 =A0 void* data;<br>
=A0};<br>
</div>@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, u=
int32_t dom, uint32_t max_iter<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long vm_generationid_addr)=
;<br>
<div class=3D"im"><br>
<br>
+/* callbacks provided by xc_domain_restore */<br>
+struct restore_callbacks {<br>
+ =A0 =A0/* callback to restore toolstack specific data */<br>
+ =A0 =A0int (*toolstack_restore)(uint32_t domid, uint8_t *buf,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0uint32_t size, void* data);<br>
+<br>
+ =A0 =A0/* to be provided as the last argument to each callback function *=
/<br>
+ =A0 =A0void* data;<br>
+};<br>
+<br>
=A0/**<br>
 =A0* This function will restore a saved domain.<br>
 =A0*<br>
</div>@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, ui=
nt32_t dom, uint32_t max_iter<br>
<div class=3D"im"> =A0* @parm superpages non-zero to allocate guest memory =
with superpages<br>
</div> =A0* @parm no_incr_generationid non-zero if generation id is NOT to =
be incremented<br>
 =A0* @parm vm_generationid_addr returned with the address of the generatio=
n id buffer<br>
<div class=3D"im">+ * @parm callbacks non-NULL to receive a callback to res=
tore toolstack<br>
+ * =A0 =A0 =A0 specific data<br>
 =A0* @return 0 on success, -1 on failure<br>
 =A0*/<br>
</div><div class=3D"im">=A0int xc_domain_restore(xc_interface *xch, int io_=
fd, uint32_t dom,<br>
</div>@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd=
, uint32_t dom,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned int=
 console_evtchn, unsigned long *console_mfn,<br>
</div><div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsign=
ed int hvm, unsigned int pae, int superpages,<br>
</div> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int no_incr_generationid=
,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long *vm_generationid_ad=
dr);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr,<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct resto=
re_callbacks *callbacks);<br>
=A0/**<br>
 =A0* xc_domain_restore writes a file to disk that contains the device<br>
 =A0* model saved state.<br>
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h<=
br>
</div>index 6286b68..46fdeaa 100644<br>
--- a/tools/libxc/xg_save_restore.h<br>
+++ b/tools/libxc/xg_save_restore.h<br>
@@ -254,6 +254,7 @@<br>
<div class=3D"im">=A0#define XC_SAVE_ID_COMPRESSED_DATA =A0 =A0-12 /* Marke=
r to indicate arrival of compressed data */<br>
=A0#define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compressio=
n logic at receiver side */<br>
</div>=A0#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14<br>
+#define XC_SAVE_ID_TOOLSTACK =A0 =A0 =A0 =A0 =A0-15 /* Optional toolstack =
specific info */<br>
<div class=3D"im"><br>
=A0/*<br>
=A0** We process save/restore/migrate in batches of pages; the below<br>
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c<br>
</div>index 91643a2..2c5eec5 100644<br>
--- a/tools/libxl/libxl_dom.c<br>
+++ b/tools/libxl/libxl_dom.c<br>
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_=
t domid,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s=
tate-&gt;store_port, &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>
</div> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0hvm, pae, sup=
erpages, no_incr_generationid,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;state-&gt;vm_gen=
erationid_addr);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &amp;state-&gt;vm_gen=
erationid_addr, NULL);<br>
<div class=3D"im"> =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>
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c<br>
</div>index 63d53a8..306a10e 100644<br>
--- a/tools/xcutils/xc_restore.c<br>
+++ b/tools/xcutils/xc_restore.c<br>
@@ -47,7 +47,7 @@ main(int argc, char **argv)<br>
<div class=3D"im"><br>
 =A0 =A0 ret =3D xc_domain_restore(xch, io_fd, domid, store_evtchn, &amp;st=
ore_mfn,<br>
</div><div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 console_evtchn, &amp;console_mfn, hvm, pae, superpages,<br>
</div>- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00, NULL);<br=
>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A00, NULL, NULL);<br=
>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
 =A0 =A0 if ( ret =3D=3D 0 )<br>
 =A0 =A0 {<br>
--<br>
1.7.2.5<br>
<br>
</div></div></blockquote></div><br>

--000e0ce0046412561504b7c33629--


--===============3706926105776435607==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3706926105776435607==--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:51:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrwKG-0004Sw-C0; Mon, 30 Jan 2012 18:51:36 +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 1RrwKF-0004Sr-Fp
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:51:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327949489!12991058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9093 invoked from network); 30 Jan 2012 18:51: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;
	30 Jan 2012 18:51:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10374027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 18:51: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; Mon, 30 Jan 2012 18:51:28 +0000
Date: Mon, 30 Jan 2012 18:53:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F268632.8040801@redhat.com>
Message-ID: <alpine.DEB.2.00.1201301841000.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<jfud2p$h6$1@dough.gmane.org>
	<alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
	<4F268632.8040801@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 30 Jan 2012, Paolo Bonzini wrote:
> On 01/30/2012 12:56 PM, Stefano Stabellini wrote:
> >> >  Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.
> >
> > Good point.
> > I should check for rtc_clock == host_clock.
> >
> >> >  Why do you need to instantiate an RTC at all?
> > I don't, in fact in previous versions of this patch series I tried to do
> > that but it is difficult and makes the common code worse, so I followed
> > Anthony's suggestion of just disabling the rtc_clock.
> 
> I see.  It shouldn't surprise you that I completely disagree with 
> Anthony on this. :)

I am OK with both approaches, but I can see the benefits of reducing
this patch to (almost) a one-liner.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 18:51:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 18:51:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RrwKG-0004Sw-C0; Mon, 30 Jan 2012 18:51:36 +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 1RrwKF-0004Sr-Fp
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 18:51:35 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327949489!12991058!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9093 invoked from network); 30 Jan 2012 18:51: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;
	30 Jan 2012 18:51:29 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10374027"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 18:51: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; Mon, 30 Jan 2012 18:51:28 +0000
Date: Mon, 30 Jan 2012 18:53:02 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <4F268632.8040801@redhat.com>
Message-ID: <alpine.DEB.2.00.1201301841000.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>
	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>
	<jfud2p$h6$1@dough.gmane.org>
	<alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
	<4F268632.8040801@redhat.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 30 Jan 2012, Paolo Bonzini wrote:
> On 01/30/2012 12:56 PM, Stefano Stabellini wrote:
> >> >  Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.
> >
> > Good point.
> > I should check for rtc_clock == host_clock.
> >
> >> >  Why do you need to instantiate an RTC at all?
> > I don't, in fact in previous versions of this patch series I tried to do
> > that but it is difficult and makes the common code worse, so I followed
> > Anthony's suggestion of just disabling the rtc_clock.
> 
> I see.  It shouldn't surprise you that I completely disagree with 
> Anthony on this. :)

I am OK with both approaches, but I can see the benefits of reducing
this patch to (almost) a one-liner.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:19:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19: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 1Rrwku-0004ip-1N; Mon, 30 Jan 2012 19:19:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rrwks-0004ik-CB
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:19:06 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327951138!12677851!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10197 invoked from network); 30 Jan 2012 19:19:00 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 19:19:00 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0UJIgNR024400;
	Mon, 30 Jan 2012 14:18:43 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 30 Jan 2012 14:18:30 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451CD@mnetexch2.adamapps.host>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: AQHM3SZo9LC4iZ0d50mifymi8U9J8ZYhJYeAgAFx17CAArUAgA==
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au><EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host><EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
From: <djmagee@mageenet.net>
To: "James Harper" <james.harper@bendigoit.com.au>, <lta@akr.fm>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] GPLPV and 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 tried the Win2003 build and it works like a charm, and has native
> > performance across my gbit network in at least one direction.
> >
> 
> Right... so if I understand the problem:
> 
> . NDIS5 driver works fine under Windows 7 with PCI passthrough
> . NDIS6 driver works fine under Windows 7 with no PCI passthrough
> . NDIS6 driver does not work correctly with PCI passthrough

Correct.

> 
> Can you now try turning off all offloads in the DomU and see if starts
> working at some point?

I disabled CSum offload, Large Send Offload, and scatter gather.  No
help.  I also set
HKLM\System\CurrentControlSet\services\tcpip\Parameters\DisableTaskOfflo
ad=1.  Also no help.

> 
> I'm at a loss to explain how this could happen though.
> 

If I think of anything else I'll try it.  Would it help to try a 32bit
Windows 7 instance and see if there's any difference?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:19:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19: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 1Rrwku-0004ip-1N; Mon, 30 Jan 2012 19:19:08 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rrwks-0004ik-CB
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:19:06 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-8.tower-216.messagelabs.com!1327951138!12677851!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10197 invoked from network); 30 Jan 2012 19:19:00 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-8.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 19:19:00 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0UJIgNR024400;
	Mon, 30 Jan 2012 14:18:43 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 30 Jan 2012 14:18:30 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451CD@mnetexch2.adamapps.host>
In-Reply-To: <6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: AQHM3SZo9LC4iZ0d50mifymi8U9J8ZYhJYeAgAFx17CAArUAgA==
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au><EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host><EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
From: <djmagee@mageenet.net>
To: "James Harper" <james.harper@bendigoit.com.au>, <lta@akr.fm>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] GPLPV and 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 tried the Win2003 build and it works like a charm, and has native
> > performance across my gbit network in at least one direction.
> >
> 
> Right... so if I understand the problem:
> 
> . NDIS5 driver works fine under Windows 7 with PCI passthrough
> . NDIS6 driver works fine under Windows 7 with no PCI passthrough
> . NDIS6 driver does not work correctly with PCI passthrough

Correct.

> 
> Can you now try turning off all offloads in the DomU and see if starts
> working at some point?

I disabled CSum offload, Large Send Offload, and scatter gather.  No
help.  I also set
HKLM\System\CurrentControlSet\services\tcpip\Parameters\DisableTaskOfflo
ad=1.  Also no help.

> 
> I'm at a loss to explain how this could happen though.
> 

If I think of anything else I'll try it.  Would it help to try a 32bit
Windows 7 instance and see if there's any difference?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:23:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrwoy-0004qG-N4; Mon, 30 Jan 2012 19:23:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rrwox-0004q9-2H
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:23:19 +0000
Received: from [85.158.138.51:21131] by server-8.bemta-3.messagelabs.com id
	52/4D-31878-62EE62F4; Mon, 30 Jan 2012 19:23:18 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327951396!11301931!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10648 invoked from network); 30 Jan 2012 19:23:17 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 19:23:17 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0UJN4FT024573;
	Mon, 30 Jan 2012 14:23:04 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 30 Jan 2012 14:22:53 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451CE@mnetexch2.adamapps.host>
In-Reply-To: <CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: AczeqoO3Zu7FfyEjSCuQZHHFr8RDtAA2dZXw
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au><EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host><EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
	<CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com>
From: <djmagee@mageenet.net>
To: "Roderick Colenbrander" <thunderbird2k@gmail.com>,
	"James Harper" <james.harper@bendigoit.com.au>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, lta@akr.fm
Subject: Re: [Xen-devel] GPLPV and 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 had weird network problems as well using the 308 drivers. For
> me the 356 drivers from the hg repository do work fine, so something
> between 308 and 356 fixed some network bugs. Perhaps put a test build
> on the website for him to try?
> 

I already have the Windows DDK installed on a couple of machines, but
the link to the hg repo at
http://wiki.xen.org/wiki/Xen_Windows_GplPv/Building seems to be broken.
Where's the current repo housed?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:23:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19:23:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrwoy-0004qG-N4; Mon, 30 Jan 2012 19:23:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1Rrwox-0004q9-2H
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:23:19 +0000
Received: from [85.158.138.51:21131] by server-8.bemta-3.messagelabs.com id
	52/4D-31878-62EE62F4; Mon, 30 Jan 2012 19:23:18 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327951396!11301931!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10648 invoked from network); 30 Jan 2012 19:23:17 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 19:23:17 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0UJN4FT024573;
	Mon, 30 Jan 2012 14:23:04 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 30 Jan 2012 14:22:53 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451CE@mnetexch2.adamapps.host>
In-Reply-To: <CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: AczeqoO3Zu7FfyEjSCuQZHHFr8RDtAA2dZXw
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au><EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host><EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
	<CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com>
From: <djmagee@mageenet.net>
To: "Roderick Colenbrander" <thunderbird2k@gmail.com>,
	"James Harper" <james.harper@bendigoit.com.au>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: xen-devel@lists.xensource.com, lta@akr.fm
Subject: Re: [Xen-devel] GPLPV and 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 had weird network problems as well using the 308 drivers. For
> me the 356 drivers from the hg repository do work fine, so something
> between 308 and 356 fixed some network bugs. Perhaps put a test build
> on the website for him to try?
> 

I already have the Windows DDK installed on a couple of machines, but
the link to the hg repo at
http://wiki.xen.org/wiki/Xen_Windows_GplPv/Building seems to be broken.
Where's the current repo housed?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:28:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19: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 1Rrwto-00050y-ET; Mon, 30 Jan 2012 19:28:20 +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 1Rrwtn-00050m-Ow
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:28:19 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327951691!13156711!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7640 invoked from network); 30 Jan 2012 19:28:13 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 19:28:13 -0000
Received: by pbdx13 with SMTP id x13so35504177pbd.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 11:28:11 -0800 (PST)
Received: by 10.68.73.106 with SMTP id k10mr44616328pbv.35.1327951691372;
	Mon, 30 Jan 2012 11:28: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 k9sm49231044pbl.18.2012.01.30.11.28.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Jan 2012 11:28:10 -0800 (PST)
Message-ID: <4F26EF47.9090108@codemonkey.ws>
Date: Mon, 30 Jan 2012 13:28:07 -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: Paolo Bonzini <pbonzini@redhat.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>	<jfud2p$h6$1@dough.gmane.org>	<alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
	<4F268632.8040801@redhat.com>
In-Reply-To: <4F268632.8040801@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/30/2012 05:59 AM, Paolo Bonzini wrote:
> On 01/30/2012 12:56 PM, Stefano Stabellini wrote:
>>> > Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.
>>
>> Good point.
>> I should check for rtc_clock == host_clock.
>>
>>> > Why do you need to instantiate an RTC at all?
>> I don't, in fact in previous versions of this patch series I tried to do
>> that but it is difficult and makes the common code worse, so I followed
>> Anthony's suggestion of just disabling the rtc_clock.
>
> I see. It shouldn't surprise you that I completely disagree with Anthony on
> this. :)

Give me some credit at least...

The original patches didn't disable the RTC, it introduced a half-neutered Xen 
specific RTC.

My original suggestion (which I still think is the best approach) is to change 
the RTC emulation to not use a second timer at all.

Regards,

Anthony Liguori

> Paolo
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:28:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19: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 1Rrwto-00050y-ET; Mon, 30 Jan 2012 19:28:20 +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 1Rrwtn-00050m-Ow
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:28:19 +0000
X-Env-Sender: anthony@codemonkey.ws
X-Msg-Ref: server-11.tower-216.messagelabs.com!1327951691!13156711!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7640 invoked from network); 30 Jan 2012 19:28:13 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-11.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 19:28:13 -0000
Received: by pbdx13 with SMTP id x13so35504177pbd.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 11:28:11 -0800 (PST)
Received: by 10.68.73.106 with SMTP id k10mr44616328pbv.35.1327951691372;
	Mon, 30 Jan 2012 11:28: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 k9sm49231044pbl.18.2012.01.30.11.28.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Jan 2012 11:28:10 -0800 (PST)
Message-ID: <4F26EF47.9090108@codemonkey.ws>
Date: Mon, 30 Jan 2012 13:28:07 -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: Paolo Bonzini <pbonzini@redhat.com>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>	<jfud2p$h6$1@dough.gmane.org>	<alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
	<4F268632.8040801@redhat.com>
In-Reply-To: <4F268632.8040801@redhat.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/30/2012 05:59 AM, Paolo Bonzini wrote:
> On 01/30/2012 12:56 PM, Stefano Stabellini wrote:
>>> > Depending on "-rtc clock=vm" or "-rtc clock=rt", this may not be true.
>>
>> Good point.
>> I should check for rtc_clock == host_clock.
>>
>>> > Why do you need to instantiate an RTC at all?
>> I don't, in fact in previous versions of this patch series I tried to do
>> that but it is difficult and makes the common code worse, so I followed
>> Anthony's suggestion of just disabling the rtc_clock.
>
> I see. It shouldn't surprise you that I completely disagree with Anthony on
> this. :)

Give me some credit at least...

The original patches didn't disable the RTC, it introduced a half-neutered Xen 
specific RTC.

My original suggestion (which I still think is the best approach) is to change 
the RTC emulation to not use a second timer at all.

Regards,

Anthony Liguori

> Paolo
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:30:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19: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 1Rrwvk-00056p-VW; Mon, 30 Jan 2012 19:30:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1Rrwvj-00056V-AD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:30:19 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327951807!12994371!1
X-Originating-IP: [220.181.15.25]
X-SpamReason: No, hits=1.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNDM=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNDM=\n,BODY_DONG,HTML_40_50,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7416 invoked from network); 30 Jan 2012 19:30:09 -0000
Received: from m15-25.126.com (HELO m15-25.126.com) (220.181.15.25)
	by server-10.tower-182.messagelabs.com with SMTP;
	30 Jan 2012 19:30: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=f1BJguFKpnp7NYY
	S9/R8loD3Id9pB77kne+w3qsAEFo=; b=YU0L1+sR/1P7cu30Yb08pA79MmtEvG4
	/jvMQxJEi1GOhy55occOLARqWiItC0fWpdW5Ad/4VbUJCK5z1LIFE1gSnv2Ahn4q
	SOHSDLI8Fxtl4iUnD2YvkkAqC3knlNjaXjaxN1vq+OBT0Bz5qOLxVkXAVzbTKHRP
	Dq/q9yvOJ8FE=
Received: from hxkhust ( [111.174.3.118] ) by ajax-webmail-wmsvr25
	(Coremail) ; Tue, 31 Jan 2012 03:30:01 +0800 (CST)
Date: Tue, 31 Jan 2012 03:30:01 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Message-ID: <33c61cf2.5e8.13530186d2c.Coremail.hxkhust@126.com>
In-Reply-To: <1327940330.26983.257.camel@zakaz.uk.xensource.com>
References: <1327940330.26983.257.camel@zakaz.uk.xensource.com>
	<298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [111.174.3.118]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: ++GlgWZvb3Rlcl9odG09MjUzNDo4MQ==
X-CM-TRANSID: GcqowGBZ_0C57yZP3_YGAA--.39877W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiaQVFBU1rxCItkQAAsQ
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8275891157364812531=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8275891157364812531==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4340_1154812815.1327951801643"

------=_Part_4340_1154812815.1327951801643
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

In the situation I consider here,the VM C won't be running again after it's set up.The existence of VM C is  only for VM A and VM B's running.If VM A or VM B change some blocks in its file system,the change will only be stored in its own virtual disk image whose format is QCOW2.That's meaning which I would like to express.However I cannot find the solution to my problem temporarily.Your further suggest is helpful for me.





At 2012-01-31 00:18:58,"Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>On Mon, 2012-01-30 at 08:11 +0000, hxkhust wrote:
>> Hi,
>>  
>> Recently I'm dong some reserch on xen and encounter a problem that I
>> cannot solve temporarily.I need your help very much and the following
>> is the question I would like to ask:
>> On a physical machine with xen virtualization platform installed ,VM
>> A,VM B are VM C's virtual disks are all image files,among which VM A
>> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
>> format. And VM A and VM B's virtual disk image files are based on VM
>> C's virtual disk image file.Now these three VMs are running on the
>> same physical machine with xen installed.
>
>This is an invalid/dangerous configuration. You can't really safely
>write to the backing file (C's raw disk) while there are active users (A
>and B's qcow2 images) of it. Imagine e.g. that all three change the same
>bit of filesystem metadata in different ways...
>
>Ian.
>
>

------=_Part_4340_1154812815.1327951801643
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>In the situation I consider here,the VM C won't be&nbsp;running again&nbsp;after it's set up.The existence of VM&nbsp;C is&nbsp; only for VM A and VM B's running.If VM&nbsp;A or VM B change some blocks in its file system,the&nbsp;change will only be stored in&nbsp;its own virtual disk image&nbsp;whose format is QCOW2.That's meaning which I would like to express.However I cannot find the solution to my problem temporarily.Your further suggest is helpful for me.<BR><BR></DIV>
<DIV></DIV>
<DIV id="divNeteaseMailCard"></DIV>
<DIV><BR></DIV><PRE><BR>At&nbsp;2012-01-31&nbsp;00:18:58,"Ian&nbsp;Campbell"&nbsp;&lt;Ian.Campbell@citrix.com&gt;&nbsp;wrote:
&gt;On&nbsp;Mon,&nbsp;2012-01-30&nbsp;at&nbsp;08:11&nbsp;+0000,&nbsp;hxkhust&nbsp;wrote:
&gt;&gt;&nbsp;Hi,
&gt;&gt;&nbsp;&nbsp;
&gt;&gt;&nbsp;Recently&nbsp;I'm&nbsp;dong&nbsp;some&nbsp;reserch&nbsp;on&nbsp;xen&nbsp;and&nbsp;encounter&nbsp;a&nbsp;problem&nbsp;that&nbsp;I
&gt;&gt;&nbsp;cannot&nbsp;solve&nbsp;temporarily.I&nbsp;need&nbsp;your&nbsp;help&nbsp;very&nbsp;much&nbsp;and&nbsp;the&nbsp;following
&gt;&gt;&nbsp;is&nbsp;the&nbsp;question&nbsp;I&nbsp;would&nbsp;like&nbsp;to&nbsp;ask:
&gt;&gt;&nbsp;On&nbsp;a&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;virtualization&nbsp;platform&nbsp;installed&nbsp;,VM
&gt;&gt;&nbsp;A,VM&nbsp;B&nbsp;are&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;all&nbsp;image&nbsp;files,among&nbsp;which&nbsp;VM&nbsp;A
&gt;&gt;&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;QCOW2&nbsp;format&nbsp;and&nbsp;VM&nbsp;C's&nbsp;disk&nbsp;is&nbsp;RAW
&gt;&gt;&nbsp;format.&nbsp;And&nbsp;VM&nbsp;A&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;files&nbsp;are&nbsp;based&nbsp;on&nbsp;VM
&gt;&gt;&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file.Now&nbsp;these&nbsp;three&nbsp;VMs&nbsp;are&nbsp;running&nbsp;on&nbsp;the
&gt;&gt;&nbsp;same&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;installed.
&gt;
&gt;This&nbsp;is&nbsp;an&nbsp;invalid/dangerous&nbsp;configuration.&nbsp;You&nbsp;can't&nbsp;really&nbsp;safely
&gt;write&nbsp;to&nbsp;the&nbsp;backing&nbsp;file&nbsp;(C's&nbsp;raw&nbsp;disk)&nbsp;while&nbsp;there&nbsp;are&nbsp;active&nbsp;users&nbsp;(A
&gt;and&nbsp;B's&nbsp;qcow2&nbsp;images)&nbsp;of&nbsp;it.&nbsp;Imagine&nbsp;e.g.&nbsp;that&nbsp;all&nbsp;three&nbsp;change&nbsp;the&nbsp;same
&gt;bit&nbsp;of&nbsp;filesystem&nbsp;metadata&nbsp;in&nbsp;different&nbsp;ways...
&gt;
&gt;Ian.
&gt;
&gt;
</PRE></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_4340_1154812815.1327951801643--



--===============8275891157364812531==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8275891157364812531==--



From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:30:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19: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 1Rrwvk-00056p-VW; Mon, 30 Jan 2012 19:30:20 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1Rrwvj-00056V-AD
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:30:19 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-10.tower-182.messagelabs.com!1327951807!12994371!1
X-Originating-IP: [220.181.15.25]
X-SpamReason: No, hits=1.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNDM=\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjI1ID0+IDczNDM=\n,BODY_DONG,HTML_40_50,
	HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7416 invoked from network); 30 Jan 2012 19:30:09 -0000
Received: from m15-25.126.com (HELO m15-25.126.com) (220.181.15.25)
	by server-10.tower-182.messagelabs.com with SMTP;
	30 Jan 2012 19:30: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=f1BJguFKpnp7NYY
	S9/R8loD3Id9pB77kne+w3qsAEFo=; b=YU0L1+sR/1P7cu30Yb08pA79MmtEvG4
	/jvMQxJEi1GOhy55occOLARqWiItC0fWpdW5Ad/4VbUJCK5z1LIFE1gSnv2Ahn4q
	SOHSDLI8Fxtl4iUnD2YvkkAqC3knlNjaXjaxN1vq+OBT0Bz5qOLxVkXAVzbTKHRP
	Dq/q9yvOJ8FE=
Received: from hxkhust ( [111.174.3.118] ) by ajax-webmail-wmsvr25
	(Coremail) ; Tue, 31 Jan 2012 03:30:01 +0800 (CST)
Date: Tue, 31 Jan 2012 03:30:01 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: "Ian Campbell" <Ian.Campbell@citrix.com>
Message-ID: <33c61cf2.5e8.13530186d2c.Coremail.hxkhust@126.com>
In-Reply-To: <1327940330.26983.257.camel@zakaz.uk.xensource.com>
References: <1327940330.26983.257.camel@zakaz.uk.xensource.com>
	<298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [111.174.3.118]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: ++GlgWZvb3Rlcl9odG09MjUzNDo4MQ==
X-CM-TRANSID: GcqowGBZ_0C57yZP3_YGAA--.39877W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbiaQVFBU1rxCItkQAAsQ
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============8275891157364812531=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8275891157364812531==
Content-Type: multipart/alternative; 
	boundary="----=_Part_4340_1154812815.1327951801643"

------=_Part_4340_1154812815.1327951801643
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

In the situation I consider here,the VM C won't be running again after it's set up.The existence of VM C is  only for VM A and VM B's running.If VM A or VM B change some blocks in its file system,the change will only be stored in its own virtual disk image whose format is QCOW2.That's meaning which I would like to express.However I cannot find the solution to my problem temporarily.Your further suggest is helpful for me.





At 2012-01-31 00:18:58,"Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>On Mon, 2012-01-30 at 08:11 +0000, hxkhust wrote:
>> Hi,
>>  
>> Recently I'm dong some reserch on xen and encounter a problem that I
>> cannot solve temporarily.I need your help very much and the following
>> is the question I would like to ask:
>> On a physical machine with xen virtualization platform installed ,VM
>> A,VM B are VM C's virtual disks are all image files,among which VM A
>> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
>> format. And VM A and VM B's virtual disk image files are based on VM
>> C's virtual disk image file.Now these three VMs are running on the
>> same physical machine with xen installed.
>
>This is an invalid/dangerous configuration. You can't really safely
>write to the backing file (C's raw disk) while there are active users (A
>and B's qcow2 images) of it. Imagine e.g. that all three change the same
>bit of filesystem metadata in different ways...
>
>Ian.
>
>

------=_Part_4340_1154812815.1327951801643
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>In the situation I consider here,the VM C won't be&nbsp;running again&nbsp;after it's set up.The existence of VM&nbsp;C is&nbsp; only for VM A and VM B's running.If VM&nbsp;A or VM B change some blocks in its file system,the&nbsp;change will only be stored in&nbsp;its own virtual disk image&nbsp;whose format is QCOW2.That's meaning which I would like to express.However I cannot find the solution to my problem temporarily.Your further suggest is helpful for me.<BR><BR></DIV>
<DIV></DIV>
<DIV id="divNeteaseMailCard"></DIV>
<DIV><BR></DIV><PRE><BR>At&nbsp;2012-01-31&nbsp;00:18:58,"Ian&nbsp;Campbell"&nbsp;&lt;Ian.Campbell@citrix.com&gt;&nbsp;wrote:
&gt;On&nbsp;Mon,&nbsp;2012-01-30&nbsp;at&nbsp;08:11&nbsp;+0000,&nbsp;hxkhust&nbsp;wrote:
&gt;&gt;&nbsp;Hi,
&gt;&gt;&nbsp;&nbsp;
&gt;&gt;&nbsp;Recently&nbsp;I'm&nbsp;dong&nbsp;some&nbsp;reserch&nbsp;on&nbsp;xen&nbsp;and&nbsp;encounter&nbsp;a&nbsp;problem&nbsp;that&nbsp;I
&gt;&gt;&nbsp;cannot&nbsp;solve&nbsp;temporarily.I&nbsp;need&nbsp;your&nbsp;help&nbsp;very&nbsp;much&nbsp;and&nbsp;the&nbsp;following
&gt;&gt;&nbsp;is&nbsp;the&nbsp;question&nbsp;I&nbsp;would&nbsp;like&nbsp;to&nbsp;ask:
&gt;&gt;&nbsp;On&nbsp;a&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;virtualization&nbsp;platform&nbsp;installed&nbsp;,VM
&gt;&gt;&nbsp;A,VM&nbsp;B&nbsp;are&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;all&nbsp;image&nbsp;files,among&nbsp;which&nbsp;VM&nbsp;A
&gt;&gt;&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;QCOW2&nbsp;format&nbsp;and&nbsp;VM&nbsp;C's&nbsp;disk&nbsp;is&nbsp;RAW
&gt;&gt;&nbsp;format.&nbsp;And&nbsp;VM&nbsp;A&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;files&nbsp;are&nbsp;based&nbsp;on&nbsp;VM
&gt;&gt;&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file.Now&nbsp;these&nbsp;three&nbsp;VMs&nbsp;are&nbsp;running&nbsp;on&nbsp;the
&gt;&gt;&nbsp;same&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;installed.
&gt;
&gt;This&nbsp;is&nbsp;an&nbsp;invalid/dangerous&nbsp;configuration.&nbsp;You&nbsp;can't&nbsp;really&nbsp;safely
&gt;write&nbsp;to&nbsp;the&nbsp;backing&nbsp;file&nbsp;(C's&nbsp;raw&nbsp;disk)&nbsp;while&nbsp;there&nbsp;are&nbsp;active&nbsp;users&nbsp;(A
&gt;and&nbsp;B's&nbsp;qcow2&nbsp;images)&nbsp;of&nbsp;it.&nbsp;Imagine&nbsp;e.g.&nbsp;that&nbsp;all&nbsp;three&nbsp;change&nbsp;the&nbsp;same
&gt;bit&nbsp;of&nbsp;filesystem&nbsp;metadata&nbsp;in&nbsp;different&nbsp;ways...
&gt;
&gt;Ian.
&gt;
&gt;
</PRE></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_4340_1154812815.1327951801643--



--===============8275891157364812531==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8275891157364812531==--



From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:41:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrx6E-0005LD-8Q; Mon, 30 Jan 2012 19:41:10 +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 1Rrx6C-0005L8-Dz
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:41:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327952462!3746919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4552 invoked from network); 30 Jan 2012 19:41:02 -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;
	30 Jan 2012 19:41:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10374414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 19:41:02 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 19:41:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120129213746.GA7164@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
	<20120129213746.GA7164@phenom.dumpdata.com>
Date: Mon, 30 Jan 2012 19:41:14 +0000
Message-ID: <1327952474.5553.53.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-01-29 at 21:37 +0000, Konrad Rzeszutek Wilk wrote:
> Sure. I also did some testing with limiting the amount of CPUs and found
> that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> > 

I think I find a way to work around this problem. In fact, it is my
fault -- I was not guarding memory safe enough.

I'm torturing my box at the moment, will see if it can survive the
night. :-)


Wei. 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:41:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19:41:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrx6E-0005LD-8Q; Mon, 30 Jan 2012 19:41:10 +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 1Rrx6C-0005L8-Dz
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:41:08 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327952462!3746919!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NTg1NQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4552 invoked from network); 30 Jan 2012 19:41:02 -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;
	30 Jan 2012 19:41:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208";a="10374414"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	30 Jan 2012 19:41:02 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Mon, 30 Jan 2012 19:41:02 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120129213746.GA7164@phenom.dumpdata.com>
References: <1326808024-3744-1-git-send-email-wei.liu2@citrix.com>
	<20120127192214.GA14437@phenom.dumpdata.com>
	<1327844561.2911.5.camel@leeds.uk.xensource.com>
	<20120129213746.GA7164@phenom.dumpdata.com>
Date: Mon, 30 Jan 2012 19:41:14 +0000
Message-ID: <1327952474.5553.53.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Paul Durrant <Paul.Durrant@citrix.com>, David
	Vrabel <david.vrabel@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V2] New Xen netback implementation
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Sun, 2012-01-29 at 21:37 +0000, Konrad Rzeszutek Wilk wrote:
> Sure. I also did some testing with limiting the amount of CPUs and found
> that 'xl vcpu-set 0 N' make netback not work anymore :-( 
> > 

I think I find a way to work around this problem. In fact, it is my
fault -- I was not guarding memory safe enough.

I'm torturing my box at the moment, will see if it can survive the
night. :-)


Wei. 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:42:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19:42:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrx7Y-0005OL-Nc; Mon, 30 Jan 2012 19:42:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1Rrx7Y-0005OB-32
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:42:32 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327952544!14557369!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22430 invoked from network); 30 Jan 2012 19:42:25 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 19:42:25 -0000
Received: by yenr9 with SMTP id r9so58671443yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 11:42: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=Y3d5Ly90oX0dhVpejPwrDNHqvEBf+elSP41LYb9MRf0=;
	b=ifVh/i8b5N/iPd0vTWY2JF6u0sLA862aSUq+itAB8pCeuEwTplKGqtVXfAVH0bQ54c
	Qdhv7GDkyoQ/NvAFvh+SWQ6sphPfmMjUlCm6pRhlMfNA2SSrvSBECv0GQjxcQl13cPH9
	0ER/OkXGUwstI4KoDxvJu47QyCXBQNg11spI8=
MIME-Version: 1.0
Received: by 10.236.190.137 with SMTP id e9mr28204279yhn.36.1327952544629;
	Mon, 30 Jan 2012 11:42:24 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Mon, 30 Jan 2012 11:42:24 -0800 (PST)
In-Reply-To: <EECC125FCE18E740AF561189E12602851451CE@mnetexch2.adamapps.host>
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
	<EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
	<EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
	<CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com>
	<EECC125FCE18E740AF561189E12602851451CE@mnetexch2.adamapps.host>
Date: Mon, 30 Jan 2012 19:42:24 +0000
Message-ID: <CAEc3jaArdDQL5+k-jdgW0idGpoUpq4CXzfg4QafJ660B8OjiRg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: djmagee@mageenet.net
Cc: James Harper <james.harper@bendigoit.com.au>, xen-devel@lists.xensource.com,
	lta@akr.fm
Subject: Re: [Xen-devel] GPLPV and pci passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 7:22 PM,  <djmagee@mageenet.net> wrote:
>> I have had weird network problems as well using the 308 drivers. For
>> me the 356 drivers from the hg repository do work fine, so something
>> between 308 and 356 fixed some network bugs. Perhaps put a test build
>> on the website for him to try?
>>
>
> I already have the Windows DDK installed on a couple of machines, but
> the link to the hg repo at
> http://wiki.xen.org/wiki/Xen_Windows_GplPv/Building seems to be broken.
> Where's the current repo housed?

You can find it here:
http://xenbits.xen.org/ext/win-pvdrivers/

Look at the README file of the source tree for additional build instructions.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 19:42:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 19:42:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrx7Y-0005OL-Nc; Mon, 30 Jan 2012 19:42:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <thunderbird2k@gmail.com>) id 1Rrx7Y-0005OB-32
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 19:42:32 +0000
X-Env-Sender: thunderbird2k@gmail.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327952544!14557369!1
X-Originating-IP: [209.85.213.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22430 invoked from network); 30 Jan 2012 19:42:25 -0000
Received: from mail-yx0-f171.google.com (HELO mail-yx0-f171.google.com)
	(209.85.213.171)
	by server-2.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	30 Jan 2012 19:42:25 -0000
Received: by yenr9 with SMTP id r9so58671443yen.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 11:42: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=Y3d5Ly90oX0dhVpejPwrDNHqvEBf+elSP41LYb9MRf0=;
	b=ifVh/i8b5N/iPd0vTWY2JF6u0sLA862aSUq+itAB8pCeuEwTplKGqtVXfAVH0bQ54c
	Qdhv7GDkyoQ/NvAFvh+SWQ6sphPfmMjUlCm6pRhlMfNA2SSrvSBECv0GQjxcQl13cPH9
	0ER/OkXGUwstI4KoDxvJu47QyCXBQNg11spI8=
MIME-Version: 1.0
Received: by 10.236.190.137 with SMTP id e9mr28204279yhn.36.1327952544629;
	Mon, 30 Jan 2012 11:42:24 -0800 (PST)
Received: by 10.100.27.35 with HTTP; Mon, 30 Jan 2012 11:42:24 -0800 (PST)
In-Reply-To: <EECC125FCE18E740AF561189E12602851451CE@mnetexch2.adamapps.host>
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au>
	<EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host>
	<EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host>
	<6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au>
	<CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com>
	<EECC125FCE18E740AF561189E12602851451CE@mnetexch2.adamapps.host>
Date: Mon, 30 Jan 2012 19:42:24 +0000
Message-ID: <CAEc3jaArdDQL5+k-jdgW0idGpoUpq4CXzfg4QafJ660B8OjiRg@mail.gmail.com>
From: Roderick Colenbrander <thunderbird2k@gmail.com>
To: djmagee@mageenet.net
Cc: James Harper <james.harper@bendigoit.com.au>, xen-devel@lists.xensource.com,
	lta@akr.fm
Subject: Re: [Xen-devel] GPLPV and pci passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 7:22 PM,  <djmagee@mageenet.net> wrote:
>> I have had weird network problems as well using the 308 drivers. For
>> me the 356 drivers from the hg repository do work fine, so something
>> between 308 and 356 fixed some network bugs. Perhaps put a test build
>> on the website for him to try?
>>
>
> I already have the Windows DDK installed on a couple of machines, but
> the link to the hg repo at
> http://wiki.xen.org/wiki/Xen_Windows_GplPv/Building seems to be broken.
> Where's the current repo housed?

You can find it here:
http://xenbits.xen.org/ext/win-pvdrivers/

Look at the README file of the source tree for additional build instructions.

Roderick

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:03:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21: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 1RryMx-0005zk-5y; Mon, 30 Jan 2012 21:02:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1RryMv-0005zf-67
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:02:29 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327957277!63083431!1
X-Originating-IP: [209.85.161.171]
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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29788 invoked from network); 30 Jan 2012 21:01:18 -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;
	30 Jan 2012 21:01:18 -0000
Received: by ggnk3 with SMTP id k3so51098151ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:02:26 -0800 (PST)
Received-SPF: pass (google.com: domain of romihs.forums@gmail.com designates
	10.50.178.106 as permitted sender) client-ip=10.50.178.106; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	romihs.forums@gmail.com designates 10.50.178.106 as permitted
	sender) smtp.mail=romihs.forums@gmail.com;
	dkim=pass header.i=romihs.forums@gmail.com
Received: from mr.google.com ([10.50.178.106])
	by 10.50.178.106 with SMTP id cx10mr24432370igc.15.1327957346166
	(num_hops = 1); Mon, 30 Jan 2012 13: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=loVPb0Y4L+ZMmFfcZ+J1RobuSyqs2JpbtBv7w7w/+54=;
	b=HGRO4TZUfrV9Xy3GtLDl/IBq1qWWpc5dwyGQqZGHY3vNZUzPVa+rwpmyuDW0ted/cb
	a9Leck81wOTaFOnHWxbAmWqDE5B8jpnvmq30EgdAAbxacEBJamr0IV57FEyrCHlG1Mll
	xgeyvFKRuuZMwGDSmuzg9SrtNGxWzKLknI9fY=
MIME-Version: 1.0
Received: by 10.50.178.106 with SMTP id cx10mr19197510igc.15.1327957346012;
	Mon, 30 Jan 2012 13:02:26 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 30 Jan 2012 13:02:25 -0800 (PST)
Date: Mon, 30 Jan 2012 22:02:25 +0100
Message-ID: <CAFoWEVP0QYr3eobUKXYhgk5mDT2MtLyZ+-RXNJpVgACARjUe7g@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Error building latest release of 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: multipart/mixed; boundary="===============2727403193473061024=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2727403193473061024==
Content-Type: multipart/alternative; boundary=e89a8f5036c8e2cc2804b7c52903

--e89a8f5036c8e2cc2804b7c52903
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I am trying to build the latest release of xen-unstable to test it with
pci-passthrough, but the process stops with errors.

I checked out the latest release of xen-unstable:

root@rom-xen:/usr/src$rev=24407;rev=24593;hg clone -r $rev
http://xenbits.xensource.com/staging/xen-unstable.hg/xen-unstable.hg-rev-${rev}
requesting all changes
adding changesets
adding manifests
adding file changes
added 24594 changesets with 124353 changes to 11427 files
updating to branch default
3240 files updated, 0 files merged, 0 files removed, 0 files unresolved

Then I go into the tool directory to run make so that qwmu gets checked
out, and I get this error (last few build messages showen below):

=== PCI passthrough capability has been enabled ===
=== PCI passthrough capability has been enabled ===
make[3]: Entering directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm'
/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0755
-p "///usr/lib/xen/bin"
/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0755
-p "///etc/xen/scripts"
/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m0755 -p
../i386-dm/qemu-ifup-Linux "///etc/xen/scripts/qemu-ifup"
/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m 755 -s
qemu-dm "//usr/lib/xen/bin"
make[3]: Leaving directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm'
make[2]: Leaving directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote'
make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools'
make[1]: Entering directory `/usr/src/xen-unstable.hg-rev-24593/tools'
if test -d git://xenbits.xen.org/qemu-upstream-unstable.git ; then \
mkdir -p qemu-xen-dir; \
else \
export GIT=git; \
/usr/src/xen-unstable.hg-rev-24593/tools/../scripts/git-checkout.sh git://
xenbits.xen.org/qemu-upstream-unstable.git master qemu-xen-dir ; \
fi
Cloning into qemu-xen-dir-remote.tmp...
remote: Counting objects: 92128, done.
remote: Compressing objects: 100% (19571/19571), done.
remote: Total 92128 (delta 72983), reused 91583 (delta 72438)
Receiving objects: 100% (92128/92128), 34.70 MiB | 1.66 MiB/s, done.
Resolving deltas: 100% (72983/72983), done.
Switched to a new branch 'dummy'
if test -d git://xenbits.xen.org/qemu-upstream-unstable.git ; then \
source=git://xenbits.xen.org/qemu-upstream-unstable.git; \
else \
source=.; \
fi; \
cd qemu-xen-dir; \
$source/configure --enable-xen --target-list=i386-softmmu \
--source-path=$source \
--extra-cflags="-I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/include
\
-I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc \
-I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore" \
--extra-ldflags="-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc \
-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore" \
--bindir=/usr/lib/xen/bin \
--disable-kvm \
; \
make install
glib-2.0 required to compile QEMU
make[2]: Entering directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote'
"/qemu"
/bin/sh: /qemu: not found
make[2]: *** [install-sysconfig] Error 127
make[2]: Leaving directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote'
make[1]: *** [subdir-all-qemu-xen-dir] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools'
make: *** [subdirs-all] Error 2


I do not understand what is causing this error. But I think it is good that
the xen developers know about this.
If anyone wants the whole output from the build, I have it saved and can
attach it if need be.

Best regards

Sandi

--e89a8f5036c8e2cc2804b7c52903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I am trying to build the latest release of xen-un=
stable to test it with pci-passthrough, but the process stops with errors.<=
/div><div><br></div><div>I checked out the latest release of xen-unstable:<=
/div>
<div><br></div><div><div>root@rom-xen:/usr/src$rev=3D24407;rev=3D24593;hg c=
lone -r $rev <a href=3D"http://xenbits.xensource.com/staging/xen-unstable.h=
g/">http://xenbits.xensource.com/staging/xen-unstable.hg/</a> xen-unstable.=
hg-rev-${rev}</div>
<div>requesting all changes</div><div>adding changesets</div><div>adding ma=
nifests</div><div>adding file changes</div><div>added 24594 changesets with=
 124353 changes to 11427 files</div><div>updating to branch default</div>
<div>3240 files updated, 0 files merged, 0 files removed, 0 files unresolve=
d</div></div><div><br></div><div>Then I go into the tool directory to run m=
ake so that qwmu gets checked out, and I get this error (last few build mes=
sages showen below):</div>
<div><br></div><div><div>=3D=3D=3D PCI passthrough capability has been enab=
led =3D=3D=3D</div><div>=3D=3D=3D PCI passthrough capability has been enabl=
ed =3D=3D=3D</div><div>make[3]: Entering directory `/usr/src/xen-unstable.h=
g-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm&#39;</div>
<div>/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0=
755 -p &quot;///usr/lib/xen/bin&quot;</div><div>/usr/src/xen-unstable.hg-re=
v-24593/tools/../tools/cross-install -d -m0755 -p &quot;///etc/xen/scripts&=
quot;</div>
<div>/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m0755=
 -p ../i386-dm/qemu-ifup-Linux &quot;///etc/xen/scripts/qemu-ifup&quot;</di=
v><div>/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m 7=
55 -s qemu-dm &quot;//usr/lib/xen/bin&quot;</div>
<div>make[3]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools/q=
emu-xen-traditional-dir-remote/i386-dm&#39;</div><div>make[2]: Leaving dire=
ctory `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-re=
mote&#39;</div>
<div>make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools&#=
39;</div><div>make[1]: Entering directory `/usr/src/xen-unstable.hg-rev-245=
93/tools&#39;</div><div>if test -d git://<a href=3D"http://xenbits.xen.org/=
qemu-upstream-unstable.git">xenbits.xen.org/qemu-upstream-unstable.git</a> =
; then \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>mkdi=
r -p qemu-xen-dir; \</div><div><span class=3D"Apple-tab-span" style=3D"whit=
e-space:pre">	</span>else \</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">		</span>export GIT=3Dgit; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>/usr=
/src/xen-unstable.hg-rev-24593/tools/../scripts/git-checkout.sh git://<a hr=
ef=3D"http://xenbits.xen.org/qemu-upstream-unstable.git">xenbits.xen.org/qe=
mu-upstream-unstable.git</a> master qemu-xen-dir ; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>fi</d=
iv><div>Cloning into qemu-xen-dir-remote.tmp...</div><div>remote: Counting =
objects: 92128, done.</div><div>remote: Compressing objects: 100% (19571/19=
571), done.</div>
<div>remote: Total 92128 (delta 72983), reused 91583 (delta 72438)</div><di=
v>Receiving objects: 100% (92128/92128), 34.70 MiB | 1.66 MiB/s, done.</div=
><div>Resolving deltas: 100% (72983/72983), done.</div><div>Switched to a n=
ew branch &#39;dummy&#39;</div>
<div>if test -d git://<a href=3D"http://xenbits.xen.org/qemu-upstream-unsta=
ble.git">xenbits.xen.org/qemu-upstream-unstable.git</a> ; then \</div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>source=3D=
git://<a href=3D"http://xenbits.xen.org/qemu-upstream-unstable.git">xenbits=
.xen.org/qemu-upstream-unstable.git</a>; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>else =
\</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</sp=
an>source=3D.; \</div><div><span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre">	</span>fi; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>cd qe=
mu-xen-dir; \</div><div><span class=3D"Apple-tab-span" style=3D"white-space=
:pre">	</span>$source/configure --enable-xen --target-list=3Di386-softmmu \=
</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>--so=
urce-path=3D$source \</div><div><span class=3D"Apple-tab-span" style=3D"whi=
te-space:pre">		</span>--extra-cflags=3D&quot;-I/usr/src/xen-unstable.hg-re=
v-24593/tools/../tools/include \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>-I/u=
sr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc \</div><div><span cla=
ss=3D"Apple-tab-span" style=3D"white-space:pre">		</span>-I/usr/src/xen-uns=
table.hg-rev-24593/tools/../tools/xenstore&quot; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>--ex=
tra-ldflags=3D&quot;-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/lib=
xc \</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		<=
/span>-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore&quot; \<=
/div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>--bi=
ndir=3D/usr/lib/xen/bin \</div><div><span class=3D"Apple-tab-span" style=3D=
"white-space:pre">		</span>--disable-kvm \</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre">		</span>; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>make =
install</div><div>glib-2.0 required to compile QEMU</div><div>make[2]: Ente=
ring directory `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remot=
e&#39;</div>
<div>&quot;/qemu&quot;</div><div>/bin/sh: /qemu: not found</div><div>make[2=
]: *** [install-sysconfig] Error 127</div><div>make[2]: Leaving directory `=
/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote&#39;</div>
<div>make[1]: *** [subdir-all-qemu-xen-dir] Error 2</div><div>make[1]: Leav=
ing directory `/usr/src/xen-unstable.hg-rev-24593/tools&#39;</div><div>make=
: *** [subdirs-all] Error 2</div></div><div><br></div><div><br></div><div>
I do not understand what is causing this error. But I think it is good that=
 the xen developers know about this.</div><div>If anyone wants the whole ou=
tput from the build, I have it saved and can attach it if need be.</div>
<div><br></div><div>Best regards</div><div><br>Sandi</div>

--e89a8f5036c8e2cc2804b7c52903--


--===============2727403193473061024==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2727403193473061024==--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:03:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21: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 1RryMx-0005zk-5y; Mon, 30 Jan 2012 21:02:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <romihs.forums@gmail.com>) id 1RryMv-0005zf-67
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:02:29 +0000
X-Env-Sender: romihs.forums@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327957277!63083431!1
X-Originating-IP: [209.85.161.171]
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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29788 invoked from network); 30 Jan 2012 21:01:18 -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;
	30 Jan 2012 21:01:18 -0000
Received: by ggnk3 with SMTP id k3so51098151ggn.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 13:02:26 -0800 (PST)
Received-SPF: pass (google.com: domain of romihs.forums@gmail.com designates
	10.50.178.106 as permitted sender) client-ip=10.50.178.106; 
Authentication-Results: mr.google.com; spf=pass (google.com: domain of
	romihs.forums@gmail.com designates 10.50.178.106 as permitted
	sender) smtp.mail=romihs.forums@gmail.com;
	dkim=pass header.i=romihs.forums@gmail.com
Received: from mr.google.com ([10.50.178.106])
	by 10.50.178.106 with SMTP id cx10mr24432370igc.15.1327957346166
	(num_hops = 1); Mon, 30 Jan 2012 13: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=loVPb0Y4L+ZMmFfcZ+J1RobuSyqs2JpbtBv7w7w/+54=;
	b=HGRO4TZUfrV9Xy3GtLDl/IBq1qWWpc5dwyGQqZGHY3vNZUzPVa+rwpmyuDW0ted/cb
	a9Leck81wOTaFOnHWxbAmWqDE5B8jpnvmq30EgdAAbxacEBJamr0IV57FEyrCHlG1Mll
	xgeyvFKRuuZMwGDSmuzg9SrtNGxWzKLknI9fY=
MIME-Version: 1.0
Received: by 10.50.178.106 with SMTP id cx10mr19197510igc.15.1327957346012;
	Mon, 30 Jan 2012 13:02:26 -0800 (PST)
Received: by 10.42.220.67 with HTTP; Mon, 30 Jan 2012 13:02:25 -0800 (PST)
Date: Mon, 30 Jan 2012 22:02:25 +0100
Message-ID: <CAFoWEVP0QYr3eobUKXYhgk5mDT2MtLyZ+-RXNJpVgACARjUe7g@mail.gmail.com>
From: Sandi Romih <romihs.forums@gmail.com>
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Error building latest release of 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: multipart/mixed; boundary="===============2727403193473061024=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2727403193473061024==
Content-Type: multipart/alternative; boundary=e89a8f5036c8e2cc2804b7c52903

--e89a8f5036c8e2cc2804b7c52903
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I am trying to build the latest release of xen-unstable to test it with
pci-passthrough, but the process stops with errors.

I checked out the latest release of xen-unstable:

root@rom-xen:/usr/src$rev=24407;rev=24593;hg clone -r $rev
http://xenbits.xensource.com/staging/xen-unstable.hg/xen-unstable.hg-rev-${rev}
requesting all changes
adding changesets
adding manifests
adding file changes
added 24594 changesets with 124353 changes to 11427 files
updating to branch default
3240 files updated, 0 files merged, 0 files removed, 0 files unresolved

Then I go into the tool directory to run make so that qwmu gets checked
out, and I get this error (last few build messages showen below):

=== PCI passthrough capability has been enabled ===
=== PCI passthrough capability has been enabled ===
make[3]: Entering directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm'
/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0755
-p "///usr/lib/xen/bin"
/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0755
-p "///etc/xen/scripts"
/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m0755 -p
../i386-dm/qemu-ifup-Linux "///etc/xen/scripts/qemu-ifup"
/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m 755 -s
qemu-dm "//usr/lib/xen/bin"
make[3]: Leaving directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm'
make[2]: Leaving directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote'
make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools'
make[1]: Entering directory `/usr/src/xen-unstable.hg-rev-24593/tools'
if test -d git://xenbits.xen.org/qemu-upstream-unstable.git ; then \
mkdir -p qemu-xen-dir; \
else \
export GIT=git; \
/usr/src/xen-unstable.hg-rev-24593/tools/../scripts/git-checkout.sh git://
xenbits.xen.org/qemu-upstream-unstable.git master qemu-xen-dir ; \
fi
Cloning into qemu-xen-dir-remote.tmp...
remote: Counting objects: 92128, done.
remote: Compressing objects: 100% (19571/19571), done.
remote: Total 92128 (delta 72983), reused 91583 (delta 72438)
Receiving objects: 100% (92128/92128), 34.70 MiB | 1.66 MiB/s, done.
Resolving deltas: 100% (72983/72983), done.
Switched to a new branch 'dummy'
if test -d git://xenbits.xen.org/qemu-upstream-unstable.git ; then \
source=git://xenbits.xen.org/qemu-upstream-unstable.git; \
else \
source=.; \
fi; \
cd qemu-xen-dir; \
$source/configure --enable-xen --target-list=i386-softmmu \
--source-path=$source \
--extra-cflags="-I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/include
\
-I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc \
-I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore" \
--extra-ldflags="-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc \
-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore" \
--bindir=/usr/lib/xen/bin \
--disable-kvm \
; \
make install
glib-2.0 required to compile QEMU
make[2]: Entering directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote'
"/qemu"
/bin/sh: /qemu: not found
make[2]: *** [install-sysconfig] Error 127
make[2]: Leaving directory
`/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote'
make[1]: *** [subdir-all-qemu-xen-dir] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools'
make: *** [subdirs-all] Error 2


I do not understand what is causing this error. But I think it is good that
the xen developers know about this.
If anyone wants the whole output from the build, I have it saved and can
attach it if need be.

Best regards

Sandi

--e89a8f5036c8e2cc2804b7c52903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello,<div><br></div><div>I am trying to build the latest release of xen-un=
stable to test it with pci-passthrough, but the process stops with errors.<=
/div><div><br></div><div>I checked out the latest release of xen-unstable:<=
/div>
<div><br></div><div><div>root@rom-xen:/usr/src$rev=3D24407;rev=3D24593;hg c=
lone -r $rev <a href=3D"http://xenbits.xensource.com/staging/xen-unstable.h=
g/">http://xenbits.xensource.com/staging/xen-unstable.hg/</a> xen-unstable.=
hg-rev-${rev}</div>
<div>requesting all changes</div><div>adding changesets</div><div>adding ma=
nifests</div><div>adding file changes</div><div>added 24594 changesets with=
 124353 changes to 11427 files</div><div>updating to branch default</div>
<div>3240 files updated, 0 files merged, 0 files removed, 0 files unresolve=
d</div></div><div><br></div><div>Then I go into the tool directory to run m=
ake so that qwmu gets checked out, and I get this error (last few build mes=
sages showen below):</div>
<div><br></div><div><div>=3D=3D=3D PCI passthrough capability has been enab=
led =3D=3D=3D</div><div>=3D=3D=3D PCI passthrough capability has been enabl=
ed =3D=3D=3D</div><div>make[3]: Entering directory `/usr/src/xen-unstable.h=
g-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm&#39;</div>
<div>/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0=
755 -p &quot;///usr/lib/xen/bin&quot;</div><div>/usr/src/xen-unstable.hg-re=
v-24593/tools/../tools/cross-install -d -m0755 -p &quot;///etc/xen/scripts&=
quot;</div>
<div>/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m0755=
 -p ../i386-dm/qemu-ifup-Linux &quot;///etc/xen/scripts/qemu-ifup&quot;</di=
v><div>/usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m 7=
55 -s qemu-dm &quot;//usr/lib/xen/bin&quot;</div>
<div>make[3]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools/q=
emu-xen-traditional-dir-remote/i386-dm&#39;</div><div>make[2]: Leaving dire=
ctory `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-re=
mote&#39;</div>
<div>make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools&#=
39;</div><div>make[1]: Entering directory `/usr/src/xen-unstable.hg-rev-245=
93/tools&#39;</div><div>if test -d git://<a href=3D"http://xenbits.xen.org/=
qemu-upstream-unstable.git">xenbits.xen.org/qemu-upstream-unstable.git</a> =
; then \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>mkdi=
r -p qemu-xen-dir; \</div><div><span class=3D"Apple-tab-span" style=3D"whit=
e-space:pre">	</span>else \</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">		</span>export GIT=3Dgit; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>/usr=
/src/xen-unstable.hg-rev-24593/tools/../scripts/git-checkout.sh git://<a hr=
ef=3D"http://xenbits.xen.org/qemu-upstream-unstable.git">xenbits.xen.org/qe=
mu-upstream-unstable.git</a> master qemu-xen-dir ; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>fi</d=
iv><div>Cloning into qemu-xen-dir-remote.tmp...</div><div>remote: Counting =
objects: 92128, done.</div><div>remote: Compressing objects: 100% (19571/19=
571), done.</div>
<div>remote: Total 92128 (delta 72983), reused 91583 (delta 72438)</div><di=
v>Receiving objects: 100% (92128/92128), 34.70 MiB | 1.66 MiB/s, done.</div=
><div>Resolving deltas: 100% (72983/72983), done.</div><div>Switched to a n=
ew branch &#39;dummy&#39;</div>
<div>if test -d git://<a href=3D"http://xenbits.xen.org/qemu-upstream-unsta=
ble.git">xenbits.xen.org/qemu-upstream-unstable.git</a> ; then \</div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>source=3D=
git://<a href=3D"http://xenbits.xen.org/qemu-upstream-unstable.git">xenbits=
.xen.org/qemu-upstream-unstable.git</a>; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>else =
\</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</sp=
an>source=3D.; \</div><div><span class=3D"Apple-tab-span" style=3D"white-sp=
ace:pre">	</span>fi; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>cd qe=
mu-xen-dir; \</div><div><span class=3D"Apple-tab-span" style=3D"white-space=
:pre">	</span>$source/configure --enable-xen --target-list=3Di386-softmmu \=
</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>--so=
urce-path=3D$source \</div><div><span class=3D"Apple-tab-span" style=3D"whi=
te-space:pre">		</span>--extra-cflags=3D&quot;-I/usr/src/xen-unstable.hg-re=
v-24593/tools/../tools/include \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>-I/u=
sr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc \</div><div><span cla=
ss=3D"Apple-tab-span" style=3D"white-space:pre">		</span>-I/usr/src/xen-uns=
table.hg-rev-24593/tools/../tools/xenstore&quot; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>--ex=
tra-ldflags=3D&quot;-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/lib=
xc \</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		<=
/span>-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore&quot; \<=
/div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">		</span>--bi=
ndir=3D/usr/lib/xen/bin \</div><div><span class=3D"Apple-tab-span" style=3D=
"white-space:pre">		</span>--disable-kvm \</div><div><span class=3D"Apple-t=
ab-span" style=3D"white-space:pre">		</span>; \</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>make =
install</div><div>glib-2.0 required to compile QEMU</div><div>make[2]: Ente=
ring directory `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remot=
e&#39;</div>
<div>&quot;/qemu&quot;</div><div>/bin/sh: /qemu: not found</div><div>make[2=
]: *** [install-sysconfig] Error 127</div><div>make[2]: Leaving directory `=
/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote&#39;</div>
<div>make[1]: *** [subdir-all-qemu-xen-dir] Error 2</div><div>make[1]: Leav=
ing directory `/usr/src/xen-unstable.hg-rev-24593/tools&#39;</div><div>make=
: *** [subdirs-all] Error 2</div></div><div><br></div><div><br></div><div>
I do not understand what is causing this error. But I think it is good that=
 the xen developers know about this.</div><div>If anyone wants the whole ou=
tput from the build, I have it saved and can attach it if need be.</div>
<div><br></div><div>Best regards</div><div><br>Sandi</div>

--e89a8f5036c8e2cc2804b7c52903--


--===============2727403193473061024==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2727403193473061024==--


From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:23:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21: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 1RrygL-0006Ef-Os; Mon, 30 Jan 2012 21:22:33 +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 1RrygJ-0006Ea-1d
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:22:31 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327958544!12462368!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTU5OTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25812 invoked from network); 30 Jan 2012 21:22:24 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 21:22:24 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id E9CB22633;
	Mon, 30 Jan 2012 23:22:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C41D420058; Mon, 30 Jan 2012 23:22:22 +0200 (EET)
Date: Mon, 30 Jan 2012 23:22:22 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120130212222.GI12984@reaktio.net>
References: <CAFoWEVP0QYr3eobUKXYhgk5mDT2MtLyZ+-RXNJpVgACARjUe7g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVP0QYr3eobUKXYhgk5mDT2MtLyZ+-RXNJpVgACARjUe7g@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error building latest release of 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 Mon, Jan 30, 2012 at 10:02:25PM +0100, Sandi Romih wrote:
>    Hello,
>    I am trying to build the latest release of xen-unstable to test it with
>    pci-passthrough, but the process stops with errors.
>    I checked out the latest release of xen-unstable:
>    root@rom-xen:/usr/src$rev=24407;rev=24593;hg clone -r $rev
>    [1]http://xenbits.xensource.com/staging/xen-unstable.hg/
>    xen-unstable.hg-rev-${rev}
>    requesting all changes
>    adding changesets
>    adding manifests
>    adding file changes
>    added 24594 changesets with 124353 changes to 11427 files
>    updating to branch default
>    3240 files updated, 0 files merged, 0 files removed, 0 files unresolved
>    Then I go into the tool directory to run make so that qwmu gets checked
>    out, and I get this error (last few build messages showen below):
>    === PCI passthrough capability has been enabled ===
>    === PCI passthrough capability has been enabled ===
>    make[3]: Entering directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm'
>    /usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0755
>    -p "///usr/lib/xen/bin"
>    /usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0755
>    -p "///etc/xen/scripts"
>    /usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m0755 -p
>    ../i386-dm/qemu-ifup-Linux "///etc/xen/scripts/qemu-ifup"
>    /usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m 755 -s
>    qemu-dm "//usr/lib/xen/bin"
>    make[3]: Leaving directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm'
>    make[2]: Leaving directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote'
>    make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools'
>    make[1]: Entering directory `/usr/src/xen-unstable.hg-rev-24593/tools'
>    if test -d git://[2]xenbits.xen.org/qemu-upstream-unstable.git ; then \
>                    mkdir -p qemu-xen-dir; \
>            else \
>                    export GIT=git; \
> 
>    /usr/src/xen-unstable.hg-rev-24593/tools/../scripts/git-checkout.sh
>    git://[3]xenbits.xen.org/qemu-upstream-unstable.git master qemu-xen-dir ;
>    \
>            fi
>    Cloning into qemu-xen-dir-remote.tmp...
>    remote: Counting objects: 92128, done.
>    remote: Compressing objects: 100% (19571/19571), done.
>    remote: Total 92128 (delta 72983), reused 91583 (delta 72438)
>    Receiving objects: 100% (92128/92128), 34.70 MiB | 1.66 MiB/s, done.
>    Resolving deltas: 100% (72983/72983), done.
>    Switched to a new branch 'dummy'
>    if test -d git://[4]xenbits.xen.org/qemu-upstream-unstable.git ; then \
> 
>    source=git://[5]xenbits.xen.org/qemu-upstream-unstable.git; \
>            else \
>                    source=.; \
>            fi; \
>            cd qemu-xen-dir; \
>            $source/configure --enable-xen --target-list=i386-softmmu \
>                    --source-path=$source \
> 
>    --extra-cflags="-I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/include
>    \
>                    -I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc
>    \
> 
>    -I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore" \
> 
>    --extra-ldflags="-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc
>    \
> 
>    -L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore" \
>                    --bindir=/usr/lib/xen/bin \
>                    --disable-kvm \
>                    ; \
>            make install
>    glib-2.0 required to compile QEMU


Based on that line.. do you have headers (development packages) for glib-2.0 installed? 


>    make[2]: Entering directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote'
>    "/qemu"
>    /bin/sh: /qemu: not found
>    make[2]: *** [install-sysconfig] Error 127
>    make[2]: Leaving directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote'
>    make[1]: *** [subdir-all-qemu-xen-dir] Error 2
>    make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools'
>    make: *** [subdirs-all] Error 2
>    I do not understand what is causing this error. But I think it is good
>    that the xen developers know about this.
>    If anyone wants the whole output from the build, I have it saved and can
>    attach it if need be.

See above.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:23:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21: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 1RrygL-0006Ef-Os; Mon, 30 Jan 2012 21:22:33 +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 1RrygJ-0006Ea-1d
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:22:31 +0000
X-Env-Sender: pasik@iki.fi
X-Msg-Ref: server-13.tower-182.messagelabs.com!1327958544!12462368!1
X-Originating-IP: [192.89.123.25]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjg5LjEyMy4yNSA9PiAzOTU5OTU=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25812 invoked from network); 30 Jan 2012 21:22:24 -0000
Received: from smtp.tele.fi (HELO smtp.tele.fi) (192.89.123.25)
	by server-13.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 21:22:24 -0000
X-Originating-Ip: [194.89.68.22]
Received: from ydin.reaktio.net (reaktio.net [194.89.68.22])
	by smtp.tele.fi (Postfix) with ESMTP id E9CB22633;
	Mon, 30 Jan 2012 23:22:22 +0200 (EET)
Received: by ydin.reaktio.net (Postfix, from userid 1001)
	id C41D420058; Mon, 30 Jan 2012 23:22:22 +0200 (EET)
Date: Mon, 30 Jan 2012 23:22:22 +0200
From: Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?= <pasik@iki.fi>
To: Sandi Romih <romihs.forums@gmail.com>
Message-ID: <20120130212222.GI12984@reaktio.net>
References: <CAFoWEVP0QYr3eobUKXYhgk5mDT2MtLyZ+-RXNJpVgACARjUe7g@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAFoWEVP0QYr3eobUKXYhgk5mDT2MtLyZ+-RXNJpVgACARjUe7g@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Error building latest release of 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 Mon, Jan 30, 2012 at 10:02:25PM +0100, Sandi Romih wrote:
>    Hello,
>    I am trying to build the latest release of xen-unstable to test it with
>    pci-passthrough, but the process stops with errors.
>    I checked out the latest release of xen-unstable:
>    root@rom-xen:/usr/src$rev=24407;rev=24593;hg clone -r $rev
>    [1]http://xenbits.xensource.com/staging/xen-unstable.hg/
>    xen-unstable.hg-rev-${rev}
>    requesting all changes
>    adding changesets
>    adding manifests
>    adding file changes
>    added 24594 changesets with 124353 changes to 11427 files
>    updating to branch default
>    3240 files updated, 0 files merged, 0 files removed, 0 files unresolved
>    Then I go into the tool directory to run make so that qwmu gets checked
>    out, and I get this error (last few build messages showen below):
>    === PCI passthrough capability has been enabled ===
>    === PCI passthrough capability has been enabled ===
>    make[3]: Entering directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm'
>    /usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0755
>    -p "///usr/lib/xen/bin"
>    /usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -d -m0755
>    -p "///etc/xen/scripts"
>    /usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m0755 -p
>    ../i386-dm/qemu-ifup-Linux "///etc/xen/scripts/qemu-ifup"
>    /usr/src/xen-unstable.hg-rev-24593/tools/../tools/cross-install -m 755 -s
>    qemu-dm "//usr/lib/xen/bin"
>    make[3]: Leaving directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote/i386-dm'
>    make[2]: Leaving directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-traditional-dir-remote'
>    make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools'
>    make[1]: Entering directory `/usr/src/xen-unstable.hg-rev-24593/tools'
>    if test -d git://[2]xenbits.xen.org/qemu-upstream-unstable.git ; then \
>                    mkdir -p qemu-xen-dir; \
>            else \
>                    export GIT=git; \
> 
>    /usr/src/xen-unstable.hg-rev-24593/tools/../scripts/git-checkout.sh
>    git://[3]xenbits.xen.org/qemu-upstream-unstable.git master qemu-xen-dir ;
>    \
>            fi
>    Cloning into qemu-xen-dir-remote.tmp...
>    remote: Counting objects: 92128, done.
>    remote: Compressing objects: 100% (19571/19571), done.
>    remote: Total 92128 (delta 72983), reused 91583 (delta 72438)
>    Receiving objects: 100% (92128/92128), 34.70 MiB | 1.66 MiB/s, done.
>    Resolving deltas: 100% (72983/72983), done.
>    Switched to a new branch 'dummy'
>    if test -d git://[4]xenbits.xen.org/qemu-upstream-unstable.git ; then \
> 
>    source=git://[5]xenbits.xen.org/qemu-upstream-unstable.git; \
>            else \
>                    source=.; \
>            fi; \
>            cd qemu-xen-dir; \
>            $source/configure --enable-xen --target-list=i386-softmmu \
>                    --source-path=$source \
> 
>    --extra-cflags="-I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/include
>    \
>                    -I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc
>    \
> 
>    -I/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore" \
> 
>    --extra-ldflags="-L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/libxc
>    \
> 
>    -L/usr/src/xen-unstable.hg-rev-24593/tools/../tools/xenstore" \
>                    --bindir=/usr/lib/xen/bin \
>                    --disable-kvm \
>                    ; \
>            make install
>    glib-2.0 required to compile QEMU


Based on that line.. do you have headers (development packages) for glib-2.0 installed? 


>    make[2]: Entering directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote'
>    "/qemu"
>    /bin/sh: /qemu: not found
>    make[2]: *** [install-sysconfig] Error 127
>    make[2]: Leaving directory
>    `/usr/src/xen-unstable.hg-rev-24593/tools/qemu-xen-dir-remote'
>    make[1]: *** [subdir-all-qemu-xen-dir] Error 2
>    make[1]: Leaving directory `/usr/src/xen-unstable.hg-rev-24593/tools'
>    make: *** [subdirs-all] Error 2
>    I do not understand what is causing this error. But I think it is good
>    that the xen developers know about this.
>    If anyone wants the whole output from the build, I have it saved and can
>    attach it if need be.

See above.

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:28:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrylc-0006Mp-Ba; Mon, 30 Jan 2012 21:28:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RrylZ-0006Mh-At
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:27:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327958868!12620403!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTEzNzEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8995 invoked from network); 30 Jan 2012 21:27:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 21:27:50 -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
	q0ULRjiM005992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 21:27:46 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
	q0ULRiOe016668
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 21:27:45 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0ULRiJC021913; Mon, 30 Jan 2012 15:27:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 13:27:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 59D64402BB; Mon, 30 Jan 2012 16:25:15 -0500 (EST)
Date: Mon, 30 Jan 2012 16:25:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120130212515.GA16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-17-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327934734-8908-17-git-send-email-wei.liu2@citrix.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.0A090201.4F270B52.003D,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 16/16] netfront: split event channels
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:45:34PM +0000, Wei Liu wrote:
> If this feature is not activated, rx_irq = tx_irq. See corresponding
> netback change log for details.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netfront.c |  147 ++++++++++++++++++++++++++++++++++----------
>  1 files changed, 115 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 32ec212..72c0429 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -98,7 +98,9 @@ struct netfront_info {
>  
>  	unsigned long rx_gso_checksum_fixup;
>  
> -	unsigned int evtchn;
> +	unsigned int split_evtchn;

bool?

> +	unsigned int tx_evtchn, rx_evtchn;
> +	unsigned int tx_irq, rx_irq;
>  	struct xenbus_device *xbdev;
>  
>  	spinlock_t   tx_lock;
> @@ -344,7 +346,7 @@ no_skb:
>   push:
>  	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
>  	if (notify)
> -		notify_remote_via_irq(np->netdev->irq);
> +		notify_remote_via_irq(np->rx_irq);
>  }
>  
>  static int xennet_open(struct net_device *dev)
> @@ -577,7 +579,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  
>  	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
>  	if (notify)
> -		notify_remote_via_irq(np->netdev->irq);
> +		notify_remote_via_irq(np->tx_irq);
>  
>  	u64_stats_update_begin(&stats->syncp);
>  	stats->tx_bytes += skb->len;
> @@ -1242,22 +1244,35 @@ static int xennet_set_features(struct net_device *dev, u32 features)
>  	return 0;
>  }
>  
> -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> +static irqreturn_t xennet_tx_interrupt(int irq, void *dev_id)
>  {
> -	struct net_device *dev = dev_id;
> -	struct netfront_info *np = netdev_priv(dev);
> +	struct netfront_info *np = dev_id;
> +	struct net_device *dev = np->netdev;
>  	unsigned long flags;
>  
>  	spin_lock_irqsave(&np->tx_lock, flags);
> +	xennet_tx_buf_gc(dev);
> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>  
> -	if (likely(netif_carrier_ok(dev))) {
> -		xennet_tx_buf_gc(dev);
> -		/* Under tx_lock: protects access to rx shared-ring indexes. */
> -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> -			napi_schedule(&np->napi);
> -	}
> +	return IRQ_HANDLED;
> +}
>  
> -	spin_unlock_irqrestore(&np->tx_lock, flags);
> +static irqreturn_t xennet_rx_interrupt(int irq, void *dev_id)
> +{
> +	struct netfront_info *np = dev_id;
> +	struct net_device *dev = np->netdev;
> +
> +	if (likely(netif_carrier_ok(dev)) &&
> +	    RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> +		napi_schedule(&np->napi);
> +
> +	return IRQ_HANDLED;
> +}
> +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> +{
> +	xennet_tx_interrupt(0, dev_id);
> +
> +	xennet_rx_interrupt(0, dev_id);
>  
>  	return IRQ_HANDLED;
>  }
> @@ -1436,9 +1451,14 @@ static void xennet_disconnect_backend(struct netfront_info *info)
>  	spin_unlock_irq(&info->tx_lock);
>  	spin_unlock_bh(&info->rx_lock);
>  
> -	if (info->netdev->irq)
> -		unbind_from_irqhandler(info->netdev->irq, info->netdev);
> -	info->evtchn = info->netdev->irq = 0;
> +	if (info->tx_irq && (info->tx_irq == info->rx_irq))
> +		unbind_from_irqhandler(info->tx_irq, info);
> +	if (info->tx_irq && (info->tx_irq != info->rx_irq)) {
> +		unbind_from_irqhandler(info->tx_irq, info);
> +		unbind_from_irqhandler(info->rx_irq, info);
> +	}
> +	info->tx_evtchn = info->tx_irq = 0;
> +	info->rx_evtchn = info->rx_irq = 0;
>  
>  	for (i = 0; i < info->tx_ring_pages; i++) {
>  		int ref = info->tx_ring_ref[i];
> @@ -1507,6 +1527,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	int err;
>  	struct net_device *netdev = info->netdev;
>  	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> +	unsigned int split_evtchn;
>  	int i, j;
>  
>  	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
> @@ -1515,7 +1536,6 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	}
>  	info->rx.sring = NULL;
>  	info->tx.sring = NULL;
> -	netdev->irq = 0;
>  
>  	err = xen_net_read_mac(dev, netdev->dev_addr);
>  	if (err) {
> @@ -1524,6 +1544,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	}
>  
>  	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "split-event-channels", "%u",


We don't want to call them 'feature-split-event-channels' ?

> +			   &split_evtchn);
> +	if (err < 0)
> +		split_evtchn = 0;
> +
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
>  			   "max-tx-ring-page-order", "%u",
>  			   &max_tx_ring_page_order);
>  	if (err < 0) {
> @@ -1589,20 +1615,59 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  		info->rx_ring_ref[j] = err;
>  	}
>  
> -	err = xenbus_alloc_evtchn(dev, &info->evtchn);
> -	if (err)
> -		goto alloc_evtchn_fail;
> +	if (!split_evtchn) {

Why not just move most of the code that deals with this
allocation in two seperate functions: setup_netfront_split
and setup_netfront_generic ?


> +		err = xenbus_alloc_evtchn(dev, &info->tx_evtchn);
> +		if (err)
> +			goto alloc_evtchn_fail;
>  
> -	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
> -					0, netdev->name, netdev);
> -	if (err < 0)
> -		goto bind_fail;
> -	netdev->irq = err;
> +		err = bind_evtchn_to_irqhandler(info->tx_evtchn,
> +						xennet_interrupt,
> +						0, netdev->name, info);
> +		if (err < 0)
> +			goto bind_fail;
> +		info->rx_evtchn = info->tx_evtchn;
> +		info->tx_irq = info->rx_irq = err;
> +		info->split_evtchn = 0;
> +		dev_info(&dev->dev, "single event channel, irq = %d\n",
> +			 info->tx_irq);
> +	} else {
> +		err = xenbus_alloc_evtchn(dev, &info->tx_evtchn);
> +		if (err)
> +			goto alloc_evtchn_fail;
> +		err = xenbus_alloc_evtchn(dev, &info->rx_evtchn);
> +		if (err) {
> +			xenbus_free_evtchn(dev, info->tx_evtchn);
> +			goto alloc_evtchn_fail;
> +		}
> +		err = bind_evtchn_to_irqhandler(info->tx_evtchn,
> +						xennet_tx_interrupt,
> +						0, netdev->name, info);
> +		if (err < 0)
> +			goto bind_fail;
> +		info->tx_irq = err;
> +		err = bind_evtchn_to_irqhandler(info->rx_evtchn,
> +						xennet_rx_interrupt,
> +						0, netdev->name, info);
> +		if (err < 0) {
> +			unbind_from_irqhandler(info->tx_irq, info);
> +			goto bind_fail;
> +		}
> +		info->rx_irq = err;
> +		info->split_evtchn = 1;
> +		dev_info(&dev->dev, "split event channels,"
> +			 " tx_irq = %d, rx_irq = %d\n",
> +			 info->tx_irq, info->rx_irq);
> +	}
>  
>  	return 0;
>  
>  bind_fail:
> -	xenbus_free_evtchn(dev, info->evtchn);
> +	if (!split_evtchn)
> +		xenbus_free_evtchn(dev, info->tx_evtchn);
> +	else {
> +		xenbus_free_evtchn(dev, info->tx_evtchn);
> +		xenbus_free_evtchn(dev, info->rx_evtchn);
> +	}
>  alloc_evtchn_fail:
>  	for (; j >= 0; j--) {
>  		int ref = info->rx_ring_ref[j];
> @@ -1690,11 +1755,27 @@ again:
>  		}
>  	}
>  
> -	err = xenbus_printf(xbt, dev->nodename,
> -			    "event-channel", "%u", info->evtchn);
> -	if (err) {
> -		message = "writing event-channel";
> -		goto abort_transaction;
> +
> +	if (!info->split_evtchn) {
> +		err = xenbus_printf(xbt, dev->nodename,
> +				    "event-channel", "%u", info->tx_evtchn);
> +		if (err) {
> +			message = "writing event-channel";
> +			goto abort_transaction;
> +		}
> +	} else {
> +		err = xenbus_printf(xbt, dev->nodename,
> +				    "event-channel-tx", "%u", info->tx_evtchn);
> +		if (err) {
> +			message = "writing event-channel-tx";
> +			goto abort_transaction;
> +		}
> +		err = xenbus_printf(xbt, dev->nodename,
> +				    "event-channel-rx", "%u", info->rx_evtchn);
> +		if (err) {
> +			message = "writing event-channel-rx";
> +			goto abort_transaction;
> +		}
>  	}
>  
>  	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
> @@ -1808,7 +1889,9 @@ static int xennet_connect(struct net_device *dev)
>  	 * packets.
>  	 */
>  	netif_carrier_on(np->netdev);
> -	notify_remote_via_irq(np->netdev->irq);
> +	notify_remote_via_irq(np->tx_irq);
> +	if (np->split_evtchn)
> +		notify_remote_via_irq(np->rx_irq);
>  	xennet_tx_buf_gc(dev);
>  	xennet_alloc_rx_buffers(dev);
>  
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:28:28 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21:28:28 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrylc-0006Mp-Ba; Mon, 30 Jan 2012 21:28:00 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RrylZ-0006Mh-At
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:27:57 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327958868!12620403!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTEzNzEz\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8995 invoked from network); 30 Jan 2012 21:27:50 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 30 Jan 2012 21:27:50 -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
	q0ULRjiM005992
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 21:27:46 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
	q0ULRiOe016668
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 21:27:45 GMT
Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0ULRiJC021913; Mon, 30 Jan 2012 15:27:44 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 13:27:44 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 59D64402BB; Mon, 30 Jan 2012 16:25:15 -0500 (EST)
Date: Mon, 30 Jan 2012 16:25:15 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120130212515.GA16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-17-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327934734-8908-17-git-send-email-wei.liu2@citrix.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.0A090201.4F270B52.003D,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 16/16] netfront: split event channels
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:45:34PM +0000, Wei Liu wrote:
> If this feature is not activated, rx_irq = tx_irq. See corresponding
> netback change log for details.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netfront.c |  147 ++++++++++++++++++++++++++++++++++----------
>  1 files changed, 115 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 32ec212..72c0429 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -98,7 +98,9 @@ struct netfront_info {
>  
>  	unsigned long rx_gso_checksum_fixup;
>  
> -	unsigned int evtchn;
> +	unsigned int split_evtchn;

bool?

> +	unsigned int tx_evtchn, rx_evtchn;
> +	unsigned int tx_irq, rx_irq;
>  	struct xenbus_device *xbdev;
>  
>  	spinlock_t   tx_lock;
> @@ -344,7 +346,7 @@ no_skb:
>   push:
>  	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->rx, notify);
>  	if (notify)
> -		notify_remote_via_irq(np->netdev->irq);
> +		notify_remote_via_irq(np->rx_irq);
>  }
>  
>  static int xennet_open(struct net_device *dev)
> @@ -577,7 +579,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
>  
>  	RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(&np->tx, notify);
>  	if (notify)
> -		notify_remote_via_irq(np->netdev->irq);
> +		notify_remote_via_irq(np->tx_irq);
>  
>  	u64_stats_update_begin(&stats->syncp);
>  	stats->tx_bytes += skb->len;
> @@ -1242,22 +1244,35 @@ static int xennet_set_features(struct net_device *dev, u32 features)
>  	return 0;
>  }
>  
> -static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> +static irqreturn_t xennet_tx_interrupt(int irq, void *dev_id)
>  {
> -	struct net_device *dev = dev_id;
> -	struct netfront_info *np = netdev_priv(dev);
> +	struct netfront_info *np = dev_id;
> +	struct net_device *dev = np->netdev;
>  	unsigned long flags;
>  
>  	spin_lock_irqsave(&np->tx_lock, flags);
> +	xennet_tx_buf_gc(dev);
> +	spin_unlock_irqrestore(&np->tx_lock, flags);
>  
> -	if (likely(netif_carrier_ok(dev))) {
> -		xennet_tx_buf_gc(dev);
> -		/* Under tx_lock: protects access to rx shared-ring indexes. */
> -		if (RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> -			napi_schedule(&np->napi);
> -	}
> +	return IRQ_HANDLED;
> +}
>  
> -	spin_unlock_irqrestore(&np->tx_lock, flags);
> +static irqreturn_t xennet_rx_interrupt(int irq, void *dev_id)
> +{
> +	struct netfront_info *np = dev_id;
> +	struct net_device *dev = np->netdev;
> +
> +	if (likely(netif_carrier_ok(dev)) &&
> +	    RING_HAS_UNCONSUMED_RESPONSES(&np->rx))
> +		napi_schedule(&np->napi);
> +
> +	return IRQ_HANDLED;
> +}
> +static irqreturn_t xennet_interrupt(int irq, void *dev_id)
> +{
> +	xennet_tx_interrupt(0, dev_id);
> +
> +	xennet_rx_interrupt(0, dev_id);
>  
>  	return IRQ_HANDLED;
>  }
> @@ -1436,9 +1451,14 @@ static void xennet_disconnect_backend(struct netfront_info *info)
>  	spin_unlock_irq(&info->tx_lock);
>  	spin_unlock_bh(&info->rx_lock);
>  
> -	if (info->netdev->irq)
> -		unbind_from_irqhandler(info->netdev->irq, info->netdev);
> -	info->evtchn = info->netdev->irq = 0;
> +	if (info->tx_irq && (info->tx_irq == info->rx_irq))
> +		unbind_from_irqhandler(info->tx_irq, info);
> +	if (info->tx_irq && (info->tx_irq != info->rx_irq)) {
> +		unbind_from_irqhandler(info->tx_irq, info);
> +		unbind_from_irqhandler(info->rx_irq, info);
> +	}
> +	info->tx_evtchn = info->tx_irq = 0;
> +	info->rx_evtchn = info->rx_irq = 0;
>  
>  	for (i = 0; i < info->tx_ring_pages; i++) {
>  		int ref = info->tx_ring_ref[i];
> @@ -1507,6 +1527,7 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	int err;
>  	struct net_device *netdev = info->netdev;
>  	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> +	unsigned int split_evtchn;
>  	int i, j;
>  
>  	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
> @@ -1515,7 +1536,6 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	}
>  	info->rx.sring = NULL;
>  	info->tx.sring = NULL;
> -	netdev->irq = 0;
>  
>  	err = xen_net_read_mac(dev, netdev->dev_addr);
>  	if (err) {
> @@ -1524,6 +1544,12 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	}
>  
>  	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "split-event-channels", "%u",


We don't want to call them 'feature-split-event-channels' ?

> +			   &split_evtchn);
> +	if (err < 0)
> +		split_evtchn = 0;
> +
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
>  			   "max-tx-ring-page-order", "%u",
>  			   &max_tx_ring_page_order);
>  	if (err < 0) {
> @@ -1589,20 +1615,59 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  		info->rx_ring_ref[j] = err;
>  	}
>  
> -	err = xenbus_alloc_evtchn(dev, &info->evtchn);
> -	if (err)
> -		goto alloc_evtchn_fail;
> +	if (!split_evtchn) {

Why not just move most of the code that deals with this
allocation in two seperate functions: setup_netfront_split
and setup_netfront_generic ?


> +		err = xenbus_alloc_evtchn(dev, &info->tx_evtchn);
> +		if (err)
> +			goto alloc_evtchn_fail;
>  
> -	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
> -					0, netdev->name, netdev);
> -	if (err < 0)
> -		goto bind_fail;
> -	netdev->irq = err;
> +		err = bind_evtchn_to_irqhandler(info->tx_evtchn,
> +						xennet_interrupt,
> +						0, netdev->name, info);
> +		if (err < 0)
> +			goto bind_fail;
> +		info->rx_evtchn = info->tx_evtchn;
> +		info->tx_irq = info->rx_irq = err;
> +		info->split_evtchn = 0;
> +		dev_info(&dev->dev, "single event channel, irq = %d\n",
> +			 info->tx_irq);
> +	} else {
> +		err = xenbus_alloc_evtchn(dev, &info->tx_evtchn);
> +		if (err)
> +			goto alloc_evtchn_fail;
> +		err = xenbus_alloc_evtchn(dev, &info->rx_evtchn);
> +		if (err) {
> +			xenbus_free_evtchn(dev, info->tx_evtchn);
> +			goto alloc_evtchn_fail;
> +		}
> +		err = bind_evtchn_to_irqhandler(info->tx_evtchn,
> +						xennet_tx_interrupt,
> +						0, netdev->name, info);
> +		if (err < 0)
> +			goto bind_fail;
> +		info->tx_irq = err;
> +		err = bind_evtchn_to_irqhandler(info->rx_evtchn,
> +						xennet_rx_interrupt,
> +						0, netdev->name, info);
> +		if (err < 0) {
> +			unbind_from_irqhandler(info->tx_irq, info);
> +			goto bind_fail;
> +		}
> +		info->rx_irq = err;
> +		info->split_evtchn = 1;
> +		dev_info(&dev->dev, "split event channels,"
> +			 " tx_irq = %d, rx_irq = %d\n",
> +			 info->tx_irq, info->rx_irq);
> +	}
>  
>  	return 0;
>  
>  bind_fail:
> -	xenbus_free_evtchn(dev, info->evtchn);
> +	if (!split_evtchn)
> +		xenbus_free_evtchn(dev, info->tx_evtchn);
> +	else {
> +		xenbus_free_evtchn(dev, info->tx_evtchn);
> +		xenbus_free_evtchn(dev, info->rx_evtchn);
> +	}
>  alloc_evtchn_fail:
>  	for (; j >= 0; j--) {
>  		int ref = info->rx_ring_ref[j];
> @@ -1690,11 +1755,27 @@ again:
>  		}
>  	}
>  
> -	err = xenbus_printf(xbt, dev->nodename,
> -			    "event-channel", "%u", info->evtchn);
> -	if (err) {
> -		message = "writing event-channel";
> -		goto abort_transaction;
> +
> +	if (!info->split_evtchn) {
> +		err = xenbus_printf(xbt, dev->nodename,
> +				    "event-channel", "%u", info->tx_evtchn);
> +		if (err) {
> +			message = "writing event-channel";
> +			goto abort_transaction;
> +		}
> +	} else {
> +		err = xenbus_printf(xbt, dev->nodename,
> +				    "event-channel-tx", "%u", info->tx_evtchn);
> +		if (err) {
> +			message = "writing event-channel-tx";
> +			goto abort_transaction;
> +		}
> +		err = xenbus_printf(xbt, dev->nodename,
> +				    "event-channel-rx", "%u", info->rx_evtchn);
> +		if (err) {
> +			message = "writing event-channel-rx";
> +			goto abort_transaction;
> +		}
>  	}
>  
>  	err = xenbus_printf(xbt, dev->nodename, "request-rx-copy", "%u",
> @@ -1808,7 +1889,9 @@ static int xennet_connect(struct net_device *dev)
>  	 * packets.
>  	 */
>  	netif_carrier_on(np->netdev);
> -	notify_remote_via_irq(np->netdev->irq);
> +	notify_remote_via_irq(np->tx_irq);
> +	if (np->split_evtchn)
> +		notify_remote_via_irq(np->rx_irq);
>  	xennet_tx_buf_gc(dev);
>  	xennet_alloc_rx_buffers(dev);
>  
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:42:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21:42:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rryz1-0006Ya-Cd; Mon, 30 Jan 2012 21:41:51 +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 1Rryyy-0006YR-LY
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:41:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327959701!12621368!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29369 invoked from network); 30 Jan 2012 21:41:41 -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;
	30 Jan 2012 21:41: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
	q0ULfaeN019656; Mon, 30 Jan 2012 21:41:36 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 q0ULfYiJ025546; 
	Mon, 30 Jan 2012 16:41:35 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 16:41:31 -0500
Message-Id: <1327959691-9284-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-12-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, ian.campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/24 v2] mini-os: create app-specific
	configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
[Change from v1: ioemu-minios.cfg needs CONFIG_START_NETWORK=n]
---
 extras/mini-os/Makefile  |   52 ++++++++++++++++++++++++++++++++++++++++-----
 extras/mini-os/main.c    |   16 +++++++-------
 extras/mini-os/minios.mk |    4 +-
 stubdom/Makefile         |    8 +++---
 stubdom/grub/minios.cfg  |    2 +
 stubdom/ioemu-minios.cfg |    2 +
 6 files changed, 64 insertions(+), 20 deletions(-)
 create mode 100644 stubdom/c/minios.cfg
 create mode 100644 stubdom/caml/minios.cfg
 create mode 100644 stubdom/grub/minios.cfg
 create mode 100644 stubdom/ioemu-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c4d26f0..48d0d21 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,10 +8,25 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(MINIOS_CONFIG),)
 include Config.mk
+else
+EXTRA_DEPS += $(MINIOS_CONFIG)
+include $(MINIOS_CONFIG)
 endif
 
+# Configuration defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+CONFIG_QEMU_XS_ARGS ?= n
+
+# Export config items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
 # Include common mini-os makerules.
 include minios.mk
 
@@ -34,13 +49,38 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e9dbf02..d4da2bb 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/grub/minios.cfg b/stubdom/grub/minios.cfg
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/stubdom/grub/minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
new file mode 100644
index 0000000..bbf1d08
--- /dev/null
+++ b/stubdom/ioemu-minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_QEMU_XS_ARGS=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:42:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21:42:18 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rryz1-0006Ya-Cd; Mon, 30 Jan 2012 21:41:51 +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 1Rryyy-0006YR-LY
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:41:49 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-13.tower-216.messagelabs.com!1327959701!12621368!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29369 invoked from network); 30 Jan 2012 21:41:41 -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;
	30 Jan 2012 21:41: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
	q0ULfaeN019656; Mon, 30 Jan 2012 21:41:36 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 q0ULfYiJ025546; 
	Mon, 30 Jan 2012 16:41:35 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Mon, 30 Jan 2012 16:41:31 -0500
Message-Id: <1327959691-9284-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1327702543-25211-12-git-send-email-dgdegra@tycho.nsa.gov>
References: <1327702543-25211-12-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>, ian.campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [Xen-devel] [PATCH 11/24 v2] mini-os: create app-specific
	configuration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 using CONFIG_QEMU and CONFIG_GRUB to enable or disable minios
code, create CONFIG_ items for features and use application-specific
configuration files to enable or disable the features.

The configuration flags are currently added to the compiler command
line; as the number of flags grows this may need to move to a header.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
[Change from v1: ioemu-minios.cfg needs CONFIG_START_NETWORK=n]
---
 extras/mini-os/Makefile  |   52 ++++++++++++++++++++++++++++++++++++++++-----
 extras/mini-os/main.c    |   16 +++++++-------
 extras/mini-os/minios.mk |    4 +-
 stubdom/Makefile         |    8 +++---
 stubdom/grub/minios.cfg  |    2 +
 stubdom/ioemu-minios.cfg |    2 +
 6 files changed, 64 insertions(+), 20 deletions(-)
 create mode 100644 stubdom/c/minios.cfg
 create mode 100644 stubdom/caml/minios.cfg
 create mode 100644 stubdom/grub/minios.cfg
 create mode 100644 stubdom/ioemu-minios.cfg

diff --git a/extras/mini-os/Makefile b/extras/mini-os/Makefile
index c4d26f0..48d0d21 100644
--- a/extras/mini-os/Makefile
+++ b/extras/mini-os/Makefile
@@ -8,10 +8,25 @@ export XEN_ROOT = $(CURDIR)/../..
 include $(XEN_ROOT)/Config.mk
 OBJ_DIR ?= $(CURDIR)
 
-ifneq ($(stubdom),y)
+ifeq ($(MINIOS_CONFIG),)
 include Config.mk
+else
+EXTRA_DEPS += $(MINIOS_CONFIG)
+include $(MINIOS_CONFIG)
 endif
 
+# Configuration defaults
+CONFIG_START_NETWORK ?= y
+CONFIG_SPARSE_BSS ?= y
+CONFIG_QEMU_XS_ARGS ?= n
+
+# Export config items as compiler directives
+flags-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
+flags-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
+flags-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
+
+DEF_CFLAGS += $(flags-y)
+
 # Include common mini-os makerules.
 include minios.mk
 
@@ -34,13 +49,38 @@ TARGET := mini-os
 # Subdirectories common to mini-os
 SUBDIRS := lib xenbus console
 
+src-y += blkfront.c
+src-y += daytime.c
+src-y += events.c
+src-y += fbfront.c
+src-y += gntmap.c
+src-y += gnttab.c
+src-y += hypervisor.c
+src-y += kernel.c
+src-y += lock.c
+src-y += main.c
+src-y += mm.c
+src-y += netfront.c
+src-y += pcifront.c
+src-y += sched.c
+
+src-y += lib/ctype.c
+src-y += lib/math.c
+src-y += lib/printf.c
+src-y += lib/stack_chk_fail.c
+src-y += lib/string.c
+src-y += lib/sys.c
+src-y += lib/xmalloc.c
+src-y += lib/xs.c
+
+src-y += xenbus/xenbus.c
+
+src-y += console/console.c
+src-y += console/xencons_ring.c
+
 # The common mini-os objects to build.
 APP_OBJS :=
-OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard *.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard lib/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard xenbus/*.c))
-OBJS += $(patsubst %.c,$(OBJ_DIR)/%.o,$(wildcard console/*.c))
-
+OBJS := $(patsubst %.c,$(OBJ_DIR)/%.o,$(src-y))
 
 .PHONY: default
 default: $(OBJ_DIR)/$(TARGET)
diff --git a/extras/mini-os/main.c b/extras/mini-os/main.c
index b95b889..aeda548 100644
--- a/extras/mini-os/main.c
+++ b/extras/mini-os/main.c
@@ -43,13 +43,13 @@ extern char __app_bss_start, __app_bss_end;
 static void call_main(void *p)
 {
     char *c, quote;
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *domargs, *msg;
 #endif
     int argc;
     char **argv;
     char *envp[] = { NULL };
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     char *vm;
     char path[128];
     int domid;
@@ -60,15 +60,15 @@ static void call_main(void *p)
      * crashing. */
     //sleep(1);
 
-#ifndef CONFIG_GRUB
+#ifdef CONFIG_SPARSE_BSS
     sparse((unsigned long) &__app_bss_start, &__app_bss_end - &__app_bss_start);
-#if defined(HAVE_LWIP) && !defined(CONFIG_QEMU)
-    start_networking();
 #endif
+#if defined(HAVE_LWIP) && defined(CONFIG_START_NETWORK)
+    start_networking();
 #endif
     create_thread("pcifront", pcifront_watches, NULL);
 
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     /* Fetch argc, argv from XenStore */
     domid = xenbus_read_integer("target");
     if (domid == -1) {
@@ -132,7 +132,7 @@ static void call_main(void *p)
 #define PARSE_ARGS_STORE(ARGS) PARSE_ARGS(ARGS, argv[argc++] = c, memmove(c, c + 1, strlen(c + 1) + 1), *c++ = 0)
 
     PARSE_ARGS_COUNT((char*)start_info.cmd_line);
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_COUNT(domargs);
 #endif
 
@@ -141,7 +141,7 @@ static void call_main(void *p)
     argc = 1;
 
     PARSE_ARGS_STORE((char*)start_info.cmd_line)
-#ifdef CONFIG_QEMU
+#ifdef CONFIG_QEMU_XS_ARGS
     PARSE_ARGS_STORE(domargs)
 #endif
 
diff --git a/extras/mini-os/minios.mk b/extras/mini-os/minios.mk
index 698648a..48ed768 100644
--- a/extras/mini-os/minios.mk
+++ b/extras/mini-os/minios.mk
@@ -39,8 +39,8 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS = $(MINI-OS_ROOT)/minios.mk \
-		$(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
 HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
diff --git a/stubdom/Makefile b/stubdom/Makefile
index e9dbf02..d4da2bb 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -341,19 +341,19 @@ grub: grub-upstream $(CROSS_ROOT)
 .PHONY: ioemu-stubdom
 ioemu-stubdom: APP_OBJS=$(CURDIR)/ioemu/i386-stubdom/qemu.a $(CURDIR)/ioemu/i386-stubdom/libqemu.a $(CURDIR)/ioemu/libqemu_common.a
 ioemu-stubdom: mini-os-$(XEN_TARGET_ARCH)-ioemu lwip-$(XEN_TARGET_ARCH) libxc ioemu
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_QEMU $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/ioemu-minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(APP_OBJS)"
 
 .PHONY: caml-stubdom
 caml-stubdom: mini-os-$(XEN_TARGET_ARCH)-caml lwip-$(XEN_TARGET_ARCH) libxc cross-ocaml caml
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_CAML $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/caml/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS="$(CURDIR)/caml/main-caml.o $(CURDIR)/caml/caml.o $(CAMLLIB)/libasmrun.a"
 
 .PHONY: c-stubdom
 c-stubdom: mini-os-$(XEN_TARGET_ARCH)-c lwip-$(XEN_TARGET_ARCH) libxc c
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_C $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/c/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< LWIPDIR=$(CURDIR)/lwip-$(XEN_TARGET_ARCH) APP_OBJS=$(CURDIR)/c/main.a
 
 .PHONY: pv-grub
 pv-grub: mini-os-$(XEN_TARGET_ARCH)-grub libxc grub
-	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="-DCONFIG_GRUB $(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
+	DEF_CPPFLAGS="$(TARGET_CPPFLAGS)" DEF_CFLAGS="$(TARGET_CFLAGS)" DEF_LDFLAGS="$(TARGET_LDFLAGS)" MINIOS_CONFIG="$(CURDIR)/grub/minios.cfg" $(CROSS_MAKE) -C $(MINI_OS) OBJ_DIR=$(CURDIR)/$< APP_OBJS=$(CURDIR)/grub-$(XEN_TARGET_ARCH)/main.a
 
 #########
 # install
diff --git a/stubdom/c/minios.cfg b/stubdom/c/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/caml/minios.cfg b/stubdom/caml/minios.cfg
new file mode 100644
index 0000000..e69de29
diff --git a/stubdom/grub/minios.cfg b/stubdom/grub/minios.cfg
new file mode 100644
index 0000000..40cfa68
--- /dev/null
+++ b/stubdom/grub/minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_SPARSE_BSS=n
diff --git a/stubdom/ioemu-minios.cfg b/stubdom/ioemu-minios.cfg
new file mode 100644
index 0000000..bbf1d08
--- /dev/null
+++ b/stubdom/ioemu-minios.cfg
@@ -0,0 +1,2 @@
+CONFIG_START_NETWORK=n
+CONFIG_QEMU_XS_ARGS=y
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:42:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RryzF-0006Z8-Cd; Mon, 30 Jan 2012 21:42:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RryzC-0006Yx-Ak
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:42:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327959670!52337547!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE1NDI5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10191 invoked from network); 30 Jan 2012 21:41:11 -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; 30 Jan 2012 21:41:11 -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
	q0ULfu5v023523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 21:41:57 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
	q0ULftm9007113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 21:41:56 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
	q0ULftn3032326; Mon, 30 Jan 2012 15:41:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 13:41:55 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 641F7402B1; Mon, 30 Jan 2012 16:39:26 -0500 (EST)
Date: Mon, 30 Jan 2012 16:39:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120130213926.GB16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327934734-8908-16-git-send-email-wei.liu2@citrix.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.4F270EA6.0020,ss=1,re=-2.300,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:45:33PM +0000, Wei Liu wrote:
> Use DMA API to allocate ring pages, because we need to get machine
> contiginous memory.

> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netfront.c |  258 ++++++++++++++++++++++++++++++++------------
>  1 files changed, 187 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 01f589d..32ec212 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -66,9 +66,18 @@ struct netfront_cb {
>  
>  #define GRANT_INVALID_REF	0
>  
> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> +#define XENNET_MAX_RING_PAGE_ORDER 2
> +#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
> +
> +#define NET_TX_RING_SIZE(_nr_pages)					\
> +	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> +#define NET_RX_RING_SIZE(_nr_pages)					\
> +	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> +
> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +
> +#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE
>  
>  struct netfront_stats {
>  	u64			rx_packets;
> @@ -84,12 +93,20 @@ struct netfront_info {
>  
>  	struct napi_struct napi;
>  
> +	/* Statistics */
> +	struct netfront_stats __percpu *stats;
> +
> +	unsigned long rx_gso_checksum_fixup;
> +
>  	unsigned int evtchn;
>  	struct xenbus_device *xbdev;
>  
>  	spinlock_t   tx_lock;
>  	struct xen_netif_tx_front_ring tx;
> -	int tx_ring_ref;
> +	dma_addr_t tx_ring_dma_handle;
> +	int tx_ring_ref[XENNET_MAX_RING_PAGES];
> +	int tx_ring_page_order;
> +	int tx_ring_pages;
>  
>  	/*
>  	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
> @@ -103,36 +120,34 @@ struct netfront_info {
>  	union skb_entry {
>  		struct sk_buff *skb;
>  		unsigned long link;
> -	} tx_skbs[NET_TX_RING_SIZE];
> +	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
>  	grant_ref_t gref_tx_head;
> -	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
> +	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
>  	unsigned tx_skb_freelist;
>  
>  	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
>  	struct xen_netif_rx_front_ring rx;
> -	int rx_ring_ref;
> +	dma_addr_t rx_ring_dma_handle;
> +	int rx_ring_ref[XENNET_MAX_RING_PAGES];
> +	int rx_ring_page_order;
> +	int rx_ring_pages;
>  
>  	/* Receive-ring batched refills. */
>  #define RX_MIN_TARGET 8
>  #define RX_DFL_MIN_TARGET 64
> -#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> +#define RX_MAX_TARGET XENNET_MAX_RX_RING_SIZE
>  	unsigned rx_min_target, rx_max_target, rx_target;
>  	struct sk_buff_head rx_batch;
>  
>  	struct timer_list rx_refill_timer;
>  
> -	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
> +	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
>  	grant_ref_t gref_rx_head;
> -	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
> -
> -	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
> -	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
> -	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
> -
> -	/* Statistics */
> -	struct netfront_stats __percpu *stats;
> +	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
>  
> -	unsigned long rx_gso_checksum_fixup;
> +	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
> +	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
> +	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
>  };
>  
>  struct netfront_rx_info {
> @@ -170,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
>  	return id;
>  }
>  
> -static int xennet_rxidx(RING_IDX idx)
> +static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
>  {
> -	return idx & (NET_RX_RING_SIZE - 1);
> +	return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
>  }
>  
>  static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
>  					 RING_IDX ri)
>  {
> -	int i = xennet_rxidx(ri);
> +	int i = xennet_rxidx(ri, np);
>  	struct sk_buff *skb = np->rx_skbs[i];
>  	np->rx_skbs[i] = NULL;
>  	return skb;
> @@ -187,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
>  static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
>  					    RING_IDX ri)
>  {
> -	int i = xennet_rxidx(ri);
> +	int i = xennet_rxidx(ri, np);
>  	grant_ref_t ref = np->grant_rx_ref[i];
>  	np->grant_rx_ref[i] = GRANT_INVALID_REF;
>  	return ref;
> @@ -300,7 +315,7 @@ no_skb:
>  
>  		skb->dev = dev;
>  
> -		id = xennet_rxidx(req_prod + i);
> +		id = xennet_rxidx(req_prod + i, np);
>  
>  		BUG_ON(np->rx_skbs[id]);
>  		np->rx_skbs[id] = skb;
> @@ -596,7 +611,7 @@ static int xennet_close(struct net_device *dev)
>  static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
>  				grant_ref_t ref)
>  {
> -	int new = xennet_rxidx(np->rx.req_prod_pvt);
> +	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
>  
>  	BUG_ON(np->rx_skbs[new]);
>  	np->rx_skbs[new] = skb;
> @@ -1089,7 +1104,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
>  	struct sk_buff *skb;
>  	int i;
>  
> -	for (i = 0; i < NET_TX_RING_SIZE; i++) {
> +	for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
>  		/* Skip over entries which are actually freelist references */
>  		if (skb_entry_is_link(&np->tx_skbs[i]))
>  			continue;
> @@ -1123,7 +1138,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
>  
>  	spin_lock_bh(&np->rx_lock);
>  
> -	for (id = 0; id < NET_RX_RING_SIZE; id++) {
> +	for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
>  		ref = np->grant_rx_ref[id];
>  		if (ref == GRANT_INVALID_REF) {
>  			unused++;
> @@ -1305,13 +1320,13 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
>  
>  	/* Initialise tx_skbs as a free chain containing every entry. */
>  	np->tx_skb_freelist = 0;
> -	for (i = 0; i < NET_TX_RING_SIZE; i++) {
> +	for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
>  		skb_entry_set_link(&np->tx_skbs[i], i+1);
>  		np->grant_tx_ref[i] = GRANT_INVALID_REF;
>  	}
>  
>  	/* Clear out rx_skbs */
> -	for (i = 0; i < NET_RX_RING_SIZE; i++) {
> +	for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
>  		np->rx_skbs[i] = NULL;
>  		np->grant_rx_ref[i] = GRANT_INVALID_REF;
>  	}
> @@ -1409,15 +1424,11 @@ static int __devinit netfront_probe(struct xenbus_device *dev,
>  	return err;
>  }
>  
> -static void xennet_end_access(int ref, void *page)
> -{
> -	/* This frees the page as a side-effect */
> -	if (ref != GRANT_INVALID_REF)
> -		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
> -}
> -
>  static void xennet_disconnect_backend(struct netfront_info *info)
>  {
> +	int i;
> +	struct xenbus_device *dev = info->xbdev;
> +
>  	/* Stop old i/f to prevent errors whilst we rebuild the state. */
>  	spin_lock_bh(&info->rx_lock);
>  	spin_lock_irq(&info->tx_lock);
> @@ -1429,12 +1440,24 @@ static void xennet_disconnect_backend(struct netfront_info *info)
>  		unbind_from_irqhandler(info->netdev->irq, info->netdev);
>  	info->evtchn = info->netdev->irq = 0;
>  
> -	/* End access and free the pages */
> -	xennet_end_access(info->tx_ring_ref, info->tx.sring);
> -	xennet_end_access(info->rx_ring_ref, info->rx.sring);
> +	for (i = 0; i < info->tx_ring_pages; i++) {
> +		int ref = info->tx_ring_ref[i];
> +		gnttab_end_foreign_access_ref(ref, 0);
> +		info->tx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
> +	dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> +			  (void *)info->tx.sring,
> +			  info->tx_ring_dma_handle);
> +
> +	for (i = 0; i < info->rx_ring_pages; i++) {
> +		int ref = info->rx_ring_ref[i];
> +		gnttab_end_foreign_access_ref(ref, 0);
> +		info->rx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
> +	dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
> +			  (void *)info->rx.sring,
> +			  info->rx_ring_dma_handle);
>  
> -	info->tx_ring_ref = GRANT_INVALID_REF;
> -	info->rx_ring_ref = GRANT_INVALID_REF;
>  	info->tx.sring = NULL;
>  	info->rx.sring = NULL;
>  }
> @@ -1483,9 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	struct xen_netif_rx_sring *rxs;
>  	int err;
>  	struct net_device *netdev = info->netdev;
> +	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> +	int i, j;
>  
> -	info->tx_ring_ref = GRANT_INVALID_REF;
> -	info->rx_ring_ref = GRANT_INVALID_REF;
> +	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
> +		info->tx_ring_ref[i] = GRANT_INVALID_REF;
> +		info->rx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
>  	info->rx.sring = NULL;
>  	info->tx.sring = NULL;
>  	netdev->irq = 0;
> @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  		goto fail;
>  	}
>  
> -	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "max-tx-ring-page-order", "%u",
> +			   &max_tx_ring_page_order);
> +	if (err < 0) {
> +		info->tx_ring_page_order = 0;
> +		dev_info(&dev->dev, "single tx ring\n");
> +	} else {
> +		info->tx_ring_page_order = max_tx_ring_page_order;
> +		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> +			 max_tx_ring_page_order);
> +	}
> +	info->tx_ring_pages = (1U << info->tx_ring_page_order);
> +
> +	txs = (struct xen_netif_tx_sring *)
> +		dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> +				   &info->tx_ring_dma_handle,
> +				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);

Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
clue whether you are OK getting pages under 4GB or above it (so 64-bit support).

If you don't supply a 'dev' it will assume 4GB. But when you are run this as a
pure PV guest that won't matter the slighest b/I there are no DMA code in action
(well, there is dma_alloc_coherent - which looking at the code would NULL it seems).

Anyhow, if you get to have more than 4GB in the guest or do PCI passthrough and use
'iommu=soft'- at which point the Xen SWIOTLB will kick and you will end up 'swizzling'
the pages to be under 4GB. That can be fixed if you declerae a 'fake' device where you set
the coherent_dma_mask to DMA_BIT_MASK(64).

But if you boot the guest under HVM, then it will use the generic SWIOTLB code, which
won't guaranteeing the pages to be "machine" contingous but will be "guest machine"
contingous. Is that sufficient for this?

How did you test this? Did you supply iommu=soft  to your guest or booted it
with more than 4GB?


>  	if (!txs) {
>  		err = -ENOMEM;
>  		xenbus_dev_fatal(dev, err, "allocating tx ring page");
>  		goto fail;
>  	}
>  	SHARED_RING_INIT(txs);
> -	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
> +	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
> +
> +	for (i = 0; i < info->tx_ring_pages; i++) {
> +		void *addr = (void *)((unsigned long)txs + PAGE_SIZE * i);
> +		err = xenbus_grant_ring(dev, virt_to_mfn(addr));
> +		if (err < 0)
> +			goto grant_tx_ring_fail;
> +		info->tx_ring_ref[i] = err;
> +	}
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "max-rx-ring-page-order", "%u",
> +			   &max_rx_ring_page_order);
>  	if (err < 0) {
> -		free_page((unsigned long)txs);
> -		goto fail;
> +		info->rx_ring_page_order = 0;
> +		dev_info(&dev->dev, "single rx ring\n");
> +	} else {
> +		info->rx_ring_page_order = max_rx_ring_page_order;
> +		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
> +			 max_rx_ring_page_order);
>  	}
> +	info->rx_ring_pages = (1U << info->rx_ring_page_order);
>  
> -	info->tx_ring_ref = err;
> -	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> +	rxs = (struct xen_netif_rx_sring *)
> +		dma_alloc_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
> +				   &info->rx_ring_dma_handle,
> +				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
>  	if (!rxs) {
>  		err = -ENOMEM;
>  		xenbus_dev_fatal(dev, err, "allocating rx ring page");
> -		goto fail;
> +		goto alloc_rx_ring_fail;
>  	}
>  	SHARED_RING_INIT(rxs);
> -	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
> -
> -	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
> -	if (err < 0) {
> -		free_page((unsigned long)rxs);
> -		goto fail;
> +	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
> +
> +	for (j = 0; j < info->rx_ring_pages; j++) {
> +		void *addr = (void *)((unsigned long)rxs + PAGE_SIZE * j);
> +		err = xenbus_grant_ring(dev, virt_to_mfn(addr));
> +		if (err < 0)
> +			goto grant_rx_ring_fail;
> +		info->rx_ring_ref[j] = err;
>  	}
> -	info->rx_ring_ref = err;
>  
>  	err = xenbus_alloc_evtchn(dev, &info->evtchn);
>  	if (err)
> -		goto fail;
> +		goto alloc_evtchn_fail;
>  
>  	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
>  					0, netdev->name, netdev);
>  	if (err < 0)
> -		goto fail;
> +		goto bind_fail;
>  	netdev->irq = err;
> +
>  	return 0;
>  
> - fail:
> +bind_fail:
> +	xenbus_free_evtchn(dev, info->evtchn);
> +alloc_evtchn_fail:
> +	for (; j >= 0; j--) {
> +		int ref = info->rx_ring_ref[j];
> +		gnttab_end_foreign_access_ref(ref, 0);
> +		info->rx_ring_ref[j] = GRANT_INVALID_REF;
> +	}
> +grant_rx_ring_fail:
> +	dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
> +			  (void *)rxs, info->rx_ring_dma_handle);
> +alloc_rx_ring_fail:
> +	for (; i >= 0; i--) {
> +		int ref = info->tx_ring_ref[i];
> +		gnttab_end_foreign_access_ref(ref, 0);
> +		info->tx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
> +grant_tx_ring_fail:
> +	dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> +			  (void *)txs, info->tx_ring_dma_handle);
> +fail:
>  	return err;
>  }
>  
> @@ -1550,6 +1632,7 @@ static int talk_to_netback(struct xenbus_device *dev,
>  	const char *message;
>  	struct xenbus_transaction xbt;
>  	int err;
> +	int i;
>  
>  	/* Create shared ring, alloc event channel. */
>  	err = setup_netfront(dev, info);
> @@ -1563,18 +1646,50 @@ again:
>  		goto destroy_ring;
>  	}
>  
> -	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> -			    info->tx_ring_ref);
> -	if (err) {
> -		message = "writing tx ring-ref";
> -		goto abort_transaction;
> +	if (info->tx_ring_page_order == 0)
> +		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> +				    info->tx_ring_ref[0]);
> +	else {
> +		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
> +				    info->tx_ring_page_order);
> +		if (err) {
> +			message = "writing tx ring-ref";
> +			goto abort_transaction;
> +		}
> +		for (i = 0; i < info->tx_ring_pages; i++) {
> +			char name[sizeof("tx-ring-ref")+2];
> +			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
> +			err = xenbus_printf(xbt, dev->nodename, name, "%u",
> +					    info->tx_ring_ref[i]);
> +			if (err) {
> +				message = "writing tx ring-ref";
> +				goto abort_transaction;
> +			}
> +		}
>  	}
> -	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> -			    info->rx_ring_ref);
> -	if (err) {
> -		message = "writing rx ring-ref";
> -		goto abort_transaction;
> +
> +	if (info->rx_ring_page_order == 0)
> +		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> +				    info->rx_ring_ref[0]);
> +	else {
> +		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
> +				    info->rx_ring_page_order);
> +		if (err) {
> +			message = "writing tx ring-ref";
> +			goto abort_transaction;
> +		}
> +		for (i = 0; i < info->rx_ring_pages; i++) {
> +			char name[sizeof("rx-ring-ref")+2];
> +			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
> +			err = xenbus_printf(xbt, dev->nodename, name, "%u",
> +					    info->rx_ring_ref[i]);
> +			if (err) {
> +				message = "writing rx ring-ref";
> +				goto abort_transaction;
> +			}
> +		}
>  	}
> +
>  	err = xenbus_printf(xbt, dev->nodename,
>  			    "event-channel", "%u", info->evtchn);
>  	if (err) {
> @@ -1661,7 +1776,8 @@ static int xennet_connect(struct net_device *dev)
>  	xennet_release_tx_bufs(np);
>  
>  	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
> -	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
> +	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE(np->rx_ring_pages);
> +	     i++) {
>  		skb_frag_t *frag;
>  		const struct page *page;
>  		if (!np->rx_skbs[i])
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:42:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21:42:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RryzF-0006Z8-Cd; Mon, 30 Jan 2012 21:42:05 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RryzC-0006Yx-Ak
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:42:02 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327959670!52337547!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE1NDI5\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10191 invoked from network); 30 Jan 2012 21:41:11 -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; 30 Jan 2012 21:41:11 -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
	q0ULfu5v023523
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 21:41:57 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
	q0ULftm9007113
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 21:41:56 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
	q0ULftn3032326; Mon, 30 Jan 2012 15:41:55 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 13:41:55 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 641F7402B1; Mon, 30 Jan 2012 16:39:26 -0500 (EST)
Date: Mon, 30 Jan 2012 16:39:26 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120130213926.GB16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327934734-8908-16-git-send-email-wei.liu2@citrix.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.4F270EA6.0020,ss=1,re=-2.300,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:45:33PM +0000, Wei Liu wrote:
> Use DMA API to allocate ring pages, because we need to get machine
> contiginous memory.

> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netfront.c |  258 ++++++++++++++++++++++++++++++++------------
>  1 files changed, 187 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 01f589d..32ec212 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -66,9 +66,18 @@ struct netfront_cb {
>  
>  #define GRANT_INVALID_REF	0
>  
> -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> +#define XENNET_MAX_RING_PAGE_ORDER 2
> +#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
> +
> +#define NET_TX_RING_SIZE(_nr_pages)					\
> +	__CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> +#define NET_RX_RING_SIZE(_nr_pages)					\
> +	__CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> +
> +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> +
> +#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE
>  
>  struct netfront_stats {
>  	u64			rx_packets;
> @@ -84,12 +93,20 @@ struct netfront_info {
>  
>  	struct napi_struct napi;
>  
> +	/* Statistics */
> +	struct netfront_stats __percpu *stats;
> +
> +	unsigned long rx_gso_checksum_fixup;
> +
>  	unsigned int evtchn;
>  	struct xenbus_device *xbdev;
>  
>  	spinlock_t   tx_lock;
>  	struct xen_netif_tx_front_ring tx;
> -	int tx_ring_ref;
> +	dma_addr_t tx_ring_dma_handle;
> +	int tx_ring_ref[XENNET_MAX_RING_PAGES];
> +	int tx_ring_page_order;
> +	int tx_ring_pages;
>  
>  	/*
>  	 * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
> @@ -103,36 +120,34 @@ struct netfront_info {
>  	union skb_entry {
>  		struct sk_buff *skb;
>  		unsigned long link;
> -	} tx_skbs[NET_TX_RING_SIZE];
> +	} tx_skbs[XENNET_MAX_TX_RING_SIZE];
>  	grant_ref_t gref_tx_head;
> -	grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
> +	grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
>  	unsigned tx_skb_freelist;
>  
>  	spinlock_t   rx_lock ____cacheline_aligned_in_smp;
>  	struct xen_netif_rx_front_ring rx;
> -	int rx_ring_ref;
> +	dma_addr_t rx_ring_dma_handle;
> +	int rx_ring_ref[XENNET_MAX_RING_PAGES];
> +	int rx_ring_page_order;
> +	int rx_ring_pages;
>  
>  	/* Receive-ring batched refills. */
>  #define RX_MIN_TARGET 8
>  #define RX_DFL_MIN_TARGET 64
> -#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> +#define RX_MAX_TARGET XENNET_MAX_RX_RING_SIZE
>  	unsigned rx_min_target, rx_max_target, rx_target;
>  	struct sk_buff_head rx_batch;
>  
>  	struct timer_list rx_refill_timer;
>  
> -	struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
> +	struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
>  	grant_ref_t gref_rx_head;
> -	grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
> -
> -	unsigned long rx_pfn_array[NET_RX_RING_SIZE];
> -	struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
> -	struct mmu_update rx_mmu[NET_RX_RING_SIZE];
> -
> -	/* Statistics */
> -	struct netfront_stats __percpu *stats;
> +	grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
>  
> -	unsigned long rx_gso_checksum_fixup;
> +	unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
> +	struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
> +	struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
>  };
>  
>  struct netfront_rx_info {
> @@ -170,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
>  	return id;
>  }
>  
> -static int xennet_rxidx(RING_IDX idx)
> +static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
>  {
> -	return idx & (NET_RX_RING_SIZE - 1);
> +	return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
>  }
>  
>  static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
>  					 RING_IDX ri)
>  {
> -	int i = xennet_rxidx(ri);
> +	int i = xennet_rxidx(ri, np);
>  	struct sk_buff *skb = np->rx_skbs[i];
>  	np->rx_skbs[i] = NULL;
>  	return skb;
> @@ -187,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
>  static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
>  					    RING_IDX ri)
>  {
> -	int i = xennet_rxidx(ri);
> +	int i = xennet_rxidx(ri, np);
>  	grant_ref_t ref = np->grant_rx_ref[i];
>  	np->grant_rx_ref[i] = GRANT_INVALID_REF;
>  	return ref;
> @@ -300,7 +315,7 @@ no_skb:
>  
>  		skb->dev = dev;
>  
> -		id = xennet_rxidx(req_prod + i);
> +		id = xennet_rxidx(req_prod + i, np);
>  
>  		BUG_ON(np->rx_skbs[id]);
>  		np->rx_skbs[id] = skb;
> @@ -596,7 +611,7 @@ static int xennet_close(struct net_device *dev)
>  static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
>  				grant_ref_t ref)
>  {
> -	int new = xennet_rxidx(np->rx.req_prod_pvt);
> +	int new = xennet_rxidx(np->rx.req_prod_pvt, np);
>  
>  	BUG_ON(np->rx_skbs[new]);
>  	np->rx_skbs[new] = skb;
> @@ -1089,7 +1104,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
>  	struct sk_buff *skb;
>  	int i;
>  
> -	for (i = 0; i < NET_TX_RING_SIZE; i++) {
> +	for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
>  		/* Skip over entries which are actually freelist references */
>  		if (skb_entry_is_link(&np->tx_skbs[i]))
>  			continue;
> @@ -1123,7 +1138,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
>  
>  	spin_lock_bh(&np->rx_lock);
>  
> -	for (id = 0; id < NET_RX_RING_SIZE; id++) {
> +	for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
>  		ref = np->grant_rx_ref[id];
>  		if (ref == GRANT_INVALID_REF) {
>  			unused++;
> @@ -1305,13 +1320,13 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
>  
>  	/* Initialise tx_skbs as a free chain containing every entry. */
>  	np->tx_skb_freelist = 0;
> -	for (i = 0; i < NET_TX_RING_SIZE; i++) {
> +	for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
>  		skb_entry_set_link(&np->tx_skbs[i], i+1);
>  		np->grant_tx_ref[i] = GRANT_INVALID_REF;
>  	}
>  
>  	/* Clear out rx_skbs */
> -	for (i = 0; i < NET_RX_RING_SIZE; i++) {
> +	for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
>  		np->rx_skbs[i] = NULL;
>  		np->grant_rx_ref[i] = GRANT_INVALID_REF;
>  	}
> @@ -1409,15 +1424,11 @@ static int __devinit netfront_probe(struct xenbus_device *dev,
>  	return err;
>  }
>  
> -static void xennet_end_access(int ref, void *page)
> -{
> -	/* This frees the page as a side-effect */
> -	if (ref != GRANT_INVALID_REF)
> -		gnttab_end_foreign_access(ref, 0, (unsigned long)page);
> -}
> -
>  static void xennet_disconnect_backend(struct netfront_info *info)
>  {
> +	int i;
> +	struct xenbus_device *dev = info->xbdev;
> +
>  	/* Stop old i/f to prevent errors whilst we rebuild the state. */
>  	spin_lock_bh(&info->rx_lock);
>  	spin_lock_irq(&info->tx_lock);
> @@ -1429,12 +1440,24 @@ static void xennet_disconnect_backend(struct netfront_info *info)
>  		unbind_from_irqhandler(info->netdev->irq, info->netdev);
>  	info->evtchn = info->netdev->irq = 0;
>  
> -	/* End access and free the pages */
> -	xennet_end_access(info->tx_ring_ref, info->tx.sring);
> -	xennet_end_access(info->rx_ring_ref, info->rx.sring);
> +	for (i = 0; i < info->tx_ring_pages; i++) {
> +		int ref = info->tx_ring_ref[i];
> +		gnttab_end_foreign_access_ref(ref, 0);
> +		info->tx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
> +	dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> +			  (void *)info->tx.sring,
> +			  info->tx_ring_dma_handle);
> +
> +	for (i = 0; i < info->rx_ring_pages; i++) {
> +		int ref = info->rx_ring_ref[i];
> +		gnttab_end_foreign_access_ref(ref, 0);
> +		info->rx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
> +	dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
> +			  (void *)info->rx.sring,
> +			  info->rx_ring_dma_handle);
>  
> -	info->tx_ring_ref = GRANT_INVALID_REF;
> -	info->rx_ring_ref = GRANT_INVALID_REF;
>  	info->tx.sring = NULL;
>  	info->rx.sring = NULL;
>  }
> @@ -1483,9 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  	struct xen_netif_rx_sring *rxs;
>  	int err;
>  	struct net_device *netdev = info->netdev;
> +	unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> +	int i, j;
>  
> -	info->tx_ring_ref = GRANT_INVALID_REF;
> -	info->rx_ring_ref = GRANT_INVALID_REF;
> +	for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
> +		info->tx_ring_ref[i] = GRANT_INVALID_REF;
> +		info->rx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
>  	info->rx.sring = NULL;
>  	info->tx.sring = NULL;
>  	netdev->irq = 0;
> @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
>  		goto fail;
>  	}
>  
> -	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "max-tx-ring-page-order", "%u",
> +			   &max_tx_ring_page_order);
> +	if (err < 0) {
> +		info->tx_ring_page_order = 0;
> +		dev_info(&dev->dev, "single tx ring\n");
> +	} else {
> +		info->tx_ring_page_order = max_tx_ring_page_order;
> +		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> +			 max_tx_ring_page_order);
> +	}
> +	info->tx_ring_pages = (1U << info->tx_ring_page_order);
> +
> +	txs = (struct xen_netif_tx_sring *)
> +		dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> +				   &info->tx_ring_dma_handle,
> +				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);

Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
clue whether you are OK getting pages under 4GB or above it (so 64-bit support).

If you don't supply a 'dev' it will assume 4GB. But when you are run this as a
pure PV guest that won't matter the slighest b/I there are no DMA code in action
(well, there is dma_alloc_coherent - which looking at the code would NULL it seems).

Anyhow, if you get to have more than 4GB in the guest or do PCI passthrough and use
'iommu=soft'- at which point the Xen SWIOTLB will kick and you will end up 'swizzling'
the pages to be under 4GB. That can be fixed if you declerae a 'fake' device where you set
the coherent_dma_mask to DMA_BIT_MASK(64).

But if you boot the guest under HVM, then it will use the generic SWIOTLB code, which
won't guaranteeing the pages to be "machine" contingous but will be "guest machine"
contingous. Is that sufficient for this?

How did you test this? Did you supply iommu=soft  to your guest or booted it
with more than 4GB?


>  	if (!txs) {
>  		err = -ENOMEM;
>  		xenbus_dev_fatal(dev, err, "allocating tx ring page");
>  		goto fail;
>  	}
>  	SHARED_RING_INIT(txs);
> -	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE);
> +	FRONT_RING_INIT(&info->tx, txs, PAGE_SIZE * info->tx_ring_pages);
> +
> +	for (i = 0; i < info->tx_ring_pages; i++) {
> +		void *addr = (void *)((unsigned long)txs + PAGE_SIZE * i);
> +		err = xenbus_grant_ring(dev, virt_to_mfn(addr));
> +		if (err < 0)
> +			goto grant_tx_ring_fail;
> +		info->tx_ring_ref[i] = err;
> +	}
>  
> -	err = xenbus_grant_ring(dev, virt_to_mfn(txs));
> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> +			   "max-rx-ring-page-order", "%u",
> +			   &max_rx_ring_page_order);
>  	if (err < 0) {
> -		free_page((unsigned long)txs);
> -		goto fail;
> +		info->rx_ring_page_order = 0;
> +		dev_info(&dev->dev, "single rx ring\n");
> +	} else {
> +		info->rx_ring_page_order = max_rx_ring_page_order;
> +		dev_info(&dev->dev, "multi page rx ring, order = %d\n",
> +			 max_rx_ring_page_order);
>  	}
> +	info->rx_ring_pages = (1U << info->rx_ring_page_order);
>  
> -	info->tx_ring_ref = err;
> -	rxs = (struct xen_netif_rx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> +	rxs = (struct xen_netif_rx_sring *)
> +		dma_alloc_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
> +				   &info->rx_ring_dma_handle,
> +				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
>  	if (!rxs) {
>  		err = -ENOMEM;
>  		xenbus_dev_fatal(dev, err, "allocating rx ring page");
> -		goto fail;
> +		goto alloc_rx_ring_fail;
>  	}
>  	SHARED_RING_INIT(rxs);
> -	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE);
> -
> -	err = xenbus_grant_ring(dev, virt_to_mfn(rxs));
> -	if (err < 0) {
> -		free_page((unsigned long)rxs);
> -		goto fail;
> +	FRONT_RING_INIT(&info->rx, rxs, PAGE_SIZE * info->rx_ring_pages);
> +
> +	for (j = 0; j < info->rx_ring_pages; j++) {
> +		void *addr = (void *)((unsigned long)rxs + PAGE_SIZE * j);
> +		err = xenbus_grant_ring(dev, virt_to_mfn(addr));
> +		if (err < 0)
> +			goto grant_rx_ring_fail;
> +		info->rx_ring_ref[j] = err;
>  	}
> -	info->rx_ring_ref = err;
>  
>  	err = xenbus_alloc_evtchn(dev, &info->evtchn);
>  	if (err)
> -		goto fail;
> +		goto alloc_evtchn_fail;
>  
>  	err = bind_evtchn_to_irqhandler(info->evtchn, xennet_interrupt,
>  					0, netdev->name, netdev);
>  	if (err < 0)
> -		goto fail;
> +		goto bind_fail;
>  	netdev->irq = err;
> +
>  	return 0;
>  
> - fail:
> +bind_fail:
> +	xenbus_free_evtchn(dev, info->evtchn);
> +alloc_evtchn_fail:
> +	for (; j >= 0; j--) {
> +		int ref = info->rx_ring_ref[j];
> +		gnttab_end_foreign_access_ref(ref, 0);
> +		info->rx_ring_ref[j] = GRANT_INVALID_REF;
> +	}
> +grant_rx_ring_fail:
> +	dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
> +			  (void *)rxs, info->rx_ring_dma_handle);
> +alloc_rx_ring_fail:
> +	for (; i >= 0; i--) {
> +		int ref = info->tx_ring_ref[i];
> +		gnttab_end_foreign_access_ref(ref, 0);
> +		info->tx_ring_ref[i] = GRANT_INVALID_REF;
> +	}
> +grant_tx_ring_fail:
> +	dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> +			  (void *)txs, info->tx_ring_dma_handle);
> +fail:
>  	return err;
>  }
>  
> @@ -1550,6 +1632,7 @@ static int talk_to_netback(struct xenbus_device *dev,
>  	const char *message;
>  	struct xenbus_transaction xbt;
>  	int err;
> +	int i;
>  
>  	/* Create shared ring, alloc event channel. */
>  	err = setup_netfront(dev, info);
> @@ -1563,18 +1646,50 @@ again:
>  		goto destroy_ring;
>  	}
>  
> -	err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> -			    info->tx_ring_ref);
> -	if (err) {
> -		message = "writing tx ring-ref";
> -		goto abort_transaction;
> +	if (info->tx_ring_page_order == 0)
> +		err = xenbus_printf(xbt, dev->nodename, "tx-ring-ref", "%u",
> +				    info->tx_ring_ref[0]);
> +	else {
> +		err = xenbus_printf(xbt, dev->nodename, "tx-ring-order", "%u",
> +				    info->tx_ring_page_order);
> +		if (err) {
> +			message = "writing tx ring-ref";
> +			goto abort_transaction;
> +		}
> +		for (i = 0; i < info->tx_ring_pages; i++) {
> +			char name[sizeof("tx-ring-ref")+2];
> +			snprintf(name, sizeof(name), "tx-ring-ref%u", i);
> +			err = xenbus_printf(xbt, dev->nodename, name, "%u",
> +					    info->tx_ring_ref[i]);
> +			if (err) {
> +				message = "writing tx ring-ref";
> +				goto abort_transaction;
> +			}
> +		}
>  	}
> -	err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> -			    info->rx_ring_ref);
> -	if (err) {
> -		message = "writing rx ring-ref";
> -		goto abort_transaction;
> +
> +	if (info->rx_ring_page_order == 0)
> +		err = xenbus_printf(xbt, dev->nodename, "rx-ring-ref", "%u",
> +				    info->rx_ring_ref[0]);
> +	else {
> +		err = xenbus_printf(xbt, dev->nodename, "rx-ring-order", "%u",
> +				    info->rx_ring_page_order);
> +		if (err) {
> +			message = "writing tx ring-ref";
> +			goto abort_transaction;
> +		}
> +		for (i = 0; i < info->rx_ring_pages; i++) {
> +			char name[sizeof("rx-ring-ref")+2];
> +			snprintf(name, sizeof(name), "rx-ring-ref%u", i);
> +			err = xenbus_printf(xbt, dev->nodename, name, "%u",
> +					    info->rx_ring_ref[i]);
> +			if (err) {
> +				message = "writing rx ring-ref";
> +				goto abort_transaction;
> +			}
> +		}
>  	}
> +
>  	err = xenbus_printf(xbt, dev->nodename,
>  			    "event-channel", "%u", info->evtchn);
>  	if (err) {
> @@ -1661,7 +1776,8 @@ static int xennet_connect(struct net_device *dev)
>  	xennet_release_tx_bufs(np);
>  
>  	/* Step 2: Rebuild the RX buffer freelist and the RX ring itself. */
> -	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE; i++) {
> +	for (requeue_idx = 0, i = 0; i < NET_RX_RING_SIZE(np->rx_ring_pages);
> +	     i++) {
>  		skb_frag_t *frag;
>  		const struct page *page;
>  		if (!np->rx_skbs[i])
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:50:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrz6m-0006wO-8V; Mon, 30 Jan 2012 21:49: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 1Rrz6k-0006wG-OG
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:49:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327960183!13006083!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNTM0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6579 invoked from network); 30 Jan 2012 21:49:44 -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; 30 Jan 2012 21:49: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
	q0ULnf5R031296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 21:49:41 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
	q0ULne3x010010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 21:49:40 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
	q0ULnd6p004476; Mon, 30 Jan 2012 15:49:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 13:49:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8868D402C7; Mon, 30 Jan 2012 16:47:10 -0500 (EST)
Date: Mon, 30 Jan 2012 16:47:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120130214710.GC16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F271076.000D,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 13/16] netback: stub for multi
 receive protocol support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:45:31PM +0000, Wei Liu wrote:
> Refactor netback, make stub for mutli receive protocols. Also stub

multi.

> existing code as protocol 0.

Why not 1?

Why do we need a new rework without anything using it besides
the existing framework? OR if you are, you should say which
patch is doing it...

> 
> Now the file layout becomes:
> 
>  - interface.c: xenvif interfaces
>  - xenbus.c: xenbus related functions
>  - netback.c: common functions for various protocols
> 
> For different protocols:
> 
>  - xenvif_rx_protocolX.h: header file for the protocol, including
>                           protocol structures and functions
>  - xenvif_rx_protocolX.c: implementations
> 
> To add a new protocol:
> 
>  - include protocol header in common.h
>  - modify XENVIF_MAX_RX_PROTOCOL in common.h
>  - add protocol structure in xenvif.rx union
>  - stub in xenbus.c
>  - modify Makefile
> 
> A protocol should define five functions:
> 
>  - setup: setup frontend / backend ring connections
>  - teardown: teardown frontend / backend ring connections
>  - start_xmit: host start xmit (i.e. guest need to do rx)
>  - event: rx completion event
>  - action: prepare host side data for guest rx
> 
.. snip..

> -
> -	return resp;
> -}
> -
>  static inline int rx_work_todo(struct xenvif *vif)
>  {
>  	return !skb_queue_empty(&vif->rx_queue);
> @@ -1507,8 +999,8 @@ int xenvif_kthread(void *data)
>  		if (kthread_should_stop())
>  			break;
>  
> -		if (rx_work_todo(vif))
> -			xenvif_rx_action(vif);
> +		if (rx_work_todo(vif) && vif->action)
> +			vif->action(vif);
>  	}
>  
>  	return 0;
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 79499fc..4067286 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -415,6 +415,7 @@ static int connect_rings(struct backend_info *be)
>  	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
>  	unsigned int  tx_ring_order;
>  	unsigned int  rx_ring_order;
> +	unsigned int  rx_protocol;
>  
>  	err = xenbus_gather(XBT_NIL, dev->otherend,
>  			    "event-channel", "%u", &evtchn, NULL);
> @@ -510,6 +511,11 @@ static int connect_rings(struct backend_info *be)
>  		}
>  	}
>  
> +	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-protocol",

feature-rx-protocol?

> +			   "%u", &rx_protocol);
> +	if (err < 0)
> +		rx_protocol = XENVIF_MIN_RX_PROTOCOL;
> +

You should check to see if the protocol is higher than what we can support.
The guest could be playing funny games and putting in 39432...


>  	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
>  			   &rx_copy);
>  	if (err == -ENOENT) {
> @@ -559,7 +565,7 @@ static int connect_rings(struct backend_info *be)
>  	err = xenvif_connect(vif,
>  			     tx_ring_ref, (1U << tx_ring_order),
>  			     rx_ring_ref, (1U << rx_ring_order),
> -			     evtchn);
> +			     evtchn, rx_protocol);
>  	if (err) {
>  		int i;
>  		xenbus_dev_fatal(dev, err,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:50:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21:50:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rrz6m-0006wO-8V; Mon, 30 Jan 2012 21:49: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 1Rrz6k-0006wG-OG
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:49:50 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1327960183!13006083!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNTM0OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6579 invoked from network); 30 Jan 2012 21:49:44 -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; 30 Jan 2012 21:49: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
	q0ULnf5R031296
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 21:49:41 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
	q0ULne3x010010
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 21:49:40 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
	q0ULnd6p004476; Mon, 30 Jan 2012 15:49:39 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 13:49:39 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 8868D402C7; Mon, 30 Jan 2012 16:47:10 -0500 (EST)
Date: Mon, 30 Jan 2012 16:47:10 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120130214710.GC16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F271076.000D,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 13/16] netback: stub for multi
 receive protocol support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:45:31PM +0000, Wei Liu wrote:
> Refactor netback, make stub for mutli receive protocols. Also stub

multi.

> existing code as protocol 0.

Why not 1?

Why do we need a new rework without anything using it besides
the existing framework? OR if you are, you should say which
patch is doing it...

> 
> Now the file layout becomes:
> 
>  - interface.c: xenvif interfaces
>  - xenbus.c: xenbus related functions
>  - netback.c: common functions for various protocols
> 
> For different protocols:
> 
>  - xenvif_rx_protocolX.h: header file for the protocol, including
>                           protocol structures and functions
>  - xenvif_rx_protocolX.c: implementations
> 
> To add a new protocol:
> 
>  - include protocol header in common.h
>  - modify XENVIF_MAX_RX_PROTOCOL in common.h
>  - add protocol structure in xenvif.rx union
>  - stub in xenbus.c
>  - modify Makefile
> 
> A protocol should define five functions:
> 
>  - setup: setup frontend / backend ring connections
>  - teardown: teardown frontend / backend ring connections
>  - start_xmit: host start xmit (i.e. guest need to do rx)
>  - event: rx completion event
>  - action: prepare host side data for guest rx
> 
.. snip..

> -
> -	return resp;
> -}
> -
>  static inline int rx_work_todo(struct xenvif *vif)
>  {
>  	return !skb_queue_empty(&vif->rx_queue);
> @@ -1507,8 +999,8 @@ int xenvif_kthread(void *data)
>  		if (kthread_should_stop())
>  			break;
>  
> -		if (rx_work_todo(vif))
> -			xenvif_rx_action(vif);
> +		if (rx_work_todo(vif) && vif->action)
> +			vif->action(vif);
>  	}
>  
>  	return 0;
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 79499fc..4067286 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -415,6 +415,7 @@ static int connect_rings(struct backend_info *be)
>  	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
>  	unsigned int  tx_ring_order;
>  	unsigned int  rx_ring_order;
> +	unsigned int  rx_protocol;
>  
>  	err = xenbus_gather(XBT_NIL, dev->otherend,
>  			    "event-channel", "%u", &evtchn, NULL);
> @@ -510,6 +511,11 @@ static int connect_rings(struct backend_info *be)
>  		}
>  	}
>  
> +	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-protocol",

feature-rx-protocol?

> +			   "%u", &rx_protocol);
> +	if (err < 0)
> +		rx_protocol = XENVIF_MIN_RX_PROTOCOL;
> +

You should check to see if the protocol is higher than what we can support.
The guest could be playing funny games and putting in 39432...


>  	err = xenbus_scanf(XBT_NIL, dev->otherend, "request-rx-copy", "%u",
>  			   &rx_copy);
>  	if (err == -ENOENT) {
> @@ -559,7 +565,7 @@ static int connect_rings(struct backend_info *be)
>  	err = xenvif_connect(vif,
>  			     tx_ring_ref, (1U << tx_ring_order),
>  			     rx_ring_ref, (1U << rx_ring_order),
> -			     evtchn);
> +			     evtchn, rx_protocol);
>  	if (err) {
>  		int i;
>  		xenbus_dev_fatal(dev, err,

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:56:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21: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 1RrzCs-00075d-57; Mon, 30 Jan 2012 21:56: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 1RrzCq-00075X-Vy
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:56:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327960544!50859226!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNzAyNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13341 invoked from network); 30 Jan 2012 21:55:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 21:55: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
	q0ULu31M006486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 21:56:03 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
	q0ULu2t9025771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 21:56:02 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0ULu1JQ009952; Mon, 30 Jan 2012 15:56:01 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 13:56:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E735E402C7; Mon, 30 Jan 2012 16:53:32 -0500 (EST)
Date: Mon, 30 Jan 2012 16:53:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120130215332.GA16747@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327934734-8908-11-git-send-email-wei.liu2@citrix.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.4F2711F4.0017,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:45:28PM +0000, Wei Liu wrote:
> If we allocate large arrays in per-cpu section, multi-page ring
> feature is likely to blow up the per-cpu section. So avoid allocating
> large arrays, instead we only store pointers to scratch spaces in
> per-cpu section.
> 
> CPU hotplug event is also taken care of.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netback/netback.c |  140 +++++++++++++++++++++++++++----------
>  1 files changed, 104 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index a8d58a9..2ac9b84 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -39,6 +39,7 @@
>  #include <linux/kthread.h>
>  #include <linux/if_vlan.h>
>  #include <linux/udp.h>
> +#include <linux/cpu.h>
>  
>  #include <net/tcp.h>
>  
> @@ -49,15 +50,15 @@
>  #include <asm/xen/page.h>
>  
>  
> -struct gnttab_copy *tx_copy_ops;
> +DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
>  
>  /*
>   * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
>   * head/fragment page uses 2 copy operations because it
>   * straddles two buffers in the frontend.
>   */
> -struct gnttab_copy *grant_copy_op;
> -struct xenvif_rx_meta *meta;
> +DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
> +DEFINE_PER_CPU(struct xenvif_rx_meta *, meta);
>  
>  static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
>  static void make_tx_response(struct xenvif *vif,
> @@ -481,8 +482,8 @@ void xenvif_rx_action(struct xenvif *vif)
>  	struct skb_cb_overlay *sco;
>  	int need_to_notify = 0;
>  
> -	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
> -	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
> +	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
> +	struct xenvif_rx_meta *m = get_cpu_var(meta);
>  
>  	struct netrx_pending_operations npo = {
>  		.copy  = gco,
> @@ -512,8 +513,8 @@ void xenvif_rx_action(struct xenvif *vif)
>  	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
>  
>  	if (!npo.copy_prod) {
> -		put_cpu_ptr(gco);
> -		put_cpu_ptr(m);
> +		put_cpu_var(grant_copy_op);
> +		put_cpu_var(meta);
>  		return;
>  	}
>  
> @@ -599,8 +600,8 @@ void xenvif_rx_action(struct xenvif *vif)
>  	if (!skb_queue_empty(&vif->rx_queue))
>  		xenvif_kick_thread(vif);
>  
> -	put_cpu_ptr(gco);
> -	put_cpu_ptr(m);
> +	put_cpu_var(grant_copy_op);
> +	put_cpu_var(meta);
>  }
>  
>  void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
> @@ -1287,12 +1288,12 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
>  	if (unlikely(!tx_work_todo(vif)))
>  		return 0;
>  
> -	tco = get_cpu_ptr(tx_copy_ops);
> +	tco = get_cpu_var(tx_copy_ops);
>  
>  	nr_gops = xenvif_tx_build_gops(vif, tco);
>  
>  	if (nr_gops == 0) {
> -		put_cpu_ptr(tco);
> +		put_cpu_var(tx_copy_ops);
>  		return 0;
>  	}
>  
> @@ -1301,7 +1302,7 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
>  
>  	work_done = xenvif_tx_submit(vif, tco, budget);
>  
> -	put_cpu_ptr(tco);
> +	put_cpu_var(tx_copy_ops);
>  
>  	return work_done;
>  }
> @@ -1452,31 +1453,97 @@ int xenvif_kthread(void *data)
>  	return 0;
>  }
>  
> +static int __create_percpu_scratch_space(unsigned int cpu)
> +{
> +	per_cpu(tx_copy_ops, cpu) =
> +		vzalloc(sizeof(struct gnttab_copy) * MAX_PENDING_REQS);
> +
> +	per_cpu(grant_copy_op, cpu) =
> +		vzalloc(sizeof(struct gnttab_copy)
> +			* 2 * XEN_NETIF_RX_RING_SIZE);
> +
> +	per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
> +				     * 2 * XEN_NETIF_RX_RING_SIZE);
> +
> +	if (!per_cpu(tx_copy_ops, cpu) ||
> +	    !per_cpu(grant_copy_op, cpu) ||
> +	    !per_cpu(meta, cpu))

Hm, shouldn't you vfree one at least them? It might be that just one of
them failed.

> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +
> +static void __free_percpu_scratch_space(unsigned int cpu)
> +{
> +	/* freeing NULL pointer is legit */
> +	vfree(per_cpu(tx_copy_ops, cpu));
> +	vfree(per_cpu(grant_copy_op, cpu));
> +	vfree(per_cpu(meta, cpu));
> +}
> +
> +static int __netback_percpu_callback(struct notifier_block *nfb,
> +				     unsigned long action, void *hcpu)
> +{
> +	unsigned int cpu = (unsigned long)hcpu;
> +	int rc = NOTIFY_DONE;
> +
> +	switch (action) {
> +	case CPU_ONLINE:
> +	case CPU_ONLINE_FROZEN:
> +		printk(KERN_INFO
> +		       "netback: CPU %x online, creating scratch space\n", cpu);

Is there any way to use 'pr_info(DRV_NAME' for these printk's? It might
require another patch, but it would  make it nicer.

> +		rc = __create_percpu_scratch_space(cpu);
> +		if (rc) {
> +			printk(KERN_ALERT
> +			       "netback: failed to create scratch space for CPU"
> +			       " %x\n", cpu);
> +			/* FIXME: nothing more we can do here, we will
> +			 * print out warning message when thread or
> +			 * NAPI runs on this cpu. Also stop getting
> +			 * called in the future.
> +			 */
> +			__free_percpu_scratch_space(cpu);
> +			rc = NOTIFY_BAD;
> +		} else {
> +			rc = NOTIFY_OK;
> +		}
> +		break;
> +	case CPU_DEAD:
> +	case CPU_DEAD_FROZEN:
> +		printk("netback: CPU %x offline, destroying scratch space\n",
> +		       cpu);

pr_debug?

> +		__free_percpu_scratch_space(cpu);
> +		rc = NOTIFY_OK;
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +static struct notifier_block netback_notifier_block = {
> +	.notifier_call = __netback_percpu_callback,
> +};
>  
>  static int __init netback_init(void)
>  {
>  	int rc = -ENOMEM;
> +	int cpu;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
> -				     * MAX_PENDING_REQS,
> -				     __alignof__(struct gnttab_copy));
> -	if (!tx_copy_ops)
> -		goto failed_init;
> +	/* Don't need to disable preempt here, since nobody else will
> +	 * touch these percpu areas during start up. */
> +	for_each_online_cpu(cpu) {
> +		rc = __create_percpu_scratch_space(cpu);
>  
> -	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
> -				       * 2 * XEN_NETIF_RX_RING_SIZE,
> -				       __alignof__(struct gnttab_copy));
> -	if (!grant_copy_op)
> -		goto failed_init_gco;
> +		if (rc)
> +			goto failed_init;
> +	}
>  
> -	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
> -			      * 2 * XEN_NETIF_RX_RING_SIZE,
> -			      __alignof__(struct xenvif_rx_meta));
> -	if (!meta)
> -		goto failed_init_meta;
> +	register_hotcpu_notifier(&netback_notifier_block);
>  
>  	rc = page_pool_init();
>  	if (rc)
> @@ -1491,25 +1558,26 @@ static int __init netback_init(void)
>  failed_init_xenbus:
>  	page_pool_destroy();
>  failed_init_pool:
> -	free_percpu(meta);
> -failed_init_meta:
> -	free_percpu(grant_copy_op);
> -failed_init_gco:
> -	free_percpu(tx_copy_ops);
> +	for_each_online_cpu(cpu)
> +		__free_percpu_scratch_space(cpu);
>  failed_init:
>  	return rc;

We don't want to try to clean up the per_cpu_spaces that might
have gotten allocated in the loop?

> -
>  }
>  
>  module_init(netback_init);
>  
>  static void __exit netback_exit(void)
>  {
> +	int cpu;
> +
>  	xenvif_xenbus_exit();
>  	page_pool_destroy();
> -	free_percpu(meta);
> -	free_percpu(grant_copy_op);
> -	free_percpu(tx_copy_ops);
> +
> +	unregister_hotcpu_notifier(&netback_notifier_block);
> +
> +	/* Since we're here, nobody else will touch per-cpu area. */
> +	for_each_online_cpu(cpu)
> +		__free_percpu_scratch_space(cpu);
>  }
>  module_exit(netback_exit);
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Mon Jan 30 21:56:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Mon, 30 Jan 2012 21: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 1RrzCs-00075d-57; Mon, 30 Jan 2012 21:56: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 1RrzCq-00075X-Vy
	for xen-devel@lists.xensource.com; Mon, 30 Jan 2012 21:56:09 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-11.tower-27.messagelabs.com!1327960544!50859226!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxNzAyNg==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13341 invoked from network); 30 Jan 2012 21:55:45 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 30 Jan 2012 21:55: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
	q0ULu31M006486
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 30 Jan 2012 21:56:03 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
	q0ULu2t9025771
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 30 Jan 2012 21:56:02 GMT
Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0ULu1JQ009952; Mon, 30 Jan 2012 15:56:01 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Mon, 30 Jan 2012 13:56:01 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id E735E402C7; Mon, 30 Jan 2012 16:53:32 -0500 (EST)
Date: Mon, 30 Jan 2012 16:53:32 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120130215332.GA16747@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1327934734-8908-11-git-send-email-wei.liu2@citrix.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.4F2711F4.0017,ss=1,re=0.000,fgs=0
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:45:28PM +0000, Wei Liu wrote:
> If we allocate large arrays in per-cpu section, multi-page ring
> feature is likely to blow up the per-cpu section. So avoid allocating
> large arrays, instead we only store pointers to scratch spaces in
> per-cpu section.
> 
> CPU hotplug event is also taken care of.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netback/netback.c |  140 +++++++++++++++++++++++++++----------
>  1 files changed, 104 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index a8d58a9..2ac9b84 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -39,6 +39,7 @@
>  #include <linux/kthread.h>
>  #include <linux/if_vlan.h>
>  #include <linux/udp.h>
> +#include <linux/cpu.h>
>  
>  #include <net/tcp.h>
>  
> @@ -49,15 +50,15 @@
>  #include <asm/xen/page.h>
>  
>  
> -struct gnttab_copy *tx_copy_ops;
> +DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
>  
>  /*
>   * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
>   * head/fragment page uses 2 copy operations because it
>   * straddles two buffers in the frontend.
>   */
> -struct gnttab_copy *grant_copy_op;
> -struct xenvif_rx_meta *meta;
> +DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
> +DEFINE_PER_CPU(struct xenvif_rx_meta *, meta);
>  
>  static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
>  static void make_tx_response(struct xenvif *vif,
> @@ -481,8 +482,8 @@ void xenvif_rx_action(struct xenvif *vif)
>  	struct skb_cb_overlay *sco;
>  	int need_to_notify = 0;
>  
> -	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
> -	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
> +	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
> +	struct xenvif_rx_meta *m = get_cpu_var(meta);
>  
>  	struct netrx_pending_operations npo = {
>  		.copy  = gco,
> @@ -512,8 +513,8 @@ void xenvif_rx_action(struct xenvif *vif)
>  	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
>  
>  	if (!npo.copy_prod) {
> -		put_cpu_ptr(gco);
> -		put_cpu_ptr(m);
> +		put_cpu_var(grant_copy_op);
> +		put_cpu_var(meta);
>  		return;
>  	}
>  
> @@ -599,8 +600,8 @@ void xenvif_rx_action(struct xenvif *vif)
>  	if (!skb_queue_empty(&vif->rx_queue))
>  		xenvif_kick_thread(vif);
>  
> -	put_cpu_ptr(gco);
> -	put_cpu_ptr(m);
> +	put_cpu_var(grant_copy_op);
> +	put_cpu_var(meta);
>  }
>  
>  void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
> @@ -1287,12 +1288,12 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
>  	if (unlikely(!tx_work_todo(vif)))
>  		return 0;
>  
> -	tco = get_cpu_ptr(tx_copy_ops);
> +	tco = get_cpu_var(tx_copy_ops);
>  
>  	nr_gops = xenvif_tx_build_gops(vif, tco);
>  
>  	if (nr_gops == 0) {
> -		put_cpu_ptr(tco);
> +		put_cpu_var(tx_copy_ops);
>  		return 0;
>  	}
>  
> @@ -1301,7 +1302,7 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
>  
>  	work_done = xenvif_tx_submit(vif, tco, budget);
>  
> -	put_cpu_ptr(tco);
> +	put_cpu_var(tx_copy_ops);
>  
>  	return work_done;
>  }
> @@ -1452,31 +1453,97 @@ int xenvif_kthread(void *data)
>  	return 0;
>  }
>  
> +static int __create_percpu_scratch_space(unsigned int cpu)
> +{
> +	per_cpu(tx_copy_ops, cpu) =
> +		vzalloc(sizeof(struct gnttab_copy) * MAX_PENDING_REQS);
> +
> +	per_cpu(grant_copy_op, cpu) =
> +		vzalloc(sizeof(struct gnttab_copy)
> +			* 2 * XEN_NETIF_RX_RING_SIZE);
> +
> +	per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
> +				     * 2 * XEN_NETIF_RX_RING_SIZE);
> +
> +	if (!per_cpu(tx_copy_ops, cpu) ||
> +	    !per_cpu(grant_copy_op, cpu) ||
> +	    !per_cpu(meta, cpu))

Hm, shouldn't you vfree one at least them? It might be that just one of
them failed.

> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +
> +static void __free_percpu_scratch_space(unsigned int cpu)
> +{
> +	/* freeing NULL pointer is legit */
> +	vfree(per_cpu(tx_copy_ops, cpu));
> +	vfree(per_cpu(grant_copy_op, cpu));
> +	vfree(per_cpu(meta, cpu));
> +}
> +
> +static int __netback_percpu_callback(struct notifier_block *nfb,
> +				     unsigned long action, void *hcpu)
> +{
> +	unsigned int cpu = (unsigned long)hcpu;
> +	int rc = NOTIFY_DONE;
> +
> +	switch (action) {
> +	case CPU_ONLINE:
> +	case CPU_ONLINE_FROZEN:
> +		printk(KERN_INFO
> +		       "netback: CPU %x online, creating scratch space\n", cpu);

Is there any way to use 'pr_info(DRV_NAME' for these printk's? It might
require another patch, but it would  make it nicer.

> +		rc = __create_percpu_scratch_space(cpu);
> +		if (rc) {
> +			printk(KERN_ALERT
> +			       "netback: failed to create scratch space for CPU"
> +			       " %x\n", cpu);
> +			/* FIXME: nothing more we can do here, we will
> +			 * print out warning message when thread or
> +			 * NAPI runs on this cpu. Also stop getting
> +			 * called in the future.
> +			 */
> +			__free_percpu_scratch_space(cpu);
> +			rc = NOTIFY_BAD;
> +		} else {
> +			rc = NOTIFY_OK;
> +		}
> +		break;
> +	case CPU_DEAD:
> +	case CPU_DEAD_FROZEN:
> +		printk("netback: CPU %x offline, destroying scratch space\n",
> +		       cpu);

pr_debug?

> +		__free_percpu_scratch_space(cpu);
> +		rc = NOTIFY_OK;
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	return rc;
> +}
> +
> +static struct notifier_block netback_notifier_block = {
> +	.notifier_call = __netback_percpu_callback,
> +};
>  
>  static int __init netback_init(void)
>  {
>  	int rc = -ENOMEM;
> +	int cpu;
>  
>  	if (!xen_domain())
>  		return -ENODEV;
>  
> -	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
> -				     * MAX_PENDING_REQS,
> -				     __alignof__(struct gnttab_copy));
> -	if (!tx_copy_ops)
> -		goto failed_init;
> +	/* Don't need to disable preempt here, since nobody else will
> +	 * touch these percpu areas during start up. */
> +	for_each_online_cpu(cpu) {
> +		rc = __create_percpu_scratch_space(cpu);
>  
> -	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
> -				       * 2 * XEN_NETIF_RX_RING_SIZE,
> -				       __alignof__(struct gnttab_copy));
> -	if (!grant_copy_op)
> -		goto failed_init_gco;
> +		if (rc)
> +			goto failed_init;
> +	}
>  
> -	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
> -			      * 2 * XEN_NETIF_RX_RING_SIZE,
> -			      __alignof__(struct xenvif_rx_meta));
> -	if (!meta)
> -		goto failed_init_meta;
> +	register_hotcpu_notifier(&netback_notifier_block);
>  
>  	rc = page_pool_init();
>  	if (rc)
> @@ -1491,25 +1558,26 @@ static int __init netback_init(void)
>  failed_init_xenbus:
>  	page_pool_destroy();
>  failed_init_pool:
> -	free_percpu(meta);
> -failed_init_meta:
> -	free_percpu(grant_copy_op);
> -failed_init_gco:
> -	free_percpu(tx_copy_ops);
> +	for_each_online_cpu(cpu)
> +		__free_percpu_scratch_space(cpu);
>  failed_init:
>  	return rc;

We don't want to try to clean up the per_cpu_spaces that might
have gotten allocated in the loop?

> -
>  }
>  
>  module_init(netback_init);
>  
>  static void __exit netback_exit(void)
>  {
> +	int cpu;
> +
>  	xenvif_xenbus_exit();
>  	page_pool_destroy();
> -	free_percpu(meta);
> -	free_percpu(grant_copy_op);
> -	free_percpu(tx_copy_ops);
> +
> +	unregister_hotcpu_notifier(&netback_notifier_block);
> +
> +	/* Since we're here, nobody else will touch per-cpu area. */
> +	for_each_online_cpu(cpu)
> +		__free_percpu_scratch_space(cpu);
>  }
>  module_exit(netback_exit);
>  
> -- 
> 1.7.2.5

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:06:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2AJ-0003YO-S5; Tue, 31 Jan 2012 01:05:43 +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 1Rs2AI-0003Y2-6i
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:05:42 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327971867!63097287!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19493 invoked from network); 31 Jan 2012 01:04:29 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 01:04:29 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15TKZ004132; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15Scj004129;
	Mon, 30 Jan 2012 17:05:28 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:05 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 6] libxl: refactor suspend/resume code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series refactors the suspend/resume code to minimize 
Remus specific code in libxl. There are a couple of trivial bug
fixes too.

Shriram


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:06:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2AJ-0003YO-S5; Tue, 31 Jan 2012 01:05:43 +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 1Rs2AI-0003Y2-6i
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:05:42 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-27.messagelabs.com!1327971867!63097287!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19493 invoked from network); 31 Jan 2012 01:04:29 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 01:04:29 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15TKZ004132; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15Scj004129;
	Mon, 30 Jan 2012 17:05:28 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:05 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 6] libxl: refactor suspend/resume code
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series refactors the suspend/resume code to minimize 
Remus specific code in libxl. There are a couple of trivial bug
fixes too.

Shriram


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:06:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2AM-0003Z0-Rp; Tue, 31 Jan 2012 01:05:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2AL-0003Y4-2k
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:05:45 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327971936!14580122!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3409 invoked from network); 31 Jan 2012 01:05:38 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 01:05:38 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15Tlw004167; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15TDm004164;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: d79c7a853c644d459cda93bf61657be48104cd63
Message-Id: <d79c7a853c644d459cda.1327971910@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:10 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 5 of 6] libxl: refactor migrate_domain and
	generalize	migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971533 28800
# Node ID d79c7a853c644d459cda93bf61657be48104cd63
# Parent  efe92d80c47487485056266a1404a8d2817b7f09
libxl: refactor migrate_domain and generalize migrate_receive

Refactor some tasks like establishing the migration channel,
initial migration protocol exchange into separate functions,
to facilitate re-use, when remus support is introduced. Also,
make migrate_receive generic (instead of resorting to stdin and
stdout as the file descriptors for communication).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r efe92d80c474 -r d79c7a853c64 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:47 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:53 2012 -0800
@@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
     exit(0);
 }
 
+static pid_t create_migration_child(const char *rune, int *send_fd,
+                                        int *recv_fd)
+{
+    int sendpipe[2], recvpipe[2];
+    pid_t child = -1;
+
+    if (!rune || !send_fd || !recv_fd)
+        return -1;
+
+    MUST( libxl_pipe(ctx, sendpipe) );
+    MUST( libxl_pipe(ctx, recvpipe) );
+
+    child = libxl_fork(ctx);
+    if (child==-1) exit(1);
+
+    if (!child) {
+        dup2(sendpipe[0], 0);
+        dup2(recvpipe[1], 1);
+        close(sendpipe[0]); close(sendpipe[1]);
+        close(recvpipe[0]); close(recvpipe[1]);
+        execlp("sh","sh","-c",rune,(char*)0);
+        perror("failed to exec sh");
+        exit(-1);
+    }
+
+    close(sendpipe[0]);
+    close(recvpipe[1]);
+    *send_fd = sendpipe[1];
+    *recv_fd = recvpipe[0];
+
+    /* if receiver dies, we get an error and can clean up
+       rather than just dying */
+    signal(SIGPIPE, SIG_IGN);
+
+    return child;
+}
+
 static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
                                      const char *what, const char *rune) {
     char buf[msgsz];
@@ -2616,18 +2653,23 @@ static void migration_child_report(pid_t
     migration_child = 0;
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
-                           const char *override_config_file)
+/* It is okay to have a NULL rune (we could be communicating over tcp sockets
+ * but not both NULL rune and NULL(send_fd, recv_fd).
+ */
+static void migrate_do_preamble(const char *domain_spec, const char *rune,
+                                const char *override_config_file,
+                                int *send_fd, int *recv_fd, pid_t *mchild)
 {
-    pid_t child = -1;
-    int rc;
-    int sendpipe[2], recvpipe[2];
-    int send_fd, recv_fd;
-    libxl_domain_suspend_info suspinfo;
-    char *away_domname;
-    char rc_buf;
+    int rc = 0;
     uint8_t *config_data;
     int config_len;
+    pid_t child = -1;
+
+    if (!send_fd || !recv_fd) {
+        fprintf(stderr, "Cannot create migration channel:"
+                "Null file descriptors supplied!\n");
+        exit(1);
+    }
 
     save_domain_core_begin(domain_spec, override_config_file,
                            &config_data, &config_len);
@@ -2638,43 +2680,44 @@ static void migrate_domain(const char *d
         exit(1);
     }
 
-    MUST( libxl_pipe(ctx, sendpipe) );
-    MUST( libxl_pipe(ctx, recvpipe) );
-
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
-
-    if (!child) {
-        dup2(sendpipe[0], 0);
-        dup2(recvpipe[1], 1);
-        close(sendpipe[0]); close(sendpipe[1]);
-        close(recvpipe[0]); close(recvpipe[1]);
-        execlp("sh","sh","-c",rune,(char*)0);
-        perror("failed to exec sh");
-        exit(-1);
-    }
-
-    close(sendpipe[0]);
-    close(recvpipe[1]);
-    send_fd = sendpipe[1];
-    recv_fd = recvpipe[0];
-
-    signal(SIGPIPE, SIG_IGN);
-    /* if receiver dies, we get an error and can clean up
-       rather than just dying */
-
-    rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
+    if (*send_fd < 0 || *recv_fd < 0) {
+        if (rune)
+            child = create_migration_child(rune, send_fd, recv_fd);
+        if (child < 0) {
+            fprintf(stderr, "failed to create migration channel"
+                    " - empty command ?\n");
+            exit(1);
+        }
+    }
+
+    rc = migrate_read_fixedmessage(*recv_fd, migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "banner", rune);
     if (rc) {
-        close(send_fd);
-        migration_child_report(child, recv_fd);
+        close(*send_fd);
+        migration_child_report(child, *recv_fd);
         exit(-rc);
     }
 
-    save_domain_core_writeconfig(send_fd, "migration stream",
+    save_domain_core_writeconfig(*send_fd, "migration stream",
                                  config_data, config_len);
-
+    if (mchild)
+        *mchild = child;
+    return;
+}
+
+static void migrate_domain(const char *domain_spec, const char *rune,
+                           const char *override_config_file)
+{
+    int rc;
+    int send_fd = -1, recv_fd = -1;
+    libxl_domain_suspend_info suspinfo;
+    char *away_domname;
+    char rc_buf;
+    pid_t child = -1;
+
+    migrate_do_preamble(domain_spec, rune, override_config_file,
+                        &send_fd, &recv_fd, &child);
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     memset(&suspinfo, 0, sizeof(suspinfo));
@@ -2798,7 +2841,12 @@ static void core_dump_domain(const char 
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor)
+/* Explicitly specifying a send & recv fd allows us to switch to a tcp socket
+ * based migration/replication channel in future, instead of exec/forking from
+ * an ssh channel.
+ */
+static void migrate_receive(int debug, int daemonize, int monitor,
+                            int send_fd, int recv_fd)
 {
     int rc, rc2;
     char rc_buf;
@@ -2810,7 +2858,7 @@ static void migrate_receive(int debug, i
 
     fprintf(stderr, "migration target: Ready to receive domain.\n");
 
-    CHK_ERRNO( libxl_write_exactly(ctx, 1,
+    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
                                    migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "migration ack stream",
@@ -2822,7 +2870,7 @@ static void migrate_receive(int debug, i
     dom_info.monitor = monitor;
     dom_info.paused = 1;
     dom_info.restore_file = "incoming migration stream";
-    dom_info.migrate_fd = 0; /* stdin */
+    dom_info.migrate_fd = recv_fd;
     dom_info.migration_domname_r = &migration_domname;
     dom_info.no_incr_generationid = 1;
 
@@ -2836,13 +2884,13 @@ static void migrate_receive(int debug, i
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
-    rc = libxl_write_exactly(ctx, 1,
+    rc = libxl_write_exactly(ctx, send_fd,
                              migrate_receiver_ready,
                              sizeof(migrate_receiver_ready),
                              "migration ack stream", "ready message");
     if (rc) exit(-rc);
 
-    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
+    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
                                    sizeof(migrate_permission_to_go),
                                    "GO message", 0);
     if (rc) goto perhaps_destroy_notify_rc;
@@ -2861,7 +2909,7 @@ static void migrate_receive(int debug, i
     rc = 0;
 
  perhaps_destroy_notify_rc:
-    rc2 = libxl_write_exactly(ctx, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd,
                               migrate_report, sizeof(migrate_report),
                               "migration ack stream",
                               "success/failure report");
@@ -2869,7 +2917,7 @@ static void migrate_receive(int debug, i
 
     rc_buf = -rc;
     assert(!!rc_buf == !!rc);
-    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
                               "migration ack stream",
                               "success/failure code");
     if (rc2) exit(-ERROR_BADFAIL);
@@ -2887,7 +2935,7 @@ static void migrate_receive(int debug, i
         fprintf(stderr, "migration target: Cleanup OK, granting sender"
                 " permission to resume.\n");
 
-        rc2 = libxl_write_exactly(ctx, 1,
+        rc2 = libxl_write_exactly(ctx, send_fd,
                                   migrate_permission_to_go,
                                   sizeof(migrate_permission_to_go),
                                   "migration ack stream",
@@ -2983,7 +3031,8 @@ int main_migrate_receive(int argc, char 
         help("migrate-receive");
         return 2;
     }
-    migrate_receive(debug, daemonize, monitor);
+    migrate_receive(debug, daemonize, monitor,
+                    /* write to stdout */1, /* read from stdin */0);
     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 Jan 31 01:06:18 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2AM-0003Z0-Rp; Tue, 31 Jan 2012 01:05:46 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2AL-0003Y4-2k
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:05:45 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-2.tower-216.messagelabs.com!1327971936!14580122!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3409 invoked from network); 31 Jan 2012 01:05:38 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-2.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 01:05:38 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15Tlw004167; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15TDm004164;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: d79c7a853c644d459cda93bf61657be48104cd63
Message-Id: <d79c7a853c644d459cda.1327971910@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:10 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 5 of 6] libxl: refactor migrate_domain and
	generalize	migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971533 28800
# Node ID d79c7a853c644d459cda93bf61657be48104cd63
# Parent  efe92d80c47487485056266a1404a8d2817b7f09
libxl: refactor migrate_domain and generalize migrate_receive

Refactor some tasks like establishing the migration channel,
initial migration protocol exchange into separate functions,
to facilitate re-use, when remus support is introduced. Also,
make migrate_receive generic (instead of resorting to stdin and
stdout as the file descriptors for communication).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r efe92d80c474 -r d79c7a853c64 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:47 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:53 2012 -0800
@@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
     exit(0);
 }
 
+static pid_t create_migration_child(const char *rune, int *send_fd,
+                                        int *recv_fd)
+{
+    int sendpipe[2], recvpipe[2];
+    pid_t child = -1;
+
+    if (!rune || !send_fd || !recv_fd)
+        return -1;
+
+    MUST( libxl_pipe(ctx, sendpipe) );
+    MUST( libxl_pipe(ctx, recvpipe) );
+
+    child = libxl_fork(ctx);
+    if (child==-1) exit(1);
+
+    if (!child) {
+        dup2(sendpipe[0], 0);
+        dup2(recvpipe[1], 1);
+        close(sendpipe[0]); close(sendpipe[1]);
+        close(recvpipe[0]); close(recvpipe[1]);
+        execlp("sh","sh","-c",rune,(char*)0);
+        perror("failed to exec sh");
+        exit(-1);
+    }
+
+    close(sendpipe[0]);
+    close(recvpipe[1]);
+    *send_fd = sendpipe[1];
+    *recv_fd = recvpipe[0];
+
+    /* if receiver dies, we get an error and can clean up
+       rather than just dying */
+    signal(SIGPIPE, SIG_IGN);
+
+    return child;
+}
+
 static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
                                      const char *what, const char *rune) {
     char buf[msgsz];
@@ -2616,18 +2653,23 @@ static void migration_child_report(pid_t
     migration_child = 0;
 }
 
-static void migrate_domain(const char *domain_spec, const char *rune,
-                           const char *override_config_file)
+/* It is okay to have a NULL rune (we could be communicating over tcp sockets
+ * but not both NULL rune and NULL(send_fd, recv_fd).
+ */
+static void migrate_do_preamble(const char *domain_spec, const char *rune,
+                                const char *override_config_file,
+                                int *send_fd, int *recv_fd, pid_t *mchild)
 {
-    pid_t child = -1;
-    int rc;
-    int sendpipe[2], recvpipe[2];
-    int send_fd, recv_fd;
-    libxl_domain_suspend_info suspinfo;
-    char *away_domname;
-    char rc_buf;
+    int rc = 0;
     uint8_t *config_data;
     int config_len;
+    pid_t child = -1;
+
+    if (!send_fd || !recv_fd) {
+        fprintf(stderr, "Cannot create migration channel:"
+                "Null file descriptors supplied!\n");
+        exit(1);
+    }
 
     save_domain_core_begin(domain_spec, override_config_file,
                            &config_data, &config_len);
@@ -2638,43 +2680,44 @@ static void migrate_domain(const char *d
         exit(1);
     }
 
-    MUST( libxl_pipe(ctx, sendpipe) );
-    MUST( libxl_pipe(ctx, recvpipe) );
-
-    child = libxl_fork(ctx);
-    if (child==-1) exit(1);
-
-    if (!child) {
-        dup2(sendpipe[0], 0);
-        dup2(recvpipe[1], 1);
-        close(sendpipe[0]); close(sendpipe[1]);
-        close(recvpipe[0]); close(recvpipe[1]);
-        execlp("sh","sh","-c",rune,(char*)0);
-        perror("failed to exec sh");
-        exit(-1);
-    }
-
-    close(sendpipe[0]);
-    close(recvpipe[1]);
-    send_fd = sendpipe[1];
-    recv_fd = recvpipe[0];
-
-    signal(SIGPIPE, SIG_IGN);
-    /* if receiver dies, we get an error and can clean up
-       rather than just dying */
-
-    rc = migrate_read_fixedmessage(recv_fd, migrate_receiver_banner,
+    if (*send_fd < 0 || *recv_fd < 0) {
+        if (rune)
+            child = create_migration_child(rune, send_fd, recv_fd);
+        if (child < 0) {
+            fprintf(stderr, "failed to create migration channel"
+                    " - empty command ?\n");
+            exit(1);
+        }
+    }
+
+    rc = migrate_read_fixedmessage(*recv_fd, migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "banner", rune);
     if (rc) {
-        close(send_fd);
-        migration_child_report(child, recv_fd);
+        close(*send_fd);
+        migration_child_report(child, *recv_fd);
         exit(-rc);
     }
 
-    save_domain_core_writeconfig(send_fd, "migration stream",
+    save_domain_core_writeconfig(*send_fd, "migration stream",
                                  config_data, config_len);
-
+    if (mchild)
+        *mchild = child;
+    return;
+}
+
+static void migrate_domain(const char *domain_spec, const char *rune,
+                           const char *override_config_file)
+{
+    int rc;
+    int send_fd = -1, recv_fd = -1;
+    libxl_domain_suspend_info suspinfo;
+    char *away_domname;
+    char rc_buf;
+    pid_t child = -1;
+
+    migrate_do_preamble(domain_spec, rune, override_config_file,
+                        &send_fd, &recv_fd, &child);
     xtl_stdiostream_adjust_flags(logger, XTL_STDIOSTREAM_HIDE_PROGRESS, 0);
 
     memset(&suspinfo, 0, sizeof(suspinfo));
@@ -2798,7 +2841,12 @@ static void core_dump_domain(const char 
     if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
 }
 
-static void migrate_receive(int debug, int daemonize, int monitor)
+/* Explicitly specifying a send & recv fd allows us to switch to a tcp socket
+ * based migration/replication channel in future, instead of exec/forking from
+ * an ssh channel.
+ */
+static void migrate_receive(int debug, int daemonize, int monitor,
+                            int send_fd, int recv_fd)
 {
     int rc, rc2;
     char rc_buf;
@@ -2810,7 +2858,7 @@ static void migrate_receive(int debug, i
 
     fprintf(stderr, "migration target: Ready to receive domain.\n");
 
-    CHK_ERRNO( libxl_write_exactly(ctx, 1,
+    CHK_ERRNO( libxl_write_exactly(ctx, send_fd,
                                    migrate_receiver_banner,
                                    sizeof(migrate_receiver_banner)-1,
                                    "migration ack stream",
@@ -2822,7 +2870,7 @@ static void migrate_receive(int debug, i
     dom_info.monitor = monitor;
     dom_info.paused = 1;
     dom_info.restore_file = "incoming migration stream";
-    dom_info.migrate_fd = 0; /* stdin */
+    dom_info.migrate_fd = recv_fd;
     dom_info.migration_domname_r = &migration_domname;
     dom_info.no_incr_generationid = 1;
 
@@ -2836,13 +2884,13 @@ static void migrate_receive(int debug, i
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
-    rc = libxl_write_exactly(ctx, 1,
+    rc = libxl_write_exactly(ctx, send_fd,
                              migrate_receiver_ready,
                              sizeof(migrate_receiver_ready),
                              "migration ack stream", "ready message");
     if (rc) exit(-rc);
 
-    rc = migrate_read_fixedmessage(0, migrate_permission_to_go,
+    rc = migrate_read_fixedmessage(recv_fd, migrate_permission_to_go,
                                    sizeof(migrate_permission_to_go),
                                    "GO message", 0);
     if (rc) goto perhaps_destroy_notify_rc;
@@ -2861,7 +2909,7 @@ static void migrate_receive(int debug, i
     rc = 0;
 
  perhaps_destroy_notify_rc:
-    rc2 = libxl_write_exactly(ctx, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd,
                               migrate_report, sizeof(migrate_report),
                               "migration ack stream",
                               "success/failure report");
@@ -2869,7 +2917,7 @@ static void migrate_receive(int debug, i
 
     rc_buf = -rc;
     assert(!!rc_buf == !!rc);
-    rc2 = libxl_write_exactly(ctx, 1, &rc_buf, 1,
+    rc2 = libxl_write_exactly(ctx, send_fd, &rc_buf, 1,
                               "migration ack stream",
                               "success/failure code");
     if (rc2) exit(-ERROR_BADFAIL);
@@ -2887,7 +2935,7 @@ static void migrate_receive(int debug, i
         fprintf(stderr, "migration target: Cleanup OK, granting sender"
                 " permission to resume.\n");
 
-        rc2 = libxl_write_exactly(ctx, 1,
+        rc2 = libxl_write_exactly(ctx, send_fd,
                                   migrate_permission_to_go,
                                   sizeof(migrate_permission_to_go),
                                   "migration ack stream",
@@ -2983,7 +3031,8 @@ int main_migrate_receive(int argc, char 
         help("migrate-receive");
         return 2;
     }
-    migrate_receive(debug, daemonize, monitor);
+    migrate_receive(debug, daemonize, monitor,
+                    /* write to stdout */1, /* read from stdin */0);
     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 Jan 31 01:06:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2AH-0003Y9-Fe; Tue, 31 Jan 2012 01:05:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2AF-0003Y3-HJ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:05:39 +0000
Received: from [85.158.138.51:46723] by server-1.bemta-3.messagelabs.com id
	C5/AD-09565-26E372F4; Tue, 31 Jan 2012 01:05:38 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327971935!11331861!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20440 invoked from network); 31 Jan 2012 01:05:37 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 01:05:37 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15T3i004153; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15TIO004150;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: cd3d43d88c0568142dd061e744c34479e1a440f4
Message-Id: <cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:08 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
	QEMU	suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971511 28800
# Node ID cd3d43d88c0568142dd061e744c34479e1a440f4
# Parent  39f63438767a8225a3148a43139c10f55a62c669
libxl: QMP stop/resume & refactor QEMU suspend/resume/save

Implement QMP stop and resume functionality and split
device model save into 3 parts:
 suspend_dm(domid)
 save_dm(domid, fd)
 resume_dm(domid)

Integrate Device model suspend into suspend_common_callback

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 39f63438767a -r cd3d43d88c05 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:24 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:31 2012 -0800
@@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
     return rc ? 0 : 1;
 }
 
+int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret = 0, fd2 = -1;
+    const char *filename = libxl__device_model_savefile(gc, domid);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        libxl__qemu_traditional_cmd(gc, domid, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
+        if (fd2 < 0) {
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "Unable to create a QEMU save file\n");
+            return ERROR_FAIL;
+        }
+        /* Save DM state into fd2 */
+        ret = libxl__qmp_migrate(gc, domid, fd2);
+        if (ret)
+            unlink(filename);
+        close(fd2);
+        fd2 = -1;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return ret;
+}
+
+int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        libxl__qemu_traditional_cmd(gc, domid, "continue");
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 static int libxl__domain_suspend_common_callback(void *data)
 {
     struct suspendinfo *si = data;
@@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
             return 0;
         }
         si->guest_responded = 1;
-        return 1;
+        goto suspend_dm;
     }
 
     if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
             shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
-                return 1;
+                goto suspend_dm;
             }
         }
 
@@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
 
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
     return 0;
+
+ suspend_dm:
+    if (si->hvm) {
+        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            return 0;
+        }
+    }
+    return 1;
 }
 
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
@@ -638,32 +704,6 @@ int libxl__domain_save_device_model(libx
     struct stat st;
     uint32_t qemu_state_len;
 
-    switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
-        if (ret)
-            goto out;
-        close(fd2);
-        fd2 = -1;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
diff -r 39f63438767a -r cd3d43d88c05 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 30 16:58:24 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Mon Jan 30 16:58:31 2012 -0800
@@ -277,6 +277,8 @@ _hidden int libxl__domain_suspend_common
                                          libxl_domain_type type,
                                          int live, int debug);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
@@ -620,6 +622,10 @@ _hidden int libxl__qmp_query_serial(libx
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
 /* close and free the QMP handler */
diff -r 39f63438767a -r cd3d43d88c05 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Mon Jan 30 16:58:24 2012 -0800
+++ b/tools/libxl/libxl_qmp.c	Mon Jan 30 16:58:31 2012 -0800
@@ -878,6 +878,38 @@ out:
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:06:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2AH-0003Y9-Fe; Tue, 31 Jan 2012 01:05:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2AF-0003Y3-HJ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:05:39 +0000
Received: from [85.158.138.51:46723] by server-1.bemta-3.messagelabs.com id
	C5/AD-09565-26E372F4; Tue, 31 Jan 2012 01:05:38 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-174.messagelabs.com!1327971935!11331861!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20440 invoked from network); 31 Jan 2012 01:05:37 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 01:05:37 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15T3i004153; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15TIO004150;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: cd3d43d88c0568142dd061e744c34479e1a440f4
Message-Id: <cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:08 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
	QEMU	suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971511 28800
# Node ID cd3d43d88c0568142dd061e744c34479e1a440f4
# Parent  39f63438767a8225a3148a43139c10f55a62c669
libxl: QMP stop/resume & refactor QEMU suspend/resume/save

Implement QMP stop and resume functionality and split
device model save into 3 parts:
 suspend_dm(domid)
 save_dm(domid, fd)
 resume_dm(domid)

Integrate Device model suspend into suspend_common_callback

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 39f63438767a -r cd3d43d88c05 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:24 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:31 2012 -0800
@@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
     return rc ? 0 : 1;
 }
 
+int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
+{
+    libxl_ctx *ctx = libxl__gc_owner(gc);
+    int ret = 0, fd2 = -1;
+    const char *filename = libxl__device_model_savefile(gc, domid);
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
+                   "Saving device model state to %s", filename);
+        libxl__qemu_traditional_cmd(gc, domid, "save");
+        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_stop(gc, domid))
+            return ERROR_FAIL;
+        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
+        if (fd2 < 0) {
+            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
+                             "Unable to create a QEMU save file\n");
+            return ERROR_FAIL;
+        }
+        /* Save DM state into fd2 */
+        ret = libxl__qmp_migrate(gc, domid, fd2);
+        if (ret)
+            unlink(filename);
+        close(fd2);
+        fd2 = -1;
+        break;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return ret;
+}
+
+int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
+{
+
+    switch (libxl__device_model_version_running(gc, domid)) {
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
+        libxl__qemu_traditional_cmd(gc, domid, "continue");
+        break;
+    }
+    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
+        if (libxl__qmp_resume(gc, domid))
+            return ERROR_FAIL;
+    default:
+        return ERROR_INVAL;
+    }
+
+    return 0;
+}
+
 static int libxl__domain_suspend_common_callback(void *data)
 {
     struct suspendinfo *si = data;
@@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
             return 0;
         }
         si->guest_responded = 1;
-        return 1;
+        goto suspend_dm;
     }
 
     if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
@@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
             shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
             if (shutdown_reason == SHUTDOWN_suspend) {
                 LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
-                return 1;
+                goto suspend_dm;
             }
         }
 
@@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
 
     LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
     return 0;
+
+ suspend_dm:
+    if (si->hvm) {
+        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
+        if (ret) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "libxl__domain_suspend_device_model failed ret=%d", ret);
+            return 0;
+        }
+    }
+    return 1;
 }
 
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
@@ -638,32 +704,6 @@ int libxl__domain_save_device_model(libx
     struct stat st;
     uint32_t qemu_state_len;
 
-    switch (libxl__device_model_version_running(gc, domid)) {
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
-                   "Saving device model state to %s", filename);
-        libxl__qemu_traditional_cmd(gc, domid, "save");
-        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
-        break;
-    }
-    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-        if (fd2 < 0) {
-            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
-                             "Unable to create a QEMU save file\n");
-            return ERROR_FAIL;
-        }
-        /* Save DM state into fd2 */
-        ret = libxl__qmp_migrate(gc, domid, fd2);
-        if (ret)
-            goto out;
-        close(fd2);
-        fd2 = -1;
-        break;
-    default:
-        return ERROR_INVAL;
-    }
-
     if (stat(filename, &st) < 0)
     {
         LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Unable to stat qemu save file\n");
diff -r 39f63438767a -r cd3d43d88c05 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 30 16:58:24 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Mon Jan 30 16:58:31 2012 -0800
@@ -277,6 +277,8 @@ _hidden int libxl__domain_suspend_common
                                          libxl_domain_type type,
                                          int live, int debug);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_save_device_model(libxl__gc *gc, uint32_t domid, int fd);
 _hidden void libxl__userdata_destroyall(libxl__gc *gc, uint32_t domid);
 
@@ -620,6 +622,10 @@ _hidden int libxl__qmp_query_serial(libx
 _hidden int libxl__qmp_pci_add(libxl__gc *gc, int d, libxl_device_pci *pcidev);
 _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
                                libxl_device_pci *pcidev);
+/* Suspend QEMU. */
+_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
+/* Resume QEMU. */
+_hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 /* Save current QEMU state into fd. */
 _hidden int libxl__qmp_migrate(libxl__gc *gc, int domid, int fd);
 /* close and free the QMP handler */
diff -r 39f63438767a -r cd3d43d88c05 tools/libxl/libxl_qmp.c
--- a/tools/libxl/libxl_qmp.c	Mon Jan 30 16:58:24 2012 -0800
+++ b/tools/libxl/libxl_qmp.c	Mon Jan 30 16:58:31 2012 -0800
@@ -878,6 +878,38 @@ out:
     return rc;
 }
 
+int libxl__qmp_stop(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "stop", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
+int libxl__qmp_resume(libxl__gc *gc, int domid)
+{
+    libxl__qmp_handler *qmp = NULL;
+    int rc = 0;
+
+    qmp = libxl__qmp_initialize(libxl__gc_owner(gc), domid);
+    if (!qmp)
+        return ERROR_FAIL;
+
+    rc = qmp_synchronous_send(qmp, "cont", NULL,
+                              NULL, NULL, qmp->timeout);
+
+    libxl__qmp_close(qmp);
+    return rc;
+}
+
 int libxl__qmp_initializations(libxl_ctx *ctx, uint32_t domid)
 {
     libxl__qmp_handler *qmp = NULL;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:06:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2AK-0003YV-97; Tue, 31 Jan 2012 01:05:44 +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 1Rs2AI-0003Y1-OT
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:05:42 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327971934!8516817!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23332 invoked from network); 31 Jan 2012 01:05:36 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 01:05:36 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15TBu004146; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15TZa004143;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: 39f63438767a8225a3148a43139c10f55a62c669
Message-Id: <39f63438767a8225a314.1327971907@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:07 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 6] libxl: bugfix: create_domain() return to
	caller if	!daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971504 28800
# Node ID 39f63438767a8225a3148a43139c10f55a62c669
# Parent  20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
libxl: bugfix: create_domain() return to caller if !daemonize

Currently the create_domain function does not honor
the daemonize flag properly. It exits irrespective of
the value of the flag. This patch fixes the issue.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 20bbc4a754a7 -r 39f63438767a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:13 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:24 2012 -0800
@@ -1814,7 +1814,7 @@ waitpid_out:
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
      */
-    if ( !need_daemon )
+    if ( daemonize && !need_daemon )
         exit(ret);
 
     return ret;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:06:19 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:06:19 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2AK-0003YV-97; Tue, 31 Jan 2012 01:05:44 +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 1Rs2AI-0003Y1-OT
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:05:42 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-21.messagelabs.com!1327971934!8516817!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23332 invoked from network); 31 Jan 2012 01:05:36 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 01:05:36 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15TBu004146; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15TZa004143;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: 39f63438767a8225a3148a43139c10f55a62c669
Message-Id: <39f63438767a8225a314.1327971907@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:07 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 6] libxl: bugfix: create_domain() return to
	caller if	!daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971504 28800
# Node ID 39f63438767a8225a3148a43139c10f55a62c669
# Parent  20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
libxl: bugfix: create_domain() return to caller if !daemonize

Currently the create_domain function does not honor
the daemonize flag properly. It exits irrespective of
the value of the flag. This patch fixes the issue.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 20bbc4a754a7 -r 39f63438767a tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:13 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:24 2012 -0800
@@ -1814,7 +1814,7 @@ waitpid_out:
      * If we have daemonized then do not return to the caller -- this has
      * already happened in the parent.
      */
-    if ( !need_daemon )
+    if ( daemonize && !need_daemon )
         exit(ret);
 
     return ret;

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:07:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2BK-0003jI-AB; Tue, 31 Jan 2012 01:06:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2BI-0003in-23
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:06:44 +0000
Received: from [85.158.138.51:56470] by server-7.bemta-3.messagelabs.com id
	D7/38-31267-3AE372F4; Tue, 31 Jan 2012 01:06:43 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327972000!11115670!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22142 invoked from network); 31 Jan 2012 01:06:41 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:06:41 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15TBY004160; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15Tus004157;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: efe92d80c47487485056266a1404a8d2817b7f09
Message-Id: <efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:09 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971527 28800
# Node ID efe92d80c47487485056266a1404a8d2817b7f09
# Parent  cd3d43d88c0568142dd061e744c34479e1a440f4
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 30 16:58:31 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 30 16:58:47 2012 -0800
@@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, fast)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 30 16:58:31 2012 -0800
+++ b/tools/libxl/libxl.h	Mon Jan 30 16:58:47 2012 -0800
@@ -268,7 +268,7 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:31 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:47 2012 -0800
@@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 1);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 1);
     exit(-ERROR_FAIL);
 
  failed_badly:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:07:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2BK-0003jI-AB; Tue, 31 Jan 2012 01:06:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2BI-0003in-23
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:06:44 +0000
Received: from [85.158.138.51:56470] by server-7.bemta-3.messagelabs.com id
	D7/38-31267-3AE372F4; Tue, 31 Jan 2012 01:06:43 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327972000!11115670!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22142 invoked from network); 31 Jan 2012 01:06:41 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:06:41 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15TBY004160; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15Tus004157;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: efe92d80c47487485056266a1404a8d2817b7f09
Message-Id: <efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:09 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971527 28800
# Node ID efe92d80c47487485056266a1404a8d2817b7f09
# Parent  cd3d43d88c0568142dd061e744c34479e1a440f4
libxl: support suspend_cancel in domain_resume

Add an extra parameter to libxl_domain_resume indicating
if the caller wishes to use the SUSPEND_CANCEL style
resume instead of the normal resume.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 30 16:58:31 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 30 16:58:47 2012 -0800
@@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
     return rc;
 }
 
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast)
 {
     GC_INIT(ctx);
     int rc = 0;
 
-    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
-        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
-                "non-cooperative hvm domain %u", domid);
-        rc = ERROR_NI;
-        goto out;
-    }
-    if (xc_domain_resume(ctx->xch, domid, 0)) {
+    if (xc_domain_resume(ctx->xch, domid, fast)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xc_domain_resume failed for domain %u",
                         domid);
         rc = ERROR_FAIL;
         goto out;
     }
+
+    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
+        rc = libxl__domain_resume_device_model(gc, domid);
+        if (rc) {
+            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                       "failed to resume device model for domain %u:%d",
+                       domid, rc);
+            goto out;
+        }
+    }
+
     if (!xs_resume_domain(ctx->xsh, domid)) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
                         "xs_resume_domain failed for domain %u",
diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 30 16:58:31 2012 -0800
+++ b/tools/libxl/libxl.h	Mon Jan 30 16:58:47 2012 -0800
@@ -268,7 +268,7 @@ int libxl_domain_create_restore(libxl_ct
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
-int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
+int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast);
 int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
 int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:31 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:47 2012 -0800
@@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
         if (common_domname) {
             libxl_domain_rename(ctx, domid, away_domname, common_domname);
         }
-        rc = libxl_domain_resume(ctx, domid);
+        rc = libxl_domain_resume(ctx, domid, 1);
         if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
 
         fprintf(stderr, "Migration failed due to problems at target.\n");
@@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
     close(send_fd);
     migration_child_report(child, recv_fd);
     fprintf(stderr, "Migration failed, resuming at sender.\n");
-    libxl_domain_resume(ctx, domid);
+    libxl_domain_resume(ctx, domid, 1);
     exit(-ERROR_FAIL);
 
  failed_badly:

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:07:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:07:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2BK-0003jX-Mi; Tue, 31 Jan 2012 01:06:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2BI-0003is-Bl
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:06:44 +0000
Received: from [85.158.138.51:48059] by server-8.bemta-3.messagelabs.com id
	57/0D-31878-3AE372F4; Tue, 31 Jan 2012 01:06:43 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327972000!11115670!2
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22167 invoked from network); 31 Jan 2012 01:06:42 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:06:42 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15T43004139; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15Tf1004136;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
Message-Id: <20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:06 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send commands
	to traditional	qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971493 28800
# Node ID 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: helper function to send commands to traditional qemu

Introduce a helper function to send commands to traditional
qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
libxl__domain_save_device_model and libxl_domain_unpause have
been refactored to use this function.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 30 16:58:13 2012 -0800
@@ -517,7 +517,7 @@ int libxl_domain_unpause(libxl_ctx *ctx,
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__qemu_traditional_cmd(gc, domid, "continue");
             libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:13 2012 -0800
@@ -349,6 +349,15 @@ out:
     return rc;
 }
 
+int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                const char *cmd)
+{
+    char *path = NULL;
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                          domid);
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -631,12 +640,9 @@ int libxl__domain_save_device_model(libx
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        char *path = NULL;
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                    "Saving device model state to %s", filename);
-        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                              domid);
-        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__qemu_traditional_cmd(gc, domid, "save");
         libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
         break;
     }
diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 30 16:58:13 2012 -0800
@@ -263,6 +263,8 @@ _hidden int libxl__build_hvm(libxl__gc *
               libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
+_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                        const char *cmd);
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Jan 30 16:58:13 2012 -0800
@@ -602,9 +602,8 @@ static int qemu_pci_add_xenstore(libxl__
         libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                         pcidev->bus, pcidev->dev, pcidev->func);
     }
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                          domid);
-    xs_write(ctx->xsh, XBT_NULL, path, "pci-ins", strlen("pci-ins"));
+
+    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
     rc = libxl__wait_for_device_model(gc, domid, NULL, NULL,
                                       pci_ins_check, state);
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
@@ -857,12 +856,11 @@ static int qemu_pci_remove_xenstore(libx
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid);
     libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                     pcidev->bus, pcidev->dev, pcidev->func);
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid);
 
     /* Remove all functions at once atomically by only signalling
      * device-model for function 0 */
     if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
-        xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", strlen("pci-rem"));
+        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
         if (libxl__wait_for_device_model(gc, domid, "pci-removed",
                                          NULL, NULL, NULL) < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model didn't respond in time");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:07:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:07:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2BK-0003jX-Mi; Tue, 31 Jan 2012 01:06:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2BI-0003is-Bl
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:06:44 +0000
Received: from [85.158.138.51:48059] by server-8.bemta-3.messagelabs.com id
	57/0D-31878-3AE372F4; Tue, 31 Jan 2012 01:06:43 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-14.tower-174.messagelabs.com!1327972000!11115670!2
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22167 invoked from network); 31 Jan 2012 01:06:42 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:06:42 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15T43004139; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15Tf1004136;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
Message-Id: <20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:06 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send commands
	to traditional	qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971493 28800
# Node ID 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
libxl: helper function to send commands to traditional qemu

Introduce a helper function to send commands to traditional
qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
libxl__domain_save_device_model and libxl_domain_unpause have
been refactored to use this function.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl.c	Mon Jan 30 16:58:13 2012 -0800
@@ -517,7 +517,7 @@ int libxl_domain_unpause(libxl_ctx *ctx,
         path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
         state = libxl__xs_read(gc, XBT_NULL, path);
         if (state != NULL && !strcmp(state, "paused")) {
-            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
+            libxl__qemu_traditional_cmd(gc, domid, "continue");
             libxl__wait_for_device_model(gc, domid, "running",
                                          NULL, NULL, NULL);
         }
diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:13 2012 -0800
@@ -349,6 +349,15 @@ out:
     return rc;
 }
 
+int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                const char *cmd)
+{
+    char *path = NULL;
+    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
+                          domid);
+    return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
+}
+
 int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                                  libxl_domain_build_info *info,
                                  libxl__domain_build_state *state,
@@ -631,12 +640,9 @@ int libxl__domain_save_device_model(libx
 
     switch (libxl__device_model_version_running(gc, domid)) {
     case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
-        char *path = NULL;
         LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
                    "Saving device model state to %s", filename);
-        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                              domid);
-        libxl__xs_write(gc, XBT_NULL, path, "save");
+        libxl__qemu_traditional_cmd(gc, domid, "save");
         libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
         break;
     }
diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_internal.h	Mon Jan 30 16:58:13 2012 -0800
@@ -263,6 +263,8 @@ _hidden int libxl__build_hvm(libxl__gc *
               libxl_device_model_info *dm_info,
               libxl__domain_build_state *state);
 
+_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
+                                        const char *cmd);
 _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
                                  const char *old_name, const char *new_name,
                                  xs_transaction_t trans);
diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_pci.c
--- a/tools/libxl/libxl_pci.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxl/libxl_pci.c	Mon Jan 30 16:58:13 2012 -0800
@@ -602,9 +602,8 @@ static int qemu_pci_add_xenstore(libxl__
         libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                         pcidev->bus, pcidev->dev, pcidev->func);
     }
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
-                          domid);
-    xs_write(ctx->xsh, XBT_NULL, path, "pci-ins", strlen("pci-ins"));
+
+    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
     rc = libxl__wait_for_device_model(gc, domid, NULL, NULL,
                                       pci_ins_check, state);
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
@@ -857,12 +856,11 @@ static int qemu_pci_remove_xenstore(libx
     path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid);
     libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
                     pcidev->bus, pcidev->dev, pcidev->func);
-    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid);
 
     /* Remove all functions at once atomically by only signalling
      * device-model for function 0 */
     if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
-        xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", strlen("pci-rem"));
+        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
         if (libxl__wait_for_device_model(gc, domid, "pci-removed",
                                          NULL, NULL, NULL) < 0) {
             LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model didn't respond in time");

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:11:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2FC-0004Hy-Gb; Tue, 31 Jan 2012 01:10:46 +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 1Rs2FB-0004Hj-7V
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:10:45 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327971935!5687413!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4208 invoked from network); 31 Jan 2012 01:05:36 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:05:36 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15TB4004174; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15TK9004171;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
Message-Id: <ffc99e708e90eb140b0a.1327971911@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:11 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 6 of 6] libxl: resume instead of unpause on xl
	save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971541 28800
# Node ID ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
# Parent  d79c7a853c644d459cda93bf61657be48104cd63
libxl: resume instead of unpause on xl save -c

The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
So call libxl_domain_resume instead of libxl_domain_unpause, when taking
a checkpoint of the domain (using xl save -c).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r d79c7a853c64 -r ffc99e708e90 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:53 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:59:01 2012 -0800
@@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
     close(fd);
 
     if (checkpoint)
-        libxl_domain_unpause(ctx, domid);
+        libxl_domain_resume(ctx, domid, 1);
     else
         libxl_domain_destroy(ctx, domid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:11:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2FC-0004Hy-Gb; Tue, 31 Jan 2012 01:10:46 +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 1Rs2FB-0004Hj-7V
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:10:45 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-16.tower-182.messagelabs.com!1327971935!5687413!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4208 invoked from network); 31 Jan 2012 01:05:36 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-16.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:05:36 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V15TB4004174; Mon, 30 Jan 2012 17:05:29 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V15TK9004171;
	Mon, 30 Jan 2012 17:05:29 -0800
MIME-Version: 1.0
X-Mercurial-Node: ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
Message-Id: <ffc99e708e90eb140b0a.1327971911@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:05:11 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: anthony.perard@citrix.com, brendan@cs.ubc.ca, ian.jackson@eu.citrix.com,
	ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 6 of 6] libxl: resume instead of unpause on xl
	save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327971541 28800
# Node ID ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
# Parent  d79c7a853c644d459cda93bf61657be48104cd63
libxl: resume instead of unpause on xl save -c

The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
So call libxl_domain_resume instead of libxl_domain_unpause, when taking
a checkpoint of the domain (using xl save -c).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r d79c7a853c64 -r ffc99e708e90 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:53 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:59:01 2012 -0800
@@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
     close(fd);
 
     if (checkpoint)
-        libxl_domain_unpause(ctx, domid);
+        libxl_domain_resume(ctx, domid, 1);
     else
         libxl_domain_destroy(ctx, domid);
 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:25:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2TG-0004fQ-Ve; Tue, 31 Jan 2012 01:25:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rs2TF-0004fL-Fh
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:25:17 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327972997!61826365!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8194 invoked from network); 31 Jan 2012 01:23:18 -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;
	31 Jan 2012 01:23:18 -0000
Received: by iaeh11 with SMTP id h11so40887555iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 17:25:15 -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=/MrHQtunoYbq9rlNxoQLGzQZCBnE35RMnH1A+4LjXFs=;
	b=J3q+n5xAc/K6IJASuAq9HEtpEX0rsZeXvC1Zbcs7OK+4JPMC/7mfMWoUwjhivP24uX
	e2Z2iKSpaJlNnfzrOEG+SEoNd6Du5lQ8rfVqYNH0L5XM7WeXntDbvcsL89nEfJEOGyaI
	fGvLv4V6wK9qZeGGGaKp46rxL1vspbcTBnQYk=
MIME-Version: 1.0
Received: by 10.43.47.202 with SMTP id ut10mr6633522icb.22.1327973114967; Mon,
	30 Jan 2012 17:25:14 -0800 (PST)
Received: by 10.42.96.132 with HTTP; Mon, 30 Jan 2012 17:25:14 -0800 (PST)
In-Reply-To: <1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
Date: Tue, 31 Jan 2012 02:25:14 +0100
Message-ID: <CAL4WiirrQ+2PqojQ9dnGRF16cxx-1QNRWqcMkVqqZSZwvWC58Q@mail.gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Le 30 janvier 2012 15:45, Wei Liu <wei.liu2@citrix.com> a =E9crit :
> If we allocate large arrays in per-cpu section, multi-page ring
> feature is likely to blow up the per-cpu section. So avoid allocating
> large arrays, instead we only store pointers to scratch spaces in
> per-cpu section.
>
> CPU hotplug event is also taken care of.
>

> =A0}
>
> +static int __create_percpu_scratch_space(unsigned int cpu)
> +{
> + =A0 =A0 =A0 per_cpu(tx_copy_ops, cpu) =3D
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 vzalloc(sizeof(struct gnttab_copy) * MAX_PE=
NDING_REQS);
> +
> + =A0 =A0 =A0 per_cpu(grant_copy_op, cpu) =3D
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 vzalloc(sizeof(struct gnttab_copy)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * 2 * XEN_NETIF_RX_RING_SIZ=
E);
> +
> + =A0 =A0 =A0 per_cpu(meta, cpu) =3D vzalloc(sizeof(struct xenvif_rx_meta)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
* 2 * XEN_NETIF_RX_RING_SIZE);
> +
> + =A0 =A0 =A0 if (!per_cpu(tx_copy_ops, cpu) ||
> + =A0 =A0 =A0 =A0 =A0 !per_cpu(grant_copy_op, cpu) ||
> + =A0 =A0 =A0 =A0 =A0 !per_cpu(meta, cpu))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOMEM;
> +
> + =A0 =A0 =A0 return 0;
> +}
> +

Problem is you lost NUMA awareness here.

Please check vzalloc_node()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:25:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01: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 1Rs2TG-0004fQ-Ve; Tue, 31 Jan 2012 01:25:18 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <eric.dumazet@gmail.com>) id 1Rs2TF-0004fL-Fh
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:25:17 +0000
X-Env-Sender: eric.dumazet@gmail.com
X-Msg-Ref: server-8.tower-27.messagelabs.com!1327972997!61826365!1
X-Originating-IP: [209.85.210.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8194 invoked from network); 31 Jan 2012 01:23:18 -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;
	31 Jan 2012 01:23:18 -0000
Received: by iaeh11 with SMTP id h11so40887555iae.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 17:25:15 -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=/MrHQtunoYbq9rlNxoQLGzQZCBnE35RMnH1A+4LjXFs=;
	b=J3q+n5xAc/K6IJASuAq9HEtpEX0rsZeXvC1Zbcs7OK+4JPMC/7mfMWoUwjhivP24uX
	e2Z2iKSpaJlNnfzrOEG+SEoNd6Du5lQ8rfVqYNH0L5XM7WeXntDbvcsL89nEfJEOGyaI
	fGvLv4V6wK9qZeGGGaKp46rxL1vspbcTBnQYk=
MIME-Version: 1.0
Received: by 10.43.47.202 with SMTP id ut10mr6633522icb.22.1327973114967; Mon,
	30 Jan 2012 17:25:14 -0800 (PST)
Received: by 10.42.96.132 with HTTP; Mon, 30 Jan 2012 17:25:14 -0800 (PST)
In-Reply-To: <1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
Date: Tue, 31 Jan 2012 02:25:14 +0100
Message-ID: <CAL4WiirrQ+2PqojQ9dnGRF16cxx-1QNRWqcMkVqqZSZwvWC58Q@mail.gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com, konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Le 30 janvier 2012 15:45, Wei Liu <wei.liu2@citrix.com> a =E9crit :
> If we allocate large arrays in per-cpu section, multi-page ring
> feature is likely to blow up the per-cpu section. So avoid allocating
> large arrays, instead we only store pointers to scratch spaces in
> per-cpu section.
>
> CPU hotplug event is also taken care of.
>

> =A0}
>
> +static int __create_percpu_scratch_space(unsigned int cpu)
> +{
> + =A0 =A0 =A0 per_cpu(tx_copy_ops, cpu) =3D
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 vzalloc(sizeof(struct gnttab_copy) * MAX_PE=
NDING_REQS);
> +
> + =A0 =A0 =A0 per_cpu(grant_copy_op, cpu) =3D
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 vzalloc(sizeof(struct gnttab_copy)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * 2 * XEN_NETIF_RX_RING_SIZ=
E);
> +
> + =A0 =A0 =A0 per_cpu(meta, cpu) =3D vzalloc(sizeof(struct xenvif_rx_meta)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
* 2 * XEN_NETIF_RX_RING_SIZE);
> +
> + =A0 =A0 =A0 if (!per_cpu(tx_copy_ops, cpu) ||
> + =A0 =A0 =A0 =A0 =A0 !per_cpu(grant_copy_op, cpu) ||
> + =A0 =A0 =A0 =A0 =A0 !per_cpu(meta, cpu))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOMEM;
> +
> + =A0 =A0 =A0 return 0;
> +}
> +

Problem is you lost NUMA awareness here.

Please check vzalloc_node()

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:31:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2Yc-0004qZ-B2; Tue, 31 Jan 2012 01:30:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2Ya-0004qI-9e
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:30:48 +0000
Received: from [85.158.138.51:2874] by server-4.bemta-3.messagelabs.com id
	5F/3A-32238-744472F4; Tue, 31 Jan 2012 01:30:47 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327973444!11267154!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19555 invoked from network); 31 Jan 2012 01:30:46 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:30:46 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V1Udua004546; Mon, 30 Jan 2012 17:30:39 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V1Udip004543;
	Mon, 30 Jan 2012 17:30:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: 070f78ba4244cf8239ded3a69ccd54ac6e1bd24d
Message-Id: <070f78ba4244cf8239de.1327972926@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:22:06 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327972788 28800
# Node ID 070f78ba4244cf8239ded3a69ccd54ac6e1bd24d
# Parent  0129989da2cda789f86f2bc83d9c642a0bcebe60
libxl: Remus - xl remus command

xl remus acts as a frontend to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication is
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * Replication is done over ssh connection currently (like live migration
   with xl). Future versions will have an option to use simple tcp socket
   based replication channel (for both Remus & live migration).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 30 17:19:48 2012 -0800
@@ -471,6 +471,40 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
     return ptr;
 }
 
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = -1;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/libxl.h	Mon Jan 30 17:19:48 2012 -0800
@@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast);
diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/xl.h	Mon Jan 30 17:19:48 2012 -0800
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 17:19:48 2012 -0800
@@ -2846,7 +2846,7 @@ static void core_dump_domain(const char 
  * an ssh channel.
  */
 static void migrate_receive(int debug, int daemonize, int monitor,
-                            int send_fd, int recv_fd)
+                            int send_fd, int recv_fd, int remus)
 {
     int rc, rc2;
     char rc_buf;
@@ -2881,6 +2881,41 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    if (remus) {
+        /* If we are here, it means that the sender (primary) has crashed.
+         * TODO: Split-Brain Check.
+         */
+        fprintf(stderr, "migration target: Remus Failover for domain %u\n",
+                domid);
+
+        /*
+         * If domain renaming fails, lets just continue (as we need the domain
+         * to be up & dom names may not matter much, as long as its reachable
+         * over network).
+         *
+         * If domain unpausing fails, destroy domain ? Or is it better to have
+         * a consistent copy of the domain (memory, cpu state, disk)
+         * on atleast one physical host ? Right now, lets just leave the domain
+         * as is and let the Administrator decide (or troubleshoot).
+         */
+        if (migration_domname) {
+            rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                     common_domname);
+            if (rc)
+                fprintf(stderr, "migration target (Remus): "
+                        "Failed to rename domain from %s to %s:%d\n",
+                        migration_domname, common_domname, rc);
+        }
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+
+        exit(rc ? -ERROR_FAIL: 0);
+    }
+
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
@@ -3007,10 +3042,10 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-    int debug = 0, daemonize = 1, monitor = 1;
+    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3024,6 +3059,9 @@ int main_migrate_receive(int argc, char 
         case 'd':
             debug = 1;
             break;
+        case 'r':
+            remus = 1;
+            break;
         }
     }
 
@@ -3032,7 +3070,8 @@ int main_migrate_receive(int argc, char 
         return 2;
     }
     migrate_receive(debug, daemonize, monitor,
-                    /* write to stdout */1, /* read from stdin */0);
+                    /* write to stdout */ 1, /* read from stdin */ 0,
+                    remus);
     return 0;
 }
 
@@ -5968,6 +6007,91 @@ done:
     return ret;
 }
 
+int main_remus(int argc, char **argv)
+{
+    int opt, rc, daemonize = 1;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+    libxl_domain_remus_info r_info;
+    int send_fd = -1, recv_fd = -1;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        case 'e':
+            daemonize = 0;
+            break;
+        }
+    }
+
+    domain = argv[optind];
+    host = argv[optind + 1];
+
+    if (r_info.blackhole) {
+        find_domain(domain);
+        send_fd = open("/dev/null", O_RDWR, 0644);
+        if (send_fd < 0) {
+            perror("failed to open /dev/null");
+            exit(-1);
+        }
+    } else {
+
+        /*
+         * TODO: change this to plain TCP socket based channel
+         * instead of SSH. For both live-migration and Remus.
+         */
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
+                         ssh_command, host,
+                         daemonize ? "" : " -e") < 0)
+                return 1;
+        }
+        migrate_do_preamble(domain, rune, NULL, &send_fd, &recv_fd, NULL);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     * TODO: Split-Brain check.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid, 1);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Mon Jan 30 17:19:48 2012 -0800
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<host>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl migrate-receive -r\n"
+      "-e                      Do not wait in the background (on <host>) for the death\n"
+      "                        of the domain."
+
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:31:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:31:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2Yc-0004qZ-B2; Tue, 31 Jan 2012 01:30:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2Ya-0004qI-9e
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:30:48 +0000
Received: from [85.158.138.51:2874] by server-4.bemta-3.messagelabs.com id
	5F/3A-32238-744472F4; Tue, 31 Jan 2012 01:30:47 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-12.tower-174.messagelabs.com!1327973444!11267154!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19555 invoked from network); 31 Jan 2012 01:30:46 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-12.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:30:46 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V1Udua004546; Mon, 30 Jan 2012 17:30:39 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V1Udip004543;
	Mon, 30 Jan 2012 17:30:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: 070f78ba4244cf8239ded3a69ccd54ac6e1bd24d
Message-Id: <070f78ba4244cf8239de.1327972926@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:22:06 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 2 of 2] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327972788 28800
# Node ID 070f78ba4244cf8239ded3a69ccd54ac6e1bd24d
# Parent  0129989da2cda789f86f2bc83d9c642a0bcebe60
libxl: Remus - xl remus command

xl remus acts as a frontend to enable remus for a given domain.
 * At the moment, only memory checkpointing and blackhole replication is
   supported. Support for disk checkpointing and network buffering will
   be added in future.
 * Replication is done over ssh connection currently (like live migration
   with xl). Future versions will have an option to use simple tcp socket
   based replication channel (for both Remus & live migration).

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 30 17:19:48 2012 -0800
@@ -471,6 +471,40 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
     return ptr;
 }
 
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int fd)
+{
+    GC_INIT(ctx);
+    libxl_domain_type type = libxl__domain_type(gc, domid);
+    int rc = 0;
+
+    if (info == NULL) {
+        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
+                   "No remus_info structure supplied for domain %d", domid);
+        rc = -1;
+        goto remus_fail;
+    }
+
+    /* TBD: Remus setup - i.e. attach qdisc, enable disk buffering, etc */
+
+    /* Point of no return */
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, /* live */ 1,
+                                      /* debug */ 0, info);
+
+    /* 
+     * With Remus, if we reach this point, it means either
+     * backup died or some network error occurred preventing us
+     * from sending checkpoints.
+     */
+
+    /* TBD: Remus cleanup - i.e. detach qdisc, release other
+     * resources.
+     */
+ remus_fail:
+    GC_FREE;
+    return rc;
+}
+
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                          uint32_t domid, int fd)
 {
diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/libxl.h	Mon Jan 30 17:19:48 2012 -0800
@@ -266,6 +266,8 @@ typedef int (*libxl_console_ready)(libxl
 int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
 int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int restore_fd);
 void libxl_domain_config_dispose(libxl_domain_config *d_config);
+int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
+                             uint32_t domid, int fd);
 int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
                           uint32_t domid, int fd);
 int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast);
diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/xl.h
--- a/tools/libxl/xl.h	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/xl.h	Mon Jan 30 17:19:48 2012 -0800
@@ -94,6 +94,7 @@ int main_cpupoolnumasplit(int argc, char
 int main_getenforce(int argc, char **argv);
 int main_setenforce(int argc, char **argv);
 int main_loadpolicy(int argc, char **argv);
+int main_remus(int argc, char **argv);
 
 void help(const char *command);
 
diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 17:19:48 2012 -0800
@@ -2846,7 +2846,7 @@ static void core_dump_domain(const char 
  * an ssh channel.
  */
 static void migrate_receive(int debug, int daemonize, int monitor,
-                            int send_fd, int recv_fd)
+                            int send_fd, int recv_fd, int remus)
 {
     int rc, rc2;
     char rc_buf;
@@ -2881,6 +2881,41 @@ static void migrate_receive(int debug, i
         exit(-rc);
     }
 
+    if (remus) {
+        /* If we are here, it means that the sender (primary) has crashed.
+         * TODO: Split-Brain Check.
+         */
+        fprintf(stderr, "migration target: Remus Failover for domain %u\n",
+                domid);
+
+        /*
+         * If domain renaming fails, lets just continue (as we need the domain
+         * to be up & dom names may not matter much, as long as its reachable
+         * over network).
+         *
+         * If domain unpausing fails, destroy domain ? Or is it better to have
+         * a consistent copy of the domain (memory, cpu state, disk)
+         * on atleast one physical host ? Right now, lets just leave the domain
+         * as is and let the Administrator decide (or troubleshoot).
+         */
+        if (migration_domname) {
+            rc = libxl_domain_rename(ctx, domid, migration_domname,
+                                     common_domname);
+            if (rc)
+                fprintf(stderr, "migration target (Remus): "
+                        "Failed to rename domain from %s to %s:%d\n",
+                        migration_domname, common_domname, rc);
+        }
+
+        rc = libxl_domain_unpause(ctx, domid);
+        if (rc)
+            fprintf(stderr, "migration target (Remus): "
+                    "Failed to unpause domain %s (id: %u):%d\n",
+                    common_domname, domid, rc);
+
+        exit(rc ? -ERROR_FAIL: 0);
+    }
+
     fprintf(stderr, "migration target: Transfer complete,"
             " requesting permission to start domain.\n");
 
@@ -3007,10 +3042,10 @@ int main_restore(int argc, char **argv)
 
 int main_migrate_receive(int argc, char **argv)
 {
-    int debug = 0, daemonize = 1, monitor = 1;
+    int debug = 0, daemonize = 1, monitor = 1, remus = 0;
     int opt;
 
-    while ((opt = def_getopt(argc, argv, "Fed", "migrate-receive", 0)) != -1) {
+    while ((opt = def_getopt(argc, argv, "Fedr", "migrate-receive", 0)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
@@ -3024,6 +3059,9 @@ int main_migrate_receive(int argc, char 
         case 'd':
             debug = 1;
             break;
+        case 'r':
+            remus = 1;
+            break;
         }
     }
 
@@ -3032,7 +3070,8 @@ int main_migrate_receive(int argc, char 
         return 2;
     }
     migrate_receive(debug, daemonize, monitor,
-                    /* write to stdout */1, /* read from stdin */0);
+                    /* write to stdout */ 1, /* read from stdin */ 0,
+                    remus);
     return 0;
 }
 
@@ -5968,6 +6007,91 @@ done:
     return ret;
 }
 
+int main_remus(int argc, char **argv)
+{
+    int opt, rc, daemonize = 1;
+    const char *ssh_command = "ssh";
+    char *host = NULL, *rune = NULL, *domain = NULL;
+    libxl_domain_remus_info r_info;
+    int send_fd = -1, recv_fd = -1;
+
+    memset(&r_info, 0, sizeof(libxl_domain_remus_info));
+    /* Defaults */
+    r_info.interval = 200;
+    r_info.blackhole = 0;
+    r_info.compression = 1;
+
+    while ((opt = def_getopt(argc, argv, "bui:s:e", "remus", 2)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+
+        case 'i':
+	    r_info.interval = atoi(optarg);
+            break;
+        case 'b':
+            r_info.blackhole = 1;
+            break;
+        case 'u':
+	    r_info.compression = 0;
+            break;
+        case 's':
+            ssh_command = optarg;
+            break;
+        case 'e':
+            daemonize = 0;
+            break;
+        }
+    }
+
+    domain = argv[optind];
+    host = argv[optind + 1];
+
+    if (r_info.blackhole) {
+        find_domain(domain);
+        send_fd = open("/dev/null", O_RDWR, 0644);
+        if (send_fd < 0) {
+            perror("failed to open /dev/null");
+            exit(-1);
+        }
+    } else {
+
+        /*
+         * TODO: change this to plain TCP socket based channel
+         * instead of SSH. For both live-migration and Remus.
+         */
+        if (!ssh_command[0]) {
+            rune = host;
+        } else {
+            if (asprintf(&rune, "exec %s %s xl migrate-receive -r %s",
+                         ssh_command, host,
+                         daemonize ? "" : " -e") < 0)
+                return 1;
+        }
+        migrate_do_preamble(domain, rune, NULL, &send_fd, &recv_fd, NULL);
+    }
+
+    /* Point of no return */
+    rc = libxl_domain_remus_start(ctx, &r_info, domid, send_fd);
+
+    /* If we are here, it means backup has failed/domain suspend failed.
+     * Try to resume the domain and exit gracefully.
+     * TODO: Split-Brain check.
+     */
+    fprintf(stderr, "remus sender: libxl_domain_suspend failed"
+            " (rc=%d)\n", rc);
+
+    if (rc == ERROR_GUEST_TIMEDOUT)
+        fprintf(stderr, "Failed to suspend domain at primary.\n");
+    else {
+        fprintf(stderr, "Remus: Backup failed? resuming domain at primary.\n");
+        libxl_domain_resume(ctx, domid, 1);
+    }
+
+    close(send_fd);
+    return -ERROR_FAIL;
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/xl_cmdtable.c
--- a/tools/libxl/xl_cmdtable.c	Mon Jan 30 17:19:46 2012 -0800
+++ b/tools/libxl/xl_cmdtable.c	Mon Jan 30 17:19:48 2012 -0800
@@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
       "Loads a new policy int the Flask Xen security module",
       "<policy file>",
     },
+    { "remus",
+      &main_remus, 0,
+      "Enable Remus HA for domain",
+      "[options] <Domain> [<host>]",
+      "-i MS                   Checkpoint domain memory every MS milliseconds (def. 200ms).\n"
+      "-b                      Replicate memory checkpoints to /dev/null (blackhole)\n"
+      "-u                      Disable memory checkpoint compression.\n"
+      "-s <sshcommand>         Use <sshcommand> instead of ssh.  String will be passed\n"
+      "                        to sh. If empty, run <host> instead of \n"
+      "                        ssh <host> xl migrate-receive -r\n"
+      "-e                      Do not wait in the background (on <host>) for the death\n"
+      "                        of the domain."
+
+    },
 };
 
 int cmdtable_len = sizeof(cmd_table)/sizeof(struct cmd_spec);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:31:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2Ya-0004qS-V0; Tue, 31 Jan 2012 01:30:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2YZ-0004qH-Qu
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:30:47 +0000
Received: from [85.158.138.51:2864] by server-2.bemta-3.messagelabs.com id
	3F/D8-24515-644472F4; Tue, 31 Jan 2012 01:30:46 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327973444!11330416!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16894 invoked from network); 31 Jan 2012 01:30:46 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:30:46 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V1UdXJ004532; Mon, 30 Jan 2012 17:30:39 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V1Ucne004529;
	Mon, 30 Jan 2012 17:30:38 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:22:04 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl - Remus support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series introduces a basic framework to
incorporate Remus into the libxl toolstack. The only functionality
currently implemented is memory checkpointing.

These patches depend on "libxl: refactor suspend/resume code" patch series.

Changes since previous version:
 * Receiving end of remus is now part of migrate-receive
 * Re-use code already present for live migration (refactored
   in the above mentioned patch series)

Shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:31:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2Ya-0004qS-V0; Tue, 31 Jan 2012 01:30:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2YZ-0004qH-Qu
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:30:47 +0000
Received: from [85.158.138.51:2864] by server-2.bemta-3.messagelabs.com id
	3F/D8-24515-644472F4; Tue, 31 Jan 2012 01:30:46 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-11.tower-174.messagelabs.com!1327973444!11330416!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16894 invoked from network); 31 Jan 2012 01:30:46 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-11.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:30:46 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V1UdXJ004532; Mon, 30 Jan 2012 17:30:39 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V1Ucne004529;
	Mon, 30 Jan 2012 17:30:38 -0800
MIME-Version: 1.0
Message-Id: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:22:04 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 0 of 2] libxl - Remus support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch series introduces a basic framework to
incorporate Remus into the libxl toolstack. The only functionality
currently implemented is memory checkpointing.

These patches depend on "libxl: refactor suspend/resume code" patch series.

Changes since previous version:
 * Receiving end of remus is now part of migrate-receive
 * Re-use code already present for live migration (refactored
   in the above mentioned patch series)

Shriram

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:31:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2Ye-0004qv-Na; Tue, 31 Jan 2012 01:30:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2Yd-0004qe-2a
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:30:51 +0000
Received: from [85.158.138.51:31187] by server-12.bemta-3.messagelabs.com id
	6A/0C-24557-A44472F4; Tue, 31 Jan 2012 01:30:50 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327973444!11326865!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24956 invoked from network); 31 Jan 2012 01:30:45 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:30:45 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V1UdOC004539; Mon, 30 Jan 2012 17:30:39 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V1UdZk004536;
	Mon, 30 Jan 2012 17:30:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0129989da2cda789f86f2bc83d9c642a0bcebe60
Message-Id: <0129989da2cda789f86f.1327972925@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:22:05 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: Remus - suspend/postflush/commit
	callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327972786 28800
# Node ID 0129989da2cda789f86f2bc83d9c642a0bcebe60
# Parent  ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
libxl: Remus - suspend/postflush/commit callbacks

 * Add libxl callback functions for Remus checkpoint suspend, postflush
   (aka resume) and checkpoint commit callbacks.
 * suspend callback is a stub that just bounces off
   libxl__domain_suspend_common_callback - which suspends the domain and
   saves the devices model state to a file.
 * resume callback currently just resumes the domain (and the device model).
 * commit callback just writes out the saved device model state to the
   network and sleeps for the checkpoint interval.

 * Future patches will augument these callbacks with more functionalities like
   issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r ffc99e708e90 -r 0129989da2cd tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 30 16:59:01 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 30 17:19:46 2012 -0800
@@ -480,7 +480,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd);
     GC_FREE;
diff -r ffc99e708e90 -r 0129989da2cd tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 30 16:59:01 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Mon Jan 30 17:19:46 2012 -0800
@@ -404,6 +404,8 @@ struct suspendinfo {
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -609,9 +611,43 @@ static int libxl__domain_suspend_common_
     return 1;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    /* TODO: Issue disk and network checkpoint reqs. */
+    return libxl__domain_suspend_common_callback(data);
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Resumes the domain and the device model */
+    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+        return 0;
+
+    /* TODO: Deal with disk. Start a new network output buffer */
+    return 1;
+}
+
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    /* This would go into tailbuf. */
+    if (si->hvm &&
+        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+        return 0;
+
+    /* TODO: Wait for disk and memory ack, release network buffer */
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -642,10 +678,20 @@ int libxl__domain_suspend_common(libxl__
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        /* save_callbacks:
+         * suspend - called after expiration of checkpoint interval,
+         *           to *suspend* the domain.
+         *
+         * postcopy - called after the domain's dirty pages have been
+         *            copied into an output buffer. We *resume* the domain
+         *            & the device model, return to the caller. Caller then
+         *            flushes the output buffer, while the domain continues to run.
+         *
+         * checkpoint - called after the memory checkpoint has been flushed out
+         *              into the network. Send the saved device state, *wait*
+         *              for checkpoint ack and *release* the network buffer (TBD).
+         *              Then *sleep* for the checkpoint interval.
+         */
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
diff -r ffc99e708e90 -r 0129989da2cd tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 30 16:59:01 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Mon Jan 30 17:19:46 2012 -0800
@@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
diff -r ffc99e708e90 -r 0129989da2cd tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 30 16:59:01 2012 -0800
+++ b/tools/libxl/libxl_types.idl	Mon Jan 30 17:19:46 2012 -0800
@@ -397,3 +397,9 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_domain_remus_info = Struct("domain_remus_info",[
+    ("interval",     integer),
+    ("blackhole",    bool),
+    ("compression",  bool),
+    ])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 01:31:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 01:31:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs2Ye-0004qv-Na; Tue, 31 Jan 2012 01:30:52 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1Rs2Yd-0004qe-2a
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 01:30:51 +0000
Received: from [85.158.138.51:31187] by server-12.bemta-3.messagelabs.com id
	6A/0C-24557-A44472F4; Tue, 31 Jan 2012 01:30:50 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-10.tower-174.messagelabs.com!1327973444!11326865!1
X-Originating-IP: [198.162.52.240]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24956 invoked from network); 31 Jan 2012 01:30:45 -0000
Received: from unknown (HELO athos.nss.cs.ubc.ca) (198.162.52.240)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 01:30:45 -0000
Received: from athos.nss.cs.ubc.ca (localhost [127.0.0.1])
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id
	q0V1UdOC004539; Mon, 30 Jan 2012 17:30:39 -0800
Received: (from root@localhost)
	by athos.nss.cs.ubc.ca (8.14.3/8.14.3/Submit) id q0V1UdZk004536;
	Mon, 30 Jan 2012 17:30:39 -0800
MIME-Version: 1.0
X-Mercurial-Node: 0129989da2cda789f86f2bc83d9c642a0bcebe60
Message-Id: <0129989da2cda789f86f.1327972925@athos.nss.cs.ubc.ca>
In-Reply-To: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
User-Agent: Mercurial-patchbomb/1.4.3
Date: Mon, 30 Jan 2012 17:22:05 -0800
From: rshriram@cs.ubc.ca
To: xen-devel@lists.xensource.com
Cc: brendan@cs.ubc.ca, ian.jackson@eu.citrix.com, ian.campbell@citrix.com
Subject: [Xen-devel] [PATCH 1 of 2] libxl: Remus - suspend/postflush/commit
	callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Shriram Rajagopalan <rshriram@cs.ubc.ca>
# Date 1327972786 28800
# Node ID 0129989da2cda789f86f2bc83d9c642a0bcebe60
# Parent  ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
libxl: Remus - suspend/postflush/commit callbacks

 * Add libxl callback functions for Remus checkpoint suspend, postflush
   (aka resume) and checkpoint commit callbacks.
 * suspend callback is a stub that just bounces off
   libxl__domain_suspend_common_callback - which suspends the domain and
   saves the devices model state to a file.
 * resume callback currently just resumes the domain (and the device model).
 * commit callback just writes out the saved device model state to the
   network and sleeps for the checkpoint interval.

 * Future patches will augument these callbacks with more functionalities like
   issuing network buffer plug/unplug commands, disk checkpoint commands, etc.

Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

diff -r ffc99e708e90 -r 0129989da2cd tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Mon Jan 30 16:59:01 2012 -0800
+++ b/tools/libxl/libxl.c	Mon Jan 30 17:19:46 2012 -0800
@@ -480,7 +480,9 @@ int libxl_domain_suspend(libxl_ctx *ctx,
     int debug = info != NULL && info->flags & XL_SUSPEND_DEBUG;
     int rc = 0;
 
-    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug);
+    rc = libxl__domain_suspend_common(gc, domid, fd, type, live, debug,
+                                      /* No Remus */ NULL);
+
     if (!rc && type == LIBXL_DOMAIN_TYPE_HVM)
         rc = libxl__domain_save_device_model(gc, domid, fd);
     GC_FREE;
diff -r ffc99e708e90 -r 0129989da2cd tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c	Mon Jan 30 16:59:01 2012 -0800
+++ b/tools/libxl/libxl_dom.c	Mon Jan 30 17:19:46 2012 -0800
@@ -404,6 +404,8 @@ struct suspendinfo {
     int hvm;
     unsigned int flags;
     int guest_responded;
+    int save_fd; /* Migration stream fd (for Remus) */
+    int interval; /* checkpoint interval (for Remus) */
 };
 
 static int libxl__domain_suspend_common_switch_qemu_logdirty(int domid, unsigned int enable, void *data)
@@ -609,9 +611,43 @@ static int libxl__domain_suspend_common_
     return 1;
 }
 
+static int libxl__remus_domain_suspend_callback(void *data)
+{
+    /* TODO: Issue disk and network checkpoint reqs. */
+    return libxl__domain_suspend_common_callback(data);
+}
+
+static int libxl__remus_domain_resume_callback(void *data)
+{
+    struct suspendinfo *si = data;
+    libxl_ctx *ctx = libxl__gc_owner(si->gc);
+
+    /* Resumes the domain and the device model */
+    if (libxl_domain_resume(ctx, si->domid, /* Fast Suspend */1))
+        return 0;
+
+    /* TODO: Deal with disk. Start a new network output buffer */
+    return 1;
+}
+
+static int libxl__remus_domain_checkpoint_callback(void *data)
+{
+    struct suspendinfo *si = data;
+
+    /* This would go into tailbuf. */
+    if (si->hvm &&
+        libxl__domain_save_device_model(si->gc, si->domid, si->save_fd))
+        return 0;
+
+    /* TODO: Wait for disk and memory ack, release network buffer */
+    usleep(si->interval * 1000);
+    return 1;
+}
+
 int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                  libxl_domain_type type,
-                                 int live, int debug)
+                                 int live, int debug,
+                                 const libxl_domain_remus_info *r_info)
 {
     libxl_ctx *ctx = libxl__gc_owner(gc);
     int flags;
@@ -642,10 +678,20 @@ int libxl__domain_suspend_common(libxl__
         return ERROR_INVAL;
     }
 
+    memset(&si, 0, sizeof(si));
     flags = (live) ? XCFLAGS_LIVE : 0
           | (debug) ? XCFLAGS_DEBUG : 0
           | (hvm) ? XCFLAGS_HVM : 0;
 
+    if (r_info != NULL) {
+        si.interval = r_info->interval;
+        if (r_info->compression)
+            flags |= XCFLAGS_CHECKPOINT_COMPRESS;
+        si.save_fd = fd;
+    }
+    else
+        si.save_fd = -1;
+
     si.domid = domid;
     si.flags = flags;
     si.hvm = hvm;
@@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
     }
 
     memset(&callbacks, 0, sizeof(callbacks));
-    callbacks.suspend = libxl__domain_suspend_common_callback;
+    if (r_info != NULL) {
+        /* save_callbacks:
+         * suspend - called after expiration of checkpoint interval,
+         *           to *suspend* the domain.
+         *
+         * postcopy - called after the domain's dirty pages have been
+         *            copied into an output buffer. We *resume* the domain
+         *            & the device model, return to the caller. Caller then
+         *            flushes the output buffer, while the domain continues to run.
+         *
+         * checkpoint - called after the memory checkpoint has been flushed out
+         *              into the network. Send the saved device state, *wait*
+         *              for checkpoint ack and *release* the network buffer (TBD).
+         *              Then *sleep* for the checkpoint interval.
+         */
+        callbacks.suspend = libxl__remus_domain_suspend_callback;
+        callbacks.postcopy = libxl__remus_domain_resume_callback;
+        callbacks.checkpoint = libxl__remus_domain_checkpoint_callback;
+    } else
+        callbacks.suspend = libxl__domain_suspend_common_callback;
+
     callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty;
     callbacks.data = &si;
 
diff -r ffc99e708e90 -r 0129989da2cd tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h	Mon Jan 30 16:59:01 2012 -0800
+++ b/tools/libxl/libxl_internal.h	Mon Jan 30 17:19:46 2012 -0800
@@ -275,7 +275,8 @@ _hidden int libxl__domain_restore_common
                                          int fd);
 _hidden int libxl__domain_suspend_common(libxl__gc *gc, uint32_t domid, int fd,
                                          libxl_domain_type type,
-                                         int live, int debug);
+                                         int live, int debug,
+                                         const libxl_domain_remus_info *r_info);
 _hidden const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid);
 _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid);
diff -r ffc99e708e90 -r 0129989da2cd tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Mon Jan 30 16:59:01 2012 -0800
+++ b/tools/libxl/libxl_types.idl	Mon Jan 30 17:19:46 2012 -0800
@@ -397,3 +397,9 @@ libxl_sched_sedf = Struct("sched_sedf", 
     ("extratime", integer),
     ("weight", integer),
     ], dispose_fn=None)
+
+libxl_domain_remus_info = Struct("domain_remus_info",[
+    ("interval",     integer),
+    ("blackhole",    bool),
+    ("compression",  bool),
+    ])

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 07:02:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 07:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs7iu-000729-OG; Tue, 31 Jan 2012 07:01:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1Rs7it-000721-0a
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 07:01:47 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327993250!52369773!1
X-Originating-IP: [220.181.15.4]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQgPT4gNjgzOA==\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQgPT4gNjgzOA==\n,HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22933 invoked from network); 31 Jan 2012 07:00:52 -0000
Received: from m15-4.126.com (HELO m15-4.126.com) (220.181.15.4)
	by server-5.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 07:00:52 -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=UZxcH7s5RlXtRnP
	Z1KhwevISUtvf8oN4xiM6MWAk75Q=; b=JY4SdK9CW8oogDqI67t+lSXBySpsVEO
	yOP4sIXrlksbh9pdxtdI1A4FpCPWNarx5Pb1zY6MZ47OdiU0qXbU8HZ1D4aUoFGH
	oGs312zfhomldkls2KD/hDVHX/4807dgldr7UHA/22/mTgCGtaNbKgjcFVlI9FiW
	6+j889oS6fek=
Received: from hxkhust ( [111.172.52.117] ) by ajax-webmail-wmsvr4
	(Coremail) ; Tue, 31 Jan 2012 15:01:37 +0800 (CST)
Date: Tue, 31 Jan 2012 15:01:37 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: "Tim Deegan" <tim@xen.org>
Message-ID: <78371237.7e0e.13532919b2f.Coremail.hxkhust@126.com>
In-Reply-To: <20120130094722.GB96325@ocelot.phlegethon.org>
References: <20120130094722.GB96325@ocelot.phlegethon.org>
	<298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [111.172.52.117]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: PVW01WZvb3Rlcl9odG09MjY1NTo4MQ==
X-CM-TRANSID: BMqowGA530DSkSdPy50HAA--.13621W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbikh5GBU3knbyFCgABsJ
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5477655499241936633=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5477655499241936633==
Content-Type: multipart/alternative; 
	boundary="----=_Part_85121_106923213.1327993297711"

------=_Part_85121_106923213.1327993297711
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Is the (prototype) memory-sharing code mentioned in your last email already offered in Xen resource code?
Thank you for your help.

At 2012-01-30 17:47:31,"Tim Deegan" <tim@xen.org> wrote:
>Hi,
>
>At 16:11 +0800 on 30 Jan (1327939919), hxkhust wrote:
>> On a physical machine with xen virtualization platform installed ,VM
>> A,VM B are VM C's virtual disks are all image files,among which VM A
>> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
>> format. And VM A and VM B's virtual disk image files are based on VM
>> C's virtual disk image file.Now these three VMs are running on the
>> same physical machine with xen installed. In the process of running VM
>> A get a page data from VM C's virtual disk image file. After that ,VM
>> B also need to get the same page data as VM A got just now.Under this
>> situation, does VMM copy the page data from VM A's memory to VM B's
>> memory or get the page data from VM C's virtual disk image file in the
>> physical disk again?
>
>It reads it from the disk again, unless you're using the (prototype)
>memory-sharing code that's in blktap.
>
>> Or if I would like to figure out this problem,what shall I do?
>
>Instrument the disk, or read the code.
>
>Tim.




------=_Part_85121_106923213.1327993297711
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 style="LINE-HEIGHT: 1.7; FONT-FAMILY: arial; COLOR: #000000; FONT-SIZE: 14px">
<DIV>Is the (prototype) memory-sharing code mentioned in your last email already offered in Xen resource code?</DIV>
<DIV>Thank you for your help.<BR><BR>At&nbsp;2012-01-30&nbsp;17:47:31,"Tim&nbsp;Deegan"&nbsp;&lt;<A href="mailto:tim@xen.org">tim@xen.org</A>&gt;&nbsp;wrote:<BR>&gt;Hi,<BR>&gt;<BR>&gt;At&nbsp;16:11&nbsp;+0800&nbsp;on&nbsp;30&nbsp;Jan&nbsp;(1327939919),&nbsp;hxkhust&nbsp;wrote:<BR>&gt;&gt;&nbsp;On&nbsp;a&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;virtualization&nbsp;platform&nbsp;installed&nbsp;,VM<BR>&gt;&gt;&nbsp;A,VM&nbsp;B&nbsp;are&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;all&nbsp;image&nbsp;files,among&nbsp;which&nbsp;VM&nbsp;A<BR>&gt;&gt;&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;QCOW2&nbsp;format&nbsp;and&nbsp;VM&nbsp;C's&nbsp;disk&nbsp;is&nbsp;RAW<BR>&gt;&gt;&nbsp;format.&nbsp;And&nbsp;VM&nbsp;A&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;files&nbsp;are&nbsp;based&nbsp;on&nbsp;VM<BR>&gt;&gt;&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file.Now&nbsp;these&nbsp;three&nbsp;VMs&nbsp;are&nbsp;running&nbsp;on&nbsp;the<BR>&gt;&gt;&nbsp;same&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;installed.&nbsp;In&nbsp;the&nbsp;process&nbsp;of&nbsp;running&nbsp;VM<BR>&gt;&gt;&nbsp;A&nbsp;get&nbsp;a&nbsp;page&nbsp;data&nbsp;from&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file.&nbsp;After&nbsp;that&nbsp;,VM<BR>&gt;&gt;&nbsp;B&nbsp;also&nbsp;need&nbsp;to&nbsp;get&nbsp;the&nbsp;same&nbsp;page&nbsp;data&nbsp;as&nbsp;VM&nbsp;A&nbsp;got&nbsp;just&nbsp;now.Under&nbsp;this<BR>&gt;&gt;&nbsp;situation,&nbsp;does&nbsp;VMM&nbsp;copy&nbsp;the&nbsp;page&nbsp;data&nbsp;from&nbsp;VM&nbsp;A's&nbsp;memory&nbsp;to&nbsp;VM&nbsp;B's<BR>&gt;&gt;&nbsp;memory&nbsp;or&nbsp;get&nbsp;the&nbsp;page&nbsp;data&nbsp;from&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file&nbsp;in&nbsp;the<BR>&gt;&gt;&nbsp;physical&nbsp;disk&nbsp;again?<BR>&gt;<BR>&gt;It&nbsp;reads&nbsp;it&nbsp;from&nbsp;the&nbsp;disk&nbsp;again,&nbsp;unless&nbsp;you're&nbsp;using&nbsp;the&nbsp;(prototype)<BR>&gt;memory-sharing&nbsp;code&nbsp;that's&nbsp;in&nbsp;blktap.<BR>&gt;<BR>&gt;&gt;&nbsp;Or&nbsp;if&nbsp;I&nbsp;would&nbsp;like&nbsp;to&nbsp;figure&nbsp;out&nbsp;this&nbsp;problem,what&nbsp;shall&nbsp;I&nbsp;do?<BR>&gt;<BR>&gt;Instrument&nbsp;the&nbsp;disk,&nbsp;or&nbsp;read&nbsp;the&nbsp;code.<BR>&gt;<BR>&gt;Tim.<BR></DIV></DIV><BR><BR><SPAN title="neteasefooter"><SPAN id="netease_mail_footer"></SPAN></SPAN></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_85121_106923213.1327993297711--



--===============5477655499241936633==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5477655499241936633==--



From xen-devel-bounces@lists.xensource.com Tue Jan 31 07:02:48 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 07:02:48 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs7iu-000729-OG; Tue, 31 Jan 2012 07:01:48 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <hxkhust@126.com>) id 1Rs7it-000721-0a
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 07:01:47 +0000
X-Env-Sender: hxkhust@126.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1327993250!52369773!1
X-Originating-IP: [220.181.15.4]
X-SpamReason: No, hits=0.1 required=7.0 tests=sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQgPT4gNjgzOA==\n,sa_preprocessor: 
	QmFkIElQOiAyMjAuMTgxLjE1LjQgPT4gNjgzOA==\n,HTML_50_60,HTML_MESSAGE
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22933 invoked from network); 31 Jan 2012 07:00:52 -0000
Received: from m15-4.126.com (HELO m15-4.126.com) (220.181.15.4)
	by server-5.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 07:00:52 -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=UZxcH7s5RlXtRnP
	Z1KhwevISUtvf8oN4xiM6MWAk75Q=; b=JY4SdK9CW8oogDqI67t+lSXBySpsVEO
	yOP4sIXrlksbh9pdxtdI1A4FpCPWNarx5Pb1zY6MZ47OdiU0qXbU8HZ1D4aUoFGH
	oGs312zfhomldkls2KD/hDVHX/4807dgldr7UHA/22/mTgCGtaNbKgjcFVlI9FiW
	6+j889oS6fek=
Received: from hxkhust ( [111.172.52.117] ) by ajax-webmail-wmsvr4
	(Coremail) ; Tue, 31 Jan 2012 15:01:37 +0800 (CST)
Date: Tue, 31 Jan 2012 15:01:37 +0800 (CST)
From: hxkhust  <hxkhust@126.com>
To: "Tim Deegan" <tim@xen.org>
Message-ID: <78371237.7e0e.13532919b2f.Coremail.hxkhust@126.com>
In-Reply-To: <20120130094722.GB96325@ocelot.phlegethon.org>
References: <20120130094722.GB96325@ocelot.phlegethon.org>
	<298edff9.10461.1352dabac58.Coremail.hxkhust@126.com>
MIME-Version: 1.0
X-Originating-IP: [111.172.52.117]
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build
	111202(16086.4213.4207) Copyright (c) 2002-2012 www.mailtech.cn 126com
X-CM-CTRLDATA: PVW01WZvb3Rlcl9odG09MjY1NTo4MQ==
X-CM-TRANSID: BMqowGA530DSkSdPy50HAA--.13621W
X-CM-SenderInfo: xk0nx3lvw6ij2wof0z/1tbikh5GBU3knbyFCgABsJ
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] A Problem with Page Cache in Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============5477655499241936633=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============5477655499241936633==
Content-Type: multipart/alternative; 
	boundary="----=_Part_85121_106923213.1327993297711"

------=_Part_85121_106923213.1327993297711
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Is the (prototype) memory-sharing code mentioned in your last email already offered in Xen resource code?
Thank you for your help.

At 2012-01-30 17:47:31,"Tim Deegan" <tim@xen.org> wrote:
>Hi,
>
>At 16:11 +0800 on 30 Jan (1327939919), hxkhust wrote:
>> On a physical machine with xen virtualization platform installed ,VM
>> A,VM B are VM C's virtual disks are all image files,among which VM A
>> and VM B's virtual disks are QCOW2 format and VM C's disk is RAW
>> format. And VM A and VM B's virtual disk image files are based on VM
>> C's virtual disk image file.Now these three VMs are running on the
>> same physical machine with xen installed. In the process of running VM
>> A get a page data from VM C's virtual disk image file. After that ,VM
>> B also need to get the same page data as VM A got just now.Under this
>> situation, does VMM copy the page data from VM A's memory to VM B's
>> memory or get the page data from VM C's virtual disk image file in the
>> physical disk again?
>
>It reads it from the disk again, unless you're using the (prototype)
>memory-sharing code that's in blktap.
>
>> Or if I would like to figure out this problem,what shall I do?
>
>Instrument the disk, or read the code.
>
>Tim.




------=_Part_85121_106923213.1327993297711
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 style="LINE-HEIGHT: 1.7; FONT-FAMILY: arial; COLOR: #000000; FONT-SIZE: 14px">
<DIV>Is the (prototype) memory-sharing code mentioned in your last email already offered in Xen resource code?</DIV>
<DIV>Thank you for your help.<BR><BR>At&nbsp;2012-01-30&nbsp;17:47:31,"Tim&nbsp;Deegan"&nbsp;&lt;<A href="mailto:tim@xen.org">tim@xen.org</A>&gt;&nbsp;wrote:<BR>&gt;Hi,<BR>&gt;<BR>&gt;At&nbsp;16:11&nbsp;+0800&nbsp;on&nbsp;30&nbsp;Jan&nbsp;(1327939919),&nbsp;hxkhust&nbsp;wrote:<BR>&gt;&gt;&nbsp;On&nbsp;a&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;virtualization&nbsp;platform&nbsp;installed&nbsp;,VM<BR>&gt;&gt;&nbsp;A,VM&nbsp;B&nbsp;are&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;all&nbsp;image&nbsp;files,among&nbsp;which&nbsp;VM&nbsp;A<BR>&gt;&gt;&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disks&nbsp;are&nbsp;QCOW2&nbsp;format&nbsp;and&nbsp;VM&nbsp;C's&nbsp;disk&nbsp;is&nbsp;RAW<BR>&gt;&gt;&nbsp;format.&nbsp;And&nbsp;VM&nbsp;A&nbsp;and&nbsp;VM&nbsp;B's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;files&nbsp;are&nbsp;based&nbsp;on&nbsp;VM<BR>&gt;&gt;&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file.Now&nbsp;these&nbsp;three&nbsp;VMs&nbsp;are&nbsp;running&nbsp;on&nbsp;the<BR>&gt;&gt;&nbsp;same&nbsp;physical&nbsp;machine&nbsp;with&nbsp;xen&nbsp;installed.&nbsp;In&nbsp;the&nbsp;process&nbsp;of&nbsp;running&nbsp;VM<BR>&gt;&gt;&nbsp;A&nbsp;get&nbsp;a&nbsp;page&nbsp;data&nbsp;from&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file.&nbsp;After&nbsp;that&nbsp;,VM<BR>&gt;&gt;&nbsp;B&nbsp;also&nbsp;need&nbsp;to&nbsp;get&nbsp;the&nbsp;same&nbsp;page&nbsp;data&nbsp;as&nbsp;VM&nbsp;A&nbsp;got&nbsp;just&nbsp;now.Under&nbsp;this<BR>&gt;&gt;&nbsp;situation,&nbsp;does&nbsp;VMM&nbsp;copy&nbsp;the&nbsp;page&nbsp;data&nbsp;from&nbsp;VM&nbsp;A's&nbsp;memory&nbsp;to&nbsp;VM&nbsp;B's<BR>&gt;&gt;&nbsp;memory&nbsp;or&nbsp;get&nbsp;the&nbsp;page&nbsp;data&nbsp;from&nbsp;VM&nbsp;C's&nbsp;virtual&nbsp;disk&nbsp;image&nbsp;file&nbsp;in&nbsp;the<BR>&gt;&gt;&nbsp;physical&nbsp;disk&nbsp;again?<BR>&gt;<BR>&gt;It&nbsp;reads&nbsp;it&nbsp;from&nbsp;the&nbsp;disk&nbsp;again,&nbsp;unless&nbsp;you're&nbsp;using&nbsp;the&nbsp;(prototype)<BR>&gt;memory-sharing&nbsp;code&nbsp;that's&nbsp;in&nbsp;blktap.<BR>&gt;<BR>&gt;&gt;&nbsp;Or&nbsp;if&nbsp;I&nbsp;would&nbsp;like&nbsp;to&nbsp;figure&nbsp;out&nbsp;this&nbsp;problem,what&nbsp;shall&nbsp;I&nbsp;do?<BR>&gt;<BR>&gt;Instrument&nbsp;the&nbsp;disk,&nbsp;or&nbsp;read&nbsp;the&nbsp;code.<BR>&gt;<BR>&gt;Tim.<BR></DIV></DIV><BR><BR><SPAN title="neteasefooter"><SPAN id="netease_mail_footer"></SPAN></SPAN></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_85121_106923213.1327993297711--



--===============5477655499241936633==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============5477655499241936633==--



From xen-devel-bounces@lists.xensource.com Tue Jan 31 07:31:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 07:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs8AU-0007Hf-Fo; Tue, 31 Jan 2012 07:30:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rs8AT-0007Ha-8L
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 07:30:17 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327995009!3798215!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15065 invoked from network); 31 Jan 2012 07:30:10 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 07:30:10 -0000
Received: by eekb45 with SMTP id b45so33360693eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 23:30:09 -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:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=aPBr0uC1OxyNrtGlOov1MzSvApWgXO1U82h+0u3Druo=;
	b=eSD7OXQSkbm6BxrBzLMcATYdGBya2ob8RvaLxmcu2GyNgT4CuCIVFmWbGQPpmZqvRa
	JFKlaSZI7DAPmw+91/EWpdYZO/RX+koGUdRBCYgWnHmGGX1i5SFudmUd5LRY7zqLsMUd
	En2mk72m3fViaRANJOaTvYCtxTsdL2KZ30iKc=
Received: by 10.14.130.208 with SMTP id k56mr949818eei.123.1327995009309;
	Mon, 30 Jan 2012 23:30:09 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id e12sm82960662eea.5.2012.01.30.23.30.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Jan 2012 23:30:08 -0800 (PST)
Message-ID: <4F27987E.5010707@redhat.com>
Date: Tue, 31 Jan 2012 08:30:06 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu,gmane.comp.emulators.xen.devel
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>	<jfud2p$h6$1@dough.gmane.org>	<alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
	<4F268632.8040801@redhat.com> <4F26EF47.9090108@codemonkey.ws>
In-Reply-To: <4F26EF47.9090108@codemonkey.ws>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/30/2012 08:28 PM, Anthony Liguori wrote:
>>
>> I see. It shouldn't surprise you that I completely disagree with
>> Anthony on this. :)
>
> Give me some credit at least...
>
> The original patches didn't disable the RTC, it introduced a
> half-neutered Xen specific RTC.

Ah. :)

> My original suggestion (which I still think is the best approach) is to
> change the RTC emulation to not use a second timer at all.

Yes, that would be really the best approach.  I tried and it's pretty 
hard, but we can give it a second try.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 07:31:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 07:31:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs8AU-0007Hf-Fo; Tue, 31 Jan 2012 07:30:18 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <paolo.bonzini@gmail.com>) id 1Rs8AT-0007Ha-8L
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 07:30:17 +0000
X-Env-Sender: paolo.bonzini@gmail.com
X-Msg-Ref: server-4.tower-21.messagelabs.com!1327995009!3798215!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15065 invoked from network); 31 Jan 2012 07:30:10 -0000
Received: from mail-ee0-f43.google.com (HELO mail-ee0-f43.google.com)
	(74.125.83.43)
	by server-4.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 07:30:10 -0000
Received: by eekb45 with SMTP id b45so33360693eek.30
	for <xen-devel@lists.xensource.com>;
	Mon, 30 Jan 2012 23:30:09 -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:newsgroups:to
	:cc:subject:references:in-reply-to:content-type
	:content-transfer-encoding;
	bh=aPBr0uC1OxyNrtGlOov1MzSvApWgXO1U82h+0u3Druo=;
	b=eSD7OXQSkbm6BxrBzLMcATYdGBya2ob8RvaLxmcu2GyNgT4CuCIVFmWbGQPpmZqvRa
	JFKlaSZI7DAPmw+91/EWpdYZO/RX+koGUdRBCYgWnHmGGX1i5SFudmUd5LRY7zqLsMUd
	En2mk72m3fViaRANJOaTvYCtxTsdL2KZ30iKc=
Received: by 10.14.130.208 with SMTP id k56mr949818eei.123.1327995009309;
	Mon, 30 Jan 2012 23:30:09 -0800 (PST)
Received: from yakj.usersys.redhat.com (93-34-182-16.ip50.fastwebnet.it.
	[93.34.182.16])
	by mx.google.com with ESMTPS id e12sm82960662eea.5.2012.01.30.23.30.08
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 30 Jan 2012 23:30:08 -0800 (PST)
Message-ID: <4F27987E.5010707@redhat.com>
Date: Tue, 31 Jan 2012 08:30:06 +0100
From: Paolo Bonzini <pbonzini@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
Newsgroups: gmane.comp.emulators.qemu,gmane.comp.emulators.xen.devel
To: Anthony Liguori <anthony@codemonkey.ws>
References: <alpine.DEB.2.00.1201271211400.3196@kaball-desktop>	<1327667215-5411-2-git-send-email-stefano.stabellini@eu.citrix.com>	<jfud2p$h6$1@dough.gmane.org>	<alpine.DEB.2.00.1201301147350.3196@kaball-desktop>
	<4F268632.8040801@redhat.com> <4F26EF47.9090108@codemonkey.ws>
In-Reply-To: <4F26EF47.9090108@codemonkey.ws>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v2 2/5] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/30/2012 08:28 PM, Anthony Liguori wrote:
>>
>> I see. It shouldn't surprise you that I completely disagree with
>> Anthony on this. :)
>
> Give me some credit at least...
>
> The original patches didn't disable the RTC, it introduced a
> half-neutered Xen specific RTC.

Ah. :)

> My original suggestion (which I still think is the best approach) is to
> change the RTC emulation to not use a second timer at all.

Yes, that would be really the best approach.  I tried and it's pretty 
hard, but we can give it a second try.

Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 07:51:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 07:51:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs8UM-0007VF-H8; Tue, 31 Jan 2012 07:50:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1Rs8UL-0007VA-4Q
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 07:50:49 +0000
Received: from [85.158.138.51:42769] by server-11.bemta-3.messagelabs.com id
	C9/25-26051-85D972F4; Tue, 31 Jan 2012 07:50:48 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327996247!11329083!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNjAyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9271 invoked from network); 31 Jan 2012 07:50:47 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 07:50:47 -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=mPmAzkJBs2MuPxA+qr+nYwz4CO2KzkEiNAVIjjdZdrEOFv796vcwQjaw
	ca12H09ah4kIGIQHUNw7IYNuG2+XZafBDLPpArEOYH74JDgOlS9MsFnPC
	A4D0/RQtfLyrlBlC4TIH7PcvJxWeIvtMS8gz2bifhcnLUodV6qYGY0ziz
	Hl2Vz5J75C/JGIg6+1S62WpFC1I/W0ZgE7PM6lpl+rRP9N68A62oZrIRp
	q+4vEqz/E9IUoGBjB/Y4pwwigzv8O;
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=1327996248; x=1359532248;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=7cpa0cXhBqAOR53NTgRgOUiC+8pxCtPBt/LQvFAnpos=;
	b=ABNlt3YFI40aps5GSbfWZ+nw7U9JWEYK4706ggvRmfkGsoDWZCd8Vnpc
	pUev6WVAEuaCTO3UGir7bxS03UhnzEvcYSk7npWubuqq6ew9SvAZ5z90k
	o0jXgMnjFd6vLOxDLeXqUwWlooAL11DMwwy9ackFgVK//H2k8f7L1p+6u
	0mAkZw3rA7/ZpPSXLqBifRsRaz4NhXItESppTTVfd6e7Qeg6Nq5+1fdJC
	2mkJWyTopYqszmEShU8Z5K0xXofb4;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,592,1320620400"; d="scan'208";a="100170556"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 31 Jan 2012 08:50:47 +0100
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="127744330"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 31 Jan 2012 08:50:46 +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 BBB9776C046;
	Tue, 31 Jan 2012 08:50:46 +0100 (CET)
Message-ID: <4F279D56.3030303@ts.fujitsu.com>
Date: Tue, 31 Jan 2012 08:50:46 +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: Jan Beulich <JBeulich@suse.com>
References: <4F268C03.5000003@ts.fujitsu.com>
	<4F26D2A8020000780006FF2F@nat28.tlf.novell.com>
In-Reply-To: <4F26D2A8020000780006FF2F@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/30/2012 05:26 PM, Jan Beulich wrote:
>>>> On 30.01.12 at 13:24, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>> To avoid this stall I tried to start a little daemon on the target machine
>> and watch for a new BS2000 domain to show up due to live migration. I wanted
>> to map the domain memory as soon as the needed mapping information located
>> in a fixed guest mfn was transferred. Discovery of the new domain works as
>> expected, but I'm not capable doing any memory mapping until the restore of
>> the domain is finished. The mapping ioctl using IOCTL_PRIVCMD_MMAP returns
>> EINVAL until xc_restore is finished (more or less).
>>
>> Why can xc_restore do the mapping while I can't? I know xc_restore is using
>> IOCTL_PRIVCMD_MMAPBATCH_V2, but I can't see a difference which should matter
>> between those two, as both are using the same hypercall to update the dom0
>> page tables.
> I cannot immediately think of a reason (and indeed the difference
> between the two is only how errors get handled), so I wonder
> whether you checked where the - pretty generic - -EINVAL is
> coming from. You also didn't mention whether any hypervisor log
> entries are associated with you failed attempts.

I'll start to add some logging to the hypervisor today.

No hypervisor logs were produced in my tests, despite of setting

debug=yes loglvl=all guest_loglvl=all

as boot parameters.

I've made an additional test using xm save/xm restore to see if the same
problem shows up. It does NOT. Mapping succeeds at once while restoring
memory is still running. I always thought xm restore and live migration on
the target machine are more or less the same. This seems not to be true.


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 Jan 31 07:51:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 07:51:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs8UM-0007VF-H8; Tue, 31 Jan 2012 07:50:50 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1Rs8UL-0007VA-4Q
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 07:50:49 +0000
Received: from [85.158.138.51:42769] by server-11.bemta-3.messagelabs.com id
	C9/25-26051-85D972F4; Tue, 31 Jan 2012 07:50:48 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1327996247!11329083!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNjAyNw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 9271 invoked from network); 31 Jan 2012 07:50:47 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-2.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 07:50:47 -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=mPmAzkJBs2MuPxA+qr+nYwz4CO2KzkEiNAVIjjdZdrEOFv796vcwQjaw
	ca12H09ah4kIGIQHUNw7IYNuG2+XZafBDLPpArEOYH74JDgOlS9MsFnPC
	A4D0/RQtfLyrlBlC4TIH7PcvJxWeIvtMS8gz2bifhcnLUodV6qYGY0ziz
	Hl2Vz5J75C/JGIg6+1S62WpFC1I/W0ZgE7PM6lpl+rRP9N68A62oZrIRp
	q+4vEqz/E9IUoGBjB/Y4pwwigzv8O;
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=1327996248; x=1359532248;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=7cpa0cXhBqAOR53NTgRgOUiC+8pxCtPBt/LQvFAnpos=;
	b=ABNlt3YFI40aps5GSbfWZ+nw7U9JWEYK4706ggvRmfkGsoDWZCd8Vnpc
	pUev6WVAEuaCTO3UGir7bxS03UhnzEvcYSk7npWubuqq6ew9SvAZ5z90k
	o0jXgMnjFd6vLOxDLeXqUwWlooAL11DMwwy9ackFgVK//H2k8f7L1p+6u
	0mAkZw3rA7/ZpPSXLqBifRsRaz4NhXItESppTTVfd6e7Qeg6Nq5+1fdJC
	2mkJWyTopYqszmEShU8Z5K0xXofb4;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,592,1320620400"; d="scan'208";a="100170556"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate10u.abg.fsc.net with ESMTP; 31 Jan 2012 08:50:47 +0100
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="127744330"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 31 Jan 2012 08:50:46 +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 BBB9776C046;
	Tue, 31 Jan 2012 08:50:46 +0100 (CET)
Message-ID: <4F279D56.3030303@ts.fujitsu.com>
Date: Tue, 31 Jan 2012 08:50:46 +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: Jan Beulich <JBeulich@suse.com>
References: <4F268C03.5000003@ts.fujitsu.com>
	<4F26D2A8020000780006FF2F@nat28.tlf.novell.com>
In-Reply-To: <4F26D2A8020000780006FF2F@nat28.tlf.novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/30/2012 05:26 PM, Jan Beulich wrote:
>>>> On 30.01.12 at 13:24, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>> To avoid this stall I tried to start a little daemon on the target machine
>> and watch for a new BS2000 domain to show up due to live migration. I wanted
>> to map the domain memory as soon as the needed mapping information located
>> in a fixed guest mfn was transferred. Discovery of the new domain works as
>> expected, but I'm not capable doing any memory mapping until the restore of
>> the domain is finished. The mapping ioctl using IOCTL_PRIVCMD_MMAP returns
>> EINVAL until xc_restore is finished (more or less).
>>
>> Why can xc_restore do the mapping while I can't? I know xc_restore is using
>> IOCTL_PRIVCMD_MMAPBATCH_V2, but I can't see a difference which should matter
>> between those two, as both are using the same hypercall to update the dom0
>> page tables.
> I cannot immediately think of a reason (and indeed the difference
> between the two is only how errors get handled), so I wonder
> whether you checked where the - pretty generic - -EINVAL is
> coming from. You also didn't mention whether any hypervisor log
> entries are associated with you failed attempts.

I'll start to add some logging to the hypervisor today.

No hypervisor logs were produced in my tests, despite of setting

debug=yes loglvl=all guest_loglvl=all

as boot parameters.

I've made an additional test using xm save/xm restore to see if the same
problem shows up. It does NOT. Mapping succeeds at once while restoring
memory is still running. I always thought xm restore and live migration on
the target machine are more or less the same. This seems not to be true.


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 Jan 31 08:43:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 08:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs9IO-0008D4-7T; Tue, 31 Jan 2012 08:42:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rs9IN-0008Cz-1e
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 08:42:31 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327999344!13268265!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1Njc5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31595 invoked from network); 31 Jan 2012 08:42:25 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 08:42:25 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=pcz0l/r5Fe8M3SQg1yZVcuTbQ9P7TDDRTgwTNMqYjOvNe17zRlToxVK4
	UfBGb+n2T2o5UiS+yQ7wKJfNrkFto71aT+uw5ehAUc9ANpJY7BwMcaeam
	aLkWtmpwz8fT/IGo4hx4iiSL8jv7Ch7VfNl9LMOJLr2khaND55RdNde+w
	2Rom+l+pUNlmvZ9CTHr9U5rpEsTN5/aiYiZJUd5FrHzaN2y0L9UbpDose
	Ke8woiRbWJqhU2QTAR7IdNVotVLwG;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1327999345; x=1359535345;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=xtG0AtdFP8RpB/BYNo7/L+bWV62mQmX4WufQuxaUdk8=;
	b=th3cwSvp/waYCtBWDr13PjlJPiUiPJG7ww5EquN54r+ky9iDiovjeAtL
	bFqA/0IXG8jMT/0nWxMZ6TwUg8ZLUxLSYjc+eBDKIfjNc0bhUHX8TxiZa
	XRXqVqlkhX+eaBrBU3qPTgkgTWUEBBidoHmTmRokWf+Z+0EcDyHEr7hNn
	e/auM1vblQuyuSNDUBiF80MqnT6dYU0sQ8R42CsvSAehVJAtgeC3aBt82
	GfRTbfMbKm7DzNfUDitbZFkunTh51;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,594,1320620400"; d="scan'208";a="84903343"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 31 Jan 2012 09:42:24 +0100
X-IronPort-AV: E=Sophos;i="4.71,593,1320620400"; d="scan'208";a="128026127"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 31 Jan 2012 09:42:24 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 36DA276C09D
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:42:24 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 31 Jan 2012 09:42:23 +0100
Message-ID: <2717113.UZgetSD5rT@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] msr: Use defines for bits of
	MSR_IA32_DEBUGCTLMSR instead of numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864

Use defines for bits of MSR_IA32_DEBUGCTLMSR instead of numbers.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r e2722b24dc09 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 31 09:40:31 2012 +0100
@@ -1944,11 +1944,12 @@ static int vmx_msr_write_intercept(unsig
         break;
     case MSR_IA32_DEBUGCTLMSR: {
         int i, rc = 0;
-
-        if ( !msr_content || (msr_content & ~3) )
+        uint64_t allowed = MSR_IA32_DEBUGCTLMSR_LBR | MSR_IA32_DEBUGCTLMSR_BTF;
+
+        if ( !msr_content || (msr_content & ~allowed) )
             break;
 
-        if ( msr_content & 1 )
+        if ( msr_content & MSR_IA32_DEBUGCTLMSR_LBR )
         {
             const struct lbr_info *lbr = last_branch_msr_get();
             if ( lbr == NULL )
diff -r e2722b24dc09 xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/msr-index.h	Tue Jan 31 09:40:31 2012 +0100
@@ -64,12 +64,18 @@
 #define MSR_MTRRfix4K_F8000		0x0000026f
 #define MSR_MTRRdefType			0x000002ff
 
+/* MSR_IA32_DEBUGCTLMSR bits: */
+#define _IA32_DEBUGCTLMSR_LBR		0 /* Last Branch Record */
+#define _IA32_DEBUGCTLMSR_BTF		1 /* Single Step on Branches */
+#define MSR_IA32_DEBUGCTLMSR_LBR	(1<<_IA32_DEBUGCTLMSR_LBR)
+#define MSR_IA32_DEBUGCTLMSR_BTF	(1<<_IA32_DEBUGCTLMSR_BTF)
+
 #define MSR_IA32_DEBUGCTLMSR		0x000001d9
 #define MSR_IA32_LASTBRANCHFROMIP	0x000001db
 #define MSR_IA32_LASTBRANCHTOIP		0x000001dc
 #define MSR_IA32_LASTINTFROMIP		0x000001dd
 #define MSR_IA32_LASTINTTOIP		0x000001de
- 
+
 #define MSR_IA32_MTRR_PHYSBASE0     0x00000200
 #define MSR_IA32_MTRR_PHYSMASK0     0x00000201
 #define MSR_IA32_MTRR_PHYSBASE1     0x00000202

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 08:43:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 08:43:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs9IO-0008D4-7T; Tue, 31 Jan 2012 08:42:32 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1Rs9IN-0008Cz-1e
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 08:42:31 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1327999344!13268265!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1Njc5OQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31595 invoked from network); 31 Jan 2012 08:42:25 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-12.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 08:42:25 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=pcz0l/r5Fe8M3SQg1yZVcuTbQ9P7TDDRTgwTNMqYjOvNe17zRlToxVK4
	UfBGb+n2T2o5UiS+yQ7wKJfNrkFto71aT+uw5ehAUc9ANpJY7BwMcaeam
	aLkWtmpwz8fT/IGo4hx4iiSL8jv7Ch7VfNl9LMOJLr2khaND55RdNde+w
	2Rom+l+pUNlmvZ9CTHr9U5rpEsTN5/aiYiZJUd5FrHzaN2y0L9UbpDose
	Ke8woiRbWJqhU2QTAR7IdNVotVLwG;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1327999345; x=1359535345;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=xtG0AtdFP8RpB/BYNo7/L+bWV62mQmX4WufQuxaUdk8=;
	b=th3cwSvp/waYCtBWDr13PjlJPiUiPJG7ww5EquN54r+ky9iDiovjeAtL
	bFqA/0IXG8jMT/0nWxMZ6TwUg8ZLUxLSYjc+eBDKIfjNc0bhUHX8TxiZa
	XRXqVqlkhX+eaBrBU3qPTgkgTWUEBBidoHmTmRokWf+Z+0EcDyHEr7hNn
	e/auM1vblQuyuSNDUBiF80MqnT6dYU0sQ8R42CsvSAehVJAtgeC3aBt82
	GfRTbfMbKm7DzNfUDitbZFkunTh51;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,594,1320620400"; d="scan'208";a="84903343"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 31 Jan 2012 09:42:24 +0100
X-IronPort-AV: E=Sophos;i="4.71,593,1320620400"; d="scan'208";a="128026127"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 31 Jan 2012 09:42:24 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 36DA276C09D
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:42:24 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Tue, 31 Jan 2012 09:42:23 +0100
Message-ID: <2717113.UZgetSD5rT@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.0-1.2-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH] msr: Use defines for bits of
	MSR_IA32_DEBUGCTLMSR instead of numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864

Use defines for bits of MSR_IA32_DEBUGCTLMSR instead of numbers.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r e2722b24dc09 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 31 09:40:31 2012 +0100
@@ -1944,11 +1944,12 @@ static int vmx_msr_write_intercept(unsig
         break;
     case MSR_IA32_DEBUGCTLMSR: {
         int i, rc = 0;
-
-        if ( !msr_content || (msr_content & ~3) )
+        uint64_t allowed = MSR_IA32_DEBUGCTLMSR_LBR | MSR_IA32_DEBUGCTLMSR_BTF;
+
+        if ( !msr_content || (msr_content & ~allowed) )
             break;
 
-        if ( msr_content & 1 )
+        if ( msr_content & MSR_IA32_DEBUGCTLMSR_LBR )
         {
             const struct lbr_info *lbr = last_branch_msr_get();
             if ( lbr == NULL )
diff -r e2722b24dc09 xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/msr-index.h	Tue Jan 31 09:40:31 2012 +0100
@@ -64,12 +64,18 @@
 #define MSR_MTRRfix4K_F8000		0x0000026f
 #define MSR_MTRRdefType			0x000002ff
 
+/* MSR_IA32_DEBUGCTLMSR bits: */
+#define _IA32_DEBUGCTLMSR_LBR		0 /* Last Branch Record */
+#define _IA32_DEBUGCTLMSR_BTF		1 /* Single Step on Branches */
+#define MSR_IA32_DEBUGCTLMSR_LBR	(1<<_IA32_DEBUGCTLMSR_LBR)
+#define MSR_IA32_DEBUGCTLMSR_BTF	(1<<_IA32_DEBUGCTLMSR_BTF)
+
 #define MSR_IA32_DEBUGCTLMSR		0x000001d9
 #define MSR_IA32_LASTBRANCHFROMIP	0x000001db
 #define MSR_IA32_LASTBRANCHTOIP		0x000001dc
 #define MSR_IA32_LASTINTFROMIP		0x000001dd
 #define MSR_IA32_LASTINTTOIP		0x000001de
- 
+
 #define MSR_IA32_MTRR_PHYSBASE0     0x00000200
 #define MSR_IA32_MTRR_PHYSMASK0     0x00000201
 #define MSR_IA32_MTRR_PHYSBASE1     0x00000202

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:02:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs9bI-0008Rm-BQ; Tue, 31 Jan 2012 09:02: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 1Rs9bH-0008Rh-7d
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:02:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328000516!11878624!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23336 invoked from network); 31 Jan 2012 09:01:56 -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; 31 Jan 2012 09:01:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 09:03:31 +0000
Message-Id: <4F27BC1002000078000700D3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 09:01:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
In-Reply-To: <1327943436.5553.39.camel@leeds.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
>> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
>> > -int xenvif_map_frontend_rings(struct xenvif *vif,
>> > -			      grant_ref_t tx_ring_ref,
>> > -			      grant_ref_t rx_ring_ref)
>> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
>> > +			      int domid,
>> > +			      unsigned long ring_ref[],
>> > +			      unsigned int  ring_ref_count)
>> >  {
>> > -	void *addr;
>> > -	struct xen_netif_tx_sring *txs;
>> > -	struct xen_netif_rx_sring *rxs;
>> > -
>> > -	int err = -ENOMEM;
>> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
>> > +	unsigned int i;
>> > +	int err = 0;
>> >  
>> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
>> > -				     tx_ring_ref, &addr);
>> 
>> Any reason why you don't just extend this function (in a prerequisite
>> patch) rather than open coding a common utility function (twice) here,
>> so that other backends (blkback!) can benefit later as well.
>> 
>> Jan
>> 
> 
> I'm mainly focusing on netback stuffs, so the code is slightly coupled
> with netback -- NETBK_MAX_RING_PAGES.
> 
> To extend xenbus_map_ring_valloc and make more generic, it requires
> setting a global maximum page number limits on rings, I think it will
> require further investigation and code refactor -- which I have no time
> to attend to at the moment. :-/

Why? You can simply pass in the number of pages, there's no need
for a global maximum.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:02:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:02:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs9bI-0008Rm-BQ; Tue, 31 Jan 2012 09:02: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 1Rs9bH-0008Rh-7d
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:02:03 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328000516!11878624!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23336 invoked from network); 31 Jan 2012 09:01:56 -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; 31 Jan 2012 09:01:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 09:03:31 +0000
Message-Id: <4F27BC1002000078000700D3@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 09:01:52 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
In-Reply-To: <1327943436.5553.39.camel@leeds.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
>> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
>> > -int xenvif_map_frontend_rings(struct xenvif *vif,
>> > -			      grant_ref_t tx_ring_ref,
>> > -			      grant_ref_t rx_ring_ref)
>> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
>> > +			      int domid,
>> > +			      unsigned long ring_ref[],
>> > +			      unsigned int  ring_ref_count)
>> >  {
>> > -	void *addr;
>> > -	struct xen_netif_tx_sring *txs;
>> > -	struct xen_netif_rx_sring *rxs;
>> > -
>> > -	int err = -ENOMEM;
>> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
>> > +	unsigned int i;
>> > +	int err = 0;
>> >  
>> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
>> > -				     tx_ring_ref, &addr);
>> 
>> Any reason why you don't just extend this function (in a prerequisite
>> patch) rather than open coding a common utility function (twice) here,
>> so that other backends (blkback!) can benefit later as well.
>> 
>> Jan
>> 
> 
> I'm mainly focusing on netback stuffs, so the code is slightly coupled
> with netback -- NETBK_MAX_RING_PAGES.
> 
> To extend xenbus_map_ring_valloc and make more generic, it requires
> setting a global maximum page number limits on rings, I think it will
> require further investigation and code refactor -- which I have no time
> to attend to at the moment. :-/

Why? You can simply pass in the number of pages, there's no need
for a global maximum.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:13:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs9lJ-0000AI-FK; Tue, 31 Jan 2012 09:12: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 1Rs9lI-0000AD-Ft
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:12:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328001100!58110947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30676 invoked from network); 31 Jan 2012 09:11:41 -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;
	31 Jan 2012 09:11:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10381912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:12: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, 31 Jan 2012 09:12:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 31 Jan 2012 09:12:22 +0000
In-Reply-To: <20120130213926.GB16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328001142.26983.289.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 21:39 +0000, Konrad Rzeszutek Wilk wrote:

[...snip... please do consider trimming unnecessary quotes]

> > @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >               goto fail;
> >       }
> >
> > -     txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> > +     err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> > +                        "max-tx-ring-page-order", "%u",
> > +                        &max_tx_ring_page_order);
> > +     if (err < 0) {
> > +             info->tx_ring_page_order = 0;
> > +             dev_info(&dev->dev, "single tx ring\n");
> > +     } else {
> > +             info->tx_ring_page_order = max_tx_ring_page_order;
> > +             dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> > +                      max_tx_ring_page_order);
> > +     }
> > +     info->tx_ring_pages = (1U << info->tx_ring_page_order);
> > +
> > +     txs = (struct xen_netif_tx_sring *)
> > +             dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > +                                &info->tx_ring_dma_handle,
> > +                                __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> 
> Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
> But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
> clue whether you are OK getting pages under 4GB or above it (so 64-bit support).

Does this allocation even need to be physically contiguous? I'd have
thought that virtually contiguous would be sufficient, and even then
only as a convenience at either end to avoid the need for more
complicated ring macros.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:13:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:13:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1Rs9lJ-0000AI-FK; Tue, 31 Jan 2012 09:12: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 1Rs9lI-0000AD-Ft
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:12:24 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328001100!58110947!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30676 invoked from network); 31 Jan 2012 09:11:41 -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;
	31 Jan 2012 09:11:41 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10381912"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:12: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, 31 Jan 2012 09:12:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 31 Jan 2012 09:12:22 +0000
In-Reply-To: <20120130213926.GB16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328001142.26983.289.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>,
	"Wei Liu \(Intern\)" <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 21:39 +0000, Konrad Rzeszutek Wilk wrote:

[...snip... please do consider trimming unnecessary quotes]

> > @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >               goto fail;
> >       }
> >
> > -     txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> > +     err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> > +                        "max-tx-ring-page-order", "%u",
> > +                        &max_tx_ring_page_order);
> > +     if (err < 0) {
> > +             info->tx_ring_page_order = 0;
> > +             dev_info(&dev->dev, "single tx ring\n");
> > +     } else {
> > +             info->tx_ring_page_order = max_tx_ring_page_order;
> > +             dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> > +                      max_tx_ring_page_order);
> > +     }
> > +     info->tx_ring_pages = (1U << info->tx_ring_page_order);
> > +
> > +     txs = (struct xen_netif_tx_sring *)
> > +             dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > +                                &info->tx_ring_dma_handle,
> > +                                __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> 
> Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
> But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
> clue whether you are OK getting pages under 4GB or above it (so 64-bit support).

Does this allocation even need to be physically contiguous? I'd have
thought that virtually contiguous would be sufficient, and even then
only as a convenience at either end to avoid the need for more
complicated ring macros.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:33:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:33:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsA5Q-0000Np-EH; Tue, 31 Jan 2012 09:33:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RsA5O-0000NY-LK
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:33:10 +0000
Received: from [85.158.138.51:25760] by server-9.bemta-3.messagelabs.com id
	1C/5A-31168-555B72F4; Tue, 31 Jan 2012 09:33:09 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328002388!9512146!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6171 invoked from network); 31 Jan 2012 09:33:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	31 Jan 2012 09:33:08 -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 q0V9X7UU008779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 04:33:07 -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 q0V9X5FV011337; Tue, 31 Jan 2012 04:33:06 -0500
Message-ID: <4F27B5AD.9050709@redhat.com>
Date: Tue, 31 Jan 2012 10:34:37 +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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	qemu-devel@nongnu.org
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	Petr Matousek <pmatouse@redhat.com>
Subject: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

in the qemu-xen-unstable tree 
(git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function 
[i386-dm/helper2.c] makes the process exit if the operand size is wrong. 
Blame: 6040eea5 ("More files imported from xen-unstable 
17192:59b8768d0d0d").

In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function 
[xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c 
("xen: Initialize event channels and io rings").

Is it justified to kill the emulator when this happens (eg. memory 
mapped IO with 64-bit operand)? What would happen on real hardware? If 
it's "undefined", wouldn't it be "better" (for some definition of 
"better") to return a constant?

Thank you,
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:33:39 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:33:39 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsA5Q-0000Np-EH; Tue, 31 Jan 2012 09:33:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RsA5O-0000NY-LK
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:33:10 +0000
Received: from [85.158.138.51:25760] by server-9.bemta-3.messagelabs.com id
	1C/5A-31168-555B72F4; Tue, 31 Jan 2012 09:33:09 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-15.tower-174.messagelabs.com!1328002388!9512146!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6171 invoked from network); 31 Jan 2012 09:33:08 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-15.tower-174.messagelabs.com with SMTP;
	31 Jan 2012 09:33:08 -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 q0V9X7UU008779
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 04:33:07 -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 q0V9X5FV011337; Tue, 31 Jan 2012 04:33:06 -0500
Message-ID: <4F27B5AD.9050709@redhat.com>
Date: Tue, 31 Jan 2012 10:34:37 +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: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	qemu-devel@nongnu.org
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	Petr Matousek <pmatouse@redhat.com>
Subject: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi,

in the qemu-xen-unstable tree 
(git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function 
[i386-dm/helper2.c] makes the process exit if the operand size is wrong. 
Blame: 6040eea5 ("More files imported from xen-unstable 
17192:59b8768d0d0d").

In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function 
[xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c 
("xen: Initialize event channels and io rings").

Is it justified to kill the emulator when this happens (eg. memory 
mapped IO with 64-bit operand)? What would happen on real hardware? If 
it's "undefined", wouldn't it be "better" (for some definition of 
"better") to return a constant?

Thank you,
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:33:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09: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 1RsA5l-0000Oy-SV; Tue, 31 Jan 2012 09:33:33 +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 1RsA5j-0000OZ-L8
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:33:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328002405!3354331!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8003 invoked from network); 31 Jan 2012 09:33:25 -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; 31 Jan 2012 09:33:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsA5K-000Em1-Iz; Tue, 31 Jan 2012 09:33:06 +0000
Date: Tue, 31 Jan 2012 09:33:05 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120131093305.GA25307@ocelot.phlegethon.org>
References: <17e25c8b6045cd7246e4.1327925241@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <17e25c8b6045cd7246e4.1327925241@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: unify return value in nominate
	and 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

At 13:07 +0100 on 30 Jan (1327928841), Olaf Hering wrote:
> xenpaging: unify return value in nominate and evict
> 
> Let p2m_mem_paging_nominate and p2m_mem_paging_evict return just one
> error number. EINVAL is not very helpful in case of nominate, it can
> happen if the pager tries to nominate a ballooned page. In this case the
> gfn is not backed by a mfn, the pager can not know that.  Similar with
> evict, anything can happen between nominate and evict.
> 
> This change helps the pager to decide if the returned error is from the
> function itself, or if it happend earlier. In the latter case, it is
> most likely fatal and should be handled as such.
> nominate and evict return EBUSY, which is supposed to mean
> "pager request reached target function, and failed."

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 Jan 31 09:33:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09: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 1RsA5l-0000Oy-SV; Tue, 31 Jan 2012 09:33:33 +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 1RsA5j-0000OZ-L8
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:33:31 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328002405!3354331!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8003 invoked from network); 31 Jan 2012 09:33:25 -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; 31 Jan 2012 09:33:25 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsA5K-000Em1-Iz; Tue, 31 Jan 2012 09:33:06 +0000
Date: Tue, 31 Jan 2012 09:33:05 +0000
From: Tim Deegan <tim@xen.org>
To: Olaf Hering <olaf@aepfle.de>
Message-ID: <20120131093305.GA25307@ocelot.phlegethon.org>
References: <17e25c8b6045cd7246e4.1327925241@probook.site>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <17e25c8b6045cd7246e4.1327925241@probook.site>
User-Agent: Mutt/1.4.2.1i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] xenpaging: unify return value in nominate
	and 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

At 13:07 +0100 on 30 Jan (1327928841), Olaf Hering wrote:
> xenpaging: unify return value in nominate and evict
> 
> Let p2m_mem_paging_nominate and p2m_mem_paging_evict return just one
> error number. EINVAL is not very helpful in case of nominate, it can
> happen if the pager tries to nominate a ballooned page. In this case the
> gfn is not backed by a mfn, the pager can not know that.  Similar with
> evict, anything can happen between nominate and evict.
> 
> This change helps the pager to decide if the returned error is from the
> function itself, or if it happend earlier. In the latter case, it is
> most likely fatal and should be handled as such.
> nominate and evict return EBUSY, which is supposed to mean
> "pager request reached target function, and failed."

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 Jan 31 09:47:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09: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 1RsAId-0000jr-AN; Tue, 31 Jan 2012 09:46:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAIb-0000jj-U5
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:46:50 +0000
Received: from [85.158.138.51:22098] by server-6.bemta-3.messagelabs.com id
	49/75-31032-888B72F4; Tue, 31 Jan 2012 09:46:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328003208!11303803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15070 invoked from network); 31 Jan 2012 09:46:48 -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;
	31 Jan 2012 09:46:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10382901"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:46:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 09:46:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:46:47 +0000
In-Reply-To: <20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328003207.26983.311.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send
 commands to traditional	qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971493 28800
> # Node ID 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> libxl: helper function to send commands to traditional qemu
> 
> Introduce a helper function to send commands to traditional
> qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
> libxl__domain_save_device_model and libxl_domain_unpause have
> been refactored to use this function.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Every caller to libxl__qemu_traditional_cmd seems to be followed with a
call to libxl__wait_for_device_model -- might be worth pushing that down
into the function?

> 
> diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 30 16:58:13 2012 -0800
> @@ -517,7 +517,7 @@ int libxl_domain_unpause(libxl_ctx *ctx,
>          path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
>          state = libxl__xs_read(gc, XBT_NULL, path);
>          if (state != NULL && !strcmp(state, "paused")) {
> -            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
> +            libxl__qemu_traditional_cmd(gc, domid, "continue");
>              libxl__wait_for_device_model(gc, domid, "running",
>                                           NULL, NULL, NULL);
>          }
> diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:13 2012 -0800
> @@ -349,6 +349,15 @@ out:
>      return rc;
>  }
>  
> +int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
> +                                const char *cmd)
> +{
> +    char *path = NULL;
> +    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> +                          domid);
> +    return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
> +}
> +
>  int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
>                                   libxl_domain_build_info *info,
>                                   libxl__domain_build_state *state,
> @@ -631,12 +640,9 @@ int libxl__domain_save_device_model(libx
>  
>      switch (libxl__device_model_version_running(gc, domid)) {
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> -        char *path = NULL;
>          LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
>                     "Saving device model state to %s", filename);
> -        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> -                              domid);
> -        libxl__xs_write(gc, XBT_NULL, path, "save");
> +        libxl__qemu_traditional_cmd(gc, domid, "save");
>          libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
>          break;
>      }
> diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl_internal.h	Mon Jan 30 16:58:13 2012 -0800
> @@ -263,6 +263,8 @@ _hidden int libxl__build_hvm(libxl__gc *
>                libxl_device_model_info *dm_info,
>                libxl__domain_build_state *state);
>  
> +_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
> +                                        const char *cmd);
>  _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>                                   const char *old_name, const char *new_name,
>                                   xs_transaction_t trans);
> diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl_pci.c	Mon Jan 30 16:58:13 2012 -0800
> @@ -602,9 +602,8 @@ static int qemu_pci_add_xenstore(libxl__
>          libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
>                          pcidev->bus, pcidev->dev, pcidev->func);
>      }
> -    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> -                          domid);
> -    xs_write(ctx->xsh, XBT_NULL, path, "pci-ins", strlen("pci-ins"));
> +
> +    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
>      rc = libxl__wait_for_device_model(gc, domid, NULL, NULL,
>                                        pci_ins_check, state);
>      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
> @@ -857,12 +856,11 @@ static int qemu_pci_remove_xenstore(libx
>      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid);
>      libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
>                      pcidev->bus, pcidev->dev, pcidev->func);
> -    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid);
>  
>      /* Remove all functions at once atomically by only signalling
>       * device-model for function 0 */
>      if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
> -        xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", strlen("pci-rem"));
> +        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
>          if (libxl__wait_for_device_model(gc, domid, "pci-removed",
>                                           NULL, NULL, NULL) < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model didn't respond in time");



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:47:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09: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 1RsAId-0000jr-AN; Tue, 31 Jan 2012 09:46:51 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAIb-0000jj-U5
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:46:50 +0000
Received: from [85.158.138.51:22098] by server-6.bemta-3.messagelabs.com id
	49/75-31032-888B72F4; Tue, 31 Jan 2012 09:46:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328003208!11303803!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15070 invoked from network); 31 Jan 2012 09:46:48 -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;
	31 Jan 2012 09:46:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10382901"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:46:47 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 09:46:47 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:46:47 +0000
In-Reply-To: <20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328003207.26983.311.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send
 commands to traditional	qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971493 28800
> # Node ID 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
> # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> libxl: helper function to send commands to traditional qemu
> 
> Introduce a helper function to send commands to traditional
> qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
> libxl__domain_save_device_model and libxl_domain_unpause have
> been refactored to use this function.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Every caller to libxl__qemu_traditional_cmd seems to be followed with a
call to libxl__wait_for_device_model -- might be worth pushing that down
into the function?

> 
> diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl.c	Mon Jan 30 16:58:13 2012 -0800
> @@ -517,7 +517,7 @@ int libxl_domain_unpause(libxl_ctx *ctx,
>          path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/state", domid);
>          state = libxl__xs_read(gc, XBT_NULL, path);
>          if (state != NULL && !strcmp(state, "paused")) {
> -            libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid), "continue");
> +            libxl__qemu_traditional_cmd(gc, domid, "continue");
>              libxl__wait_for_device_model(gc, domid, "running",
>                                           NULL, NULL, NULL);
>          }
> diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:13 2012 -0800
> @@ -349,6 +349,15 @@ out:
>      return rc;
>  }
>  
> +int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
> +                                const char *cmd)
> +{
> +    char *path = NULL;
> +    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> +                          domid);
> +    return libxl__xs_write(gc, XBT_NULL, path, "%s", cmd);
> +}
> +
>  int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
>                                   libxl_domain_build_info *info,
>                                   libxl__domain_build_state *state,
> @@ -631,12 +640,9 @@ int libxl__domain_save_device_model(libx
>  
>      switch (libxl__device_model_version_running(gc, domid)) {
>      case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> -        char *path = NULL;
>          LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
>                     "Saving device model state to %s", filename);
> -        path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> -                              domid);
> -        libxl__xs_write(gc, XBT_NULL, path, "save");
> +        libxl__qemu_traditional_cmd(gc, domid, "save");
>          libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
>          break;
>      }
> diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_internal.h
> --- a/tools/libxl/libxl_internal.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl_internal.h	Mon Jan 30 16:58:13 2012 -0800
> @@ -263,6 +263,8 @@ _hidden int libxl__build_hvm(libxl__gc *
>                libxl_device_model_info *dm_info,
>                libxl__domain_build_state *state);
>  
> +_hidden int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t domid,
> +                                        const char *cmd);
>  _hidden int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
>                                   const char *old_name, const char *new_name,
>                                   xs_transaction_t trans);
> diff -r e2722b24dc09 -r 20bbc4a754a7 tools/libxl/libxl_pci.c
> --- a/tools/libxl/libxl_pci.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/tools/libxl/libxl_pci.c	Mon Jan 30 16:58:13 2012 -0800
> @@ -602,9 +602,8 @@ static int qemu_pci_add_xenstore(libxl__
>          libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
>                          pcidev->bus, pcidev->dev, pcidev->func);
>      }
> -    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command",
> -                          domid);
> -    xs_write(ctx->xsh, XBT_NULL, path, "pci-ins", strlen("pci-ins"));
> +
> +    libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
>      rc = libxl__wait_for_device_model(gc, domid, NULL, NULL,
>                                        pci_ins_check, state);
>      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter",
> @@ -857,12 +856,11 @@ static int qemu_pci_remove_xenstore(libx
>      path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/parameter", domid);
>      libxl__xs_write(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
>                      pcidev->bus, pcidev->dev, pcidev->func);
> -    path = libxl__sprintf(gc, "/local/domain/0/device-model/%d/command", domid);
>  
>      /* Remove all functions at once atomically by only signalling
>       * device-model for function 0 */
>      if ( !force && (pcidev->vdevfn & 0x7) == 0 ) {
> -        xs_write(ctx->xsh, XBT_NULL, path, "pci-rem", strlen("pci-rem"));
> +        libxl__qemu_traditional_cmd(gc, domid, "pci-rem");
>          if (libxl__wait_for_device_model(gc, domid, "pci-removed",
>                                           NULL, NULL, NULL) < 0) {
>              LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Device Model didn't respond in time");



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:47:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAJ1-0000m4-V2; Tue, 31 Jan 2012 09:47:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAJ0-0000lX-9b
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:47:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328003228!12862578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30781 invoked from network); 31 Jan 2012 09:47:08 -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;
	31 Jan 2012 09:47:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10382915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:47: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, 31 Jan 2012 09:47:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:47:07 +0000
In-Reply-To: <39f63438767a8225a314.1327971907@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<39f63438767a8225a314.1327971907@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328003228.26983.312.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6] libxl: bugfix: create_domain()
 return to caller if !daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971504 28800
> # Node ID 39f63438767a8225a3148a43139c10f55a62c669
> # Parent  20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
> libxl: bugfix: create_domain() return to caller if !daemonize
> 
> Currently the create_domain function does not honor
> the daemonize flag properly. It exits irrespective of
> the value of the flag. This patch fixes the issue.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 20bbc4a754a7 -r 39f63438767a tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:13 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:24 2012 -0800
> @@ -1814,7 +1814,7 @@ waitpid_out:
>       * If we have daemonized then do not return to the caller -- this has
>       * already happened in the parent.
>       */
> -    if ( !need_daemon )
> +    if ( daemonize && !need_daemon )
>          exit(ret);
>  
>      return ret;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:47:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:47:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAJ1-0000m4-V2; Tue, 31 Jan 2012 09:47:15 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAJ0-0000lX-9b
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:47:14 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328003228!12862578!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30781 invoked from network); 31 Jan 2012 09:47:08 -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;
	31 Jan 2012 09:47:08 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10382915"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:47: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, 31 Jan 2012 09:47:08 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:47:07 +0000
In-Reply-To: <39f63438767a8225a314.1327971907@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<39f63438767a8225a314.1327971907@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328003228.26983.312.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 6] libxl: bugfix: create_domain()
 return to caller if !daemonize
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971504 28800
> # Node ID 39f63438767a8225a3148a43139c10f55a62c669
> # Parent  20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
> libxl: bugfix: create_domain() return to caller if !daemonize
> 
> Currently the create_domain function does not honor
> the daemonize flag properly. It exits irrespective of
> the value of the flag. This patch fixes the issue.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 20bbc4a754a7 -r 39f63438767a tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:13 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:24 2012 -0800
> @@ -1814,7 +1814,7 @@ waitpid_out:
>       * If we have daemonized then do not return to the caller -- this has
>       * already happened in the parent.
>       */
> -    if ( !need_daemon )
> +    if ( daemonize && !need_daemon )
>          exit(ret);
>  
>      return ret;



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:53:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAP7-00014f-RR; Tue, 31 Jan 2012 09:53:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsAP6-00014Y-Bs
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:53:32 +0000
Received: from [85.158.138.51:33547] by server-3.bemta-3.messagelabs.com id
	0B/31-26314-B1AB72F4; Tue, 31 Jan 2012 09:53:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328003608!11167316!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28257 invoked from network); 31 Jan 2012 09:53:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 09:53:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 09:53:27 +0000
Message-Id: <4F27C8240200007800070110@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 09:53:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
In-Reply-To: <20120130213926.GB16261@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 22:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Jan 30, 2012 at 02:45:33PM +0000, Wei Liu wrote:
>> @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, 
> struct netfront_info *info)
>>  		goto fail;
>>  	}
>>  
>> -	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
>> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
>> +			   "max-tx-ring-page-order", "%u",
>> +			   &max_tx_ring_page_order);
>> +	if (err < 0) {
>> +		info->tx_ring_page_order = 0;
>> +		dev_info(&dev->dev, "single tx ring\n");
>> +	} else {
>> +		info->tx_ring_page_order = max_tx_ring_page_order;
>> +		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
>> +			 max_tx_ring_page_order);
>> +	}
>> +	info->tx_ring_pages = (1U << info->tx_ring_page_order);
>> +
>> +	txs = (struct xen_netif_tx_sring *)
>> +		dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
>> +				   &info->tx_ring_dma_handle,
>> +				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> 
> Hm, so I see you are using 'NULL' which is a big nono (the API docs say 
> that).
> But the other reason why it is a no-no, is b/c this way the generic DMA 
> engine has no
> clue whether you are OK getting pages under 4GB or above it (so 64-bit 
> support).
> 
> If you don't supply a 'dev' it will assume 4GB. But when you are run this as 
> a
> pure PV guest that won't matter the slighest b/I there are no DMA code in 
> action
> (well, there is dma_alloc_coherent - which looking at the code would NULL it 
> seems).
> 
> Anyhow, if you get to have more than 4GB in the guest or do PCI passthrough 
> and use
> 'iommu=soft'- at which point the Xen SWIOTLB will kick and you will end up 
> 'swizzling'
> the pages to be under 4GB. That can be fixed if you declerae a 'fake' device 
> where you set
> the coherent_dma_mask to DMA_BIT_MASK(64).
> 
> But if you boot the guest under HVM, then it will use the generic SWIOTLB 
> code, which
> won't guaranteeing the pages to be "machine" contingous but will be "guest 
> machine"
> contingous. Is that sufficient for this?
> 
> How did you test this? Did you supply iommu=soft  to your guest or booted it
> with more than 4GB?

Imo the use of the DMA API is a mistake here anyway. There's no need
for anything to be contiguous in a PV frontend/backend handshake
protocol, or if one finds there is it's very likely just because of trying to
avoid doing something properly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:53:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:53:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAP7-00014f-RR; Tue, 31 Jan 2012 09:53:33 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsAP6-00014Y-Bs
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:53:32 +0000
Received: from [85.158.138.51:33547] by server-3.bemta-3.messagelabs.com id
	0B/31-26314-B1AB72F4; Tue, 31 Jan 2012 09:53:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328003608!11167316!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28257 invoked from network); 31 Jan 2012 09:53:29 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 09:53:29 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 09:53:27 +0000
Message-Id: <4F27C8240200007800070110@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 09:53:24 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
In-Reply-To: <20120130213926.GB16261@phenom.dumpdata.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
	ian.campbell@citrix.com
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 22:39, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Mon, Jan 30, 2012 at 02:45:33PM +0000, Wei Liu wrote:
>> @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, 
> struct netfront_info *info)
>>  		goto fail;
>>  	}
>>  
>> -	txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
>> +	err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
>> +			   "max-tx-ring-page-order", "%u",
>> +			   &max_tx_ring_page_order);
>> +	if (err < 0) {
>> +		info->tx_ring_page_order = 0;
>> +		dev_info(&dev->dev, "single tx ring\n");
>> +	} else {
>> +		info->tx_ring_page_order = max_tx_ring_page_order;
>> +		dev_info(&dev->dev, "multi page tx ring, order = %d\n",
>> +			 max_tx_ring_page_order);
>> +	}
>> +	info->tx_ring_pages = (1U << info->tx_ring_page_order);
>> +
>> +	txs = (struct xen_netif_tx_sring *)
>> +		dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
>> +				   &info->tx_ring_dma_handle,
>> +				   __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> 
> Hm, so I see you are using 'NULL' which is a big nono (the API docs say 
> that).
> But the other reason why it is a no-no, is b/c this way the generic DMA 
> engine has no
> clue whether you are OK getting pages under 4GB or above it (so 64-bit 
> support).
> 
> If you don't supply a 'dev' it will assume 4GB. But when you are run this as 
> a
> pure PV guest that won't matter the slighest b/I there are no DMA code in 
> action
> (well, there is dma_alloc_coherent - which looking at the code would NULL it 
> seems).
> 
> Anyhow, if you get to have more than 4GB in the guest or do PCI passthrough 
> and use
> 'iommu=soft'- at which point the Xen SWIOTLB will kick and you will end up 
> 'swizzling'
> the pages to be under 4GB. That can be fixed if you declerae a 'fake' device 
> where you set
> the coherent_dma_mask to DMA_BIT_MASK(64).
> 
> But if you boot the guest under HVM, then it will use the generic SWIOTLB 
> code, which
> won't guaranteeing the pages to be "machine" contingous but will be "guest 
> machine"
> contingous. Is that sufficient for this?
> 
> How did you test this? Did you supply iommu=soft  to your guest or booted it
> with more than 4GB?

Imo the use of the DMA API is a mistake here anyway. There's no need
for anything to be contiguous in a PV frontend/backend handshake
protocol, or if one finds there is it's very likely just because of trying to
avoid doing something properly.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:55:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAQI-00018C-AS; Tue, 31 Jan 2012 09:54:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAQH-000183-0D
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:54:45 +0000
Received: from [85.158.138.51:28595] by server-5.bemta-3.messagelabs.com id
	75/1E-02363-46AB72F4; Tue, 31 Jan 2012 09:54:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328003681!6220880!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5309 invoked from network); 31 Jan 2012 09:54:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 09:54:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10383157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:54: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, 31 Jan 2012 09:54:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:54:41 +0000
In-Reply-To: <cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328003681.26983.318.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971511 28800
> # Node ID cd3d43d88c0568142dd061e744c34479e1a440f4
> # Parent  39f63438767a8225a3148a43139c10f55a62c669
> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 
> Implement QMP stop and resume functionality and split
> device model save into 3 parts:
>  suspend_dm(domid)
>  save_dm(domid, fd)
>  resume_dm(domid)
> 
> Integrate Device model suspend into suspend_common_callback
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 39f63438767a -r cd3d43d88c05 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:24 2012 -0800
> +++ b/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:31 2012 -0800
> @@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
>      return rc ? 0 : 1;
>  }
>  
> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int ret = 0, fd2 = -1;
> +    const char *filename = libxl__device_model_savefile(gc, domid);
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +                   "Saving device model state to %s", filename);
> +        libxl__qemu_traditional_cmd(gc, domid, "save");
> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_stop(gc, domid))
> +            return ERROR_FAIL;
> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
> +        if (fd2 < 0) {
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +                             "Unable to create a QEMU save file\n");
> +            return ERROR_FAIL;
> +        }
> +        /* Save DM state into fd2 */
> +        ret = libxl__qmp_migrate(gc, domid, fd2);
> +        if (ret)
> +            unlink(filename);
> +        close(fd2);
> +        fd2 = -1;
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return ret;
> +}
> +
> +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        libxl__qemu_traditional_cmd(gc, domid, "continue");

No libxl__wait_for_device_model -> "running"?

> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_resume(gc, domid))
> +            return ERROR_FAIL;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return 0;
> +}
> +
>  static int libxl__domain_suspend_common_callback(void *data)
>  {
>      struct suspendinfo *si = data;
> @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
>              return 0;
>          }
>          si->guest_responded = 1;
> -        return 1;
> +        goto suspend_dm;
>      }
>  
>      if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
> @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
>              shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
>              if (shutdown_reason == SHUTDOWN_suspend) {
>                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
> -                return 1;
> +                goto suspend_dm;
>              }
>          }
>  
> @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
>  
>      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
>      return 0;
> +
> + suspend_dm:

The goto's make the code flow a bit tricky to follow (this function is
already a bit tricksy with the early exit for the evtchn suspend case).

Why not pass si to libxl__domain_suspend_device_model and let it contain
the "if !hvm return" and logging stuff so you can just call in in place
of the two goto statements?

> +    if (si->hvm) {
> +        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
> +        if (ret) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "libxl__domain_suspend_device_model failed ret=%d", ret);
> +            return 0;
> +        }
> +    }
> +    return 1;
>  }
>  

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:55:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:55:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAQI-00018C-AS; Tue, 31 Jan 2012 09:54:46 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAQH-000183-0D
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:54:45 +0000
Received: from [85.158.138.51:28595] by server-5.bemta-3.messagelabs.com id
	75/1E-02363-46AB72F4; Tue, 31 Jan 2012 09:54:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-174.messagelabs.com!1328003681!6220880!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5309 invoked from network); 31 Jan 2012 09:54:42 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 09:54:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10383157"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:54: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, 31 Jan 2012 09:54:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:54:41 +0000
In-Reply-To: <cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328003681.26983.318.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
 QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971511 28800
> # Node ID cd3d43d88c0568142dd061e744c34479e1a440f4
> # Parent  39f63438767a8225a3148a43139c10f55a62c669
> libxl: QMP stop/resume & refactor QEMU suspend/resume/save
> 
> Implement QMP stop and resume functionality and split
> device model save into 3 parts:
>  suspend_dm(domid)
>  save_dm(domid, fd)
>  resume_dm(domid)
> 
> Integrate Device model suspend into suspend_common_callback
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 39f63438767a -r cd3d43d88c05 tools/libxl/libxl_dom.c
> --- a/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:24 2012 -0800
> +++ b/tools/libxl/libxl_dom.c	Mon Jan 30 16:58:31 2012 -0800
> @@ -425,6 +425,61 @@ static int libxl__domain_suspend_common_
>      return rc ? 0 : 1;
>  }
>  
> +int libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +    libxl_ctx *ctx = libxl__gc_owner(gc);
> +    int ret = 0, fd2 = -1;
> +    const char *filename = libxl__device_model_savefile(gc, domid);
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG,
> +                   "Saving device model state to %s", filename);
> +        libxl__qemu_traditional_cmd(gc, domid, "save");
> +        libxl__wait_for_device_model(gc, domid, "paused", NULL, NULL, NULL);
> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_stop(gc, domid))
> +            return ERROR_FAIL;
> +        fd2 = open(filename, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
> +        if (fd2 < 0) {
> +            LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> +                             "Unable to create a QEMU save file\n");
> +            return ERROR_FAIL;
> +        }
> +        /* Save DM state into fd2 */
> +        ret = libxl__qmp_migrate(gc, domid, fd2);
> +        if (ret)
> +            unlink(filename);
> +        close(fd2);
> +        fd2 = -1;
> +        break;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return ret;
> +}
> +
> +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
> +{
> +
> +    switch (libxl__device_model_version_running(gc, domid)) {
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> +        libxl__qemu_traditional_cmd(gc, domid, "continue");

No libxl__wait_for_device_model -> "running"?

> +        break;
> +    }
> +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> +        if (libxl__qmp_resume(gc, domid))
> +            return ERROR_FAIL;
> +    default:
> +        return ERROR_INVAL;
> +    }
> +
> +    return 0;
> +}
> +
>  static int libxl__domain_suspend_common_callback(void *data)
>  {
>      struct suspendinfo *si = data;
> @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
>              return 0;
>          }
>          si->guest_responded = 1;
> -        return 1;
> +        goto suspend_dm;
>      }
>  
>      if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
> @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
>              shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift) & XEN_DOMINF_shutdownmask;
>              if (shutdown_reason == SHUTDOWN_suspend) {
>                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has suspended");
> -                return 1;
> +                goto suspend_dm;
>              }
>          }
>  
> @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
>  
>      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
>      return 0;
> +
> + suspend_dm:

The goto's make the code flow a bit tricky to follow (this function is
already a bit tricksy with the early exit for the evtchn suspend case).

Why not pass si to libxl__domain_suspend_device_model and let it contain
the "if !hvm return" and logging stuff so you can just call in in place
of the two goto statements?

> +    if (si->hvm) {
> +        ret = libxl__domain_suspend_device_model(si->gc, si->domid);
> +        if (ret) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "libxl__domain_suspend_device_model failed ret=%d", ret);
> +            return 0;
> +        }
> +    }
> +    return 1;
>  }
>  

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:58:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsATD-0001IW-TX; Tue, 31 Jan 2012 09:57:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RsATC-0001IG-GK
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:57:46 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328003857!12188579!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29364 invoked from network); 31 Jan 2012 09:57:39 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 09:57:39 -0000
Received: by pbds6 with SMTP id s6so231760pbd.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 01:57: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=+y3Osqtpnv8LbioU2X6y5wXYLSncMW5Q/DteuLsojTs=;
	b=NuHm0sXpiBcsaNkXkqJRVC7B2vUBOTCbnVHiWjCXAjfcA0cWyK76bGcvUOqxy5WXYp
	DmDo/xOA0dklB20ihBa/OXAeOUy9ZurgEffBMt+rnk+UFk5w0Uqw/H6OE/CCRgl0JGv6
	yLb/AyAFIM4KBuDjxP7muV+gktdnB+fhBSSzg=
MIME-Version: 1.0
Received: by 10.68.134.68 with SMTP id pi4mr1968148pbb.56.1328003857330; Tue,
	31 Jan 2012 01:57:37 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Tue, 31 Jan 2012 01:57:37 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
Date: Tue, 31 Jan 2012 10:57:37 +0100
X-Google-Sender-Auth: DVnZb_D9AUPRMypvk65KRUDcwSE
Message-ID: <CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGVsbG8sCgpJJ3ZlIGJlZW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBlbWFpbCBmb3Igc29tZSB0aW1l
LCBidXQgdGhlcmUgYXJlIHBhcnRzCnRoYXQgYXJlIHN0aWxsIG5vdCBjbGVhciwgc28gSSdtIHNv
cnJ5IHRvIGJvdGhlciB5b3UgYWdhaW4gd2l0aAp0aGlzLi4uCgoyMDEyLzEvMjcgU3RlZmFubyBT
dGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT46Cj4gT24gRnJpLCAy
NyBKYW4gMjAxMiwgUm9nZXIgUGF1IE1vbm7Dg8KpIHdyb3RlOgo+PiBIZWxsbywKPj4KPj4gSSBo
YXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIGRyaXZlciBkb21haW5zIGFuZCByb290IGhhcmQgZGlz
a3MsIGlmIHRoZQo+PiByb290IGhhcmQgZGlzayAodGhlIG9uZSBjb250YWluaW5nIHRoZSBrZXJu
ZWwgYW5kIHJhbWRpc2spIGlzIG9uIGEKPj4gZHJpdmVyIGRvbWFpbiwgaG93IGNhbiB3ZSBwYXNz
IHRoZSBrZXJuZWwgdG8gdGhlIERvbTA/IGxpYnZjaGFuIHNlZW1zCj4+IGxpa2UgYSBnb29kIG9w
dGlvbiB0byBwYXNzIHRoZSBrZXJuZWwgYW5kIHJhbWRpc2sgZnJvbSBkcml2ZXIgZG9tYWlucwo+
PiB0byBEb20wLCBidXQgSSB3b3VsZCBsaWtlIHRvIGhlYXIgb3BpbmlvbnMgYWJvdXQgdGhhdC4K
Pj4KPj4gSWYga2VybmVsIGFuZCByYW1kaXNrIHBhc3NpbmcgaXMgbm90IGltcGxlbWVudGVkLCB0
aGUgb25seSB3YXkgdG8gYm9vdAo+PiBmcm9tIGhhcmQgZGlzayBzdG9yZWQgb24gZHJpdmVyIGRv
bWFpbnMgaXMgdG8gZXh0cmFjdCB0aGUga2VybmVsIGFuZAo+PiByYW1kaXNrIGFuZCBzdG9yZSB0
aGVtIG9uIHRoZSBEb20wLgo+Cj4gTGV0IG1lIGRlc2NyaWJlIGluIG1vcmUgZGV0YWlscyB0aGlz
IHNjZW5hcmlvIGZvciB5b3U6Cj4gd2UgYXJlIHVzaW5nIGEgc3RvcmFnZSBkcml2ZXIgZG9tYWlu
ICh0aGUgc3RvcmFnZSBjb250cm9sbGVyIGlzIGFzc2lnbmVkCj4gdG8gYSBkb21haW4gb3RoZXIg
dGhhbiBkb20wKSwgYW5kIGRvbTAgaXMgc3RpbGwgcmVzcG9uc2libGUgZm9yIGNyZWF0aW5nCj4g
YWxsIHRoZSBvdGhlciBWTXMsIGluY2x1ZGluZyB0aGUgc3RvcmFnZSBkcml2ZXIgZG9tYWluLgoK
T2ssIHlvdSBsYXVuY2ggdGhlIERvbTAgbm9ybWFsbHkgYW5kIHRoZW4geW91IGxhdW5jaCBhbm90
aGVyIGRvbWFpbihzKQp0aGF0IHdpbGwgYmUgdGhlIGRyaXZlciBkb21haW5zLCB0aGF0J3Mgb2su
IEV2ZXJ5IG9uZSBvZiB0aGlzIGRyaXZlcnMKZG9tYWlucyBzaG91bGQgYmUgcnVubmluZyB4ZW5i
YWNrZW5kZCB0byByZWFjdCB0byBkZXZpY2UKY3JlYXRpb24vZGVzdHJ1Y3Rpb24uCgo+Cj4gSG93
IGNhbiBkb20wIGNyZWF0ZSB0aGUgc3RvcmFnZSBkcml2ZXIgZG9tYWluIGlmIHRoZSBrZXJuZWwg
YW5kIGluaXRyZAo+IG9mIHRoZSBzdG9yYWdlIGRyaXZlciBkb21haW4gYXJlIG9uIHRoZSBoYXJk
IGRpc2s/Cj4KPiBBIHNpbXBsZSBzb2x1dGlvbiB3b3VsZCBiZSBoYXZpbmcgdGhlIHN0b3JhZ2Ug
ZHJpdmVyIGRvbWFpbiBrZXJuZWwgYW5kCj4gaW5pdHJkIGluc2lkZSBkb20wIGluaXRyZCBvciBw
YXNzZWQgdG8gZG9tMCB0aHJvdWdoIG11bHRpYm9vdCBieSB0aGUKPiBib290bG9hZGVyIGFzIGFu
IGFkZGl0aW9uYWwgcGF5bG9hZCAoYmV0dGVyKS4KPiBEb20wIHNob3VsZCBiZSBjYXBhYmxlIG9m
IGZyZWVpbmcgdGhlIG1lbW9yeSB1c2VkIHRoaXMgd2F5IGFmdGVyCj4gY3JlYXRpbmcgdGhlIHN0
b3JhZ2UgZHJpdmVyIGRvbWFpbi4KClRoYXQncyB3aGF0IEkgZG9uJ3QgZ2V0LiBCb290aW5nIHRo
ZSBkcml2ZXIgZG9tYWluIHNob3VsZCBiZSBubwpwcm9ibGVtLCBiZWNhdXNlIHlvdSBjYW4gYWxz
byBoYXZlIGEgeGVuYmFja2VuZGQgcnVubmluZyBpbiB0aGUgRG9tMAp0byBib290IHRoZSBkcml2
ZXIgZG9tYWluIChvciBtYXliZSB5b3Ugd2FudCB0byB1c2UgYm90aCBEb20wIGFuZAphbm90aGVy
IERvbVUgYXMgZHJpdmVyIGRvbWFpbnMpLgoKV2hhdCBJIGRvbid0IGdldCBpcyB3aGF0IHlvdSBk
byB3aGVuIHlvdSBoYXZlIHRvIGJvb3QgYSBQViBEb21VIHdoaWNoCnJvb3QgSEREIGlzIG9uIHRo
ZSBkcml2ZXIgZG9tYWluLiBEb20wIG5lZWRzIHRoZSBrZXJuZWwvaW5pdHJkIGZyb20KdGhlIEhE
RCAodXN1YWxseSBleHRyYWN0ZWQgdXNpbmcgcHlncnViKS4gU2luY2UgdGhlIEhERCBpcyBpbnNp
ZGUgdGhlCmRyaXZlciBkb21haW4sIERvbTAgZG9lc24ndCBoYXZlIGFjY2VzcyB0byB0aGF0IGlt
YWdlLCBzbyB0aGVyZSdzIG5vCndheSB0byBleHRyYWN0IHRoZSBrZXJuZWwvaW5pdHJkIGZyb20g
dGhlIERvbTAuIFdoYXQgSSB0aHJvdWdoIGlzIHRoYXQKdGhlIGRyaXZlciBkb21haW4gaGFzIHRv
IHJ1biBweWdydWIsIGV4dHJhY3QgdGhlIGtlcm5lbC9pbml0cmQsIGFuZApwYXNzIGJvdGggZmls
ZXMgdG8gdGhlIERvbTAsIGJ1dCBob3cgY2FuIHdlIHBhc3MgdGhvc2UgZmlsZXM/IGxpYnZjaGFu
CnNlZW1zIGxpa2UgdGhlIGJlc3Qgb3B0aW9uLCBidXQgSSB3b3VsZCBsaWtlIHRvIGhlYWQgb3Ro
ZXJzIG9waW5pb25zCmFib3V0IHRoaXMuCgpDdXJyZW50bHkgSSBoYXZlIGEgbW9zdGx5IHdvcmtp
bmcgeGVuYmFja2VuZGQgaW1wbGVtZW50YXRpb24gd2l0aApsaWJ4bCwgdGhhdCBjYW4gaGFuZGxl
IHZiZCBhbmQgdmlmIGludGVyZmFjZXMsIGJ1dCBJJ20gbWlzc2luZyBxZGlzaywKSSBzdGlsbCBo
YXZlIHRvIGxvb2sgaW50byB0aGUgUWVtdSBzdHVmZiB0byBiZSBhYmxlIHRvIGxhdW5jaCBhIGRl
dmljZQptb2RlbCB0aGF0IG9ubHkgYXR0YWNoZXMgYSBIREQuCgpUaGFua3MsIFJvZ2VyLgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 31 09:58:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 09:58:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsATD-0001IW-TX; Tue, 31 Jan 2012 09:57:47 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <royger@gmail.com>) id 1RsATC-0001IG-GK
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 09:57:46 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-14.tower-216.messagelabs.com!1328003857!12188579!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29364 invoked from network); 31 Jan 2012 09:57:39 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-14.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 09:57:39 -0000
Received: by pbds6 with SMTP id s6so231760pbd.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 01:57: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=+y3Osqtpnv8LbioU2X6y5wXYLSncMW5Q/DteuLsojTs=;
	b=NuHm0sXpiBcsaNkXkqJRVC7B2vUBOTCbnVHiWjCXAjfcA0cWyK76bGcvUOqxy5WXYp
	DmDo/xOA0dklB20ihBa/OXAeOUy9ZurgEffBMt+rnk+UFk5w0Uqw/H6OE/CCRgl0JGv6
	yLb/AyAFIM4KBuDjxP7muV+gktdnB+fhBSSzg=
MIME-Version: 1.0
Received: by 10.68.134.68 with SMTP id pi4mr1968148pbb.56.1328003857330; Tue,
	31 Jan 2012 01:57:37 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Tue, 31 Jan 2012 01:57:37 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
Date: Tue, 31 Jan 2012 10:57:37 +0100
X-Google-Sender-Auth: DVnZb_D9AUPRMypvk65KRUDcwSE
Message-ID: <CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
From: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

SGVsbG8sCgpJJ3ZlIGJlZW4gdGhpbmtpbmcgYWJvdXQgdGhpcyBlbWFpbCBmb3Igc29tZSB0aW1l
LCBidXQgdGhlcmUgYXJlIHBhcnRzCnRoYXQgYXJlIHN0aWxsIG5vdCBjbGVhciwgc28gSSdtIHNv
cnJ5IHRvIGJvdGhlciB5b3UgYWdhaW4gd2l0aAp0aGlzLi4uCgoyMDEyLzEvMjcgU3RlZmFubyBT
dGFiZWxsaW5pIDxzdGVmYW5vLnN0YWJlbGxpbmlAZXUuY2l0cml4LmNvbT46Cj4gT24gRnJpLCAy
NyBKYW4gMjAxMiwgUm9nZXIgUGF1IE1vbm7Dg8KpIHdyb3RlOgo+PiBIZWxsbywKPj4KPj4gSSBo
YXZlIGEgcXVlc3Rpb24gcmVnYXJkaW5nIGRyaXZlciBkb21haW5zIGFuZCByb290IGhhcmQgZGlz
a3MsIGlmIHRoZQo+PiByb290IGhhcmQgZGlzayAodGhlIG9uZSBjb250YWluaW5nIHRoZSBrZXJu
ZWwgYW5kIHJhbWRpc2spIGlzIG9uIGEKPj4gZHJpdmVyIGRvbWFpbiwgaG93IGNhbiB3ZSBwYXNz
IHRoZSBrZXJuZWwgdG8gdGhlIERvbTA/IGxpYnZjaGFuIHNlZW1zCj4+IGxpa2UgYSBnb29kIG9w
dGlvbiB0byBwYXNzIHRoZSBrZXJuZWwgYW5kIHJhbWRpc2sgZnJvbSBkcml2ZXIgZG9tYWlucwo+
PiB0byBEb20wLCBidXQgSSB3b3VsZCBsaWtlIHRvIGhlYXIgb3BpbmlvbnMgYWJvdXQgdGhhdC4K
Pj4KPj4gSWYga2VybmVsIGFuZCByYW1kaXNrIHBhc3NpbmcgaXMgbm90IGltcGxlbWVudGVkLCB0
aGUgb25seSB3YXkgdG8gYm9vdAo+PiBmcm9tIGhhcmQgZGlzayBzdG9yZWQgb24gZHJpdmVyIGRv
bWFpbnMgaXMgdG8gZXh0cmFjdCB0aGUga2VybmVsIGFuZAo+PiByYW1kaXNrIGFuZCBzdG9yZSB0
aGVtIG9uIHRoZSBEb20wLgo+Cj4gTGV0IG1lIGRlc2NyaWJlIGluIG1vcmUgZGV0YWlscyB0aGlz
IHNjZW5hcmlvIGZvciB5b3U6Cj4gd2UgYXJlIHVzaW5nIGEgc3RvcmFnZSBkcml2ZXIgZG9tYWlu
ICh0aGUgc3RvcmFnZSBjb250cm9sbGVyIGlzIGFzc2lnbmVkCj4gdG8gYSBkb21haW4gb3RoZXIg
dGhhbiBkb20wKSwgYW5kIGRvbTAgaXMgc3RpbGwgcmVzcG9uc2libGUgZm9yIGNyZWF0aW5nCj4g
YWxsIHRoZSBvdGhlciBWTXMsIGluY2x1ZGluZyB0aGUgc3RvcmFnZSBkcml2ZXIgZG9tYWluLgoK
T2ssIHlvdSBsYXVuY2ggdGhlIERvbTAgbm9ybWFsbHkgYW5kIHRoZW4geW91IGxhdW5jaCBhbm90
aGVyIGRvbWFpbihzKQp0aGF0IHdpbGwgYmUgdGhlIGRyaXZlciBkb21haW5zLCB0aGF0J3Mgb2su
IEV2ZXJ5IG9uZSBvZiB0aGlzIGRyaXZlcnMKZG9tYWlucyBzaG91bGQgYmUgcnVubmluZyB4ZW5i
YWNrZW5kZCB0byByZWFjdCB0byBkZXZpY2UKY3JlYXRpb24vZGVzdHJ1Y3Rpb24uCgo+Cj4gSG93
IGNhbiBkb20wIGNyZWF0ZSB0aGUgc3RvcmFnZSBkcml2ZXIgZG9tYWluIGlmIHRoZSBrZXJuZWwg
YW5kIGluaXRyZAo+IG9mIHRoZSBzdG9yYWdlIGRyaXZlciBkb21haW4gYXJlIG9uIHRoZSBoYXJk
IGRpc2s/Cj4KPiBBIHNpbXBsZSBzb2x1dGlvbiB3b3VsZCBiZSBoYXZpbmcgdGhlIHN0b3JhZ2Ug
ZHJpdmVyIGRvbWFpbiBrZXJuZWwgYW5kCj4gaW5pdHJkIGluc2lkZSBkb20wIGluaXRyZCBvciBw
YXNzZWQgdG8gZG9tMCB0aHJvdWdoIG11bHRpYm9vdCBieSB0aGUKPiBib290bG9hZGVyIGFzIGFu
IGFkZGl0aW9uYWwgcGF5bG9hZCAoYmV0dGVyKS4KPiBEb20wIHNob3VsZCBiZSBjYXBhYmxlIG9m
IGZyZWVpbmcgdGhlIG1lbW9yeSB1c2VkIHRoaXMgd2F5IGFmdGVyCj4gY3JlYXRpbmcgdGhlIHN0
b3JhZ2UgZHJpdmVyIGRvbWFpbi4KClRoYXQncyB3aGF0IEkgZG9uJ3QgZ2V0LiBCb290aW5nIHRo
ZSBkcml2ZXIgZG9tYWluIHNob3VsZCBiZSBubwpwcm9ibGVtLCBiZWNhdXNlIHlvdSBjYW4gYWxz
byBoYXZlIGEgeGVuYmFja2VuZGQgcnVubmluZyBpbiB0aGUgRG9tMAp0byBib290IHRoZSBkcml2
ZXIgZG9tYWluIChvciBtYXliZSB5b3Ugd2FudCB0byB1c2UgYm90aCBEb20wIGFuZAphbm90aGVy
IERvbVUgYXMgZHJpdmVyIGRvbWFpbnMpLgoKV2hhdCBJIGRvbid0IGdldCBpcyB3aGF0IHlvdSBk
byB3aGVuIHlvdSBoYXZlIHRvIGJvb3QgYSBQViBEb21VIHdoaWNoCnJvb3QgSEREIGlzIG9uIHRo
ZSBkcml2ZXIgZG9tYWluLiBEb20wIG5lZWRzIHRoZSBrZXJuZWwvaW5pdHJkIGZyb20KdGhlIEhE
RCAodXN1YWxseSBleHRyYWN0ZWQgdXNpbmcgcHlncnViKS4gU2luY2UgdGhlIEhERCBpcyBpbnNp
ZGUgdGhlCmRyaXZlciBkb21haW4sIERvbTAgZG9lc24ndCBoYXZlIGFjY2VzcyB0byB0aGF0IGlt
YWdlLCBzbyB0aGVyZSdzIG5vCndheSB0byBleHRyYWN0IHRoZSBrZXJuZWwvaW5pdHJkIGZyb20g
dGhlIERvbTAuIFdoYXQgSSB0aHJvdWdoIGlzIHRoYXQKdGhlIGRyaXZlciBkb21haW4gaGFzIHRv
IHJ1biBweWdydWIsIGV4dHJhY3QgdGhlIGtlcm5lbC9pbml0cmQsIGFuZApwYXNzIGJvdGggZmls
ZXMgdG8gdGhlIERvbTAsIGJ1dCBob3cgY2FuIHdlIHBhc3MgdGhvc2UgZmlsZXM/IGxpYnZjaGFu
CnNlZW1zIGxpa2UgdGhlIGJlc3Qgb3B0aW9uLCBidXQgSSB3b3VsZCBsaWtlIHRvIGhlYWQgb3Ro
ZXJzIG9waW5pb25zCmFib3V0IHRoaXMuCgpDdXJyZW50bHkgSSBoYXZlIGEgbW9zdGx5IHdvcmtp
bmcgeGVuYmFja2VuZGQgaW1wbGVtZW50YXRpb24gd2l0aApsaWJ4bCwgdGhhdCBjYW4gaGFuZGxl
IHZiZCBhbmQgdmlmIGludGVyZmFjZXMsIGJ1dCBJJ20gbWlzc2luZyBxZGlzaywKSSBzdGlsbCBo
YXZlIHRvIGxvb2sgaW50byB0aGUgUWVtdSBzdHVmZiB0byBiZSBhYmxlIHRvIGxhdW5jaCBhIGRl
dmljZQptb2RlbCB0aGF0IG9ubHkgYXR0YWNoZXMgYSBIREQuCgpUaGFua3MsIFJvZ2VyLgoKX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVsIG1h
aWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuc291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVu
c291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:01:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAW9-0001XN-G8; Tue, 31 Jan 2012 10:00:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAW8-0001X9-MX
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:00:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328004041!12639312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13245 invoked from network); 31 Jan 2012 10:00:42 -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;
	31 Jan 2012 10:00:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10383357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:00: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, 31 Jan 2012 10:00:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:00:41 +0000
In-Reply-To: <efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328004041.26983.322.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971527 28800
> # Node ID efe92d80c47487485056266a1404a8d2817b7f09
> # Parent  cd3d43d88c0568142dd061e744c34479e1a440f4
> libxl: support suspend_cancel in domain_resume
> 
> Add an extra parameter to libxl_domain_resume indicating
> if the caller wishes to use the SUSPEND_CANCEL style
> resume instead of the normal resume.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 30 16:58:31 2012 -0800
> +++ b/tools/libxl/libxl.c	Mon Jan 30 16:58:47 2012 -0800
> @@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
>      return rc;
>  }
>  
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast)
>  {
>      GC_INIT(ctx);
>      int rc = 0;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
> -                "non-cooperative hvm domain %u", domid);
> -        rc = ERROR_NI;
> -        goto out;
> -    }
> -    if (xc_domain_resume(ctx->xch, domid, 0)) {
> +    if (xc_domain_resume(ctx->xch, domid, fast)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xc_domain_resume failed for domain %u",
>                          domid);
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +        rc = libxl__domain_resume_device_model(gc, domid);
> +        if (rc) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "failed to resume device model for domain %u:%d",
> +                       domid, rc);
> +            goto out;
> +        }
> +    }
> +
>      if (!xs_resume_domain(ctx->xsh, domid)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xs_resume_domain failed for domain %u",
> diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Mon Jan 30 16:58:31 2012 -0800
> +++ b/tools/libxl/libxl.h	Mon Jan 30 16:58:47 2012 -0800
> @@ -268,7 +268,7 @@ int libxl_domain_create_restore(libxl_ct
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                            uint32_t domid, int fd);
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast);

Please can you add a few words about what fast means and when its use
would be appropriate.

I'm not sure fast is right word -- it happens that this mechanism is
faster but isn't the real meaning "co-operative" or something along
those lines?

Would a better name be libxl_domain_suspend_cancel, sharing a common
helper internally with libxl_domain_resume?

Ian.

>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:31 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:47 2012 -0800
> @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
>          if (common_domname) {
>              libxl_domain_rename(ctx, domid, away_domname, common_domname);
>          }
> -        rc = libxl_domain_resume(ctx, domid);
> +        rc = libxl_domain_resume(ctx, domid, 1);
>          if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
>  
>          fprintf(stderr, "Migration failed due to problems at target.\n");
> @@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
>      close(send_fd);
>      migration_child_report(child, recv_fd);
>      fprintf(stderr, "Migration failed, resuming at sender.\n");
> -    libxl_domain_resume(ctx, domid);
> +    libxl_domain_resume(ctx, domid, 1);
>      exit(-ERROR_FAIL);
>  
>   failed_badly:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:01:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:01:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAW9-0001XN-G8; Tue, 31 Jan 2012 10:00:49 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAW8-0001X9-MX
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:00:48 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328004041!12639312!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13245 invoked from network); 31 Jan 2012 10:00:42 -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;
	31 Jan 2012 10:00:42 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10383357"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:00: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, 31 Jan 2012 10:00:41 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:00:41 +0000
In-Reply-To: <efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328004041.26983.322.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971527 28800
> # Node ID efe92d80c47487485056266a1404a8d2817b7f09
> # Parent  cd3d43d88c0568142dd061e744c34479e1a440f4
> libxl: support suspend_cancel in domain_resume
> 
> Add an extra parameter to libxl_domain_resume indicating
> if the caller wishes to use the SUSPEND_CANCEL style
> resume instead of the normal resume.
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 30 16:58:31 2012 -0800
> +++ b/tools/libxl/libxl.c	Mon Jan 30 16:58:47 2012 -0800
> @@ -229,24 +229,29 @@ int libxl_domain_rename(libxl_ctx *ctx, 
>      return rc;
>  }
>  
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid)
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast)
>  {
>      GC_INIT(ctx);
>      int rc = 0;
>  
> -    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> -        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Called domain_resume on "
> -                "non-cooperative hvm domain %u", domid);
> -        rc = ERROR_NI;
> -        goto out;
> -    }
> -    if (xc_domain_resume(ctx->xch, domid, 0)) {
> +    if (xc_domain_resume(ctx->xch, domid, fast)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xc_domain_resume failed for domain %u",
>                          domid);
>          rc = ERROR_FAIL;
>          goto out;
>      }
> +
> +    if (LIBXL__DOMAIN_IS_TYPE(gc,  domid, HVM)) {
> +        rc = libxl__domain_resume_device_model(gc, domid);
> +        if (rc) {
> +            LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                       "failed to resume device model for domain %u:%d",
> +                       domid, rc);
> +            goto out;
> +        }
> +    }
> +
>      if (!xs_resume_domain(ctx->xsh, domid)) {
>          LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
>                          "xs_resume_domain failed for domain %u",
> diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.h
> --- a/tools/libxl/libxl.h	Mon Jan 30 16:58:31 2012 -0800
> +++ b/tools/libxl/libxl.h	Mon Jan 30 16:58:47 2012 -0800
> @@ -268,7 +268,7 @@ int libxl_domain_create_restore(libxl_ct
>  void libxl_domain_config_dispose(libxl_domain_config *d_config);
>  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
>                            uint32_t domid, int fd);
> -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast);

Please can you add a few words about what fast means and when its use
would be appropriate.

I'm not sure fast is right word -- it happens that this mechanism is
faster but isn't the real meaning "co-operative" or something along
those lines?

Would a better name be libxl_domain_suspend_cancel, sharing a common
helper internally with libxl_domain_resume?

Ian.

>  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
>  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:31 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:47 2012 -0800
> @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
>          if (common_domname) {
>              libxl_domain_rename(ctx, domid, away_domname, common_domname);
>          }
> -        rc = libxl_domain_resume(ctx, domid);
> +        rc = libxl_domain_resume(ctx, domid, 1);
>          if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
>  
>          fprintf(stderr, "Migration failed due to problems at target.\n");
> @@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
>      close(send_fd);
>      migration_child_report(child, recv_fd);
>      fprintf(stderr, "Migration failed, resuming at sender.\n");
> -    libxl_domain_resume(ctx, domid);
> +    libxl_domain_resume(ctx, domid, 1);
>      exit(-ERROR_FAIL);
>  
>   failed_badly:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:01:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:01:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAWc-0001Zr-Tt; Tue, 31 Jan 2012 10:01: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 1RsAWb-0001ZI-B1
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:01:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328004002!63147524!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1480 invoked from network); 31 Jan 2012 10:00:04 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 10:00:04 -0000
Received: by pbds6 with SMTP id s6so249316pbd.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 02:01:11 -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=E+GCkcs9gQIRs2lcei3xzKz86jsUDo6/gVS2RHqUdMU=;
	b=DOPhcWZUBCmL390/oLHi42/hlK5qTscxx+vkM6GEfXXD4rueoqFA39aiMAongMPOp4
	z/4VTy17rr1JFanx62xMGL6I5uHAmy92pwNquxOYCDfUKDVfUKBngiOoZTiPswgKG5hN
	sCzFc7z7mTbrXBVZMY5Nd9rNwK0mKAa+xEC6E=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr49334630pbc.5.1328004071171; Tue,
	31 Jan 2012 02:01:11 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Tue, 31 Jan 2012 02:01:11 -0800 (PST)
Date: Tue, 31 Jan 2012 11:01:11 +0100
X-Google-Sender-Auth: -na-dryzp8yheS6R-JJ5GvTot0c
Message-ID: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@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] How to get DomU id from 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

Hello,

This is quite a trivial question, but I haven't been able to find how
to do it. Is there anyway to get the id of a PV DomU from inside the
(same) PV DomU?

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 Jan 31 10:01:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:01:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAWc-0001Zr-Tt; Tue, 31 Jan 2012 10:01: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 1RsAWb-0001ZI-B1
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:01:17 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328004002!63147524!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1480 invoked from network); 31 Jan 2012 10:00:04 -0000
Received: from mail-pw0-f43.google.com (HELO mail-pw0-f43.google.com)
	(209.85.160.43)
	by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 10:00:04 -0000
Received: by pbds6 with SMTP id s6so249316pbd.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 02:01:11 -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=E+GCkcs9gQIRs2lcei3xzKz86jsUDo6/gVS2RHqUdMU=;
	b=DOPhcWZUBCmL390/oLHi42/hlK5qTscxx+vkM6GEfXXD4rueoqFA39aiMAongMPOp4
	z/4VTy17rr1JFanx62xMGL6I5uHAmy92pwNquxOYCDfUKDVfUKBngiOoZTiPswgKG5hN
	sCzFc7z7mTbrXBVZMY5Nd9rNwK0mKAa+xEC6E=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr49334630pbc.5.1328004071171; Tue,
	31 Jan 2012 02:01:11 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Tue, 31 Jan 2012 02:01:11 -0800 (PST)
Date: Tue, 31 Jan 2012 11:01:11 +0100
X-Google-Sender-Auth: -na-dryzp8yheS6R-JJ5GvTot0c
Message-ID: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@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] How to get DomU id from 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

Hello,

This is quite a trivial question, but I haven't been able to find how
to do it. Is there anyway to get the id of a PV DomU from inside the
(same) PV DomU?

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 Jan 31 10:04:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsAZp-0001r4-SL; Tue, 31 Jan 2012 10:04: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 1RsAZo-0001qc-DY
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:04:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328004216!54716703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13799 invoked from network); 31 Jan 2012 10:03:36 -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;
	31 Jan 2012 10:03:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10383473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:04:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:04:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:04:29 +0000
In-Reply-To: <1328004041.26983.322.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328004269.26983.323.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 10:00 +0000, Ian Campbell wrote:
> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h	Mon Jan 30 16:58:31 2012 -0800
> > +++ b/tools/libxl/libxl.h	Mon Jan 30 16:58:47 2012 -0800
> > @@ -268,7 +268,7 @@ int libxl_domain_create_restore(libxl_ct
> >  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> >  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> >                            uint32_t domid, int fd);
> > -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> > +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast);
> 
> Please can you add a few words about what fast means and when its use
> would be appropriate.
> 
> I'm not sure fast is right word -- it happens that this mechanism is
> faster but isn't the real meaning "co-operative" or something along
> those lines?
> 
> Would a better name be libxl_domain_suspend_cancel, sharing a common
> helper internally with libxl_domain_resume?

BTW, is there any way to tell if the guest even claims to support this
mechanism?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:04:56 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsAZp-0001r4-SL; Tue, 31 Jan 2012 10:04: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 1RsAZo-0001qc-DY
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:04:36 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328004216!54716703!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13799 invoked from network); 31 Jan 2012 10:03:36 -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;
	31 Jan 2012 10:03:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10383473"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:04:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:04:29 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:04:29 +0000
In-Reply-To: <1328004041.26983.322.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328004269.26983.323.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
 domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 10:00 +0000, Ian Campbell wrote:
> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/libxl.h
> > --- a/tools/libxl/libxl.h	Mon Jan 30 16:58:31 2012 -0800
> > +++ b/tools/libxl/libxl.h	Mon Jan 30 16:58:47 2012 -0800
> > @@ -268,7 +268,7 @@ int libxl_domain_create_restore(libxl_ct
> >  void libxl_domain_config_dispose(libxl_domain_config *d_config);
> >  int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> >                            uint32_t domid, int fd);
> > -int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid);
> > +int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int fast);
> 
> Please can you add a few words about what fast means and when its use
> would be appropriate.
> 
> I'm not sure fast is right word -- it happens that this mechanism is
> faster but isn't the real meaning "co-operative" or something along
> those lines?
> 
> Would a better name be libxl_domain_suspend_cancel, sharing a common
> helper internally with libxl_domain_resume?

BTW, is there any way to tell if the guest even claims to support this
mechanism?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:06:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAbR-0001yA-Bq; Tue, 31 Jan 2012 10:06:17 +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 1RsAbQ-0001xn-Eq
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:06:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328004370!11892375!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17025 invoked from network); 31 Jan 2012 10:06:10 -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; 31 Jan 2012 10:06:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsAbG-000MRJ-AW; Tue, 31 Jan 2012 10:06:06 +0000
Date: Tue, 31 Jan 2012 10:06:05 +0000
From: Tim Deegan <tim@xen.org>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Message-ID: <20120131100605.GB25307@ocelot.phlegethon.org>
References: <20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 10:57 +0100 on 31 Jan (1328007457), Roger Pau Monn? wrote:
> That's what I don't get. Booting the driver domain should be no
> problem, because you can also have a xenbackendd running in the Dom0
> to boot the driver domain (or maybe you want to use both Dom0 and
> another DomU as driver domains).
> 
> What I don't get is what you do when you have to boot a PV DomU which
> root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> the HDD (usually extracted using pygrub). Since the HDD is inside the
> driver domain, Dom0 doesn't have access to that image, so there's no
> way to extract the kernel/initrd from the Dom0. What I through is that
> the driver domain has to run pygrub, extract the kernel/initrd, and
> pass both files to the Dom0, but how can we pass those files? libvchan
> seems like the best option, but I would like to head others opinions
> about this.

You could attach to the disk image (using blkfront in dom0 and
blkback/tap/whatever in the driver domain), run pygrub and detach.
That's basically the same thing you have to do with a qcow image in a
traditional dom0.

Or you could use pvgrub to boot the domain, so dom0 code never has to
touch the guets-supplied disk image or kernel.  That seems much better
to me, but maybe it wouldn't work for some existing deployments?

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 Jan 31 10:06:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:06:33 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAbR-0001yA-Bq; Tue, 31 Jan 2012 10:06:17 +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 1RsAbQ-0001xn-Eq
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:06:16 +0000
X-Env-Sender: tim@xen.org
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328004370!11892375!1
X-Originating-IP: [81.29.64.94]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17025 invoked from network); 31 Jan 2012 10:06:10 -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; 31 Jan 2012 10:06:10 -0000
Received: from tjd by mail.phlegethon.org with local (Exim 4.67 (FreeBSD))
	(envelope-from <tim@xen.org>)
	id 1RsAbG-000MRJ-AW; Tue, 31 Jan 2012 10:06:06 +0000
Date: Tue, 31 Jan 2012 10:06:05 +0000
From: Tim Deegan <tim@xen.org>
To: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Message-ID: <20120131100605.GB25307@ocelot.phlegethon.org>
References: <20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 10:57 +0100 on 31 Jan (1328007457), Roger Pau Monn? wrote:
> That's what I don't get. Booting the driver domain should be no
> problem, because you can also have a xenbackendd running in the Dom0
> to boot the driver domain (or maybe you want to use both Dom0 and
> another DomU as driver domains).
> 
> What I don't get is what you do when you have to boot a PV DomU which
> root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> the HDD (usually extracted using pygrub). Since the HDD is inside the
> driver domain, Dom0 doesn't have access to that image, so there's no
> way to extract the kernel/initrd from the Dom0. What I through is that
> the driver domain has to run pygrub, extract the kernel/initrd, and
> pass both files to the Dom0, but how can we pass those files? libvchan
> seems like the best option, but I would like to head others opinions
> about this.

You could attach to the disk image (using blkfront in dom0 and
blkback/tap/whatever in the driver domain), run pygrub and detach.
That's basically the same thing you have to do with a qcow image in a
traditional dom0.

Or you could use pvgrub to boot the domain, so dom0 code never has to
touch the guets-supplied disk image or kernel.  That seems much better
to me, but maybe it wouldn't work for some existing deployments?

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 Jan 31 10:14:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsAik-0002Dc-9P; Tue, 31 Jan 2012 10:13: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 1RsAij-0002DU-1N
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:13:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328004776!52259608!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31295 invoked from network); 31 Jan 2012 10:12:56 -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; 31 Jan 2012 10:12:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 10:13:43 +0000
Message-Id: <4F27CCE40200007800070120@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 10:13:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <1361d9895cb17aa8fce1.1327943146@wotan.osrc.amd.com>
In-Reply-To: <1361d9895cb17aa8fce1.1327943146@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 18:05, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> --- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode.c	Mon Jan 30 18:00:50 2012 +0100
> @@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      info->error = 0;
>      info->cpu = cpumask_first(&cpu_online_map);
>  
> +    if ( microcode_ops->start_update )
> +    {
> +	ret = microcode_ops->start_update();
> +	if ( ret != 0 )
> +        {
> +	    xfree(info);
> +	    return ret;
> +	}

Indentation (no tabs).

> +    }
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> --- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode_amd.c	Mon Jan 30 18:00:50 2012 +0100
> @@ -337,13 +341,18 @@ static int cpu_request_microcode(int cpu
>      /* On success keep the microcode patch for
>       * re-apply on resume.
>       */
> -    if (error == 1)
> +    if ( error == 1 )
>      {
>          xfree(mc_old);
> -        return 0;
> +        error = 0;
> +    } else 

    }
    else

> +    {
> +        xfree(mc_amd);
> +        uci->mc.mc_amd = mc_old;
>      }
> -    xfree(mc_amd);
> -    uci->mc.mc_amd = mc_old;
> +
> +  out:
> +    svm_host_osvw_init();
>  
>      return error;
>  }
> --- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/platform_hypercall.c	Mon Jan 30 18:00:50 2012 +0100
> @@ -166,7 +166,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>              break;
>  
>          guest_from_compat_handle(data, op->u.microcode.data);
> +
> +        while ( !domctl_lock_acquire() )

It's not clear to me what you're trying to protect against here. I don't
think this prevents guests from making progress (and hence possibly
seeing the intermediate [and wrong] OSVW state between
svm_host_osvw_reset() and svm_host_osvw_init()).

Jan

> +            if ( hypercall_preempt_check() )
> +            {
> +                ret = hypercall_create_continuation(
> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
> +                goto out;
> +            }
> +
>          ret = microcode_update(data, op->u.microcode.length);
> +        domctl_lock_release();
>      }
>      break;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:14:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsAik-0002Dc-9P; Tue, 31 Jan 2012 10:13: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 1RsAij-0002DU-1N
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:13:49 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328004776!52259608!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31295 invoked from network); 31 Jan 2012 10:12:56 -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; 31 Jan 2012 10:12:56 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 10:13:43 +0000
Message-Id: <4F27CCE40200007800070120@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 10:13:40 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Boris Ostrovsky" <boris.ostrovsky@amd.com>
References: <1361d9895cb17aa8fce1.1327943146@wotan.osrc.amd.com>
In-Reply-To: <1361d9895cb17aa8fce1.1327943146@wotan.osrc.amd.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Christoph.Egger@amd.com, xen-devel@lists.xensource.com, keir@xen.org
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
 in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 30.01.12 at 18:05, Boris Ostrovsky <boris.ostrovsky@amd.com> wrote:
> --- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode.c	Mon Jan 30 18:00:50 2012 +0100
> @@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
>      info->error = 0;
>      info->cpu = cpumask_first(&cpu_online_map);
>  
> +    if ( microcode_ops->start_update )
> +    {
> +	ret = microcode_ops->start_update();
> +	if ( ret != 0 )
> +        {
> +	    xfree(info);
> +	    return ret;
> +	}

Indentation (no tabs).

> +    }
> +
>      return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>  }
>  
> --- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/microcode_amd.c	Mon Jan 30 18:00:50 2012 +0100
> @@ -337,13 +341,18 @@ static int cpu_request_microcode(int cpu
>      /* On success keep the microcode patch for
>       * re-apply on resume.
>       */
> -    if (error == 1)
> +    if ( error == 1 )
>      {
>          xfree(mc_old);
> -        return 0;
> +        error = 0;
> +    } else 

    }
    else

> +    {
> +        xfree(mc_amd);
> +        uci->mc.mc_amd = mc_old;
>      }
> -    xfree(mc_amd);
> -    uci->mc.mc_amd = mc_old;
> +
> +  out:
> +    svm_host_osvw_init();
>  
>      return error;
>  }
> --- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/platform_hypercall.c	Mon Jan 30 18:00:50 2012 +0100
> @@ -166,7 +166,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>              break;
>  
>          guest_from_compat_handle(data, op->u.microcode.data);
> +
> +        while ( !domctl_lock_acquire() )

It's not clear to me what you're trying to protect against here. I don't
think this prevents guests from making progress (and hence possibly
seeing the intermediate [and wrong] OSVW state between
svm_host_osvw_reset() and svm_host_osvw_init()).

Jan

> +            if ( hypercall_preempt_check() )
> +            {
> +                ret = hypercall_create_continuation(
> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
> +                goto out;
> +            }
> +
>          ret = microcode_update(data, op->u.microcode.length);
> +        domctl_lock_release();
>      }
>      break;
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:20:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsAp2-0002Q0-5o; Tue, 31 Jan 2012 10:20:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAoz-0002Pr-VH
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:20:18 +0000
Received: from [85.158.138.51:38168] by server-4.bemta-3.messagelabs.com id
	36/07-32238-160C72F4; Tue, 31 Jan 2012 10:20:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328005216!11353762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30619 invoked from network); 31 Jan 2012 10:20:16 -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;
	31 Jan 2012 10:20:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:19: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;
	Tue, 31 Jan 2012 10:19:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:19:37 +0000
In-Reply-To: <d79c7a853c644d459cda.1327971910@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<d79c7a853c644d459cda.1327971910@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328005177.26983.332.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5 of 6] libxl: refactor migrate_domain and
 generalize migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971533 28800
> # Node ID d79c7a853c644d459cda93bf61657be48104cd63
> # Parent  efe92d80c47487485056266a1404a8d2817b7f09
> libxl: refactor migrate_domain and generalize migrate_receive
> 
> Refactor some tasks like establishing the migration channel,
> initial migration protocol exchange into separate functions,
> to facilitate re-use, when remus support is introduced. Also,
> make migrate_receive generic (instead of resorting to stdin and
> stdout as the file descriptors for communication).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r efe92d80c474 -r d79c7a853c64 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:47 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:53 2012 -0800
> @@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
>      exit(0);
>  }
>  
> +static pid_t create_migration_child(const char *rune, int *send_fd,
> +                                        int *recv_fd)
> +{
> +    int sendpipe[2], recvpipe[2];
> +    pid_t child = -1;
> +
> +    if (!rune || !send_fd || !recv_fd)
> +        return -1;
> +
> +    MUST( libxl_pipe(ctx, sendpipe) );
> +    MUST( libxl_pipe(ctx, recvpipe) );
> +
> +    child = libxl_fork(ctx);
> +    if (child==-1) exit(1);
> +
> +    if (!child) {
> +        dup2(sendpipe[0], 0);
> +        dup2(recvpipe[1], 1);
> +        close(sendpipe[0]); close(sendpipe[1]);
> +        close(recvpipe[0]); close(recvpipe[1]);
> +        execlp("sh","sh","-c",rune,(char*)0);
> +        perror("failed to exec sh");
> +        exit(-1);
> +    }
> +
> +    close(sendpipe[0]);
> +    close(recvpipe[1]);
> +    *send_fd = sendpipe[1];
> +    *recv_fd = recvpipe[0];
> +
> +    /* if receiver dies, we get an error and can clean up
> +       rather than just dying */
> +    signal(SIGPIPE, SIG_IGN);
> +
> +    return child;
> +}
> +
>  static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
>                                       const char *what, const char *rune) {
>      char buf[msgsz];
> @@ -2616,18 +2653,23 @@ static void migration_child_report(pid_t
>      migration_child = 0;
>  }
>  
> -static void migrate_domain(const char *domain_spec, const char *rune,
> -                           const char *override_config_file)
> +/* It is okay to have a NULL rune (we could be communicating over tcp sockets
> + * but not both NULL rune and NULL(send_fd, recv_fd).
> + */

The first check in the function ("Cannot create migration channel...")
seems to insist that both send_fd and recv_fd must be non-NULL without
reference to rune?

> +static void migrate_do_preamble(const char *domain_spec, const char *rune,
> +                                const char *override_config_file,
> +                                int *send_fd, int *recv_fd, pid_t *mchild)
>  {
> -    pid_t child = -1;
> -    int rc;
> -    int sendpipe[2], recvpipe[2];
> -    int send_fd, recv_fd;
> -    libxl_domain_suspend_info suspinfo;
> -    char *away_domname;
> -    char rc_buf;
> +    int rc = 0;
>      uint8_t *config_data;
>      int config_len;
> +    pid_t child = -1;
> +
> +    if (!send_fd || !recv_fd) {
> +        fprintf(stderr, "Cannot create migration channel:"
> +                "Null file descriptors supplied!\n");
> +        exit(1);
> +    }
>  
>      save_domain_core_begin(domain_spec, override_config_file,
>                             &config_data, &config_len);
> @@ -2638,43 +2680,44 @@ static void migrate_domain(const char *d
[...]
> +    if (*send_fd < 0 || *recv_fd < 0) {
> +        if (rune)
> +            child = create_migration_child(rune, send_fd, recv_fd);
> +        if (child < 0) {
> +            fprintf(stderr, "failed to create migration channel"
> +                    " - empty command ?\n");
> +            exit(1);
> +        }
> +    }

I think the migrate_domain function should contain:
	save_domain_core_begin
	create_migration_child(&rx_fd, &tx_fd) (or int fd[2])
	migrate_do_preamble(rx_fd, tx_fd) 

And that migrate_do_preamble should start at this point:

> +
> +    rc = migrate_read_fixedmessage(*recv_fd, migrate_receiver_banner,
>                                     sizeof(migrate_receiver_banner)-1,
>                                     "banner", rune);

Rather than trying to push the create_migration_child down into
migrate_do_preamble. I think that gives us sufficient building blocks
and shared code to do what you want or to add tcp support later etc.

> @@ -2798,7 +2841,12 @@ static void core_dump_domain(const char 
>      if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
>  }
>  
> -static void migrate_receive(int debug, int daemonize, int monitor)
> +/* Explicitly specifying a send & recv fd allows us to switch to a tcp socket
> + * based migration/replication channel in future, instead of exec/forking from
> + * an ssh channel.
> + */

I don't think you need to justify the use of send_fd/recv_fd in the
comment here, it seems natural to allow the caller to pass in the
communication fds for whatever reason and the commit message is a fine
place to mention your specific reasons for wanting it.

[...]
> @@ -2983,7 +3031,8 @@ int main_migrate_receive(int argc, char 
>          help("migrate-receive");
>          return 2;
>      }
> -    migrate_receive(debug, daemonize, monitor);
> +    migrate_receive(debug, daemonize, monitor,
> +                    /* write to stdout */1, /* read from stdin */0);

unistd.h defines STD{IN,OUT,ERR}_FILENO which would be useful here.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:20:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsAp2-0002Q0-5o; Tue, 31 Jan 2012 10:20:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsAoz-0002Pr-VH
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:20:18 +0000
Received: from [85.158.138.51:38168] by server-4.bemta-3.messagelabs.com id
	36/07-32238-160C72F4; Tue, 31 Jan 2012 10:20:17 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328005216!11353762!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30619 invoked from network); 31 Jan 2012 10:20:16 -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;
	31 Jan 2012 10:20:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384084"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:19: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;
	Tue, 31 Jan 2012 10:19:37 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:19:37 +0000
In-Reply-To: <d79c7a853c644d459cda.1327971910@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<d79c7a853c644d459cda.1327971910@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328005177.26983.332.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 5 of 6] libxl: refactor migrate_domain and
 generalize migrate_receive
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971533 28800
> # Node ID d79c7a853c644d459cda93bf61657be48104cd63
> # Parent  efe92d80c47487485056266a1404a8d2817b7f09
> libxl: refactor migrate_domain and generalize migrate_receive
> 
> Refactor some tasks like establishing the migration channel,
> initial migration protocol exchange into separate functions,
> to facilitate re-use, when remus support is introduced. Also,
> make migrate_receive generic (instead of resorting to stdin and
> stdout as the file descriptors for communication).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r efe92d80c474 -r d79c7a853c64 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:47 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:53 2012 -0800
> @@ -2531,6 +2531,43 @@ static int save_domain(const char *p, co
>      exit(0);
>  }
>  
> +static pid_t create_migration_child(const char *rune, int *send_fd,
> +                                        int *recv_fd)
> +{
> +    int sendpipe[2], recvpipe[2];
> +    pid_t child = -1;
> +
> +    if (!rune || !send_fd || !recv_fd)
> +        return -1;
> +
> +    MUST( libxl_pipe(ctx, sendpipe) );
> +    MUST( libxl_pipe(ctx, recvpipe) );
> +
> +    child = libxl_fork(ctx);
> +    if (child==-1) exit(1);
> +
> +    if (!child) {
> +        dup2(sendpipe[0], 0);
> +        dup2(recvpipe[1], 1);
> +        close(sendpipe[0]); close(sendpipe[1]);
> +        close(recvpipe[0]); close(recvpipe[1]);
> +        execlp("sh","sh","-c",rune,(char*)0);
> +        perror("failed to exec sh");
> +        exit(-1);
> +    }
> +
> +    close(sendpipe[0]);
> +    close(recvpipe[1]);
> +    *send_fd = sendpipe[1];
> +    *recv_fd = recvpipe[0];
> +
> +    /* if receiver dies, we get an error and can clean up
> +       rather than just dying */
> +    signal(SIGPIPE, SIG_IGN);
> +
> +    return child;
> +}
> +
>  static int migrate_read_fixedmessage(int fd, const void *msg, int msgsz,
>                                       const char *what, const char *rune) {
>      char buf[msgsz];
> @@ -2616,18 +2653,23 @@ static void migration_child_report(pid_t
>      migration_child = 0;
>  }
>  
> -static void migrate_domain(const char *domain_spec, const char *rune,
> -                           const char *override_config_file)
> +/* It is okay to have a NULL rune (we could be communicating over tcp sockets
> + * but not both NULL rune and NULL(send_fd, recv_fd).
> + */

The first check in the function ("Cannot create migration channel...")
seems to insist that both send_fd and recv_fd must be non-NULL without
reference to rune?

> +static void migrate_do_preamble(const char *domain_spec, const char *rune,
> +                                const char *override_config_file,
> +                                int *send_fd, int *recv_fd, pid_t *mchild)
>  {
> -    pid_t child = -1;
> -    int rc;
> -    int sendpipe[2], recvpipe[2];
> -    int send_fd, recv_fd;
> -    libxl_domain_suspend_info suspinfo;
> -    char *away_domname;
> -    char rc_buf;
> +    int rc = 0;
>      uint8_t *config_data;
>      int config_len;
> +    pid_t child = -1;
> +
> +    if (!send_fd || !recv_fd) {
> +        fprintf(stderr, "Cannot create migration channel:"
> +                "Null file descriptors supplied!\n");
> +        exit(1);
> +    }
>  
>      save_domain_core_begin(domain_spec, override_config_file,
>                             &config_data, &config_len);
> @@ -2638,43 +2680,44 @@ static void migrate_domain(const char *d
[...]
> +    if (*send_fd < 0 || *recv_fd < 0) {
> +        if (rune)
> +            child = create_migration_child(rune, send_fd, recv_fd);
> +        if (child < 0) {
> +            fprintf(stderr, "failed to create migration channel"
> +                    " - empty command ?\n");
> +            exit(1);
> +        }
> +    }

I think the migrate_domain function should contain:
	save_domain_core_begin
	create_migration_child(&rx_fd, &tx_fd) (or int fd[2])
	migrate_do_preamble(rx_fd, tx_fd) 

And that migrate_do_preamble should start at this point:

> +
> +    rc = migrate_read_fixedmessage(*recv_fd, migrate_receiver_banner,
>                                     sizeof(migrate_receiver_banner)-1,
>                                     "banner", rune);

Rather than trying to push the create_migration_child down into
migrate_do_preamble. I think that gives us sufficient building blocks
and shared code to do what you want or to add tcp support later etc.

> @@ -2798,7 +2841,12 @@ static void core_dump_domain(const char 
>      if (rc) { fprintf(stderr,"core dump failed (rc=%d)\n",rc);exit(-1); }
>  }
>  
> -static void migrate_receive(int debug, int daemonize, int monitor)
> +/* Explicitly specifying a send & recv fd allows us to switch to a tcp socket
> + * based migration/replication channel in future, instead of exec/forking from
> + * an ssh channel.
> + */

I don't think you need to justify the use of send_fd/recv_fd in the
comment here, it seems natural to allow the caller to pass in the
communication fds for whatever reason and the commit message is a fine
place to mention your specific reasons for wanting it.

[...]
> @@ -2983,7 +3031,8 @@ int main_migrate_receive(int argc, char 
>          help("migrate-receive");
>          return 2;
>      }
> -    migrate_receive(debug, daemonize, monitor);
> +    migrate_receive(debug, daemonize, monitor,
> +                    /* write to stdout */1, /* read from stdin */0);

unistd.h defines STD{IN,OUT,ERR}_FILENO which would be useful here.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:21:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:21:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsApt-0002T8-KD; Tue, 31 Jan 2012 10:21: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 1RsAps-0002Sg-Kq
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:21:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328005266!12816903!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12556 invoked from network); 31 Jan 2012 10:21:06 -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;
	31 Jan 2012 10:21:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:21: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, 31 Jan 2012 10:21:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:21:05 +0000
In-Reply-To: <ffc99e708e90eb140b0a.1327971911@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<ffc99e708e90eb140b0a.1327971911@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328005265.26983.333.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6 of 6] libxl: resume instead of unpause on
	xl save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971541 28800
> # Node ID ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
> # Parent  d79c7a853c644d459cda93bf61657be48104cd63
> libxl: resume instead of unpause on xl save -c
> 
> The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
> So call libxl_domain_resume instead of libxl_domain_unpause, when taking
> a checkpoint of the domain (using xl save -c).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Does checkpoint imply/require support for this resume mechanism?

> diff -r d79c7a853c64 -r ffc99e708e90 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:53 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:59:01 2012 -0800
> @@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
>      close(fd);
>  
>      if (checkpoint)
> -        libxl_domain_unpause(ctx, domid);
> +        libxl_domain_resume(ctx, domid, 1);
>      else
>          libxl_domain_destroy(ctx, domid);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:21:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:21:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsApt-0002T8-KD; Tue, 31 Jan 2012 10:21: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 1RsAps-0002Sg-Kq
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:21:12 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328005266!12816903!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12556 invoked from network); 31 Jan 2012 10:21:06 -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;
	31 Jan 2012 10:21:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384203"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:21: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, 31 Jan 2012 10:21:05 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:21:05 +0000
In-Reply-To: <ffc99e708e90eb140b0a.1327971911@athos.nss.cs.ubc.ca>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<ffc99e708e90eb140b0a.1327971911@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328005265.26983.333.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6 of 6] libxl: resume instead of unpause on
	xl save -c
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327971541 28800
> # Node ID ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
> # Parent  d79c7a853c644d459cda93bf61657be48104cd63
> libxl: resume instead of unpause on xl save -c
> 
> The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
> So call libxl_domain_resume instead of libxl_domain_unpause, when taking
> a checkpoint of the domain (using xl save -c).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>

Does checkpoint imply/require support for this resume mechanism?

> diff -r d79c7a853c64 -r ffc99e708e90 tools/libxl/xl_cmdimpl.c
> --- a/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:58:53 2012 -0800
> +++ b/tools/libxl/xl_cmdimpl.c	Mon Jan 30 16:59:01 2012 -0800
> @@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
>      close(fd);
>  
>      if (checkpoint)
> -        libxl_domain_unpause(ctx, domid);
> +        libxl_domain_resume(ctx, domid, 1);
>      else
>          libxl_domain_destroy(ctx, domid);
>  



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:24:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsAsW-0002dR-6m; Tue, 31 Jan 2012 10:23:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsAsV-0002dE-11
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:23:55 +0000
Received: from [85.158.138.51:31832] by server-7.bemta-3.messagelabs.com id
	97/17-31267-A31C72F4; Tue, 31 Jan 2012 10:23:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328005433!11173792!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28040 invoked from network); 31 Jan 2012 10:23:53 -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; 31 Jan 2012 10:23:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 10:23:52 +0000
Message-Id: <4F27CF440200007800070126@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 10:23:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <2717113.UZgetSD5rT@amur>
In-Reply-To: <2717113.UZgetSD5rT@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] msr: Use defines for bits of
 MSR_IA32_DEBUGCTLMSR instead of numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 09:42, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> # HG changeset patch
> # Parent e2722b24dc0962de37215320b05d1bb7c4c42864
> 
> Use defines for bits of MSR_IA32_DEBUGCTLMSR instead of numbers.

That would be nice, but only if done consistently everywhere (missing
at least xen/arch/x86/traps.c:ler_enable(); I'm surprise SVM code
doesn't appear to need any adjustment).

> Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> 
> diff -r e2722b24dc09 xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 31 09:40:31 2012 +0100
> @@ -1944,11 +1944,12 @@ static int vmx_msr_write_intercept(unsig
>          break;
>      case MSR_IA32_DEBUGCTLMSR: {
>          int i, rc = 0;
> -
> -        if ( !msr_content || (msr_content & ~3) )
> +        uint64_t allowed = MSR_IA32_DEBUGCTLMSR_LBR | 
> MSR_IA32_DEBUGCTLMSR_BTF;
> +
> +        if ( !msr_content || (msr_content & ~allowed) )
>              break;
>  
> -        if ( msr_content & 1 )
> +        if ( msr_content & MSR_IA32_DEBUGCTLMSR_LBR )
>          {
>              const struct lbr_info *lbr = last_branch_msr_get();
>              if ( lbr == NULL )
> diff -r e2722b24dc09 xen/include/asm-x86/msr-index.h
> --- a/xen/include/asm-x86/msr-index.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/msr-index.h	Tue Jan 31 09:40:31 2012 +0100
> @@ -64,12 +64,18 @@
>  #define MSR_MTRRfix4K_F8000		0x0000026f
>  #define MSR_MTRRdefType			0x000002ff
>  
> +/* MSR_IA32_DEBUGCTLMSR bits: */
> +#define _IA32_DEBUGCTLMSR_LBR		0 /* Last Branch Record */
> +#define _IA32_DEBUGCTLMSR_BTF		1 /* Single Step on Branches */
> +#define MSR_IA32_DEBUGCTLMSR_LBR	(1<<_IA32_DEBUGCTLMSR_LBR)
> +#define MSR_IA32_DEBUGCTLMSR_BTF	(1<<_IA32_DEBUGCTLMSR_BTF)
> +

Please no MSR_ prefix on values not representing MSR indices.

Also I personally prefer to have individual field definitions of an
MSR follow its index definition.

Jan

>  #define MSR_IA32_DEBUGCTLMSR		0x000001d9
>  #define MSR_IA32_LASTBRANCHFROMIP	0x000001db
>  #define MSR_IA32_LASTBRANCHTOIP		0x000001dc
>  #define MSR_IA32_LASTINTFROMIP		0x000001dd
>  #define MSR_IA32_LASTINTTOIP		0x000001de
> - 
> +
>  #define MSR_IA32_MTRR_PHYSBASE0     0x00000200
>  #define MSR_IA32_MTRR_PHYSMASK0     0x00000201
>  #define MSR_IA32_MTRR_PHYSBASE1     0x00000202



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:24:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsAsW-0002dR-6m; Tue, 31 Jan 2012 10:23:56 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsAsV-0002dE-11
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:23:55 +0000
Received: from [85.158.138.51:31832] by server-7.bemta-3.messagelabs.com id
	97/17-31267-A31C72F4; Tue, 31 Jan 2012 10:23:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328005433!11173792!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=UPPERCASE_25_50
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28040 invoked from network); 31 Jan 2012 10:23:53 -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; 31 Jan 2012 10:23:53 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 10:23:52 +0000
Message-Id: <4F27CF440200007800070126@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 10:23:48 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Dietmar Hahn" <dietmar.hahn@ts.fujitsu.com>
References: <2717113.UZgetSD5rT@amur>
In-Reply-To: <2717113.UZgetSD5rT@amur>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH] msr: Use defines for bits of
 MSR_IA32_DEBUGCTLMSR instead of numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 09:42, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote:
> # HG changeset patch
> # Parent e2722b24dc0962de37215320b05d1bb7c4c42864
> 
> Use defines for bits of MSR_IA32_DEBUGCTLMSR instead of numbers.

That would be nice, but only if done consistently everywhere (missing
at least xen/arch/x86/traps.c:ler_enable(); I'm surprise SVM code
doesn't appear to need any adjustment).

> Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
> 
> diff -r e2722b24dc09 xen/arch/x86/hvm/vmx/vmx.c
> --- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 31 09:40:31 2012 +0100
> @@ -1944,11 +1944,12 @@ static int vmx_msr_write_intercept(unsig
>          break;
>      case MSR_IA32_DEBUGCTLMSR: {
>          int i, rc = 0;
> -
> -        if ( !msr_content || (msr_content & ~3) )
> +        uint64_t allowed = MSR_IA32_DEBUGCTLMSR_LBR | 
> MSR_IA32_DEBUGCTLMSR_BTF;
> +
> +        if ( !msr_content || (msr_content & ~allowed) )
>              break;
>  
> -        if ( msr_content & 1 )
> +        if ( msr_content & MSR_IA32_DEBUGCTLMSR_LBR )
>          {
>              const struct lbr_info *lbr = last_branch_msr_get();
>              if ( lbr == NULL )
> diff -r e2722b24dc09 xen/include/asm-x86/msr-index.h
> --- a/xen/include/asm-x86/msr-index.h	Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/msr-index.h	Tue Jan 31 09:40:31 2012 +0100
> @@ -64,12 +64,18 @@
>  #define MSR_MTRRfix4K_F8000		0x0000026f
>  #define MSR_MTRRdefType			0x000002ff
>  
> +/* MSR_IA32_DEBUGCTLMSR bits: */
> +#define _IA32_DEBUGCTLMSR_LBR		0 /* Last Branch Record */
> +#define _IA32_DEBUGCTLMSR_BTF		1 /* Single Step on Branches */
> +#define MSR_IA32_DEBUGCTLMSR_LBR	(1<<_IA32_DEBUGCTLMSR_LBR)
> +#define MSR_IA32_DEBUGCTLMSR_BTF	(1<<_IA32_DEBUGCTLMSR_BTF)
> +

Please no MSR_ prefix on values not representing MSR indices.

Also I personally prefer to have individual field definitions of an
MSR follow its index definition.

Jan

>  #define MSR_IA32_DEBUGCTLMSR		0x000001d9
>  #define MSR_IA32_LASTBRANCHFROMIP	0x000001db
>  #define MSR_IA32_LASTBRANCHTOIP		0x000001dc
>  #define MSR_IA32_LASTINTFROMIP		0x000001dd
>  #define MSR_IA32_LASTINTTOIP		0x000001de
> - 
> +
>  #define MSR_IA32_MTRR_PHYSBASE0     0x00000200
>  #define MSR_IA32_MTRR_PHYSMASK0     0x00000201
>  #define MSR_IA32_MTRR_PHYSBASE1     0x00000202



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:24:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAtI-0002ic-MM; Tue, 31 Jan 2012 10:24: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 1RsAtH-0002hx-FL
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:24:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328005477!13073778!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3418 invoked from network); 31 Jan 2012 10:24:37 -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;
	31 Jan 2012 10:24:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:24: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;
	Tue, 31 Jan 2012 10:24:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 31 Jan 2012 10:24:36 +0000
In-Reply-To: <1327934734-8908-6-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-6-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328005476.26983.335.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>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 05/16] netback: add module get/put
 operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 14:45 +0000, Wei Liu wrote:
> If there is vif running and user unloads netback, it will certainly
> cause problems -- guest's network interface just mysteriously stops
> working.

This seems like a bug fix for  02/16 "netback: add module unload
function". Please could you fold back such fixes where appropriate? I
think there's a handful of these sorts of patches in the series.

> v2: fix module_put path
> 
> disconnect function may get called by the generic framework even
> before vif connects.
> 
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netback/interface.c |   11 ++++++++++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index dfc04f8..7914f60 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>  	if (vif->irq)
>  		return 0;
>  
> +	__module_get(THIS_MODULE);
> +
>  	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
>  	if (err < 0)
>  		goto err;
> @@ -372,12 +374,14 @@ err_unbind:
>  err_unmap:
>  	xen_netbk_unmap_frontend_rings(vif);
>  err:
> +	module_put(THIS_MODULE);
>  	return err;
>  }
>  
>  void xenvif_disconnect(struct xenvif *vif)
>  {
>  	struct net_device *dev = vif->dev;
> +	int need_module_put = 0;
>  
>  	if (netif_carrier_ok(dev)) {
>  		rtnl_lock();
> @@ -397,12 +401,17 @@ void xenvif_disconnect(struct xenvif *vif)
>  
>  	del_timer_sync(&vif->credit_timeout);
>  
> -	if (vif->irq)
> +	if (vif->irq) {
>  		unbind_from_irqhandler(vif->irq, vif);
> +		need_module_put = 1;

This seems like a slightly odd condition. Why is the put not
unconditional?


> +	}
>  
>  	unregister_netdev(vif->dev);
>  
>  	xen_netbk_unmap_frontend_rings(vif);
>  
>  	free_netdev(vif->dev);
> +
> +	if (need_module_put)
> +		module_put(THIS_MODULE);
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:24:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:24:57 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsAtI-0002ic-MM; Tue, 31 Jan 2012 10:24: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 1RsAtH-0002hx-FL
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:24:43 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328005477!13073778!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3418 invoked from network); 31 Jan 2012 10:24:37 -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;
	31 Jan 2012 10:24:37 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:24: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;
	Tue, 31 Jan 2012 10:24:36 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 31 Jan 2012 10:24:36 +0000
In-Reply-To: <1327934734-8908-6-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-6-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328005476.26983.335.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>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 05/16] netback: add module get/put
 operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 14:45 +0000, Wei Liu wrote:
> If there is vif running and user unloads netback, it will certainly
> cause problems -- guest's network interface just mysteriously stops
> working.

This seems like a bug fix for  02/16 "netback: add module unload
function". Please could you fold back such fixes where appropriate? I
think there's a handful of these sorts of patches in the series.

> v2: fix module_put path
> 
> disconnect function may get called by the generic framework even
> before vif connects.
> 
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netback/interface.c |   11 ++++++++++-
>  1 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index dfc04f8..7914f60 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
>  	if (vif->irq)
>  		return 0;
>  
> +	__module_get(THIS_MODULE);
> +
>  	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
>  	if (err < 0)
>  		goto err;
> @@ -372,12 +374,14 @@ err_unbind:
>  err_unmap:
>  	xen_netbk_unmap_frontend_rings(vif);
>  err:
> +	module_put(THIS_MODULE);
>  	return err;
>  }
>  
>  void xenvif_disconnect(struct xenvif *vif)
>  {
>  	struct net_device *dev = vif->dev;
> +	int need_module_put = 0;
>  
>  	if (netif_carrier_ok(dev)) {
>  		rtnl_lock();
> @@ -397,12 +401,17 @@ void xenvif_disconnect(struct xenvif *vif)
>  
>  	del_timer_sync(&vif->credit_timeout);
>  
> -	if (vif->irq)
> +	if (vif->irq) {
>  		unbind_from_irqhandler(vif->irq, vif);
> +		need_module_put = 1;

This seems like a slightly odd condition. Why is the put not
unconditional?


> +	}
>  
>  	unregister_netdev(vif->dev);
>  
>  	xen_netbk_unmap_frontend_rings(vif);
>  
>  	free_netdev(vif->dev);
> +
> +	if (need_module_put)
> +		module_put(THIS_MODULE);
>  }



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:36:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsB3w-00033m-Ft; Tue, 31 Jan 2012 10:35:44 +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 1RsB3u-00033h-W5
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:35:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328006083!54724620!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12502 invoked from network); 31 Jan 2012 10:34:44 -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;
	31 Jan 2012 10:34:44 -0000
Received: by pbds6 with SMTP id s6so417967pbd.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 02:35: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=oLT+p9KOYP+kG6cGD8jf6p1olXyC+5IKRVhTuCbjZRg=;
	b=uzTkojBcFtjPN6Md9/8ZSVR86/Ckq8CJpvbp9pXn9QOouK6ARSpXMnccVA8S6tCq/J
	LCmNeT+dn7MnAnhWp57CY8m1vCSk7KWOAqZGEXuCXWiZHttzeFMh6l52POk4ZpT1G8OF
	oYQG3YFsp26YYz3z6Zv2FF5ptqgOJVdOGU2KA=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr49524184pbc.5.1328006136742; Tue,
	31 Jan 2012 02:35:36 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Tue, 31 Jan 2012 02:35:36 -0800 (PST)
In-Reply-To: <4F27C2CE.30702@redhat.com>
References: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
	<4F27C2CE.30702@redhat.com>
Date: Tue, 31 Jan 2012 11:35:36 +0100
X-Google-Sender-Auth: IP4Rk7eXwPJLwUx79mA9HdBkW30
Message-ID: <CAPLaKK47wwd1BtGUswOMW3VcwO6PL6YsUVZMB58roCsooM3cVA@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
Subject: Re: [Xen-devel] How to get DomU id from 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

MjAxMi8xLzMxIExhc3psbyBFcnNlayA8bGVyc2VrQHJlZGhhdC5jb20+Ogo+IE9uIDAxLzMxLzEy
IDExOjAxLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Cj4+IFRoaXMgaXMgcXVpdGUgYSB0cml2
aWFsIHF1ZXN0aW9uLCBidXQgSSBoYXZlbid0IGJlZW4gYWJsZSB0byBmaW5kIGhvdwo+PiB0byBk
byBpdC4gSXMgdGhlcmUgYW55d2F5IHRvIGdldCB0aGUgaWQgb2YgYSBQViBEb21VIGZyb20gaW5z
aWRlIHRoZQo+PiAoc2FtZSkgUFYgRG9tVT8KPgo+Cj4gSGVyZSdzIGEgaGFjayAodW50ZXN0ZWQp
OiBvbmUgY291bGQgY3JlYXRlIGEgbG9vcCBldmVudCBjaGFubmVsIHdpdGgKPiBFVlRDSE5PUF9i
aW5kX2ludGVyZG9tYWluIChwYXNzaW5nIGluIERPTUlEX1NFTEYgYXMgcmVtb3RlX2RvbSksIHRo
ZW4gcXVlcnkKPiBpdCB3aXRoIEVWVENITk9QX3N0YXR1cyAoYWxzbyBwYXNzaW5nIGluIERPTUlE
X1NFTEYpLiBPbiByZXR1cm4sCj4gImludGVyZG9tYWluLmRvbSIgKD0gdGhlIHJlbW90ZSBlbmQp
IHNob3VsZCBoYXZlIHRoZSByZWFsIGRvbWlkLgoKVGhhbmtzLCBzdXJlIHRoYXQgbG9va3MgcXVp
dGUgaGFja2lzaCwgdGhlcmUncyBubyBvdGhlciB3YXkgdG8gZG8gaXQ/CkkgbmVlZCB0byBrbm93
IHRoZSBkb20gaWQgdG8gc2V0IHRoZSBjb3JyZWN0IHdhdGNoZXMgb24geGVuc3RvcmUgZm9yCmRy
aXZlciBkb21haW5zLiBFYWNoIGRyaXZlciBkb21haW4gc2hvdWxkIHdhdGNoIGEgc3BlY2lmaWMg
cGF0aCBpbgp4ZW5zdG9yZSwgdGhhdCBpcyBkZXRlcm1pbmVkIGJhc2VkIG9uIHRoZSBpZCBvZiB0
aGUgZG9tYWluIGl0c2VsZi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:36:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10: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 1RsB3w-00033m-Ft; Tue, 31 Jan 2012 10:35:44 +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 1RsB3u-00033h-W5
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:35:43 +0000
X-Env-Sender: royger@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328006083!54724620!1
X-Originating-IP: [209.85.160.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12502 invoked from network); 31 Jan 2012 10:34:44 -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;
	31 Jan 2012 10:34:44 -0000
Received: by pbds6 with SMTP id s6so417967pbd.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 02:35: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=oLT+p9KOYP+kG6cGD8jf6p1olXyC+5IKRVhTuCbjZRg=;
	b=uzTkojBcFtjPN6Md9/8ZSVR86/Ckq8CJpvbp9pXn9QOouK6ARSpXMnccVA8S6tCq/J
	LCmNeT+dn7MnAnhWp57CY8m1vCSk7KWOAqZGEXuCXWiZHttzeFMh6l52POk4ZpT1G8OF
	oYQG3YFsp26YYz3z6Zv2FF5ptqgOJVdOGU2KA=
MIME-Version: 1.0
Received: by 10.68.219.69 with SMTP id pm5mr49524184pbc.5.1328006136742; Tue,
	31 Jan 2012 02:35:36 -0800 (PST)
Received: by 10.142.252.8 with HTTP; Tue, 31 Jan 2012 02:35:36 -0800 (PST)
In-Reply-To: <4F27C2CE.30702@redhat.com>
References: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
	<4F27C2CE.30702@redhat.com>
Date: Tue, 31 Jan 2012 11:35:36 +0100
X-Google-Sender-Auth: IP4Rk7eXwPJLwUx79mA9HdBkW30
Message-ID: <CAPLaKK47wwd1BtGUswOMW3VcwO6PL6YsUVZMB58roCsooM3cVA@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
Subject: Re: [Xen-devel] How to get DomU id from 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

MjAxMi8xLzMxIExhc3psbyBFcnNlayA8bGVyc2VrQHJlZGhhdC5jb20+Ogo+IE9uIDAxLzMxLzEy
IDExOjAxLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+Cj4+IFRoaXMgaXMgcXVpdGUgYSB0cml2
aWFsIHF1ZXN0aW9uLCBidXQgSSBoYXZlbid0IGJlZW4gYWJsZSB0byBmaW5kIGhvdwo+PiB0byBk
byBpdC4gSXMgdGhlcmUgYW55d2F5IHRvIGdldCB0aGUgaWQgb2YgYSBQViBEb21VIGZyb20gaW5z
aWRlIHRoZQo+PiAoc2FtZSkgUFYgRG9tVT8KPgo+Cj4gSGVyZSdzIGEgaGFjayAodW50ZXN0ZWQp
OiBvbmUgY291bGQgY3JlYXRlIGEgbG9vcCBldmVudCBjaGFubmVsIHdpdGgKPiBFVlRDSE5PUF9i
aW5kX2ludGVyZG9tYWluIChwYXNzaW5nIGluIERPTUlEX1NFTEYgYXMgcmVtb3RlX2RvbSksIHRo
ZW4gcXVlcnkKPiBpdCB3aXRoIEVWVENITk9QX3N0YXR1cyAoYWxzbyBwYXNzaW5nIGluIERPTUlE
X1NFTEYpLiBPbiByZXR1cm4sCj4gImludGVyZG9tYWluLmRvbSIgKD0gdGhlIHJlbW90ZSBlbmQp
IHNob3VsZCBoYXZlIHRoZSByZWFsIGRvbWlkLgoKVGhhbmtzLCBzdXJlIHRoYXQgbG9va3MgcXVp
dGUgaGFja2lzaCwgdGhlcmUncyBubyBvdGhlciB3YXkgdG8gZG8gaXQ/CkkgbmVlZCB0byBrbm93
IHRoZSBkb20gaWQgdG8gc2V0IHRoZSBjb3JyZWN0IHdhdGNoZXMgb24geGVuc3RvcmUgZm9yCmRy
aXZlciBkb21haW5zLiBFYWNoIGRyaXZlciBkb21haW4gc2hvdWxkIHdhdGNoIGEgc3BlY2lmaWMg
cGF0aCBpbgp4ZW5zdG9yZSwgdGhhdCBpcyBkZXRlcm1pbmVkIGJhc2VkIG9uIHRoZSBpZCBvZiB0
aGUgZG9tYWluIGl0c2VsZi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5nIGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJj
ZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJjZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:36:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB4X-00035s-TH; Tue, 31 Jan 2012 10:36:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RsB4W-00035g-Mt
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:36:20 +0000
Received: from [85.158.138.51:16977] by server-10.bemta-3.messagelabs.com id
	87/21-20948-324C72F4; Tue, 31 Jan 2012 10:36:19 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328006178!7162468!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27631 invoked from network); 31 Jan 2012 10:36:19 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	31 Jan 2012 10:36:19 -0000
Received: from mail17-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 31 Jan 2012 10:36:18 +0000
Received: from mail17-am1 (localhost [127.0.0.1])	by mail17-am1-R.bigfish.com
	(Postfix) with ESMTP id 954CC3203A5;
	Tue, 31 Jan 2012 10:36:18 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h)
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 mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1
	(MessageSwitch) id 1328006176407302_21342;
	Tue, 31 Jan 2012 10:36:16 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.235])	by
	mail17-am1.bigfish.com (Postfix) with ESMTP id 56F0B2A0045;
	Tue, 31 Jan 2012 10:36:16 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server id
	14.1.225.23; Tue, 31 Jan 2012 10:36:11 +0000
X-WSS-ID: 0LYNS4A-01-2M6-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 2FC6A10280DA;	Tue, 31 Jan 2012 04:36:09 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 31 Jan 2012 04:36:17 -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, 31 Jan 2012 04:36:09 -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, 31 Jan 2012
	05:36:08 -0500
Message-ID: <4F27C417.2070209@amd.com>
Date: Tue, 31 Jan 2012 11:36:07 +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: <1361d9895cb17aa8fce1.1327943146@wotan.osrc.amd.com>
	<4F27CCE40200007800070120@nat28.tlf.novell.com>
In-Reply-To: <4F27CCE40200007800070120@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, xen-devel@lists.xensource.com,
	keir@xen.org
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/12 11:13, Jan Beulich wrote:
>> --- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
>> +++ b/xen/arch/x86/platform_hypercall.c	Mon Jan 30 18:00:50 2012 +0100
>> @@ -166,7 +166,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>>               break;
>>
>>           guest_from_compat_handle(data, op->u.microcode.data);
>> +
>> +        while ( !domctl_lock_acquire() )
>
> It's not clear to me what you're trying to protect against here. I don't
> think this prevents guests from making progress (and hence possibly
> seeing the intermediate [and wrong] OSVW state between
> svm_host_osvw_reset() and svm_host_osvw_init()).

The reason is because when we allocated VCPUs (via XEN_DOMCTL_max_vcpus 
and possibly other controls) we call svm_vcpu_initialise() -> 
svm_guest_osvw_init(). If we are in the middle of microcode update then 
osvw_length/osvw_status may be in an inconsistent state.

Christoph

> Jan
>
>> +            if ( hypercall_preempt_check() )
>> +            {
>> +                ret = hypercall_create_continuation(
>> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
>> +                goto out;
>> +            }
>> +
>>           ret = microcode_update(data, op->u.microcode.length);
>> +        domctl_lock_release();
>>       }
>>       break;
>>
>
>
>


-- 
---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 Jan 31 10:36:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:36:32 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB4X-00035s-TH; Tue, 31 Jan 2012 10:36:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Christoph.Egger@amd.com>) id 1RsB4W-00035g-Mt
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:36:20 +0000
Received: from [85.158.138.51:16977] by server-10.bemta-3.messagelabs.com id
	87/21-20948-324C72F4; Tue, 31 Jan 2012 10:36:19 +0000
X-Env-Sender: Christoph.Egger@amd.com
X-Msg-Ref: server-7.tower-174.messagelabs.com!1328006178!7162468!1
X-Originating-IP: [213.199.154.209]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27631 invoked from network); 31 Jan 2012 10:36:19 -0000
Received: from am1ehsobe006.messaging.microsoft.com (HELO
	AM1EHSOBE006.bigfish.com) (213.199.154.209)
	by server-7.tower-174.messagelabs.com with AES128-SHA encrypted SMTP;
	31 Jan 2012 10:36:19 -0000
Received: from mail17-am1-R.bigfish.com (10.3.201.253) by
	AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id
	14.1.225.23; Tue, 31 Jan 2012 10:36:18 +0000
Received: from mail17-am1 (localhost [127.0.0.1])	by mail17-am1-R.bigfish.com
	(Postfix) with ESMTP id 954CC3203A5;
	Tue, 31 Jan 2012 10:36:18 +0000 (UTC)
X-SpamScore: -10
X-BigFish: VPS-10(zzbb2dI1432N98dKzz1202hzzz2dhc1bhc31hc1ah668h839h)
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 mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1
	(MessageSwitch) id 1328006176407302_21342;
	Tue, 31 Jan 2012 10:36:16 +0000 (UTC)
Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.235])	by
	mail17-am1.bigfish.com (Postfix) with ESMTP id 56F0B2A0045;
	Tue, 31 Jan 2012 10:36:16 +0000 (UTC)
Received: from ausb3twp01.amd.com (163.181.249.108) by
	AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server id
	14.1.225.23; Tue, 31 Jan 2012 10:36:11 +0000
X-WSS-ID: 0LYNS4A-01-2M6-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 2FC6A10280DA;	Tue, 31 Jan 2012 04:36:09 -0600 (CST)
Received: from SAUSEXDAG02.amd.com (163.181.55.2) by sausexedgep02.amd.com
	(163.181.36.59) with Microsoft SMTP Server (TLS) id 8.3.192.1;
	Tue, 31 Jan 2012 04:36:17 -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, 31 Jan 2012 04:36:09 -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, 31 Jan 2012
	05:36:08 -0500
Message-ID: <4F27C417.2070209@amd.com>
Date: Tue, 31 Jan 2012 11:36:07 +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: <1361d9895cb17aa8fce1.1327943146@wotan.osrc.amd.com>
	<4F27CCE40200007800070120@nat28.tlf.novell.com>
In-Reply-To: <4F27CCE40200007800070120@nat28.tlf.novell.com>
X-OriginatorOrg: amd.com
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, xen-devel@lists.xensource.com,
	keir@xen.org
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/12 11:13, Jan Beulich wrote:
>> --- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
>> +++ b/xen/arch/x86/platform_hypercall.c	Mon Jan 30 18:00:50 2012 +0100
>> @@ -166,7 +166,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>>               break;
>>
>>           guest_from_compat_handle(data, op->u.microcode.data);
>> +
>> +        while ( !domctl_lock_acquire() )
>
> It's not clear to me what you're trying to protect against here. I don't
> think this prevents guests from making progress (and hence possibly
> seeing the intermediate [and wrong] OSVW state between
> svm_host_osvw_reset() and svm_host_osvw_init()).

The reason is because when we allocated VCPUs (via XEN_DOMCTL_max_vcpus 
and possibly other controls) we call svm_vcpu_initialise() -> 
svm_guest_osvw_init(). If we are in the middle of microcode update then 
osvw_length/osvw_status may be in an inconsistent state.

Christoph

> Jan
>
>> +            if ( hypercall_preempt_check() )
>> +            {
>> +                ret = hypercall_create_continuation(
>> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
>> +                goto out;
>> +            }
>> +
>>           ret = microcode_update(data, op->u.microcode.length);
>> +        domctl_lock_release();
>>       }
>>       break;
>>
>
>
>


-- 
---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 Jan 31 10:36:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB4j-00037B-Az; Tue, 31 Jan 2012 10:36:33 +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 1RsB4h-00036I-Gg
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:36:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328006182!13072611!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10761 invoked from network); 31 Jan 2012 10:36:23 -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; 31 Jan 2012 10:36:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 10:36:21 +0000
Message-Id: <4F27D232020000780007012B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 10:36:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <4F27B5AD.9050709@redhat.com>
In-Reply-To: <4F27B5AD.9050709@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Petr Matousek <pmatouse@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 10:34, Laszlo Ersek <lersek@redhat.com> wrote:
> in the qemu-xen-unstable tree 
> (git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function 
> [i386-dm/helper2.c] makes the process exit if the operand size is wrong. 
> Blame: 6040eea5 ("More files imported from xen-unstable 
> 17192:59b8768d0d0d").
> 
> In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function 
> [xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c 
> ("xen: Initialize event channels and io rings").
> 
> Is it justified to kill the emulator when this happens (eg. memory 
> mapped IO with 64-bit operand)?

Afaict, this is not about MMIO, but PIO.

> What would happen on real hardware? If 
> it's "undefined", wouldn't it be "better" (for some definition of 
> "better") to return a constant?

The AMD manual specifies that REX.W is ignored; the Intel manual
doesn't mention REX at all here. However, if a decoder incorrectly
decodes the guest instruction, that's a bug there. So imo qemu
validly treats this condition as fatal.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:36:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:36:47 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB4j-00037B-Az; Tue, 31 Jan 2012 10:36:33 +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 1RsB4h-00036I-Gg
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:36:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328006182!13072611!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10761 invoked from network); 31 Jan 2012 10:36:23 -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; 31 Jan 2012 10:36:23 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 10:36:21 +0000
Message-Id: <4F27D232020000780007012B@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 10:36:18 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <4F27B5AD.9050709@redhat.com>
In-Reply-To: <4F27B5AD.9050709@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Petr Matousek <pmatouse@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 10:34, Laszlo Ersek <lersek@redhat.com> wrote:
> in the qemu-xen-unstable tree 
> (git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function 
> [i386-dm/helper2.c] makes the process exit if the operand size is wrong. 
> Blame: 6040eea5 ("More files imported from xen-unstable 
> 17192:59b8768d0d0d").
> 
> In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function 
> [xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c 
> ("xen: Initialize event channels and io rings").
> 
> Is it justified to kill the emulator when this happens (eg. memory 
> mapped IO with 64-bit operand)?

Afaict, this is not about MMIO, but PIO.

> What would happen on real hardware? If 
> it's "undefined", wouldn't it be "better" (for some definition of 
> "better") to return a constant?

The AMD manual specifies that REX.W is ignored; the Intel manual
doesn't mention REX at all here. However, if a decoder incorrectly
decodes the guest instruction, that's a bug there. So imo qemu
validly treats this condition as fatal.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:37:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:37:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB5S-0003EH-Pc; Tue, 31 Jan 2012 10:37: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 1RsB5Q-0003D3-Eh
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:37:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328006230!14642444!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19089 invoked from network); 31 Jan 2012 10:37:10 -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;
	31 Jan 2012 10:37:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:37:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:37:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 31 Jan 2012 10:37:09 +0000
In-Reply-To: <1327934734-8908-15-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-15-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328006229.26983.343.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>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 14/16] netback: split event channels
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 14:45 +0000, Wei Liu wrote:
> Originally, netback and netfront only use one event channel to do tx /
> rx notification. This may cause unnecessary wake-up of NAPI / kthread.
> 
> When guest tx is completed, netback will only notify tx_irq.
> 
> Also modify xenvif_protocol0 to reflect this change. Rx protocol
> only notifies rx_irq.
> 
> If split-event-channels feature is not activated, rx_irq = tx_irq, so
> RX protocol will just work as expected.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netback/common.h              |    9 ++-
>  drivers/net/xen-netback/interface.c           |   90 ++++++++++++++++++++-----
>  drivers/net/xen-netback/netback.c             |    2 +-
>  drivers/net/xen-netback/xenbus.c              |   52 ++++++++++++---
>  drivers/net/xen-netback/xenvif_rx_protocol0.c |    2 +-
>  5 files changed, 123 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index f3d95b3..376f0bf 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -100,8 +100,10 @@ struct xenvif {
>  
>  	u8               fe_dev_addr[6];
>  
> -	/* Physical parameters of the comms window. */
> -	unsigned int     irq;
> +	/* when split_irq == 0, only use tx_irq */
> +	int              split_irq;
> +	unsigned int     tx_irq;
> +	unsigned int     rx_irq;

Can you get rid of split_irq by setting tx_irq == rx_irq in that case
and simplify the code by doing so?

I think this should work even for places like:

	if (!vif->split_irq)
		enable_irq(vif->tx_irq);
	else {
		enable_irq(vif->tx_irq);
		enable_irq(vif->rx_irq);
	}

Just by doing
		enable_irq(vif->tx_irq);
		enable_irq(vif->rx_irq);

Since enable/disable_irq maintain a count and so it will do the right
thing if they happen to be the same.

>  	/* The shared tx ring and index. */
>  	struct xen_netif_tx_back_ring tx;
> @@ -162,7 +164,8 @@ struct xenvif *xenvif_alloc(struct device *parent,
>  int xenvif_connect(struct xenvif *vif,
>  		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
>  		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
> -		   unsigned int evtchn, unsigned int rx_protocol);
> +		   unsigned int evtchn[], int split_evtchn,
> +		   unsigned int rx_protocol);
>  void xenvif_disconnect(struct xenvif *vif);
>  
>  int xenvif_xenbus_init(void);
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 0f05f03..afccd5d 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -46,15 +46,31 @@ int xenvif_schedulable(struct xenvif *vif)
>  	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
>  }
>  
> -static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> +static irqreturn_t xenvif_tx_interrupt(int irq, void *dev_id)
> +{
> +	struct xenvif *vif = dev_id;
> +
> +	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
> +		napi_schedule(&vif->napi);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
>  {
>  	struct xenvif *vif = dev_id;
>  
>  	if (xenvif_schedulable(vif) && vif->event != NULL)
>  		vif->event(vif);
>  
> -	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
> -		napi_schedule(&vif->napi);
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> +{
> +	xenvif_tx_interrupt(0, dev_id);

Might as well pass irq down.
[...]
> @@ -308,13 +334,14 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
>  int xenvif_connect(struct xenvif *vif,
>  		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
>  		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
> -		   unsigned int evtchn, unsigned int rx_protocol)
> +		   unsigned int evtchn[], int split_evtchn,

Explicitly tx_evtchn and rx_evtchn would be clearer than remembering
that [0]==tx and [1]==rx I think.

> +		   unsigned int rx_protocol)
>  {
>  	int err = -ENOMEM;
>  	struct xen_netif_tx_sring *txs;
>  
>  	/* Already connected through? */
> -	if (vif->irq)
> +	if (vif->tx_irq)
>  		return 0;
>  
>  	__module_get(THIS_MODULE);
> @@ -345,13 +372,35 @@ int xenvif_connect(struct xenvif *vif,
>  	if (vif->setup(vif))
>  		goto err_rx_unmap;
>  
> -	err = bind_interdomain_evtchn_to_irqhandler(
> -		vif->domid, evtchn, xenvif_interrupt, 0,
> -		vif->dev->name, vif);
> -	if (err < 0)
> -		goto err_rx_unmap;
> -	vif->irq = err;
> -	disable_irq(vif->irq);
> +	if (!split_evtchn) {

Presumably this is one of the places where you do have to care about
split vs non. I did consider whether simply registering two handlers for
the interrupt in a shared-interrupt style would work, but I think that
way lies madness and confusion...

> +		err = bind_interdomain_evtchn_to_irqhandler(
> +			vif->domid, evtchn[0], xenvif_interrupt, 0,
> +			vif->dev->name, vif);
> +		if (err < 0)
> +			goto err_rx_unmap;
> +		vif->tx_irq = vif->rx_irq = err;
> +		disable_irq(vif->tx_irq);
> +		vif->split_irq = 0;
> +	} else {
> +		err = bind_interdomain_evtchn_to_irqhandler(
> +			vif->domid, evtchn[0], xenvif_tx_interrupt,
> +			0, vif->dev->name, vif);
> +		if (err < 0)
> +			goto err_rx_unmap;
> +		vif->tx_irq = err;
> +		disable_irq(vif->tx_irq);
> +
> +		err = bind_interdomain_evtchn_to_irqhandler(
> +			vif->domid, evtchn[1], xenvif_rx_interrupt,
> +			0, vif->dev->name, vif);
> +		if (err < 0) {
> +			unbind_from_irqhandler(vif->tx_irq, vif);
> +			goto err_rx_unmap;
> +		}
> +		vif->rx_irq = err;
> +		disable_irq(vif->rx_irq);
> +		vif->split_irq = 1;
> +	}
>  
>  	init_waitqueue_head(&vif->wq);
>  	vif->task = kthread_create(xenvif_kthread,
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 4067286..c5a3b27 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -131,6 +131,14 @@ static int netback_probe(struct xenbus_device *dev,
>  			goto abort_transaction;
>  		}
>  
> +		err = xenbus_printf(xbt, dev->nodename,
> +				    "split-event-channels",

Usually we use "feature-FOO" as the names for these sorts of nodes.

> +				    "%u", 1);
> +		if (err) {
> +			message = "writing split-event-channels";
> +			goto abort_transaction;
> +		}
> +
>  		err = xenbus_transaction_end(xbt, 0);
>  	} while (err == -EAGAIN);
>  
> @@ -408,7 +416,7 @@ static int connect_rings(struct backend_info *be)
>  {
>  	struct xenvif *vif = be->vif;
>  	struct xenbus_device *dev = be->dev;
> -	unsigned int evtchn, rx_copy;
> +	unsigned int evtchn[2], split_evtchn, rx_copy;

Another case where I think two vars is better than a small array.

>  	int err;
>  	int val;
>  	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:37:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:37:29 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB5S-0003EH-Pc; Tue, 31 Jan 2012 10:37: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 1RsB5Q-0003D3-Eh
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:37:16 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328006230!14642444!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19089 invoked from network); 31 Jan 2012 10:37:10 -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;
	31 Jan 2012 10:37:10 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384760"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:37:10 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:37:09 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Date: Tue, 31 Jan 2012 10:37:09 +0000
In-Reply-To: <1327934734-8908-15-git-send-email-wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-15-git-send-email-wei.liu2@citrix.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328006229.26983.343.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>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 14/16] netback: split event channels
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 14:45 +0000, Wei Liu wrote:
> Originally, netback and netfront only use one event channel to do tx /
> rx notification. This may cause unnecessary wake-up of NAPI / kthread.
> 
> When guest tx is completed, netback will only notify tx_irq.
> 
> Also modify xenvif_protocol0 to reflect this change. Rx protocol
> only notifies rx_irq.
> 
> If split-event-channels feature is not activated, rx_irq = tx_irq, so
> RX protocol will just work as expected.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  drivers/net/xen-netback/common.h              |    9 ++-
>  drivers/net/xen-netback/interface.c           |   90 ++++++++++++++++++++-----
>  drivers/net/xen-netback/netback.c             |    2 +-
>  drivers/net/xen-netback/xenbus.c              |   52 ++++++++++++---
>  drivers/net/xen-netback/xenvif_rx_protocol0.c |    2 +-
>  5 files changed, 123 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index f3d95b3..376f0bf 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -100,8 +100,10 @@ struct xenvif {
>  
>  	u8               fe_dev_addr[6];
>  
> -	/* Physical parameters of the comms window. */
> -	unsigned int     irq;
> +	/* when split_irq == 0, only use tx_irq */
> +	int              split_irq;
> +	unsigned int     tx_irq;
> +	unsigned int     rx_irq;

Can you get rid of split_irq by setting tx_irq == rx_irq in that case
and simplify the code by doing so?

I think this should work even for places like:

	if (!vif->split_irq)
		enable_irq(vif->tx_irq);
	else {
		enable_irq(vif->tx_irq);
		enable_irq(vif->rx_irq);
	}

Just by doing
		enable_irq(vif->tx_irq);
		enable_irq(vif->rx_irq);

Since enable/disable_irq maintain a count and so it will do the right
thing if they happen to be the same.

>  	/* The shared tx ring and index. */
>  	struct xen_netif_tx_back_ring tx;
> @@ -162,7 +164,8 @@ struct xenvif *xenvif_alloc(struct device *parent,
>  int xenvif_connect(struct xenvif *vif,
>  		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
>  		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
> -		   unsigned int evtchn, unsigned int rx_protocol);
> +		   unsigned int evtchn[], int split_evtchn,
> +		   unsigned int rx_protocol);
>  void xenvif_disconnect(struct xenvif *vif);
>  
>  int xenvif_xenbus_init(void);
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 0f05f03..afccd5d 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -46,15 +46,31 @@ int xenvif_schedulable(struct xenvif *vif)
>  	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
>  }
>  
> -static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> +static irqreturn_t xenvif_tx_interrupt(int irq, void *dev_id)
> +{
> +	struct xenvif *vif = dev_id;
> +
> +	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
> +		napi_schedule(&vif->napi);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
>  {
>  	struct xenvif *vif = dev_id;
>  
>  	if (xenvif_schedulable(vif) && vif->event != NULL)
>  		vif->event(vif);
>  
> -	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
> -		napi_schedule(&vif->napi);
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> +{
> +	xenvif_tx_interrupt(0, dev_id);

Might as well pass irq down.
[...]
> @@ -308,13 +334,14 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
>  int xenvif_connect(struct xenvif *vif,
>  		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
>  		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
> -		   unsigned int evtchn, unsigned int rx_protocol)
> +		   unsigned int evtchn[], int split_evtchn,

Explicitly tx_evtchn and rx_evtchn would be clearer than remembering
that [0]==tx and [1]==rx I think.

> +		   unsigned int rx_protocol)
>  {
>  	int err = -ENOMEM;
>  	struct xen_netif_tx_sring *txs;
>  
>  	/* Already connected through? */
> -	if (vif->irq)
> +	if (vif->tx_irq)
>  		return 0;
>  
>  	__module_get(THIS_MODULE);
> @@ -345,13 +372,35 @@ int xenvif_connect(struct xenvif *vif,
>  	if (vif->setup(vif))
>  		goto err_rx_unmap;
>  
> -	err = bind_interdomain_evtchn_to_irqhandler(
> -		vif->domid, evtchn, xenvif_interrupt, 0,
> -		vif->dev->name, vif);
> -	if (err < 0)
> -		goto err_rx_unmap;
> -	vif->irq = err;
> -	disable_irq(vif->irq);
> +	if (!split_evtchn) {

Presumably this is one of the places where you do have to care about
split vs non. I did consider whether simply registering two handlers for
the interrupt in a shared-interrupt style would work, but I think that
way lies madness and confusion...

> +		err = bind_interdomain_evtchn_to_irqhandler(
> +			vif->domid, evtchn[0], xenvif_interrupt, 0,
> +			vif->dev->name, vif);
> +		if (err < 0)
> +			goto err_rx_unmap;
> +		vif->tx_irq = vif->rx_irq = err;
> +		disable_irq(vif->tx_irq);
> +		vif->split_irq = 0;
> +	} else {
> +		err = bind_interdomain_evtchn_to_irqhandler(
> +			vif->domid, evtchn[0], xenvif_tx_interrupt,
> +			0, vif->dev->name, vif);
> +		if (err < 0)
> +			goto err_rx_unmap;
> +		vif->tx_irq = err;
> +		disable_irq(vif->tx_irq);
> +
> +		err = bind_interdomain_evtchn_to_irqhandler(
> +			vif->domid, evtchn[1], xenvif_rx_interrupt,
> +			0, vif->dev->name, vif);
> +		if (err < 0) {
> +			unbind_from_irqhandler(vif->tx_irq, vif);
> +			goto err_rx_unmap;
> +		}
> +		vif->rx_irq = err;
> +		disable_irq(vif->rx_irq);
> +		vif->split_irq = 1;
> +	}
>  
>  	init_waitqueue_head(&vif->wq);
>  	vif->task = kthread_create(xenvif_kthread,
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index 4067286..c5a3b27 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -131,6 +131,14 @@ static int netback_probe(struct xenbus_device *dev,
>  			goto abort_transaction;
>  		}
>  
> +		err = xenbus_printf(xbt, dev->nodename,
> +				    "split-event-channels",

Usually we use "feature-FOO" as the names for these sorts of nodes.

> +				    "%u", 1);
> +		if (err) {
> +			message = "writing split-event-channels";
> +			goto abort_transaction;
> +		}
> +
>  		err = xenbus_transaction_end(xbt, 0);
>  	} while (err == -EAGAIN);
>  
> @@ -408,7 +416,7 @@ static int connect_rings(struct backend_info *be)
>  {
>  	struct xenvif *vif = be->vif;
>  	struct xenbus_device *dev = be->dev;
> -	unsigned int evtchn, rx_copy;
> +	unsigned int evtchn[2], split_evtchn, rx_copy;

Another case where I think two vars is better than a small array.

>  	int err;
>  	int val;
>  	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:39:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:39:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB7d-0003Tr-C5; Tue, 31 Jan 2012 10:39:33 +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 1RsB7c-0003TB-8U
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:39:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328006365!13004408!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14843 invoked from network); 31 Jan 2012 10:39:26 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 10:39:26 -0000
Received: by werb14 with SMTP id b14so15410941wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 02:39: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=8ol6h+d7HxFPiUoa0iAMqgZHtPEzMokeEvyrNl1J7to=;
	b=v+og0f5pJLp/YE1A0kahbo5MQcHsvxODy1m9K/X9r+qq5h25/ZdpT97BJYIGAafBzw
	OZ+x1kwxdog7GIB+e4C8tToh+WhGDWQP0EhGL1VXN3JSF92jsq0Gor7EPOkc3LIzYDYy
	ZN4SZrTevBhIxi8aCbs7pruQYZrBa8vqbgstM=
Received: by 10.216.93.85 with SMTP id k63mr8612013wef.5.1328006365528;
	Tue, 31 Jan 2012 02:39:25 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q2sm24586978wiy.7.2012.01.31.02.39.23
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 02:39:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 31 Jan 2012 10:39:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Christoph Egger <Christoph.Egger@amd.com>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CB4D7558.2A12B%keir.xen@gmail.com>
Thread-Topic: [PATCH] x86/AMD: Add support for AMD's OSVW feature in guests
Thread-Index: AczgBJa3fTrVLiJx602Aort6UNbe0w==
In-Reply-To: <4F27C417.2070209@amd.com>
Mime-version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 31/01/2012 10:36, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> On 01/31/12 11:13, Jan Beulich wrote:
>>> --- a/xen/arch/x86/platform_hypercall.c Thu Jan 26 17:43:31 2012 +0000
>>> +++ b/xen/arch/x86/platform_hypercall.c Mon Jan 30 18:00:50 2012 +0100
>>> @@ -166,7 +166,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>>>               break;
>>> 
>>>           guest_from_compat_handle(data, op->u.microcode.data);
>>> +
>>> +        while ( !domctl_lock_acquire() )
>> 
>> It's not clear to me what you're trying to protect against here. I don't
>> think this prevents guests from making progress (and hence possibly
>> seeing the intermediate [and wrong] OSVW state between
>> svm_host_osvw_reset() and svm_host_osvw_init()).
> 
> The reason is because when we allocated VCPUs (via XEN_DOMCTL_max_vcpus
> and possibly other controls) we call svm_vcpu_initialise() ->
> svm_guest_osvw_init(). If we are in the middle of microcode update then
> osvw_length/osvw_status may be in an inconsistent state.

Deserves a code comment. Even better, deserves its own synchronisation
(e.g., your own specific lock for this purpose). It would be nice to avoid
further intricate dependencies on the big domctl lock, so we can consider
removing it in future.

 -- Keir

> Christoph
> 
>> Jan
>> 
>>> +            if ( hypercall_preempt_check() )
>>> +            {
>>> +                ret = hypercall_create_continuation(
>>> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
>>> +                goto out;
>>> +            }
>>> +
>>>           ret = microcode_update(data, op->u.microcode.length);
>>> +        domctl_lock_release();
>>>       }
>>>       break;
>>> 
>> 
>> 
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:39:46 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:39:46 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB7d-0003Tr-C5; Tue, 31 Jan 2012 10:39:33 +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 1RsB7c-0003TB-8U
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:39:32 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-7.tower-182.messagelabs.com!1328006365!13004408!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_14,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14843 invoked from network); 31 Jan 2012 10:39:26 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-7.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 10:39:26 -0000
Received: by werb14 with SMTP id b14so15410941wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 02:39: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=8ol6h+d7HxFPiUoa0iAMqgZHtPEzMokeEvyrNl1J7to=;
	b=v+og0f5pJLp/YE1A0kahbo5MQcHsvxODy1m9K/X9r+qq5h25/ZdpT97BJYIGAafBzw
	OZ+x1kwxdog7GIB+e4C8tToh+WhGDWQP0EhGL1VXN3JSF92jsq0Gor7EPOkc3LIzYDYy
	ZN4SZrTevBhIxi8aCbs7pruQYZrBa8vqbgstM=
Received: by 10.216.93.85 with SMTP id k63mr8612013wef.5.1328006365528;
	Tue, 31 Jan 2012 02:39:25 -0800 (PST)
Received: from [192.168.1.70] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id q2sm24586978wiy.7.2012.01.31.02.39.23
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 02:39:24 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 31 Jan 2012 10:39:20 +0000
From: Keir Fraser <keir.xen@gmail.com>
To: Christoph Egger <Christoph.Egger@amd.com>, Jan Beulich <JBeulich@suse.com>
Message-ID: <CB4D7558.2A12B%keir.xen@gmail.com>
Thread-Topic: [PATCH] x86/AMD: Add support for AMD's OSVW feature in guests
Thread-Index: AczgBJa3fTrVLiJx602Aort6UNbe0w==
In-Reply-To: <4F27C417.2070209@amd.com>
Mime-version: 1.0
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>, xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 31/01/2012 10:36, "Christoph Egger" <Christoph.Egger@amd.com> wrote:

> On 01/31/12 11:13, Jan Beulich wrote:
>>> --- a/xen/arch/x86/platform_hypercall.c Thu Jan 26 17:43:31 2012 +0000
>>> +++ b/xen/arch/x86/platform_hypercall.c Mon Jan 30 18:00:50 2012 +0100
>>> @@ -166,7 +166,17 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
>>>               break;
>>> 
>>>           guest_from_compat_handle(data, op->u.microcode.data);
>>> +
>>> +        while ( !domctl_lock_acquire() )
>> 
>> It's not clear to me what you're trying to protect against here. I don't
>> think this prevents guests from making progress (and hence possibly
>> seeing the intermediate [and wrong] OSVW state between
>> svm_host_osvw_reset() and svm_host_osvw_init()).
> 
> The reason is because when we allocated VCPUs (via XEN_DOMCTL_max_vcpus
> and possibly other controls) we call svm_vcpu_initialise() ->
> svm_guest_osvw_init(). If we are in the middle of microcode update then
> osvw_length/osvw_status may be in an inconsistent state.

Deserves a code comment. Even better, deserves its own synchronisation
(e.g., your own specific lock for this purpose). It would be nice to avoid
further intricate dependencies on the big domctl lock, so we can consider
removing it in future.

 -- Keir

> Christoph
> 
>> Jan
>> 
>>> +            if ( hypercall_preempt_check() )
>>> +            {
>>> +                ret = hypercall_create_continuation(
>>> +                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
>>> +                goto out;
>>> +            }
>>> +
>>>           ret = microcode_update(data, op->u.microcode.length);
>>> +        domctl_lock_release();
>>>       }
>>>       break;
>>> 
>> 
>> 
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:40:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:40:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB7x-0003Xc-QC; Tue, 31 Jan 2012 10:39:53 +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 1RsB7w-0003Wd-ON
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:39:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328006386!12830224!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16273 invoked from network); 31 Jan 2012 10:39:46 -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;
	31 Jan 2012 10:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:39:46 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:39:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328005476.26983.335.camel@zakaz.uk.xensource.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-6-git-send-email-wei.liu2@citrix.com>
	<1328005476.26983.335.camel@zakaz.uk.xensource.com>
Date: Tue, 31 Jan 2012 10:39:59 +0000
Message-ID: <1328006399.5553.58.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 05/16] netback: add module get/put
 operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 10:24 +0000, Ian Campbell wrote:
> On Mon, 2012-01-30 at 14:45 +0000, Wei Liu wrote:
> > If there is vif running and user unloads netback, it will certainly
> > cause problems -- guest's network interface just mysteriously stops
> > working.
> 
> This seems like a bug fix for  02/16 "netback: add module unload
> function". Please could you fold back such fixes where appropriate? I
> think there's a handful of these sorts of patches in the series.
> 

Sure.

> > v2: fix module_put path
> > 
> > disconnect function may get called by the generic framework even
> > before vif connects.
> > 
> > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/net/xen-netback/interface.c |   11 ++++++++++-
> >  1 files changed, 10 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> > index dfc04f8..7914f60 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
> >  	if (vif->irq)
> >  		return 0;
> >  
> > +	__module_get(THIS_MODULE);
> > +
> >  	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
> >  	if (err < 0)
> >  		goto err;
> > @@ -372,12 +374,14 @@ err_unbind:
> >  err_unmap:
> >  	xen_netbk_unmap_frontend_rings(vif);
> >  err:
> > +	module_put(THIS_MODULE);
> >  	return err;
> >  }
> >  
> >  void xenvif_disconnect(struct xenvif *vif)
> >  {
> >  	struct net_device *dev = vif->dev;
> > +	int need_module_put = 0;
> >  
> >  	if (netif_carrier_ok(dev)) {
> >  		rtnl_lock();
> > @@ -397,12 +401,17 @@ void xenvif_disconnect(struct xenvif *vif)
> >  
> >  	del_timer_sync(&vif->credit_timeout);
> >  
> > -	if (vif->irq)
> > +	if (vif->irq) {
> >  		unbind_from_irqhandler(vif->irq, vif);
> > +		need_module_put = 1;
> 
> This seems like a slightly odd condition. Why is the put not
> unconditional?
> 

This is what I observed. The framework will call disconnect
unconditionally in the cleanup phase. If the frontend fails to
initialize, the connect function will not get called, so there lacks a
corresponding module_get().


Wei.

> 
> > +	}
> >  
> >  	unregister_netdev(vif->dev);
> >  
> >  	xen_netbk_unmap_frontend_rings(vif);
> >  
> >  	free_netdev(vif->dev);
> > +
> > +	if (need_module_put)
> > +		module_put(THIS_MODULE);
> >  }
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:40:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:40:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsB7x-0003Xc-QC; Tue, 31 Jan 2012 10:39:53 +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 1RsB7w-0003Wd-ON
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:39:52 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328006386!12830224!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16273 invoked from network); 31 Jan 2012 10:39:46 -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;
	31 Jan 2012 10:39:46 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384845"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:39:46 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:39:46 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328005476.26983.335.camel@zakaz.uk.xensource.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-6-git-send-email-wei.liu2@citrix.com>
	<1328005476.26983.335.camel@zakaz.uk.xensource.com>
Date: Tue, 31 Jan 2012 10:39:59 +0000
Message-ID: <1328006399.5553.58.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 05/16] netback: add module get/put
 operations along with vif connect/disconnect.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 10:24 +0000, Ian Campbell wrote:
> On Mon, 2012-01-30 at 14:45 +0000, Wei Liu wrote:
> > If there is vif running and user unloads netback, it will certainly
> > cause problems -- guest's network interface just mysteriously stops
> > working.
> 
> This seems like a bug fix for  02/16 "netback: add module unload
> function". Please could you fold back such fixes where appropriate? I
> think there's a handful of these sorts of patches in the series.
> 

Sure.

> > v2: fix module_put path
> > 
> > disconnect function may get called by the generic framework even
> > before vif connects.
> > 
> > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/net/xen-netback/interface.c |   11 ++++++++++-
> >  1 files changed, 10 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> > index dfc04f8..7914f60 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -323,6 +323,8 @@ int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
> >  	if (vif->irq)
> >  		return 0;
> >  
> > +	__module_get(THIS_MODULE);
> > +
> >  	err = xen_netbk_map_frontend_rings(vif, tx_ring_ref, rx_ring_ref);
> >  	if (err < 0)
> >  		goto err;
> > @@ -372,12 +374,14 @@ err_unbind:
> >  err_unmap:
> >  	xen_netbk_unmap_frontend_rings(vif);
> >  err:
> > +	module_put(THIS_MODULE);
> >  	return err;
> >  }
> >  
> >  void xenvif_disconnect(struct xenvif *vif)
> >  {
> >  	struct net_device *dev = vif->dev;
> > +	int need_module_put = 0;
> >  
> >  	if (netif_carrier_ok(dev)) {
> >  		rtnl_lock();
> > @@ -397,12 +401,17 @@ void xenvif_disconnect(struct xenvif *vif)
> >  
> >  	del_timer_sync(&vif->credit_timeout);
> >  
> > -	if (vif->irq)
> > +	if (vif->irq) {
> >  		unbind_from_irqhandler(vif->irq, vif);
> > +		need_module_put = 1;
> 
> This seems like a slightly odd condition. Why is the put not
> unconditional?
> 

This is what I observed. The framework will call disconnect
unconditionally in the cleanup phase. If the frontend fails to
initialize, the connect function will not get called, so there lacks a
corresponding module_get().


Wei.

> 
> > +	}
> >  
> >  	unregister_netdev(vif->dev);
> >  
> >  	xen_netbk_unmap_frontend_rings(vif);
> >  
> >  	free_netdev(vif->dev);
> > +
> > +	if (need_module_put)
> > +		module_put(THIS_MODULE);
> >  }
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:44:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBBq-0003xS-Na; Tue, 31 Jan 2012 10:43:54 +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 1RsBBp-0003xB-Fp
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:43:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328006627!9758499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19740 invoked from network); 31 Jan 2012 10:43:47 -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;
	31 Jan 2012 10:43:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:43:27 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:43:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
In-Reply-To: <CAL4WiirrQ+2PqojQ9dnGRF16cxx-1QNRWqcMkVqqZSZwvWC58Q@mail.gmail.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
	<CAL4WiirrQ+2PqojQ9dnGRF16cxx-1QNRWqcMkVqqZSZwvWC58Q@mail.gmail.com>
Date: Tue, 31 Jan 2012 10:43:40 +0000
Message-ID: <1328006620.5553.59.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:25 +0000, Eric Dumazet wrote:
> 
> Problem is you lost NUMA awareness here.
> 
> Please check vzalloc_node()

Good point, thanks.

Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:44:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:44:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBBq-0003xS-Na; Tue, 31 Jan 2012 10:43:54 +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 1RsBBp-0003xB-Fp
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:43:53 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-12.tower-21.messagelabs.com!1328006627!9758499!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19740 invoked from network); 31 Jan 2012 10:43:47 -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;
	31 Jan 2012 10:43:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10384951"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:43:27 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:43:27 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
In-Reply-To: <CAL4WiirrQ+2PqojQ9dnGRF16cxx-1QNRWqcMkVqqZSZwvWC58Q@mail.gmail.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
	<CAL4WiirrQ+2PqojQ9dnGRF16cxx-1QNRWqcMkVqqZSZwvWC58Q@mail.gmail.com>
Date: Tue, 31 Jan 2012 10:43:40 +0000
Message-ID: <1328006620.5553.59.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:25 +0000, Eric Dumazet wrote:
> 
> Problem is you lost NUMA awareness here.
> 
> Please check vzalloc_node()

Good point, thanks.

Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:44:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBBv-0003xu-5d; Tue, 31 Jan 2012 10:43:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RsBBu-0003xU-6u
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:43:58 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328006584!50754851!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11481 invoked from network); 31 Jan 2012 10:43:05 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 10:43:05 -0000
Received: by lagp5 with SMTP id p5so5666684lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 02:43:53 -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
	:content-transfer-encoding;
	bh=4eJuFT1DB07OxvRlXMQ87gnXbp18WYm3EXCtPcJxWME=;
	b=CVyNTRrssvRNnnjUtisutqPiBUzmm+3zb3SL4uj+ICUkxmZfs/CuBXT/QxZ4/P1h8J
	iaXybIioLhQj8Mex7R1EBiam0NkVozbf3iVg4D+K7W6mCpvQOeyLzTnW5S/1p46V3bvI
	ofZQ+eco1X99S9HJZfj7g4IGv6Ltw0JjgKatg=
Received: by 10.112.101.196 with SMTP id fi4mr5525002lbb.28.1328006633230;
	Tue, 31 Jan 2012 02:43:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.85.36 with HTTP; Tue, 31 Jan 2012 02:43:38 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
References: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 31 Jan 2012 14:43:38 +0400
X-Google-Sender-Auth: zSx91zaN2BCcDiKZSbTZdeemTtY
Message-ID: <CACaajQuk4o2ec7v=vQY9dGcu32UM1-gZ44ET2+eo8dCe6RPXsg@mail.gmail.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to get DomU id from 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

MjAxMi8xLzMxIFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PjoKPiBI
ZWxsbywKPgo+IFRoaXMgaXMgcXVpdGUgYSB0cml2aWFsIHF1ZXN0aW9uLCBidXQgSSBoYXZlbid0
IGJlZW4gYWJsZSB0byBmaW5kIGhvdwo+IHRvIGRvIGl0LiBJcyB0aGVyZSBhbnl3YXkgdG8gZ2V0
IHRoZSBpZCBvZiBhIFBWIERvbVUgZnJvbSBpbnNpZGUgdGhlCj4gKHNhbWUpIFBWIERvbVU/Cj4K
CnhlbnN0b3JlIHJlYWQgZG9taWQKCgoKLS0gClZhc2lsaXkgVG9sc3RvdiwKQ2xvZG8ucnUKZS1t
YWlsOiB2LnRvbHN0b3ZAc2VsZmlwLnJ1CmphYmJlcjogdmFzZUBzZWxmaXAucnUKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:44:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:44:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBBv-0003xu-5d; Tue, 31 Jan 2012 10:43:59 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vase@selfip.ru>) id 1RsBBu-0003xU-6u
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:43:58 +0000
X-Env-Sender: vase@selfip.ru
X-Msg-Ref: server-10.tower-27.messagelabs.com!1328006584!50754851!1
X-Originating-IP: [209.85.215.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_TEST_2,
	RCVD_BY_IP,spamassassin: 
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11481 invoked from network); 31 Jan 2012 10:43:05 -0000
Received: from mail-lpp01m010-f43.google.com (HELO
	mail-lpp01m010-f43.google.com) (209.85.215.43)
	by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 10:43:05 -0000
Received: by lagp5 with SMTP id p5so5666684lag.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 02:43:53 -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
	:content-transfer-encoding;
	bh=4eJuFT1DB07OxvRlXMQ87gnXbp18WYm3EXCtPcJxWME=;
	b=CVyNTRrssvRNnnjUtisutqPiBUzmm+3zb3SL4uj+ICUkxmZfs/CuBXT/QxZ4/P1h8J
	iaXybIioLhQj8Mex7R1EBiam0NkVozbf3iVg4D+K7W6mCpvQOeyLzTnW5S/1p46V3bvI
	ofZQ+eco1X99S9HJZfj7g4IGv6Ltw0JjgKatg=
Received: by 10.112.101.196 with SMTP id fi4mr5525002lbb.28.1328006633230;
	Tue, 31 Jan 2012 02:43:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.85.36 with HTTP; Tue, 31 Jan 2012 02:43:38 -0800 (PST)
X-Originating-IP: [85.143.161.18]
In-Reply-To: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
References: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
From: Vasiliy Tolstov <v.tolstov@selfip.ru>
Date: Tue, 31 Jan 2012 14:43:38 +0400
X-Google-Sender-Auth: zSx91zaN2BCcDiKZSbTZdeemTtY
Message-ID: <CACaajQuk4o2ec7v=vQY9dGcu32UM1-gZ44ET2+eo8dCe6RPXsg@mail.gmail.com>
To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= <roger.pau@entel.upc.edu>
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to get DomU id from 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

MjAxMi8xLzMxIFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBlbnRlbC51cGMuZWR1PjoKPiBI
ZWxsbywKPgo+IFRoaXMgaXMgcXVpdGUgYSB0cml2aWFsIHF1ZXN0aW9uLCBidXQgSSBoYXZlbid0
IGJlZW4gYWJsZSB0byBmaW5kIGhvdwo+IHRvIGRvIGl0LiBJcyB0aGVyZSBhbnl3YXkgdG8gZ2V0
IHRoZSBpZCBvZiBhIFBWIERvbVUgZnJvbSBpbnNpZGUgdGhlCj4gKHNhbWUpIFBWIERvbVU/Cj4K
CnhlbnN0b3JlIHJlYWQgZG9taWQKCgoKLS0gClZhc2lsaXkgVG9sc3RvdiwKQ2xvZG8ucnUKZS1t
YWlsOiB2LnRvbHN0b3ZAc2VsZmlwLnJ1CmphYmJlcjogdmFzZUBzZWxmaXAucnUKCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi1kZXZlbCBtYWlsaW5n
IGxpc3QKWGVuLWRldmVsQGxpc3RzLnhlbnNvdXJjZS5jb20KaHR0cDovL2xpc3RzLnhlbnNvdXJj
ZS5jb20veGVuLWRldmVsCg==

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:46:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 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 1RsBEN-0004BV-PB; Tue, 31 Jan 2012 10:46:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsBEL-0004BO-Qb
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:46:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328006783!9430867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18354 invoked from network); 31 Jan 2012 10:46:24 -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;
	31 Jan 2012 10:46:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385251"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:46: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, 31 Jan 2012 10:46:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 31 Jan 2012 10:46:23 +0000
In-Reply-To: <CAPLaKK47wwd1BtGUswOMW3VcwO6PL6YsUVZMB58roCsooM3cVA@mail.gmail.com>
References: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
	<4F27C2CE.30702@redhat.com>
	<CAPLaKK47wwd1BtGUswOMW3VcwO6PL6YsUVZMB58roCsooM3cVA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328006783.26983.345.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Xen-devel] How to get DomU id from 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

T24gVHVlLCAyMDEyLTAxLTMxIGF0IDEwOjM1ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8zMSBMYXN6bG8gRXJzZWsgPGxlcnNla0ByZWRoYXQuY29tPjoKPiA+IE9uIDAx
LzMxLzEyIDExOjAxLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+ID4KPiA+PiBUaGlzIGlzIHF1
aXRlIGEgdHJpdmlhbCBxdWVzdGlvbiwgYnV0IEkgaGF2ZW4ndCBiZWVuIGFibGUgdG8gZmluZCBo
b3cKPiA+PiB0byBkbyBpdC4gSXMgdGhlcmUgYW55d2F5IHRvIGdldCB0aGUgaWQgb2YgYSBQViBE
b21VIGZyb20gaW5zaWRlIHRoZQo+ID4+IChzYW1lKSBQViBEb21VPwo+ID4KPiA+Cj4gPiBIZXJl
J3MgYSBoYWNrICh1bnRlc3RlZCk6IG9uZSBjb3VsZCBjcmVhdGUgYSBsb29wIGV2ZW50IGNoYW5u
ZWwgd2l0aAo+ID4gRVZUQ0hOT1BfYmluZF9pbnRlcmRvbWFpbiAocGFzc2luZyBpbiBET01JRF9T
RUxGIGFzIHJlbW90ZV9kb20pLCB0aGVuIHF1ZXJ5Cj4gPiBpdCB3aXRoIEVWVENITk9QX3N0YXR1
cyAoYWxzbyBwYXNzaW5nIGluIERPTUlEX1NFTEYpLiBPbiByZXR1cm4sCj4gPiAiaW50ZXJkb21h
aW4uZG9tIiAoPSB0aGUgcmVtb3RlIGVuZCkgc2hvdWxkIGhhdmUgdGhlIHJlYWwgZG9taWQuCj4g
Cj4gVGhhbmtzLCBzdXJlIHRoYXQgbG9va3MgcXVpdGUgaGFja2lzaCwgdGhlcmUncyBubyBvdGhl
ciB3YXkgdG8gZG8gaXQ/Cj4gSSBuZWVkIHRvIGtub3cgdGhlIGRvbSBpZCB0byBzZXQgdGhlIGNv
cnJlY3Qgd2F0Y2hlcyBvbiB4ZW5zdG9yZSBmb3IKPiBkcml2ZXIgZG9tYWlucy4gRWFjaCBkcml2
ZXIgZG9tYWluIHNob3VsZCB3YXRjaCBhIHNwZWNpZmljIHBhdGggaW4KPiB4ZW5zdG9yZSwgdGhh
dCBpcyBkZXRlcm1pbmVkIGJhc2VkIG9uIHRoZSBpZCBvZiB0aGUgZG9tYWluIGl0c2VsZi4KCldv
dWxkIGl0IG1ha2Ugc2Vuc2UgdG8gcHV0IHRoYXQgcGF0aCB1bmRlciB0aGUgZG9tYWluJ3MgImhv
bWUKZGlyZWN0b3J5Ij8KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:46:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 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 1RsBEN-0004BV-PB; Tue, 31 Jan 2012 10:46:31 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsBEL-0004BO-Qb
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:46:30 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328006783!9430867!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18354 invoked from network); 31 Jan 2012 10:46:24 -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;
	31 Jan 2012 10:46:24 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385251"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:46: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, 31 Jan 2012 10:46:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 31 Jan 2012 10:46:23 +0000
In-Reply-To: <CAPLaKK47wwd1BtGUswOMW3VcwO6PL6YsUVZMB58roCsooM3cVA@mail.gmail.com>
References: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
	<4F27C2CE.30702@redhat.com>
	<CAPLaKK47wwd1BtGUswOMW3VcwO6PL6YsUVZMB58roCsooM3cVA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328006783.26983.345.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Xen-devel] How to get DomU id from 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

T24gVHVlLCAyMDEyLTAxLTMxIGF0IDEwOjM1ICswMDAwLCBSb2dlciBQYXUgTW9ubsOpIHdyb3Rl
Ogo+IDIwMTIvMS8zMSBMYXN6bG8gRXJzZWsgPGxlcnNla0ByZWRoYXQuY29tPjoKPiA+IE9uIDAx
LzMxLzEyIDExOjAxLCBSb2dlciBQYXUgTW9ubsOpIHdyb3RlOgo+ID4KPiA+PiBUaGlzIGlzIHF1
aXRlIGEgdHJpdmlhbCBxdWVzdGlvbiwgYnV0IEkgaGF2ZW4ndCBiZWVuIGFibGUgdG8gZmluZCBo
b3cKPiA+PiB0byBkbyBpdC4gSXMgdGhlcmUgYW55d2F5IHRvIGdldCB0aGUgaWQgb2YgYSBQViBE
b21VIGZyb20gaW5zaWRlIHRoZQo+ID4+IChzYW1lKSBQViBEb21VPwo+ID4KPiA+Cj4gPiBIZXJl
J3MgYSBoYWNrICh1bnRlc3RlZCk6IG9uZSBjb3VsZCBjcmVhdGUgYSBsb29wIGV2ZW50IGNoYW5u
ZWwgd2l0aAo+ID4gRVZUQ0hOT1BfYmluZF9pbnRlcmRvbWFpbiAocGFzc2luZyBpbiBET01JRF9T
RUxGIGFzIHJlbW90ZV9kb20pLCB0aGVuIHF1ZXJ5Cj4gPiBpdCB3aXRoIEVWVENITk9QX3N0YXR1
cyAoYWxzbyBwYXNzaW5nIGluIERPTUlEX1NFTEYpLiBPbiByZXR1cm4sCj4gPiAiaW50ZXJkb21h
aW4uZG9tIiAoPSB0aGUgcmVtb3RlIGVuZCkgc2hvdWxkIGhhdmUgdGhlIHJlYWwgZG9taWQuCj4g
Cj4gVGhhbmtzLCBzdXJlIHRoYXQgbG9va3MgcXVpdGUgaGFja2lzaCwgdGhlcmUncyBubyBvdGhl
ciB3YXkgdG8gZG8gaXQ/Cj4gSSBuZWVkIHRvIGtub3cgdGhlIGRvbSBpZCB0byBzZXQgdGhlIGNv
cnJlY3Qgd2F0Y2hlcyBvbiB4ZW5zdG9yZSBmb3IKPiBkcml2ZXIgZG9tYWlucy4gRWFjaCBkcml2
ZXIgZG9tYWluIHNob3VsZCB3YXRjaCBhIHNwZWNpZmljIHBhdGggaW4KPiB4ZW5zdG9yZSwgdGhh
dCBpcyBkZXRlcm1pbmVkIGJhc2VkIG9uIHRoZSBpZCBvZiB0aGUgZG9tYWluIGl0c2VsZi4KCldv
dWxkIGl0IG1ha2Ugc2Vuc2UgdG8gcHV0IHRoYXQgcGF0aCB1bmRlciB0aGUgZG9tYWluJ3MgImhv
bWUKZGlyZWN0b3J5Ij8KCklhbi4KCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KWGVuLWRldmVsIG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVu
c291cmNlLmNvbQpodHRwOi8vbGlzdHMueGVuc291cmNlLmNvbS94ZW4tZGV2ZWwK

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:49:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:49:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBGf-0004OI-B0; Tue, 31 Jan 2012 10:48:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RsBGd-0004Nw-Jn
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:48:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328006924!13079123!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4018 invoked from network); 31 Jan 2012 10:48:45 -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;
	31 Jan 2012 10:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:48:29 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:48:29 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120130215332.GA16747@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
	<20120130215332.GA16747@phenom.dumpdata.com>
Date: Tue, 31 Jan 2012 10:48:42 +0000
Message-ID: <1328006922.5553.61.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 21:53 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 02:45:28PM +0000, Wei Liu wrote:
> > If we allocate large arrays in per-cpu section, multi-page ring
> > feature is likely to blow up the per-cpu section. So avoid allocating
> > large arrays, instead we only store pointers to scratch spaces in
> > per-cpu section.
> > 
> > CPU hotplug event is also taken care of.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/net/xen-netback/netback.c |  140 +++++++++++++++++++++++++++----------
> >  1 files changed, 104 insertions(+), 36 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index a8d58a9..2ac9b84 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -39,6 +39,7 @@
> >  #include <linux/kthread.h>
> >  #include <linux/if_vlan.h>
> >  #include <linux/udp.h>
> > +#include <linux/cpu.h>
> >  
> >  #include <net/tcp.h>
> >  
> > @@ -49,15 +50,15 @@
> >  #include <asm/xen/page.h>
> >  
> >  
> > -struct gnttab_copy *tx_copy_ops;
> > +DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
> >  
> >  /*
> >   * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
> >   * head/fragment page uses 2 copy operations because it
> >   * straddles two buffers in the frontend.
> >   */
> > -struct gnttab_copy *grant_copy_op;
> > -struct xenvif_rx_meta *meta;
> > +DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
> > +DEFINE_PER_CPU(struct xenvif_rx_meta *, meta);
> >  
> >  static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
> >  static void make_tx_response(struct xenvif *vif,
> > @@ -481,8 +482,8 @@ void xenvif_rx_action(struct xenvif *vif)
> >  	struct skb_cb_overlay *sco;
> >  	int need_to_notify = 0;
> >  
> > -	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
> > -	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
> > +	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
> > +	struct xenvif_rx_meta *m = get_cpu_var(meta);
> >  
> >  	struct netrx_pending_operations npo = {
> >  		.copy  = gco,
> > @@ -512,8 +513,8 @@ void xenvif_rx_action(struct xenvif *vif)
> >  	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
> >  
> >  	if (!npo.copy_prod) {
> > -		put_cpu_ptr(gco);
> > -		put_cpu_ptr(m);
> > +		put_cpu_var(grant_copy_op);
> > +		put_cpu_var(meta);
> >  		return;
> >  	}
> >  
> > @@ -599,8 +600,8 @@ void xenvif_rx_action(struct xenvif *vif)
> >  	if (!skb_queue_empty(&vif->rx_queue))
> >  		xenvif_kick_thread(vif);
> >  
> > -	put_cpu_ptr(gco);
> > -	put_cpu_ptr(m);
> > +	put_cpu_var(grant_copy_op);
> > +	put_cpu_var(meta);
> >  }
> >  
> >  void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
> > @@ -1287,12 +1288,12 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
> >  	if (unlikely(!tx_work_todo(vif)))
> >  		return 0;
> >  
> > -	tco = get_cpu_ptr(tx_copy_ops);
> > +	tco = get_cpu_var(tx_copy_ops);
> >  
> >  	nr_gops = xenvif_tx_build_gops(vif, tco);
> >  
> >  	if (nr_gops == 0) {
> > -		put_cpu_ptr(tco);
> > +		put_cpu_var(tx_copy_ops);
> >  		return 0;
> >  	}
> >  
> > @@ -1301,7 +1302,7 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
> >  
> >  	work_done = xenvif_tx_submit(vif, tco, budget);
> >  
> > -	put_cpu_ptr(tco);
> > +	put_cpu_var(tx_copy_ops);
> >  
> >  	return work_done;
> >  }
> > @@ -1452,31 +1453,97 @@ int xenvif_kthread(void *data)
> >  	return 0;
> >  }
> >  
> > +static int __create_percpu_scratch_space(unsigned int cpu)
> > +{
> > +	per_cpu(tx_copy_ops, cpu) =
> > +		vzalloc(sizeof(struct gnttab_copy) * MAX_PENDING_REQS);
> > +
> > +	per_cpu(grant_copy_op, cpu) =
> > +		vzalloc(sizeof(struct gnttab_copy)
> > +			* 2 * XEN_NETIF_RX_RING_SIZE);
> > +
> > +	per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
> > +				     * 2 * XEN_NETIF_RX_RING_SIZE);
> > +
> > +	if (!per_cpu(tx_copy_ops, cpu) ||
> > +	    !per_cpu(grant_copy_op, cpu) ||
> > +	    !per_cpu(meta, cpu))
> 
> Hm, shouldn't you vfree one at least them? It might be that just one of
> them failed.
> 

The caller will clean up.

> > +		return -ENOMEM;
> > +
> > +	return 0;
> > +}
> > +
> > +static void __free_percpu_scratch_space(unsigned int cpu)
> > +{
> > +	/* freeing NULL pointer is legit */
> > +	vfree(per_cpu(tx_copy_ops, cpu));
> > +	vfree(per_cpu(grant_copy_op, cpu));
> > +	vfree(per_cpu(meta, cpu));
> > +}
> > +
> > +static int __netback_percpu_callback(struct notifier_block *nfb,
> > +				     unsigned long action, void *hcpu)
> > +{
> > +	unsigned int cpu = (unsigned long)hcpu;
> > +	int rc = NOTIFY_DONE;
> > +
> > +	switch (action) {
> > +	case CPU_ONLINE:
> > +	case CPU_ONLINE_FROZEN:
> > +		printk(KERN_INFO
> > +		       "netback: CPU %x online, creating scratch space\n", cpu);
> 
> Is there any way to use 'pr_info(DRV_NAME' for these printk's? It might
> require another patch, but it would  make it nicer.
> 

Hmm... will look into that.

> > +		rc = __create_percpu_scratch_space(cpu);
> > +		if (rc) {
> > +			printk(KERN_ALERT
> > +			       "netback: failed to create scratch space for CPU"
> > +			       " %x\n", cpu);
> > +			/* FIXME: nothing more we can do here, we will
> > +			 * print out warning message when thread or
> > +			 * NAPI runs on this cpu. Also stop getting
> > +			 * called in the future.
> > +			 */
> > +			__free_percpu_scratch_space(cpu);
> > +			rc = NOTIFY_BAD;
> > +		} else {
> > +			rc = NOTIFY_OK;
> > +		}
> > +		break;
> > +	case CPU_DEAD:
> > +	case CPU_DEAD_FROZEN:
> > +		printk("netback: CPU %x offline, destroying scratch space\n",
> > +		       cpu);
> 
> pr_debug?
> 
> > +		__free_percpu_scratch_space(cpu);
> > +		rc = NOTIFY_OK;
> > +		break;
> > +	default:
> > +		break;
> > +	}
> > +
> > +	return rc;
> > +}
> > +
> > +static struct notifier_block netback_notifier_block = {
> > +	.notifier_call = __netback_percpu_callback,
> > +};
> >  
> >  static int __init netback_init(void)
> >  {
> >  	int rc = -ENOMEM;
> > +	int cpu;
> >  
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> > -	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
> > -				     * MAX_PENDING_REQS,
> > -				     __alignof__(struct gnttab_copy));
> > -	if (!tx_copy_ops)
> > -		goto failed_init;
> > +	/* Don't need to disable preempt here, since nobody else will
> > +	 * touch these percpu areas during start up. */
> > +	for_each_online_cpu(cpu) {
> > +		rc = __create_percpu_scratch_space(cpu);
> >  
> > -	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
> > -				       * 2 * XEN_NETIF_RX_RING_SIZE,
> > -				       __alignof__(struct gnttab_copy));
> > -	if (!grant_copy_op)
> > -		goto failed_init_gco;
> > +		if (rc)
> > +			goto failed_init;
> > +	}
> >  
> > -	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
> > -			      * 2 * XEN_NETIF_RX_RING_SIZE,
> > -			      __alignof__(struct xenvif_rx_meta));
> > -	if (!meta)
> > -		goto failed_init_meta;
> > +	register_hotcpu_notifier(&netback_notifier_block);
> >  
> >  	rc = page_pool_init();
> >  	if (rc)
> > @@ -1491,25 +1558,26 @@ static int __init netback_init(void)
> >  failed_init_xenbus:
> >  	page_pool_destroy();
> >  failed_init_pool:
> > -	free_percpu(meta);
> > -failed_init_meta:
> > -	free_percpu(grant_copy_op);
> > -failed_init_gco:
> > -	free_percpu(tx_copy_ops);
> > +	for_each_online_cpu(cpu)
> > +		__free_percpu_scratch_space(cpu);
> >  failed_init:
> >  	return rc;
> 
> We don't want to try to clean up the per_cpu_spaces that might
> have gotten allocated in the loop?
> 

Good catch, thanks.


Wei.

> > -
> >  }
> >  
> >  module_init(netback_init);
> >  
> >  static void __exit netback_exit(void)
> >  {
> > +	int cpu;
> > +
> >  	xenvif_xenbus_exit();
> >  	page_pool_destroy();
> > -	free_percpu(meta);
> > -	free_percpu(grant_copy_op);
> > -	free_percpu(tx_copy_ops);
> > +
> > +	unregister_hotcpu_notifier(&netback_notifier_block);
> > +
> > +	/* Since we're here, nobody else will touch per-cpu area. */
> > +	for_each_online_cpu(cpu)
> > +		__free_percpu_scratch_space(cpu);
> >  }
> >  module_exit(netback_exit);
> >  
> > -- 
> > 1.7.2.5



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:49:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:49:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBGf-0004OI-B0; Tue, 31 Jan 2012 10:48:53 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RsBGd-0004Nw-Jn
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:48:51 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328006924!13079123!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4018 invoked from network); 31 Jan 2012 10:48:45 -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;
	31 Jan 2012 10:48:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385323"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:48:29 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:48:29 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120130215332.GA16747@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-11-git-send-email-wei.liu2@citrix.com>
	<20120130215332.GA16747@phenom.dumpdata.com>
Date: Tue, 31 Jan 2012 10:48:42 +0000
Message-ID: <1328006922.5553.61.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 10/16] netback: rework of per-cpu
	scratch space.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 21:53 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 02:45:28PM +0000, Wei Liu wrote:
> > If we allocate large arrays in per-cpu section, multi-page ring
> > feature is likely to blow up the per-cpu section. So avoid allocating
> > large arrays, instead we only store pointers to scratch spaces in
> > per-cpu section.
> > 
> > CPU hotplug event is also taken care of.
> > 
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/net/xen-netback/netback.c |  140 +++++++++++++++++++++++++++----------
> >  1 files changed, 104 insertions(+), 36 deletions(-)
> > 
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index a8d58a9..2ac9b84 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -39,6 +39,7 @@
> >  #include <linux/kthread.h>
> >  #include <linux/if_vlan.h>
> >  #include <linux/udp.h>
> > +#include <linux/cpu.h>
> >  
> >  #include <net/tcp.h>
> >  
> > @@ -49,15 +50,15 @@
> >  #include <asm/xen/page.h>
> >  
> >  
> > -struct gnttab_copy *tx_copy_ops;
> > +DEFINE_PER_CPU(struct gnttab_copy *, tx_copy_ops);
> >  
> >  /*
> >   * Given MAX_BUFFER_OFFSET of 4096 the worst case is that each
> >   * head/fragment page uses 2 copy operations because it
> >   * straddles two buffers in the frontend.
> >   */
> > -struct gnttab_copy *grant_copy_op;
> > -struct xenvif_rx_meta *meta;
> > +DEFINE_PER_CPU(struct gnttab_copy *, grant_copy_op);
> > +DEFINE_PER_CPU(struct xenvif_rx_meta *, meta);
> >  
> >  static void xenvif_idx_release(struct xenvif *vif, u16 pending_idx);
> >  static void make_tx_response(struct xenvif *vif,
> > @@ -481,8 +482,8 @@ void xenvif_rx_action(struct xenvif *vif)
> >  	struct skb_cb_overlay *sco;
> >  	int need_to_notify = 0;
> >  
> > -	struct gnttab_copy *gco = get_cpu_ptr(grant_copy_op);
> > -	struct xenvif_rx_meta *m = get_cpu_ptr(meta);
> > +	struct gnttab_copy *gco = get_cpu_var(grant_copy_op);
> > +	struct xenvif_rx_meta *m = get_cpu_var(meta);
> >  
> >  	struct netrx_pending_operations npo = {
> >  		.copy  = gco,
> > @@ -512,8 +513,8 @@ void xenvif_rx_action(struct xenvif *vif)
> >  	BUG_ON(npo.meta_prod > MAX_PENDING_REQS);
> >  
> >  	if (!npo.copy_prod) {
> > -		put_cpu_ptr(gco);
> > -		put_cpu_ptr(m);
> > +		put_cpu_var(grant_copy_op);
> > +		put_cpu_var(meta);
> >  		return;
> >  	}
> >  
> > @@ -599,8 +600,8 @@ void xenvif_rx_action(struct xenvif *vif)
> >  	if (!skb_queue_empty(&vif->rx_queue))
> >  		xenvif_kick_thread(vif);
> >  
> > -	put_cpu_ptr(gco);
> > -	put_cpu_ptr(m);
> > +	put_cpu_var(grant_copy_op);
> > +	put_cpu_var(meta);
> >  }
> >  
> >  void xenvif_queue_tx_skb(struct xenvif *vif, struct sk_buff *skb)
> > @@ -1287,12 +1288,12 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
> >  	if (unlikely(!tx_work_todo(vif)))
> >  		return 0;
> >  
> > -	tco = get_cpu_ptr(tx_copy_ops);
> > +	tco = get_cpu_var(tx_copy_ops);
> >  
> >  	nr_gops = xenvif_tx_build_gops(vif, tco);
> >  
> >  	if (nr_gops == 0) {
> > -		put_cpu_ptr(tco);
> > +		put_cpu_var(tx_copy_ops);
> >  		return 0;
> >  	}
> >  
> > @@ -1301,7 +1302,7 @@ int xenvif_tx_action(struct xenvif *vif, int budget)
> >  
> >  	work_done = xenvif_tx_submit(vif, tco, budget);
> >  
> > -	put_cpu_ptr(tco);
> > +	put_cpu_var(tx_copy_ops);
> >  
> >  	return work_done;
> >  }
> > @@ -1452,31 +1453,97 @@ int xenvif_kthread(void *data)
> >  	return 0;
> >  }
> >  
> > +static int __create_percpu_scratch_space(unsigned int cpu)
> > +{
> > +	per_cpu(tx_copy_ops, cpu) =
> > +		vzalloc(sizeof(struct gnttab_copy) * MAX_PENDING_REQS);
> > +
> > +	per_cpu(grant_copy_op, cpu) =
> > +		vzalloc(sizeof(struct gnttab_copy)
> > +			* 2 * XEN_NETIF_RX_RING_SIZE);
> > +
> > +	per_cpu(meta, cpu) = vzalloc(sizeof(struct xenvif_rx_meta)
> > +				     * 2 * XEN_NETIF_RX_RING_SIZE);
> > +
> > +	if (!per_cpu(tx_copy_ops, cpu) ||
> > +	    !per_cpu(grant_copy_op, cpu) ||
> > +	    !per_cpu(meta, cpu))
> 
> Hm, shouldn't you vfree one at least them? It might be that just one of
> them failed.
> 

The caller will clean up.

> > +		return -ENOMEM;
> > +
> > +	return 0;
> > +}
> > +
> > +static void __free_percpu_scratch_space(unsigned int cpu)
> > +{
> > +	/* freeing NULL pointer is legit */
> > +	vfree(per_cpu(tx_copy_ops, cpu));
> > +	vfree(per_cpu(grant_copy_op, cpu));
> > +	vfree(per_cpu(meta, cpu));
> > +}
> > +
> > +static int __netback_percpu_callback(struct notifier_block *nfb,
> > +				     unsigned long action, void *hcpu)
> > +{
> > +	unsigned int cpu = (unsigned long)hcpu;
> > +	int rc = NOTIFY_DONE;
> > +
> > +	switch (action) {
> > +	case CPU_ONLINE:
> > +	case CPU_ONLINE_FROZEN:
> > +		printk(KERN_INFO
> > +		       "netback: CPU %x online, creating scratch space\n", cpu);
> 
> Is there any way to use 'pr_info(DRV_NAME' for these printk's? It might
> require another patch, but it would  make it nicer.
> 

Hmm... will look into that.

> > +		rc = __create_percpu_scratch_space(cpu);
> > +		if (rc) {
> > +			printk(KERN_ALERT
> > +			       "netback: failed to create scratch space for CPU"
> > +			       " %x\n", cpu);
> > +			/* FIXME: nothing more we can do here, we will
> > +			 * print out warning message when thread or
> > +			 * NAPI runs on this cpu. Also stop getting
> > +			 * called in the future.
> > +			 */
> > +			__free_percpu_scratch_space(cpu);
> > +			rc = NOTIFY_BAD;
> > +		} else {
> > +			rc = NOTIFY_OK;
> > +		}
> > +		break;
> > +	case CPU_DEAD:
> > +	case CPU_DEAD_FROZEN:
> > +		printk("netback: CPU %x offline, destroying scratch space\n",
> > +		       cpu);
> 
> pr_debug?
> 
> > +		__free_percpu_scratch_space(cpu);
> > +		rc = NOTIFY_OK;
> > +		break;
> > +	default:
> > +		break;
> > +	}
> > +
> > +	return rc;
> > +}
> > +
> > +static struct notifier_block netback_notifier_block = {
> > +	.notifier_call = __netback_percpu_callback,
> > +};
> >  
> >  static int __init netback_init(void)
> >  {
> >  	int rc = -ENOMEM;
> > +	int cpu;
> >  
> >  	if (!xen_domain())
> >  		return -ENODEV;
> >  
> > -	tx_copy_ops = __alloc_percpu(sizeof(struct gnttab_copy)
> > -				     * MAX_PENDING_REQS,
> > -				     __alignof__(struct gnttab_copy));
> > -	if (!tx_copy_ops)
> > -		goto failed_init;
> > +	/* Don't need to disable preempt here, since nobody else will
> > +	 * touch these percpu areas during start up. */
> > +	for_each_online_cpu(cpu) {
> > +		rc = __create_percpu_scratch_space(cpu);
> >  
> > -	grant_copy_op = __alloc_percpu(sizeof(struct gnttab_copy)
> > -				       * 2 * XEN_NETIF_RX_RING_SIZE,
> > -				       __alignof__(struct gnttab_copy));
> > -	if (!grant_copy_op)
> > -		goto failed_init_gco;
> > +		if (rc)
> > +			goto failed_init;
> > +	}
> >  
> > -	meta = __alloc_percpu(sizeof(struct xenvif_rx_meta)
> > -			      * 2 * XEN_NETIF_RX_RING_SIZE,
> > -			      __alignof__(struct xenvif_rx_meta));
> > -	if (!meta)
> > -		goto failed_init_meta;
> > +	register_hotcpu_notifier(&netback_notifier_block);
> >  
> >  	rc = page_pool_init();
> >  	if (rc)
> > @@ -1491,25 +1558,26 @@ static int __init netback_init(void)
> >  failed_init_xenbus:
> >  	page_pool_destroy();
> >  failed_init_pool:
> > -	free_percpu(meta);
> > -failed_init_meta:
> > -	free_percpu(grant_copy_op);
> > -failed_init_gco:
> > -	free_percpu(tx_copy_ops);
> > +	for_each_online_cpu(cpu)
> > +		__free_percpu_scratch_space(cpu);
> >  failed_init:
> >  	return rc;
> 
> We don't want to try to clean up the per_cpu_spaces that might
> have gotten allocated in the loop?
> 

Good catch, thanks.


Wei.

> > -
> >  }
> >  
> >  module_init(netback_init);
> >  
> >  static void __exit netback_exit(void)
> >  {
> > +	int cpu;
> > +
> >  	xenvif_xenbus_exit();
> >  	page_pool_destroy();
> > -	free_percpu(meta);
> > -	free_percpu(grant_copy_op);
> > -	free_percpu(tx_copy_ops);
> > +
> > +	unregister_hotcpu_notifier(&netback_notifier_block);
> > +
> > +	/* Since we're here, nobody else will touch per-cpu area. */
> > +	for_each_online_cpu(cpu)
> > +		__free_percpu_scratch_space(cpu);
> >  }
> >  module_exit(netback_exit);
> >  
> > -- 
> > 1.7.2.5



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:53:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBL2-0004dR-2c; Tue, 31 Jan 2012 10:53:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RsBL1-0004dD-6F
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:53:23 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328007196!9267814!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32712 invoked from network); 31 Jan 2012 10:53:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 10:53:17 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0VArGCr012955
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 05:53:16 -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 q0VArDVA008516; Tue, 31 Jan 2012 05:53:14 -0500
Message-ID: <4F27C875.8080503@redhat.com>
Date: Tue, 31 Jan 2012 11:54:45 +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: <4F27B5AD.9050709@redhat.com>
	<4F27D232020000780007012B@nat28.tlf.novell.com>
In-Reply-To: <4F27D232020000780007012B@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Petr Matousek <pmatouse@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/12 11:36, Jan Beulich wrote:
>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com>  wrote:
>> in the qemu-xen-unstable tree
>> (git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function
>> [i386-dm/helper2.c] makes the process exit if the operand size is wrong.
>> Blame: 6040eea5 ("More files imported from xen-unstable
>> 17192:59b8768d0d0d").
>>
>> In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function
>> [xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c
>> ("xen: Initialize event channels and io rings").
>>
>> Is it justified to kill the emulator when this happens (eg. memory
>> mapped IO with 64-bit operand)?
>
> Afaict, this is not about MMIO, but PIO.

One possible way seems to be (see 
http://xenbits.xensource.com/hg/linux-2.6.18-xen.hg/rev/1141):

vmx_hpw_miss() [xen/arch/ia64/vmx/vmx_fault.c]
-> emulate_io_inst() [xen/arch/ia64/vmx/mmio.c]
   -> mmio_access()
     -> legacy_io_access()
       -> vmx_send_assist_req() [xen/arch/ia64/vmx/vmx_support.c]
         -> notify_via_xen_event_channel() [xen/common/event_channel.c]

and in qemu-xen-unstable,

cpu_handle_ioreq() [i386-dm/helper2.c], set up in main_loop()
-> __handle_ioreq()
   -> cpu_ioreq_pio()
     -> do_inp()

Thanks,
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:53:35 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:53:35 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBL2-0004dR-2c; Tue, 31 Jan 2012 10:53:24 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RsBL1-0004dD-6F
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:53:23 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328007196!9267814!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32712 invoked from network); 31 Jan 2012 10:53:17 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-7.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 10:53:17 -0000
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
	(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0VArGCr012955
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 05:53:16 -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 q0VArDVA008516; Tue, 31 Jan 2012 05:53:14 -0500
Message-ID: <4F27C875.8080503@redhat.com>
Date: Tue, 31 Jan 2012 11:54:45 +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: <4F27B5AD.9050709@redhat.com>
	<4F27D232020000780007012B@nat28.tlf.novell.com>
In-Reply-To: <4F27D232020000780007012B@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Petr Matousek <pmatouse@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/12 11:36, Jan Beulich wrote:
>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com>  wrote:
>> in the qemu-xen-unstable tree
>> (git://xenbits.xen.org/qemu-xen-unstable.git), the do_inp() function
>> [i386-dm/helper2.c] makes the process exit if the operand size is wrong.
>> Blame: 6040eea5 ("More files imported from xen-unstable
>> 17192:59b8768d0d0d").
>>
>> In the qemu tree (git://git.qemu.org/qemu.git), the do_inp() function
>> [xen-all.c] does the same (via hw_error() / abort()). Blame: 9ce94e7c
>> ("xen: Initialize event channels and io rings").
>>
>> Is it justified to kill the emulator when this happens (eg. memory
>> mapped IO with 64-bit operand)?
>
> Afaict, this is not about MMIO, but PIO.

One possible way seems to be (see 
http://xenbits.xensource.com/hg/linux-2.6.18-xen.hg/rev/1141):

vmx_hpw_miss() [xen/arch/ia64/vmx/vmx_fault.c]
-> emulate_io_inst() [xen/arch/ia64/vmx/mmio.c]
   -> mmio_access()
     -> legacy_io_access()
       -> vmx_send_assist_req() [xen/arch/ia64/vmx/vmx_support.c]
         -> notify_via_xen_event_channel() [xen/common/event_channel.c]

and in qemu-xen-unstable,

cpu_handle_ioreq() [i386-dm/helper2.c], set up in main_loop()
-> __handle_ioreq()
   -> cpu_ioreq_pio()
     -> do_inp()

Thanks,
Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:54:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBLY-0004gA-Fs; Tue, 31 Jan 2012 10:53: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 1RsBLW-0004fc-U5
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:53:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328007168!59101579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10453 invoked from network); 31 Jan 2012 10:52: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;
	31 Jan 2012 10:52:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:53:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:53:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:53:23 +0000
In-Reply-To: <0129989da2cda789f86f.1327972925@athos.nss.cs.ubc.ca>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
	<0129989da2cda789f86f.1327972925@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328007203.26983.347.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> @@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
>      }
>  
>      memset(&callbacks, 0, sizeof(callbacks));
> -    callbacks.suspend = libxl__domain_suspend_common_callback;
> +    if (r_info != NULL) {
> +        /* save_callbacks:
> +         * suspend - called after expiration of checkpoint interval,
> +         *           to *suspend* the domain.
> +         *
> +         * postcopy - called after the domain's dirty pages have been
> +         *            copied into an output buffer. We *resume* the domain
> +         *            & the device model, return to the caller. Caller then
> +         *            flushes the output buffer, while the domain continues to run.
> +         *
> +         * checkpoint - called after the memory checkpoint has been flushed out
> +         *              into the network. Send the saved device state, *wait*
> +         *              for checkpoint ack and *release* the network buffer (TBD).
> +         *              Then *sleep* for the checkpoint interval.
> +         */

Please can you put this next to the definition of the struct (in
xenguest.h). Otherwise this patch looks ok to me.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 10:54:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 10:54:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBLY-0004gA-Fs; Tue, 31 Jan 2012 10:53: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 1RsBLW-0004fc-U5
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 10:53:55 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328007168!59101579!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10453 invoked from network); 31 Jan 2012 10:52: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;
	31 Jan 2012 10:52:48 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385470"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:53:23 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:53:23 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 10:53:23 +0000
In-Reply-To: <0129989da2cda789f86f.1327972925@athos.nss.cs.ubc.ca>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
	<0129989da2cda789f86f.1327972925@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328007203.26983.347.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Remus -
	suspend/postflush/commit callbacks
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> @@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
>      }
>  
>      memset(&callbacks, 0, sizeof(callbacks));
> -    callbacks.suspend = libxl__domain_suspend_common_callback;
> +    if (r_info != NULL) {
> +        /* save_callbacks:
> +         * suspend - called after expiration of checkpoint interval,
> +         *           to *suspend* the domain.
> +         *
> +         * postcopy - called after the domain's dirty pages have been
> +         *            copied into an output buffer. We *resume* the domain
> +         *            & the device model, return to the caller. Caller then
> +         *            flushes the output buffer, while the domain continues to run.
> +         *
> +         * checkpoint - called after the memory checkpoint has been flushed out
> +         *              into the network. Send the saved device state, *wait*
> +         *              for checkpoint ack and *release* the network buffer (TBD).
> +         *              Then *sleep* for the checkpoint interval.
> +         */

Please can you put this next to the definition of the struct (in
xenguest.h). Otherwise this patch looks ok to me.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:00:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11: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 1RsBRU-0004zi-A6; Tue, 31 Jan 2012 11:00: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 1RsBRS-0004xm-FS
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:00:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328007596!10724000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31541 invoked from network); 31 Jan 2012 10:59:56 -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;
	31 Jan 2012 10:59:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:58:38 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:58:38 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120130213926.GB16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
Date: Tue, 31 Jan 2012 10:58:51 +0000
Message-ID: <1328007531.5553.65.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 21:39 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 02:45:33PM +0000, Wei Liu wrote:
> > Use DMA API to allocate ring pages, because we need to get machine
> > contiginous memory.
> 
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/net/xen-netfront.c |  258 ++++++++++++++++++++++++++++++++------------
> >  1 files changed, 187 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 01f589d..32ec212 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -66,9 +66,18 @@ struct netfront_cb {
> >
> >  #define GRANT_INVALID_REF    0
> >
> > -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> > -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> > -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> > +#define XENNET_MAX_RING_PAGE_ORDER 2
> > +#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
> > +
> > +#define NET_TX_RING_SIZE(_nr_pages)                                  \
> > +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> > +#define NET_RX_RING_SIZE(_nr_pages)                                  \
> > +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> > +
> > +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +
> > +#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE
> >
> >  struct netfront_stats {
> >       u64                     rx_packets;
> > @@ -84,12 +93,20 @@ struct netfront_info {
> >
> >       struct napi_struct napi;
> >
> > +     /* Statistics */
> > +     struct netfront_stats __percpu *stats;
> > +
> > +     unsigned long rx_gso_checksum_fixup;
> > +
> >       unsigned int evtchn;
> >       struct xenbus_device *xbdev;
> >
> >       spinlock_t   tx_lock;
> >       struct xen_netif_tx_front_ring tx;
> > -     int tx_ring_ref;
> > +     dma_addr_t tx_ring_dma_handle;
> > +     int tx_ring_ref[XENNET_MAX_RING_PAGES];
> > +     int tx_ring_page_order;
> > +     int tx_ring_pages;
> >
> >       /*
> >        * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
> > @@ -103,36 +120,34 @@ struct netfront_info {
> >       union skb_entry {
> >               struct sk_buff *skb;
> >               unsigned long link;
> > -     } tx_skbs[NET_TX_RING_SIZE];
> > +     } tx_skbs[XENNET_MAX_TX_RING_SIZE];
> >       grant_ref_t gref_tx_head;
> > -     grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
> > +     grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
> >       unsigned tx_skb_freelist;
> >
> >       spinlock_t   rx_lock ____cacheline_aligned_in_smp;
> >       struct xen_netif_rx_front_ring rx;
> > -     int rx_ring_ref;
> > +     dma_addr_t rx_ring_dma_handle;
> > +     int rx_ring_ref[XENNET_MAX_RING_PAGES];
> > +     int rx_ring_page_order;
> > +     int rx_ring_pages;
> >
> >       /* Receive-ring batched refills. */
> >  #define RX_MIN_TARGET 8
> >  #define RX_DFL_MIN_TARGET 64
> > -#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> > +#define RX_MAX_TARGET XENNET_MAX_RX_RING_SIZE
> >       unsigned rx_min_target, rx_max_target, rx_target;
> >       struct sk_buff_head rx_batch;
> >
> >       struct timer_list rx_refill_timer;
> >
> > -     struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
> > +     struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
> >       grant_ref_t gref_rx_head;
> > -     grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
> > -
> > -     unsigned long rx_pfn_array[NET_RX_RING_SIZE];
> > -     struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
> > -     struct mmu_update rx_mmu[NET_RX_RING_SIZE];
> > -
> > -     /* Statistics */
> > -     struct netfront_stats __percpu *stats;
> > +     grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
> >
> > -     unsigned long rx_gso_checksum_fixup;
> > +     unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
> > +     struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
> > +     struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
> >  };
> >
> >  struct netfront_rx_info {
> > @@ -170,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
> >       return id;
> >  }
> >
> > -static int xennet_rxidx(RING_IDX idx)
> > +static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
> >  {
> > -     return idx & (NET_RX_RING_SIZE - 1);
> > +     return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
> >  }
> >
> >  static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
> >                                        RING_IDX ri)
> >  {
> > -     int i = xennet_rxidx(ri);
> > +     int i = xennet_rxidx(ri, np);
> >       struct sk_buff *skb = np->rx_skbs[i];
> >       np->rx_skbs[i] = NULL;
> >       return skb;
> > @@ -187,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
> >  static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
> >                                           RING_IDX ri)
> >  {
> > -     int i = xennet_rxidx(ri);
> > +     int i = xennet_rxidx(ri, np);
> >       grant_ref_t ref = np->grant_rx_ref[i];
> >       np->grant_rx_ref[i] = GRANT_INVALID_REF;
> >       return ref;
> > @@ -300,7 +315,7 @@ no_skb:
> >
> >               skb->dev = dev;
> >
> > -             id = xennet_rxidx(req_prod + i);
> > +             id = xennet_rxidx(req_prod + i, np);
> >
> >               BUG_ON(np->rx_skbs[id]);
> >               np->rx_skbs[id] = skb;
> > @@ -596,7 +611,7 @@ static int xennet_close(struct net_device *dev)
> >  static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
> >                               grant_ref_t ref)
> >  {
> > -     int new = xennet_rxidx(np->rx.req_prod_pvt);
> > +     int new = xennet_rxidx(np->rx.req_prod_pvt, np);
> >
> >       BUG_ON(np->rx_skbs[new]);
> >       np->rx_skbs[new] = skb;
> > @@ -1089,7 +1104,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
> >       struct sk_buff *skb;
> >       int i;
> >
> > -     for (i = 0; i < NET_TX_RING_SIZE; i++) {
> > +     for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
> >               /* Skip over entries which are actually freelist references */
> >               if (skb_entry_is_link(&np->tx_skbs[i]))
> >                       continue;
> > @@ -1123,7 +1138,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
> >
> >       spin_lock_bh(&np->rx_lock);
> >
> > -     for (id = 0; id < NET_RX_RING_SIZE; id++) {
> > +     for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
> >               ref = np->grant_rx_ref[id];
> >               if (ref == GRANT_INVALID_REF) {
> >                       unused++;
> > @@ -1305,13 +1320,13 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
> >
> >       /* Initialise tx_skbs as a free chain containing every entry. */
> >       np->tx_skb_freelist = 0;
> > -     for (i = 0; i < NET_TX_RING_SIZE; i++) {
> > +     for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
> >               skb_entry_set_link(&np->tx_skbs[i], i+1);
> >               np->grant_tx_ref[i] = GRANT_INVALID_REF;
> >       }
> >
> >       /* Clear out rx_skbs */
> > -     for (i = 0; i < NET_RX_RING_SIZE; i++) {
> > +     for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
> >               np->rx_skbs[i] = NULL;
> >               np->grant_rx_ref[i] = GRANT_INVALID_REF;
> >       }
> > @@ -1409,15 +1424,11 @@ static int __devinit netfront_probe(struct xenbus_device *dev,
> >       return err;
> >  }
> >
> > -static void xennet_end_access(int ref, void *page)
> > -{
> > -     /* This frees the page as a side-effect */
> > -     if (ref != GRANT_INVALID_REF)
> > -             gnttab_end_foreign_access(ref, 0, (unsigned long)page);
> > -}
> > -
> >  static void xennet_disconnect_backend(struct netfront_info *info)
> >  {
> > +     int i;
> > +     struct xenbus_device *dev = info->xbdev;
> > +
> >       /* Stop old i/f to prevent errors whilst we rebuild the state. */
> >       spin_lock_bh(&info->rx_lock);
> >       spin_lock_irq(&info->tx_lock);
> > @@ -1429,12 +1440,24 @@ static void xennet_disconnect_backend(struct netfront_info *info)
> >               unbind_from_irqhandler(info->netdev->irq, info->netdev);
> >       info->evtchn = info->netdev->irq = 0;
> >
> > -     /* End access and free the pages */
> > -     xennet_end_access(info->tx_ring_ref, info->tx.sring);
> > -     xennet_end_access(info->rx_ring_ref, info->rx.sring);
> > +     for (i = 0; i < info->tx_ring_pages; i++) {
> > +             int ref = info->tx_ring_ref[i];
> > +             gnttab_end_foreign_access_ref(ref, 0);
> > +             info->tx_ring_ref[i] = GRANT_INVALID_REF;
> > +     }
> > +     dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > +                       (void *)info->tx.sring,
> > +                       info->tx_ring_dma_handle);
> > +
> > +     for (i = 0; i < info->rx_ring_pages; i++) {
> > +             int ref = info->rx_ring_ref[i];
> > +             gnttab_end_foreign_access_ref(ref, 0);
> > +             info->rx_ring_ref[i] = GRANT_INVALID_REF;
> > +     }
> > +     dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
> > +                       (void *)info->rx.sring,
> > +                       info->rx_ring_dma_handle);
> >
> > -     info->tx_ring_ref = GRANT_INVALID_REF;
> > -     info->rx_ring_ref = GRANT_INVALID_REF;
> >       info->tx.sring = NULL;
> >       info->rx.sring = NULL;
> >  }
> > @@ -1483,9 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >       struct xen_netif_rx_sring *rxs;
> >       int err;
> >       struct net_device *netdev = info->netdev;
> > +     unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> > +     int i, j;
> >
> > -     info->tx_ring_ref = GRANT_INVALID_REF;
> > -     info->rx_ring_ref = GRANT_INVALID_REF;
> > +     for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
> > +             info->tx_ring_ref[i] = GRANT_INVALID_REF;
> > +             info->rx_ring_ref[i] = GRANT_INVALID_REF;
> > +     }
> >       info->rx.sring = NULL;
> >       info->tx.sring = NULL;
> >       netdev->irq = 0;
> > @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >               goto fail;
> >       }
> >
> > -     txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> > +     err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> > +                        "max-tx-ring-page-order", "%u",
> > +                        &max_tx_ring_page_order);
> > +     if (err < 0) {
> > +             info->tx_ring_page_order = 0;
> > +             dev_info(&dev->dev, "single tx ring\n");
> > +     } else {
> > +             info->tx_ring_page_order = max_tx_ring_page_order;
> > +             dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> > +                      max_tx_ring_page_order);
> > +     }
> > +     info->tx_ring_pages = (1U << info->tx_ring_page_order);
> > +
> > +     txs = (struct xen_netif_tx_sring *)
> > +             dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > +                                &info->tx_ring_dma_handle,
> > +                                __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> 
> Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
> But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
> clue whether you are OK getting pages under 4GB or above it (so 64-bit support).
> 
> If you don't supply a 'dev' it will assume 4GB. But when you are run this as a
> pure PV guest that won't matter the slighest b/I there are no DMA code in action
> (well, there is dma_alloc_coherent - which looking at the code would NULL it seems).
> 
> Anyhow, if you get to have more than 4GB in the guest or do PCI passthrough and use
> 'iommu=soft'- at which point the Xen SWIOTLB will kick and you will end up 'swizzling'
> the pages to be under 4GB. That can be fixed if you declerae a 'fake' device where you set
> the coherent_dma_mask to DMA_BIT_MASK(64).
> 

This seems to be a reasonable solution. I could not set netfront's DMA
mask, that's why I used NULL device. And, how do I create a 'fake'
device?

> But if you boot the guest under HVM, then it will use the generic SWIOTLB code, which
> won't guaranteeing the pages to be "machine" contingous but will be "guest machine"
> contingous. Is that sufficient for this?
> 

For HVM, this is sufficient.

> How did you test this? Did you supply iommu=soft  to your guest or booted it
> with more than 4GB?
> 

I haven't tested guest with more than 4GB RAM.


Wei.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:00:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11: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 1RsBRU-0004zi-A6; Tue, 31 Jan 2012 11:00: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 1RsBRS-0004xm-FS
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:00:02 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328007596!10724000!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31541 invoked from network); 31 Jan 2012 10:59:56 -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;
	31 Jan 2012 10:59:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385649"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 10:58:38 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 10:58:38 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120130213926.GB16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
Date: Tue, 31 Jan 2012 10:58:51 +0000
Message-ID: <1328007531.5553.65.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 21:39 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 02:45:33PM +0000, Wei Liu wrote:
> > Use DMA API to allocate ring pages, because we need to get machine
> > contiginous memory.
> 
> >
> > Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> > ---
> >  drivers/net/xen-netfront.c |  258 ++++++++++++++++++++++++++++++++------------
> >  1 files changed, 187 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> > index 01f589d..32ec212 100644
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -66,9 +66,18 @@ struct netfront_cb {
> >
> >  #define GRANT_INVALID_REF    0
> >
> > -#define NET_TX_RING_SIZE __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE)
> > -#define NET_RX_RING_SIZE __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE)
> > -#define TX_MAX_TARGET min_t(int, NET_TX_RING_SIZE, 256)
> > +#define XENNET_MAX_RING_PAGE_ORDER 2
> > +#define XENNET_MAX_RING_PAGES      (1U << XENNET_MAX_RING_PAGE_ORDER)
> > +
> > +#define NET_TX_RING_SIZE(_nr_pages)                                  \
> > +     __CONST_RING_SIZE(xen_netif_tx, PAGE_SIZE * (_nr_pages))
> > +#define NET_RX_RING_SIZE(_nr_pages)                                  \
> > +     __CONST_RING_SIZE(xen_netif_rx, PAGE_SIZE * (_nr_pages))
> > +
> > +#define XENNET_MAX_TX_RING_SIZE NET_TX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +#define XENNET_MAX_RX_RING_SIZE NET_RX_RING_SIZE(XENNET_MAX_RING_PAGES)
> > +
> > +#define TX_MAX_TARGET XENNET_MAX_TX_RING_SIZE
> >
> >  struct netfront_stats {
> >       u64                     rx_packets;
> > @@ -84,12 +93,20 @@ struct netfront_info {
> >
> >       struct napi_struct napi;
> >
> > +     /* Statistics */
> > +     struct netfront_stats __percpu *stats;
> > +
> > +     unsigned long rx_gso_checksum_fixup;
> > +
> >       unsigned int evtchn;
> >       struct xenbus_device *xbdev;
> >
> >       spinlock_t   tx_lock;
> >       struct xen_netif_tx_front_ring tx;
> > -     int tx_ring_ref;
> > +     dma_addr_t tx_ring_dma_handle;
> > +     int tx_ring_ref[XENNET_MAX_RING_PAGES];
> > +     int tx_ring_page_order;
> > +     int tx_ring_pages;
> >
> >       /*
> >        * {tx,rx}_skbs store outstanding skbuffs. Free tx_skb entries
> > @@ -103,36 +120,34 @@ struct netfront_info {
> >       union skb_entry {
> >               struct sk_buff *skb;
> >               unsigned long link;
> > -     } tx_skbs[NET_TX_RING_SIZE];
> > +     } tx_skbs[XENNET_MAX_TX_RING_SIZE];
> >       grant_ref_t gref_tx_head;
> > -     grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
> > +     grant_ref_t grant_tx_ref[XENNET_MAX_TX_RING_SIZE];
> >       unsigned tx_skb_freelist;
> >
> >       spinlock_t   rx_lock ____cacheline_aligned_in_smp;
> >       struct xen_netif_rx_front_ring rx;
> > -     int rx_ring_ref;
> > +     dma_addr_t rx_ring_dma_handle;
> > +     int rx_ring_ref[XENNET_MAX_RING_PAGES];
> > +     int rx_ring_page_order;
> > +     int rx_ring_pages;
> >
> >       /* Receive-ring batched refills. */
> >  #define RX_MIN_TARGET 8
> >  #define RX_DFL_MIN_TARGET 64
> > -#define RX_MAX_TARGET min_t(int, NET_RX_RING_SIZE, 256)
> > +#define RX_MAX_TARGET XENNET_MAX_RX_RING_SIZE
> >       unsigned rx_min_target, rx_max_target, rx_target;
> >       struct sk_buff_head rx_batch;
> >
> >       struct timer_list rx_refill_timer;
> >
> > -     struct sk_buff *rx_skbs[NET_RX_RING_SIZE];
> > +     struct sk_buff *rx_skbs[XENNET_MAX_RX_RING_SIZE];
> >       grant_ref_t gref_rx_head;
> > -     grant_ref_t grant_rx_ref[NET_RX_RING_SIZE];
> > -
> > -     unsigned long rx_pfn_array[NET_RX_RING_SIZE];
> > -     struct multicall_entry rx_mcl[NET_RX_RING_SIZE+1];
> > -     struct mmu_update rx_mmu[NET_RX_RING_SIZE];
> > -
> > -     /* Statistics */
> > -     struct netfront_stats __percpu *stats;
> > +     grant_ref_t grant_rx_ref[XENNET_MAX_RX_RING_SIZE];
> >
> > -     unsigned long rx_gso_checksum_fixup;
> > +     unsigned long rx_pfn_array[XENNET_MAX_RX_RING_SIZE];
> > +     struct multicall_entry rx_mcl[XENNET_MAX_RX_RING_SIZE+1];
> > +     struct mmu_update rx_mmu[XENNET_MAX_RX_RING_SIZE];
> >  };
> >
> >  struct netfront_rx_info {
> > @@ -170,15 +185,15 @@ static unsigned short get_id_from_freelist(unsigned *head,
> >       return id;
> >  }
> >
> > -static int xennet_rxidx(RING_IDX idx)
> > +static int xennet_rxidx(RING_IDX idx, struct netfront_info *info)
> >  {
> > -     return idx & (NET_RX_RING_SIZE - 1);
> > +     return idx & (NET_RX_RING_SIZE(info->rx_ring_pages) - 1);
> >  }
> >
> >  static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
> >                                        RING_IDX ri)
> >  {
> > -     int i = xennet_rxidx(ri);
> > +     int i = xennet_rxidx(ri, np);
> >       struct sk_buff *skb = np->rx_skbs[i];
> >       np->rx_skbs[i] = NULL;
> >       return skb;
> > @@ -187,7 +202,7 @@ static struct sk_buff *xennet_get_rx_skb(struct netfront_info *np,
> >  static grant_ref_t xennet_get_rx_ref(struct netfront_info *np,
> >                                           RING_IDX ri)
> >  {
> > -     int i = xennet_rxidx(ri);
> > +     int i = xennet_rxidx(ri, np);
> >       grant_ref_t ref = np->grant_rx_ref[i];
> >       np->grant_rx_ref[i] = GRANT_INVALID_REF;
> >       return ref;
> > @@ -300,7 +315,7 @@ no_skb:
> >
> >               skb->dev = dev;
> >
> > -             id = xennet_rxidx(req_prod + i);
> > +             id = xennet_rxidx(req_prod + i, np);
> >
> >               BUG_ON(np->rx_skbs[id]);
> >               np->rx_skbs[id] = skb;
> > @@ -596,7 +611,7 @@ static int xennet_close(struct net_device *dev)
> >  static void xennet_move_rx_slot(struct netfront_info *np, struct sk_buff *skb,
> >                               grant_ref_t ref)
> >  {
> > -     int new = xennet_rxidx(np->rx.req_prod_pvt);
> > +     int new = xennet_rxidx(np->rx.req_prod_pvt, np);
> >
> >       BUG_ON(np->rx_skbs[new]);
> >       np->rx_skbs[new] = skb;
> > @@ -1089,7 +1104,7 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
> >       struct sk_buff *skb;
> >       int i;
> >
> > -     for (i = 0; i < NET_TX_RING_SIZE; i++) {
> > +     for (i = 0; i < NET_TX_RING_SIZE(np->tx_ring_pages); i++) {
> >               /* Skip over entries which are actually freelist references */
> >               if (skb_entry_is_link(&np->tx_skbs[i]))
> >                       continue;
> > @@ -1123,7 +1138,7 @@ static void xennet_release_rx_bufs(struct netfront_info *np)
> >
> >       spin_lock_bh(&np->rx_lock);
> >
> > -     for (id = 0; id < NET_RX_RING_SIZE; id++) {
> > +     for (id = 0; id < NET_RX_RING_SIZE(np->rx_ring_pages); id++) {
> >               ref = np->grant_rx_ref[id];
> >               if (ref == GRANT_INVALID_REF) {
> >                       unused++;
> > @@ -1305,13 +1320,13 @@ static struct net_device * __devinit xennet_create_dev(struct xenbus_device *dev
> >
> >       /* Initialise tx_skbs as a free chain containing every entry. */
> >       np->tx_skb_freelist = 0;
> > -     for (i = 0; i < NET_TX_RING_SIZE; i++) {
> > +     for (i = 0; i < XENNET_MAX_TX_RING_SIZE; i++) {
> >               skb_entry_set_link(&np->tx_skbs[i], i+1);
> >               np->grant_tx_ref[i] = GRANT_INVALID_REF;
> >       }
> >
> >       /* Clear out rx_skbs */
> > -     for (i = 0; i < NET_RX_RING_SIZE; i++) {
> > +     for (i = 0; i < XENNET_MAX_RX_RING_SIZE; i++) {
> >               np->rx_skbs[i] = NULL;
> >               np->grant_rx_ref[i] = GRANT_INVALID_REF;
> >       }
> > @@ -1409,15 +1424,11 @@ static int __devinit netfront_probe(struct xenbus_device *dev,
> >       return err;
> >  }
> >
> > -static void xennet_end_access(int ref, void *page)
> > -{
> > -     /* This frees the page as a side-effect */
> > -     if (ref != GRANT_INVALID_REF)
> > -             gnttab_end_foreign_access(ref, 0, (unsigned long)page);
> > -}
> > -
> >  static void xennet_disconnect_backend(struct netfront_info *info)
> >  {
> > +     int i;
> > +     struct xenbus_device *dev = info->xbdev;
> > +
> >       /* Stop old i/f to prevent errors whilst we rebuild the state. */
> >       spin_lock_bh(&info->rx_lock);
> >       spin_lock_irq(&info->tx_lock);
> > @@ -1429,12 +1440,24 @@ static void xennet_disconnect_backend(struct netfront_info *info)
> >               unbind_from_irqhandler(info->netdev->irq, info->netdev);
> >       info->evtchn = info->netdev->irq = 0;
> >
> > -     /* End access and free the pages */
> > -     xennet_end_access(info->tx_ring_ref, info->tx.sring);
> > -     xennet_end_access(info->rx_ring_ref, info->rx.sring);
> > +     for (i = 0; i < info->tx_ring_pages; i++) {
> > +             int ref = info->tx_ring_ref[i];
> > +             gnttab_end_foreign_access_ref(ref, 0);
> > +             info->tx_ring_ref[i] = GRANT_INVALID_REF;
> > +     }
> > +     dma_free_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > +                       (void *)info->tx.sring,
> > +                       info->tx_ring_dma_handle);
> > +
> > +     for (i = 0; i < info->rx_ring_pages; i++) {
> > +             int ref = info->rx_ring_ref[i];
> > +             gnttab_end_foreign_access_ref(ref, 0);
> > +             info->rx_ring_ref[i] = GRANT_INVALID_REF;
> > +     }
> > +     dma_free_coherent(NULL, PAGE_SIZE * info->rx_ring_pages,
> > +                       (void *)info->rx.sring,
> > +                       info->rx_ring_dma_handle);
> >
> > -     info->tx_ring_ref = GRANT_INVALID_REF;
> > -     info->rx_ring_ref = GRANT_INVALID_REF;
> >       info->tx.sring = NULL;
> >       info->rx.sring = NULL;
> >  }
> > @@ -1483,9 +1506,13 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >       struct xen_netif_rx_sring *rxs;
> >       int err;
> >       struct net_device *netdev = info->netdev;
> > +     unsigned int max_tx_ring_page_order, max_rx_ring_page_order;
> > +     int i, j;
> >
> > -     info->tx_ring_ref = GRANT_INVALID_REF;
> > -     info->rx_ring_ref = GRANT_INVALID_REF;
> > +     for (i = 0; i < XENNET_MAX_RING_PAGES; i++) {
> > +             info->tx_ring_ref[i] = GRANT_INVALID_REF;
> > +             info->rx_ring_ref[i] = GRANT_INVALID_REF;
> > +     }
> >       info->rx.sring = NULL;
> >       info->tx.sring = NULL;
> >       netdev->irq = 0;
> > @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> >               goto fail;
> >       }
> >
> > -     txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> > +     err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> > +                        "max-tx-ring-page-order", "%u",
> > +                        &max_tx_ring_page_order);
> > +     if (err < 0) {
> > +             info->tx_ring_page_order = 0;
> > +             dev_info(&dev->dev, "single tx ring\n");
> > +     } else {
> > +             info->tx_ring_page_order = max_tx_ring_page_order;
> > +             dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> > +                      max_tx_ring_page_order);
> > +     }
> > +     info->tx_ring_pages = (1U << info->tx_ring_page_order);
> > +
> > +     txs = (struct xen_netif_tx_sring *)
> > +             dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > +                                &info->tx_ring_dma_handle,
> > +                                __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> 
> Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
> But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
> clue whether you are OK getting pages under 4GB or above it (so 64-bit support).
> 
> If you don't supply a 'dev' it will assume 4GB. But when you are run this as a
> pure PV guest that won't matter the slighest b/I there are no DMA code in action
> (well, there is dma_alloc_coherent - which looking at the code would NULL it seems).
> 
> Anyhow, if you get to have more than 4GB in the guest or do PCI passthrough and use
> 'iommu=soft'- at which point the Xen SWIOTLB will kick and you will end up 'swizzling'
> the pages to be under 4GB. That can be fixed if you declerae a 'fake' device where you set
> the coherent_dma_mask to DMA_BIT_MASK(64).
> 

This seems to be a reasonable solution. I could not set netfront's DMA
mask, that's why I used NULL device. And, how do I create a 'fake'
device?

> But if you boot the guest under HVM, then it will use the generic SWIOTLB code, which
> won't guaranteeing the pages to be "machine" contingous but will be "guest machine"
> contingous. Is that sufficient for this?
> 

For HVM, this is sufficient.

> How did you test this? Did you supply iommu=soft  to your guest or booted it
> with more than 4GB?
> 

I haven't tested guest with more than 4GB RAM.


Wei.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:01:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBS9-00052w-7g; Tue, 31 Jan 2012 11:00:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1RsBS7-00052N-KP
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:00:43 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328007626!13077428!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26916 invoked from network); 31 Jan 2012 11:00:37 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:00:37 -0000
Received: by ggnu1 with SMTP id u1so4677989ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 03:00:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=T940BcmQ0iZHqzMmF9GZsIIPxt0t0iQ8RbyWNawtpi0=;
	b=N4raONNV1M0upQ9HEeLCXLysocZH+FcY6/vOxDzns/XQmBXpMWUzY/j9aGEaRJ4t8V
	V1TDEo3/Cu8bQqMUy8WGyWDWyjTGCRMNhpwt9paMin1CKjWG2qbujBjgvM4diOLP9Tc4
	03ERDlIxZtuJ5QIJ+UZ5vQp2a/2Lo3v69U8UQ=
Received: by 10.236.9.33 with SMTP id 21mr2388683yhs.39.1328007613152;
	Tue, 31 Jan 2012 03:00:13 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id n24sm32530582yhj.13.2012.01.31.03.00.10
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 03:00:12 -0800 (PST)
Message-ID: <4F27C9B8.3030006@cantab.net>
Date: Tue, 31 Jan 2012 11:00:08 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ben Guthro <ben@guthro.net>
References: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>	<4F26C68C.7020600@citrix.com>
	<CAOvdn6VDAJZw6hYAvZ-1CmEg8Ts0-0PB4gVUX4nq2ap=gO0VVQ@mail.gmail.com>
In-Reply-To: <CAOvdn6VDAJZw6hYAvZ-1CmEg8Ts0-0PB4gVUX4nq2ap=gO0VVQ@mail.gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek <konrad@darnok.org>
Subject: Re: [Xen-devel] debugging 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 30/01/12 17:32, Ben Guthro wrote:
> Yes, it helped a lot!
> This seems to have resolved the hang - thanks for pointing it my way!
> 
> So - if I'm reading the git log correctly, I should just have to
> cherry-pick 7a7546b377bdaa25ac77f33d9433c59f259b9688 from mainline?

Yes.

> It seems like this may be something to CC the -stable queue on, IMHO.

It's already queued.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:01:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBS9-00052w-7g; Tue, 31 Jan 2012 11:00:45 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <d.vrabel.98@gmail.com>) id 1RsBS7-00052N-KP
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:00:43 +0000
X-Env-Sender: d.vrabel.98@gmail.com
X-Msg-Ref: server-12.tower-182.messagelabs.com!1328007626!13077428!1
X-Originating-IP: [209.85.161.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26916 invoked from network); 31 Jan 2012 11:00:37 -0000
Received: from mail-gx0-f171.google.com (HELO mail-gx0-f171.google.com)
	(209.85.161.171)
	by server-12.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:00:37 -0000
Received: by ggnu1 with SMTP id u1so4677989ggn.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 03:00:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=T940BcmQ0iZHqzMmF9GZsIIPxt0t0iQ8RbyWNawtpi0=;
	b=N4raONNV1M0upQ9HEeLCXLysocZH+FcY6/vOxDzns/XQmBXpMWUzY/j9aGEaRJ4t8V
	V1TDEo3/Cu8bQqMUy8WGyWDWyjTGCRMNhpwt9paMin1CKjWG2qbujBjgvM4diOLP9Tc4
	03ERDlIxZtuJ5QIJ+UZ5vQp2a/2Lo3v69U8UQ=
Received: by 10.236.9.33 with SMTP id 21mr2388683yhs.39.1328007613152;
	Tue, 31 Jan 2012 03:00:13 -0800 (PST)
Received: from [10.80.2.76] (firewall.ctxuk.citrix.com. [62.200.22.2])
	by mx.google.com with ESMTPS id n24sm32530582yhj.13.2012.01.31.03.00.10
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 03:00:12 -0800 (PST)
Message-ID: <4F27C9B8.3030006@cantab.net>
Date: Tue, 31 Jan 2012 11:00:08 +0000
From: David Vrabel <dvrabel@cantab.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: Ben Guthro <ben@guthro.net>
References: <CAOvdn6We7=dqynZnC9eRosrQV9LzEgPAJMmvWh=wa87Ty+6ggg@mail.gmail.com>	<4F26C68C.7020600@citrix.com>
	<CAOvdn6VDAJZw6hYAvZ-1CmEg8Ts0-0PB4gVUX4nq2ap=gO0VVQ@mail.gmail.com>
In-Reply-To: <CAOvdn6VDAJZw6hYAvZ-1CmEg8Ts0-0PB4gVUX4nq2ap=gO0VVQ@mail.gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen Devel <xen-devel@lists.xensource.com>,
	Konrad Rzeszutek <konrad@darnok.org>
Subject: Re: [Xen-devel] debugging 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 30/01/12 17:32, Ben Guthro wrote:
> Yes, it helped a lot!
> This seems to have resolved the hang - thanks for pointing it my way!
> 
> So - if I'm reading the git log correctly, I should just have to
> cherry-pick 7a7546b377bdaa25ac77f33d9433c59f259b9688 from mainline?

Yes.

> It seems like this may be something to CC the -stable queue on, IMHO.

It's already queued.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:01:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBSA-00053D-KM; Tue, 31 Jan 2012 11:00:46 +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 1RsBS8-00052S-MH
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:00:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328007638!12480545!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6714 invoked from network); 31 Jan 2012 11:00:38 -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;
	31 Jan 2012 11:00:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:00: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;
	Tue, 31 Jan 2012 11:00:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 11:00:38 +0000
In-Reply-To: <070f78ba4244cf8239de.1327972926@athos.nss.cs.ubc.ca>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
	<070f78ba4244cf8239de.1327972926@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328007638.26983.350.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:22 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327972788 28800
> # Node ID 070f78ba4244cf8239ded3a69ccd54ac6e1bd24d
> # Parent  0129989da2cda789f86f2bc83d9c642a0bcebe60
> libxl: Remus - xl remus command
> 
> xl remus acts as a frontend to enable remus for a given domain.
>  * At the moment, only memory checkpointing and blackhole replication is
>    supported. Support for disk checkpointing and network buffering will
>    be added in future.
>  * Replication is done over ssh connection currently (like live migration
>    with xl). Future versions will have an option to use simple tcp socket
>    based replication channel (for both Remus & live migration).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 30 17:19:46 2012 -0800
> +++ b/tools/libxl/libxl.c	Mon Jan 30 17:19:48 2012 -0800
> @@ -471,6 +471,40 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
>      return ptr;
>  }
>  
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> +                             uint32_t domid, int fd)

This new function probably belongs in patch 1/2 with the other libxl
changes.

> +{
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    int rc = 0;
> +
> +    if (info == NULL) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "No remus_info structure supplied for domain %d", domid);
> +        rc = -1;

libxl functions should return one of ERROR_* not -1 one. In this case
ERROR_INVAL I suppose.

[...]

> diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Mon Jan 30 17:19:46 2012 -0800
> +++ b/tools/libxl/xl_cmdtable.c	Mon Jan 30 17:19:48 2012 -0800
> @@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
>        "Loads a new policy int the Flask Xen security module",
>        "<policy file>",
>      },
> +    { "remus",

Please also add this command to docs/man/xl.pod.1.

Otherwise this patch looks good, thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:01:03 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:01:03 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBSA-00053D-KM; Tue, 31 Jan 2012 11:00:46 +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 1RsBS8-00052S-MH
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:00:44 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328007638!12480545!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6714 invoked from network); 31 Jan 2012 11:00:38 -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;
	31 Jan 2012 11:00:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385711"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:00: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;
	Tue, 31 Jan 2012 11:00:38 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "rshriram@cs.ubc.ca" <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 11:00:38 +0000
In-Reply-To: <070f78ba4244cf8239de.1327972926@athos.nss.cs.ubc.ca>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
	<070f78ba4244cf8239de.1327972926@athos.nss.cs.ubc.ca>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328007638.26983.350.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 2 of 2] libxl: Remus - xl remus command
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 01:22 +0000, rshriram@cs.ubc.ca wrote:
> # HG changeset patch
> # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> # Date 1327972788 28800
> # Node ID 070f78ba4244cf8239ded3a69ccd54ac6e1bd24d
> # Parent  0129989da2cda789f86f2bc83d9c642a0bcebe60
> libxl: Remus - xl remus command
> 
> xl remus acts as a frontend to enable remus for a given domain.
>  * At the moment, only memory checkpointing and blackhole replication is
>    supported. Support for disk checkpointing and network buffering will
>    be added in future.
>  * Replication is done over ssh connection currently (like live migration
>    with xl). Future versions will have an option to use simple tcp socket
>    based replication channel (for both Remus & live migration).
> 
> Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
> 
> diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/libxl.c
> --- a/tools/libxl/libxl.c	Mon Jan 30 17:19:46 2012 -0800
> +++ b/tools/libxl/libxl.c	Mon Jan 30 17:19:48 2012 -0800
> @@ -471,6 +471,40 @@ libxl_vminfo * libxl_list_vm(libxl_ctx *
>      return ptr;
>  }
>  
> +int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
> +                             uint32_t domid, int fd)

This new function probably belongs in patch 1/2 with the other libxl
changes.

> +{
> +    GC_INIT(ctx);
> +    libxl_domain_type type = libxl__domain_type(gc, domid);
> +    int rc = 0;
> +
> +    if (info == NULL) {
> +        LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
> +                   "No remus_info structure supplied for domain %d", domid);
> +        rc = -1;

libxl functions should return one of ERROR_* not -1 one. In this case
ERROR_INVAL I suppose.

[...]

> diff -r 0129989da2cd -r 070f78ba4244 tools/libxl/xl_cmdtable.c
> --- a/tools/libxl/xl_cmdtable.c	Mon Jan 30 17:19:46 2012 -0800
> +++ b/tools/libxl/xl_cmdtable.c	Mon Jan 30 17:19:48 2012 -0800
> @@ -412,6 +412,20 @@ struct cmd_spec cmd_table[] = {
>        "Loads a new policy int the Flask Xen security module",
>        "<policy file>",
>      },
> +    { "remus",

Please also add this command to docs/man/xl.pod.1.

Otherwise this patch looks good, thanks.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:03:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBUD-0005JA-AQ; Tue, 31 Jan 2012 11:02:53 +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 1RsBUB-0005Ij-MZ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:02:51 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328007722!58135468!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30929 invoked from network); 31 Jan 2012 11:02:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 11:02:03 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0VB2iV7014720
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 06:02:44 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0VB2gqP006554; Tue, 31 Jan 2012 06:02:42 -0500
Message-ID: <4F27CAAE.8070602@redhat.com>
Date: Tue, 31 Jan 2012 12:04: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/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: <4F27B5AD.9050709@redhat.com>
	<4F27D232020000780007012B@nat28.tlf.novell.com>
In-Reply-To: <4F27D232020000780007012B@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Petr Matousek <pmatouse@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/12 11:36, Jan Beulich wrote:
>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com>  wrote:

>> Is it justified to kill the emulator when this happens (eg. memory
>> mapped IO with 64-bit operand)?

> The AMD manual specifies that REX.W is ignored; the Intel manual
> doesn't mention REX at all here. However, if a decoder incorrectly
> decodes the guest instruction, that's a bug there. So imo qemu
> validly treats this condition as fatal.

 From the Itanium(R) SDM rev 2.3,

10.7.2.1 I/O Port Addressing Restrictions

     For the 64MB physical I/O port block the following operations are
     undefined and may result in unpredictable processor operation;
     references larger than 4-bytes, [...]

It seems that not only a decoding failure can trigger this.

Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:03:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:03:02 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBUD-0005JA-AQ; Tue, 31 Jan 2012 11:02:53 +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 1RsBUB-0005Ij-MZ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:02:51 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-4.tower-27.messagelabs.com!1328007722!58135468!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30929 invoked from network); 31 Jan 2012 11:02:03 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-4.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 11:02:03 -0000
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0VB2iV7014720
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 06:02:44 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id q0VB2gqP006554; Tue, 31 Jan 2012 06:02:42 -0500
Message-ID: <4F27CAAE.8070602@redhat.com>
Date: Tue, 31 Jan 2012 12:04: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/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: <4F27B5AD.9050709@redhat.com>
	<4F27D232020000780007012B@nat28.tlf.novell.com>
In-Reply-To: <4F27D232020000780007012B@nat28.tlf.novell.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Petr Matousek <pmatouse@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/12 11:36, Jan Beulich wrote:
>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com>  wrote:

>> Is it justified to kill the emulator when this happens (eg. memory
>> mapped IO with 64-bit operand)?

> The AMD manual specifies that REX.W is ignored; the Intel manual
> doesn't mention REX at all here. However, if a decoder incorrectly
> decodes the guest instruction, that's a bug there. So imo qemu
> validly treats this condition as fatal.

 From the Itanium(R) SDM rev 2.3,

10.7.2.1 I/O Port Addressing Restrictions

     For the 64MB physical I/O port block the following operations are
     undefined and may result in unpredictable processor operation;
     references larger than 4-bytes, [...]

It seems that not only a decoding failure can trigger this.

Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:03:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBUv-0005OB-OP; Tue, 31 Jan 2012 11:03:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RsBUu-0005Nw-RV
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:03:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328007754!59103870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23814 invoked from network); 31 Jan 2012 11:02:35 -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;
	31 Jan 2012 11:02:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:03:31 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:03:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120130214710.GC16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
	<20120130214710.GC16261@phenom.dumpdata.com>
Date: Tue, 31 Jan 2012 11:03:44 +0000
Message-ID: <1328007824.5553.70.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 13/16] netback: stub for multi
 receive protocol support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 21:47 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 02:45:31PM +0000, Wei Liu wrote:
> > Refactor netback, make stub for mutli receive protocols. Also stub
> 
> multi.
> 

Good catch, thanks.

> > existing code as protocol 0.
> 
> Why not 1?
> 

We have some existing xenolinux code which has not been upstreamed calls
this protocol 0, just try to be compatible.

> Why do we need a new rework without anything using it besides
> the existing framework? OR if you are, you should say which
> patch is doing it...
> 

It is not in use at the moment, and will be in use in the future.

> > 
> > Now the file layout becomes:
> > 
> >  - interface.c: xenvif interfaces
> >  - xenbus.c: xenbus related functions
> >  - netback.c: common functions for various protocols
> > 
> > For different protocols:
> > 
> >  - xenvif_rx_protocolX.h: header file for the protocol, including
> >                           protocol structures and functions
> >  - xenvif_rx_protocolX.c: implementations
> > 
> > To add a new protocol:
> > 
> >  - include protocol header in common.h
> >  - modify XENVIF_MAX_RX_PROTOCOL in common.h
> >  - add protocol structure in xenvif.rx union
> >  - stub in xenbus.c
> >  - modify Makefile
> > 
> > A protocol should define five functions:
> > 
> >  - setup: setup frontend / backend ring connections
> >  - teardown: teardown frontend / backend ring connections
> >  - start_xmit: host start xmit (i.e. guest need to do rx)
> >  - event: rx completion event
> >  - action: prepare host side data for guest rx
> > 
> .. snip..
> 
> > -
> > -	return resp;
> > -}
> > -
> >  static inline int rx_work_todo(struct xenvif *vif)
> >  {
> >  	return !skb_queue_empty(&vif->rx_queue);
> > @@ -1507,8 +999,8 @@ int xenvif_kthread(void *data)
> >  		if (kthread_should_stop())
> >  			break;
> >  
> > -		if (rx_work_todo(vif))
> > -			xenvif_rx_action(vif);
> > +		if (rx_work_todo(vif) && vif->action)
> > +			vif->action(vif);
> >  	}
> >  
> >  	return 0;
> > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> > index 79499fc..4067286 100644
> > --- a/drivers/net/xen-netback/xenbus.c
> > +++ b/drivers/net/xen-netback/xenbus.c
> > @@ -415,6 +415,7 @@ static int connect_rings(struct backend_info *be)
> >  	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
> >  	unsigned int  tx_ring_order;
> >  	unsigned int  rx_ring_order;
> > +	unsigned int  rx_protocol;
> >  
> >  	err = xenbus_gather(XBT_NIL, dev->otherend,
> >  			    "event-channel", "%u", &evtchn, NULL);
> > @@ -510,6 +511,11 @@ static int connect_rings(struct backend_info *be)
> >  		}
> >  	}
> >  
> > +	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-protocol",
> 
> feature-rx-protocol?
> 

This is not a feature switch. Does it make sense to add "feature-"
prefix?

> > +			   "%u", &rx_protocol);
> > +	if (err < 0)
> > +		rx_protocol = XENVIF_MIN_RX_PROTOCOL;
> > +
> 
> You should check to see if the protocol is higher than what we can support.
> The guest could be playing funny games and putting in 39432...
> 
> 

Good point.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:03:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:03:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBUv-0005OB-OP; Tue, 31 Jan 2012 11:03:37 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RsBUu-0005Nw-RV
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:03:37 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328007754!59103870!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23814 invoked from network); 31 Jan 2012 11:02:35 -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;
	31 Jan 2012 11:02:35 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385813"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:03:31 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:03:30 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120130214710.GC16261@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
	<20120130214710.GC16261@phenom.dumpdata.com>
Date: Tue, 31 Jan 2012 11:03:44 +0000
Message-ID: <1328007824.5553.70.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 13/16] netback: stub for multi
 receive protocol support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 21:47 +0000, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 02:45:31PM +0000, Wei Liu wrote:
> > Refactor netback, make stub for mutli receive protocols. Also stub
> 
> multi.
> 

Good catch, thanks.

> > existing code as protocol 0.
> 
> Why not 1?
> 

We have some existing xenolinux code which has not been upstreamed calls
this protocol 0, just try to be compatible.

> Why do we need a new rework without anything using it besides
> the existing framework? OR if you are, you should say which
> patch is doing it...
> 

It is not in use at the moment, and will be in use in the future.

> > 
> > Now the file layout becomes:
> > 
> >  - interface.c: xenvif interfaces
> >  - xenbus.c: xenbus related functions
> >  - netback.c: common functions for various protocols
> > 
> > For different protocols:
> > 
> >  - xenvif_rx_protocolX.h: header file for the protocol, including
> >                           protocol structures and functions
> >  - xenvif_rx_protocolX.c: implementations
> > 
> > To add a new protocol:
> > 
> >  - include protocol header in common.h
> >  - modify XENVIF_MAX_RX_PROTOCOL in common.h
> >  - add protocol structure in xenvif.rx union
> >  - stub in xenbus.c
> >  - modify Makefile
> > 
> > A protocol should define five functions:
> > 
> >  - setup: setup frontend / backend ring connections
> >  - teardown: teardown frontend / backend ring connections
> >  - start_xmit: host start xmit (i.e. guest need to do rx)
> >  - event: rx completion event
> >  - action: prepare host side data for guest rx
> > 
> .. snip..
> 
> > -
> > -	return resp;
> > -}
> > -
> >  static inline int rx_work_todo(struct xenvif *vif)
> >  {
> >  	return !skb_queue_empty(&vif->rx_queue);
> > @@ -1507,8 +999,8 @@ int xenvif_kthread(void *data)
> >  		if (kthread_should_stop())
> >  			break;
> >  
> > -		if (rx_work_todo(vif))
> > -			xenvif_rx_action(vif);
> > +		if (rx_work_todo(vif) && vif->action)
> > +			vif->action(vif);
> >  	}
> >  
> >  	return 0;
> > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> > index 79499fc..4067286 100644
> > --- a/drivers/net/xen-netback/xenbus.c
> > +++ b/drivers/net/xen-netback/xenbus.c
> > @@ -415,6 +415,7 @@ static int connect_rings(struct backend_info *be)
> >  	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
> >  	unsigned int  tx_ring_order;
> >  	unsigned int  rx_ring_order;
> > +	unsigned int  rx_protocol;
> >  
> >  	err = xenbus_gather(XBT_NIL, dev->otherend,
> >  			    "event-channel", "%u", &evtchn, NULL);
> > @@ -510,6 +511,11 @@ static int connect_rings(struct backend_info *be)
> >  		}
> >  	}
> >  
> > +	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-protocol",
> 
> feature-rx-protocol?
> 

This is not a feature switch. Does it make sense to add "feature-"
prefix?

> > +			   "%u", &rx_protocol);
> > +	if (err < 0)
> > +		rx_protocol = XENVIF_MIN_RX_PROTOCOL;
> > +
> 
> You should check to see if the protocol is higher than what we can support.
> The guest could be playing funny games and putting in 39432...
> 
> 

Good point.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:10:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBag-0005lb-I7; Tue, 31 Jan 2012 11:09:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RsBaf-0005lW-2C
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:09:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328008118!52272402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14243 invoked from network); 31 Jan 2012 11:08:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:08:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:08:52 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:08:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27BC1002000078000700D3@nat28.tlf.novell.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 11:09:05 +0000
Message-ID: <1328008145.5553.74.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
> >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> >> > -			      grant_ref_t tx_ring_ref,
> >> > -			      grant_ref_t rx_ring_ref)
> >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> >> > +			      int domid,
> >> > +			      unsigned long ring_ref[],
> >> > +			      unsigned int  ring_ref_count)
> >> >  {
> >> > -	void *addr;
> >> > -	struct xen_netif_tx_sring *txs;
> >> > -	struct xen_netif_rx_sring *rxs;
> >> > -
> >> > -	int err = -ENOMEM;
> >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> >> > +	unsigned int i;
> >> > +	int err = 0;
> >> >  
> >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> >> > -				     tx_ring_ref, &addr);
> >> 
> >> Any reason why you don't just extend this function (in a prerequisite
> >> patch) rather than open coding a common utility function (twice) here,
> >> so that other backends (blkback!) can benefit later as well.
> >> 
> >> Jan
> >> 
> > 
> > I'm mainly focusing on netback stuffs, so the code is slightly coupled
> > with netback -- NETBK_MAX_RING_PAGES.
> > 
> > To extend xenbus_map_ring_valloc and make more generic, it requires
> > setting a global maximum page number limits on rings, I think it will
> > require further investigation and code refactor -- which I have no time
> > to attend to at the moment. :-/
> 
> Why? You can simply pass in the number of pages, there's no need
> for a global maximum.
> 

I mean the gnttab_map_gran_ref array, it is statically allocated at the
moment. Of course we can make it dynamically allocated, but why bother
taking the risk of allocation failure.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:10:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:10:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBag-0005lb-I7; Tue, 31 Jan 2012 11:09:34 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RsBaf-0005lW-2C
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:09:33 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328008118!52272402!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14243 invoked from network); 31 Jan 2012 11:08:38 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:08:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10385966"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:08:52 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:08:52 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27BC1002000078000700D3@nat28.tlf.novell.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 11:09:05 +0000
Message-ID: <1328008145.5553.74.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
> >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> >> > -			      grant_ref_t tx_ring_ref,
> >> > -			      grant_ref_t rx_ring_ref)
> >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> >> > +			      int domid,
> >> > +			      unsigned long ring_ref[],
> >> > +			      unsigned int  ring_ref_count)
> >> >  {
> >> > -	void *addr;
> >> > -	struct xen_netif_tx_sring *txs;
> >> > -	struct xen_netif_rx_sring *rxs;
> >> > -
> >> > -	int err = -ENOMEM;
> >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> >> > +	unsigned int i;
> >> > +	int err = 0;
> >> >  
> >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> >> > -				     tx_ring_ref, &addr);
> >> 
> >> Any reason why you don't just extend this function (in a prerequisite
> >> patch) rather than open coding a common utility function (twice) here,
> >> so that other backends (blkback!) can benefit later as well.
> >> 
> >> Jan
> >> 
> > 
> > I'm mainly focusing on netback stuffs, so the code is slightly coupled
> > with netback -- NETBK_MAX_RING_PAGES.
> > 
> > To extend xenbus_map_ring_valloc and make more generic, it requires
> > setting a global maximum page number limits on rings, I think it will
> > require further investigation and code refactor -- which I have no time
> > to attend to at the moment. :-/
> 
> Why? You can simply pass in the number of pages, there's no need
> for a global maximum.
> 

I mean the gnttab_map_gran_ref array, it is statically allocated at the
moment. Of course we can make it dynamically allocated, but why bother
taking the risk of allocation failure.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:12:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBde-0005rr-5C; Tue, 31 Jan 2012 11:12: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 1RsBdd-0005rm-00
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:12:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328008322!57831476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30283 invoked from network); 31 Jan 2012 11:12:02 -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;
	31 Jan 2012 11:12:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10386094"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:12:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:12:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>
Date: Tue, 31 Jan 2012 11:12:30 +0000
In-Reply-To: <1328008145.5553.74.camel@leeds.uk.xensource.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
	<1328008145.5553.74.camel@leeds.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328008350.26983.355.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>,
	Jan Beulich <JBeulich@suse.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 11:09 +0000, Wei Liu (Intern) wrote:
> On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
> > >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> > > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> > >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> > >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> > >> > -			      grant_ref_t tx_ring_ref,
> > >> > -			      grant_ref_t rx_ring_ref)
> > >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> > >> > +			      int domid,
> > >> > +			      unsigned long ring_ref[],
> > >> > +			      unsigned int  ring_ref_count)
> > >> >  {
> > >> > -	void *addr;
> > >> > -	struct xen_netif_tx_sring *txs;
> > >> > -	struct xen_netif_rx_sring *rxs;
> > >> > -
> > >> > -	int err = -ENOMEM;
> > >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> > >> > +	unsigned int i;
> > >> > +	int err = 0;
> > >> >  
> > >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> > >> > -				     tx_ring_ref, &addr);
> > >> 
> > >> Any reason why you don't just extend this function (in a prerequisite
> > >> patch) rather than open coding a common utility function (twice) here,
> > >> so that other backends (blkback!) can benefit later as well.
> > >> 
> > >> Jan
> > >> 
> > > 
> > > I'm mainly focusing on netback stuffs, so the code is slightly coupled
> > > with netback -- NETBK_MAX_RING_PAGES.
> > > 
> > > To extend xenbus_map_ring_valloc and make more generic, it requires
> > > setting a global maximum page number limits on rings, I think it will
> > > require further investigation and code refactor -- which I have no time
> > > to attend to at the moment. :-/
> > 
> > Why? You can simply pass in the number of pages, there's no need
> > for a global maximum.
> > 
> 
> I mean the gnttab_map_gran_ref array, it is statically allocated at the
> moment. Of course we can make it dynamically allocated, but why bother
> taking the risk of allocation failure.

You can do
	struct gnttab_map_grant_ref op[nr_pages];
and the compiler will do the right thing with the on-stack data
structure. In the kernel you'd need to be a bit careful about the size
of pages first but that should be all.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:12:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:12:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBde-0005rr-5C; Tue, 31 Jan 2012 11:12: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 1RsBdd-0005rm-00
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:12:37 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-27.messagelabs.com!1328008322!57831476!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30283 invoked from network); 31 Jan 2012 11:12:02 -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;
	31 Jan 2012 11:12:02 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10386094"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:12:30 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:12:30 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: "Wei Liu (Intern)" <wei.liu2@citrix.com>
Date: Tue, 31 Jan 2012 11:12:30 +0000
In-Reply-To: <1328008145.5553.74.camel@leeds.uk.xensource.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
	<1328008145.5553.74.camel@leeds.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328008350.26983.355.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>,
	Jan Beulich <JBeulich@suse.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 11:09 +0000, Wei Liu (Intern) wrote:
> On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
> > >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> > > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> > >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> > >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> > >> > -			      grant_ref_t tx_ring_ref,
> > >> > -			      grant_ref_t rx_ring_ref)
> > >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> > >> > +			      int domid,
> > >> > +			      unsigned long ring_ref[],
> > >> > +			      unsigned int  ring_ref_count)
> > >> >  {
> > >> > -	void *addr;
> > >> > -	struct xen_netif_tx_sring *txs;
> > >> > -	struct xen_netif_rx_sring *rxs;
> > >> > -
> > >> > -	int err = -ENOMEM;
> > >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> > >> > +	unsigned int i;
> > >> > +	int err = 0;
> > >> >  
> > >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> > >> > -				     tx_ring_ref, &addr);
> > >> 
> > >> Any reason why you don't just extend this function (in a prerequisite
> > >> patch) rather than open coding a common utility function (twice) here,
> > >> so that other backends (blkback!) can benefit later as well.
> > >> 
> > >> Jan
> > >> 
> > > 
> > > I'm mainly focusing on netback stuffs, so the code is slightly coupled
> > > with netback -- NETBK_MAX_RING_PAGES.
> > > 
> > > To extend xenbus_map_ring_valloc and make more generic, it requires
> > > setting a global maximum page number limits on rings, I think it will
> > > require further investigation and code refactor -- which I have no time
> > > to attend to at the moment. :-/
> > 
> > Why? You can simply pass in the number of pages, there's no need
> > for a global maximum.
> > 
> 
> I mean the gnttab_map_gran_ref array, it is statically allocated at the
> moment. Of course we can make it dynamically allocated, but why bother
> taking the risk of allocation failure.

You can do
	struct gnttab_map_grant_ref op[nr_pages];
and the compiler will do the right thing with the on-stack data
structure. In the kernel you'd need to be a bit careful about the size
of pages first but that should be all.

Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:15:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBgW-00060z-Pv; Tue, 31 Jan 2012 11:15:36 +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 1RsBgV-00060h-IV
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:15:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328008526!9272373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6895 invoked from network); 31 Jan 2012 11:15:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:15:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10386200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:15:26 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:15:26 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27C8240200007800070110@nat28.tlf.novell.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
	<4F27C8240200007800070110@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 11:15:40 +0000
Message-ID: <1328008540.5553.79.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 09:53 +0000, Jan Beulich wrote:
> > with more than 4GB?
> 
> Imo the use of the DMA API is a mistake here anyway. There's no need
> for anything to be contiguous in a PV frontend/backend handshake
> protocol, or if one finds there is it's very likely just because of trying to
> avoid doing something properly.
> 

Seems you're right. I look at the backend code again, I make use of 
vm_struct to create a contiguous area in backend kernel. In fact I can
avoid DMA API completely. ;-)


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:15:54 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:15:54 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBgW-00060z-Pv; Tue, 31 Jan 2012 11:15:36 +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 1RsBgV-00060h-IV
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:15:35 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328008526!9272373!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6895 invoked from network); 31 Jan 2012 11:15:27 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-7.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:15:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10386200"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:15:26 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:15:26 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27C8240200007800070110@nat28.tlf.novell.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
	<4F27C8240200007800070110@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 11:15:40 +0000
Message-ID: <1328008540.5553.79.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 09:53 +0000, Jan Beulich wrote:
> > with more than 4GB?
> 
> Imo the use of the DMA API is a mistake here anyway. There's no need
> for anything to be contiguous in a PV frontend/backend handshake
> protocol, or if one finds there is it's very likely just because of trying to
> avoid doing something properly.
> 

Seems you're right. I look at the backend code again, I make use of 
vm_struct to create a contiguous area in backend kernel. In fact I can
avoid DMA API completely. ;-)


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:17:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11: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 1RsBiF-00069H-AP; Tue, 31 Jan 2012 11:17:23 +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 1RsBiE-00068w-3m
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:17:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328008635!14651154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26967 invoked from network); 31 Jan 2012 11:17:15 -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;
	31 Jan 2012 11:17:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10386258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:17:15 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:17:14 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328001142.26983.289.camel@zakaz.uk.xensource.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
	<1328001142.26983.289.camel@zakaz.uk.xensource.com>
Date: Tue, 31 Jan 2012 11:17:28 +0000
Message-ID: <1328008648.5553.81.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 09:12 +0000, Ian Campbell wrote:
> On Mon, 2012-01-30 at 21:39 +0000, Konrad Rzeszutek Wilk wrote:
> 
> [...snip... please do consider trimming unnecessary quotes]
> 
> > > @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> > >               goto fail;
> > >       }
> > >
> > > -     txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> > > +     err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> > > +                        "max-tx-ring-page-order", "%u",
> > > +                        &max_tx_ring_page_order);
> > > +     if (err < 0) {
> > > +             info->tx_ring_page_order = 0;
> > > +             dev_info(&dev->dev, "single tx ring\n");
> > > +     } else {
> > > +             info->tx_ring_page_order = max_tx_ring_page_order;
> > > +             dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> > > +                      max_tx_ring_page_order);
> > > +     }
> > > +     info->tx_ring_pages = (1U << info->tx_ring_page_order);
> > > +
> > > +     txs = (struct xen_netif_tx_sring *)
> > > +             dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > > +                                &info->tx_ring_dma_handle,
> > > +                                __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> > 
> > Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
> > But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
> > clue whether you are OK getting pages under 4GB or above it (so 64-bit support).
> 
> Does this allocation even need to be physically contiguous? I'd have
> thought that virtually contiguous would be sufficient, and even then
> only as a convenience at either end to avoid the need for more
> complicated ring macros.
> 

I had a second thought about this, you're right. I just need to make
sure it is virtually contiguous in both frontend and backend, that's
sufficient.

Wei.

> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:17:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11: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 1RsBiF-00069H-AP; Tue, 31 Jan 2012 11:17:23 +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 1RsBiE-00068w-3m
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:17:22 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-216.messagelabs.com!1328008635!14651154!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26967 invoked from network); 31 Jan 2012 11:17:15 -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;
	31 Jan 2012 11:17:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10386258"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:17:15 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:17:14 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328001142.26983.289.camel@zakaz.uk.xensource.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-16-git-send-email-wei.liu2@citrix.com>
	<20120130213926.GB16261@phenom.dumpdata.com>
	<1328001142.26983.289.camel@zakaz.uk.xensource.com>
Date: Tue, 31 Jan 2012 11:17:28 +0000
Message-ID: <1328008648.5553.81.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 15/16] netfront: multi page ring
 support.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 09:12 +0000, Ian Campbell wrote:
> On Mon, 2012-01-30 at 21:39 +0000, Konrad Rzeszutek Wilk wrote:
> 
> [...snip... please do consider trimming unnecessary quotes]
> 
> > > @@ -1496,50 +1523,105 @@ static int setup_netfront(struct xenbus_device *dev, struct netfront_info *info)
> > >               goto fail;
> > >       }
> > >
> > > -     txs = (struct xen_netif_tx_sring *)get_zeroed_page(GFP_NOIO | __GFP_HIGH);
> > > +     err = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> > > +                        "max-tx-ring-page-order", "%u",
> > > +                        &max_tx_ring_page_order);
> > > +     if (err < 0) {
> > > +             info->tx_ring_page_order = 0;
> > > +             dev_info(&dev->dev, "single tx ring\n");
> > > +     } else {
> > > +             info->tx_ring_page_order = max_tx_ring_page_order;
> > > +             dev_info(&dev->dev, "multi page tx ring, order = %d\n",
> > > +                      max_tx_ring_page_order);
> > > +     }
> > > +     info->tx_ring_pages = (1U << info->tx_ring_page_order);
> > > +
> > > +     txs = (struct xen_netif_tx_sring *)
> > > +             dma_alloc_coherent(NULL, PAGE_SIZE * info->tx_ring_pages,
> > > +                                &info->tx_ring_dma_handle,
> > > +                                __GFP_ZERO | GFP_NOIO | __GFP_HIGH);
> > 
> > Hm, so I see you are using 'NULL' which is a big nono (the API docs say that).
> > But the other reason why it is a no-no, is b/c this way the generic DMA engine has no
> > clue whether you are OK getting pages under 4GB or above it (so 64-bit support).
> 
> Does this allocation even need to be physically contiguous? I'd have
> thought that virtually contiguous would be sufficient, and even then
> only as a convenience at either end to avoid the need for more
> complicated ring macros.
> 

I had a second thought about this, you're right. I just need to make
sure it is virtually contiguous in both frontend and backend, that's
sufficient.

Wei.

> Ian.
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:28:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBsO-0006VG-OJ; Tue, 31 Jan 2012 11:27:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RsBsM-0006V8-8x
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:27:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328009262!12461419!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1034 invoked from network); 31 Jan 2012 11:27:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:27:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320642000"; d="scan'208";a="21447695"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 06:27:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 06:27:22 -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 q0VBRJEM031514;
	Tue, 31 Jan 2012 03:27:20 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 11:27:18 +0000
Message-ID: <1328009238.27781.87.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote:
> >>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> >> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> x86's vMCE implementation lets a guest know of as many MCE reporting
> >> >> banks as there are in the host. While a PV guest could be expected to
> >> >> deal with this number changing (particularly decreasing) during migration
> >> >> (not currently handled anywhere afaict), for HVM guests this is certainly
> >> >> wrong.
> >> >>
> >> >> At least to me it isn't, however, clear how to properly handle this. The
> >> >> easiest would appear to be to save and restore the number of banks
> >> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
> >> >> silently tolerate accesses between the host and guest values.
> >> >
> >> > We ran into this in the XS 6.0 release as well.  I think that the
> >> > ideal thing to do would be to have a parameter that can be set at
> >> > boot, to say how many vMCE banks a guest has, defaulting to the number
> >> > of MCE banks on the host.  This parameter would be preserved across
> >> > migration.  Ideally, a pool-aware toolstack like xapi would then set
> >> > this value to be the value of the host in the pool with the largest
> >> > number of banks, allowing a guest to access all the banks on any host
> >> > to which it migrates.
> >> >
> >> > What do you think?
> >>
> >> That sounds like the way to go.
> >
> > So should we put this on IanC's to-do-be-done list?  Are you going to
> > put it on your to-do list? :-)
> 
> Below/attached a draft patch (compile tested only), handling save/
> restore of the bank count, but not allowing for a config setting to
> specify its initial value (yet).

Looks pretty good for a first blush.  Just one question: Why is the vmce
count made on a per-vcpu basis, rather than on a per-domain basis, like
the actual banks are?  Is the host MCE stuff per-vcpu?

 -George

> +static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> +{
> +    int ret = 1;
> +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
>      struct bank_entry *entry;
> 
> -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> -    if ( bank >= nr_mce_banks )
> -        return -1;
> +    *val = 0;
> 
>      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
>      {
>      case MSR_IA32_MC0_CTL:
> -        *val = vmce->mci_ctl[bank] &
> -            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
> +        if ( bank < nr_mce_banks )
> +            *val = vmce->mci_ctl[bank] &
> +                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
>          mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
>                     bank, *val);
>          break;
> @@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct domain
>          switch ( boot_cpu_data.x86_vendor )
>          {
>          case X86_VENDOR_INTEL:
> -            ret = intel_mce_rdmsr(msr, val);
> +            ret = intel_mce_rdmsr(v, msr, val);
>              break;
>          default:
>              ret = 0;
> @@ -145,13 +151,13 @@ static int bank_mce_rdmsr(struct domain
>   */
>  int vmce_rdmsr(uint32_t msr, uint64_t *val)
>  {
> -    struct domain *d = current->domain;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    const struct vcpu *cur = current;
> +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
>      int ret = 1;
> 
>      *val = 0;
> 
> -    spin_lock(&dom_vmce(d)->lock);
> +    spin_lock(&vmce->lock);
> 
>      switch ( msr )
>      {
> @@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
>                     *val);
>          break;
>      default:
> -        ret = mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
> +        ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
>          break;
>      }
> 
> -    spin_unlock(&dom_vmce(d)->lock);
> +    spin_unlock(&vmce->lock);
>      return ret;
>  }
> 
> -static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
> +static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
>  {
> -    int bank, ret = 1;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    int ret = 1;
> +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
>      struct bank_entry *entry = NULL;
> 
> -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> -    if ( bank >= nr_mce_banks )
> -        return -EINVAL;
> -
>      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
>      {
>      case MSR_IA32_MC0_CTL:
> -        vmce->mci_ctl[bank] = val;
> +        if ( bank < nr_mce_banks )
> +            vmce->mci_ctl[bank] = val;
>          break;
>      case MSR_IA32_MC0_STATUS:
>          /* Give the first entry of the list, it corresponds to current
> @@ -202,9 +206,9 @@ static int bank_mce_wrmsr(struct domain
>           * the guest, this node will be deleted.
>           * Only error bank is written. Non-error banks simply return.
>           */
> -        if ( !list_empty(&dom_vmce(d)->impact_header) )
> +        if ( !list_empty(&vmce->impact_header) )
>          {
> -            entry = list_entry(dom_vmce(d)->impact_header.next,
> +            entry = list_entry(vmce->impact_header.next,
>                                 struct bank_entry, list);
>              if ( entry->bank == bank )
>                  entry->mci_status = val;
> @@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain
>          switch ( boot_cpu_data.x86_vendor )
>          {
>          case X86_VENDOR_INTEL:
> -            ret = intel_mce_wrmsr(msr, val);
> +            ret = intel_mce_wrmsr(v, msr, val);
>              break;
>          default:
>              ret = 0;
> @@ -247,9 +251,9 @@ static int bank_mce_wrmsr(struct domain
>   */
>  int vmce_wrmsr(u32 msr, u64 val)
>  {
> -    struct domain *d = current->domain;
> +    struct vcpu *cur = current;
>      struct bank_entry *entry = NULL;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
>      int ret = 1;
> 
>      if ( !g_mcg_cap )
> @@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)
>          vmce->mcg_status = val;
>          mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", val);
>          /* For HVM guest, this is the point for deleting vMCE injection node */
> -        if ( d->is_hvm && (vmce->nr_injection > 0) )
> +        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
>          {
>              vmce->nr_injection--; /* Should be 0 */
>              if ( !list_empty(&vmce->impact_header) )
> @@ -293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)
>          ret = -1;
>          break;
>      default:
> -        ret = mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
> +        ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0;
>          break;
>      }
> 
> @@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)
>      return ret;
>  }
> 
> +static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +{
> +    struct vcpu *v;
> +    int err = 0;
> +
> +    for_each_vcpu( d, v ) {
> +        struct hvm_vmce_vcpu ctxt = {
> +            .nr_banks = v->arch.nr_vmce_banks
> +        };
> +
> +        err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
> +        if ( err )
> +            break;
> +    }
> +
> +    return err;
> +}
> +
> +static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +{
> +    unsigned int vcpuid = hvm_load_instance(h);
> +    struct vcpu *v;
> +    struct hvm_vmce_vcpu ctxt;
> +    int err;
> +
> +    if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
> +    {
> +        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        return -EINVAL;
> +    }
> +
> +    err = hvm_load_entry(VMCE_VCPU, h, &ctxt);
> +    if ( !err )
> +        v->arch.nr_vmce_banks = ctxt.nr_banks;
> +
> +    return err;
> +}
> +
> +HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
> +                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
> +
>  int inject_vmce(struct domain *d)
>  {
>      int cpu = smp_processor_id();
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)
> 
>      v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
> 
> +    vmce_init_vcpu(v);
> +
>      rc = is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0;
>   done:
>      if ( rc )
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1027,11 +1027,12 @@ long arch_do_domctl(
>                  evc->syscall32_callback_eip    = 0;
>                  evc->syscall32_disables_events = 0;
>              }
> +            evc->nr_mce_banks = v->arch.nr_vmce_banks;
>          }
>          else
>          {
>              ret = -EINVAL;
> -            if ( evc->size != sizeof(*evc) )
> +            if ( evc->size < offsetof(typeof(*evc), nr_mce_banks) )
>                  goto ext_vcpucontext_out;
>  #ifdef __x86_64__
>              if ( !is_hvm_domain(d) )
> @@ -1059,6 +1060,16 @@ long arch_do_domctl(
>                   (evc->syscall32_callback_cs & ~3) ||
>                   evc->syscall32_callback_eip )
>                  goto ext_vcpucontext_out;
> +
> +            if ( evc->size >= offsetof(typeof(*evc), mbz[ARRAY_SIZE(evc->mbz)]) )
> +            {
> +                unsigned int i;
> +
> +                for ( i = 0; i < ARRAY_SIZE(evc->mbz); ++i )
> +                    if ( evc->mbz[i] )
> +                        goto ext_vcpucontext_out;
> +                v->arch.nr_vmce_banks = evc->nr_mce_banks;
> +            }
>          }
> 
>          ret = 0;
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -488,6 +488,8 @@ struct arch_vcpu
>      /* This variable determines whether nonlazy extended state has been used,
>       * and thus should be saved/restored. */
>      bool_t nonlazy_xstate_used;
> +
> +    uint8_t nr_vmce_banks;
> 
>      struct paging_vcpu paging;
> 
> --- a/xen/include/asm-x86/mce.h
> +++ b/xen/include/asm-x86/mce.h
> @@ -28,6 +28,7 @@ struct domain_mca_msrs
>  /* Guest vMCE MSRs virtualization */
>  extern int vmce_init_msr(struct domain *d);
>  extern void vmce_destroy_msr(struct domain *d);
> +extern void vmce_init_vcpu(struct vcpu *);
>  extern int vmce_wrmsr(uint32_t msr, uint64_t val);
>  extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
> 
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
> 
>  DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context);
> 
> +struct hvm_vmce_vcpu {
> +    uint8_t nr_banks;
> +};
> +
> +DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
> +
>  /*
>   * Largest type-code in use
>   */
> -#define HVM_SAVE_CODE_MAX 17
> +#define HVM_SAVE_CODE_MAX 18
> 
>  #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
>      uint32_t         vcpu;
>      /*
>       * SET: Size of struct (IN)
> -     * GET: Size of struct (OUT)
> +     * GET: Size of struct (OUT, up to 128 bytes)
>       */
>      uint32_t         size;
>  #if defined(__i386__) || defined(__x86_64__)
> @@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucontext {
>      uint16_t         sysenter_callback_cs;
>      uint8_t          syscall32_disables_events;
>      uint8_t          sysenter_disables_events;
> +    uint8_t          nr_mce_banks;
> +    /* This array can be split and used for future extension. */
> +    /* It is there just to grow the structure beyond 4.1's size. */
> +    uint8_t          mbz[9];
>  #endif
>  };
>  typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:28:07 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:28:07 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBsO-0006VG-OJ; Tue, 31 Jan 2012 11:27:52 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RsBsM-0006V8-8x
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:27:50 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328009262!12461419!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1034 invoked from network); 31 Jan 2012 11:27:43 -0000
Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89)
	by server-9.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:27:43 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320642000"; d="scan'208";a="21447695"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 06:27:22 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 06:27:22 -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 q0VBRJEM031514;
	Tue, 31 Jan 2012 03:27:20 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 11:27:18 +0000
Message-ID: <1328009238.27781.87.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote:
> >>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> >> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> x86's vMCE implementation lets a guest know of as many MCE reporting
> >> >> banks as there are in the host. While a PV guest could be expected to
> >> >> deal with this number changing (particularly decreasing) during migration
> >> >> (not currently handled anywhere afaict), for HVM guests this is certainly
> >> >> wrong.
> >> >>
> >> >> At least to me it isn't, however, clear how to properly handle this. The
> >> >> easiest would appear to be to save and restore the number of banks
> >> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
> >> >> silently tolerate accesses between the host and guest values.
> >> >
> >> > We ran into this in the XS 6.0 release as well.  I think that the
> >> > ideal thing to do would be to have a parameter that can be set at
> >> > boot, to say how many vMCE banks a guest has, defaulting to the number
> >> > of MCE banks on the host.  This parameter would be preserved across
> >> > migration.  Ideally, a pool-aware toolstack like xapi would then set
> >> > this value to be the value of the host in the pool with the largest
> >> > number of banks, allowing a guest to access all the banks on any host
> >> > to which it migrates.
> >> >
> >> > What do you think?
> >>
> >> That sounds like the way to go.
> >
> > So should we put this on IanC's to-do-be-done list?  Are you going to
> > put it on your to-do list? :-)
> 
> Below/attached a draft patch (compile tested only), handling save/
> restore of the bank count, but not allowing for a config setting to
> specify its initial value (yet).

Looks pretty good for a first blush.  Just one question: Why is the vmce
count made on a per-vcpu basis, rather than on a per-domain basis, like
the actual banks are?  Is the host MCE stuff per-vcpu?

 -George

> +static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> +{
> +    int ret = 1;
> +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
>      struct bank_entry *entry;
> 
> -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> -    if ( bank >= nr_mce_banks )
> -        return -1;
> +    *val = 0;
> 
>      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
>      {
>      case MSR_IA32_MC0_CTL:
> -        *val = vmce->mci_ctl[bank] &
> -            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
> +        if ( bank < nr_mce_banks )
> +            *val = vmce->mci_ctl[bank] &
> +                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
>          mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
>                     bank, *val);
>          break;
> @@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct domain
>          switch ( boot_cpu_data.x86_vendor )
>          {
>          case X86_VENDOR_INTEL:
> -            ret = intel_mce_rdmsr(msr, val);
> +            ret = intel_mce_rdmsr(v, msr, val);
>              break;
>          default:
>              ret = 0;
> @@ -145,13 +151,13 @@ static int bank_mce_rdmsr(struct domain
>   */
>  int vmce_rdmsr(uint32_t msr, uint64_t *val)
>  {
> -    struct domain *d = current->domain;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    const struct vcpu *cur = current;
> +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
>      int ret = 1;
> 
>      *val = 0;
> 
> -    spin_lock(&dom_vmce(d)->lock);
> +    spin_lock(&vmce->lock);
> 
>      switch ( msr )
>      {
> @@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
>                     *val);
>          break;
>      default:
> -        ret = mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
> +        ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
>          break;
>      }
> 
> -    spin_unlock(&dom_vmce(d)->lock);
> +    spin_unlock(&vmce->lock);
>      return ret;
>  }
> 
> -static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
> +static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
>  {
> -    int bank, ret = 1;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    int ret = 1;
> +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
>      struct bank_entry *entry = NULL;
> 
> -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> -    if ( bank >= nr_mce_banks )
> -        return -EINVAL;
> -
>      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
>      {
>      case MSR_IA32_MC0_CTL:
> -        vmce->mci_ctl[bank] = val;
> +        if ( bank < nr_mce_banks )
> +            vmce->mci_ctl[bank] = val;
>          break;
>      case MSR_IA32_MC0_STATUS:
>          /* Give the first entry of the list, it corresponds to current
> @@ -202,9 +206,9 @@ static int bank_mce_wrmsr(struct domain
>           * the guest, this node will be deleted.
>           * Only error bank is written. Non-error banks simply return.
>           */
> -        if ( !list_empty(&dom_vmce(d)->impact_header) )
> +        if ( !list_empty(&vmce->impact_header) )
>          {
> -            entry = list_entry(dom_vmce(d)->impact_header.next,
> +            entry = list_entry(vmce->impact_header.next,
>                                 struct bank_entry, list);
>              if ( entry->bank == bank )
>                  entry->mci_status = val;
> @@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain
>          switch ( boot_cpu_data.x86_vendor )
>          {
>          case X86_VENDOR_INTEL:
> -            ret = intel_mce_wrmsr(msr, val);
> +            ret = intel_mce_wrmsr(v, msr, val);
>              break;
>          default:
>              ret = 0;
> @@ -247,9 +251,9 @@ static int bank_mce_wrmsr(struct domain
>   */
>  int vmce_wrmsr(u32 msr, u64 val)
>  {
> -    struct domain *d = current->domain;
> +    struct vcpu *cur = current;
>      struct bank_entry *entry = NULL;
> -    struct domain_mca_msrs *vmce = dom_vmce(d);
> +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
>      int ret = 1;
> 
>      if ( !g_mcg_cap )
> @@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)
>          vmce->mcg_status = val;
>          mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", val);
>          /* For HVM guest, this is the point for deleting vMCE injection node */
> -        if ( d->is_hvm && (vmce->nr_injection > 0) )
> +        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
>          {
>              vmce->nr_injection--; /* Should be 0 */
>              if ( !list_empty(&vmce->impact_header) )
> @@ -293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)
>          ret = -1;
>          break;
>      default:
> -        ret = mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
> +        ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0;
>          break;
>      }
> 
> @@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)
>      return ret;
>  }
> 
> +static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +{
> +    struct vcpu *v;
> +    int err = 0;
> +
> +    for_each_vcpu( d, v ) {
> +        struct hvm_vmce_vcpu ctxt = {
> +            .nr_banks = v->arch.nr_vmce_banks
> +        };
> +
> +        err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
> +        if ( err )
> +            break;
> +    }
> +
> +    return err;
> +}
> +
> +static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> +{
> +    unsigned int vcpuid = hvm_load_instance(h);
> +    struct vcpu *v;
> +    struct hvm_vmce_vcpu ctxt;
> +    int err;
> +
> +    if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
> +    {
> +        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> +        return -EINVAL;
> +    }
> +
> +    err = hvm_load_entry(VMCE_VCPU, h, &ctxt);
> +    if ( !err )
> +        v->arch.nr_vmce_banks = ctxt.nr_banks;
> +
> +    return err;
> +}
> +
> +HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
> +                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
> +
>  int inject_vmce(struct domain *d)
>  {
>      int cpu = smp_processor_id();
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)
> 
>      v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
> 
> +    vmce_init_vcpu(v);
> +
>      rc = is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0;
>   done:
>      if ( rc )
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1027,11 +1027,12 @@ long arch_do_domctl(
>                  evc->syscall32_callback_eip    = 0;
>                  evc->syscall32_disables_events = 0;
>              }
> +            evc->nr_mce_banks = v->arch.nr_vmce_banks;
>          }
>          else
>          {
>              ret = -EINVAL;
> -            if ( evc->size != sizeof(*evc) )
> +            if ( evc->size < offsetof(typeof(*evc), nr_mce_banks) )
>                  goto ext_vcpucontext_out;
>  #ifdef __x86_64__
>              if ( !is_hvm_domain(d) )
> @@ -1059,6 +1060,16 @@ long arch_do_domctl(
>                   (evc->syscall32_callback_cs & ~3) ||
>                   evc->syscall32_callback_eip )
>                  goto ext_vcpucontext_out;
> +
> +            if ( evc->size >= offsetof(typeof(*evc), mbz[ARRAY_SIZE(evc->mbz)]) )
> +            {
> +                unsigned int i;
> +
> +                for ( i = 0; i < ARRAY_SIZE(evc->mbz); ++i )
> +                    if ( evc->mbz[i] )
> +                        goto ext_vcpucontext_out;
> +                v->arch.nr_vmce_banks = evc->nr_mce_banks;
> +            }
>          }
> 
>          ret = 0;
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -488,6 +488,8 @@ struct arch_vcpu
>      /* This variable determines whether nonlazy extended state has been used,
>       * and thus should be saved/restored. */
>      bool_t nonlazy_xstate_used;
> +
> +    uint8_t nr_vmce_banks;
> 
>      struct paging_vcpu paging;
> 
> --- a/xen/include/asm-x86/mce.h
> +++ b/xen/include/asm-x86/mce.h
> @@ -28,6 +28,7 @@ struct domain_mca_msrs
>  /* Guest vMCE MSRs virtualization */
>  extern int vmce_init_msr(struct domain *d);
>  extern void vmce_destroy_msr(struct domain *d);
> +extern void vmce_init_vcpu(struct vcpu *);
>  extern int vmce_wrmsr(uint32_t msr, uint64_t val);
>  extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
> 
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
> 
>  DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context);
> 
> +struct hvm_vmce_vcpu {
> +    uint8_t nr_banks;
> +};
> +
> +DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
> +
>  /*
>   * Largest type-code in use
>   */
> -#define HVM_SAVE_CODE_MAX 17
> +#define HVM_SAVE_CODE_MAX 18
> 
>  #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
>      uint32_t         vcpu;
>      /*
>       * SET: Size of struct (IN)
> -     * GET: Size of struct (OUT)
> +     * GET: Size of struct (OUT, up to 128 bytes)
>       */
>      uint32_t         size;
>  #if defined(__i386__) || defined(__x86_64__)
> @@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucontext {
>      uint16_t         sysenter_callback_cs;
>      uint8_t          syscall32_disables_events;
>      uint8_t          sysenter_disables_events;
> +    uint8_t          nr_mce_banks;
> +    /* This array can be split and used for future extension. */
> +    /* It is there just to grow the structure beyond 4.1's size. */
> +    uint8_t          mbz[9];
>  #endif
>  };
>  typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:28:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBsk-0006Wk-5c; Tue, 31 Jan 2012 11:28:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RsBsi-0006Vw-ER
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:28:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328009284!12485366!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27187 invoked from network); 31 Jan 2012 11:28:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:28:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320642000"; d="scan'208";a="179750462"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 06:28:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 06:28:03 -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 q0VBS2la031517;
	Tue, 31 Jan 2012 03:28:02 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <1328009238.27781.87.camel@elijah>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<1328009238.27781.87.camel@elijah>
Date: Tue, 31 Jan 2012 11:28:01 +0000
Message-ID: <1328009281.27781.88.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 11:27 +0000, George Dunlap wrote:
> On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote:
> > >>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> > > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> > >> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> > >> >> x86's vMCE implementation lets a guest know of as many MCE reporting
> > >> >> banks as there are in the host. While a PV guest could be expected to
> > >> >> deal with this number changing (particularly decreasing) during migration
> > >> >> (not currently handled anywhere afaict), for HVM guests this is certainly
> > >> >> wrong.
> > >> >>
> > >> >> At least to me it isn't, however, clear how to properly handle this. The
> > >> >> easiest would appear to be to save and restore the number of banks
> > >> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
> > >> >> silently tolerate accesses between the host and guest values.
> > >> >
> > >> > We ran into this in the XS 6.0 release as well.  I think that the
> > >> > ideal thing to do would be to have a parameter that can be set at
> > >> > boot, to say how many vMCE banks a guest has, defaulting to the number
> > >> > of MCE banks on the host.  This parameter would be preserved across
> > >> > migration.  Ideally, a pool-aware toolstack like xapi would then set
> > >> > this value to be the value of the host in the pool with the largest
> > >> > number of banks, allowing a guest to access all the banks on any host
> > >> > to which it migrates.
> > >> >
> > >> > What do you think?
> > >>
> > >> That sounds like the way to go.
> > >
> > > So should we put this on IanC's to-do-be-done list?  Are you going to
> > > put it on your to-do list? :-)
> > 
> > Below/attached a draft patch (compile tested only), handling save/
> > restore of the bank count, but not allowing for a config setting to
> > specify its initial value (yet).
> 
> Looks pretty good for a first blush.  Just one question: Why is the vmce
> count made on a per-vcpu basis, rather than on a per-domain basis, like
> the actual banks are?  Is the host MCE stuff per-vcpu?

(Per-pcpu, that is...)

> 
>  -George
> 
> > +static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> > +{
> > +    int ret = 1;
> > +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> > +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
> >      struct bank_entry *entry;
> > 
> > -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> > -    if ( bank >= nr_mce_banks )
> > -        return -1;
> > +    *val = 0;
> > 
> >      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
> >      {
> >      case MSR_IA32_MC0_CTL:
> > -        *val = vmce->mci_ctl[bank] &
> > -            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
> > +        if ( bank < nr_mce_banks )
> > +            *val = vmce->mci_ctl[bank] &
> > +                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
> >          mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
> >                     bank, *val);
> >          break;
> > @@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct domain
> >          switch ( boot_cpu_data.x86_vendor )
> >          {
> >          case X86_VENDOR_INTEL:
> > -            ret = intel_mce_rdmsr(msr, val);
> > +            ret = intel_mce_rdmsr(v, msr, val);
> >              break;
> >          default:
> >              ret = 0;
> > @@ -145,13 +151,13 @@ static int bank_mce_rdmsr(struct domain
> >   */
> >  int vmce_rdmsr(uint32_t msr, uint64_t *val)
> >  {
> > -    struct domain *d = current->domain;
> > -    struct domain_mca_msrs *vmce = dom_vmce(d);
> > +    const struct vcpu *cur = current;
> > +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
> >      int ret = 1;
> > 
> >      *val = 0;
> > 
> > -    spin_lock(&dom_vmce(d)->lock);
> > +    spin_lock(&vmce->lock);
> > 
> >      switch ( msr )
> >      {
> > @@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
> >                     *val);
> >          break;
> >      default:
> > -        ret = mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
> > +        ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
> >          break;
> >      }
> > 
> > -    spin_unlock(&dom_vmce(d)->lock);
> > +    spin_unlock(&vmce->lock);
> >      return ret;
> >  }
> > 
> > -static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
> > +static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
> >  {
> > -    int bank, ret = 1;
> > -    struct domain_mca_msrs *vmce = dom_vmce(d);
> > +    int ret = 1;
> > +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> > +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
> >      struct bank_entry *entry = NULL;
> > 
> > -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> > -    if ( bank >= nr_mce_banks )
> > -        return -EINVAL;
> > -
> >      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
> >      {
> >      case MSR_IA32_MC0_CTL:
> > -        vmce->mci_ctl[bank] = val;
> > +        if ( bank < nr_mce_banks )
> > +            vmce->mci_ctl[bank] = val;
> >          break;
> >      case MSR_IA32_MC0_STATUS:
> >          /* Give the first entry of the list, it corresponds to current
> > @@ -202,9 +206,9 @@ static int bank_mce_wrmsr(struct domain
> >           * the guest, this node will be deleted.
> >           * Only error bank is written. Non-error banks simply return.
> >           */
> > -        if ( !list_empty(&dom_vmce(d)->impact_header) )
> > +        if ( !list_empty(&vmce->impact_header) )
> >          {
> > -            entry = list_entry(dom_vmce(d)->impact_header.next,
> > +            entry = list_entry(vmce->impact_header.next,
> >                                 struct bank_entry, list);
> >              if ( entry->bank == bank )
> >                  entry->mci_status = val;
> > @@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain
> >          switch ( boot_cpu_data.x86_vendor )
> >          {
> >          case X86_VENDOR_INTEL:
> > -            ret = intel_mce_wrmsr(msr, val);
> > +            ret = intel_mce_wrmsr(v, msr, val);
> >              break;
> >          default:
> >              ret = 0;
> > @@ -247,9 +251,9 @@ static int bank_mce_wrmsr(struct domain
> >   */
> >  int vmce_wrmsr(u32 msr, u64 val)
> >  {
> > -    struct domain *d = current->domain;
> > +    struct vcpu *cur = current;
> >      struct bank_entry *entry = NULL;
> > -    struct domain_mca_msrs *vmce = dom_vmce(d);
> > +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
> >      int ret = 1;
> > 
> >      if ( !g_mcg_cap )
> > @@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)
> >          vmce->mcg_status = val;
> >          mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", val);
> >          /* For HVM guest, this is the point for deleting vMCE injection node */
> > -        if ( d->is_hvm && (vmce->nr_injection > 0) )
> > +        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
> >          {
> >              vmce->nr_injection--; /* Should be 0 */
> >              if ( !list_empty(&vmce->impact_header) )
> > @@ -293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)
> >          ret = -1;
> >          break;
> >      default:
> > -        ret = mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
> > +        ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0;
> >          break;
> >      }
> > 
> > @@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)
> >      return ret;
> >  }
> > 
> > +static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> > +{
> > +    struct vcpu *v;
> > +    int err = 0;
> > +
> > +    for_each_vcpu( d, v ) {
> > +        struct hvm_vmce_vcpu ctxt = {
> > +            .nr_banks = v->arch.nr_vmce_banks
> > +        };
> > +
> > +        err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
> > +        if ( err )
> > +            break;
> > +    }
> > +
> > +    return err;
> > +}
> > +
> > +static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> > +{
> > +    unsigned int vcpuid = hvm_load_instance(h);
> > +    struct vcpu *v;
> > +    struct hvm_vmce_vcpu ctxt;
> > +    int err;
> > +
> > +    if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
> > +    {
> > +        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> > +        return -EINVAL;
> > +    }
> > +
> > +    err = hvm_load_entry(VMCE_VCPU, h, &ctxt);
> > +    if ( !err )
> > +        v->arch.nr_vmce_banks = ctxt.nr_banks;
> > +
> > +    return err;
> > +}
> > +
> > +HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
> > +                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
> > +
> >  int inject_vmce(struct domain *d)
> >  {
> >      int cpu = smp_processor_id();
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)
> > 
> >      v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
> > 
> > +    vmce_init_vcpu(v);
> > +
> >      rc = is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0;
> >   done:
> >      if ( rc )
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -1027,11 +1027,12 @@ long arch_do_domctl(
> >                  evc->syscall32_callback_eip    = 0;
> >                  evc->syscall32_disables_events = 0;
> >              }
> > +            evc->nr_mce_banks = v->arch.nr_vmce_banks;
> >          }
> >          else
> >          {
> >              ret = -EINVAL;
> > -            if ( evc->size != sizeof(*evc) )
> > +            if ( evc->size < offsetof(typeof(*evc), nr_mce_banks) )
> >                  goto ext_vcpucontext_out;
> >  #ifdef __x86_64__
> >              if ( !is_hvm_domain(d) )
> > @@ -1059,6 +1060,16 @@ long arch_do_domctl(
> >                   (evc->syscall32_callback_cs & ~3) ||
> >                   evc->syscall32_callback_eip )
> >                  goto ext_vcpucontext_out;
> > +
> > +            if ( evc->size >= offsetof(typeof(*evc), mbz[ARRAY_SIZE(evc->mbz)]) )
> > +            {
> > +                unsigned int i;
> > +
> > +                for ( i = 0; i < ARRAY_SIZE(evc->mbz); ++i )
> > +                    if ( evc->mbz[i] )
> > +                        goto ext_vcpucontext_out;
> > +                v->arch.nr_vmce_banks = evc->nr_mce_banks;
> > +            }
> >          }
> > 
> >          ret = 0;
> > --- a/xen/include/asm-x86/domain.h
> > +++ b/xen/include/asm-x86/domain.h
> > @@ -488,6 +488,8 @@ struct arch_vcpu
> >      /* This variable determines whether nonlazy extended state has been used,
> >       * and thus should be saved/restored. */
> >      bool_t nonlazy_xstate_used;
> > +
> > +    uint8_t nr_vmce_banks;
> > 
> >      struct paging_vcpu paging;
> > 
> > --- a/xen/include/asm-x86/mce.h
> > +++ b/xen/include/asm-x86/mce.h
> > @@ -28,6 +28,7 @@ struct domain_mca_msrs
> >  /* Guest vMCE MSRs virtualization */
> >  extern int vmce_init_msr(struct domain *d);
> >  extern void vmce_destroy_msr(struct domain *d);
> > +extern void vmce_init_vcpu(struct vcpu *);
> >  extern int vmce_wrmsr(uint32_t msr, uint64_t val);
> >  extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
> > 
> > --- a/xen/include/public/arch-x86/hvm/save.h
> > +++ b/xen/include/public/arch-x86/hvm/save.h
> > @@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
> > 
> >  DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context);
> > 
> > +struct hvm_vmce_vcpu {
> > +    uint8_t nr_banks;
> > +};
> > +
> > +DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
> > +
> >  /*
> >   * Largest type-code in use
> >   */
> > -#define HVM_SAVE_CODE_MAX 17
> > +#define HVM_SAVE_CODE_MAX 18
> > 
> >  #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
> >      uint32_t         vcpu;
> >      /*
> >       * SET: Size of struct (IN)
> > -     * GET: Size of struct (OUT)
> > +     * GET: Size of struct (OUT, up to 128 bytes)
> >       */
> >      uint32_t         size;
> >  #if defined(__i386__) || defined(__x86_64__)
> > @@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucontext {
> >      uint16_t         sysenter_callback_cs;
> >      uint8_t          syscall32_disables_events;
> >      uint8_t          sysenter_disables_events;
> > +    uint8_t          nr_mce_banks;
> > +    /* This array can be split and used for future extension. */
> > +    /* It is there just to grow the structure beyond 4.1's size. */
> > +    uint8_t          mbz[9];
> >  #endif
> >  };
> >  typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:28:38 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:28:38 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsBsk-0006Wk-5c; Tue, 31 Jan 2012 11:28:14 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RsBsi-0006Vw-ER
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:28:12 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-4.tower-182.messagelabs.com!1328009284!12485366!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 27187 invoked from network); 31 Jan 2012 11:28:05 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-4.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 11:28:05 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320642000"; d="scan'208";a="179750462"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 06:28:04 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 06:28:03 -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 q0VBS2la031517;
	Tue, 31 Jan 2012 03:28:02 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <1328009238.27781.87.camel@elijah>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<1328009238.27781.87.camel@elijah>
Date: Tue, 31 Jan 2012 11:28:01 +0000
Message-ID: <1328009281.27781.88.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 11:27 +0000, George Dunlap wrote:
> On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote:
> > >>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> > > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> > >> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> > >> >> x86's vMCE implementation lets a guest know of as many MCE reporting
> > >> >> banks as there are in the host. While a PV guest could be expected to
> > >> >> deal with this number changing (particularly decreasing) during migration
> > >> >> (not currently handled anywhere afaict), for HVM guests this is certainly
> > >> >> wrong.
> > >> >>
> > >> >> At least to me it isn't, however, clear how to properly handle this. The
> > >> >> easiest would appear to be to save and restore the number of banks
> > >> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
> > >> >> silently tolerate accesses between the host and guest values.
> > >> >
> > >> > We ran into this in the XS 6.0 release as well.  I think that the
> > >> > ideal thing to do would be to have a parameter that can be set at
> > >> > boot, to say how many vMCE banks a guest has, defaulting to the number
> > >> > of MCE banks on the host.  This parameter would be preserved across
> > >> > migration.  Ideally, a pool-aware toolstack like xapi would then set
> > >> > this value to be the value of the host in the pool with the largest
> > >> > number of banks, allowing a guest to access all the banks on any host
> > >> > to which it migrates.
> > >> >
> > >> > What do you think?
> > >>
> > >> That sounds like the way to go.
> > >
> > > So should we put this on IanC's to-do-be-done list?  Are you going to
> > > put it on your to-do list? :-)
> > 
> > Below/attached a draft patch (compile tested only), handling save/
> > restore of the bank count, but not allowing for a config setting to
> > specify its initial value (yet).
> 
> Looks pretty good for a first blush.  Just one question: Why is the vmce
> count made on a per-vcpu basis, rather than on a per-domain basis, like
> the actual banks are?  Is the host MCE stuff per-vcpu?

(Per-pcpu, that is...)

> 
>  -George
> 
> > +static int bank_mce_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> > +{
> > +    int ret = 1;
> > +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> > +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
> >      struct bank_entry *entry;
> > 
> > -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> > -    if ( bank >= nr_mce_banks )
> > -        return -1;
> > +    *val = 0;
> > 
> >      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
> >      {
> >      case MSR_IA32_MC0_CTL:
> > -        *val = vmce->mci_ctl[bank] &
> > -            (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
> > +        if ( bank < nr_mce_banks )
> > +            *val = vmce->mci_ctl[bank] &
> > +                   (h_mci_ctrl ? h_mci_ctrl[bank] : ~0UL);
> >          mce_printk(MCE_VERBOSE, "MCE: rdmsr MC%u_CTL 0x%"PRIx64"\n",
> >                     bank, *val);
> >          break;
> > @@ -126,7 +132,7 @@ static int bank_mce_rdmsr(struct domain
> >          switch ( boot_cpu_data.x86_vendor )
> >          {
> >          case X86_VENDOR_INTEL:
> > -            ret = intel_mce_rdmsr(msr, val);
> > +            ret = intel_mce_rdmsr(v, msr, val);
> >              break;
> >          default:
> >              ret = 0;
> > @@ -145,13 +151,13 @@ static int bank_mce_rdmsr(struct domain
> >   */
> >  int vmce_rdmsr(uint32_t msr, uint64_t *val)
> >  {
> > -    struct domain *d = current->domain;
> > -    struct domain_mca_msrs *vmce = dom_vmce(d);
> > +    const struct vcpu *cur = current;
> > +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
> >      int ret = 1;
> > 
> >      *val = 0;
> > 
> > -    spin_lock(&dom_vmce(d)->lock);
> > +    spin_lock(&vmce->lock);
> > 
> >      switch ( msr )
> >      {
> > @@ -173,28 +179,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *v
> >                     *val);
> >          break;
> >      default:
> > -        ret = mce_bank_msr(msr) ? bank_mce_rdmsr(d, msr, val) : 0;
> > +        ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
> >          break;
> >      }
> > 
> > -    spin_unlock(&dom_vmce(d)->lock);
> > +    spin_unlock(&vmce->lock);
> >      return ret;
> >  }
> > 
> > -static int bank_mce_wrmsr(struct domain *d, u32 msr, u64 val)
> > +static int bank_mce_wrmsr(struct vcpu *v, u32 msr, u64 val)
> >  {
> > -    int bank, ret = 1;
> > -    struct domain_mca_msrs *vmce = dom_vmce(d);
> > +    int ret = 1;
> > +    unsigned int bank = (msr - MSR_IA32_MC0_CTL) / 4;
> > +    struct domain_mca_msrs *vmce = dom_vmce(v->domain);
> >      struct bank_entry *entry = NULL;
> > 
> > -    bank = (msr - MSR_IA32_MC0_CTL) / 4;
> > -    if ( bank >= nr_mce_banks )
> > -        return -EINVAL;
> > -
> >      switch ( msr & (MSR_IA32_MC0_CTL | 3) )
> >      {
> >      case MSR_IA32_MC0_CTL:
> > -        vmce->mci_ctl[bank] = val;
> > +        if ( bank < nr_mce_banks )
> > +            vmce->mci_ctl[bank] = val;
> >          break;
> >      case MSR_IA32_MC0_STATUS:
> >          /* Give the first entry of the list, it corresponds to current
> > @@ -202,9 +206,9 @@ static int bank_mce_wrmsr(struct domain
> >           * the guest, this node will be deleted.
> >           * Only error bank is written. Non-error banks simply return.
> >           */
> > -        if ( !list_empty(&dom_vmce(d)->impact_header) )
> > +        if ( !list_empty(&vmce->impact_header) )
> >          {
> > -            entry = list_entry(dom_vmce(d)->impact_header.next,
> > +            entry = list_entry(vmce->impact_header.next,
> >                                 struct bank_entry, list);
> >              if ( entry->bank == bank )
> >                  entry->mci_status = val;
> > @@ -228,7 +232,7 @@ static int bank_mce_wrmsr(struct domain
> >          switch ( boot_cpu_data.x86_vendor )
> >          {
> >          case X86_VENDOR_INTEL:
> > -            ret = intel_mce_wrmsr(msr, val);
> > +            ret = intel_mce_wrmsr(v, msr, val);
> >              break;
> >          default:
> >              ret = 0;
> > @@ -247,9 +251,9 @@ static int bank_mce_wrmsr(struct domain
> >   */
> >  int vmce_wrmsr(u32 msr, u64 val)
> >  {
> > -    struct domain *d = current->domain;
> > +    struct vcpu *cur = current;
> >      struct bank_entry *entry = NULL;
> > -    struct domain_mca_msrs *vmce = dom_vmce(d);
> > +    struct domain_mca_msrs *vmce = dom_vmce(cur->domain);
> >      int ret = 1;
> > 
> >      if ( !g_mcg_cap )
> > @@ -266,7 +270,7 @@ int vmce_wrmsr(u32 msr, u64 val)
> >          vmce->mcg_status = val;
> >          mce_printk(MCE_VERBOSE, "MCE: wrmsr MCG_STATUS %"PRIx64"\n", val);
> >          /* For HVM guest, this is the point for deleting vMCE injection node */
> > -        if ( d->is_hvm && (vmce->nr_injection > 0) )
> > +        if ( is_hvm_vcpu(cur) && (vmce->nr_injection > 0) )
> >          {
> >              vmce->nr_injection--; /* Should be 0 */
> >              if ( !list_empty(&vmce->impact_header) )
> > @@ -293,7 +297,7 @@ int vmce_wrmsr(u32 msr, u64 val)
> >          ret = -1;
> >          break;
> >      default:
> > -        ret = mce_bank_msr(msr) ? bank_mce_wrmsr(d, msr, val) : 0;
> > +        ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0;
> >          break;
> >      }
> > 
> > @@ -301,6 +305,47 @@ int vmce_wrmsr(u32 msr, u64 val)
> >      return ret;
> >  }
> > 
> > +static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> > +{
> > +    struct vcpu *v;
> > +    int err = 0;
> > +
> > +    for_each_vcpu( d, v ) {
> > +        struct hvm_vmce_vcpu ctxt = {
> > +            .nr_banks = v->arch.nr_vmce_banks
> > +        };
> > +
> > +        err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, &ctxt);
> > +        if ( err )
> > +            break;
> > +    }
> > +
> > +    return err;
> > +}
> > +
> > +static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
> > +{
> > +    unsigned int vcpuid = hvm_load_instance(h);
> > +    struct vcpu *v;
> > +    struct hvm_vmce_vcpu ctxt;
> > +    int err;
> > +
> > +    if ( vcpuid >= d->max_vcpus || (v = d->vcpu[vcpuid]) == NULL )
> > +    {
> > +        gdprintk(XENLOG_ERR, "HVM restore: domain has no vcpu %u\n", vcpuid);
> > +        return -EINVAL;
> > +    }
> > +
> > +    err = hvm_load_entry(VMCE_VCPU, h, &ctxt);
> > +    if ( !err )
> > +        v->arch.nr_vmce_banks = ctxt.nr_banks;
> > +
> > +    return err;
> > +}
> > +
> > +HVM_REGISTER_SAVE_RESTORE(VMCE_VCPU, vmce_save_vcpu_ctxt,
> > +                          vmce_load_vcpu_ctxt, 1, HVMSR_PER_VCPU);
> > +
> >  int inject_vmce(struct domain *d)
> >  {
> >      int cpu = smp_processor_id();
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -468,6 +468,8 @@ int vcpu_initialise(struct vcpu *v)
> > 
> >      v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
> > 
> > +    vmce_init_vcpu(v);
> > +
> >      rc = is_pv_32on64_vcpu(v) ? setup_compat_l4(v) : 0;
> >   done:
> >      if ( rc )
> > --- a/xen/arch/x86/domctl.c
> > +++ b/xen/arch/x86/domctl.c
> > @@ -1027,11 +1027,12 @@ long arch_do_domctl(
> >                  evc->syscall32_callback_eip    = 0;
> >                  evc->syscall32_disables_events = 0;
> >              }
> > +            evc->nr_mce_banks = v->arch.nr_vmce_banks;
> >          }
> >          else
> >          {
> >              ret = -EINVAL;
> > -            if ( evc->size != sizeof(*evc) )
> > +            if ( evc->size < offsetof(typeof(*evc), nr_mce_banks) )
> >                  goto ext_vcpucontext_out;
> >  #ifdef __x86_64__
> >              if ( !is_hvm_domain(d) )
> > @@ -1059,6 +1060,16 @@ long arch_do_domctl(
> >                   (evc->syscall32_callback_cs & ~3) ||
> >                   evc->syscall32_callback_eip )
> >                  goto ext_vcpucontext_out;
> > +
> > +            if ( evc->size >= offsetof(typeof(*evc), mbz[ARRAY_SIZE(evc->mbz)]) )
> > +            {
> > +                unsigned int i;
> > +
> > +                for ( i = 0; i < ARRAY_SIZE(evc->mbz); ++i )
> > +                    if ( evc->mbz[i] )
> > +                        goto ext_vcpucontext_out;
> > +                v->arch.nr_vmce_banks = evc->nr_mce_banks;
> > +            }
> >          }
> > 
> >          ret = 0;
> > --- a/xen/include/asm-x86/domain.h
> > +++ b/xen/include/asm-x86/domain.h
> > @@ -488,6 +488,8 @@ struct arch_vcpu
> >      /* This variable determines whether nonlazy extended state has been used,
> >       * and thus should be saved/restored. */
> >      bool_t nonlazy_xstate_used;
> > +
> > +    uint8_t nr_vmce_banks;
> > 
> >      struct paging_vcpu paging;
> > 
> > --- a/xen/include/asm-x86/mce.h
> > +++ b/xen/include/asm-x86/mce.h
> > @@ -28,6 +28,7 @@ struct domain_mca_msrs
> >  /* Guest vMCE MSRs virtualization */
> >  extern int vmce_init_msr(struct domain *d);
> >  extern void vmce_destroy_msr(struct domain *d);
> > +extern void vmce_init_vcpu(struct vcpu *);
> >  extern int vmce_wrmsr(uint32_t msr, uint64_t val);
> >  extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
> > 
> > --- a/xen/include/public/arch-x86/hvm/save.h
> > +++ b/xen/include/public/arch-x86/hvm/save.h
> > @@ -585,9 +585,15 @@ struct hvm_viridian_vcpu_context {
> > 
> >  DECLARE_HVM_SAVE_TYPE(VIRIDIAN_VCPU, 17, struct hvm_viridian_vcpu_context);
> > 
> > +struct hvm_vmce_vcpu {
> > +    uint8_t nr_banks;
> > +};
> > +
> > +DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
> > +
> >  /*
> >   * Largest type-code in use
> >   */
> > -#define HVM_SAVE_CODE_MAX 17
> > +#define HVM_SAVE_CODE_MAX 18
> > 
> >  #endif /* __XEN_PUBLIC_HVM_SAVE_X86_H__ */
> > --- a/xen/include/public/domctl.h
> > +++ b/xen/include/public/domctl.h
> > @@ -559,7 +559,7 @@ struct xen_domctl_ext_vcpucontext {
> >      uint32_t         vcpu;
> >      /*
> >       * SET: Size of struct (IN)
> > -     * GET: Size of struct (OUT)
> > +     * GET: Size of struct (OUT, up to 128 bytes)
> >       */
> >      uint32_t         size;
> >  #if defined(__i386__) || defined(__x86_64__)
> > @@ -571,6 +571,10 @@ struct xen_domctl_ext_vcpucontext {
> >      uint16_t         sysenter_callback_cs;
> >      uint8_t          syscall32_disables_events;
> >      uint8_t          sysenter_disables_events;
> > +    uint8_t          nr_mce_banks;
> > +    /* This array can be split and used for future extension. */
> > +    /* It is there just to grow the structure beyond 4.1's size. */
> > +    uint8_t          mbz[9];
> >  #endif
> >  };
> >  typedef struct xen_domctl_ext_vcpucontext xen_domctl_ext_vcpucontext_t;
> > 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11: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 1RsBvA-0006hA-QZ; Tue, 31 Jan 2012 11:30:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RsBv9-0006gn-LU
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:30:43 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328009436!10930766!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22956 invoked from network); 31 Jan 2012 11:30:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 11:30:37 -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 q0VAT8Wg002398
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 05:29:08 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0VAT6PO022446; Tue, 31 Jan 2012 05:29:07 -0500
Message-ID: <4F27C2CE.30702@redhat.com>
Date: Tue, 31 Jan 2012 11:30:38 +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: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
References: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
In-Reply-To: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to get DomU id from DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/12 11:01, Roger Pau Monn=E9 wrote:

> This is quite a trivial question, but I haven't been able to find how
> to do it. Is there anyway to get the id of a PV DomU from inside the
> (same) PV DomU?

Here's a hack (untested): one could create a loop event channel with =

EVTCHNOP_bind_interdomain (passing in DOMID_SELF as remote_dom), then =

query it with EVTCHNOP_status (also passing in DOMID_SELF). On return, =

"interdomain.dom" (=3D the remote end) should have the real domid.

Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:30:55 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11: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 1RsBvA-0006hA-QZ; Tue, 31 Jan 2012 11:30:44 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <lersek@redhat.com>) id 1RsBv9-0006gn-LU
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:30:43 +0000
X-Env-Sender: lersek@redhat.com
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328009436!10930766!1
X-Originating-IP: [209.132.183.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTE2MDk=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22956 invoked from network); 31 Jan 2012 11:30:37 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28)
	by server-8.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 11:30:37 -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 q0VAT8Wg002398
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 05:29:08 -0500
Received: from lacos-laptop.usersys.redhat.com (dhcp-1-169.brq.redhat.com
	[10.34.1.169])
	by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id q0VAT6PO022446; Tue, 31 Jan 2012 05:29:07 -0500
Message-ID: <4F27C2CE.30702@redhat.com>
Date: Tue, 31 Jan 2012 11:30:38 +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: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
References: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
In-Reply-To: <CAPLaKK7bMzTQ_Uw2RBOkXQcFvg4qRS1EUHpY3Qpm6RSYPeXCjg@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] How to get DomU id from DomU
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/12 11:01, Roger Pau Monn=E9 wrote:

> This is quite a trivial question, but I haven't been able to find how
> to do it. Is there anyway to get the id of a PV DomU from inside the
> (same) PV DomU?

Here's a hack (untested): one could create a loop event channel with =

EVTCHNOP_bind_interdomain (passing in DOMID_SELF as remote_dom), then =

query it with EVTCHNOP_status (also passing in DOMID_SELF). On return, =

"interdomain.dom" (=3D the remote end) should have the real domid.

Laszlo

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:51:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsCEw-00078I-7h; Tue, 31 Jan 2012 11:51: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 1RsCEv-00078A-CU
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:51:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328010663!13306739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16691 invoked from network); 31 Jan 2012 11:51:03 -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;
	31 Jan 2012 11:51:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10387108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:51: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;
	Tue, 31 Jan 2012 11:51:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Tue, 31 Jan 2012 11:51:03 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328010663.26983.367.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This weeks update. Please send me corrections (especially
"done"). Lots of DONE this week, nice to see. We've had patches posted
for most of the blockers too AFAICT.

hypervisor, blockers:

      * round-up of the closing of the security hole in MSI-X
        passthrough (uniformly - i.e. even for Dom0 - disallowing write
        access to MSI-X table pages). (Jan Beulich -- more fixes
        required than first thought, patches posted)
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice and schedule rate. (George Dunlap)
      * get the interface changes for sharing/paging/mem-events done and
        dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
        Andres Lagar-Cavilla et al)
              * mem event ring management DONE
              * sharing patches posted

tools, blockers:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (Ian J, DONE)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate). (Ian Campbell, patches
                posted, repost pending).
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                repost pending)
              * topologyinfo datastructure should be a list of tuples,
                not a tuple of lists. (Ian Campbell, patches posted,
                repost pending)
      * xl to use json for machine readable output instead of sexp by
        default (Ian Campbell, patch posted, repost pending)
      * xl support for vcpu pinning (Dario Faggioli, DONE)
      * xl feature parity with xend wrt driver domain support (George
        Dunlap)
      * Integrate qemu+seabios upstream into the build (Stefano, DONE).
        No change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

hypervisor, nice to have:

      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al)
      * A long standing issue is a fully synchronized p2m (locking
        lookups) (Andres Lagar-Cavilla)
      * NUMA improvement: domain affinity consistent with cpupool
        membership (Dario Faggioli, Jeurgen Gross -- DONE)

tools, nice to have:

      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms. (discussion on-going. patches posted?)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monet)
      * libyajl v2 support (patch posted by Roger Pau Monet, general
        agrement that this shouldn't be blocked by autoconf but that we
        probably will take both)
      * Configure/control paging via xl/libxl (Olaf Herring)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard)
              * Upstream qemu save restore (Anthony Perard)
      * Nested-virtualisation (currently should be marked
        experimental,likely to release that way? Consider nested-svm
        separate to nested-vmx. Nested-svm is in better shape)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, patches posted)

Tools, need to decide if pre- or post-4.2 feature:

      * Autoconf (Roger Pau Monet posted a patch, we'll probably take
        this for 4.2)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:51:30 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:51:30 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsCEw-00078I-7h; Tue, 31 Jan 2012 11:51: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 1RsCEv-00078A-CU
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:51:09 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328010663!13306739!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16691 invoked from network); 31 Jan 2012 11:51:03 -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;
	31 Jan 2012 11:51:03 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10387108"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:51: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;
	Tue, 31 Jan 2012 11:51:03 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: xen-devel <xen-devel@lists.xensource.com>
Date: Tue, 31 Jan 2012 11:51:03 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328010663.26983.367.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Subject: [Xen-devel] Xen 4.2 TODO List Update
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This weeks update. Please send me corrections (especially
"done"). Lots of DONE this week, nice to see. We've had patches posted
for most of the blockers too AFAICT.

hypervisor, blockers:

      * round-up of the closing of the security hole in MSI-X
        passthrough (uniformly - i.e. even for Dom0 - disallowing write
        access to MSI-X table pages). (Jan Beulich -- more fixes
        required than first thought, patches posted)
      * domctls / sysctls set up to modify scheduler parameters, like
        the credit1 timeslice and schedule rate. (George Dunlap)
      * get the interface changes for sharing/paging/mem-events done and
        dusted so that 4.2 is a stable API that we hold to. (Tim Deegan,
        Andres Lagar-Cavilla et al)
              * mem event ring management DONE
              * sharing patches posted

tools, blockers:

      * libxl stable API -- we would like 4.2 to define a stable API
        which downstream's can start to rely on not changing. Aspects of
        this are:
              * event handling (Ian J, DONE)
              * drop libxl_device_model_info (move bits to build_info or
                elsewhere as appropriate). (Ian Campbell, patches
                posted, repost pending).
              * add libxl_defbool and generally try and arrange that
                memset(foo,0,...) requests the defaults (Ian Campbell,
                repost pending)
              * topologyinfo datastructure should be a list of tuples,
                not a tuple of lists. (Ian Campbell, patches posted,
                repost pending)
      * xl to use json for machine readable output instead of sexp by
        default (Ian Campbell, patch posted, repost pending)
      * xl support for vcpu pinning (Dario Faggioli, DONE)
      * xl feature parity with xend wrt driver domain support (George
        Dunlap)
      * Integrate qemu+seabios upstream into the build (Stefano, DONE).
        No change in default qemu for 4.2.
      * More formally deprecate xm/xend. Manpage patches already in
        tree. Needs release noting and communication around -rc1 to
        remind people to test xl.

hypervisor, nice to have:

      * solid implementation of sharing/paging/mem-events (using work
        queues) (Tim Deegan, Olaf Herring et al)
      * A long standing issue is a fully synchronized p2m (locking
        lookups) (Andres Lagar-Cavilla)
      * NUMA improvement: domain affinity consistent with cpupool
        membership (Dario Faggioli, Jeurgen Gross -- DONE)

tools, nice to have:

      * Hotplug script stuff -- internal to libxl (I think, therefore I
        didn't put this under stable API above) but still good to have
        for 4.2? Roger Pau Monet was looking at this but its looking
        like a big can-o-worms. (discussion on-going. patches posted?)
      * Block script support -- follows on from hotplug script (Roger
        Pau Monet)
      * libyajl v2 support (patch posted by Roger Pau Monet, general
        agrement that this shouldn't be blocked by autoconf but that we
        probably will take both)
      * Configure/control paging via xl/libxl (Olaf Herring)
      * Upstream qemu feature patches:
              * Upstream qemu PCI passthrough support (Anthony Perard)
              * Upstream qemu save restore (Anthony Perard)
      * Nested-virtualisation (currently should be marked
        experimental,likely to release that way? Consider nested-svm
        separate to nested-vmx. Nested-svm is in better shape)
      * Initial xl support for Remus (memory checkpoint, blackholing)
        (Shriram, patches posted)

Tools, need to decide if pre- or post-4.2 feature:

      * Autoconf (Roger Pau Monet posted a patch, we'll probably take
        this for 4.2)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:57:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsCKX-0007Lv-9k; Tue, 31 Jan 2012 11:56:57 +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 1RsCKV-0007Ld-81
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:56:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328011009!13091745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5331 invoked from network); 31 Jan 2012 11:56:49 -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;
	31 Jan 2012 11:56:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10387225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:56:48 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:56:48 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328006229.26983.343.camel@zakaz.uk.xensource.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-15-git-send-email-wei.liu2@citrix.com>
	<1328006229.26983.343.camel@zakaz.uk.xensource.com>
Date: Tue, 31 Jan 2012 11:57:02 +0000
Message-ID: <1328011022.5553.83.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 14/16] netback: split event channels
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 10:37 +0000, Ian Campbell wrote:
> O
> 
> Can you get rid of split_irq by setting tx_irq == rx_irq in that case
> and simplify the code by doing so?
> 
> I think this should work even for places like:
> 
> 	if (!vif->split_irq)
> 		enable_irq(vif->tx_irq);
> 	else {
> 		enable_irq(vif->tx_irq);
> 		enable_irq(vif->rx_irq);
> 	}
> 
> Just by doing
> 		enable_irq(vif->tx_irq);
> 		enable_irq(vif->rx_irq);
> 
> Since enable/disable_irq maintain a count and so it will do the right
> thing if they happen to be the same.
> 

Hmm... OK.

> >  	/* The shared tx ring and index. */
> >  	struct xen_netif_tx_back_ring tx;
> > @@ -162,7 +164,8 @@ struct xenvif *xenvif_alloc(struct device *parent,
> >  int xenvif_connect(struct xenvif *vif,
> >  		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
> >  		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
> > -		   unsigned int evtchn, unsigned int rx_protocol);
> > +		   unsigned int evtchn[], int split_evtchn,
> > +		   unsigned int rx_protocol);
> >  void xenvif_disconnect(struct xenvif *vif);
> >  
> >  int xenvif_xenbus_init(void);
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> > index 0f05f03..afccd5d 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -46,15 +46,31 @@ int xenvif_schedulable(struct xenvif *vif)
> >  	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
> >  }
> >  
> > -static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> > +static irqreturn_t xenvif_tx_interrupt(int irq, void *dev_id)
> > +{
> > +	struct xenvif *vif = dev_id;
> > +
> > +	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
> > +		napi_schedule(&vif->napi);
> > +
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
> >  {
> >  	struct xenvif *vif = dev_id;
> >  
> >  	if (xenvif_schedulable(vif) && vif->event != NULL)
> >  		vif->event(vif);
> >  
> > -	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
> > -		napi_schedule(&vif->napi);
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> > +{
> > +	xenvif_tx_interrupt(0, dev_id);
> 
> Might as well pass irq down.

Sure.

> [...]
> > @@ -308,13 +334,14 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> >  int xenvif_connect(struct xenvif *vif,
> >  		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
> >  		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
> > -		   unsigned int evtchn, unsigned int rx_protocol)
> > +		   unsigned int evtchn[], int split_evtchn,
> 
> Explicitly tx_evtchn and rx_evtchn would be clearer than remembering
> that [0]==tx and [1]==rx I think.
> 
> > +		   unsigned int rx_protocol)
> >  {
> >  	int err = -ENOMEM;
> >  	struct xen_netif_tx_sring *txs;
> >  
> >  	/* Already connected through? */
> > -	if (vif->irq)
> > +	if (vif->tx_irq)
> >  		return 0;
> >  
> >  	__module_get(THIS_MODULE);
> > @@ -345,13 +372,35 @@ int xenvif_connect(struct xenvif *vif,
> >  	if (vif->setup(vif))
> >  		goto err_rx_unmap;
> >  
> > -	err = bind_interdomain_evtchn_to_irqhandler(
> > -		vif->domid, evtchn, xenvif_interrupt, 0,
> > -		vif->dev->name, vif);
> > -	if (err < 0)
> > -		goto err_rx_unmap;
> > -	vif->irq = err;
> > -	disable_irq(vif->irq);
> > +	if (!split_evtchn) {
> 
> Presumably this is one of the places where you do have to care about
> split vs non. I did consider whether simply registering two handlers for
> the interrupt in a shared-interrupt style would work, but I think that
> way lies madness and confusion...
> 
> > +		err = bind_interdomain_evtchn_to_irqhandler(
> > +			vif->domid, evtchn[0], xenvif_interrupt, 0,
> > +			vif->dev->name, vif);
> > +		if (err < 0)
> > +			goto err_rx_unmap;
> > +		vif->tx_irq = vif->rx_irq = err;
> > +		disable_irq(vif->tx_irq);
> > +		vif->split_irq = 0;
> > +	} else {
> > +		err = bind_interdomain_evtchn_to_irqhandler(
> > +			vif->domid, evtchn[0], xenvif_tx_interrupt,
> > +			0, vif->dev->name, vif);
> > +		if (err < 0)
> > +			goto err_rx_unmap;
> > +		vif->tx_irq = err;
> > +		disable_irq(vif->tx_irq);
> > +
> > +		err = bind_interdomain_evtchn_to_irqhandler(
> > +			vif->domid, evtchn[1], xenvif_rx_interrupt,
> > +			0, vif->dev->name, vif);
> > +		if (err < 0) {
> > +			unbind_from_irqhandler(vif->tx_irq, vif);
> > +			goto err_rx_unmap;
> > +		}
> > +		vif->rx_irq = err;
> > +		disable_irq(vif->rx_irq);
> > +		vif->split_irq = 1;
> > +	}
> >  
> >  	init_waitqueue_head(&vif->wq);
> >  	vif->task = kthread_create(xenvif_kthread,
> > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> > index 4067286..c5a3b27 100644
> > --- a/drivers/net/xen-netback/xenbus.c
> > +++ b/drivers/net/xen-netback/xenbus.c
> > @@ -131,6 +131,14 @@ static int netback_probe(struct xenbus_device *dev,
> >  			goto abort_transaction;
> >  		}
> >  
> > +		err = xenbus_printf(xbt, dev->nodename,
> > +				    "split-event-channels",
> 
> Usually we use "feature-FOO" as the names for these sorts of nodes.
> 

Got it.

> > +				    "%u", 1);
> > +		if (err) {
> > +			message = "writing split-event-channels";
> > +			goto abort_transaction;
> > +		}
> > +
> >  		err = xenbus_transaction_end(xbt, 0);
> >  	} while (err == -EAGAIN);
> >  
> > @@ -408,7 +416,7 @@ static int connect_rings(struct backend_info *be)
> >  {
> >  	struct xenvif *vif = be->vif;
> >  	struct xenbus_device *dev = be->dev;
> > -	unsigned int evtchn, rx_copy;
> > +	unsigned int evtchn[2], split_evtchn, rx_copy;
> 
> Another case where I think two vars is better than a small array.
> 
> >  	int err;
> >  	int val;
> >  	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
> 

Reasonable change.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 11:57:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 11:57:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsCKX-0007Lv-9k; Tue, 31 Jan 2012 11:56:57 +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 1RsCKV-0007Ld-81
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 11:56:55 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-2.tower-182.messagelabs.com!1328011009!13091745!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 5331 invoked from network); 31 Jan 2012 11:56:49 -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;
	31 Jan 2012 11:56:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,595,1320624000"; d="scan'208";a="10387225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:56:48 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 11:56:48 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328006229.26983.343.camel@zakaz.uk.xensource.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-15-git-send-email-wei.liu2@citrix.com>
	<1328006229.26983.343.camel@zakaz.uk.xensource.com>
Date: Tue, 31 Jan 2012 11:57:02 +0000
Message-ID: <1328011022.5553.83.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 14/16] netback: split event channels
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 10:37 +0000, Ian Campbell wrote:
> O
> 
> Can you get rid of split_irq by setting tx_irq == rx_irq in that case
> and simplify the code by doing so?
> 
> I think this should work even for places like:
> 
> 	if (!vif->split_irq)
> 		enable_irq(vif->tx_irq);
> 	else {
> 		enable_irq(vif->tx_irq);
> 		enable_irq(vif->rx_irq);
> 	}
> 
> Just by doing
> 		enable_irq(vif->tx_irq);
> 		enable_irq(vif->rx_irq);
> 
> Since enable/disable_irq maintain a count and so it will do the right
> thing if they happen to be the same.
> 

Hmm... OK.

> >  	/* The shared tx ring and index. */
> >  	struct xen_netif_tx_back_ring tx;
> > @@ -162,7 +164,8 @@ struct xenvif *xenvif_alloc(struct device *parent,
> >  int xenvif_connect(struct xenvif *vif,
> >  		   unsigned long tx_ring_ref[], unsigned int tx_ring_order,
> >  		   unsigned long rx_ring_ref[], unsigned int rx_ring_order,
> > -		   unsigned int evtchn, unsigned int rx_protocol);
> > +		   unsigned int evtchn[], int split_evtchn,
> > +		   unsigned int rx_protocol);
> >  void xenvif_disconnect(struct xenvif *vif);
> >  
> >  int xenvif_xenbus_init(void);
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> > index 0f05f03..afccd5d 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -46,15 +46,31 @@ int xenvif_schedulable(struct xenvif *vif)
> >  	return netif_running(vif->dev) && netif_carrier_ok(vif->dev);
> >  }
> >  
> > -static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> > +static irqreturn_t xenvif_tx_interrupt(int irq, void *dev_id)
> > +{
> > +	struct xenvif *vif = dev_id;
> > +
> > +	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
> > +		napi_schedule(&vif->napi);
> > +
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t xenvif_rx_interrupt(int irq, void *dev_id)
> >  {
> >  	struct xenvif *vif = dev_id;
> >  
> >  	if (xenvif_schedulable(vif) && vif->event != NULL)
> >  		vif->event(vif);
> >  
> > -	if (RING_HAS_UNCONSUMED_REQUESTS(&vif->tx))
> > -		napi_schedule(&vif->napi);
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static irqreturn_t xenvif_interrupt(int irq, void *dev_id)
> > +{
> > +	xenvif_tx_interrupt(0, dev_id);
> 
> Might as well pass irq down.

Sure.

> [...]
> > @@ -308,13 +334,14 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> >  int xenvif_connect(struct xenvif *vif,
> >  		   unsigned long tx_ring_ref[], unsigned int tx_ring_ref_count,
> >  		   unsigned long rx_ring_ref[], unsigned int rx_ring_ref_count,
> > -		   unsigned int evtchn, unsigned int rx_protocol)
> > +		   unsigned int evtchn[], int split_evtchn,
> 
> Explicitly tx_evtchn and rx_evtchn would be clearer than remembering
> that [0]==tx and [1]==rx I think.
> 
> > +		   unsigned int rx_protocol)
> >  {
> >  	int err = -ENOMEM;
> >  	struct xen_netif_tx_sring *txs;
> >  
> >  	/* Already connected through? */
> > -	if (vif->irq)
> > +	if (vif->tx_irq)
> >  		return 0;
> >  
> >  	__module_get(THIS_MODULE);
> > @@ -345,13 +372,35 @@ int xenvif_connect(struct xenvif *vif,
> >  	if (vif->setup(vif))
> >  		goto err_rx_unmap;
> >  
> > -	err = bind_interdomain_evtchn_to_irqhandler(
> > -		vif->domid, evtchn, xenvif_interrupt, 0,
> > -		vif->dev->name, vif);
> > -	if (err < 0)
> > -		goto err_rx_unmap;
> > -	vif->irq = err;
> > -	disable_irq(vif->irq);
> > +	if (!split_evtchn) {
> 
> Presumably this is one of the places where you do have to care about
> split vs non. I did consider whether simply registering two handlers for
> the interrupt in a shared-interrupt style would work, but I think that
> way lies madness and confusion...
> 
> > +		err = bind_interdomain_evtchn_to_irqhandler(
> > +			vif->domid, evtchn[0], xenvif_interrupt, 0,
> > +			vif->dev->name, vif);
> > +		if (err < 0)
> > +			goto err_rx_unmap;
> > +		vif->tx_irq = vif->rx_irq = err;
> > +		disable_irq(vif->tx_irq);
> > +		vif->split_irq = 0;
> > +	} else {
> > +		err = bind_interdomain_evtchn_to_irqhandler(
> > +			vif->domid, evtchn[0], xenvif_tx_interrupt,
> > +			0, vif->dev->name, vif);
> > +		if (err < 0)
> > +			goto err_rx_unmap;
> > +		vif->tx_irq = err;
> > +		disable_irq(vif->tx_irq);
> > +
> > +		err = bind_interdomain_evtchn_to_irqhandler(
> > +			vif->domid, evtchn[1], xenvif_rx_interrupt,
> > +			0, vif->dev->name, vif);
> > +		if (err < 0) {
> > +			unbind_from_irqhandler(vif->tx_irq, vif);
> > +			goto err_rx_unmap;
> > +		}
> > +		vif->rx_irq = err;
> > +		disable_irq(vif->rx_irq);
> > +		vif->split_irq = 1;
> > +	}
> >  
> >  	init_waitqueue_head(&vif->wq);
> >  	vif->task = kthread_create(xenvif_kthread,
> > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> > index 4067286..c5a3b27 100644
> > --- a/drivers/net/xen-netback/xenbus.c
> > +++ b/drivers/net/xen-netback/xenbus.c
> > @@ -131,6 +131,14 @@ static int netback_probe(struct xenbus_device *dev,
> >  			goto abort_transaction;
> >  		}
> >  
> > +		err = xenbus_printf(xbt, dev->nodename,
> > +				    "split-event-channels",
> 
> Usually we use "feature-FOO" as the names for these sorts of nodes.
> 

Got it.

> > +				    "%u", 1);
> > +		if (err) {
> > +			message = "writing split-event-channels";
> > +			goto abort_transaction;
> > +		}
> > +
> >  		err = xenbus_transaction_end(xbt, 0);
> >  	} while (err == -EAGAIN);
> >  
> > @@ -408,7 +416,7 @@ static int connect_rings(struct backend_info *be)
> >  {
> >  	struct xenvif *vif = be->vif;
> >  	struct xenbus_device *dev = be->dev;
> > -	unsigned int evtchn, rx_copy;
> > +	unsigned int evtchn[2], split_evtchn, rx_copy;
> 
> Another case where I think two vars is better than a small array.
> 
> >  	int err;
> >  	int val;
> >  	unsigned long tx_ring_ref[NETBK_MAX_RING_PAGES];
> 

Reasonable change.


Wei.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 12:43:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 12:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsD38-00007Q-Gv; Tue, 31 Jan 2012 12:43:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RsD37-00007L-0J
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 12:43:01 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328013774!12845547!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NzA3Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21878 invoked from network); 31 Jan 2012 12:42:55 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 12:42:55 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=kMDQJaI9XGHQFAc3o07IGNRx7GPvQ7RkeAhlBPDYjQ5Nzfb10JTVIrM6
	MF0mKHaPjz4ofTtXUetjGdO2jvSluvBuBQx0lj0Um02CB0FqP3ivrY2w2
	SAqgBIq+leUjCZ7KyhXpA7uOqg53mnMJWta79FBRhYnNNCpJwOQFmQXpy
	XyQd9aBonuh8Io67zoIYQFoZtPDQGugtYT0XAenPVpqAtORgIu32LPF6J
	ZQuFFc0BL2tX7UXocQSWuGUhQyDw+;
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=1328013775; x=1359549775;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=dEVQ86jN1e7Vbeu0Hzxaie8KQEFDkYhYTMJ4smJ+NQE=;
	b=kJc7C99hbbWb/vzXq1LBZhLRT0sPX/SAXYaWqFQibDqKFqsdcXTvuCru
	+89BCUqNhiH57/cho2OKLgTbD5wi/cHKLEmv3rpbqFIsOJbD/RCup+HbG
	hOzeEDmvHNACdK6onr9l5f2wIny1fRZhqvV17vF+9DSEx83s5RMTEcHuu
	9L/iSdcpsngHFzl89o+XR4Yi3+T3OLuvqrKVlRymEajB/PvUaGpLyaz46
	p58F6RRNRtocOkw/d5cPEAtMTkfzy;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="84941270"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 31 Jan 2012 13:42:54 +0100
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="128048293"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 31 Jan 2012 13:42:54 +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 45DFE76C0A4;
	Tue, 31 Jan 2012 13:42:54 +0100 (CET)
Message-ID: <4F27E1CE.6080100@ts.fujitsu.com>
Date: Tue, 31 Jan 2012 13:42:54 +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: Jan Beulich <JBeulich@suse.com>
References: <4F268C03.5000003@ts.fujitsu.com>	<4F26D2A8020000780006FF2F@nat28.tlf.novell.com>
	<4F279D56.3030303@ts.fujitsu.com>
In-Reply-To: <4F279D56.3030303@ts.fujitsu.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/2012 08:50 AM, Juergen Gross wrote:
> On 01/30/2012 05:26 PM, Jan Beulich wrote:
>>>>> On 30.01.12 at 13:24, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>>> To avoid this stall I tried to start a little daemon on the target machine
>>> and watch for a new BS2000 domain to show up due to live migration. I wanted
>>> to map the domain memory as soon as the needed mapping information located
>>> in a fixed guest mfn was transferred. Discovery of the new domain works as
>>> expected, but I'm not capable doing any memory mapping until the restore of
>>> the domain is finished. The mapping ioctl using IOCTL_PRIVCMD_MMAP returns
>>> EINVAL until xc_restore is finished (more or less).
>>>
>>> Why can xc_restore do the mapping while I can't? I know xc_restore is using
>>> IOCTL_PRIVCMD_MMAPBATCH_V2, but I can't see a difference which should matter
>>> between those two, as both are using the same hypercall to update the dom0
>>> page tables.
>> I cannot immediately think of a reason (and indeed the difference
>> between the two is only how errors get handled), so I wonder
>> whether you checked where the - pretty generic - -EINVAL is
>> coming from. You also didn't mention whether any hypervisor log
>> entries are associated with you failed attempts.
>
> I'll start to add some logging to the hypervisor today.
>
> No hypervisor logs were produced in my tests, despite of setting
>
> debug=yes loglvl=all guest_loglvl=all
>
> as boot parameters.
>
> I've made an additional test using xm save/xm restore to see if the same
> problem shows up. It does NOT. Mapping succeeds at once while restoring
> memory is still running. I always thought xm restore and live migration on
> the target machine are more or less the same. This seems not to be true.

Okay, here are my results (so far):

do_mmu_update() calls mod_l1_entry() which fails with -EINVAL due to an
invalid mfn and p2m-type == 4 returned by:

mfn_x(gfn_to_mfn(pg_dom, l1e_get_pfn(nl1e), &p2mt))

I still don't see why xc_restore is able to do the mapping while my daemon is
not. And I can't find any difference between a domain creation due to
xm restore and a live migration.


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 Jan 31 12:43:34 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 12:43:34 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsD38-00007Q-Gv; Tue, 31 Jan 2012 12:43:02 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <juergen.gross@ts.fujitsu.com>) id 1RsD37-00007L-0J
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 12:43:01 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328013774!12845547!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NzA3Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21878 invoked from network); 31 Jan 2012 12:42:55 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 12:42:55 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=kMDQJaI9XGHQFAc3o07IGNRx7GPvQ7RkeAhlBPDYjQ5Nzfb10JTVIrM6
	MF0mKHaPjz4ofTtXUetjGdO2jvSluvBuBQx0lj0Um02CB0FqP3ivrY2w2
	SAqgBIq+leUjCZ7KyhXpA7uOqg53mnMJWta79FBRhYnNNCpJwOQFmQXpy
	XyQd9aBonuh8Io67zoIYQFoZtPDQGugtYT0XAenPVpqAtORgIu32LPF6J
	ZQuFFc0BL2tX7UXocQSWuGUhQyDw+;
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=1328013775; x=1359549775;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=dEVQ86jN1e7Vbeu0Hzxaie8KQEFDkYhYTMJ4smJ+NQE=;
	b=kJc7C99hbbWb/vzXq1LBZhLRT0sPX/SAXYaWqFQibDqKFqsdcXTvuCru
	+89BCUqNhiH57/cho2OKLgTbD5wi/cHKLEmv3rpbqFIsOJbD/RCup+HbG
	hOzeEDmvHNACdK6onr9l5f2wIny1fRZhqvV17vF+9DSEx83s5RMTEcHuu
	9L/iSdcpsngHFzl89o+XR4Yi3+T3OLuvqrKVlRymEajB/PvUaGpLyaz46
	p58F6RRNRtocOkw/d5cPEAtMTkfzy;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="84941270"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate20u.abg.fsc.net with ESMTP; 31 Jan 2012 13:42:54 +0100
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="128048293"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 31 Jan 2012 13:42:54 +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 45DFE76C0A4;
	Tue, 31 Jan 2012 13:42:54 +0100 (CET)
Message-ID: <4F27E1CE.6080100@ts.fujitsu.com>
Date: Tue, 31 Jan 2012 13:42:54 +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: Jan Beulich <JBeulich@suse.com>
References: <4F268C03.5000003@ts.fujitsu.com>	<4F26D2A8020000780006FF2F@nat28.tlf.novell.com>
	<4F279D56.3030303@ts.fujitsu.com>
In-Reply-To: <4F279D56.3030303@ts.fujitsu.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/2012 08:50 AM, Juergen Gross wrote:
> On 01/30/2012 05:26 PM, Jan Beulich wrote:
>>>>> On 30.01.12 at 13:24, Juergen Gross<juergen.gross@ts.fujitsu.com>  wrote:
>>> To avoid this stall I tried to start a little daemon on the target machine
>>> and watch for a new BS2000 domain to show up due to live migration. I wanted
>>> to map the domain memory as soon as the needed mapping information located
>>> in a fixed guest mfn was transferred. Discovery of the new domain works as
>>> expected, but I'm not capable doing any memory mapping until the restore of
>>> the domain is finished. The mapping ioctl using IOCTL_PRIVCMD_MMAP returns
>>> EINVAL until xc_restore is finished (more or less).
>>>
>>> Why can xc_restore do the mapping while I can't? I know xc_restore is using
>>> IOCTL_PRIVCMD_MMAPBATCH_V2, but I can't see a difference which should matter
>>> between those two, as both are using the same hypercall to update the dom0
>>> page tables.
>> I cannot immediately think of a reason (and indeed the difference
>> between the two is only how errors get handled), so I wonder
>> whether you checked where the - pretty generic - -EINVAL is
>> coming from. You also didn't mention whether any hypervisor log
>> entries are associated with you failed attempts.
>
> I'll start to add some logging to the hypervisor today.
>
> No hypervisor logs were produced in my tests, despite of setting
>
> debug=yes loglvl=all guest_loglvl=all
>
> as boot parameters.
>
> I've made an additional test using xm save/xm restore to see if the same
> problem shows up. It does NOT. Mapping succeeds at once while restoring
> memory is still running. I always thought xm restore and live migration on
> the target machine are more or less the same. This seems not to be true.

Okay, here are my results (so far):

do_mmu_update() calls mod_l1_entry() which fails with -EINVAL due to an
invalid mfn and p2m-type == 4 returned by:

mfn_x(gfn_to_mfn(pg_dom, l1e_get_pfn(nl1e), &p2mt))

I still don't see why xc_restore is able to do the mapping while my daemon is
not. And I can't find any difference between a domain creation due to
xm restore and a live migration.


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 Jan 31 12:50:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 12:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDAF-0000QH-Ky; Tue, 31 Jan 2012 12:50:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RsDAD-0000PX-L5; Tue, 31 Jan 2012 12:50:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328014215!12855415!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25702 invoked from network); 31 Jan 2012 12:50:15 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 12:50:15 -0000
Received: by wibhm2 with SMTP id hm2so15656519wib.30
	for <multiple recipients>; Tue, 31 Jan 2012 04:50:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=WDhJiiYOnBQQZqUPX9NtS2pQ1RC2x+TdkSgAGnjguoA=;
	b=IBnOQjq14woCAq5bqAycBp2+dsPxS3zh6uEDv/eyGaVCBL8gors/PV7sDIyBJoWPuo
	EYnbVRIS16anJdwwbX0OSapUNTRlkf1La5tgd1Mle8STlmWknuIPMAt6wBvzlpXUmZ/G
	ycp8+tDiCebF5u9vZ0WEvfGK775KChFkmQdMI=
Received: by 10.180.24.202 with SMTP id w10mr2819942wif.9.1328014214836;
	Tue, 31 Jan 2012 04:50:14 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id j16sm62688190wie.4.2012.01.31.04.50.10
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 04:50:11 -0800 (PST)
Message-ID: <4F27E36B.8050200@xen.org>
Date: Tue, 31 Jan 2012 12:49:47 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Florian Heigl <florian.heigl@gmail.com>
References: <4F1473A2.4060103@xen.org>
	<CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
	<4F2666DC.7080601@xen.org>
	<CAFivhP=cr10B2p=d2is3wO3KtaFG1xD9WSPonM048J8aRB91oA@mail.gmail.com>
In-Reply-To: <CAFivhP=cr10B2p=d2is3wO3KtaFG1xD9WSPonM048J8aRB91oA@mail.gmail.com>
Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	xen-arm@lists.xensource.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users]  Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 30/01/2012 16:07, Florian Heigl wrote:
>
> these on the last Monday of the month, starting from Feb.
> Would it be possible to insert (i.e. quarterly) an extra doc day that
> is on a bank holiday or weekend for us with dayjobs?
> Of course it won't be fun if it's just me, but there got to be some
> more people interested!!!
> ,.
> Florian
>
I think that would be possible, but the challenge is to find a common 
bank holiday date. I added a "Extra Days" section on 
http://wiki.xen.org/wiki/Xen_Document_Days#Proposed_dates_for_2012 - how 
about proposing a couple of days and putting your name behind it.

Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 12:50:50 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 12:50:50 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDAF-0000QH-Ky; Tue, 31 Jan 2012 12:50:23 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RsDAD-0000PX-L5; Tue, 31 Jan 2012 12:50:21 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-9.tower-216.messagelabs.com!1328014215!12855415!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25702 invoked from network); 31 Jan 2012 12:50:15 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-9.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 12:50:15 -0000
Received: by wibhm2 with SMTP id hm2so15656519wib.30
	for <multiple recipients>; Tue, 31 Jan 2012 04:50:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	bh=WDhJiiYOnBQQZqUPX9NtS2pQ1RC2x+TdkSgAGnjguoA=;
	b=IBnOQjq14woCAq5bqAycBp2+dsPxS3zh6uEDv/eyGaVCBL8gors/PV7sDIyBJoWPuo
	EYnbVRIS16anJdwwbX0OSapUNTRlkf1La5tgd1Mle8STlmWknuIPMAt6wBvzlpXUmZ/G
	ycp8+tDiCebF5u9vZ0WEvfGK775KChFkmQdMI=
Received: by 10.180.24.202 with SMTP id w10mr2819942wif.9.1328014214836;
	Tue, 31 Jan 2012 04:50:14 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id j16sm62688190wie.4.2012.01.31.04.50.10
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 04:50:11 -0800 (PST)
Message-ID: <4F27E36B.8050200@xen.org>
Date: Tue, 31 Jan 2012 12:49:47 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Florian Heigl <florian.heigl@gmail.com>
References: <4F1473A2.4060103@xen.org>
	<CAPLaKK616ymyOp+=GBpdqj2Sv1SAFyU5dStCQ2C4Nd6udMadTw@mail.gmail.com>
	<4F2666DC.7080601@xen.org>
	<CAFivhP=cr10B2p=d2is3wO3KtaFG1xD9WSPonM048J8aRB91oA@mail.gmail.com>
In-Reply-To: <CAFivhP=cr10B2p=d2is3wO3KtaFG1xD9WSPonM048J8aRB91oA@mail.gmail.com>
Cc: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	xen-arm@lists.xensource.com,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>
Subject: Re: [Xen-devel] [Xen-users]  Xen Document Days for Jan,
 Feb & March : Looking for input on dates and a couple volunteers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
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 30/01/2012 16:07, Florian Heigl wrote:
>
> these on the last Monday of the month, starting from Feb.
> Would it be possible to insert (i.e. quarterly) an extra doc day that
> is on a bank holiday or weekend for us with dayjobs?
> Of course it won't be fun if it's just me, but there got to be some
> more people interested!!!
> ,.
> Florian
>
I think that would be possible, but the challenge is to find a common 
bank holiday date. I added a "Extra Days" section on 
http://wiki.xen.org/wiki/Xen_Document_Days#Proposed_dates_for_2012 - how 
about proposing a couple of days and putting your name behind it.

Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 12:57:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 12: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 1RsDGT-0000zU-5v; Tue, 31 Jan 2012 12:56:49 +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 1RsDGR-0000zB-Ld
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 12:56:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328014601!12846700!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20807 invoked from network); 31 Jan 2012 12:56:41 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 12:56:41 -0000
Received: by wgbdr13 with SMTP id dr13so228277wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 04:56: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7dSXTxVErHbvTWcB03yxKavamPIrdGkroSNZcUBqfSg=;
	b=CKSwRBgAzLCM0uKky8CijAD0dxff9lLu9bq2kp671j7In+GmeNJ7ngXOC72fdnvI1G
	Bgid+CZlP+gbTnl9SO6J9IuXzZI5VKUm2XmQvckulNZSUQaYP/EqE9esCtweDvpOKr5R
	YLAPwYoVCetB6bpeM4lls4TNz7DOHmNbEG/ho=
Received: by 10.180.95.105 with SMTP id dj9mr34042674wib.18.1328014601287;
	Tue, 31 Jan 2012 04:56:41 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id bj10sm37141727wib.9.2012.01.31.04.56.40
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 04:56:40 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 31 Jan 2012 12:56:37 +0000
From: Keir Fraser <keir@xen.org>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB4D9585.3894A%keir@xen.org>
Thread-Topic: [Xen-devel] live migration question
Thread-Index: AczgF8RZiJMY50PghEiCYcQ6AO/CCg==
In-Reply-To: <4F27E1CE.6080100@ts.fujitsu.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 31/01/2012 12:42, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

>> I've made an additional test using xm save/xm restore to see if the same
>> problem shows up. It does NOT. Mapping succeeds at once while restoring
>> memory is still running. I always thought xm restore and live migration on
>> the target machine are more or less the same. This seems not to be true.
> 
> Okay, here are my results (so far):
> 
> do_mmu_update() calls mod_l1_entry() which fails with -EINVAL due to an
> invalid mfn and p2m-type == 4 returned by:
> 
> mfn_x(gfn_to_mfn(pg_dom, l1e_get_pfn(nl1e), &p2mt))
> 
> I still don't see why xc_restore is able to do the mapping while my daemon is
> not. And I can't find any difference between a domain creation due to
> xm restore and a live migration.

Memory pages are populated as they appear in the migration data stream.
Perhaps you are trying to map a guest page that has simply not yet been
allocated.

Bear in mind that IOCTL_PRIVCMD_MMAPBATCH_V2 will note, but proceed past,
failed individual mappings. While IOCTL_PRIVCMD_MMAP, for example, will fail
the entire ioctl() in that situation. There's a reason that xc_restore uses
the former ioctl!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 12:57:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 12: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 1RsDGT-0000zU-5v; Tue, 31 Jan 2012 12:56:49 +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 1RsDGR-0000zB-Ld
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 12:56:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-216.messagelabs.com!1328014601!12846700!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20807 invoked from network); 31 Jan 2012 12:56:41 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-15.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 12:56:41 -0000
Received: by wgbdr13 with SMTP id dr13so228277wgb.24
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 04:56: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:cc:message-id:thread-topic
	:thread-index:in-reply-to:mime-version:content-type
	:content-transfer-encoding;
	bh=7dSXTxVErHbvTWcB03yxKavamPIrdGkroSNZcUBqfSg=;
	b=CKSwRBgAzLCM0uKky8CijAD0dxff9lLu9bq2kp671j7In+GmeNJ7ngXOC72fdnvI1G
	Bgid+CZlP+gbTnl9SO6J9IuXzZI5VKUm2XmQvckulNZSUQaYP/EqE9esCtweDvpOKr5R
	YLAPwYoVCetB6bpeM4lls4TNz7DOHmNbEG/ho=
Received: by 10.180.95.105 with SMTP id dj9mr34042674wib.18.1328014601287;
	Tue, 31 Jan 2012 04:56:41 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id bj10sm37141727wib.9.2012.01.31.04.56.40
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 04:56:40 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 31 Jan 2012 12:56:37 +0000
From: Keir Fraser <keir@xen.org>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Jan Beulich <JBeulich@suse.com>
Message-ID: <CB4D9585.3894A%keir@xen.org>
Thread-Topic: [Xen-devel] live migration question
Thread-Index: AczgF8RZiJMY50PghEiCYcQ6AO/CCg==
In-Reply-To: <4F27E1CE.6080100@ts.fujitsu.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 31/01/2012 12:42, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

>> I've made an additional test using xm save/xm restore to see if the same
>> problem shows up. It does NOT. Mapping succeeds at once while restoring
>> memory is still running. I always thought xm restore and live migration on
>> the target machine are more or less the same. This seems not to be true.
> 
> Okay, here are my results (so far):
> 
> do_mmu_update() calls mod_l1_entry() which fails with -EINVAL due to an
> invalid mfn and p2m-type == 4 returned by:
> 
> mfn_x(gfn_to_mfn(pg_dom, l1e_get_pfn(nl1e), &p2mt))
> 
> I still don't see why xc_restore is able to do the mapping while my daemon is
> not. And I can't find any difference between a domain creation due to
> xm restore and a live migration.

Memory pages are populated as they appear in the migration data stream.
Perhaps you are trying to map a guest page that has simply not yet been
allocated.

Bear in mind that IOCTL_PRIVCMD_MMAPBATCH_V2 will note, but proceed past,
failed individual mappings. While IOCTL_PRIVCMD_MMAP, for example, will fail
the entire ioctl() in that situation. There's a reason that xc_restore uses
the former ioctl!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:04:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDNN-0001FZ-3q; Tue, 31 Jan 2012 13:03:57 +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 1RsDNL-0001FI-4L
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:03:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328014968!59128785!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19748 invoked from network); 31 Jan 2012 13:02:48 -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; 31 Jan 2012 13:02:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 13:03:47 +0000
Message-Id: <4F27F4C20200007800070203@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 13:03:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] qemu-dm: unregister_iomem() broken?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This function (introduced quite a long time ago in
e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
devices in HVM domains") appears to be completely broken, causing
the regression reported in
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
the newly added caller of it in
56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
MSI-X table handling"). As it's unclear how the function can ever
have fulfilled its purpose, and as I'm not seeing the log message
resulting from it being called on the sole original call path with SLE11
guests, I'd like to ask you or someone else at Citrix with access to a
suitable guest to double check that the below patch doesn't break it.
Once verified that it fixes the problem at hand *and* doesn't break
what it was supposed to be sued for originally, I'll do a formal
submission.

Thanks, Jan

--- a/i386-dm/exec-dm.c
+++ b/i386-dm/exec-dm.c
@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab
     int io_index = io_table_address >> IO_MEM_SHIFT;
 
     for (i = 0; i < mmio_cnt; i++) {
-	if (mmio[i].size && mmio[i].io_index == io_index) {
+	if (mmio[i].io_index == io_index) {
 	   mmio[i].start = mmio[i].size = 0;
 	   break;
 	}
@@ -466,12 +466,16 @@ static int iomem_index(target_phys_addr_
 
 void unregister_iomem(target_phys_addr_t start)
 {
-    int index = iomem_index(start);
-    if (index) {
+    unsigned int index;
+
+    for (index = 0; index < mmio_cnt; index++)
+        if (start == mmio[index].start)
+            break;
+    if (index < mmio_cnt) {
         fprintf(logfile, "squash iomem [%lx, %lx).\n",
 		(unsigned long)(mmio[index].start),
                 (unsigned long)(mmio[index].start + mmio[index].size));
-        mmio[index].start = mmio[index].size = 0;
+        mmio[index].size = 0;
     }
 }
 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:04:21 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:04:21 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDNN-0001FZ-3q; Tue, 31 Jan 2012 13:03:57 +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 1RsDNL-0001FI-4L
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:03:55 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328014968!59128785!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19748 invoked from network); 31 Jan 2012 13:02:48 -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; 31 Jan 2012 13:02:48 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 13:03:47 +0000
Message-Id: <4F27F4C20200007800070203@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 13:03:46 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Haitao Shan <haitao.shan@intel.com>
Subject: [Xen-devel] qemu-dm: unregister_iomem() broken?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This function (introduced quite a long time ago in
e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
devices in HVM domains") appears to be completely broken, causing
the regression reported in
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
the newly added caller of it in
56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
MSI-X table handling"). As it's unclear how the function can ever
have fulfilled its purpose, and as I'm not seeing the log message
resulting from it being called on the sole original call path with SLE11
guests, I'd like to ask you or someone else at Citrix with access to a
suitable guest to double check that the below patch doesn't break it.
Once verified that it fixes the problem at hand *and* doesn't break
what it was supposed to be sued for originally, I'll do a formal
submission.

Thanks, Jan

--- a/i386-dm/exec-dm.c
+++ b/i386-dm/exec-dm.c
@@ -360,7 +360,7 @@ void cpu_unregister_io_memory(int io_tab
     int io_index = io_table_address >> IO_MEM_SHIFT;
 
     for (i = 0; i < mmio_cnt; i++) {
-	if (mmio[i].size && mmio[i].io_index == io_index) {
+	if (mmio[i].io_index == io_index) {
 	   mmio[i].start = mmio[i].size = 0;
 	   break;
 	}
@@ -466,12 +466,16 @@ static int iomem_index(target_phys_addr_
 
 void unregister_iomem(target_phys_addr_t start)
 {
-    int index = iomem_index(start);
-    if (index) {
+    unsigned int index;
+
+    for (index = 0; index < mmio_cnt; index++)
+        if (start == mmio[index].start)
+            break;
+    if (index < mmio_cnt) {
         fprintf(logfile, "squash iomem [%lx, %lx).\n",
 		(unsigned long)(mmio[index].start),
                 (unsigned long)(mmio[index].start + mmio[index].size));
-        mmio[index].start = mmio[index].size = 0;
+        mmio[index].size = 0;
     }
 }
 





_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:15:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:15:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDXs-0001Rn-9Q; Tue, 31 Jan 2012 13:14:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsDXr-0001Rf-Gu
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:14:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328015680!13323308!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13165 invoked from network); 31 Jan 2012 13:14:41 -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; 31 Jan 2012 13:14:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 13:14:39 +0000
Message-Id: <4F27F74F020000780007020E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 13:14:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <4F27B5AD.9050709@redhat.com>
	<4F27D232020000780007012B@nat28.tlf.novell.com>
	<4F27CAAE.8070602@redhat.com>
In-Reply-To: <4F27CAAE.8070602@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Petr Matousek <pmatouse@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 12:04, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/31/12 11:36, Jan Beulich wrote:
>>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com>  wrote:
> 
>>> Is it justified to kill the emulator when this happens (eg. memory
>>> mapped IO with 64-bit operand)?
> 
>> The AMD manual specifies that REX.W is ignored; the Intel manual
>> doesn't mention REX at all here. However, if a decoder incorrectly
>> decodes the guest instruction, that's a bug there. So imo qemu
>> validly treats this condition as fatal.
> 
>  From the Itanium(R) SDM rev 2.3,
> 
> 10.7.2.1 I/O Port Addressing Restrictions
> 
>      For the 64MB physical I/O port block the following operations are
>      undefined and may result in unpredictable processor operation;
>      references larger than 4-bytes, [...]
> 
> It seems that not only a decoding failure can trigger this.

Oh, yes, I forgot that port I/O goes via MMIO on ia64. So yes, for
that case your observation is correct, though killing qemu-dm in
that case still seems to fall well under "undefined behavior". But
improving the situation wouldn't be bad then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:15:11 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:15:11 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDXs-0001Rn-9Q; Tue, 31 Jan 2012 13:14:48 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <JBeulich@suse.com>) id 1RsDXr-0001Rf-Gu
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:14:47 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-12.tower-216.messagelabs.com!1328015680!13323308!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13165 invoked from network); 31 Jan 2012 13:14:41 -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; 31 Jan 2012 13:14:41 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 13:14:39 +0000
Message-Id: <4F27F74F020000780007020E@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 13:14:39 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Laszlo Ersek" <lersek@redhat.com>
References: <4F27B5AD.9050709@redhat.com>
	<4F27D232020000780007012B@nat28.tlf.novell.com>
	<4F27CAAE.8070602@redhat.com>
In-Reply-To: <4F27CAAE.8070602@redhat.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Miroslav Rezanina <mrezanin@redhat.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Petr Matousek <pmatouse@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Xen-devel] qemu(-dm): aborting on wrong mmio size?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 12:04, Laszlo Ersek <lersek@redhat.com> wrote:
> On 01/31/12 11:36, Jan Beulich wrote:
>>>>> On 31.01.12 at 10:34, Laszlo Ersek<lersek@redhat.com>  wrote:
> 
>>> Is it justified to kill the emulator when this happens (eg. memory
>>> mapped IO with 64-bit operand)?
> 
>> The AMD manual specifies that REX.W is ignored; the Intel manual
>> doesn't mention REX at all here. However, if a decoder incorrectly
>> decodes the guest instruction, that's a bug there. So imo qemu
>> validly treats this condition as fatal.
> 
>  From the Itanium(R) SDM rev 2.3,
> 
> 10.7.2.1 I/O Port Addressing Restrictions
> 
>      For the 64MB physical I/O port block the following operations are
>      undefined and may result in unpredictable processor operation;
>      references larger than 4-bytes, [...]
> 
> It seems that not only a decoding failure can trigger this.

Oh, yes, I forgot that port I/O goes via MMIO on ia64. So yes, for
that case your observation is correct, though killing qemu-dm in
that case still seems to fall well under "undefined behavior". But
improving the situation wouldn't be bad then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:18:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDal-0001Yj-Sz; Tue, 31 Jan 2012 13:17:47 +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 1RsDak-0001YK-F2
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:17:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328015859!12677255!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20497 invoked from network); 31 Jan 2012 13:17:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 13:17:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 13:17:38 +0000
Message-Id: <4F27F8020200007800070211@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 13:17:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<1328009238.27781.87.camel@elijah>
In-Reply-To: <1328009238.27781.87.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 12:27, George Dunlap <george.dunlap@citrix.com> wrote:
> On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote:
>> >>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
>> > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
>> >> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> >> x86's vMCE implementation lets a guest know of as many MCE reporting
>> >> >> banks as there are in the host. While a PV guest could be expected to
>> >> >> deal with this number changing (particularly decreasing) during migration
>> >> >> (not currently handled anywhere afaict), for HVM guests this is certainly
>> >> >> wrong.
>> >> >>
>> >> >> At least to me it isn't, however, clear how to properly handle this. The
>> >> >> easiest would appear to be to save and restore the number of banks
>> >> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
>> >> >> silently tolerate accesses between the host and guest values.
>> >> >
>> >> > We ran into this in the XS 6.0 release as well.  I think that the
>> >> > ideal thing to do would be to have a parameter that can be set at
>> >> > boot, to say how many vMCE banks a guest has, defaulting to the number
>> >> > of MCE banks on the host.  This parameter would be preserved across
>> >> > migration.  Ideally, a pool-aware toolstack like xapi would then set
>> >> > this value to be the value of the host in the pool with the largest
>> >> > number of banks, allowing a guest to access all the banks on any host
>> >> > to which it migrates.
>> >> >
>> >> > What do you think?
>> >>
>> >> That sounds like the way to go.
>> >
>> > So should we put this on IanC's to-do-be-done list?  Are you going to
>> > put it on your to-do list? :-)
>> 
>> Below/attached a draft patch (compile tested only), handling save/
>> restore of the bank count, but not allowing for a config setting to
>> specify its initial value (yet).
> 
> Looks pretty good for a first blush.  Just one question: Why is the vmce
> count made on a per-vcpu basis, rather than on a per-domain basis, like
> the actual banks are?  Is the host MCE stuff per-vcpu?

The question should probably be the other way around - why is the
vMCE implementation using global (fake) MSRs rather than per-vCPU
ones (as they would be on hardware). If the change here was
implemented as per-domain MSRs, a future move of the vMCE
implementation to a more natural model would be impossible. Also,
for the PV case the save/restore logic is much simpler this way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:18:06 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:18:06 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDal-0001Yj-Sz; Tue, 31 Jan 2012 13:17:47 +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 1RsDak-0001YK-F2
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:17:46 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-10.tower-216.messagelabs.com!1328015859!12677255!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20497 invoked from network); 31 Jan 2012 13:17:40 -0000
Received: from nat28.tlf.novell.com (HELO nat28.tlf.novell.com) (130.57.49.28)
	by server-10.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 13:17:40 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 13:17:38 +0000
Message-Id: <4F27F8020200007800070211@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 13:17:38 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "George Dunlap" <george.dunlap@citrix.com>, <George.Dunlap@eu.citrix.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<1328009238.27781.87.camel@elijah>
In-Reply-To: <1328009238.27781.87.camel@elijah>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 12:27, George Dunlap <george.dunlap@citrix.com> wrote:
> On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote:
>> >>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
>> > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
>> >> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
>> >> >> x86's vMCE implementation lets a guest know of as many MCE reporting
>> >> >> banks as there are in the host. While a PV guest could be expected to
>> >> >> deal with this number changing (particularly decreasing) during migration
>> >> >> (not currently handled anywhere afaict), for HVM guests this is certainly
>> >> >> wrong.
>> >> >>
>> >> >> At least to me it isn't, however, clear how to properly handle this. The
>> >> >> easiest would appear to be to save and restore the number of banks
>> >> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
>> >> >> silently tolerate accesses between the host and guest values.
>> >> >
>> >> > We ran into this in the XS 6.0 release as well.  I think that the
>> >> > ideal thing to do would be to have a parameter that can be set at
>> >> > boot, to say how many vMCE banks a guest has, defaulting to the number
>> >> > of MCE banks on the host.  This parameter would be preserved across
>> >> > migration.  Ideally, a pool-aware toolstack like xapi would then set
>> >> > this value to be the value of the host in the pool with the largest
>> >> > number of banks, allowing a guest to access all the banks on any host
>> >> > to which it migrates.
>> >> >
>> >> > What do you think?
>> >>
>> >> That sounds like the way to go.
>> >
>> > So should we put this on IanC's to-do-be-done list?  Are you going to
>> > put it on your to-do list? :-)
>> 
>> Below/attached a draft patch (compile tested only), handling save/
>> restore of the bank count, but not allowing for a config setting to
>> specify its initial value (yet).
> 
> Looks pretty good for a first blush.  Just one question: Why is the vmce
> count made on a per-vcpu basis, rather than on a per-domain basis, like
> the actual banks are?  Is the host MCE stuff per-vcpu?

The question should probably be the other way around - why is the
vMCE implementation using global (fake) MSRs rather than per-vCPU
ones (as they would be on hardware). If the change here was
implemented as per-domain MSRs, a future move of the vMCE
implementation to a more natural model would be impossible. Also,
for the PV case the save/restore logic is much simpler this way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:24:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDhI-0001qo-PO; Tue, 31 Jan 2012 13:24: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 1RsDhG-0001qh-SV
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:24:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328016264!11931173!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12256 invoked from network); 31 Jan 2012 13:24:24 -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; 31 Jan 2012 13:24:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 13:24:23 +0000
Message-Id: <4F27F9960200007800070228@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 13:24:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
	<1328008145.5553.74.camel@leeds.uk.xensource.com>
In-Reply-To: <1328008145.5553.74.camel@leeds.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 12:09, Wei Liu <wei.liu2@citrix.com> wrote:
> On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
>> >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
>> > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
>> >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
>> >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
>> >> > -			      grant_ref_t tx_ring_ref,
>> >> > -			      grant_ref_t rx_ring_ref)
>> >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
>> >> > +			      int domid,
>> >> > +			      unsigned long ring_ref[],
>> >> > +			      unsigned int  ring_ref_count)
>> >> >  {
>> >> > -	void *addr;
>> >> > -	struct xen_netif_tx_sring *txs;
>> >> > -	struct xen_netif_rx_sring *rxs;
>> >> > -
>> >> > -	int err = -ENOMEM;
>> >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
>> >> > +	unsigned int i;
>> >> > +	int err = 0;
>> >> >  
>> >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
>> >> > -				     tx_ring_ref, &addr);
>> >> 
>> >> Any reason why you don't just extend this function (in a prerequisite
>> >> patch) rather than open coding a common utility function (twice) here,
>> >> so that other backends (blkback!) can benefit later as well.
>> >> 
>> >> Jan
>> >> 
>> > 
>> > I'm mainly focusing on netback stuffs, so the code is slightly coupled
>> > with netback -- NETBK_MAX_RING_PAGES.
>> > 
>> > To extend xenbus_map_ring_valloc and make more generic, it requires
>> > setting a global maximum page number limits on rings, I think it will
>> > require further investigation and code refactor -- which I have no time
>> > to attend to at the moment. :-/
>> 
>> Why? You can simply pass in the number of pages, there's no need
>> for a global maximum.
>> 
> 
> I mean the gnttab_map_gran_ref array, it is statically allocated at the
> moment. Of course we can make it dynamically allocated, but why bother
> taking the risk of allocation failure.

There's so many other allocations, why would you worry about this
one.

But of course you can undo what a recent change did, and then
subsequently someone else will have to clean up again after you.
I'm just asking to follow good programming practices and write
re-usable code where potential for re-use is obvious (after all,
multi-page block interface patches have been floating around for
much longer than yours for the net interface).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:24:52 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:24:52 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsDhI-0001qo-PO; Tue, 31 Jan 2012 13:24: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 1RsDhG-0001qh-SV
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:24:31 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328016264!11931173!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12256 invoked from network); 31 Jan 2012 13:24:24 -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; 31 Jan 2012 13:24:24 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 13:24:23 +0000
Message-Id: <4F27F9960200007800070228@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 13:24:22 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Wei Liu" <wei.liu2@citrix.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
	<1328008145.5553.74.camel@leeds.uk.xensource.com>
In-Reply-To: <1328008145.5553.74.camel@leeds.uk.xensource.com>
Mime-Version: 1.0
Content-Disposition: inline
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 12:09, Wei Liu <wei.liu2@citrix.com> wrote:
> On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
>> >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
>> > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
>> >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
>> >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
>> >> > -			      grant_ref_t tx_ring_ref,
>> >> > -			      grant_ref_t rx_ring_ref)
>> >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
>> >> > +			      int domid,
>> >> > +			      unsigned long ring_ref[],
>> >> > +			      unsigned int  ring_ref_count)
>> >> >  {
>> >> > -	void *addr;
>> >> > -	struct xen_netif_tx_sring *txs;
>> >> > -	struct xen_netif_rx_sring *rxs;
>> >> > -
>> >> > -	int err = -ENOMEM;
>> >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
>> >> > +	unsigned int i;
>> >> > +	int err = 0;
>> >> >  
>> >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
>> >> > -				     tx_ring_ref, &addr);
>> >> 
>> >> Any reason why you don't just extend this function (in a prerequisite
>> >> patch) rather than open coding a common utility function (twice) here,
>> >> so that other backends (blkback!) can benefit later as well.
>> >> 
>> >> Jan
>> >> 
>> > 
>> > I'm mainly focusing on netback stuffs, so the code is slightly coupled
>> > with netback -- NETBK_MAX_RING_PAGES.
>> > 
>> > To extend xenbus_map_ring_valloc and make more generic, it requires
>> > setting a global maximum page number limits on rings, I think it will
>> > require further investigation and code refactor -- which I have no time
>> > to attend to at the moment. :-/
>> 
>> Why? You can simply pass in the number of pages, there's no need
>> for a global maximum.
>> 
> 
> I mean the gnttab_map_gran_ref array, it is statically allocated at the
> moment. Of course we can make it dynamically allocated, but why bother
> taking the risk of allocation failure.

There's so many other allocations, why would you worry about this
one.

But of course you can undo what a recent change did, and then
subsequently someone else will have to clean up again after you.
I'm just asking to follow good programming practices and write
re-usable code where potential for re-use is obvious (after all,
multi-page block interface patches have been floating around for
much longer than yours for the net interface).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:33:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13: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 1RsDpB-00022k-Ty; Tue, 31 Jan 2012 13:32:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RsDpA-00022f-Ey
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:32:40 +0000
Received: from [85.158.138.51:12668] by server-8.bemta-3.messagelabs.com id
	38/DF-31878-77DE72F4; Tue, 31 Jan 2012 13:32:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328016757!11391054!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17309 invoked from network); 31 Jan 2012 13:32:38 -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;
	31 Jan 2012 13:32:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10389728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 13:32:37 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 13:32:37 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27F9960200007800070228@nat28.tlf.novell.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
	<1328008145.5553.74.camel@leeds.uk.xensource.com>
	<4F27F9960200007800070228@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 13:32:50 +0000
Message-ID: <1328016770.5553.87.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 13:24 +0000, Jan Beulich wrote:
> >>> On 31.01.12 at 12:09, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
> >> >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> >> >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> >> >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> >> >> > -			      grant_ref_t tx_ring_ref,
> >> >> > -			      grant_ref_t rx_ring_ref)
> >> >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> >> >> > +			      int domid,
> >> >> > +			      unsigned long ring_ref[],
> >> >> > +			      unsigned int  ring_ref_count)
> >> >> >  {
> >> >> > -	void *addr;
> >> >> > -	struct xen_netif_tx_sring *txs;
> >> >> > -	struct xen_netif_rx_sring *rxs;
> >> >> > -
> >> >> > -	int err = -ENOMEM;
> >> >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> >> >> > +	unsigned int i;
> >> >> > +	int err = 0;
> >> >> >  
> >> >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> >> >> > -				     tx_ring_ref, &addr);
> >> >> 
> >> >> Any reason why you don't just extend this function (in a prerequisite
> >> >> patch) rather than open coding a common utility function (twice) here,
> >> >> so that other backends (blkback!) can benefit later as well.
> >> >> 
> >> >> Jan
> >> >> 
> >> > 
> >> > I'm mainly focusing on netback stuffs, so the code is slightly coupled
> >> > with netback -- NETBK_MAX_RING_PAGES.
> >> > 
> >> > To extend xenbus_map_ring_valloc and make more generic, it requires
> >> > setting a global maximum page number limits on rings, I think it will
> >> > require further investigation and code refactor -- which I have no time
> >> > to attend to at the moment. :-/
> >> 
> >> Why? You can simply pass in the number of pages, there's no need
> >> for a global maximum.
> >> 
> > 
> > I mean the gnttab_map_gran_ref array, it is statically allocated at the
> > moment. Of course we can make it dynamically allocated, but why bother
> > taking the risk of allocation failure.
> 
> There's so many other allocations, why would you worry about this
> one.
> 

IMHO, this is not a critical part of the code, so failing this one thus
making all other pieces not workable is very strange.

> But of course you can undo what a recent change did, and then
> subsequently someone else will have to clean up again after you.
> I'm just asking to follow good programming practices and write
> re-usable code where potential for re-use is obvious (after all,
> multi-page block interface patches have been floating around for
> much longer than yours for the net interface).
> 

I understand your concern. If the changes required will not make this
series longer and involves major changes in block interface, I'm happy
to refactor the xenbus interface.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:33:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13: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 1RsDpB-00022k-Ty; Tue, 31 Jan 2012 13:32:41 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <wei.liu2@citrix.com>) id 1RsDpA-00022f-Ey
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:32:40 +0000
Received: from [85.158.138.51:12668] by server-8.bemta-3.messagelabs.com id
	38/DF-31878-77DE72F4; Tue, 31 Jan 2012 13:32:39 +0000
X-Env-Sender: wei.liu2@citrix.com
X-Msg-Ref: server-8.tower-174.messagelabs.com!1328016757!11391054!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17309 invoked from network); 31 Jan 2012 13:32:38 -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;
	31 Jan 2012 13:32:38 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10389728"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 13:32:37 +0000
Received: from [10.80.2.15] (10.80.2.15) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 13:32:37 +0000
From: Wei Liu <wei.liu2@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27F9960200007800070228@nat28.tlf.novell.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
	<1328008145.5553.74.camel@leeds.uk.xensource.com>
	<4F27F9960200007800070228@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 13:32:50 +0000
Message-ID: <1328016770.5553.87.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
X-Mailer: Evolution 2.30.3 
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	wei.liu2@citrix.com, Ian Campbell <Ian.Campbell@citrix.com>,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
 support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 13:24 +0000, Jan Beulich wrote:
> >>> On 31.01.12 at 12:09, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
> >> >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> >> > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> >> >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> >> >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> >> >> > -			      grant_ref_t tx_ring_ref,
> >> >> > -			      grant_ref_t rx_ring_ref)
> >> >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> >> >> > +			      int domid,
> >> >> > +			      unsigned long ring_ref[],
> >> >> > +			      unsigned int  ring_ref_count)
> >> >> >  {
> >> >> > -	void *addr;
> >> >> > -	struct xen_netif_tx_sring *txs;
> >> >> > -	struct xen_netif_rx_sring *rxs;
> >> >> > -
> >> >> > -	int err = -ENOMEM;
> >> >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> >> >> > +	unsigned int i;
> >> >> > +	int err = 0;
> >> >> >  
> >> >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> >> >> > -				     tx_ring_ref, &addr);
> >> >> 
> >> >> Any reason why you don't just extend this function (in a prerequisite
> >> >> patch) rather than open coding a common utility function (twice) here,
> >> >> so that other backends (blkback!) can benefit later as well.
> >> >> 
> >> >> Jan
> >> >> 
> >> > 
> >> > I'm mainly focusing on netback stuffs, so the code is slightly coupled
> >> > with netback -- NETBK_MAX_RING_PAGES.
> >> > 
> >> > To extend xenbus_map_ring_valloc and make more generic, it requires
> >> > setting a global maximum page number limits on rings, I think it will
> >> > require further investigation and code refactor -- which I have no time
> >> > to attend to at the moment. :-/
> >> 
> >> Why? You can simply pass in the number of pages, there's no need
> >> for a global maximum.
> >> 
> > 
> > I mean the gnttab_map_gran_ref array, it is statically allocated at the
> > moment. Of course we can make it dynamically allocated, but why bother
> > taking the risk of allocation failure.
> 
> There's so many other allocations, why would you worry about this
> one.
> 

IMHO, this is not a critical part of the code, so failing this one thus
making all other pieces not workable is very strange.

> But of course you can undo what a recent change did, and then
> subsequently someone else will have to clean up again after you.
> I'm just asking to follow good programming practices and write
> re-usable code where potential for re-use is obvious (after all,
> multi-page block interface patches have been floating around for
> much longer than yours for the net interface).
> 

I understand your concern. If the changes required will not make this
series longer and involves major changes in block interface, I'm happy
to refactor the xenbus interface.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:45:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13: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 1RsE1a-0002D1-7V; Tue, 31 Jan 2012 13:45:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsE1Y-0002Cw-AC
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:45:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328017521!10759622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4268 invoked from network); 31 Jan 2012 13:45:22 -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;
	31 Jan 2012 13:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10390089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 13:45:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 13:45:21 +0000
Date: Tue, 31 Jan 2012 13:47:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120131100605.GB25307@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.00.1201311346190.3196@kaball-desktop>
References: <20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
	<20120131100605.GB25307@ocelot.phlegethon.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Tim Deegan wrote:
> Hi, 
> 
> At 10:57 +0100 on 31 Jan (1328007457), Roger Pau Monn? wrote:
> > That's what I don't get. Booting the driver domain should be no
> > problem, because you can also have a xenbackendd running in the Dom0
> > to boot the driver domain (or maybe you want to use both Dom0 and
> > another DomU as driver domains).
> > 
> > What I don't get is what you do when you have to boot a PV DomU which
> > root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> > the HDD (usually extracted using pygrub). Since the HDD is inside the
> > driver domain, Dom0 doesn't have access to that image, so there's no
> > way to extract the kernel/initrd from the Dom0. What I through is that
> > the driver domain has to run pygrub, extract the kernel/initrd, and
> > pass both files to the Dom0, but how can we pass those files? libvchan
> > seems like the best option, but I would like to head others opinions
> > about this.
> 
> You could attach to the disk image (using blkfront in dom0 and
> blkback/tap/whatever in the driver domain), run pygrub and detach.
> That's basically the same thing you have to do with a qcow image in a
> traditional dom0.

this


> Or you could use pvgrub to boot the domain, so dom0 code never has to
> touch the guets-supplied disk image or kernel.  That seems much better
> to me, but maybe it wouldn't work for some existing deployments?

It wouldn't work with guests that use grub2, I believe.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:45:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13: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 1RsE1a-0002D1-7V; Tue, 31 Jan 2012 13:45:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsE1Y-0002Cw-AC
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:45:28 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328017521!10759622!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4268 invoked from network); 31 Jan 2012 13:45:22 -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;
	31 Jan 2012 13:45:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10390089"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 13:45:21 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 13:45:21 +0000
Date: Tue, 31 Jan 2012 13:47:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Tim Deegan <tim@xen.org>
In-Reply-To: <20120131100605.GB25307@ocelot.phlegethon.org>
Message-ID: <alpine.DEB.2.00.1201311346190.3196@kaball-desktop>
References: <20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
	<20120131100605.GB25307@ocelot.phlegethon.org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Tim Deegan wrote:
> Hi, 
> 
> At 10:57 +0100 on 31 Jan (1328007457), Roger Pau Monn? wrote:
> > That's what I don't get. Booting the driver domain should be no
> > problem, because you can also have a xenbackendd running in the Dom0
> > to boot the driver domain (or maybe you want to use both Dom0 and
> > another DomU as driver domains).
> > 
> > What I don't get is what you do when you have to boot a PV DomU which
> > root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> > the HDD (usually extracted using pygrub). Since the HDD is inside the
> > driver domain, Dom0 doesn't have access to that image, so there's no
> > way to extract the kernel/initrd from the Dom0. What I through is that
> > the driver domain has to run pygrub, extract the kernel/initrd, and
> > pass both files to the Dom0, but how can we pass those files? libvchan
> > seems like the best option, but I would like to head others opinions
> > about this.
> 
> You could attach to the disk image (using blkfront in dom0 and
> blkback/tap/whatever in the driver domain), run pygrub and detach.
> That's basically the same thing you have to do with a qcow image in a
> traditional dom0.

this


> Or you could use pvgrub to boot the domain, so dom0 code never has to
> touch the guets-supplied disk image or kernel.  That seems much better
> to me, but maybe it wouldn't work for some existing deployments?

It wouldn't work with guests that use grub2, I believe.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:50:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsE6F-0002Ph-Uy; Tue, 31 Jan 2012 13:50:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsE6E-0002Pa-62
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:50:18 +0000
Received: from [85.158.138.51:25101] by server-6.bemta-3.messagelabs.com id
	BE/9B-31032-991F72F4; Tue, 31 Jan 2012 13:50:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328017816!11363221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1668 invoked from network); 31 Jan 2012 13:50:16 -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;
	31 Jan 2012 13:50:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10390236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 13:50: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; Tue, 31 Jan 2012 13:50:16 +0000
Date: Tue, 31 Jan 2012 13:51:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201311348060.3196@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-156531201-1328017933=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-156531201-1328017933=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Tue, 31 Jan 2012, Roger Pau Monné wrote:
> That's what I don't get. Booting the driver domain should be no
> problem, because you can also have a xenbackendd running in the Dom0
> to boot the driver domain (or maybe you want to use both Dom0 and
> another DomU as driver domains).
> 
> What I don't get is what you do when you have to boot a PV DomU which
> root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> the HDD (usually extracted using pygrub). Since the HDD is inside the
> driver domain, Dom0 doesn't have access to that image, so there's no
> way to extract the kernel/initrd from the Dom0. What I through is that
> the driver domain has to run pygrub, extract the kernel/initrd, and
> pass both files to the Dom0, but how can we pass those files? libvchan
> seems like the best option, but I would like to head others opinions
> about this.

As Tim said, you would use blkfront in dom0 to get a device you can open
with pygrub.


> Currently I have a mostly working xenbackendd implementation with
> libxl, that can handle vbd and vif interfaces, but I'm missing qdisk,
> I still have to look into the Qemu stuff to be able to launch a device
> model that only attaches a HDD.
 
In case of qdisk, you can use the same blkfront in dom0 trick described
above, or, if the backend and the frontend are both in dom0, you can use
QEMU's nbdserver to export the disk and nbd-client to setup a device
that pygrub can open.
--8323329-156531201-1328017933=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-156531201-1328017933=:3196--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:50:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:50:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsE6F-0002Ph-Uy; Tue, 31 Jan 2012 13:50:19 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsE6E-0002Pa-62
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:50:18 +0000
Received: from [85.158.138.51:25101] by server-6.bemta-3.messagelabs.com id
	BE/9B-31032-991F72F4; Tue, 31 Jan 2012 13:50:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-174.messagelabs.com!1328017816!11363221!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1668 invoked from network); 31 Jan 2012 13:50:16 -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;
	31 Jan 2012 13:50:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10390236"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 13:50: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; Tue, 31 Jan 2012 13:50:16 +0000
Date: Tue, 31 Jan 2012 13:51:58 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@entel.upc.edu>
In-Reply-To: <CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201311348060.3196@kaball-desktop>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-156531201-1328017933=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<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-156531201-1328017933=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Tue, 31 Jan 2012, Roger Pau Monné wrote:
> That's what I don't get. Booting the driver domain should be no
> problem, because you can also have a xenbackendd running in the Dom0
> to boot the driver domain (or maybe you want to use both Dom0 and
> another DomU as driver domains).
> 
> What I don't get is what you do when you have to boot a PV DomU which
> root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> the HDD (usually extracted using pygrub). Since the HDD is inside the
> driver domain, Dom0 doesn't have access to that image, so there's no
> way to extract the kernel/initrd from the Dom0. What I through is that
> the driver domain has to run pygrub, extract the kernel/initrd, and
> pass both files to the Dom0, but how can we pass those files? libvchan
> seems like the best option, but I would like to head others opinions
> about this.

As Tim said, you would use blkfront in dom0 to get a device you can open
with pygrub.


> Currently I have a mostly working xenbackendd implementation with
> libxl, that can handle vbd and vif interfaces, but I'm missing qdisk,
> I still have to look into the Qemu stuff to be able to launch a device
> model that only attaches a HDD.
 
In case of qdisk, you can use the same blkfront in dom0 trick described
above, or, if the backend and the frontend are both in dom0, you can use
QEMU's nbdserver to export the disk and nbd-client to setup a device
that pygrub can open.
--8323329-156531201-1328017933=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-156531201-1328017933=:3196--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:52:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13: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 1RsE7z-0002XI-FV; Tue, 31 Jan 2012 13:52: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 1RsE7y-0002X0-5B
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:52:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328017920!12568089!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28398 invoked from network); 31 Jan 2012 13:52:00 -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;
	31 Jan 2012 13:52:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10390299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 13:51:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 13:51:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 31 Jan 2012 13:51:59 +0000
In-Reply-To: <alpine.DEB.2.00.1201311346190.3196@kaball-desktop>
References: <20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
	<20120131100605.GB25307@ocelot.phlegethon.org>
	<alpine.DEB.2.00.1201311346190.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328017919.26983.383.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 13:47 +0000, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Tim Deegan wrote:
> > Hi, 
> > 
> > At 10:57 +0100 on 31 Jan (1328007457), Roger Pau Monn? wrote:
> > > That's what I don't get. Booting the driver domain should be no
> > > problem, because you can also have a xenbackendd running in the Dom0
> > > to boot the driver domain (or maybe you want to use both Dom0 and
> > > another DomU as driver domains).
> > > 
> > > What I don't get is what you do when you have to boot a PV DomU which
> > > root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> > > the HDD (usually extracted using pygrub). Since the HDD is inside the
> > > driver domain, Dom0 doesn't have access to that image, so there's no
> > > way to extract the kernel/initrd from the Dom0. What I through is that
> > > the driver domain has to run pygrub, extract the kernel/initrd, and
> > > pass both files to the Dom0, but how can we pass those files? libvchan
> > > seems like the best option, but I would like to head others opinions
> > > about this.
> > 
> > You could attach to the disk image (using blkfront in dom0 and
> > blkback/tap/whatever in the driver domain), run pygrub and detach.
> > That's basically the same thing you have to do with a qcow image in a
> > traditional dom0.
> 
> this
> 
> 
> > Or you could use pvgrub to boot the domain, so dom0 code never has to
> > touch the guets-supplied disk image or kernel.  That seems much better
> > to me, but maybe it wouldn't work for some existing deployments?
> 
> It wouldn't work with guests that use grub2, I believe.

One of the grub2 developers posted about working on pv grub2 back in
November...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:52:24 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13: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 1RsE7z-0002XI-FV; Tue, 31 Jan 2012 13:52: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 1RsE7y-0002X0-5B
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:52:06 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328017920!12568089!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28398 invoked from network); 31 Jan 2012 13:52:00 -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;
	31 Jan 2012 13:52:00 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10390299"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 13:51:59 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 13:51:59 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Date: Tue, 31 Jan 2012 13:51:59 +0000
In-Reply-To: <alpine.DEB.2.00.1201311346190.3196@kaball-desktop>
References: <20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
	<20120131100605.GB25307@ocelot.phlegethon.org>
	<alpine.DEB.2.00.1201311346190.3196@kaball-desktop>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328017919.26983.383.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Tim \(Xen.org\)" <tim@xen.org>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 13:47 +0000, Stefano Stabellini wrote:
> On Tue, 31 Jan 2012, Tim Deegan wrote:
> > Hi, 
> > 
> > At 10:57 +0100 on 31 Jan (1328007457), Roger Pau Monn? wrote:
> > > That's what I don't get. Booting the driver domain should be no
> > > problem, because you can also have a xenbackendd running in the Dom0
> > > to boot the driver domain (or maybe you want to use both Dom0 and
> > > another DomU as driver domains).
> > > 
> > > What I don't get is what you do when you have to boot a PV DomU which
> > > root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> > > the HDD (usually extracted using pygrub). Since the HDD is inside the
> > > driver domain, Dom0 doesn't have access to that image, so there's no
> > > way to extract the kernel/initrd from the Dom0. What I through is that
> > > the driver domain has to run pygrub, extract the kernel/initrd, and
> > > pass both files to the Dom0, but how can we pass those files? libvchan
> > > seems like the best option, but I would like to head others opinions
> > > about this.
> > 
> > You could attach to the disk image (using blkfront in dom0 and
> > blkback/tap/whatever in the driver domain), run pygrub and detach.
> > That's basically the same thing you have to do with a qcow image in a
> > traditional dom0.
> 
> this
> 
> 
> > Or you could use pvgrub to boot the domain, so dom0 code never has to
> > touch the guets-supplied disk image or kernel.  That seems much better
> > to me, but maybe it wouldn't work for some existing deployments?
> 
> It wouldn't work with guests that use grub2, I believe.

One of the grub2 developers posted about working on pv grub2 back in
November...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:54:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEA8-0002gr-0m; Tue, 31 Jan 2012 13:54:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RsEA6-0002gi-1w
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:54:18 +0000
Received: from [85.158.138.51:9058] by server-12.bemta-3.messagelabs.com id
	CF/92-24557-982F72F4; Tue, 31 Jan 2012 13:54:17 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328018056!11426426!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NzA3Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25656 invoked from network); 31 Jan 2012 13:54:16 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 13:54:16 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=iive9rWwiu68SUJG0ZMB14uIa9fzoxlVP2JhwD4YQThW+TUMP4Pl5tpP
	m4fe/ukoRjBgiIDJwBdSnCTvsehZsIP77eEr8p559QlnwwB+mfl2PqLHH
	R6QPzexgSHcHNFMgsRmTkQL+wvJgGEkMN7jMmU/pPb2PDzsI2jIlVIcUB
	zHK11taBs4yLmNCIYVABvpIVzo34QMCTJJPYusic45dUmDZ+049JwkBR2
	zSVU2WywTJOVpBYuUbpcRQTFHfb5l;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328018056; x=1359554056;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=scnw7cd1VwAiGlRHXzighNOz5Mc44FWXcsEfucVKa+Y=;
	b=piPDODMOZNdUY0A4aQX3o7BbOHi4cRKqSkiKh2geWpR5wkiw6OecgTff
	PlT+tUd7NJ7JjtTDQyd6XTPLD8CMYlXV2FvwlnvZYNJ06FJ5fGStX48UD
	q2u7xSIXBwOjWfvWcmxWCKxYXpUZcYe4cHgad5hPUHQao7IQzAeQFWfLC
	m6/7vCyrUmW0F2qelyvfDctkJSURPb775XfqkBXLzjNLiueihAPR0FadJ
	LLggzlkoRQdD4LZcapRAIllxp/xse;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="84953921"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 31 Jan 2012 14:54:15 +0100
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="127781409"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 31 Jan 2012 14:54:15 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 22E71960EA6;
	Tue, 31 Jan 2012 14:54:15 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Date: Tue, 31 Jan 2012 14:54:14 +0100
Message-ID: <2409234.cBcKmkEUVD@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2] msr: Use defines for bits of
	MSR_IA32_DEBUGCTLMSR instead of numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes to v1:
  As Jan suggested:
    - changed definitions of the bit fields
    - did the change more consistently across the source.

Dietmar.


# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864

Use defines for bits of MSR_IA32_DEBUGCTLMSR instead of numbers.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r e2722b24dc09 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 31 14:30:32 2012 +0100
@@ -1944,11 +1944,12 @@ static int vmx_msr_write_intercept(unsig
         break;
     case MSR_IA32_DEBUGCTLMSR: {
         int i, rc = 0;
-
-        if ( !msr_content || (msr_content & ~3) )
+        uint64_t supported = IA32_DEBUGCTLMSR_LBR | IA32_DEBUGCTLMSR_BTF;
+
+        if ( !msr_content || (msr_content & ~supported) )
             break;
 
-        if ( msr_content & 1 )
+        if ( msr_content & IA32_DEBUGCTLMSR_LBR )
         {
             const struct lbr_info *lbr = last_branch_msr_get();
             if ( lbr == NULL )
diff -r e2722b24dc09 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/traps.c	Tue Jan 31 14:30:32 2012 +0100
@@ -3376,12 +3376,12 @@ void write_efer(u64 val)
 static void ler_enable(void)
 {
     u64 debugctl;
-    
+
     if ( !this_cpu(ler_msr) )
         return;
 
     rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
-    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | 1);
+    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | IA32_DEBUGCTLMSR_LBR);
 }
 
 void do_debug(struct cpu_user_regs *regs)
diff -r e2722b24dc09 xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/msr-index.h	Tue Jan 31 14:30:32 2012 +0100
@@ -65,11 +65,14 @@
 #define MSR_MTRRdefType			0x000002ff
 
 #define MSR_IA32_DEBUGCTLMSR		0x000001d9
+#define IA32_DEBUGCTLMSR_LBR		(1<<0) /* Last Branch Record */
+#define IA32_DEBUGCTLMSR_BTF		(1<<1) /* Single Step on Branches */
+
 #define MSR_IA32_LASTBRANCHFROMIP	0x000001db
 #define MSR_IA32_LASTBRANCHTOIP		0x000001dc
 #define MSR_IA32_LASTINTFROMIP		0x000001dd
 #define MSR_IA32_LASTINTTOIP		0x000001de
- 
+
 #define MSR_IA32_MTRR_PHYSBASE0     0x00000200
 #define MSR_IA32_MTRR_PHYSMASK0     0x00000201
 #define MSR_IA32_MTRR_PHYSBASE1     0x00000202


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:54:42 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:54:42 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEA8-0002gr-0m; Tue, 31 Jan 2012 13:54:20 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <dietmar.hahn@ts.fujitsu.com>) id 1RsEA6-0002gi-1w
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:54:18 +0000
Received: from [85.158.138.51:9058] by server-12.bemta-3.messagelabs.com id
	CF/92-24557-982F72F4; Tue, 31 Jan 2012 13:54:17 +0000
X-Env-Sender: dietmar.hahn@ts.fujitsu.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328018056!11426426!1
X-Originating-IP: [80.70.172.51]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjUxID0+IDE1NzA3Ng==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25656 invoked from network); 31 Jan 2012 13:54:16 -0000
Received: from dgate20.ts.fujitsu.com (HELO dgate20.ts.fujitsu.com)
	(80.70.172.51)
	by server-11.tower-174.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 13:54:16 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:From:To:Subject:Date:Message-ID:
	User-Agent:MIME-Version:Content-Transfer-Encoding:
	Content-Type;
	b=iive9rWwiu68SUJG0ZMB14uIa9fzoxlVP2JhwD4YQThW+TUMP4Pl5tpP
	m4fe/ukoRjBgiIDJwBdSnCTvsehZsIP77eEr8p559QlnwwB+mfl2PqLHH
	R6QPzexgSHcHNFMgsRmTkQL+wvJgGEkMN7jMmU/pPb2PDzsI2jIlVIcUB
	zHK11taBs4yLmNCIYVABvpIVzo34QMCTJJPYusic45dUmDZ+049JwkBR2
	zSVU2WywTJOVpBYuUbpcRQTFHfb5l;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
	d=ts.fujitsu.com; i=dietmar.hahn@ts.fujitsu.com;
	q=dns/txt; s=s1536b; t=1328018056; x=1359554056;
	h=from:to:subject:date:message-id:mime-version:
	content-transfer-encoding;
	bh=scnw7cd1VwAiGlRHXzighNOz5Mc44FWXcsEfucVKa+Y=;
	b=piPDODMOZNdUY0A4aQX3o7BbOHi4cRKqSkiKh2geWpR5wkiw6OecgTff
	PlT+tUd7NJ7JjtTDQyd6XTPLD8CMYlXV2FvwlnvZYNJ06FJ5fGStX48UD
	q2u7xSIXBwOjWfvWcmxWCKxYXpUZcYe4cHgad5hPUHQao7IQzAeQFWfLC
	m6/7vCyrUmW0F2qelyvfDctkJSURPb775XfqkBXLzjNLiueihAPR0FadJ
	LLggzlkoRQdD4LZcapRAIllxp/xse;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="84953921"
Received: from abgdgate30u.abg.fsc.net ([172.25.138.66])
	by dgate20u.abg.fsc.net with ESMTP; 31 Jan 2012 14:54:15 +0100
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="127781409"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate30u.abg.fsc.net with ESMTP; 31 Jan 2012 14:54:15 +0100
Received: from amur.localnet (amur.mch.fsc.net [172.25.53.126])
	by sanpedro.mch.fsc.net (Postfix) with SMTP id 22E71960EA6;
	Tue, 31 Jan 2012 14:54:15 +0100 (CET)
From: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Date: Tue, 31 Jan 2012 14:54:14 +0100
Message-ID: <2409234.cBcKmkEUVD@amur>
User-Agent: KMail/4.7.2 (Linux/3.1.9-1.4-xen; KDE/4.7.2; x86_64; ; )
MIME-Version: 1.0
Subject: [Xen-devel] [PATCH v2] msr: Use defines for bits of
	MSR_IA32_DEBUGCTLMSR instead of numbers
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Changes to v1:
  As Jan suggested:
    - changed definitions of the bit fields
    - did the change more consistently across the source.

Dietmar.


# HG changeset patch
# Parent e2722b24dc0962de37215320b05d1bb7c4c42864

Use defines for bits of MSR_IA32_DEBUGCTLMSR instead of numbers.

Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>

diff -r e2722b24dc09 xen/arch/x86/hvm/vmx/vmx.c
--- a/xen/arch/x86/hvm/vmx/vmx.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/vmx/vmx.c	Tue Jan 31 14:30:32 2012 +0100
@@ -1944,11 +1944,12 @@ static int vmx_msr_write_intercept(unsig
         break;
     case MSR_IA32_DEBUGCTLMSR: {
         int i, rc = 0;
-
-        if ( !msr_content || (msr_content & ~3) )
+        uint64_t supported = IA32_DEBUGCTLMSR_LBR | IA32_DEBUGCTLMSR_BTF;
+
+        if ( !msr_content || (msr_content & ~supported) )
             break;
 
-        if ( msr_content & 1 )
+        if ( msr_content & IA32_DEBUGCTLMSR_LBR )
         {
             const struct lbr_info *lbr = last_branch_msr_get();
             if ( lbr == NULL )
diff -r e2722b24dc09 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/traps.c	Tue Jan 31 14:30:32 2012 +0100
@@ -3376,12 +3376,12 @@ void write_efer(u64 val)
 static void ler_enable(void)
 {
     u64 debugctl;
-    
+
     if ( !this_cpu(ler_msr) )
         return;
 
     rdmsrl(MSR_IA32_DEBUGCTLMSR, debugctl);
-    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | 1);
+    wrmsrl(MSR_IA32_DEBUGCTLMSR, debugctl | IA32_DEBUGCTLMSR_LBR);
 }
 
 void do_debug(struct cpu_user_regs *regs)
diff -r e2722b24dc09 xen/include/asm-x86/msr-index.h
--- a/xen/include/asm-x86/msr-index.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/msr-index.h	Tue Jan 31 14:30:32 2012 +0100
@@ -65,11 +65,14 @@
 #define MSR_MTRRdefType			0x000002ff
 
 #define MSR_IA32_DEBUGCTLMSR		0x000001d9
+#define IA32_DEBUGCTLMSR_LBR		(1<<0) /* Last Branch Record */
+#define IA32_DEBUGCTLMSR_BTF		(1<<1) /* Single Step on Branches */
+
 #define MSR_IA32_LASTBRANCHFROMIP	0x000001db
 #define MSR_IA32_LASTBRANCHTOIP		0x000001dc
 #define MSR_IA32_LASTINTFROMIP		0x000001dd
 #define MSR_IA32_LASTINTTOIP		0x000001de
- 
+
 #define MSR_IA32_MTRR_PHYSBASE0     0x00000200
 #define MSR_IA32_MTRR_PHYSMASK0     0x00000201
 #define MSR_IA32_MTRR_PHYSBASE1     0x00000202


-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 13:59:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:59:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEEc-0002uw-PG; Tue, 31 Jan 2012 13:58:58 +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 1RsEEa-0002up-Ot
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:58:56 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328018204!50772838!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNjI2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11751 invoked from network); 31 Jan 2012 13:56:45 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 13:56:45 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=HFSX8b2POeChUgq9ynRtOsNVtoUrgAJjSfZ0zXF2YYqrS/0j3cgpCmCz
	KkACz5UQlOBypb6jerbeFSqOSgB5Rk8w96dw4Vs+9WaOymksjak2dWiEF
	VCGBaqvw1/UbrNkyASgtEnjDqOIXdOrgPd3qSlB1KfnKdOJuXtUhdOCA3
	lj4pS3JQ9PiKblF2brqaYmXUshfCpX3cAZM9VRg0nEzOtVDB3Yu5V3rb7
	lZdKfGra/aNPAbZPBXCa8UZukQ6rj;
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=1328018336; x=1359554336;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=WGzbqRunM8jGQVyI263RHLqnk0OB9bjn5RCPB2t65gI=;
	b=QZnJ2yYe2qqNFLQYV9HbkoZrZcgw0N3l02mUc/Yu6TVQKmMZcJ7ZXzaE
	y639rVzb4FFaAOIA8wOj93SNkoc8LPzX4Nrr4A3qBJPwBZkY/4J19o4ph
	YEF0fjzV8dCQB23hkRtRFjawdHO6vCTuF4gMSf6FB6LqdO5ej202WD1ax
	TZEAsRgGfYGaNppjwldD7P5+cNSZ//Se48kBPDbcYVt7ijZMzQFIFb0Jd
	cZfOmAK+Lh6NW9uv9vxFlsFN7+KlO;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,596,1320620400"; d="scan'208";a="100238657"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 31 Jan 2012 14:58:55 +0100
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="128060157"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 31 Jan 2012 14:58:55 +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 1F7BC960F10;
	Tue, 31 Jan 2012 14:58:55 +0100 (CET)
Message-ID: <4F27F39F.2030904@ts.fujitsu.com>
Date: Tue, 31 Jan 2012 14:58:55 +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: Keir Fraser <keir@xen.org>
References: <CB4D9585.3894A%keir@xen.org>
In-Reply-To: <CB4D9585.3894A%keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/2012 01:56 PM, Keir Fraser wrote:
> On 31/01/2012 12:42, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  wrote:
>
>>> I've made an additional test using xm save/xm restore to see if the same
>>> problem shows up. It does NOT. Mapping succeeds at once while restoring
>>> memory is still running. I always thought xm restore and live migration on
>>> the target machine are more or less the same. This seems not to be true.
>> Okay, here are my results (so far):
>>
>> do_mmu_update() calls mod_l1_entry() which fails with -EINVAL due to an
>> invalid mfn and p2m-type == 4 returned by:
>>
>> mfn_x(gfn_to_mfn(pg_dom, l1e_get_pfn(nl1e),&p2mt))
>>
>> I still don't see why xc_restore is able to do the mapping while my daemon is
>> not. And I can't find any difference between a domain creation due to
>> xm restore and a live migration.
> Memory pages are populated as they appear in the migration data stream.
> Perhaps you are trying to map a guest page that has simply not yet been
> allocated.

As far as I can tell, memory is transferred from low to high mfns. The first
iteration takes about 12 minutes in my test case. Why is the mapping possible
only after the last iteration has finished? The mfn I try to map is in the
first 16 MB of the domain, so it should arrive in the first second!

> Bear in mind that IOCTL_PRIVCMD_MMAPBATCH_V2 will note, but proceed past,
> failed individual mappings. While IOCTL_PRIVCMD_MMAP, for example, will fail
> the entire ioctl() in that situation. There's a reason that xc_restore uses
> the former ioctl!

I understand that. But what is the difference between xm restore and live
migration? Somehow the memory seems to be treated different.


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 Jan 31 13:59:17 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 13:59:17 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEEc-0002uw-PG; Tue, 31 Jan 2012 13:58:58 +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 1RsEEa-0002up-Ot
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 13:58:56 +0000
X-Env-Sender: juergen.gross@ts.fujitsu.com
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328018204!50772838!1
X-Originating-IP: [80.70.172.49]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogODAuNzAuMTcyLjQ5ID0+IDIxNjI2Nw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11751 invoked from network); 31 Jan 2012 13:56:45 -0000
Received: from dgate10.ts.fujitsu.com (HELO dgate10.ts.fujitsu.com)
	(80.70.172.49)
	by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 13:56:45 -0000
DomainKey-Signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns;
	h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV:
	Received:Received:Message-ID:Date:From:Organization:
	User-Agent:MIME-Version:To:CC:Subject:References:
	In-Reply-To:Content-Type:Content-Transfer-Encoding;
	b=HFSX8b2POeChUgq9ynRtOsNVtoUrgAJjSfZ0zXF2YYqrS/0j3cgpCmCz
	KkACz5UQlOBypb6jerbeFSqOSgB5Rk8w96dw4Vs+9WaOymksjak2dWiEF
	VCGBaqvw1/UbrNkyASgtEnjDqOIXdOrgPd3qSlB1KfnKdOJuXtUhdOCA3
	lj4pS3JQ9PiKblF2brqaYmXUshfCpX3cAZM9VRg0nEzOtVDB3Yu5V3rb7
	lZdKfGra/aNPAbZPBXCa8UZukQ6rj;
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=1328018336; x=1359554336;
	h=message-id:date:from:mime-version:to:cc:subject:
	references:in-reply-to:content-transfer-encoding;
	bh=WGzbqRunM8jGQVyI263RHLqnk0OB9bjn5RCPB2t65gI=;
	b=QZnJ2yYe2qqNFLQYV9HbkoZrZcgw0N3l02mUc/Yu6TVQKmMZcJ7ZXzaE
	y639rVzb4FFaAOIA8wOj93SNkoc8LPzX4Nrr4A3qBJPwBZkY/4J19o4ph
	YEF0fjzV8dCQB23hkRtRFjawdHO6vCTuF4gMSf6FB6LqdO5ej202WD1ax
	TZEAsRgGfYGaNppjwldD7P5+cNSZ//Se48kBPDbcYVt7ijZMzQFIFb0Jd
	cZfOmAK+Lh6NW9uv9vxFlsFN7+KlO;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.71,596,1320620400"; d="scan'208";a="100238657"
Received: from abgdgate40u.abg.fsc.net ([172.25.138.90])
	by dgate10u.abg.fsc.net with ESMTP; 31 Jan 2012 14:58:55 +0100
X-IronPort-AV: E=Sophos;i="4.71,595,1320620400"; d="scan'208";a="128060157"
Received: from sanpedro.mch.fsc.net ([172.17.20.6])
	by abgdgate40u.abg.fsc.net with ESMTP; 31 Jan 2012 14:58:55 +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 1F7BC960F10;
	Tue, 31 Jan 2012 14:58:55 +0100 (CET)
Message-ID: <4F27F39F.2030904@ts.fujitsu.com>
Date: Tue, 31 Jan 2012 14:58:55 +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: Keir Fraser <keir@xen.org>
References: <CB4D9585.3894A%keir@xen.org>
In-Reply-To: <CB4D9585.3894A%keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 01/31/2012 01:56 PM, Keir Fraser wrote:
> On 31/01/2012 12:42, "Juergen Gross"<juergen.gross@ts.fujitsu.com>  wrote:
>
>>> I've made an additional test using xm save/xm restore to see if the same
>>> problem shows up. It does NOT. Mapping succeeds at once while restoring
>>> memory is still running. I always thought xm restore and live migration on
>>> the target machine are more or less the same. This seems not to be true.
>> Okay, here are my results (so far):
>>
>> do_mmu_update() calls mod_l1_entry() which fails with -EINVAL due to an
>> invalid mfn and p2m-type == 4 returned by:
>>
>> mfn_x(gfn_to_mfn(pg_dom, l1e_get_pfn(nl1e),&p2mt))
>>
>> I still don't see why xc_restore is able to do the mapping while my daemon is
>> not. And I can't find any difference between a domain creation due to
>> xm restore and a live migration.
> Memory pages are populated as they appear in the migration data stream.
> Perhaps you are trying to map a guest page that has simply not yet been
> allocated.

As far as I can tell, memory is transferred from low to high mfns. The first
iteration takes about 12 minutes in my test case. Why is the mapping possible
only after the last iteration has finished? The mfn I try to map is in the
first 16 MB of the domain, so it should arrive in the first second!

> Bear in mind that IOCTL_PRIVCMD_MMAPBATCH_V2 will note, but proceed past,
> failed individual mappings. While IOCTL_PRIVCMD_MMAP, for example, will fail
> the entire ioctl() in that situation. There's a reason that xc_restore uses
> the former ioctl!

I understand that. But what is the difference between xm restore and live
migration? Somehow the memory seems to be treated different.


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 Jan 31 14:04:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEJU-0003A7-Ms; Tue, 31 Jan 2012 14:04:00 +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 1RsEJT-00039v-ES
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:03:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328018633!11938721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31875 invoked from network); 31 Jan 2012 14:03:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:03:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10390823"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:03:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 14:03:34 +0000
Date: Tue, 31 Jan 2012 14:05:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27F4C20200007800070203@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201311357520.3196@kaball-desktop>
References: <4F27F4C20200007800070203@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] qemu-dm: unregister_iomem() broken?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Jan Beulich wrote:
> This function (introduced quite a long time ago in
> e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
> devices in HVM domains") appears to be completely broken, causing
> the regression reported in
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
> the newly added caller of it in
> 56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
> MSI-X table handling"). As it's unclear how the function can ever
> have fulfilled its purpose, and as I'm not seeing the log message
> resulting from it being called on the sole original call path with SLE11
> guests, I'd like to ask you or someone else at Citrix with access to a
> suitable guest to double check that the below patch doesn't break it.

Any upstream Linux kernel with PVHVM would work as a testcase.
Just make sure you have CONFIG_XEN_PVHVM=y and the appropriate frontends
in the kernel config.


> Once verified that it fixes the problem at hand *and* doesn't break
> what it was supposed to be sued for originally, I'll do a formal
> submission.

I have run a smoke test, here is the interesting part of the logs
without this patch:


region type 0 at [f3000000,f3020000).
squash iomem [f3020000, f3021000).
region type 1 at [c100,c140).


and now with this patch:


region type 0 at [f3000000,f3020000).
squash iomem [f3000000, f3020000).
region type 1 at [c100,c140).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:04:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEJU-0003A7-Ms; Tue, 31 Jan 2012 14:04:00 +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 1RsEJT-00039v-ES
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:03:59 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328018633!11938721!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31875 invoked from network); 31 Jan 2012 14:03:53 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:03:53 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10390823"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:03:34 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 14:03:34 +0000
Date: Tue, 31 Jan 2012 14:05:15 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27F4C20200007800070203@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201311357520.3196@kaball-desktop>
References: <4F27F4C20200007800070203@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] qemu-dm: unregister_iomem() broken?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Jan Beulich wrote:
> This function (introduced quite a long time ago in
> e7911109f4321e9ba0cc56a253b653600aa46bea - "disable qemu PCI
> devices in HVM domains") appears to be completely broken, causing
> the regression reported in
> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1805 (due to
> the newly added caller of it in
> 56d7747a3cf811910c4cf865e1ebcb8b82502005 - "qemu: clean up
> MSI-X table handling"). As it's unclear how the function can ever
> have fulfilled its purpose, and as I'm not seeing the log message
> resulting from it being called on the sole original call path with SLE11
> guests, I'd like to ask you or someone else at Citrix with access to a
> suitable guest to double check that the below patch doesn't break it.

Any upstream Linux kernel with PVHVM would work as a testcase.
Just make sure you have CONFIG_XEN_PVHVM=y and the appropriate frontends
in the kernel config.


> Once verified that it fixes the problem at hand *and* doesn't break
> what it was supposed to be sued for originally, I'll do a formal
> submission.

I have run a smoke test, here is the interesting part of the logs
without this patch:


region type 0 at [f3000000,f3020000).
squash iomem [f3020000, f3021000).
region type 1 at [c100,c140).


and now with this patch:


region type 0 at [f3000000,f3020000).
squash iomem [f3000000, f3020000).
region type 1 at [c100,c140).

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEYm-0003Q7-8P; Tue, 31 Jan 2012 14:19:48 +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 1RsEYk-0003Pz-SR
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:19:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328019580!11941653!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25364 invoked from network); 31 Jan 2012 14:19:40 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:19:40 -0000
Received: by werb14 with SMTP id b14so84993wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 06:19:40 -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=NBErODtW3J2BX6HZCU/Wz2hClwt3v2wiOgdBfH1TTW0=;
	b=lEUTbF9LTJxaWk8CQ786phc9jz0fL6VnPQbaJ6KEuX0gkZgMJAoKyVA4oOlovmgrmg
	R1JF3It2ft+Rq8QMSQM7gdIfQqurVEXJMGE53zUUmSfY8Cpjuier+rB3WyX+AVCKwtHu
	fhQMlNimtgiipOrlJhcBTXCXxo2VpSi6+dTJ8=
Received: by 10.216.135.169 with SMTP id u41mr3098345wei.13.1328019465633;
	Tue, 31 Jan 2012 06:17:45 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id d9sm37642915wiy.2.2012.01.31.06.17.42
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 06:17:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 31 Jan 2012 14:17:38 +0000
From: Keir Fraser <keir@xen.org>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Message-ID: <CB4DA882.3896E%keir@xen.org>
Thread-Topic: [Xen-devel] live migration question
Thread-Index: AczgIxW7CEIqnkIG+U2xhp9goqOlNw==
In-Reply-To: <4F27F39F.2030904@ts.fujitsu.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 31/01/2012 13:58, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

>>> I still don't see why xc_restore is able to do the mapping while my daemon
>>> is
>>> not. And I can't find any difference between a domain creation due to
>>> xm restore and a live migration.
>> Memory pages are populated as they appear in the migration data stream.
>> Perhaps you are trying to map a guest page that has simply not yet been
>> allocated.
> 
> As far as I can tell, memory is transferred from low to high mfns. The first
> iteration takes about 12 minutes in my test case. Why is the mapping possible
> only after the last iteration has finished? The mfn I try to map is in the
> first 16 MB of the domain, so it should arrive in the first second!

It's pointless to speculate further until you add some hypervisor tracing to
determine when your guest pfn of interest is actually allocated.

>> Bear in mind that IOCTL_PRIVCMD_MMAPBATCH_V2 will note, but proceed past,
>> failed individual mappings. While IOCTL_PRIVCMD_MMAP, for example, will fail
>> the entire ioctl() in that situation. There's a reason that xc_restore uses
>> the former ioctl!
> 
> I understand that. But what is the difference between xm restore and live
> migration? Somehow the memory seems to be treated different.

As you already noted, they are almost identical, however they are driven by
the stream of memory data they are provided from the original VM. The
ordering of pages used to be randomised in xc_domain_save in the live
migration case.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:20:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:20:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEYm-0003Q7-8P; Tue, 31 Jan 2012 14:19:48 +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 1RsEYk-0003Pz-SR
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:19:47 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328019580!11941653!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25364 invoked from network); 31 Jan 2012 14:19:40 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-13.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:19:40 -0000
Received: by werb14 with SMTP id b14so84993wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 06:19:40 -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=NBErODtW3J2BX6HZCU/Wz2hClwt3v2wiOgdBfH1TTW0=;
	b=lEUTbF9LTJxaWk8CQ786phc9jz0fL6VnPQbaJ6KEuX0gkZgMJAoKyVA4oOlovmgrmg
	R1JF3It2ft+Rq8QMSQM7gdIfQqurVEXJMGE53zUUmSfY8Cpjuier+rB3WyX+AVCKwtHu
	fhQMlNimtgiipOrlJhcBTXCXxo2VpSi6+dTJ8=
Received: by 10.216.135.169 with SMTP id u41mr3098345wei.13.1328019465633;
	Tue, 31 Jan 2012 06:17:45 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id d9sm37642915wiy.2.2012.01.31.06.17.42
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 06:17:45 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 31 Jan 2012 14:17:38 +0000
From: Keir Fraser <keir@xen.org>
To: Juergen Gross <juergen.gross@ts.fujitsu.com>
Message-ID: <CB4DA882.3896E%keir@xen.org>
Thread-Topic: [Xen-devel] live migration question
Thread-Index: AczgIxW7CEIqnkIG+U2xhp9goqOlNw==
In-Reply-To: <4F27F39F.2030904@ts.fujitsu.com>
Mime-version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] live migration question
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 31/01/2012 13:58, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

>>> I still don't see why xc_restore is able to do the mapping while my daemon
>>> is
>>> not. And I can't find any difference between a domain creation due to
>>> xm restore and a live migration.
>> Memory pages are populated as they appear in the migration data stream.
>> Perhaps you are trying to map a guest page that has simply not yet been
>> allocated.
> 
> As far as I can tell, memory is transferred from low to high mfns. The first
> iteration takes about 12 minutes in my test case. Why is the mapping possible
> only after the last iteration has finished? The mfn I try to map is in the
> first 16 MB of the domain, so it should arrive in the first second!

It's pointless to speculate further until you add some hypervisor tracing to
determine when your guest pfn of interest is actually allocated.

>> Bear in mind that IOCTL_PRIVCMD_MMAPBATCH_V2 will note, but proceed past,
>> failed individual mappings. While IOCTL_PRIVCMD_MMAP, for example, will fail
>> the entire ioctl() in that situation. There's a reason that xc_restore uses
>> the former ioctl!
> 
> I understand that. But what is the difference between xm restore and live
> migration? Somehow the memory seems to be treated different.

As you already noted, they are almost identical, however they are driven by
the stream of memory data they are provided from the original VM. The
ordering of pages used to be randomised in xc_domain_save in the live
migration case.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:23:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEbp-0003Yl-SC; Tue, 31 Jan 2012 14:22:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsEbo-0003YT-8Z
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:22:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328019769!12806982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29133 invoked from network); 31 Jan 2012 14:22:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:22:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10391708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:21: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;
	Tue, 31 Jan 2012 14:21:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 31 Jan 2012 14:21:45 +0000
In-Reply-To: <20258.59550.374377.953444@mariner.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
	<20258.59550.374377.953444@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328019706.26983.395.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 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 18:10 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> > libxl: expose cpu topology as a single list of cpu->{node,core,socket} maps.
> > 
> > Rather than the previous tripple list which is more complicated to work with
> > and harder for language bindings.
> 

> > +    for (cpu = 0; cpu < nr; cpu++) {
> ...
> > +        libxl_cputopology_dispose(&topology[cpu]);
> >      }
> >  
> > -    libxl_topologyinfo_dispose(&topology);
> > -
> > +    free(topology);
> 
> This is quite ugly to have out here in the caller.  Perhaps we should
> provide a helper for this, called libxl_cputopology_free or
> something ?
> 
> > -    libxl_topologyinfo_dispose(&topology);
> > +    for (cpu = 0; cpu < nr_cpus; cpu++)
> > +        libxl_cputopology_dispose(&topology[cpu]);
> > +    free(topology);
> 
> And here it is again, proving my point :-).

I added libxl_cputopology_list_free(libxl_cputopology *, int nr)
which disposes all elements of the list and frees the underlying
storage. Is that what you meant?

I don't like "list" rather than "array" but we use the terminology that
way elsewhere too (e.g. libxl_device_FOO_list, so I suppose it is my own
fault)

> > +#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY ~0
> ...
> > +libxl_cputopology = Struct("cputopology", [
> > +    ("core", uint32),
> > +    ("socket", uint32),
> > +    ("node", uint32),
> 
> You mean (~(uint32_t)0) I think.  The outer ( ) should be included too!

Done.

Updated patch below:

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328015490 0
# Node ID f8fbad48472b54e8055a861af0be6c9455e3d160
# Parent  1ab41d14959e9e378ca0ca80603524d1f8a05478
libxl: expose cpu topology as a single list of cpu->{node,core,socket} maps.

Rather than the previous tripple list which is more complicated to work with
and harder for language bindings.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/gentest.py	Tue Jan 31 13:11:30 2012 +0000
@@ -195,6 +195,7 @@ static void libxl_string_list_rand_init(
     *p = l;
 }
 
+#if 0 /* To be remove in a subsequent patch */
 static void libxl_cpuarray_rand_init(libxl_cpuarray *p)
 {
     int i;
@@ -209,6 +210,7 @@ static void libxl_cpuarray_rand_init(lib
             p->array[i] = r;
     }
 }
+#endif
 """)
     for ty in builtins + types:
         if ty.typename not in handcoded:
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Jan 31 13:11:30 2012 +0000
@@ -2755,57 +2755,68 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
+    libxl_cputopology *ret = NULL;
     int i;
-    int rc = 0;
-
-    rc += libxl_cpuarray_alloc(ctx, &info->coremap);
-    rc += libxl_cpuarray_alloc(ctx, &info->socketmap);
-    rc += libxl_cpuarray_alloc(ctx, &info->nodemap);
-    if (rc)
+    int max_cpus;
+
+    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus == 0)
+    {
+        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
+        return NULL;
+    }
+
+    coremap = xc_hypercall_buffer_alloc
+        (ctx->xch, coremap, sizeof(*coremap) * max_cpus);
+    socketmap = xc_hypercall_buffer_alloc
+        (ctx->xch, socketmap, sizeof(*socketmap) * max_cpus);
+    nodemap = xc_hypercall_buffer_alloc
+        (ctx->xch, nodemap, sizeof(*nodemap) * max_cpus);
+    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL)) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate hypercall arguments");
         goto fail;
-
-    coremap = xc_hypercall_buffer_alloc(ctx->xch, coremap, sizeof(*coremap) * info->coremap.entries);
-    socketmap = xc_hypercall_buffer_alloc(ctx->xch, socketmap, sizeof(*socketmap) * info->socketmap.entries);
-    nodemap = xc_hypercall_buffer_alloc(ctx->xch, nodemap, sizeof(*nodemap) * info->nodemap.entries);
-    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL))
-        goto fail;
+    }
 
     set_xen_guest_handle(tinfo.cpu_to_core, coremap);
     set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
     set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
-    tinfo.max_cpu_index = info->coremap.entries - 1;
-    if (xc_topologyinfo(ctx->xch, &tinfo) != 0)
+    tinfo.max_cpu_index = max_cpus - 1;
+    if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
+        LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
         goto fail;
-
-    for (i = 0; i <= tinfo.max_cpu_index; i++) {
-        if (i < info->coremap.entries)
-            info->coremap.array[i] = (coremap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : coremap[i];
-        if (i < info->socketmap.entries)
-            info->socketmap.array[i] = (socketmap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : socketmap[i];
-        if (i < info->nodemap.entries)
-            info->nodemap.array[i] = (nodemap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : nodemap[i];
     }
 
-    xc_hypercall_buffer_free(ctx->xch, coremap);
-    xc_hypercall_buffer_free(ctx->xch, socketmap);
-    xc_hypercall_buffer_free(ctx->xch, nodemap);
-    return 0;
+    ret = malloc(sizeof(libxl_cputopology) * max_cpus);
+    if (ret == NULL) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate return value");
+        goto fail;
+    }
+
+    for (i = 0; i <= max_cpus; i++) {
+#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \
+    LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i]
+        ret[i].core = V(coremap, i);
+        ret[i].socket = V(socketmap, i);
+        ret[i].node = V(nodemap, i);
+#undef V
+    }
 
 fail:
     xc_hypercall_buffer_free(ctx->xch, coremap);
     xc_hypercall_buffer_free(ctx->xch, socketmap);
     xc_hypercall_buffer_free(ctx->xch, nodemap);
-    libxl_topologyinfo_dispose(info);
-    return ERROR_FAIL;
+
+    if (ret)
+        *nr = max_cpus;
+    return ret;
 }
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
@@ -3604,30 +3615,30 @@ int libxl_cpupool_cpuadd(libxl_ctx *ctx,
 int libxl_cpupool_cpuadd_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus)
 {
     int rc = 0;
-    int cpu;
+    int cpu, nr;
     libxl_cpumap freemap;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         return ERROR_FAIL;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &nr);
+    if (!topology) {
         rc = ERROR_FAIL;
         goto out;
     }
 
     *cpus = 0;
-    for (cpu = 0; cpu < topology.nodemap.entries; cpu++) {
-        if (libxl_cpumap_test(&freemap, cpu) &&
-            (topology.nodemap.array[cpu] == node) &&
+    for (cpu = 0; cpu < nr; cpu++) {
+        if (libxl_cpumap_test(&freemap, cpu) && (topology[cpu].node == node) &&
             !libxl_cpupool_cpuadd(ctx, poolid, cpu)) {
                 (*cpus)++;
         }
+        libxl_cputopology_dispose(&topology[cpu]);
     }
 
-    libxl_topologyinfo_dispose(&topology);
-
+    free(topology);
 out:
     libxl_cpumap_dispose(&freemap);
     return rc;
@@ -3651,8 +3662,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
     int ret = 0;
     int n_pools;
     int p;
-    int cpu;
-    libxl_topologyinfo topology;
+    int cpu, nr_cpus;
+    libxl_cputopology *topology;
     libxl_cpupoolinfo *poolinfo;
 
     poolinfo = libxl_list_cpupool(ctx, &n_pools);
@@ -3660,7 +3671,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
         return ERROR_NOMEM;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (!topology) {
         ret = ERROR_FAIL;
         goto out;
     }
@@ -3668,8 +3680,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
     *cpus = 0;
     for (p = 0; p < n_pools; p++) {
         if (poolinfo[p].poolid == poolid) {
-            for (cpu = 0; cpu < topology.nodemap.entries; cpu++) {
-                if ((topology.nodemap.array[cpu] == node) &&
+            for (cpu = 0; cpu < nr_cpus; cpu++) {
+                if ((topology[cpu].node == node) &&
                     libxl_cpumap_test(&poolinfo[p].cpumap, cpu) &&
                     !libxl_cpupool_cpuremove(ctx, poolid, cpu)) {
                         (*cpus)++;
@@ -3678,7 +3690,9 @@ int libxl_cpupool_cpuremove_node(libxl_c
         }
     }
 
-    libxl_topologyinfo_dispose(&topology);
+    for (cpu = 0; cpu < nr_cpus; cpu++)
+        libxl_cputopology_dispose(&topology[cpu]);
+    free(topology);
 
 out:
     for (p = 0; p < n_pools; p++) {
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/libxl.h	Tue Jan 31 13:11:30 2012 +0000
@@ -576,7 +576,9 @@ int libxl_userdata_retrieve(libxl_ctx *c
    */
 
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
-int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info);
+#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
+void libxl_cputopology_list_free(libxl_cputopology *, int nr);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
                                        int *nb_vcpu, int *nrcpus);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 31 13:11:30 2012 +0000
@@ -376,10 +376,10 @@ libxl_physinfo = Struct("physinfo", [
     ("phys_cap", uint32),
     ], dispose_fn=None, dir=DIR_OUT)
 
-libxl_topologyinfo = Struct("topologyinfo", [
-    ("coremap", libxl_cpuarray),   # cpu to core map
-    ("socketmap", libxl_cpuarray), # cpu to socket map
-    ("nodemap", libxl_cpuarray),   # cpu to node map
+libxl_cputopology = Struct("cputopology", [
+    ("core", uint32),
+    ("socket", uint32),
+    ("node", uint32),
     ])
 
 libxl_sched_credit = Struct("sched_credit", [
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Tue Jan 31 13:11:30 2012 +0000
@@ -557,6 +557,14 @@ int libxl__enum_from_string(const libxl_
     return ERROR_FAIL;
 }
 
+void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_cputopology_dispose(&list[i]);
+    free(list);
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 13:11:30 2012 +0000
@@ -3856,10 +3856,11 @@ static void output_physinfo(void)
 
 static void output_topologyinfo(void)
 {
-    libxl_topologyinfo info;
-    int i;
-
-    if (libxl_get_topologyinfo(ctx, &info)) {
+    libxl_cputopology *info;
+    int i, nr;
+
+    info = libxl_get_cpu_topology(ctx, &nr);
+    if (info == NULL) {
         fprintf(stderr, "libxl_get_topologyinfo failed.\n");
         return;
     }
@@ -3867,16 +3868,16 @@ static void output_topologyinfo(void)
     printf("cpu_topology           :\n");
     printf("cpu:    core    socket     node\n");
 
-    for (i = 0; i < info.coremap.entries; i++) {
-        if (info.coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY)
-            printf("%3d:    %4d     %4d     %4d\n", i, info.coremap.array[i],
-                info.socketmap.array[i], info.nodemap.array[i]);
-    }
+    for (i = 0; i < nr; i++) {
+        if (info[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+            printf("%3d:    %4d     %4d     %4d\n", i,
+                   info[i].core, info[i].socket, info[i].node);
+    }
+
+    libxl_cputopology_list_free(info, nr);
 
     printf("numa_info              : none\n");
 
-    libxl_topologyinfo_dispose(&info);
-
     return;
 }
 
@@ -5373,7 +5374,7 @@ int main_cpupoolcreate(int argc, char **
     libxl_cpumap freemap;
     libxl_cpumap cpumap;
     libxl_uuid uuid;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
 
     while (1) {
         opt = getopt_long(argc, argv, "hnf:", long_options, &option_index);
@@ -5482,16 +5483,18 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
     if (!xlu_cfg_get_list(config, "nodes", &nodes, 0, 0)) {
+        int nr;
         n_cpus = 0;
         n_nodes = 0;
-        if (libxl_get_topologyinfo(ctx, &topology)) {
+        topology = libxl_get_cpu_topology(ctx, &nr);
+        if (topology == NULL) {
             fprintf(stderr, "libxl_get_topologyinfo failed\n");
             return -ERROR_FAIL;
         }
         while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
             n = atoi(buf);
-            for (i = 0; i < topology.nodemap.entries; i++) {
-                if ((topology.nodemap.array[i] == n) &&
+            for (i = 0; i < nr; i++) {
+                if ((topology[i].node == n) &&
                     libxl_cpumap_test(&freemap, i)) {
                     libxl_cpumap_set(&cpumap, i);
                     n_cpus++;
@@ -5500,7 +5503,7 @@ int main_cpupoolcreate(int argc, char **
             n_nodes++;
         }
 
-        libxl_topologyinfo_dispose(&topology);
+        libxl_cputopology_list_free(topology, nr);
 
         if (n_cpus == 0) {
             fprintf(stderr, "no free cpu found\n");
@@ -5822,11 +5825,12 @@ int main_cpupoolnumasplit(int argc, char
     int schedid;
     int n_pools;
     int node;
+    int n_cpus;
     char name[16];
     libxl_uuid uuid;
     libxl_cpumap cpumap;
     libxl_cpupoolinfo *poolinfo;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
     libxl_dominfo info;
 
     if ((opt = def_getopt(argc, argv, "", "cpupool-numa-split", 0)) != -1)
@@ -5848,21 +5852,22 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &n_cpus);
+    if (topology == NULL) {
         fprintf(stderr, "libxl_get_topologyinfo failed\n");
         return -ERROR_FAIL;
     }
 
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
-        libxl_topologyinfo_dispose(&topology);
+        libxl_cputopology_list_free(topology, n_cpus);
         return -ERROR_FAIL;
     }
 
     /* Reset Pool-0 to 1st node: first add cpus, then remove cpus to avoid
        a cpupool without cpus in between */
 
-    node = topology.nodemap.array[0];
+    node = topology[0].node;
     if (libxl_cpupool_cpuadd_node(ctx, 0, node, &n)) {
         fprintf(stderr, "error on adding cpu to Pool 0\n");
         return -ERROR_FAIL;
@@ -5876,9 +5881,9 @@ int main_cpupoolnumasplit(int argc, char
     }
 
     n = 0;
-    for (c = 0; c < topology.nodemap.entries; c++) {
-        if (topology.nodemap.array[c] == node) {
-            topology.nodemap.array[c] = LIBXL_CPUARRAY_INVALID_ENTRY;
+    for (c = 0; c < n_cpus; c++) {
+        if (topology[c].node == node) {
+            topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             libxl_cpumap_set(&cpumap, n);
             n++;
         }
@@ -5903,12 +5908,12 @@ int main_cpupoolnumasplit(int argc, char
     }
     memset(cpumap.map, 0, cpumap.size);
 
-    for (c = 0; c < topology.nodemap.entries; c++) {
-        if (topology.nodemap.array[c] == LIBXL_CPUARRAY_INVALID_ENTRY) {
+    for (c = 0; c < n_cpus; c++) {
+        if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
             continue;
         }
 
-        node = topology.nodemap.array[c];
+        node = topology[c].node;
         ret = -libxl_cpupool_cpuremove_node(ctx, 0, node, &n);
         if (ret) {
             fprintf(stderr, "error on removing cpu from Pool 0\n");
@@ -5930,15 +5935,15 @@ int main_cpupoolnumasplit(int argc, char
             goto out;
         }
 
-        for (p = c; p < topology.nodemap.entries; p++) {
-            if (topology.nodemap.array[p] == node) {
-                topology.nodemap.array[p] = LIBXL_CPUARRAY_INVALID_ENTRY;
+        for (p = c; p < n_cpus; p++) {
+            if (topology[p].node == node) {
+                topology[p].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             }
         }
     }
 
 out:
-    libxl_topologyinfo_dispose(&topology);
+    libxl_cputopology_list_free(topology, n_cpus);
     libxl_cpumap_dispose(&cpumap);
 
     return ret;
diff -r 1ab41d14959e -r f8fbad48472b tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Tue Jan 31 13:11:30 2012 +0000
@@ -29,6 +29,8 @@ functions = { # ( name , [type1,type2,..
     "device_pci":     DEVICE_FUNCTIONS,
     "physinfo":       [ ("get",            ["unit", "t"]),
                       ],
+    "cputopology":    [ ("get",            ["unit", "t array"]),
+                      ],
     "sched_credit":   [ ("domain_get",     ["domid", "t"]),
                         ("domain_set",     ["domid", "t", "unit"]),
                       ],
@@ -266,7 +268,6 @@ if __name__ == '__main__':
         "domain_create_info",
         "domain_build_info",
         "vcpuinfo",
-        "topologyinfo",
         "event",
         ]
 
diff -r 1ab41d14959e -r f8fbad48472b tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight.ml.in	Tue Jan 31 13:11:30 2012 +0000
@@ -19,17 +19,6 @@ type domid = int
 
 (* @@LIBXL_TYPES@@ *)
 
-module Topologyinfo = struct
-	type t =
-	{
-		core : int;
-		socket : int;
-		node : int;
-	}
-	external get : unit -> t array = "stub_xl_topologyinfo"
-end
-
-
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff -r 1ab41d14959e -r f8fbad48472b tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight.mli.in	Tue Jan 31 13:11:30 2012 +0000
@@ -19,16 +19,6 @@ type domid = int
 
 (* @@LIBXL_TYPES@@ *)
 
-module Topologyinfo : sig
-	type t =
-	{
-		core : int;
-		socket : int;
-		node : int;
-	}
-	external get : unit -> t array = "stub_xl_topologyinfo"
-end
-
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff -r 1ab41d14959e -r f8fbad48472b tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Tue Jan 31 13:11:30 2012 +0000
@@ -210,28 +210,6 @@ static value Val_hwcap(libxl_hwcap *c_va
 
 #include "_libxl_types.inc"
 
-static value Val_topologyinfo(libxl_topologyinfo *c_val)
-{
-	CAMLparam0();
-	CAMLlocal3(v, topology, topologyinfo);
-	int i;
-
-	topologyinfo = caml_alloc_tuple(c_val->coremap.entries);
-	for (i = 0; i < c_val->coremap.entries; i++) {
-		v = Val_none;
-		if (c_val->coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY) {
-			topology = caml_alloc_tuple(3);
-			Store_field(topology, 0, Val_int(c_val->coremap.array[i]));
-			Store_field(topology, 1, Val_int(c_val->socketmap.array[i]));
-			Store_field(topology, 2, Val_int(c_val->nodemap.array[i]));
-			v = Val_some(topology);
-		}
-		Store_field(topologyinfo, i, v);
-	}
-
-	CAMLreturn(topologyinfo);
-}
-
 value stub_xl_device_disk_add(value info, value domid)
 {
 	CAMLparam2(info, domid);
@@ -462,22 +440,33 @@ value stub_xl_physinfo_get(value unit)
 	CAMLreturn(physinfo);
 }
 
-value stub_xl_topologyinfo(value unit)
+value stub_xl_cputopology_get(value unit)
 {
 	CAMLparam1(unit);
-	CAMLlocal1(topologyinfo);
-	libxl_topologyinfo c_topologyinfo;
-	int ret;
+	CAMLlocal2(topology, v);
+	libxl_cputopology *c_topology;
+	int i, nr, ret;
 	INIT_STRUCT();
 
 	INIT_CTX();
-	ret = libxl_get_topologyinfo(ctx, &c_topologyinfo);
+
+	c_topology = libxl_get_cpu_topology(ctx, &nr);
 	if (ret != 0)
 		failwith_xl("topologyinfo", &lg);
+
+	topology = caml_alloc_tuple(nr);
+	for (i = 0; i < nr; i++) {
+		if (c_topology[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+			v = Val_some(Val_cputopology(&gc, &lg, &c_topology[i]));
+		else
+			v = Val_none;
+		Store_field(topology, i, v);
+	}
+
+	libxl_cputopology_list_free(c_topology, nr);
+
 	FREE_CTX();
-
-	topologyinfo = Val_topologyinfo(&c_topologyinfo);
-	CAMLreturn(topologyinfo);
+	CAMLreturn(topology);
 }
 
 value stub_xl_sched_credit_domain_get(value domid)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:23:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:23:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEbp-0003Yl-SC; Tue, 31 Jan 2012 14:22:57 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsEbo-0003YT-8Z
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:22:56 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-8.tower-216.messagelabs.com!1328019769!12806982!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29133 invoked from network); 31 Jan 2012 14:22:49 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-8.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:22:49 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10391708"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:21: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;
	Tue, 31 Jan 2012 14:21:46 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 31 Jan 2012 14:21:45 +0000
In-Reply-To: <20258.59550.374377.953444@mariner.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
	<20258.59550.374377.953444@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328019706.26983.395.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 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Fri, 2012-01-27 at 18:10 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> > libxl: expose cpu topology as a single list of cpu->{node,core,socket} maps.
> > 
> > Rather than the previous tripple list which is more complicated to work with
> > and harder for language bindings.
> 

> > +    for (cpu = 0; cpu < nr; cpu++) {
> ...
> > +        libxl_cputopology_dispose(&topology[cpu]);
> >      }
> >  
> > -    libxl_topologyinfo_dispose(&topology);
> > -
> > +    free(topology);
> 
> This is quite ugly to have out here in the caller.  Perhaps we should
> provide a helper for this, called libxl_cputopology_free or
> something ?
> 
> > -    libxl_topologyinfo_dispose(&topology);
> > +    for (cpu = 0; cpu < nr_cpus; cpu++)
> > +        libxl_cputopology_dispose(&topology[cpu]);
> > +    free(topology);
> 
> And here it is again, proving my point :-).

I added libxl_cputopology_list_free(libxl_cputopology *, int nr)
which disposes all elements of the list and frees the underlying
storage. Is that what you meant?

I don't like "list" rather than "array" but we use the terminology that
way elsewhere too (e.g. libxl_device_FOO_list, so I suppose it is my own
fault)

> > +#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY ~0
> ...
> > +libxl_cputopology = Struct("cputopology", [
> > +    ("core", uint32),
> > +    ("socket", uint32),
> > +    ("node", uint32),
> 
> You mean (~(uint32_t)0) I think.  The outer ( ) should be included too!

Done.

Updated patch below:

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1328015490 0
# Node ID f8fbad48472b54e8055a861af0be6c9455e3d160
# Parent  1ab41d14959e9e378ca0ca80603524d1f8a05478
libxl: expose cpu topology as a single list of cpu->{node,core,socket} maps.

Rather than the previous tripple list which is more complicated to work with
and harder for language bindings.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <Ian.Jackson@eu.citrix.com>

diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/gentest.py
--- a/tools/libxl/gentest.py	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/gentest.py	Tue Jan 31 13:11:30 2012 +0000
@@ -195,6 +195,7 @@ static void libxl_string_list_rand_init(
     *p = l;
 }
 
+#if 0 /* To be remove in a subsequent patch */
 static void libxl_cpuarray_rand_init(libxl_cpuarray *p)
 {
     int i;
@@ -209,6 +210,7 @@ static void libxl_cpuarray_rand_init(lib
             p->array[i] = r;
     }
 }
+#endif
 """)
     for ty in builtins + types:
         if ty.typename not in handcoded:
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/libxl.c
--- a/tools/libxl/libxl.c	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/libxl.c	Tue Jan 31 13:11:30 2012 +0000
@@ -2755,57 +2755,68 @@ int libxl_get_physinfo(libxl_ctx *ctx, l
     return 0;
 }
 
-int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr)
 {
     xc_topologyinfo_t tinfo;
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_core_t, coremap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_socket_t, socketmap);
     DECLARE_HYPERCALL_BUFFER(xc_cpu_to_node_t, nodemap);
+    libxl_cputopology *ret = NULL;
     int i;
-    int rc = 0;
-
-    rc += libxl_cpuarray_alloc(ctx, &info->coremap);
-    rc += libxl_cpuarray_alloc(ctx, &info->socketmap);
-    rc += libxl_cpuarray_alloc(ctx, &info->nodemap);
-    if (rc)
+    int max_cpus;
+
+    max_cpus = libxl_get_max_cpus(ctx);
+    if (max_cpus == 0)
+    {
+        LIBXL__LOG(ctx, XTL_ERROR, "Unable to determine number of CPUS");
+        return NULL;
+    }
+
+    coremap = xc_hypercall_buffer_alloc
+        (ctx->xch, coremap, sizeof(*coremap) * max_cpus);
+    socketmap = xc_hypercall_buffer_alloc
+        (ctx->xch, socketmap, sizeof(*socketmap) * max_cpus);
+    nodemap = xc_hypercall_buffer_alloc
+        (ctx->xch, nodemap, sizeof(*nodemap) * max_cpus);
+    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL)) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate hypercall arguments");
         goto fail;
-
-    coremap = xc_hypercall_buffer_alloc(ctx->xch, coremap, sizeof(*coremap) * info->coremap.entries);
-    socketmap = xc_hypercall_buffer_alloc(ctx->xch, socketmap, sizeof(*socketmap) * info->socketmap.entries);
-    nodemap = xc_hypercall_buffer_alloc(ctx->xch, nodemap, sizeof(*nodemap) * info->nodemap.entries);
-    if ((coremap == NULL) || (socketmap == NULL) || (nodemap == NULL))
-        goto fail;
+    }
 
     set_xen_guest_handle(tinfo.cpu_to_core, coremap);
     set_xen_guest_handle(tinfo.cpu_to_socket, socketmap);
     set_xen_guest_handle(tinfo.cpu_to_node, nodemap);
-    tinfo.max_cpu_index = info->coremap.entries - 1;
-    if (xc_topologyinfo(ctx->xch, &tinfo) != 0)
+    tinfo.max_cpu_index = max_cpus - 1;
+    if (xc_topologyinfo(ctx->xch, &tinfo) != 0) {
+        LIBXL__LOG_ERRNO(ctx, XTL_ERROR, "Topology info hypercall failed");
         goto fail;
-
-    for (i = 0; i <= tinfo.max_cpu_index; i++) {
-        if (i < info->coremap.entries)
-            info->coremap.array[i] = (coremap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : coremap[i];
-        if (i < info->socketmap.entries)
-            info->socketmap.array[i] = (socketmap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : socketmap[i];
-        if (i < info->nodemap.entries)
-            info->nodemap.array[i] = (nodemap[i] == INVALID_TOPOLOGY_ID) ?
-                LIBXL_CPUARRAY_INVALID_ENTRY : nodemap[i];
     }
 
-    xc_hypercall_buffer_free(ctx->xch, coremap);
-    xc_hypercall_buffer_free(ctx->xch, socketmap);
-    xc_hypercall_buffer_free(ctx->xch, nodemap);
-    return 0;
+    ret = malloc(sizeof(libxl_cputopology) * max_cpus);
+    if (ret == NULL) {
+        LIBXL__LOG_ERRNOVAL(ctx, XTL_ERROR, ENOMEM,
+                            "Unable to allocate return value");
+        goto fail;
+    }
+
+    for (i = 0; i <= max_cpus; i++) {
+#define V(map, i) (map[i] == INVALID_TOPOLOGY_ID) ? \
+    LIBXL_CPUTOPOLOGY_INVALID_ENTRY : map[i]
+        ret[i].core = V(coremap, i);
+        ret[i].socket = V(socketmap, i);
+        ret[i].node = V(nodemap, i);
+#undef V
+    }
 
 fail:
     xc_hypercall_buffer_free(ctx->xch, coremap);
     xc_hypercall_buffer_free(ctx->xch, socketmap);
     xc_hypercall_buffer_free(ctx->xch, nodemap);
-    libxl_topologyinfo_dispose(info);
-    return ERROR_FAIL;
+
+    if (ret)
+        *nr = max_cpus;
+    return ret;
 }
 
 const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
@@ -3604,30 +3615,30 @@ int libxl_cpupool_cpuadd(libxl_ctx *ctx,
 int libxl_cpupool_cpuadd_node(libxl_ctx *ctx, uint32_t poolid, int node, int *cpus)
 {
     int rc = 0;
-    int cpu;
+    int cpu, nr;
     libxl_cpumap freemap;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
 
     if (libxl_get_freecpus(ctx, &freemap)) {
         return ERROR_FAIL;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &nr);
+    if (!topology) {
         rc = ERROR_FAIL;
         goto out;
     }
 
     *cpus = 0;
-    for (cpu = 0; cpu < topology.nodemap.entries; cpu++) {
-        if (libxl_cpumap_test(&freemap, cpu) &&
-            (topology.nodemap.array[cpu] == node) &&
+    for (cpu = 0; cpu < nr; cpu++) {
+        if (libxl_cpumap_test(&freemap, cpu) && (topology[cpu].node == node) &&
             !libxl_cpupool_cpuadd(ctx, poolid, cpu)) {
                 (*cpus)++;
         }
+        libxl_cputopology_dispose(&topology[cpu]);
     }
 
-    libxl_topologyinfo_dispose(&topology);
-
+    free(topology);
 out:
     libxl_cpumap_dispose(&freemap);
     return rc;
@@ -3651,8 +3662,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
     int ret = 0;
     int n_pools;
     int p;
-    int cpu;
-    libxl_topologyinfo topology;
+    int cpu, nr_cpus;
+    libxl_cputopology *topology;
     libxl_cpupoolinfo *poolinfo;
 
     poolinfo = libxl_list_cpupool(ctx, &n_pools);
@@ -3660,7 +3671,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
         return ERROR_NOMEM;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &nr_cpus);
+    if (!topology) {
         ret = ERROR_FAIL;
         goto out;
     }
@@ -3668,8 +3680,8 @@ int libxl_cpupool_cpuremove_node(libxl_c
     *cpus = 0;
     for (p = 0; p < n_pools; p++) {
         if (poolinfo[p].poolid == poolid) {
-            for (cpu = 0; cpu < topology.nodemap.entries; cpu++) {
-                if ((topology.nodemap.array[cpu] == node) &&
+            for (cpu = 0; cpu < nr_cpus; cpu++) {
+                if ((topology[cpu].node == node) &&
                     libxl_cpumap_test(&poolinfo[p].cpumap, cpu) &&
                     !libxl_cpupool_cpuremove(ctx, poolid, cpu)) {
                         (*cpus)++;
@@ -3678,7 +3690,9 @@ int libxl_cpupool_cpuremove_node(libxl_c
         }
     }
 
-    libxl_topologyinfo_dispose(&topology);
+    for (cpu = 0; cpu < nr_cpus; cpu++)
+        libxl_cputopology_dispose(&topology[cpu]);
+    free(topology);
 
 out:
     for (p = 0; p < n_pools; p++) {
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/libxl.h
--- a/tools/libxl/libxl.h	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/libxl.h	Tue Jan 31 13:11:30 2012 +0000
@@ -576,7 +576,9 @@ int libxl_userdata_retrieve(libxl_ctx *c
    */
 
 int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
-int libxl_get_topologyinfo(libxl_ctx *ctx, libxl_topologyinfo *info);
+#define LIBXL_CPUTOPOLOGY_INVALID_ENTRY (~(uint32_t)0)
+libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nr);
+void libxl_cputopology_list_free(libxl_cputopology *, int nr);
 libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
                                        int *nb_vcpu, int *nrcpus);
 int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/libxl_types.idl	Tue Jan 31 13:11:30 2012 +0000
@@ -376,10 +376,10 @@ libxl_physinfo = Struct("physinfo", [
     ("phys_cap", uint32),
     ], dispose_fn=None, dir=DIR_OUT)
 
-libxl_topologyinfo = Struct("topologyinfo", [
-    ("coremap", libxl_cpuarray),   # cpu to core map
-    ("socketmap", libxl_cpuarray), # cpu to socket map
-    ("nodemap", libxl_cpuarray),   # cpu to node map
+libxl_cputopology = Struct("cputopology", [
+    ("core", uint32),
+    ("socket", uint32),
+    ("node", uint32),
     ])
 
 libxl_sched_credit = Struct("sched_credit", [
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/libxl_utils.c
--- a/tools/libxl/libxl_utils.c	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/libxl_utils.c	Tue Jan 31 13:11:30 2012 +0000
@@ -557,6 +557,14 @@ int libxl__enum_from_string(const libxl_
     return ERROR_FAIL;
 }
 
+void libxl_cputopology_list_free(libxl_cputopology *list, int nr)
+{
+    int i;
+    for (i = 0; i < nr; i++)
+        libxl_cputopology_dispose(&list[i]);
+    free(list);
+}
+
 /*
  * Local variables:
  * mode: C
diff -r 1ab41d14959e -r f8fbad48472b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Tue Jan 31 13:11:30 2012 +0000
@@ -3856,10 +3856,11 @@ static void output_physinfo(void)
 
 static void output_topologyinfo(void)
 {
-    libxl_topologyinfo info;
-    int i;
-
-    if (libxl_get_topologyinfo(ctx, &info)) {
+    libxl_cputopology *info;
+    int i, nr;
+
+    info = libxl_get_cpu_topology(ctx, &nr);
+    if (info == NULL) {
         fprintf(stderr, "libxl_get_topologyinfo failed.\n");
         return;
     }
@@ -3867,16 +3868,16 @@ static void output_topologyinfo(void)
     printf("cpu_topology           :\n");
     printf("cpu:    core    socket     node\n");
 
-    for (i = 0; i < info.coremap.entries; i++) {
-        if (info.coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY)
-            printf("%3d:    %4d     %4d     %4d\n", i, info.coremap.array[i],
-                info.socketmap.array[i], info.nodemap.array[i]);
-    }
+    for (i = 0; i < nr; i++) {
+        if (info[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+            printf("%3d:    %4d     %4d     %4d\n", i,
+                   info[i].core, info[i].socket, info[i].node);
+    }
+
+    libxl_cputopology_list_free(info, nr);
 
     printf("numa_info              : none\n");
 
-    libxl_topologyinfo_dispose(&info);
-
     return;
 }
 
@@ -5373,7 +5374,7 @@ int main_cpupoolcreate(int argc, char **
     libxl_cpumap freemap;
     libxl_cpumap cpumap;
     libxl_uuid uuid;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
 
     while (1) {
         opt = getopt_long(argc, argv, "hnf:", long_options, &option_index);
@@ -5482,16 +5483,18 @@ int main_cpupoolcreate(int argc, char **
         return -ERROR_FAIL;
     }
     if (!xlu_cfg_get_list(config, "nodes", &nodes, 0, 0)) {
+        int nr;
         n_cpus = 0;
         n_nodes = 0;
-        if (libxl_get_topologyinfo(ctx, &topology)) {
+        topology = libxl_get_cpu_topology(ctx, &nr);
+        if (topology == NULL) {
             fprintf(stderr, "libxl_get_topologyinfo failed\n");
             return -ERROR_FAIL;
         }
         while ((buf = xlu_cfg_get_listitem(nodes, n_nodes)) != NULL) {
             n = atoi(buf);
-            for (i = 0; i < topology.nodemap.entries; i++) {
-                if ((topology.nodemap.array[i] == n) &&
+            for (i = 0; i < nr; i++) {
+                if ((topology[i].node == n) &&
                     libxl_cpumap_test(&freemap, i)) {
                     libxl_cpumap_set(&cpumap, i);
                     n_cpus++;
@@ -5500,7 +5503,7 @@ int main_cpupoolcreate(int argc, char **
             n_nodes++;
         }
 
-        libxl_topologyinfo_dispose(&topology);
+        libxl_cputopology_list_free(topology, nr);
 
         if (n_cpus == 0) {
             fprintf(stderr, "no free cpu found\n");
@@ -5822,11 +5825,12 @@ int main_cpupoolnumasplit(int argc, char
     int schedid;
     int n_pools;
     int node;
+    int n_cpus;
     char name[16];
     libxl_uuid uuid;
     libxl_cpumap cpumap;
     libxl_cpupoolinfo *poolinfo;
-    libxl_topologyinfo topology;
+    libxl_cputopology *topology;
     libxl_dominfo info;
 
     if ((opt = def_getopt(argc, argv, "", "cpupool-numa-split", 0)) != -1)
@@ -5848,21 +5852,22 @@ int main_cpupoolnumasplit(int argc, char
         return -ERROR_FAIL;
     }
 
-    if (libxl_get_topologyinfo(ctx, &topology)) {
+    topology = libxl_get_cpu_topology(ctx, &n_cpus);
+    if (topology == NULL) {
         fprintf(stderr, "libxl_get_topologyinfo failed\n");
         return -ERROR_FAIL;
     }
 
     if (libxl_cpumap_alloc(ctx, &cpumap)) {
         fprintf(stderr, "Failed to allocate cpumap\n");
-        libxl_topologyinfo_dispose(&topology);
+        libxl_cputopology_list_free(topology, n_cpus);
         return -ERROR_FAIL;
     }
 
     /* Reset Pool-0 to 1st node: first add cpus, then remove cpus to avoid
        a cpupool without cpus in between */
 
-    node = topology.nodemap.array[0];
+    node = topology[0].node;
     if (libxl_cpupool_cpuadd_node(ctx, 0, node, &n)) {
         fprintf(stderr, "error on adding cpu to Pool 0\n");
         return -ERROR_FAIL;
@@ -5876,9 +5881,9 @@ int main_cpupoolnumasplit(int argc, char
     }
 
     n = 0;
-    for (c = 0; c < topology.nodemap.entries; c++) {
-        if (topology.nodemap.array[c] == node) {
-            topology.nodemap.array[c] = LIBXL_CPUARRAY_INVALID_ENTRY;
+    for (c = 0; c < n_cpus; c++) {
+        if (topology[c].node == node) {
+            topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             libxl_cpumap_set(&cpumap, n);
             n++;
         }
@@ -5903,12 +5908,12 @@ int main_cpupoolnumasplit(int argc, char
     }
     memset(cpumap.map, 0, cpumap.size);
 
-    for (c = 0; c < topology.nodemap.entries; c++) {
-        if (topology.nodemap.array[c] == LIBXL_CPUARRAY_INVALID_ENTRY) {
+    for (c = 0; c < n_cpus; c++) {
+        if (topology[c].node == LIBXL_CPUTOPOLOGY_INVALID_ENTRY) {
             continue;
         }
 
-        node = topology.nodemap.array[c];
+        node = topology[c].node;
         ret = -libxl_cpupool_cpuremove_node(ctx, 0, node, &n);
         if (ret) {
             fprintf(stderr, "error on removing cpu from Pool 0\n");
@@ -5930,15 +5935,15 @@ int main_cpupoolnumasplit(int argc, char
             goto out;
         }
 
-        for (p = c; p < topology.nodemap.entries; p++) {
-            if (topology.nodemap.array[p] == node) {
-                topology.nodemap.array[p] = LIBXL_CPUARRAY_INVALID_ENTRY;
+        for (p = c; p < n_cpus; p++) {
+            if (topology[p].node == node) {
+                topology[p].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
             }
         }
     }
 
 out:
-    libxl_topologyinfo_dispose(&topology);
+    libxl_cputopology_list_free(topology, n_cpus);
     libxl_cpumap_dispose(&cpumap);
 
     return ret;
diff -r 1ab41d14959e -r f8fbad48472b tools/ocaml/libs/xl/genwrap.py
--- a/tools/ocaml/libs/xl/genwrap.py	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/ocaml/libs/xl/genwrap.py	Tue Jan 31 13:11:30 2012 +0000
@@ -29,6 +29,8 @@ functions = { # ( name , [type1,type2,..
     "device_pci":     DEVICE_FUNCTIONS,
     "physinfo":       [ ("get",            ["unit", "t"]),
                       ],
+    "cputopology":    [ ("get",            ["unit", "t array"]),
+                      ],
     "sched_credit":   [ ("domain_get",     ["domid", "t"]),
                         ("domain_set",     ["domid", "t", "unit"]),
                       ],
@@ -266,7 +268,6 @@ if __name__ == '__main__':
         "domain_create_info",
         "domain_build_info",
         "vcpuinfo",
-        "topologyinfo",
         "event",
         ]
 
diff -r 1ab41d14959e -r f8fbad48472b tools/ocaml/libs/xl/xenlight.ml.in
--- a/tools/ocaml/libs/xl/xenlight.ml.in	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight.ml.in	Tue Jan 31 13:11:30 2012 +0000
@@ -19,17 +19,6 @@ type domid = int
 
 (* @@LIBXL_TYPES@@ *)
 
-module Topologyinfo = struct
-	type t =
-	{
-		core : int;
-		socket : int;
-		node : int;
-	}
-	external get : unit -> t array = "stub_xl_topologyinfo"
-end
-
-
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff -r 1ab41d14959e -r f8fbad48472b tools/ocaml/libs/xl/xenlight.mli.in
--- a/tools/ocaml/libs/xl/xenlight.mli.in	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight.mli.in	Tue Jan 31 13:11:30 2012 +0000
@@ -19,16 +19,6 @@ type domid = int
 
 (* @@LIBXL_TYPES@@ *)
 
-module Topologyinfo : sig
-	type t =
-	{
-		core : int;
-		socket : int;
-		node : int;
-	}
-	external get : unit -> t array = "stub_xl_topologyinfo"
-end
-
 external send_trigger : domid -> trigger -> int -> unit = "stub_xl_send_trigger"
 external send_sysrq : domid -> char -> unit = "stub_xl_send_sysrq"
 external send_debug_keys : domid -> string -> unit = "stub_xl_send_debug_keys"
diff -r 1ab41d14959e -r f8fbad48472b tools/ocaml/libs/xl/xenlight_stubs.c
--- a/tools/ocaml/libs/xl/xenlight_stubs.c	Tue Jan 31 13:11:29 2012 +0000
+++ b/tools/ocaml/libs/xl/xenlight_stubs.c	Tue Jan 31 13:11:30 2012 +0000
@@ -210,28 +210,6 @@ static value Val_hwcap(libxl_hwcap *c_va
 
 #include "_libxl_types.inc"
 
-static value Val_topologyinfo(libxl_topologyinfo *c_val)
-{
-	CAMLparam0();
-	CAMLlocal3(v, topology, topologyinfo);
-	int i;
-
-	topologyinfo = caml_alloc_tuple(c_val->coremap.entries);
-	for (i = 0; i < c_val->coremap.entries; i++) {
-		v = Val_none;
-		if (c_val->coremap.array[i] != LIBXL_CPUARRAY_INVALID_ENTRY) {
-			topology = caml_alloc_tuple(3);
-			Store_field(topology, 0, Val_int(c_val->coremap.array[i]));
-			Store_field(topology, 1, Val_int(c_val->socketmap.array[i]));
-			Store_field(topology, 2, Val_int(c_val->nodemap.array[i]));
-			v = Val_some(topology);
-		}
-		Store_field(topologyinfo, i, v);
-	}
-
-	CAMLreturn(topologyinfo);
-}
-
 value stub_xl_device_disk_add(value info, value domid)
 {
 	CAMLparam2(info, domid);
@@ -462,22 +440,33 @@ value stub_xl_physinfo_get(value unit)
 	CAMLreturn(physinfo);
 }
 
-value stub_xl_topologyinfo(value unit)
+value stub_xl_cputopology_get(value unit)
 {
 	CAMLparam1(unit);
-	CAMLlocal1(topologyinfo);
-	libxl_topologyinfo c_topologyinfo;
-	int ret;
+	CAMLlocal2(topology, v);
+	libxl_cputopology *c_topology;
+	int i, nr, ret;
 	INIT_STRUCT();
 
 	INIT_CTX();
-	ret = libxl_get_topologyinfo(ctx, &c_topologyinfo);
+
+	c_topology = libxl_get_cpu_topology(ctx, &nr);
 	if (ret != 0)
 		failwith_xl("topologyinfo", &lg);
+
+	topology = caml_alloc_tuple(nr);
+	for (i = 0; i < nr; i++) {
+		if (c_topology[i].core != LIBXL_CPUTOPOLOGY_INVALID_ENTRY)
+			v = Val_some(Val_cputopology(&gc, &lg, &c_topology[i]));
+		else
+			v = Val_none;
+		Store_field(topology, i, v);
+	}
+
+	libxl_cputopology_list_free(c_topology, nr);
+
 	FREE_CTX();
-
-	topologyinfo = Val_topologyinfo(&c_topologyinfo);
-	CAMLreturn(topologyinfo);
+	CAMLreturn(topology);
 }
 
 value stub_xl_sched_credit_domain_get(value domid)




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:25:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEdg-0003iq-Iy; Tue, 31 Jan 2012 14:24: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 1RsEdf-0003iK-BZ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:24:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1328019884!8978750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22499 invoked from network); 31 Jan 2012 14:24:45 -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;
	31 Jan 2012 14:24:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10391805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:24: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, 31 Jan 2012 14:24: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
	1RsEdY-0004hV-1s; Tue, 31 Jan 2012 14:24:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsEdX-0004Bk-Vl;
	Tue, 31 Jan 2012 14:24:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.63915.47408.626083@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:24:43 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328019706.26983.395.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
	<20258.59550.374377.953444@mariner.uk.xensource.com>
	<1328019706.26983.395.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 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> I added libxl_cputopology_list_free(libxl_cputopology *, int nr)
> which disposes all elements of the list and frees the underlying
> storage. Is that what you meant?

Yes.

> I don't like "list" rather than "array" but we use the terminology that
> way elsewhere too (e.g. libxl_device_FOO_list, so I suppose it is my own
> fault)

Well if you like add another patch to rename them all :-).  But I
think "list" is OK.

> Done.
> 
> Updated patch below:

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 Tue Jan 31 14:25:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEdg-0003iq-Iy; Tue, 31 Jan 2012 14:24: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 1RsEdf-0003iK-BZ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:24:51 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1328019884!8978750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22499 invoked from network); 31 Jan 2012 14:24:45 -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;
	31 Jan 2012 14:24:45 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10391805"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:24: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, 31 Jan 2012 14:24: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
	1RsEdY-0004hV-1s; Tue, 31 Jan 2012 14:24:44 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsEdX-0004Bk-Vl;
	Tue, 31 Jan 2012 14:24:43 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.63915.47408.626083@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:24:43 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1328019706.26983.395.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327512250@cosworth.uk.xensource.com>
	<e1753f37c9064f1e84fa.1327512256@cosworth.uk.xensource.com>
	<20258.59550.374377.953444@mariner.uk.xensource.com>
	<1328019706.26983.395.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 6 of 9] libxl: expose cpu topology as a
 single list of cpu->{node, core, socket} maps
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 6 of 9] libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps"):
> I added libxl_cputopology_list_free(libxl_cputopology *, int nr)
> which disposes all elements of the list and frees the underlying
> storage. Is that what you meant?

Yes.

> I don't like "list" rather than "array" but we use the terminology that
> way elsewhere too (e.g. libxl_device_FOO_list, so I suppose it is my own
> fault)

Well if you like add another patch to rename them all :-).  But I
think "list" is OK.

> Done.
> 
> Updated patch below:

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 Tue Jan 31 14:34:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:34:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEmo-000453-DF; Tue, 31 Jan 2012 14:34:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RsEmn-00044e-Px
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:34:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328020449!12270665!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31166 invoked from network); 31 Jan 2012 14:34:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:34:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="179774966"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:34:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 09:34:08 -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 q0VEY67D032306;
	Tue, 31 Jan 2012 06:34:06 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27F8020200007800070211@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<1328009238.27781.87.camel@elijah>
	<4F27F8020200007800070211@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 14:34:05 +0000
Message-ID: <1328020445.22639.20.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 13:17 +0000, Jan Beulich wrote:
> >>> On 31.01.12 at 12:27, George Dunlap <george.dunlap@citrix.com> wrote:
> > On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote:
> >> >>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> >> > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> >> >> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> >> >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> >> x86's vMCE implementation lets a guest know of as many MCE reporting
> >> >> >> banks as there are in the host. While a PV guest could be expected to
> >> >> >> deal with this number changing (particularly decreasing) during migration
> >> >> >> (not currently handled anywhere afaict), for HVM guests this is certainly
> >> >> >> wrong.
> >> >> >>
> >> >> >> At least to me it isn't, however, clear how to properly handle this. The
> >> >> >> easiest would appear to be to save and restore the number of banks
> >> >> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
> >> >> >> silently tolerate accesses between the host and guest values.
> >> >> >
> >> >> > We ran into this in the XS 6.0 release as well.  I think that the
> >> >> > ideal thing to do would be to have a parameter that can be set at
> >> >> > boot, to say how many vMCE banks a guest has, defaulting to the number
> >> >> > of MCE banks on the host.  This parameter would be preserved across
> >> >> > migration.  Ideally, a pool-aware toolstack like xapi would then set
> >> >> > this value to be the value of the host in the pool with the largest
> >> >> > number of banks, allowing a guest to access all the banks on any host
> >> >> > to which it migrates.
> >> >> >
> >> >> > What do you think?
> >> >>
> >> >> That sounds like the way to go.
> >> >
> >> > So should we put this on IanC's to-do-be-done list?  Are you going to
> >> > put it on your to-do list? :-)
> >> 
> >> Below/attached a draft patch (compile tested only), handling save/
> >> restore of the bank count, but not allowing for a config setting to
> >> specify its initial value (yet).
> > 
> > Looks pretty good for a first blush.  Just one question: Why is the vmce
> > count made on a per-vcpu basis, rather than on a per-domain basis, like
> > the actual banks are?  Is the host MCE stuff per-vcpu?
> 
> The question should probably be the other way around - why is the
> vMCE implementation using global (fake) MSRs rather than per-vCPU
> ones (as they would be on hardware). If the change here was
> implemented as per-domain MSRs, a future move of the vMCE
> implementation to a more natural model would be impossible. Also,
> for the PV case the save/restore logic is much simpler this way.

Ah, that makes sense.  Good spot on the impossiblity of changing to
per-vcpu later.  

 -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:34:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:34:31 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsEmo-000453-DF; Tue, 31 Jan 2012 14:34:18 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@eu.citrix.com>) id 1RsEmn-00044e-Px
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:34:18 +0000
X-Env-Sender: George.Dunlap@eu.citrix.com
X-Msg-Ref: server-14.tower-182.messagelabs.com!1328020449!12270665!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31166 invoked from network); 31 Jan 2012 14:34:11 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-14.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:34:11 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="179774966"
Received: from ftlpmailmx02.citrite.net ([10.13.107.66])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 09:34:09 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.66) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 09:34:08 -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 q0VEY67D032306;
	Tue, 31 Jan 2012 06:34:06 -0800
From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F27F8020200007800070211@nat28.tlf.novell.com>
References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com>
	<CAFLBxZZf84k9kJcU0vMvw0dicrQXOXmPMdMS57Kzef0PuRQfzA@mail.gmail.com>
	<4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
	<1327596896.24345.66.camel@elijah>
	<4F26AD7C020000780006FDC1@nat28.tlf.novell.com>
	<1328009238.27781.87.camel@elijah>
	<4F27F8020200007800070211@nat28.tlf.novell.com>
Date: Tue, 31 Jan 2012 14:34:05 +0000
Message-ID: <1328020445.22639.20.camel@elijah>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Cc: George Dunlap <George.Dunlap@eu.citrix.com>, Olaf Hering <olaf@aepfle.de>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] vMCE vs migration
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 13:17 +0000, Jan Beulich wrote:
> >>> On 31.01.12 at 12:27, George Dunlap <george.dunlap@citrix.com> wrote:
> > On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote:
> >> >>> On 26.01.12 at 17:54, George Dunlap <george.dunlap@citrix.com> wrote:
> >> > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> >> >> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> >> >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
> >> >> >> x86's vMCE implementation lets a guest know of as many MCE reporting
> >> >> >> banks as there are in the host. While a PV guest could be expected to
> >> >> >> deal with this number changing (particularly decreasing) during migration
> >> >> >> (not currently handled anywhere afaict), for HVM guests this is certainly
> >> >> >> wrong.
> >> >> >>
> >> >> >> At least to me it isn't, however, clear how to properly handle this. The
> >> >> >> easiest would appear to be to save and restore the number of banks
> >> >> >> the guest was made believe it can access, making vmce_{rd,wr}msr()
> >> >> >> silently tolerate accesses between the host and guest values.
> >> >> >
> >> >> > We ran into this in the XS 6.0 release as well.  I think that the
> >> >> > ideal thing to do would be to have a parameter that can be set at
> >> >> > boot, to say how many vMCE banks a guest has, defaulting to the number
> >> >> > of MCE banks on the host.  This parameter would be preserved across
> >> >> > migration.  Ideally, a pool-aware toolstack like xapi would then set
> >> >> > this value to be the value of the host in the pool with the largest
> >> >> > number of banks, allowing a guest to access all the banks on any host
> >> >> > to which it migrates.
> >> >> >
> >> >> > What do you think?
> >> >>
> >> >> That sounds like the way to go.
> >> >
> >> > So should we put this on IanC's to-do-be-done list?  Are you going to
> >> > put it on your to-do list? :-)
> >> 
> >> Below/attached a draft patch (compile tested only), handling save/
> >> restore of the bank count, but not allowing for a config setting to
> >> specify its initial value (yet).
> > 
> > Looks pretty good for a first blush.  Just one question: Why is the vmce
> > count made on a per-vcpu basis, rather than on a per-domain basis, like
> > the actual banks are?  Is the host MCE stuff per-vcpu?
> 
> The question should probably be the other way around - why is the
> vMCE implementation using global (fake) MSRs rather than per-vCPU
> ones (as they would be on hardware). If the change here was
> implemented as per-domain MSRs, a future move of the vMCE
> implementation to a more natural model would be impossible. Also,
> for the PV case the save/restore logic is much simpler this way.

Ah, that makes sense.  Good spot on the impossiblity of changing to
per-vcpu later.  

 -George



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:36:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEp7-0004H9-W9; Tue, 31 Jan 2012 14:36:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsEp6-0004GV-Kx
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:36:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328020594!10770131!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28357 invoked from network); 31 Jan 2012 14:36:34 -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;
	31 Jan 2012 14:36:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10392262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:36: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, 31 Jan 2012 14:36: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
	1RsEov-0004m4-2O; Tue, 31 Jan 2012 14:36:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsEov-0004CV-0W;
	Tue, 31 Jan 2012 14:36:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.64620.849351.654475@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:36:28 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <a44bd706400238c6f5e3.1327337126@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
	<a44bd706400238c6f5e3.1327337126@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 03 of 20] ocaml: use libxl IDL type helpers
 for C argument passing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 03 of 20] ocaml: use libxl IDL type helpers for C argument passing"):
> ocaml: use libxl IDL type helpers for C argument passing

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 Jan 31 14:36:57 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEp7-0004H9-W9; Tue, 31 Jan 2012 14:36:42 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsEp6-0004GV-Kx
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:36:40 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328020594!10770131!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28357 invoked from network); 31 Jan 2012 14:36:34 -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;
	31 Jan 2012 14:36:34 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10392262"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:36: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, 31 Jan 2012 14:36: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
	1RsEov-0004m4-2O; Tue, 31 Jan 2012 14:36:29 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsEov-0004CV-0W;
	Tue, 31 Jan 2012 14:36:29 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.64620.849351.654475@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:36:28 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <a44bd706400238c6f5e3.1327337126@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
	<a44bd706400238c6f5e3.1327337126@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 03 of 20] ocaml: use libxl IDL type helpers
 for C argument passing
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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 03 of 20] ocaml: use libxl IDL type helpers for C argument passing"):
> ocaml: use libxl IDL type helpers for C argument passing

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 Jan 31 14:44:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEwi-0004ZI-V3; Tue, 31 Jan 2012 14:44: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 1RsEwh-0004ZB-30
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:44:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328020996!63205321!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22319 invoked from network); 31 Jan 2012 14:43:16 -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;
	31 Jan 2012 14:43:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10392720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14: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; Tue, 31 Jan 2012 14:44:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsEwa-0004p1-OA; Tue, 31 Jan 2012 14:44:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsEwa-0004DP-M3;
	Tue, 31 Jan 2012 14:44:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.65096.503704.448913@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:44:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327569695.26983.23.camel@zakaz.uk.xensource.com>
References: <osstest-11601-mainreport@xen.org>
	<1327569695.26983.23.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] [xen-unstable test] 11601: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> If you are not amenable to having the harness fallback to xl
> button-press/trigger power automatically how about something like the
> following patch with the proviso that it is up to the harness to ensure
> that a guest is configured appropriately such that ACPI power and reset
> events map to shutdown and reboot respectively?
> 
> (patch applies on top of my updated"libxl: remove libxl_button_press in
> favour of libxl_send_trigger" patch from earlier in the week)
...
> xl: allow enable automatic fallback to ACPI events if PV control not available.
> 
> Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
> reset event to be sent to the guest in the event that the guest does not
> support the PV control interface.
> 
> This is not the default because the response to these triggers is an
> guest-internal configuration.

I'm happy with this, but then I would have been happy with this being
the default.

Certainly I think this is a good start, so:

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 Tue Jan 31 14:44:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEwi-0004ZI-V3; Tue, 31 Jan 2012 14:44: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 1RsEwh-0004ZB-30
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:44:31 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328020996!63205321!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22319 invoked from network); 31 Jan 2012 14:43:16 -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;
	31 Jan 2012 14:43:16 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10392720"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14: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; Tue, 31 Jan 2012 14:44:25 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsEwa-0004p1-OA; Tue, 31 Jan 2012 14:44:24 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsEwa-0004DP-M3;
	Tue, 31 Jan 2012 14:44:24 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.65096.503704.448913@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:44:24 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1327569695.26983.23.camel@zakaz.uk.xensource.com>
References: <osstest-11601-mainreport@xen.org>
	<1327569695.26983.23.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] [xen-unstable test] 11601: 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

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> If you are not amenable to having the harness fallback to xl
> button-press/trigger power automatically how about something like the
> following patch with the proviso that it is up to the harness to ensure
> that a guest is configured appropriately such that ACPI power and reset
> events map to shutdown and reboot respectively?
> 
> (patch applies on top of my updated"libxl: remove libxl_button_press in
> favour of libxl_send_trigger" patch from earlier in the week)
...
> xl: allow enable automatic fallback to ACPI events if PV control not available.
> 
> Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
> reset event to be sent to the guest in the event that the guest does not
> support the PV control interface.
> 
> This is not the default because the response to these triggers is an
> guest-internal configuration.

I'm happy with this, but then I would have been happy with this being
the default.

Certainly I think this is a good start, so:

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 Tue Jan 31 14:45:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsExP-0004bu-D2; Tue, 31 Jan 2012 14:45: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 1RsExN-0004bT-SW
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:45:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328021107!13323124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26320 invoked from network); 31 Jan 2012 14:45:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:45:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10392746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:45: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, 31 Jan 2012 14:45: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
	1RsExG-0004pI-N3; Tue, 31 Jan 2012 14:45:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsExG-0004DZ-Le;
	Tue, 31 Jan 2012 14:45:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.65138.658134.762269@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:45:06 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <e6287c6308bd2ef1fb64.1327337131@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
	<e6287c6308bd2ef1fb64.1327337131@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 08 of 20] libxl: now that dm creation takes
 domain_config stop passing down 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

Ian Campbell writes ("[PATCH 08 of 20] libxl: now that dm creation takes domain_config stop passing down devices"):
> libxl: now that dm creation takes domain_config stop passing down devices.

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 Jan 31 14:45:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:45:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsExP-0004bu-D2; Tue, 31 Jan 2012 14:45: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 1RsExN-0004bT-SW
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:45:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-4.tower-216.messagelabs.com!1328021107!13323124!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26320 invoked from network); 31 Jan 2012 14:45:07 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-4.tower-216.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:45:07 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10392746"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:45: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, 31 Jan 2012 14:45: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
	1RsExG-0004pI-N3; Tue, 31 Jan 2012 14:45:06 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsExG-0004DZ-Le;
	Tue, 31 Jan 2012 14:45:06 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.65138.658134.762269@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:45:06 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <e6287c6308bd2ef1fb64.1327337131@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
	<e6287c6308bd2ef1fb64.1327337131@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 08 of 20] libxl: now that dm creation takes
 domain_config stop passing down 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

Ian Campbell writes ("[PATCH 08 of 20] libxl: now that dm creation takes domain_config stop passing down devices"):
> libxl: now that dm creation takes domain_config stop passing down devices.

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 Jan 31 14:46:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEyc-0004jB-Sq; Tue, 31 Jan 2012 14:46:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RsEyb-0004iq-8H
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:46:29 +0000
Received: from [85.158.138.51:8501] by server-12.bemta-3.messagelabs.com id
	56/7E-24557-4CEF72F4; Tue, 31 Jan 2012 14:46:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328021186!11405382!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE3Mzky\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14191 invoked from network); 31 Jan 2012 14:46:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 14:46:27 -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
	q0VEkLt0003116
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 14:46:22 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0VEkKhd002325
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 14:46:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0VEkKxG007698; Tue, 31 Jan 2012 08:46:20 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 06:46:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4239640294; Tue, 31 Jan 2012 09:43:49 -0500 (EST)
Date: Tue, 31 Jan 2012 09:43:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120131144349.GD3244@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
	<20120130214710.GC16261@phenom.dumpdata.com>
	<1328007824.5553.70.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328007824.5553.70.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F27FEBF.0037,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 13/16] netback: stub for multi
 receive protocol 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

> > > existing code as protocol 0.
> > 
> > Why not 1?
> > 
> 
> We have some existing xenolinux code which has not been upstreamed calls
> this protocol 0, just try to be compatible.

Ah. Please do mention that in the description.

> 
> > Why do we need a new rework without anything using it besides
> > the existing framework? OR if you are, you should say which
> > patch is doing it...
> > 
> 
> It is not in use at the moment, and will be in use in the future.

Ok, should it be part of the "in the future" patchset then?

> 
> > > 
> > > Now the file layout becomes:
> > > 
> > >  - interface.c: xenvif interfaces
> > >  - xenbus.c: xenbus related functions
> > >  - netback.c: common functions for various protocols
> > > 
> > > For different protocols:
> > > 
> > >  - xenvif_rx_protocolX.h: header file for the protocol, including
> > >                           protocol structures and functions
> > >  - xenvif_rx_protocolX.c: implementations
> > > 
> > > To add a new protocol:
> > > 
> > >  - include protocol header in common.h
> > >  - modify XENVIF_MAX_RX_PROTOCOL in common.h
> > >  - add protocol structure in xenvif.rx union
> > >  - stub in xenbus.c
> > >  - modify Makefile
> > > 
> > > A protocol should define five functions:
> > > 
> > >  - setup: setup frontend / backend ring connections
> > >  - teardown: teardown frontend / backend ring connections
> > >  - start_xmit: host start xmit (i.e. guest need to do rx)
> > >  - event: rx completion event
> > >  - action: prepare host side data for guest rx
> > > 
> > .. snip..
> > 
> > > -
> > > -	return resp;
> > > -}
> > > -
> > >  static inline int rx_work_todo(struct xenvif *vif)
> > >  {
> > >  	return !skb_queue_empty(&vif->rx_queue);
> > > @@ -1507,8 +999,8 @@ int xenvif_kthread(void *data)
> > >  		if (kthread_should_stop())
> > >  			break;
> > >  
> > > -		if (rx_work_todo(vif))
> > > -			xenvif_rx_action(vif);
> > > +		if (rx_work_todo(vif) && vif->action)
> > > +			vif->action(vif);
> > >  	}
> > >  
> > >  	return 0;
> > > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> > > index 79499fc..4067286 100644
> > > --- a/drivers/net/xen-netback/xenbus.c
> > > +++ b/drivers/net/xen-netback/xenbus.c
> > > @@ -415,6 +415,7 @@ static int connect_rings(struct backend_info *be)
> > >  	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
> > >  	unsigned int  tx_ring_order;
> > >  	unsigned int  rx_ring_order;
> > > +	unsigned int  rx_protocol;
> > >  
> > >  	err = xenbus_gather(XBT_NIL, dev->otherend,
> > >  			    "event-channel", "%u", &evtchn, NULL);
> > > @@ -510,6 +511,11 @@ static int connect_rings(struct backend_info *be)
> > >  		}
> > >  	}
> > >  
> > > +	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-protocol",
> > 
> > feature-rx-protocol?
> > 
> 
> This is not a feature switch. Does it make sense to add "feature-"

Good point.
> prefix?

It is negotiating a new protocol. Hm, perhaps 'protocol-rx-version' instead?
Or just 'protocol-version'?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:46:44 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsEyc-0004jB-Sq; Tue, 31 Jan 2012 14:46:30 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RsEyb-0004iq-8H
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:46:29 +0000
Received: from [85.158.138.51:8501] by server-12.bemta-3.messagelabs.com id
	56/7E-24557-4CEF72F4; Tue, 31 Jan 2012 14:46:28 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-2.tower-174.messagelabs.com!1328021186!11405382!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE3Mzky\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14191 invoked from network); 31 Jan 2012 14:46:27 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-2.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 14:46:27 -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
	q0VEkLt0003116
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 14:46:22 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156])
	by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0VEkKhd002325
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 14:46:21 GMT
Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59])
	by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0VEkKxG007698; Tue, 31 Jan 2012 08:46:20 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 06:46:20 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 4239640294; Tue, 31 Jan 2012 09:43:49 -0500 (EST)
Date: Tue, 31 Jan 2012 09:43:49 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120131144349.GD3244@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-14-git-send-email-wei.liu2@citrix.com>
	<20120130214710.GC16261@phenom.dumpdata.com>
	<1328007824.5553.70.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328007824.5553.70.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
X-CT-RefId: str=0001.0A090203.4F27FEBF.0037,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 13/16] netback: stub for multi
 receive protocol 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

> > > existing code as protocol 0.
> > 
> > Why not 1?
> > 
> 
> We have some existing xenolinux code which has not been upstreamed calls
> this protocol 0, just try to be compatible.

Ah. Please do mention that in the description.

> 
> > Why do we need a new rework without anything using it besides
> > the existing framework? OR if you are, you should say which
> > patch is doing it...
> > 
> 
> It is not in use at the moment, and will be in use in the future.

Ok, should it be part of the "in the future" patchset then?

> 
> > > 
> > > Now the file layout becomes:
> > > 
> > >  - interface.c: xenvif interfaces
> > >  - xenbus.c: xenbus related functions
> > >  - netback.c: common functions for various protocols
> > > 
> > > For different protocols:
> > > 
> > >  - xenvif_rx_protocolX.h: header file for the protocol, including
> > >                           protocol structures and functions
> > >  - xenvif_rx_protocolX.c: implementations
> > > 
> > > To add a new protocol:
> > > 
> > >  - include protocol header in common.h
> > >  - modify XENVIF_MAX_RX_PROTOCOL in common.h
> > >  - add protocol structure in xenvif.rx union
> > >  - stub in xenbus.c
> > >  - modify Makefile
> > > 
> > > A protocol should define five functions:
> > > 
> > >  - setup: setup frontend / backend ring connections
> > >  - teardown: teardown frontend / backend ring connections
> > >  - start_xmit: host start xmit (i.e. guest need to do rx)
> > >  - event: rx completion event
> > >  - action: prepare host side data for guest rx
> > > 
> > .. snip..
> > 
> > > -
> > > -	return resp;
> > > -}
> > > -
> > >  static inline int rx_work_todo(struct xenvif *vif)
> > >  {
> > >  	return !skb_queue_empty(&vif->rx_queue);
> > > @@ -1507,8 +999,8 @@ int xenvif_kthread(void *data)
> > >  		if (kthread_should_stop())
> > >  			break;
> > >  
> > > -		if (rx_work_todo(vif))
> > > -			xenvif_rx_action(vif);
> > > +		if (rx_work_todo(vif) && vif->action)
> > > +			vif->action(vif);
> > >  	}
> > >  
> > >  	return 0;
> > > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> > > index 79499fc..4067286 100644
> > > --- a/drivers/net/xen-netback/xenbus.c
> > > +++ b/drivers/net/xen-netback/xenbus.c
> > > @@ -415,6 +415,7 @@ static int connect_rings(struct backend_info *be)
> > >  	unsigned long rx_ring_ref[NETBK_MAX_RING_PAGES];
> > >  	unsigned int  tx_ring_order;
> > >  	unsigned int  rx_ring_order;
> > > +	unsigned int  rx_protocol;
> > >  
> > >  	err = xenbus_gather(XBT_NIL, dev->otherend,
> > >  			    "event-channel", "%u", &evtchn, NULL);
> > > @@ -510,6 +511,11 @@ static int connect_rings(struct backend_info *be)
> > >  		}
> > >  	}
> > >  
> > > +	err = xenbus_scanf(XBT_NIL, dev->otherend, "rx-protocol",
> > 
> > feature-rx-protocol?
> > 
> 
> This is not a feature switch. Does it make sense to add "feature-"

Good point.
> prefix?

It is negotiating a new protocol. Hm, perhaps 'protocol-rx-version' instead?
Or just 'protocol-version'?


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:49:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsF15-0004zm-FV; Tue, 31 Jan 2012 14:49:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsF14-0004zO-8X
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:49:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328021335!9319260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20832 invoked from network); 31 Jan 2012 14:48:55 -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;
	31 Jan 2012 14:48:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10392857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14: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; Tue, 31 Jan 2012 14:48: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
	1RsF0K-0004qR-H2; Tue, 31 Jan 2012 14:48:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsF0K-0004Dk-FC;
	Tue, 31 Jan 2012 14:48:16 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.65328.443173.839778@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:48:16 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326732404.14689.34.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
	<20244.20607.725332.428230@mariner.uk.xensource.com>
	<1326732404.14689.34.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 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configuration info build_info->u.hvm"):
> On Mon, 2012-01-16 at 16:29 +0000, Ian Jackson wrote:
> > Eg, if we implement some kind of pvusb, aren't we just going to have
> > to move it back ?
> 
> On the one hand I agree.
> 
> On the other hand these particular two USB options are very thin shims
> over the equivalent qemu options and do not contain anything like the
> necessary richness to allow them to describe a device in the detail
> needed to be a first class thing in the IDL. I suspect that if/when we
> have PVUSB we will gain libxl_device_usb as a thing which is completely
> orthogonal to these two.
> 
> I think a similar argument applies to the audio option?

Fair enough.

...
> While we are at it -- do you have any thoughts on how per-arch options
> should be handled? I was thinking of adding the possibility in the IDL
> to tag a field with a list of architectures?

This is a red herring for this patch, I think, so:

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 Jan 31 14:49:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsF15-0004zm-FV; Tue, 31 Jan 2012 14:49:03 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsF14-0004zO-8X
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:49:02 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328021335!9319260!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20832 invoked from network); 31 Jan 2012 14:48:55 -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;
	31 Jan 2012 14:48:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10392857"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14: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; Tue, 31 Jan 2012 14:48: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
	1RsF0K-0004qR-H2; Tue, 31 Jan 2012 14:48:16 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsF0K-0004Dk-FC;
	Tue, 31 Jan 2012 14:48:16 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20263.65328.443173.839778@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 14:48:16 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
In-Reply-To: <1326732404.14689.34.camel@zakaz.uk.xensource.com>
References: <patchbomb.1326716098@cosworth.uk.xensource.com>
	<540c9fa96606437f3197.1326716112@cosworth.uk.xensource.com>
	<20244.20607.725332.428230@mariner.uk.xensource.com>
	<1326732404.14689.34.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 of 32 RFC] libxl: HVM device
 configuration info build_info->u.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

Ian Campbell writes ("Re: [Xen-devel] [PATCH 14 of 32 RFC] libxl: HVM device configuration info build_info->u.hvm"):
> On Mon, 2012-01-16 at 16:29 +0000, Ian Jackson wrote:
> > Eg, if we implement some kind of pvusb, aren't we just going to have
> > to move it back ?
> 
> On the one hand I agree.
> 
> On the other hand these particular two USB options are very thin shims
> over the equivalent qemu options and do not contain anything like the
> necessary richness to allow them to describe a device in the detail
> needed to be a first class thing in the IDL. I suspect that if/when we
> have PVUSB we will gain libxl_device_usb as a thing which is completely
> orthogonal to these two.
> 
> I think a similar argument applies to the audio option?

Fair enough.

...
> While we are at it -- do you have any thoughts on how per-arch options
> should be handled? I was thinking of adding the possibility in the IDL
> to tag a field with a list of architectures?

This is a red herring for this patch, I think, so:

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 Jan 31 14:51:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsF30-0005Bt-WF; Tue, 31 Jan 2012 14:51:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RsF2z-0005Bk-9n
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:51:01 +0000
Received: from [85.158.138.51:4715] by server-1.bemta-3.messagelabs.com id
	B3/16-09565-4DFF72F4; Tue, 31 Jan 2012 14:51:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328021458!11226133!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxODk0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32379 invoked from network); 31 Jan 2012 14:50:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 14:50: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
	q0VEotvh032217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 14:50:56 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
	q0VEosBZ002106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 14:50:54 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0VEoprR012561; Tue, 31 Jan 2012 08:50:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 06:50:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 530E440294; Tue, 31 Jan 2012 09:48:20 -0500 (EST)
Date: Tue, 31 Jan 2012 09:48:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120131144820.GE3244@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
	<1328008145.5553.74.camel@leeds.uk.xensource.com>
	<4F27F9960200007800070228@nat28.tlf.novell.com>
	<1328016770.5553.87.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328016770.5553.87.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F27FFD0.002F,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 01:32:50PM +0000, Wei Liu wrote:
> On Tue, 2012-01-31 at 13:24 +0000, Jan Beulich wrote:
> > >>> On 31.01.12 at 12:09, Wei Liu <wei.liu2@citrix.com> wrote:
> > > On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
> > >> >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> > >> > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> > >> >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> > >> >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> > >> >> > -			      grant_ref_t tx_ring_ref,
> > >> >> > -			      grant_ref_t rx_ring_ref)
> > >> >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> > >> >> > +			      int domid,
> > >> >> > +			      unsigned long ring_ref[],
> > >> >> > +			      unsigned int  ring_ref_count)
> > >> >> >  {
> > >> >> > -	void *addr;
> > >> >> > -	struct xen_netif_tx_sring *txs;
> > >> >> > -	struct xen_netif_rx_sring *rxs;
> > >> >> > -
> > >> >> > -	int err = -ENOMEM;
> > >> >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> > >> >> > +	unsigned int i;
> > >> >> > +	int err = 0;
> > >> >> >  
> > >> >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> > >> >> > -				     tx_ring_ref, &addr);
> > >> >> 
> > >> >> Any reason why you don't just extend this function (in a prerequisite
> > >> >> patch) rather than open coding a common utility function (twice) here,
> > >> >> so that other backends (blkback!) can benefit later as well.
> > >> >> 
> > >> >> Jan
> > >> >> 
> > >> > 
> > >> > I'm mainly focusing on netback stuffs, so the code is slightly coupled
> > >> > with netback -- NETBK_MAX_RING_PAGES.
> > >> > 
> > >> > To extend xenbus_map_ring_valloc and make more generic, it requires
> > >> > setting a global maximum page number limits on rings, I think it will
> > >> > require further investigation and code refactor -- which I have no time
> > >> > to attend to at the moment. :-/
> > >> 
> > >> Why? You can simply pass in the number of pages, there's no need
> > >> for a global maximum.
> > >> 
> > > 
> > > I mean the gnttab_map_gran_ref array, it is statically allocated at the
> > > moment. Of course we can make it dynamically allocated, but why bother
> > > taking the risk of allocation failure.
> > 
> > There's so many other allocations, why would you worry about this
> > one.
> > 
> 
> IMHO, this is not a critical part of the code, so failing this one thus
> making all other pieces not workable is very strange.
> 
> > But of course you can undo what a recent change did, and then
> > subsequently someone else will have to clean up again after you.
> > I'm just asking to follow good programming practices and write
> > re-usable code where potential for re-use is obvious (after all,
> > multi-page block interface patches have been floating around for
> > much longer than yours for the net interface).
> > 
> 
> I understand your concern. If the changes required will not make this
> series longer and involves major changes in block interface, I'm happy
> to refactor the xenbus interface.

Please do. Patches are more than welcome to make it be more versatile.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:51:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:51:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsF30-0005Bt-WF; Tue, 31 Jan 2012 14:51:03 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RsF2z-0005Bk-9n
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:51:01 +0000
Received: from [85.158.138.51:4715] by server-1.bemta-3.messagelabs.com id
	B3/16-09565-4DFF72F4; Tue, 31 Jan 2012 14:51:00 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328021458!11226133!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxODk0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32379 invoked from network); 31 Jan 2012 14:50:59 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-14.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 14:50: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
	q0VEotvh032217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 14:50:56 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
	q0VEosBZ002106
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 14:50:54 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64])
	by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id
	q0VEoprR012561; Tue, 31 Jan 2012 08:50:51 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 06:50:51 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 530E440294; Tue, 31 Jan 2012 09:48:20 -0500 (EST)
Date: Tue, 31 Jan 2012 09:48:20 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Wei Liu <wei.liu2@citrix.com>
Message-ID: <20120131144820.GE3244@phenom.dumpdata.com>
References: <1327934734-8908-1-git-send-email-wei.liu2@citrix.com>
	<1327934734-8908-13-git-send-email-wei.liu2@citrix.com>
	<4F26D4E5020000780006FF41@nat28.tlf.novell.com>
	<1327943436.5553.39.camel@leeds.uk.xensource.com>
	<4F27BC1002000078000700D3@nat28.tlf.novell.com>
	<1328008145.5553.74.camel@leeds.uk.xensource.com>
	<4F27F9960200007800070228@nat28.tlf.novell.com>
	<1328016770.5553.87.camel@leeds.uk.xensource.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1328016770.5553.87.camel@leeds.uk.xensource.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090204.4F27FFD0.002F,ss=1,re=0.000,fgs=0
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Xen-devel] [RFC PATCH V3 12/16] netback: multi-page ring
	support
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, Jan 31, 2012 at 01:32:50PM +0000, Wei Liu wrote:
> On Tue, 2012-01-31 at 13:24 +0000, Jan Beulich wrote:
> > >>> On 31.01.12 at 12:09, Wei Liu <wei.liu2@citrix.com> wrote:
> > > On Tue, 2012-01-31 at 09:01 +0000, Jan Beulich wrote:
> > >> >>> On 30.01.12 at 18:10, Wei Liu <wei.liu2@citrix.com> wrote:
> > >> > On Mon, 2012-01-30 at 16:35 +0000, Jan Beulich wrote:
> > >> >> >>> On 30.01.12 at 15:45, Wei Liu <wei.liu2@citrix.com> wrote:
> > >> >> > -int xenvif_map_frontend_rings(struct xenvif *vif,
> > >> >> > -			      grant_ref_t tx_ring_ref,
> > >> >> > -			      grant_ref_t rx_ring_ref)
> > >> >> > +int xenvif_map_frontend_rings(struct xen_comms *comms,
> > >> >> > +			      int domid,
> > >> >> > +			      unsigned long ring_ref[],
> > >> >> > +			      unsigned int  ring_ref_count)
> > >> >> >  {
> > >> >> > -	void *addr;
> > >> >> > -	struct xen_netif_tx_sring *txs;
> > >> >> > -	struct xen_netif_rx_sring *rxs;
> > >> >> > -
> > >> >> > -	int err = -ENOMEM;
> > >> >> > +	struct gnttab_map_grant_ref op[NETBK_MAX_RING_PAGES];
> > >> >> > +	unsigned int i;
> > >> >> > +	int err = 0;
> > >> >> >  
> > >> >> > -	err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
> > >> >> > -				     tx_ring_ref, &addr);
> > >> >> 
> > >> >> Any reason why you don't just extend this function (in a prerequisite
> > >> >> patch) rather than open coding a common utility function (twice) here,
> > >> >> so that other backends (blkback!) can benefit later as well.
> > >> >> 
> > >> >> Jan
> > >> >> 
> > >> > 
> > >> > I'm mainly focusing on netback stuffs, so the code is slightly coupled
> > >> > with netback -- NETBK_MAX_RING_PAGES.
> > >> > 
> > >> > To extend xenbus_map_ring_valloc and make more generic, it requires
> > >> > setting a global maximum page number limits on rings, I think it will
> > >> > require further investigation and code refactor -- which I have no time
> > >> > to attend to at the moment. :-/
> > >> 
> > >> Why? You can simply pass in the number of pages, there's no need
> > >> for a global maximum.
> > >> 
> > > 
> > > I mean the gnttab_map_gran_ref array, it is statically allocated at the
> > > moment. Of course we can make it dynamically allocated, but why bother
> > > taking the risk of allocation failure.
> > 
> > There's so many other allocations, why would you worry about this
> > one.
> > 
> 
> IMHO, this is not a critical part of the code, so failing this one thus
> making all other pieces not workable is very strange.
> 
> > But of course you can undo what a recent change did, and then
> > subsequently someone else will have to clean up again after you.
> > I'm just asking to follow good programming practices and write
> > re-usable code where potential for re-use is obvious (after all,
> > multi-page block interface patches have been floating around for
> > much longer than yours for the net interface).
> > 
> 
> I understand your concern. If the changes required will not make this
> series longer and involves major changes in block interface, I'm happy
> to refactor the xenbus interface.

Please do. Patches are more than welcome to make it be more versatile.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:51:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsF3S-0005Fp-M2; Tue, 31 Jan 2012 14:51:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsF3R-0005Ev-2r; Tue, 31 Jan 2012 14:51:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1328021482!8984856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10032 invoked from network); 31 Jan 2012 14:51:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:51:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:51:22 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 14:51:22 +0000
Date: Tue, 31 Jan 2012 14:53:04 +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: <1328002610.26983.302.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
References: <9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	xen-devel@lists.xensource.com, "Frank, Chen" <chysun2000@163.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Ian Campbell wrote:
> > make[3]: Entering directory
> > `/home/frank/workspace/xen/src/xen-arm-v6/xen/include'
> > for i in public/callback.h public/dom0_ops.h public/elfnote.h
> > public/event_channel.h public/features.h public/grant_table.h
> > public/kexec.h public/mem_event.h public/memory.h public/nmi.h
> > public/physdev.h public/platform.h public/sched.h public/tmem.h
> > public/trace.h public/vcpu.h public/version.h public/xen-compat.h
> > public/xen.h public/xencomm.h public/xenoprof.h public/hvm/e820.h
> > public/hvm/hvm_info_table.h public/hvm/hvm_op.h public/hvm/ioreq.h
> > public/hvm/params.h public/io/blkif.h public/io/console.h
> > public/io/fbif.h public/io/fsif.h public/io/kbdif.h
> > public/io/libxenvchan.h public/io/netif.h public/io/pciif.h
> > public/io/protocols.h public/io/ring.h public/io/tpmif.h
> > public/io/usbif.h public/io/vscsiif.h public/io/xenbus.h
> > public/io/xs_wire.h; do arm-linux-gnueabi-gcc -ansi -include stdint.h
> > -Wall -W -Werror -S -o /dev/null -xc $i || exit 1; echo $i; done
> > >headers.chk.new
> > public/callback.h:87:5: error: unknown type name 'xen_callback_t'
> 
> At this point I get:
> [ -e include/asm ] || ln -sf asm-arm include/asm
> make -f /local/scratch/ianc/devel/arm/xen-unstable/xen/Rules.mk -C include
> make[3]: Entering directory `/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
> 
> Aha -- the difference is down to XEN_TARGET_ARCH vs. XEN_COMPILE_ARCH,
> see towards the end of xen/include/Makefile:
>         ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
>         ...
>         all: headers.chk
>         ...
> 
> I'm inferring from the Makefile that:
> XEN_COMPILE_ARCH == the host architecture -- e.g. the machine you are
> 	compiling on
> XEN_TARGET_ARCH == the target architecture -- e.g. the machine you want 
> 	to run the resulting Xen on.
> 
> And indeed if I do a native build on an arm system I see the same error
> as you do. We'll look at fixing this but in the meantime I suggest you
> use XEN_TARGET_ARCH and not XEN_COMPILE_ARCH.

The following patch fixes the compile issue (that indeed is due to the
header files check you pointed out).

---

arm: few missing #define

Few missing #define are the cause of a compile failure with
XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
native compilation). This patch fill the gaps.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c430cf3..e04c4fd 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
 
 struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
+typedef unsigned long xen_callback_t;
+
 #endif
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
diff --git a/xen/include/public/io/protocols.h b/xen/include/public/io/protocols.h
index 77bd1bd..0b7a2ea 100644
--- a/xen/include/public/io/protocols.h
+++ b/xen/include/public/io/protocols.h
@@ -26,6 +26,7 @@
 #define XEN_IO_PROTO_ABI_X86_32     "x86_32-abi"
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -33,6 +34,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
 #elif defined(__ia64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:51:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14: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 1RsF3S-0005Fp-M2; Tue, 31 Jan 2012 14:51:30 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsF3R-0005Ev-2r; Tue, 31 Jan 2012 14:51:29 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1328021482!8984856!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10032 invoked from network); 31 Jan 2012 14:51:22 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 14:51:22 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393023"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:51:22 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 14:51:22 +0000
Date: Tue, 31 Jan 2012 14:53:04 +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: <1328002610.26983.302.camel@zakaz.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201311418130.3196@kaball-desktop>
References: <9e3a3f3.470c.135325af644.Coremail.chysun2000@163.com>
	<1328002610.26983.302.camel@zakaz.uk.xensource.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>,
	xen-devel@lists.xensource.com, "Frank, Chen" <chysun2000@163.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [XenARM] [help] How to compile the unstable source
 for arm at sstabellini/xen-unstable.git/.git
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Ian Campbell wrote:
> > make[3]: Entering directory
> > `/home/frank/workspace/xen/src/xen-arm-v6/xen/include'
> > for i in public/callback.h public/dom0_ops.h public/elfnote.h
> > public/event_channel.h public/features.h public/grant_table.h
> > public/kexec.h public/mem_event.h public/memory.h public/nmi.h
> > public/physdev.h public/platform.h public/sched.h public/tmem.h
> > public/trace.h public/vcpu.h public/version.h public/xen-compat.h
> > public/xen.h public/xencomm.h public/xenoprof.h public/hvm/e820.h
> > public/hvm/hvm_info_table.h public/hvm/hvm_op.h public/hvm/ioreq.h
> > public/hvm/params.h public/io/blkif.h public/io/console.h
> > public/io/fbif.h public/io/fsif.h public/io/kbdif.h
> > public/io/libxenvchan.h public/io/netif.h public/io/pciif.h
> > public/io/protocols.h public/io/ring.h public/io/tpmif.h
> > public/io/usbif.h public/io/vscsiif.h public/io/xenbus.h
> > public/io/xs_wire.h; do arm-linux-gnueabi-gcc -ansi -include stdint.h
> > -Wall -W -Werror -S -o /dev/null -xc $i || exit 1; echo $i; done
> > >headers.chk.new
> > public/callback.h:87:5: error: unknown type name 'xen_callback_t'
> 
> At this point I get:
> [ -e include/asm ] || ln -sf asm-arm include/asm
> make -f /local/scratch/ianc/devel/arm/xen-unstable/xen/Rules.mk -C include
> make[3]: Entering directory `/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
> make[3]: Nothing to be done for `all'.
> make[3]: Leaving directory `/local/scratch/ianc/devel/arm/xen-unstable/xen/include'
> 
> Aha -- the difference is down to XEN_TARGET_ARCH vs. XEN_COMPILE_ARCH,
> see towards the end of xen/include/Makefile:
>         ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
>         ...
>         all: headers.chk
>         ...
> 
> I'm inferring from the Makefile that:
> XEN_COMPILE_ARCH == the host architecture -- e.g. the machine you are
> 	compiling on
> XEN_TARGET_ARCH == the target architecture -- e.g. the machine you want 
> 	to run the resulting Xen on.
> 
> And indeed if I do a native build on an arm system I see the same error
> as you do. We'll look at fixing this but in the meantime I suggest you
> use XEN_TARGET_ARCH and not XEN_COMPILE_ARCH.

The following patch fixes the compile issue (that indeed is due to the
header files check you pointed out).

---

arm: few missing #define

Few missing #define are the cause of a compile failure with
XEN_TARGET_ARM=arm and XEN_COMPILE_ARM=arm (for example in the case of a
native compilation). This patch fill the gaps.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index c430cf3..e04c4fd 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -110,6 +110,8 @@ typedef struct arch_vcpu_info arch_vcpu_info_t;
 
 struct arch_shared_info { };
 typedef struct arch_shared_info arch_shared_info_t;
+typedef unsigned long xen_callback_t;
+
 #endif
 
 #endif /*  __XEN_PUBLIC_ARCH_ARM_H__ */
diff --git a/xen/include/public/io/protocols.h b/xen/include/public/io/protocols.h
index 77bd1bd..0b7a2ea 100644
--- a/xen/include/public/io/protocols.h
+++ b/xen/include/public/io/protocols.h
@@ -26,6 +26,7 @@
 #define XEN_IO_PROTO_ABI_X86_32     "x86_32-abi"
 #define XEN_IO_PROTO_ABI_X86_64     "x86_64-abi"
 #define XEN_IO_PROTO_ABI_IA64       "ia64-abi"
+#define XEN_IO_PROTO_ABI_ARM        "arm-abi"
 
 #if defined(__i386__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32
@@ -33,6 +34,8 @@
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_64
 #elif defined(__ia64__)
 # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64
+#elif defined(__arm__)
+# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM
 #else
 # error arch fixup needed here
 #endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:52:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:52:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsF40-0005M9-4A; Tue, 31 Jan 2012 14:52:04 +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 1RsF3y-0005L3-Rz
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:52:03 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328021516!11947412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15982 invoked from network); 31 Jan 2012 14:51:56 -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;
	31 Jan 2012 14:51:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:51:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 14:51:54 +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 1RsF3q-0004rb-3D;
	Tue, 31 Jan 2012 14:51:54 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RsF3e-0006NG-Do;
	Tue, 31 Jan 2012 14:51:42 +0000
Date: Tue, 31 Jan 2012 14:51:42 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120131145142.GB23556@spongy.cam.xci-test.com>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
	<CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
	<alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
	<20120117162414.GA25281@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201171634300.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201171634300.3150@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (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 17/01 04:34, Stefano Stabellini wrote:
> On Tue, 17 Jan 2012, Jean Guyader wrote:
> > On 17/01 02:51, Stefano Stabellini wrote:
> > > On Mon, 16 Jan 2012, Jean Guyader wrote:
> > > > On 12 January 2012 14:34, Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > > > >> On 12/01 12:41, 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>
> > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > > > >>
> > > > >> ?? ?? 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.
> > > > >>
> > > > >> ?? ?? 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.
> > > > >>
> > > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > > > >> index dbe8804..7ee3c61 100644
> > > > >> --- a/hw/pass-through.c
> > > > >> +++ b/hw/pass-through.c
> > > > >> @@ -238,6 +238,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).
> > > > >> @@ -444,6 +452,16 @@ 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,
> > > > >> ?? ?? ??},
> > > > >> + ?? ??/* Intel IGFX OpRegion reg */
> > > > >> + ?? ??{
> > > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > > > >> + ?? ?? ?? ??.init_val ?? = 0,
> > > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > > > >> + ?? ??},
> > > > >> ?? ?? ??{
> > > > >> ?? ?? ?? ?? ??.size = 0,
> > > > >> ?? ?? ??},
> > > > >> @@ -737,7 +755,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 */
> > > > >> @@ -3006,6 +3024,19 @@ 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)
> > > > >> +{
> > > > >> + ?? ??/*
> > > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > > > >> + ?? ??** therefore the size should be 0xff.
> > > > >> + ?? ??*/
> > > > >> + ?? ??if (igd_passthru)
> > > > >> + ?? ?? ?? ??return 0xFF;
> > > > >> + ?? ??return grp_reg->grp_size;
> > > > >> +}
> > > > >
> > > > > Apart from the trivial code style error in the comment above, is this
> > > > > going to have the unintended side effect of initializing as 0 all the
> > > > > emulated registers between 0x40 and 0xff, that previously were probably
> > > > > passed through?
> > > > >
> > > > 
> > > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
> > >  
> > > actually there is a small change in behaviour: before your patch
> > > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> > > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> > > reg_grp_entry corresponding to "Header Type0 reg group" and then
> > > pt_find_reg would return NULL.
> > > This case seems to be handled correctly and bring to the same results
> > > in both pt_pci_write_config and pt_pci_read_config.
> > > 
> > > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> > > group" only it if really is part of this group otherwise it should be in
> > > its own separate group.
> > 
> > The pci pass through groups have been designed to pass through pci capabilities
> > from the device. You can't really create a group for something which isn't a pci
> > capability.
> > 
> > I have noted the change of behavior but that doesn't have any impact on what we
> > will return to the guest so I think it fine.
>  
> in that case, ack

Ian,

Could you apply this patch please?

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 14:52:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 14:52:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsF40-0005M9-4A; Tue, 31 Jan 2012 14:52:04 +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 1RsF3y-0005L3-Rz
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 14:52:03 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328021516!11947412!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15982 invoked from network); 31 Jan 2012 14:51:56 -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;
	31 Jan 2012 14:51:56 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393048"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 14:51:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 14:51:54 +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 1RsF3q-0004rb-3D;
	Tue, 31 Jan 2012 14:51:54 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RsF3e-0006NG-Do;
	Tue, 31 Jan 2012 14:51:42 +0000
Date: Tue, 31 Jan 2012 14:51:42 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Message-ID: <20120131145142.GB23556@spongy.cam.xci-test.com>
References: <1326372062-20905-1-git-send-email-jean.guyader@eu.citrix.com>
	<20120112124254.GB11262@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201121416200.3150@kaball-desktop>
	<CAEBdQ90KcOi6RvbUYcyXKZPpsKWvu2ERg35eBZosKNuUrCGabQ@mail.gmail.com>
	<alpine.DEB.2.00.1201171447450.3150@kaball-desktop>
	<20120117162414.GA25281@spongy.cam.xci-test.com>
	<alpine.DEB.2.00.1201171634300.3150@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201171634300.3150@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"allen.m.kay@intel.com" <allen.m.kay@intel.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>,
	"konrad@darnok.org" <konrad@darnok.org>,
	Jean Guyader <jean.guyader@gmail.com>
Subject: Re: [Xen-devel] [PATCH] qemu-xen: Intel GPU passthrough,
 fix OpRegion mapping. (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 17/01 04:34, Stefano Stabellini wrote:
> On Tue, 17 Jan 2012, Jean Guyader wrote:
> > On 17/01 02:51, Stefano Stabellini wrote:
> > > On Mon, 16 Jan 2012, Jean Guyader wrote:
> > > > On 12 January 2012 14:34, Stefano Stabellini
> > > > <stefano.stabellini@eu.citrix.com> wrote:
> > > > > On Thu, 12 Jan 2012, Jean Guyader wrote:
> > > > >> On 12/01 12:41, 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>
> > > > >> commit a6036bee23bb338e6cf48e9f0d75ff0845f8cfe3
> > > > >> Author: Jean Guyader <jean.guyader@eu.citrix.com>
> > > > >> Date: ?? Wed Nov 23 07:53:30 2011 +0000
> > > > >>
> > > > >> ?? ?? 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.
> > > > >>
> > > > >> ?? ?? 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.
> > > > >>
> > > > >> diff --git a/hw/pass-through.c b/hw/pass-through.c
> > > > >> index dbe8804..7ee3c61 100644
> > > > >> --- a/hw/pass-through.c
> > > > >> +++ b/hw/pass-through.c
> > > > >> @@ -238,6 +238,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).
> > > > >> @@ -444,6 +452,16 @@ 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,
> > > > >> ?? ?? ??},
> > > > >> + ?? ??/* Intel IGFX OpRegion reg */
> > > > >> + ?? ??{
> > > > >> + ?? ?? ?? ??.offset ?? ?? = PCI_INTEL_OPREGION,
> > > > >> + ?? ?? ?? ??.size ?? ?? ?? = 4,
> > > > >> + ?? ?? ?? ??.init_val ?? = 0,
> > > > >> + ?? ?? ?? ??.no_wb ?? ?? ??= 1,
> > > > >> + ?? ?? ?? ??.u.dw.read ?? = pt_intel_opregion_read,
> > > > >> + ?? ?? ?? ??.u.dw.write ??= pt_intel_opregion_write,
> > > > >> + ?? ?? ?? ??.u.dw.restore ??= NULL,
> > > > >> + ?? ??},
> > > > >> ?? ?? ??{
> > > > >> ?? ?? ?? ?? ??.size = 0,
> > > > >> ?? ?? ??},
> > > > >> @@ -737,7 +755,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 */
> > > > >> @@ -3006,6 +3024,19 @@ 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)
> > > > >> +{
> > > > >> + ?? ??/*
> > > > >> + ?? ??** By default we will trap up to 0x40 in the cfg space.
> > > > >> + ?? ??** If an intel device is pass through we need to trap 0xfc,
> > > > >> + ?? ??** therefore the size should be 0xff.
> > > > >> + ?? ??*/
> > > > >> + ?? ??if (igd_passthru)
> > > > >> + ?? ?? ?? ??return 0xFF;
> > > > >> + ?? ??return grp_reg->grp_size;
> > > > >> +}
> > > > >
> > > > > Apart from the trivial code style error in the comment above, is this
> > > > > going to have the unintended side effect of initializing as 0 all the
> > > > > emulated registers between 0x40 and 0xff, that previously were probably
> > > > > passed through?
> > > > >
> > > > 
> > > > Based on how pt_find_reg_grp is implemented that doesn't make any difference.
> > >  
> > > actually there is a small change in behaviour: before your patch
> > > pt_find_reg_grp would return NULL for any cfg register between 0x40 and
> > > 0xff. Now if igd_passthru is set pt_find_reg_grp would return the
> > > reg_grp_entry corresponding to "Header Type0 reg group" and then
> > > pt_find_reg would return NULL.
> > > This case seems to be handled correctly and bring to the same results
> > > in both pt_pci_write_config and pt_pci_read_config.
> > > 
> > > In any case PCI_INTEL_OPREGION should be part of "Header Type0 reg
> > > group" only it if really is part of this group otherwise it should be in
> > > its own separate group.
> > 
> > The pci pass through groups have been designed to pass through pci capabilities
> > from the device. You can't really create a group for something which isn't a pci
> > capability.
> > 
> > I have noted the change of behavior but that doesn't have any impact on what we
> > will return to the guest so I think it fine.
>  
> in that case, ack

Ian,

Could you apply this patch please?

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:02:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:02:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFDf-0005vI-7U; Tue, 31 Jan 2012 15:02: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 1RsFDc-0005vD-RC
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:02:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328022075!62455789!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22938 invoked from network); 31 Jan 2012 15:01:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 15:01:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:01:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 15:01:59 +0000
Date: Tue, 31 Jan 2012 15:03:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2089809799-1328022236=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-2089809799-1328022236=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
> On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>       Introduce a new save_id to save/restore toolstack specific extra
>       information.
> 
>       Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>       ---
>  tools/libxc/xc_domain_restore.c |   32 +++++++++++++++++++++++++++++++-
>  tools/libxc/xc_domain_save.c    |   17 +++++++++++++++++
>  tools/libxc/xenguest.h          |   23 ++++++++++++++++++++++-
>  tools/libxc/xg_save_restore.h   |    1 +
>  tools/libxl/libxl_dom.c         |    2 +-
>  tools/xcutils/xc_restore.c      |    2 +-
>  6 files changed, 73 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..ead3df4 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -45,6 +45,8 @@ struct restore_ctx {
>     int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
>     int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
>     struct domain_info_context dinfo;
> +    uint8_t *toolstack_data;
> +    uint32_t toolstack_data_len;
>  };
> 
> 
> This is still leaking speculative state. You have only moved the restore code but
> you are still reading the (potentially discardable) state into a global ctx structure.
> 
> Take a look at the tailbuf code right below the pagebuf_get() call in xc_domain_restore().
> It reads the tailbuf onto a temporary buffer and then copies it onto the main one.
> This way, if an error occurs while receiving data, one can completely discard the current
> checkpoint (pagebuf & tmptailbuf) and restore from the previous one (tailbuf).
> 
> You could have a similar *consistent buffer* in the xc_domain_restore function itself, and copy the toolstack
> stuff into it before starting to buffer a new checkpoint. Perhaps something like the snippet below?
> 
> + toolstack_data = realloc(pagebuf.toolstack_data_len)
> + memcpy(toolstack_data, pagebuf.toolstack_data, pagebuf.toolstack_data_len);
> if ( ctx->last_checkpoint )
> 
> Though, this would incur two reallocs (once in pagebuf_get and once more in the main loop).
> 
> If there is a maximum size for this buffer, I would suggest mallocing it once and for all, and just
> memcpy it.
> 

Even though the current toolstack data is tiny, I don't want to realloc
a potentially big buffer twice or memcpy'ing more than necessary.
I don't want to add a maximum size either.
What if I add two new arguments to pagebuf_get_one: a pointer to the
buffer to be malloc'ed and the length? Like it was done with the
callbacks argument in the previous version of this patch?



>       @@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
>               }
>               return pagebuf_get_one(xch, ctx, buf, fd, dom);
> 
> +    case XC_SAVE_ID_TOOLSTACK:
> +        {
> +            RDEXACT(fd, &ctx->toolstack_data_len,
> +                    sizeof(ctx->toolstack_data_len));
> +            ctx->toolstack_data = (uint8_t*) malloc(ctx->toolstack_data_len);
> +            if ( ctx->toolstack_data == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, ctx->toolstack_data, ctx->toolstack_data_len);
> 
> 
> Basically this becomes,
>  RDEXACT(fd, &buf->toolstack_data_len,...)
> buf->toolstack_data = (uint8_t *)realloc(buf->toolstack_data_len, 0)
> RDEXACT(fd, buf->toolstack_data, buf->toolstack_data_len)
> 
> And please do realloc. Since the pagebuf_get_one code is called repeatedly
> by the main loop, using malloc would result in loads of memory leaks.
> 

I presume that this buf pointer would be an argument passed to
pagebuf_get_one.
In this case, I don't suppose I need to memcpy anything anywhere, do I?
Later on, in finish_hvm, I'll just do:



   if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
   {
       if ( callbacks->toolstack_restore(dom,
                   buf->toolstack_data, buf->toolstack_data_len,
                   callbacks->data) < 0 )
       {
           PERROR("error calling toolstack_restore");
           free(buf->toolstack_data);
           buf->toolstack_data = NULL;
           buf->toolstack_data_len = 0;
           goto out;
       }
   }
   free(buf->toolstack_data);
   buf->toolstack_data = NULL;
   buf->toolstack_data_len = 0;


--8323329-2089809799-1328022236=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-2089809799-1328022236=:3196--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:02:20 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:02:20 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFDf-0005vI-7U; Tue, 31 Jan 2012 15:02: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 1RsFDc-0005vD-RC
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:02:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-9.tower-27.messagelabs.com!1328022075!62455789!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22938 invoked from network); 31 Jan 2012 15:01:15 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 15:01:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393395"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:01:59 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 15:01:59 +0000
Date: Tue, 31 Jan 2012 15:03:41 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-2089809799-1328022236=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-2089809799-1328022236=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
> On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
>       Introduce a new save_id to save/restore toolstack specific extra
>       information.
> 
>       Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>       ---
>  tools/libxc/xc_domain_restore.c |   32 +++++++++++++++++++++++++++++++-
>  tools/libxc/xc_domain_save.c    |   17 +++++++++++++++++
>  tools/libxc/xenguest.h          |   23 ++++++++++++++++++++++-
>  tools/libxc/xg_save_restore.h   |    1 +
>  tools/libxl/libxl_dom.c         |    2 +-
>  tools/xcutils/xc_restore.c      |    2 +-
>  6 files changed, 73 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..ead3df4 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -45,6 +45,8 @@ struct restore_ctx {
>     int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
>     int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
>     struct domain_info_context dinfo;
> +    uint8_t *toolstack_data;
> +    uint32_t toolstack_data_len;
>  };
> 
> 
> This is still leaking speculative state. You have only moved the restore code but
> you are still reading the (potentially discardable) state into a global ctx structure.
> 
> Take a look at the tailbuf code right below the pagebuf_get() call in xc_domain_restore().
> It reads the tailbuf onto a temporary buffer and then copies it onto the main one.
> This way, if an error occurs while receiving data, one can completely discard the current
> checkpoint (pagebuf & tmptailbuf) and restore from the previous one (tailbuf).
> 
> You could have a similar *consistent buffer* in the xc_domain_restore function itself, and copy the toolstack
> stuff into it before starting to buffer a new checkpoint. Perhaps something like the snippet below?
> 
> + toolstack_data = realloc(pagebuf.toolstack_data_len)
> + memcpy(toolstack_data, pagebuf.toolstack_data, pagebuf.toolstack_data_len);
> if ( ctx->last_checkpoint )
> 
> Though, this would incur two reallocs (once in pagebuf_get and once more in the main loop).
> 
> If there is a maximum size for this buffer, I would suggest mallocing it once and for all, and just
> memcpy it.
> 

Even though the current toolstack data is tiny, I don't want to realloc
a potentially big buffer twice or memcpy'ing more than necessary.
I don't want to add a maximum size either.
What if I add two new arguments to pagebuf_get_one: a pointer to the
buffer to be malloc'ed and the length? Like it was done with the
callbacks argument in the previous version of this patch?



>       @@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
>               }
>               return pagebuf_get_one(xch, ctx, buf, fd, dom);
> 
> +    case XC_SAVE_ID_TOOLSTACK:
> +        {
> +            RDEXACT(fd, &ctx->toolstack_data_len,
> +                    sizeof(ctx->toolstack_data_len));
> +            ctx->toolstack_data = (uint8_t*) malloc(ctx->toolstack_data_len);
> +            if ( ctx->toolstack_data == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, ctx->toolstack_data, ctx->toolstack_data_len);
> 
> 
> Basically this becomes,
>  RDEXACT(fd, &buf->toolstack_data_len,...)
> buf->toolstack_data = (uint8_t *)realloc(buf->toolstack_data_len, 0)
> RDEXACT(fd, buf->toolstack_data, buf->toolstack_data_len)
> 
> And please do realloc. Since the pagebuf_get_one code is called repeatedly
> by the main loop, using malloc would result in loads of memory leaks.
> 

I presume that this buf pointer would be an argument passed to
pagebuf_get_one.
In this case, I don't suppose I need to memcpy anything anywhere, do I?
Later on, in finish_hvm, I'll just do:



   if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
   {
       if ( callbacks->toolstack_restore(dom,
                   buf->toolstack_data, buf->toolstack_data_len,
                   callbacks->data) < 0 )
       {
           PERROR("error calling toolstack_restore");
           free(buf->toolstack_data);
           buf->toolstack_data = NULL;
           buf->toolstack_data_len = 0;
           goto out;
       }
   }
   free(buf->toolstack_data);
   buf->toolstack_data = NULL;
   buf->toolstack_data_len = 0;


--8323329-2089809799-1328022236=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-2089809799-1328022236=:3196--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:07:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:07:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFIK-00064a-0S; Tue, 31 Jan 2012 15:06:52 +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 1RsFII-00064Q-4N
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:06:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328022403!12582184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32456 invoked from network); 31 Jan 2012 15:06:44 -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;
	31 Jan 2012 15:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:06: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; Tue, 31 Jan 2012 15:06:44 +0000
Date: Tue, 31 Jan 2012 15:08:26 +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.1201311457230.3196@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-133505091-1328022521=:3196"
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-133505091-1328022521=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Tue, 31 Jan 2012, Stefano Stabellini wrote:
> On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
> > On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >       Introduce a new save_id to save/restore toolstack specific extra
> >       information.
> > 
> >       Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >       ---
> >  tools/libxc/xc_domain_restore.c |   32 +++++++++++++++++++++++++++++++-
> >  tools/libxc/xc_domain_save.c    |   17 +++++++++++++++++
> >  tools/libxc/xenguest.h          |   23 ++++++++++++++++++++++-
> >  tools/libxc/xg_save_restore.h   |    1 +
> >  tools/libxl/libxl_dom.c         |    2 +-
> >  tools/xcutils/xc_restore.c      |    2 +-
> >  6 files changed, 73 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> > index 3fda6f8..ead3df4 100644
> > --- a/tools/libxc/xc_domain_restore.c
> > +++ b/tools/libxc/xc_domain_restore.c
> > @@ -45,6 +45,8 @@ struct restore_ctx {
> >     int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
> >     int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
> >     struct domain_info_context dinfo;
> > +    uint8_t *toolstack_data;
> > +    uint32_t toolstack_data_len;
> >  };
> > 
> > 
> > This is still leaking speculative state. You have only moved the restore code but
> > you are still reading the (potentially discardable) state into a global ctx structure.
> > 
> > Take a look at the tailbuf code right below the pagebuf_get() call in xc_domain_restore().
> > It reads the tailbuf onto a temporary buffer and then copies it onto the main one.
> > This way, if an error occurs while receiving data, one can completely discard the current
> > checkpoint (pagebuf & tmptailbuf) and restore from the previous one (tailbuf).
> > 
> > You could have a similar *consistent buffer* in the xc_domain_restore function itself, and copy the toolstack
> > stuff into it before starting to buffer a new checkpoint. Perhaps something like the snippet below?
> > 
> > + toolstack_data = realloc(pagebuf.toolstack_data_len)
> > + memcpy(toolstack_data, pagebuf.toolstack_data, pagebuf.toolstack_data_len);
> > if ( ctx->last_checkpoint )
> > 
> > Though, this would incur two reallocs (once in pagebuf_get and once more in the main loop).
> > 
> > If there is a maximum size for this buffer, I would suggest mallocing it once and for all, and just
> > memcpy it.
> > 
> 
> Even though the current toolstack data is tiny, I don't want to realloc
> a potentially big buffer twice or memcpy'ing more than necessary.
> I don't want to add a maximum size either.
> What if I add two new arguments to pagebuf_get_one: a pointer to the
> buffer to be malloc'ed and the length? Like it was done with the
> callbacks argument in the previous version of this patch?
> 
> 
> 
> >       @@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
> >               }
> >               return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > 
> > +    case XC_SAVE_ID_TOOLSTACK:
> > +        {
> > +            RDEXACT(fd, &ctx->toolstack_data_len,
> > +                    sizeof(ctx->toolstack_data_len));
> > +            ctx->toolstack_data = (uint8_t*) malloc(ctx->toolstack_data_len);
> > +            if ( ctx->toolstack_data == NULL )
> > +            {
> > +                PERROR("error memory allocation");
> > +                return -1;
> > +            }
> > +            RDEXACT(fd, ctx->toolstack_data, ctx->toolstack_data_len);
> > 
> > 
> > Basically this becomes,
> >  RDEXACT(fd, &buf->toolstack_data_len,...)
> > buf->toolstack_data = (uint8_t *)realloc(buf->toolstack_data_len, 0)
> > RDEXACT(fd, buf->toolstack_data, buf->toolstack_data_len)
> > 
> > And please do realloc. Since the pagebuf_get_one code is called repeatedly
> > by the main loop, using malloc would result in loads of memory leaks.
> > 
> 
> I presume that this buf pointer would be an argument passed to
> pagebuf_get_one.
> In this case, I don't suppose I need to memcpy anything anywhere, do I?
> Later on, in finish_hvm, I'll just do:
> 
> 
> 
>    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
>    {
>        if ( callbacks->toolstack_restore(dom,
>                    buf->toolstack_data, buf->toolstack_data_len,
>                    callbacks->data) < 0 )
>        {
>            PERROR("error calling toolstack_restore");
>            free(buf->toolstack_data);
>            buf->toolstack_data = NULL;
>            buf->toolstack_data_len = 0;
>            goto out;
>        }
>    }
>    free(buf->toolstack_data);
>    buf->toolstack_data = NULL;
>    buf->toolstack_data_len = 0;


Sorry about this, I configured my mailer not to send emails in UTF-8
because they can be the cause of nasty python bugs with spaces and tabs.
Let me write this code snippet again:

    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
    {
        if ( callbacks->toolstack_restore(dom,
                    buf->toolstack_data, buf->toolstack_data_len,
                    callbacks->data) < 0 )
        {
            PERROR("error calling toolstack_restore");
            free(buf->toolstack_data);
            buf->toolstack_data = NULL;
            buf->toolstack_data_len = 0;
            goto out;
        }
    }
    free(buf->toolstack_data);
    buf->toolstack_data = NULL;
    buf->toolstack_data_len = 0;

--8323329-133505091-1328022521=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-133505091-1328022521=:3196--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:07:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:07:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFIK-00064a-0S; Tue, 31 Jan 2012 15:06:52 +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 1RsFII-00064Q-4N
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:06:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328022403!12582184!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32456 invoked from network); 31 Jan 2012 15:06:44 -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;
	31 Jan 2012 15:06:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393564"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:06: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; Tue, 31 Jan 2012 15:06:44 +0000
Date: Tue, 31 Jan 2012 15:08:26 +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.1201311457230.3196@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-133505091-1328022521=:3196"
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-133505091-1328022521=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Tue, 31 Jan 2012, Stefano Stabellini wrote:
> On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
> > On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> >       Introduce a new save_id to save/restore toolstack specific extra
> >       information.
> > 
> >       Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >       ---
> >  tools/libxc/xc_domain_restore.c |   32 +++++++++++++++++++++++++++++++-
> >  tools/libxc/xc_domain_save.c    |   17 +++++++++++++++++
> >  tools/libxc/xenguest.h          |   23 ++++++++++++++++++++++-
> >  tools/libxc/xg_save_restore.h   |    1 +
> >  tools/libxl/libxl_dom.c         |    2 +-
> >  tools/xcutils/xc_restore.c      |    2 +-
> >  6 files changed, 73 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
> > index 3fda6f8..ead3df4 100644
> > --- a/tools/libxc/xc_domain_restore.c
> > +++ b/tools/libxc/xc_domain_restore.c
> > @@ -45,6 +45,8 @@ struct restore_ctx {
> >     int last_checkpoint; /* Set when we should commit to the current checkpoint when it completes. */
> >     int compressing; /* Set when sender signals that pages would be sent compressed (for Remus) */
> >     struct domain_info_context dinfo;
> > +    uint8_t *toolstack_data;
> > +    uint32_t toolstack_data_len;
> >  };
> > 
> > 
> > This is still leaking speculative state. You have only moved the restore code but
> > you are still reading the (potentially discardable) state into a global ctx structure.
> > 
> > Take a look at the tailbuf code right below the pagebuf_get() call in xc_domain_restore().
> > It reads the tailbuf onto a temporary buffer and then copies it onto the main one.
> > This way, if an error occurs while receiving data, one can completely discard the current
> > checkpoint (pagebuf & tmptailbuf) and restore from the previous one (tailbuf).
> > 
> > You could have a similar *consistent buffer* in the xc_domain_restore function itself, and copy the toolstack
> > stuff into it before starting to buffer a new checkpoint. Perhaps something like the snippet below?
> > 
> > + toolstack_data = realloc(pagebuf.toolstack_data_len)
> > + memcpy(toolstack_data, pagebuf.toolstack_data, pagebuf.toolstack_data_len);
> > if ( ctx->last_checkpoint )
> > 
> > Though, this would incur two reallocs (once in pagebuf_get and once more in the main loop).
> > 
> > If there is a maximum size for this buffer, I would suggest mallocing it once and for all, and just
> > memcpy it.
> > 
> 
> Even though the current toolstack data is tiny, I don't want to realloc
> a potentially big buffer twice or memcpy'ing more than necessary.
> I don't want to add a maximum size either.
> What if I add two new arguments to pagebuf_get_one: a pointer to the
> buffer to be malloc'ed and the length? Like it was done with the
> callbacks argument in the previous version of this patch?
> 
> 
> 
> >       @@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
> >               }
> >               return pagebuf_get_one(xch, ctx, buf, fd, dom);
> > 
> > +    case XC_SAVE_ID_TOOLSTACK:
> > +        {
> > +            RDEXACT(fd, &ctx->toolstack_data_len,
> > +                    sizeof(ctx->toolstack_data_len));
> > +            ctx->toolstack_data = (uint8_t*) malloc(ctx->toolstack_data_len);
> > +            if ( ctx->toolstack_data == NULL )
> > +            {
> > +                PERROR("error memory allocation");
> > +                return -1;
> > +            }
> > +            RDEXACT(fd, ctx->toolstack_data, ctx->toolstack_data_len);
> > 
> > 
> > Basically this becomes,
> >  RDEXACT(fd, &buf->toolstack_data_len,...)
> > buf->toolstack_data = (uint8_t *)realloc(buf->toolstack_data_len, 0)
> > RDEXACT(fd, buf->toolstack_data, buf->toolstack_data_len)
> > 
> > And please do realloc. Since the pagebuf_get_one code is called repeatedly
> > by the main loop, using malloc would result in loads of memory leaks.
> > 
> 
> I presume that this buf pointer would be an argument passed to
> pagebuf_get_one.
> In this case, I don't suppose I need to memcpy anything anywhere, do I?
> Later on, in finish_hvm, I'll just do:
> 
> 
> 
>    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
>    {
>        if ( callbacks->toolstack_restore(dom,
>                    buf->toolstack_data, buf->toolstack_data_len,
>                    callbacks->data) < 0 )
>        {
>            PERROR("error calling toolstack_restore");
>            free(buf->toolstack_data);
>            buf->toolstack_data = NULL;
>            buf->toolstack_data_len = 0;
>            goto out;
>        }
>    }
>    free(buf->toolstack_data);
>    buf->toolstack_data = NULL;
>    buf->toolstack_data_len = 0;


Sorry about this, I configured my mailer not to send emails in UTF-8
because they can be the cause of nasty python bugs with spaces and tabs.
Let me write this code snippet again:

    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
    {
        if ( callbacks->toolstack_restore(dom,
                    buf->toolstack_data, buf->toolstack_data_len,
                    callbacks->data) < 0 )
        {
            PERROR("error calling toolstack_restore");
            free(buf->toolstack_data);
            buf->toolstack_data = NULL;
            buf->toolstack_data_len = 0;
            goto out;
        }
    }
    free(buf->toolstack_data);
    buf->toolstack_data = NULL;
    buf->toolstack_data_len = 0;

--8323329-133505091-1328022521=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-133505091-1328022521=:3196--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:07:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFJA-00068m-MY; Tue, 31 Jan 2012 15:07:44 +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 1RsFJ9-00068X-EZ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:07:43 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328022407!54777925!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21625 invoked from network); 31 Jan 2012 15:06:48 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 15:06:48 -0000
Received: by wibhm2 with SMTP id hm2so78444wib.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 07:07:41 -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
	:references:in-reply-to:content-type;
	bh=x1a+WIxy0hcV/ZjI7rzcTGzvmWUjyUzUtRgcP7OOrgQ=;
	b=YmBskorGUU757E6Vu3ilToV7OfQszSn/6Uac9YF2tQ2J/mLYsNmkx/GV7lNgdpPv4w
	2L3I42L2XzFjARoUq94LdhaLqU8hjdrMHcE/KfF0x9rRl9EJPCnFxSjPpvXPAD8A3M50
	Fo/N71imUJd1ci9FzqUIYuZQm3joDgUq50umY=
Received: by 10.180.107.68 with SMTP id ha4mr9397449wib.9.1328022461666;
	Tue, 31 Jan 2012 07:07:41 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id d9sm37935546wiy.2.2012.01.31.07.07.39
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 07:07:40 -0800 (PST)
Message-ID: <4F2803A3.60507@xen.org>
Date: Tue, 31 Jan 2012 15:07:15 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, netlogic.xen@gmail.com
References: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
In-Reply-To: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
Subject: Re: [Xen-devel] MIPS port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6828358242859683760=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============6828358242859683760==
Content-Type: multipart/alternative;
 boundary="------------060606060503060203070105"

This is a multi-part message in MIME format.
--------------060606060503060203070105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Prasad,

I just saw the press announcement. Congratulations.

Seems nobody has come back regarding submitting changes. That is 
probably because you baselined on Xen 3.4. I guess we could look into 
publishing the code as a tarball, but to be honest this has not worked 
that well for the Xen ARM project and Samsung is going through the 
process of moving all the code into a repo.

I would much rather prefer if we created a repo (that could be baselined 
from the 3.4 branch). Basically, I wanted to double check whether you 
intend to move to xen-unstable and PVOPS and in what timeframe (months, 
years). It may make sense for you guys to send somebody to the Hackathon 
in Santa Clara - Konrad who runs the PVOPS project I think will be 
there. And many of the other devs too. And so will I. I understand you 
are based in Santa Clara?

Sign up here http://wiki.xen.org/wiki/Hackathon/March2012

It would also be great if you could introduce me to some marketing 
people. I want to make sure that you are listed at 
http://www.xen.org/community/vendors/XenProductsPage.html ; I also 
wanted to discuss other ways how Xen.org can help promote you guys as 
well as how you can help Xen (it is not only about code contributions).

Regards
Lars

On 05/01/2012 23:38, Prasad Boddupalli wrote:
> Hello All,
>
> About 3 weeks back, after resolving some console related issues, SMP 
> versions of PV dom0 and domU could be booted on our MIPS boards. Our 
> current version of MIPS Xen is based on an old version (3.4.0) and are 
> currently in the process of moving the changes to the unstable branch. 
> The Linux changes are not part of pv-ops infrastructure.
>
> Although we have our simulator, the plan is to get the above running 
> on Qemu to enable others try out the MIPS version of Xen. Linux could 
> be released as a tarball for the present.
>
> The performance of applications such as hackbench is a little 
> unsatisfactory when run on PV Linux (due to frequent traps in the 
> syscall path). So, we are also working on performance improvements, 
> which probably could go on in parallel with the submission to open source.
>
> Any suggestions with regard to submitting our changes are welcome.
>
> Prasad.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


--------------060606060503060203070105
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">
    Prasad,<br>
    <br>
    I just saw the press announcement. Congratulations. <br>
    <br>
    Seems nobody has come back regarding submitting changes. That is
    probably because you baselined on Xen 3.4. I guess we could look
    into publishing the code as a tarball, but to be honest this has not
    worked that well for the Xen ARM project and Samsung is going
    through the process of moving all the code into a repo. <br>
    <br>
    I would much rather prefer if we created a repo (that could be
    baselined from the 3.4 branch). Basically, I wanted to double check
    whether you intend to move to xen-unstable and PVOPS and in what
    timeframe (months, years). It may make sense for you guys to send
    somebody to the Hackathon in Santa Clara - Konrad who runs the PVOPS
    project I think will be there. And many of the other devs too. And
    so will I. I understand you are based in Santa Clara?<br>
    <br>
    Sign up here <a href="http://wiki.xen.org/wiki/Hackathon/March2012">http://wiki.xen.org/wiki/Hackathon/March2012</a><br>
    <br>
    It would also be great if you could introduce me to some marketing
    people. I want to make sure that you are listed at
    <a class="moz-txt-link-freetext" href="http://www.xen.org/community/vendors/XenProductsPage.html">http://www.xen.org/community/vendors/XenProductsPage.html</a> ; I also
    wanted to discuss other ways how Xen.org can help promote you guys
    as well as how you can help Xen (it is not only about code
    contributions).<br>
    <br>
    Regards<br>
    Lars<br>
    <br>
    On 05/01/2012 23:38, Prasad Boddupalli wrote:
    <blockquote
cite="mid:CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com"
      type="cite">Hello All,<br>
      <br>
      About 3 weeks back, after resolving some console related issues,
      SMP versions of PV dom0 and domU could be booted on our MIPS
      boards. Our current version of MIPS Xen is based on an old version
      (3.4.0) and are currently in the process of moving the changes to
      the unstable branch. The Linux changes are not part of pv-ops
      infrastructure.<br>
      <br>
      Although we have our simulator, the plan is to get the above
      running on Qemu to enable others try out the MIPS version of Xen.
      Linux could be released as a tarball for the present.<br>
      <br>
      The performance of applications such as hackbench is a little
      unsatisfactory when run on PV Linux (due to frequent traps in the
      syscall path). So, we are also working on performance
      improvements, which probably could go on in parallel with the
      submission to open source.<br>
      <br>
      Any suggestions with regard to submitting our changes are welcome.<br>
      <br>
      Prasad.<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <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>
    <br>
  </body>
</html>

--------------060606060503060203070105--


--===============6828358242859683760==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6828358242859683760==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:07:59 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:07:59 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFJA-00068m-MY; Tue, 31 Jan 2012 15:07:44 +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 1RsFJ9-00068X-EZ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:07:43 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328022407!54777925!1
X-Originating-IP: [209.85.212.171]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21625 invoked from network); 31 Jan 2012 15:06:48 -0000
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com)
	(209.85.212.171)
	by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 15:06:48 -0000
Received: by wibhm2 with SMTP id hm2so78444wib.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 07:07:41 -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
	:references:in-reply-to:content-type;
	bh=x1a+WIxy0hcV/ZjI7rzcTGzvmWUjyUzUtRgcP7OOrgQ=;
	b=YmBskorGUU757E6Vu3ilToV7OfQszSn/6Uac9YF2tQ2J/mLYsNmkx/GV7lNgdpPv4w
	2L3I42L2XzFjARoUq94LdhaLqU8hjdrMHcE/KfF0x9rRl9EJPCnFxSjPpvXPAD8A3M50
	Fo/N71imUJd1ci9FzqUIYuZQm3joDgUq50umY=
Received: by 10.180.107.68 with SMTP id ha4mr9397449wib.9.1328022461666;
	Tue, 31 Jan 2012 07:07:41 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id d9sm37935546wiy.2.2012.01.31.07.07.39
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 07:07:40 -0800 (PST)
Message-ID: <4F2803A3.60507@xen.org>
Date: Tue, 31 Jan 2012 15:07:15 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: xen-devel@lists.xensource.com, netlogic.xen@gmail.com
References: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
In-Reply-To: <CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com>
Subject: Re: [Xen-devel] MIPS port
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6828358242859683760=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This is a multi-part message in MIME format.
--===============6828358242859683760==
Content-Type: multipart/alternative;
 boundary="------------060606060503060203070105"

This is a multi-part message in MIME format.
--------------060606060503060203070105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Prasad,

I just saw the press announcement. Congratulations.

Seems nobody has come back regarding submitting changes. That is 
probably because you baselined on Xen 3.4. I guess we could look into 
publishing the code as a tarball, but to be honest this has not worked 
that well for the Xen ARM project and Samsung is going through the 
process of moving all the code into a repo.

I would much rather prefer if we created a repo (that could be baselined 
from the 3.4 branch). Basically, I wanted to double check whether you 
intend to move to xen-unstable and PVOPS and in what timeframe (months, 
years). It may make sense for you guys to send somebody to the Hackathon 
in Santa Clara - Konrad who runs the PVOPS project I think will be 
there. And many of the other devs too. And so will I. I understand you 
are based in Santa Clara?

Sign up here http://wiki.xen.org/wiki/Hackathon/March2012

It would also be great if you could introduce me to some marketing 
people. I want to make sure that you are listed at 
http://www.xen.org/community/vendors/XenProductsPage.html ; I also 
wanted to discuss other ways how Xen.org can help promote you guys as 
well as how you can help Xen (it is not only about code contributions).

Regards
Lars

On 05/01/2012 23:38, Prasad Boddupalli wrote:
> Hello All,
>
> About 3 weeks back, after resolving some console related issues, SMP 
> versions of PV dom0 and domU could be booted on our MIPS boards. Our 
> current version of MIPS Xen is based on an old version (3.4.0) and are 
> currently in the process of moving the changes to the unstable branch. 
> The Linux changes are not part of pv-ops infrastructure.
>
> Although we have our simulator, the plan is to get the above running 
> on Qemu to enable others try out the MIPS version of Xen. Linux could 
> be released as a tarball for the present.
>
> The performance of applications such as hackbench is a little 
> unsatisfactory when run on PV Linux (due to frequent traps in the 
> syscall path). So, we are also working on performance improvements, 
> which probably could go on in parallel with the submission to open source.
>
> Any suggestions with regard to submitting our changes are welcome.
>
> Prasad.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


--------------060606060503060203070105
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">
    Prasad,<br>
    <br>
    I just saw the press announcement. Congratulations. <br>
    <br>
    Seems nobody has come back regarding submitting changes. That is
    probably because you baselined on Xen 3.4. I guess we could look
    into publishing the code as a tarball, but to be honest this has not
    worked that well for the Xen ARM project and Samsung is going
    through the process of moving all the code into a repo. <br>
    <br>
    I would much rather prefer if we created a repo (that could be
    baselined from the 3.4 branch). Basically, I wanted to double check
    whether you intend to move to xen-unstable and PVOPS and in what
    timeframe (months, years). It may make sense for you guys to send
    somebody to the Hackathon in Santa Clara - Konrad who runs the PVOPS
    project I think will be there. And many of the other devs too. And
    so will I. I understand you are based in Santa Clara?<br>
    <br>
    Sign up here <a href="http://wiki.xen.org/wiki/Hackathon/March2012">http://wiki.xen.org/wiki/Hackathon/March2012</a><br>
    <br>
    It would also be great if you could introduce me to some marketing
    people. I want to make sure that you are listed at
    <a class="moz-txt-link-freetext" href="http://www.xen.org/community/vendors/XenProductsPage.html">http://www.xen.org/community/vendors/XenProductsPage.html</a> ; I also
    wanted to discuss other ways how Xen.org can help promote you guys
    as well as how you can help Xen (it is not only about code
    contributions).<br>
    <br>
    Regards<br>
    Lars<br>
    <br>
    On 05/01/2012 23:38, Prasad Boddupalli wrote:
    <blockquote
cite="mid:CAPw52B_k1UUqBV0AtxHNfdsBGgAF9JRb7P2rtoQOUGE1yW2Htw@mail.gmail.com"
      type="cite">Hello All,<br>
      <br>
      About 3 weeks back, after resolving some console related issues,
      SMP versions of PV dom0 and domU could be booted on our MIPS
      boards. Our current version of MIPS Xen is based on an old version
      (3.4.0) and are currently in the process of moving the changes to
      the unstable branch. The Linux changes are not part of pv-ops
      infrastructure.<br>
      <br>
      Although we have our simulator, the plan is to get the above
      running on Qemu to enable others try out the MIPS version of Xen.
      Linux could be released as a tarball for the present.<br>
      <br>
      The performance of applications such as hackbench is a little
      unsatisfactory when run on PV Linux (due to frequent traps in the
      syscall path). So, we are also working on performance
      improvements, which probably could go on in parallel with the
      submission to open source.<br>
      <br>
      Any suggestions with regard to submitting our changes are welcome.<br>
      <br>
      Prasad.<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <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>
    <br>
  </body>
</html>

--------------060606060503060203070105--


--===============6828358242859683760==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6828358242859683760==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:11:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:11:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFMH-0006Mg-EJ; Tue, 31 Jan 2012 15:10:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsFMG-0006MX-9v
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:10:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328022594!59153841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1229 invoked from network); 31 Jan 2012 15:09:54 -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;
	31 Jan 2012 15:09:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:10:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 15:10:13 +0000
Date: Tue, 31 Jan 2012 15:12:05 +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: <20263.65096.503704.448913@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201311511360.3196@kaball-desktop>
References: <osstest-11601-mainreport@xen.org>
	<1327569695.26983.23.camel@zakaz.uk.xensource.com>
	<20263.65096.503704.448913@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] [xen-unstable test] 11601: 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

On Tue, 31 Jan 2012, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> > If you are not amenable to having the harness fallback to xl
> > button-press/trigger power automatically how about something like the
> > following patch with the proviso that it is up to the harness to ensure
> > that a guest is configured appropriately such that ACPI power and reset
> > events map to shutdown and reboot respectively?
> > 
> > (patch applies on top of my updated"libxl: remove libxl_button_press in
> > favour of libxl_send_trigger" patch from earlier in the week)
> ...
> > xl: allow enable automatic fallback to ACPI events if PV control not available.
> > 
> > Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
> > reset event to be sent to the guest in the event that the guest does not
> > support the PV control interface.
> > 
> > This is not the default because the response to these triggers is an
> > guest-internal configuration.
> 
> I'm happy with this, but then I would have been happy with this being
> the default.
> 
> Certainly I think this is a good start, so:
> 

I think it is a good compromise.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:11:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:11:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFMH-0006Mg-EJ; Tue, 31 Jan 2012 15:10:57 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsFMG-0006MX-9v
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:10:56 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328022594!59153841!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1229 invoked from network); 31 Jan 2012 15:09:54 -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;
	31 Jan 2012 15:09:54 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10393798"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:10:13 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 15:10:13 +0000
Date: Tue, 31 Jan 2012 15:12:05 +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: <20263.65096.503704.448913@mariner.uk.xensource.com>
Message-ID: <alpine.DEB.2.00.1201311511360.3196@kaball-desktop>
References: <osstest-11601-mainreport@xen.org>
	<1327569695.26983.23.camel@zakaz.uk.xensource.com>
	<20263.65096.503704.448913@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] [xen-unstable test] 11601: 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

On Tue, 31 Jan 2012, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> > If you are not amenable to having the harness fallback to xl
> > button-press/trigger power automatically how about something like the
> > following patch with the proviso that it is up to the harness to ensure
> > that a guest is configured appropriately such that ACPI power and reset
> > events map to shutdown and reboot respectively?
> > 
> > (patch applies on top of my updated"libxl: remove libxl_button_press in
> > favour of libxl_send_trigger" patch from earlier in the week)
> ...
> > xl: allow enable automatic fallback to ACPI events if PV control not available.
> > 
> > Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
> > reset event to be sent to the guest in the event that the guest does not
> > support the PV control interface.
> > 
> > This is not the default because the response to these triggers is an
> > guest-internal configuration.
> 
> I'm happy with this, but then I would have been happy with this being
> the default.
> 
> Certainly I think this is a good start, so:
> 

I think it is a good compromise.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:28:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFcv-0006kv-3z; Tue, 31 Jan 2012 15:28: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 1RsFct-0006kY-F7
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:28:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328023681!13102750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8119 invoked from network); 31 Jan 2012 15:28:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 15:28:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10394627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:28: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, 31 Jan 2012 15:28: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
	1RsFcm-00054O-UP; Tue, 31 Jan 2012 15:28:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsFcm-0004Ln-SD;
	Tue, 31 Jan 2012 15:28:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20264.2176.835843.913573@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 15:28:00 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <3101b9483229b61afe49.1327337140@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
	<3101b9483229b61afe49.1327337140@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 17 of 20] libxl: move device model selection
 variables to b_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH 17 of 20] libxl: move device model selection variables to b_info"):
> libxl: move device model selection variables to b_info.
> 
> Currently we have one set of device model version (and associated)
> variables.  However we can actually have two device models (stub
> device model + non-stub PV device model) which need not necessarily
> be the same version. Perhaps this needs more thought.

Your explanation here isn't entirely clear I think.  AFAICT from
reading the code, both before and after this patch we assume that both
device models are of the same version and there is only one version
knob to twiddle in the config file.

But I didn't peer into the whole thing in detail...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:28:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:28:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFcv-0006kv-3z; Tue, 31 Jan 2012 15:28: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 1RsFct-0006kY-F7
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:28:07 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328023681!13102750!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8119 invoked from network); 31 Jan 2012 15:28:01 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 15:28:01 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10394627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:28: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, 31 Jan 2012 15:28: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
	1RsFcm-00054O-UP; Tue, 31 Jan 2012 15:28:00 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsFcm-0004Ln-SD;
	Tue, 31 Jan 2012 15:28:00 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20264.2176.835843.913573@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 15:28:00 +0000
To: Ian Campbell <ian.campbell@citrix.com>
In-Reply-To: <3101b9483229b61afe49.1327337140@cosworth.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
	<3101b9483229b61afe49.1327337140@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 17 of 20] libxl: move device model selection
 variables to b_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Ian Campbell writes ("[PATCH 17 of 20] libxl: move device model selection variables to b_info"):
> libxl: move device model selection variables to b_info.
> 
> Currently we have one set of device model version (and associated)
> variables.  However we can actually have two device models (stub
> device model + non-stub PV device model) which need not necessarily
> be the same version. Perhaps this needs more thought.

Your explanation here isn't entirely clear I think.  AFAICT from
reading the code, both before and after this patch we assume that both
device models are of the same version and there is only one version
knob to twiddle in the config file.

But I didn't peer into the whole thing in detail...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:35:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:35:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFjN-0006vm-VL; Tue, 31 Jan 2012 15:34:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RsFjM-0006vf-A6
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:34:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328024032!54783239!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE3Mzky\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12152 invoked from network); 31 Jan 2012 15:33:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 15:33:53 -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
	q0VFYf5t011545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 15:34:42 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
	q0VFYe8p004861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 15:34:41 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
	q0VFYewS017322; Tue, 31 Jan 2012 09:34:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 07:34:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3978C40294; Tue, 31 Jan 2012 10:32:09 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, lenb@kernel.org, len.brown@intel.com,
	linux-acpi@vger.kernel.org
Date: Tue, 31 Jan 2012 10:32:03 -0500
Message-Id: <1328023924-6858-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F280A13.0025,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [RFC] Using per_cpu(processor) information to pipe it
	up the hypervisor. v1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I was wondering if you could advise me ontwo questions:
 - How to "get" ACPI PM information for processors that are down (either b/c of
   maxcpus=X or they are hot-plugged). The per_cpu(processor) is a great location
   to get all of this - but sadly it is not filled with information for dead CPUs.
   Is there another way to get this data?

 - Where should such a driver (see the patch please) live? I was thinking drivers/acpi/
   but since the "processor" is an exported symbol it could live in drivers/xen as well?
   What is your feeling about it?

Short description of the patch: It simple parses the "per_cpu(processor)" data and 
pipes it up the hypervisor and then unloads itself. It is a much shorter version
of https://lkml.org/lkml/2011/11/30/245, but it does have the caveat that it does
not work with 'maxcpus' or with hot-plugged CPUs or with limiting the amount of
CPUs a guest can see.

P.S.
Also the name of it stinks. 'Sink' or 'plumber' initially came to my mind. Any
thoughts of a better name?

Thanks!

 drivers/xen/Kconfig         |    5 +
 drivers/xen/Makefile        |    2 +-
 drivers/xen/acpi_xen_sink.c |  265 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 271 insertions(+), 1 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:35:09 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:35:09 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFjN-0006vm-VL; Tue, 31 Jan 2012 15:34:49 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RsFjM-0006vf-A6
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:34:48 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328024032!54783239!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE3Mzky\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12152 invoked from network); 31 Jan 2012 15:33:53 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 15:33:53 -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
	q0VFYf5t011545
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 15:34:42 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
	q0VFYe8p004861
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 15:34:41 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
	q0VFYewS017322; Tue, 31 Jan 2012 09:34:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 07:34:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 3978C40294; Tue, 31 Jan 2012 10:32:09 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, lenb@kernel.org, len.brown@intel.com,
	linux-acpi@vger.kernel.org
Date: Tue, 31 Jan 2012 10:32:03 -0500
Message-Id: <1328023924-6858-1-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090209.4F280A13.0025,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com
Subject: [Xen-devel] [RFC] Using per_cpu(processor) information to pipe it
	up the hypervisor. v1
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I was wondering if you could advise me ontwo questions:
 - How to "get" ACPI PM information for processors that are down (either b/c of
   maxcpus=X or they are hot-plugged). The per_cpu(processor) is a great location
   to get all of this - but sadly it is not filled with information for dead CPUs.
   Is there another way to get this data?

 - Where should such a driver (see the patch please) live? I was thinking drivers/acpi/
   but since the "processor" is an exported symbol it could live in drivers/xen as well?
   What is your feeling about it?

Short description of the patch: It simple parses the "per_cpu(processor)" data and 
pipes it up the hypervisor and then unloads itself. It is a much shorter version
of https://lkml.org/lkml/2011/11/30/245, but it does have the caveat that it does
not work with 'maxcpus' or with hot-plugged CPUs or with limiting the amount of
CPUs a guest can see.

P.S.
Also the name of it stinks. 'Sink' or 'plumber' initially came to my mind. Any
thoughts of a better name?

Thanks!

 drivers/xen/Kconfig         |    5 +
 drivers/xen/Makefile        |    2 +-
 drivers/xen/acpi_xen_sink.c |  265 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 271 insertions(+), 1 deletions(-)


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFjT-0006w9-Bk; Tue, 31 Jan 2012 15:34:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RsFjS-0006vl-M4
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:34:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328024086!9486020!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE3Mzky\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14872 invoked from network); 31 Jan 2012 15:34:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 15:34:47 -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
	q0VFYfAZ011552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 15:34:42 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
	q0VFYe1S006596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 15:34:41 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
	q0VFYejk015957; Tue, 31 Jan 2012 09:34:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 07:34:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 40BFF40167; Tue, 31 Jan 2012 10:32:09 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, lenb@kernel.org, len.brown@intel.com,
	linux-acpi@vger.kernel.org
Date: Tue, 31 Jan 2012 10:32:04 -0500
Message-Id: <1328023924-6858-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328023924-6858-1-git-send-email-konrad.wilk@oracle.com>
References: <1328023924-6858-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F280A13.0022,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/acpi: Provide a ACPI driver that sends
	"processor" data to the hypervisor.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The ACPI processor processes the _Pxx and the _Cx state information
which are populated in the 'processor' per-cpu structure. We read
the contents of that structure and pipe it up the Xen hypervisor.

We assume that the ACPI processor is smart and did all the filtering
work so that the contents is correct. After we are done parsing
the information, we unload ourselves and let the hypervisor deal
with cpufreq, cpuidle states and such.

Note: This only works right now under Intel CPUs, b/c the Xen hypervisor
does not properly process the AMD MSR_PSTATE_CUR_LIMIT under AMD.

For Intel the hypervisor needs this patch
http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00511.html

which passes inthe MWAIT CPU attribute.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Kconfig         |    5 +
 drivers/xen/Makefile        |    2 +-
 drivers/xen/acpi_xen_sink.c |  265 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 271 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/acpi_xen_sink.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a1ced52..747ef17 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -178,4 +178,9 @@ config XEN_PRIVCMD
 	depends on XEN
 	default m
 
+config XEN_ACPI_SINK
+	tristate
+	depends on XEN && ACPI_PROCESSOR && CPU_FREQ
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..1585b35 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-
+obj-$(CONFIG_XEN_ACPI_SINK)		+= acpi_xen_sink.o
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
diff --git a/drivers/xen/acpi_xen_sink.c b/drivers/xen/acpi_xen_sink.c
new file mode 100644
index 0000000..78771ca
--- /dev/null
+++ b/drivers/xen/acpi_xen_sink.c
@@ -0,0 +1,265 @@
+
+#define DEBUG 1
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+#include <linux/cpumask.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define DRV_NAME	"ACPI_Xen_Sink"
+MODULE_AUTHOR("Konrad Rzeszutek Wilk");
+MODULE_DESCRIPTION("ACPI Power Management driver to send data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+static int __init push_cxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_CX,
+	};
+	struct xen_processor_cx *xen_cx, *xen_cx_states = NULL;
+	struct acpi_processor_cx *cx;
+	int i, ok, ret = 0;
+
+	if (!_pr->flags.power_setup_done)
+		return -ENODEV;
+
+	xen_cx_states = kcalloc(_pr->power.count,
+				sizeof(struct xen_processor_cx), GFP_KERNEL);
+	if (!xen_cx_states)
+		return -ENOMEM;
+
+	for (ok = 0, i = 1; i <= _pr->power.count; i++) {
+		cx = &_pr->power.states[i];
+		if (!cx->valid)
+			continue;
+
+		xen_cx = &(xen_cx_states[ok++]);
+
+		xen_cx->reg.space_id = ACPI_ADR_SPACE_SYSTEM_IO;
+		if (cx->entry_method == ACPI_CSTATE_SYSTEMIO) {
+			/* TODO: double check whether anybody cares about it */
+			xen_cx->reg.bit_width = 8;
+			xen_cx->reg.bit_offset = 0;
+		} else {
+			xen_cx->reg.space_id = ACPI_ADR_SPACE_FIXED_HARDWARE;
+			if (cx->entry_method == ACPI_CSTATE_FFH) {
+				/* NATIVE_CSTATE_BEYOND_HALT */
+				xen_cx->reg.bit_offset = 2;
+				xen_cx->reg.bit_width = 1; /* VENDOR_INTEL */
+			}
+		}
+		xen_cx->reg.access_size = 0;
+		xen_cx->reg.address = cx->address;
+
+		xen_cx->type = cx->type;
+		xen_cx->latency = cx->latency;
+		xen_cx->power = cx->power;
+
+		xen_cx->dpcnt = 0;
+		set_xen_guest_handle(xen_cx->dp, NULL);
+
+		pr_debug("\t_CX: ID:%d [C%d:%s]\n", _pr->acpi_id, i, cx->desc);
+	}
+	if (!ok) {
+		pr_err("No available Cx info for cpu %d\n", _pr->acpi_id);
+		kfree(xen_cx_states);
+		return -EINVAL;
+	}
+	op.u.set_pminfo.power.count = ok;
+	op.u.set_pminfo.power.flags.bm_control = _pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check = _pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst = _pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =
+		_pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, xen_cx_states);
+
+	if (xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	kfree(xen_cx_states);
+
+	return ret;
+}
+
+
+
+static struct xen_processor_px *
+__init xen_copy_pss_data(struct acpi_processor *_pr,
+			 struct xen_processor_performance *xen_perf)
+{
+	struct xen_processor_px *xen_states = NULL;
+	int i;
+
+	xen_states = kcalloc(_pr->performance->state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+	if (!xen_states)
+		return ERR_PTR(-ENOMEM);
+
+	xen_perf->state_count = _pr->performance->state_count;
+
+	BUILD_BUG_ON(sizeof(struct xen_processor_px) !=
+		     sizeof(struct acpi_processor_px));
+	for (i = 0; i < _pr->performance->state_count; i++) {
+
+		/* Fortunatly for us, they both have the same size */
+		memcpy(&(xen_states[i]), &(_pr->performance->states[i]),
+		       sizeof(struct acpi_processor_px));
+#ifdef DEBUG
+		{
+			struct xen_processor_px *_px;
+			_px = &(xen_states[i]);
+			pr_debug("\t_PSS: [%2d]: %d, %d, %d, %d, %d, %d\n", i,
+				(u32)_px->core_frequency, (u32)_px->power,
+				(u32)_px->transition_latency,
+				(u32)_px->bus_master_latency, (u32)_px->control,
+				(u32)_px->status);
+		}
+#endif
+	}
+	return xen_states;
+}
+static int __init xen_copy_psd_data(struct acpi_processor *_pr,
+				    struct xen_processor_performance *xen_perf)
+{
+	xen_perf->shared_type = _pr->performance->shared_type;
+
+	BUILD_BUG_ON(sizeof(struct xen_psd_package) !=
+		     sizeof(struct acpi_psd_package));
+	memcpy(&(xen_perf->domain_info), &(_pr->performance->domain_info),
+	       sizeof(struct acpi_psd_package));
+
+#if DEBUG
+	{
+		struct xen_psd_package *_psd;
+		_psd = &(xen_perf->domain_info);
+		pr_debug("\t_PSD: num_entries:%d rev=%d domain=%d coord_type=%d, "
+			 "num_processers=%d\n", (u32)_psd->num_entries,
+			 (u32)_psd->revision, (u32)_psd->domain,
+			 (u32)_psd->coord_type, (u32)_psd->num_processors);
+	}
+#endif
+	return 0;
+}
+static int __init xen_copy_pct_data(struct acpi_pct_register *pct,
+				    struct xen_pct_register *_pct)
+{
+	/* It would be nice if you could just do 'memcpy(pct, _pct') but
+	 * sadly the Xen structure did not have the proper padding
+	 * so the descriptor field takes two (_pct) bytes instead of one (pct).
+	 */
+	_pct->descriptor = pct->descriptor;
+	_pct->length = pct->length;
+	_pct->space_id = pct->space_id;
+	_pct->bit_width = pct->bit_width;
+	_pct->bit_offset = pct->bit_offset;
+	_pct->reserved = pct->reserved;
+	_pct->address = pct->address;
+#ifdef DEBUG
+	pr_debug("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
+		 "bit_width=%d, bit_offset=%d), reserved=%d, address=0x%x\n",
+		 _pct->descriptor, _pct->length, _pct->space_id,
+		 _pct->bit_width, _pct->bit_offset, _pct->reserved,
+		 (u32)_pct->address);
+#endif
+	return 0;
+}
+static int __init push_pxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	int ret = -EINVAL;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+	struct xen_processor_performance *xen_perf;
+	struct xen_processor_px *xen_states = NULL;
+
+	if (!_pr->performance)
+		return -ENODEV;
+
+	xen_perf = &op.u.set_pminfo.perf;
+
+	/* PPC */
+	xen_perf->platform_limit = _pr->performance_platform_limit;
+	xen_perf->flags |= XEN_PX_PPC;
+	/* PCT */
+	xen_copy_pct_data(&(_pr->performance->control_register),
+			  &xen_perf->control_register);
+	xen_copy_pct_data(&(_pr->performance->status_register),
+			  &xen_perf->status_register);
+	xen_perf->flags |= XEN_PX_PCT;
+	/* PSS */
+	xen_states = xen_copy_pss_data(_pr, xen_perf);
+	if (!IS_ERR_OR_NULL(xen_states)) {
+		set_xen_guest_handle(xen_perf->states, xen_states);
+		xen_perf->flags |= XEN_PX_PSS;
+	}
+	/* PSD */
+	if (!xen_copy_psd_data(_pr, xen_perf))
+		xen_perf->flags |= XEN_PX_PSD;
+
+	if (xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	if (!IS_ERR_OR_NULL(xen_states))
+		kfree(xen_states);
+	return ret;
+}
+
+static int __init acpi_xen_sink_init(void)
+{
+	int cpu;
+	int err = -ENODEV;
+	struct acpi_processor *_pr;
+	struct cpuinfo_x86 *c = &cpu_data(0);
+
+	/* TODO: Under AMD, the information is populated
+	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
+	 * MSR which returns the wrong value (under Xen) so the population
+	 * of 'processors' has bogus data. So only run this under
+	 * Intel for right now. */
+	if (!cpu_has(c, X86_FEATURE_EST)) {
+		pr_err("AMD platform is not supported (yet)\n");
+		return -ENODEV;
+	}
+	/*
+	 * It is imperative that we get called _after_ acpi_processor has
+	 * loaded. Otherwise the _pr might be bogus.
+	*/
+	if (request_module("processor")) {
+		pr_err("Unable to load ACPI processor module!\n");
+		return -ENODEV;
+	}
+	for_each_possible_cpu(cpu) {
+		_pr = per_cpu(processors, cpu);
+		if (!_pr)
+			continue;
+
+		if (_pr->flags.power)
+			err = push_cxx_to_hypervisor(_pr);
+
+		if (_pr->performance->states)
+			err |= push_pxx_to_hypervisor(_pr);
+		if (err)
+			break;
+	}
+	return -ENODEV; /* force it to unload */
+}
+static void __exit acpi_xen_sink_exit(void)
+{
+}
+module_init(acpi_xen_sink_init);
+module_exit(acpi_xen_sink_exit);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:35:16 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:35:16 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFjT-0006w9-Bk; Tue, 31 Jan 2012 15:34:55 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1RsFjS-0006vl-M4
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:34:54 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328024086!9486020!1
X-Originating-IP: [148.87.113.117]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQ4Ljg3LjExMy4xMTcgPT4gNTE3Mzky\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14872 invoked from network); 31 Jan 2012 15:34:47 -0000
Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com)
	(148.87.113.117)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 15:34:47 -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
	q0VFYfAZ011552
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 15:34:42 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
	q0VFYe1S006596
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 15:34:41 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
	q0VFYejk015957; Tue, 31 Jan 2012 09:34:40 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 07:34:40 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id 40BFF40167; Tue, 31 Jan 2012 10:32:09 -0500 (EST)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: linux-kernel@vger.kernel.org, lenb@kernel.org, len.brown@intel.com,
	linux-acpi@vger.kernel.org
Date: Tue, 31 Jan 2012 10:32:04 -0500
Message-Id: <1328023924-6858-2-git-send-email-konrad.wilk@oracle.com>
X-Mailer: git-send-email 1.7.7.5
In-Reply-To: <1328023924-6858-1-git-send-email-konrad.wilk@oracle.com>
References: <1328023924-6858-1-git-send-email-konrad.wilk@oracle.com>
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090205.4F280A13.0022,ss=1,re=-2.300,fgs=0
Cc: xen-devel@lists.xensource.com,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: [Xen-devel] [PATCH] xen/acpi: Provide a ACPI driver that sends
	"processor" data to the hypervisor.
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

The ACPI processor processes the _Pxx and the _Cx state information
which are populated in the 'processor' per-cpu structure. We read
the contents of that structure and pipe it up the Xen hypervisor.

We assume that the ACPI processor is smart and did all the filtering
work so that the contents is correct. After we are done parsing
the information, we unload ourselves and let the hypervisor deal
with cpufreq, cpuidle states and such.

Note: This only works right now under Intel CPUs, b/c the Xen hypervisor
does not properly process the AMD MSR_PSTATE_CUR_LIMIT under AMD.

For Intel the hypervisor needs this patch
http://old-list-archives.xen.org/archives/html/xen-devel/2011-08/msg00511.html

which passes inthe MWAIT CPU attribute.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 drivers/xen/Kconfig         |    5 +
 drivers/xen/Makefile        |    2 +-
 drivers/xen/acpi_xen_sink.c |  265 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 271 insertions(+), 1 deletions(-)
 create mode 100644 drivers/xen/acpi_xen_sink.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index a1ced52..747ef17 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -178,4 +178,9 @@ config XEN_PRIVCMD
 	depends on XEN
 	default m
 
+config XEN_ACPI_SINK
+	tristate
+	depends on XEN && ACPI_PROCESSOR && CPU_FREQ
+	default m
+
 endmenu
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index aa31337..1585b35 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -20,7 +20,7 @@ obj-$(CONFIG_SWIOTLB_XEN)		+= swiotlb-xen.o
 obj-$(CONFIG_XEN_DOM0)			+= pci.o
 obj-$(CONFIG_XEN_PCIDEV_BACKEND)	+= xen-pciback/
 obj-$(CONFIG_XEN_PRIVCMD)		+= xen-privcmd.o
-
+obj-$(CONFIG_XEN_ACPI_SINK)		+= acpi_xen_sink.o
 xen-evtchn-y				:= evtchn.o
 xen-gntdev-y				:= gntdev.o
 xen-gntalloc-y				:= gntalloc.o
diff --git a/drivers/xen/acpi_xen_sink.c b/drivers/xen/acpi_xen_sink.c
new file mode 100644
index 0000000..78771ca
--- /dev/null
+++ b/drivers/xen/acpi_xen_sink.c
@@ -0,0 +1,265 @@
+
+#define DEBUG 1
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/types.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/processor.h>
+#include <linux/cpumask.h>
+
+#include <xen/interface/platform.h>
+#include <asm/xen/hypercall.h>
+
+#define DRV_NAME	"ACPI_Xen_Sink"
+MODULE_AUTHOR("Konrad Rzeszutek Wilk");
+MODULE_DESCRIPTION("ACPI Power Management driver to send data to Xen hypervisor");
+MODULE_LICENSE("GPL");
+
+static int __init push_cxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_CX,
+	};
+	struct xen_processor_cx *xen_cx, *xen_cx_states = NULL;
+	struct acpi_processor_cx *cx;
+	int i, ok, ret = 0;
+
+	if (!_pr->flags.power_setup_done)
+		return -ENODEV;
+
+	xen_cx_states = kcalloc(_pr->power.count,
+				sizeof(struct xen_processor_cx), GFP_KERNEL);
+	if (!xen_cx_states)
+		return -ENOMEM;
+
+	for (ok = 0, i = 1; i <= _pr->power.count; i++) {
+		cx = &_pr->power.states[i];
+		if (!cx->valid)
+			continue;
+
+		xen_cx = &(xen_cx_states[ok++]);
+
+		xen_cx->reg.space_id = ACPI_ADR_SPACE_SYSTEM_IO;
+		if (cx->entry_method == ACPI_CSTATE_SYSTEMIO) {
+			/* TODO: double check whether anybody cares about it */
+			xen_cx->reg.bit_width = 8;
+			xen_cx->reg.bit_offset = 0;
+		} else {
+			xen_cx->reg.space_id = ACPI_ADR_SPACE_FIXED_HARDWARE;
+			if (cx->entry_method == ACPI_CSTATE_FFH) {
+				/* NATIVE_CSTATE_BEYOND_HALT */
+				xen_cx->reg.bit_offset = 2;
+				xen_cx->reg.bit_width = 1; /* VENDOR_INTEL */
+			}
+		}
+		xen_cx->reg.access_size = 0;
+		xen_cx->reg.address = cx->address;
+
+		xen_cx->type = cx->type;
+		xen_cx->latency = cx->latency;
+		xen_cx->power = cx->power;
+
+		xen_cx->dpcnt = 0;
+		set_xen_guest_handle(xen_cx->dp, NULL);
+
+		pr_debug("\t_CX: ID:%d [C%d:%s]\n", _pr->acpi_id, i, cx->desc);
+	}
+	if (!ok) {
+		pr_err("No available Cx info for cpu %d\n", _pr->acpi_id);
+		kfree(xen_cx_states);
+		return -EINVAL;
+	}
+	op.u.set_pminfo.power.count = ok;
+	op.u.set_pminfo.power.flags.bm_control = _pr->flags.bm_control;
+	op.u.set_pminfo.power.flags.bm_check = _pr->flags.bm_check;
+	op.u.set_pminfo.power.flags.has_cst = _pr->flags.has_cst;
+	op.u.set_pminfo.power.flags.power_setup_done =
+		_pr->flags.power_setup_done;
+
+	set_xen_guest_handle(op.u.set_pminfo.power.states, xen_cx_states);
+
+	if (xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	kfree(xen_cx_states);
+
+	return ret;
+}
+
+
+
+static struct xen_processor_px *
+__init xen_copy_pss_data(struct acpi_processor *_pr,
+			 struct xen_processor_performance *xen_perf)
+{
+	struct xen_processor_px *xen_states = NULL;
+	int i;
+
+	xen_states = kcalloc(_pr->performance->state_count,
+			     sizeof(struct xen_processor_px), GFP_KERNEL);
+	if (!xen_states)
+		return ERR_PTR(-ENOMEM);
+
+	xen_perf->state_count = _pr->performance->state_count;
+
+	BUILD_BUG_ON(sizeof(struct xen_processor_px) !=
+		     sizeof(struct acpi_processor_px));
+	for (i = 0; i < _pr->performance->state_count; i++) {
+
+		/* Fortunatly for us, they both have the same size */
+		memcpy(&(xen_states[i]), &(_pr->performance->states[i]),
+		       sizeof(struct acpi_processor_px));
+#ifdef DEBUG
+		{
+			struct xen_processor_px *_px;
+			_px = &(xen_states[i]);
+			pr_debug("\t_PSS: [%2d]: %d, %d, %d, %d, %d, %d\n", i,
+				(u32)_px->core_frequency, (u32)_px->power,
+				(u32)_px->transition_latency,
+				(u32)_px->bus_master_latency, (u32)_px->control,
+				(u32)_px->status);
+		}
+#endif
+	}
+	return xen_states;
+}
+static int __init xen_copy_psd_data(struct acpi_processor *_pr,
+				    struct xen_processor_performance *xen_perf)
+{
+	xen_perf->shared_type = _pr->performance->shared_type;
+
+	BUILD_BUG_ON(sizeof(struct xen_psd_package) !=
+		     sizeof(struct acpi_psd_package));
+	memcpy(&(xen_perf->domain_info), &(_pr->performance->domain_info),
+	       sizeof(struct acpi_psd_package));
+
+#if DEBUG
+	{
+		struct xen_psd_package *_psd;
+		_psd = &(xen_perf->domain_info);
+		pr_debug("\t_PSD: num_entries:%d rev=%d domain=%d coord_type=%d, "
+			 "num_processers=%d\n", (u32)_psd->num_entries,
+			 (u32)_psd->revision, (u32)_psd->domain,
+			 (u32)_psd->coord_type, (u32)_psd->num_processors);
+	}
+#endif
+	return 0;
+}
+static int __init xen_copy_pct_data(struct acpi_pct_register *pct,
+				    struct xen_pct_register *_pct)
+{
+	/* It would be nice if you could just do 'memcpy(pct, _pct') but
+	 * sadly the Xen structure did not have the proper padding
+	 * so the descriptor field takes two (_pct) bytes instead of one (pct).
+	 */
+	_pct->descriptor = pct->descriptor;
+	_pct->length = pct->length;
+	_pct->space_id = pct->space_id;
+	_pct->bit_width = pct->bit_width;
+	_pct->bit_offset = pct->bit_offset;
+	_pct->reserved = pct->reserved;
+	_pct->address = pct->address;
+#ifdef DEBUG
+	pr_debug("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
+		 "bit_width=%d, bit_offset=%d), reserved=%d, address=0x%x\n",
+		 _pct->descriptor, _pct->length, _pct->space_id,
+		 _pct->bit_width, _pct->bit_offset, _pct->reserved,
+		 (u32)_pct->address);
+#endif
+	return 0;
+}
+static int __init push_pxx_to_hypervisor(struct acpi_processor *_pr)
+{
+	int ret = -EINVAL;
+	struct xen_platform_op op = {
+		.cmd			= XENPF_set_processor_pminfo,
+		.interface_version	= XENPF_INTERFACE_VERSION,
+		.u.set_pminfo.id	= _pr->acpi_id,
+		.u.set_pminfo.type	= XEN_PM_PX,
+	};
+	struct xen_processor_performance *xen_perf;
+	struct xen_processor_px *xen_states = NULL;
+
+	if (!_pr->performance)
+		return -ENODEV;
+
+	xen_perf = &op.u.set_pminfo.perf;
+
+	/* PPC */
+	xen_perf->platform_limit = _pr->performance_platform_limit;
+	xen_perf->flags |= XEN_PX_PPC;
+	/* PCT */
+	xen_copy_pct_data(&(_pr->performance->control_register),
+			  &xen_perf->control_register);
+	xen_copy_pct_data(&(_pr->performance->status_register),
+			  &xen_perf->status_register);
+	xen_perf->flags |= XEN_PX_PCT;
+	/* PSS */
+	xen_states = xen_copy_pss_data(_pr, xen_perf);
+	if (!IS_ERR_OR_NULL(xen_states)) {
+		set_xen_guest_handle(xen_perf->states, xen_states);
+		xen_perf->flags |= XEN_PX_PSS;
+	}
+	/* PSD */
+	if (!xen_copy_psd_data(_pr, xen_perf))
+		xen_perf->flags |= XEN_PX_PSD;
+
+	if (xen_initial_domain())
+		ret = HYPERVISOR_dom0_op(&op);
+
+	if (!IS_ERR_OR_NULL(xen_states))
+		kfree(xen_states);
+	return ret;
+}
+
+static int __init acpi_xen_sink_init(void)
+{
+	int cpu;
+	int err = -ENODEV;
+	struct acpi_processor *_pr;
+	struct cpuinfo_x86 *c = &cpu_data(0);
+
+	/* TODO: Under AMD, the information is populated
+	 * using the powernow-k8 driver which does an MSR_PSTATE_CUR_LIMIT
+	 * MSR which returns the wrong value (under Xen) so the population
+	 * of 'processors' has bogus data. So only run this under
+	 * Intel for right now. */
+	if (!cpu_has(c, X86_FEATURE_EST)) {
+		pr_err("AMD platform is not supported (yet)\n");
+		return -ENODEV;
+	}
+	/*
+	 * It is imperative that we get called _after_ acpi_processor has
+	 * loaded. Otherwise the _pr might be bogus.
+	*/
+	if (request_module("processor")) {
+		pr_err("Unable to load ACPI processor module!\n");
+		return -ENODEV;
+	}
+	for_each_possible_cpu(cpu) {
+		_pr = per_cpu(processors, cpu);
+		if (!_pr)
+			continue;
+
+		if (_pr->flags.power)
+			err = push_cxx_to_hypervisor(_pr);
+
+		if (_pr->performance->states)
+			err |= push_pxx_to_hypervisor(_pr);
+		if (err)
+			break;
+	}
+	return -ENODEV; /* force it to unload */
+}
+static void __exit acpi_xen_sink_exit(void)
+{
+}
+module_init(acpi_xen_sink_init);
+module_exit(acpi_xen_sink_exit);
-- 
1.7.7.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFnX-0007Cu-9T; Tue, 31 Jan 2012 15:39:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsFnV-0007Cg-P6
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:39:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328024338!4462664!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21208 invoked from network); 31 Jan 2012 15:38:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 15:38:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10395022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:38:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 15:38:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 31 Jan 2012 15:38:58 +0000
In-Reply-To: <20264.2176.835843.913573@mariner.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
	<3101b9483229b61afe49.1327337140@cosworth.uk.xensource.com>
	<20264.2176.835843.913573@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328024338.26983.414.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 17 of 20] libxl: move device model selection
 variables to b_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 15:28 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 17 of 20] libxl: move device model selection variables to b_info"):
> > libxl: move device model selection variables to b_info.
> > 
> > Currently we have one set of device model version (and associated)
> > variables.  However we can actually have two device models (stub
> > device model + non-stub PV device model) which need not necessarily
> > be the same version. Perhaps this needs more thought.
> 
> Your explanation here isn't entirely clear I think.  AFAICT from
> reading the code, both before and after this patch we assume that both
> device models are of the same version and there is only one version
> knob to twiddle in the config file.

That's right. I have just moved where that one nob was. The comment was
(now I look at it, misleadingly worded,) musing on whether we should
have two nobs or not and/or how that would look.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:39:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:39:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFnX-0007Cu-9T; Tue, 31 Jan 2012 15:39:07 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1RsFnV-0007Cg-P6
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:39:05 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-21.messagelabs.com!1328024338!4462664!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21208 invoked from network); 31 Jan 2012 15:38:59 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 15:38:59 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10395022"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:38:58 +0000
Received: from [10.80.2.42] (10.80.2.42) by LONPMAILMX01.citrite.net
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 15:38:58 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 31 Jan 2012 15:38:58 +0000
In-Reply-To: <20264.2176.835843.913573@mariner.uk.xensource.com>
References: <patchbomb.1327337123@cosworth.uk.xensource.com>
	<3101b9483229b61afe49.1327337140@cosworth.uk.xensource.com>
	<20264.2176.835843.913573@mariner.uk.xensource.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328024338.26983.414.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 17 of 20] libxl: move device model selection
 variables to b_info
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 2012-01-31 at 15:28 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH 17 of 20] libxl: move device model selection variables to b_info"):
> > libxl: move device model selection variables to b_info.
> > 
> > Currently we have one set of device model version (and associated)
> > variables.  However we can actually have two device models (stub
> > device model + non-stub PV device model) which need not necessarily
> > be the same version. Perhaps this needs more thought.
> 
> Your explanation here isn't entirely clear I think.  AFAICT from
> reading the code, both before and after this patch we assume that both
> device models are of the same version and there is only one version
> knob to twiddle in the config file.

That's right. I have just moved where that one nob was. The comment was
(now I look at it, misleadingly worded,) musing on whether we should
have two nobs or not and/or how that would look.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:49:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFwy-0007T2-EF; Tue, 31 Jan 2012 15:48:52 +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 1RsFww-0007Sw-5u
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:48:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328024874!54786193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8170 invoked from network); 31 Jan 2012 15:47:55 -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;
	31 Jan 2012 15:47:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10395513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:48:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 15:48:36 +0000
Date: Tue, 31 Jan 2012 15:50:18 +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.1201251239180.3196@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201301432370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Stefano Stabellini wrote:
> Hi all,
> this is the fourth version of the Xen save/restore patch series.
> We have been discussing this issue for quite a while on #qemu and
> qemu-devel:
> 
> 
> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> 
> 
> The principal changes in the this version are:
> 
> - Following Anthony's suggestion I have introduced a new monitor command
> to save the non-ram device state to file.
> 
> - I have also removed the hack not to reset the cirrus videoram on
> restore, because it turns out that the videoram doesn't need to be
> reset in the reset handler at all (tested on Win2K, where the problem
> was found in the first place).
> 

Is everybody happy enough with this series?
Do you have any additional comments?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 15:49:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 15:49:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsFwy-0007T2-EF; Tue, 31 Jan 2012 15:48:52 +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 1RsFww-0007Sw-5u
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 15:48:50 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328024874!54786193!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8170 invoked from network); 31 Jan 2012 15:47:55 -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;
	31 Jan 2012 15:47:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10395513"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 15:48:35 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 15:48:36 +0000
Date: Tue, 31 Jan 2012 15:50:18 +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.1201251239180.3196@kaball-desktop>
Message-ID: <alpine.DEB.2.00.1201301432370.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201251239180.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Anthony Liguori <anthony@codemonkey.ws>, Avi Kivity <avi@redhat.com>
Subject: Re: [Xen-devel] [PATCH v4 0/6] save/restore on Xen
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, 25 Jan 2012, Stefano Stabellini wrote:
> Hi all,
> this is the fourth version of the Xen save/restore patch series.
> We have been discussing this issue for quite a while on #qemu and
> qemu-devel:
> 
> 
> http://marc.info/?l=qemu-devel&m=132346828427314&w=2
> http://marc.info/?l=qemu-devel&m=132377734605464&w=2
> 
> 
> The principal changes in the this version are:
> 
> - Following Anthony's suggestion I have introduced a new monitor command
> to save the non-ram device state to file.
> 
> - I have also removed the hack not to reset the cirrus videoram on
> restore, because it turns out that the videoram doesn't need to be
> reset in the reset handler at all (tested on Win2K, where the problem
> was found in the first place).
> 

Is everybody happy enough with this series?
Do you have any additional comments?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:10:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16: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 1RsGHT-0008CA-D0; Tue, 31 Jan 2012 16:10: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 1RsGHS-0008C5-P4
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:10:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328026164!50508769!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13702 invoked from network); 31 Jan 2012 16:09:25 -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;
	31 Jan 2012 16:09:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10396521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:10: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; Tue, 31 Jan 2012 16:10:01 +0000
Date: Tue, 31 Jan 2012 16:11:44 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH v4 0/6] prevent QEMU from waking up needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents QEMU from waking up needlessly on Xen
several times a second in order to check some timers.



The first patch stops QEMU from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that QEMU doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fifth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.



Changes in v4:

- do not initialize pcspk on xen;

- disable rtc_clock only when it points to the host_clock (the default);

- make sure it compiles on older xen versions.


Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.



Shortlog and diffstat follow:

Stefano Stabellini (6):
      xen: do not initialize the interval timer and PCSPK emulator
      xen: disable rtc_clock
      xen: introduce an event channel for buffered io event notifications
      timers: the rearm function should be able to handle delta = INT64_MAX
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      qemu_calculate_timeout: increase minimum timeout to 1h

 hw/pc.c      |    9 ++++++---
 qemu-timer.c |   30 ++++++++++++++++++------------
 xen-all.c    |   49 +++++++++++++++++++++++++++++++++++++++++++------
 3 files changed, 67 insertions(+), 21 deletions(-)


A git tree, based on fd39941ac78fbe969e292eeb91415ec548bd97a6, is available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-4

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:10:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16: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 1RsGHT-0008CA-D0; Tue, 31 Jan 2012 16:10: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 1RsGHS-0008C5-P4
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:10:02 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328026164!50508769!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13702 invoked from network); 31 Jan 2012 16:09:25 -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;
	31 Jan 2012 16:09:25 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10396521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:10: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; Tue, 31 Jan 2012 16:10:01 +0000
Date: Tue, 31 Jan 2012 16:11:44 +0000
From: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Message-ID: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Jan Kiszka <jan.kiszka@siemens.com>, Avi Kivity <avi@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: [Xen-devel] [PATCH v4 0/6] prevent QEMU from waking up needlessly
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi all,
this small patch series prevents QEMU from waking up needlessly on Xen
several times a second in order to check some timers.



The first patch stops QEMU from emulating the PIT on Xen, the second
patch disables the rtc_clock entirely.

The third patch makes use of a new mechanism to receive buffered io
event notifications from Xen, so that QEMU doesn't need to check the
buffered io page for data 10 times a sec for the entire life of the VM.

The fourth patch fixes win32_rearm_timer and mm_rearm_timer that
risk an overflow if INT64_MAX is passed as delta.

The fifth patch changes qemu_next_alarm_deadline only to check the
expire time of a clock if it is enabled.

Finally the last patch increases the default select timeout to 1h:
nothing should rely on the select timeout to be 1sec, so we might as
well increase it to 1h.



Changes in v4:

- do not initialize pcspk on xen;

- disable rtc_clock only when it points to the host_clock (the default);

- make sure it compiles on older xen versions.


Changes in v3:

- added a new patch to fix win32_rearm_timer and mm_rearm_timer, that
risk an overflow if INT64_MAX is passed as delta.



Shortlog and diffstat follow:

Stefano Stabellini (6):
      xen: do not initialize the interval timer and PCSPK emulator
      xen: disable rtc_clock
      xen: introduce an event channel for buffered io event notifications
      timers: the rearm function should be able to handle delta = INT64_MAX
      qemu_next_alarm_deadline: check the expire time of a clock only if it is enabled
      qemu_calculate_timeout: increase minimum timeout to 1h

 hw/pc.c      |    9 ++++++---
 qemu-timer.c |   30 ++++++++++++++++++------------
 xen-all.c    |   49 +++++++++++++++++++++++++++++++++++++++++++------
 3 files changed, 67 insertions(+), 21 deletions(-)


A git tree, based on fd39941ac78fbe969e292eeb91415ec548bd97a6, is available here:

git://xenbits.xen.org/people/sstabellini/qemu-dm.git timers-4

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGIk-0008Fq-Jm; Tue, 31 Jan 2012 16:11:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGIj-0008FX-Oj
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:11:21 +0000
Received: from [85.158.138.51:23291] by server-5.bemta-3.messagelabs.com id
	42/CA-02363-8A2182F4; Tue, 31 Jan 2012 16:11:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328026273!11241516!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11946 invoked from network); 31 Jan 2012 16:11:20 -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;
	31 Jan 2012 16:11:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="21462328"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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; Tue, 31 Jan 2012 11:11:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0VGAvVs032535;
	Tue, 31 Jan 2012 08:11:07 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:53 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 5/6] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 29410f1..de20852 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGIk-0008Fq-Jm; Tue, 31 Jan 2012 16:11:22 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGIj-0008FX-Oj
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:11:21 +0000
Received: from [85.158.138.51:23291] by server-5.bemta-3.messagelabs.com id
	42/CA-02363-8A2182F4; Tue, 31 Jan 2012 16:11:20 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328026273!11241516!3
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11946 invoked from network); 31 Jan 2012 16:11:20 -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;
	31 Jan 2012 16:11:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="21462328"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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; Tue, 31 Jan 2012 11:11:18 -0500
Received: from localhost.localdomain (kaball.uk.xensource.com [10.80.2.59])	by
	smtp01.ad.xensource.com (8.13.1/8.13.1) with ESMTP id q0VGAvVs032535;
	Tue, 31 Jan 2012 08:11:07 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:53 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 5/6] qemu_next_alarm_deadline: check the
	expire time of a clock only if it is enabled
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Also delta in qemu_next_alarm_deadline is a 64 bit value so set the
default to INT64_MAX instead of INT32_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index 29410f1..de20852 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -106,23 +106,21 @@ static inline int alarm_has_dynticks(struct qemu_alarm_timer *t)
 
 static int64_t qemu_next_alarm_deadline(void)
 {
-    int64_t delta;
+    int64_t delta = INT64_MAX;
     int64_t rtdelta;
 
-    if (!use_icount && vm_clock->active_timers) {
+    if (!use_icount && vm_clock->enabled && vm_clock->active_timers) {
         delta = vm_clock->active_timers->expire_time -
                      qemu_get_clock_ns(vm_clock);
-    } else {
-        delta = INT32_MAX;
     }
-    if (host_clock->active_timers) {
+    if (host_clock->enabled && host_clock->active_timers) {
         int64_t hdelta = host_clock->active_timers->expire_time -
                  qemu_get_clock_ns(host_clock);
         if (hdelta < delta) {
             delta = hdelta;
         }
     }
-    if (rt_clock->active_timers) {
+    if (rt_clock->enabled && rt_clock->active_timers) {
         rtdelta = (rt_clock->active_timers->expire_time -
                  qemu_get_clock_ns(rt_clock));
         if (rtdelta < delta) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGIg-0008FF-S6; Tue, 31 Jan 2012 16:11:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGIf-0008F8-6d
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:11:17 +0000
Received: from [85.158.138.51:22961] by server-9.bemta-3.messagelabs.com id
	A2/32-31168-4A2182F4; Tue, 31 Jan 2012 16:11:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328026273!11241516!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11789 invoked from network); 31 Jan 2012 16:11:15 -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;
	31 Jan 2012 16:11:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="21462295"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 11:11: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 q0VGAvVp032535;
	Tue, 31 Jan 2012 08:11:02 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:50 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index fd39168..101c962 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -514,6 +514,10 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    /* if rtc_clock is left to default (host_clock), disable it */
+    if (rtc_clock == host_clock) {
+        qemu_clock_enable(rtc_clock, false);
+    }
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGIg-0008FF-S6; Tue, 31 Jan 2012 16:11:18 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGIf-0008F8-6d
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:11:17 +0000
Received: from [85.158.138.51:22961] by server-9.bemta-3.messagelabs.com id
	A2/32-31168-4A2182F4; Tue, 31 Jan 2012 16:11:16 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328026273!11241516!2
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11789 invoked from network); 31 Jan 2012 16:11:15 -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;
	31 Jan 2012 16:11:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="21462295"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11:14 -0500
Received: from smtp01.ad.xensource.com (10.219.128.104) by
	smtprelay.citrix.com (10.13.107.65) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 11:11: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 q0VGAvVp032535;
	Tue, 31 Jan 2012 08:11:02 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:50 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 2/6] xen: disable rtc_clock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

rtc_clock is only used by the RTC emulator (mc146818rtc.c), however Xen
has its own RTC emulator in the hypervisor so we can disable it.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index fd39168..101c962 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -514,6 +514,10 @@ void xen_vcpu_init(void)
         qemu_register_reset(xen_reset_vcpu, first_cpu);
         xen_reset_vcpu(first_cpu);
     }
+    /* if rtc_clock is left to default (host_clock), disable it */
+    if (rtc_clock == host_clock) {
+        qemu_clock_enable(rtc_clock, false);
+    }
 }
 
 /* get the ioreq packets from share mem */
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGIj-0008FY-7g; Tue, 31 Jan 2012 16:11:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGIi-0008FA-1v
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:11:20 +0000
Received: from [85.158.138.51:62582] by server-10.bemta-3.messagelabs.com id
	F2/2A-20948-5A2182F4; Tue, 31 Jan 2012 16:11:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328026273!11241516!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11744 invoked from network); 31 Jan 2012 16:11:15 -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;
	31 Jan 2012 16:11:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="21462294"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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, 31 Jan 2012 11:11: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 q0VGAvVr032535;
	Tue, 31 Jan 2012 08:11:05 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:52 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 4/6] timers: the rearm function should be
	able to handle delta = INT64_MAX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index a22f27e..29410f1 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -696,13 +696,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-    int nearest_delta_ms = (delta + 999999) / 1000000;
+    int64_t nearest_delta_ms = delta / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* UINT_MAX can be 32 bit */
+    if (nearest_delta_ms > UINT_MAX) {
+        nearest_delta_ms = UINT_MAX;
+    }
 
     timeKillEvent(mm_timer);
-    mm_timer = timeSetEvent(nearest_delta_ms,
+    mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
                             mm_period,
                             mm_alarm_handler,
                             (DWORD_PTR)t,
@@ -757,16 +761,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
                               int64_t nearest_delta_ns)
 {
     HANDLE hTimer = t->timer;
-    int nearest_delta_ms;
+    int64_t nearest_delta_ms;
     BOOLEAN success;
 
-    nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
+    nearest_delta_ms = nearest_delta_ns / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* ULONG_MAX can be 32 bit */
+    if (nearest_delta_ms > ULONG_MAX) {
+        nearest_delta_ms = ULONG_MAX;
+    }
     success = ChangeTimerQueueTimer(NULL,
                                     hTimer,
-                                    nearest_delta_ms,
+                                    (unsigned long) nearest_delta_ms,
                                     3600000);
 
     if (!success) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGIj-0008FY-7g; Tue, 31 Jan 2012 16:11:21 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGIi-0008FA-1v
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:11:20 +0000
Received: from [85.158.138.51:62582] by server-10.bemta-3.messagelabs.com id
	F2/2A-20948-5A2182F4; Tue, 31 Jan 2012 16:11:17 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328026273!11241516!1
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11744 invoked from network); 31 Jan 2012 16:11:15 -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;
	31 Jan 2012 16:11:15 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="21462294"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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, 31 Jan 2012 11:11: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 q0VGAvVr032535;
	Tue, 31 Jan 2012 08:11:05 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:52 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 4/6] timers: the rearm function should be
	able to handle delta = INT64_MAX
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Fix win32_rearm_timer and mm_rearm_timer: they should be able to handle
INT64_MAX as a delta parameter without overflowing.
Also, the next deadline in ms should be calculated rounding down rather
than up (see unix_rearm_timer and dynticks_rearm_timer).

Finally ChangeTimerQueueTimer takes an unsigned long and timeSetEvent
takes an unsigned int as delta, so cast the ms delta to the appropriate
unsigned integer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |   18 +++++++++++++-----
 1 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index a22f27e..29410f1 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -696,13 +696,17 @@ static void mm_stop_timer(struct qemu_alarm_timer *t)
 
 static void mm_rearm_timer(struct qemu_alarm_timer *t, int64_t delta)
 {
-    int nearest_delta_ms = (delta + 999999) / 1000000;
+    int64_t nearest_delta_ms = delta / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* UINT_MAX can be 32 bit */
+    if (nearest_delta_ms > UINT_MAX) {
+        nearest_delta_ms = UINT_MAX;
+    }
 
     timeKillEvent(mm_timer);
-    mm_timer = timeSetEvent(nearest_delta_ms,
+    mm_timer = timeSetEvent((unsigned int) nearest_delta_ms,
                             mm_period,
                             mm_alarm_handler,
                             (DWORD_PTR)t,
@@ -757,16 +761,20 @@ static void win32_rearm_timer(struct qemu_alarm_timer *t,
                               int64_t nearest_delta_ns)
 {
     HANDLE hTimer = t->timer;
-    int nearest_delta_ms;
+    int64_t nearest_delta_ms;
     BOOLEAN success;
 
-    nearest_delta_ms = (nearest_delta_ns + 999999) / 1000000;
+    nearest_delta_ms = nearest_delta_ns / 1000000;
     if (nearest_delta_ms < 1) {
         nearest_delta_ms = 1;
     }
+    /* ULONG_MAX can be 32 bit */
+    if (nearest_delta_ms > ULONG_MAX) {
+        nearest_delta_ms = ULONG_MAX;
+    }
     success = ChangeTimerQueueTimer(NULL,
                                     hTimer,
-                                    nearest_delta_ms,
+                                    (unsigned long) nearest_delta_ms,
                                     3600000);
 
     if (!success) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGIn-0008GW-1M; Tue, 31 Jan 2012 16:11:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGIl-0008Ft-8d
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:11:23 +0000
Received: from [85.158.138.51:23407] by server-2.bemta-3.messagelabs.com id
	22/3C-24515-AA2182F4; Tue, 31 Jan 2012 16:11:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328026273!11241516!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12016 invoked from network); 31 Jan 2012 16:11:21 -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;
	31 Jan 2012 16:11:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="21462336"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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; Tue, 31 Jan 2012 11:11: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 q0VGAvVt032535;
	Tue, 31 Jan 2012 08:11:09 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:54 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 6/6] qemu_calculate_timeout: increase minimum
	timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index de20852..84b970e 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -823,6 +823,6 @@ fail:
 
 int qemu_calculate_timeout(void)
 {
-    return 1000;
+    return 1000*60*60;
 }
 
-- 
1.7.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 Jan 31 16:11:40 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:11:40 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGIn-0008GW-1M; Tue, 31 Jan 2012 16:11:25 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGIl-0008Ft-8d
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:11:23 +0000
Received: from [85.158.138.51:23407] by server-2.bemta-3.messagelabs.com id
	22/3C-24515-AA2182F4; Tue, 31 Jan 2012 16:11:22 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-14.tower-174.messagelabs.com!1328026273!11241516!4
X-Originating-IP: [66.165.176.89]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAxMTg1NTg=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12016 invoked from network); 31 Jan 2012 16:11:21 -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;
	31 Jan 2012 16:11:21 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="21462336"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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; Tue, 31 Jan 2012 11:11: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 q0VGAvVt032535;
	Tue, 31 Jan 2012 08:11:09 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:54 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 6/6] qemu_calculate_timeout: increase minimum
	timeout to 1h
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

There is no reason why the minimum timeout should be 1sec, it could
easily be 1h and we would save lots of cpu cycles.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 qemu-timer.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu-timer.c b/qemu-timer.c
index de20852..84b970e 100644
--- a/qemu-timer.c
+++ b/qemu-timer.c
@@ -823,6 +823,6 @@ fail:
 
 int qemu_calculate_timeout(void)
 {
-    return 1000;
+    return 1000*60*60;
 }
 
-- 
1.7.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 Jan 31 16:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16: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 1RsGKt-0000C8-Iu; Tue, 31 Jan 2012 16:13:35 +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 1RsGKr-0000Az-MG
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:13:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328026405!13110776!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28556 invoked from network); 31 Jan 2012 16:13:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 16:13:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="179800437"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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, 31 Jan 2012 11:11: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 q0VGAvVo032535;
	Tue, 31 Jan 2012 08:10:57 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:49 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 1/6] xen: do not initialize the interval
	timer and PCSPK emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PIT and PCSPK are emulated by the hypervisor so we don't need to emulate
them in Qemu: this patch prevents Qemu from waking up needlessly at
PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 31608d3..18abee0 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -44,6 +44,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1137,7 +1138,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     DriveInfo *fd[MAX_FD];
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1158,8 +1159,10 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-    pit = pit_init(isa_bus, 0x40, 0);
-    pcspk_init(pit);
+    if (!xen_available()) {
+        pit = pit_init(isa_bus, 0x40, 0);
+        pcspk_init(pit);
+    }
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
         if (serial_hds[i]) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:13:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16: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 1RsGKt-0000C8-Iu; Tue, 31 Jan 2012 16:13:35 +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 1RsGKr-0000Az-MG
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:13:33 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328026405!13110776!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28556 invoked from network); 31 Jan 2012 16:13:27 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 16:13:27 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="179800437"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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, 31 Jan 2012 11:11: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 q0VGAvVo032535;
	Tue, 31 Jan 2012 08:10:57 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:49 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 1/6] xen: do not initialize the interval
	timer and PCSPK emulator
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

PIT and PCSPK are emulated by the hypervisor so we don't need to emulate
them in Qemu: this patch prevents Qemu from waking up needlessly at
PIT_FREQ on Xen.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 hw/pc.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/hw/pc.c b/hw/pc.c
index 31608d3..18abee0 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -44,6 +44,7 @@
 #include "ui/qemu-spice.h"
 #include "memory.h"
 #include "exec-memory.h"
+#include "arch_init.h"
 
 /* output Bochs bios info messages */
 //#define DEBUG_BIOS
@@ -1137,7 +1138,7 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
     DriveInfo *fd[MAX_FD];
     qemu_irq rtc_irq = NULL;
     qemu_irq *a20_line;
-    ISADevice *i8042, *port92, *vmmouse, *pit;
+    ISADevice *i8042, *port92, *vmmouse, *pit = NULL;
     qemu_irq *cpu_exit_irq;
 
     register_ioport_write(0x80, 1, 1, ioport80_write, NULL);
@@ -1158,8 +1159,10 @@ void pc_basic_device_init(ISABus *isa_bus, qemu_irq *gsi,
 
     qemu_register_boot_set(pc_boot_set, *rtc_state);
 
-    pit = pit_init(isa_bus, 0x40, 0);
-    pcspk_init(pit);
+    if (!xen_available()) {
+        pit = pit_init(isa_bus, 0x40, 0);
+        pcspk_init(pit);
+    }
 
     for(i = 0; i < MAX_SERIAL_PORTS; i++) {
         if (serial_hds[i]) {
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:13:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGKt-0000CH-Uf; Tue, 31 Jan 2012 16:13:35 +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 1RsGKs-0000BA-7B
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:13:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328026405!13110776!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28612 invoked from network); 31 Jan 2012 16:13:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 16:13:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="179800457"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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; Tue, 31 Jan 2012 11:11: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 q0VGAvVq032535;
	Tue, 31 Jan 2012 08:11:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:51 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 3/6] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   45 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 101c962..0ce8002 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -59,6 +59,9 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 }
 #  define FMT_ioreq_size "u"
 #endif
+#ifndef HVM_PARAM_BUFIOREQ_EVTCHN
+#define HVM_PARAM_BUFIOREQ_EVTCHN 26
+#endif
 
 #define BUFFER_IO_MAX_DELAY  100
 
@@ -77,6 +80,8 @@ typedef struct XenIOState {
     QEMUTimer *buffered_io_timer;
     /* the evtchn port for polling the notification, */
     evtchn_port_t *ioreq_local_port;
+    /* evtchn local port for buffered io */
+    evtchn_port_t bufioreq_local_port;
     /* the evtchn fd for polling */
     XenEvtchn xce_handle;
     /* which vcpu we are serving */
@@ -549,6 +554,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(state->xce_handle);
+    if (port == state->bufioreq_local_port) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+        return NULL;
+    }
+
     if (port != -1) {
         for (i = 0; i < smp_cpus; i++) {
             if (state->ioreq_local_port[i] == port) {
@@ -697,16 +708,18 @@ static void handle_ioreq(ioreq_t *req)
     }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!state->buffered_io_page) {
-        return;
+        return 0;
     }
 
+    memset(&req, 0x00, sizeof(req));
+
     while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {
         buf_req = &state->buffered_io_page->buf_ioreq[
             state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -731,15 +744,21 @@ static void handle_buffered_iopage(XenIOState *state)
         xen_mb();
         state->buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     XenIOState *state = opaque;
 
-    handle_buffered_iopage(state);
-    qemu_mod_timer(state->buffered_io_timer,
-                   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    if (handle_buffered_iopage(state)) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    } else {
+        qemu_del_timer(state->buffered_io_timer);
+        xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -869,7 +888,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
     state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
                                                  state);
-    qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -921,6 +939,7 @@ int xen_hvm_init(void)
 {
     int i, rc;
     unsigned long ioreq_pfn;
+    unsigned long bufioreq_evtchn;
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -970,6 +989,20 @@ int xen_hvm_init(void)
         state->ioreq_local_port[i] = rc;
     }
 
+    rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+            &bufioreq_evtchn);
+    if (rc < 0) {
+        fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+        return -1;
+    }
+    rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+            (uint32_t)bufioreq_evtchn);
+    if (rc == -1) {
+        fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+        return -1;
+    }
+    state->bufioreq_local_port = rc;
+
     /* Init RAM management */
     xen_map_cache_init();
     xen_ram_init(ram_size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:13:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:13:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGKt-0000CH-Uf; Tue, 31 Jan 2012 16:13:35 +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 1RsGKs-0000BA-7B
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:13:34 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328026405!13110776!2
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28612 invoked from network); 31 Jan 2012 16:13:28 -0000
Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 16:13:28 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="179800457"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:11: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; Tue, 31 Jan 2012 11:11: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 q0VGAvVq032535;
	Tue, 31 Jan 2012 08:11:03 -0800
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:12:51 +0000
Message-ID: <1328026374-12803-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.1201311551120.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201311551120.3196@kaball-desktop>
MIME-Version: 1.0
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com,
	anthony@codemonkey.ws, pbonzini@redhat.com
Subject: [Xen-devel] [PATCH v4 3/6] xen: introduce an event channel for
	buffered io event notifications
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Use the newly introduced HVM_PARAM_BUFIOREQ_EVTCHN to receive
notifications for buffered io events.
After the first notification is received leave the event channel masked
and setup a timer to process the rest of the batch.
Once we have completed processing the batch, unmask the event channel
and delete the timer.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 xen-all.c |   45 +++++++++++++++++++++++++++++++++++++++------
 1 files changed, 39 insertions(+), 6 deletions(-)

diff --git a/xen-all.c b/xen-all.c
index 101c962..0ce8002 100644
--- a/xen-all.c
+++ b/xen-all.c
@@ -59,6 +59,9 @@ static inline ioreq_t *xen_vcpu_ioreq(shared_iopage_t *shared_page, int vcpu)
 }
 #  define FMT_ioreq_size "u"
 #endif
+#ifndef HVM_PARAM_BUFIOREQ_EVTCHN
+#define HVM_PARAM_BUFIOREQ_EVTCHN 26
+#endif
 
 #define BUFFER_IO_MAX_DELAY  100
 
@@ -77,6 +80,8 @@ typedef struct XenIOState {
     QEMUTimer *buffered_io_timer;
     /* the evtchn port for polling the notification, */
     evtchn_port_t *ioreq_local_port;
+    /* evtchn local port for buffered io */
+    evtchn_port_t bufioreq_local_port;
     /* the evtchn fd for polling */
     XenEvtchn xce_handle;
     /* which vcpu we are serving */
@@ -549,6 +554,12 @@ static ioreq_t *cpu_get_ioreq(XenIOState *state)
     evtchn_port_t port;
 
     port = xc_evtchn_pending(state->xce_handle);
+    if (port == state->bufioreq_local_port) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+        return NULL;
+    }
+
     if (port != -1) {
         for (i = 0; i < smp_cpus; i++) {
             if (state->ioreq_local_port[i] == port) {
@@ -697,16 +708,18 @@ static void handle_ioreq(ioreq_t *req)
     }
 }
 
-static void handle_buffered_iopage(XenIOState *state)
+static int handle_buffered_iopage(XenIOState *state)
 {
     buf_ioreq_t *buf_req = NULL;
     ioreq_t req;
     int qw;
 
     if (!state->buffered_io_page) {
-        return;
+        return 0;
     }
 
+    memset(&req, 0x00, sizeof(req));
+
     while (state->buffered_io_page->read_pointer != state->buffered_io_page->write_pointer) {
         buf_req = &state->buffered_io_page->buf_ioreq[
             state->buffered_io_page->read_pointer % IOREQ_BUFFER_SLOT_NUM];
@@ -731,15 +744,21 @@ static void handle_buffered_iopage(XenIOState *state)
         xen_mb();
         state->buffered_io_page->read_pointer += qw ? 2 : 1;
     }
+
+    return req.count;
 }
 
 static void handle_buffered_io(void *opaque)
 {
     XenIOState *state = opaque;
 
-    handle_buffered_iopage(state);
-    qemu_mod_timer(state->buffered_io_timer,
-                   BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    if (handle_buffered_iopage(state)) {
+        qemu_mod_timer(state->buffered_io_timer,
+                BUFFER_IO_MAX_DELAY + qemu_get_clock_ms(rt_clock));
+    } else {
+        qemu_del_timer(state->buffered_io_timer);
+        xc_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+    }
 }
 
 static void cpu_handle_ioreq(void *opaque)
@@ -869,7 +888,6 @@ static void xen_main_loop_prepare(XenIOState *state)
 
     state->buffered_io_timer = qemu_new_timer_ms(rt_clock, handle_buffered_io,
                                                  state);
-    qemu_mod_timer(state->buffered_io_timer, qemu_get_clock_ms(rt_clock));
 
     if (evtchn_fd != -1) {
         qemu_set_fd_handler(evtchn_fd, cpu_handle_ioreq, NULL, state);
@@ -921,6 +939,7 @@ int xen_hvm_init(void)
 {
     int i, rc;
     unsigned long ioreq_pfn;
+    unsigned long bufioreq_evtchn;
     XenIOState *state;
 
     state = g_malloc0(sizeof (XenIOState));
@@ -970,6 +989,20 @@ int xen_hvm_init(void)
         state->ioreq_local_port[i] = rc;
     }
 
+    rc = xc_get_hvm_param(xen_xc, xen_domid, HVM_PARAM_BUFIOREQ_EVTCHN,
+            &bufioreq_evtchn);
+    if (rc < 0) {
+        fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+        return -1;
+    }
+    rc = xc_evtchn_bind_interdomain(state->xce_handle, xen_domid,
+            (uint32_t)bufioreq_evtchn);
+    if (rc == -1) {
+        fprintf(stderr, "bind interdomain ioctl error %d\n", errno);
+        return -1;
+    }
+    state->bufioreq_local_port = rc;
+
     /* Init RAM management */
     xen_map_cache_init();
     xen_ram_init(ram_size);
-- 
1.7.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:31:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGbV-00010p-Rq; Tue, 31 Jan 2012 16:30:45 +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 1RsGbU-00010i-F6
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:30:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328027436!9339783!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxODk0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6418 invoked from network); 31 Jan 2012 16:30:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 16:30:38 -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
	q0VGUX5i018818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 16:30:33 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0VGUVBV005714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 16:30:32 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
	q0VGUV6d032049; Tue, 31 Jan 2012 10:30:31 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 08:30:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DFC9540933; Tue, 31 Jan 2012 11:27:59 -0500 (EST)
Date: Tue, 31 Jan 2012 11:27:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120131162759.GA18248@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F28172A.0048,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen pvhvm: do not remap pirqs onto evtchns
 if !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:31:46PM +0000, Stefano Stabellini wrote:
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

So the xen_have_vector_callback looks to be only set by

1398         if (xen_feature(XENFEAT_hvm_callback_vector))
1399                 xen_have_vector_callback = 1;

So could this be just done via a check for that instead?


> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 492ade8..d99346e 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -374,7 +374,7 @@ int __init pci_xen_init(void)
>  
>  int __init pci_xen_hvm_init(void)
>  {
> -	if (!xen_feature(XENFEAT_hvm_pirqs))
> +	if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
>  		return 0;
>  
>  #ifdef CONFIG_ACPI
> --
> 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 Jan 31 16:31:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:31:04 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGbV-00010p-Rq; Tue, 31 Jan 2012 16:30:45 +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 1RsGbU-00010i-F6
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:30:44 +0000
X-Env-Sender: konrad.wilk@oracle.com
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328027436!9339783!1
X-Originating-IP: [141.146.126.227]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuMjI3ID0+IDUxODk0Mw==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6418 invoked from network); 31 Jan 2012 16:30:38 -0000
Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com)
	(141.146.126.227)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 16:30:38 -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
	q0VGUX5i018818
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Tue, 31 Jan 2012 16:30:33 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157])
	by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id
	q0VGUVBV005714
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 31 Jan 2012 16:30:32 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
	q0VGUV6d032049; Tue, 31 Jan 2012 10:30:31 -0600
Received: from phenom.dumpdata.com (/209.6.85.33)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Tue, 31 Jan 2012 08:30:30 -0800
Received: by phenom.dumpdata.com (Postfix, from userid 1000)
	id DFC9540933; Tue, 31 Jan 2012 11:27:59 -0500 (EST)
Date: Tue, 31 Jan 2012 11:27:59 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Message-ID: <20120131162759.GA18248@phenom.dumpdata.com>
References: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
X-CT-RefId: str=0001.0A090206.4F28172A.0048,ss=1,re=0.000,fgs=0
Cc: xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org
Subject: Re: [Xen-devel] [PATCH] xen pvhvm: do not remap pirqs onto evtchns
 if !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Mon, Jan 30, 2012 at 02:31:46PM +0000, Stefano Stabellini wrote:
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

So the xen_have_vector_callback looks to be only set by

1398         if (xen_feature(XENFEAT_hvm_callback_vector))
1399                 xen_have_vector_callback = 1;

So could this be just done via a check for that instead?


> 
> diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c
> index 492ade8..d99346e 100644
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
> @@ -374,7 +374,7 @@ int __init pci_xen_init(void)
>  
>  int __init pci_xen_hvm_init(void)
>  {
> -	if (!xen_feature(XENFEAT_hvm_pirqs))
> +	if (!xen_have_vector_callback || !xen_feature(XENFEAT_hvm_pirqs))
>  		return 0;
>  
>  #ifdef CONFIG_ACPI
> --
> 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 Jan 31 16:37:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:37:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGiB-0001AL-Nb; Tue, 31 Jan 2012 16:37:39 +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 1RsGi9-0001AD-NM
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:37:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328027849!12596936!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15325 invoked from network); 31 Jan 2012 16:37:31 -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;
	31 Jan 2012 16:37:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="179806352"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:37:28 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 31 Jan 2012
	11:37:28 -0500
Message-ID: <4F2818C7.1050702@citrix.com>
Date: Tue, 31 Jan 2012 16:37:27 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] PCI SERR NMI may cause Xen to deadlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
occurs while the CPU is in printk() then Xen may deadlock as
pci_serr_error() calls console_force_unlock() which screws up the
console lock.

I don't think removing the console_force_unlock() is sufficient as it
looks like printk() is unsafe to call from NMI context.  We would like
keep the diagnostic.  Does the following (untested) patch to defer the
printk() to a softirq look like a valid approach?

I also considered passing the NMI to dom0 (like other NMIs are) but I
couldn't see how NMIs were handled in the current upstream pv-ops kernels.

diff -r e2722b24dc09 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/traps.c	Tue Jan 31 16:28:45 2012 +0000
@@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
     st->vcpu = NULL;
 }

+static void pci_serr_softirq(void)
+{
+    printk("\n\nNMI - PCI system error (SERR)\n");
+}
+
 void async_exception_cleanup(struct vcpu *curr)
 {
     int trap;
@@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int

 static void pci_serr_error(struct cpu_user_regs *regs)
 {
-    console_force_unlock();
-    printk("\n\nNMI - PCI system error (SERR)\n");
-
     outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the PCI
SERR error line. */
+
+    /* Would like to print a diagnostic here but can't call printk()
+       from NMI context -- raise a softirq instead. */
+    raise_softirq(PCI_SERR_SOFTIRQ);
 }

 static void io_check_error(struct cpu_user_regs *regs)
@@ -3563,6 +3569,7 @@ void __init trap_init(void)
     cpu_init();

     open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
+    open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }

 long register_guest_nmi_callback(unsigned long address)
diff -r e2722b24dc09 xen/include/asm-x86/softirq.h
--- a/xen/include/asm-x86/softirq.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/softirq.h	Tue Jan 31 16:28:45 2012 +0000
@@ -6,6 +6,7 @@
 #define VCPU_KICK_SOFTIRQ      (NR_COMMON_SOFTIRQS + 2)

 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
-#define NR_ARCH_SOFTIRQS       4
+#define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
+#define NR_ARCH_SOFTIRQS       5

 #endif /* __ASM_SOFTIRQ_H__ */

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:37:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:37:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGiB-0001AL-Nb; Tue, 31 Jan 2012 16:37:39 +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 1RsGi9-0001AD-NM
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:37:37 +0000
X-Env-Sender: david.vrabel@citrix.com
X-Msg-Ref: server-13.tower-182.messagelabs.com!1328027849!12596936!1
X-Originating-IP: [66.165.176.63]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAyMjc3NTY=\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15325 invoked from network); 31 Jan 2012 16:37:31 -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;
	31 Jan 2012 16:37:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="179806352"
Received: from ftlpmailmx01.citrite.net ([10.13.107.65])
	by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 11:37:28 -0500
Received: from [10.80.2.76] (10.80.2.76) by FTLPMAILMX01.citrite.net
	(10.13.107.65) with Microsoft SMTP Server id 8.3.213.0; Tue, 31 Jan 2012
	11:37:28 -0500
Message-ID: <4F2818C7.1050702@citrix.com>
Date: Tue, 31 Jan 2012 16:37:27 +0000
From: David Vrabel <david.vrabel@citrix.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] PCI SERR NMI may cause Xen to deadlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
occurs while the CPU is in printk() then Xen may deadlock as
pci_serr_error() calls console_force_unlock() which screws up the
console lock.

I don't think removing the console_force_unlock() is sufficient as it
looks like printk() is unsafe to call from NMI context.  We would like
keep the diagnostic.  Does the following (untested) patch to defer the
printk() to a softirq look like a valid approach?

I also considered passing the NMI to dom0 (like other NMIs are) but I
couldn't see how NMIs were handled in the current upstream pv-ops kernels.

diff -r e2722b24dc09 xen/arch/x86/traps.c
--- a/xen/arch/x86/traps.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/traps.c	Tue Jan 31 16:28:45 2012 +0000
@@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
     st->vcpu = NULL;
 }

+static void pci_serr_softirq(void)
+{
+    printk("\n\nNMI - PCI system error (SERR)\n");
+}
+
 void async_exception_cleanup(struct vcpu *curr)
 {
     int trap;
@@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int

 static void pci_serr_error(struct cpu_user_regs *regs)
 {
-    console_force_unlock();
-    printk("\n\nNMI - PCI system error (SERR)\n");
-
     outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the PCI
SERR error line. */
+
+    /* Would like to print a diagnostic here but can't call printk()
+       from NMI context -- raise a softirq instead. */
+    raise_softirq(PCI_SERR_SOFTIRQ);
 }

 static void io_check_error(struct cpu_user_regs *regs)
@@ -3563,6 +3569,7 @@ void __init trap_init(void)
     cpu_init();

     open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
+    open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }

 long register_guest_nmi_callback(unsigned long address)
diff -r e2722b24dc09 xen/include/asm-x86/softirq.h
--- a/xen/include/asm-x86/softirq.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/softirq.h	Tue Jan 31 16:28:45 2012 +0000
@@ -6,6 +6,7 @@
 #define VCPU_KICK_SOFTIRQ      (NR_COMMON_SOFTIRQS + 2)

 #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
-#define NR_ARCH_SOFTIRQS       4
+#define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
+#define NR_ARCH_SOFTIRQS       5

 #endif /* __ASM_SOFTIRQ_H__ */

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:39:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGjI-0001Dd-6D; Tue, 31 Jan 2012 16:38:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsGjG-0001DQ-75
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:38:46 +0000
Received: from [85.158.138.51:22541] by server-1.bemta-3.messagelabs.com id
	7E/A4-09565-519182F4; Tue, 31 Jan 2012 16:38:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328027924!11456364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17478 invoked from network); 31 Jan 2012 16:38:44 -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;
	31 Jan 2012 16:38:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10397595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:38: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, 31 Jan 2012 16:38: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
	1RsGis-0005Tt-Dq; Tue, 31 Jan 2012 16:38:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsGis-0008ER-D0;
	Tue, 31 Jan 2012 16:38:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20264.6398.391503.37479@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 16:38:22 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327669569.26983.178.camel@zakaz.uk.xensource.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1327669569.26983.178.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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/24] mini-os: fix list.h include guard name"):
> mini-os: use BSD sys/queue.h instead of Linux list.h

Thanks, I have applied this one (with the related qemu patch and tag
update).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:39:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:39:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGjI-0001Dd-6D; Tue, 31 Jan 2012 16:38:48 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsGjG-0001DQ-75
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:38:46 +0000
Received: from [85.158.138.51:22541] by server-1.bemta-3.messagelabs.com id
	7E/A4-09565-519182F4; Tue, 31 Jan 2012 16:38:45 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-174.messagelabs.com!1328027924!11456364!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 17478 invoked from network); 31 Jan 2012 16:38:44 -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;
	31 Jan 2012 16:38:44 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10397595"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:38: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, 31 Jan 2012 16:38: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
	1RsGis-0005Tt-Dq; Tue, 31 Jan 2012 16:38:22 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsGis-0008ER-D0;
	Tue, 31 Jan 2012 16:38:22 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20264.6398.391503.37479@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 16:38:22 +0000
To: Ian Campbell <Ian.Campbell@citrix.com>
Newsgroups: chiark.mail.xen.devel
In-Reply-To: <1327669569.26983.178.camel@zakaz.uk.xensource.com>
References: <1327607111-15394-1-git-send-email-dgdegra@tycho.nsa.gov>
	<1327607111-15394-14-git-send-email-dgdegra@tycho.nsa.gov>
	<1327669569.26983.178.camel@zakaz.uk.xensource.com>
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] [PATCH 13/24] mini-os: fix list.h include guard name
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: 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/24] mini-os: fix list.h include guard name"):
> mini-os: use BSD sys/queue.h instead of Linux list.h

Thanks, I have applied this one (with the related qemu patch and tag
update).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:39:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGjU-0001Ev-JE; Tue, 31 Jan 2012 16:39:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGjT-0001Eh-GE
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:38:59 +0000
Received: from [85.158.138.51:23377] by server-5.bemta-3.messagelabs.com id
	D0/33-02363-229182F4; Tue, 31 Jan 2012 16:38:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328027937!11279444!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12007 invoked from network); 31 Jan 2012 16:38:58 -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;
	31 Jan 2012 16:38:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10397603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:38: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; Tue, 31 Jan 2012 16:38:43 +0000
Date: Tue, 31 Jan 2012 16:40:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120131162759.GA18248@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201311636380.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
	<20120131162759.GA18248@phenom.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen pvhvm: do not remap pirqs onto evtchns
 if !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 02:31:46PM +0000, Stefano Stabellini wrote:
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> So the xen_have_vector_callback looks to be only set by
> 
> 1398         if (xen_feature(XENFEAT_hvm_callback_vector))
> 1399                 xen_have_vector_callback = 1;
> 
> So could this be just done via a check for that instead?
> 

Sure, but I don't think it would be better: using
xen_have_vector_callback is more consistent and give us the flexibility
of allowing users to manually override it in the future.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:39:13 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:39:13 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGjU-0001Ev-JE; Tue, 31 Jan 2012 16:39:00 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsGjT-0001Eh-GE
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:38:59 +0000
Received: from [85.158.138.51:23377] by server-5.bemta-3.messagelabs.com id
	D0/33-02363-229182F4; Tue, 31 Jan 2012 16:38:58 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-16.tower-174.messagelabs.com!1328027937!11279444!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12007 invoked from network); 31 Jan 2012 16:38:58 -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;
	31 Jan 2012 16:38:58 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10397603"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:38: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; Tue, 31 Jan 2012 16:38:43 +0000
Date: Tue, 31 Jan 2012 16:40:26 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
In-Reply-To: <20120131162759.GA18248@phenom.dumpdata.com>
Message-ID: <alpine.DEB.2.00.1201311636380.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301429530.3196@kaball-desktop>
	<20120131162759.GA18248@phenom.dumpdata.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>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH] xen pvhvm: do not remap pirqs onto evtchns
 if !xen_have_vector_callback
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 30, 2012 at 02:31:46PM +0000, Stefano Stabellini wrote:
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 
> So the xen_have_vector_callback looks to be only set by
> 
> 1398         if (xen_feature(XENFEAT_hvm_callback_vector))
> 1399                 xen_have_vector_callback = 1;
> 
> So could this be just done via a check for that instead?
> 

Sure, but I don't think it would be better: using
xen_have_vector_callback is more consistent and give us the flexibility
of allowing users to manually override it in the future.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:50:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:50:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGu3-0001gU-Qp; Tue, 31 Jan 2012 16:49:55 +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 1RsGu2-0001gM-Ku
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:49:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328028540!52479490!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12709 invoked from network); 31 Jan 2012 16:49:01 -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; 31 Jan 2012 16:49:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 16:49:49 +0000
Message-Id: <4F2829BD02000078000702C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 16:49:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4F27F4C20200007800070203@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201311357520.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201311357520.3196@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] qemu-dm: unregister_iomem() broken?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 15:05, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> I have run a smoke test, here is the interesting part of the logs

I take it that it worked?

> without this patch:
> 
> 
> region type 0 at [f3000000,f3020000).
> squash iomem [f3020000, f3021000).
> region type 1 at [c100,c140).
> 
> 
> and now with this patch:
> 
> 
> region type 0 at [f3000000,f3020000).
> squash iomem [f3000000, f3020000).
> region type 1 at [c100,c140).

So it looks consistent now, while it apparently was inconsistent before
(and no-one noticed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:50:14 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:50:14 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGu3-0001gU-Qp; Tue, 31 Jan 2012 16:49:55 +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 1RsGu2-0001gM-Ku
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:49:54 +0000
X-Env-Sender: JBeulich@suse.com
X-Msg-Ref: server-5.tower-27.messagelabs.com!1328028540!52479490!1
X-Originating-IP: [130.57.49.28]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12709 invoked from network); 31 Jan 2012 16:49:01 -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; 31 Jan 2012 16:49:01 -0000
Received: from EMEA1-MTA by nat28.tlf.novell.com
	with Novell_GroupWise; Tue, 31 Jan 2012 16:49:49 +0000
Message-Id: <4F2829BD02000078000702C4@nat28.tlf.novell.com>
X-Mailer: Novell GroupWise Internet Agent 12.0.0 
Date: Tue, 31 Jan 2012 16:49:49 +0000
From: "Jan Beulich" <JBeulich@suse.com>
To: "Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
References: <4F27F4C20200007800070203@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201311357520.3196@kaball-desktop>
In-Reply-To: <alpine.DEB.2.00.1201311357520.3196@kaball-desktop>
Mime-Version: 1.0
Content-Disposition: inline
Cc: Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] qemu-dm: unregister_iomem() broken?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

>>> On 31.01.12 at 15:05, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> I have run a smoke test, here is the interesting part of the logs

I take it that it worked?

> without this patch:
> 
> 
> region type 0 at [f3000000,f3020000).
> squash iomem [f3020000, f3021000).
> region type 1 at [c100,c140).
> 
> 
> and now with this patch:
> 
> 
> region type 0 at [f3000000,f3020000).
> squash iomem [f3000000, f3020000).
> region type 1 at [c100,c140).

So it looks consistent now, while it apparently was inconsistent before
(and no-one noticed).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:51:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGv1-0001kL-94; Tue, 31 Jan 2012 16:50: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 1RsGuz-0001k2-O0
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:50:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1328028646!9009120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20527 invoked from network); 31 Jan 2012 16:50:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 16:50:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10398370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:50: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;
	Tue, 31 Jan 2012 16:50:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 31 Jan 2012 16:50:45 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [GIT PULL] libxl API updates backlog
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've built up a rather large backlog of patches. Many of them have been
posted before and acked so rather than spam the list with another big
mail bomb I am sending as a git pull request a large batch of those
patches which have been acked.

These were all posted before as part of either "libxl: drop
device_model_info" or "libxl: API updates + xl: JSON" (which in turn
were previously split out of "libxl: drop device_model_info, better
defaults support, stubdoms by default", the rest of which will come
later). A small number have been posted individually here or there.

FYI after this I have ~20 patches which form the "better defaults" part
of the series mentioned above. However this portion has been somewhat
heavily reworked since last time and would therefore benefit from a
repost, which I'll do soon, I hope.

The following changes since commit 175a8a1275de58cd67aa2ff9b617270b7697e08b:

  xen: do not remap pirqs if !is_hvm_pv_evtchn_domain (2012-01-31 11:39:37 +0000)

are available in the git repository at:
  git://xenbits.xen.org/people/ianc/xen-unstable.git for-ianj/libxl

Ian Campbell (34):
      libxl: remove libxl_domain_create_info.poolname
      libxl: name libxl_create_cpupool consistent with other functions
      libxl: do not write/maintain "pool_name" in XenStore
      libxl: remove comment support from IDL
      libxl: use keyword arguments for field definitions in aggregate types
      ocaml: use libxl IDL type helpers for C argument passing
      libxl: define libxl_vnc_info to hold all info about the vnc info
      libxl: define libxl_spice_info to hold all info about the spice server
      libxl: define libxl_sdl_info to hold all info about the SDL config
      libxl: plumb libxl_domain_config down into device model creation
      libxl: now that dm creation takes domain_config stop passing down devices
      libxl: remove redundant info from dm info
      libxl: drop dm_info.dom_name
      libxl: use vfb[0] directly for xenpv device model
      libxl: move HVM emulated GFX support into b_info->u.hvm
      libxl: HVM device configuration info build_info->u.hvm
      libxl: move gfx_passthru setting to b_info->u.hvm
      libxl: Remove libxl_device_model_info.type
      libxl: remove uuid from device model info
      libxl: move device model selection variables to b_info
      libxl: move "saved_state" to libxl__domain_build_state
      libxl: remove libxl_device_model_info
      libxl: only write "disable_pf" key to xenstore when it makes sense
      libxl: Rename libxl IDL infrastructure
      libxl: de-hard-tabbify idl.txt
      libxl: remove libxl_button_press in favour of libxl_send_trigger
      ocaml: add helpers for Some/None option types
      ocaml: Topology.get returns an array not a single element
      libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps
      libxl: drop libxl_cpuarray -- topology was the only user
      libxl: add named enum for timer mode
      xl: use json output by default
      docs: document /etc/xen/xl.conf
      xl: allow enable automatic fallback to ACPI events if PV control not available

 docs/man/xl.conf.pod.5                |   93 +++++
 docs/man/xl.pod.1                     |   38 ++-
 tools/hotplug/Linux/init.d/xendomains |   21 +-
 tools/libxl/Makefile                  |    4 +-
 tools/libxl/gentest.py                |   40 +--
 tools/libxl/gentypes.py               |   57 +--
 tools/libxl/{libxltypes.py => idl.py} |   26 +-
 tools/libxl/idl.txt                   |   83 ++---
 tools/libxl/libxl.c                   |  267 ++++++-------
 tools/libxl/libxl.h                   |   28 +-
 tools/libxl/libxl_create.c            |  111 ++----
 tools/libxl/libxl_dm.c                |  718 ++++++++++++++++++---------------
 tools/libxl/libxl_dom.c               |   19 +-
 tools/libxl/libxl_internal.h          |   23 +-
 tools/libxl/libxl_json.c              |  173 +++++++-
 tools/libxl/libxl_json.h              |    3 +
 tools/libxl/libxl_types.idl           |  206 +++++-----
 tools/libxl/libxl_utils.c             |   32 +--
 tools/libxl/libxl_utils.h             |    2 -
 tools/libxl/libxl_uuid.c              |    4 +-
 tools/libxl/libxl_uuid.h              |    2 +-
 tools/libxl/xl.c                      |   10 +
 tools/libxl/xl.h                      |    8 +
 tools/libxl/xl_cmdimpl.c              |  507 ++++++++++-------------
 tools/libxl/xl_sxp.c                  |  220 ++++++++++
 tools/ocaml/libs/xl/Makefile          |    2 +-
 tools/ocaml/libs/xl/genwrap.py        |   63 ++--
 tools/ocaml/libs/xl/xenlight.ml.in    |   15 +-
 tools/ocaml/libs/xl/xenlight.mli.in   |   14 +-
 tools/ocaml/libs/xl/xenlight_stubs.c  |   82 ++---
 tools/python/Makefile                 |    2 +-
 tools/python/genwrap.py               |   35 +-
 tools/python/xen/lowlevel/xl/xl.c     |   24 --
 33 files changed, 1626 insertions(+), 1306 deletions(-)
 create mode 100644 docs/man/xl.conf.pod.5
 rename tools/libxl/{libxltypes.py => idl.py} (92%)
 create mode 100644 tools/libxl/xl_sxp.c



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:51:08 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:51:08 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsGv1-0001kL-94; Tue, 31 Jan 2012 16:50: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 1RsGuz-0001k2-O0
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:50:53 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-15.tower-21.messagelabs.com!1328028646!9009120!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20527 invoked from network); 31 Jan 2012 16:50:47 -0000
Received: from smtp.eu.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-15.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 16:50:47 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10398370"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:50: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;
	Tue, 31 Jan 2012 16:50:45 +0000
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Date: Tue, 31 Jan 2012 16:50:45 +0000
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.0.3- 
Message-ID: <1328028645.26983.439.camel@zakaz.uk.xensource.com>
MIME-Version: 1.0
Cc: xen-devel <xen-devel@lists.xensource.com>
Subject: [Xen-devel] [GIT PULL] libxl API updates backlog
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

I've built up a rather large backlog of patches. Many of them have been
posted before and acked so rather than spam the list with another big
mail bomb I am sending as a git pull request a large batch of those
patches which have been acked.

These were all posted before as part of either "libxl: drop
device_model_info" or "libxl: API updates + xl: JSON" (which in turn
were previously split out of "libxl: drop device_model_info, better
defaults support, stubdoms by default", the rest of which will come
later). A small number have been posted individually here or there.

FYI after this I have ~20 patches which form the "better defaults" part
of the series mentioned above. However this portion has been somewhat
heavily reworked since last time and would therefore benefit from a
repost, which I'll do soon, I hope.

The following changes since commit 175a8a1275de58cd67aa2ff9b617270b7697e08b:

  xen: do not remap pirqs if !is_hvm_pv_evtchn_domain (2012-01-31 11:39:37 +0000)

are available in the git repository at:
  git://xenbits.xen.org/people/ianc/xen-unstable.git for-ianj/libxl

Ian Campbell (34):
      libxl: remove libxl_domain_create_info.poolname
      libxl: name libxl_create_cpupool consistent with other functions
      libxl: do not write/maintain "pool_name" in XenStore
      libxl: remove comment support from IDL
      libxl: use keyword arguments for field definitions in aggregate types
      ocaml: use libxl IDL type helpers for C argument passing
      libxl: define libxl_vnc_info to hold all info about the vnc info
      libxl: define libxl_spice_info to hold all info about the spice server
      libxl: define libxl_sdl_info to hold all info about the SDL config
      libxl: plumb libxl_domain_config down into device model creation
      libxl: now that dm creation takes domain_config stop passing down devices
      libxl: remove redundant info from dm info
      libxl: drop dm_info.dom_name
      libxl: use vfb[0] directly for xenpv device model
      libxl: move HVM emulated GFX support into b_info->u.hvm
      libxl: HVM device configuration info build_info->u.hvm
      libxl: move gfx_passthru setting to b_info->u.hvm
      libxl: Remove libxl_device_model_info.type
      libxl: remove uuid from device model info
      libxl: move device model selection variables to b_info
      libxl: move "saved_state" to libxl__domain_build_state
      libxl: remove libxl_device_model_info
      libxl: only write "disable_pf" key to xenstore when it makes sense
      libxl: Rename libxl IDL infrastructure
      libxl: de-hard-tabbify idl.txt
      libxl: remove libxl_button_press in favour of libxl_send_trigger
      ocaml: add helpers for Some/None option types
      ocaml: Topology.get returns an array not a single element
      libxl: expose cpu topology as a single list of cpu->{node, core, socket} maps
      libxl: drop libxl_cpuarray -- topology was the only user
      libxl: add named enum for timer mode
      xl: use json output by default
      docs: document /etc/xen/xl.conf
      xl: allow enable automatic fallback to ACPI events if PV control not available

 docs/man/xl.conf.pod.5                |   93 +++++
 docs/man/xl.pod.1                     |   38 ++-
 tools/hotplug/Linux/init.d/xendomains |   21 +-
 tools/libxl/Makefile                  |    4 +-
 tools/libxl/gentest.py                |   40 +--
 tools/libxl/gentypes.py               |   57 +--
 tools/libxl/{libxltypes.py => idl.py} |   26 +-
 tools/libxl/idl.txt                   |   83 ++---
 tools/libxl/libxl.c                   |  267 ++++++-------
 tools/libxl/libxl.h                   |   28 +-
 tools/libxl/libxl_create.c            |  111 ++----
 tools/libxl/libxl_dm.c                |  718 ++++++++++++++++++---------------
 tools/libxl/libxl_dom.c               |   19 +-
 tools/libxl/libxl_internal.h          |   23 +-
 tools/libxl/libxl_json.c              |  173 +++++++-
 tools/libxl/libxl_json.h              |    3 +
 tools/libxl/libxl_types.idl           |  206 +++++-----
 tools/libxl/libxl_utils.c             |   32 +--
 tools/libxl/libxl_utils.h             |    2 -
 tools/libxl/libxl_uuid.c              |    4 +-
 tools/libxl/libxl_uuid.h              |    2 +-
 tools/libxl/xl.c                      |   10 +
 tools/libxl/xl.h                      |    8 +
 tools/libxl/xl_cmdimpl.c              |  507 ++++++++++-------------
 tools/libxl/xl_sxp.c                  |  220 ++++++++++
 tools/ocaml/libs/xl/Makefile          |    2 +-
 tools/ocaml/libs/xl/genwrap.py        |   63 ++--
 tools/ocaml/libs/xl/xenlight.ml.in    |   15 +-
 tools/ocaml/libs/xl/xenlight.mli.in   |   14 +-
 tools/ocaml/libs/xl/xenlight_stubs.c  |   82 ++---
 tools/python/Makefile                 |    2 +-
 tools/python/genwrap.py               |   35 +-
 tools/python/xen/lowlevel/xl/xl.c     |   24 --
 33 files changed, 1626 insertions(+), 1306 deletions(-)
 create mode 100644 docs/man/xl.conf.pod.5
 rename tools/libxl/{libxltypes.py => idl.py} (92%)
 create mode 100644 tools/libxl/xl_sxp.c



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:52:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16: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 1RsGwK-0001u3-Uy; Tue, 31 Jan 2012 16:52:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <allen.m.kay@intel.com>) id 1RsGwK-0001tq-4N
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:52:16 +0000
Received: from [85.158.138.51:41534] by server-8.bemta-3.messagelabs.com id
	A8/42-31878-F3C182F4; Tue, 31 Jan 2012 16:52:15 +0000
X-Env-Sender: allen.m.kay@intel.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328028734!11445657!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNDU2OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29468 invoked from network); 31 Jan 2012 16:52:14 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-174.messagelabs.com with SMTP;
	31 Jan 2012 16:52:14 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 31 Jan 2012 08:52:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="112473087"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by fmsmga001.fm.intel.com with ESMTP; 31 Jan 2012 08:52:13 -0800
Received: from orsmsx102.amr.corp.intel.com (10.22.225.129) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 31 Jan 2012 08:52:12 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.3]) by
	ORSMSX102.amr.corp.intel.com ([169.254.1.146]) with mapi id
	14.01.0355.002; Tue, 31 Jan 2012 08:52:08 -0800
From: "Kay, Allen M" <allen.m.kay@intel.com>
To: Jean Guyader <jean.guyader@eu.citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] Intel GPU passthrough: Host bridge config space
Thread-Index: AczUZ/rLeegF0284Tr6G2NK7hpSpQAL0KmRA
Date: Tue, 31 Jan 2012 16:52:11 +0000
Message-ID: <003AAFE53969E14CB1F09B6FD68C3CD409F0F8@ORSMSX105.amr.corp.intel.com>
References: <1326729625-26264-1-git-send-email-jean.guyader@eu.citrix.com>
In-Reply-To: <1326729625-26264-1-git-send-email-jean.guyader@eu.citrix.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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config
	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

Looks good.  Ack!

Allen

-----Original Message-----
From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] 
Sent: Monday, January 16, 2012 8:00 AM
To: xen-devel@lists.xensource.com
Cc: Kay, Allen M; Ian Jackson; Jean Guyader
Subject: [PATCH] Intel GPU passthrough: Host bridge config space


Expose more host bridge config space value to make the driver happy for all the different revisions of the device.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:52:32 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16: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 1RsGwK-0001u3-Uy; Tue, 31 Jan 2012 16:52:16 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <allen.m.kay@intel.com>) id 1RsGwK-0001tq-4N
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:52:16 +0000
Received: from [85.158.138.51:41534] by server-8.bemta-3.messagelabs.com id
	A8/42-31878-F3C182F4; Tue, 31 Jan 2012 16:52:15 +0000
X-Env-Sender: allen.m.kay@intel.com
X-Msg-Ref: server-6.tower-174.messagelabs.com!1328028734!11445657!1
X-Originating-IP: [192.55.52.88]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogMTkyLjU1LjUyLjg4ID0+IDMwNDU2OA==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29468 invoked from network); 31 Jan 2012 16:52:14 -0000
Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88)
	by server-6.tower-174.messagelabs.com with SMTP;
	31 Jan 2012 16:52:14 -0000
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 31 Jan 2012 08:52:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="112473087"
Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49])
	by fmsmga001.fm.intel.com with ESMTP; 31 Jan 2012 08:52:13 -0800
Received: from orsmsx102.amr.corp.intel.com (10.22.225.129) by
	orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server
	(TLS) id 8.2.255.0; Tue, 31 Jan 2012 08:52:12 -0800
Received: from orsmsx105.amr.corp.intel.com ([169.254.4.3]) by
	ORSMSX102.amr.corp.intel.com ([169.254.1.146]) with mapi id
	14.01.0355.002; Tue, 31 Jan 2012 08:52:08 -0800
From: "Kay, Allen M" <allen.m.kay@intel.com>
To: Jean Guyader <jean.guyader@eu.citrix.com>, "xen-devel@lists.xensource.com"
	<xen-devel@lists.xensource.com>
Thread-Topic: [PATCH] Intel GPU passthrough: Host bridge config space
Thread-Index: AczUZ/rLeegF0284Tr6G2NK7hpSpQAL0KmRA
Date: Tue, 31 Jan 2012 16:52:11 +0000
Message-ID: <003AAFE53969E14CB1F09B6FD68C3CD409F0F8@ORSMSX105.amr.corp.intel.com>
References: <1326729625-26264-1-git-send-email-jean.guyader@eu.citrix.com>
In-Reply-To: <1326729625-26264-1-git-send-email-jean.guyader@eu.citrix.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: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jean Guyader <Jean.Guyader@citrix.com>
Subject: Re: [Xen-devel] [PATCH] Intel GPU passthrough: Host bridge config
	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

Looks good.  Ack!

Allen

-----Original Message-----
From: Jean Guyader [mailto:jean.guyader@eu.citrix.com] 
Sent: Monday, January 16, 2012 8:00 AM
To: xen-devel@lists.xensource.com
Cc: Kay, Allen M; Ian Jackson; Jean Guyader
Subject: [PATCH] Intel GPU passthrough: Host bridge config space


Expose more host bridge config space value to make the driver happy for all the different revisions of the device.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:57:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsH1M-0002GH-SV; Tue, 31 Jan 2012 16:57:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsH1K-0002G1-S4
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:57:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328029040!12594405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 581 invoked from network); 31 Jan 2012 16:57:20 -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;
	31 Jan 2012 16:57:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10398521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:57:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 16:57:20 +0000
Date: Tue, 31 Jan 2012 16:59:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F2829BD02000078000702C4@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201311653270.3196@kaball-desktop>
References: <4F27F4C20200007800070203@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201311357520.3196@kaball-desktop>
	<4F2829BD02000078000702C4@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu-dm: unregister_iomem() broken?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Jan Beulich wrote:
> >>> On 31.01.12 at 15:05, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > I have run a smoke test, here is the interesting part of the logs
> 
> I take it that it worked?

Yes: the guest booted correctly, no emulated disks or nics present.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 16:57:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 16:57:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsH1M-0002GH-SV; Tue, 31 Jan 2012 16:57:28 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsH1K-0002G1-S4
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 16:57:27 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-5.tower-216.messagelabs.com!1328029040!12594405!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 581 invoked from network); 31 Jan 2012 16:57:20 -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;
	31 Jan 2012 16:57:20 -0000
X-IronPort-AV: E=Sophos;i="4.71,596,1320624000"; d="scan'208";a="10398521"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 16:57:20 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 16:57:20 +0000
Date: Tue, 31 Jan 2012 16:59:03 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Jan Beulich <JBeulich@suse.com>
In-Reply-To: <4F2829BD02000078000702C4@nat28.tlf.novell.com>
Message-ID: <alpine.DEB.2.00.1201311653270.3196@kaball-desktop>
References: <4F27F4C20200007800070203@nat28.tlf.novell.com>
	<alpine.DEB.2.00.1201311357520.3196@kaball-desktop>
	<4F2829BD02000078000702C4@nat28.tlf.novell.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Cc: Haitao Shan <haitao.shan@intel.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] qemu-dm: unregister_iomem() broken?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Tue, 31 Jan 2012, Jan Beulich wrote:
> >>> On 31.01.12 at 15:05, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> > I have run a smoke test, here is the interesting part of the logs
> 
> I take it that it worked?

Yes: the guest booted correctly, no emulated disks or nics present.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:10:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17: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 1RsHDg-0002VU-7W; Tue, 31 Jan 2012 17:10:12 +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 1RsHDe-0002VP-Hw
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:10:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328029788!63953780!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11612 invoked from network); 31 Jan 2012 17:09:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 17:09:48 -0000
Received: by werb14 with SMTP id b14so406988wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:10:09 -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=BCA8qctd56fURPoztsC3dtDFOVqknR2YxUC8oFkqIfs=;
	b=VEKLAykouWbJSTBTboMcTF0RQJA9kGARlwtl5QOemJZw382NY87oaO0Pp+WkgVRo+c
	nY+as2sei+JDNtlVZTAf0ZWKMAIeYl37JbvgbdJ9BCID53z/kCpnSN13NopYsWz1apCf
	qOcdi5iuBPxHGBcYstGdH3RGqcC7EAK+Qc3LA=
Received: by 10.216.137.7 with SMTP id x7mr1272547wei.52.1328029809072;
	Tue, 31 Jan 2012 09:10:09 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id j16sm64753142wie.4.2012.01.31.09.10.07
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 09:10:08 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 31 Jan 2012 17:09:56 +0000
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB4DD0E4.38A78%keir@xen.org>
Thread-Topic: [Xen-devel] PCI SERR NMI may cause Xen to deadlock
Thread-Index: AczgOyepb+SgW9rjvEeC7wMd8aq7zw==
In-Reply-To: <4F2818C7.1050702@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] PCI SERR NMI may cause Xen to deadlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 31/01/2012 16:37, "David Vrabel" <david.vrabel@citrix.com> wrote:

> If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
> occurs while the CPU is in printk() then Xen may deadlock as
> pci_serr_error() calls console_force_unlock() which screws up the
> console lock.
> 
> I don't think removing the console_force_unlock() is sufficient as it
> looks like printk() is unsafe to call from NMI context.  We would like
> keep the diagnostic.  Does the following (untested) patch to defer the
> printk() to a softirq look like a valid approach?

Yes, if the NMI is non-fatal then console_force_unlock() cannot be used. So
your only other option is to defer the printk.

 -- Keir

> I also considered passing the NMI to dom0 (like other NMIs are) but I
> couldn't see how NMIs were handled in the current upstream pv-ops kernels.
> 
> diff -r e2722b24dc09 xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/traps.c Tue Jan 31 16:28:45 2012 +0000
> @@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
>      st->vcpu = NULL;
>  }
> 
> +static void pci_serr_softirq(void)
> +{
> +    printk("\n\nNMI - PCI system error (SERR)\n");
> +}
> +
>  void async_exception_cleanup(struct vcpu *curr)
>  {
>      int trap;
> @@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int
> 
>  static void pci_serr_error(struct cpu_user_regs *regs)
>  {
> -    console_force_unlock();
> -    printk("\n\nNMI - PCI system error (SERR)\n");
> -
>      outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the PCI
> SERR error line. */
> +
> +    /* Would like to print a diagnostic here but can't call printk()
> +       from NMI context -- raise a softirq instead. */
> +    raise_softirq(PCI_SERR_SOFTIRQ);
>  }
> 
>  static void io_check_error(struct cpu_user_regs *regs)
> @@ -3563,6 +3569,7 @@ void __init trap_init(void)
>      cpu_init();
> 
>      open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
> +    open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
>  }
> 
>  long register_guest_nmi_callback(unsigned long address)
> diff -r e2722b24dc09 xen/include/asm-x86/softirq.h
> --- a/xen/include/asm-x86/softirq.h Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/softirq.h Tue Jan 31 16:28:45 2012 +0000
> @@ -6,6 +6,7 @@
>  #define VCPU_KICK_SOFTIRQ      (NR_COMMON_SOFTIRQS + 2)
> 
>  #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
> -#define NR_ARCH_SOFTIRQS       4
> +#define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
> +#define NR_ARCH_SOFTIRQS       5
> 
>  #endif /* __ASM_SOFTIRQ_H__ */
> 
> 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 Jan 31 17:10:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17: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 1RsHDg-0002VU-7W; Tue, 31 Jan 2012 17:10:12 +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 1RsHDe-0002VP-Hw
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:10:10 +0000
X-Env-Sender: keir.xen@gmail.com
X-Msg-Ref: server-15.tower-27.messagelabs.com!1328029788!63953780!1
X-Originating-IP: [74.125.82.171]
X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11612 invoked from network); 31 Jan 2012 17:09:48 -0000
Received: from mail-we0-f171.google.com (HELO mail-we0-f171.google.com)
	(74.125.82.171)
	by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 17:09:48 -0000
Received: by werb14 with SMTP id b14so406988wer.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:10:09 -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=BCA8qctd56fURPoztsC3dtDFOVqknR2YxUC8oFkqIfs=;
	b=VEKLAykouWbJSTBTboMcTF0RQJA9kGARlwtl5QOemJZw382NY87oaO0Pp+WkgVRo+c
	nY+as2sei+JDNtlVZTAf0ZWKMAIeYl37JbvgbdJ9BCID53z/kCpnSN13NopYsWz1apCf
	qOcdi5iuBPxHGBcYstGdH3RGqcC7EAK+Qc3LA=
Received: by 10.216.137.7 with SMTP id x7mr1272547wei.52.1328029809072;
	Tue, 31 Jan 2012 09:10:09 -0800 (PST)
Received: from [192.168.1.3] (host86-153-23-164.range86-153.btcentralplus.com.
	[86.153.23.164])
	by mx.google.com with ESMTPS id j16sm64753142wie.4.2012.01.31.09.10.07
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 09:10:08 -0800 (PST)
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Tue, 31 Jan 2012 17:09:56 +0000
From: Keir Fraser <keir@xen.org>
To: David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Message-ID: <CB4DD0E4.38A78%keir@xen.org>
Thread-Topic: [Xen-devel] PCI SERR NMI may cause Xen to deadlock
Thread-Index: AczgOyepb+SgW9rjvEeC7wMd8aq7zw==
In-Reply-To: <4F2818C7.1050702@citrix.com>
Mime-version: 1.0
Subject: Re: [Xen-devel] PCI SERR NMI may cause Xen to deadlock
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On 31/01/2012 16:37, "David Vrabel" <david.vrabel@citrix.com> wrote:

> If a PCI System Error (SERR) is asserted it causes an NMI. If this NMI
> occurs while the CPU is in printk() then Xen may deadlock as
> pci_serr_error() calls console_force_unlock() which screws up the
> console lock.
> 
> I don't think removing the console_force_unlock() is sufficient as it
> looks like printk() is unsafe to call from NMI context.  We would like
> keep the diagnostic.  Does the following (untested) patch to defer the
> printk() to a softirq look like a valid approach?

Yes, if the NMI is non-fatal then console_force_unlock() cannot be used. So
your only other option is to defer the printk.

 -- Keir

> I also considered passing the NMI to dom0 (like other NMIs are) but I
> couldn't see how NMIs were handled in the current upstream pv-ops kernels.
> 
> diff -r e2722b24dc09 xen/arch/x86/traps.c
> --- a/xen/arch/x86/traps.c Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/arch/x86/traps.c Tue Jan 31 16:28:45 2012 +0000
> @@ -3173,6 +3173,11 @@ static void nmi_mce_softirq(void)
>      st->vcpu = NULL;
>  }
> 
> +static void pci_serr_softirq(void)
> +{
> +    printk("\n\nNMI - PCI system error (SERR)\n");
> +}
> +
>  void async_exception_cleanup(struct vcpu *curr)
>  {
>      int trap;
> @@ -3259,10 +3264,11 @@ static void nmi_dom0_report(unsigned int
> 
>  static void pci_serr_error(struct cpu_user_regs *regs)
>  {
> -    console_force_unlock();
> -    printk("\n\nNMI - PCI system error (SERR)\n");
> -
>      outb((inb(0x61) & 0x0f) | 0x04, 0x61); /* clear-and-disable the PCI
> SERR error line. */
> +
> +    /* Would like to print a diagnostic here but can't call printk()
> +       from NMI context -- raise a softirq instead. */
> +    raise_softirq(PCI_SERR_SOFTIRQ);
>  }
> 
>  static void io_check_error(struct cpu_user_regs *regs)
> @@ -3563,6 +3569,7 @@ void __init trap_init(void)
>      cpu_init();
> 
>      open_softirq(NMI_MCE_SOFTIRQ, nmi_mce_softirq);
> +    open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
>  }
> 
>  long register_guest_nmi_callback(unsigned long address)
> diff -r e2722b24dc09 xen/include/asm-x86/softirq.h
> --- a/xen/include/asm-x86/softirq.h Thu Jan 26 17:43:31 2012 +0000
> +++ b/xen/include/asm-x86/softirq.h Tue Jan 31 16:28:45 2012 +0000
> @@ -6,6 +6,7 @@
>  #define VCPU_KICK_SOFTIRQ      (NR_COMMON_SOFTIRQS + 2)
> 
>  #define MACHINE_CHECK_SOFTIRQ  (NR_COMMON_SOFTIRQS + 3)
> -#define NR_ARCH_SOFTIRQS       4
> +#define PCI_SERR_SOFTIRQ       (NR_COMMON_SOFTIRQS + 4)
> +#define NR_ARCH_SOFTIRQS       5
> 
>  #endif /* __ASM_SOFTIRQ_H__ */
> 
> 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 Jan 31 17:21:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHOC-0002kH-Ji; Tue, 31 Jan 2012 17:21:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RsHOB-0002jz-0O
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:21:03 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328030455!9348116!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8181 invoked from network); 31 Jan 2012 17:20:56 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:20:56 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0VHKVwD022661;
	Tue, 31 Jan 2012 12:20:31 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 31 Jan 2012 12:20:20 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451D4@mnetexch2.adamapps.host>
In-Reply-To: <CAEc3jaArdDQL5+k-jdgW0idGpoUpq4CXzfg4QafJ660B8OjiRg@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: Aczfh02OP+4KKHczThOZ3aw1zFRdRAAtPecg
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au><EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host><EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au><CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com><EECC125FCE18E740AF561189E12602851451CE@mnetexch2.adamapps.host>
	<CAEc3jaArdDQL5+k-jdgW0idGpoUpq4CXzfg4QafJ660B8OjiRg@mail.gmail.com>
From: <djmagee@mageenet.net>
To: "Roderick Colenbrander" <thunderbird2k@gmail.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: James Harper <james.harper@bendigoit.com.au>, xen-devel@lists.xensource.com,
	lta@akr.fm
Subject: Re: [Xen-devel] GPLPV and pci passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Mon, Jan 30, 2012 at 7:22 PM,  <djmagee@mageenet.net> wrote:
> >> I have had weird network problems as well using the 308 drivers.
For
> >> me the 356 drivers from the hg repository do work fine, so
something
> >> between 308 and 356 fixed some network bugs. Perhaps put a test
> build
> >> on the website for him to try?
> >>
> >
> > I already have the Windows DDK installed on a couple of machines,
but
> > the link to the hg repo at
> > http://wiki.xen.org/wiki/Xen_Windows_GplPv/Building seems to be
> broken.
> > Where's the current repo housed?
> 
> You can find it here:
> http://xenbits.xen.org/ext/win-pvdrivers/
> 
> Look at the README file of the source tree for additional build
> instructions.
> 
> Roderick

Thanks, that was easy enough.

I built the latest code available from the hg repo and I have the same
symptoms.  I'll dig around and see if I can find a good place to dump
some debug output and track down the problem.

Doug

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:21:26 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:21:26 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHOC-0002kH-Ji; Tue, 31 Jan 2012 17:21:04 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <djmagee@mageenet.net>) id 1RsHOB-0002jz-0O
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:21:03 +0000
X-Env-Sender: djmagee@mageenet.net
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328030455!9348116!1
X-Originating-IP: [64.78.148.213]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 8181 invoked from network); 31 Jan 2012 17:20:56 -0000
Received: from host213.adamapps.net (HELO host213.adamapps.net) (64.78.148.213)
	by server-7.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:20:56 -0000
Received: from mnetexch2.adamapps.host ([172.23.68.3])
	by host213.adamapps.net (8.13.8/8.13.8) with ESMTP id q0VHKVwD022661;
	Tue, 31 Jan 2012 12:20:31 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 31 Jan 2012 12:20:20 -0500
Message-ID: <EECC125FCE18E740AF561189E12602851451D4@mnetexch2.adamapps.host>
In-Reply-To: <CAEc3jaArdDQL5+k-jdgW0idGpoUpq4CXzfg4QafJ660B8OjiRg@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Xen-devel] GPLPV and pci passthrough
Thread-Index: Aczfh02OP+4KKHczThOZ3aw1zFRdRAAtPecg
References: <EECC125FCE18E740AF561189E12602851451C8@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B054FE179@BITCOM1.int.sbss.com.au><EECC125FCE18E740AF561189E12602851451CB@mnetexch2.adamapps.host><EECC125FCE18E740AF561189E12602851451CC@mnetexch2.adamapps.host><6035A0D088A63A46850C3988ED045A4B0550711F@BITCOM1.int.sbss.com.au><CAEc3jaC_Z3XE-BQxEOaonfNDo94oZV_kOqy9z-ZdtUjuJfV9bg@mail.gmail.com><EECC125FCE18E740AF561189E12602851451CE@mnetexch2.adamapps.host>
	<CAEc3jaArdDQL5+k-jdgW0idGpoUpq4CXzfg4QafJ660B8OjiRg@mail.gmail.com>
From: <djmagee@mageenet.net>
To: "Roderick Colenbrander" <thunderbird2k@gmail.com>
X-Spam-Score: undef - spam scanning disabled
X-CanItPRO-Stream: internal
X-Canit-Stats-ID: Bayes signature not available
Cc: James Harper <james.harper@bendigoit.com.au>, xen-devel@lists.xensource.com,
	lta@akr.fm
Subject: Re: [Xen-devel] GPLPV and pci passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

> On Mon, Jan 30, 2012 at 7:22 PM,  <djmagee@mageenet.net> wrote:
> >> I have had weird network problems as well using the 308 drivers.
For
> >> me the 356 drivers from the hg repository do work fine, so
something
> >> between 308 and 356 fixed some network bugs. Perhaps put a test
> build
> >> on the website for him to try?
> >>
> >
> > I already have the Windows DDK installed on a couple of machines,
but
> > the link to the hg repo at
> > http://wiki.xen.org/wiki/Xen_Windows_GplPv/Building seems to be
> broken.
> > Where's the current repo housed?
> 
> You can find it here:
> http://xenbits.xen.org/ext/win-pvdrivers/
> 
> Look at the README file of the source tree for additional build
> instructions.
> 
> Roderick

Thanks, that was easy enough.

I built the latest code available from the hg repo and I have the same
symptoms.  I'll dig around and see if I can find a good place to dump
some debug output and track down the problem.

Doug

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:24:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17: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 1RsHR8-0002sq-6m; Tue, 31 Jan 2012 17:24:06 +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 1RsHR6-0002sU-9u
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:24:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328030634!10802811!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16047 invoked from network); 31 Jan 2012 17:23:56 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:23:56 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHNpPV006609
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:23:52 -0800
Received: by bkbzv3 with SMTP id zv3so361974bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:23:49 -0800 (PST)
Received: by 10.204.154.86 with SMTP id n22mr10746607bkw.85.1328030629425;
	Tue, 31 Jan 2012 09:23:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:23:09 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:23:09 -0800
Message-ID: <CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============3976202373544603632=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3976202373544603632==
Content-Type: multipart/alternative; boundary=0015175d0396eaf25604b7d639cf

--0015175d0396eaf25604b7d639cf
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2012-01-31, at 7:08 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> On Tue, 31 Jan 2012, Stefano Stabellini wrote:
>> On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
>>> On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:
>>>     Introduce a new save_id to save/restore toolstack specific extra
>>>     information.
>>>
>>>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com=
>
>>>     ---
>>> =C3=82=C2 tools/libxc/xc_domain_restore.c | =C3=82=C2  32
+++++++++++++++++++++++++++++++-
>>> =C3=82=C2 tools/libxc/xc_domain_save.c =C3=82=C2  =C3=82=C2 | =C3=82=C2=
  17 +++++++++++++++++
>>> =C3=82=C2 tools/libxc/xenguest.h =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  =C3=82=C2 | =C3=82=C2  23
++++++++++++++++++++++-
>>> =C3=82=C2 tools/libxc/xg_save_restore.h =C3=82=C2  | =C3=82=C2  =C3=82=
=C2 1 +
>>> =C3=82=C2 tools/libxl/libxl_dom.c =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  | =C3=82=C2  =C3=82=C2 2 +-
>>> =C3=82=C2 tools/xcutils/xc_restore.c =C3=82=C2  =C3=82=C2  =C3=82=C2 | =
=C3=82=C2  =C3=82=C2 2 +-
>>> =C3=82=C2 6 files changed, 73 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tools/libxc/xc_domain_restore.c
b/tools/libxc/xc_domain_restore.c
>>> index 3fda6f8..ead3df4 100644
>>> --- a/tools/libxc/xc_domain_restore.c
>>> +++ b/tools/libxc/xc_domain_restore.c
>>> @@ -45,6 +45,8 @@ struct restore_ctx {
>>> =C3=82=C2  =C3=82=C2  int last_checkpoint; /* Set when we should commit=
 to the
current checkpoint when it completes. */
>>> =C3=82=C2  =C3=82=C2  int compressing; /* Set when sender signals that =
pages would
be sent compressed (for Remus) */
>>> =C3=82=C2  =C3=82=C2  struct domain_info_context dinfo;
>>> + =C3=82=C2  =C3=82=C2 uint8_t *toolstack_data;
>>> + =C3=82=C2  =C3=82=C2 uint32_t toolstack_data_len;
>>> =C3=82=C2 };
>>>
>>>
>>> This is still leaking speculative state. You have only moved the
restore code but
>>> you are still reading the (potentially discardable) state into a global
ctx structure.
>>>
>>> Take a look at the tailbuf code right below the pagebuf_get() call in
xc_domain_restore().
>>> It reads the tailbuf onto a temporary buffer and then copies it onto
the main one.
>>> This way, if an error occurs while receiving data, one can completely
discard the current
>>> checkpoint (pagebuf & tmptailbuf) and restore from the previous one
(tailbuf).
>>>
>>> You could have a similar *consistent buffer* in the xc_domain_restore
function itself, and copy the toolstack
>>> stuff into it before starting to buffer a new checkpoint. Perhaps
something like the snippet below?
>>>
>>> + toolstack_data =3D realloc(pagebuf.toolstack_data_len)
>>> + memcpy(toolstack_data, pagebuf.toolstack_data,
pagebuf.toolstack_data_len);
>>> if ( ctx->last_checkpoint )
>>>
>>> Though, this would incur two reallocs (once in pagebuf_get and once
more in the main loop).
>>>
>>> If there is a maximum size for this buffer, I would suggest mallocing
it once and for all, and just
>>> memcpy it.
>>>
>>
>> Even though the current toolstack data is tiny, I don't want to realloc
>> a potentially big buffer twice or memcpy'ing more than necessary.
>> I don't want to add a maximum size either.
>> What if I add two new arguments to pagebuf_get_one: a pointer to the
>> buffer to be malloc'ed and the length? Like it was done with the
>> callbacks argument in the previous version of this patch?
>>
>>
>>
>>>     @@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch,
struct restore_ctx *ctx,
>>>     =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  }
>>>     =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  return pagebuf_get_one(=
xch, ctx, buf, fd, dom);
>>>
>>> + =C3=82=C2  =C3=82=C2 case XC_SAVE_ID_TOOLSTACK:
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 {
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 RDEX=
ACT(fd, &ctx->toolstack_data_len,
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2
sizeof(ctx->toolstack_data_len));
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 ctx-=
>toolstack_data =3D (uint8_t*)
malloc(ctx->toolstack_data_len);
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 if (=
 ctx->toolstack_data =3D=3D NULL )
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 {
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  =C3=82=C2 PERROR("error memory
allocation");
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  =C3=82=C2 return -1;
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 }
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 RDEX=
ACT(fd, ctx->toolstack_data,
ctx->toolstack_data_len);
>>>
>>>
>>> Basically this becomes,
>>> =C3=82=C2 RDEXACT(fd, &buf->toolstack_data_len,...)
>>> buf->toolstack_data =3D (uint8_t *)realloc(buf->toolstack_data_len, 0)
>>> RDEXACT(fd, buf->toolstack_data, buf->toolstack_data_len)
>>>
>>> And please do realloc. Since the pagebuf_get_one code is called
repeatedly
>>> by the main loop, using malloc would result in loads of memory leaks.
>>>
>>
>> I presume that this buf pointer would be an argument passed to
>> pagebuf_get_one.
>> In this case, I don't suppose I need to memcpy anything anywhere, do I?
>> Later on, in finish_hvm, I'll just do:
>>
>>
>>
>> =C3=82=C2  =C3=82=C2 if ( callbacks !=3D NULL && callbacks->toolstack_re=
store !=3D NULL )
>> =C3=82=C2  =C3=82=C2 {
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 if ( callbacks->toolstack_res=
tore(dom,
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=
=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 buf->toolstack_data,
buf->toolstack_data_len,
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=
=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 callbacks->data) < 0 )
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 {
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 PERROR(=
"error calling toolstack_restore");
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 free(bu=
f->toolstack_data);
>>          buf->toolstack_data =3D NULL;
>>          buf->toolstack_data_len =3D 0;
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 goto ou=
t;
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 }
>> =C3=82=C2  =C3=82=C2 }
>> =C3=82=C2  =C3=82=C2 free(buf->toolstack_data);
>>  buf->toolstack_data =3D NULL;
>>  buf->toolstack_data_len =3D 0;
>
>
> Sorry about this, I configured my mailer not to send emails in UTF-8
> because they can be the cause of nasty python bugs with spaces and tabs.
> Let me write this code snippet again:
>
>   if ( callbacks !=3D NULL && callbacks->toolstack_restore !=3D NULL )
>   {
>       if ( callbacks->toolstack_restore(dom,
>                   buf->toolstack_data, buf->toolstack_data_len,
>                   callbacks->data) < 0 )
>       {
>           PERROR("error calling toolstack_restore");
>           free(buf->toolstack_data);
>           buf->toolstack_data =3D NULL;
>           buf->toolstack_data_len =3D 0;
>           goto out;
>       }
>   }
>   free(buf->toolstack_data);
>   buf->toolstack_data =3D NULL;
>   buf->toolstack_data_len =3D 0;

Let me rephrase the issue to make sure I am on the same page with you.
Please feel free to refute my assumptions or anything obvious that I might
have
missed.

Your code as-is (first version of the patch, where restore_toolstack is
called
in pagebuf_get_one) would work well for live migration only
i.e. num(checkpoints) =3D1
It wont work for remus (num(checkpoints) >1), since you are committing
speculative state (state from an incomplete checkpoint).

Now , I assume that the toolstack data is going to be sent in every
checkpoint,
just like the qemu device model state.

If that is not the case, the restore side of the code is fine as-is (even
with
previous version) but the save end needs to be modified, for it seems to
send the data with every checkpoint.  With that mod, things would work fine
for both live migration & Remus.


Assuming that the toolstack data is sent repeatedly with every checkpoint,
there are a few things to note:

* Do not commit state (like xenstore write) in pagebuf_get_one
because state received there (ie last half buffered checkpoint) could be
discarded.
-- this was the bug in the first version (calling toolstack_restore in
pagebuf)

* Since pagebuf_get_one gets called for each checkpoint, a malloc in
pagebuf_get_one
needs a free before the next call. Alternative: use realloc (e.g.
buf->pages)
and free in pagebuf_free().

-- this is the bug in your current version of the patch. I see a malloc in
pagebuf_get_one function, but
   no corresponding free. You are freeing in finish_hvm (after the Nth
checkpoint), but have
  created N-1 memory leaks.

* Do not touch anything from *current_version* of pagebuf after finish:,
since it has been marked incomplete.
  Moving the toolstack_data pointer from a discardable pagebuf to
restore_ctx, is not going to solve
  the issue as you are still (indirectly) accessing the data from
current_version of pagebuf.

 State received in pagebuf_get is applied in xc_domain_restore, only in the
following code
 region (simplified):

//We have a full checkpoint[i] and a corresponding tailbuf.
copypages:
  apply checkpoint[i]

if (pagebuf_get(checkpoint[i+1]) || tailbuf_get(tmptailbuf)) {
  printf("Error receiving last checkpoint");
  //So, "discard" it and resume domain, with memory checkpoint[i],
  // and also apply tailbuf
}

memcpy(tailbuf, tmptailbuf);

/* At this point, I have a full checkpoint[i+1] and a tailbuf that is
consistent with
  checkpoint i+1.
*/
goto copypages;

finish:
  if (hvm) goto finish_hvm;
  ... pv stuff
  finish_hvm:
    Apply tailbuf (that corresponds to checkpoint[i])
   ...



But if you wish to receive dynamic state (e.g. device model, toolstack,
etc) in every checkpoint
that should be applied *only once*  in the end, you could use the tailbuf
(as done by the
qemu device model currently).
Or if you have to receive them in the pagebuf, then have two pieces of the
same state,
 consistent_state, curr_state, such that you do

 pagebuf_get(curr_state)
 tailbuf_get(..)..
 if (no error so far), then
  copy curr_state to consistent_state.
  goto copypages;

finish:
 ..
  finish_hvm:
     apply consistent_state.

IMHO, it looks cleaner to push the toolstack state into buffer_tail
(send/receive in tailbuf), so
that you can continue to do malloc in buffer_tail and a corresponding free
in tailbuf_free.

cheers
shriram

--0015175d0396eaf25604b7d639cf
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2012-01-31, at 7:08 AM, Stefano Stabellini &lt;<a href=3D"mailto:stefano=
.stabellini@eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt; wrote:<=
br><br>&gt; On Tue, 31 Jan 2012, Stefano Stabellini wrote:<br>&gt;&gt; On M=
on, 30 Jan 2012, Shriram Rajagopalan wrote:<br>

&gt;&gt;&gt; On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini &lt;<a hre=
f=3D"mailto:stefano.stabellini@eu.citrix.com">stefano.stabellini@eu.citrix.=
com</a>&gt; wrote:<br>&gt;&gt;&gt; =A0 =A0 Introduce a new save_id to save/=
restore toolstack specific extra<br>

&gt;&gt;&gt; =A0 =A0 information.<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; =A0 =A0 =
Signed-off-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellini@=
eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>&gt;&gt;&gt; =A0=
 =A0 ---<br>

&gt;&gt;&gt; =C3=82=C2 tools/libxc/xc_domain_restore.c | =C3=82=C2 =A032 ++=
+++++++++++++++++++++++++++++-<br>&gt;&gt;&gt; =C3=82=C2 tools/libxc/xc_dom=
ain_save.c =C3=82=C2 =A0=C3=82=C2 | =C3=82=C2 =A017 +++++++++++++++++<br>&g=
t;&gt;&gt; =C3=82=C2 tools/libxc/xenguest.h =C3=82=C2 =A0=C3=82=C2 =A0=C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 | =C3=82=C2 =A023 ++++++++++++++++++++++-<=
br>

&gt;&gt;&gt; =C3=82=C2 tools/libxc/xg_save_restore.h =C3=82=C2 =A0| =C3=82=
=C2 =A0=C3=82=C2 1 +<br>&gt;&gt;&gt; =C3=82=C2 tools/libxl/libxl_dom.c =C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0| =C3=82=C2 =A0=C3=82=C2 2=
 +-<br>&gt;&gt;&gt; =C3=82=C2 tools/xcutils/xc_restore.c =C3=82=C2 =A0=C3=
=82=C2 =A0=C3=82=C2 | =C3=82=C2 =A0=C3=82=C2 2 +-<br>

&gt;&gt;&gt; =C3=82=C2 6 files changed, 73 insertions(+), 4 deletions(-)<br=
>&gt;&gt;&gt; <br>&gt;&gt;&gt; diff --git a/tools/libxc/xc_domain_restore.c=
 b/tools/libxc/xc_domain_restore.c<br>&gt;&gt;&gt; index 3fda6f8..ead3df4 1=
00644<br>

&gt;&gt;&gt; --- a/tools/libxc/xc_domain_restore.c<br>&gt;&gt;&gt; +++ b/to=
ols/libxc/xc_domain_restore.c<br>&gt;&gt;&gt; @@ -45,6 +45,8 @@ struct rest=
ore_ctx {<br>&gt;&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0int last_checkpoint; /*=
 Set when we should commit to the current checkpoint when it completes. */<=
br>

&gt;&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0int compressing; /* Set when sender =
signals that pages would be sent compressed (for Remus) */<br>&gt;&gt;&gt; =
=C3=82=C2 =A0=C3=82=C2 =A0struct domain_info_context dinfo;<br>&gt;&gt;&gt;=
 + =C3=82=C2 =A0=C3=82=C2 uint8_t *toolstack_data;<br>

&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 uint32_t toolstack_data_len;<br>&gt;&=
gt;&gt; =C3=82=C2 };<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; <br>&gt;&gt;&gt; This=
 is still leaking speculative state. You have only moved the restore code b=
ut<br>&gt;&gt;&gt; you are still reading the (potentially discardable) stat=
e into a global ctx structure.<br>

&gt;&gt;&gt; <br>&gt;&gt;&gt; Take a look at the tailbuf code right below t=
he pagebuf_get() call in xc_domain_restore().<br>&gt;&gt;&gt; It reads the =
tailbuf onto a temporary buffer and then copies it onto the main one.<br>

&gt;&gt;&gt; This way, if an error occurs while receiving data, one can com=
pletely discard the current<br>&gt;&gt;&gt; checkpoint (pagebuf &amp; tmpta=
ilbuf) and restore from the previous one (tailbuf).<br>&gt;&gt;&gt; <br>

&gt;&gt;&gt; You could have a similar *consistent buffer* in the xc_domain_=
restore function itself, and copy the toolstack<br>&gt;&gt;&gt; stuff into =
it before starting to buffer a new checkpoint. Perhaps something like the s=
nippet below?<br>

&gt;&gt;&gt; <br>&gt;&gt;&gt; + toolstack_data =3D realloc(pagebuf.toolstac=
k_data_len)<br>&gt;&gt;&gt; + memcpy(toolstack_data, pagebuf.toolstack_data=
, pagebuf.toolstack_data_len);<br>&gt;&gt;&gt; if ( ctx-&gt;last_checkpoint=
 )<br>

&gt;&gt;&gt; <br>&gt;&gt;&gt; Though, this would incur two reallocs (once i=
n pagebuf_get and once more in the main loop).<br>&gt;&gt;&gt; <br>&gt;&gt;=
&gt; If there is a maximum size for this buffer, I would suggest mallocing =
it once and for all, and just<br>

&gt;&gt;&gt; memcpy it.<br>&gt;&gt;&gt; <br>&gt;&gt; <br>&gt;&gt; Even thou=
gh the current toolstack data is tiny, I don&#39;t want to realloc<br>&gt;&=
gt; a potentially big buffer twice or memcpy&#39;ing more than necessary.<b=
r>

&gt;&gt; I don&#39;t want to add a maximum size either.<br>&gt;&gt; What if=
 I add two new arguments to pagebuf_get_one: a pointer to the<br>&gt;&gt; b=
uffer to be malloc&#39;ed and the length? Like it was done with the<br>

&gt;&gt; callbacks argument in the previous version of this patch?<br>&gt;&=
gt; <br>&gt;&gt; <br>&gt;&gt; <br>&gt;&gt;&gt; =A0 =A0 @@ -827,6 +829,20 @@=
 static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,<br>

&gt;&gt;&gt; =A0 =A0 =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0}<=
br>&gt;&gt;&gt; =A0 =A0 =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =
=A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>&gt;&gt;&gt; <br>&gt;=
&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 case XC_SAVE_ID_TOOLSTACK:<br>&gt;&gt;&gt=
; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 {<br>

&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 RDEXACT(fd, &amp;ctx-&gt;toolstack_data_len,<br>&gt;&gt;&g=
t; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 sizeof(ctx-&gt;t=
oolstack_data_len));<br>&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =
=A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 ctx-&gt;toolstack_data =3D (uint8_t*=
) malloc(ctx-&gt;toolstack_data_len);<br>

&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 if ( ctx-&gt;toolstack_data =3D=3D NULL )<br>&gt;&gt;&gt; =
+ =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 {<br>&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =
=A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 PERROR(&quot;error memo=
ry allocation&quot;);<br>

&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 return -1;<br>&gt;&gt;&gt; + =C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 }<b=
r>&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 RDEXACT(fd, ctx-&gt;toolstack_data, ctx-&gt;toolstack_data=
_len);<br>

&gt;&gt;&gt; <br>&gt;&gt;&gt; <br>&gt;&gt;&gt; Basically this becomes,<br>&=
gt;&gt;&gt; =C3=82=C2 RDEXACT(fd, &amp;buf-&gt;toolstack_data_len,...)<br>&=
gt;&gt;&gt; buf-&gt;toolstack_data =3D (uint8_t *)realloc(buf-&gt;toolstack=
_data_len, 0)<br>

&gt;&gt;&gt; RDEXACT(fd, buf-&gt;toolstack_data, buf-&gt;toolstack_data_len=
)<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; And please do realloc. Since the pagebuf=
_get_one code is called repeatedly<br>&gt;&gt;&gt; by the main loop, using =
malloc would result in loads of memory leaks.<br>

&gt;&gt;&gt; <br>&gt;&gt; <br>&gt;&gt; I presume that this buf pointer woul=
d be an argument passed to<br>&gt;&gt; pagebuf_get_one.<br>&gt;&gt; In this=
 case, I don&#39;t suppose I need to memcpy anything anywhere, do I?<br>

&gt;&gt; Later on, in finish_hvm, I&#39;ll just do:<br>&gt;&gt; <br>&gt;&gt=
; <br>&gt;&gt; <br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 if ( callbacks !=3D NULL=
 &amp;&amp; callbacks-&gt;toolstack_restore !=3D NULL )<br>&gt;&gt; =C3=82=
=C2 =A0=C3=82=C2 {<br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=
=82=C2 if ( callbacks-&gt;toolstack_restore(dom,<br>

&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=
=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 buf-&gt;tools=
tack_data, buf-&gt;toolstack_data_len,<br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =
=A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 =A0=C3=82=C2 callbacks-&gt;data) &lt; 0 )<br>&gt;&gt; =C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 {<br>

&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=
=C3=82=C2 PERROR(&quot;error calling toolstack_restore&quot;);<br>&gt;&gt; =
=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =
free(buf-&gt;toolstack_data);<br>&gt;&gt; =A0 =A0 =A0 =A0 =A0buf-&gt;toolst=
ack_data =3D NULL;<br>&gt;&gt; =A0 =A0 =A0 =A0 =A0buf-&gt;toolstack_data_le=
n =3D 0;<br>

&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=
=C3=82=C2 goto out;<br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=
=82=C2 }<br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 }<br>&gt;&gt; =C3=82=C2 =A0=C3=
=82=C2 free(buf-&gt;toolstack_data);<br>&gt;&gt; =A0buf-&gt;toolstack_data =
=3D NULL;<br>&gt;&gt; =A0buf-&gt;toolstack_data_len =3D 0;<br>

&gt; <br>&gt; <br>&gt; Sorry about this, I configured my mailer not to send=
 emails in UTF-8<br>&gt; because they can be the cause of nasty python bugs=
 with spaces and tabs.<br>&gt; Let me write this code snippet again:<br>

&gt; <br>&gt; =A0 if ( callbacks !=3D NULL &amp;&amp; callbacks-&gt;toolsta=
ck_restore !=3D NULL )<br>&gt; =A0 {<br>&gt; =A0 =A0 =A0 if ( callbacks-&gt=
;toolstack_restore(dom,<br>&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 buf-&gt=
;toolstack_data, buf-&gt;toolstack_data_len,<br>

&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 callbacks-&gt;data) &lt; 0 )<br>&g=
t; =A0 =A0 =A0 {<br>&gt; =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error calling too=
lstack_restore&quot;);<br>&gt; =A0 =A0 =A0 =A0 =A0 free(buf-&gt;toolstack_d=
ata);<br>&gt; =A0 =A0 =A0 =A0 =A0 buf-&gt;toolstack_data =3D NULL;<br>

&gt; =A0 =A0 =A0 =A0 =A0 buf-&gt;toolstack_data_len =3D 0;<br>&gt; =A0 =A0 =
=A0 =A0 =A0 goto out;<br>&gt; =A0 =A0 =A0 }<br>&gt; =A0 }<br>&gt; =A0 free(=
buf-&gt;toolstack_data);<br>&gt; =A0 buf-&gt;toolstack_data =3D NULL;<br>&g=
t; =A0 buf-&gt;toolstack_data_len =3D 0;<br>

<br>Let me rephrase the issue to make sure I am on the same page with you.<=
br>Please feel free to refute my assumptions or anything obvious that I mig=
ht have<br>missed.<br><br>Your code as-is (first version of the patch, wher=
e restore_toolstack is called <br>

in pagebuf_get_one) would work well for live migration only<br>i.e. num(che=
ckpoints) =3D1<br>It wont work for remus (num(checkpoints) &gt;1), since yo=
u are committing<br>speculative state (state from an incomplete checkpoint)=
.<br>

<br>Now , I assume that the toolstack data is going to be sent in every che=
ckpoint,<br>just like the qemu device model state.<br><br>If that is not th=
e case, the restore side of the code is fine as-is (even with <br>previous =
version) but the save end needs to be modified, for it seems to<br>

send the data with every checkpoint.=A0 With that mod, things would work fi=
ne<br>for both live migration &amp; Remus.<br><br><br>Assuming that the too=
lstack data is sent repeatedly with every checkpoint, <br>there are a few t=
hings to note:<br>

<br>* Do not commit state (like xenstore write) in pagebuf_get_one<br>becau=
se state received there (ie last half buffered checkpoint) could be discard=
ed.<br>-- this was the bug in the first version (calling toolstack_restore =
in pagebuf)<br>

<br>* Since pagebuf_get_one gets called for each checkpoint, a malloc in pa=
gebuf_get_one<br>
needs a free before the next call. Alternative: use realloc (e.g. buf-&gt;p=
ages)<br>
and free in pagebuf_free().<br>
<br>-- this is the bug in your current version of the patch. I see a malloc=
 in pagebuf_get_one function, but<br>
=A0=A0 no corresponding free. You are freeing in finish_hvm (after the Nth =
checkpoint), but have<br>
=A0 created N-1 memory leaks. <br><br>* Do not touch anything from *current=
_version* of pagebuf after finish:, since it has been marked incomplete.<br=
>=A0 Moving the toolstack_data pointer from a discardable pagebuf to restor=
e_ctx, is not going to solve<br>

=A0 the issue as you are still (indirectly) accessing the data from current=
_version of pagebuf.<br><br>=A0State received in pagebuf_get is applied in =
xc_domain_restore, only in the following code<br>=A0region (simplified):<br=
>
<br>
//We have a full checkpoint[i] and a corresponding tailbuf.<br>copypages:<b=
r>=A0 apply checkpoint[i]<br><br>if (pagebuf_get(checkpoint[i+1]) || tailbu=
f_get(tmptailbuf)) {<br>=A0 printf(&quot;Error receiving last checkpoint&qu=
ot;);<br>

=A0 //So, &quot;discard&quot; it and resume domain, with memory checkpoint[=
i],<br>=A0 // and also apply tailbuf<br>}<br><br>memcpy(tailbuf, tmptailbuf=
);<br><br>/* At this point, I have a full checkpoint[i+1] and a tailbuf tha=
t is consistent with<br>

=A0 checkpoint i+1.<br>*/<br>goto copypages;<br><br>finish:<br>=A0 if (hvm)=
 goto finish_hvm;<br>=A0 ... pv stuff<br>=A0 finish_hvm:<br>=A0=A0=A0 Apply=
 tailbuf (that corresponds to checkpoint[i])<br>=A0=A0 ...<br><br><br><br>B=
ut if you wish to receive dynamic state (e.g. device model, toolstack, etc)=
 in every checkpoint<br>

that should be applied *only once*=A0 in the end, you could use the tailbuf=
 (as done by the<br>qemu device model currently). <br>Or if you have to rec=
eive them in the pagebuf, then have two pieces of the same state, <br>=A0co=
nsistent_state, curr_state, such that you do<br>

<br>=A0pagebuf_get(curr_state)<br>=A0tailbuf_get(..)..<br>=A0if (no error s=
o far), then<br>=A0 copy curr_state to consistent_state.<br>=A0 goto copypa=
ges;<br><br>finish:<br>=A0..<br>=A0 finish_hvm:<br>=A0=A0=A0=A0 apply consi=
stent_state.<br><br>

IMHO, it looks cleaner to push the toolstack state into buffer_tail (send/r=
eceive in tailbuf), so<br>that you can continue to do malloc in buffer_tail=
 and a corresponding free in tailbuf_free.<br><br>cheers<br>shriram<br>


--0015175d0396eaf25604b7d639cf--


--===============3976202373544603632==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3976202373544603632==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:24:29 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17: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 1RsHR8-0002sq-6m; Tue, 31 Jan 2012 17:24:06 +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 1RsHR6-0002sU-9u
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:24:04 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-21.messagelabs.com!1328030634!10802811!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG,
	HTML_20_30,HTML_MESSAGE,RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16047 invoked from network); 31 Jan 2012 17:23:56 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-13.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:23:56 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHNpPV006609
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:23:52 -0800
Received: by bkbzv3 with SMTP id zv3so361974bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:23:49 -0800 (PST)
Received: by 10.204.154.86 with SMTP id n22mr10746607bkw.85.1328030629425;
	Tue, 31 Jan 2012 09:23:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:23:09 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:23:09 -0800
Message-ID: <CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============3976202373544603632=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============3976202373544603632==
Content-Type: multipart/alternative; boundary=0015175d0396eaf25604b7d639cf

--0015175d0396eaf25604b7d639cf
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2012-01-31, at 7:08 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> On Tue, 31 Jan 2012, Stefano Stabellini wrote:
>> On Mon, 30 Jan 2012, Shriram Rajagopalan wrote:
>>> On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:
>>>     Introduce a new save_id to save/restore toolstack specific extra
>>>     information.
>>>
>>>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com=
>
>>>     ---
>>> =C3=82=C2 tools/libxc/xc_domain_restore.c | =C3=82=C2  32
+++++++++++++++++++++++++++++++-
>>> =C3=82=C2 tools/libxc/xc_domain_save.c =C3=82=C2  =C3=82=C2 | =C3=82=C2=
  17 +++++++++++++++++
>>> =C3=82=C2 tools/libxc/xenguest.h =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  =C3=82=C2 | =C3=82=C2  23
++++++++++++++++++++++-
>>> =C3=82=C2 tools/libxc/xg_save_restore.h =C3=82=C2  | =C3=82=C2  =C3=82=
=C2 1 +
>>> =C3=82=C2 tools/libxl/libxl_dom.c =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  | =C3=82=C2  =C3=82=C2 2 +-
>>> =C3=82=C2 tools/xcutils/xc_restore.c =C3=82=C2  =C3=82=C2  =C3=82=C2 | =
=C3=82=C2  =C3=82=C2 2 +-
>>> =C3=82=C2 6 files changed, 73 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tools/libxc/xc_domain_restore.c
b/tools/libxc/xc_domain_restore.c
>>> index 3fda6f8..ead3df4 100644
>>> --- a/tools/libxc/xc_domain_restore.c
>>> +++ b/tools/libxc/xc_domain_restore.c
>>> @@ -45,6 +45,8 @@ struct restore_ctx {
>>> =C3=82=C2  =C3=82=C2  int last_checkpoint; /* Set when we should commit=
 to the
current checkpoint when it completes. */
>>> =C3=82=C2  =C3=82=C2  int compressing; /* Set when sender signals that =
pages would
be sent compressed (for Remus) */
>>> =C3=82=C2  =C3=82=C2  struct domain_info_context dinfo;
>>> + =C3=82=C2  =C3=82=C2 uint8_t *toolstack_data;
>>> + =C3=82=C2  =C3=82=C2 uint32_t toolstack_data_len;
>>> =C3=82=C2 };
>>>
>>>
>>> This is still leaking speculative state. You have only moved the
restore code but
>>> you are still reading the (potentially discardable) state into a global
ctx structure.
>>>
>>> Take a look at the tailbuf code right below the pagebuf_get() call in
xc_domain_restore().
>>> It reads the tailbuf onto a temporary buffer and then copies it onto
the main one.
>>> This way, if an error occurs while receiving data, one can completely
discard the current
>>> checkpoint (pagebuf & tmptailbuf) and restore from the previous one
(tailbuf).
>>>
>>> You could have a similar *consistent buffer* in the xc_domain_restore
function itself, and copy the toolstack
>>> stuff into it before starting to buffer a new checkpoint. Perhaps
something like the snippet below?
>>>
>>> + toolstack_data =3D realloc(pagebuf.toolstack_data_len)
>>> + memcpy(toolstack_data, pagebuf.toolstack_data,
pagebuf.toolstack_data_len);
>>> if ( ctx->last_checkpoint )
>>>
>>> Though, this would incur two reallocs (once in pagebuf_get and once
more in the main loop).
>>>
>>> If there is a maximum size for this buffer, I would suggest mallocing
it once and for all, and just
>>> memcpy it.
>>>
>>
>> Even though the current toolstack data is tiny, I don't want to realloc
>> a potentially big buffer twice or memcpy'ing more than necessary.
>> I don't want to add a maximum size either.
>> What if I add two new arguments to pagebuf_get_one: a pointer to the
>> buffer to be malloc'ed and the length? Like it was done with the
>> callbacks argument in the previous version of this patch?
>>
>>
>>
>>>     @@ -827,6 +829,20 @@ static int pagebuf_get_one(xc_interface *xch,
struct restore_ctx *ctx,
>>>     =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  }
>>>     =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  return pagebuf_get_one(=
xch, ctx, buf, fd, dom);
>>>
>>> + =C3=82=C2  =C3=82=C2 case XC_SAVE_ID_TOOLSTACK:
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 {
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 RDEX=
ACT(fd, &ctx->toolstack_data_len,
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2
sizeof(ctx->toolstack_data_len));
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 ctx-=
>toolstack_data =3D (uint8_t*)
malloc(ctx->toolstack_data_len);
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 if (=
 ctx->toolstack_data =3D=3D NULL )
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 {
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  =C3=82=C2 PERROR("error memory
allocation");
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=
=82=C2  =C3=82=C2 return -1;
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 }
>>> + =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 RDEX=
ACT(fd, ctx->toolstack_data,
ctx->toolstack_data_len);
>>>
>>>
>>> Basically this becomes,
>>> =C3=82=C2 RDEXACT(fd, &buf->toolstack_data_len,...)
>>> buf->toolstack_data =3D (uint8_t *)realloc(buf->toolstack_data_len, 0)
>>> RDEXACT(fd, buf->toolstack_data, buf->toolstack_data_len)
>>>
>>> And please do realloc. Since the pagebuf_get_one code is called
repeatedly
>>> by the main loop, using malloc would result in loads of memory leaks.
>>>
>>
>> I presume that this buf pointer would be an argument passed to
>> pagebuf_get_one.
>> In this case, I don't suppose I need to memcpy anything anywhere, do I?
>> Later on, in finish_hvm, I'll just do:
>>
>>
>>
>> =C3=82=C2  =C3=82=C2 if ( callbacks !=3D NULL && callbacks->toolstack_re=
store !=3D NULL )
>> =C3=82=C2  =C3=82=C2 {
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 if ( callbacks->toolstack_res=
tore(dom,
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=
=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 buf->toolstack_data,
buf->toolstack_data_len,
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=
=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 callbacks->data) < 0 )
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 {
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 PERROR(=
"error calling toolstack_restore");
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 free(bu=
f->toolstack_data);
>>          buf->toolstack_data =3D NULL;
>>          buf->toolstack_data_len =3D 0;
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 goto ou=
t;
>> =C3=82=C2  =C3=82=C2  =C3=82=C2  =C3=82=C2 }
>> =C3=82=C2  =C3=82=C2 }
>> =C3=82=C2  =C3=82=C2 free(buf->toolstack_data);
>>  buf->toolstack_data =3D NULL;
>>  buf->toolstack_data_len =3D 0;
>
>
> Sorry about this, I configured my mailer not to send emails in UTF-8
> because they can be the cause of nasty python bugs with spaces and tabs.
> Let me write this code snippet again:
>
>   if ( callbacks !=3D NULL && callbacks->toolstack_restore !=3D NULL )
>   {
>       if ( callbacks->toolstack_restore(dom,
>                   buf->toolstack_data, buf->toolstack_data_len,
>                   callbacks->data) < 0 )
>       {
>           PERROR("error calling toolstack_restore");
>           free(buf->toolstack_data);
>           buf->toolstack_data =3D NULL;
>           buf->toolstack_data_len =3D 0;
>           goto out;
>       }
>   }
>   free(buf->toolstack_data);
>   buf->toolstack_data =3D NULL;
>   buf->toolstack_data_len =3D 0;

Let me rephrase the issue to make sure I am on the same page with you.
Please feel free to refute my assumptions or anything obvious that I might
have
missed.

Your code as-is (first version of the patch, where restore_toolstack is
called
in pagebuf_get_one) would work well for live migration only
i.e. num(checkpoints) =3D1
It wont work for remus (num(checkpoints) >1), since you are committing
speculative state (state from an incomplete checkpoint).

Now , I assume that the toolstack data is going to be sent in every
checkpoint,
just like the qemu device model state.

If that is not the case, the restore side of the code is fine as-is (even
with
previous version) but the save end needs to be modified, for it seems to
send the data with every checkpoint.  With that mod, things would work fine
for both live migration & Remus.


Assuming that the toolstack data is sent repeatedly with every checkpoint,
there are a few things to note:

* Do not commit state (like xenstore write) in pagebuf_get_one
because state received there (ie last half buffered checkpoint) could be
discarded.
-- this was the bug in the first version (calling toolstack_restore in
pagebuf)

* Since pagebuf_get_one gets called for each checkpoint, a malloc in
pagebuf_get_one
needs a free before the next call. Alternative: use realloc (e.g.
buf->pages)
and free in pagebuf_free().

-- this is the bug in your current version of the patch. I see a malloc in
pagebuf_get_one function, but
   no corresponding free. You are freeing in finish_hvm (after the Nth
checkpoint), but have
  created N-1 memory leaks.

* Do not touch anything from *current_version* of pagebuf after finish:,
since it has been marked incomplete.
  Moving the toolstack_data pointer from a discardable pagebuf to
restore_ctx, is not going to solve
  the issue as you are still (indirectly) accessing the data from
current_version of pagebuf.

 State received in pagebuf_get is applied in xc_domain_restore, only in the
following code
 region (simplified):

//We have a full checkpoint[i] and a corresponding tailbuf.
copypages:
  apply checkpoint[i]

if (pagebuf_get(checkpoint[i+1]) || tailbuf_get(tmptailbuf)) {
  printf("Error receiving last checkpoint");
  //So, "discard" it and resume domain, with memory checkpoint[i],
  // and also apply tailbuf
}

memcpy(tailbuf, tmptailbuf);

/* At this point, I have a full checkpoint[i+1] and a tailbuf that is
consistent with
  checkpoint i+1.
*/
goto copypages;

finish:
  if (hvm) goto finish_hvm;
  ... pv stuff
  finish_hvm:
    Apply tailbuf (that corresponds to checkpoint[i])
   ...



But if you wish to receive dynamic state (e.g. device model, toolstack,
etc) in every checkpoint
that should be applied *only once*  in the end, you could use the tailbuf
(as done by the
qemu device model currently).
Or if you have to receive them in the pagebuf, then have two pieces of the
same state,
 consistent_state, curr_state, such that you do

 pagebuf_get(curr_state)
 tailbuf_get(..)..
 if (no error so far), then
  copy curr_state to consistent_state.
  goto copypages;

finish:
 ..
  finish_hvm:
     apply consistent_state.

IMHO, it looks cleaner to push the toolstack state into buffer_tail
(send/receive in tailbuf), so
that you can continue to do malloc in buffer_tail and a corresponding free
in tailbuf_free.

cheers
shriram

--0015175d0396eaf25604b7d639cf
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 2012-01-31, at 7:08 AM, Stefano Stabellini &lt;<a href=3D"mailto:stefano=
.stabellini@eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt; wrote:<=
br><br>&gt; On Tue, 31 Jan 2012, Stefano Stabellini wrote:<br>&gt;&gt; On M=
on, 30 Jan 2012, Shriram Rajagopalan wrote:<br>

&gt;&gt;&gt; On Mon, Jan 30, 2012 at 8:54 AM, Stefano Stabellini &lt;<a hre=
f=3D"mailto:stefano.stabellini@eu.citrix.com">stefano.stabellini@eu.citrix.=
com</a>&gt; wrote:<br>&gt;&gt;&gt; =A0 =A0 Introduce a new save_id to save/=
restore toolstack specific extra<br>

&gt;&gt;&gt; =A0 =A0 information.<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; =A0 =A0 =
Signed-off-by: Stefano Stabellini &lt;<a href=3D"mailto:stefano.stabellini@=
eu.citrix.com">stefano.stabellini@eu.citrix.com</a>&gt;<br>&gt;&gt;&gt; =A0=
 =A0 ---<br>

&gt;&gt;&gt; =C3=82=C2 tools/libxc/xc_domain_restore.c | =C3=82=C2 =A032 ++=
+++++++++++++++++++++++++++++-<br>&gt;&gt;&gt; =C3=82=C2 tools/libxc/xc_dom=
ain_save.c =C3=82=C2 =A0=C3=82=C2 | =C3=82=C2 =A017 +++++++++++++++++<br>&g=
t;&gt;&gt; =C3=82=C2 tools/libxc/xenguest.h =C3=82=C2 =A0=C3=82=C2 =A0=C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 | =C3=82=C2 =A023 ++++++++++++++++++++++-<=
br>

&gt;&gt;&gt; =C3=82=C2 tools/libxc/xg_save_restore.h =C3=82=C2 =A0| =C3=82=
=C2 =A0=C3=82=C2 1 +<br>&gt;&gt;&gt; =C3=82=C2 tools/libxl/libxl_dom.c =C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0| =C3=82=C2 =A0=C3=82=C2 2=
 +-<br>&gt;&gt;&gt; =C3=82=C2 tools/xcutils/xc_restore.c =C3=82=C2 =A0=C3=
=82=C2 =A0=C3=82=C2 | =C3=82=C2 =A0=C3=82=C2 2 +-<br>

&gt;&gt;&gt; =C3=82=C2 6 files changed, 73 insertions(+), 4 deletions(-)<br=
>&gt;&gt;&gt; <br>&gt;&gt;&gt; diff --git a/tools/libxc/xc_domain_restore.c=
 b/tools/libxc/xc_domain_restore.c<br>&gt;&gt;&gt; index 3fda6f8..ead3df4 1=
00644<br>

&gt;&gt;&gt; --- a/tools/libxc/xc_domain_restore.c<br>&gt;&gt;&gt; +++ b/to=
ols/libxc/xc_domain_restore.c<br>&gt;&gt;&gt; @@ -45,6 +45,8 @@ struct rest=
ore_ctx {<br>&gt;&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0int last_checkpoint; /*=
 Set when we should commit to the current checkpoint when it completes. */<=
br>

&gt;&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0int compressing; /* Set when sender =
signals that pages would be sent compressed (for Remus) */<br>&gt;&gt;&gt; =
=C3=82=C2 =A0=C3=82=C2 =A0struct domain_info_context dinfo;<br>&gt;&gt;&gt;=
 + =C3=82=C2 =A0=C3=82=C2 uint8_t *toolstack_data;<br>

&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 uint32_t toolstack_data_len;<br>&gt;&=
gt;&gt; =C3=82=C2 };<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; <br>&gt;&gt;&gt; This=
 is still leaking speculative state. You have only moved the restore code b=
ut<br>&gt;&gt;&gt; you are still reading the (potentially discardable) stat=
e into a global ctx structure.<br>

&gt;&gt;&gt; <br>&gt;&gt;&gt; Take a look at the tailbuf code right below t=
he pagebuf_get() call in xc_domain_restore().<br>&gt;&gt;&gt; It reads the =
tailbuf onto a temporary buffer and then copies it onto the main one.<br>

&gt;&gt;&gt; This way, if an error occurs while receiving data, one can com=
pletely discard the current<br>&gt;&gt;&gt; checkpoint (pagebuf &amp; tmpta=
ilbuf) and restore from the previous one (tailbuf).<br>&gt;&gt;&gt; <br>

&gt;&gt;&gt; You could have a similar *consistent buffer* in the xc_domain_=
restore function itself, and copy the toolstack<br>&gt;&gt;&gt; stuff into =
it before starting to buffer a new checkpoint. Perhaps something like the s=
nippet below?<br>

&gt;&gt;&gt; <br>&gt;&gt;&gt; + toolstack_data =3D realloc(pagebuf.toolstac=
k_data_len)<br>&gt;&gt;&gt; + memcpy(toolstack_data, pagebuf.toolstack_data=
, pagebuf.toolstack_data_len);<br>&gt;&gt;&gt; if ( ctx-&gt;last_checkpoint=
 )<br>

&gt;&gt;&gt; <br>&gt;&gt;&gt; Though, this would incur two reallocs (once i=
n pagebuf_get and once more in the main loop).<br>&gt;&gt;&gt; <br>&gt;&gt;=
&gt; If there is a maximum size for this buffer, I would suggest mallocing =
it once and for all, and just<br>

&gt;&gt;&gt; memcpy it.<br>&gt;&gt;&gt; <br>&gt;&gt; <br>&gt;&gt; Even thou=
gh the current toolstack data is tiny, I don&#39;t want to realloc<br>&gt;&=
gt; a potentially big buffer twice or memcpy&#39;ing more than necessary.<b=
r>

&gt;&gt; I don&#39;t want to add a maximum size either.<br>&gt;&gt; What if=
 I add two new arguments to pagebuf_get_one: a pointer to the<br>&gt;&gt; b=
uffer to be malloc&#39;ed and the length? Like it was done with the<br>

&gt;&gt; callbacks argument in the previous version of this patch?<br>&gt;&=
gt; <br>&gt;&gt; <br>&gt;&gt; <br>&gt;&gt;&gt; =A0 =A0 @@ -827,6 +829,20 @@=
 static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,<br>

&gt;&gt;&gt; =A0 =A0 =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0}<=
br>&gt;&gt;&gt; =A0 =A0 =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =
=A0return pagebuf_get_one(xch, ctx, buf, fd, dom);<br>&gt;&gt;&gt; <br>&gt;=
&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 case XC_SAVE_ID_TOOLSTACK:<br>&gt;&gt;&gt=
; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 {<br>

&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 RDEXACT(fd, &amp;ctx-&gt;toolstack_data_len,<br>&gt;&gt;&g=
t; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 sizeof(ctx-&gt;t=
oolstack_data_len));<br>&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =
=A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 ctx-&gt;toolstack_data =3D (uint8_t*=
) malloc(ctx-&gt;toolstack_data_len);<br>

&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 if ( ctx-&gt;toolstack_data =3D=3D NULL )<br>&gt;&gt;&gt; =
+ =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 {<br>&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =
=A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 PERROR(&quot;error memo=
ry allocation&quot;);<br>

&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 return -1;<br>&gt;&gt;&gt; + =C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 }<b=
r>&gt;&gt;&gt; + =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 RDEXACT(fd, ctx-&gt;toolstack_data, ctx-&gt;toolstack_data=
_len);<br>

&gt;&gt;&gt; <br>&gt;&gt;&gt; <br>&gt;&gt;&gt; Basically this becomes,<br>&=
gt;&gt;&gt; =C3=82=C2 RDEXACT(fd, &amp;buf-&gt;toolstack_data_len,...)<br>&=
gt;&gt;&gt; buf-&gt;toolstack_data =3D (uint8_t *)realloc(buf-&gt;toolstack=
_data_len, 0)<br>

&gt;&gt;&gt; RDEXACT(fd, buf-&gt;toolstack_data, buf-&gt;toolstack_data_len=
)<br>&gt;&gt;&gt; <br>&gt;&gt;&gt; And please do realloc. Since the pagebuf=
_get_one code is called repeatedly<br>&gt;&gt;&gt; by the main loop, using =
malloc would result in loads of memory leaks.<br>

&gt;&gt;&gt; <br>&gt;&gt; <br>&gt;&gt; I presume that this buf pointer woul=
d be an argument passed to<br>&gt;&gt; pagebuf_get_one.<br>&gt;&gt; In this=
 case, I don&#39;t suppose I need to memcpy anything anywhere, do I?<br>

&gt;&gt; Later on, in finish_hvm, I&#39;ll just do:<br>&gt;&gt; <br>&gt;&gt=
; <br>&gt;&gt; <br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 if ( callbacks !=3D NULL=
 &amp;&amp; callbacks-&gt;toolstack_restore !=3D NULL )<br>&gt;&gt; =C3=82=
=C2 =A0=C3=82=C2 {<br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=
=82=C2 if ( callbacks-&gt;toolstack_restore(dom,<br>

&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=
=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 buf-&gt;tools=
tack_data, buf-&gt;toolstack_data_len,<br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =
=A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=
=C2 =A0=C3=82=C2 =A0=C3=82=C2 callbacks-&gt;data) &lt; 0 )<br>&gt;&gt; =C3=
=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 {<br>

&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=
=C3=82=C2 PERROR(&quot;error calling toolstack_restore&quot;);<br>&gt;&gt; =
=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =
free(buf-&gt;toolstack_data);<br>&gt;&gt; =A0 =A0 =A0 =A0 =A0buf-&gt;toolst=
ack_data =3D NULL;<br>&gt;&gt; =A0 =A0 =A0 =A0 =A0buf-&gt;toolstack_data_le=
n =3D 0;<br>

&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=
=C3=82=C2 goto out;<br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 =A0=C3=82=C2 =A0=C3=
=82=C2 }<br>&gt;&gt; =C3=82=C2 =A0=C3=82=C2 }<br>&gt;&gt; =C3=82=C2 =A0=C3=
=82=C2 free(buf-&gt;toolstack_data);<br>&gt;&gt; =A0buf-&gt;toolstack_data =
=3D NULL;<br>&gt;&gt; =A0buf-&gt;toolstack_data_len =3D 0;<br>

&gt; <br>&gt; <br>&gt; Sorry about this, I configured my mailer not to send=
 emails in UTF-8<br>&gt; because they can be the cause of nasty python bugs=
 with spaces and tabs.<br>&gt; Let me write this code snippet again:<br>

&gt; <br>&gt; =A0 if ( callbacks !=3D NULL &amp;&amp; callbacks-&gt;toolsta=
ck_restore !=3D NULL )<br>&gt; =A0 {<br>&gt; =A0 =A0 =A0 if ( callbacks-&gt=
;toolstack_restore(dom,<br>&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 buf-&gt=
;toolstack_data, buf-&gt;toolstack_data_len,<br>

&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 callbacks-&gt;data) &lt; 0 )<br>&g=
t; =A0 =A0 =A0 {<br>&gt; =A0 =A0 =A0 =A0 =A0 PERROR(&quot;error calling too=
lstack_restore&quot;);<br>&gt; =A0 =A0 =A0 =A0 =A0 free(buf-&gt;toolstack_d=
ata);<br>&gt; =A0 =A0 =A0 =A0 =A0 buf-&gt;toolstack_data =3D NULL;<br>

&gt; =A0 =A0 =A0 =A0 =A0 buf-&gt;toolstack_data_len =3D 0;<br>&gt; =A0 =A0 =
=A0 =A0 =A0 goto out;<br>&gt; =A0 =A0 =A0 }<br>&gt; =A0 }<br>&gt; =A0 free(=
buf-&gt;toolstack_data);<br>&gt; =A0 buf-&gt;toolstack_data =3D NULL;<br>&g=
t; =A0 buf-&gt;toolstack_data_len =3D 0;<br>

<br>Let me rephrase the issue to make sure I am on the same page with you.<=
br>Please feel free to refute my assumptions or anything obvious that I mig=
ht have<br>missed.<br><br>Your code as-is (first version of the patch, wher=
e restore_toolstack is called <br>

in pagebuf_get_one) would work well for live migration only<br>i.e. num(che=
ckpoints) =3D1<br>It wont work for remus (num(checkpoints) &gt;1), since yo=
u are committing<br>speculative state (state from an incomplete checkpoint)=
.<br>

<br>Now , I assume that the toolstack data is going to be sent in every che=
ckpoint,<br>just like the qemu device model state.<br><br>If that is not th=
e case, the restore side of the code is fine as-is (even with <br>previous =
version) but the save end needs to be modified, for it seems to<br>

send the data with every checkpoint.=A0 With that mod, things would work fi=
ne<br>for both live migration &amp; Remus.<br><br><br>Assuming that the too=
lstack data is sent repeatedly with every checkpoint, <br>there are a few t=
hings to note:<br>

<br>* Do not commit state (like xenstore write) in pagebuf_get_one<br>becau=
se state received there (ie last half buffered checkpoint) could be discard=
ed.<br>-- this was the bug in the first version (calling toolstack_restore =
in pagebuf)<br>

<br>* Since pagebuf_get_one gets called for each checkpoint, a malloc in pa=
gebuf_get_one<br>
needs a free before the next call. Alternative: use realloc (e.g. buf-&gt;p=
ages)<br>
and free in pagebuf_free().<br>
<br>-- this is the bug in your current version of the patch. I see a malloc=
 in pagebuf_get_one function, but<br>
=A0=A0 no corresponding free. You are freeing in finish_hvm (after the Nth =
checkpoint), but have<br>
=A0 created N-1 memory leaks. <br><br>* Do not touch anything from *current=
_version* of pagebuf after finish:, since it has been marked incomplete.<br=
>=A0 Moving the toolstack_data pointer from a discardable pagebuf to restor=
e_ctx, is not going to solve<br>

=A0 the issue as you are still (indirectly) accessing the data from current=
_version of pagebuf.<br><br>=A0State received in pagebuf_get is applied in =
xc_domain_restore, only in the following code<br>=A0region (simplified):<br=
>
<br>
//We have a full checkpoint[i] and a corresponding tailbuf.<br>copypages:<b=
r>=A0 apply checkpoint[i]<br><br>if (pagebuf_get(checkpoint[i+1]) || tailbu=
f_get(tmptailbuf)) {<br>=A0 printf(&quot;Error receiving last checkpoint&qu=
ot;);<br>

=A0 //So, &quot;discard&quot; it and resume domain, with memory checkpoint[=
i],<br>=A0 // and also apply tailbuf<br>}<br><br>memcpy(tailbuf, tmptailbuf=
);<br><br>/* At this point, I have a full checkpoint[i+1] and a tailbuf tha=
t is consistent with<br>

=A0 checkpoint i+1.<br>*/<br>goto copypages;<br><br>finish:<br>=A0 if (hvm)=
 goto finish_hvm;<br>=A0 ... pv stuff<br>=A0 finish_hvm:<br>=A0=A0=A0 Apply=
 tailbuf (that corresponds to checkpoint[i])<br>=A0=A0 ...<br><br><br><br>B=
ut if you wish to receive dynamic state (e.g. device model, toolstack, etc)=
 in every checkpoint<br>

that should be applied *only once*=A0 in the end, you could use the tailbuf=
 (as done by the<br>qemu device model currently). <br>Or if you have to rec=
eive them in the pagebuf, then have two pieces of the same state, <br>=A0co=
nsistent_state, curr_state, such that you do<br>

<br>=A0pagebuf_get(curr_state)<br>=A0tailbuf_get(..)..<br>=A0if (no error s=
o far), then<br>=A0 copy curr_state to consistent_state.<br>=A0 goto copypa=
ges;<br><br>finish:<br>=A0..<br>=A0 finish_hvm:<br>=A0=A0=A0=A0 apply consi=
stent_state.<br><br>

IMHO, it looks cleaner to push the toolstack state into buffer_tail (send/r=
eceive in tailbuf), so<br>that you can continue to do malloc in buffer_tail=
 and a corresponding free in tailbuf_free.<br><br>cheers<br>shriram<br>


--0015175d0396eaf25604b7d639cf--


--===============3976202373544603632==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============3976202373544603632==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:32:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHYF-0003BT-A5; Tue, 31 Jan 2012 17:31:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsHYE-0003BO-P0
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:31:26 +0000
Received: from [85.158.138.51:8496] by server-11.bemta-3.messagelabs.com id
	E3/87-26051-D65282F4; Tue, 31 Jan 2012 17:31:25 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328031083!11387570!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30290 invoked from network); 31 Jan 2012 17:31:24 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:31:24 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHVKBT007811
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:31:21 -0800
Received: by bkbzv3 with SMTP id zv3so376486bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:31:19 -0800 (PST)
Received: by 10.204.154.86 with SMTP id n22mr10758458bkw.85.1328031079380;
	Tue, 31 Jan 2012 09:31:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:30:39 -0800 (PST)
In-Reply-To: <1328003207.26983.311.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
	<1328003207.26983.311.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:30:39 -0800
Message-ID: <CAP8mzPOo+muJTB8FLYOetsNm_6EfYia3gnNKFQ-pO0YCcQfqYg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send
 commands to traditional qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============7233116686518015766=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7233116686518015766==
Content-Type: multipart/alternative; boundary=0015175d0396bcb61c04b7d65480

--0015175d0396bcb61c04b7d65480
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 1:46 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1327971493 28800
> > # Node ID 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
> > # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> > libxl: helper function to send commands to traditional qemu
> >
> > Introduce a helper function to send commands to traditional
> > qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
> > libxl__domain_save_device_model and libxl_domain_unpause have
> > been refactored to use this function.
> >
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Every caller to libxl__qemu_traditional_cmd seems to be followed with a
> call to libxl__wait_for_device_model -- might be worth pushing that down
> into the function?
>
>
Yes I noticed that. Though some seem to be using the callback while others
dont.
This would necessitate another helper function, like
libxl_qemu_traditional_change_state
that does both the command and the state check (if callback supplied). This
way people could still use the libxl_qemu_traditional_cmd for use-cases
that dont
require a special state check. But all this is for another , later patch
:P. At the moment,
I just want to get the remus framework in :D.

thanks for the ack.

--0015175d0396bcb61c04b7d65480
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 1:46 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Tue, 2012-01-31 at 01:05 +0000, <a href=3D"mailto:rshr=
iram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; # HG changeset patch<br>
&gt; # User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">r=
shriram@cs.ubc.ca</a>&gt;<br>
&gt; # Date 1327971493 28800<br>
&gt; # Node ID 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a<br>
&gt; # Parent =A0e2722b24dc0962de37215320b05d1bb7c4c42864<br>
&gt; libxl: helper function to send commands to traditional qemu<br>
&gt;<br>
&gt; Introduce a helper function to send commands to traditional<br>
&gt; qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,<br>
&gt; libxl__domain_save_device_model and libxl_domain_unpause have<br>
&gt; been refactored to use this function.<br>
&gt;<br>
&gt; Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.u=
bc.ca">rshriram@cs.ubc.ca</a>&gt;<br>
<br>
</div>Acked-by: Ian Campbell &lt;<a href=3D"mailto:ian.campbell@citrix.com"=
>ian.campbell@citrix.com</a>&gt;<br>
<br>
Every caller to libxl__qemu_traditional_cmd seems to be followed with a<br>
call to libxl__wait_for_device_model -- might be worth pushing that down<br=
>
into the function?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote></div>=
<br>Yes I noticed that. Though some seem to be using the callback while oth=
ers dont.<br>This would necessitate another helper function, like libxl_qem=
u_traditional_change_state<br>

that does both the command and the state check (if callback supplied). This=
<br>way people could still use the libxl_qemu_traditional_cmd for use-cases=
 that dont<br>require a special state check. But all this is for another , =
later patch :P. At the moment,<br>

I just want to get the remus framework in :D.<br><br>thanks for the ack.<br=
>

--0015175d0396bcb61c04b7d65480--


--===============7233116686518015766==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7233116686518015766==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:32:01 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:32:01 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHYF-0003BT-A5; Tue, 31 Jan 2012 17:31:27 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsHYE-0003BO-P0
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:31:26 +0000
Received: from [85.158.138.51:8496] by server-11.bemta-3.messagelabs.com id
	E3/87-26051-D65282F4; Tue, 31 Jan 2012 17:31:25 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-3.tower-174.messagelabs.com!1328031083!11387570!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30290 invoked from network); 31 Jan 2012 17:31:24 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-3.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:31:24 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHVKBT007811
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:31:21 -0800
Received: by bkbzv3 with SMTP id zv3so376486bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:31:19 -0800 (PST)
Received: by 10.204.154.86 with SMTP id n22mr10758458bkw.85.1328031079380;
	Tue, 31 Jan 2012 09:31:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:30:39 -0800 (PST)
In-Reply-To: <1328003207.26983.311.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<20bbc4a754a701ef14c9.1327971906@athos.nss.cs.ubc.ca>
	<1328003207.26983.311.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:30:39 -0800
Message-ID: <CAP8mzPOo+muJTB8FLYOetsNm_6EfYia3gnNKFQ-pO0YCcQfqYg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 6] libxl: helper function to send
 commands to traditional qemu
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============7233116686518015766=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============7233116686518015766==
Content-Type: multipart/alternative; boundary=0015175d0396bcb61c04b7d65480

--0015175d0396bcb61c04b7d65480
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 1:46 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1327971493 28800
> > # Node ID 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a
> > # Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
> > libxl: helper function to send commands to traditional qemu
> >
> > Introduce a helper function to send commands to traditional
> > qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,
> > libxl__domain_save_device_model and libxl_domain_unpause have
> > been refactored to use this function.
> >
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>
> Every caller to libxl__qemu_traditional_cmd seems to be followed with a
> call to libxl__wait_for_device_model -- might be worth pushing that down
> into the function?
>
>
Yes I noticed that. Though some seem to be using the callback while others
dont.
This would necessitate another helper function, like
libxl_qemu_traditional_change_state
that does both the command and the state check (if callback supplied). This
way people could still use the libxl_qemu_traditional_cmd for use-cases
that dont
require a special state check. But all this is for another , later patch
:P. At the moment,
I just want to get the remus framework in :D.

thanks for the ack.

--0015175d0396bcb61c04b7d65480
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 1:46 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Tue, 2012-01-31 at 01:05 +0000, <a href=3D"mailto:rshr=
iram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; # HG changeset patch<br>
&gt; # User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">r=
shriram@cs.ubc.ca</a>&gt;<br>
&gt; # Date 1327971493 28800<br>
&gt; # Node ID 20bbc4a754a701ef14c9136a1adffc1c90bc1f4a<br>
&gt; # Parent =A0e2722b24dc0962de37215320b05d1bb7c4c42864<br>
&gt; libxl: helper function to send commands to traditional qemu<br>
&gt;<br>
&gt; Introduce a helper function to send commands to traditional<br>
&gt; qemu. qemu_pci_add_xenstore, qemu_pci_remove_xenstore,<br>
&gt; libxl__domain_save_device_model and libxl_domain_unpause have<br>
&gt; been refactored to use this function.<br>
&gt;<br>
&gt; Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.u=
bc.ca">rshriram@cs.ubc.ca</a>&gt;<br>
<br>
</div>Acked-by: Ian Campbell &lt;<a href=3D"mailto:ian.campbell@citrix.com"=
>ian.campbell@citrix.com</a>&gt;<br>
<br>
Every caller to libxl__qemu_traditional_cmd seems to be followed with a<br>
call to libxl__wait_for_device_model -- might be worth pushing that down<br=
>
into the function?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote></div>=
<br>Yes I noticed that. Though some seem to be using the callback while oth=
ers dont.<br>This would necessitate another helper function, like libxl_qem=
u_traditional_change_state<br>

that does both the command and the state check (if callback supplied). This=
<br>way people could still use the libxl_qemu_traditional_cmd for use-cases=
 that dont<br>require a special state check. But all this is for another , =
later patch :P. At the moment,<br>

I just want to get the remus framework in :D.<br><br>thanks for the ack.<br=
>

--0015175d0396bcb61c04b7d65480--


--===============7233116686518015766==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============7233116686518015766==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:34:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:34:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHac-0003Gn-Sg; Tue, 31 Jan 2012 17:33:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsHab-0003Gb-DV
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:33:53 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328031224!11975407!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20481 invoked from network); 31 Jan 2012 17:33:46 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 17:33:46 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHXgpO008237
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:33:43 -0800
Received: by bkbzv3 with SMTP id zv3so381835bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:33:41 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr10805779bkc.13.1328031221153; Tue,
	31 Jan 2012 09:33:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:32:59 -0800 (PST)
In-Reply-To: <1328003681.26983.318.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
	<1328003681.26983.318.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:32:59 -0800
Message-ID: <CAP8mzPMer3bnxqBRCJYCYqi5nR9DcjQzmRbebNDKD39bm=v+pg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
	QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============8608592479568863293=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8608592479568863293==
Content-Type: multipart/alternative; boundary=000e0ce040442fffd004b7d65dcd

--000e0ce040442fffd004b7d65dcd
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 1:54 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
> > +{
> > +
> > +    switch (libxl__device_model_version_running(gc, domid)) {
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> > +        libxl__qemu_traditional_cmd(gc, domid, "continue");
>
> No libxl__wait_for_device_model -> "running"?
>
>
Nope. Thats how xend/remus also does it. There seems to be no reference to
such
a state anywhere.


>  > +        break;
> > +    }
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > +        if (libxl__qmp_resume(gc, domid))
> > +            return ERROR_FAIL;
> > +    default:
> > +        return ERROR_INVAL;
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> >  static int libxl__domain_suspend_common_callback(void *data)
> >  {
> >      struct suspendinfo *si = data;
> > @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
> >              return 0;
> >          }
> >          si->guest_responded = 1;
> > -        return 1;
> > +        goto suspend_dm;
> >      }
> >
> >      if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
> > @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
> >              shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
> & XEN_DOMINF_shutdownmask;
> >              if (shutdown_reason == SHUTDOWN_suspend) {
> >                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has
> suspended");
> > -                return 1;
> > +                goto suspend_dm;
> >              }
> >          }
> >
> > @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
> >
> >      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
> >      return 0;
> > +
> > + suspend_dm:
>
> The goto's make the code flow a bit tricky to follow (this function is
> already a bit tricksy with the early exit for the evtchn suspend case).
>
> Why not pass si to libxl__domain_suspend_device_model and let it contain
> the "if !hvm return" and logging stuff so you can just call in in place
> of the two goto statements?
>
>
will do.

shriram

--000e0ce040442fffd004b7d65dcd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 1:54 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On Tue, 2012-01-31 at 01:05 +0000, =
<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)<=
br>
&gt; +{<br>
&gt; +<br>
&gt; + =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; + =A0 =A0 =A0 =A0libxl__qemu_traditional_cmd(gc, domid, &quot;continue=
&quot;);<br>
<br>
</div></div>No libxl__wait_for_device_model -&gt; &quot;running&quot;?<br>
<div><div class=3D"h5"><br></div></div></blockquote><div><br>Nope. Thats ho=
w xend/remus also does it. There seems to be no reference to such<br>a stat=
e anywhere.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">

<div><div class=3D"h5">
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0}<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; + =A0 =A0 =A0 =A0if (libxl__qmp_resume(gc, domid))<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
&gt; + =A0 =A0default:<br>
&gt; + =A0 =A0 =A0 =A0return ERROR_INVAL;<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return 0;<br>
&gt; +}<br>
&gt; +<br>
&gt; =A0static int libxl__domain_suspend_common_callback(void *data)<br>
&gt; =A0{<br>
&gt; =A0 =A0 =A0struct suspendinfo *si =3D data;<br>
&gt; @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0si-&gt;guest_responded =3D 1;<br>
&gt; - =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0goto suspend_dm;<br>
&gt; =A0 =A0 =A0}<br>
&gt;<br>
&gt; =A0 =A0 =A0if (si-&gt;hvm &amp;&amp; (!hvm_pvdrv || hvm_s_state)) {<br=
>
&gt; @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0shutdown_reason =3D (info.flags &gt;&gt; XE=
N_DOMINF_shutdownshift) &amp; XEN_DOMINF_shutdownmask;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0if (shutdown_reason =3D=3D SHUTDOWN_suspend=
) {<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, &=
quot;guest has suspended&quot;);<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto suspend_dm;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt;<br>
&gt; @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_<br>
&gt;<br>
&gt; =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;guest did not suspe=
nd&quot;);<br>
&gt; =A0 =A0 =A0return 0;<br>
&gt; +<br>
&gt; + suspend_dm:<br>
<br>
</div></div>The goto&#39;s make the code flow a bit tricky to follow (this =
function is<br>
already a bit tricksy with the early exit for the evtchn suspend case).<br>
<br>
Why not pass si to libxl__domain_suspend_device_model and let it contain<br=
>
the &quot;if !hvm return&quot; and logging stuff so you can just call in in=
 place<br>
of the two goto statements?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br>will do. <br></div><br></div>shriram<br>

--000e0ce040442fffd004b7d65dcd--


--===============8608592479568863293==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8608592479568863293==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:34:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:34:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHac-0003Gn-Sg; Tue, 31 Jan 2012 17:33:54 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsHab-0003Gb-DV
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:33:53 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-13.tower-216.messagelabs.com!1328031224!11975407!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20481 invoked from network); 31 Jan 2012 17:33:46 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-13.tower-216.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 17:33:46 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHXgpO008237
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:33:43 -0800
Received: by bkbzv3 with SMTP id zv3so381835bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:33:41 -0800 (PST)
Received: by 10.205.128.4 with SMTP id hc4mr10805779bkc.13.1328031221153; Tue,
	31 Jan 2012 09:33:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:32:59 -0800 (PST)
In-Reply-To: <1328003681.26983.318.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
	<1328003681.26983.318.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:32:59 -0800
Message-ID: <CAP8mzPMer3bnxqBRCJYCYqi5nR9DcjQzmRbebNDKD39bm=v+pg@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
	QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============8608592479568863293=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============8608592479568863293==
Content-Type: multipart/alternative; boundary=000e0ce040442fffd004b7d65dcd

--000e0ce040442fffd004b7d65dcd
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 1:54 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
> > +{
> > +
> > +    switch (libxl__device_model_version_running(gc, domid)) {
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
> > +        libxl__qemu_traditional_cmd(gc, domid, "continue");
>
> No libxl__wait_for_device_model -> "running"?
>
>
Nope. Thats how xend/remus also does it. There seems to be no reference to
such
a state anywhere.


>  > +        break;
> > +    }
> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
> > +        if (libxl__qmp_resume(gc, domid))
> > +            return ERROR_FAIL;
> > +    default:
> > +        return ERROR_INVAL;
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> >  static int libxl__domain_suspend_common_callback(void *data)
> >  {
> >      struct suspendinfo *si = data;
> > @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
> >              return 0;
> >          }
> >          si->guest_responded = 1;
> > -        return 1;
> > +        goto suspend_dm;
> >      }
> >
> >      if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
> > @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
> >              shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
> & XEN_DOMINF_shutdownmask;
> >              if (shutdown_reason == SHUTDOWN_suspend) {
> >                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has
> suspended");
> > -                return 1;
> > +                goto suspend_dm;
> >              }
> >          }
> >
> > @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
> >
> >      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
> >      return 0;
> > +
> > + suspend_dm:
>
> The goto's make the code flow a bit tricky to follow (this function is
> already a bit tricksy with the early exit for the evtchn suspend case).
>
> Why not pass si to libxl__domain_suspend_device_model and let it contain
> the "if !hvm return" and logging stuff so you can just call in in place
> of the two goto statements?
>
>
will do.

shriram

--000e0ce040442fffd004b7d65dcd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 1:54 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On Tue, 2012-01-31 at 01:05 +0000, =
<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)<=
br>
&gt; +{<br>
&gt; +<br>
&gt; + =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; + =A0 =A0 =A0 =A0libxl__qemu_traditional_cmd(gc, domid, &quot;continue=
&quot;);<br>
<br>
</div></div>No libxl__wait_for_device_model -&gt; &quot;running&quot;?<br>
<div><div class=3D"h5"><br></div></div></blockquote><div><br>Nope. Thats ho=
w xend/remus also does it. There seems to be no reference to such<br>a stat=
e anywhere.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">

<div><div class=3D"h5">
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0}<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; + =A0 =A0 =A0 =A0if (libxl__qmp_resume(gc, domid))<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
&gt; + =A0 =A0default:<br>
&gt; + =A0 =A0 =A0 =A0return ERROR_INVAL;<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return 0;<br>
&gt; +}<br>
&gt; +<br>
&gt; =A0static int libxl__domain_suspend_common_callback(void *data)<br>
&gt; =A0{<br>
&gt; =A0 =A0 =A0struct suspendinfo *si =3D data;<br>
&gt; @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0si-&gt;guest_responded =3D 1;<br>
&gt; - =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0goto suspend_dm;<br>
&gt; =A0 =A0 =A0}<br>
&gt;<br>
&gt; =A0 =A0 =A0if (si-&gt;hvm &amp;&amp; (!hvm_pvdrv || hvm_s_state)) {<br=
>
&gt; @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0shutdown_reason =3D (info.flags &gt;&gt; XE=
N_DOMINF_shutdownshift) &amp; XEN_DOMINF_shutdownmask;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0if (shutdown_reason =3D=3D SHUTDOWN_suspend=
) {<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, &=
quot;guest has suspended&quot;);<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto suspend_dm;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt;<br>
&gt; @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_<br>
&gt;<br>
&gt; =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;guest did not suspe=
nd&quot;);<br>
&gt; =A0 =A0 =A0return 0;<br>
&gt; +<br>
&gt; + suspend_dm:<br>
<br>
</div></div>The goto&#39;s make the code flow a bit tricky to follow (this =
function is<br>
already a bit tricksy with the early exit for the evtchn suspend case).<br>
<br>
Why not pass si to libxl__domain_suspend_device_model and let it contain<br=
>
the &quot;if !hvm return&quot; and logging stuff so you can just call in in=
 place<br>
of the two goto statements?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br>will do. <br></div><br></div>shriram<br>

--000e0ce040442fffd004b7d65dcd--


--===============8608592479568863293==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============8608592479568863293==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:53:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:53:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHtK-0003d4-MZ; Tue, 31 Jan 2012 17:53:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsHtI-0003cw-NM
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:53:12 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328032314!63235394!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24923 invoked from network); 31 Jan 2012 17:51:56 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:51:56 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHr0Hu011856
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:53:01 -0800
Received: by bkbzv3 with SMTP id zv3so417224bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:52:59 -0800 (PST)
Received: by 10.204.145.82 with SMTP id c18mr10772562bkv.121.1328032379306;
	Tue, 31 Jan 2012 09:52:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:52:19 -0800 (PST)
In-Reply-To: <1328004041.26983.322.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:52:19 -0800
Message-ID: <CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============4650708505621222075=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4650708505621222075==
Content-Type: multipart/alternative; boundary=000e0cdfc7bc38051d04b7d6a253

--000e0cdfc7bc38051d04b7d6a253
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 2:00 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:Please can
> you add a few words about what fast means and when its use
> would be appropriate.
>
> I'm not sure fast is right word -- it happens that this mechanism is
> faster but isn't the real meaning "co-operative" or something along
> those lines?
>
> Would a better name be libxl_domain_suspend_cancel, sharing a common
> helper internally with libxl_domain_resume?
>
>
The explanation is already there, on top of xc_domain_resume in libxc.
fast suspend - hvm guest checks for the return code of the shutdown call.
If it returns 1,
  then it just resumes, else shuts down. (similar case for PV guest)

if fast = 0, then the guest is led to believe that it is resuming in a new
host (ie wakeup
from hibernate sorts).

As for guests supporting this fast suspend, almost all guests (pv/hvm
linux/windows)
do support suspend_cancel. IIRC, I think some very old kernels didnt have
this ability.


 Ian.
>
> >  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> >  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> >  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> > diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c        Mon Jan 30 16:58:31 2012 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c        Mon Jan 30 16:58:47 2012 -0800
> > @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
> >          if (common_domname) {
> >              libxl_domain_rename(ctx, domid, away_domname,
> common_domname);
> >          }
> > -        rc = libxl_domain_resume(ctx, domid);
> > +        rc = libxl_domain_resume(ctx, domid, 1);
> >          if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
> >
> >          fprintf(stderr, "Migration failed due to problems at
> target.\n");
> > @@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
> >      close(send_fd);
> >      migration_child_report(child, recv_fd);
> >      fprintf(stderr, "Migration failed, resuming at sender.\n");
> > -    libxl_domain_resume(ctx, domid);
> > +    libxl_domain_resume(ctx, domid, 1);
> >      exit(-ERROR_FAIL);
> >
> >   failed_badly:
>
>
>

--000e0cdfc7bc38051d04b7d6a253
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 2:00 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On Tue, 2012-01-31 at 01:05 +0000, =
<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:Please c=
an you add a few words about what fast means and when its use<br></div></di=
v>


would be appropriate.<br>
<br>
I&#39;m not sure fast is right word -- it happens that this mechanism is<br=
>
faster but isn&#39;t the real meaning &quot;co-operative&quot; or something=
 along<br>
those lines?<br>
<br>
Would a better name be libxl_domain_suspend_cancel, sharing a common<br>
helper internally with libxl_domain_resume?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br>The explanation is already there, on top of xc_domain_resume in=
 libxc.<br>fast suspend - hvm guest checks for the return code of the shutd=
own call. If it returns 1,<br>

=A0 then it just resumes, else shuts down. (similar case for PV guest)<br><=
br>if fast =3D 0, then the guest is led to believe that it is resuming in a=
 new host (ie wakeup<br>from hibernate sorts).<br>=A0<br>As for guests supp=
orting this fast suspend, almost all guests (pv/hvm linux/windows) <br>

do support suspend_cancel. IIRC, I think some very old kernels didnt have t=
his ability.<br><br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">

<span class=3D"HOEnZb"><font color=3D"#888888">
Ian.<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; =A0int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);<br>
&gt; =A0int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);<br>
&gt; =A0int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);<br>
&gt; diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/xl_cmdimpl.c<br>
&gt; --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Mon Jan 30 16:58:31 2012=
 -0800<br>
&gt; +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Mon Jan 30 16:58:47 2012=
 -0800<br>
&gt; @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d<br>
&gt; =A0 =A0 =A0 =A0 =A0if (common_domname) {<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_domain_rename(ctx, domid, away_domnam=
e, common_domname);<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; - =A0 =A0 =A0 =A0rc =3D libxl_domain_resume(ctx, domid);<br>
&gt; + =A0 =A0 =A0 =A0rc =3D libxl_domain_resume(ctx, domid, 1);<br>
&gt; =A0 =A0 =A0 =A0 =A0if (!rc) fprintf(stderr, &quot;migration sender: Re=
sumed OK.\n&quot;);<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;Migration failed due to probl=
ems at target.\n&quot;);<br>
&gt; @@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d<br>
&gt; =A0 =A0 =A0close(send_fd);<br>
&gt; =A0 =A0 =A0migration_child_report(child, recv_fd);<br>
&gt; =A0 =A0 =A0fprintf(stderr, &quot;Migration failed, resuming at sender.=
\n&quot;);<br>
&gt; - =A0 =A0libxl_domain_resume(ctx, domid);<br>
&gt; + =A0 =A0libxl_domain_resume(ctx, domid, 1);<br>
&gt; =A0 =A0 =A0exit(-ERROR_FAIL);<br>
&gt;<br>
&gt; =A0 failed_badly:<br>
<br>
<br>
</div></div></blockquote></div><br>

--000e0cdfc7bc38051d04b7d6a253--


--===============4650708505621222075==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4650708505621222075==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:53:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:53:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHtK-0003d4-MZ; Tue, 31 Jan 2012 17:53:14 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsHtI-0003cw-NM
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:53:12 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-27.messagelabs.com!1328032314!63235394!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24923 invoked from network); 31 Jan 2012 17:51:56 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:51:56 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHr0Hu011856
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:53:01 -0800
Received: by bkbzv3 with SMTP id zv3so417224bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:52:59 -0800 (PST)
Received: by 10.204.145.82 with SMTP id c18mr10772562bkv.121.1328032379306;
	Tue, 31 Jan 2012 09:52:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:52:19 -0800 (PST)
In-Reply-To: <1328004041.26983.322.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<efe92d80c47487485056.1327971909@athos.nss.cs.ubc.ca>
	<1328004041.26983.322.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:52:19 -0800
Message-ID: <CAP8mzPPB49gH22_grx9KKQMv_gmNtVQOg8hPz+7YYg4OhU44vw@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 4 of 6] libxl: support suspend_cancel in
	domain_resume
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============4650708505621222075=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4650708505621222075==
Content-Type: multipart/alternative; boundary=000e0cdfc7bc38051d04b7d6a253

--000e0cdfc7bc38051d04b7d6a253
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 2:00 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:Please can
> you add a few words about what fast means and when its use
> would be appropriate.
>
> I'm not sure fast is right word -- it happens that this mechanism is
> faster but isn't the real meaning "co-operative" or something along
> those lines?
>
> Would a better name be libxl_domain_suspend_cancel, sharing a common
> helper internally with libxl_domain_resume?
>
>
The explanation is already there, on top of xc_domain_resume in libxc.
fast suspend - hvm guest checks for the return code of the shutdown call.
If it returns 1,
  then it just resumes, else shuts down. (similar case for PV guest)

if fast = 0, then the guest is led to believe that it is resuming in a new
host (ie wakeup
from hibernate sorts).

As for guests supporting this fast suspend, almost all guests (pv/hvm
linux/windows)
do support suspend_cancel. IIRC, I think some very old kernels didnt have
this ability.


 Ian.
>
> >  int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> >  int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> >  int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);
> > diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c        Mon Jan 30 16:58:31 2012 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c        Mon Jan 30 16:58:47 2012 -0800
> > @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d
> >          if (common_domname) {
> >              libxl_domain_rename(ctx, domid, away_domname,
> common_domname);
> >          }
> > -        rc = libxl_domain_resume(ctx, domid);
> > +        rc = libxl_domain_resume(ctx, domid, 1);
> >          if (!rc) fprintf(stderr, "migration sender: Resumed OK.\n");
> >
> >          fprintf(stderr, "Migration failed due to problems at
> target.\n");
> > @@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d
> >      close(send_fd);
> >      migration_child_report(child, recv_fd);
> >      fprintf(stderr, "Migration failed, resuming at sender.\n");
> > -    libxl_domain_resume(ctx, domid);
> > +    libxl_domain_resume(ctx, domid, 1);
> >      exit(-ERROR_FAIL);
> >
> >   failed_badly:
>
>
>

--000e0cdfc7bc38051d04b7d6a253
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 2:00 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On Tue, 2012-01-31 at 01:05 +0000, =
<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:Please c=
an you add a few words about what fast means and when its use<br></div></di=
v>


would be appropriate.<br>
<br>
I&#39;m not sure fast is right word -- it happens that this mechanism is<br=
>
faster but isn&#39;t the real meaning &quot;co-operative&quot; or something=
 along<br>
those lines?<br>
<br>
Would a better name be libxl_domain_suspend_cancel, sharing a common<br>
helper internally with libxl_domain_resume?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br>The explanation is already there, on top of xc_domain_resume in=
 libxc.<br>fast suspend - hvm guest checks for the return code of the shutd=
own call. If it returns 1,<br>

=A0 then it just resumes, else shuts down. (similar case for PV guest)<br><=
br>if fast =3D 0, then the guest is led to believe that it is resuming in a=
 new host (ie wakeup<br>from hibernate sorts).<br>=A0<br>As for guests supp=
orting this fast suspend, almost all guests (pv/hvm linux/windows) <br>

do support suspend_cancel. IIRC, I think some very old kernels didnt have t=
his ability.<br><br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">

<span class=3D"HOEnZb"><font color=3D"#888888">
Ian.<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
&gt; =A0int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);<br>
&gt; =A0int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);<br>
&gt; =A0int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid);<br>
&gt; diff -r cd3d43d88c05 -r efe92d80c474 tools/libxl/xl_cmdimpl.c<br>
&gt; --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Mon Jan 30 16:58:31 2012=
 -0800<br>
&gt; +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Mon Jan 30 16:58:47 2012=
 -0800<br>
&gt; @@ -2751,7 +2751,7 @@ static void migrate_domain(const char *d<br>
&gt; =A0 =A0 =A0 =A0 =A0if (common_domname) {<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0libxl_domain_rename(ctx, domid, away_domnam=
e, common_domname);<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; - =A0 =A0 =A0 =A0rc =3D libxl_domain_resume(ctx, domid);<br>
&gt; + =A0 =A0 =A0 =A0rc =3D libxl_domain_resume(ctx, domid, 1);<br>
&gt; =A0 =A0 =A0 =A0 =A0if (!rc) fprintf(stderr, &quot;migration sender: Re=
sumed OK.\n&quot;);<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0 =A0fprintf(stderr, &quot;Migration failed due to probl=
ems at target.\n&quot;);<br>
&gt; @@ -2773,7 +2773,7 @@ static void migrate_domain(const char *d<br>
&gt; =A0 =A0 =A0close(send_fd);<br>
&gt; =A0 =A0 =A0migration_child_report(child, recv_fd);<br>
&gt; =A0 =A0 =A0fprintf(stderr, &quot;Migration failed, resuming at sender.=
\n&quot;);<br>
&gt; - =A0 =A0libxl_domain_resume(ctx, domid);<br>
&gt; + =A0 =A0libxl_domain_resume(ctx, domid, 1);<br>
&gt; =A0 =A0 =A0exit(-ERROR_FAIL);<br>
&gt;<br>
&gt; =A0 failed_badly:<br>
<br>
<br>
</div></div></blockquote></div><br>

--000e0cdfc7bc38051d04b7d6a253--


--===============4650708505621222075==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4650708505621222075==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:57:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHwb-0003m3-AP; Tue, 31 Jan 2012 17:56:37 +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 1RsHwZ-0003lc-Hg
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:56:35 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328032587!8666985!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1713 invoked from network); 31 Jan 2012 17:56:29 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:56:29 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHuP6p012386
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:56:26 -0800
Received: by bkbzv3 with SMTP id zv3so422835bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:56:24 -0800 (PST)
Received: by 10.204.141.14 with SMTP id k14mr10794299bku.67.1328032584357;
	Tue, 31 Jan 2012 09:56:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:55:44 -0800 (PST)
In-Reply-To: <1328005265.26983.333.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<ffc99e708e90eb140b0a.1327971911@athos.nss.cs.ubc.ca>
	<1328005265.26983.333.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:55:44 -0800
Message-ID: <CAP8mzPOq00kR6-RnrSCAZuudLwtLuHTMj0fm2=njJ6s5KRiacA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6 of 6] libxl: resume instead of unpause on
	xl save -c
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="===============6973330762589617513=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6973330762589617513==
Content-Type: multipart/alternative; boundary=00151759367070d74d04b7d6aee9

--00151759367070d74d04b7d6aee9
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 2:21 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1327971541 28800
> > # Node ID ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
> > # Parent  d79c7a853c644d459cda93bf61657be48104cd63
> > libxl: resume instead of unpause on xl save -c
> >
> > The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
> > So call libxl_domain_resume instead of libxl_domain_unpause, when taking
> > a checkpoint of the domain (using xl save -c).
> >
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
> Does checkpoint imply/require support for this resume mechanism?
>
>
Yes. pause & unpause, suspend & resume - thats the order of calls.
A checkpoint involves
 suspend_guest
  copy out data
 resume_guest

The current libxl code does
 suspend_guest
   copy out data
 unpause_guest



>  > diff -r d79c7a853c64 -r ffc99e708e90 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c        Mon Jan 30 16:58:53 2012 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c        Mon Jan 30 16:59:01 2012 -0800
> > @@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
> >      close(fd);
> >
> >      if (checkpoint)
> > -        libxl_domain_unpause(ctx, domid);
> > +        libxl_domain_resume(ctx, domid, 1);
> >      else
> >          libxl_domain_destroy(ctx, domid);
> >
>
>
>

--00151759367070d74d04b7d6aee9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 2:21 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Tue, 2012-01-31 at 01:05 +0000, <a href=3D"mailto:rshr=
iram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; # HG changeset patch<br>
&gt; # User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">r=
shriram@cs.ubc.ca</a>&gt;<br>
&gt; # Date 1327971541 28800<br>
&gt; # Node ID ffc99e708e90eb140b0a6f2e7087d567e71e9d0f<br>
&gt; # Parent =A0d79c7a853c644d459cda93bf61657be48104cd63<br>
&gt; libxl: resume instead of unpause on xl save -c<br>
&gt;<br>
&gt; The guest is &quot;suspended&quot; via libxl_domain_suspend when takin=
g a snapshot.<br>
&gt; So call libxl_domain_resume instead of libxl_domain_unpause, when taki=
ng<br>
&gt; a checkpoint of the domain (using xl save -c).<br>
&gt;<br>
&gt; Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.u=
bc.ca">rshriram@cs.ubc.ca</a>&gt;<br>
<br>
</div>Does checkpoint imply/require support for this resume mechanism?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br>Yes. pause &amp; unpause, suspend &amp; resume - thats the order of call=
s.<br>A checkpoint involves <br>=A0suspend_guest<br>=A0 copy out data<br>=
=A0resume_guest<br>

<br>The current libxl code does<br>=A0suspend_guest<br>=A0=A0 copy out data=
<br>=A0unpause_guest<br><br>=A0<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">
&gt; diff -r d79c7a853c64 -r ffc99e708e90 tools/libxl/xl_cmdimpl.c<br>
&gt; --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Mon Jan 30 16:58:53 2012=
 -0800<br>
&gt; +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Mon Jan 30 16:59:01 2012=
 -0800<br>
&gt; @@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co<br>
&gt; =A0 =A0 =A0close(fd);<br>
&gt;<br>
&gt; =A0 =A0 =A0if (checkpoint)<br>
&gt; - =A0 =A0 =A0 =A0libxl_domain_unpause(ctx, domid);<br>
&gt; + =A0 =A0 =A0 =A0libxl_domain_resume(ctx, domid, 1);<br>
&gt; =A0 =A0 =A0else<br>
&gt; =A0 =A0 =A0 =A0 =A0libxl_domain_destroy(ctx, domid);<br>
&gt;<br>
<br>
<br>
</div></div></blockquote></div><br>

--00151759367070d74d04b7d6aee9--


--===============6973330762589617513==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6973330762589617513==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 17:57:12 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 17:57:12 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsHwb-0003m3-AP; Tue, 31 Jan 2012 17:56:37 +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 1RsHwZ-0003lc-Hg
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 17:56:35 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328032587!8666985!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 1713 invoked from network); 31 Jan 2012 17:56:29 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-6.tower-21.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 17:56:29 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VHuP6p012386
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 09:56:26 -0800
Received: by bkbzv3 with SMTP id zv3so422835bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 09:56:24 -0800 (PST)
Received: by 10.204.141.14 with SMTP id k14mr10794299bku.67.1328032584357;
	Tue, 31 Jan 2012 09:56:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:55:44 -0800 (PST)
In-Reply-To: <1328005265.26983.333.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<ffc99e708e90eb140b0a.1327971911@athos.nss.cs.ubc.ca>
	<1328005265.26983.333.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:55:44 -0800
Message-ID: <CAP8mzPOq00kR6-RnrSCAZuudLwtLuHTMj0fm2=njJ6s5KRiacA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 6 of 6] libxl: resume instead of unpause on
	xl save -c
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="===============6973330762589617513=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============6973330762589617513==
Content-Type: multipart/alternative; boundary=00151759367070d74d04b7d6aee9

--00151759367070d74d04b7d6aee9
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 2:21 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
> > # HG changeset patch
> > # User Shriram Rajagopalan <rshriram@cs.ubc.ca>
> > # Date 1327971541 28800
> > # Node ID ffc99e708e90eb140b0a6f2e7087d567e71e9d0f
> > # Parent  d79c7a853c644d459cda93bf61657be48104cd63
> > libxl: resume instead of unpause on xl save -c
> >
> > The guest is "suspended" via libxl_domain_suspend when taking a snapshot.
> > So call libxl_domain_resume instead of libxl_domain_unpause, when taking
> > a checkpoint of the domain (using xl save -c).
> >
> > Signed-off-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
>
> Does checkpoint imply/require support for this resume mechanism?
>
>
Yes. pause & unpause, suspend & resume - thats the order of calls.
A checkpoint involves
 suspend_guest
  copy out data
 resume_guest

The current libxl code does
 suspend_guest
   copy out data
 unpause_guest



>  > diff -r d79c7a853c64 -r ffc99e708e90 tools/libxl/xl_cmdimpl.c
> > --- a/tools/libxl/xl_cmdimpl.c        Mon Jan 30 16:58:53 2012 -0800
> > +++ b/tools/libxl/xl_cmdimpl.c        Mon Jan 30 16:59:01 2012 -0800
> > @@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co
> >      close(fd);
> >
> >      if (checkpoint)
> > -        libxl_domain_unpause(ctx, domid);
> > +        libxl_domain_resume(ctx, domid, 1);
> >      else
> >          libxl_domain_destroy(ctx, domid);
> >
>
>
>

--00151759367070d74d04b7d6aee9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 2:21 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On Tue, 2012-01-31 at 01:05 +0000, <a href=3D"mailto:rshr=
iram@cs.ubc.ca">rshriram@cs.ubc.ca</a> wrote:<br>
&gt; # HG changeset patch<br>
&gt; # User Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.ubc.ca">r=
shriram@cs.ubc.ca</a>&gt;<br>
&gt; # Date 1327971541 28800<br>
&gt; # Node ID ffc99e708e90eb140b0a6f2e7087d567e71e9d0f<br>
&gt; # Parent =A0d79c7a853c644d459cda93bf61657be48104cd63<br>
&gt; libxl: resume instead of unpause on xl save -c<br>
&gt;<br>
&gt; The guest is &quot;suspended&quot; via libxl_domain_suspend when takin=
g a snapshot.<br>
&gt; So call libxl_domain_resume instead of libxl_domain_unpause, when taki=
ng<br>
&gt; a checkpoint of the domain (using xl save -c).<br>
&gt;<br>
&gt; Signed-off-by: Shriram Rajagopalan &lt;<a href=3D"mailto:rshriram@cs.u=
bc.ca">rshriram@cs.ubc.ca</a>&gt;<br>
<br>
</div>Does checkpoint imply/require support for this resume mechanism?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br>Yes. pause &amp; unpause, suspend &amp; resume - thats the order of call=
s.<br>A checkpoint involves <br>=A0suspend_guest<br>=A0 copy out data<br>=
=A0resume_guest<br>

<br>The current libxl code does<br>=A0suspend_guest<br>=A0=A0 copy out data=
<br>=A0unpause_guest<br><br>=A0<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">
&gt; diff -r d79c7a853c64 -r ffc99e708e90 tools/libxl/xl_cmdimpl.c<br>
&gt; --- a/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Mon Jan 30 16:58:53 2012=
 -0800<br>
&gt; +++ b/tools/libxl/xl_cmdimpl.c =A0 =A0 =A0 =A0Mon Jan 30 16:59:01 2012=
 -0800<br>
&gt; @@ -2524,7 +2524,7 @@ static int save_domain(const char *p, co<br>
&gt; =A0 =A0 =A0close(fd);<br>
&gt;<br>
&gt; =A0 =A0 =A0if (checkpoint)<br>
&gt; - =A0 =A0 =A0 =A0libxl_domain_unpause(ctx, domid);<br>
&gt; + =A0 =A0 =A0 =A0libxl_domain_resume(ctx, domid, 1);<br>
&gt; =A0 =A0 =A0else<br>
&gt; =A0 =A0 =A0 =A0 =A0libxl_domain_destroy(ctx, domid);<br>
&gt;<br>
<br>
<br>
</div></div></blockquote></div><br>

--00151759367070d74d04b7d6aee9--


--===============6973330762589617513==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============6973330762589617513==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 18:00:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsI04-00042h-5I; Tue, 31 Jan 2012 18:00:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsI02-00042V-Cf
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:00:10 +0000
Received: from [85.158.138.51:32812] by server-4.bemta-3.messagelabs.com id
	1D/16-32238-92C282F4; Tue, 31 Jan 2012 18:00:09 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328032806!11468439!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12055 invoked from network); 31 Jan 2012 18:00:08 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 18:00:08 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VI0490013148
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 10:00:05 -0800
Received: by bkbzv3 with SMTP id zv3so429264bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 10:00:03 -0800 (PST)
Received: by 10.204.130.89 with SMTP id r25mr10820728bks.49.1328032803306;
	Tue, 31 Jan 2012 10:00:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:59:23 -0800 (PST)
In-Reply-To: <1328007203.26983.347.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
	<0129989da2cda789f86f.1327972925@athos.nss.cs.ubc.ca>
	<1328007203.26983.347.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:59:23 -0800
Message-ID: <CAP8mzPOk-_=A9a+hnf5O4_eRKn9vhKBpU7qXbeU+Xorz29AKpQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Remus -
	suspend/postflush/commit callbacks
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="===============2798159479883757733=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2798159479883757733==
Content-Type: multipart/alternative; boundary=0015174482667dbe1704b7d6bb72

--0015174482667dbe1704b7d6bb72
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 2:53 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> > @@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
> >      }
> >
> >      memset(&callbacks, 0, sizeof(callbacks));
> > -    callbacks.suspend = libxl__domain_suspend_common_callback;
> > +    if (r_info != NULL) {
> > +        /* save_callbacks:
> > +         * suspend - called after expiration of checkpoint interval,
> > +         *           to *suspend* the domain.
> > +         *
> > +         * postcopy - called after the domain's dirty pages have been
> > +         *            copied into an output buffer. We *resume* the
> domain
> > +         *            & the device model, return to the caller. Caller
> then
> > +         *            flushes the output buffer, while the domain
> continues to run.
> > +         *
> > +         * checkpoint - called after the memory checkpoint has been
> flushed out
> > +         *              into the network. Send the saved device state,
> *wait*
> > +         *              for checkpoint ack and *release* the network
> buffer (TBD).
> > +         *              Then *sleep* for the checkpoint interval.
> > +         */
>
> Please can you put this next to the definition of the struct (in
> xenguest.h). Otherwise this patch looks ok to me.
>
> Ian.
>
>
>
struct save_callbacks already has comments on these callbacks, it is
generic though,
as the postcopy and checkpoint callbacks could be used even without Remus.
One need
not necessarily do all the actions specified in the above comment.


But, with libxl/remus, it seemed proper to add more detailed comments to
the code
that does other things in the callback, specific to remus/checkpointing.

shriram

--0015174482667dbe1704b7d6bb72
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 2:53 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">&gt; @@ -669,7 +715,27 @@ int libxl__domain_suspend_commo=
n(libxl__<br>
&gt; =A0 =A0 =A0}<br>
&gt;<br>
&gt; =A0 =A0 =A0memset(&amp;callbacks, 0, sizeof(callbacks));<br>
&gt; - =A0 =A0callbacks.suspend =3D libxl__domain_suspend_common_callback;<=
br>
&gt; + =A0 =A0if (r_info !=3D NULL) {<br>
&gt; + =A0 =A0 =A0 =A0/* save_callbacks:<br>
&gt; + =A0 =A0 =A0 =A0 * suspend - called after expiration of checkpoint in=
terval,<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 to *suspend* the domain.<br>
&gt; + =A0 =A0 =A0 =A0 *<br>
&gt; + =A0 =A0 =A0 =A0 * postcopy - called after the domain&#39;s dirty pag=
es have been<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0copied into an output buffe=
r. We *resume* the domain<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0&amp; the device model, ret=
urn to the caller. Caller then<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0flushes the output buffer, =
while the domain continues to run.<br>
&gt; + =A0 =A0 =A0 =A0 *<br>
&gt; + =A0 =A0 =A0 =A0 * checkpoint - called after the memory checkpoint ha=
s been flushed out<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0into the network. Send =
the saved device state, *wait*<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0for checkpoint ack and =
*release* the network buffer (TBD).<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0Then *sleep* for the ch=
eckpoint interval.<br>
&gt; + =A0 =A0 =A0 =A0 */<br>
<br>
</div>Please can you put this next to the definition of the struct (in<br>
xenguest.h). Otherwise this patch looks ok to me.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br></font></span></blockquote><div><br>struct save_callbacks already has c=
omments on these callbacks, it is generic though,<br>as the postcopy and ch=
eckpoint callbacks could be used even without Remus. One need<br>not necess=
arily do all the actions specified in the above comment.<br>

<br><br>But, with libxl/remus, it seemed proper to add more detailed commen=
ts to the code <br>that does other things in the callback, specific to remu=
s/checkpointing.<br></div></div><br>shriram<br>

--0015174482667dbe1704b7d6bb72--


--===============2798159479883757733==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2798159479883757733==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 18:00:43 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18:00:43 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsI04-00042h-5I; Tue, 31 Jan 2012 18:00:12 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsI02-00042V-Cf
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:00:10 +0000
Received: from [85.158.138.51:32812] by server-4.bemta-3.messagelabs.com id
	1D/16-32238-92C282F4; Tue, 31 Jan 2012 18:00:09 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-5.tower-174.messagelabs.com!1328032806!11468439!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12055 invoked from network); 31 Jan 2012 18:00:08 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-5.tower-174.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 18:00:08 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VI0490013148
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 10:00:05 -0800
Received: by bkbzv3 with SMTP id zv3so429264bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 10:00:03 -0800 (PST)
Received: by 10.204.130.89 with SMTP id r25mr10820728bks.49.1328032803306;
	Tue, 31 Jan 2012 10:00:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 09:59:23 -0800 (PST)
In-Reply-To: <1328007203.26983.347.camel@zakaz.uk.xensource.com>
References: <patchbomb.1327972924@athos.nss.cs.ubc.ca>
	<0129989da2cda789f86f.1327972925@athos.nss.cs.ubc.ca>
	<1328007203.26983.347.camel@zakaz.uk.xensource.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 09:59:23 -0800
Message-ID: <CAP8mzPOk-_=A9a+hnf5O4_eRKn9vhKBpU7qXbeU+Xorz29AKpQ@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 1 of 2] libxl: Remus -
	suspend/postflush/commit callbacks
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="===============2798159479883757733=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============2798159479883757733==
Content-Type: multipart/alternative; boundary=0015174482667dbe1704b7d6bb72

--0015174482667dbe1704b7d6bb72
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 2:53 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> > @@ -669,7 +715,27 @@ int libxl__domain_suspend_common(libxl__
> >      }
> >
> >      memset(&callbacks, 0, sizeof(callbacks));
> > -    callbacks.suspend = libxl__domain_suspend_common_callback;
> > +    if (r_info != NULL) {
> > +        /* save_callbacks:
> > +         * suspend - called after expiration of checkpoint interval,
> > +         *           to *suspend* the domain.
> > +         *
> > +         * postcopy - called after the domain's dirty pages have been
> > +         *            copied into an output buffer. We *resume* the
> domain
> > +         *            & the device model, return to the caller. Caller
> then
> > +         *            flushes the output buffer, while the domain
> continues to run.
> > +         *
> > +         * checkpoint - called after the memory checkpoint has been
> flushed out
> > +         *              into the network. Send the saved device state,
> *wait*
> > +         *              for checkpoint ack and *release* the network
> buffer (TBD).
> > +         *              Then *sleep* for the checkpoint interval.
> > +         */
>
> Please can you put this next to the definition of the struct (in
> xenguest.h). Otherwise this patch looks ok to me.
>
> Ian.
>
>
>
struct save_callbacks already has comments on these callbacks, it is
generic though,
as the postcopy and checkpoint callbacks could be used even without Remus.
One need
not necessarily do all the actions specified in the above comment.


But, with libxl/remus, it seemed proper to add more detailed comments to
the code
that does other things in the callback, specific to remus/checkpointing.

shriram

--0015174482667dbe1704b7d6bb72
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 2:53 AM, Ian Campbell <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix.com">Ian.Campbell=
@citrix.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"im">&gt; @@ -669,7 +715,27 @@ int libxl__domain_suspend_commo=
n(libxl__<br>
&gt; =A0 =A0 =A0}<br>
&gt;<br>
&gt; =A0 =A0 =A0memset(&amp;callbacks, 0, sizeof(callbacks));<br>
&gt; - =A0 =A0callbacks.suspend =3D libxl__domain_suspend_common_callback;<=
br>
&gt; + =A0 =A0if (r_info !=3D NULL) {<br>
&gt; + =A0 =A0 =A0 =A0/* save_callbacks:<br>
&gt; + =A0 =A0 =A0 =A0 * suspend - called after expiration of checkpoint in=
terval,<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 to *suspend* the domain.<br>
&gt; + =A0 =A0 =A0 =A0 *<br>
&gt; + =A0 =A0 =A0 =A0 * postcopy - called after the domain&#39;s dirty pag=
es have been<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0copied into an output buffe=
r. We *resume* the domain<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0&amp; the device model, ret=
urn to the caller. Caller then<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0flushes the output buffer, =
while the domain continues to run.<br>
&gt; + =A0 =A0 =A0 =A0 *<br>
&gt; + =A0 =A0 =A0 =A0 * checkpoint - called after the memory checkpoint ha=
s been flushed out<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0into the network. Send =
the saved device state, *wait*<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0for checkpoint ack and =
*release* the network buffer (TBD).<br>
&gt; + =A0 =A0 =A0 =A0 * =A0 =A0 =A0 =A0 =A0 =A0 =A0Then *sleep* for the ch=
eckpoint interval.<br>
&gt; + =A0 =A0 =A0 =A0 */<br>
<br>
</div>Please can you put this next to the definition of the struct (in<br>
xenguest.h). Otherwise this patch looks ok to me.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Ian.<br>
<br>
<br></font></span></blockquote><div><br>struct save_callbacks already has c=
omments on these callbacks, it is generic though,<br>as the postcopy and ch=
eckpoint callbacks could be used even without Remus. One need<br>not necess=
arily do all the actions specified in the above comment.<br>

<br><br>But, with libxl/remus, it seemed proper to add more detailed commen=
ts to the code <br>that does other things in the callback, specific to remu=
s/checkpointing.<br></div></div><br>shriram<br>

--0015174482667dbe1704b7d6bb72--


--===============2798159479883757733==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============2798159479883757733==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 18:16:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsIF0-0004FY-Ld; Tue, 31 Jan 2012 18:15:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsIEz-0004FT-GB
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:15:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328033730!12965155!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15302 invoked from network); 31 Jan 2012 18:15:31 -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;
	31 Jan 2012 18:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10400369"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 18: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; Tue, 31 Jan 2012 18:15:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsIEs-0000f9-Ft; Tue, 31 Jan 2012 18:15:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsIEs-0005MZ-Bo;
	Tue, 31 Jan 2012 18:15:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20264.12226.353960.721433@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 18:15:30 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <833bcc6d444eaa6cb62d.1327747782@debian.localdomain>
References: <833bcc6d444eaa6cb62d.1327747782@debian.localdomain>
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] 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

Roger Pau Monne writes ("[PATCH v4] libxl: add support for yajl 2.x"):
> libxl: add support for yajl 2.x

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 Jan 31 18:16:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18:16:05 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsIF0-0004FY-Ld; Tue, 31 Jan 2012 18:15:38 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>) id 1RsIEz-0004FT-GB
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:15:37 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-14.tower-21.messagelabs.com!1328033730!12965155!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15302 invoked from network); 31 Jan 2012 18:15:31 -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;
	31 Jan 2012 18:15:31 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10400369"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 18: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; Tue, 31 Jan 2012 18:15:31 +0000
Received: from mariner.cam.xci-test.com	([10.80.2.22]
	helo=mariner.uk.xensource.com ident=Debian-exim)	by
	norwich.cam.xci-test.com
	with esmtp (Exim 4.72)	(envelope-from <Ian.Jackson@eu.citrix.com>)	id
	1RsIEs-0000f9-Ft; Tue, 31 Jan 2012 18:15:30 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsIEs-0005MZ-Bo;
	Tue, 31 Jan 2012 18:15:30 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20264.12226.353960.721433@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 18:15:30 +0000
To: Roger Pau Monne <roger.pau@entel.upc.edu>
In-Reply-To: <833bcc6d444eaa6cb62d.1327747782@debian.localdomain>
References: <833bcc6d444eaa6cb62d.1327747782@debian.localdomain>
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] 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

Roger Pau Monne writes ("[PATCH v4] libxl: add support for yajl 2.x"):
> libxl: add support for yajl 2.x

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 Jan 31 18:40:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsIcd-0004ka-Ch; Tue, 31 Jan 2012 18:40:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RsIcb-0004kC-DH
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:40:02 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328035194!12529671!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4870 invoked from network); 31 Jan 2012 18:39:55 -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;
	31 Jan 2012 18:39:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10400628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 18:39:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 18:39:55 +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 1RsIcU-0000nM-M8;
	Tue, 31 Jan 2012 18:39:54 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RsIcI-00071X-TR;
	Tue, 31 Jan 2012 18:39:42 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 31 Jan 2012 18:39:40 +0000
Message-ID: <1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
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>
Subject: [Xen-devel] [PATCH 2/2] qemu-xen: Intel GPU passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Reset Intel GPU fences when the domain starts (first mapping
of Bar0).

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |  133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 133 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch; name="0002-qemu-xen-Intel-GPU-passthrough.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-qemu-xen-Intel-GPU-passthrough.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 5d5e5da..7403abe 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -13,6 +13,31 @@
 extern int gfx_passthru;
 extern int igd_passthru;
 
+#define IGFX_CANTIGA            0x10
+#define IGFX_IRONLAKE           0x20
+#define IGFX_IBEXPEAK           0x30
+#define IGFX_COUGARPOINT        0x40
+
+struct igfx_chip
+{
+    int chip;
+    uint16_t device_id;
+};
+
+struct igfx_chip igfx_chips[] =
+{
+    {IGFX_IRONLAKE,     0x0042},
+    {IGFX_IRONLAKE,     0x0046},
+    {IGFX_CANTIGA,      0x20e4},
+    {IGFX_CANTIGA,      0x2a42},
+    {IGFX_CANTIGA,      0x2e12},
+    {IGFX_COUGARPOINT,  0x0152},
+    {IGFX_COUGARPOINT,  0x0112},
+    {IGFX_COUGARPOINT,  0x0116},
+    {IGFX_COUGARPOINT,  0x0126},
+    {0, 0}
+};
+
 static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
 {
     PT_LOG("pch_map_irq called\n");
@@ -37,6 +62,98 @@ void intel_pch_init(PCIBus *bus)
                         pch_map_irq, "intel_bridge_1f");
 }
 
+static int igd_get_chip(struct pt_dev *p)
+{
+    int i;
+    int chip = 0;
+    int devid = p->pci_dev->device_id;
+
+    for (i = 0; igfx_chips[i].chip; i++)
+        if (devid == igfx_chips[i].device_id)
+        {
+            chip = igfx_chips[i].chip;
+            break;
+        }
+
+    if (!chip)
+    {
+        if (devid & 0x2000)
+            chip = IGFX_CANTIGA;
+        else if (devid & 0x100)
+            chip =  IGFX_COUGARPOINT;
+        else
+            chip = IGFX_IRONLAKE;
+        PT_LOG("GUESS FOR CHIP 0x%04x as type %x", devid, chip);
+    }
+    return chip;
+}
+
+
+static uint32_t igd_mmio_read(struct pt_dev *p, uint32_t addr, uint8_t size)
+{
+    uint8_t *map = p->bases[0].map;
+    uint32_t ret;
+
+    switch (size)
+    {
+        case 1:
+            ret = *(volatile uint8_t *)(map + addr);
+            break;
+        case 2:
+            ret = *(volatile uint16_t *)(map + addr);
+            break;
+        case 4:
+            ret = *(volatile uint32_t *)(map + addr);
+            break;
+        default:
+            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
+    }
+    return ret;
+}
+
+static void igd_mmio_write(struct pt_dev *p, uint32_t addr, uint32_t val,
+                           uint8_t size)
+{
+    uint8_t *map = p->bases[0].map;
+
+    switch (size)
+    {
+        case 1:
+            *(volatile uint8_t *)(map + addr) = (uint8_t)val;
+            break;
+        case 2:
+            *(volatile uint16_t *)(map + addr) = (uint16_t)val;
+            break;
+        case 4:
+            *(volatile uint32_t *)(map + addr) = (uint32_t)val;
+            break;
+        default:
+            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
+    }
+}
+
+static void igd_reset_fences(struct pt_dev *pt_dev)
+{
+    int i = 0;
+    uint32_t fence_addr;
+
+    switch (igd_get_chip(pt_dev))
+    {
+        case IGFX_CANTIGA:
+        case IGFX_IRONLAKE:
+        case IGFX_IBEXPEAK:
+            fence_addr = 0x3000;
+        case IGFX_COUGARPOINT:
+            fence_addr = 0x100000;
+    }
+
+    for (i = 0; i < 16; i++)
+    {
+        igd_mmio_write(pt_dev, fence_addr + (i << 4), 0, 4);
+        igd_mmio_write(pt_dev, fence_addr + (i << 4) + 4, 0, 4);
+    }
+}
+
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -98,6 +215,16 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
  */
 void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
 {
+    /*
+     * Reset the fence register on the first remap
+     * of Bar0 for a Intel GPU
+     */
+    if (real_device->pci_dev->device_class == 0x0300 &&
+            real_device->pci_dev->device_id == PCI_VENDOR_ID_INTEL &&
+            bar == 0 && first_map && map == DPCI_ADD_MAPPING)
+    {
+        igd_reset_fences(real_device);
+    }
 }
 
 /*
@@ -137,6 +264,12 @@ int register_vga_regions(struct pt_dev *real_device)
         PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
     }
 
+    if (vendor_id == PCI_VENDOR_ID_INTEL)
+    {
+        if (pt_pci_host_map_bar(real_device, 0) != 0)
+            PT_LOG("Can't map Intel Bar 0\n");
+    }
+
     if ( ret != 0 )
         PT_LOG("VGA region mapping failed\n");
 

--------------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 Tue Jan 31 18:40:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsIcd-0004kh-RA; Tue, 31 Jan 2012 18:40:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RsIcb-0004kA-Ci
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:40:02 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328035194!12529671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4856 invoked from network); 31 Jan 2012 18:39:55 -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;
	31 Jan 2012 18:39:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10400627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 18:39:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 18:39:55 +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 1RsIcU-0000nJ-Gv;
	Tue, 31 Jan 2012 18:39:54 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RsIcI-00071V-PH;
	Tue, 31 Jan 2012 18:39:42 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 18:39:39 +0000
Message-ID: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
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>
Subject: [Xen-devel] [PATCH 1/2] qemu-xen: Pass through, utility functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


Add a function to map a specific bar into a pt_dev.

Add a function that gets called everytime the bar of a pass
through device gets remap.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |   34 ++++++++++++++++++++++++++++++++++
 hw/pass-through.h |    3 +++
 hw/pt-graphics.c  |    7 +++++++
 3 files changed, 44 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Pass-through-utility-functions.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Pass-through-utility-functions.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..1bdb223 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -93,6 +93,7 @@
 #include <unistd.h>
 #include <sys/ioctl.h>
 #include <assert.h>
+#include <sys/mman.h>
 
 extern int gfx_passthru;
 int igd_passthru = 0;
@@ -1155,6 +1156,9 @@ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,
     if ( e_size == 0 )
         return;
 
+    if (assigned_device->pci_dev->device_class == 0x0300)
+        pt_graphic_bar_remap(assigned_device, i, first_map, DPCI_ADD_MAPPING);
+
     if ( !first_map && old_ebase != -1 )
     {
         if ( has_msix_mapping(assigned_device, i) )
@@ -1969,6 +1973,9 @@ static void pt_unregister_regions(struct pt_dev *assigned_device)
         if ( type == PCI_ADDRESS_SPACE_MEM ||
              type == PCI_ADDRESS_SPACE_MEM_PREFETCH )
         {
+            if (assigned_device->pci_dev->device_class == 0x0300)
+                pt_graphic_bar_remap(assigned_device, i, 0, DPCI_REMOVE_MAPPING);
+
             ret = xc_domain_memory_mapping(xc_handle, domid,
                     assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
                     assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
@@ -2101,6 +2108,33 @@ int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len)
     return ret;
 }
 
+int pt_pci_host_map_bar(struct pt_dev *pt_dev, int bar)
+{
+    int fd;
+    struct stat s;
+    uint8_t *map;
+
+    char filename[1024];
+
+    snprintf(filename, 1024, "/sys/bus/pci/devices/0000:%02x:%02x.%01x/resource%d",
+            pt_dev->pci_dev->bus,
+            pt_dev->pci_dev->dev,
+            pt_dev->pci_dev->func,
+            bar);
+    fd = open(filename, O_RDWR | O_SYNC);
+    if (fd < 0)
+        return fd;
+    fstat(fd, &s);
+
+    map = mmap(0, s.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+    if (map != MAP_FAILED)
+    {
+        pt_dev->bases[bar].map = map;
+        return 0;
+    }
+    return errno;
+}
+
 /* parse BAR */
 static int pt_bar_reg_parse(
         struct pt_dev *ptdev, struct pt_reg_info_tbl *reg)
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..26e6ff1 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -170,6 +170,7 @@ struct pt_region {
         uint64_t pio_base;
         uint64_t u;
     } access;
+    uint8_t *map;
 };
 
 struct pt_msi_info {
@@ -414,6 +415,7 @@ uint8_t pci_intx(struct pt_dev *ptdev);
 struct pci_dev *pt_pci_get_dev(int bus, int dev, int func);
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len);
 int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len);
+int pt_pci_host_map_bar(struct pt_dev *pt_dev, int bar);
 void intel_pch_init(PCIBus *bus);
 int register_vga_regions(struct pt_dev *real_device);
 int unregister_vga_regions(struct pt_dev *real_device);
@@ -422,6 +424,7 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..5d5e5da 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -94,6 +94,13 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 }
 
 /*
+ * Callback whenever a bar get remapped
+ */
+void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
+{
+}
+
+/*
  * register VGA resources for the domain with assigned gfx
  */
 int register_vga_regions(struct pt_dev *real_device)

--------------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 Tue Jan 31 18:40:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsIcd-0004kh-RA; Tue, 31 Jan 2012 18:40:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RsIcb-0004kA-Ci
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:40:02 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328035194!12529671!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4856 invoked from network); 31 Jan 2012 18:39:55 -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;
	31 Jan 2012 18:39:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10400627"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 18:39:54 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 18:39:55 +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 1RsIcU-0000nJ-Gv;
	Tue, 31 Jan 2012 18:39:54 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RsIcI-00071V-PH;
	Tue, 31 Jan 2012 18:39:42 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 18:39:39 +0000
Message-ID: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
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>
Subject: [Xen-devel] [PATCH 1/2] qemu-xen: Pass through, utility functions
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
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


Add a function to map a specific bar into a pt_dev.

Add a function that gets called everytime the bar of a pass
through device gets remap.

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pass-through.c |   34 ++++++++++++++++++++++++++++++++++
 hw/pass-through.h |    3 +++
 hw/pt-graphics.c  |    7 +++++++
 3 files changed, 44 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch;
	name="0001-qemu-xen-Pass-through-utility-functions.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0001-qemu-xen-Pass-through-utility-functions.patch"

diff --git a/hw/pass-through.c b/hw/pass-through.c
index dbe8804..1bdb223 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -93,6 +93,7 @@
 #include <unistd.h>
 #include <sys/ioctl.h>
 #include <assert.h>
+#include <sys/mman.h>
 
 extern int gfx_passthru;
 int igd_passthru = 0;
@@ -1155,6 +1156,9 @@ static void pt_iomem_map(PCIDevice *d, int i, uint32_t e_phys, uint32_t e_size,
     if ( e_size == 0 )
         return;
 
+    if (assigned_device->pci_dev->device_class == 0x0300)
+        pt_graphic_bar_remap(assigned_device, i, first_map, DPCI_ADD_MAPPING);
+
     if ( !first_map && old_ebase != -1 )
     {
         if ( has_msix_mapping(assigned_device, i) )
@@ -1969,6 +1973,9 @@ static void pt_unregister_regions(struct pt_dev *assigned_device)
         if ( type == PCI_ADDRESS_SPACE_MEM ||
              type == PCI_ADDRESS_SPACE_MEM_PREFETCH )
         {
+            if (assigned_device->pci_dev->device_class == 0x0300)
+                pt_graphic_bar_remap(assigned_device, i, 0, DPCI_REMOVE_MAPPING);
+
             ret = xc_domain_memory_mapping(xc_handle, domid,
                     assigned_device->bases[i].e_physbase >> XC_PAGE_SHIFT,
                     assigned_device->bases[i].access.maddr >> XC_PAGE_SHIFT,
@@ -2101,6 +2108,33 @@ int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len)
     return ret;
 }
 
+int pt_pci_host_map_bar(struct pt_dev *pt_dev, int bar)
+{
+    int fd;
+    struct stat s;
+    uint8_t *map;
+
+    char filename[1024];
+
+    snprintf(filename, 1024, "/sys/bus/pci/devices/0000:%02x:%02x.%01x/resource%d",
+            pt_dev->pci_dev->bus,
+            pt_dev->pci_dev->dev,
+            pt_dev->pci_dev->func,
+            bar);
+    fd = open(filename, O_RDWR | O_SYNC);
+    if (fd < 0)
+        return fd;
+    fstat(fd, &s);
+
+    map = mmap(0, s.st_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
+    if (map != MAP_FAILED)
+    {
+        pt_dev->bases[bar].map = map;
+        return 0;
+    }
+    return errno;
+}
+
 /* parse BAR */
 static int pt_bar_reg_parse(
         struct pt_dev *ptdev, struct pt_reg_info_tbl *reg)
diff --git a/hw/pass-through.h b/hw/pass-through.h
index 884139c..26e6ff1 100644
--- a/hw/pass-through.h
+++ b/hw/pass-through.h
@@ -170,6 +170,7 @@ struct pt_region {
         uint64_t pio_base;
         uint64_t u;
     } access;
+    uint8_t *map;
 };
 
 struct pt_msi_info {
@@ -414,6 +415,7 @@ uint8_t pci_intx(struct pt_dev *ptdev);
 struct pci_dev *pt_pci_get_dev(int bus, int dev, int func);
 u32 pt_pci_host_read(struct pci_dev *pci_dev, u32 addr, int len);
 int pt_pci_host_write(struct pci_dev *pci_dev, u32 addr, u32 val, int len);
+int pt_pci_host_map_bar(struct pt_dev *pt_dev, int bar);
 void intel_pch_init(PCIBus *bus);
 int register_vga_regions(struct pt_dev *real_device);
 int unregister_vga_regions(struct pt_dev *real_device);
@@ -422,6 +424,7 @@ PCIBus *intel_pci_bridge_init(PCIBus *bus, int devfn, uint16_t vid,
            uint16_t did, const char *name, uint16_t revision);
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len);
 uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len);
+void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map);
 
 #endif /* __PASSTHROUGH_H__ */
 
diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index fec7390..5d5e5da 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -94,6 +94,13 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
 }
 
 /*
+ * Callback whenever a bar get remapped
+ */
+void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
+{
+}
+
+/*
  * register VGA resources for the domain with assigned gfx
  */
 int register_vga_regions(struct pt_dev *real_device)

--------------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 Tue Jan 31 18:40:27 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18:40:27 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsIcd-0004ka-Ch; Tue, 31 Jan 2012 18:40:03 +0000
Received: from mail182.messagelabs.com ([85.158.139.83])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Jean.Guyader@citrix.com>) id 1RsIcb-0004kC-DH
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:40:02 +0000
X-Env-Sender: Jean.Guyader@citrix.com
X-Msg-Ref: server-9.tower-182.messagelabs.com!1328035194!12529671!2
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4870 invoked from network); 31 Jan 2012 18:39:55 -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;
	31 Jan 2012 18:39:55 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10400628"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 18:39:55 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 18:39:55 +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 1RsIcU-0000nM-M8;
	Tue, 31 Jan 2012 18:39:54 +0000
Received: from jeangu by spongy.cam.xci-test.com with local (Exim 4.69)
	(envelope-from <jean.guyader@eu.citrix.com>)	id 1RsIcI-00071X-TR;
	Tue, 31 Jan 2012 18:39:42 +0000
From: Jean Guyader <jean.guyader@eu.citrix.com>
To: <xen-devel@lists.xensource.com>
Date: Tue, 31 Jan 2012 18:39:40 +0000
Message-ID: <1328035180-26966-2-git-send-email-jean.guyader@eu.citrix.com>
X-Mailer: git-send-email 1.7.2.5
In-Reply-To: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
References: <1328035180-26966-1-git-send-email-jean.guyader@eu.citrix.com>
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>
Subject: [Xen-devel] [PATCH 2/2] qemu-xen: Intel GPU passthrough
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--------------true
Content-Type: text/plain; charset="UTF-8"; format=fixed
Content-Transfer-Encoding: 8bit


Reset Intel GPU fences when the domain starts (first mapping
of Bar0).

Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com>
---
 hw/pt-graphics.c |  133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 133 insertions(+), 0 deletions(-)


--------------true
Content-Type: text/x-patch; name="0002-qemu-xen-Intel-GPU-passthrough.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
	filename="0002-qemu-xen-Intel-GPU-passthrough.patch"

diff --git a/hw/pt-graphics.c b/hw/pt-graphics.c
index 5d5e5da..7403abe 100644
--- a/hw/pt-graphics.c
+++ b/hw/pt-graphics.c
@@ -13,6 +13,31 @@
 extern int gfx_passthru;
 extern int igd_passthru;
 
+#define IGFX_CANTIGA            0x10
+#define IGFX_IRONLAKE           0x20
+#define IGFX_IBEXPEAK           0x30
+#define IGFX_COUGARPOINT        0x40
+
+struct igfx_chip
+{
+    int chip;
+    uint16_t device_id;
+};
+
+struct igfx_chip igfx_chips[] =
+{
+    {IGFX_IRONLAKE,     0x0042},
+    {IGFX_IRONLAKE,     0x0046},
+    {IGFX_CANTIGA,      0x20e4},
+    {IGFX_CANTIGA,      0x2a42},
+    {IGFX_CANTIGA,      0x2e12},
+    {IGFX_COUGARPOINT,  0x0152},
+    {IGFX_COUGARPOINT,  0x0112},
+    {IGFX_COUGARPOINT,  0x0116},
+    {IGFX_COUGARPOINT,  0x0126},
+    {0, 0}
+};
+
 static int pch_map_irq(PCIDevice *pci_dev, int irq_num)
 {
     PT_LOG("pch_map_irq called\n");
@@ -37,6 +62,98 @@ void intel_pch_init(PCIBus *bus)
                         pch_map_irq, "intel_bridge_1f");
 }
 
+static int igd_get_chip(struct pt_dev *p)
+{
+    int i;
+    int chip = 0;
+    int devid = p->pci_dev->device_id;
+
+    for (i = 0; igfx_chips[i].chip; i++)
+        if (devid == igfx_chips[i].device_id)
+        {
+            chip = igfx_chips[i].chip;
+            break;
+        }
+
+    if (!chip)
+    {
+        if (devid & 0x2000)
+            chip = IGFX_CANTIGA;
+        else if (devid & 0x100)
+            chip =  IGFX_COUGARPOINT;
+        else
+            chip = IGFX_IRONLAKE;
+        PT_LOG("GUESS FOR CHIP 0x%04x as type %x", devid, chip);
+    }
+    return chip;
+}
+
+
+static uint32_t igd_mmio_read(struct pt_dev *p, uint32_t addr, uint8_t size)
+{
+    uint8_t *map = p->bases[0].map;
+    uint32_t ret;
+
+    switch (size)
+    {
+        case 1:
+            ret = *(volatile uint8_t *)(map + addr);
+            break;
+        case 2:
+            ret = *(volatile uint16_t *)(map + addr);
+            break;
+        case 4:
+            ret = *(volatile uint32_t *)(map + addr);
+            break;
+        default:
+            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
+    }
+    return ret;
+}
+
+static void igd_mmio_write(struct pt_dev *p, uint32_t addr, uint32_t val,
+                           uint8_t size)
+{
+    uint8_t *map = p->bases[0].map;
+
+    switch (size)
+    {
+        case 1:
+            *(volatile uint8_t *)(map + addr) = (uint8_t)val;
+            break;
+        case 2:
+            *(volatile uint16_t *)(map + addr) = (uint16_t)val;
+            break;
+        case 4:
+            *(volatile uint32_t *)(map + addr) = (uint32_t)val;
+            break;
+        default:
+            PT_LOG("igd_do_mmio: Unknown size %d\n", size);
+    }
+}
+
+static void igd_reset_fences(struct pt_dev *pt_dev)
+{
+    int i = 0;
+    uint32_t fence_addr;
+
+    switch (igd_get_chip(pt_dev))
+    {
+        case IGFX_CANTIGA:
+        case IGFX_IRONLAKE:
+        case IGFX_IBEXPEAK:
+            fence_addr = 0x3000;
+        case IGFX_COUGARPOINT:
+            fence_addr = 0x100000;
+    }
+
+    for (i = 0; i < 16; i++)
+    {
+        igd_mmio_write(pt_dev, fence_addr + (i << 4), 0, 4);
+        igd_mmio_write(pt_dev, fence_addr + (i << 4) + 4, 0, 4);
+    }
+}
+
 void igd_pci_write(PCIDevice *pci_dev, uint32_t config_addr, uint32_t val, int len)
 {
     struct pci_dev *pci_dev_host_bridge = pt_pci_get_dev(0, 0, 0);
@@ -98,6 +215,16 @@ uint32_t igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
  */
 void pt_graphic_bar_remap(struct pt_dev *real_device, int bar, int first_map, int map)
 {
+    /*
+     * Reset the fence register on the first remap
+     * of Bar0 for a Intel GPU
+     */
+    if (real_device->pci_dev->device_class == 0x0300 &&
+            real_device->pci_dev->device_id == PCI_VENDOR_ID_INTEL &&
+            bar == 0 && first_map && map == DPCI_ADD_MAPPING)
+    {
+        igd_reset_fences(real_device);
+    }
 }
 
 /*
@@ -137,6 +264,12 @@ int register_vga_regions(struct pt_dev *real_device)
         PT_LOG("register_vga: igd_opregion = %x\n", igd_opregion);
     }
 
+    if (vendor_id == PCI_VENDOR_ID_INTEL)
+    {
+        if (pt_pci_host_map_bar(real_device, 0) != 0)
+            PT_LOG("Can't map Intel Bar 0\n");
+    }
+
     if ( ret != 0 )
         PT_LOG("VGA region mapping failed\n");
 

--------------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 Tue Jan 31 18:57:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18: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 1RsIsl-0005OY-GR; Tue, 31 Jan 2012 18:56:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsIsk-0005OR-Mk
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:56:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328036150!52349734!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31136 invoked from network); 31 Jan 2012 18:55:50 -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;
	31 Jan 2012 18:55:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10400802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 18:56:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 18:56:38 +0000
Date: Tue, 31 Jan 2012 18:58:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1278865655-1328036317=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1278865655-1328036317=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Tue, 31 Jan 2012, Shriram Rajagopalan wrote:
> Or if you have to receive them in the pagebuf, then have two pieces of the same state,
>  consistent_state, curr_state, such that you do
> 
>  pagebuf_get(curr_state)
>  tailbuf_get(..)..
>  if (no error so far), then
>   copy curr_state to consistent_state.
>   goto copypages;
> 
> finish:
>  ..
>   finish_hvm:
>      apply consistent_state.

I think I am starting to understand: see appended patch if it makes
things better.

---

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..02b523d 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -684,6 +684,11 @@ typedef struct {
     uint64_t vm_generationid_addr;
 } pagebuf_t;
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 static int pagebuf_init(pagebuf_t* buf)
 {
     memset(buf, 0, sizeof(*buf));
@@ -703,7 +708,8 @@ static void pagebuf_free(pagebuf_t* buf)
 }
 
 static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
-                           pagebuf_t* buf, int fd, uint32_t dom)
+                           pagebuf_t* buf, int fd, uint32_t dom,
+                           struct toolstack_data_t *tdata)
 {
     int count, countpages, oldcount, i;
     void* ptmp;
@@ -726,7 +732,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
     case XC_SAVE_ID_ENABLE_VERIFY_MODE:
         DPRINTF("Entering page verify mode\n");
         buf->verify = 1;
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_VCPU_INFO:
         buf->new_ctxt_format = 1;
@@ -737,7 +743,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("Max VCPU ID: %d, vcpumap: %llx\n", buf->max_vcpu_id, buf->vcpumap);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_HVM_IDENT_PT:
         /* Skip padding 4 bytes then read the EPT identity PT location. */
@@ -748,7 +754,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_HVM_VM86_TSS:
         /* Skip padding 4 bytes then read the vm86 TSS location. */
@@ -759,7 +765,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("VM86 TSS location: %llx\n", buf->vm86_tss);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_TMEM:
         DPRINTF("xc_domain_restore start tmem\n");
@@ -767,14 +773,14 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tmem");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_TMEM_EXTRA:
         if ( xc_tmem_restore_extra(xch, dom, fd) ) {
             PERROR("error reading/restoring tmem extra");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_TSC_INFO:
     {
@@ -788,7 +794,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tsc info");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
     }
 
     case XC_SAVE_ID_HVM_CONSOLE_PFN :
@@ -800,12 +806,12 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("console pfn location: %llx\n", buf->console_pfn);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_LAST_CHECKPOINT:
         ctx->last_checkpoint = 1;
         // DPRINTF("last checkpoint indication received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -815,7 +821,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the acpi ioport location");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_HVM_VIRIDIAN:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -825,7 +831,20 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the viridian flag");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
+
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &tdata->len, sizeof(tdata->len));
+            tdata->data = (uint8_t*) realloc(tdata->data, tdata->len);
+            if ( tdata->data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, tdata->data, tdata->len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
+        }
 
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
@@ -835,7 +854,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
          */
         ctx->compressing = 1;
         // DPRINTF("compression flag received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_COMPRESSED_DATA:
 
@@ -870,7 +889,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         DPRINTF("read generation id buffer address");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
@@ -914,7 +933,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
      * following a <XC_SAVE_ID_COMPRESSED_DATA, compressedChunkSize> tuple.
      */
     if (buf->compressing)
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     oldcount = buf->nr_physpages;
     buf->nr_physpages += countpages;
@@ -939,7 +958,8 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
 }
 
 static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
-                       pagebuf_t* buf, int fd, uint32_t dom)
+                       pagebuf_t* buf, int fd, uint32_t dom,
+                       struct toolstack_data_t *tdata)
 {
     int rc;
 
@@ -947,7 +967,7 @@ static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
     buf->compbuf_pos = buf->compbuf_size = 0;
 
     do {
-        rc = pagebuf_get_one(xch, ctx, buf, fd, dom);
+        rc = pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
     } while (rc > 0);
 
     if (rc < 0)
@@ -1262,7 +1282,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1310,6 +1331,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdata2, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1322,6 +1344,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
+    memset(&tdata2, 0, sizeof(tdata2));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1441,7 +1465,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         if ( !ctx->completed ) {
             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
             pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
-            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
+            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom, &tdata) < 0 ) {
                 PERROR("Error when reading batch");
                 goto out;
             }
@@ -1589,7 +1613,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     // DPRINTF("Buffered checkpoint\n");
 
-    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
+    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom, &tdata2) ) {
         PERROR("error when buffering batch, finishing");
         goto finish;
     }
@@ -1602,6 +1626,9 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     }
     tailbuf_free(&tailbuf);
     memcpy(&tailbuf, &tmptail, sizeof(tailbuf));
+    tdatatmp = tdata;
+    tdata = tdata2;
+    tdata2 = tdatatmp;
 
     goto loadpages;
 
@@ -2023,6 +2050,20 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            free(tdata2.data);
+            goto out;
+        }
+    }
+    free(tdata.data);
+    free(tdata2.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..76aa475 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..2c5eec5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..306a10e 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
                             console_evtchn, &console_mfn, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
--8323329-1278865655-1328036317=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1278865655-1328036317=:3196--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 18:57:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 18: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 1RsIsl-0005OY-GR; Tue, 31 Jan 2012 18:56:43 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1RsIsk-0005OR-Mk
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 18:56:43 +0000
X-Env-Sender: Stefano.Stabellini@eu.citrix.com
X-Msg-Ref: server-6.tower-27.messagelabs.com!1328036150!52349734!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31136 invoked from network); 31 Jan 2012 18:55:50 -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;
	31 Jan 2012 18:55:50 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10400802"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 18:56:38 +0000
Received: from kaball.uk.xensource.com (10.80.2.59) by
	LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 18:56:38 +0000
Date: Tue, 31 Jan 2012 18:58:21 +0000
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
X-X-Sender: sstabellini@kaball-desktop
To: Shriram Rajagopalan <rshriram@cs.ubc.ca>
In-Reply-To: <CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1278865655-1328036317=:3196"
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--8323329-1278865655-1328036317=:3196
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT

On Tue, 31 Jan 2012, Shriram Rajagopalan wrote:
> Or if you have to receive them in the pagebuf, then have two pieces of the same state,
>  consistent_state, curr_state, such that you do
> 
>  pagebuf_get(curr_state)
>  tailbuf_get(..)..
>  if (no error so far), then
>   copy curr_state to consistent_state.
>   goto copypages;
> 
> finish:
>  ..
>   finish_hvm:
>      apply consistent_state.

I think I am starting to understand: see appended patch if it makes
things better.

---

diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restore.c
index 3fda6f8..02b523d 100644
--- a/tools/libxc/xc_domain_restore.c
+++ b/tools/libxc/xc_domain_restore.c
@@ -684,6 +684,11 @@ typedef struct {
     uint64_t vm_generationid_addr;
 } pagebuf_t;
 
+struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+
 static int pagebuf_init(pagebuf_t* buf)
 {
     memset(buf, 0, sizeof(*buf));
@@ -703,7 +708,8 @@ static void pagebuf_free(pagebuf_t* buf)
 }
 
 static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
-                           pagebuf_t* buf, int fd, uint32_t dom)
+                           pagebuf_t* buf, int fd, uint32_t dom,
+                           struct toolstack_data_t *tdata)
 {
     int count, countpages, oldcount, i;
     void* ptmp;
@@ -726,7 +732,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
     case XC_SAVE_ID_ENABLE_VERIFY_MODE:
         DPRINTF("Entering page verify mode\n");
         buf->verify = 1;
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_VCPU_INFO:
         buf->new_ctxt_format = 1;
@@ -737,7 +743,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("Max VCPU ID: %d, vcpumap: %llx\n", buf->max_vcpu_id, buf->vcpumap);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_HVM_IDENT_PT:
         /* Skip padding 4 bytes then read the EPT identity PT location. */
@@ -748,7 +754,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("EPT identity map address: %llx\n", buf->identpt);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_HVM_VM86_TSS:
         /* Skip padding 4 bytes then read the vm86 TSS location. */
@@ -759,7 +765,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("VM86 TSS location: %llx\n", buf->vm86_tss);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_TMEM:
         DPRINTF("xc_domain_restore start tmem\n");
@@ -767,14 +773,14 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tmem");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_TMEM_EXTRA:
         if ( xc_tmem_restore_extra(xch, dom, fd) ) {
             PERROR("error reading/restoring tmem extra");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_TSC_INFO:
     {
@@ -788,7 +794,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error reading/restoring tsc info");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
     }
 
     case XC_SAVE_ID_HVM_CONSOLE_PFN :
@@ -800,12 +806,12 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         // DPRINTF("console pfn location: %llx\n", buf->console_pfn);
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_LAST_CHECKPOINT:
         ctx->last_checkpoint = 1;
         // DPRINTF("last checkpoint indication received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_HVM_ACPI_IOPORTS_LOCATION:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -815,7 +821,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the acpi ioport location");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_HVM_VIRIDIAN:
         /* Skip padding 4 bytes then read the acpi ioport location. */
@@ -825,7 +831,20 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             PERROR("error read the viridian flag");
             return -1;
         }
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
+
+    case XC_SAVE_ID_TOOLSTACK:
+        {
+            RDEXACT(fd, &tdata->len, sizeof(tdata->len));
+            tdata->data = (uint8_t*) realloc(tdata->data, tdata->len);
+            if ( tdata->data == NULL )
+            {
+                PERROR("error memory allocation");
+                return -1;
+            }
+            RDEXACT(fd, tdata->data, tdata->len);
+            return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
+        }
 
     case XC_SAVE_ID_ENABLE_COMPRESSION:
         /* We cannot set compression flag directly in pagebuf structure,
@@ -835,7 +854,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
          */
         ctx->compressing = 1;
         // DPRINTF("compression flag received");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     case XC_SAVE_ID_COMPRESSED_DATA:
 
@@ -870,7 +889,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
             return -1;
         }
         DPRINTF("read generation id buffer address");
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     default:
         if ( (count > MAX_BATCH_SIZE) || (count < 0) ) {
@@ -914,7 +933,7 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
      * following a <XC_SAVE_ID_COMPRESSED_DATA, compressedChunkSize> tuple.
      */
     if (buf->compressing)
-        return pagebuf_get_one(xch, ctx, buf, fd, dom);
+        return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
 
     oldcount = buf->nr_physpages;
     buf->nr_physpages += countpages;
@@ -939,7 +958,8 @@ static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
 }
 
 static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
-                       pagebuf_t* buf, int fd, uint32_t dom)
+                       pagebuf_t* buf, int fd, uint32_t dom,
+                       struct toolstack_data_t *tdata)
 {
     int rc;
 
@@ -947,7 +967,7 @@ static int pagebuf_get(xc_interface *xch, struct restore_ctx *ctx,
     buf->compbuf_pos = buf->compbuf_size = 0;
 
     do {
-        rc = pagebuf_get_one(xch, ctx, buf, fd, dom);
+        rc = pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
     } while (rc > 0);
 
     if (rc < 0)
@@ -1262,7 +1282,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-                      unsigned long *vm_generationid_addr)
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks)
 {
     DECLARE_DOMCTL;
     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
@@ -1310,6 +1331,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     pagebuf_t pagebuf;
     tailbuf_t tailbuf, tmptail;
+    struct toolstack_data_t tdata, tdata2, tdatatmp;
     void* vcpup;
     uint64_t console_pfn = 0;
 
@@ -1322,6 +1344,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     pagebuf_init(&pagebuf);
     memset(&tailbuf, 0, sizeof(tailbuf));
     tailbuf.ishvm = hvm;
+    memset(&tdata, 0, sizeof(tdata));
+    memset(&tdata2, 0, sizeof(tdata2));
 
     memset(ctx, 0, sizeof(*ctx));
 
@@ -1441,7 +1465,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
         if ( !ctx->completed ) {
             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
             pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
-            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
+            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom, &tdata) < 0 ) {
                 PERROR("Error when reading batch");
                 goto out;
             }
@@ -1589,7 +1613,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
 
     // DPRINTF("Buffered checkpoint\n");
 
-    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {
+    if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom, &tdata2) ) {
         PERROR("error when buffering batch, finishing");
         goto finish;
     }
@@ -1602,6 +1626,9 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     }
     tailbuf_free(&tailbuf);
     memcpy(&tailbuf, &tmptail, sizeof(tailbuf));
+    tdatatmp = tdata;
+    tdata = tdata2;
+    tdata2 = tdatatmp;
 
     goto loadpages;
 
@@ -2023,6 +2050,20 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
     goto out;
 
   finish_hvm:
+    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
+    {
+        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
+                    callbacks->data) < 0 )
+        {
+            PERROR("error calling toolstack_restore");
+            free(tdata.data);
+            free(tdata2.data);
+            goto out;
+        }
+    }
+    free(tdata.data);
+    free(tdata2.data);
+
     /* Dump the QEMU state to a state file for QEMU to load */
     if ( dump_qemu(xch, dom, &tailbuf.u.hvm) ) {
         PERROR("Error dumping QEMU state to file");
diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
index f473dd7..318c433 100644
--- a/tools/libxc/xc_domain_save.c
+++ b/tools/libxc/xc_domain_save.c
@@ -1687,6 +1687,23 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
         }
     }
 
+    if ( callbacks != NULL && callbacks->toolstack_save != NULL )
+    {
+        int id = XC_SAVE_ID_TOOLSTACK;
+        uint8_t *buf;
+        uint32_t len;
+
+        if ( callbacks->toolstack_save(dom, &buf, &len, callbacks->data) < 0 )
+        {
+            PERROR("Error calling toolstack_save");
+            goto out;
+        }
+        wrexact(io_fd, &id, sizeof(id));
+        wrexact(io_fd, &len, sizeof(len));
+        wrexact(io_fd, buf, len);
+        free(buf);
+    }
+
     if ( !callbacks->checkpoint )
     {
         /*
diff --git a/tools/libxc/xenguest.h b/tools/libxc/xenguest.h
index 6026370..76aa475 100644
--- a/tools/libxc/xenguest.h
+++ b/tools/libxc/xenguest.h
@@ -44,6 +44,14 @@ struct save_callbacks {
     /* Enable qemu-dm logging dirty pages to xen */
     int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /* HVM only */
 
+    /* Save toolstack specific data
+     * @param buf the buffer with the data to be saved
+     * @param len the length of the buffer
+     * The callee allocates the buffer, the caller frees it (buffer must
+     * be free'able).
+     */
+    int (*toolstack_save)(uint32_t domid, uint8_t **buf, uint32_t *len, void *data);
+
     /* to be provided as the last argument to each callback function */
     void* data;
 };
@@ -62,6 +70,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
                    unsigned long vm_generationid_addr);
 
 
+/* callbacks provided by xc_domain_restore */
+struct restore_callbacks {
+    /* callback to restore toolstack specific data */
+    int (*toolstack_restore)(uint32_t domid, uint8_t *buf,
+            uint32_t size, void* data);
+
+    /* to be provided as the last argument to each callback function */
+    void* data;
+};
+
 /**
  * This function will restore a saved domain.
  *
@@ -75,6 +93,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter
  * @parm superpages non-zero to allocate guest memory with superpages
  * @parm no_incr_generationid non-zero if generation id is NOT to be incremented
  * @parm vm_generationid_addr returned with the address of the generation id buffer
+ * @parm callbacks non-NULL to receive a callback to restore toolstack
+ *       specific data
  * @return 0 on success, -1 on failure
  */
 int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
@@ -82,7 +102,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
                       unsigned int console_evtchn, unsigned long *console_mfn,
                       unsigned int hvm, unsigned int pae, int superpages,
                       int no_incr_generationid,
-		      unsigned long *vm_generationid_addr);
+                      unsigned long *vm_generationid_addr,
+                      struct restore_callbacks *callbacks);
 /**
  * xc_domain_restore writes a file to disk that contains the device
  * model saved state.
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 6286b68..46fdeaa 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -254,6 +254,7 @@
 #define XC_SAVE_ID_COMPRESSED_DATA    -12 /* Marker to indicate arrival of compressed data */
 #define XC_SAVE_ID_ENABLE_COMPRESSION -13 /* Marker to enable compression logic at receiver side */
 #define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14
+#define XC_SAVE_ID_TOOLSTACK          -15 /* Optional toolstack specific info */
 
 /*
 ** We process save/restore/migrate in batches of pages; the below
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 91643a2..2c5eec5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -379,7 +379,7 @@ int libxl__domain_restore_common(libxl__gc *gc, uint32_t domid,
                            state->store_port, &state->store_mfn,
                            state->console_port, &state->console_mfn,
                            hvm, pae, superpages, no_incr_generationid,
-                           &state->vm_generationid_addr);
+                           &state->vm_generationid_addr, NULL);
     if ( rc ) {
         LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "restoring domain");
         return ERROR_FAIL;
diff --git a/tools/xcutils/xc_restore.c b/tools/xcutils/xc_restore.c
index 63d53a8..306a10e 100644
--- a/tools/xcutils/xc_restore.c
+++ b/tools/xcutils/xc_restore.c
@@ -47,7 +47,7 @@ main(int argc, char **argv)
 
     ret = xc_domain_restore(xch, io_fd, domid, store_evtchn, &store_mfn,
                             console_evtchn, &console_mfn, hvm, pae, superpages,
-                            0, NULL);
+                            0, NULL, NULL);
 
     if ( ret == 0 )
     {
--8323329-1278865655-1328036317=:3196
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--8323329-1278865655-1328036317=:3196--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 19:05:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 19:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsJ1N-0005fc-Un; Tue, 31 Jan 2012 19:05:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RsJ1M-0005fC-4v; Tue, 31 Jan 2012 19:05:36 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328036729!8675926!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12681 invoked from network); 31 Jan 2012 19:05:29 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 19:05:29 -0000
Received: by wgbdr13 with SMTP id dr13so312224wgb.24
	for <multiple recipients>; Tue, 31 Jan 2012 11:05:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=Vz0sMK7MnR7ZZxDiKPBOxOk7rIDdNakxQwn7TYQfWD0=;
	b=bdixcmv2CAZYlfzVivs13szZdyDj8fAisRDybpA35I1UjtqhOwgrjZW/tBuDpLDdM/
	543UiWhztzofzI6A+wz36SiNDStFnkDf6YIHezcfkMimQfp8xcQ0K6DAEN3eYk5JOgYm
	q+ta3D9F02IkSn87yGHjBwN9poo4cjU8EGB3U=
Received: by 10.180.77.228 with SMTP id v4mr13618600wiw.2.1328036260389;
	Tue, 31 Jan 2012 10:57:40 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id x7sm14228612wif.10.2012.01.31.10.57.38
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 10:57:39 -0800 (PST)
Message-ID: <4F28398A.4000402@xen.org>
Date: Tue, 31 Jan 2012 18:57:14 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>
Subject: [Xen-devel] XenSummit 2012: Dates, Location, PMC & CFP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dear Community Members,

I am pleased to announce the date and location of the 2012 XenSummit in 
North America. It will be held from August 27-28, 2012 in San Diego, CA, 
USA. The event will be held immediately before LinuxCon North America 
2012, at the same venue. You will find more information on the XenSummit 
events page (see http://xen.org/community/xensummit.html).

Call for Participation

The CFP for XenSummit is now also open. All submissions must be received 
before midnight May 1, 2012 PDT. Submit your proposal by going to 
http://xen.org/polls/xensummit_na_2012.html

PMC

I will also again be looking for volunteers to join the Program 
Management Committee for XenSummit. As a PMC member you have the 
following responsibilities
- Review submitted topics for the event (we will typically have 3 one 
hour calls and a bit of homework is needed)
- Assist in compiling the final agenda for the event
- If attending, introduce speakers - you don't have to

Please get in touch with me, if you want to join the PMC. We are aiming 
to have the first PMC meeting shortly after May 1st.

Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 19:05:58 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 19:05:58 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsJ1N-0005fc-Un; Tue, 31 Jan 2012 19:05:37 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <lars.kurth.xen@gmail.com>)
	id 1RsJ1M-0005fC-4v; Tue, 31 Jan 2012 19:05:36 +0000
X-Env-Sender: lars.kurth.xen@gmail.com
X-Msg-Ref: server-6.tower-21.messagelabs.com!1328036729!8675926!1
X-Originating-IP: [74.125.82.43]
X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG,
  RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12681 invoked from network); 31 Jan 2012 19:05:29 -0000
Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com)
	(74.125.82.43)
	by server-6.tower-21.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 19:05:29 -0000
Received: by wgbdr13 with SMTP id dr13so312224wgb.24
	for <multiple recipients>; Tue, 31 Jan 2012 11:05:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=sender:message-id:date:from:user-agent:mime-version:to:subject
	:content-type:content-transfer-encoding;
	bh=Vz0sMK7MnR7ZZxDiKPBOxOk7rIDdNakxQwn7TYQfWD0=;
	b=bdixcmv2CAZYlfzVivs13szZdyDj8fAisRDybpA35I1UjtqhOwgrjZW/tBuDpLDdM/
	543UiWhztzofzI6A+wz36SiNDStFnkDf6YIHezcfkMimQfp8xcQ0K6DAEN3eYk5JOgYm
	q+ta3D9F02IkSn87yGHjBwN9poo4cjU8EGB3U=
Received: by 10.180.77.228 with SMTP id v4mr13618600wiw.2.1328036260389;
	Tue, 31 Jan 2012 10:57:40 -0800 (PST)
Received: from [172.16.25.10] (5e0518fc.bb.sky.com. [94.5.24.252])
	by mx.google.com with ESMTPS id x7sm14228612wif.10.2012.01.31.10.57.38
	(version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 10:57:39 -0800 (PST)
Message-ID: <4F28398A.4000402@xen.org>
Date: Tue, 31 Jan 2012 18:57:14 +0000
From: Lars Kurth <lars.kurth@xen.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, 
	"xen-users@lists.xensource.com" <xen-users@lists.xensource.com>,
	"xen-api@lists.xensource.com" <xen-api@lists.xensource.com>, 
	"xen-arm@lists.xensource.com" <xen-arm@lists.xensource.com>
Subject: [Xen-devel] XenSummit 2012: Dates, Location, PMC & CFP
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Dear Community Members,

I am pleased to announce the date and location of the 2012 XenSummit in 
North America. It will be held from August 27-28, 2012 in San Diego, CA, 
USA. The event will be held immediately before LinuxCon North America 
2012, at the same venue. You will find more information on the XenSummit 
events page (see http://xen.org/community/xensummit.html).

Call for Participation

The CFP for XenSummit is now also open. All submissions must be received 
before midnight May 1, 2012 PDT. Submit your proposal by going to 
http://xen.org/polls/xensummit_na_2012.html

PMC

I will also again be looking for volunteers to join the Program 
Management Committee for XenSummit. As a PMC member you have the 
following responsibilities
- Review submitted topics for the event (we will typically have 3 one 
hour calls and a bit of homework is needed)
- Assist in compiling the final agenda for the event
- If attending, introduce speakers - you don't have to

Please get in touch with me, if you want to join the PMC. We are aiming 
to have the first PMC meeting shortly after May 1st.

Best Regards
Lars

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 19:18:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 19: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 1RsJD0-0006DP-Ts; Tue, 31 Jan 2012 19:17:38 +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 1RsJCy-0006DJ-VH
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 19:17:37 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328037450!13160238!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14473 invoked from network); 31 Jan 2012 19:17:30 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	AM1EHSOBE002.bigfish.com) (213.199.154.205)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	31 Jan 2012 19:17:30 -0000
Received: from mail20-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 31 Jan 2012 19:17:30 +0000
Received: from mail20-am1 (localhost [127.0.0.1])	by mail20-am1-R.bigfish.com
	(Postfix) with ESMTP id 35B1B48049D;
	Tue, 31 Jan 2012 19:17:30 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail20-am1 (localhost.localdomain [127.0.0.1]) by mail20-am1
	(MessageSwitch) id 1328037447108272_8224;
	Tue, 31 Jan 2012 19:17:27 +0000 (UTC)
Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.249])	by
	mail20-am1.bigfish.com (Postfix) with ESMTP id 1620A3C0045;
	Tue, 31 Jan 2012 19:17:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server id
	14.1.225.23; Tue, 31 Jan 2012 19:17:26 +0000
X-WSS-ID: 0LYOG8Y-02-1BC-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 28D52C8215;	Tue, 31 Jan 2012 13:17:22 -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, 31 Jan 2012 13:17:33 -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, 31 Jan 2012 13:17:23 -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, 31 Jan 2012
	14:17:22 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2BD3B49C58B; Tue, 31 Jan 2012
	19:17:21 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 1CDFD2D202B; Tue,
	31 Jan 2012 20:17:21 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: a8abf3fae8ae919141b4ebabf76cc3855915b414
Message-ID: <a8abf3fae8ae919141b4.1328037416@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Tue, 31 Jan 2012 20:16:56 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v3] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1328036109 -3600
# Node ID a8abf3fae8ae919141b4ebabf76cc3855915b414
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r e2722b24dc09 -r a8abf3fae8ae tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_cpuid_x86.c	Tue Jan 31 19:55:09 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
diff -r e2722b24dc09 -r a8abf3fae8ae xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Tue Jan 31 19:55:09 2012 +0100
@@ -83,6 +83,9 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
 
 static bool_t amd_erratum383_found __read_mostly;
 
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -902,6 +905,61 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
+    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |= 1;
+}
+
+void svm_host_osvw_reset()
+{
+    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status = 0;
+}
+
+void svm_host_osvw_init()
+{
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+         
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len = status = 0;
+
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+    }
+    else
+        osvw_length = osvw_status = 0;
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +988,9 @@ static int svm_vcpu_initialise(struct vc
     }
 
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
 
@@ -1044,6 +1105,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.hvm_svm.osvw.length;
+        else
+            *val = v->arch.hvm_svm.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1176,9 @@ static int svm_cpu_up(void)
     }
 #endif
 
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
 
@@ -1104,6 +1189,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
 
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1475,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1606,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r e2722b24dc09 -r a8abf3fae8ae xen/arch/x86/microcode.c
--- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode.c	Tue Jan 31 19:55:09 2012 +0100
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error = 0;
     info->cpu = cpumask_first(&cpu_online_map);
 
+    if ( microcode_ops->start_update )
+    {
+        ret = microcode_ops->start_update();
+        if ( ret != 0 )
+        {
+            xfree(info);
+            return ret;
+        }
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
 }
 
diff -r e2722b24dc09 -r a8abf3fae8ae xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode_amd.c	Tue Jan 31 19:55:09 2012 +0100
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
 
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -287,7 +288,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_amd = xmalloc(struct microcode_amd);
@@ -295,7 +297,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error = -ENOMEM;
+        goto out;
     }
 
     error = install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +306,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_old = uci->mc.mc_amd;
@@ -337,13 +341,19 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error == 1)
+    if ( error == 1 )
     {
         xfree(mc_old);
-        return 0;
+        error = 0;
+    } 
+    else 
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd = mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd = mc_old;
+
+  out:
+    svm_host_osvw_init();
 
     return error;
 }
@@ -395,11 +405,19 @@ err1:
     return -ENOMEM;
 }
 
+static int start_update(void) 
+{
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops = {
     .microcode_resume_match           = microcode_resume_match,
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
+    .start_update                     = start_update,
 };
 
 static __init int microcode_init_amd(void)
diff -r e2722b24dc09 -r a8abf3fae8ae xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Tue Jan 31 19:55:09 2012 +0100
@@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
 
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        /* 
+         * alloc_vpcu() will access data which is modified during
+         * microcode update
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret = hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret = microcode_update(data, op->u.microcode.length);
+        spin_unlock(&vcpu_alloc_lock);
     }
     break;
 
diff -r e2722b24dc09 -r a8abf3fae8ae xen/common/domctl.c
--- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/common/domctl.c	Tue Jan 31 19:55:09 2012 +0100
@@ -29,6 +29,7 @@
 #include <xsm/xsm.h>
 
 static DEFINE_SPINLOCK(domctl_lock);
+DEFINE_SPINLOCK(vcpu_alloc_lock);
 
 int cpumask_to_xenctl_cpumap(
     struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
@@ -502,6 +503,20 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
+        /* 
+         * Certain operations (e.g. CPU microcode updates) modify data which is
+         * used during VCPU allocation/initialization
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =  hypercall_create_continuation(
+                    __HYPERVISOR_domctl, "h", u_domctl);
+                domain_unpause(d);
+                rcu_unlock_domain(d);
+                break;
+            }
+
         /* We cannot reduce maximum VCPUs. */
         ret = -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
@@ -551,6 +566,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret = 0;
 
     maxvcpu_out:
+        spin_unlock(&vcpu_alloc_lock);
         domain_unpause(d);
         rcu_unlock_domain(d);
     }
diff -r e2722b24dc09 -r a8abf3fae8ae xen/include/asm-x86/hvm/svm/svm.h
--- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/svm.h	Tue Jan 31 19:55:09 2012 +0100
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
diff -r e2722b24dc09 -r a8abf3fae8ae xen/include/asm-x86/hvm/svm/vmcb.h
--- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Tue Jan 31 19:55:09 2012 +0100
@@ -516,6 +516,12 @@ struct arch_svm_struct {
     
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
 
 struct vmcb_struct *alloc_vmcb(void);
diff -r e2722b24dc09 -r a8abf3fae8ae xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/microcode.h	Tue Jan 31 19:55:09 2012 +0100
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
 
 struct cpu_signature {
diff -r e2722b24dc09 -r a8abf3fae8ae xen/include/xen/domain.h
--- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/xen/domain.h	Tue Jan 31 19:55:09 2012 +0100
@@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
 
 void arch_vcpu_reset(struct vcpu *v);
 
+extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 19:18:02 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 19: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 1RsJD0-0006DP-Ts; Tue, 31 Jan 2012 19:17:38 +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 1RsJCy-0006DJ-VH
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 19:17:37 +0000
X-Env-Sender: Boris.Ostrovsky@amd.com
X-Msg-Ref: server-6.tower-182.messagelabs.com!1328037450!13160238!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.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 14473 invoked from network); 31 Jan 2012 19:17:30 -0000
Received: from am1ehsobe002.messaging.microsoft.com (HELO
	AM1EHSOBE002.bigfish.com) (213.199.154.205)
	by server-6.tower-182.messagelabs.com with AES128-SHA encrypted SMTP;
	31 Jan 2012 19:17:30 -0000
Received: from mail20-am1-R.bigfish.com (10.3.201.243) by
	AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id
	14.1.225.23; Tue, 31 Jan 2012 19:17:30 +0000
Received: from mail20-am1 (localhost [127.0.0.1])	by mail20-am1-R.bigfish.com
	(Postfix) with ESMTP id 35B1B48049D;
	Tue, 31 Jan 2012 19:17:30 +0000 (UTC)
X-SpamScore: 0
X-BigFish: VPS0(zzzz1202hzz8275bhz2dhc1bhc31hc1ah668h839h944h)
X-Forefront-Antispam-Report: CIP:163.181.249.109; KIP:(null); UIP:(null);
	IPV:NLI; H:ausb3twp02.amd.com; RD:none; EFVD:NLI
Received: from mail20-am1 (localhost.localdomain [127.0.0.1]) by mail20-am1
	(MessageSwitch) id 1328037447108272_8224;
	Tue, 31 Jan 2012 19:17:27 +0000 (UTC)
Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.249])	by
	mail20-am1.bigfish.com (Postfix) with ESMTP id 1620A3C0045;
	Tue, 31 Jan 2012 19:17:27 +0000 (UTC)
Received: from ausb3twp02.amd.com (163.181.249.109) by
	AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server id
	14.1.225.23; Tue, 31 Jan 2012 19:17:26 +0000
X-WSS-ID: 0LYOG8Y-02-1BC-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 28D52C8215;	Tue, 31 Jan 2012 13:17:22 -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, 31 Jan 2012 13:17:33 -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, 31 Jan 2012 13:17:23 -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, 31 Jan 2012
	14:17:22 -0500
Received: from wotan.amd.com (wotan.osrc.amd.com [165.204.15.11])	by
	gwo.osrc.amd.com (Postfix) with ESMTP id 2BD3B49C58B; Tue, 31 Jan 2012
	19:17:21 +0000 (GMT)
Received: by wotan.amd.com (Postfix, from userid 41729)	id 1CDFD2D202B; Tue,
	31 Jan 2012 20:17:21 +0100 (CET)
MIME-Version: 1.0
X-Mercurial-Node: a8abf3fae8ae919141b4ebabf76cc3855915b414
Message-ID: <a8abf3fae8ae919141b4.1328037416@wotan.osrc.amd.com>
User-Agent: Mercurial-patchbomb/1.8.2
Date: Tue, 31 Jan 2012 20:16:56 +0100
From: Boris Ostrovsky <boris.ostrovsky@amd.com>
To: <JBeulich@suse.com>, <keir@xen.org>
X-OriginatorOrg: amd.com
Cc: boris.ostrovsky@amd.com, Christoph.Egger@amd.com,
	xen-devel@lists.xensource.com
Subject: [Xen-devel] [PATCH v3] x86/AMD: Add support for AMD's OSVW feature
	in guests
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

# HG changeset patch
# User Boris Ostrovsky <boris.ostrovsky@amd.com>
# Date 1328036109 -3600
# Node ID a8abf3fae8ae919141b4ebabf76cc3855915b414
# Parent  e2722b24dc0962de37215320b05d1bb7c4c42864
x86/AMD: Add support for AMD's OSVW feature in guests.

In some cases guests should not provide workarounds for errata even when the
physical processor is affected. For example, because of erratum 400 on family
10h processors a Linux guest will read an MSR (resulting in VMEXIT) before
going to idle in order to avoid getting stuck in a non-C0 state. This is not
necessary: HLT and IO instructions are intercepted and therefore there is no
reason for erratum 400 workaround in the guest.

This patch allows us to present a guest with certain errata as fixed,
regardless of the state of actual hardware.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: Christoph Egger <Christoph.Egger@amd.com>

diff -r e2722b24dc09 -r a8abf3fae8ae tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/tools/libxc/xc_cpuid_x86.c	Tue Jan 31 19:55:09 2012 +0100
@@ -108,6 +108,7 @@ static void amd_xc_cpuid_policy(
                     bitmaskof(X86_FEATURE_SSE4A) |
                     bitmaskof(X86_FEATURE_MISALIGNSSE) |
                     bitmaskof(X86_FEATURE_3DNOWPREFETCH) |
+                    bitmaskof(X86_FEATURE_OSVW) |
                     bitmaskof(X86_FEATURE_XOP) |
                     bitmaskof(X86_FEATURE_FMA4) |
                     bitmaskof(X86_FEATURE_TBM) |
diff -r e2722b24dc09 -r a8abf3fae8ae xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/hvm/svm/svm.c	Tue Jan 31 19:55:09 2012 +0100
@@ -83,6 +83,9 @@ static DEFINE_PER_CPU_READ_MOSTLY(void *
 
 static bool_t amd_erratum383_found __read_mostly;
 
+/* OSVW bits */
+static uint64_t osvw_length, osvw_status;
+
 void __update_guest_eip(struct cpu_user_regs *regs, unsigned int inst_len)
 {
     struct vcpu *curr = current;
@@ -902,6 +905,61 @@ static void svm_do_resume(struct vcpu *v
     reset_stack_and_jump(svm_asm_do_resume);
 }
 
+static void svm_guest_osvw_init(struct vcpu *vcpu)
+{
+    if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD )
+        return;
+
+    /*
+     * Guests should see errata 400 and 415 as fixed (assuming that
+     * HLT and IO instructions are intercepted).
+     */
+    vcpu->arch.hvm_svm.osvw.length = (osvw_length >= 3) ? osvw_length : 3;
+    vcpu->arch.hvm_svm.osvw.status = osvw_status & ~(6ULL);
+
+    /*
+     * By increasing VCPU's osvw.length to 3 we are telling the guest that
+     * all osvw.status bits inside that length, including bit 0 (which is
+     * reserved for erratum 298), are valid. However, if host processor's
+     * osvw_len is 0 then osvw_status[0] carries no information. We need to
+     * be conservative here and therefore we tell the guest that erratum 298
+     * is present (because we really don't know).
+     */
+    if ( osvw_length == 0 && boot_cpu_data.x86 == 0x10 )
+        vcpu->arch.hvm_svm.osvw.status |= 1;
+}
+
+void svm_host_osvw_reset()
+{
+    osvw_length = 64; /* One register (MSRC001_0141) worth of errata */
+    osvw_status = 0;
+}
+
+void svm_host_osvw_init()
+{
+    /* 
+     * Get OSVW bits. If bits are not the same on different processors then
+     * choose the worst case (i.e. if erratum is present on one processor and
+     * not on another assume that the erratum is present everywhere).
+     */
+    if ( test_bit(X86_FEATURE_OSVW, &boot_cpu_data.x86_capability) )
+    {
+        uint64_t len, status;
+         
+        if ( rdmsr_safe(MSR_AMD_OSVW_ID_LENGTH, len) ||
+             rdmsr_safe(MSR_AMD_OSVW_STATUS, status) )
+            len = status = 0;
+
+        if (len < osvw_length)
+            osvw_length = len;
+
+        osvw_status |= status;
+        osvw_status &= (1ULL << osvw_length) - 1;
+    }
+    else
+        osvw_length = osvw_status = 0;
+}
+
 static int svm_domain_initialise(struct domain *d)
 {
     return 0;
@@ -930,6 +988,9 @@ static int svm_vcpu_initialise(struct vc
     }
 
     vpmu_initialise(v);
+
+    svm_guest_osvw_init(v);
+
     return 0;
 }
 
@@ -1044,6 +1105,27 @@ static void svm_init_erratum_383(struct 
     }
 }
 
+static int svm_handle_osvw(struct vcpu *v, uint32_t msr, uint64_t *val, bool_t read)
+{
+    uint eax, ebx, ecx, edx;
+     
+    /* Guest OSVW support */
+    hvm_cpuid(0x80000001, &eax, &ebx, &ecx, &edx);
+    if ( !test_bit((X86_FEATURE_OSVW & 31), &ecx) )
+        return -1;
+
+    if ( read )
+    {
+        if (msr == MSR_AMD_OSVW_ID_LENGTH)
+            *val = v->arch.hvm_svm.osvw.length;
+        else
+            *val = v->arch.hvm_svm.osvw.status;
+    } 
+    /* Writes are ignored */
+
+    return 0;
+}
+
 static int svm_cpu_up(void)
 {
     uint64_t msr_content;
@@ -1094,6 +1176,9 @@ static int svm_cpu_up(void)
     }
 #endif
 
+    /* Initialize OSVW bits to be used by guests */
+    svm_host_osvw_init();
+
     return 0;
 }
 
@@ -1104,6 +1189,8 @@ struct hvm_function_table * __init start
     if ( !test_bit(X86_FEATURE_SVM, &boot_cpu_data.x86_capability) )
         return NULL;
 
+    svm_host_osvw_reset();
+
     if ( svm_cpu_up() )
     {
         printk("SVM: failed to initialise.\n");
@@ -1388,6 +1475,13 @@ static int svm_msr_read_intercept(unsign
         vpmu_do_rdmsr(msr, msr_content);
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, msr_content, 1);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_rdmsr(v, msr, msr_content);
         if ( ret < 0 )
@@ -1512,6 +1606,13 @@ static int svm_msr_write_intercept(unsig
          */
         break;
 
+    case MSR_AMD_OSVW_ID_LENGTH:
+    case MSR_AMD_OSVW_STATUS:
+        ret = svm_handle_osvw(v, msr, &msr_content, 0);
+        if ( ret < 0 )
+            goto gpf;
+        break;
+
     default:
         ret = nsvm_wrmsr(v, msr, msr_content);
         if ( ret < 0 )
diff -r e2722b24dc09 -r a8abf3fae8ae xen/arch/x86/microcode.c
--- a/xen/arch/x86/microcode.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode.c	Tue Jan 31 19:55:09 2012 +0100
@@ -218,6 +218,16 @@ int microcode_update(XEN_GUEST_HANDLE(co
     info->error = 0;
     info->cpu = cpumask_first(&cpu_online_map);
 
+    if ( microcode_ops->start_update )
+    {
+        ret = microcode_ops->start_update();
+        if ( ret != 0 )
+        {
+            xfree(info);
+            return ret;
+        }
+    }
+
     return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
 }
 
diff -r e2722b24dc09 -r a8abf3fae8ae xen/arch/x86/microcode_amd.c
--- a/xen/arch/x86/microcode_amd.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/microcode_amd.c	Tue Jan 31 19:55:09 2012 +0100
@@ -25,6 +25,7 @@
 #include <asm/msr.h>
 #include <asm/processor.h>
 #include <asm/microcode.h>
+#include <asm/hvm/svm/svm.h>
 
 struct equiv_cpu_entry {
     uint32_t installed_cpu;
@@ -287,7 +288,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! Wrong "
                "microcode patch file magic\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_amd = xmalloc(struct microcode_amd);
@@ -295,7 +297,8 @@ static int cpu_request_microcode(int cpu
     {
         printk(KERN_ERR "microcode: error! "
                "Can not allocate memory for microcode patch\n");
-        return -ENOMEM;
+        error = -ENOMEM;
+        goto out;
     }
 
     error = install_equiv_cpu_table(mc_amd, buf, &offset);
@@ -303,7 +306,8 @@ static int cpu_request_microcode(int cpu
     {
         xfree(mc_amd);
         printk(KERN_ERR "microcode: installing equivalent cpu table failed\n");
-        return -EINVAL;
+        error = -EINVAL;
+        goto out;
     }
 
     mc_old = uci->mc.mc_amd;
@@ -337,13 +341,19 @@ static int cpu_request_microcode(int cpu
     /* On success keep the microcode patch for
      * re-apply on resume.
      */
-    if (error == 1)
+    if ( error == 1 )
     {
         xfree(mc_old);
-        return 0;
+        error = 0;
+    } 
+    else 
+    {
+        xfree(mc_amd);
+        uci->mc.mc_amd = mc_old;
     }
-    xfree(mc_amd);
-    uci->mc.mc_amd = mc_old;
+
+  out:
+    svm_host_osvw_init();
 
     return error;
 }
@@ -395,11 +405,19 @@ err1:
     return -ENOMEM;
 }
 
+static int start_update(void) 
+{
+    svm_host_osvw_reset();
+
+    return 0;
+}
+
 static const struct microcode_ops microcode_amd_ops = {
     .microcode_resume_match           = microcode_resume_match,
     .cpu_request_microcode            = cpu_request_microcode,
     .collect_cpu_info                 = collect_cpu_info,
     .apply_microcode                  = apply_microcode,
+    .start_update                     = start_update,
 };
 
 static __init int microcode_init_amd(void)
diff -r e2722b24dc09 -r a8abf3fae8ae xen/arch/x86/platform_hypercall.c
--- a/xen/arch/x86/platform_hypercall.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/arch/x86/platform_hypercall.c	Tue Jan 31 19:55:09 2012 +0100
@@ -166,7 +166,21 @@ ret_t do_platform_op(XEN_GUEST_HANDLE(xe
             break;
 
         guest_from_compat_handle(data, op->u.microcode.data);
+
+        /* 
+         * alloc_vpcu() will access data which is modified during
+         * microcode update
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret = hypercall_create_continuation(
+                    __HYPERVISOR_platform_op, "h", u_xenpf_op);
+                goto out;
+            }
+
         ret = microcode_update(data, op->u.microcode.length);
+        spin_unlock(&vcpu_alloc_lock);
     }
     break;
 
diff -r e2722b24dc09 -r a8abf3fae8ae xen/common/domctl.c
--- a/xen/common/domctl.c	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/common/domctl.c	Tue Jan 31 19:55:09 2012 +0100
@@ -29,6 +29,7 @@
 #include <xsm/xsm.h>
 
 static DEFINE_SPINLOCK(domctl_lock);
+DEFINE_SPINLOCK(vcpu_alloc_lock);
 
 int cpumask_to_xenctl_cpumap(
     struct xenctl_cpumap *xenctl_cpumap, const cpumask_t *cpumask)
@@ -502,6 +503,20 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         /* Needed, for example, to ensure writable p.t. state is synced. */
         domain_pause(d);
 
+        /* 
+         * Certain operations (e.g. CPU microcode updates) modify data which is
+         * used during VCPU allocation/initialization
+         */
+        while ( !spin_trylock(&vcpu_alloc_lock) )
+            if ( hypercall_preempt_check() )
+            {
+                ret =  hypercall_create_continuation(
+                    __HYPERVISOR_domctl, "h", u_domctl);
+                domain_unpause(d);
+                rcu_unlock_domain(d);
+                break;
+            }
+
         /* We cannot reduce maximum VCPUs. */
         ret = -EINVAL;
         if ( (max < d->max_vcpus) && (d->vcpu[max] != NULL) )
@@ -551,6 +566,7 @@ long do_domctl(XEN_GUEST_HANDLE(xen_domc
         ret = 0;
 
     maxvcpu_out:
+        spin_unlock(&vcpu_alloc_lock);
         domain_unpause(d);
         rcu_unlock_domain(d);
     }
diff -r e2722b24dc09 -r a8abf3fae8ae xen/include/asm-x86/hvm/svm/svm.h
--- a/xen/include/asm-x86/hvm/svm/svm.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/svm.h	Tue Jan 31 19:55:09 2012 +0100
@@ -98,4 +98,7 @@ extern u32 svm_feature_flags;
                                   ~TSC_RATIO_RSVD_BITS )
 #define vcpu_tsc_ratio(v)       TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
+extern void svm_host_osvw_reset(void);
+extern void svm_host_osvw_init(void);
+
 #endif /* __ASM_X86_HVM_SVM_H__ */
diff -r e2722b24dc09 -r a8abf3fae8ae xen/include/asm-x86/hvm/svm/vmcb.h
--- a/xen/include/asm-x86/hvm/svm/vmcb.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h	Tue Jan 31 19:55:09 2012 +0100
@@ -516,6 +516,12 @@ struct arch_svm_struct {
     
     /* AMD lightweight profiling MSR */
     uint64_t guest_lwp_cfg;
+
+    /* OSVW MSRs */
+    struct {
+        u64 length;
+        u64 status;
+    } osvw;
 };
 
 struct vmcb_struct *alloc_vmcb(void);
diff -r e2722b24dc09 -r a8abf3fae8ae xen/include/asm-x86/microcode.h
--- a/xen/include/asm-x86/microcode.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/asm-x86/microcode.h	Tue Jan 31 19:55:09 2012 +0100
@@ -11,6 +11,7 @@ struct microcode_ops {
     int (*cpu_request_microcode)(int cpu, const void *buf, size_t size);
     int (*collect_cpu_info)(int cpu, struct cpu_signature *csig);
     int (*apply_microcode)(int cpu);
+    int (*start_update)(void);
 };
 
 struct cpu_signature {
diff -r e2722b24dc09 -r a8abf3fae8ae xen/include/xen/domain.h
--- a/xen/include/xen/domain.h	Thu Jan 26 17:43:31 2012 +0000
+++ b/xen/include/xen/domain.h	Tue Jan 31 19:55:09 2012 +0100
@@ -69,6 +69,7 @@ void arch_dump_domain_info(struct domain
 
 void arch_vcpu_reset(struct vcpu *v);
 
+extern spinlock_t vcpu_alloc_lock;
 bool_t domctl_lock_acquire(void);
 void domctl_lock_release(void);
 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 19:34:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 19: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 1RsJT1-0006ij-R6; Tue, 31 Jan 2012 19:34: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 1RsJT0-0006iD-QN
	for xen-devel@lists.xen.org; Tue, 31 Jan 2012 19:34:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328038444!13135354!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29538 invoked from network); 31 Jan 2012 19:34:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 19:34:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10401226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 19:34:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 19:34: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
	1RsJSt-00016u-G6	for xen-devel@lists.xen.org;
	Tue, 31 Jan 2012 19:34:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsJSt-0005nc-FR	for
	xen-devel@lists.xen.org; Tue, 31 Jan 2012 19:34:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20264.16939.464835.330617@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 19:34:03 +0000
To: xen-devel@lists.xen.org
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] [RFC] libxl: fork/wait handling API proposal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Here is a first cut of a new API proposal.  There is no implementation
as yet.

libxl will also need to use pthread_atfork to ensure proper tidying up
of things on forks, but this is hidden inside the library and does not
need to be in the API.  I have some WIP code for this but it's not
ready for the light of day.

Ian.

diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index f889115..17ffd81 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -369,6 +369,125 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     warnings to stderr if no callback is provided).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     The application must install a SIGCHLD handler and reap (at
+ *     least) all of libxl's children and pass their exit status
+ *     to libxl by calling libxl_childproc_exited.
+ *
+ *     An application which does this must call
+ *     libxl_childproc_setmode.
+ * 
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, must not:
+ *   - have any child processes running while it uses any libxl
+ *     operation which might create or use child processes (see
+ *     above);
+ *   - install a SIGCHLD handler; or
+ *   - reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but
+     * NOT from within a signal handler. */
+    libxl_sigchld_owner_mainloop,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_app.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_NOT_READY if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*childproc_exited_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libx, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/* May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_NOT_READY.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_exited(libxl_ctx *ctx, pid_t, int status);
+
+
 #endif
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 19:34:33 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 19: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 1RsJT1-0006ij-R6; Tue, 31 Jan 2012 19:34: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 1RsJT0-0006iD-QN
	for xen-devel@lists.xen.org; Tue, 31 Jan 2012 19:34:11 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-11.tower-182.messagelabs.com!1328038444!13135354!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29538 invoked from network); 31 Jan 2012 19:34:04 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-11.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 19:34:04 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10401226"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 19:34:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 19:34: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
	1RsJSt-00016u-G6	for xen-devel@lists.xen.org;
	Tue, 31 Jan 2012 19:34:03 +0000
Received: from iwj by mariner.uk.xensource.com with local (Exim 4.72)
	(envelope-from <Ian.Jackson@eu.citrix.com>)	id 1RsJSt-0005nc-FR	for
	xen-devel@lists.xen.org; Tue, 31 Jan 2012 19:34:03 +0000
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
MIME-Version: 1.0
Message-ID: <20264.16939.464835.330617@mariner.uk.xensource.com>
Date: Tue, 31 Jan 2012 19:34:03 +0000
To: xen-devel@lists.xen.org
X-Mailer: VM 8.1.0 under 23.2.1 (i486-pc-linux-gnu)
Subject: [Xen-devel] [RFC] libxl: fork/wait handling API proposal
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Here is a first cut of a new API proposal.  There is no implementation
as yet.

libxl will also need to use pthread_atfork to ensure proper tidying up
of things on forks, but this is hidden inside the library and does not
need to be in the API.  I have some WIP code for this but it's not
ready for the light of day.

Ian.

diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
index f889115..17ffd81 100644
--- a/tools/libxl/libxl_event.h
+++ b/tools/libxl/libxl_event.h
@@ -369,6 +369,125 @@ void libxl_osevent_occurred_fd(libxl_ctx *ctx, void *for_libxl,
  */
 void libxl_osevent_occurred_timeout(libxl_ctx *ctx, void *for_libxl);
 
+
+/*======================================================================*/
+
+/*
+ * Subprocess handling.
+ *
+ * Unfortunately the POSIX interface makes this very awkward.
+ *
+ * There are two possible arrangements for collecting statuses from
+ * wait/waitpid.
+ *
+ * For naive programs:
+ *
+ *     libxl will keep a SIGCHLD handler installed whenever it has an
+ *     active (unreaped) child.  It will reap all children with
+ *     wait(); any children it does not recognise will be passed to
+ *     the application via an optional callback (and will result in
+ *     warnings to stderr if no callback is provided).
+ *
+ *     libxl may have children whenever:
+ *
+ *       - libxl is performing an operation which can be made
+ *         asynchronous; ie one taking a libxl_asyncop_how, even
+ *         if NULL is passed indicating that the operation is
+ *         synchronous; or
+ *
+ *       - events of any kind are being generated, as requested
+ *         by libxl_evenable_....
+ *
+ * For programs which run their own children alongside libxl's:
+ *
+ *     The application must install a SIGCHLD handler and reap (at
+ *     least) all of libxl's children and pass their exit status
+ *     to libxl by calling libxl_childproc_exited.
+ *
+ *     An application which does this must call
+ *     libxl_childproc_setmode.
+ * 
+ * An application which fails to call setmode, or which passes 0 for
+ * hooks, must not:
+ *   - have any child processes running while it uses any libxl
+ *     operation which might create or use child processes (see
+ *     above);
+ *   - install a SIGCHLD handler; or
+ *   - reap any children.
+ */
+
+
+typedef enum {
+    /* libxl owns SIGCHLD whenever it has a child */
+    libxl_sigchld_owner_libxl,
+
+    /* Application promises to call libxl_childproc_exited but
+     * NOT from within a signal handler. */
+    libxl_sigchld_owner_mainloop,
+} libxl_sigchld_owner;
+
+typedef struct {
+    libxl_sigchld_owner chldowner;
+
+    /* All of these are optional: */
+
+    /* Called by libxl instead of fork.  Should behave exactly like
+     * fork, including setting errno etc.  May NOT reenter into libxl.
+     * Application may use this to discover pids of libxl's children,
+     * for example.
+     */
+    pid_t (*fork_replacement)(void *user);
+
+    /* With libxl_sigchld_owner_libxl, called by libxl when it has
+     * reaped a pid.  (Not permitted with _owner_app.)
+     *
+     * Should return 0 if the child was recognised by the application
+     * (or if the application does not keep those kind of records),
+     * ERROR_NOT_READY if the application knows that the child is not
+     * the application's; if it returns another error code it is a
+     * disaster as described for libxl_event_register_callbacks.
+     * (libxl will report unexpected children to its error log.)
+     *
+     * If not supplied, the application is assumed not to start
+     * any children of its own.
+     *
+     * This function is NOT called from within the signal handler.
+     * Rather it will be called from inside a libxl's event handling
+     * code and thus only when libxl is running, for example from
+     * within libxl_event_wait.  (libxl uses the self-pipe trick
+     * to implement this.)
+     *
+     * childproc_exited_callback may call back into libxl, but it
+     * is best to avoid making long-running libxl calls as that might
+     * stall the calling event loop while the nested operation
+     * completes.
+     */
+    int (*childproc_exited_callback)(pid_t, int status, void *user);
+} libxl_childproc_hooks;
+
+/* hooks may be 0 in which is equivalent to &{ libxl_sigchld_owner_libx, 0, 0 }
+ *
+ * May not be called when libxl might have any child processes, or the
+ * behaviour is undefined.  So it is best to call this at
+ * initialisation.
+ */
+void libxl_childproc_setmode(libxl_ctx *ctx, const libxl_childproc_hooks *hooks,
+                             void *user);
+
+/* May be called only by an application which has called setmode with
+ * chldowner == libxl_sigchld_owner_mainloop.  If pid was a process started
+ * by this instance of libxl, returns 0 after doing whatever
+ * processing is appropriate.  Otherwise silently returns
+ * ERROR_NOT_READY.  No other error returns are possible.
+ *
+ * May NOT be called from within a signal handler which might
+ * interrupt any libxl operation.  The application will almost
+ * certainly need to use the self-pipe trick (or a working pselect or
+ * ppoll) to implement this.
+ */
+int libxl_childproc_exited(libxl_ctx *ctx, pid_t, int status);
+
+
 #endif
 
 /*

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 19:35:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 19: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 1RsJU3-0006mJ-Ac; Tue, 31 Jan 2012 19:35: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 1RsJU2-0006lx-6R
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 19:35:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328038506!4860793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28242 invoked from network); 31 Jan 2012 19:35:06 -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;
	31 Jan 2012 19:35:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10401225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 19:34:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 19:34: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 1RsJSs-00016r-Vg;
	Tue, 31 Jan 2012 19:34:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsJSs-00033u-JL;
	Tue, 31 Jan 2012 19:34:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11747-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 31 Jan 2012 19:34:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 11747: 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 11747 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11747/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 10914

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  00c4b19f2648
baseline version:
 xen                  49bf114c23f5

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  James Carter <jwcart2@tycho.nsa.gov>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=00c4b19f2648
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 00c4b19f2648
+ branch=xen-4.1-testing
+ revision=00c4b19f2648
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 00c4b19f2648 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 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 19:35:31 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 19: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 1RsJU3-0006mJ-Ac; Tue, 31 Jan 2012 19:35: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 1RsJU2-0006lx-6R
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 19:35:14 +0000
X-Env-Sender: Ian.Jackson@eu.citrix.com
X-Msg-Ref: server-2.tower-21.messagelabs.com!1328038506!4860793!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28242 invoked from network); 31 Jan 2012 19:35:06 -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;
	31 Jan 2012 19:35:06 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10401225"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 19:34:03 +0000
Received: from norwich.cam.xci-test.com (10.80.248.129) by
	smtprelay.citrix.com (10.30.203.162) with Microsoft SMTP Server id
	8.3.213.0; Tue, 31 Jan 2012 19:34: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 1RsJSs-00016r-Vg;
	Tue, 31 Jan 2012 19:34:03 +0000
Received: from osstest by woking.xci-test.com with local (Exim 4.69)
	(envelope-from <ian.jackson@eu.citrix.com>)	id 1RsJSs-00033u-JL;
	Tue, 31 Jan 2012 19:34:02 +0000
To: xen-devel@lists.xensource.com
Message-ID: <osstest-11747-mainreport@xen.org>
From: xen.org <ian.jackson@eu.citrix.com>
Date: Tue, 31 Jan 2012 19:34:02 +0000
MIME-Version: 1.0
Cc: ian.jackson@eu.citrix.com
Subject: [Xen-devel] [xen-4.1-testing test] 11747: 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 11747 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11747/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf      5 xen-boot                  fail REGR. vs. 10914

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel 11 leak-check/check             fail never pass
 test-amd64-i386-rhel6hvm-amd 11 leak-check/check             fail   never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-win           16 leak-check/check             fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass

version targeted for testing:
 xen                  00c4b19f2648
baseline version:
 xen                  49bf114c23f5

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  James Carter <jwcart2@tycho.nsa.gov>
  Jean Guyader <jean.guyader@eu.citrix.com>
  Keir Fraser <keir@xen.org>
  Paulian Bogdan Marinca <paulian@marinca.net>
  Stefano Stabellini <stefano.stabellini@eu.citrix.com>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     fail    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-4.1-testing
+ revision=00c4b19f2648
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig 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 00c4b19f2648
+ branch=xen-4.1-testing
+ revision=00c4b19f2648
+ . cri-lock-repos
++ . cri-common
+++ umask 002
+++ getconfig Repos
+++ perl -e '
                use Osstest;
                readconfigonly();
                print $c{Repos} or die $!;
        '
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock ']'
+ . cri-common
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-4.1-testing
+ . ap-common
++ : http://xenbits.xen.org/staging/xen-4.1-testing.hg
++ : git://xenbits.xen.org/staging/qemu-xen-4.1-testing.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
++ : xen/next-2.6.32
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : stable/2.6.39.x
++ : daily-cron.xen-4.1-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-4.1-testing.git
++ : daily-cron.xen-4.1-testing
+ : xen@xenbits.xensource.com
+ : git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
+ : xen/next-2.6.32
+ : stable/2.6.39.x
+ case "$branch" in
+ cd /export/home/osstest/repos/xen-4.1-testing.hg
+ hg push -r 00c4b19f2648 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 4 changes to 4 files

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 20:03:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 20:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsJud-0007Mr-T8; Tue, 31 Jan 2012 20:02: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 1RsJub-0007Mm-Uo
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 20:02:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328040155!5834250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28082 invoked from network); 31 Jan 2012 20:02:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 20:02:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10401508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 20:02:35 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 20:02:35 +0000
Message-ID: <1328040154.28964.29.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 31 Jan 2012 20:02:34 +0000
In-Reply-To: <CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, 2012-01-31 at 09:57 +0000, Roger Pau Monn=E9 wrote:
> =

> =

> What I don't get is what you do when you have to boot a PV DomU which
> root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> the HDD (usually extracted using pygrub). Since the HDD is inside the
> driver domain, Dom0 doesn't have access to that image, so there's no
> way to extract the kernel/initrd from the Dom0. =


The usual way to deal with is to create a vbd device in dom0 (or which
ever domain runs pygrub) which attached to the backend domain and pass
that to pygrub. This is the sort of thing libxl_device_disk_local_attach
would be expected to handle.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 20:03:10 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 20:03:10 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsJud-0007Mr-T8; Tue, 31 Jan 2012 20:02: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 1RsJub-0007Mm-Uo
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 20:02:42 +0000
X-Env-Sender: Ian.Campbell@citrix.com
X-Msg-Ref: server-16.tower-182.messagelabs.com!1328040155!5834250!1
X-Originating-IP: [62.200.22.115]
X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: 
	VHJ1c3RlZCBJUDogNjIuMjAwLjIyLjExNSA9PiA4NjIzMQ==\n
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 28082 invoked from network); 31 Jan 2012 20:02:36 -0000
Received: from smtp.ctxuk.citrix.com (HELO SMTP.EU.CITRIX.COM) (62.200.22.115)
	by server-16.tower-182.messagelabs.com with RC4-SHA encrypted SMTP;
	31 Jan 2012 20:02:36 -0000
X-IronPort-AV: E=Sophos;i="4.71,597,1320624000"; d="scan'208";a="10401508"
Received: from lonpmailmx01.citrite.net ([10.30.203.162])
	by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5;
	31 Jan 2012 20:02:35 +0000
Received: from [127.0.0.1] (10.80.16.67) by smtprelay.citrix.com
	(10.30.203.162) with Microsoft SMTP Server id 8.3.213.0;
	Tue, 31 Jan 2012 20:02:35 +0000
Message-ID: <1328040154.28964.29.camel@dagon.hellion.org.uk>
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Roger Pau =?ISO-8859-1?Q?Monn=E9?= <roger.pau@entel.upc.edu>
Date: Tue, 31 Jan 2012 20:02:34 +0000
In-Reply-To: <CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
References: <1325694562.25206.304.camel@zakaz.uk.xensource.com>
	<20236.27158.706017.813195@mariner.uk.xensource.com>
	<alpine.DEB.2.00.1201101655390.3150@kaball-desktop>
	<20236.28931.127139.752426@mariner.uk.xensource.com>
	<CAPLaKK5PnnD-mP+rWyKtpeM6_mMqNZBQ+16U73CZcisagJeHFw@mail.gmail.com>
	<1326284268.17210.200.camel@zakaz.uk.xensource.com>
	<20239.3781.557131.765561@mariner.uk.xensource.com>
	<CAPLaKK5mutNHYge+bt113fy-D+bE9GjXHQJc0Ay9nfTxCoHRBg@mail.gmail.com>
	<20244.25907.223422.50324@mariner.uk.xensource.com>
	<1326791863.14689.52.camel@zakaz.uk.xensource.com>
	<CAPLaKK7XOHyQANS=zZLU8-Mc9BBPO_sH64ztqTFA6kmtfp13Kg@mail.gmail.com>
	<1326793927.14689.80.camel@zakaz.uk.xensource.com>
	<CAPLaKK5Cp+RtoxBs+hoXt=E_qDFuHr8EcwfUJ8RdhvmH5Jo9tA@mail.gmail.com>
	<1326796747.14689.93.camel@zakaz.uk.xensource.com>
	<CAPLaKK6w4j45y+_FhDfT67Q=h2a1mo5qXWZ+6r+7pNfLSX_rbA@mail.gmail.com>
	<CAPLaKK5Q=Gzu+DCywOAfDj5yCnGMbJaO=uuizTJixUrsbfVQ0w@mail.gmail.com>
	<alpine.DEB.2.00.1201271047300.3196@kaball-desktop>
	<CAPLaKK6uUr5ug8mjURAdewf+0LcLBkx37Q=Q8gF7ZN9RLaAPmA@mail.gmail.com>
Organization: Citrix Systems, Inc.
X-Mailer: Evolution 3.2.2-1 
MIME-Version: 1.0
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [Xen-devel] Driver domains and hotplug scripts, redux
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; 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, 2012-01-31 at 09:57 +0000, Roger Pau Monn=E9 wrote:
> =

> =

> What I don't get is what you do when you have to boot a PV DomU which
> root HDD is on the driver domain. Dom0 needs the kernel/initrd from
> the HDD (usually extracted using pygrub). Since the HDD is inside the
> driver domain, Dom0 doesn't have access to that image, so there's no
> way to extract the kernel/initrd from the Dom0. =


The usual way to deal with is to create a vbd device in dom0 (or which
ever domain runs pygrub) which attached to the backend domain and pass
that to pygrub. This is the sort of thing libxl_device_disk_local_attach
would be expected to handle.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDp-0008GE-69; Tue, 31 Jan 2012 21:26:37 +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 1RsLDn-0008FO-Dl
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328045188!9375309!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11110 invoked from network); 31 Jan 2012 21:26:28 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 21:26:28 -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
	q0VLQRco009318
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:27 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 q0VLQQZv006185
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 16:26:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:08 -0500
Message-Id: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Subject: [Xen-devel] [PATCH 00/10] FLASK updates: MSI interrupts, cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch set adds XSM security labels to useful debugging output
locations, and fixes some assumptions that all interrupts behaved like
GSI interrupts (which had useful non-dynamic IDs). It also cleans up the
policy build process and adds an example of how to use the user field in
the security context.

Debug output:
[PATCH 01/10] xsm: Add security labels to event-channel dump
[PATCH 02/10] xsm: Add security label to IRQ debug output

MSI interrupt fixes:
[PATCH 03/10] xsm/flask: Use PCI device label for PCI-MSI IRQs
[PATCH 04/10] xsm: Add xsm_map_domain_pirq hook
[PATCH 05/10] xsm: Use mapped IRQ not PIRQ in unmap_domain_pirq

Cleanup:
[PATCH 06/10] xsm/flask: Improve error reporting for ocontexts
[PATCH 07/10] xsm/flask: Remove useless back pointers
[PATCH 08/10] flask/policy: Policy build updates
[PATCH 09/10] flask/policy: Add user and constraint examples
[PATCH 10/10] flask/policy: use declare_domain for dom0_t

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDo-0008G7-QI; Tue, 31 Jan 2012 21:26:36 +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 1RsLDn-0008FN-30
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328045127!59201447!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12867 invoked from network); 31 Jan 2012 21:25:28 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:25:28 -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
	q0VLQRco009322
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:27 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 q0VLQQZw006185; 
	Tue, 31 Jan 2012 16:26:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:09 -0500
Message-Id: <1328045178-30665-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 01/10] xsm: Add security labels to event-channel
	dump
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 FLASK, event channel labels are distinct from the labels of the
domain using them. When debugging policy issues, it is useful to be able
to view the current label of event channels; add this label to the event
channel dump.

This patch also adds the IRQ associated with a PIRQ for event channels
bound to a PIRQ, and moves the xen_consumer flag to the front to create
more consistent alignment in the output.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c |   19 +++++++++++++++----
 xen/include/xsm/xsm.h      |    6 ++++++
 xen/xsm/dummy.c            |    6 ++++++
 xen/xsm/flask/hooks.c      |   30 ++++++++++++++++++++++++++++++
 4 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index f784254..989ebae 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1256,6 +1256,7 @@ void evtchn_move_pirqs(struct vcpu *v)
 static void domain_dump_evtchn_info(struct domain *d)
 {
     unsigned int port;
+    int irq;
 
     bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
                          d->poll_mask, d->max_vcpus);
@@ -1268,6 +1269,7 @@ static void domain_dump_evtchn_info(struct domain *d)
     for ( port = 1; port < MAX_EVTCHNS(d); ++port )
     {
         const struct evtchn *chn;
+        char *ssid;
 
         if ( !port_is_valid(d, port) )
             continue;
@@ -1275,11 +1277,12 @@ static void domain_dump_evtchn_info(struct domain *d)
         if ( chn->state == ECS_FREE )
             continue;
 
-        printk("    %4u [%d/%d]: s=%d n=%d",
+        printk("    %4u [%d/%d]: s=%d n=%d x=%d",
                port,
                !!test_bit(port, &shared_info(d, evtchn_pending)),
                !!test_bit(port, &shared_info(d, evtchn_mask)),
-               chn->state, chn->notify_vcpu_id);
+               chn->state, chn->notify_vcpu_id, chn->xen_consumer);
+
         switch ( chn->state )
         {
         case ECS_UNBOUND:
@@ -1291,13 +1294,21 @@ static void domain_dump_evtchn_info(struct domain *d)
                    chn->u.interdomain.remote_port);
             break;
         case ECS_PIRQ:
-            printk(" p=%d", chn->u.pirq.irq);
+            irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
+            printk(" p=%d i=%d", chn->u.pirq.irq, irq);
             break;
         case ECS_VIRQ:
             printk(" v=%d", chn->u.virq);
             break;
         }
-        printk(" x=%d\n", chn->xen_consumer);
+
+        ssid = xsm_show_security_evtchn(d, chn);
+        if (ssid) {
+            printk(" Z=%s\n", ssid);
+            xfree(ssid);
+        } else {
+            printk("\n");
+        }
     }
 
     spin_unlock(&d->event_lock);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index e3cae60..92204b3 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -99,6 +99,7 @@ struct xsm_operations {
     void (*free_security_domain) (struct domain *d);
     int (*alloc_security_evtchn) (struct evtchn *chn);
     void (*free_security_evtchn) (struct evtchn *chn);
+    char *(*show_security_evtchn) (struct domain *d, const struct evtchn *chn);
 
     int (*get_pod_target) (struct domain *d);
     int (*set_pod_target) (struct domain *d);
@@ -424,6 +425,11 @@ static inline void xsm_free_security_evtchn (struct evtchn *chn)
     (void)xsm_call(free_security_evtchn(chn));
 }
 
+static inline char *xsm_show_security_evtchn (struct domain *d, const struct evtchn *chn)
+{
+    return xsm_call(show_security_evtchn(d, chn));
+}
+
 static inline int xsm_get_pod_target (struct domain *d)
 {
     return xsm_call(get_pod_target(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index d99f886..fca9d7b 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -290,6 +290,11 @@ static void dummy_free_security_evtchn (struct evtchn *chn)
     return;
 }
 
+static char *dummy_show_security_evtchn (struct domain *d, const struct evtchn *chn)
+{
+    return NULL;
+}
+
 static int dummy_test_assign_device (uint32_t machine_bdf)
 {
     return 0;
@@ -637,6 +642,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, free_security_domain);
     set_to_dummy_if_null(ops, alloc_security_evtchn);
     set_to_dummy_if_null(ops, free_security_evtchn);
+    set_to_dummy_if_null(ops, show_security_evtchn);
 
     set_to_dummy_if_null(ops, memory_adjust_reservation);
     set_to_dummy_if_null(ops, memory_stat_reservation);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 543dc77..d207b1d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -274,6 +274,35 @@ static void flask_free_security_evtchn(struct evtchn *chn)
     xfree(esec);
 }
 
+static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *chn)
+{
+    struct evtchn_security_struct *esec;
+    int irq;
+    u32 sid = 0;
+    char *ctx;
+    u32 ctx_len;
+
+    switch ( chn->state )
+    {
+    case ECS_UNBOUND:
+    case ECS_INTERDOMAIN:
+        esec = chn->ssid;
+        if ( esec )
+            sid = esec->sid;
+        break;
+    case ECS_PIRQ:
+        irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
+        if (irq)
+            security_irq_sid(irq, &sid);
+        break;
+    }
+    if ( !sid )
+        return NULL;
+    if (security_sid_to_context(sid, &ctx, &ctx_len))
+        return NULL;
+    return ctx;
+}
+
 static int flask_grant_mapref(struct domain *d1, struct domain *d2, 
                               uint32_t flags)
 {
@@ -1499,6 +1528,7 @@ static struct xsm_operations flask_ops = {
     .free_security_domain = flask_domain_free_security,
     .alloc_security_evtchn = flask_alloc_security_evtchn,
     .free_security_evtchn = flask_free_security_evtchn,
+    .show_security_evtchn = flask_show_security_evtchn,
 
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDo-0008G7-QI; Tue, 31 Jan 2012 21:26:36 +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 1RsLDn-0008FN-30
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328045127!59201447!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12867 invoked from network); 31 Jan 2012 21:25:28 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-2.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:25:28 -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
	q0VLQRco009322
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:27 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 q0VLQQZw006185; 
	Tue, 31 Jan 2012 16:26:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:09 -0500
Message-Id: <1328045178-30665-2-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 01/10] xsm: Add security labels to event-channel
	dump
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 FLASK, event channel labels are distinct from the labels of the
domain using them. When debugging policy issues, it is useful to be able
to view the current label of event channels; add this label to the event
channel dump.

This patch also adds the IRQ associated with a PIRQ for event channels
bound to a PIRQ, and moves the xen_consumer flag to the front to create
more consistent alignment in the output.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/common/event_channel.c |   19 +++++++++++++++----
 xen/include/xsm/xsm.h      |    6 ++++++
 xen/xsm/dummy.c            |    6 ++++++
 xen/xsm/flask/hooks.c      |   30 ++++++++++++++++++++++++++++++
 4 files changed, 57 insertions(+), 4 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index f784254..989ebae 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1256,6 +1256,7 @@ void evtchn_move_pirqs(struct vcpu *v)
 static void domain_dump_evtchn_info(struct domain *d)
 {
     unsigned int port;
+    int irq;
 
     bitmap_scnlistprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
                          d->poll_mask, d->max_vcpus);
@@ -1268,6 +1269,7 @@ static void domain_dump_evtchn_info(struct domain *d)
     for ( port = 1; port < MAX_EVTCHNS(d); ++port )
     {
         const struct evtchn *chn;
+        char *ssid;
 
         if ( !port_is_valid(d, port) )
             continue;
@@ -1275,11 +1277,12 @@ static void domain_dump_evtchn_info(struct domain *d)
         if ( chn->state == ECS_FREE )
             continue;
 
-        printk("    %4u [%d/%d]: s=%d n=%d",
+        printk("    %4u [%d/%d]: s=%d n=%d x=%d",
                port,
                !!test_bit(port, &shared_info(d, evtchn_pending)),
                !!test_bit(port, &shared_info(d, evtchn_mask)),
-               chn->state, chn->notify_vcpu_id);
+               chn->state, chn->notify_vcpu_id, chn->xen_consumer);
+
         switch ( chn->state )
         {
         case ECS_UNBOUND:
@@ -1291,13 +1294,21 @@ static void domain_dump_evtchn_info(struct domain *d)
                    chn->u.interdomain.remote_port);
             break;
         case ECS_PIRQ:
-            printk(" p=%d", chn->u.pirq.irq);
+            irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
+            printk(" p=%d i=%d", chn->u.pirq.irq, irq);
             break;
         case ECS_VIRQ:
             printk(" v=%d", chn->u.virq);
             break;
         }
-        printk(" x=%d\n", chn->xen_consumer);
+
+        ssid = xsm_show_security_evtchn(d, chn);
+        if (ssid) {
+            printk(" Z=%s\n", ssid);
+            xfree(ssid);
+        } else {
+            printk("\n");
+        }
     }
 
     spin_unlock(&d->event_lock);
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index e3cae60..92204b3 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -99,6 +99,7 @@ struct xsm_operations {
     void (*free_security_domain) (struct domain *d);
     int (*alloc_security_evtchn) (struct evtchn *chn);
     void (*free_security_evtchn) (struct evtchn *chn);
+    char *(*show_security_evtchn) (struct domain *d, const struct evtchn *chn);
 
     int (*get_pod_target) (struct domain *d);
     int (*set_pod_target) (struct domain *d);
@@ -424,6 +425,11 @@ static inline void xsm_free_security_evtchn (struct evtchn *chn)
     (void)xsm_call(free_security_evtchn(chn));
 }
 
+static inline char *xsm_show_security_evtchn (struct domain *d, const struct evtchn *chn)
+{
+    return xsm_call(show_security_evtchn(d, chn));
+}
+
 static inline int xsm_get_pod_target (struct domain *d)
 {
     return xsm_call(get_pod_target(d));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index d99f886..fca9d7b 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -290,6 +290,11 @@ static void dummy_free_security_evtchn (struct evtchn *chn)
     return;
 }
 
+static char *dummy_show_security_evtchn (struct domain *d, const struct evtchn *chn)
+{
+    return NULL;
+}
+
 static int dummy_test_assign_device (uint32_t machine_bdf)
 {
     return 0;
@@ -637,6 +642,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, free_security_domain);
     set_to_dummy_if_null(ops, alloc_security_evtchn);
     set_to_dummy_if_null(ops, free_security_evtchn);
+    set_to_dummy_if_null(ops, show_security_evtchn);
 
     set_to_dummy_if_null(ops, memory_adjust_reservation);
     set_to_dummy_if_null(ops, memory_stat_reservation);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 543dc77..d207b1d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -274,6 +274,35 @@ static void flask_free_security_evtchn(struct evtchn *chn)
     xfree(esec);
 }
 
+static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *chn)
+{
+    struct evtchn_security_struct *esec;
+    int irq;
+    u32 sid = 0;
+    char *ctx;
+    u32 ctx_len;
+
+    switch ( chn->state )
+    {
+    case ECS_UNBOUND:
+    case ECS_INTERDOMAIN:
+        esec = chn->ssid;
+        if ( esec )
+            sid = esec->sid;
+        break;
+    case ECS_PIRQ:
+        irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
+        if (irq)
+            security_irq_sid(irq, &sid);
+        break;
+    }
+    if ( !sid )
+        return NULL;
+    if (security_sid_to_context(sid, &ctx, &ctx_len))
+        return NULL;
+    return ctx;
+}
+
 static int flask_grant_mapref(struct domain *d1, struct domain *d2, 
                               uint32_t flags)
 {
@@ -1499,6 +1528,7 @@ static struct xsm_operations flask_ops = {
     .free_security_domain = flask_domain_free_security,
     .alloc_security_evtchn = flask_alloc_security_evtchn,
     .free_security_evtchn = flask_free_security_evtchn,
+    .show_security_evtchn = flask_show_security_evtchn,
 
     .get_pod_target = flask_get_pod_target,
     .set_pod_target = flask_set_pod_target,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDp-0008GE-69; Tue, 31 Jan 2012 21:26:37 +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 1RsLDn-0008FO-Dl
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328045188!9375309!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11110 invoked from network); 31 Jan 2012 21:26:28 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-7.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 21:26:28 -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
	q0VLQRco009318
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:27 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 q0VLQQZv006185
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 16:26:26 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:08 -0500
Message-Id: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
Subject: [Xen-devel] [PATCH 00/10] FLASK updates: MSI interrupts, cleanups
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

This patch set adds XSM security labels to useful debugging output
locations, and fixes some assumptions that all interrupts behaved like
GSI interrupts (which had useful non-dynamic IDs). It also cleans up the
policy build process and adds an example of how to use the user field in
the security context.

Debug output:
[PATCH 01/10] xsm: Add security labels to event-channel dump
[PATCH 02/10] xsm: Add security label to IRQ debug output

MSI interrupt fixes:
[PATCH 03/10] xsm/flask: Use PCI device label for PCI-MSI IRQs
[PATCH 04/10] xsm: Add xsm_map_domain_pirq hook
[PATCH 05/10] xsm: Use mapped IRQ not PIRQ in unmap_domain_pirq

Cleanup:
[PATCH 06/10] xsm/flask: Improve error reporting for ocontexts
[PATCH 07/10] xsm/flask: Remove useless back pointers
[PATCH 08/10] flask/policy: Policy build updates
[PATCH 09/10] flask/policy: Add user and constraint examples
[PATCH 10/10] flask/policy: use declare_domain for dom0_t

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDq-0008Gt-BS; Tue, 31 Jan 2012 21:26: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 1RsLDo-0008FS-BY
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328045188!3944285!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15189 invoked from network); 31 Jan 2012 21:26:29 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 21:26: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
	q0VLQRco009323
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:27 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 q0VLQQZx006185; 
	Tue, 31 Jan 2012 16:26:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:10 -0500
Message-Id: <1328045178-30665-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 02/10] xsm: Add security label to IRQ debug
	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>
MIME-Version: 1.0
Content-Type: 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/arch/x86/irq.c    |    8 ++++++++
 xen/include/xsm/xsm.h |    7 +++++++
 xen/xsm/dummy.c       |    7 ++++++-
 xen/xsm/flask/hooks.c |   16 ++++++++++++++++
 4 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 058f89d..6d17ec0 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2001,6 +2001,7 @@ static void dump_irqs(unsigned char key)
     struct domain *d;
     const struct pirq *info;
     unsigned long flags;
+    char *ssid;
 
     printk("Guest interrupt information:\n");
 
@@ -2012,6 +2013,8 @@ static void dump_irqs(unsigned char key)
         if ( !irq_desc_initialized(desc) || desc->handler == &no_irq_type )
             continue;
 
+        ssid = xsm_show_irq_sid(irq);
+
         spin_lock_irqsave(&desc->lock, flags);
 
         cpumask_scnprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
@@ -2021,6 +2024,9 @@ static void dump_irqs(unsigned char key)
                irq, keyhandler_scratch, desc->arch.vector,
                desc->handler->typename, desc->status);
 
+        if ( ssid )
+            printk("Z=%-25s ", ssid);
+
         if ( !(desc->status & IRQ_GUEST) )
             printk("mapped, unbound\n");
         else
@@ -2053,6 +2059,8 @@ static void dump_irqs(unsigned char key)
         }
 
         spin_unlock_irqrestore(&desc->lock, flags);
+
+        xfree(ssid);
     }
 
     dump_ioapic_irq_info();
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 92204b3..6e3a8f0 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -113,6 +113,8 @@ struct xsm_operations {
 
     int (*kexec) (void);
     int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
+
+    char *(*show_irq_sid) (int irq);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
     int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
@@ -477,6 +479,11 @@ static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
     return xsm_call(schedop_shutdown(d1, d2));
 }
 
+static inline char *xsm_show_irq_sid (int irq)
+{
+    return xsm_call(show_irq_sid(irq));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index fca9d7b..83e5dba 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -365,12 +365,16 @@ static int dummy_sched_op (void)
     return 0;
 }
 
-
 static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
 }
 
+static char *dummy_show_irq_sid (int irq)
+{
+    return NULL;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -655,6 +659,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, kexec);
     set_to_dummy_if_null(ops, schedop_shutdown);
 
+    set_to_dummy_if_null(ops, show_irq_sid);
     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);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d207b1d..d79405b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -712,6 +712,20 @@ static inline u32 resource_to_perm(uint8_t access)
         return RESOURCE__REMOVE;
 }
 
+static char *flask_show_irq_sid (int irq)
+{
+    u32 sid, ctx_len;
+    char *ctx;
+    int rc = security_irq_sid(irq, &sid);
+    if ( rc )
+        return NULL;
+
+    if (security_sid_to_context(sid, &ctx, &ctx_len))
+        return NULL;
+
+    return ctx;
+}
+
 static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     u32 perm;
@@ -1543,6 +1557,8 @@ static struct xsm_operations flask_ops = {
     .kexec = flask_kexec,
     .schedop_shutdown = flask_schedop_shutdown,
 
+    .show_irq_sid = flask_show_irq_sid,
+
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDq-0008Gt-BS; Tue, 31 Jan 2012 21:26: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 1RsLDo-0008FS-BY
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-4.tower-21.messagelabs.com!1328045188!3944285!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15189 invoked from network); 31 Jan 2012 21:26:29 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-4.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 21:26: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
	q0VLQRco009323
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:27 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 q0VLQQZx006185; 
	Tue, 31 Jan 2012 16:26:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:10 -0500
Message-Id: <1328045178-30665-3-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 02/10] xsm: Add security label to IRQ debug
	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>
MIME-Version: 1.0
Content-Type: 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/arch/x86/irq.c    |    8 ++++++++
 xen/include/xsm/xsm.h |    7 +++++++
 xen/xsm/dummy.c       |    7 ++++++-
 xen/xsm/flask/hooks.c |   16 ++++++++++++++++
 4 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 058f89d..6d17ec0 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2001,6 +2001,7 @@ static void dump_irqs(unsigned char key)
     struct domain *d;
     const struct pirq *info;
     unsigned long flags;
+    char *ssid;
 
     printk("Guest interrupt information:\n");
 
@@ -2012,6 +2013,8 @@ static void dump_irqs(unsigned char key)
         if ( !irq_desc_initialized(desc) || desc->handler == &no_irq_type )
             continue;
 
+        ssid = xsm_show_irq_sid(irq);
+
         spin_lock_irqsave(&desc->lock, flags);
 
         cpumask_scnprintf(keyhandler_scratch, sizeof(keyhandler_scratch),
@@ -2021,6 +2024,9 @@ static void dump_irqs(unsigned char key)
                irq, keyhandler_scratch, desc->arch.vector,
                desc->handler->typename, desc->status);
 
+        if ( ssid )
+            printk("Z=%-25s ", ssid);
+
         if ( !(desc->status & IRQ_GUEST) )
             printk("mapped, unbound\n");
         else
@@ -2053,6 +2059,8 @@ static void dump_irqs(unsigned char key)
         }
 
         spin_unlock_irqrestore(&desc->lock, flags);
+
+        xfree(ssid);
     }
 
     dump_ioapic_irq_info();
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 92204b3..6e3a8f0 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -113,6 +113,8 @@ struct xsm_operations {
 
     int (*kexec) (void);
     int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
+
+    char *(*show_irq_sid) (int irq);
     int (*irq_permission) (struct domain *d, int pirq, uint8_t allow);
     int (*iomem_permission) (struct domain *d, uint64_t s, uint64_t e, uint8_t allow);
     int (*pci_config_permission) (struct domain *d, uint32_t machine_bdf, uint16_t start, uint16_t end, uint8_t access);
@@ -477,6 +479,11 @@ static inline int xsm_schedop_shutdown (struct domain *d1, struct domain *d2)
     return xsm_call(schedop_shutdown(d1, d2));
 }
 
+static inline char *xsm_show_irq_sid (int irq)
+{
+    return xsm_call(show_irq_sid(irq));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index fca9d7b..83e5dba 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -365,12 +365,16 @@ static int dummy_sched_op (void)
     return 0;
 }
 
-
 static long dummy___do_xsm_op(XEN_GUEST_HANDLE(xsm_op_t) op)
 {
     return -ENOSYS;
 }
 
+static char *dummy_show_irq_sid (int irq)
+{
+    return NULL;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -655,6 +659,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, kexec);
     set_to_dummy_if_null(ops, schedop_shutdown);
 
+    set_to_dummy_if_null(ops, show_irq_sid);
     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);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d207b1d..d79405b 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -712,6 +712,20 @@ static inline u32 resource_to_perm(uint8_t access)
         return RESOURCE__REMOVE;
 }
 
+static char *flask_show_irq_sid (int irq)
+{
+    u32 sid, ctx_len;
+    char *ctx;
+    int rc = security_irq_sid(irq, &sid);
+    if ( rc )
+        return NULL;
+
+    if (security_sid_to_context(sid, &ctx, &ctx_len))
+        return NULL;
+
+    return ctx;
+}
+
 static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
 {
     u32 perm;
@@ -1543,6 +1557,8 @@ static struct xsm_operations flask_ops = {
     .kexec = flask_kexec,
     .schedop_shutdown = flask_schedop_shutdown,
 
+    .show_irq_sid = flask_show_irq_sid,
+
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDp-0008GW-V7; Tue, 31 Jan 2012 21:26:37 +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 1RsLDo-0008FQ-1W
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328045071!61983990!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15584 invoked from network); 31 Jan 2012 21:24:31 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:24:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0VLQSco009333
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa2006185; 
	Tue, 31 Jan 2012 16:26:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:13 -0500
Message-Id: <1328045178-30665-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/10] xsm: Use mapped IRQ not PIRQ in
	unmap_domain_pirq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

XSM permissions are defined in terms of IRQs, not PIRQs; use the correct
number when checking permission in unmap_domain_pirq.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/physdev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index a3ceb7d..05fff9e 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -239,7 +239,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
-    ret = xsm_irq_permission(d, pirq, 0);
+    ret = xsm_irq_permission(d, domain_pirq_to_irq(d, pirq), 0);
     if ( ret )
         goto free_domain;
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDp-0008GW-V7; Tue, 31 Jan 2012 21:26:37 +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 1RsLDo-0008FQ-1W
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-27.messagelabs.com!1328045071!61983990!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 15584 invoked from network); 31 Jan 2012 21:24:31 -0000
Received: from msux-gh1-uea02.nsa.gov (HELO msux-gh1-uea02.nsa.gov)
	(63.239.65.40) by server-8.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:24:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0VLQSco009333
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa2006185; 
	Tue, 31 Jan 2012 16:26:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:13 -0500
Message-Id: <1328045178-30665-6-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 05/10] xsm: Use mapped IRQ not PIRQ in
	unmap_domain_pirq
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

XSM permissions are defined in terms of IRQs, not PIRQs; use the correct
number when checking permission in unmap_domain_pirq.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/physdev.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index a3ceb7d..05fff9e 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -239,7 +239,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
     if ( !IS_PRIV_FOR(current->domain, d) )
         goto free_domain;
 
-    ret = xsm_irq_permission(d, pirq, 0);
+    ret = xsm_irq_permission(d, domain_pirq_to_irq(d, pirq), 0);
     if ( ret )
         goto free_domain;
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDp-0008GM-Ic; Tue, 31 Jan 2012 21:26:37 +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 1RsLDn-0008FP-FZ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328045134!54824491!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13407 invoked from network); 31 Jan 2012 21:25:35 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:25:35 -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
	q0VLQSPV014715
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa0006185; 
	Tue, 31 Jan 2012 16:26:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:11 -0500
Message-Id: <1328045178-30665-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/10] xsm/flask: Use PCI device label for
	PCI-MSI 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Because the PCI-MSI IRQ numbers are allocated dynamically, labeling them
by number is not useful. Instead, for all IRQs beyond nr_irqs_gsi,
use the associated msi_desc to find the PCI device and use the label of
the PCI device for the IRQ.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |   53 +++++++++++++++++++++++++++++++++++-------------
 1 files changed, 38 insertions(+), 15 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d79405b..0dbf19d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -19,6 +19,7 @@
 #include <xen/errno.h>
 #include <xen/guest_access.h>
 #include <xen/xenoprof.h>
+#include <asm/msi.h>
 #include <public/xen.h>
 #include <public/physdev.h>
 #include <public/platform.h>
@@ -62,6 +63,36 @@ static int domain_has_xen(struct domain *d, u32 perms)
     return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
 }
 
+static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    if ( irq >= nr_irqs || irq < 0 )
+        return -EINVAL;
+    if ( irq < nr_irqs_gsi ) {
+        if (ad) {
+            AVC_AUDIT_DATA_INIT(ad, IRQ);
+            ad->irq = irq;
+        }
+        return security_irq_sid(irq, sid);
+    }
+    if ( desc->msi_desc ) {
+        struct pci_dev *dev = desc->msi_desc->dev;
+        u32 sbdf = (dev->seg << 16) | (dev->bus << 8) | dev->devfn;
+        if (ad) {
+            AVC_AUDIT_DATA_INIT(ad, DEV);
+            ad->device = sbdf;
+        }
+        return security_device_sid(sbdf, sid);
+    }
+    if (ad) {
+        AVC_AUDIT_DATA_INIT(ad, IRQ);
+        ad->irq = irq;
+    }
+    /* HPET or IOMMU IRQ, should not be seen by domains */
+    *sid = SECINITSID_UNLABELED;
+    return 0;
+}
+
 static int flask_domain_alloc_security(struct domain *d)
 {
     struct domain_security_struct *dsec;
@@ -292,8 +323,8 @@ static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *c
         break;
     case ECS_PIRQ:
         irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
-        if (irq)
-            security_irq_sid(irq, &sid);
+        if (irq && get_irq_sid(irq, &sid, NULL))
+            return NULL;
         break;
     }
     if ( !sid )
@@ -716,7 +747,7 @@ static char *flask_show_irq_sid (int irq)
 {
     u32 sid, ctx_len;
     char *ctx;
-    int rc = security_irq_sid(irq, &sid);
+    int rc = get_irq_sid(irq, &sid, NULL);
     if ( rc )
         return NULL;
 
@@ -726,7 +757,7 @@ static char *flask_show_irq_sid (int irq)
     return ctx;
 }
 
-static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
+static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
 {
     u32 perm;
     u32 rsid;
@@ -749,13 +780,10 @@ static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
     ssec = current->domain->ssid;
     tsec = d->ssid;
 
-    rc = security_irq_sid(pirq, &rsid);
+    rc = get_irq_sid(irq, &rsid, &ad);
     if ( rc )
         return rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, IRQ);
-    ad.irq = pirq;
-
     rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
     if ( rc )
         return rc;
@@ -915,12 +943,10 @@ static int flask_resource_setup_gsi(int gsi)
     struct avc_audit_data ad;
     struct domain_security_struct *ssec;
 
-    rc = security_irq_sid(gsi, &rsid);
+    rc = get_irq_sid(gsi, &rsid, &ad);
     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);
 }
@@ -1424,13 +1450,10 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
 
     irq = domain_pirq_to_irq(d, bind->machine_irq);
 
-    rc = security_irq_sid(irq, &rsid);
+    rc = get_irq_sid(irq, &rsid, &ad);
     if ( rc )
         return rc;
 
-    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);
     if ( rc )
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:04 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDp-0008GM-Ic; Tue, 31 Jan 2012 21:26:37 +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 1RsLDn-0008FP-FZ
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:35 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-27.messagelabs.com!1328045134!54824491!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=2.0 required=7.0 tests=SUBJECT_RANDOMQ
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13407 invoked from network); 31 Jan 2012 21:25:35 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:25:35 -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
	q0VLQSPV014715
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa0006185; 
	Tue, 31 Jan 2012 16:26:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:11 -0500
Message-Id: <1328045178-30665-4-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 03/10] xsm/flask: Use PCI device label for
	PCI-MSI 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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Because the PCI-MSI IRQ numbers are allocated dynamically, labeling them
by number is not useful. Instead, for all IRQs beyond nr_irqs_gsi,
use the associated msi_desc to find the PCI device and use the label of
the PCI device for the IRQ.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c |   53 +++++++++++++++++++++++++++++++++++-------------
 1 files changed, 38 insertions(+), 15 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index d79405b..0dbf19d 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -19,6 +19,7 @@
 #include <xen/errno.h>
 #include <xen/guest_access.h>
 #include <xen/xenoprof.h>
+#include <asm/msi.h>
 #include <public/xen.h>
 #include <public/physdev.h>
 #include <public/platform.h>
@@ -62,6 +63,36 @@ static int domain_has_xen(struct domain *d, u32 perms)
     return avc_has_perm(dsec->sid, SECINITSID_XEN, SECCLASS_XEN, perms, NULL);
 }
 
+static int get_irq_sid(int irq, u32 *sid, struct avc_audit_data *ad)
+{
+    struct irq_desc *desc = irq_to_desc(irq);
+    if ( irq >= nr_irqs || irq < 0 )
+        return -EINVAL;
+    if ( irq < nr_irqs_gsi ) {
+        if (ad) {
+            AVC_AUDIT_DATA_INIT(ad, IRQ);
+            ad->irq = irq;
+        }
+        return security_irq_sid(irq, sid);
+    }
+    if ( desc->msi_desc ) {
+        struct pci_dev *dev = desc->msi_desc->dev;
+        u32 sbdf = (dev->seg << 16) | (dev->bus << 8) | dev->devfn;
+        if (ad) {
+            AVC_AUDIT_DATA_INIT(ad, DEV);
+            ad->device = sbdf;
+        }
+        return security_device_sid(sbdf, sid);
+    }
+    if (ad) {
+        AVC_AUDIT_DATA_INIT(ad, IRQ);
+        ad->irq = irq;
+    }
+    /* HPET or IOMMU IRQ, should not be seen by domains */
+    *sid = SECINITSID_UNLABELED;
+    return 0;
+}
+
 static int flask_domain_alloc_security(struct domain *d)
 {
     struct domain_security_struct *dsec;
@@ -292,8 +323,8 @@ static char *flask_show_security_evtchn(struct domain *d, const struct evtchn *c
         break;
     case ECS_PIRQ:
         irq = domain_pirq_to_irq(d, chn->u.pirq.irq);
-        if (irq)
-            security_irq_sid(irq, &sid);
+        if (irq && get_irq_sid(irq, &sid, NULL))
+            return NULL;
         break;
     }
     if ( !sid )
@@ -716,7 +747,7 @@ static char *flask_show_irq_sid (int irq)
 {
     u32 sid, ctx_len;
     char *ctx;
-    int rc = security_irq_sid(irq, &sid);
+    int rc = get_irq_sid(irq, &sid, NULL);
     if ( rc )
         return NULL;
 
@@ -726,7 +757,7 @@ static char *flask_show_irq_sid (int irq)
     return ctx;
 }
 
-static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
+static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
 {
     u32 perm;
     u32 rsid;
@@ -749,13 +780,10 @@ static int flask_irq_permission (struct domain *d, int pirq, uint8_t access)
     ssec = current->domain->ssid;
     tsec = d->ssid;
 
-    rc = security_irq_sid(pirq, &rsid);
+    rc = get_irq_sid(irq, &rsid, &ad);
     if ( rc )
         return rc;
 
-    AVC_AUDIT_DATA_INIT(&ad, IRQ);
-    ad.irq = pirq;
-
     rc = avc_has_perm(ssec->sid, rsid, SECCLASS_RESOURCE, perm, &ad);
     if ( rc )
         return rc;
@@ -915,12 +943,10 @@ static int flask_resource_setup_gsi(int gsi)
     struct avc_audit_data ad;
     struct domain_security_struct *ssec;
 
-    rc = security_irq_sid(gsi, &rsid);
+    rc = get_irq_sid(gsi, &rsid, &ad);
     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);
 }
@@ -1424,13 +1450,10 @@ static int flask_bind_pt_irq (struct domain *d, struct xen_domctl_bind_pt_irq *b
 
     irq = domain_pirq_to_irq(d, bind->machine_irq);
 
-    rc = security_irq_sid(irq, &rsid);
+    rc = get_irq_sid(irq, &rsid, &ad);
     if ( rc )
         return rc;
 
-    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);
     if ( rc )
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDs-0008Ht-Eb; Tue, 31 Jan 2012 21:26:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsLDp-0008Fa-Ra
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328045189!9606933!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4894 invoked from network); 31 Jan 2012 21:26:30 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 21:26:30 -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
	q0VLQSPV014721
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa3006185; 
	Tue, 31 Jan 2012 16:26:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:14 -0500
Message-Id: <1328045178-30665-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/10] xsm/flask: Improve error reporting for
	ocontexts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 returning -EINVAL for all errors, return -EEXIST if adding an
entry that overlaps with an existing entry, and -ENOENT if attempting to
remove an entry that does not exist. Adding an ocontext that already
exists with the same SID is no longer an error.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/ss/services.c |   29 +++++++++++++++++++++--------
 1 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 7b08e73..3b0acf5 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -2084,8 +2084,10 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
         {
             if ( c->u.pirq == add->u.pirq )
             {
+                if ( c->sid[0] == sid )
+                    break;
                 printk("%s: Duplicate pirq %d\n", __FUNCTION__, add->u.pirq);
-                ret = -EINVAL;
+                ret = -EEXIST;
                 break;
             }
             c = c->next;
@@ -2112,10 +2114,14 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
 
         if (c && c->u.ioport.low_ioport <= high)
         {
+            if (c->u.ioport.low_ioport == low &&
+                c->u.ioport.high_ioport == high && c->sid[0] == sid)
+                break;
+
             printk("%s: IO Port overlap with entry 0x%x - 0x%x\n",
                    __FUNCTION__, c->u.ioport.low_ioport,
                    c->u.ioport.high_ioport);
-            ret = -EINVAL;
+            ret = -EEXIST;
             break;
         }
 
@@ -2142,10 +2148,14 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
 
         if (c && c->u.iomem.low_iomem <= high)
         {
+            if (c->u.iomem.low_iomem == low &&
+                c->u.iomem.high_iomem == high && c->sid[0] == sid)
+                break;
+
             printk("%s: IO Memory overlap with entry 0x%x - 0x%x\n",
                    __FUNCTION__, c->u.iomem.low_iomem,
                    c->u.iomem.high_iomem);
-            ret = -EINVAL;
+            ret = -EEXIST;
             break;
         }
 
@@ -2171,9 +2181,12 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
         {
             if ( c->u.device == add->u.device )
             {
+                if ( c->sid[0] == sid )
+                    break;
+
                 printk("%s: Duplicate PCI Device 0x%x\n", __FUNCTION__,
                         add->u.device);
-                ret = -EINVAL;
+                ret = -EEXIST;
                 break;
             }
             c = c->next;
@@ -2230,7 +2243,7 @@ int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
         }
 
         printk("%s: ocontext not found: pirq %d\n", __FUNCTION__, low);
-        ret = -EINVAL;
+        ret = -ENOENT;
         break;
 
     case OCON_IOPORT:
@@ -2257,7 +2270,7 @@ int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
 
         printk("%s: ocontext not found: ioport 0x%x - 0x%x\n", __FUNCTION__,
                 low, high);
-        ret = -EINVAL;
+        ret = -ENOENT;
         break;
 
     case OCON_IOMEM:
@@ -2284,7 +2297,7 @@ int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
 
         printk("%s: ocontext not found: iomem 0x%x - 0x%x\n", __FUNCTION__,
                 low, high);
-        ret = -EINVAL;
+        ret = -ENOENT;
         break;
 
     case OCON_DEVICE:
@@ -2309,7 +2322,7 @@ int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
         }
 
         printk("%s: ocontext not found: pcidevice 0x%x\n", __FUNCTION__, low);
-        ret = -EINVAL;
+        ret = -ENOENT;
         break;
 
     default:
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDs-0008IF-Qe; Tue, 31 Jan 2012 21:26:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsLDq-0008Fb-0G
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328045190!3456815!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2491 invoked from network); 31 Jan 2012 21:26:31 -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;
	31 Jan 2012 21:26:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0VLQTco009338
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0VLQQa7006185; 
	Tue, 31 Jan 2012 16:26:29 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:18 -0500
Message-Id: <1328045178-30665-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 10/10] flask/policy: use declare_domain for
	dom0_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.if |    4 ++--
 tools/flask/policy/policy/modules/xen/xen.te |    4 +---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3065718..dde7f90 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -5,10 +5,10 @@
 # Domain creation and setup
 #
 ################################################################################
-# declare_domain(type)
+# declare_domain(type, attrs...)
 #   Declare a type as a domain type, and allow basic domain setup
 define(`declare_domain', `
-	type $1, domain_type;
+	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
 	allow $1 $1:grant { query setup };
 	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
 	allow $1 $1:hvm { getparam setparam };
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 67dd0df..fb71b75 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -25,7 +25,7 @@ attribute mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
-type dom0_t, domain_type, mls_priv;
+declare_domain(dom0_t, mls_priv);
 
 # Untracked I/O memory (pseudo-domain)
 type domio_t, xen_type;
@@ -63,8 +63,6 @@ allow dom0_t security_t:security { check_context compute_av compute_create
 	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 };
 
 admin_device(dom0_t, device_t)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDs-0008Ht-Eb; Tue, 31 Jan 2012 21:26:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsLDp-0008Fa-Ra
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-3.tower-21.messagelabs.com!1328045189!9606933!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4894 invoked from network); 31 Jan 2012 21:26:30 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-3.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 21:26:30 -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
	q0VLQSPV014721
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa3006185; 
	Tue, 31 Jan 2012 16:26:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:14 -0500
Message-Id: <1328045178-30665-7-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 06/10] xsm/flask: Improve error reporting for
	ocontexts
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 returning -EINVAL for all errors, return -EEXIST if adding an
entry that overlaps with an existing entry, and -ENOENT if attempting to
remove an entry that does not exist. Adding an ocontext that already
exists with the same SID is no longer an error.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/ss/services.c |   29 +++++++++++++++++++++--------
 1 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/xen/xsm/flask/ss/services.c b/xen/xsm/flask/ss/services.c
index 7b08e73..3b0acf5 100644
--- a/xen/xsm/flask/ss/services.c
+++ b/xen/xsm/flask/ss/services.c
@@ -2084,8 +2084,10 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
         {
             if ( c->u.pirq == add->u.pirq )
             {
+                if ( c->sid[0] == sid )
+                    break;
                 printk("%s: Duplicate pirq %d\n", __FUNCTION__, add->u.pirq);
-                ret = -EINVAL;
+                ret = -EEXIST;
                 break;
             }
             c = c->next;
@@ -2112,10 +2114,14 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
 
         if (c && c->u.ioport.low_ioport <= high)
         {
+            if (c->u.ioport.low_ioport == low &&
+                c->u.ioport.high_ioport == high && c->sid[0] == sid)
+                break;
+
             printk("%s: IO Port overlap with entry 0x%x - 0x%x\n",
                    __FUNCTION__, c->u.ioport.low_ioport,
                    c->u.ioport.high_ioport);
-            ret = -EINVAL;
+            ret = -EEXIST;
             break;
         }
 
@@ -2142,10 +2148,14 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
 
         if (c && c->u.iomem.low_iomem <= high)
         {
+            if (c->u.iomem.low_iomem == low &&
+                c->u.iomem.high_iomem == high && c->sid[0] == sid)
+                break;
+
             printk("%s: IO Memory overlap with entry 0x%x - 0x%x\n",
                    __FUNCTION__, c->u.iomem.low_iomem,
                    c->u.iomem.high_iomem);
-            ret = -EINVAL;
+            ret = -EEXIST;
             break;
         }
 
@@ -2171,9 +2181,12 @@ int security_ocontext_add( char *ocontext, unsigned long low, unsigned long high
         {
             if ( c->u.device == add->u.device )
             {
+                if ( c->sid[0] == sid )
+                    break;
+
                 printk("%s: Duplicate PCI Device 0x%x\n", __FUNCTION__,
                         add->u.device);
-                ret = -EINVAL;
+                ret = -EEXIST;
                 break;
             }
             c = c->next;
@@ -2230,7 +2243,7 @@ int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
         }
 
         printk("%s: ocontext not found: pirq %d\n", __FUNCTION__, low);
-        ret = -EINVAL;
+        ret = -ENOENT;
         break;
 
     case OCON_IOPORT:
@@ -2257,7 +2270,7 @@ int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
 
         printk("%s: ocontext not found: ioport 0x%x - 0x%x\n", __FUNCTION__,
                 low, high);
-        ret = -EINVAL;
+        ret = -ENOENT;
         break;
 
     case OCON_IOMEM:
@@ -2284,7 +2297,7 @@ int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
 
         printk("%s: ocontext not found: iomem 0x%x - 0x%x\n", __FUNCTION__,
                 low, high);
-        ret = -EINVAL;
+        ret = -ENOENT;
         break;
 
     case OCON_DEVICE:
@@ -2309,7 +2322,7 @@ int security_ocontext_del( char *ocontext, unsigned int low, unsigned int high )
         }
 
         printk("%s: ocontext not found: pcidevice 0x%x\n", __FUNCTION__, low);
-        ret = -EINVAL;
+        ret = -ENOENT;
         break;
 
     default:
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDl-0008Fc-Dc; Tue, 31 Jan 2012 21:26:33 +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 1RsLDj-0008FT-MN
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328045058!50834221!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13910 invoked from network); 31 Jan 2012 21:24:19 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:24:19 -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
	q0VLQSPV014722
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa4006185; 
	Tue, 31 Jan 2012 16:26:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:15 -0500
Message-Id: <1328045178-30665-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 07/10] xsm/flask: Remove useless back 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: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c          |    3 ---
 xen/xsm/flask/include/objsec.h |    2 --
 2 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a095915..ad1013f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -104,8 +104,6 @@ static int flask_domain_alloc_security(struct domain *d)
 
     memset(dsec, 0, sizeof(struct domain_security_struct));
 
-    dsec->d = d;
-
     if ( is_idle_domain(d) )
     {
         dsec->sid = SECINITSID_XEN;
@@ -281,7 +279,6 @@ static int flask_alloc_security_evtchn(struct evtchn *chn)
 
     memset(esec, 0, sizeof(struct evtchn_security_struct));
 
-    esec->chn = chn;
     esec->sid = SECINITSID_UNLABELED;
 
     chn->ssid = esec;
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index 12f709a..df5baee 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -18,13 +18,11 @@
 #include "avc.h"
 
 struct domain_security_struct {
-    struct domain *d;      /* back pointer to domain object */
     u32 sid;               /* current SID */
     u32 create_sid;
 };
 
 struct evtchn_security_struct {
-    struct evtchn *chn;      /* back pointer to evtchn object */
     u32 sid;                 /* current SID */
 };
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDs-0008IF-Qe; Tue, 31 Jan 2012 21:26:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsLDq-0008Fb-0G
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:38 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-5.tower-21.messagelabs.com!1328045190!3456815!1
X-Originating-IP: [63.239.65.40]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2491 invoked from network); 31 Jan 2012 21:26:31 -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;
	31 Jan 2012 21:26:31 -0000
Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1])
	by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id
	q0VLQTco009338
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0VLQQa7006185; 
	Tue, 31 Jan 2012 16:26:29 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:18 -0500
Message-Id: <1328045178-30665-11-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 10/10] flask/policy: use declare_domain for
	dom0_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

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/policy/modules/xen/xen.if |    4 ++--
 tools/flask/policy/policy/modules/xen/xen.te |    4 +---
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if b/tools/flask/policy/policy/modules/xen/xen.if
index 3065718..dde7f90 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -5,10 +5,10 @@
 # Domain creation and setup
 #
 ################################################################################
-# declare_domain(type)
+# declare_domain(type, attrs...)
 #   Declare a type as a domain type, and allow basic domain setup
 define(`declare_domain', `
-	type $1, domain_type;
+	type $1, domain_type`'ifelse(`$#', `1', `', `,shift($@)');
 	allow $1 $1:grant { query setup };
 	allow $1 $1:mmu { adjust physmap map_read map_write stat pinpage };
 	allow $1 $1:hvm { getparam setparam };
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 67dd0df..fb71b75 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -25,7 +25,7 @@ attribute mls_priv;
 type xen_t, xen_type, mls_priv;
 
 # Domain 0
-type dom0_t, domain_type, mls_priv;
+declare_domain(dom0_t, mls_priv);
 
 # Untracked I/O memory (pseudo-domain)
 type domio_t, xen_type;
@@ -63,8 +63,6 @@ allow dom0_t security_t:security { check_context compute_av compute_create
 	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 };
 
 admin_device(dom0_t, device_t)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDl-0008Fc-Dc; Tue, 31 Jan 2012 21:26:33 +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 1RsLDj-0008FT-MN
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:31 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-14.tower-27.messagelabs.com!1328045058!50834221!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 13910 invoked from network); 31 Jan 2012 21:24:19 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-14.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:24:19 -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
	q0VLQSPV014722
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa4006185; 
	Tue, 31 Jan 2012 16:26:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:15 -0500
Message-Id: <1328045178-30665-8-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 07/10] xsm/flask: Remove useless back 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: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/xsm/flask/hooks.c          |    3 ---
 xen/xsm/flask/include/objsec.h |    2 --
 2 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index a095915..ad1013f 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -104,8 +104,6 @@ static int flask_domain_alloc_security(struct domain *d)
 
     memset(dsec, 0, sizeof(struct domain_security_struct));
 
-    dsec->d = d;
-
     if ( is_idle_domain(d) )
     {
         dsec->sid = SECINITSID_XEN;
@@ -281,7 +279,6 @@ static int flask_alloc_security_evtchn(struct evtchn *chn)
 
     memset(esec, 0, sizeof(struct evtchn_security_struct));
 
-    esec->chn = chn;
     esec->sid = SECINITSID_UNLABELED;
 
     chn->ssid = esec;
diff --git a/xen/xsm/flask/include/objsec.h b/xen/xsm/flask/include/objsec.h
index 12f709a..df5baee 100644
--- a/xen/xsm/flask/include/objsec.h
+++ b/xen/xsm/flask/include/objsec.h
@@ -18,13 +18,11 @@
 #include "avc.h"
 
 struct domain_security_struct {
-    struct domain *d;      /* back pointer to domain object */
     u32 sid;               /* current SID */
     u32 create_sid;
 };
 
 struct evtchn_security_struct {
-    struct evtchn *chn;      /* back pointer to evtchn object */
     u32 sid;                 /* current SID */
 };
 
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDr-0008HR-Cw; Tue, 31 Jan 2012 21:26:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsLDp-0008FU-7k
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328045129!59201454!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12966 invoked from network); 31 Jan 2012 21:25:30 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:25:30 -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
	q0VLQTPV014730
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0VLQQa6006185; 
	Tue, 31 Jan 2012 16:26:29 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:17 -0500
Message-Id: <1328045178-30665-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 09/10] flask/policy: Add user and constraint
	examples
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 examples show how to use constraints and the user field of the
security label to prevent communication between virtual machines of
different customers in a multi-tenant environment.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |   42 +++++++++++++++++++------
 tools/flask/policy/policy/constraints        |   15 ++++++++-
 tools/flask/policy/policy/modules/xen/xen.te |   28 +++++++++++++----
 tools/flask/policy/policy/users              |   14 ++------
 4 files changed, 71 insertions(+), 28 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 2eb75d6..285bb9f 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -27,14 +27,17 @@ FLASK_ENABLE to "y"; this change requires a make clean and rebuild.
 
 FLASK uses only one domain configuration parameter (seclabel) defining the
 full security label of the newly created domain. If using the example policy,
-"seclabel='system_u:system_r:domU_t'" would be used for normal domains. For
-simple policies including the example policy, the user and role portions of the
-label are unused and will always be "system_u:system_r".  Most of FLASK policy
-consists of defining the interactions allowed between different types (domU_t
-would be the type in this example); FLASK policy does not distinguish between
-domains with the same type. This is the same format as used for SELinux
-labeling; see http://selinuxproject.org for more details on the use of the user,
-role, and optional MLS/MCS labels.
+"seclabel='system_u:system_r:domU_t'" is an example of a normal domain. The
+labels are in the same format as SELinux labels; see http://selinuxproject.org
+for more details on the use of the user, role, and optional MLS/MCS labels.
+
+FLASK policy overview
+---------------------
+
+Most of FLASK policy consists of defining the interactions allowed between
+different types (domU_t would be the type in this example). For simple policies,
+only type enforcement is used and the user and role are set to system_u and
+system_r for all domains.
 
 The FLASK security framework is mostly configured using a security policy file.
 This policy file is not normally generated during the Xen build process because
@@ -57,8 +60,27 @@ that can be used without dom0 disaggregation. It has two main types for domUs:
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
 
-More types can be added to allow groups of domains to communicate without
-allowing communication between groups, or only between certain groups.
+One disadvantage of using type enforcement to enforce isolation is that a new
+type is needed for each group of domains. In addition, it is not possible to
+allow isolated_domU_t cannot to create loopback event channels without allowing
+two domains of type isolated_domU_t to communicate with one another.
+
+Users and roles
+---------------
+
+Users are defined in tools/flask/policy/policy/users. The example policy defines
+two users (customer_1 and customer_2) in addition to the system user system_u.
+Users are visible in the labels of domains and associated objects (event
+channels); in the example policy, "customer_1:vm_r:domU_t" is a valid label for
+the customer_1 user.
+
+Access control rules involving users and roles are defined in the policy
+constraints file (tools/flask/policy/policy/constraints). The example policy
+provides constraints that prevent different users from communicating using
+grants or event channels, while still allowing communication with dom0.
+
+Resource Policy
+---------------
 
 The example policy also includes a resource type (nic_dev_t) for device
 passthrough, configured to allow use by domU_t. To label the PCI device 3:2.0
diff --git a/tools/flask/policy/policy/constraints b/tools/flask/policy/policy/constraints
index beb949c..765ed4d 100644
--- a/tools/flask/policy/policy/constraints
+++ b/tools/flask/policy/policy/constraints
@@ -22,6 +22,19 @@
 # role_op : == | != | eq | dom | domby | incomp
 #
 # names : name | { name_list }
-# name_list : name | name_list name		
+# name_list : name | name_list name
 #
 
+# Prevent event channels and grants between different customers
+
+constrain event bind (
+	u1 == system_u or
+	u2 == system_u or
+	u1 == u2
+);
+
+constrain grant { map_read map_write copy } (
+	u1 == system_u or
+	u2 == system_u or
+	u1 == u2
+);
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index ac52c3f..67dd0df 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -22,22 +22,22 @@ attribute mls_priv;
 ################################################################################
 
 # The hypervisor itself
-type xen_t, xen_type, domain_type, mls_priv;
+type xen_t, xen_type, mls_priv;
 
 # Domain 0
 type dom0_t, domain_type, mls_priv;
 
 # Untracked I/O memory (pseudo-domain)
-type domio_t, domain_type;
+type domio_t, xen_type;
 
 # Xen heap (pseudo-domain)
-type domxen_t, domain_type;
+type domxen_t, xen_type;
 
 # Unlabeled objects
-type unlabeled_t, domain_type;
+type unlabeled_t, xen_type;
 
 # The XSM/FLASK security server
-type security_t, domain_type;
+type security_t, xen_type;
 
 # Unlabeled device resources
 # Note: don't allow access to these types directly; see below for how to label
@@ -143,7 +143,11 @@ delegate_devices(dom0_t, domU_t)
 
 ################################################################################
 #
-# Constraints
+# Policy constraints
+#
+# Neverallow rules will cause the policy build to fail if an allow rule exists
+# that violates the expression. This is used to ensure proper labeling of
+# objects.
 #
 ################################################################################
 
@@ -159,9 +163,19 @@ neverallow * ~event_type:event { create send status };
 
 ################################################################################
 #
-# Labels for initial SIDs and system role
+# Roles
 #
 ################################################################################
 
+# The object role (object_r) is used for devices, resources, and event channels;
+# it does not need to be defined here and should not be used for domains.
+
+# The system role is used for utility domains and pseudo-domains
 role system_r;
 role system_r types { xen_type domain_type };
+# If you want to prevent domUs from being placed in system_r:
+##role system_r types { xen_type dom0_t };
+
+# The vm role is used for customer virtual machines
+role vm_r;
+role vm_r types { domain_type -dom0_t };
diff --git a/tools/flask/policy/policy/users b/tools/flask/policy/policy/users
index a0205e5..35ed8a9 100644
--- a/tools/flask/policy/policy/users
+++ b/tools/flask/policy/policy/users
@@ -3,15 +3,9 @@
 # System User configuration.
 #
 
-#
-# gen_user(username, role_set, mls_defaultlevel, mls_range)
-#
-
-#
-# system_u is the user identity for system processes and objects.
-# There should be no corresponding Unix user identity for system,
-# and a user process should never be assigned the system user
-# identity.
-#
+# system_u is the user identity for system domains and objects
 gen_user(system_u,, system_r, s0, s0 - mls_systemhigh)
 
+# Other users are defined using the vm role
+gen_user(customer_1,, vm_r, s0, s0)
+gen_user(customer_2,, vm_r, s0, s0)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDr-0008HR-Cw; Tue, 31 Jan 2012 21:26:39 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsLDp-0008FU-7k
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-2.tower-27.messagelabs.com!1328045129!59201454!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 12966 invoked from network); 31 Jan 2012 21:25:30 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-2.tower-27.messagelabs.com with SMTP;
	31 Jan 2012 21:25:30 -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
	q0VLQTPV014730
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0VLQQa6006185; 
	Tue, 31 Jan 2012 16:26:29 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:17 -0500
Message-Id: <1328045178-30665-10-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 09/10] flask/policy: Add user and constraint
	examples
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 examples show how to use constraints and the user field of the
security label to prevent communication between virtual machines of
different customers in a multi-tenant environment.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 docs/misc/xsm-flask.txt                      |   42 +++++++++++++++++++------
 tools/flask/policy/policy/constraints        |   15 ++++++++-
 tools/flask/policy/policy/modules/xen/xen.te |   28 +++++++++++++----
 tools/flask/policy/policy/users              |   14 ++------
 4 files changed, 71 insertions(+), 28 deletions(-)

diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 2eb75d6..285bb9f 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -27,14 +27,17 @@ FLASK_ENABLE to "y"; this change requires a make clean and rebuild.
 
 FLASK uses only one domain configuration parameter (seclabel) defining the
 full security label of the newly created domain. If using the example policy,
-"seclabel='system_u:system_r:domU_t'" would be used for normal domains. For
-simple policies including the example policy, the user and role portions of the
-label are unused and will always be "system_u:system_r".  Most of FLASK policy
-consists of defining the interactions allowed between different types (domU_t
-would be the type in this example); FLASK policy does not distinguish between
-domains with the same type. This is the same format as used for SELinux
-labeling; see http://selinuxproject.org for more details on the use of the user,
-role, and optional MLS/MCS labels.
+"seclabel='system_u:system_r:domU_t'" is an example of a normal domain. The
+labels are in the same format as SELinux labels; see http://selinuxproject.org
+for more details on the use of the user, role, and optional MLS/MCS labels.
+
+FLASK policy overview
+---------------------
+
+Most of FLASK policy consists of defining the interactions allowed between
+different types (domU_t would be the type in this example). For simple policies,
+only type enforcement is used and the user and role are set to system_u and
+system_r for all domains.
 
 The FLASK security framework is mostly configured using a security policy file.
 This policy file is not normally generated during the Xen build process because
@@ -57,8 +60,27 @@ that can be used without dom0 disaggregation. It has two main types for domUs:
  - domU_t is a domain that can communicate with any other domU_t
  - isolated_domU_t can only communicate with dom0
 
-More types can be added to allow groups of domains to communicate without
-allowing communication between groups, or only between certain groups.
+One disadvantage of using type enforcement to enforce isolation is that a new
+type is needed for each group of domains. In addition, it is not possible to
+allow isolated_domU_t cannot to create loopback event channels without allowing
+two domains of type isolated_domU_t to communicate with one another.
+
+Users and roles
+---------------
+
+Users are defined in tools/flask/policy/policy/users. The example policy defines
+two users (customer_1 and customer_2) in addition to the system user system_u.
+Users are visible in the labels of domains and associated objects (event
+channels); in the example policy, "customer_1:vm_r:domU_t" is a valid label for
+the customer_1 user.
+
+Access control rules involving users and roles are defined in the policy
+constraints file (tools/flask/policy/policy/constraints). The example policy
+provides constraints that prevent different users from communicating using
+grants or event channels, while still allowing communication with dom0.
+
+Resource Policy
+---------------
 
 The example policy also includes a resource type (nic_dev_t) for device
 passthrough, configured to allow use by domU_t. To label the PCI device 3:2.0
diff --git a/tools/flask/policy/policy/constraints b/tools/flask/policy/policy/constraints
index beb949c..765ed4d 100644
--- a/tools/flask/policy/policy/constraints
+++ b/tools/flask/policy/policy/constraints
@@ -22,6 +22,19 @@
 # role_op : == | != | eq | dom | domby | incomp
 #
 # names : name | { name_list }
-# name_list : name | name_list name		
+# name_list : name | name_list name
 #
 
+# Prevent event channels and grants between different customers
+
+constrain event bind (
+	u1 == system_u or
+	u2 == system_u or
+	u1 == u2
+);
+
+constrain grant { map_read map_write copy } (
+	u1 == system_u or
+	u2 == system_u or
+	u1 == u2
+);
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index ac52c3f..67dd0df 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -22,22 +22,22 @@ attribute mls_priv;
 ################################################################################
 
 # The hypervisor itself
-type xen_t, xen_type, domain_type, mls_priv;
+type xen_t, xen_type, mls_priv;
 
 # Domain 0
 type dom0_t, domain_type, mls_priv;
 
 # Untracked I/O memory (pseudo-domain)
-type domio_t, domain_type;
+type domio_t, xen_type;
 
 # Xen heap (pseudo-domain)
-type domxen_t, domain_type;
+type domxen_t, xen_type;
 
 # Unlabeled objects
-type unlabeled_t, domain_type;
+type unlabeled_t, xen_type;
 
 # The XSM/FLASK security server
-type security_t, domain_type;
+type security_t, xen_type;
 
 # Unlabeled device resources
 # Note: don't allow access to these types directly; see below for how to label
@@ -143,7 +143,11 @@ delegate_devices(dom0_t, domU_t)
 
 ################################################################################
 #
-# Constraints
+# Policy constraints
+#
+# Neverallow rules will cause the policy build to fail if an allow rule exists
+# that violates the expression. This is used to ensure proper labeling of
+# objects.
 #
 ################################################################################
 
@@ -159,9 +163,19 @@ neverallow * ~event_type:event { create send status };
 
 ################################################################################
 #
-# Labels for initial SIDs and system role
+# Roles
 #
 ################################################################################
 
+# The object role (object_r) is used for devices, resources, and event channels;
+# it does not need to be defined here and should not be used for domains.
+
+# The system role is used for utility domains and pseudo-domains
 role system_r;
 role system_r types { xen_type domain_type };
+# If you want to prevent domUs from being placed in system_r:
+##role system_r types { xen_type dom0_t };
+
+# The vm role is used for customer virtual machines
+role vm_r;
+role vm_r types { domain_type -dom0_t };
diff --git a/tools/flask/policy/policy/users b/tools/flask/policy/policy/users
index a0205e5..35ed8a9 100644
--- a/tools/flask/policy/policy/users
+++ b/tools/flask/policy/policy/users
@@ -3,15 +3,9 @@
 # System User configuration.
 #
 
-#
-# gen_user(username, role_set, mls_defaultlevel, mls_range)
-#
-
-#
-# system_u is the user identity for system processes and objects.
-# There should be no corresponding Unix user identity for system,
-# and a user process should never be assigned the system user
-# identity.
-#
+# system_u is the user identity for system domains and objects
 gen_user(system_u,, system_r, s0, s0 - mls_systemhigh)
 
+# Other users are defined using the vm role
+gen_user(customer_1,, vm_r, s0, s0)
+gen_user(customer_2,, vm_r, s0, s0)
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDq-0008H0-O0; Tue, 31 Jan 2012 21:26: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 1RsLDo-0008FR-CL
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328045189!10975360!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3626 invoked from network); 31 Jan 2012 21:26:29 -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;
	31 Jan 2012 21:26:29 -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
	q0VLQSPV014716
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa1006185; 
	Tue, 31 Jan 2012 16:26:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:12 -0500
Message-Id: <1328045178-30665-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/10] xsm: Add xsm_map_domain_pirq hook
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 checking permissions in map_domain_pirq, the msi_desc field of the
irq_desc is not yet populated with the PCI device being used. Pass in
the msi_info structure which contains the intended PCI device whose
label will be used in the security check.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/irq.c    |    2 +-
 xen/include/xsm/xsm.h |    6 ++++++
 xen/xsm/dummy.c       |    6 ++++++
 xen/xsm/flask/hooks.c |   37 +++++++++++++++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 6d17ec0..bbcfa09 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1828,7 +1828,7 @@ int map_domain_pirq(
         return 0;
     }
 
-    ret = xsm_irq_permission(d, irq, 1);
+    ret = xsm_map_domain_pirq(d, irq, data);
     if ( ret )
     {
         dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6e3a8f0..e896f73 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -115,6 +115,7 @@ struct xsm_operations {
     int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
 
     char *(*show_irq_sid) (int irq);
+    int (*map_domain_pirq) (struct domain *d, int irq, void *data);
     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);
@@ -484,6 +485,11 @@ static inline char *xsm_show_irq_sid (int irq)
     return xsm_call(show_irq_sid(irq));
 }
 
+static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
+{
+    return xsm_call(map_domain_pirq(d, irq, data));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 83e5dba..7027ee7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -375,6 +375,11 @@ static char *dummy_show_irq_sid (int irq)
     return NULL;
 }
 
+static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
+{
+    return 0;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -660,6 +665,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, schedop_shutdown);
 
     set_to_dummy_if_null(ops, show_irq_sid);
+    set_to_dummy_if_null(ops, map_domain_pirq);
     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);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0dbf19d..a095915 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -757,6 +757,42 @@ static char *flask_show_irq_sid (int irq)
     return ctx;
 }
 
+static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
+{
+    u32 sid;
+    int rc = -EPERM;
+    struct msi_info *msi = data;
+
+    struct domain_security_struct *ssec, *tsec;
+    struct avc_audit_data ad;
+
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+
+    if ( rc )
+        return rc;
+
+    if ( irq >= nr_irqs_gsi && msi ) {
+        u32 machine_bdf = (msi->seg << 16) | (msi->bus << 8) | msi->devfn;
+        AVC_AUDIT_DATA_INIT(&ad, DEV);
+        ad.device = machine_bdf;
+        rc = security_device_sid(machine_bdf, &sid);
+    } else {
+        rc = get_irq_sid(irq, &sid, &ad);
+    }
+    if ( rc )
+        return rc;
+
+    ssec = current->domain->ssid;
+    tsec = d->ssid;
+
+    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
+    if ( rc )
+        return rc;
+
+    rc = avc_has_perm(tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return rc;
+}
+
 static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
 {
     u32 perm;
@@ -1582,6 +1618,7 @@ static struct xsm_operations flask_ops = {
 
     .show_irq_sid = flask_show_irq_sid,
 
+    .map_domain_pirq = flask_map_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDs-0008Hc-2j; Tue, 31 Jan 2012 21:26:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsLDp-0008FZ-Lz
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328045190!9375311!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11144 invoked from network); 31 Jan 2012 21:26:30 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 21:26:30 -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
	q0VLQTPV014725
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0VLQQa5006185; 
	Tue, 31 Jan 2012 16:26:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:16 -0500
Message-Id: <1328045178-30665-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/10] flask/policy: Policy build 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

Eliminate temporary files used in creating FLASK policy to improve error
reporting during policy build. Syntax errors now point to the file and
line number visible to the user, not the intermediate temporary file.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/Makefile                  |   61 +++----------------------
 tools/flask/policy/policy/initial_sids       |   12 +++++
 tools/flask/policy/policy/modules/xen/xen.te |   10 ----
 3 files changed, 20 insertions(+), 63 deletions(-)
 create mode 100644 tools/flask/policy/policy/initial_sids

diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index a27c813..5c25cbe 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -102,9 +102,8 @@ else
 	POLVER +=$(NAME).$(PV)
 endif
 
-
-# determine the policy version and current kernel version if possible
-M4PARAM += -D mls_num_sens=$(MLS_SENS) -D mls_num_cats=$(MLS_CATS) -D hide_broken_symptoms
+# Always define these because they are referenced even in non-MLS policy
+M4PARAM += -D mls_num_sens=$(MLS_SENS) -D mls_num_cats=$(MLS_CATS)
 
 M4SUPPORT = $(wildcard $(POLDIR)/support/*.spt)
 
@@ -126,9 +125,9 @@ ALL_INTERFACES := $(ALL_MODULES:.te=.if)
 ALL_TE_FILES := $(ALL_MODULES)
 
 PRE_TE_FILES := $(SECCLASS) $(ISIDS) $(AVS) $(M4SUPPORT) $(POLDIR)/mls 
-POST_TE_FILES := $(POLDIR)/users $(POLDIR)/constraints
+POST_TE_FILES := $(POLDIR)/users $(POLDIR)/constraints $(POLDIR)/initial_sids
 
-POLICY_SECTIONS := tmp/pre_te_files.conf tmp/all_interfaces.conf tmp/all_attrs_types.conf $(GLOBALBOOL) $(GLOBALTUN) tmp/only_te_rules.conf tmp/all_post.conf
+POLICY_SECTIONS := $(PRE_TE_FILES) $(ALL_INTERFACES) $(GLOBALBOOL) $(GLOBALTUN) $(ALL_TE_FILES) $(POST_TE_FILES)
 
 ########################################
 #
@@ -140,7 +139,7 @@ policy: $(POLVER)
 
 install: $(LOADPATH)
 
-load: tmp/load
+load: .load_stamp
 
 ########################################
 #
@@ -166,11 +165,11 @@ $(LOADPATH): policy.conf
 #
 # Load the binary policy
 #
-tmp/load: reload
-reload: $(LOADPATH) $(FCPATH)
+.load_stamp: reload
+reload: $(LOADPATH)
 	@echo "Loading $(NAME) $(LOADPATH)"
 	$(QUIET) $(LOADPOLICY) $(LOADPATH)
-	@touch tmp/load
+	@touch .load_stamp
 
 ########################################
 #
@@ -181,50 +180,6 @@ policy.conf: $(POLICY_SECTIONS)
 # checkpolicy can use the #line directives provided by -s for error reporting:
 	$(QUIET) m4 -D self_contained_policy $(M4PARAM) -s $^ > $@
 
-tmp/pre_te_files.conf: $(PRE_TE_FILES)
-	@test -d tmp || mkdir -p tmp
-	$(QUIET) cat $^ > $@
-
-tmp/all_interfaces.conf: $(M4SUPPORT) $(ALL_INTERFACES)
-ifeq ($(ALL_INTERFACES),)
-	$(error No enabled modules! $(notdir $(MOD_CONF)) please create a modules.conf file)
-endif
-	@test -d tmp || mkdir -p tmp
-	$(QUIET) cat $^ | sed -e s/dollarsstar/\$$\*/g > $@
-
-tmp/all_te_files.conf: $(ALL_TE_FILES)
-ifeq ($(ALL_TE_FILES),)
-	$(error No enabled modules! $(notdir $(MOD_CONF)) please create a modules.conf file)
-endif
-	@test -d tmp || mkdir -p tmp
-	$(QUIET) cat $^ > $@
-
-tmp/post_te_files.conf: $(POST_TE_FILES)
-	@test -d tmp || mkdir -p tmp
-	$(QUIET) cat $^ > $@
-
-# extract attributes and put them first. extract post te stuff
-# like genfscon and put last.  portcon, nodecon, and netifcon
-# is delayed since they are generated by m4
-tmp/all_attrs_types.conf tmp/all_post.conf: tmp/only_te_rules.conf
-tmp/only_te_rules.conf: tmp/all_te_files.conf tmp/post_te_files.conf
-	$(QUIET) grep ^attribute tmp/all_te_files.conf > tmp/all_attrs_types.conf || true
-	$(QUIET) grep '^type ' tmp/all_te_files.conf >> tmp/all_attrs_types.conf
-	$(QUIET) cat tmp/post_te_files.conf > tmp/all_post.conf
-	$(QUIET) grep '^sid ' tmp/all_te_files.conf >> tmp/all_post.conf || true
-	$(QUIET) grep ^pirqcon tmp/all_te_files.conf >> \
-                      tmp/all_post.conf || true
-	$(QUIET) grep ^ioportcon tmp/all_te_files.conf >> \
-                      tmp/all_post.conf || true
-	$(QUIET) grep ^iomemcon tmp/all_te_files.conf >> \
-                      tmp/all_post.conf || true
-	$(QUIET) grep ^pcidevicecon tmp/all_te_files.conf >> \
-                      tmp/all_post.conf || true
-	$(QUIET) sed -r -e /^attribute/d -e '/^type /d' -e '/^sid /d' \
-                     -e "/^pirqcon/d" -e "/^pcidevicecon/d" -e "/^ioportcon/d" \
-                     -e "/^iomemcon/d" < tmp/all_te_files.conf \
-                     > tmp/only_te_rules.conf
-
 ########################################
 #
 # Remove the dontaudit rules from the policy.conf
diff --git a/tools/flask/policy/policy/initial_sids b/tools/flask/policy/policy/initial_sids
new file mode 100644
index 0000000..b70a54e
--- /dev/null
+++ b/tools/flask/policy/policy/initial_sids
@@ -0,0 +1,12 @@
+# Labels for initial SIDs
+
+sid xen gen_context(system_u:system_r:xen_t,s0)
+sid dom0 gen_context(system_u:system_r:dom0_t,s0)
+sid domxen gen_context(system_u:system_r:domxen_t,s0)
+sid domio gen_context(system_u:system_r:domio_t,s0)
+sid unlabeled gen_context(system_u:system_r:unlabeled_t,s0)
+sid security gen_context(system_u:system_r:security_t,s0)
+sid irq gen_context(system_u:object_r:irq_t,s0)
+sid iomem gen_context(system_u:object_r:iomem_t,s0)
+sid ioport gen_context(system_u:object_r:ioport_t,s0)
+sid device gen_context(system_u:object_r:device_t,s0)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index c5e0883..ac52c3f 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -162,16 +162,6 @@ 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)
-sid dom0 gen_context(system_u:system_r:dom0_t,s0)
-sid domxen gen_context(system_u:system_r:domxen_t,s0)
-sid domio gen_context(system_u:system_r:domio_t,s0)
-sid unlabeled gen_context(system_u:system_r:unlabeled_t,s0)
-sid security gen_context(system_u:system_r:security_t,s0)
-sid irq gen_context(system_u:object_r:irq_t,s0)
-sid iomem gen_context(system_u:object_r:iomem_t,s0)
-sid ioport gen_context(system_u:object_r:ioport_t,s0)
-sid device gen_context(system_u:object_r:device_t,s0)
 
 role system_r;
 role system_r types { xen_type domain_type };
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDs-0008Hc-2j; Tue, 31 Jan 2012 21:26:40 +0000
Received: from mail21.messagelabs.com ([85.158.143.35])
	by lists.xen.org with smtp (Exim 4.72)
	(envelope-from <dgdegra@tycho.nsa.gov>) id 1RsLDp-0008FZ-Lz
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:37 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-7.tower-21.messagelabs.com!1328045190!9375311!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11144 invoked from network); 31 Jan 2012 21:26:30 -0000
Received: from msux-gh1-uea01.nsa.gov (HELO msux-gh1-uea01.nsa.gov)
	(63.239.65.39) by server-7.tower-21.messagelabs.com with SMTP;
	31 Jan 2012 21:26:30 -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
	q0VLQTPV014725
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:29 GMT
Received: from moss-nexus.epoch.ncsc.mil (moss-nexus [144.51.25.48])
	by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id q0VLQQa5006185; 
	Tue, 31 Jan 2012 16:26:28 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:16 -0500
Message-Id: <1328045178-30665-9-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 08/10] flask/policy: Policy build 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

Eliminate temporary files used in creating FLASK policy to improve error
reporting during policy build. Syntax errors now point to the file and
line number visible to the user, not the intermediate temporary file.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 tools/flask/policy/Makefile                  |   61 +++----------------------
 tools/flask/policy/policy/initial_sids       |   12 +++++
 tools/flask/policy/policy/modules/xen/xen.te |   10 ----
 3 files changed, 20 insertions(+), 63 deletions(-)
 create mode 100644 tools/flask/policy/policy/initial_sids

diff --git a/tools/flask/policy/Makefile b/tools/flask/policy/Makefile
index a27c813..5c25cbe 100644
--- a/tools/flask/policy/Makefile
+++ b/tools/flask/policy/Makefile
@@ -102,9 +102,8 @@ else
 	POLVER +=$(NAME).$(PV)
 endif
 
-
-# determine the policy version and current kernel version if possible
-M4PARAM += -D mls_num_sens=$(MLS_SENS) -D mls_num_cats=$(MLS_CATS) -D hide_broken_symptoms
+# Always define these because they are referenced even in non-MLS policy
+M4PARAM += -D mls_num_sens=$(MLS_SENS) -D mls_num_cats=$(MLS_CATS)
 
 M4SUPPORT = $(wildcard $(POLDIR)/support/*.spt)
 
@@ -126,9 +125,9 @@ ALL_INTERFACES := $(ALL_MODULES:.te=.if)
 ALL_TE_FILES := $(ALL_MODULES)
 
 PRE_TE_FILES := $(SECCLASS) $(ISIDS) $(AVS) $(M4SUPPORT) $(POLDIR)/mls 
-POST_TE_FILES := $(POLDIR)/users $(POLDIR)/constraints
+POST_TE_FILES := $(POLDIR)/users $(POLDIR)/constraints $(POLDIR)/initial_sids
 
-POLICY_SECTIONS := tmp/pre_te_files.conf tmp/all_interfaces.conf tmp/all_attrs_types.conf $(GLOBALBOOL) $(GLOBALTUN) tmp/only_te_rules.conf tmp/all_post.conf
+POLICY_SECTIONS := $(PRE_TE_FILES) $(ALL_INTERFACES) $(GLOBALBOOL) $(GLOBALTUN) $(ALL_TE_FILES) $(POST_TE_FILES)
 
 ########################################
 #
@@ -140,7 +139,7 @@ policy: $(POLVER)
 
 install: $(LOADPATH)
 
-load: tmp/load
+load: .load_stamp
 
 ########################################
 #
@@ -166,11 +165,11 @@ $(LOADPATH): policy.conf
 #
 # Load the binary policy
 #
-tmp/load: reload
-reload: $(LOADPATH) $(FCPATH)
+.load_stamp: reload
+reload: $(LOADPATH)
 	@echo "Loading $(NAME) $(LOADPATH)"
 	$(QUIET) $(LOADPOLICY) $(LOADPATH)
-	@touch tmp/load
+	@touch .load_stamp
 
 ########################################
 #
@@ -181,50 +180,6 @@ policy.conf: $(POLICY_SECTIONS)
 # checkpolicy can use the #line directives provided by -s for error reporting:
 	$(QUIET) m4 -D self_contained_policy $(M4PARAM) -s $^ > $@
 
-tmp/pre_te_files.conf: $(PRE_TE_FILES)
-	@test -d tmp || mkdir -p tmp
-	$(QUIET) cat $^ > $@
-
-tmp/all_interfaces.conf: $(M4SUPPORT) $(ALL_INTERFACES)
-ifeq ($(ALL_INTERFACES),)
-	$(error No enabled modules! $(notdir $(MOD_CONF)) please create a modules.conf file)
-endif
-	@test -d tmp || mkdir -p tmp
-	$(QUIET) cat $^ | sed -e s/dollarsstar/\$$\*/g > $@
-
-tmp/all_te_files.conf: $(ALL_TE_FILES)
-ifeq ($(ALL_TE_FILES),)
-	$(error No enabled modules! $(notdir $(MOD_CONF)) please create a modules.conf file)
-endif
-	@test -d tmp || mkdir -p tmp
-	$(QUIET) cat $^ > $@
-
-tmp/post_te_files.conf: $(POST_TE_FILES)
-	@test -d tmp || mkdir -p tmp
-	$(QUIET) cat $^ > $@
-
-# extract attributes and put them first. extract post te stuff
-# like genfscon and put last.  portcon, nodecon, and netifcon
-# is delayed since they are generated by m4
-tmp/all_attrs_types.conf tmp/all_post.conf: tmp/only_te_rules.conf
-tmp/only_te_rules.conf: tmp/all_te_files.conf tmp/post_te_files.conf
-	$(QUIET) grep ^attribute tmp/all_te_files.conf > tmp/all_attrs_types.conf || true
-	$(QUIET) grep '^type ' tmp/all_te_files.conf >> tmp/all_attrs_types.conf
-	$(QUIET) cat tmp/post_te_files.conf > tmp/all_post.conf
-	$(QUIET) grep '^sid ' tmp/all_te_files.conf >> tmp/all_post.conf || true
-	$(QUIET) grep ^pirqcon tmp/all_te_files.conf >> \
-                      tmp/all_post.conf || true
-	$(QUIET) grep ^ioportcon tmp/all_te_files.conf >> \
-                      tmp/all_post.conf || true
-	$(QUIET) grep ^iomemcon tmp/all_te_files.conf >> \
-                      tmp/all_post.conf || true
-	$(QUIET) grep ^pcidevicecon tmp/all_te_files.conf >> \
-                      tmp/all_post.conf || true
-	$(QUIET) sed -r -e /^attribute/d -e '/^type /d' -e '/^sid /d' \
-                     -e "/^pirqcon/d" -e "/^pcidevicecon/d" -e "/^ioportcon/d" \
-                     -e "/^iomemcon/d" < tmp/all_te_files.conf \
-                     > tmp/only_te_rules.conf
-
 ########################################
 #
 # Remove the dontaudit rules from the policy.conf
diff --git a/tools/flask/policy/policy/initial_sids b/tools/flask/policy/policy/initial_sids
new file mode 100644
index 0000000..b70a54e
--- /dev/null
+++ b/tools/flask/policy/policy/initial_sids
@@ -0,0 +1,12 @@
+# Labels for initial SIDs
+
+sid xen gen_context(system_u:system_r:xen_t,s0)
+sid dom0 gen_context(system_u:system_r:dom0_t,s0)
+sid domxen gen_context(system_u:system_r:domxen_t,s0)
+sid domio gen_context(system_u:system_r:domio_t,s0)
+sid unlabeled gen_context(system_u:system_r:unlabeled_t,s0)
+sid security gen_context(system_u:system_r:security_t,s0)
+sid irq gen_context(system_u:object_r:irq_t,s0)
+sid iomem gen_context(system_u:object_r:iomem_t,s0)
+sid ioport gen_context(system_u:object_r:ioport_t,s0)
+sid device gen_context(system_u:object_r:device_t,s0)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index c5e0883..ac52c3f 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -162,16 +162,6 @@ 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)
-sid dom0 gen_context(system_u:system_r:dom0_t,s0)
-sid domxen gen_context(system_u:system_r:domxen_t,s0)
-sid domio gen_context(system_u:system_r:domio_t,s0)
-sid unlabeled gen_context(system_u:system_r:unlabeled_t,s0)
-sid security gen_context(system_u:system_r:security_t,s0)
-sid irq gen_context(system_u:object_r:irq_t,s0)
-sid iomem gen_context(system_u:object_r:iomem_t,s0)
-sid ioport gen_context(system_u:object_r:ioport_t,s0)
-sid device gen_context(system_u:object_r:device_t,s0)
 
 role system_r;
 role system_r types { xen_type domain_type };
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:27:05 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21: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 1RsLDq-0008H0-O0; Tue, 31 Jan 2012 21:26: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 1RsLDo-0008FR-CL
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:26:36 +0000
X-Env-Sender: dgdegra@tycho.nsa.gov
X-Msg-Ref: server-8.tower-21.messagelabs.com!1328045189!10975360!1
X-Originating-IP: [63.239.65.39]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3626 invoked from network); 31 Jan 2012 21:26:29 -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;
	31 Jan 2012 21:26:29 -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
	q0VLQSPV014716
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 21:26:28 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 q0VLQQa1006185; 
	Tue, 31 Jan 2012 16:26:27 -0500
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: xen-devel@lists.xensource.com
Date: Tue, 31 Jan 2012 16:26:12 -0500
Message-Id: <1328045178-30665-5-git-send-email-dgdegra@tycho.nsa.gov>
X-Mailer: git-send-email 1.7.7.6
In-Reply-To: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
References: <1328045178-30665-1-git-send-email-dgdegra@tycho.nsa.gov>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: [Xen-devel] [PATCH 04/10] xsm: Add xsm_map_domain_pirq hook
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
MIME-Version: 1.0
Content-Type: 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 checking permissions in map_domain_pirq, the msi_desc field of the
irq_desc is not yet populated with the PCI device being used. Pass in
the msi_info structure which contains the intended PCI device whose
label will be used in the security check.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
---
 xen/arch/x86/irq.c    |    2 +-
 xen/include/xsm/xsm.h |    6 ++++++
 xen/xsm/dummy.c       |    6 ++++++
 xen/xsm/flask/hooks.c |   37 +++++++++++++++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 6d17ec0..bbcfa09 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1828,7 +1828,7 @@ int map_domain_pirq(
         return 0;
     }
 
-    ret = xsm_irq_permission(d, irq, 1);
+    ret = xsm_map_domain_pirq(d, irq, data);
     if ( ret )
     {
         dprintk(XENLOG_G_ERR, "dom%d: could not permit access to irq %d mapping to pirq %d\n",
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 6e3a8f0..e896f73 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -115,6 +115,7 @@ struct xsm_operations {
     int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
 
     char *(*show_irq_sid) (int irq);
+    int (*map_domain_pirq) (struct domain *d, int irq, void *data);
     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);
@@ -484,6 +485,11 @@ static inline char *xsm_show_irq_sid (int irq)
     return xsm_call(show_irq_sid(irq));
 }
 
+static inline int xsm_map_domain_pirq (struct domain *d, int irq, void *data)
+{
+    return xsm_call(map_domain_pirq(d, irq, data));
+}
+
 static inline int xsm_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return xsm_call(irq_permission(d, pirq, allow));
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 83e5dba..7027ee7 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -375,6 +375,11 @@ static char *dummy_show_irq_sid (int irq)
     return NULL;
 }
 
+static int dummy_map_domain_pirq (struct domain *d, int irq, void *data)
+{
+    return 0;
+}
+
 static int dummy_irq_permission (struct domain *d, int pirq, uint8_t allow)
 {
     return 0;
@@ -660,6 +665,7 @@ void xsm_fixup_ops (struct xsm_operations *ops)
     set_to_dummy_if_null(ops, schedop_shutdown);
 
     set_to_dummy_if_null(ops, show_irq_sid);
+    set_to_dummy_if_null(ops, map_domain_pirq);
     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);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 0dbf19d..a095915 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -757,6 +757,42 @@ static char *flask_show_irq_sid (int irq)
     return ctx;
 }
 
+static int flask_map_domain_pirq (struct domain *d, int irq, void *data)
+{
+    u32 sid;
+    int rc = -EPERM;
+    struct msi_info *msi = data;
+
+    struct domain_security_struct *ssec, *tsec;
+    struct avc_audit_data ad;
+
+    rc = domain_has_perm(current->domain, d, SECCLASS_RESOURCE, RESOURCE__ADD);
+
+    if ( rc )
+        return rc;
+
+    if ( irq >= nr_irqs_gsi && msi ) {
+        u32 machine_bdf = (msi->seg << 16) | (msi->bus << 8) | msi->devfn;
+        AVC_AUDIT_DATA_INIT(&ad, DEV);
+        ad.device = machine_bdf;
+        rc = security_device_sid(machine_bdf, &sid);
+    } else {
+        rc = get_irq_sid(irq, &sid, &ad);
+    }
+    if ( rc )
+        return rc;
+
+    ssec = current->domain->ssid;
+    tsec = d->ssid;
+
+    rc = avc_has_perm(ssec->sid, sid, SECCLASS_RESOURCE, RESOURCE__ADD_IRQ, &ad);
+    if ( rc )
+        return rc;
+
+    rc = avc_has_perm(tsec->sid, sid, SECCLASS_RESOURCE, RESOURCE__USE, &ad);
+    return rc;
+}
+
 static int flask_irq_permission (struct domain *d, int irq, uint8_t access)
 {
     u32 perm;
@@ -1582,6 +1618,7 @@ static struct xsm_operations flask_ops = {
 
     .show_irq_sid = flask_show_irq_sid,
 
+    .map_domain_pirq = flask_map_domain_pirq,
     .irq_permission = flask_irq_permission,
     .iomem_permission = flask_iomem_permission,
     .pci_config_permission = flask_pci_config_permission,
-- 
1.7.7.6


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:42:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21:42:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsLTD-0001WA-K1; Tue, 31 Jan 2012 21:42:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1RsLTB-0001W5-R4
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:42:30 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328046109!50544617!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2839 invoked from network); 31 Jan 2012 21:41:51 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 21:41:51 -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=PHgKgsDGKL0PRCSAbZL2YaUhS
	NE=; b=xe7kV2zeAJ8Alt1fUD5da3VjLSL9gkxQ6003Louod/k1IDlpAZ6CbmVZq
	OP7/TiVkNyyQwANPX2sNiQpGjak/bOF9Qzc0Jfv9tWvnpgQj/hVgscayl+1jZDTf
	aT2wRjwRrFt+PmC8Pz2rZRKHlwGm5LfDNKB6uWANAp4Ag2aXQo=
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=xqExcX/FhV6nm97iCux
	w2McsYMHUqgmDz72KK+lM5uND03QWn+iFsYi5xvldvZ83RdpR80JZUoW9zlTqs72
	KCnp5Vc0RZHqksW7Kghz8rJVATKZRVIlAhWm4ZgGXP0iETM5S6rkYGC8o3fmv92F
	Uu8W5bBUN06ELdAPJvtrcaKI=
Received: (qmail 19790 invoked from network); 31 Jan 2012 21:42:25 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gossamer-threads.com@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	31 Jan 2012 21:42:25 -0000
Message-ID: <4F28603F.8010900@gt.net>
Date: Tue, 31 Jan 2012 13:42:23 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Crashing / unable to start domUs due to high number of
	luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi All,

We've got a xen setup based around a dell iscsi device with each xen 
host having 2 lun's, we then run multipath on top of that. After adding 
a couple new virtual disks the other day, a couple of our online stable 
VM's suddenly hard locked up. Attaching to the console gave me nothing, 
looked like they lost their disk devices.

Attempting to restart them on the same dom0 failed with hot plug errors, 
as did attempting to start them on a few different dom0's. After doing a 
"multipath -F" to remove unused devices and manually bringing in just 
the selected LUN's via "multipath diskname", I was able to successfully 
start them. This initially made me think perhaps I was hitting some sort 
of udev / multipath / iscsi device lun limit (136 luns, 8 paths per lun 
= 1088 iscsi connections). Just to be clear, the problem occurred on 
multiple dom0's at the same time so it definitely seems iscsi related.

Now, a day later, I'm debugging this further and I'm again unable to 
start VM's, even with all extra multipath devices removed. I rebooted 
one of the dom0's and was able to successfully migrate our production 
VM's off a broken server, so I've now got an empty dom0 that's unable to 
start any vm's.

Starting a VM results in the following in xend.log:

[2012-01-31 13:06:16 12353] DEBUG (DevController:144) Waiting for 0.
[2012-01-31 13:06:16 12353] DEBUG (DevController:628) 
hotplugStatusCallback /local/domain/0/backend/vif/35/0/hotplug-status.
[2012-01-31 13:07:56 12353] ERROR (SrvBase:88) Request wait_for_devices 
failed.
Traceback (most recent call last):
   File "/usr/lib64/python2.6/site-packages/xen/web/SrvBase.py", line 
85, in perform
     return op_method(op, req)
   File 
"/usr/lib64/python2.6/site-packages/xen/xend/server/SrvDomain.py", line 
85, in op_wait_for_devices
     return self.dom.waitForDevices()
   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", 
line 1237, in waitForDevices
     self.getDeviceController(devclass).waitForDevices()
   File 
"/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py", 
line 140, in waitForDevices
     return map(self.waitForDevice, self.deviceIDs())
   File 
"/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py", 
line 155, in waitForDevice
     (devid, self.deviceClass))
VmError: Device 0 (vif) could not be connected. Hotplug scripts not working.
[2012-01-31 13:07:56 12353] DEBUG (XendDomainInfo:3071) 
XendDomainInfo.destroy: domid=35
[2012-01-31 13:07:58 12353] DEBUG (XendDomainInfo:2401) Destroying 
device model

I tried turning up udev's log level but that didn't reveal anything. 
Reading the xenstore for the vif doesn't show anything unusual either:

ukxen1 ~ # xenstore-ls /local/domain/0/backend/vif/35
0 = ""
  bridge = "vlan91"
  domain = "nathanxenuk1"
  handle = "0"
  uuid = "2128d0b7-d50f-c2ad-4243-8a42bb598b81"
  script = "/etc/xen/scripts/vif-bridge"
  state = "1"
  frontend = "/local/domain/35/device/vif/0"
  mac = "00:16:3d:03:00:44"
  online = "1"
  frontend-id = "35"

The bridge device (vlan91) exists, trying a different bridge doesn't 
matter. Removing the VIF completely results in the same error for the 
VBD. Adding debugging to the hotplug/network scripts didn't reveal 
anything, it looks like they aren't even being executed yet. Nothing is 
logged to xen-hotplug.log.

The only thing I can think of that this may be related to, is gentoo 
defaulted to a 10mb /dev which we filled up a few months back. We upped 
the size to 50mb in the mount options and everything's been completely 
stable since (~33 days). None of the /dev on the dom0's is higher than 
25% usage. Asides from adding the new luns, no changes have been made in 
the past month.

To try and test if removing some devices would solve anything, I tried 
doing an "iscsiadm -m node --logout" and it promptly hard locked the 
entire box. After a reboot, I was unable to reproduce the problem on 
that particular dom0.

I've still got 1 dom0 that's exhibiting the problem, if anyone is able 
to suggest any further debugging steps?

- Nathan


(XEN) Xen version 4.1.1 (root@) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, 
pie-10.1.5) ) Mon Aug 29 16:24:12 PDT 2011

ukxen1 xen # xm info
host                   : ukxen1
release                : 3.0.3
version                : #4 SMP Thu Dec 22 12:44:22 PST 2011
machine                : x86_64
nr_cpus                : 24
nr_nodes               : 2
cores_per_socket       : 6
threads_per_core       : 2
cpu_mhz                : 2261
hw_caps                : 
bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 98291
free_memory            : 91908
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : console=vga dom0_mem=1024M dom0_max_vcpus=1 
dom0_vcpus_pin=true
cc_compiler            : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5)
cc_compile_by          : root
cc_compile_domain      :
cc_compile_date        : Mon Aug 29 16:24:12 PDT 2011
xend_config_format     : 4



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:42:49 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21:42:49 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsLTD-0001WA-K1; Tue, 31 Jan 2012 21:42:31 +0000
Received: from mail27.messagelabs.com ([193.109.254.147])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <nathan@gt.net>) id 1RsLTB-0001W5-R4
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:42:30 +0000
X-Env-Sender: nathan@gt.net
X-Msg-Ref: server-12.tower-27.messagelabs.com!1328046109!50544617!1
X-Originating-IP: [208.70.244.21]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2839 invoked from network); 31 Jan 2012 21:41:51 -0000
Received: from gossamer.nmsrv.com (HELO gossamer.nmsrv.com) (208.70.244.21)
	by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 21:41:51 -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=PHgKgsDGKL0PRCSAbZL2YaUhS
	NE=; b=xe7kV2zeAJ8Alt1fUD5da3VjLSL9gkxQ6003Louod/k1IDlpAZ6CbmVZq
	OP7/TiVkNyyQwANPX2sNiQpGjak/bOF9Qzc0Jfv9tWvnpgQj/hVgscayl+1jZDTf
	aT2wRjwRrFt+PmC8Pz2rZRKHlwGm5LfDNKB6uWANAp4Ag2aXQo=
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=xqExcX/FhV6nm97iCux
	w2McsYMHUqgmDz72KK+lM5uND03QWn+iFsYi5xvldvZ83RdpR80JZUoW9zlTqs72
	KCnp5Vc0RZHqksW7Kghz8rJVATKZRVIlAhWm4ZgGXP0iETM5S6rkYGC8o3fmv92F
	Uu8W5bBUN06ELdAPJvtrcaKI=
Received: (qmail 19790 invoked from network); 31 Jan 2012 21:42:25 -0000
X-AntiVirus: Clean
Received: from gateway.gossamer-threads.com (HELO ?192.168.1.152?)
	(nathan@gossamer-threads.com@208.70.247.145)
	by gossamer.nmsrv.com with ESMTPSA (DHE-RSA-CAMELLIA256-SHA encrypted);
	31 Jan 2012 21:42:25 -0000
Message-ID: <4F28603F.8010900@gt.net>
Date: Tue, 31 Jan 2012 13:42:23 -0800
From: Nathan March <nathan@gt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: [Xen-devel] Crashing / unable to start domUs due to high number of
	luns?
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

Hi All,

We've got a xen setup based around a dell iscsi device with each xen 
host having 2 lun's, we then run multipath on top of that. After adding 
a couple new virtual disks the other day, a couple of our online stable 
VM's suddenly hard locked up. Attaching to the console gave me nothing, 
looked like they lost their disk devices.

Attempting to restart them on the same dom0 failed with hot plug errors, 
as did attempting to start them on a few different dom0's. After doing a 
"multipath -F" to remove unused devices and manually bringing in just 
the selected LUN's via "multipath diskname", I was able to successfully 
start them. This initially made me think perhaps I was hitting some sort 
of udev / multipath / iscsi device lun limit (136 luns, 8 paths per lun 
= 1088 iscsi connections). Just to be clear, the problem occurred on 
multiple dom0's at the same time so it definitely seems iscsi related.

Now, a day later, I'm debugging this further and I'm again unable to 
start VM's, even with all extra multipath devices removed. I rebooted 
one of the dom0's and was able to successfully migrate our production 
VM's off a broken server, so I've now got an empty dom0 that's unable to 
start any vm's.

Starting a VM results in the following in xend.log:

[2012-01-31 13:06:16 12353] DEBUG (DevController:144) Waiting for 0.
[2012-01-31 13:06:16 12353] DEBUG (DevController:628) 
hotplugStatusCallback /local/domain/0/backend/vif/35/0/hotplug-status.
[2012-01-31 13:07:56 12353] ERROR (SrvBase:88) Request wait_for_devices 
failed.
Traceback (most recent call last):
   File "/usr/lib64/python2.6/site-packages/xen/web/SrvBase.py", line 
85, in perform
     return op_method(op, req)
   File 
"/usr/lib64/python2.6/site-packages/xen/xend/server/SrvDomain.py", line 
85, in op_wait_for_devices
     return self.dom.waitForDevices()
   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", 
line 1237, in waitForDevices
     self.getDeviceController(devclass).waitForDevices()
   File 
"/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py", 
line 140, in waitForDevices
     return map(self.waitForDevice, self.deviceIDs())
   File 
"/usr/lib64/python2.6/site-packages/xen/xend/server/DevController.py", 
line 155, in waitForDevice
     (devid, self.deviceClass))
VmError: Device 0 (vif) could not be connected. Hotplug scripts not working.
[2012-01-31 13:07:56 12353] DEBUG (XendDomainInfo:3071) 
XendDomainInfo.destroy: domid=35
[2012-01-31 13:07:58 12353] DEBUG (XendDomainInfo:2401) Destroying 
device model

I tried turning up udev's log level but that didn't reveal anything. 
Reading the xenstore for the vif doesn't show anything unusual either:

ukxen1 ~ # xenstore-ls /local/domain/0/backend/vif/35
0 = ""
  bridge = "vlan91"
  domain = "nathanxenuk1"
  handle = "0"
  uuid = "2128d0b7-d50f-c2ad-4243-8a42bb598b81"
  script = "/etc/xen/scripts/vif-bridge"
  state = "1"
  frontend = "/local/domain/35/device/vif/0"
  mac = "00:16:3d:03:00:44"
  online = "1"
  frontend-id = "35"

The bridge device (vlan91) exists, trying a different bridge doesn't 
matter. Removing the VIF completely results in the same error for the 
VBD. Adding debugging to the hotplug/network scripts didn't reveal 
anything, it looks like they aren't even being executed yet. Nothing is 
logged to xen-hotplug.log.

The only thing I can think of that this may be related to, is gentoo 
defaulted to a 10mb /dev which we filled up a few months back. We upped 
the size to 50mb in the mount options and everything's been completely 
stable since (~33 days). None of the /dev on the dom0's is higher than 
25% usage. Asides from adding the new luns, no changes have been made in 
the past month.

To try and test if removing some devices would solve anything, I tried 
doing an "iscsiadm -m node --logout" and it promptly hard locked the 
entire box. After a reboot, I was unable to reproduce the problem on 
that particular dom0.

I've still got 1 dom0 that's exhibiting the problem, if anyone is able 
to suggest any further debugging steps?

- Nathan


(XEN) Xen version 4.1.1 (root@) (gcc version 4.3.4 (Gentoo 4.3.4 p1.1, 
pie-10.1.5) ) Mon Aug 29 16:24:12 PDT 2011

ukxen1 xen # xm info
host                   : ukxen1
release                : 3.0.3
version                : #4 SMP Thu Dec 22 12:44:22 PST 2011
machine                : x86_64
nr_cpus                : 24
nr_nodes               : 2
cores_per_socket       : 6
threads_per_core       : 2
cpu_mhz                : 2261
hw_caps                : 
bfebfbff:2c100800:00000000:00003f40:029ee3ff:00000000:00000001:00000000
virt_caps              : hvm hvm_directio
total_memory           : 98291
free_memory            : 91908
free_cpus              : 0
xen_major              : 4
xen_minor              : 1
xen_extra              : .1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : unavailable
xen_commandline        : console=vga dom0_mem=1024M dom0_max_vcpus=1 
dom0_vcpus_pin=true
cc_compiler            : gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5)
cc_compile_by          : root
cc_compile_domain      :
cc_compile_date        : Mon Aug 29 16:24:12 PDT 2011
xend_config_format     : 4



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:54:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsLex-0001l6-6h; Tue, 31 Jan 2012 21:54:39 +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 1RsLeu-0001kt-QE
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:54:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328046868!13171152!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18428 invoked from network); 31 Jan 2012 21:54:30 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 21:54: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
	q0VLsSXF000556
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 16:54:28 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0VLsR9G000554;
	Tue, 31 Jan 2012 16:54:27 -0500
Date: Tue, 31 Jan 2012 17:54:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Pavel Mat??ja <pavel@netsafe.cz>
Message-ID: <20120131215427.GA32295@andromeda.dapyr.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
	<201201252029.12936.pavel@netsafe.cz>
	<201201252052.17845.pavel@netsafe.cz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201201252052.17845.pavel@netsafe.cz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 08:52:17PM +0100, Pavel Mat??ja wrote:
> On Wed 25. of January 2012 20:29:12 Pavel Mat??ja wrote:
> > On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > > Also, i believe you said the card you're trying to pass through is not
> > > the primary card in your host system.  If that's the case, don't use
> > > gfx_passthru or expect to get the video bios working.  The 'primary'
> > > video adapter owns certain io ports and memory areas that are consitent
> > > from machine to machine.  Also, the system will copy the vbios from the
> > > card to a location in memory (0xc0000) so it can execute at boot time.
> > > 
> > > Xen's gfx_passthru code depends on all of these factors.  As the code
> > > stands, if you use gfx_passthru on a secondary card, it will still copy
> > > the vbios from the primary card (as it simply reads memory from
> > > 0xc0000), and directly map io ports and low memory areas to those used
> > > by the primary card in the host system.  In this case the guest will
> > > almost certainly never get past executing ROMBIOS, and the host may or
> > > may not lock up or experience 'issues'.
> > 
> > This will do the trick with secondary card (replace path to VGA BIOS):
> > 
> > --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c 2012-01-25
> > 20:26:37.927654890 +0100
> > +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> > 2011-07-30 13:57:57.347396095 +0200
> > @@ -487,10 +487,10 @@
> >  {
> >      int fd;
> >      uint32_t bios_size = 0;
> > -    uint32_t start = 0;
> > +    uint32_t start = 0xC0000;
> >      uint16_t magic = 0;
> > 
> > -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> > O_RDONLY)) < 0 )

How does one "extract" the bios from the ATI cards? With NVidia I
noticed could do it via /sys/kernel/debug/dri/0/vbios.rom.

But that is not present on ATI cards. Did you instrument the radeon
driver to dump it somewhere?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 21:54:51 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 21:54:51 +0000
Received: from localhost ([127.0.0.1] helo=lists.xen.org)
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <xen-devel-bounces@lists.xensource.com>)
	id 1RsLex-0001l6-6h; Tue, 31 Jan 2012 21:54:39 +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 1RsLeu-0001kt-QE
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 21:54:37 +0000
X-Env-Sender: darnok@68k.org
X-Msg-Ref: server-10.tower-182.messagelabs.com!1328046868!13171152!1
X-Originating-IP: [206.212.254.10]
X-SpamReason: No, hits=0.0 required=7.0 tests=
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 18428 invoked from network); 31 Jan 2012 21:54:30 -0000
Received: from andromeda.dapyr.net (HELO andromeda.dapyr.net) (206.212.254.10)
	by server-10.tower-182.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 21:54: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
	q0VLsSXF000556
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 31 Jan 2012 16:54:28 -0500
Received: (from darnok@localhost)
	by andromeda.dapyr.net (8.13.4/8.13.4/Submit) id q0VLsR9G000554;
	Tue, 31 Jan 2012 16:54:27 -0500
Date: Tue, 31 Jan 2012 17:54:27 -0400
From: Konrad Rzeszutek Wilk <konrad@darnok.org>
To: Pavel Mat??ja <pavel@netsafe.cz>
Message-ID: <20120131215427.GA32295@andromeda.dapyr.net>
References: <CAFoWEVPfusbuE42T9KzZohsP_V_r1y9t_rEM3f8ee6kMxsiAmg@mail.gmail.com>
	<1327510331.2452.21.camel@mnetdjm5.mageenet.host>
	<201201252029.12936.pavel@netsafe.cz>
	<201201252052.17845.pavel@netsafe.cz>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <201201252052.17845.pavel@netsafe.cz>
User-Agent: Mutt/1.5.9i
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [Xen-users]    VGA passthough still not working
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Xen developer discussion <xen-devel.lists.xensource.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

On Wed, Jan 25, 2012 at 08:52:17PM +0100, Pavel Mat??ja wrote:
> On Wed 25. of January 2012 20:29:12 Pavel Mat??ja wrote:
> > On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > > Also, i believe you said the card you're trying to pass through is not
> > > the primary card in your host system.  If that's the case, don't use
> > > gfx_passthru or expect to get the video bios working.  The 'primary'
> > > video adapter owns certain io ports and memory areas that are consitent
> > > from machine to machine.  Also, the system will copy the vbios from the
> > > card to a location in memory (0xc0000) so it can execute at boot time.
> > > 
> > > Xen's gfx_passthru code depends on all of these factors.  As the code
> > > stands, if you use gfx_passthru on a secondary card, it will still copy
> > > the vbios from the primary card (as it simply reads memory from
> > > 0xc0000), and directly map io ports and low memory areas to those used
> > > by the primary card in the host system.  In this case the guest will
> > > almost certainly never get past executing ROMBIOS, and the host may or
> > > may not lock up or experience 'issues'.
> > 
> > This will do the trick with secondary card (replace path to VGA BIOS):
> > 
> > --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c 2012-01-25
> > 20:26:37.927654890 +0100
> > +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> > 2011-07-30 13:57:57.347396095 +0200
> > @@ -487,10 +487,10 @@
> >  {
> >      int fd;
> >      uint32_t bios_size = 0;
> > -    uint32_t start = 0;
> > +    uint32_t start = 0xC0000;
> >      uint16_t magic = 0;
> > 
> > -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> > O_RDONLY)) < 0 )

How does one "extract" the bios from the ATI cards? With NVidia I
noticed could do it via /sys/kernel/debug/dri/0/vbios.rom.

But that is not present on ATI cards. Did you instrument the radeon
driver to dump it somewhere?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

From xen-devel-bounces@lists.xensource.com Tue Jan 31 22:52:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 22: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 1RsMYj-0002Ub-4H; Tue, 31 Jan 2012 22:52:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsMYg-0002UW-Gf
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 22:52:14 +0000
Received: from [85.158.138.51:21939] by server-12.bemta-3.messagelabs.com id
	5B/74-24557-D90782F4; Tue, 31 Jan 2012 22:52:13 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328050329!11471716!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21132 invoked from network); 31 Jan 2012 22:52:11 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 22:52:11 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VMq6r2004267
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 14:52:07 -0800
Received: by bkbzv3 with SMTP id zv3so936051bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 14:52:05 -0800 (PST)
Received: by 10.204.148.84 with SMTP id o20mr11193566bkv.103.1328050325461;
	Tue, 31 Jan 2012 14:52:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 14:51:25 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
	<alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 14:51:25 -0800
Message-ID: <CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============4325662592453297858=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4325662592453297858==
Content-Type: multipart/alternative; boundary=0015175cac0ce49bc904b7dacf8f

--0015175cac0ce49bc904b7dacf8f
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 10:58 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> On Tue, 31 Jan 2012, Shriram Rajagopalan wrote:
> > Or if you have to receive them in the pagebuf, then have two pieces of
> the same state,
> >  consistent_state, curr_state, such that you do
> >
> >  pagebuf_get(curr_state)
> >  tailbuf_get(..)..
> >  if (no error so far), then
> >   copy curr_state to consistent_state.
> >   goto copypages;
> >
> > finish:
> >  ..
> >   finish_hvm:
> >      apply consistent_state.
>
> I think I am starting to understand: see appended patch if it makes
> things better.
>
>
Instead of adding yet another parameter to pagebuf_get_one, you could
simplify the patch by adding a toolstack_data_t field to the pagebuf struct.
See comments below.



> ---
>
> diff --git a/tools/libxc/xc_domain_restore.c
> b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..02b523d 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -684,6 +684,11 @@ typedef struct {
>     uint64_t vm_generationid_addr;
>  } pagebuf_t;
>
> +struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+

Add an instance of this struct to the pagebuf_t structure
(gets initialized to NULL, by pagebuf_init)

and dont forget to add the appropriate free calls to pagebuf_free.


>   static int pagebuf_init(pagebuf_t* buf)
>  {
>     memset(buf, 0, sizeof(*buf));
> @@ -703,7 +708,8 @@ static void pagebuf_free(pagebuf_t* buf)
>  }
>
>  static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
> -                           pagebuf_t* buf, int fd, uint32_t dom)
> +                           pagebuf_t* buf, int fd, uint32_t dom,
> +                           struct toolstack_data_t *tdata)
>

Eliminate the extra arg. and all the fixes to pagebuf_get_one() calls.

 +        {
> +    case XC_SAVE_ID_TOOLSTACK:
> +            RDEXACT(fd, &tdata->len, sizeof(tdata->len));
> +            tdata->data = (uint8_t*) realloc(tdata->data, tdata->len);
> +            if ( tdata->data == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, tdata->data, tdata->len);
> +            return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
> +        }
>
>
RDEXACT(fd, &buf->tdata->len, sizeof())
...

@@ -1262,7 +1282,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
>                       unsigned int hvm, unsigned int pae, int superpages,
>                       int no_incr_generationid,
> -                      unsigned long *vm_generationid_addr)
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks)
>  {
>     DECLARE_DOMCTL;
>     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -1310,6 +1331,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>
>     pagebuf_t pagebuf;
>     tailbuf_t tailbuf, tmptail;
> +    struct toolstack_data_t tdata, tdata2, tdatatmp;
>

struct toolstack_data_t tdata, tdatatmp;

and the memsets ofcourse.


> @@ -1441,7 +1465,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>          if ( !ctx->completed ) {
>             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
>             pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
> -            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
> +            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom, &tdata)
> < 0 ) {
>                  PERROR("Error when reading batch");
>                 goto out;
>             }
>

Both live migration and Remus reach this piece of code, while applying
the 1st or Nth checkpoint (respectively)

if (ctx->last_checkpoint)
{
  //  DPRINTF("Last checkpoint, finishing\n");
  goto finish;
}

// DPRINTF("Buffered checkpoint\n");

if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {

So, your code could be plugged right on top of the first "if".

+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;

if (ctx->last_checkpoint)
...

@@ -2023,6 +2050,20 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>     goto out;
>
>   finish_hvm:
> +    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
>

how about another (tdata.data != NULL) ? If older versions of xen (with
lets say older libxl toolstack)
were to migrate to xen 4.2, they wouldnt be sending the TOOLSTACK_ID would
they?


> +    {
> +        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
> +                    callbacks->data) < 0 )
> +        {
> +            PERROR("error calling toolstack_restore");
> +            free(tdata.data);
> +            free(tdata2.data);
> +            goto out;
> +        }
> +    }
> +    free(tdata.data);
> +    free(tdata2.data);
> +
>

Add free(buf->tdata.data) to pagebuf_free and
just do free(tdata.data) here.

cheers
shriram

--0015175cac0ce49bc904b7dacf8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 10:58 AM, Stefano Stabel=
lini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.c=
om">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div class=3D"im">On Tue, 31 Jan 2012, Shriram Rajagopalan wrote:<br>
&gt; Or if you have to receive them in the pagebuf, then have two pieces of=
 the same state,<br>
&gt; =A0consistent_state, curr_state, such that you do<br>
&gt;<br>
&gt; =A0pagebuf_get(curr_state)<br>
&gt; =A0tailbuf_get(..)..<br>
&gt; =A0if (no error so far), then<br>
&gt; =A0 copy curr_state to consistent_state.<br>
&gt; =A0 goto copypages;<br>
&gt;<br>
&gt; finish:<br>
&gt; =A0..<br>
&gt; =A0 finish_hvm:<br>
&gt; =A0=A0=A0=A0 apply consistent_state.<br>
<br>
</div>I think I am starting to understand: see appended patch if it makes<b=
r>
things better.<br>
<br></blockquote><div><br>Instead of adding yet another parameter to pagebu=
f_get_one, you could<br>simplify the patch by adding a toolstack_data_t fie=
ld to the pagebuf struct.<br>See comments below.<br><br>=A0<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">


---<br>
<br>
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restor=
e.c<br>
index 3fda6f8..02b523d 100644<br>
--- a/tools/libxc/xc_domain_restore.c<br>
+++ b/tools/libxc/xc_domain_restore.c<br>
@@ -684,6 +684,11 @@ typedef struct {<br>
 =A0 =A0 uint64_t vm_generationid_addr;<br>
=A0} pagebuf_t;<br>
<br></blockquote><div>+struct toolstack_data_t {<br>
+ =A0 =A0uint8_t *data;<br>
<div class=3D"im">+ =A0 =A0uint32_t len;<br>
+};<br>
+<br>
</div><br>Add an instance of this struct to the pagebuf_t structure<br>(get=
s initialized to NULL, by pagebuf_init)<br><br>and dont forget to add the a=
ppropriate free calls to pagebuf_free.<br>=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">

=A0
static int pagebuf_init(pagebuf_t* buf)<br>
=A0{<br>
 =A0 =A0 memset(buf, 0, sizeof(*buf));<br>
@@ -703,7 +708,8 @@ static void pagebuf_free(pagebuf_t* buf)<br>
<div class=3D"im">=A0}<br>
<br>
=A0static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,<b=
r>
</div><div class=3D"im">- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 pagebuf_t* buf, int fd, uint32_t dom)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf_t* buf, int f=
d, uint32_t dom,<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct toolstac=
k_data_t *tdata)<br></blockquote><div><br>Eliminate the extra arg. and all =
the fixes to pagebuf_get_one() calls.<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">

<div class=3D"im">
+ =A0 =A0 =A0 =A0{<br>
</div>+ =A0 =A0case XC_SAVE_ID_TOOLSTACK:<br>+ =A0 =A0 =A0 =A0 =A0 =A0RDEXA=
CT(fd, &amp;tdata-&gt;len, sizeof(tdata-&gt;len));<br>
+ =A0 =A0 =A0 =A0 =A0 =A0tdata-&gt;data =3D (uint8_t*) realloc(tdata-&gt;da=
ta, tdata-&gt;len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( tdata-&gt;data =3D=3D NULL )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0{<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error memor=
y allocation&quot;);<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0}<br>
+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, tdata-&gt;data, tdata-&gt;len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, tda=
ta);<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0}<br>
<br></div></blockquote><div class=3D"im"><br>RDEXACT(fd, &amp;buf-&gt;tdata=
-&gt;len, sizeof())<br>...<br><br>
</div><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">@@ -1262,7 +1282,8 =
@@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,<br>
<div class=3D"im"> =A0 =A0 =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 =A0 =A0 =A0 unsigned int hvm, unsigned int=
 pae, int superpages,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int no_incr_generationid,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct restore_callbacks *call=
backs)<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>
</div>@@ -1310,6 +1331,7 @@ int xc_domain_restore(xc_interface *xch, int io=
_fd, uint32_t dom,<br>
<br>
 =A0 =A0 pagebuf_t pagebuf;<br>
 =A0 =A0 tailbuf_t tailbuf, tmptail;<br>
+ =A0 =A0struct toolstack_data_t tdata, tdata2, tdatatmp;<br></blockquote><=
div><br>struct toolstack_data_t tdata, tdatatmp;<br><br>and the memsets ofc=
ourse.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0=
pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
@@ -1441,7 +1465,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, u=
int32_t dom,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 if ( !ctx-&gt;completed ) {<br>
 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf.nr_physpages =3D pagebuf.nr_pages =3D 0;<b=
r>
 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf.compbuf_pos =3D pagebuf.compbuf_size =3D 0=
;<br>
- =A0 =A0 =A0 =A0 =A0 =A0if ( pagebuf_get_one(xch, ctx, &amp;pagebuf, io_fd=
, dom) &lt; 0 ) {<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0if ( pagebuf_get_one(xch, ctx, &amp;pagebuf,=
 io_fd, dom, &amp;tdata) &lt; 0 ) {<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;Error when =
reading batch&quot;);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;<br>
 =A0 =A0 =A0 =A0 =A0 =A0 }<br></div></blockquote><div><br>Both live migrati=
on and Remus reach this piece of code, while applying<br>the 1st or Nth che=
ckpoint (respectively)<br><br>if (ctx-&gt;last_checkpoint)<br>{<br>=A0 //=
=A0 DPRINTF(&quot;Last checkpoint, finishing\n&quot;);<br>

=A0 goto finish;<br>}<br><br>// DPRINTF(&quot;Buffered checkpoint\n&quot;);=
<br><br>if ( pagebuf_get(xch, ctx, &amp;pagebuf, io_fd, dom) ) {<br>
<br>So, your code could be plugged right on top of the first &quot;if&quot;=
.<br><br>+=A0=A0=A0 tdatatmp =3D tdata;<br>
+ =A0 =A0tdata =3D pagebuf.tdata;<br>
+ =A0=A0 pagebuf.tdata =3D tdatatmp;<br>
<br>if (ctx-&gt;last_checkpoint)<br>...<br> <br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
@@ -2023,6 +2050,20 @@ int xc_domain_restore(xc_interface *xch, int io_fd, =
uint32_t dom,<br>
 =A0 =A0 goto out;<br>
<br>
 =A0 finish_hvm:<br>
<div class=3D"im">+ =A0 =A0if ( callbacks !=3D NULL &amp;&amp; callbacks-&g=
t;toolstack_restore !=3D NULL )<br></div></blockquote><div><br>how about an=
other (tdata.data !=3D NULL) ? If older versions of xen (with lets say olde=
r libxl toolstack)<br>

were to migrate to xen 4.2, they wouldnt be sending the TOOLSTACK_ID would =
they?<br>=A0</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 cl=
ass=3D"im">


</div>+ =A0 =A0{<br>
+ =A0 =A0 =A0 =A0if ( callbacks-&gt;toolstack_restore(dom, tdata.data, tdat=
a.len,<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0callbacks-&gt;da=
ta) &lt; 0 )<br>
+ =A0 =A0 =A0 =A0{<br>
</div><div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error calling=
 toolstack_restore&quot;);<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0free(tdata.data);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0free(tdata2.data);<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0}<br>
</div>+ =A0 =A0free(tdata.data);<br>
+ =A0 =A0free(tdata2.data);<br>
<div class=3D"HOEnZb"><div class=3D"h5">+<br></div></div></blockquote><div>=
<br>Add free(buf-&gt;tdata.data) to pagebuf_free and<br>just do free(tdata.=
data) here.<br><br></div></div>cheers<br>shriram<br>

--0015175cac0ce49bc904b7dacf8f--


--===============4325662592453297858==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4325662592453297858==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 22:52:47 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 22: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 1RsMYj-0002Ub-4H; Tue, 31 Jan 2012 22:52:17 +0000
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsMYg-0002UW-Gf
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 22:52:14 +0000
Received: from [85.158.138.51:21939] by server-12.bemta-3.messagelabs.com id
	5B/74-24557-D90782F4; Tue, 31 Jan 2012 22:52:13 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-10.tower-174.messagelabs.com!1328050329!11471716!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 21132 invoked from network); 31 Jan 2012 22:52:11 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-10.tower-174.messagelabs.com with DHE-RSA-AES256-SHA
	encrypted SMTP; 31 Jan 2012 22:52:11 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VMq6r2004267
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 14:52:07 -0800
Received: by bkbzv3 with SMTP id zv3so936051bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 14:52:05 -0800 (PST)
Received: by 10.204.148.84 with SMTP id o20mr11193566bkv.103.1328050325461;
	Tue, 31 Jan 2012 14:52:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 14:51:25 -0800 (PST)
In-Reply-To: <alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
References: <alpine.DEB.2.00.1201301647180.3196@kaball-desktop>
	<1327942455-23587-1-git-send-email-stefano.stabellini@eu.citrix.com>
	<CAP8mzPMLGLmfPY4PJ5+JsiyFczHc=-z6Tm6gVKdTT+d0T96Znw@mail.gmail.com>
	<alpine.DEB.2.00.1201311457230.3196@kaball-desktop>
	<alpine.DEB.2.00.1201311505540.3196@kaball-desktop>
	<CAP8mzPP7E049RhNVF=TNSgVVh+dPiFHauDJ85Kwcyd38bMyizg@mail.gmail.com>
	<alpine.DEB.2.00.1201311847140.3196@kaball-desktop>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 14:51:25 -0800
Message-ID: <CAP8mzPOxDONHTNFmr6HurRqwucno8UaOjVzrfogHP5GCqaoZ-A@mail.gmail.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3 1/2] libxc: introduce XC_SAVE_ID_TOOLSTACK
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============4325662592453297858=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============4325662592453297858==
Content-Type: multipart/alternative; boundary=0015175cac0ce49bc904b7dacf8f

--0015175cac0ce49bc904b7dacf8f
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 10:58 AM, Stefano Stabellini <
stefano.stabellini@eu.citrix.com> wrote:

> On Tue, 31 Jan 2012, Shriram Rajagopalan wrote:
> > Or if you have to receive them in the pagebuf, then have two pieces of
> the same state,
> >  consistent_state, curr_state, such that you do
> >
> >  pagebuf_get(curr_state)
> >  tailbuf_get(..)..
> >  if (no error so far), then
> >   copy curr_state to consistent_state.
> >   goto copypages;
> >
> > finish:
> >  ..
> >   finish_hvm:
> >      apply consistent_state.
>
> I think I am starting to understand: see appended patch if it makes
> things better.
>
>
Instead of adding yet another parameter to pagebuf_get_one, you could
simplify the patch by adding a toolstack_data_t field to the pagebuf struct.
See comments below.



> ---
>
> diff --git a/tools/libxc/xc_domain_restore.c
> b/tools/libxc/xc_domain_restore.c
> index 3fda6f8..02b523d 100644
> --- a/tools/libxc/xc_domain_restore.c
> +++ b/tools/libxc/xc_domain_restore.c
> @@ -684,6 +684,11 @@ typedef struct {
>     uint64_t vm_generationid_addr;
>  } pagebuf_t;
>
> +struct toolstack_data_t {
+    uint8_t *data;
+    uint32_t len;
+};
+

Add an instance of this struct to the pagebuf_t structure
(gets initialized to NULL, by pagebuf_init)

and dont forget to add the appropriate free calls to pagebuf_free.


>   static int pagebuf_init(pagebuf_t* buf)
>  {
>     memset(buf, 0, sizeof(*buf));
> @@ -703,7 +708,8 @@ static void pagebuf_free(pagebuf_t* buf)
>  }
>
>  static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,
> -                           pagebuf_t* buf, int fd, uint32_t dom)
> +                           pagebuf_t* buf, int fd, uint32_t dom,
> +                           struct toolstack_data_t *tdata)
>

Eliminate the extra arg. and all the fixes to pagebuf_get_one() calls.

 +        {
> +    case XC_SAVE_ID_TOOLSTACK:
> +            RDEXACT(fd, &tdata->len, sizeof(tdata->len));
> +            tdata->data = (uint8_t*) realloc(tdata->data, tdata->len);
> +            if ( tdata->data == NULL )
> +            {
> +                PERROR("error memory allocation");
> +                return -1;
> +            }
> +            RDEXACT(fd, tdata->data, tdata->len);
> +            return pagebuf_get_one(xch, ctx, buf, fd, dom, tdata);
> +        }
>
>
RDEXACT(fd, &buf->tdata->len, sizeof())
...

@@ -1262,7 +1282,8 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>                        unsigned int console_evtchn, unsigned long
> *console_mfn,
>                       unsigned int hvm, unsigned int pae, int superpages,
>                       int no_incr_generationid,
> -                      unsigned long *vm_generationid_addr)
> +                      unsigned long *vm_generationid_addr,
> +                      struct restore_callbacks *callbacks)
>  {
>     DECLARE_DOMCTL;
>     int rc = 1, frc, i, j, n, m, pae_extended_cr3 = 0, ext_vcpucontext = 0;
> @@ -1310,6 +1331,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>
>     pagebuf_t pagebuf;
>     tailbuf_t tailbuf, tmptail;
> +    struct toolstack_data_t tdata, tdata2, tdatatmp;
>

struct toolstack_data_t tdata, tdatatmp;

and the memsets ofcourse.


> @@ -1441,7 +1465,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>          if ( !ctx->completed ) {
>             pagebuf.nr_physpages = pagebuf.nr_pages = 0;
>             pagebuf.compbuf_pos = pagebuf.compbuf_size = 0;
> -            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom) < 0 ) {
> +            if ( pagebuf_get_one(xch, ctx, &pagebuf, io_fd, dom, &tdata)
> < 0 ) {
>                  PERROR("Error when reading batch");
>                 goto out;
>             }
>

Both live migration and Remus reach this piece of code, while applying
the 1st or Nth checkpoint (respectively)

if (ctx->last_checkpoint)
{
  //  DPRINTF("Last checkpoint, finishing\n");
  goto finish;
}

// DPRINTF("Buffered checkpoint\n");

if ( pagebuf_get(xch, ctx, &pagebuf, io_fd, dom) ) {

So, your code could be plugged right on top of the first "if".

+    tdatatmp = tdata;
+    tdata = pagebuf.tdata;
+    pagebuf.tdata = tdatatmp;

if (ctx->last_checkpoint)
...

@@ -2023,6 +2050,20 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
> uint32_t dom,
>     goto out;
>
>   finish_hvm:
> +    if ( callbacks != NULL && callbacks->toolstack_restore != NULL )
>

how about another (tdata.data != NULL) ? If older versions of xen (with
lets say older libxl toolstack)
were to migrate to xen 4.2, they wouldnt be sending the TOOLSTACK_ID would
they?


> +    {
> +        if ( callbacks->toolstack_restore(dom, tdata.data, tdata.len,
> +                    callbacks->data) < 0 )
> +        {
> +            PERROR("error calling toolstack_restore");
> +            free(tdata.data);
> +            free(tdata2.data);
> +            goto out;
> +        }
> +    }
> +    free(tdata.data);
> +    free(tdata2.data);
> +
>

Add free(buf->tdata.data) to pagebuf_free and
just do free(tdata.data) here.

cheers
shriram

--0015175cac0ce49bc904b7dacf8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 10:58 AM, Stefano Stabel=
lini <span dir=3D"ltr">&lt;<a href=3D"mailto:stefano.stabellini@eu.citrix.c=
om">stefano.stabellini@eu.citrix.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div class=3D"im">On Tue, 31 Jan 2012, Shriram Rajagopalan wrote:<br>
&gt; Or if you have to receive them in the pagebuf, then have two pieces of=
 the same state,<br>
&gt; =A0consistent_state, curr_state, such that you do<br>
&gt;<br>
&gt; =A0pagebuf_get(curr_state)<br>
&gt; =A0tailbuf_get(..)..<br>
&gt; =A0if (no error so far), then<br>
&gt; =A0 copy curr_state to consistent_state.<br>
&gt; =A0 goto copypages;<br>
&gt;<br>
&gt; finish:<br>
&gt; =A0..<br>
&gt; =A0 finish_hvm:<br>
&gt; =A0=A0=A0=A0 apply consistent_state.<br>
<br>
</div>I think I am starting to understand: see appended patch if it makes<b=
r>
things better.<br>
<br></blockquote><div><br>Instead of adding yet another parameter to pagebu=
f_get_one, you could<br>simplify the patch by adding a toolstack_data_t fie=
ld to the pagebuf struct.<br>See comments below.<br><br>=A0<br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">


---<br>
<br>
diff --git a/tools/libxc/xc_domain_restore.c b/tools/libxc/xc_domain_restor=
e.c<br>
index 3fda6f8..02b523d 100644<br>
--- a/tools/libxc/xc_domain_restore.c<br>
+++ b/tools/libxc/xc_domain_restore.c<br>
@@ -684,6 +684,11 @@ typedef struct {<br>
 =A0 =A0 uint64_t vm_generationid_addr;<br>
=A0} pagebuf_t;<br>
<br></blockquote><div>+struct toolstack_data_t {<br>
+ =A0 =A0uint8_t *data;<br>
<div class=3D"im">+ =A0 =A0uint32_t len;<br>
+};<br>
+<br>
</div><br>Add an instance of this struct to the pagebuf_t structure<br>(get=
s initialized to NULL, by pagebuf_init)<br><br>and dont forget to add the a=
ppropriate free calls to pagebuf_free.<br>=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">

=A0
static int pagebuf_init(pagebuf_t* buf)<br>
=A0{<br>
 =A0 =A0 memset(buf, 0, sizeof(*buf));<br>
@@ -703,7 +708,8 @@ static void pagebuf_free(pagebuf_t* buf)<br>
<div class=3D"im">=A0}<br>
<br>
=A0static int pagebuf_get_one(xc_interface *xch, struct restore_ctx *ctx,<b=
r>
</div><div class=3D"im">- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 pagebuf_t* buf, int fd, uint32_t dom)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf_t* buf, int f=
d, uint32_t dom,<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct toolstac=
k_data_t *tdata)<br></blockquote><div><br>Eliminate the extra arg. and all =
the fixes to pagebuf_get_one() calls.<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">

<div class=3D"im">
+ =A0 =A0 =A0 =A0{<br>
</div>+ =A0 =A0case XC_SAVE_ID_TOOLSTACK:<br>+ =A0 =A0 =A0 =A0 =A0 =A0RDEXA=
CT(fd, &amp;tdata-&gt;len, sizeof(tdata-&gt;len));<br>
+ =A0 =A0 =A0 =A0 =A0 =A0tdata-&gt;data =3D (uint8_t*) realloc(tdata-&gt;da=
ta, tdata-&gt;len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0if ( tdata-&gt;data =3D=3D NULL )<br>
+ =A0 =A0 =A0 =A0 =A0 =A0{<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error memor=
y allocation&quot;);<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return -1;<br>
+ =A0 =A0 =A0 =A0 =A0 =A0}<br>
+ =A0 =A0 =A0 =A0 =A0 =A0RDEXACT(fd, tdata-&gt;data, tdata-&gt;len);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0return pagebuf_get_one(xch, ctx, buf, fd, dom, tda=
ta);<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0}<br>
<br></div></blockquote><div class=3D"im"><br>RDEXACT(fd, &amp;buf-&gt;tdata=
-&gt;len, sizeof())<br>...<br><br>
</div><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">@@ -1262,7 +1282,8 =
@@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,<br>
<div class=3D"im"> =A0 =A0 =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 =A0 =A0 =A0 unsigned int hvm, unsigned int=
 pae, int superpages,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int no_incr_generationid,<br>
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr)<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long *vm_generationid=
_addr,<br>
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct restore_callbacks *call=
backs)<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>
</div>@@ -1310,6 +1331,7 @@ int xc_domain_restore(xc_interface *xch, int io=
_fd, uint32_t dom,<br>
<br>
 =A0 =A0 pagebuf_t pagebuf;<br>
 =A0 =A0 tailbuf_t tailbuf, tmptail;<br>
+ =A0 =A0struct toolstack_data_t tdata, tdata2, tdatatmp;<br></blockquote><=
div><br>struct toolstack_data_t tdata, tdatatmp;<br><br>and the memsets ofc=
ourse.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0=
pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
@@ -1441,7 +1465,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, u=
int32_t dom,<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 if ( !ctx-&gt;completed ) {<br>
 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf.nr_physpages =3D pagebuf.nr_pages =3D 0;<b=
r>
 =A0 =A0 =A0 =A0 =A0 =A0 pagebuf.compbuf_pos =3D pagebuf.compbuf_size =3D 0=
;<br>
- =A0 =A0 =A0 =A0 =A0 =A0if ( pagebuf_get_one(xch, ctx, &amp;pagebuf, io_fd=
, dom) &lt; 0 ) {<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0if ( pagebuf_get_one(xch, ctx, &amp;pagebuf,=
 io_fd, dom, &amp;tdata) &lt; 0 ) {<br>
<div class=3D"im"> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 PERROR(&quot;Error when =
reading batch&quot;);<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;<br>
 =A0 =A0 =A0 =A0 =A0 =A0 }<br></div></blockquote><div><br>Both live migrati=
on and Remus reach this piece of code, while applying<br>the 1st or Nth che=
ckpoint (respectively)<br><br>if (ctx-&gt;last_checkpoint)<br>{<br>=A0 //=
=A0 DPRINTF(&quot;Last checkpoint, finishing\n&quot;);<br>

=A0 goto finish;<br>}<br><br>// DPRINTF(&quot;Buffered checkpoint\n&quot;);=
<br><br>if ( pagebuf_get(xch, ctx, &amp;pagebuf, io_fd, dom) ) {<br>
<br>So, your code could be plugged right on top of the first &quot;if&quot;=
.<br><br>+=A0=A0=A0 tdatatmp =3D tdata;<br>
+ =A0 =A0tdata =3D pagebuf.tdata;<br>
+ =A0=A0 pagebuf.tdata =3D tdatatmp;<br>
<br>if (ctx-&gt;last_checkpoint)<br>...<br> <br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
@@ -2023,6 +2050,20 @@ int xc_domain_restore(xc_interface *xch, int io_fd, =
uint32_t dom,<br>
 =A0 =A0 goto out;<br>
<br>
 =A0 finish_hvm:<br>
<div class=3D"im">+ =A0 =A0if ( callbacks !=3D NULL &amp;&amp; callbacks-&g=
t;toolstack_restore !=3D NULL )<br></div></blockquote><div><br>how about an=
other (tdata.data !=3D NULL) ? If older versions of xen (with lets say olde=
r libxl toolstack)<br>

were to migrate to xen 4.2, they wouldnt be sending the TOOLSTACK_ID would =
they?<br>=A0</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 cl=
ass=3D"im">


</div>+ =A0 =A0{<br>
+ =A0 =A0 =A0 =A0if ( callbacks-&gt;toolstack_restore(dom, tdata.data, tdat=
a.len,<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0callbacks-&gt;da=
ta) &lt; 0 )<br>
+ =A0 =A0 =A0 =A0{<br>
</div><div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0PERROR(&quot;error calling=
 toolstack_restore&quot;);<br>
</div>+ =A0 =A0 =A0 =A0 =A0 =A0free(tdata.data);<br>
+ =A0 =A0 =A0 =A0 =A0 =A0free(tdata2.data);<br>
<div class=3D"im">+ =A0 =A0 =A0 =A0 =A0 =A0goto out;<br>
+ =A0 =A0 =A0 =A0}<br>
+ =A0 =A0}<br>
</div>+ =A0 =A0free(tdata.data);<br>
+ =A0 =A0free(tdata2.data);<br>
<div class=3D"HOEnZb"><div class=3D"h5">+<br></div></div></blockquote><div>=
<br>Add free(buf-&gt;tdata.data) to pagebuf_free and<br>just do free(tdata.=
data) here.<br><br></div></div>cheers<br>shriram<br>

--0015175cac0ce49bc904b7dacf8f--


--===============4325662592453297858==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============4325662592453297858==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 23:55:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 23: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 1RsNX4-00036O-KJ; Tue, 31 Jan 2012 23:54:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsNX2-00036J-O6
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 23:54:37 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328054066!9541756!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10089 invoked from network); 31 Jan 2012 23:54:28 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 23:54:28 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VNsOik021017
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 15:54:25 -0800
Received: by bkbzv3 with SMTP id zv3so1025158bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 15:54:22 -0800 (PST)
Received: by 10.204.148.84 with SMTP id o20mr11267918bkv.103.1328054062397;
	Tue, 31 Jan 2012 15:54:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 15:53:42 -0800 (PST)
In-Reply-To: <CAP8mzPMer3bnxqBRCJYCYqi5nR9DcjQzmRbebNDKD39bm=v+pg@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
	<1328003681.26983.318.camel@zakaz.uk.xensource.com>
	<CAP8mzPMer3bnxqBRCJYCYqi5nR9DcjQzmRbebNDKD39bm=v+pg@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 15:53:42 -0800
Message-ID: <CAP8mzPMHGfRRATgAya9vFqdcK85R_zUBXsa17S2URfpDqWEHMA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
	QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============0325357120574861163=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0325357120574861163==
Content-Type: multipart/alternative; boundary=0015175cac0ca1ba2604b7dbae25

--0015175cac0ca1ba2604b7dbae25
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 9:32 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> On Tue, Jan 31, 2012 at 1:54 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
>
>> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
>> > +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
>> > +{
>> > +
>> > +    switch (libxl__device_model_version_running(gc, domid)) {
>> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
>> > +        libxl__qemu_traditional_cmd(gc, domid, "continue");
>>
>> No libxl__wait_for_device_model -> "running"?
>>
>>
> Nope. Thats how xend/remus also does it. There seems to be no reference to
> such
> a state anywhere.
>
>
>>  > +        break;
>> > +    }
>> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
>> > +        if (libxl__qmp_resume(gc, domid))
>> > +            return ERROR_FAIL;
>> > +    default:
>> > +        return ERROR_INVAL;
>> > +    }
>> > +
>> > +    return 0;
>> > +}
>> > +
>> >  static int libxl__domain_suspend_common_callback(void *data)
>> >  {
>> >      struct suspendinfo *si = data;
>> > @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
>> >              return 0;
>> >          }
>> >          si->guest_responded = 1;
>> > -        return 1;
>> > +        goto suspend_dm;
>> >      }
>> >
>> >      if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
>> > @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
>> >              shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
>> & XEN_DOMINF_shutdownmask;
>> >              if (shutdown_reason == SHUTDOWN_suspend) {
>> >                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has
>> suspended");
>> > -                return 1;
>> > +                goto suspend_dm;
>> >              }
>> >          }
>> >
>> > @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
>> >
>> >      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
>> >      return 0;
>> > +
>> > + suspend_dm:
>>
>> The goto's make the code flow a bit tricky to follow (this function is
>> already a bit tricksy with the early exit for the evtchn suspend case).
>>
>> Why not pass si to libxl__domain_suspend_device_model and let it contain
>> the "if !hvm return" and logging stuff so you can just call in in place
>> of the two goto statements?
>>
>>
> will do.
>
>
I gave it a shot. Passing suspendinfo struct to suspend_device_model is not
feasible, as the function is declared in libxl_internal.h, but suspendinfo
struct
declaration is local to libxl_dom.c.  I am not sure if its worthwhile to
declare a private struct like suspendinfo in libxl_internal.h, just to get
rid of this goto.

OTOH, passing a dummy hvm parameter to the function looks a bit silly

libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid, int hvm)

What do you think? goto needs to go?

shriram

--0015175cac0ca1ba2604b7dbae25
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 9:32 AM, Shriram Rajagop=
alan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@c=
s.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"gmail_quote"><div class=3D"im">On Tue, Jan 31, 2012 at 1:54 A=
M, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix=
.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">


<div><div><div class=3D"im">On Tue, 2012-01-31 at 01:05 +0000, <a href=3D"m=
ailto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a> wrote:<b=
r></div><div class=3D"im">
&gt; +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)<=
br>
&gt; +{<br>
&gt; +<br>
&gt; + =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; + =A0 =A0 =A0 =A0libxl__qemu_traditional_cmd(gc, domid, &quot;continue=
&quot;);<br>
<br>
</div></div></div><div class=3D"im">No libxl__wait_for_device_model -&gt; &=
quot;running&quot;?<br>
<div><div><br></div></div></div></blockquote><div><br>Nope. Thats how xend/=
remus also does it. There seems to be no reference to such<br>a state anywh=
ere.<br>=A0<br></div><div><div class=3D"h5"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">


<div><div>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0}<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; + =A0 =A0 =A0 =A0if (libxl__qmp_resume(gc, domid))<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
&gt; + =A0 =A0default:<br>
&gt; + =A0 =A0 =A0 =A0return ERROR_INVAL;<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return 0;<br>
&gt; +}<br>
&gt; +<br>
&gt; =A0static int libxl__domain_suspend_common_callback(void *data)<br>
&gt; =A0{<br>
&gt; =A0 =A0 =A0struct suspendinfo *si =3D data;<br>
&gt; @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0si-&gt;guest_responded =3D 1;<br>
&gt; - =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0goto suspend_dm;<br>
&gt; =A0 =A0 =A0}<br>
&gt;<br>
&gt; =A0 =A0 =A0if (si-&gt;hvm &amp;&amp; (!hvm_pvdrv || hvm_s_state)) {<br=
>
&gt; @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0shutdown_reason =3D (info.flags &gt;&gt; XE=
N_DOMINF_shutdownshift) &amp; XEN_DOMINF_shutdownmask;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0if (shutdown_reason =3D=3D SHUTDOWN_suspend=
) {<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, &=
quot;guest has suspended&quot;);<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto suspend_dm;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt;<br>
&gt; @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_<br>
&gt;<br>
&gt; =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;guest did not suspe=
nd&quot;);<br>
&gt; =A0 =A0 =A0return 0;<br>
&gt; +<br>
&gt; + suspend_dm:<br>
<br>
</div></div>The goto&#39;s make the code flow a bit tricky to follow (this =
function is<br>
already a bit tricksy with the early exit for the evtchn suspend case).<br>
<br>
Why not pass si to libxl__domain_suspend_device_model and let it contain<br=
>
the &quot;if !hvm return&quot; and logging stuff so you can just call in in=
 place<br>
of the two goto statements?<br>
<div><div><br></div></div></blockquote></div></div><div><br>will do. <br></=
div><span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div>=
</blockquote><div><br>I gave it a shot. Passing suspendinfo struct to suspe=
nd_device_model is not<br>

feasible, as the function is declared in libxl_internal.h, but suspendinfo =
struct<br>declaration is local to libxl_dom.c.=A0 I am not sure if its wort=
hwhile to <br>declare a private struct like suspendinfo in libxl_internal.h=
, just to get rid of this goto.<br>

<br>OTOH, passing a dummy hvm parameter to the function looks a bit silly<b=
r><br>libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid, int=
 hvm)<br><br></div></div>What do you think? goto needs to go? <br><br>
shriram<br>

--0015175cac0ca1ba2604b7dbae25--


--===============0325357120574861163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0325357120574861163==--


From xen-devel-bounces@lists.xensource.com Tue Jan 31 23:55:15 2012
Return-path: <xen-devel-bounces@lists.xensource.com>
Envelope-to: archives@lists.xen.org
Delivery-date: Tue, 31 Jan 2012 23: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 1RsNX4-00036O-KJ; Tue, 31 Jan 2012 23:54:38 +0000
Received: from mail216.messagelabs.com ([85.158.143.99])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <rshriram@cs.ubc.ca>) id 1RsNX2-00036J-O6
	for xen-devel@lists.xensource.com; Tue, 31 Jan 2012 23:54:37 +0000
X-Env-Sender: rshriram@cs.ubc.ca
X-Msg-Ref: server-7.tower-216.messagelabs.com!1328054066!9541756!1
X-Originating-IP: [142.103.6.52]
X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_40_50,HTML_MESSAGE,
	RCVD_BY_IP
X-StarScan-Version: 6.5.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 10089 invoked from network); 31 Jan 2012 23:54:28 -0000
Received: from smtp.cs.ubc.ca (HELO smtp.cs.ubc.ca) (142.103.6.52)
	by server-7.tower-216.messagelabs.com with DHE-RSA-AES256-SHA encrypted
	SMTP; 31 Jan 2012 23:54:28 -0000
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com
	[209.85.214.43]) (authenticated bits=0)
	by smtp.cs.ubc.ca (8.14.3/8.13.6) with ESMTP id q0VNsOik021017
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL)
	for <xen-devel@lists.xensource.com>; Tue, 31 Jan 2012 15:54:25 -0800
Received: by bkbzv3 with SMTP id zv3so1025158bkb.30
	for <xen-devel@lists.xensource.com>;
	Tue, 31 Jan 2012 15:54:22 -0800 (PST)
Received: by 10.204.148.84 with SMTP id o20mr11267918bkv.103.1328054062397;
	Tue, 31 Jan 2012 15:54:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.204.52.135 with HTTP; Tue, 31 Jan 2012 15:53:42 -0800 (PST)
In-Reply-To: <CAP8mzPMer3bnxqBRCJYCYqi5nR9DcjQzmRbebNDKD39bm=v+pg@mail.gmail.com>
References: <patchbomb.1327971905@athos.nss.cs.ubc.ca>
	<cd3d43d88c0568142dd0.1327971908@athos.nss.cs.ubc.ca>
	<1328003681.26983.318.camel@zakaz.uk.xensource.com>
	<CAP8mzPMer3bnxqBRCJYCYqi5nR9DcjQzmRbebNDKD39bm=v+pg@mail.gmail.com>
From: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Date: Tue, 31 Jan 2012 15:53:42 -0800
Message-ID: <CAP8mzPMHGfRRATgAya9vFqdcK85R_zUBXsa17S2URfpDqWEHMA@mail.gmail.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	"brendan@cs.ubc.ca" <brendan@cs.ubc.ca>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [Xen-devel] [PATCH 3 of 6] libxl: QMP stop/resume & refactor
	QEMU suspend/resume/save
X-BeenThere: xen-devel@lists.xensource.com
X-Mailman-Version: 2.1.13
Precedence: list
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="===============0325357120574861163=="
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com

--===============0325357120574861163==
Content-Type: multipart/alternative; boundary=0015175cac0ca1ba2604b7dbae25

--0015175cac0ca1ba2604b7dbae25
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 31, 2012 at 9:32 AM, Shriram Rajagopalan <rshriram@cs.ubc.ca>wrote:

> On Tue, Jan 31, 2012 at 1:54 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:
>
>> On Tue, 2012-01-31 at 01:05 +0000, rshriram@cs.ubc.ca wrote:
>> > +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)
>> > +{
>> > +
>> > +    switch (libxl__device_model_version_running(gc, domid)) {
>> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {
>> > +        libxl__qemu_traditional_cmd(gc, domid, "continue");
>>
>> No libxl__wait_for_device_model -> "running"?
>>
>>
> Nope. Thats how xend/remus also does it. There seems to be no reference to
> such
> a state anywhere.
>
>
>>  > +        break;
>> > +    }
>> > +    case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
>> > +        if (libxl__qmp_resume(gc, domid))
>> > +            return ERROR_FAIL;
>> > +    default:
>> > +        return ERROR_INVAL;
>> > +    }
>> > +
>> > +    return 0;
>> > +}
>> > +
>> >  static int libxl__domain_suspend_common_callback(void *data)
>> >  {
>> >      struct suspendinfo *si = data;
>> > @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_
>> >              return 0;
>> >          }
>> >          si->guest_responded = 1;
>> > -        return 1;
>> > +        goto suspend_dm;
>> >      }
>> >
>> >      if (si->hvm && (!hvm_pvdrv || hvm_s_state)) {
>> > @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_
>> >              shutdown_reason = (info.flags >> XEN_DOMINF_shutdownshift)
>> & XEN_DOMINF_shutdownmask;
>> >              if (shutdown_reason == SHUTDOWN_suspend) {
>> >                  LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "guest has
>> suspended");
>> > -                return 1;
>> > +                goto suspend_dm;
>> >              }
>> >          }
>> >
>> > @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_
>> >
>> >      LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "guest did not suspend");
>> >      return 0;
>> > +
>> > + suspend_dm:
>>
>> The goto's make the code flow a bit tricky to follow (this function is
>> already a bit tricksy with the early exit for the evtchn suspend case).
>>
>> Why not pass si to libxl__domain_suspend_device_model and let it contain
>> the "if !hvm return" and logging stuff so you can just call in in place
>> of the two goto statements?
>>
>>
> will do.
>
>
I gave it a shot. Passing suspendinfo struct to suspend_device_model is not
feasible, as the function is declared in libxl_internal.h, but suspendinfo
struct
declaration is local to libxl_dom.c.  I am not sure if its worthwhile to
declare a private struct like suspendinfo in libxl_internal.h, just to get
rid of this goto.

OTOH, passing a dummy hvm parameter to the function looks a bit silly

libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid, int hvm)

What do you think? goto needs to go?

shriram

--0015175cac0ca1ba2604b7dbae25
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jan 31, 2012 at 9:32 AM, Shriram Rajagop=
alan <span dir=3D"ltr">&lt;<a href=3D"mailto:rshriram@cs.ubc.ca">rshriram@c=
s.ubc.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"gmail_quote"><div class=3D"im">On Tue, Jan 31, 2012 at 1:54 A=
M, Ian Campbell <span dir=3D"ltr">&lt;<a href=3D"mailto:Ian.Campbell@citrix=
.com" target=3D"_blank">Ian.Campbell@citrix.com</a>&gt;</span> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">


<div><div><div class=3D"im">On Tue, 2012-01-31 at 01:05 +0000, <a href=3D"m=
ailto:rshriram@cs.ubc.ca" target=3D"_blank">rshriram@cs.ubc.ca</a> wrote:<b=
r></div><div class=3D"im">
&gt; +int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t domid)<=
br>
&gt; +{<br>
&gt; +<br>
&gt; + =A0 =A0switch (libxl__device_model_version_running(gc, domid)) {<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL: {<br>
&gt; + =A0 =A0 =A0 =A0libxl__qemu_traditional_cmd(gc, domid, &quot;continue=
&quot;);<br>
<br>
</div></div></div><div class=3D"im">No libxl__wait_for_device_model -&gt; &=
quot;running&quot;?<br>
<div><div><br></div></div></div></blockquote><div><br>Nope. Thats how xend/=
remus also does it. There seems to be no reference to such<br>a state anywh=
ere.<br>=A0<br></div><div><div class=3D"h5"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">


<div><div>
&gt; + =A0 =A0 =A0 =A0break;<br>
&gt; + =A0 =A0}<br>
&gt; + =A0 =A0case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:<br>
&gt; + =A0 =A0 =A0 =A0if (libxl__qmp_resume(gc, domid))<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0return ERROR_FAIL;<br>
&gt; + =A0 =A0default:<br>
&gt; + =A0 =A0 =A0 =A0return ERROR_INVAL;<br>
&gt; + =A0 =A0}<br>
&gt; +<br>
&gt; + =A0 =A0return 0;<br>
&gt; +}<br>
&gt; +<br>
&gt; =A0static int libxl__domain_suspend_common_callback(void *data)<br>
&gt; =A0{<br>
&gt; =A0 =A0 =A0struct suspendinfo *si =3D data;<br>
&gt; @@ -454,7 +509,7 @@ static int libxl__domain_suspend_common_<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0return 0;<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0si-&gt;guest_responded =3D 1;<br>
&gt; - =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0goto suspend_dm;<br>
&gt; =A0 =A0 =A0}<br>
&gt;<br>
&gt; =A0 =A0 =A0if (si-&gt;hvm &amp;&amp; (!hvm_pvdrv || hvm_s_state)) {<br=
>
&gt; @@ -532,7 +587,7 @@ static int libxl__domain_suspend_common_<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0shutdown_reason =3D (info.flags &gt;&gt; XE=
N_DOMINF_shutdownshift) &amp; XEN_DOMINF_shutdownmask;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0if (shutdown_reason =3D=3D SHUTDOWN_suspend=
) {<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, &=
quot;guest has suspended&quot;);<br>
&gt; - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return 1;<br>
&gt; + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto suspend_dm;<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0}<br>
&gt; =A0 =A0 =A0 =A0 =A0}<br>
&gt;<br>
&gt; @@ -541,6 +596,17 @@ static int libxl__domain_suspend_common_<br>
&gt;<br>
&gt; =A0 =A0 =A0LIBXL__LOG(ctx, LIBXL__LOG_ERROR, &quot;guest did not suspe=
nd&quot;);<br>
&gt; =A0 =A0 =A0return 0;<br>
&gt; +<br>
&gt; + suspend_dm:<br>
<br>
</div></div>The goto&#39;s make the code flow a bit tricky to follow (this =
function is<br>
already a bit tricksy with the early exit for the evtchn suspend case).<br>
<br>
Why not pass si to libxl__domain_suspend_device_model and let it contain<br=
>
the &quot;if !hvm return&quot; and logging stuff so you can just call in in=
 place<br>
of the two goto statements?<br>
<div><div><br></div></div></blockquote></div></div><div><br>will do. <br></=
div><span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div>=
</blockquote><div><br>I gave it a shot. Passing suspendinfo struct to suspe=
nd_device_model is not<br>

feasible, as the function is declared in libxl_internal.h, but suspendinfo =
struct<br>declaration is local to libxl_dom.c.=A0 I am not sure if its wort=
hwhile to <br>declare a private struct like suspendinfo in libxl_internal.h=
, just to get rid of this goto.<br>

<br>OTOH, passing a dummy hvm parameter to the function looks a bit silly<b=
r><br>libxl__domain_suspend_device_model(libxl__gc *gc, uint32_t domid, int=
 hvm)<br><br></div></div>What do you think? goto needs to go? <br><br>
shriram<br>

--0015175cac0ca1ba2604b7dbae25--


--===============0325357120574861163==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

--===============0325357120574861163==--